From xen-devel-bounces@lists.xenproject.org Thu Jan 01 22:56:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Jan 2026 22:56:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1194792.1512981 (Exim 4.92) (envelope-from ) id 1vbRan-0000po-VD; Thu, 01 Jan 2026 22:56:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1194792.1512981; Thu, 01 Jan 2026 22:56:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vbRan-0000pg-Rl; Thu, 01 Jan 2026 22:56:29 +0000 Received: by outflank-mailman (input) for mailman id 1194792; Thu, 01 Jan 2026 22:56: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 1vbRam-0000pa-EI for xen-devel@lists.xenproject.org; Thu, 01 Jan 2026 22:56:28 +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 1986dcc7-e765-11f0-b15e-2bf370ae4941; Thu, 01 Jan 2026 23:56:26 +0100 (CET) Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfout.stl.internal (Postfix) with ESMTP id E7A6C1D000B5; Thu, 1 Jan 2026 17:56:24 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Thu, 01 Jan 2026 17:56:25 -0500 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 1 Jan 2026 17:56:23 -0500 (EST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1986dcc7-e765-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:message-id:mime-version:reply-to :subject:subject:to:to; s=fm1; t=1767308184; x=1767394584; bh=aV Knce9UA3xLzfq4I/i29bc4sVrFPEl/2n54K2rVS1Y=; b=dxTDEVcQXAAvHqAkYZ 5A8Q+Zxzty4kB7X9kCh8XiqhouAWpQhMfJfw6ddV8UZaIjJDcDMe9jVzPwvZnRh2 lCsQenFYdAed+0gI8lKWnmLJnNttrnS8r8irJcPR61XaQ1VoVCE3jAtw+WzlMRt1 jqZ1QRXFzTn+Uw0ii6X+5ljl3uqfV03qppWGuQV00zJ5a0B0k1pKTjrc1Bwi/U1v 3RuJyspO37ka4S7uRx2sCxW3Hu2B23E1B5nv6kT/zT504N5rn5bQPCQMUYKT8ri7 rewQ4ggQiJTz1OW8Wuenq8u0NeLA6T3oIUh0F8s7ShW63db3KYrQ4c3jP/eUVxUY kVcQ== 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=fm2; t=1767308184; x= 1767394584; bh=aVKnce9UA3xLzfq4I/i29bc4sVrFPEl/2n54K2rVS1Y=; b=S UzJXl1Bqbm/cpkQsxJzT5ASRFnyTMVDV2wms8kkYTxtN6A85LMb3k67m1Qkm/adG WSJWP7D0fbsz6S6Z4cC73k78b2u8scEc9dmmuKINScJ5X5FTA7dHgMtR1HTej6e1 BWLDQEpRyWelDc/711xQ/BT5uCl1pT+9/wXu+OEOguCJQl0kInyOjjqqF9N08SV1 lK5Eey7zmJaqOmWsxA7VlgQUZaw/+XkyGcjpIeSe/OBvQC/b2IxDgkJDIff2xIIF nJIgrNenFxx5QX3CPlAfFRx4bxtlzi7H/ZWQ5PzeHhHkupHcEDF0JTX6EpqeL8xI lFaVz9aZ0iXfTtgphpEHg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdekjedtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpeffhffvvefukfggtggusehgtderredttdejnecuhfhrohhmpeforghrvghkucforghr tgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhishhisg hlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefgtdfgvdetteff leeugfdugfegjeekgfefffdvheffhfdtfeeggfeuhedtffeuleenucffohhmrghinhepqh husggvshdqohhsrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsg drtghomhdpnhgspghrtghpthhtohepgedpmhhouggvpehsmhhtphhouhhtpdhrtghpthht ohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtg hpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomhdprhgtphhtthhopegrnhgurhgv fidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtghpthhtoheprhhoghgvrhdrph gruhestghithhrihigrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Thu, 1 Jan 2026 23:56:12 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: xen-devel Cc: Jan Beulich , Andrew Cooper , Roger Pau =?utf-8?B?TW9ubsOp?= Subject: Dealing with SIOV/IMS Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NBzhMn7VFeiIx1Hq" Content-Disposition: inline --NBzhMn7VFeiIx1Hq Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jan 2026 23:56:12 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: xen-devel Cc: Jan Beulich , Andrew Cooper , Roger Pau =?utf-8?B?TW9ubsOp?= Subject: Dealing with SIOV/IMS Hi, I've got yet another report[1] of device failing because (I assume) the drivers reads MSI/MSI-X values (thinking it sees values actually set in the HW) and then pass them to the device via some alternative means. IIUC this is what IMS does. I'm interested in two things: 1. Some plan for a long term solution - it was briefly discussed on XenDevel matrix room in September, Roger said: > urg, that's the spec that also defines IMS IIRC? I think the only way > to support anything like that is using vfio/mdev and re-using the > drivers from Linux. There's too much device-specific magic to > implement any of this in Xen, or do our own Xen-specific drivers. 2. A short term workaround for few specific devices. If you look at the linked threads, users resort to patching the domU driver and then copying MSI values from dom0's lspci output manually... I think we can do better than this short term, via some quirks in QEMU. Either let the domU see the real HW values, or translate IMS writes at QEMU level (assuming they can be identified). Disclaimer - I haven't looked yet at this specific driver, nor the SIOV/IMS spec, so I'm not sure if that's viable approach... [1] https://forum.qubes-os.org/t/solved-qualcomm-qcnfa765-ath11k-wcn6855-wi= fi-working-on-thinkpad-p14s-gen4-amd/38192 --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --NBzhMn7VFeiIx1Hq Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmlW+4wACgkQ24/THMrX 1ywQbAf/Rpii9AUUJGqZCu+T23c77jmTYIL0wp0V/o6DCSlGWAIn4ECJudQ4AGw8 tqn0LAQ/eSIrcPQLgybq5JoDQYmwaCbYMvaL1Uvrl4Ea9DmfCT3yJ2k8majjaeZH /DMo6nM477N02eULdUQi4Emfika4wbOIDDsZQAte7S0Zup1VBIWdO7rC2hmKmGF1 tQrrwxBoXwYRjA+5iH4S4SZeX9wJs7ehPcCIT+uz173opjrTPBUMNYfM7Nbl724f xamnTETpU82DNCCRd/q481HNlGiXWTr+JJh319tNBpENRQAyetI5sQOc5bcyTsS8 x2arJHrJKbF4MRDGs5kRAv6ky3+PSw== =Bnc3 -----END PGP SIGNATURE----- --NBzhMn7VFeiIx1Hq-- From xen-devel-bounces@lists.xenproject.org Fri Jan 02 01:02:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Jan 2026 01:02:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1194805.1512991 (Exim 4.92) (envelope-from ) id 1vbTYK-0001N7-GI; Fri, 02 Jan 2026 01:02:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1194805.1512991; Fri, 02 Jan 2026 01:02: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 1vbTYK-0001N0-D0; Fri, 02 Jan 2026 01:02:04 +0000 Received: by outflank-mailman (input) for mailman id 1194805; Fri, 02 Jan 2026 01:02: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 1vbTYI-0001MQ-7G for xen-devel@lists.xenproject.org; Fri, 02 Jan 2026 01:02:02 +0000 Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com [2607:f8b0:4864:20::112c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a2fafdd6-e776-11f0-9ccf-f158ae23cfc8; Fri, 02 Jan 2026 02:01:58 +0100 (CET) Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-787da30c50fso104535047b3.3 for ; Thu, 01 Jan 2026 17:01:58 -0800 (PST) Received: from [10.138.34.110] (h69-131-146-178.cncrtn.broadband.dynamic.tds.net. [69.131.146.178]) by smtp.gmail.com with ESMTPSA id 00721157ae682-78fb44f0dcdsm152117307b3.30.2026.01.01.17.01.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Jan 2026 17:01:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a2fafdd6-e776-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767315717; x=1767920517; 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=ltarQJfJ+LzqQBIQmaaL8RKQb1xGu7Kq2R9foeGM+T8=; b=XNJZkGTO0SFz+HaznnkoHJo4rI7UqzTW5oRx+9vtQd3Kizvqlt7GKm8TXLdUzps5p8 WNzq5L0aBk+OtRj2fZ44afVGVnzenn/wy0g2VQ2vQZbAJfM+iZQlsEjO6LVtD+8NxrUV rc3jKQ2To2zb93PricC02psUBIIl9rsdN227F9Vj4YwaO/vn7EzBUuOWjujqrTGBCvv2 D7A4hbSCo6PDWlfJytxkB4iVL2Jn9bWacvfHt4V51nsF4H3H0HGYgkyRtZgsIX8jxJOc QcwCo77b5HqhykyhMnfUq9nk5JBs/GRGsb5dcFrJQCHDiaTfpZLHA/AgFQPAM6/O21Xd b3pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767315717; x=1767920517; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ltarQJfJ+LzqQBIQmaaL8RKQb1xGu7Kq2R9foeGM+T8=; b=sbGlNKn0vIpcCZGGNepWecgvzFjpsws5MkvFm4u9S+kDEnxChQe8CdkXXe+7Qf4vXJ aANquPz4TcqwQXZIyAlTNXtRCiAYpvpietMrQCrp71K6ZR6Wa7sr/FEx/OQKhAAepdVw O+OJbfT+ZYv0WMjXWGEUDABzvwuDhha7zbwD5pfNrPJmZL/2bxSOzwXr8/QGO/zxfVSj AbcozKJ3u59FjuGyK5Aq+itVVydsPaYef0n+0lr2RJ+IqlFpjNXg3K17jO00EMPhuSu0 B5j+owafC8yvNUrrlv/XwRgAq30npxJpi5z2ToYCPV2/2ZhReeH7lnAztXFoQyk4uKx6 cH/A== X-Forwarded-Encrypted: i=1; AJvYcCXMTsPgVSMKjH3Drd1682t0GWdOhrU6yNnmK0FL3heGzJZ9jCi4Zm7d6sMhWt0xYrg9K7y0uGGKiuc=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxo/HjhWTQdnXXRj9YzGD14mnVeIYG0zEcU08tqg75niz65ejGG 30OKKkbf7XXFZISZ6enTsf4CkuCoGKLT04ou7VVEA0yCELZgnrMO+cdR X-Gm-Gg: AY/fxX4qqwY82Bk2wPTc1YvtLtbDbK6mkbooRAI4FGY4sjxBIW7fi+/n7CfhDZg0y0M 2wTd8fgX/BmpdHrfb3vcGTg/THIShIOBQZDbu76b1d8q++XTznJXtrbv3CLBBmJKCACrc8qpOH9 zpJfZAk0TGNMplF/xtU+2Xy/GSLHWKQ/YGqR6gO35Wt0UQyTl3LBxAFb0Uz6mMFDKL41OEREWud B3r1/IjxLA+VmVdRusFMy+XVy7RYasJgvlLty2o99xVUIMXqY+KyZKm0ckJtdPF+cMub7zNwl5P sKIHpT21uPXlf9HBbYLd+rQIhdHz+2m8o153w2PzbL+s1KdRG64dk84XhXUe9kp+BDQONhY6OB7 qfqrT4e/DFIGaPz08GTWc8pfaVIf2j78qPug9REwb/cPd05xtT7gKL/J/mKwCev8espIO1cmPRX kLcKuTc+pmzzhgjuQUEVw4V9j9sti4F0x7Oj5xJxSulisoBGfTLpBvA7lb+skQ4IOP7wnn8z2M7 yMVpNumpZsVffvOl80YrGoDttxESw== X-Google-Smtp-Source: AGHT+IFFKp60peUTFJl+0eBkTg4RNUtwwKDKGSxPzycLoKDLtrnIJjJHclgNZhaHGH63igTc6dLsNw== X-Received: by 2002:a05:690c:2601:b0:78c:697e:738 with SMTP id 00721157ae682-78fb3f37a5amr704332527b3.18.1767315716538; Thu, 01 Jan 2026 17:01:56 -0800 (PST) Message-ID: <3e802d7a-ab0c-4b9f-bebe-bb22bb1cf945@gmail.com> Date: Thu, 1 Jan 2026 20:01:51 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Dealing with SIOV/IMS To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , xen-devel Cc: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: Content-Language: en-US From: Demi Marie Obenour Autocrypt: addr=demiobenour@gmail.com; keydata= xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+ VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/ 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E +MYSfkEjBz0E8CLOcAw7JIwAaeBT In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Qu6fL30lE0gy9QR1Lv4ZdsET" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Qu6fL30lE0gy9QR1Lv4ZdsET Content-Type: multipart/mixed; boundary="------------cP3BctXuGBBpM5ri53ni8zAP"; protected-headers="v1" Message-ID: <3e802d7a-ab0c-4b9f-bebe-bb22bb1cf945@gmail.com> Date: Thu, 1 Jan 2026 20:01:51 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Dealing with SIOV/IMS To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , xen-devel Cc: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: Content-Language: en-US From: Demi Marie Obenour Autocrypt: addr=demiobenour@gmail.com; keydata= xsFNBFp+A0oBEADffj6anl9/BHhUSxGTICeVl2tob7hPDdhHNgPR4C8xlYt5q49yB+l2nipd aq+4Gk6FZfqC825TKl7eRpUjMriwle4r3R0ydSIGcy4M6eb0IcxmuPYfbWpr/si88QKgyGSV Z7GeNW1UnzTdhYHuFlk8dBSmB1fzhEYEk0RcJqg4AKoq6/3/UorR+FaSuVwT7rqzGrTlscnT DlPWgRzrQ3jssesI7sZLm82E3pJSgaUoCdCOlL7MMPCJwI8JpPlBedRpe9tfVyfu3euTPLPx wcV3L/cfWPGSL4PofBtB8NUU6QwYiQ9Hzx4xOyn67zW73/G0Q2vPPRst8LBDqlxLjbtx/WLR 6h3nBc3eyuZ+q62HS1pJ5EvUT1vjyJ1ySrqtUXWQ4XlZyoEFUfpJxJoN0A9HCxmHGVckzTRl 5FMWo8TCniHynNXsBtDQbabt7aNEOaAJdE7to0AH3T/Bvwzcp0ZJtBk0EM6YeMLtotUut7h2 Bkg1b//r6bTBswMBXVJ5H44Qf0+eKeUg7whSC9qpYOzzrm7+0r9F5u3qF8ZTx55TJc2g656C 9a1P1MYVysLvkLvS4H+crmxA/i08Tc1h+x9RRvqba4lSzZ6/Tmt60DPM5Sc4R0nSm9BBff0N m0bSNRS8InXdO1Aq3362QKX2NOwcL5YaStwODNyZUqF7izjK4QARAQABzTxEZW1pIE1hcmll IE9iZW5vdXIgKGxvdmVyIG9mIGNvZGluZykgPGRlbWlvYmVub3VyQGdtYWlsLmNvbT7CwXgE EwECACIFAlp+A0oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJELKItV//nCLBhr8Q AK/xrb4wyi71xII2hkFBpT59ObLN+32FQT7R3lbZRjVFjc6yMUjOb1H/hJVxx+yo5gsSj5LS 9AwggioUSrcUKldfA/PKKai2mzTlUDxTcF3vKx6iMXKA6AqwAw4B57ZEJoMM6egm57TV19kz PMc879NV2nc6+elaKl+/kbVeD3qvBuEwsTe2Do3HAAdrfUG/j9erwIk6gha/Hp9yZlCnPTX+ VK+xifQqt8RtMqS5R/S8z0msJMI/ajNU03kFjOpqrYziv6OZLJ5cuKb3bZU5aoaRQRDzkFIR 6aqtFLTohTo20QywXwRa39uFaOT/0YMpNyel0kdOszFOykTEGI2u+kja35g9TkH90kkBTG+a EWttIht0Hy6YFmwjcAxisSakBuHnHuMSOiyRQLu43ej2+mDWgItLZ48Mu0C3IG1seeQDjEYP tqvyZ6bGkf2Vj+L6wLoLLIhRZxQOedqArIk/Sb2SzQYuxN44IDRt+3ZcDqsPppoKcxSyd1Ny 2tpvjYJXlfKmOYLhTWs8nwlAlSHX/c/jz/ywwf7eSvGknToo1Y0VpRtoxMaKW1nvH0OeCSVJ itfRP7YbiRVc2aNqWPCSgtqHAuVraBRbAFLKh9d2rKFB3BmynTUpc1BQLJP8+D5oNyb8Ts4x Xd3iV/uD8JLGJfYZIR7oGWFLP4uZ3tkneDfYzsFNBFp+A0oBEAC9ynZI9LU+uJkMeEJeJyQ/ 8VFkCJQPQZEsIGzOTlPnwvVna0AS86n2Z+rK7R/usYs5iJCZ55/JISWd8xD57ue0eB47bcJv VqGlObI2DEG8TwaW0O0duRhDgzMEL4t1KdRAepIESBEA/iPpI4gfUbVEIEQuqdqQyO4GAe+M kD0Hy5JH/0qgFmbaSegNTdQg5iqYjRZ3ttiswalql1/iSyv1WYeC1OAs+2BLOAT2NEggSiVO txEfgewsQtCWi8H1SoirakIfo45Hz0tk/Ad9ZWh2PvOGt97Ka85o4TLJxgJJqGEnqcFUZnJJ riwoaRIS8N2C8/nEM53jb1sH0gYddMU3QxY7dYNLIUrRKQeNkF30dK7V6JRH7pleRlf+wQcN fRAIUrNlatj9TxwivQrKnC9aIFFHEy/0mAgtrQShcMRmMgVlRoOA5B8RTulRLCmkafvwuhs6 dCxN0GNAORIVVFxjx9Vn7OqYPgwiofZ6SbEl0hgPyWBQvE85klFLZLoj7p+joDY1XNQztmfA rnJ9x+YV4igjWImINAZSlmEcYtd+xy3Li/8oeYDAqrsnrOjb+WvGhCykJk4urBog2LNtcyCj kTs7F+WeXGUo0NDhbd3Z6AyFfqeF7uJ3D5hlpX2nI9no/ugPrrTVoVZAgrrnNz0iZG2DVx46 x913pVKHl5mlYQARAQABwsFfBBgBAgAJBQJafgNKAhsMAAoJELKItV//nCLBwNIP/AiIHE8b oIqReFQyaMzxq6lE4YZCZNj65B/nkDOvodSiwfwjjVVE2V3iEzxMHbgyTCGA67+Bo/d5aQGj gn0TPtsGzelyQHipaUzEyrsceUGWYoKXYyVWKEfyh0cDfnd9diAm3VeNqchtcMpoehETH8fr RHnJdBcjf112PzQSdKC6kqU0Q196c4Vp5HDOQfNiDnTf7gZSj0BraHOByy9LEDCLhQiCmr+2 E0rW4tBtDAn2HkT9uf32ZGqJCn1O+2uVfFhGu6vPE5qkqrbSE8TG+03H8ecU2q50zgHWPdHM OBvy3EhzfAh2VmOSTcRK+tSUe/u3wdLRDPwv/DTzGI36Kgky9MsDC5gpIwNbOJP2G/q1wT1o Gkw4IXfWv2ufWiXqJ+k7HEi2N1sree7Dy9KBCqb+ca1vFhYPDJfhP75I/VnzHVssZ/rYZ9+5 1yDoUABoNdJNSGUYl+Yh9Pw9pE3Kt4EFzUlFZWbE4xKL/NPno+z4J9aWemLLszcYz/u3XnbO vUSQHSrmfOzX3cV4yfmjM5lewgSstoxGyTx2M8enslgdXhPthZlDnTnOT+C+OTsh8+m5tos8 HQjaPM01MKBiAqdPgksm1wu2DrrwUi6ChRVTUBcj6+/9IJ81H2P2gJk3Ls3AVIxIffLoY34E +MYSfkEjBz0E8CLOcAw7JIwAaeBT In-Reply-To: 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= --------------cP3BctXuGBBpM5ri53ni8zAP Content-Type: multipart/mixed; boundary="------------257C6UYihX53qXyQM3BkQaaV" --------------257C6UYihX53qXyQM3BkQaaV Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 1/1/26 17:56, Marek Marczykowski-G=C3=B3recki wrote: > Hi, >=20 > I've got yet another report[1] of device failing because (I assume) the= > drivers reads MSI/MSI-X values (thinking it sees values actually set in= > the HW) and then pass them to the device via some alternative means. > IIUC this is what IMS does. >=20 > I'm interested in two things: > 1. Some plan for a long term solution - it was briefly discussed on > XenDevel matrix room in September, Roger said: >=20 >> urg, that's the spec that also defines IMS IIRC? I think the only way= >> to support anything like that is using vfio/mdev and re-using the >> drivers from Linux. There's too much device-specific magic to >> implement any of this in Xen, or do our own Xen-specific drivers. >=20 > 2. A short term workaround for few specific devices. If you look at the= > linked threads, users resort to patching the domU driver and then > copying MSI values from dom0's lspci output manually... I think we can > do better than this short term, via some quirks in QEMU. Either let the= > domU see the real HW values, or translate IMS writes at QEMU level > (assuming they can be identified). Disclaimer - I haven't looked yet at= > this specific driver, nor the SIOV/IMS spec, so I'm not sure if that's > viable approach... >=20 > [1] https://forum.qubes-os.org/t/solved-qualcomm-qcnfa765-ath11k-wcn685= 5-wifi-working-on-thinkpad-p14s-gen4-amd/38192 Disclaimer: I have not read the Intel or AMD IOMMU specs, do not have access to the PCI spec, and know very little about ath11k. All of this is based on various mailing list threads and Matrix messages. It might be wrong. Please correct me if it is. First, a background on IMS. All of this comes from [2] and its thread. IMS is a result of wanting to store interrupts in host memory. This avoids needing to have them in expensive on-die SRAM or including DRAM in the card. However, on-die SRAM is used to cached the interrupts. This means that interrupts must be managed via command queues. This causes problems for Linux and for any other OS that expects to be able to change IRQs without a command/response operation. The only workarounds I saw in that thread are: 1. Redesign the OS so it never needs to change interrupts from a context where device commands are impossible. 2. Modify the command queue code so it can run in interrupt context. 3. Rely on the IOMMU to remap interrupts. ath10k and friends use an even worse hack, which is to pin everything to a fixed CPU so that the problems mentioned above (which relate to moving interrupts between CPUs) don't arise. Now, the part that is relevant to Xen: IMS *also* causes problems for hypervisors. Hypervisors present guests with a virtualized MSI range rather than exposing the actual one. My understanding is that virtualization serves two purposes: 4. It turns non-remappable MSIs into remappable ones, so that they are translated by the IOMMU instead of being rejected. 5. It fixes some information in the MSI (target CPU?) so that the interrupt correctly reaches the guest. With IMS, virtualizing the guest's interrupts is no longer possible. That would require virtualizing the command queues, which are device-specific and in any case (probably) too complex for the hypervsior to handle. The only way I know of to make IMS work under Xen is option (3) above: give the guest access to the real MSI configuration space, and rely on the IOMMU to translate the guest's interrupts to whatever it needs. This is possible on AMD but not on Intel. See [4] and the related Matrix messages. For Intel, the only solution I know of is to patch ath11k and friends to get the real interrupt from Xen and/or QEMU so they can program the hardware accordingly. This will require a driver patch. I *think* ath11k and friends are the only IMS devices consumers are likely to run into. I suspect the others are likely enterprise devices with VFIO/MDEV support. Supporting all devices could be done via a paravirtualized interface, perhaps as part of paravirtualized IOMMU support. On Intel, the IOMMU must play a role in MSI assignment anyway, so a PV IOMMU could coordinate with a hypervisor to avoid this kind of problem. A lot of this information is taken from the thread in [3]. [2]: https://lore.kernel.org/lkml/20200821201705.GA2811871@nvidia.com/ [3]: https://lore.kernel.org/xen-devel/20250226211125.43625-1-jason.andry= uk@amd.com/t/#m590f8a0de6fecde893345a6836828dc84eaccd5d [4]: https://matrix.to/#/!XcEgmbCouiNWHlGdHk:matrix.org/$laXuwPmDLINXAYnw= oDsVCUvByPS6-5IjB_1OCAl9zgQ --=20 Sincerely, Demi Marie Obenour (she/her/hers) --------------257C6UYihX53qXyQM3BkQaaV 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----- --------------257C6UYihX53qXyQM3BkQaaV-- --------------cP3BctXuGBBpM5ri53ni8zAP-- --------------Qu6fL30lE0gy9QR1Lv4ZdsET 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/sszaHOrMp8lMFAmlXGQAACgkQszaHOrMp 8lNlYw//XJX+4syYvp3y9QSOoP9PCYr5KyUt1BCnvJHvMv0gStoAFAAVW6oVfYYa /5MpeWKcTfQ27Lgj6yYW3SXmxY+4D6ReltBXXs2qmjbq1c4zveBps+91d/UhIivK uefXJdIWl0cNRNwNRDNb9g+OmKYzkXBnXWN3KBVxsfl2p80RjM5kNACwLUjU97Ee ct/vPrfS9nIHH1H4q9qS+K9o/o9HPfRvx/Pnq7UXdqZI0rpdaj24le4T4V9mQM8X J9/7AVhwD3Pfgq0cItnI9+ne4g4kaCST4504u8pA/ZLb73cP9MxHoSI07PBKF1aO EPwlNKBBzobtkKW9t/s6QrTxM6IG+LHUUNsp07RXp2ct9swOR0f15F6s2fJr4SS6 4wX036/SOWEap+EDedacieyxbm/nGmLD6YpRsLPl4PRQsA4iQ1TPbX5lLq6DFHTt 56Vp8wP9tU7hcJJ7iiyNWAqQNd2CfTFHkLv8KC3cSOxbvJedgPgAOwJL4bYbBzD2 Lfg0G2lorHFhfURdSp61qbYs79pJWYLOT7X8gSiFT+m/BRNH6h/0GwHk6kRRqO4f caHsRDeKf0+PiL1cPB9FMLM/4etuEkGZcZM4ImxU9TbnID7/YeL7vCy34VMG/9Jw 4TtyEypWQVjzMoolsB75ELPbw3W+hve/A7SOoYlMwnHWsNRTf9w= =xbHK -----END PGP SIGNATURE----- --------------Qu6fL30lE0gy9QR1Lv4ZdsET-- From xen-devel-bounces@lists.xenproject.org Fri Jan 02 01:23:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Jan 2026 01:23:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1194819.1513001 (Exim 4.92) (envelope-from ) id 1vbTsV-0004GZ-81; Fri, 02 Jan 2026 01:22:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1194819.1513001; Fri, 02 Jan 2026 01:22:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vbTsV-0004GS-4I; Fri, 02 Jan 2026 01:22:55 +0000 Received: by outflank-mailman (input) for mailman id 1194819; Fri, 02 Jan 2026 01:22:53 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vbTsT-0004GM-NT for xen-devel@lists.xenproject.org; Fri, 02 Jan 2026 01:22:53 +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 8e15b53e-e779-11f0-b15e-2bf370ae4941; Fri, 02 Jan 2026 02:22:51 +0100 (CET) Received: from IA1PR03MB8288.namprd03.prod.outlook.com (2603:10b6:208:59e::6) by MN2PR03MB5181.namprd03.prod.outlook.com (2603:10b6:208:1e5::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Fri, 2 Jan 2026 01:22:49 +0000 Received: from IA1PR03MB8288.namprd03.prod.outlook.com ([fe80::4af0:a6d4:e568:ac0e]) by IA1PR03MB8288.namprd03.prod.outlook.com ([fe80::4af0:a6d4:e568:ac0e%6]) with mapi id 15.20.9478.004; Fri, 2 Jan 2026 01:22:49 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8e15b53e-e779-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jRn9y3e6Wmg12TXb80tJhBzlGfFrhOivFObkG7ebuXJzJDjtfMV0SxOFyV9WAqqtkxVDryUn1pUT6QM3dRjiZoglLGE36CUQuagyRw4iKDCXf1FXcfqf17/xwgBoyJ+b7xpTzuah/qWAsP5REuqSlT071DyvpOyQa3aJ95o8w6XF0flh3qAR5+JNSzy7R0WswUpsuFJKcpnsUc6dM95ihL5WDU8I97/AMFU7dU/e8hyKMxEH+SHyRwNTUhKRbFqEsw7npPR3Aa0EKQKQcymc3xEdxL31+ZRC+qlxOOjX3fzZEPnNuS9jjisSENosH4yX+vzWg3ozGsPyVzz5N/mIxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fpWFgV4moOBcRVk1A5juyp7Uf0nwRfe4k547PPJBQZE=; b=kw0Ms+vyrC67hzsMakGvm8GauFTCPKY8YiFcflRJtNAulxi/KahY5fn+DV8GxyElQRag+94W8KQxBfWFKUqmH9Yxm0PrQMhLGQKeRlcyzxyWPeqO+6NesKbEcM4qc+TRmsZWsU3l3izVKP0sYfapQt8xpyGU4psIZlsK7YCBp3oAED34JJXR7TLv5351dqucjv+3SnzLNnYP4EnUyk26kHCt9lmOrHCbJ+zU7LixzB8EXlyGHi2FlmlgIDD4jHXWlkvnhOIUXGn+T0+Yw9DfuljdmXQyVnK97BC6QEwVQhcRNSCq+VfIM2S5BMazNX6vWKQO5g/wFa5ovFz0UGeOEw== 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=fpWFgV4moOBcRVk1A5juyp7Uf0nwRfe4k547PPJBQZE=; b=lAQy2B46oxVLvcijUBTLJyIegJWwK6Itg3b1BItK3rd09SS/XTLsaqfS/YKJ99JVvlIbdXq5n9xEZqgjWjs9AQcZSn/dWItfkWn5QO6IUBLOXS6SDjBDYYdBRgZLKZ5eVzO8AGiDWwff5k2mEWyiJ0R8i2q3tvo8/g0iBJoDR0Y= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <90681969-e7c1-40ce-88c9-a5639865c93c@citrix.com> Date: Fri, 2 Jan 2026 01:22:32 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: Dealing with SIOV/IMS To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , xen-devel References: Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0296.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:38f::10) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: IA1PR03MB8288:EE_|MN2PR03MB5181:EE_ X-MS-Office365-Filtering-Correlation-Id: dd9e081c-a010-4247-4d8b-08de499d6b36 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?K2ZqQm5GMk5uV2pHbEoxMlZ5ZVhMVjVLQmVjRDdzeEUyVDVFTVRZOGc1bEsx?= =?utf-8?B?azNaYXNzYXA0cEkrOHp0enVrck13cUQ3R0ZJS1NPOXEzV1JxZTVLSGRpMitM?= =?utf-8?B?d2o2S2VYY0FyY0NXYm1ucW8xaXQyRUFpbko1YWlTc1Y3TkpsOXR2MEFoT2N2?= =?utf-8?B?QmFhU0Z0c0VBMUVLMXRtYkt4NTZEYnBLVHZuTTcxK2JsT1JXdkxXeVdGdlpD?= =?utf-8?B?WGd1RG9FV0VwMDVHL21TaGJwZWg0SkZOYUkxd2YzaGJMQUQ1MXlCN1pEemR4?= =?utf-8?B?UTB6aUxXb1JZZDZNa2xxZWVyYUxqaUgwK3VtMjl2Y21JWllJSmlLZ3pJbjlq?= =?utf-8?B?eG5qeFVkaUJLNytteW40aWZTUmYwZ2NrQUZDbTBBNDRBMjRMUERyMjJkREdz?= =?utf-8?B?bTNXSC9sNUtnWXFlNVlxcFJzWmh3ckU4WW1ZU3p2eHRJWi9GU1Z0dDN5RG16?= =?utf-8?B?dHFheHpuSFA1azYwVEVqRXF1cllyN296NFI0RVF1S2FBYjlyZGwrUjF5QXlE?= =?utf-8?B?Nk96cksybEx0WUhWK0tOVEkxYU9wb0phV0N4K1NoWFE3LzJ4S0pKU2RiYVV5?= =?utf-8?B?bXBEc3VqU1JpOUFNc2NNNzE5ejdDRkVIZEZ0enNMUG9YaXkxSUhWTzdoZUIx?= =?utf-8?B?aElUYW4vanY3dEp5elVVeTlqelFMczgzS3dVeHdmQzFLODZiUEJPeHFpYk1s?= =?utf-8?B?SERjZmNQVkFXRm1BaS8rVzhpWi9uQnJsTEptdHMwZ2NqNk52ejRneURSc3Ra?= =?utf-8?B?VWY3OXhvZU9HMCtkZUlWVFJTL2tBSnkzZXRhVVV0eHpxMVZjTUVkakNEQXBT?= =?utf-8?B?MllSeGRNMHZaMkhzOEY4b2dIWHFBMlFYN1BDaFIrMjRwOEJFQ0hiRmFGcERn?= =?utf-8?B?MEpaNTdiWWhBRlRKQ09wc0RqY200Z1RaeE1kdXRZQUN4WEdZVmJJU1kxcVNa?= =?utf-8?B?cEZDazd4dzBzckZhaWhSZlgvYktxV25UUGF4ZTNYVEkxVWt4bEtBT1RVVTBQ?= =?utf-8?B?RCsrUU4zRFdGK3ZCajFCeE5hYXlCVUJVMzkzZ1hSeVZ2MEozK3l6MGZKQkl1?= =?utf-8?B?YTNHVk52L3F0RGpYMThnTnZEbmJtMkJtQlVTOFJhclFpb3NtL09scHQ0VUVi?= =?utf-8?B?OERVQlJlU3k1ZmRRV1U3a0VoYy94WUZ5ZVJ4aEpHcms2c1NjVy96Y3ZrcDJB?= =?utf-8?B?dFB6R200emorUkNOTkhwdGR5dUdjSjdIRGlWV0ZUeUJkRGVSYXdYbTYwRGJ3?= =?utf-8?B?SERKZzFZNG93RlhxdjZBQ3NVeVY1RUNtbDU2SkE0L085Z2w2NFM0c1NGdDlK?= =?utf-8?B?ek9TdS9UbjVLYUY2ZGdpdStBUG1SY2ZlMktFKzZNMmRVMFZFL0o5TnBlRm1M?= =?utf-8?B?YTlRMWE0UzJHWmZyL3VDTGNyNEpaU09TdHR6S2dtSHIzY1E3Q0lQbHJmS2tS?= =?utf-8?B?ZUh1OWtFbFhVSk13bE5VUkhuYlhxR3FuOVA4bVRiQ0JhOFdPR1JkajVQaU9D?= =?utf-8?B?UFlnYWJZVUd5SGpEazJNeVIyamppV0lpblF0R2RwMkRvMzBMN3NFS3hQQVJG?= =?utf-8?B?Sy9SakRDUk53N3BDbmtlMnhONXpRQ2pNZ1lFT0xJVUR6U0ZPejZsb05DVEhw?= =?utf-8?B?dnY2SmpYZXBWUEEvWmN0SVRwaEtSbjE3ak5ET0tHc0loS2NlWWwycFFJT1B3?= =?utf-8?B?TW1aa2lUSElsUUxkNW9uMVhJUG0wcjZFc3BpZlAvRlU5NUlnZEcxZWVmdVZH?= =?utf-8?B?Rk5aV29MNTlJNzBKKzMxWk50Z1liYkJLSGpML0VMckR5Qk9qUWgrSWdYWUVo?= =?utf-8?B?a2ZEZkkyYUxiQy8yQXdnL3E1Vm5VcEh5eURFRUhkVzdaRWFKTDdmVVFEdjNF?= =?utf-8?B?aFhFVVVZRWNPSkJDTEFrelBGbEVaZGZkeGNuLzlzQlUzVmVldUdUS2xsMnlZ?= =?utf-8?Q?THYFUnRjAZr1lBkINUPzEx1CNLRw8bje?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA1PR03MB8288.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UHJZSTAyWFhaV2ZlVVRnT1d2dUhQOXNjQy8zM0ZzdlJwSGhUalF3L3d0c2ho?= =?utf-8?B?UXN4UGl1WUt5OFlWYStoRTFXbnhrak9wQVlUZ2ZiVEFudVhPNGl6TDBNYTVQ?= =?utf-8?B?MjhhRjQvWVhTbDh2NTVLU0lOak8zczl3NkV2a3FwSzBPdG81blJtQVkwNUxF?= =?utf-8?B?RUp0QWk1UnRpQldlYWtEanl5cGVqbUFISVBQdWVtdVVlSDJ0TnVQa2xNcmdi?= =?utf-8?B?cXBTcTFOUmhTbWRVSzEreWx0U08vRmxtbWxsd3gwRUFiZXJwREV5NXYrTnRB?= =?utf-8?B?elVNVE9mZGtJZlZoQmJybnlKWkwxeWpWSXByZjIyVDFYeFVnV1FGempveklr?= =?utf-8?B?bDBhT2hBK3hENlJrcGcrYnBCUVZPdCtsV2JTSEoxd2NMT3JJYTd0RjJEL0Y4?= =?utf-8?B?T01WOG1hMjFWdlluTGVRdG45elBkZUIwZ3JuUVB2NkxRakpWYWZHa0d6L216?= =?utf-8?B?cDVFVjM0eW5tVnpoa1dxZWJtdnJnRkxaWmlmNGVNR2lXcjJId3RkRHVSMUFN?= =?utf-8?B?N3pIY3paQlluQS9CYnBQb0RJamZXaWppS0hBOHQ1OVd5RlJxM01zVzNLU3pO?= =?utf-8?B?RWdxN2JkVjBxeFN4MG02bFVsd2dBejhPM2czK205RmpvUXZzcWp3K3pLRnVy?= =?utf-8?B?K3A4Yk9FejU4bU1xTmpEM1ZuaGdjRVcvK2VjMXM1M3BFOTREV1pHYXkrakU2?= =?utf-8?B?ZTJJcGpSOGl6eXZuVVZ6Tk1iYmZNdXVkMWVrSHNBQU5YNUttRHZGZFBiWWp5?= =?utf-8?B?dWMvd0ZmWXBESitjQlNlUEJVZE1zSjloWGFQUzNpM1U0Nk9scGhaWTJRK2F1?= =?utf-8?B?eGE2U1dRMGc3S3dpaW9MRHJFcUF2TnBSdHdGaXZmNGdWTnZvQWZ2UDBHeFF6?= =?utf-8?B?K1JOZEw3WFhLN0FiL3hBeXd4QlJQZ05MY2xQU3VteWVsYnBuMWRvOUI2OG01?= =?utf-8?B?OHBjVEpVY0xkZDZTSlJGa1l4QzZNUUE3bEtZVDFWK29mR05odlUrWmxNQlN5?= =?utf-8?B?VUowQ0R2M3RETFp4RmxFRm9xSFBTWXI5L09HQVFUa1pjMFRVZlpndGwwcitX?= =?utf-8?B?S3VneExtSnNZYkhKMG41ZE0vd2xhOGFwcVNkb0E3bkFnbUlJdVo3dklBNDJi?= =?utf-8?B?SXJMdWlURE04QnVKWEtuQUNhOXJycGFjZ0EzOVEyM1gva1ZSWVFoVWIzY1Mw?= =?utf-8?B?YUVDeXZmci95eDhpNWY1LzF3eGFDNWJjdUJmTzJhMVRoenNjKzV2Z2h2ZXUx?= =?utf-8?B?NlV4SFhXc1VuTE0yMm81T2x6bnRSby91RXFsMFNwbFZTT0ozai9sWWtLY0RF?= =?utf-8?B?ektsS1RIMnd5bldRTFpUTExFSW9xUkZJa1lNWkowTkxFamFoSlJibEFVcTl5?= =?utf-8?B?SWxTdHI3QTJ3VUR0YU1uTVdNQmtDcU5QZEJiQkxabGJuZEZSa0JWZVEyZ3kr?= =?utf-8?B?SVprV0I2WlpuTjhvcmZTMXMrU1dURU5JZVRRTmF6ZUxyMWdPRzJlZHVsVGQ1?= =?utf-8?B?bm9kU3RGd09EQ3F3TTNMOEZNSGVJY3pOL21tOHdlUzFxakwzUmJ4aElZRHRx?= =?utf-8?B?aUdxKzVYTXFKajdQUkhrV0h3NzFZMmpoUTUrTkhseGVRN2VVMFRVWkF3cStt?= =?utf-8?B?cGhJUFJUSXJ3VW05L1pSRlprTXhBRGMwVExsb0RMZVg5RDVVOWkzMm5KUTdQ?= =?utf-8?B?OHNubGFzZ0lXWmJJS2RYbkJpQnFKSXlOeml0YURqUTNWcjJ0YjJSY2xHQkor?= =?utf-8?B?d3pGSEpCd2VCSFUzRUhFc29oWFlSODNrWjRBK0wvQUhvUEpyN2N0Z2F6b0NB?= =?utf-8?B?WmF4cTJoL2pSbVhRYUtFKzRKNmJNdFFHMnp2WWtoeUZoSFhCRFdIbWFqNnpN?= =?utf-8?B?cGxqY29Sc0U1U1hOTDA5NktCYXFBR0NPcjF4b2xEbzYvSDM2aWZhdElxNWoz?= =?utf-8?B?ckpGU3hXS3ZMYkwycHVZeWpOOHRNYVNnRzhLRURCSGhKUWdFaHp3bW1CcFA4?= =?utf-8?B?cDJhSTNFUjdHeVRzbGx6SU5qWllPM01CWmM4YXcxdGVqdTZmVDVPMFJ2dmpi?= =?utf-8?B?bEx4L0V6NGhsSjZHR1BGTDROS1EyTDBGbjlKZU1pYmxKdmFPa1dTUmM1bW9l?= =?utf-8?B?MEhPdUZkWU55dW5vVjduSnVxeW40OXpKaEtEakVXQjFEWHhNNzdyWGRDNFo2?= =?utf-8?B?RlhBYnNCdDdIanFiZW1qVmRBeUYwMlNYcHdOSmYzK1VWQ21kRFNtVjlJQXIr?= =?utf-8?B?WUVnS09sZjFEZ0ZEWmFsLy9tZE9hYzNsWWxnalVqVlIzR2pxV1VyZlRpQ1l5?= =?utf-8?B?NStDRHdKd3hIRCtEMHpxQTdtT2c0RVVXNVM5OFFJbjJpSVRWbmg5dz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: dd9e081c-a010-4247-4d8b-08de499d6b36 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jan 2026 01:22:49.3928 (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: mJoLYbTiq3eNZuFBqZ8KUxpnCaKLd/SunjeNd/ndNbv5hTo9/v3qcGQRJOp/i3XK9gdifVf66JwfxESc5IQdIO/XY64uPRPE9r4ja2Dp2rQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR03MB5181 On 01/01/2026 10:56 pm, Marek Marczykowski-Górecki wrote: > Hi, > > I've got yet another report[1] of device failing because (I assume) the > drivers reads MSI/MSI-X values (thinking it sees values actually set in > the HW) and then pass them to the device via some alternative means. Ath11k is known broken in this regard.  It doesn't even work on native systems.  (It only works in Linux by dropping to a single interrupt and tying it to CPU 0). But, my understand is that this is specific to Ath11k and not to do with IMS. > IIUC this is what IMS does. Not really.  IMS moves the MSI-X table out of a BAR and into host memory. It was a short-sighted design which is very hard for native to use and impossible for virt to use. AIUI, IMS has been abandoned as a technology, so I think we can simply ignore it. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jan 02 03:53:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Jan 2026 03:53:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1194831.1513011 (Exim 4.92) (envelope-from ) id 1vbWDd-0005C9-HC; Fri, 02 Jan 2026 03:52:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1194831.1513011; Fri, 02 Jan 2026 03:52:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vbWDd-0005C2-E5; Fri, 02 Jan 2026 03:52:53 +0000 Received: by outflank-mailman (input) for mailman id 1194831; Fri, 02 Jan 2026 03:52:51 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vbWDb-0005Bv-N4 for xen-devel@lists.xenproject.org; Fri, 02 Jan 2026 03:52:51 +0000 Received: from mail-yx1-xb12f.google.com (mail-yx1-xb12f.google.com [2607:f8b0:4864:20::b12f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 81516f28-e78e-11f0-b15e-2bf370ae4941; Fri, 02 Jan 2026 04:52:49 +0100 (CET) Received: by mail-yx1-xb12f.google.com with SMTP id 956f58d0204a3-646b8d2431dso3129986d50.2 for ; Thu, 01 Jan 2026 19:52:49 -0800 (PST) Received: from [10.138.34.110] (h69-131-146-178.cncrtn.broadband.dynamic.tds.net. [69.131.146.178]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-6466a8bd6ffsm19553704d50.9.2026.01.01.19.52.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Jan 2026 19:52:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 81516f28-e78e-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767325968; x=1767930768; 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=5byPbifVZYEfUQt6d4q9JK0TnJf7xI/JALrPGKBl0Og=; b=GeEc/yIvR7As0MTOVn/Eyt3EAdD/+3+iqa95gA20ZcRUPMw4OBerdpLIWSpiVa/fab wFFiS2SuHaeGAVb00Eb/W5FoBmAKYBq+VrSDVnqCUFpZmOIq4zvHPj9R0KDgpcAto3eQ +M+LUuiQ++4MCRx6IqEQB4xawZDMKxUoSicwElWlqecLlxPOZ1OAd3gQfEmiQ/nhr8HD db0Necfqz9iCTcZRJ3tXdTTcDXlvV2CJGXacXT4dk6eWBbx0AOJDtQOncL6wnwHInBSo HaAAcMIlLY3MF3I6eFhM1Bs2whdI89MfjMqsC1L/td/RWl4wf8OpHzIwqSddB3Kg8eiy Vs0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767325968; x=1767930768; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5byPbifVZYEfUQt6d4q9JK0TnJf7xI/JALrPGKBl0Og=; b=A8YoGwN37LB+iO/vcLROxoWMW5P1fvfBTS5oWnd5aE/rjU+WT7A9YhRpXtKNQYQwEe D1omjQlkFZx7vm9JPg7VYqGdSMZoCtCmWiurhFYNcepFVvxnknsY+t/5+V0qw3uvs/ck d4Hp8QUVH/qFD0Nko9KISk6c3CaBERlb1VfY3qz3+OMPqizso3x2ardYkdFjAbfQr5NR Es5TKoNFhbwPf+Uv6XGyHJPkxszLSLsHnIDXkQbafaQ9RBAMxdad1AR8WR7pmLGPHvDE lOOW4sN8KCKd8iQBpq9Z43a3k6j87ZWyYv9lIijytDsPhYDx4mqoOO+k6e2msWZETHW8 6ulw== X-Forwarded-Encrypted: i=1; AJvYcCWWJOqD15mxXd86oI57rddWZeFvHj+23EIZhSYIKv+BIrIAajViaKZgZJHfPaRf2I7ghJf29+dYHTA=@lists.xenproject.org X-Gm-Message-State: AOJu0YyaCgyx5jg9k1g1prw3XfTpCP1jOuFAeddHm0Jy2gFDqlY2w5jv ExM2fKH8QA8g3RE9GkCJtFc5suO+gK5+2rmdnnz1wIetZF1+fYAWm2ZR X-Gm-Gg: AY/fxX7E1rcd6FFnaNoZQEqaZsdEAUvoWZAwyty1fnkUg5k4DFrWxomKf23W0sfq5k1 13aBeIX+KKv6OeQ086k6Zkc8cXFZusfns8ac4Q2ccVIQYnhSH9shEZ00MzPcEVh45Zkyy/CRSFi 61+3yqr+dtkP6MIggX6ano2U8Uo6H8QCZzQUBTjOhf6Zwhndhzpvlo5tXxSzdTAnaLfVx61VMRE O7b4BuiuAqnGwcgQUIWsDcp1kU2HqcNmE2ct+RgH4eKybDIHXtvXN7MBglpmhYSAJG6vE0fb6HM 1rPcDxW3xwLi+uktUWV8qoJxreruINVrVSxYZPa0dF+udqADs5um2uP7TGqfppsLzDf89d6ch0T PsQyOvShp2fdyxd3PPQs0eqv0XWygKIq8btvSmmNCGr1UC9mKM1Zitgl1DZKSb485oA7gtzCeNH 0ugj/H/aFuHk6ExzOlBfdoYhdqPTitbquAQ+dUPdMzMAAQsqJLDdc+Js61FjnPUFvHxDSxOkjXd IlqAD+eAuMHPhqnP0fe/cD8jjrjlg== X-Google-Smtp-Source: AGHT+IFEXZmhL5sdauifnLvGekhcTJUaTkbMqGYV3udiINV/4LUn12cBkEkIUa2c3Dcppw1V3LCEJQ== X-Received: by 2002:a53:dd45:0:b0:644:7919:52d with SMTP id 956f58d0204a3-6466a8bd63emr24323687d50.65.1767325968321; Thu, 01 Jan 2026 19:52:48 -0800 (PST) Message-ID: Date: Thu, 1 Jan 2026 22:52:41 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Dealing with SIOV/IMS To: Andrew Cooper , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , xen-devel Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <90681969-e7c1-40ce-88c9-a5639865c93c@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: <90681969-e7c1-40ce-88c9-a5639865c93c@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------ICSh5EEKvjL0iNYwPWwjs0GH" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------ICSh5EEKvjL0iNYwPWwjs0GH Content-Type: multipart/mixed; boundary="------------J587ffhWwcDzZ5cL2z8slbOm"; protected-headers="v1" Message-ID: Date: Thu, 1 Jan 2026 22:52:41 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Dealing with SIOV/IMS To: Andrew Cooper , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , xen-devel Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <90681969-e7c1-40ce-88c9-a5639865c93c@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: <90681969-e7c1-40ce-88c9-a5639865c93c@citrix.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= --------------J587ffhWwcDzZ5cL2z8slbOm Content-Type: multipart/mixed; boundary="------------YV0D8oOaPhdnxUsvgAHrnhcA" --------------YV0D8oOaPhdnxUsvgAHrnhcA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 1/1/26 20:22, Andrew Cooper wrote: > On 01/01/2026 10:56 pm, Marek Marczykowski-G=C3=B3recki wrote: >> Hi, >> >> I've got yet another report[1] of device failing because (I assume) th= e >> drivers reads MSI/MSI-X values (thinking it sees values actually set i= n >> the HW) and then pass them to the device via some alternative means. >=20 > Ath11k is known broken in this regard.=C2=A0 It doesn't even work on na= tive > systems.=C2=A0 (It only works in Linux by dropping to a single interrup= t and > tying it to CPU 0). I wonder what it does on Windows. Does Windows play nice with IMS? > But, my understand is that this is specific to Ath11k and not to do wit= h > IMS. Does that mean that an ath11k-specific hack in QEMU might be an option? >> IIUC this is what IMS does. >=20 > Not really.=C2=A0 IMS moves the MSI-X table out of a BAR and into host = memory. >=20 > It was a short-sighted design which is very hard for native to use and > impossible for virt to use. >=20 > AIUI, IMS has been abandoned as a technology, so I think we can simply > ignore it. --=20 Sincerely, Demi Marie Obenour (she/her/hers) --------------YV0D8oOaPhdnxUsvgAHrnhcA 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----- --------------YV0D8oOaPhdnxUsvgAHrnhcA-- --------------J587ffhWwcDzZ5cL2z8slbOm-- --------------ICSh5EEKvjL0iNYwPWwjs0GH 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/sszaHOrMp8lMFAmlXQQoACgkQszaHOrMp 8lM3vxAAjWzqbEGoCvUP65i2IYQvB3SQzY2SPMZpo0r3HwcGkBa+1V56+EzxJmXA w5WIZ3Srbfyh+hdXmfvWSf+HH7RKof8HPkZveIpvw6HOD/GGpFv2QgMcFlRqeTTq rywyAXPqPhd8pTF++PJqTWVc5oP46WfuP/Z/yj3LYVhP4U6Zbv1BIQE89wI45Ovp 62+Z/9JNKn/dM0nYtzXulrbE4eN0TaH+8AmptoHVC9xwtZEkh3zx3L/cvJh8G5FJ QCBA+5qZVeP09c0UE+uw4nk6K3QyPm0BqnlkHyfvXO25jSn3WQ2QALKcJx1wVEtE mwxAyJ7b/UjwmINfInyLuTlfwHDnJvuT1z5ZlAIe1eM3C0xPCppdx6p2HFUr/xQY t8rPD3nOSNO5jZJRyN131DnJos8o2lpXjbc/EBioWcT/X2sBo23oxpwbXiptt5nA kIihuqXx9jM661MDnqwXCvGu4XBRJGeDHx/hhsm++6VdmY7obgzc9mVbcQeLepcP TOA2ltOKU4G1Thd2wo8xqvOim3Z/jYMDOkONezykebDCLckDRzR3Li154t2EYOW7 6wK3iVj144xiV6SWHXyKeXjGVM1D/gx8es8sy1VW0tp0aMkCCdozSK4wpw7Svr20 mlF7ftYkSnx4hxjXDSiDGImVisz8JRlGiRPbRNqB/PWjdt/NQco= =z2Xl -----END PGP SIGNATURE----- --------------ICSh5EEKvjL0iNYwPWwjs0GH-- From xen-devel-bounces@lists.xenproject.org Fri Jan 02 08:40:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Jan 2026 08:40:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1194855.1513022 (Exim 4.92) (envelope-from ) id 1vbahp-00053s-Ky; Fri, 02 Jan 2026 08:40:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1194855.1513022; Fri, 02 Jan 2026 08:40:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vbahp-00053l-GF; Fri, 02 Jan 2026 08:40:21 +0000 Received: by outflank-mailman (input) for mailman id 1194855; Fri, 02 Jan 2026 08:40: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 1vbaho-00053f-4X for xen-devel@lists.xenproject.org; Fri, 02 Jan 2026 08:40:20 +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 a9909538-e7b6-11f0-9ccf-f158ae23cfc8; Fri, 02 Jan 2026 09:40:17 +0100 (CET) Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-598f59996aaso14142343e87.1 for ; Fri, 02 Jan 2026 00:40:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a9909538-e7b6-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767343216; x=1767948016; 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=oXv3agKNnV0s9elI9yh2JSpFn8oB/bR6iRkK8+zm05E=; b=a9KI4h1+LyAoovROCQWR+FizWW7w2H29Yp/rK6uo95tY9euQW9WkUgw1RXobEAL3GJ Mvo9xGMAJFIQsQV09fpGrIvFTY52O+O3AA5xl6XTTKPW/RPSVEn6JxLzQPEdGfrYMv4o uWQvQfs2do/L/K6ztngRtHmxU5dCDiVmK5VkcIlBINoWDs3Afeg1UO2QCmxqhlRq6RLD 4uXG3ic1LBxDgsfjMGHNmsoESgDLeflvOBr+qmYP6GYK0qDSFUGZVOGGENKGMXBQbrex ooFsl0QGTJYcvklPOBOQ3Um5gThU5TNEUOfiY7GC0UILaO3ca7pgBC83hPzEw+YD3rdx 7KCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767343216; x=1767948016; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=oXv3agKNnV0s9elI9yh2JSpFn8oB/bR6iRkK8+zm05E=; b=lU+LyhbAdckND21ziAkdYyyDE2/GLmhauhO4hXwKjAtBFRVmN9cGzOnWW7Aka6i3c8 gm98UwjMiSaLQxJxKbAEsOGwRpH7ficcXocyom5X38ea//x6Ftic41HoKpyZZyS2mRaL mMnYJiMyIbAG+9FaFbBb7DACVjSNecsJY9Gkj13ofQ/vFMWQbwITEI52T9Y26K9YvO2S Ywwvorgl3l1NZusLhhsybKEo72QFHidiEOl6gPAinGoa5UvObQi2wsqjUzGRLkJZ32D3 njoU7NiPoiq5z5gJzfo5qMHx6mL7Z6ftKZwhzlRNPMZSD+tq86G8GI++38aYE9bYDjOg apXA== X-Gm-Message-State: AOJu0Yw6sC4K3SDCPwo5AZpZEyfSlxbAKLlDnHWinDN/JSmu2ydvMHEM ZK2timKeKVmso/227MIbGq3xTj/QRVoJFc8KYRoWyLWYD5fyEcAD/ZbJdo7qVw+AuTy7u5NNdpi EFNMpsmgZQpnCZrzZzCXcOft7EmYMaEw= X-Gm-Gg: AY/fxX6GOG4JAm7S4Rv/+kTHbBb7abwU/oELq/FsVtqGsIq53a+06yZ5aA8I7UxdHUc 3y68zrhg75uFR5PXs/b93/rj9IKZ6rnd3Q3BX1dLB7chM8Xq4f/3jsSnXZvSXMvXSWqLeBxr7li 6lGNaDuGdffd9GlTwSCwLBkpcyLea47YD0WySoN6M4Az0oRt1DdoOtSWvW/rbiZAhhsbrUGf9VY GWYX2BIx57iNymtbXaDLt9mbjAHiYHo/8Ur4Lgh83cJBiGizmI3j3lTpTR4vGjDea3DPvw= X-Google-Smtp-Source: AGHT+IHSah1FqpXb0pDArFOIyWEczE0xZ6hZ2vaeTd0SD77mOpsMZBecIkKl686G9AV6g9ykQAY6HzFtIiOak+TD/L0= X-Received: by 2002:a05:6512:128c:b0:595:9152:b920 with SMTP id 2adb3069b0e04-59a17d479d3mr15426420e87.39.1767343215513; Fri, 02 Jan 2026 00:40:15 -0800 (PST) MIME-Version: 1.0 References: <9f084beff76e40fed2138ba2d59145a96b930c63.1765472890.git.mykola_kvach@epam.com> In-Reply-To: From: Mykola Kvach Date: Fri, 2 Jan 2026 10:40:04 +0200 X-Gm-Features: AQt7F2qXLshlF6bDzxyoPtKPsyUAFnAAo_SqV0sd3lPi1TvvyHWtzNrJPXZW6g4 Message-ID: Subject: Re: [PATCH v7 03/12] xen/arm: gic-v3: Implement GICv3 suspend/resume functions 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 Fri, Dec 26, 2025 at 2:39=E2=80=AFPM Julien Grall wrote= : > > Hi Mykola, > > On 11/12/2025 18:43, Mykola Kvach wrote: > > 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 V7: > > - restore LPI regs on resume > > - add timeout during redist disabling > > - squash with suspend/resume handling for GICv3 eSPI registers > > - drop ITS guard paths so suspend/resume always runs; switch missing ct= x > > allocation to panic > > - trim TODO comments; narrow redistributor storage to PPI icfgr > > - keep distributor context allocation even without ITS; adjust resume > > to use GENMASK(31, 0) for clearing enables > > - drop storage of the SGI configuration register, as SGIs are always > > edge-triggered > > --- > > xen/arch/arm/gic-v3-lpi.c | 3 + > > xen/arch/arm/gic-v3.c | 319 ++++++++++++++++++++++++= - > > xen/arch/arm/include/asm/gic_v3_defs.h | 1 + > > 3 files changed, 320 insertions(+), 3 deletions(-) > > > > 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; > > Do we need this check because we don't free the LPI pending table when > the CPU is turned off? Yes. In the system suspend/resume case we intentionally keep the LPI pending table in RAM and reuse it after wake-up/CPU bring-up. The state is still stored in memory, so we do not need to save/restore it elsewhere; we just need to avoid allocating a new table on resume. > > If so, don't we already have a problem for CPU hotplug because the > percpu area will be freed but not the pending table? System suspend/resume is a special case in Xen: system_state is transitioned during suspend, and the generic percpu allocator does not free/allocate percpu areas in that state (see [1] and [2]). As a result, the percpu storage (including the pointer to the pending table) remains intact across the suspend/resume cycle, and reusing the existing table is safe. CPU hotplug is different: system_state remains in the normal running state, so percpu areas can be freed on CPU offline. In that scenario we should not rely on the =E2=80=9Creuse on resume=E2=80=9D logic; the pend= ing table needs to be explicitly freed as part of the CPU teardown (otherwise it would indeed be leaked once the percpu pointer is gone). The check in this change is intended for suspend/resume, not for hotplug semantics. [1] https://elixir.bootlin.com/xen/v4.21.0/source/xen/common/percpu.c#L36 [2] https://elixir.bootlin.com/xen/v4.21.0/source/xen/common/percpu.c#L88 Thanks, Mykola > > Cheers, > > -- > Julien Grall > From xen-devel-bounces@lists.xenproject.org Fri Jan 02 08:46:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Jan 2026 08:46:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1194895.1513048 (Exim 4.92) (envelope-from ) id 1vbanh-0006Xx-IZ; Fri, 02 Jan 2026 08:46:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1194895.1513048; Fri, 02 Jan 2026 08:46:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vbanh-0006Xq-EJ; Fri, 02 Jan 2026 08:46:25 +0000 Received: by outflank-mailman (input) for mailman id 1194895; Fri, 02 Jan 2026 08:46:24 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vbang-0006Xe-7Z for xen-devel@lists.xenproject.org; Fri, 02 Jan 2026 08:46:24 +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 839b12e2-e7b7-11f0-9ccf-f158ae23cfc8; Fri, 02 Jan 2026 09:46:22 +0100 (CET) Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-37b983fbd45so91045351fa.3 for ; Fri, 02 Jan 2026 00:46:22 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 839b12e2-e7b7-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767343581; x=1767948381; 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=qrW4S6osv5NZbj7pLDS3/qMIoLYngCGkqu0/MOgwGfc=; b=h1IBtQ6aZxdgDbPWB1nipPvzQ5br6ja1P1xPgsNktzOKox3sEcc/1XgI5EhKgyDqqJ QyHZgk1CjLepWScUkqIPkxy1qiDs3nAQ7Fb0cTxJ8bPtNJCFSzvIyzpfWgCY1UJX2r5N e8VSLVjPTiY199BHa+0N4FdcpSoNt7DmmbNnq3ydAAf0ayChoKa6Bz9WuUocvKEDohfd Z7L4xLJ5WO3r9sVjlOL90QCp2yj7n7FnHvMDIgUn5JL35gYnMcNswdiN5AsGkLHsY6bb UNeqxhvhR+hriFB1HmfMDaBHJ1zQMmaUDmWbTWrCtPPYqQsxZ9N15RDUUnFcJtKLudht m+sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767343581; x=1767948381; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=qrW4S6osv5NZbj7pLDS3/qMIoLYngCGkqu0/MOgwGfc=; b=eTT8vp5R0qFFeUNKCCo5SE441JtPp9CSIAvsnt2/VAUntrl/rbeuGzBVOzwCaOhKOp rgNCxhiY0CWTihDbdkmzeBwoDVkygomhEGA1g/KHmj1ETkGxeqLwjDnWBwaHZrwGS5/o PXL6GDTAX7iui2+/lnR/x0CsaxSuq2VB5SUS9mMfDgps1cXY+xF49judp6fn0MKyNSzW 1ntmd71Ndo42e2OG3PoSUdb/arlmRFP7Z7OOHCKZ0Yop+lNiO1MEliaqhtEQKHUcqp6Y jlqPvcER6xBpNP4egJ5Be90DExT7/xJUgXIOiaKWMifSg5vo2oFf+Vw2S7D7ENN2bzfH TaFA== X-Gm-Message-State: AOJu0Yx9Ua0Mmu21W6kOwNimoQz7r+KusR6iKYxpmLao+e1kANwDP9zh 8nYSCqc1l6XIt3/lIchjY6X2CSSXcd3jVcY8EdApMEBu9GEHWPzQ/YzUAOUYtPSRXarfZihO/aa Dk9ncWF7R/plMgRuDL5e9iDXjmHeWh+4= X-Gm-Gg: AY/fxX6y9aYQBZ/clGTxJVksqtK2JfSGlnFtDvG32c8TdHEcULfPERbjrO29/rY5IFg YP3b0mh5N85pLTTwwvITmISRTSyRHW7gYb1n8UFdWxSmP3IfxJzOTLgAqpwb8XzjgC4vvkdiKYZ ml5j0uljVMTo/UN3GG//URJdWNyJZANnfTchywTgKV7+qd3JLhkpfBi0zsH+LCf2Y6oMaaIub2m DUqCNJW0kLfckEVQCcAlrdaOoeWU0HEIFNp6TOBdtyE0KVlcYKyBqOI0osl9GBp6hUuGdY= X-Google-Smtp-Source: AGHT+IEvUREJT59G9gbF4ntKzbDgoUMEE9esOUpfrf1a+xc4mTp2vdJkppWwy+0Ib2hgvtDlLcB2KQTAyfUH0Brozv4= X-Received: by 2002:a2e:be20:0:b0:37f:8332:6ae0 with SMTP id 38308e7fff4ca-381216428e4mr133323951fa.33.1767343581213; Fri, 02 Jan 2026 00:46:21 -0800 (PST) MIME-Version: 1.0 References: <9f084beff76e40fed2138ba2d59145a96b930c63.1765472890.git.mykola_kvach@epam.com> <584bcb9e-ca3a-442a-9b6c-bdb5fb5fb8f4@xen.org> In-Reply-To: <584bcb9e-ca3a-442a-9b6c-bdb5fb5fb8f4@xen.org> From: Mykola Kvach Date: Fri, 2 Jan 2026 10:46:10 +0200 X-Gm-Features: AQt7F2qJKVPqT4IwEhLh-H696ZWNpSTB6ej9QkT-7pjn3ko7owHrClVnUNotyz8 Message-ID: Subject: Re: [PATCH v7 03/12] xen/arm: gic-v3: Implement GICv3 suspend/resume functions To: Julien Grall Cc: xen-devel@lists.xenproject.org, Mykyta Poturai , Mykola Kvach , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 31, 2025 at 5:35=E2=80=AFPM Julien Grall wrote= : > > Hi, > > On 26/12/2025 12:39, Julien Grall wrote: > > Hi Mykola, > > > > On 11/12/2025 18:43, Mykola Kvach wrote: > >> 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/resum= e. > >> > >> 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 V7: > >> - restore LPI regs on resume > >> - add timeout during redist disabling > >> - squash with suspend/resume handling for GICv3 eSPI registers > >> - drop ITS guard paths so suspend/resume always runs; switch missing c= tx > >> allocation to panic > >> - trim TODO comments; narrow redistributor storage to PPI icfgr > >> - keep distributor context allocation even without ITS; adjust resume > >> to use GENMASK(31, 0) for clearing enables > >> - drop storage of the SGI configuration register, as SGIs are always > >> edge-triggered > >> --- > >> xen/arch/arm/gic-v3-lpi.c | 3 + > >> xen/arch/arm/gic-v3.c | 319 +++++++++++++++++++++++= +- > >> xen/arch/arm/include/asm/gic_v3_defs.h | 1 + > >> 3 files changed, 320 insertions(+), 3 deletions(-) > >> > >> 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; > > > > Do we need this check because we don't free the LPI pending table when > > the CPU is turned off? > > > > If so, don't we already have a problem for CPU hotplug because the > > percpu area will be freed but not the pending table? > > Looking at [1], we don't seem to support CPU OFF when the GICv3 ITS is > enabled. So this change could be delayed. But CC Mykyta for awareness. Probably you are right. Another option is to move this `system_state =3D=3D SYS_STATE_resume` handling out of this change and into the follow-up commit where ITS suspend/resume support is introduced, so the rationale and behavior stay co-located with the suspend implementation. If you think the better approach is to avoid these changes for now, I=E2=80=99m fine with that as well and can drop them in the next revision o= f the series (and reintroduce them together with the ITS suspend). Thanks, Mykola > > Cheers, > > [1] > https://lore.kernel.org/48bafdb8e6269a3d958065c6a1062ce2736632a0.17629397= 73.git.mykyta_poturai@epam.com > > > > > Cheers, > > > > -- > Julien Grall > From xen-devel-bounces@lists.xenproject.org Fri Jan 02 09:43:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Jan 2026 09:43:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1194911.1513058 (Exim 4.92) (envelope-from ) id 1vbbgH-0005nA-Fc; Fri, 02 Jan 2026 09:42:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1194911.1513058; Fri, 02 Jan 2026 09:42: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 1vbbgH-0005n3-Bj; Fri, 02 Jan 2026 09:42:49 +0000 Received: by outflank-mailman (input) for mailman id 1194911; Fri, 02 Jan 2026 09:42: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 1vbbgG-0005mx-4c for xen-devel@lists.xenproject.org; Fri, 02 Jan 2026 09:42:48 +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 62688ae7-e7bf-11f0-9ccf-f158ae23cfc8; Fri, 02 Jan 2026 10:42:43 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS4PR03MB8447.namprd03.prod.outlook.com (2603:10b6:8:322::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Fri, 2 Jan 2026 09:42:40 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9478.004; Fri, 2 Jan 2026 09:42: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: 62688ae7-e7bf-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=GeKuvjpijCl6DTbfwBdd7l7czTXGHr4ogTbNM4y3klCbmLHOQ5Wg+tgKqP9qtL90iXQibA4Sl1TCNsp4U+upsHKIbTGIXmac2Zp6YypOJj/ILMN1+ZVruPdkChd3NMhDgN+UsJGb/ghQhG76xnHG4DsYTjJiZOIzCW+oB7QGFGCCKOMQuRBqj9UWn1WVh79FWgQa7D9Oob1VfyW8aKoKSmGqVhu8pp7AvzVMMVIzcNnzDV7FUUO79+NbMkGhqAXwEQLp5uFmqu05VRb4B66/X904weCf38+TnlVzn9PCp//vi85ueAzPAbPdYsDxSZfEFB/i8VjJmt45fur1J7xT+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=CTBIoynGvjpXTtxUwXGOfeyWAeChqHuqKcbpPGXyv6s=; b=pJDO84mPC9zKyyLCsMr3VX953eKZl3UBALJeU92eRTfId0DkxjOkb8FOBbzKYN74izj+gWO71abzAqrbJer18lh7mx1D6SgZmNOpVcwIee1fshJ1ZMAZtlCXjGS8Uo49381kYTkmogQoss2YYHhuSulClwogdEYku2mcHGtouAqaPMwxn8zw8rRagN6zxAc7PubdROn3ZQphyMsXufcJqbBHvKXQfnLKg2sLGJ1KTywXT0IHZLUKqejmsX2zLPhVJ61Ay+ngnYVouaIzClYbgp28m5sctiOMUjXIbpigAtl0z8buicE9fqKNWBhocvmG0UykJAHkNA9aXIW6h+4pCQ== 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=CTBIoynGvjpXTtxUwXGOfeyWAeChqHuqKcbpPGXyv6s=; b=ZjDGLMjzOcxrEERB24rddSyK3cEwcSnhye8A2J8R+rkP2IrWNGJy4+dDYbdzOHeELZIul88hxkLRrjsREYw8U/8bUb3w/F7/9ixYWWKJhsXp69pDDXsTK1nmIRWsSE1GJ1ewdM6/1rWyYYZtRTzhTxBqPLKF7ft6cBpNka+ZEbU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <24aefd91-18ef-4ac2-a1b2-6098aa31e716@citrix.com> Date: Fri, 2 Jan 2026 09:42:34 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , sstabellini@kernel.org, consulting@bugseng.com, Doug Goldstein , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [XEN PATCH] xen: rework deviation to address varargs MISRA violations To: Nicola Vetrini , xen-devel@lists.xenproject.org References: Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0210.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a5::17) To IA1PR03MB8288.namprd03.prod.outlook.com (2603:10b6:208:59e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS4PR03MB8447:EE_ X-MS-Office365-Filtering-Correlation-Id: 6de0ab2a-0cf9-4af9-f07a-08de49e344a4 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?WE0wM2lrZUZkcmVRVlZGSGNxSktvM2ZuclkzdkxzVUE0ZmVaSGNSOUlVVUxp?= =?utf-8?B?WmkxbENFNE9EdzU4N0JqUnVhNGcxeEVCUzQ2blRpQjIweTlGUTQ2SGU3UlVJ?= =?utf-8?B?Qitucythcnh6VkkyRUN5OThxak8wUDd4NjExUkpwaFRhQXdzbk5jSEVwMUlI?= =?utf-8?B?ODdKZzc1UE9WQ3UrK0NBeFNlbmV4SGhvNGVyS1ppU09xN3l2QW15RHJnVmxr?= =?utf-8?B?QXkySFE4c0x1RnlqcTdvUWdZWEV1MEhoQWs3OUVibE9DM1BHMTh2dXdkcjJh?= =?utf-8?B?Uk1rdHdKTHJzeXRuTFppKzV4R1pNdzdVSWpxUUlQQWxUMUxBZUFnRWVOb2s4?= =?utf-8?B?TU4rL0Izd2MrOHZLK0thN2lwU2JvbGV3Z1hwSzFMZ1JCYmY4TzZLaWhGcUJI?= =?utf-8?B?dTN0MVYwLzhaV25wTmVuRjZ4S1hCbDBTaEU5UlY1b0Q4T0d5aDlwK3hlQ25u?= =?utf-8?B?elBqSjJjS3VQajQrRVI2S21MNGlyWmx4SE9qTjZSR0JjKytCOVlBblVWNEha?= =?utf-8?B?c1BiL1FnbTFrTW1HMy9pRnlFeVRuRW5Mb2FVVWN5YlI2SjdtS1RJODlORnIx?= =?utf-8?B?SW0yb2I2Zm1SRVhZaXl5U0pBVnJzeXlJTDN5QkY3TDdOZXVOQkduUnQzQlN2?= =?utf-8?B?TXpjYmt0NjZyM2hCSE9tYzRJRGVXcEVpd1Y1ZUtvYTMxdFBpOThBeDh0NVN2?= =?utf-8?B?R3lndU84bHBHcXQ4dmk0aTEvekNEQVAvcVBJdVdwazJVcTlrRWtZcDhRS0J6?= =?utf-8?B?VzVyMFowUU40UWhvWk4wenpLZmdtSjJxYVhXaDlFanRxNjVldisvVkpuNjZx?= =?utf-8?B?MVR1V2k2aEJFbXNVazdiNnBvZ1dwaWhLS0FERitOWStGMisxY0tJWTJSMzZp?= =?utf-8?B?UlBRUlRSalEyNjl1ZWZSNTNka090MmhzZm4za3c1Qyt1bWVBMStwQWxBK3I0?= =?utf-8?B?ZVBKOGRUcHU0cnJzQldpQ0dTa0NvMnhJWkY3aGVwM3JhdVF3Zm9ZZ3dSaUc5?= =?utf-8?B?bjJCMkJjSmZDclhoV21pZ0pKbkQzcU9LZzZGbVVad2NCbkxlclY1bVFyaUt4?= =?utf-8?B?bWtWZTRIWXpLdXZtTUNSZGxOZldPQjdvdStaaFBqNUdWY2pNa2M1Z3hFY3BB?= =?utf-8?B?TkNaSEwwT2JMNHV4OVlQR29lb3k4d0gvN3hJdnNNOE5LckIwcklRZEFiMXNC?= =?utf-8?B?Y1NZcTJhaXI5OGJvSjNIdDBOS056V2NXVDlab3NOMGcvZ2xGaE9DMXVxVVJF?= =?utf-8?B?aTZVWHduSm5nS2tKMXA1K0h1L2VJVC94R0Mzd1pVUEg3d2JqNWF3VHZZcG9F?= =?utf-8?B?U1lVeWVubUJsTmRvQ0Q2Sm9kaTMwWWJUbk5JMkd5V0duelNhMlV6Qisrbkpa?= =?utf-8?B?M3NvcmtyY0JlYjJKeUg0dUZIeDRmNG9nQmtSMU5yZTZtMUJucVRvOTZUN1Z0?= =?utf-8?B?SDllUmcvck5Ed09Jdm9Uemg5dS9JTXRMbC9wZEF3bE1kRE8zUm1CTU1jMHlE?= =?utf-8?B?N0cwUnZMeVNUSmt5ZWZxcFRuR0dmVC9xOE1uZzhJeDJQT3ZaNzhuZmc2WGQz?= =?utf-8?B?SmxiVUxKa0h3S280U3dnZVRGbitsT0l6Q2xBVnA2VXloNGVoWnNlbm5xNEVi?= =?utf-8?B?blF3M3R5WGduTTU1L1ZYalI1WHNwVDVUNVJZZDlYeDhNUkkydmszUjVuS2xY?= =?utf-8?B?ZEUrN2x6aW1hZ1JzU05VQllzRzZDQzZHb3JPdVlSbksyaXY1N29GdFVSNU9Z?= =?utf-8?B?L1R1NzFxQUhhL3BaVFNFNzBvSWNjM21iNFNTUkt3NnBTMW9sTWF6cjBINWhn?= =?utf-8?B?d2t3YklJSGk1RFcxM3REWjFGZkl6eFAzZy83eE1iNmpyczljTytoY2V6WG1k?= =?utf-8?B?Z2YzQTVnUkpQY09LcCtKNmNUaG9qTEYwOHdDY2xyRU40TmJ1QWoyZGJTRmhp?= =?utf-8?Q?8VQACsaADuV8UEwcKa+w63xkGEN2DkAd?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OXFUT3QwNTVWVkZZWU9DREpZZGxKd2ZXNzdZeEhLa2M0dTRSbWZUK2dvZEIz?= =?utf-8?B?dEkzNlBpQTRPQTh3UVlXWFFBRU1XNERtRFdhOVY5ckdWWHF1eWFLSndHNEs1?= =?utf-8?B?czM5UzZoektCMTBidXRPNGFIZUJPQ2crSExJbC9FNEduRlhLd2hmeG5kbjJE?= =?utf-8?B?REN0OGhQaUJ0bS8xbWhZRlhsWVlyTTRJYmZKajA5WmpYZDkzZ3JUMVVwRUpl?= =?utf-8?B?M1ZNVGc4elRFRm5kRVA0cmRaN3VWNXV5OFBIRjg4VXBkdDRNMGFHMmZDaklz?= =?utf-8?B?SmZhSm1VZGNpMnhMejdqaEt1QXdGVHNlNWpVSTNEMk5ob01JaGR3dFhMdG91?= =?utf-8?B?QXJvNmFwbkIzbzc0V1RjL0tOTGgzbFZiRXJhWHFNQkY3R1hXbDF3T2YxS3dZ?= =?utf-8?B?RE1ISjhqKzU3cEFidTF2OGFnSWpFQXhKcHMvdU12Q3ZEcDByU3FOclRZQW9U?= =?utf-8?B?Vy8wbDhSYWtBYTlFRlJQYTRqMWlORFVpRlYzdHZUQjZkZ1ZZbzFSZmJZOFIv?= =?utf-8?B?dlVodGpKbEh6bWN5T1Q0cHVYRHZPcTFFQjBwMkRlSGE0RkRCUjNVZmNSVGp0?= =?utf-8?B?NmZxalhhSGZtdVh0K0R0MW90WGh4U2ljTzZiNmF4czJmMXZSZjYveU1jSndN?= =?utf-8?B?U2g3MHZWWStqUXF4YlhHRCtJeTNYbWNWQlNORzlLQkxXMmd0QnhkNVJ1UnFm?= =?utf-8?B?WXI0ZzNlVitGRFAzOHQrbmF3YVd2VG1tOHF6Vk9QZ2pWUTAvMlV2aHJrSDR6?= =?utf-8?B?Y3RTSTZUOEJSZ0JZT2cwaTBmYVp2dnBRRmw5M2h0LzdkVStYb1pVenlUeUdP?= =?utf-8?B?Sy8vM0l4aElmSXVneHl3TmtBVGRRZTlRaFE4dWNZeVk3Z2NkZ21TcjJKNVdX?= =?utf-8?B?bWFIY2w3ZHA3a2I2WUdjVWdRUHRrY0tiZW9RZDRFRlhMdHZ3UFRiZkN3bzht?= =?utf-8?B?ZEMvQml4dk95TnBjMWN3a3VTWERQakkvVmpLZmlybDFWdUFxbklabDhoOFlt?= =?utf-8?B?Z0pXamY4MnYyZXptZzFONGFkZ2ZqVzdGeHlOSWtvTlZrRldJSWx3RWMxbTZX?= =?utf-8?B?MmRwbnFFbnA5MlRIVkxZc0VuVUxLUVpEdnptQkFEQ3R3bWNsRkRUc0UxK3d2?= =?utf-8?B?Q0lKNEFmbHlRZktlQ0JNcmtKVmZxcEx5YWxDZEJxV2NmVGZYbjBQVnE3RGVl?= =?utf-8?B?SGJtdTFmQWdvbFdsRlRCaW0zODhGdHV3Y0krODNIYTRwL1NGbTYzN0c4cU05?= =?utf-8?B?M241WlZlRkhoZ0VVcEpoY3dwOXM0L3RiS2s3dzhDMWpXVlJVZENPUktrZHh4?= =?utf-8?B?b293b3pGL0pDbkdZdEUrQnNXYjhpd1ZpbzB4UnFHVjk4RGg5T05oUHAwakdP?= =?utf-8?B?RXZRSkR6MnhRYTZHeUVKZEtJOENZb0RJWW84UElCbTJWcXVtQ2tzWUx5bG9Q?= =?utf-8?B?OFBidzR6bXA0azZ2RDBxc3NGWENmWmFzUCtWVUV3WWxsZ0RBaEVsbWVNTS9j?= =?utf-8?B?TjRrRFVObjFvcndFV0RBYVVYT0tobTRKYmpxaE1Xc3BuQjY2WmtMUmp1b0dl?= =?utf-8?B?N0piVGlFWEdZczJQZWpjeXlCQ3ppY2hMNDdaZE9HQlBlZ3R4ODRlMXV3eHZM?= =?utf-8?B?MkRUV2Rwbm43MFJHRU5KUHBsaDJSY3FlaS9XTDBkUCtCdE9ERDNQOTJiRkRP?= =?utf-8?B?WTVFNWtiUXFkUUJwOHRWS3pnZWYzMFBzWGlxcDRQUUpycFFRZ0VLa0tsS2lZ?= =?utf-8?B?TXJVbXRUVFNPMHR0cjdRalkxcUFLakxwODJma2ZlbnJBVER6bGR4ME42K2o3?= =?utf-8?B?MU1iNnlGZjFVOWZpekxsbzdVRzVvbzB1Rkd1SktrZDhzay9iM0hMUVo3TDhw?= =?utf-8?B?RGxERkxQTm02UEsrYlpIL2xNRGxrclZoWVRGalhZOFhrYXVzdW41NHBhWjZn?= =?utf-8?B?WlhQKzh1RjZaUWFVdkVOUW9MY1dqUGhwWXUweXRFVzUvZVJsbmtoSjBpMndC?= =?utf-8?B?WnpRbkhWSGFGWTBac2IydlZRQ21yekh1UXZsRXY1L21HOHQ4bDBBbHhnVnNE?= =?utf-8?B?SVhrSGoyNEpiN2pPeUNlWWo0TGNoc3JvUHp2RzFBcXdBblFNUjQ1d1FJYVh4?= =?utf-8?B?OWdlcWFUSHNiOEZ3bjVJVHNPSEpSUGRFS1U4RHN1Skt5VXB4MmdOQk5WK3JI?= =?utf-8?B?QlpBMjBnR3Z1M2l4MTFwczJHMkxjUEVoY0gzVkV4UWxhblMxRnRYczdTRWFZ?= =?utf-8?B?b0JCd3B2bnZMSWYzc1ExcmtEa0V2cHhPUG1KLzk1cTl1TWxQMkxmRFdJY3lz?= =?utf-8?B?QkdUdE85MkQxbHUwYmJVeCtRMzhoMGp3aWVtbklEUDNlUEtXbDUvajBHUFln?= =?utf-8?Q?8rbfF/JCahT8iB0U=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6de0ab2a-0cf9-4af9-f07a-08de49e344a4 X-MS-Exchange-CrossTenant-AuthSource: IA1PR03MB8288.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jan 2026 09:42:39.8946 (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: 4Kd/z1xxqzzdlVnqnaPkFxzD/JwCw9YlrcnL+T7k11XHiESe1QZVIfjxn1jYT+lSzEybkLZ9AgHmMhZQ0/MBeC+bJLIpKBnl4rf7P4AHwMA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR03MB8447 On 31/12/2025 11:22 am, Nicola Vetrini wrote: > diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl > index 219ba6993b90..7dee4a488d45 100644 > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl > @@ -570,13 +570,11 @@ safe." > # Series 17. > # > > --doc_begin="printf()-like functions are allowed to use the variadic features provided by stdarg.h." > --config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(^.*printk\\(.*\\)$)))"} > --config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(^.*printf\\(.*\\)$)))"} > --config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"} > --config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"} > --config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vprintk_common)&&kind(function))))"} > --config=MC3A2.R17.1,macros+={hide , "^va_(arg|start|copy|end)$"} > +-doc_begin="printf()-like or scanf()-like functions are allowed to use the variadic features provided by stdarg.h, > +provided that they are declared using the `format' attribute." > +-decl_selector+={format_attr, "property(format)"} > +-config=MC3A2.R17.1,reports+={deliberate, "any_area(^.*va_list.*$&&context(ancestor_or_self(format_attr)))"} > +-config=MC3A2.R17.1,macros+={deliberate , "^va_(arg|start|copy|end)$"} > -doc_end > > -doc_begin="Not using the return value of a function does not endanger safety if it coincides with an actual argument." > diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst > index b3431ef24e26..584907b048ec 100644 > --- a/docs/misra/deviations.rst > +++ b/docs/misra/deviations.rst > @@ -570,8 +570,8 @@ Deviations related to MISRA C:2012 Rules: > - Tagged as `deliberate` for ECLAIR. > > * - R17.1 > - - printf()-like functions are allowed to use the variadic features provided > - by `stdarg.h`. > + - printf()-like or scanf()-like functions are allowed to use the variadic > + features provided by `stdarg.h`. > - Tagged as `deliberate` for ECLAIR. Much nicer.  But don't we want to repeat the part about __attribute__((format(...))) here?  After all, that is the justification of why it's safer than nothing. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jan 02 11:53:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Jan 2026 11:53:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1194920.1513067 (Exim 4.92) (envelope-from ) id 1vbdia-00041f-7E; Fri, 02 Jan 2026 11:53:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1194920.1513067; Fri, 02 Jan 2026 11: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 1vbdia-00041Y-4Y; Fri, 02 Jan 2026 11:53:20 +0000 Received: by outflank-mailman (input) for mailman id 1194920; Fri, 02 Jan 2026 11:53: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 1vbdiY-00041S-GO for xen-devel@lists.xenproject.org; Fri, 02 Jan 2026 11:53:19 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9e912b33-e7d1-11f0-9ccf-f158ae23cfc8; Fri, 02 Jan 2026 12:53:14 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 1E5C54EE3BF1; Fri, 2 Jan 2026 12:53:13 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9e912b33-e7d1-11f0-9ccf-f158ae23cfc8 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=1767354793; b=lWHe1KvKwMy5ygJTclDXNClhXYzLMMu8LTcFTc73BTyjpTAHtYhY+J2hhjDaj1N36Bwh +NoH5UR53JsmUHUb4ohH4Mtx1NqWDA5D+F1SQ4nI3Nzanaf7R/ikPyKSE1yeIEphOGbAZ ghu6oavOq/QDK9KtRGPYGMa4X1pCCaLjGDmZQql7eOTxI/rz/XldB/Yhf/gV1VXX/ivWJ FYsh1a+35iXJrZ7HH+0to7t6tXRsDJsLJwVL8SpGs9FpqKrtZMnzMg5pnC2C/J0gF/Hl3 t271Q++lRDiuh+Z8jKK1OHO84/CSWOHJjIsaAM20ujlwH6yaFURpsj3zKM5HQSZB5pvEb 28FTdVc7+f4/g+JjfG+0e8npgzC/9WyRRB7C6qgC4tTY5NFG1/N34i98sqvy+phi9nstY YIW2M2Vjhd6+lpgLssRYd6ux8tA0NJqumyUHJZelU0XaFsb60Ba4xaux2S1YALHVsf8CY 85eLLh1dNgFBbRj+jAn8/Z6/AwSR00sa7aT5pHprcArFYDyOYrOSmH4nQaI5jSQcUl6/B 7V3mjn2b2qZuuQ1e2Ckn04PCErbzIshEURi+75f11FmquB8sDBlDBy8p8WVtryb2Q/tEP kAumo+Eddov6V9vHWBNSecki12n1+iS+rdOPIzJTW6/PvMaPKSc37eTVoo0YIog= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1767354793; 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=GBQdkdQCLkFLBwvjCkDIdwxPjwFznPD3sgAMOHZLt9I=; b=s2k9kVC0d06DjDnjYj3++oONo0LkKVNJavym+BKQu7V0jdU+2N5GmhMgOj+ea1CiK/Ax G+HfLZ/MAGvAl1akUszlMyI4hAsqselXHMBzMDRL1HYmMFfpszqwWFkCdcXQ9MPj13Mfd x+kdvz28+8Ex2o9MRdIakGwImxbEvuzEbDQNAD71SWEafbryC4+tKe/9OtcuoCyapTl23 hYfQaf73lZB3hpYiA2atykzZpvP2VVC2ZzCMgJ7J3JkxK1t/C4aX3r4txcsv544oMFzEo BRJcnNXqfzt/YKYZjQqwUUXE3d9kGdUzMcYpEAhyqQPaLWUFBmEnhKS0Mglx5NeFlILoM 3GcvT6YMzUqF6FiKBcBmPaS7sQu27Y25E7E6+PZa3S7+1fOKl9qf0X0B14mqsCcUPId28 SkUOIlM4gbnm2Wr+jf++TRP/sPZG8auGkzZZK+PfiqTT5MLzfK91NQR+pjBXHKER7GasE LLDs2uzIZA8eIg3fyC/4R6+dTWGvI9pkq18PI+oye73RC41XQOSHKBIVilUijJDnlSTkh tjGODwRhYrEU2EQK5V77DSdAJvdmYTOyAg4sPZeLSnJGwqeRxe1XWhhsGJ6dMk/bWayjn mjgsfWPjX9zPwm+JPWz87q86FyJPxm18nbO63IyMMt6IInGwGcW62OTaHL7QWRA= 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=1767354793; bh=Npq9oEZbZzzLWGpHEQTOn38Lskoh4OH7F8bHIUAeYq4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=loooHjHphBWZ6+8s9NRNPPTQVxdRLrpABLlY+jUxL5anqc0YJ02gipFDDEdaw0Lp+ dWPahfr8Fr/RLoiL2K34Z3Z1lMgW+E8AuxXMetz0HiHhBfWLvY60QQdQ5QNn3CqrPK QWEfiMmvGdGDDM1r89V/e10dUI4pqD8zo1kyxjW5u38d9BE2RlBXWX+NpxmReQVmJp AGMKGPWjeXlfXk2t6vQwq+RCeVLqlKyK+xFZbP07y0BMEvmgqOuIrF8SCkcsHxyI0F qlqbDduYYYa52GpT6A/tKlv1Opv16dLGE3ilfuS70dN42sxTNuC30YKLA6QDPspwhQ Hj0aZX4c6z+Ig== MIME-Version: 1.0 Date: Fri, 02 Jan 2026 12:53:13 +0100 From: Nicola Vetrini To: Andrew Cooper Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, consulting@bugseng.com, Doug Goldstein , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [XEN PATCH] xen: rework deviation to address varargs MISRA violations In-Reply-To: <24aefd91-18ef-4ac2-a1b2-6098aa31e716@citrix.com> References: <24aefd91-18ef-4ac2-a1b2-6098aa31e716@citrix.com> Message-ID: <6a0d6249997997a1b152d860932f68bc@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2026-01-02 10:42, Andrew Cooper wrote: > On 31/12/2025 11:22 am, Nicola Vetrini wrote: >> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl >> b/automation/eclair_analysis/ECLAIR/deviations.ecl >> index 219ba6993b90..7dee4a488d45 100644 >> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl >> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl >> @@ -570,13 +570,11 @@ safe." >> # Series 17. >> # >> >> --doc_begin="printf()-like functions are allowed to use the variadic >> features provided by stdarg.h." >> --config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(^.*printk\\(.*\\)$)))"} >> --config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(^.*printf\\(.*\\)$)))"} >> --config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"} >> --config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"} >> --config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vprintk_common)&&kind(function))))"} >> --config=MC3A2.R17.1,macros+={hide , "^va_(arg|start|copy|end)$"} >> +-doc_begin="printf()-like or scanf()-like functions are allowed to >> use the variadic features provided by stdarg.h, >> +provided that they are declared using the `format' attribute." >> +-decl_selector+={format_attr, "property(format)"} >> +-config=MC3A2.R17.1,reports+={deliberate, >> "any_area(^.*va_list.*$&&context(ancestor_or_self(format_attr)))"} >> +-config=MC3A2.R17.1,macros+={deliberate , >> "^va_(arg|start|copy|end)$"} >> -doc_end >> >> -doc_begin="Not using the return value of a function does not >> endanger safety if it coincides with an actual argument." >> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst >> index b3431ef24e26..584907b048ec 100644 >> --- a/docs/misra/deviations.rst >> +++ b/docs/misra/deviations.rst >> @@ -570,8 +570,8 @@ Deviations related to MISRA C:2012 Rules: >> - Tagged as `deliberate` for ECLAIR. >> >> * - R17.1 >> - - printf()-like functions are allowed to use the variadic >> features provided >> - by `stdarg.h`. >> + - printf()-like or scanf()-like functions are allowed to use the >> variadic >> + features provided by `stdarg.h`. >> - Tagged as `deliberate` for ECLAIR. > > Much nicer.  But don't we want to repeat the part about > __attribute__((format(...))) here?  After all, that is the > justification > of why it's safer than nothing. > Ok, that would be more accurate for sure. I didn't do that to preserve the original intention of the deviation, but they are practically equivalent with the current codebase, so changing the text makes little difference. I'll tweak that. > ~Andrew -- 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 Jan 02 16:02:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 02 Jan 2026 16:02:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1194953.1513076 (Exim 4.92) (envelope-from ) id 1vbhbA-00084Z-6j; Fri, 02 Jan 2026 16:01:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1194953.1513076; Fri, 02 Jan 2026 16:01: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 1vbhbA-00084S-45; Fri, 02 Jan 2026 16:01:56 +0000 Received: by outflank-mailman (input) for mailman id 1194953; Fri, 02 Jan 2026 16:01: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 1vbhb9-00084M-8r for xen-devel@lists.xenproject.org; Fri, 02 Jan 2026 16:01:55 +0000 Received: from SN4PR0501CU005.outbound.protection.outlook.com (mail-southcentralusazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c10d::3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5a046546-e7f4-11f0-9ccf-f158ae23cfc8; Fri, 02 Jan 2026 17:01:53 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BN5PR03MB8109.namprd03.prod.outlook.com (2603:10b6:408:2a9::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Fri, 2 Jan 2026 16:01:48 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9478.004; Fri, 2 Jan 2026 16:01: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: 5a046546-e7f4-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=pYsL3SCApt9VcA+kE+J6TeCTKTJwEaWPPDF+5nHx6N1AZhbhgKSuTp/LVkc2c9FpEtzQS7qb7DDCVnadxicZm33iw5S9TgmoO+iNX73e+ggQFifO5051c8K4+o6E9tjD/vMvzB/LPHny43frC2rpjpVuSDCvWNVQYz+Zoc5ICOzLr5xJOr4XKK2l8GlrLXkZT/ah//16Ds5UnUa4sNj1n+v9ryYXGlA18eE4fo/g9CbbtLIGghS5/XDeJL9REZ0Teg9lMOkNzL0eAhiBqMqlYB0bmURdeN5PMr/vZTf/Y2U3PeuJMtigotTBN6YzreWu5S8FZR38/2w12ZnytZISKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xi7j5Av3isY9OR8MmPvCD7mWUjoTgiijQ5dtf6qQSCE=; b=iejWT7+2oRs37O7cA7Ghj4wb9Egw+y5VM9FDtNieXxS+g8i3JDSyMpwdnz+Hvv5igEhkxkleMVVif9+FFmQV7cU60NOQ//DJsxE8rHhY5/jimue/pFUBA7XrLxSfZ8aWB2tuOypPOl5nbJHPxsBa95Xui9AH2infxETPAOE+dHAVVY48nwwJds3hiMsdANKKY7hFRarMWUSiKmXBfJdSRQSzTJevd54IrcMToABHLcfm/785+RqBPWMg22Q5iOoAMj+ESbrYDsKjeRS9J9wFnx/p2eh1c8VhY3Cve6Cj4xAXgze0IzepyVj4Nymq4t5jtBzV4EYWkIQMe958aYl09g== 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=xi7j5Av3isY9OR8MmPvCD7mWUjoTgiijQ5dtf6qQSCE=; b=vfM5VXL/8vORw6CigVll0AOn84RwGHnEmAC65OTAtuZ6N/yvq2HrErrNcgCZJKzICqBjsVqukH89pPC++Iv9rA19202eZfWePyLIFHcN0RQWw/M2bhK/p+nXMSmNdCa46GldRqpBXpdZF2ObwldsaC6OKfWjSjEEjATEVVKsKbI= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <5b49e965-7e1a-4b04-baa9-c14e2de2e247@citrix.com> Date: Fri, 2 Jan 2026 16:01:22 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH 2/4] x86/xstate: Rework XSAVE/XRSTOR given a newer toolchain baseline To: Xen-devel References: <20251230135427.188440-1-andrew.cooper3@citrix.com> <20251230135427.188440-3-andrew.cooper3@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20251230135427.188440-3-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0510.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:13b::17) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BN5PR03MB8109:EE_ X-MS-Office365-Filtering-Correlation-Id: 58667c5c-5130-40d9-67c5-08de4a18315d 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?Z1pSYktqa2w2c01iNS9sRXdrcWhEZFgrRGtlMkpyWlkzM1prQ1NBVXkxRVBG?= =?utf-8?B?SUQ2bzYxaElMa2lFWTVPNkRTTHZNbk5yL0lzMk43MEt5bkVFak1nYW52Rjhq?= =?utf-8?B?cU1rVlIzUDJoOXlLYUcwejJkcHM1dW80NTZuNmM3Z2NYekU4K2VJVjhQbG0y?= =?utf-8?B?ckhnOHVYUEx6SWJnbWhTYTQ4WFVrNnh1VVd2RnVBRVd4WnRPaVNtNXpwazBk?= =?utf-8?B?VmhFK0lUTTRPeXpGMWo0aHhtc2gxSjNiWjVzVzMzb0RoTG81b0dsb3lVZlpl?= =?utf-8?B?NWlUcDlOaDlYTWNWYlozbHVSNnZZa3p3Y2lrUVRYb2pvNmtGK1JQMHB1b1B3?= =?utf-8?B?b1Z3a25JY1g4NmZtR3NrR1ZZS0Z5bHJyd0g2Sm1wMENhM003bms0Mzk2WnlW?= =?utf-8?B?STZKK3p2ZUxzOCs0Ukxud1JpSlVNdGhOUjhKQ24wNEZSdEVNN3ZXU1Ixbnp5?= =?utf-8?B?NmYrYkpMRDlGMDFXaHhZbEszeXhXenVNSGdtNE44VURwWmcvdHhVZXRjNDFj?= =?utf-8?B?QjgzcVJwa0NCY3dNemlpRXYrQmltcTJxc1hSK1c3M1BNVVplMTE5NzR1aW0w?= =?utf-8?B?c0ZCSktzVDAwNEhMVjA5QTVOdVZ2WHB0WEZYV1JmUENCZGRSRzl4OS9qWjlH?= =?utf-8?B?MmoyN1hnaWZHQlNhR1R2aC9uL3lHVTRuRHRiZHFDZzZCZjY5Y3JwandHNWwx?= =?utf-8?B?WFY5RldSTHpoc0tDT0NoWDFJdzlMSlNERHlxR0NtWGhEbm1ZTG1TZ2Zkc3la?= =?utf-8?B?ZW9YTGU3T2hhVGpQZGNEUTVBbU8rckEvbEFyaS9GYS9CQzZEcnpRajJGRS8x?= =?utf-8?B?Z0VFMk5CT3dXUzFCYy9TcWVybkxSM2kzNmxmc2FnQXl3aVNOR01ERHpPdi9U?= =?utf-8?B?VXNmRFZoOXkzcjlxUUtPTFRiVW5OMHlBaERrRkNiZ3JOU1BYVUVJbURaT0Jy?= =?utf-8?B?Ukx0OUFHOStaMFpaRGJZLzc3eFNHbTBUVklpUFVnR0ZQRkloTXhGVndva3p5?= =?utf-8?B?eDU5UGtnR2VlampjTllsc0RxMjVXNSszaFoydTltaWxmSUM5VytFZTlxNUdH?= =?utf-8?B?NEU1U1hXY3I5dlA4TmQyNHQ5WUpaVm8ySHRSZEFNNlA5OU13bHNPREo2aXhP?= =?utf-8?B?bmRqd3JZSG5HTlkzNmZVQWJ0d0hEcGVGaGkxTDQwNHlIOHJ5UWNlNjJFellH?= =?utf-8?B?d0pHR2lMOFdZSVpKRnVaWDhCeEV0dnFtUnZWSkt6am9ObHR3eHRRSEtlcUpx?= =?utf-8?B?Wm8wcHhhbXNCL0F2N2dTZXB2dzQ1cVo4bjRsU0FEallhcVplbjhBdWJwVk1v?= =?utf-8?B?RmlBQ0JHZjd2WnVEU01haFVCS2xzYkQ2cGFRV2FoK01hTFcxUmYxZXFWa2Yw?= =?utf-8?B?OGtuQjI4cVhVb3ZsWlNQOU1RdEN5aFc1UTBpQkhLWWEybHF4Mjk0M3FMRUVU?= =?utf-8?B?SzFEb3ByR3RmU3ZjOW5GQkNtTHBvVE1pOUZsWWRDZ3U2S2JtdUFGNENaZC9F?= =?utf-8?B?OUpTUDdlMXA3WjVsU2JpN1dpRHczeHNLbVB0aEpUWFdpY2JPSDF4ME1KYnpr?= =?utf-8?B?dkszOHZtMERaS3hPajE3ZFBDMUY0QVdmSXRlVEgwTWlVNGY5THMrL29TQXNi?= =?utf-8?B?U3Z5TTI2cDRXTWNPaFdEVDNuNUxORkdNNzM5NXZmS3VxdU9XUmlTU29haFQ5?= =?utf-8?B?VzlyWXphVWhOWXNvOHQrRlBBSUcxb3NEUXNZSU9DaC9raWFWYTBHMk5rNVJU?= =?utf-8?B?Z3M1Ly9sQkVKeWZ3L2tQMk1pSlBINlFtMlBwYnUxTG1PTWEzdU5XNkg1MmZC?= =?utf-8?B?RjBSTTFaTC9Mb09ZWkRHVTJxR3dUU0xpMEc3TXpZRzJGcTRJNWNZcGROVm12?= =?utf-8?B?K0o1Qmwrb0g1ckd1UElqUkEvb2hGeFFXcDR2UTdDZ3U4STA1dlorRXcvZElD?= =?utf-8?Q?lajxzG57nnjQQbvjU7lTCqoHqYdvotpe?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bUU1cVR0czBQR1RqbHlBdGowZGgxa2R1VmhTdkpTdDlWSjVleERrMzc4MUdQ?= =?utf-8?B?M0h5L1h0b01yZWl0aWs3YkhhaWQ1U2kxcmJnN0Nvcy9wWUVidytIbkljZzFV?= =?utf-8?B?Nm9nN2VQL2lKOVZQcnQ2b3M3eVBsQVl4eWwwcGEzY3NydklSRFFZV05GSDlC?= =?utf-8?B?WWVyeEMzNFljV2R1V3QzdzVVTEQ4RE9wRjllTFBRVXdoT2c5TFNEZ0pENGYw?= =?utf-8?B?cTBjT0VBdWJhZlp3Tm95NC90WXdXVDNFaVNBZnBzMlp6WkJVbHFUc2hlVlFR?= =?utf-8?B?U2RXb2dRQWQ0MVYzams0blMzQ1VEUklWMDNTcXhrMGF2c0EydGJERFUzb1Bn?= =?utf-8?B?eHFPSXdWUzNyNGNscFkxZzVHbzliU3dCajNCZWdZUnJ0MWZnMXNSdER4cjhT?= =?utf-8?B?NWducng0SzhwSHkzdVhuT0dnajB4WFJRRThkbkxKeVpvNFZueG80VTh5ZmJh?= =?utf-8?B?MkZWZzM0VlN5MEdFbmhRYWZUVjJSQmtPblFBMnNoV0x3ZmNCMk1XYzJZTDBq?= =?utf-8?B?SkhoQ055WURhT1dxck5FNVhZUnFkdlQ3VU5XeW51WWxRcmxEWnhQR2k3YUF0?= =?utf-8?B?NnlMZmZIOFpkUGhpNkdyRTFWZ0lkTlFQUzhaMXNucXFDQVNwcjRmb2d2KzRS?= =?utf-8?B?U0t3b1BTcjBvNW9abXoyMmJoZ1R6bzViOXZiRzl1VHBWUWRVWnhNR3pOUFBv?= =?utf-8?B?OVUwWXZjZFd2UVBGMVViQnJ1TUYwa2NJcUE2ZWtaVkw3aktwSnFwanZzT2ND?= =?utf-8?B?M1BaWFdIWVhHTUo1NGtpVTMvZlByclRaQkVCUG5zUlFVaExveU5odG1HRlJW?= =?utf-8?B?RE9zSjZybStLK2d6TThhdjlUZ1NaTUJQTEJJbWg0QmxGRHhRWGpUYzRDQWtP?= =?utf-8?B?c2Rjay9vUjBlQ0lSbldmQkQ5U0lRVXc1S2ZaMmRBUVpWTWVLWjNLRUtHc2J0?= =?utf-8?B?NGhOZkJWUzNmWkFtd09iaW1vNit2Ny9xeWh6NGV1c3RybzFjMks5SHA3K2kr?= =?utf-8?B?L0k5ekFnd0JsTTZxVWFjZDZoelFheDYxYTJpYTViRFF4djg3bzg2bEdZU25B?= =?utf-8?B?aXJHWDVJVDVhNzBZTzhZeUgyQzlodUNQM3RWTXVDY29ucDc0RGlmdml5SVNM?= =?utf-8?B?RXFteVhUZVJRZE1GYWVzd0JZOWpqcFVTNnpjbk1DbFRyV0kzQ0F6aXBZbjRr?= =?utf-8?B?QTI0Q1NDZnhyUDdCdmJzNnVYdk9VcE9vL0YxNlY0QWJXNlBYa2ZLSys0QXRK?= =?utf-8?B?NXFjdjNPNVFKcVFNcFlZa3hzWm9aQ1pkdUZnejlnVkg3aFgwQmtLZHRkOUMw?= =?utf-8?B?SVhJQTBhNlFXektVZUhxQ08wS2RqREtaUml3anBHa3EyUU0xOE44Vk4wcmFB?= =?utf-8?B?c0RFajhEVFdDTm1oa0FWSitQeG8vZDk4Q21VcEQrWG9ib0J2M3EyeHhWYmNZ?= =?utf-8?B?UWFTNVc5N010K3B3cVZDRXVpdHpaNDRubnlNc296TExHWFZ4dXRxbDZZTWhV?= =?utf-8?B?WkpmWlh1eXovblJJSTh0a3o5dWwrYjZ0d3pKR212UnkyN0NQR0dETndlUmVJ?= =?utf-8?B?NUdDd0RJRWhHYVFZM1dOb3pLejJuM1hmNVJQV0xuOG9Ka0p2a1R6ZUZWejRm?= =?utf-8?B?RjhERXBjTzhybkRCVGhlVys4Nm9PTDdnZ0hEcUFiaC9oK0dqVFZYVGZaRGJ1?= =?utf-8?B?YUhONy9RV0hqTmZPM1Y3R09aemdKR2xaengwTjc0WHduVXhXejZXQTdhWUk4?= =?utf-8?B?V1o4NlNCQW5Cb3UrQXdjWEhZY3cxYVNoN3ZaQ1Q5d2ozUkxncFNkZFROaERz?= =?utf-8?B?d1kwbEp4MEl1YjJ5TitvL1RCQ1B3Y2YzL0N5TmM3QVRFMTN1N2xTSXJwcTEw?= =?utf-8?B?ajA2eEdmcGZXK2lCMGRGSDEwU2JoOEtJOE4yajZhZDN6TnNXdHN6WmxCakx0?= =?utf-8?B?MG0rYU16V1VHQmlGcUdFSUhwZjgzcDlndDluckZhWjRRWjI5VFcvTWFOUXpH?= =?utf-8?B?Z0FYc0hpcnRYV3FYMkswRGpLbkt0S2hJcVY5Q3BSNFV0RXFaSmx1Z2NCa0ti?= =?utf-8?B?QkJLbVNkVWlNcHdVc0s3c2NidHdhdGNBdXdaWmROV240WUtWNFpmZFU4UStV?= =?utf-8?B?RTlXbW00dHFsQ1hBZE4vRjZ5YzNYSVdzdlp3N3hJRTdiYTRwTzdrajdCMkFZ?= =?utf-8?B?cnFhT0dRU1o4bXJwdnZJUTd4TlZ5aWZoMk54elIrb05ldWZTdW8yNUxTd1ZI?= =?utf-8?B?dTk2amJRUUVnRktZMjBGNytHaWhqSm5ubkE3cU9kait4Q0YvSmIyNXBYVEhm?= =?utf-8?B?SGZ0Zi80aW5hdlZ2ZC9oWDJNcjVGTUUxVllYZ09TVUlIczRJeEh3MFdtVFFx?= =?utf-8?Q?YcVovUMd3CdhLu4E=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 58667c5c-5130-40d9-67c5-08de4a18315d X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jan 2026 16:01:40.0089 (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: woIm0/bp9n+/g/Tygse2US7FDunMk1GK1clhChhdi2qAfSYygJ4T19cIYZVzpWedWk/L7nLsRSNTOf13SHKXALeAs7HxFCOVcpMHvgRHYr4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN5PR03MB8109 On 30/12/2025 1:54 pm, Andrew Cooper wrote: > diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c > index 384f78bd5281..4215a83efefb 100644 > --- a/xen/arch/x86/xstate.c > +++ b/xen/arch/x86/xstate.c > @@ -310,21 +310,21 @@ void xsave(struct vcpu *v, uint64_t mask) > uint32_t hmask = mask >> 32; > uint32_t lmask = mask; > unsigned int fip_width = v->domain->arch.x87_fip_width; > -#define XSAVE(pfx) \ > - if ( v->arch.xcr0_accum & XSTATE_XSAVES_ONLY ) \ > - asm volatile ( ".byte " pfx "0x0f,0xc7,0x2f\n" /* xsaves */ \ > - : "=m" (*ptr) \ > - : "a" (lmask), "d" (hmask), "D" (ptr) ); \ > - else \ > - alternative_io(".byte " pfx "0x0f,0xae,0x27\n", /* xsave */ \ > - ".byte " pfx "0x0f,0xae,0x37\n", /* xsaveopt */ \ > - X86_FEATURE_XSAVEOPT, \ > - "=m" (*ptr), \ > - "a" (lmask), "d" (hmask), "D" (ptr)) > + > +#define XSAVE(pfx) \ > + if ( v->arch.xcr0_accum & XSTATE_XSAVES_ONLY ) \ > + asm volatile ( "xsaves %0" \ > + : "=m" (*ptr) \ > + : "a" (lmask), "d" (hmask) ); \ > + else \ > + alternative_io("xsave %0", \ > + "xsaveopt %0", X86_FEATURE_XSAVEOPT, \ > + "=m" (*ptr), \ > + "a" (lmask), "d" (hmask)) This loses the pfx.  I've fixed up locally and double checked the disassembly. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jan 05 08:07:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 08:07:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195067.1513102 (Exim 4.92) (envelope-from ) id 1vcfcC-0006t1-07; Mon, 05 Jan 2026 08:07:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195067.1513102; Mon, 05 Jan 2026 08:06: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 1vcfcB-0006su-Tm; Mon, 05 Jan 2026 08:06:59 +0000 Received: by outflank-mailman (input) for mailman id 1195067; Sun, 04 Jan 2026 17:29: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 1vcRuz-00081A-IC for xen-devel@lists.xen.org; Sun, 04 Jan 2026 17:29:29 +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 eb3e4084-e992-11f0-b15e-2bf370ae4941; Sun, 04 Jan 2026 18:29:28 +0100 (CET) Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-598f81d090cso13857935e87.2 for ; Sun, 04 Jan 2026 09:29:27 -0800 (PST) Received: from [192.168.1.66] (95-24-239-83.broadband.corbina.ru. [95.24.239.83]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-38122687547sm124189561fa.47.2026.01.04.09.29.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 04 Jan 2026 09:29:24 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: eb3e4084-e992-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767547766; x=1768152566; darn=lists.xen.org; h=subject:from:to:content-language:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=Y1u5fdZmMOkdhG7z6A4tRt3Cl7Fdt/qRjWRb6Ckni6s=; b=ncBNsJ/nMmHj9RHihGv5OecoqdpB1ICezFezZrr1wtYJAEyYryXpuOH+8PCG+FlzyF WdKpGZjoBSTqfLeiAr/oint3kivSIv1djcutBlC4oHiVg8NgQv+e3d53Z5wmoiTQm66t G5AcOChjiiZzyYFRqyqVKvCYO6/x3j2iWqTeaovXmGYMb5Ys1z8kEKkxz2HAwgb66/9k bibs/qZ2Gb+WO6AQssJD8PJ1brGIuQo7U/NyNUv3/RiGNmA+FyVvwQNdpZvSB3hddOgU OKoVHxuC4aKoUPJyOBSrZOtUwAN3Ha0TA58ADUJlwOqP3dgmoRacimE6fOOZGGbJu7jy wJog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767547766; x=1768152566; h=subject:from:to:content-language:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Y1u5fdZmMOkdhG7z6A4tRt3Cl7Fdt/qRjWRb6Ckni6s=; b=KYmWg9OgY4eeu8azUMQeWnqKpYVFiwH8iCDTNHaRoecLCzyeSf/8r/SHtgbTAGFSQG K9uFq8cjChVhOZPqe78zsY2eYDEh38mgGEeSbEbC4LUL8Rk23vsbMIQ3Sx3lXsDknRG7 PJoJcdy037gCX6dKZJ/J3bFLTD4sRDewaMci6TgaeO2sWX1A+UXnzkJ7njdgRCl9ORWv xvBP2ZAd784xdoAfBWM7Ge5vpLgdEoHsZOaNWYOqf8wgezQR5vaH8d7d+CSssj5SUY7g 9Q7n34tScxp9S202AlOas2hGofmyLDWFtiQ0g7RLpvrU1XWF9sXlOuOGa+LJ6hST3mUt Bh2Q== X-Gm-Message-State: AOJu0Yzd07JHk9Mf+De4Fmi1u5EFjYG+KPM+mTw/kJ/KJh0oRAjh8b1C epOGUZfZjHxktDP+YWq3/wqvfAM1HB55y4eFc0KIhPUbuC3kGZQ6VxrH7Ig5DRKaGuE= X-Gm-Gg: AY/fxX7+KBcRJKaOSVIUoPmWi8hO1BGtZcM8bhHEF/d2K5RQV/KCM2FfNFwXsdWThJa DMj0qXY+E7DO8URsvqr19RI10TFJrXHWqaLCrL1wToVo0xISkHSiz29ffxCsK1KyDOgJz7qVRlt rpWm1NNfITpuXPsaB3ULi29HRpxEWudpXS/zI1ybAQpzR8hDVQW+2XO44huxNwycz37c8fczPVZ Z9foxx3W5PkZoYZr5HPq71hGYgSdhUrEUPAfZOXWVhkSFVb1XOPB/U2aJVVmDXQsyU0fmQetlGT BuVeVWU+o16FBZubnEzl3rCFdRodPdeLV9Z3djLDNptmPMkLY9WcnAAsx6+6JyCurqCZ6mcjCJA 6mu681knerxsw7kjbci7BZgBBGDoz55sV+k+i/Gq/Usa7+8eNAhvMkD7ZtspT4d9/SclFu4Z7bb W/Gq63fWDmt+t91O/Kze34ZZ1jB8gyp0vjmyPBo1OQg9qNOSsoPwRlZO8hc9A= X-Google-Smtp-Source: AGHT+IFVRoqwOGEN8QOYprmFNMDA9/GZs2cS7OnM0rGqPrBoKd6LyKkJmd08CLTb/htPss0OhMtErw== X-Received: by 2002:a2e:a816:0:b0:36d:4996:1c26 with SMTP id 38308e7fff4ca-3812158e095mr137682301fa.11.1767547765754; Sun, 04 Jan 2026 09:29:25 -0800 (PST) Content-Type: multipart/alternative; boundary="------------HQ8XlUAhr8DTv2IAMrzprYDH" Message-ID: <3ef6bcd6-2936-46f8-a7d0-54cd965a6861@gmail.com> Date: Sun, 4 Jan 2026 20:29:21 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: ru To: xen-devel@lists.xen.org From: =?UTF-8?B?0JDQvdGC0L7QvSDQnNCw0YDQutC+0LI=?= Subject: [BUG] Potential Integer Underflow in Time Calibration Logic and Live Snapshot Revert causing DWM crashes in Windows Guests This is a multi-part message in MIME format. --------------HQ8XlUAhr8DTv2IAMrzprYDH Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Component: Xen Hypervisor (x86 / time.c) Versions affected: Potential in 4.17-4.21 and unstable (tested on 4.18 with high vCPU density) Description: In high-load scenarios (24+ cores, heavy Dom0 load, and frequent VM pauses via DRAKVUF/VMI), Windows guests experience Desktop Window Manager (DWM.exe) crashes with error 0x8898009b. The root cause is an integer memory overflow in the time scaling logic, in case if the time calibration occurs simultaneously with a snapshot reversion or RDTSC(P) instruction emulation. Technical Analysis: The get_s_time_fixed function in (xen/arch/x86/time.c) accepts at_tsc as an argument. If it is less than local_tsc, a negative delta will be produced, which will be incorrectly handled in scale_delta (Or, if at_tsc is zero, a race condition may occur after receiving ticks via rdtsc_ordered, time calibration will occur, and local_tsc may become larger than the tick values). This will result in an extremely large number instead of a backward offset. This is guaranteed to be reproducible in hvm_load_cpu_ctxt (xen/arch/x86/hvm/hvm.c), as sync_tsc will be less than local_tsc after time calibration. This can also potentially occur during RDTSC(P) emulation simultaneously with time_calibration_rendezvous_tail (xen/arch/x86/time.c). Windows DWM, sensitive to QueryPerformanceCounter jumps, fails catastrophically when it receives an essentially infinite timestamp delta. Steps to Reproduce:       Setup a host with a high core count (e.g., 24+ cores).       Run a high density of Windows 10 DomUs (20 domains with 4 vcpus each).       Apply heavy load on Dom0 (e.g., DRAKVUF monitoring).       Frequently pause/resume or revert snapshots of the DomUs.       Observe dwm.exe crashes in Guests with MILERR_QPC_TIME_WENT_BACKWARD (0x8898009b). Currently, the lack of sign-awareness in the delta scaling path allows a nanosecond-scale race condition to turn into a multi-millennium time jump. Environment:       CPU: 24 cores (Intel Xeon with Invariant TSC)       Dom0: High vCPU count (24)       Feature: tsc_mode="always_emulate", *timer_mode="**no_delay_for_missed_ticks**"*       Guest: Windows 10/11 with tsc as time source --------------HQ8XlUAhr8DTv2IAMrzprYDH Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Component: Xen Hypervisor (x86 / time.c)
Versions affected: Potential in 4.17-4.21 and unstable (tested on 4.18 with high vCPU density)
Description:
In high-load scenarios (24+ cores, heavy Dom0 load, and frequent VM pauses via DRAKVUF/VMI), Windows guests experience Desktop Window Manager (DWM.exe) crashes with error 0x8898009b.
The root cause is an integer memory overflow in the time scaling logic, in case if the time calibration occurs simultaneously with a snapshot reversion or RDTSC(P) instruction emulation.
Technical Analysis:
The get_s_time_fixed function in (xen/arch/x86/time.c) accepts at_tsc as an argument. If it is less than local_tsc, a negative delta will be produced, which will be incorrectly handled in scale_delta (Or, if at_tsc is zero, a race condition may occur after receiving ticks via rdtsc_ordered, time calibration will occur, and local_tsc may become larger than the tick values). This will result in an extremely large number instead of a backward offset. This is guaranteed to be reproducible in hvm_load_cpu_ctxt (xen/arch/x86/hvm/hvm.c), as sync_tsc will be less than local_tsc after time calibration. This can also potentially occur during RDTSC(P) emulation simultaneously with time_calibration_rendezvous_tail (xen/arch/x86/time.c).
Windows DWM, sensitive to QueryPerformanceCounter jumps, fails catastrophically when it receives an essentially infinite timestamp delta.

Steps to Reproduce:

      Setup a host with a high core count (e.g., 24+ cores).
        
      Run a high density of Windows 10 DomUs (20 domains with 4 vcpus each).
        
      Apply heavy load on Dom0 (e.g., DRAKVUF monitoring).
        
      Frequently pause/resume or revert snapshots of the DomUs.
        
      Observe dwm.exe crashes in Guests with MILERR_QPC_TIME_WENT_BACKWARD (0x8898009b).

Currently, the lack of sign-awareness in the delta scaling path allows a nanosecond-scale race condition to turn into a multi-millennium time jump.

Environment:

      CPU: 24 cores (Intel Xeon with Invariant TSC)

      Dom0: High vCPU count (24)
        
      Feature: tsc_mode="always_emulate", timer_mode="no_delay_for_missed_ticks"
        
      Guest: Windows 10/11 with tsc as time source

--------------HQ8XlUAhr8DTv2IAMrzprYDH-- From xen-devel-bounces@lists.xenproject.org Mon Jan 05 09:16:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 09:16:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195138.1513113 (Exim 4.92) (envelope-from ) id 1vcghW-000719-Rh; Mon, 05 Jan 2026 09:16:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195138.1513113; Mon, 05 Jan 2026 09:16: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 1vcghW-000712-OX; Mon, 05 Jan 2026 09:16:34 +0000 Received: by outflank-mailman (input) for mailman id 1195138; Mon, 05 Jan 2026 09:16: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 1vcghU-00070w-Ls for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 09:16:32 +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 384709cf-ea17-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 10:16:30 +0100 (CET) Received: from DUZPR01CA0040.eurprd01.prod.exchangelabs.com (2603:10a6:10:468::18) by PAVPR08MB9185.eurprd08.prod.outlook.com (2603:10a6:102:30d::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Mon, 5 Jan 2026 09:16:23 +0000 Received: from DB5PEPF00014B98.eurprd02.prod.outlook.com (2603:10a6:10:468:cafe::2b) by DUZPR01CA0040.outlook.office365.com (2603:10a6:10:468::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9478.4 via Frontend Transport; Mon, 5 Jan 2026 09:16:39 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by DB5PEPF00014B98.mail.protection.outlook.com (10.167.8.165) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.1 via Frontend Transport; Mon, 5 Jan 2026 09:16:22 +0000 Received: from DU2PR08MB7272.eurprd08.prod.outlook.com (2603:10a6:10:2d7::16) by MRWPR08MB11828.eurprd08.prod.outlook.com (2603:10a6:501:9a::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Mon, 5 Jan 2026 09:15:17 +0000 Received: from DU2PR08MB7272.eurprd08.prod.outlook.com ([fe80::5d34:206f:373:a323]) by DU2PR08MB7272.eurprd08.prod.outlook.com ([fe80::5d34:206f:373:a323%6]) with mapi id 15.20.9478.004; Mon, 5 Jan 2026 09:15:17 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 384709cf-ea17-11f0-b15e-2bf370ae4941 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=HFHtk6Xfwx7tFlVt2IdlxMlTLAmnSjq9bsoFg3FVcURS+lDjbRK4XWQryRgdCspiOe1B8puRtMAHIJ8SzQOqfdxVEDctnp4NiRbDKrPowBaPeNjvMD++ES9fVXuWBIsE4va4/+nUiAjhQTuc3OmoAE9sVyu0kpIGV/CboU29gFNHdHyiJz1qMyr7i+lqLI5sh79P1VAcT+lQDjad3IaPoiQ+47gf6ljPNtXzJJeDCMAeAYBh7iMoUpHuSW/OdNULkQiXU24lQeoaHa6iR7u1tlgPKUBqU8iT1iFwKHAZ5lSkaa16O+nZRIQHBJfGjieYtEFVaCxgLBzD6ouCb3XPKg== 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=HOJU0ZwIPPkllI4+3caktRw115EKGzLiBmLFkOAAD00=; b=Oc72TmBe0qX52I9yMggK52yh2E0LZ3oMmAIHlQcc0PNIk52F7vWTa/Z2fpNOchp0LrO8ISm4yWR9evH2uQP6jxQPxQlr2OvloTYOSkqDh34BRBDXHhLi4kziosyl9KV3GbdgGTXksGvSGHBbPW3w+8jhDpUa0IwZ0X/YYASNm+esL44ZVW9tVIj1F5R1/I/k+wxrsNNeqdNKfB+tdeLRMCTGYp3cO9DNqZdkfeOcNuLZvDKyzkSYuEMFCll10EMIn3Nv1j3Vmr4W49nBuz06jlZ/WVckvRXxijQUOLgi7Buhlq6IJO5X0Yz7+v51rCeAMutGVHcQrsjfSqEVuBbF5A== 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=HOJU0ZwIPPkllI4+3caktRw115EKGzLiBmLFkOAAD00=; b=EtzLvFHIm3PeF13yqg1mKVkKlbCTTU5L6JiILq4f4QbLOs0kKeFDVTQW3xWtR/prMgTxCuxFMsvfqBaebVERK6nwjjb6pu6yjszUlXp7sSma5jhSdIh5LLCo004d9TEbrvgsRfuh14lW1EAls8VyLPyOzEiUTGKVC7h/MQc8TKw= 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=L5KsgNWCF6IKl3zEy/I6XS2EM1/x6vUGFWvx/USQzSVXZ01F0Z01yptYSdWNFhq9qKexbiijViKr1RY0qQjzBaM6Hq3lSFbr3VJsKYvY3VIJF/KGEFRf9OAWXHsky7Lm+irkxxokVls161sdZwd7MPtPrvW4HT/mHW2ynWq5FhjvA2JaCeAR3m9kd+VYmF7QePRoH7fyqnZ+gw1VT7fafOK3S1jbD4zRy+uns3ycZ+JXXr27EFgWxd9kkfXwXXYct0Ll6GnXzXoJQ93znzPguWmq2SklgtObsCHxUQAYky0si30ys754yO4evfu9amAA17LfdIQ0HyhLaRE48IkTLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HOJU0ZwIPPkllI4+3caktRw115EKGzLiBmLFkOAAD00=; b=jWFaH2b3WKFgaaA80TdIPH1w6OrLFvYORHdHge61Xs06RZ3a5of57w/wWe2CXLDkGtL6yhJaXmRbpeLvg1aJm3Ppy5/5cDIS+qQVGR25xt+wrlQJ4q6ozIwZUi1ZLobti/nML+sMFzr/cCbqtLA/APP7Cf8QDPiZQ5biYqLDHuWT/UewVAzbQzNHhEyjkFRje5pbHdY+VPAXUwDpdxQjxgGqvmJJOBAJDOgmFSjCYRR87DHEGqBzURBOD1BkMGVU2J5HAfPzDtEwCRGVUmuMyeKUtiX7tlBYM6E5h/pMwZEkweKmK2so+hF/66e0HBUiNXzSr4djCpdmPeURpnrjxg== 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=HOJU0ZwIPPkllI4+3caktRw115EKGzLiBmLFkOAAD00=; b=EtzLvFHIm3PeF13yqg1mKVkKlbCTTU5L6JiILq4f4QbLOs0kKeFDVTQW3xWtR/prMgTxCuxFMsvfqBaebVERK6nwjjb6pu6yjszUlXp7sSma5jhSdIh5LLCo004d9TEbrvgsRfuh14lW1EAls8VyLPyOzEiUTGKVC7h/MQc8TKw= From: Luca Fancellu To: Bertrand Marquis CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk Subject: Re: [PATCH] xen/arm: Set ThumbEE as not present in PFR0 Thread-Topic: [PATCH] xen/arm: Set ThumbEE as not present in PFR0 Thread-Index: AQHcfiO80ZeGSKmclk2/0HK7x9tq5A== Date: Mon, 5 Jan 2026 09:15:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3826.700.81) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DU2PR08MB7272:EE_|MRWPR08MB11828:EE_|DB5PEPF00014B98:EE_|PAVPR08MB9185:EE_ X-MS-Office365-Filtering-Correlation-Id: e2372975-7704-4028-610f-08de4c3b180d x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|376014|366016|1800799024|38070700021; X-Microsoft-Antispam-Message-Info-Original: =?us-ascii?Q?JOalNdXt64IkkmEgKThr0UbuXJ4b1ZY9E6r3iPR+gAmMveXxtNt2wbYm/AGT?= =?us-ascii?Q?+1Jc2ILBvoQdyOKOsjGv83Ty9zq5R42QHnrVmvoevTcD0AIL5hlqGv680MhR?= =?us-ascii?Q?LFihNcsWxv6tv4uKhGJ9HJVTZgzOgf9DhcvXyTYej4NHkOKHr/UeliHhPmYA?= =?us-ascii?Q?4a+pD4hVIpwyoS3drIJraxFIEOARFMJqs/jHwR8szdhTJafriJNFcG2GxBxr?= =?us-ascii?Q?82NnFAzHyi9v75k0S8tK0SsvC6itDbflF9hI8IKg/2AHkWhsobAcOt8ws2YS?= =?us-ascii?Q?qjuTCUKjhQQM/YLFAJzk9DDwVs8vhJnq+jAGH83CrFW8PwuQxZSf0ryz1P3o?= =?us-ascii?Q?W1659SdKBCt0fodvlLd1HOWv/eFJBeLWoIOjNcJtWU9DRPCVJIgwKJ4Vt4oc?= =?us-ascii?Q?LxeAEx3X7aeshZASJyFvrJfXkxUPPQ7/D8epBQUZ45IgwkHq2rE7TpmnlUFA?= =?us-ascii?Q?SqcvFlUhkJKiHA/lZmaLSwouNW0KMXf+foi56dc9GWmffN7beSPquworSNoj?= =?us-ascii?Q?Y3IemTXYg6SvJ0Dyk6UIAcUDXJUCX70XRWqW3IZxzQ3k7Mi/8khOGS3Crr1R?= =?us-ascii?Q?X2Bvhhp3jjK8T30UYvJDqI+9B4EPp9U6y2j5OaZ0uywK7hLMm9SfWtSuJQUM?= =?us-ascii?Q?PbAudeUwLp8eWg1lxB8Qt1aoOhe+jJRxh/h7f0w9ctjciE1vjdkDT69TX3gD?= =?us-ascii?Q?ArOWwy9Qnle4blX5fNLNt/nvg0+RST6Fg5tL4KQRr+8FSAABbFTjEzsJbGW3?= =?us-ascii?Q?H1PyyLPBbY6tjB8wqsxVlelexL4l+SdSxjp3qTf4+48sACDzunBlbad3CQJ+?= =?us-ascii?Q?wBV8CSG3Wv+/69W7GyIaQv0SC2XwZhzkZLHOIM+059425IyTp/gpcYfL3J+O?= =?us-ascii?Q?0CHXlCiulZuL7WoNygWIg+6JxOylQz4h+ltN2CvaRVuYHEhw9oWclv19CMkt?= =?us-ascii?Q?j2KiB//zB9D/njamC82/u1C4oMHbfvFBbenb69RRb30h01LvHRXRzFdFi4HM?= =?us-ascii?Q?SYaQfSXUcvzWAlisLZllIOzmKfD1ccOE4GMG9gkVZnFiKcC7rz/HQ9/mewTX?= =?us-ascii?Q?rfUTNKvvMUERtH8WwwSaX5VgBtzfgIQji0ZGReQ5bd8yNoZOvnkdo0ATn8aT?= =?us-ascii?Q?Xia1dJIhzuc969Nk4sDA5v2B6e0vVqg2xk4VS5EN2pEg1b6DHQeidL4jk3kC?= =?us-ascii?Q?GIMJTPdUJAGJSToq3ZoqLl0tzZHsCRSGeAp4DUGocU+9xs+YRpnkqsP17g4n?= =?us-ascii?Q?9TVjNZsTjQ7ZEglgZHR+IM7YAsh4ATI1ybm5MxgTsXhabAxZWRH+JIEpTPs6?= =?us-ascii?Q?sFskRMcB2ftNDtC/DvLsinHsKFZzQCLjbzSlryenBuXvtJrNXj6dw8PFns1F?= =?us-ascii?Q?4xBVRDINKXycbsbitvv/6haC8BM1+9sTS17WFW4hhEsOpCZfa0+Fj9kGF81J?= =?us-ascii?Q?w2JgAGzuh/amtmZc2cXzwtj37ACJ5AMN6PuSgtraN+NUKZN4EAvqgFf4Foxa?= =?us-ascii?Q?2qJVSy3Vrxk0TwiiaH364l2VPf9WzaQudV6D?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU2PR08MB7272.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: <8F9D7965CA59A448B72CD21A356F8FC5@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MRWPR08MB11828 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5PEPF00014B98.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 6709afd2-bce3-47e1-a6b1-08de4c3af15a X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|36860700013|35042699022|14060799003|82310400026|13003099007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?YvXBA0PPcxjRBJr98zUI9Hox55AyjKW0wG0w4YMRMyp+4GoV+FCVbbhxEhOK?= =?us-ascii?Q?Yy4RRciykuXc6UA0wAGJ5CqOdQDnkcVHXFwvjLZtGCyZUuIJ7kiCKsFHSuEp?= =?us-ascii?Q?BF+eNJwQuGUZa8JEWL16R2hYdYUG9qCYBzqFCbXMfIp32OrOpDHFTsMv429l?= =?us-ascii?Q?yPLcEznDRGJMjYBGbv/bz02O9K3fSM9KKXxHVtFpu4naTTzhI6DQJ/AHOm7J?= =?us-ascii?Q?86pHl/cfVzluJlaP6seozwnMJm5v9wqwJts4Ww4lWjvQrUlFH8BBlpTtbxvo?= =?us-ascii?Q?cTORvaCsZzgUaBo+xoz451YzYzDlGaQOEUwqiyBd1Ie5puSyzTfnjwFfbJTb?= =?us-ascii?Q?G4P5gjaryxVdwNFWB3X0OIKu8JR0x2cUUWE/xwzs5Wlm0d/5x+re7w4YIrsp?= =?us-ascii?Q?njiGTqBrmKdIjPnpcVaRgrjaf8nJ6fFWgYuDxfkaLcUuchln2DqbL1wTitJn?= =?us-ascii?Q?zIhvA7G79JStkUDjy4q3TaRR2j6E7adtP0nNBbmITpk7d2DgM0tk0uRwd53n?= =?us-ascii?Q?Yd478eddpwgEQFIpYS6zLHPBgHMBUzHCrpYGmc+fyryVbmo11YUlJl0MgJHx?= =?us-ascii?Q?Gb1679YlHUZvIt2233UTw7vhsMiv/dxlLkeSc1KnGSrUg4qGzt5qQeT17Gym?= =?us-ascii?Q?UtqjbttMN0j53bE83dmpMEFHEfHC2B7ZnJ7jbHuvxqa6QlD3ao92/Kwlimyp?= =?us-ascii?Q?J7eVS3SHYf9cnDggSbQhA/VSPvn/I6orHN1SxAJzP1X42TeRFA6+tJ73TpUh?= =?us-ascii?Q?W4veEU1g/+ALi1YOMLiHavEPCuTQ6M5cV/RHS4wQpJZXmOXcA6BqGq9E5LTN?= =?us-ascii?Q?I/rDBZIIevnZBFP3R97J8YwNsAt+ysuuTHNjq6d96FwVjyhU3Sfjan98FKtf?= =?us-ascii?Q?rKBNrel87qlKyFIKy/pDA/3eQgQNVX+9Bo3noVkiV8GZq+/yQJkAMT7cbYdE?= =?us-ascii?Q?k8fbcgIIRp5YOrLIsjqq52IA2909Tp8ugmovy2Kw8aHrzHGoSZstLXcvru0l?= =?us-ascii?Q?aJvPe3i+3w2YUHQ8E2zqU8Rm5UJdYsU6692apHjWAlg0/MaZqWgD73EfbRVr?= =?us-ascii?Q?KLAleBFm+60ImcCq3ld+o7GynZmZWQ1Ooi8NnBh2OmjoCOTJblvgW0xSLjQQ?= =?us-ascii?Q?j6OedjVP1YD3JfiJsTXtvcRkyWD5jEl95UxPvV4vTzKaPi8Te3ZU42qhUiMp?= =?us-ascii?Q?ZXXtKdHGlcyAxmATBKhdEwmXFwx62aIW6uHM1WfHzHCkqi4q5lBMwINOwYA8?= =?us-ascii?Q?dvPDkEIX/De1LBD5xOvcy0BDLS71wVMmtgYS7+if4yvhIxDepZw8pXPozj5+?= =?us-ascii?Q?i5GccCI8CIBN4f6Ceekt1PPcbj9Gdq1ZGIkBp0jxYZJH+CxRAtLdBZ90BJx5?= =?us-ascii?Q?VAE3HxWlvDhDFuDi9OrzJvwCAkIr96355BfSvutJfAPCdA2Xpd4uXW06nFCi?= =?us-ascii?Q?Mccm/eAjSVRXefSKzAw3anY9/LXQ3IxeQydMv91MlLHPxkjL8tuar0e4LjVA?= =?us-ascii?Q?zBmh9JDmfFnL4GCz+WukB7kgcTIo4TNr+h1TaJxSROnb4p+D/7W/E5k6woX0?= =?us-ascii?Q?7UTbSKyo8A0ZzoVqhsA=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)(376014)(1800799024)(36860700013)(35042699022)(14060799003)(82310400026)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2026 09:16:22.2445 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e2372975-7704-4028-610f-08de4c3b180d 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: DB5PEPF00014B98.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR08MB9185 Hi all, > On 9 Dec 2025, at 10:37, Bertrand Marquis wrot= e: >=20 > Force ThumbEE support to not available in the version of the PFR0 > register value we present to guest. > Xen does not support ThumbEE and will trap all access to ThumbEE > registers so do not report it being supported if the hardware supports > it. >=20 > Fixes: 5bbe1fe413f9 ("ARM: Drop ThumbEE support") > Signed-off-by: Bertrand Marquis > Reviewed-by: Michal Orzel > Reviewed-by: Luca Fancellu > Tested-by: Luca Fancellu > --- just a follow up on this one, the QEMU bug preventing PFR0 to be trapped at= EL2 on Arm v7a will be fixed when these pathes will be merged: https://patchew.org/QEMU/20251231170858.254594-1-peter.maydell@linaro.org/ Cheers, Luca From xen-devel-bounces@lists.xenproject.org Mon Jan 05 11:05:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 11:05:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195151.1513133 (Exim 4.92) (envelope-from ) id 1vciP4-0003cL-Iq; Mon, 05 Jan 2026 11:05:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195151.1513133; Mon, 05 Jan 2026 11:05: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 1vciP4-0003cC-Fw; Mon, 05 Jan 2026 11:05:38 +0000 Received: by outflank-mailman (input) for mailman id 1195151; Mon, 05 Jan 2026 11:05: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 1vciP3-0003bi-FL for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 11:05:37 +0000 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7497c5c7-ea26-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 12:05:33 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 8E1CA5BE34; Mon, 5 Jan 2026 11:05: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 C299213964; Mon, 5 Jan 2026 11:05: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 Uq/KLfuaW2n0WQAAD6G6ig (envelope-from ); Mon, 05 Jan 2026 11:05: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: 7497c5c7-ea26-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1767611133; 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=d7kz22UVoMzVOoVceTJa5D3QW6nnJWeqh52qRHMmxyM=; b=D+hNut3y0sEIHOfNimoEEIzc8JDdM0ipyZKf6Oor1G05pOhArTT2PqQObAwGKyqPvd0eaQ zBXF6vXudtWE7VijoF5embZ/WS/e8MHXGPQDYlB7RpCa4fVz/EgXGDfUqy0Ib6h+zqWEtK +A3ogIuG8iwllDvNYQZ4ZcpijOKxyws= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1767611132; 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=d7kz22UVoMzVOoVceTJa5D3QW6nnJWeqh52qRHMmxyM=; b=PQVwouCVc7nGDB1qdgE830ofCVoKADTLcrFqXrmg3S4GjIR2ZlxCGc0yA2KOklpz6Wcxfq FVKxwC+Eq9e9UlSz0mA8FDm5JR2if9kLDGVOWm4WgVerdfDitqlLmYQ+Nx2hiUY4k4ithT XDjGJBzSNza1xccmoLx/qct3gm2bzk0= 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 , Long Li , Peter Zijlstra , Will Deacon , Boqun Feng , Waiman Long , Jiri Kosina , Josh Poimboeuf , Pawan Gupta , Boris Ostrovsky , xen-devel@lists.xenproject.org Subject: [PATCH v5 01/21] x86/paravirt: Remove not needed includes of paravirt.h Date: Mon, 5 Jan 2026 12:05:00 +0100 Message-ID: <20260105110520.21356-2-jgross@suse.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260105110520.21356-1-jgross@suse.com> References: <20260105110520.21356-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)[24]; MIME_TRACE(0.00)[0:+]; TAGGED_RCPT(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]; RCVD_TLS_ALL(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[infradead.org:email,suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:helo]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com] X-Spam-Level: X-Spam-Flag: NO 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 Acked-by: Peter Zijlstra (Intel) --- V3: - reinstate the include in mmu_context.h (kernel test robot) V4: - reinstate the include in arch/x86/kernel/x86_init.c (Boris Petkov) --- 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/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/lib/cache-smp.c | 1 - arch/x86/mm/init.c | 1 - arch/x86/xen/spinlock.c | 1 - 16 files changed, 22 deletions(-) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index f9983a1907bf..42447b1e1dff 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -31,7 +31,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 6e6c0a740837..4bd1e271bb22 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 a26e66d66444..9cd493d467d4 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/mshyperv.h b/arch/x86/include/asm/mshyperv.h index eef4c3a5ba28..f64393e853ee 100644 --- a/arch/x86/include/asm/mshyperv.h +++ b/arch/x86/include/asm/mshyperv.h @@ -8,7 +8,6 @@ #include #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 d0a2847a4bb0..83f51cab0b1e 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -26,7 +26,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/lib/cache-smp.c b/arch/x86/lib/cache-smp.c index 824664c0ecbd..7d3edd6deb6b 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 #include diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c index 8bf6ad4b9400..76537d40493c 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 Mon Jan 05 11:05:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 11:05:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195150.1513123 (Exim 4.92) (envelope-from ) id 1vciOw-0003Le-86; Mon, 05 Jan 2026 11:05:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195150.1513123; Mon, 05 Jan 2026 11:05:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vciOw-0003LX-50; Mon, 05 Jan 2026 11:05:30 +0000 Received: by outflank-mailman (input) for mailman id 1195150; Mon, 05 Jan 2026 11:05:29 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vciOv-0003LR-DO for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 11:05:29 +0000 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 70fc182b-ea26-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 12:05:27 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 514E43371A; Mon, 5 Jan 2026 11:05:26 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id A2DBE13964; Mon, 5 Jan 2026 11:05:24 +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 uP41JvSaW2ntWQAAD6G6ig (envelope-from ); Mon, 05 Jan 2026 11:05: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: 70fc182b-ea26-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1767611126; 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=iVzu4kE4MLmm+li5ZBJK76LENzxCWIbHtMPjUgiboWw=; b=C3JCCpcVjFUSa3srxxotvwVl2NOiZOLOK8hHyDzwSRoieBhrKbvEUjN82h9eqkbtyDTgdF ORnfKNzTkvWpfTGy3qHgHY0Ey3JJXC7lzxwiNA7E1GZd1Jk6DQGiEDHrpVWYD5nhtPOlnj fp6hjeZ+kuRgsZiXem+tNUV+QN0M2lw= Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=C3JCCpcV DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1767611126; 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=iVzu4kE4MLmm+li5ZBJK76LENzxCWIbHtMPjUgiboWw=; b=C3JCCpcVjFUSa3srxxotvwVl2NOiZOLOK8hHyDzwSRoieBhrKbvEUjN82h9eqkbtyDTgdF ORnfKNzTkvWpfTGy3qHgHY0Ey3JJXC7lzxwiNA7E1GZd1Jk6DQGiEDHrpVWYD5nhtPOlnj fp6hjeZ+kuRgsZiXem+tNUV+QN0M2lw= 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 , Long Li , 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 (CS GROUP)" , 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 v5 00/21] paravirt: cleanup and reorg Date: Mon, 5 Jan 2026 12:04:59 +0100 Message-ID: <20260105110520.21356-1-jgross@suse.com> X-Mailer: git-send-email 2.51.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Flag: NO X-Spam-Score: -1.51 X-Rspamd-Queue-Id: 514E43371A 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]; FUZZY_RATELIMITED(0.00)[rspamd.com]; TO_DN_SOME(0.00)[]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; MIME_TRACE(0.00)[0:+]; ARC_NA(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,broadcom.com,armlinux.org.uk,arm.com,xen0n.name,linux.ibm.com,ellerman.id.au,dabbelt.com,eecs.berkeley.edu,ghiti.fr,linaro.org,goodmis.org,google.com,suse.de,lists.infradead.org,epam.com]; DKIM_TRACE(0.00)[suse.com:+]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_GT_50(0.00)[58]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; R_RATELIMIT(0.00)[to_ip_from(RLkdkdrsxe9hqhhs5ask8616i6)]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:mid,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo]; RCVD_VIA_SMTP_AUTH(0.00)[]; TAGGED_RCPT(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com] X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Rspamd-Action: no action X-Spam-Level: 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 Changes in V3: - fixed 2 issues detected by kernel test robot Changes in V4: - fixed one build issue Changes in V5: - fixed another build issue - rebase 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/mshyperv.h | 1 - arch/x86/include/asm/paravirt-base.h | 35 ++ arch/x86/include/asm/paravirt-spinlock.h | 145 ++++++++ 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 | 87 +---- 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 | 13 +- arch/x86/kernel/kvmclock.c | 1 + arch/x86/kernel/paravirt-spinlocks.c | 26 +- arch/x86/kernel/paravirt.c | 42 +-- arch/x86/kernel/tsc.c | 10 +- arch/x86/kernel/vsmp_64.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 | 1 + 66 files changed, 662 insertions(+), 827 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 Mon Jan 05 11:06:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 11:06:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195161.1513143 (Exim 4.92) (envelope-from ) id 1vciPW-0004D6-RG; Mon, 05 Jan 2026 11:06:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195161.1513143; Mon, 05 Jan 2026 11: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 1vciPW-0004Cz-O3; Mon, 05 Jan 2026 11:06:06 +0000 Received: by outflank-mailman (input) for mailman id 1195161; Mon, 05 Jan 2026 11:06: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 1vciPU-0003LR-Vo for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 11:06:05 +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 86910f4d-ea26-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 12:06:04 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 5BA0B336E8; Mon, 5 Jan 2026 11:06: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 30B6313964; Mon, 5 Jan 2026 11:06: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 ItpvChqbW2kWWgAAD6G6ig (envelope-from ); Mon, 05 Jan 2026 11:06: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: 86910f4d-ea26-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1767611163; 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=J40DNlks4Gvgx9Q7SIsbfiAZc2I9oXyqHrX9G9MnLts=; b=bl4l/b0t3rkUft+9XXHMt66dVhWPjkxOKnCfmmQIDOxrmkCoZZ7uorO6j8WdyceuLH3Frj PV/Eo/MwcWyQ6hxKCGesy9DPjOCGn7jxhcuFEkH/CM4JD6Qcfaflur36Ou71DNxMxV7tqA CHG0cZijkhTAZkJBWmg/OWrHSKJmFNc= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1767611163; 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=J40DNlks4Gvgx9Q7SIsbfiAZc2I9oXyqHrX9G9MnLts=; b=bl4l/b0t3rkUft+9XXHMt66dVhWPjkxOKnCfmmQIDOxrmkCoZZ7uorO6j8WdyceuLH3Frj PV/Eo/MwcWyQ6hxKCGesy9DPjOCGn7jxhcuFEkH/CM4JD6Qcfaflur36Ou71DNxMxV7tqA CHG0cZijkhTAZkJBWmg/OWrHSKJmFNc= 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 (CS GROUP)" , 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 v5 06/21] sched: Move clock related paravirt code to kernel/sched Date: Mon, 5 Jan 2026 12:05:05 +0100 Message-ID: <20260105110520.21356-7-jgross@suse.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260105110520.21356-1-jgross@suse.com> References: <20260105110520.21356-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]; ARC_NA(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,infradead.org:email]; RCPT_COUNT_TWELVE(0.00)[43]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; FUZZY_RATELIMITED(0.00)[rspamd.com]; FREEMAIL_CC(0.00)[suse.com,broadcom.com,armlinux.org.uk,arm.com,kernel.org,xen0n.name,linux.ibm.com,ellerman.id.au,gmail.com,dabbelt.com,eecs.berkeley.edu,ghiti.fr,linutronix.de,redhat.com,alien8.de,linux.intel.com,zytor.com,epam.com,infradead.org,linaro.org,goodmis.org,google.com,suse.de,lists.infradead.org,lists.xenproject.org]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_RATELIMIT(0.00)[to_ip_from(RLfdszjqhz8kzzb9uwpzdm8png)]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FREEMAIL_ENVRCPT(0.00)[gmail.com] X-Spam-Level: X-Spam-Flag: NO X-Spam-Score: -6.80 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 31220f512b16..102ddbd4298e 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -1056,6 +1056,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 df78ddee0abb..21b4de55f823 100644 --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -30,6 +30,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 41ba0be16911..efc45669b6a0 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -770,6 +770,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 4f97896887ec..7ff8dbec7ee3 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 28e7cc4f7964..fcc2a1c0dcb8 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 Mon Jan 05 11:06:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 11:06:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195163.1513153 (Exim 4.92) (envelope-from ) id 1vciPd-0004YF-4P; Mon, 05 Jan 2026 11:06:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195163.1513153; Mon, 05 Jan 2026 11:06: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 1vciPd-0004Y8-1b; Mon, 05 Jan 2026 11:06:13 +0000 Received: by outflank-mailman (input) for mailman id 1195163; Mon, 05 Jan 2026 11: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 1vciPb-0003LR-Dw for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 11:06: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 8a0c2ba5-ea26-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 12:06:09 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 4CD5E5BE34; Mon, 5 Jan 2026 11:06:09 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id CCFD513964; Mon, 5 Jan 2026 11:06:08 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id EqRlMCCbW2keWgAAD6G6ig (envelope-from ); Mon, 05 Jan 2026 11:06: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: 8a0c2ba5-ea26-11f0-b15e-2bf370ae4941 Authentication-Results: smtp-out2.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, "Peter Zijlstra (Intel)" Subject: [PATCH v5 07/21] arm/paravirt: Use common code for paravirt_steal_clock() Date: Mon, 5 Jan 2026 12:05:06 +0100 Message-ID: <20260105110520.21356-8-jgross@suse.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260105110520.21356-1-jgross@suse.com> References: <20260105110520.21356-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[] X-Spam-Flag: NO X-Spam-Score: -4.00 X-Rspamd-Queue-Id: 4CD5E5BE34 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Rspamd-Action: no action X-Spam-Level: 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 fa83c040ee2d..fc9b5b7016c3 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1320,6 +1320,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 Mon Jan 05 11:06:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 11:06:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195179.1513162 (Exim 4.92) (envelope-from ) id 1vciQ0-0005D7-Bi; Mon, 05 Jan 2026 11:06:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195179.1513162; Mon, 05 Jan 2026 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 1vciQ0-0005D0-8v; Mon, 05 Jan 2026 11:06:36 +0000 Received: by outflank-mailman (input) for mailman id 1195179; Mon, 05 Jan 2026 11: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 1vciPy-0003bi-Ro for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 11:06:34 +0000 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 983b4e66-ea26-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 12:06:33 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id EFCDB5BE37; Mon, 5 Jan 2026 11:06: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 6D09113964; Mon, 5 Jan 2026 11:06:32 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id rI8SGTibW2k7WgAAD6G6ig (envelope-from ); Mon, 05 Jan 2026 11:06:32 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 983b4e66-ea26-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1767611193; 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=sq7KPXy9CZZvgz6hcAmaAiaWfI6QDSCYH9PhP1wlCXQ=; b=R3uquS7DuaTqkmiy3OL14/GMUd1PcYm5UmreeS2zp+4xRhygoZX3LqQjYR5k/5GLd9B24x JFSb6HcM/UDD6OER7qPF89zQUWI+rpGpbVcSLt46GUf5iGinfReidaWahawxnhchocq3or Pt/ay2wiUh1LPWztr/DNhVtFg1oSwtk= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1767611192; 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=sq7KPXy9CZZvgz6hcAmaAiaWfI6QDSCYH9PhP1wlCXQ=; b=DFq1Nhqb2K455fBwjfKUATz/GZWRxyGpycWnPfkV3LVFmseqSauzLSAZTgCooIsa562iob umiYRFNeJuuHcljvuu0t8Yct3EXpiTxRHPQlaOON8+ybe+KUQMEoO8urCmoBsze4NptrfP eKALTL9Kwlr9d4uO3lJTNs6eP2suCVM= 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 v5 11/21] x86/paravirt: Use common code for paravirt_steal_clock() Date: Mon, 5 Jan 2026 12:05:10 +0100 Message-ID: <20260105110520.21356-12-jgross@suse.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260105110520.21356-1-jgross@suse.com> References: <20260105110520.21356-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.988]; MIME_GOOD(-0.10)[text/plain]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,infradead.org:email,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)[17]; 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-Level: X-Spam-Flag: NO X-Spam-Score: -6.80 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 1f30358dfecd..62e11572da27 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -799,6 +799,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 Mon Jan 05 11:06:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 11:06:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195182.1513173 (Exim 4.92) (envelope-from ) id 1vciQ7-0005Xx-Jf; Mon, 05 Jan 2026 11:06:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195182.1513173; Mon, 05 Jan 2026 11:06:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vciQ7-0005Xq-GN; Mon, 05 Jan 2026 11:06:43 +0000 Received: by outflank-mailman (input) for mailman id 1195182; Mon, 05 Jan 2026 11:06:42 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vciQ6-0003bi-KA for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 11:06:42 +0000 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9bd5d03e-ea26-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 12:06:39 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 2B25F336E8; Mon, 5 Jan 2026 11:06: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 66B9B13964; Mon, 5 Jan 2026 11:06:38 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 3MN7Fz6bW2k+WgAAD6G6ig (envelope-from ); Mon, 05 Jan 2026 11:06: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: 9bd5d03e-ea26-11f0-9ccf-f158ae23cfc8 Authentication-Results: smtp-out1.suse.de; none 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 , Long Li , Daniel Lezcano , xen-devel@lists.xenproject.org, "Peter Zijlstra (Intel)" Subject: [PATCH v5 12/21] x86/paravirt: Move paravirt_sched_clock() related code into tsc.c Date: Mon, 5 Jan 2026 12:05:11 +0100 Message-ID: <20260105110520.21356-13-jgross@suse.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260105110520.21356-1-jgross@suse.com> References: <20260105110520.21356-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[]; R_RATELIMIT(0.00)[to_ip_from(RLkdkdrsxe9hqhhs5ask8616i6)] X-Rspamd-Queue-Id: 2B25F336E8 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spam-Score: -4.00 X-Spam-Level: X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Spam-Flag: NO X-Rspamd-Action: no action 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 7d3e13e14eab..d5d0b500d13e 100644 --- a/arch/x86/kernel/tsc.c +++ b/arch/x86/kernel/tsc.c @@ -267,19 +267,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 10356d4ec55c..e9f5034a1bc8 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 Mon Jan 05 11:07:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 11:07:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195194.1513188 (Exim 4.92) (envelope-from ) id 1vciQl-0006Rt-4S; Mon, 05 Jan 2026 11:07:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195194.1513188; Mon, 05 Jan 2026 11:07: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 1vciQk-0006RC-VP; Mon, 05 Jan 2026 11:07:22 +0000 Received: by outflank-mailman (input) for mailman id 1195194; Mon, 05 Jan 2026 11:07:21 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vciQS-0003bi-LB for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 11:07:04 +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 a9add913-ea26-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 12:07:02 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 65687336E8; Mon, 5 Jan 2026 11:07:02 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 059B83EA63; Mon, 5 Jan 2026 11:07:01 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 0zRyO1WbW2lZWgAAD6G6ig (envelope-from ); Mon, 05 Jan 2026 11:07:01 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a9add913-ea26-11f0-9ccf-f158ae23cfc8 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 v5 16/21] x86/xen: Drop xen_cpu_ops Date: Mon, 5 Jan 2026 12:05:15 +0100 Message-ID: <20260105110520.21356-17-jgross@suse.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260105110520.21356-1-jgross@suse.com> References: <20260105110520.21356-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[] X-Rspamd-Queue-Id: 65687336E8 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spam-Score: -4.00 X-Spam-Level: X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Spam-Flag: NO X-Rspamd-Action: no action Instead of having a pre-filled array xen_cpu_ops for Xen PV paravirt functions, drop the array and assign each element individually. This is in preparation of reducing the paravirt include hell by splitting paravirt.h into multiple more fine grained header files, which will in turn require to split up the pv_ops vector as well. Dropping the pre-filled array makes life easier for objtool to detect missing initializers in multiple pv_ops_ arrays. Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky --- 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 b74ff8bc7f2a..8a19a88190ee 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -1212,54 +1212,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 0c32a92dc693..8ab88f2b2c1b 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -570,7 +570,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 Mon Jan 05 11:07:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 11:07:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195193.1513183 (Exim 4.92) (envelope-from ) id 1vciQk-0006Pk-RU; Mon, 05 Jan 2026 11:07:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195193.1513183; Mon, 05 Jan 2026 11:07:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vciQk-0006Pd-OM; Mon, 05 Jan 2026 11:07:22 +0000 Received: by outflank-mailman (input) for mailman id 1195193; Mon, 05 Jan 2026 11:07:21 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vciQX-0003bi-WF for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 11:07:10 +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 ad2074c1-ea26-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 12:07:08 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 31BC85BE37; Mon, 5 Jan 2026 11:07: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 C8E743EA63; Mon, 5 Jan 2026 11:07: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 L7x+L1ubW2lgWgAAD6G6ig (envelope-from ); Mon, 05 Jan 2026 11:07: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: ad2074c1-ea26-11f0-9ccf-f158ae23cfc8 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 v5 17/21] x86/xen: Drop xen_mmu_ops Date: Mon, 5 Jan 2026 12:05:16 +0100 Message-ID: <20260105110520.21356-18-jgross@suse.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260105110520.21356-1-jgross@suse.com> References: <20260105110520.21356-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[] X-Spam-Flag: NO X-Spam-Score: -4.00 X-Rspamd-Queue-Id: 31BC85BE37 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Rspamd-Action: no action X-Spam-Level: Instead of having a pre-filled array xen_mmu_ops for Xen PV paravirt functions, drop the array and assign each element individually. This is in preparation of reducing the paravirt include hell by splitting paravirt.h into multiple more fine grained header files, which will in turn require to split up the pv_ops vector as well. Dropping the pre-filled array makes life easier for objtool to detect missing initializers in multiple pv_ops_ arrays. Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky --- 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 8ab88f2b2c1b..61f3e0c48fcc 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -570,7 +570,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 Mon Jan 05 11:07:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 11:07:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195199.1513203 (Exim 4.92) (envelope-from ) id 1vciQo-0006vm-D7; Mon, 05 Jan 2026 11:07:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195199.1513203; Mon, 05 Jan 2026 11:07: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 1vciQo-0006vZ-9j; Mon, 05 Jan 2026 11:07:26 +0000 Received: by outflank-mailman (input) for mailman id 1195199; Mon, 05 Jan 2026 11:07: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 1vciQM-0003LR-91 for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 11:06:58 +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 a6562cfd-ea26-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 12:06:57 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 9172A3371A; Mon, 5 Jan 2026 11:06:56 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 28DB53EA63; Mon, 5 Jan 2026 11:06:56 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 3DtICFCbW2lVWgAAD6G6ig (envelope-from ); Mon, 05 Jan 2026 11:06: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: a6562cfd-ea26-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1767611216; 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=yxeYozxB3y3glk17EJVmmk2QBVB9KFdsuEkufVyAx4A=; b=SmIcCakSwxMgJy19BiigeL4XfZFX9ELM4tAqgozKfHw320myllYlRTIf6Odojy9Wuxn5ij JLLLjztRIqETlMXpFJwr+mjf02O3D6W3sCalbfzCb/MCz0FToXL5+lnBdnxkRtQzjlVlsm I1ypAILC8amK1ydjtaN+b7drJHrpYPw= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1767611216; 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=yxeYozxB3y3glk17EJVmmk2QBVB9KFdsuEkufVyAx4A=; b=SmIcCakSwxMgJy19BiigeL4XfZFX9ELM4tAqgozKfHw320myllYlRTIf6Odojy9Wuxn5ij JLLLjztRIqETlMXpFJwr+mjf02O3D6W3sCalbfzCb/MCz0FToXL5+lnBdnxkRtQzjlVlsm I1ypAILC8amK1ydjtaN+b7drJHrpYPw= 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 v5 15/21] x86/xen: Drop xen_irq_ops Date: Mon, 5 Jan 2026 12:05:14 +0100 Message-ID: <20260105110520.21356-16-jgross@suse.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260105110520.21356-1-jgross@suse.com> References: <20260105110520.21356-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.988]; MIME_GOOD(-0.10)[text/plain]; DBL_BLOCKED_OPENRESOLVER(0.00)[oracle.com:email,imap1.dmz-prg2.suse.org:helo,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)[12]; 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-Level: X-Spam-Flag: NO X-Spam-Score: -6.80 Instead of having a pre-filled array xen_irq_ops for Xen PV paravirt functions, drop the array and assign each element individually. This is in preparation of reducing the paravirt include hell by splitting paravirt.h into multiple more fine grained header files, which will in turn require to split up the pv_ops vector as well. Dropping the pre-filled array makes life easier for objtool to detect missing initializers in multiple pv_ops_ arrays. Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky --- 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 3f7999317f4d..0c32a92dc693 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -571,7 +571,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 Mon Jan 05 11:17:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 11:17:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195222.1513214 (Exim 4.92) (envelope-from ) id 1vciaY-0000x1-9l; Mon, 05 Jan 2026 11:17:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195222.1513214; Mon, 05 Jan 2026 11:17: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 1vciaY-0000wu-5w; Mon, 05 Jan 2026 11:17:30 +0000 Received: by outflank-mailman (input) for mailman id 1195222; Mon, 05 Jan 2026 11:17: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 1vciQw-0003bi-1g for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 11:07: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 bb4b1cc3-ea26-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 12:07:32 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id D75DC336E8; Mon, 5 Jan 2026 11:07:31 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 22DFC3EA63; Mon, 5 Jan 2026 11:07: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 3hfuBnObW2l4WgAAD6G6ig (envelope-from ); Mon, 05 Jan 2026 11:07: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: bb4b1cc3-ea26-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1767611251; 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=m2x+DB8IEEuPPYlyN3XtHvE/Gv0XnNAceoEiDGJY84Y=; b=lptGcwlJAhmpQwpbJbGlZEEbxPHbmEqaetuxTliZGcL+EeP6UwoeE7uCOCBIOYcgAZDE+q TlwgnBovt2zCJGCtwhx3Rd0G6JkBksvJ9JQGvl+Do0+zmoUJ2UDzZeGlSHj/sTY6VL3ifC jAKqXxZcIfJvvRDAMHWSSQd2QToob/k= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1767611251; 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=m2x+DB8IEEuPPYlyN3XtHvE/Gv0XnNAceoEiDGJY84Y=; b=lptGcwlJAhmpQwpbJbGlZEEbxPHbmEqaetuxTliZGcL+EeP6UwoeE7uCOCBIOYcgAZDE+q TlwgnBovt2zCJGCtwhx3Rd0G6JkBksvJ9JQGvl+Do0+zmoUJ2UDzZeGlSHj/sTY6VL3ifC jAKqXxZcIfJvvRDAMHWSSQd2QToob/k= 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 , Long Li , 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 v5 21/21] x86/pvlocks: Move paravirt spinlock functions into own header Date: Mon, 5 Jan 2026 12:05:20 +0100 Message-ID: <20260105110520.21356-22-jgross@suse.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260105110520.21356-1-jgross@suse.com> References: <20260105110520.21356-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Flag: NO X-Spam-Score: -6.80 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.989]; 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)[25]; 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)[] 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 V3: - hide native_pv_lock_init() with CONFIG_SMP (kernel test robot) V4: - don't reference pv_ops_lock without CONFIG_PARAVIRT_SPINLOCKS (kernel test robot) V5: - move paravirt_set_cap() declaration into paravirt-base.h (kernel test robot) --- arch/x86/hyperv/hv_spinlock.c | 10 +- arch/x86/include/asm/paravirt-base.h | 6 + arch/x86/include/asm/paravirt-spinlock.h | 145 +++++++++++++++++++++++ arch/x86/include/asm/paravirt.h | 61 ---------- arch/x86/include/asm/paravirt_types.h | 17 --- arch/x86/include/asm/qspinlock.h | 87 +------------- arch/x86/kernel/Makefile | 2 +- arch/x86/kernel/kvm.c | 12 +- arch/x86/kernel/paravirt-spinlocks.c | 26 +++- arch/x86/kernel/paravirt.c | 21 ---- arch/x86/xen/spinlock.c | 10 +- tools/objtool/check.c | 1 + 12 files changed, 198 insertions(+), 200 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-base.h b/arch/x86/include/asm/paravirt-base.h index 3827ea20de18..982a0b93bc76 100644 --- a/arch/x86/include/asm/paravirt-base.h +++ b/arch/x86/include/asm/paravirt-base.h @@ -26,4 +26,10 @@ u64 _paravirt_ident_64(u64); #endif #define paravirt_nop ((void *)nop_func) +#ifdef CONFIG_PARAVIRT_SPINLOCKS +void paravirt_set_cap(void); +#else +static inline void paravirt_set_cap(void) { } +#endif + #endif /* _ASM_X86_PARAVIRT_BASE_H */ diff --git a/arch/x86/include/asm/paravirt-spinlock.h b/arch/x86/include/asm/paravirt-spinlock.h new file mode 100644 index 000000000000..a5011ef3a6cc --- /dev/null +++ b/arch/x86/include/asm/paravirt-spinlock.h @@ -0,0 +1,145 @@ +/* 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 +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 b36d425d099b..7ccd41628d36 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..25a1919542d9 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,90 +30,10 @@ 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 +static inline void native_pv_lock_init(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 */ - #include #endif /* _ASM_X86_QSPINLOCK_H */ diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index bc184dd38d99..e9aeeeafad17 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 21b4de55f823..de550b12d9ab 100644 --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -829,8 +829,10 @@ 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 = +#ifdef CONFIG_PARAVIRT_SPINLOCKS + pv_ops_lock.vcpu_is_preempted = PV_CALLEE_SAVE(__kvm_vcpu_is_preempted); +#endif } if (kvm_para_has_feature(KVM_FEATURE_PV_EOI)) @@ -1126,11 +1128,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..95452444868f 100644 --- a/arch/x86/kernel/paravirt-spinlocks.c +++ b/arch/x86/kernel/paravirt-spinlocks.c @@ -3,12 +3,22 @@ * 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); +#ifdef CONFIG_SMP +void __init native_pv_lock_init(void) +{ + if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) + static_branch_enable(&virt_spin_lock_key); +} +#endif + +#ifdef CONFIG_PARAVIRT_SPINLOCKS __visible void __native_queued_spin_unlock(struct qspinlock *lock) { native_queued_spin_unlock(lock); @@ -17,7 +27,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 +39,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 +51,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 b3fec88d5bd3..c2952df6842c 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -527,6 +527,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 Mon Jan 05 11:35:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 11:35:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195264.1513233 (Exim 4.92) (envelope-from ) id 1vcisK-0004Ku-4R; Mon, 05 Jan 2026 11:35:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195264.1513233; Mon, 05 Jan 2026 11: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 1vcisK-0004Kn-1E; Mon, 05 Jan 2026 11:35:52 +0000 Received: by outflank-mailman (input) for mailman id 1195264; Mon, 05 Jan 2026 11: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 1vcisI-00047I-CF for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 11:35:50 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id af20ca6f-ea2a-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 12:35:49 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5593D497; Mon, 5 Jan 2026 03:35:42 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 12DBD3F5A1; Mon, 5 Jan 2026 03:35:47 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: af20ca6f-ea2a-11f0-b15e-2bf370ae4941 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Luca Fancellu , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Hari Limaye Subject: [PATCH v2 1/6] arm/mpu: Implement copy_from_paddr for MPU systems Date: Mon, 5 Jan 2026 11:34:58 +0000 Message-ID: <20260105113503.2674777-2-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260105113503.2674777-1-harry.ramsey@arm.com> References: <20260105113503.2674777-1-harry.ramsey@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Luca Fancellu Implement the function copy_from_paddr variant for MPU systems, using the map_pages_to_xen/destroy_xen_mappings to temporarily map the memory range to be copied. Signed-off-by: Luca Fancellu Signed-off-by: Hari Limaye Signed-off-by: Harry Ramsey Reviewed-by: default avatarMichal Orzel --- v2: - add Michal R-by --- xen/arch/arm/mpu/setup.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/mpu/setup.c b/xen/arch/arm/mpu/setup.c index 163573b932..ec264f54f2 100644 --- a/xen/arch/arm/mpu/setup.c +++ b/xen/arch/arm/mpu/setup.c @@ -91,7 +91,19 @@ void * __init early_fdt_map(paddr_t fdt_paddr) */ void __init copy_from_paddr(void *dst, paddr_t paddr, unsigned long len) { - BUG_ON("unimplemented"); + paddr_t start_pg = round_pgdown(paddr); + paddr_t end_pg = round_pgup(paddr + len); + unsigned long nr_mfns = (end_pg - start_pg) >> PAGE_SHIFT; + mfn_t mfn = maddr_to_mfn(start_pg); + + if ( map_pages_to_xen(start_pg, mfn, nr_mfns, PAGE_HYPERVISOR_WC) ) + panic("Unable to map range for copy_from_paddr\n"); + + memcpy(dst, maddr_to_virt(paddr), len); + clean_dcache_va_range(dst, len); + + if ( destroy_xen_mappings(start_pg, end_pg) ) + panic("Unable to unmap range for copy_from_paddr\n"); } void __init remove_early_mappings(void) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Jan 05 11:35:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 11:35:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195263.1513222 (Exim 4.92) (envelope-from ) id 1vcisH-00047V-TV; Mon, 05 Jan 2026 11:35:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195263.1513222; Mon, 05 Jan 2026 11: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 1vcisH-00047O-QV; Mon, 05 Jan 2026 11:35:49 +0000 Received: by outflank-mailman (input) for mailman id 1195263; Mon, 05 Jan 2026 11:35: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 1vcisG-00047I-GR for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 11:35:48 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id ad2b40f7-ea2a-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 12:35:46 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E5E8E339; Mon, 5 Jan 2026 03:35:38 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D11563F5A1; Mon, 5 Jan 2026 03:35:44 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ad2b40f7-ea2a-11f0-b15e-2bf370ae4941 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v2 0/6] Fourth MPU Series Date: Mon, 5 Jan 2026 11:34:57 +0000 Message-ID: <20260105113503.2674777-1-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This series aims to further the ongoing work to introduce support for MPU systems in xen. The patches in this series implement various memory functions and enable the hypervisor timer. Luca Fancellu (3): arm/mpu: Implement copy_from_paddr for MPU systems arm/mpu: Implement vmap functions for MPU arm/mpu: Introduce modify_after_init_mappings Penny Zheng (3): arm/mpu: Implement free_init_memory for MPU systems arm: Use secure hypervisor timer in MPU system arm/mpu: Map domain page in AArch64 MPU systems xen/arch/arm/Kconfig | 1 + xen/arch/arm/include/asm/arm64/sysregs.h | 11 ++ xen/arch/arm/include/asm/mpu/mm.h | 16 +- xen/arch/arm/include/asm/setup.h | 5 + xen/arch/arm/mmu/setup.c | 15 ++ xen/arch/arm/mpu/Makefile | 1 + xen/arch/arm/mpu/domain-page.c | 53 +++++++ xen/arch/arm/mpu/mm.c | 189 ++++++++++++++++++----- xen/arch/arm/mpu/setup.c | 54 ++++++- xen/arch/arm/mpu/vmap.c | 14 +- xen/arch/arm/setup.c | 15 +- 11 files changed, 318 insertions(+), 56 deletions(-) create mode 100644 xen/arch/arm/mpu/domain-page.c -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Jan 05 11:35:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 11:35:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195265.1513243 (Exim 4.92) (envelope-from ) id 1vcisN-0004aE-AS; Mon, 05 Jan 2026 11:35:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195265.1513243; Mon, 05 Jan 2026 11:35: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 1vcisN-0004Zy-7X; Mon, 05 Jan 2026 11:35:55 +0000 Received: by outflank-mailman (input) for mailman id 1195265; Mon, 05 Jan 2026 11: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 1vcisL-0004YP-Gt for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 11:35:53 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id afe15c3e-ea2a-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 12:35:51 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9AB03339; Mon, 5 Jan 2026 03:35:43 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6F6E13F5A1; Mon, 5 Jan 2026 03:35:49 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: afe15c3e-ea2a-11f0-9ccf-f158ae23cfc8 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Luca Fancellu , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v2 2/6] arm/mpu: Implement vmap functions for MPU Date: Mon, 5 Jan 2026 11:34:59 +0000 Message-ID: <20260105113503.2674777-3-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260105113503.2674777-1-harry.ramsey@arm.com> References: <20260105113503.2674777-1-harry.ramsey@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Luca Fancellu HAS_VMAP is not enabled on MPU systems, but the vmap functions are used in places across common code. In order to keep the existing code and maintain correct functionality, implement the `vmap_contig` and `vunmap` functions for MPU systems. Introduce a helper function `destroy_xen_mapping_containing` to aid with unmapping an entire region when only the start address is known. Signed-off-by: Luca Fancellu Signed-off-by: Harry Ramsey --- v2: - Rename `destroy_entire_xen_mapping` to `destroy_xen_mapping_containing` - Improve code documentation. - Refactor nested code. - Fix ignored rc error code in `destroy_xen_mapping_containing`. --- xen/arch/arm/include/asm/mpu/mm.h | 10 +++++ xen/arch/arm/mpu/mm.c | 74 ++++++++++++++++++++++++++----- xen/arch/arm/mpu/vmap.c | 14 ++++-- 3 files changed, 83 insertions(+), 15 deletions(-) diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h index e1ded6521d..1b5ffa5b64 100644 --- a/xen/arch/arm/include/asm/mpu/mm.h +++ b/xen/arch/arm/include/asm/mpu/mm.h @@ -111,6 +111,16 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags); int mpumap_contains_region(pr_t *table, uint8_t nr_regions, paddr_t base, paddr_t limit, uint8_t *index); + +/* + * Destroys and frees (if reference count is 0) an entire xen mapping on MPU + * systems where only the start address is known. + * + * @param s Start address of memory region to be destroyed. + * @return: 0 on success, negative on error. + */ +int destroy_xen_mapping_containing(paddr_t s); + #endif /* __ARM_MPU_MM_H__ */ /* diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c index 687dec3bc6..207e8d2d91 100644 --- a/xen/arch/arm/mpu/mm.c +++ b/xen/arch/arm/mpu/mm.c @@ -290,6 +290,42 @@ static void disable_mpu_region_from_index(uint8_t index) write_protection_region(&xen_mpumap[index], index); } +/* + * Free a xen_mpumap entry given the index. A mpu region is actually disabled + * when the refcount is 0 and the region type is MPUMAP_REGION_FOUND. + * + * @param idx Index of the mpumap entry. + * @param region_found_type MPUMAP_REGION_* value. + * @return 0 on success, otherwise negative on error. + */ +static int xen_mpumap_free_entry(uint8_t idx, int region_found_type) +{ + ASSERT(spin_is_locked(&xen_mpumap_lock)); + ASSERT(idx != INVALID_REGION_IDX); + + if ( MPUMAP_REGION_OVERLAP == region_found_type ) + { + printk(XENLOG_ERR "Cannot remove an overlapping region\n"); + return -EINVAL; + } + + if ( xen_mpumap[idx].refcount ) + { + xen_mpumap[idx].refcount -= 1; + return 0; + } + + if ( MPUMAP_REGION_FOUND == region_found_type ) + disable_mpu_region_from_index(idx); + else + { + printk(XENLOG_ERR "Cannot remove a partial region\n"); + return -EINVAL; + } + + return 0; +} + /* * Update the entry in the MPU memory region mapping table (xen_mpumap) for the * given memory range and flags, creating one if none exists. @@ -357,18 +393,7 @@ static int xen_mpumap_update_entry(paddr_t base, paddr_t limit, return -EINVAL; } - if ( xen_mpumap[idx].refcount == 0 ) - { - if ( MPUMAP_REGION_FOUND == rc ) - disable_mpu_region_from_index(idx); - else - { - printk("Cannot remove a partial region\n"); - return -EINVAL; - } - } - else - xen_mpumap[idx].refcount -= 1; + return xen_mpumap_free_entry(idx, rc); } return 0; @@ -418,6 +443,31 @@ int destroy_xen_mappings(unsigned long s, unsigned long e) return xen_mpumap_update(s, e, 0); } +int destroy_xen_mapping_containing(paddr_t s) +{ + int rc; + uint8_t idx; + + ASSERT(IS_ALIGNED(s, PAGE_SIZE)); + + spin_lock(&xen_mpumap_lock); + + rc = mpumap_contains_region(xen_mpumap, max_mpu_regions, s, s + PAGE_SIZE, + &idx); + if ( rc == MPUMAP_REGION_NOTFOUND ) + { + printk(XENLOG_ERR "Cannot remove entry that does not exist"); + return -EINVAL; + } + + /* As we are unmapping entire region use MPUMAP_REGION_FOUND instead */ + rc = xen_mpumap_free_entry(idx, MPUMAP_REGION_FOUND); + + spin_unlock(&xen_mpumap_lock); + + return rc; +} + int map_pages_to_xen(unsigned long virt, mfn_t mfn, unsigned long nr_mfns, unsigned int flags) { diff --git a/xen/arch/arm/mpu/vmap.c b/xen/arch/arm/mpu/vmap.c index f977b79cd4..54d949e7ce 100644 --- a/xen/arch/arm/mpu/vmap.c +++ b/xen/arch/arm/mpu/vmap.c @@ -1,19 +1,27 @@ /* SPDX-License-Identifier: GPL-2.0-only */ #include +#include #include #include #include void *vmap_contig(mfn_t mfn, unsigned int nr) { - BUG_ON("unimplemented"); - return NULL; + paddr_t base = mfn_to_maddr(mfn); + + if ( map_pages_to_xen(base, mfn, nr, PAGE_HYPERVISOR ) ) + return NULL; + + return maddr_to_virt(base); } void vunmap(const void *va) { - BUG_ON("unimplemented"); + paddr_t base = virt_to_maddr(va); + + if ( destroy_xen_mapping_containing(base) ) + panic("Failed to vunmap region\n"); } /* -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Jan 05 11:35:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 11:35:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195266.1513249 (Exim 4.92) (envelope-from ) id 1vcisN-0004cj-KU; Mon, 05 Jan 2026 11:35:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195266.1513249; Mon, 05 Jan 2026 11:35: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 1vcisN-0004bm-Dn; Mon, 05 Jan 2026 11:35:55 +0000 Received: by outflank-mailman (input) for mailman id 1195266; Mon, 05 Jan 2026 11:35: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 1vcisL-00047I-Oq for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 11:35:53 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id b0f8bc5c-ea2a-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 12:35:53 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4DCEB497; Mon, 5 Jan 2026 03:35:45 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B24C83F5A1; Mon, 5 Jan 2026 03:35:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b0f8bc5c-ea2a-11f0-b15e-2bf370ae4941 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Penny Zheng , Wei Chen , Luca Fancellu , Hari Limaye Subject: [PATCH v2 3/6] arm/mpu: Implement free_init_memory for MPU systems Date: Mon, 5 Jan 2026 11:35:00 +0000 Message-ID: <20260105113503.2674777-4-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260105113503.2674777-1-harry.ramsey@arm.com> References: <20260105113503.2674777-1-harry.ramsey@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Penny Zheng Implement the function `free_init_memory` for MPU systems. In order to support this, the function `modify_xen_mappings` is implemented. On MPU systems, we map the init text and init data sections using separate MPU memory regions. Therefore these are removed separately in `free_init_memory`. Additionally remove warning messages from `is_mm_attr_match` as some permissions can now be updated by `xen_mpumap_update_entry`. Signed-off-by: Penny Zheng Signed-off-by: Wei Chen Signed-off-by: Luca Fancellu Signed-off-by: Hari Limaye Signed-off-by: Harry Ramsey --- v2: - Refactor `is_mm_attr_match` to return logical values regarding the permission mismatch. - Improve code documentation. --- xen/arch/arm/include/asm/mpu/mm.h | 6 +- xen/arch/arm/include/asm/setup.h | 2 + xen/arch/arm/mpu/mm.c | 113 +++++++++++++++++++++++------- 3 files changed, 95 insertions(+), 26 deletions(-) diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h index 1b5ffa5b64..f0941de295 100644 --- a/xen/arch/arm/include/asm/mpu/mm.h +++ b/xen/arch/arm/include/asm/mpu/mm.h @@ -15,7 +15,11 @@ #define MPUMAP_REGION_FOUND 1 #define MPUMAP_REGION_INCLUSIVE 2 -#define INVALID_REGION_IDX 0xFFU +#define MPU_ATTR_RO_MISMATCH -1 +#define MPU_ATTR_XN_MISMATCH -2 +#define MPU_ATTR_AI_MISMATCH -3 + +#define INVALID_REGION_IDX 0xFFU extern struct page_info *frame_table; diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h index 1eaf13bd66..005cf7be59 100644 --- a/xen/arch/arm/include/asm/setup.h +++ b/xen/arch/arm/include/asm/setup.h @@ -65,6 +65,8 @@ int map_irq_to_domain(struct domain *d, unsigned int irq, int map_range_to_domain(const struct dt_device_node *dev, uint64_t addr, uint64_t len, void *data); +extern const char __init_data_begin[], __bss_start[], __bss_end[]; + struct init_info { /* Pointer to the stack, used by head.S when entering in C */ diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c index 207e8d2d91..4194d4fefd 100644 --- a/xen/arch/arm/mpu/mm.c +++ b/xen/arch/arm/mpu/mm.c @@ -171,33 +171,18 @@ int mpumap_contains_region(pr_t *table, uint8_t nr_regions, paddr_t base, return MPUMAP_REGION_NOTFOUND; } -static bool is_mm_attr_match(pr_t *region, unsigned int attributes) +static int is_mm_attr_match(pr_t *region, unsigned int attributes) { if ( region->prbar.reg.ro != PAGE_RO_MASK(attributes) ) - { - printk(XENLOG_WARNING - "Mismatched Access Permission attributes (%#x instead of %#x)\n", - region->prbar.reg.ro, PAGE_RO_MASK(attributes)); - return false; - } + return MPU_ATTR_RO_MISMATCH; if ( region->prbar.reg.xn != PAGE_XN_MASK(attributes) ) - { - printk(XENLOG_WARNING - "Mismatched Execute Never attributes (%#x instead of %#x)\n", - region->prbar.reg.xn, PAGE_XN_MASK(attributes)); - return false; - } + return MPU_ATTR_XN_MISMATCH; if ( region->prlar.reg.ai != PAGE_AI_MASK(attributes) ) - { - printk(XENLOG_WARNING - "Mismatched Memory Attribute Index (%#x instead of %#x)\n", - region->prlar.reg.ai, PAGE_AI_MASK(attributes)); - return false; - } + return MPU_ATTR_AI_MISMATCH; - return true; + return 0; } /* Map a frame table to cover physical addresses ps through pe */ @@ -357,12 +342,45 @@ static int xen_mpumap_update_entry(paddr_t base, paddr_t limit, */ if ( flags_has_page_present && (rc >= MPUMAP_REGION_FOUND) ) { - if ( !is_mm_attr_match(&xen_mpumap[idx], flags) ) + int attr_match = is_mm_attr_match(&xen_mpumap[idx], flags); + + /* We do not support modifying AI attribute. */ + if ( MPU_ATTR_AI_MISMATCH == attr_match ) { - printk("Modifying an existing entry is not supported\n"); + printk(XENLOG_ERR + "Modifying memory attribute is not supported\n"); return -EINVAL; } + /* + * Permissions RO and XN can be changed only by the full region. + * Permissions that match can continue and just increment refcount. + */ + if ( MPU_ATTR_RO_MISMATCH == attr_match || + MPU_ATTR_XN_MISMATCH == attr_match ) + { + if ( rc == MPUMAP_REGION_INCLUSIVE ) + { + printk(XENLOG_ERR + "Cannot modify partial region permissions\n"); + return -EINVAL; + } + + if ( xen_mpumap[idx].refcount != 0 ) + { + printk(XENLOG_ERR + "Cannot modify memory permissions for a region mapped multiple times\n"); + return -EINVAL; + } + + /* Set new permission */ + xen_mpumap[idx].prbar.reg.ro = PAGE_RO_MASK(flags); + xen_mpumap[idx].prbar.reg.xn = PAGE_XN_MASK(flags); + + write_protection_region(&xen_mpumap[idx], idx); + return 0; + } + /* Check for overflow of refcount before incrementing. */ if ( xen_mpumap[idx].refcount == 0xFF ) { @@ -506,8 +524,7 @@ void __init setup_mm_helper(void) int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf) { - BUG_ON("unimplemented"); - return -EINVAL; + return xen_mpumap_update(s, e, nf); } void dump_hyp_walk(vaddr_t addr) @@ -518,7 +535,53 @@ void dump_hyp_walk(vaddr_t addr) /* Release all __init and __initdata ranges to be reused */ void free_init_memory(void) { - BUG_ON("unimplemented"); + unsigned long inittext_end = (unsigned long)__init_data_begin; + unsigned long len = __init_end - __init_begin; + uint8_t idx; + int rc; + + /* Modify inittext region to be read/write instead of read/execute. */ + rc = modify_xen_mappings((unsigned long)__init_begin, inittext_end, + PAGE_HYPERVISOR_RW); + if ( rc ) + panic("Unable to map RW the init text section (rc = %d)\n", rc); + + /* + * From now on, init will not be used for execution anymore, + * so nuke the instruction cache to remove entries related to init. + */ + invalidate_icache_local(); + + /* + * The initdata region already has read/write permissions so it can just be + * zeroed out. + */ + memset(__init_begin, 0, len); + + rc = destroy_xen_mappings((unsigned long)__init_begin, inittext_end); + if ( rc ) + panic("Unable to remove init text section (rc = %d)\n", rc); + + /* + * The initdata and bss sections are mapped using a single MPU region, so + * modify the start of this region to remove the initdata section. + */ + spin_lock(&xen_mpumap_lock); + + rc = mpumap_contains_region(xen_mpumap, max_mpu_regions, + (unsigned long)__init_data_begin, + (unsigned long)__bss_end, + &idx); + if ( rc < MPUMAP_REGION_FOUND ) + panic("Unable to find bss data section (rc = %d)\n", rc); + + /* bss data section is shrunk and now starts from __bss_start */ + pr_set_base(&xen_mpumap[idx], (unsigned long)__bss_start); + + write_protection_region(&xen_mpumap[idx], idx); + context_sync_mpu(); + + spin_unlock(&xen_mpumap_lock); } void __iomem *ioremap_attr(paddr_t start, size_t len, unsigned int flags) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Jan 05 11:35:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 11:35:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195267.1513254 (Exim 4.92) (envelope-from ) id 1vcisN-0004jy-Uv; Mon, 05 Jan 2026 11:35:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195267.1513254; Mon, 05 Jan 2026 11:35: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 1vcisN-0004hj-PI; Mon, 05 Jan 2026 11:35:55 +0000 Received: by outflank-mailman (input) for mailman id 1195267; Mon, 05 Jan 2026 11:35: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 1vcisN-00047I-2K for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 11:35:55 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id b1c18be3-ea2a-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 12:35:54 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AEF01339; Mon, 5 Jan 2026 03:35:46 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 68AD63F5A1; Mon, 5 Jan 2026 03:35:52 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b1c18be3-ea2a-11f0-b15e-2bf370ae4941 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Luca Fancellu , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Hari Limaye Subject: [PATCH v2 4/6] arm/mpu: Introduce modify_after_init_mappings Date: Mon, 5 Jan 2026 11:35:01 +0000 Message-ID: <20260105113503.2674777-5-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260105113503.2674777-1-harry.ramsey@arm.com> References: <20260105113503.2674777-1-harry.ramsey@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Luca Fancellu During `init_done`, Xen sets the permissions of all symbols marked with __ro_after_init to be read-only. This does not work on MPU systems at present because part-region modification is not supported. Therefore introduce the function `modify_after_init_mappings` for MMU and MPU, to handle the divergent approaches to setting permissions of __ro_after_init symbols. For MPU systems `modify_xen_mappings` will shrink the RW mapping on one side and extend the RO mapping on the other. This approach prevents wasting an additional region between RW and RO mappings. As the new function is marked with __init, it needs to be called before `free_init_memory`. Signed-off-by: Luca Fancellu Signed-off-by: Hari Limaye Signed-off-by: Harry Ramsey --- v2: - No changes --- xen/arch/arm/include/asm/setup.h | 3 +++ xen/arch/arm/mmu/setup.c | 15 ++++++++++++ xen/arch/arm/mpu/mm.c | 2 +- xen/arch/arm/mpu/setup.c | 40 ++++++++++++++++++++++++++++++++ xen/arch/arm/setup.c | 15 ++---------- 5 files changed, 61 insertions(+), 14 deletions(-) diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h index 005cf7be59..899e33925c 100644 --- a/xen/arch/arm/include/asm/setup.h +++ b/xen/arch/arm/include/asm/setup.h @@ -78,6 +78,9 @@ struct init_info paddr_t consider_modules(paddr_t s, paddr_t e, uint32_t size, paddr_t align, int first_mod); +/* Modify some mappings after the init is done */ +void modify_after_init_mappings(void); + #endif /* * Local variables: diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c index 9b874f8ab2..d042f73597 100644 --- a/xen/arch/arm/mmu/setup.c +++ b/xen/arch/arm/mmu/setup.c @@ -213,6 +213,21 @@ void __init remove_early_mappings(void) BUG_ON(rc); } +void __init modify_after_init_mappings(void) +{ + /* + * We have finished booting. Mark the section .data.ro_after_init + * read-only. + */ + int rc = modify_xen_mappings((unsigned long)&__ro_after_init_start, + (unsigned long)&__ro_after_init_end, + PAGE_HYPERVISOR_RO); + + if ( rc ) + panic("Unable to mark the .data.ro_after_init section read-only (rc = %d)\n", + rc); +} + /* * After boot, Xen page-tables should not contain mapping that are both * Writable and eXecutables. diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c index 4194d4fefd..7fc1658bb2 100644 --- a/xen/arch/arm/mpu/mm.c +++ b/xen/arch/arm/mpu/mm.c @@ -32,7 +32,7 @@ DECLARE_BITMAP(xen_mpumap_mask, MAX_MPU_REGION_NR) \ /* EL2 Xen MPU memory region mapping table. */ pr_t __cacheline_aligned __section(".data") xen_mpumap[MAX_MPU_REGION_NR]; -static DEFINE_SPINLOCK(xen_mpumap_lock); +DEFINE_SPINLOCK(xen_mpumap_lock); static void __init __maybe_unused build_assertions(void) { diff --git a/xen/arch/arm/mpu/setup.c b/xen/arch/arm/mpu/setup.c index ec264f54f2..55317ee318 100644 --- a/xen/arch/arm/mpu/setup.c +++ b/xen/arch/arm/mpu/setup.c @@ -8,11 +8,14 @@ #include #include #include +#include #include static paddr_t __initdata mapped_fdt_base = INVALID_PADDR; static paddr_t __initdata mapped_fdt_limit = INVALID_PADDR; +extern spinlock_t xen_mpumap_lock; + void __init setup_pagetables(void) {} void * __init early_fdt_map(paddr_t fdt_paddr) @@ -106,6 +109,43 @@ void __init copy_from_paddr(void *dst, paddr_t paddr, unsigned long len) panic("Unable to unmap range for copy_from_paddr\n"); } +void __init modify_after_init_mappings(void) +{ + int rc; + uint8_t idx_rodata; + uint8_t idx_rwdata; + + spin_lock(&xen_mpumap_lock); + + rc = mpumap_contains_region(xen_mpumap, max_mpu_regions, + (unsigned long)_srodata, + (unsigned long)_erodata, + &idx_rodata); + + if ( rc < MPUMAP_REGION_FOUND ) + panic("Unable to find rodata section (rc = %d)\n", rc); + + rc = mpumap_contains_region(xen_mpumap, max_mpu_regions, + (unsigned long)__ro_after_init_start, + (unsigned long)__init_begin, + &idx_rwdata); + + if ( rc < MPUMAP_REGION_FOUND ) + panic("Unable to find rwdata section (rc = %d)\n", rc); + + /* Shrink rwdata section to begin at __ro_after_init_end */ + pr_set_base(&xen_mpumap[idx_rwdata], (unsigned long)__ro_after_init_end); + + /* Extend rodata section to end at __ro_after_init_end */ + pr_set_limit(&xen_mpumap[idx_rodata], (unsigned long)__ro_after_init_end); + + write_protection_region(&xen_mpumap[idx_rwdata], idx_rwdata); + write_protection_region(&xen_mpumap[idx_rodata], idx_rodata); + context_sync_mpu(); + + spin_unlock(&xen_mpumap_lock); +} + void __init remove_early_mappings(void) { int rc = destroy_xen_mappings(round_pgdown(mapped_fdt_base), diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 7ad870e382..6310a47d68 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -66,23 +66,12 @@ domid_t __read_mostly max_init_domid; static __used void noreturn init_done(void) { - int rc; - /* Must be done past setting system_state. */ unregister_init_virtual_region(); - free_init_memory(); + modify_after_init_mappings(); - /* - * We have finished booting. Mark the section .data.ro_after_init - * read-only. - */ - rc = modify_xen_mappings((unsigned long)&__ro_after_init_start, - (unsigned long)&__ro_after_init_end, - PAGE_HYPERVISOR_RO); - if ( rc ) - panic("Unable to mark the .data.ro_after_init section read-only (rc = %d)\n", - rc); + free_init_memory(); startup_cpu_idle_loop(); } -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Jan 05 11:35:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 11:35:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195268.1513273 (Exim 4.92) (envelope-from ) id 1vcisP-0005Fw-F5; Mon, 05 Jan 2026 11:35:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195268.1513273; Mon, 05 Jan 2026 11: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 1vcisP-0005F9-8B; Mon, 05 Jan 2026 11:35:57 +0000 Received: by outflank-mailman (input) for mailman id 1195268; Mon, 05 Jan 2026 11: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 1vcisO-00047I-Bb for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 11:35:56 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id b2a8ba1d-ea2a-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 12:35:55 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 488CC497; Mon, 5 Jan 2026 03:35:48 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C65AF3F5A1; Mon, 5 Jan 2026 03:35:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b2a8ba1d-ea2a-11f0-b15e-2bf370ae4941 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Penny Zheng , Wei Chen , Luca Fancellu Subject: [PATCH v2 5/6] arm: Use secure hypervisor timer in MPU system Date: Mon, 5 Jan 2026 11:35:02 +0000 Message-ID: <20260105113503.2674777-6-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260105113503.2674777-1-harry.ramsey@arm.com> References: <20260105113503.2674777-1-harry.ramsey@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Penny Zheng As MPU systems only have one secure state, we have to use secure EL2 hypervisor timer for Xen in secure EL2. Signed-off-by: Penny Zheng Signed-off-by: Wei Chen Signed-off-by: Luca Fancellu Signed-off-by: Harry Ramsey --- v2: - Remove unncessary kconfig attribute. - Remove unncessary hypervisor timer macro. --- xen/arch/arm/include/asm/arm64/sysregs.h | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/include/asm/arm64/sysregs.h index 7dfd20414d..19d409d3eb 100644 --- a/xen/arch/arm/include/asm/arm64/sysregs.h +++ b/xen/arch/arm/include/asm/arm64/sysregs.h @@ -462,6 +462,17 @@ #define ZCR_ELx_LEN_SIZE 9 #define ZCR_ELx_LEN_MASK 0x1ff +#ifdef CONFIG_MPU +/* + * The Armv8-R AArch64 architecture always executes code in Secure + * state with EL2 as the highest exception level. + * + * Hypervisor timer registers for Secure EL2. + */ +#define CNTHP_CTL_EL2 CNTHPS_CTL_EL2 +#define CNTHP_CVAL_EL2 CNTHPS_CVAL_EL2 +#endif + #define REGION_TEXT_PRBAR 0x38 /* SH=11 AP=10 XN=00 */ #define REGION_RO_PRBAR 0x3A /* SH=11 AP=10 XN=10 */ #define REGION_DATA_PRBAR 0x32 /* SH=11 AP=00 XN=10 */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Jan 05 11:36:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 11:36:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195269.1513283 (Exim 4.92) (envelope-from ) id 1vcisS-0005dB-NZ; Mon, 05 Jan 2026 11:36:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195269.1513283; Mon, 05 Jan 2026 11: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 1vcisS-0005d1-Jq; Mon, 05 Jan 2026 11:36:00 +0000 Received: by outflank-mailman (input) for mailman id 1195269; Mon, 05 Jan 2026 11: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 1vcisQ-0004YP-Ty for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 11:35:58 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id b3955a49-ea2a-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 12:35:57 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DC96B339; Mon, 5 Jan 2026 03:35:49 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 633843F5A1; Mon, 5 Jan 2026 03:35:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b3955a49-ea2a-11f0-9ccf-f158ae23cfc8 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Penny Zheng , Wei Chen , Luca Fancellu Subject: [PATCH v2 6/6] arm/mpu: Map domain page in AArch64 MPU systems Date: Mon, 5 Jan 2026 11:35:03 +0000 Message-ID: <20260105113503.2674777-7-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260105113503.2674777-1-harry.ramsey@arm.com> References: <20260105113503.2674777-1-harry.ramsey@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Penny Zheng In MPU systems, we implement map_domain_page()/unmap_domain_page() through mapping the domain page with a MPU region on demand. Signed-off-by: Penny Zheng Signed-off-by: Wei Chen Signed-off-by: Luca Fancellu Signed-off-by: Harry Ramsey --- v2: - No changes --- xen/arch/arm/Kconfig | 1 + xen/arch/arm/mpu/Makefile | 1 + xen/arch/arm/mpu/domain-page.c | 53 ++++++++++++++++++++++++++++++++++ 3 files changed, 55 insertions(+) create mode 100644 xen/arch/arm/mpu/domain-page.c diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index cf6af68299..baa6c4cf15 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -91,6 +91,7 @@ config MMU config MPU bool "MPU" if UNSUPPORTED + select ARCH_MAP_DOMAIN_PAGE if ARM_64 select STATIC_MEMORY help Memory Protection Unit (MPU). Select if you plan to run Xen on ARMv8-R diff --git a/xen/arch/arm/mpu/Makefile b/xen/arch/arm/mpu/Makefile index 4963c8b550..940297af3f 100644 --- a/xen/arch/arm/mpu/Makefile +++ b/xen/arch/arm/mpu/Makefile @@ -1,5 +1,6 @@ obj-$(CONFIG_ARM_32) += arm32/ obj-$(CONFIG_ARM_64) += arm64/ +obj-$(CONFIG_ARM_64) += domain-page.o obj-y += mm.o obj-y += p2m.o obj-y += setup.init.o diff --git a/xen/arch/arm/mpu/domain-page.c b/xen/arch/arm/mpu/domain-page.c new file mode 100644 index 0000000000..1b43bf82a6 --- /dev/null +++ b/xen/arch/arm/mpu/domain-page.c @@ -0,0 +1,53 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include +#include +#include +#include +#include + +void *map_domain_page_global(mfn_t mfn) +{ + BUG_ON("unimplemented"); + return NULL; +} + +/* Map a page of domheap memory */ +void *map_domain_page(mfn_t mfn) +{ + paddr_t pa = mfn_to_maddr(mfn); + + if ( map_pages_to_xen((unsigned long)pa, mfn, 1, PAGE_HYPERVISOR_RW) ) + return NULL; + + return maddr_to_virt(pa); +} + +/* Release a mapping taken with map_domain_page() */ +void unmap_domain_page(const void *ptr) +{ + paddr_t base = virt_to_maddr(ptr); + + if ( destroy_xen_mapping_containing(base) ) + panic("Failed to unmap domain page\n"); +} + +mfn_t domain_page_map_to_mfn(const void *ptr) +{ + BUG_ON("unimplemented"); + return INVALID_MFN; +} + +void unmap_domain_page_global(const void *va) +{ + BUG_ON("unimplemented"); +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Jan 05 11:55:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 11:55:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195334.1513296 (Exim 4.92) (envelope-from ) id 1vcjAz-0001lw-7b; Mon, 05 Jan 2026 11:55:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195334.1513296; Mon, 05 Jan 2026 11:55: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 1vcjAz-0001lp-4x; Mon, 05 Jan 2026 11:55:09 +0000 Received: by outflank-mailman (input) for mailman id 1195334; Mon, 05 Jan 2026 11:55: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 1vcjAx-0001lV-RS for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 11:55:07 +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 5f6d2f90-ea2d-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 12:55:05 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS4PR03MB8448.namprd03.prod.outlook.com (2603:10b6:8:322::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Mon, 5 Jan 2026 11:55:02 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9478.004; Mon, 5 Jan 2026 11:55:02 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5f6d2f90-ea2d-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VuOwOtsuXPQERFjah0FRlEEfqUE1ulQiyKGNuAEiqPMRe25McDtZ1DwFFAwyeRVDKbl8jQAmnmrKrRG0W6kvpWpjp0Jr5LFb+LIWZvh1Z9lWbAci0bBpTWJKqsTk6fDuw/xeosFx0CoJf5F4vTJYvzcMKQolLZWs9EAaYQfhKc8OaYWp5Ce+k5dLZtK8CEhxz8QeiDhzCceZuPE02sXADZR78Nklh4CWaOvMl3MIwHu7JfJlZCRr7tHo1xdVrPqcCvT41z7pIMNMA+YlGjIbMLkve8UHTgAvIc5doKO7ZwsjbW98RE/mTXIDDeFCt4njLz1apcHIiArm4RB2ELEVPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TVSzjmRxUNtkuc29qu1eezjpn/C8hcGzXlOoQvcPSXg=; b=LBUeNDLDkMw6dC6jX/jQRufHij8E6EPv4xx/6SbseFOwNOHEea7pXBIU4kGYmgLLMe8qiUICe0pOEsYkk32vkzIFqvqUO0Pt8uLuUi4PWMVMf66/j0mIoqEFvGXJkcyelwqmg0gYbOZThBE/jSRCRGtd0bx4bm7eNNHoQisR8TtRFf/jzMeHeQp8ibU27PTzBKIMtK2penGKOakFhVwDWzDm3PbXlv6KwtjVYgaBrSBb/w4CCAKQue0q8ZHPtumPOEJxFbzBaSsbMm0cLs152WEqhuk3+DndUoE4La1F6tAHPfPa3OXMF/JzrMoZEznZCmI0RT6VV7lLj7m2avHl/g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TVSzjmRxUNtkuc29qu1eezjpn/C8hcGzXlOoQvcPSXg=; b=K21apxCnnuhWwlbwUEQ2RFQBo5xnZRlxs42FZ4SIjhA8llYIomrICczgCwcPwu04gzzl8MGq9N7mkPlpJzerLtHoLc/IT5NYRi/mcOjxOBdwoc1m9/FpOzHswVZUwS0kBE2339ZkpYaNdlAwpq4i4bDtHa/SaZ9wKNSKEz5fYjc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Mon, 5 Jan 2026 11:54:58 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , xen-devel@lists.xenproject.org, sstabellini@kernel.org, consulting@bugseng.com, Doug Goldstein , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [XEN PATCH] xen: rework deviation to address varargs MISRA violations To: Nicola Vetrini References: <24aefd91-18ef-4ac2-a1b2-6098aa31e716@citrix.com> <6a0d6249997997a1b152d860932f68bc@bugseng.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <6a0d6249997997a1b152d860932f68bc@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0128.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:193::7) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS4PR03MB8448:EE_ X-MS-Office365-Filtering-Correlation-Id: 2c552305-5478-438f-4e46-08de4c514245 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?cnROK3ptalFMNTBuNHBmZXlOOUZjOTNuUDhBdUJmaGJEbzVNKzg5MlFrSFNa?= =?utf-8?B?UnVzNVdtSk9jODFIcXNsUXE2MFFxWW5VZDhVbjQrVFpoOEkrN0NyMlQ4SzI1?= =?utf-8?B?eDhhSW1oT2hFVFZEWk8wTkhoQjdaYmU0aFVlenJaUHRTWU4xMURvMjYyMU1N?= =?utf-8?B?aUx0Wm9IQURlaGQ3OXdVUFZkMEt2YnR3L2pKaElaTUVydURLSWwrc1NMeVJa?= =?utf-8?B?YXBKUFhISjlRWEtlQ2RPR0p2ZlBzV2FjQ3hYU1hrNzVWM1BRdXlEWmhQd2Ro?= =?utf-8?B?N1R1b3VIdjcvSkNTSEFHR1MzMjFYbzlmZi8ySnJEeUZzL3l0ZmQvZ2xvQi9s?= =?utf-8?B?cmVYaUNrWjNCcmpwYTlYd01zZGljbjR0aFg0ci9qZXYyNWt6M3ZKWmt4RXh1?= =?utf-8?B?ZW1ua1R4eVlSQ1Zhb2I3NDVvUFFoc3Fxb0hxdlBKd3RMRjVBTTJOd2N5SnJo?= =?utf-8?B?NmFQRCthSDNXRTdndnpEUk12Q2NvTWlkZnZjMkRrNFRYOHRFZjhoalNlblJ0?= =?utf-8?B?QU5EdmtKYUNjYXRhK2JCL1hUS0pBcWRVUEZCSzVIc1p1aFlJVm1tRmNhRzFM?= =?utf-8?B?UmtRZXRueHozZkZYYUZwWmFpUSt0VnkwRTFqTE91SEhTT1ZwY25pdVVHRzJY?= =?utf-8?B?RGRTY1NVSlJLd2YzUEROMmZPMzhYaXRla1ZhQVNJL3p1M1pia2p3a0R6OElz?= =?utf-8?B?S1pub1hGRFZWOFJaTHJGYXVJc1U0ZTFGcnprV0dHcXdJWUFqWG52dHUxb2xM?= =?utf-8?B?SVB4bDlNSkJhYnZjSTNYTTRyZ2lVQkFNaTVTSmxDUVROdTk4QW1JWWd6ejVT?= =?utf-8?B?YStSQlNzc2IrZ29WeHlzTHRzalF5UlhsM2d0OFhkcUtaTEhrbkhRY0pJQ3hG?= =?utf-8?B?RGJrbW5pOURBUWV1a05IR3gzS1lUdDg3amVmT3o0Z3JtUmllRk1MNUc2YWxG?= =?utf-8?B?blZwUVJrd3lBOTNxdTloZXMrNU4yaUN3QmxpWGZSOXRjSCsvbFhpSTdNc1dP?= =?utf-8?B?WE9vRk1PK2lZSndiUUZMaCs4eEh4d25jdnRsdUYvTWxFWE1tdmpkNEFrNE92?= =?utf-8?B?YURuU1U0VytncmRnK3ZERnowZXRLMWYxdmllQkxQeHoyLzhMSFYyV3ltNVEv?= =?utf-8?B?U1dHL25zRXg1eG9UbXdDdGpjYXZLR2xxMDc0TkQ4aGYxM0liTFdBUWEvSTFR?= =?utf-8?B?QlFwLytFTktuYzRhcVBmUHM2bEV1cmt6eWo1bDc5VTdYd25YQVJMVHVMWFRW?= =?utf-8?B?NEFaMkJ6Y3daZW1sZWk4ckZhS3dMNnR3bUNkNTZ5ZVRuTXVRK2U1TnlLdWcr?= =?utf-8?B?WElaaFZnQlVqRWlGMWtqL1I0eXZRcUZpS2EvOVRKZXVXejRxQyszTGNNb3dF?= =?utf-8?B?T0RqcFUrNGxOZzJIYVY0K3QxWThua1c3SE82L0pvL3QvVGh4NEZNTXhXQVNE?= =?utf-8?B?MUszNlBqTXpOTXlNcTBLSm0vV29HSTN5L0VSMmNzSEhPSXM3QWlEeGhucGdr?= =?utf-8?B?c0VtekxYY1g2MFd3Y0FtSFFXWEF6c21WZDZXd3Q5aEZEOW14NXNxM1ZuY1l2?= =?utf-8?B?TGJ0Kzl2UGw0bTJsK1NvUXRFR090OGVKalhxMFR6LzIxenl4ZlI3TU9vUCtG?= =?utf-8?B?aTNPcWVBODFpYU9GY1UyeXdnZ2pqby82WXhvcVNFRUlPbzhhN3hpbExPYjBL?= =?utf-8?B?YTVOZlZRMDJyUUM2a0hJaXNSeitoRzROSktlbUFoRFlnV0hxTFl4bGhpSWVy?= =?utf-8?B?Q0QrYmt6RDN5QVFEem1CSGxQYy9JWFhWRytOVkNhUlZIMjJYM3p3b1M0UzNl?= =?utf-8?B?Ly9Ja056RDhoR0MrMnFpb01BdWJOWVJhMEVaUytUenk1Mys5Q1liREpqVTdq?= =?utf-8?B?aU05eTNJc0tZOG82TzFFYi8vc0hoc3h0ZXF6TGtwWUNvT3J0K2VjaTE3bnph?= =?utf-8?Q?+CVcbqS5T5b+i3gN9tToVTP9qO76UjmV?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RklkaEcxMW8xVmk4Tm9rWFR6MnNnN0ZoOVZLcUYwTytmYTh4RW9jNVBLM3o3?= =?utf-8?B?MlRYd0t6NVFIWVR1OW5nZ1lXb1BkSmtVZld4T1ZuRHpVUi9rVUJxWlNNcEJT?= =?utf-8?B?ZEIxbjNTbUI5NGdDb016dFpTRGhDeHg5a2JZTG1QVkN6bFF3cENYMkM1THM3?= =?utf-8?B?U29wUmdCeGV3cVZXL1ZkRVJ1WVdKa0RubVNNOUdzaVVyRW1RR1NmR0RzaHh3?= =?utf-8?B?RnlVV0tQUzZFcEY1d3VKVERPYWNuWjhxNGo0VHVSYUV1WHNoNkRJa2ZpVXEx?= =?utf-8?B?V0o4dGpweWh5ZlFUd3kvbG5hS2VBTldGRThvc280S0g0THJtK3oxaHhEaVNX?= =?utf-8?B?dVQwNUFFclg5cklTMzh2SEpPUjI0bWZYOWFiSVpuU21tbVlEZDNLK0dkVFIz?= =?utf-8?B?cFJWUENtcmlpcTZhb2NpbnJjaWtKc0gxdXhHd3BZTkQ3OWxGVENPeFNRSTJn?= =?utf-8?B?TTZCSW91YXRXTTdpS0NVQS83aU9jbDJUK09CQ3N0VUVpZ1pJbzVXQlVwNUZH?= =?utf-8?B?ck9UMU5MLzdmTDRIWlI4U0xWSlZjUC9ETXdiTDVPc1YvaUszdzZMWlZya0wx?= =?utf-8?B?dU1VSXNGenpzcnVaVWFGeU16TnM5V1g5OWZkSWVwN25Fbk9KZHNvd0NiRmFQ?= =?utf-8?B?RkZkTmZDcWtyUmYvRXp3Mm5uNGI5Smc5YWJ0N3NFSDBUT1VtbjlDZjkydlFy?= =?utf-8?B?VnpkZzRVMlZEbWdRam1SVE5QTDdDYVczUlE4SmtzbDU5S1VnV1lFZTBqMklw?= =?utf-8?B?Q2hMcy96UFh5TDdmZmMxdEJPa3pBdGU2elpMd09qV0wyN2tsSWNSN202WnJ0?= =?utf-8?B?ZXowMDJ0KzBmck8rbzdENTRxRWdsOG1OMTBreC9WUnlPU0EvRkwzVEFjR0Jr?= =?utf-8?B?OGhrS0pWaUUrazVDbmIvZzV5T2trNDdEU1kzdjBUZzdiMlJISHdsSmdOWVJz?= =?utf-8?B?czB0Y2czWWNOSEZ3MUZtTUF3YnZYRCtJUzduVUhLN1J3VnJZRnlHVjdac0ZT?= =?utf-8?B?eEwzcDFSc1d0S05KTndNdlo1MnNvRlhodUxlb1ZhRGxUcFgzUVBWOFlqMnc3?= =?utf-8?B?SjV6MnFOSWoybmFWc0VNb0RLSDNCZnpMZ2U5WmJKdFJzOVFBeGpSZU14cjYz?= =?utf-8?B?VTc0OThmd21EWENUa2V4OUVkbDlvT1NCUTBhc3R3N29lNW9oRTdiSGJPM3BI?= =?utf-8?B?MXRITVBJWFVDZnJqUFlnZFRjbzB3NzJMMDYxZ3lMaGJqNktQOXZLSmxDWmR6?= =?utf-8?B?N1ZGTUJaU09LeDZQYXNnTmloZGN3b0lINWo1TnFERXNpdWtNU3F2VUNWZ05q?= =?utf-8?B?QWR4dUhKcncvdTdkSVpnOUpvMTlBK3NKVThJc001b0N1SGMzNEdhV0lJeGZq?= =?utf-8?B?c3JrUHNJeDRuTHExSEVqdGdsQTZ0TG5BNzZJaXpEc1dkNlFBZnRUWDZ5Qkdn?= =?utf-8?B?OFB3dkZQNld4QlMwQjNZMXlxanFSYU5YYXZBZ3dQL1ZmUENRWWxPN3MxdU5n?= =?utf-8?B?czJjZ3JWTG81WTdHcG5ZanFDN2s4UVNucjJ5WFpEMytRQUMvY1ZLRWdCd1FK?= =?utf-8?B?b2dVengxd2kvYnJqa09SWGI0SDArU1NpaGRpbGF1Vy9aY21SejFMUmt1dVRv?= =?utf-8?B?VUNiSjJTUGNYOEFiQ3B2R1hhNlREWDVlQ3ZUV2RSb3JRQ2ZETy9zSXNqOHJX?= =?utf-8?B?dVJIQzlNclhJL1UyZ0pjZWJKbzhrQjFsaUovSGxzVGwva2txTEorL1pkOUxS?= =?utf-8?B?OVpXZk1Qb2dPYnlsb2NoRTRWN083Q3pUbVdKWTFGdTNUd29aVHpnYkpJWmM4?= =?utf-8?B?dW04Yzk4MzJucGxRSjdKOGtyWEtQNndSdVp4S0tiaEllaFgyQnFnQ1dVck5Z?= =?utf-8?B?QXpJMktWUytnZ3l3ZDVzZlNkOFNLV3Uxdks1ODRRRlltVGdyanBaL1VSL1kr?= =?utf-8?B?NzZSTk93emtHYWc2TW9iRWhTVXo1TjJhNHVIMXdkM3ZxNUw3K3Y4Uk83VUE1?= =?utf-8?B?SUY4WXZrU2hDdmJ5VTE0WEdkRXo2cUhBM05wa1hTNEZKY3phelZLYnRIb0pQ?= =?utf-8?B?bzFFTllDUVhwTXFKKzVENU9WbElDKzB5ZDdqcWFFdXZkUjk5QUJhK0k1aEY4?= =?utf-8?B?ampsUitlL2FOYm1YY3lsa2UyK1QzQVB4cVA1OEsvQzhobEU2dkpackQvTGFF?= =?utf-8?B?RFcrMWlvMHdBSlY0R1ptTmJtUXd2b0lTVk53cTNLd09QNS9QK3VFZk92cXI1?= =?utf-8?B?NkQ0Y0p0TlN0dW1DZmtldVVsSHVzSWV4THpBMDRVUzN1T2VYdktGUjlTUW1j?= =?utf-8?B?TW94UWZSc3JzblNxaDYvNkFBT1ZwcW9FT1NUWFJaUnRRcU9sNTdPUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2c552305-5478-438f-4e46-08de4c514245 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2026 11:55:02.1766 (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: shvYJl3Wyf+aqb06gQWUwFPd96JdNz3bN/SsDui4OXNMtjHT0kFn77p5jPRNpzfspQiXbZLb6vdI3QWzuQbfk2DRNMITDQrQgIihuCMipoI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR03MB8448 On 02/01/2026 11:53 am, Nicola Vetrini wrote: > On 2026-01-02 10:42, Andrew Cooper wrote: >> On 31/12/2025 11:22 am, Nicola Vetrini wrote: >>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl >>> b/automation/eclair_analysis/ECLAIR/deviations.ecl >>> index 219ba6993b90..7dee4a488d45 100644 >>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl >>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl >>> @@ -570,13 +570,11 @@ safe." >>>  # Series 17. >>>  # >>> >>> --doc_begin="printf()-like functions are allowed to use the variadic >>> features provided by stdarg.h." >>> --config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(^.*printk\\(.*\\)$)))"} >>> >>> --config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(^.*printf\\(.*\\)$)))"} >>> >>> --config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"} >>> >>> --config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"} >>> >>> --config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vprintk_common)&&kind(function))))"} >>> >>> --config=MC3A2.R17.1,macros+={hide , "^va_(arg|start|copy|end)$"} >>> +-doc_begin="printf()-like or scanf()-like functions are allowed to >>> use the variadic features provided by stdarg.h, >>> +provided that they are declared using the `format' attribute." >>> +-decl_selector+={format_attr, "property(format)"} >>> +-config=MC3A2.R17.1,reports+={deliberate, >>> "any_area(^.*va_list.*$&&context(ancestor_or_self(format_attr)))"} >>> +-config=MC3A2.R17.1,macros+={deliberate , "^va_(arg|start|copy|end)$"} >>>  -doc_end >>> >>>  -doc_begin="Not using the return value of a function does not >>> endanger safety if it coincides with an actual argument." >>> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst >>> index b3431ef24e26..584907b048ec 100644 >>> --- a/docs/misra/deviations.rst >>> +++ b/docs/misra/deviations.rst >>> @@ -570,8 +570,8 @@ Deviations related to MISRA C:2012 Rules: >>>       - Tagged as `deliberate` for ECLAIR. >>> >>>     * - R17.1 >>> -     - printf()-like functions  are allowed to use the variadic >>> features provided >>> -       by `stdarg.h`. >>> +     - printf()-like or scanf()-like functions are allowed to use >>> the variadic >>> +       features provided by `stdarg.h`. >>>       - Tagged as `deliberate` for ECLAIR. >> >> Much nicer.  But don't we want to repeat the part about >> __attribute__((format(...))) here?  After all, that is the justification >> of why it's safer than nothing. >> > > Ok, that would be more accurate for sure. I didn't do that to preserve > the original intention of the deviation, but they are practically > equivalent with the current codebase, so changing the text makes > little difference. I'll tweak that. I can adjust on commit, if you're happy?  Everything else is fine AFAICT. In fact, this fixes the x86_64-allcode complaint for vmcoreinfo_append_str() which is already annotated, and debugtrace_printk() too (not yet enabled in *-allcode). ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jan 05 12:25:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 12:25:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195363.1513306 (Exim 4.92) (envelope-from ) id 1vcjdc-0006NF-PJ; Mon, 05 Jan 2026 12:24:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195363.1513306; Mon, 05 Jan 2026 12: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 1vcjdc-0006N8-MS; Mon, 05 Jan 2026 12:24:44 +0000 Received: by outflank-mailman (input) for mailman id 1195363; Mon, 05 Jan 2026 12:24:43 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcjdb-0006Mx-Bq for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 12:24:43 +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 81e240b4-ea31-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 13:24:40 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-430f2ee2f00so6485566f8f.3 for ; Mon, 05 Jan 2026 04:24:40 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4324eaa08efsm100989410f8f.29.2026.01.05.04.24.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jan 2026 04:24:38 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 81e240b4-ea31-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1767615879; x=1768220679; 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=dF/48okZMvDl5o4Ue3bSiWkxn9CbY3LNREFlu8eqb0o=; b=aeIsjYp/ZbujhHMA35HWOUq+xmNZ67tbGcxp7Jt5CDok0MtrrVr1yvx+HdsQK++BoN 3MiCKDQbbjypNZIcZv7OMnLIt3t6jVfaBe7cC6mQuIkXZSIWcE7Bu2H3Ho2RrfesKbVZ hwUsiZrBREgSg7sQtNtxtglveWHXd5fnBYkGk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767615879; x=1768220679; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=dF/48okZMvDl5o4Ue3bSiWkxn9CbY3LNREFlu8eqb0o=; b=QGTRCSF4Pvhu1reBFA1szPTBF4gkGseJ0F3m4iqDG49HCslMsM8apeHum2xus0KXta Jkf4C2RziKSCtTZ7egHLBwN98HZquu0bKwdAya2teRa/yPoVrR9AjchznPOPJABKAVDA GNgvuJ7bau+xXqW12Sl4BxhqIp40PZzGaof2l+g0vwWY0UBBEH8y/Zloj2atrtDWcCo2 nSHBJhNmL3+KBApw66NhRw/+AyRCHNpEEag1G4gcEhR0zrdbz50w+fIEX6R3duHB22ae EwK00aZX9ezFmtP4uf+DTVgcRc95hNIrjso/lTCnqNFKTsNaCnuN+ZlyoAvDltd9G8J9 LeIw== X-Gm-Message-State: AOJu0YwicxlHNECapzdgKNfXN6P7Cq8oTk+ROT1f5Ds+i4uyeMq3GC1g nlo7MtGtS6BE/zJ6Eg3lWxyCa/6JgavqwU41rV30tGMihRhIVr5vSsKI6elHCkWI1OjqrUQQrUe 1kLLh X-Gm-Gg: AY/fxX5NGSXUB22Bcx5ACSLj/3cZaiiMAceZGISU589aK7y+jKOr9KpgmYgQ4+PgVon i+KAle/Dd090gQiHFQA7Xlr2mUUELUpSpMVci9f7p1c2pDn2duSd5O8q35JPTGjwTBlEFTLMGJ4 fHDLNe8EsC/buXT9osCH9SYxcYfS18ITl9v2u0+OcQkyLiuUE+cLD+OGC+NAYK623R9bHcdgB9D LqpsBHv0O3CKurjPG6rhJ3U5+GEBvz8c6LfNUXvrjabSn1KaWJx9m1MqZBhHI24LvII4DRMLcPQ Gn44E+8vBDfwWTDJKFxATxrJ0/QJv1iN1q8I0lMZKAmfPsbhkHwkd6XbdNC7N32clT/WUsMoh6q /bF4wo/qPeuEno4LCSp3VGAxOrnGlD8Fm0F/rpf45Rwn/83Do4ykVUxtiWDAs1Cr2c5K295nGwQ qzCnZiuFVe8WsVT2UVAy3b815RH31Yfy6OVzsOUM+SeM1K2LEaG0sriPLXts+6kA== X-Google-Smtp-Source: AGHT+IFIqdxg7o4PK24Anp1jrtIbVfLvpHwzqAbxxmfwYf5T8jcxdhj16al95MKHB34tw35sLdqxAQ== X-Received: by 2002:a05:6000:2909:b0:42b:55a1:214c with SMTP id ffacd0b85a97d-4324e709a9dmr53182310f8f.55.1767615879346; Mon, 05 Jan 2026 04:24:39 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Stefano Stabellini , "consulting @ bugseng . com" , Nicola Vetrini , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel Subject: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible Date: Mon, 5 Jan 2026 12:24:36 +0000 Message-Id: <20260105122436.555444-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 On x86, this is basically everything. For ARM, CONFIG_MPU and CONFIG_MMU are mutually exclusive (with CONFIG_STATIC_MEMORY in the mix), as well as CONFIG_NEW_VGIC being mutually exclusive with the other VGIC infrastructure. No functional change, but a lot of new Eclair reports (non-blocking). Signed-off-by: Andrew Cooper --- CC: Stefano Stabellini CC: consulting@bugseng.com CC: Nicola Vetrini CC: Jan Beulich CC: Roger Pau Monné CC: Julien Grall CC: Volodymyr Babchuk CC: Bertrand Marquis CC: Michal Orzel https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2245142422 Maintaining these lists is going to be a nightmare. I think we really do need to implement CONFIG_COMPILE_TEST --- automation/gitlab-ci/analyze.yaml | 45 +++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/automation/gitlab-ci/analyze.yaml b/automation/gitlab-ci/analyze.yaml index a472692fcb31..7a2c0bfa77d1 100644 --- a/automation/gitlab-ci/analyze.yaml +++ b/automation/gitlab-ci/analyze.yaml @@ -44,6 +44,24 @@ eclair-x86_64-allcode: LOGFILE: "eclair-x86_64.log" VARIANT: "X86_64" RULESET: "monitored" + EXTRA_XEN_CONFIG: | + CONFIG_ARGO=y + CONFIG_DEBUG_LOCK_PROFILE=y + CONFIG_DEBUG_TRACE=y + CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y + CONFIG_EXPERT=y + CONFIG_HYPERV_GUEST=y + CONFIG_LATE_HWDOM=y + CONFIG_MEM_PAGING=y + CONFIG_MEM_SHARING=y + CONFIG_PERF_ARRAYS=y + CONFIG_PERF_COUNTERS=y + CONFIG_PV32=y + CONFIG_UNSUPPORTED=y + CONFIG_XENOPROF=y + CONFIG_XEN_GUEST=y + CONFIG_XHCI=y + CONFIG_XSM=y allow_failure: true eclair-x86_64-testing: @@ -104,6 +122,33 @@ eclair-ARM64-allcode: LOGFILE: "eclair-ARM64.log" VARIANT: "ARM64" RULESET: "monitored" + EXTRA_XEN_CONFIG: | + CONFIG_ACPI=y + CONFIG_ARGO=y + CONFIG_ARM64_SVE=y + CONFIG_ARM_SMMU_V3=y + CONFIG_BOOT_TIME_CPUPOOLS=y + CONFIG_DEBUG_LOCK_PROFILE=y + CONFIG_DEBUG_TRACE=y + CONFIG_DEVICE_TREE_DEBUG=y + CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y + CONFIG_EXPERT=y + CONFIG_FFA=y + CONFIG_FFA_VM_TO_VM=y + CONFIG_GICV3_ESPI=y + CONFIG_HAS_ITS=y + CONFIG_IOREQ_SERVER=y + CONFIG_IPMMU_VMSA=y + CONFIG_LIVEPATCH=y + CONFIG_LLC_COLORING=y + CONFIG_OPTEE=y + CONFIG_OVERLAY_DTB=y + CONFIG_PCI_PASSTHROUGH=y + CONFIG_PERF_ARRAYS=y + CONFIG_PERF_COUNTERS=y + CONFIG_STACK_PROTECTOR=y + CONFIG_UNSUPPORTED=y + CONFIG_VM_EVENT=y allow_failure: true eclair-ARM64-testing: -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 05 12:28:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 12:28:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195373.1513318 (Exim 4.92) (envelope-from ) id 1vcjhL-00074Z-9K; Mon, 05 Jan 2026 12:28:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195373.1513318; Mon, 05 Jan 2026 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 1vcjhL-00074S-4z; Mon, 05 Jan 2026 12:28:35 +0000 Received: by outflank-mailman (input) for mailman id 1195373; Mon, 05 Jan 2026 12:28:33 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcjhJ-00074K-0s for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 12:28: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 0a94a923-ea32-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 13:28:29 +0100 (CET) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-64b5ed53d0aso20090377a12.3 for ; Mon, 05 Jan 2026 04:28:29 -0800 (PST) Received: from ?IPV6:2003:e5:8704:4800:66fd:131f:60bd:bc29? (p200300e58704480066fd131f60bdbc29.dip0.t-ipconnect.de. [2003:e5:8704:4800:66fd:131f:60bd:bc29]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-64b9159a4eesm52542264a12.24.2026.01.05.04.28.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 04:28:28 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0a94a923-ea32-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767616109; x=1768220909; 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=PUth7Rv+PEjGuKvoMHkvuUFCQojP1Kmz0Cp68IdoWZI=; b=T/HICEUA3vwmxiG4vcVDrg80OK47HBVwL/5EnkaxNSMnGHECyiyy1SxQnBKId1dAvx LE1x/S2CbJkWbVrRF7+maDlo+u7SxsuF2QsjBsHcpq085x1V957PWH/e8imdo0bAp04w PpOXgK/Fwy8l972o35KSl0iN6HZfC5YyH1PWuA21yBbn4fEcRMzWs3bAyutj2/KudHFF 5YJ2Y/PZkAI6lMOVprK/1y4fs7lovvHI+ZYoBR4H11t1P7q4RQlAVdqOdzW+VesKHIC9 jHLzRpSkV1ydY+vMXEjCMKdMaBSt7zAGTHeC0TWEDqG/j9CxupBvqRynFOnUufgdkuJx b1Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767616109; x=1768220909; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=PUth7Rv+PEjGuKvoMHkvuUFCQojP1Kmz0Cp68IdoWZI=; b=P7hAgb0VF66oIZ/FF52AUpLJRUbGqYUaG1h5bh3wCkjYnGvzfHG3Js254iYuqgzdno +USEMnIvCWQnMvs83KTPMq6g8FIVrV+YTrwP7BOpNr+iNe6LFjCWfbZee6AJCf2NNbgk T5EZr0I0GDsKBpCnOjjAe492EUvwGp3BOZDvO9ocpp2Do3/S7TXlxQPy8iMCRZnJxb2l u1GJXWtkiuOh3n+rSYm4wr1skRqASfQyo4cdse29IMF4cqK04TYoHT7YWz2xsETCRo1A 6ybyzHAU5FDc5xjCR+CKqvxMxNYom0NxEEBmUhHz7XI8fgrYU5w/+yZf4aaLpSVo0FRg rDNg== X-Forwarded-Encrypted: i=1; AJvYcCXCUJrVc5/kEtRVIa/mYopihCtDwr8y4CMAejFCf+cvcZigrvah6kD9x01GHrjJAV40dVDMDuV9BIA=@lists.xenproject.org X-Gm-Message-State: AOJu0YzBvH3F3ZLMHrKl6k+OkPNGhsVnPTZUggXLJahekgRTMbXtQk7x 1EODhe9ziqgeGDRg3jspkQwfJB4vFc5OXm8KzdLE8epI9OuTjq5nJPabqPDI1D7HTvg= X-Gm-Gg: AY/fxX7fp8gAVj6PUpkHI2kA7S1zvnzyrlny9m75VBQWs8FJYSWbBRPBFYvtmVFPucW hB5YzvcTO+KarKlAHYrmOEft/aCFEhgCb+af/566Vb9StuTVX6TTaKCHBOIjcU5HDESFXbUEPCD S9RWq12c/lgg3axXW0/QuxoTHE8PsbcHaw0bMRdlOtww2Vtr5yZHHqZZGOL/KpoFe02RtHqLwKS YQoFxxtgKM5pVKyRAukyPD0j+zDiwXJg7UAF0X6grVtsW+EUgPq//VDjSOFhaxuPjAm9d6fOr8l BdjOjNYSCM+nhG2SNwdrt3fRwJgeZ9P6P4mx/fbi5+pRBLeEYmPahTNXESlvuxxJKfe5WkPdVjf MXuGMpKzLKRZ+yY7zgCRtgsJ6qRHl15HMPX/SUygM71O7ll9RJSzF6BqeyrdoxODbVtvvuHDpSA RoGmh7PITzk25uagaZDcSIjD1MZL9+ibbxz6JN7PqOaRsY5OWXczr1WCHnccllAiVPCJ+LkJ8o/ ZXwFITHZT8H63isDNFpglNsvqUQhal50iE6QQcYLLsfi8Tp6w== X-Google-Smtp-Source: AGHT+IHw7RzSwkUW6CQBSGYajsZ1cArTBvARw1HKoDtokXcxTEUwSVAhF63qSESresl9jE+EqPIj4g== X-Received: by 2002:a05:6402:35c6:b0:64d:2769:8460 with SMTP id 4fb4d7f45d1cf-64d276986c7mr41494908a12.6.1767616108941; Mon, 05 Jan 2026 04:28:28 -0800 (PST) Message-ID: <8acc1980-add8-4e0d-bba3-f7452fe53bce@suse.com> Date: Mon, 5 Jan 2026 13:28:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/8] dma-mapping: Separate DMA sync issuing and completion waiting To: Barry Song <21cnbao@gmail.com>, catalin.marinas@arm.com, m.szyprowski@samsung.com, robin.murphy@arm.com, will@kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Barry Song , Leon Romanovsky , Ada Couprie Diaz , Ard Biesheuvel , Marc Zyngier , Anshuman Khandual , Ryan Roberts , Suren Baghdasaryan , Joerg Roedel , Stefano Stabellini , Oleksandr Tyshchenko , Tangquan Zheng References: <20251226225254.46197-1-21cnbao@gmail.com> <20251226225254.46197-5-21cnbao@gmail.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20251226225254.46197-5-21cnbao@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------GxvkXPYAwDmy46KJEUE01P1J" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------GxvkXPYAwDmy46KJEUE01P1J Content-Type: multipart/mixed; boundary="------------ZpAK7ynzPzqJUaubTQ1077Hn"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Barry Song <21cnbao@gmail.com>, catalin.marinas@arm.com, m.szyprowski@samsung.com, robin.murphy@arm.com, will@kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Barry Song , Leon Romanovsky , Ada Couprie Diaz , Ard Biesheuvel , Marc Zyngier , Anshuman Khandual , Ryan Roberts , Suren Baghdasaryan , Joerg Roedel , Stefano Stabellini , Oleksandr Tyshchenko , Tangquan Zheng Message-ID: <8acc1980-add8-4e0d-bba3-f7452fe53bce@suse.com> Subject: Re: [PATCH v2 4/8] dma-mapping: Separate DMA sync issuing and completion waiting References: <20251226225254.46197-1-21cnbao@gmail.com> <20251226225254.46197-5-21cnbao@gmail.com> In-Reply-To: <20251226225254.46197-5-21cnbao@gmail.com> --------------ZpAK7ynzPzqJUaubTQ1077Hn Content-Type: multipart/mixed; boundary="------------EvMF4abzzyTjflF1c0aAYmMW" --------------EvMF4abzzyTjflF1c0aAYmMW Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjYuMTIuMjUgMjM6NTIsIEJhcnJ5IFNvbmcgd3JvdGU6DQo+IEZyb206IEJhcnJ5IFNv bmcgPGJhb2h1YUBrZXJuZWwub3JnPg0KPiANCj4gQ3VycmVudGx5LCBhcmNoX3N5bmNfZG1h X2Zvcl9jcHUgYW5kIGFyY2hfc3luY19kbWFfZm9yX2RldmljZQ0KPiBhbHdheXMgd2FpdCBm b3IgdGhlIGNvbXBsZXRpb24gb2YgZWFjaCBETUEgYnVmZmVyLiBUaGF0IGlzLA0KPiBpc3N1 aW5nIHRoZSBETUEgc3luYyBhbmQgd2FpdGluZyBmb3IgY29tcGxldGlvbiBpcyBkb25lIGlu IGENCj4gc2luZ2xlIEFQSSBjYWxsLg0KPiANCj4gRm9yIHNjYXR0ZXItZ2F0aGVyIGxpc3Rz IHdpdGggbXVsdGlwbGUgZW50cmllcywgdGhpcyBtZWFucw0KPiBpc3N1aW5nIGFuZCB3YWl0 aW5nIGlzIHJlcGVhdGVkIGZvciBlYWNoIGVudHJ5LCB3aGljaCBjYW4gaHVydA0KPiBwZXJm b3JtYW5jZS4gQXJjaGl0ZWN0dXJlcyBsaWtlIEFSTTY0IG1heSBiZSBhYmxlIHRvIGlzc3Vl IGFsbA0KPiBETUEgc3luYyBvcGVyYXRpb25zIGZvciBhbGwgZW50cmllcyBmaXJzdCBhbmQg dGhlbiB3YWl0IGZvcg0KPiBjb21wbGV0aW9uIHRvZ2V0aGVyLg0KPiANCj4gVG8gYWRkcmVz cyB0aGlzLCBhcmNoX3N5bmNfZG1hX2Zvcl8qIG5vdyBpc3N1ZXMgRE1BIG9wZXJhdGlvbnMg aW4NCj4gYmF0Y2gsIGZvbGxvd2VkIGJ5IGEgZmx1c2guIE9uIEFSTTY0LCB0aGUgZmx1c2gg aXMgaW1wbGVtZW50ZWQNCj4gdXNpbmcgYSBkc2IgaW5zdHJ1Y3Rpb24gd2l0aGluIGFyY2hf c3luY19kbWFfZmx1c2goKS4NCj4gDQo+IEZvciBub3csIGFkZCBhcmNoX3N5bmNfZG1hX2Zs dXNoKCkgYWZ0ZXIgZWFjaA0KPiBhcmNoX3N5bmNfZG1hX2Zvcl8qKCkgY2FsbC4gYXJjaF9z eW5jX2RtYV9mbHVzaCgpIGlzIGRlZmluZWQgYXMgYQ0KPiBuby1vcCBvbiBhbGwgYXJjaGl0 ZWN0dXJlcyBleGNlcHQgYXJtNjQsIHNvIHRoaXMgcGF0Y2ggZG9lcyBub3QNCj4gY2hhbmdl IGV4aXN0aW5nIGJlaGF2aW9yLiBTdWJzZXF1ZW50IHBhdGNoZXMgd2lsbCBpbnRyb2R1Y2Ug dHJ1ZQ0KPiBiYXRjaGluZyBmb3IgU0cgRE1BIGJ1ZmZlcnMuDQo+IA0KPiBDYzogTGVvbiBS b21hbm92c2t5IDxsZW9uQGtlcm5lbC5vcmc+DQo+IENjOiBDYXRhbGluIE1hcmluYXMgPGNh dGFsaW4ubWFyaW5hc0Bhcm0uY29tPg0KPiBDYzogV2lsbCBEZWFjb24gPHdpbGxAa2VybmVs Lm9yZz4NCj4gQ2M6IE1hcmVrIFN6eXByb3dza2kgPG0uc3p5cHJvd3NraUBzYW1zdW5nLmNv bT4NCj4gQ2M6IFJvYmluIE11cnBoeSA8cm9iaW4ubXVycGh5QGFybS5jb20+DQo+IENjOiBB ZGEgQ291cHJpZSBEaWF6IDxhZGEuY291cHJpZWRpYXpAYXJtLmNvbT4NCj4gQ2M6IEFyZCBC aWVzaGV1dmVsIDxhcmRiQGtlcm5lbC5vcmc+DQo+IENjOiBNYXJjIFp5bmdpZXIgPG1hekBr ZXJuZWwub3JnPg0KPiBDYzogQW5zaHVtYW4gS2hhbmR1YWwgPGFuc2h1bWFuLmtoYW5kdWFs QGFybS5jb20+DQo+IENjOiBSeWFuIFJvYmVydHMgPHJ5YW4ucm9iZXJ0c0Bhcm0uY29tPg0K PiBDYzogU3VyZW4gQmFnaGRhc2FyeWFuIDxzdXJlbmJAZ29vZ2xlLmNvbT4NCj4gQ2M6IEpv ZXJnIFJvZWRlbCA8am9yb0A4Ynl0ZXMub3JnPg0KPiBDYzogSnVlcmdlbiBHcm9zcyA8amdy b3NzQHN1c2UuY29tPg0KPiBDYzogU3RlZmFubyBTdGFiZWxsaW5pIDxzc3RhYmVsbGluaUBr ZXJuZWwub3JnPg0KPiBDYzogT2xla3NhbmRyIFR5c2hjaGVua28gPG9sZWtzYW5kcl90eXNo Y2hlbmtvQGVwYW0uY29tPg0KPiBDYzogVGFuZ3F1YW4gWmhlbmcgPHpoZW5ndGFuZ3F1YW5A b3Bwby5jb20+DQo+IFNpZ25lZC1vZmYtYnk6IEJhcnJ5IFNvbmcgPGJhb2h1YUBrZXJuZWwu b3JnPg0KDQpSZXZpZXdlZC1ieTogSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPiAj IGRyaXZlcnMveGVuL3N3aW90bGIteGVuLmMNCg0KDQpKdWVyZ2VuDQo= --------------EvMF4abzzyTjflF1c0aAYmMW 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----- --------------EvMF4abzzyTjflF1c0aAYmMW-- --------------ZpAK7ynzPzqJUaubTQ1077Hn-- --------------GxvkXPYAwDmy46KJEUE01P1J 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/Ey8FAmlbrmsFAwAAAAAACgkQsN6d1ii/Ey86 BAf/TjdHSGSVxUq/1jBWSwsEL60D1UwbkianqWSyU9Lsgv+ciQZTl9YQCekRNSDjfbC+TkQk95o+ ljksgKaiQl/4XuHFJY9ax5EseY3bgye1Z0Np6xYNuFLLBvqM7uhasqj72tN00Km61L66qlCMx+fW 3d5gg3VRLs3lah8IkXTIhy0uJEhnY0A4uIk7VETLcj7+7a5S4CMHE5VMChqNUWcK9Sh9kTb8P1Nh Gse1tYNFtQ47AYbZMtrtbRg+0b4vbqUsHVEYT4L3wLnUJWDdHD6vLl8Y/9wqqvrRev2y3bj38wtl 3VS1yVV7aJypH6t/+psUq87o3BRJ3C931NL73VcD0g== =QB9Y -----END PGP SIGNATURE----- --------------GxvkXPYAwDmy46KJEUE01P1J-- From xen-devel-bounces@lists.xenproject.org Mon Jan 05 12:30:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 12:30:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195382.1513327 (Exim 4.92) (envelope-from ) id 1vcjjB-0008Vs-J9; Mon, 05 Jan 2026 12:30:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195382.1513327; Mon, 05 Jan 2026 12:30:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcjjB-0008Vl-Fk; Mon, 05 Jan 2026 12:30:29 +0000 Received: by outflank-mailman (input) for mailman id 1195382; Mon, 05 Jan 2026 12:30: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 1vcjjA-0008Vf-1T for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 12:30:28 +0000 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [2a00:1450:4864:20::62f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5026fc01-ea32-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 13:30:26 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-b73161849e1so2697515266b.2 for ; Mon, 05 Jan 2026 04:30:26 -0800 (PST) Received: from ?IPV6:2003:e5:8704:4800:66fd:131f:60bd:bc29? (p200300e58704480066fd131f60bdbc29.dip0.t-ipconnect.de. [2003:e5:8704:4800:66fd:131f:60bd:bc29]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b841fc8f2a2sm86653866b.63.2026.01.05.04.30.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 04:30:25 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5026fc01-ea32-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767616226; x=1768221026; 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=I2Nk/tTo8pumwLJRVroAmmxAzYDU4LxxrIEGYy3AXlM=; b=aBFzmR5INiqO4FfpB2WgKC07gypDazfGTkZ1RA0r/n80BJUFSC+JLIxu2Vj7lEUJe3 i4Bw6RBfSQ+rfBQ4yCryEmcPt6HrmYcHbMkI//Ru6ztXGseN1nAp6Jd01XMzBzj61mdg zPRqwRZ/ITsxoiyR94d+IRJnseACviZdUuf5EFBjiIp9yJ0yI7FrsRNc3jkzAIpAM6BQ gtppXdyH07CeWw4PxaYsgwJ5XNiofoc8TIoGMDu+h8t4s99NWSqH+nQsJzrEZnRJAvXO Zm7f/eRp5M4rJlr+PQeVrqQt/sjDdUPAuTIEOPgh8t4NWPhYoFbLJOXSTWf9yDdZDwM2 +jvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767616226; x=1768221026; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=I2Nk/tTo8pumwLJRVroAmmxAzYDU4LxxrIEGYy3AXlM=; b=q9EX4OffvTSBEy8CNE+GYx6TR91+oFIV1nl8nj5wAxeTk9g/OP7qbQbNnqJMbCDaCQ /Qig5an4NWjF9cnEK09/668YC19YChipPv43cf1qtjqM6Sj+rYpu2Kw8pwfvM+NmMRcb 68Fs/kHc/HrcrXpO8IIjH6tBy5wSWMijDkLzzKHLmsSjaYvBP/M42b9Oza8vy/JJ0N7w /LfdwTNdwxhoyGOVKQw9omO3JYalzjobQGY93A34xxYOv50+YhGrtbrDTAXavEkeTssD ouopsCCgsVQyRQa7froWNkfLKMKkfnf8lrkn1f0s0ItrJ98sUroj8uJHD8iffco4t5iZ E1ow== X-Forwarded-Encrypted: i=1; AJvYcCXlEYI3sw+xE0YQhwq9TLvkVtG7HwYq9OGgl209tvWVa4wTDE6oSYm5OREJ4o1AbZOMZm7a9AqLMAQ=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy5zMJ+3ld0S1AxKWXlvF2mVsaKw++os7F0+T0qlWQm9P9/OP3c KIMnBOo7lYZbabTSIvhQzFuO4IB/8Hypsy0UVg0T2HcVZiDmXpsRtlSQ3vBiJe2io6o= X-Gm-Gg: AY/fxX5yEi3uzZfU32tnd1DtaQzPd+iz7xvuwx4si+FiucEFbBKszR3txoUcCptBIT8 xZjupQf/PXDBMruzLiBEb6v5bRctdj5W1nkfaDcBChp8YIwDWqBEQJOJL5kw/V+AbpXGIR6Qbwh eNrqBIn5AP/WRWwMdsayFJDfW5PN2uBuZbUglpwO6loQPd6MuQPa2axNZnyTkM+2ksqR99eSeX1 TWIH9sCzW6NIULIUphiZNfLTE2GXXUcg6NA12SuEOnisc1xKPo6Wj3GDjE8vY7agCwHzwGSmcpP Vw/MrIll/p1O1bC++R/sBcgdbiHXk72vOtkgzPQoLJXJWMMFnIhW5SXcpZ8Am5po71CmyHq64Pb NEynqmJmmqY/8ib7sS+juNPp1UK/M0sMB1mYiqKINHfDSOEU8ywfQ+gKDNweIsOYKdZ6ROnT69A PRFLvP84zu/wI1vbIk57dxC5e51aIP3TUARQnRPTnnBem31lxny6XiPvb44Sg0Vj96/jV+xQS+J gW6I2T9VDNEX5ZSXTL3ZJ+25pMc+LUqaSik+bx44nkImdUuNQ== X-Google-Smtp-Source: AGHT+IGCPHQgxAPDtbyWEiEGXI40NdxL+l7/n1HqJvGf0MHXX253ZEZgOIBDCyPHpnJitWr3iDDuxQ== X-Received: by 2002:a17:907:9606:b0:b80:3447:e0c0 with SMTP id a640c23a62f3a-b80371f8c3amr4880080766b.62.1767616225840; Mon, 05 Jan 2026 04:30:25 -0800 (PST) Message-ID: Date: Mon, 5 Jan 2026 13:30:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/events: replace use of system_wq with system_percpu_wq To: Marco Crivellari , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Cc: Tejun Heo , Lai Jiangshan , Frederic Weisbecker , Sebastian Andrzej Siewior , Michal Hocko , Stefano Stabellini , Oleksandr Tyshchenko References: <20251106155831.306248-1-marco.crivellari@suse.com> <20251106155831.306248-2-marco.crivellari@suse.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20251106155831.306248-2-marco.crivellari@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------rZniUMkCsQegAOQbSofO81jm" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------rZniUMkCsQegAOQbSofO81jm Content-Type: multipart/mixed; boundary="------------OiDwSmYXtw8G29gJdIB9TKXH"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Marco Crivellari , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Cc: Tejun Heo , Lai Jiangshan , Frederic Weisbecker , Sebastian Andrzej Siewior , Michal Hocko , Stefano Stabellini , Oleksandr Tyshchenko Message-ID: Subject: Re: [PATCH 1/2] xen/events: replace use of system_wq with system_percpu_wq References: <20251106155831.306248-1-marco.crivellari@suse.com> <20251106155831.306248-2-marco.crivellari@suse.com> In-Reply-To: <20251106155831.306248-2-marco.crivellari@suse.com> --------------OiDwSmYXtw8G29gJdIB9TKXH Content-Type: multipart/mixed; boundary="------------JgwdlsoBKx5EbJGQVVg6FwZu" --------------JgwdlsoBKx5EbJGQVVg6FwZu Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDYuMTEuMjUgMTY6NTgsIE1hcmNvIENyaXZlbGxhcmkgd3JvdGU6DQo+IEN1cnJlbnRs eSBpZiBhIHVzZXIgZW5xdWV1ZXMgYSB3b3JrIGl0ZW0gdXNpbmcgc2NoZWR1bGVfZGVsYXll ZF93b3JrKCkgdGhlDQo+IHVzZWQgd3EgaXMgInN5c3RlbV93cSIgKHBlci1jcHUgd3EpIHdo aWxlIHF1ZXVlX2RlbGF5ZWRfd29yaygpIHVzZQ0KPiBXT1JLX0NQVV9VTkJPVU5EICh1c2Vk IHdoZW4gYSBjcHUgaXMgbm90IHNwZWNpZmllZCkuIFRoZSBzYW1lIGFwcGxpZXMgdG8NCj4g c2NoZWR1bGVfd29yaygpIHRoYXQgaXMgdXNpbmcgc3lzdGVtX3dxIGFuZCBxdWV1ZV93b3Jr KCksIHRoYXQgbWFrZXMgdXNlDQo+IGFnYWluIG9mIFdPUktfQ1BVX1VOQk9VTkQuDQo+IA0K PiBUaGlzIGxhY2sgb2YgY29uc2lzdGVuY3kgY2Fubm90IGJlIGFkZHJlc3NlZCB3aXRob3V0 IHJlZmFjdG9yaW5nIHRoZSBBUEkuDQo+IA0KPiBUaGlzIGNvbnRpbnVlcyB0aGUgZWZmb3J0 IHRvIHJlZmFjdG9yIHdvcmtxdWV1ZSBBUElzLCB3aGljaCBiZWdhbiB3aXRoDQo+IHRoZSBp bnRyb2R1Y3Rpb24gb2YgbmV3IHdvcmtxdWV1ZXMgYW5kIGEgbmV3IGFsbG9jX3dvcmtxdWV1 ZSBmbGFnIGluOg0KPiANCj4gY29tbWl0IDEyOGVhOWY2Y2NmYiAoIndvcmtxdWV1ZTogQWRk IHN5c3RlbV9wZXJjcHVfd3EgYW5kIHN5c3RlbV9kZmxfd3EiKQ0KPiBjb21taXQgOTMwYzJl YTU2NmFmICgid29ya3F1ZXVlOiBBZGQgbmV3IFdRX1BFUkNQVSBmbGFnIikNCj4gDQo+IFN3 aXRjaCB0byB1c2luZyBzeXN0ZW1fcGVyY3B1X3dxIGJlY2F1c2Ugc3lzdGVtX3dxIGlzIGdv aW5nIGF3YXkgYXMgcGFydCBvZg0KPiBhIHdvcmtxdWV1ZSByZXN0cnVjdHVyaW5nLg0KPiAN Cj4gU3VnZ2VzdGVkLWJ5OiBUZWp1biBIZW8gPHRqQGtlcm5lbC5vcmc+DQo+IFNpZ25lZC1v ZmYtYnk6IE1hcmNvIENyaXZlbGxhcmkgPG1hcmNvLmNyaXZlbGxhcmlAc3VzZS5jb20+DQoN ClJldmlld2VkLWJ5OiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQoNCg0KSnVl cmdlbg0K --------------JgwdlsoBKx5EbJGQVVg6FwZu 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----- --------------JgwdlsoBKx5EbJGQVVg6FwZu-- --------------OiDwSmYXtw8G29gJdIB9TKXH-- --------------rZniUMkCsQegAOQbSofO81jm 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/Ey8FAmlbruAFAwAAAAAACgkQsN6d1ii/Ey/1 hAf/d2Gq7Ba3L6q6plswJt8zJSFPkOu1TaKD6e6pjwQMjItpJT/z236hcoV0G9eUAZP/grT9bvEo TdnlxRupTSmXaLp6OYQFIaParjBvwDtF4PHq03yMxfE3LRicvkf8vF5Hb2h1d1RWCj5liyCYiGzl FQbGvbMYA+habVsSfqhG2S8yvYTv4x011NQ8sX1F3KRpTopfzKChll1byC4y3FNyw5+Zr+BZnGG2 toO1SKhfbLP80S3YfMbbfBj0WlRSemidrB8mvZdU4j2Rj3BT/FxYihIY3lP/T5CC8pHm+xK94i65 h69PSMndbMiyJ2FgGcTfEeoSS4r3n207uvQ4byvn5g== =JGqa -----END PGP SIGNATURE----- --------------rZniUMkCsQegAOQbSofO81jm-- From xen-devel-bounces@lists.xenproject.org Mon Jan 05 12:30:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 12:30:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195387.1513337 (Exim 4.92) (envelope-from ) id 1vcjjc-0000Uh-Uk; Mon, 05 Jan 2026 12:30:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195387.1513337; Mon, 05 Jan 2026 12:30:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcjjc-0000UZ-Rq; Mon, 05 Jan 2026 12:30:56 +0000 Received: by outflank-mailman (input) for mailman id 1195387; Mon, 05 Jan 2026 12:30: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 1vcjjb-0008Vf-IS for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 12:30:55 +0000 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [2a00:1450:4864:20::32e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 60ecad66-ea32-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 13:30:54 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-4775ae5684fso45522125e9.1 for ; Mon, 05 Jan 2026 04:30:54 -0800 (PST) Received: from ?IPV6:2003:e5:8704:4800:66fd:131f:60bd:bc29? (p200300e58704480066fd131f60bdbc29.dip0.t-ipconnect.de. [2003:e5:8704:4800:66fd:131f:60bd:bc29]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d6d14912asm149324915e9.8.2026.01.05.04.30.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 04:30:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 60ecad66-ea32-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767616254; x=1768221054; 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=3IfjnrxjRzFX+Zru/wByu+UKYqoBOIp/X4fNnDziGyo=; b=PqIb/yFLTk04r3UQqWzwLgl/io2lMGwfX5v9ISakba0iP2TLinXkvQK8YNuxXf2ltr Sc4lEJjFIwCF+xpxaKLjIxEyVEmx5r3WMjYROSIfZhKMUNWOCENkBHCYtR52JANGJDVE loPI8yC0TSriRV42S/LTmxbnUhxw/RO/sVeabmmskO75SnlHsQNHA0iC/9pnaPWucbsl FOi4IqUSbciw4M9dUwIg+6AY3StUo9j9H7uNUJBrAShDeuKv8Y8qJcWheodc4+ZqgV/A s4ZgF6X0PRS/dykTXjZ2HH0FIriz/xzCN+1xt5mogYSa6XVPZG/g0fOiy3ri6mChThS6 uclw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767616254; x=1768221054; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3IfjnrxjRzFX+Zru/wByu+UKYqoBOIp/X4fNnDziGyo=; b=uKRrIEjXjYi/fuB17Tt+8LP+IH0b73dy7lRK7cCU136Edm8jELv8PViROTF1tuftVr 0WjTqI0/+f4hyTfhsPoObsdy1B4ytZ09e0/KwPTolLfBhs0POQaFvtVVjARuCn33P7pg 1/EcoCX1cfI9SEHIcuhs63G6AzbROvLLv4U++zy8u4dH4dBsUoGZZbw2XybP6IOBPn60 S36Jkz7WUA5pX0wy10i8npZWkELY3WpTXtPtvZZydZUK7JJCTc3IL7JfDDmQXxmaiU4z A4lp+z3VaXrzeH8itrMNqYjMFZ/CxSXF0vwRIPcpp6CdH7uQm56b4uxCa++0LK9qvaHQ NaoQ== X-Forwarded-Encrypted: i=1; AJvYcCVJHPu93JxyuBp7KfA2vADNWPXm1f4e3moCpJFY3UAY6LDovRmc7kiVSjpuHGaqgAmqAUeaovzza6w=@lists.xenproject.org X-Gm-Message-State: AOJu0YzrDd4Io+vCQoN9PHtWkxGF3YlhnCWo9tIfRXFIZDywY5xmtlZm 26+f6o5TA+vSryiBgCfVAfEI+prLdO+IRU+Joh2N2hmgWRoKoK/BeMLm75OAnUk89Eo= X-Gm-Gg: AY/fxX6DEWAKBb+MQwkHm8lskkY4Ee8HZcukiOvW4TzVxgM4i1BdmUAkakS1eOTQz+c CSc4uG9myHSPoEawelChsdp7wiV8pMoI4A862hST5mCtxSiYu+mF51Uwr7sruYksncv9wMZjaZS u0eAMSM0//4YdEwF2UUqcdKDi2iu1fr/Ax/Y4Oj9JL88LsRjA7LK8KR8+6UM+4QqUkNWpMquiS2 AnFN4zvvsw2/TuNVsXvkATzCNeXqU5v1BnJrKrI7zSdx9L9huB86Vo9ghpMuZujTAu0aWXFuMTw 3WvoIQjhPpUyes/xXRIXJ+ZC+1dRO7V2K8cwd7m1F7CtCObn5CIWWdoCDvpnp70DzJlPuIPqBm0 sHCg9oiPkefDx/BDDx+AMBeTl3qZw7ec/IWadLfxXpW2Mv9y46asZ5f3NPYX9LfQB7+oNRmOtBi Qox0YX2D8aLrP+Zdn4ZVxESZWB0y7k6VNXRTY4/W8Bu4dATdYS8H0l/kSGyqd8JZtzgwxj9ZukT oevWoUCYCyK7crPxluenqazdiej2UslAn8jtQ8= X-Google-Smtp-Source: AGHT+IES1qlktk8zGYm5cv5z603J5DVcPKE4FRYiohr8zXZs9DB9qqW7e7mJqhfqVEsKLh3RYNMHDQ== X-Received: by 2002:a05:600c:3e0b:b0:477:2f7c:314f with SMTP id 5b1f17b1804b1-47d19555af8mr593489765e9.10.1767616254114; Mon, 05 Jan 2026 04:30:54 -0800 (PST) Message-ID: <11cf87f7-060d-413a-a42e-bc39619cd11a@suse.com> Date: Mon, 5 Jan 2026 13:30:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] xen: privcmd: WQ_PERCPU added to alloc_workqueue users To: Marco Crivellari , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Cc: Tejun Heo , Lai Jiangshan , Frederic Weisbecker , Sebastian Andrzej Siewior , Michal Hocko , Stefano Stabellini , Oleksandr Tyshchenko References: <20251106155831.306248-1-marco.crivellari@suse.com> <20251106155831.306248-3-marco.crivellari@suse.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20251106155831.306248-3-marco.crivellari@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------lGbqr5zLuvclXNIporo4n6SP" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------lGbqr5zLuvclXNIporo4n6SP Content-Type: multipart/mixed; boundary="------------RxWE3za0dL5nnjt1Pdx0UiYj"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Marco Crivellari , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Cc: Tejun Heo , Lai Jiangshan , Frederic Weisbecker , Sebastian Andrzej Siewior , Michal Hocko , Stefano Stabellini , Oleksandr Tyshchenko Message-ID: <11cf87f7-060d-413a-a42e-bc39619cd11a@suse.com> Subject: Re: [PATCH 2/2] xen: privcmd: WQ_PERCPU added to alloc_workqueue users References: <20251106155831.306248-1-marco.crivellari@suse.com> <20251106155831.306248-3-marco.crivellari@suse.com> In-Reply-To: <20251106155831.306248-3-marco.crivellari@suse.com> --------------RxWE3za0dL5nnjt1Pdx0UiYj Content-Type: multipart/mixed; boundary="------------0SyVemSfu5BWy9VLIxFJoyu1" --------------0SyVemSfu5BWy9VLIxFJoyu1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDYuMTEuMjUgMTY6NTgsIE1hcmNvIENyaXZlbGxhcmkgd3JvdGU6DQo+IEN1cnJlbnRs eSBpZiBhIHVzZXIgZW5xdWV1ZSBhIHdvcmsgaXRlbSB1c2luZyBzY2hlZHVsZV9kZWxheWVk X3dvcmsoKSB0aGUNCj4gdXNlZCB3cSBpcyAic3lzdGVtX3dxIiAocGVyLWNwdSB3cSkgd2hp bGUgcXVldWVfZGVsYXllZF93b3JrKCkgdXNlDQo+IFdPUktfQ1BVX1VOQk9VTkQgKHVzZWQg d2hlbiBhIGNwdSBpcyBub3Qgc3BlY2lmaWVkKS4gVGhlIHNhbWUgYXBwbGllcyB0bw0KPiBz Y2hlZHVsZV93b3JrKCkgdGhhdCBpcyB1c2luZyBzeXN0ZW1fd3EgYW5kIHF1ZXVlX3dvcmso KSwgdGhhdCBtYWtlcyB1c2UNCj4gYWdhaW4gb2YgV09SS19DUFVfVU5CT1VORC4NCj4gVGhp cyBsYWNrIG9mIGNvbnNpc3RlbnRjeSBjYW5ub3QgYmUgYWRkcmVzc2VkIHdpdGhvdXQgcmVm YWN0b3JpbmcgdGhlIEFQSS4NCj4gDQo+IGFsbG9jX3dvcmtxdWV1ZSgpIHRyZWF0cyBhbGwg cXVldWVzIGFzIHBlci1DUFUgYnkgZGVmYXVsdCwgd2hpbGUgdW5ib3VuZA0KPiB3b3JrcXVl dWVzIG11c3Qgb3B0LWluIHZpYSBXUV9VTkJPVU5ELg0KPiANCj4gVGhpcyBkZWZhdWx0IGlz IHN1Ym9wdGltYWw6IG1vc3Qgd29ya2xvYWRzIGJlbmVmaXQgZnJvbSB1bmJvdW5kIHF1ZXVl cywNCj4gYWxsb3dpbmcgdGhlIHNjaGVkdWxlciB0byBwbGFjZSB3b3JrZXIgdGhyZWFkcyB3 aGVyZSB0aGV54oCZcmUgbmVlZGVkIGFuZA0KPiByZWR1Y2luZyBub2lzZSB3aGVuIENQVXMg YXJlIGlzb2xhdGVkLg0KPiANCj4gVGhpcyBjb250aW51ZXMgdGhlIGVmZm9ydCB0byByZWZh Y3RvciB3b3JrcXVldWUgQVBJcywgd2hpY2ggYmVnYW4gd2l0aA0KPiB0aGUgaW50cm9kdWN0 aW9uIG9mIG5ldyB3b3JrcXVldWVzIGFuZCBhIG5ldyBhbGxvY193b3JrcXVldWUgZmxhZyBp bjoNCj4gDQo+IGNvbW1pdCAxMjhlYTlmNmNjZmIgKCJ3b3JrcXVldWU6IEFkZCBzeXN0ZW1f cGVyY3B1X3dxIGFuZCBzeXN0ZW1fZGZsX3dxIikNCj4gY29tbWl0IDkzMGMyZWE1NjZhZiAo IndvcmtxdWV1ZTogQWRkIG5ldyBXUV9QRVJDUFUgZmxhZyIpDQo+IA0KPiBUaGlzIGNoYW5n ZSBhZGRzIGEgbmV3IFdRX1BFUkNQVSBmbGFnIHRvIGV4cGxpY2l0bHkgcmVxdWVzdCBhbGxv Y193b3JrcXVldWUoKQ0KPiB0byBiZSBwZXItY3B1IHdoZW4gV1FfVU5CT1VORCBoYXMgbm90 IGJlZW4gc3BlY2lmaWVkLg0KPiANCj4gV2l0aCB0aGUgaW50cm9kdWN0aW9uIG9mIHRoZSBX UV9QRVJDUFUgZmxhZyAoZXF1aXZhbGVudCB0byAhV1FfVU5CT1VORCksDQo+IGFueSBhbGxv Y193b3JrcXVldWUoKSBjYWxsZXIgdGhhdCBkb2VzbuKAmXQgZXhwbGljaXRseSBzcGVjaWZ5 IFdRX1VOQk9VTkQNCj4gbXVzdCBub3cgdXNlIFdRX1BFUkNQVS4NCj4gDQo+IE9uY2UgbWln cmF0aW9uIGlzIGNvbXBsZXRlLCBXUV9VTkJPVU5EIGNhbiBiZSByZW1vdmVkIGFuZCB1bmJv dW5kIHdpbGwNCj4gYmVjb21lIHRoZSBpbXBsaWNpdCBkZWZhdWx0Lg0KPiANCj4gU3VnZ2Vz dGVkLWJ5OiBUZWp1biBIZW8gPHRqQGtlcm5lbC5vcmc+DQo+IFNpZ25lZC1vZmYtYnk6IE1h cmNvIENyaXZlbGxhcmkgPG1hcmNvLmNyaXZlbGxhcmlAc3VzZS5jb20+DQoNClJldmlld2Vk LWJ5OiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQoNCg0KSnVlcmdlbg0K --------------0SyVemSfu5BWy9VLIxFJoyu1 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----- --------------0SyVemSfu5BWy9VLIxFJoyu1-- --------------RxWE3za0dL5nnjt1Pdx0UiYj-- --------------lGbqr5zLuvclXNIporo4n6SP 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/Ey8FAmlbrv0FAwAAAAAACgkQsN6d1ii/Ey98 QAgAg6SlZqiwL4c1FQ4ec3hoO8VySdf+gywGdMUU8aomPTxnNY+06Cf6mLZpGOFxloHzUWJULyIe wxiaY5kdnLGGh7U7cS0PKH91d6//dhn5vfTbv/1vixAvDzlaQAYk44caqhRbVoLQejM0h+7sM3Fz tKBtHjbm93kLP70YiU4DUwP0oiG0SXPjLq0NlgIKATn8/Y1rfviIDYAprIMqWpN5K322UixfwWyz oEw95wS7TaSRTgUYNqH5UJR08EjohHTRuVyfJJZumjSK2oMzD1pCLDLPRYM3wRPk8urfFIlGjpQD gckhK8471gq4BsszVu3BRzQGkJ6b9n75ezlv9Et9eA== =rnWo -----END PGP SIGNATURE----- --------------lGbqr5zLuvclXNIporo4n6SP-- From xen-devel-bounces@lists.xenproject.org Mon Jan 05 13:50:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 13:50:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195408.1513346 (Exim 4.92) (envelope-from ) id 1vckyF-0002l5-Ev; Mon, 05 Jan 2026 13:50:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195408.1513346; Mon, 05 Jan 2026 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 1vckyF-0002ky-CA; Mon, 05 Jan 2026 13:50:07 +0000 Received: by outflank-mailman (input) for mailman id 1195408; Mon, 05 Jan 2026 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 1vckyE-0002dh-2Y for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 13:50:06 +0000 Received: from mail187-9.suw11.mandrillapp.com (mail187-9.suw11.mandrillapp.com [198.2.187.9]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6f1c9171-ea3d-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 14:50:03 +0100 (CET) Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail187-9.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4dlFzZ04zNzK5vg69 for ; Mon, 5 Jan 2026 13:50:02 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 6139dbf1b10240ecb780db96bb83dcf8; Mon, 05 Jan 2026 13:50: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: 6f1c9171-ea3d-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1767621002; x=1767891002; bh=Jx2VszJ0a4ZLDSguWGgJq3sBug+HdQPg/Syy4sUYLK8=; 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=r0ShA0aH0atrnR8yBLMDNk8hxFb7M6CX9QqALWiBNs4NIr6vhyhBh/QIi3FAm2IbH y8IeAhzkDdYNN3e1UQg+OkuYOG5pnnX8snwlrFknQFZCvTTYW5/3uDvD28f6nXugig 1QuKu9XzFXzv6SPYoSB90cQaf6IEYwSZ3QZCqPIkyRTGzz/0U5UnxJxG3stOcVN9ea dBRd3QqeOI+KU5e6rvcZrQODrJLrb+Tmj4E9F9w2ZUdhNz3Png7b/EOVJniOvxhHBZ 4FMqIEmdRtu6uYloKBupnVDd+3AU1QPNN1cUKooWXhiPhobOuUh57CzBX6mVtvt8WL qgKNjkNTFuG/Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1767621002; x=1767881502; i=teddy.astie@vates.tech; bh=Jx2VszJ0a4ZLDSguWGgJq3sBug+HdQPg/Syy4sUYLK8=; 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=0RyqLFcbcEXCyjV9DJ5Z6DsnaKi5R1L3mT+/qa22ylhaf0VPi9sFMML8rGUw3BwTs lCXbgS16hwMJ4mbQpXmrMtVLJVa98QQCKlpZGNeFvMHugCgulAsUpPGqbmABFuoPHC jeIKvdrC93ZOH2ixMAPhj5+M2bWhAEp+EZEqHsIx6DFET2QrFjOhKD20KIWfTHaaA9 vnWVHI/Jxc4YwWO7c37+3y03g65UsTMphBroFSExoAv0YzEdO+fL9aK6tSPwEXbL2C Qf4tLeAva7Q/ReXUqB+WIQOZhCgyqm5wS2a+9KYtPvlvNtbirHuX1ueN+8KFLZMsnL WwexzZNB8Ap6w== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[RFC=20PATCH]=20pvh:=20Introduce=20SIF=5FHVM=5FGHCB=20for=20SEV-ES/SNP=20guests?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1767621000671 Message-Id: <18d08be6-7e31-4b5f-b9b8-908375abfa29@vates.tech> To: "Jan Beulich" Cc: "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" , xen-devel@lists.xenproject.org References: <3b6f5146287d3402a09836b7cf876d4f8dc9eee1.1766889890.git.teddy.astie@vates.tech> <7d439b75-801b-406d-98e0-29c207e1c1ba@suse.com> <7bbd6560-c988-44d9-a2e8-448cceb455e2@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.6139dbf1b10240ecb780db96bb83dcf8?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260105:md Date: Mon, 05 Jan 2026 13:50:01 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 29/12/2025 =C3=A0 15:16, Jan Beulich a =C3=A9crit=C2=A0: > On 29.12.2025 13:39, Teddy Astie wrote: >> Le 29/12/2025 =C3=A0 09:24, Jan Beulich a =C3=A9crit=C2=A0: >>> On 28.12.2025 13:49, Teddy Astie wrote: >>>> --- a/xen/include/public/xen.h >>>> +++ b/xen/include/public/xen.h >>>> @@ -890,6 +890,8 @@ typedef struct start_info start_info_t; >>>> #define SIF_MOD_START_PFN (1<<3) /* Is mod_start a PFN? */ >>>> #define SIF_VIRT_P2M_4TOOLS (1<<4) /* Do Xen tools understand a vir= t. mapped */ >>>> /* P->M making the 3 level tree = obsolete? */ >>>> +#define SIF_HVM_GHCB (1<<5) /* Domain is SEV-ES/SNP guest that= requires */ >>>> + /* use of GHCB. */ >>> >>> Naming-wise, do we really want to tie this to AMD (and hence exclude ot= her >>> vendors, or require yet another bit to be allocated later)? >> >> This is SEV-ES/SNP only, I don't think the same bit can be reused for >> another technology (unless it also uses the GHCB MSR). As the guest >> can't even check if it is Intel or AMD CPU at this point (if running >> under SEV-ES or SEV-SNP). > > If it was just telling AMD from Intel, that would be possible. There are > a few well-known differences in how certain instructions behave [1]. But > here you aren't after telling apart the vendors; you want to know whether > you're (fundamentally) on SVM or VT-x. > > Of course I have to admit that I find it quite irritating that in order > to execute CPUID one has to have a #VC handler properly set up. This > inverses the typical flow of events. Did they really not think of some > replacement for at least the most basic information? > Yes, but only with more information beforehand. Regarding the #VC approach, the negociation example also state this > The above example is just one way to perform the GHCB negotiation for an SEV-ES guest. For example, you could use the GHCBInfo =3D 0x004 CPUID Request to obtain actual values for the CPUID instructions executed by the guest. Or you could use the GHCBInfo =3D 0x002 Request for SEV Information if MSR 0xc001_0130 does not contain the GHCBInfo =3D 0x001 SEV Information. But that only works as long as you know GHCB MSR is available; which you may be able to check through SEV_STATUS MSR; but this MSR is only meaningful on CPUs that supports SEV (APM says the hypervisor cannot intercept these MSRs). This proposal aims to give this information to the guest through the start_info structure. Under SEV-ES/SNP, the hypervisor cannot fake EFER MSR which in this case may have forced guest-visible EFER:SVME, it could be a way to check for SEV-ES for but it's quite hacky and fragile. (I still need to test this though) > Jan > > [1] Of course, such details can change going forward. Vendors did alter > the behavior of certain insns in the past. > -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Mon Jan 05 14:23:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 14:23:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195417.1513358 (Exim 4.92) (envelope-from ) id 1vclUJ-00073f-V6; Mon, 05 Jan 2026 14:23:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195417.1513358; Mon, 05 Jan 2026 14:23: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 1vclUJ-00073Y-R4; Mon, 05 Jan 2026 14:23:15 +0000 Received: by outflank-mailman (input) for mailman id 1195417; Mon, 05 Jan 2026 14:23: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 1vclUH-00073S-UL for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 14:23:13 +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 1026e15d-ea42-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 15:23:11 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-47d63594f7eso24809875e9.0 for ; Mon, 05 Jan 2026 06:23:11 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d6c0c148bsm57250425e9.18.2026.01.05.06.23.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 06:23:09 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1026e15d-ea42-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767622990; x=1768227790; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=6si9mWEhUYCepCa96A28RLdBxiL+gruBzfgL8pmOmtk=; b=Q7KkMQPuuFX+9z+3hM0hH4nQVxbnJzI6vmD3WqQz0OcGUsycEg00LqtupAY3P79i7b QF3Dj+/UZyJJ4khtwNwqfmQmf71txiJnBCUpe9o0Cjpk0YGFgtOH1nPFdoHdMaGfKFDv ioZNt2jvOZK1S+EKmmbaZtpL6KCqGGK48fTIZGJ93ZzVMhAA3NLlLNpvMEkDpIpm+M34 OA4CozK7W1MNyT/8OGaQdLtk98a66JF9+2nw21gLf1exrc5zQU6KKB+yCss98Y1xuEKy nQGYJuc2B3cWcfavyB0izhctWsGX7N08uVG/eSFmQXlAEDAJn8eLBcgpozzrXLfBPPC2 zrkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767622990; x=1768227790; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6si9mWEhUYCepCa96A28RLdBxiL+gruBzfgL8pmOmtk=; b=eXjqqBA4TDKkSkMDlzgKDiwJfwgS+AMgwDTnZTyX9AAoEPzaMZAqpYhQ2CZhwu4aYw CO4Gw8EBpNtPWvpLqqvk+kKuqjof7jIM5hTpJ9Woh0qr6JK0bZChO6EudbCWXQCEQjLQ gJNd8dIZXdpkXCPR4/5i5V2xVQXwkGhKG2XUEtxmj+oRwJ/yzP0oD9tiL7Si+6SV+dkh L3jITK2TCs5F5HBKvwulEX24fPmuNaf1lkQhaQxldwahL+PnhOWDyFeWIvFmMX0N+Ir4 /3IT0T7isxoFRzHwPTjsGQpwFRs08XcBVdodo3mIUPl/YPhYnLGmyjxMJv52sWZ3DbHN U/QA== X-Forwarded-Encrypted: i=1; AJvYcCXr7+nMYIsUXxG7Rzj0QM0v4qLa7Bw9CPpEjq0tgmCwXHTQi8McoBSXdYpRxhEIsbbF1EFbr1Zgmo8=@lists.xenproject.org X-Gm-Message-State: AOJu0YxWsEvQ0VNRVYSG6zdh542vaXma6fK4U0l4wI2+uK1axbQ47ILf 7lAjncZR0Po890F2yaKv5Q4Dhp48XwajDH3SF6pNV+yenUzaFun5Zlzzh5TNOt09Fw== X-Gm-Gg: AY/fxX7hKpmrcAuj5YF/xdGbcjt9sJ3KVMiY0fx7UQ3NxRatkyIplDbZ/XFUsVRljVt yaNWQesfKI9ZjRsou+/UBP82Rkv8JuK3gJSNQw5otPK/voMWBDyWbOTbka764ypJNqbst8ntife Pq6r+qnNBijVyIiQ9kujiUz7TEEIUjqq5jiLXuEmry0Y/hnaI6lfqQVHxYr42tX5kKNn3qMQ5s4 mlgYDW/d38c+9OyiyabFoI9Z9SR2fM/Y4JiwoWmH+EqxPMBWNt9CS9hkUx54Z7jRQDPCScseoYz h1MPKWLbmIRCcm5naqwJnqCq74tj9OtvehSWyUvmxZigXyBN4jiPXnQ/wx7c/ff2XAMSdVlM7XD FF0AkKI47+GdFxAjOW6xVGruki6EhUePxJQKKY7QfIcydiTrngbEKtPS730/lCSC3s1+1/nHHq0 8tJGUeLQyAdkZkRSDNshLXYPjhtkmbkMB+DWjCVz/+kQYuVDLg9O4AABpP3Az8xUyAJZwmoKs24 Ib3AJDobZEgxQ== X-Google-Smtp-Source: AGHT+IFId92m8FLvtkRLqxHo6o7HQ94iWBgVgItjHW8SokaeDql5ULrUFH+ZVFry3gF5ZcPqzuY9DQ== X-Received: by 2002:a05:600c:638d:b0:477:afc5:fb02 with SMTP id 5b1f17b1804b1-47d4c8f4972mr351702685e9.21.1767622990197; Mon, 05 Jan 2026 06:23:10 -0800 (PST) Message-ID: <9287e959-dc85-48ba-ac8a-97589b79c5be@suse.com> Date: Mon, 5 Jan 2026 15:23:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 1/3] 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: <5d10efb00eebb35861135280dfee391d0c55cf0d.1766406895.git.oleksii.kurochko@gmail.com> <360d4fb9-52b9-400d-93a7-baa4b98e708a@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: <360d4fb9-52b9-400d-93a7-baa4b98e708a@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.12.2025 16:25, Oleksii Kurochko wrote: > > On 12/29/25 4:06 PM, Jan Beulich wrote: >> On 22.12.2025 17:37, Oleksii Kurochko wrote: >>> --- a/xen/arch/riscv/p2m.c >>> +++ b/xen/arch/riscv/p2m.c >>> @@ -1057,3 +1057,188 @@ 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 costly 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(const struct p2m_domain *p2m, gfn_t gfn, >>> + gfn_t boundary, bool is_lower, >>> + unsigned int *level_out) >>> +{ >>> + unsigned int level = P2M_ROOT_LEVEL(p2m); >>> + bool ret = false; >>> + >>> + ASSERT(p2m); >>> + >>> + if ( is_lower ? gfn_x(gfn) < gfn_x(boundary) >>> + : gfn_x(gfn) > gfn_x(boundary) ) >>> + { >>> + for ( ; level; level-- ) >>> + { >>> + unsigned long mask = BIT(P2M_GFN_LEVEL_SHIFT(level), UL) - 1; >>> + >>> + if ( is_lower ? (gfn_x(gfn) | mask) < gfn_x(boundary) >>> + : (gfn_x(gfn) & ~mask) > gfn_x(boundary) ) >>> + break; >>> + } >>> + >>> + ret = true; >> For this case ... >> >>> + } >>> + >>> + if ( level_out ) >>> + *level_out = level; >> ... this is correct, but of "ret" is still false it very likely isn't, and >> arranging things this way may end up being confusing. Perhaps "level" should >> be constrained to the if()'s scope? The caller cares about the value only >> when the return value is true, after all. > > We could simply move the "|if ( level_out )"| check inside the|if| block, but > is this really a significant issue? As I said - it is (or has the potential to be) confusing. No more, but also no less. > We still need to check the return value, > and if it is false,|level_out| should just be ignored and there is not big > difference then if level_out will contain what it contained before the call > of check_outside_boundary() or it will be set to P2M_ROOT_LEVEL(p2m). > > Alternatively, could we initialize|level| to a non-existent value in the > "ret=false" case, for example|P2M_MAX_ROOT_LEVEL| + 1, and return that value > via|level_out|? Might be another option, yes. Depending on how the ultimate set of callers are going to behave. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 05 14:25:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 14:25:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195430.1513367 (Exim 4.92) (envelope-from ) id 1vclW2-0007bk-B4; Mon, 05 Jan 2026 14:25:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195430.1513367; Mon, 05 Jan 2026 14:25:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vclW2-0007bd-89; Mon, 05 Jan 2026 14:25:02 +0000 Received: by outflank-mailman (input) for mailman id 1195430; Mon, 05 Jan 2026 14:25:01 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vclW1-0007ak-KZ for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 14:25:01 +0000 Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [2a00:1450:4864:20::32b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 51a2fe92-ea42-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 15:25:00 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-47d59da3d81so8844815e9.0 for ; Mon, 05 Jan 2026 06:25:00 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4324eab33f5sm100662528f8f.41.2026.01.05.06.24.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 06:24:59 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 51a2fe92-ea42-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767623100; x=1768227900; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=3gMqLT/CFiOQX20PMXoEv4yOZ+d5HtUyUw7rUQE9dAE=; b=QuyCZq3geUzUtJsdUMHR80f55+YHwscm+KoYmjN350OYnwkFx+mc9FTlyERVmfwEDR DRshI+MypPOtTwjDLi+o1WXjf03wG8j7FM/t7TGen+9jK7ec35uBX7O9SpPH+7Hs0py0 UKeG4Me7a799Zr7OT6qhoSTo794jmM3DmkscEfkwzvf3pS2J5CakBrRV1QYoFbb8vqPG gwD+VwbAPVzPSLhYEUSF/ln60EZoWsXbFr2GlPhe4A2o0NTxC+WS0FR0oL8VQW9NsXR4 smB6aIJLlCkTfQJ1Kke9sZZyYABpZj+ZjaSjVpBI1suKLJTkOVC3zTfTkMhjZh8kSN19 5rpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767623100; x=1768227900; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3gMqLT/CFiOQX20PMXoEv4yOZ+d5HtUyUw7rUQE9dAE=; b=nyLzz08NBvCQnGYS92mXXiFzYSwEb7Zm6xWg4qOQrCUiafYhTtGcG2DQV+kFxn0H4q tbNvrZM95HHkZ6y2GZuXlllFD3LtT86VmCuVawPp982I+urFa2YghtEEGkqBW/MzHt5I 8wnytPZKd5klNeMdLD9eTr7fDjOb6lquE7hwy5s470s+qbhiyFOMnThbrqXw1TYdZNoG wQVgG/YnZMuh39a9UE2s0LAcn1T0E1InZFeudovoHkUKg+0bX3A63ZFm3SIHvUK/wWtv +gdmlqmLFlRel3lVU5vOB4/bLXXrfYnT8w9nhrpa1soDK8tfynBrLwtoERGW9qA7m88D 534w== X-Forwarded-Encrypted: i=1; AJvYcCX5J0BMujHMLd1AR9L0d3g5Pc36cbDHfn4yeZzp1P+zMwflemrgGihc/YP85qy7/jmhu+pmJHS8q7Y=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy7APKEBmRg4rMLku3Eg3SXhvE04OkmnfH5D0n67ykBzCS4Ev/s Q/iiTspDf/AP9u8rIcBucUBHL3cs6fcyd/jP1kmLW91txhFuvfQHmbX7IYCana4doA== X-Gm-Gg: AY/fxX4EpOGOzmHIvis9NejWJ5yrFtf/KRl1DdBmD7Rlt+6FFRjXNC5bP/RB2Sv1wNc h5dntUmgOjlxqdhJNQbNXOSAIfXUUn9PV6ptGKzFfHxCUln/oFDA7kMU90XrNZrpCVAKQOVLhDL ds6q6A2QZpoKPhV0xYtNEOEhDOVbk46iD5d46lC50Pnv0Aj3rdYxExNXs0fp4J0USBqpUrJ6fdR 87/n1c/KcTUoxGqNTvoXu2ovZiaX7FGGwg+h2oMPkzjXb/AeCwSgU+RRzCvUHbDJQxtSzANBCAd 86xxUJpIDGAKYqhdl9MDnHCwUab45G4hgy8ZNfPC+atKYSfqounEmP5642sGAZuKrPaKJ7sfK/F lw6lxY3cmR6ssB/oH3Buss5f6pU8wtvQbGEYZp5iIQuE41Pl95fMmp8lh3lX0GnmWv3hcKMH2K5 MiPDSfKbJpmtkfm0bJCEe9N4GS87GlSShCYw+wcQ0R/U4B6IAT3lGxLORCi7kF3fN8/kvyCO5N8 bM= X-Google-Smtp-Source: AGHT+IHpU8IiDPanCMLgsSJ4So9NkzNYI1iTXldwl49PLS0ncjedA/PYsgVDYaw6ROvzZI+4yhosBw== X-Received: by 2002:a05:6000:4313:b0:431:cf0:2e8b with SMTP id ffacd0b85a97d-432aa40933cmr10579266f8f.29.1767623100172; Mon, 05 Jan 2026 06:25:00 -0800 (PST) Message-ID: Date: Mon, 5 Jan 2026 15:24:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 2/3] 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: <127d893e3b6a0da1195f9a128c8d0591e6ef473d.1766406895.git.oleksii.kurochko@gmail.com> <0a4fb29a-a0b5-4e20-91c4-425702677d11@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 30.12.2025 16:47, Oleksii Kurochko wrote: > > On 12/29/25 4:13 PM, Jan Beulich wrote: >> On 22.12.2025 17:37, Oleksii Kurochko wrote: >>> @@ -370,24 +396,96 @@ static struct page_info *p2m_alloc_page(struct p2m_domain *p2m) >>> return pg; >>> } >>> >>> -static int p2m_set_type(pte_t *pte, p2m_type_t t) >>> +/* >>> + * `pte` – PTE entry for which the type `t` will be stored. >>> + * >>> + * If `t` >= p2m_first_external, a valid `ctx` must be provided. >>> + */ >>> +static void p2m_set_type(pte_t *pte, p2m_type_t t, >>> + const struct p2m_pte_ctx *ctx) >>> { >>> - int rc = 0; >>> + struct page_info **md_pg; >>> + struct md_t *metadata = NULL; >>> >>> - if ( t > p2m_first_external ) >>> - panic("unimplemeted\n"); >>> - else >>> - pte->pte |= MASK_INSR(t, P2M_TYPE_PTE_BITS_MASK); >>> + /* >>> + * It is sufficient to compare ctx->index with PAGETABLE_ENTRIES because, >>> + * even for the p2m root page table (which is a 16 KB page allocated as >>> + * four 4 KB pages), calc_offset() guarantees that the page-table index >>> + * will always fall within the range [0, 511]. >>> + */ >>> + ASSERT(ctx && ctx->index < PAGETABLE_ENTRIES); >>> >>> - return rc; >>> + /* >>> + * At the moment, p2m_get_root_pointer() returns one of four possible p2m >>> + * root pages, so there is no need to search for the correct ->pt_page >>> + * here. >>> + * Non-root page tables are 4 KB pages, so simply using ->pt_page is >>> + * sufficient. >>> + */ >>> + md_pg = &ctx->pt_page->v.md.pg; >>> + >>> + if ( !*md_pg && (t >= p2m_first_external) ) >>> + { >>> + /* >>> + * Since p2m_alloc_page() initializes an allocated page with >>> + * zeros, p2m_invalid is expected to have the value 0 as well. >>> + */ >>> + BUILD_BUG_ON(p2m_invalid); >>> + >>> + ASSERT(ctx->p2m); >> I think I previously asked for this to be moved out of the if(). Else you >> may not notice a caller side issue until a point where a metadata page >> actually needs allocating. (This could simply be folded into the earlier >> ASSERT().) > > I think that I understand your intention and okay to fold ASSERT(ctx->p2m) > into the earlier ASSERT(). > Just want to note that generally if the metadata page has been already > allocated and then p2m_set_type() will be called with ctx->p2m == NULL then > nothing serious will happen as basically ctx->p2m is needed in this function > only for allocation of metadata page. Correct, but how would any particular caller know? Yes, there may be special cases where a caller does know, but imo the code is going to be more robust if the check is always being made (forcing all callers to set ->p2m). Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 05 14:44:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 14:44:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195442.1513377 (Exim 4.92) (envelope-from ) id 1vclop-0002Mb-Rd; Mon, 05 Jan 2026 14:44:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195442.1513377; Mon, 05 Jan 2026 14:44:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vclop-0002MU-OH; Mon, 05 Jan 2026 14:44:27 +0000 Received: by outflank-mailman (input) for mailman id 1195442; Mon, 05 Jan 2026 14:44:26 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcloo-0002MO-B1 for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 14:44:26 +0000 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [2a00:1450:4864:20::32c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 06e28607-ea45-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 15:44:24 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-47774d3536dso11305e9.0 for ; Mon, 05 Jan 2026 06:44:24 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d6d13ed0asm165934995e9.3.2026.01.05.06.44.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 06:44:22 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 06e28607-ea45-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767624263; x=1768229063; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=v2XZa/+OUht4lzTXEfmEYzo3p577uCWIJ6aVSCp22xM=; b=Sp9+hxR2ryjaYS617xM+iDCQle+6rAJyTE3uxepBK2xHUUFndxgQuZT4iLDWCjyPB9 7RMIt76/4h/gj4SGjB5Sdwuz6KJNtkHcX+52mYY7Mcmg8YwGqgfGEcR9Y3N0dP/8Wzgi EFQeM0YKZakz7Ty7AEt4hFuEOjVILBQgHIC2hiNhRrNd4IZu3AQ4OBzl7jHzWlIe3Oov rQDPy8KJrQwT3qwIbnn9VBJdGU0Ir+2irAPsQwV2nzFyUVj7VnRM7//BHnHO+vLnbYuE 0mvfM3RvTiYO93OelUTUX3H1/GW7g/3DZOaayO0ZkW8hMUVGIHSNcmSvOl0Xrrmgjyq1 dwSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767624263; x=1768229063; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=v2XZa/+OUht4lzTXEfmEYzo3p577uCWIJ6aVSCp22xM=; b=ftXz3Gp8sQ9++eXr1PkiX/VJHusXNg76Mw14Q6qv7ljn1Pa1s/LGSQOVoJTJytXrlw 7qKT0xcZw82uOtcNQ/HzG7ZJSvSzsl6tbmY3Vu5grEVb48mj62oBKEoSN4jq/vJ8yRxs W2NKKzIpvdM4pytsk5OPQO4ZFSd1h/CXUmN8xcS512+Ept3cUIX4bYnj5oxzFgpEsNcX xvyHrJuQy5izxUG3lXf9BYBAhXaZGJNyRzETdd1SDy49chO2ai3X/vn5er2i4Zlotdbm N6nfP4HtmUPunWoy3Oomjs47aHIZP3X170636CdynGkM5998G7Q0WnJ30xV+HzS0L+BP RdpQ== X-Forwarded-Encrypted: i=1; AJvYcCWCVvw9DFkOT4COwhRfxlhqYRuSbmQvTx+/szp5vkeRjDd4nrnVBvscYLCtezbXnYgaDo+I+gH9Spk=@lists.xenproject.org X-Gm-Message-State: AOJu0YzaOClO2gcO+u9HBCupyVsb+EGsltRZYfk9o/qLclASIQKKRQtm vFz6s/K7jJMjDJl0HC/zFW4t24QgjsVVAeT/yrBgx+VF79PHE4v9YfzP6wffp3Zs7A== X-Gm-Gg: AY/fxX44RmaCVVawyXfEWQZjV9WGkG2kTYmtKEw3NvAH8czMXsa7Y8+mCLVJJoBWMyU RpbU3f9mDM28ZE4nZBiIrAbojGMcPL+iN3kV2Np+G8qtNHYGj1W5RS+jiJTq9C9wI/ssw+VFOzo 1g2/B9n7OxQuX3A4HcghCzaIx/wOnLUvBrc94Y874UtvETHtZt8/Ec+SK8slQWAdQ+PXplnVzVM OANcsEAXhZG55b69Zfbv5XaYvh/7R7OZ/V8N6EHDbqqiD347ydpyu3Z9ONyjhPzGUrS5JXq/6ti EymBTOGmzylcx7z5gs63iRHWcHPC0mMBQarmmVYc7nwfUW5Q9GMJ/E8I/NhW9fNIN0uvhexQzLq uNc1HXfuS82j6Vb/sy2ggOoN1oB+eTDtItDwnasZeJ/HKUXv49ONlqY+LP5xGD03y19CHQSVms7 FhhAvJDNJRkp1OfUw8UolSPc75ZIcXesidQYuDJ+lMAFyfKECE0BULx8rCwzlV8Ee2mwhbIuVx7 uc= X-Google-Smtp-Source: AGHT+IFeQqpVgX73VR7ao41n1Yipw9jK1Ar6juD309qcJVIGnx8BFGjbwpDYbpRFKsZEhbnTADFWlg== X-Received: by 2002:a05:600c:6a8f:b0:47d:52ef:c572 with SMTP id 5b1f17b1804b1-47d6ba7ac36mr74123265e9.1.1767624263289; Mon, 05 Jan 2026 06:44:23 -0800 (PST) Message-ID: Date: Mon, 5 Jan 2026 15:44:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/4] xen/arm: optimize the size of struct vcpu To: Oleksii Kurochko Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , "Orzel, Michal" , xen-devel@lists.xenproject.org References: <0756ee97dd47f6acdefe593694b743eb6bfefacb.1766504313.git.oleksii.kurochko@gmail.com> <9f2c9e4a-64e3-4e5e-b5da-976ab433f6cd@amd.com> <9f343323-2743-4bd6-82de-afe3b48adb70@amd.com> <096a8105-667e-43a6-856f-3ed52fb1c0a0@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: <096a8105-667e-43a6-856f-3ed52fb1c0a0@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 31.12.2025 09:27, Oleksii Kurochko wrote: > On 12/29/25 12:10 PM, Orzel, Michal wrote: >> On 29/12/2025 12:08, Orzel, Michal wrote: >>> On 23/12/2025 18:01, Oleksii Kurochko wrote: >>>> When CONFIG_NEW_VGIC=y and CONFIG_ARM_64=y, the size of struct vcpu >>>> exceeds one page, which requires allocating two pages and led to the >>>> introduction of MAX_PAGES_PER_VCPU. >> Also, I think it would be better to drop MAX_PAGES_PER_VCPU in this patch. > > Then I'll update alloc_vcpu_struct() and free_vcpu_struct() to: > struct vcpu *alloc_vcpu_struct(const struct domain *d) > { > struct vcpu *v; > > - BUILD_BUG_ON(sizeof(*v) > MAX_PAGES_PER_VCPU * PAGE_SIZE); > - v = alloc_xenheap_pages(get_order_from_bytes(sizeof(*v)), 0); > + BUILD_BUG_ON(sizeof(*v) > PAGE_SIZE); > + v = alloc_xenheap_pages(0, 0); Just one nit here: As (iirc) previously indicated by Andrew, please avoid open-coding of alloc_xenheap_page(). Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 05 14:51:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 14:51:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195452.1513386 (Exim 4.92) (envelope-from ) id 1vclv1-00048n-E8; Mon, 05 Jan 2026 14:50:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195452.1513386; Mon, 05 Jan 2026 14: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 1vclv1-00048g-BH; Mon, 05 Jan 2026 14:50:51 +0000 Received: by outflank-mailman (input) for mailman id 1195452; Mon, 05 Jan 2026 14:50:50 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vclv0-00048a-4m for xen-devel@lists.xen.org; Mon, 05 Jan 2026 14:50:50 +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 ebb183f3-ea45-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 15:50:47 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-47a95efd2ceso126838635e9.2 for ; Mon, 05 Jan 2026 06:50:47 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d6d452a3bsm153988995e9.11.2026.01.05.06.50.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 06:50:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ebb183f3-ea45-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767624647; x=1768229447; darn=lists.xen.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=AkszFi0SMt9EIcyN2EucawmenV3NU2J1E6gDS8B9vxY=; b=EqJB2ojlamIHBy+e8zziskz8Yj4stLjOIiDZodipKq62jB367Ql/3fdjm+EjngD5BY TbM+XCiAF2o+aH8lMnmpEAqAZCRPF2b1ILCyqRd+Ezh4LSQ4+YtTImLBbTNsRMJ8L7A4 Djj2zzgY20Q+aXL98SrvPMXyi/mNMOfxDbutRIJx8169uF2DbaY1VMRUbzizTj4ofMBk J7I/kT6qUBhj6XcjE5I3D345crxAAQO5ZixdgKE3VT2gGs/PNy3y4ciPBDOLuTR89gVM kBVrC2/SqL4h+zy623iS821zoHwymUowv+3ZYiwUrk9hILwmOMfkvAUKDaF8SAMg8WS2 P+IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767624647; x=1768229447; h=content-transfer-encoding:in-reply-to:autocrypt:from:cc :content-language:references:to:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=AkszFi0SMt9EIcyN2EucawmenV3NU2J1E6gDS8B9vxY=; b=Q8g4FUP9Kmsi04aJw0CsN1iykGiR4Cgpana98ddYJkk9cSbLwBfXt5GhXio5qut+bD 4Y8kkNEwGK/FPfYjnJfSxgqSVCpbxBRuXUuCKjPP6c77Qk8pC5U98TdSkX0+kaduC+dn yK9uJbD/Mbocngpw0HV7borv00LzYiyxZcgLrgZNMVB9LOPVunnbOjZTWOzQhU1fcqml IC9VQFe7KTUwgVyrx8Q0SHWCbMZYC4vng156ACVKL2VG5OLFC2QvnOXvnAnIbnW+uxOX wv2acCyQlVU+uTgPW5wy26St/2LL6KPI7sCZck6qx90eze4sL+r3yt4mxjE82Bnfx05q P0YQ== X-Gm-Message-State: AOJu0YxcHbW3NQJ88/gtYoE5ylZBuEcGEoUCz5ayV8+rhFhjrKYiFvEK WciyJ56VA33UTqXdV05lWXESf6sIKGQYYaUW1mOAuH43HzbpTkNNXDnNiWakEsyDww== X-Gm-Gg: AY/fxX5CJqi5vSoxYInFJHYkmMYyx2C9LLQf6zqd8MRFoMj3T+45HKtmja4+Cgk9l3O po7H0RhGjM4jCuEo09AsD5L1TV3GpejNkIizVvk9ZOjLmiyfXhMn7JIOytiZpTSJUjUedlxB8AP 0YgTTFr6IJK/Xupbc8MeHuOcfIQnSZsPfoRhslmqH7Qk3IxPkoqcbV42gISh4LVvq+NvW89b+/y azPrLGp+ibPijjEo+J1hfOqVovHK+xg1sXV5voN+GvKuwQ460rLXCvJw72vSLSR1JfEhVR4LCTA bz2/e+BCZIURO6BFcXvpq9KSZQjillzlKA6ywRopulDXV2tdBjptnf229PSPCbBRQ37DewU6P/M AkXMIfs3ZdfiOk+LfziYaop/+xzaRrmH+utGBaAaoCHnAeSShnB++H4qxdOMBSHa6B+CGN7FQCX MKaKiBxOIJk6sdzZYahebA5hMho0A+oLqYjoPiOTVw1amORuBSE93rniCPddhpfFBezepH8WTfv 3I= X-Google-Smtp-Source: AGHT+IFWOXrKpXO0AzGK4GY5IibfyG3pyDn9QAJKNg5ULkz0pnXCQB/TlOLggKIq4M7ml8ZJJVFvtw== X-Received: by 2002:a05:600c:4686:b0:47a:80f8:82ac with SMTP id 5b1f17b1804b1-47d195a08c8mr661239935e9.26.1767624647094; Mon, 05 Jan 2026 06:50:47 -0800 (PST) Message-ID: <4f49c839-39c1-4562-87b7-69ee9d8b6aef@suse.com> Date: Mon, 5 Jan 2026 15:50:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [BUG] Potential Integer Underflow in Time Calibration Logic and Live Snapshot Revert causing DWM crashes in Windows Guests To: =?UTF-8?B?0JDQvdGC0L7QvSDQnNCw0YDQutC+0LI=?= References: <3ef6bcd6-2936-46f8-a7d0-54cd965a6861@gmail.com> Content-Language: en-US Cc: xen-devel@lists.xen.org From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <3ef6bcd6-2936-46f8-a7d0-54cd965a6861@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 04.01.2026 18:29, Антон Марков wrote: > Component: Xen Hypervisor (x86 / time.c) > Versions affected: Potential in 4.17-4.21 and unstable (tested on 4.18 > with high vCPU density) > Description: > In high-load scenarios (24+ cores, heavy Dom0 load, and frequent VM > pauses via DRAKVUF/VMI), Windows guests experience Desktop Window > Manager (DWM.exe) crashes with error 0x8898009b. > The root cause is an integer memory overflow in the time scaling logic, > in case if the time calibration occurs simultaneously with a snapshot > reversion or RDTSC(P) instruction emulation. > Technical Analysis: > The get_s_time_fixed function in (xen/arch/x86/time.c) accepts at_tsc as > an argument. If it is less than local_tsc, a negative delta will be > produced, which will be incorrectly handled in scale_delta (Or, if > at_tsc is zero, a race condition may occur after receiving ticks via > rdtsc_ordered, time calibration will occur, and local_tsc may become > larger than the tick values). This will result in an extremely large > number instead of a backward offset. This is guaranteed to be > reproducible in hvm_load_cpu_ctxt (xen/arch/x86/hvm/hvm.c), as sync_tsc > will be less than local_tsc after time calibration. Indeed, this will need fixing. > This can also > potentially occur during RDTSC(P) emulation simultaneously with > time_calibration_rendezvous_tail (xen/arch/x86/time.c). > Windows DWM, sensitive to QueryPerformanceCounter jumps, fails > catastrophically when it receives an essentially infinite timestamp delta. > > Steps to Reproduce: > >       Setup a host with a high core count (e.g., 24+ cores). > >       Run a high density of Windows 10 DomUs (20 domains with 4 vcpus > each). > >       Apply heavy load on Dom0 (e.g., DRAKVUF monitoring). > >       Frequently pause/resume or revert snapshots of the DomUs. > >       Observe dwm.exe crashes in Guests with > MILERR_QPC_TIME_WENT_BACKWARD (0x8898009b). > > Currently, the lack of sign-awareness in the delta scaling path allows a > nanosecond-scale race condition to turn into a multi-millennium time jump. Just to mention: I think scale_delta() was never intended to be called with negative delta values. Hence my plan is to deal with those call sites which may encounter negative deltas. I hope to get to this tomorrow. Thanks for the report, Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 05 14:55:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 14:55:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195463.1513396 (Exim 4.92) (envelope-from ) id 1vclzt-0004jf-0V; Mon, 05 Jan 2026 14:55:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195463.1513396; Mon, 05 Jan 2026 14: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 1vclzs-0004jY-U5; Mon, 05 Jan 2026 14:55:52 +0000 Received: by outflank-mailman (input) for mailman id 1195463; Mon, 05 Jan 2026 14:55:51 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vclzr-0004jS-Fp for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 14:55:51 +0000 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [2a00:1450:4864:20::32d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9b190ac3-ea46-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 15:55:42 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-4779adb38d3so93124225e9.2 for ; Mon, 05 Jan 2026 06:55:42 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d6c0c148bsm57757175e9.18.2026.01.05.06.55.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 06:55:41 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9b190ac3-ea46-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767624941; x=1768229741; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=UCbETxYKREBNzUds4ADq3xqV9KAq1CS2qCXv+CKwZd0=; b=K4wdpZ8Pg72LOv5xId5URHRgPbyQmdKiebkyETFt2XO0mLKUO48X1A0ecvbya6Pb1H tcowpx1aKjqvO2bBehxJOOcLM4+fqVSzMRL/x/1P/Kedp0PzTn64nX5ttxlO3Hp2M2iJ VzL9Y1qJMC/3+vNndElEO6W8r80tfftKh1p9tMD4RIUYuq4ojaG7O4r+pchsHPB+4RyR WrqkvPgXxauhNSs3Z7tPRMQrrDPwDBR5BkWwAZD3CGWXLRDkIBPYo7koRe2kUGW8C7fB H2wXShsQf7p2E50LaStN/UNOdlPtdvQZR4LqAxlhHSFYJmbmtT9xbZnWaktP4ANOoAGl WE/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767624941; x=1768229741; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=UCbETxYKREBNzUds4ADq3xqV9KAq1CS2qCXv+CKwZd0=; b=oca/EzrDcr2IDt5p1xIomp4dRq2+3zgpT46K4OhBzo54mwsSHQ3FBBOQBz2/APxrFB 4dOxWN3FXfcBinJ08wuhZF8vg1C1YrS2TZCJpJ2cTrsm6XP38USWKpi2LDi4tzExuK0K iq57f6CKMliqO+s+qnZdNQM3T5e0fLupjjB2L9E5we4vJCaVBfSvDfvwRr2M4TKSWT6f Rh4H6xd3cNgnPZ1OfAD625H/XZsjFcVdL9nR5UUw2Clo3bPLuMFaXqE+XVqEofHDqRwd tcDA+vPpDcM03bV/lmeMmanaLSEFVfZC9NMEFun+7hpwAILyv62oI9S6Ece+gBZe1/Wm WcNA== X-Forwarded-Encrypted: i=1; AJvYcCXKB3WQD9DD3A4zFfQCiM1rIWNpRFps5/UP39ZKn3eibD4T6Z1KLoCj8XVomW7USZrsF96BQLwVwtg=@lists.xenproject.org X-Gm-Message-State: AOJu0YxV1rw6fKBDWi7+xzy3+eW8axCs+THnprkQXlILBPRUREkpUSi1 cUQ9o4Bx5+z2k70mP9WEEFvjitwAURdimPBpFAUcJRsiwIy3YkKIRODNe0XW+zmPaA== X-Gm-Gg: AY/fxX5Wxe1f2dI9eM1C9FBfRXa+EUJxalhNcuUK5FR0f6iN5JqXVkVDnxn6NyDW4Kn IRO+APcy8rXIzBnuEoVfTinzcpsWf3lzfTqMeHFf8mXSOEzwksRMU3lunvMsdrvFxX0KchsiDNY WIFMK4ctBcsLLmsVUVRNTkQuZrDx9PGLKFrH+b5fjNGwOBIGiipeCV5WMw+UqCq5SAUa8o9Y2AS R2GTMF/0yBfZvAIyrtvg9t+HyZFvLFEuHZPfugrl+fb4Rq792jj+pZEpY9LfJr8AeCb/06nHu0l SoJHgQkK1MR7cGf1N1RGWfg9wkfIIf6vJwJNKynotm2EOO1md0vkO3ViqHOq8dy2ZldNy3QXNPE TktlR46oZPnK6tnynCFvyiPeQ50PJNpHsqcz6bNsZ9SyOxKp7dAdQR6G52EQVIYxsTyw5/qG02h nafnE5084IKFitYrUl611NHNPPxEGzkvkZEF3cH2/emzdUeiy4EktXeTrxhcJfjavCaym1yBiAo XA= X-Google-Smtp-Source: AGHT+IFHINvgnlyWbdUXWba9Q1jbPRcjuNR9PjTwa2ylez1K3thP6luycJ/GjS3nvfCnVtLjgbr6MQ== X-Received: by 2002:a05:600c:548d:b0:477:79f8:da9d with SMTP id 5b1f17b1804b1-47d19584bf6mr687448085e9.24.1767624941457; Mon, 05 Jan 2026 06:55:41 -0800 (PST) Message-ID: Date: Mon, 5 Jan 2026 15:55:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] xen: rework deviation to address varargs MISRA violations To: Nicola Vetrini Cc: sstabellini@kernel.org, consulting@bugseng.com, Doug Goldstein , 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 31.12.2025 12:22, Nicola Vetrini wrote: > --- a/xen/common/libelf/libelf-private.h > +++ b/xen/common/libelf/libelf-private.h > @@ -84,7 +84,9 @@ > #define elf_err(elf, fmt, args ... ) \ > elf_call_log_callback(elf, 1, fmt , ## args ); > > -void elf_call_log_callback(struct elf_binary*, bool iserr, const char *fmt,...); > +void > +__attribute__ ((format (printf, 3, 4))) > +elf_call_log_callback(struct elf_binary*, bool iserr, const char *fmt, ...); Just one tiny, nit-like request here: If already you touch this, can the missing blank ahead of the first * please also be added at this occasion? Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 05 14:58:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 14:58:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195477.1513406 (Exim 4.92) (envelope-from ) id 1vcm2B-0005bz-FB; Mon, 05 Jan 2026 14:58:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195477.1513406; Mon, 05 Jan 2026 14: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 1vcm2B-0005bs-CL; Mon, 05 Jan 2026 14:58:15 +0000 Received: by outflank-mailman (input) for mailman id 1195477; Mon, 05 Jan 2026 14:58: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 1vcm2A-0005bm-Kf for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 14:58:14 +0000 Received: from SN4PR0501CU005.outbound.protection.outlook.com (mail-southcentralusazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c10d::3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f40bc348-ea46-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 15:58:12 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MW4PR03MB6425.namprd03.prod.outlook.com (2603:10b6:303:120::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Mon, 5 Jan 2026 14:58:08 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9478.004; Mon, 5 Jan 2026 14:58:08 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f40bc348-ea46-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=N81HSWSklfr0s+HkvPFwEE0C1nBlG/tajm7WeDIb6smySEH0G4nEy5pnWpbQBXfl2zspQpmGFj0+dN7yg/08NZxvCjtIm8+T3SLMZ9Ia7oeeGSQJf1HTDHravAw1Sk/Ggk99Qk8srUf80ZnnhvC8DZtZe4M7EUpL0O+PZj0Spotv1izQEcuJnAV1zg+rRneoyrhsFxdKgoPJ2P2ADQ4Sh6JNqa/j/4Zq83F1tEUIOUfapWfRhOmoV5qUso+ZwanD3i4F7JTv8UlzqmLXb7pc7WzDuNLWmp4TgYiAfL0EzvfCH7wvHoNJ+6s9g4Fw5P5wM5CU6HRE7HiHoBzhZLA3Mw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=x3H64XTLbV7Q4tYtJ9M0Bb8wNfaPHGjyyFsHtSDBmlA=; b=jCeIVBXsGJIJp+T5dDl13Jt8khQUSUkLVMNQ/18YCfhDG3vtWrG9RKsqdbCB7h6XNGo/l8D/xpA2yBOECKLcYEIfkiB02UpD9b0enIfTbzWWtdW2SJimEVERlLir3Qmp+N4I9SCACaUaJxFJZSx+gHRV5lSCJc7Vli7ICU4rR7Jj43uCPejj3d4ezEZzFzx8mLu/RvrkUb6QYKk5mn8y4rBO3QaA6kDwjAn3A9EzASWTpYrWzqkOYL88dgXRB1yvJhZrcmLbqChpLJW5MZKbIkABxO9Y9YGsL119HMXclB/fBkAKeWNPChLy0aJpiTwVMUaGm6bja3uhORLFLeNuUA== 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=x3H64XTLbV7Q4tYtJ9M0Bb8wNfaPHGjyyFsHtSDBmlA=; b=UM/a1FDU+98fPKig5dcbacDv2JbGBfimfn6ajoERAH0QFfT1UJY6nGUuJFCctHY6MQdpiSg9ZRlQfvMs04Qff0162tVw3spGzCJ6fwFT4bNDPz5wopjGD+R5aQsAvFbFw2F9L7XGzESx2p55dnA6u2bnpQg97WQNRGIS0hQslgs= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Mon, 5 Jan 2026 14:58:04 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , sstabellini@kernel.org, consulting@bugseng.com, Doug Goldstein , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org Subject: Re: [XEN PATCH] xen: rework deviation to address varargs MISRA violations To: Jan Beulich , Nicola Vetrini References: Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0042.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:152::11) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MW4PR03MB6425:EE_ X-MS-Office365-Filtering-Correlation-Id: c65d5db5-2c80-491e-2da9-08de4c6ad680 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?V1l6ZFJNakJsZW4yNExhQjBkL3Q1VVZ0VHNIbjV1a2RFbGdnSE95NDlhTlYw?= =?utf-8?B?TkhLSWhSNlI4WDY4cnd0MW1ObVNqbDFBR0MwZXh6OWVNb2NzOVkxNkxsaXhP?= =?utf-8?B?WDZiejNjZ1ZnbHFrVGVUd01aOU1lTkg3Y1I5ZWNGa3pIUUF0cVBYTTZuQXh0?= =?utf-8?B?Q3RJeitwMXlUSzJmTzJRTmQxeExkbXZhU2dUN3ZQcXBydXN5VTBXVzFpaFNF?= =?utf-8?B?VFAxUEppUTFkUkFGRm56SUtCcVRnUk5FY3NZZmlZY0x4NnRUV01aNFQwTldH?= =?utf-8?B?MC93NCtOUzYrUVNzcnJOaWlhOWZ4anJkL2F6ZXVhdVB0MEdpaDE3MHBmWWdy?= =?utf-8?B?MzZLVDBMZTBmM0pNMTFHeENXNm5hc1ZaWklTcXlBZTZvYTd4WVBXV1l4M25z?= =?utf-8?B?RUdWbUxidTVNcEQvREdQUHhjalE2R2F3ajdSZDFxcnBoQlY3cmllbVErRzVz?= =?utf-8?B?VWQ4Y3luNTBLOFpJejhhdkRyNk01K1RlRTAySVhhRFE4VE5PcmQ2NkV5NTFl?= =?utf-8?B?cXpRL3JGb0EwMlBrRisrYzVLTzdHM2RDbW9Fa0tZTGZlK09ENVRETFpwMzcz?= =?utf-8?B?ZWRZb2lBMkx0dTAzT0ZLVEllUFAzeVZZa3lBUVREemNMbkltSklDdWo3Zi9m?= =?utf-8?B?blFZV05QQW1ZcDR2Tmgxc2RsaHBCdnF2czhJdmFHdTJycXQwY1FuQTViamly?= =?utf-8?B?YkZoWEdnWkFxNlJ6cTVMQlNvbkxKK3FLalBUclVlSy8wUC9Rcmxtb0xhZThv?= =?utf-8?B?YUN5MktIOEhpQmFFZERrc1NNTG5PalBHUFRJR3U1Qm5ZNXlSTFBxOE80UU5D?= =?utf-8?B?cjVDSGQ4aEZqOTNRazJVRVNVNEx5bHJxVTg1M3JmcjBOc05Oalp1NjdkWVdM?= =?utf-8?B?TE50dFVQcFFYNGpEdWlpZ29kWFAvbHkxRng4WVF1Y2MyNnM1Zi9wQU9TRjlT?= =?utf-8?B?dUd2bUtmKy94OElBdkd0RUlaZ0VnVEVCRVk5dXlIQzdlNXFKME1IcDYxSENm?= =?utf-8?B?NGVxc2RranJsTDRUek00aklSUGRHTjUxK1NObTJSV1h3UDhiTVovYVgydlpD?= =?utf-8?B?R3VhazZiOWNjMVdYQzREQ3Ixb05kSEFXRnBtWVowZk5MSzZCdzN4bmloUkxh?= =?utf-8?B?T2JLWDdEei9wRnhKOTlqOEEzb1pIWm5na2xBOWdibVlPSkE1N0ZHVFBoUUY2?= =?utf-8?B?MjJUWVRleUtoTk5RQnd3RC82QnFteDUxby9QWnUzUU9qZzV5RDBUc1VNd2FO?= =?utf-8?B?QmlQUWQyN1R1WjM4cytKS1p1M3piV21BOWZWeFRCcFRjWnJxdmFlOFFGUm05?= =?utf-8?B?YlpuMTF6QlZFS2lGbHdIRHVFM2xIVkJvSDZ2MEwyRmRtbWZPUzMvTmVMd1cv?= =?utf-8?B?ZVNqbGJyc2FTOU5QT3kxbzB5UnY0d3J6Skw2U09BS0JWdGg4Uy9hTnM3WE1L?= =?utf-8?B?UW1aODNEQ2lnQnkzeFBKYkNIczM1cDVMTDA5b20yY1A2anRZbjZHajY2RTds?= =?utf-8?B?ZVhkK2Z0QnFxa0RGellRbHpNRFU4Qkl1VVlGS0V2elFNWk45SzdnR2ZpY1V0?= =?utf-8?B?ZjNsaUEySXZuelZHUmo4eW9JdWVpRndIQmNJd2xNVUo4eUdCekZ6MDVQbjFJ?= =?utf-8?B?VVRJcnJQMVBxdlh3K09QazBGMDJJR1RxUExrTEhKNi9Md01NUjlvU29aU29a?= =?utf-8?B?eXlKS1JnMkE0akhYbWszczJMbitseVJYZEthcFFqWWtQWkpHN1BDaHF0OUtB?= =?utf-8?B?VUZyZmdKQW56V20raG9jOHJyVUY5L3JkOGxVbkEvTmV0QzNVeTBtcjFMemF5?= =?utf-8?B?MkpqSC9uMEZLd1FsZzZkb1N0SSt5NTRTWmpkOTl6V1UweC9tQjZMRnF1ZVlV?= =?utf-8?B?MW1RcFA1aVcrUm1YNllkbHNxTnAzN3l6Nk8xVE43djdJaytDT0ljODlGbTFI?= =?utf-8?Q?AVnVUtbc6NGWU3TYLryl3902JdGzcde1?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OWNkT3JadWsyYUtiUEdseWJJUVgyZ3RXRVRpY2pDSTMrdE1sMmxySlhXaFVC?= =?utf-8?B?enF5dTZZWkUyUlBJdHlBYmJtbDJRMVF3QW9ZL3dmRS9VSU5LQStESVVkTDU5?= =?utf-8?B?KytmYmRkQkhhWW1lMktNMXB1RE5pRlNJSVZVLzVTK3pEaCs5UTNsVGQ0WDVX?= =?utf-8?B?SUU4MXRWclg4K2c1THNCdXBRelBTTXpXb0oyTFkwOGdPK1lEd1ZxaVNZd3dx?= =?utf-8?B?Q2VCWDlZWHRZZlMyT3luclR1SmJRTG5zTEtrcGRqTlBaOUJ4U2dYQ01wdEZh?= =?utf-8?B?WXhtNS9vQzFwR1RTbmp6enBOakVUN0ZuZGZuT0JJczJrUW5YN05PcTJLRk1S?= =?utf-8?B?dXA0ZGpXVkRydy9ZZk9SL1JVNTNMNTRvT2ViQWNwL0RCYjlUTFU5bzRGN3F0?= =?utf-8?B?TEVDcFY4dXVYRlZEQmZTb1lYLzEvbjAwTmxOSGZDdHl4L2luL1IwVlJQQzU2?= =?utf-8?B?TUo0NTlkRllMQTNVZWlmQ00zMk1PTlVnSnpHNVE3TEp5L29zQUlFS3JiRGd6?= =?utf-8?B?dGhVQU1vQmxYck1OSUtmZlF5b1hzTnk5bUVCN3hqMmJPTW9tR1UvNlBEQjdR?= =?utf-8?B?TnpuOXByb1BRL1JZa3BJY2xmNWoxNVNENFRKSEsvN25zaml1V0dtZE1jUkdm?= =?utf-8?B?WEd5bTJLQXlJVlFSMlpHSmJwM0M4UDJ2cFpjZUp2a3JmNUNXNzl5L3RDZUc2?= =?utf-8?B?MXNJbEp4cjdrQXgrRWNGUFZ5dE42MzdGaHZ5R2YySXZVdU93NGgyQWxrUlRZ?= =?utf-8?B?VFgxdHY0MUZjTlBETDl2RnNqNG1oKy81eFJLMk1td3JvZkQraXI5cjJlUTRI?= =?utf-8?B?UzhMZ24ySUp0WEovMzdDSXRwOWNQU2Q4N1pDZEJDNEFtZ0tpQmF0Rk1FRU1l?= =?utf-8?B?cWIxNTJhb3pERjVSMUdoUjZyYitsOVQzQ28vRzNIcDYwb2RSbnV4OTdNT3hw?= =?utf-8?B?eXp3T2IveWZhMW9JcWltYkxoSk95dkRMb1JyaTB3TzF5SzdZRU5XNEJjMnUv?= =?utf-8?B?cGtlV1lpM1cwajh6TVV5SlBJT25NWGErdDZXMyt6aFJCNjByMG04UFNEMlZt?= =?utf-8?B?Yzh5ZkViS1BVR2xCRnd3TWc4eFJhdUFrS0hGYk5XbzUwYzVyZ3NLeHFmbFlw?= =?utf-8?B?czhSQXJXa1VwL29RdGVHR0UreGF0UXFOeS9uQkNMS0VhNWFGd3dJN1pvenZH?= =?utf-8?B?S0ZmbnovZUdxQVdMQTNaenA5T3BEZHRZUUhvYmRXaFRrM09XeXBhd2tkSGp6?= =?utf-8?B?bnVHdmJNVEtGTWFBWStVK2ZRM0MrUVVON2ZmRjM0SUx5Vmc3bm0wWlVCS0VH?= =?utf-8?B?aVRZRGlWWTJpOGNrUEVXb3ppT1VJcHVzZzdoUHMzLzFsZ1RKeWFTckxjWVFD?= =?utf-8?B?TDlFNW9Ya3owVXhtM0ZvMC9ONnU1T1d4bUdnczdmQllyUjEzZmJjcGo2RWgr?= =?utf-8?B?cVZVMEVWR3J2Z0FyV282ZThRS2xLTHJrUE9NZ1k2cXRIR0d3bUNmUmQ4Yncv?= =?utf-8?B?THU2YXYvZ09ORzBWNW9VNFRueWR5ZGpIOE9JU2hKUys5UGVjY1FqeFh0TXBt?= =?utf-8?B?Uklpd1Nja1VES0prNjNTVS9Gc2RZUGFVNWpUZDAvOCtwMGtiRWlZMFhmTjFw?= =?utf-8?B?czA4bUtHd1pYUzVjbGFPekRhWWphN3lBcTcra2NQNitZK0JRSmQ4b3JCVHdV?= =?utf-8?B?d3l4ZkJIQTk3MU1PN1YvRy9HdmRyNmlOUG9yN21qMVdYQWJpRllFZ2FQRHZp?= =?utf-8?B?NEdiMEcvek55MjVQTm53RUZyeldORTNGVXdMNkpBNTlSeEUwOU9FM2RCWG1S?= =?utf-8?B?ZzR3MDc1Y0FmTjVDR1hveWM2MG9vb0dTd0hNcnkwQ1lnK1l0NHhtdkVJTmVG?= =?utf-8?B?ZHlaUmdxVGZKSXVjWHh0TFRTK1F1S2pQSHlCMzhtQWp3RzdORW12eDJOK056?= =?utf-8?B?c29LSCtvOUw2YUkwTW9zZ21PdmFVTjUwVEZtaXBJV0J1ZHBhNU9MZlBkYkZk?= =?utf-8?B?OUhtRXMrc2VYTFN1OGNVaWlYdU1NWUkxam1MeW1ZN20wVlYwUVVyeElnZTJl?= =?utf-8?B?TG5OOXRDWGdsSEJmdmNRWTgxRUFjbHRwbkxZY3p2NTlEUDloaEpJZ2sxbmcw?= =?utf-8?B?UEdHbnUwa0oreHJybjJSTURYbGhjZ1BxMVUzeUpVcVJ1OHkrazNNdW9tRzF0?= =?utf-8?B?WXhBVEhxaGsxdS9YV25YQWtNU2dleC84Z3hWYitvTzl0aXkzaHY3WDBXTk50?= =?utf-8?B?VlNaUytVY3hRMFBaN0VmSTN2ZTEvTnVkbDlodmhVVGdkblNsdjN4dXlvWUYv?= =?utf-8?B?NHpMUDNMSUlaNDJIcGg3a0wzQlA0bm5kR3NpQVAxS0ZQVXJaNGltUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: c65d5db5-2c80-491e-2da9-08de4c6ad680 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2026 14:58:08.3756 (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: VlExak2rixeBWiHRlfOvv9fEDOb/ck1lxEitte+Un8bXGrqEof+cnF/skVRjLBqrJrTDfrWxNZroHTOoRnX0S8Iwjjcc3jUHsscNuZy2ZtY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR03MB6425 On 05/01/2026 2:55 pm, Jan Beulich wrote: > On 31.12.2025 12:22, Nicola Vetrini wrote: >> --- a/xen/common/libelf/libelf-private.h >> +++ b/xen/common/libelf/libelf-private.h >> @@ -84,7 +84,9 @@ >> #define elf_err(elf, fmt, args ... ) \ >> elf_call_log_callback(elf, 1, fmt , ## args ); >> >> -void elf_call_log_callback(struct elf_binary*, bool iserr, const char *fmt,...); >> +void >> +__attribute__ ((format (printf, 3, 4))) >> +elf_call_log_callback(struct elf_binary*, bool iserr, const char *fmt, ...); > Just one tiny, nit-like request here: If already you touch this, can the > missing blank ahead of the first * please also be added at this occasion? The parameter also needs a name.  I have both fixed up locally. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jan 05 14:58:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 14:58:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195484.1513417 (Exim 4.92) (envelope-from ) id 1vcm2o-00063k-Np; Mon, 05 Jan 2026 14:58:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195484.1513417; Mon, 05 Jan 2026 14:58:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcm2o-00063d-K2; Mon, 05 Jan 2026 14:58:54 +0000 Received: by outflank-mailman (input) for mailman id 1195484; Mon, 05 Jan 2026 14:58:53 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcm2n-0005rw-F7 for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 14:58:53 +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 0cb727b4-ea47-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 15:58:52 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-47d59da3d81so9052395e9.0 for ; Mon, 05 Jan 2026 06:58:52 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4324eaa477bsm101221912f8f.36.2026.01.05.06.58.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 06:58:51 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0cb727b4-ea47-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767625132; x=1768229932; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=WqetD6V/IMpK5hubDRuG4yjp9MxO0CO+FnQXl4IocwY=; b=ePCAW/Fw6ejMsQYS1AaWZJdUe2fzC9hdUwLygUjDVV5zzFNc9NmmSH8/PxpixD4v2U hKenkkZyGWzfUICJ0QLlSsT1K5WDKwo3VneruUDrwzTHuNCyKRn+GKt5f9PF6jHNUTPU +FzaLnxSUHScPHnZnJqUT+V4WqjKgdN4FCyIMy7+zDWCerOO3msKT7zYI0xXMVNvLOmr SuqLSGdrgtmPi12oAk4GiAMmUJxl0p3MpDyjoNFD9gIY9hPlx48KUUDPBM88gfd3ztW3 xvnzMgBkHTr7F84rY+Oc5XJDkZJJJYTvmpPPIZzIzViXtlwOdhKaiGkDPPmTtIYTuED6 BbAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767625132; x=1768229932; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=WqetD6V/IMpK5hubDRuG4yjp9MxO0CO+FnQXl4IocwY=; b=fGvRd06vSbf5azrFnLA9DxImZuQjak8ObWUA8eDC93kR7bM1h+NCxoSGwNMoqkwcSn k7fDr3UHGG+VPpZ3bhI8IGBtugtU5H7vmkQAlkGpBP7BkMwYtqTcQsLq1Kr40FMw93b7 tQcAAzuWhKuCZB0Nrg8ECOrYYGwSqoq5zWDph1CQfdZYKnC7Zxu4YehTE6xGb58RS/hF ckAmpdvadTpHRX52MdtSSZfsI7QRPijLJtXStKKXvySEFaBp6q4FGAPc92iIY1nwi8es 2Qc0qTojKEjwbSldl0UzYzBlGcnXsVFrClpOkS0DAIDsdjsMDurkwWv3fC0y1EhI8xth URww== X-Forwarded-Encrypted: i=1; AJvYcCX9ISYIBAAUAGWZMWQMf5gaqHUrKLN5fdR8mXxXP/mo05vMPluPcy3UaB+q1NbUCKl2QBh8IgKbzsQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YwQeRZMPNI33V7mGtaUR+i5+gN63HvWptw1dtHqJ51V3+ENLwiB 7rZTGvNRARU1wdykEFghQPtKTQCSlJxtN3wEaGQCgMmT4V15kvU38n5J8crQj6jyIA== X-Gm-Gg: AY/fxX4tclW/JEXbraz13JeJyVSYxlJmf+3TSkrHPJRIICO99+g31TZVNVAxYLz5LVW kLiLybVzwJ7Xy8a4IWWJpkZfS/X8af3i2AjUJt7gPloS7QEnzQnjeGKk5uJPIm+omWkLI6c1xMI QJe8D1UHpWno16KvEDLnT4G+Snaq0krzrRfQ/V5tmU4Z2ZuNXqbTR5E16ng/98MpPuVYWwNIzWj 6Srnk+4Ykg8i5/vVYb9X5dvP0EX9LJqeZhT8CpigVBQlzQh9IN2tFzQH1Dix1cv35ceyuMvZtAx Mn1eDB0eMVk1nj6rGs/9CkQN9TbVupvVhisO8ErEqPPVC8sSdqzFVT6qLoaeZWvEaTIw8h8OGyo KS3M8VmJwDFg/5n3qf3L9k6iwVUXugk2MVU5fR4RmITlookzwmwVdN9CHzsWKyBPgr5WD+oxkzq 83yMNjbFcfXTMAtXi2x7xb1YYH1OaYzdSgVR/ZHgg6QUAdq4/d2XzF8mt79klebm6v9Fu/grJ49 C8= X-Google-Smtp-Source: AGHT+IGz6Emlozjr23+vwG+3LC9r0rxGWde1xnh1CzSOlduyPz5YYy2B6jxqiCnwMdYkv7OJQ4/IDg== X-Received: by 2002:a05:6000:2c0f:b0:430:f3bd:720a with SMTP id ffacd0b85a97d-432aa434f4amr11330331f8f.27.1767625132066; Mon, 05 Jan 2026 06:58:52 -0800 (PST) Message-ID: <1ab74598-52f8-4579-b281-bc4e482e2ed1@suse.com> Date: Mon, 5 Jan 2026 15:58:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible To: Andrew Cooper Cc: Stefano Stabellini , "consulting @ bugseng . com" , Nicola Vetrini , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Xen-devel References: <20260105122436.555444-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: <20260105122436.555444-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.01.2026 13:24, Andrew Cooper wrote: > On x86, this is basically everything. > > For ARM, CONFIG_MPU and CONFIG_MMU are mutually exclusive (with > CONFIG_STATIC_MEMORY in the mix), as well as CONFIG_NEW_VGIC being mutually > exclusive with the other VGIC infrastructure. > > No functional change, but a lot of new Eclair reports (non-blocking). > > Signed-off-by: Andrew Cooper What I would have wished to be clarified here is why allyesconfig isn't suitable to use. After all that would address ... > Maintaining these lists is going to be a nightmare. ... e.g. this concern. Jan > I think we really do need > to implement CONFIG_COMPILE_TEST > --- > automation/gitlab-ci/analyze.yaml | 45 +++++++++++++++++++++++++++++++ > 1 file changed, 45 insertions(+) > > diff --git a/automation/gitlab-ci/analyze.yaml b/automation/gitlab-ci/analyze.yaml > index a472692fcb31..7a2c0bfa77d1 100644 > --- a/automation/gitlab-ci/analyze.yaml > +++ b/automation/gitlab-ci/analyze.yaml > @@ -44,6 +44,24 @@ eclair-x86_64-allcode: > LOGFILE: "eclair-x86_64.log" > VARIANT: "X86_64" > RULESET: "monitored" > + EXTRA_XEN_CONFIG: | > + CONFIG_ARGO=y > + CONFIG_DEBUG_LOCK_PROFILE=y > + CONFIG_DEBUG_TRACE=y > + CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y > + CONFIG_EXPERT=y > + CONFIG_HYPERV_GUEST=y > + CONFIG_LATE_HWDOM=y > + CONFIG_MEM_PAGING=y > + CONFIG_MEM_SHARING=y > + CONFIG_PERF_ARRAYS=y > + CONFIG_PERF_COUNTERS=y > + CONFIG_PV32=y > + CONFIG_UNSUPPORTED=y > + CONFIG_XENOPROF=y > + CONFIG_XEN_GUEST=y > + CONFIG_XHCI=y > + CONFIG_XSM=y > allow_failure: true > > eclair-x86_64-testing: > @@ -104,6 +122,33 @@ eclair-ARM64-allcode: > LOGFILE: "eclair-ARM64.log" > VARIANT: "ARM64" > RULESET: "monitored" > + EXTRA_XEN_CONFIG: | > + CONFIG_ACPI=y > + CONFIG_ARGO=y > + CONFIG_ARM64_SVE=y > + CONFIG_ARM_SMMU_V3=y > + CONFIG_BOOT_TIME_CPUPOOLS=y > + CONFIG_DEBUG_LOCK_PROFILE=y > + CONFIG_DEBUG_TRACE=y > + CONFIG_DEVICE_TREE_DEBUG=y > + CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y > + CONFIG_EXPERT=y > + CONFIG_FFA=y > + CONFIG_FFA_VM_TO_VM=y > + CONFIG_GICV3_ESPI=y > + CONFIG_HAS_ITS=y > + CONFIG_IOREQ_SERVER=y > + CONFIG_IPMMU_VMSA=y > + CONFIG_LIVEPATCH=y > + CONFIG_LLC_COLORING=y > + CONFIG_OPTEE=y > + CONFIG_OVERLAY_DTB=y > + CONFIG_PCI_PASSTHROUGH=y > + CONFIG_PERF_ARRAYS=y > + CONFIG_PERF_COUNTERS=y > + CONFIG_STACK_PROTECTOR=y > + CONFIG_UNSUPPORTED=y > + CONFIG_VM_EVENT=y > allow_failure: true > > eclair-ARM64-testing: From xen-devel-bounces@lists.xenproject.org Mon Jan 05 15:12:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 15:12:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195492.1513428 (Exim 4.92) (envelope-from ) id 1vcmFg-0000TW-Rd; Mon, 05 Jan 2026 15:12:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195492.1513428; Mon, 05 Jan 2026 15: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 1vcmFg-0000TP-N5; Mon, 05 Jan 2026 15:12:12 +0000 Received: by outflank-mailman (input) for mailman id 1195492; Mon, 05 Jan 2026 15:12:11 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcmFf-0000TJ-BQ for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 15:12:11 +0000 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [2a00:1450:4864:20::331]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e6e80784-ea48-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 16:12:08 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-4779cb0a33fso326035e9.0 for ; Mon, 05 Jan 2026 07:12:08 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d6d143f6asm167040315e9.6.2026.01.05.07.12.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 07:12:07 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e6e80784-ea48-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767625927; x=1768230727; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=8hrn6pHQjABHadqBMB5YW34vBH/fMQ5tWPi/R90yKAw=; b=as8/8La1UcUEfTInk44YPZ4Vgt9Vget3ugTsQVvkA6bvpzMdQGv1UjFhf6BadstYry IZPZ5d55YAk+9UBWBNrVHWN7J9L9pH5euykk6zGcR1EJ3z+mn/2xqz9m1TXQy4NNAjpK rdrvQshtLGzhXO+bdv02yfhtfZBJZgIoyjOlS/HDwgY6CHwkH/Jn4IWlt+5c74+zqDG8 WXB1kKYNusgsxMuJS/5oLKPyUEoE5myZUdVd7cSuQITukwAhKIoJlxN93zNDnSfsTUzG GGePALWWQUN20sMK2KY0E3SPYh85rIqB/yYLTZtCakxrbDBJ7qQ8S5sKPG8PCoXuTpRM YQRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767625927; x=1768230727; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8hrn6pHQjABHadqBMB5YW34vBH/fMQ5tWPi/R90yKAw=; b=Lu8b7HkCU4whTWCQc3J6PM6jrBUAsZ0VouomtLL1bQ2XVPDn9c0O8r/5FkHIkZEfSW Bet3/2vthAL1rRxmZMKb8DBktGShzoacXYsuP3NI/h/4z8w/KHQdWqK7BHGa6KQzmyMv 3Cn4CCyggQAew5AXUK/9XmoxHGIxbMEuRX8BNFzYcJFf6NUFk/dD84a7QWFr2I5Jdb1R DDs4D/hQPhnTphQekNYwpc49iNJCuJc8xjvGgRadKIcPhg/UKkJSilkaYzK+x1KIHa89 yPmIaywUTTuAh1Q9gbpjMg/ZUbbTDj0ScOYQwjz+3I2LiZHYfwRzK2zxgT8W7y9QT7tA aH2Q== X-Forwarded-Encrypted: i=1; AJvYcCWGC1gKr1BvJx8pYXUVyVz7ksqYuq+iTRpZYliYC3s3mXH2igpT0xJBQwDzSHWN+TOyD7J2evnQU70=@lists.xenproject.org X-Gm-Message-State: AOJu0YyNRUAu0sQbwQOIpciqjqL2/L9UiwpTUj0P3tL2/I1FyOh012N5 lGjqCOMhVtjkCJe2Q4PnOp/NW6bRVtGmgz9gTR4WlQX9i4Ys5HhPyvesqZ7E6qLqQA== X-Gm-Gg: AY/fxX6lTXRyA1WgTEGnzmqZARbk1jdZPFsbvDnSKHRYLkx3u1LXH4B8I33czF+kdTU u8m2gWI1qTx+JV4I6i8kb1dC/cedN4pmo+L60Y5tq6XJDdy8K20DDZdeLKKQQ7zyIa4lTXPoBBZ NeCA0TTNvqFgamkD0nqu5ltZq2HQqfZULvHJzA0fTOTyFS+QirOmhq4x3PO9QEsC9DI6sWf9QAJ jpZos2RxXf1SwNglKHQh9w4mnyBBHDDcHxRzIVu5m9D6EdW9lhKsaNfhOT80X45K7qlxs0uQoe5 N0Wu2fCi+PaYqNZ4UtDX4iHFYrYk6qxHlOE0pAN7JvGRYHvczKIqLywJ1inIMBOMLbVWTpEK4f0 CQvkmaPDX7cAoWvM/OgCxED69UT2u2UtcOe/Fqk7Vjkcl/8ufhY8GTYAAoPvHhwRVTqF7za/BKu BD9kLGF0YwAdp2OynPWl8oB4zs0yYN37fWCEWyw1T6AIvLLd3O//nbx3anUz+ATpC8Kk2P5Vk7c N31bctbnT6yWw== X-Google-Smtp-Source: AGHT+IHZyN7U5aT0UYgATnhqh9Xqt1sc9MPAssVhBJEJwbNwRIya3CzWusYqM02OySmkP049cdz63g== X-Received: by 2002:a05:600c:8208:b0:47b:d949:9ba9 with SMTP id 5b1f17b1804b1-47d19566f0dmr629104285e9.13.1767625927597; Mon, 05 Jan 2026 07:12:07 -0800 (PST) Message-ID: <12a0ebd2-26b6-4743-a1cd-8948ad85e1f0@suse.com> Date: Mon, 5 Jan 2026 16:12:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/4] x86/xstate: Deindent the logic in xrstor() To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20251230135427.188440-1-andrew.cooper3@citrix.com> <20251230135427.188440-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: <20251230135427.188440-2-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.12.2025 14:54, Andrew Cooper wrote: > ... to improve the legibility of the following fix. ... wanting to replace the for() with an open-coded form of a loop. Which is fine, but could have done with saying here. > No functional change. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 05 15:16:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 15:16:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195504.1513437 (Exim 4.92) (envelope-from ) id 1vcmJV-0001Kt-9n; Mon, 05 Jan 2026 15:16:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195504.1513437; Mon, 05 Jan 2026 15: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 1vcmJV-0001Km-6A; Mon, 05 Jan 2026 15:16:09 +0000 Received: by outflank-mailman (input) for mailman id 1195504; Mon, 05 Jan 2026 15:16:07 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcmJT-0001Kc-CI for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 15:16:07 +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 743a29c9-ea49-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 16:16:05 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-47d3ba3a4deso97615e9.2 for ; Mon, 05 Jan 2026 07:16:05 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bca2fbfdsm98065f8f.17.2026.01.05.07.16.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 07:16:04 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 743a29c9-ea49-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767626165; x=1768230965; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=d0ZvIJsgBJSFFLwejM+snzgNBAfb6u9D3qK9/6a/auo=; b=Mfs21TKmAMAHfJsy25OMilOM1p+k5GWvTtoCo5hc/wGeG4Jg+WRD7u7/vF5q0bAeDH OXsWCyQrwGEXUV7cXLzOhecy25ncKIKt+xNLqjBzCY1I5QwctadSTph29f5tOvb30IEk j7NixxaNqyGgiO0jr3sqoNBXpE72SnWffU6rEee+jyKtUfyfzyzQdbzVzeRtliHY1G7L aAQvPyDLu5m+XkkwoPqN4W/BiT8S7ZRLt4BwRrbRCys0dq5ryLr6vFoOGjd5y5Lp7PKI 5tIoL00qRJXVgGu7vPy0QlYdP9VmtCjNEE2YGq+vKR4+c6NkyhyXFyGW57DUTt/wcJDo R6rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767626165; x=1768230965; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=d0ZvIJsgBJSFFLwejM+snzgNBAfb6u9D3qK9/6a/auo=; b=MDFZmKLfTdm7NOHKqk8z19iZ9IouJsynkrfkNh4HczSz/9rpHKXxgXcyqbl+knoDNR sGCpBNoxQcezCHskr9Ub0tlSQyfLRfQ8AQdNl/QcBsjLNy4gn7fZ+OFH6YM4bjbX6pKv DP4M9HEMiDoaBmBYAZSaSC/1ypj6mr42J55LPWeJKCEW+CIHxk7GLGaEyMJ263oxhRc4 PaQVbwUmZcmq/sjEVQ/nXF3UCY68sUyQC1i+/3xKQ4xMdxQkhlU6cPLkN3sFg5ulpG1d cnOfWsxGikXafL0aDcugS96higbIlu4+jY8WLGyexAGjU4XfrKNZNlA9X5qx+GNbu8tA pe5Q== X-Forwarded-Encrypted: i=1; AJvYcCUbRkPRT8RUU0R112vJh4XzDH5yKpDamjBZ4SYTOAHFnOGDcHpwIEA7QPRWTpwYN0/cmMZ757WcI+c=@lists.xenproject.org X-Gm-Message-State: AOJu0Yza5eu8EEkqdzrTR5+lYKrd/Q1UVyYSkK8uP/DpHeCpfRAcI9+p evagBhBziSMCQkYyKrZqnPZVkAoLUK6ssLJbIZtwhAzbEN1hKJ/3uJWzM307tHkjbw== X-Gm-Gg: AY/fxX4ENpyu5K/gfM2G6Pq71s4/hQGi9znMEfODtIhr/gE/RT4NLOjojTE0pbEjMJO 5nQ39ZwKixLfBW8/HWE836DFbCa9FtAZFSbhxkgmDKObdPoNQHq3RPwwGksMiUTBe53FoThAi5Z ID4pATQWW181Yh6l83uJpqdDD9I9kQ6jXvzY2SnyWWY/HlcSZB5qSiCKU6Gb/bMTLRBtFuzaL/3 4rXsSJ0JSPs/8rw1qLMtHjFJ6Z3tKMDIoMylfi7ZLYoUAEw2GhZRmf+5qYaZASnfblfLfUycABT MrrIqfv0o/EMFdXVEUTMVlO76WKJ9zNcJHuKgYXqi4fa5AKmSaxVAX/glj2EN6L0PmGPahc2D6g 06X/yglICzrv0lL+e+FtojfXdFh1twvH0I3eU9XRAWCNlo4LRLmmWpxoTHVpwN/Ny9+Uh9/rJWD QdM7XuQ/u16Vl9UchT1eXSLLD/Kv6K9q3pv4keUQpQpp8rEe+okL67WfCQihDT7NsdB7BazP10p 8FprzjFWaHNwA== X-Google-Smtp-Source: AGHT+IHvUgte7wULTj3XTxiQKEJLLoloXRcQ2p/6mAU+wT8Ak6K5k71/9n7c2m9Rg3FtlPmT5F93Gg== X-Received: by 2002:a05:600c:35cb:b0:479:3a88:de60 with SMTP id 5b1f17b1804b1-47d1959e061mr604262115e9.37.1767626164690; Mon, 05 Jan 2026 07:16:04 -0800 (PST) Message-ID: <7bd2372a-6687-47c5-94df-2366866f53ea@suse.com> Date: Mon, 5 Jan 2026 16:16:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/4] x86/xstate: Rework XSAVE/XRSTOR given a newer toolchain baseline To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20251230135427.188440-1-andrew.cooper3@citrix.com> <20251230135427.188440-3-andrew.cooper3@citrix.com> <5b49e965-7e1a-4b04-baa9-c14e2de2e247@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: <5b49e965-7e1a-4b04-baa9-c14e2de2e247@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 02.01.2026 17:01, Andrew Cooper wrote: > On 30/12/2025 1:54 pm, Andrew Cooper wrote: >> --- a/xen/arch/x86/xstate.c >> +++ b/xen/arch/x86/xstate.c >> @@ -310,21 +310,21 @@ void xsave(struct vcpu *v, uint64_t mask) >> uint32_t hmask = mask >> 32; >> uint32_t lmask = mask; >> unsigned int fip_width = v->domain->arch.x87_fip_width; >> -#define XSAVE(pfx) \ >> - if ( v->arch.xcr0_accum & XSTATE_XSAVES_ONLY ) \ >> - asm volatile ( ".byte " pfx "0x0f,0xc7,0x2f\n" /* xsaves */ \ >> - : "=m" (*ptr) \ >> - : "a" (lmask), "d" (hmask), "D" (ptr) ); \ >> - else \ >> - alternative_io(".byte " pfx "0x0f,0xae,0x27\n", /* xsave */ \ >> - ".byte " pfx "0x0f,0xae,0x37\n", /* xsaveopt */ \ >> - X86_FEATURE_XSAVEOPT, \ >> - "=m" (*ptr), \ >> - "a" (lmask), "d" (hmask), "D" (ptr)) >> + >> +#define XSAVE(pfx) \ >> + if ( v->arch.xcr0_accum & XSTATE_XSAVES_ONLY ) \ >> + asm volatile ( "xsaves %0" \ >> + : "=m" (*ptr) \ >> + : "a" (lmask), "d" (hmask) ); \ >> + else \ >> + alternative_io("xsave %0", \ >> + "xsaveopt %0", X86_FEATURE_XSAVEOPT, \ >> + "=m" (*ptr), \ >> + "a" (lmask), "d" (hmask)) > > This loses the pfx.  I've fixed up locally and double checked the > disassembly. Question being: Do we want to stick to using the prefix form, when gas specifically has been offering a kind-of-suffix form instead from the very beginning (xsaves and xsaves64)? If we wanted to stick to the prefixes, I'd favor a form where the use sites don't need to supply the separating blank (i.e. the macro itself would insert it, as doing do with an empty prefix results in merely an indentation "issue" in the generated assembly). Thoughts? Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 05 15:46:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 15:46:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195519.1513446 (Exim 4.92) (envelope-from ) id 1vcmmi-0006Eh-Hl; Mon, 05 Jan 2026 15:46:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195519.1513446; Mon, 05 Jan 2026 15:46:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcmmi-0006Ea-FA; Mon, 05 Jan 2026 15:46:20 +0000 Received: by outflank-mailman (input) for mailman id 1195519; Mon, 05 Jan 2026 15:46: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 1vcmmh-0006EU-8O for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 15:46:19 +0000 Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [2a00:1450:4864:20::42c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ac78bc01-ea4d-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 16:46:17 +0100 (CET) Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-4327790c4e9so3164188f8f.2 for ; Mon, 05 Jan 2026 07:46:17 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bca2f8fbsm194740f8f.10.2026.01.05.07.46.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 07:46:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ac78bc01-ea4d-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767627977; x=1768232777; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=XPnu0vThWEgbI0+DkMRoNLVg7V3inLjFC/70HVjgUUs=; b=JW/QT+lwarqZDhzbC74GNIkXZwAA8vPY3q96d7AmfLhCW2IWWZU15XA0kLqdHNxD8p z5Byu6TqAZ3ssWty69dvtSDddf7wYfyI/C1F+UGRHzSlOXk64/nscV4t2jj7ZTcbIVil zNOdldHYft+8eFrRApWRp3DJI9v6Y078jthSATNOANhVef0NMyWFHhkVN25mIyVYuM6D B90xHiSLHT1Hrxy9p3UlpcGdD3Z1myvLIBFT/bGjMEU9Uh887KWu+fLUBd/ZSkQgOsXt 3vY47uS/lsW2Fk0iaU/cHdig6xZszZfT8Y8NmJXCQPpbA/JubO4eB+vroG2Jlp5jE8B7 FJ/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767627977; x=1768232777; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=XPnu0vThWEgbI0+DkMRoNLVg7V3inLjFC/70HVjgUUs=; b=lnp5d3SONkF2BguHTna/f/IL8JQYfC3AjtTkBhKBOzr5L8uNRb5Qo3R6iHth8P2lJL 2V7GLnfmcVsEUp8Mx5O1Lb1HZWHfbxBOzPI4QwCeF+umH+RGC7csexD++gkNSa7nZQRH i453KyVsOyz6R4Zm/AaUZJcm86dQ8PeF0TJkbZU9/QAiyOP2snobF14S+dhmeO4lLdyL rAwl/4JCosLmeAdrUjr0dywhEVoIjNlsMPdi8w+PdFjfAm4akxFKySt6VXSem/eBSx7L xQ7J3yYPezx6l65os5yhWsMZqsWd5RcMmfeWaeP2DG2YAWRPQbotwNioHq+DCmO0a7f1 EveA== X-Forwarded-Encrypted: i=1; AJvYcCX1YeqGSPMo+kuijBpgeopyJnfSZHvaYQmWJ2MoMOQ+c530qJVuVMyaTcBgMd05WWqJxt2zUDkqCDo=@lists.xenproject.org X-Gm-Message-State: AOJu0YwdydBmSDTjWRwuKLlwqt3sv9Io/6DsBi9riN4dDx5NrPSiK5l8 vK5n3pFvQfbcarp5yFqtrd8QpI/2QdQXHC+nXXwh/qKWQoFcXbabr9RO4b60dGszKw== X-Gm-Gg: AY/fxX4edg3SWg9dcNzA6/jXG9VMm8w/Ee/9HcC02F3AEjM7EBKeu4DuDUJXgWpDoOH Cm0Hq8aH0fliQLw557Yq0hBPZ7yoZ8+KKgWSI2s5LTN7JAXyLXwDvgHsCBuBI4SQX5tsqN7naOy VZAMOZQRRnQon/K7IqA4Kb1k0NyUQ5nApreLMdoli1wVjH8kh/FhrQ7QEGQpAZYsDWPmirrcmDg jGBSsekYqmLoVkdShzegkG+iq+1VnWcrADwWUeCFG8zF/5le8flI7+kC9D+x5toZEz7BimrTaBw cdJKJ/wzwBZy2ZCuDoqVx8bjwOtRP5LAq9dl3uJ5jvzngWRTXcGq0vMRzpGH/D6cQO7r42YvZ9a J/3iwF3uCsyKeDgVpQue2XIULt7PGLvQtAS5XpSfwvRDaxOdhUj8B78xVgUu3+ASz+RUYybC6PV l00ghGrgTv5xKrJdZHQqCyCsr5+2i8Kr99T8sws+3IaCz6DTyROae54kwP0xwoWpTanx7Q5u0xY 8k= X-Google-Smtp-Source: AGHT+IHmgw+GvbLF1rhSiPMvK24miYy9YjgnCuuiN8osungdBnVsOfZFUxZx1FpUVxhYW7LEd34wRA== X-Received: by 2002:a05:6000:4287:b0:430:f272:3489 with SMTP id ffacd0b85a97d-432bca3e33amr232998f8f.28.1767627977017; Mon, 05 Jan 2026 07:46:17 -0800 (PST) Message-ID: <4b051e1f-0d99-4637-b433-bade93e67e0a@suse.com> Date: Mon, 5 Jan 2026 16:46:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/4] x86/xstate: Rework XSAVE/XRSTOR given a newer toolchain baseline To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20251230135427.188440-1-andrew.cooper3@citrix.com> <20251230135427.188440-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: <20251230135427.188440-3-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.12.2025 14:54, Andrew Cooper wrote: > --- a/xen/arch/x86/xstate.c > +++ b/xen/arch/x86/xstate.c > @@ -310,21 +310,21 @@ void xsave(struct vcpu *v, uint64_t mask) > uint32_t hmask = mask >> 32; > uint32_t lmask = mask; > unsigned int fip_width = v->domain->arch.x87_fip_width; > -#define XSAVE(pfx) \ > - if ( v->arch.xcr0_accum & XSTATE_XSAVES_ONLY ) \ > - asm volatile ( ".byte " pfx "0x0f,0xc7,0x2f\n" /* xsaves */ \ > - : "=m" (*ptr) \ > - : "a" (lmask), "d" (hmask), "D" (ptr) ); \ > - else \ > - alternative_io(".byte " pfx "0x0f,0xae,0x27\n", /* xsave */ \ > - ".byte " pfx "0x0f,0xae,0x37\n", /* xsaveopt */ \ > - X86_FEATURE_XSAVEOPT, \ > - "=m" (*ptr), \ > - "a" (lmask), "d" (hmask), "D" (ptr)) > + > +#define XSAVE(pfx) \ > + if ( v->arch.xcr0_accum & XSTATE_XSAVES_ONLY ) \ > + asm volatile ( "xsaves %0" \ > + : "=m" (*ptr) \ > + : "a" (lmask), "d" (hmask) ); \ > + else \ > + alternative_io("xsave %0", \ > + "xsaveopt %0", X86_FEATURE_XSAVEOPT, \ > + "=m" (*ptr), \ > + "a" (lmask), "d" (hmask)) While no doubt neater to read this way, there's a subtle latent issue here: "m" doesn't exclude RIP-relative addressing, yet that addressing form can't be used in replacement code (up and until we leverage your decode-lite to actually be able to fix up the displacement). Sadly "o" as a constraint doesn't look to be any different in this regard (I think it should be, as adding a "small integer" may already bring the displacement beyond the permitted range, but their definition of "offsettable" allows this). This issue is latent until such time that (a) a caller appears passing in the address of a Xen-internal variable and (b) we make LTO work again. Since the breakage would be impossible to notice at build time, I think we would be better off if we avoided it from the beginning. Which may mean sacrificing on code gen, by using "r" and then "(%0)" as the insn operand. > @@ -489,17 +484,17 @@ void xrstor(struct vcpu *v, uint64_t mask) > ptr->xsave_hdr.xcomp_bv = 0; > } > memset(ptr->xsave_hdr.reserved, 0, sizeof(ptr->xsave_hdr.reserved)); > - continue; > + goto retry; > > case 2: /* Stage 2: Reset all state. */ > ptr->fpu_sse.mxcsr = MXCSR_DEFAULT; > ptr->xsave_hdr.xstate_bv = 0; > ptr->xsave_hdr.xcomp_bv = v->arch.xcr0_accum & XSTATE_XSAVES_ONLY > ? XSTATE_COMPACTION_ENABLED : 0; > - continue; > - } > + goto retry; > > - domain_crash(current->domain); > + default: /* Stage 3: Nothing else to do. */ > + domain_crash(v->domain, "Uncorrectable XRSTOR fault\n"); > return; There's an unexplained change here as to which domain is being crashed. You switch to crashing the subject domain, yet if that's not also the requester, it isn't "guilty" in causing the observed fault. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 05 15:52:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 15:52:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195528.1513456 (Exim 4.92) (envelope-from ) id 1vcmsG-00084w-4I; Mon, 05 Jan 2026 15:52:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195528.1513456; Mon, 05 Jan 2026 15:52:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcmsG-00084p-1k; Mon, 05 Jan 2026 15:52:04 +0000 Received: by outflank-mailman (input) for mailman id 1195528; Mon, 05 Jan 2026 15:52: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 1vcmsF-00084j-FH for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 15:52:03 +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 7999460c-ea4e-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 16:52:01 +0100 (CET) Received: by mail-wr1-x431.google.com with SMTP id ffacd0b85a97d-43277900fb4so891912f8f.1 for ; Mon, 05 Jan 2026 07:52:01 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bca27603sm234937f8f.6.2026.01.05.07.52.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 07:52:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7999460c-ea4e-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767628321; x=1768233121; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=5GBBwsA4/MhDc4ro2F+Qm/pUvbzErcSrA6GY4MVFwfs=; b=b51x9XbWRJFZJ6fuJQ60kN7o/JefkVqS4x0nmX9d0i1ExThWg3SOv6Ow8FB4mmm50V TCJbLhVV/ynpRLbHFqgZAIvre3OGqUQIiFzylBzYouRn113W5Quc+NlmqyLIZ86YZqiQ i77Nok4BSqkW5fkROKAgWL/NmY60Y6rTqp95wHTh3EPPN8vpHFL1kOqHiM5VFhURE6kK S/TxYCy+xy7wWG1Xi7mA/13MG7BDgztYKkt2+SB/oF0+xrpLVa1siZ0ZL+BF3gxLoeYN FmT+qqeezibB+ytNDNYSh/UIUGPDICQplwhKM0IiREc3js5sEdCqjEh49nNA0/b64bIY z6dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767628321; x=1768233121; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5GBBwsA4/MhDc4ro2F+Qm/pUvbzErcSrA6GY4MVFwfs=; b=h/cy3FnqwBexb/CIj7hLLZjngUJ9W9oUWWQKat+nvD2G3ITAqaxR7v7vhrZ9EXItuO R0jyMD0ee6mqvQPqWWlFoRHrogxb2Qhquly1VT6WYVN8CDGbZyopgPhTekDilA9/yiFd K2YunvtXwptNqRgzlYPsMdWLkyAw8tmKXR+QV+K78vjvMCOJVUaPntcINm123uXGYCeQ IB/rXRKJX8ZeqzAM+RM/ry5yJGoMycdM+luAA1pNqDcm437sp+ZzrtPoVvZM8YXpoptC swQ3peBs+6TJ6MTY1qbbHqHWBOMTEtEmM2w3p5KRFs9PXnxy4Qc+6rZe6uEOnZXKmkD5 x2Eg== X-Forwarded-Encrypted: i=1; AJvYcCX0ILiyqIx/LYIatYSXIyiMxYTJmBxo8ufObQWfwd1Pnf89NTPLm7XEJQeZPzeJry4mHanAsp9NfcI=@lists.xenproject.org X-Gm-Message-State: AOJu0YygM/H6so05cNRfSUB49kLmVJBgSUT5LRsnDjBJva+vaMm8c62O riGg+GgIio5Kb1/exCWAGlLE0O7teyipjbFuRtAgrxphKqOHobDBJkIXgaYVhgrD8g== X-Gm-Gg: AY/fxX6teFBDeI4K+eaf8UjDzJB/HQrEvu/MvFlvObULlhIQzgsE1WAL80nULAcSfk4 6TmxFY6D+cdlUkyV1AddUVZIpTozZ/qLAJlclr4dv1ljsXqzR/5YW4sqURCR8pKx74JmYCIuctE pNqYrqYQB+3VXgmQRSNPyXdZs1TQoONY/mTaBD23qWX6nFjRslyUuE7dpNaf5B4JVs5/UrsDapx KBVtbw/MYx6ZL3Gjw45JB46V+LRd1gTBuQ9KA2axRwsjq5/A+gg6FsKuf1XsygGbdsqovLVKM/2 Se+LeftMh3ieR+kpsxG0xkyuewU5swH+b7Wj2He6wBYumZAvdWE86CgKykDiuYfd7gWbyH5YCWo VNTtr14tEXFQt3AANGS7ekDy2ExfwHuKLkkN3nio9xYmyiGcWJRubvMqhHmi2a4H8jax6BS6403 8ki7cYfkVIHcrxeoBtdhyubUQIg7rltPDHp4dcMOMuEch1RfFkw6+aOMjxs9bbPDd7fcOB7S9AT WI= X-Google-Smtp-Source: AGHT+IEMyNRObhYzSbz+PCesMqEiMiXAWNK+ovyNYDL70lk3k3QXYC+TtbWmmBsLxVWIS486sJpwIg== X-Received: by 2002:a05:6000:2312:b0:431:4ee:1f4e with SMTP id ffacd0b85a97d-432aa3f8464mr12158082f8f.11.1767628321222; Mon, 05 Jan 2026 07:52:01 -0800 (PST) Message-ID: <662888ee-e983-4194-b8ca-f28560881c29@suse.com> Date: Mon, 5 Jan 2026 16:52:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/4] x86/i387: Rework fpu_fxrstor() given a newer toolchain baseline To: Andrew Cooper , Nicola Vetrini Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20251230135427.188440-1-andrew.cooper3@citrix.com> <20251230135427.188440-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: <20251230135427.188440-4-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.12.2025 14:54, Andrew Cooper wrote: > Use asm goto rather than hiding a memset() in the fixup section. With the > compiler now able to see the write into fpu_ctxt (as opposed to the asm > constraint erroneously stating it as input-only), it validly objects to the > pointer being const. > > While FXRSTOR oughtn't to fault on an all-zeros input, avoid a risk of an > infinite loop entirely by using a fixup scheme similar to xrstor(), and > crashing the domain if we run out options. Question being - does ... > --- a/xen/arch/x86/i387.c > +++ b/xen/arch/x86/i387.c > @@ -38,7 +38,8 @@ static inline void fpu_xrstor(struct vcpu *v, uint64_t mask) > /* Restore x87 FPU, MMX, SSE and SSE2 state */ > static inline void fpu_fxrstor(struct vcpu *v) > { > - const fpusse_t *fpu_ctxt = &v->arch.xsave_area->fpu_sse; > + fpusse_t *fpu_ctxt = &v->arch.xsave_area->fpu_sse; > + unsigned int faults = 0; > > /* > * Some CPUs don't save/restore FDP/FIP/FOP unless an exception > @@ -59,49 +60,41 @@ static inline void fpu_fxrstor(struct vcpu *v) > * possibility, which may occur if the block was passed to us by control > * tools or through VCPUOP_initialise, by silently clearing the block. > */ > + retry: > switch ( __builtin_expect(fpu_ctxt->x[FPU_WORD_SIZE_OFFSET], 8) ) > { > default: > - asm_inline volatile ( > + asm_inline volatile goto ( > "1: fxrstorq %0\n" > - ".section .fixup,\"ax\" \n" > - "2: push %%"__OP"ax \n" > - " push %%"__OP"cx \n" > - " push %%"__OP"di \n" > - " lea %0,%%"__OP"di \n" > - " mov %1,%%ecx \n" > - " xor %%eax,%%eax \n" > - " rep ; stosl \n" > - " pop %%"__OP"di \n" > - " pop %%"__OP"cx \n" > - " pop %%"__OP"ax \n" > - " jmp 1b \n" > - ".previous \n" > - _ASM_EXTABLE(1b, 2b) > - : > - : "m" (*fpu_ctxt), "i" (sizeof(*fpu_ctxt) / 4) ); > + _ASM_EXTABLE(1b, %l[fault]) > + :: "m" (*fpu_ctxt) > + :: fault ); > break; > + > case 4: case 2: > - asm_inline volatile ( > - "1: fxrstor %0 \n" > - ".section .fixup,\"ax\"\n" > - "2: push %%"__OP"ax \n" > - " push %%"__OP"cx \n" > - " push %%"__OP"di \n" > - " lea %0,%%"__OP"di \n" > - " mov %1,%%ecx \n" > - " xor %%eax,%%eax \n" > - " rep ; stosl \n" > - " pop %%"__OP"di \n" > - " pop %%"__OP"cx \n" > - " pop %%"__OP"ax \n" > - " jmp 1b \n" > - ".previous \n" > - _ASM_EXTABLE(1b, 2b) > - : > - : "m" (*fpu_ctxt), "i" (sizeof(*fpu_ctxt) / 4) ); > + asm_inline volatile goto ( > + "1: fxrstor %0\n" > + _ASM_EXTABLE(1b, %l[fault]) > + :: "m" (*fpu_ctxt) > + :: fault ); > break; > } > + > + return; > + > + fault: > + faults++; > + > + switch ( faults ) > + { > + case 1: /* Stage 1: Reset all state. */ > + memset(fpu_ctxt, 0, sizeof(*fpu_ctxt)); > + goto retry; > + > + default: /* Stage 2: Nothing else to do. */ > + domain_crash(v->domain, "Uncorrectable FXRSTOR fault\n"); > + return; ... this then count as unreachable and/or dead code in Misra's terms? Nicola? Sure, Eclair wouldn't be able to spot it, but that's no excuse imo. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 05 15:58:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 15:58:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195538.1513467 (Exim 4.92) (envelope-from ) id 1vcmyo-0000bD-Q6; Mon, 05 Jan 2026 15:58:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195538.1513467; Mon, 05 Jan 2026 15:58:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcmyo-0000b6-Ml; Mon, 05 Jan 2026 15:58:50 +0000 Received: by outflank-mailman (input) for mailman id 1195538; Mon, 05 Jan 2026 15:58:50 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcmyo-0000b0-6Q for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 15:58:50 +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 6bd0c708-ea4f-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 16:58:48 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-42fbc544b09so4619f8f.1 for ; Mon, 05 Jan 2026 07:58:48 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bca56a16sm203047f8f.30.2026.01.05.07.58.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 07:58:47 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6bd0c708-ea4f-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767628727; x=1768233527; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=vJeUUtyiAVCWOJ2rKsQ6Joxu1RVPYWrNIDpmQK9/v3Q=; b=XUD4UXjZ20pkeZrEEtVO2z2AafOV2ZlrgZbvXTLc74e+YnOQEqVbVzfpxDoF2FGa8+ XgphE5jGURBtz9zFn9svHKbG+a9ubWs3tJf4EqWrAzTHzKZC+iHJILoaRRnhwMKNUjca b8sv49jx8WI1bHor3o0Xkn19bjQdgAh1Lxwwh17JzQbQjrDYjPjwK7odeGtu0V9mdTCb vXBDpcnG1qacyKmrVGzOVsgRypekcsxKHA8FHnA1adMum/H/Gl57lt/HNgg7/0T0FEhx 38ylNwN+vEH9TK9yWOrWQ3Ai9fHXD+WOww2jas3G6frNuQSYQzufDIJNj+nT6rRwEICo lXDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767628727; x=1768233527; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vJeUUtyiAVCWOJ2rKsQ6Joxu1RVPYWrNIDpmQK9/v3Q=; b=JazWcO8AC2t4Wbw83X32MhfoP3z1FWOzU7FSK5J929FZm1EAIOvRVZRYmy/vECZC7I JovBoYDIyoAK4qQEeBUXLLgX1CW035ShknhOmymcqPlSxhDvZ9CeBkG6pZXrOZeq6bHc sFdWrkrufYTfO4JxyUXwCd+2075c2mJcY9Gxo6ih2knKK8j7IoV4qHgWrF0GWN3tnJvj pFBT94AlPCOx5ZdNV/AoYT/CXkJONkAR8Y7aMF0TbrzWAXNJfSiurrCX+KT91J67HfI4 7bKLi4v8fOhDEkXQqNmadTDPkGz/z3VEDPhCGkxi+z/4GxoTZuhmmhnwoENHFkvMtqM2 IwBA== X-Forwarded-Encrypted: i=1; AJvYcCUJVG7s4lGghb0AdnGXGIsMSP3L43CxtHBTqlq7F2fBU0yYKLEx7+Zg/0CqI6K4JnfpNLq3vOFQJwA=@lists.xenproject.org X-Gm-Message-State: AOJu0YxNWNPJK/YUoKTycXrNHgMO/EuzdKDigZ0vr1bJzUd30lta5IJF 6FvOtfPzQDrVGtG5JCtCuEUfUHNeBRCfW1Os4a/s/r5TSjRycbxrfBfR9kSz1vDmfA== X-Gm-Gg: AY/fxX6mfJJH6YM+pTd4BNZjRo6VhnVG0/famlBX4JxA+YPfAFFi5YPqH231j5VmN4y 728aaxZJOuHJmQ8y++IsM1W7UbSu0F4ehSZFbTsZ4roQE4Sy/4wm12bwA5gSwPUC0z1QwLyuYNr WBhVsrH5XW+JFg4NtmSk7Dd5bFDVCtU/FBfOaTlbCcHWp5lZooXkiZldzuCrKx3H6v3i+UVuMtg fdhW6gYb5Lv4xV9MigfDt9XbLxFUen9hPaRaSoSzl1/1KMZjFPyct/FEE/1ueW3eWALKom3mg/K 02+Z4c0g1UdFRcFo3cbViUzA2P3c9VpmSVAiNVamTVL9DJ/OGIgB9NYXpJQtAyByQYrvADEmp74 5ZkqysOB+0ypa6Euzs2+BzYXU+w0wyF2W2zPr1KF+VMSqabCMGiEuDCSuRKHO+vF2TnUllGlMB1 xxZzVtMpwtjEVoYmkKi/ViW5Y+bwCiVw4XHZHoaF7uA5Ktdj6oWAM2k9RSb5uLoQf8p6XVxHgHL v/1m3t1k4c0PA== X-Google-Smtp-Source: AGHT+IEtDyX4uAU/t5XLwiFiB80ihOQKxUjWyn75kkNXoVXRHp3k9k1S4XPfVeuQj74iceG1xb9RAw== X-Received: by 2002:a05:6000:430c:b0:430:f68f:ee96 with SMTP id ffacd0b85a97d-432bca4ab6cmr221478f8f.36.1767628727533; Mon, 05 Jan 2026 07:58:47 -0800 (PST) Message-ID: <673f05ca-39d7-4219-86bc-044a84e46699@suse.com> Date: Mon, 5 Jan 2026 16:58:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 4/4] x86: Avoid using .byte for instructions where safe to do so To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20251230135427.188440-1-andrew.cooper3@citrix.com> <20251230135427.188440-5-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20251230135427.188440-5-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.12.2025 14:54, Andrew Cooper wrote: > --- a/xen/arch/x86/include/asm/asm-defns.h > +++ b/xen/arch/x86/include/asm/asm-defns.h > @@ -1,9 +1,5 @@ > #include > > -.macro clzero > - .byte 0x0f, 0x01, 0xfc > -.endm This can't go away yet, as it became known to gas only in 2.26. > --- a/xen/arch/x86/include/asm/prot-key.h > +++ b/xen/arch/x86/include/asm/prot-key.h > @@ -19,16 +19,14 @@ static inline uint32_t rdpkru(void) > { > uint32_t pkru; > > - asm volatile ( ".byte 0x0f,0x01,0xee" > - : "=a" (pkru) : "c" (0) : "dx" ); > + asm volatile ( "rdpkru" : "=a" (pkru) : "c" (0) : "dx" ); > > return pkru; > } > > static inline void wrpkru(uint32_t pkru) > { > - asm volatile ( ".byte 0x0f,0x01,0xef" > - :: "a" (pkru), "d" (0), "c" (0) ); > + asm volatile ( "wrpkru" :: "a" (pkru), "d" (0), "c" (0) ); > } Same for both of these. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 05 16:05:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 16:05:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195547.1513476 (Exim 4.92) (envelope-from ) id 1vcn59-0002jI-EG; Mon, 05 Jan 2026 16:05:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195547.1513476; Mon, 05 Jan 2026 16:05:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcn59-0002jB-B9; Mon, 05 Jan 2026 16:05:23 +0000 Received: by outflank-mailman (input) for mailman id 1195547; Mon, 05 Jan 2026 16:05: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 1vcn58-0002j5-AF for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 16:05:22 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 552a1d18-ea50-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 17:05:19 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 6F0744EE0742; Mon, 5 Jan 2026 17:05:18 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 552a1d18-ea50-11f0-9ccf-f158ae23cfc8 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=1767629118; b=hXo1sje6fM85B94ysb59PqeMFmZBbinx1abgJ3j69neoV0yELzv0yVoUkDeTKvMEwI3P UJ1a9oxozR/gTxx14SjVy8MOykbjgaGFepGRdewHxGSzr94sQFqHj6kiG9/2II4qOz5VN Qawcq4gQqTG3rT6X5JUfgMod+wHLiiXOuDJRuGigD/qsj6nQh/DgJ7B3/m7XSgcdmXaP1 mKkK99d+7eLq9EJtLqJv2nbK0UjzM9TNO5sdZy4M2lgBaydxctahHFAR0lDbVbEK73p70 tsmks6zFbjeevmiRP+ghY5LVyycY9SUEas2MD6jl1jByFncBiPQaKmH2WDqG2wCWQBCZg rd7/t2U4GL1Ij/MYHpv4dWzIUxsZnT7zedaLOV8Qm162UpuJIcQChSdJNHZCMTjApLBr6 P+uDYEWXkvARjtSO5WAE1t8EDZIUFAdeM/bLd3oGwX+irmjHFaRuBtXZmu7F214k8h2uz gPxHN7dcNURIAJHjt5RcEFb7QNaLwISfYDaJ1C5rZRhSlS4eFJKUMKRHv8artAD0Fsx7x 6dCzOFX0ULvcnkwsNqi3810qwGFeob8nlKwb1BMFJCcmsGLRTs0Y6MFzbvVfVW4xetB0F 9qjBRYECcd+qoy00PSoqB+pj5kLDIlLBv5kcbl3bqDEvTy+eY2cVopqzy3EjBPg= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1767629118; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=IefPlY65k/C/hJSwkaU7F/jJ6zlOnXHTUK57BtlC6Lo=; b=qIT4kF9VcamDP1D5d/HvzltpkyS6BpvTXMdz8qK6vbcVg6HutJ2yLyEJSZzp5IgqANVd z1+JZ+sHp15n3nDcPp14LnVI2SPxmjNfk9ruteGD3LJBxfynhuFPTzRGJ75Ox5TFgMucq TU3jAH+TfzsCaoOdy4L+p11eM50rvcRWY3xmuWRw/G9TndWb4HRJwbE1KayTK6wI5jbSC qbbJeFb8hzdO1lg/7KEGBHvHPLQG/qJEHkCyQVlX9Bzvq34cbkmcoTRmd4jCEPtFunyHG abZTwlfH0kObSPayYrKXaSOXkFoCHwvJ8krgCtRhdiVW181+uqvYNqEVLn6D6eZlsb92M LqDGVBDUfbFHNZA8XxNZKvOUGuYQGvlsQPpzox1Ew5i8OfQN4Ap5vvBYdLfElMd9be9jp sUy9K9ivOHUZ9o9RIKiaHWWgobNFtpUFgzHtBS3xTfugcyxhrEhmx+xJdbFz+K5PPlGXB 8KYrjtKErWHWGRPACMCdoJLgD1aonIQA49KKf9pEcio4pp9p2uUmfGCVzCaLw7CCBEzvb kxjWisEpSALQgpizBBiMiwBZR3Il+6qVJ9O1uNUZgRhkL9r94kgklk0MYXVDq0aIWyT5W gJpT7qn3rWGQMJIZSm4tCru4FA2oz15PKXBVe0NVxnz0oVZ3DUQIk0wgOL+PlmM= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Mon, 05 Jan 2026 17:05:18 +0100 From: Nicola Vetrini To: Andrew Cooper Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, consulting@bugseng.com, Doug Goldstein , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [XEN PATCH] xen: rework deviation to address varargs MISRA violations In-Reply-To: References: <24aefd91-18ef-4ac2-a1b2-6098aa31e716@citrix.com> <6a0d6249997997a1b152d860932f68bc@bugseng.com> Message-ID: <009ef0575d867bf81fcf399b664491a9@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2026-01-05 12:54, Andrew Cooper wrote: > On 02/01/2026 11:53 am, Nicola Vetrini wrote: >> On 2026-01-02 10:42, Andrew Cooper wrote: >>> On 31/12/2025 11:22 am, Nicola Vetrini wrote: >>>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl >>>> b/automation/eclair_analysis/ECLAIR/deviations.ecl >>>> index 219ba6993b90..7dee4a488d45 100644 >>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl >>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl >>>> @@ -570,13 +570,11 @@ safe." >>>>  # Series 17. >>>>  # >>>> >>>> --doc_begin="printf()-like functions are allowed to use the variadic >>>> features provided by stdarg.h." >>>> --config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(^.*printk\\(.*\\)$)))"} >>>> >>>> --config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(^.*printf\\(.*\\)$)))"} >>>> >>>> --config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(panic)&&kind(function))))"} >>>> >>>> --config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(elf_call_log_callback)&&kind(function))))"} >>>> >>>> --config=MC3A2.R17.1,reports+={deliberate,"any_area(^.*va_list.*$&&context(ancestor_or_self(name(vprintk_common)&&kind(function))))"} >>>> >>>> --config=MC3A2.R17.1,macros+={hide , "^va_(arg|start|copy|end)$"} >>>> +-doc_begin="printf()-like or scanf()-like functions are allowed to >>>> use the variadic features provided by stdarg.h, >>>> +provided that they are declared using the `format' attribute." >>>> +-decl_selector+={format_attr, "property(format)"} >>>> +-config=MC3A2.R17.1,reports+={deliberate, >>>> "any_area(^.*va_list.*$&&context(ancestor_or_self(format_attr)))"} >>>> +-config=MC3A2.R17.1,macros+={deliberate , >>>> "^va_(arg|start|copy|end)$"} >>>>  -doc_end >>>> >>>>  -doc_begin="Not using the return value of a function does not >>>> endanger safety if it coincides with an actual argument." >>>> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst >>>> index b3431ef24e26..584907b048ec 100644 >>>> --- a/docs/misra/deviations.rst >>>> +++ b/docs/misra/deviations.rst >>>> @@ -570,8 +570,8 @@ Deviations related to MISRA C:2012 Rules: >>>>       - Tagged as `deliberate` for ECLAIR. >>>> >>>>     * - R17.1 >>>> -     - printf()-like functions  are allowed to use the variadic >>>> features provided >>>> -       by `stdarg.h`. >>>> +     - printf()-like or scanf()-like functions are allowed to use >>>> the variadic >>>> +       features provided by `stdarg.h`. >>>>       - Tagged as `deliberate` for ECLAIR. >>> >>> Much nicer.  But don't we want to repeat the part about >>> __attribute__((format(...))) here?  After all, that is the >>> justification >>> of why it's safer than nothing. >>> >> >> Ok, that would be more accurate for sure. I didn't do that to preserve >> the original intention of the deviation, but they are practically >> equivalent with the current codebase, so changing the text makes >> little difference. I'll tweak that. > > I can adjust on commit, if you're happy?  Everything else is fine > AFAICT. > > In fact, this fixes the x86_64-allcode complaint for > vmcoreinfo_append_str() which is already annotated, and > debugtrace_printk() too (not yet enabled in *-allcode). > > ~Andrew Yes, sorry for the delay. I forgot I had to respin the patch here. -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Mon Jan 05 16:07:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 16:07:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195561.1513487 (Exim 4.92) (envelope-from ) id 1vcn6g-0003Jb-PR; Mon, 05 Jan 2026 16:06:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195561.1513487; Mon, 05 Jan 2026 16: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 1vcn6g-0003JU-MW; Mon, 05 Jan 2026 16:06:58 +0000 Received: by outflank-mailman (input) for mailman id 1195561; Mon, 05 Jan 2026 16: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 1vcn6f-0003JL-A5 for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 16:06:57 +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 8ea6a2ba-ea50-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 17:06:56 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-430fbb6012bso14149f8f.1 for ; Mon, 05 Jan 2026 08:06:56 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bca27642sm272556f8f.2.2026.01.05.08.06.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 08:06:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8ea6a2ba-ea50-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767629215; x=1768234015; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=uGlrI54Jpek/rSowiORoNmjYuKtXANePipxG9zcj3oM=; b=CMKhP/HudYiTPpdchMiLT+oIxbNlPwk7U4TW4PIuUOkboi2umR/oJDJrX0EXpbeNwr QMP2PxZS404hlPnlg4y5YDlbqNOcdUoE1RjapQBDMtcPlbsLOWqnIMNCGdjWl9/HjKE9 D/SNxvby4bn6aQ0U0UbKMAcDk9ULOAY/eWGGLir0A2pLeCUNQZvb+amNAemNcxz4RlKL JxvLoGvutfB3FMJBaFq8x7apQolTzczYWESkFpU2LelrHgz6jmJF/4gK7PmC2DkL6k6K QRMJG8djGRbfVkpR1MrbxBUJt4ft1+J4vzGe83fiKigEQsXMxhT5Se2dlUIxnZCrXGiN ABfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767629215; x=1768234015; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uGlrI54Jpek/rSowiORoNmjYuKtXANePipxG9zcj3oM=; b=lkmkRK9TLS03aMuHICC1gDND8zkfEoeI5zuvJJ3tXi0De3Bb5hipiOwzPM5yTtQ1GN WCcZXKwsuqC9863Yf3khtHkGLRN4DLrynv+jJdLLVH8b3zLE11jxqwQr8vJU3G8Vdr76 NUeOWW8JG2q4nn/re8DW50aqoq/TolgWDGY3h9FkGiEKbNi7YqfX4YOV3yvbcK8R+6Wm yxeLfqXyyrDustAGJ1854jrx322TB9tk1R/efw6qB+uYreW2y74FO8VFGl54k3ijrg/y uJge1KUy9ws/2UujrpR2GUMxjskalUO5YiIJpXbaMgepU/44ZfF+aQVhxNu562GC/IFs zIaA== X-Forwarded-Encrypted: i=1; AJvYcCVNPwBKRTuKTzo380jW/i4+D1JSCPspUhsWvi3gicIgxqRBTk21N1P/C40T68a7ImFFhrN9Gngo5ME=@lists.xenproject.org X-Gm-Message-State: AOJu0YyimZ5LyVhosj2iM/+atm++wS4UaLp616yQyUBqYLnEjvxPApoI zGh6hOQLCRy5rhZd/eBcvIXOFrSP61LR0T+ElZzv8WVy9T1vAL2Ykyu2zOyHNfWlEg== X-Gm-Gg: AY/fxX7TpksbRjOU3ZOeFY8G3kYSTZLuAAaWaOnStQ/JWalNRVvAxxMVVEmxky3jTgh u6UwWMSIXOroHU3/8oBlDdSSLlRR+24vJXynCEH+Xzf60WaPKwH587lofpWw94sknov/fnEPoFM Seb8mGr4JsYnqbfOKcNlFm1cvom0RX1XgSbKjXtWi53MhqcNDf0L3oVXA8CoYhYRJAy6FrHKqoi bbbVmV7khvvHj1UaJxHOkEtU0oyV0APtuxw2a3F6tx3dTuui14vmO3f/ZOMdJzlSpx4lCo21afz TK0p4AEEwvgnD9LEISb8hCd6VStnkXkDNneAhVqmQlAxheKxghMg8GWdGkL/RejQI7Zju57BED6 e8ql0zjEiNFC3TNh0Jbu1DgrgOIkpYEKPoPr+lhkNqnLrShQXSd9VgFfExtQs6JTy5qIpQVLXXa N3OGQjULLWdVKbiY3UIB6500ErjfEv4xKye6ZuCBxdQoahEQdJm2IOrnHrvmCgdDnLHPcGRIZku aA/eZeHrifg8A== X-Google-Smtp-Source: AGHT+IGFfr0Yetmy9/JYr/+D5ObT+TNNb1rKadgfIZXzQZ2ANuAnk/yulEdVhcwfa1Lu7E+R2+fsbA== X-Received: by 2002:a5d:5846:0:b0:432:86dd:f449 with SMTP id ffacd0b85a97d-432bc97d4e5mr359612f8f.0.1767629215454; Mon, 05 Jan 2026 08:06:55 -0800 (PST) Message-ID: <4a59e889-37f1-4dc3-8c7f-71ef47e8483d@suse.com> Date: Mon, 5 Jan 2026 17:06:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] xen: Fix endian handling in muldiv64.c To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , Xen-devel References: <20251230135050.188191-1-andrew.cooper3@citrix.com> <20251230135050.188191-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: <20251230135050.188191-2-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.12.2025 14:50, Andrew Cooper wrote: > WORDS_BIGENDIAN is a QEMU-ism. In the very dim and distant past, we had a > fork of QEMU living in xen.git which wired WORDS_BIGENDIAN in the userspace > part of the build, but nothing ever wired it up in the hypervisor build. Perhaps the assumption was that big-endian targets would #define WORDS_BIGENDIAN in their asm/config.h? > Fixes: 86d5da49a6f7 ("[HVM] Support multiple HVM time device models coming soon.") > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich > I'm not sure that this wants backporting, seeing as we have no big-endian > architectures at all. Otherwse, 4.20 and older can't rely on the existence of > __LITTLE_ENDIAN on older toolchains. This not being active breakage, I think we can omit the backporting here. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 05 16:07:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 16:07:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195568.1513497 (Exim 4.92) (envelope-from ) id 1vcn7Z-0003zn-3F; Mon, 05 Jan 2026 16:07:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195568.1513497; Mon, 05 Jan 2026 16: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 1vcn7Y-0003zg-W3; Mon, 05 Jan 2026 16:07:52 +0000 Received: by outflank-mailman (input) for mailman id 1195568; Mon, 05 Jan 2026 16:07: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 1vcn7X-0003zR-KT for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 16:07:51 +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 ae697904-ea50-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 17:07:49 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-47d59da3d81so9496945e9.0 for ; Mon, 05 Jan 2026 08:07:49 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d73066fdbsm109741885e9.15.2026.01.05.08.07.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 08:07:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ae697904-ea50-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767629269; x=1768234069; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=x40MIlm0Dc9F4QL8EOqSeDunw4hJcgQNZdr1PWNMoPc=; b=GcvN/wLjU7Qug3JHWgpAl3386vAJciRsYBdG0evON0tYPlvBXpwnOBux1XQBy4Wap7 suM5I/SERCOg2C087eb8rPvcxMdv+ZBKnSszw5Dn4CHZJuU59GY7L45x+vZAU44EKhs2 /N+37apBGzGa6B+nuFqnuNTw2qLPjvUmyd4dzoI8HWSdma7ObI6DQOOsigf2Khz8MGfx vvyVV80rJEZYfKqwYWaT58I4CqHyDD1Hg7I9x/iRDKyNO7xAv0cX9PXgdeXsasztslsn D8vZJU8Fw/v3LtvaMdA3ABHYu9h3jBPk5WHRKGTf/IqYJev9MDRE2C0cVTAyrskq00XN Uqkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767629269; x=1768234069; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=x40MIlm0Dc9F4QL8EOqSeDunw4hJcgQNZdr1PWNMoPc=; b=orOd630yJ6hY27PrPPCyFRHmm6YuGnL3g0zJBsQfd3JBnfXW80tauidNXjZBe/7ucM yvzSUgSVxRf0U6P/rjnhaBVP3/Krzp61zCq+alc5uisGeWwpauLJ8zC2knKRL0Xz8Cl8 QRJjDKfWBccFQ+8dU0KnnkCun8+f3dWOr9p9aIpTE1C4K65UZ2C2ToXs9DMreTBlq83u 0S50w4YkyXm5Ea2FkOvJcL/aiVO5n5Xf/KTs41eUjkPJeJIWoZQ07P7sWc/6OcvVaZln Wiim5jYj3392+S2LjSoPuDml3/mczDS2GA3Sf7j1Jq2Ka9Rbn2IL5FpEZlDlEVTAxkA9 lw4A== X-Forwarded-Encrypted: i=1; AJvYcCXZWxbITbcChaQzFzcN4Q66c6uyooRpek0ttEv5H+/SI9uON2hgkwJuTVgCPqQr0nGX6GerGIZv3nU=@lists.xenproject.org X-Gm-Message-State: AOJu0YxztS1Jz/DZThXh7PO/e+6YP8r5MsnCx4AP3PopBVpe2vHLEyuF CqPQgZdBBpTkv4kBzhpiDvK+zHI8Rr9MWo6afhhHDWixROQ08+q+fMFNGGfbqgFhmw== X-Gm-Gg: AY/fxX62Hp7C3eAXv7j8D3ccN1gdd95Th+p0GgN3VP6U+gJ9MEsJeyFV0tPiO8K0gSN N8Y5iQXs98Bz6+oZaVwGou3D5/Ruw+O2Te/Sct+d7gJTk55V3p23kl0AW1VhUEy1U76JiMGjiZb KHab93u5uFhrXnHFmh4AxTF6B47a9yOIzw7639HRfhQs/CbGyBpv7ksLzebLImR9Ua8SKjrHBei GN0ACHcZfvJ9h6VELzb/Cr6453A8HfU8Cd/gKxnIBd6PsgjQteOdKN1FqCCV/RqU4aliZQ4k0u/ GULdNK+mbwpZUE4pgdg5mq8BrrBLgsW2GWtSfkuaqQwbvKyHGguZpWFPyKHtlBgX4Kd7WDvFk5H vpOB5PX+8I01tDGW11tzq7MzZjjEzBFl9H95lfzk4SCt7tzRSbkVQrs4MbRbqD2c2hMJiz0N5rb tWcZ3X3gJ8GIDYQufhbD+6J49TUMx8UC/96s+3tPUUSEiINk1YvW67hudeR4rWqxYgGG14lul/l DE= X-Google-Smtp-Source: AGHT+IFFrHlg8cXLcqfrSt0VstVqB9RqjZ/OQbv1t5eoivSbWriYQa2uBQC67J+1OA5jauQLzHE0mw== X-Received: by 2002:a05:600c:4e4c:b0:47d:403a:277 with SMTP id 5b1f17b1804b1-47d6ba7e435mr112395935e9.4.1767629268885; Mon, 05 Jan 2026 08:07:48 -0800 (PST) Message-ID: <58b2ca93-4d13-453b-a880-f40c890f0af3@suse.com> Date: Mon, 5 Jan 2026 17:07:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/5] x86/time: Sort headers To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , Xen-devel References: <20251230135050.188191-1-andrew.cooper3@citrix.com> <20251230135050.188191-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: <20251230135050.188191-4-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.12.2025 14:50, Andrew Cooper wrote: > ... in preparation for a logical change. > > No functional change. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Jan 05 16:13:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 16:13:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195579.1513507 (Exim 4.92) (envelope-from ) id 1vcnCd-0005rD-LA; Mon, 05 Jan 2026 16:13:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195579.1513507; Mon, 05 Jan 2026 16:13:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcnCd-0005r6-HW; Mon, 05 Jan 2026 16:13:07 +0000 Received: by outflank-mailman (input) for mailman id 1195579; Mon, 05 Jan 2026 16:13:06 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcnCc-0005qX-Lk for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 16:13:06 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6a267ce3-ea51-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 17:13:04 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 77FB14EE0742; Mon, 5 Jan 2026 17:13:03 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6a267ce3-ea51-11f0-9ccf-f158ae23cfc8 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=1767629583; b=k9/wDpfh6enap/4FiX9zDlTUS0sJ2aW8gQ2Kn8nRk512+t0gEm3Mu4ln46rREGjcY7hF T7lDOQn8QjHfTp7GdMrZBWc7INSGF6P7xGyEZIEOD5tBEsT7eeTAhfYRqMFaXzr0APIYb nydbX4HD+Ks4mCs4CpF/OICkmf2t+0trndeOpZxdXZfOeUMeETk09Cg5KReKd8n7fY1F7 HYrIzATn+UaT8T1SSKLIiJaBls0MlkQLJkpfTkW0dnlRjRt55uS+MOqkovUEjLaGsQmgl fkEMKtOvODu1GYZtXZSuI0HneFyrpCGDzFKn9M+wDlh5hglE/cnncY4K+65iXAIiKpPEY 3DDY+e70F6SgJ+frP60HYl43IzETNX+so2ZGxQdsPGUytSro9oEOzuaNM6VuB7hIuicni vyWtDMVI4yfVJa5wPOdwfeLI/upOXrhiCJEVswxNaJwB929m8+GMMtAGoSuzpdfYixSyc 8/LdeidR1vOEkvpRgXXYrlvErCeqzWf2OsyKbG0of85FvwpbB4MEg1OyAO2LarnFbaAyF jzfD+AuyDSO6Q5nh/Ubv8+uZibRB1OXmcXlDya6tNpuX+ieoKvVpaNoIyCUSCTS5LpNSt Ce9yT/j+RZ9x+HNF2oxZMcF2TX/DuuQNjvhKvw05MobQLZKWkJl88AGBigbtxyc= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1767629583; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=kkkFcPaTtOnOacVvxiO1is934CxyV1Z9JxBRoNWjIe8=; b=WiNhFvHwd41+8F8EINIUtKlrnCJIclSioIgt0ClUuMDCl5WA+pfN4Df8+tTFPSuWTojN Njzokpky/Uy9It6uaQqUvQxmbQWaYxMiCJr5VX5Wln2fIoGODqsrNB/NoI3mkQ4Fi72oe K0M/V9NxD69RUs/b7zzIS+PSJdPzjx5Tv5bmVzP9e0yNAP3K4rq2sAPMxnWFG8mO/aMVT U4eUIS85Tebs6Tunk00LDf+38kZqlxIgLbSOPkwWNTQeM0cxSkiTQJoAsQgb+lOLUNEVQ aQ5rT2qPIevMXmucqjCZffD/tmuihQvm0DqBlVmXSgsf2ljy2mISq1cyR6ToL3SVx7OeV yOn9XUkYM8jkvLcpblh8nZaGjhQE2goKWePKiN0Cvf7lE6aYEC+IpK5Gd36COPwN2mD71 14IY7hA/2dFCpc6gsIQN4rY94fDsbDjLh39qyWdfYgQXTIfEo45nFhRtq4irkMtXVlXZ9 Vw5UESOtYqJGELX/HVMo0js+dRPN5a8tHgIDB8U4T1wf9J0u1V78hE4BQTSrzg9rXxxW7 yh9redpMcz22JaBUVDFW/Ore5vJvp11QWvvyawo7jfiV2eF+WuDOxwyBaRz1gaDJxRASx YcMPB0ids0zF7ujTwaX59n7LW2wJnybq1iVv48ZLcsdtP6geOtGuFgoiqid+Xaw= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Mon, 05 Jan 2026 17:13:03 +0100 From: Nicola Vetrini To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn?= =?UTF-8?Q?=C3=A9?= , Xen-devel Subject: Re: [PATCH 3/4] x86/i387: Rework fpu_fxrstor() given a newer toolchain baseline In-Reply-To: <662888ee-e983-4194-b8ca-f28560881c29@suse.com> References: <20251230135427.188440-1-andrew.cooper3@citrix.com> <20251230135427.188440-4-andrew.cooper3@citrix.com> <662888ee-e983-4194-b8ca-f28560881c29@suse.com> Message-ID: <37ff7e30cc0715d619a20d7ea6ab72b5@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 2026-01-05 16:52, Jan Beulich wrote: > On 30.12.2025 14:54, Andrew Cooper wrote: >> Use asm goto rather than hiding a memset() in the fixup section. With >> the >> compiler now able to see the write into fpu_ctxt (as opposed to the >> asm >> constraint erroneously stating it as input-only), it validly objects >> to the >> pointer being const. >> >> While FXRSTOR oughtn't to fault on an all-zeros input, avoid a risk of >> an >> infinite loop entirely by using a fixup scheme similar to xrstor(), >> and >> crashing the domain if we run out options. > > Question being - does ... > >> --- a/xen/arch/x86/i387.c >> +++ b/xen/arch/x86/i387.c >> @@ -38,7 +38,8 @@ static inline void fpu_xrstor(struct vcpu *v, >> uint64_t mask) >> /* Restore x87 FPU, MMX, SSE and SSE2 state */ >> static inline void fpu_fxrstor(struct vcpu *v) >> { >> - const fpusse_t *fpu_ctxt = &v->arch.xsave_area->fpu_sse; >> + fpusse_t *fpu_ctxt = &v->arch.xsave_area->fpu_sse; >> + unsigned int faults = 0; >> >> /* >> * Some CPUs don't save/restore FDP/FIP/FOP unless an exception >> @@ -59,49 +60,41 @@ static inline void fpu_fxrstor(struct vcpu *v) >> * possibility, which may occur if the block was passed to us by >> control >> * tools or through VCPUOP_initialise, by silently clearing the >> block. >> */ >> + retry: >> switch ( __builtin_expect(fpu_ctxt->x[FPU_WORD_SIZE_OFFSET], 8) ) >> { >> default: >> - asm_inline volatile ( >> + asm_inline volatile goto ( >> "1: fxrstorq %0\n" >> - ".section .fixup,\"ax\" \n" >> - "2: push %%"__OP"ax \n" >> - " push %%"__OP"cx \n" >> - " push %%"__OP"di \n" >> - " lea %0,%%"__OP"di \n" >> - " mov %1,%%ecx \n" >> - " xor %%eax,%%eax \n" >> - " rep ; stosl \n" >> - " pop %%"__OP"di \n" >> - " pop %%"__OP"cx \n" >> - " pop %%"__OP"ax \n" >> - " jmp 1b \n" >> - ".previous \n" >> - _ASM_EXTABLE(1b, 2b) >> - : >> - : "m" (*fpu_ctxt), "i" (sizeof(*fpu_ctxt) / 4) ); >> + _ASM_EXTABLE(1b, %l[fault]) >> + :: "m" (*fpu_ctxt) >> + :: fault ); >> break; >> + >> case 4: case 2: >> - asm_inline volatile ( >> - "1: fxrstor %0 \n" >> - ".section .fixup,\"ax\"\n" >> - "2: push %%"__OP"ax \n" >> - " push %%"__OP"cx \n" >> - " push %%"__OP"di \n" >> - " lea %0,%%"__OP"di \n" >> - " mov %1,%%ecx \n" >> - " xor %%eax,%%eax \n" >> - " rep ; stosl \n" >> - " pop %%"__OP"di \n" >> - " pop %%"__OP"cx \n" >> - " pop %%"__OP"ax \n" >> - " jmp 1b \n" >> - ".previous \n" >> - _ASM_EXTABLE(1b, 2b) >> - : >> - : "m" (*fpu_ctxt), "i" (sizeof(*fpu_ctxt) / 4) ); >> + asm_inline volatile goto ( >> + "1: fxrstor %0\n" >> + _ASM_EXTABLE(1b, %l[fault]) >> + :: "m" (*fpu_ctxt) >> + :: fault ); >> break; >> } >> + >> + return; >> + >> + fault: >> + faults++; >> + >> + switch ( faults ) >> + { >> + case 1: /* Stage 1: Reset all state. */ >> + memset(fpu_ctxt, 0, sizeof(*fpu_ctxt)); >> + goto retry; >> + >> + default: /* Stage 2: Nothing else to do. */ >> + domain_crash(v->domain, "Uncorrectable FXRSTOR fault\n"); >> + return; > > ... this then count as unreachable and/or dead code in Misra's terms? > Nicola? > Sure, Eclair wouldn't be able to spot it, but that's no excuse imo. > > Jan Right now, probably not, but even if it did, an ASSERT_UNREACHABLE can be added in the default branch to deal with that. -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Mon Jan 05 16:14:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 16:14:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195588.1513517 (Exim 4.92) (envelope-from ) id 1vcnDr-0006Ml-Tl; Mon, 05 Jan 2026 16:14:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195588.1513517; Mon, 05 Jan 2026 16: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 1vcnDr-0006Me-Qv; Mon, 05 Jan 2026 16:14:23 +0000 Received: by outflank-mailman (input) for mailman id 1195588; Mon, 05 Jan 2026 16:14:23 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcnDr-00067T-9I for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 16:14:23 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 98af01af-ea51-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 17:14:22 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 23D2D4EE0742; Mon, 5 Jan 2026 17:14:22 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 98af01af-ea51-11f0-b15e-2bf370ae4941 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=1767629662; b=QXW0oDlusUnRnrE2n1yHvyxNBi3PklygDKM2BFWyX+wg8cRZH1SioBd0O2gCoGUSboNs HeDrDDO7lrkbfTZyQiXQ53i66tuNpM8XhRJ7OMqzr4b9Nt3BmLBVfXt3ZXTbnha+m50j9 bfyOOl0exnX5i6PV9xKGr3LgeELYrE5x/XEYQVfP3caqXcBt8+lVfRQnWWdJa8DQnz+xx S9G4J5MoD3m8zifTWCX42wF9/Uqv+7Vrs8T6AuG3YnklDNeW6AVBIudvGh6VdcmZ6bD2L +t2E9Pf87EQTY2uM+hmI0iJfBJ7NCmQ6NtkgueJ+w8FIWlNFna9oQRMmJNMz0nZ3zSj7W zHripiVfTjcoOFBLfbTUWbJS4xLfXZwOSkbh4Qee75h7UllFHbpMNd/ev1geRVEqvV67p jhom1tJneit5Jn0w7fxBE3w06ELFgLIfM418Vm/u22UdcG50HNUgdmUAgioo1LFbkIsdb sHlvAvyfRjhpMkgR9jLl4NvTZH9AvBh1RK2Q17LL6xnwaJ/pWpPvpGEkcVOZed5DEMHMD ynHitU7nePbBE/77VrZd1RsIf2BBsy2H99mKdG/rrkAV+f/nQfZ/CSUjgNM8yCLDBQOmk IPxWAKdYBT6TTKB4xRaxmJzpQaulhHxyiazVMFXLUohGuOExNCqHY56tn62WU74= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1767629662; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=IRShN447taDVIf8Z0vC2iX4D5SbpGvJAylpvDAXXMaU=; b=L1qPjv9dS+7SBCt7pcv7Ok7uOqznSkYuy57XUvyInoUZr2z6g1AbwS78kYNEMuI2fdd0 6a3MNHjTt2/HugJOBoXz/ky1DvRjTTVm7V04+yczmct22J3rrKfGXotvJTQq1K9A4UHEX 5TWMbuafVhwfy1WQE9qxNPodO2aZEaq+cyKcndFl/2URlAFTsqG41X99bA2/pbmsoIz/d k4YfasMQwafJh9NfYVZPiohBy5T/YrubKi254+LaLuXE3+U3OEKQZIdHqrQnnax/VBYRG dnGZ35E4hLO5sfqDgi+SskRCfcvFt8uqO4FqX5jSz1tkF9sr/zh6CdspuXtmJ2X28/7/g PZo4k0P5Z2JbRjDAC7wxPWCXbZr35179qPVPw6VtrExAdeMd9GwkKTw0FpKgxSb5bAYaE yFw5z4wNg1UvsipSAXin0kslBZsN3dynG47Df7r5vTkBB8G7zAPC7vN/+Zyjw7snuX3KO RCQtFiB8nbIydXTo8TwX53V3qAIPtcDXvs2raTEpym1zMo7U+EqvmqZbswMvH5u19K24U ElJj+QQkwR39/g38RsKrHPD0Afp9ZfF+pArqNNaTvsXztpcdSZkDDa39zJ+RkFlhHAj2/ QN5SnF2jcyJWIA+D3J3XBQh2tWZ/UnyjCg3dQ+gylzk3994lvf9rxTZkBxieB64= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Mon, 05 Jan 2026 17:14:22 +0100 From: Nicola Vetrini To: Andrew Cooper Cc: Jan Beulich , sstabellini@kernel.org, consulting@bugseng.com, Doug Goldstein , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org Subject: Re: [XEN PATCH] xen: rework deviation to address varargs MISRA violations In-Reply-To: References: Message-ID: <33ee7e20703de4f6b7a4c2d49dabece2@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2026-01-05 15:58, Andrew Cooper wrote: > On 05/01/2026 2:55 pm, Jan Beulich wrote: >> On 31.12.2025 12:22, Nicola Vetrini wrote: >>> --- a/xen/common/libelf/libelf-private.h >>> +++ b/xen/common/libelf/libelf-private.h >>> @@ -84,7 +84,9 @@ >>> #define elf_err(elf, fmt, args ... ) \ >>> elf_call_log_callback(elf, 1, fmt , ## args ); >>> >>> -void elf_call_log_callback(struct elf_binary*, bool iserr, const >>> char *fmt,...); >>> +void >>> +__attribute__ ((format (printf, 3, 4))) >>> +elf_call_log_callback(struct elf_binary*, bool iserr, const char >>> *fmt, ...); >> Just one tiny, nit-like request here: If already you touch this, can >> the >> missing blank ahead of the first * please also be added at this >> occasion? > > The parameter also needs a name.  I have both fixed up locally. > > ~Andrew Thanks -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Mon Jan 05 16:17:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 16:17:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195597.1513527 (Exim 4.92) (envelope-from ) id 1vcnGi-0006ve-AH; Mon, 05 Jan 2026 16:17:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195597.1513527; Mon, 05 Jan 2026 16:17:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcnGi-0006vX-7S; Mon, 05 Jan 2026 16:17:20 +0000 Received: by outflank-mailman (input) for mailman id 1195597; Mon, 05 Jan 2026 16:17:18 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcnGg-0006vN-NH for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 16:17:18 +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 01021771-ea52-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 17:17:17 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-4775ae5684fso487815e9.1 for ; Mon, 05 Jan 2026 08:17:17 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d6ba3af58sm64115365e9.2.2026.01.05.08.17.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 08:17:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 01021771-ea52-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767629837; x=1768234637; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=fib44n/6C5mBpRqag6xUcSyFFCTC3CvyredpLYirKoc=; b=OGDKBGU7PRIxI5ExtJ0gqn24nPrJRDzH+qJHmrcG5mvP99IRV+tHmbiOnM6AcYh48x KIe5wjsQGHxT2gxWO5w6ejcZalQ20p64Ot/yh/uMxhjlpd2Xo62kmqE1BslP49xOY6bS w6MhcU/ZQJp8oWNro7KIJWXub6ghlprfUbTzOLgmWdX/06esclXIplqFGLToTbEX5sb0 lF0See4rrZbP4it4CLvRdcQX8GFNjbF1IjG8OVN5tGxvMX2QFQXFGQbQ+1y6eATEftII SfjTPRIJcfIfKGgNvqfke9EBgEpqR4UoITqzftQs14Erxn/tbRyY98NhfJqcPKEapBIM egOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767629837; x=1768234637; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=fib44n/6C5mBpRqag6xUcSyFFCTC3CvyredpLYirKoc=; b=Ra8ocHgnPVTrdgt04wJIed20B8rgRej8VNrqDw/kaSpFR0HZkq90oFFGsm5P0RY+4V pCJKYTu2MWeuKcIYZxf53qr40QMgAySm1rZVKpujW0D9vG48rqZcIpqPZb4tpfR7EqfO 4xc4a6aBRmdzWWOsTWy8G1OL4IDF4AIhcdBhlF1rvwSU/SPQY+nGI58vBuiJNmuGPVLZ Ic0Arf0KAB62sahA5hTrZwTTZ7TunIcVXi69qwDWDN52kGGyr3YkrPGbTeDof7kvW/pX VeAH8TitQYGDtNyfUpcx25HwkDjYfyJ/zgecSs2aqwxeubo0Iekl5AuaPzBMyAxfmdWj WrvA== X-Forwarded-Encrypted: i=1; AJvYcCUV0FhWcTlAQrBKqCazzXO4/qQUX7U0UeXoopg9x8F0viUNuweFLg2tAF5pL33gJNx+9LHKbxGqC9A=@lists.xenproject.org X-Gm-Message-State: AOJu0YynXnUKiTn5hufOOM+1y2+W7cE8inuUCrR9iCL+29t0/8QiNXQt 6C+zeHdCXQtufudviWVgO+pmt1DK+e18F7FBMAD6/pGm3dvlEkvIbxosRE3RZIL9Og== X-Gm-Gg: AY/fxX5z0c7mdD/iyeK7A/0UDpSsQiAYUxharcjjkLOySif3ZPNvaIZzjFWx9TGT9kW noO38i9x8DB4j08HXyMf7jxwLepRza3sxGHqkoJpff681ecpZIzP3OOM1IPh1SZ3b1QlAlJbreb bkFsc++tZ88GeN/klZ4l2XJ9cjbPn4TgtU22JlJrI5W7Mun9oxXsuUzZ3C8Ij6Af0ocR0L+tJM+ 7j2jkJfD1lW/XNdUqdy/F2/6XA9o5bn0jFvdLDcbgw4r5Sk1dq+YfvMS/RaAw7UlgcK03nFsUVA RVgQMx5yDIwLYsal6EeEFPTESa2ahTU4J37AcrgGRJ7sUjq4VYuvzfWSnX3TuIUryv+a+PCucXg UtNtjVCY2lVdhNcL4uCspX44K4vb80aI13BYmLUE+pb+C8REymaqhmYEDxWinQlpPAdNqRVcMzL Ph8mdrc93o3AdPHhJIsY8BokEBezNbnckbZfB7WYz3zZR9u84kXyym+kxHbMbYV3WYv+D6DGvG/ uY= X-Google-Smtp-Source: AGHT+IHO06bkhLszfPEOnmL/BXSIuwkGQOUAPYA5I2poM6TmOYIc2Kd4Hg0NfyCLVJ3xEZvsefCahA== X-Received: by 2002:a05:600c:64c4:b0:477:7af8:c8ad with SMTP id 5b1f17b1804b1-47d1959afedmr633866395e9.31.1767629836857; Mon, 05 Jan 2026 08:17:16 -0800 (PST) Message-ID: <3df1cf4c-f7c5-4592-90f9-1bd4065559e6@suse.com> Date: Mon, 5 Jan 2026 17:17:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 4/5] xen: Split muldiv64() out of lib.h To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , Xen-devel References: <20251230135050.188191-1-andrew.cooper3@citrix.com> <20251230135050.188191-5-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20251230135050.188191-5-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.12.2025 14:50, Andrew Cooper wrote: > --- a/xen/common/bitops.c > +++ b/xen/common/bitops.c > @@ -247,3 +247,15 @@ static void __init __constructor test_bitops(void) > test_multiple_bits_set(); > test_hweight(); > } > + > +#include > + > +/* Not a bitop, but here in lieu of any any better location */ > +static void __init __constructor test_muldiv64(void) > +{ > + uint64_t res = muldiv64(0xffffffffffffffffULL, > + HIDE(0xffffffffU), > + HIDE(0xffffffffU)); > + if ( res != 0xffffffffffffffffULL ) > + panic("muldiv64(), expecting -1ULL, got 0x%"PRIx64"\n", res); Nit: Better %#"PRIX64". > --- /dev/null > +++ b/xen/include/xen/muldiv.h > @@ -0,0 +1,18 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#ifndef XEN_MULDIV_H > +#define XEN_MULDIV_H > + > +#include > + > +uint64_t attr_const generic_muldiv64(uint64_t a, uint32_t b, uint32_t c); > + > +/* > + * Calculate a * b / c using at least 96-bit internal precision. The > + * behaviour is undefined if the end result does not fit in a uint64_t. > + */ > +static inline uint64_t attr_const muldiv64(uint64_t a, uint32_t b, uint32_t c) > +{ > + return generic_muldiv64(a, b, c); > +} As to the file name: Are you expecting any other forms to appear here? Else why not make it muldiv64.h, matching the .c file's base name? I'm not going to insist though, so even with just the earlier nit addressed: Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 05 16:21:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 16:21:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195610.1513538 (Exim 4.92) (envelope-from ) id 1vcnKI-0000E1-Uv; Mon, 05 Jan 2026 16:21:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195610.1513538; Mon, 05 Jan 2026 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 1vcnKI-0000Dp-RG; Mon, 05 Jan 2026 16:21:02 +0000 Received: by outflank-mailman (input) for mailman id 1195610; Mon, 05 Jan 2026 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 1vcnKH-0000CR-NO for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 16:21:01 +0000 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [2a00:1450:4864:20::333]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 85dcbb0d-ea52-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 17:21:00 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-47d3ffa6720so968245e9.0 for ; Mon, 05 Jan 2026 08:21:00 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d6c0c148bsm59048055e9.18.2026.01.05.08.20.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 08:20:59 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 85dcbb0d-ea52-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767630060; x=1768234860; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=6jShIZmeIibAp/iblNc8xKCcRTgXVm3tEsNaObNaPks=; b=SG08rxz4mGwrwSupOGsarg4yfSU4izsY6I1FP/7LqwrdmC6jGXuhagx/eoWLaLW+cy aiZl5c4RcPdkz9waCbOOVruoo7m8GyZ/ghiMLuTVXd9m4TF/jX8M4IYXlVgQZh2bAtZw QZFLcs/PXgZwr3WQuAIJvoBNlBkr+SmtO0iZM1/HucmNUrTbNLpLOGXEyHvCSd+eTa2g aiHZnzQ1/7xWM0l2r89VrDndGkdvTIHDuN/Uk9YVhTZr7Ne9adsz+DQTCmJ4EeMWNcpx d3s3+L3hOlh7loxTkxgfaQstfYGVnciXjjRPRY1ZHug5lp4Rd72QyRvhZxB32NW2So0l DXYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767630060; x=1768234860; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6jShIZmeIibAp/iblNc8xKCcRTgXVm3tEsNaObNaPks=; b=Bv2/aTJbHePthqGTtHZElYmVt99RRB8/QpOS+kka1k9Tc19bP56QXEePpm9JFCaSTn 2m5PinlqwHL8RuAeUqzKSsNQH2FQ4V158tF0H+ohQZqYMLcJP8bGKBSkf4YAzoLjnl2P gCekHeDXt2DXoxpoATHBw5GZV06pXXqLuYA7ULbMWX1mbxvDR+FKxysYBbRlD4jy/Xqx 8G6cyWypg9Cqvht7VW6s4oqNCUVL49gVxOXoiLJX3wSrvgLv2CfDqJzgWERkB+SlbHBd Eq0AIu299y59GE9VaGwbPhirFrTopQXImQOhfgPWyRdbPrJPIjEJZNzLrnhjoTGRaBff ALcw== X-Forwarded-Encrypted: i=1; AJvYcCWuilRJ+ZYpA0d0ZBAOMMrB98Xk59iB5Yv/x3H57DGqjzhb8sv00E55EngYDXrvWWUJyj21GhYcUMM=@lists.xenproject.org X-Gm-Message-State: AOJu0YxSQtVsJvTKA7GZWH0yunFY9v/ZPaAuskgv+awN1ve6U5EuEtv2 AJzixqAxvyR6rhJO83LddPJO69vMCQJB8wvSY1GpJ5iIXU6z1V+sUfbVpRUNo/U4Yw== X-Gm-Gg: AY/fxX7N9qOzrWVjkoVk4YiBFhv2NkM4Viqm7OX+2Zp279XqTtacjoJm4rUelvy76k7 18I6O+Z6y5BZNphYvBXPOBw9SqJRA/bK0dDJzC61PO5C8nc48WRWHL4qN+1IBZTsTHhUXR8btUk MW3YuXTlx+0N8OkvSmEgTl+BtX+jJua/3pt8+M+ia37sqB/Z6CDfZdvQmklO6szSyw/gYbUYF1n Kk5wvAEaoaqLRYDPUw3wWLNDeP8b0SysUQupqqUoD9UkqQQxmBrFLKqL6frLYuQC13cZJLLekAY pHqSOSTCvDutSv3KVGZrEf09fyqiEOE2f3HeDDws5/IY35T407/uMEA75WcGkT3Cwhe/mhi8f3F WsPYLoosz4cihYR0aSPH1LRxsIlQl11kw8mCGsIcmX75wEH/MtP2ufiRw3+uOQ6ruiBTdFTTWXC ihZ0sDvLjeYwbaT/eQS+vhstuWlsvALJ0dpD3xIDv2Sdxe0IEUflxvVcquYU85PYz+VXKNFL6uo vY= X-Google-Smtp-Source: AGHT+IHC4/bjaxk7rbgEq6X3hbUtdI6NFGo7WESuZAuGb8yskDUM4VmV8+pr9213AOk5vrQzKXyhZg== X-Received: by 2002:a05:600c:c041:b0:45d:5c71:769a with SMTP id 5b1f17b1804b1-47d1c0360b0mr450664335e9.26.1767630059803; Mon, 05 Jan 2026 08:20:59 -0800 (PST) Message-ID: <4645c4cf-6ae7-4ae3-84d7-6cf00c49d113@suse.com> Date: Mon, 5 Jan 2026 17:20:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 5/5] xen: Move x86-ism out of muldiv64.c To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Oleksii Kurochko , Xen-devel References: <20251230135050.188191-1-andrew.cooper3@citrix.com> <20251230135050.188191-6-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20251230135050.188191-6-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.12.2025 14:50, Andrew Cooper wrote: > Having an #ifdef CONFIG_X86 section in a common library is rude. > > Furthermore, for x86 the main logic is 6 bytes, If both insns' operands are registers. > meaning it's ripe for > inlining. Create an x86-specific asm/muldiv.h implementing arch_muldiv64(). > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 05 16:26:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 16:26:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195620.1513546 (Exim 4.92) (envelope-from ) id 1vcnPL-00011v-FT; Mon, 05 Jan 2026 16:26:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195620.1513546; Mon, 05 Jan 2026 16:26: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 1vcnPL-00011o-Ct; Mon, 05 Jan 2026 16:26:15 +0000 Received: by outflank-mailman (input) for mailman id 1195620; Mon, 05 Jan 2026 16:26: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 1vcnPK-00011h-2u for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 16:26:14 +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 3ff4a40f-ea53-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 17:26:12 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-47d3ffb0f44so561255e9.3 for ; Mon, 05 Jan 2026 08:26:12 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d6d45aa2fsm157096235e9.13.2026.01.05.08.26.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 08:26:11 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3ff4a40f-ea53-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767630372; x=1768235172; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=edV0gUOR7nY9cH1pifz+KBx2Cfr0fY764GA/rtQ9ryg=; b=L9e9ATc8CZz+d0AqzUma7T7ynZKAVMpww6XNVZAKWaJ6BUcqoPo6Uh+C9uwcHtqhjh gsSNNmE41YIbQAtWRDOg7RJ8nGYtB4th8ZqTsktyBfa27m3UPGWsZVYVJrA8ClsU1gf2 +cDkZfFN+kf2LIX6SpmNmV2i0GtBMmDi40aluapH626T24b80wbEQ+dr5yiAOMFsm0bO C99TX4XOeHe/pBZQDQ8A6zZOZ9MRyp7HnhR66Gu8m1q9WnvE1gu1aZHmfKuL3ExO4M+o Jf3IphriD/sJRxYb5nSFX7rf/W3Vio/i72jOCvjhiMCj7Zx1gojYrGPHfS5kcIVJ95Q4 REgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767630372; x=1768235172; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=edV0gUOR7nY9cH1pifz+KBx2Cfr0fY764GA/rtQ9ryg=; b=ulIQt5krM+VDMKlyE01yIzWmCtBlcnvP2BJGCUfwTsG6fz9wemRZoHLqkmbivjIFVN XDKLnegpZVjYcjXsqRAsEC31UsT13KjObC3bQ7U28Jfrb1XVKRpj2V3fUn9++wA4Sfr8 ewL6dhSv5K3Z8x24R8aUx4VVkJ/TpCdGPVKPDJsPQ1OBSyVJuz6oYhuZ8yAwooC2IeGg rREuQEE9mcfIDq6g4OyuJ4li5VSehUuq6H9n8Ew6MZFTyMAlG9G15sxZ6IXddUgE7YLG U+RLNl6xr98eviAg31iUBq3vlCzrDLipl3QvBeWWFlyHfTsfsX33MnJ8c7DveQwDjuW8 0g0g== X-Forwarded-Encrypted: i=1; AJvYcCVFnZITheHeWo6FNrcXEEGFECOK6tAM1DRXLsWD941Zs3N21diatHA7AfF+bWBi//TPtrafjIQcP34=@lists.xenproject.org X-Gm-Message-State: AOJu0YxI+Tn3qLYs9vfW3cAExuhDB61pxCh9FVHbtGmDHHSd7B4WFYXj LzVVvAHHDULQfvuz169BBp5ulf/upyarLQ6LOCLgi5yx+bgg2QD947uoGdPvoRXx9A== X-Gm-Gg: AY/fxX7SDM+Tjlk2jLHpoXcpkiKx56TeSfCBYz46FcYs5qjyUACJdzir4bS+sCe8w5a UtrJyYOfgArWqWyBoR9q34fMAhzgLuDa8E3tResN5kp5YcLPrxsIaiqPV/zUyD6XVleLcXvaZua /aUm4IbfDrxZ1P29hQV2uOt840ePVpsyXneTDA6J/65PrtJGjoDBt8XbOAGkWWQoln58ky+zXnT ONEaHYO6L+2TbtZFfbTVjhsMSIgwl+Kr9VzfavjnU1mkvgCqDaNArK2gjOeWKvllV5z+L0pttF6 VySgpMVXZFVjZ2Hn6Q3chfRsqcVZxkQ4zxYgqbwaF3erHe0pC4Hzhw1wT2Ot6scKecEMWBuNEyH 5yqa1DZBRu3sniddoqY9toaTSzAT4+VF4FzHhLVu7AFKE+5nHARCTF+rA3M4917a/xc31bRVbNh 3G/7CGzQHcY/Lzz+nkh90fau/8Ycf2kV6QA6yMqqeuHYYITHydk0/Vb29WzlPa6JOTd1rqs6w7w 25/1Dw9VKerVg== X-Google-Smtp-Source: AGHT+IHHa2n4VdrYc2IaW2mvpmc9IT7q+wFhO2fin3Ufa4JVXVUTo/OYtKAAr7iqkuvsn7zYXaoAoQ== X-Received: by 2002:a05:600c:198b:b0:477:9fcf:3fe3 with SMTP id 5b1f17b1804b1-47d1df12f84mr606872715e9.0.1767630371898; Mon, 05 Jan 2026 08:26:11 -0800 (PST) Message-ID: <63a1aa58-f609-4bfe-b827-90c59e40a02d@suse.com> Date: Mon, 5 Jan 2026 17:26:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/1] xen/riscv: add RISC-V virtual SBI base extension support for guests To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.12.2025 16:50, Oleksii Kurochko wrote: > Add support of virtual SBI base extension calls for RISC-V guests, delegating > hardware-specific queries to the underlying SBI and handling version and > firmware ID queries directly. > > The changes include: > 1. Define new SBI base extension function IDs (SBI_EXT_BASE_GET_MVENDORID, > SBI_EXT_BASE_GET_MARCHID, SBI_EXT_BASE_GET_MIMPID). > 2. Introduce XEN_SBI_VER_MAJOR, XEN_SBI_VER_MINOR for imeplenataion of > SBI_EXT_BASE_GET_SPEC_VERSION. > 4. Introduce SBI_XEN_IMPID to implement SBI_EXT_BASE_GET_IMP_ID. > 5. Implement handling of SBI base extension functions, including version, > firmware ID, and machine-specific queries. > > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich Albeit with a question: > --- /dev/null > +++ b/xen/arch/riscv/vsbi/base-extension.c > @@ -0,0 +1,82 @@ > + > +/* SPDX-License-Identifier: GPL-2.0-only */ > + > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +/* Xen-controlled SBI version reported to guests */ > +#define XEN_SBI_VER_MAJOR 0 > +#define XEN_SBI_VER_MINOR 2 Is it clear from whatever spec it is that is ... > +static int vsbi_base_ecall_handler(unsigned long eid, unsigned long fid, > + struct cpu_user_regs *regs) > +{ > + int ret = 0; > + struct sbiret sbi_ret; > + > + ASSERT(eid == SBI_EXT_BASE); > + > + switch ( fid ) > + { > + case SBI_EXT_BASE_GET_SPEC_VERSION: > + regs->a1 = MASK_INSR(XEN_SBI_VER_MAJOR, SBI_SPEC_VERSION_MAJOR_MASK) | > + XEN_SBI_VER_MINOR; > + break; ... implied here (it's ..._SPEC_VERSION after all) under what conditions the version would need bumping and what effects this would have on existing (e.g. migrating-in) guests? Recall that ... > + case SBI_EXT_BASE_GET_IMP_ID: > + regs->a1 = SBI_XEN_IMPID; > + break; > + > + case SBI_EXT_BASE_GET_IMP_VERSION: > + regs->a1 = (xen_major_version() << 16) | xen_minor_version(); > + break; > + > + case SBI_EXT_BASE_GET_MVENDORID: > + case SBI_EXT_BASE_GET_MARCHID: > + case SBI_EXT_BASE_GET_MIMPID: > + if ( is_hardware_domain(current->domain) ) > + { > + sbi_ret = sbi_ecall(SBI_EXT_BASE, fid, 0, 0, 0, 0, 0, 0); > + ret = sbi_ret.error; > + regs->a1 = sbi_ret.value; > + } > + else > + /* > + * vSBI should present a consistent, virtualized view to guests. > + * In particular, DomU-visible data must remain stable across > + * migration and must not expose hardware-specific details. ... what is being said here applies to other sub-functions as well. IOW it looks to me as if the version reported needs to be a per-guest property. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 05 16:30:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 16:30:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195630.1513557 (Exim 4.92) (envelope-from ) id 1vcnTT-00036K-VE; Mon, 05 Jan 2026 16:30:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195630.1513557; Mon, 05 Jan 2026 16:30:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcnTT-00036D-SP; Mon, 05 Jan 2026 16:30:31 +0000 Received: by outflank-mailman (input) for mailman id 1195630; Mon, 05 Jan 2026 16:30: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 1vcnTT-000367-De for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 16:30:31 +0000 Received: from CH1PR05CU001.outbound.protection.outlook.com (mail-northcentralusazlp170100001.outbound.protection.outlook.com [2a01:111:f403:c105::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d8f08d5b-ea53-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 17:30:30 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA2PR03MB5802.namprd03.prod.outlook.com (2603:10b6:806:f9::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Mon, 5 Jan 2026 16:30:25 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9478.004; Mon, 5 Jan 2026 16: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: d8f08d5b-ea53-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=d6GM7R+Q3RHtFDRPTeOrKUu2GAbNQhyNEstjAKh+31papcrjfOUO1hjCStbO39AcX0e2rs2UZ5mJ1cx2MtHnmSHzU5h2B9Pfar4mDIW74Mg2qOrh+0QEAstfokilal4iC8XC4CJ6jP12yK1HK8d1d89/5XE+SmQ00uC/uQgYYec/IhhnX0GAu+cPqXX9F0QSEHFH6eFj0Qq5ziT2jeznRp6KCzeXgJz3v9wlUD7rcxhjAwc1VXoNkHQ006JT645/sw2uqEHndeXk616vULqgta+XiIdISkrzPPRHX9ph36Wtg5itTAgFv5x5N7VuWRkfFGo1voEXHXaMIxefRsKQeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jNMfRUWDIRwvlSqEoaathDbUKK0R3FDWIkAAM7ol/hU=; b=Wsi9/OKkgsvYYK6Dvvd+SWpdVmzSjL3bqfBEzYKGFdRlippIBXofQSYFbTuWswTxQXNW0naZn2p26OX6ReLnwjuMhRZUr6sSANn1A9t4LFeFMH7ZoTe6TyPVcDb2+CmRGrxJRcMqQB8eloMHZkEl6Xx0saK/HztqKnb+toulAuZnvGJJmha/cv6VfaE/AVz3KweV16/yYR2J197GfNHNComJ7v6GV+dC/yZihwsCLy6XNO5fb31BoddyPe0+x1Nyl+mO6orks5nFLZb3iP0T5jrTF5geBEugH3ZXTNLfm/E3W6546BmgBmmFct2o8F1nSBznplq3O+00Y1QYgOppig== 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=jNMfRUWDIRwvlSqEoaathDbUKK0R3FDWIkAAM7ol/hU=; b=FS8kv9JpzZldC3ANHsP/syNeXuoTuTtXdtuK16Kbk/TDqjqHRaEfST4KxvLOXjC2OWX0QXcIDjAb4wnAbY9B9csybJyD7NkVVPZdeveQjoSH3OGq1LFUGM116/2Y607/o+QFpQH4U99/kthf6fRgRJmxmTJpooaDW8sdezyAFHU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <20a27b92-f356-4905-8a3f-b76eb53dcd5e@citrix.com> Date: Mon, 5 Jan 2026 16:30:21 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD Subject: Re: [PATCH 0/2] x86emul: use vpath uniformly in harnesses To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <4c2a53b1-7133-4900-8bc8-26fc97aa1702@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <4c2a53b1-7133-4900-8bc8-26fc97aa1702@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0114.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:c::30) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA2PR03MB5802:EE_ X-MS-Office365-Filtering-Correlation-Id: e2a81d05-b5ef-49f1-7d7f-08de4c77bad2 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?NGpjV2dNZEVJS3dOVXV4SHNkVUxscUZQMWJQaUFGZHJteVF6RUxnbVNkTkFH?= =?utf-8?B?YVc2N1NsVFlPNWJZVk42d3JBVGJSSmRMTW9kMmcva1BYbW9wbnNjcllaS2sx?= =?utf-8?B?WmpUREh2aGprWE5iOWRoV0R6bXU1cW91bU1CYkVmUnkxanZIN0tFTXUreWRx?= =?utf-8?B?Wm51cnlQc090ZmVXcHZweXp0TkdBQUtkcmNOR3U4dUI0dUVDQ1AxUCtwcHJD?= =?utf-8?B?VkhtZnQxckh2QzFZVjg3OTZ2WFRXNkFYNWVLVk83SEE0dmtkVmFuWEdUemxy?= =?utf-8?B?WkhjQ2M2Ly94azFvQ0NGdU0rdmJpLy92SWpoMlozMVNYTzFaRnVMUHRRaS9I?= =?utf-8?B?QzFTNnBaVjhMMXVqSFB0ajV2ODJOT1V1bEM4UUxyKzFFcHdvY2dWcmhxVVhh?= =?utf-8?B?cHZZemdscVRCSUptdUNuaVlPajBkbjlTdkMrajBmWUV3RVhlMHZZMEJ3ckEx?= =?utf-8?B?MnFIN24rS2kvTTFPc0NwZEUyU0k0UlZMSFdnSE9MekNQWENocENUM2x5QkZi?= =?utf-8?B?cDVLSmZIb3FZQ0FoKzBhMWszNHRNL3plT1FDQ3o3V3ZRVWNHVVVRYkNPanJk?= =?utf-8?B?STQwaHAzZFp1UFJWNThRWkJhYTMvWkNUMmZmRFVSQUo2SGJJRUxPT2V3MTJz?= =?utf-8?B?QVF4WExmY29YQTlyOFhSVGYzWUhZUGQrUGRGdm9BUWVGamEvR0VoeC9MdzEz?= =?utf-8?B?SWJpWjk3U29xdUNSZ0h3RTgwb2N1UUtZdk1QVkNVY3Q0dUJrZXAxcWg0NHE3?= =?utf-8?B?TVpvQ0J2Y3E0ZENhR3A0VVpDMHZyanVNSExPUzBpZmZ5NFY4dlVibldqYTc1?= =?utf-8?B?bHBEQ005U3ZmVjNSK1VtQkRUdXpSb29tdnF0K1pXMFkxRVp1Z2N4OExhWk9p?= =?utf-8?B?djFobWJkcVRzSlZybWdWZ0pwTCtpaEZhUEZDYUJ4eGdnRXNMU3BOc2VYa2xI?= =?utf-8?B?eDlWa1ZUd2xjcDNQTHZsM1NkWjdXN3pXQmZoMGcwQWtRZmJzbzhRVWtkSUps?= =?utf-8?B?THF4U3FNWjFJQVV0UHNuQjBlRFZBd2xiMzFCSStLdGIwMFQraXFmN1VNK2sr?= =?utf-8?B?WHFMM0p1bmxUSTdhSVNBRkhDTFBYb0VaU2hTaWU1bkV0TTFzamZxOGQrbXEr?= =?utf-8?B?RENRVnhPUVdlY2Y5b3ppSU14MENwR3haQjJjcHNhSkpzNktWYzh5Q1o1Q0Na?= =?utf-8?B?QjhMWnZVbmtZU2haa0hCeDBTd2g1cVAxTHd4YnhGQmJtS05PcEM5cE4zVjBY?= =?utf-8?B?bUpDM2NxWDN6QWZRYm1TT09NMVRFWk1yYU83YkNuNmNUVEtTV2RHL0ZwYmxV?= =?utf-8?B?SmtLTVJSc042Kzh3b1p6NmVtek9Ba1owRWNkcXcvQVZwMEtFREV2ajNtaFJx?= =?utf-8?B?ZUdPMU9YNTZKb05wVDhOdERNeU9SMS9EMithMmNKbU1WWmY1TU40bHByMUh1?= =?utf-8?B?Q3VzUFNRU3pIQU1LaWk4ZHRubmJFSDVUM0pRenJrRWJET09USjE1YUxmS3JU?= =?utf-8?B?amZWQ3RUck1PTEE0SjZRamxDS01FbkdXUnNnNUtjVmx1c2xxZ0h1ZXBRMkJj?= =?utf-8?B?VlI4OFFBb3VPSklOSXVWMG9TL2V4ODIzWlRMUVkxTnJKV2tiaWk1WENFdWFk?= =?utf-8?B?Y0g1Skx2cGtlT1h6bS82cHR1aERCOWtwRUZyRkVMTlMyem9sMXpiSnNCNzMx?= =?utf-8?B?NElMbHY3UURZblBSMk15N0lETzg3Z3FNdm9rZ1VETWthSDM0TEVka3VscGNK?= =?utf-8?B?WW1QYmdNUVFPWENOZFhUY1p5UVlmUnc4enQxYVBJVVNNNERwY0RhRzRveERF?= =?utf-8?B?WmJXRnNnTEliRVN6RWNVZlZPZEp6d2xzVWZkcHlOMlBEcG5Tdjl2cFZaSzRt?= =?utf-8?B?U2JlQ3p1bUlrVk1JNU4wUjdEL3VPdEl3c0pDSUNHVU1mOFRlNy93QnZFeUlV?= =?utf-8?Q?GJ6DogZSFgm0YyIMFTx1K0Pcs2BRFhKP?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UnlheGhLMEZzSGlweEFFU3k4bGNsNlpDc0pTbnR2MjM4bFIzRUI2dW53Vnd0?= =?utf-8?B?TUFOUENWMEFRcHpIWkRqUGk2dlRWdGZGUmhpV2ZHZ2JsaWp2WXh1WTB4V2hF?= =?utf-8?B?OUNtU3VTeCs1VGRobm1YWVA2Uk9HQkhhTzQzdHZWL0JReHAvZUdJMjNDNVB4?= =?utf-8?B?dGVlVjk5YWlVbElwU3p0aVUvQVVDZ1l4WmVibmJXcXdiSkVXdTdMVm1QUlFi?= =?utf-8?B?aisxVmRuTHpTRWoxN3o3TWhFL3JraGxyN2lVeFhldWpROE81aFZ4USt3bWg0?= =?utf-8?B?cHZBM09jNEFoZHIzeGJMbWxLS0dhOGFVME95cGU2K1ZWajE5dVhLbFZSOUNX?= =?utf-8?B?cXV2bEFpb1NYS3Yvc2NLak5TTHF1QW1zTHRJQXJnOE0rQzRnY0gxQVRnTGQ5?= =?utf-8?B?L2VZQlE0WW5ONEQ3OTMrcytmT3FXUUdBdm9SemY3eHF3ckxvVDdHSjl0cW5s?= =?utf-8?B?Q1hydEgvakhiNWphR3NUNFJ5YlBIRk9mekJBUFJZYVZFTEM5UDdibjJTekpQ?= =?utf-8?B?VStQYTR5WHAwRkpPWUlEbWszUWoxT3RhdjVPNjUwd1FMRWV0SU1PeDlQUnN2?= =?utf-8?B?RExVeFdDZUdJNTIzQ0VXWXc5b3VBSkM1Y2NsSk5qTjVod2NlTzFicmVpelhM?= =?utf-8?B?TEg5S1lCdU9zNjlHL092UlY4K1dxRmpBOTArbk1DcTlJMGg2clNGQjd3ekVS?= =?utf-8?B?OXphWkc2V0tKK2xCLzFaVjVwOUdHVGlJSEljbWwzbE5OcE1GNFFqRlF1ZTNm?= =?utf-8?B?SmJlSnZDeGRVNUNnb2ZtN1F4dkFBTGV6MDBuMUFRdkVFZlZNYzRMVlFZQmVI?= =?utf-8?B?UGE1bkxjWk5OMlhFM05NcUtEdEF6STYyMkZWYzhHSkZtdGtwNTdtclFMbGNw?= =?utf-8?B?SGRsaHJZWVN4NHphZzhIT3F5Y3VCOE1CS1loYW94YlFwVDV2dGZSMTlOa1N0?= =?utf-8?B?d010azNuN05hU2RaNFNiZGJwaXJXbCtiQXprbTBnMS9ybE4rUGRWcXFLd2pX?= =?utf-8?B?MnVqd2V0OXpTd0JMLzhFOWhXUHNtY2VvaElBUU00K0hzUFdINHJIUWRTRGVO?= =?utf-8?B?c0ZHaWZsRi9ZRXljWmF6OU5tRHdxU0RXeHhjZTR3ZkRKV0lvM1dOQkVsVk9i?= =?utf-8?B?Sk1kemRJZGJJYXlDcnV5VFhvUVcyY1R5YXFDOVgvbFRIMkxqNEtQMEllOXc4?= =?utf-8?B?ZW5Qb1lMWStLT1JTTXJPcDcyRW5WRUJncHBTcVlUNXllcmhtUWlYZWROYlNL?= =?utf-8?B?d01aWHZBZWc2aDlRMzdDVndGd2xTWkhuU3dvVDcya0UxdGhaeGoybUNqYnBW?= =?utf-8?B?bGYvNm1paE5OYnJPVitDQWFRWHU5SXdHcG1USTFWK1piQlgzMW9kNU9pZXhX?= =?utf-8?B?ODJDREI4ZU9yRXh0KytMSDFkNVB4V05SMUR3aVRWUHZYQXhnWmswWHNBVU8v?= =?utf-8?B?d2dLVjR3TGQ4WllhcmFsbVNNWk1LeHlLa3pOeC94TDI3WUI3L0pReGxRdnZi?= =?utf-8?B?bEhTaU5tRGxmbFFGUXcvN2pMc2t2eVQwdFJLNVIvamtkTTc2c2lyVklqWm1o?= =?utf-8?B?b1hRRmcwMUJDLzNiY0tOWDFSZVRzcW5BRFRhVi9KcHpsQU1UcStxTldYRldj?= =?utf-8?B?dFlTYXQ2dXJyYldHTjErdDM1YlJ5WW1NWXNDZUhRdUcvanhheU11T1BzcnBu?= =?utf-8?B?S3FHZ24renRpYUk3Qm1zWGZvZXNZZWRVRnRjcU9qUE1HUU5UajIrdmlUcVhu?= =?utf-8?B?KysxZzl6QW5FNjhmLzhOWlZUOVgrSFNwR05BbjREbm9Ta1ZNZE9NZFBEeTdl?= =?utf-8?B?VCtKSHpkSmJrT3lmLzdXNkp4TGJnZ20xVndVZEJRTzN5cDRQcUpSaExFQmpB?= =?utf-8?B?cXUzRytMN3kzRlJHREFzM3IvZDByOUFKVDdmMXF2YjVVRGwyZHFRR1h0NHpE?= =?utf-8?B?TGpIc0xNY2NJakFOZ0RSSkRUekVjUmF6L3pXaXY1U1ljdnpVTDh3TXdVQnF3?= =?utf-8?B?REtQUmR1WHNjaEw2dmNCZWp3ckxyTVVOYWlzbUM1T2o3M3RHUGZkNmdReFlQ?= =?utf-8?B?cUxZQmR2WGtTSVl2TmNqT0Jxd0xzeWF3YU14eUY4bDFGbHo2U1JtK1RJSmNN?= =?utf-8?B?YVhDREVxOGQ3Z0RPVEd4Q2xRdGtBUkZBOENXNmhNYnpyQ0QwTVVXMG43aTBk?= =?utf-8?B?VFRIaXZBUXFvZCtSUEd0dGN6aTVpN3hIakFyZmRSR094c2pzeFMyT2NCdUpB?= =?utf-8?B?bS9XK3BFWmhpVHVPZFhwTU55WFBYbXdHNjRNS0tCWmFaOXlSQ0Y5V1Q5SUZG?= =?utf-8?B?R1dJa1pHZVFiUHc2MzJwSm5lc09tNkU3SnJ0a1RiaFJwRnh5VE1xQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: e2a81d05-b5ef-49f1-7d7f-08de4c77bad2 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2026 16:30:25.3056 (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: MTqYUbJ37kJughMPVD9JRDINWEPjPXGQ+KjKI6TQoJmXAI3ynoAx2FlCbm/V25M/DhH25m94RdH4XCxrLrbROTFOR+SkDwLcJsytP5zKQHQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR03MB5802 On 18/12/2025 10:58 am, Jan Beulich wrote: > While seemingly independent, the latter really depends on the former, or else > the fuzzing harness build's behavior would be dependent upon the test harness > having been built (and hence x86_emulate/ there being absent / present, > offering source files [as symlinks] which really should be taken from the xen/ > subtree). > > 1: test: use vpath uniformly for access to code living elsewhere > 2: fuzz: use vpath uniformly for access to code living elsewhere Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Mon Jan 05 16:39:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 16:39:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195640.1513567 (Exim 4.92) (envelope-from ) id 1vcnbx-0004Ce-OT; Mon, 05 Jan 2026 16:39:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195640.1513567; Mon, 05 Jan 2026 16: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 1vcnbx-0004CX-Lm; Mon, 05 Jan 2026 16:39:17 +0000 Received: by outflank-mailman (input) for mailman id 1195640; Mon, 05 Jan 2026 16:39: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 1vcnbw-0004CR-SQ for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 16:39:16 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 11d5d516-ea55-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 17:39:15 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by LV9PR03MB8365.namprd03.prod.outlook.com (2603:10b6:408:368::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Mon, 5 Jan 2026 16:39:11 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9478.004; Mon, 5 Jan 2026 16:39: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: 11d5d516-ea55-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=s/IHUIuBqFSJ+I9g5kFde+uQmQj+l4aUfzaBZURYHcNbXyFv8RjHEpeIknUrXZG1HMRWODor18Ah3IyZblCGNsWEbBuUQJ2Vs4eR5eH32o19RKOuBo6MDpgTbb+BGCFZykRPQHz0bemj25Zg2xxA3r4sUONbuMt2lbnQ4Or3DczdjynHq8TL0cqD+3zDbEBYgWJHPQHGpmZ49pT2od63ZI5j0V+Mp+9G1v8y/cIlVvFgExYRhRc/QOHbgfUmADGHq4/DIUvsMbK7CjfQUkhFW81bWZQrpUBu9r9s7H9TMbzSK0n3jnrjgaoiuoVjZ9fNzSpnyTJw6/Y0FXrqdaURPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PGBMpuiMJb+UJ2De7d9N+iXS6VpGaV00kOHkC/mEeNo=; b=o2W1JfHWfnyuw0GLfihzZCm36tIKZUOQwkqGdcFhjhoRWwDVVNr8RIIME/fVedFUftICX9U8z4gNjuqvTcGZ9alox8c3m7x8xex+tL+lT5tH5qGYAvv/kU+kg6kQLdw/TpPNgC05VoUh/maq8vw4YiVeKnWaWxQR5JdDVLGkpTWZUJfao5E1wZp9IUbWjOuFjqqVTaSB0YXMZwjSJLHw5W9yrAz83Kpt5DNh03qY+UzPg7u3ysI0fERdGxgbx2HLTq7jEVeahfB2a1bcBQAC1E+uWFaVQBl+xxvGtAOXs+Wxe3eHg1NEsN2apzlCtZnbxXggaTHb3j3fVSTdf7ybJQ== 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=PGBMpuiMJb+UJ2De7d9N+iXS6VpGaV00kOHkC/mEeNo=; b=ZD7SWbXHGjq1IqOHRcZ+py0PPQeEkW2mrzv1Rpgq/k91SQetUHhr+Pta+8ew5y+LbkieDzAvjvQzOjed70SDLo1WU3GG/IMPnlF1OutDyKz/EshRbyMnCr5DsUI/XY82h9bzPIAuh/CywpKk5LY+7hl7hR3RCeLn1drCFDyBcHg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <31301264-0655-4cda-a66c-8768269e0c89@citrix.com> Date: Mon, 5 Jan 2026 16:39:08 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel Subject: Re: [PATCH 3/4] x86/i387: Rework fpu_fxrstor() given a newer toolchain baseline To: Nicola Vetrini , Jan Beulich References: <20251230135427.188440-1-andrew.cooper3@citrix.com> <20251230135427.188440-4-andrew.cooper3@citrix.com> <662888ee-e983-4194-b8ca-f28560881c29@suse.com> <37ff7e30cc0715d619a20d7ea6ab72b5@bugseng.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <37ff7e30cc0715d619a20d7ea6ab72b5@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0167.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:312::12) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|LV9PR03MB8365:EE_ X-MS-Office365-Filtering-Correlation-Id: 5db19400-a324-4a6b-0733-08de4c78f48f 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?L3VCNHR1TEh5d1drNUxnSkc5R3hpR01MNmhGNnF1clhWYmplMU9rWWlLeUpW?= =?utf-8?B?ZmZGSTBQZ1BaSCtzdjhPZDFtYjJKUmlISFg3K3JCZnlLVW5vN0JISmJ4Q2x5?= =?utf-8?B?Y0pNM3pDb2ptR3dXMTFwblpJSFBSV2FlYnJEUm1tWWY1U2RDOEtSTlB2dkt1?= =?utf-8?B?Vm1ULzBaeTZ1aU53b3g0d0xNQVZpcHR6bkRnRFBRbjk3bWRhSXE1NTdudzFO?= =?utf-8?B?M1dQZzhxblJXODcyTVV5Z0RDTll3cUc2MjYvclBISzh3VVpuSFRBc09aeEln?= =?utf-8?B?a2hnSXk3SXdSTE54Y1FHb2JicTRrOEppUHFFUC9VZllZeFlRaDNyWTVWWGJL?= =?utf-8?B?VXpoN2J5VWJ6bVZMZUFDditybzE4d1pNdXN1YjYyaEw1VHFnZzNGWW5OWDVu?= =?utf-8?B?bEJDL1F6ME1TVnhuc2YvcHlIM2ZFbmhDWElUWjVpNjJtY3lpd241bVBKZXJX?= =?utf-8?B?T3l4aWxSdmVhMzlmemFyWEJINktPOWF1N0hML1h4TU1RSk1hQmxXemlRSmJm?= =?utf-8?B?ZklhYUFhVHFEY2kyMk4wRHZTQlhYaEtod2w5NTFwYVE2N1Z0QlBWNldCTC9U?= =?utf-8?B?b242aVhsZlRaeVNNN09XeTIvS1RLWjZzd29ESUZDaG1NTnJkeXZ2blROSVVJ?= =?utf-8?B?MkdXVXFWR3N3WWR5OTVnK2xzMG9kb2xJQVNRcEVCRFR2Z1RpWlQ5ME9UMnUz?= =?utf-8?B?dGNNOXN3Z2JwRk10V1VDYi9rZm9MWFUyRFRrcnBxY1VjelRFd01pYSt4Tndi?= =?utf-8?B?TzBPeVVVUitNcEg4QWwwQk1mVi9JMko0NEVVS2FTQk5QNWEzK2kvd0JCUGRF?= =?utf-8?B?dXhkcENWYnRXM1FMSDZMUlExdXpZakE5cnF4WWhtMGFlTE44bVYraWVsQzBL?= =?utf-8?B?TytOeFdubTJ6MFZoZ1ZtSXpJcnM4RVNsUGJXejlVWU1JNkVTeE5KUWZKemVY?= =?utf-8?B?RGRUMkx5eklMZFZLUEpXUks4WHBRT3Z0Sm9GS2Jyb3RRbDIyUDNHMG9TYTA2?= =?utf-8?B?NEJmZm5ZTVlJbDh2UlFpcmZ6V25IcmNtZmZMSDVSNGxPWkY5SU9GM1dTTUJs?= =?utf-8?B?T0FoajNBa1dEbHB0SDNLTCtLQjhGcVY1em8vSXROYTlSQjY3bUF4ZFREbkxC?= =?utf-8?B?Rm1vVExhVWdqQ1NiMUpPVVBmNHN0MEp5NHdjL0ZsZXdOS2swLzdBaWt1SFds?= =?utf-8?B?ZGJGdk1tdXBMU1UzaTNSUnpIVmZzRjNvczZMeUNDM2tWN2pXcUgzR04vdjFW?= =?utf-8?B?d0xWbitJWEtxemhsSFhETnpDbHJQQlUvV0NGNHJaM3dHNjR4WnkwNTlKQlRu?= =?utf-8?B?bWJac0FrcWx4WmUrQ09jbi8vaTdMZHdna2hJMWg0MDQ4MExFUnBYRE15bG9i?= =?utf-8?B?NzMrRVkzQkJlelN5ZzIvNnRBbzFyRkdRQU9WYk9qYld2ZjAzUWZwNThBZS9z?= =?utf-8?B?YmFUWGVGaWVZR1daUWd1Q25vREJhUjh0WkNSYW9EWGNPTU1jNWJsK1ZMMFlY?= =?utf-8?B?azkyNkt1UjJwNGlaU0ZOOFplYmRRcFJIRmlBZ0xkK3U2TlJKS0pqcmtUaGV2?= =?utf-8?B?eFFBdWt6VW1NU2s0WGMyeEZrSHNuNXRpOGVwc1l3T1hzaDJqNjAzcmY0WVMy?= =?utf-8?B?NDBJTDc1UTJCRWJJbEhIblZCbUZUZzhMVWVOL0wzajN1M2NnK2dJSVZUcFVF?= =?utf-8?B?dm9PblU5aFVFbkJ3MzEvY3J0eHZxbzJLYmhLZjdta1dRSGRkck8wQkpXS0lp?= =?utf-8?B?ZjRYelEzNGF5cmc0SG42Vi9uc2dYNTUxQ1FlMEY4L0lrTnB4VGNGbGNNMXZy?= =?utf-8?B?d0xsNG1OM0NDeWNCSUdKa3lBMHkrTE5mOU16ZS9hbnZUdFZQeUx3S2ZKRTVh?= =?utf-8?B?cloydHZaUldMU2NYNkFxVG5sVUNENmRCZ1FnR2hDa09qVkh2bVlxNVpaTVFs?= =?utf-8?Q?HoFzCU3Itqzcgm9I2hu/u0Mi2UZ9qJCR?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WStZTzhzU1c4NzNJMU5OajhZUVZkRncyVkpsdVd3dUREYzBwa0RNOGtMZ0ha?= =?utf-8?B?MFFNbGJOVC9wbW5ON0RTaE9Ca1p2d0JVa2YySTk3a01jTG1NR29jMjFNS3VB?= =?utf-8?B?S3lrcWQ5eDNwVDJzNWdPb0lVRjdxalR2ZVV4cG1Cd2lEbkZMRGwvZ0lxZjFX?= =?utf-8?B?STFTT2RwQUVSYVRvTExUVXhoS01ZSnBiWDE4WWdvKzcwUXozeWJJemZqRUpp?= =?utf-8?B?YVRjVE5ZTWl4ZmtnZHg5NXpnK09sRTJIaEF5UlhyMzBjRDBnM1QwQ2JTUE5N?= =?utf-8?B?OGtpUGxxYW1tUUd3QVJjcXlmNlFiRkxoZHBYTk16Q0pUUXkvRjdUMlErNjI0?= =?utf-8?B?VU53dHJXZjcvTWV1MGZPQ0dOaWlqeldZL2Nabnk5K3U5ck14eE9kcnAyc0pr?= =?utf-8?B?c0FZUk1WeVBEL0ZsaHJBcjhTdzRCKzJFVUdpU1dUS1JSeGR6VE1MdzQwc2VG?= =?utf-8?B?aEd0cUYvdFI0cks3c3luWDhhZHBqNUVTcUJETTVsOWtPMEt0dmRJM2pEYlBB?= =?utf-8?B?NU9tdVBPalkxbExzam40VDZ6MGViWVFtcFJjMGh0ZW56d0UxT09vSGpMQTRl?= =?utf-8?B?UWpJVlJkQ002cW5PZmhOTnJqcVVTU3EyUW5NSTZYNCtFVEVYaEw5RWIvN0p6?= =?utf-8?B?UlNGaW9aRUZiZjNlSlBhcE9MWTVGcXNYTlBCN1ljZnVnQWpzOWFGOW56NDI0?= =?utf-8?B?akFZR2RmOHFBeDc4K29vYlBTK2VEME1tSXVOL2Q4bGVMSlBwVVJmVm5DbzJ0?= =?utf-8?B?Vi9CeDQzRmI5WlFiVXB0a1k2eFBCL1JtU1doS0wwRDV2Q2JXaHR2ZVhCc1Qz?= =?utf-8?B?S0NjeXlSTUdBeG14UnpOWjBxZ2ZCYjJKNDFwWHIrNlpzTnNYc2tGcUM2SUdX?= =?utf-8?B?NmJtSk5GSkM5UHB0UnRqN0luNGdqeHJJamFDMW41YXZQNXV1cmxMU0lmb3dx?= =?utf-8?B?TEpEUmNOZjU5cWwzUkZPcmRaWGt3VWlIUW1GV2JOZThiVGpleThjSlhrYTJx?= =?utf-8?B?S3dwOElZa1VUNzViK3d0SDU5clo3MXZNd0FlanlmUGc3SVRqZWxZNzMyWmxJ?= =?utf-8?B?SFRkdmNYdFA4YUZmc1hsbFcwc1FneVVYTzBYdlBiSVFLcmtUWTNTMklaUVo4?= =?utf-8?B?b0pMbkhQZEJPamFpZFZMSklxK3NpWkVJaG9xcVEyYTRYRmpUa0toaWNnak9S?= =?utf-8?B?enNQYk9EUGdZUVNiMW5laVVISGpPMHM1ZUhTcEpQY0x0WlFDZGI5c2FFZVpU?= =?utf-8?B?ekZSMEZZWUJzNzk0V1kwNXFNQnF2UlhDTW04cHJZbU41eW5DTDdxNnowN09W?= =?utf-8?B?QjVCNitSWFJYVG5iUDV1Qmw3dW8vcTdldW1LZXRGcEJZWDMvWHkydlh2V0o1?= =?utf-8?B?WWp0NVRRRStPRmkzeTAzd2UzSWlONEJ1T1JzbDlzRndDaTd4dTRzQ1YreVVU?= =?utf-8?B?dCs5Q0tXUnZCQzdERHV4L1ZPazU1NlJRUThGYUtrUHhPeG80UW4vU243a0pU?= =?utf-8?B?WUtWVzNzRmRTeldjSlB1MHNET1dQUXVLQ3g4UkRwcFdib2tjTmI0T2Q3SVBi?= =?utf-8?B?ZVA3bWFWT2NkaE9vci83NWV1YVVTNXA3STIycUhidm1aMUZ1WUh6SmZScHZE?= =?utf-8?B?aUNZLzI0KzVwZlBac3hyR29LU3pUd0xva2xaVURpS2lEaTZ0Wmg1M3NuRmlB?= =?utf-8?B?Q0U4d3FlVVEvZnIydEJ2ei8yUDB3OUtyVjhxb0lKeUs1UDU1YTZ4d1MwbGVL?= =?utf-8?B?YmlMQTY5UnNmSVJkcVJtMVVuSnMzczRXcjJNRnBzdkxIaExYa3NHaGluRjdM?= =?utf-8?B?ZGwzdTI2cXNMbHd5WDYvWWVuZzV3SmNVYTFCdFZxNzlXSnNDOXlSdG45S2hL?= =?utf-8?B?ZDEzVWdNcGdKVW5pRXVVL01NenNlbnVzWW9PcnNZZjRxYjBhZzdPcGR6SG1C?= =?utf-8?B?VVlVRjNVVmtucFlEdW9mMncvTnN0U0RwUTZzR3FXNlZUa2trRmFUT1VoQU9I?= =?utf-8?B?NUUycG9DUWxMT0ZENXE0aVFKcGYrdDJta2RId3hMdlpWMngxUE1LSEpZMlZE?= =?utf-8?B?Y3RaS0g3UElVWU94bGdJdldIaWpRZ1l5cE5iVmpPNGNSNGlOU2dBMGdJZ3Vk?= =?utf-8?B?em50ZW4vSVg4QW1Hc1A0ZjJCUmUwZDNESHNHWmNFQ0tGcTZJR081cnduY3N6?= =?utf-8?B?cE5mMnBCUHpGSlZWOFNOZHNqSkFZd2VnWVZNMDlRaEMzOFdLMkRkYldRZUMz?= =?utf-8?B?bEVmN0dtbVZ1UUVOUFBDSG83ODNNQkZvWmlYODdPUkVHM2FaL2RRMzR6M1FQ?= =?utf-8?B?VkZKKzNSMk5uRG05YTFlcGJKMjA0RnF2NWFROXdjV1Z1MkNrZWZITFIyamtX?= =?utf-8?Q?nqfCIqdgHCC5p9K4=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5db19400-a324-4a6b-0733-08de4c78f48f X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2026 16:39:11.7078 (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: Um/r2RoU7oQaE0QzOeSBlcuPkk5qBWDVDRmAzVPtj6JGat5ycVdALYXiJk+vV+9X5Hdrhiu/2km3m118ETbXzWPHK0nHtdJSwPLMJ/vdULQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV9PR03MB8365 On 05/01/2026 4:13 pm, Nicola Vetrini wrote: > On 2026-01-05 16:52, Jan Beulich wrote: >> On 30.12.2025 14:54, Andrew Cooper wrote: >>> Use asm goto rather than hiding a memset() in the fixup section.  >>> With the >>> compiler now able to see the write into fpu_ctxt (as opposed to the asm >>> constraint erroneously stating it as input-only), it validly objects >>> to the >>> pointer being const. >>> >>> While FXRSTOR oughtn't to fault on an all-zeros input, avoid a risk >>> of an >>> infinite loop entirely by using a fixup scheme similar to xrstor(), and >>> crashing the domain if we run out options. >> >> Question being - does ... >> >>> --- a/xen/arch/x86/i387.c >>> +++ b/xen/arch/x86/i387.c >>> @@ -38,7 +38,8 @@ static inline void fpu_xrstor(struct vcpu *v, >>> uint64_t mask) >>>  /* Restore x87 FPU, MMX, SSE and SSE2 state */ >>>  static inline void fpu_fxrstor(struct vcpu *v) >>>  { >>> -    const fpusse_t *fpu_ctxt = &v->arch.xsave_area->fpu_sse; >>> +    fpusse_t *fpu_ctxt = &v->arch.xsave_area->fpu_sse; >>> +    unsigned int faults = 0; >>> >>>      /* >>>       * Some CPUs don't save/restore FDP/FIP/FOP unless an exception >>> @@ -59,49 +60,41 @@ static inline void fpu_fxrstor(struct vcpu *v) >>>       * possibility, which may occur if the block was passed to us >>> by control >>>       * tools or through VCPUOP_initialise, by silently clearing the >>> block. >>>       */ >>> + retry: >>>      switch ( __builtin_expect(fpu_ctxt->x[FPU_WORD_SIZE_OFFSET], 8) ) >>>      { >>>      default: >>> -        asm_inline volatile ( >>> +        asm_inline volatile goto ( >>>              "1: fxrstorq %0\n" >>> -            ".section .fixup,\"ax\"   \n" >>> -            "2: push %%"__OP"ax       \n" >>> -            "   push %%"__OP"cx       \n" >>> -            "   push %%"__OP"di       \n" >>> -            "   lea  %0,%%"__OP"di    \n" >>> -            "   mov  %1,%%ecx         \n" >>> -            "   xor  %%eax,%%eax      \n" >>> -            "   rep ; stosl           \n" >>> -            "   pop  %%"__OP"di       \n" >>> -            "   pop  %%"__OP"cx       \n" >>> -            "   pop  %%"__OP"ax       \n" >>> -            "   jmp  1b               \n" >>> -            ".previous                \n" >>> -            _ASM_EXTABLE(1b, 2b) >>> -            : >>> -            : "m" (*fpu_ctxt), "i" (sizeof(*fpu_ctxt) / 4) ); >>> +            _ASM_EXTABLE(1b, %l[fault]) >>> +            :: "m" (*fpu_ctxt) >>> +            :: fault ); >>>          break; >>> + >>>      case 4: case 2: >>> -        asm_inline volatile ( >>> -            "1: fxrstor %0         \n" >>> -            ".section .fixup,\"ax\"\n" >>> -            "2: push %%"__OP"ax    \n" >>> -            "   push %%"__OP"cx    \n" >>> -            "   push %%"__OP"di    \n" >>> -            "   lea  %0,%%"__OP"di \n" >>> -            "   mov  %1,%%ecx      \n" >>> -            "   xor  %%eax,%%eax   \n" >>> -            "   rep ; stosl        \n" >>> -            "   pop  %%"__OP"di    \n" >>> -            "   pop  %%"__OP"cx    \n" >>> -            "   pop  %%"__OP"ax    \n" >>> -            "   jmp  1b            \n" >>> -            ".previous             \n" >>> -            _ASM_EXTABLE(1b, 2b) >>> -            : >>> -            : "m" (*fpu_ctxt), "i" (sizeof(*fpu_ctxt) / 4) ); >>> +        asm_inline volatile goto ( >>> +            "1: fxrstor %0\n" >>> +            _ASM_EXTABLE(1b, %l[fault]) >>> +            :: "m" (*fpu_ctxt) >>> +            :: fault ); >>>          break; >>>      } >>> + >>> +    return; >>> + >>> + fault: >>> +    faults++; >>> + >>> +    switch ( faults ) >>> +    { >>> +    case 1: /* Stage 1: Reset all state. */ >>> +        memset(fpu_ctxt, 0, sizeof(*fpu_ctxt)); >>> +        goto retry; >>> + >>> +    default: /* Stage 2: Nothing else to do. */ >>> +        domain_crash(v->domain, "Uncorrectable FXRSTOR fault\n"); >>> +        return; >> >> ... this then count as unreachable and/or dead code in Misra's terms? >> Nicola? >> Sure, Eclair wouldn't be able to spot it, but that's no excuse imo. >> >> Jan > > Right now, probably not, but even if it did, an ASSERT_UNREACHABLE can > be added in the default branch to deal with that. It's fully reachable. FXRSTOR can fault multiple times, and can fault for reasons unrelated to the contents of the buffer.  Fault recovery isn't even limited to only #GP[0] only, and FXRSTOR can suffer #AC from a misaligned pointer. If Xen is operating properly, it oughtn't to fault more than once, but right now the logic will livelock rather than terminate. Further fixes being discussed (better auditing of toolstack-provided buffers) should cause it never to fault for buffer-contents reasons, at which point I'll be removing the retry aspect and escalating to domain_crash() unconditionally. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jan 05 16:48:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 16:48:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195654.1513577 (Exim 4.92) (envelope-from ) id 1vcnkz-0006GN-MM; Mon, 05 Jan 2026 16:48:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195654.1513577; Mon, 05 Jan 2026 16:48:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcnkz-0006GG-Jr; Mon, 05 Jan 2026 16:48:37 +0000 Received: by outflank-mailman (input) for mailman id 1195654; Mon, 05 Jan 2026 16:48: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 1vcnky-0006Fo-9w for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 16:48: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 5df10cd8-ea56-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 17:48:31 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-47aa03d3326so1034585e9.3 for ; Mon, 05 Jan 2026 08:48:31 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7ee79168sm2487765e9.15.2026.01.05.08.48.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 08:48:30 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5df10cd8-ea56-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767631711; x=1768236511; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=E09I5imYmWYeJj+EEPmVbW6LYOM7SpfXkaLt0CMgNbo=; b=A68nNRGpEhCiwTDo6y0FfH3yVu8elnvNu6u0AzAZLEZx61PTnOKX75jA+v5dycRr8q CExB3n/J06R77MuHiAk/RAyJXrF2O9e3pZNxWbfYwf1I40ANTcOrlrbMgDTf0u6mBf2Z TKWKiZTdq4/VKVGmlRvCtwSItKxrpJQboxzEzWmS+nDpNtmwVXPaIrO3aozPKh2Oaem+ /90bpNiVnKAeDmxbPuhpkIrHn00S2xDw/1rxYIDACXDa3OpB24xFFk2r6zrUzft42rRZ tYc5sazDmvvCGVuF72bTjRLHcX+I5l4I0+fs1FZWGqULjPOjc1PYPoSyE2MZxgaERpTj jzoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767631711; x=1768236511; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=E09I5imYmWYeJj+EEPmVbW6LYOM7SpfXkaLt0CMgNbo=; b=cGRv7hwpNxQBkL9wjVVY+EXf5pz6/EhQNUZOLSd13GbEWgqmd/pByZljKDOn8Huram +qn4fZR24b+XrHO31ngDSDkIBX+I7nSnPqOMOEN8GG5xM/xBO0IPuQFPXuDDPuMQHQUB /7y1VXGDzazUa8z8cPRZar/IsufUtTs5unvdYefryHxLwi2a9kkgaFOWXOkHAg4QzHtM IIFyGoFRLQhvBSJPot/cd3isjAZgzF1ytySVaaNKO/fUH1jWYpXeDasTSzIFij+VUdAP CNEHWLhuSVk9S9NQDibL/v8vBBJzfDZ/tQ0ClI9YvItScxUcdDMIrn4EWibqTroR+P3y gD1g== X-Forwarded-Encrypted: i=1; AJvYcCUmV5qx0sgd7WAeZeGrkoEffeclfun4cm2Nr0s3YksrPymSEhLLq6vHeTqt9WweXF6dqt9AegxoBIA=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz+jTUx0A6hPzW941woshWBehluYdkThFJK2EB+garS2MfQzzfm OqzIGlTHjdUFyFr7NSjkenI8+OWLLNSzTqDvy+TlpgcBsshmG/6RuGbLlQswZKc+XiaXxEX8rFg Ro8k= X-Gm-Gg: AY/fxX6y35CgTGa0zRMWiXEL/bljXd44BKntysE1OQlQQmVf8QFnsG+ZNB3g5KR+h/E FcstpSnHNpodsV6/u61oEM+Rf0M6m+5NHJV5UhixjrRhe9R+tqz7fvg1rChrZMdH2ovt4eI9VV7 dZ51Z7uu+lUk5ueZaYCglwBpiYM0FexaQI4sUFICI7y0D4z5Bm9R9XZxIHNn48Eb6VIpbve7pM8 bSAJfwuUPsuvH9HEljPcWK8T3hKAM22mWg4XUzRgKV4Udygwpq2Jt+L29w9FWUjfg06vWWzdk3o +80pIN1kPst43TxdMDIB8hzhjq0BWjGafo/1hRK7ASx/qB1VzGRXysak+UHqEhDcL1mMmkqWCR3 Y6jZj8RJZl3EpU2Zmck34wOTUPdpliCkyKk1hirhlRKCKbTMk1vpSx+dEMWwL9ukavmY2dhWx4d bbHQZg8M7FAnVllUfRL6Z+pya+STKdsRL1FFgIa7iZfDeWnuDB/DYLc7z+6DxYaGdaC93ewj7fX Xo= X-Google-Smtp-Source: AGHT+IEJr6hXDvCpEsE99FObOMSKOczkJqcOtquEVpKhtfmXSLfCgqr7ukl7hsp8hGMEWSYHJ4iQVw== X-Received: by 2002:a05:600c:858e:b0:47a:81b7:9a20 with SMTP id 5b1f17b1804b1-47d1c62930dmr467911725e9.9.1767631710726; Mon, 05 Jan 2026 08:48:30 -0800 (PST) Message-ID: Date: Mon, 5 Jan 2026 17:48:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/4] x86/i387: Rework fpu_fxrstor() given a newer toolchain baseline To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel , Nicola Vetrini References: <20251230135427.188440-1-andrew.cooper3@citrix.com> <20251230135427.188440-4-andrew.cooper3@citrix.com> <662888ee-e983-4194-b8ca-f28560881c29@suse.com> <37ff7e30cc0715d619a20d7ea6ab72b5@bugseng.com> <31301264-0655-4cda-a66c-8768269e0c89@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: <31301264-0655-4cda-a66c-8768269e0c89@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 05.01.2026 17:39, Andrew Cooper wrote: > On 05/01/2026 4:13 pm, Nicola Vetrini wrote: >> On 2026-01-05 16:52, Jan Beulich wrote: >>> On 30.12.2025 14:54, Andrew Cooper wrote: >>>> Use asm goto rather than hiding a memset() in the fixup section.  >>>> With the >>>> compiler now able to see the write into fpu_ctxt (as opposed to the asm >>>> constraint erroneously stating it as input-only), it validly objects >>>> to the >>>> pointer being const. >>>> >>>> While FXRSTOR oughtn't to fault on an all-zeros input, avoid a risk >>>> of an >>>> infinite loop entirely by using a fixup scheme similar to xrstor(), and >>>> crashing the domain if we run out options. >>> >>> Question being - does ... >>> >>>> --- a/xen/arch/x86/i387.c >>>> +++ b/xen/arch/x86/i387.c >>>> @@ -38,7 +38,8 @@ static inline void fpu_xrstor(struct vcpu *v, >>>> uint64_t mask) >>>>  /* Restore x87 FPU, MMX, SSE and SSE2 state */ >>>>  static inline void fpu_fxrstor(struct vcpu *v) >>>>  { >>>> -    const fpusse_t *fpu_ctxt = &v->arch.xsave_area->fpu_sse; >>>> +    fpusse_t *fpu_ctxt = &v->arch.xsave_area->fpu_sse; >>>> +    unsigned int faults = 0; >>>> >>>>      /* >>>>       * Some CPUs don't save/restore FDP/FIP/FOP unless an exception >>>> @@ -59,49 +60,41 @@ static inline void fpu_fxrstor(struct vcpu *v) >>>>       * possibility, which may occur if the block was passed to us >>>> by control >>>>       * tools or through VCPUOP_initialise, by silently clearing the >>>> block. >>>>       */ >>>> + retry: >>>>      switch ( __builtin_expect(fpu_ctxt->x[FPU_WORD_SIZE_OFFSET], 8) ) >>>>      { >>>>      default: >>>> -        asm_inline volatile ( >>>> +        asm_inline volatile goto ( >>>>              "1: fxrstorq %0\n" >>>> -            ".section .fixup,\"ax\"   \n" >>>> -            "2: push %%"__OP"ax       \n" >>>> -            "   push %%"__OP"cx       \n" >>>> -            "   push %%"__OP"di       \n" >>>> -            "   lea  %0,%%"__OP"di    \n" >>>> -            "   mov  %1,%%ecx         \n" >>>> -            "   xor  %%eax,%%eax      \n" >>>> -            "   rep ; stosl           \n" >>>> -            "   pop  %%"__OP"di       \n" >>>> -            "   pop  %%"__OP"cx       \n" >>>> -            "   pop  %%"__OP"ax       \n" >>>> -            "   jmp  1b               \n" >>>> -            ".previous                \n" >>>> -            _ASM_EXTABLE(1b, 2b) >>>> -            : >>>> -            : "m" (*fpu_ctxt), "i" (sizeof(*fpu_ctxt) / 4) ); >>>> +            _ASM_EXTABLE(1b, %l[fault]) >>>> +            :: "m" (*fpu_ctxt) >>>> +            :: fault ); >>>>          break; >>>> + >>>>      case 4: case 2: >>>> -        asm_inline volatile ( >>>> -            "1: fxrstor %0         \n" >>>> -            ".section .fixup,\"ax\"\n" >>>> -            "2: push %%"__OP"ax    \n" >>>> -            "   push %%"__OP"cx    \n" >>>> -            "   push %%"__OP"di    \n" >>>> -            "   lea  %0,%%"__OP"di \n" >>>> -            "   mov  %1,%%ecx      \n" >>>> -            "   xor  %%eax,%%eax   \n" >>>> -            "   rep ; stosl        \n" >>>> -            "   pop  %%"__OP"di    \n" >>>> -            "   pop  %%"__OP"cx    \n" >>>> -            "   pop  %%"__OP"ax    \n" >>>> -            "   jmp  1b            \n" >>>> -            ".previous             \n" >>>> -            _ASM_EXTABLE(1b, 2b) >>>> -            : >>>> -            : "m" (*fpu_ctxt), "i" (sizeof(*fpu_ctxt) / 4) ); >>>> +        asm_inline volatile goto ( >>>> +            "1: fxrstor %0\n" >>>> +            _ASM_EXTABLE(1b, %l[fault]) >>>> +            :: "m" (*fpu_ctxt) >>>> +            :: fault ); >>>>          break; >>>>      } >>>> + >>>> +    return; >>>> + >>>> + fault: >>>> +    faults++; >>>> + >>>> +    switch ( faults ) >>>> +    { >>>> +    case 1: /* Stage 1: Reset all state. */ >>>> +        memset(fpu_ctxt, 0, sizeof(*fpu_ctxt)); >>>> +        goto retry; >>>> + >>>> +    default: /* Stage 2: Nothing else to do. */ >>>> +        domain_crash(v->domain, "Uncorrectable FXRSTOR fault\n"); >>>> +        return; >>> >>> ... this then count as unreachable and/or dead code in Misra's terms? >>> Nicola? >>> Sure, Eclair wouldn't be able to spot it, but that's no excuse imo. >> >> Right now, probably not, but even if it did, an ASSERT_UNREACHABLE can >> be added in the default branch to deal with that. > > It's fully reachable. > > FXRSTOR can fault multiple times, and can fault for reasons unrelated to > the contents of the buffer.  Fault recovery isn't even limited to only > #GP[0] only, and FXRSTOR can suffer #AC from a misaligned pointer. None of these faults are what we mean to recover from here. Faults unrelated to buffer contents would pretty likely occur on the memset() as well. As to #AC - in ring 3, but not in ring 0 (where Xen runs)? > If Xen is operating properly, it oughtn't to fault more than once, but > right now the logic will livelock rather than terminate. s/will/would/ as that's only hypothetical (assuming no other bugs). > Further fixes being discussed (better auditing of toolstack-provided > buffers) should cause it never to fault for buffer-contents reasons, at > which point I'll be removing the retry aspect and escalating to > domain_crash() unconditionally. Still in the meantime I think Nicola's suggestion should be taken and ASSERT_UNREACHABLE() be added. Then Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 05 16:55:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 16:55:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195663.1513586 (Exim 4.92) (envelope-from ) id 1vcnrM-0007pf-BH; Mon, 05 Jan 2026 16:55:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195663.1513586; Mon, 05 Jan 2026 16:55:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcnrM-0007pY-8B; Mon, 05 Jan 2026 16:55:12 +0000 Received: by outflank-mailman (input) for mailman id 1195663; Mon, 05 Jan 2026 16:55: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 1vcnrK-0007pQ-QH for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 16:55:10 +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 4a5c308d-ea57-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 17:55:09 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS0PR03MB8341.namprd03.prod.outlook.com (2603:10b6:8:28f::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Mon, 5 Jan 2026 16:55:06 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9478.004; Mon, 5 Jan 2026 16: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" X-Inumbo-ID: 4a5c308d-ea57-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=pDCIFjEzkxN+5E3WTM6RFbT0Z13xB2sYHdexMIYAKHtPKrSPpKPXaHkJapRKjsjLdlEiXM6bvdqBUtZ18qhNdMScfGqA2Vd2CHdavCvX2h28IoQeZ5oCKsFdIkd1d0zK0S5ho6uT8KddbKN6Drq6EsJ/nJPqjW44cwrUL/ylsnKaq5kZeDbO51Z7PJHhsm+6Aj9ASlXyeZ2zETjLwt8GtWZo7DJ+wz6ZoxzReUF5p2esQnqt2WIBAT/ZcozavVJ239QynVv7Wt8OzD67ru4B2JVIZTR7LP18LvyY330ZcdE4aI2JJiv5OIclkM6R5daF3tQkiLN239RgN0JIQLu7KQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/1U2VkXkLrnVS++cCGGmJu5RGKllksxQxfv4Jh4ZWvA=; b=ea0ZON/c/P3/d+5mYSFv5sauOPzA/2KFWRextaI5r2Wqvf8qXfvYnIrcYmpbk+GqPl3A/AuZe1MOH6JxrLhhLdUHaaLKbEOEW/2IK9jJA/Qy5QB/5ByhCGKs1f6iLWF3136lT+GVa6OccVewH1c16Llkln1jiULQ7TP9i8zDE6iZ6+LZxRYQEyzwavyDwne8k8HB8FuuyJ8QAdIPKMzkVLb0qL6HTgmxLntpIzyzfowTMzfq/YvM+ZYoYYFJxxKkrD3X0cJnTButdLxhgiSzE6eofKGmZODZJ3u3zeU/fx9gj8HCzq0+/BMo6MBYGYeLP2i0HHjwcF7NeFXWDSiycA== 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=/1U2VkXkLrnVS++cCGGmJu5RGKllksxQxfv4Jh4ZWvA=; b=aNaRJaQrqU6QP/tpfB44a4gA4XMvVDdg5vWKezHz60Kxztfp3BSlChERTRM3K4lxbZR5qLl1MQYFwbSOkSzrN2sSxaAA7IObM4Ibf19n9YGb8ykJCdi3IUJdKC9R4+NX0HZUKV+NCSmWQqTuJ3tIxxT+H/OvbZNKXrnVwPYB9cI= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <2a22afe1-7b85-4671-a534-00306b97ec21@citrix.com> Date: Mon, 5 Jan 2026 16:55:02 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel Subject: Re: [PATCH 2/4] x86/xstate: Rework XSAVE/XRSTOR given a newer toolchain baseline To: Jan Beulich References: <20251230135427.188440-1-andrew.cooper3@citrix.com> <20251230135427.188440-3-andrew.cooper3@citrix.com> <5b49e965-7e1a-4b04-baa9-c14e2de2e247@citrix.com> <7bd2372a-6687-47c5-94df-2366866f53ea@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <7bd2372a-6687-47c5-94df-2366866f53ea@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0091.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2bc::8) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS0PR03MB8341:EE_ X-MS-Office365-Filtering-Correlation-Id: 0eaf3194-b86f-4cc1-b902-08de4c7b2d33 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?em9qdlBMOG5naGJIN3cyeDMrTUFNN3gwODZ2Z1VQS2xSUDNrZEtZQ1liQnND?= =?utf-8?B?WFBBRUtldE5GbE1KUFFtWlVTUW45VDlCSE1EN3d6NTZJRGlNa3pSY0g5cHd6?= =?utf-8?B?d0h1Y3B0MXRnYWRxTnBFaDRVc3gyUUcrWFdqVTNBNEYxSk5NUDgxaVFreHY3?= =?utf-8?B?amFSS2xCT3N1NkMveHNhR09NQXBvKzRITk1Qc2FHWWRqdXA4aXlHZzRadDgx?= =?utf-8?B?TU9WZWxtOUZPaFlzL0RYUGY4WEc1dE4xN1FTbytuQ0d1WG1mY3VNaWxXMDE4?= =?utf-8?B?Y1hTdkMralFyVmY3eWtxR2dVeHkrdzZ4SW42VkgwVE9aOGdWQVRXU1l1dVRv?= =?utf-8?B?RkxJWUpLYXI1TFlEVTJ5dzBXRGtrSk8rVEFLZnRlc3Q1b09MSjh3Vk8zcjFr?= =?utf-8?B?Ulk2QVk3eDFHOGRFV3hIdUpDd0FIRTE5RW51b29WcHczamc4NkVOWldhQzlq?= =?utf-8?B?SDRNbUNGVFdSaXVJTHczaUZxbXNjRC9PZmgvKzJ2UUlJQkR0bVJIcFN2Z0FB?= =?utf-8?B?NXdRYk5qMmpGQnpncHBiQ1lwUGtxVE8rZTVkU3BydzhvZXhhNnh3QnQ4WkQw?= =?utf-8?B?T1JCMzFrTXZEQ3MzSEVJQWlsNitDT3FidTZDK3F6TXkvWWljZ1VsOWYrdmpt?= =?utf-8?B?OTV6MGlUdVhOeVNiQXQzWHEvQk84MnU0eTg5TlFLUys0SlArdksrbnZ5aVAr?= =?utf-8?B?WU05ZmpxelYxNXJ6MHJPajdlVk11N1JqaDJaMlpSRTBCY1ZrRVVrNlEvUDE2?= =?utf-8?B?bjhhM3NVRHExTDk3a0tVRXVsUWpKbEZXaVVtTzZNTzZRRDZaMTZmQmlKRDdW?= =?utf-8?B?Q2hnQ0FUT2p0WlIvemVWdGtQa0NZR09FS1o1L0xnSzVGcXMzdjA2SlRKcno0?= =?utf-8?B?Njd2KzdtUURaYlVsY3Fnai9ZZ0dvNHJ6dm1lUFd0cTYxZjRvbUhWcHlBNXQv?= =?utf-8?B?VnJ2eHNzOWJ1MVc2ZmlMb3lyMGtTbWpWaWd4Ukk3L0s0emhMUmlxajYwdlhn?= =?utf-8?B?ajJpNHFPYUtxeGpxTzZoZzJtd1FUK2ZZeGVld3kzMnBrRmhEdzRueTRYdGcv?= =?utf-8?B?Q0ZMaklzUlZzcmU2WDR1Q0VyRTlJUFBBSU40M1NvTFZlS0t2R04wUjk3cldT?= =?utf-8?B?ZW11M2I5RGl6NEJ3cndjWXB0dDlNOEhlTmlWYmEzamU2Y3lFUjJ0ajRCeW90?= =?utf-8?B?NGVVMkVYZUFucllhMzB3L092b3VIaDJiWnJPc1g3eXJnRVcybUJHN2hZRUFz?= =?utf-8?B?aVdrYlZnM3Y0S3pWcU9pcDBQaTJJckVkdWUveTFsd1dzWmRybVYvemlrSFdT?= =?utf-8?B?OXB5WnZsMTEwaXo5ZXJjOFp5QmpSbTdHdXRKR0lNNWg2Syszc0xRVk1wclBB?= =?utf-8?B?R3lUbGVRZ3NhdjloaHNqVWRjNnNnMzIyb1lWVi8wdDNkK2RSNHpkQ2ZSN2hl?= =?utf-8?B?N21MaHFCRjZkYlAyOW1UL1ZtRkRvajRqRWVzV2tEQWFSbHgxRTlZcXdrZDls?= =?utf-8?B?UVU5TFh2MnpBdEpBZ0M4K3VoekszdXFHNUNTK2VNWnVaQXhNTVRrc2pWSXF0?= =?utf-8?B?ZnZ0NEpqUXJhRmNiTnNWejhPNnlKcFI0b0RabDErS2VDZ0FZVWdPdXNNaWxy?= =?utf-8?B?WEdYNEFDYmp1THo2d1AyVTllWnJ6NDFQSW0vT0dUZkladklJUks0Qk5NVmtW?= =?utf-8?B?MWdwK2pYT3M5d2p1cVVXb2ZLdzVCbVd0bzMxYnIwNTBKSFU4TUNIbldUSkFM?= =?utf-8?B?RVVaVjYzZFowdklGSHNxSFY5Zy9JT0ZJR25QTmt0MUV6RnhPL0dPLzM5ZzFj?= =?utf-8?B?VmQwaFM2QmQ4ZndEbVVsM2Z3bmlTUEdjR0lXUWhjaU5EMU95UWVURVhiUUVn?= =?utf-8?B?WDNnQzhZYlV6M09mcWE3bnBBbmFzZmR4SHZqR1lsRldVcmxtVWJka2FvYXhO?= =?utf-8?Q?2a5ThqhhEJZsQnpR51vxq7mSP5AkcuxE?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MW5RaDkvaTBWSmlKemVpcnh2TU9ndUgrWEswMUdwVVgwc1Bybk9FY3VPb2VW?= =?utf-8?B?VEc2TDd0UURTcG1UUk5UNVNsRHJraDV4b0RwTkwzcTZmM1NjSDk3SllHSDdk?= =?utf-8?B?b2xCMXR2K1RIMTI5K0xnTW9yNDh6YWo1VzduUVBmQTlUeHdZdi9qUDhFNG9X?= =?utf-8?B?VExvSk9SWXN2TjhaaGNRd1NNM2U1V0lDenl4ZTBqTGtuNWFCQmd0VXdEdmhs?= =?utf-8?B?ZHFxUXhtTDBBdXVzTmsrbWc3VkdINVM5MlZxNlBJQVc1V3JjbDNoYUtaeW9T?= =?utf-8?B?TTJXalNBazB0NzRwZExoZ2VWdi8zR2lOWmpNSGR1QUYxNk9YRWN3dklTZk1M?= =?utf-8?B?M1drZ2d1NGZMNWhpdjhmZmxIU1Z1MU4wSEhBSEp1RkE3N2hURWhwUmI0aXFP?= =?utf-8?B?YVhoU01WRjlWblI1TzZxcUxLUm91UXQ4azFiTTM0N0FJOEVxcFRUekZPenBQ?= =?utf-8?B?UWU4TjhoazQvRXY3VVlLcjc2UE9QdVJRZFZnYzdtelZveEp1VFo2QXVtUkhO?= =?utf-8?B?VGZKamsrN00rVEkrcTJJc1pDRmYvY1U3SERkdlZ5UVR5TTQ4ZlRQSThlMGRI?= =?utf-8?B?VXFtZ3l5dHpuS0xEN00zaFI2L2lMQ1p1ZEpLSU4zcDlBWXdmWThJQ0ozR0s1?= =?utf-8?B?V1kydzJzK0VXSVpydGQ4M2Y0VGhNRmx3TmVQeG15YzBoUFAzcUxxMDZIUHV0?= =?utf-8?B?L3ZpZGpjNXB3YmgzL2xBd0dIakk3THJSYVgvRmdpazFWYlpub3FJWXJqNC93?= =?utf-8?B?WmN5OHErOEw3VE42Q3FWTzU5K3R5VXNPcDRtWkV2c3hMUzJoZ2R1dElWZTNU?= =?utf-8?B?WjM3L0t2MlhMY24rbHVhbmkzQVIwZXBZKy9zWWtCZDYzRkNqNm5La3pIRnpu?= =?utf-8?B?QmFmRmlSRVFLTUp2akVncURGaWk4T2gybDViTjUwd2h0K0RMdkpMalRhZXFw?= =?utf-8?B?aGhQdkptcVorS0hSWnpuYUFOV2pIMElDT1N3eHlIcVllVmo5MGR3Q01jd2Qx?= =?utf-8?B?bWZMZVk5YjVsWk0wUEtDOXg1NjRidWhqMVl6SThaMlMvUHdhM2MzdTVhNDJu?= =?utf-8?B?clhCbFN3eGRLalpMY3hjYm5vQmM0TUpZM0VsdXVGUDArTlVtbEVkeTdqVmI5?= =?utf-8?B?blc0TGo1WVNIaTZ2NUdzSHdCR3FtQk5mNG9mdXhCNEY3QmRXR2JTWVI3Vzk2?= =?utf-8?B?aVVOYkhtZUprZEVOMW9JMm1hdzFSV0V2L1U3ZWVKaDUvZExPRzRRN3I0dzdu?= =?utf-8?B?aU1ORUFkMlF4Y24zcmdxL29QQlRsVC8xRFlaTFdWMnpDczk0OTlCOXZvYjFl?= =?utf-8?B?M1R2V0JCcUlNak9MUEpNR2k5cjlFNVl5ZHBOVjBhdTFyWUxtaVdCaFI5MVdo?= =?utf-8?B?dytUWko3WmJBT0MvNDIrYzhLeW5LazlNZFF4VTVkUEpEWmlsS21odjVlV09w?= =?utf-8?B?RlR4UUFzb3RZS0UvKzVPMEtmaWxpaUEvMHlLeEI0UUoxV1RYL21PR3FneGJW?= =?utf-8?B?T2NqcGxQdmlVTnpLUnBvMnB3c2hPbml6LzQrV3ZlRHpISk5CZDc3bThSTzQ5?= =?utf-8?B?alUwRGFZVnpkNmY2OHB6ZEhGNVg2d2xSd2ZZVjVzb0wrUytuREZvVnlZTTRP?= =?utf-8?B?ekVXVlZZWWdSbnNENkwzL244RVlZazUyd2ZsTWtqSDRnWklaaUFQbFl2SU1V?= =?utf-8?B?UUZDN3lsTzFHelo0Ylh3d1RpSjcvQWVlSzhISS9qU0MvUWUxZ0VEamNIb2RR?= =?utf-8?B?bVJnR29kTmxEME1iTmFPSlJkSnJ5YVhiNFgwRlJvYXN2TXAxcllFQnFaVTFx?= =?utf-8?B?eFJuTEljelNwUzRCZnQ2M3MzemRUSk1OSEViOFEvekovTXd0YUdpbklrdFNS?= =?utf-8?B?VnNQY0Y0b3ZkcHdlZU5qTW9uUXR4cTd2SUFuaDlFOVR4TGUvenpXbzFHOFVD?= =?utf-8?B?V1ZQSU1DS0ZDOWI0NkRqMkJPZ0FQeUEzaERGdGFjNlJWMkh2dElEVGlqSDAw?= =?utf-8?B?YklSWTh3ZWRyUDE4M1pyNWszbk9MZ1dDcEQwUnBsUHpEOHhENGVGM29XTjc1?= =?utf-8?B?SWFWVW1NUGYzRmVNUUNlV3V3dDRFcDY5aTF5d0RXQ1lYUWpGT2JRNVFnMCsy?= =?utf-8?B?UisvTm5pYzNWUVhKNVY4MGlOa3VVQkkwcHVpTHdqSS9TWm5KbUd6NmhDQ0RQ?= =?utf-8?B?UllWRVB6ck00WlhBZG1adXBBK1JnVmtPVzRsUW9VMjFINWpxYmF1ZkZsQUVC?= =?utf-8?B?TzVja0RLcHd6bkJvaEMxL2dNSXlUS2tYaEtkNkNwRXNWamJBZ083eUhyM2Z0?= =?utf-8?B?UnUvbmwwaEJRVWhyVVY2anBhaDdFWnpMeWFWN2dCdmZkaklhOEJQQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0eaf3194-b86f-4cc1-b902-08de4c7b2d33 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2026 16:55:05.7744 (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: JvxoPGGEoyl4XXgm3z+WNjyydgYkjWnG0W01cz0sD646K2u6oSuLBiRHr++funZCTJrIFDeZ1RXJNBbZT4YeHRNe8b0Tz6jmidBUGhtbJEc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB8341 On 05/01/2026 3:16 pm, Jan Beulich wrote: > On 02.01.2026 17:01, Andrew Cooper wrote: >> On 30/12/2025 1:54 pm, Andrew Cooper wrote: >>> --- a/xen/arch/x86/xstate.c >>> +++ b/xen/arch/x86/xstate.c >>> @@ -310,21 +310,21 @@ void xsave(struct vcpu *v, uint64_t mask) >>> uint32_t hmask = mask >> 32; >>> uint32_t lmask = mask; >>> unsigned int fip_width = v->domain->arch.x87_fip_width; >>> -#define XSAVE(pfx) \ >>> - if ( v->arch.xcr0_accum & XSTATE_XSAVES_ONLY ) \ >>> - asm volatile ( ".byte " pfx "0x0f,0xc7,0x2f\n" /* xsaves */ \ >>> - : "=m" (*ptr) \ >>> - : "a" (lmask), "d" (hmask), "D" (ptr) ); \ >>> - else \ >>> - alternative_io(".byte " pfx "0x0f,0xae,0x27\n", /* xsave */ \ >>> - ".byte " pfx "0x0f,0xae,0x37\n", /* xsaveopt */ \ >>> - X86_FEATURE_XSAVEOPT, \ >>> - "=m" (*ptr), \ >>> - "a" (lmask), "d" (hmask), "D" (ptr)) >>> + >>> +#define XSAVE(pfx) \ >>> + if ( v->arch.xcr0_accum & XSTATE_XSAVES_ONLY ) \ >>> + asm volatile ( "xsaves %0" \ >>> + : "=m" (*ptr) \ >>> + : "a" (lmask), "d" (hmask) ); \ >>> + else \ >>> + alternative_io("xsave %0", \ >>> + "xsaveopt %0", X86_FEATURE_XSAVEOPT, \ >>> + "=m" (*ptr), \ >>> + "a" (lmask), "d" (hmask)) >> This loses the pfx.  I've fixed up locally and double checked the >> disassembly. > Question being: Do we want to stick to using the prefix form, when gas > specifically has been offering a kind-of-suffix form instead from the > very beginning (xsaves and xsaves64)? > > If we wanted to stick to the prefixes, I'd favor a form where the use > sites don't need to supply the separating blank (i.e. the macro itself > would insert it, as doing do with an empty prefix results in merely > an indentation "issue" in the generated assembly). Thoughts? I don't expect this macro to survive the fixes to use the compressed format.  From that point of view, "closest to the original" is least churn. One problem with using a suffix form is that you could feed in "opt" instead of "64" and break things in rather more subtle ways. I'll adjust the position of the space, but I think this can keep on using prefixes in the short term. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jan 05 16:58:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 16:58:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195673.1513597 (Exim 4.92) (envelope-from ) id 1vcnum-0000RS-Q2; Mon, 05 Jan 2026 16:58:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195673.1513597; Mon, 05 Jan 2026 16: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 1vcnum-0000RL-Mm; Mon, 05 Jan 2026 16:58:44 +0000 Received: by outflank-mailman (input) for mailman id 1195673; Mon, 05 Jan 2026 16: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 1vcnul-0000RF-BH for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 16:58:43 +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 c47f6c20-ea57-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 17:58:33 +0100 (CET) Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-432777da980so54698f8f.0 for ; Mon, 05 Jan 2026 08:58:33 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bca2fabcsm530355f8f.16.2026.01.05.08.58.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 08:58:32 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c47f6c20-ea57-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767632312; x=1768237112; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=03e/fx0aBaqngeNND1sOQn6a5hcabBfkxB+SMXmaLcU=; b=VZR/HMrNmO8F7IF3bNLTVfhKEXTRpHwtqd6H36jS/AGt5XbMnHUdu8OYXX6coxus5O UlOVbvIKZNpFdRQtcGGCTlx1aCXsQJJS/oQV8hu/H2u8d2QMbcgE+oU3JUovbnZNONFq woTMdb5+DCskYADyoR+vc7Q1P0x4M1ocaTQ9t/PEnrdlomnmWSXuU59UgDNaAAOdN9pU kxzNpXBgVYh6tLE7MMKBReEXBXWCWqVhy+6HVnTBPMThbvrn+v9xlfY7jEh4Mmdmc7Lt C5y0DmR081i4kVCcdiMyZWEzFHPF45pQMNDlBI2qYXkWQxzgoZDPQYlBKofiHcEAZITL ZFOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767632312; x=1768237112; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=03e/fx0aBaqngeNND1sOQn6a5hcabBfkxB+SMXmaLcU=; b=Cfs5TG7qsbzK8tiDaRn7ZtROuiCpFEzHcGpSjik4H//k/Ignk0VZt9d+A4YNiTinFT kEss6UEnYM1WzPFbH+BpV/fpS1KJz/yttmnq1EqIy/72VbP/7ZRZ679NzJRc2zCN04z6 doLZ5GSrftr5G8lK6Ql3XmdkND05/QlerNt4VXMuk0Dtpbv6LTsQFwcWiQ8eiOgHhOjn JA9qEAJZIWYQjppI9rnbcbC0nSdFTaIGb3eLDoyWEFxQ2RsCto1cBlxOLkc5PSu+zgV6 I7pIh7EsX5OKNLKS4n5N4qkmQz6Y68xAlXSKsNGlnPF+OZIUdeIzdwPgW3Pd9qHJznQ8 IKRQ== X-Forwarded-Encrypted: i=1; AJvYcCW/xXRZF2mqKiDlDtaG7SgoCnf6/Fz5akDjkjd+o6uPvRGoNbQigmVrr4RqaL1T1bh/8d98tzESuc8=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw3gWLqK/62owdoNe0dAjsu703qyrKb+kXsht7snuYb+JcZmHdV N0hknPd2H0Zaf7SYsLu6O6XggZoARH16j4UFg2hJqmnXsTaz2ZgNpLNfO3Gg7luPiw== X-Gm-Gg: AY/fxX4Xaz7wyZ10axY/wGBrEGPUYBsEmWJLwTm5MJxcprNL8vOf57rEa/076GHXL00 sxYfqQt4wnE196Nt4XBi67KrID9REF25Bdym2yFCf4/JAZHas9kREUfT513JPpcWlEEr+fjE5hy 7QbvZTJOfcuti/cXHvJq2YVqk/RtLjIAs2xLNu6k6TQ5kVT5vRlYMKkTM32y1aeSPNH21kknC5o cqnMJOW/YZgqgiqjZcq7aFwau0eERqxPF1K6MJxm/5xpNsBs7PG5aKFlFimeTseByAZfQGADTJY A8GV7ExEtu84e7snbNdML11TZpqSKNCB/cO1ighEsZz0qWreA2K94EjZdY7qwpowqjrZ42TPP3W PmdpJe5UvtvWDmq85idW9uEmDvBgGcndrKRRyXPjwbxb0kEB6J6E76976byc/aaW4YWglTk3Jht VGHivUqoFYUMN7Z6szMgzsxvDbR17n/kWo84Jvjb6aNyrUUi7qU4fjxJDKrpFeCx8NbUi4mx+Wd /E= X-Google-Smtp-Source: AGHT+IEwsGnLHRjMTO+GfgSpgn8WUBCF7iEDmCKcSj3XQBUgu3Yf88JkN5+v9yjNnZoKSuMDcaoxjg== X-Received: by 2002:a05:6000:1843:b0:42b:3dfb:644c with SMTP id ffacd0b85a97d-432bca18dfdmr541289f8f.10.1767632312348; Mon, 05 Jan 2026 08:58:32 -0800 (PST) Message-ID: <41b7b388-6c10-4cbe-a4af-a25baba64e2a@suse.com> Date: Mon, 5 Jan 2026 17:58:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 01/15] xen/riscv: introduce struct arch_vcpu 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: <3b531dff3755da010664111cf7d936ccba7c1f5d.1766595589.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: <3b531dff3755da010664111cf7d936ccba7c1f5d.1766595589.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 24.12.2025 18:03, Oleksii Kurochko wrote: > Introduce structure with VCPU's registers which describes its state. > > Signed-off-by: Oleksii Kurochko Since none of this is being used for the time being, I think the description wants to be a little less terse. Coming from the x86 (rather then the Arm) side, I find the arrangements irritating. And even when comparing to Arm, ... > --- a/xen/arch/riscv/include/asm/domain.h > +++ b/xen/arch/riscv/include/asm/domain.h > @@ -22,9 +22,63 @@ struct hvm_domain > struct arch_vcpu_io { > }; > > -struct arch_vcpu { > +struct arch_vcpu > +{ > struct vcpu_vmid vmid; > -}; > + > + /* Xen's state: Callee-saved registers and tp, gp, ra */ ... I don't think the following structure describes "Xen's state". On Arm it's guest controlled register values which are being saved afaict. I would then expect the same to become the case for RISC-V. > + struct > + { > + register_t s0; > + register_t s1; > + register_t s2; > + register_t s3; > + register_t s4; > + register_t s5; > + register_t s6; > + register_t s7; > + register_t s8; > + register_t s9; > + register_t s10; > + register_t s11; > + > + register_t sp; > + register_t gp; > + > + /* ra is used to jump to guest when creating new vcpu */ > + register_t ra; > + } xen_saved_context; The xen_ prefix here also doesn't exist in Arm code. Nor is there a similar, partly potentially misleading comment on "pc" there comparable to the one that you added for "ra". ("Potentially misleading" because what is being described is, aiui, not the only and not even the main purpose of the field.) > + /* CSRs */ > + register_t hstatus; > + register_t hedeleg; > + register_t hideleg; > + register_t hvip; > + register_t hip; > + register_t hie; > + register_t hgeie; > + register_t henvcfg; > + register_t hcounteren; > + register_t htimedelta; > + register_t htval; > + register_t htinst; > + register_t hstateen0; > +#ifdef CONFIG_RISCV_32 > + register_t henvcfgh; > + register_t htimedeltah; > +#endif > + > + /* VCSRs */ > + register_t vsstatus; > + register_t vsip; > + register_t vsie; > + register_t vstvec; > + register_t vsscratch; > + register_t vscause; > + register_t vstval; > + register_t vsatp; > + register_t vsepc; > +} __cacheline_aligned; Why this attribute? Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 05 17:06:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 17:06:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195687.1513608 (Exim 4.92) (envelope-from ) id 1vco2P-000281-OG; Mon, 05 Jan 2026 17:06:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195687.1513608; Mon, 05 Jan 2026 17:06:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vco2P-00027u-KM; Mon, 05 Jan 2026 17:06:37 +0000 Received: by outflank-mailman (input) for mailman id 1195687; Mon, 05 Jan 2026 17:06: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 1vco2O-00027o-I2 for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 17:06:36 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e34e8e68-ea58-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 18:06:34 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-477632d9326so912105e9.1 for ; Mon, 05 Jan 2026 09:06:34 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7ee5bc57sm3511595e9.11.2026.01.05.09.06.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 09:06:33 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e34e8e68-ea58-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767632793; x=1768237593; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=6w8+OXGrdIqZSTdZ3i5+/35ScU4yn1oGqDHkJQmcbMk=; b=PqrHVKYpdO2GnXHqtGHFx7L3n+Eyw58T6s9RoOnmz8owBZI6tXeeW3jsZojM9lWKtH ZlmtfdJJAP4Kong1fiDLMpP4g0cEqFSBO+vB7SYYa3r0KRMAbTz/hrR4YQbBFloLYbbc 6WweN9h6pI6s8PqLzwHTzMd2/owCy3JuiZoXLoWUXsFfFJFHncBnTKdqOCLbIuE2DwsF KNoQxzEVY2cabJU2LldSaz1rfId42ocZBTu09FXOGkQ4+1fe4HyzlilHUv6+7+6pze1J ghnO7giFPj1awQz3UOMyK2F6ixcCWotBq2BNeFtCNDD9ye3xfkLcDUFqOr1b4UkpXjdE JBSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767632793; x=1768237593; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6w8+OXGrdIqZSTdZ3i5+/35ScU4yn1oGqDHkJQmcbMk=; b=jDGuzUiIIooFWtwlDnByOVfNGe5D1yHh8mOyKc0rpQejrhFpoKRrmE8xof2FURkcvS Z43dVOLNFL0Q9RNK4ZUPYj0mPnJKnNmJrCH6cG+LU4fOuIQ2ki4Q4XKanek649Njz59O 8jfj1F/oB+jtxlJkeJRjwRaDyXIM2dlpwyXS+qq+WDzwLl6lsDgZcFz9XwV5ZEBSeWiE b/Jbj0IEk3z0MDLHbZ6jJrSi4Aj4qERegGs0kxKvJPtZeWju6wRgAz5b4CQln6lMJ0K8 u+RDQTLjLfxgCFkBDvv4g7XKx5DmOnGKyZs4Klkr/cIY30pU8ll/pBKeW9pSavWyTr7W TiQQ== X-Forwarded-Encrypted: i=1; AJvYcCUKjr+Q2ZNS5aOLCPFnf6HBeaZI1Bts2IXz/17WH2KCt2PC83YBZ2f3z6JfF1SR6XpS2q8taHOAyEs=@lists.xenproject.org X-Gm-Message-State: AOJu0YzHY2gogN3kq5yW83BA7awlwEhnf6FMyYf7K84fU3WEbAyxrr0p tBK+EL+j1lFTmP54vY4BwcFRmlpe2Wg91X9s9i047uBbHIqPId6SRok3U1H1tYmL+A== X-Gm-Gg: AY/fxX5YuJnlJn/6EBsHYkP5N/a1jvDu8G01rtaVOA1LZJQVPFZd435Av04frOHZb2U 7thqbdttaFjQdfGsYNJMf7O5t6Gw9VfcrkCoS6EeaDMPFGDlPl2opuLc5GQ/sXcyc3bWZZgLxd5 glHk4BaGv5xP0athKlZyD0ycw52khunxuNrXL2j/CI4KjQMP236SgW7L5Td10UqNaBkL0LEGoHf niSXZDy2LvOfiaYoGO0J+YJbFzI9Liak6zD9DOVhkTK6TQK/8s5NTff8N6O1vofqarTlO5j2cPx Av1pHFWvsGYXN6u8b+yLmdaIp2BR9uRxCDOKNWx1/Y+4UVk5RN1rBAr/oZ7C2isBztpAtKWKU+7 dceiKXAx6VRTaqwfjkipwyH2TgQZRwCbCM3EL2Ds24PKKyC5seCl+yzHmo/RZ/GdOjlC0y56Tdh r4eXMGFBLtEq3107SXPjSZPLH1c+rPiQvWBoiwXc6rfscRUiW+7kr7JYhKK4Bxi4khZ0W+OcllL Go= X-Google-Smtp-Source: AGHT+IEPPcwO0JpH30zpEMZ3VzKx2THUDTdo20mc49baiG96elxUOAZjnYVT3TzTyM6tyIg/PVWatA== X-Received: by 2002:a05:600c:1d1d:b0:46e:35a0:3587 with SMTP id 5b1f17b1804b1-47d7f09da9emr38325e9.27.1767632793398; Mon, 05 Jan 2026 09:06:33 -0800 (PST) Message-ID: <1c13180b-29f5-4e7f-a05b-baac70737cc6@suse.com> Date: Mon, 5 Jan 2026 18:06:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/4] x86/xstate: Rework XSAVE/XRSTOR given a newer toolchain baseline To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20251230135427.188440-1-andrew.cooper3@citrix.com> <20251230135427.188440-3-andrew.cooper3@citrix.com> <5b49e965-7e1a-4b04-baa9-c14e2de2e247@citrix.com> <7bd2372a-6687-47c5-94df-2366866f53ea@suse.com> <2a22afe1-7b85-4671-a534-00306b97ec21@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: <2a22afe1-7b85-4671-a534-00306b97ec21@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 05.01.2026 17:55, Andrew Cooper wrote: > On 05/01/2026 3:16 pm, Jan Beulich wrote: >> On 02.01.2026 17:01, Andrew Cooper wrote: >>> On 30/12/2025 1:54 pm, Andrew Cooper wrote: >>>> --- a/xen/arch/x86/xstate.c >>>> +++ b/xen/arch/x86/xstate.c >>>> @@ -310,21 +310,21 @@ void xsave(struct vcpu *v, uint64_t mask) >>>> uint32_t hmask = mask >> 32; >>>> uint32_t lmask = mask; >>>> unsigned int fip_width = v->domain->arch.x87_fip_width; >>>> -#define XSAVE(pfx) \ >>>> - if ( v->arch.xcr0_accum & XSTATE_XSAVES_ONLY ) \ >>>> - asm volatile ( ".byte " pfx "0x0f,0xc7,0x2f\n" /* xsaves */ \ >>>> - : "=m" (*ptr) \ >>>> - : "a" (lmask), "d" (hmask), "D" (ptr) ); \ >>>> - else \ >>>> - alternative_io(".byte " pfx "0x0f,0xae,0x27\n", /* xsave */ \ >>>> - ".byte " pfx "0x0f,0xae,0x37\n", /* xsaveopt */ \ >>>> - X86_FEATURE_XSAVEOPT, \ >>>> - "=m" (*ptr), \ >>>> - "a" (lmask), "d" (hmask), "D" (ptr)) >>>> + >>>> +#define XSAVE(pfx) \ >>>> + if ( v->arch.xcr0_accum & XSTATE_XSAVES_ONLY ) \ >>>> + asm volatile ( "xsaves %0" \ >>>> + : "=m" (*ptr) \ >>>> + : "a" (lmask), "d" (hmask) ); \ >>>> + else \ >>>> + alternative_io("xsave %0", \ >>>> + "xsaveopt %0", X86_FEATURE_XSAVEOPT, \ >>>> + "=m" (*ptr), \ >>>> + "a" (lmask), "d" (hmask)) >>> This loses the pfx.  I've fixed up locally and double checked the >>> disassembly. >> Question being: Do we want to stick to using the prefix form, when gas >> specifically has been offering a kind-of-suffix form instead from the >> very beginning (xsaves and xsaves64)? >> >> If we wanted to stick to the prefixes, I'd favor a form where the use >> sites don't need to supply the separating blank (i.e. the macro itself >> would insert it, as doing do with an empty prefix results in merely >> an indentation "issue" in the generated assembly). Thoughts? > > I don't expect this macro to survive the fixes to use the compressed > format.  From that point of view, "closest to the original" is least churn. > > One problem with using a suffix form is that you could feed in "opt" > instead of "64" and break things in rather more subtle ways. Except that there's no XSAVESOPT nor XSAVEOPTOPT. > I'll adjust the position of the space, but I think this can keep on > using prefixes in the short term. Okay, I wanted the alternative to at least be considered. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 05 17:46:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 17:46:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195697.1513617 (Exim 4.92) (envelope-from ) id 1vcoeQ-00005o-Ht; Mon, 05 Jan 2026 17:45:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195697.1513617; Mon, 05 Jan 2026 17:45:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcoeQ-00005g-FN; Mon, 05 Jan 2026 17:45:54 +0000 Received: by outflank-mailman (input) for mailman id 1195697; Mon, 05 Jan 2026 17:45: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 1vcoeP-00005a-Aw for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 17:45:53 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 602629aa-ea5e-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 18:45:51 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CO1PR03MB5844.namprd03.prod.outlook.com (2603:10b6:303:9c::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Mon, 5 Jan 2026 17:45:49 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9478.004; Mon, 5 Jan 2026 17: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: 602629aa-ea5e-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=s6FvwfDoU6vR1xcGUoitD4IagM1c56hPyDvf3jyxUOVDT/+SuewNkVmr0qWUC4imIKpoPCF09IaLeTYSix0a+RdWb+keBHFOkKPoqF+iCFq2SyXxRVK1Y34j5kP+wt1gi3WHa6k1XMoL1Vsud+OT32TKBlv+LgJy3PrVFiM9wuWR17UjYpBs5TD1wUK6fg9bnPm9A29mlUmLolG1juLDpoNpfj37QCEAiCFUum0YvpYEO+2kFITbZKTamuIjcKagppkexRHPEWohvXYf7Wf/aiSgqPArdUdJ6dzCmwXZUA6HTBbauwIatv0+SRdIR/L2xdr66hZ5sObi1gkKugO3rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LRHMEVjAlxGKe8YdkGQSjyT4a7TtDFmNvYQTsDv1AKo=; b=t4ONbqDwMQusWtWL1UKbXlduJLHCfKKVSowGhnY+HofhQl7uey/WlHr+9aWUF5+MqQRJYjTJAVB2XWjpZrf4k0e3dZo897DA2gRCqE9UJWPfW20FSPdhdBv+jPkFTmj4iYqJW0HQx2Wg7Sq63iKVirjPW6WiE2PtVjGOgha2HG3VBjA68ZlzjbGGG25GUqt4Yx2IwwATuxUAg55raMN3fr0VC73MUA2p2d9Bfp9HOyMLWBOHsEJ/zhLx/tRJIRLOdsiv/z2leqSW/Md7e3nKIGgNOrPUIdc7W8HWHk+fLT/N8bIhJJy9CACw5qyM3iBYsD8n0VTPCz76k5oS/rhleg== 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=LRHMEVjAlxGKe8YdkGQSjyT4a7TtDFmNvYQTsDv1AKo=; b=Y/Wo6pBzToCuGf+ccGnnaP/rqZOPz4IFNL25jwfLQB+6w3pRM9UiXwbHS1s3OynwfTt3jmP71fOgW/+yJfn2VkTvi2FzHT9zZ+BbiC3u3KvbrWL/JdJPX1eUJ0Ycq6dCOIZmigQDTDIcJfkPfPh6Vmul6J4UJ21baEU9yxAoTto= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Mon, 5 Jan 2026 17:45:46 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel Subject: Re: [PATCH 2/4] x86/xstate: Rework XSAVE/XRSTOR given a newer toolchain baseline To: Jan Beulich References: <20251230135427.188440-1-andrew.cooper3@citrix.com> <20251230135427.188440-3-andrew.cooper3@citrix.com> <4b051e1f-0d99-4637-b433-bade93e67e0a@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <4b051e1f-0d99-4637-b433-bade93e67e0a@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0222.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:b::18) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CO1PR03MB5844:EE_ X-MS-Office365-Filtering-Correlation-Id: 6c7f8ada-6f68-42be-21e7-08de4c824330 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?bDB4bVd4bTIwV2xVV3RUZmVyVVNTWlE2V1prUjV2QzVsa1VWNmdoNnMwcnpP?= =?utf-8?B?UXkzdThhallQQk42Y0xNbVRURUlXVFhZOHBCc0pBSEZHeTduc0dwUWsyQjNP?= =?utf-8?B?cVRyVkNmalF5aTlvcGN3NDdGTXJHdHR0UzRpMElNNUhLd3FMMjZGZERZczFM?= =?utf-8?B?NjN1WTBhS0s5NDIxVDdBd1JNL1I4VWdTZnVNS2FLRkZ5VDltRTNuTlV4UmNE?= =?utf-8?B?WTlQT1ZEYit5anpWdko5Q1UyUTF1ejFXN3M0VUJNQ2d1R3M4RnBFckxUcWcv?= =?utf-8?B?YUE2NDF5eTcyUFNIQmI1bGJBOXhmM0IxTk9ONFEvcG9BMkdZUnpkMVBtdUxQ?= =?utf-8?B?ZWkxN2V3TWxFY1dHc0JTV092eno0QnBxTHdBMWJNOEZ2Rm0rc01UZy9nNFFW?= =?utf-8?B?bFMwTTVlMkdYOUxMSkF2UXNiSk9NTUs3bnVoSVpTUkdlajQxT0srOWk2aC9M?= =?utf-8?B?R0cwK1MrbklWVzRNb01UNHRHYjNGaW82TGRLTGIyT0w3VFU3VnZPUkt3V0Jo?= =?utf-8?B?MGl4QjZIdGxpb0tGQ2NhZThYNnhiWndxc2xWb01LNHBTYnd2SUFyR0laKys1?= =?utf-8?B?dk1HTjJ4SzVzcXo1bGpkUGMvRUptNW5SK3pFQTJYWFg1MithU1duWXZCZjQ3?= =?utf-8?B?YzZPQm5Gc05CTGU4ck03dEU0MERGa0lpTG9sZ0FoMHNRb2s4MDdBSnlvcGYz?= =?utf-8?B?cnZiNnBBOVBFbEpIQjZwWDRWVmpESlE5VmpEeE1TT0Z4OE5KYU5VSzN2SGpQ?= =?utf-8?B?cFQ5WFlsYmFBWHp1dXd4UC8yenJOSGFvQ1NLTlhMWnIzNU44VVM0WkJKblZD?= =?utf-8?B?dDF2L0lZVHdDeWtMTHRoOHBDa2c5MU96U09VdXVzbmg1SndFNFRQZHlSNkt1?= =?utf-8?B?OWYyRjRqblp3SndRb3RaZmE4dENCWk13aXJjSXBBU1ZEeHl4L3M2d0JCL0Rp?= =?utf-8?B?WmxYdG9nNEQwcWx1dDlJRk13WURXRUhjcWV1cDVmUDlNZkpoRjNWVUI5ZkFR?= =?utf-8?B?cDVLLzcwOXFwdU9rendFNVVKSUJIZDBRbUhKaXZ4bzk4MmxsU0hlcVNKRkV5?= =?utf-8?B?ajlKRHNTMUo3bERRQlRhaWdhcnNpQWRWS2EzN3N3WmxNcEFEd3A3Tllqak5u?= =?utf-8?B?M2FiVllidDJoUU40cmFZMTR1R3JkVXdwem1ycllSelk1N21TRGpNK3U4M1cr?= =?utf-8?B?NEtLOEJ0SXhUcXpJUnpXcmxDRzVDOHZ3S3ZzQ3p4L3FHQlVXY0I0ZWJCR25M?= =?utf-8?B?UStGdlgrZnZCb2FkZ2JHaTJpeTlHWmVxQzFQZElwbUdQeS82dkxKc1g5WUFr?= =?utf-8?B?SERlRS9uVmNseGRFWjhEM08rZ1BCeklJSEE0dXRiRDkxTVVnczJxcEFEUCtk?= =?utf-8?B?OWtUWjJpV3BsNWpSSjM0VC9oVjBuQThndHE1bzFUY1h5RXZwcjNFUnFBcmln?= =?utf-8?B?U3dRUElXM3JJb3NLMGV4QzNKSWdPQ3FYaGMzQklVS2RJSzVXSllMcjkrcnBs?= =?utf-8?B?bitXN25nUTZQeERxenZsOFlBWHJvSVY4TnFzMERYVGNwb0x2OEZVWWp1Qmdx?= =?utf-8?B?OSt4UUsvcWIrQUFEbHhqclJ4dXA0aEs0T3JJZ0V3dksyZHpwUXR2YTI1a2dy?= =?utf-8?B?elJUczV2Q2pNaU5Bd1lLWHRETmQrUTJ3aW9LTE1zRE14ZjE3TTg3VFQ0Z1pP?= =?utf-8?B?bHdKN3EyajFPWUx6aTVhMmVUVThzVnd1SG1PTVZPSndSZURzMzFScWtzQnAx?= =?utf-8?B?VWpqOUpuK3VHWVNiRUkwTE5rOThvYXN0cHhsQWt2WFFnTmMwTytVRndhRG9r?= =?utf-8?B?aE9mUUxsaENyMEpNUlpmeGY2R1dNcHRlUmljRGZ0VUcrWmc0bzF2V3U2Z0Ju?= =?utf-8?B?SjdEcm1Sd3Rwb01UaUlCYTVrQU4yc2ZvTXVGQk5EdVh4aEFOWFVabG81TUpB?= =?utf-8?Q?2WSmF5a0Ht8nJrIjAknvc3dLuUuuT0bC?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dW1jQUd1bkIxTzNPbStacWhNQmFuRWZrTm5yNTZLT1R1bnFYWkR2YUFlZGhN?= =?utf-8?B?Qzd0M0JmUmFtTFMwdUhocExJOGJPdEFzd0p0QTlnLzlKaTF0U3IwNkF4c0wv?= =?utf-8?B?eCtoeUJYckZxRmdRUU5wMmRZL1JjT3lFZEFrUTlZd2RGdktaZk5rQWJhTU5x?= =?utf-8?B?MGhXcWJhL0JqY1UycVBNbjRCWVpuL1FXeTY4eHNCZU9tS0Y4NDg4K3hka0xJ?= =?utf-8?B?a2Z6R2pKTG9WSUg0WVg5VU03UVk5OTRJQ0luWXpUREFtNnZ4WkN5NGJYZTVO?= =?utf-8?B?c1loQlRPWkpadlBNOGhiWHd0RUpYNGdyaE93bG0xSXhWWGQxL1lkR0RXKzlW?= =?utf-8?B?T1NudlYrUnh5cE41WlBlUE5FakdTNEIvV3VDQ2VBU1VZMHVLWDlTN1ZONEFE?= =?utf-8?B?c2hCdkY4ejE1Z1pCeEdLYnpZYm9pazhUaTQrOTd1WktUT1h1K0xzRTExRzBD?= =?utf-8?B?YmZ1RVltT2Jpd1JLZ1RwdjUyQnJXTXhnT3hwMWNOa2t4SE9jQVhEbjRHOEdM?= =?utf-8?B?NkdEU29hc3BCOVRaOFNEZXpLb1Vxblo4bkVaWHpFeFY3SVpabTFhQVNXUkZt?= =?utf-8?B?VlJnS2pVZUYzVmhyYVFzZVZrNElVNG1WZnlIRlRBZ3BTZ2lEbVU2a3NJclNo?= =?utf-8?B?K3UwcTZYNUJWejJnN1U0Vk5jYkUzMTFwVE8yUlo2dGo5SktYcGVLdjVqVHk0?= =?utf-8?B?ay80aVVkdVllNG5CYWtoQW5OdEJSWXVYZ200SldOcDROK1RBUUxzYkpZcEpa?= =?utf-8?B?RjlGRjBrWHBmemdPYTA4eE5RK2pkV3BqYVREa2JBS0wvY0FQMk1INTVRT2tV?= =?utf-8?B?dWJiQ0NEZjFYbDgrTGdRY0VITnZwWlhMdWpzNXpNTmJValBwSU5WQUhHUXZI?= =?utf-8?B?NTBrTEs4MjFTNGxNazd1Mzh1OXZUM3E3T0lOYmcyM0ZLNitwbktFWVJEY1d2?= =?utf-8?B?OVZDSjY4SkdlNks4WjVjNjZ5ZjRFblpaRkFVT0pPc1FGeVRjL3cxMk5WMUZj?= =?utf-8?B?WGgxMDlIUU1RQXlJYXo0M09nZU1TVlJjZnFlblFVMGl3RnIvakRrU2VTM0t1?= =?utf-8?B?NWllRDJZWFdtdHdkUm9acW5yVkpMZjNndUV6UCtOWDdOeUdZNmZzM3hFT05p?= =?utf-8?B?VXR3VGk3eVA0RTFvSTR5bjVjMmVIdk85VTNBNkM5K1hrUDhOQ0c4YVQ2bzFw?= =?utf-8?B?d0I2L20zNDJlMzNMNFNJVnU4Qk1UOFlMS00zQTdneURtci9FNWJxSlNuRFhk?= =?utf-8?B?QjZ0Z1NxeXZEUHdLMTkva2hVc2lXVmVheHovT0drMkV2dmd0OGcvbEo4T1I2?= =?utf-8?B?TUZqYzZqdE4waWNwSU1uTS9WYWhYRHFabkFvZ1lDTktxUnFBK1NEekk2T1Mv?= =?utf-8?B?dmVNL01MOVBXNGZTQjNPMjUwUExTOERGQWg5akZIODdVUGhFUTVYVENYVk8y?= =?utf-8?B?SXRlS2xjakhMYmdpMm1RUGx6cEtCcmQrQmpOZ0p5Nm9Cb1h1TVRnMGpoL0NO?= =?utf-8?B?Q1RQNkVNOUlONEg1TFA0eVJ1UEJ6V01DajErcHZZNFl3VW9LSDNKUmVkQUdR?= =?utf-8?B?N2t5V0N1TVBsVTBRM2cvYVFET0YyNzdOckhNdU5tc1dhRVhtMy90c0llREpp?= =?utf-8?B?U0tnRGlldC8vZTBLeTMrSENub0ljTzMvV1hOOWFrNUdYaHU4SXA3cEo4MTRL?= =?utf-8?B?T05vb1NqQUhvb1RsdDRibS9oNmJFQXU4N25FZE9KeW5MenFPWS90akFhTzFn?= =?utf-8?B?MGZ0K2p0ZmtJSzJZT3g4TGR3V3lneWlOdkgvKytxa04vV0poaXhwUmp4T1pO?= =?utf-8?B?Y3p0ZmV0REtKRThLZTgwSUM2T09YWUo1bVdRRUc4K0tLbzdwSjZaZTExK3BR?= =?utf-8?B?bEI3Zjg0S0duM0NYMFl5NW5JTm1JZFBSZkVSQlg5UFZnbU5BUjdyeTYvVDl5?= =?utf-8?B?bEtnU2pNdmJLUW5ZdnFocnlyYjE0RGxMMjVPaitUYjZxY01HcCtDeFR4dCto?= =?utf-8?B?SklpU3VnZHRVMnFFTWVLa3diOVBEelhGU3NhM1dWWlBmVnFkRkRDdmJaeHpq?= =?utf-8?B?a0dvSmhJOERhUHBtTlZMNm5zdWI2bVRkWmlNQVRXb2lUcVBNK244Szl0bk5T?= =?utf-8?B?RjRJVllBUkVTQkMycnAwazJpUjkvOXlvektIUnN5U1dqM0l0cnhsRVBTWXdR?= =?utf-8?B?WWViNU1JdDlhSFl4SlBOLzhTdEtJRXZ4VDl6S0p0SWFwZE1pc01YWHJPNGJi?= =?utf-8?B?Z25LUW8xVXEvYVJyTER5VUFqeUZ5c2RBMFIydXVKS21FeDMvbnNtRkNzNjdt?= =?utf-8?B?ZW9jVS9BSitXVDRUeUw0cnU1K3MzM0JRTzI4SjBVZzBkMHZuNmJpZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6c7f8ada-6f68-42be-21e7-08de4c824330 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2026 17:45:49.0545 (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: SkwbYi6iWE2edbbLs2ezvJGHtq9N+qRXLOGdJhl8jI8IC/sMQYG4GNvVmBnJSS6nd6WqCT0gO3vcS5mdS7J3Ils92z4aXQePbRKdSOljv0M= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB5844 On 05/01/2026 3:46 pm, Jan Beulich wrote: > On 30.12.2025 14:54, Andrew Cooper wrote: >> --- a/xen/arch/x86/xstate.c >> +++ b/xen/arch/x86/xstate.c >> @@ -310,21 +310,21 @@ void xsave(struct vcpu *v, uint64_t mask) >> uint32_t hmask = mask >> 32; >> uint32_t lmask = mask; >> unsigned int fip_width = v->domain->arch.x87_fip_width; >> -#define XSAVE(pfx) \ >> - if ( v->arch.xcr0_accum & XSTATE_XSAVES_ONLY ) \ >> - asm volatile ( ".byte " pfx "0x0f,0xc7,0x2f\n" /* xsaves */ \ >> - : "=m" (*ptr) \ >> - : "a" (lmask), "d" (hmask), "D" (ptr) ); \ >> - else \ >> - alternative_io(".byte " pfx "0x0f,0xae,0x27\n", /* xsave */ \ >> - ".byte " pfx "0x0f,0xae,0x37\n", /* xsaveopt */ \ >> - X86_FEATURE_XSAVEOPT, \ >> - "=m" (*ptr), \ >> - "a" (lmask), "d" (hmask), "D" (ptr)) >> + >> +#define XSAVE(pfx) \ >> + if ( v->arch.xcr0_accum & XSTATE_XSAVES_ONLY ) \ >> + asm volatile ( "xsaves %0" \ >> + : "=m" (*ptr) \ >> + : "a" (lmask), "d" (hmask) ); \ >> + else \ >> + alternative_io("xsave %0", \ >> + "xsaveopt %0", X86_FEATURE_XSAVEOPT, \ >> + "=m" (*ptr), \ >> + "a" (lmask), "d" (hmask)) > While no doubt neater to read this way, there's a subtle latent issue here: > "m" doesn't exclude RIP-relative addressing, yet that addressing form can't > be used in replacement code (up and until we leverage your decode-lite to > actually be able to fix up the displacement). I guess I'll fix that first. I'm not interested in trying to keep playing games to work around deficiencies in our alternatives infrastructure. > Sadly "o" as a constraint > doesn't look to be any different in this regard (I think it should be, as > adding a "small integer" may already bring the displacement beyond the > permitted range, but their definition of "offsettable" allows this). > > This issue is latent until such time that (a) a caller appears passing in > the address of a Xen-internal variable and (b) we make LTO work again. > Since the breakage would be impossible to notice at build time, I think we > would be better off if we avoided it from the beginning. Which may mean > sacrificing on code gen, by using "r" and then "(%0)" as the insn operand. Even with LTO, I don't see any plausible case where we have build-time struct vcpu's to pass in. > >> @@ -489,17 +484,17 @@ void xrstor(struct vcpu *v, uint64_t mask) >> ptr->xsave_hdr.xcomp_bv = 0; >> } >> memset(ptr->xsave_hdr.reserved, 0, sizeof(ptr->xsave_hdr.reserved)); >> - continue; >> + goto retry; >> >> case 2: /* Stage 2: Reset all state. */ >> ptr->fpu_sse.mxcsr = MXCSR_DEFAULT; >> ptr->xsave_hdr.xstate_bv = 0; >> ptr->xsave_hdr.xcomp_bv = v->arch.xcr0_accum & XSTATE_XSAVES_ONLY >> ? XSTATE_COMPACTION_ENABLED : 0; >> - continue; >> - } >> + goto retry; >> >> - domain_crash(current->domain); >> + default: /* Stage 3: Nothing else to do. */ >> + domain_crash(v->domain, "Uncorrectable XRSTOR fault\n"); >> return; > There's an unexplained change here as to which domain is being crashed. > You switch to crashing the subject domain, yet if that's not also the > requester, it isn't "guilty" in causing the observed fault. So dom0 should be crashed because there bad data in the migration stream? v is always curr.  XRSTOR can't be used correctly outside of the subject context, and indeed the Stage 2 logic above is definitely buggy when v != curr. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jan 05 18:15:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 18:15:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195707.1513626 (Exim 4.92) (envelope-from ) id 1vcp6d-0004Qj-OB; Mon, 05 Jan 2026 18:15:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195707.1513626; Mon, 05 Jan 2026 18:15:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcp6d-0004Qc-LM; Mon, 05 Jan 2026 18:15:03 +0000 Received: by outflank-mailman (input) for mailman id 1195707; Mon, 05 Jan 2026 18:15: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 1vcp6c-0004QW-Nd for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 18:15:02 +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 71b3c477-ea62-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 19:14:58 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA3PR03MB7302.namprd03.prod.outlook.com (2603:10b6:806:2f1::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9434.8; Mon, 5 Jan 2026 18:14:55 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9478.004; Mon, 5 Jan 2026 18:14: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: 71b3c477-ea62-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=piqd3azGVnnWNPJajq4IiLA44M9e3Rh6JxXbnOC7OMKkcWhZdxVQkWsMs6AB7qvnIyAbp03hwJY7b00np2sSpG2DKj3MqtqbxxUW/Vbr8gD/BuuE/Cncl1tv+M1vcVYClBiL4gPWoKTKaWbqzuz2DAxD2yBKn6NFythCom8k2pMJWYigRiXZhe6KYb9yX4iPbbEXNbpPnEhoIahDDBOmMB+MDKwbL0n+Z5InOHMDwWklzQQX/wuyOEh6nnuVGnviZOn3Ix51hdNpBxDS2qrEv8aJgSEVOKCt4hh92nPbmjUci4dkonvaR8FIUrYVifYF+2KJ05aKnhUeBf52cOu99Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uJ/sLfZkrTC7T8SMjX+AYaQOVhpKR/Q+mNtj9nFx+1I=; b=I5lQrKGfGQdha1oSLqm6S4Wxfy2pkT7Tyjv3bKovtoQ3LI4vzQm/1a0axNnrzljTerXDXV9oBY4xX3/D/3r2RdSrQjXO5OJ8/nnhG4JzQfQilvdsSM4h1DLpZ72sqZmJtOYQ7ZAfh3EJ2K5JScLInPc7V6RaSHXPzRP4ofPdt0rV0KxTxl2jVLDO+ukOArb+gcamii5MsMwYqLc8ADJEwt7nNKe6x/CQjgCdxeT8yYbYnYDszkMg/XtdbPRGTipYpTYL2NFwGLKNQWSQSM8ok9zFQ1/2JfJels+jYvvWT1qbmcBo8TzJMaaol5hu0SHrAo4zldFjqxhKuAbJTMJ7fg== 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=uJ/sLfZkrTC7T8SMjX+AYaQOVhpKR/Q+mNtj9nFx+1I=; b=mZV9gF2J6IZQNmpx84vdrd+H+Ahn8WT1slUJ78v+NQBhuZjYL+mfoZxRGcbnDogyhC6OOhpMkY47bQNWs/bnNSTHGgrvGXJZtOd9NPLHXezX4UqwgzFhaOMMi5ErQ3nBlDPcu2880uJkgoYZvYwEjsQDmx64dH9UQ4cMxyRTPFc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <82d99c52-c39b-4fbb-bbb2-0e952df91673@citrix.com> Date: Mon, 5 Jan 2026 18:14:51 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Stefano Stabellini , "consulting @ bugseng . com" , Nicola Vetrini , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel Subject: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible To: Xen-devel References: <20260105122436.555444-1-andrew.cooper3@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260105122436.555444-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0244.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8a::16) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA3PR03MB7302:EE_ X-MS-Office365-Filtering-Correlation-Id: a5e72f7c-a501-4fe9-de10-08de4c8653e1 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?dXVlK2txMjUvN05KaHJjZXJKOGl6dkxGdGJzdFZmeFVLQ3p3T3pPS2tsU2VW?= =?utf-8?B?Z3NPbmhOeGc5enZ1Zjlvdmw2eXRMSXk3Qis0NGE1OE9STGdpVGg1bHB1djlR?= =?utf-8?B?SWRTSUxGb3k4SXVqTWM1b29MZTVSblhIaXlWRUoyT1g5VjlTcXZQUHZIU0FR?= =?utf-8?B?YS9FSml0clJpRnNSNmVDUStUYzlPRXp1NFhWM3Jhci9zWGRzQUE5QTNGQkx5?= =?utf-8?B?S0dBRlhJQjFrcUxPejZBR3NDaFhuWTNGUVNoMmtHVWlDNGJac0Z2TWROMDgw?= =?utf-8?B?d3FwWFhWM3FnRmdjWGNDUnUybHhrLzYyb0NPQnBZUk1pcmFvZ1lnRUh4YWFa?= =?utf-8?B?RzI4ZlBxaGxkUEMyUUNLQjYxNzBnOHlrVUpiMGRNSVQ0ZDJVTURlRyt6c0Nk?= =?utf-8?B?WEJJL3NRdFpFcExnaFd3eG1QWVo3QllQTjZtK2htcVp6djlpSENFeTN2bUxm?= =?utf-8?B?QjUxUGJ1RXc3VVR2Ti8wNi9YaExpRlhBQloxclRLVGo3eFZzb05SNWdtSFhj?= =?utf-8?B?WGk0OXp0TU00eWVQTGVDM3VYbjd4dGRIdTV3dU5Kbjc0RGhwNi9zUENaTk5n?= =?utf-8?B?QndJU01SYXNHLzBhTU9yU3U4MkpxRDA3eFRPcFlBRk5BVm54SUx2T3RteVFl?= =?utf-8?B?TThkd0drT2krUDBlNzJWaVNiMXJUZktwVWJGcllaeVcxaHZ0T0haUzluU3Za?= =?utf-8?B?NlZsOTh6QU5McW9VZ0ttTTRteDkwTHZmQUJLM0FGWm1xYTd1L0RxWVJ1NUJG?= =?utf-8?B?UEpkcU55Rjg2RzRvWjN0VHo0NXVXZ2VhOUdTQkpvUG9aOExSMDQzSWMwWEpm?= =?utf-8?B?clZPcFlMcnFHb1dBbU5sczNENXZyVUljTkh4eDlmdjFIOTJWbnpKaDJralNj?= =?utf-8?B?cCt1d3VEZHNWTy9uUVRqalhjM1dUcVZqODdkbTlkV0pSMVkvWHdTalFTU244?= =?utf-8?B?aWdRUTcvTEJlRjIrOXVEcFlMU3hOK3FuNXNOYVJlL2xEaHRnYmVRNlBocjJt?= =?utf-8?B?Wk84YkpBYzgzZWFJSnVnS0JudnFSY0xhSHgvMEY5dkVOVTVYejlpd0FtVXZU?= =?utf-8?B?MDJUQTNTcEdVcXJ3Sm05WTY5TmQ3UjhHU1BKRTZoZm12WnhBd2RwL25QcHVQ?= =?utf-8?B?YnB1R2lGVFdoQ0JrSm9qdjhTQmQ0d3g3dThKT0V5RHVQb1BnTnR6WUthZjZx?= =?utf-8?B?M3ZZS0dsWmFVQnBCU2dySlphZGNrcE14MUJteStRYmJvRzNxZEpPdFF6czdS?= =?utf-8?B?dks5QXlKRDBMTlJvbVRaQ0VaeFhiQjhLNXNIMGRjb2crTEF0eXVkQWxMdDRW?= =?utf-8?B?cVZPUTBtQzdTVWRGZHNSV1c4cTB2b2poak1LdTFhamJGOUI4dHR4Zms4dXJr?= =?utf-8?B?SGVzV3lRUDdSbnBaL2RvcTRhUjJMeE93ajFVVVkyZkFQY21MU2FuMy9ieHZm?= =?utf-8?B?UEJHS0lFMGpNSG9uQithR1dOVEFwMCtCWmFNbHl3L3BpTXI1b1E4N2JzY05C?= =?utf-8?B?UDRhK1FTbTlnUUZXZkwzTDR6Nm9TT2x0RENnK2E5ZitWQ29GOHpmb0Z2YjlL?= =?utf-8?B?dGlzWExCQ0JENER4bC95d2NoREJNQW9TWGVkNGtBSGJOL0YzTWhXRnR3RW10?= =?utf-8?B?TmlVbVo5RGpJVHVlK2NnRlRLQm8yaU1MKzlpSHlVZVpyTlFTaWlDakVsalQ0?= =?utf-8?B?OHV1YkVBeldLZkJDUnNIa0NHa1BkSEpwV3FzakpYSFduR0VRcDFValIyNnN6?= =?utf-8?B?UCtuNW9laHU4RFdtOHowUjNNVDJ1SjZRS2MzbXNFRWEycGlTeEp4Y3cwNzhF?= =?utf-8?B?d0lGYlFYYUZmVW9mOVNpdUNyN3lxN2RkTWpKZVZZYWo2b1VNSEVEYmhBTTdD?= =?utf-8?B?UDYzVk1CNnVwN1VjWXZUQWZZekhSem1aVXFMaXlZeFg2U290ZDBXZ1hEeG1L?= =?utf-8?B?dXg2d09HMEE4Umw4dU9vZitYZEJjQTBUekZVVjZqSnQvY0NDbGdzT3pQOFEr?= =?utf-8?B?YkhtcDVvczF3PT0=?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?R0RHd2NsRjVCZHAxZVZMZ21NYVo5R1JJSUFJaDBBVForcStneGI0UDNjMjlD?= =?utf-8?B?V3RFZkVNb2tVbU50cG1XeDNVNGpoRlBVUVM5UnNibHF2dUZHcVdWZzhIaVM4?= =?utf-8?B?bmFxUzRVU3FnSHQwSjhKa3g3c2RoS3Vaa3d3d21iYTMyRFg1czk2SDBNODRl?= =?utf-8?B?QzZnNWhWQkZJaTYzVHZjY0RyZkUwSXNVVWhXemZ6YkhmWFNRVXJqUHZvNkkv?= =?utf-8?B?NEZ6c3lmWjlsZjM4TU01bHY3S2J5VzNQMGxSdVFqS2s0d0d0WEo3bWhkWjZj?= =?utf-8?B?MnhjRDZwWjIxc25rU0Z6RmJzMm9DdHBhcUxsRTQ2RnlwZmR4ejVsNFBBZEMw?= =?utf-8?B?enJ5aE5mREthNmNvaDVYa3JDblRjZlNoeWhLeFMzN0liWEhHMnA4V3p0TENY?= =?utf-8?B?aEhwN2hTdUxkT1FtOXFzZEk3WUhldkNGa1RFWHo2ZUNZTTFFSHNzZWt3UFpo?= =?utf-8?B?RnBiY3BVWVhDS2NGaUtKUFBTODdFdUV1UzAzOWRlOWRGd0dBMUhjYXZNTStw?= =?utf-8?B?amgrdEsxSll1Wm44Z1BLam5vMzdpN0pXQkV2cEk2OGJzNGErclhJM05vcy95?= =?utf-8?B?ZWdKRVU2Q2UyOVhsSXVwb3dBUC93KzExdDU4ZUVXMWNNaEdXTDlDYVdtN2JT?= =?utf-8?B?S2J2U0ZJU1hzMTg0ZFY1RlBCN0FhQXZNazdOYkZtakVSdU4wRWdualk4SzBr?= =?utf-8?B?UE93MWJXNFhFRjJ1NVNNQnJLaHVtT2pOWmV2emdDMWJPTFlhbDJWNjJwRjlW?= =?utf-8?B?UDBOMlEwKzUrWnFidzVmZjJGVnZicWJraVZzK2YwbU5BWTVaWUpicmlLZlE4?= =?utf-8?B?VjdsVmVabUJNa0VsOTVqaUIrRWtDeGlrbUR6eWFYWS9pNGVJZ2ErVTMrcjZ0?= =?utf-8?B?QzlkYUxEeXNYSnpYcHhIVEFsb2FzVXh2TkZ0QXVKbnViVFRiTnlrTUN5Rm5h?= =?utf-8?B?R0h3MUJpNHBLeVRsTEpMY3pqbU1JKytDQ2VldWVybUVDZ2xnVHJiTktMUnR6?= =?utf-8?B?WVZ4cHZGVlNheVc2b2wra2xqa0Fxd3ozRHhmWkZpY1k5ajlJSEh4UGRYcTNq?= =?utf-8?B?NVM3eVRDRUNiSTNxU0l4NUlmOFUvamZEWUNibnpQUk0rVkZMVDIwRlZhaGRY?= =?utf-8?B?clBXWnFoa1JWT1VvcjRramdaTEdMNERHYnVoU1JFeVFKa29kTDBTcyswdzlo?= =?utf-8?B?ekhWZTYyQ3E0b1AwRW5vU1NMR2g1UFpsMW1LSDRZS3IvbVlCakxqVGVOSVFK?= =?utf-8?B?Ym54YmVIYVdmRGJwbjJyTlR5cWdZcDdMY3dhaG1CWldtUGhxS0RIVWZIVkNS?= =?utf-8?B?aXhSeWFGVWU4Sk1tVDM5d25jYm1EQkZvYzZKWCtLaVNrR05UK3NoMTRiQmJn?= =?utf-8?B?bTFETlFzaEVDU3JuWHgrQmdsMUJIakw3TWcyS0lDY1JwdW5tbTVYQlpiNUVp?= =?utf-8?B?YjNkOERzSHY3dnJzRWl5Z0dNbm5JNExzNmFuSi9mY2NZbjYyWjQ5Mzc3Z0Rt?= =?utf-8?B?MVA1WkVNcnIrdFc1SFdSN1dic3lLYS9hbmZ0dHgydTlDUmR5RnA3TjBSeUpu?= =?utf-8?B?eDF6RWJjQkxQeVhKY09MaWNTQlVWRFV5VDhZdHZXb2x4K0YzaHdDNEhjSTZv?= =?utf-8?B?cVc2KzhVTVUrbmJNdk5ZTE1vQ241UC8vMVk2b29na3NIY2kxWEtMVnRzWjRU?= =?utf-8?B?NVZOdGN5VEVuQTVjYzAzVDI2SXlLYWlDSU1oT1RWRi9YcWFSNkpwYVViS2Ju?= =?utf-8?B?WUk2N1RNdVBQT0NZb3ZrN2o0NWFDU3RYODVRVk9XN3JSeFpaeUt1SFIwcjkv?= =?utf-8?B?d2w4ODBmaUNhVXNKanJyY2RKNmpyaVF6cTNsNmJIbVZCZk5YS3hiMEFxb1Az?= =?utf-8?B?bTdmQWNpYmlsSllZQVJwY3pBUERRRnBvVjA5VXpqQ251TGdKQ3NTdjU2QWxq?= =?utf-8?B?bVVISWE4YmNVZmk1K1FRek9ERU1OODB0dS80bjRqYldJTTVnKyt5S0VNRjA5?= =?utf-8?B?aGd2UEFVSnE5MGtRZFFIMklUVHZOSk1WUTZPQlczcjR2YmtpZlN3T2lqRlFt?= =?utf-8?B?d1l1OGh1OXRmWmJCZ1BsYTdBWThXRWdDODdiMlFCM2NSMVNSbnBTeVpUKzcw?= =?utf-8?B?bE9VZ0lvL3BXeHk4ck5tS2hsd1dCdTcrQWxvRm9aTjkxSlVmdVJJVjEzYnJo?= =?utf-8?B?TVdMTlRIVmk0c01vYSsvTnBPWlo3RUtSM1RZdk02T2N6c3hHS0VkZUtsUW9i?= =?utf-8?B?cjkveWVCWENrN0JDdndOU1YxbWo2VjI1Y2FNNGIrcmFBRHpieTEzajNsL2JJ?= =?utf-8?B?ZklwVHkyTDV3Ukg5UFh1SWVjNGo1QWJMYjlpUldrbUxHQy9MQTNmQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a5e72f7c-a501-4fe9-de10-08de4c8653e1 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2026 18:14:55.1341 (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: qza4XP0VLpIM2n+Ge9BKhKsr4Qhk4/uBFAMnAJh5BKqY94FBW9haZgBUrlNI/GMwluH3J9v3mhYmC7IznRPID9y1Z3qNAb4Zgg+v0zkcxxg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR03MB7302 On 05/01/2026 12:24 pm, Andrew Cooper wrote: > eclair-x86_64-testing: > @@ -104,6 +122,33 @@ eclair-ARM64-allcode: > LOGFILE: "eclair-ARM64.log" > VARIANT: "ARM64" > RULESET: "monitored" > + EXTRA_XEN_CONFIG: | > + CONFIG_ACPI=y > + CONFIG_ARGO=y > + CONFIG_ARM64_SVE=y > + CONFIG_ARM_SMMU_V3=y > + CONFIG_BOOT_TIME_CPUPOOLS=y > + CONFIG_DEBUG_LOCK_PROFILE=y > + CONFIG_DEBUG_TRACE=y > + CONFIG_DEVICE_TREE_DEBUG=y > + CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y > + CONFIG_EXPERT=y > + CONFIG_FFA=y > + CONFIG_FFA_VM_TO_VM=y > + CONFIG_GICV3_ESPI=y > + CONFIG_HAS_ITS=y > + CONFIG_IOREQ_SERVER=y > + CONFIG_IPMMU_VMSA=y > + CONFIG_LIVEPATCH=y > + CONFIG_LLC_COLORING=y > + CONFIG_OPTEE=y > + CONFIG_OVERLAY_DTB=y > + CONFIG_PCI_PASSTHROUGH=y > + CONFIG_PERF_ARRAYS=y > + CONFIG_PERF_COUNTERS=y > + CONFIG_STACK_PROTECTOR=y > + CONFIG_UNSUPPORTED=y > + CONFIG_VM_EVENT=y > allow_failure: true https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/12604499722 shows 122 failures in otherwise-clean guidelines.  Some observations: llc-colouring.c uses binary literals.  These are safe to use now since 4.21 with the updated toolchain baseline, but the Eclair config wants updating to allow this language extension. ipmmu-vmsa.c has a git:// url inside a block comment, which is considered to be a Rule 3.1 violation.  In principle this ought to fix it: diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl index 7dee4a488d45..8f5fc6c93bc5 100644 --- a/automation/eclair_analysis/ECLAIR/deviations.ecl +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl @@ -60,7 +60,7 @@ removed by the compiler, the resulting slowdown is negligible."    -doc_begin="Comments starting with '/*' and containing hyperlinks are safe as  they are not instances of commented-out code." --config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*https?://.*$))"} +-config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*(https?|git)://.*$))"}  -doc_end    # but I've not tried it yet. There's a R8.4 violation against __stack_chk_guard.  I think this wants deviating locally, because it's a fairly magic construct. Other than that, there's a smattering of violations.  Some will be fixed by some work I've got pending for the x86 side of things, but most are specific to arch/arm/. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jan 05 19:57:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 19:57:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195722.1513637 (Exim 4.92) (envelope-from ) id 1vcqhi-0000Wf-TG; Mon, 05 Jan 2026 19:57:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195722.1513637; Mon, 05 Jan 2026 19:57:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcqhi-0000WY-PL; Mon, 05 Jan 2026 19:57:26 +0000 Received: by outflank-mailman (input) for mailman id 1195722; Mon, 05 Jan 2026 19:57: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 1vcqhg-0000WS-IJ for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 19:57: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 bfb571da-ea70-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 20:57:23 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-4779cc419b2so2506125e9.3 for ; Mon, 05 Jan 2026 11:57:22 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f68f4ddsm4237405e9.2.2026.01.05.11.57.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jan 2026 11:57:19 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bfb571da-ea70-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1767643041; x=1768247841; 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=N2UBxLQak+i5Ob4lOnr175LyFxF1yg59I9tmG5XM1dQ=; b=uXthQpcB9ldoKA+qZjHXnTZ+0LMoq56F1JMR2E7ByHnsKRN4pVNdgjqn/ASA01UsYK YUYn3tGhwM+8mJX0DMFnzkzx8JkGyBl6bJB8qlJ70TWI5scQXXVgwsZP0ssTqljOYKEl 1RxUYfHIQfL56J7KNiXxJ05aNPDfnN1XXUQ14= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767643041; x=1768247841; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=N2UBxLQak+i5Ob4lOnr175LyFxF1yg59I9tmG5XM1dQ=; b=fxyZ8VoE7qPhNvbemvVDty3IIiBVJTvj19GNNjMfxI3TwG8HKtWKxLvLwfFsl+jshk j/0JUA2YNNqAHdIb3GKjoWxsjv75NmY5BvIvPm5+6dwj736BqC8+0BmGaac5b/Xcn8g+ MBSjvoXYCMhBv1UcqpKo4pc0XQMnIcRPYnbQkqDgVfx1EFknIpeCvlx1fqVXxArkFuyF bsWGcYkuWbUSQSc7VHDHvX0znbsHG9gGicRY9+VnQqnFfmlY4IcAf5B4kBXIT3cu0xWM kYA6jP8wdNTpP/fnZDJdeBvwsFJSEYw9cM2rReO3hgyDJZ3hY7APSH5NOhIDxcMPfZef 5WuQ== X-Gm-Message-State: AOJu0YwN0Oe4vmgwDwbElQHOeh8HAzenHG5EzmdzzIepCFtxM1kLy0IL ZsL3xSnN23V04+h0MY3aEfE90kzsUtI7kh0AQqiC2fc9ctHnp7RC+UvbLrE8hHlJ5SmgoQgc+ti U8f43 X-Gm-Gg: AY/fxX7R3s3VVu+oQ/k3jgYj3J5S86dGhIH8Nn7bTILEIfIT5cAeLr7ZNOjmf5LMgRL miaiBQKXKc8vnF92FHEduUcJSukRW49DjFnl+loA6cbOuzmC7QrbdF9pxlqiHsbqw6ae4CufVZT m6eG0lcy9sC+A5jM7Du3Rr8WxZLKaiIFkQZxBaorE9l20LsrUrjbnQqU5EcBfEyGjIQuDA+gAtG 1WLgMFwm0PoMfBB16VUt9itr8NceCX5DFJ0St2FfOJMBbv4kKuBacmCCu1dI77IXtbrGelSo8o7 qt9YZ//FivsewP1DT6f6ckZgBC49ENOnY25lip/Os0VxcNSgGkRAtsf3MPZeHMGIIEtn1Y2m2sA hTrfPFM5f6T8MwsPPcNOoTDLneSoAekGsjFQFc2/Gq4pR2eIuh+awUj3Wh5A+6+wPb/b/JSuPFU 29xB8aObdq2Axjff2ZI6+S9DNgpYRgIZlW51RPDMcGSxF4tbAR7b4rHJVbC5pl1A8SdxWPzjRy X-Google-Smtp-Source: AGHT+IE2xy1jvBdQ2UVHXv62JX+gu97k1tDL42/Ig4znjKXkd51TGSwTmmRHpBK+KldektVWEDf+Yg== X-Received: by 2002:a05:600c:8116:b0:477:429b:3b93 with SMTP id 5b1f17b1804b1-47d7f09b7a0mr5117385e9.18.1767643039705; Mon, 05 Jan 2026 11:57:19 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Oleksii Kurochko , "Daniel P . Smith" Subject: [PATCH] xen: Drop xenoprofile support Date: Mon, 5 Jan 2026 19:57:17 +0000 Message-Id: <20260105195717.601500-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 most recent xenoprof change was 300ef0cb4fde ("x86: Add Xenoprofile support for AMD Family16h") in 2013, despite there being 42 changes worth of other cleanup/rearranging since then. Oprofile themselves dropped Xen support in commit 0c142c3a096d ("Remove opcontrol and the GUI and processor models dependent on it") in 2014, as part of releasing version 1.0 and switching over to using operf based on the Linux perf_event subsystem. Linux's version of this patch was merged in commit 24880bef417f ("Merge tag 'oprofile-removal-5.12'") in 2021. Drop xenoprof and all supporting infrastructure, including the hypercall, the XSM hook and flask vectors which lose their only caller, and even shrinks struct domain by one pointer which wasn't properly excluded in !CONFIG_XENOPROF builds. Retain the public xenoprof.h header as it is ABI, but note that the functionality is removed. 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: Daniel P. Smith Despite appearing to be architecture neutral, the internals of Xenoprof were entirely x86-specific. Another curiosity is that only the VMX MSR hooks called passive_domain_do_{rd,wr}msr(), and I can't see how this was correct for SVM. The real reason for finally getting around to this is the number of MISRA violations reported by the eclair-x86_64-allcode job that I don't feel like fixing. --- CHANGELOG.md | 3 + docs/misc/xen-command-line.pandoc | 6 - tools/flask/policy/modules/dom0.te | 2 - xen/arch/x86/Makefile | 1 - xen/arch/x86/cpu/vpmu_amd.c | 7 - xen/arch/x86/cpu/vpmu_intel.c | 6 - xen/arch/x86/hvm/svm/entry.S | 1 - xen/arch/x86/hvm/svm/svm.c | 2 - xen/arch/x86/hvm/vmx/vmx.c | 9 - xen/arch/x86/include/asm/xenoprof.h | 95 --- xen/arch/x86/oprofile/Makefile | 6 - xen/arch/x86/oprofile/backtrace.c | 145 ---- xen/arch/x86/oprofile/nmi_int.c | 485 ------------ xen/arch/x86/oprofile/op_counter.h | 41 - xen/arch/x86/oprofile/op_model_athlon.c | 547 ------------- xen/arch/x86/oprofile/op_model_p4.c | 721 ----------------- xen/arch/x86/oprofile/op_model_ppro.c | 348 --------- xen/arch/x86/oprofile/op_x86_model.h | 58 -- xen/arch/x86/oprofile/xenoprof.c | 106 --- xen/arch/x86/traps.c | 4 - xen/common/Kconfig | 11 - xen/common/Makefile | 1 - xen/common/compat/xenoprof.c | 42 - xen/common/domain.c | 6 - xen/common/xenoprof.c | 977 ------------------------ xen/include/Makefile | 1 - xen/include/hypercall-defs.c | 6 - xen/include/public/xen.h | 2 +- xen/include/public/xenoprof.h | 2 +- xen/include/xen/sched.h | 3 - xen/include/xen/xenoprof.h | 49 -- xen/include/xsm/dummy.h | 7 - xen/include/xsm/xsm.h | 7 - xen/xsm/dummy.c | 2 - xen/xsm/flask/hooks.c | 35 - xen/xsm/flask/policy/access_vectors | 4 - 36 files changed, 5 insertions(+), 3743 deletions(-) delete mode 100644 xen/arch/x86/include/asm/xenoprof.h delete mode 100644 xen/arch/x86/oprofile/Makefile delete mode 100644 xen/arch/x86/oprofile/backtrace.c delete mode 100644 xen/arch/x86/oprofile/nmi_int.c delete mode 100644 xen/arch/x86/oprofile/op_counter.h delete mode 100644 xen/arch/x86/oprofile/op_model_athlon.c delete mode 100644 xen/arch/x86/oprofile/op_model_p4.c delete mode 100644 xen/arch/x86/oprofile/op_model_ppro.c delete mode 100644 xen/arch/x86/oprofile/op_x86_model.h delete mode 100644 xen/arch/x86/oprofile/xenoprof.c delete mode 100644 xen/common/compat/xenoprof.c delete mode 100644 xen/common/xenoprof.c delete mode 100644 xen/include/xen/xenoprof.h diff --git a/CHANGELOG.md b/CHANGELOG.md index 3aaf5986231c..1663f6878ef2 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -15,6 +15,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) - The cpuid_mask_* command line options for legacy AMD CPUs. These were deprecated in Xen 4.7 and noted not to work correctly with AMD CPUs from 2011 onwards. + - Xenoprofile support. Oprofile themselves removed support for Xen in 2014 + prior to the version 1.0 release, and there has been no development since + before then in Xen. ## [4.21.0](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.21.0) - 2025-11-19 diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 805da22c44a5..189d0d2c9d4b 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -508,12 +508,6 @@ character, but for xen to keep the console. > Default: `power` -### cpu_type (x86) -> `= arch_perfmon` - -If set, force use of the performance counters for oprofile, rather than detecting -available support. - ### cpufreq > `= none | {{ | xen } { [:[powersave|performance|ondemand|userspace][,[]][,[]]] } [,verbose]} | dom0-kernel | hwp[:[][,verbose]] | amd-cppc[:[active][,verbose]]` diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te index ad2b4f9ea75f..d30edf8be1fb 100644 --- a/tools/flask/policy/modules/dom0.te +++ b/tools/flask/policy/modules/dom0.te @@ -21,8 +21,6 @@ allow dom0_t xen_t:xen { writeconsole readapic writeapic - privprofile - nonprivprofile kexec firmware sleep diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile index 1fc651146f10..d8b41cec1620 100644 --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -7,7 +7,6 @@ obj-$(CONFIG_GUEST) += guest/ obj-$(CONFIG_HVM) += hvm/ obj-y += lib/ obj-y += mm/ -obj-$(CONFIG_XENOPROF) += oprofile/ obj-$(CONFIG_PV) += pv/ obj-y += x86_64/ obj-y += x86_emulate/ diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c index fa157d45dd01..aee99bb88128 100644 --- a/xen/arch/x86/cpu/vpmu_amd.c +++ b/xen/arch/x86/cpu/vpmu_amd.c @@ -12,7 +12,6 @@ #include #include -#include #include #include @@ -363,8 +362,6 @@ static int cf_check amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content) if ( (type == MSR_TYPE_CTRL) && is_pmu_enabled(msr_content) && !vpmu_is_set(vpmu, VPMU_RUNNING) ) { - if ( !acquire_pmu_ownership(PMU_OWNER_HVM) ) - return 0; vpmu_set(vpmu, VPMU_RUNNING); if ( is_svm_vcpu(v) && is_msr_bitmap_on(vpmu) ) @@ -378,7 +375,6 @@ static int cf_check amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content) vpmu_reset(vpmu, VPMU_RUNNING); if ( is_svm_vcpu(v) && is_msr_bitmap_on(vpmu) ) amd_vpmu_unset_msr_bitmap(v); - release_pmu_ownership(PMU_OWNER_HVM); } if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) @@ -426,9 +422,6 @@ static void cf_check amd_vpmu_destroy(struct vcpu *v) vpmu->context = NULL; vpmu->priv_context = NULL; - if ( vpmu_is_set(vpmu, VPMU_RUNNING) ) - release_pmu_ownership(PMU_OWNER_HVM); - vpmu_clear(vpmu); } diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c index 7ce98ee42e54..1e3b06ef8e68 100644 --- a/xen/arch/x86/cpu/vpmu_intel.c +++ b/xen/arch/x86/cpu/vpmu_intel.c @@ -9,7 +9,6 @@ #include #include -#include #include #include #include @@ -441,9 +440,6 @@ static int cf_check core2_vpmu_alloc_resource(struct vcpu *v) struct xen_pmu_intel_ctxt *core2_vpmu_cxt = NULL; uint64_t *p = NULL; - if ( !acquire_pmu_ownership(PMU_OWNER_HVM) ) - return 0; - if ( is_vmx_vcpu(v) ) { if ( vmx_add_host_load_msr(v, MSR_CORE_PERF_GLOBAL_CTRL, 0) ) @@ -487,7 +483,6 @@ static int cf_check core2_vpmu_alloc_resource(struct vcpu *v) return 1; out_err: - release_pmu_ownership(PMU_OWNER_HVM); xfree(core2_vpmu_cxt); xfree(p); @@ -814,7 +809,6 @@ static void cf_check core2_vpmu_destroy(struct vcpu *v) vpmu->priv_context = NULL; if ( is_vmx_vcpu(v) && cpu_has_vmx_msr_bitmap ) core2_vpmu_unset_msr_bitmap(v); - release_pmu_ownership(PMU_OWNER_HVM); vpmu_clear(vpmu); } diff --git a/xen/arch/x86/hvm/svm/entry.S b/xen/arch/x86/hvm/svm/entry.S index 610c64bf4c97..af8db23b033f 100644 --- a/xen/arch/x86/hvm/svm/entry.S +++ b/xen/arch/x86/hvm/svm/entry.S @@ -155,7 +155,6 @@ __UNLIKELY_END(nsvm_hap) * to safely resolve any Spectre-v1 concerns in the above logic. */ stgi -LABEL(svm_stgi_label, 0) call svm_vmexit_handler jmp .Lsvm_do_resume diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 1208999454d3..da113f488b71 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -36,7 +36,6 @@ #include #include #include -#include #include @@ -1152,7 +1151,6 @@ static int cf_check svm_vcpu_initialise(struct vcpu *v) static void cf_check svm_vcpu_destroy(struct vcpu *v) { svm_destroy_vmcb(v); - passive_domain_destroy(v); } /* diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 05b59cb8e4d2..f4beac192d75 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -48,7 +48,6 @@ #include #include #include -#include #include #include @@ -692,7 +691,6 @@ static void cf_check vmx_vcpu_destroy(struct vcpu *v) */ vmx_vcpu_disable_pml(v); vmx_destroy_vmcs(v); - passive_domain_destroy(v); } /* @@ -3560,9 +3558,6 @@ static int cf_check vmx_msr_read_intercept( break; default: - if ( passive_domain_do_rdmsr(msr, msr_content) ) - goto done; - if ( vmx_read_guest_msr(curr, msr, msr_content) == 0 ) break; @@ -3582,7 +3577,6 @@ static int cf_check vmx_msr_read_intercept( goto gp_fault; } -done: HVM_DBG_LOG(DBG_LEVEL_MSR, "returns: ecx=%#x, msr_value=%#"PRIx64, msr, *msr_content); return X86EMUL_OKAY; @@ -3875,9 +3869,6 @@ static int cf_check vmx_msr_write_intercept( break; default: - if ( passive_domain_do_wrmsr(msr, msr_content) ) - return X86EMUL_OKAY; - if ( vmx_write_guest_msr(v, msr, msr_content) == 0 || is_last_branch_msr(msr) ) break; diff --git a/xen/arch/x86/include/asm/xenoprof.h b/xen/arch/x86/include/asm/xenoprof.h deleted file mode 100644 index dc6f822d3220..000000000000 --- a/xen/arch/x86/include/asm/xenoprof.h +++ /dev/null @@ -1,95 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0-or-later */ -/****************************************************************************** - * asm-x86/xenoprof.h - * xenoprof x86 arch specific header file - * - * Copyright (c) 2006 Isaku Yamahata - * VA Linux Systems Japan K.K. - */ - -#ifndef __ASM_X86_XENOPROF_H__ -#define __ASM_X86_XENOPROF_H__ - -struct vcpu; - -#ifdef CONFIG_XENOPROF - -#include - -int nmi_reserve_counters(void); -int nmi_setup_events(void); -int nmi_enable_virq(void); -int nmi_start(void); -void nmi_stop(void); -void nmi_disable_virq(void); -void nmi_release_counters(void); - -int xenoprof_arch_init(int *num_events, char *cpu_type); -#define xenoprof_arch_reserve_counters() nmi_reserve_counters() -#define xenoprof_arch_setup_events() nmi_setup_events() -#define xenoprof_arch_enable_virq() nmi_enable_virq() -#define xenoprof_arch_start() nmi_start() -#define xenoprof_arch_stop() nmi_stop() -#define xenoprof_arch_disable_virq() nmi_disable_virq() -#define xenoprof_arch_release_counters() nmi_release_counters() - -int xenoprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg); -int compat_oprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg); -int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE_PARAM(void) arg); - -struct cpu_user_regs; - -/* AMD IBS support */ -void ibs_init(void); -extern u32 ibs_caps; - -int xenoprofile_get_mode(struct vcpu *, const struct cpu_user_regs *); - -static inline int xenoprof_backtrace_supported(void) -{ - return 1; -} - -void xenoprof_backtrace(struct vcpu *, const struct cpu_user_regs *, - unsigned long depth, int mode); - -int passive_domain_do_rdmsr(unsigned int msr, uint64_t *msr_content); -int passive_domain_do_wrmsr(unsigned int msr, uint64_t msr_content); -void passive_domain_destroy(struct vcpu *v); - -bool nmi_oprofile_send_virq(void); - -#else - -static inline int passive_domain_do_rdmsr(unsigned int msr, - uint64_t *msr_content) -{ - return 0; -} - -static inline int passive_domain_do_wrmsr(unsigned int msr, - uint64_t msr_content) -{ - return 0; -} - -static inline void passive_domain_destroy(struct vcpu *v) {} - -static inline bool nmi_oprofile_send_virq(void) -{ - return false; -} - -#endif /* CONFIG_XENOPROF */ - -#endif /* __ASM_X86_XENOPROF_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/x86/oprofile/Makefile b/xen/arch/x86/oprofile/Makefile deleted file mode 100644 index 956e3d1b5d05..000000000000 --- a/xen/arch/x86/oprofile/Makefile +++ /dev/null @@ -1,6 +0,0 @@ -obj-y += xenoprof.o -obj-y += nmi_int.o -obj-y += op_model_p4.o -obj-y += op_model_ppro.o -obj-y += op_model_athlon.o -obj-y += backtrace.o diff --git a/xen/arch/x86/oprofile/backtrace.c b/xen/arch/x86/oprofile/backtrace.c deleted file mode 100644 index 61de18c8d596..000000000000 --- a/xen/arch/x86/oprofile/backtrace.c +++ /dev/null @@ -1,145 +0,0 @@ -/** - * @file backtrace.c - * - * @remark Copyright 2002 OProfile authors - * @remark Read the file COPYING - * - * @author John Levon - * @author David Smith - * Modified for Xen by Amitabha Roy - * - */ - -#include -#include -#include -#include - -struct __packed frame_head { - struct frame_head * ebp; - unsigned long ret; -}; -typedef struct frame_head frame_head_t; - -struct __packed frame_head_32bit { - uint32_t ebp; - uint32_t ret; -}; -typedef struct frame_head_32bit frame_head32_t; - -static struct frame_head * -dump_hypervisor_backtrace(struct vcpu *vcpu, const struct frame_head *head, - int mode) -{ - if (!xenoprof_add_trace(vcpu, head->ret, mode)) - return 0; - - /* frame pointers should strictly progress back up the stack - * (towards higher addresses) */ - if (head >= head->ebp) - return NULL; - - return head->ebp; -} - -static inline int is_32bit_vcpu(struct vcpu *vcpu) -{ - if (is_hvm_vcpu(vcpu)) - return !hvm_long_mode_active(vcpu); - else - return is_pv_32bit_vcpu(vcpu); -} - -static struct frame_head * -dump_guest_backtrace(struct vcpu *vcpu, const struct frame_head *head, - int mode) -{ - /* Also check accessibility of one struct frame_head beyond. */ - frame_head_t bufhead[2]; - - if ( is_32bit_vcpu(vcpu) ) - { - frame_head32_t bufhead32[2]; - - if ( raw_copy_from_guest(bufhead32, head, sizeof(bufhead32)) ) - return 0; - bufhead[0].ebp = (struct frame_head *)(unsigned long)bufhead32[0].ebp; - bufhead[0].ret = bufhead32[0].ret; - } - else if ( raw_copy_from_guest(bufhead, head, sizeof(bufhead)) ) - return 0; - - if ( !xenoprof_add_trace(vcpu, bufhead[0].ret, mode) ) - return 0; - - /* frame pointers should strictly progress back up the stack - * (towards higher addresses) */ - if ( head >= bufhead[0].ebp ) - return NULL; - - return bufhead[0].ebp; -} - -/* - * | | /\ Higher addresses - * | | - * --------------- stack base (address of current_thread_info) - * | thread info | - * . . - * | stack | - * --------------- saved regs->ebp value if valid (frame_head address) - * . . - * --------------- saved regs->rsp value if x86_64 - * | | - * --------------- struct pt_regs * stored on stack if 32-bit - * | | - * . . - * | | - * --------------- %esp - * | | - * | | \/ Lower addresses - * - * Thus, regs (or regs->rsp for x86_64) <-> stack base restricts the - * valid(ish) ebp values. Note: (1) for x86_64, NMI and several other - * exceptions use special stacks, maintained by the interrupt stack table - * (IST). These stacks are set up in trap_init() in - * arch/x86_64/kernel/traps.c. Thus, for x86_64, regs now does not point - * to the kernel stack; instead, it points to some location on the NMI - * stack. On the other hand, regs->rsp is the stack pointer saved when the - * NMI occurred. (2) For 32-bit, regs->esp is not valid because the - * processor does not save %esp on the kernel stack when interrupts occur - * in the kernel mode. - */ -#if defined(CONFIG_FRAME_POINTER) -static int valid_hypervisor_stack(const struct frame_head *head, - const struct cpu_user_regs *regs) -{ - unsigned long headaddr = (unsigned long)head; - unsigned long stack = (unsigned long)regs->rsp; - unsigned long stack_base = (stack & ~(STACK_SIZE - 1)) + STACK_SIZE; - - return headaddr > stack && headaddr < stack_base; -} -#else -/* without fp, it's just junk */ -static int valid_hypervisor_stack(const struct frame_head *head, - const struct cpu_user_regs *regs) -{ - return 0; -} -#endif - -void xenoprof_backtrace(struct vcpu *vcpu, const struct cpu_user_regs *regs, - unsigned long depth, int mode) -{ - const struct frame_head *head = (void *)regs->rbp; - - if (mode > 1) { - while (depth-- && valid_hypervisor_stack(head, regs)) - head = dump_hypervisor_backtrace(vcpu, head, mode); - return; - } - - while (depth-- && head) - head = dump_guest_backtrace(vcpu, head, mode); -} diff --git a/xen/arch/x86/oprofile/nmi_int.c b/xen/arch/x86/oprofile/nmi_int.c deleted file mode 100644 index 1d6454cf39e8..000000000000 --- a/xen/arch/x86/oprofile/nmi_int.c +++ /dev/null @@ -1,485 +0,0 @@ -/** - * @file nmi_int.c - * - * @remark Copyright 2002 OProfile authors - * @remark Read the file COPYING - * - * @author John Levon - * - * Modified for Xen: by Aravind Menon & Jose Renato Santos - * These modifications are: - * Copyright (C) 2005 Hewlett-Packard Co. - */ - -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include - -#include -#include -#include -#include -#include - -#include "op_counter.h" -#include "op_x86_model.h" - -struct op_counter_config counter_config[OP_MAX_COUNTER]; -struct op_ibs_config ibs_config; - -struct op_x86_model_spec const *__read_mostly model; -static struct op_msrs cpu_msrs[NR_CPUS]; -static unsigned long saved_lvtpc[NR_CPUS]; - -static const char *cpu_type; - -static DEFINE_PER_CPU(struct vcpu *, nmi_cont_vcpu); - -static int passive_domain_msr_op_checks(unsigned int msr, int *typep, int *indexp) -{ - struct vpmu_struct *vpmu = vcpu_vpmu(current); - if ( model == NULL ) - return 0; - if ( model->is_arch_pmu_msr == NULL ) - return 0; - if ( !model->is_arch_pmu_msr(msr, typep, indexp) ) - return 0; - - if ( !vpmu_is_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED) ) - if ( ! model->allocated_msr(current) ) - return 0; - return 1; -} - -int passive_domain_do_rdmsr(unsigned int msr, uint64_t *msr_content) -{ - int type, index; - - if ( !passive_domain_msr_op_checks(msr, &type, &index)) - return 0; - - model->load_msr(current, type, index, msr_content); - return 1; -} - -int passive_domain_do_wrmsr(unsigned int msr, uint64_t msr_content) -{ - int type, index; - - if ( !passive_domain_msr_op_checks(msr, &type, &index)) - return 0; - - model->save_msr(current, type, index, msr_content); - return 1; -} - -void passive_domain_destroy(struct vcpu *v) -{ - struct vpmu_struct *vpmu = vcpu_vpmu(v); - if ( vpmu_is_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED) ) - model->free_msr(v); -} - -bool nmi_oprofile_send_virq(void) -{ - struct vcpu *v = xchg(&this_cpu(nmi_cont_vcpu), NULL); - - if (v) - send_guest_vcpu_virq(v, VIRQ_XENOPROF); - - return v; -} - -static int cf_check nmi_callback(const struct cpu_user_regs *regs, int cpu) -{ - int xen_mode, ovf; - - ovf = model->check_ctrs(cpu, &cpu_msrs[cpu], regs); - xen_mode = ring_0(regs); - if (ovf && is_active(current->domain) && !xen_mode && - !this_cpu(nmi_cont_vcpu)) { - this_cpu(nmi_cont_vcpu) = current; - trigger_nmi_continuation(); - } - - if ( ovf == 2 ) - current->arch.nmi_pending = true; - return 1; -} - - -static void nmi_cpu_save_registers(struct op_msrs *msrs) -{ - unsigned int const nr_ctrs = model->num_counters; - unsigned int const nr_ctrls = model->num_controls; - struct op_msr *counters = msrs->counters; - struct op_msr *controls = msrs->controls; - unsigned int i; - - for (i = 0; i < nr_ctrs; ++i) { - rdmsrl(counters[i].addr, counters[i].value); - } - - for (i = 0; i < nr_ctrls; ++i) { - rdmsrl(controls[i].addr, controls[i].value); - } -} - - -static void cf_check nmi_save_registers(void *dummy) -{ - int cpu = smp_processor_id(); - struct op_msrs * msrs = &cpu_msrs[cpu]; - model->fill_in_addresses(msrs); - nmi_cpu_save_registers(msrs); -} - - -static void free_msrs(void) -{ - unsigned int i; - - for (i = 0; i < nr_cpu_ids; ++i) { - XVFREE(cpu_msrs[i].counters); - XVFREE(cpu_msrs[i].controls); - } -} - - -static int allocate_msrs(void) -{ - unsigned int i; - int success = 1; - - for_each_online_cpu (i) { - cpu_msrs[i].counters = xvmalloc_array(struct op_msr, - model->num_counters); - if (!cpu_msrs[i].counters) { - success = 0; - break; - } - cpu_msrs[i].controls = xvmalloc_array(struct op_msr, - model->num_controls); - if (!cpu_msrs[i].controls) { - success = 0; - break; - } - } - - if (!success) - free_msrs(); - - return success; -} - - -static void cf_check nmi_cpu_setup(void *dummy) -{ - int cpu = smp_processor_id(); - struct op_msrs * msrs = &cpu_msrs[cpu]; - model->setup_ctrs(msrs); -} - - -int nmi_setup_events(void) -{ - on_each_cpu(nmi_cpu_setup, NULL, 1); - return 0; -} - -int nmi_reserve_counters(void) -{ - if (!allocate_msrs()) - return -ENOMEM; - - /* - * We need to be careful to install our NMI handler - * without actually triggering any NMIs as this will - * break the core code horrifically. - */ - if (reserve_lapic_nmi() < 0) { - free_msrs(); - return -EBUSY; - } - /* We need to serialize save and setup for HT because the subset - * of msrs are distinct for save and setup operations - */ - on_each_cpu(nmi_save_registers, NULL, 1); - return 0; -} - -int nmi_enable_virq(void) -{ - set_nmi_callback(nmi_callback); - return 0; -} - - -void nmi_disable_virq(void) -{ - unset_nmi_callback(); -} - - -static void nmi_restore_registers(struct op_msrs * msrs) -{ - unsigned int const nr_ctrs = model->num_counters; - unsigned int const nr_ctrls = model->num_controls; - struct op_msr * counters = msrs->counters; - struct op_msr * controls = msrs->controls; - unsigned int i; - - for (i = 0; i < nr_ctrls; ++i) { - wrmsrl(controls[i].addr, controls[i].value); - } - - for (i = 0; i < nr_ctrs; ++i) { - wrmsrl(counters[i].addr, counters[i].value); - } -} - - -static void cf_check nmi_cpu_shutdown(void *dummy) -{ - int cpu = smp_processor_id(); - struct op_msrs * msrs = &cpu_msrs[cpu]; - nmi_restore_registers(msrs); -} - - -void nmi_release_counters(void) -{ - on_each_cpu(nmi_cpu_shutdown, NULL, 1); - release_lapic_nmi(); - free_msrs(); -} - - -static void cf_check nmi_cpu_start(void *dummy) -{ - int cpu = smp_processor_id(); - struct op_msrs const * msrs = &cpu_msrs[cpu]; - saved_lvtpc[cpu] = apic_read(APIC_LVTPC); - apic_write(APIC_LVTPC, APIC_DM_NMI); - model->start(msrs); -} - - -int nmi_start(void) -{ - on_each_cpu(nmi_cpu_start, NULL, 1); - return 0; -} - - -static void cf_check nmi_cpu_stop(void *dummy) -{ - unsigned int v; - int cpu = smp_processor_id(); - struct op_msrs const * msrs = &cpu_msrs[cpu]; - model->stop(msrs); - - /* restoring APIC_LVTPC can trigger an apic error because the delivery - * mode and vector nr combination can be illegal. That's by design: on - * power on apic lvt contain a zero vector nr which are legal only for - * NMI delivery mode. So inhibit apic err before restoring lvtpc - */ - if ( (apic_read(APIC_LVTPC) & APIC_DM_MASK) != APIC_DM_NMI - || (apic_read(APIC_LVTPC) & APIC_LVT_MASKED) ) - { - printk("nmi_stop: APIC not good %ul\n", apic_read(APIC_LVTPC)); - mdelay(5000); - } - v = apic_read(APIC_LVTERR); - apic_write(APIC_LVTERR, v | APIC_LVT_MASKED); - apic_write(APIC_LVTPC, saved_lvtpc[cpu]); - apic_write(APIC_LVTERR, v); -} - - -void nmi_stop(void) -{ - on_each_cpu(nmi_cpu_stop, NULL, 1); -} - - -static int __init p4_init(const char **cpu_type) -{ - unsigned int cpu_model = current_cpu_data.x86_model; - - if ((cpu_model > 6) || (cpu_model == 5)) { - printk("xenoprof: Initialization failed. " - "Intel processor model %u for pentium 4 family is not " - "supported\n", cpu_model); - return 0; - } - - switch (current_cpu_data.x86_num_siblings) { - case 1: - *cpu_type = "i386/p4"; - model = &op_p4_spec; - return 1; - - case 2: - *cpu_type = "i386/p4-ht"; - model = &op_p4_ht2_spec; - return 1; - } - - printk("Xenoprof ERROR: P4 HyperThreading detected with > 2 threads\n"); - - return 0; -} - - -static int force_arch_perfmon; - -static int __init cf_check force_cpu_type(const char *str) -{ - if (!strcmp(str, "arch_perfmon")) { - force_arch_perfmon = 1; - printk(KERN_INFO "oprofile: forcing architectural perfmon\n"); - } - else - return -EINVAL; - - return 0; -} -custom_param("cpu_type", force_cpu_type); - -static int __init ppro_init(const char **cpu_type) -{ - if (force_arch_perfmon && cpu_has_arch_perfmon) - return 0; - - switch (current_cpu_data.x86_model) { - case 14: - *cpu_type = "i386/core"; - break; - case 15: - *cpu_type = "i386/core_2"; - ppro_has_global_ctrl = 1; - break; - default: - /* Unknown */ - return 0; - } - - model = &op_ppro_spec; - return 1; -} - -static int __init arch_perfmon_init(const char **cpu_type) -{ - if (!cpu_has_arch_perfmon) - return 0; - *cpu_type = "i386/arch_perfmon"; - model = &op_arch_perfmon_spec; - arch_perfmon_setup_counters(); - ppro_has_global_ctrl = 1; - return 1; -} - -static int __init cf_check nmi_init(void) -{ - unsigned int vendor = current_cpu_data.x86_vendor; - unsigned int family = current_cpu_data.x86; - - if (!cpu_has_apic) { - printk("xenoprof: Initialization failed. No APIC\n"); - return -ENODEV; - } - - switch (vendor) { - case X86_VENDOR_AMD: - /* Needs to be at least an Athlon (or hammer in 32bit mode) */ - - switch (family) { - default: - printk("xenoprof: Initialization failed. " - "AMD processor family %u is not " - "supported\n", family); - return -ENODEV; - case 0xf: - model = &op_athlon_spec; - cpu_type = "x86-64/hammer"; - break; - case 0x10: - model = &op_athlon_spec; - cpu_type = "x86-64/family10"; - ibs_init(); - break; - case 0x11: - model = &op_athlon_spec; - cpu_type = "x86-64/family11h"; - break; - case 0x12: - model = &op_athlon_spec; - cpu_type = "x86-64/family12h"; - break; - case 0x14: - model = &op_athlon_spec; - cpu_type = "x86-64/family14h"; - break; - case 0x15: - model = &op_amd_fam15h_spec; - cpu_type = "x86-64/family15h"; - break; - case 0x16: - model = &op_athlon_spec; - cpu_type = "x86-64/family16h"; - break; - } - break; - - case X86_VENDOR_INTEL: - switch (family) { - /* Pentium IV */ - case 0xf: - p4_init(&cpu_type); - break; - - /* A P6-class processor */ - case 6: - ppro_init(&cpu_type); - break; - - default: - break; - } - if (!cpu_type && !arch_perfmon_init(&cpu_type)) { - printk("xenoprof: Initialization failed. " - "Intel processor family %u model %d is not supported\n", - family, current_cpu_data.x86_model); - return -ENODEV; - } - break; - - default: - printk("xenoprof: Initialization failed. " - "Unsupported processor. Unknown vendor %u\n", - vendor); - return -ENODEV; - } - - return 0; -} - -__initcall(nmi_init); - -int xenoprof_arch_init(int *num_events, char *_cpu_type) -{ - if (cpu_type == NULL) - return -ENODEV; - *num_events = model->num_counters; - strlcpy(_cpu_type, cpu_type, XENOPROF_CPU_TYPE_SIZE); - return 0; -} diff --git a/xen/arch/x86/oprofile/op_counter.h b/xen/arch/x86/oprofile/op_counter.h deleted file mode 100644 index b515ac9ebc8e..000000000000 --- a/xen/arch/x86/oprofile/op_counter.h +++ /dev/null @@ -1,41 +0,0 @@ -/** - * @file op_counter.h - * - * @remark Copyright 2002 OProfile authors - * @remark Read the file COPYING - * - * @author John Levon - */ - -#ifndef OP_COUNTER_H -#define OP_COUNTER_H - -#define OP_MAX_COUNTER 8 - -/* Per-perfctr configuration as set via - * oprofilefs. - */ -struct op_counter_config { - unsigned long count; - unsigned long enabled; - unsigned long event; - unsigned long kernel; - unsigned long user; - unsigned long unit_mask; -}; - -extern struct op_counter_config counter_config[]; - -/* AMD IBS configuration */ -struct op_ibs_config { - unsigned long op_enabled; - unsigned long fetch_enabled; - unsigned long max_cnt_fetch; - unsigned long max_cnt_op; - unsigned long rand_en; - unsigned long dispatched_ops; -}; - -extern struct op_ibs_config ibs_config; - -#endif /* OP_COUNTER_H */ diff --git a/xen/arch/x86/oprofile/op_model_athlon.c b/xen/arch/x86/oprofile/op_model_athlon.c deleted file mode 100644 index 4c016624a69b..000000000000 --- a/xen/arch/x86/oprofile/op_model_athlon.c +++ /dev/null @@ -1,547 +0,0 @@ -/** - * @file op_model_athlon.h - * athlon / K7 model-specific MSR operations - * - * @remark Copyright 2002 OProfile authors - * @remark Read the file COPYING - * - * @author John Levon - * @author Philippe Elie - * @author Graydon Hoare - */ - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include "op_x86_model.h" -#include "op_counter.h" - -#define K7_NUM_COUNTERS 4 -#define K7_NUM_CONTROLS 4 - -#define FAM15H_NUM_COUNTERS 6 -#define FAM15H_NUM_CONTROLS 6 - -#define MAX_COUNTERS FAM15H_NUM_COUNTERS - -#define CTR_READ(msr_content,msrs,c) do {rdmsrl(msrs->counters[(c)].addr, (msr_content));} while (0) -#define CTR_WRITE(l,msrs,c) wrmsr(msrs->counters[(c)].addr, -(l)) -#define CTR_OVERFLOWED(n) (!((n) & (1ULL<<31))) - -#define CTRL_READ(msr_content,msrs,c) do {rdmsrl(msrs->controls[(c)].addr, (msr_content));} while (0) -#define CTRL_WRITE(msr_content,msrs,c) do {wrmsrl(msrs->controls[(c)].addr, (msr_content));} while (0) -#define CTRL_SET_ACTIVE(n) (n |= (1ULL<<22)) -#define CTRL_SET_INACTIVE(n) (n &= ~(1ULL<<22)) -#define CTRL_CLEAR(val) (val &= (1ULL<<21)) -#define CTRL_SET_ENABLE(val) (val |= 1ULL<<20) -#define CTRL_SET_USR(val,u) (val |= ((u & 1) << 16)) -#define CTRL_SET_KERN(val,k) (val |= ((k & 1) << 17)) -#define CTRL_SET_UM(val, m) (val |= ((m & 0xff) << 8)) -#define CTRL_SET_EVENT(val, e) (val |= (((e >> 8) & 0xf) | (e & 0xff))) -#define CTRL_SET_HOST_ONLY(val, h) (val |= ((h & 0x1ULL) << 41)) -#define CTRL_SET_GUEST_ONLY(val, h) (val |= ((h & 0x1ULL) << 40)) - -static unsigned long reset_value[MAX_COUNTERS]; - -extern char svm_stgi_label[]; - -u32 ibs_caps = 0; -static u64 ibs_op_ctl; - -/* IBS cpuid feature detection */ -#define IBS_CPUID_FEATURES 0x8000001b - -/* IBS MSRs */ -#define MSR_AMD64_IBSFETCHCTL 0xc0011030 -#define MSR_AMD64_IBSFETCHLINAD 0xc0011031 -#define MSR_AMD64_IBSFETCHPHYSAD 0xc0011032 -#define MSR_AMD64_IBSOPCTL 0xc0011033 -#define MSR_AMD64_IBSOPRIP 0xc0011034 -#define MSR_AMD64_IBSOPDATA 0xc0011035 -#define MSR_AMD64_IBSOPDATA2 0xc0011036 -#define MSR_AMD64_IBSOPDATA3 0xc0011037 -#define MSR_AMD64_IBSDCLINAD 0xc0011038 -#define MSR_AMD64_IBSDCPHYSAD 0xc0011039 -#define MSR_AMD64_IBSCTL 0xc001103a - -/* - * Same bit mask as for IBS cpuid feature flags (Fn8000_001B_EAX), but - * bit 0 is used to indicate the existence of IBS. - */ -#define IBS_CAPS_AVAIL (1LL<<0) -#define IBS_CAPS_RDWROPCNT (1LL<<3) -#define IBS_CAPS_OPCNT (1LL<<4) - -/* IBS randomization macros */ -#define IBS_RANDOM_BITS 12 -#define IBS_RANDOM_MASK ((1ULL << IBS_RANDOM_BITS) - 1) -#define IBS_RANDOM_MAXCNT_OFFSET (1ULL << (IBS_RANDOM_BITS - 5)) - -/* IbsFetchCtl bits/masks */ -#define IBS_FETCH_RAND_EN (1ULL<<57) -#define IBS_FETCH_VAL (1ULL<<49) -#define IBS_FETCH_ENABLE (1ULL<<48) -#define IBS_FETCH_CNT 0xFFFF0000ULL -#define IBS_FETCH_MAX_CNT 0x0000FFFFULL - -/* IbsOpCtl bits */ -#define IBS_OP_CNT_CTL (1ULL<<19) -#define IBS_OP_VAL (1ULL<<18) -#define IBS_OP_ENABLE (1ULL<<17) -#define IBS_OP_MAX_CNT 0x0000FFFFULL - -/* IBS sample identifier */ -#define IBS_FETCH_CODE 13 -#define IBS_OP_CODE 14 - -#define clamp(val, min, max) ({ \ - typeof(val) __val = (val); \ - typeof(min) __min = (min); \ - typeof(max) __max = (max); \ - (void) (&__val == &__min); \ - (void) (&__val == &__max); \ - __val = __val < __min ? __min: __val; \ - __val > __max ? __max: __val; }) - -/* - * 16-bit Linear Feedback Shift Register (LFSR) - */ -static unsigned int lfsr_random(void) -{ - static unsigned int lfsr_value = 0xF00D; - unsigned int bit; - - /* Compute next bit to shift in */ - bit = ((lfsr_value >> 0) ^ - (lfsr_value >> 2) ^ - (lfsr_value >> 3) ^ - (lfsr_value >> 5)) & 0x0001; - - /* Advance to next register value */ - lfsr_value = (lfsr_value >> 1) | (bit << 15); - - return lfsr_value; -} - -/* - * IBS software randomization - * - * The IBS periodic op counter is randomized in software. The lower 12 - * bits of the 20 bit counter are randomized. IbsOpCurCnt is - * initialized with a 12 bit random value. - */ -static inline u64 op_amd_randomize_ibs_op(u64 val) -{ - unsigned int random = lfsr_random(); - - if (!(ibs_caps & IBS_CAPS_RDWROPCNT)) - /* - * Work around if the hw can not write to IbsOpCurCnt - * - * Randomize the lower 8 bits of the 16 bit - * IbsOpMaxCnt [15:0] value in the range of -128 to - * +127 by adding/subtracting an offset to the - * maximum count (IbsOpMaxCnt). - * - * To avoid over or underflows and protect upper bits - * starting at bit 16, the initial value for - * IbsOpMaxCnt must fit in the range from 0x0081 to - * 0xff80. - */ - val += (int8_t)(random >> 4); - else - val |= (u64)(random & IBS_RANDOM_MASK) << 32; - - return val; -} - -static void cf_check athlon_fill_in_addresses(struct op_msrs * const msrs) -{ - msrs->counters[0].addr = MSR_K7_PERFCTR0; - msrs->counters[1].addr = MSR_K7_PERFCTR1; - msrs->counters[2].addr = MSR_K7_PERFCTR2; - msrs->counters[3].addr = MSR_K7_PERFCTR3; - - msrs->controls[0].addr = MSR_K7_EVNTSEL0; - msrs->controls[1].addr = MSR_K7_EVNTSEL1; - msrs->controls[2].addr = MSR_K7_EVNTSEL2; - msrs->controls[3].addr = MSR_K7_EVNTSEL3; -} - -static void cf_check fam15h_fill_in_addresses(struct op_msrs * const msrs) -{ - msrs->counters[0].addr = MSR_AMD_FAM15H_PERFCTR0; - msrs->counters[1].addr = MSR_AMD_FAM15H_PERFCTR1; - msrs->counters[2].addr = MSR_AMD_FAM15H_PERFCTR2; - msrs->counters[3].addr = MSR_AMD_FAM15H_PERFCTR3; - msrs->counters[4].addr = MSR_AMD_FAM15H_PERFCTR4; - msrs->counters[5].addr = MSR_AMD_FAM15H_PERFCTR5; - - msrs->controls[0].addr = MSR_AMD_FAM15H_EVNTSEL0; - msrs->controls[1].addr = MSR_AMD_FAM15H_EVNTSEL1; - msrs->controls[2].addr = MSR_AMD_FAM15H_EVNTSEL2; - msrs->controls[3].addr = MSR_AMD_FAM15H_EVNTSEL3; - msrs->controls[4].addr = MSR_AMD_FAM15H_EVNTSEL4; - msrs->controls[5].addr = MSR_AMD_FAM15H_EVNTSEL5; -} - -static void cf_check athlon_setup_ctrs(struct op_msrs const * const msrs) -{ - uint64_t msr_content; - int i; - unsigned int const nr_ctrs = model->num_counters; - unsigned int const nr_ctrls = model->num_controls; - - /* clear all counters */ - for (i = 0 ; i < nr_ctrls; ++i) { - CTRL_READ(msr_content, msrs, i); - CTRL_CLEAR(msr_content); - CTRL_WRITE(msr_content, msrs, i); - } - - /* avoid a false detection of ctr overflows in NMI handler */ - for (i = 0; i < nr_ctrs; ++i) { - CTR_WRITE(1, msrs, i); - } - - /* enable active counters */ - for (i = 0; i < nr_ctrs; ++i) { - if (counter_config[i].enabled) { - reset_value[i] = counter_config[i].count; - - CTR_WRITE(counter_config[i].count, msrs, i); - - CTRL_READ(msr_content, msrs, i); - CTRL_CLEAR(msr_content); - CTRL_SET_ENABLE(msr_content); - CTRL_SET_USR(msr_content, counter_config[i].user); - CTRL_SET_KERN(msr_content, counter_config[i].kernel); - CTRL_SET_UM(msr_content, counter_config[i].unit_mask); - CTRL_SET_EVENT(msr_content, counter_config[i].event); - CTRL_SET_HOST_ONLY(msr_content, 0); - CTRL_SET_GUEST_ONLY(msr_content, 0); - CTRL_WRITE(msr_content, msrs, i); - } else { - reset_value[i] = 0; - } - } -} - -static inline void -ibs_log_event(u64 data, struct cpu_user_regs const * const regs, int mode) -{ - struct vcpu *v = current; - u32 temp = 0; - - temp = data & 0xFFFFFFFF; - xenoprof_log_event(v, regs, temp, mode, 0); - - temp = (data >> 32) & 0xFFFFFFFF; - xenoprof_log_event(v, regs, temp, mode, 0); - -} - -static inline int handle_ibs(int mode, struct cpu_user_regs const * const regs) -{ - u64 val, ctl; - struct vcpu *v = current; - - if (!ibs_caps) - return 1; - - if (ibs_config.fetch_enabled) { - rdmsrl(MSR_AMD64_IBSFETCHCTL, ctl); - if (ctl & IBS_FETCH_VAL) { - rdmsrl(MSR_AMD64_IBSFETCHLINAD, val); - xenoprof_log_event(v, regs, IBS_FETCH_CODE, mode, 0); - xenoprof_log_event(v, regs, val, mode, 0); - - ibs_log_event(val, regs, mode); - ibs_log_event(ctl, regs, mode); - - rdmsrl(MSR_AMD64_IBSFETCHPHYSAD, val); - ibs_log_event(val, regs, mode); - - /* reenable the IRQ */ - ctl &= ~(IBS_FETCH_VAL | IBS_FETCH_CNT); - ctl |= IBS_FETCH_ENABLE; - wrmsrl(MSR_AMD64_IBSFETCHCTL, ctl); - } - } - - if (ibs_config.op_enabled) { - rdmsrl(MSR_AMD64_IBSOPCTL, ctl); - if (ctl & IBS_OP_VAL) { - - rdmsrl(MSR_AMD64_IBSOPRIP, val); - xenoprof_log_event(v, regs, IBS_OP_CODE, mode, 0); - xenoprof_log_event(v, regs, val, mode, 0); - - ibs_log_event(val, regs, mode); - - rdmsrl(MSR_AMD64_IBSOPDATA, val); - ibs_log_event(val, regs, mode); - rdmsrl(MSR_AMD64_IBSOPDATA2, val); - ibs_log_event(val, regs, mode); - rdmsrl(MSR_AMD64_IBSOPDATA3, val); - ibs_log_event(val, regs, mode); - rdmsrl(MSR_AMD64_IBSDCLINAD, val); - ibs_log_event(val, regs, mode); - rdmsrl(MSR_AMD64_IBSDCPHYSAD, val); - ibs_log_event(val, regs, mode); - - /* reenable the IRQ */ - ctl = op_amd_randomize_ibs_op(ibs_op_ctl); - wrmsrl(MSR_AMD64_IBSOPCTL, ctl); - } - } - - return 1; -} - -static int cf_check athlon_check_ctrs( - unsigned int const cpu, struct op_msrs const * const msrs, - struct cpu_user_regs const * const regs) - -{ - uint64_t msr_content; - int i; - unsigned long eip = regs->rip; - int mode = 0; - struct vcpu *v = current; - unsigned int const nr_ctrs = model->num_counters; - -#ifdef CONFIG_AMD_SVM - struct cpu_user_regs *guest_regs = guest_cpu_user_regs(); - - if (!guest_mode(regs) && - (eip == (unsigned long)svm_stgi_label)) { - /* SVM guest was running when NMI occurred */ - ASSERT(is_hvm_vcpu(v)); - eip = guest_regs->rip; - mode = xenoprofile_get_mode(v, guest_regs); - } else -#endif - mode = xenoprofile_get_mode(v, regs); - - for (i = 0 ; i < nr_ctrs; ++i) { - CTR_READ(msr_content, msrs, i); - if (CTR_OVERFLOWED(msr_content)) { - xenoprof_log_event(current, regs, eip, mode, i); - CTR_WRITE(reset_value[i], msrs, i); - } - } - - /* See op_model_ppro.c */ - return handle_ibs(mode, regs); -} - -static inline void start_ibs(void) -{ - u64 val = 0; - - if (!ibs_caps) - return; - - if (ibs_config.fetch_enabled) { - val = (ibs_config.max_cnt_fetch >> 4) & IBS_FETCH_MAX_CNT; - val |= ibs_config.rand_en ? IBS_FETCH_RAND_EN : 0; - val |= IBS_FETCH_ENABLE; - wrmsrl(MSR_AMD64_IBSFETCHCTL, val); - } - - if (ibs_config.op_enabled) { - ibs_op_ctl = ibs_config.max_cnt_op >> 4; - if (!(ibs_caps & IBS_CAPS_RDWROPCNT)) { - /* - * IbsOpCurCnt not supported. See - * op_amd_randomize_ibs_op() for details. - */ - ibs_op_ctl = clamp((unsigned long long)ibs_op_ctl, - 0x0081ULL, 0xFF80ULL); - } else { - /* - * The start value is randomized with a - * positive offset, we need to compensate it - * with the half of the randomized range. Also - * avoid underflows. - */ - ibs_op_ctl = min(ibs_op_ctl + IBS_RANDOM_MAXCNT_OFFSET, - IBS_OP_MAX_CNT); - } - if (ibs_caps & IBS_CAPS_OPCNT && ibs_config.dispatched_ops) - ibs_op_ctl |= IBS_OP_CNT_CTL; - ibs_op_ctl |= IBS_OP_ENABLE; - val = op_amd_randomize_ibs_op(ibs_op_ctl); - wrmsrl(MSR_AMD64_IBSOPCTL, val); - } -} - -static void cf_check athlon_start(struct op_msrs const * const msrs) -{ - uint64_t msr_content; - int i; - unsigned int const nr_ctrs = model->num_counters; - for (i = 0 ; i < nr_ctrs ; ++i) { - if (reset_value[i]) { - CTRL_READ(msr_content, msrs, i); - CTRL_SET_ACTIVE(msr_content); - CTRL_WRITE(msr_content, msrs, i); - } - } - start_ibs(); -} - -static void stop_ibs(void) -{ - if (!ibs_caps) - return; - - if (ibs_config.fetch_enabled) - /* clear max count and enable */ - wrmsrl(MSR_AMD64_IBSFETCHCTL, 0); - - if (ibs_config.op_enabled) - /* clear max count and enable */ - wrmsrl(MSR_AMD64_IBSOPCTL, 0); -} - -static void cf_check athlon_stop(struct op_msrs const * const msrs) -{ - uint64_t msr_content; - int i; - unsigned int const nr_ctrs = model->num_counters; - - /* Subtle: stop on all counters to avoid race with - * setting our pm callback */ - for (i = 0 ; i < nr_ctrs ; ++i) { - CTRL_READ(msr_content, msrs, i); - CTRL_SET_INACTIVE(msr_content); - CTRL_WRITE(msr_content, msrs, i); - } - - stop_ibs(); -} - -#define IBSCTL_LVTOFFSETVAL (1 << 8) -#define APIC_EILVT_MSG_NMI 0x4 -#define APIC_EILVT_LVTOFF_IBS 1 -#define APIC_EILVTn(n) (0x500 + 0x10 * n) -static inline void __init cf_check init_ibs_nmi_per_cpu(void *arg) -{ - unsigned long reg; - - reg = (APIC_EILVT_LVTOFF_IBS << 4) + APIC_EILVTn(0); - apic_write(reg, APIC_EILVT_MSG_NMI << 8); -} - -#define PCI_DEVICE_ID_AMD_10H_NB_MISC 0x1203 -#define IBSCTL 0x1cc -static int __init init_ibs_nmi(void) -{ - int bus, dev, func; - u32 id, value; - u16 vendor_id, dev_id; - int nodes; - - /* per CPU setup */ - on_each_cpu(init_ibs_nmi_per_cpu, NULL, 1); - - nodes = 0; - for (bus = 0; bus < 256; bus++) { - for (dev = 0; dev < 32; dev++) { - for (func = 0; func < 8; func++) { - id = pci_conf_read32(PCI_SBDF(0, bus, dev, func), - PCI_VENDOR_ID); - - vendor_id = id & 0xffff; - dev_id = (id >> 16) & 0xffff; - - if ((vendor_id == PCI_VENDOR_ID_AMD) && - (dev_id == PCI_DEVICE_ID_AMD_10H_NB_MISC)) { - - pci_conf_write32( - PCI_SBDF(0, bus, dev, func), - IBSCTL, - IBSCTL_LVTOFFSETVAL | APIC_EILVT_LVTOFF_IBS); - - value = pci_conf_read32(PCI_SBDF(0, bus, dev, func), - IBSCTL); - - if (value != (IBSCTL_LVTOFFSETVAL | - APIC_EILVT_LVTOFF_IBS)) { - printk("Xenoprofile: Failed to setup IBS LVT offset, " - "IBSCTL = %#x\n", value); - return 1; - } - nodes++; - } - } - } - } - - if (!nodes) { - printk("Xenoprofile: No CPU node configured for IBS\n"); - return 1; - } - - return 0; -} - -static void __init get_ibs_caps(void) -{ - if (!boot_cpu_has(X86_FEATURE_IBS)) - return; - - /* check IBS cpuid feature flags */ - if (current_cpu_data.extended_cpuid_level >= IBS_CPUID_FEATURES) - ibs_caps = cpuid_eax(IBS_CPUID_FEATURES); - if (!(ibs_caps & IBS_CAPS_AVAIL)) - /* cpuid flags not valid */ - ibs_caps = 0; -} - -void __init ibs_init(void) -{ - get_ibs_caps(); - - if ( !ibs_caps ) - return; - - if (init_ibs_nmi()) { - ibs_caps = 0; - return; - } - - printk("Xenoprofile: AMD IBS detected (%#x)\n", - (unsigned)ibs_caps); -} - -struct op_x86_model_spec const op_athlon_spec = { - .num_counters = K7_NUM_COUNTERS, - .num_controls = K7_NUM_CONTROLS, - .fill_in_addresses = &athlon_fill_in_addresses, - .setup_ctrs = &athlon_setup_ctrs, - .check_ctrs = &athlon_check_ctrs, - .start = &athlon_start, - .stop = &athlon_stop -}; - -struct op_x86_model_spec const op_amd_fam15h_spec = { - .num_counters = FAM15H_NUM_COUNTERS, - .num_controls = FAM15H_NUM_CONTROLS, - .fill_in_addresses = &fam15h_fill_in_addresses, - .setup_ctrs = &athlon_setup_ctrs, - .check_ctrs = &athlon_check_ctrs, - .start = &athlon_start, - .stop = &athlon_stop -}; diff --git a/xen/arch/x86/oprofile/op_model_p4.c b/xen/arch/x86/oprofile/op_model_p4.c deleted file mode 100644 index d047258644db..000000000000 --- a/xen/arch/x86/oprofile/op_model_p4.c +++ /dev/null @@ -1,721 +0,0 @@ -/** - * @file op_model_p4.c - * P4 model-specific MSR operations - * - * @remark Copyright 2002 OProfile authors - * @remark Read the file COPYING - * - * @author Graydon Hoare - */ - -#include -#include -#include -#include -#include -#include -#include -#include - -#include "op_x86_model.h" -#include "op_counter.h" - -#define NUM_EVENTS 39 - -#define NUM_COUNTERS_NON_HT 8 -#define NUM_ESCRS_NON_HT 45 -#define NUM_CCCRS_NON_HT 18 -#define NUM_CONTROLS_NON_HT (NUM_ESCRS_NON_HT + NUM_CCCRS_NON_HT) - -#define NUM_COUNTERS_HT2 4 -#define NUM_ESCRS_HT2 23 -#define NUM_CCCRS_HT2 9 -#define NUM_CONTROLS_HT2 (NUM_ESCRS_HT2 + NUM_CCCRS_HT2) - -static unsigned int num_counters = NUM_COUNTERS_NON_HT; - - -/* this has to be checked dynamically since the - hyper-threadedness of a chip is discovered at - kernel boot-time. */ -static inline void setup_num_counters(void) -{ - if (boot_cpu_data.x86_num_siblings == 2) /* XXX */ - num_counters = NUM_COUNTERS_HT2; -} - -static int inline addr_increment(void) -{ - return boot_cpu_data.x86_num_siblings == 2 ? 2 : 1; -} - - -/* tables to simulate simplified hardware view of p4 registers */ -struct p4_counter_binding { - int virt_counter; - int counter_address; - int cccr_address; -}; - -struct p4_event_binding { - int escr_select; /* value to put in CCCR */ - int event_select; /* value to put in ESCR */ - struct { - int virt_counter; /* for this counter... */ - int escr_address; /* use this ESCR */ - } bindings[2]; -}; - -/* nb: these CTR_* defines are a duplicate of defines in - event/i386.p4*events. */ - - -#define CTR_BPU_0 (1 << 0) -#define CTR_MS_0 (1 << 1) -#define CTR_FLAME_0 (1 << 2) -#define CTR_IQ_4 (1 << 3) -#define CTR_BPU_2 (1 << 4) -#define CTR_MS_2 (1 << 5) -#define CTR_FLAME_2 (1 << 6) -#define CTR_IQ_5 (1 << 7) - -static struct p4_counter_binding p4_counters [NUM_COUNTERS_NON_HT] = { - { CTR_BPU_0, MSR_P4_BPU_PERFCTR0, MSR_P4_BPU_CCCR0 }, - { CTR_MS_0, MSR_P4_MS_PERFCTR0, MSR_P4_MS_CCCR0 }, - { CTR_FLAME_0, MSR_P4_FLAME_PERFCTR0, MSR_P4_FLAME_CCCR0 }, - { CTR_IQ_4, MSR_P4_IQ_PERFCTR4, MSR_P4_IQ_CCCR4 }, - { CTR_BPU_2, MSR_P4_BPU_PERFCTR2, MSR_P4_BPU_CCCR2 }, - { CTR_MS_2, MSR_P4_MS_PERFCTR2, MSR_P4_MS_CCCR2 }, - { CTR_FLAME_2, MSR_P4_FLAME_PERFCTR2, MSR_P4_FLAME_CCCR2 }, - { CTR_IQ_5, MSR_P4_IQ_PERFCTR5, MSR_P4_IQ_CCCR5 } -}; - -#define NUM_UNUSED_CCCRS NUM_CCCRS_NON_HT - NUM_COUNTERS_NON_HT - -/* All cccr we don't use. */ -static int p4_unused_cccr[NUM_UNUSED_CCCRS] = { - MSR_P4_BPU_CCCR1, MSR_P4_BPU_CCCR3, - MSR_P4_MS_CCCR1, MSR_P4_MS_CCCR3, - MSR_P4_FLAME_CCCR1, MSR_P4_FLAME_CCCR3, - MSR_P4_IQ_CCCR0, MSR_P4_IQ_CCCR1, - MSR_P4_IQ_CCCR2, MSR_P4_IQ_CCCR3 -}; - -/* p4 event codes in libop/op_event.h are indices into this table. */ - -static const struct p4_event_binding p4_events[NUM_EVENTS] = { - - { /* BRANCH_RETIRED */ - 0x05, 0x06, - { {CTR_IQ_4, MSR_P4_CRU_ESCR2}, - {CTR_IQ_5, MSR_P4_CRU_ESCR3} } - }, - - { /* MISPRED_BRANCH_RETIRED */ - 0x04, 0x03, - { { CTR_IQ_4, MSR_P4_CRU_ESCR0}, - { CTR_IQ_5, MSR_P4_CRU_ESCR1} } - }, - - { /* TC_DELIVER_MODE */ - 0x01, 0x01, - { { CTR_MS_0, MSR_P4_TC_ESCR0}, - { CTR_MS_2, MSR_P4_TC_ESCR1} } - }, - - { /* BPU_FETCH_REQUEST */ - 0x00, 0x03, - { { CTR_BPU_0, MSR_P4_BPU_ESCR0}, - { CTR_BPU_2, MSR_P4_BPU_ESCR1} } - }, - - { /* ITLB_REFERENCE */ - 0x03, 0x18, - { { CTR_BPU_0, MSR_P4_ITLB_ESCR0}, - { CTR_BPU_2, MSR_P4_ITLB_ESCR1} } - }, - - { /* MEMORY_CANCEL */ - 0x05, 0x02, - { { CTR_FLAME_0, MSR_P4_DAC_ESCR0}, - { CTR_FLAME_2, MSR_P4_DAC_ESCR1} } - }, - - { /* MEMORY_COMPLETE */ - 0x02, 0x08, - { { CTR_FLAME_0, MSR_P4_SAAT_ESCR0}, - { CTR_FLAME_2, MSR_P4_SAAT_ESCR1} } - }, - - { /* LOAD_PORT_REPLAY */ - 0x02, 0x04, - { { CTR_FLAME_0, MSR_P4_SAAT_ESCR0}, - { CTR_FLAME_2, MSR_P4_SAAT_ESCR1} } - }, - - { /* STORE_PORT_REPLAY */ - 0x02, 0x05, - { { CTR_FLAME_0, MSR_P4_SAAT_ESCR0}, - { CTR_FLAME_2, MSR_P4_SAAT_ESCR1} } - }, - - { /* MOB_LOAD_REPLAY */ - 0x02, 0x03, - { { CTR_BPU_0, MSR_P4_MOB_ESCR0}, - { CTR_BPU_2, MSR_P4_MOB_ESCR1} } - }, - - { /* PAGE_WALK_TYPE */ - 0x04, 0x01, - { { CTR_BPU_0, MSR_P4_PMH_ESCR0}, - { CTR_BPU_2, MSR_P4_PMH_ESCR1} } - }, - - { /* BSQ_CACHE_REFERENCE */ - 0x07, 0x0c, - { { CTR_BPU_0, MSR_P4_BSU_ESCR0}, - { CTR_BPU_2, MSR_P4_BSU_ESCR1} } - }, - - { /* IOQ_ALLOCATION */ - 0x06, 0x03, - { { CTR_BPU_0, MSR_P4_FSB_ESCR0}, - { 0, 0 } } - }, - - { /* IOQ_ACTIVE_ENTRIES */ - 0x06, 0x1a, - { { CTR_BPU_2, MSR_P4_FSB_ESCR1}, - { 0, 0 } } - }, - - { /* FSB_DATA_ACTIVITY */ - 0x06, 0x17, - { { CTR_BPU_0, MSR_P4_FSB_ESCR0}, - { CTR_BPU_2, MSR_P4_FSB_ESCR1} } - }, - - { /* BSQ_ALLOCATION */ - 0x07, 0x05, - { { CTR_BPU_0, MSR_P4_BSU_ESCR0}, - { 0, 0 } } - }, - - { /* BSQ_ACTIVE_ENTRIES */ - 0x07, 0x06, - { { CTR_BPU_2, MSR_P4_BSU_ESCR1 /* guess */}, - { 0, 0 } } - }, - - { /* X87_ASSIST */ - 0x05, 0x03, - { { CTR_IQ_4, MSR_P4_CRU_ESCR2}, - { CTR_IQ_5, MSR_P4_CRU_ESCR3} } - }, - - { /* SSE_INPUT_ASSIST */ - 0x01, 0x34, - { { CTR_FLAME_0, MSR_P4_FIRM_ESCR0}, - { CTR_FLAME_2, MSR_P4_FIRM_ESCR1} } - }, - - { /* PACKED_SP_UOP */ - 0x01, 0x08, - { { CTR_FLAME_0, MSR_P4_FIRM_ESCR0}, - { CTR_FLAME_2, MSR_P4_FIRM_ESCR1} } - }, - - { /* PACKED_DP_UOP */ - 0x01, 0x0c, - { { CTR_FLAME_0, MSR_P4_FIRM_ESCR0}, - { CTR_FLAME_2, MSR_P4_FIRM_ESCR1} } - }, - - { /* SCALAR_SP_UOP */ - 0x01, 0x0a, - { { CTR_FLAME_0, MSR_P4_FIRM_ESCR0}, - { CTR_FLAME_2, MSR_P4_FIRM_ESCR1} } - }, - - { /* SCALAR_DP_UOP */ - 0x01, 0x0e, - { { CTR_FLAME_0, MSR_P4_FIRM_ESCR0}, - { CTR_FLAME_2, MSR_P4_FIRM_ESCR1} } - }, - - { /* 64BIT_MMX_UOP */ - 0x01, 0x02, - { { CTR_FLAME_0, MSR_P4_FIRM_ESCR0}, - { CTR_FLAME_2, MSR_P4_FIRM_ESCR1} } - }, - - { /* 128BIT_MMX_UOP */ - 0x01, 0x1a, - { { CTR_FLAME_0, MSR_P4_FIRM_ESCR0}, - { CTR_FLAME_2, MSR_P4_FIRM_ESCR1} } - }, - - { /* X87_FP_UOP */ - 0x01, 0x04, - { { CTR_FLAME_0, MSR_P4_FIRM_ESCR0}, - { CTR_FLAME_2, MSR_P4_FIRM_ESCR1} } - }, - - { /* X87_SIMD_MOVES_UOP */ - 0x01, 0x2e, - { { CTR_FLAME_0, MSR_P4_FIRM_ESCR0}, - { CTR_FLAME_2, MSR_P4_FIRM_ESCR1} } - }, - - { /* MACHINE_CLEAR */ - 0x05, 0x02, - { { CTR_IQ_4, MSR_P4_CRU_ESCR2}, - { CTR_IQ_5, MSR_P4_CRU_ESCR3} } - }, - - { /* GLOBAL_POWER_EVENTS */ - 0x06, 0x13 /* older manual says 0x05, newer 0x13 */, - { { CTR_BPU_0, MSR_P4_FSB_ESCR0}, - { CTR_BPU_2, MSR_P4_FSB_ESCR1} } - }, - - { /* TC_MS_XFER */ - 0x00, 0x05, - { { CTR_MS_0, MSR_P4_MS_ESCR0}, - { CTR_MS_2, MSR_P4_MS_ESCR1} } - }, - - { /* UOP_QUEUE_WRITES */ - 0x00, 0x09, - { { CTR_MS_0, MSR_P4_MS_ESCR0}, - { CTR_MS_2, MSR_P4_MS_ESCR1} } - }, - - { /* FRONT_END_EVENT */ - 0x05, 0x08, - { { CTR_IQ_4, MSR_P4_CRU_ESCR2}, - { CTR_IQ_5, MSR_P4_CRU_ESCR3} } - }, - - { /* EXECUTION_EVENT */ - 0x05, 0x0c, - { { CTR_IQ_4, MSR_P4_CRU_ESCR2}, - { CTR_IQ_5, MSR_P4_CRU_ESCR3} } - }, - - { /* REPLAY_EVENT */ - 0x05, 0x09, - { { CTR_IQ_4, MSR_P4_CRU_ESCR2}, - { CTR_IQ_5, MSR_P4_CRU_ESCR3} } - }, - - { /* INSTR_RETIRED */ - 0x04, 0x02, - { { CTR_IQ_4, MSR_P4_CRU_ESCR0}, - { CTR_IQ_5, MSR_P4_CRU_ESCR1} } - }, - - { /* UOPS_RETIRED */ - 0x04, 0x01, - { { CTR_IQ_4, MSR_P4_CRU_ESCR0}, - { CTR_IQ_5, MSR_P4_CRU_ESCR1} } - }, - - { /* UOP_TYPE */ - 0x02, 0x02, - { { CTR_IQ_4, MSR_P4_RAT_ESCR0}, - { CTR_IQ_5, MSR_P4_RAT_ESCR1} } - }, - - { /* RETIRED_MISPRED_BRANCH_TYPE */ - 0x02, 0x05, - { { CTR_MS_0, MSR_P4_TBPU_ESCR0}, - { CTR_MS_2, MSR_P4_TBPU_ESCR1} } - }, - - { /* RETIRED_BRANCH_TYPE */ - 0x02, 0x04, - { { CTR_MS_0, MSR_P4_TBPU_ESCR0}, - { CTR_MS_2, MSR_P4_TBPU_ESCR1} } - } -}; - - -#define MISC_PMC_ENABLED_P(x) ((x) & 1ULL << 7) - -#define ESCR_RESERVED_BITS 0x80000003ULL -#define ESCR_CLEAR(escr) ((escr) &= ESCR_RESERVED_BITS) -#define ESCR_SET_USR_0(escr, usr) ((escr) |= (((usr) & 1ULL) << 2)) -#define ESCR_SET_OS_0(escr, os) ((escr) |= (((os) & 1ULL) << 3)) -#define ESCR_SET_USR_1(escr, usr) ((escr) |= (((usr) & 1ULL))) -#define ESCR_SET_OS_1(escr, os) ((escr) |= (((os) & 1ULL) << 1)) -#define ESCR_SET_EVENT_SELECT(escr, sel) ((escr) |= (((sel) & 0x3fULL) << 25)) -#define ESCR_SET_EVENT_MASK(escr, mask) ((escr) |= (((mask) & 0xffffULL) << 9)) -#define ESCR_READ(escr,ev,i) do {rdmsrl(ev->bindings[(i)].escr_address, (escr));} while (0) -#define ESCR_WRITE(escr,ev,i) do {wrmsrl(ev->bindings[(i)].escr_address, (escr));} while (0) - -#define CCCR_RESERVED_BITS 0x38030FFFULL -#define CCCR_CLEAR(cccr) ((cccr) &= CCCR_RESERVED_BITS) -#define CCCR_SET_REQUIRED_BITS(cccr) ((cccr) |= 0x00030000ULL) -#define CCCR_SET_ESCR_SELECT(cccr, sel) ((cccr) |= (((sel) & 0x07ULL) << 13)) -#define CCCR_SET_PMI_OVF_0(cccr) ((cccr) |= (1ULL<<26)) -#define CCCR_SET_PMI_OVF_1(cccr) ((cccr) |= (1ULL<<27)) -#define CCCR_SET_ENABLE(cccr) ((cccr) |= (1ULL<<12)) -#define CCCR_SET_DISABLE(cccr) ((cccr) &= ~(1ULL<<12)) -#define CCCR_READ(msr_content, i) do {rdmsrl(p4_counters[(i)].cccr_address, (msr_content));} while (0) -#define CCCR_WRITE(msr_content, i) do {wrmsrl(p4_counters[(i)].cccr_address, (msr_content));} while (0) -#define CCCR_OVF_P(cccr) ((cccr) & (1ULL<<31)) -#define CCCR_CLEAR_OVF(cccr) ((cccr) &= (~(1ULL<<31))) - -#define CTR_READ(msr_content,i) do {rdmsrl(p4_counters[(i)].counter_address, (msr_content));} while (0) -#define CTR_WRITE(msr_content,i) do {wrmsrl(p4_counters[(i)].counter_address, -(msr_content));} while (0) -#define CTR_OVERFLOW_P(ctr) (!((ctr) & 0x80000000ULL)) - - -/* this assigns a "stagger" to the current CPU, which is used throughout - the code in this module as an extra array offset, to select the "even" - or "odd" part of all the divided resources. */ -static unsigned int get_stagger(void) -{ - int cpu = smp_processor_id(); - return (cpu != cpumask_first(per_cpu(cpu_sibling_mask, cpu))); -} - - -/* finally, mediate access to a real hardware counter - by passing a "virtual" counter numer to this macro, - along with your stagger setting. */ -#define VIRT_CTR(stagger, i) ((i) + ((num_counters) * (stagger))) - -static unsigned long reset_value[NUM_COUNTERS_NON_HT]; - - -static void cf_check p4_fill_in_addresses(struct op_msrs * const msrs) -{ - unsigned int i; - unsigned int addr, stag; - - setup_num_counters(); - stag = get_stagger(); - - /* the counter registers we pay attention to */ - for (i = 0; i < num_counters; ++i) { - msrs->counters[i].addr = - p4_counters[VIRT_CTR(stag, i)].counter_address; - } - - /* FIXME: bad feeling, we don't save the 10 counters we don't use. */ - - /* 18 CCCR registers */ - for (i = 0, addr = MSR_P4_BPU_CCCR0 + stag; - addr <= MSR_P4_IQ_CCCR5; ++i, addr += addr_increment()) { - msrs->controls[i].addr = addr; - } - - /* 43 ESCR registers in three or four discontiguous group */ - for (addr = MSR_P4_BSU_ESCR0 + stag; - addr < MSR_P4_IQ_ESCR0; ++i, addr += addr_increment()) { - msrs->controls[i].addr = addr; - } - - /* no IQ_ESCR0/1 on some models, we save a seconde time BSU_ESCR0/1 - * to avoid special case in nmi_{save|restore}_registers() */ - if (boot_cpu_data.x86_model >= 0x3) { - for (addr = MSR_P4_BSU_ESCR0 + stag; - addr <= MSR_P4_BSU_ESCR1; ++i, addr += addr_increment()) { - msrs->controls[i].addr = addr; - } - } else { - for (addr = MSR_P4_IQ_ESCR0 + stag; - addr <= MSR_P4_IQ_ESCR1; ++i, addr += addr_increment()) { - msrs->controls[i].addr = addr; - } - } - - for (addr = MSR_P4_RAT_ESCR0 + stag; - addr <= MSR_P4_SSU_ESCR0; ++i, addr += addr_increment()) { - msrs->controls[i].addr = addr; - } - - for (addr = MSR_P4_MS_ESCR0 + stag; - addr <= MSR_P4_TC_ESCR1; ++i, addr += addr_increment()) { - msrs->controls[i].addr = addr; - } - - for (addr = MSR_P4_IX_ESCR0 + stag; - addr <= MSR_P4_CRU_ESCR3; ++i, addr += addr_increment()) { - msrs->controls[i].addr = addr; - } - - /* there are 2 remaining non-contiguously located ESCRs */ - - if (num_counters == NUM_COUNTERS_NON_HT) { - /* standard non-HT CPUs handle both remaining ESCRs*/ - msrs->controls[i++].addr = MSR_P4_CRU_ESCR5; - msrs->controls[i++].addr = MSR_P4_CRU_ESCR4; - - } else if (stag == 0) { - /* HT CPUs give the first remainder to the even thread, as - the 32nd control register */ - msrs->controls[i++].addr = MSR_P4_CRU_ESCR4; - - } else { - /* and two copies of the second to the odd thread, - for the 22st and 23nd control registers */ - msrs->controls[i++].addr = MSR_P4_CRU_ESCR5; - msrs->controls[i++].addr = MSR_P4_CRU_ESCR5; - } -} - - -static void pmc_setup_one_p4_counter(unsigned int ctr) -{ - int i; - int const maxbind = 2; - uint64_t cccr = 0; - uint64_t escr = 0; - unsigned int counter_bit; - const struct p4_event_binding *ev = NULL; - unsigned int stag; - - stag = get_stagger(); - - /* convert from counter *number* to counter *bit* */ - counter_bit = 1 << VIRT_CTR(stag, ctr); - - /* find our event binding structure. */ - if (counter_config[ctr].event <= 0 || counter_config[ctr].event > NUM_EVENTS) { - printk(KERN_ERR "oprofile: P4 event code %#lx out of range\n", - counter_config[ctr].event); - return; - } - - ev = &(p4_events[counter_config[ctr].event - 1]); - - for (i = 0; i < maxbind; i++) { - if (ev->bindings[i].virt_counter & counter_bit) { - - /* modify ESCR */ - ESCR_READ(escr, ev, i); - ESCR_CLEAR(escr); - if (stag == 0) { - ESCR_SET_USR_0(escr, counter_config[ctr].user); - ESCR_SET_OS_0(escr, counter_config[ctr].kernel); - } else { - ESCR_SET_USR_1(escr, counter_config[ctr].user); - ESCR_SET_OS_1(escr, counter_config[ctr].kernel); - } - ESCR_SET_EVENT_SELECT(escr, ev->event_select); - ESCR_SET_EVENT_MASK(escr, counter_config[ctr].unit_mask); - ESCR_WRITE(escr, ev, i); - - /* modify CCCR */ - CCCR_READ(cccr, VIRT_CTR(stag, ctr)); - CCCR_CLEAR(cccr); - CCCR_SET_REQUIRED_BITS(cccr); - CCCR_SET_ESCR_SELECT(cccr, ev->escr_select); - if (stag == 0) { - CCCR_SET_PMI_OVF_0(cccr); - } else { - CCCR_SET_PMI_OVF_1(cccr); - } - CCCR_WRITE(cccr, VIRT_CTR(stag, ctr)); - return; - } - } - - printk(KERN_ERR - "oprofile: P4 event code %#lx no binding, stag %d ctr %d\n", - counter_config[ctr].event, stag, ctr); -} - - -static void cf_check p4_setup_ctrs(struct op_msrs const * const msrs) -{ - unsigned int i; - uint64_t msr_content; - unsigned int addr; - unsigned int stag; - - stag = get_stagger(); - - rdmsrl(MSR_IA32_MISC_ENABLE, msr_content); - if (! MISC_PMC_ENABLED_P(msr_content)) { - printk(KERN_ERR "oprofile: P4 PMC not available\n"); - return; - } - - /* clear the cccrs we will use */ - for (i = 0 ; i < num_counters ; i++) { - rdmsrl(p4_counters[VIRT_CTR(stag, i)].cccr_address, msr_content); - CCCR_CLEAR(msr_content); - CCCR_SET_REQUIRED_BITS(msr_content); - wrmsrl(p4_counters[VIRT_CTR(stag, i)].cccr_address, msr_content); - } - - /* clear cccrs outside our concern */ - for (i = stag ; i < NUM_UNUSED_CCCRS ; i += addr_increment()) { - rdmsrl(p4_unused_cccr[i], msr_content); - CCCR_CLEAR(msr_content); - CCCR_SET_REQUIRED_BITS(msr_content); - wrmsrl(p4_unused_cccr[i], msr_content); - } - - /* clear all escrs (including those outside our concern) */ - for (addr = MSR_P4_BSU_ESCR0 + stag; - addr < MSR_P4_IQ_ESCR0; addr += addr_increment()) { - wrmsrl(addr, 0x0ULL); - } - - /* On older models clear also MSR_P4_IQ_ESCR0/1 */ - if (boot_cpu_data.x86_model < 0x3) { - wrmsrl(MSR_P4_IQ_ESCR0, 0x0ULL); - wrmsrl(MSR_P4_IQ_ESCR1, 0x0ULL); - } - - for (addr = MSR_P4_RAT_ESCR0 + stag; - addr <= MSR_P4_SSU_ESCR0; ++i, addr += addr_increment()) { - wrmsrl(addr, 0x0ULL); - } - - for (addr = MSR_P4_MS_ESCR0 + stag; - addr <= MSR_P4_TC_ESCR1; addr += addr_increment()){ - wrmsrl(addr, 0x0ULL); - } - - for (addr = MSR_P4_IX_ESCR0 + stag; - addr <= MSR_P4_CRU_ESCR3; addr += addr_increment()){ - wrmsrl(addr, 0x0ULL); - } - - if (num_counters == NUM_COUNTERS_NON_HT) { - wrmsrl(MSR_P4_CRU_ESCR4, 0x0ULL); - wrmsrl(MSR_P4_CRU_ESCR5, 0x0ULL); - } else if (stag == 0) { - wrmsrl(MSR_P4_CRU_ESCR4, 0x0ULL); - } else { - wrmsrl(MSR_P4_CRU_ESCR5, 0x0ULL); - } - - /* setup all counters */ - for (i = 0 ; i < num_counters ; ++i) { - if (counter_config[i].enabled) { - reset_value[i] = counter_config[i].count; - pmc_setup_one_p4_counter(i); - CTR_WRITE(counter_config[i].count, VIRT_CTR(stag, i)); - } else { - reset_value[i] = 0; - } - } -} - -static int cf_check p4_check_ctrs( - unsigned int const cpu, struct op_msrs const * const msrs, - struct cpu_user_regs const * const regs) -{ - unsigned long ctr, stag, real; - uint64_t msr_content; - int i; - int ovf = 0; - unsigned long eip = regs->rip; - int mode = xenoprofile_get_mode(current, regs); - - stag = get_stagger(); - - for (i = 0; i < num_counters; ++i) { - - if (!reset_value[i]) - continue; - - /* - * there is some eccentricity in the hardware which - * requires that we perform 2 extra corrections: - * - * - check both the CCCR:OVF flag for overflow and the - * counter high bit for un-flagged overflows. - * - * - write the counter back twice to ensure it gets - * updated properly. - * - * the former seems to be related to extra NMIs happening - * during the current NMI; the latter is reported as errata - * N15 in intel doc 249199-029, pentium 4 specification - * update, though their suggested work-around does not - * appear to solve the problem. - */ - - real = VIRT_CTR(stag, i); - - CCCR_READ(msr_content, real); - CTR_READ(ctr, real); - if (CCCR_OVF_P(msr_content) || CTR_OVERFLOW_P(ctr)) { - xenoprof_log_event(current, regs, eip, mode, i); - CTR_WRITE(reset_value[i], real); - CCCR_CLEAR_OVF(msr_content); - CCCR_WRITE(msr_content, real); - CTR_WRITE(reset_value[i], real); - ovf = 1; - } - } - - /* P4 quirk: you have to re-unmask the apic vector */ - apic_write(APIC_LVTPC, apic_read(APIC_LVTPC) & ~APIC_LVT_MASKED); - - return ovf; -} - - -static void cf_check p4_start(struct op_msrs const * const msrs) -{ - unsigned int stag; - uint64_t msr_content; - int i; - - stag = get_stagger(); - - for (i = 0; i < num_counters; ++i) { - if (!reset_value[i]) - continue; - CCCR_READ(msr_content, VIRT_CTR(stag, i)); - CCCR_SET_ENABLE(msr_content); - CCCR_WRITE(msr_content, VIRT_CTR(stag, i)); - } -} - - -static void cf_check p4_stop(struct op_msrs const * const msrs) -{ - unsigned int stag; - uint64_t msr_content; - int i; - - stag = get_stagger(); - - for (i = 0; i < num_counters; ++i) { - CCCR_READ(msr_content, VIRT_CTR(stag, i)); - CCCR_SET_DISABLE(msr_content); - CCCR_WRITE(msr_content, VIRT_CTR(stag, i)); - } -} - - -struct op_x86_model_spec const op_p4_ht2_spec = { - .num_counters = NUM_COUNTERS_HT2, - .num_controls = NUM_CONTROLS_HT2, - .fill_in_addresses = &p4_fill_in_addresses, - .setup_ctrs = &p4_setup_ctrs, - .check_ctrs = &p4_check_ctrs, - .start = &p4_start, - .stop = &p4_stop -}; - - -struct op_x86_model_spec const op_p4_spec = { - .num_counters = NUM_COUNTERS_NON_HT, - .num_controls = NUM_CONTROLS_NON_HT, - .fill_in_addresses = &p4_fill_in_addresses, - .setup_ctrs = &p4_setup_ctrs, - .check_ctrs = &p4_check_ctrs, - .start = &p4_start, - .stop = &p4_stop -}; diff --git a/xen/arch/x86/oprofile/op_model_ppro.c b/xen/arch/x86/oprofile/op_model_ppro.c deleted file mode 100644 index 4bbb4502c7da..000000000000 --- a/xen/arch/x86/oprofile/op_model_ppro.c +++ /dev/null @@ -1,348 +0,0 @@ -/** - * @file op_model_ppro.h - * pentium pro / P6 model-specific MSR operations - * - * @remark Copyright 2002 OProfile authors - * @remark Read the file COPYING - * - * @author John Levon - * @author Philippe Elie - * @author Graydon Hoare - */ - -#include -#include -#include -#include - -#include -#include -#include -#include -#include -#include -#include - -#include "op_x86_model.h" -#include "op_counter.h" - -struct arch_msr_pair { - u64 counter; - u64 control; -}; - -/* - * Intel "Architectural Performance Monitoring" CPUID - * detection/enumeration details: - */ -union cpuid10_eax { - struct { - unsigned int version_id:8; - unsigned int num_counters:8; - unsigned int bit_width:8; - unsigned int mask_length:8; - } split; - unsigned int full; -}; - -static int num_counters = 2; -static int counter_width = 32; - -#define CTR_OVERFLOWED(n) (!((n) & (1ULL<<(counter_width-1)))) - -#define CTRL_READ(msr_content,msrs,c) do {rdmsrl((msrs->controls[(c)].addr), (msr_content));} while (0) -#define CTRL_WRITE(msr_content,msrs,c) do {wrmsrl((msrs->controls[(c)].addr), (msr_content));} while (0) -#define CTRL_SET_ACTIVE(n) (n |= (1ULL<<22)) -#define CTRL_SET_INACTIVE(n) (n &= ~(1ULL<<22)) -#define CTRL_CLEAR(x) (x &= (1ULL<<21)) -#define CTRL_SET_ENABLE(val) (val |= 1ULL<<20) -#define CTRL_SET_USR(val,u) (val |= ((u & 1ULL) << 16)) -#define CTRL_SET_KERN(val,k) (val |= ((k & 1ULL) << 17)) -#define CTRL_SET_UM(val, m) (val |= (m << 8)) -#define CTRL_SET_EVENT(val, e) (val |= e) -#define IS_ACTIVE(val) (val & (1ULL << 22) ) -#define IS_ENABLE(val) (val & (1ULL << 20) ) -static unsigned long reset_value[OP_MAX_COUNTER]; -int ppro_has_global_ctrl = 0; - -static void cf_check ppro_fill_in_addresses(struct op_msrs * const msrs) -{ - int i; - - for (i = 0; i < num_counters; i++) - msrs->counters[i].addr = MSR_P6_PERFCTR(i); - for (i = 0; i < num_counters; i++) - msrs->controls[i].addr = MSR_P6_EVNTSEL(i); -} - - -static void cf_check ppro_setup_ctrs(struct op_msrs const * const msrs) -{ - uint64_t msr_content; - int i; - - if (cpu_has_arch_perfmon) { - union cpuid10_eax eax; - eax.full = cpuid_eax(0xa); - - /* - * For Core2 (family 6, model 15), don't reset the - * counter width: - */ - if (!(eax.split.version_id == 0 && - current_cpu_data.x86 == 6 && - current_cpu_data.x86_model == 15)) { - - if (counter_width < eax.split.bit_width) - counter_width = eax.split.bit_width; - } - } - - /* clear all counters */ - for (i = 0 ; i < num_counters; ++i) { - CTRL_READ(msr_content, msrs, i); - CTRL_CLEAR(msr_content); - CTRL_WRITE(msr_content, msrs, i); - } - - /* avoid a false detection of ctr overflows in NMI handler */ - for (i = 0; i < num_counters; ++i) - wrmsrl(msrs->counters[i].addr, ~0x0ULL); - - /* enable active counters */ - for (i = 0; i < num_counters; ++i) { - if (counter_config[i].enabled) { - reset_value[i] = counter_config[i].count; - - wrmsrl(msrs->counters[i].addr, -reset_value[i]); - - CTRL_READ(msr_content, msrs, i); - CTRL_CLEAR(msr_content); - CTRL_SET_ENABLE(msr_content); - CTRL_SET_USR(msr_content, counter_config[i].user); - CTRL_SET_KERN(msr_content, counter_config[i].kernel); - CTRL_SET_UM(msr_content, counter_config[i].unit_mask); - CTRL_SET_EVENT(msr_content, counter_config[i].event); - CTRL_WRITE(msr_content, msrs, i); - } else { - reset_value[i] = 0; - } - } -} - -static int cf_check ppro_check_ctrs( - unsigned int const cpu, struct op_msrs const * const msrs, - struct cpu_user_regs const * const regs) -{ - u64 val; - int i; - int ovf = 0; - unsigned long eip = regs->rip; - int mode = xenoprofile_get_mode(current, regs); - struct arch_msr_pair *msrs_content = vcpu_vpmu(current)->context; - - for (i = 0 ; i < num_counters; ++i) { - if (!reset_value[i]) - continue; - rdmsrl(msrs->counters[i].addr, val); - if (CTR_OVERFLOWED(val)) { - xenoprof_log_event(current, regs, eip, mode, i); - wrmsrl(msrs->counters[i].addr, -reset_value[i]); - if ( is_passive(current->domain) && (mode != 2) && - vpmu_is_set(vcpu_vpmu(current), - VPMU_PASSIVE_DOMAIN_ALLOCATED) ) - { - if ( IS_ACTIVE(msrs_content[i].control) ) - { - msrs_content[i].counter = val; - if ( IS_ENABLE(msrs_content[i].control) ) - ovf = 2; - } - } - if ( !ovf ) - ovf = 1; - } - } - - /* Only P6 based Pentium M need to re-unmask the apic vector but it - * doesn't hurt other P6 variant */ - apic_write(APIC_LVTPC, apic_read(APIC_LVTPC) & ~APIC_LVT_MASKED); - - return ovf; -} - - -static void cf_check ppro_start(struct op_msrs const * const msrs) -{ - uint64_t msr_content; - int i; - - for (i = 0; i < num_counters; ++i) { - if (reset_value[i]) { - CTRL_READ(msr_content, msrs, i); - CTRL_SET_ACTIVE(msr_content); - CTRL_WRITE(msr_content, msrs, i); - } - } - /* Global Control MSR is enabled by default when system power on. - * However, this may not hold true when xenoprof starts to run. - */ - if ( ppro_has_global_ctrl ) - wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, (1ULL<= MSR_IA32_PERFCTR0) && - (msr_index < (MSR_IA32_PERFCTR0 + num_counters)) ) - { - *type = MSR_TYPE_ARCH_COUNTER; - *index = msr_index - MSR_IA32_PERFCTR0; - return 1; - } - if ( (msr_index >= MSR_P6_EVNTSEL(0)) && - (msr_index < (MSR_P6_EVNTSEL(num_counters))) ) - { - *type = MSR_TYPE_ARCH_CTRL; - *index = msr_index - MSR_P6_EVNTSEL(0); - return 1; - } - - return 0; -} - -static int cf_check ppro_allocate_msr(struct vcpu *v) -{ - struct vpmu_struct *vpmu = vcpu_vpmu(v); - struct arch_msr_pair *msr_content; - - msr_content = xvzalloc_array(struct arch_msr_pair, num_counters); - if ( !msr_content ) - goto out; - vpmu->context = (void *)msr_content; - vpmu_clear(vpmu); - vpmu_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED); - return 1; -out: - printk(XENLOG_G_WARNING "Insufficient memory for oprofile," - " oprofile is unavailable on dom%d vcpu%d\n", - v->vcpu_id, v->domain->domain_id); - return 0; -} - -static void cf_check ppro_free_msr(struct vcpu *v) -{ - struct vpmu_struct *vpmu = vcpu_vpmu(v); - - if ( !vpmu_is_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED) ) - return; - XVFREE(vpmu->context); - vpmu_reset(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED); -} - -static void cf_check ppro_load_msr( - struct vcpu *v, int type, int index, u64 *msr_content) -{ - struct arch_msr_pair *msrs = vcpu_vpmu(v)->context; - switch ( type ) - { - case MSR_TYPE_ARCH_COUNTER: - *msr_content = msrs[index].counter; - break; - case MSR_TYPE_ARCH_CTRL: - *msr_content = msrs[index].control; - break; - } -} - -static void cf_check ppro_save_msr( - struct vcpu *v, int type, int index, u64 msr_content) -{ - struct arch_msr_pair *msrs = vcpu_vpmu(v)->context; - - switch ( type ) - { - case MSR_TYPE_ARCH_COUNTER: - msrs[index].counter = msr_content; - break; - case MSR_TYPE_ARCH_CTRL: - msrs[index].control = msr_content; - break; - } -} - -/* - * Architectural performance monitoring. - * - * Newer Intel CPUs (Core1+) have support for architectural - * events described in CPUID 0xA. See the IA32 SDM Vol3b.18 for details. - * The advantage of this is that it can be done without knowing about - * the specific CPU. - */ -void arch_perfmon_setup_counters(void) -{ - union cpuid10_eax eax; - - eax.full = cpuid_eax(0xa); - - /* Workaround for BIOS bugs in 6/15. Taken from perfmon2 */ - if (eax.split.version_id == 0 && current_cpu_data.x86 == 6 && - current_cpu_data.x86_model == 15) { - eax.split.version_id = 2; - eax.split.num_counters = 2; - eax.split.bit_width = 40; - } - - num_counters = min_t(u8, eax.split.num_counters, OP_MAX_COUNTER); - - op_arch_perfmon_spec.num_counters = num_counters; - op_arch_perfmon_spec.num_controls = num_counters; - op_ppro_spec.num_counters = num_counters; - op_ppro_spec.num_controls = num_counters; -} - -struct op_x86_model_spec __read_mostly op_ppro_spec = { - .num_counters = 2, - .num_controls = 2, - .fill_in_addresses = &ppro_fill_in_addresses, - .setup_ctrs = &ppro_setup_ctrs, - .check_ctrs = &ppro_check_ctrs, - .start = &ppro_start, - .stop = &ppro_stop, - .is_arch_pmu_msr = &ppro_is_arch_pmu_msr, - .allocated_msr = &ppro_allocate_msr, - .free_msr = &ppro_free_msr, - .load_msr = &ppro_load_msr, - .save_msr = &ppro_save_msr -}; - -struct op_x86_model_spec __read_mostly op_arch_perfmon_spec = { - /* num_counters/num_controls filled in at runtime */ - .fill_in_addresses = &ppro_fill_in_addresses, - .setup_ctrs = &ppro_setup_ctrs, - .check_ctrs = &ppro_check_ctrs, - .start = &ppro_start, - .stop = &ppro_stop, - .is_arch_pmu_msr = &ppro_is_arch_pmu_msr, - .allocated_msr = &ppro_allocate_msr, - .free_msr = &ppro_free_msr, - .load_msr = &ppro_load_msr, - .save_msr = &ppro_save_msr -}; diff --git a/xen/arch/x86/oprofile/op_x86_model.h b/xen/arch/x86/oprofile/op_x86_model.h deleted file mode 100644 index 35bc3c1e222c..000000000000 --- a/xen/arch/x86/oprofile/op_x86_model.h +++ /dev/null @@ -1,58 +0,0 @@ -/** - * @file op_x86_model.h - * interface to x86 model-specific MSR operations - * - * @remark Copyright 2002 OProfile authors - * @remark Read the file COPYING - * - * @author Graydon Hoare - */ - -#ifndef OP_X86_MODEL_H -#define OP_X86_MODEL_H - -struct op_msr { - unsigned long addr; - uint64_t value; -}; - -struct op_msrs { - struct op_msr * counters; - struct op_msr * controls; -}; - -struct pt_regs; - -/* The model vtable abstracts the differences between - * various x86 CPU model's perfctr support. - */ -struct op_x86_model_spec { - unsigned int num_counters; - unsigned int num_controls; - void (*fill_in_addresses)(struct op_msrs * const msrs); - void (*setup_ctrs)(struct op_msrs const * const msrs); - int (*check_ctrs)(unsigned int const cpu, - struct op_msrs const * const msrs, - struct cpu_user_regs const * const regs); - void (*start)(struct op_msrs const * const msrs); - void (*stop)(struct op_msrs const * const msrs); - int (*is_arch_pmu_msr)(u64 msr_index, int *type, int *index); - int (*allocated_msr)(struct vcpu *v); - void (*free_msr)(struct vcpu *v); - void (*load_msr)(struct vcpu * const v, int type, int index, u64 *msr_content); - void (*save_msr)(struct vcpu * const v, int type, int index, u64 msr_content); -}; - -extern struct op_x86_model_spec op_ppro_spec; -extern struct op_x86_model_spec op_arch_perfmon_spec; -extern struct op_x86_model_spec const op_p4_spec; -extern struct op_x86_model_spec const op_p4_ht2_spec; -extern struct op_x86_model_spec const op_athlon_spec; -extern struct op_x86_model_spec const op_amd_fam15h_spec; - -void arch_perfmon_setup_counters(void); - -extern int ppro_has_global_ctrl; -extern struct op_x86_model_spec const *model; - -#endif /* OP_X86_MODEL_H */ diff --git a/xen/arch/x86/oprofile/xenoprof.c b/xen/arch/x86/oprofile/xenoprof.c deleted file mode 100644 index 7f2525bfb4d6..000000000000 --- a/xen/arch/x86/oprofile/xenoprof.c +++ /dev/null @@ -1,106 +0,0 @@ -/* - * Copyright (C) 2005 Hewlett-Packard Co. - * written by Aravind Menon & Jose Renato Santos - * (email: xenoprof@groups.hp.com) - * - * Copyright (c) 2006 Isaku Yamahata - * VA Linux Systems Japan K.K. - * x86 specific part - */ - -#include -#include -#include -#include - -#include "op_counter.h" - -int xenoprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg) -{ - struct xenoprof_counter counter; - - if ( copy_from_guest(&counter, arg, 1) ) - return -EFAULT; - - if ( counter.ind >= OP_MAX_COUNTER ) - return -E2BIG; - - counter_config[counter.ind].count = counter.count; - counter_config[counter.ind].enabled = counter.enabled; - counter_config[counter.ind].event = counter.event; - counter_config[counter.ind].kernel = counter.kernel; - counter_config[counter.ind].user = counter.user; - counter_config[counter.ind].unit_mask = counter.unit_mask; - - return 0; -} - -int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE_PARAM(void) arg) -{ - struct xenoprof_ibs_counter ibs_counter; - - if ( copy_from_guest(&ibs_counter, arg, 1) ) - return -EFAULT; - - ibs_config.op_enabled = ibs_counter.op_enabled; - ibs_config.fetch_enabled = ibs_counter.fetch_enabled; - ibs_config.max_cnt_fetch = ibs_counter.max_cnt_fetch; - ibs_config.max_cnt_op = ibs_counter.max_cnt_op; - ibs_config.rand_en = ibs_counter.rand_en; - ibs_config.dispatched_ops = ibs_counter.dispatched_ops; - - return 0; -} - -#ifdef CONFIG_COMPAT -#include - -int compat_oprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg) -{ - struct compat_oprof_counter counter; - - if ( copy_from_guest(&counter, arg, 1) ) - return -EFAULT; - - if ( counter.ind >= OP_MAX_COUNTER ) - return -E2BIG; - - counter_config[counter.ind].count = counter.count; - counter_config[counter.ind].enabled = counter.enabled; - counter_config[counter.ind].event = counter.event; - counter_config[counter.ind].kernel = counter.kernel; - counter_config[counter.ind].user = counter.user; - counter_config[counter.ind].unit_mask = counter.unit_mask; - - return 0; -} -#endif - -int xenoprofile_get_mode(struct vcpu *curr, const struct cpu_user_regs *regs) -{ - if ( !guest_mode(regs) ) - return 2; - - if ( !is_hvm_vcpu(curr) ) - return guest_kernel_mode(curr, regs); - - switch ( hvm_guest_x86_mode(curr) ) - { - case X86_MODE_REAL: - return 1; - case X86_MODE_VM86: - return 0; - default: /* 16BIT | 32BIT | 64BIT */ - return hvm_get_cpl(curr) != 3; - } -} - -/* - * Local variables: - * mode: C - * c-file-style: "BSD" - * c-basic-offset: 4 - * tab-width: 4 - * indent-tabs-mode: nil - * End: - */ diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index 6ba7ae5202ca..f621b99a5fcc 100644 --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -50,7 +50,6 @@ #include #include #include -#include /* * opt_nmi: one of 'ignore', 'dom0', or 'fatal'. @@ -1943,9 +1942,6 @@ bool nmi_check_continuation(void) if ( pci_serr_nmicont() ) ret = true; - if ( nmi_oprofile_send_virq() ) - ret = true; - return ret; } diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 401d5046f6f5..38320b248a90 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -374,17 +374,6 @@ config EFI_SET_VIRTUAL_ADDRESS_MAP If unsure, say N. -config XENOPROF - bool "Xen Oprofile Support" if EXPERT - depends on X86 - help - Xen OProfile (Xenoprof) is a system-wide profiler for Xen virtual - machine environments, capable of profiling the Xen virtual machine - monitor, multiple Linux guest operating systems, and applications - running on them. - - If unsure, say Y. - config XSM bool "Xen Security Modules support" default ARM diff --git a/xen/common/Makefile b/xen/common/Makefile index 8486c0b5106d..92c97d641e67 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -63,7 +63,6 @@ obj-$(CONFIG_HAS_VMAP) += vmap.o obj-y += vsprintf.o obj-y += wait.o obj-bin-y += warning.init.o -obj-$(CONFIG_XENOPROF) += xenoprof.o obj-y += xmalloc_tlsf.o obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo unlz4 unzstd earlycpio,$(n).init.o) diff --git a/xen/common/compat/xenoprof.c b/xen/common/compat/xenoprof.c deleted file mode 100644 index 8fbd86c24c01..000000000000 --- a/xen/common/compat/xenoprof.c +++ /dev/null @@ -1,42 +0,0 @@ -/* - * compat/xenoprof.c - */ - -#include - -#define COMPAT -#define ret_t int - -#define do_xenoprof_op compat_xenoprof_op - -#define xen_oprof_init xenoprof_init -CHECK_oprof_init; -#undef xen_oprof_init - -#define xenoprof_get_buffer compat_oprof_get_buffer -#define xenoprof_op_get_buffer compat_oprof_op_get_buffer -#define xenoprof_arch_counter compat_oprof_arch_counter - -#define xen_domid_t domid_t -#define compat_domid_t domid_compat_t -CHECK_TYPE(domid); -#undef compat_domid_t -#undef xen_domid_t - -#define xen_oprof_passive xenoprof_passive -CHECK_oprof_passive; -#undef xen_oprof_passive - -#define xenoprof_counter compat_oprof_counter - -#include "../xenoprof.c" - -/* - * Local variables: - * mode: C - * c-file-style: "BSD" - * c-basic-offset: 4 - * tab-width: 4 - * indent-tabs-mode: nil - * End: - */ diff --git a/xen/common/domain.c b/xen/common/domain.c index 93c71bc766b0..2f4fd844441e 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -31,7 +31,6 @@ #include #include #include -#include #include #include #include @@ -1452,11 +1451,6 @@ static void cf_check complete_domain_destroy(struct rcu_head *head) sched_destroy_domain(d); - /* Free page used by xen oprofile buffer. */ -#ifdef CONFIG_XENOPROF - free_xenoprof_pages(d); -#endif - #ifdef CONFIG_MEM_PAGING xfree(d->vm_event_paging); #endif diff --git a/xen/common/xenoprof.c b/xen/common/xenoprof.c deleted file mode 100644 index 1926a92fe481..000000000000 --- a/xen/common/xenoprof.c +++ /dev/null @@ -1,977 +0,0 @@ -/* - * Copyright (C) 2005 Hewlett-Packard Co. - * written by Aravind Menon & Jose Renato Santos - * (email: xenoprof@groups.hp.com) - * - * arch generic xenoprof and IA64 support. - * dynamic map/unmap xenoprof buffer support. - * Copyright (c) 2006 Isaku Yamahata - * VA Linux Systems Japan K.K. - */ - -#ifndef COMPAT -#include -#include -#include -#include -#include -#include -#include -#include - -/* Override macros from asm/page.h to make them work with mfn_t */ -#undef virt_to_mfn -#define virt_to_mfn(va) _mfn(__virt_to_mfn(va)) - -#define XENOPROF_DOMAIN_IGNORED 0 -#define XENOPROF_DOMAIN_ACTIVE 1 -#define XENOPROF_DOMAIN_PASSIVE 2 - -#define XENOPROF_IDLE 0 -#define XENOPROF_INITIALIZED 1 -#define XENOPROF_COUNTERS_RESERVED 2 -#define XENOPROF_READY 3 -#define XENOPROF_PROFILING 4 - -#ifndef CONFIG_COMPAT -#define XENOPROF_COMPAT(x) false -typedef struct xenoprof_buf xenoprof_buf_t; -#define xenoprof_buf(d, b, field) ACCESS_ONCE((b)->field) -#else -#include -#define XENOPROF_COMPAT(x) ((x)->is_compat) -typedef union { - struct xenoprof_buf native; - struct compat_oprof_buf compat; -} xenoprof_buf_t; -#define xenoprof_buf(d, b, field) ACCESS_ONCE(*(!(d)->xenoprof->is_compat \ - ? &(b)->native.field \ - : &(b)->compat.field)) -#endif - -/* Limit amount of pages used for shared buffer (per domain) */ -#define MAX_OPROF_SHARED_PAGES 32 - -/* Lock protecting the following global state */ -static DEFINE_SPINLOCK(xenoprof_lock); - -static DEFINE_SPINLOCK(pmu_owner_lock); -int pmu_owner = 0; -int pmu_hvm_refcount = 0; - -struct xenoprof_vcpu { - int event_size; - xenoprof_buf_t *buffer; -}; - -struct xenoprof { - char *rawbuf; - int npages; - int nbuf; - int bufsize; - int domain_type; -#ifdef CONFIG_COMPAT - bool is_compat; -#endif - struct xenoprof_vcpu *vcpu; -}; - -static struct domain *active_domains[MAX_OPROF_DOMAINS]; -static int active_ready[MAX_OPROF_DOMAINS]; -static unsigned int adomains; - -static struct domain *passive_domains[MAX_OPROF_DOMAINS]; -static unsigned int pdomains; - -static unsigned int activated; -static struct domain *xenoprof_primary_profiler; -static int xenoprof_state = XENOPROF_IDLE; -static unsigned long backtrace_depth; - -static u64 total_samples; -static u64 invalid_buffer_samples; -static u64 corrupted_buffer_samples; -static u64 lost_samples; -static u64 active_samples; -static u64 passive_samples; -static u64 idle_samples; -static u64 others_samples; - -int acquire_pmu_ownership(int pmu_ownership) -{ - spin_lock(&pmu_owner_lock); - if ( pmu_owner == PMU_OWNER_NONE ) - { - pmu_owner = pmu_ownership; - goto out; - } - - if ( pmu_owner == pmu_ownership ) - goto out; - - spin_unlock(&pmu_owner_lock); - return 0; - out: - if ( pmu_owner == PMU_OWNER_HVM ) - pmu_hvm_refcount++; - spin_unlock(&pmu_owner_lock); - return 1; -} - -void release_pmu_ownership(int pmu_ownership) -{ - spin_lock(&pmu_owner_lock); - if ( pmu_ownership == PMU_OWNER_HVM ) - pmu_hvm_refcount--; - if ( !pmu_hvm_refcount ) - pmu_owner = PMU_OWNER_NONE; - spin_unlock(&pmu_owner_lock); -} - -int is_active(struct domain *d) -{ - struct xenoprof *x = d->xenoprof; - return ((x != NULL) && (x->domain_type == XENOPROF_DOMAIN_ACTIVE)); -} - -int is_passive(struct domain *d) -{ - struct xenoprof *x = d->xenoprof; - return ((x != NULL) && (x->domain_type == XENOPROF_DOMAIN_PASSIVE)); -} - -static int is_profiled(struct domain *d) -{ - return (is_active(d) || is_passive(d)); -} - -static void xenoprof_reset_stat(void) -{ - total_samples = 0; - invalid_buffer_samples = 0; - corrupted_buffer_samples = 0; - lost_samples = 0; - active_samples = 0; - passive_samples = 0; - idle_samples = 0; - others_samples = 0; -} - -static void xenoprof_reset_buf(struct domain *d) -{ - int j; - xenoprof_buf_t *buf; - - if ( d->xenoprof == NULL ) - { - printk("xenoprof_reset_buf: ERROR - Unexpected " - "Xenoprof NULL pointer \n"); - return; - } - - for ( j = 0; j < d->max_vcpus; j++ ) - { - buf = d->xenoprof->vcpu[j].buffer; - if ( buf != NULL ) - { - xenoprof_buf(d, buf, event_head) = 0; - xenoprof_buf(d, buf, event_tail) = 0; - } - } -} - -static int -share_xenoprof_page_with_guest(struct domain *d, mfn_t mfn, int npages) -{ - int i; - - /* Check if previous page owner has released the page. */ - for ( i = 0; i < npages; i++ ) - { - struct page_info *page = mfn_to_page(mfn_add(mfn, i)); - - if ( (page->count_info & (PGC_allocated|PGC_count_mask)) != 0 ) - { - printk(XENLOG_G_INFO "dom%d mfn %#lx page->count_info %#lx\n", - d->domain_id, mfn_x(mfn_add(mfn, i)), page->count_info); - return -EBUSY; - } - page_set_owner(page, NULL); - } - - for ( i = 0; i < npages; i++ ) - share_xen_page_with_guest(mfn_to_page(mfn_add(mfn, i)), d, SHARE_rw); - - return 0; -} - -static void -unshare_xenoprof_page_with_guest(struct xenoprof *x) -{ - int i, npages = x->npages; - mfn_t mfn = virt_to_mfn(x->rawbuf); - - for ( i = 0; i < npages; i++ ) - { - struct page_info *page = mfn_to_page(mfn_add(mfn, i)); - - BUG_ON(page_get_owner(page) != current->domain); - put_page_alloc_ref(page); - } -} - -static void -xenoprof_shared_gmfn_with_guest( - struct domain *d, unsigned long maddr, unsigned long gmaddr, int npages) -{ - int i; - - for ( i = 0; i < npages; i++, maddr += PAGE_SIZE, gmaddr += PAGE_SIZE ) - { - BUG_ON(page_get_owner(maddr_to_page(maddr)) != d); - if ( i == 0 ) - gdprintk(XENLOG_WARNING, - "xenoprof unsupported with autotranslated guests\n"); - - } -} - -static int alloc_xenoprof_struct( - struct domain *d, int max_samples, int is_passive) -{ - struct vcpu *v; - int nvcpu, npages, bufsize, max_bufsize; - unsigned max_max_samples; - int i; - - nvcpu = 0; - for_each_vcpu ( d, v ) - nvcpu++; - - if ( !nvcpu ) - return -EINVAL; - - d->xenoprof = xzalloc(struct xenoprof); - if ( d->xenoprof == NULL ) - { - printk("alloc_xenoprof_struct(): memory allocation failed\n"); - return -ENOMEM; - } - - d->xenoprof->vcpu = xzalloc_array(struct xenoprof_vcpu, d->max_vcpus); - if ( d->xenoprof->vcpu == NULL ) - { - xfree(d->xenoprof); - d->xenoprof = NULL; - printk("alloc_xenoprof_struct(): vcpu array allocation failed\n"); - return -ENOMEM; - } - - bufsize = sizeof(struct xenoprof_buf); - i = sizeof(struct event_log); -#ifdef CONFIG_COMPAT - d->xenoprof->is_compat = is_pv_32bit_domain(is_passive ? hardware_domain : d); - if ( XENOPROF_COMPAT(d->xenoprof) ) - { - bufsize = sizeof(struct compat_oprof_buf); - i = sizeof(struct compat_event_log); - } -#endif - - /* reduce max_samples if necessary to limit pages allocated */ - max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / nvcpu; - max_max_samples = ( (max_bufsize - bufsize) / i ) + 1; - if ( (unsigned)max_samples > max_max_samples ) - max_samples = max_max_samples; - - bufsize += (max_samples - 1) * i; - npages = (nvcpu * bufsize - 1) / PAGE_SIZE + 1; - - d->xenoprof->rawbuf = alloc_xenheap_pages(get_order_from_pages(npages), 0); - if ( d->xenoprof->rawbuf == NULL ) - { - xfree(d->xenoprof->vcpu); - xfree(d->xenoprof); - d->xenoprof = NULL; - return -ENOMEM; - } - - for ( i = 0; i < npages; ++i ) - clear_page(d->xenoprof->rawbuf + i * PAGE_SIZE); - - d->xenoprof->npages = npages; - d->xenoprof->nbuf = nvcpu; - d->xenoprof->bufsize = bufsize; - d->xenoprof->domain_type = XENOPROF_DOMAIN_IGNORED; - - /* Update buffer pointers for active vcpus */ - i = 0; - for_each_vcpu ( d, v ) - { - xenoprof_buf_t *buf = (xenoprof_buf_t *) - &d->xenoprof->rawbuf[i * bufsize]; - - d->xenoprof->vcpu[v->vcpu_id].event_size = max_samples; - d->xenoprof->vcpu[v->vcpu_id].buffer = buf; - xenoprof_buf(d, buf, event_size) = max_samples; - xenoprof_buf(d, buf, vcpu_id) = v->vcpu_id; - - i++; - /* in the unlikely case that the number of active vcpus changes */ - if ( i >= nvcpu ) - break; - } - - return 0; -} - -void free_xenoprof_pages(struct domain *d) -{ - struct xenoprof *x; - int order; - - x = d->xenoprof; - if ( x == NULL ) - return; - - if ( x->rawbuf != NULL ) - { - order = get_order_from_pages(x->npages); - free_xenheap_pages(x->rawbuf, order); - } - - xfree(x->vcpu); - xfree(x); - d->xenoprof = NULL; -} - -static int active_index(struct domain *d) -{ - int i; - - for ( i = 0; i < adomains; i++ ) - if ( active_domains[i] == d ) - return i; - - return -1; -} - -static int set_active(struct domain *d) -{ - int ind; - struct xenoprof *x; - - ind = active_index(d); - if ( ind < 0 ) - return -EPERM; - - x = d->xenoprof; - if ( x == NULL ) - return -EPERM; - - x->domain_type = XENOPROF_DOMAIN_ACTIVE; - active_ready[ind] = 1; - activated++; - - return 0; -} - -static int reset_active(struct domain *d) -{ - int ind; - struct xenoprof *x; - - ind = active_index(d); - if ( ind < 0 ) - return -EPERM; - - x = d->xenoprof; - if ( x == NULL ) - return -EPERM; - - x->domain_type = XENOPROF_DOMAIN_IGNORED; - active_ready[ind] = 0; - active_domains[ind] = NULL; - activated--; - put_domain(d); - - if ( activated <= 0 ) - adomains = 0; - - return 0; -} - -static void reset_passive(struct domain *d) -{ - struct xenoprof *x; - - if ( d == NULL ) - return; - - x = d->xenoprof; - if ( x == NULL ) - return; - - x->domain_type = XENOPROF_DOMAIN_IGNORED; - unshare_xenoprof_page_with_guest(x); -} - -static void reset_active_list(void) -{ - int i; - - for ( i = 0; i < adomains; i++ ) - if ( active_ready[i] ) - reset_active(active_domains[i]); - - adomains = 0; - activated = 0; -} - -static void reset_passive_list(void) -{ - int i; - - for ( i = 0; i < pdomains; i++ ) - { - reset_passive(passive_domains[i]); - put_domain(passive_domains[i]); - passive_domains[i] = NULL; - } - - pdomains = 0; -} - -static int add_active_list(domid_t domid) -{ - struct domain *d; - - if ( adomains >= MAX_OPROF_DOMAINS ) - return -E2BIG; - - d = get_domain_by_id(domid); - if ( d == NULL ) - return -EINVAL; - - active_domains[adomains] = d; - active_ready[adomains] = 0; - adomains++; - - return 0; -} - -static int add_passive_list(XEN_GUEST_HANDLE_PARAM(void) arg) -{ - struct xenoprof_passive passive; - struct domain *d; - int ret = 0; - - if ( pdomains >= MAX_OPROF_DOMAINS ) - return -E2BIG; - - if ( copy_from_guest(&passive, arg, 1) ) - return -EFAULT; - - d = get_domain_by_id(passive.domain_id); - if ( d == NULL ) - return -EINVAL; - - if ( d->xenoprof == NULL ) - { - ret = alloc_xenoprof_struct(d, passive.max_samples, 1); - if ( ret < 0 ) - { - put_domain(d); - return -ENOMEM; - } - } - - ret = share_xenoprof_page_with_guest( - current->domain, virt_to_mfn(d->xenoprof->rawbuf), - d->xenoprof->npages); - if ( ret < 0 ) - { - put_domain(d); - return ret; - } - - d->xenoprof->domain_type = XENOPROF_DOMAIN_PASSIVE; - passive.nbuf = d->xenoprof->nbuf; - passive.bufsize = d->xenoprof->bufsize; - if ( !paging_mode_translate(current->domain) ) - passive.buf_gmaddr = __pa(d->xenoprof->rawbuf); - else - xenoprof_shared_gmfn_with_guest( - current->domain, __pa(d->xenoprof->rawbuf), - passive.buf_gmaddr, d->xenoprof->npages); - - if ( __copy_to_guest(arg, &passive, 1) ) - { - put_domain(d); - return -EFAULT; - } - - passive_domains[pdomains] = d; - pdomains++; - - return ret; -} - - -/* Get space in the buffer */ -static int xenoprof_buf_space(int head, int tail, int size) -{ - return ((tail > head) ? 0 : size) + tail - head - 1; -} - -/* Check for space and add a sample. Return 1 if successful, 0 otherwise. */ -static int xenoprof_add_sample(const struct domain *d, - const struct xenoprof_vcpu *v, - uint64_t eip, int mode, int event) -{ - xenoprof_buf_t *buf = v->buffer; - int head, tail, size; - - head = xenoprof_buf(d, buf, event_head); - tail = xenoprof_buf(d, buf, event_tail); - size = v->event_size; - - /* make sure indexes in shared buffer are sane */ - if ( (head < 0) || (head >= size) || (tail < 0) || (tail >= size) ) - { - corrupted_buffer_samples++; - return 0; - } - - if ( xenoprof_buf_space(head, tail, size) > 0 ) - { - xenoprof_buf(d, buf, event_log[head].eip) = eip; - xenoprof_buf(d, buf, event_log[head].mode) = mode; - xenoprof_buf(d, buf, event_log[head].event) = event; - head++; - if ( head >= size ) - head = 0; - - xenoprof_buf(d, buf, event_head) = head; - } - else - { - xenoprof_buf(d, buf, lost_samples)++; - lost_samples++; - return 0; - } - - return 1; -} - -int xenoprof_add_trace(struct vcpu *vcpu, uint64_t pc, int mode) -{ - struct domain *d = vcpu->domain; - - /* Do not accidentally write an escape code due to a broken frame. */ - if ( pc == XENOPROF_ESCAPE_CODE ) - { - invalid_buffer_samples++; - return 0; - } - - return xenoprof_add_sample(d, &d->xenoprof->vcpu[vcpu->vcpu_id], - pc, mode, 0); -} - -void xenoprof_log_event(struct vcpu *vcpu, const struct cpu_user_regs *regs, - uint64_t pc, int mode, int event) -{ - struct domain *d = vcpu->domain; - struct xenoprof_vcpu *v; - xenoprof_buf_t *buf; - - total_samples++; - - /* Ignore samples of un-monitored domains. */ - if ( !is_profiled(d) ) - { - others_samples++; - return; - } - - v = &d->xenoprof->vcpu[vcpu->vcpu_id]; - if ( v->buffer == NULL ) - { - invalid_buffer_samples++; - return; - } - - buf = v->buffer; - - /* Provide backtrace if requested. */ - if ( backtrace_depth > 0 ) - { - if ( xenoprof_buf_space(xenoprof_buf(d, buf, event_head), - xenoprof_buf(d, buf, event_tail), - v->event_size) < 2 ) - { - xenoprof_buf(d, buf, lost_samples)++; - lost_samples++; - return; - } - - /* xenoprof_add_sample() will increment lost_samples on failure */ - if ( !xenoprof_add_sample(d, v, XENOPROF_ESCAPE_CODE, mode, - XENOPROF_TRACE_BEGIN) ) - return; - } - - if ( xenoprof_add_sample(d, v, pc, mode, event) ) - { - if ( is_active(vcpu->domain) ) - active_samples++; - else - passive_samples++; - if ( mode == 0 ) - xenoprof_buf(d, buf, user_samples)++; - else if ( mode == 1 ) - xenoprof_buf(d, buf, kernel_samples)++; - else - xenoprof_buf(d, buf, xen_samples)++; - - } - - if ( backtrace_depth > 0 ) - xenoprof_backtrace(vcpu, regs, backtrace_depth, mode); -} - - - -static int xenoprof_op_init(XEN_GUEST_HANDLE_PARAM(void) arg) -{ - struct domain *d = current->domain; - struct xenoprof_init xenoprof_init; - int ret; - - if ( copy_from_guest(&xenoprof_init, arg, 1) ) - return -EFAULT; - - if ( (ret = xenoprof_arch_init(&xenoprof_init.num_events, - xenoprof_init.cpu_type)) ) - return ret; - - /* Only the hardware domain may become the primary profiler here because - * there is currently no cleanup of xenoprof_primary_profiler or associated - * profiling state when the primary profiling domain is shut down or - * crashes. Once a better cleanup method is present, it will be possible to - * allow another domain to be the primary profiler. - */ - xenoprof_init.is_primary = - ((xenoprof_primary_profiler == d) || - ((xenoprof_primary_profiler == NULL) && is_hardware_domain(d))); - if ( xenoprof_init.is_primary ) - xenoprof_primary_profiler = current->domain; - - return __copy_to_guest(arg, &xenoprof_init, 1) ? -EFAULT : 0; -} - -#define ret_t long - -#endif /* !COMPAT */ - -static int xenoprof_op_get_buffer(XEN_GUEST_HANDLE_PARAM(void) arg) -{ - struct xenoprof_get_buffer xenoprof_get_buffer; - struct domain *d = current->domain; - int ret; - - if ( copy_from_guest(&xenoprof_get_buffer, arg, 1) ) - return -EFAULT; - - /* - * We allocate xenoprof struct and buffers only at first time - * get_buffer is called. Memory is then kept until domain is destroyed. - */ - if ( d->xenoprof == NULL ) - { - ret = alloc_xenoprof_struct(d, xenoprof_get_buffer.max_samples, 0); - if ( ret < 0 ) - return ret; - } - else - d->xenoprof->domain_type = XENOPROF_DOMAIN_IGNORED; - - ret = share_xenoprof_page_with_guest( - d, virt_to_mfn(d->xenoprof->rawbuf), d->xenoprof->npages); - if ( ret < 0 ) - return ret; - - xenoprof_reset_buf(d); - - xenoprof_get_buffer.nbuf = d->xenoprof->nbuf; - xenoprof_get_buffer.bufsize = d->xenoprof->bufsize; - if ( !paging_mode_translate(d) ) - xenoprof_get_buffer.buf_gmaddr = __pa(d->xenoprof->rawbuf); - else - xenoprof_shared_gmfn_with_guest( - d, __pa(d->xenoprof->rawbuf), xenoprof_get_buffer.buf_gmaddr, - d->xenoprof->npages); - - return __copy_to_guest(arg, &xenoprof_get_buffer, 1) ? -EFAULT : 0; -} - -#define NONPRIV_OP(op) ( (op == XENOPROF_init) \ - || (op == XENOPROF_enable_virq) \ - || (op == XENOPROF_disable_virq) \ - || (op == XENOPROF_get_buffer)) - -ret_t do_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) -{ - int ret = 0; - - if ( (op < 0) || (op > XENOPROF_last_op) ) - { - gdprintk(XENLOG_DEBUG, "invalid operation %d\n", op); - return -EINVAL; - } - - if ( !NONPRIV_OP(op) && (current->domain != xenoprof_primary_profiler) ) - { - gdprintk(XENLOG_DEBUG, "denied privileged operation %d\n", op); - return -EPERM; - } - - ret = xsm_profile(XSM_HOOK, current->domain, op); - if ( ret ) - return ret; - - spin_lock(&xenoprof_lock); - - switch ( op ) - { - case XENOPROF_init: - ret = xenoprof_op_init(arg); - if ( (ret == 0) && - (current->domain == xenoprof_primary_profiler) ) - xenoprof_state = XENOPROF_INITIALIZED; - break; - - case XENOPROF_get_buffer: - if ( !acquire_pmu_ownership(PMU_OWNER_XENOPROF) ) - { - ret = -EBUSY; - break; - } - ret = xenoprof_op_get_buffer(arg); - break; - - case XENOPROF_reset_active_list: - reset_active_list(); - ret = 0; - break; - - case XENOPROF_reset_passive_list: - reset_passive_list(); - ret = 0; - break; - - case XENOPROF_set_active: - { - domid_t domid; - if ( xenoprof_state != XENOPROF_INITIALIZED ) - { - ret = -EPERM; - break; - } - if ( copy_from_guest(&domid, arg, 1) ) - { - ret = -EFAULT; - break; - } - ret = add_active_list(domid); - break; - } - - case XENOPROF_set_passive: - if ( xenoprof_state != XENOPROF_INITIALIZED ) - { - ret = -EPERM; - break; - } - ret = add_passive_list(arg); - break; - - case XENOPROF_reserve_counters: - if ( xenoprof_state != XENOPROF_INITIALIZED ) - { - ret = -EPERM; - break; - } - ret = xenoprof_arch_reserve_counters(); - if ( !ret ) - xenoprof_state = XENOPROF_COUNTERS_RESERVED; - break; - - case XENOPROF_counter: - if ( (xenoprof_state != XENOPROF_COUNTERS_RESERVED) || - (adomains == 0) ) - { - ret = -EPERM; - break; - } - ret = xenoprof_arch_counter(arg); - break; - - case XENOPROF_setup_events: - if ( xenoprof_state != XENOPROF_COUNTERS_RESERVED ) - { - ret = -EPERM; - break; - } - ret = xenoprof_arch_setup_events(); - if ( !ret ) - xenoprof_state = XENOPROF_READY; - break; - - case XENOPROF_enable_virq: - { - int i; - - if ( current->domain == xenoprof_primary_profiler ) - { - if ( xenoprof_state != XENOPROF_READY ) - { - ret = -EPERM; - break; - } - xenoprof_arch_enable_virq(); - xenoprof_reset_stat(); - for ( i = 0; i < pdomains; i++ ) - xenoprof_reset_buf(passive_domains[i]); - } - xenoprof_reset_buf(current->domain); - ret = set_active(current->domain); - break; - } - - case XENOPROF_start: - ret = -EPERM; - if ( (xenoprof_state == XENOPROF_READY) && - (activated == adomains) ) - ret = xenoprof_arch_start(); - if ( ret == 0 ) - xenoprof_state = XENOPROF_PROFILING; - break; - - case XENOPROF_stop: - { - struct domain *d; - struct vcpu *v; - int i; - - if ( xenoprof_state != XENOPROF_PROFILING ) - { - ret = -EPERM; - break; - } - xenoprof_arch_stop(); - - /* Flush remaining samples. */ - for ( i = 0; i < adomains; i++ ) - { - if ( !active_ready[i] ) - continue; - d = active_domains[i]; - for_each_vcpu(d, v) - send_guest_vcpu_virq(v, VIRQ_XENOPROF); - } - xenoprof_state = XENOPROF_READY; - break; - } - - case XENOPROF_disable_virq: - { - struct xenoprof *x; - if ( (xenoprof_state == XENOPROF_PROFILING) && - (is_active(current->domain)) ) - { - ret = -EPERM; - break; - } - if ( (ret = reset_active(current->domain)) != 0 ) - break; - x = current->domain->xenoprof; - unshare_xenoprof_page_with_guest(x); - release_pmu_ownership(PMU_OWNER_XENOPROF); - break; - } - - case XENOPROF_release_counters: - ret = -EPERM; - if ( (xenoprof_state == XENOPROF_COUNTERS_RESERVED) || - (xenoprof_state == XENOPROF_READY) ) - { - xenoprof_state = XENOPROF_INITIALIZED; - xenoprof_arch_release_counters(); - xenoprof_arch_disable_virq(); - reset_passive_list(); - ret = 0; - } - break; - - case XENOPROF_shutdown: - ret = -EPERM; - if ( xenoprof_state == XENOPROF_INITIALIZED ) - { - activated = 0; - adomains=0; - xenoprof_primary_profiler = NULL; - backtrace_depth=0; - ret = 0; - } - break; - - case XENOPROF_set_backtrace: - ret = 0; - if ( !xenoprof_backtrace_supported() ) - ret = -EINVAL; - else if ( copy_from_guest(&backtrace_depth, arg, 1) ) - ret = -EFAULT; - break; - - case XENOPROF_ibs_counter: - if ( (xenoprof_state != XENOPROF_COUNTERS_RESERVED) || - (adomains == 0) ) - { - ret = -EPERM; - break; - } - ret = xenoprof_arch_ibs_counter(arg); - break; - - case XENOPROF_get_ibs_caps: - ret = ibs_caps; - break; - - default: - ret = -ENOSYS; - } - - spin_unlock(&xenoprof_lock); - - if ( ret < 0 ) - gdprintk(XENLOG_DEBUG, "operation %d failed: %d\n", op, ret); - - return ret; -} - -#if defined(CONFIG_COMPAT) && !defined(COMPAT) -#undef ret_t -#include "compat/xenoprof.c" -#endif - -/* - * Local variables: - * mode: C - * c-file-style: "BSD" - * c-basic-offset: 4 - * tab-width: 4 - * indent-tabs-mode: nil - * End: - */ diff --git a/xen/include/Makefile b/xen/include/Makefile index e71f419e8c22..b3184a395b50 100644 --- a/xen/include/Makefile +++ b/xen/include/Makefile @@ -31,7 +31,6 @@ headers-$(CONFIG_HVM) += compat/hvm/hvm_vcpu.h headers-$(CONFIG_HYPFS) += compat/hypfs.h headers-$(CONFIG_KEXEC) += compat/kexec.h headers-$(CONFIG_TRACEBUFFER) += compat/trace.h -headers-$(CONFIG_XENOPROF) += compat/xenoprof.h headers-$(CONFIG_XSM_FLASK) += compat/xsm/flask_op.h headers-n := $(sort $(filter-out $(headers-y),$(headers-n) $(headers-))) diff --git a/xen/include/hypercall-defs.c b/xen/include/hypercall-defs.c index 5782cdfd1496..63755bb8df6e 100644 --- a/xen/include/hypercall-defs.c +++ b/xen/include/hypercall-defs.c @@ -127,9 +127,6 @@ argo_op(unsigned int cmd, void *arg1, void *arg2, unsigned long arg3, unsigned l #ifdef CONFIG_PV iret() nmi_op(unsigned int cmd, void *arg) -#ifdef CONFIG_XENOPROF -xenoprof_op(int op, void *arg) -#endif #endif /* CONFIG_PV */ #ifdef CONFIG_COMPAT @@ -269,9 +266,6 @@ xsm_op compat do compat do do nmi_op compat do - - - sched_op compat do compat do do callback_op compat do - - - -#ifdef CONFIG_XENOPROF -xenoprof_op compat do - - - -#endif event_channel_op do do do:1 do:1 do:1 physdev_op compat do hvm hvm do_arm #ifdef CONFIG_HVM diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h index 7f15204c3885..b12fd10e6315 100644 --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -106,7 +106,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t); #define __HYPERVISOR_nmi_op 28 #define __HYPERVISOR_sched_op 29 #define __HYPERVISOR_callback_op 30 -#define __HYPERVISOR_xenoprof_op 31 +#define __HYPERVISOR_xenoprof_op 31 /* Dropped in Xen 4.22 */ #define __HYPERVISOR_event_channel_op 32 #define __HYPERVISOR_physdev_op 33 #define __HYPERVISOR_hvm_op 34 diff --git a/xen/include/public/xenoprof.h b/xen/include/public/xenoprof.h index 2298b6759ed3..f97a67042e07 100644 --- a/xen/include/public/xenoprof.h +++ b/xen/include/public/xenoprof.h @@ -3,7 +3,7 @@ * xenoprof.h * * Interface for enabling system wide profiling based on hardware performance - * counters + * counters. Dropped from Xen in 4.22. * * Copyright (C) 2005 Hewlett-Packard Co. * Written by Aravind Menon & Jose Renato Santos diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index 1f77e0869b5d..dc06f6f1131a 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -573,9 +573,6 @@ struct domain /* Control-plane tools handle for this domain. */ xen_domain_handle_t handle; - /* OProfile support. */ - struct xenoprof *xenoprof; - /* Domain watchdog. */ #define NR_DOMAIN_WATCHDOG_TIMERS 2 spinlock_t watchdog_lock; diff --git a/xen/include/xen/xenoprof.h b/xen/include/xen/xenoprof.h deleted file mode 100644 index c3dac447d334..000000000000 --- a/xen/include/xen/xenoprof.h +++ /dev/null @@ -1,49 +0,0 @@ -/****************************************************************************** - * xenoprof.h - * - * Xenoprof: Xenoprof enables performance profiling in Xen - * - * Copyright (C) 2005 Hewlett-Packard Co. - * written by Aravind Menon & Jose Renato Santos - */ - -#ifndef __XEN_XENOPROF_H__ -#define __XEN_XENOPROF_H__ - -#define PMU_OWNER_NONE 0 -#define PMU_OWNER_XENOPROF 1 -#define PMU_OWNER_HVM 2 - -#ifdef CONFIG_XENOPROF - -#include -#include - -struct domain; -struct vcpu; -struct cpu_user_regs; - -int acquire_pmu_ownership(int pmu_ownership); -void release_pmu_ownership(int pmu_ownership); - -int is_active(struct domain *d); -int is_passive(struct domain *d); -void free_xenoprof_pages(struct domain *d); - -int xenoprof_add_trace(struct vcpu *, uint64_t pc, int mode); - -void xenoprof_log_event(struct vcpu *, const struct cpu_user_regs *, - uint64_t pc, int mode, int event); - -#else -static inline int acquire_pmu_ownership(int pmu_ownership) -{ - return 1; -} - -static inline void release_pmu_ownership(int pmu_ownership) -{ -} -#endif /* CONFIG_XENOPROF */ - -#endif /* __XEN__XENOPROF_H__ */ diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h index e801dbcdbaef..b8fd7aeedd9e 100644 --- a/xen/include/xsm/dummy.h +++ b/xen/include/xsm/dummy.h @@ -278,13 +278,6 @@ static XSM_INLINE int cf_check xsm_console_io( return xsm_default_action(XSM_PRIV, d, NULL); } -static XSM_INLINE int cf_check xsm_profile( - XSM_DEFAULT_ARG struct domain *d, int op) -{ - XSM_ASSERT_ACTION(XSM_HOOK); - return xsm_default_action(action, d, NULL); -} - static XSM_INLINE int cf_check xsm_kexec(XSM_DEFAULT_VOID) { XSM_ASSERT_ACTION(XSM_PRIV); diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h index 2d831d774541..cc32a6c09104 100644 --- a/xen/include/xsm/xsm.h +++ b/xen/include/xsm/xsm.h @@ -101,8 +101,6 @@ struct xsm_ops { int (*console_io)(struct domain *d, int cmd); - int (*profile)(struct domain *d, int op); - int (*kexec)(void); int (*schedop_shutdown)(struct domain *d1, struct domain *d2); @@ -450,11 +448,6 @@ static inline int xsm_console_io(xsm_default_t def, struct domain *d, int cmd) return alternative_call(xsm_ops.console_io, d, cmd); } -static inline int xsm_profile(xsm_default_t def, struct domain *d, int op) -{ - return alternative_call(xsm_ops.profile, d, op); -} - static inline int xsm_kexec(xsm_default_t def) { return alternative_call(xsm_ops.kexec); diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c index 96dc82ac2e29..244ef557528b 100644 --- a/xen/xsm/dummy.c +++ b/xen/xsm/dummy.c @@ -61,8 +61,6 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = { .console_io = xsm_console_io, - .profile = xsm_profile, - .kexec = xsm_kexec, .schedop_shutdown = xsm_schedop_shutdown, diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c index 9f3915617cc8..b250b2706535 100644 --- a/xen/xsm/flask/hooks.c +++ b/xen/xsm/flask/hooks.c @@ -19,7 +19,6 @@ #include #include #include -#include #include #ifdef CONFIG_HAS_PCI_MSI #include @@ -512,38 +511,6 @@ static int cf_check flask_console_io(struct domain *d, int cmd) return domain_has_xen(d, perm); } -static int cf_check flask_profile(struct domain *d, int op) -{ - uint32_t perm; - - switch ( op ) - { - case XENOPROF_init: - case XENOPROF_enable_virq: - case XENOPROF_disable_virq: - case XENOPROF_get_buffer: - perm = XEN__NONPRIVPROFILE; - break; - case XENOPROF_reset_active_list: - case XENOPROF_reset_passive_list: - case XENOPROF_set_active: - case XENOPROF_set_passive: - case XENOPROF_reserve_counters: - case XENOPROF_counter: - case XENOPROF_setup_events: - case XENOPROF_start: - case XENOPROF_stop: - case XENOPROF_release_counters: - case XENOPROF_shutdown: - perm = XEN__PRIVPROFILE; - break; - default: - return avc_unknown_permission("xenoprof op", op); - } - - return domain_has_xen(d, perm); -} - static int cf_check flask_kexec(void) { return domain_has_xen(current->domain, XEN__KEXEC); @@ -1930,8 +1897,6 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = { .console_io = flask_console_io, - .profile = flask_profile, - .kexec = flask_kexec, .schedop_shutdown = flask_schedop_shutdown, diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors index 51a1577a66c7..ce907d50a45e 100644 --- a/xen/xsm/flask/policy/access_vectors +++ b/xen/xsm/flask/policy/access_vectors @@ -38,10 +38,6 @@ class xen readapic # PHYSDEVOP_apic_write writeapic -# Most XENOPROF_* - privprofile -# XENOPROF_{init,enable_virq,disable_virq,get_buffer} - nonprivprofile # kexec hypercall kexec # XENPF_firmware_info, XENPF_efi_runtime_call base-commit: c36ddba28e314e9350f4024972023b52e34ec73e -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 05 21:12:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 21:12:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195737.1513652 (Exim 4.92) (envelope-from ) id 1vcrs2-0001wP-CX; Mon, 05 Jan 2026 21:12:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195737.1513652; Mon, 05 Jan 2026 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 1vcrs2-0001wI-8t; Mon, 05 Jan 2026 21:12:10 +0000 Received: by outflank-mailman (input) for mailman id 1195737; Mon, 05 Jan 2026 21:12:09 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcrs1-0001wC-9m for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 21:12:09 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 30129710-ea7b-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 22:12:06 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 04F6E4EE0742; Mon, 5 Jan 2026 22:12:05 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 30129710-ea7b-11f0-9ccf-f158ae23cfc8 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=1767647525; b=jnNIDsDY+vU+TTv5NB0WozdOZ13Td8J3axRBEk7hhiX3sbKnJ8hJqp1p16NYE9P2yGgy jCAsx9CiXFsbaSP4bRiIElx1lMoXlvsfUUjh4PpfAovD7HtzCXoUFeGtJrPM3YUQO7N1C fX1HkEYHsf5KorRIE7eG8ybfjNU3+UWBoVw6PHz3nLe41PEClu3VtPVRRqEvifmzptzOI cmJIU+GEP5XAIYDSzkHWcLUltgYSZwwDES140qdLznB3vFM4xKXZL+K4CDhBXSIm3g+7J ZkXkYNe+2ma1IUStZAMIMXYKnduACDkSutcJnX2caPfBF8MSqTL/ONhGXUFyh0rDkR2xP rPRm2amIpUmLpZeCngIlyCHdZUMYZdMX7Y3VkrjhoxTjGrqziPITWe08kI+XLKXhDuJl/ zs8hrNE0DcsY2fMHD/DtF/i6TYc0KnVRLLfbXjG/JebtRDK65+fn+UJEd40SeAGniQ3qs c4CKwx6lyaTXzmpOOgkI7IKSk4U9kZd7GJH6XEoY2q0F/fSCnFM9/6bkROTE/yUN31Bw+ EMi/2jXWVqXuCpU9+yJ0tf95uRIYdOBm97Q48CoyecNTAa1ONsw7Ndl4S6GecqDa3R1nD SqmmH0nSvfqkCb9GFqNP4A0dJSG43tKMAj0D3WHD+x+UgCge1FQwtzjnVBdIp+4= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1767647525; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=hmrUncizQe8f9wwReEAF/w1zYnSKq61MzoVCTzB7rHQ=; b=weF8nNVnXAroTX2Y4WqHcu2pWgOjOWbmbqlrwQ7SkPHM4COsR/44+6hfUUa+bWbG6Pbf jbExfE9XKity/SNf+jlity/vBguE+1V1US8uGNY5v0o2lhX0fDxv0D0rCKgJqiz3Ev5J7 KBTR2uAkf5WzC1h1bbiYLwuq8vUPLGNs1CBcmN2t2hKlAj6Ma+bGsfRIa05X8i3X2r6N0 EhpMAqvJi1hxUemRP020urtAHqvt3Rlz6lN/4Rk8er9JZipW7tpp9ES3ZQ27rqheE+KrQ QcY5+H54NHHZjbeCKP9Dk3jaucp5gcYSazcG/lJn5hmKgy6YVXKh0TPYRFOaNMpiXzH01 OB3ITSb4C/2oLro2AKcO8MRrs8UoKC+6s10baN4Y2kO3r5lfWcb1BfF2IhH6N7Kmc4MhS tdXj6BPoY5ww89sPLPnZ1F+E+BDkch2UKxaqOmErELb/RTNYFIqBagooc9HWq7x9Rm8it tMltb3Jser2V6XQt+Lldjx5EKq9uycY8FlX9Vr7qf5nysbMDcDqJY59I2SF12V86LwoBA URQkRJKUIVgZEHCK/YwUU0ayN7edqQtd2s3bijo3sPmeVYZEzXr5z0U+/UeijNv2YGi2C 8vFt3rPtHxfUyYE0VAoyiBNOZqF6dXVTgJXky165ejed6NG8r0pCHw7A/Y6aCwg= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Mon, 05 Jan 2026 22:12:04 +0100 From: Nicola Vetrini To: Andrew Cooper Cc: Xen-devel , Stefano Stabellini , "consulting @ bugseng . com" , Jan Beulich , =?UTF-8?Q?R?= =?UTF-8?Q?oger_Pau_Monn=C3=A9?= , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel Subject: Re: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible In-Reply-To: <82d99c52-c39b-4fbb-bbb2-0e952df91673@citrix.com> References: <20260105122436.555444-1-andrew.cooper3@citrix.com> <82d99c52-c39b-4fbb-bbb2-0e952df91673@citrix.com> Message-ID: <6609d3d66bb3522770967265f50cdd0d@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2026-01-05 19:14, Andrew Cooper wrote: > On 05/01/2026 12:24 pm, Andrew Cooper wrote: >> eclair-x86_64-testing: >> @@ -104,6 +122,33 @@ eclair-ARM64-allcode: >> LOGFILE: "eclair-ARM64.log" >> VARIANT: "ARM64" >> RULESET: "monitored" >> + EXTRA_XEN_CONFIG: | >> + CONFIG_ACPI=y >> + CONFIG_ARGO=y >> + CONFIG_ARM64_SVE=y >> + CONFIG_ARM_SMMU_V3=y >> + CONFIG_BOOT_TIME_CPUPOOLS=y >> + CONFIG_DEBUG_LOCK_PROFILE=y >> + CONFIG_DEBUG_TRACE=y >> + CONFIG_DEVICE_TREE_DEBUG=y >> + CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y >> + CONFIG_EXPERT=y >> + CONFIG_FFA=y >> + CONFIG_FFA_VM_TO_VM=y >> + CONFIG_GICV3_ESPI=y >> + CONFIG_HAS_ITS=y >> + CONFIG_IOREQ_SERVER=y >> + CONFIG_IPMMU_VMSA=y >> + CONFIG_LIVEPATCH=y >> + CONFIG_LLC_COLORING=y >> + CONFIG_OPTEE=y >> + CONFIG_OVERLAY_DTB=y >> + CONFIG_PCI_PASSTHROUGH=y >> + CONFIG_PERF_ARRAYS=y >> + CONFIG_PERF_COUNTERS=y >> + CONFIG_STACK_PROTECTOR=y >> + CONFIG_UNSUPPORTED=y >> + CONFIG_VM_EVENT=y >> allow_failure: true > > https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/12604499722 > shows 122 failures in otherwise-clean guidelines.  Some observations: > > llc-colouring.c uses binary literals.  These are safe to use now since > 4.21 with the updated toolchain baseline, but the Eclair config wants > updating to allow this language extension. > Yeah (though I don't see a strong reason to do so, for a single literal); I can write the patch. Also xen/arch/arm/acpi/boot.c could use __func__ as almost everywhere else in xen/ > ipmmu-vmsa.c has a git:// url inside a block comment, which is > considered to be a Rule 3.1 violation.  In principle this ought to fix > it: > Indeed it should. > diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl > b/automation/eclair_analysis/ECLAIR/deviations.ecl > index 7dee4a488d45..8f5fc6c93bc5 100644 > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl > @@ -60,7 +60,7 @@ removed by the compiler, the resulting slowdown is > negligible." >   >  -doc_begin="Comments starting with '/*' and containing hyperlinks are > safe as >  they are not instances of commented-out code." > --config=MC3A2.R3.1,reports+={safe, > "first_area(text(^.*https?://.*$))"} > +-config=MC3A2.R3.1,reports+={safe, > "first_area(text(^.*(https?|git)://.*$))"} >  -doc_end >   >  # > > > but I've not tried it yet. > > There's a R8.4 violation against __stack_chk_guard.  I think this wants > deviating locally, because it's a fairly magic construct. > ack. > Other than that, there's a smattering of violations.  Some will be > fixed > by some work I've got pending for the x86 side of things, but most are > specific to arch/arm/. > > ~Andrew -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Mon Jan 05 21:17:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 21:17:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195746.1513660 (Exim 4.92) (envelope-from ) id 1vcrxM-0002aa-Tq; Mon, 05 Jan 2026 21:17:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195746.1513660; Mon, 05 Jan 2026 21: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 1vcrxM-0002aT-Qk; Mon, 05 Jan 2026 21:17:40 +0000 Received: by outflank-mailman (input) for mailman id 1195746; Mon, 05 Jan 2026 21:17:39 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcrxL-0002aN-Fl for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 21:17:39 +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 f507e72d-ea7b-11f0-9ccf-f158ae23cfc8; Mon, 05 Jan 2026 22:17:36 +0100 (CET) Received: from SN7PR04CA0183.namprd04.prod.outlook.com (2603:10b6:806:126::8) by BN3PR12MB9594.namprd12.prod.outlook.com (2603:10b6:408:2cb::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Mon, 5 Jan 2026 21:17:27 +0000 Received: from SN1PEPF00026368.namprd02.prod.outlook.com (2603:10b6:806:126:cafe::5f) by SN7PR04CA0183.outlook.office365.com (2603:10b6:806:126::8) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9478.4 via Frontend Transport; Mon, 5 Jan 2026 21:17:18 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SN1PEPF00026368.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.9499.1 via Frontend Transport; Mon, 5 Jan 2026 21:17:26 +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, 5 Jan 2026 15:17:26 -0600 Received: from satlexmb08.amd.com (10.181.42.217) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 5 Jan 2026 15:17:25 -0600 Received: from [172.27.233.189] (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, 5 Jan 2026 15:17:24 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f507e72d-ea7b-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Dht+kQKcb8WyXN6WjamMrjBxyq2FTfARHhbGZMmN24u6ARYXtzxbkNMFg3fS7DDPvaA9qbabf/NOwWyKGtAyPOX338YCo14i4ppcEItKP7stjv/3tZvA+yExOWLCrMgrP6PoPSKY0abo1f5GfRI3vOiFnPiBS1zq/tNSxT70cy+RGbNXDDpGEGog1RmNUEHtaweZMztXytalIInQ22Aeuq0GgiRZUqK8Zmt/OzKVD+XMW2gDKuOqO6TuSa/Ysj4qYJQ1RYeIZLkXtHTonlsgULiiyayFaQuA44/jnOsrE8qmG2l+3Ic9hKwinzfqv/63r/A0ehUmW0WQXLKtGX1bfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Rrm+IchhvLmLkF2ahuYkeqyLbWWsxlXM4XviXUTTook=; b=NCbr1qTiiyNBqGX2RSQozuhv5rd5Jdxe4ksygMQYrKGY6uOQqNkGmmtbkwOtXh+00FZYdsQWgFev+y7CIqvSFwnSiYXWjV5hXuI6AU1t8H10XUicnj7JwF8ao70shpZ7iGAB7569ml/7SH5Icq6tyXb23zbHd3Rja6YLtmgDsH2fS5wOhVN70SzGsahq1jJUzjv1msxYqiPMssBKKWZnOWmGjBj6JROOM2Thd2Ky/5dMPqD5Gm7zjo+iexk+K0Reac1qUEyFRYS6zM9P+3Z5B5tKZRgfOF72y+OozalpNCC9BBEjwkEKhWEHeZtfdBAQa1GXg7iNkvB3uvSsh/lL1g== 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=Rrm+IchhvLmLkF2ahuYkeqyLbWWsxlXM4XviXUTTook=; b=JvypHkYmHs90oYx7j1MbPtNKrtKyiI2+mHEpoLQ7AtcjUwhLKcLiMyvdlFtWwguZlBPWxIr5K7vdp796qo0sJuzUoqxr57i1LcUbZUvCg5d2TFQjEnKsT+GNcs8RLYl3+qF2LScl0qx1lgBjjoaXx3LI/RAZTiFJxff7IyerGEw= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <68ebb184-217c-427f-ad4d-381925decf7c@amd.com> Date: Mon, 5 Jan 2026 16:17:24 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen: Drop xenoprofile support To: Andrew Cooper , Xen-devel CC: Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Oleksii Kurochko , "Daniel P . Smith" References: <20260105195717.601500-1-andrew.cooper3@citrix.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <20260105195717.601500-1-andrew.cooper3@citrix.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: SN1PEPF00026368:EE_|BN3PR12MB9594:EE_ X-MS-Office365-Filtering-Correlation-Id: 3935c24e-0df9-47d9-c550-08de4c9fd395 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?VTJxQjFDa3Y1MDBMajl5RHFvamNlTUg0Y3owVVBlNG94M0hKUUZjWG9pNFht?= =?utf-8?B?b1daYkZjcXFOb0hVbk93ckVLT2JySmtWZ2NPM3F0ZUg2d2d0ODkwM3NpWVJD?= =?utf-8?B?TWpjL2lUWmZLWEhVWU56WVJIaDNuWDhaNTM3Ky9uZmlTU3ZhQStxTlBuWGsx?= =?utf-8?B?V09CdmgxbEJTMkliSyt4K0VUaUJRalF4THd3Y1dQMWZrRXhTN3dPRVhldkpy?= =?utf-8?B?aVRTa0tDbmdLR0RPQ3drZTFtTnBDMFIyNWFrb2ZOZXJzRm1YVUpZaURLQklx?= =?utf-8?B?WmZ1c0tMeUdMWHBPZnFBWUlEbUxCTndQK1lNMGxmQnRtVWpMbWxlaE5mQ29N?= =?utf-8?B?eCtpTjlxbndQN01DZlBTQk9LR2tQa25jS3ExU2tqdm5kb3VjbGhlZEY3ck1X?= =?utf-8?B?Sm5NY29DTFAxbUwyTHdxejU3blU3RmQ5WWNGK3djTmpIT0VoS2Q4QmhPS3lR?= =?utf-8?B?WHFsNGJTNkV0b3ZFRDd1bUgwNjBIZEVvR3VrMUFQeTd5eUZkSkZxR2FlSjEw?= =?utf-8?B?TDdNTnczcm1xUXhwNzEyQXNXR1B2UlNwNVhnWktiL3hhTzB4YlA5c3d6RFkz?= =?utf-8?B?ZXhjcVF3YTNDTUhPQXZlZlVhRVYyUnRPaVNxRkZyZEpqMjRlVElYWk1rNG9k?= =?utf-8?B?dTVpQ1Z5Qi9peUltTWx3S1VDbnBCSEpYMkhsdkdoZXYyZysrT1JzVUFKRTNP?= =?utf-8?B?dHRYZWRsZitHY0R2ZU1uZG5KVCtIa0RDL0dhZDdKTUpRTlhGV1hOWFVadUdw?= =?utf-8?B?UDNHeEtTb1ZNMm0wQXRuc083Q2hZcUw2UTF3NllsRG9HanFxcyswOFgwQjMz?= =?utf-8?B?Kzh3U3hHWnNwNElDUXZ1d1dENGs0NGRrQ3NiaHBtSmZITWV2MjdlU1JSR1pI?= =?utf-8?B?NVV6bTB2T2o3bTRlZmlsRVFpRGtGZC9jWitmQTkxdVVHNEsyNmtLOUo4L0M2?= =?utf-8?B?UFlCT2FqeFBFbVIzcXdDTkxKR0JMeGhxZit4azU2M0FlK2dlNi9KUnNvYXdC?= =?utf-8?B?WHhTeHZvbzdHNml4MlllaXlTNUpaWWZEajl2VUdYRThMdTBGWDlqYzFaSHRN?= =?utf-8?B?dU9hMzhRaHovYTgxaHpKZFg1UVVqQlVkUExZT2ROSmUxUjc2T0ZCQmxVM2tK?= =?utf-8?B?TDQ5d0t1ai9yeWV3VkN6K0plMUZXVVdUdWc0VTVCR01aWkZISkJJdmQvczMy?= =?utf-8?B?Q2xFRGlkRGZOTy8rMXQ1cmJqTGZUeGtjKzlySUxrcVRjSU1pMklKQVFzMjBY?= =?utf-8?B?MGRvaWJaVFRCVmNRUGViSG9FQ1U3WHpCR2VNVDFVVFdxcEpIT3ZZTnJoOG5V?= =?utf-8?B?dkQvN2NiNnVNbDhRNHd0U0FSdXg2KzZsR255RS9zV3Z4dm8zSjdWN1NXOUVm?= =?utf-8?B?eGgyRlc4UERKbXpwVzdJWHFFQTk5WmhWbnkzTzVZR2tzOTVwWkhIZ1RpM1J6?= =?utf-8?B?VUI5UGZmL0ZEenlxZzI1cHBNTEw2elp4clc5bWsyMnhaTEdpdlZaT3lxZys1?= =?utf-8?B?cytoSzQ3Mlg5VTBTWGRZaXg0U1RMOHNQNXB4THJWeG9VVFZCdEhwRGIxSi9C?= =?utf-8?B?WGMxUVdGMUZ6RDVLK3R5OWhVNExZQlFjNEltaElOWDAvWkRmSnVrQ3loN28y?= =?utf-8?B?Q2FwcXNBZTdMT3ovekQyVFp4YWV1cy9VWGZFYnI1a0ZNT01wNFZYUDI4akQ4?= =?utf-8?B?dXliMUw2b21FL1FEUlBDbnNabnJCWUNHN2twMmh3R0ZKcGh5TEIwM0RETVdX?= =?utf-8?B?YUtQOU9xU0RFWm9QVm9yUlNiSTlPN2E1MCtIT1o0WTJ0ZnlmSG14RkJwaWln?= =?utf-8?B?QWw5ZWpabHlZdzNteFZYZU1Xb042MDU4SDV2eWdEUDV6Y0hFY2dlVFprcTNz?= =?utf-8?B?RUdxM3BKUmVRNERGWmF4RVh3SXVHRkl6cXFpdFl1R05VYUhEVHlaMEZ6OW40?= =?utf-8?B?SFA1bnFZVy9HM3p0N2dZbDN5YW1JVGtPWnNwbUpwY3B2dSs5d1kzcGtmeFIw?= =?utf-8?B?a2Nhd2s1UWlubXJWWlZkaS96ekVnWWV6RndxT200RDgrYlowMVV0cVEwSGE1?= =?utf-8?B?aDhNMjJCUUNqOFJlSXVSOERMSGQvdFRhZlBhMzVPM3FBNjJnaHdFSnkwaFRz?= =?utf-8?Q?OTMM=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(36860700013)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2026 21:17:26.5853 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3935c24e-0df9-47d9-c550-08de4c9fd395 X-MS-Exchange-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: SN1PEPF00026368.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR12MB9594 On 2026-01-05 14:57, Andrew Cooper wrote: > The most recent xenoprof change was 300ef0cb4fde ("x86: Add Xenoprofile > support for AMD Family16h") in 2013, despite there being 42 changes worth of > other cleanup/rearranging since then. > > Oprofile themselves dropped Xen support in commit 0c142c3a096d ("Remove > opcontrol and the GUI and processor models dependent on it") in 2014, as part > of releasing version 1.0 and switching over to using operf based on the Linux > perf_event subsystem. Linux's version of this patch was merged in commit > 24880bef417f ("Merge tag 'oprofile-removal-5.12'") in 2021. > > Drop xenoprof and all supporting infrastructure, including the hypercall, the > XSM hook and flask vectors which lose their only caller, and even shrinks > struct domain by one pointer which wasn't properly excluded in > !CONFIG_XENOPROF builds. > > Retain the public xenoprof.h header as it is ABI, but note that the > functionality is removed. > > Signed-off-by: Andrew Cooper Reviewed-by: Jason Andryuk VPMU_PASSIVE_DOMAIN_ALLOCATED could be dropped as well - maybe in a follow up to re-number the remaining VPMU_ flags? Regards, Jason From xen-devel-bounces@lists.xenproject.org Mon Jan 05 21:20:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 21:20:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195756.1513671 (Exim 4.92) (envelope-from ) id 1vcrzv-00043V-9L; Mon, 05 Jan 2026 21:20:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195756.1513671; Mon, 05 Jan 2026 21:20:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcrzv-00043O-6U; Mon, 05 Jan 2026 21:20:19 +0000 Received: by outflank-mailman (input) for mailman id 1195756; Mon, 05 Jan 2026 21:20:17 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vcrzt-00043H-NN for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 21:20:17 +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 53b685dc-ea7c-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 22:20:16 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by LV8PR03MB7446.namprd03.prod.outlook.com (2603:10b6:408:186::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Mon, 5 Jan 2026 21:20:12 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9478.004; Mon, 5 Jan 2026 21:20: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: 53b685dc-ea7c-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=sa1lq9B+Fsqc6LNIdUx3tY7UXgtdUDKvBOE9iQDCkhzQsr5IhKFfXAhqEyCioEUYCyLw3lCjUareRWQ43zAaKQkyjuCMh0PUEF4Qk/ydICruefs/r6VTPC8QE46qWUc1Eeo7kmoFGP76XECdU5NI/3y7wfmtygIbEKxaVZQCIa8HdzvdmFjbdbgoIOkKT4/z/a6JXSvgdzimaTvbgqLDTGB0S8QyuFz9EADfn/LdmqL+/dMGhqQsMhxHQNtG8/hnU4NP4sRkbsRSpoRF4iG1f7CdUkq0ILdReLV/1YNwFB1WSMGCjXqHJxqPhPqMqRoKbkmUVwI5cVbm2j0JoBlsvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Vzxh0RagYBCAW8uT4wSRqZj7umkm7gk019GzWqknGGY=; b=gkpFhFOlpWCBTbeMl+7E6i739hMu+CIwYcj+8M5+hWkDUB6PXCYYeYfdnYV/TBWXG1X+8b62qNdUZ+q1uX1DjPcD8azvvB/4BxRJXZROMpkVOJ5KT17HWIuRV0JeCKTLpjUHFbX5csQtKj5vWw3djKfNV/1VOLvY8wk7ZuIHDTDVot74q/Dh7S6ZNuVQ2egkwExx5sDLeF6ZuZXlxIn/mPofOGg+MGm/pRKBxabmaRjB6UvLJbMUF8R5aA9lPwKRT6F66WVXRyRu8ouo2QG4WtORDN4DlyWTIdCenZqdorYR7M4iB/lOgVICiWmDJy8vyYWUcoaK82DVz9jYennaJQ== 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=Vzxh0RagYBCAW8uT4wSRqZj7umkm7gk019GzWqknGGY=; b=wacEFowuDy6OALA+TzLqbRCauxbouc3ZDhmDe3fYAGmvGCwqQfPDhY6g2a1oWEWxda1iFdLbyqfBwHwA6zrFEwhC9blxH2gOiRSEGg0sbkD5k8SG+fPAnTuBvht7wAqKA7h0tHHmtqv3ajsWt/KHOrvf372IhgMHAc8YXdZAOyk= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Mon, 5 Jan 2026 21:20:06 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Oleksii Kurochko , "Daniel P . Smith" Subject: Re: [PATCH] xen: Drop xenoprofile support To: Jason Andryuk , Xen-devel References: <20260105195717.601500-1-andrew.cooper3@citrix.com> <68ebb184-217c-427f-ad4d-381925decf7c@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <68ebb184-217c-427f-ad4d-381925decf7c@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0645.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:296::16) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|LV8PR03MB7446:EE_ X-MS-Office365-Filtering-Correlation-Id: 11d75fee-b2a8-42a7-b6ec-08de4ca034f3 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?RTFjUHU4NFNoS29mRHlPNUE1QlNnamVuOWJXMmlGZ2ptSnhCUUthdFFWN3hE?= =?utf-8?B?Njl4Y2U3WkF3WFh0a3FiQVBKZzY4bHhFMWV4NkRxVUl1WFpJeC9Za25iUlBq?= =?utf-8?B?SEptQmwzbFZMcjlKdi9reldGdm9FbDVkdDlJaE1uZW1oK3hzOTRXNWRxUnJ0?= =?utf-8?B?bWxQdUM0ZTBuaEc1Si96b3AwN2JsUHUyVjFVTFFWb3FZcDRhMVNlL0NNWkpR?= =?utf-8?B?Vy9OK2trc2lvTlNSVXgxdHczQXFoaGdtWmZVWjhwNU1IWkVyTk50L3liemlM?= =?utf-8?B?VE5POEtFOUZFSXB2ejgwNitsYzNwcWg3ZENXdmdKd2t0OGNFSGk0K0E2WWMr?= =?utf-8?B?clJsa1gxUEROQ21NN25EaU5NVmlQa1hIeXRYbjZmTlBqSDhmRmFVWXl5NjB1?= =?utf-8?B?enFnN2hBQTlINitHZ3d6SlU3Z0s5UWhxV2hlY2ZySzJDODBrVXRvdENFTWRV?= =?utf-8?B?SGZ6bU1teEFJaFdONG9hclZ2WUxTdUl4d0FGNXNjNjNLT2NLZ3FvcVQxSWdT?= =?utf-8?B?emUrZXN5VitOVVVaVEo4Uk0vK2U3SkZrSHNYQzVQanNzN1dGMm1QQUZqQlZh?= =?utf-8?B?RUlQOFZReWtaa1JnWnpnY2kyMWdtem5qUTNhSVc5UVNORWlkWXJIZTI0aDBJ?= =?utf-8?B?QURmSElsZVZTWU0vOE9GQkx4MXhWM0FINDIvdmZSU3pCUmVabUowcjVmRHk0?= =?utf-8?B?YkgzU2s1YlF3YkZKdUFoTFR2SW9uRjZJdDVXaEw1WUcxUjcvdDAwTWt4aGl4?= =?utf-8?B?TGphWTdkempRL2NTaElCa3A2QTRHZXJZci9keStSKzJCa2xGbmdISmJWTzdJ?= =?utf-8?B?OG1MblBSMHpPNTk3N2NNenltclhkSWo4ejVCYTVnRzRVSjhJR3BRSDdyTWN3?= =?utf-8?B?OXJzY2ozTXo0UzhTWFlPdjUxMlNoSlZucmxoekN4ZzZNTkZlaVV1aDI3Rlkx?= =?utf-8?B?dVNYNHRTUGtkTDFKQ3FLbUdRWGpOVVNuV1JpU29Zek1nL3hEV3oxNlZUMkZK?= =?utf-8?B?S1V1Y1F0SlY3dWs0K1Zhb3lSanZHdUgyV1dma1NZNmdCNzlEZjFxcjAxTFdh?= =?utf-8?B?aE5TL1NCeXRHbDBLS2ZUQjdaWmtZaVVkcmxrUnduMVhDWlB5STZIdFpJK2N2?= =?utf-8?B?bDZNSzFkbHNoVnp5Uk4yQVlSekRVbHcxT29ReDNDTFY3YUJ2L1FXWlBtQjBx?= =?utf-8?B?MnpZVXI2bTJ5cUNGOUFzQURPeGRmOGRkNHdoUHZLRDBES3VMVFlGTUhNQXBv?= =?utf-8?B?RVBOdFcrUlM4VVFMcVBRdTdFb3VSQk1DeFJQdmQxZllLdXlxQ2tYVFRpSFRs?= =?utf-8?B?SGFSRktBQ1lvRDF4NkhFejRIdng4dVBjMnMyckFhUjcxMkswSWhBTUNxcDN4?= =?utf-8?B?cGpSLyt4ZUU4dk92S0c1UFlnRTdibzJUQk5aVXBwRzlseklmdnl1SjhDanUz?= =?utf-8?B?STAvOVhoOElQMWgvZnBiM3M2YUZlb0lGTmhWTDBUZFdFUUZMNGRZZ3FFTEV1?= =?utf-8?B?djVGSy93aWRMYVkwWmdSSDBRZ1A4dTV0Uk9zTkx2ZGZSVGFaYmRoNDBJQlZz?= =?utf-8?B?VWNTU25yWmhMUmVJZ0ZYaVVnTi8vL3dTS08vbkFQNHFjaDhyYS92K3cxbzFV?= =?utf-8?B?N3oxM1FLZVlpbC8xeDNvMHlna3p4aGh4czlBUlhTcWFMWFlZbXpscnlDU1U5?= =?utf-8?B?M0o4TG83Y2dUdzdBOFJNNlFCYy9EWHlITERhNldLL1FSTVMvVkxmcUZnRnlz?= =?utf-8?B?V2thRDM4VnFEdTRNM2hTRCtyWFQwVmVmM2NFYXpwNTJCM3UwbE9EVjRrWEx6?= =?utf-8?B?ODBHKzgzT2JDZEp6K1BncFQ2NlpkSkVxNk1ld01SQU1qRkszWWlwTEt2SWNt?= =?utf-8?B?aWJva252QmhVeWx6ZVNLanNDWTFWeDlsOU9xSUNOcng1dkxPZWFKYm9zczM4?= =?utf-8?Q?ZRsLd/Qu+9QSZ4jvyVTXU3I/qNroG3Xh?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eUNmc0orbVVQY2hHTnNBNVFrTXlra2U4Q1o2bUg2SXpPM1lsTXJTc1VYb3Ra?= =?utf-8?B?RFhFbVM4VnRZTy91NFFIa21pUS9sL1p1Tis0Q01lV21jenFiRkJCa2p5WjBl?= =?utf-8?B?R0N3bmE3TXdJRGV3b2RIMFlKTzc1UmhMUk9BL1V6WkpaNkoxVHFzdnZuRm1R?= =?utf-8?B?d3FycW5EWW1UQUMyZ29ZUnhyVy83Y0N5YVhBaGg2eHJRUDZHbzBGaDBpcER3?= =?utf-8?B?cUFFVGpzaGc0SlBCTUhpcFlnQWcybUk1TENWM1Z6a2QrQmxTTGVLM2NSd1FF?= =?utf-8?B?ZG9SbGVRZUZnWTBsaWpSSGpoTkZoU3JxZ2tqbjBVS2E4aFNVTStpcjJLNEcz?= =?utf-8?B?VCs1QnR6YnZUekxMVmpRZ05BMnJ4djVXTUswaDJiSlBFWU1UU3BIUktpc3Bi?= =?utf-8?B?YzNLU0VBQTJuMGJaaXJhZWYvNnBNZ0wyclVKSTNWQkd1VE5pMVNVZmlFcmpw?= =?utf-8?B?MjdCNnQ2Q0Z1U083Tmo0cHByU1o4R1NyRmhHeTI5WiswZ0RvMmF6ZzQySHE1?= =?utf-8?B?Z1RkWHQzLzJwRG12SlF0ZFFvZHJNc1YwQWlmR1haOXFpV2MwckswRnhuWGdS?= =?utf-8?B?b1FtdlhsaXlFQ1Bvd1NGejMrOVRkMlpGR1pWRDlWYnpydkhYWHgxZWdlN0FL?= =?utf-8?B?UVpKTjZibU4rVlRVMlF4Y0hCd0crRzduQ0YrYWVIRnA0bWlseklsdkdUajlr?= =?utf-8?B?UkRTK0F4dU5BMmdma2V2d0JxUXVNTUNoQ3E4RDlDeVBSbS82TmlaNEQzTTRu?= =?utf-8?B?Yyt2WGlmbklsak9SdmxlclZqNmNBVGJuUnhHYWlLL1Y3Q1lGTE5lSXlEV05m?= =?utf-8?B?RDVIWSs4U29RbDZRRzZNVmhNK0pybFdPQm1BQTcyRjNRVjdJa0pGM1drMUpn?= =?utf-8?B?elVKZjJzQ0hpd0xEWXR4Tk5xamd5cW5Zcmp6TGFhaEVSSFZpTHMxckUrL21H?= =?utf-8?B?NXdYNms2aHJJRGMzRTczRWFrQmJFbEJtMFM3RWtVM1dtR3Y2M0RZRlJHRXpj?= =?utf-8?B?c3ZPMHFhMjBINjl0eEJ2TDl6bXFTdGxzUlVnaTNQcFBzeElLZ3ZhT0xtckY1?= =?utf-8?B?Y1RVVmVoUE5TVFZWYUFneEZjY1hxK2pIc2hkTlBlQkRNVm8vbGhaeGhiT05n?= =?utf-8?B?UUdkdkdqN2YzQ1Fxejd2dmk0L3dVRHVhaXFGOXRLb21JMjQra1BOMlRRMC9U?= =?utf-8?B?WWZUMkdHMURKN1c2ZzRpL0grRXFwaFR0R2hDbVZxUWFqVHJPcmVraEZUOHdR?= =?utf-8?B?ckpQaVJ4cnRUYjFRSm1EeU95M3VHemE1ckhiajJreklhZnMvWGJ3a0tJZmoz?= =?utf-8?B?OXBtbHdsSGFpWlhJdkxzN2dNWmltb3RBejBiVy8waXZ0bEI4N28weFVveWZq?= =?utf-8?B?ekNyMWY1MEpyZUpiVGVza2RLYVpyYkVrVnAwUi9Na1hCaUs3eVN0a2x3VzhT?= =?utf-8?B?S2JQTkxZMlFQSitYZXFLMXNvZWdWZnd3akYrT0xTeFJVMklsT3VuaTVWMUtx?= =?utf-8?B?M1d1L0Q3SzZwNWhRbVdpUHV1cEFYMDEzNGNXUldTY01SaTI4dE9uVmVlSTQw?= =?utf-8?B?UnA0bURkM1RnN0VhQkpSeU04TkttUGdvWmxiOVdacDJwanYwRkdUcjJpZmNU?= =?utf-8?B?NE0vczR0SjFpUGVMUjhDQWdmbDNpWFZaNkNyRForR29oQmRFb1FwOXIzd29k?= =?utf-8?B?U1FFZ3lweDQ4d2lOV2lESkpjNGhVUU56cGsxRHo2T1VwLysxMlRGcDVYd09G?= =?utf-8?B?bmJOcXN5YWVacXNLMWVxZy94WTNuK3FwMFhBclk5RnFVbWtpZE4wK1pHUDM1?= =?utf-8?B?cC9aenRmbEVqdEsvMXhoajVDL2ZVRXQzN1ZEY2g5TDl3ZitGc2hPK0MvdWpT?= =?utf-8?B?MS9HUzhjS2k0bGU5SDN4UDNtNEErM2xKaE95N3YzMU5SNDVLdkVXQ2VOeFE0?= =?utf-8?B?ckFUcDVONFhkbzREQVdNaWpRRVNTWXExTHhXbDJ4SkR3SGlKZkFseXM0bHlk?= =?utf-8?B?OFRHOGc4YXBQQVpnbVJ4VFhham54QnptVzZOd1JLamNwWWdSRWRTajZNbXFP?= =?utf-8?B?TlZrRHVtWWNKaVNzNmo1a3hsRGordzdYTVltT3gxZlNsMEVmSjVhVkRseGFP?= =?utf-8?B?S3dWRm5OTkhRZTF6SlZTMU91M1hHTkFYT1BVRDIvd3NyUzhDcnNJaEkzdVlx?= =?utf-8?B?NnhqRUlFOXgwTUFWeTdiSkU3eUkrR0FCdlhBVGo3YU5SdEM5QndzbUdZby82?= =?utf-8?B?VlI3OTJvNXJlNHhVWEhJZENmZU9VK3pHSWswWGtSNnNGUmMxeGNqeGtOSlgv?= =?utf-8?B?c1Y2MWx6clMraUswZnVzbEFZYkNCckFMRlc2RytNZFMzTTA4bUdtZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 11d75fee-b2a8-42a7-b6ec-08de4ca034f3 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2026 21:20:10.0805 (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: RinlCZRiBFSr8SYP45io0K/jErbx7xjEyla6SHsdOZ3KpelTCPdqZIbY9vVOB6MoP2u/IUmBelr36Rw7rZxFuH40fK2P5Ni7r3R3uBDZWzI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR03MB7446 On 05/01/2026 9:17 pm, Jason Andryuk wrote: > On 2026-01-05 14:57, Andrew Cooper wrote: >> The most recent xenoprof change was 300ef0cb4fde ("x86: Add Xenoprofile >> support for AMD Family16h") in 2013, despite there being 42 changes >> worth of >> other cleanup/rearranging since then. >> >> Oprofile themselves dropped Xen support in commit 0c142c3a096d ("Remove >> opcontrol and the GUI and processor models dependent on it") in 2014, >> as part >> of releasing version 1.0 and switching over to using operf based on >> the Linux >> perf_event subsystem.  Linux's version of this patch was merged in >> commit >> 24880bef417f ("Merge tag 'oprofile-removal-5.12'") in 2021. >> >> Drop xenoprof and all supporting infrastructure, including the >> hypercall, the >> XSM hook and flask vectors which lose their only caller, and even >> shrinks >> struct domain by one pointer which wasn't properly excluded in >> !CONFIG_XENOPROF builds. >> >> Retain the public xenoprof.h header as it is ABI, but note that the >> functionality is removed. >> >> Signed-off-by: Andrew Cooper > > Reviewed-by: Jason Andryuk Thanks. > > VPMU_PASSIVE_DOMAIN_ALLOCATED could be dropped as well - maybe in a > follow up to re-number the remaining VPMU_ flags? Oh - so it can.  I'll fold in the deletion, but I'll leave the renumbering for later. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jan 05 21:22:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 05 Jan 2026 21:22:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195770.1513681 (Exim 4.92) (envelope-from ) id 1vcs1r-0004ew-MX; Mon, 05 Jan 2026 21:22:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195770.1513681; Mon, 05 Jan 2026 21: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 1vcs1r-0004ep-JX; Mon, 05 Jan 2026 21:22:19 +0000 Received: by outflank-mailman (input) for mailman id 1195770; Mon, 05 Jan 2026 21:22: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 1vcs1q-0004eh-Qf for xen-devel@lists.xenproject.org; Mon, 05 Jan 2026 21:22:18 +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 9c7dcf94-ea7c-11f0-b15e-2bf370ae4941; Mon, 05 Jan 2026 22:22:17 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by LV8PR03MB7446.namprd03.prod.outlook.com (2603:10b6:408:186::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Mon, 5 Jan 2026 21:22:14 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9478.004; Mon, 5 Jan 2026 21:22: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: 9c7dcf94-ea7c-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nKVLnwngFUc1I7H2MILi89KbeFt3beJqLhtxwr6q8xO7aaRVYdxPXNPX5m2N2kgnY6NCe4MEWJFXCzesXTxmRwGifLgKrP1F9ydhr6RRkfuiuzuwReHqsD1lTB2ZCBNnER8uH9co6Y/Gr6Lrr/Epj7x5L68mUrFeRs0Xd2v1klio9fs+8XEn4+pUpiqelLDtsHicW1j8YqLnvzOuM41cBU1Iv0sbN7uZo+zuFH0RkBYtzBAKb3HQQnyxsm6P1aDiuDGxb9QG2/r3unk/1pB0hxD37UAlUVZuacd3732oJysMjYupzUiou/tySKNUrHg6cxZdSKSOq6VSev/bO6nqag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GOVC8T33nshyLW1CmKwEyFz8Ud/d/fwuAsHfRhc7jE0=; b=F6LHpco/0GJF89PsZB9af/oAo8jsu+Y91HSJxSxWnAu3VTWuDGW7mwAiM3wgg1SOwAwyCslUPD8adpUYdXXK4/KcWL/7F3hvPtcAa4sXMwIteJ/y5ybXnGC2ZEYr5tIwgPRlhRTWGrkOAWaAxEx5HT6r5Y2JsoY+IOaX/4vVkJqyULnloZrvNAEt8XsfGh7sIIcE/Rpne4puW466ifEDas5cd0u7KUhub12I8p6Stafobg6vlEmaYwd5MAyZSEkWv9P5t1U7BDQgKHkpgWD1ygMAziUNu4sBzAaRYqO1Kub+GCvtcC2TfJFk3PwBuB/wEjU5liYTXlkuIE+4SctUDA== 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=GOVC8T33nshyLW1CmKwEyFz8Ud/d/fwuAsHfRhc7jE0=; b=dEKJT5zFWJVbTcOrVXehBil6BufPMoFa2i31Q0toYwArJgDOHHHA87dKH1sdNcdiUuTDmmLJvlHmEBn7vx8h4MidINHsdmBMkRonrG7JG84MrUMtcN7zcnYiJleXFWkkzJWNXqiJFae04E1nDPqGAop4jW60OkuSe6XFMq/SfzE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Mon, 5 Jan 2026 21:22:10 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Xen-devel , Stefano Stabellini , "consulting @ bugseng . com" , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel Subject: Re: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible To: Nicola Vetrini References: <20260105122436.555444-1-andrew.cooper3@citrix.com> <82d99c52-c39b-4fbb-bbb2-0e952df91673@citrix.com> <6609d3d66bb3522770967265f50cdd0d@bugseng.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <6609d3d66bb3522770967265f50cdd0d@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0137.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9f::29) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|LV8PR03MB7446:EE_ X-MS-Office365-Filtering-Correlation-Id: c14c63dd-57b4-4e8d-44f5-08de4ca07f1e 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?Tlp1NG96NEE4OEZUTWRqdWVPMXBjOU5TMk1XR2RvVnYxaUQzaHFEOXRWMFdJ?= =?utf-8?B?VENhZ1FSQzlGVGwvT1dOMXV5dFlEcDE4MFdaYjV3L0NjNUhxTFliMmRmTjFn?= =?utf-8?B?NGR0dFdnZHVTSElzenFhNjJpWnd3Szh1ZmRrZUxLaHRaUUVKT0FQQStJVXRr?= =?utf-8?B?S0hYRENTUEV4VDVYNGh5aUFMZUVDcllnMDBYaUVDOFoydzF0aXFHZTFMWEZ6?= =?utf-8?B?WU5tRjNEOUxCVFhxRnVqM0hvcEpJeDA0Wm9BV2pCK1Rwa0FUV1ZSblVDbmNN?= =?utf-8?B?M21hSFRWQjJTdzUyZkJyMUthNjJmMEZ1MDk3MXJVSHRtNElTL3ljVEFKUkVo?= =?utf-8?B?QkkwYXpmeHhXYTF3RmlzS3dRRzJMaldpbUNOSDNKclJhVTVFWGRWYU1JQkZ5?= =?utf-8?B?TkZrcHdES0l6M1cvOVpKM3I2cTNOU0ZBVjJlUjlrVXZERnQ4Q0RNcTFCUHZK?= =?utf-8?B?QW9QSlBDQ1JkQTVHN1Y0cDRCQW0rSkFBdkFKY3dONWRQb2lORU5nbk9ac29h?= =?utf-8?B?OHhGS2pKd05aMldJRGtTTmpNcHFseHc3L0lPT2Q1SU5jM1NUTWhIRWdmRVN2?= =?utf-8?B?eFFIa3hSeHpoOGhCMjUxV1QvWUpkc2VXQzlWK2xkaXZITHpKZHc5dVBKOG5Z?= =?utf-8?B?ZU9OWkw4NzRneG4wSDVqSU9aUkZwTTNScVF1VjVQN2tmYmVrYUFOS3p2YU55?= =?utf-8?B?REJ6eXhvNTlFWGpMOXRBdmh6cTZuMzVlUjZVUmtBa1BPMzN0WUtGcjc5OWhw?= =?utf-8?B?MERSczZ1cnB4am56RDBvYTZhNWU2U2xGdGRvQWoyTnN5WStpRlFrQW94dmVH?= =?utf-8?B?L3RUNHNzL2FiMWUzbVhuS2kzeFVJRWhCSzE5WXhyVTQ1ZVVDTkNVcUJ3Wldj?= =?utf-8?B?aXV3WW5yYnpvVElueFlqTm56cHZrU3YyblU0VkhEQUE4N3JhUHgwUnoyVVZR?= =?utf-8?B?UlhiMW9YYUlZNmlVb3V4YzRzVVgxdEEybVhqc2lxL3pTeHM2YVpXZlYxQnZ2?= =?utf-8?B?MW5ITE1tckxqSVVtSlNJN3VkalE5aGlpaHdrREw3Z2ExeUh4Nng0em1KeFQv?= =?utf-8?B?ZGRsUHJVRlh1RWNJUjVmMTR2YjVtdHZzcFREZWxZbWR4TWQyQTVFRStOL1Iy?= =?utf-8?B?OHZYWUs0Nnkzd2VPS1Z1VW9ZL2lvQ0tselQ5a25GVDkzQmJ2N0IxWTV3RklY?= =?utf-8?B?WU5ObHRYaWtzbkxNdDdQVDNEQzk4eWhuT2NCYTVqUmpndzFUQk5mQU1XVzdU?= =?utf-8?B?bTBnU0l5RVhMeitPSUdkbHNzRXEvWDRPK3VsbCtDRkgxZjRUYlFjTkU4dERG?= =?utf-8?B?NDg4bURJYkFJb2ZVRTI2ZmNScXRVTS96SDNZYnArNjlQSzNicmxKcHJZeWpt?= =?utf-8?B?NWxId1hDbHphNjFGOU12RDB1K3JCbWZ0bk5vMlNVVm1MaUdMMG1NM1JUMDY0?= =?utf-8?B?Um5RZVNadlRQNUhWVk4xS0lZL3dlVnRzRG8yMlpBVWdkcWFQN0ZVaGFVZnRl?= =?utf-8?B?WTk2TkpzdWIxcW5XZEpySVU2VXc4dFEvRExzZjNwOFh1OEpHTkR5eEdmVXpY?= =?utf-8?B?Y1Q3WGhuN1J6bFR3QWErUFU3SHJoZ0xvRXJPazltdVpWUXBRMXNpRHMyMW5z?= =?utf-8?B?WHNvRGhRY0VMTllwY1hWR1IvZmg5dXFUSEdnRFAvNXNXd3JXVDY4Zm02TXlo?= =?utf-8?B?WEZJakl0YnRTcUIzc3JPdGxJdVEvSmMxWWQxNG8waFFEWFJVWjFpYis3ZktE?= =?utf-8?B?YzlDcHlWaVlpNTYxNnN3L0JoNVYrWVlLVWlqeXNWcy9PaGc1VEJJMkdhY2U0?= =?utf-8?B?dVZQM0ZPWUptUm90WG9YaFBkZW96SXlwL25Qc0tWNXQ5eFZxY20rRW5hMGFQ?= =?utf-8?B?YTZuWUhlQ3BEUmRPMFJHOWppNGswQndXQWJ4aXh2NHFLNFE9PQ==?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QnA3eldvR2JnaXU4WDhIZ0tMYy9lZUZRN09aUjVqWkN2QjdQOVBZMlFFaEZF?= =?utf-8?B?SkhpQnlxQmdFWFQ1ODNtNkZlalc2VTdSSURCZEFBZzBySFBzeHpyWFp4anZ1?= =?utf-8?B?Uld2c2FnV1d0Z1k5WC83bjJMcEdWV045dzcvdGN3eU5mTy9lQTdWU3FEbHBa?= =?utf-8?B?djlkZzZ6ZlkzcXNoYTV2NlAyTHlIYlpia3A3TnlZc1VpU1NWUm10UlFqbExH?= =?utf-8?B?OG1peXJlWXBGQ2pXYThOaEJoUzZsV3F0dFI5RTlubFF3SThpck5ES2l2RU1P?= =?utf-8?B?TnlPend5M3puYlNieHpFYk55ZzNIZUw2eXFJTnI3ay9qOUJPcVVsVksrK25V?= =?utf-8?B?a0ZaNkZha0M3NFFpMGoxbzJLdkpYNzBrK284d01wU1Y5eExseTlsYjEyQTZo?= =?utf-8?B?amV5c2ZpL1dOWXJQaTZSY0dCdmVEM0RTakI5bG9oMFkyVHdaRC9BaW5JZldm?= =?utf-8?B?YzI2VkpHNmMvUVFOYlhzcHpSZzBKKzEwVjBPZ0pzbGcwTkQzcWV5UGFKVzlD?= =?utf-8?B?UDZuelRvVWZDNk8wbCtzNGFUMDd0bVpnTDhKZnB5YWdEWG5GbDdTTUxiVS90?= =?utf-8?B?bzJZOE1TN1FjOEJ2ZlNpbEdnL0QrTXF1NGJZNkNBTXo5T2IzM09Nb252dDFO?= =?utf-8?B?TTdkUldlZTNsUGFicEdzUjU1d2NqZ1htRmVxK2tDYk1xREl4NEt2NVNuMUxn?= =?utf-8?B?TVZGWWJzTzhWcHJyNDd5MnFreGlIRE92d3l6ZTE2emkyc3Axekp0R0NwNkMw?= =?utf-8?B?YnUzdW5pVWxQb0tRSytKRGU5bTZGU2VUYyt4TEtWbzdTdStvT0ptaXJac3pN?= =?utf-8?B?VVp1VlFvcjhSWWZDaVZMTFVOZXdaeWxBZjFkS3o0YXoxR0dpU3BBR1JtS0Q5?= =?utf-8?B?Uld4aXZYeVhvZ3krckxEYjNtanNpK3FQMDcycUFJcytaODdKV1FTU3BaWFVr?= =?utf-8?B?MUQwYzFKUVIxWVdMeU0zbnd6YjBvdDcvM2wrd2RWTzlrOTZPVGsvNlkyVkxt?= =?utf-8?B?bzhYWDkwZXJjS3gvM29ySUJScTk5Y2ZXREc4aWc2cUpKUlMzdEkzempZMHcw?= =?utf-8?B?U2t1Ui9xMkZHS1ROcXBCbndOem56eDVjS2RNQUhVZ2hFd290VmVub2dwN05W?= =?utf-8?B?dGR6YXB1YmJRZjdsYlBIeWtiVGxKUkVHSkpHSUwyR3BHQzlGZGdjVHpZWGFK?= =?utf-8?B?N0UxQTgvaG5UUjVPQlVUTmc3dDQxRHlXZ3pEeVdMMWtyRmtUZS9BNzJ1N01u?= =?utf-8?B?aFI0TUlSK1lja0k3OFgwZ2VPUmF2U3FMczFsYURYOTd2YUZIZ0ppMGJtQzk2?= =?utf-8?B?YzJ6OFdZT3hsd294UERwVk1US0FqWmwwZVh3b0FnVnowcXo0Qjc3UHdWeTNX?= =?utf-8?B?cWxvNTAxUXR5RlY3V0FqaXlGODlZVFdFdWppd1puYXRjcUR5WkZMaVZYeUR5?= =?utf-8?B?RlBMZ0VhRTI3QVc3OW53MTc4YTJQdmZxbWNMaCtHc0svY2ZYdjduS0dBSUsv?= =?utf-8?B?UEI4NUpNSCswdjlpbkJ3RlFycDJvRE1xYjJzUFF2Y0tDRlMrUXFlY1IxRzM2?= =?utf-8?B?VmpjakRKbDZOeUcxaEZmQWkrekRDM3htVEdIU2QxeFF6NVdGSlE1S2dpRVlt?= =?utf-8?B?UG5zRlFVNzRIMm41Z0JXbytWeE5yZjJFWjdaa2UzYTVSbWxmdm1wZGJpWXNK?= =?utf-8?B?UDlxRzJlZTVWVW8vZnNlNzVaVkhNa1VnWTMzTk94bnRaNFQvcGJ4Qkllb2RB?= =?utf-8?B?Sk1WSUp4TnYrNE9EbFBXWVNueFpyYzUzcVFybUJ6QmZCMGx5SHZ3cksvdXor?= =?utf-8?B?ZVVGbkhBRDZ4dDhSYkIrSzdtY1RoRGJ2WWE5dmVJbUJsN0dEazRXL3FVcTJl?= =?utf-8?B?Vm1YdHdLL0xYQ0p4NXpPSWJNNE9uNXZTRXpZdTlQNzROa2ZJV1Z0bmRZcFlU?= =?utf-8?B?UXIvZHJCZ3VVSmtmcUp6aVdaN0hQR1g1WFZVZ1J6TVM3anZIbkZRQWpmRFU4?= =?utf-8?B?c0c3OTl3VlV3MXU0eWk5TThQYUl6WDNDeDhMTDhkbDlmZWtqREF4b25RSXll?= =?utf-8?B?WUtRMGJtZzNPWE9YdmExeUcwNFo4L01jU2ltTkwzNjNPa3JYZGdNY01DaCtO?= =?utf-8?B?QkdZanNEbXducWt0Y3RVcXY1ZjdDeWFhZzRtVnRtdG0xY1kzbzNWM2tRQzYx?= =?utf-8?B?Vk1tWkVtbmpDdktjRGg5d0NOaHMwTWlFUmt4UjRkLzlJMXpRSlpqSVF1ZlRx?= =?utf-8?B?T20vejFldkxtTXI0RjVpcFQzRmVGTUtXS2U2VHM5NkFSN2d5cVVpemhtMW1v?= =?utf-8?B?cDdsT0EySUwrdmZtTittNVg3MUpVcXdTd2JpYVdVV0JSaGxQYlVYU3FoZ3VW?= =?utf-8?Q?nhSQcASpy3AJLFpA=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: c14c63dd-57b4-4e8d-44f5-08de4ca07f1e X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2026 21:22:14.6571 (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: qpKvn3f9xzT2jqrSZfoDAEHWS84NlBFFBlSF3LSUd6xWPDDfo1c+azcJ5ZQCVpAMU0YJCjZqNku7vYOrcT1ATusOIYUWGOXute+UZZpNWFw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR03MB7446 On 05/01/2026 9:12 pm, Nicola Vetrini wrote: > On 2026-01-05 19:14, Andrew Cooper wrote: >> >> llc-colouring.c uses binary literals.  These are safe to use now since >> 4.21 with the updated toolchain baseline, but the Eclair config wants >> updating to allow this language extension. >> > > Yeah (though I don't see a strong reason to do so, for a single > literal); I can write the patch. A separate discussion happened about starting to use binary literals more widely.  It's a capability we'd like to be able to use. > > Also xen/arch/arm/acpi/boot.c could use __func__ as almost everywhere > else in xen/ Yeah (although I considered that not interesting enough to discuss.) > >> ipmmu-vmsa.c has a git:// url inside a block comment, which is >> considered to be a Rule 3.1 violation.  In principle this ought to >> fix it: >> > > Indeed it should. > >> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl >> b/automation/eclair_analysis/ECLAIR/deviations.ecl >> index 7dee4a488d45..8f5fc6c93bc5 100644 >> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl >> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl >> @@ -60,7 +60,7 @@ removed by the compiler, the resulting slowdown is >> negligible." >>   >>  -doc_begin="Comments starting with '/*' and containing hyperlinks >> are safe as >>  they are not instances of commented-out code." >> --config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*https?://.*$))"} >> +-config=MC3A2.R3.1,reports+={safe, >> "first_area(text(^.*(https?|git)://.*$))"} >>  -doc_end >>   >>  # >> >> >> but I've not tried it yet. >> >> There's a R8.4 violation against __stack_chk_guard.  I think this wants >> deviating locally, because it's a fairly magic construct. >> > > ack. For the x86 side, https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/hardware/xen-staging/ECLAIR_normal/andrew/eclair/X86_64/12595699289/PROJECT.ecd;/by_service/MC3A2.R8.4.html shows that we've got the same problem with pvh_start_info_pa and early_hypercall_insn. Like __stack_chk_guard, these are external because they're accessed by assembly, but don't need/want to be declared anywhere else in C.  What's the recommended way of handling these issues? ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 06 01:04:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 01:04:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195800.1513699 (Exim 4.92) (envelope-from ) id 1vcvUL-0005FP-Rp; Tue, 06 Jan 2026 01:03:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195800.1513699; Tue, 06 Jan 2026 01: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 1vcvUL-0005FG-My; Tue, 06 Jan 2026 01:03:57 +0000 Received: by outflank-mailman (input) for mailman id 1195800; Tue, 06 Jan 2026 01: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 1vcvUK-0005FA-3i for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 01:03:56 +0000 Received: from mail-yw1-x112f.google.com (mail-yw1-x112f.google.com [2607:f8b0:4864:20::112f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 91cbc98d-ea9b-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 02:03:54 +0100 (CET) Received: by mail-yw1-x112f.google.com with SMTP id 00721157ae682-78fb7ab7562so5146437b3.2 for ; Mon, 05 Jan 2026 17:03:54 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 91cbc98d-ea9b-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767661433; x=1768266233; 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=0iHJG05lFXNcNOBT5oN+oQTjn3c3C+wc56WQy98TbMI=; b=Dt7FPuQbwek18vDECm9farqF4WRIb4UCnCdXDkDcaS5HWBsGyq2PdMyioXIyfkm2JZ 7CV0omqdW1xynRPs9QPnuFmzQV/AbAhLeiH+Uffq50d4sTQKLoK/+hehpIZLZOK3GLpS iCFsXSW7/vQAxopY0sntCYqvHy+tUu5GHWlMTC08ILhSAoKk2TAQ52aRv63PZ6cW9JVe YtNWYNwvXSP9nmvdI8hbazNLYGA1AnIBAjlcpdgBxwQyIqaJznjGGEEE4aIaPFbH6mZa XW6WMTYN4wOTUpBMBT2B+xUWl8oxmF7yB+wCax+gV32Ln7ugyPeNgqmpA8PeZ1YOOdSh INBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767661433; x=1768266233; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=0iHJG05lFXNcNOBT5oN+oQTjn3c3C+wc56WQy98TbMI=; b=GZky5J6yyw3rNxPxQn8tRxyfjrOkoEIjvl8CE7es4+qlyqVmw8sOkylQyEnSIAiN9E m5wv3fnIaBXE1ObCKzsJJVgvifKOsUmQB9ng9+jt57fi+MD7xkqRH1PkEZCFUdhe5lcA LuPSbdlnaw1qvz//WmA9FvS0a2gVJlyVCkRJPJMPDro/fBK/jrk0T8kBabOizBjJ2DjT WyHPO6+EE2QBOvC6W/6Aew/N66cwo+9EAVSEK26C6iu+x4+v0q2JESSykHXG3tPF2pIR br9qT2f3Opz9mZCCR3uA5wFBQSsiism096slp4v0pO+XDvwNCgeTrXU9o0bNpSmhfpSY PN+Q== X-Gm-Message-State: AOJu0YzRHzdU2j30f2dsbIu4WeKiNg94GkJntYMinuciM5P7RHApyjeE wHqyWdPdBFLeCAz/dtOxR24EaZvDBan1hVDlFU+VHQ4wklebt8wYX6bOutS1dPFEwhoY0wjgVJf yMMV9cXlB5z3pSvo/YJITwMquurpDtjAbEBFm X-Gm-Gg: AY/fxX77rPVlWZyK7lInIqb3h30/dY/cVGd7x8WJcDPgV89YJIeTG1X4if2Xt2017yB EqRbEjZ1htrd0mh/XzwzfK4IJr4NchCM8e6sKD+bBb+5W9k/6AKObJ1gPmWdGXoBYpU3vYnvvua yOlHS3eE1QsX6zHirOhaNPWaHM6ksaR57qjH5lZra0qRFk32DK3/MNbg9t8pNsoT3tzL9iUOUGH qLJVe3i64OHGRZgf+J1iktSVRqvmQq05ALqoZ/i2arFNQavhE+AosDVAQq8eJTe3f7X X-Google-Smtp-Source: AGHT+IGzAbkf0LAUWOzJgVoyyfjWT7jXOwBnUdivCDVUdjoLENg89IGG1KBqseo130qpGMj8dY5YqpI8aKDXH5924E4= X-Received: by 2002:a05:690c:3807:b0:78c:5bb4:1d4c with SMTP id 00721157ae682-790a8af684dmr28441367b3.39.1767661432880; Mon, 05 Jan 2026 17:03:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jason Andryuk Date: Mon, 5 Jan 2026 20:03:41 -0500 X-Gm-Features: AQt7F2oYSUr5uDXUV17GVFvhluZAhf8r61RZRRacBrnTueZhYhwThOjQLegHp1E Message-ID: Subject: Re: Cpufreq drivers not working on T480S To: Milky Cc: "xen-devel@lists.xenproject.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Dec 30, 2025 at 8:50=E2=80=AFPM Milky = wrote: > (Re-CC'ing the ML because I forgot by accident. Hopefully the quoted > sections provide sufficient context) > > On Tuesday, December 30th, 2025 at 10:44 AM, Jason Andryuk wrote: > As suggested, I added the debug parameters to the dom0 kernel. Before or > after `modprobe xen-acpi-processor dyndbg=3D=3Dpmf`, there is no useful > debug information that I could find, apart from the > `xen_acpi_processor:get_max_acpi_id` message as seen below. > > ``` > # sudo dmesg | grep xen.acpi > [ 2.282851] Kernel command line: placeholder root=3D/dev/mapper/qubes_= dom0-root ro rd.luks.uuid=3D<...> rd.lvm.lv=3Dqubes_dom0/root rd.lvm.lv=3Dq= ubes_dom0/swap plymouth.ignore-serial-consoles 6.6.77-1.qubes.fc37.x86_64 x= 86_64 rhgb loglevel=3D9 "dyndbg=3Dmodule xen_acpi_processor +p" "xen_acpi_p= rocessor.dyndbg=3Dfunc * +p" rd.qubes.hide_all_usb > [ 5.224092] xen_acpi_processor: Max ACPI ID: 6 You successfully turned on dyndbg to get that output, but there is no further output. This makes me think something else is wrong and xen-acpi-processor doesn't upload anything. The call here https://elixir.bootlin.com/linux/v6.18.2/source/drivers/xen/x= en-acpi-processor.c#L557 to https://elixir.bootlin.com/linux/v6.18.2/source/drivers/acpi/processor_perf= lib.c#L421 goes into some acpi code. Maybe there are other messages in dmesg around the same time? Maybe you'd have to turn on more debugging to get them. > # sudo lsmod | grep xen_acpi > > > # sudo modprobe xen-acpi-processor dyndbg=3D=3Dpmf > modprobe: ERROR: could not insert 'xen_acpi_processor': No such device > ``` > > Maybe also with Xen's command line try cpufreq=3Dxen:no-hwp to disable > > HWP and see if the regular ACPI cpufreq driver works better. > > > > I'm thinking it's something where xen-acpi-processor didn't upload > > ACPI CPU data, which means cpufreq isn't running. That may also be > > why you see that bogus CPU frequency. > > After booting with `xen:no-hwp`, I wasn't sure how to check if the > regular ACPI cpufreq driver is operational. Is `xenpm` still the > correct way to query for CPU info? I've tried the following: > > ``` > # sudo xl dmesg | grep -i hwp > (XEN) Command line: placeholder cpufreq=3Dxen:no-hwp,verbose loglvl=3Dall= dom0_mem=3Dmin:1024M dom0_mem=3Dmax:4096M ucode=3Dscan smt=3Doff gnttab_ma= x_frames=3D2048 gnttab_max_maptrack_frames=3D4096 no-real-mode edd=3Doff > (XEN) HWP: 1 notify: 1 act-window: 1 energy-perf: 1 pkg-level: 0 peci: 0 > (XEN) HWP: Hardware Duty Cycling (HDC) supported, enabled > (XEN) HWP: HW_FEEDBACK not supported no-hwp failed to disable HWP. But if there is no ACPI CPU data, it wouldn't work either. You could de-compile the ACPI tables and see if they have CPU info. Something like: mkdir acpi-tables cd acpi-tables cp /sys/firmware/acpi/tables/* . iasl -d * grep -r -e _PCT -e _PPC -e _PSS *.dsl That could help confirm the tables are missing. Regards, Jason From xen-devel-bounces@lists.xenproject.org Tue Jan 06 06:40:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 06:40:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195811.1513709 (Exim 4.92) (envelope-from ) id 1vd0k9-0001IT-F6; Tue, 06 Jan 2026 06:40:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195811.1513709; Tue, 06 Jan 2026 06: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 1vd0k9-0001IM-Bz; Tue, 06 Jan 2026 06:40:37 +0000 Received: by outflank-mailman (input) for mailman id 1195811; Tue, 06 Jan 2026 06:40:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd0k8-0001IE-Lk for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 06:40:36 +0000 Received: from TYDPR03CU002.outbound.protection.outlook.com (mail-japaneastazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c405::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 982ae886-eaca-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 07:40:33 +0100 (CET) Received: from KL1PR0601MB4588.apcprd06.prod.outlook.com (2603:1096:820:87::11) by SEZPR06MB7173.apcprd06.prod.outlook.com (2603:1096:101:22f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.5; Tue, 6 Jan 2026 06:40:26 +0000 Received: from KL1PR0601MB4588.apcprd06.prod.outlook.com ([fe80::3f19:282d:5fe2:f523]) by KL1PR0601MB4588.apcprd06.prod.outlook.com ([fe80::3f19:282d:5fe2:f523%3]) with mapi id 15.20.9478.005; Tue, 6 Jan 2026 06:40:26 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 982ae886-eaca-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Zm9Dx6dDxlCFIfBwrOP2CiXMYM06LTzJCia0l0juR/DW+v94E+iE9eNpluSKwFbcx/aILx4WlsypImE+0CwMQ2ugAD9nUm8tjtVFVviPXD/3FItLGISfH0UNc/0mz7W4sbzs2IbQcc5EAPhI4RSeL2ivTfUtAvAC7IxWFMukv52J3qajyGJq2vIVM60TZFQl5aYRz37aZPloXC3lEGWcLw0mZGsQeOnF0pumb1CXLFvk5sSgf3S8i4J6YsmCnhjrL7ITKaQfn/LcZYMwX1pzfDXkxgdjSAzT8c/zhLtVNUYh3LkUyTOFaOFaVeI16nQ2VSy16R4J2XPR0sMcDlrhGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9Uv+NAI6jEJ5mTLs9M/JrTne1pihN67PjYw2suMMsoU=; b=yFbjJInn4qEWgIEqbe1De76ROoCvbIU7+LklLY2YqLCGQzt5Tzie4g+jtYozCUbOp+W3e+hjcbQKT86v5H4TrQG7C+42dDkD1aX19InMEpSeSWVToo3oFPjJ68y1bCxO/u7VkN80S6hvdSerMoczd2DgMp7JwzIN8mkUrUc2HBgx83IdW/9E9qHkrkV28XJFYplqwevJd5/dj8sCG+QsDajtreYVGvhyQ72SONSaKM2hRgPWtVxtjHe37eqvrGpQdS3HTQM1fu6SQOalaAELDF++bOmQ8ZuctTqHNDKcb6yUbB7yzgWOREBc+Zn+1ch7Y/tiaSE9euBw1sDDWg2LGg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9Uv+NAI6jEJ5mTLs9M/JrTne1pihN67PjYw2suMMsoU=; b=g6RG69mtGvapE/mRe4NCJGqNg0S1d3CEwm0yDRCkqHaNiyNdyVFKcNDzqI/aeVg1mP0gGWKEV04sqw3GAAMg9JgrqBJWI4SrcL6k7etRpjQiwxV7FUDvgrESGSWjFzkgvFz1r1VIzgQYiFOYIU+dLXCFZM/J7Eyx5/Xfvax2FeEehsaYSF31gC+euZ3eZYyJ82weNOr+mqd2MTUsGLbzjBzuxMaL/do4dYqy6vOkMqTvinxXxJYSVLND/N6Yll14X+VRxZrfkFtP1CG8iSJEK2wmD1s4MF5oD03OJE+bdqzXiWhK6g8p26Bwe0v/ZyA4q1xdwwePa6EVIpkYhdlmWQ== From: "Ashraf, Haseeb" To: Haseeb Ashraf , "xen-devel@lists.xenproject.org" , Julien Grall CC: Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , "Driscoll, Dan" , "Ahsan Khawaja, Noor" , "Arslan, Fahad" , "Bachtel, Andrew" Subject: Re: [PATCH 0/3] xen/arm{32,64}: perform IPA-based TLBI when IPA is Thread-Topic: [PATCH 0/3] xen/arm{32,64}: perform IPA-based TLBI when IPA is Thread-Index: AQHcaEpRSCjrYdYkH06BEtnycvkPLLUkOFKPgCClBPk= Date: Tue, 6 Jan 2026 06:40:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Enabled=True;MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a;MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_SetDate=2026-01-06T06:40:25.675Z;MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Name=C1 - Restricted;MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_ContentBits=1;MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Method=Standard; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=siemens.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: KL1PR0601MB4588:EE_|SEZPR06MB7173:EE_ x-ms-office365-filtering-correlation-id: f6c6ae12-a47a-4ea2-6f32-08de4cee79d4 x-ms-exchange-atpmessageproperties: SA x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|39142699007|31052699007|366016|38070700021|7053199007|8096899003; x-microsoft-antispam-message-info: =?us-ascii?Q?moZUyL+svQ4C6JMpZBRKB3bHUYd1hSOiVIAaURaLlN5tnmouNZvm+LaW+oR1?= =?us-ascii?Q?dJeT9T+Euq9QvWOhbAcu8+r0C+cL/wvaXKwQ0cUkPuFt1TitAm1Tp497hZF7?= =?us-ascii?Q?pYe93xKuEf0JD5Z3h0CIxEXTfLhMRXGrdu/Xq6xa4EDoCcUbvr0RxZdDxiTI?= =?us-ascii?Q?UCqQlay7FVSy3CGqQvNzuyMtmdxg3wPh8AWdyoIFgzhu76d8/4TfcFUlV1IN?= =?us-ascii?Q?sboaAlKFAoaDw6TdKAUWSaqlY6t8JmMe+PZRDaQf1EKL23B1Pw8IdGf0yDqN?= =?us-ascii?Q?zqaNCUxArzdsLDupltV+Cdk4gngIRyAG0ydUgWIBrwaEaImiLetIRuVbZnci?= =?us-ascii?Q?glPEachq+XZrJjlodMSMwOWyGfpP3dDDoQGytoqh7zh2JOAAMZWMO4B885Mt?= =?us-ascii?Q?MoD6FGwLAn3By2vWDIr+XUBN6XcuOUHfBAWWYU+l9VpmaLWmjHb8k0JV7ul8?= =?us-ascii?Q?s4+o6bWl670nrzgPHYanec7kKGfxjoIPzvojMJgONx5TBVdmowvEFnrac6yV?= =?us-ascii?Q?Z1mTtFPV3WLN30bUjDxoolb8GZteIOqDFYP/0qprQsXpJkC1IGyT9R51yvWi?= =?us-ascii?Q?MHQYi2qxueyOrarFEZldLDyz+BF/WHhbYGam5Czp8aHpvp6lCBeetc77CK9/?= =?us-ascii?Q?VU/Zue23SJ34oDu4PaTSWJZV+ZgSjkqwDaMfGQY4sH8EBn5otw38v97ZVQ12?= =?us-ascii?Q?QOxenKalzvP9pxaflGw6qxqikgUxo/scOZ/SrIdMPqpSboaT2hxUCZpSUzbf?= =?us-ascii?Q?lwpMTWhK5YN0K5ck8ybYc3hjHm3wT7ognW6KAqMWdL4H7k7LEiut3TTFV4Ik?= =?us-ascii?Q?c0RDzk5FNtqm/VcYtdRzXWCWtXeMm78Hdl/z0pYZ7EFJ1U3CRGPDcLq540wR?= =?us-ascii?Q?BXohaMwHO55nLtPXXbVzPXFeRIXfK8PiU8nFBWUv8BS/2wFXEol5rbxUDqhN?= =?us-ascii?Q?NI3CE6q0U7rdrr+z51tHS8T/WqgivmbeTDl1ft7PcdB9lG3sM76k5vWZv5Co?= =?us-ascii?Q?zkX9ia4ER+wqygjp13iJPQt2OMvlEdYWAuouz7xSKM+IqOf6EXJO6XeRygXt?= =?us-ascii?Q?22Q+b1UpiKX+WH5Bi/DM6Z7O9SwpI7E6cgEGemEC8vaxHRkxj8Ryza+B1tNe?= =?us-ascii?Q?E0zR3VqAK9bDtGwCePLyUwqGC0q3+S8jLtAirKztkbp4N2RdPxAjRXg9iUmM?= =?us-ascii?Q?NhxOn3z2n0cOTTbLNoRyEm6Q6HhlOBTYKyMQHcTjsywsioPtUusgsnB2Od/t?= =?us-ascii?Q?3X8+UwsnXuesH0qSZYutNevhOfIFMuyXtEQlm99CmBaFexsYL7TUbV1lEcHT?= =?us-ascii?Q?nkQVjcQHGMouZPhnPRKhTuK6nsPafoEubZq4csF21Ftjopxq7ikRyhSqasmJ?= =?us-ascii?Q?FBWifctC1BUFGefLMrUKU9yP82DCa5LQfr0cUagW80bobHvuyVDICgWsb7bw?= =?us-ascii?Q?XlXikvM6GEg5kRXYNSdHjkKeZZsbjtclxzR6D2wMGnz7v3aiGVnjK8TopAWf?= =?us-ascii?Q?yaobkiUC8dZDR9ohFMnuAmcQ84abC6hAPhel?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:KL1PR0601MB4588.apcprd06.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(39142699007)(31052699007)(366016)(38070700021)(7053199007)(8096899003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?4owgrbmzcZA84JLSwo8ytamxP3SxouLr7LHp2DnPJIPGOfH687S+4hZ8uuZg?= =?us-ascii?Q?MPEkTTMjztxwR2bWDYH1IJqm3KUuah5RG9NZ2pX8pEDRaLYEk9+2z95z/X0d?= =?us-ascii?Q?pW006o6iMqGf9x5sEiTMzxtacmHzvGQrRz45Hvbe5JVF+16b8UgPF5V5vB9Q?= =?us-ascii?Q?BPUo4K8qfxJNaE6XksSG8mpHSRLhybl38a1wOHLb8xboN7Ut6HAvXpBi35/A?= =?us-ascii?Q?HzWiiIPZUGulNAndTrnbFg+um0bLwk/CSHOrhKqEjTOuoQo3LgIlMEHYY4KP?= =?us-ascii?Q?y8/8gCH56Dk2bs3J4PXu/s/W6QO1ZdK1tMobDtm6O6M3t//+KQgdpubdE26n?= =?us-ascii?Q?8brtU17EKkvZXBuQth2yDOmPUQw3u/HLcunA6L8QspiFtM3UPAnvlvg7ppcY?= =?us-ascii?Q?4eSf6T1ZgE7PoagAz1R4v3AI39KiK7GvQfDG0G9hrf+mLtxzs6+iMy6iTxSg?= =?us-ascii?Q?qbIkSWzJAZxYMom5k0abXObotIA642cRGm0lzqWmm8tE5ZwtOyHo4FnA/xPQ?= =?us-ascii?Q?gv0YIVZeMBsNeofFDIFSWtMMN/16lzAqTG1F1LBnp2mdFMQmwO0vWiS4CTor?= =?us-ascii?Q?ajt5QRh9gTOyYNmyez29zFiDqulXA+SQrhPs2QSuyp8MShynZAezf+4gRJk1?= =?us-ascii?Q?gPy5PtiW0NpvDkJXp7iq7BaORjQvvpj7THmcpEAvKTzUzbPXBGpIm7xwZtL0?= =?us-ascii?Q?h0VNu5E3Wul2JOpRShJ4V/9vSXKtad6kDw1/2u5Jd8fIxbpbPg6EPYubneo+?= =?us-ascii?Q?DEXGDIeXBxdlANUwlqo6R1SAXSXzxG349M0lsonzXt8f1dTXLxo8FQ7tj86x?= =?us-ascii?Q?vRV3MtxOO5BKiE1OM+ir+rXRpYLLOp4D/bYOgUEqIzgn6NhP9Ug6IMXtxQwV?= =?us-ascii?Q?gPK2nx4UovPmHMmhaKNLnYs6pfSzSL1Y7P3zPFTpCsIqBvWHa5LE0IYUPfBo?= =?us-ascii?Q?OraC870nxB1pJYjOshEVowsygIgWLopci0FZ1SEAWVJ7Pbu7ckqq1k6MRq9a?= =?us-ascii?Q?YFPgoaWqD+lrjuMvpedqSudjERKLakz4AGfqEwV9iDCGCLo5vAc0ISS3i7tx?= =?us-ascii?Q?acYyk50Q0ZvAUywsvXBVt0BmhZ80oclguWeRgs6YnrrFnGJh9hpSZDrMlo89?= =?us-ascii?Q?MFdZOoc9ILlFyiDrWEW9t+whTgaExcpg+O9KWyyxzKhxexF8x+ezyz82GCyh?= =?us-ascii?Q?fzFXgEGRtNkHdMjizp08epPP0cG+MwDg8iF+xj18u1BcdrPGlofFIZMPp1us?= =?us-ascii?Q?5I9+F+lRifKrNm13kI0VYMyU0937pUD8d6nWth9F6eug6VaY6quxG0hmZ22V?= =?us-ascii?Q?UkGCYAUrIOthbu6YI00U6eBQMI7gUkLmtDUj54GwxAWIKtHWiUaRJqBXaD5y?= =?us-ascii?Q?OpJ4HtFHYvm9KRJ62QuOrmjJzRTRA7uhSpQfQ90xyyLvGPbsZQWEAO1Pfzwu?= =?us-ascii?Q?/3M6Q3yJ6srvxMs5QSNrqqDb8qmtYuMP4Z30Y+e+nddRfdpPc7CmDkwjHZcW?= =?us-ascii?Q?MgzcxkaKH7FLbfX2Aw09Y5k3Xpyg3hle360t3yFcCsdPDp2CkJDt6wTerlOp?= =?us-ascii?Q?jjn7uTDIVXksBCRhnl15ZcMhA9p425hvGdH4FiIPQzPtjc2Lwl32WzyrDuUD?= =?us-ascii?Q?V1HmaCjTQYEcFHRIJNj3uPsQoOdG6jZDBXSzzREuqZuMPnwo+lwTNDgYf2nd?= =?us-ascii?Q?nNZYvK+9gTQHF7psBtKSbdRxdmewiW26pByk9DR7t3a70Grc/Z5LTnPBmBvf?= =?us-ascii?Q?P+U646i40A=3D=3D?= Content-Type: multipart/alternative; boundary="_000_KL1PR0601MB458826078A6100130495FB26E687AKL1PR0601MB4588_" MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: KL1PR0601MB4588.apcprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f6c6ae12-a47a-4ea2-6f32-08de4cee79d4 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2026 06:40:26.2836 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: C+xh1jm5SqtN0pP92GdTj842hcfjHioDVOnxFD0RmupgFGuwgyqIC6BQFxYSdOEBIra6yXhl7XDdjFxbpgDrVwTW5v8vPDwDPQzrUu5ASuA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SEZPR06MB7173 --_000_KL1PR0601MB458826078A6100130495FB26E687AKL1PR0601MB4588_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello everyone, Is there any comment on this patch series? I want to get this merged as it = is a blocker for supporting Xen on KVM. Regards, Haseeb ________________________________ From: Ashraf, Haseeb (DI SW EDA HAV SLS EPS RTOS LIN) Sent: Tuesday, December 16, 2025 5:08 PM To: Haseeb Ashraf ; xen-devel@lists.xenproject.o= rg ; Julien Grall Cc: Stefano Stabellini ; Bertrand Marquis ; Michal Orzel ; Volodymyr Babchuk <= Volodymyr_Babchuk@epam.com>; Driscoll, Dan (DI SW EDA HAV SLS EPS TOA) ; Ahsan Khawaja, Noor (DI SW EDA HAV SLS EPS RTOS LIN= ) ; Arslan, Fahad (DI SW EDA HAV SLS EPS RTOS LIN) = ; Bachtel, Andrew (DI SW EDA HAV SLS EPS TOA) Subject: Re: [PATCH 0/3] xen/arm{32,64}: perform IPA-based TLBI when IPA is Hi @Julien Grall, Bringing up this patch series. Please have a look at it, and let me if ther= e is any comment on v3 of this series. Thanks & Regards, Haseeb --_000_KL1PR0601MB458826078A6100130495FB26E687AKL1PR0601MB4588_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello everyone,

Is there any comment on this patch series? I want to get this merged as it = is a blocker for supporting Xen on KVM.

Regards,
Haseeb
From: Ashraf, Haseeb (DI SW= EDA HAV SLS EPS RTOS LIN) <haseeb.ashraf@siemens.com>
Sent: Tuesday, December 16, 2025 5:08 PM
To: Haseeb Ashraf <haseebashraf091@gmail.com>; xen-devel@lists= .xenproject.org <xen-devel@lists.xenproject.org>; Julien Grall <ju= lien@xen.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>; Bertrand Marq= uis <bertrand.marquis@arm.com>; Michal Orzel <michal.orzel@amd.com= >; Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>; Driscoll, Dan (= DI SW EDA HAV SLS EPS TOA) <dan.driscoll@siemens.com>; Ahsan Khawaja, Noor (DI SW EDA HAV SLS EPS RTOS LIN) <noor.ahsan@siemens.com&= gt;; Arslan, Fahad (DI SW EDA HAV SLS EPS RTOS LIN) <fahad.arslan@siemen= s.com>; Bachtel, Andrew (DI SW EDA HAV SLS EPS TOA) <andrew.bachtel@s= iemens.com>
Subject: Re: [PATCH 0/3] xen/arm{32,64}: perform IPA-based TLBI when= IPA is
 
Hi @Julien Grall,

Bringing up this patch series. Please have a look at it, and let me if ther= e is any comment on v3 of this series.

Thanks & Regards,
Haseeb
--_000_KL1PR0601MB458826078A6100130495FB26E687AKL1PR0601MB4588_-- From xen-devel-bounces@lists.xenproject.org Tue Jan 06 07:35:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 07:35:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195826.1513719 (Exim 4.92) (envelope-from ) id 1vd1ap-0007XW-8d; Tue, 06 Jan 2026 07:35:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195826.1513719; Tue, 06 Jan 2026 07:35:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd1ap-0007XP-5m; Tue, 06 Jan 2026 07:35:03 +0000 Received: by outflank-mailman (input) for mailman id 1195826; Tue, 06 Jan 2026 07:35:02 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd1ao-0007XJ-56 for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 07:35:02 +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 2d98d794-ead2-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 08:34:48 +0100 (CET) Received: from DU2PR04CA0052.eurprd04.prod.outlook.com (2603:10a6:10:234::27) by DB9PR08MB6569.eurprd08.prod.outlook.com (2603:10a6:10:261::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.5; Tue, 6 Jan 2026 07:34:44 +0000 Received: from DB1PEPF000509FB.eurprd03.prod.outlook.com (2603:10a6:10:234:cafe::ac) by DU2PR04CA0052.outlook.office365.com (2603:10a6:10:234::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9478.4 via Frontend Transport; Tue, 6 Jan 2026 07:34:10 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by DB1PEPF000509FB.mail.protection.outlook.com (10.167.242.37) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9478.4 via Frontend Transport; Tue, 6 Jan 2026 07:34:44 +0000 Received: from DBAPR08MB5590.eurprd08.prod.outlook.com (2603:10a6:10:1aa::17) by PAVPR08MB9625.eurprd08.prod.outlook.com (2603:10a6:102:310::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.5; Tue, 6 Jan 2026 07:33:41 +0000 Received: from DBAPR08MB5590.eurprd08.prod.outlook.com ([fe80::f68e:1311:9070:68b]) by DBAPR08MB5590.eurprd08.prod.outlook.com ([fe80::f68e:1311:9070:68b%4]) with mapi id 15.20.9478.004; Tue, 6 Jan 2026 07:33: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: 2d98d794-ead2-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=M4ldH6Ir/tZkp/7UNQD7JCsDJqbldxrySSwaUyqPr40fFcufKWmt4YpnAQQvQskBqPyFLuRIuH+/Jp1SSRZLEbOJ3ZBVuBwhb05wT+4bU5P8SFnjG5pUHfC+Z9aPabUhdbN36LIH55e7JIzobiRSky7OdpUwZcnBT5hS256h8sInqBY8bsyF/ajxVh7uR8ZI65j55UjJLa/7n3uWQrAqU5hyczLc+eZ5ywNatARlX/vJlU+6L9brlnF+zQv+60PrfIAtmOIJgnEI5ml4p2vy9J/FQ7VEKYAZM3UIG9AF4DXK+0rBDcvhtEmj6+jic7qcONCJBVw3nFmtMbmkStahiA== 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=MRSbXfzzqUvu/4SAewuKbw/DWnOhJZsViMucTaOIFno=; b=UEeOMPZgq6KdXrBsfSRFj8qQK+Vkk08OVaXmy9rMvcCxTMHlczIqnrqtVfGTxDlW/XD1r2CenixldMLdvi/wGMFdZAUTOJzqUnwuGkZT9AZ1mqumaufFJ+faBW9JWo9/quWLVMvCKylukfmMh8P9HFHa/NPiODddBxttJgu2dAfzrFV14HVrkT6DuobaEOyUHCLmlG0079Ick50qx/6BXfhgq/ubrSbw0BavqG9uDgPH+z3wfYtq1l4Niwo5rx/5ZsyRzTJivOojiqaHiubzloNXIQ+d29HnmwmjvZYPM5cCC8XCdNePTfjCNuoBhbOJk4JpOV9BzIg/wqJtVeeuyg== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=citrix.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MRSbXfzzqUvu/4SAewuKbw/DWnOhJZsViMucTaOIFno=; b=MN1FpV8L11xLlAHnFifqMiOJb0duyeugDF+GNjem3sj7D5nk8l6QrHozNjqISSWv4XrzYofa2UAbVi+bQeHIY5tXZfvzsOMWJ90HT4qbqLQVaxkANJ8g7z01bm1zd4q+9wXcj5tzi2Lw0Y8sTvy9jIi0v8vZWkuGpNTnnfooDp8= 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=dg5eolmfG7RTjZ1gW5ysfJ3ukRZjSP+/RsCRgBXtGv0WRFr8sZLPwplWuXBV4pmqGAvMA+YWlJxkklUfftBzd6sw5ov9qT1SNFQOxrmTaVYQu+AQhdUfIbQh7q4O1AYaYgktvtiBTjtm4Ra5tR4WEwWMPiH7K5Dbl1hfq8tb3MUwJZbLR6qmP+OtuqWoiGvq407cDagdybI+1zEN5Nsh+1C4+atCzu2RQaPOpsxQkrnjRzCdTzcShkr0Ygsg+xE26C3cIQxMqs3Sri9Z5MWpO9n7l8GMkbb2eDA8rjcqoWXyTZn9U46rvvdZ9NNhP4feCv6h1fMFxHhBYe1G3k9rAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MRSbXfzzqUvu/4SAewuKbw/DWnOhJZsViMucTaOIFno=; b=rvLMZCGVHJuwtJXDn3ekqVDsttYIaDJshfrKORRfYgDkObwO+lm0afAyRw5+jx5TW8JETioS9IrHngyf4TzHjmrPM5uN7FWyymRZTzg9fS2ydj1Y1oZnd22r9+Bq2HXywYlA34vnT2uA2YlbYiN2ZaiekABfX9JQI3ADXlDyBUcLki6SqJlHCQX+01FK6svFUioy5k+v+h7b7vO/MXl0GkxMKkH9URrC3K/T/IEpmaqE2EqbJr/CFAjg06hTe/UgV5sT/8Kkh8HtDIthmCcDP5zH9ATFAohaMerDpI/qnPKxaKxhwRQx+roBoblpGgE/WrzH6inH4BlJNZdipzm2Vg== 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=MRSbXfzzqUvu/4SAewuKbw/DWnOhJZsViMucTaOIFno=; b=MN1FpV8L11xLlAHnFifqMiOJb0duyeugDF+GNjem3sj7D5nk8l6QrHozNjqISSWv4XrzYofa2UAbVi+bQeHIY5tXZfvzsOMWJ90HT4qbqLQVaxkANJ8g7z01bm1zd4q+9wXcj5tzi2Lw0Y8sTvy9jIi0v8vZWkuGpNTnnfooDp8= From: Bertrand Marquis To: Andrew Cooper CC: Xen-devel , Stefano Stabellini , "consulting @ bugseng . com" , Nicola Vetrini , Jan Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Julien Grall , Volodymyr Babchuk , Michal Orzel Subject: Re: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible Thread-Topic: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible Thread-Index: AQHcfj5G7fNp7PSkb0GiHPxZx0yorLVD4eGAgADfJYA= Date: Tue, 6 Jan 2026 07:33:41 +0000 Message-ID: References: <20260105122436.555444-1-andrew.cooper3@citrix.com> <82d99c52-c39b-4fbb-bbb2-0e952df91673@citrix.com> In-Reply-To: <82d99c52-c39b-4fbb-bbb2-0e952df91673@citrix.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.300.41.1.7) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DBAPR08MB5590:EE_|PAVPR08MB9625:EE_|DB1PEPF000509FB:EE_|DB9PR08MB6569:EE_ X-MS-Office365-Filtering-Correlation-Id: a8f7711f-b581-4b58-4ffd-08de4cf60fef x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|10070799003|366016|376014|7416014|1800799024|38070700021; X-Microsoft-Antispam-Message-Info-Original: =?iso-8859-1?Q?obsnU5WKvrUo7fAZc6GhmEa69/If3m8mOa2cvAKdBCpvIzsmPsoYcJD+/7?= =?iso-8859-1?Q?2CojQ5hze5bRWroXrhCtiwRkCz9Go81ZG9J7jKWCQH4IgkdjGcJMRGIgFS?= =?iso-8859-1?Q?PqjdId+c/Zva4v9DauYFUBogYoQ3RuREtBkTTREpaJghR4LcPktgRwa4W8?= =?iso-8859-1?Q?pCStFc8gK4jH97mYRkOdeEkYqtdPjcv9vztPN5NXlV6eOwUFdE5r0Xr3Le?= =?iso-8859-1?Q?6usLYoQMDTOZRmWRAyroTkMHy2uAB5rrTzgsdVdlzk02Fx5MhYos4ono9x?= =?iso-8859-1?Q?5GDjmZr8GdeB4pUfXmPP0WoClMrxWKuTIA5ew9MHLh+ANjhZ+DjlVTBaOb?= =?iso-8859-1?Q?72FsR308OP9IidXd66Lbi2uzJkjwqRRdK1pd8mUkViwgar0h3eW3AOJD/t?= =?iso-8859-1?Q?dlAtfhKxNBSu5GjOsPKmjgS+dk88li/81BmlDd4UcpryHkp4IqFxnFCTEk?= =?iso-8859-1?Q?d2DjQQEQSf3ln8F6QhWNbt9kTVbxqMz/nFVQHCPzlCqggJNvhKgsZyZSoX?= =?iso-8859-1?Q?5NbFsTQNlHSI3ECazqx3J1DLk41jUZ7CJr5WkQDZNmcOGdFkIt9tg/t4Ai?= =?iso-8859-1?Q?GzbxOyomaJkSjz+Aq7XbQ3DgvOA7SALN40cI9kD/uif2jocMW4PFEkQcj5?= =?iso-8859-1?Q?s3yNusu1Bn1XRIyTsbnbBquGmcYWTRV/010z94F+osq8Ws9BniWnV1vEPv?= =?iso-8859-1?Q?DC6sgRFTXODIhzEitHVWlYQvxLYpLDzffmGu/zw2fBucXhlAupAQg3LWdM?= =?iso-8859-1?Q?k6oTaWQ+dS8ffX155wsjO3ETgKUgm2rA2SCNs2kN7zn9l08N28bkVjYXCc?= =?iso-8859-1?Q?cZKxi2BnDc+vzEGGNGS50Exy864reNma27IggESTIQ0Qqm2byzcvH6b6tT?= =?iso-8859-1?Q?FENJZeW9PNIlRJHZt4UBEjkJzzzEOTd2RLS6ekl85KO8XJrjOHJ59SMSdF?= =?iso-8859-1?Q?NvXyd4i8xvi84SyCDSBocs5g6HQ3E8zpkJeDUZH+yfGn33KMuQr1K9l8Pn?= =?iso-8859-1?Q?nLNG2VmiXJlfZIpfdAjO235ZALDP690fzjJbTzvjE1x3XVbHM8Pz5tb/se?= =?iso-8859-1?Q?3UCale3UzovOhKFBqvfHmS/Y+yX+C4Jgx37y572UMGN6zxdytIIeruNNX/?= =?iso-8859-1?Q?PYZoUw0xDGEU7n2vuigOenur7gB7slA+p8iYQcp2rWUSSvQFiuM1Sgd5Gm?= =?iso-8859-1?Q?XU6WvjVIBPBVZYnYUAH0f4Uu0BQPba6Gdsxb673dBtnGj6x8xRq6iR8cSq?= =?iso-8859-1?Q?/Qc6g5WRVYUcna9mYWve6o8Z2DvJFmc/tivWEY69Sy7DLrBWpDDmvSUMv+?= =?iso-8859-1?Q?d8C1ZmUVvCe8FVNEtzWUWhnxwX0ca+a1mCxvrep0+hPILhMOHpzQSFmNb/?= =?iso-8859-1?Q?3L8OezFG5Hv252P9iuJE3SDEFSPi7TEozcaYaW6bT71qWu2M46PSn/omiS?= =?iso-8859-1?Q?5/FW8IuLZhvs4g7pe4rAve3G6YFJyygz4prxcziSiJ7Bix5hA0BLvzzknN?= =?iso-8859-1?Q?E1oQUSlfIy4GuMVxzit6eQwSYiyIc/GQGNf5CkSMqFe0TwAqLPG/+8B6mn?= =?iso-8859-1?Q?sJ79MVehCYph5d8uEroP3gsye8hJ?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5590.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(366016)(376014)(7416014)(1800799024)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <48AE3827746C4D42BD37529AAF9FF18D@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR08MB9625 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB1PEPF000509FB.eurprd03.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 099a91a1-2f31-4db3-310f-08de4cf5ea91 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|36860700013|14060799003|82310400026|35042699022|13003099007|7053199007; X-Microsoft-Antispam-Message-Info: =?iso-8859-1?Q?UdASsxJQJ33NAiY9QlMk40yvxPH0ciW1SM8XqVLtO0/RZ+QxI1gqc9XkbF?= =?iso-8859-1?Q?X4tORGH1IPaQOJCRxtsi+g93BE7RJ+NqEKFkBHRVE0dwXZvA4F4xMAYvbX?= =?iso-8859-1?Q?wms1gtp4tT0gNdNDS1wrsj2BNdeAlRU1wjbei3K/RurUVGSbyXN0mG3rAb?= =?iso-8859-1?Q?2u9ekW4laacfzvpdq8Ly5ac4I/nOZ8X5B5EpNjit1sCQT8yLqRpX+CukOI?= =?iso-8859-1?Q?0LRBVZ/tm6RFG6FTr2VgTJ7w/pwiWX9LmkZNF1PBQgrLlOmCoJf4xdbQKc?= =?iso-8859-1?Q?VlCLf8LNukf1uu5mGU3G52H8WLlgwqxjbU4Kc8ZF8rvJOfIPvZLekSbva2?= =?iso-8859-1?Q?IGEvSQorHRHGx5NhF5g8f42kHUptPSjaIl0KCSaplfpc0h4Bf8/NxCSKqe?= =?iso-8859-1?Q?H69rjuM77nNk+/9GjJSR7OpDKRuzuEhL4uyU+oG1+5CE4ERdqe8NjScAGi?= =?iso-8859-1?Q?pdU4nrlgMFSUid79ja5R2G+lMWHTvREMnbFtike2Oz+FBV0nZsqvotsojN?= =?iso-8859-1?Q?iWxluW7OJqspgtWE3Gm89ANu6BoU9klwGjV/fnBrMM0L6EwzxyTTUWFCQw?= =?iso-8859-1?Q?N+a0pO02k0TsPK5UZPg1ZzKPDq1vxaf07zUAtNmvaquEwusMFtfxVNPuJ0?= =?iso-8859-1?Q?b029mKS8ou/adh6fYN8C+3wGAZXos95G4Ka8w1w76UMXHqVfeJGhSiLloF?= =?iso-8859-1?Q?KWkUMqs1zccQnnD6oYSP8JduPQL6jv0AjbPT7m1zeDEr25biJO8MZquKDZ?= =?iso-8859-1?Q?u9XjoJ3tXJ8t2DmWziNN/+3g4DRlMKikLqvzZhbx48JIJZEW1vENd0Ulrv?= =?iso-8859-1?Q?b27sa0kgI5C9jYWmOqtGl6lDR7w/U9MKuKN1UBWdqUCsmnEVxZoz+tgzrh?= =?iso-8859-1?Q?HL7dp7ENsnYMmLgZYIXbuoMI7BwLgwCnaLB0Huuh/y3vqtk/lE9PRGoQ8N?= =?iso-8859-1?Q?pyJR65r3ArrF+XIzeRduh5C9I3D7nHcikNzU9rw5ceVxE0t2axbAXuw6Rk?= =?iso-8859-1?Q?U9s/jOEZUMn87VsmvJs0xyH5wKwbHPJDiriSRdRuKvYDscqVp0mXe19I9I?= =?iso-8859-1?Q?Atkf+dzVkVKl6/5IhkOkdfUv5bqOuaLRjfG1Ae0Q3NESIhO4UW5dpxRfXi?= =?iso-8859-1?Q?nVqV5PMdg/q7DUrUz6OMxtM8ODnbbHz4k/8GO67+iUa1ie4SSmr1sJSBWN?= =?iso-8859-1?Q?UdwolhAo25A/qbwY0UaLm98ujCU3qtCIQv7xawRHKiE6srZrsAR+1y4yR9?= =?iso-8859-1?Q?y6gH4zmf+d3Hp0G8zTyTSO+5KiIdPADqQyZ53Slm4EbjzT3VzT8RHsJfh3?= =?iso-8859-1?Q?M+RyH8/Dyfh/hMbjxAr2iP1xUFFBwWJWwhmRyA9zCexVc8vK7atJMbZ3t2?= =?iso-8859-1?Q?BpkrsQc1xUyiHUozOSr+L8IPnrK4YaJzIqUDoH+g9eZPmA1IXm3MXU8ION?= =?iso-8859-1?Q?HvbaXSKEgHTVtUIg43AfelKomJn9g3kaqCW6QhVWwiQbloWcldsfriQ/F4?= =?iso-8859-1?Q?UWNnzKFF+Al53Uk32/1R+nD/mGEiM3M5ZpuBusHBjTe+9q+tzEv/4ylB7W?= =?iso-8859-1?Q?OFQe/03mvpvIn4h8lBv7GFMaBwLynYoq5XKpIS/lvuWhvpLOTCB7vVT7f7?= =?iso-8859-1?Q?uTtSIgz4yWW+k=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)(376014)(7416014)(1800799024)(36860700013)(14060799003)(82310400026)(35042699022)(13003099007)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2026 07:34:44.5218 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a8f7711f-b581-4b58-4ffd-08de4cf60fef 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: DB1PEPF000509FB.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB6569 Hi Andrew, > On 5 Jan 2026, at 19:14, Andrew Cooper wrote: >=20 > On 05/01/2026 12:24 pm, Andrew Cooper wrote: >> eclair-x86_64-testing: >> @@ -104,6 +122,33 @@ eclair-ARM64-allcode: >> LOGFILE: "eclair-ARM64.log" >> VARIANT: "ARM64" >> RULESET: "monitored" >> + EXTRA_XEN_CONFIG: | >> + CONFIG_ACPI=3Dy >> + CONFIG_ARGO=3Dy >> + CONFIG_ARM64_SVE=3Dy >> + CONFIG_ARM_SMMU_V3=3Dy >> + CONFIG_BOOT_TIME_CPUPOOLS=3Dy >> + CONFIG_DEBUG_LOCK_PROFILE=3Dy >> + CONFIG_DEBUG_TRACE=3Dy >> + CONFIG_DEVICE_TREE_DEBUG=3Dy >> + CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=3Dy >> + CONFIG_EXPERT=3Dy >> + CONFIG_FFA=3Dy >> + CONFIG_FFA_VM_TO_VM=3Dy >> + CONFIG_GICV3_ESPI=3Dy >> + CONFIG_HAS_ITS=3Dy >> + CONFIG_IOREQ_SERVER=3Dy >> + CONFIG_IPMMU_VMSA=3Dy >> + CONFIG_LIVEPATCH=3Dy >> + CONFIG_LLC_COLORING=3Dy >> + CONFIG_OPTEE=3Dy >> + CONFIG_OVERLAY_DTB=3Dy >> + CONFIG_PCI_PASSTHROUGH=3Dy >> + CONFIG_PERF_ARRAYS=3Dy >> + CONFIG_PERF_COUNTERS=3Dy >> + CONFIG_STACK_PROTECTOR=3Dy >> + CONFIG_UNSUPPORTED=3Dy >> + CONFIG_VM_EVENT=3Dy >> allow_failure: true >=20 > https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/12604499722 > shows 122 failures in otherwise-clean guidelines. Some observations: >=20 > llc-colouring.c uses binary literals. These are safe to use now since > 4.21 with the updated toolchain baseline, but the Eclair config wants > updating to allow this language extension. >=20 > ipmmu-vmsa.c has a git:// url inside a block comment, which is > considered to be a Rule 3.1 violation. In principle this ought to fix it= : >=20 > diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automatio= n/eclair_analysis/ECLAIR/deviations.ecl > index 7dee4a488d45..8f5fc6c93bc5 100644 > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl > @@ -60,7 +60,7 @@ removed by the compiler, the resulting slowdown is negl= igible." > =20 > -doc_begin=3D"Comments starting with '/*' and containing hyperlinks are = safe as > they are not instances of commented-out code." > --config=3DMC3A2.R3.1,reports+=3D{safe, "first_area(text(^.*https?://.*$)= )"} > +-config=3DMC3A2.R3.1,reports+=3D{safe, "first_area(text(^.*(https?|git):= //.*$))"} > -doc_end > =20 > # >=20 >=20 > but I've not tried it yet. >=20 > There's a R8.4 violation against __stack_chk_guard. I think this wants > deviating locally, because it's a fairly magic construct. >=20 > Other than that, there's a smattering of violations. Some will be fixed > by some work I've got pending for the x86 side of things, but most are > specific to arch/arm/. >=20 They are quite a lot of violations coming from ffa. I have a pending serie on FF-A waiting to be reviewed/committed. I can push something to fix the findings after it, if that is ok for you ? I will retrigger the CI from the branch corresponding to my serie and work from there. In any case, very good thing to activate all those and check with the CI, t= hanks a lot :-) Cheers Bertrand > ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 06 07:39:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 07:39:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195836.1513729 (Exim 4.92) (envelope-from ) id 1vd1ei-00088t-Nx; Tue, 06 Jan 2026 07:39:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195836.1513729; Tue, 06 Jan 2026 07: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 1vd1ei-00088m-LC; Tue, 06 Jan 2026 07:39:04 +0000 Received: by outflank-mailman (input) for mailman id 1195836; Tue, 06 Jan 2026 07:39: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 1vd1eh-00088g-6q for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 07:39:03 +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 c490df79-ead2-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 08:39:01 +0100 (CET) Received: from AS4PR09CA0030.eurprd09.prod.outlook.com (2603:10a6:20b:5d4::20) by GVXPR08MB11536.eurprd08.prod.outlook.com (2603:10a6:150:2c3::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Tue, 6 Jan 2026 07:38:54 +0000 Received: from AM3PEPF00009B9F.eurprd04.prod.outlook.com (2603:10a6:20b:5d4:cafe::66) by AS4PR09CA0030.outlook.office365.com (2603:10a6:20b:5d4::20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.2 via Frontend Transport; Tue, 6 Jan 2026 07:38:52 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by AM3PEPF00009B9F.mail.protection.outlook.com (10.167.16.24) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.1 via Frontend Transport; Tue, 6 Jan 2026 07:38:53 +0000 Received: from DBAPR08MB5590.eurprd08.prod.outlook.com (2603:10a6:10:1aa::17) by DB9PR08MB11545.eurprd08.prod.outlook.com (2603:10a6:10:606::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Tue, 6 Jan 2026 07:37:50 +0000 Received: from DBAPR08MB5590.eurprd08.prod.outlook.com ([fe80::f68e:1311:9070:68b]) by DBAPR08MB5590.eurprd08.prod.outlook.com ([fe80::f68e:1311:9070:68b%4]) with mapi id 15.20.9478.004; Tue, 6 Jan 2026 07:37:50 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c490df79-ead2-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=jmAHBBahRZ8OO+SRYTTItkLTdqqKdQS4fdSXVYZglsO/tY4mTGF3hmSmnJnAX5oGnLtkw5JhqMff+vX0gI/4D4G117z6PiWp94hQsvEplKBt9vWapntavuJXz5TK0NBI/7MF5+J0ZHBVC/UgK32e8yFiB82/pDMycxMnbon799xjB6wcEC4PEfuTrL2I889TxePb58VXB/E9ONuTWq7/PUT3cwl6DEbdHsmpnLhVPUoM9BN3h5aHB6wgs+WWgf1MXdhe42AC19UhC1Ux5f/3EYCY0AslQglKe0USC2XLICEWmLS6v2lRa8i/0oj6fGM0z/ywoIEuT4FUCf+hw0Gagg== 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=6Dwqc33X5Dlp7xZffu3FfBk8YWW4XA667tnXi8LDJnY=; b=pTnavakCzvR7qzJDIa39A1UPoPQ8mqMDie1s63V3qt6CtXQtMF+HktI9vivdOTmccyAXhzlpB3Sexjopz6qMNUH8D2fYCmDh+p9pzX30U8CZ1dISxZMgLZbQ81bQAp4bo8R+MvB5n/rTjOWAUv6yg0IJZpb5QRbAJtqTVustrZeKtN4sgwXeTIoS8sFFhufRXLkFboMKozJ0PDIas+h17Fu5FPPcVceoXAZXdJFmoHUS5OpKgUul78dJCNjkoiyXwLkMAcnBDMFWI4KMsOCu/0gZEpWVjezADgs6P9xc4NjUY+qjQ5dJbpyLKnD1Eg+dnwuD1h+18pOP1YC3TANH/g== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=citrix.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6Dwqc33X5Dlp7xZffu3FfBk8YWW4XA667tnXi8LDJnY=; b=Xjc+banGmePP60aYtfBxTNBl08ysc+hp5IoXdbjz1t1EHhTLKmb7BoDbG+L1kWmVWNyLjYFIq7KB8f0eX8YY+tdqTB9nqOZbIvhNsYKqB9VVzrYaR6shnonA/Mu8BI2DCuhGFbpgL9W3JJzJRROIyNaQC5ny5PambLFP8aGiL0M= 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=EpoXJlaiwVIk6nhBVH2sQXQ3KQNBUhMYMhlrp30rYnahrHc3SG8m+dFOkhJX/CmEjqCMP5oWXy4N7pWKCwmj/3XqgO6/3IhmmoMYrUXahLG3lWJ+ppo6+gHpCHL0mocuX57+yb8HuTMiL+k27XaqYIepy64qbi3X6mBfigmyDyFrTbHiLjrKd1AxfVcDRLF3WN7t7LUq3LD1+GgLL1Q2roRrhc1BmDfRRHxwh3wBLCUmRseZuGxPbJpJdoXkT0DFWiDfDkKJ/lxXjO0yVI3nkbYgiN5pV1Speln7ACtT2V5wsdryjVWLKcJJk9M04lPLZ0thUPCY53tIHcVSTj2aaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6Dwqc33X5Dlp7xZffu3FfBk8YWW4XA667tnXi8LDJnY=; b=M7o8DaZHAmRDGA5EAJZl8ObgwA8++qOPmBchYSXd7RjZbdNGCogZbaU3/Wt6s3/uWxx5wKzk5lPMHG36jn1WzPBXDR9ZDzwUSMhJnKHa1WybtT4d+wHMFJQend22948g6iiJzEgJGPe3nWfPr8FpTvm6kmGiwYOJZCuN2AqKFqLfgBMPUgHEhZiTk+q01kmxrRORb9/j0KXJcbecNR/b9cyO/9x7gw/hO/yQVZiJdUBfLY1IONgsvPqlsTlG77hGlYe0IW//CZreOGXC9ezuTjNKMCojH0NbXf7erDkYjAdLa/tAIyG8WjBbTVfP/U5rWlmsLz9Al4XFFAQ6CDEn+w== 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=6Dwqc33X5Dlp7xZffu3FfBk8YWW4XA667tnXi8LDJnY=; b=Xjc+banGmePP60aYtfBxTNBl08ysc+hp5IoXdbjz1t1EHhTLKmb7BoDbG+L1kWmVWNyLjYFIq7KB8f0eX8YY+tdqTB9nqOZbIvhNsYKqB9VVzrYaR6shnonA/Mu8BI2DCuhGFbpgL9W3JJzJRROIyNaQC5ny5PambLFP8aGiL0M= From: Bertrand Marquis To: Andrew Cooper CC: Xen-devel , Stefano Stabellini , "consulting @ bugseng . com" , Nicola Vetrini , Jan Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Julien Grall , Volodymyr Babchuk , Michal Orzel Subject: Re: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible Thread-Topic: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible Thread-Index: AQHcfj5G7fNp7PSkb0GiHPxZx0yorLVD4eGAgADfJYCAAAEpAA== Date: Tue, 6 Jan 2026 07:37:50 +0000 Message-ID: References: <20260105122436.555444-1-andrew.cooper3@citrix.com> <82d99c52-c39b-4fbb-bbb2-0e952df91673@citrix.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.300.41.1.7) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DBAPR08MB5590:EE_|DB9PR08MB11545:EE_|AM3PEPF00009B9F:EE_|GVXPR08MB11536:EE_ X-MS-Office365-Filtering-Correlation-Id: dab7e027-4446-474a-005a-08de4cf6a42f 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|366016|1800799024|10070799003|38070700021; X-Microsoft-Antispam-Message-Info-Original: =?iso-8859-1?Q?qDwSalro0T8GrHVsDOGpDGi/Sdx+E5niSHRkj6nTghvEQFX5aijb3XnKLO?= =?iso-8859-1?Q?vsMJ3tLpxe+K0Z71cX/fvgHZ3BhwQgKkYU/LwZhCwSjwpfPRcrCZHcWulJ?= =?iso-8859-1?Q?1s+3SFOBb8tD3jNIBsfy41zvGahgEqRg55velP8S4kFtX0mTPo8f+b6Lte?= =?iso-8859-1?Q?z+qyqqQ596WVFEphru2xC/t/jK/8N14bl2AIN7c/ZN9nox3bH5oBYQ+UWs?= =?iso-8859-1?Q?1m/A0Iu4Zj60hRtuJkUgeA+hMxsbQrwTukPTb/wcMyzGP4tUo/lbRKW5bG?= =?iso-8859-1?Q?AOxSReg+KeWS5TmLXUK1Bnr6/TTPZPousJkTf5HbltsQRHzGckyKJGISQD?= =?iso-8859-1?Q?eq+RaHc7y3lz9irNoXqh94hFmk+Ij9MwPYksnI5gJqxOw2eK94Cnt6zb8J?= =?iso-8859-1?Q?rXt1P1sHFaAlLNaVzHgbwbiHFeiaZ4B3jlRxDXk1gmLZYaTceYeK4c+pHW?= =?iso-8859-1?Q?GBCLwwPxjL4UWOr9+akSuhUYKed8Kt3aF5oSM8HMkUJQ8nNjO8rUR3qfjN?= =?iso-8859-1?Q?uBOs+e0SBva4EHXDhtNbrCAwrtOPCXGX5lUw2ptTgFmsyRhthhzmlenvlT?= =?iso-8859-1?Q?++RD6qXLfZC0Sy8TZVAne+4Qz2g/Fl8qJZqgDIe1nVxEBtIBMZp2OlogMp?= =?iso-8859-1?Q?LKMife8Z6NZH7Y9N9e/jBgaaF1o1bNqN+mtvbEOLlr6OId9clg27DjTYTJ?= =?iso-8859-1?Q?6xBJL9NurKS4tB3kARTHY0T6dQ0KuAQ5vhyGJ6ewH/zhV2UfR0M9xl7fam?= =?iso-8859-1?Q?ilZlhsIlGlfyja9iEFgfLdwsSfRr6P8CXQrByVv+FOsg/MTtvJ+bT+4h2r?= =?iso-8859-1?Q?+lzZXDOEJIHTT+HWbcPLjNoTh4CNcZ0YEn1WFBgHXuC+s9uI34fFD+8Typ?= =?iso-8859-1?Q?zOzv9jM6Dm3HOYQBn+UG177GYdrkXgutLV2Y2i5YEpH4bjaKSldk81ThOE?= =?iso-8859-1?Q?Aa0wxyo4iY6c6M2GqPlqml2y0C06hCXkJvuf3ZutYWTkVJx5HLX2hpNPAq?= =?iso-8859-1?Q?gICSf0tAl5XhTtT6X4gCXIVsaYGSEPxmWffKAtZP4+btlZKlDEtQDLmbYT?= =?iso-8859-1?Q?RkTs4JzBHlOXJzzkt1jkdRWc9VayX6nJ/oucandURc2b8zZQLaPgVLCnII?= =?iso-8859-1?Q?dAzzQAHV7JogDdMNbkFKow9xjrvTgoVOip9dGI18NeHcwbddzQpPFEIVEr?= =?iso-8859-1?Q?NCqu+skSKwJgi9s3u1ZXLmp3BhcD1MtVUVt0x90ILoR90xrzLaEUYZce5J?= =?iso-8859-1?Q?D81IdiGE98bPaaaEo3AYFMR/rywZDQonDrLd1lO2HWS87ScqMxn2o7OW1m?= =?iso-8859-1?Q?KciobBuZJCY6ngqwDqC9JI0NLMOPtil4aj4sxIB2WulkiMFM1Ykcq0IDAT?= =?iso-8859-1?Q?a4jEJscX4cLUdCWVIohexBS0yZJfiA0iRXroqKoIOUbFe+YKLdYsMX19si?= =?iso-8859-1?Q?YsAkzjGdpmsUhtLODFkX9tPWFuJClP6iQjjxDQ5ugyQdsNvXRLzzf4MbWH?= =?iso-8859-1?Q?GYQKxEGzeneMOtZD+fZ7GbxEP5DTsAH832F/7LmJKsdoTXc8Ei2POMKo8t?= =?iso-8859-1?Q?hwNuC0ND5GnsCAfws8enGNil1HTt?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5590.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(366016)(1800799024)(10070799003)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <84B3E08D5F8E7D4698D75E7DCFA15C9E@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB11545 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM3PEPF00009B9F.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 77fc7f67-0623-4b72-78f0-08de4cf67efb X-Microsoft-Antispam: BCL:0;ARA:13230040|35042699022|36860700013|1800799024|82310400026|376014|7416014|14060799003|7053199007|13003099007; X-Microsoft-Antispam-Message-Info: =?iso-8859-1?Q?10VhA6oItr6dnAjsSFiSRIlTEcunAm0lWVoNrZuhmhQ4mGacxqQ1LIoeZu?= =?iso-8859-1?Q?4BMEp6Y5PL2Y12u0JceYDZQFHwwtKNY9ngw5Wn8d413l5MbPxCYctSTp+4?= =?iso-8859-1?Q?BdHpOKDstM5QN/sLNRbbFTjmfu2D/i284O2bZh08IHvIL2uPr6QW3lQ6ig?= =?iso-8859-1?Q?5zyBLollD1u+EriNxujinEaBIBuekukjJy3OIbi4KQf72rHau2oC9i9jge?= =?iso-8859-1?Q?0BFhhICvjSTao3ZBJsRmmOLYOBVEzo0ozCUJiLr2rQj5bJ770M3iWOcDh2?= =?iso-8859-1?Q?MbZ9HIniiD9by067kKwPw5cdIxYngU4UWWDfI6LdzYH+9SSFsMlo/rMUCr?= =?iso-8859-1?Q?M1DeoZKxvgNk+AOY28X/kPlF+/NG7L5Je/WQE3UGAxbJB/Idhg058OD4i/?= =?iso-8859-1?Q?fHF3OvXcISoQqUbpwRZovon2UyBBOKbWZbMu93aFSLHO6tbhL4Tfs1BQ99?= =?iso-8859-1?Q?NLvpTZWGOYEK6du5Cw2SXK7KMAiQzfl/2zU1H8A+RkmD58AC0BmZ2vyqgA?= =?iso-8859-1?Q?zoAz8/Ima9Tlu0bZMnraIAXFi+bxXL2NCCCQMqw0d+cSumS6y0vEofO0jR?= =?iso-8859-1?Q?yzrZ9n9kftOCqb2qyLT+FuJQiRgF8uF5C8iQywoDIvopIJgLs+fzGI3Ow9?= =?iso-8859-1?Q?NKoufBTpZJ3kyE/qzDjN70XCQgxFCNqgQo17COe7ITnlABD/oAmgaC+TYA?= =?iso-8859-1?Q?94Wa6AOgbkvHB/HX10HJU0Ww8Zzzw0WXyG1WQ7MSVhTwy29lTqYW0WZ/I3?= =?iso-8859-1?Q?FHJHhBB5gml2Ct2c5EuTzLPiEsYGDrPVUaFulptSokXbeqVGYj0xdvwDwz?= =?iso-8859-1?Q?2UEFpDYIAw3NykzUJ6btqDq/pR5dEiQvDGoWsYX4GNl9v73JiD6BtANWqR?= =?iso-8859-1?Q?6AmVxW68yuZxFZSURjS2eFLkxP1pTEvhtJONGXKzrkJEUwlq6uS/WIAems?= =?iso-8859-1?Q?vWp5vC1LrggijS4/pGD/4yhZ9AmPkfuEDA+eC62gOA85cuCBLqkQwIZPfe?= =?iso-8859-1?Q?aYlVwhJ8QVJNlaUZhRTHp+qvbJhgZXRUgye3y0c3lLHgvWfK/G+pjVkiDv?= =?iso-8859-1?Q?vGLHVglo8qksl3t3eTChZRwj5qwb3bPxHrJ5x4LkSV6f241wQZQlwOO/C5?= =?iso-8859-1?Q?KQUBQ52cmlqiKqP52I+pQk2LlmCFXAxDkBZjkNMSqS6Jt5gs3g0apsJFuP?= =?iso-8859-1?Q?VEssoFvzpN4Q9tC92VYq6r8r8l86+yAhr9yOVoy/q4n2t4ICaBSp5kIwQ3?= =?iso-8859-1?Q?C0vgQDdCho9xVwctGVH5lEG5RAwKYTR/xms4Bf8L+HhhWxjRohPwx2jAg0?= =?iso-8859-1?Q?QfkL1jvUOIWhJBWZphDac408uX4C/wA9oM+wRPJ4H5q13nKi1aFM6uw01J?= =?iso-8859-1?Q?S2GewH/OxRhQp4v7fmr0K6Ug64RPuceCS9gwSBUGAvLGJjCsnLaHeK07w8?= =?iso-8859-1?Q?KoWIfzH5V6Xqq1WZwKkGo766f28zkeFkVPpcThp1h1wR3ei4kYzYdwARA9?= =?iso-8859-1?Q?kTq0UCicEyqjeD827fhQN4Yg/w2nPYNPMEX9+j0LheWA4r6HAp5DnFjZ0y?= =?iso-8859-1?Q?RHpSn/I/JL4GaXNwXX4bAjqD2slk2FOjdHjVdrhoWPvZva0KbQYrJfHp4w?= =?iso-8859-1?Q?dj8ykAN8UWLvA=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)(35042699022)(36860700013)(1800799024)(82310400026)(376014)(7416014)(14060799003)(7053199007)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2026 07:38:53.2288 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dab7e027-4446-474a-005a-08de4cf6a42f 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: AM3PEPF00009B9F.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR08MB11536 > On 6 Jan 2026, at 08:33, Bertrand Marquis wrot= e: >=20 > Hi Andrew, >=20 >> On 5 Jan 2026, at 19:14, Andrew Cooper wrote= : >>=20 >> On 05/01/2026 12:24 pm, Andrew Cooper wrote: >>> eclair-x86_64-testing: >>> @@ -104,6 +122,33 @@ eclair-ARM64-allcode: >>> LOGFILE: "eclair-ARM64.log" >>> VARIANT: "ARM64" >>> RULESET: "monitored" >>> + EXTRA_XEN_CONFIG: | >>> + CONFIG_ACPI=3Dy >>> + CONFIG_ARGO=3Dy >>> + CONFIG_ARM64_SVE=3Dy >>> + CONFIG_ARM_SMMU_V3=3Dy >>> + CONFIG_BOOT_TIME_CPUPOOLS=3Dy >>> + CONFIG_DEBUG_LOCK_PROFILE=3Dy >>> + CONFIG_DEBUG_TRACE=3Dy >>> + CONFIG_DEVICE_TREE_DEBUG=3Dy >>> + CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=3Dy >>> + CONFIG_EXPERT=3Dy >>> + CONFIG_FFA=3Dy >>> + CONFIG_FFA_VM_TO_VM=3Dy >>> + CONFIG_GICV3_ESPI=3Dy >>> + CONFIG_HAS_ITS=3Dy >>> + CONFIG_IOREQ_SERVER=3Dy >>> + CONFIG_IPMMU_VMSA=3Dy >>> + CONFIG_LIVEPATCH=3Dy >>> + CONFIG_LLC_COLORING=3Dy >>> + CONFIG_OPTEE=3Dy >>> + CONFIG_OVERLAY_DTB=3Dy >>> + CONFIG_PCI_PASSTHROUGH=3Dy >>> + CONFIG_PERF_ARRAYS=3Dy >>> + CONFIG_PERF_COUNTERS=3Dy >>> + CONFIG_STACK_PROTECTOR=3Dy >>> + CONFIG_UNSUPPORTED=3Dy >>> + CONFIG_VM_EVENT=3Dy >>> allow_failure: true >>=20 >> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/12604499722 >> shows 122 failures in otherwise-clean guidelines. Some observations: >>=20 >> llc-colouring.c uses binary literals. These are safe to use now since >> 4.21 with the updated toolchain baseline, but the Eclair config wants >> updating to allow this language extension. >>=20 >> ipmmu-vmsa.c has a git:// url inside a block comment, which is >> considered to be a Rule 3.1 violation. In principle this ought to fix i= t: >>=20 >> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automati= on/eclair_analysis/ECLAIR/deviations.ecl >> index 7dee4a488d45..8f5fc6c93bc5 100644 >> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl >> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl >> @@ -60,7 +60,7 @@ removed by the compiler, the resulting slowdown is neg= ligible." >>=20 >> -doc_begin=3D"Comments starting with '/*' and containing hyperlinks are = safe as >> they are not instances of commented-out code." >> --config=3DMC3A2.R3.1,reports+=3D{safe, "first_area(text(^.*https?://.*$= ))"} >> +-config=3DMC3A2.R3.1,reports+=3D{safe, "first_area(text(^.*(https?|git)= ://.*$))"} >> -doc_end >>=20 >> # >>=20 >>=20 >> but I've not tried it yet. >>=20 >> There's a R8.4 violation against __stack_chk_guard. I think this wants >> deviating locally, because it's a fairly magic construct. >>=20 >> Other than that, there's a smattering of violations. Some will be fixed >> by some work I've got pending for the x86 side of things, but most are >> specific to arch/arm/. >>=20 >=20 > They are quite a lot of violations coming from ffa. > I have a pending serie on FF-A waiting to be reviewed/committed. > I can push something to fix the findings after it, if that is ok for you = ? >=20 > I will retrigger the CI from the branch corresponding to my serie and wor= k > from there. >=20 > In any case, very good thing to activate all those and check with the CI,= thanks a lot :-) There are also a bunch of optee ones that i can handle in a patch. Cheers Bertrand >=20 > Cheers > Bertrand >=20 >> ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 06 08:00:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 08:00:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195850.1513738 (Exim 4.92) (envelope-from ) id 1vd1yt-0002aM-F1; Tue, 06 Jan 2026 07:59:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195850.1513738; Tue, 06 Jan 2026 07: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 1vd1yt-0002aF-CR; Tue, 06 Jan 2026 07:59:55 +0000 Received: by outflank-mailman (input) for mailman id 1195850; Tue, 06 Jan 2026 07:59: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 1vd1yr-0002a9-JT for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 07:59:53 +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 acdff867-ead5-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 08:59:49 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-477ba2c1ca2so7205085e9.2 for ; Mon, 05 Jan 2026 23:59:49 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f695956sm28690045e9.6.2026.01.05.23.59.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jan 2026 23:59:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: acdff867-ead5-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767686389; x=1768291189; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=W+VElUht1tGQQpu9NmbvXUKqeP5mLf9xG4i5ZNxiFpA=; b=bRHB6ymlstNZ7j4zIOV4IVOfl+XR1U5x/alp6ugzRu5uB6Z5Qmti/9OyoKEPd+gGQD zwCtQndWEx2YNNrPIgm020/1BbS0VZlij9A9QiLpf+hHdv8VwSC/DJyw3U4Sf0QcpXzn mmeM52XQQSyYstcOXUYr+j54vCPcIvVdJbA16Qxcy+egys46J5RB+WYtXTZkBxqprOu9 kFzZ/9q+H4NjC/NLCPO8FodT+fZbPCh/UjWa+r2EwCeCUSC2O9ZIA2gH99BtMZs9qQrp x1Bl1yb/aQ3dFOmsxwoD9YLcAQsYPx6Ox23yOj+IePiZ7NAe6KSIjZofPukYYsYqAaUQ fPYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767686389; x=1768291189; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=W+VElUht1tGQQpu9NmbvXUKqeP5mLf9xG4i5ZNxiFpA=; b=WaVKGPTg0Ye/7mEa/lTFyAf/6cZ8D3A6pcNKpWrGDSY1tJ163TZZodmN+Z9CyuUUbf 4zUuVr8EzU72pzNU69gNAhOH7Uf76aIwE9jQ42Za0FxK+/T0GATLbVuJe3f9OWarL/eD Q6p1SMZg5u1T2EcGNsyxiykPvnbyfFZ2WWFqAGqcY6HtwLZRAsZ2r2Ew1YWlQTQADGBz yJCvAbAofuFcFrIzdKvOYoe21qsU2CwR8xR6P0btd39oRkayxTP2nR4Tg6tK2sEzMRLH 8NWkqSOTAklkcYm8ggawKxRIriXOFKGv2krjTdNH5+HDCyFcsmfw+v2FGLvkE+TE1076 RsOA== X-Forwarded-Encrypted: i=1; AJvYcCUSvyU7rT4AIlDxwGzm7G5OFQgwR/zdKepO04t3CroXJ4Ksr8M1+htnLa5022ECpZ/9Ukt6bAJzsUs=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywizej3cJCAfd/0WSIeqC7rkQzlorfi8QoxkMgtbT1PxPsZez0p y9IlGJxyy0Xn0tn3ksycbAPKJpE9wT6AM/Mjh1e3EZ9aK07BFEAQBEtyeqSmZ+ukjw== X-Gm-Gg: AY/fxX5xzBqzXHbU/th3KOJChBlVGcyvWizsarLVw8uWvMsymj8+ls/W0Nb1g96UQcm +C4AGPhHyAYbFOofoQBF1gFDmVXlYvTneDoJ1QfK6lWcdy7SeHASPmQjAXZcmE+7MbrZ9ICrKFe FvVVmMUYKkPkIqeIsJVnKJmo/zFMQbumIqgitK18WESwSACBaTSZHn54DXgXhW52fm5iOZby2bi hyEJ3ZU1gH75doIJ1myCxe69XsCWKftWgIeXwUzYyhuBAxkmG7jpPzXZSoCtRSmgELWQuJa27Xn zW1/qkE7hnWwu3VbJ6WC3RFj4BodJldqAgRD04fD+PNzdNyKVxHKL8OQvWORmMrVrd51lkh5bik XFua1MR/Dwx6UWGF0acArvfgKc3ktm/U4Y6XQYJ9iCQNtFcn67e+p3S5O511wNPBm/qIKexhbq+ RtPZTFVRoVfngcJVxOBYAtDvwClL8DcD609Z9uxV2X3WT+YkxkkTVKtJkda6tbC+tgLQEtatTlX Wtc4FNXJ0dsWQ== X-Google-Smtp-Source: AGHT+IFYKMj4I83QfzjCwQYRl3JFmJb17JHz7QppLFZo3+Wnw+ch2w7irUPCn8yKIhaUidx0ICsv9Q== X-Received: by 2002:a05:600c:1d1d:b0:479:1b0f:dfff with SMTP id 5b1f17b1804b1-47d7f073054mr22937385e9.10.1767686389260; Mon, 05 Jan 2026 23:59:49 -0800 (PST) Message-ID: <6062efac-8285-4062-926f-dc3ece871654@suse.com> Date: Tue, 6 Jan 2026 08:59:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/4] x86/xstate: Rework XSAVE/XRSTOR given a newer toolchain baseline To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20251230135427.188440-1-andrew.cooper3@citrix.com> <20251230135427.188440-3-andrew.cooper3@citrix.com> <4b051e1f-0d99-4637-b433-bade93e67e0a@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.01.2026 18:45, Andrew Cooper wrote: > On 05/01/2026 3:46 pm, Jan Beulich wrote: >> On 30.12.2025 14:54, Andrew Cooper wrote: >>> --- a/xen/arch/x86/xstate.c >>> +++ b/xen/arch/x86/xstate.c >>> @@ -310,21 +310,21 @@ void xsave(struct vcpu *v, uint64_t mask) >>> uint32_t hmask = mask >> 32; >>> uint32_t lmask = mask; >>> unsigned int fip_width = v->domain->arch.x87_fip_width; >>> -#define XSAVE(pfx) \ >>> - if ( v->arch.xcr0_accum & XSTATE_XSAVES_ONLY ) \ >>> - asm volatile ( ".byte " pfx "0x0f,0xc7,0x2f\n" /* xsaves */ \ >>> - : "=m" (*ptr) \ >>> - : "a" (lmask), "d" (hmask), "D" (ptr) ); \ >>> - else \ >>> - alternative_io(".byte " pfx "0x0f,0xae,0x27\n", /* xsave */ \ >>> - ".byte " pfx "0x0f,0xae,0x37\n", /* xsaveopt */ \ >>> - X86_FEATURE_XSAVEOPT, \ >>> - "=m" (*ptr), \ >>> - "a" (lmask), "d" (hmask), "D" (ptr)) >>> + >>> +#define XSAVE(pfx) \ >>> + if ( v->arch.xcr0_accum & XSTATE_XSAVES_ONLY ) \ >>> + asm volatile ( "xsaves %0" \ >>> + : "=m" (*ptr) \ >>> + : "a" (lmask), "d" (hmask) ); \ >>> + else \ >>> + alternative_io("xsave %0", \ >>> + "xsaveopt %0", X86_FEATURE_XSAVEOPT, \ >>> + "=m" (*ptr), \ >>> + "a" (lmask), "d" (hmask)) >> While no doubt neater to read this way, there's a subtle latent issue here: >> "m" doesn't exclude RIP-relative addressing, yet that addressing form can't >> be used in replacement code (up and until we leverage your decode-lite to >> actually be able to fix up the displacement). > > I guess I'll fix that first. > > I'm not interested in trying to keep playing games to work around > deficiencies in our alternatives infrastructure. > >> Sadly "o" as a constraint >> doesn't look to be any different in this regard (I think it should be, as >> adding a "small integer" may already bring the displacement beyond the >> permitted range, but their definition of "offsettable" allows this). >> >> This issue is latent until such time that (a) a caller appears passing in >> the address of a Xen-internal variable and (b) we make LTO work again. >> Since the breakage would be impossible to notice at build time, I think we >> would be better off if we avoided it from the beginning. Which may mean >> sacrificing on code gen, by using "r" and then "(%0)" as the insn operand. > > Even with LTO, I don't see any plausible case where we have build-time > struct vcpu's to pass in. Sure, but struct vcpu * also isn't a great parameter for this kind of a function. >>> @@ -489,17 +484,17 @@ void xrstor(struct vcpu *v, uint64_t mask) >>> ptr->xsave_hdr.xcomp_bv = 0; >>> } >>> memset(ptr->xsave_hdr.reserved, 0, sizeof(ptr->xsave_hdr.reserved)); >>> - continue; >>> + goto retry; >>> >>> case 2: /* Stage 2: Reset all state. */ >>> ptr->fpu_sse.mxcsr = MXCSR_DEFAULT; >>> ptr->xsave_hdr.xstate_bv = 0; >>> ptr->xsave_hdr.xcomp_bv = v->arch.xcr0_accum & XSTATE_XSAVES_ONLY >>> ? XSTATE_COMPACTION_ENABLED : 0; >>> - continue; >>> - } >>> + goto retry; >>> >>> - domain_crash(current->domain); >>> + default: /* Stage 3: Nothing else to do. */ >>> + domain_crash(v->domain, "Uncorrectable XRSTOR fault\n"); >>> return; >> There's an unexplained change here as to which domain is being crashed. >> You switch to crashing the subject domain, yet if that's not also the >> requester, it isn't "guilty" in causing the observed fault. > > So dom0 should be crashed because there bad data in the migration stream? Well, I'm not saying the behavior needs to stay like this, or that's it's the best of all possible options. But in principle Dom0 could sanitize the migration stream before passing it to Xen. So it is still first and foremost Dom0 which is to blame. > v is always curr. Not quite - see xstate_set_init(). And for some of the callers of hvm_update_guest_cr() I also don't think they always act on current. In particular hvm_vcpu_reset_state() never does, I suppose (not the least because of the vcpu_pause() in its sole caller). >  XRSTOR can't be used correctly outside of the subject context, Then are you suggesting e.g. xstate_set_init() is buggy? > and indeed the Stage 2 logic above is definitely buggy when v != curr. Apparently I'm blind, as I don't see an issue there. It's all v's data which is being fiddled with. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 06 08:25:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 08:25:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195869.1513749 (Exim 4.92) (envelope-from ) id 1vd2NU-0006wl-SC; Tue, 06 Jan 2026 08:25:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195869.1513749; Tue, 06 Jan 2026 08: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 1vd2NU-0006we-OQ; Tue, 06 Jan 2026 08:25:20 +0000 Received: by outflank-mailman (input) for mailman id 1195869; Tue, 06 Jan 2026 08: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 1vd2NT-0006wY-OB for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 08:25:19 +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 3af73827-ead9-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 09:25:16 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4779cc419b2so5633975e9.3 for ; Tue, 06 Jan 2026 00:25:16 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f703a8csm29200215e9.13.2026.01.06.00.25.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 00:25:15 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3af73827-ead9-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767687916; x=1768292716; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=R4VKNmVVls93J6OR2UhGYpb0oYUKE4ugmobwaWTQuR8=; b=ehPngQhUu0wRnqntESfYAXbffELUTtO/eoX76kzRZOZXtXqJaeh6cj8GTQEtlsfzP2 VjQkD8SXWEfahuxEw6a0Ru++B6aTB10hHwhe8+coJQR1JLiM/tmfeUsawQhpNiNnJFkW 9Yc5d8VwBbrnzbydiU3bJnrpSSEouwqR9RpXpn/aBuB6PlQtSXphJnaUWvHHj6iRrSW6 8ydw96dykknVQqMau9Olty4LNsoc1cI4+LAVxJEl9JWgFPnbyjQThtz2DInP6KLXvoae BUWZLOs1L9g+u+Bk/2NBL3QZOv16wBS/sGUjODdX98CC1IO4i+JJsJ5ZrREbbP0q2xDr 3Nhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767687916; x=1768292716; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=R4VKNmVVls93J6OR2UhGYpb0oYUKE4ugmobwaWTQuR8=; b=QGyp9XW4gRqJEQVsKLJ2pNnlc2xnRlnOm8yZJqGh90+Lcf7zMpzA6gvqMEDEuRfmp5 gHyOc5Vt60q/Hzce10wo+cD7oxvzAsCJu182rqeZc7YzR7xrVyjLeVqw9K5Ky4xBG5eu SHHacYy1evpUOkcPvhWkkAKnEFu5IuAh/Khxby7rhgNq/PHXxZFJPVQc7sfwVldMfq0v iKB8V8W9UJZLxRGtx7Yw6gE4UM9U2Scq5shFZUP29lkrYT65DF68CuZJ7Geil0GR7T+A nuM5P5aBthnz10rUXD0DAXnimpxN1/6yLLN6bdKD8d0PfDAsOthmTqTK4VFxRjzzhmwh gWFw== X-Gm-Message-State: AOJu0YzTu6GM1JMGm+EZgIxVeLPeP0LGcZ5VTU0PjT3iVb8wueT7nUfb LF3xkicI5QDja83MjE+3lzNG6jLm2/T7EEx5GY66lT/7q8s9BRjSrQUzviJ51crN6g== X-Gm-Gg: AY/fxX6C6bGUAzdpnGS5n8mkeTQDAvoH5lsxnDvftmymDAjsni3prJAcjqPOANX/blG qR3M8l5eQmUBF75BKEFJLEwz2Gn12+fT2/hLIe+nPXWDmo2a4lFR6G9kUyPJg/fSUtMktgF/RF7 qlAz+qWFKwjm8Xu2/NRS3TK16xaxABCkl9Fy8n1pByXizJR1+1MxssDgkWSVbDowZN6ilYcC0S3 DWZ96gkrjGS3Jae+jZ/7Ab9lCJjL7u1jkL6sNQAgt4lQBrAmDZlL5PmbSPCU2xsE9HNltxfXAb8 cpU6rYT1NpImyHZUGNxHFIj6NhXykNkVFOzybEKI9axgSo4Aw9dmDL0Rhp2GShtO7bzQN96m7Od p6Xa5o7IAKgp74zBMwTEXR6olEeuNyk+64CrduKnYMs2/zqyjxbF76nS/h99EmbQ0Xc7LotfB+5 mM22V853leWphQqoT5VU5x2uDm7afDBqhru3jdFaaR1IzYajwa8hKRS/Sy3zpd0DNQV39KnQZg1 fFZJxgz75CyBA== X-Google-Smtp-Source: AGHT+IGyPTJy5z2RuQeqInH3J6Jdg8Y1GNDK48TdBWmFkBbTVeBzKIYIgoQJ+4D/mtIOgLOhKonQbg== X-Received: by 2002:a05:600c:1384:b0:477:9b35:3e49 with SMTP id 5b1f17b1804b1-47d7f066fcamr21839395e9.3.1767687916111; Tue, 06 Jan 2026 00:25:16 -0800 (PST) Message-ID: <6f02aca2-eaca-48b8-a2f3-4afff42ad264@suse.com> Date: Tue, 6 Jan 2026 09:25:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Cpufreq drivers not working on T480S To: Jason Andryuk , Milky Cc: "xen-devel@lists.xenproject.org" References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06.01.2026 02:03, Jason Andryuk wrote: > On Tue, Dec 30, 2025 at 8:50 PM Milky wrote: >> (Re-CC'ing the ML because I forgot by accident. Hopefully the quoted >> sections provide sufficient context) >> >> On Tuesday, December 30th, 2025 at 10:44 AM, Jason Andryuk wrote: > >> As suggested, I added the debug parameters to the dom0 kernel. Before or >> after `modprobe xen-acpi-processor dyndbg==pmf`, there is no useful >> debug information that I could find, apart from the >> `xen_acpi_processor:get_max_acpi_id` message as seen below. >> >> ``` >> # sudo dmesg | grep xen.acpi >> [ 2.282851] Kernel command line: placeholder root=/dev/mapper/qubes_dom0-root ro rd.luks.uuid=<...> rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap plymouth.ignore-serial-consoles 6.6.77-1.qubes.fc37.x86_64 x86_64 rhgb loglevel=9 "dyndbg=module xen_acpi_processor +p" "xen_acpi_processor.dyndbg=func * +p" rd.qubes.hide_all_usb >> [ 5.224092] xen_acpi_processor: Max ACPI ID: 6 > > You successfully turned on dyndbg to get that output, but there is no > further output. This makes me think something else is wrong and > xen-acpi-processor doesn't upload anything. > > The call here https://elixir.bootlin.com/linux/v6.18.2/source/drivers/xen/xen-acpi-processor.c#L557 > to > https://elixir.bootlin.com/linux/v6.18.2/source/drivers/acpi/processor_perflib.c#L421 > goes into some acpi code. Maybe there are other messages in dmesg > around the same time? Maybe you'd have to turn on more debugging to > get them. > >> # sudo lsmod | grep xen_acpi >> >> >> # sudo modprobe xen-acpi-processor dyndbg==pmf >> modprobe: ERROR: could not insert 'xen_acpi_processor': No such device >> ``` > >>> Maybe also with Xen's command line try cpufreq=xen:no-hwp to disable >>> HWP and see if the regular ACPI cpufreq driver works better. >>> >>> I'm thinking it's something where xen-acpi-processor didn't upload >>> ACPI CPU data, which means cpufreq isn't running. That may also be >>> why you see that bogus CPU frequency. >> >> After booting with `xen:no-hwp`, I wasn't sure how to check if the >> regular ACPI cpufreq driver is operational. Is `xenpm` still the >> correct way to query for CPU info? I've tried the following: >> >> ``` >> # sudo xl dmesg | grep -i hwp >> (XEN) Command line: placeholder cpufreq=xen:no-hwp,verbose loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M ucode=scan smt=off gnttab_max_frames=2048 gnttab_max_maptrack_frames=4096 no-real-mode edd=off >> (XEN) HWP: 1 notify: 1 act-window: 1 energy-perf: 1 pkg-level: 0 peci: 0 >> (XEN) HWP: Hardware Duty Cycling (HDC) supported, enabled >> (XEN) HWP: HW_FEEDBACK not supported > > no-hwp failed to disable HWP. But if there is no ACPI CPU data, it > wouldn't work either. There isn't any "no-hwp" option that we would recognize, is there? Iirc HWP isn't enabled by default, so simply not saying "cpufreq=hwp" should disable the driver? (I already found the original report confusing in this regard, hence why I preferred to not reply so far. I wonder if there are local patches in use.) Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 06 08:28:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 08:28:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195878.1513760 (Exim 4.92) (envelope-from ) id 1vd2QA-0007ae-8s; Tue, 06 Jan 2026 08:28:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195878.1513760; Tue, 06 Jan 2026 08:28:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd2QA-0007aX-54; Tue, 06 Jan 2026 08:28:06 +0000 Received: by outflank-mailman (input) for mailman id 1195878; Tue, 06 Jan 2026 08:28:05 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd2Q9-0007aP-06 for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 08:28: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 9df90e24-ead9-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 09:28:03 +0100 (CET) Received: from AS9PR06CA0583.eurprd06.prod.outlook.com (2603:10a6:20b:486::20) by AS8PR08MB6565.eurprd08.prod.outlook.com (2603:10a6:20b:33c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Tue, 6 Jan 2026 08:27:58 +0000 Received: from AMS1EPF00000044.eurprd04.prod.outlook.com (2603:10a6:20b:486:cafe::8f) by AS9PR06CA0583.outlook.office365.com (2603:10a6:20b:486::20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9478.4 via Frontend Transport; Tue, 6 Jan 2026 08:27:53 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by AMS1EPF00000044.mail.protection.outlook.com (10.167.16.41) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.1 via Frontend Transport; Tue, 6 Jan 2026 08:27:57 +0000 Received: from DBAPR08MB5590.eurprd08.prod.outlook.com (2603:10a6:10:1aa::17) by DB4PR08MB8176.eurprd08.prod.outlook.com (2603:10a6:10:380::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Tue, 6 Jan 2026 08:26:53 +0000 Received: from DBAPR08MB5590.eurprd08.prod.outlook.com ([fe80::f68e:1311:9070:68b]) by DBAPR08MB5590.eurprd08.prod.outlook.com ([fe80::f68e:1311:9070:68b%4]) with mapi id 15.20.9478.004; Tue, 6 Jan 2026 08:26: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: 9df90e24-ead9-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=SwNzLV+JYEOFSNFFzs9l78y9OqER+NNCkmPhlN4+aAgqnTr+n/9KMFGXFYfka3+3Ut4egLf3dFlrMQjF/GrydN5pkBEuBRpsilFdSP2v33d/XOwK7wOOCEud2pIL2iiRUpKnBFASQkHubDqQSAmvQYTrr++aYiFKxH9AM/1wZxrSgPmQocecNTIx/ShEKWnyTQ3xt1bc4R+HeHTWwgND8CU06xxApWP/idpwp/FM4zT4DSLd2NL25rCI4qG8LUH+UNInhm1DyaqFOHfbhOIhSC9el0jFN1n+VvEFLH+9/rk/KvPdIUTRyHBAWUT51GsyvWZ6w5uakWeqCtBC5QEZwQ== 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=Pji4ghQaSnjwkr++d3QS7//Q2KJcQ+HUDXzPXClNDuc=; b=Wc5+ln7KhyMOK4urkYxoJAgzVL0feNeYhPVFMOGiMmUP+itzwRZmX45GA1Iu+qDfuyeZ4/r5lJcpO+5fHIsUPYBDs8G9C2CTgGy7qN5iUNuGzU5Q1pd8k7vbDOWkSxCW5hCOXl+ja3PPZzt31Mmxfl/DbUuMFBLFCiLCwRoJjkGzXagzezKneqkZOtneCzmx+Fe/uyBuxJushV9K8z7FERIzcwkjvfFR5V/362Bpoyc9XFo+KUDaWLbp/cAS4U/SK04J9GBYzBBFnNjRlBotQBNOKd1Z+DeGxQG0Q5xvZqo/hNx4aKp9S9J9j2ZnZqTVrSxHw3bka0hJdqsFqiimUw== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=bugseng.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=Pji4ghQaSnjwkr++d3QS7//Q2KJcQ+HUDXzPXClNDuc=; b=NeFoJKy3sGBxtydxVu5QZn3QTydUNR5LuviY7yNYEuhOwmwYhnReCoIXpjy3Z2Z93PiPzsEDJbfGtRn4NSuf3x7hnbBdTZwpf7pxt3GTqDC77dmlieoujYwlzJIz/kzAZpHyRWbROdBPsUI/tW8N2416dhfsk47kxlg+c34SXtk= 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=VRn4HA2Qjv2nTHsb3GjcJ0OhWLvuW8vnIuV+tNxl0gLngCSFj9R9dL1gd4VEuNlY+3hqHqRvnBTtRV5dA909/QlDOTTCdG7qlrb9juFv4uGLDh+sYIY8kwa1x9VXVlPrCB/9tDXIrNxOstd0N5eoj0t7hf0ME6vu56f1OleBqVPuMja4zFnokWkxa90NfoI2QrDGt0/v2HnAlKovbrFhRFT1JOnwp/XIerZXosUleU3P00+2wUHT4Nf8Qiy3o1EzlS0G7tVH2HhnonXUgPBXXndPOLwjanoBHC42mAORW/Z6dfyeO7aHy0yuJ57Vfxtd6D1cUdmjXDHhsWDPhbugRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Pji4ghQaSnjwkr++d3QS7//Q2KJcQ+HUDXzPXClNDuc=; b=lVMpdivIqzjfkOA/Yq99/7tbRYVn/W5Wz6n9TMglPkDQPflCIGgg/YcyVEp8urrj4ldDMBOPSslDSCYrH3pb6yDIMyeTXfuoN4dIdkP+j7JwCx1OrUHHGv7uCzvg3oNme4SBmyptseF+hVJKn4vsE6ZxdVZhQ9mZjG1gctAKhZa6wgHheVzLv/3JjqKy/C8h/MEqRxhCqRmm7yYWG+DzVAU95g4FVIqoY/Kpkg/35rJid8FCHFzWoTUJp0G+2o+fjZ68er6/nZDo/MvoBmQy+f9L49BWChzGw8LeP8msXIliAR73LAec9iJ04ObOJgw8dMlxTPWPw44kYxlzoyp5OA== 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=Pji4ghQaSnjwkr++d3QS7//Q2KJcQ+HUDXzPXClNDuc=; b=NeFoJKy3sGBxtydxVu5QZn3QTydUNR5LuviY7yNYEuhOwmwYhnReCoIXpjy3Z2Z93PiPzsEDJbfGtRn4NSuf3x7hnbBdTZwpf7pxt3GTqDC77dmlieoujYwlzJIz/kzAZpHyRWbROdBPsUI/tW8N2416dhfsk47kxlg+c34SXtk= From: Bertrand Marquis To: Nicola Vetrini CC: Xen-devel , Stefano Stabellini , "consulting @ bugseng . com" , Jan Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Julien Grall , Volodymyr Babchuk , Michal Orzel , Andrew Cooper Subject: Re: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible Thread-Topic: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible Thread-Index: AQHcfj5G7fNp7PSkb0GiHPxZx0yorLVD4eGAgADfJYCAAA7cAA== Date: Tue, 6 Jan 2026 08:26:53 +0000 Message-ID: <541EF107-3536-4525-ACC2-065A9A13481B@arm.com> References: <20260105122436.555444-1-andrew.cooper3@citrix.com> <82d99c52-c39b-4fbb-bbb2-0e952df91673@citrix.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.300.41.1.7) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DBAPR08MB5590:EE_|DB4PR08MB8176:EE_|AMS1EPF00000044:EE_|AS8PR08MB6565:EE_ X-MS-Office365-Filtering-Correlation-Id: 8ac1bcef-4c8c-42e3-31d4-08de4cfd7f1d 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|10070799003|1800799024|366016|38070700021; X-Microsoft-Antispam-Message-Info-Original: =?iso-8859-1?Q?aU/KuodPe+a4xOxtcguK4qU7lXyjj2JzNzfKYI2aXUxfb9JrinDGhr22om?= =?iso-8859-1?Q?nSdm406SSnatSqwTQDxDGdAYCZ75tzoEevkY/uMk3HEG4nGqAnLorPwMRg?= =?iso-8859-1?Q?2QQSiuWNi6mWa2xE1Kk/Tno+MOjTfPlN57DMi5YwGWokDRZU8CpCQmXQRm?= =?iso-8859-1?Q?JLpxr+unGs3KfGTUyypCK2pUWPcIQ37DTAb7MlKLwjo+1rYAPCB9gIF0FD?= =?iso-8859-1?Q?P6wRVVIFLH+EDLQy4l5bACGBoSC7eWy/HRu0Glns7P4ttJx012WYMkkwgk?= =?iso-8859-1?Q?Gz1ZmsI0qEsNfTVdpuKMH/4Q2u4SKTiMDuR6rCCc0tK94MTN9e99t29TdI?= =?iso-8859-1?Q?JONmA2Oy5/l+R6tXWYzE/EVL7lS7XlcXxoaf3FBOCkIOt8trwByYbJuSgn?= =?iso-8859-1?Q?bsgy7DPLLBLgjPFjw46ve1N315RjWdfy3zJ1Vs8fBYJnTZDumZTmrRcPq2?= =?iso-8859-1?Q?xlgEC30Z6Y3KuMfLXgkxSC1ZqWCrjPzotoC3Ukmd2F/K3VpKXauWNwxK5x?= =?iso-8859-1?Q?iBhiHdOQcWHWJbhc3xz76sgjA7d1pCIareA/ldg3aGrkkhOwkXg9BWBdsv?= =?iso-8859-1?Q?ycAsOpSOI59lVfUNvo9cUJ8/KOs+4tRqKwbyGfGuml6GZz1I3MXpvEaiH3?= =?iso-8859-1?Q?bypSGcie2ktFS3ulRQxvh59Z8agBbBVtkWV2svwPfDzzXRx3EulkSUkLua?= =?iso-8859-1?Q?mNN1Pe4zUIDu1RnLa4lQjAi0jEuiIYHCR0SL4uyb6lAepzwdMyoW3+UgTy?= =?iso-8859-1?Q?RZUQ89cpKYzI/N1BO8fn63+r0vwlbpsN4/6FAEWCFxKsLZXp5sCI21cUnq?= =?iso-8859-1?Q?9nRWftaT8VUtGsvY4ta7LBke6j8u8FQjP/1VE/n0lQM2geti5G201hcaBH?= =?iso-8859-1?Q?K5TKclWYqtoRkQxKt/9NlwWnpBz+kIamXhzemomaLa8eb+EKqP3q5M1KGC?= =?iso-8859-1?Q?tNqvOD6HII63+/uioh7MWQkzX87h4k+a0NERGDzFXNXic+HisFNft5n8Bc?= =?iso-8859-1?Q?pEvGQZPDpg8rOfNO02t3kve5bezy2pU+2I1mGIrxTiLNy3kWgUlpFy+5Ix?= =?iso-8859-1?Q?+zchKRC3t6WUb4wxTIzVNePhjdEnQqFPVfPzz6NkJV9PU9tlsVI1h+M6NU?= =?iso-8859-1?Q?nvDJgsx9rGDHZWwneQy+ovsF9tc1Hhy+MQIgb1hqtW5Pf1demOCTfqqRzV?= =?iso-8859-1?Q?H5tiZiOouh5NHjRuoE5/QTzHI4b3nqIxRR9Z2TdgbNg+09gqqvSX2SBDZT?= =?iso-8859-1?Q?kBWV6RR7OrOWujT9Wpvi971lrnrVI0om6+xx0nkgcPwTKSCTPxA0EJ0Lk9?= =?iso-8859-1?Q?frriglY44NgSVJ6kBMJqtvPnadabHN8eUda9JSvA233bwwdBeKxVWBzJgk?= =?iso-8859-1?Q?9oAWo8BehjVUKZPcDs0mR4zKAVzq+Oufb2MLs37Wqyz6zabubyxYIIT0y0?= =?iso-8859-1?Q?Ekl3P2P2X3EMNlLFT0ACbxswo+ipSgESQZHVk6k0ssujArgxvz4cAX8TuQ?= =?iso-8859-1?Q?euPBJQWFEXaZsoTuk7RBI10uBZ9QJOcuD9JviXa+6MiA=3D=3D?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5590.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(10070799003)(1800799024)(366016)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR08MB8176 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AMS1EPF00000044.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 24d8947b-9a87-48ff-aacc-08de4cfd58ea X-Microsoft-Antispam: BCL:0;ARA:13230040|14060799003|36860700013|376014|1800799024|7416014|82310400026|35042699022; X-Microsoft-Antispam-Message-Info: =?iso-8859-1?Q?xDEwiZTmMP4HZcdtv4yza9viXKhdwXQ2i54RqQDzcx35n4uqwlKilqAwUG?= =?iso-8859-1?Q?HHxcTiN7rFT6RqJKSM+kLJeslJ/q/2rYDsgoOrbqj35f0xZ6ohjwqusfdy?= =?iso-8859-1?Q?f+/n6uUlMk/RxKCvkJqSMkMywKeAeSpiPOzNJAYf0F4xQStZdTCMjCAuaD?= =?iso-8859-1?Q?kjsjhwbTO++fWe7IlsBOmuanr7hhPNz1z6S8zR5kAFctHSBAh7yjJMWc5L?= =?iso-8859-1?Q?gh68dtevz/GwphwbRNeCJfZMsx95HeDYU2ujv6I6oy7RSPCabecfxf49Io?= =?iso-8859-1?Q?g60id1me7xnoOy5JalDoUiKL6ZIkPo1ppcx43yV1mvRIqqH0chp8xsHy3j?= =?iso-8859-1?Q?Cf0oUFxPx+K9l7+mGsEfs/RPbVB6B2vEU9ntZc0rftK4yhIkqhTqcFJ+uK?= =?iso-8859-1?Q?ZBXOBa61vkjqIiU6jVZjMaOnJuhC4i25JTyJLG/3XDBr+VO+UdJ5+Bbsvx?= =?iso-8859-1?Q?6BDtx5h/4Qz0aRwocZ/xkiIQTdGdqTWATdK58ekm9cC7S+Jf1vqk2RsVkP?= =?iso-8859-1?Q?atwGQHKRjtI0a0fTAboCpkwdDe9Q2WryWRlpSapLZekY1cXEgzB/MSB/wK?= =?iso-8859-1?Q?hUruuAAQvSzla1lAVndvpDpuqLirdz8amWAj+MqD/4ULNoNGJiVT6W3pMU?= =?iso-8859-1?Q?kYGOyLnXKvNbqG6ZCZzW9tiF2QuuJrPhBS03Qx7hVQ2R13o9yDwnBVoDWU?= =?iso-8859-1?Q?SvbPvP1gNyWxyJ8fMdFisc3j63frRgWdKRMFYHiXulH3VwpPwhirQfOlyO?= =?iso-8859-1?Q?+ZjEFEHnuoe+s5x6ORUiv64xrRjqJeKZrc4bwjEz/lrHo9UUfwCb2AiEaX?= =?iso-8859-1?Q?DY2f/Mq2ZuI9Is4lMBXJNx2vecTDVI6/z0JDSYouAvN8Jy+0CeHecgpZ0b?= =?iso-8859-1?Q?pv7jCSL34uDpoFbg3eheI2Ekk3+xeK3WexHIe85p1izlwU16ncO6jA6x7c?= =?iso-8859-1?Q?REPijqjXVERQgtdtaWVYBfHrCNH4/YAQjfIT+dl8NmQpeVczNRkb3gEl3J?= =?iso-8859-1?Q?j+7kDNunPeEHxQBtn6IRSvy5jmdc0Wj8cg98m2UN1wj/+m1HU+RMTkahzf?= =?iso-8859-1?Q?wAYI4stXbMbBlmvDBzDO0MqOv/aR70mgwj2MpbiPbioAst737dHfsFs71o?= =?iso-8859-1?Q?ixnLiF8GESy/V+5v0tsPsgHZdVLEx5o9XDp8GTqq84lgoX/7uykKnWOWfz?= =?iso-8859-1?Q?MUXsA6+7C+GP1CUBYuq1C3jXoMb8dfSAVMCuAnJZ0WZsrY8o0mVi8f14JN?= =?iso-8859-1?Q?dWH7Uzsz7KyyrazakZqBzAO9jsJVNCD4ZJtIH4gDT+I6jk5B/8entNOFHz?= =?iso-8859-1?Q?ew+Y0wX4qB4JMMxUSM63Wodenmq8OpIPw8celygr0hmnRwH2wf/rqVKUPH?= =?iso-8859-1?Q?5Aon8jCLqQyCqwPcrs2huE2flPSvcvT3yC1spMGfphdZNYvuvjGTfb+eYK?= =?iso-8859-1?Q?rhxNOcq/YdY10ze5Pj00E2kyNkM/OYccVxw0LQNhTqffXDJ5mQjoOf05Mr?= =?iso-8859-1?Q?CrIlzJz9fOzVXVDNQT85R58bpzlGIuHSp9vWjLLmE0/hfKgco2PYY8vBWI?= =?iso-8859-1?Q?sRCeIh7yEYEMWl2SbAnK97DEJk/9?= X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(14060799003)(36860700013)(376014)(1800799024)(7416014)(82310400026)(35042699022);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2026 08:27:57.5310 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8ac1bcef-4c8c-42e3-31d4-08de4cfd7f1d 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: AMS1EPF00000044.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB6565 Hi Nicolas, On this subject, could you help me understand what the following error mean= and how I should fix that: https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen= -project/hardware/xen-staging/ECLAIR_normal/andrew/eclair/ARM64/12604499722= /PROJECT.ecd;/by_service/MC3A2.R20.12.html Thanks Bertrand > On 6 Jan 2026, at 08:33, Bertrand Marquis wrot= e: >=20 > Hi Andrew, >=20 >> On 5 Jan 2026, at 19:14, Andrew Cooper wrote= : >>=20 >> On 05/01/2026 12:24 pm, Andrew Cooper wrote: >>> eclair-x86_64-testing: >>> @@ -104,6 +122,33 @@ eclair-ARM64-allcode: >>> LOGFILE: "eclair-ARM64.log" >>> VARIANT: "ARM64" >>> RULESET: "monitored" >>> + EXTRA_XEN_CONFIG: | >>> + CONFIG_ACPI=3Dy >>> + CONFIG_ARGO=3Dy >>> + CONFIG_ARM64_SVE=3Dy >>> + CONFIG_ARM_SMMU_V3=3Dy >>> + CONFIG_BOOT_TIME_CPUPOOLS=3Dy >>> + CONFIG_DEBUG_LOCK_PROFILE=3Dy >>> + CONFIG_DEBUG_TRACE=3Dy >>> + CONFIG_DEVICE_TREE_DEBUG=3Dy >>> + CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=3Dy >>> + CONFIG_EXPERT=3Dy >>> + CONFIG_FFA=3Dy >>> + CONFIG_FFA_VM_TO_VM=3Dy >>> + CONFIG_GICV3_ESPI=3Dy >>> + CONFIG_HAS_ITS=3Dy >>> + CONFIG_IOREQ_SERVER=3Dy >>> + CONFIG_IPMMU_VMSA=3Dy >>> + CONFIG_LIVEPATCH=3Dy >>> + CONFIG_LLC_COLORING=3Dy >>> + CONFIG_OPTEE=3Dy >>> + CONFIG_OVERLAY_DTB=3Dy >>> + CONFIG_PCI_PASSTHROUGH=3Dy >>> + CONFIG_PERF_ARRAYS=3Dy >>> + CONFIG_PERF_COUNTERS=3Dy >>> + CONFIG_STACK_PROTECTOR=3Dy >>> + CONFIG_UNSUPPORTED=3Dy >>> + CONFIG_VM_EVENT=3Dy >>> allow_failure: true >>=20 >> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/12604499722 >> shows 122 failures in otherwise-clean guidelines. Some observations: >>=20 >> llc-colouring.c uses binary literals. These are safe to use now since >> 4.21 with the updated toolchain baseline, but the Eclair config wants >> updating to allow this language extension. >>=20 >> ipmmu-vmsa.c has a git:// url inside a block comment, which is >> considered to be a Rule 3.1 violation. In principle this ought to fix i= t: >>=20 >> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automati= on/eclair_analysis/ECLAIR/deviations.ecl >> index 7dee4a488d45..8f5fc6c93bc5 100644 >> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl >> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl >> @@ -60,7 +60,7 @@ removed by the compiler, the resulting slowdown is neg= ligible." >>=20 >> -doc_begin=3D"Comments starting with '/*' and containing hyperlinks are = safe as >> they are not instances of commented-out code." >> --config=3DMC3A2.R3.1,reports+=3D{safe, "first_area(text(^.*https?://.*$= ))"} >> +-config=3DMC3A2.R3.1,reports+=3D{safe, "first_area(text(^.*(https?|git)= ://.*$))"} >> -doc_end >>=20 >> # >>=20 >>=20 >> but I've not tried it yet. >>=20 >> There's a R8.4 violation against __stack_chk_guard. I think this wants >> deviating locally, because it's a fairly magic construct. >>=20 >> Other than that, there's a smattering of violations. Some will be fixed >> by some work I've got pending for the x86 side of things, but most are >> specific to arch/arm/. >>=20 >=20 > They are quite a lot of violations coming from ffa. > I have a pending serie on FF-A waiting to be reviewed/committed. > I can push something to fix the findings after it, if that is ok for you = ? >=20 > I will retrigger the CI from the branch corresponding to my serie and wor= k > from there. >=20 > In any case, very good thing to activate all those and check with the CI,= thanks a lot :-) >=20 > Cheers > Bertrand >=20 >> ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 06 08:41:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 08:41:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195891.1513768 (Exim 4.92) (envelope-from ) id 1vd2cd-0001tK-D7; Tue, 06 Jan 2026 08:40:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195891.1513768; Tue, 06 Jan 2026 08:40:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd2cd-0001tD-AZ; Tue, 06 Jan 2026 08:40:59 +0000 Received: by outflank-mailman (input) for mailman id 1195891; Tue, 06 Jan 2026 08:40: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 1vd2cb-0001t7-ST for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 08:40:57 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6a3dd83e-eadb-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 09:40:55 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id CC60B4EE3C04; Tue, 6 Jan 2026 09:40:53 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6a3dd83e-eadb-11f0-b15e-2bf370ae4941 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=1767688854; b=IgCoRWlKNnf/Dv7E0nbzSuQ/YkMHzfyqJdyNfFGRoGbRYXobZNF6cRERNTQq3vtMlQMU A3Jn2O6/Vqp4/vdgFEiwdLVCjOhKCbSu1wX8eHr6NVmSvP/59o+npBBgDA0/wWivI9u8y onaLW0Y/cA3H8rhAVXGhSi4yKqNvGr+SESJ7eYs1eYffha198zEp/UO+3dy0W/m6lT/f4 /iJ5XUrJRC/8rpgMX0DMfjeQq99CCcBX6nvmpMaCli3lgBqJPS4Vlq7662WCBXYKs54CG ITI2h/aGjuOrTZ0z04NLya9Gd7RtNZBPJM1Ak+MEX/p3uPGrWuoQPSU4LEXayA1DNK1Oj BleelDtJke28AzY2W9cO2w0InJ84iQeeUtk+/qzLDM5ooOBOfnNwWGdvyZRRuPqNhCva/ Nl2Nkp36z1JDKI5IIvzrMDP/RIPaMEejnQaV7aVImYR4WzTjmhTvwvR9R/VpXLn2/8/Uk CwLoqHCn5LlbWBM5keIq7zRQH5b2fdS3b46rwh7liYKth8AnTttz+Ws67Fu0uwBgOKmUc u+L4viiyr3fsQKN4LID+/Del/c8q8BJCD5CTs/LBxFhvDB0nCYAst7YehFyeAwZ/zQF0x T8bMKeiDEZnM4RpsvCqRuBGox93w7b9sHOTKxL5PKOlaqj2usUZRndj5CtI5T+8= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1767688854; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=nPf2LAuIWbTF6a75nZl47tigpN5euymIO5ZZ4SIV92o=; b=rDGyXkg0jSII2p1KayKvupX2wKaTdwJhKa5N4pGz8JgfxWdEavFtl1OETW+ZJ0dOL5vh wVJ4j3aG7vJA63FmJDjH/rJ3SgcSU7iuErXITg2A/n3J4pDVvAZVeS0tLDCNNrGpyiuKt GLYHQ25Xgv5LbnUROgyWBCKTfQRM4Vs0iq9rR+vMs5ZXxorwFQ6UGncAcg2+nnxEtAvZl 7lm6EkjEVXvQbmeWkqeKdYCwr5Mp/K20zD2sdjXTuEZp6ytZ5S9zxE6ajlaFwOuSLIHWK /nAL/3SnkUTw5KxgUQAXgQRtkM32wrxQAK+mFLzBvvtN+Y8FAT8cSdAMuxKbTyRfWwmVM Y/T2Hun9G4YrwHv91SJ5owto/PzmkdezdgE7dcrYHHyT8dYaqrZJZl0//zo3yTM+942E6 m4cFqmUTZZpeeRUMsRg4EdsbGaovoRH/v2szsAcSbtwAw8krJzqv+mDan74Ee/jVyvLix p+2cnWo/jMvkvBKfb1gDlz5eTG0FXllFwdc3279oraZWGKhhHLZAc9G+Txyd7NNl8Jxek 8UIfSuRNy9DZDuZAbHr3w9LKFR+3WiNnijod5KusI9abtB1FBIrbub9cSXfuQ+7NVzMTg SLxp9NQiyFZRfmUXHihaAmOUi1lfkelj3tyE9/FQiN+palz6qPL4jQmoNZ+28rM= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Tue, 06 Jan 2026 09:40:53 +0100 From: Nicola Vetrini To: Bertrand Marquis Cc: Xen-devel , Stefano Stabellini , "consulting @ bugseng . com" , Jan Beulich , =?UTF-8?Q?R?= =?UTF-8?Q?oger_Pau_Monn=C3=A9?= , Julien Grall , Volodymyr Babchuk , Michal Orzel , Andrew Cooper Subject: Re: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible In-Reply-To: <541EF107-3536-4525-ACC2-065A9A13481B@arm.com> References: <20260105122436.555444-1-andrew.cooper3@citrix.com> <82d99c52-c39b-4fbb-bbb2-0e952df91673@citrix.com> <541EF107-3536-4525-ACC2-065A9A13481B@arm.com> Message-ID: <543958adfed3e5547141d56341c2788d@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 2026-01-06 09:26, Bertrand Marquis wrote: > Hi Nicolas, > > On this subject, could you help me understand what the following error > mean and how I should fix that: > https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/hardware/xen-staging/ECLAIR_normal/andrew/eclair/ARM64/12604499722/PROJECT.ecd;/by_service/MC3A2.R20.12.html > Hi Bertrand, the point here is that the macro parameter 'FFA_VERSION' is itself a macro. This means that inside 'FW_ABI' and similar macros one occurrence of the 'abi' macro parameter will be further expanded to the value of 'FFA_VERSION', while the one used for stringification will not. This is potentially confusing for some programmers that do not know well the semantics of the preprocessor, which is why MISRA discourages it, but in these cases I would say it's very much intentional. There are already a few deviations for special cases (e.g. BUILD_BUG_ON uses the same pattern to print the condition), so I would suggest adding the macro FW_ABI to the deviation. > Thanks > Bertrand > >> On 6 Jan 2026, at 08:33, Bertrand Marquis >> wrote: >> >> Hi Andrew, >> >>> On 5 Jan 2026, at 19:14, Andrew Cooper >>> wrote: >>> >>> On 05/01/2026 12:24 pm, Andrew Cooper wrote: >>>> eclair-x86_64-testing: >>>> @@ -104,6 +122,33 @@ eclair-ARM64-allcode: >>>> LOGFILE: "eclair-ARM64.log" >>>> VARIANT: "ARM64" >>>> RULESET: "monitored" >>>> + EXTRA_XEN_CONFIG: | >>>> + CONFIG_ACPI=y >>>> + CONFIG_ARGO=y >>>> + CONFIG_ARM64_SVE=y >>>> + CONFIG_ARM_SMMU_V3=y >>>> + CONFIG_BOOT_TIME_CPUPOOLS=y >>>> + CONFIG_DEBUG_LOCK_PROFILE=y >>>> + CONFIG_DEBUG_TRACE=y >>>> + CONFIG_DEVICE_TREE_DEBUG=y >>>> + CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y >>>> + CONFIG_EXPERT=y >>>> + CONFIG_FFA=y >>>> + CONFIG_FFA_VM_TO_VM=y >>>> + CONFIG_GICV3_ESPI=y >>>> + CONFIG_HAS_ITS=y >>>> + CONFIG_IOREQ_SERVER=y >>>> + CONFIG_IPMMU_VMSA=y >>>> + CONFIG_LIVEPATCH=y >>>> + CONFIG_LLC_COLORING=y >>>> + CONFIG_OPTEE=y >>>> + CONFIG_OVERLAY_DTB=y >>>> + CONFIG_PCI_PASSTHROUGH=y >>>> + CONFIG_PERF_ARRAYS=y >>>> + CONFIG_PERF_COUNTERS=y >>>> + CONFIG_STACK_PROTECTOR=y >>>> + CONFIG_UNSUPPORTED=y >>>> + CONFIG_VM_EVENT=y >>>> allow_failure: true >>> >>> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/12604499722 >>> shows 122 failures in otherwise-clean guidelines. Some observations: >>> >>> llc-colouring.c uses binary literals. These are safe to use now >>> since >>> 4.21 with the updated toolchain baseline, but the Eclair config wants >>> updating to allow this language extension. >>> >>> ipmmu-vmsa.c has a git:// url inside a block comment, which is >>> considered to be a Rule 3.1 violation. In principle this ought to >>> fix it: >>> >>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl >>> b/automation/eclair_analysis/ECLAIR/deviations.ecl >>> index 7dee4a488d45..8f5fc6c93bc5 100644 >>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl >>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl >>> @@ -60,7 +60,7 @@ removed by the compiler, the resulting slowdown is >>> negligible." >>> >>> -doc_begin="Comments starting with '/*' and containing hyperlinks are >>> safe as >>> they are not instances of commented-out code." >>> --config=MC3A2.R3.1,reports+={safe, >>> "first_area(text(^.*https?://.*$))"} >>> +-config=MC3A2.R3.1,reports+={safe, >>> "first_area(text(^.*(https?|git)://.*$))"} >>> -doc_end >>> >>> # >>> >>> >>> but I've not tried it yet. >>> >>> There's a R8.4 violation against __stack_chk_guard. I think this >>> wants >>> deviating locally, because it's a fairly magic construct. >>> >>> Other than that, there's a smattering of violations. Some will be >>> fixed >>> by some work I've got pending for the x86 side of things, but most >>> are >>> specific to arch/arm/. >>> >> >> They are quite a lot of violations coming from ffa. >> I have a pending serie on FF-A waiting to be reviewed/committed. >> I can push something to fix the findings after it, if that is ok for >> you ? >> >> I will retrigger the CI from the branch corresponding to my serie and >> work >> from there. >> >> In any case, very good thing to activate all those and check with the >> CI, thanks a lot :-) >> >> Cheers >> Bertrand >> >>> ~Andrew -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Tue Jan 06 08:43:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 08:43:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195900.1513778 (Exim 4.92) (envelope-from ) id 1vd2ex-0002QL-PM; Tue, 06 Jan 2026 08:43:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195900.1513778; Tue, 06 Jan 2026 08:43:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd2ex-0002QE-ML; Tue, 06 Jan 2026 08:43:23 +0000 Received: by outflank-mailman (input) for mailman id 1195900; Tue, 06 Jan 2026 08: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 1vd2ew-0002Q8-54 for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 08:43:22 +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 bff25556-eadb-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 09:43:19 +0100 (CET) Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-64b608ffca7so952348a12.3 for ; Tue, 06 Jan 2026 00:43:19 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6507b9d4c0asm1549446a12.9.2026.01.06.00.43.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 00:43:15 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bff25556-eadb-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767688998; x=1768293798; 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=8Cv2Ql8VdVagTE0RWAlWbZxKzTc4eqa0BtII0luXEeQ=; b=IECy8ddzR47lBJqteZ69Czfl7ma9dMlu5ZfUPKr1yjh1QJq3YGuvVY8FJb8GAnvs2V ONJTlmpjGx70GkMZcIIgu1MNpoqXhifr9YqtN+ictpVTlOouKjmzOGIfnJsuYsU7ih1k F7dxtpC2fAjXf6xeBtYEUiHZ8hg/Zwm2HUjztcTq4FoBj9dm7E68uy306oE17KQuKMMh wKj1QlHC1z4DsffeXvRmzkMo5ZtVYAM7u4c10jl2F6Q6tMc/k+7Y6aFFtw/5UdB/NbdM kqDZvaSos9zRn+lvj3/Swe86aABkf0l93EgIodz2kJOCkW9JTT3OgV2yhMHyOs/4qR9p FG2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767688998; x=1768293798; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8Cv2Ql8VdVagTE0RWAlWbZxKzTc4eqa0BtII0luXEeQ=; b=cYGaNfxdRxJDvQZrI/Pbt+i13n4Pc3HJsQ1NZxhvPqOkiHWdMiEKKuW7J9ziifsMXE WTV59QEii1Po+j8eAUCb/CcJIi9qyV5DP8sysdr83xoO03Liz0yGO4bOlTo2nu+BvG13 CABbmrD9cjliv6lkL4Vw5ASjJdCjSVgdy9ysSMQOOw/xFdNk5FHnUrJ2ZPPnA3QZQovT DbKzki5NIfuaCGkH3R4uIIqti5vFgtkDcDyerZF562rZP9opY+hgRyKdxpCY0k+ydYbd Tek9Gn/4GUPwLjhyo0lSQIjolH+NPFsXoffH6+1J0PS1JrV9bFjjRNm7Y01ACInxGtey wRqw== X-Forwarded-Encrypted: i=1; AJvYcCWUCor2F31tJzmE2OuwglUfieG6PAWV+jVuWRvlDNwU8mGTwG+rUxnULiENnbBPSRc8YXq0qXoYKd8=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy5h59Tk/m+DaUp6KiPAciugXMgoePbBeTF2xQ1f0v3EdAKoidB YkzsIcyL0QYTW3+NgfJbLe5jUBFLjQw07aICim1jO77yikDuSgNjjgHG X-Gm-Gg: AY/fxX6Ruo+0EH2Di0MSAqpGdnVOaoNJeB2puiOWK/kEZtQMk825LMoiWyeEwQFSCMt 0EtTkdbKbomnO1Y8X8HQxGPqlliYrctdNmoSPEjSKzU0fU4YriUyBiftJ7OOsOoa73SYrJWhpyH OXfa7kwyKiUoomBYxS0zkaVVSaP2kHgOlLBnUFBSWBxK+k7u+yjgJmvtnLJ59/4qsZ2RnZpAek+ ff2rDpL+/w76lBmwZeDwilk1yt9BQuTNGsFPjKF1WdVdUIW0thAAi9FFEyUkQXaFaPg/nePDbGd YcpsoKxWKB7tfYFMh+rzhjDsHzTjknUN5RujG5J5Pb16u7qPXuwAH2bvbIUE9+mFNyEGW1PQ9ak PfkSQIijUNOfR0+DONlAtk75CUdjMxNTSWM5k5j1ce772ju3wXqp9IweeM0it+1waX5MT+T9sLb pH+6nwgDTc72j4mFlK5ThD4ZI7BLPtX/z2mHqUa3AgZI3cNjHPvSxgHzVmFcqWTyU= X-Google-Smtp-Source: AGHT+IH5YKS4rbka398AK4n+4Jm7WsK7PTvxTCF7SUO7xrL7W3OoXqSGp9bzNeXepI3sGjYbL/V8TQ== X-Received: by 2002:a05:6402:2113:b0:64d:4f75:aa28 with SMTP id 4fb4d7f45d1cf-65079561dd7mr2140089a12.18.1767688996223; Tue, 06 Jan 2026 00:43:16 -0800 (PST) Message-ID: <724e78ef-b6ed-40db-a5c0-bd6473b6fe16@gmail.com> Date: Tue, 6 Jan 2026 09:43:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen: Drop xenoprofile support To: Andrew Cooper , Xen-devel Cc: Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P . Smith" References: <20260105195717.601500-1-andrew.cooper3@citrix.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <20260105195717.601500-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/5/26 8:57 PM, Andrew Cooper wrote: > The most recent xenoprof change was 300ef0cb4fde ("x86: Add Xenoprofile > support for AMD Family16h") in 2013, despite there being 42 changes worth of > other cleanup/rearranging since then. > > Oprofile themselves dropped Xen support in commit 0c142c3a096d ("Remove > opcontrol and the GUI and processor models dependent on it") in 2014, as part > of releasing version 1.0 and switching over to using operf based on the Linux > perf_event subsystem. Linux's version of this patch was merged in commit > 24880bef417f ("Merge tag 'oprofile-removal-5.12'") in 2021. > > Drop xenoprof and all supporting infrastructure, including the hypercall, the > XSM hook and flask vectors which lose their only caller, and even shrinks > struct domain by one pointer which wasn't properly excluded in > !CONFIG_XENOPROF builds. > > Retain the public xenoprof.h header as it is ABI, but note that the > functionality is removed. > > 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: Daniel P. Smith > > Despite appearing to be architecture neutral, the internals of Xenoprof were > entirely x86-specific. Another curiosity is that only the VMX MSR hooks > called passive_domain_do_{rd,wr}msr(), and I can't see how this was correct > for SVM. > > The real reason for finally getting around to this is the number of MISRA > violations reported by the eclair-x86_64-allcode job that I don't feel like > fixing. > --- > CHANGELOG.md | 3 + > docs/misc/xen-command-line.pandoc | 6 - > tools/flask/policy/modules/dom0.te | 2 - > xen/arch/x86/Makefile | 1 - > xen/arch/x86/cpu/vpmu_amd.c | 7 - > xen/arch/x86/cpu/vpmu_intel.c | 6 - > xen/arch/x86/hvm/svm/entry.S | 1 - > xen/arch/x86/hvm/svm/svm.c | 2 - > xen/arch/x86/hvm/vmx/vmx.c | 9 - > xen/arch/x86/include/asm/xenoprof.h | 95 --- > xen/arch/x86/oprofile/Makefile | 6 - > xen/arch/x86/oprofile/backtrace.c | 145 ---- > xen/arch/x86/oprofile/nmi_int.c | 485 ------------ > xen/arch/x86/oprofile/op_counter.h | 41 - > xen/arch/x86/oprofile/op_model_athlon.c | 547 ------------- > xen/arch/x86/oprofile/op_model_p4.c | 721 ----------------- > xen/arch/x86/oprofile/op_model_ppro.c | 348 --------- > xen/arch/x86/oprofile/op_x86_model.h | 58 -- > xen/arch/x86/oprofile/xenoprof.c | 106 --- > xen/arch/x86/traps.c | 4 - > xen/common/Kconfig | 11 - > xen/common/Makefile | 1 - > xen/common/compat/xenoprof.c | 42 - > xen/common/domain.c | 6 - > xen/common/xenoprof.c | 977 ------------------------ > xen/include/Makefile | 1 - > xen/include/hypercall-defs.c | 6 - > xen/include/public/xen.h | 2 +- > xen/include/public/xenoprof.h | 2 +- > xen/include/xen/sched.h | 3 - > xen/include/xen/xenoprof.h | 49 -- > xen/include/xsm/dummy.h | 7 - > xen/include/xsm/xsm.h | 7 - > xen/xsm/dummy.c | 2 - > xen/xsm/flask/hooks.c | 35 - > xen/xsm/flask/policy/access_vectors | 4 - > 36 files changed, 5 insertions(+), 3743 deletions(-) > delete mode 100644 xen/arch/x86/include/asm/xenoprof.h > delete mode 100644 xen/arch/x86/oprofile/Makefile > delete mode 100644 xen/arch/x86/oprofile/backtrace.c > delete mode 100644 xen/arch/x86/oprofile/nmi_int.c > delete mode 100644 xen/arch/x86/oprofile/op_counter.h > delete mode 100644 xen/arch/x86/oprofile/op_model_athlon.c > delete mode 100644 xen/arch/x86/oprofile/op_model_p4.c > delete mode 100644 xen/arch/x86/oprofile/op_model_ppro.c > delete mode 100644 xen/arch/x86/oprofile/op_x86_model.h > delete mode 100644 xen/arch/x86/oprofile/xenoprof.c > delete mode 100644 xen/common/compat/xenoprof.c > delete mode 100644 xen/common/xenoprof.c > delete mode 100644 xen/include/xen/xenoprof.h > > diff --git a/CHANGELOG.md b/CHANGELOG.md > index 3aaf5986231c..1663f6878ef2 100644 > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -15,6 +15,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) > - The cpuid_mask_* command line options for legacy AMD CPUs. These were > deprecated in Xen 4.7 and noted not to work correctly with AMD CPUs from > 2011 onwards. > + - Xenoprofile support. Oprofile themselves removed support for Xen in 2014 > + prior to the version 1.0 release, and there has been no development since > + before then in Xen. LGTM: Acked-by: Oleksii Kurochko # CHANGELOG.md Nit: It is necessary to drop the extra space before " Oprofile themselves...". Thanks. ~ Oleksii > > ## [4.21.0](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.21.0) - 2025-11-19 > > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc > index 805da22c44a5..189d0d2c9d4b 100644 > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -508,12 +508,6 @@ character, but for xen to keep the console. > > > Default: `power` > > -### cpu_type (x86) > -> `= arch_perfmon` > - > -If set, force use of the performance counters for oprofile, rather than detecting > -available support. > - > ### cpufreq > > `= none | {{ | xen } { [:[powersave|performance|ondemand|userspace][,[]][,[]]] } [,verbose]} | dom0-kernel | hwp[:[][,verbose]] | amd-cppc[:[active][,verbose]]` > > diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te > index ad2b4f9ea75f..d30edf8be1fb 100644 > --- a/tools/flask/policy/modules/dom0.te > +++ b/tools/flask/policy/modules/dom0.te > @@ -21,8 +21,6 @@ allow dom0_t xen_t:xen { > writeconsole > readapic > writeapic > - privprofile > - nonprivprofile > kexec > firmware > sleep > diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile > index 1fc651146f10..d8b41cec1620 100644 > --- a/xen/arch/x86/Makefile > +++ b/xen/arch/x86/Makefile > @@ -7,7 +7,6 @@ obj-$(CONFIG_GUEST) += guest/ > obj-$(CONFIG_HVM) += hvm/ > obj-y += lib/ > obj-y += mm/ > -obj-$(CONFIG_XENOPROF) += oprofile/ > obj-$(CONFIG_PV) += pv/ > obj-y += x86_64/ > obj-y += x86_emulate/ > diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c > index fa157d45dd01..aee99bb88128 100644 > --- a/xen/arch/x86/cpu/vpmu_amd.c > +++ b/xen/arch/x86/cpu/vpmu_amd.c > @@ -12,7 +12,6 @@ > > #include > #include > -#include > > #include > #include > @@ -363,8 +362,6 @@ static int cf_check amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content) > if ( (type == MSR_TYPE_CTRL) && > is_pmu_enabled(msr_content) && !vpmu_is_set(vpmu, VPMU_RUNNING) ) > { > - if ( !acquire_pmu_ownership(PMU_OWNER_HVM) ) > - return 0; > vpmu_set(vpmu, VPMU_RUNNING); > > if ( is_svm_vcpu(v) && is_msr_bitmap_on(vpmu) ) > @@ -378,7 +375,6 @@ static int cf_check amd_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content) > vpmu_reset(vpmu, VPMU_RUNNING); > if ( is_svm_vcpu(v) && is_msr_bitmap_on(vpmu) ) > amd_vpmu_unset_msr_bitmap(v); > - release_pmu_ownership(PMU_OWNER_HVM); > } > > if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) > @@ -426,9 +422,6 @@ static void cf_check amd_vpmu_destroy(struct vcpu *v) > vpmu->context = NULL; > vpmu->priv_context = NULL; > > - if ( vpmu_is_set(vpmu, VPMU_RUNNING) ) > - release_pmu_ownership(PMU_OWNER_HVM); > - > vpmu_clear(vpmu); > } > > diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c > index 7ce98ee42e54..1e3b06ef8e68 100644 > --- a/xen/arch/x86/cpu/vpmu_intel.c > +++ b/xen/arch/x86/cpu/vpmu_intel.c > @@ -9,7 +9,6 @@ > > #include > #include > -#include > #include > #include > #include > @@ -441,9 +440,6 @@ static int cf_check core2_vpmu_alloc_resource(struct vcpu *v) > struct xen_pmu_intel_ctxt *core2_vpmu_cxt = NULL; > uint64_t *p = NULL; > > - if ( !acquire_pmu_ownership(PMU_OWNER_HVM) ) > - return 0; > - > if ( is_vmx_vcpu(v) ) > { > if ( vmx_add_host_load_msr(v, MSR_CORE_PERF_GLOBAL_CTRL, 0) ) > @@ -487,7 +483,6 @@ static int cf_check core2_vpmu_alloc_resource(struct vcpu *v) > return 1; > > out_err: > - release_pmu_ownership(PMU_OWNER_HVM); > > xfree(core2_vpmu_cxt); > xfree(p); > @@ -814,7 +809,6 @@ static void cf_check core2_vpmu_destroy(struct vcpu *v) > vpmu->priv_context = NULL; > if ( is_vmx_vcpu(v) && cpu_has_vmx_msr_bitmap ) > core2_vpmu_unset_msr_bitmap(v); > - release_pmu_ownership(PMU_OWNER_HVM); > vpmu_clear(vpmu); > } > > diff --git a/xen/arch/x86/hvm/svm/entry.S b/xen/arch/x86/hvm/svm/entry.S > index 610c64bf4c97..af8db23b033f 100644 > --- a/xen/arch/x86/hvm/svm/entry.S > +++ b/xen/arch/x86/hvm/svm/entry.S > @@ -155,7 +155,6 @@ __UNLIKELY_END(nsvm_hap) > * to safely resolve any Spectre-v1 concerns in the above logic. > */ > stgi > -LABEL(svm_stgi_label, 0) > call svm_vmexit_handler > jmp .Lsvm_do_resume > > diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c > index 1208999454d3..da113f488b71 100644 > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -36,7 +36,6 @@ > #include > #include > #include > -#include > > #include > > @@ -1152,7 +1151,6 @@ static int cf_check svm_vcpu_initialise(struct vcpu *v) > static void cf_check svm_vcpu_destroy(struct vcpu *v) > { > svm_destroy_vmcb(v); > - passive_domain_destroy(v); > } > > /* > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c > index 05b59cb8e4d2..f4beac192d75 100644 > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -48,7 +48,6 @@ > #include > #include > #include > -#include > > #include > #include > @@ -692,7 +691,6 @@ static void cf_check vmx_vcpu_destroy(struct vcpu *v) > */ > vmx_vcpu_disable_pml(v); > vmx_destroy_vmcs(v); > - passive_domain_destroy(v); > } > > /* > @@ -3560,9 +3558,6 @@ static int cf_check vmx_msr_read_intercept( > break; > > default: > - if ( passive_domain_do_rdmsr(msr, msr_content) ) > - goto done; > - > if ( vmx_read_guest_msr(curr, msr, msr_content) == 0 ) > break; > > @@ -3582,7 +3577,6 @@ static int cf_check vmx_msr_read_intercept( > goto gp_fault; > } > > -done: > HVM_DBG_LOG(DBG_LEVEL_MSR, "returns: ecx=%#x, msr_value=%#"PRIx64, > msr, *msr_content); > return X86EMUL_OKAY; > @@ -3875,9 +3869,6 @@ static int cf_check vmx_msr_write_intercept( > break; > > default: > - if ( passive_domain_do_wrmsr(msr, msr_content) ) > - return X86EMUL_OKAY; > - > if ( vmx_write_guest_msr(v, msr, msr_content) == 0 || > is_last_branch_msr(msr) ) > break; > diff --git a/xen/arch/x86/include/asm/xenoprof.h b/xen/arch/x86/include/asm/xenoprof.h > deleted file mode 100644 > index dc6f822d3220..000000000000 > --- a/xen/arch/x86/include/asm/xenoprof.h > +++ /dev/null > @@ -1,95 +0,0 @@ > -/* SPDX-License-Identifier: GPL-2.0-or-later */ > -/****************************************************************************** > - * asm-x86/xenoprof.h > - * xenoprof x86 arch specific header file > - * > - * Copyright (c) 2006 Isaku Yamahata > - * VA Linux Systems Japan K.K. > - */ > - > -#ifndef __ASM_X86_XENOPROF_H__ > -#define __ASM_X86_XENOPROF_H__ > - > -struct vcpu; > - > -#ifdef CONFIG_XENOPROF > - > -#include > - > -int nmi_reserve_counters(void); > -int nmi_setup_events(void); > -int nmi_enable_virq(void); > -int nmi_start(void); > -void nmi_stop(void); > -void nmi_disable_virq(void); > -void nmi_release_counters(void); > - > -int xenoprof_arch_init(int *num_events, char *cpu_type); > -#define xenoprof_arch_reserve_counters() nmi_reserve_counters() > -#define xenoprof_arch_setup_events() nmi_setup_events() > -#define xenoprof_arch_enable_virq() nmi_enable_virq() > -#define xenoprof_arch_start() nmi_start() > -#define xenoprof_arch_stop() nmi_stop() > -#define xenoprof_arch_disable_virq() nmi_disable_virq() > -#define xenoprof_arch_release_counters() nmi_release_counters() > - > -int xenoprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg); > -int compat_oprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg); > -int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE_PARAM(void) arg); > - > -struct cpu_user_regs; > - > -/* AMD IBS support */ > -void ibs_init(void); > -extern u32 ibs_caps; > - > -int xenoprofile_get_mode(struct vcpu *, const struct cpu_user_regs *); > - > -static inline int xenoprof_backtrace_supported(void) > -{ > - return 1; > -} > - > -void xenoprof_backtrace(struct vcpu *, const struct cpu_user_regs *, > - unsigned long depth, int mode); > - > -int passive_domain_do_rdmsr(unsigned int msr, uint64_t *msr_content); > -int passive_domain_do_wrmsr(unsigned int msr, uint64_t msr_content); > -void passive_domain_destroy(struct vcpu *v); > - > -bool nmi_oprofile_send_virq(void); > - > -#else > - > -static inline int passive_domain_do_rdmsr(unsigned int msr, > - uint64_t *msr_content) > -{ > - return 0; > -} > - > -static inline int passive_domain_do_wrmsr(unsigned int msr, > - uint64_t msr_content) > -{ > - return 0; > -} > - > -static inline void passive_domain_destroy(struct vcpu *v) {} > - > -static inline bool nmi_oprofile_send_virq(void) > -{ > - return false; > -} > - > -#endif /* CONFIG_XENOPROF */ > - > -#endif /* __ASM_X86_XENOPROF_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/x86/oprofile/Makefile b/xen/arch/x86/oprofile/Makefile > deleted file mode 100644 > index 956e3d1b5d05..000000000000 > --- a/xen/arch/x86/oprofile/Makefile > +++ /dev/null > @@ -1,6 +0,0 @@ > -obj-y += xenoprof.o > -obj-y += nmi_int.o > -obj-y += op_model_p4.o > -obj-y += op_model_ppro.o > -obj-y += op_model_athlon.o > -obj-y += backtrace.o > diff --git a/xen/arch/x86/oprofile/backtrace.c b/xen/arch/x86/oprofile/backtrace.c > deleted file mode 100644 > index 61de18c8d596..000000000000 > --- a/xen/arch/x86/oprofile/backtrace.c > +++ /dev/null > @@ -1,145 +0,0 @@ > -/** > - * @file backtrace.c > - * > - * @remark Copyright 2002 OProfile authors > - * @remark Read the file COPYING > - * > - * @author John Levon > - * @author David Smith > - * Modified for Xen by Amitabha Roy > - * > - */ > - > -#include > -#include > -#include > -#include > - > -struct __packed frame_head { > - struct frame_head * ebp; > - unsigned long ret; > -}; > -typedef struct frame_head frame_head_t; > - > -struct __packed frame_head_32bit { > - uint32_t ebp; > - uint32_t ret; > -}; > -typedef struct frame_head_32bit frame_head32_t; > - > -static struct frame_head * > -dump_hypervisor_backtrace(struct vcpu *vcpu, const struct frame_head *head, > - int mode) > -{ > - if (!xenoprof_add_trace(vcpu, head->ret, mode)) > - return 0; > - > - /* frame pointers should strictly progress back up the stack > - * (towards higher addresses) */ > - if (head >= head->ebp) > - return NULL; > - > - return head->ebp; > -} > - > -static inline int is_32bit_vcpu(struct vcpu *vcpu) > -{ > - if (is_hvm_vcpu(vcpu)) > - return !hvm_long_mode_active(vcpu); > - else > - return is_pv_32bit_vcpu(vcpu); > -} > - > -static struct frame_head * > -dump_guest_backtrace(struct vcpu *vcpu, const struct frame_head *head, > - int mode) > -{ > - /* Also check accessibility of one struct frame_head beyond. */ > - frame_head_t bufhead[2]; > - > - if ( is_32bit_vcpu(vcpu) ) > - { > - frame_head32_t bufhead32[2]; > - > - if ( raw_copy_from_guest(bufhead32, head, sizeof(bufhead32)) ) > - return 0; > - bufhead[0].ebp = (struct frame_head *)(unsigned long)bufhead32[0].ebp; > - bufhead[0].ret = bufhead32[0].ret; > - } > - else if ( raw_copy_from_guest(bufhead, head, sizeof(bufhead)) ) > - return 0; > - > - if ( !xenoprof_add_trace(vcpu, bufhead[0].ret, mode) ) > - return 0; > - > - /* frame pointers should strictly progress back up the stack > - * (towards higher addresses) */ > - if ( head >= bufhead[0].ebp ) > - return NULL; > - > - return bufhead[0].ebp; > -} > - > -/* > - * | | /\ Higher addresses > - * | | > - * --------------- stack base (address of current_thread_info) > - * | thread info | > - * . . > - * | stack | > - * --------------- saved regs->ebp value if valid (frame_head address) > - * . . > - * --------------- saved regs->rsp value if x86_64 > - * | | > - * --------------- struct pt_regs * stored on stack if 32-bit > - * | | > - * . . > - * | | > - * --------------- %esp > - * | | > - * | | \/ Lower addresses > - * > - * Thus, regs (or regs->rsp for x86_64) <-> stack base restricts the > - * valid(ish) ebp values. Note: (1) for x86_64, NMI and several other > - * exceptions use special stacks, maintained by the interrupt stack table > - * (IST). These stacks are set up in trap_init() in > - * arch/x86_64/kernel/traps.c. Thus, for x86_64, regs now does not point > - * to the kernel stack; instead, it points to some location on the NMI > - * stack. On the other hand, regs->rsp is the stack pointer saved when the > - * NMI occurred. (2) For 32-bit, regs->esp is not valid because the > - * processor does not save %esp on the kernel stack when interrupts occur > - * in the kernel mode. > - */ > -#if defined(CONFIG_FRAME_POINTER) > -static int valid_hypervisor_stack(const struct frame_head *head, > - const struct cpu_user_regs *regs) > -{ > - unsigned long headaddr = (unsigned long)head; > - unsigned long stack = (unsigned long)regs->rsp; > - unsigned long stack_base = (stack & ~(STACK_SIZE - 1)) + STACK_SIZE; > - > - return headaddr > stack && headaddr < stack_base; > -} > -#else > -/* without fp, it's just junk */ > -static int valid_hypervisor_stack(const struct frame_head *head, > - const struct cpu_user_regs *regs) > -{ > - return 0; > -} > -#endif > - > -void xenoprof_backtrace(struct vcpu *vcpu, const struct cpu_user_regs *regs, > - unsigned long depth, int mode) > -{ > - const struct frame_head *head = (void *)regs->rbp; > - > - if (mode > 1) { > - while (depth-- && valid_hypervisor_stack(head, regs)) > - head = dump_hypervisor_backtrace(vcpu, head, mode); > - return; > - } > - > - while (depth-- && head) > - head = dump_guest_backtrace(vcpu, head, mode); > -} > diff --git a/xen/arch/x86/oprofile/nmi_int.c b/xen/arch/x86/oprofile/nmi_int.c > deleted file mode 100644 > index 1d6454cf39e8..000000000000 > --- a/xen/arch/x86/oprofile/nmi_int.c > +++ /dev/null > @@ -1,485 +0,0 @@ > -/** > - * @file nmi_int.c > - * > - * @remark Copyright 2002 OProfile authors > - * @remark Read the file COPYING > - * > - * @author John Levon > - * > - * Modified for Xen: by Aravind Menon & Jose Renato Santos > - * These modifications are: > - * Copyright (C) 2005 Hewlett-Packard Co. > - */ > - > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > - > -#include > - > -#include > -#include > -#include > -#include > -#include > - > -#include "op_counter.h" > -#include "op_x86_model.h" > - > -struct op_counter_config counter_config[OP_MAX_COUNTER]; > -struct op_ibs_config ibs_config; > - > -struct op_x86_model_spec const *__read_mostly model; > -static struct op_msrs cpu_msrs[NR_CPUS]; > -static unsigned long saved_lvtpc[NR_CPUS]; > - > -static const char *cpu_type; > - > -static DEFINE_PER_CPU(struct vcpu *, nmi_cont_vcpu); > - > -static int passive_domain_msr_op_checks(unsigned int msr, int *typep, int *indexp) > -{ > - struct vpmu_struct *vpmu = vcpu_vpmu(current); > - if ( model == NULL ) > - return 0; > - if ( model->is_arch_pmu_msr == NULL ) > - return 0; > - if ( !model->is_arch_pmu_msr(msr, typep, indexp) ) > - return 0; > - > - if ( !vpmu_is_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED) ) > - if ( ! model->allocated_msr(current) ) > - return 0; > - return 1; > -} > - > -int passive_domain_do_rdmsr(unsigned int msr, uint64_t *msr_content) > -{ > - int type, index; > - > - if ( !passive_domain_msr_op_checks(msr, &type, &index)) > - return 0; > - > - model->load_msr(current, type, index, msr_content); > - return 1; > -} > - > -int passive_domain_do_wrmsr(unsigned int msr, uint64_t msr_content) > -{ > - int type, index; > - > - if ( !passive_domain_msr_op_checks(msr, &type, &index)) > - return 0; > - > - model->save_msr(current, type, index, msr_content); > - return 1; > -} > - > -void passive_domain_destroy(struct vcpu *v) > -{ > - struct vpmu_struct *vpmu = vcpu_vpmu(v); > - if ( vpmu_is_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED) ) > - model->free_msr(v); > -} > - > -bool nmi_oprofile_send_virq(void) > -{ > - struct vcpu *v = xchg(&this_cpu(nmi_cont_vcpu), NULL); > - > - if (v) > - send_guest_vcpu_virq(v, VIRQ_XENOPROF); > - > - return v; > -} > - > -static int cf_check nmi_callback(const struct cpu_user_regs *regs, int cpu) > -{ > - int xen_mode, ovf; > - > - ovf = model->check_ctrs(cpu, &cpu_msrs[cpu], regs); > - xen_mode = ring_0(regs); > - if (ovf && is_active(current->domain) && !xen_mode && > - !this_cpu(nmi_cont_vcpu)) { > - this_cpu(nmi_cont_vcpu) = current; > - trigger_nmi_continuation(); > - } > - > - if ( ovf == 2 ) > - current->arch.nmi_pending = true; > - return 1; > -} > - > - > -static void nmi_cpu_save_registers(struct op_msrs *msrs) > -{ > - unsigned int const nr_ctrs = model->num_counters; > - unsigned int const nr_ctrls = model->num_controls; > - struct op_msr *counters = msrs->counters; > - struct op_msr *controls = msrs->controls; > - unsigned int i; > - > - for (i = 0; i < nr_ctrs; ++i) { > - rdmsrl(counters[i].addr, counters[i].value); > - } > - > - for (i = 0; i < nr_ctrls; ++i) { > - rdmsrl(controls[i].addr, controls[i].value); > - } > -} > - > - > -static void cf_check nmi_save_registers(void *dummy) > -{ > - int cpu = smp_processor_id(); > - struct op_msrs * msrs = &cpu_msrs[cpu]; > - model->fill_in_addresses(msrs); > - nmi_cpu_save_registers(msrs); > -} > - > - > -static void free_msrs(void) > -{ > - unsigned int i; > - > - for (i = 0; i < nr_cpu_ids; ++i) { > - XVFREE(cpu_msrs[i].counters); > - XVFREE(cpu_msrs[i].controls); > - } > -} > - > - > -static int allocate_msrs(void) > -{ > - unsigned int i; > - int success = 1; > - > - for_each_online_cpu (i) { > - cpu_msrs[i].counters = xvmalloc_array(struct op_msr, > - model->num_counters); > - if (!cpu_msrs[i].counters) { > - success = 0; > - break; > - } > - cpu_msrs[i].controls = xvmalloc_array(struct op_msr, > - model->num_controls); > - if (!cpu_msrs[i].controls) { > - success = 0; > - break; > - } > - } > - > - if (!success) > - free_msrs(); > - > - return success; > -} > - > - > -static void cf_check nmi_cpu_setup(void *dummy) > -{ > - int cpu = smp_processor_id(); > - struct op_msrs * msrs = &cpu_msrs[cpu]; > - model->setup_ctrs(msrs); > -} > - > - > -int nmi_setup_events(void) > -{ > - on_each_cpu(nmi_cpu_setup, NULL, 1); > - return 0; > -} > - > -int nmi_reserve_counters(void) > -{ > - if (!allocate_msrs()) > - return -ENOMEM; > - > - /* > - * We need to be careful to install our NMI handler > - * without actually triggering any NMIs as this will > - * break the core code horrifically. > - */ > - if (reserve_lapic_nmi() < 0) { > - free_msrs(); > - return -EBUSY; > - } > - /* We need to serialize save and setup for HT because the subset > - * of msrs are distinct for save and setup operations > - */ > - on_each_cpu(nmi_save_registers, NULL, 1); > - return 0; > -} > - > -int nmi_enable_virq(void) > -{ > - set_nmi_callback(nmi_callback); > - return 0; > -} > - > - > -void nmi_disable_virq(void) > -{ > - unset_nmi_callback(); > -} > - > - > -static void nmi_restore_registers(struct op_msrs * msrs) > -{ > - unsigned int const nr_ctrs = model->num_counters; > - unsigned int const nr_ctrls = model->num_controls; > - struct op_msr * counters = msrs->counters; > - struct op_msr * controls = msrs->controls; > - unsigned int i; > - > - for (i = 0; i < nr_ctrls; ++i) { > - wrmsrl(controls[i].addr, controls[i].value); > - } > - > - for (i = 0; i < nr_ctrs; ++i) { > - wrmsrl(counters[i].addr, counters[i].value); > - } > -} > - > - > -static void cf_check nmi_cpu_shutdown(void *dummy) > -{ > - int cpu = smp_processor_id(); > - struct op_msrs * msrs = &cpu_msrs[cpu]; > - nmi_restore_registers(msrs); > -} > - > - > -void nmi_release_counters(void) > -{ > - on_each_cpu(nmi_cpu_shutdown, NULL, 1); > - release_lapic_nmi(); > - free_msrs(); > -} > - > - > -static void cf_check nmi_cpu_start(void *dummy) > -{ > - int cpu = smp_processor_id(); > - struct op_msrs const * msrs = &cpu_msrs[cpu]; > - saved_lvtpc[cpu] = apic_read(APIC_LVTPC); > - apic_write(APIC_LVTPC, APIC_DM_NMI); > - model->start(msrs); > -} > - > - > -int nmi_start(void) > -{ > - on_each_cpu(nmi_cpu_start, NULL, 1); > - return 0; > -} > - > - > -static void cf_check nmi_cpu_stop(void *dummy) > -{ > - unsigned int v; > - int cpu = smp_processor_id(); > - struct op_msrs const * msrs = &cpu_msrs[cpu]; > - model->stop(msrs); > - > - /* restoring APIC_LVTPC can trigger an apic error because the delivery > - * mode and vector nr combination can be illegal. That's by design: on > - * power on apic lvt contain a zero vector nr which are legal only for > - * NMI delivery mode. So inhibit apic err before restoring lvtpc > - */ > - if ( (apic_read(APIC_LVTPC) & APIC_DM_MASK) != APIC_DM_NMI > - || (apic_read(APIC_LVTPC) & APIC_LVT_MASKED) ) > - { > - printk("nmi_stop: APIC not good %ul\n", apic_read(APIC_LVTPC)); > - mdelay(5000); > - } > - v = apic_read(APIC_LVTERR); > - apic_write(APIC_LVTERR, v | APIC_LVT_MASKED); > - apic_write(APIC_LVTPC, saved_lvtpc[cpu]); > - apic_write(APIC_LVTERR, v); > -} > - > - > -void nmi_stop(void) > -{ > - on_each_cpu(nmi_cpu_stop, NULL, 1); > -} > - > - > -static int __init p4_init(const char **cpu_type) > -{ > - unsigned int cpu_model = current_cpu_data.x86_model; > - > - if ((cpu_model > 6) || (cpu_model == 5)) { > - printk("xenoprof: Initialization failed. " > - "Intel processor model %u for pentium 4 family is not " > - "supported\n", cpu_model); > - return 0; > - } > - > - switch (current_cpu_data.x86_num_siblings) { > - case 1: > - *cpu_type = "i386/p4"; > - model = &op_p4_spec; > - return 1; > - > - case 2: > - *cpu_type = "i386/p4-ht"; > - model = &op_p4_ht2_spec; > - return 1; > - } > - > - printk("Xenoprof ERROR: P4 HyperThreading detected with > 2 threads\n"); > - > - return 0; > -} > - > - > -static int force_arch_perfmon; > - > -static int __init cf_check force_cpu_type(const char *str) > -{ > - if (!strcmp(str, "arch_perfmon")) { > - force_arch_perfmon = 1; > - printk(KERN_INFO "oprofile: forcing architectural perfmon\n"); > - } > - else > - return -EINVAL; > - > - return 0; > -} > -custom_param("cpu_type", force_cpu_type); > - > -static int __init ppro_init(const char **cpu_type) > -{ > - if (force_arch_perfmon && cpu_has_arch_perfmon) > - return 0; > - > - switch (current_cpu_data.x86_model) { > - case 14: > - *cpu_type = "i386/core"; > - break; > - case 15: > - *cpu_type = "i386/core_2"; > - ppro_has_global_ctrl = 1; > - break; > - default: > - /* Unknown */ > - return 0; > - } > - > - model = &op_ppro_spec; > - return 1; > -} > - > -static int __init arch_perfmon_init(const char **cpu_type) > -{ > - if (!cpu_has_arch_perfmon) > - return 0; > - *cpu_type = "i386/arch_perfmon"; > - model = &op_arch_perfmon_spec; > - arch_perfmon_setup_counters(); > - ppro_has_global_ctrl = 1; > - return 1; > -} > - > -static int __init cf_check nmi_init(void) > -{ > - unsigned int vendor = current_cpu_data.x86_vendor; > - unsigned int family = current_cpu_data.x86; > - > - if (!cpu_has_apic) { > - printk("xenoprof: Initialization failed. No APIC\n"); > - return -ENODEV; > - } > - > - switch (vendor) { > - case X86_VENDOR_AMD: > - /* Needs to be at least an Athlon (or hammer in 32bit mode) */ > - > - switch (family) { > - default: > - printk("xenoprof: Initialization failed. " > - "AMD processor family %u is not " > - "supported\n", family); > - return -ENODEV; > - case 0xf: > - model = &op_athlon_spec; > - cpu_type = "x86-64/hammer"; > - break; > - case 0x10: > - model = &op_athlon_spec; > - cpu_type = "x86-64/family10"; > - ibs_init(); > - break; > - case 0x11: > - model = &op_athlon_spec; > - cpu_type = "x86-64/family11h"; > - break; > - case 0x12: > - model = &op_athlon_spec; > - cpu_type = "x86-64/family12h"; > - break; > - case 0x14: > - model = &op_athlon_spec; > - cpu_type = "x86-64/family14h"; > - break; > - case 0x15: > - model = &op_amd_fam15h_spec; > - cpu_type = "x86-64/family15h"; > - break; > - case 0x16: > - model = &op_athlon_spec; > - cpu_type = "x86-64/family16h"; > - break; > - } > - break; > - > - case X86_VENDOR_INTEL: > - switch (family) { > - /* Pentium IV */ > - case 0xf: > - p4_init(&cpu_type); > - break; > - > - /* A P6-class processor */ > - case 6: > - ppro_init(&cpu_type); > - break; > - > - default: > - break; > - } > - if (!cpu_type && !arch_perfmon_init(&cpu_type)) { > - printk("xenoprof: Initialization failed. " > - "Intel processor family %u model %d is not supported\n", > - family, current_cpu_data.x86_model); > - return -ENODEV; > - } > - break; > - > - default: > - printk("xenoprof: Initialization failed. " > - "Unsupported processor. Unknown vendor %u\n", > - vendor); > - return -ENODEV; > - } > - > - return 0; > -} > - > -__initcall(nmi_init); > - > -int xenoprof_arch_init(int *num_events, char *_cpu_type) > -{ > - if (cpu_type == NULL) > - return -ENODEV; > - *num_events = model->num_counters; > - strlcpy(_cpu_type, cpu_type, XENOPROF_CPU_TYPE_SIZE); > - return 0; > -} > diff --git a/xen/arch/x86/oprofile/op_counter.h b/xen/arch/x86/oprofile/op_counter.h > deleted file mode 100644 > index b515ac9ebc8e..000000000000 > --- a/xen/arch/x86/oprofile/op_counter.h > +++ /dev/null > @@ -1,41 +0,0 @@ > -/** > - * @file op_counter.h > - * > - * @remark Copyright 2002 OProfile authors > - * @remark Read the file COPYING > - * > - * @author John Levon > - */ > - > -#ifndef OP_COUNTER_H > -#define OP_COUNTER_H > - > -#define OP_MAX_COUNTER 8 > - > -/* Per-perfctr configuration as set via > - * oprofilefs. > - */ > -struct op_counter_config { > - unsigned long count; > - unsigned long enabled; > - unsigned long event; > - unsigned long kernel; > - unsigned long user; > - unsigned long unit_mask; > -}; > - > -extern struct op_counter_config counter_config[]; > - > -/* AMD IBS configuration */ > -struct op_ibs_config { > - unsigned long op_enabled; > - unsigned long fetch_enabled; > - unsigned long max_cnt_fetch; > - unsigned long max_cnt_op; > - unsigned long rand_en; > - unsigned long dispatched_ops; > -}; > - > -extern struct op_ibs_config ibs_config; > - > -#endif /* OP_COUNTER_H */ > diff --git a/xen/arch/x86/oprofile/op_model_athlon.c b/xen/arch/x86/oprofile/op_model_athlon.c > deleted file mode 100644 > index 4c016624a69b..000000000000 > --- a/xen/arch/x86/oprofile/op_model_athlon.c > +++ /dev/null > @@ -1,547 +0,0 @@ > -/** > - * @file op_model_athlon.h > - * athlon / K7 model-specific MSR operations > - * > - * @remark Copyright 2002 OProfile authors > - * @remark Read the file COPYING > - * > - * @author John Levon > - * @author Philippe Elie > - * @author Graydon Hoare > - */ > - > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > - > -#include "op_x86_model.h" > -#include "op_counter.h" > - > -#define K7_NUM_COUNTERS 4 > -#define K7_NUM_CONTROLS 4 > - > -#define FAM15H_NUM_COUNTERS 6 > -#define FAM15H_NUM_CONTROLS 6 > - > -#define MAX_COUNTERS FAM15H_NUM_COUNTERS > - > -#define CTR_READ(msr_content,msrs,c) do {rdmsrl(msrs->counters[(c)].addr, (msr_content));} while (0) > -#define CTR_WRITE(l,msrs,c) wrmsr(msrs->counters[(c)].addr, -(l)) > -#define CTR_OVERFLOWED(n) (!((n) & (1ULL<<31))) > - > -#define CTRL_READ(msr_content,msrs,c) do {rdmsrl(msrs->controls[(c)].addr, (msr_content));} while (0) > -#define CTRL_WRITE(msr_content,msrs,c) do {wrmsrl(msrs->controls[(c)].addr, (msr_content));} while (0) > -#define CTRL_SET_ACTIVE(n) (n |= (1ULL<<22)) > -#define CTRL_SET_INACTIVE(n) (n &= ~(1ULL<<22)) > -#define CTRL_CLEAR(val) (val &= (1ULL<<21)) > -#define CTRL_SET_ENABLE(val) (val |= 1ULL<<20) > -#define CTRL_SET_USR(val,u) (val |= ((u & 1) << 16)) > -#define CTRL_SET_KERN(val,k) (val |= ((k & 1) << 17)) > -#define CTRL_SET_UM(val, m) (val |= ((m & 0xff) << 8)) > -#define CTRL_SET_EVENT(val, e) (val |= (((e >> 8) & 0xf) | (e & 0xff))) > -#define CTRL_SET_HOST_ONLY(val, h) (val |= ((h & 0x1ULL) << 41)) > -#define CTRL_SET_GUEST_ONLY(val, h) (val |= ((h & 0x1ULL) << 40)) > - > -static unsigned long reset_value[MAX_COUNTERS]; > - > -extern char svm_stgi_label[]; > - > -u32 ibs_caps = 0; > -static u64 ibs_op_ctl; > - > -/* IBS cpuid feature detection */ > -#define IBS_CPUID_FEATURES 0x8000001b > - > -/* IBS MSRs */ > -#define MSR_AMD64_IBSFETCHCTL 0xc0011030 > -#define MSR_AMD64_IBSFETCHLINAD 0xc0011031 > -#define MSR_AMD64_IBSFETCHPHYSAD 0xc0011032 > -#define MSR_AMD64_IBSOPCTL 0xc0011033 > -#define MSR_AMD64_IBSOPRIP 0xc0011034 > -#define MSR_AMD64_IBSOPDATA 0xc0011035 > -#define MSR_AMD64_IBSOPDATA2 0xc0011036 > -#define MSR_AMD64_IBSOPDATA3 0xc0011037 > -#define MSR_AMD64_IBSDCLINAD 0xc0011038 > -#define MSR_AMD64_IBSDCPHYSAD 0xc0011039 > -#define MSR_AMD64_IBSCTL 0xc001103a > - > -/* > - * Same bit mask as for IBS cpuid feature flags (Fn8000_001B_EAX), but > - * bit 0 is used to indicate the existence of IBS. > - */ > -#define IBS_CAPS_AVAIL (1LL<<0) > -#define IBS_CAPS_RDWROPCNT (1LL<<3) > -#define IBS_CAPS_OPCNT (1LL<<4) > - > -/* IBS randomization macros */ > -#define IBS_RANDOM_BITS 12 > -#define IBS_RANDOM_MASK ((1ULL << IBS_RANDOM_BITS) - 1) > -#define IBS_RANDOM_MAXCNT_OFFSET (1ULL << (IBS_RANDOM_BITS - 5)) > - > -/* IbsFetchCtl bits/masks */ > -#define IBS_FETCH_RAND_EN (1ULL<<57) > -#define IBS_FETCH_VAL (1ULL<<49) > -#define IBS_FETCH_ENABLE (1ULL<<48) > -#define IBS_FETCH_CNT 0xFFFF0000ULL > -#define IBS_FETCH_MAX_CNT 0x0000FFFFULL > - > -/* IbsOpCtl bits */ > -#define IBS_OP_CNT_CTL (1ULL<<19) > -#define IBS_OP_VAL (1ULL<<18) > -#define IBS_OP_ENABLE (1ULL<<17) > -#define IBS_OP_MAX_CNT 0x0000FFFFULL > - > -/* IBS sample identifier */ > -#define IBS_FETCH_CODE 13 > -#define IBS_OP_CODE 14 > - > -#define clamp(val, min, max) ({ \ > - typeof(val) __val = (val); \ > - typeof(min) __min = (min); \ > - typeof(max) __max = (max); \ > - (void) (&__val == &__min); \ > - (void) (&__val == &__max); \ > - __val = __val < __min ? __min: __val; \ > - __val > __max ? __max: __val; }) > - > -/* > - * 16-bit Linear Feedback Shift Register (LFSR) > - */ > -static unsigned int lfsr_random(void) > -{ > - static unsigned int lfsr_value = 0xF00D; > - unsigned int bit; > - > - /* Compute next bit to shift in */ > - bit = ((lfsr_value >> 0) ^ > - (lfsr_value >> 2) ^ > - (lfsr_value >> 3) ^ > - (lfsr_value >> 5)) & 0x0001; > - > - /* Advance to next register value */ > - lfsr_value = (lfsr_value >> 1) | (bit << 15); > - > - return lfsr_value; > -} > - > -/* > - * IBS software randomization > - * > - * The IBS periodic op counter is randomized in software. The lower 12 > - * bits of the 20 bit counter are randomized. IbsOpCurCnt is > - * initialized with a 12 bit random value. > - */ > -static inline u64 op_amd_randomize_ibs_op(u64 val) > -{ > - unsigned int random = lfsr_random(); > - > - if (!(ibs_caps & IBS_CAPS_RDWROPCNT)) > - /* > - * Work around if the hw can not write to IbsOpCurCnt > - * > - * Randomize the lower 8 bits of the 16 bit > - * IbsOpMaxCnt [15:0] value in the range of -128 to > - * +127 by adding/subtracting an offset to the > - * maximum count (IbsOpMaxCnt). > - * > - * To avoid over or underflows and protect upper bits > - * starting at bit 16, the initial value for > - * IbsOpMaxCnt must fit in the range from 0x0081 to > - * 0xff80. > - */ > - val += (int8_t)(random >> 4); > - else > - val |= (u64)(random & IBS_RANDOM_MASK) << 32; > - > - return val; > -} > - > -static void cf_check athlon_fill_in_addresses(struct op_msrs * const msrs) > -{ > - msrs->counters[0].addr = MSR_K7_PERFCTR0; > - msrs->counters[1].addr = MSR_K7_PERFCTR1; > - msrs->counters[2].addr = MSR_K7_PERFCTR2; > - msrs->counters[3].addr = MSR_K7_PERFCTR3; > - > - msrs->controls[0].addr = MSR_K7_EVNTSEL0; > - msrs->controls[1].addr = MSR_K7_EVNTSEL1; > - msrs->controls[2].addr = MSR_K7_EVNTSEL2; > - msrs->controls[3].addr = MSR_K7_EVNTSEL3; > -} > - > -static void cf_check fam15h_fill_in_addresses(struct op_msrs * const msrs) > -{ > - msrs->counters[0].addr = MSR_AMD_FAM15H_PERFCTR0; > - msrs->counters[1].addr = MSR_AMD_FAM15H_PERFCTR1; > - msrs->counters[2].addr = MSR_AMD_FAM15H_PERFCTR2; > - msrs->counters[3].addr = MSR_AMD_FAM15H_PERFCTR3; > - msrs->counters[4].addr = MSR_AMD_FAM15H_PERFCTR4; > - msrs->counters[5].addr = MSR_AMD_FAM15H_PERFCTR5; > - > - msrs->controls[0].addr = MSR_AMD_FAM15H_EVNTSEL0; > - msrs->controls[1].addr = MSR_AMD_FAM15H_EVNTSEL1; > - msrs->controls[2].addr = MSR_AMD_FAM15H_EVNTSEL2; > - msrs->controls[3].addr = MSR_AMD_FAM15H_EVNTSEL3; > - msrs->controls[4].addr = MSR_AMD_FAM15H_EVNTSEL4; > - msrs->controls[5].addr = MSR_AMD_FAM15H_EVNTSEL5; > -} > - > -static void cf_check athlon_setup_ctrs(struct op_msrs const * const msrs) > -{ > - uint64_t msr_content; > - int i; > - unsigned int const nr_ctrs = model->num_counters; > - unsigned int const nr_ctrls = model->num_controls; > - > - /* clear all counters */ > - for (i = 0 ; i < nr_ctrls; ++i) { > - CTRL_READ(msr_content, msrs, i); > - CTRL_CLEAR(msr_content); > - CTRL_WRITE(msr_content, msrs, i); > - } > - > - /* avoid a false detection of ctr overflows in NMI handler */ > - for (i = 0; i < nr_ctrs; ++i) { > - CTR_WRITE(1, msrs, i); > - } > - > - /* enable active counters */ > - for (i = 0; i < nr_ctrs; ++i) { > - if (counter_config[i].enabled) { > - reset_value[i] = counter_config[i].count; > - > - CTR_WRITE(counter_config[i].count, msrs, i); > - > - CTRL_READ(msr_content, msrs, i); > - CTRL_CLEAR(msr_content); > - CTRL_SET_ENABLE(msr_content); > - CTRL_SET_USR(msr_content, counter_config[i].user); > - CTRL_SET_KERN(msr_content, counter_config[i].kernel); > - CTRL_SET_UM(msr_content, counter_config[i].unit_mask); > - CTRL_SET_EVENT(msr_content, counter_config[i].event); > - CTRL_SET_HOST_ONLY(msr_content, 0); > - CTRL_SET_GUEST_ONLY(msr_content, 0); > - CTRL_WRITE(msr_content, msrs, i); > - } else { > - reset_value[i] = 0; > - } > - } > -} > - > -static inline void > -ibs_log_event(u64 data, struct cpu_user_regs const * const regs, int mode) > -{ > - struct vcpu *v = current; > - u32 temp = 0; > - > - temp = data & 0xFFFFFFFF; > - xenoprof_log_event(v, regs, temp, mode, 0); > - > - temp = (data >> 32) & 0xFFFFFFFF; > - xenoprof_log_event(v, regs, temp, mode, 0); > - > -} > - > -static inline int handle_ibs(int mode, struct cpu_user_regs const * const regs) > -{ > - u64 val, ctl; > - struct vcpu *v = current; > - > - if (!ibs_caps) > - return 1; > - > - if (ibs_config.fetch_enabled) { > - rdmsrl(MSR_AMD64_IBSFETCHCTL, ctl); > - if (ctl & IBS_FETCH_VAL) { > - rdmsrl(MSR_AMD64_IBSFETCHLINAD, val); > - xenoprof_log_event(v, regs, IBS_FETCH_CODE, mode, 0); > - xenoprof_log_event(v, regs, val, mode, 0); > - > - ibs_log_event(val, regs, mode); > - ibs_log_event(ctl, regs, mode); > - > - rdmsrl(MSR_AMD64_IBSFETCHPHYSAD, val); > - ibs_log_event(val, regs, mode); > - > - /* reenable the IRQ */ > - ctl &= ~(IBS_FETCH_VAL | IBS_FETCH_CNT); > - ctl |= IBS_FETCH_ENABLE; > - wrmsrl(MSR_AMD64_IBSFETCHCTL, ctl); > - } > - } > - > - if (ibs_config.op_enabled) { > - rdmsrl(MSR_AMD64_IBSOPCTL, ctl); > - if (ctl & IBS_OP_VAL) { > - > - rdmsrl(MSR_AMD64_IBSOPRIP, val); > - xenoprof_log_event(v, regs, IBS_OP_CODE, mode, 0); > - xenoprof_log_event(v, regs, val, mode, 0); > - > - ibs_log_event(val, regs, mode); > - > - rdmsrl(MSR_AMD64_IBSOPDATA, val); > - ibs_log_event(val, regs, mode); > - rdmsrl(MSR_AMD64_IBSOPDATA2, val); > - ibs_log_event(val, regs, mode); > - rdmsrl(MSR_AMD64_IBSOPDATA3, val); > - ibs_log_event(val, regs, mode); > - rdmsrl(MSR_AMD64_IBSDCLINAD, val); > - ibs_log_event(val, regs, mode); > - rdmsrl(MSR_AMD64_IBSDCPHYSAD, val); > - ibs_log_event(val, regs, mode); > - > - /* reenable the IRQ */ > - ctl = op_amd_randomize_ibs_op(ibs_op_ctl); > - wrmsrl(MSR_AMD64_IBSOPCTL, ctl); > - } > - } > - > - return 1; > -} > - > -static int cf_check athlon_check_ctrs( > - unsigned int const cpu, struct op_msrs const * const msrs, > - struct cpu_user_regs const * const regs) > - > -{ > - uint64_t msr_content; > - int i; > - unsigned long eip = regs->rip; > - int mode = 0; > - struct vcpu *v = current; > - unsigned int const nr_ctrs = model->num_counters; > - > -#ifdef CONFIG_AMD_SVM > - struct cpu_user_regs *guest_regs = guest_cpu_user_regs(); > - > - if (!guest_mode(regs) && > - (eip == (unsigned long)svm_stgi_label)) { > - /* SVM guest was running when NMI occurred */ > - ASSERT(is_hvm_vcpu(v)); > - eip = guest_regs->rip; > - mode = xenoprofile_get_mode(v, guest_regs); > - } else > -#endif > - mode = xenoprofile_get_mode(v, regs); > - > - for (i = 0 ; i < nr_ctrs; ++i) { > - CTR_READ(msr_content, msrs, i); > - if (CTR_OVERFLOWED(msr_content)) { > - xenoprof_log_event(current, regs, eip, mode, i); > - CTR_WRITE(reset_value[i], msrs, i); > - } > - } > - > - /* See op_model_ppro.c */ > - return handle_ibs(mode, regs); > -} > - > -static inline void start_ibs(void) > -{ > - u64 val = 0; > - > - if (!ibs_caps) > - return; > - > - if (ibs_config.fetch_enabled) { > - val = (ibs_config.max_cnt_fetch >> 4) & IBS_FETCH_MAX_CNT; > - val |= ibs_config.rand_en ? IBS_FETCH_RAND_EN : 0; > - val |= IBS_FETCH_ENABLE; > - wrmsrl(MSR_AMD64_IBSFETCHCTL, val); > - } > - > - if (ibs_config.op_enabled) { > - ibs_op_ctl = ibs_config.max_cnt_op >> 4; > - if (!(ibs_caps & IBS_CAPS_RDWROPCNT)) { > - /* > - * IbsOpCurCnt not supported. See > - * op_amd_randomize_ibs_op() for details. > - */ > - ibs_op_ctl = clamp((unsigned long long)ibs_op_ctl, > - 0x0081ULL, 0xFF80ULL); > - } else { > - /* > - * The start value is randomized with a > - * positive offset, we need to compensate it > - * with the half of the randomized range. Also > - * avoid underflows. > - */ > - ibs_op_ctl = min(ibs_op_ctl + IBS_RANDOM_MAXCNT_OFFSET, > - IBS_OP_MAX_CNT); > - } > - if (ibs_caps & IBS_CAPS_OPCNT && ibs_config.dispatched_ops) > - ibs_op_ctl |= IBS_OP_CNT_CTL; > - ibs_op_ctl |= IBS_OP_ENABLE; > - val = op_amd_randomize_ibs_op(ibs_op_ctl); > - wrmsrl(MSR_AMD64_IBSOPCTL, val); > - } > -} > - > -static void cf_check athlon_start(struct op_msrs const * const msrs) > -{ > - uint64_t msr_content; > - int i; > - unsigned int const nr_ctrs = model->num_counters; > - for (i = 0 ; i < nr_ctrs ; ++i) { > - if (reset_value[i]) { > - CTRL_READ(msr_content, msrs, i); > - CTRL_SET_ACTIVE(msr_content); > - CTRL_WRITE(msr_content, msrs, i); > - } > - } > - start_ibs(); > -} > - > -static void stop_ibs(void) > -{ > - if (!ibs_caps) > - return; > - > - if (ibs_config.fetch_enabled) > - /* clear max count and enable */ > - wrmsrl(MSR_AMD64_IBSFETCHCTL, 0); > - > - if (ibs_config.op_enabled) > - /* clear max count and enable */ > - wrmsrl(MSR_AMD64_IBSOPCTL, 0); > -} > - > -static void cf_check athlon_stop(struct op_msrs const * const msrs) > -{ > - uint64_t msr_content; > - int i; > - unsigned int const nr_ctrs = model->num_counters; > - > - /* Subtle: stop on all counters to avoid race with > - * setting our pm callback */ > - for (i = 0 ; i < nr_ctrs ; ++i) { > - CTRL_READ(msr_content, msrs, i); > - CTRL_SET_INACTIVE(msr_content); > - CTRL_WRITE(msr_content, msrs, i); > - } > - > - stop_ibs(); > -} > - > -#define IBSCTL_LVTOFFSETVAL (1 << 8) > -#define APIC_EILVT_MSG_NMI 0x4 > -#define APIC_EILVT_LVTOFF_IBS 1 > -#define APIC_EILVTn(n) (0x500 + 0x10 * n) > -static inline void __init cf_check init_ibs_nmi_per_cpu(void *arg) > -{ > - unsigned long reg; > - > - reg = (APIC_EILVT_LVTOFF_IBS << 4) + APIC_EILVTn(0); > - apic_write(reg, APIC_EILVT_MSG_NMI << 8); > -} > - > -#define PCI_DEVICE_ID_AMD_10H_NB_MISC 0x1203 > -#define IBSCTL 0x1cc > -static int __init init_ibs_nmi(void) > -{ > - int bus, dev, func; > - u32 id, value; > - u16 vendor_id, dev_id; > - int nodes; > - > - /* per CPU setup */ > - on_each_cpu(init_ibs_nmi_per_cpu, NULL, 1); > - > - nodes = 0; > - for (bus = 0; bus < 256; bus++) { > - for (dev = 0; dev < 32; dev++) { > - for (func = 0; func < 8; func++) { > - id = pci_conf_read32(PCI_SBDF(0, bus, dev, func), > - PCI_VENDOR_ID); > - > - vendor_id = id & 0xffff; > - dev_id = (id >> 16) & 0xffff; > - > - if ((vendor_id == PCI_VENDOR_ID_AMD) && > - (dev_id == PCI_DEVICE_ID_AMD_10H_NB_MISC)) { > - > - pci_conf_write32( > - PCI_SBDF(0, bus, dev, func), > - IBSCTL, > - IBSCTL_LVTOFFSETVAL | APIC_EILVT_LVTOFF_IBS); > - > - value = pci_conf_read32(PCI_SBDF(0, bus, dev, func), > - IBSCTL); > - > - if (value != (IBSCTL_LVTOFFSETVAL | > - APIC_EILVT_LVTOFF_IBS)) { > - printk("Xenoprofile: Failed to setup IBS LVT offset, " > - "IBSCTL = %#x\n", value); > - return 1; > - } > - nodes++; > - } > - } > - } > - } > - > - if (!nodes) { > - printk("Xenoprofile: No CPU node configured for IBS\n"); > - return 1; > - } > - > - return 0; > -} > - > -static void __init get_ibs_caps(void) > -{ > - if (!boot_cpu_has(X86_FEATURE_IBS)) > - return; > - > - /* check IBS cpuid feature flags */ > - if (current_cpu_data.extended_cpuid_level >= IBS_CPUID_FEATURES) > - ibs_caps = cpuid_eax(IBS_CPUID_FEATURES); > - if (!(ibs_caps & IBS_CAPS_AVAIL)) > - /* cpuid flags not valid */ > - ibs_caps = 0; > -} > - > -void __init ibs_init(void) > -{ > - get_ibs_caps(); > - > - if ( !ibs_caps ) > - return; > - > - if (init_ibs_nmi()) { > - ibs_caps = 0; > - return; > - } > - > - printk("Xenoprofile: AMD IBS detected (%#x)\n", > - (unsigned)ibs_caps); > -} > - > -struct op_x86_model_spec const op_athlon_spec = { > - .num_counters = K7_NUM_COUNTERS, > - .num_controls = K7_NUM_CONTROLS, > - .fill_in_addresses = &athlon_fill_in_addresses, > - .setup_ctrs = &athlon_setup_ctrs, > - .check_ctrs = &athlon_check_ctrs, > - .start = &athlon_start, > - .stop = &athlon_stop > -}; > - > -struct op_x86_model_spec const op_amd_fam15h_spec = { > - .num_counters = FAM15H_NUM_COUNTERS, > - .num_controls = FAM15H_NUM_CONTROLS, > - .fill_in_addresses = &fam15h_fill_in_addresses, > - .setup_ctrs = &athlon_setup_ctrs, > - .check_ctrs = &athlon_check_ctrs, > - .start = &athlon_start, > - .stop = &athlon_stop > -}; > diff --git a/xen/arch/x86/oprofile/op_model_p4.c b/xen/arch/x86/oprofile/op_model_p4.c > deleted file mode 100644 > index d047258644db..000000000000 > --- a/xen/arch/x86/oprofile/op_model_p4.c > +++ /dev/null > @@ -1,721 +0,0 @@ > -/** > - * @file op_model_p4.c > - * P4 model-specific MSR operations > - * > - * @remark Copyright 2002 OProfile authors > - * @remark Read the file COPYING > - * > - * @author Graydon Hoare > - */ > - > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > - > -#include "op_x86_model.h" > -#include "op_counter.h" > - > -#define NUM_EVENTS 39 > - > -#define NUM_COUNTERS_NON_HT 8 > -#define NUM_ESCRS_NON_HT 45 > -#define NUM_CCCRS_NON_HT 18 > -#define NUM_CONTROLS_NON_HT (NUM_ESCRS_NON_HT + NUM_CCCRS_NON_HT) > - > -#define NUM_COUNTERS_HT2 4 > -#define NUM_ESCRS_HT2 23 > -#define NUM_CCCRS_HT2 9 > -#define NUM_CONTROLS_HT2 (NUM_ESCRS_HT2 + NUM_CCCRS_HT2) > - > -static unsigned int num_counters = NUM_COUNTERS_NON_HT; > - > - > -/* this has to be checked dynamically since the > - hyper-threadedness of a chip is discovered at > - kernel boot-time. */ > -static inline void setup_num_counters(void) > -{ > - if (boot_cpu_data.x86_num_siblings == 2) /* XXX */ > - num_counters = NUM_COUNTERS_HT2; > -} > - > -static int inline addr_increment(void) > -{ > - return boot_cpu_data.x86_num_siblings == 2 ? 2 : 1; > -} > - > - > -/* tables to simulate simplified hardware view of p4 registers */ > -struct p4_counter_binding { > - int virt_counter; > - int counter_address; > - int cccr_address; > -}; > - > -struct p4_event_binding { > - int escr_select; /* value to put in CCCR */ > - int event_select; /* value to put in ESCR */ > - struct { > - int virt_counter; /* for this counter... */ > - int escr_address; /* use this ESCR */ > - } bindings[2]; > -}; > - > -/* nb: these CTR_* defines are a duplicate of defines in > - event/i386.p4*events. */ > - > - > -#define CTR_BPU_0 (1 << 0) > -#define CTR_MS_0 (1 << 1) > -#define CTR_FLAME_0 (1 << 2) > -#define CTR_IQ_4 (1 << 3) > -#define CTR_BPU_2 (1 << 4) > -#define CTR_MS_2 (1 << 5) > -#define CTR_FLAME_2 (1 << 6) > -#define CTR_IQ_5 (1 << 7) > - > -static struct p4_counter_binding p4_counters [NUM_COUNTERS_NON_HT] = { > - { CTR_BPU_0, MSR_P4_BPU_PERFCTR0, MSR_P4_BPU_CCCR0 }, > - { CTR_MS_0, MSR_P4_MS_PERFCTR0, MSR_P4_MS_CCCR0 }, > - { CTR_FLAME_0, MSR_P4_FLAME_PERFCTR0, MSR_P4_FLAME_CCCR0 }, > - { CTR_IQ_4, MSR_P4_IQ_PERFCTR4, MSR_P4_IQ_CCCR4 }, > - { CTR_BPU_2, MSR_P4_BPU_PERFCTR2, MSR_P4_BPU_CCCR2 }, > - { CTR_MS_2, MSR_P4_MS_PERFCTR2, MSR_P4_MS_CCCR2 }, > - { CTR_FLAME_2, MSR_P4_FLAME_PERFCTR2, MSR_P4_FLAME_CCCR2 }, > - { CTR_IQ_5, MSR_P4_IQ_PERFCTR5, MSR_P4_IQ_CCCR5 } > -}; > - > -#define NUM_UNUSED_CCCRS NUM_CCCRS_NON_HT - NUM_COUNTERS_NON_HT > - > -/* All cccr we don't use. */ > -static int p4_unused_cccr[NUM_UNUSED_CCCRS] = { > - MSR_P4_BPU_CCCR1, MSR_P4_BPU_CCCR3, > - MSR_P4_MS_CCCR1, MSR_P4_MS_CCCR3, > - MSR_P4_FLAME_CCCR1, MSR_P4_FLAME_CCCR3, > - MSR_P4_IQ_CCCR0, MSR_P4_IQ_CCCR1, > - MSR_P4_IQ_CCCR2, MSR_P4_IQ_CCCR3 > -}; > - > -/* p4 event codes in libop/op_event.h are indices into this table. */ > - > -static const struct p4_event_binding p4_events[NUM_EVENTS] = { > - > - { /* BRANCH_RETIRED */ > - 0x05, 0x06, > - { {CTR_IQ_4, MSR_P4_CRU_ESCR2}, > - {CTR_IQ_5, MSR_P4_CRU_ESCR3} } > - }, > - > - { /* MISPRED_BRANCH_RETIRED */ > - 0x04, 0x03, > - { { CTR_IQ_4, MSR_P4_CRU_ESCR0}, > - { CTR_IQ_5, MSR_P4_CRU_ESCR1} } > - }, > - > - { /* TC_DELIVER_MODE */ > - 0x01, 0x01, > - { { CTR_MS_0, MSR_P4_TC_ESCR0}, > - { CTR_MS_2, MSR_P4_TC_ESCR1} } > - }, > - > - { /* BPU_FETCH_REQUEST */ > - 0x00, 0x03, > - { { CTR_BPU_0, MSR_P4_BPU_ESCR0}, > - { CTR_BPU_2, MSR_P4_BPU_ESCR1} } > - }, > - > - { /* ITLB_REFERENCE */ > - 0x03, 0x18, > - { { CTR_BPU_0, MSR_P4_ITLB_ESCR0}, > - { CTR_BPU_2, MSR_P4_ITLB_ESCR1} } > - }, > - > - { /* MEMORY_CANCEL */ > - 0x05, 0x02, > - { { CTR_FLAME_0, MSR_P4_DAC_ESCR0}, > - { CTR_FLAME_2, MSR_P4_DAC_ESCR1} } > - }, > - > - { /* MEMORY_COMPLETE */ > - 0x02, 0x08, > - { { CTR_FLAME_0, MSR_P4_SAAT_ESCR0}, > - { CTR_FLAME_2, MSR_P4_SAAT_ESCR1} } > - }, > - > - { /* LOAD_PORT_REPLAY */ > - 0x02, 0x04, > - { { CTR_FLAME_0, MSR_P4_SAAT_ESCR0}, > - { CTR_FLAME_2, MSR_P4_SAAT_ESCR1} } > - }, > - > - { /* STORE_PORT_REPLAY */ > - 0x02, 0x05, > - { { CTR_FLAME_0, MSR_P4_SAAT_ESCR0}, > - { CTR_FLAME_2, MSR_P4_SAAT_ESCR1} } > - }, > - > - { /* MOB_LOAD_REPLAY */ > - 0x02, 0x03, > - { { CTR_BPU_0, MSR_P4_MOB_ESCR0}, > - { CTR_BPU_2, MSR_P4_MOB_ESCR1} } > - }, > - > - { /* PAGE_WALK_TYPE */ > - 0x04, 0x01, > - { { CTR_BPU_0, MSR_P4_PMH_ESCR0}, > - { CTR_BPU_2, MSR_P4_PMH_ESCR1} } > - }, > - > - { /* BSQ_CACHE_REFERENCE */ > - 0x07, 0x0c, > - { { CTR_BPU_0, MSR_P4_BSU_ESCR0}, > - { CTR_BPU_2, MSR_P4_BSU_ESCR1} } > - }, > - > - { /* IOQ_ALLOCATION */ > - 0x06, 0x03, > - { { CTR_BPU_0, MSR_P4_FSB_ESCR0}, > - { 0, 0 } } > - }, > - > - { /* IOQ_ACTIVE_ENTRIES */ > - 0x06, 0x1a, > - { { CTR_BPU_2, MSR_P4_FSB_ESCR1}, > - { 0, 0 } } > - }, > - > - { /* FSB_DATA_ACTIVITY */ > - 0x06, 0x17, > - { { CTR_BPU_0, MSR_P4_FSB_ESCR0}, > - { CTR_BPU_2, MSR_P4_FSB_ESCR1} } > - }, > - > - { /* BSQ_ALLOCATION */ > - 0x07, 0x05, > - { { CTR_BPU_0, MSR_P4_BSU_ESCR0}, > - { 0, 0 } } > - }, > - > - { /* BSQ_ACTIVE_ENTRIES */ > - 0x07, 0x06, > - { { CTR_BPU_2, MSR_P4_BSU_ESCR1 /* guess */}, > - { 0, 0 } } > - }, > - > - { /* X87_ASSIST */ > - 0x05, 0x03, > - { { CTR_IQ_4, MSR_P4_CRU_ESCR2}, > - { CTR_IQ_5, MSR_P4_CRU_ESCR3} } > - }, > - > - { /* SSE_INPUT_ASSIST */ > - 0x01, 0x34, > - { { CTR_FLAME_0, MSR_P4_FIRM_ESCR0}, > - { CTR_FLAME_2, MSR_P4_FIRM_ESCR1} } > - }, > - > - { /* PACKED_SP_UOP */ > - 0x01, 0x08, > - { { CTR_FLAME_0, MSR_P4_FIRM_ESCR0}, > - { CTR_FLAME_2, MSR_P4_FIRM_ESCR1} } > - }, > - > - { /* PACKED_DP_UOP */ > - 0x01, 0x0c, > - { { CTR_FLAME_0, MSR_P4_FIRM_ESCR0}, > - { CTR_FLAME_2, MSR_P4_FIRM_ESCR1} } > - }, > - > - { /* SCALAR_SP_UOP */ > - 0x01, 0x0a, > - { { CTR_FLAME_0, MSR_P4_FIRM_ESCR0}, > - { CTR_FLAME_2, MSR_P4_FIRM_ESCR1} } > - }, > - > - { /* SCALAR_DP_UOP */ > - 0x01, 0x0e, > - { { CTR_FLAME_0, MSR_P4_FIRM_ESCR0}, > - { CTR_FLAME_2, MSR_P4_FIRM_ESCR1} } > - }, > - > - { /* 64BIT_MMX_UOP */ > - 0x01, 0x02, > - { { CTR_FLAME_0, MSR_P4_FIRM_ESCR0}, > - { CTR_FLAME_2, MSR_P4_FIRM_ESCR1} } > - }, > - > - { /* 128BIT_MMX_UOP */ > - 0x01, 0x1a, > - { { CTR_FLAME_0, MSR_P4_FIRM_ESCR0}, > - { CTR_FLAME_2, MSR_P4_FIRM_ESCR1} } > - }, > - > - { /* X87_FP_UOP */ > - 0x01, 0x04, > - { { CTR_FLAME_0, MSR_P4_FIRM_ESCR0}, > - { CTR_FLAME_2, MSR_P4_FIRM_ESCR1} } > - }, > - > - { /* X87_SIMD_MOVES_UOP */ > - 0x01, 0x2e, > - { { CTR_FLAME_0, MSR_P4_FIRM_ESCR0}, > - { CTR_FLAME_2, MSR_P4_FIRM_ESCR1} } > - }, > - > - { /* MACHINE_CLEAR */ > - 0x05, 0x02, > - { { CTR_IQ_4, MSR_P4_CRU_ESCR2}, > - { CTR_IQ_5, MSR_P4_CRU_ESCR3} } > - }, > - > - { /* GLOBAL_POWER_EVENTS */ > - 0x06, 0x13 /* older manual says 0x05, newer 0x13 */, > - { { CTR_BPU_0, MSR_P4_FSB_ESCR0}, > - { CTR_BPU_2, MSR_P4_FSB_ESCR1} } > - }, > - > - { /* TC_MS_XFER */ > - 0x00, 0x05, > - { { CTR_MS_0, MSR_P4_MS_ESCR0}, > - { CTR_MS_2, MSR_P4_MS_ESCR1} } > - }, > - > - { /* UOP_QUEUE_WRITES */ > - 0x00, 0x09, > - { { CTR_MS_0, MSR_P4_MS_ESCR0}, > - { CTR_MS_2, MSR_P4_MS_ESCR1} } > - }, > - > - { /* FRONT_END_EVENT */ > - 0x05, 0x08, > - { { CTR_IQ_4, MSR_P4_CRU_ESCR2}, > - { CTR_IQ_5, MSR_P4_CRU_ESCR3} } > - }, > - > - { /* EXECUTION_EVENT */ > - 0x05, 0x0c, > - { { CTR_IQ_4, MSR_P4_CRU_ESCR2}, > - { CTR_IQ_5, MSR_P4_CRU_ESCR3} } > - }, > - > - { /* REPLAY_EVENT */ > - 0x05, 0x09, > - { { CTR_IQ_4, MSR_P4_CRU_ESCR2}, > - { CTR_IQ_5, MSR_P4_CRU_ESCR3} } > - }, > - > - { /* INSTR_RETIRED */ > - 0x04, 0x02, > - { { CTR_IQ_4, MSR_P4_CRU_ESCR0}, > - { CTR_IQ_5, MSR_P4_CRU_ESCR1} } > - }, > - > - { /* UOPS_RETIRED */ > - 0x04, 0x01, > - { { CTR_IQ_4, MSR_P4_CRU_ESCR0}, > - { CTR_IQ_5, MSR_P4_CRU_ESCR1} } > - }, > - > - { /* UOP_TYPE */ > - 0x02, 0x02, > - { { CTR_IQ_4, MSR_P4_RAT_ESCR0}, > - { CTR_IQ_5, MSR_P4_RAT_ESCR1} } > - }, > - > - { /* RETIRED_MISPRED_BRANCH_TYPE */ > - 0x02, 0x05, > - { { CTR_MS_0, MSR_P4_TBPU_ESCR0}, > - { CTR_MS_2, MSR_P4_TBPU_ESCR1} } > - }, > - > - { /* RETIRED_BRANCH_TYPE */ > - 0x02, 0x04, > - { { CTR_MS_0, MSR_P4_TBPU_ESCR0}, > - { CTR_MS_2, MSR_P4_TBPU_ESCR1} } > - } > -}; > - > - > -#define MISC_PMC_ENABLED_P(x) ((x) & 1ULL << 7) > - > -#define ESCR_RESERVED_BITS 0x80000003ULL > -#define ESCR_CLEAR(escr) ((escr) &= ESCR_RESERVED_BITS) > -#define ESCR_SET_USR_0(escr, usr) ((escr) |= (((usr) & 1ULL) << 2)) > -#define ESCR_SET_OS_0(escr, os) ((escr) |= (((os) & 1ULL) << 3)) > -#define ESCR_SET_USR_1(escr, usr) ((escr) |= (((usr) & 1ULL))) > -#define ESCR_SET_OS_1(escr, os) ((escr) |= (((os) & 1ULL) << 1)) > -#define ESCR_SET_EVENT_SELECT(escr, sel) ((escr) |= (((sel) & 0x3fULL) << 25)) > -#define ESCR_SET_EVENT_MASK(escr, mask) ((escr) |= (((mask) & 0xffffULL) << 9)) > -#define ESCR_READ(escr,ev,i) do {rdmsrl(ev->bindings[(i)].escr_address, (escr));} while (0) > -#define ESCR_WRITE(escr,ev,i) do {wrmsrl(ev->bindings[(i)].escr_address, (escr));} while (0) > - > -#define CCCR_RESERVED_BITS 0x38030FFFULL > -#define CCCR_CLEAR(cccr) ((cccr) &= CCCR_RESERVED_BITS) > -#define CCCR_SET_REQUIRED_BITS(cccr) ((cccr) |= 0x00030000ULL) > -#define CCCR_SET_ESCR_SELECT(cccr, sel) ((cccr) |= (((sel) & 0x07ULL) << 13)) > -#define CCCR_SET_PMI_OVF_0(cccr) ((cccr) |= (1ULL<<26)) > -#define CCCR_SET_PMI_OVF_1(cccr) ((cccr) |= (1ULL<<27)) > -#define CCCR_SET_ENABLE(cccr) ((cccr) |= (1ULL<<12)) > -#define CCCR_SET_DISABLE(cccr) ((cccr) &= ~(1ULL<<12)) > -#define CCCR_READ(msr_content, i) do {rdmsrl(p4_counters[(i)].cccr_address, (msr_content));} while (0) > -#define CCCR_WRITE(msr_content, i) do {wrmsrl(p4_counters[(i)].cccr_address, (msr_content));} while (0) > -#define CCCR_OVF_P(cccr) ((cccr) & (1ULL<<31)) > -#define CCCR_CLEAR_OVF(cccr) ((cccr) &= (~(1ULL<<31))) > - > -#define CTR_READ(msr_content,i) do {rdmsrl(p4_counters[(i)].counter_address, (msr_content));} while (0) > -#define CTR_WRITE(msr_content,i) do {wrmsrl(p4_counters[(i)].counter_address, -(msr_content));} while (0) > -#define CTR_OVERFLOW_P(ctr) (!((ctr) & 0x80000000ULL)) > - > - > -/* this assigns a "stagger" to the current CPU, which is used throughout > - the code in this module as an extra array offset, to select the "even" > - or "odd" part of all the divided resources. */ > -static unsigned int get_stagger(void) > -{ > - int cpu = smp_processor_id(); > - return (cpu != cpumask_first(per_cpu(cpu_sibling_mask, cpu))); > -} > - > - > -/* finally, mediate access to a real hardware counter > - by passing a "virtual" counter numer to this macro, > - along with your stagger setting. */ > -#define VIRT_CTR(stagger, i) ((i) + ((num_counters) * (stagger))) > - > -static unsigned long reset_value[NUM_COUNTERS_NON_HT]; > - > - > -static void cf_check p4_fill_in_addresses(struct op_msrs * const msrs) > -{ > - unsigned int i; > - unsigned int addr, stag; > - > - setup_num_counters(); > - stag = get_stagger(); > - > - /* the counter registers we pay attention to */ > - for (i = 0; i < num_counters; ++i) { > - msrs->counters[i].addr = > - p4_counters[VIRT_CTR(stag, i)].counter_address; > - } > - > - /* FIXME: bad feeling, we don't save the 10 counters we don't use. */ > - > - /* 18 CCCR registers */ > - for (i = 0, addr = MSR_P4_BPU_CCCR0 + stag; > - addr <= MSR_P4_IQ_CCCR5; ++i, addr += addr_increment()) { > - msrs->controls[i].addr = addr; > - } > - > - /* 43 ESCR registers in three or four discontiguous group */ > - for (addr = MSR_P4_BSU_ESCR0 + stag; > - addr < MSR_P4_IQ_ESCR0; ++i, addr += addr_increment()) { > - msrs->controls[i].addr = addr; > - } > - > - /* no IQ_ESCR0/1 on some models, we save a seconde time BSU_ESCR0/1 > - * to avoid special case in nmi_{save|restore}_registers() */ > - if (boot_cpu_data.x86_model >= 0x3) { > - for (addr = MSR_P4_BSU_ESCR0 + stag; > - addr <= MSR_P4_BSU_ESCR1; ++i, addr += addr_increment()) { > - msrs->controls[i].addr = addr; > - } > - } else { > - for (addr = MSR_P4_IQ_ESCR0 + stag; > - addr <= MSR_P4_IQ_ESCR1; ++i, addr += addr_increment()) { > - msrs->controls[i].addr = addr; > - } > - } > - > - for (addr = MSR_P4_RAT_ESCR0 + stag; > - addr <= MSR_P4_SSU_ESCR0; ++i, addr += addr_increment()) { > - msrs->controls[i].addr = addr; > - } > - > - for (addr = MSR_P4_MS_ESCR0 + stag; > - addr <= MSR_P4_TC_ESCR1; ++i, addr += addr_increment()) { > - msrs->controls[i].addr = addr; > - } > - > - for (addr = MSR_P4_IX_ESCR0 + stag; > - addr <= MSR_P4_CRU_ESCR3; ++i, addr += addr_increment()) { > - msrs->controls[i].addr = addr; > - } > - > - /* there are 2 remaining non-contiguously located ESCRs */ > - > - if (num_counters == NUM_COUNTERS_NON_HT) { > - /* standard non-HT CPUs handle both remaining ESCRs*/ > - msrs->controls[i++].addr = MSR_P4_CRU_ESCR5; > - msrs->controls[i++].addr = MSR_P4_CRU_ESCR4; > - > - } else if (stag == 0) { > - /* HT CPUs give the first remainder to the even thread, as > - the 32nd control register */ > - msrs->controls[i++].addr = MSR_P4_CRU_ESCR4; > - > - } else { > - /* and two copies of the second to the odd thread, > - for the 22st and 23nd control registers */ > - msrs->controls[i++].addr = MSR_P4_CRU_ESCR5; > - msrs->controls[i++].addr = MSR_P4_CRU_ESCR5; > - } > -} > - > - > -static void pmc_setup_one_p4_counter(unsigned int ctr) > -{ > - int i; > - int const maxbind = 2; > - uint64_t cccr = 0; > - uint64_t escr = 0; > - unsigned int counter_bit; > - const struct p4_event_binding *ev = NULL; > - unsigned int stag; > - > - stag = get_stagger(); > - > - /* convert from counter *number* to counter *bit* */ > - counter_bit = 1 << VIRT_CTR(stag, ctr); > - > - /* find our event binding structure. */ > - if (counter_config[ctr].event <= 0 || counter_config[ctr].event > NUM_EVENTS) { > - printk(KERN_ERR "oprofile: P4 event code %#lx out of range\n", > - counter_config[ctr].event); > - return; > - } > - > - ev = &(p4_events[counter_config[ctr].event - 1]); > - > - for (i = 0; i < maxbind; i++) { > - if (ev->bindings[i].virt_counter & counter_bit) { > - > - /* modify ESCR */ > - ESCR_READ(escr, ev, i); > - ESCR_CLEAR(escr); > - if (stag == 0) { > - ESCR_SET_USR_0(escr, counter_config[ctr].user); > - ESCR_SET_OS_0(escr, counter_config[ctr].kernel); > - } else { > - ESCR_SET_USR_1(escr, counter_config[ctr].user); > - ESCR_SET_OS_1(escr, counter_config[ctr].kernel); > - } > - ESCR_SET_EVENT_SELECT(escr, ev->event_select); > - ESCR_SET_EVENT_MASK(escr, counter_config[ctr].unit_mask); > - ESCR_WRITE(escr, ev, i); > - > - /* modify CCCR */ > - CCCR_READ(cccr, VIRT_CTR(stag, ctr)); > - CCCR_CLEAR(cccr); > - CCCR_SET_REQUIRED_BITS(cccr); > - CCCR_SET_ESCR_SELECT(cccr, ev->escr_select); > - if (stag == 0) { > - CCCR_SET_PMI_OVF_0(cccr); > - } else { > - CCCR_SET_PMI_OVF_1(cccr); > - } > - CCCR_WRITE(cccr, VIRT_CTR(stag, ctr)); > - return; > - } > - } > - > - printk(KERN_ERR > - "oprofile: P4 event code %#lx no binding, stag %d ctr %d\n", > - counter_config[ctr].event, stag, ctr); > -} > - > - > -static void cf_check p4_setup_ctrs(struct op_msrs const * const msrs) > -{ > - unsigned int i; > - uint64_t msr_content; > - unsigned int addr; > - unsigned int stag; > - > - stag = get_stagger(); > - > - rdmsrl(MSR_IA32_MISC_ENABLE, msr_content); > - if (! MISC_PMC_ENABLED_P(msr_content)) { > - printk(KERN_ERR "oprofile: P4 PMC not available\n"); > - return; > - } > - > - /* clear the cccrs we will use */ > - for (i = 0 ; i < num_counters ; i++) { > - rdmsrl(p4_counters[VIRT_CTR(stag, i)].cccr_address, msr_content); > - CCCR_CLEAR(msr_content); > - CCCR_SET_REQUIRED_BITS(msr_content); > - wrmsrl(p4_counters[VIRT_CTR(stag, i)].cccr_address, msr_content); > - } > - > - /* clear cccrs outside our concern */ > - for (i = stag ; i < NUM_UNUSED_CCCRS ; i += addr_increment()) { > - rdmsrl(p4_unused_cccr[i], msr_content); > - CCCR_CLEAR(msr_content); > - CCCR_SET_REQUIRED_BITS(msr_content); > - wrmsrl(p4_unused_cccr[i], msr_content); > - } > - > - /* clear all escrs (including those outside our concern) */ > - for (addr = MSR_P4_BSU_ESCR0 + stag; > - addr < MSR_P4_IQ_ESCR0; addr += addr_increment()) { > - wrmsrl(addr, 0x0ULL); > - } > - > - /* On older models clear also MSR_P4_IQ_ESCR0/1 */ > - if (boot_cpu_data.x86_model < 0x3) { > - wrmsrl(MSR_P4_IQ_ESCR0, 0x0ULL); > - wrmsrl(MSR_P4_IQ_ESCR1, 0x0ULL); > - } > - > - for (addr = MSR_P4_RAT_ESCR0 + stag; > - addr <= MSR_P4_SSU_ESCR0; ++i, addr += addr_increment()) { > - wrmsrl(addr, 0x0ULL); > - } > - > - for (addr = MSR_P4_MS_ESCR0 + stag; > - addr <= MSR_P4_TC_ESCR1; addr += addr_increment()){ > - wrmsrl(addr, 0x0ULL); > - } > - > - for (addr = MSR_P4_IX_ESCR0 + stag; > - addr <= MSR_P4_CRU_ESCR3; addr += addr_increment()){ > - wrmsrl(addr, 0x0ULL); > - } > - > - if (num_counters == NUM_COUNTERS_NON_HT) { > - wrmsrl(MSR_P4_CRU_ESCR4, 0x0ULL); > - wrmsrl(MSR_P4_CRU_ESCR5, 0x0ULL); > - } else if (stag == 0) { > - wrmsrl(MSR_P4_CRU_ESCR4, 0x0ULL); > - } else { > - wrmsrl(MSR_P4_CRU_ESCR5, 0x0ULL); > - } > - > - /* setup all counters */ > - for (i = 0 ; i < num_counters ; ++i) { > - if (counter_config[i].enabled) { > - reset_value[i] = counter_config[i].count; > - pmc_setup_one_p4_counter(i); > - CTR_WRITE(counter_config[i].count, VIRT_CTR(stag, i)); > - } else { > - reset_value[i] = 0; > - } > - } > -} > - > -static int cf_check p4_check_ctrs( > - unsigned int const cpu, struct op_msrs const * const msrs, > - struct cpu_user_regs const * const regs) > -{ > - unsigned long ctr, stag, real; > - uint64_t msr_content; > - int i; > - int ovf = 0; > - unsigned long eip = regs->rip; > - int mode = xenoprofile_get_mode(current, regs); > - > - stag = get_stagger(); > - > - for (i = 0; i < num_counters; ++i) { > - > - if (!reset_value[i]) > - continue; > - > - /* > - * there is some eccentricity in the hardware which > - * requires that we perform 2 extra corrections: > - * > - * - check both the CCCR:OVF flag for overflow and the > - * counter high bit for un-flagged overflows. > - * > - * - write the counter back twice to ensure it gets > - * updated properly. > - * > - * the former seems to be related to extra NMIs happening > - * during the current NMI; the latter is reported as errata > - * N15 in intel doc 249199-029, pentium 4 specification > - * update, though their suggested work-around does not > - * appear to solve the problem. > - */ > - > - real = VIRT_CTR(stag, i); > - > - CCCR_READ(msr_content, real); > - CTR_READ(ctr, real); > - if (CCCR_OVF_P(msr_content) || CTR_OVERFLOW_P(ctr)) { > - xenoprof_log_event(current, regs, eip, mode, i); > - CTR_WRITE(reset_value[i], real); > - CCCR_CLEAR_OVF(msr_content); > - CCCR_WRITE(msr_content, real); > - CTR_WRITE(reset_value[i], real); > - ovf = 1; > - } > - } > - > - /* P4 quirk: you have to re-unmask the apic vector */ > - apic_write(APIC_LVTPC, apic_read(APIC_LVTPC) & ~APIC_LVT_MASKED); > - > - return ovf; > -} > - > - > -static void cf_check p4_start(struct op_msrs const * const msrs) > -{ > - unsigned int stag; > - uint64_t msr_content; > - int i; > - > - stag = get_stagger(); > - > - for (i = 0; i < num_counters; ++i) { > - if (!reset_value[i]) > - continue; > - CCCR_READ(msr_content, VIRT_CTR(stag, i)); > - CCCR_SET_ENABLE(msr_content); > - CCCR_WRITE(msr_content, VIRT_CTR(stag, i)); > - } > -} > - > - > -static void cf_check p4_stop(struct op_msrs const * const msrs) > -{ > - unsigned int stag; > - uint64_t msr_content; > - int i; > - > - stag = get_stagger(); > - > - for (i = 0; i < num_counters; ++i) { > - CCCR_READ(msr_content, VIRT_CTR(stag, i)); > - CCCR_SET_DISABLE(msr_content); > - CCCR_WRITE(msr_content, VIRT_CTR(stag, i)); > - } > -} > - > - > -struct op_x86_model_spec const op_p4_ht2_spec = { > - .num_counters = NUM_COUNTERS_HT2, > - .num_controls = NUM_CONTROLS_HT2, > - .fill_in_addresses = &p4_fill_in_addresses, > - .setup_ctrs = &p4_setup_ctrs, > - .check_ctrs = &p4_check_ctrs, > - .start = &p4_start, > - .stop = &p4_stop > -}; > - > - > -struct op_x86_model_spec const op_p4_spec = { > - .num_counters = NUM_COUNTERS_NON_HT, > - .num_controls = NUM_CONTROLS_NON_HT, > - .fill_in_addresses = &p4_fill_in_addresses, > - .setup_ctrs = &p4_setup_ctrs, > - .check_ctrs = &p4_check_ctrs, > - .start = &p4_start, > - .stop = &p4_stop > -}; > diff --git a/xen/arch/x86/oprofile/op_model_ppro.c b/xen/arch/x86/oprofile/op_model_ppro.c > deleted file mode 100644 > index 4bbb4502c7da..000000000000 > --- a/xen/arch/x86/oprofile/op_model_ppro.c > +++ /dev/null > @@ -1,348 +0,0 @@ > -/** > - * @file op_model_ppro.h > - * pentium pro / P6 model-specific MSR operations > - * > - * @remark Copyright 2002 OProfile authors > - * @remark Read the file COPYING > - * > - * @author John Levon > - * @author Philippe Elie > - * @author Graydon Hoare > - */ > - > -#include > -#include > -#include > -#include > - > -#include > -#include > -#include > -#include > -#include > -#include > -#include > - > -#include "op_x86_model.h" > -#include "op_counter.h" > - > -struct arch_msr_pair { > - u64 counter; > - u64 control; > -}; > - > -/* > - * Intel "Architectural Performance Monitoring" CPUID > - * detection/enumeration details: > - */ > -union cpuid10_eax { > - struct { > - unsigned int version_id:8; > - unsigned int num_counters:8; > - unsigned int bit_width:8; > - unsigned int mask_length:8; > - } split; > - unsigned int full; > -}; > - > -static int num_counters = 2; > -static int counter_width = 32; > - > -#define CTR_OVERFLOWED(n) (!((n) & (1ULL<<(counter_width-1)))) > - > -#define CTRL_READ(msr_content,msrs,c) do {rdmsrl((msrs->controls[(c)].addr), (msr_content));} while (0) > -#define CTRL_WRITE(msr_content,msrs,c) do {wrmsrl((msrs->controls[(c)].addr), (msr_content));} while (0) > -#define CTRL_SET_ACTIVE(n) (n |= (1ULL<<22)) > -#define CTRL_SET_INACTIVE(n) (n &= ~(1ULL<<22)) > -#define CTRL_CLEAR(x) (x &= (1ULL<<21)) > -#define CTRL_SET_ENABLE(val) (val |= 1ULL<<20) > -#define CTRL_SET_USR(val,u) (val |= ((u & 1ULL) << 16)) > -#define CTRL_SET_KERN(val,k) (val |= ((k & 1ULL) << 17)) > -#define CTRL_SET_UM(val, m) (val |= (m << 8)) > -#define CTRL_SET_EVENT(val, e) (val |= e) > -#define IS_ACTIVE(val) (val & (1ULL << 22) ) > -#define IS_ENABLE(val) (val & (1ULL << 20) ) > -static unsigned long reset_value[OP_MAX_COUNTER]; > -int ppro_has_global_ctrl = 0; > - > -static void cf_check ppro_fill_in_addresses(struct op_msrs * const msrs) > -{ > - int i; > - > - for (i = 0; i < num_counters; i++) > - msrs->counters[i].addr = MSR_P6_PERFCTR(i); > - for (i = 0; i < num_counters; i++) > - msrs->controls[i].addr = MSR_P6_EVNTSEL(i); > -} > - > - > -static void cf_check ppro_setup_ctrs(struct op_msrs const * const msrs) > -{ > - uint64_t msr_content; > - int i; > - > - if (cpu_has_arch_perfmon) { > - union cpuid10_eax eax; > - eax.full = cpuid_eax(0xa); > - > - /* > - * For Core2 (family 6, model 15), don't reset the > - * counter width: > - */ > - if (!(eax.split.version_id == 0 && > - current_cpu_data.x86 == 6 && > - current_cpu_data.x86_model == 15)) { > - > - if (counter_width < eax.split.bit_width) > - counter_width = eax.split.bit_width; > - } > - } > - > - /* clear all counters */ > - for (i = 0 ; i < num_counters; ++i) { > - CTRL_READ(msr_content, msrs, i); > - CTRL_CLEAR(msr_content); > - CTRL_WRITE(msr_content, msrs, i); > - } > - > - /* avoid a false detection of ctr overflows in NMI handler */ > - for (i = 0; i < num_counters; ++i) > - wrmsrl(msrs->counters[i].addr, ~0x0ULL); > - > - /* enable active counters */ > - for (i = 0; i < num_counters; ++i) { > - if (counter_config[i].enabled) { > - reset_value[i] = counter_config[i].count; > - > - wrmsrl(msrs->counters[i].addr, -reset_value[i]); > - > - CTRL_READ(msr_content, msrs, i); > - CTRL_CLEAR(msr_content); > - CTRL_SET_ENABLE(msr_content); > - CTRL_SET_USR(msr_content, counter_config[i].user); > - CTRL_SET_KERN(msr_content, counter_config[i].kernel); > - CTRL_SET_UM(msr_content, counter_config[i].unit_mask); > - CTRL_SET_EVENT(msr_content, counter_config[i].event); > - CTRL_WRITE(msr_content, msrs, i); > - } else { > - reset_value[i] = 0; > - } > - } > -} > - > -static int cf_check ppro_check_ctrs( > - unsigned int const cpu, struct op_msrs const * const msrs, > - struct cpu_user_regs const * const regs) > -{ > - u64 val; > - int i; > - int ovf = 0; > - unsigned long eip = regs->rip; > - int mode = xenoprofile_get_mode(current, regs); > - struct arch_msr_pair *msrs_content = vcpu_vpmu(current)->context; > - > - for (i = 0 ; i < num_counters; ++i) { > - if (!reset_value[i]) > - continue; > - rdmsrl(msrs->counters[i].addr, val); > - if (CTR_OVERFLOWED(val)) { > - xenoprof_log_event(current, regs, eip, mode, i); > - wrmsrl(msrs->counters[i].addr, -reset_value[i]); > - if ( is_passive(current->domain) && (mode != 2) && > - vpmu_is_set(vcpu_vpmu(current), > - VPMU_PASSIVE_DOMAIN_ALLOCATED) ) > - { > - if ( IS_ACTIVE(msrs_content[i].control) ) > - { > - msrs_content[i].counter = val; > - if ( IS_ENABLE(msrs_content[i].control) ) > - ovf = 2; > - } > - } > - if ( !ovf ) > - ovf = 1; > - } > - } > - > - /* Only P6 based Pentium M need to re-unmask the apic vector but it > - * doesn't hurt other P6 variant */ > - apic_write(APIC_LVTPC, apic_read(APIC_LVTPC) & ~APIC_LVT_MASKED); > - > - return ovf; > -} > - > - > -static void cf_check ppro_start(struct op_msrs const * const msrs) > -{ > - uint64_t msr_content; > - int i; > - > - for (i = 0; i < num_counters; ++i) { > - if (reset_value[i]) { > - CTRL_READ(msr_content, msrs, i); > - CTRL_SET_ACTIVE(msr_content); > - CTRL_WRITE(msr_content, msrs, i); > - } > - } > - /* Global Control MSR is enabled by default when system power on. > - * However, this may not hold true when xenoprof starts to run. > - */ > - if ( ppro_has_global_ctrl ) > - wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, (1ULL< -} > - > - > -static void cf_check ppro_stop(struct op_msrs const * const msrs) > -{ > - uint64_t msr_content; > - int i; > - > - for (i = 0; i < num_counters; ++i) { > - if (!reset_value[i]) > - continue; > - CTRL_READ(msr_content, msrs, i); > - CTRL_SET_INACTIVE(msr_content); > - CTRL_WRITE(msr_content, msrs, i); > - } > - if ( ppro_has_global_ctrl ) > - wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0x0ULL); > -} > - > -static int cf_check ppro_is_arch_pmu_msr(u64 msr_index, int *type, int *index) > -{ > - if ( (msr_index >= MSR_IA32_PERFCTR0) && > - (msr_index < (MSR_IA32_PERFCTR0 + num_counters)) ) > - { > - *type = MSR_TYPE_ARCH_COUNTER; > - *index = msr_index - MSR_IA32_PERFCTR0; > - return 1; > - } > - if ( (msr_index >= MSR_P6_EVNTSEL(0)) && > - (msr_index < (MSR_P6_EVNTSEL(num_counters))) ) > - { > - *type = MSR_TYPE_ARCH_CTRL; > - *index = msr_index - MSR_P6_EVNTSEL(0); > - return 1; > - } > - > - return 0; > -} > - > -static int cf_check ppro_allocate_msr(struct vcpu *v) > -{ > - struct vpmu_struct *vpmu = vcpu_vpmu(v); > - struct arch_msr_pair *msr_content; > - > - msr_content = xvzalloc_array(struct arch_msr_pair, num_counters); > - if ( !msr_content ) > - goto out; > - vpmu->context = (void *)msr_content; > - vpmu_clear(vpmu); > - vpmu_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED); > - return 1; > -out: > - printk(XENLOG_G_WARNING "Insufficient memory for oprofile," > - " oprofile is unavailable on dom%d vcpu%d\n", > - v->vcpu_id, v->domain->domain_id); > - return 0; > -} > - > -static void cf_check ppro_free_msr(struct vcpu *v) > -{ > - struct vpmu_struct *vpmu = vcpu_vpmu(v); > - > - if ( !vpmu_is_set(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED) ) > - return; > - XVFREE(vpmu->context); > - vpmu_reset(vpmu, VPMU_PASSIVE_DOMAIN_ALLOCATED); > -} > - > -static void cf_check ppro_load_msr( > - struct vcpu *v, int type, int index, u64 *msr_content) > -{ > - struct arch_msr_pair *msrs = vcpu_vpmu(v)->context; > - switch ( type ) > - { > - case MSR_TYPE_ARCH_COUNTER: > - *msr_content = msrs[index].counter; > - break; > - case MSR_TYPE_ARCH_CTRL: > - *msr_content = msrs[index].control; > - break; > - } > -} > - > -static void cf_check ppro_save_msr( > - struct vcpu *v, int type, int index, u64 msr_content) > -{ > - struct arch_msr_pair *msrs = vcpu_vpmu(v)->context; > - > - switch ( type ) > - { > - case MSR_TYPE_ARCH_COUNTER: > - msrs[index].counter = msr_content; > - break; > - case MSR_TYPE_ARCH_CTRL: > - msrs[index].control = msr_content; > - break; > - } > -} > - > -/* > - * Architectural performance monitoring. > - * > - * Newer Intel CPUs (Core1+) have support for architectural > - * events described in CPUID 0xA. See the IA32 SDM Vol3b.18 for details. > - * The advantage of this is that it can be done without knowing about > - * the specific CPU. > - */ > -void arch_perfmon_setup_counters(void) > -{ > - union cpuid10_eax eax; > - > - eax.full = cpuid_eax(0xa); > - > - /* Workaround for BIOS bugs in 6/15. Taken from perfmon2 */ > - if (eax.split.version_id == 0 && current_cpu_data.x86 == 6 && > - current_cpu_data.x86_model == 15) { > - eax.split.version_id = 2; > - eax.split.num_counters = 2; > - eax.split.bit_width = 40; > - } > - > - num_counters = min_t(u8, eax.split.num_counters, OP_MAX_COUNTER); > - > - op_arch_perfmon_spec.num_counters = num_counters; > - op_arch_perfmon_spec.num_controls = num_counters; > - op_ppro_spec.num_counters = num_counters; > - op_ppro_spec.num_controls = num_counters; > -} > - > -struct op_x86_model_spec __read_mostly op_ppro_spec = { > - .num_counters = 2, > - .num_controls = 2, > - .fill_in_addresses = &ppro_fill_in_addresses, > - .setup_ctrs = &ppro_setup_ctrs, > - .check_ctrs = &ppro_check_ctrs, > - .start = &ppro_start, > - .stop = &ppro_stop, > - .is_arch_pmu_msr = &ppro_is_arch_pmu_msr, > - .allocated_msr = &ppro_allocate_msr, > - .free_msr = &ppro_free_msr, > - .load_msr = &ppro_load_msr, > - .save_msr = &ppro_save_msr > -}; > - > -struct op_x86_model_spec __read_mostly op_arch_perfmon_spec = { > - /* num_counters/num_controls filled in at runtime */ > - .fill_in_addresses = &ppro_fill_in_addresses, > - .setup_ctrs = &ppro_setup_ctrs, > - .check_ctrs = &ppro_check_ctrs, > - .start = &ppro_start, > - .stop = &ppro_stop, > - .is_arch_pmu_msr = &ppro_is_arch_pmu_msr, > - .allocated_msr = &ppro_allocate_msr, > - .free_msr = &ppro_free_msr, > - .load_msr = &ppro_load_msr, > - .save_msr = &ppro_save_msr > -}; > diff --git a/xen/arch/x86/oprofile/op_x86_model.h b/xen/arch/x86/oprofile/op_x86_model.h > deleted file mode 100644 > index 35bc3c1e222c..000000000000 > --- a/xen/arch/x86/oprofile/op_x86_model.h > +++ /dev/null > @@ -1,58 +0,0 @@ > -/** > - * @file op_x86_model.h > - * interface to x86 model-specific MSR operations > - * > - * @remark Copyright 2002 OProfile authors > - * @remark Read the file COPYING > - * > - * @author Graydon Hoare > - */ > - > -#ifndef OP_X86_MODEL_H > -#define OP_X86_MODEL_H > - > -struct op_msr { > - unsigned long addr; > - uint64_t value; > -}; > - > -struct op_msrs { > - struct op_msr * counters; > - struct op_msr * controls; > -}; > - > -struct pt_regs; > - > -/* The model vtable abstracts the differences between > - * various x86 CPU model's perfctr support. > - */ > -struct op_x86_model_spec { > - unsigned int num_counters; > - unsigned int num_controls; > - void (*fill_in_addresses)(struct op_msrs * const msrs); > - void (*setup_ctrs)(struct op_msrs const * const msrs); > - int (*check_ctrs)(unsigned int const cpu, > - struct op_msrs const * const msrs, > - struct cpu_user_regs const * const regs); > - void (*start)(struct op_msrs const * const msrs); > - void (*stop)(struct op_msrs const * const msrs); > - int (*is_arch_pmu_msr)(u64 msr_index, int *type, int *index); > - int (*allocated_msr)(struct vcpu *v); > - void (*free_msr)(struct vcpu *v); > - void (*load_msr)(struct vcpu * const v, int type, int index, u64 *msr_content); > - void (*save_msr)(struct vcpu * const v, int type, int index, u64 msr_content); > -}; > - > -extern struct op_x86_model_spec op_ppro_spec; > -extern struct op_x86_model_spec op_arch_perfmon_spec; > -extern struct op_x86_model_spec const op_p4_spec; > -extern struct op_x86_model_spec const op_p4_ht2_spec; > -extern struct op_x86_model_spec const op_athlon_spec; > -extern struct op_x86_model_spec const op_amd_fam15h_spec; > - > -void arch_perfmon_setup_counters(void); > - > -extern int ppro_has_global_ctrl; > -extern struct op_x86_model_spec const *model; > - > -#endif /* OP_X86_MODEL_H */ > diff --git a/xen/arch/x86/oprofile/xenoprof.c b/xen/arch/x86/oprofile/xenoprof.c > deleted file mode 100644 > index 7f2525bfb4d6..000000000000 > --- a/xen/arch/x86/oprofile/xenoprof.c > +++ /dev/null > @@ -1,106 +0,0 @@ > -/* > - * Copyright (C) 2005 Hewlett-Packard Co. > - * written by Aravind Menon & Jose Renato Santos > - * (email: xenoprof@groups.hp.com) > - * > - * Copyright (c) 2006 Isaku Yamahata > - * VA Linux Systems Japan K.K. > - * x86 specific part > - */ > - > -#include > -#include > -#include > -#include > - > -#include "op_counter.h" > - > -int xenoprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg) > -{ > - struct xenoprof_counter counter; > - > - if ( copy_from_guest(&counter, arg, 1) ) > - return -EFAULT; > - > - if ( counter.ind >= OP_MAX_COUNTER ) > - return -E2BIG; > - > - counter_config[counter.ind].count = counter.count; > - counter_config[counter.ind].enabled = counter.enabled; > - counter_config[counter.ind].event = counter.event; > - counter_config[counter.ind].kernel = counter.kernel; > - counter_config[counter.ind].user = counter.user; > - counter_config[counter.ind].unit_mask = counter.unit_mask; > - > - return 0; > -} > - > -int xenoprof_arch_ibs_counter(XEN_GUEST_HANDLE_PARAM(void) arg) > -{ > - struct xenoprof_ibs_counter ibs_counter; > - > - if ( copy_from_guest(&ibs_counter, arg, 1) ) > - return -EFAULT; > - > - ibs_config.op_enabled = ibs_counter.op_enabled; > - ibs_config.fetch_enabled = ibs_counter.fetch_enabled; > - ibs_config.max_cnt_fetch = ibs_counter.max_cnt_fetch; > - ibs_config.max_cnt_op = ibs_counter.max_cnt_op; > - ibs_config.rand_en = ibs_counter.rand_en; > - ibs_config.dispatched_ops = ibs_counter.dispatched_ops; > - > - return 0; > -} > - > -#ifdef CONFIG_COMPAT > -#include > - > -int compat_oprof_arch_counter(XEN_GUEST_HANDLE_PARAM(void) arg) > -{ > - struct compat_oprof_counter counter; > - > - if ( copy_from_guest(&counter, arg, 1) ) > - return -EFAULT; > - > - if ( counter.ind >= OP_MAX_COUNTER ) > - return -E2BIG; > - > - counter_config[counter.ind].count = counter.count; > - counter_config[counter.ind].enabled = counter.enabled; > - counter_config[counter.ind].event = counter.event; > - counter_config[counter.ind].kernel = counter.kernel; > - counter_config[counter.ind].user = counter.user; > - counter_config[counter.ind].unit_mask = counter.unit_mask; > - > - return 0; > -} > -#endif > - > -int xenoprofile_get_mode(struct vcpu *curr, const struct cpu_user_regs *regs) > -{ > - if ( !guest_mode(regs) ) > - return 2; > - > - if ( !is_hvm_vcpu(curr) ) > - return guest_kernel_mode(curr, regs); > - > - switch ( hvm_guest_x86_mode(curr) ) > - { > - case X86_MODE_REAL: > - return 1; > - case X86_MODE_VM86: > - return 0; > - default: /* 16BIT | 32BIT | 64BIT */ > - return hvm_get_cpl(curr) != 3; > - } > -} > - > -/* > - * Local variables: > - * mode: C > - * c-file-style: "BSD" > - * c-basic-offset: 4 > - * tab-width: 4 > - * indent-tabs-mode: nil > - * End: > - */ > diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c > index 6ba7ae5202ca..f621b99a5fcc 100644 > --- a/xen/arch/x86/traps.c > +++ b/xen/arch/x86/traps.c > @@ -50,7 +50,6 @@ > #include > #include > #include > -#include > > /* > * opt_nmi: one of 'ignore', 'dom0', or 'fatal'. > @@ -1943,9 +1942,6 @@ bool nmi_check_continuation(void) > if ( pci_serr_nmicont() ) > ret = true; > > - if ( nmi_oprofile_send_virq() ) > - ret = true; > - > return ret; > } > > diff --git a/xen/common/Kconfig b/xen/common/Kconfig > index 401d5046f6f5..38320b248a90 100644 > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -374,17 +374,6 @@ config EFI_SET_VIRTUAL_ADDRESS_MAP > > If unsure, say N. > > -config XENOPROF > - bool "Xen Oprofile Support" if EXPERT > - depends on X86 > - help > - Xen OProfile (Xenoprof) is a system-wide profiler for Xen virtual > - machine environments, capable of profiling the Xen virtual machine > - monitor, multiple Linux guest operating systems, and applications > - running on them. > - > - If unsure, say Y. > - > config XSM > bool "Xen Security Modules support" > default ARM > diff --git a/xen/common/Makefile b/xen/common/Makefile > index 8486c0b5106d..92c97d641e67 100644 > --- a/xen/common/Makefile > +++ b/xen/common/Makefile > @@ -63,7 +63,6 @@ obj-$(CONFIG_HAS_VMAP) += vmap.o > obj-y += vsprintf.o > obj-y += wait.o > obj-bin-y += warning.init.o > -obj-$(CONFIG_XENOPROF) += xenoprof.o > obj-y += xmalloc_tlsf.o > > obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo unlz4 unzstd earlycpio,$(n).init.o) > diff --git a/xen/common/compat/xenoprof.c b/xen/common/compat/xenoprof.c > deleted file mode 100644 > index 8fbd86c24c01..000000000000 > --- a/xen/common/compat/xenoprof.c > +++ /dev/null > @@ -1,42 +0,0 @@ > -/* > - * compat/xenoprof.c > - */ > - > -#include > - > -#define COMPAT > -#define ret_t int > - > -#define do_xenoprof_op compat_xenoprof_op > - > -#define xen_oprof_init xenoprof_init > -CHECK_oprof_init; > -#undef xen_oprof_init > - > -#define xenoprof_get_buffer compat_oprof_get_buffer > -#define xenoprof_op_get_buffer compat_oprof_op_get_buffer > -#define xenoprof_arch_counter compat_oprof_arch_counter > - > -#define xen_domid_t domid_t > -#define compat_domid_t domid_compat_t > -CHECK_TYPE(domid); > -#undef compat_domid_t > -#undef xen_domid_t > - > -#define xen_oprof_passive xenoprof_passive > -CHECK_oprof_passive; > -#undef xen_oprof_passive > - > -#define xenoprof_counter compat_oprof_counter > - > -#include "../xenoprof.c" > - > -/* > - * Local variables: > - * mode: C > - * c-file-style: "BSD" > - * c-basic-offset: 4 > - * tab-width: 4 > - * indent-tabs-mode: nil > - * End: > - */ > diff --git a/xen/common/domain.c b/xen/common/domain.c > index 93c71bc766b0..2f4fd844441e 100644 > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -31,7 +31,6 @@ > #include > #include > #include > -#include > #include > #include > #include > @@ -1452,11 +1451,6 @@ static void cf_check complete_domain_destroy(struct rcu_head *head) > > sched_destroy_domain(d); > > - /* Free page used by xen oprofile buffer. */ > -#ifdef CONFIG_XENOPROF > - free_xenoprof_pages(d); > -#endif > - > #ifdef CONFIG_MEM_PAGING > xfree(d->vm_event_paging); > #endif > diff --git a/xen/common/xenoprof.c b/xen/common/xenoprof.c > deleted file mode 100644 > index 1926a92fe481..000000000000 > --- a/xen/common/xenoprof.c > +++ /dev/null > @@ -1,977 +0,0 @@ > -/* > - * Copyright (C) 2005 Hewlett-Packard Co. > - * written by Aravind Menon & Jose Renato Santos > - * (email: xenoprof@groups.hp.com) > - * > - * arch generic xenoprof and IA64 support. > - * dynamic map/unmap xenoprof buffer support. > - * Copyright (c) 2006 Isaku Yamahata > - * VA Linux Systems Japan K.K. > - */ > - > -#ifndef COMPAT > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > - > -/* Override macros from asm/page.h to make them work with mfn_t */ > -#undef virt_to_mfn > -#define virt_to_mfn(va) _mfn(__virt_to_mfn(va)) > - > -#define XENOPROF_DOMAIN_IGNORED 0 > -#define XENOPROF_DOMAIN_ACTIVE 1 > -#define XENOPROF_DOMAIN_PASSIVE 2 > - > -#define XENOPROF_IDLE 0 > -#define XENOPROF_INITIALIZED 1 > -#define XENOPROF_COUNTERS_RESERVED 2 > -#define XENOPROF_READY 3 > -#define XENOPROF_PROFILING 4 > - > -#ifndef CONFIG_COMPAT > -#define XENOPROF_COMPAT(x) false > -typedef struct xenoprof_buf xenoprof_buf_t; > -#define xenoprof_buf(d, b, field) ACCESS_ONCE((b)->field) > -#else > -#include > -#define XENOPROF_COMPAT(x) ((x)->is_compat) > -typedef union { > - struct xenoprof_buf native; > - struct compat_oprof_buf compat; > -} xenoprof_buf_t; > -#define xenoprof_buf(d, b, field) ACCESS_ONCE(*(!(d)->xenoprof->is_compat \ > - ? &(b)->native.field \ > - : &(b)->compat.field)) > -#endif > - > -/* Limit amount of pages used for shared buffer (per domain) */ > -#define MAX_OPROF_SHARED_PAGES 32 > - > -/* Lock protecting the following global state */ > -static DEFINE_SPINLOCK(xenoprof_lock); > - > -static DEFINE_SPINLOCK(pmu_owner_lock); > -int pmu_owner = 0; > -int pmu_hvm_refcount = 0; > - > -struct xenoprof_vcpu { > - int event_size; > - xenoprof_buf_t *buffer; > -}; > - > -struct xenoprof { > - char *rawbuf; > - int npages; > - int nbuf; > - int bufsize; > - int domain_type; > -#ifdef CONFIG_COMPAT > - bool is_compat; > -#endif > - struct xenoprof_vcpu *vcpu; > -}; > - > -static struct domain *active_domains[MAX_OPROF_DOMAINS]; > -static int active_ready[MAX_OPROF_DOMAINS]; > -static unsigned int adomains; > - > -static struct domain *passive_domains[MAX_OPROF_DOMAINS]; > -static unsigned int pdomains; > - > -static unsigned int activated; > -static struct domain *xenoprof_primary_profiler; > -static int xenoprof_state = XENOPROF_IDLE; > -static unsigned long backtrace_depth; > - > -static u64 total_samples; > -static u64 invalid_buffer_samples; > -static u64 corrupted_buffer_samples; > -static u64 lost_samples; > -static u64 active_samples; > -static u64 passive_samples; > -static u64 idle_samples; > -static u64 others_samples; > - > -int acquire_pmu_ownership(int pmu_ownership) > -{ > - spin_lock(&pmu_owner_lock); > - if ( pmu_owner == PMU_OWNER_NONE ) > - { > - pmu_owner = pmu_ownership; > - goto out; > - } > - > - if ( pmu_owner == pmu_ownership ) > - goto out; > - > - spin_unlock(&pmu_owner_lock); > - return 0; > - out: > - if ( pmu_owner == PMU_OWNER_HVM ) > - pmu_hvm_refcount++; > - spin_unlock(&pmu_owner_lock); > - return 1; > -} > - > -void release_pmu_ownership(int pmu_ownership) > -{ > - spin_lock(&pmu_owner_lock); > - if ( pmu_ownership == PMU_OWNER_HVM ) > - pmu_hvm_refcount--; > - if ( !pmu_hvm_refcount ) > - pmu_owner = PMU_OWNER_NONE; > - spin_unlock(&pmu_owner_lock); > -} > - > -int is_active(struct domain *d) > -{ > - struct xenoprof *x = d->xenoprof; > - return ((x != NULL) && (x->domain_type == XENOPROF_DOMAIN_ACTIVE)); > -} > - > -int is_passive(struct domain *d) > -{ > - struct xenoprof *x = d->xenoprof; > - return ((x != NULL) && (x->domain_type == XENOPROF_DOMAIN_PASSIVE)); > -} > - > -static int is_profiled(struct domain *d) > -{ > - return (is_active(d) || is_passive(d)); > -} > - > -static void xenoprof_reset_stat(void) > -{ > - total_samples = 0; > - invalid_buffer_samples = 0; > - corrupted_buffer_samples = 0; > - lost_samples = 0; > - active_samples = 0; > - passive_samples = 0; > - idle_samples = 0; > - others_samples = 0; > -} > - > -static void xenoprof_reset_buf(struct domain *d) > -{ > - int j; > - xenoprof_buf_t *buf; > - > - if ( d->xenoprof == NULL ) > - { > - printk("xenoprof_reset_buf: ERROR - Unexpected " > - "Xenoprof NULL pointer \n"); > - return; > - } > - > - for ( j = 0; j < d->max_vcpus; j++ ) > - { > - buf = d->xenoprof->vcpu[j].buffer; > - if ( buf != NULL ) > - { > - xenoprof_buf(d, buf, event_head) = 0; > - xenoprof_buf(d, buf, event_tail) = 0; > - } > - } > -} > - > -static int > -share_xenoprof_page_with_guest(struct domain *d, mfn_t mfn, int npages) > -{ > - int i; > - > - /* Check if previous page owner has released the page. */ > - for ( i = 0; i < npages; i++ ) > - { > - struct page_info *page = mfn_to_page(mfn_add(mfn, i)); > - > - if ( (page->count_info & (PGC_allocated|PGC_count_mask)) != 0 ) > - { > - printk(XENLOG_G_INFO "dom%d mfn %#lx page->count_info %#lx\n", > - d->domain_id, mfn_x(mfn_add(mfn, i)), page->count_info); > - return -EBUSY; > - } > - page_set_owner(page, NULL); > - } > - > - for ( i = 0; i < npages; i++ ) > - share_xen_page_with_guest(mfn_to_page(mfn_add(mfn, i)), d, SHARE_rw); > - > - return 0; > -} > - > -static void > -unshare_xenoprof_page_with_guest(struct xenoprof *x) > -{ > - int i, npages = x->npages; > - mfn_t mfn = virt_to_mfn(x->rawbuf); > - > - for ( i = 0; i < npages; i++ ) > - { > - struct page_info *page = mfn_to_page(mfn_add(mfn, i)); > - > - BUG_ON(page_get_owner(page) != current->domain); > - put_page_alloc_ref(page); > - } > -} > - > -static void > -xenoprof_shared_gmfn_with_guest( > - struct domain *d, unsigned long maddr, unsigned long gmaddr, int npages) > -{ > - int i; > - > - for ( i = 0; i < npages; i++, maddr += PAGE_SIZE, gmaddr += PAGE_SIZE ) > - { > - BUG_ON(page_get_owner(maddr_to_page(maddr)) != d); > - if ( i == 0 ) > - gdprintk(XENLOG_WARNING, > - "xenoprof unsupported with autotranslated guests\n"); > - > - } > -} > - > -static int alloc_xenoprof_struct( > - struct domain *d, int max_samples, int is_passive) > -{ > - struct vcpu *v; > - int nvcpu, npages, bufsize, max_bufsize; > - unsigned max_max_samples; > - int i; > - > - nvcpu = 0; > - for_each_vcpu ( d, v ) > - nvcpu++; > - > - if ( !nvcpu ) > - return -EINVAL; > - > - d->xenoprof = xzalloc(struct xenoprof); > - if ( d->xenoprof == NULL ) > - { > - printk("alloc_xenoprof_struct(): memory allocation failed\n"); > - return -ENOMEM; > - } > - > - d->xenoprof->vcpu = xzalloc_array(struct xenoprof_vcpu, d->max_vcpus); > - if ( d->xenoprof->vcpu == NULL ) > - { > - xfree(d->xenoprof); > - d->xenoprof = NULL; > - printk("alloc_xenoprof_struct(): vcpu array allocation failed\n"); > - return -ENOMEM; > - } > - > - bufsize = sizeof(struct xenoprof_buf); > - i = sizeof(struct event_log); > -#ifdef CONFIG_COMPAT > - d->xenoprof->is_compat = is_pv_32bit_domain(is_passive ? hardware_domain : d); > - if ( XENOPROF_COMPAT(d->xenoprof) ) > - { > - bufsize = sizeof(struct compat_oprof_buf); > - i = sizeof(struct compat_event_log); > - } > -#endif > - > - /* reduce max_samples if necessary to limit pages allocated */ > - max_bufsize = (MAX_OPROF_SHARED_PAGES * PAGE_SIZE) / nvcpu; > - max_max_samples = ( (max_bufsize - bufsize) / i ) + 1; > - if ( (unsigned)max_samples > max_max_samples ) > - max_samples = max_max_samples; > - > - bufsize += (max_samples - 1) * i; > - npages = (nvcpu * bufsize - 1) / PAGE_SIZE + 1; > - > - d->xenoprof->rawbuf = alloc_xenheap_pages(get_order_from_pages(npages), 0); > - if ( d->xenoprof->rawbuf == NULL ) > - { > - xfree(d->xenoprof->vcpu); > - xfree(d->xenoprof); > - d->xenoprof = NULL; > - return -ENOMEM; > - } > - > - for ( i = 0; i < npages; ++i ) > - clear_page(d->xenoprof->rawbuf + i * PAGE_SIZE); > - > - d->xenoprof->npages = npages; > - d->xenoprof->nbuf = nvcpu; > - d->xenoprof->bufsize = bufsize; > - d->xenoprof->domain_type = XENOPROF_DOMAIN_IGNORED; > - > - /* Update buffer pointers for active vcpus */ > - i = 0; > - for_each_vcpu ( d, v ) > - { > - xenoprof_buf_t *buf = (xenoprof_buf_t *) > - &d->xenoprof->rawbuf[i * bufsize]; > - > - d->xenoprof->vcpu[v->vcpu_id].event_size = max_samples; > - d->xenoprof->vcpu[v->vcpu_id].buffer = buf; > - xenoprof_buf(d, buf, event_size) = max_samples; > - xenoprof_buf(d, buf, vcpu_id) = v->vcpu_id; > - > - i++; > - /* in the unlikely case that the number of active vcpus changes */ > - if ( i >= nvcpu ) > - break; > - } > - > - return 0; > -} > - > -void free_xenoprof_pages(struct domain *d) > -{ > - struct xenoprof *x; > - int order; > - > - x = d->xenoprof; > - if ( x == NULL ) > - return; > - > - if ( x->rawbuf != NULL ) > - { > - order = get_order_from_pages(x->npages); > - free_xenheap_pages(x->rawbuf, order); > - } > - > - xfree(x->vcpu); > - xfree(x); > - d->xenoprof = NULL; > -} > - > -static int active_index(struct domain *d) > -{ > - int i; > - > - for ( i = 0; i < adomains; i++ ) > - if ( active_domains[i] == d ) > - return i; > - > - return -1; > -} > - > -static int set_active(struct domain *d) > -{ > - int ind; > - struct xenoprof *x; > - > - ind = active_index(d); > - if ( ind < 0 ) > - return -EPERM; > - > - x = d->xenoprof; > - if ( x == NULL ) > - return -EPERM; > - > - x->domain_type = XENOPROF_DOMAIN_ACTIVE; > - active_ready[ind] = 1; > - activated++; > - > - return 0; > -} > - > -static int reset_active(struct domain *d) > -{ > - int ind; > - struct xenoprof *x; > - > - ind = active_index(d); > - if ( ind < 0 ) > - return -EPERM; > - > - x = d->xenoprof; > - if ( x == NULL ) > - return -EPERM; > - > - x->domain_type = XENOPROF_DOMAIN_IGNORED; > - active_ready[ind] = 0; > - active_domains[ind] = NULL; > - activated--; > - put_domain(d); > - > - if ( activated <= 0 ) > - adomains = 0; > - > - return 0; > -} > - > -static void reset_passive(struct domain *d) > -{ > - struct xenoprof *x; > - > - if ( d == NULL ) > - return; > - > - x = d->xenoprof; > - if ( x == NULL ) > - return; > - > - x->domain_type = XENOPROF_DOMAIN_IGNORED; > - unshare_xenoprof_page_with_guest(x); > -} > - > -static void reset_active_list(void) > -{ > - int i; > - > - for ( i = 0; i < adomains; i++ ) > - if ( active_ready[i] ) > - reset_active(active_domains[i]); > - > - adomains = 0; > - activated = 0; > -} > - > -static void reset_passive_list(void) > -{ > - int i; > - > - for ( i = 0; i < pdomains; i++ ) > - { > - reset_passive(passive_domains[i]); > - put_domain(passive_domains[i]); > - passive_domains[i] = NULL; > - } > - > - pdomains = 0; > -} > - > -static int add_active_list(domid_t domid) > -{ > - struct domain *d; > - > - if ( adomains >= MAX_OPROF_DOMAINS ) > - return -E2BIG; > - > - d = get_domain_by_id(domid); > - if ( d == NULL ) > - return -EINVAL; > - > - active_domains[adomains] = d; > - active_ready[adomains] = 0; > - adomains++; > - > - return 0; > -} > - > -static int add_passive_list(XEN_GUEST_HANDLE_PARAM(void) arg) > -{ > - struct xenoprof_passive passive; > - struct domain *d; > - int ret = 0; > - > - if ( pdomains >= MAX_OPROF_DOMAINS ) > - return -E2BIG; > - > - if ( copy_from_guest(&passive, arg, 1) ) > - return -EFAULT; > - > - d = get_domain_by_id(passive.domain_id); > - if ( d == NULL ) > - return -EINVAL; > - > - if ( d->xenoprof == NULL ) > - { > - ret = alloc_xenoprof_struct(d, passive.max_samples, 1); > - if ( ret < 0 ) > - { > - put_domain(d); > - return -ENOMEM; > - } > - } > - > - ret = share_xenoprof_page_with_guest( > - current->domain, virt_to_mfn(d->xenoprof->rawbuf), > - d->xenoprof->npages); > - if ( ret < 0 ) > - { > - put_domain(d); > - return ret; > - } > - > - d->xenoprof->domain_type = XENOPROF_DOMAIN_PASSIVE; > - passive.nbuf = d->xenoprof->nbuf; > - passive.bufsize = d->xenoprof->bufsize; > - if ( !paging_mode_translate(current->domain) ) > - passive.buf_gmaddr = __pa(d->xenoprof->rawbuf); > - else > - xenoprof_shared_gmfn_with_guest( > - current->domain, __pa(d->xenoprof->rawbuf), > - passive.buf_gmaddr, d->xenoprof->npages); > - > - if ( __copy_to_guest(arg, &passive, 1) ) > - { > - put_domain(d); > - return -EFAULT; > - } > - > - passive_domains[pdomains] = d; > - pdomains++; > - > - return ret; > -} > - > - > -/* Get space in the buffer */ > -static int xenoprof_buf_space(int head, int tail, int size) > -{ > - return ((tail > head) ? 0 : size) + tail - head - 1; > -} > - > -/* Check for space and add a sample. Return 1 if successful, 0 otherwise. */ > -static int xenoprof_add_sample(const struct domain *d, > - const struct xenoprof_vcpu *v, > - uint64_t eip, int mode, int event) > -{ > - xenoprof_buf_t *buf = v->buffer; > - int head, tail, size; > - > - head = xenoprof_buf(d, buf, event_head); > - tail = xenoprof_buf(d, buf, event_tail); > - size = v->event_size; > - > - /* make sure indexes in shared buffer are sane */ > - if ( (head < 0) || (head >= size) || (tail < 0) || (tail >= size) ) > - { > - corrupted_buffer_samples++; > - return 0; > - } > - > - if ( xenoprof_buf_space(head, tail, size) > 0 ) > - { > - xenoprof_buf(d, buf, event_log[head].eip) = eip; > - xenoprof_buf(d, buf, event_log[head].mode) = mode; > - xenoprof_buf(d, buf, event_log[head].event) = event; > - head++; > - if ( head >= size ) > - head = 0; > - > - xenoprof_buf(d, buf, event_head) = head; > - } > - else > - { > - xenoprof_buf(d, buf, lost_samples)++; > - lost_samples++; > - return 0; > - } > - > - return 1; > -} > - > -int xenoprof_add_trace(struct vcpu *vcpu, uint64_t pc, int mode) > -{ > - struct domain *d = vcpu->domain; > - > - /* Do not accidentally write an escape code due to a broken frame. */ > - if ( pc == XENOPROF_ESCAPE_CODE ) > - { > - invalid_buffer_samples++; > - return 0; > - } > - > - return xenoprof_add_sample(d, &d->xenoprof->vcpu[vcpu->vcpu_id], > - pc, mode, 0); > -} > - > -void xenoprof_log_event(struct vcpu *vcpu, const struct cpu_user_regs *regs, > - uint64_t pc, int mode, int event) > -{ > - struct domain *d = vcpu->domain; > - struct xenoprof_vcpu *v; > - xenoprof_buf_t *buf; > - > - total_samples++; > - > - /* Ignore samples of un-monitored domains. */ > - if ( !is_profiled(d) ) > - { > - others_samples++; > - return; > - } > - > - v = &d->xenoprof->vcpu[vcpu->vcpu_id]; > - if ( v->buffer == NULL ) > - { > - invalid_buffer_samples++; > - return; > - } > - > - buf = v->buffer; > - > - /* Provide backtrace if requested. */ > - if ( backtrace_depth > 0 ) > - { > - if ( xenoprof_buf_space(xenoprof_buf(d, buf, event_head), > - xenoprof_buf(d, buf, event_tail), > - v->event_size) < 2 ) > - { > - xenoprof_buf(d, buf, lost_samples)++; > - lost_samples++; > - return; > - } > - > - /* xenoprof_add_sample() will increment lost_samples on failure */ > - if ( !xenoprof_add_sample(d, v, XENOPROF_ESCAPE_CODE, mode, > - XENOPROF_TRACE_BEGIN) ) > - return; > - } > - > - if ( xenoprof_add_sample(d, v, pc, mode, event) ) > - { > - if ( is_active(vcpu->domain) ) > - active_samples++; > - else > - passive_samples++; > - if ( mode == 0 ) > - xenoprof_buf(d, buf, user_samples)++; > - else if ( mode == 1 ) > - xenoprof_buf(d, buf, kernel_samples)++; > - else > - xenoprof_buf(d, buf, xen_samples)++; > - > - } > - > - if ( backtrace_depth > 0 ) > - xenoprof_backtrace(vcpu, regs, backtrace_depth, mode); > -} > - > - > - > -static int xenoprof_op_init(XEN_GUEST_HANDLE_PARAM(void) arg) > -{ > - struct domain *d = current->domain; > - struct xenoprof_init xenoprof_init; > - int ret; > - > - if ( copy_from_guest(&xenoprof_init, arg, 1) ) > - return -EFAULT; > - > - if ( (ret = xenoprof_arch_init(&xenoprof_init.num_events, > - xenoprof_init.cpu_type)) ) > - return ret; > - > - /* Only the hardware domain may become the primary profiler here because > - * there is currently no cleanup of xenoprof_primary_profiler or associated > - * profiling state when the primary profiling domain is shut down or > - * crashes. Once a better cleanup method is present, it will be possible to > - * allow another domain to be the primary profiler. > - */ > - xenoprof_init.is_primary = > - ((xenoprof_primary_profiler == d) || > - ((xenoprof_primary_profiler == NULL) && is_hardware_domain(d))); > - if ( xenoprof_init.is_primary ) > - xenoprof_primary_profiler = current->domain; > - > - return __copy_to_guest(arg, &xenoprof_init, 1) ? -EFAULT : 0; > -} > - > -#define ret_t long > - > -#endif /* !COMPAT */ > - > -static int xenoprof_op_get_buffer(XEN_GUEST_HANDLE_PARAM(void) arg) > -{ > - struct xenoprof_get_buffer xenoprof_get_buffer; > - struct domain *d = current->domain; > - int ret; > - > - if ( copy_from_guest(&xenoprof_get_buffer, arg, 1) ) > - return -EFAULT; > - > - /* > - * We allocate xenoprof struct and buffers only at first time > - * get_buffer is called. Memory is then kept until domain is destroyed. > - */ > - if ( d->xenoprof == NULL ) > - { > - ret = alloc_xenoprof_struct(d, xenoprof_get_buffer.max_samples, 0); > - if ( ret < 0 ) > - return ret; > - } > - else > - d->xenoprof->domain_type = XENOPROF_DOMAIN_IGNORED; > - > - ret = share_xenoprof_page_with_guest( > - d, virt_to_mfn(d->xenoprof->rawbuf), d->xenoprof->npages); > - if ( ret < 0 ) > - return ret; > - > - xenoprof_reset_buf(d); > - > - xenoprof_get_buffer.nbuf = d->xenoprof->nbuf; > - xenoprof_get_buffer.bufsize = d->xenoprof->bufsize; > - if ( !paging_mode_translate(d) ) > - xenoprof_get_buffer.buf_gmaddr = __pa(d->xenoprof->rawbuf); > - else > - xenoprof_shared_gmfn_with_guest( > - d, __pa(d->xenoprof->rawbuf), xenoprof_get_buffer.buf_gmaddr, > - d->xenoprof->npages); > - > - return __copy_to_guest(arg, &xenoprof_get_buffer, 1) ? -EFAULT : 0; > -} > - > -#define NONPRIV_OP(op) ( (op == XENOPROF_init) \ > - || (op == XENOPROF_enable_virq) \ > - || (op == XENOPROF_disable_virq) \ > - || (op == XENOPROF_get_buffer)) > - > -ret_t do_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg) > -{ > - int ret = 0; > - > - if ( (op < 0) || (op > XENOPROF_last_op) ) > - { > - gdprintk(XENLOG_DEBUG, "invalid operation %d\n", op); > - return -EINVAL; > - } > - > - if ( !NONPRIV_OP(op) && (current->domain != xenoprof_primary_profiler) ) > - { > - gdprintk(XENLOG_DEBUG, "denied privileged operation %d\n", op); > - return -EPERM; > - } > - > - ret = xsm_profile(XSM_HOOK, current->domain, op); > - if ( ret ) > - return ret; > - > - spin_lock(&xenoprof_lock); > - > - switch ( op ) > - { > - case XENOPROF_init: > - ret = xenoprof_op_init(arg); > - if ( (ret == 0) && > - (current->domain == xenoprof_primary_profiler) ) > - xenoprof_state = XENOPROF_INITIALIZED; > - break; > - > - case XENOPROF_get_buffer: > - if ( !acquire_pmu_ownership(PMU_OWNER_XENOPROF) ) > - { > - ret = -EBUSY; > - break; > - } > - ret = xenoprof_op_get_buffer(arg); > - break; > - > - case XENOPROF_reset_active_list: > - reset_active_list(); > - ret = 0; > - break; > - > - case XENOPROF_reset_passive_list: > - reset_passive_list(); > - ret = 0; > - break; > - > - case XENOPROF_set_active: > - { > - domid_t domid; > - if ( xenoprof_state != XENOPROF_INITIALIZED ) > - { > - ret = -EPERM; > - break; > - } > - if ( copy_from_guest(&domid, arg, 1) ) > - { > - ret = -EFAULT; > - break; > - } > - ret = add_active_list(domid); > - break; > - } > - > - case XENOPROF_set_passive: > - if ( xenoprof_state != XENOPROF_INITIALIZED ) > - { > - ret = -EPERM; > - break; > - } > - ret = add_passive_list(arg); > - break; > - > - case XENOPROF_reserve_counters: > - if ( xenoprof_state != XENOPROF_INITIALIZED ) > - { > - ret = -EPERM; > - break; > - } > - ret = xenoprof_arch_reserve_counters(); > - if ( !ret ) > - xenoprof_state = XENOPROF_COUNTERS_RESERVED; > - break; > - > - case XENOPROF_counter: > - if ( (xenoprof_state != XENOPROF_COUNTERS_RESERVED) || > - (adomains == 0) ) > - { > - ret = -EPERM; > - break; > - } > - ret = xenoprof_arch_counter(arg); > - break; > - > - case XENOPROF_setup_events: > - if ( xenoprof_state != XENOPROF_COUNTERS_RESERVED ) > - { > - ret = -EPERM; > - break; > - } > - ret = xenoprof_arch_setup_events(); > - if ( !ret ) > - xenoprof_state = XENOPROF_READY; > - break; > - > - case XENOPROF_enable_virq: > - { > - int i; > - > - if ( current->domain == xenoprof_primary_profiler ) > - { > - if ( xenoprof_state != XENOPROF_READY ) > - { > - ret = -EPERM; > - break; > - } > - xenoprof_arch_enable_virq(); > - xenoprof_reset_stat(); > - for ( i = 0; i < pdomains; i++ ) > - xenoprof_reset_buf(passive_domains[i]); > - } > - xenoprof_reset_buf(current->domain); > - ret = set_active(current->domain); > - break; > - } > - > - case XENOPROF_start: > - ret = -EPERM; > - if ( (xenoprof_state == XENOPROF_READY) && > - (activated == adomains) ) > - ret = xenoprof_arch_start(); > - if ( ret == 0 ) > - xenoprof_state = XENOPROF_PROFILING; > - break; > - > - case XENOPROF_stop: > - { > - struct domain *d; > - struct vcpu *v; > - int i; > - > - if ( xenoprof_state != XENOPROF_PROFILING ) > - { > - ret = -EPERM; > - break; > - } > - xenoprof_arch_stop(); > - > - /* Flush remaining samples. */ > - for ( i = 0; i < adomains; i++ ) > - { > - if ( !active_ready[i] ) > - continue; > - d = active_domains[i]; > - for_each_vcpu(d, v) > - send_guest_vcpu_virq(v, VIRQ_XENOPROF); > - } > - xenoprof_state = XENOPROF_READY; > - break; > - } > - > - case XENOPROF_disable_virq: > - { > - struct xenoprof *x; > - if ( (xenoprof_state == XENOPROF_PROFILING) && > - (is_active(current->domain)) ) > - { > - ret = -EPERM; > - break; > - } > - if ( (ret = reset_active(current->domain)) != 0 ) > - break; > - x = current->domain->xenoprof; > - unshare_xenoprof_page_with_guest(x); > - release_pmu_ownership(PMU_OWNER_XENOPROF); > - break; > - } > - > - case XENOPROF_release_counters: > - ret = -EPERM; > - if ( (xenoprof_state == XENOPROF_COUNTERS_RESERVED) || > - (xenoprof_state == XENOPROF_READY) ) > - { > - xenoprof_state = XENOPROF_INITIALIZED; > - xenoprof_arch_release_counters(); > - xenoprof_arch_disable_virq(); > - reset_passive_list(); > - ret = 0; > - } > - break; > - > - case XENOPROF_shutdown: > - ret = -EPERM; > - if ( xenoprof_state == XENOPROF_INITIALIZED ) > - { > - activated = 0; > - adomains=0; > - xenoprof_primary_profiler = NULL; > - backtrace_depth=0; > - ret = 0; > - } > - break; > - > - case XENOPROF_set_backtrace: > - ret = 0; > - if ( !xenoprof_backtrace_supported() ) > - ret = -EINVAL; > - else if ( copy_from_guest(&backtrace_depth, arg, 1) ) > - ret = -EFAULT; > - break; > - > - case XENOPROF_ibs_counter: > - if ( (xenoprof_state != XENOPROF_COUNTERS_RESERVED) || > - (adomains == 0) ) > - { > - ret = -EPERM; > - break; > - } > - ret = xenoprof_arch_ibs_counter(arg); > - break; > - > - case XENOPROF_get_ibs_caps: > - ret = ibs_caps; > - break; > - > - default: > - ret = -ENOSYS; > - } > - > - spin_unlock(&xenoprof_lock); > - > - if ( ret < 0 ) > - gdprintk(XENLOG_DEBUG, "operation %d failed: %d\n", op, ret); > - > - return ret; > -} > - > -#if defined(CONFIG_COMPAT) && !defined(COMPAT) > -#undef ret_t > -#include "compat/xenoprof.c" > -#endif > - > -/* > - * Local variables: > - * mode: C > - * c-file-style: "BSD" > - * c-basic-offset: 4 > - * tab-width: 4 > - * indent-tabs-mode: nil > - * End: > - */ > diff --git a/xen/include/Makefile b/xen/include/Makefile > index e71f419e8c22..b3184a395b50 100644 > --- a/xen/include/Makefile > +++ b/xen/include/Makefile > @@ -31,7 +31,6 @@ headers-$(CONFIG_HVM) += compat/hvm/hvm_vcpu.h > headers-$(CONFIG_HYPFS) += compat/hypfs.h > headers-$(CONFIG_KEXEC) += compat/kexec.h > headers-$(CONFIG_TRACEBUFFER) += compat/trace.h > -headers-$(CONFIG_XENOPROF) += compat/xenoprof.h > headers-$(CONFIG_XSM_FLASK) += compat/xsm/flask_op.h > > headers-n := $(sort $(filter-out $(headers-y),$(headers-n) $(headers-))) > diff --git a/xen/include/hypercall-defs.c b/xen/include/hypercall-defs.c > index 5782cdfd1496..63755bb8df6e 100644 > --- a/xen/include/hypercall-defs.c > +++ b/xen/include/hypercall-defs.c > @@ -127,9 +127,6 @@ argo_op(unsigned int cmd, void *arg1, void *arg2, unsigned long arg3, unsigned l > #ifdef CONFIG_PV > iret() > nmi_op(unsigned int cmd, void *arg) > -#ifdef CONFIG_XENOPROF > -xenoprof_op(int op, void *arg) > -#endif > #endif /* CONFIG_PV */ > > #ifdef CONFIG_COMPAT > @@ -269,9 +266,6 @@ xsm_op compat do compat do do > nmi_op compat do - - - > sched_op compat do compat do do > callback_op compat do - - - > -#ifdef CONFIG_XENOPROF > -xenoprof_op compat do - - - > -#endif > event_channel_op do do do:1 do:1 do:1 > physdev_op compat do hvm hvm do_arm > #ifdef CONFIG_HVM > diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h > index 7f15204c3885..b12fd10e6315 100644 > --- a/xen/include/public/xen.h > +++ b/xen/include/public/xen.h > @@ -106,7 +106,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t); > #define __HYPERVISOR_nmi_op 28 > #define __HYPERVISOR_sched_op 29 > #define __HYPERVISOR_callback_op 30 > -#define __HYPERVISOR_xenoprof_op 31 > +#define __HYPERVISOR_xenoprof_op 31 /* Dropped in Xen 4.22 */ > #define __HYPERVISOR_event_channel_op 32 > #define __HYPERVISOR_physdev_op 33 > #define __HYPERVISOR_hvm_op 34 > diff --git a/xen/include/public/xenoprof.h b/xen/include/public/xenoprof.h > index 2298b6759ed3..f97a67042e07 100644 > --- a/xen/include/public/xenoprof.h > +++ b/xen/include/public/xenoprof.h > @@ -3,7 +3,7 @@ > * xenoprof.h > * > * Interface for enabling system wide profiling based on hardware performance > - * counters > + * counters. Dropped from Xen in 4.22. > * > * Copyright (C) 2005 Hewlett-Packard Co. > * Written by Aravind Menon & Jose Renato Santos > diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h > index 1f77e0869b5d..dc06f6f1131a 100644 > --- a/xen/include/xen/sched.h > +++ b/xen/include/xen/sched.h > @@ -573,9 +573,6 @@ struct domain > /* Control-plane tools handle for this domain. */ > xen_domain_handle_t handle; > > - /* OProfile support. */ > - struct xenoprof *xenoprof; > - > /* Domain watchdog. */ > #define NR_DOMAIN_WATCHDOG_TIMERS 2 > spinlock_t watchdog_lock; > diff --git a/xen/include/xen/xenoprof.h b/xen/include/xen/xenoprof.h > deleted file mode 100644 > index c3dac447d334..000000000000 > --- a/xen/include/xen/xenoprof.h > +++ /dev/null > @@ -1,49 +0,0 @@ > -/****************************************************************************** > - * xenoprof.h > - * > - * Xenoprof: Xenoprof enables performance profiling in Xen > - * > - * Copyright (C) 2005 Hewlett-Packard Co. > - * written by Aravind Menon & Jose Renato Santos > - */ > - > -#ifndef __XEN_XENOPROF_H__ > -#define __XEN_XENOPROF_H__ > - > -#define PMU_OWNER_NONE 0 > -#define PMU_OWNER_XENOPROF 1 > -#define PMU_OWNER_HVM 2 > - > -#ifdef CONFIG_XENOPROF > - > -#include > -#include > - > -struct domain; > -struct vcpu; > -struct cpu_user_regs; > - > -int acquire_pmu_ownership(int pmu_ownership); > -void release_pmu_ownership(int pmu_ownership); > - > -int is_active(struct domain *d); > -int is_passive(struct domain *d); > -void free_xenoprof_pages(struct domain *d); > - > -int xenoprof_add_trace(struct vcpu *, uint64_t pc, int mode); > - > -void xenoprof_log_event(struct vcpu *, const struct cpu_user_regs *, > - uint64_t pc, int mode, int event); > - > -#else > -static inline int acquire_pmu_ownership(int pmu_ownership) > -{ > - return 1; > -} > - > -static inline void release_pmu_ownership(int pmu_ownership) > -{ > -} > -#endif /* CONFIG_XENOPROF */ > - > -#endif /* __XEN__XENOPROF_H__ */ > diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h > index e801dbcdbaef..b8fd7aeedd9e 100644 > --- a/xen/include/xsm/dummy.h > +++ b/xen/include/xsm/dummy.h > @@ -278,13 +278,6 @@ static XSM_INLINE int cf_check xsm_console_io( > return xsm_default_action(XSM_PRIV, d, NULL); > } > > -static XSM_INLINE int cf_check xsm_profile( > - XSM_DEFAULT_ARG struct domain *d, int op) > -{ > - XSM_ASSERT_ACTION(XSM_HOOK); > - return xsm_default_action(action, d, NULL); > -} > - > static XSM_INLINE int cf_check xsm_kexec(XSM_DEFAULT_VOID) > { > XSM_ASSERT_ACTION(XSM_PRIV); > diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h > index 2d831d774541..cc32a6c09104 100644 > --- a/xen/include/xsm/xsm.h > +++ b/xen/include/xsm/xsm.h > @@ -101,8 +101,6 @@ struct xsm_ops { > > int (*console_io)(struct domain *d, int cmd); > > - int (*profile)(struct domain *d, int op); > - > int (*kexec)(void); > int (*schedop_shutdown)(struct domain *d1, struct domain *d2); > > @@ -450,11 +448,6 @@ static inline int xsm_console_io(xsm_default_t def, struct domain *d, int cmd) > return alternative_call(xsm_ops.console_io, d, cmd); > } > > -static inline int xsm_profile(xsm_default_t def, struct domain *d, int op) > -{ > - return alternative_call(xsm_ops.profile, d, op); > -} > - > static inline int xsm_kexec(xsm_default_t def) > { > return alternative_call(xsm_ops.kexec); > diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c > index 96dc82ac2e29..244ef557528b 100644 > --- a/xen/xsm/dummy.c > +++ b/xen/xsm/dummy.c > @@ -61,8 +61,6 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = { > > .console_io = xsm_console_io, > > - .profile = xsm_profile, > - > .kexec = xsm_kexec, > .schedop_shutdown = xsm_schedop_shutdown, > > diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c > index 9f3915617cc8..b250b2706535 100644 > --- a/xen/xsm/flask/hooks.c > +++ b/xen/xsm/flask/hooks.c > @@ -19,7 +19,6 @@ > #include > #include > #include > -#include > #include > #ifdef CONFIG_HAS_PCI_MSI > #include > @@ -512,38 +511,6 @@ static int cf_check flask_console_io(struct domain *d, int cmd) > return domain_has_xen(d, perm); > } > > -static int cf_check flask_profile(struct domain *d, int op) > -{ > - uint32_t perm; > - > - switch ( op ) > - { > - case XENOPROF_init: > - case XENOPROF_enable_virq: > - case XENOPROF_disable_virq: > - case XENOPROF_get_buffer: > - perm = XEN__NONPRIVPROFILE; > - break; > - case XENOPROF_reset_active_list: > - case XENOPROF_reset_passive_list: > - case XENOPROF_set_active: > - case XENOPROF_set_passive: > - case XENOPROF_reserve_counters: > - case XENOPROF_counter: > - case XENOPROF_setup_events: > - case XENOPROF_start: > - case XENOPROF_stop: > - case XENOPROF_release_counters: > - case XENOPROF_shutdown: > - perm = XEN__PRIVPROFILE; > - break; > - default: > - return avc_unknown_permission("xenoprof op", op); > - } > - > - return domain_has_xen(d, perm); > -} > - > static int cf_check flask_kexec(void) > { > return domain_has_xen(current->domain, XEN__KEXEC); > @@ -1930,8 +1897,6 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = { > > .console_io = flask_console_io, > > - .profile = flask_profile, > - > .kexec = flask_kexec, > .schedop_shutdown = flask_schedop_shutdown, > > diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors > index 51a1577a66c7..ce907d50a45e 100644 > --- a/xen/xsm/flask/policy/access_vectors > +++ b/xen/xsm/flask/policy/access_vectors > @@ -38,10 +38,6 @@ class xen > readapic > # PHYSDEVOP_apic_write > writeapic > -# Most XENOPROF_* > - privprofile > -# XENOPROF_{init,enable_virq,disable_virq,get_buffer} > - nonprivprofile > # kexec hypercall > kexec > # XENPF_firmware_info, XENPF_efi_runtime_call > > base-commit: c36ddba28e314e9350f4024972023b52e34ec73e From xen-devel-bounces@lists.xenproject.org Tue Jan 06 08:53:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 08:53:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195915.1513789 (Exim 4.92) (envelope-from ) id 1vd2oS-0004DA-PZ; Tue, 06 Jan 2026 08:53:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195915.1513789; Tue, 06 Jan 2026 08:53:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd2oS-0004D3-Lm; Tue, 06 Jan 2026 08:53:12 +0000 Received: by outflank-mailman (input) for mailman id 1195915; Tue, 06 Jan 2026 08:53:11 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd2oR-0004Cv-Lr for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 08:53:11 +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 1f94b95b-eadd-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 09:53:08 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-47775fb6c56so6555955e9.1 for ; Tue, 06 Jan 2026 00:53:08 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f41f5e0sm31413165e9.8.2026.01.06.00.53.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 00:53:07 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1f94b95b-eadd-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767689588; x=1768294388; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=0LqFlE8Kjt3pdHwCM8kYgyPYzoed+FK5PjoEKPEg9pc=; b=Le6nQ0FGOA/aOrCsU8xlqJIe9Ddx2YosGm+czkLkHDTRWFNGtQyDBDNtCdlxVEG5FC Sl8NQ165ub2WDiMsxr8EL7vRpMF7JhEJ+4ruGtHHmWho0iooUnuXD2yX/ZIF2wU12s9i dKVZPYxQb6+Q4H7QbdL49NFu03pZJmJGQD2ARGag5MsEa3i8aMeRmR9e8np5xv/shh8K SLTxQmtmlV9eoxJIDgTCIIHFuqg6FwTpktj4HrzRPrFLiwNI5D4aws16vJpIkGlgaA3k 1hrTTGm6pa+lPfWifA3KPTYzgOGEOxEbkyCZ6Kcrax4ZTMD2LsLoXFy+csoYE5TyQHn+ Xuog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767689588; x=1768294388; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0LqFlE8Kjt3pdHwCM8kYgyPYzoed+FK5PjoEKPEg9pc=; b=Xxqf2dWD5SM2YJ3+bGbuP20PB1H8XMNVqNVvyS2DEZVZQu8vyZu/CL0S8lnLUzzXv9 8QdkAubGc2Tj1dV7WTMtRgRORHhmEnIaZeuY/2MN8rMGjnHQWDjlVm5prMUmKjX+8wc1 2kSMaCOByEg9Bh7mv84XPS4iuFymxyGjXtkAJRQzW778ZklxcCZYLIN6qHN99MzuUawF wQjHSECO0A7mtoYHIn60W27c1m+bc4uH6PSvFmHE1+UE2YvDEK0kYNSZef4MxZ62Ae4K bUgXFR8BLmIA6QoDVzJ0VgjvpfxbTW+5iUIL0VzHV1BaTN0GlKd6jPxPnp/rdHdsgeNC p6Lw== X-Forwarded-Encrypted: i=1; AJvYcCX/SE1SRanLRCQQScsD9zYAITk2SauhL53bKDh5w0OSO0oK/30p2SLVF+9rg0sU1hgil5bIlgH5Xq4=@lists.xenproject.org X-Gm-Message-State: AOJu0YwIr+D9yFh9Eq0JjmjANSla82QLEKlaSZ7zIT1oC9uyHjLUjmrN ZZEQGYyDG9QY7y0YYiplW9OCOP0FEv5SqbCekdkpQa9tVLqboyTySuYZHqnPhYJfnQ== X-Gm-Gg: AY/fxX7eM7yN4scK5v9k5yYzmgoCgTOwU5khKIMK/ti2twwXSLKgyP4/rluyPzyboB6 il5TqcVXddrdZmmIpJ8ER0Q+W839qjut38JaW7ecgnWHlPJmUlQBpmZMaHkawrVwZFnbHvpV0hM 0eq2tOOaV4VgKtSfzRTLR+Le4q6JrK9jHGtT34mAxwY6fyFP+i8AzUKHYN0cCigzRUxBOt4kA1S +IVn5xsGiAXua/T/sJ3E+t7rNyArFn0xRrNF6yNa2MvmhIqtEkvuStyOX4HybIcXiNCPsBzYvrS xJpNGYLYWBneHsv7m/tGKHOgWn9I+UXi8u2uzuL0D+XI3e3e4YHG8MJyWOG4R8WszmuhYHBwrIb P65Ya7gtpwKHcUbT8fNP7qFJp7emDY0tkrr7IHbwpJKV/Xy1b6jJlKgKRYPb5po6afcIHvPjzZX 5JT3EDpDdQMyceNioy+zgDH3WbQOLeJFg2B427t0V1e7aAaONOTmbGG4+uOAksd6pSFQOAGZ0Vf APXWoHQDDUtHg== X-Google-Smtp-Source: AGHT+IFWyVAHAd9pCAt+w6ij04HEm52pynKRPJKuyL2bntjr1G8NvG8/NTUyGadFo3z/J15COlTBtg== X-Received: by 2002:a05:600c:4443:b0:475:e007:bae0 with SMTP id 5b1f17b1804b1-47d821da708mr8940655e9.16.1767689588131; Tue, 06 Jan 2026 00:53:08 -0800 (PST) Message-ID: <8561e1dd-492b-4d51-bf10-0a4523c941a8@suse.com> Date: Tue, 6 Jan 2026 09:53:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen: Drop xenoprofile support To: Oleksii Kurochko Cc: Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P . Smith" , Andrew Cooper , Xen-devel References: <20260105195717.601500-1-andrew.cooper3@citrix.com> <724e78ef-b6ed-40db-a5c0-bd6473b6fe16@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: <724e78ef-b6ed-40db-a5c0-bd6473b6fe16@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06.01.2026 09:43, Oleksii Kurochko wrote: > > On 1/5/26 8:57 PM, Andrew Cooper wrote: >> The most recent xenoprof change was 300ef0cb4fde ("x86: Add Xenoprofile >> support for AMD Family16h") in 2013, despite there being 42 changes worth of >> other cleanup/rearranging since then. >> >> Oprofile themselves dropped Xen support in commit 0c142c3a096d ("Remove >> opcontrol and the GUI and processor models dependent on it") in 2014, as part >> of releasing version 1.0 and switching over to using operf based on the Linux >> perf_event subsystem. Linux's version of this patch was merged in commit >> 24880bef417f ("Merge tag 'oprofile-removal-5.12'") in 2021. >> >> Drop xenoprof and all supporting infrastructure, including the hypercall, the >> XSM hook and flask vectors which lose their only caller, and even shrinks >> struct domain by one pointer which wasn't properly excluded in >> !CONFIG_XENOPROF builds. >> >> Retain the public xenoprof.h header as it is ABI, but note that the >> functionality is removed. >> >> 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: Daniel P. Smith >> >> Despite appearing to be architecture neutral, the internals of Xenoprof were >> entirely x86-specific. Another curiosity is that only the VMX MSR hooks >> called passive_domain_do_{rd,wr}msr(), and I can't see how this was correct >> for SVM. >> >> The real reason for finally getting around to this is the number of MISRA >> violations reported by the eclair-x86_64-allcode job that I don't feel like >> fixing. >> --- >> CHANGELOG.md | 3 + >> docs/misc/xen-command-line.pandoc | 6 - >> tools/flask/policy/modules/dom0.te | 2 - >> xen/arch/x86/Makefile | 1 - >> xen/arch/x86/cpu/vpmu_amd.c | 7 - >> xen/arch/x86/cpu/vpmu_intel.c | 6 - >> xen/arch/x86/hvm/svm/entry.S | 1 - >> xen/arch/x86/hvm/svm/svm.c | 2 - >> xen/arch/x86/hvm/vmx/vmx.c | 9 - >> xen/arch/x86/include/asm/xenoprof.h | 95 --- >> xen/arch/x86/oprofile/Makefile | 6 - >> xen/arch/x86/oprofile/backtrace.c | 145 ---- >> xen/arch/x86/oprofile/nmi_int.c | 485 ------------ >> xen/arch/x86/oprofile/op_counter.h | 41 - >> xen/arch/x86/oprofile/op_model_athlon.c | 547 ------------- >> xen/arch/x86/oprofile/op_model_p4.c | 721 ----------------- >> xen/arch/x86/oprofile/op_model_ppro.c | 348 --------- >> xen/arch/x86/oprofile/op_x86_model.h | 58 -- >> xen/arch/x86/oprofile/xenoprof.c | 106 --- >> xen/arch/x86/traps.c | 4 - >> xen/common/Kconfig | 11 - >> xen/common/Makefile | 1 - >> xen/common/compat/xenoprof.c | 42 - >> xen/common/domain.c | 6 - >> xen/common/xenoprof.c | 977 ------------------------ >> xen/include/Makefile | 1 - >> xen/include/hypercall-defs.c | 6 - >> xen/include/public/xen.h | 2 +- >> xen/include/public/xenoprof.h | 2 +- >> xen/include/xen/sched.h | 3 - >> xen/include/xen/xenoprof.h | 49 -- >> xen/include/xsm/dummy.h | 7 - >> xen/include/xsm/xsm.h | 7 - >> xen/xsm/dummy.c | 2 - >> xen/xsm/flask/hooks.c | 35 - >> xen/xsm/flask/policy/access_vectors | 4 - >> 36 files changed, 5 insertions(+), 3743 deletions(-) >> delete mode 100644 xen/arch/x86/include/asm/xenoprof.h >> delete mode 100644 xen/arch/x86/oprofile/Makefile >> delete mode 100644 xen/arch/x86/oprofile/backtrace.c >> delete mode 100644 xen/arch/x86/oprofile/nmi_int.c >> delete mode 100644 xen/arch/x86/oprofile/op_counter.h >> delete mode 100644 xen/arch/x86/oprofile/op_model_athlon.c >> delete mode 100644 xen/arch/x86/oprofile/op_model_p4.c >> delete mode 100644 xen/arch/x86/oprofile/op_model_ppro.c >> delete mode 100644 xen/arch/x86/oprofile/op_x86_model.h >> delete mode 100644 xen/arch/x86/oprofile/xenoprof.c >> delete mode 100644 xen/common/compat/xenoprof.c >> delete mode 100644 xen/common/xenoprof.c >> delete mode 100644 xen/include/xen/xenoprof.h >> >> diff --git a/CHANGELOG.md b/CHANGELOG.md >> index 3aaf5986231c..1663f6878ef2 100644 >> --- a/CHANGELOG.md >> +++ b/CHANGELOG.md >> @@ -15,6 +15,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) >> - The cpuid_mask_* command line options for legacy AMD CPUs. These were >> deprecated in Xen 4.7 and noted not to work correctly with AMD CPUs from >> 2011 onwards. >> + - Xenoprofile support. Oprofile themselves removed support for Xen in 2014 >> + prior to the version 1.0 release, and there has been no development since >> + before then in Xen. > > LGTM: > Acked-by: Oleksii Kurochko # CHANGELOG.md > > Nit: It is necessary to drop the extra space before " Oprofile themselves...". Why would that be? See the other bullet point in context, which also uses a two blanks after the inner full stop. This is deliberate. Also - please trim your replies. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 06 09:31:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 09:31:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195926.1513799 (Exim 4.92) (envelope-from ) id 1vd3P1-0001DF-Gq; Tue, 06 Jan 2026 09:30:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195926.1513799; Tue, 06 Jan 2026 09:30: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 1vd3P1-0001D8-Co; Tue, 06 Jan 2026 09:30:59 +0000 Received: by outflank-mailman (input) for mailman id 1195926; Tue, 06 Jan 2026 09:30: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 1vd3P0-0001D2-5h for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 09:30:58 +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 66ed4aef-eae2-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 10:30:56 +0100 (CET) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-64b7318f1b0so1035273a12.2 for ; Tue, 06 Jan 2026 01:30:56 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6507b22c3absm1676847a12.0.2026.01.06.01.30.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 01:30:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 66ed4aef-eae2-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767691855; x=1768296655; 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=m5KiI2HFK3/MUDGhJ/NFBei7zgTAAsWpBROr01X7qlc=; b=dXMV5tDYQdpG0y7+phGTE5SnwkcFqA1nXieYe3JlpDGzgRsa+bCkRYLcZmICiKG63z C8o9+JQszmbDUmgOIXlsNE1dtzO42hp8pjSJKCXN1rQ1W/bDQXstJQBKnBTgMK5nkyrY n69hqg6nud7HWuL+F3ABS4l1DWszi6vr/8/5uxwjddx7cbqlTXUnSovOwaropTL9ozAv 8UVfhlv2ZsR7Byw1C1nYOMR1vVKkAaK1GCdOyAva0t15TjrvTMObPlFHuocV50UVfMEM +hweJ/Q5Ft7HNt8eik6s4dbBqGiph7Fi6vIAxAkrU+lhDoSyl0cdrYEfHHAPeg5W+Kby 2y5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767691855; x=1768296655; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=m5KiI2HFK3/MUDGhJ/NFBei7zgTAAsWpBROr01X7qlc=; b=Wh2+AZ4WnD5/pM7v88a40f662nO1ZzKI7/nx3c3vd9TdWN0lyDwHhB4TSeLlvcvI9z 7YyObpNNVnye3OJse8B8lMTmmz/U5MK2ftUfQ4CPVw+gBOll5hcppKHAmXL6j4uq0aGl 4VyN865sPi7XGQ43MPREl77Ds8gEAaIUTVpj78qoKM10WDswXAg+bKO9WsbvSGcg6r1y S1hfemIRCJpc2a3/w7gUdGEjcqSnvLlhN3WgcS9U8JBSAJoAF24tszs36EkYKwKVWw1a O6bIXk85iLUNSFKS2/+lSxVUDVdJ9A+5zmKX5kSwm0tsXyp1TQdS64+olBYG2Q4ecHIs GSNg== X-Forwarded-Encrypted: i=1; AJvYcCUITzdSAedwmv0JtaSBwnWcf5Tr6NT+TYO9zBeqd+O31OyJVD4zlhhMxXFckKqPkaLmTflvey1aZcQ=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw9R/q2sQHMHWZQI+w+4y0lXAwi5kO+M5i8WzGFGkIFNT9Jc8xJ Az9lqiNBPoGvllkUlkn2yYO/hWC5lFgjKWUmix4rlOxM9y4D348uPSWl X-Gm-Gg: AY/fxX4VPYZ5xrIhg8LsAQM/VydFhjXapCYvx0z3fexRrhwzouF++jt+Vz+W9tZA/7K XzDKKZXYlzuklUtYrJz1MnZ0glWv7jZJ6JYNRFZEKr6wzTtLh+tAY0AKBoRPkKE1MtQP8L1XOg6 Cf8Zd32yHRhFu3TLBW+tNWKyGhjpPyFfl476z7XBhc4lmbNugYCXVOXiYtuk+sazQKp3TzdBbE7 PsA0pGtEcn2e4iwvril4wkIAGoFkapB8PRAe0lzlzz3rgd8V/Njpoa/km2/+PYR1afAp/p+L/2f saLMrwjSDfwX46LN+pq6mqrMnN+j0Dbk1iKoxl4Zm8C2qScLOmynUsSaZ2RjtQP0G1AK0xALu7R QH+GC+hj7MxgEhVWjLLkLymV2QHOo98GAocwUldUr5lMD/f3jA1jy3Qte6I1+WkCg5Mt1FwxhxQ y0G/2VPgtgw6RjuphC6fsXRozaX+m9VVycU6psEQwSc8gbxyn1AyMTK3oQGKpRQ9s= X-Google-Smtp-Source: AGHT+IEPfu/TRVaqjz5eL2kvkOZ/4VUFm39SWutgAFFOyS8ihSWHrMhLvIVB3UzP8g3IgvDpR8hJGA== X-Received: by 2002:a05:6402:1ec7:b0:641:8a92:9338 with SMTP id 4fb4d7f45d1cf-65079561be4mr2110370a12.22.1767691855330; Tue, 06 Jan 2026 01:30:55 -0800 (PST) Message-ID: <6bbe1965-ff08-46dc-9e9c-215ca73f9f16@gmail.com> Date: Tue, 6 Jan 2026 10:30:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/1] xen/riscv: add RISC-V virtual SBI base extension support for guests To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <63a1aa58-f609-4bfe-b827-90c59e40a02d@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <63a1aa58-f609-4bfe-b827-90c59e40a02d@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/5/26 5:26 PM, Jan Beulich wrote: > On 30.12.2025 16:50, Oleksii Kurochko wrote: >> Add support of virtual SBI base extension calls for RISC-V guests, delegating >> hardware-specific queries to the underlying SBI and handling version and >> firmware ID queries directly. >> >> The changes include: >> 1. Define new SBI base extension function IDs (SBI_EXT_BASE_GET_MVENDORID, >> SBI_EXT_BASE_GET_MARCHID, SBI_EXT_BASE_GET_MIMPID). >> 2. Introduce XEN_SBI_VER_MAJOR, XEN_SBI_VER_MINOR for imeplenataion of >> SBI_EXT_BASE_GET_SPEC_VERSION. >> 4. Introduce SBI_XEN_IMPID to implement SBI_EXT_BASE_GET_IMP_ID. >> 5. Implement handling of SBI base extension functions, including version, >> firmware ID, and machine-specific queries. >> >> Signed-off-by: Oleksii Kurochko > Acked-by: Jan Beulich Thanks. > > Albeit with a question: > >> --- /dev/null >> +++ b/xen/arch/riscv/vsbi/base-extension.c >> @@ -0,0 +1,82 @@ >> + >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> + >> +#include >> +#include >> +#include >> + >> +#include >> +#include >> +#include >> + >> +/* Xen-controlled SBI version reported to guests */ >> +#define XEN_SBI_VER_MAJOR 0 >> +#define XEN_SBI_VER_MINOR 2 > Is it clear from whatever spec it is that is ... > >> +static int vsbi_base_ecall_handler(unsigned long eid, unsigned long fid, >> + struct cpu_user_regs *regs) >> +{ >> + int ret = 0; >> + struct sbiret sbi_ret; >> + >> + ASSERT(eid == SBI_EXT_BASE); >> + >> + switch ( fid ) >> + { >> + case SBI_EXT_BASE_GET_SPEC_VERSION: >> + regs->a1 = MASK_INSR(XEN_SBI_VER_MAJOR, SBI_SPEC_VERSION_MAJOR_MASK) | >> + XEN_SBI_VER_MINOR; >> + break; > ... implied here (it's ..._SPEC_VERSION after all) under what conditions the > version would need bumping and what effects this would have on existing (e.g. > migrating-in) guests? Recall that ... For example, sooner or later we will want to use the SBI DBCN (Debug Console Extension) for early debug output for guests, as it provides an API to work with strings instead of single characters. This will require bumping the SBI version to 2.0. I don’t think this should cause any migration issues. If a guest was fully booted and running with Xen SBI version 0.2, it would continue to use the legacy extension for early console output (or for hvc console which is using SBI calls in Linux for the moment). If the guest was still in the initialization stage (before SBI extensions were probed), it would simply use the newer SBI DBCN extension instead of the Legacy one. ~ Oleksii > >> + case SBI_EXT_BASE_GET_IMP_ID: >> + regs->a1 = SBI_XEN_IMPID; >> + break; >> + >> + case SBI_EXT_BASE_GET_IMP_VERSION: >> + regs->a1 = (xen_major_version() << 16) | xen_minor_version(); >> + break; >> + >> + case SBI_EXT_BASE_GET_MVENDORID: >> + case SBI_EXT_BASE_GET_MARCHID: >> + case SBI_EXT_BASE_GET_MIMPID: >> + if ( is_hardware_domain(current->domain) ) >> + { >> + sbi_ret = sbi_ecall(SBI_EXT_BASE, fid, 0, 0, 0, 0, 0, 0); >> + ret = sbi_ret.error; >> + regs->a1 = sbi_ret.value; >> + } >> + else >> + /* >> + * vSBI should present a consistent, virtualized view to guests. >> + * In particular, DomU-visible data must remain stable across >> + * migration and must not expose hardware-specific details. > ... what is being said here applies to other sub-functions as well. IOW it > looks to me as if the version reported needs to be a per-guest property. > > Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 06 09:36:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 09:36:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195935.1513809 (Exim 4.92) (envelope-from ) id 1vd3Ub-0001lx-2m; Tue, 06 Jan 2026 09:36:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195935.1513809; Tue, 06 Jan 2026 09:36:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd3Ua-0001lq-Vq; Tue, 06 Jan 2026 09:36:44 +0000 Received: by outflank-mailman (input) for mailman id 1195935; Tue, 06 Jan 2026 09:36:43 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd3UZ-0001lk-6m for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 09:36:43 +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 350c324a-eae3-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 10:36:41 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-47774d3536dso7105455e9.0 for ; Tue, 06 Jan 2026 01:36:41 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0e175csm3434024f8f.14.2026.01.06.01.36.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 01:36:40 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 350c324a-eae3-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767692201; x=1768297001; 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=lBXTGRE5HcDeLgIDuPEpao5sCLOV6JQ0v3radDtzHXc=; b=PCFYF18BnWKRKmi8jyZsg8JWTIdZUJGRE68jSH+yOPTNLS6jd+i5lbhJJXOVFBPCvL haJp7s5eGvEm4eiiktqymqYfWmJH2QBdxNaPmOAAonABDivbN/HFqswxbladrV5uk+y8 NxV5OX2s81vjNZ2FjFkKlpvDmzrbL0hY+N7U6wTIAAWZtNWj+p8VFJBReiz0XKu5NJCC nS+yFclW1tS/+6ASbYU0ut4LUCUkLNBv26ru0WKBmJygN8y27yMX3PLhZWrSNRjdD8xx cjwcMeWMA7ThWqgU011RQW88HdxhyKsKCcbLCDOidUgswIh7Pl87HO30ntz9J4xE+jaa jv9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767692201; x=1768297001; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=lBXTGRE5HcDeLgIDuPEpao5sCLOV6JQ0v3radDtzHXc=; b=FYn6dbd9P3CUvWEcEvr52V6pZhCZ1ng0TIxfyFbPia6e8cFuj3mxFnzGI3olnCjf84 O5hDCvTy/6HVQZ5tzIfTOYvEJOL4UXcDvnZFdLWQ1yHg4KSlt/UXE282iLwFZo68kEPl dIVEFsyAxN2RGzg6a5pANcy9aG8NMR1+MGKmlqiImFOZ3U+DBFyW0YHo/FSUufPV5jKe ISXyYi9Y6vbFfgDuUtLch9L8xH/S0p64A3mqHBdthWXEGQZYMqsL2dc8i7MzpE97gw2N zkeu8w4SKxHNlC7drlSnQwghbSd5uwbRB7dzClxW2ZEYM4DxDoibEdDjgUd5LWRnKSD8 Ku3A== X-Forwarded-Encrypted: i=1; AJvYcCVB90+jR5itMdpBtwCBBAOl6fihZ6eJ7PyoFVIo3M2F7jFqbE7HWDNzv0qmsdDHqo8iADpnYzYeb9Y=@lists.xenproject.org X-Gm-Message-State: AOJu0YwDxceRc5qqOJ7L/xJ62C9a+hrquL+MlvuiW5xJbSRAxbBa/lA+ u55b++ETUhnQpMNLKoLnd/pHP3EVi3igqfCPPNZiRjbPLaOMF+yeSHbUUV7f524KfPmTik7wJvo bQWU= X-Gm-Gg: AY/fxX50B1YGIZcs4NklumApY1uSTzPJVg0am9LnqjoGOo756FbsY2BkV1W2vcMokqv UzojVZ2TVh8t3QbbSkNLUHOOxrKIfJviwUPTakQJCl7KkR+ItrYWcwNG6mGBFKI2ACFSKxvgr1a jDZO5r4fVBGem6UJ05K3p76HxM+VIZjvAk4yiwiZ7yyN8ARAJGdvUNDXzNUgZMe4iViA2QjRWC/ AyuXRzXMLY5ePF4218Rr7Lbb66OrUUZ6zhXu3NCBaO08MnxShzMXhBVsFabeE2EaOwNEXSaXQd6 ZctTEu03yBJCTn8QyjCUSyJlkMvKzRm4ICFGAl1stS+txshBDni9+sf0XGqLo4Cheicq15gHxvS ZLmHp8iZ92ZeUZFGQ9VC1xm3bIlBBun00Qw/1uaVUw2YNelCQuRTL5BhU0foVjOcmPJxo3mcg6X +JryuvHPVHLLlue9ItUbWqIIzuVre7rgNf22+2EGo6sTgRgrTZuWPdowbVc//Oz+iCOJ3Bwq7b/ xJawPNkFEB3kQ== X-Google-Smtp-Source: AGHT+IGyxZINnobUJHzeiTqZeTjswJdiG6gOb3gsDkWxzrpTGomrFQWUdthTJuXfvw3UkyCeVkScNA== X-Received: by 2002:a05:600c:524f:b0:477:3fcf:368c with SMTP id 5b1f17b1804b1-47d7f616361mr27408265e9.9.1767692200933; Tue, 06 Jan 2026 01:36:40 -0800 (PST) Message-ID: <5d45bb91-4ef5-48ec-b1fd-4f186f46c0ad@suse.com> Date: Tue, 6 Jan 2026 10:36:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] x86/cpu-policy: enable build of fuzzing harness by default From: Jan Beulich To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , "xen-devel@lists.xenproject.org" References: <4a8f06b9-8210-487f-9dd7-e0221e2df9db@suse.com> Content-Language: en-US Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 22.12.2025 17:53, Jan Beulich wrote: > ... on x86, to make sure its bit-rotting can be limited at least a little. > > Signed-off-by: Jan Beulich > > --- a/tools/fuzz/Makefile > +++ b/tools/fuzz/Makefile > @@ -4,6 +4,7 @@ include $(XEN_ROOT)/tools/Rules.mk > SUBDIRS-y := > SUBDIRS-y += libelf > SUBDIRS-y += x86_instruction_emulator > +SUBDIRS-$(CONFIG_X86_64) += cpu-policy > > .PHONY: all clean distclean install uninstall > all clean distclean install uninstall: %: subdirs-% > As it turns out this causes build failures on Ubuntu (and only there, and only with gcc, which I don't understand): afl-policy-fuzzer.c: In function 'main': afl-policy-fuzzer.c:153:9: error: ignoring return value of 'fread', declared with attribute warn_unused_result [-Werror=unused-result] fread(cp, sizeof(*cp), 1, fp); ^ cc1: all warnings being treated as errors Given how the code uses calloc() up front I don't really see why evaluating the return value would actually be meaningful here, so I'm inclined to add a cast to void (provided that would make a difference, which I have yet to check). Opinions? Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 06 09:37:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 09:37:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195944.1513818 (Exim 4.92) (envelope-from ) id 1vd3Vl-0002PI-Br; Tue, 06 Jan 2026 09:37:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195944.1513818; Tue, 06 Jan 2026 09: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 1vd3Vl-0002PB-8p; Tue, 06 Jan 2026 09:37:57 +0000 Received: by outflank-mailman (input) for mailman id 1195944; Tue, 06 Jan 2026 09: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 1vd3Vk-00024N-Ov for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 09:37:56 +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 609d1fa4-eae3-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 10:37:54 +0100 (CET) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-b728a43e410so135348366b.1 for ; Tue, 06 Jan 2026 01:37:54 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a4d31e7sm182307666b.42.2026.01.06.01.37.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 01:37:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 609d1fa4-eae3-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767692274; x=1768297074; 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=lxL8KR51DQ0oQopH+6Hbg+17A0zcRfk1vzTAao2LITM=; b=Ix7/Xgxh05Y0srr8BgPmNcOWICb3DUgmEq4Nyz4i8J4q7rUoL/MQqpa+BGSv9aoBFP CgnOW87mYl+yHFJUYEsWvKIW9fz+O+r6nben1QBrxdVWrYIpU9C/K7arAKg31eVYvn5Z StrjSM8BMA5BuyJRrCFytN208czRm57dlOGMLr5NrLAcMZQ7ailA6zSPP/nLuyZIM8PD 4VDk74SF+pzGPzPBtfK69bHIS2oUbBx68Rhes5M74g8g9qqcZ5EmPZU29NjcGx+M6vTv N9mmVJXQWBLD43ISIjee28NC6HR2TVrin1RQjMSjRwFYvDAO0qVPEZ5veV2g48CuuDfi JGxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767692274; x=1768297074; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lxL8KR51DQ0oQopH+6Hbg+17A0zcRfk1vzTAao2LITM=; b=evidT/STiMJelsTkpHGVmCdzRSoWqMZsd+HnGK40dMRoupMzZbTMSaQtE0lBDvbzh6 pq3q5JB78ZNT3WVfTI9NxPBipP819yjvnhHhEqFepkqajcSP6laETn/9aWT5xuRTqElD jW7KPoqg5sYbpFXFumgDVNrHMbPy6xsnN6uSDLoAwhz6Bc8DErV/SS70fovU/k+hDBku G4KATLoT5emys397M8zoJZ6ERZRcc/UVmFVPGKWj/PbEksbPFtyJKZHZcuR6T7w4/yiG p4mn4Ls+Yz/gGtWMCwxWKT4d1ZQnc1qA49ZOnwEl9bhz4zpNsl81K1wZXjGWuT+gSZgU krFw== X-Forwarded-Encrypted: i=1; AJvYcCWx/riF+rvr9xLvAJ8MPmkZRd3WfSc/nHDT90cyPcCFsPAcf0mRNHG8NeF8T+Fejie2v9PiswZqMJ4=@lists.xenproject.org X-Gm-Message-State: AOJu0YwgtK2pPk1+hX2p3K/afUGut3Rhgkhsf0EqIuk1lR+L7zQ2e3z5 vwlodxyug9iUSxiIqfn4bCb8rZFP45E9weH3zsFmLTjzGJPwcBAtq/s1 X-Gm-Gg: AY/fxX75nIKaU6RVlPwr/dB6jnDKQdhX5vMxxXQxN/uilQNY/f5JJNtzww85tWO6FOX BxsACG6Sxb9YjFf/twxMNsqOuG1Frw0qtmG4BH8hO0NPXgqW6/mJm4omxdgzkvtjEGTX0ktWq8i qT29EISDCyu2tnZRgjhn2mhdvDMADafMfe20XIGABYAsrvSkUoESfUuqlRXPe+gq9DW2a16HNlt taXS3LYOYPiMdYVxkbSmDNLSsYbQNXRQ/f3yfgtCQIjYeXucFEa5exWEgp4XS5PhVIm0Wjn8Gfx 7ohwWGuYenA169GZI8iRJ8DxB9Ba1ayYnODwpIO4ZbSd3GBvZrqnrA5P9oByWO77ypsoVt1VD33 hIuv2i2AhYGa505xReuyqXxnn8MSjwDwC0K9DWhRUcj2BhoXAqywySAaD1fpE3SObbDXYhjaxIG WtTSlm2n/A+9p65aPWkEKUmhaXzJAFT9R9lX1JMKHq3NZiVmvQ7GIAMG15Ny3/EiQ= X-Google-Smtp-Source: AGHT+IHy7gB7FInof//tCEI+P/oCC7nIrId1JGSsJUOGQYF+fyUl78GcF9XI/ZSqUr2uiDm8vrCGjA== X-Received: by 2002:a17:907:3f96:b0:b83:3770:a0e4 with SMTP id a640c23a62f3a-b8426be68f7mr249627266b.34.1767692274213; Tue, 06 Jan 2026 01:37:54 -0800 (PST) Message-ID: <10a38a49-c19a-4bca-8616-1490c3ef6a57@gmail.com> Date: Tue, 6 Jan 2026 10:37:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen: Drop xenoprofile support To: Jan Beulich Cc: Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P . Smith" , Andrew Cooper , Xen-devel References: <20260105195717.601500-1-andrew.cooper3@citrix.com> <724e78ef-b6ed-40db-a5c0-bd6473b6fe16@gmail.com> <8561e1dd-492b-4d51-bf10-0a4523c941a8@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <8561e1dd-492b-4d51-bf10-0a4523c941a8@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/6/26 9:53 AM, Jan Beulich wrote: > On 06.01.2026 09:43, Oleksii Kurochko wrote: >> On 1/5/26 8:57 PM, Andrew Cooper wrote: >>> The most recent xenoprof change was 300ef0cb4fde ("x86: Add Xenoprofile >>> support for AMD Family16h") in 2013, despite there being 42 changes worth of >>> other cleanup/rearranging since then. >>> >>> Oprofile themselves dropped Xen support in commit 0c142c3a096d ("Remove >>> opcontrol and the GUI and processor models dependent on it") in 2014, as part >>> of releasing version 1.0 and switching over to using operf based on the Linux >>> perf_event subsystem. Linux's version of this patch was merged in commit >>> 24880bef417f ("Merge tag 'oprofile-removal-5.12'") in 2021. >>> >>> Drop xenoprof and all supporting infrastructure, including the hypercall, the >>> XSM hook and flask vectors which lose their only caller, and even shrinks >>> struct domain by one pointer which wasn't properly excluded in >>> !CONFIG_XENOPROF builds. >>> >>> Retain the public xenoprof.h header as it is ABI, but note that the >>> functionality is removed. >>> >>> 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: Daniel P. Smith >>> >>> Despite appearing to be architecture neutral, the internals of Xenoprof were >>> entirely x86-specific. Another curiosity is that only the VMX MSR hooks >>> called passive_domain_do_{rd,wr}msr(), and I can't see how this was correct >>> for SVM. >>> >>> The real reason for finally getting around to this is the number of MISRA >>> violations reported by the eclair-x86_64-allcode job that I don't feel like >>> fixing. >>> --- >>> CHANGELOG.md | 3 + >>> docs/misc/xen-command-line.pandoc | 6 - >>> tools/flask/policy/modules/dom0.te | 2 - >>> xen/arch/x86/Makefile | 1 - >>> xen/arch/x86/cpu/vpmu_amd.c | 7 - >>> xen/arch/x86/cpu/vpmu_intel.c | 6 - >>> xen/arch/x86/hvm/svm/entry.S | 1 - >>> xen/arch/x86/hvm/svm/svm.c | 2 - >>> xen/arch/x86/hvm/vmx/vmx.c | 9 - >>> xen/arch/x86/include/asm/xenoprof.h | 95 --- >>> xen/arch/x86/oprofile/Makefile | 6 - >>> xen/arch/x86/oprofile/backtrace.c | 145 ---- >>> xen/arch/x86/oprofile/nmi_int.c | 485 ------------ >>> xen/arch/x86/oprofile/op_counter.h | 41 - >>> xen/arch/x86/oprofile/op_model_athlon.c | 547 ------------- >>> xen/arch/x86/oprofile/op_model_p4.c | 721 ----------------- >>> xen/arch/x86/oprofile/op_model_ppro.c | 348 --------- >>> xen/arch/x86/oprofile/op_x86_model.h | 58 -- >>> xen/arch/x86/oprofile/xenoprof.c | 106 --- >>> xen/arch/x86/traps.c | 4 - >>> xen/common/Kconfig | 11 - >>> xen/common/Makefile | 1 - >>> xen/common/compat/xenoprof.c | 42 - >>> xen/common/domain.c | 6 - >>> xen/common/xenoprof.c | 977 ------------------------ >>> xen/include/Makefile | 1 - >>> xen/include/hypercall-defs.c | 6 - >>> xen/include/public/xen.h | 2 +- >>> xen/include/public/xenoprof.h | 2 +- >>> xen/include/xen/sched.h | 3 - >>> xen/include/xen/xenoprof.h | 49 -- >>> xen/include/xsm/dummy.h | 7 - >>> xen/include/xsm/xsm.h | 7 - >>> xen/xsm/dummy.c | 2 - >>> xen/xsm/flask/hooks.c | 35 - >>> xen/xsm/flask/policy/access_vectors | 4 - >>> 36 files changed, 5 insertions(+), 3743 deletions(-) >>> delete mode 100644 xen/arch/x86/include/asm/xenoprof.h >>> delete mode 100644 xen/arch/x86/oprofile/Makefile >>> delete mode 100644 xen/arch/x86/oprofile/backtrace.c >>> delete mode 100644 xen/arch/x86/oprofile/nmi_int.c >>> delete mode 100644 xen/arch/x86/oprofile/op_counter.h >>> delete mode 100644 xen/arch/x86/oprofile/op_model_athlon.c >>> delete mode 100644 xen/arch/x86/oprofile/op_model_p4.c >>> delete mode 100644 xen/arch/x86/oprofile/op_model_ppro.c >>> delete mode 100644 xen/arch/x86/oprofile/op_x86_model.h >>> delete mode 100644 xen/arch/x86/oprofile/xenoprof.c >>> delete mode 100644 xen/common/compat/xenoprof.c >>> delete mode 100644 xen/common/xenoprof.c >>> delete mode 100644 xen/include/xen/xenoprof.h >>> >>> diff --git a/CHANGELOG.md b/CHANGELOG.md >>> index 3aaf5986231c..1663f6878ef2 100644 >>> --- a/CHANGELOG.md >>> +++ b/CHANGELOG.md >>> @@ -15,6 +15,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) >>> - The cpuid_mask_* command line options for legacy AMD CPUs. These were >>> deprecated in Xen 4.7 and noted not to work correctly with AMD CPUs from >>> 2011 onwards. >>> + - Xenoprofile support. Oprofile themselves removed support for Xen in 2014 >>> + prior to the version 1.0 release, and there has been no development since >>> + before then in Xen. >> LGTM: >> Acked-by: Oleksii Kurochko # CHANGELOG.md >> >> Nit: It is necessary to drop the extra space before " Oprofile themselves...". > Why would that be? See the other bullet point in context, which also uses a > two blanks after the inner full stop. This is deliberate. I just missed that a similar case was mentioned above. If this is deliberate, then I’m fine with it. It’s just not obvious (at least, for me) where it’s acceptable and where it isn’t to have extra spaces. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Jan 06 09:49:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 09:49:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195959.1513829 (Exim 4.92) (envelope-from ) id 1vd3go-0004E9-DM; Tue, 06 Jan 2026 09:49:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195959.1513829; Tue, 06 Jan 2026 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 1vd3go-0004E2-AP; Tue, 06 Jan 2026 09:49:22 +0000 Received: by outflank-mailman (input) for mailman id 1195959; Tue, 06 Jan 2026 09:49:21 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd3gn-0004Dw-0f for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 09:49:21 +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 f872b88f-eae4-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 10:49:19 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-432755545fcso416052f8f.1 for ; Tue, 06 Jan 2026 01:49:19 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5df9c5sm3483453f8f.22.2026.01.06.01.49.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 01:49:18 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f872b88f-eae4-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767692958; x=1768297758; 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=+vMmsVSuC+yn89Hk8vSUEwtja6nNc0uUwda/2UTby9w=; b=GWNwIp8V3WloyDNIRUpfn8zjWA81tICVx3OB0tH663TZwrHZUYIHP7MJC5F4cURApx 4I62oseX357HJRdPZiEo9Y5LNYA7G8GPwaqlmgvrvJqpvs96o3CjnC1z9XlDJ/okWaPp nDhVnCkcpse8Q9IxNxPtKqvLbhDly12zMfCLj892FAF3rAKOBVqZqX4TWkBBvCAndxf1 +odDErQtzhpyUFuYAwiQltiRnKE9bktSZUIH2ICZwHtfYJjTHTwy4qYdyjFRsFS/3XMT /obFZ9QEHJLl2HYbaddVGii27ScyXPjS7X9KuEouYDWl8XGEg6VxAqBn9dkfQFpcnWza 21dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767692958; x=1768297758; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+vMmsVSuC+yn89Hk8vSUEwtja6nNc0uUwda/2UTby9w=; b=klDTt2YdgQ8nmeeqaOZS+hmWwD9tYwxWiAqbeYWPGItdu9D4T4rNMDoQ4vvtUB6/mz 8TLOxTV+OIyCgqGk0dgvtnLEtiDEeCu9racpbYM8eJMBFG28XpSvld1Bui61TTWAG4GQ M0UYi3QYkRi1JSdKXRUpjoEivXvkO+05qGHdMotIHGv0gVQm1PSiD3gtEMG1H9DSWaVA Tn4fOqnBX2MQvnVrwBLtkxmj8uhbthEaBnpDCZuKnk+1zEu/g78iNOEoBi22VLNc6/Af tlf8LYCYP9igx99Jd4LP2SfGr2LbtbmyOp22llo85HIw8yHuJacqiUDpsEWDgPTEg7r5 XnHw== X-Forwarded-Encrypted: i=1; AJvYcCUwNRIXJ6+CVqjMkmDIs80Y1III5QB5K55iU8ytnURpPUEk3gO1VIFYrfjj4OBLfrKcLL2jL6d3MFw=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxjv5FjUda3LQko1zX7HIurvBOjEBowpGbrSWuaZ5IWm0dPRXDK tSJGPc0bBaylH1e5Werr8NxQpFBjDx76cMXGd2SbIqh37dia9pUEiOHBQ2DHHYm36g== X-Gm-Gg: AY/fxX4AMrmqkyEAMh9e/JupHSr2xHdJ729vLFPzJyroC6h091w+XHRu/dR9uUOufJg wPossrW1wfldTEb/r1AD0VaL2yf390p8MGLinfZ8+SBbgjDMk1BVeLnA0LZ5shhQknAqLNuSqQJ paI4+kibUmRK5nXvnyOGvdHFi4KEJcYKfqTH/aXQ9XkdA6xWqOCsok8NYFdYI+nuAI8+5uY5hzj kvncVba79dHC9IRa8u9iKkWvxuBsp4WKIDD6wp0RFVE421Xo764Umsp3TO+Zd9kuobyVRKbKJde 1b8MksOQlHKpdMpIej+7ZtWwqG2y4yO88I761WK7ZWi3Dyv+NhTMYMWkwWZl2ZJBM0mpRBbafrC WD3mKenD/7eCn3lgx67TZ3DNkRAohqZkskmdKwglPadLfi6mY+TQrOPs8jkQOm0f5KNhnSzdEnH yVVyhrEiL/wjjigjAdCXYEbuqVe9Obl3wKTbeRSP+5ukrxZf88VjhKKjWC3UXRU1OWYkkpm43ef YwerJoWt8CdiQ== X-Google-Smtp-Source: AGHT+IFC2tpwjRtu/k6J7abAHD2okAAossK0/k1+oXSVftAygmXOCe4lUlkwgjKh4eiv/SMhfjQiyQ== X-Received: by 2002:a05:6000:40ce:b0:430:f718:2388 with SMTP id ffacd0b85a97d-432bca2c3efmr2606539f8f.8.1767692958475; Tue, 06 Jan 2026 01:49:18 -0800 (PST) Message-ID: <19ae296c-5ea0-46ce-9107-8d212c065257@suse.com> Date: Tue, 6 Jan 2026 10:49:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] x86/cpu-policy: enable build of fuzzing harness by default From: Jan Beulich To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , "xen-devel@lists.xenproject.org" References: <4a8f06b9-8210-487f-9dd7-e0221e2df9db@suse.com> <5d45bb91-4ef5-48ec-b1fd-4f186f46c0ad@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: <5d45bb91-4ef5-48ec-b1fd-4f186f46c0ad@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 06.01.2026 10:36, Jan Beulich wrote: > On 22.12.2025 17:53, Jan Beulich wrote: >> ... on x86, to make sure its bit-rotting can be limited at least a little. >> >> Signed-off-by: Jan Beulich >> >> --- a/tools/fuzz/Makefile >> +++ b/tools/fuzz/Makefile >> @@ -4,6 +4,7 @@ include $(XEN_ROOT)/tools/Rules.mk >> SUBDIRS-y := >> SUBDIRS-y += libelf >> SUBDIRS-y += x86_instruction_emulator >> +SUBDIRS-$(CONFIG_X86_64) += cpu-policy >> >> .PHONY: all clean distclean install uninstall >> all clean distclean install uninstall: %: subdirs-% >> > > As it turns out this causes build failures on Ubuntu (and only there, and only > with gcc, which I don't understand): > > afl-policy-fuzzer.c: In function 'main': > afl-policy-fuzzer.c:153:9: error: ignoring return value of 'fread', declared with attribute warn_unused_result [-Werror=unused-result] > fread(cp, sizeof(*cp), 1, fp); > ^ > cc1: all warnings being treated as errors > > Given how the code uses calloc() up front I don't really see why evaluating > the return value would actually be meaningful here, so I'm inclined to add a > cast to void (provided that would make a difference, which I have yet to > check). Opinions? Simply casting doesn't work. Hence what I'm intending to do is --- a/tools/fuzz/cpu-policy/afl-policy-fuzzer.c +++ b/tools/fuzz/cpu-policy/afl-policy-fuzzer.c @@ -133,6 +133,7 @@ int main(int argc, char **argv) #endif { struct cpu_policy *cp = NULL; + size_t size; if ( fp != stdin ) { @@ -150,9 +151,9 @@ int main(int argc, char **argv) if ( !cp ) goto skip; - fread(cp, sizeof(*cp), 1, fp); + size = fread(cp, sizeof(*cp), 1, fp); - if ( !feof(fp) ) + if ( !size || !feof(fp) ) goto skip; check_policy(cp); along with amending the description: "Since on Ubuntu fread()'s return value needs evaluating, adjust the code there to also skip the test when there's no data at all." May I keep your ack with that adjustment? Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 06 09:55:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 09:55:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195968.1513838 (Exim 4.92) (envelope-from ) id 1vd3ms-0005kC-18; Tue, 06 Jan 2026 09:55:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195968.1513838; Tue, 06 Jan 2026 09:55:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd3mr-0005k5-UN; Tue, 06 Jan 2026 09:55:37 +0000 Received: by outflank-mailman (input) for mailman id 1195968; Tue, 06 Jan 2026 09: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 1vd3mq-0005jz-9S for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 09:55:36 +0000 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [2a00:1450:4864:20::32e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d7c39dcc-eae5-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 10:55:33 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-47d3ffb0f44so4809945e9.3 for ; Tue, 06 Jan 2026 01:55:33 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7fb5b246sm13959195e9.18.2026.01.06.01.55.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 01:55:32 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d7c39dcc-eae5-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767693333; x=1768298133; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Gpvm82FPEXt9e5XX+Tq+esnYxOTnUKZ6E3gFo+R7kjI=; b=b0VVdWyAsblawRvHakhdtREG0pae9JLz1R3izTqjjRcVynOjL11WZod7knAm+7Kj5k dKCWVuz7jWGovPW6i7h06a3egOb2n8KLatGaYM5LdXKrRXskjHfwp60+gaEoOqgTACju OEWV9A5lZQnGwwGWLSXVyrCNQUVqbChg6DcpGq2J3cih5qQIYXlNH1u3V3fJflBIt7ti ei1Niayy4QTFQRJi5nVivQpCvkZzTkMYgzl2RbnyJAQfTjWkvlULQ7bpC+WkzZpZjytV F06MgxvreEkdUQk451pd0BckuVl96gC0K6qWQclyDkcY0AHCABVYuewR0YfhtqYJCOxn rn7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767693333; x=1768298133; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Gpvm82FPEXt9e5XX+Tq+esnYxOTnUKZ6E3gFo+R7kjI=; b=jMTLBzOwJ7sGyO+jZuXvhC1s3ZYmoH9wyb5rHC6BESFWAw/Z5PSQPdY8GkERWv1i/A Ac8Y1LAy380frEWZznGByA6S4ijEQllsXy+FwgQqTn3HzYBguRxOfbHfjqwfq6NdAAWy EzPd+PBl00zz/C3a5yYuvQWxmo1ItW5Cpvcfn7N6r7gTtzB2Zv9XlxKAfXjnVSkQn19p K1AsLWj/EKym6XFTuFmeMeHhRTQDOA/wz9llS+pfvUKFeHp34ujLsSW4owpMzbo4WNRp l9H6GbDw2FD05Gb9R7dUdOooFoBEKXMvZ4hcxa2rja9qRhMmiJSUuFmnPwGdYUBKp0E3 KR7A== X-Forwarded-Encrypted: i=1; AJvYcCWBdAEfuAyQEYutKiuel3rVurxD85AfVDbkebdolcduF3C3lR8v/CD5SEuy7aZUVz6Wkrzp7iuoBMA=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw42xPh0xLAopJ8B9SSTbBohwKicqhFBIPxLIv+EpoNXALYUxpr YW4w8CbyuR8XhDj5DrZBhWrDqZYvi2PF/xCZwDsAQk0iLv44O9DsdFdoo8/OGN0bLw== X-Gm-Gg: AY/fxX6IDiX3sh2O88CHKZA8WT4Ud2uKe0z+XCGKY2ec5vEd1DA572gg7RgAS75o3Ew NH51d0SybfcaOPc+MCGp3vZ+arD1pmDc/kUbbStN3G9sCYlmVTSeWxbJ8FwB2eIpoEx01nkB6/v N77cLV046NyEgDix6+e7V6LQ+aP0eH8cVosEdErlL5mBrbo9ZC6IOJUewnsHNYuEAi9WcgobtrQ 9bghDn6tnuRDEZdDnV6+PNjLOfP913c4T4RfXOE2pUrEAn+h8ByhdQV0mWzzYPBJMMtELENf7yP Sa0p/x+JW/+3XY+FgPMLv8GixjqR0CVzmE8srywH8iXCWVAH2yejw9Lfy1ZL3cXXPXKst6rOjVu DpVLFnei1DSl8iDPD1oYATE73o6EK/zenv+MowHjfxhGjnJbVg6Rflz0NMa5NltRSie0W3Qpe6Z F4dsUGqNtBwzq7/v5SPI4tbMU1uaHR7jAPGOnD35HKU6m6obTaWQoWOb3fh9r+ozBnyN5qsUIHE Ds= X-Google-Smtp-Source: AGHT+IHdV8x8zlhDAqO0qJm6N0sa0i81lW9i5VSx/iLSJI+kd+D91uHMyzTXoV+dvhBYNKX+5VTEwg== X-Received: by 2002:a05:600c:3f14:b0:477:89d5:fdac with SMTP id 5b1f17b1804b1-47d7f09ffcbmr31724265e9.31.1767693333134; Tue, 06 Jan 2026 01:55:33 -0800 (PST) Message-ID: Date: Tue, 6 Jan 2026 10:55:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/1] xen/riscv: add RISC-V virtual SBI base extension support for guests To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <63a1aa58-f609-4bfe-b827-90c59e40a02d@suse.com> <6bbe1965-ff08-46dc-9e9c-215ca73f9f16@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: <6bbe1965-ff08-46dc-9e9c-215ca73f9f16@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06.01.2026 10:30, Oleksii Kurochko wrote: > On 1/5/26 5:26 PM, Jan Beulich wrote: >> On 30.12.2025 16:50, Oleksii Kurochko wrote: >>> Add support of virtual SBI base extension calls for RISC-V guests, delegating >>> hardware-specific queries to the underlying SBI and handling version and >>> firmware ID queries directly. >>> >>> The changes include: >>> 1. Define new SBI base extension function IDs (SBI_EXT_BASE_GET_MVENDORID, >>> SBI_EXT_BASE_GET_MARCHID, SBI_EXT_BASE_GET_MIMPID). >>> 2. Introduce XEN_SBI_VER_MAJOR, XEN_SBI_VER_MINOR for imeplenataion of >>> SBI_EXT_BASE_GET_SPEC_VERSION. >>> 4. Introduce SBI_XEN_IMPID to implement SBI_EXT_BASE_GET_IMP_ID. >>> 5. Implement handling of SBI base extension functions, including version, >>> firmware ID, and machine-specific queries. >>> >>> Signed-off-by: Oleksii Kurochko >> Acked-by: Jan Beulich > > Thanks. > >> Albeit with a question: >> >>> --- /dev/null >>> +++ b/xen/arch/riscv/vsbi/base-extension.c >>> @@ -0,0 +1,82 @@ >>> + >>> +/* SPDX-License-Identifier: GPL-2.0-only */ >>> + >>> +#include >>> +#include >>> +#include >>> + >>> +#include >>> +#include >>> +#include >>> + >>> +/* Xen-controlled SBI version reported to guests */ >>> +#define XEN_SBI_VER_MAJOR 0 >>> +#define XEN_SBI_VER_MINOR 2 >> Is it clear from whatever spec it is that is ... >> >>> +static int vsbi_base_ecall_handler(unsigned long eid, unsigned long fid, >>> + struct cpu_user_regs *regs) >>> +{ >>> + int ret = 0; >>> + struct sbiret sbi_ret; >>> + >>> + ASSERT(eid == SBI_EXT_BASE); >>> + >>> + switch ( fid ) >>> + { >>> + case SBI_EXT_BASE_GET_SPEC_VERSION: >>> + regs->a1 = MASK_INSR(XEN_SBI_VER_MAJOR, SBI_SPEC_VERSION_MAJOR_MASK) | >>> + XEN_SBI_VER_MINOR; >>> + break; >> ... implied here (it's ..._SPEC_VERSION after all) under what conditions the >> version would need bumping and what effects this would have on existing (e.g. >> migrating-in) guests? Recall that ... > > For example, sooner or later we will want to use the SBI DBCN (Debug Console > Extension) for early debug output for guests, as it provides an API to work with > strings instead of single characters. This will require bumping the SBI version > to 2.0. I fear there's a misunderstanding here, likely on my side: Why would it be 2.0? Didn't you say the version is Xen controlled? If so, why not 0.3 or 1.0? Contrary to what you said previously, it now looks to me as if the version wasn't "Xen-controlled", but instead what we pick reflects functionality required by a particular spec version of a spec we do not control. That's "SBI version implemented by Xen" to me though, not really a "Xen-controlled" version. Jan > I don’t think this should cause any migration issues. If a guest was fully booted > and running with Xen SBI version 0.2, it would continue to use the legacy extension > for early console output (or for hvc console which is using SBI calls in Linux for > the moment). If the guest was still in the initialization stage (before SBI > extensions were probed), it would simply use the newer SBI DBCN extension instead > of the Legacy one. > > ~ Oleksii > >> >>> + case SBI_EXT_BASE_GET_IMP_ID: >>> + regs->a1 = SBI_XEN_IMPID; >>> + break; >>> + >>> + case SBI_EXT_BASE_GET_IMP_VERSION: >>> + regs->a1 = (xen_major_version() << 16) | xen_minor_version(); >>> + break; >>> + >>> + case SBI_EXT_BASE_GET_MVENDORID: >>> + case SBI_EXT_BASE_GET_MARCHID: >>> + case SBI_EXT_BASE_GET_MIMPID: >>> + if ( is_hardware_domain(current->domain) ) >>> + { >>> + sbi_ret = sbi_ecall(SBI_EXT_BASE, fid, 0, 0, 0, 0, 0, 0); >>> + ret = sbi_ret.error; >>> + regs->a1 = sbi_ret.value; >>> + } >>> + else >>> + /* >>> + * vSBI should present a consistent, virtualized view to guests. >>> + * In particular, DomU-visible data must remain stable across >>> + * migration and must not expose hardware-specific details. >> ... what is being said here applies to other sub-functions as well. IOW it >> looks to me as if the version reported needs to be a per-guest property. >> >> Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 06 10:17:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 10:17:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195977.1513850 (Exim 4.92) (envelope-from ) id 1vd48G-0000Tt-OW; Tue, 06 Jan 2026 10:17:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195977.1513850; Tue, 06 Jan 2026 10:17: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 1vd48G-0000Tl-In; Tue, 06 Jan 2026 10:17:44 +0000 Received: by outflank-mailman (input) for mailman id 1195977; Tue, 06 Jan 2026 10:17: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 1vd48E-0000SE-RM for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 10:17:43 +0000 Received: from mail187-9.suw11.mandrillapp.com (mail187-9.suw11.mandrillapp.com [198.2.187.9]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id eda7efdb-eae8-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 11:17:39 +0100 (CET) Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail187-9.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4dlnD21WhpzK5vgM2 for ; Tue, 6 Jan 2026 10:17:38 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 87690f0c43da4feab2fe905a101f6203; Tue, 06 Jan 2026 10:17: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: eda7efdb-eae8-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1767694658; x=1767964658; bh=bsU2eUdwrfoDXp5ItDq8DJEDIz9Wl4CJVMm0N36WL8E=; 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=kkBcbENirjuN3QPZqnsVlv5KZe7yVpdBAYsoYQtlzLniJwRXpyIT8oPTwQEGgana0 FSHtTgL0JreQI9XfzznpjeJOeEdIaw6eAoSW8lLugOXq4fEMCszRqTkqd+oJoDezYD E5DkD7Ga5ePEXXRX157tuUWBO1n0zuAJYU5s+MFT6eN9chMxiqezjCnmjIpJOgvA91 +xdELVQLNYNM3dPcvS/6T3N5pAyHowr/dw3QDrZyrfcm3tiAL4wOmobhg7PNQJ63UF bY2sgyoZt3qU3dsrrqs5gy1ozExFYCgrJP9bc2Qu2+eIb9mi7LmvJVE7hB6QftY/eu ChOn67Dpw3uzA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1767694658; x=1767955158; i=teddy.astie@vates.tech; bh=bsU2eUdwrfoDXp5ItDq8DJEDIz9Wl4CJVMm0N36WL8E=; 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=GgdXkVMoiIPBZQ5hyIHIdCnTE5fKIEnbeM7cF0CjWIvJjlsdOWROnBGTO9IOcgVD/ 7+jBYPRGVV6kmTDA5lyTVOxBmT2TOgp87xEeLdPQgrRsTqYTzkw9zprQhlLDV0FkHi Qp1MDK1Huk60hjSSyKwH8x38cqPhklnLARptVsAC9F749SV1sCY3Czmpq9nq/WyfQu nmwW0YYoNzAf8b3+HXTx+SzTttpF9UAsRJHkD9a2saS4zmBsXcvuEqd/MrT/OUXZP8 6yaOBVK0LhtMxyigKezaQNjLXrL0ELG6F+gSNVtHo60f+Db9+vxveQqBUpZsqZC+uN l1HFqD4hQsddg== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH]=20xen:=20Drop=20xenoprofile=20support?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1767694656181 Message-Id: <03ede724-4b01-4a16-a23f-0bc2ed25efbf@vates.tech> To: "Andrew Cooper" , Xen-devel Cc: "Anthony PERARD" , "Michal Orzel" , "Jan Beulich" , "Julien Grall" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" , "Oleksii Kurochko" , "Daniel P . Smith" References: <20260105195717.601500-1-andrew.cooper3@citrix.com> In-Reply-To: <20260105195717.601500-1-andrew.cooper3@citrix.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.87690f0c43da4feab2fe905a101f6203?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260106:md Date: Tue, 06 Jan 2026 10:17:38 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 05/01/2026 =C3=A0 21:01, Andrew Cooper a =C3=A9crit=C2=A0: > The most recent xenoprof change was 300ef0cb4fde ("x86: Add Xenoprofile > support for AMD Family16h") in 2013, despite there being 42 changes worth= of > other cleanup/rearranging since then. > > Oprofile themselves dropped Xen support in commit 0c142c3a096d ("Remove > opcontrol and the GUI and processor models dependent on it") in 2014, as = part > of releasing version 1.0 and switching over to using operf based on the L= inux > perf_event subsystem. Linux's version of this patch was merged in commit > 24880bef417f ("Merge tag 'oprofile-removal-5.12'") in 2021. > > Drop xenoprof and all supporting infrastructure, including the hypercall,= the > XSM hook and flask vectors which lose their only caller, and even shrinks > struct domain by one pointer which wasn't properly excluded in > !CONFIG_XENOPROF builds. > > Retain the public xenoprof.h header as it is ABI, but note that the > functionality is removed. > > Signed-off-by: Andrew Cooper > --- > CC: Anthony PERARD > CC: Michal Orzel > CC: Jan Beulich > CC: Julien Grall > CC: Roger Pau Monn=C3=A9 > CC: Stefano Stabellini > CC: Oleksii Kurochko > CC: Daniel P. Smith > > Despite appearing to be architecture neutral, the internals of Xenoprof w= ere > entirely x86-specific. Another curiosity is that only the VMX MSR hooks > called passive_domain_do_{rd,wr}msr(), and I can't see how this was corre= ct > for SVM. > > The real reason for finally getting around to this is the number of MISRA > violations reported by the eclair-x86_64-allcode job that I don't feel li= ke > fixing. > --- > CHANGELOG.md | 3 + > docs/misc/xen-command-line.pandoc | 6 - > tools/flask/policy/modules/dom0.te | 2 - > xen/arch/x86/Makefile | 1 - > xen/arch/x86/cpu/vpmu_amd.c | 7 - > xen/arch/x86/cpu/vpmu_intel.c | 6 - > xen/arch/x86/hvm/svm/entry.S | 1 - > xen/arch/x86/hvm/svm/svm.c | 2 - > xen/arch/x86/hvm/vmx/vmx.c | 9 - > xen/arch/x86/include/asm/xenoprof.h | 95 --- > xen/arch/x86/oprofile/Makefile | 6 - > xen/arch/x86/oprofile/backtrace.c | 145 ---- > xen/arch/x86/oprofile/nmi_int.c | 485 ------------ > xen/arch/x86/oprofile/op_counter.h | 41 - > xen/arch/x86/oprofile/op_model_athlon.c | 547 ------------- > xen/arch/x86/oprofile/op_model_p4.c | 721 ----------------- > xen/arch/x86/oprofile/op_model_ppro.c | 348 --------- > xen/arch/x86/oprofile/op_x86_model.h | 58 -- > xen/arch/x86/oprofile/xenoprof.c | 106 --- > xen/arch/x86/traps.c | 4 - > xen/common/Kconfig | 11 - > xen/common/Makefile | 1 - > xen/common/compat/xenoprof.c | 42 - > xen/common/domain.c | 6 - > xen/common/xenoprof.c | 977 ------------------------ > xen/include/Makefile | 1 - > xen/include/hypercall-defs.c | 6 - > xen/include/public/xen.h | 2 +- > xen/include/public/xenoprof.h | 2 +- > xen/include/xen/sched.h | 3 - > xen/include/xen/xenoprof.h | 49 -- > xen/include/xsm/dummy.h | 7 - > xen/include/xsm/xsm.h | 7 - > xen/xsm/dummy.c | 2 - > xen/xsm/flask/hooks.c | 35 - > xen/xsm/flask/policy/access_vectors | 4 - > 36 files changed, 5 insertions(+), 3743 deletions(-) > delete mode 100644 xen/arch/x86/include/asm/xenoprof.h > delete mode 100644 xen/arch/x86/oprofile/Makefile > delete mode 100644 xen/arch/x86/oprofile/backtrace.c > delete mode 100644 xen/arch/x86/oprofile/nmi_int.c > delete mode 100644 xen/arch/x86/oprofile/op_counter.h > delete mode 100644 xen/arch/x86/oprofile/op_model_athlon.c > delete mode 100644 xen/arch/x86/oprofile/op_model_p4.c > delete mode 100644 xen/arch/x86/oprofile/op_model_ppro.c > delete mode 100644 xen/arch/x86/oprofile/op_x86_model.h > delete mode 100644 xen/arch/x86/oprofile/xenoprof.c > delete mode 100644 xen/common/compat/xenoprof.c > delete mode 100644 xen/common/xenoprof.c > delete mode 100644 xen/include/xen/xenoprof.h > > diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h > index 7f15204c3885..b12fd10e6315 100644 > --- a/xen/include/public/xen.h > +++ b/xen/include/public/xen.h > @@ -106,7 +106,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t); > #define __HYPERVISOR_nmi_op 28 > #define __HYPERVISOR_sched_op 29 > #define __HYPERVISOR_callback_op 30 > -#define __HYPERVISOR_xenoprof_op 31 > +#define __HYPERVISOR_xenoprof_op 31 /* Dropped in Xen 4.22 */ > #define __HYPERVISOR_event_channel_op 32 > #define __HYPERVISOR_physdev_op 33 > #define __HYPERVISOR_hvm_op 34 > diff --git a/xen/include/public/xenoprof.h b/xen/include/public/xenoprof.= h > index 2298b6759ed3..f97a67042e07 100644 > --- a/xen/include/public/xenoprof.h > +++ b/xen/include/public/xenoprof.h > @@ -3,7 +3,7 @@ > * xenoprof.h > * > * Interface for enabling system wide profiling based on hardware perfo= rmance > - * counters > + * counters. Dropped from Xen in 4.22. > * > * Copyright (C) 2005 Hewlett-Packard Co. > * Written by Aravind Menon & Jose Renato Santos Reviewed-by: Teddy Astie Some question: do we plan to drop xenoprof.h headers at some point (even if not today) ? 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 Jan 06 10:38:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 10:38:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1195991.1513859 (Exim 4.92) (envelope-from ) id 1vd4Rj-0003Vd-9m; Tue, 06 Jan 2026 10:37:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1195991.1513859; Tue, 06 Jan 2026 10:37:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd4Rj-0003VV-5t; Tue, 06 Jan 2026 10:37:51 +0000 Received: by outflank-mailman (input) for mailman id 1195991; Tue, 06 Jan 2026 10:37:49 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd4Rh-0003VN-90 for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 10:37:49 +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 be10a871-eaeb-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 11:37:47 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-47775fb6cb4so4727775e9.0 for ; Tue, 06 Jan 2026 02:37:47 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7faf4cb4sm14312935e9.8.2026.01.06.02.37.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 02:37:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: be10a871-eaeb-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767695867; x=1768300667; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=VnEJ4Cdq23DCIsrH4J2zeEbPVJtvH3fYuXPDQXd4JNA=; b=X6apKxPR7vNXPZ4hzzIJFbaOCemniwHyruu+/FOEl/pc/au35RRJWD5/sGtCxqz2QN 0itq9wzJ/3GINYyFb36iE0sh8bnDaWxhwXLeGvlW3rYsWs+jdn57XtSn4cV5aYM9k19b lv00VoIKmVQnoFmc6pBPndLuiA1fsgRyv9L2keDvUEyQMg5oyYOHmYgBWLv9nAUm6dyA i069W8nCR3Aof5II+hJaFuaQLctX33BaXgehzUsVBhDRBtX8iCM+1tXseDrBW5Ef51qp 5ggcpB7mtYUuCj6rBDjS/5bcbb021ai2mr5jJNSPDoPvF4dCr4Oc7RqzzC5/UMdqbI93 CdWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767695867; x=1768300667; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=VnEJ4Cdq23DCIsrH4J2zeEbPVJtvH3fYuXPDQXd4JNA=; b=BKUyh04IlpkpKGz6kYr/JIZqI5fMkxTR+V0IAGsc+xqwn3LmKLEaROdNifcDlXAmiu ftcBK6VpRBi3C50EFjzLsAv20wFdgl2NzIGfkT2fafFG7fz+LtEai/fh16v1iXn3OXhz 6tIWp5xKQ+iTwk7xN9MyLeh9tpFf6BLuO+Aah+hG830aObv2uZrYO13FQxoB/9XT6W4i n5URnOmwtcNVhbRWz7d0xqfTZQzCpiKT2hPocaJ1okDosjJn31cNR0sU8abWusigrQrk j3cdcAfypgTqp8J8j+NX1H/bWg584sl/d0q1lkroFK7Y+gBem9WuQ/a235bh0w8t7D/Y 1oqg== X-Forwarded-Encrypted: i=1; AJvYcCWOkbz3zgr70Tgi8u17TNsh3f5n4xR0ECk6wEwIfQIXvO/eS8rwRPOEw+OARCcKqY3p/bDxiISS0MQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YyU9O1mBADRSckbnw1zpOJqYAFwUVISJOyo4UDqD3JpIEfSYnkd eEGZCi5a4a6p60dZvQL9IPm3Yt/bGAuz9mgDrXfy0Ia4yKYV5b4+s3rNRgJQ91+wYQ== X-Gm-Gg: AY/fxX5ULLqLWNpTFAAh6k3tBRD+mzYTaA/2yG3sR9rZrkaO+5Z3fx3vAHvuaxyJalY URO33Gmh98CJzoWdzp1KlUu9tTCcKFrUVm60+6cMvf8ZftD9TwcJH4hRFJCWEYlXy+2rYq1beW6 5ZT0VSVFLTrj6Js9vgoDMVNZNNz2eyfMjQ9iaaZugOLsJcf9kiay+U9EBmQxtN8ZwKSR5Jaei2S GXv/KmWhyB6gf8+w5hvF/0mZy6yGNDoBhwPNvkRp9vTXTH/8cA0fAnxJbuRCZTEQNHJCVqO6T59 eZMByS0d3nqhFINz/tuvEZJ9ZA9963VwhQza+HABDSefUTpu5HQKMfyPlaFCmF7entV8vmnMJzt twCMMmL+o4MqkL/+45wJ8zEyOsvf6+duT3upeCA0+xMmtKiv+v347L/FS7Z+3YUJGJvlKCtDgjy Usxrl+WMAHur+xi3IOnwOgTN+Y6mEorWvUEjLxtAZ+Sldz7jSdcpfoO9cuc9w+ZpP5LaCrividX VQ= X-Google-Smtp-Source: AGHT+IEtwJ2t4LIpPE0qde7foCzF2lXC7ZeTUAbp8MfL3Gb94CtXhxMKRihl3Rwel+PFZfpuYtPlKg== X-Received: by 2002:a05:600c:45c3:b0:477:9cdb:e336 with SMTP id 5b1f17b1804b1-47d7f097784mr28452085e9.21.1767695867064; Tue, 06 Jan 2026 02:37:47 -0800 (PST) Message-ID: <1db4bfe3-c190-4dd0-aa3e-bcffa42ee120@suse.com> Date: Tue, 6 Jan 2026 11:37:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen: Drop xenoprofile support To: Teddy Astie Cc: Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Oleksii Kurochko , "Daniel P . Smith" , Andrew Cooper , Xen-devel References: <20260105195717.601500-1-andrew.cooper3@citrix.com> <03ede724-4b01-4a16-a23f-0bc2ed25efbf@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: <03ede724-4b01-4a16-a23f-0bc2ed25efbf@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 06.01.2026 11:17, Teddy Astie wrote: > Some question: do we plan to drop xenoprof.h headers at some point (even > if not today) ? I think we will want to keep the public header, to avoid breaking people's builds. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 06 10:41:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 10:41:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196000.1513868 (Exim 4.92) (envelope-from ) id 1vd4Vd-00050U-OM; Tue, 06 Jan 2026 10:41:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196000.1513868; Tue, 06 Jan 2026 10:41:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd4Vd-00050N-Lp; Tue, 06 Jan 2026 10:41:53 +0000 Received: by outflank-mailman (input) for mailman id 1196000; Tue, 06 Jan 2026 10:41: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 1vd4Vc-00050H-Uv for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 10:41:53 +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 4f0112fb-eaec-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 11:41:50 +0100 (CET) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-b727f452fffso412413466b.1 for ; Tue, 06 Jan 2026 02:41:50 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a51543fsm191522466b.55.2026.01.06.02.41.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 02:41:49 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4f0112fb-eaec-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767696110; x=1768300910; 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=/FTe9m+tOClIYe1qC/TkyZS0SAPAYTqJ/3osCXjap5Y=; b=nCrz/WCWZMn/Q9XMyjxGmMg6STNLBG2r5IaNR0yfl4clYAg4nc66Oxi+Ms5TnZg7G/ 3F6AxebURedCxbPbI3XuT3AMkXUEwtBZjDf4zLf5gVt0CTKm2pNXSXMc0JAYthJ9XadZ vx3rQm/YEBek2KzpZVCFrHwF/4LSLDS/3sYjyh7FE2U/lVxBHBzgmJbMJOI9qK21NrWN wegSqA6LC4kIM/wAsMazIp36RXxtAxNmDmoxNNZAuZ+6XhjVaE+/kwZcPje7vBf84si8 rnyH+7mk97buICCYahCHUWlcboKLvuZlrd5xlcqDLSN2XiTSYyFPYDUq4DGYGgap66WX /W7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767696110; x=1768300910; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/FTe9m+tOClIYe1qC/TkyZS0SAPAYTqJ/3osCXjap5Y=; b=X4uQo2BxdP1VDMfm0jqJHALuA/AizUEjVrf/1kCNsQBhWq3dY1rZaYhWF6S2J2QPgi SJFQfu7CxW7hi7AfCkLeybZULygXcnxKdjfzmch+bpFEfj0g0NSy24Ppk1SyKMilvGAl UPuMw5bDg11G2RKCwFtzqmlMEesszfUrW77tXMBHXOVompSZJo2CMX1jOUpf5ooIzV0b 37qIwISdpfo2PVnnrpxnp94YI9HMImBmfbt0qprw1cjY4vyNWkpSJKhMzEWVtEl3xY4j X6mBUS4Usz1Ml7Yjx7FYv/rMzR3bMP/zhqNCPnl0yunVl+uNqGtiTMyaBNnMPpBii0wT wRNA== X-Forwarded-Encrypted: i=1; AJvYcCWiFXJw1ooG7BZ4vpCT+6zmovwt7hi2ezUH6/jud2cfHqp6WNEvtWO7j8Jlbj+FPyR8KY7i/4mB5Gw=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy0j4dvyVCmmehJIgaT9duRwHjo14SQfOCq6697CzRQzz9En8Fi 8uzRKgGGNNldMjJshyeRpiUo8ssOrL6+/ZqWlvZGWzLFny4pAaJ3CSC4 X-Gm-Gg: AY/fxX5k7PhNNsFwaxRWQg3qDV93R6l3JdmAmfKoM81cZiOfHluwTWubJQihXlU9wbL kGXW+ujLS0U7EKsQFTD1FNmANktFP8qesVvKOGWvzOnk2hvxWaTGEWdGG8A20aKqzxcntvcmeUm Mz3G1q9fzFRF6GEVwWbjLWZjDCYwELDMwhElUG137iybPO3jbOnTXIZk61Vt5XDFH5oIEx6B13l 86RV+smH/G5PIDJ8PJBlvJFVB+yfFI0JdUZACgs0GcktpwAzxzqqGOW83pxyPSxNDJd1m7SWkz4 ylX3mvS3Y+sqvgusoydTIf9ZWK2uMWBDZrM9vNSVKDOD1E/iFFpUodC5wzLRutacqw1JQfltG05 S5okmL9OhqDpEFYtV3vZmPyxR/0l+jbcka4wXkwxmXpvLLD32IgDVOmChEaKxTP+dqMxt431bzT 7F7WZmUA/pUL6NKsBcC9Oq2Iv9Gzr6D4FxMfKhZB+qz2Gs6ho7K4EVLTjWt5PNN3k= X-Google-Smtp-Source: AGHT+IEPYDYiYjdLEn5HH9xuGeHUbcxplmWJdYHPJbCMz6E74+h7gmLC/QUgnDJSqIqqFJlWloTVow== X-Received: by 2002:a17:907:9413:b0:b72:b7cd:f59e with SMTP id a640c23a62f3a-b84298bddeamr212845066b.8.1767696109810; Tue, 06 Jan 2026 02:41:49 -0800 (PST) Message-ID: <78cb2186-1fa9-4ad1-9999-410beb34b71e@gmail.com> Date: Tue, 6 Jan 2026 11:41:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/1] xen/riscv: add RISC-V virtual SBI base extension support for guests To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <63a1aa58-f609-4bfe-b827-90c59e40a02d@suse.com> <6bbe1965-ff08-46dc-9e9c-215ca73f9f16@gmail.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 1/6/26 10:55 AM, Jan Beulich wrote: > On 06.01.2026 10:30, Oleksii Kurochko wrote: >> On 1/5/26 5:26 PM, Jan Beulich wrote: >>> On 30.12.2025 16:50, Oleksii Kurochko wrote: >>>> Add support of virtual SBI base extension calls for RISC-V guests, delegating >>>> hardware-specific queries to the underlying SBI and handling version and >>>> firmware ID queries directly. >>>> >>>> The changes include: >>>> 1. Define new SBI base extension function IDs (SBI_EXT_BASE_GET_MVENDORID, >>>> SBI_EXT_BASE_GET_MARCHID, SBI_EXT_BASE_GET_MIMPID). >>>> 2. Introduce XEN_SBI_VER_MAJOR, XEN_SBI_VER_MINOR for imeplenataion of >>>> SBI_EXT_BASE_GET_SPEC_VERSION. >>>> 4. Introduce SBI_XEN_IMPID to implement SBI_EXT_BASE_GET_IMP_ID. >>>> 5. Implement handling of SBI base extension functions, including version, >>>> firmware ID, and machine-specific queries. >>>> >>>> Signed-off-by: Oleksii Kurochko >>> Acked-by: Jan Beulich >> Thanks. >> >>> Albeit with a question: >>> >>>> --- /dev/null >>>> +++ b/xen/arch/riscv/vsbi/base-extension.c >>>> @@ -0,0 +1,82 @@ >>>> + >>>> +/* SPDX-License-Identifier: GPL-2.0-only */ >>>> + >>>> +#include >>>> +#include >>>> +#include >>>> + >>>> +#include >>>> +#include >>>> +#include >>>> + >>>> +/* Xen-controlled SBI version reported to guests */ >>>> +#define XEN_SBI_VER_MAJOR 0 >>>> +#define XEN_SBI_VER_MINOR 2 >>> Is it clear from whatever spec it is that is ... >>> >>>> +static int vsbi_base_ecall_handler(unsigned long eid, unsigned long fid, >>>> + struct cpu_user_regs *regs) >>>> +{ >>>> + int ret = 0; >>>> + struct sbiret sbi_ret; >>>> + >>>> + ASSERT(eid == SBI_EXT_BASE); >>>> + >>>> + switch ( fid ) >>>> + { >>>> + case SBI_EXT_BASE_GET_SPEC_VERSION: >>>> + regs->a1 = MASK_INSR(XEN_SBI_VER_MAJOR, SBI_SPEC_VERSION_MAJOR_MASK) | >>>> + XEN_SBI_VER_MINOR; >>>> + break; >>> ... implied here (it's ..._SPEC_VERSION after all) under what conditions the >>> version would need bumping and what effects this would have on existing (e.g. >>> migrating-in) guests? Recall that ... >> For example, sooner or later we will want to use the SBI DBCN (Debug Console >> Extension) for early debug output for guests, as it provides an API to work with >> strings instead of single characters. This will require bumping the SBI version >> to 2.0. > I fear there's a misunderstanding here, likely on my side: Why would it be 2.0? > Didn't you say the version is Xen controlled? If so, why not 0.3 or 1.0? I mentioned 2.0 because SBI DBCN support starts in SBI version 2.0 (2.0-rc2, to be more precise). If we use 0.3 or 1.0 instead, the guest won’t know [1][2] that it can use the SBI DBCN extension instead of the legacy extension. [1] https://elixir.bootlin.com/linux/v6.18.3/source/arch/riscv/kernel/sbi.c#L692 [2] https://elixir.bootlin.com/linux/v6.18.3/source/drivers/tty/hvc/hvc_riscv_sbi.c#L67 > > Contrary to what you said previously, it now looks to me as if the version > wasn't "Xen-controlled", but instead what we pick reflects functionality > required by a particular spec version of a spec we do not control. That's > "SBI version implemented by Xen" to me though, not really a "Xen-controlled" > version. I will update the comment above definitions of XEN_SBI_VER_MAJOR and XEN_SBI_VER_MINOR to: /* SBI version implemented by Xen and reported to guests */ ~ Oleksii >> I don’t think this should cause any migration issues. If a guest was fully booted >> and running with Xen SBI version 0.2, it would continue to use the legacy extension >> for early console output (or for hvc console which is using SBI calls in Linux for >> the moment). If the guest was still in the initialization stage (before SBI >> extensions were probed), it would simply use the newer SBI DBCN extension instead >> of the Legacy one. >> >> ~ Oleksii >> >>>> + case SBI_EXT_BASE_GET_IMP_ID: >>>> + regs->a1 = SBI_XEN_IMPID; >>>> + break; >>>> + >>>> + case SBI_EXT_BASE_GET_IMP_VERSION: >>>> + regs->a1 = (xen_major_version() << 16) | xen_minor_version(); >>>> + break; >>>> + >>>> + case SBI_EXT_BASE_GET_MVENDORID: >>>> + case SBI_EXT_BASE_GET_MARCHID: >>>> + case SBI_EXT_BASE_GET_MIMPID: >>>> + if ( is_hardware_domain(current->domain) ) >>>> + { >>>> + sbi_ret = sbi_ecall(SBI_EXT_BASE, fid, 0, 0, 0, 0, 0, 0); >>>> + ret = sbi_ret.error; >>>> + regs->a1 = sbi_ret.value; >>>> + } >>>> + else >>>> + /* >>>> + * vSBI should present a consistent, virtualized view to guests. >>>> + * In particular, DomU-visible data must remain stable across >>>> + * migration and must not expose hardware-specific details. >>> ... what is being said here applies to other sub-functions as well. IOW it >>> looks to me as if the version reported needs to be a per-guest property. >>> >>> Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 06 10:59:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 10:59:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196010.1513878 (Exim 4.92) (envelope-from ) id 1vd4mF-0006sW-3y; Tue, 06 Jan 2026 10:59:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196010.1513878; Tue, 06 Jan 2026 10:59:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd4mF-0006sP-1H; Tue, 06 Jan 2026 10:59:03 +0000 Received: by outflank-mailman (input) for mailman id 1196010; Tue, 06 Jan 2026 10:59: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 1vd4mD-0006sJ-LJ for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 10:59:01 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b3699dd6-eaee-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 11:58:59 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MN6PR03MB8006.namprd03.prod.outlook.com (2603:10b6:208:4ee::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Tue, 6 Jan 2026 10:58:55 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9478.005; Tue, 6 Jan 2026 10:58: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: b3699dd6-eaee-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qr5AoxmO6/PwWORAeWF/ypc+T0I86ca6pfYixY5IMPy6wafagrBaXpC20st1PFTLJ12UkSocs9y4FzKXGEOhRgptZzQgkl6Sv5nwV2APoErtXI9SfD9CWXYSJxDhfe45Lp12qHJWsZyQykeV9vtKvfHWk8dRmR/9LkizBWO1hk5Pz26uTL+m6qMu0v8IAJA3bQo6u7GSbwmzZBSlX3EwtbQ1Ye0vw6X3UY3ZYzfaUPicfpeLbBSCPnjQJfa8cHT295gApRcrTDJ7KnZRxesPOG3lMoCLnwxi8yPW1Lf3rr3iejuSiTSnazCZhCTON1MHJR8HfvUVX2hJCqoDSurORw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=26l3ZTOJrrzdLT8AAIkQDwGgWRD9N4s7dh3yPy7iVWo=; b=HzN9TwpNCFyJcA6KnbsusbKoQzxVdk0fVviiPYx8/xShgTP/HlFfDxwRmlCBNamyXBZypaIfCEhRI0Bj+5GB2IVGZJChhF/SRgbcaGE3HZN8Hc9pIrMFU089p9nrrvQY2tWcg85Yn3Yog0ueHeOPyGEX0fmqBtNSdPA45wn3j7DzIflspZyOhdQWYTE+nNjeqsksT06K1Nx64BCv4XRH3Zj5udd5u2FAe0zhQhkxoZMm5+Q9EG3GrrJPaVljMZgqFcTFL2FshT9c6EdYUDI70dKfmOmMcj31Ffyiabs49bv9ryT5BKtaYEdcqwoEAV92wSc7PTBHkyFFfx5Gq5L0Iw== 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=26l3ZTOJrrzdLT8AAIkQDwGgWRD9N4s7dh3yPy7iVWo=; b=O63RvtuOFJbk7psFOfKYtlJj57mCBbOLrsE7VK2ELivm3jkt193KOtHfRvgmvyETA0obiaut3fLOhPfow9aA6PNq9f335AZCq9bmSX+rH7AHivdFSAsiyyHImTYf4oigzov7drdevERolMu99alJxB3jRpWxJLPnYzzmzMhMHYc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <5ae32738-9fef-4ba6-a53c-0f665e536eba@citrix.com> Date: Tue, 6 Jan 2026 10:58:51 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P . Smith" , Xen-devel Subject: Re: [PATCH] xen: Drop xenoprofile support To: Oleksii Kurochko , Jan Beulich References: <20260105195717.601500-1-andrew.cooper3@citrix.com> <724e78ef-b6ed-40db-a5c0-bd6473b6fe16@gmail.com> <8561e1dd-492b-4d51-bf10-0a4523c941a8@suse.com> <10a38a49-c19a-4bca-8616-1490c3ef6a57@gmail.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <10a38a49-c19a-4bca-8616-1490c3ef6a57@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0409.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:189::18) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MN6PR03MB8006:EE_ X-MS-Office365-Filtering-Correlation-Id: 8e33b79b-b5ba-4a33-de76-08de4d1295bd 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?YmxCaHF3Z3dsMkN6MTg3TnFIWFZPU2NaK1l3TDlTY3Ewb1p6dmxnVDdQL1lt?= =?utf-8?B?Ti85QXBMUUxTeGVVOWdYUTZIam1ONGQ4UzdWV1JxTTZCbkZYQXBMM1hCZDlP?= =?utf-8?B?ZSthVFNuTUp5UWx5REdkYmJBUEtSdk5zNFZmU2YwdHBiQWhZdTNua0Jibkxs?= =?utf-8?B?VE9pVFNvUnRIVkRheXNDQWpMWElncUxWYlpHQVdWZWRkMUdjL0ZwM2ljR0FZ?= =?utf-8?B?WUZRaWJtMFV0RWZqUnhZTS9MZWF4UVhCNWJTeEY5RDFPWVVQaFFBeFl6d0VL?= =?utf-8?B?aUV0T1BnZlRqbTA5OFJERlFDdElUUWJuNExrRUJCK2c4dkwxWXNIa0JJaTl0?= =?utf-8?B?SWZ5NTRDVnFhMG5udWc1K3NhZitYRG91SnFmMHVKU2hXaEQ0cHlBM3d2N3cy?= =?utf-8?B?RHdpU2JONy9KQllaRHZlVGM3MVRoZ0NSUjEwaTl2eXhaWTA1eEQvZWVSUUFw?= =?utf-8?B?WUtZRTZxaENHWDZFaHhwbzBuTFVqYXRFSEhxQ2RwY3lnVUZCVnd4K214MXN3?= =?utf-8?B?Vk5adzVHS3F2emFSRTljVUxHb0FHZXJvSk5zWUwyMys2bzFZWnRqZTdBcXgr?= =?utf-8?B?OXVXcHpQd2lPa3ZRaDFjU2huekxOeDJjMG55WXdOSGdad2tXV2RSM3Z4Tmow?= =?utf-8?B?SGRnenlBTTlNVWhRMUI2VlIyN253Z0I2aUQrbTlFL2pibDloOFlUNVI0bmtI?= =?utf-8?B?ajZQNWhpeWRIVjVTM0x0MEdsbDFXRFFFMHlOcW5nVjBod0tsdk5LdHdNTVI0?= =?utf-8?B?ejdQcUtTSG1pWncwQXgrQTVZVjJFOG1qZFVnbnZrZ3ZabEpCSnI0U0lDVHFR?= =?utf-8?B?WlAxek9BTms2Qk9iQnVSUGtzYldXOEdFSXYvRGQ4bW5kQkFKcnlGRG0xeVZs?= =?utf-8?B?cFpjc3hZRFlYUWU3a0RZaDdjLytqcGI1VFNuVlFhY0VtM1BwQ3VybDlKbVJB?= =?utf-8?B?TFJsSmsxWGk5VStEVVZTTDVjSjcrZGMvMmxoNG1PRitCdkRCdGNBZ25CNWdZ?= =?utf-8?B?cHBteUF6bWtmT2JtY3NsZERYQ25Ed0NIMHd3RjZ1Uk9uNUVIUlVGVi90QmE5?= =?utf-8?B?OERtWU5YeFdnR3JlY2dEWG9ZV0dUTlE1SUt1aVhzengvMUsyK0p3djkydXg1?= =?utf-8?B?Q3k2WkZoOE55YThsUzIxWXhPdDRYMXRoZ3lZemJ5ZzQyNUFjUWFmKzBoOC9W?= =?utf-8?B?OFNDQkhZUVA2UXVBR1FVVWNDS00wcEtja1EyRTAzbVRtRkxHRWw3VnMyMXZu?= =?utf-8?B?MXovcFlwdGJOOEJJNXBtdllDK1NWb1IzMlc0Ukloa21mU3MwWGxwbVVhWk9L?= =?utf-8?B?bTV5a3JoRlBhWnZkeUhPOTZWNkdpWWZYMW5Pb3pLaktuRERJQWw0YnFBWjdq?= =?utf-8?B?ZG91UHhMaEtianM2ejN1ZDM0WjBaV3VsL2JTNUxvVEdqWWF2KzBIcEl4MGo1?= =?utf-8?B?WDFEbmZDaXN5UEMzbTkrM2xmbUhlMmpXTk4rMmFNeHlzcUM1WEphMmVqVmFm?= =?utf-8?B?Szdud1Zmd1VPYnZBQlVzT0s4Rkd0clFvRytubG9BNk5UaWdwOWV3R0svb2x2?= =?utf-8?B?UlNuSXRxSFE3V3laNUN6ZTkwc0RzaWlmRDFUVjh5VVVsQWhCSmhEOERtZXVo?= =?utf-8?B?U29rdGRBV3dvcWhZTVBFUTFiWGhwcVNBR3NFN1JmNVJTU3VyNXpnYVNqS1lh?= =?utf-8?B?bTJOaFZhR1RRY1k4QlhYY2xsNDZpOWY1S0tWRlhhWlh1SzdIQjBaYmZsdk9p?= =?utf-8?B?a0RaVkovcmlsaXNPcEx4enhETmZtNzdmenhrTkVFVG9lUWZlK2lQelRKTXRD?= =?utf-8?B?VzI2SmF0SHk1cWZLWC9TQUFpR2I3VDJtWlZZNXJmSWFaNnZDNU9IL2l5NWtP?= =?utf-8?B?dDdqY3FTRnBoRkF1Z2FxblgzSEdFbHJ3anNVM3Z3bXhwbVE9PQ==?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Y0lLZHliMnVKV2tRd0lHOXc1c2xDYitxckd5amRIbk5nb01aUkxwN0R2TlBm?= =?utf-8?B?ZUNyRHZiaThiMVBVQ1c3ZDhDK2xzdFgrbmNERFVFTzlpNUJJWmd5S3h4Wngy?= =?utf-8?B?VFp3Snd3SlpuWE1PREJJTmc4eHBwWFRCRzJxeFdWSGdiUTVUNXFVYzdib29p?= =?utf-8?B?ZEhMZEhzdUE5T2ZPMUdxTUtSQ1Vpbm9uSHhRRjh4dFNIdHFPcGxXVjQzeGxJ?= =?utf-8?B?ZDdwQUZhOTN2MjAwRUJuR2k0Tmc5c2JxNXJwQ0FVd1E4ZFBWa1I0cFkwSW5j?= =?utf-8?B?VEN5THdvSHNhbXhQZlVNeEFBcWJPaFBiMlhLUGcxU2ExRGkzeWEyZUZHKzhv?= =?utf-8?B?TlREL2k0WklheUpHY0lwSFN2RDczOW5nRTROYjl3UTRROGRKRFV0M3puUUFY?= =?utf-8?B?VWJLeWRmaFdyZVREdENXbkdaSnRSY21vN0FGemk4N05DV1pmbk4rTzFSenBG?= =?utf-8?B?L0x3ZHptS244NzN1WC9sTGYzWGFwNGhJYXpmTUs2NHEzMnhFYmh4NmdQTDhh?= =?utf-8?B?Ly9qNi9waE5pWE9rNDFXZ1ZWTUl4TjZmNzF0dUdqOGswK05KbVdmUk1wa2dP?= =?utf-8?B?T1FpNDgzM1h0NWV6Z2FpV01GNXJEUFV6UjFPUVdaN1dxY0h6YUg0RTdVNkRN?= =?utf-8?B?T2VZMDNOSXU5TFREMy9jdlRGMHlCZFAveHNzdnNONWIxelE2ejRkSGtmeHhW?= =?utf-8?B?RHdMa3QyU0lMcFVIQmthQkprTTcwWkhCZTFQRituc05RNS9ybm15ZjZxTWsv?= =?utf-8?B?d000N0lqVWtUZDRUd3RrYlM4bmJPTjkvcVdEM09WVkRzUC9Cd1BUbVhJKzJX?= =?utf-8?B?SWsySUNOWTU3Z0w1NzJJZjJkV0FCenQ4cHd6VkduV0phV3BLK0U5dVp6ZGdm?= =?utf-8?B?Mk94UVFBMlZ4b05STlB1cWtLVGh5aDhGOTB0RWgzYm1xeGJnUDVwNXhiLytj?= =?utf-8?B?ZTlmMzVUY0pRNFhndWV0WWZJV2dxTUZudjFQZzVSMXdsL3BYc1YyZHJ4em9J?= =?utf-8?B?Nm84VUR5eXB3NXVuaERPMEN3dmpKVU9SM2E5YS8yWHN3eVJzdXIwdklZNnJH?= =?utf-8?B?SDZwS2tvdnhkbnZJamRud0JFSnhUN08xUm5ZSkhmQTJ2Q0Z0UG55aWxtRVNV?= =?utf-8?B?ODZBMENGWjJqWFRhVWI4Mk02VVV5L0Rnb1JLWkN2RDRuTktKM0hKcW5wUC85?= =?utf-8?B?d25wdzBod1ZOa0tqMnVwRmVQNWR5amtiZVE5NDlwQVpPOXB3b28xR0lzUE0r?= =?utf-8?B?VWtsV2lrdDJ3bXM0dHFzbEl1MGtlK3NYbEtVL08wdk9xVDlmb0FHQnJKVGg1?= =?utf-8?B?NEFvNlVRSFhBTSt5ZjFkMVhoOU5OZ2NhdXpLR3M4R3JpODB2Q1haV2o5Zi9v?= =?utf-8?B?WnJnR3dDYU54SnFYbThlbjlKMFBMNXZOTlY0TlBHbHVrMmN1Mm16MXo3V1VH?= =?utf-8?B?M2ZwZ2tMTHJxbVVSOHNKNWxFUnplYUFOYjJGdmc4V2dJTUNRK2IxRHFFVCs3?= =?utf-8?B?WFIzZ3hsZHJiZGx2WFIxSUVkSmdLbjRISWIvMUNuMDQ1czNNNWZEbWRGdVVa?= =?utf-8?B?bHdvRU9HbUF4ZWtYYzFCTEJ0WHZKTjE0WExhTWRVUXBSQW9kRGx2RTlaajFm?= =?utf-8?B?ekVSNUErWThEWUNCWHJNdEUzZmRINEpqVTdGNWd6MGFMa2Ztd3gxK0RxVnZJ?= =?utf-8?B?ZHAxcE5lejJlNVlLUTUvbEY0aUFIbGw3MkpEbVJOM0p3UEV3UlplV3ZBWW1j?= =?utf-8?B?bmtwbEhQd0JyeERFOGhyNnhZajB6UHdkLzV4Q0Qvb01lcGtRS3FnSG1MSDYz?= =?utf-8?B?eWVaQVNLOWhnQXAvNzhxREZKdGFHa2l5cklTL3JCMzVEdm14QksyTmlDMWYv?= =?utf-8?B?L21IQmNPODdRbWtOUi9NbUNNYitQeUcrZjYxd01LdXg4dlExeUZPZjJpdnlD?= =?utf-8?B?QnNtcno5bmx6MGpYVnRGekd2OXk2alY5UVBva3NNWVgwak5EeG1YbWx2TWVO?= =?utf-8?B?Y25EQWppTjJGVTZIZFpNMTd4alJXVStoN2NGaDdzbk01S1dYejJvWG90aFht?= =?utf-8?B?emVKYmhGaGsrU2l3eG1pemVsOEtVOVJrMjBMR0NVRWk5M0RmSW50am9CUUl2?= =?utf-8?B?dmZmekltOS9oZXlWTHhnZVBzVzU4Q3pDcE5FTjBMN3lzNVRQMHovR3UxQTBt?= =?utf-8?B?WS93dlg5UmltdndEM2VKRnBvMUdPUmh3MmFWTFA5KzBKbTVId0k4TkR4SXV0?= =?utf-8?B?TUl1b3FOVGcxN2F3NjY5cld1MGJzTDR6OXl3dVduc0ZQVjl2UTE3UDVvcGtL?= =?utf-8?B?Uk9ydXJBbGptN2J2WkVvZ1lCTkJMbXRiZXBINnlYdjJrNENFdTZrWkpkY2J6?= =?utf-8?Q?PU05qzwCAuYaWLlI=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8e33b79b-b5ba-4a33-de76-08de4d1295bd X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2026 10:58:55.0861 (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: U+wBDqINGQ6DaeAl66MQGFASV7h7JZm7PjFZObSY1PvSRh3kAlI8sM3MUSnZNxtJ5U/Qv+8cIAMEV1AvY9jXfyRxJTdMspZ7hmIJjtfrNAY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR03MB8006 On 06/01/2026 9:37 am, Oleksii Kurochko wrote: > > On 1/6/26 9:53 AM, Jan Beulich wrote: >> On 06.01.2026 09:43, Oleksii Kurochko wrote: >>> On 1/5/26 8:57 PM, Andrew Cooper wrote: >>>> The most recent xenoprof change was 300ef0cb4fde ("x86: Add >>>> Xenoprofile >>>> support for AMD Family16h") in 2013, despite there being 42 changes >>>> worth of >>>> other cleanup/rearranging since then. >>>> >>>> Oprofile themselves dropped Xen support in commit 0c142c3a096d >>>> ("Remove >>>> opcontrol and the GUI and processor models dependent on it") in >>>> 2014, as part >>>> of releasing version 1.0 and switching over to using operf based on >>>> the Linux >>>> perf_event subsystem.  Linux's version of this patch was merged in >>>> commit >>>> 24880bef417f ("Merge tag 'oprofile-removal-5.12'") in 2021. >>>> >>>> Drop xenoprof and all supporting infrastructure, including the >>>> hypercall, the >>>> XSM hook and flask vectors which lose their only caller, and even >>>> shrinks >>>> struct domain by one pointer which wasn't properly excluded in >>>> !CONFIG_XENOPROF builds. >>>> >>>> Retain the public xenoprof.h header as it is ABI, but note that the >>>> functionality is removed. >>>> >>>> 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: Daniel P. Smith >>>> >>>> Despite appearing to be architecture neutral, the internals of >>>> Xenoprof were >>>> entirely x86-specific.  Another curiosity is that only the VMX MSR >>>> hooks >>>> called passive_domain_do_{rd,wr}msr(), and I can't see how this was >>>> correct >>>> for SVM. >>>> >>>> The real reason for finally getting around to this is the number of >>>> MISRA >>>> violations reported by the eclair-x86_64-allcode job that I don't >>>> feel like >>>> fixing. >>>> --- >>>>    CHANGELOG.md                            |   3 + >>>>    docs/misc/xen-command-line.pandoc       |   6 - >>>>    tools/flask/policy/modules/dom0.te      |   2 - >>>>    xen/arch/x86/Makefile                   |   1 - >>>>    xen/arch/x86/cpu/vpmu_amd.c             |   7 - >>>>    xen/arch/x86/cpu/vpmu_intel.c           |   6 - >>>>    xen/arch/x86/hvm/svm/entry.S            |   1 - >>>>    xen/arch/x86/hvm/svm/svm.c              |   2 - >>>>    xen/arch/x86/hvm/vmx/vmx.c              |   9 - >>>>    xen/arch/x86/include/asm/xenoprof.h     |  95 --- >>>>    xen/arch/x86/oprofile/Makefile          |   6 - >>>>    xen/arch/x86/oprofile/backtrace.c       | 145 ---- >>>>    xen/arch/x86/oprofile/nmi_int.c         | 485 ------------ >>>>    xen/arch/x86/oprofile/op_counter.h      |  41 - >>>>    xen/arch/x86/oprofile/op_model_athlon.c | 547 ------------- >>>>    xen/arch/x86/oprofile/op_model_p4.c     | 721 ----------------- >>>>    xen/arch/x86/oprofile/op_model_ppro.c   | 348 --------- >>>>    xen/arch/x86/oprofile/op_x86_model.h    |  58 -- >>>>    xen/arch/x86/oprofile/xenoprof.c        | 106 --- >>>>    xen/arch/x86/traps.c                    |   4 - >>>>    xen/common/Kconfig                      |  11 - >>>>    xen/common/Makefile                     |   1 - >>>>    xen/common/compat/xenoprof.c            |  42 - >>>>    xen/common/domain.c                     |   6 - >>>>    xen/common/xenoprof.c                   | 977 >>>> ------------------------ >>>>    xen/include/Makefile                    |   1 - >>>>    xen/include/hypercall-defs.c            |   6 - >>>>    xen/include/public/xen.h                |   2 +- >>>>    xen/include/public/xenoprof.h           |   2 +- >>>>    xen/include/xen/sched.h                 |   3 - >>>>    xen/include/xen/xenoprof.h              |  49 -- >>>>    xen/include/xsm/dummy.h                 |   7 - >>>>    xen/include/xsm/xsm.h                   |   7 - >>>>    xen/xsm/dummy.c                         |   2 - >>>>    xen/xsm/flask/hooks.c                   |  35 - >>>>    xen/xsm/flask/policy/access_vectors     |   4 - >>>>    36 files changed, 5 insertions(+), 3743 deletions(-) >>>>    delete mode 100644 xen/arch/x86/include/asm/xenoprof.h >>>>    delete mode 100644 xen/arch/x86/oprofile/Makefile >>>>    delete mode 100644 xen/arch/x86/oprofile/backtrace.c >>>>    delete mode 100644 xen/arch/x86/oprofile/nmi_int.c >>>>    delete mode 100644 xen/arch/x86/oprofile/op_counter.h >>>>    delete mode 100644 xen/arch/x86/oprofile/op_model_athlon.c >>>>    delete mode 100644 xen/arch/x86/oprofile/op_model_p4.c >>>>    delete mode 100644 xen/arch/x86/oprofile/op_model_ppro.c >>>>    delete mode 100644 xen/arch/x86/oprofile/op_x86_model.h >>>>    delete mode 100644 xen/arch/x86/oprofile/xenoprof.c >>>>    delete mode 100644 xen/common/compat/xenoprof.c >>>>    delete mode 100644 xen/common/xenoprof.c >>>>    delete mode 100644 xen/include/xen/xenoprof.h >>>> >>>> diff --git a/CHANGELOG.md b/CHANGELOG.md >>>> index 3aaf5986231c..1663f6878ef2 100644 >>>> --- a/CHANGELOG.md >>>> +++ b/CHANGELOG.md >>>> @@ -15,6 +15,9 @@ The format is based on [Keep a >>>> Changelog](https://keepachangelog.com/en/1.0.0/) >>>>       - The cpuid_mask_* command line options for legacy AMD CPUs.  >>>> These were >>>>         deprecated in Xen 4.7 and noted not to work correctly with >>>> AMD CPUs from >>>>         2011 onwards. >>>> +   - Xenoprofile support.  Oprofile themselves removed support for >>>> Xen in 2014 >>>> +     prior to the version 1.0 release, and there has been no >>>> development since >>>> +     before then in Xen. >>> LGTM: >>> Acked-by: Oleksii Kurochko # CHANGELOG.md >>> >>> Nit: It is necessary to drop the extra space before "  Oprofile >>> themselves...". >> Why would that be? See the other bullet point in context, which also >> uses a >> two blanks after the inner full stop. This is deliberate. > > I just missed that a similar case was mentioned above. If this is > deliberate, > then I’m fine with it. It’s just not obvious (at least, for me) where > it’s > acceptable and where it isn’t to have extra spaces. The hunk looks correct in https://lore.kernel.org/xen-devel/20260105195717.601500-1-andrew.cooper3@citrix.com/T/#u It's only your reply https://lore.kernel.org/xen-devel/724e78ef-b6ed-40db-a5c0-bd6473b6fe16@gmail.com/ where it looks to have whitespace problems, so I suspect that will be a local MUA problem. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 06 11:11:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 11:11:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196025.1513888 (Exim 4.92) (envelope-from ) id 1vd4xw-0001D5-82; Tue, 06 Jan 2026 11:11:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196025.1513888; Tue, 06 Jan 2026 11:11:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd4xw-0001Cy-5K; Tue, 06 Jan 2026 11:11:08 +0000 Received: by outflank-mailman (input) for mailman id 1196025; Tue, 06 Jan 2026 11:11: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 1vd4xu-0001CO-OR for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 11:11:06 +0000 Received: from CY3PR05CU001.outbound.protection.outlook.com (mail-westcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c112::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 62262446-eaf0-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 12:11:02 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by LV2PR03MB989132.namprd03.prod.outlook.com (2603:10b6:408:37c::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Tue, 6 Jan 2026 11:10:59 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9478.005; Tue, 6 Jan 2026 11:10: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: 62262446-eaf0-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ag2UvleQpeZc4fWnkm45SO9iJifmfW/XcTioLPbLwEF+o2KE9fYVK9Z/qZix2zDy+ou672VZpDNI3mVst064/LNKKrFMHK0W6na2GD2urnFnAr5ppwA+DncjQm8XnJLodLGeKZkCtwcZ5bu+WSCzrorg2FpBgys79AQkgRbbqwfCC4+w2d2GcLMaDKl5/JqmFh/qUHBqS1m5xkXYaLJyc5VfE7QYPm4Gcf3bCe+8Y/o2xh+SR3XZHsEJkx5h1DydXmjPQlcHglo+yKQYgGzvFFPywZ644yTLgjW99CJ+R4QdNtnOnJ2Ys6wu124evdC/EPX70/Wx+OX5KmOe9d0a4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=C+ukKtl/227861n5z68DDhFGF3b9FABE9HyFN+KtKNE=; b=ATsJArxq1NpyzWFSdzWtagKqHWEGyVbGJak9HTp+ARRIJySNXh+egKMnbj1GD6s5LOgDCN5sFYR64gHbiCItkGhPB5b21dFYn6koycB3o8VEJyMKXk2/adTB7WHlgVdDKjyzFN9svENDSpZvXdGON4BKUD+EUuU3jitwRh6bVd+TSuxQ4O28SuQieu5YAgqRY/EnrnlrsM6xoBg6gSvuqVWGSZWXSTTP5QpO9EMGlJYjrrAplZbZcUc551QqZcuAbwEDia20BEW9hmoVmF5ZTzaAFx/ZYJtTfIpGX3vrmTLEm36ixgsKtXl8l8sbKca8Rth/j+X8WcCte6U805WeFw== 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=C+ukKtl/227861n5z68DDhFGF3b9FABE9HyFN+KtKNE=; b=dSrgzB8n7kWLWcyWrO8dktCgsAu84MoRULgklPFHE336ozDDEfkGozbvpAfb2X7ikEawGbBKDadKGF6virBPwO+lp5gZdsrYoZCJuCi0Kyi1Fos6a6m9G4sQoTRwJcm5vR1wv/UcGMgWK494y9aakRgSy+Crb/KCpzFdqtLxlY4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <296a2932-1e6c-4c6f-81cb-a76975fdb423@citrix.com> Date: Tue, 6 Jan 2026 11:10:54 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Xen-devel , Stefano Stabellini , "consulting @ bugseng . com" , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julien Grall , Volodymyr Babchuk , Michal Orzel Subject: Re: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible To: Nicola Vetrini , Bertrand Marquis References: <20260105122436.555444-1-andrew.cooper3@citrix.com> <82d99c52-c39b-4fbb-bbb2-0e952df91673@citrix.com> <541EF107-3536-4525-ACC2-065A9A13481B@arm.com> <543958adfed3e5547141d56341c2788d@bugseng.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <543958adfed3e5547141d56341c2788d@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0170.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:312::9) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|LV2PR03MB989132:EE_ X-MS-Office365-Filtering-Correlation-Id: 8a033585-2f9e-4657-8dd9-08de4d14452a 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?cVJCNWFjcXpGOEtoTjZ0VkxoN3JseDJGTVZkNVRLQUIzVnMwa0lwMXVMSEh3?= =?utf-8?B?aTVISG5wUEl4dkJBVC9PbzR6Z0xadlRuaGplMitQNmxJUzZudXQrdTNuT3dx?= =?utf-8?B?MHh2UDdGTkMyNmpoclFMalhaYTJNRmhzT09VUFlFN0NPSThZMmVYdTNmV1pu?= =?utf-8?B?TTJDT2s0S0d3REQrT0hjWWVVQU9DN2NONDVVQ2FqWkVBMlJ2VDE3YzhLYndS?= =?utf-8?B?U3lEandydnF1QTBIOVBpODFLWkx4N3ZDbWFrcE0xaUNMVDNiTXM4T3ZFYS9T?= =?utf-8?B?bzV5dTlCMnB5VU4wRkN4eEE5TS8yakFidVgrOEgybjk2L2ZvekYvUzdVUEhW?= =?utf-8?B?R3Vwb0xWQXFUM0kvT05qckFSdnA4KzRYS0FmRXdLUkRWbUNmZlFHY1puU0Fx?= =?utf-8?B?VU9Venh2bllTdFVuTVcyZTNuVmdXTzZua2ptYVBMRkw0UkJDYVI3WUoxWnZp?= =?utf-8?B?ay94bFl4MFFDck03RzQ0TG9rYlV3R0ExVFZHY2dJcm0xdFBEanUxWTZLT3Fs?= =?utf-8?B?YXBWVzhHVnlmbVhWOUFWMy9hUW03OTM0UnI2QTVLVFk5QUZoVzdhK2JBN3hr?= =?utf-8?B?QXU1d1dMQUUxSUU4MzBpU1kycmljOEoyZUtPWlA4ZWJWOE9va2NjUlFiRXVw?= =?utf-8?B?MEw3UUdtM3RwdTVZUFVuKzR6MGtzNXllQi9zYjhJaGpYSVNNUU1wY0YwQ0Fm?= =?utf-8?B?TXk5aHhya1c3WjFFc0REM3JGbFBaNm53N241ZHNOaVRHVE5pQkFVTndUZ1VO?= =?utf-8?B?cFBOekNsd29OSlVyYmkwNWZXMHlaaDhMWmFpS2dDcVF2c3BtckdKSUtDYnMv?= =?utf-8?B?VVF0YXFsUWh3ZXNVM0Voak9hdHZGWGpkRElWTERYTS81Z25HeEs3alVobXBE?= =?utf-8?B?M3c2dFp0VW9JbmcyZkdMdjBEV0Iwd2V6Q0pxckJpK0Z0YkNFcU1lTU0zUzZG?= =?utf-8?B?K3o2Um9SbnBhbkZyc3RhZHMyRTk4QmhxdWl3TlVSV20zVisxRGlQSXJpTnQ1?= =?utf-8?B?ZFpQSHJJYnlwenNUeEt2OVBDUm1ZOE9leEpPOUQrK0RZeHB4U3VGOXMxNFZ3?= =?utf-8?B?Qno2RWZkbFJmbmR3aC9rb2lhWHhvNVpydFgwYm5FOGpPQnBwazNuS0RVOEZo?= =?utf-8?B?Ny8ycndRMzJLRmVKcUdDa0lERmVuZ0haRkkya3R2Zll6cTFqUGV4TmNpa1ho?= =?utf-8?B?MUV0OFUrVHFpaTlUb2pjQ201VXh0cE1lUmpzMVYrSTlnbkx3T0FHY1VabkRw?= =?utf-8?B?aDBFVFdkSDVWZlVTak81Y2x1NlVwalAwTnBsb3c1bE54Y1UrWStmYmx0YkFr?= =?utf-8?B?Sm16THVEMitIb3NCVjRUWnpoZUpGci95emVzcFpTMStIeDdZR0hIQWN4cEZv?= =?utf-8?B?dXMzWURSd2hFU01SdnY5cVo5aFVUZ2tUeUFNY2QzR2Vtb2twcHhkS2tLWU8r?= =?utf-8?B?U05VWTFEcEx2M3ZsRkV6Z0kxSldOYkVVWFh6VDUySmcrNHhUS2FIeFh6Wkt1?= =?utf-8?B?RjdEYkVCY2diRnRJMncza0FiYzhtZ0NtVjE1a2p6amJ4VDh0OUFTVUNPa2hu?= =?utf-8?B?dkNjMkVLOGVoL3pvenMzTnZKNTBaa0tlMnlxS016ZVg0Z1F5WXc5RS9IMERw?= =?utf-8?B?ZUNaOWtBT3pXOUJML3NrKy95STdua3FvTzJyRWpBaGNZYUJETWUxUnA1aTB2?= =?utf-8?B?Y2Y5K3ZwYU0xRWxTWXk5NkFuRXdyb3ViY3hVT0U1b2lVWFlETnJJaHhwcFpP?= =?utf-8?B?NGI5ZWQxdjVJbWV1bzlRZk9GUzhzelVYNG1tUHZrM1Q0S093RWRzOFpMSmdl?= =?utf-8?B?emtxY1Q4Zk4vRTZGYmVtTFhZRktEaFZoZzhnaEpJZGRrSkpiSHIzK1hlc3VO?= =?utf-8?B?T3BXUGlrNGNHN0poUytnL05DZGNYbzBhNWJ2WllaT21rdHc9PQ==?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aXdZSDlsODhHQmQ0b3B1NGMvYlZrNlp5cFRwRVMyTEx6M3pwd3BpeUltM0Q4?= =?utf-8?B?ZWVIV3lRTVlNUE4rWkhLWjI0K2l3aVVHY1RxamNEZk1WMGJReDFEM3RVNlFy?= =?utf-8?B?NUtmMVhnMnM4Z25FeWtlWmluZ05HSnhhbUo1Rk4wSG5LMTlIK1ErWjR3Ri9v?= =?utf-8?B?eFpZcWdYbWZrd0ZLalJ2YXUwWWpXdjNKWXlCWXlncGtuYmhwZE54ZGpGVUJP?= =?utf-8?B?RXlWY0ZxOE9FNU5QNlJPdCszb1AwYVo0amJycE9LS1FnSjFVSFhaYlVWaFlL?= =?utf-8?B?STZpT0lINUVWaUVBRXNpN1JzbmdPdlVOcXNqMGw2ZnU4VWwzRkR6N0VpRFNh?= =?utf-8?B?TDFvd0lucTlpbmFQQVRzL0RtMzVGZnVqOXJoaDFINHVDeFpoS3FUUGlCdGpZ?= =?utf-8?B?bzZORVUxWlNJRjdYS3kra25HTFRPUnFBSWlVVExzSnNhd2x4akgzb3BrUkxs?= =?utf-8?B?WTIwQnVxbDAxalVxbTNBZG9pNXd1Rit6czVtb3c5R2VQVVBXQkI1NkxTdStn?= =?utf-8?B?T2VTL2VxQ01ESysxM05aZTJqV0V4b3FGNnBBUFZrRzhsUlNTTUpaYTVncXdu?= =?utf-8?B?L1JKbHk4cy9JRE5pdldKZ000Sm1jQjV5eFE2VldES0R4emNQcXJDSG1qTDJl?= =?utf-8?B?ZGNUSGsxa1dyT010S1NIYWoxZys1K09pS1U2cll4aDhqdEtEeHhYU3FzbW80?= =?utf-8?B?aTVkK0ZqL214Z05yNDBUeUVTQTc3VFh0ZkEzSXdtUlVyWFh2WHMrWkZQSW52?= =?utf-8?B?dU5BcHh0aThlb1d6SnVHeEtTM1ptQWtIUnJkd2ZKa01zSm14ZExIM0VYUENG?= =?utf-8?B?T1VIN1JQRlk3RDZ5R1JVcFp6T0Fhdzk0L3NxcmU4VG54UkNRb3J5TmUrMlZ3?= =?utf-8?B?SHY2U2VlOE5vMWRYQlZ4ZjhJUWpkbGQ1S1d1YWFoUkJ1K2ViRmljdlNXVDZ5?= =?utf-8?B?VTh2dzF5YmhGcWtST3JpSTRZbTI4OW5FU2NGZk1wWTVOcG9PdmFBekJlWHFV?= =?utf-8?B?Q2xyME1BS0VmVUdaeDAxM2lXZm1EcjhhTkhrUnlzRm1EdDdxK0dFdVRpUGtL?= =?utf-8?B?aVNJT2FqMVYyZXczYk1VeGxySHI5ZkhaVUZjYTl1ZWVVekNKWU8zZjhKZ1ZY?= =?utf-8?B?cEphQ0NwSkZmc3UvMFh2cnMyZE9oR2NoVTYrY3lnOHl5SGJtd3NHR0VSNjl1?= =?utf-8?B?bE91aEQ4ZFZZNUN2dzlSV21odWtYTEF5YWpwRElseDJ5QnNETGVEeXpIcFdZ?= =?utf-8?B?SFgzQ0xmWU9zZXVWRVA0MU81WG8zMHdPQWMxVWhORkRkVTdkdW41Y252MFZE?= =?utf-8?B?aTNGWS9LdkJ3OGdySm44cHhTVkRmUlpVWkgydlNpRW9mc21jZWs1cDVzNXdX?= =?utf-8?B?L2lHcTBCb2EvbW9ZRUEzNEl4Sk83MEExT3pUaGdlamhzcXdvYUl5T1pjVWIv?= =?utf-8?B?VWYrQnR5bjBLRm9sb3F4SlJpM3c2VDUvblRTL253eFB2QVlMNUpyOFJhaXo3?= =?utf-8?B?N3JnOXBycVFaU0hNWjlwSmo4dWczMG1hOTd3bTZpaXl4L2dxSnI4QUx3MW51?= =?utf-8?B?SXg1cjRPaU9KaGJlcUFOQTlreDEvb2k4UC9UcG9vVksvOWlhR050SVBYUHp3?= =?utf-8?B?TDdIOGlERXdnTzFhRENHTCs5ZjZ1dGZzbnh6eENFMWtFQW1ETzd3M0Z0R0E2?= =?utf-8?B?SDd2MncrTVdvRHR4VUVLQzk1ZFQrZVcwMmFkN1dmQ0NZMXFYVDBlbTl5ejNu?= =?utf-8?B?bDhiZUJORWFQZXd4T1E3Qnhvd0psOW9MOHdpTDJqSE9WN2V2RzVLUzBhOUFD?= =?utf-8?B?aHo3aTFiUE5UY1RGak9GQ2ZmMTh1WkUyQTlMYjR0NlN1M1NWdlRSV3JBMzdR?= =?utf-8?B?enhmeUFMQlNXT3hWU2MyRGh1bU5FOWxLdzhtZmJJOExlMzJkUU1SOTl0Vm5J?= =?utf-8?B?SFpkMzZKVzhSTmovdGVWSi8yTFdkNzFWT2hBRS9EbjhXeFZNYkZoNGxyWDBl?= =?utf-8?B?SkR5RUhLSmt5U1lXNTNZUmFUL2l2ODI2ZHdycGQ5YXFIU1ZLeWRGaWlaQkUv?= =?utf-8?B?T3BGWkZIZ2pzaDY2ajk4d1BRMGhYRXFiSjRCanVQSEpyMmRpMWoyZ0JlWjQ2?= =?utf-8?B?eU1rWk1pcVpRQVlZeUZvT0NKaGVlbzJHZmx5YmlydXlqN3NkVkxJVFZTT2RS?= =?utf-8?B?WXRjTDB5WVhvT2x4U2VJbmIwUmJMRm9tTk83QmFoMjgzTGt2RHFUTHkrcmxI?= =?utf-8?B?VC9jd2NkQzBNRlBiTTFHOThqckphQTR3Qm9lT0p5VHlUWW1wdEY4eHhvdDlo?= =?utf-8?B?M0E3eC9NUXRMd1ZrNUkzaTQyVC82ditudHlsYlpZVnNZMHhxK1d1ZXZIZFVG?= =?utf-8?Q?7liyuD39Fj77W4Zg=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8a033585-2f9e-4657-8dd9-08de4d14452a X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2026 11:10:58.9760 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: T+EqU+TtrvShO3KZuuFonH0QhVhHN0aXyuLm6EVLV3A5HFm07M7QQMzKmHxfRf9DWQQlbqY1pKo7TLqRYZ5e3rvDuPtJdHfYgrFqDhvWzuw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR03MB989132 On 06/01/2026 8:40 am, Nicola Vetrini wrote: > On 2026-01-06 09:26, Bertrand Marquis wrote: >> Hi Nicolas, >> >> On this subject, could you help me understand what the following >> error mean and how I should fix that: >> https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/hardware/xen-staging/ECLAIR_normal/andrew/eclair/ARM64/12604499722/PROJECT.ecd;/by_service/MC3A2.R20.12.html >> >> > > Hi Bertrand, > > the point here is that the macro parameter 'FFA_VERSION' is itself a > macro. This means that inside 'FW_ABI' and similar macros one > occurrence of the 'abi' macro parameter will be further expanded to > the value of 'FFA_VERSION', while the one used for stringification > will not. This is potentially confusing for some programmers that do > not know well the semantics of the preprocessor, which is why MISRA > discourages it, but in these cases I would say it's very much > intentional. There are already a few deviations for special cases > (e.g. BUILD_BUG_ON uses the same pattern to print the condition), so I > would suggest adding the macro FW_ABI to the deviation. We have a bunch of those on the x86 side too. https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/hardware/xen-staging/ECLAIR_normal/andrew/eclair/X86_64/12611734537/PROJECT.ecd;/by_service/MC3A2.R20.12.html Here, we're using the numeric value for making a hypercall, but rendering the textural name for failure messages as it's more helpful than just the param number. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 06 11:20:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 11:20:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196034.1513898 (Exim 4.92) (envelope-from ) id 1vd57L-0002wM-3A; Tue, 06 Jan 2026 11:20:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196034.1513898; Tue, 06 Jan 2026 11: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 1vd57L-0002wF-0b; Tue, 06 Jan 2026 11:20:51 +0000 Received: by outflank-mailman (input) for mailman id 1196034; Tue, 06 Jan 2026 11:20:50 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd57J-0002w9-S3 for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 11:20: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 c06a8b24-eaf1-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 12:20:48 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by PH7PR03MB7170.namprd03.prod.outlook.com (2603:10b6:510:241::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Tue, 6 Jan 2026 11:20:44 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9478.005; Tue, 6 Jan 2026 11:20: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: c06a8b24-eaf1-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iRH/HI/RPr2TqTWNGnAxijXlnaX9/CJbpWy24JvSpNcH7IePiiim26G/NlbXFqRFWS4ptcyeQsyGmOnOOLgmdp1BwcFlvZvxTK8o1oJTUd2ojUuUA/R+0s4CtOYL2xAl9Swc+rPatTkGCh/BfW/WdCInsZjaZpj8w4ZyrKITj8Rsj2N67/aD9pN7XFP2fLxrcCYJrQP2S0zS0GPAtIeGrElMhjwxvriu9oWiPs3u6f5Vw2kA0GsaEmnuoKUtraHCMPk2SeUDaEbYcf0mHZCKyEZ1ZTtVNUL5ufphJGFpyPtIu8BdOjqIFuHV+mj4Bv+633usZvXuId81n/Vwx8CCig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+IqqzMDdNweW6Nsta7d74ip5tAchem585cBEU5q0NRU=; b=weMSEnZdUDI8Jc+Wag0QZ+xqqONYE9Md9ZUA75MAwVfbdK84VF4skgrkqIF4EjiHNAVgL+QQ7avwYHaHfiA5vlfDDRhWlzqQSypM+TgWB4gQWuNR6KC6GQZK7x/+522ngqe6s+aMeehRiPvdlCHbqtCiF9639WqL6vVOxfcNqiF3NoS2H97zuFgCuBbe0GZSXAIpzsgBwRqDJagKkn+iiQKi8iPgIP7aUQOrcpgy44gV/vnVm54GTMbbW1/+O+gUwvfbHccscwL2m4irWBdsNNPMlhu3xGRLEhbh2qjSY24d2qCGfSLrQ6cYotvR7pErXJNYBq9POHsk0l1HEx0ooA== 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=+IqqzMDdNweW6Nsta7d74ip5tAchem585cBEU5q0NRU=; b=NWsjsbe2Hw9aSCKKvw3anu5V4DSf8ywvhlcM70q54gbUT86w7dqxy0rSCGyggUzNN3SPlD/XT3TgactCrwLGou2fm5sXzoNQwrplRAP7v89cg8nBQQ+26IxYYaMBhHeAHimsGQ9mvrPbJMOd3NIoft32NSuEmD7TGtnvvljCmY4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <0e1e877a-a8fa-42aa-8546-ee66f9287e18@citrix.com> Date: Tue, 6 Jan 2026 11:20:40 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Xen-devel , Stefano Stabellini , "consulting @ bugseng . com" , Nicola Vetrini , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julien Grall , Volodymyr Babchuk , Michal Orzel Subject: Re: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible To: Bertrand Marquis References: <20260105122436.555444-1-andrew.cooper3@citrix.com> <82d99c52-c39b-4fbb-bbb2-0e952df91673@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0325.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18c::6) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PH7PR03MB7170:EE_ X-MS-Office365-Filtering-Correlation-Id: 33772b5c-269f-41fc-57ed-08de4d15a233 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?aUZaR094RzRsV2VsaDA5QlBJaml4d2Z1b1c4OFpZNUtlTkZUZjBjVHVnYVZB?= =?utf-8?B?R2RYZUxacVhhOUI2YXh1NTB4RW83MVJDWXoxaGhWOWRwTUpLTkZoL0N6Mnh4?= =?utf-8?B?eFJYbkNNNGZPbXRpUEtvVWV1Y0FneVFrbzlrU29teVVDdkNEcGlVK1RnUGFF?= =?utf-8?B?VEduK1BVaXhRRlZ6TmVPTVkzczlOams0WVVjNlBhUkRvYTBZUHR3QXlWajMz?= =?utf-8?B?K2RpRWNCTnFpb1NzK0oxd2RpdGt3L1lHbytmUE0yQStjWE9rQ3BpRXNzbVhx?= =?utf-8?B?bGNtVFpYa24relVMT1dXWERIa0oxVkNvaURSQnNzc0tCOXBJWXJBK2ZHalp1?= =?utf-8?B?bm5pOWF2cTVGWWVHNk5GKzliSlhOY2pBWng4dzVvYWFpWG1rQU01LytwS0h3?= =?utf-8?B?dURPWXJWSk1EV1JhMnBUVlVMU3RMT202MWdlUFViQ2tNbTRnR0hXZC9CL1VF?= =?utf-8?B?dThOQmM4aTZoeCtiZmZQSjBuREpOZ1NrSWFhZTh2ZjdQRUlBekg2UlpncDRw?= =?utf-8?B?Z2JuSFZZV09NaDkzc3BMa2ZXRG4yMkxrblVFdTJPNWsxZGI3T3hhQWQ5V3Fr?= =?utf-8?B?VEFaVHpGTWEzWTdhRktWSE1lUnJSVjY0Y1NyV1gvVnBuZDdzUHR2b2N1NmU2?= =?utf-8?B?NUtQVkp5QzMveE42K1ErWlhicjZuWXVTMm1nN1gwZUFOTlBmNDRLOEp6NHo2?= =?utf-8?B?WElrL2lwLzVYSEMyNmNRRitqekpmZnlvL211RW5VK0lEb0FFY29sZklvZXp4?= =?utf-8?B?TFdtOU1jcHBvaTFnc3NhTlduMzRRbVdXYjZjMXBkZ0tNWmptYnFUWklEOWNh?= =?utf-8?B?YnFFcDQyUzljUy9GaXlUQnVZUjd4TzNsVzAxZWFSeGVHYjM1UW52SXFXNG9D?= =?utf-8?B?NThlT25GcFVmSHNEeGk2cE84RWFlSTBsOVNkeUFINlJiaWdkMHY5VGxHdkRJ?= =?utf-8?B?VDRTd2pYRU9TRG5qTmhiZnZ5eDVOZzB4a0p6OXg5ZzhMQkg3L05RdjgzSXlB?= =?utf-8?B?aXB5QnlLd2tqOXlzKzI1U1Y2YUE2cFhpdDFhWWNNM2hUS2h1OWtJR1VGL0Nk?= =?utf-8?B?SStZT3p2SGUraXNYUXhSUXVTUTVUWld0K0FRdnh1aEJ6M1ptN1RxdXhJUHVS?= =?utf-8?B?YUZ5OVJCMWdtYkgrRVRKYzFVUjBuN1RaZG0yajkwZWkvSHFZTi9rOWg0c3M3?= =?utf-8?B?Q3JxWTF3WHpSSkdxbklRTm1URytxRUtFSUNIbi9HRHAvSHltbEgwRklqaE1G?= =?utf-8?B?dlJoRi9WM1FKYXRGK0JQWkhqazlRcXc1TzNhOEU1TTdkZEkzQlNaRmU5TWVM?= =?utf-8?B?eHh5R1VvamhOQ3IrS2d5NFpDbGxhQlErV0U5bUZyRC9GOVcydlpQa0pyakdB?= =?utf-8?B?ZWkyWG1QU2pQYXpzblFUNmNBb21YSUd3SldodDlwWGE1aEhPTHo5OWxBcDVo?= =?utf-8?B?ZEtDSjlzUi9sYnNoektSU3Q0OHNBYlBKYW5xSlhwL1hmbzVRbGY0NGxLQ21z?= =?utf-8?B?dE0yOHJ1VzYyNUswS3h2ZFZmTnI1eUxNYXdsaS8zUGRYeTBNNk1sV0RtNW0z?= =?utf-8?B?a0pMOHZXRTVvOU93Zy9CZC9laWFrT245ZnRCcDljYmF3OFdqamdESk1YVlB1?= =?utf-8?B?bEhjeXhZSUo4VUdOb2F5OGRsbFZhem1tL0NaNHkrWVpGT3hyL3NxYkw4cXVW?= =?utf-8?B?ZmNUaW9JWE1OM1RGVld6SUVzUk5yTDVnRmdBdGxNWGxxWDNnblhwa2h4c05M?= =?utf-8?B?UWxGMW5hMEZxTVphQXdIcnpwd2RuT2NUcHl6RCtId09rRkpXczR3YW9HcFFP?= =?utf-8?B?aUQvcFFjQTR0M1N6eWtvUjVWU1ZydHZQV2h3MkdTN2w2WmdiVkkwWDZhMWFB?= =?utf-8?B?M1lteUYzWVJsaVlGVHVQZGRiMFM1bzVhcVA5VUxja0FRRDlvS1R3VEoyM2JR?= =?utf-8?B?SnI3MzFUaVBwVHVFZUtXREJsdklIZTZGVEdSS3dmQ1VSQ2Nmd2Z0T010Zm1G?= =?utf-8?B?anhIZVRIV2Z3PT0=?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?alN6aXRCaG82SzVVVXNsU3djTEo5UjRCY0o2eGtvTlZTMXRmUW5NbVpIRGlE?= =?utf-8?B?Q1c4MUNqNSt6MlpNUHRDcTdiSTB3bzQzZ1pNaDhxVGZMMGh0M3JQYXFmRjlL?= =?utf-8?B?Vmo3aFdOcUpqY0htc2ZBeHRiZGxLYVdoSlcycHJUbXk0MkY2WXhlYmFPa3lv?= =?utf-8?B?STVNZ2dIcTlYUGVBRjdIQll0bVhFQVVkSVdxLzZtQjRzb1MrMkJoaWNrV0w5?= =?utf-8?B?Z2VHeFhCWkw2MlZJMDRkS1I5SjIwMkNTOXgybXVhNVdvaklVdFZyTGI5aXFQ?= =?utf-8?B?MDVFRDRKUDhqdmVTcllkdzdzZGdzVGZyVVBSTklmZUFXWExMRk5DKzBYOE1t?= =?utf-8?B?cmJiajdGYU9BNkNIaU1Vc0k0TzBpQnY1L2tmN1ZHZEs2QTZ0TkcwWllyemtz?= =?utf-8?B?N1k5M0JBaTFnWUNTY0lHU3pYRVNwYmNFOExqUGwwS2g4dGplMlF5TFpiWUJN?= =?utf-8?B?aEFNMmhPQ1htbTNXYUswMTZOMGRIOTFLVXdXK1FuRlFTZndvc1o5SGJxTTJw?= =?utf-8?B?U3JESllVNE5CZUUxcENud1RaMjRMQXhKTHZTZlFkY1ZmV2VVS0dFRmFsNmtw?= =?utf-8?B?N1ZhSFdCK2hFVlMvUUNjalhWcEhRSHlsSHhLME5OYm1rSmdreU1Rd0JRMWUv?= =?utf-8?B?SnljSUk4Q3VZQVRIdmQzTktIZ21uemM4RzV6YS92U25zNEpxcjNscG5ZMnc1?= =?utf-8?B?SzB1djJzcWFHQ3pTWjBuSG1zRUpENVZPVVdwZXUySG9VbGFWaXpWSTJHQ0hD?= =?utf-8?B?cUZiMzFFOVN4T2xqMU55Nm5wMFo4TGZTdU53UGRlRmZTak9OQmFBSTRxME4r?= =?utf-8?B?U0VFeEJNc0l2NThqT3BIOE4wVXRiZVRUaENjY3QxZHZSN1lhaU1oZkYzampB?= =?utf-8?B?cS90dFhGK1Ayd1pqNUJia2plaWhDb053enllWUNZOHI1ekVBbDd5czNqSVFv?= =?utf-8?B?dTdaMkJVb00zU1hxOUNRZCt4dWFydU5kdHNNaDg5Y1NIQ1VpektSbXF1V00y?= =?utf-8?B?L0lxU0xmdTBiU05MR3ZFbjFwUDNVeHJxdEtYMXZvR21SeEt2OWYvRnZvSnRz?= =?utf-8?B?K2pTOTEyL29rZG9SY2srSUJBdExERjdqeEpQSXJiSDMyRXVkRjlaMllvdUQy?= =?utf-8?B?RXJJVGlVaC9lYmYvcnFBd0pEUDhqcDhzNklud3lIL0ZtS1RrZDBaMVB1SzdG?= =?utf-8?B?QzBuNlcrTlFFNlo0d1hoS0x2Zmx6R0hKUmNuSjF6SlZXQ1k4SXlpVXB0RnF3?= =?utf-8?B?NEFWQ3ZQZ3YyaGwvU3NlOENneTEvSjFVTmlDTHlmYWFqeWh2STAzNnpUdndm?= =?utf-8?B?OElsYVZWUERFQ2lyZnR6eVFmWlJnblcrbnB3Y09yL3Bja0NUQTRCUzJnVGlu?= =?utf-8?B?a2p3R2JFZmNWclUrRGd6dmI1akhneFE4SGhHSWw3MEZ4ckl1V2NhR3hiMFVh?= =?utf-8?B?bG81endid3E0K3lEMnBOODJoTXNiclhjbnhIV1M4VVlyS2JqNzZ3dDRtdVNY?= =?utf-8?B?dVVETEx0VFZ6R0NEeHh3ZStVWTRNdndHS3FrUHRwWWhtTXVVNTJybHgxdHdG?= =?utf-8?B?WlFLenJZTnN3VmdCYldYcGhyTTZPNHFqeTJXTUM0MWhST29Ha29DV1phTzZl?= =?utf-8?B?amVWbFJISGZuN2J3UFBiWTZkdFZZV1FDZmxFdVY0NmlFZ01UZUtWTlBrUXUy?= =?utf-8?B?ZjJlWUs1eVFJazdocTJEL3lNdUdZUEN0S2UxR0E0U2orS0pHRVVyOTlKOUg5?= =?utf-8?B?OFlqMVM0dElHQnhnWDNGWmpVVGRRNHBXdGQ5NExRTThVakN3aTRHd0hUS1Ra?= =?utf-8?B?Sy9VYkY1SkFFVEpJOWRaNkpINzliOTc2UitHWTc5ak5BSmVYK1VwckhyMCtH?= =?utf-8?B?V1paYU5hT3lzTUhYTzh0ZEFyWFRkUnRyWjhwbWd0QnFISHpDYWtqc3NYbjBm?= =?utf-8?B?T0VxU3RoVXhmeTRyRGZJRG5Nc3kwUVVPK2J0OUpGRkdMUUpLb1phVXhFejh3?= =?utf-8?B?a1luWjdVZk9vSFh4MjhiZU0renVTNjRiTVlNS28xY21xQ0tzM25OOG9QY1gx?= =?utf-8?B?YlhIbFJ6R0ZrZzhXQ2xHOU9yQzNaUk81UDQwTmRRenROeGF4eEppVjJtcksr?= =?utf-8?B?Y1ZXNGowRFZya0lpdlhnak5yS3RtY29FMWZVQjhwN2kzNWlnYUYyK0FDVU96?= =?utf-8?B?dXQrOUZFeXpNMXNwUWo4OTM5dFRFRGdDVEZIOS95SWZkT1ovYUdwUXpxMFJz?= =?utf-8?B?VjNuaVR2RGVqQkFyNkRHVm81QTV6SzZkdWZqZFVqc0dvVVYxKzNPYTg3b2w1?= =?utf-8?B?dU1oaGhPWk5GSTQzVXErTk5EeURNQmw1OFJ0N21aT1hscDY2YSszSDRZQU5o?= =?utf-8?Q?PIF8xVjMxMIEdLWM=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 33772b5c-269f-41fc-57ed-08de4d15a233 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2026 11:20:44.4842 (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: xQ1owL2BG7tH0SA8Csk9FmcwPnn83hrlulg93zzysXbg2f46gsEjYr9fE1JzudXoK5cTtzZV+FWLbDZB1Tp3h38aFxNXE84j04d1Td7PavU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR03MB7170 On 06/01/2026 7:37 am, Bertrand Marquis wrote: > >> On 6 Jan 2026, at 08:33, Bertrand Marquis wrote: >> >> Hi Andrew, >> >>> On 5 Jan 2026, at 19:14, Andrew Cooper wrote: >>> >>> On 05/01/2026 12:24 pm, Andrew Cooper wrote: >>>> eclair-x86_64-testing: >>>> @@ -104,6 +122,33 @@ eclair-ARM64-allcode: >>>> LOGFILE: "eclair-ARM64.log" >>>> VARIANT: "ARM64" >>>> RULESET: "monitored" >>>> + EXTRA_XEN_CONFIG: | >>>> + CONFIG_ACPI=y >>>> + CONFIG_ARGO=y >>>> + CONFIG_ARM64_SVE=y >>>> + CONFIG_ARM_SMMU_V3=y >>>> + CONFIG_BOOT_TIME_CPUPOOLS=y >>>> + CONFIG_DEBUG_LOCK_PROFILE=y >>>> + CONFIG_DEBUG_TRACE=y >>>> + CONFIG_DEVICE_TREE_DEBUG=y >>>> + CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y >>>> + CONFIG_EXPERT=y >>>> + CONFIG_FFA=y >>>> + CONFIG_FFA_VM_TO_VM=y >>>> + CONFIG_GICV3_ESPI=y >>>> + CONFIG_HAS_ITS=y >>>> + CONFIG_IOREQ_SERVER=y >>>> + CONFIG_IPMMU_VMSA=y >>>> + CONFIG_LIVEPATCH=y >>>> + CONFIG_LLC_COLORING=y >>>> + CONFIG_OPTEE=y >>>> + CONFIG_OVERLAY_DTB=y >>>> + CONFIG_PCI_PASSTHROUGH=y >>>> + CONFIG_PERF_ARRAYS=y >>>> + CONFIG_PERF_COUNTERS=y >>>> + CONFIG_STACK_PROTECTOR=y >>>> + CONFIG_UNSUPPORTED=y >>>> + CONFIG_VM_EVENT=y >>>> allow_failure: true >>> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/12604499722 >>> shows 122 failures in otherwise-clean guidelines. Some observations: >>> >>> llc-colouring.c uses binary literals. These are safe to use now since >>> 4.21 with the updated toolchain baseline, but the Eclair config wants >>> updating to allow this language extension. >>> >>> ipmmu-vmsa.c has a git:// url inside a block comment, which is >>> considered to be a Rule 3.1 violation. In principle this ought to fix it: >>> >>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl >>> index 7dee4a488d45..8f5fc6c93bc5 100644 >>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl >>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl >>> @@ -60,7 +60,7 @@ removed by the compiler, the resulting slowdown is negligible." >>> >>> -doc_begin="Comments starting with '/*' and containing hyperlinks are safe as >>> they are not instances of commented-out code." >>> --config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*https?://.*$))"} >>> +-config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*(https?|git)://.*$))"} >>> -doc_end >>> >>> # >>> >>> >>> but I've not tried it yet. >>> >>> There's a R8.4 violation against __stack_chk_guard. I think this wants >>> deviating locally, because it's a fairly magic construct. >>> >>> Other than that, there's a smattering of violations. Some will be fixed >>> by some work I've got pending for the x86 side of things, but most are >>> specific to arch/arm/. >>> >> They are quite a lot of violations coming from ffa. >> I have a pending serie on FF-A waiting to be reviewed/committed. >> I can push something to fix the findings after it, if that is ok for you ? >> >> I will retrigger the CI from the branch corresponding to my serie and work >> from there. >> >> In any case, very good thing to activate all those and check with the CI, thanks a lot :-) > There are also a bunch of optee ones that i can handle in a patch. These failures are non-blocking in Gitlab CI right now.  Therefore, fixes can come independently of this patch. Once all the code is being actively scanned, I'd like to see about creating a new blocking ruleset so the rules we've cleaned fully across the codebase are enforced. One point that was only in the cover letter of the original email and needs discussing. In ARM, MPU and MMU are mutually exclusive, as are VGIC and NEW_VGIC, so I can't find a way of getting ARM64-allcode to really match up with its name. I strongly recommend deleting NEW_VGIC.  It's had 0 development on it since it's introduction in 2018, is causing problems that Oleksii has had to work around to improve domain/vcpu allocation in common code (done now, series pending), and it has corruption problems when destroying domains (noticed during the review of Oleksii's series). MMU vs MPU is harder.  I'm not sure if it's even feasible to make a build that contains both. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 06 11:42:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 11:42:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196045.1513909 (Exim 4.92) (envelope-from ) id 1vd5Rf-0005pM-OM; Tue, 06 Jan 2026 11:41:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196045.1513909; Tue, 06 Jan 2026 11: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 1vd5Rf-0005pF-LH; Tue, 06 Jan 2026 11:41:51 +0000 Received: by outflank-mailman (input) for mailman id 1196045; Tue, 06 Jan 2026 11:41:50 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd5Re-0005p9-FH for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 11:41:50 +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 aef53e98-eaf4-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 12:41:47 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by PH0PR03MB5687.namprd03.prod.outlook.com (2603:10b6:510:39::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Tue, 6 Jan 2026 11:41:44 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9478.005; Tue, 6 Jan 2026 11:41: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: aef53e98-eaf4-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=KhiAvqk8lIcfxxssu1Psl0IKqCmpLroMEKcGyWfkp27z1htGfN2wCNg53inrWmE48T5d10TGAcXwLXbNek6wlvTWOpgz5IVDUatMqv9wTWQyGJ2GFXLUZD3gLj8iqSTTmVn3DJyreOYL8e52UQ4KcP7eAxrk0ftKXePnO247Qgzt9zI6HKoVAQbjEDZr/iP/nm8WGEFBQCIJkVxE3ufT62epgwXEK6aDzSa8RcIXySX3DeUpJTbuVDYkG6uhaLUCihQFlXXlVXO5vCxSullKunB4o8lp/X4Yme5CgiH6hjIPr+fG8VCCVeCRI6joDor2XdX9l+vr3gzjR95S5F1+5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=X1VX6iq/jsPPCV+Nae6kUP/AIiuXAfJEYCYZBK32dQ8=; b=OM8r5iIK1GObMzacgAoCr3lcoRQnKYKEt0FoXZaepWG6hEYfg1hBWBzT/B01mbeYFy1uppCQeaIVm4ytzcbR0eocYxF2heqxMr8RvBUzqqO+KNTX+Jq/4zsN/JL9BFPk9yHtNv00UZw+BfHVJj2bfK+Ps+I0rYJuNxz26vyd+cmyM8KnkHTL888ak/qonuJvSnove3nJgdJvKId132hKnJNFBgeKzwrEmwqfAZfL2Q3r/UkO4DyM/mdYnpfI9EpxZnUevZiDnO/teRBtzWYlQYNL2ZD/afGAlv65y9CLWXGnneqbxn6oGAytYMbHa22Nd+5s/lAHmML2nSaS/X2nVg== 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=X1VX6iq/jsPPCV+Nae6kUP/AIiuXAfJEYCYZBK32dQ8=; b=omkMl0YXijFV9NFv8RH2pqdufSLyxOl/YzJAk2EQv25b8gq+IcK+F8/L8B8oUMgmWFNJzkM0U+OLESKfQ62CZ7IZ/lweVI4alKNgi4jrO5+Y8mvBexjCqdHIBi5RUy5E1neWn6butsCsZY+TlCqxzeNyg8LcgMt2K8tWiiVTdo8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Tue, 6 Jan 2026 11:41:40 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH 1/2] x86/cpu-policy: enable build of fuzzing harness by default To: Jan Beulich References: <4a8f06b9-8210-487f-9dd7-e0221e2df9db@suse.com> <5d45bb91-4ef5-48ec-b1fd-4f186f46c0ad@suse.com> <19ae296c-5ea0-46ce-9107-8d212c065257@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <19ae296c-5ea0-46ce-9107-8d212c065257@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P302CA0019.GBRP302.PROD.OUTLOOK.COM (2603:10a6:600:2c1::11) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PH0PR03MB5687:EE_ X-MS-Office365-Filtering-Correlation-Id: 4ed11e84-b8a6-4f58-7a59-08de4d1890cd 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?RnZaZUxuYXhncG1NU3VhSEw1aFZSNDhpdWNRZXZ6MFR6V3kwVTlTYTEybFFC?= =?utf-8?B?M2RUNWdVR2RJSmgwektudXZ5OWxQaVZuTWs3cFoxT0s1YzF3ZUtpa05iUmZM?= =?utf-8?B?THc1MUFCVGltOGRJSnZvQ0tqOU8xeHZCM0dMU3RUVE83YjZFNDBpN3h0NFQ5?= =?utf-8?B?RU9rWnRlT200THh1M1FvSlNqNDlDSmNiYXVyUFdwdlJVczJFRG05bmQ1YkZi?= =?utf-8?B?QVVMUmpMNDVRdlNNcVh1NGovTDFjSjJOa0xQM2N1OXRkU2ppeTQ4V2FHSElD?= =?utf-8?B?N1c4S29HZ1VzZHh2UUhxZDVqMU1GdCs4OXVYSk56OEI0eUV3dU5McUNFdWRk?= =?utf-8?B?eXYzTWhSTmNGTnE4VWtlakFaZlZHVThhU0ZCQTVJd3hiRFRabFZVZURuMFhv?= =?utf-8?B?NnpteVNPek93K0Z1Vk82elJhZitaMGMwQ21IQ0dBNmdmVnBqSGIrOGpqaUlw?= =?utf-8?B?U2pBUjdqTWdYVzdBT2FJSVJ3c0d4ZnZENWlWYThnRXhUZkJkblNXYnJqSHlQ?= =?utf-8?B?Yk1McEl3M05mUHlmN3NHVDhlbHNjWDNhbW0xU1RxQ01pZTMvb0svT2F1N3h1?= =?utf-8?B?YWlCa0xVWlU2VTB2d0QxTnNydXFyZFQ0Q0J4bE54ZlVnZ0p6K3FCUU5OUjl6?= =?utf-8?B?VzVTVHphTnpzRGMza0RwMEE3d2EyRjk1bkkwR3YySk9PcEQ2Z0FOemtTbGlz?= =?utf-8?B?QVZ3cCs3Ny83eGRzdkZGRnhmQWp6VitBc0xyWTJVa3lwK3pPZVB3akRjM2Fu?= =?utf-8?B?aXM1Mkg3N1hWeXhEQ2JXQ2VzWGNOemI4eWRLTmJBVDh2c1VmdDdXMVcrUTA2?= =?utf-8?B?aFN6NHF6WkdHTklpYzAvSGxKMWdWSkdqVTRXRksvVVRBeWhDelNGbU5DMW5n?= =?utf-8?B?MmtWT0N1Z085dU1hNks0OHcxZDVDclNTaks3KzNwdjJ4MmkwMVQrWDNOTEw4?= =?utf-8?B?OGVGTGQ0WmlZMU1zOHBKMFIvanZvemRyS0pWS0hhc0psamhVYlV3VVpvczhW?= =?utf-8?B?alZBdVlzL2xPYjV2S2VYdkVzOGRhcnZhZzR0emV2NERBanJWd3pKQnhsVlVO?= =?utf-8?B?eXVXQ2hoWnhsc21jNlIxRmNGRmFWSTRVMmJpbzVYVkRDbzAwSHBFYWl1OElj?= =?utf-8?B?R2lKWGJCRTBKdVBaQTcrN0dtaXVOcGg4LzRvNWJ3Z3NRWkF5L0s2Q1EvaWdl?= =?utf-8?B?TGx1SS9VMmtNUFhaOWhwODVVZ3BTRTd6cFozMU52aHl2R0dZd2VjYjd6ZlhW?= =?utf-8?B?MnZmWWhvY0V0aXI5WDZpK2Q2VSs0b2lIZ1VhRnJzdHNZMk9vS3hQUExRVVgv?= =?utf-8?B?Qk5LcktiTlZ4M3kxeGcrWms5Z091V09CTGtpSjBocDdkdXVSd2Y3RHh0R3ht?= =?utf-8?B?R2t3S1FwajFPU3F2NWxyYUxGRUV2TFJ4bU5SMk16dFhRdGtZWWJ3ZUVSYzkr?= =?utf-8?B?TDBiQ0ZiaHJsMElmTS9oVFRpWHd4Si9zZ0Z4L2JZbDhMVkxXT0JHZnRSVzFm?= =?utf-8?B?WTRXTzNYSCt4ZHNPSVZqMVZiSlo5d3FVcXM5T3FiaU1PYUJkT1lta2lZZkkv?= =?utf-8?B?c000ZkdwRFlMWkd1YW8vTi9sbVRyVjk3bHE2QTluQWxDT2lmNHZJQW1RS291?= =?utf-8?B?MjNHMDIxYlRoMXdtOTNIWEFlUXRHQldKQnI3T3VXcHlqdjNJUWtEUi9vZEts?= =?utf-8?B?Y2lOZVZ4ZmpMaFhqdFVkNlh2MWlveWJTNGMyTDVtZlpaV0VKbU5QSjAyUUg5?= =?utf-8?B?ZElYUFpaeXoxN3B3WGlWYzZVUDdUcWFPUUJQUlZyWGVxVVVlSE5KaytON29C?= =?utf-8?B?QkljbHV2OURjaGN3ZFEyTGU4cWJvR00zZlBUbGs3aVEzSXpJd1NEaTU2U2RC?= =?utf-8?B?cS9oNEpsMnE0Y3YwUml3WTIzTjRmKzE4VUJaa0lhYVJBbHpVQUhZdHQ4UHN1?= =?utf-8?Q?svWNjMgOyOLut5iK8MmDr0HdzUZOpM70?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UFVyS283WGdUbjJ0bDVpY3Q5VHlQK2s3U3Ztbi9JbS9iWDlONWRaVUFabXpI?= =?utf-8?B?dGpGZUlCYk9wdnhxazZybWl1cEZhOVowenJzQVUxdmhpNk14dUN5MkUzcDJV?= =?utf-8?B?ZFNidFo5Wm9SUFNpTlpBaFhMUlgyNTNaY1R3WVhjd0ZUQzBLc01keGlXYjdG?= =?utf-8?B?eVNKZG15MUlUbW01OGNWVmNOZUZKTkZLNFpBT3hCc3NlM0xmN2x2RzBjMDcw?= =?utf-8?B?WVFGY1JGeG4vSHJ5bzhKU2RkOXlpZGV4UzNCZlZmVDZXVW9Pb01qdFhNa2RJ?= =?utf-8?B?YXdIYW9KOGo1VVJlQU5vcGZDZGRCaHFvR2x0bzl3OXVsOXlKcDZ0TzlYOExl?= =?utf-8?B?ajNJUGJla0hjdWcxMHAvbDJ0WWJ1TTdsUmJCcWdBckVoTU05Uyt0UDk0MXBJ?= =?utf-8?B?MGYwcjVIZDFYc0Zpb2lpSGJxT2NOVDliaktEeEdrRGtseG5pWU1JYzZXUjVa?= =?utf-8?B?RjU1ZnBjNzVLNHFpNHdMNy9nMEtxUGRWOHhITHZQWUFYR2xXdE85dCticHFZ?= =?utf-8?B?NkMyVXphTlJVNTJNMzY4NmR1NW1sYlEyeFVZdUhVVGd6MVk2LzRmTW1vejQ2?= =?utf-8?B?dEdEYTFWYzE0VUQ2R2xzSXFyZXU3QmVUV0s3VnZCWnpiS3ZlQTBnT3NkaE91?= =?utf-8?B?VDdDZFdCS21XNmh5cS9Payt6Z0x3L2dWY2pDRERQSjFZRldwYVFUZGMyOHRX?= =?utf-8?B?WE96c3cvV21mbUV4VFhpSmI4ZHRxRjhCRWZvblBVMlJYdlNaWEJmaE1NcTRE?= =?utf-8?B?K1J0OXdLdEZseVlpRWhjQ3dnWWhob0dFWG5ZNUlURkFzQjNiTzQvaUd1eG5i?= =?utf-8?B?bHdPNkJ1amhya1YrRi9pMVdIYU1ycVkzVDlUZkhhM2QzS2lzaWRKVmRXN2lB?= =?utf-8?B?QmFTanRlOEVkVDY2blRTdDRUM3diaTZyd01pMWNSTFhScnFZaDg4ZGs2anY0?= =?utf-8?B?cGpRRHVaVmlsb2RoSVplZ0lVUTB2VXZLcDZCcm9XMUFpT0F2QTN4U0Z2V2Fo?= =?utf-8?B?TlB2RzQ3ZWVwelBMN2lpd1NrYW95ZmN0dGxPUndtNG5wZjM3T1Qyd29uZU51?= =?utf-8?B?S2pOdGZhL3BuSC9kZnorcW9rTW1PeGZwV1NEZ1NJVC8yL09IQmZiYm9GaXpO?= =?utf-8?B?VU55dG9yWU8xNndSNHNVL0RXVTBtYmFDdkJZc0dVakUxcVY2aWhQdTFBdkdJ?= =?utf-8?B?ZWt0RUpQQlpJandhNTRIS1hyekZCbWZKb0RrYXIrUjVIZmw0VU1NaFFCWndO?= =?utf-8?B?NmVkOXE2YXpPYmNNcWZWN0RaanRXUHhIRDhiQmdOdmxlR3ZTWTJZN05DS0Zt?= =?utf-8?B?TkNhRFI1bWlLaHgzVnlWQXhhWmJ0Q1dhR3EzVmUzbXdXWGltWDR0K1lCUWlO?= =?utf-8?B?M2xhQ0laZTZtakc4aTFpQllyNGd3VGpNSmZyeVA5QzMxbWVyTUt4VDZTNFl6?= =?utf-8?B?bjdCS2Fzc1BVSjdyS2U1SXRSV2RNRTAvZVUwNi9pRkxaZXF0Y3o4VmlGZXlt?= =?utf-8?B?ZzBoSGxmcmtQU011ZzVnL05yMlNzWU5lUnVtSXZuQndjd05OZ0oweVBPdEhS?= =?utf-8?B?N1BYb1FabXErdU43cGZOd0cyeFJrRG5wMGJrZG9tTDFwQlhTaW1nclEzdWNw?= =?utf-8?B?aHh3b24wRWtDR3F5UGJqUGNGbmE5ay8xcU5OVWVkVEFjdUUyWTF0YUI4bElm?= =?utf-8?B?R0ZqeC8wL2ZWdGNlRzRwc3JVYzBKOGlaU0JKNEhRY040QVBvU1Z6VkV3ZFpp?= =?utf-8?B?cXJESXFIVVplSWFpVUp2MXVHUVRUNm1ONHUxUEYwOHRDSjI2NjdaeENNV2xF?= =?utf-8?B?L0ZXTW00UDhJVzluQXpZZXNydURLRzN1eHNwQStjQnZLVU5pVEtWSGtmSzds?= =?utf-8?B?YldVem5kWm5vaGd1VW1BWWRQSWdFbGZ1TnZ2WUQ4QmhHNXFqOThkMk5nY3BC?= =?utf-8?B?K2VCby9zaGlJTisxVXc3TitvNFd2SG1MTWFNR093SGpGTmxkT1ZpS3ZXSGVt?= =?utf-8?B?czIrVjM2a0V3bE1BckFEQ1MyOTQ5ajY4NjBJUHEwSCs2L0pKUHJ2STRSZkVz?= =?utf-8?B?SnpvbGxoLzlLcndJakNST05yT3dvcFdLYU1wajIxL0dsdVJqK3k2NHM5Q05T?= =?utf-8?B?Zk9JQnpjUENvLzlkU1JEOWZPNmg5SWJuc3JJS3lBT0dWRzhkTVp4SGhndUJn?= =?utf-8?B?Y1VVcnUwTVF5Wlo2Zzc5MlE1Y1RQQ2tmMkNjTVNyZy9udEVMdE9qZ1BKNDE0?= =?utf-8?B?cVl3WEZTU0J5V0FQYVhqT0VpOTg3c1VMWnJEdmRvTGVzd0UwRFBDYUpqN0tJ?= =?utf-8?B?UFZ3OTlrSFU3Zm53UmRaR0VpWVFKOTc0S204dkJidG9VTVNwMERwME1oUkYy?= =?utf-8?Q?J3JoZbWWzXbC2U4I=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4ed11e84-b8a6-4f58-7a59-08de4d1890cd X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2026 11:41:43.8621 (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: GyzZ9muzKNyIctiXvyIVNSrcI4njo5VYJ7YyPfTpT1N3brXMTlFCRw0UQyfOsFkjI+0025IIysxbNeKziPBzI9Ysdsa/NBY8dXe1cIURs4M= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB5687 On 06/01/2026 9:49 am, Jan Beulich wrote: > On 06.01.2026 10:36, Jan Beulich wrote: >> On 22.12.2025 17:53, Jan Beulich wrote: >>> ... on x86, to make sure its bit-rotting can be limited at least a little. >>> >>> Signed-off-by: Jan Beulich >>> >>> --- a/tools/fuzz/Makefile >>> +++ b/tools/fuzz/Makefile >>> @@ -4,6 +4,7 @@ include $(XEN_ROOT)/tools/Rules.mk >>> SUBDIRS-y := >>> SUBDIRS-y += libelf >>> SUBDIRS-y += x86_instruction_emulator >>> +SUBDIRS-$(CONFIG_X86_64) += cpu-policy >>> >>> .PHONY: all clean distclean install uninstall >>> all clean distclean install uninstall: %: subdirs-% >>> >> As it turns out this causes build failures on Ubuntu (and only there, and only >> with gcc, which I don't understand): >> >> afl-policy-fuzzer.c: In function 'main': >> afl-policy-fuzzer.c:153:9: error: ignoring return value of 'fread', declared with attribute warn_unused_result [-Werror=unused-result] >> fread(cp, sizeof(*cp), 1, fp); >> ^ >> cc1: all warnings being treated as errors >> >> Given how the code uses calloc() up front I don't really see why evaluating >> the return value would actually be meaningful here, so I'm inclined to add a >> cast to void (provided that would make a difference, which I have yet to >> check). Opinions? > Simply casting doesn't work. Hence what I'm intending to do is > > --- a/tools/fuzz/cpu-policy/afl-policy-fuzzer.c > +++ b/tools/fuzz/cpu-policy/afl-policy-fuzzer.c > @@ -133,6 +133,7 @@ int main(int argc, char **argv) > #endif > { > struct cpu_policy *cp = NULL; > + size_t size; > > if ( fp != stdin ) > { > @@ -150,9 +151,9 @@ int main(int argc, char **argv) > if ( !cp ) > goto skip; > > - fread(cp, sizeof(*cp), 1, fp); > + size = fread(cp, sizeof(*cp), 1, fp); > > - if ( !feof(fp) ) > + if ( !size || !feof(fp) ) > goto skip; > > check_policy(cp); > > along with amending the description: > > "Since on Ubuntu fread()'s return value needs evaluating, adjust the code > there to also skip the test when there's no data at all." > > May I keep your ack with that adjustment? Yes.  This is just harness code, so whatever compiles. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 06 12:04:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 12:04:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196062.1513919 (Exim 4.92) (envelope-from ) id 1vd5nT-0000Qc-LO; Tue, 06 Jan 2026 12:04:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196062.1513919; Tue, 06 Jan 2026 12: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 1vd5nT-0000QV-IU; Tue, 06 Jan 2026 12:04:23 +0000 Received: by outflank-mailman (input) for mailman id 1196062; Tue, 06 Jan 2026 12:04: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 1vd5nS-0000QP-2W for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 12:04:22 +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 d190c7c8-eaf7-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 13:04:15 +0100 (CET) Received: from AS8PR04CA0039.eurprd04.prod.outlook.com (2603:10a6:20b:312::14) by AM8PR08MB5588.eurprd08.prod.outlook.com (2603:10a6:20b:1d4::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Tue, 6 Jan 2026 12:04:10 +0000 Received: from AMS0EPF000001A0.eurprd05.prod.outlook.com (2603:10a6:20b:312:cafe::65) by AS8PR04CA0039.outlook.office365.com (2603:10a6:20b:312::14) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9478.6 via Frontend Transport; Tue, 6 Jan 2026 12:04:07 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by AMS0EPF000001A0.mail.protection.outlook.com (10.167.16.230) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.1 via Frontend Transport; Tue, 6 Jan 2026 12:04:09 +0000 Received: from DBAPR08MB5590.eurprd08.prod.outlook.com (2603:10a6:10:1aa::17) by AS8PR08MB8221.eurprd08.prod.outlook.com (2603:10a6:20b:524::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.5; Tue, 6 Jan 2026 12:03:04 +0000 Received: from DBAPR08MB5590.eurprd08.prod.outlook.com ([fe80::f68e:1311:9070:68b]) by DBAPR08MB5590.eurprd08.prod.outlook.com ([fe80::f68e:1311:9070:68b%4]) with mapi id 15.20.9478.004; Tue, 6 Jan 2026 12:03:03 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d190c7c8-eaf7-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=eXEBGZ2eGIvlo0f7TNX+vysPxEmtLA7VQoXzUP9Ndo8Q1rSC2SLJuoJkcty+A3Ut1jL/XtIiF/g/W2idVVn3vG09j1MiKuKrcUiMaW0R2wUt/wtZGFfC/VbS3JMMmPrMbiveIzvv7u364jGQZB+A+FXiH/tsr9GynrwlGYkOm6w88+3ev+SHP12ybvlJazmm2LmoLhIvmKykkGP413XCUNnUis05buJLGM4a6lQsjxLKZW5iVW0yjZdw6pMRFg0Q3kCi+1Bx2lCT3HlbvsXk8EnTUEEj2PQkddLa56CsDcCiFJfQUW8WiR8w+ySdvykAY7JgkHXOhfcvU1vOkyLz4Q== 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=QLDwNF5wRePAW3G3MXfAr7V6jc585+UVl/pYwIObaSk=; b=rNd/ojOxcffYFPwFAZG0RSMJ/d50z2T/sbIb2cUCJtX+z6A9p8eZuE3IiDo7BKg3RacikvEHcz4Xj/zwJF9D+3XX16vik7XA5TdESlAsCHKjpq0xFy6vrSafoDOOUelI/tyIULSX8oWQMIYGI2prvOHOf2Pn/4q41kvgoJ1QAGYH0GCuXC6rnLUfAFCcOn9kyq3KNEUDmO05MYqG6H7hEvbmVspLgqkuz9y5tQt5h48soW86pOp6A+awS4vxHvcOiaGDBLM9sJtgRZ8xoVNw64jrqlvtEbw3QadT6vBpbS+YqJhcP7+eb5T8LbpvND5VWndsohy1ChLcPVWV4KB47w== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=citrix.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QLDwNF5wRePAW3G3MXfAr7V6jc585+UVl/pYwIObaSk=; b=U0BzgJE2Syj5rDa6VWxnL1NcohZBr3BycX/kpY0N2CT1D/1swALDhHhmAdne8VHRlgZs4hLSxH1zlI4VKRfr8uwXBOGTJAdZOr0W7T57WK2UclsCGs3HvRU4M5YY+FU+DpYenojNroR43aWIImPKVjefrs1tlaRf9L0y/8Jbrwo= 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=MAripRtdM7P03gfJ3L8FHbg50+4JWWllELFaVh5k+opIiGpYiHLabsB/zISQ0jOI1h7VeG7ExR3V8hHK/8m8xRBkr3uwy8mYRsCvcnevK0EOfM7h0dwjY7Ah0+bKZj4RuCMQLcTOvWAH0EJpd1jQmUrFixhi20r3iSiF3C5uqZNFgCOCNsZ4yVuKJY5nYxZabMPNrBN698JDR+OScAaXKMczXknM4+f5WJNwxZ8h3WMLQzVP4HzHzw/J/LCPFCdmcEyxMuorrWa0P5XXCdu5bN984pR4n+QA+IZ3OqJPjzW6nAdjjxNVE8sAiyRafO3bLFkIdVr+r9sokduNUC3RkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QLDwNF5wRePAW3G3MXfAr7V6jc585+UVl/pYwIObaSk=; b=iDcGE+vfDWbSX2sWbOrZSYh4IbU+zlPpPw8/iiMT+TeKa90blm+l5VXCM1A7B+lLf+ndX8X5BSDr4Ip44eHc2IP6YhEJNsiSHHgbFAymRGl83OSzJA7YJKvOs59xQXpZv7YMZtwz65RBeLYTpPgEszWoz4+YYT66LRKVMfZwmAQx9Ja9XHzIqVfYlb/52lkC9EL8J0Q0zuXsZV0bov2DiKBtI3Z8l9P+szvoPq1UIQpuHyh1xOUb+hgI7n++FJrMRd+CEpgSreuril29hU4oq06ZIuMMgCNviRY5D4alKpEIhR3tME0AO+O0s1HYNQnS+n897GtRyS4H6qipkgwcog== 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=QLDwNF5wRePAW3G3MXfAr7V6jc585+UVl/pYwIObaSk=; b=U0BzgJE2Syj5rDa6VWxnL1NcohZBr3BycX/kpY0N2CT1D/1swALDhHhmAdne8VHRlgZs4hLSxH1zlI4VKRfr8uwXBOGTJAdZOr0W7T57WK2UclsCGs3HvRU4M5YY+FU+DpYenojNroR43aWIImPKVjefrs1tlaRf9L0y/8Jbrwo= From: Bertrand Marquis To: Andrew Cooper CC: Xen-devel , Stefano Stabellini , "consulting @ bugseng . com" , Nicola Vetrini , Jan Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Julien Grall , Volodymyr Babchuk , Michal Orzel Subject: Re: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible Thread-Topic: ARM64 notes: Re: [PATCH] CI: Extend eclair-*-allcode to enable as much as possible Thread-Index: AQHcfj5G7fNp7PSkb0GiHPxZx0yorLVD4eGAgADfJYCAAAEpAIAAPk4AgAALzIA= Date: Tue, 6 Jan 2026 12:03:03 +0000 Message-ID: <9FC8579A-066D-488D-960F-737FDFCD1005@arm.com> References: <20260105122436.555444-1-andrew.cooper3@citrix.com> <82d99c52-c39b-4fbb-bbb2-0e952df91673@citrix.com> <0e1e877a-a8fa-42aa-8546-ee66f9287e18@citrix.com> In-Reply-To: <0e1e877a-a8fa-42aa-8546-ee66f9287e18@citrix.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.300.41.1.7) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DBAPR08MB5590:EE_|AS8PR08MB8221:EE_|AMS0EPF000001A0:EE_|AM8PR08MB5588:EE_ X-MS-Office365-Filtering-Correlation-Id: b4c8d57e-2573-4128-1477-08de4d1bb323 x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|376014|7416014|1800799024|366016|38070700021; X-Microsoft-Antispam-Message-Info-Original: =?iso-8859-1?Q?f8tqyyw05Em2ZligjZXWRE1UuEwAyxSGh0RPE/zcbao4N1EcEH4PEbIjvA?= =?iso-8859-1?Q?5A2edoJELByr7CHgKKdrK/HozripYlE3Pv4maMbepUqOUnNeDcFyyhO7oT?= =?iso-8859-1?Q?ayvtkOTUhC2nev8vuGJ+JeqGCrSkf1DtuEb4ddj+wtuh+G+VW5njf7CmhK?= =?iso-8859-1?Q?9SzvXiwAl7CWFexhA2xUPDH8V8KUIygBb49OOcDKFV5Wx/+CGJaENMvFOf?= =?iso-8859-1?Q?aXgA6eSw8GMMQD6SesZ2svDQzJe2uhSV8rsa+tcT18TFt3iq3+uAdGIygA?= =?iso-8859-1?Q?9USoxpHg0nL2KFnZbrzKDB0hp2VqwgYDt1LRwoVTR605KblTrhpywFALGm?= =?iso-8859-1?Q?3Cr1dcOlaxtx/J7n4ZFx7oANpBYyPt90s8d4CV2+FCgqWd48vBIrJGYbwo?= =?iso-8859-1?Q?QyS8fdrD2y819wwjdgJwLZi1vY1C2FQ5q11tvw0KeSXEguukqArpabQNWC?= =?iso-8859-1?Q?9KJfHDXkQwVSw/9mrXIDbnLHlGoQ1CnzWxXZn9Iodyf77G1OAzn221+UOC?= =?iso-8859-1?Q?1qLIBHA/0pQFOfAwpRjV7XyfJln2xcOqWeyRxZRku9I0f2y9l6riVWOIYW?= =?iso-8859-1?Q?tCHbGrAzxiErUYSxyBpk8GeiWrSMfJhUccPxMzhchfZLe0JB1UybTl6BI6?= =?iso-8859-1?Q?pUKnoZc1aO9bebdl7EpC4envyx4U6UCkXuRab+1IlIakb/zJKw3LAP0LsA?= =?iso-8859-1?Q?Cu2pBK6A7rZkfiAaaP7kLmZJMjzeK+R//xiY6mFxk68MeIz5Df6pSCujeT?= =?iso-8859-1?Q?zWVb3rH29aSDAk9wNQpgduT+XyiJtaXEHrjiGuv3m3s2eDp7GF5DGwUsLB?= =?iso-8859-1?Q?oQutbCrJRBYXqTdXALrymSLCnLTCIwIaKD70AYM0LOHjwvgrkT1mrV5Lpt?= =?iso-8859-1?Q?ACFCb1yqgLzbvuW9a3gTTQCrtz/YjpjEvmLDYk/BdluiirmyvEiV9dEZwQ?= =?iso-8859-1?Q?ej6rU3yP2iwoGr8NcB/RiPnpV5qw2UizqEXMmW4n4RVilgtRDNxwOZ/D5y?= =?iso-8859-1?Q?1OBbLxVcVsSuOSCCXxBRHG0PqhqzO1I6MOh6c5e1hO8GeTYdGsAFHf8ck2?= =?iso-8859-1?Q?onWygA9Fx9+G2aeGcTaiY/6Meqzk78rn8gX3c0LZOpMCVBZf8FzzGZYulM?= =?iso-8859-1?Q?OezNKQ1CjN+R8eYBa15xSpX4KhO2EACWnjXt8+b8kpiafVr0FXCg5MXjY4?= =?iso-8859-1?Q?brthFpZdlxC7H8mr0tXIHby+g9p+u2swHFGI41JYRwjET6YAhSFph0CXA+?= =?iso-8859-1?Q?LpnSZJsE+lWXy0edENLlzG0wTWVy1hFVFs1X640mGk4KNtpOyJ1VxZwsO8?= =?iso-8859-1?Q?TJzOTgNKET4/jmqOb3EB8OP45dzBYoQUuXG3l4ZVBoVryCX6Vt5oHmd+y1?= =?iso-8859-1?Q?MWm3Ih/wXAHfTEwqugD60roGC0T8OBuxDjsaPPouM2bWzUht0zzL2E2cmx?= =?iso-8859-1?Q?e98ok4yExBpWd7hO0n996UFl1zhL4fcXoVKiSrEgtom/8oe2ehOGrSInw3?= =?iso-8859-1?Q?0+RAgE4jJlgOopNx1O7nut/3BfvHKdefIku+dXJbnfHRbft2BFdbE/VKe4?= =?iso-8859-1?Q?nXKZZaLaEOajIyh/Q7HGa3YzVQRw?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5590.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(366016)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <42149D0448CF494E83F7AF4CA3A93A5F@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB8221 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AMS0EPF000001A0.eurprd05.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: e0476ff7-4c14-4533-6d7e-08de4d1b8bd6 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|35042699022|376014|7416014|82310400026|36860700013|14060799003|13003099007|7053199007; X-Microsoft-Antispam-Message-Info: =?iso-8859-1?Q?JBAJsH0F7nJSCpgWYG6cEklBdCIa39a6oKW7/LN3TIArQq23hW+rLfANNV?= =?iso-8859-1?Q?XIQY5Jm+jWoXnPtrBiGcw2nX0S+3Vo280KTS19MeIETVqAn4RzkjdgBcY7?= =?iso-8859-1?Q?SAYvymaAQlRQ4Iaa2haz/XPA3mCG2bm3t+72RL+/LRNETNLi7l4pGjNH64?= =?iso-8859-1?Q?X9hm30KKoO7TEknvqgq54mPg3ebd0/wuntPTxNKS4nK7VuxvmFHnCRadm8?= =?iso-8859-1?Q?uUGy/6xs7y6nf3hA8r3FPx0D1nA5UGEM1lWblgb5nD+RnQrknHT92VWVs9?= =?iso-8859-1?Q?e1/FDX9RWm+NROu/3RbyoC/J0NKDiVmrRTGPnfu6xhElUPXtwvsebtqCtY?= =?iso-8859-1?Q?JTA5FFyU0qWpR3h1kRvnsH+bI3HOD3mwgUBsIdwYYOLLzPfSP7hMgF9HJs?= =?iso-8859-1?Q?uRa6MC0C1sqK1/uoLwHh+L57AET51sAOnduY9orf/Mv3aAHTFKI+Ky98L1?= =?iso-8859-1?Q?9ctKGVLdL3Ep0/35UlzIpE5c+p4REsUBDyqZwSu0Xyyw2jkU3kMN2ktgD8?= =?iso-8859-1?Q?oi3rz3UJRJsHUJsdpIcj3n/fo+tsHbp0XDGVOXczRbEFtx6rmoBXZJ3hfp?= =?iso-8859-1?Q?ku2h0uvPZJ8hvquelAl0uisE9iNPyxD2Y3X15AEyKvw/9/KDIHZnnU/KGk?= =?iso-8859-1?Q?CKR98a7NJrCKB8mOeNmUuerYjfOENy5wSLnblnV5YO8TrmJG4QreYxrIpy?= =?iso-8859-1?Q?kstKkCsHjayMLVf9HUSthjQ8PuXuMtt35mU7eV8+vkVM/7dy8Qol5G2fYC?= =?iso-8859-1?Q?lWIUr14ZLL4iAsNIjz9IaTpdh/DNQy2k1G5UZSsGr8D2+pu/ZIwIYl5Ggk?= =?iso-8859-1?Q?Isqi2PqcNthXAt+aOpcuN3FzbMg4m5FZeCJYQHah6n/scT+mKffRFsXaFq?= =?iso-8859-1?Q?Co89rfTERg6UbuipJ0je0SEfUJOLD906iJe0Y2jB++l0v1dcfBHzt5akRf?= =?iso-8859-1?Q?S0iEqTP78xa5Ct5asizfiAVaPJIYJ/YuOuIzm48IjNzSoMKXai9oSzUxAl?= =?iso-8859-1?Q?AlqwpXEjQbNhW5D0ia/ajbuYW+uAD/EHBeRtQUxgPK6teeHAqSEQ5TWHjB?= =?iso-8859-1?Q?5qTxRg80hl5nVxCDbX18Uuf1nKg4gpvMkBp7GfyxGtLtBkmMYyDlue2t1J?= =?iso-8859-1?Q?xd3W/Kn7Du44StIbpFJ5BEFL/zvL2VGL5yYBzByk7SwRfcPjldRRnM9Zmj?= =?iso-8859-1?Q?1EnkHPhzRXZfDwdc8OecaDHC0t/3KAo9ZHk9sdmij5aBO0xwbgq3kg7EmH?= =?iso-8859-1?Q?lhhqtUxB8sE5Fvckd9xhdO0HV5yfvn7vzFdkxoRXjMjwYiX7DBiDD4252U?= =?iso-8859-1?Q?p8OxUsMhF6v3X6eLC98FAN6+py326wSIEprMoUWOHQweEcyok4UNa8lXrW?= =?iso-8859-1?Q?f30VfufkJ+1jZORIpJ3VQE/SUSCgnid4YouMC+J1jaluLWme4ZmeCPIr3i?= =?iso-8859-1?Q?QjaOqFjzX4MSYJxc3jZAeaWH0pawEpWrIn8DPQh9vP4cb6Bi8rUZSr47Og?= =?iso-8859-1?Q?zMN42db1upWHx3xKC41OdVrza+OZDtKfXBRDa6CpitdubfynxcfZHWjTe9?= =?iso-8859-1?Q?+8aFIRLEW+dbJ5od5BIMKlkksM6yPennQ8rDGV3HBHsT5aU66hRYNEUrGl?= =?iso-8859-1?Q?V1FvHUNBymsvk=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)(1800799024)(35042699022)(376014)(7416014)(82310400026)(36860700013)(14060799003)(13003099007)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2026 12:04:09.7057 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b4c8d57e-2573-4128-1477-08de4d1bb323 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: AMS0EPF000001A0.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB5588 Hi Andrew, > On 6 Jan 2026, at 12:20, Andrew Cooper wrote: >=20 > On 06/01/2026 7:37 am, Bertrand Marquis wrote: >>=20 >>> On 6 Jan 2026, at 08:33, Bertrand Marquis wr= ote: >>>=20 >>> Hi Andrew, >>>=20 >>>> On 5 Jan 2026, at 19:14, Andrew Cooper wro= te: >>>>=20 >>>> On 05/01/2026 12:24 pm, Andrew Cooper wrote: >>>>> eclair-x86_64-testing: >>>>> @@ -104,6 +122,33 @@ eclair-ARM64-allcode: >>>>> LOGFILE: "eclair-ARM64.log" >>>>> VARIANT: "ARM64" >>>>> RULESET: "monitored" >>>>> + EXTRA_XEN_CONFIG: | >>>>> + CONFIG_ACPI=3Dy >>>>> + CONFIG_ARGO=3Dy >>>>> + CONFIG_ARM64_SVE=3Dy >>>>> + CONFIG_ARM_SMMU_V3=3Dy >>>>> + CONFIG_BOOT_TIME_CPUPOOLS=3Dy >>>>> + CONFIG_DEBUG_LOCK_PROFILE=3Dy >>>>> + CONFIG_DEBUG_TRACE=3Dy >>>>> + CONFIG_DEVICE_TREE_DEBUG=3Dy >>>>> + CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=3Dy >>>>> + CONFIG_EXPERT=3Dy >>>>> + CONFIG_FFA=3Dy >>>>> + CONFIG_FFA_VM_TO_VM=3Dy >>>>> + CONFIG_GICV3_ESPI=3Dy >>>>> + CONFIG_HAS_ITS=3Dy >>>>> + CONFIG_IOREQ_SERVER=3Dy >>>>> + CONFIG_IPMMU_VMSA=3Dy >>>>> + CONFIG_LIVEPATCH=3Dy >>>>> + CONFIG_LLC_COLORING=3Dy >>>>> + CONFIG_OPTEE=3Dy >>>>> + CONFIG_OVERLAY_DTB=3Dy >>>>> + CONFIG_PCI_PASSTHROUGH=3Dy >>>>> + CONFIG_PERF_ARRAYS=3Dy >>>>> + CONFIG_PERF_COUNTERS=3Dy >>>>> + CONFIG_STACK_PROTECTOR=3Dy >>>>> + CONFIG_UNSUPPORTED=3Dy >>>>> + CONFIG_VM_EVENT=3Dy >>>>> allow_failure: true >>>> https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/12604499722 >>>> shows 122 failures in otherwise-clean guidelines. Some observations: >>>>=20 >>>> llc-colouring.c uses binary literals. These are safe to use now since >>>> 4.21 with the updated toolchain baseline, but the Eclair config wants >>>> updating to allow this language extension. >>>>=20 >>>> ipmmu-vmsa.c has a git:// url inside a block comment, which is >>>> considered to be a Rule 3.1 violation. In principle this ought to fix= it: >>>>=20 >>>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automa= tion/eclair_analysis/ECLAIR/deviations.ecl >>>> index 7dee4a488d45..8f5fc6c93bc5 100644 >>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl >>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl >>>> @@ -60,7 +60,7 @@ removed by the compiler, the resulting slowdown is n= egligible." >>>>=20 >>>> -doc_begin=3D"Comments starting with '/*' and containing hyperlinks ar= e safe as >>>> they are not instances of commented-out code." >>>> --config=3DMC3A2.R3.1,reports+=3D{safe, "first_area(text(^.*https?://.= *$))"} >>>> +-config=3DMC3A2.R3.1,reports+=3D{safe, "first_area(text(^.*(https?|gi= t)://.*$))"} >>>> -doc_end >>>>=20 >>>> # >>>>=20 >>>>=20 >>>> but I've not tried it yet. >>>>=20 >>>> There's a R8.4 violation against __stack_chk_guard. I think this want= s >>>> deviating locally, because it's a fairly magic construct. >>>>=20 >>>> Other than that, there's a smattering of violations. Some will be fix= ed >>>> by some work I've got pending for the x86 side of things, but most are >>>> specific to arch/arm/. >>>>=20 >>> They are quite a lot of violations coming from ffa. >>> I have a pending serie on FF-A waiting to be reviewed/committed. >>> I can push something to fix the findings after it, if that is ok for yo= u ? >>>=20 >>> I will retrigger the CI from the branch corresponding to my serie and w= ork >>> from there. >>>=20 >>> In any case, very good thing to activate all those and check with the C= I, thanks a lot :-) >> There are also a bunch of optee ones that i can handle in a patch. >=20 > These failures are non-blocking in Gitlab CI right now. Therefore, > fixes can come independently of this patch. >=20 > Once all the code is being actively scanned, I'd like to see about > creating a new blocking ruleset so the rules we've cleaned fully across > the codebase are enforced. >=20 >=20 > One point that was only in the cover letter of the original email and > needs discussing. >=20 > In ARM, MPU and MMU are mutually exclusive, as are VGIC and NEW_VGIC, so > I can't find a way of getting ARM64-allcode to really match up with its > name. >=20 > I strongly recommend deleting NEW_VGIC. It's had 0 development on it > since it's introduction in 2018, is causing problems that Oleksii has > had to work around to improve domain/vcpu allocation in common code > (done now, series pending), and it has corruption problems when > destroying domains (noticed during the review of Oleksii's series). >=20 > MMU vs MPU is harder. I'm not sure if it's even feasible to make a > build that contains both. MMU and MPU are definitely not possible to select together and will never be. The allcode should definitely select GIC and MMU, for the new vgic I think there was some people still using that for some reason a while ago but not sure this is still the case, Julien is a lot more aware. For MPU, at some point we will need to validate the code but I think we can do something like a virtual "arm64-mpu" allcode config when that is needed. At this stage, development is still in process so we do not need to check that part of the code. Cheers Bertrand >=20 > ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 06 13:46:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 13:46:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196077.1513945 (Exim 4.92) (envelope-from ) id 1vd7OF-0003um-TT; Tue, 06 Jan 2026 13:46:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196077.1513945; Tue, 06 Jan 2026 13: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 1vd7OF-0003uf-Pd; Tue, 06 Jan 2026 13:46:27 +0000 Received: by outflank-mailman (input) for mailman id 1196077; Tue, 06 Jan 2026 13: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 1vd7OE-0003uZ-Jg for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 13:46:26 +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 17d39554-eb06-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 14:46:25 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-477770019e4so8360295e9.3 for ; Tue, 06 Jan 2026 05:46:25 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0e199bsm4612328f8f.16.2026.01.06.05.46.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 05:46:24 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 17d39554-eb06-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767707184; x=1768311984; 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=nm6Bd5AlYJkO2GSMSZ5vUgv9i+yeuKEXMRTc4L+c/S0=; b=drXhM85uvJjZKP1eCuB5tnZKW+Un1lwPHX7ucKYW2/U56xU4EvRQ36bY7I0nIRZbV+ Ao/5PL83xZeeNW/9yefz/zGNtZ4UKRX9jbBrrmqLFy8TXWogLOEc4Ea2aT6lGEDRQLnw 5ztfw3zVoE7NTGjp9HTTC66p0rz7+ZIcDTErlY/cYVwUyyAKlBnCHV/ITWRZV5zHg6r5 Gw9kus2DBOvDsdrkjBmh0K+gbC+x4W/QqDaPSs7UzHS+umz2DsVVYGl2qzzj2t9QnBLW R1yd+JzJ/XQMkyDTV+L1UgjanYVH8rqq0n+PD/tDDi6OcOVOpnSmSR2qwAOSLKVA9Cxo AfFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767707184; x=1768311984; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nm6Bd5AlYJkO2GSMSZ5vUgv9i+yeuKEXMRTc4L+c/S0=; b=MOt5uOAuW9hKT1qW333kX34o/R38QnqzKVOz4gHDTqFtZke9aHm+xgfyrOtUOqO1N6 D72XjFP1XS65HaFw5I5uF06B3peSzR852ThXVA5VCx2vfcmW3GWGq8Yo/dJkOJzHucAT PIeeOi33+WEPrR4uCbmkshX/YhYgZRYLiuc1fDAcLVP7Y2TQbQJ0W7LAdsItikcLJ/JI RdXIn+CirWUyFUAdWZ4allcze74FKd1XOJaUo5oZZzmePrQBXMz5NTuTGkyPYxMRH23a 7gc+2hPmjmuScHWP/o1LamSDRiq+kPcySWqNAYobf8KnXwUifZTdlHmNua/YRa7zY9/F 1QLA== X-Gm-Message-State: AOJu0Yzjuse8TiLTHyDoVZoXfS2ZPbUdeD/Q282RENMYnyc4SE3H1f2U 5/0yHf/qwMc7wlgDx5FXNbZgskp3arXRULFskR5BKCcHL4QgPN2NGQENIN2/aPo7aYFA9WE1SUa OSwE= X-Gm-Gg: AY/fxX49KbdTo32lKCsjQ2tGafPM+ujHt+/HdYkfNatibTdDnLtAeF96Wl6tw2sSb3j 5h2y0m+2FY2HmmqmDJUccTcFfl7lZcEMuB6ZCPyKk7x4+YVlVCQjA4JtcRt/SLxFW6dnen6Mufg ulGwJfvVkj7Hknfl002BOoLOB/5myc2V+Ao8ukIZqZ9wuq20uvognOi+P/XZTQBocsuUEKj0f8n XE1ncLDoT1aiPSvkTUssD78hQVW7KnEHKbfoLdlzQtD1yS02hlDcKqaTHs+EPb4L6bM5t/ef4F7 TdJyGNOnpDWgDUKic2QZpL49tZDIFONO/OQclMSS7WmcbESfD/1741I0eyLjLjQ8gWSIyLGDshh FrHgvKUeColONDxqB/++Qb8wdi13kdCyXs2dElVXFjnIO6IcGtMTVztv3d1Ce4Jbr74zZcIg70L UAUjGXX5WjgjI0GPwcJ7VAqckrmMzvMwU01FTHcwdyqLh77PduOW0xyf5cPUDGqT/LEEhWRAos9 VQ= X-Google-Smtp-Source: AGHT+IH3UrQMVtEI+W2iH8Gvg3XFXjUg3iiqF8d0gc2sOHP618+xC/zwBWOGjBzn1BJ4AdYRhx5vZg== X-Received: by 2002:a05:600c:4f0e:b0:46e:4a30:2b0f with SMTP id 5b1f17b1804b1-47d7f0a0023mr33364995e9.29.1767707184611; Tue, 06 Jan 2026 05:46:24 -0800 (PST) Message-ID: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@suse.com> Date: Tue, 6 Jan 2026 14:46:23 +0100 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?= , Stewart Hildebrand From: Jan Beulich Subject: [PATCH 0/6] (v)PCI: extended capability handling Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This is a follow-on to 'vPCI: avoid bogus "overlap in extended cap list" warnings', addressing further issues noted there. 1: PCI: determine whether a device has extended config space 2: PCI: pass pdev to pci_ats_{device,enabled}() 3: x86/MSI: pass pdev to read_pci_mem_bar() 4: PCI: pass pdev to pci_find_{,next_}ext_capability() 5: PCI: don't look for ext-caps when there's no extended cfg space 6: vPCI/DomU: really no ext-caps without extended config space Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 06 13:47:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 13:47:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196086.1513955 (Exim 4.92) (envelope-from ) id 1vd7PQ-0004Qu-52; Tue, 06 Jan 2026 13:47:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196086.1513955; Tue, 06 Jan 2026 13: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 1vd7PQ-0004Qn-22; Tue, 06 Jan 2026 13:47:40 +0000 Received: by outflank-mailman (input) for mailman id 1196086; Tue, 06 Jan 2026 13:47: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 1vd7PP-0004MT-8n for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 13:47:39 +0000 Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [2a00:1450:4864:20::441]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 424d368c-eb06-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 14:47:36 +0100 (CET) Received: by mail-wr1-x441.google.com with SMTP id ffacd0b85a97d-431048c4068so598447f8f.1 for ; Tue, 06 Jan 2026 05:47:36 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ee5eesm4452123f8f.34.2026.01.06.05.47.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 05:47:35 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 424d368c-eb06-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767707256; x=1768312056; 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=BDLn8He9nK6XbJ/8V88KJti2+rZ0Z1f8Yos0AnCw0VA=; b=IMu9it5QrAlG/ynaM5vWLVt0djk+r8fJuMGnjOyAWOZjhntETUZ2i1PYdrZCGpcpSj tSes/WK92yUsCT2IHQeVnSgsnBpr2hFIk8kgBVPIHCkq7Cqmia0nYzqB70wGgKdi7u2k CPQDNmOkboOFgOzY1uL7kBXjlUSfmoea/XsEi/U8sCfeufXWkGet9klA22NGO8ueB2Eh lit9gCsbVye8SRIorfeyCwL/RObgLpz5AUAR+XJmPReKSGMMxz1DGDd/cyG2lUU8P6Gz 1eveofkur4wEjwIBbex4tlb2Y3+rnnWf20gdUYt2QtXO5DYJKu2YM2bH2fZNltd1VUTS TYvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767707256; x=1768312056; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=BDLn8He9nK6XbJ/8V88KJti2+rZ0Z1f8Yos0AnCw0VA=; b=Az1ZXQAaDMTIxgV3TksvaUodBE4vCtDh3aLX5J7+MIiDmijJ/DZQRgtUTN6ihwATjA j+thELNJShwDF6F12oC0LLMqlnjxRyNe5qNIp7SCpFZgJ17ZPu8PVs4EYasbV1PyLOdK mOqK2QlYDqXU9NyvB8ObrWxIW3aDDOGU9FdfDyw37MqmJNFVumfePIlHBew69kkgrjV1 jYYqrD6oSrC6i+s4siCHytQa6EnwLgFLZU9/L/fp8eUFGUEzkvmVD9PeH6956zWtzu9a ZSaBwHiE7yapDEOMPGD1i722cCt4CiHm62VlnZBeMSx+xOIRK2+QQTkABPbtiUWyNLsK Dt6g== X-Gm-Message-State: AOJu0YyI5iJHymEtX8XV3Im1Mn2qUv2ouonDw1I2PNPtxRFYHQAbWKK0 uqNO0MBPk7CiQ4xQnwPnEUdkwy7u5TfQe1G4q4TaLuH3wlFu9+9J7880JloEuRZUksbik80vwOI tDHgT2g== X-Gm-Gg: AY/fxX7zZoE5VJ1m+t8rhT2Frq2wuRkxMFl3dIAorMSe+FBJDY3o4tTUYED3fbg1LLs +NMw05oFSb0RkpkhwhiqKcIpbqCj+aEsDIjAOoJZimeC1Tkh4ZH4YEYq2PDF/8ZSEP5VHmNOYZG 7ByqonUUVenCqWlxD6c9OKPsDcgvom6Ms3tgOJ6cCz4YihiIEi/ZdDMoj9zOSX9UmyKD9t+3s0/ vFajaGqgzNtTrnhEj6nHN60gnaWt9tSVyXPnRPrMObfqSWGoj6Q6tQsdMQVdqi9k6EqD3jorgSr uV3ViNt1OJkKRnq1J8KHxP0jigrNuvCWen6xlqj8ROpyTrvEUdH8vNMcxxuh1onj2cA/nztN5vm Et8WR0CsI+BQZ6dtm9+7BbnOR+GNUVnPDFKtyk/AMqZuD8izO/2EKcnsoCjoa1rxL9nArxnjJwy /23XUNwIPW5Eq9Dz2GRRmD/Ewr7wSMScQ2PyZJvspheIbh1NnFyoo+IEmh1XUZN3OdSzm44Ecuf NZClKcPP+oWAg== X-Google-Smtp-Source: AGHT+IGR1qjdN0+d6S1aRQi9RMdKImof2Me0oRB/iSacgv1pCD0vvzys+mivEscXWKdH61/P37RRUQ== X-Received: by 2002:a5d:4751:0:b0:430:2773:84d6 with SMTP id ffacd0b85a97d-432bcfc4e77mr2539572f8f.24.1767707255790; Tue, 06 Jan 2026 05:47:35 -0800 (PST) Message-ID: <52eb1293-b5d4-4f7a-b53b-285e4dd274a5@suse.com> Date: Tue, 6 Jan 2026 14:47:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 1/6] PCI: determine whether a device has extended config space From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand References: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@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: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Legacy PCI devices don't have any extended config space. Reading any part thereof may return all ones or other arbitrary data, e.g. in some cases base config space contents repeatedly. Logic follows Linux 6.19-rc's pci_cfg_space_size(), albeit leveraging our determination of device type; in particular some comments are taken verbatim from there. Signed-off-by: Jan Beulich --- Note that alloc_pdev()'s switch doesn't handle DEV_TYPE_PCI2PCIe_BRIDGE at all. Such bridges will therefore not have ->ext_cfg set (which is likely wrong). Shouldn't we handle them like DEV_TYPE_LEGACY_PCI_BRIDGE (or DEV_TYPE_PCI?) anyway (just like VT-d's set_msi_source_id() does)? Linux also has CONFIG_PCI_QUIRKS, allowing to compile out the slightly risky code (as reads may in principle have side effects). Should we gain such, too? --- a/xen/drivers/passthrough/pci.c +++ b/xen/drivers/passthrough/pci.c @@ -310,6 +310,41 @@ static void apply_quirks(struct pci_dev * from trying to size the BARs or add handlers to trap accesses. */ pdev->ignore_bars = true; + + if ( pdev->ext_cfg ) + { + unsigned int pos; + + /* + * PCI Express to PCI/PCI-X Bridge Specification, rev 1.0, 4.1.4 says + * that when forwarding a type1 configuration request the bridge must + * check that the extended register address field is zero. The bridge + * is not permitted to forward the transactions and must handle it as + * an Unsupported Request. Some bridges do not follow this rule and + * simply drop the extended register bits, resulting in the standard + * config space being aliased, every 256 bytes across the entire + * configuration space. Test for this condition by comparing the first + * dword of each potential alias to the vendor/device ID. + * Known offenders: + * ASM1083/1085 PCIe-to-PCI Reversible Bridge (1b21:1080, rev 01 & 03) + * AMD/ATI SBx00 PCI to PCI Bridge (1002:4384, rev 40) + */ + for ( pos = PCI_CFG_SPACE_SIZE; + pos < PCI_CFG_SPACE_EXP_SIZE; pos += PCI_CFG_SPACE_SIZE ) + { + if ( pci_conf_read16(pdev->sbdf, pos) != vendor || + pci_conf_read16(pdev->sbdf, pos + 2) != device ) + break; + } + + if ( pos >= PCI_CFG_SPACE_EXP_SIZE ) + { + printk(XENLOG_WARNING + "%pp: extended config space aliases base one\n", + &pdev->sbdf); + pdev->ext_cfg = false; + } + } } static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn) @@ -351,6 +386,8 @@ static struct pci_dev *alloc_pdev(struct unsigned long flags; case DEV_TYPE_PCIe2PCI_BRIDGE: + pdev->ext_cfg = true; + fallthrough; case DEV_TYPE_LEGACY_PCI_BRIDGE: sec_bus = pci_conf_read8(pdev->sbdf, PCI_SECONDARY_BUS); sub_bus = pci_conf_read8(pdev->sbdf, PCI_SUBORDINATE_BUS); @@ -363,9 +400,19 @@ static struct pci_dev *alloc_pdev(struct pseg->bus2bridge[sec_bus].devfn = devfn; } spin_unlock_irqrestore(&pseg->bus2bridge_lock, flags); + + fallthrough; + case DEV_TYPE_PCI: + pos = pci_find_cap_offset(pdev->sbdf, PCI_CAP_ID_PCIX); + if ( pos && + (pci_conf_read32(pdev->sbdf, pos + PCI_X_STATUS) & + (PCI_X_STATUS_266MHZ | PCI_X_STATUS_533MHZ)) ) + pdev->ext_cfg = true; break; case DEV_TYPE_PCIe_ENDPOINT: + pdev->ext_cfg = true; + pos = pci_find_cap_offset(pdev->sbdf, PCI_CAP_ID_EXP); BUG_ON(!pos); cap = pci_conf_read16(pdev->sbdf, pos + PCI_EXP_DEVCAP); @@ -409,9 +456,9 @@ static struct pci_dev *alloc_pdev(struct } break; - case DEV_TYPE_PCI: case DEV_TYPE_PCIe_BRIDGE: case DEV_TYPE_PCI_HOST_BRIDGE: + pdev->ext_cfg = true; break; default: @@ -420,6 +467,19 @@ static struct pci_dev *alloc_pdev(struct break; } + if ( pdev->ext_cfg && + /* + * Regular PCI devices have 256 bytes, but PCI-X 2 and PCI Express + * devices have 4096 bytes. Even if the device is capable, that + * doesn't mean we can access it. Maybe we don't have a way to + * generate extended config space accesses, or the device is behind a + * reverse Express bridge. So we try reading the dword at + * PCI_CFG_SPACE_SIZE which must either be 0 or a valid extended + * capability header. + */ + pci_conf_read32(pdev->sbdf, PCI_CFG_SPACE_SIZE) == 0xffffffffU ) + pdev->ext_cfg = false; + apply_quirks(pdev); check_pdev(pdev); @@ -717,6 +777,11 @@ int pci_add_device(u16 seg, u8 bus, u8 d list_add(&pdev->vf_list, &pf_pdev->vf_list); } + + if ( !pdev->ext_cfg ) + printk(XENLOG_WARNING + "%pp: VF without extended config space?\n", + &pdev->sbdf); } } --- a/xen/include/xen/pci.h +++ b/xen/include/xen/pci.h @@ -126,6 +126,9 @@ struct pci_dev { nodeid_t node; /* NUMA node */ + /* Whether the device has extended config space. */ + bool ext_cfg; + /* Device to be quarantined, don't automatically re-assign to dom0 */ bool quarantine; From xen-devel-bounces@lists.xenproject.org Tue Jan 06 13:48:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 13:48:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196094.1513964 (Exim 4.92) (envelope-from ) id 1vd7Pu-0004sD-FQ; Tue, 06 Jan 2026 13:48:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196094.1513964; Tue, 06 Jan 2026 13:48: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 1vd7Pu-0004s6-Cc; Tue, 06 Jan 2026 13:48:10 +0000 Received: by outflank-mailman (input) for mailman id 1196094; Tue, 06 Jan 2026 13:48: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 1vd7Pt-0004MT-3F for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 13:48:09 +0000 Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [2a00:1450:4864:20::441]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 557fc6dc-eb06-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 14:48:08 +0100 (CET) Received: by mail-wr1-x441.google.com with SMTP id ffacd0b85a97d-42fb0fc5aa9so457392f8f.1 for ; Tue, 06 Jan 2026 05:48:08 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ee5eesm4454297f8f.34.2026.01.06.05.48.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 05:48:07 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 557fc6dc-eb06-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767707288; x=1768312088; 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=JRm8agxN0LTD6ZCWwor27j6bp3Ta0t1F7caudO6/9MY=; b=dVmXSx4NqTJlAIOT800l6hvvirpS+dhJTVgLx5YEWw8ag8QmViP7g/XCXa31vH5iwI Q+xMOgx7G/HEMnjd14ENoNFxYfo+XIQBTZvCvS4IrnFOZHXnK5z9eU7zs4znTZKtSqCL TGiHkBXwmeZ5iSNpjW07TLeVEM9i4tZHeXauLbOd0YeK7ZGNUjiStrqKFtsul4zTyxIV pN18CUM1ZoFUuCaNeFzPWMM6/BJ+kb3XV9eJyPi/fcY5sjsnwnCeZREouvBZZJfd/RxL /a9KHJ6qbif06uV9MXGsLd3yTNDzHD0mPWgrs56flr7fao4byvDYw7aKsGXHnfI0G74p og6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767707288; x=1768312088; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=JRm8agxN0LTD6ZCWwor27j6bp3Ta0t1F7caudO6/9MY=; b=aYHRt62MsqgqMxr2kfRpzw8c/BfkZksTx3Ljbr4gSWL+zx6PpT6d1s8ZFb1SavJnP/ HJ6Y+vHVLjyVXOx/cQz/wIXvZPfXMhR5uhFEk6gHOZixscwQmUG5RrSkxDVG116Qxc/S dUo1a0XnYO9E0VejYC/RsFOikrf+JipLePR+MAH7JJUbGShNNKtSEQM6c3FNmM2khWQJ SQeRWo0XhUEF1yyfFMffPRgbfWtBVizHK2ARebGgZum/NXDAnx3FHOpMxHRICTqeHiL4 VfcmrudIx1UeU17x2DVAVzyPluoVNARLbGK7A5N4fn7sP25kZ8aSvscxesKnGE0WdUV/ l+nA== X-Gm-Message-State: AOJu0YzzjdBZd18Za0XJzNOKbedmUoWP1AjZFnoTlN2L1mvl30hLDP2O 0SzrrFl5AxY2+FDFyGK2aV/Sc/d7n3Jiogear1RdFWVRjkus/3QqUdDFwEcYERfQ1t6ohtl6UEU o7ZYcHA== X-Gm-Gg: AY/fxX4LDd7KE2wz/XnTOoIo/k1CpxORr74WH+JKUm2DL67K+V8qnzZSXRunEw9Xt6E x1RTq6zYST94kDwQmWREkkWjEIXbtaDN8ChK2DXioJy4q+rKCOaZmjEJT5Y8g+SC36J3LzPKYLS 0M5zfOj1fecHoVWw8zs3TnutQoOdbCSr4wKIITecxubyD9vd0hWNqncz/T0OrBCyCquy3a3yCzM 93Xb2NvUcWEUGuuimwD7f7gMtaQh2RNE3WAg9Z4rxml5tgkBTRbhmfDPl/FfzIcPeLuK3Nebqvg ml/nlVRYymz+InOry2PjYHHzfNCQnT5y2ImRNvT0yzLX57jDudXLuJvKtk4JIXPShRSnbpeL+rL e9vPVlNdl6re46ZjEzvlauMtjzwTt/OmYtHnyO1j25AKKzXs4RrCZ82OZ9HlQkqfiJ4ZWhmGZgI O7kYfmybxRqRUzQfvbAmRRsSEgqkP7iOtePjLYh3bh4Je5cg2Xk800ALsetuBWX3kCFU3hP6hr2 MTfvq3g6LEXBw== X-Google-Smtp-Source: AGHT+IF5NIuhIpx1takip1N4KLIGJjCkAL8DY16vJhPkQkrMtPtzdKpQzQLZOUhptMqlSyR+Bod4jA== X-Received: by 2002:a05:6000:2209:b0:430:fd84:317a with SMTP id ffacd0b85a97d-432bca50bcfmr4258704f8f.38.1767707288023; Tue, 06 Jan 2026 05:48:08 -0800 (PST) Message-ID: <2ee53e39-997e-4bca-be57-ac51f75b471d@suse.com> Date: Tue, 6 Jan 2026 14:48:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 2/6] PCI: pass pdev to pci_ats_{device,enabled}() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand References: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@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: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This not only brings both in sync with {en,dis}able_ats_device() but also prepares for doing the same to pci_find_{,next_}ext_capability(). Signed-off-by: Jan Beulich --- a/xen/drivers/passthrough/amd/iommu_cmd.c +++ b/xen/drivers/passthrough/amd/iommu_cmd.c @@ -285,7 +285,7 @@ void amd_iommu_flush_iotlb(u8 devfn, con if ( !ats_enabled ) return; - if ( !pci_ats_enabled(pdev->seg, pdev->bus, pdev->devfn) ) + if ( !pci_ats_enabled(pdev) ) return; iommu = find_iommu_for_device(pdev->sbdf); --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c @@ -121,7 +121,7 @@ static bool use_ats( { return !ivrs_dev->block_ats && iommu_has_cap(iommu, PCI_CAP_IOTLB_SHIFT) && - pci_ats_device(iommu->sbdf.seg, pdev->bus, pdev->devfn); + pci_ats_device(pdev); } static int __must_check amd_iommu_setup_domain_device( @@ -274,8 +274,7 @@ static int __must_check amd_iommu_setup_ ASSERT(pcidevs_locked()); - if ( use_ats(pdev, iommu, ivrs_dev) && - !pci_ats_enabled(iommu->sbdf.seg, bus, pdev->devfn) ) + if ( use_ats(pdev, iommu, ivrs_dev) && !pci_ats_enabled(pdev) ) { if ( devfn == pdev->devfn ) enable_ats_device(pdev, &iommu->ats_devices); @@ -418,8 +417,7 @@ static void amd_iommu_disable_domain_dev ASSERT(pcidevs_locked()); - if ( pci_ats_device(iommu->sbdf.seg, bus, pdev->devfn) && - pci_ats_enabled(iommu->sbdf.seg, bus, pdev->devfn) ) + if ( pci_ats_device(pdev) && pci_ats_enabled(pdev) ) disable_ats_device(pdev); BUG_ON ( iommu->dev_table.buffer == NULL ); --- a/xen/drivers/passthrough/ats.h +++ b/xen/drivers/passthrough/ats.h @@ -27,27 +27,25 @@ extern bool ats_enabled; int enable_ats_device(struct pci_dev *pdev, struct list_head *ats_list); void disable_ats_device(struct pci_dev *pdev); -static inline int pci_ats_enabled(int seg, int bus, int devfn) +static inline int pci_ats_enabled(const struct pci_dev *pdev) { u32 value; int pos; - pos = pci_find_ext_capability(PCI_SBDF(seg, bus, devfn), - PCI_EXT_CAP_ID_ATS); + pos = pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_ATS); BUG_ON(!pos); - value = pci_conf_read16(PCI_SBDF(seg, bus, devfn), pos + ATS_REG_CTL); + value = pci_conf_read16(pdev->sbdf, pos + ATS_REG_CTL); return value & ATS_ENABLE; } -static inline int pci_ats_device(int seg, int bus, int devfn) +static inline int pci_ats_device(const struct pci_dev *pdev) { if ( !ats_enabled ) return 0; - return pci_find_ext_capability(PCI_SBDF(seg, bus, devfn), - PCI_EXT_CAP_ID_ATS); + return pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_ATS); } #endif /* DRIVERS__PASSTHROUGH__ATS_H */ From xen-devel-bounces@lists.xenproject.org Tue Jan 06 13:48:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 13:48:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196105.1513975 (Exim 4.92) (envelope-from ) id 1vd7QP-0005OT-Nn; Tue, 06 Jan 2026 13:48:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196105.1513975; Tue, 06 Jan 2026 13: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 1vd7QP-0005OK-Ki; Tue, 06 Jan 2026 13:48:41 +0000 Received: by outflank-mailman (input) for mailman id 1196105; Tue, 06 Jan 2026 13:48: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 1vd7QO-0004MT-0o for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 13:48:40 +0000 Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [2a00:1450:4864:20::444]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 67bb659a-eb06-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 14:48:39 +0100 (CET) Received: by mail-wr1-x444.google.com with SMTP id ffacd0b85a97d-430f5ecaa08so433731f8f.3 for ; Tue, 06 Jan 2026 05:48:39 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0dabcbsm4276299f8f.7.2026.01.06.05.48.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 05:48:38 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 67bb659a-eb06-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767707319; x=1768312119; 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=ltpDchFjsfTzbthj3P9NFlV6ik3WXNe5NU0TTv/FNnM=; b=JJwofQooSi5Wf97O/1lDBaDM5LpLRaSpkF/jNV0lnxi+91wKRvHgTbziFWfnVoDROw mawGqpnVOZQc+SWjy8kj5wBXvpHBmDcicsvDCgUtmIkc7pPMx8Z8tiz7u9EI0kR492Jd arcbSCtzpzxH42/9Jm8HlIpCJCDHpQPkQQHtisJ4h3Ze7IjaJw/kFft5f4812m9YzazS VZYWC+fZrWHW8wlqUYdb9JZzXUZ53rPAvpnlnASKS4KBm/z7Td7aftpgVZm0Lrf4JPWF 6VKtaRwsBu8GWMDk2nnTjhv1MK7VO24OdSVr6gYSB8/ohL9mrM5sNsWOkYJd8k1HOXy6 3qAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767707319; x=1768312119; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ltpDchFjsfTzbthj3P9NFlV6ik3WXNe5NU0TTv/FNnM=; b=R99vdiNRtlQBsI2NdZ++70rTEVYkCkYaVWc06XVx77yKztw8Lrf7kxxg3rbwlGbc7g uwhrlCdmrDiqj1mk6e748UaKWevWqMpbhT5ldWQ+Xlxxlcth8Bl9oDPMXzTnB3yLxfZm csSMt2BZNK0uqH8DuQ12l3BNLuuZrtppvyFLRFFIBhqRv4b8wFRuxk9Use3symkqaso6 3/uchiSUyNOqO1E/rJgRB9I4m7jnuuUMnAc37QxSNAgLnY85/G/lz4dOwTFQs05zdCaa zwUSIVK6E0Slmi4pZkpM8LPHc2EjRvE8JiWIcDfs0WGi9W3GKCoEmvSZSuCKI2fTkEj2 2hNw== X-Gm-Message-State: AOJu0YziQhj4uRcOoB6LYtueIu4d3yaz+4qsVwZl0VItEmRH0fKJoXXo xjlldGGPzIlRtQs2e79WyHn/62WRnyI6vu4yy5YHwMaZ5NK3Mwx6tKojLGntQFuiwOwaGWQpwqz qY2je7g== X-Gm-Gg: AY/fxX61ioS7GITmI70hIJo088sPYC2hFXD/eI7bqx34hvN4cofcTM+/gmkBL/m7Kny KngaAz0uXLWc69uguD/fnfeFaufn8UgSvv3N/Vt3lTLzA2Bwcc+DpKJW4V2hkSkl+UJWAd9iF2t xK140EPSne2zeLtqlhzwHiEIC1a4zet6C+kj0I5RHWoA5uq2kigaJP8SiJGL5XnRO7O8J1X3l2q NcU12Yjur4VO7b41zVJsOW4U8zt9UgCRVFaqd3kDHJjHCcd3yJx8cA5flX6i/9nxy3PLD9hP1yP IRTHYHs+fFxQJxavjOCuyvylyI4T6JIcNSJOtbm5xl6ty+djS6fCxF1LkZrHyhRY6MfBi5GIoxP cW1G/BKHhpe7pyOvSiOrhtayEhQMHX0/4MrMiIBzwQfnq4vDFIu3aG02GJjMX6Vbwa8bY8EA8nh q5JeYaOP9Ib4x7c2faxS/3NdKN9ODhNdkJOeMOdiTJWkCKUKmbDBob5eZdDSa9DJMEm4WBKt+TL YHmuhvpugZTiQ== X-Google-Smtp-Source: AGHT+IEbTX6zUm9ZKzRIj6MT6mo69QEiGCv+eHFQBB8LGf+XX7nLFSeR09wIaS9BTPIlmI6WqzHeNg== X-Received: by 2002:a05:6000:40e1:b0:432:5bf9:cf15 with SMTP id ffacd0b85a97d-432bca2cc68mr4245371f8f.5.1767707318683; Tue, 06 Jan 2026 05:48:38 -0800 (PST) Message-ID: Date: Tue, 6 Jan 2026 14:48:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 3/6] x86/MSI: pass pdev to read_pci_mem_bar() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand References: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@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: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This not only reduces the number of parameters and local variables, but also prepares for doing the same to pci_find_{,next_}ext_capability(). Signed-off-by: Jan Beulich --- a/xen/arch/x86/msi.c +++ b/xen/arch/x86/msi.c @@ -662,11 +662,11 @@ static int msi_capability_init(struct pc return 0; } -static uint64_t read_pci_mem_bar(pci_sbdf_t sbdf, uint8_t bir, int vf, - const struct pf_info *pf_info) +static uint64_t read_pci_mem_bar(const struct pci_dev *pdev, uint8_t bir, + int vf) { - uint16_t seg = sbdf.seg; - uint8_t bus = sbdf.bus, slot = sbdf.dev, func = sbdf.fn; + uint16_t seg = pdev->sbdf.seg; + uint8_t bus = pdev->sbdf.bus, slot = pdev->sbdf.dev, func = pdev->sbdf.fn; u8 limit; u32 addr, base = PCI_BASE_ADDRESS_0; u64 disp = 0; @@ -676,20 +676,18 @@ static uint64_t read_pci_mem_bar(pci_sbd unsigned int pos; uint16_t ctrl, num_vf, offset, stride; - ASSERT(pf_info); - - pos = pci_find_ext_capability(sbdf, PCI_EXT_CAP_ID_SRIOV); - ctrl = pci_conf_read16(sbdf, pos + PCI_SRIOV_CTRL); - num_vf = pci_conf_read16(sbdf, pos + PCI_SRIOV_NUM_VF); - offset = pci_conf_read16(sbdf, pos + PCI_SRIOV_VF_OFFSET); - stride = pci_conf_read16(sbdf, pos + PCI_SRIOV_VF_STRIDE); + pos = pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_SRIOV); + ctrl = pci_conf_read16(pdev->sbdf, pos + PCI_SRIOV_CTRL); + num_vf = pci_conf_read16(pdev->sbdf, pos + PCI_SRIOV_NUM_VF); + offset = pci_conf_read16(pdev->sbdf, pos + PCI_SRIOV_VF_OFFSET); + stride = pci_conf_read16(pdev->sbdf, pos + PCI_SRIOV_VF_STRIDE); if ( !pos || !(ctrl & PCI_SRIOV_CTRL_VFE) || !(ctrl & PCI_SRIOV_CTRL_MSE) || !num_vf || !offset || (num_vf > 1 && !stride) || bir >= PCI_SRIOV_NUM_BARS || - !pf_info->vf_rlen[bir] ) + !pdev->physfn.vf_rlen[bir] ) return 0; base = pos + PCI_SRIOV_BAR; vf -= PCI_BDF(bus, slot, func) + offset; @@ -703,8 +701,8 @@ static uint64_t read_pci_mem_bar(pci_sbd } if ( vf >= num_vf ) return 0; - BUILD_BUG_ON(ARRAY_SIZE(pf_info->vf_rlen) != PCI_SRIOV_NUM_BARS); - disp = vf * pf_info->vf_rlen[bir]; + BUILD_BUG_ON(ARRAY_SIZE(pdev->physfn.vf_rlen) != PCI_SRIOV_NUM_BARS); + disp = vf * pdev->physfn.vf_rlen[bir]; limit = PCI_SRIOV_NUM_BARS; } else switch ( pci_conf_read8(PCI_SBDF(seg, bus, slot, func), @@ -759,10 +757,6 @@ static int msix_capability_init(struct p u16 control; u64 table_paddr; u32 table_offset; - u16 seg = dev->seg; - u8 bus = dev->bus; - u8 slot = PCI_SLOT(dev->devfn); - u8 func = PCI_FUNC(dev->devfn); bool maskall = msix->host_maskall, zap_on_error = false; unsigned int pos = dev->msix_pos; @@ -809,32 +803,20 @@ static int msix_capability_init(struct p (is_hardware_domain(current->domain) && (dev->domain == current->domain || dev->domain == dom_io))) ) { - unsigned int bir = table_offset & PCI_MSIX_BIRMASK, pbus, pslot, pfunc; - int vf; + unsigned int bir = table_offset & PCI_MSIX_BIRMASK; + int vf = -1; + const struct pci_dev *pf_dev = dev; paddr_t pba_paddr; unsigned int pba_offset; - const struct pf_info *pf_info; - if ( !dev->info.is_virtfn ) - { - pbus = bus; - pslot = slot; - pfunc = func; - vf = -1; - pf_info = NULL; - } - else + if ( dev->info.is_virtfn ) { - pbus = dev->info.physfn.bus; - pslot = PCI_SLOT(dev->info.physfn.devfn); - pfunc = PCI_FUNC(dev->info.physfn.devfn); vf = dev->sbdf.bdf; ASSERT(dev->pf_pdev); - pf_info = &dev->pf_pdev->physfn; + pf_dev = dev->pf_pdev; } - table_paddr = read_pci_mem_bar(PCI_SBDF(seg, pbus, pslot, pfunc), bir, - vf, pf_info); + table_paddr = read_pci_mem_bar(pf_dev, bir, vf); WARN_ON(msi && msi->table_base != table_paddr); if ( !table_paddr ) { @@ -857,8 +839,7 @@ static int msix_capability_init(struct p pba_offset = pci_conf_read32(dev->sbdf, msix_pba_offset_reg(pos)); bir = (u8)(pba_offset & PCI_MSIX_BIRMASK); - pba_paddr = read_pci_mem_bar(PCI_SBDF(seg, pbus, pslot, pfunc), bir, vf, - pf_info); + pba_paddr = read_pci_mem_bar(pf_dev, bir, vf); WARN_ON(!pba_paddr); pba_paddr += pba_offset & ~PCI_MSIX_BIRMASK; From xen-devel-bounces@lists.xenproject.org Tue Jan 06 13:49:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 13:49:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196111.1513984 (Exim 4.92) (envelope-from ) id 1vd7R5-0005vU-Vy; Tue, 06 Jan 2026 13:49:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196111.1513984; Tue, 06 Jan 2026 13:49: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 1vd7R5-0005vN-TC; Tue, 06 Jan 2026 13:49:23 +0000 Received: by outflank-mailman (input) for mailman id 1196111; Tue, 06 Jan 2026 13:49:22 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd7R4-0004Q3-Fv for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 13:49:22 +0000 Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [2a00:1450:4864:20::442]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7e9ebcc9-eb06-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 14:49:17 +0100 (CET) Received: by mail-wr1-x442.google.com with SMTP id ffacd0b85a97d-4308d81fdf6so477272f8f.2 for ; Tue, 06 Jan 2026 05:49:17 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0e199bsm4624650f8f.16.2026.01.06.05.49.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 05:49:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7e9ebcc9-eb06-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767707357; x=1768312157; 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=VALIeZIxI2UW6d8eRGujCTMwXTGh4om+pwgD9mOB0J8=; b=frlJ7Gu0egdILkXe7RuWMHpv3tKqQmRWdcxQC83nbUmMmpZIpa2m8xL5qDerAYmUcV gIjeMn4VrDEzP2qqNK45FkIz2nV5y0fjdMuJ+GT+BM+677C03Q0DElAtgAa4k+tQQwKU 5PxjT7+qnJdqLhJJoeCw8dedQzN8mHzq972scgHulvjtcYUfxXChsLuwGqVU54CXFE8f G8W2rZwTr8jOuy7qNRpAO59v9WC9W0AAqeGyKmIbBjHD4axF7Stx/kqQpBr9pg5aB3fL qXTpdIQHJuuSSYpnzcpz0CYqp1OD1C28Mqh2PiF2qIt5jHpngD/7E4abPi1LjICXnfXj 18jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767707357; x=1768312157; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=VALIeZIxI2UW6d8eRGujCTMwXTGh4om+pwgD9mOB0J8=; b=v5ux7GZohfbOikVvJPLcxralaOo6SkldnC+OQ1Iv1mbH1lUTVI1NTTjjvMMfrVYAlK CjF5vsnN80y9Cr44yBTew30lhauxq3UZEbls0mWOPPjcPmJiY+dY7P9IhJap11FuYNRr ewGSHozeYeUKT27OWihfIAbAvnZAb596jv25D94OZNC6iAiNW8eIJAIcZGS1E7hrb0c3 s6L2naJO76DMt64DbKrnT5Trb//ApyYQVNXY6rAt0vGqkcQNnpc2VmEfUpEb+ld6exnv wgNN5Jj4HnS5tD/xnYTbZSf5GJm91jvCnPCYKgtNiSYkzU3s/GfymCW+URmLFnXi6Nj0 fgjw== X-Gm-Message-State: AOJu0Yx6ctWXOfD2h5Tv4VFh0xYnFphQ5VXQWymaKQQ3rdZOxMHGL4DD 7TJItIN9exKWcZGMlxtjAEs1H8/vsygkaP2+DEPTt5IEmrs/+11ihQC7yBlX1DzJFQ8Q7CLbN75 HUoso+Q== X-Gm-Gg: AY/fxX4WwE5SZ4DiCV7T8qnG9/WM/sQwP7s2M1s6u+Sg7nKlvWcsOX89/3SkT8wLeVA y19U+Ob4MPnCZRk1uRDoD2bNHzXaBqmBpnIvDGkV8u8Dtz7gu/IptxUr4AwBIU5rZFKyq1hLE0F gEoEtKLEjC6fYQ2ylB0onWBfTMChyyp43P2jYg5OOJ32O6mgCubZrKsDETDit99DxtLyYYmbImk txX2edSlwYS8sBfg62m2pj+K8+hJJtYXNg4HqjKyLUkzy7x8ZxEJAYvK0bFaYwk4uT6NCskxoPD QYM/rFhyD59rfr3nZuIyE93+kZb+HeoT5eFqxfIgeGpPKNvqXn99HhaMogUgLNl10z6aW1lkmwz LM00lF6D6NEQ/PShBGDxAr7j0EqoXJ8oSXpqz/03cgIlPplTHNVtXu95wF+klgbFXZ/Ph1KRDik qylhz9a0IzajZWjSR4Sd4Ja0wetimS9EfpI89MWIIlCOWPuCwMiQGed+65Ecwr7J8iPWRH/k7zD 7pIbC2JhjuSuQ== X-Google-Smtp-Source: AGHT+IGQOlE1EGqvWFA9ndk3JdUEMv0/a8kKS8pTHu3PVfhb0xLjW9bG6MmEKyZoadHrRqGom2yCgA== X-Received: by 2002:a05:6000:40dc:b0:430:f325:435e with SMTP id ffacd0b85a97d-432bca2b787mr3565273f8f.16.1767707357020; Tue, 06 Jan 2026 05:49:17 -0800 (PST) Message-ID: <594cc7a9-710c-4863-b46f-f5e6bc0247de@suse.com> Date: Tue, 6 Jan 2026 14:49:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 4/6] PCI: pass pdev to pci_find_{,next_}ext_capability() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand References: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@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: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This is in preparation of using attributes recorded for devices. Additionally locating (extended) capabilities of non-devices (e.g. phantom functions) makes no sense. While there also eliminate open-coding of PCI_CFG_SPACE_SIZE in adjacent code. Signed-off-by: Jan Beulich --- a/xen/arch/x86/msi.c +++ b/xen/arch/x86/msi.c @@ -676,7 +676,7 @@ static uint64_t read_pci_mem_bar(const s unsigned int pos; uint16_t ctrl, num_vf, offset, stride; - pos = pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_SRIOV); + pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_SRIOV); ctrl = pci_conf_read16(pdev->sbdf, pos + PCI_SRIOV_CTRL); num_vf = pci_conf_read16(pdev->sbdf, pos + PCI_SRIOV_NUM_VF); offset = pci_conf_read16(pdev->sbdf, pos + PCI_SRIOV_VF_OFFSET); --- a/xen/drivers/passthrough/ats.c +++ b/xen/drivers/passthrough/ats.c @@ -26,7 +26,7 @@ int enable_ats_device(struct pci_dev *pd u32 value; int pos; - pos = pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_ATS); + pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ATS); BUG_ON(!pos); if ( iommu_verbose ) --- a/xen/drivers/passthrough/ats.h +++ b/xen/drivers/passthrough/ats.h @@ -32,7 +32,7 @@ static inline int pci_ats_enabled(const u32 value; int pos; - pos = pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_ATS); + pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ATS); BUG_ON(!pos); value = pci_conf_read16(pdev->sbdf, pos + ATS_REG_CTL); @@ -45,7 +45,7 @@ static inline int pci_ats_device(const s if ( !ats_enabled ) return 0; - return pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_ATS); + return pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ATS); } #endif /* DRIVERS__PASSTHROUGH__ATS_H */ --- a/xen/drivers/passthrough/pci.c +++ b/xen/drivers/passthrough/pci.c @@ -641,7 +641,7 @@ static void pci_enable_acs(struct pci_de if ( !is_iommu_enabled(pdev->domain) ) return; - pos = pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_ACS); + pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ACS); if (!pos) return; @@ -787,8 +787,7 @@ int pci_add_device(u16 seg, u8 bus, u8 d if ( !pdev->info.is_virtfn && !pdev->physfn.vf_rlen[0] ) { - unsigned int pos = pci_find_ext_capability(pdev->sbdf, - PCI_EXT_CAP_ID_SRIOV); + unsigned int pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_SRIOV); uint16_t ctrl = pci_conf_read16(pdev->sbdf, pos + PCI_SRIOV_CTRL); if ( !pos ) --- a/xen/drivers/passthrough/vtd/x86/ats.c +++ b/xen/drivers/passthrough/vtd/x86/ats.c @@ -62,7 +62,7 @@ int ats_device(const struct pci_dev *pde return 0; ats_drhd = find_ats_dev_drhd(drhd->iommu); - pos = pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_ATS); + pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ATS); if ( pos && (ats_drhd == NULL) ) { --- a/xen/drivers/passthrough/vtd/quirks.c +++ b/xen/drivers/passthrough/vtd/quirks.c @@ -531,10 +531,10 @@ void pci_vtd_quirk(const struct pci_dev /* Sandybridge-EP (Romley) */ case 0x3c00: /* host bridge */ case 0x3c01 ... 0x3c0b: /* root ports */ - pos = pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_ERR); + pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ERR); if ( !pos ) { - pos = pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_VNDR); + pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_VNDR); while ( pos ) { val = pci_conf_read32(pdev->sbdf, pos + PCI_VNDR_HEADER); @@ -543,7 +543,7 @@ void pci_vtd_quirk(const struct pci_dev pos += PCI_VNDR_HEADER; break; } - pos = pci_find_next_ext_capability(pdev->sbdf, pos, + pos = pci_find_next_ext_capability(pdev, pos, PCI_EXT_CAP_ID_VNDR); } ff = 0; --- a/xen/drivers/pci/pci.c +++ b/xen/drivers/pci/pci.c @@ -89,9 +89,10 @@ unsigned int pci_find_next_cap(pci_sbdf_ * within the device's PCI configuration space or 0 if the device does * not support it. */ -unsigned int pci_find_ext_capability(pci_sbdf_t sbdf, unsigned int cap) +unsigned int pci_find_ext_capability(const struct pci_dev *pdev, + unsigned int cap) { - return pci_find_next_ext_capability(sbdf, 0, cap); + return pci_find_next_ext_capability(pdev, 0, cap); } /** @@ -104,14 +105,15 @@ unsigned int pci_find_ext_capability(pci * within the device's PCI configuration space or 0 if the device does * not support it. */ -unsigned int pci_find_next_ext_capability(pci_sbdf_t sbdf, unsigned int start, +unsigned int pci_find_next_ext_capability(const struct pci_dev *pdev, + unsigned int start, unsigned int cap) { u32 header; int ttl = 480; /* 3840 bytes, minimum 8 bytes per capability */ - unsigned int pos = max(start, 0x100U); + unsigned int pos = max(start, PCI_CFG_SPACE_SIZE + 0U); - header = pci_conf_read32(sbdf, pos); + header = pci_conf_read32(pdev->sbdf, pos); /* * If we have no capabilities, this is indicated by cap ID, @@ -125,9 +127,9 @@ unsigned int pci_find_next_ext_capabilit if ( PCI_EXT_CAP_ID(header) == cap && pos != start ) return pos; pos = PCI_EXT_CAP_NEXT(header); - if ( pos < 0x100 ) + if ( pos < PCI_CFG_SPACE_SIZE ) break; - header = pci_conf_read32(sbdf, pos); + header = pci_conf_read32(pdev->sbdf, pos); } return 0; } --- a/xen/drivers/vpci/rebar.c +++ b/xen/drivers/vpci/rebar.c @@ -53,7 +53,7 @@ static int cf_check init_rebar(struct pc { uint32_t ctrl; unsigned int nbars; - unsigned int rebar_offset = pci_find_ext_capability(pdev->sbdf, + unsigned int rebar_offset = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_REBAR); if ( !rebar_offset ) --- a/xen/drivers/vpci/vpci.c +++ b/xen/drivers/vpci/vpci.c @@ -196,7 +196,7 @@ static struct vpci_register *vpci_get_pr static int vpci_ext_capability_hide( const struct pci_dev *pdev, unsigned int cap) { - const unsigned int offset = pci_find_ext_capability(pdev->sbdf, cap); + const unsigned int offset = pci_find_ext_capability(pdev, cap); struct vpci_register *r, *prev_r; struct vpci *vpci = pdev->vpci; uint32_t header, pre_header; @@ -264,7 +264,7 @@ static int vpci_init_capabilities(struct if ( !is_ext ) pos = pci_find_cap_offset(pdev->sbdf, cap); else if ( is_hardware_domain(pdev->domain) ) - pos = pci_find_ext_capability(pdev->sbdf, cap); + pos = pci_find_ext_capability(pdev, cap); if ( !pos ) continue; @@ -333,7 +333,7 @@ void vpci_deassign_device(struct pci_dev if ( !capability->is_ext ) pos = pci_find_cap_offset(pdev->sbdf, cap); else if ( is_hardware_domain(pdev->domain) ) - pos = pci_find_ext_capability(pdev->sbdf, cap); + pos = pci_find_ext_capability(pdev, cap); if ( pos ) { int rc = capability->cleanup(pdev, false); --- a/xen/include/xen/pci.h +++ b/xen/include/xen/pci.h @@ -263,8 +263,10 @@ unsigned int pci_find_next_cap_ttl(pci_s unsigned int *ttl); unsigned int pci_find_next_cap(pci_sbdf_t sbdf, unsigned int pos, unsigned int cap); -unsigned int pci_find_ext_capability(pci_sbdf_t sbdf, unsigned int cap); -unsigned int pci_find_next_ext_capability(pci_sbdf_t sbdf, unsigned int start, +unsigned int pci_find_ext_capability(const struct pci_dev *pdev, + unsigned int cap); +unsigned int pci_find_next_ext_capability(const struct pci_dev *pdev, + unsigned int start, unsigned int cap); const char *parse_pci(const char *s, unsigned int *seg_p, unsigned int *bus_p, unsigned int *dev_p, unsigned int *func_p); From xen-devel-bounces@lists.xenproject.org Tue Jan 06 13:56:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 13:56:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196118.1513994 (Exim 4.92) (envelope-from ) id 1vd7Xr-0007cK-Oq; Tue, 06 Jan 2026 13:56:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196118.1513994; Tue, 06 Jan 2026 13:56:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd7Xr-0007cD-MI; Tue, 06 Jan 2026 13:56:23 +0000 Received: by outflank-mailman (input) for mailman id 1196118; Tue, 06 Jan 2026 13:56:23 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd7Xq-0007c1-VP for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 13:56:22 +0000 Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [2a00:1450:4864:20::341]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7b6d9c2b-eb07-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 14:56:21 +0100 (CET) Received: by mail-wm1-x341.google.com with SMTP id 5b1f17b1804b1-477a2ab455fso9398355e9.3 for ; Tue, 06 Jan 2026 05:56:21 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f653c78sm46337045e9.11.2026.01.06.05.56.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 05:56:20 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7b6d9c2b-eb07-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767707781; x=1768312581; 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=ZO8rgZJr4KzU2Xy8wgmhHWqpTW2gXbvRQCQ99uEvvTE=; b=Se9JHngtMTCw0qGJ3ssBY5xa2deus4dSPEy8JGyGIgxlpIbuWD65Dn2C9oSpkzLyw1 mP+5GyRE26q8h/lZc5yfh87oelNGM72qgVHMDCi0SgE3CkaRx7EbuML7ydJZ8xY3W1Gm bDXAvz/pwZaVePg2csxS3tAPewpuUOGQCFc66LIxnfeD0WBnSDZSJFlbe0cZKHNQE/LE l4MY6aQATvzeiowlSKJkIDbGTLMMqaNPdVJhdyIJWJ3ez7Np0S36cc5u0z+vrJGAnPlx 52hdnRgRrngxX27GyY3Ni7s6gR6yPZW45uCZF99X7YDucFqt0lvyJlQ5CUZUOtTEWdEw ZC6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767707781; x=1768312581; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZO8rgZJr4KzU2Xy8wgmhHWqpTW2gXbvRQCQ99uEvvTE=; b=uLto6qlaprti5wQkTS8QgvGWoRob85trLr3BTFcySdvqy89UgWjXFqrQelC6qKTgwF xmvEcfx642erSfWtBr+pNIGBlX66HDDqvq6HKtclTsDOI6d+usJzZdTY3/ej8E6sXExS dyt4ghMGGDVPpVJuoBHPzpuwgrq7pJcUMVNT/yqkh5/CM23uhv8JjIAfW8UtRnPxjs/+ SVr28zR7fooeLq1lOJxWR6e5nozPKX4J27Jv+OcV9jGeP/39/pfPZrsc45oaomX6Ntmn PJ8LK4zqdYWY05rCZtAraVKQFyLpyV7m6kouXcwa5HLIs6dcHxO+dekJQkGpfhvV1Udb qqfA== X-Gm-Message-State: AOJu0YwRbIIBykUD3jaWxdD3/1Xt90gJUUOWK7LEhT/6+yEeICl5CQ1T 7rFv4jNRL3T6weFCRU8M6iGGL3TtkSETZ1TJuEo7OfsSjZHCiAK8HS4uAU+K97pddjGPIWsOrgf oG9Wp4Q== X-Gm-Gg: AY/fxX4gbukjJRt8aBiRf5VDIwbRukXc2pyeDGebE5ypPwUqDpZG84xMyygVTMLjdJb H3NMq8UGgp/K5TcFB2t8EE4J2TGhOBYoHlQuVeLZMYmQH375jihot39AgCv7Oi/6LZl6+y8gQ9c zUKANJpJw8m2wTsJzPNqOI7E+0yDukINGWOiq72ZFp3ZvIEWY/RVmCWGFBzuv/0SL9OI+0u/SNb scZFoEg0pEuJ3OJKcxArg7cMZlXTMZS3gcmthAA5xIYQfgqsDVKpJ9/8msOJJ4/1DDZRy4owhFd 6TXwi6i7A60q9LnwRZUggb+Si5S3B5WRVT6mR1+YYHRRlDe0jZaF+Bac+SOSol/WhafkwXbg5L9 4KIx82SALMpHQTEskswUoVuWg6tBZX3lDviMlyv5tq1A2xKIp+tSG3S9wzpHog9PBWyXt2gLcW1 CQdRg2aF9/hfi9Fro9rxzegutp3F721KCxTSyY7IDrR8BBZupXUXCupSkL8+fDJUM3E5CkTQ2zy Rw= X-Google-Smtp-Source: AGHT+IFd0IBXWuEdGOhm7twVEuVVeXrCJeSSfyPPVVRSnIfvsIYsCagShfS8Dim8onIIcZk3OA5wVQ== X-Received: by 2002:a05:600c:8b4b:b0:45d:5c71:769a with SMTP id 5b1f17b1804b1-47d7f0a198cmr35749595e9.26.1767707781226; Tue, 06 Jan 2026 05:56:21 -0800 (PST) Message-ID: Date: Tue, 6 Jan 2026 14:56:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH 0/5] x86: assorted time handling adjustments Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit The first patch aims at addressing a recent bug report, but may also point out further more or less related issues. The other patches do some tidying found desirable while doing the investigation. 1: time: deal with negative deltas in get_s_time_fixed() 2: 3: 4: 5: Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 06 13:57:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 13:57:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196126.1514005 (Exim 4.92) (envelope-from ) id 1vd7Yg-00087R-1T; Tue, 06 Jan 2026 13:57:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196126.1514005; Tue, 06 Jan 2026 13:57:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd7Yf-00087K-Ud; Tue, 06 Jan 2026 13:57:13 +0000 Received: by outflank-mailman (input) for mailman id 1196126; Tue, 06 Jan 2026 13:57: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 1vd7Yf-000879-2Q for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 13:57:13 +0000 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [2a00:1450:4864:20::342]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9889a982-eb07-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 14:57:10 +0100 (CET) Received: by mail-wm1-x342.google.com with SMTP id 5b1f17b1804b1-4779adb38d3so7656895e9.2 for ; Tue, 06 Jan 2026 05:57:10 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7faecaccsm18788265e9.2.2026.01.06.05.57.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 05:57:09 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9889a982-eb07-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767707830; x=1768312630; 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=VaFiZnCalOwuRAXOcJsU/zkWwQmDiViHYDLlWhgQwGU=; b=DWp660djlvcD3xNxA4WYg7M1nuPuAONw4OVcyyaNrHRDnMXO3K2wJvQTdJIzGKpWHK R5euuy++wq0w0eMVj1S/qDXduGKia4YmpwngZjTgLhg3HmLiMVQXiPPsltWd0/6HgkZT glB7jFRIFv9+ozZq3g3MceBeRPr9Yak/WnrW+WHH7ruDmdTX7s4lxnMCPAtrDIuDEkNY UlFTW43Gmq4Oo3J4PMluK2k1FA8/M9i2yrI1/mmj4PqevWN8BO9VKL65nUI951C1u2ST uIgBbTb/Foajdff+OH0TuYC/qIivZFk0yAvummKUecxya6JNMXVCTXBa6kR7ijxTR0Zv FX3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767707830; x=1768312630; h=content-transfer-encoding:autocrypt:content-language:cc:to:subject :from:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=VaFiZnCalOwuRAXOcJsU/zkWwQmDiViHYDLlWhgQwGU=; b=Qtz1xdGtA8a2TpgPDeJWkW/zyotqlbbd8Vs7M99zyvNo+AnchnlXRTOs3SApHD09LG cgn2RPLj4D7W8wXNO/c9TEA3IOgxZhZQd1+10ax/OheUM50GOt9X+4qksMwoFnaDWic8 Gvhx4HmL3uV/yzJPLzhVhz7GGPkwq0PNSVWGWpN4BMrIBYnoRzR0yYTAe3UnFMK4uwae RDj2C8IgBwTxBw9Wm/dI2VWVbzgJGvi/MmSWqk+Q3R42pGen5xUCX0TW1x3faIquhE6S xH+d1Z/DF39VaDSaMiLjeWucFcNSLHjQW9BSiUL7GEQcR5fvPJftXEaON3k0SVkdMLOv SZUQ== X-Gm-Message-State: AOJu0YyRsBYag0DxaGjR7ZW3lI+sITeivAa2uOM7208TDT+tiq0Ljban KQelTL8NwUMVjIQ+wcdfEHbxnX7dAfvUMMhbl88S4D5bfgVqWrVDceOjsEy7cRrKC8sgVAgMtnq /PGM5rw== X-Gm-Gg: AY/fxX4kYF35yaDoq7p1Mm/KjucVb5EGLoo0ELhCi7SpMDInviqiAvoVSGWC36p5rcZ mVIEUcnsW/MTUXoz79pAFgWW25b30EahQV9RALBu/Z5iCcG9lFDvLfDyTvsQOrQd7NqwJma01S3 Vh/VjDS1/2saiRVoenzoaGoKKfokg2ZemXci6U7G86IrYCgBbGnZjDhGzD0paCKa4Xbe67z4ULl pxYQg8ah0RP9y42RXz1sWLXgb5pYXG2gxrPJOX0Tu4OMrTdDc2LxLrTP3cYwCqCc+ea2Y+ReqvY g6UIeGy/YY77KIa7hKaVNwJewznoiJ6SrKfSybXh6c7O9SE7Hj14NQ+hYMJpyiB41Y9gY+Y3nOx t/nUeTCrpQFA0uTUg06BPMbJLSU8U5ZHgtumhORv2ZIYrKobS8r7M4jW9f8my4vRfQvmsmq6PEE Ms2nZmwTU6XKE7k6WGrQ94zQe5y1/w7jgfcQUC2MLj7IW1jIRT2ydFYpo+Ju0qW+Pxw25WmKcZl jk= X-Google-Smtp-Source: AGHT+IEaQPMWyAssGz3slEpzDLOocVu6RT281QRSSOxTO6UGuVlKdQSrvfs0L3MzEhonYzG4WxcMUA== X-Received: by 2002:a05:600c:8485:b0:477:a9e:859a with SMTP id 5b1f17b1804b1-47d7f090008mr35948495e9.22.1767707829995; Tue, 06 Jan 2026 05:57:09 -0800 (PST) Message-ID: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> Date: Tue, 6 Jan 2026 14:57:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jan Beulich Subject: [PATCH 0/5] x86: assorted time handling adjustments 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 The first patch aims at addressing a recent bug report, but may also point out further more or less related issues. The other patches do some tidying found desirable while doing the investigation. 1: time: deal with negative deltas in get_s_time_fixed() 2: time: scale_delta() can be static 3: HVM: drop at_tsc parameter from ->set_tsc_offset() hook 4: time: gtsc_to_gtime() is HVM-only 5: time: pv_soft_rdtsc() is PV-only Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 06 13:57:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 13:57:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196143.1514015 (Exim 4.92) (envelope-from ) id 1vd7ZN-0000LD-A1; Tue, 06 Jan 2026 13:57:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196143.1514015; Tue, 06 Jan 2026 13:57: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 1vd7ZN-0000L6-6t; Tue, 06 Jan 2026 13:57:57 +0000 Received: by outflank-mailman (input) for mailman id 1196143; Tue, 06 Jan 2026 13:57: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 1vd7Rz-0004MT-QV for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 13:50:19 +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 a340ddc3-eb06-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 14:50:19 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-43260a5a096so624029f8f.0 for ; Tue, 06 Jan 2026 05:50:19 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0daa84sm4502490f8f.2.2026.01.06.05.50.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 05:50:18 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a340ddc3-eb06-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767707418; x=1768312218; 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=LxIHHnoWmRfEZQKRp7c/KawtwyGIc/YRyMoiBmbjtBI=; b=RsrYTQMd77w/i4NR2tSMUQeGxnUa5vi08TgmHHTS8+NeY12NvLXlLVr6Ma95yWIB/P d3qLDo8J+GttBcWDzz9RXYtm/51+CzY85nh2ROhV+PzYscPUmXCUc2VKmGt4lb/+qt0l O1IPOLTDwwf8STmaxY91GGjYAijrpLUvZVQjXqLnmqcHDoysY66XvBPI3RMOLasIWEyT PfCqlTvU7SKbPwTLKG3V0A1sxGNwFRJHEaxTF4xBV1X5LU+t7o/TihonsTKq9Mna2p3u 8QKwouyXfpdEAJnhYSInaKU6Kc8dWMj919mzRyuCPFpC18BB7wdf3lqCbZeZXqy76c1F HdkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767707418; x=1768312218; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=LxIHHnoWmRfEZQKRp7c/KawtwyGIc/YRyMoiBmbjtBI=; b=ONIB+vNLqVZbdnEnKl5YSSBiy1962kRTXW7oaSHYsp5qEaSafsNJkdIeZXbVdR6iF7 YUuQdH1xJc+lLHOIjvFpiUsp4tuycuDC4GMnMXamWM+LCTn4HZWMzVFiNb4eMoHPShh9 4zK3/30ZDQMFN9xwUQ/52/7UbaOQ3EvXxWHhngSwYAlCO/1xYaXynvM65/ljWPBfmVIM A9KVfFU17t4v8XLIqvzAslkf2oqLb/uHw7TLSg9YvF5JWQN3nYBs+lwfAmHl+TgV5q4D kE7lMqmO4oB/oLWwO9+sjYpspQL17ui+x4QQ/rybXjA/WndqvHI1htDXkidXPWeiAoHA d+WA== X-Gm-Message-State: AOJu0YxTgMMgN/8XsZM9PpjYwc0zkteZUlfZ85C45gf0TJSE3CFkESls Pa8fFsDhWuQrz23bGTQ1Sf/J7uyuTi9wdKpgCkDG+5ivHMKfWL8gS4iTsml0k7plSnBwBMKxNwd cngA= X-Gm-Gg: AY/fxX7cfQNJK5Lh6QmfRKY9/eAVJargNQagFH3RstYNQsxwJK8j0OSpF6oFhP2Bvvg j0SQQCh66g/4embbNOp+MH1nUGVKI1NIYOj9Z+oWMJPnIRi/s/34m2I4nwTyHULc3XkwdSOqfeV wjp0F5h+CFwDqNBocRjlccWNDogDqQRnMyj8xYzWk+FCyP/iJGGN7K3vKCK+8+D9pbe/Md3wwO+ 6GVaaSkGVSA1IOQiQP15/qxbhLDS42ouEDMUQtihrYXWshlKnloeJ6TzMHxyOE9raxGYW4kIYUN IMTozgdhxZXdUkKlOBNRii+1Rx9OfOE0vWmbgkoKQzcNABj4bUWnbeRh0OL1Oo6uZZH00IOFPdA 25+uFjP/0bYj7LDkrUioGcJvPHnFpQsPilwHTEzFz8Xussk74kARIlhhYq53yxG3SZwfIyyoiqY NwEDAxm7F5xmdXEKgs7xaHvMbpADsUdd0Ra8mf4qodSlvWjb5W9sGyMPJJChYgTEZMqaqOJ5KbG Ao= X-Google-Smtp-Source: AGHT+IFoIKcKZEb6fpXZ3yLHOppIPAnw6aSQPSZKTVyBbq08Aq6Hb6k95aMw0wy4H5RvXABb/dNEoQ== X-Received: by 2002:a05:6000:2c0c:b0:427:23a:c339 with SMTP id ffacd0b85a97d-432bca2ac7fmr3599687f8f.14.1767707418501; Tue, 06 Jan 2026 05:50:18 -0800 (PST) Message-ID: <432bb0bd-96a6-4505-8c1c-7e8eb4de1f5c@suse.com> Date: Tue, 6 Jan 2026 14:50:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 6/6] vPCI/DomU: really no ext-caps without extended config space From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand References: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@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: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Whether to emulate accesses to the first 32 bits of extended config space as read-as-zero or read-as-all-ones depends on whether a device actually has extended config space. If it doesn't, read-as-zero isn't correct; not getting this right may confuse functions like Linux 6.19-rc's pci_ext_cfg_is_aliased(). Fixes: a845b50c12f3 ("vpci/header: Emulate extended capability list for dom0") Signed-off-by: Jan Beulich --- a/xen/drivers/vpci/header.c +++ b/xen/drivers/vpci/header.c @@ -830,9 +830,14 @@ static int vpci_init_ext_capability_list unsigned int pos = PCI_CFG_SPACE_SIZE; if ( !is_hardware_domain(pdev->domain) ) + { + if ( !pdev->ext_cfg ) + return 0; + /* Extended capabilities read as zero, write ignore for DomU */ return vpci_add_register(pdev->vpci, vpci_read_val, NULL, pos, 4, (void *)0); + } do { From xen-devel-bounces@lists.xenproject.org Tue Jan 06 13:58:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 13:58:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196149.1514025 (Exim 4.92) (envelope-from ) id 1vd7ZY-0000ha-HP; Tue, 06 Jan 2026 13:58:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196149.1514025; Tue, 06 Jan 2026 13:58: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 1vd7ZY-0000hT-Df; Tue, 06 Jan 2026 13:58:08 +0000 Received: by outflank-mailman (input) for mailman id 1196149; Tue, 06 Jan 2026 13:58: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 1vd7RZ-0004MT-DD for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 13:49: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 937f2561-eb06-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 14:49:52 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-47d3ba3a4deso6092685e9.2 for ; Tue, 06 Jan 2026 05:49:52 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f69e13bsm43099975e9.7.2026.01.06.05.49.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 05:49:51 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 937f2561-eb06-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767707392; x=1768312192; 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=2cfIXKgHYTFCKsrX1bFpAF8sQFG6ytaJSHI//BPGSL8=; b=HgCtGjAIicX+vNFSnc8f4jIhsV7yovP/PhlrweB0mNJBeSixojNOdvr6NTsPpZTZUR 3eCSMBjmZTBH5uFQ84qnd0aJSF2iiDOgXxeQAMqylPbMbBdn+sIIEgzknwcBf72jlj3h BIeE8osIDuY12KKkSl7LyI0Nzg/zGZ8LFIWVZhUTOwDsS8XPEzytxvKPwU+oQkCao3Fg rZ2yM9MrSgiDHZz5itam+IaDd+mFxRzdVFMW4yNDDVNE4B10YNQz8epEY13jnhNLHXhL 53jFpr3T8wvQdtwhnKOh+BI3O1iNy9Wyl5TDbA3U9HR3xKbL4Yp2NM4g+WZwY14Mb8Fm Vqeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767707392; x=1768312192; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2cfIXKgHYTFCKsrX1bFpAF8sQFG6ytaJSHI//BPGSL8=; b=FMY9GBP7C0ts8itM2xB4MMuNIHQ5zH0gqaUoIsu41iUvy1RWPwS6c3zqWIoDdtiT9N Bl4NqhwdbAIAES+VdfJ7iByFMJ+cp2zF3Vpdh+e3ApbckNSkNBRMZoBTEiuQpqQdib4M N287IFTAcYh9tLKBfNayOlGNpRXTqDfql7ObX7H+rTtyovOmnwH3h6OtxVrw8R1Zq2qp HXV7lvieYzdY8vJ9/BM90r83D3k73vbOwKuB3NCcoMJzJGuOzC+IREZ6MOGApGoBNYP6 /vnH3uutv046BnM4f1FPmbNLwMYcSqM4pGTZG6joS7jyreS9exApBWaBCdqdocbUEAK9 bUGg== X-Gm-Message-State: AOJu0YxKXFswTGOJkRc22VEqpeFo7udM9xn6NbBmujmR9qWckkiQuttA YqMFJ2g6mUI72hTQ2dVzE/tAsSkWltGtDK48ePsQgvnz8AR8V1VutgAMsJOVCglSwBw2CwMUp10 33GA= X-Gm-Gg: AY/fxX6NDM/7f23vfSTsXAUhGe2SfsEfIo83puKfDhJE0fkWZy7ejBue6NQiDhlmMp9 5kNmH4Na+3PH0Yow8BlNnIY5QeXzvvRS3h+u0jzgVAIb0mZSieXr53QWIC7rgRuvflbrFn2DeuN EOj4p9DPtHaaPOcLKzKNYmYE2JtnTHbp/tgE/Pg78sZC/sdYnlMeZaHdDqC+vePwYbzU+w/Ut/K wx6X8ZZDp8xJsNCnOXiDDEDrbdZWByuUg3+Pq7SL9JFfHzQ2vyoRFmiGcnl02e+pDkuiaTrcX9o hayjVn8HaZAYbedGO799j8ZAMfKUzg64U9OYfzAtkoDaFt3YD6beyoF4FY7THlb8jBa9qusTlIP yqi68PffjXasjWdskXiNaZsoQnnVuTr8VQ9VHcAVq5v6mffVFNXaPNbZukZt8auHVv2ovyA8fUm nqT/uXqEuMpIVnEvlpF7TP8aFUas1bZtcOzYZp1we1POgxovh9ezjX13pbvkOJroYLWfRztan/V k0= X-Google-Smtp-Source: AGHT+IExk9a4kJflf5MXqX0+A74y+swup+hf1gx6iK7W3f/9V+3U0r2+q1yX0qkByPjLKAKoVBZhgA== X-Received: by 2002:a05:600c:620c:b0:477:54cd:200a with SMTP id 5b1f17b1804b1-47d7f066c8emr33236895e9.6.1767707392064; Tue, 06 Jan 2026 05:49:52 -0800 (PST) Message-ID: Date: Tue, 6 Jan 2026 14:49:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 5/6] PCI: don't look for ext-caps when there's no extended cfg space From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand References: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@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: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Avoid interpreting as extended capabilities what may be about anything. In doing so, vPCI then also won't mis-interpret data from beyond base config space anymore. Fixes: 3b35911d709e ("Enable pci mmcfg and ATS for x86_64") Fixes: a845b50c12f3 ("vpci/header: Emulate extended capability list for dom0") Signed-off-by: Jan Beulich --- Because of the multiple prereq changes, despite the Fixes: tags I'm not quite sure whether to backport this. (I'm leaning towards "no".) --- a/xen/drivers/pci/pci.c +++ b/xen/drivers/pci/pci.c @@ -113,6 +113,12 @@ unsigned int pci_find_next_ext_capabilit int ttl = 480; /* 3840 bytes, minimum 8 bytes per capability */ unsigned int pos = max(start, PCI_CFG_SPACE_SIZE + 0U); + if ( !pdev->ext_cfg ) + { + ASSERT(!start); + return 0; + } + header = pci_conf_read32(pdev->sbdf, pos); /* From xen-devel-bounces@lists.xenproject.org Tue Jan 06 13:58:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 13:58:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196157.1514035 (Exim 4.92) (envelope-from ) id 1vd7Zg-00017D-Or; Tue, 06 Jan 2026 13:58:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196157.1514035; Tue, 06 Jan 2026 13:58:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd7Zg-000173-Le; Tue, 06 Jan 2026 13:58:16 +0000 Received: by outflank-mailman (input) for mailman id 1196157; Tue, 06 Jan 2026 13:58: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 1vd7Ze-0000Ic-Rh for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 13:58:14 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bddc0357-eb07-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 14:58:13 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-47bdbc90dcaso7326685e9.1 for ; Tue, 06 Jan 2026 05:58:13 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f70bc4fsm43681615e9.15.2026.01.06.05.58.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 05:58:12 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bddc0357-eb07-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767707893; x=1768312693; 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=r/ifospxoAmGxl7rlu8s5a4uuTwWZrTxZ5REb4+DRPA=; b=PVx4I6E/vCgBOBWGd6SBBiAbDNkwvO0dxRYtitW1wc15bmktNcaU4gcZTlpD5e7N8f TcWyN/tFeBocW3dxZDpIajBLZQ/eDX4zU9mO9ofwCMQk2Ocug8nK74vUmV8mR/VZkoAv da7hKC1uWmEsrtu8/+9ystgx2NyNPoBTQT2Eli2iLqunX/n3y0iU/1C4Vl9Jdt//tSvT wksyj8O2yQgSnpXk6Bi6HsBrp9empRMH3JiG5drl+CzDcURR5qyqU0wLb6XOauvmY+qd twkIq3mw7MjGEi4tvqLBigM8GEIHZxLDDPQGkQn2P2KpHzIuIS13l3Y700R3hp4XeHVH 1DQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767707893; x=1768312693; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=r/ifospxoAmGxl7rlu8s5a4uuTwWZrTxZ5REb4+DRPA=; b=Curwb+0/8luzzyt4HXs+/uCfB+L6G2Mh2RA/TiYqHkGcyB+NQoVcL6Q8904bmSMa6s pZijoD+hXgnFM40EP57faSkBxh0MRYReOFgg+mlOybK22kZ6fIDnXC+sCdR3qubZ5iOd S78mm0Luks9SRqeXizLB7z4m+H0C9GO9qJsZjCE4pgssHBASNOB4iS3dh7NPkJC07EbO Mb1o3d+MBOtwKJMPwiir8DdJrzh4gg0UZgRFPHhQPrDgPJMVQ6gvoRtkbhT/hRrp5zRz vvmAb6c9/TnmR8Li+BBMhcsjt6vYfMZhS7FFq7FcrX/eKhRYz2G1SVnIBFg0/yMnEnQt birw== X-Gm-Message-State: AOJu0YwYkqtE5FPgLj3VL7tId7fLgJjoo9GQY0b7NNN3Ah31Mc3272nW DVoNya6d7aw4J1RRcg0SsEvkP6585ahh66So96vvQTrPcBsif047mHg24yTMGTMVullMD7bzxTG aOPo= X-Gm-Gg: AY/fxX4lyCTfFVqLzzr0nDKgk9blQSzWG2yxuQ0hONozyDiWuBEsFrhlgm4t94hGUqW 5UyUpQ/4Q6Ki+suM02K9lJ6gLOIp1ehNXBI67EGlvRcsewY5TY9lEzTDI91MAd9Z0P6aWmLVIa4 dWd2kQAvHbmLboEKOMpSjo+H0u2LPhzIvZCHmayDJTdyAkcXbdItU+A2rKhQjZi7S+xXkEjCg/j sQIw/N6zvCXqJ3PTx5H3CTK3FKNS5n8z1MoHV79u8l1YWzDoB1Ltxk0I+bHRO1G0MWn1g6Wlba7 eIzRSk5TwAU9+v72swTfBylVRG0B1AgNlqa3AeyYDohYxoINKLzUZ+Xrxdi8Ql4Vra46A82HpLa bNH5ENOIrBBT5/pNc4sqddBL6Uuo2y2uFzqrYJYUVgzaNefChG1PhiDUUXTKRhWa6P9Isi5lCtC JLXIiIkbvHnb5rSJEmljqK/oP6vIPxckHcqdkDiRTBJQgirCZXU9dVQBulaXp+WbWC5kho5WeI6 fk= X-Google-Smtp-Source: AGHT+IESFugYWnSWR1GVQ6MKPDsm28/iwTFbijmreacv6DKgHXqXKRAEV7WwUQVI7g9BZJmJcvPLIw== X-Received: by 2002:a05:600c:5289:b0:475:de12:d3b5 with SMTP id 5b1f17b1804b1-47d7f0a94e9mr34155405e9.34.1767707892696; Tue, 06 Jan 2026 05:58:12 -0800 (PST) Message-ID: <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> Date: Tue, 6 Jan 2026 14:58:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , =?UTF-8?B?0JDQvdGC0L7QvSDQnNCw0YDQutC+0LI=?= References: <66a53368-9c33-436c-858e-2b2d25ae84b7@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: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Callers may pass in TSC values from before the local TSC stamp was last updated (this would in particular be the case when the TSC was latched, a time rendezvous occurs, and the latched value is used only afterwards). scale_delta(), otoh, deals with unsigned values, and hence would treat negative incoming deltas as huge positive values, yielding entirely bogus return values. Fixes: 88e64cb785c1 ("x86/HVM: use fixed TSC value when saving or restoring domain") Reported-by: Антон Марков Signed-off-by: Jan Beulich --- An alternative might be to have scale_delta() deal with signed deltas, yet that seemed more risky to me. There could likely be more Fixes: tags; the one used is the oldest applicable one, from what I can tell. A similar issue looks to exist in read_xen_timer() and its read_cycle() helper, if we're scheduled out (and beck in) between reading of the TSC and calculation of the delta (involving ->tsc_timestamp). Am I overlooking anything there? stime2tsc() guards against negative deltas by using 0 instead; I'm not quite sure that's correct either. amd_check_erratum_1474() (next to its call to tsc_ticks2ns()) has a comment towards the TSC being "sane", but is that correct? Due to TSC_ADJUST, rdtsc() may well return a huge value (and the TSC would then wrap through 0 at some point). Shouldn't we subtract boot_tsc_stamp before calling tsc_ticks2ns()? A similar issue looks to exist in tsc_get_info(), again when rdtsc() possibly returns a huge value due to TSC_ADJUST. Once again I wonder whether we shouldn't subtract boot_tsc_stamp. --- a/xen/arch/x86/time.c +++ b/xen/arch/x86/time.c @@ -1649,8 +1649,13 @@ s_time_t get_s_time_fixed(u64 at_tsc) tsc = at_tsc; else tsc = rdtsc_ordered(); - delta = tsc - t->stamp.local_tsc; - return t->stamp.local_stime + scale_delta(delta, &t->tsc_scale); + + if ( tsc >= t->stamp.local_tsc ) + delta = scale_delta(tsc - t->stamp.local_tsc, &t->tsc_scale); + else + delta = -scale_delta(t->stamp.local_tsc - tsc, &t->tsc_scale); + + return t->stamp.local_stime + delta; } s_time_t get_s_time(void) From xen-devel-bounces@lists.xenproject.org Tue Jan 06 13:58:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 13:58:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196164.1514045 (Exim 4.92) (envelope-from ) id 1vd7Zy-0001j8-4K; Tue, 06 Jan 2026 13:58:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196164.1514045; Tue, 06 Jan 2026 13:58:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd7Zy-0001j0-1E; Tue, 06 Jan 2026 13:58:34 +0000 Received: by outflank-mailman (input) for mailman id 1196164; Tue, 06 Jan 2026 13:58: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 1vd7Zw-0000Ic-OF for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 13:58:32 +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 c87719c0-eb07-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 14:58:31 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-42e2d02a3c9so662912f8f.3 for ; Tue, 06 Jan 2026 05:58:31 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0daa84sm4538795f8f.2.2026.01.06.05.58.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 05:58:30 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c87719c0-eb07-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767707910; x=1768312710; 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=qbeAdy4fJOCoiATm+OOVH4vL9Ep2W/kjzFBlSuDnJHg=; b=AAk4cKEH/MNAF6bbT/iomc7jS8D4jE4uWO2rzpmxju8Xz6NS0NqU+a/EF+uhzRmv/j mL6dpLTvQdt55RbEuCuCfdDU92VBBGKztaND4ON4jcnfN8HCOKuPh6y0yG/WVd+GBMts LXgJjRCu0qXp70RXFn5sYSlb7Hinq/zvKh3bpG5XW2HSjb0OPdZjJJEklTrCUhYAGBiU Tm8c5d0iHL734kJ4AcnozzyDqnY/1x0JSiQ+3HLwRk/Rym1bddA4ZR/7e6IcXVrhko34 zancJj0UMElkl+YEFix2nu4Ymmuu3d4Rw7PGmF7yl14AAJlOFlCic2jU19ZWGN7cYKmt /OEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767707910; x=1768312710; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=qbeAdy4fJOCoiATm+OOVH4vL9Ep2W/kjzFBlSuDnJHg=; b=wSqDFDnuO+DdY51yA7d0Y2loOkmthTh2VcOuSN6r3Qb2HfU052kDPPuo63vGJk+GmX msqdkJhf4tCQ26qW4tC1An1S3Q8Wvahnh9XcYq129gfRtEoVBccQO90MiVtTVujjSGB0 OHS8eIvGxqA2vTEAmXrG157bvsM3xig7PMWGB5VzHzwWeFBC4jmnjGu9XA6bMlNJ7SU9 5tzLvG5cuptESV2CaQsrd4WGU3v5GeETUV9hEWJMgmr1BeO7eBHKnu+NX2W0kDxCoGSY pz/cUqNL/JIJclogXdUhnFjW6Q8k9XLy6NUsKOiYurlH+eG0Z4Nr575PDZp6HQ3LvhTw V8NQ== X-Gm-Message-State: AOJu0YygxPN/dsy0UlWpAXJ7g2QICcdn5ZEkRx+5jHFwAAQmVx5UtOQk 5ZKiVoZ0uGEwWUeQwc1Jh4lZF1Eqbo/KHuEZBeGoBvqZslsFSMflee9wYCSCrJgbn0H6c40fiSg 7hN4= X-Gm-Gg: AY/fxX4Fua3DdFCSwhjm9HqNsFNSgwPvAdbW0xFHY11p1yr8IqNLOCHipGnVK+2/izk wfG2lZ3SVnjlGcPYzDHiu5Kbi91DnKdfvugfeCE/Rme4Vi84+nt3CSVpTbsUA7lxauGyEf1g5MX 0wZE5HAD0LUUdXSbV2kEW6CD4tF3aB4e3o0VoKYAtWCV9Bg7dPRBLZ/nefo4cSUndWHJNN3evVk hvhR6WBqWOxkkkKC8g0aEgDL/22W6kge2cLXQtgv6VeXxN5NG0q/fS5Jt/IFdS5rmp1xXrTi0Zr VvaUsXAnsCdIBNqaLPdd7btRh2uRMaIq4bVNdhJBQUQBm1JVzP3fLVeGexP1lApfXFSjLFAw0z5 o9vaf2D128gNMoYZyP1zpVv5UHy2HTBXwzGrvyoxgu25frRxYezBRxIAMP19PVVVVLxkleWjZpy /24FLChq9Bi0RDbGm+tEKtusS6829y2tIPYHb7BiKCI2PwiDvHI7hdbni/6Nv54zEpvRJKS0+rc R0= X-Google-Smtp-Source: AGHT+IGs8dt/cpuz54Rk28BksowpcERFXjUxejHHjhnBtQD+XHzSST3nTisOBYQYPDD/p+vcm0aNnQ== X-Received: by 2002:a5d:5d08:0:b0:430:fb00:108f with SMTP id ffacd0b85a97d-432bc9d272dmr3811591f8f.18.1767707910383; Tue, 06 Jan 2026 05:58:30 -0800 (PST) Message-ID: Date: Tue, 6 Jan 2026 14:58:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 2/5] x86/time: scale_delta() can be static From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <66a53368-9c33-436c-858e-2b2d25ae84b7@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: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit It's used in time.c alone. Modernize types while there. Amends: 5a82d598d2d ("viridian: unify time sources") Signed-off-by: Jan Beulich --- a/xen/arch/x86/include/asm/time.h +++ b/xen/arch/x86/include/asm/time.h @@ -56,7 +56,6 @@ u64 stime2tsc(s_time_t stime); struct time_scale; void set_time_scale(struct time_scale *ts, u64 ticks_per_sec); -u64 scale_delta(u64 delta, const struct time_scale *scale); /* Programmable Interval Timer (8254) */ --- a/xen/arch/x86/time.c +++ b/xen/arch/x86/time.c @@ -131,9 +131,9 @@ static inline u32 mul_frac(u32 multiplic * Scale a 64-bit delta by scaling and multiplying by a 32-bit fraction, * yielding a 64-bit result. */ -u64 scale_delta(u64 delta, const struct time_scale *scale) +static uint64_t scale_delta(uint64_t delta, const struct time_scale *scale) { - u64 product; + uint64_t product; if ( scale->shift < 0 ) delta >>= -scale->shift; From xen-devel-bounces@lists.xenproject.org Tue Jan 06 14:00:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 14:00:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196182.1514055 (Exim 4.92) (envelope-from ) id 1vd7bn-0003YH-EG; Tue, 06 Jan 2026 14:00:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196182.1514055; Tue, 06 Jan 2026 14: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 1vd7bn-0003YA-BL; Tue, 06 Jan 2026 14:00:27 +0000 Received: by outflank-mailman (input) for mailman id 1196182; Tue, 06 Jan 2026 14: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 1vd7bl-0003Y4-R2 for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 14:00:25 +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 0b86e8b6-eb08-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 15:00:23 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-4779adb38d3so7683695e9.2 for ; Tue, 06 Jan 2026 06:00:23 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0dad8bsm4656713f8f.8.2026.01.06.06.00.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 06:00:22 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0b86e8b6-eb08-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767708023; x=1768312823; 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=mUKumA/eSvAXgzYPa6wZCvrzBSQf3BW7uOlRVhXEMGg=; b=ahGHzP6DLUcqQ7fs25W/EqeQt8s4MfqXr5yVHiWDwPYM1mQ16CfwqP4UO6O9kAke1A GystfiFUnFSsbcHraFm7EJ397l6yBNIkgVQL+Bb5xCfe377huKN0jzosuz5xHn33NAs/ bbzqdd+UWCV3LOvGGD+JwUjU7P9jTSV+XwVz6XKvbwNPU15FOGYG5M5xaxspmEvEKj2U oIubnZF1Jtqydi5abVw4455pbyrdUyQbnlbvzX48V2/uCC2l8a0vFXYFUlZud+H+ttTz wzhLQszQxf6winYCzO8cyXFRQSe24nHuhNydcLFhFB6HcA8YL4ck7Jl8prkhqMoHbI3D oWpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767708023; x=1768312823; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mUKumA/eSvAXgzYPa6wZCvrzBSQf3BW7uOlRVhXEMGg=; b=T2JKVOd81wwq69GpQKYcAWcHRkSFiMc1k3diVUYsCmkzX2bs8ieTfl6Yg0N2HCfb7h LJ1EXXsVe2nUR+sHq1I7Foh3pYKB4EojRyIBjgakz2m90ZNurbi74N58BAeIvJogba7z RZyeQMaPothzY/0FXTOY31ki9F8FEcsMfQSYD646KrJyFKIW5p1wEyEIe47A1U8K8AjX EsEngZX2D18pZur4R1o2ADBo4orVonVGhmtvFeHIW0mERuBBiGyquC7sA3TY+euchaXF ClwBCCRxzOK9hzZOJO/8CFJlYBH9h+Rf8LMWQEBlgaUH4nHfbbXNXkJvjpJpiOttHsfs iZXw== X-Gm-Message-State: AOJu0YzkV+ZMVqbhc18Ddg0a0RtBxNlM3JhjNpOeP6Nb6tYLF5M8p2aO gWg7eRXcli3MM9nCnTkMKHu2DL9PMCTS8acV0oCuPMAOgccC0BVzwjDknEoxaORrI9OwxbYkb47 QR80= X-Gm-Gg: AY/fxX5UMPjB7uNTOr2L9SbuSJDNSOvadfhPJe7SWtw/VctI/up1rxKvTusl1RDBh5s 65y9QPR7Rszi3yZMTmhq7Vdv0Fq/upNU9B31YRNavRrOU9kQm1CL33XyOVtVdqf2g+povb69b8Z gfgBvI8f70bA8n86z2hJc1glIMwR2V7bRpUM6gM1kS0Zgb4r4kF/rsIwAgx7LwQB57UFD8dj/iO AvwdS57VtnzUwK9CB1jPDU8NHsmvBfKlzQvgDuEdvZBErNXk0JjyUcIN+Lv70OdYMUU3cqUG3N/ s7NB/W8ZHFzjkHui+gs6kvIiyOYUHQ6IUwumRPHdUcQXX2cs2CiaUCHXNRTzW4ptxtupPvudOTS WTcHyy3nSA6lrWVpRX7XfZhQmY7bevOTu3ZqL8HYFAsdRyrrXn+QVuF1li9F3+jErCvHLm4wpVr Y8sboNNzLrc+Lmqxis8CC+lGJvzCexL3V3pxJyl9mpwTWSl3pJRDeQQFmNjh8ThXq82bpgSIDEz hY= X-Google-Smtp-Source: AGHT+IHY95kcdHPxzm5HEAVWP8bxzJnA+ZrGdPY3OXpzuMGfiL6929Ime8G2sAWu9aPCN/sb41102g== X-Received: by 2002:a05:600c:1384:b0:477:fcb:226b with SMTP id 5b1f17b1804b1-47d7f05d468mr31298525e9.2.1767708022953; Tue, 06 Jan 2026 06:00:22 -0800 (PST) Message-ID: <5467f5c4-e752-4d44-bbb7-05e6fa1a672c@suse.com> Date: Tue, 6 Jan 2026 15:00:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 5/5] x86/time: pv_soft_rdtsc() is PV-only From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <66a53368-9c33-436c-858e-2b2d25ae84b7@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: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Omit the function when PV=n, by moving it to the sole file using it, thus allowing it to become static as well. Signed-off-by: Jan Beulich --- a/xen/arch/x86/include/asm/time.h +++ b/xen/arch/x86/include/asm/time.h @@ -37,8 +37,6 @@ uint64_t cf_check acpi_pm_tick_to_ns(uin uint64_t tsc_ticks2ns(uint64_t ticks); -struct cpu_user_regs; -uint64_t pv_soft_rdtsc(const struct vcpu *v, const struct cpu_user_regs *regs); uint64_t gtime_to_gtsc(const struct domain *d, uint64_t time); uint64_t gtsc_to_gtime(const struct domain *d, uint64_t tsc); --- a/xen/arch/x86/pv/emul-priv-op.c +++ b/xen/arch/x86/pv/emul-priv-op.c @@ -874,6 +874,20 @@ static uint64_t guest_efer(const struct return val; } +static uint64_t soft_rdtsc( + const struct vcpu *v, const struct cpu_user_regs *regs) +{ + s_time_t old, new, now = get_s_time(); + struct domain *d = v->domain; + + do { + old = d->arch.vtsc_last; + new = now > d->arch.vtsc_last ? now : old + 1; + } while ( cmpxchg(&d->arch.vtsc_last, old, new) != old ); + + return gtime_to_gtsc(d, new); +} + static int cf_check read_msr( unsigned int reg, uint64_t *val, struct x86_emulate_ctxt *ctxt) { @@ -920,7 +934,7 @@ static int cf_check read_msr( return X86EMUL_OKAY; case MSR_IA32_TSC: - *val = currd->arch.vtsc ? pv_soft_rdtsc(curr, ctxt->regs) : rdtsc(); + *val = currd->arch.vtsc ? soft_rdtsc(curr, ctxt->regs) : rdtsc(); return X86EMUL_OKAY; case MSR_EFER: --- a/xen/arch/x86/time.c +++ b/xen/arch/x86/time.c @@ -2848,19 +2848,6 @@ uint64_t gtsc_to_gtime(const struct doma } #endif /* CONFIG_HVM */ -uint64_t pv_soft_rdtsc(const struct vcpu *v, const struct cpu_user_regs *regs) -{ - s_time_t old, new, now = get_s_time(); - struct domain *d = v->domain; - - do { - old = d->arch.vtsc_last; - new = now > d->arch.vtsc_last ? now : old + 1; - } while ( cmpxchg(&d->arch.vtsc_last, old, new) != old ); - - return gtime_to_gtsc(d, new); -} - bool clocksource_is_tsc(void) { return plt_src.read_counter == READ_TSC_POISON; From xen-devel-bounces@lists.xenproject.org Tue Jan 06 14:07:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 14:07:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196202.1514076 (Exim 4.92) (envelope-from ) id 1vd7ip-0004o4-DO; Tue, 06 Jan 2026 14:07:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196202.1514076; Tue, 06 Jan 2026 14:07: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 1vd7ip-0004nw-8H; Tue, 06 Jan 2026 14:07:43 +0000 Received: by outflank-mailman (input) for mailman id 1196202; Tue, 06 Jan 2026 14:07: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 1vd7b9-0000Ic-6G for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 13:59:47 +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 f4ca02ae-eb07-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 14:59:45 +0100 (CET) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-43246af170aso568541f8f.0 for ; Tue, 06 Jan 2026 05:59:45 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0e1adbsm4682325f8f.17.2026.01.06.05.59.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 05:59:44 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f4ca02ae-eb07-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767707985; x=1768312785; 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=YfooQE8xDDthz+4K3ntwahmx+kDJ4t+nLpvD3J6Xa0o=; b=e7rChalbrBiJP+j9GJJPJ2BQaMW1HkbgnHdbWigWbU9nSZpOw1ZsmdDkcCuyYqQC2M xFQKrloCycnZDh6Dgc3QPn8iremNvSMgTMAQH8Q5n63gVxd+D2reXM4HnggMEINQxkQO jlGyp9AvrXaii/mEp77ZwQzc1LHVl2ls7PCfoOKuc1XOmgW2mjsJtAeiCiQQMSxZo1Mh vjOvF1HkzxmlgMOuYdMkDa6huWG5LjSdDuqxjlQCrDiwpUNu1ZlWSNcqVOgGKz8gb9B8 WxYYt/KsTC+5dupwqPG7YLQR9AH7Db6FYYMTIxMc7FE0AsXJGwBXedw69Ubc6orH8TM9 BcWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767707985; x=1768312785; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=YfooQE8xDDthz+4K3ntwahmx+kDJ4t+nLpvD3J6Xa0o=; b=FXKPwHtUiBpJKqMOU9q6XQYA1SOBIiWGnNdcBVIjvZc7T/GdqFotbAGnaqYHrdhNMJ 02bnmuiQ4meCL+ILUstt0jIFEuJyLfUMLT6jpCbI0R84kJru3gqEEVAL0jIrRPp+Redh UW8nnF7e2xDwxHhcEI44YxIWQlWMLRQDFukh0VHjhm50mPELsF1gbSK9aoLRk6zxzGLP rWf8fB3YZ+nBt+6tME6z2nYTwxGTm5bjlYmBUBJLobZEG3HqT4O5Vzvv67GLcP18aSOj EiEJbU0pUYow+QbDTGfZl2hyLio53t1SNdm5nCeOHE7ZKcMvCBn6WhKwVr0xKZ3wFgso tZDA== X-Gm-Message-State: AOJu0YzYA49csU5lKNje6oibCi0g5UV1CVw9/ZsM2QsC9e1Ob8Iv0Ax2 WVbD56ZHBPR2ztqDQNxuu1hkfVnwSLNwtqjWnMgZCJtMWwRUwXhfwXz8fGUrqYzchgekbzoGd2Z 8yto= X-Gm-Gg: AY/fxX4m8Ab3Je0aioVdib5GfWTjVGOQjYl53bGugfyjNyqLuhQ0H4aJ6l4wPQz2Uq4 vEcso6wDPN3nROJWRTJpwrlq6jhEmNTW8CB1PqZn6ELU2AmpL+vn8lfSehTAv6hZqxPDhG0td2e L1NZF8aGpp1mNru8/eqVw+G0cjHvp5ySvoHlKdPy8HNGsMPHzjN4clkZUIEX29fIU1cT/o0OI7c gcCTzsyr8RrJZvkx7v7mmVjuq45Jmi+CUZCWl85Xlbi0DHdnQYEgIc+5iZw1NJuiqQQwVycyBvJ GZQeikjYuvxtQAhuUZ1th+4NowL9DHYy+IYW6Op2Armyc1dUz6GT9FC/eeqLTU9I+Lc5TnGRhlB yURW32o6sRcsB/QG2bkRtOgqazFkso+6u4JAmDAW5nWCHrWYrsKNn6K697q0EMf3T8V5pXpSa5v FxB9v/67twuPyHxqfOkWJFec0Y8EMJwkFP2PvIX8dIwkni5KIO7H2EVYiUgJnaYr+fDEZ5bwOL+ do= X-Google-Smtp-Source: AGHT+IEmEb4GNZ4LQani0gWmVmOvIO6J/jf0qV6+//ns/nO7VSMpuKJYFdNvqeudPiMcRiJv0q4/7Q== X-Received: by 2002:a05:6000:430e:b0:432:b953:b02b with SMTP id ffacd0b85a97d-432bcfd3d7cmr3819280f8f.16.1767707984860; Tue, 06 Jan 2026 05:59:44 -0800 (PST) Message-ID: <79c32e1e-15d6-4b9a-9645-1429a21e63ec@suse.com> Date: Tue, 6 Jan 2026 14:59:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 4/5] x86/time: gtsc_to_gtime() is HVM-only From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <66a53368-9c33-436c-858e-2b2d25ae84b7@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: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Omit the function when HVM=n. With that the !HVM logic can also go away; leave an assertion. Signed-off-by: Jan Beulich --- a/xen/arch/x86/time.c +++ b/xen/arch/x86/time.c @@ -2840,14 +2840,13 @@ uint64_t gtime_to_gtsc(const struct doma return scale_delta(time, &d->arch.ns_to_vtsc); } +#ifdef CONFIG_HVM uint64_t gtsc_to_gtime(const struct domain *d, uint64_t tsc) { - u64 time = scale_delta(tsc, &d->arch.vtsc_to_ns); - - if ( !is_hvm_domain(d) ) - time += d->arch.vtsc_offset; - return time; + ASSERT(is_hvm_domain(d)); + return scale_delta(tsc, &d->arch.vtsc_to_ns); } +#endif /* CONFIG_HVM */ uint64_t pv_soft_rdtsc(const struct vcpu *v, const struct cpu_user_regs *regs) { From xen-devel-bounces@lists.xenproject.org Tue Jan 06 14:07:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 14:07:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196199.1514064 (Exim 4.92) (envelope-from ) id 1vd7ij-0004Vv-4L; Tue, 06 Jan 2026 14:07:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196199.1514064; Tue, 06 Jan 2026 14:07:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd7ij-0004Vo-1G; Tue, 06 Jan 2026 14:07:37 +0000 Received: by outflank-mailman (input) for mailman id 1196199; Tue, 06 Jan 2026 14:07:36 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd7aM-0000Ic-9g for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 13:58:58 +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 d7b5f913-eb07-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 14:58:56 +0100 (CET) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-430f3ef2d37so812960f8f.3 for ; Tue, 06 Jan 2026 05:58:56 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0e19bfsm4654784f8f.18.2026.01.06.05.58.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 05:58:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d7b5f913-eb07-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767707936; x=1768312736; 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=/W6SkAbgch3VF6wNy3YU3AMUhJhp6OUaf6yGBOkOVJw=; b=dDgYK9JvFvg8xYLxeoaQtW7gQs9gCBI8E6R9OTnInEhsHqMBM2flrd5WR8nfm5LzBY jTcWMIixZa0W0rkZFi9TAeO7Gw+8teJ+ZqpAl9XOhWB6Wl70OGO7dd2nQtmtfOePd2UN 62tKgE9JxZ1AT522Za4Vu85erIxA0+k1YWk8R1XHlV2QnSIiTb/WL7w8OlwXj6PcgFgc 5r4pavkYf3xnb7FW7E7FdPMIl5S4Ho+joEXOTlDOpZGkvgv/tk35y9nGMhNcBmKA97xg EOr9evFX3LYroBjgWzm0e9VbpQlwjOacO4qPb11li5bA0jP93v+rCGaGd0wb4KK6hysi 5OQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767707936; x=1768312736; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/W6SkAbgch3VF6wNy3YU3AMUhJhp6OUaf6yGBOkOVJw=; b=ReHjUGB5ty5q+XsPkdpQAu0wGh0D4ZJVqfb+Nc26Xv8jaUOiJkNhJwtc08le79dBZo 440lqm3BmlQFHHPClon4ROACr9NSZRyXk5mryhQSL6Rm2cNci0WUdssC0IcUF7EpM/uZ Aw0JUAHpZBuhWzQRMQguzGvQHTHsQ29kr3JemgTf4Ke8QvUM02H5w0JXeJW6PybPmbi/ Wss8WGWp7R+tPxxcImXcVUKiAo2GdWumBLgXVXXzPIhbq/xDHPR0NXdJ/zT+eqRl7nem HTxQQiNaF5vNRPncQpfP1zW4ERdV6BtmnETpfQ00ET4OrZT14q2czkhpVoVR3aCqnAYN kpVw== X-Gm-Message-State: AOJu0YwGrIfQlQzcfeT21wNyrJ36T1e0LU77FHk5vJ1u2oNcy9smA0nq dz23kjZhALji2XzOOJBzbkM98QgXEcHdHMDecI8W1nUhj8wu7UYLKvqxuXCIHTNbzUo23cWnwzY Qe/k= X-Gm-Gg: AY/fxX4b3gIggiodN9Un0xIF3mz6by51rpVXNDFU33Ys95Nge5WGy4NvK/C6v8ZIQgm B+aPfQeKBmVm9StfS/JyvPM0LLyYe/c5myAKSWUbeyQ5JxitSY6GAbWChztX9i4pNsx8RYDtAr9 TRUHwwKiInD2oCwvhFVTzSxKFT16GT4W1IQoXwI64SqMcm3paTquibttFWioJL26JHZG5ljeK4t UYFKlYPPtHJsKCF69cmfanwpv2v6NGvDxsMPfwV50XAT2AsKUDKEVUFxgwv8IGbhlH18Lxz3oio RW0WYsStR8WtNIz5ULwy0hgISbGtRp/BXxtyuTKeAhC0EHlYCBm/fYdUu85BEjKfuX86Ak7ibO4 VeyVwOaNCrwcn4OqRUGi6zSf/cZYrGBPHwi8+JPibl7DWSHnbna2s08Vj6DwrbHPca9cMpnPQZB jpIbHe4RQFzdfKAjwFgvbtPt7zNYm3oE2ZjKudHX3GIEz00DWVrzquicl3YNcEskw9/36gYIVhY sJ688s7axq1zQ== X-Google-Smtp-Source: AGHT+IEGeRGZxtt1c2ZvMypgAJp7gPNtwh7MGE9GrSiyIhqdrHGTy53gt/Im7l3M7uDHN9ud0RefRA== X-Received: by 2002:a05:6000:400b:b0:430:fcda:452d with SMTP id ffacd0b85a97d-432bca312admr3431267f8f.22.1767707935839; Tue, 06 Jan 2026 05:58:55 -0800 (PST) Message-ID: <366597a9-c506-4183-bdee-8ef3d1045669@suse.com> Date: Tue, 6 Jan 2026 14:58:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 3/5] x86/HVM: drop at_tsc parameter from ->set_tsc_offset() hook From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <66a53368-9c33-436c-858e-2b2d25ae84b7@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: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit While the VMX hook never used the parameter, the SVM one lost its sole use some time ago (while the original use of the parameter had gone away even earlier). Again modernize types while there. Amends: 0cd50753eb40 ("nestedsvm: Disable TscRateMSR") Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/domain.c +++ b/xen/arch/x86/hvm/domain.c @@ -312,8 +312,7 @@ int arch_set_info_hvm_guest(struct vcpu /* Sync AP's TSC with BSP's. */ v->arch.hvm.cache_tsc_offset = d->vcpu[0]->arch.hvm.cache_tsc_offset; - hvm_set_tsc_offset(v, v->arch.hvm.cache_tsc_offset, - d->arch.hvm.sync_tsc); + hvm_set_tsc_offset(v, v->arch.hvm.cache_tsc_offset); paging_update_paging_modes(v); --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -412,7 +412,7 @@ static void hvm_set_guest_tsc_fixed(stru delta_tsc = guest_tsc - tsc; v->arch.hvm.cache_tsc_offset = delta_tsc; - hvm_set_tsc_offset(v, v->arch.hvm.cache_tsc_offset, at_tsc); + hvm_set_tsc_offset(v, v->arch.hvm.cache_tsc_offset); } #define hvm_set_guest_tsc(v, t) hvm_set_guest_tsc_fixed(v, t, 0) @@ -430,7 +430,7 @@ static void hvm_set_guest_tsc_msr(struct static void hvm_set_guest_tsc_adjust(struct vcpu *v, u64 tsc_adjust) { v->arch.hvm.cache_tsc_offset += tsc_adjust - v->arch.hvm.msr_tsc_adjust; - hvm_set_tsc_offset(v, v->arch.hvm.cache_tsc_offset, 0); + hvm_set_tsc_offset(v, v->arch.hvm.cache_tsc_offset); v->arch.hvm.msr_tsc_adjust = tsc_adjust; if ( v == current ) update_vcpu_system_time(v); @@ -4023,8 +4023,7 @@ void hvm_vcpu_reset_state(struct vcpu *v /* Sync AP's TSC with BSP's. */ v->arch.hvm.cache_tsc_offset = v->domain->vcpu[0]->arch.hvm.cache_tsc_offset; - hvm_set_tsc_offset(v, v->arch.hvm.cache_tsc_offset, - d->arch.hvm.sync_tsc); + hvm_set_tsc_offset(v, v->arch.hvm.cache_tsc_offset); v->arch.hvm.msr_tsc_adjust = 0; --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -779,7 +779,7 @@ static int cf_check svm_get_guest_pat(st return 1; } -static void cf_check svm_set_tsc_offset(struct vcpu *v, u64 offset, u64 at_tsc) +static void cf_check svm_set_tsc_offset(struct vcpu *v, uint64_t offset) { struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; struct vmcb_struct *n1vmcb, *n2vmcb; --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -1558,7 +1558,7 @@ static void cf_check vmx_handle_cd(struc } } -static void cf_check vmx_set_tsc_offset(struct vcpu *v, u64 offset, u64 at_tsc) +static void cf_check vmx_set_tsc_offset(struct vcpu *v, uint64_t offset) { vmx_vmcs_enter(v); --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -1114,7 +1114,7 @@ static void load_shadow_guest_state(stru hvm_inject_hw_exception(X86_EXC_GP, 0); } - hvm_set_tsc_offset(v, v->arch.hvm.cache_tsc_offset, 0); + hvm_set_tsc_offset(v, v->arch.hvm.cache_tsc_offset); vvmcs_to_shadow_bulk(v, ARRAY_SIZE(vmentry_fields), vmentry_fields); @@ -1330,7 +1330,7 @@ static void load_vvmcs_host_state(struct hvm_inject_hw_exception(X86_EXC_GP, 0); } - hvm_set_tsc_offset(v, v->arch.hvm.cache_tsc_offset, 0); + hvm_set_tsc_offset(v, v->arch.hvm.cache_tsc_offset); set_vvmcs(v, VM_ENTRY_INTR_INFO, 0); --- a/xen/arch/x86/include/asm/hvm/hvm.h +++ b/xen/arch/x86/include/asm/hvm/hvm.h @@ -165,7 +165,7 @@ struct hvm_function_table { int (*get_guest_pat)(struct vcpu *v, uint64_t *gpat); int (*set_guest_pat)(struct vcpu *v, uint64_t gpat); - void (*set_tsc_offset)(struct vcpu *v, u64 offset, u64 at_tsc); + void (*set_tsc_offset)(struct vcpu *v, uint64_t offset); void (*inject_event)(const struct x86_event *event); @@ -482,10 +482,9 @@ static inline void hvm_cpuid_policy_chan alternative_vcall(hvm_funcs.cpuid_policy_changed, v); } -static inline void hvm_set_tsc_offset(struct vcpu *v, uint64_t offset, - uint64_t at_tsc) +static inline void hvm_set_tsc_offset(struct vcpu *v, uint64_t offset) { - alternative_vcall(hvm_funcs.set_tsc_offset, v, offset, at_tsc); + alternative_vcall(hvm_funcs.set_tsc_offset, v, offset); } /* @@ -847,7 +846,7 @@ static inline void hvm_sync_pir_to_irr(s */ int hvm_guest_x86_mode(struct vcpu *v); void hvm_cpuid_policy_changed(struct vcpu *v); -void hvm_set_tsc_offset(struct vcpu *v, uint64_t offset, uint64_t at_tsc); +void hvm_set_tsc_offset(struct vcpu *v, uint64_t offset); /* End of prototype list */ --- a/xen/arch/x86/time.c +++ b/xen/arch/x86/time.c @@ -2985,8 +2985,7 @@ int tsc_set_info(struct domain *d, */ d->arch.hvm.sync_tsc = rdtsc(); hvm_set_tsc_offset(d->vcpu[0], - d->vcpu[0]->arch.hvm.cache_tsc_offset, - d->arch.hvm.sync_tsc); + d->vcpu[0]->arch.hvm.cache_tsc_offset); } } From xen-devel-bounces@lists.xenproject.org Tue Jan 06 14:19:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 14:19:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196227.1514085 (Exim 4.92) (envelope-from ) id 1vd7uR-0007BM-IJ; Tue, 06 Jan 2026 14:19:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196227.1514085; Tue, 06 Jan 2026 14:19:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd7uR-0007BF-FK; Tue, 06 Jan 2026 14:19:43 +0000 Received: by outflank-mailman (input) for mailman id 1196227; Tue, 06 Jan 2026 14:19: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 1vd7uQ-0007B4-80 for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 14:19:42 +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 bcf9b1b8-eb0a-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 15:19:40 +0100 (CET) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-b7a72874af1so195459066b.3 for ; Tue, 06 Jan 2026 06:19:40 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a27cac3sm239882266b.20.2026.01.06.06.19.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 06:19:38 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bcf9b1b8-eb0a-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767709180; x=1768313980; 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=yYMcvm2DTbFlTmVaCqRaa8/IZM6wMLkLwGv3atb4HpA=; b=C4h6N5XC3EiOORhzsVAxEuaTKtJeINve9C+tFHoEWQ/9PQt4FJcje1w9X6YYG6yKJY pPb9tySqMqFIbGA7811s5CzpKcxMIXpqehjnr1ZkopnntTz70zmLTOox0rC6DZbkOcqz pQW+g0lI/Q99m+c3VB72F9rjwXsMeSUNF/d4WNcpXLqrR1bvOc2v8gSt5T5ehZxdVhDG RLI2YNyU5483lifihTU6lkPC/FhCKtw7A5zlwq9qAIOSRssOXcxeFpEu/O+T5/ngxMXA t01jvQHjktC6oMZ+CG0jsgzWEdmg5KXhzigJYqHw/wfvl6GvmEG8GJfn+C8T4Y5aZ17F OpzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767709180; x=1768313980; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yYMcvm2DTbFlTmVaCqRaa8/IZM6wMLkLwGv3atb4HpA=; b=eq+kTMY4foWhflKdEU/9hFnhbMmzXbcdeioRuJyKClcMIrZbYzy0O2HjnbNRjtKzsk qkt9yruictvg3AeixTx/gLLaAoHlbR9tV00MrOaKk6thBryHe1MwkeE0J1/EIt0D2vah 2v5Xg0+pJTjxpKDyakGGJ16msqcB9ViqH+l8EzRUJ5LraTQ7c9Oc+G4IRbL5v4SsHpk/ AqUIURPMxbRmgsv6jPlZZyG22QZkXhwHMOqKZ9saYuoNd1g2W2HEbP4I+ARDWMZqs9Ur MgSwartCatHn+CNIe81H809Vln6L3chuecMhoA+jInme6XC694rJ2Wx0flTsprX+NViW O6Dg== X-Forwarded-Encrypted: i=1; AJvYcCWAhpgFJhhXTqARMyGnqP6byYDPD8j87AzIzQk8NP3a5pItoQILO9729C2A2JNjv5upK/Bv2+9eKSo=@lists.xenproject.org X-Gm-Message-State: AOJu0YzI3a6+sFHumU/BTXFMXGa6hpgDDXdQrd+MUN18axY1o1P9FXZg L3ADSmurQzUm1Zm/o+Iv3XBdXX40zJiFTrWFaXwRpfeIRZtP8c2tpD3i X-Gm-Gg: AY/fxX5SaO6ngt/xcJ+zBW8MshQbfYBMtsuh5gKHwgpKkJ4hQdQG+tKsFRmrMNkP0rj GPezCFo3Rv0qtYoLcqqy4JQ72MGZhJ+1WJsSm4EnvVd89vL4OKIPfGxS5nR8hKGwylcaAae6S4v V8LmhOSh/HO9naQ57MXI3JT27YcpjF1T6UidugsfG97p0beaKA/i+uMvkotxSyCysA1+O+4KLJ1 eA1VW/FyNgRa83+6RDmKfIgg2vL64pUy5MftD1HenE0mI1BpE5S6r6r3GDnsUuRMW/beBUM8aET Gr66u7dDxRs7bCkmo87vbWw9sfJ3ZDGyAqR3Fnb7+hFaPYqSTANGTZtumXachhwl9vdq0Lkj46S yYmsV0bu6G6/Hw6ICOFWc+tWXIpZLKVjlh0+Yf26nd+OrUEkMTKCMwKL4PmaKxuVLknU2TZZk3a u49vvFkB3emnFQomCAYf2Cq6+ykHlmCQPs4jykQXiqDkQqz+TklTJBPglml92/wXQ= X-Google-Smtp-Source: AGHT+IFx0bipXXXz+5Ry5eSLrud01hvIVvn1RQX0Nl5R1CkYinUPrBL9vdsc2VSeralaVRONvHvWcA== X-Received: by 2002:a17:907:944f:b0:b7f:e709:d447 with SMTP id a640c23a62f3a-b8426da94c0mr306214166b.33.1767709179178; Tue, 06 Jan 2026 06:19:39 -0800 (PST) Message-ID: <89629a0d-de6e-46e2-8517-a4b2fdd52183@gmail.com> Date: Tue, 6 Jan 2026 15:19:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 01/15] xen/riscv: introduce struct arch_vcpu 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: <3b531dff3755da010664111cf7d936ccba7c1f5d.1766595589.git.oleksii.kurochko@gmail.com> <41b7b388-6c10-4cbe-a4af-a25baba64e2a@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <41b7b388-6c10-4cbe-a4af-a25baba64e2a@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/5/26 5:58 PM, Jan Beulich wrote: > On 24.12.2025 18:03, Oleksii Kurochko wrote: >> Introduce structure with VCPU's registers which describes its state. >> >> Signed-off-by: Oleksii Kurochko > Since none of this is being used for the time being, I think the description > wants to be a little less terse. Coming from the x86 (rather then the Arm) > side, I find the arrangements irritating. And even when comparing to Arm, ... > >> --- a/xen/arch/riscv/include/asm/domain.h >> +++ b/xen/arch/riscv/include/asm/domain.h >> @@ -22,9 +22,63 @@ struct hvm_domain >> struct arch_vcpu_io { >> }; >> >> -struct arch_vcpu { >> +struct arch_vcpu >> +{ >> struct vcpu_vmid vmid; >> -}; >> + >> + /* Xen's state: Callee-saved registers and tp, gp, ra */ > ... I don't think the following structure describes "Xen's state". On Arm > it's guest controlled register values which are being saved afaict. I > would then expect the same to become the case for RISC-V. I think this is not fully correct, because guest-controlled registers on Arm are allocated on the stack [1][2]. Regarding|xen_saved_context| (or|saved_context| on Arm, which I used as a base), I think|xen_saved_context| is a slightly better name. Looking at how the |saved_context| structure is used on Arm [3], it can be concluded that |__context_switch()| switches only Xen’s internal context. What actually happens is that|__context_switch()| is called while running on the previous vCPU’s stack and returns on the next vCPU’s stack. Therefore, it is necessary to have the correct register values stored in the|saved_context| structure in order to continue Xen’s execution when it later returns to the previous stack. Probably I need to introduce|__context_switch()| in this patch series for RISC-V now; I hope this will clarify things better. At the moment, it looks like [4]. [1] https://elixir.bootlin.com/xen/v4.21.0/source/xen/arch/arm/include/asm/arm64/processor.h#L14 [2] https://elixir.bootlin.com/xen/v4.21.0/source/xen/arch/arm/domain.c#L547 [3] https://elixir.bootlin.com/xen/v4.21.0/source/xen/arch/arm/arm64/entry.S#L650 [4] https://gitlab.com/xen-project/people/olkur/xen/-/blob/riscv-next-upstreaming/xen/arch/riscv/entry.S?ref_type=heads#L153 > >> + struct >> + { >> + register_t s0; >> + register_t s1; >> + register_t s2; >> + register_t s3; >> + register_t s4; >> + register_t s5; >> + register_t s6; >> + register_t s7; >> + register_t s8; >> + register_t s9; >> + register_t s10; >> + register_t s11; >> + >> + register_t sp; >> + register_t gp; >> + >> + /* ra is used to jump to guest when creating new vcpu */ >> + register_t ra; >> + } xen_saved_context; > The xen_ prefix here also doesn't exist in Arm code. I think it should be added for Arm too. I can send a patch. > Nor is there a > similar, partly potentially misleading comment on "pc" there > comparable to the one that you added for "ra". ("Potentially > misleading" because what is being described is, aiui, not the only > and not even the main purpose of the field.) Yes, the purpose of|ra| here is not just to jump to the new vCPU code (|continue_new_vcpu()|). It is used that way only the first time; afterwards,|ra| will simply point to the next instruction after the call to|__context_switch()| in|context_switch()| [5]. [5] https://gitlab.com/xen-project/people/olkur/xen/-/blob/riscv-next-upstreaming/xen/arch/riscv/domain.c?ref_type=heads#L463 > >> + /* CSRs */ >> + register_t hstatus; >> + register_t hedeleg; >> + register_t hideleg; >> + register_t hvip; >> + register_t hip; >> + register_t hie; >> + register_t hgeie; >> + register_t henvcfg; >> + register_t hcounteren; >> + register_t htimedelta; >> + register_t htval; >> + register_t htinst; >> + register_t hstateen0; >> +#ifdef CONFIG_RISCV_32 >> + register_t henvcfgh; >> + register_t htimedeltah; >> +#endif >> + >> + /* VCSRs */ >> + register_t vsstatus; >> + register_t vsip; >> + register_t vsie; >> + register_t vstvec; >> + register_t vsscratch; >> + register_t vscause; >> + register_t vstval; >> + register_t vsatp; >> + register_t vsepc; >> +} __cacheline_aligned; > Why this attribute? As arch_vcpu structure is accessed pretty often I thought it would be nice to have it cache-aligned so some accesses would be faster and something like false sharing won't happen. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Jan 06 14:27:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 14:27:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196240.1514110 (Exim 4.92) (envelope-from ) id 1vd81W-0000Yb-CR; Tue, 06 Jan 2026 14:27:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196240.1514110; Tue, 06 Jan 2026 14:27:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd81W-0000YU-9w; Tue, 06 Jan 2026 14:27:02 +0000 Received: by outflank-mailman (input) for mailman id 1196240; Tue, 06 Jan 2026 14:27:01 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd81V-0000YO-8A for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 14:27:01 +0000 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [2a00:1450:4864:20::333]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c30e81a5-eb0b-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 15:26:59 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-4779cb0a33fso11652865e9.0 for ; Tue, 06 Jan 2026 06:26:59 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7fb4c451sm20761295e9.5.2026.01.06.06.26.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 06:26:58 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c30e81a5-eb0b-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767709619; x=1768314419; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=XBhMQhGjjHpc1gSwBSjL22wDqF6Zt+gMzS49c7NEUgI=; b=fOomjP4xsfgWtSad+/KbgBdOKnkMlUm1co3JLqFtqrHEqH7By1AKvwdFDbo9vWSUTJ 1RQ9nT/Ui+CGGCZxW/7xjrJLxrX0uPMpI6U/9WIzn/TtygL8dMqu3V5c3o+mcuiJQLHs Y4SdzLsbqREBjwe8SDkm2Whc6U9IdjFzc7rcaRJ21GIPrf78SCKlKqB7j1b21hQxLqHl UsjUTbePYJDynjOR9ZiHhUovazHpNIhKUbjE3zFFSK7G/e2XqsDMZ7Xespru6g99G99N vWeTKG/ascm8jm3wGiWVtf1QsJ5wfKINlMyTxsdUbtdWPfXq1oSEMDncT927rzI0Wz1p SxWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767709619; x=1768314419; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=XBhMQhGjjHpc1gSwBSjL22wDqF6Zt+gMzS49c7NEUgI=; b=rqfFlbd9GoaPXpqX1+dJf+jaYkPKlPNW4sRfF1cEMsFYi4QVToj/ZUIJFMBBHMsU8l 6VAf47PYUpA5C6fjFr9BEq/2+Q3dpQuZBLWIngFjq4QIkEv5F8nI9YMtlBv+VLrq3X6e Q1DDuOr67HuipQTRdJkb3yTfWSXixeCcpNpk+VR/rvpQ87TqOHAI6Z/B42fsN/Z9A+Eg 1bg6PZqa+tfAG5tY5fmK8bHq0repWE84uVEHyKSwaHHvKe/nOMcXPR5agpcS9AVS+c9E IWAoK0cftqLAXlcf4UAPWrfmV3k1+TXB8RkL+9UH8rlXZ1pLh3fVUXE/XU8KHW700+m8 AS3Q== X-Forwarded-Encrypted: i=1; AJvYcCWMIYi+IXzpWDtAcoW0DNLRS9YGhBdtEwvBYMwsOAJ6ppf5HnMB20aasB9g8ZAnlkG1yrhVM01ijiY=@lists.xenproject.org X-Gm-Message-State: AOJu0Yze98B5M8MY4S0HOjZU8Roy4nFQCKER8+p1re399iv4ADMXfp+n /SwnDjWUy2Cb+nF/cmwXVQl1LfQB7nGQ08pkUQN103O6+kk3d+57EmTjokdpJhTRrA== X-Gm-Gg: AY/fxX524wfgsKNpqlN2j+WqQWqPIURLEfQ0cIuxOG1LJYzZysL+ZjQZma+OiEb7+lY 2C67UC5YXpJh95Gyopdi0st6TuXtrwwGYABO3ahfAWqH4fxfX4tL0FnKRCPRqNHqm147oPEUC9y PzC9pykL/yf0WAKA+B7khVG4WV5wL8WpSViKBsArZ2zomb/NXwGviqB5KSkrvQa+RZ2sQAct0Pf EjhX1l4MjByMyBO0MOaA8o+znGBYUK5uD0Tm8jcZ2313cnrzl6wPN/MXTZTORNwqe3dCTHuVzOv v60x/fOtus8JuVKoMIOLzg8tEzZvd8MX4iXtuWQeyXvt4AKYcfceRX0wAKEw7W5l3woWJjHk8I6 Xj+1tZNOw1S70xHMWkf3url2wm8HxvAjhaSZm044GetQmygBtAWhRykeYtqSO3h92fLc3tSbZ4H 9M4/oK7nFihY1x34I0uLtPYc+nZgDIaOkRnSWJUYYbSoJed6FeR5imhk/7tYxsRgQIMEGkILpTq r8= X-Google-Smtp-Source: AGHT+IFeruKI6obClXDY0ylLJ/PyJv1B+rtSUo6HuhDyw9oohvpIgH5yNzEwilzDTvoaG2aHONUrTg== X-Received: by 2002:a05:600c:8485:b0:479:1ac2:f9b8 with SMTP id 5b1f17b1804b1-47d7f0975e8mr38719265e9.21.1767709619292; Tue, 06 Jan 2026 06:26:59 -0800 (PST) Message-ID: <2253f28f-07af-46db-9116-e9b5427953a9@suse.com> Date: Tue, 6 Jan 2026 15:26:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 01/15] xen/riscv: introduce struct arch_vcpu 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: <3b531dff3755da010664111cf7d936ccba7c1f5d.1766595589.git.oleksii.kurochko@gmail.com> <41b7b388-6c10-4cbe-a4af-a25baba64e2a@suse.com> <89629a0d-de6e-46e2-8517-a4b2fdd52183@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: <89629a0d-de6e-46e2-8517-a4b2fdd52183@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06.01.2026 15:19, Oleksii Kurochko wrote: > On 1/5/26 5:58 PM, Jan Beulich wrote: >> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>> Introduce structure with VCPU's registers which describes its state. >>> >>> Signed-off-by: Oleksii Kurochko >> Since none of this is being used for the time being, I think the description >> wants to be a little less terse. Coming from the x86 (rather then the Arm) >> side, I find the arrangements irritating. And even when comparing to Arm, ... >> >>> --- a/xen/arch/riscv/include/asm/domain.h >>> +++ b/xen/arch/riscv/include/asm/domain.h >>> @@ -22,9 +22,63 @@ struct hvm_domain >>> struct arch_vcpu_io { >>> }; >>> >>> -struct arch_vcpu { >>> +struct arch_vcpu >>> +{ >>> struct vcpu_vmid vmid; >>> -}; >>> + >>> + /* Xen's state: Callee-saved registers and tp, gp, ra */ >> ... I don't think the following structure describes "Xen's state". On Arm >> it's guest controlled register values which are being saved afaict. I >> would then expect the same to become the case for RISC-V. > > I think this is not fully correct, because guest-controlled registers on > Arm are allocated on the stack [1][2]. I'll admit that I should have said "possibly guest-controlled". Callee- saved registers may or may not be used in functions, and if one isn't used throughout the call-stack reaching __context_switch(), it would still hold whatever the guest had put there. > Regarding|xen_saved_context| (or|saved_context| on Arm, which I used as a base), > I think|xen_saved_context| is a slightly better name. Looking at how the > |saved_context| structure is used on Arm [3], it can be concluded that > |__context_switch()| switches only Xen’s internal context. What actually happens is > that|__context_switch()| is called while running on the previous vCPU’s stack > and returns on the next vCPU’s stack. Therefore, it is necessary to have > the correct register values stored in the|saved_context| structure in order > to continue Xen’s execution when it later returns to the previous stack. For this and ... > Probably I need to introduce|__context_switch()| in this patch series for RISC-V > now; I hope this will clarify things better. At the moment, it looks like [4]. > > [1] https://elixir.bootlin.com/xen/v4.21.0/source/xen/arch/arm/include/asm/arm64/processor.h#L14 > [2] https://elixir.bootlin.com/xen/v4.21.0/source/xen/arch/arm/domain.c#L547 > > [3] https://elixir.bootlin.com/xen/v4.21.0/source/xen/arch/arm/arm64/entry.S#L650 > > [4] https://gitlab.com/xen-project/people/olkur/xen/-/blob/riscv-next-upstreaming/xen/arch/riscv/entry.S?ref_type=heads#L153 > >> >>> + struct >>> + { >>> + register_t s0; >>> + register_t s1; >>> + register_t s2; >>> + register_t s3; >>> + register_t s4; >>> + register_t s5; >>> + register_t s6; >>> + register_t s7; >>> + register_t s8; >>> + register_t s9; >>> + register_t s10; >>> + register_t s11; >>> + >>> + register_t sp; >>> + register_t gp; >>> + >>> + /* ra is used to jump to guest when creating new vcpu */ >>> + register_t ra; >>> + } xen_saved_context; >> The xen_ prefix here also doesn't exist in Arm code. > > I think it should be added for Arm too. I can send a patch. ... this, to reword my comment: What value does the xen_ prefix add? >> Nor is there a >> similar, partly potentially misleading comment on "pc" there >> comparable to the one that you added for "ra". ("Potentially >> misleading" because what is being described is, aiui, not the only >> and not even the main purpose of the field.) > > Yes, the purpose of|ra| here is not just to jump to the new vCPU code > (|continue_new_vcpu()|). It is used that way only the first time; > afterwards,|ra| will simply point to the next instruction after the > call to|__context_switch()| in|context_switch()| [5]. > > [5] https://gitlab.com/xen-project/people/olkur/xen/-/blob/riscv-next-upstreaming/xen/arch/riscv/domain.c?ref_type=heads#L463 > >> >>> + /* CSRs */ >>> + register_t hstatus; >>> + register_t hedeleg; >>> + register_t hideleg; >>> + register_t hvip; >>> + register_t hip; >>> + register_t hie; >>> + register_t hgeie; >>> + register_t henvcfg; >>> + register_t hcounteren; >>> + register_t htimedelta; >>> + register_t htval; >>> + register_t htinst; >>> + register_t hstateen0; >>> +#ifdef CONFIG_RISCV_32 >>> + register_t henvcfgh; >>> + register_t htimedeltah; >>> +#endif >>> + >>> + /* VCSRs */ >>> + register_t vsstatus; >>> + register_t vsip; >>> + register_t vsie; >>> + register_t vstvec; >>> + register_t vsscratch; >>> + register_t vscause; >>> + register_t vstval; >>> + register_t vsatp; >>> + register_t vsepc; >>> +} __cacheline_aligned; >> Why this attribute? > > As arch_vcpu structure is accessed pretty often I thought it would > be nice to have it cache-aligned so some accesses would be faster > and something like false sharing won't happen. I think you would want to prove that this actually makes a difference. I notice Arm has such an attribute (and maybe indeed you merely copied it), but x86 doesn't. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 06 15:00:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 15:00:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196250.1514121 (Exim 4.92) (envelope-from ) id 1vd8Xb-00068Y-L1; Tue, 06 Jan 2026 15:00:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196250.1514121; Tue, 06 Jan 2026 15: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 1vd8Xb-00068R-Hz; Tue, 06 Jan 2026 15:00:11 +0000 Received: by outflank-mailman (input) for mailman id 1196250; Tue, 06 Jan 2026 15:00:10 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd8Xa-00068L-Ey for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 15:00:10 +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 6303c89f-eb10-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 16:00:07 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA3PR03MB7346.namprd03.prod.outlook.com (2603:10b6:806:382::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9456.14; Tue, 6 Jan 2026 15:00:03 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9478.005; Tue, 6 Jan 2026 15:00: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: 6303c89f-eb10-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=LlCkHsDCZ1gA4YlawX/vvNFoAsFdU98LfmFd2oMX1uLZR1s1hu/DouR4xan8E863aWR0eWZgUxy7cUoG9jSeTIThxsMX4NblOEKc+maWD7TBi2Y7APPAbQaRaXRmPfTbACSmd0EPILvlKS3INMaej35oy04oUIbHZplHHYGbqF8NmZ7QJaUmxVOtRB66Zq4CdKueZ/OM0arvgV766hBXCGYAmPP2+hFZt14j6JV6vHKvBqX1pTzcoPobagtyjYqcc0v3zSnm1ZkQj8Athe4Ijmgi+aLgLhcO9nlV0rJ17ikmKMH9zjZy+DGgX0/u6rlDGfv4RsWwnYEGXWM8SF/UFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FZfdYqZJGarK96C9DX+uTvdfguavdEJn0EYcuxDnZBo=; b=OvbEZIATjJOeXB1Eio5hAWiECjO7VZhawUO9eSi0B3rmFsScwdWX2Zh82fr1T8oaqENzrcLxghT2uuYxWUcBCaj6APizdADz2T/WCbutg9arwjmSHq3e8ZgNp6wioGWwkx2O3WAWggJksJVVXY6Dd+tuhNxQokoDlBFmwgZrlaGuBOqqhj8Pfi+uoY3z4CdTW43KxYP7atsTgEzrbNvSqkGiBCmVP3YDMDyPqW3C2xMs2FiQIg6XJZ88vfC6lxTRRapsW9qevG9lln5vR+ddAL72plt5j9ae/doVgO/Tw6GjmrUP2Na6IcV6wADL2u5+u+0lnCxNdPTPDtpBmD9zjQ== 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=FZfdYqZJGarK96C9DX+uTvdfguavdEJn0EYcuxDnZBo=; b=wQgOwNl/calrlcjfkHr+uC497mC3zzRfpF8Nkrmn11pFcIN4DrwGxgWDQ+XCYIXDYNfWdg2gfmftDRQq3a6Kdo8HSRys/qV8hQFzl7FHCMybBfbh+CUG1MrlNJfZ9KP5+yYATtIze2IX5fcPWxov/Fm+9b5tJOFJKJX0xjQLkFE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <0d3aed3a-a32a-4234-b8db-ab1181a86afc@citrix.com> Date: Tue, 6 Jan 2026 14:59:59 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Alistair Francis , Bob Eshleman , Connor Davis , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH v1 01/15] xen/riscv: introduce struct arch_vcpu To: Jan Beulich , Oleksii Kurochko References: <3b531dff3755da010664111cf7d936ccba7c1f5d.1766595589.git.oleksii.kurochko@gmail.com> <41b7b388-6c10-4cbe-a4af-a25baba64e2a@suse.com> <89629a0d-de6e-46e2-8517-a4b2fdd52183@gmail.com> <2253f28f-07af-46db-9116-e9b5427953a9@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <2253f28f-07af-46db-9116-e9b5427953a9@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0019.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2ae::21) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA3PR03MB7346:EE_ X-MS-Office365-Filtering-Correlation-Id: 72b40d46-a470-47c0-1049-08de4d344550 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?akZvOVBFOU8vK3N3aitodmJFSFNzT3Y4TFNJSzVCVDdiYmxLSEV1ZWx1dXQr?= =?utf-8?B?dytoRjBZcGMwU3FjY3lxakhtTDB0UVZjOEZQMWhGS1lnSy9KaW5iZVFpdEtU?= =?utf-8?B?elRoMlR4MmlHOHl6WGkwUmxaVnJoUFVLMFU4d2V4V2Qwc1J5RmdGZk9nWDhH?= =?utf-8?B?aUdrajBIOEkwNnFXVE5vSlBrNGNqeFQxZm91Vmt6OXJQQ0dlNEtoUHl1RjJS?= =?utf-8?B?SFhpQ2J2Vk1IbWxrRGpXbmZIV2YyM21vNSttY1hMekczeEIvTi9GOHRlS0ky?= =?utf-8?B?ZVZUVUFpOVFGNk9nUUNFQXRkMHZ2TmZSN0JvckpEUVhkMC83eW56MGVOZU0x?= =?utf-8?B?Uy95MGZhMTBaSjh6cFVDRW1tRU9wOGdKMHAweE9oNENUSVpoMWdQdURPY3N4?= =?utf-8?B?cnRBSjduU0FIdTl3NndmbzhuWm1pUVo0cUFsdXkrNCsvRUFmY1Zoc3UwK1F4?= =?utf-8?B?T21wK0VjL3JLS3pzNGVwZGRSS0FFbm5QbUtoY3FURzJUOC95eHp0eVVnd2FN?= =?utf-8?B?Ym12R1YwR3JBeXcwd1REelRvUGdQa3ZweUhVM09yN1hmZWZzczZSWmthSHNS?= =?utf-8?B?NTZkMHRpUW1IRTBVKzN4N2NrNTRMN2dtYk1yNERwNERSU3oyVHFRUmRuZWJT?= =?utf-8?B?YTNMd2ZyZ0d6djhpNWhUQU9aMUxucGV3Qk1qTEZLZCsyTmJPZ0RGREE3eStn?= =?utf-8?B?cEh4bk1COXpoYkV6enMwd0dxNmNTME41dmJlUkR6ZC9JbGNPYWQrSmZNNk1M?= =?utf-8?B?U2R0OVhwYU4xdlpwMTk4K3Z4NnJxZXovaWp2MTZmcTVCbjlEQ2s2bTVQUDF3?= =?utf-8?B?K1dFMXNXTC9KWUhaUklwQUtockUraFUvaThvMFpzQmJ4eVBSekhrVDhUZ2dt?= =?utf-8?B?dmQzOXh1TURtNVBadXBYTG5vQUIzUno2T2doZDR2aG9KbnZUQjhwZ1N2OUNK?= =?utf-8?B?clpvMXhJc2ZNOW1FbEFSUDh0cVpEZ3ZwRUE4bWRJNDJBZG9xOU1BaGVmbG5N?= =?utf-8?B?S1hKc0I0NFV4cWQ3dzdyTFo3M3VzQW9HSUFubjdhOS9ZZWZmWWRmNGlQekVs?= =?utf-8?B?UVAvMGM3WmRsUlVUbXNicWNxOGxWSWl5NElMRllmME5UcCsvcjJTRWN5QjdS?= =?utf-8?B?QWE1NW1PSkVodjAxSG5pVXBYUlJQTDFkK0tkWm5DUFJWYS9JczFuR0tjSnl1?= =?utf-8?B?MC9sbmZTb1dkTTlUZy85eG5WVjM3bWxFOVpBUFVaS0x1cUFGRFZBT3k1cGhB?= =?utf-8?B?TzliQWRPMnpuMDRBUEFWQ2psakNnZDZ1MksrNG5McmxGYXkwVlFpUm5OZ1NQ?= =?utf-8?B?cUFFaXowdjcvYUNtSXpYME4yR0dCR001VU53a1o4SlpnVTFOUHdhanhuK1dy?= =?utf-8?B?RWtzazgyakpNdE11QjdQRVZkM0FWTU55ZE4yZjMrTDdmR2s2Q2kxLzY4MXNW?= =?utf-8?B?RUptUmNzL2pycmllWHRyYkJwUXVPSXhSNEE3SVlaaWxXMmFZbVNZZkxlbW1P?= =?utf-8?B?b3RlUmdFTG9FejdON1M2UzhQZmgyWktvNGtJdjg3VEtzQ1czMjhKa1dUNm9x?= =?utf-8?B?UEFadWcxeUg1M1J5cmZBcFYyN2FCdzNqZDZRQVd5ZUJUZEZ1L0oyOGNqNHEz?= =?utf-8?B?Vk5GS2xRNVp5YW0rSW93WmIxRENjdnZEQktpS2hrUmdpL1cxUXdKYlJrak94?= =?utf-8?B?R1EvWXZ1VTJ3WndYaVJ2QTUweWljY1ZITEFYZThUMTBZUWJGN0JTNE5mNThz?= =?utf-8?B?R0pySjBoekU4SmNqclJpZkRDdVVzRGZ3RDYwZU04bXZrdHdsbUhQdUdDUE9a?= =?utf-8?B?Qm8vV251bHNUT2oxSC9sNVRTUmQxd3ZqTm5NR0tJMFhYQXl1amRCM2RJWkVr?= =?utf-8?B?RWZ1Y244RVo4a3ZEQ0M2UWhkb3J5eHBwNm1WR1JyYm1vK01JZHA3a2RJd2lH?= =?utf-8?Q?X4CbKyqTWdSf1SB68LDjtDC87MJfiktm?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?V1Z6MWNQSWhUZFdIT0VlTlNMTzVjUVU0OVB6b0ZEWnp3b21rOWI0TWV5cFZE?= =?utf-8?B?RlRNU0hVSEhrYWVucVdWK1NaVXh3T3YvUFc0cEt2VC9RcTVZdzkwRklxU1RV?= =?utf-8?B?Ungva3BuU2NkeFFaeVFDa0pWaWMxenhYbGJBMTkrYklYTHEvdkV3SWtFNGcz?= =?utf-8?B?SVVuMmxyRm1TS2t3bGZpK1V5dWVhRm5DYVgraGc1VGZMQU96clRzSHMyRkZY?= =?utf-8?B?ZDVKYVJWU0lVdGEySCtWZGU5YWp4T1RTZGk0U0dIekR1VVZ4ZnhJMWpISEhH?= =?utf-8?B?Q1VtaWZEdWl0aVBYNm5uM3gyTGhGN1VwaURzTXRVWG82VHQ2WUsxZE52Q3BH?= =?utf-8?B?V2pGVnErQm9jdDd6QVh5WG4vNjY4anFhNDNiRXZpbnhGQUc4VmtCaHlraVE2?= =?utf-8?B?cHhBWm1aRmpQWkMxOXh5bkxJRWFiYno3Ync0TUczSHhPUlFVNUpYbndYS3l4?= =?utf-8?B?bzdsVFZBd2srTEh1emFRSEVyVjlVSFJBSys2MnpWTjA4SHhKcUtsYkxFR05S?= =?utf-8?B?ZTVPUmdNQ1NxcXNiLzVvWnlKc0t5K3hnSXhQZW5Ob3lqbEtYYnZLSGQ2cnhP?= =?utf-8?B?RWV5NVNZemZudFhLMWFpYWFEbFlqMzhPT3Q4ZTEvcFdkNmxxTkpIbVgrRUFS?= =?utf-8?B?NjlwYnJvVjZLUTlkNmRHQWk3NmVCd1c2eE1wa2JMUGJ1VlBtMGpEazlKeGNS?= =?utf-8?B?LzhDVDk4ajdNOTJQMkZzQmxLN3FNNTBVSXpabVNtU0xDazd5TkRrbU1Kd2pQ?= =?utf-8?B?MlM4TG02MHZhY0poNHRKaU1ZeFRENkw3azNQaGY0cTR0MUdsbGdVL3dyODhL?= =?utf-8?B?b0R4cFJHNlFKRTFHbzJ2eERjOXhNakNzdXFrVUhGMVhmblJUYU1KVnBSb2w1?= =?utf-8?B?alY1S3dqYndqd2o4RzJFNHR2R3FQSFF5MVpoQ0dpRmRQU1Zxc2p0d0NiRi9W?= =?utf-8?B?dy85Zy8ySUFtZWk4KzdNQitlM0RtQWJiRG4rajFuTDVyY3h2U2ltcXhEeDd2?= =?utf-8?B?bFR1YmliYVdPbmJzWUNNWTBRUXJHdEdxRmZlOEcyejYwUEQ2SXgzTXBGalRT?= =?utf-8?B?d0pkZThZNG03NU1lenIxV3VVSS9YZW1GVEYwY1RjY3pLdUQxRG5HWmV3WjUv?= =?utf-8?B?ZUExTlVRSHgya2dQZG1NRW85MDJlcnR0UG5EYXozdFhKRGlpc041M3RydVFv?= =?utf-8?B?WFpzTVV4ZmZNSmxBMDdSZmNFMnpocHhVMlVpSk9EY2UzcE9Ia0gvbEg2NXk2?= =?utf-8?B?S2ppdXRSeHUra1lRdG9Sd1d6emNVNnpDa2N6TDRwOXhUSmJFTndrcXplb0lw?= =?utf-8?B?OHkrSnlNazRxRTBpbmZkSTVMVG4rSW1EbENoandHczBzalBpYXV5cVQ1cDZI?= =?utf-8?B?REhoSkpKSGhTZXNoTWw2emFrZm1zelJmTFBsRCtFSFRnS1lFSm9iYVgweDMx?= =?utf-8?B?WXgvRkhjVWpEYVBvakRqNVQ3NG9jMk9iaDdENkNnM0QrY1c2ZHkreHg4VXg1?= =?utf-8?B?WkRTejgrWGl4TmZQY2MvRGtodWF1TkI1bDF4bDZ6emtzMUZRTXZnMlQyT0hH?= =?utf-8?B?OWR0MmhHVFRPYkU3TEhlc3ZOcHVnRnBueXFZM2JjdDhrT1R0TXJ5bHhDWnNM?= =?utf-8?B?MFltWXhGczJ3OFhYWWU4T0pjL24rRVZOSUx4aE5KS09XY3BJamt1UlpkanhZ?= =?utf-8?B?SjdTVHJ5WVdzMmhEMnVSQjZDV3lBRk5VdmNmaEh5OWNXdEQrRlR5WGo0SmQ2?= =?utf-8?B?MzRYRFRscStVRHowSmxTdkx3blUwb1d5YWEvQ05kREx4TmIvcmxqUVdYT1dT?= =?utf-8?B?dU9xeGVVQWxEQzlid25xSHFyUE1SSWpjT3NaYy9abEhkdXMxTlB2ZW93RVRY?= =?utf-8?B?T0V4UktXdnZZaU1YWENjTDliWkx2VnpBYWEvSzg4MG5LZU9mbVU2alBPbVg2?= =?utf-8?B?T25TUXZ5S1RGeU91YjN0dldzbno0LzJlYS9SZ2JZd0pQaktMQ3ljOVFZeUNs?= =?utf-8?B?L1E5UVBaNm9mZUhVaEhYM1gwRkJoMEFnaEFUUmxPMHJyNkV0YkRiUXlrdWEz?= =?utf-8?B?NW5vWVdldnIrMXpKTnk5ZFFNYXlKMHBjRjVQZ3NlSHRQYnkydTdqT3kwYml0?= =?utf-8?B?RnlRaUFpNUNhYk83M1RtTzZsbU5SL054bk4rQis5MkJwREFnMlVGc1oweHJ0?= =?utf-8?B?VkZ2RHlxYXRZVndDQ3l4MmxGRTMrM2hRdElSUEM5dzR5OVlUWjNpS092ZmpD?= =?utf-8?B?N21NMFFrK0grTForM1Frby9RRmdQNjhQeG5sY2pQZ24vV3BGUkQyc3BFa1Iz?= =?utf-8?B?ZkRmckVIUzIyRU5xRTJBMjZPY00zcHJ4THBKS2Z5NU1DeFVwSWdGQ2txL0xm?= =?utf-8?Q?0/sM5uBP1io1kzIg=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 72b40d46-a470-47c0-1049-08de4d344550 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2026 15:00:03.0461 (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: Ajw4gVt+XYRSqTUioDQYLeq2SJWEwdeWOXazODWjJYVrztqyuu5p5e8Krz70BH/zXHVBvacne3H20+bTi8uqNzJhZfQlP0xNv2YdtAtmBn0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR03MB7346 On 06/01/2026 2:26 pm, Jan Beulich wrote: > On 06.01.2026 15:19, Oleksii Kurochko wrote: >>>> + struct >>>> + { >>>> + register_t s0; >>>> + register_t s1; >>>> + register_t s2; >>>> + register_t s3; >>>> + register_t s4; >>>> + register_t s5; >>>> + register_t s6; >>>> + register_t s7; >>>> + register_t s8; >>>> + register_t s9; >>>> + register_t s10; >>>> + register_t s11; >>>> + >>>> + register_t sp; >>>> + register_t gp; >>>> + >>>> + /* ra is used to jump to guest when creating new vcpu */ >>>> + register_t ra; >>>> + } xen_saved_context; >>> The xen_ prefix here also doesn't exist in Arm code. >> I think it should be added for Arm too. I can send a patch. > ... this, to reword my comment: What value does the xen_ prefix add? This was my recommendation after reverse engineering how ARM worked to explain it to Oleksii.  But I also thought I said to write a real comment too. This is arbitrary *Xen* state, not guest state like you'd expect to find in struct vcpu.  The guest GPR state is at the base of the vCPU stack. I suggested that this property be made clearer for the benefit of anyone trying to decipher the context switching logic. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 06 15:05:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 15:05:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196264.1514132 (Exim 4.92) (envelope-from ) id 1vd8cs-0006lD-Bh; Tue, 06 Jan 2026 15:05:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196264.1514132; Tue, 06 Jan 2026 15:05: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 1vd8cs-0006l6-77; Tue, 06 Jan 2026 15:05:38 +0000 Received: by outflank-mailman (input) for mailman id 1196264; Tue, 06 Jan 2026 15:05: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 1vd8cq-0006l0-4d for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 15:05:36 +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 26f0a724-eb11-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 16:05:35 +0100 (CET) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-b79f8f7ea43so218921866b.2 for ; Tue, 06 Jan 2026 07:05:35 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a2338cbsm245955266b.14.2026.01.06.07.05.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 07:05:33 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 26f0a724-eb11-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767711934; x=1768316734; 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=GNJ13SsOIzHp4IQ6BEQpZefQKZX3cYAvERa/uKn8OKo=; b=bGgzn+JrFR74n89yK9jo0QCsnWPXS8T5YjGutBq+QRr9AWS65qSqfCpGNtN4q4m/WP AGcKiGcBB5x93P28OthqpNA43+/qIi6aZrH1SbzZItwgHVefxwbET5KvYvAs+8Uy5X36 I+HckOQkB4WQZOL/igsqc9w1CBBc5Dq+/u2gwK8ORUYqLERDo7EAEWAkoPCRRMO/otyG 81guLGx3rgDTt57pNNzziHvCh5DPHUz+/gnWpcPh8tsWBVVPjBFPB5dk0Zgqj6RyE3Zs p7vYJTe1t1d3QomF7OaJyUPgri7L3b9qbDgq/wkgfwXT4Y1mvyhwEIotRmLQseo9ygtq ZsZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767711934; x=1768316734; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GNJ13SsOIzHp4IQ6BEQpZefQKZX3cYAvERa/uKn8OKo=; b=aJ/S7duWVyWmhbUIV/wzOBIJ+enm6qST/EJeUrf1TUfy1Wy3RwRHSQOsKw3iOjsirt DSuk4qX0yOIznOFgXEncOvVpPu5IdvpnJs+cR932nyhEBRbUrjDipavU/dJ6pIqud/6V kbaVbkf7NjlGs6SyP3lNneW64qGvokVIuVVemdARP5OjSGGYASVgNihci5pfAUnviKvM LunJzUmF7MDF8LSTTA+GW8jrpQqStDczokM5BiXc3Zefc1+oL4/e2Lnrh6mX8LKpOShE dm6mm6dpY9grurE4GU1aCQsAt2SWvILPeYD05Z5XKLVx+orXfCYsuL4lmpdvYsaNMUvr O+/g== X-Forwarded-Encrypted: i=1; AJvYcCXxyLpZdLISScQqC1GVo4zX+YooK6/D3AAuBKXU3Zu0uECKY9rIBBGpNvOkJzvm8KHxqTKXnKLnjIo=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxqydur47YXC75Y5exHfwckCWSw0qJ3flXAh8ZNmctzhh0uoPnr x52Hnr7AkgkSxtRaO5CCVXCYzEIzmLSazmqknLCoW5Hc14h+fDeRMbPa X-Gm-Gg: AY/fxX7rbTl+eA6hFH0XZiXHAboD73fItZ37akv5ES9vlpe/9nQUde1G/AEpbiHadlp ZcOokwfwNg0V0CJlppCs5Kq1gh6axRPnQaACxLjf7fywJlylgKJrGW8yfKgk97+W+j6MBNDM8ze FruaUJU8XOwCf2LXI4rS3s/vQRmD5cZBkEH5KWyjp0nRJQT8pnasJ33w1jBIxuBHec31DqmDMZf P20ZBf7Flupy1ai41ddp7VLD9B6NztNx9M/ct0J1NppZVKW4aW88e0emFtTs087pEW20+ENH1tN /f7CzsSK+q1NC0rNwtSGWiBNqLPAmzrkFo+xxeNUcV3lNAfn/7Qq3Pjf1Jm+Zg9lzFEQz/UVeZp MvM0U0Yrtqmh36kIYnN9Zr10UCVDZM0Nlypt2DMgK0xueEj/dT+/2LjojyTfQtxtRyP6emn9PQV KlNcbsM9V2VuuiuYuEs5h4BqVRYzDptWI+eDeP/FNXs+U6iXML7E7MhQM+ISVk+Bs= X-Google-Smtp-Source: AGHT+IGYK+WEoPRAHxOHnIIb0CLeLLcg3Iy48zqa02RkIG3yyrBgQUm8cFy9189dwJHSQag4jpBTAg== X-Received: by 2002:a17:907:989:b0:b83:972a:cb85 with SMTP id a640c23a62f3a-b8426a684e8mr370184466b.21.1767711934020; Tue, 06 Jan 2026 07:05:34 -0800 (PST) Message-ID: <839c06a2-dbd2-44c5-abe6-905a1f3ffefd@gmail.com> Date: Tue, 6 Jan 2026 16:05:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 01/15] xen/riscv: introduce struct arch_vcpu 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: <3b531dff3755da010664111cf7d936ccba7c1f5d.1766595589.git.oleksii.kurochko@gmail.com> <41b7b388-6c10-4cbe-a4af-a25baba64e2a@suse.com> <89629a0d-de6e-46e2-8517-a4b2fdd52183@gmail.com> <2253f28f-07af-46db-9116-e9b5427953a9@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <2253f28f-07af-46db-9116-e9b5427953a9@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/6/26 3:26 PM, Jan Beulich wrote: > On 06.01.2026 15:19, Oleksii Kurochko wrote: >> On 1/5/26 5:58 PM, Jan Beulich wrote: >>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>> Introduce structure with VCPU's registers which describes its state. >>>> >>>> Signed-off-by: Oleksii Kurochko >>> Since none of this is being used for the time being, I think the description >>> wants to be a little less terse. Coming from the x86 (rather then the Arm) >>> side, I find the arrangements irritating. And even when comparing to Arm, ... >>> >>>> --- a/xen/arch/riscv/include/asm/domain.h >>>> +++ b/xen/arch/riscv/include/asm/domain.h >>>> @@ -22,9 +22,63 @@ struct hvm_domain >>>> struct arch_vcpu_io { >>>> }; >>>> >>>> -struct arch_vcpu { >>>> +struct arch_vcpu >>>> +{ >>>> struct vcpu_vmid vmid; >>>> -}; >>>> + >>>> + /* Xen's state: Callee-saved registers and tp, gp, ra */ >>> ... I don't think the following structure describes "Xen's state". On Arm >>> it's guest controlled register values which are being saved afaict. I >>> would then expect the same to become the case for RISC-V. >> I think this is not fully correct, because guest-controlled registers on >> Arm are allocated on the stack [1][2]. > I'll admit that I should have said "possibly guest-controlled". Callee- > saved registers may or may not be used in functions, and if one isn't > used throughout the call-stack reaching __context_switch(), it would > still hold whatever the guest had put there. But the guest doesn't put there nothing, only Xen does that and it is a reason why I am trying to call it Xen state. Guest works only with what is stored in struct cpu_info->guest_cpu_user_regs.* ... > >> Regarding|xen_saved_context| (or|saved_context| on Arm, which I used as a base), >> I think|xen_saved_context| is a slightly better name. Looking at how the >> |saved_context| structure is used on Arm [3], it can be concluded that >> |__context_switch()| switches only Xen’s internal context. What actually happens is >> that|__context_switch()| is called while running on the previous vCPU’s stack >> and returns on the next vCPU’s stack. Therefore, it is necessary to have >> the correct register values stored in the|saved_context| structure in order >> to continue Xen’s execution when it later returns to the previous stack. > For this and ... > >> Probably I need to introduce|__context_switch()| in this patch series for RISC-V >> now; I hope this will clarify things better. At the moment, it looks like [4]. >> >> [1] https://elixir.bootlin.com/xen/v4.21.0/source/xen/arch/arm/include/asm/arm64/processor.h#L14 >> [2] https://elixir.bootlin.com/xen/v4.21.0/source/xen/arch/arm/domain.c#L547 >> >> [3] https://elixir.bootlin.com/xen/v4.21.0/source/xen/arch/arm/arm64/entry.S#L650 >> >> [4] https://gitlab.com/xen-project/people/olkur/xen/-/blob/riscv-next-upstreaming/xen/arch/riscv/entry.S?ref_type=heads#L153 >> >>>> + struct >>>> + { >>>> + register_t s0; >>>> + register_t s1; >>>> + register_t s2; >>>> + register_t s3; >>>> + register_t s4; >>>> + register_t s5; >>>> + register_t s6; >>>> + register_t s7; >>>> + register_t s8; >>>> + register_t s9; >>>> + register_t s10; >>>> + register_t s11; >>>> + >>>> + register_t sp; >>>> + register_t gp; >>>> + >>>> + /* ra is used to jump to guest when creating new vcpu */ >>>> + register_t ra; >>>> + } xen_saved_context; >>> The xen_ prefix here also doesn't exist in Arm code. >> I think it should be added for Arm too. I can send a patch. > ... this, to reword my comment: What value does the xen_ prefix add? ... because guest doesn't access saved_context and as I mentioned above guest has "access" only to struct cpu_info->guest_cpu_user_regs.*. > >>> Nor is there a >>> similar, partly potentially misleading comment on "pc" there >>> comparable to the one that you added for "ra". ("Potentially >>> misleading" because what is being described is, aiui, not the only >>> and not even the main purpose of the field.) >> Yes, the purpose of|ra| here is not just to jump to the new vCPU code >> (|continue_new_vcpu()|). It is used that way only the first time; >> afterwards,|ra| will simply point to the next instruction after the >> call to|__context_switch()| in|context_switch()| [5]. >> >> [5] https://gitlab.com/xen-project/people/olkur/xen/-/blob/riscv-next-upstreaming/xen/arch/riscv/domain.c?ref_type=heads#L463 >> >>>> + /* CSRs */ >>>> + register_t hstatus; >>>> + register_t hedeleg; >>>> + register_t hideleg; >>>> + register_t hvip; >>>> + register_t hip; >>>> + register_t hie; >>>> + register_t hgeie; >>>> + register_t henvcfg; >>>> + register_t hcounteren; >>>> + register_t htimedelta; >>>> + register_t htval; >>>> + register_t htinst; >>>> + register_t hstateen0; >>>> +#ifdef CONFIG_RISCV_32 >>>> + register_t henvcfgh; >>>> + register_t htimedeltah; >>>> +#endif >>>> + >>>> + /* VCSRs */ >>>> + register_t vsstatus; >>>> + register_t vsip; >>>> + register_t vsie; >>>> + register_t vstvec; >>>> + register_t vsscratch; >>>> + register_t vscause; >>>> + register_t vstval; >>>> + register_t vsatp; >>>> + register_t vsepc; >>>> +} __cacheline_aligned; >>> Why this attribute? >> As arch_vcpu structure is accessed pretty often I thought it would >> be nice to have it cache-aligned so some accesses would be faster >> and something like false sharing won't happen. > I think you would want to prove that this actually makes a difference. > I notice Arm has such an attribute (and maybe indeed you merely copied > it), but x86 doesn't. I haven't measured, but I saw that Arm has and it was my explanation to myself to put it for RISC-V too. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Jan 06 15:33:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 15:33:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196281.1514141 (Exim 4.92) (envelope-from ) id 1vd93b-0002OX-CI; Tue, 06 Jan 2026 15:33:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196281.1514141; Tue, 06 Jan 2026 15:33:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd93b-0002OQ-9g; Tue, 06 Jan 2026 15:33:15 +0000 Received: by outflank-mailman (input) for mailman id 1196281; Tue, 06 Jan 2026 15:33:14 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vd93a-0002OK-6C for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 15:33:14 +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 022fde68-eb15-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 16:33:11 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-47d1d8a49f5so7465735e9.3 for ; Tue, 06 Jan 2026 07:33:11 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0dabcbsm4690205f8f.7.2026.01.06.07.33.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 07:33:10 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 022fde68-eb15-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767713591; x=1768318391; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=IlMszOJoLmP4nNIOLEdUOg2zQbNBuJx9LdtT9pdYzgY=; b=WnT3ULP+FQXvCVaKqbN2/tsp8etWKt3KbREqM615iy+IyQ5i0moB31qtQ/+C2j7sP/ TA8oSXhU7mzNc5TfqV9BZRRVSJgD6TGkjewMA3Vk+8sfOlYdXRshjJ0WV4W3/VA4T9cQ /sdy2xjZ26qAsTSvdBLBN3zjVeIM0vcPGzM7+wp+RJ26Rgxw8aTfd/jxU77VUUKVI+UE UZ67cPXrma3qbQB3isQfpqowMJ47o1TgbZp7vlXQc/FYNBIzTDYxqfrZ6LLc4S4SRfXu Wo549xDXShoYxB3COMK9nZ+9/pmYbyO7XZc90ll1zwxhXfwSkdQjsSSFLrZSdN78JPKX X+wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767713591; x=1768318391; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=IlMszOJoLmP4nNIOLEdUOg2zQbNBuJx9LdtT9pdYzgY=; b=dYEwjKpJcgyqIr/+GkVNDTKxNxNGrGKdJ1XxpgUft5+P3xRq/UTc1+7Woq2aEOMMmq tq9G1+74/ql/8uObH0zHYWy9dxMHJeKnq0MWgGHne8VkCQnOQq4yZ2Gf+bbqLkoHQJIf rNCdTwJSCd25VfX4Pu+chQlT0FGciNFDJBzGGgleu/NIEFN6Q2IAI8JPlh4ZjOgpLeOp OqEDmeW506vXmc7gv1tZoJby/8UDcLVZgXB0i2TPLaJ950Q7voif8NrcYWr9LJIf+GK0 BT/lkxXzvsQ5iZsyf+0AN4od4Zj2lzKhk3RHK10LDiG/TkRRlS5DX/oQTFMFKr1fdyUD rUlA== X-Forwarded-Encrypted: i=1; AJvYcCWAN7Hxkxy2D/78Nn3hxqJqoD37+DENNeLovwkUr3f8W70zz9rr2rAKucOT6EZMwXmF2ntxTD+VMsk=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywamp0D5+qhf4pajiZD8npY68RpE8VMvNW1js6aMCj3hN4celaN SH951Y11DNY0xhtROZ7zPJdJiJEFIeHq4xkIoN1Vyx/1efL4XxPjtNsg8dwoNz5jXw== X-Gm-Gg: AY/fxX512/C7V2qTfPPgCtPe4E4aNDGsRqRcd1usfP8OERcjpcbUW7aTrkOclHezQ/j Zy5Ov+9ua6j8Tr4+6fWtYDRV6g0WjzrUP0on0cfuZcaeGJnkAgDt/kwny5bGw4xuETRsq2/KhtU hmgMeuD+BVrFrfV4zr1hatPSn+NlGy0b59qLgNWSu5nrWmRkRIIrh679Cakr5kkssk02PjNSWYp U4wtSGLgeZMOWamBaSMwBV8b1Jf32tbmx7xePwzxgYyThzvbFDl2ZqRnpA8tmAThfRAPuPAFInP zLD0Eif1YKlnjYSNEj8jsTb3Ab++JlXyo4ISZfBOQdRA4LD+IO5wj6GmUED1ONlgzgejTmSw4rq hcUyw91IyMHaf9wEmRTQTvIlKjRDiace8VAq3JVMSlF4U+iQnnurZgxk3630cpE2XwCf8BZfQ7m Y8HjVqxbulOLlSON3ijEfAnSpNodZhNYBQqOA2disJxmBOMg8OQRGCdxire6qNYX0N31FwBv6JR WI= X-Google-Smtp-Source: AGHT+IGw1f1o35O60ZXy7DP1J5u9az+naxK7h0/Jma2lXGXGVpy3PfIhCDJlfvDZnKIklqHZAFAHLg== X-Received: by 2002:a05:600c:8b6c:b0:45d:d97c:236c with SMTP id 5b1f17b1804b1-47d7f0929b5mr38685485e9.21.1767713590680; Tue, 06 Jan 2026 07:33:10 -0800 (PST) Message-ID: Date: Tue, 6 Jan 2026 16:33:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 01/15] xen/riscv: introduce struct arch_vcpu 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: <3b531dff3755da010664111cf7d936ccba7c1f5d.1766595589.git.oleksii.kurochko@gmail.com> <41b7b388-6c10-4cbe-a4af-a25baba64e2a@suse.com> <89629a0d-de6e-46e2-8517-a4b2fdd52183@gmail.com> <2253f28f-07af-46db-9116-e9b5427953a9@suse.com> <839c06a2-dbd2-44c5-abe6-905a1f3ffefd@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: <839c06a2-dbd2-44c5-abe6-905a1f3ffefd@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06.01.2026 16:05, Oleksii Kurochko wrote: > On 1/6/26 3:26 PM, Jan Beulich wrote: >> On 06.01.2026 15:19, Oleksii Kurochko wrote: >>> On 1/5/26 5:58 PM, Jan Beulich wrote: >>>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>>> Introduce structure with VCPU's registers which describes its state. >>>>> >>>>> Signed-off-by: Oleksii Kurochko >>>> Since none of this is being used for the time being, I think the description >>>> wants to be a little less terse. Coming from the x86 (rather then the Arm) >>>> side, I find the arrangements irritating. And even when comparing to Arm, ... >>>> >>>>> --- a/xen/arch/riscv/include/asm/domain.h >>>>> +++ b/xen/arch/riscv/include/asm/domain.h >>>>> @@ -22,9 +22,63 @@ struct hvm_domain >>>>> struct arch_vcpu_io { >>>>> }; >>>>> >>>>> -struct arch_vcpu { >>>>> +struct arch_vcpu >>>>> +{ >>>>> struct vcpu_vmid vmid; >>>>> -}; >>>>> + >>>>> + /* Xen's state: Callee-saved registers and tp, gp, ra */ >>>> ... I don't think the following structure describes "Xen's state". On Arm >>>> it's guest controlled register values which are being saved afaict. I >>>> would then expect the same to become the case for RISC-V. >>> I think this is not fully correct, because guest-controlled registers on >>> Arm are allocated on the stack [1][2]. >> I'll admit that I should have said "possibly guest-controlled". Callee- >> saved registers may or may not be used in functions, and if one isn't >> used throughout the call-stack reaching __context_switch(), it would >> still hold whatever the guest had put there. > > But the guest doesn't put there nothing, only Xen does that and it is a reason > why I am trying to call it Xen state. Guest works only with what is stored in > struct cpu_info->guest_cpu_user_regs.* ... > >>> Regarding|xen_saved_context| (or|saved_context| on Arm, which I used as a base), >>> I think|xen_saved_context| is a slightly better name. Looking at how the >>> |saved_context| structure is used on Arm [3], it can be concluded that >>> |__context_switch()| switches only Xen’s internal context. What actually happens is >>> that|__context_switch()| is called while running on the previous vCPU’s stack >>> and returns on the next vCPU’s stack. Therefore, it is necessary to have >>> the correct register values stored in the|saved_context| structure in order >>> to continue Xen’s execution when it later returns to the previous stack. >> For this and ... >> >>> Probably I need to introduce|__context_switch()| in this patch series for RISC-V >>> now; I hope this will clarify things better. At the moment, it looks like [4]. >>> >>> [1] https://elixir.bootlin.com/xen/v4.21.0/source/xen/arch/arm/include/asm/arm64/processor.h#L14 >>> [2] https://elixir.bootlin.com/xen/v4.21.0/source/xen/arch/arm/domain.c#L547 >>> >>> [3] https://elixir.bootlin.com/xen/v4.21.0/source/xen/arch/arm/arm64/entry.S#L650 >>> >>> [4] https://gitlab.com/xen-project/people/olkur/xen/-/blob/riscv-next-upstreaming/xen/arch/riscv/entry.S?ref_type=heads#L153 >>> >>>>> + struct >>>>> + { >>>>> + register_t s0; >>>>> + register_t s1; >>>>> + register_t s2; >>>>> + register_t s3; >>>>> + register_t s4; >>>>> + register_t s5; >>>>> + register_t s6; >>>>> + register_t s7; >>>>> + register_t s8; >>>>> + register_t s9; >>>>> + register_t s10; >>>>> + register_t s11; >>>>> + >>>>> + register_t sp; >>>>> + register_t gp; >>>>> + >>>>> + /* ra is used to jump to guest when creating new vcpu */ >>>>> + register_t ra; >>>>> + } xen_saved_context; >>>> The xen_ prefix here also doesn't exist in Arm code. >>> I think it should be added for Arm too. I can send a patch. >> ... this, to reword my comment: What value does the xen_ prefix add? > > ... because guest doesn't access saved_context and as I mentioned above > guest has "access" only to struct cpu_info->guest_cpu_user_regs.*. The guest has no access to anything in the hypervisor. That said, seeing that Andrew had asked for this, so be it then (albeit I remain unconvinced). Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 06 15:56:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 15:56:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196295.1514150 (Exim 4.92) (envelope-from ) id 1vd9QH-0005DG-4m; Tue, 06 Jan 2026 15:56:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196295.1514150; Tue, 06 Jan 2026 15:56: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 1vd9QH-0005D9-2J; Tue, 06 Jan 2026 15:56:41 +0000 Received: by outflank-mailman (input) for mailman id 1196295; Tue, 06 Jan 2026 15:56: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 1vd9QG-0005D3-1k for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 15:56:40 +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 48e0eda0-eb18-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 16:56:38 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-47d1d8a49f5so7645575e9.3 for ; Tue, 06 Jan 2026 07:56:38 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ff1e9sm5387608f8f.41.2026.01.06.07.56.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 07:56:37 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 48e0eda0-eb18-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767714998; x=1768319798; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=ebd+bkqBU1tfghm0vHLMcZDmdzfTwmFGQGb6MBYMJ0k=; b=aa26EJEJps2H1E8jF6BwimpFMtrnV8vXPpbTC5F5p4Zx02A+QqwUHhs4IfpCKlUZbr on1aPbavuh/YEBI/g5PzLySCIhR+DXoV1q8PEBcxkUhlk1iNEQ8sdtftj5HgE/If4h25 dnCJFYEorbKGD+ZSSc6hH5AYFn28NtgWpLD8tmxgdt6O2v2g/bM9FIlpM/eIrmSnQnYj 5IqfvdBbBnB3eKOP7iat1omR9+gELMAZog4iC8rXMeKZcsIfMGvXGXeZWIbDKviMpy7I nPIDBMn1jHqC5i2xdxdcQzmj5xzfDcnmWs9w5UIU6qg6OBnvudF4mq12bQaNBkLDNFKY RJgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767714998; x=1768319798; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ebd+bkqBU1tfghm0vHLMcZDmdzfTwmFGQGb6MBYMJ0k=; b=wOBBvraBy5294Z4UJhiXlc1abE4QRAvQhaCDrG1R2/4M6m6WKq02XPvGFLaXNQmCrf dB5lv0pQanmDl1S49jit+pVoIOPN5g28y8iLgmCku5TMSUDuc/gpfqjl1x0tE6F3cHy6 qCbB11BESAl1o9fPdI7NAgGBTzcwhha7AklwGjfBV4BsS7JBjK45cU6N4yASv313O6UY D9w8Nw2pbiqmF9oemQ0f7JJ1kTjszrRxPgnwe3Jl6mlUwRT2b/VSDrIWuA5al68Ijq5i 6UmfRtEQWiPfNpyaqRHRV6KI1mjNK3/CIW3HpslRsZmnj51sbB0OMz/vt0xCSFYK3KFL lEMA== X-Forwarded-Encrypted: i=1; AJvYcCWI4M+6M/PgaYZcoxOr4llgkLX1iklhbRoZutXR1CIbLOgoDKwS2r/p4z+vDMZTIkswU21iIClIV0s=@lists.xenproject.org X-Gm-Message-State: AOJu0YzN/aWKLCd7GUQbQYaH8yoiptVUJz8z0SEGCxTYYIVZfl7nMtYw PIPAHodJye8e3+70rwpskRhx3yVRFZMuz9/E0YF4+bBX7r/vHCoRSr4+OaEAc7X6Ig== X-Gm-Gg: AY/fxX5yL7zMd7TD8OtYBz6n/COwWUJZFhVP2onMw/pS1zGgXud2xc0H5+4S44dCTHc OiwarsyLRlgKaprnaWmXBD0VicIdpaNyjN7OGdpLgLu0ywzkzF3917Eu5BFfYfkrao7Mtp7WoCh wvmma/hFn8l7OveaB6SgKS0YAY2NZR+s+qFhswrNqhcwth4XNvPzApxDILZR71nJnotX9tYViUz Iyk2RegCZZ7rHpb6ijxDYZmqlTsQcIEE8/qE7lH7k8FleUcl2hxmwQjZq11TqLfH7Hj8oYl9Isz NqemhnI/iZe1Q/2sD7La0xg0rMtFki3bnkN1+JFpVCf+1vk/H3CuDpT2uVaPBcUaXmCib2ERj0u 0Sa4+wyIDqoQUdY/u8TMIg1VGQLom6x/nvVQ+RzelDA91e508QQQaraZayAWp4QjbcVP1sTF62e OvDYZRsPbaOHHiYPdigVa3Ahal3h62JtZfvh0JLEJ025q+6C4IqN08GfpVeENv8mTLbMy4iqS8c bM= X-Google-Smtp-Source: AGHT+IFcuBWkErPL8McMvOrvh0UDAPXRH1NnRq9qrF5d3VpNbxNTY/oXCW5Gb5o096DI1gPWGdE1HQ== X-Received: by 2002:a05:600c:3b27:b0:477:8a29:582c with SMTP id 5b1f17b1804b1-47d7f0a1804mr40155165e9.34.1767714997801; Tue, 06 Jan 2026 07:56:37 -0800 (PST) Message-ID: <2e7ab738-6b5d-4ac4-a46b-1eef1cd09fb1@suse.com> Date: Tue, 6 Jan 2026 16:56:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 02/15] xen/riscv: implement arch_vcpu_{create,destroy}() To: Oleksii Kurochko Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit (some or even all of the comments may also apply to present Arm code) On 24.12.2025 18:03, Oleksii Kurochko wrote: > --- /dev/null > +++ b/xen/arch/riscv/domain.c > @@ -0,0 +1,56 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > + > +#include > +#include > + > +static void continue_new_vcpu(struct vcpu *prev) > +{ > + BUG_ON("unimplemented\n"); > +} > + > +int arch_vcpu_create(struct vcpu *v) > +{ > + int rc = 0; > + > + BUILD_BUG_ON(sizeof(struct cpu_info) > STACK_SIZE); I fear you're in trouble also when == or when only a few bytes are left on the stack. IOW I'm unconvinced that this is a useful check to have. > + v->arch.stack = alloc_xenheap_pages(STACK_ORDER, MEMF_node(vcpu_to_node(v))); > + if ( !v->arch.stack ) > + return -ENOMEM; You don't really need contiguous memory, do you? In which case why not vmalloc()? This would then also use the larger domheap. > + v->arch.cpu_info = (struct cpu_info *)(v->arch.stack > + + STACK_SIZE > + - sizeof(struct cpu_info)); Why the cast? > + memset(v->arch.cpu_info, 0, sizeof(*v->arch.cpu_info)); > + > + v->arch.xen_saved_context.sp = (register_t)v->arch.cpu_info; > + v->arch.xen_saved_context.ra = (register_t)continue_new_vcpu; > + > + printk("Create vCPU with sp=%#lx, pc=%#lx, cpu_info(%#lx)\n", > + v->arch.xen_saved_context.sp, v->arch.xen_saved_context.ra, > + (unsigned long)v->arch.cpu_info); Please don't, as this is going to get pretty noisy. (And if this wanted keeping, use %p for pointers rather than casting to unsigned long.) > + /* Idle VCPUs don't need the rest of this setup */ > + if ( is_idle_vcpu(v) ) > + return rc; > + > + /* > + * As the vtimer and interrupt controller (IC) are not yet implemented, > + * return an error. > + * > + * TODO: Drop this once the vtimer and IC are implemented. > + */ > + rc = -EOPNOTSUPP; > + goto fail; > + > + return rc; > + > + fail: > + arch_vcpu_destroy(v); > + return rc; > +} > + > +void arch_vcpu_destroy(struct vcpu *v) > +{ > + free_xenheap_pages(v->arch.stack, STACK_ORDER); > +} Better to use FREE_XENHEAP_PAGES() here, I think, to make the function idempotent. > --- a/xen/arch/riscv/include/asm/current.h > +++ b/xen/arch/riscv/include/asm/current.h > @@ -21,6 +21,12 @@ struct pcpu_info { > /* tp points to one of these */ > extern struct pcpu_info pcpu_info[NR_CPUS]; > > +/* Per-VCPU state that lives at the top of the stack */ > +struct cpu_info { > + /* This should be the first member. */ > + struct cpu_user_regs guest_cpu_user_regs; > +}; You may want to enforce what the comment says by way of a BUILD_BUG_ON(). > --- a/xen/arch/riscv/include/asm/domain.h > +++ b/xen/arch/riscv/include/asm/domain.h > @@ -49,6 +49,9 @@ struct arch_vcpu > register_t ra; > } xen_saved_context; > > + struct cpu_info *cpu_info; > + void *stack; Do you really need both fields, when one is derived from the other? Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 06 16:00:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 16:00:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196307.1514161 (Exim 4.92) (envelope-from ) id 1vd9Tp-0007P7-O1; Tue, 06 Jan 2026 16:00:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196307.1514161; Tue, 06 Jan 2026 16:00: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 1vd9Tp-0007P0-KT; Tue, 06 Jan 2026 16:00:21 +0000 Received: by outflank-mailman (input) for mailman id 1196307; Tue, 06 Jan 2026 16:00: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 1vd9To-0007Ou-9n for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 16:00:20 +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 cc6cd723-eb18-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 17:00:19 +0100 (CET) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-b7277324054so205902466b.0 for ; Tue, 06 Jan 2026 08:00:19 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a23433asm265070766b.3.2026.01.06.08.00.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 08:00:17 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cc6cd723-eb18-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767715218; x=1768320018; 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=dXzgotMMoAFsrtHUndWOcVA3dD1wQQgYXVKnrLhYyn4=; b=TOUPPS4C+q4EWZshIqnckI9WB4vsolWX0lN15o/tXItvKsqfEpQXZ9nA+mWvFC2/fe eFaHHjijpJD5qegcfBEkDBzV/1wAF+k9WatiquUrZNn+08YO0EYehkQ4X3acNn8X4vOh o4pK5zE0sKZnGiqkIV6z6Bhr4J6SpD7clfXfk4OCYwz7cNAq7qp7TgW9yp4/3oW2Ajye 1fNfurKGFcRBBStlSsaOpo76EtV/r9SgJCEGKCqfMduevZH1/jKESCo/iVpVFXkpbwyu 49VFqD4+pD1Iil6LH+Cc0CrQ0iXDwRhF2YY75YuU8Xe2NH6DaOUsf4/6HwWN4J8Ox0D0 2ixw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767715218; x=1768320018; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dXzgotMMoAFsrtHUndWOcVA3dD1wQQgYXVKnrLhYyn4=; b=AuS5zW09Vd0saIKb2rkkMG+sp1J1SxmDvStRzhnOK9rvvzZUusGK62V0CDL+sRZDGa 49BJrY5etPPKNl9RJABrP/sDByrAkBxInN5wovX4DGoNKOoglqc8jHw0Q1Bmx+certo2 +nJGrAFu++zcVPi9Bf4N6/PIDEVUd0AyOOOj3BBh6mZ74OweLbqrlO0zif0lhxT62qIg +yIy6JJ65o1FZqwk0kjz3/sqRYhRDNvFQAqVFrpTazMCtLOW14E/9zNY/UWK037gRWb1 xE4OihAoyArHyNb8lk9hOIqwkO1ir1fWDy4P7uc4rI2wsBbxo8odC3Nb9qTsH8YQhk4M n7Fg== X-Forwarded-Encrypted: i=1; AJvYcCV0T8fgPV+S0y/y3eP9tnMWjbdUIfvkxoF2+X9rQQwxPgk9Yqil9v+Sl7sWMDq+h0DkeF5YWPyRREI=@lists.xenproject.org X-Gm-Message-State: AOJu0YzjBbYO3MZ/UV1+v5y+9oSzm6Gq58n7Wq1q3T2w2IjS2JQLt5pr 1t9P0KKMZGZ4CZ+cb8F3qW1uUZ+OGlGHhqdozRthtMYjnyXWOEl+Gr8/ X-Gm-Gg: AY/fxX5Q0LBLylveaYPES90nPjydrpDWNqTkk/EDmOhop5mI7aXiAZgrJwREuD0Oifg oG9LI0gIhSj6pKNiAvU9zE5gsnmjpC4d1VOFbll6F/CV5pLO7KzLjqZxNVNFQ1juSQvAoQBnitc j6YEQn8lLwFj2XnmwWjZ2wb1gjLPklPsyfLhDQ63/azjCluQNIMxb0xu0EjSJxioL/WfZUeeYrn eEccLiHLih/b9UqqOglT5opHJPakbLkC5XUzsrTuaFSRi4JLQd/Bgv0N2iD2hRxbwrqiZic+lc1 yPKILyZukYJTUgRk8O21rCoaQ1UwB8VHmkxgSeuT3ctRCkAqmcIzbqgxjBEk3YCXtL8Zmsi4DwH sPlh3AeDI1PbWKgM6ZmICRveL0HIxi247EoY7RhOvMq0RpHipAVQrfVXMvgULiIe3rFfQb6U2lK j5eRt08bTp8Z13oYaQJb4Pv6R9s7wqMl+/V5aqcQfijhOTYZig34DMEk7xlEfwZ9c= X-Google-Smtp-Source: AGHT+IGYiWtL2mzfcJjYIj/lQRLe2q1dB3h9umdIT1pjm3drjpprFqVbwfeFZp/61e1z1tOFDCmx4A== X-Received: by 2002:a17:907:970a:b0:b76:da45:e3d6 with SMTP id a640c23a62f3a-b8426a6bc17mr374828966b.16.1767715218120; Tue, 06 Jan 2026 08:00:18 -0800 (PST) Message-ID: <5daf24da-0600-4afe-8a20-9f938e2dadaa@gmail.com> Date: Tue, 6 Jan 2026 17:00:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 01/15] xen/riscv: introduce struct arch_vcpu 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: <3b531dff3755da010664111cf7d936ccba7c1f5d.1766595589.git.oleksii.kurochko@gmail.com> <41b7b388-6c10-4cbe-a4af-a25baba64e2a@suse.com> <89629a0d-de6e-46e2-8517-a4b2fdd52183@gmail.com> <2253f28f-07af-46db-9116-e9b5427953a9@suse.com> <839c06a2-dbd2-44c5-abe6-905a1f3ffefd@gmail.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 1/6/26 4:33 PM, Jan Beulich wrote: > On 06.01.2026 16:05, Oleksii Kurochko wrote: >> On 1/6/26 3:26 PM, Jan Beulich wrote: >>> On 06.01.2026 15:19, Oleksii Kurochko wrote: >>>> On 1/5/26 5:58 PM, Jan Beulich wrote: >>>>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>>>> Introduce structure with VCPU's registers which describes its state. >>>>>> >>>>>> Signed-off-by: Oleksii Kurochko >>>>> Since none of this is being used for the time being, I think the description >>>>> wants to be a little less terse. Coming from the x86 (rather then the Arm) >>>>> side, I find the arrangements irritating. And even when comparing to Arm, ... >>>>> >>>>>> --- a/xen/arch/riscv/include/asm/domain.h >>>>>> +++ b/xen/arch/riscv/include/asm/domain.h >>>>>> @@ -22,9 +22,63 @@ struct hvm_domain >>>>>> struct arch_vcpu_io { >>>>>> }; >>>>>> >>>>>> -struct arch_vcpu { >>>>>> +struct arch_vcpu >>>>>> +{ >>>>>> struct vcpu_vmid vmid; >>>>>> -}; >>>>>> + >>>>>> + /* Xen's state: Callee-saved registers and tp, gp, ra */ >>>>> ... I don't think the following structure describes "Xen's state". On Arm >>>>> it's guest controlled register values which are being saved afaict. I >>>>> would then expect the same to become the case for RISC-V. >>>> I think this is not fully correct, because guest-controlled registers on >>>> Arm are allocated on the stack [1][2]. >>> I'll admit that I should have said "possibly guest-controlled". Callee- >>> saved registers may or may not be used in functions, and if one isn't >>> used throughout the call-stack reaching __context_switch(), it would >>> still hold whatever the guest had put there. >> But the guest doesn't put there nothing, only Xen does that and it is a reason >> why I am trying to call it Xen state. Guest works only with what is stored in >> struct cpu_info->guest_cpu_user_regs.* ... >> >>>> Regarding|xen_saved_context| (or|saved_context| on Arm, which I used as a base), >>>> I think|xen_saved_context| is a slightly better name. Looking at how the >>>> |saved_context| structure is used on Arm [3], it can be concluded that >>>> |__context_switch()| switches only Xen’s internal context. What actually happens is >>>> that|__context_switch()| is called while running on the previous vCPU’s stack >>>> and returns on the next vCPU’s stack. Therefore, it is necessary to have >>>> the correct register values stored in the|saved_context| structure in order >>>> to continue Xen’s execution when it later returns to the previous stack. >>> For this and ... >>> >>>> Probably I need to introduce|__context_switch()| in this patch series for RISC-V >>>> now; I hope this will clarify things better. At the moment, it looks like [4]. >>>> >>>> [1] https://elixir.bootlin.com/xen/v4.21.0/source/xen/arch/arm/include/asm/arm64/processor.h#L14 >>>> [2] https://elixir.bootlin.com/xen/v4.21.0/source/xen/arch/arm/domain.c#L547 >>>> >>>> [3] https://elixir.bootlin.com/xen/v4.21.0/source/xen/arch/arm/arm64/entry.S#L650 >>>> >>>> [4] https://gitlab.com/xen-project/people/olkur/xen/-/blob/riscv-next-upstreaming/xen/arch/riscv/entry.S?ref_type=heads#L153 >>>> >>>>>> + struct >>>>>> + { >>>>>> + register_t s0; >>>>>> + register_t s1; >>>>>> + register_t s2; >>>>>> + register_t s3; >>>>>> + register_t s4; >>>>>> + register_t s5; >>>>>> + register_t s6; >>>>>> + register_t s7; >>>>>> + register_t s8; >>>>>> + register_t s9; >>>>>> + register_t s10; >>>>>> + register_t s11; >>>>>> + >>>>>> + register_t sp; >>>>>> + register_t gp; >>>>>> + >>>>>> + /* ra is used to jump to guest when creating new vcpu */ >>>>>> + register_t ra; >>>>>> + } xen_saved_context; >>>>> The xen_ prefix here also doesn't exist in Arm code. >>>> I think it should be added for Arm too. I can send a patch. >>> ... this, to reword my comment: What value does the xen_ prefix add? >> ... because guest doesn't access saved_context and as I mentioned above >> guest has "access" only to struct cpu_info->guest_cpu_user_regs.*. > The guest has no access to anything in the hypervisor. Of course, the guest doesn't have access. By "access" I meant guest context stored in cpu_info->guest_cpu_user_regs.*. > That said, seeing > that Andrew had asked for this, so be it then (albeit I remain unconvinced). I will add some extra comments about xen_saved_context to make things more clear. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Jan 06 16:57:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 16:57:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196329.1514170 (Exim 4.92) (envelope-from ) id 1vdANA-0005BZ-QN; Tue, 06 Jan 2026 16:57:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196329.1514170; Tue, 06 Jan 2026 16:57:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdANA-0005BS-NW; Tue, 06 Jan 2026 16:57:32 +0000 Received: by outflank-mailman (input) for mailman id 1196329; Tue, 06 Jan 2026 16:57: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 1vdAN9-0005BM-IB for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 16:57:31 +0000 Received: from mail132-4.atl131.mandrillapp.com (mail132-4.atl131.mandrillapp.com [198.2.132.4]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c8a08e50-eb20-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 17:57:29 +0100 (CET) Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail132-4.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4dly5M3pjfzlfcGn for ; Tue, 6 Jan 2026 16:57:27 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id e4e5ddc247f74125bf560e26af8e0b56; Tue, 06 Jan 2026 16:57: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: c8a08e50-eb20-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1767718647; x=1767988647; bh=y1DHwVnEK5SakP4fiqnEDnUD6SZeD8vTuVFiLGj8VJg=; 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=LaSHKnbbbChkcXy3T33zFzEknClH/i7HZeaaHtntSRNlow3k5iJDG7gJMRYPCbjYI QqtrYUvGMrzEZKnmbI0u/uP07GmxrdN7czvfU7wSc/CvkneApMCJYotJ9/5f7wbK0H VETsSQKFBuT755A9TgwlP3ccFduc5giyKd15o+RcF+w/yInhiByNL6wTE4oTQTq/p1 8LGeXvxcl3qRu57LYbzPEgASYmTXIEUP87Mjid3TgBg30ZhHdhtW5FgBobzc8+s4mD ODf1ovS7wEr6C1g6eNy1AnLfZ8u1nmv6bpEMWOJXE3q43FeoGOCmAFsvmpby183yR9 GwfbgZUfax7Kg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1767718647; x=1767979147; i=teddy.astie@vates.tech; bh=y1DHwVnEK5SakP4fiqnEDnUD6SZeD8vTuVFiLGj8VJg=; 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=YRnR6g4v5/yUHzpAfpYqsP3VDFnGxOCE8F5t1O8gLBIwfvdPQOoccSs9EPs2YMJj/ FrvORDbJvmU/lAOgtefo2rw9FgQDYlYEO8lwf+gpHU+/FzvX+IU53pAhLws1uyZBFs iao6o4hCXlipG1c0hmeo2dPoAiTVLoCcwmTwMp2n0Xj+rr6vkTZvxPRhwdBd1pRdcI yHbiaiS1JJWt3noN3jCvE22UCVHNuCu5ecbz7+Qs+t9zOwEFBD5pZRnGMHvPpBkwUo I8ZFdxhrmYFeXioTML5mx+Z5RtUli2FejkRre5NFUjJdWJP1rHlxj+tP8G2TBQSTf0 DrqGQxHjiBEiQ== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=202/6]=20PCI:=20pass=20pdev=20to=20pci=5Fats=5F{device,enabled}()?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1767718645842 Message-Id: To: "Jan Beulich" , xen-devel@lists.xenproject.org Cc: "Andrew Cooper" , "Julien Grall" , "Stefano Stabellini" , "Anthony PERARD" , "Michal Orzel" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stewart Hildebrand" References: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@suse.com> <2ee53e39-997e-4bca-be57-ac51f75b471d@suse.com> In-Reply-To: <2ee53e39-997e-4bca-be57-ac51f75b471d@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.e4e5ddc247f74125bf560e26af8e0b56?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260106:md Date: Tue, 06 Jan 2026 16:57:27 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, Le 06/01/2026 =C3=A0 14:51, Jan Beulich a =C3=A9crit=C2=A0: > This not only brings both in sync with {en,dis}able_ats_device() but also > prepares for doing the same to pci_find_{,next_}ext_capability(). > > Signed-off-by: Jan Beulich > > --- a/xen/drivers/passthrough/amd/iommu_cmd.c > +++ b/xen/drivers/passthrough/amd/iommu_cmd.c > @@ -285,7 +285,7 @@ void amd_iommu_flush_iotlb(u8 devfn, con > if ( !ats_enabled ) > return; > > - if ( !pci_ats_enabled(pdev->seg, pdev->bus, pdev->devfn) ) > + if ( !pci_ats_enabled(pdev) ) > return; > > iommu =3D find_iommu_for_device(pdev->sbdf); > --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c > +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c > @@ -121,7 +121,7 @@ static bool use_ats( > { > return !ivrs_dev->block_ats && > iommu_has_cap(iommu, PCI_CAP_IOTLB_SHIFT) && > - pci_ats_device(iommu->sbdf.seg, pdev->bus, pdev->devfn); > + pci_ats_device(pdev); > } > > static int __must_check amd_iommu_setup_domain_device( > @@ -274,8 +274,7 @@ static int __must_check amd_iommu_setup_ > > ASSERT(pcidevs_locked()); > > - if ( use_ats(pdev, iommu, ivrs_dev) && > - !pci_ats_enabled(iommu->sbdf.seg, bus, pdev->devfn) ) > + if ( use_ats(pdev, iommu, ivrs_dev) && !pci_ats_enabled(pdev) ) > { > if ( devfn =3D=3D pdev->devfn ) > enable_ats_device(pdev, &iommu->ats_devices); > @@ -418,8 +417,7 @@ static void amd_iommu_disable_domain_dev > > ASSERT(pcidevs_locked()); > > - if ( pci_ats_device(iommu->sbdf.seg, bus, pdev->devfn) && > - pci_ats_enabled(iommu->sbdf.seg, bus, pdev->devfn) ) > + if ( pci_ats_device(pdev) && pci_ats_enabled(pdev) ) > disable_ats_device(pdev); > > BUG_ON ( iommu->dev_table.buffer =3D=3D NULL ); > --- a/xen/drivers/passthrough/ats.h > +++ b/xen/drivers/passthrough/ats.h > @@ -27,27 +27,25 @@ extern bool ats_enabled; > int enable_ats_device(struct pci_dev *pdev, struct list_head *ats_list)= ; > void disable_ats_device(struct pci_dev *pdev); > > -static inline int pci_ats_enabled(int seg, int bus, int devfn) > +static inline int pci_ats_enabled(const struct pci_dev *pdev) > { > u32 value; > int pos; > > - pos =3D pci_find_ext_capability(PCI_SBDF(seg, bus, devfn), > - PCI_EXT_CAP_ID_ATS); > + pos =3D pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_ATS); > BUG_ON(!pos); > > - value =3D pci_conf_read16(PCI_SBDF(seg, bus, devfn), pos + ATS_REG_C= TL); > + value =3D pci_conf_read16(pdev->sbdf, pos + ATS_REG_CTL); > > return value & ATS_ENABLE; > } > > -static inline int pci_ats_device(int seg, int bus, int devfn) > +static inline int pci_ats_device(const struct pci_dev *pdev) > { > if ( !ats_enabled ) > return 0; > > - return pci_find_ext_capability(PCI_SBDF(seg, bus, devfn), > - PCI_EXT_CAP_ID_ATS); > + return pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_ATS); > } > > #endif /* DRIVERS__PASSTHROUGH__ATS_H */ > > Reviewed-by: Teddy Astie Teddy -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Jan 06 17:02:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 17:02:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196341.1514180 (Exim 4.92) (envelope-from ) id 1vdARf-0006iy-AB; Tue, 06 Jan 2026 17:02:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196341.1514180; Tue, 06 Jan 2026 17: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 1vdARf-0006ir-7a; Tue, 06 Jan 2026 17:02:11 +0000 Received: by outflank-mailman (input) for mailman id 1196341; Tue, 06 Jan 2026 17: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 1vdARd-0006ik-Kz for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 17:02:09 +0000 Received: from mail187-9.suw11.mandrillapp.com (mail187-9.suw11.mandrillapp.com [198.2.187.9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6dad9009-eb21-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 18:02:06 +0100 (CET) Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail187-9.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4dlyBh74PPzK5vgVM for ; Tue, 6 Jan 2026 17:02:04 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 8cc4b391f3b146d5ac0f9bccd49f68b9; Tue, 06 Jan 2026 17:02: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: 6dad9009-eb21-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1767718925; x=1767988925; bh=egqjvhUVqm4ao1P2jtHT/8Qd8On7BJ1hb3Y7cTHD+O8=; 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=Rlrv6CeLYrGL2epincZPGgmYvftm0DkKsyyeltqANie/ndy1376m/lgA3zu8j8NpN PJ6V+xKKqr+GfKg+XgAsRfaX8uBBYGCai3lKgIXQ/WUaV9AfFXzN50GsVuA3ghB3S4 PFJqrZU088I2a1z8bgNzk5ycTl+lVp6foDGXQqQfDW4/HNZsoGhAUwhXbf6R2EZvqT BNU1SQ7aFA6mEyiNa/XndPtqv97KR+cxVtDqY+zishOqrDRnNhAhGWTbvVugk7WvJJ 60H/ODd3/O2lbTbJjkkGboWayw6FowzKsjEkJhSo5Ny8N4JTqnKpqyLQpILu8O5dn6 WIEEOJUZu5PKw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1767718925; x=1767979425; i=teddy.astie@vates.tech; bh=egqjvhUVqm4ao1P2jtHT/8Qd8On7BJ1hb3Y7cTHD+O8=; 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=yvWXeI6p0SHn/kovpIGMczh5V/7/aCb7N/xbw/1LkaxrMfRTDZTkJcPwobBPXjUet mUvs2FfVb7c/XsNCZxCAqDSoX+t7qaBYbL2SYJP2GFC3fFK1TQKq+osH0NB+llH4cj A86MJaMBxDaB2kIN2K8JR1dY9NuZr/sITBl/x9qU5XL2wM9qTiIaYI6IlYzik0ho5O MpMrPivGt2YtGq3lFOsK7CkGMUaoliHxqxxbnxoNUm0zEPI1iQy/lurgoK8oaiqjeZ 0u6rCC1qSM8ADd3xqXSduNZalP5F1VBX4b+1nBa2sLFJ7SZvWmt45QJ3+LVWCO0ZxQ 0mJvIRH1VpExg== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=203/6]=20x86/MSI:=20pass=20pdev=20to=20read=5Fpci=5Fmem=5Fbar()?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1767718923781 Message-Id: To: "Jan Beulich" , xen-devel@lists.xenproject.org Cc: "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stewart Hildebrand" References: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@suse.com> In-Reply-To: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.8cc4b391f3b146d5ac0f9bccd49f68b9?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260106:md Date: Tue, 06 Jan 2026 17:02:04 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 06/01/2026 =C3=A0 14:51, Jan Beulich a =C3=A9crit=C2=A0: > This not only reduces the number of parameters and local variables, but > also prepares for doing the same to pci_find_{,next_}ext_capability(). > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/msi.c > +++ b/xen/arch/x86/msi.c > @@ -662,11 +662,11 @@ static int msi_capability_init(struct pc > return 0; > } > > -static uint64_t read_pci_mem_bar(pci_sbdf_t sbdf, uint8_t bir, int vf, > - const struct pf_info *pf_info) > +static uint64_t read_pci_mem_bar(const struct pci_dev *pdev, uint8_t bir= , > + int vf) > { > - uint16_t seg =3D sbdf.seg; > - uint8_t bus =3D sbdf.bus, slot =3D sbdf.dev, func =3D sbdf.fn; > + uint16_t seg =3D pdev->sbdf.seg; > + uint8_t bus =3D pdev->sbdf.bus, slot =3D pdev->sbdf.dev, func =3D pd= ev->sbdf.fn; > u8 limit; > u32 addr, base =3D PCI_BASE_ADDRESS_0; > u64 disp =3D 0; > @@ -676,20 +676,18 @@ static uint64_t read_pci_mem_bar(pci_sbd > unsigned int pos; > uint16_t ctrl, num_vf, offset, stride; > > - ASSERT(pf_info); > - > - pos =3D pci_find_ext_capability(sbdf, PCI_EXT_CAP_ID_SRIOV); > - ctrl =3D pci_conf_read16(sbdf, pos + PCI_SRIOV_CTRL); > - num_vf =3D pci_conf_read16(sbdf, pos + PCI_SRIOV_NUM_VF); > - offset =3D pci_conf_read16(sbdf, pos + PCI_SRIOV_VF_OFFSET); > - stride =3D pci_conf_read16(sbdf, pos + PCI_SRIOV_VF_STRIDE); > + pos =3D pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_SRIOV= ); > + ctrl =3D pci_conf_read16(pdev->sbdf, pos + PCI_SRIOV_CTRL); > + num_vf =3D pci_conf_read16(pdev->sbdf, pos + PCI_SRIOV_NUM_VF); > + offset =3D pci_conf_read16(pdev->sbdf, pos + PCI_SRIOV_VF_OFFSET= ); > + stride =3D pci_conf_read16(pdev->sbdf, pos + PCI_SRIOV_VF_STRIDE= ); > > if ( !pos || > !(ctrl & PCI_SRIOV_CTRL_VFE) || > !(ctrl & PCI_SRIOV_CTRL_MSE) || > !num_vf || !offset || (num_vf > 1 && !stride) || > bir >=3D PCI_SRIOV_NUM_BARS || > - !pf_info->vf_rlen[bir] ) > + !pdev->physfn.vf_rlen[bir] ) > return 0; > base =3D pos + PCI_SRIOV_BAR; > vf -=3D PCI_BDF(bus, slot, func) + offset; > @@ -703,8 +701,8 @@ static uint64_t read_pci_mem_bar(pci_sbd > } > if ( vf >=3D num_vf ) > return 0; > - BUILD_BUG_ON(ARRAY_SIZE(pf_info->vf_rlen) !=3D PCI_SRIOV_NUM_BAR= S); > - disp =3D vf * pf_info->vf_rlen[bir]; > + BUILD_BUG_ON(ARRAY_SIZE(pdev->physfn.vf_rlen) !=3D PCI_SRIOV_NUM= _BARS); > + disp =3D vf * pdev->physfn.vf_rlen[bir]; > limit =3D PCI_SRIOV_NUM_BARS; > } > else switch ( pci_conf_read8(PCI_SBDF(seg, bus, slot, func), > @@ -759,10 +757,6 @@ static int msix_capability_init(struct p > u16 control; > u64 table_paddr; > u32 table_offset; > - u16 seg =3D dev->seg; > - u8 bus =3D dev->bus; > - u8 slot =3D PCI_SLOT(dev->devfn); > - u8 func =3D PCI_FUNC(dev->devfn); > bool maskall =3D msix->host_maskall, zap_on_error =3D false; > unsigned int pos =3D dev->msix_pos; > > @@ -809,32 +803,20 @@ static int msix_capability_init(struct p > (is_hardware_domain(current->domain) && > (dev->domain =3D=3D current->domain || dev->domain =3D=3D do= m_io))) ) > { > - unsigned int bir =3D table_offset & PCI_MSIX_BIRMASK, pbus, pslo= t, pfunc; > - int vf; > + unsigned int bir =3D table_offset & PCI_MSIX_BIRMASK; > + int vf =3D -1; > + const struct pci_dev *pf_dev =3D dev; > paddr_t pba_paddr; > unsigned int pba_offset; > - const struct pf_info *pf_info; > > - if ( !dev->info.is_virtfn ) > - { > - pbus =3D bus; > - pslot =3D slot; > - pfunc =3D func; > - vf =3D -1; > - pf_info =3D NULL; > - } > - else > + if ( dev->info.is_virtfn ) > { > - pbus =3D dev->info.physfn.bus; > - pslot =3D PCI_SLOT(dev->info.physfn.devfn); > - pfunc =3D PCI_FUNC(dev->info.physfn.devfn); > vf =3D dev->sbdf.bdf; > ASSERT(dev->pf_pdev); > - pf_info =3D &dev->pf_pdev->physfn; > + pf_dev =3D dev->pf_pdev; > } > > - table_paddr =3D read_pci_mem_bar(PCI_SBDF(seg, pbus, pslot, pfun= c), bir, > - vf, pf_info); > + table_paddr =3D read_pci_mem_bar(pf_dev, bir, vf); > WARN_ON(msi && msi->table_base !=3D table_paddr); > if ( !table_paddr ) > { > @@ -857,8 +839,7 @@ static int msix_capability_init(struct p > > pba_offset =3D pci_conf_read32(dev->sbdf, msix_pba_offset_reg(p= os)); > bir =3D (u8)(pba_offset & PCI_MSIX_BIRMASK); > - pba_paddr =3D read_pci_mem_bar(PCI_SBDF(seg, pbus, pslot, pfunc)= , bir, vf, > - pf_info); > + pba_paddr =3D read_pci_mem_bar(pf_dev, bir, vf); > WARN_ON(!pba_paddr); > pba_paddr +=3D pba_offset & ~PCI_MSIX_BIRMASK; > > > Reviewed-by: Teddy Astie -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Jan 06 17:04:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 17:04:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196350.1514191 (Exim 4.92) (envelope-from ) id 1vdATU-0007EH-Ks; Tue, 06 Jan 2026 17:04:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196350.1514191; Tue, 06 Jan 2026 17:04:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdATU-0007EA-Hy; Tue, 06 Jan 2026 17:04:04 +0000 Received: by outflank-mailman (input) for mailman id 1196350; Tue, 06 Jan 2026 17:04: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 1vdATU-0007E2-4e for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 17:04:04 +0000 Received: from mail187-9.suw11.mandrillapp.com (mail187-9.suw11.mandrillapp.com [198.2.187.9]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b2f9add9-eb21-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 18:04:02 +0100 (CET) Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail187-9.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4dlyDx0qqhzK5vrVM for ; Tue, 6 Jan 2026 17:04:01 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 359c39a1b76b443caecc621e9aa905e3; Tue, 06 Jan 2026 17: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: b2f9add9-eb21-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1767719041; x=1767989041; bh=PsaykRCeu3N+wVHokhx8ZhkaU760h6d3CDcBgBZBAcc=; 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=QUAtvkjmKgDjiVwOmB8CrEto8BgZ0DTY/0HjSF+5E+aD0YD7y0vBQaOFL9MOXLxJb Loe2UsBnwsrlf7jGfsgR55ORzNYT1fyE1qjLPPqOr6KhWwtu2z7PVD10Krqg0GihQd /TNzpUoS/80N/ZK/VdB3Rj63C5A3/QzaRbbbfz8eEBtzHE/WZz0u7KVyF6cXVvsvUR Z0F6PfbK/lWIAPOyi077VWHI6FJCgUWWA7HYqSH++GvX6zp87qHw1J6IdS2xHzhriJ G71qyDQtB/xSiFNjzPahlDqplBqdPShgJqP3DXfjTt4PH6shNvLSy3E/Dn8oXKUkYT 0lTd9/yFB02/Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1767719041; x=1767979541; i=teddy.astie@vates.tech; bh=PsaykRCeu3N+wVHokhx8ZhkaU760h6d3CDcBgBZBAcc=; 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=N7WOgLkIjJxzUEdP6m0wYNwogwfotBoMpbL6iX3hgv7bcwaqk6dOyD2GSUMgykS4T UzFMqdE0onXEc2j5kx37pcVkfheNV7vSMOnmZVXHyt27hoqOKqUKGzwrYJwLzeR5rH A8L7qp4WfgJFzO27Qywp0YcWRAOkCVSthSZxdM2DY5/kMi5zV5HunPLmLO0ctyxT+9 Zl0+g/JyL84I7YwYo9wDvwdUSLBOHvfIVXOPhR4A3sL5TkWIedDcmf97bI/BgZAubb 8X32yIjWj0IqwEfUYYzJYXd+wQUuVFq6tD88x9HFhfCyihuF8btPZ/6UiaJZQj3bu5 R1SGbTb1MfeKA== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=204/6]=20PCI:=20pass=20pdev=20to=20pci=5Ffind=5F{,next=5F}ext=5Fcapability()?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1767719039376 Message-Id: To: "Jan Beulich" , xen-devel@lists.xenproject.org Cc: "Andrew Cooper" , "Julien Grall" , "Stefano Stabellini" , "Anthony PERARD" , "Michal Orzel" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stewart Hildebrand" References: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@suse.com> <594cc7a9-710c-4863-b46f-f5e6bc0247de@suse.com> In-Reply-To: <594cc7a9-710c-4863-b46f-f5e6bc0247de@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.359c39a1b76b443caecc621e9aa905e3?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260106:md Date: Tue, 06 Jan 2026 17:04:01 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 06/01/2026 =C3=A0 14:52, Jan Beulich a =C3=A9crit=C2=A0: > This is in preparation of using attributes recorded for devices. > Additionally locating (extended) capabilities of non-devices (e.g. phanto= m > functions) makes no sense. > > While there also eliminate open-coding of PCI_CFG_SPACE_SIZE in adjacent > code. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/msi.c > +++ b/xen/arch/x86/msi.c > @@ -676,7 +676,7 @@ static uint64_t read_pci_mem_bar(const s > unsigned int pos; > uint16_t ctrl, num_vf, offset, stride; > > - pos =3D pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_SRIOV= ); > + pos =3D pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_SRIOV); > ctrl =3D pci_conf_read16(pdev->sbdf, pos + PCI_SRIOV_CTRL); > num_vf =3D pci_conf_read16(pdev->sbdf, pos + PCI_SRIOV_NUM_VF); > offset =3D pci_conf_read16(pdev->sbdf, pos + PCI_SRIOV_VF_OFFSE= T); > --- a/xen/drivers/passthrough/ats.c > +++ b/xen/drivers/passthrough/ats.c > @@ -26,7 +26,7 @@ int enable_ats_device(struct pci_dev *pd > u32 value; > int pos; > > - pos =3D pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_ATS); > + pos =3D pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ATS); > BUG_ON(!pos); > > if ( iommu_verbose ) > --- a/xen/drivers/passthrough/ats.h > +++ b/xen/drivers/passthrough/ats.h > @@ -32,7 +32,7 @@ static inline int pci_ats_enabled(const > u32 value; > int pos; > > - pos =3D pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_ATS); > + pos =3D pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ATS); > BUG_ON(!pos); > > value =3D pci_conf_read16(pdev->sbdf, pos + ATS_REG_CTL); > @@ -45,7 +45,7 @@ static inline int pci_ats_device(const s > if ( !ats_enabled ) > return 0; > > - return pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_ATS); > + return pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ATS); > } > > #endif /* DRIVERS__PASSTHROUGH__ATS_H */ > --- a/xen/drivers/passthrough/pci.c > +++ b/xen/drivers/passthrough/pci.c > @@ -641,7 +641,7 @@ static void pci_enable_acs(struct pci_de > if ( !is_iommu_enabled(pdev->domain) ) > return; > > - pos =3D pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_ACS); > + pos =3D pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ACS); > if (!pos) > return; > > @@ -787,8 +787,7 @@ int pci_add_device(u16 seg, u8 bus, u8 d > > if ( !pdev->info.is_virtfn && !pdev->physfn.vf_rlen[0] ) > { > - unsigned int pos =3D pci_find_ext_capability(pdev->sbdf, > - PCI_EXT_CAP_ID_SRIOV)= ; > + unsigned int pos =3D pci_find_ext_capability(pdev, PCI_EXT_CAP_I= D_SRIOV); > uint16_t ctrl =3D pci_conf_read16(pdev->sbdf, pos + PCI_SRIOV_C= TRL); > > if ( !pos ) > --- a/xen/drivers/passthrough/vtd/x86/ats.c > +++ b/xen/drivers/passthrough/vtd/x86/ats.c > @@ -62,7 +62,7 @@ int ats_device(const struct pci_dev *pde > return 0; > > ats_drhd =3D find_ats_dev_drhd(drhd->iommu); > - pos =3D pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_ATS); > + pos =3D pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ATS); > > if ( pos && (ats_drhd =3D=3D NULL) ) > { > --- a/xen/drivers/passthrough/vtd/quirks.c > +++ b/xen/drivers/passthrough/vtd/quirks.c > @@ -531,10 +531,10 @@ void pci_vtd_quirk(const struct pci_dev > /* Sandybridge-EP (Romley) */ > case 0x3c00: /* host bridge */ > case 0x3c01 ... 0x3c0b: /* root ports */ > - pos =3D pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_ERR); > + pos =3D pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ERR); > if ( !pos ) > { > - pos =3D pci_find_ext_capability(pdev->sbdf, PCI_EXT_CAP_ID_V= NDR); > + pos =3D pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_VNDR); > while ( pos ) > { > val =3D pci_conf_read32(pdev->sbdf, pos + PCI_VNDR_HEAD= ER); > @@ -543,7 +543,7 @@ void pci_vtd_quirk(const struct pci_dev > pos +=3D PCI_VNDR_HEADER; > break; > } > - pos =3D pci_find_next_ext_capability(pdev->sbdf, pos, > + pos =3D pci_find_next_ext_capability(pdev, pos, > PCI_EXT_CAP_ID_VNDR)= ; > } > ff =3D 0; > --- a/xen/drivers/pci/pci.c > +++ b/xen/drivers/pci/pci.c > @@ -89,9 +89,10 @@ unsigned int pci_find_next_cap(pci_sbdf_ > * within the device's PCI configuration space or 0 if the device does > * not support it. > */ > -unsigned int pci_find_ext_capability(pci_sbdf_t sbdf, unsigned int cap) > +unsigned int pci_find_ext_capability(const struct pci_dev *pdev, > + unsigned int cap) > { > - return pci_find_next_ext_capability(sbdf, 0, cap); > + return pci_find_next_ext_capability(pdev, 0, cap); > } > > /** > @@ -104,14 +105,15 @@ unsigned int pci_find_ext_capability(pci > * within the device's PCI configuration space or 0 if the device does > * not support it. > */ > -unsigned int pci_find_next_ext_capability(pci_sbdf_t sbdf, unsigned int = start, > +unsigned int pci_find_next_ext_capability(const struct pci_dev *pdev, > + unsigned int start, > unsigned int cap) > { > u32 header; > int ttl =3D 480; /* 3840 bytes, minimum 8 bytes per capability */ > - unsigned int pos =3D max(start, 0x100U); > + unsigned int pos =3D max(start, PCI_CFG_SPACE_SIZE + 0U); > > - header =3D pci_conf_read32(sbdf, pos); > + header =3D pci_conf_read32(pdev->sbdf, pos); > > /* > * If we have no capabilities, this is indicated by cap ID, > @@ -125,9 +127,9 @@ unsigned int pci_find_next_ext_capabilit > if ( PCI_EXT_CAP_ID(header) =3D=3D cap && pos !=3D start ) > return pos; > pos =3D PCI_EXT_CAP_NEXT(header); > - if ( pos < 0x100 ) > + if ( pos < PCI_CFG_SPACE_SIZE ) > break; > - header =3D pci_conf_read32(sbdf, pos); > + header =3D pci_conf_read32(pdev->sbdf, pos); > } > return 0; > } > --- a/xen/drivers/vpci/rebar.c > +++ b/xen/drivers/vpci/rebar.c > @@ -53,7 +53,7 @@ static int cf_check init_rebar(struct pc > { > uint32_t ctrl; > unsigned int nbars; > - unsigned int rebar_offset =3D pci_find_ext_capability(pdev->sbdf, > + unsigned int rebar_offset =3D pci_find_ext_capability(pdev, > PCI_EXT_CAP_ID_= REBAR); > > if ( !rebar_offset ) > --- a/xen/drivers/vpci/vpci.c > +++ b/xen/drivers/vpci/vpci.c > @@ -196,7 +196,7 @@ static struct vpci_register *vpci_get_pr > static int vpci_ext_capability_hide( > const struct pci_dev *pdev, unsigned int cap) > { > - const unsigned int offset =3D pci_find_ext_capability(pdev->sbdf, ca= p); > + const unsigned int offset =3D pci_find_ext_capability(pdev, cap); > struct vpci_register *r, *prev_r; > struct vpci *vpci =3D pdev->vpci; > uint32_t header, pre_header; > @@ -264,7 +264,7 @@ static int vpci_init_capabilities(struct > if ( !is_ext ) > pos =3D pci_find_cap_offset(pdev->sbdf, cap); > else if ( is_hardware_domain(pdev->domain) ) > - pos =3D pci_find_ext_capability(pdev->sbdf, cap); > + pos =3D pci_find_ext_capability(pdev, cap); > > if ( !pos ) > continue; > @@ -333,7 +333,7 @@ void vpci_deassign_device(struct pci_dev > if ( !capability->is_ext ) > pos =3D pci_find_cap_offset(pdev->sbdf, cap); > else if ( is_hardware_domain(pdev->domain) ) > - pos =3D pci_find_ext_capability(pdev->sbdf, cap); > + pos =3D pci_find_ext_capability(pdev, cap); > if ( pos ) > { > int rc =3D capability->cleanup(pdev, false); > --- a/xen/include/xen/pci.h > +++ b/xen/include/xen/pci.h > @@ -263,8 +263,10 @@ unsigned int pci_find_next_cap_ttl(pci_s > unsigned int *ttl); > unsigned int pci_find_next_cap(pci_sbdf_t sbdf, unsigned int pos, > unsigned int cap); > -unsigned int pci_find_ext_capability(pci_sbdf_t sbdf, unsigned int cap); > -unsigned int pci_find_next_ext_capability(pci_sbdf_t sbdf, unsigned int = start, > +unsigned int pci_find_ext_capability(const struct pci_dev *pdev, > + unsigned int cap); > +unsigned int pci_find_next_ext_capability(const struct pci_dev *pdev, > + unsigned int start, > unsigned int cap); > const char *parse_pci(const char *s, unsigned int *seg_p, unsigned int = *bus_p, > unsigned int *dev_p, unsigned int *func_p); > > Reviewed-by: Teddy Astie -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Jan 06 17:37:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 17:37:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196371.1514200 (Exim 4.92) (envelope-from ) id 1vdAzI-00038w-6O; Tue, 06 Jan 2026 17:36:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196371.1514200; Tue, 06 Jan 2026 17: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 1vdAzI-00038p-3h; Tue, 06 Jan 2026 17:36:56 +0000 Received: by outflank-mailman (input) for mailman id 1196371; Tue, 06 Jan 2026 17:36: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 1vdAzH-00038j-70 for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 17:36:55 +0000 Received: from mail132-4.atl131.mandrillapp.com (mail132-4.atl131.mandrillapp.com [198.2.132.4]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 48df8576-eb26-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 18:36:52 +0100 (CET) Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail132-4.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4dlyyp0gVTzlfcH2 for ; Tue, 6 Jan 2026 17:36:50 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id bfe4d8aa3bf34ea088abf611718410b1; Tue, 06 Jan 2026 17:36:49 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 48df8576-eb26-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1767721010; x=1767991010; bh=w3mV3E2iL19ORVQDih7RkM67id0b/WPDTgHutCZfw84=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=IlcgEn9aTOIPo7aVto3g5B3TVUeI1vYI3ZKIkXIiOGdBruPh3+BCgKVbCFlsLAwLi hJDnpZct7vVPSeAvG3KmYpRdRj/2hHu98dOJ7AI0vZIF+SwcBFYpqmJsbsT6XRVyWz I4+5RVSYPPPDO97nDTYqfcvlUPdSXvFDGnnaCyC7OFKijn1i7AuxraWiu9/g2B1okn R2EIf6gtt4Jcmq+T3/mFs4p+W6kho+f/VG0Jxpj4eZog70mEeRlJwoDHBQq9Mr2PHI 0URLDF5OHQ7kPYnpU+rwGKd1sGliRRTry7M8Im3+VSN9PgRUpZjVnKBy2zP8KR4SjU D4KDka/JDPJ3w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1767721010; x=1767981510; i=teddy.astie@vates.tech; bh=w3mV3E2iL19ORVQDih7RkM67id0b/WPDTgHutCZfw84=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=gkW6SiOF15wS5oFhi4GscfzabCvx6VxzbcLjKybXDnAT7/kiNe3WRuOk2260zCERF nRcF/j/YgA8b810Uk4k1qx/b03yaaxs4WHqmfO0nBBn2Dbv1IA9x/mYRcCY9DQQwxN 2P1tUdWs4rbw5egWCqKLCUREFVWKVpwYxWM3PkCm5R/44FE+1WvTu7aAC3MTImgr2i +xVb1FOvFHoL82Bu9LSEHblif623dWCVDN0iXH4CMUlyh3df45HzYyGiIjt6+VwG9b pQcS4pL1DzYYHrVFA2tr48gGGVHfJePNUR+UH4tjMJkRzXPzG4hnFBW3yGr6Sk3iQ0 51BXaUY8QnzDg== From: "Teddy Astie" Subject: =?utf-8?Q?[PATCH]=20xen/virtio:=20Don't=20use=20grant-dma-ops=20when=20running=20as=20Dom0?= X-Mailer: git-send-email 2.52.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1767721008494 To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Cc: "Teddy Astie" , "Juergen Gross" , "Stefano Stabellini" , "Oleksandr Tyshchenko" , "Boris Ostrovsky" Message-Id: <6698564dd2270a9f7377b78ebfb20cb425cabbe8.1767720955.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.bfe4d8aa3bf34ea088abf611718410b1?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260106:md Date: Tue, 06 Jan 2026 17:36:49 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Dom0 inherit devices from the machine and is usually in PV mode. If we are running in a virtual that has virtio devices, these devices would be considered as using grants with Dom0 as backend, while being the said Dom0 itself, while we want to use these devices like regular PCI devices. Fix this by preventing grant-dma-ops from being used when running as Dom0 (initial domain). We still keep the device-tree logic as-is. Signed-off-by: Teddy Astie Fixes: 61367688f1fb0 ("xen/virtio: enable grant based virtio on x86") --- CC: Juergen Gross CC: Stefano Stabellini CC: Oleksandr Tyshchenko CC: Boris Ostrovsky drivers/xen/grant-dma-ops.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c index 14077d23f2a1..c2603e700178 100644 --- a/drivers/xen/grant-dma-ops.c +++ b/drivers/xen/grant-dma-ops.c @@ -366,7 +366,8 @@ static int xen_grant_init_backend_domid(struct device *dev, if (np) { ret = xen_dt_grant_init_backend_domid(dev, np, backend_domid); of_node_put(np); - } else if (IS_ENABLED(CONFIG_XEN_VIRTIO_FORCE_GRANT) || xen_pv_domain()) { + } else if (!xen_initial_domain() && + (IS_ENABLED(CONFIG_XEN_VIRTIO_FORCE_GRANT) || xen_pv_domain())) { dev_info(dev, "Using dom0 as backend\n"); *backend_domid = 0; ret = 0; -- 2.52.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 Jan 06 17:50:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 17:50:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196382.1514210 (Exim 4.92) (envelope-from ) id 1vdBCd-0005sU-An; Tue, 06 Jan 2026 17:50:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196382.1514210; Tue, 06 Jan 2026 17:50:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdBCd-0005sN-8B; Tue, 06 Jan 2026 17:50:43 +0000 Received: by outflank-mailman (input) for mailman id 1196382; Tue, 06 Jan 2026 17:50:42 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdBCc-0005sH-2Q for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 17:50:42 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 369b17ee-eb28-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 18:50:40 +0100 (CET) Received: from nico-ideapad (unknown [46.228.253.214]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPSA id 5A9D54EE3C04; Tue, 6 Jan 2026 18:50:36 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 369b17ee-eb28-11f0-b15e-2bf370ae4941 Authentication-Results: bugseng.com; arc=none smtp.remote-ip=46.228.253.214 ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1767721838; b=G3abZtpGtXqYpXFEv3mZ6ALAZkKkeAFTlVjn5qS9o6xJSSgM4qchSuCMtQPTek4LVcMW p0lwZ4rOblVJX1E22edYLsmNY/YebYUq5A7Nk04SK2plR+Fq01Xbcw1/Lqt2Zc8eOEBSq Iv3jUkMypnmljB5uoZpfkkzcn5flBwEs70FET4yGKmxUnf6LbDtYdZAfYxf772vAeUKtE jmeSM+OuXrO7uFgSwSLxFoqieE5OxTPxNp7v4S7RLU0jNiunlZEd9Hn2zhaRKSe1UeDsY Ck7kuK6qVlAbakNwaCCGb2MGLCaUa85kJGzeVfM6rZbV2Wyo7y699nvfXZY/CSxgPQEVP Ql/OcKrozmmDPYfu7MH+NBI26kPL31Ibpd/e07bKPpUlBKsyF+R3yMcRty3sA91ABC1HL EVhBzeqsCWe411SK623lFoX0wwufibG9ypTBKthL+7E7ROjR1i1dXP7mR6foLb3zP8TVs wJwLgmgX0DeBgJZ9b8rWTwPYobWmrM7guh7VkTam3aGeZNfH2bd/BWb72q54JXZ0wGwKD ZN9Pl48SCyatYjh0gQGr1DGIrfLt1E5EScjXurvBLWkKbESS67wuTv2bBYbJ0vAItDJ2r bbK+/RiJ9I2cR4DLt0KaHSTVS/ZmlM1Ll8VnAm222yMx7K/dcvlmCGPzJylCVRY= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1767721838; h=From:To:Cc:Subject:Date:Message-ID:X-Mailer:MIME-Version: Content-Transfer-Encoding; bh=T4UUPg4ziycQ2CZJTxKm9+cjlQl10naOxSR1r3Y4jNM=; b=2C8y3b1P1mIWd7u4YOzXQ/6bF8R5I43+0MYx6fiBlljJC144lZlqVXOF+mjwZ8RLLXP4 MfBE9OGlUKQDqTI7+NI/dBIWAOhLvURWpvpKUgSyKa7Qqgxm0kAn6UX4LQ1o+D8zTQ2ua scEn8E4wcS8/+sOMWRxim/x9Fnh8wWF/RumDHwOcS/2zfUoUlvHaAXjbp0AVhOt/hwpft enPKEopnUgQ6R2xiBC62LWtqcqriXAEGdXPmKm6QpN0bVtl1fhvqss9zaBT6VCCX5zB9R b8gMJYqMiiCzeUB8Q4cOXIqfjEvsGfVxTmmUdIzBGfJczIC0m8fVzfPFEHaFW2hD45zdA ivwuWjJduGBJ6TwSpwoM1Atqi2aO8d5GKF36Kum3WyeT/EncqMcutcx2wA89Fw+9RdUf/ LPMcN+Jf475FPVJkFAVtJbNRrgYmK1gdGkVm9e8q5kGIdD1EV1akf9TdNEayvv5D0vCaw VoEXu440HhgPc5znmAlBs3QEJlYxKPEd0dZFXSdsycRV7VM2cYRKikzLgpQuFG+D4on27 ezzN0boWnlH+/zxcglSs4CJj1iz9ufkuSkQqzHf9X7/jcbHKNKkbyFeSVsKGCrSJbJAWG u9cMHlIaEwu01SDiJqJrSDCrJDbFRsEjjWIafk8ZnS9dC7Jj/FUW676q9cQG1z8= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=46.228.253.214 From: Nicola Vetrini To: xen-devel@lists.xenproject.org Cc: Nicola Vetrini , Doug Goldstein , Stefano Stabellini , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH] misra: allow using binary literals in c99 as an extension. Date: Tue, 6 Jan 2026 18:50:08 +0100 Message-ID: <30bb474fbb0e9236728fad9515bca4d160d594b3.1767721635.git.nicola.vetrini@bugseng.com> X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Nicola Vetrini There is consensus towards using more binary literals in Xen, so they are enabled both for X86_64 and ARM64. Signed-off-by: Nicola Vetrini --- automation/eclair_analysis/ECLAIR/toolchain.ecl | 5 +++++ docs/misra/C-language-toolchain.rst | 4 ++++ 2 files changed, 9 insertions(+) diff --git a/automation/eclair_analysis/ECLAIR/toolchain.ecl b/automation/eclair_analysis/ECLAIR/toolchain.ecl index 4bc88aa029..da00c2198a 100644 --- a/automation/eclair_analysis/ECLAIR/toolchain.ecl +++ b/automation/eclair_analysis/ECLAIR/toolchain.ecl @@ -332,3 +332,8 @@ ext_sizeof_alignof_void_type" -doc_begin="See Section \"4.13 Preprocessing Directives\" of "GCC_MANUAL" and Section \"11.1 Implementation-defined behavior\" of "CPP_MANUAL"." -config=STD.inclexpd,behavior={c99, GCC_X86_64, "specified"} -doc_end + +-doc_begin="See Section \"6.65 Binary Constants using the '0b' Prefix\" of "GCC_MANUAL"." +-config=STD.ltrlbin,behavior={c99, GCC_ARM64, "specified"} +-config=STD.ltrlbin,behavior={c99, GCC_X86_64, "specified"} +-doc_end diff --git a/docs/misra/C-language-toolchain.rst b/docs/misra/C-language-toolchain.rst index ec0c9953be..5d418e262a 100644 --- a/docs/misra/C-language-toolchain.rst +++ b/docs/misra/C-language-toolchain.rst @@ -218,6 +218,10 @@ The table columns are as follows: - All architectures - See Section "6.3 Labels as Values" of GCC_MANUAL. + * - Binary constants + - ARM64, X86_64 + - See Section "6.65 Binary Constants using the '0b' Prefix" + Translation Limits __________________ -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 06 18:42:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 18:42:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196400.1514221 (Exim 4.92) (envelope-from ) id 1vdC0V-0003gv-2M; Tue, 06 Jan 2026 18:42:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196400.1514221; Tue, 06 Jan 2026 18:42:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdC0U-0003go-Uz; Tue, 06 Jan 2026 18:42:14 +0000 Received: by outflank-mailman (input) for mailman id 1196400; Tue, 06 Jan 2026 18:42:13 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdC0T-0003gi-KB for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 18:42:13 +0000 Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [2607:f8b0:4864:20::a35]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 692fda02-eb2f-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 19:42:11 +0100 (CET) Received: by mail-vk1-xa35.google.com with SMTP id 71dfb90a1353d-55b26461e78so378177e0c.3 for ; Tue, 06 Jan 2026 10:42:11 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 692fda02-eb2f-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767724930; x=1768329730; 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=CIXoBgSYkP/sd1BWOcNCLESjfDQLcEW6GaW2Kbu8M0A=; b=hMZnsy9DVqeMNmruFPZPrxXb2LakZ7LLMiI8vAw1wckJNqciu9MjIqzJhhr5uJxJK7 aui2rIJ6jsi0xiuNWTVPiT2NCxckQvIab0VIBnRO1x2ew5KM627xW3KTge8x83WTCztk xi9USpZ6yWoI44w2CcxC6xVhNxR682yXGwdBJNJ0AWxKVMDGK05weGv5iPmXm1soKrlf Pp0GWth6ljjKL9z6zex3CNhee9a5DGxU3OSHXLmZgu+RR3mtmqbQzgKUfCZ0W5ucTrSa lhCcSwCGYTNci5KXbOMCU+3AbYqeVhjqh5MSUfpwMEuTEUVpZX7qXFt8GBHHzwdMfZwI 3mLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767724930; x=1768329730; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=CIXoBgSYkP/sd1BWOcNCLESjfDQLcEW6GaW2Kbu8M0A=; b=ZHvIkMl36Jaxl5RqABsRTNuEMqLtMHmfoau0cDykFtEDSbbJyJMusVFknDz5a05v4X p8Z5Uv78zuZ5eJnDv638ndV2avKLwjTPy5l85Vsl3vZ9twqGXXJt2HGbqFsYnDK4PVSm 8UYBik3fo8HClRQ8K5+iG/yfAf1Kh90lcKbzQMgDTPvW0XMpk0G6GdCq6q2kXB00Jwe7 kTufbMHNgcDywV5A9UASghit4/Cl0+0hAUr5PHpueAbfdC3/iKbVbwQKPviMXizI5Ixn M5cO/FfZfSXHOh9U5ZHFM9l/xHJtJEAzf9R6n5fmzjLEPvuJiVOdrpuPP36IeZBMMC8g /Buw== X-Forwarded-Encrypted: i=1; AJvYcCVkknHWuLVH4CJCQi3ZN2NxqcSZzfGrUZY/s1QjMdLHgxpAA3/7Ni4TsF4EIpc2+ilBh7PeRPQr3Pk=@lists.xenproject.org X-Gm-Message-State: AOJu0YwEgrk3kwxjHFeT7nGgzwY9jB9MAj3VLTuNVTqTcrOZ/B0vZMwa U9f50tm4QUNw52mK1IzG2m9V85hg8WbRqy5392x2HD49cRd7Z/up/+OJBuJwBbCrVPp4mAEWndD MQbW+PzWtNWCcZXRLk/3dndyOtvm5Td8= X-Gm-Gg: AY/fxX5NbIuQVULmnkJYAN3CJkoPYwyZWz/zV2wmTHWZEp7wBvj5KsUiwh7hsYb1J5p kd8lO1vYiBQVQfuA29kYQFFLHzChCjXW4fladb+JbQ3AhEKq2kbMOQZOuvtRSeNZrIQIqg5h8oK 8z/1UiynfvfNoOOocCviz6XObyVUZIP3aWh/vJQ8zWaXqnL7cjFadypiLPBg/+lqJI7l/afSnLp /7K6scdzi8KOVL6W7BKi0gc2tpYHminRwtpISt609KD/Y+8U1rrHyDl5TDfl2O8EJGD8A== X-Google-Smtp-Source: AGHT+IGzdDZdJH61h073/MhkLoyFPUTEGFa4biMd35SsepoUxfnatinjaLQUW4RiSiTNL7sRRTPCzkdKJMTlCl0LUrk= X-Received: by 2002:a05:6102:560f:b0:5df:aff3:c41c with SMTP id ada2fe7eead31-5ec744a174bmr1358450137.30.1767724928829; Tue, 06 Jan 2026 10:42:08 -0800 (PST) MIME-Version: 1.0 References: <20251226225254.46197-1-21cnbao@gmail.com> <20251226225254.46197-6-21cnbao@gmail.com> <20251227200933.GO11869@unreal> <20251228145041.GS11869@unreal> In-Reply-To: <20251228145041.GS11869@unreal> From: Barry Song <21cnbao@gmail.com> Date: Wed, 7 Jan 2026 07:41:57 +1300 X-Gm-Features: AQt7F2qVpIXArh0HsV3sq1RKrv0OCVapLrZHo6-0eziWiogqpS6BzLG8_AyfAb8 Message-ID: Subject: Re: [PATCH v2 5/8] dma-mapping: Support batch mode for dma_direct_sync_sg_for_* To: Leon Romanovsky Cc: catalin.marinas@arm.com, m.szyprowski@samsung.com, robin.murphy@arm.com, will@kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Ada Couprie Diaz , Ard Biesheuvel , Marc Zyngier , Anshuman Khandual , Ryan Roberts , Suren Baghdasaryan , Tangquan Zheng Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 29, 2025 at 3:50=E2=80=AFAM Leon Romanovsky w= rote: > > On Sun, Dec 28, 2025 at 09:52:05AM +1300, Barry Song wrote: > > On Sun, Dec 28, 2025 at 9:09=E2=80=AFAM Leon Romanovsky wrote: > > > > > > On Sat, Dec 27, 2025 at 11:52:45AM +1300, Barry Song wrote: > > > > From: Barry Song > > > > > > > > Instead of performing a flush per SG entry, issue all cache > > > > operations first and then flush once. This ultimately benefits > > > > __dma_sync_sg_for_cpu() and __dma_sync_sg_for_device(). > > > > > > > > Cc: Leon Romanovsky > > > > Cc: Catalin Marinas > > > > Cc: Will Deacon > > > > Cc: Marek Szyprowski > > > > Cc: Robin Murphy > > > > Cc: Ada Couprie Diaz > > > > Cc: Ard Biesheuvel > > > > Cc: Marc Zyngier > > > > Cc: Anshuman Khandual > > > > Cc: Ryan Roberts > > > > Cc: Suren Baghdasaryan > > > > Cc: Tangquan Zheng > > > > Signed-off-by: Barry Song > > > > --- > > > > kernel/dma/direct.c | 14 +++++++------- > > > > 1 file changed, 7 insertions(+), 7 deletions(-) > > > > > > <...> > > > > > > > - if (!dev_is_dma_coherent(dev)) { > > > > + if (!dev_is_dma_coherent(dev)) > > > > arch_sync_dma_for_device(paddr, sg->length, > > > > dir); > > > > - arch_sync_dma_flush(); > > > > - } > > > > } > > > > + if (!dev_is_dma_coherent(dev)) > > > > + arch_sync_dma_flush(); > > > > > > This patch should be squashed into the previous one. You introduced > > > arch_sync_dma_flush() there, and now you are placing it elsewhere. > > > > Hi Leon, > > > > The previous patch replaces all arch_sync_dma_for_* calls with > > arch_sync_dma_for_* plus arch_sync_dma_flush(), without any > > functional change. The subsequent patches then implement the > > actual batching. I feel this is a better approach for reviewing > > each change independently. Otherwise, the previous patch would > > be too large. > > Don't worry about it. Your patches are small enough. My hardware does not require a bounce buffer, but I am concerned that this patch may be incorrect for systems that do require one. Now it is: void dma_direct_sync_sg_for_cpu(struct device *dev, struct scatterlist *sgl, int nents, enum dma_data_direction= dir) { struct scatterlist *sg; int i; for_each_sg(sgl, sg, nents, i) { phys_addr_t paddr =3D dma_to_phys(dev, sg_dma_address(sg)); if (!dev_is_dma_coherent(dev)) arch_sync_dma_for_cpu(paddr, sg->length, dir); swiotlb_sync_single_for_cpu(dev, paddr, sg->length, dir); if (dir =3D=3D DMA_FROM_DEVICE) arch_dma_mark_clean(paddr, sg->length); } if (!dev_is_dma_coherent(dev)) { arch_sync_dma_flush(); arch_sync_dma_for_cpu_all(); } } Should we call swiotlb_sync_single_for_cpu() and arch_dma_mark_clean() after the flush to ensure the CPU sees the latest data and that the memcpy is correct? I mean: void dma_direct_sync_sg_for_cpu(struct device *dev, struct scatterlist *sgl, int nents, enum dma_data_direction= dir) { struct scatterlist *sg; int i; for_each_sg(sgl, sg, nents, i) { phys_addr_t paddr =3D dma_to_phys(dev, sg_dma_address(sg)); if (!dev_is_dma_coherent(dev)) arch_sync_dma_for_cpu(paddr, sg->length, dir); } if (!dev_is_dma_coherent(dev)) { arch_sync_dma_flush(); arch_sync_dma_for_cpu_all(); } for_each_sg(sgl, sg, nents, i) { phys_addr_t paddr =3D dma_to_phys(dev, sg_dma_address(sg)); swiotlb_sync_single_for_cpu(dev, paddr, sg->length, dir); if (dir =3D=3D DMA_FROM_DEVICE) arch_dma_mark_clean(paddr, sg->length); } } Could this be the same issue for dma_direct_unmap_sg()? Another option is to not support batched synchronization for the bounce buffer case, since it is rare. In that case, it could be: diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index 550a1a13148d..a4840f7e8722 100644 --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -423,8 +423,11 @@ void dma_direct_sync_sg_for_cpu(struct device *dev, for_each_sg(sgl, sg, nents, i) { phys_addr_t paddr =3D dma_to_phys(dev, sg_dma_address(sg)); - if (!dev_is_dma_coherent(dev)) + if (!dev_is_dma_coherent(dev)) { arch_sync_dma_for_cpu(paddr, sg->length, dir); + if (unlikely(dev->dma_io_tlb_mem)) + arch_sync_dma_flush(); + } swiotlb_sync_single_for_cpu(dev, paddr, sg->length, dir); What=E2=80=99s your view on this, Leon? Thanks Barry From xen-devel-bounces@lists.xenproject.org Tue Jan 06 18:53:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 18:53:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196412.1514230 (Exim 4.92) (envelope-from ) id 1vdCBL-0005KZ-T7; Tue, 06 Jan 2026 18:53:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196412.1514230; Tue, 06 Jan 2026 18:53: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 1vdCBL-0005KS-Pu; Tue, 06 Jan 2026 18:53:27 +0000 Received: by outflank-mailman (input) for mailman id 1196412; Tue, 06 Jan 2026 18:53: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 1vdCBK-0005KM-M5 for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 18:53:26 +0000 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170100009.outbound.protection.outlook.com [2a01:111:f403:c107::9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f99f84fd-eb30-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 19:53:24 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CO1PR03MB5844.namprd03.prod.outlook.com (2603:10b6:303:9c::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Tue, 6 Jan 2026 18:53:20 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9478.005; Tue, 6 Jan 2026 18:53:20 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f99f84fd-eb30-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=W7NB1+brIec66z4pEkpsDLpl7N7eQC9LbYIjDg1GY93bOVbMdcKDgNeHL1zSFZMsG8YJYOj6lZg1OQS5dBHH6FMl6b7mWvDG7fsXY04e++2vm6CWUROzHPjHudSOjGa57qVeBzbvC8yGDq4WYSe5Y/YbcDpFfEgeW8RXWVvkUDl1hRe6zmX9GqLoQw/+4+PM3aAfHish8sWm+gqPJW8K/pTZy6KzTINtVvB3gJVRTKRgTzovGD8cWs6OQ73rONYIIWlfDEl8+1LXA4Mtdi8Zsivn4ARuzCIM5HwE+nRpHkSeKWO98P15Av4g0p5VlRI3lYbv/o9/mi1XxqfpKaes6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lEkWKgZsRK9tGzOoVFDJWIcu9E7/TeEa6oN39ecUl9U=; b=IsdXpMg4eL3MzYPGm/vE/qouUte1YSR/oHMRxpHYEHHsD8r8qH9cMbRFC8thT0zGzdo46V5PhVXB1DpZqMKfT/TTOSNEdOZlmXLl0yqBrDyfd4R5I7lZ29fVId9ljtb5fZjTpEcXtp5TCHsgNIRCxlPyUMIJRQLscqkWrrKDuKJ1fcR/OzhJQrSOZ5FeyuewQbUke+A8iZ0EnlBVew2kQRk0pTSxVtswRuV9Mtbk0byjO3oWTcONHMmwfuU12Z5JFIa9b4mAk/yw4eQVqIkIw//zA/o18cz8/83bXKIc3suemHL5S8/S+dBcrlt1/IMPXKum/GGVzhyBVLrWKQzOTw== 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=lEkWKgZsRK9tGzOoVFDJWIcu9E7/TeEa6oN39ecUl9U=; b=b2FTxdzUziOTjtvNHDApPHxEuc0PJ6up2K5owOI/acfCOBFJnVk4LfOwMWxAYHZcgSkDbBjkgwmU21ZqQNeylz3Prd/MHv6CgoYu2FL0LnhLqzCM64gqbHMA6HIPszk3vSMrQ6MJkaJeyTlApKSxDMDk3XyWmRaSzPB7zJbu0Ak= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <44781ed1-33ea-4438-9125-86557388ff24@citrix.com> Date: Tue, 6 Jan 2026 18:53:16 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Nicola Vetrini , Doug Goldstein , Stefano Stabellini , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] misra: allow using binary literals in c99 as an extension. To: Nicola Vetrini , xen-devel@lists.xenproject.org References: <30bb474fbb0e9236728fad9515bca4d160d594b3.1767721635.git.nicola.vetrini@bugseng.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <30bb474fbb0e9236728fad9515bca4d160d594b3.1767721635.git.nicola.vetrini@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0110.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2c3::14) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CO1PR03MB5844:EE_ X-MS-Office365-Filtering-Correlation-Id: 7109b04b-b1a5-4d50-d5cc-08de4d54dc3a 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?eFdHR2RlSEJVd2pTVy9acUpwdHM2b01KdGpTYUQrR2x2TjBSY3F0VmN2MHo0?= =?utf-8?B?Z1VqbnhCcjFGM1p4UTBtZlIzTE8raTdZRTcrakVRYmQ4WTJ0V0N2ZWFNbEhi?= =?utf-8?B?NzlDNGFHMVp6aEswQWMyYkhIVHFUQ3RKdjVwbHp2OVpoVmNwZWpTY0Fwdlpm?= =?utf-8?B?VG8xSVFjLzd0NE1ZWHc0aWZDaFpKMzRaL210cGFRQWx1QkIrS2N2ZHhkSEgz?= =?utf-8?B?c1lJcFI5NEpyMUNQUlJIeFFIRXdPQk5BMFlnSnFkYVc5cDhkTGVNMjdna0ZV?= =?utf-8?B?U1NBR1dzUkJxZUtEN1VJUzBBRTBFeEhLcnpSVFlzQ1NtelNrREIrUGpXajdO?= =?utf-8?B?R3ZyRVJDaHg0Y1RMOERzS2I2WWNPUmtXbkk4TVYxdURoaU1abzVZNEJqN2ZM?= =?utf-8?B?dDM2cUJqaGxvaDd6b1luMVBIOTdidjQ5YnFKR2h3S05acjVmL0trdWhlMG5j?= =?utf-8?B?T0gydzdDcHFYUC9CcFVzZGJPL2pBRGdUZ1RPQm5nTVZzMXZhRkMrTmgxK3J1?= =?utf-8?B?VEtNNkhmRTRTRG1WaytvOXZXVTRrVzVLaTVZYlIwK3dUUGNKdGFYQTEremZT?= =?utf-8?B?Zmc2bTZKS2l1ZlRibXdiQ2F2elYwN0Ftc2RheVV2dmIrRGlCc2RnSXFHbkNE?= =?utf-8?B?bCtoQ1piSHByUEdsazZDNUFZSFBiMVRvdHVxa2RueDVxaEEzb1NiL1d5TjdO?= =?utf-8?B?Y0xwUGViNENuUkxycHNiMmlaZWxxSnRmNG84aTMxV1BnR2Q2Sm1HOG5ja3Qw?= =?utf-8?B?cE5UUER0L2VoSlRXdjNmNHMzNEVkWjlkMStwcjZnSjBDcE5URndLYm1JT1hE?= =?utf-8?B?YTN1c2UrenJBSkhjSC9aOWFGbURhZmpVT3l5TW9mT2RyM2d0T1V3K3NYTHFp?= =?utf-8?B?dnBTN2h0TWlvV3N3Q2pFOThPd1lVMTEwOXFrSzhCVzVnM25qTnUyeFFoODZD?= =?utf-8?B?V0tqWk9pREJVZVU2eVRjLzUyZE1EOHdPMUxQN3hWUmNaWXZnb1A5M0FtVDdN?= =?utf-8?B?VHRkUWNxcFhNVVRaOUF1MlFPQnJHTFBtTHRhYmRsL2VMS1htaVY4VlR5YW9k?= =?utf-8?B?VEJnTDdialA3T0VQQ3dpU0RXTE5DRnVPUzlObmIvR3ZNTU9OTFozWmhiQ09D?= =?utf-8?B?Y2ppZ0dZTnRxL1M4U2NnakhoWFRzUENhdXRmbGovZVpSb2hNeHROdi9UbXJa?= =?utf-8?B?QVBjc2NYWDNYNVFCRmdJV0h1ZXpYeXVNc2YzNTNlUzFINC80ZVBYQlJWT3hY?= =?utf-8?B?WUoxdk5hK1hMVUJmUHlybkVYcWZoNGxySzF1Tm1UUllmOGYvbzYvOXh3WndO?= =?utf-8?B?a3NEL2FXQTRRRzYyL0VXWTl4NTRIemtxb2Q4VWRnZldEUHhYeFVNWngyUnI4?= =?utf-8?B?bCtTS01IZHg1M1kvWkFKTUNPNHdQR0VCQXpwcThBY09LWFdVNzNBNTBaajVS?= =?utf-8?B?UkZURlgzbHF2WEg1VWxyaEhwTDVJdUZNNDJvWWVYWHcwaFlzbyt3bWxuV0h4?= =?utf-8?B?enVSV1l2Nm9kY1oxKzJwekVrUGs0YW9GaEZPT1N3SzBxeEVJVjdmTFNjNVZq?= =?utf-8?B?NGVWT2RKUElFYzNWamEvZnRDcGlrcDREVFFSbGVPL3VpWlBJYlpIZDRTdjcz?= =?utf-8?B?aWNKQmg3RFlRdGhOeHVybkYxSVI4WVVrbnRzSENHS2dpZ1JubCtTL1hzWU5Q?= =?utf-8?B?VHJ3WkxjSy9rREdyQlYxM1FWK3MxNC94eEVKV25pdHFXYjFvRUFjbEkzYUpW?= =?utf-8?B?SS94aUc5TmtlVzFXeEdtRVprWjJ6aEZLUUlTSG93ZXY4elBINTdEVGpobGVU?= =?utf-8?B?UXByZ2lYZ0tOWmdjN0xWY0gzS09WTG1XeXNHNlhxZHFRTFN4UndQNFpmeFdU?= =?utf-8?B?S2NWc09Vc2VnVHh4NjcrZHhlQlhLV1p6aXNxRFVFYjE1cmhJam1pcVNTdDhY?= =?utf-8?Q?wrZjmR8/8FdUhsrLSqH1hsVBHCpcHf0X?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TGd6NWdOMi8wV2Q4djBIS2l0bWtYZ1JJcTlua0NXVEYyTUpFL055aEthQzUz?= =?utf-8?B?eE9WMHJIalltdjFGQ0dob2lqV1Q3ZEhIK05BdWtFWVMrbzdMOTBDUFhKNmwr?= =?utf-8?B?c2M3ZG5xNHZYQ0lwaERuQVMzVHJiakZNNDFUdEUvVVFtZVJFSVR5VE5QRW81?= =?utf-8?B?Wk93d0dqZWE2T1U1cm9OWWtZRTBUYURHNnY4cDRZZW9BeU9rNFZGZTNFaGJB?= =?utf-8?B?NVJ1QWRvRDJreFB5czNlNFdzV1UxcmljQVQreldQM3U4OFg4VmtBc0RGK082?= =?utf-8?B?dUxhNmk4TEROc0luTVZ5M1gvQjlXbkM5aFVaNlZ6RXNJN0czaUVRemNpc2lU?= =?utf-8?B?OC9YODBCYmw0WnJWRHBsN3JFWXJSVWZaZlU4Y1hKWEVhMGFmTmVDWlZud2Z2?= =?utf-8?B?RWhQeTdBRGdWVHJLcTFqdGxkYzFGQUhsNmVPU0VwWGdOcUc5YXNWWUtLOTZW?= =?utf-8?B?Zlc2OVdxRmFlMlZ4YXNwZzMvbmc1YmVCdTUyZWFIak94K2dUanllQmxHMzV0?= =?utf-8?B?RUpuYzZ6MTJsQWc1N3VMWDUzajBNRTJmMUNnM2hCVWgyTmFGcDg4Y3J6L3Ni?= =?utf-8?B?NDFPalVWaVZGdzVRV1hmN2hYcGp3VVJDaklmZDNBR3ZrOVlzTGxnSEgxY3B2?= =?utf-8?B?WEpGa1RnZ1hzUXVxekNJK3Q2blgyNndETThleGc2TGIzazA4SFg2amtBMEVl?= =?utf-8?B?ekxMMEhKOTZYb0R2OXdjQVQ4TkE3NUd0VTlwSElRU3Z1eitCMnhEcUtQSlFI?= =?utf-8?B?NkhSaVAwSVNudjZHNzVjRHFCeEdYV0lXTzM3aGxqVVhGWTFmcjlsV0pTOHRo?= =?utf-8?B?cmtFWWxjUkdweDN0enlMdSt6dkdYclVHZytoTjdMYWhkQUtiMUcyNnpUd2RU?= =?utf-8?B?OHRKcGVSVWU4emF6WGtNSEJoT1VhUHgrVWJDS1lOQ2lDNlNLc3ZtYTF1b3Va?= =?utf-8?B?bFdWbEp0UENuUGdpZENmcWwxcHNHU2FmRkxDN0xlTlBSRG93eThhUTBoeGIz?= =?utf-8?B?VTFKdjFnYXNGU0N0dkVlMjIxK3VPdVNBMy9EQlhYUUV2V0MzeDRmU2dtcElz?= =?utf-8?B?OXVyWng2TEVmaGhkcXd5L0NsaWM4cGdTZnd1YUFMMnRMbHlIOE1raG1LUGJF?= =?utf-8?B?YVVOTlkrTmpKb20vMjJGVElGVXQrNGdHNkRma0R5Z3JZN0VmUCtTWmRrK2h4?= =?utf-8?B?OTVIS0hQUnpBbDV3KzJtVTFiSXcwbkQyOVEzd0ZJWG5hR09FaVIzbW8xUmdi?= =?utf-8?B?cTFSTlZvT0xPTmo5Tk5QRGpvNnR3ajZVend0dEVnN3BNMUZIYnVjb0hPdlRp?= =?utf-8?B?dDhrUGNKdmxhRjB0a3hvNjgyN09tM01hdGhUb242U3dpdVlSSnVvR0JrTkxt?= =?utf-8?B?R0QzMW9HWFNhODhWOUFHMndEdFBYZlgxK1F0V2ZGbHZIeTd2UnpYSVNQZngy?= =?utf-8?B?dnlMcEhjWGErVTR1eXpJRTR4K3pudHh0ZWlDVWR4L0U1N0tLV1pZTGRJa3VW?= =?utf-8?B?bTVLbDF1V3V4NTJidTY2NGhoV0RqZXNDQTNuYlltRGpnZmQwZHU0NWRrMVIy?= =?utf-8?B?d1B6OW94enBNdGVoWU5PeG9ieHE2SlYwUThtb1haNjFCOXRmZld4c253NzI5?= =?utf-8?B?UEhrQlUwNXZOc0k1NzlNaEhhendXZEU1ZGZhOEx0NlFmZndXVkM2ZXhTZkI4?= =?utf-8?B?a3JUQ3RmMTNQc1BiTG1UcmxxOEdLVlB6QXlkYzBzRjgvL3FCMmkvb2piYWJt?= =?utf-8?B?SVdzMHdkNlViK0ZYYWViVmh4c1NzWnV0Ym8wL3BMS1VTcURtYU80TVVYeXor?= =?utf-8?B?Q284V243WUVRUUcwSlZaSmw4OEdKQXhoN0N0ak1DdGFBRW4zKzhPWFIwYXNs?= =?utf-8?B?NTVBZUg2Q1FKbnRGdUZBNExYSUg1QmJ4aEsxWkViVG44TGExa1hlelNZZ0V6?= =?utf-8?B?eG0yMTJBNk9oaG1WYjNNSGNraGJyZjVuL204RkhUbVlxNi9URnc5VHV3S3Jm?= =?utf-8?B?SDBJY2N6RjVHOGJiQWN6b0lmejhzbUtJT0dwMWEzL1RoYkRwOUdEY1NqdGo3?= =?utf-8?B?aFdhdlEzOCt5eFdNUWk0NzVya00zM2xxdGFtZ01LZmNTdzZCSlRPYzVGTjV2?= =?utf-8?B?SzJQR3VLa250a2hZcGJsdFF3dTB1cTlKOXhtYW5WMHJFUTQ5ak5oZm5HK1Zq?= =?utf-8?B?eEY1MmhUM2FLNzFGcWdaWlhnUmp1d3V1TVFNWkdzdjJYWHRWaUw3QmRtZVA0?= =?utf-8?B?VXdySTRVdzNET1V2cUxPUVozYmc2MUpaamE5RUFRbmJKRDRveFc1SU5wR2E1?= =?utf-8?B?QVg5eFpsZ09NYnpFWUhsa0I3Mi9xdFlCbkNpUTVxVDBaeU53QksyZFhXQWdS?= =?utf-8?Q?HjzX8JW0jv9sYmzU=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7109b04b-b1a5-4d50-d5cc-08de4d54dc3a X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2026 18:53:20.2091 (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: ehkaMo0Nvyppf1dvDadQt3bZmFnlSa0yKXdWvoHUUDu6UNinuoZVuLqa4ujAreou2DzXekQHV67HUi+Bap3GAOhRFb7VMzVrwJetDu3VnNY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB5844 On 06/01/2026 5:50 pm, Nicola Vetrini wrote: > From: Nicola Vetrini > > There is consensus towards using more binary literals in Xen, > so they are enabled both for X86_64 and ARM64. > > Signed-off-by: Nicola Vetrini Reviewed-by: Andrew Cooper Thanks for looking into this. From xen-devel-bounces@lists.xenproject.org Tue Jan 06 19:03:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 19:03:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196428.1514241 (Exim 4.92) (envelope-from ) id 1vdCLI-00074a-Sx; Tue, 06 Jan 2026 19:03:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196428.1514241; Tue, 06 Jan 2026 19:03:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdCLI-00074T-P8; Tue, 06 Jan 2026 19:03:44 +0000 Received: by outflank-mailman (input) for mailman id 1196428; Tue, 06 Jan 2026 19:03: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 1vdCLI-00074N-4V for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 19:03:44 +0000 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [2a00:1450:4864:20::32c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6a1adbe6-eb32-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 20:03:41 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-477563e28a3so926535e9.1 for ; Tue, 06 Jan 2026 11:03:41 -0800 (PST) Received: from ?IPV6:2003:e5:8704:4800:66fd:131f:60bd:bc29? (p200300e58704480066fd131f60bdbc29.dip0.t-ipconnect.de. [2003:e5:8704:4800:66fd:131f:60bd:bc29]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5fe83bsm6093014f8f.38.2026.01.06.11.03.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 11:03:40 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6a1adbe6-eb32-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767726220; x=1768331020; 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=E+Xu68DwFwkgG0/Z5NJvQPYycTqVZCEroAP5k4c0kJI=; b=Gu3RjdcFEBDevzEY+KyBiw+IJf6FivLzpzSLbkAuUbcKvnppbJFfKIT29M8YPPasSM GbrFYo9oOEllss6hiC0NAISm/HiOqxDp0aT0g0sL+HgS8BV+MdKaS2pG9BqFoe5jXxlO HYDCLugoHQzKbn7/NgEUfv0k2KpUmupu+JD7Y6Pwk/mskazJ4uUFgimSBBpzb6csD0lz V5Z/iAw5BOCqc2+4OnsQ3aINDW3whc1mQQH60Z7YfCRcecLeTBWMcYGRKLwTYBN22VWL iSQkiYkCSNaYoWiYEU3DuvLDRZZR62dmnH4i8mVBL1EViHWNRdYS/xCtv+qJpXXj2x3t K63Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767726220; x=1768331020; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=E+Xu68DwFwkgG0/Z5NJvQPYycTqVZCEroAP5k4c0kJI=; b=gcV7EWpkPaT1fSnJYi4KF9H7hGs//HtPc41XDJWHwcn2xeHxNC/wL/d7mZbaTJVTb6 Yco9cT3leH6w3qGP8zAMzSD/aPCAoPDXb8sZSM4+/G2TsIgHZuurozryuUooHN/VMHEF eetoh17z1xeQLK6ybevjPeu/vSjDlgEaFxgDIpg/KPWqRmHLF94bG0ampAJgbBpeP43N q4RhZnlY9IIhueLHUsS0X+nAWKKlZCiJES9a0yVSSvB8xPo3P7AAD+Hd5J7ds933x3Y1 qjW4ZwM1W5uxXqaWFT4GWIYr4l5pDKzF29oOPqNrimtxKPdYMj7RTERLryRq9LX//I9K cTaQ== X-Forwarded-Encrypted: i=1; AJvYcCVaQxianzqAjWrPfg00bzHuSxOUSys8N7Gv9C2TDHt+D95wm78eHM4kohKAbCwlOrutXQILs6v3obc=@lists.xenproject.org X-Gm-Message-State: AOJu0YyHDi+B85QNAs90+tYUGZ0bmQZpILPQHmyHhMDXzCV55jFRGkvL cjGkjAs71/xdtmx9QmejCVJLZHZ8GQPzFVcHYvlv/QVmDkn1Likj4BpWRbxWh1Ow/Hn+MYN7sGH NEBZU X-Gm-Gg: AY/fxX6bKPVYxSJkUFCf2dBTtaTMEfaJ1vdTY3jGqj0kihD770P4D1kP2pJLcazeuZf x840uSaSdxwojC0uMd//pIcIGV97NwBRujL1rdb4GZGVAHefgeOr4xLi+l8BO8FDdPyAQLzdeXn 2zjo21t/b6Fz4da3F/tY4qvz1bvZKleb9/J6WI1xqK3cgBn7uqNThljl+WYZLm3+yE3ovqL1nhQ 7S7tQtJCUiCJVZoZvK8mhn/+M9ujVfYQsvwoo/LTxuW6ftAsLMwGfm5rLtxThk70NAW7K3Lc6en 2EHxdiaZe0QuyDQVkCX/N5y8vf4pKBgeGOKCp5fot2JHbWHhR6URVBneeQlc6IomxNLSLLNOxxX lLmzwpCcsEDL07sQCTOJeEWNWIwmCkbpDuHtXSudeD733dqPG4FhxCeyjVsGCgeX+uvjQBSnpw0 RA3FF3G8PICVIIe8Xzn3ECZu/aiA4mX5pRUARQTNg8aAuuX0i/MhYVV4X4RJ6Y8u7k1Z5XerCOO Ulz6I6w3BVFjejVmMHCEyTAND/ERV5UBqyN1sHclT7Ug2dXTw== X-Google-Smtp-Source: AGHT+IG8bUdVuI3KS2XmPpuQ5KCfWx6gX6ioAPAQUlFi5yYAp+HLTgbxAT8hDsm+XpoIvgYcZw6s/w== X-Received: by 2002:a05:600c:8215:b0:46e:2815:8568 with SMTP id 5b1f17b1804b1-47d8486cd41mr1743975e9.10.1767726220532; Tue, 06 Jan 2026 11:03:40 -0800 (PST) Message-ID: <995f7ac8-0a8b-43d9-9cc7-63622ec52ca1@suse.com> Date: Tue, 6 Jan 2026 20:03:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/virtio: Don't use grant-dma-ops when running as Dom0 To: Teddy Astie , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Cc: Stefano Stabellini , Oleksandr Tyshchenko , Boris Ostrovsky References: <6698564dd2270a9f7377b78ebfb20cb425cabbe8.1767720955.git.teddy.astie@vates.tech> 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: <6698564dd2270a9f7377b78ebfb20cb425cabbe8.1767720955.git.teddy.astie@vates.tech> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------mPWVaRT2wREt8jkdOEqELTr7" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------mPWVaRT2wREt8jkdOEqELTr7 Content-Type: multipart/mixed; boundary="------------omsVVH3QFyb0fambBJ2fQ7w1"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Teddy Astie , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Cc: Stefano Stabellini , Oleksandr Tyshchenko , Boris Ostrovsky Message-ID: <995f7ac8-0a8b-43d9-9cc7-63622ec52ca1@suse.com> Subject: Re: [PATCH] xen/virtio: Don't use grant-dma-ops when running as Dom0 References: <6698564dd2270a9f7377b78ebfb20cb425cabbe8.1767720955.git.teddy.astie@vates.tech> In-Reply-To: <6698564dd2270a9f7377b78ebfb20cb425cabbe8.1767720955.git.teddy.astie@vates.tech> --------------omsVVH3QFyb0fambBJ2fQ7w1 Content-Type: multipart/mixed; boundary="------------RyHkulx8kllKBGfO0OZZGJIu" --------------RyHkulx8kllKBGfO0OZZGJIu Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDYuMDEuMjYgMTg6MzYsIFRlZGR5IEFzdGllIHdyb3RlOg0KPiBEb20wIGluaGVyaXQg ZGV2aWNlcyBmcm9tIHRoZSBtYWNoaW5lIGFuZCBpcyB1c3VhbGx5IGluIFBWIG1vZGUuDQo+ IElmIHdlIGFyZSBydW5uaW5nIGluIGEgdmlydHVhbCB0aGF0IGhhcyB2aXJ0aW8gZGV2aWNl cywgdGhlc2UgZGV2aWNlcw0KPiB3b3VsZCBiZSBjb25zaWRlcmVkIGFzIHVzaW5nIGdyYW50 cyB3aXRoIERvbTAgYXMgYmFja2VuZCwgd2hpbGUgYmVpbmcNCj4gdGhlIHNhaWQgRG9tMCBp dHNlbGYsIHdoaWxlIHdlIHdhbnQgdG8gdXNlIHRoZXNlIGRldmljZXMgbGlrZSByZWd1bGFy DQo+IFBDSSBkZXZpY2VzLg0KPiANCj4gRml4IHRoaXMgYnkgcHJldmVudGluZyBncmFudC1k bWEtb3BzIGZyb20gYmVpbmcgdXNlZCB3aGVuIHJ1bm5pbmcgYXMgRG9tMA0KPiAoaW5pdGlh bCBkb21haW4pLiBXZSBzdGlsbCBrZWVwIHRoZSBkZXZpY2UtdHJlZSBsb2dpYyBhcy1pcy4N Cj4gDQo+IFNpZ25lZC1vZmYtYnk6IFRlZGR5IEFzdGllIDx0ZWRkeS5hc3RpZUB2YXRlcy50 ZWNoPg0KPiBGaXhlczogNjEzNjc2ODhmMWZiMCAoInhlbi92aXJ0aW86IGVuYWJsZSBncmFu dCBiYXNlZCB2aXJ0aW8gb24geDg2IikNCj4gLS0tDQo+IENDOiBKdWVyZ2VuIEdyb3NzIDxq Z3Jvc3NAc3VzZS5jb20+DQo+IENDOiBTdGVmYW5vIFN0YWJlbGxpbmkgPHNzdGFiZWxsaW5p QGtlcm5lbC5vcmc+DQo+IENDOiBPbGVrc2FuZHIgVHlzaGNoZW5rbyA8b2xla3NhbmRyX3R5 c2hjaGVua29AZXBhbS5jb20+DQo+IENDOiBCb3JpcyBPc3Ryb3Zza3kgPGJvcmlzLm9zdHJv dnNreUBvcmFjbGUuY29tPg0KPiANCj4gICBkcml2ZXJzL3hlbi9ncmFudC1kbWEtb3BzLmMg fCAzICsrLQ0KPiAgIDEgZmlsZSBjaGFuZ2VkLCAyIGluc2VydGlvbnMoKyksIDEgZGVsZXRp b24oLSkNCj4gDQo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9ncmFudC1kbWEtb3BzLmMg Yi9kcml2ZXJzL3hlbi9ncmFudC1kbWEtb3BzLmMNCj4gaW5kZXggMTQwNzdkMjNmMmExLi5j MjYwM2U3MDAxNzggMTAwNjQ0DQo+IC0tLSBhL2RyaXZlcnMveGVuL2dyYW50LWRtYS1vcHMu Yw0KPiArKysgYi9kcml2ZXJzL3hlbi9ncmFudC1kbWEtb3BzLmMNCj4gQEAgLTM2Niw3ICsz NjYsOCBAQCBzdGF0aWMgaW50IHhlbl9ncmFudF9pbml0X2JhY2tlbmRfZG9taWQoc3RydWN0 IGRldmljZSAqZGV2LA0KPiAgIAlpZiAobnApIHsNCj4gICAJCXJldCA9IHhlbl9kdF9ncmFu dF9pbml0X2JhY2tlbmRfZG9taWQoZGV2LCBucCwgYmFja2VuZF9kb21pZCk7DQo+ICAgCQlv Zl9ub2RlX3B1dChucCk7DQo+IC0JfSBlbHNlIGlmIChJU19FTkFCTEVEKENPTkZJR19YRU5f VklSVElPX0ZPUkNFX0dSQU5UKSB8fCB4ZW5fcHZfZG9tYWluKCkpIHsNCj4gKwl9IGVsc2Ug aWYgKCF4ZW5faW5pdGlhbF9kb21haW4oKSAmJg0KPiArCQkgICAoSVNfRU5BQkxFRChDT05G SUdfWEVOX1ZJUlRJT19GT1JDRV9HUkFOVCkgfHwgeGVuX3B2X2RvbWFpbigpKSkgew0KPiAg IAkJZGV2X2luZm8oZGV2LCAiVXNpbmcgZG9tMCBhcyBiYWNrZW5kXG4iKTsNCj4gICAJCSpi YWNrZW5kX2RvbWlkID0gMDsNCj4gICAJCXJldCA9IDA7DQoNClBsZWFzZSBtYWtlIHRoaXMg Y29udHJvbGxhYmxlLCBlLmcuIHZpYSBhIGJvb3QgcGFyYW1ldGVyLg0KDQpJdCBpcyBjb21w bGV0ZWx5IHZhbGlkIHRvIGhhdmUgYSB2aXJ0aW8gZGV2aWNlIGluIGRvbTAgd2l0aCB0aGUg YmFja2VuZCBpbg0KYSBkb21VLiBZb3UnbGwgbmVlZCBncmFudHMgaW4gdGhpcyBjYXNlLg0K DQoNCkp1ZXJnZW4NCg== --------------RyHkulx8kllKBGfO0OZZGJIu 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----- --------------RyHkulx8kllKBGfO0OZZGJIu-- --------------omsVVH3QFyb0fambBJ2fQ7w1-- --------------mPWVaRT2wREt8jkdOEqELTr7 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/Ey8FAmldXIsFAwAAAAAACgkQsN6d1ii/Ey9f ZQgAgmCrByeGPni0rvsTkjNLY7fpws/bJL1Eaej2na2F+fUBfpwS+DB9Irek8aCyh0FlF7uVP4do 5D1DOBU8c28SKCuQlDYs6rRzk3SySvEgW8+Lwn9d6HS7zbDtWwQqnIBh6oDlwP2w6HPYnXpgBOn0 2kS/nAvaVNvXnUAA81YSWYhf4rUBpFvdnD88y31QzZLi+6oh8tPmimIIAEZNNj2Np/v5SElRhrY0 Qsuu6oGS/AAnh103zdGiTGQjrvV5JeBRPou6V8JmgGhrrFAJdMshoYYXwzYc2jONpYTv9vDy+lxX pWFodW9gBxL5mwICwC1AOClBAdaBMMNFnJtdRdrV/g== =zU/j -----END PGP SIGNATURE----- --------------mPWVaRT2wREt8jkdOEqELTr7-- From xen-devel-bounces@lists.xenproject.org Tue Jan 06 19:12:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 19:12:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196437.1514251 (Exim 4.92) (envelope-from ) id 1vdCTT-0000IY-Mm; Tue, 06 Jan 2026 19:12:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196437.1514251; Tue, 06 Jan 2026 19:12:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdCTT-0000IR-Io; Tue, 06 Jan 2026 19:12:11 +0000 Received: by outflank-mailman (input) for mailman id 1196437; Tue, 06 Jan 2026 19:12: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 1vdCTS-0000IK-GZ for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 19:12:10 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id 98718ec2-eb33-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 20:12:08 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C9CDB497; Tue, 6 Jan 2026 11:12:00 -0800 (PST) Received: from [10.57.46.241] (unknown [10.57.46.241]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1C7853F5A1; Tue, 6 Jan 2026 11:12:04 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 98718ec2-eb33-11f0-b15e-2bf370ae4941 Message-ID: Date: Tue, 6 Jan 2026 19:12:02 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/8] dma-mapping: Support batch mode for dma_direct_sync_sg_for_* To: Barry Song <21cnbao@gmail.com>, Leon Romanovsky Cc: catalin.marinas@arm.com, m.szyprowski@samsung.com, will@kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Ada Couprie Diaz , Ard Biesheuvel , Marc Zyngier , Anshuman Khandual , Ryan Roberts , Suren Baghdasaryan , Tangquan Zheng References: <20251226225254.46197-1-21cnbao@gmail.com> <20251226225254.46197-6-21cnbao@gmail.com> <20251227200933.GO11869@unreal> <20251228145041.GS11869@unreal> From: Robin Murphy Content-Language: en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2026-01-06 6:41 pm, Barry Song wrote: > On Mon, Dec 29, 2025 at 3:50 AM Leon Romanovsky wrote: >> >> On Sun, Dec 28, 2025 at 09:52:05AM +1300, Barry Song wrote: >>> On Sun, Dec 28, 2025 at 9:09 AM Leon Romanovsky wrote: >>>> >>>> On Sat, Dec 27, 2025 at 11:52:45AM +1300, Barry Song wrote: >>>>> From: Barry Song >>>>> >>>>> Instead of performing a flush per SG entry, issue all cache >>>>> operations first and then flush once. This ultimately benefits >>>>> __dma_sync_sg_for_cpu() and __dma_sync_sg_for_device(). >>>>> >>>>> Cc: Leon Romanovsky >>>>> Cc: Catalin Marinas >>>>> Cc: Will Deacon >>>>> Cc: Marek Szyprowski >>>>> Cc: Robin Murphy >>>>> Cc: Ada Couprie Diaz >>>>> Cc: Ard Biesheuvel >>>>> Cc: Marc Zyngier >>>>> Cc: Anshuman Khandual >>>>> Cc: Ryan Roberts >>>>> Cc: Suren Baghdasaryan >>>>> Cc: Tangquan Zheng >>>>> Signed-off-by: Barry Song >>>>> --- >>>>> kernel/dma/direct.c | 14 +++++++------- >>>>> 1 file changed, 7 insertions(+), 7 deletions(-) >>>> >>>> <...> >>>> >>>>> - if (!dev_is_dma_coherent(dev)) { >>>>> + if (!dev_is_dma_coherent(dev)) >>>>> arch_sync_dma_for_device(paddr, sg->length, >>>>> dir); >>>>> - arch_sync_dma_flush(); >>>>> - } >>>>> } >>>>> + if (!dev_is_dma_coherent(dev)) >>>>> + arch_sync_dma_flush(); >>>> >>>> This patch should be squashed into the previous one. You introduced >>>> arch_sync_dma_flush() there, and now you are placing it elsewhere. >>> >>> Hi Leon, >>> >>> The previous patch replaces all arch_sync_dma_for_* calls with >>> arch_sync_dma_for_* plus arch_sync_dma_flush(), without any >>> functional change. The subsequent patches then implement the >>> actual batching. I feel this is a better approach for reviewing >>> each change independently. Otherwise, the previous patch would >>> be too large. >> >> Don't worry about it. Your patches are small enough. > > My hardware does not require a bounce buffer, but I am concerned that > this patch may be incorrect for systems that do require one. > > Now it is: > > void dma_direct_sync_sg_for_cpu(struct device *dev, > struct scatterlist *sgl, int nents, enum dma_data_direction dir) > { > struct scatterlist *sg; > int i; > > for_each_sg(sgl, sg, nents, i) { > phys_addr_t paddr = dma_to_phys(dev, sg_dma_address(sg)); > > if (!dev_is_dma_coherent(dev)) > arch_sync_dma_for_cpu(paddr, sg->length, dir); > > swiotlb_sync_single_for_cpu(dev, paddr, sg->length, dir); > > if (dir == DMA_FROM_DEVICE) > arch_dma_mark_clean(paddr, sg->length); > } > > if (!dev_is_dma_coherent(dev)) { > arch_sync_dma_flush(); > arch_sync_dma_for_cpu_all(); > } > } > > Should we call swiotlb_sync_single_for_cpu() and > arch_dma_mark_clean() after the flush to ensure the CPU sees the > latest data and that the memcpy is correct? I mean: Yes, this and the equivalents in the later patches are broken for all the sync_for_cpu and unmap paths which may end up bouncing (beware some of them get a bit fiddly) - any cache maintenance *must* be completed before calling SWIOTLB. As for mark_clean, IIRC that was an IA-64 thing, and appears to be entirely dead now. Thanks, Robin. > void dma_direct_sync_sg_for_cpu(struct device *dev, > struct scatterlist *sgl, int nents, enum dma_data_direction dir) > { > struct scatterlist *sg; > int i; > > for_each_sg(sgl, sg, nents, i) { > phys_addr_t paddr = dma_to_phys(dev, sg_dma_address(sg)); > > if (!dev_is_dma_coherent(dev)) > arch_sync_dma_for_cpu(paddr, sg->length, dir); > } > > if (!dev_is_dma_coherent(dev)) { > arch_sync_dma_flush(); > arch_sync_dma_for_cpu_all(); > } > > for_each_sg(sgl, sg, nents, i) { > phys_addr_t paddr = dma_to_phys(dev, sg_dma_address(sg)); > > swiotlb_sync_single_for_cpu(dev, paddr, sg->length, dir); > > if (dir == DMA_FROM_DEVICE) > arch_dma_mark_clean(paddr, sg->length); > } > } > > Could this be the same issue for dma_direct_unmap_sg()? > > Another option is to not support batched synchronization for the bounce > buffer case, since it is rare. In that case, it could be: > > diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c > index 550a1a13148d..a4840f7e8722 100644 > --- a/kernel/dma/direct.c > +++ b/kernel/dma/direct.c > @@ -423,8 +423,11 @@ void dma_direct_sync_sg_for_cpu(struct device *dev, > for_each_sg(sgl, sg, nents, i) { > phys_addr_t paddr = dma_to_phys(dev, sg_dma_address(sg)); > > - if (!dev_is_dma_coherent(dev)) > + if (!dev_is_dma_coherent(dev)) { > arch_sync_dma_for_cpu(paddr, sg->length, dir); > + if (unlikely(dev->dma_io_tlb_mem)) > + arch_sync_dma_flush(); > + } > > swiotlb_sync_single_for_cpu(dev, paddr, sg->length, dir); > > What’s your view on this, Leon? > > Thanks > Barry From xen-devel-bounces@lists.xenproject.org Tue Jan 06 19:42:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 19:42:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196449.1514261 (Exim 4.92) (envelope-from ) id 1vdCwe-0004KN-St; Tue, 06 Jan 2026 19:42:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196449.1514261; Tue, 06 Jan 2026 19:42:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdCwe-0004KG-Q1; Tue, 06 Jan 2026 19:42:20 +0000 Received: by outflank-mailman (input) for mailman id 1196449; Tue, 06 Jan 2026 19:42: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 1vdCwd-0004KA-7I for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 19:42:19 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id ce23d1c8-eb37-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 20:42:16 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 01059497; Tue, 6 Jan 2026 11:42:09 -0800 (PST) Received: from [10.57.46.241] (unknown [10.57.46.241]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 259E33F5A1; Tue, 6 Jan 2026 11:42:13 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ce23d1c8-eb37-11f0-b15e-2bf370ae4941 Message-ID: <73c533b9-1315-409f-baad-ef9a46ab6bf0@arm.com> Date: Tue, 6 Jan 2026 19:42:10 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC v2 8/8] dma-iommu: Support DMA sync batch mode for iommu_dma_sync_sg_for_{cpu, device} To: Barry Song <21cnbao@gmail.com>, Leon Romanovsky Cc: catalin.marinas@arm.com, m.szyprowski@samsung.com, will@kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Ada Couprie Diaz , Ard Biesheuvel , Marc Zyngier , Anshuman Khandual , Ryan Roberts , Suren Baghdasaryan , Joerg Roedel , Tangquan Zheng References: <20251226225254.46197-1-21cnbao@gmail.com> <20251226225254.46197-9-21cnbao@gmail.com> <20251227201642.GQ11869@unreal> From: Robin Murphy Content-Language: en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2025-12-27 8:59 pm, Barry Song wrote: > On Sun, Dec 28, 2025 at 9:16 AM Leon Romanovsky wrote: >> >> On Sat, Dec 27, 2025 at 11:52:48AM +1300, Barry Song wrote: >>> From: Barry Song >>> >>> Apply batched DMA synchronization to iommu_dma_sync_sg_for_cpu() and >>> iommu_dma_sync_sg_for_device(). For all buffers in an SG list, only >>> a single flush operation is needed. >>> >>> I do not have the hardware to test this, so the patch is marked as >>> RFC. I would greatly appreciate any testing feedback. >>> >>> Cc: Leon Romanovsky >>> Cc: Marek Szyprowski >>> Cc: Catalin Marinas >>> Cc: Will Deacon >>> Cc: Ada Couprie Diaz >>> Cc: Ard Biesheuvel >>> Cc: Marc Zyngier >>> Cc: Anshuman Khandual >>> Cc: Ryan Roberts >>> Cc: Suren Baghdasaryan >>> Cc: Robin Murphy >>> Cc: Joerg Roedel >>> Cc: Tangquan Zheng >>> Signed-off-by: Barry Song >>> --- >>> drivers/iommu/dma-iommu.c | 15 +++++++-------- >>> 1 file changed, 7 insertions(+), 8 deletions(-) >>> >>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c >>> index ffa940bdbbaf..b68dbfcb7846 100644 >>> --- a/drivers/iommu/dma-iommu.c >>> +++ b/drivers/iommu/dma-iommu.c >>> @@ -1131,10 +1131,9 @@ void iommu_dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sgl, >>> iommu_dma_sync_single_for_cpu(dev, sg_dma_address(sg), >>> sg->length, dir); >>> } else if (!dev_is_dma_coherent(dev)) { >>> - for_each_sg(sgl, sg, nelems, i) { >>> + for_each_sg(sgl, sg, nelems, i) >>> arch_sync_dma_for_cpu(sg_phys(sg), sg->length, dir); >>> - arch_sync_dma_flush(); >>> - } >>> + arch_sync_dma_flush(); >> >> This and previous patches should be squashed into the one which >> introduced arch_sync_dma_flush(). > > Hi Leon, > > The series is structured to first introduce no functional change by > replacing all arch_sync_dma_for_* calls with arch_sync_dma_for_* plus > arch_sync_dma_flush(). Subsequent patches then add batching for > different scenarios as separate changes. > > Another issue is that I was unable to find a board that both runs > mainline and exercises the IOMMU paths affected by these changes. > As a result, patches 7 and 8 are marked as RFC, while the other > patches have been tested on a real board running mainline + changes. FWIW if you can get your hands on an M.2 NVMe for the Rock5 then that has an SMMU in front of PCIe (and could also work to test non-coherent SWIOTLB, with the SMMU in bypass and either some fake restrictive dma-ranges in the DT or a hack to reduce the DMA mask in the NVMe driver.) Cheers, Robin. From xen-devel-bounces@lists.xenproject.org Tue Jan 06 19:47:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 19:47:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196462.1514270 (Exim 4.92) (envelope-from ) id 1vdD21-0004xQ-Dy; Tue, 06 Jan 2026 19:47:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196462.1514270; Tue, 06 Jan 2026 19:47: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 1vdD21-0004xJ-B3; Tue, 06 Jan 2026 19:47:53 +0000 Received: by outflank-mailman (input) for mailman id 1196462; Tue, 06 Jan 2026 19: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 1vdD20-0004wx-6c for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 19:47:52 +0000 Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [2607:f8b0:4864:20::f36]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 944edfd0-eb38-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 20:47:49 +0100 (CET) Received: by mail-qv1-xf36.google.com with SMTP id 6a1803df08f44-8887f43b224so16144576d6.1 for ; Tue, 06 Jan 2026 11:47:49 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 944edfd0-eb38-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767728868; x=1768333668; 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=pntXy9Hj0WqvRGVZav4oj27VTA9+7WcxJK6ERgbcGK8=; b=ZDaZ4RmPIURtIIImM+ZQZgpEfTCloZQAiGZ2yEpjOuVLT809UcuuqlMq1S/IxvoOhC 6YKaejwZtEaTfDgBAWgtkotoVsVVhC4Lgr/V87TKcXgilWTjmNtWDGCmh7NdRuJsV2VX EXu+vnpAlRSKk/ZjuV3poz2i2i+LLeSgx1+A9yEGNYlgWzaHLzi9aKVj8jBt7G0BGP9x 8Ql9Z5DQT4RNsb+vvtIqKS3PA1cUNzcxxBpkjZZQZukRTX/Rtg3t/gqLYiuLtavuHrdE uHygjsIfKVEKwkk5wZSTCCtG4TogHuVbyxW/Dn1RoQ4Am7azcM0/iLCwx9PRGKrT+U0o GdKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767728868; x=1768333668; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=pntXy9Hj0WqvRGVZav4oj27VTA9+7WcxJK6ERgbcGK8=; b=ThZs0mbWue2D3hXz5w7X8d4vIJ0sSx/FSgIyGDFDoDctKg1K8iupJfjIHAXz6vOGWw MBp3wvdmjCWKPGqkvyBlxU1sTcpvpRg8P3HBaKLRrduCmrz2NeuYddECvSZB0o+b1ICu 1VFAKs5sFKCILFrLpuoAFkOdfzYw/yE+N337zQqj6YAcfSxojO3gpolwdhr2yieO8DZJ JUc9Y1kuz4E3hPZETY3L5G+VGanegFRSzRhmpXxuqnWg7J1M5brSdyhoqcIVJi1CwZPP vDdDsPeVdvFmuESRmkdwopJn5FPXlwRrNAFS6nOPFyk4qwFdrCw8BlXU2ab7hdbSERfa KFRw== X-Forwarded-Encrypted: i=1; AJvYcCWg/2xxOKXCzMc/e4WgA67a7HfXWR2hYPfTG66LuHeKzajkZbpXfkCd03hBeQOGFntzklIV/cosGCc=@lists.xenproject.org X-Gm-Message-State: AOJu0YyHPUAdlPUq+aPsllIfHqKeV2WXXBgmj/b81YRtZYxIHAJhAeZi +Etk/6wxgLqq4+p952WgoOBZCdzJ16jALj+BXxT2Ig0WvXEVcqmaL3ivO+abjXGqjKh4CcVZbno mqTCK40VVDWfY6OkQLQmHS1hcdMhD+6Q= X-Gm-Gg: AY/fxX5bEZruvw8QT43Kel7bLZC4NsLPZKa2AhWVxTGVjVooRXhX4T0uW29WQolHXdp 6zdCadVXNTZhHMv6YsI0gr3COvMq7jIKQk6YMMSyrbzOj4Cz9a7EIoS3/0fGBykrCcXh+ROZQyA wIsZGxmcwAkYoH0dbcgXYkEnpCgNxsPASACz4cDmocJ+R13IMJ1m6YGd/uhIwT5JBQA2gln+Iwh 2VciBHGC0mDJS9KJtBQ/ob/abwzcUSpLwpcxKPy7obQcl3GwN2wSSNIA0KSfHwJYby25A== X-Google-Smtp-Source: AGHT+IEsDozTTuOpHzQH0xjAygijM9mAO6rgCGg7RgPz/1lUD4/ZMIEqkH9QqpKy9eDQlYCqtEtPfalOfqOAQTgTldI= X-Received: by 2002:a05:6214:622:b0:890:5973:a567 with SMTP id 6a1803df08f44-890841e56d5mr1480896d6.12.1767728867862; Tue, 06 Jan 2026 11:47:47 -0800 (PST) MIME-Version: 1.0 References: <20251226225254.46197-1-21cnbao@gmail.com> <20251226225254.46197-6-21cnbao@gmail.com> <20251227200933.GO11869@unreal> <20251228145041.GS11869@unreal> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Wed, 7 Jan 2026 08:47:36 +1300 X-Gm-Features: AQt7F2rGhHEzeZcOruGijVOJFT9sChymTkhWX1JfhRWGcohbyfQWWuu1bqdVJW0 Message-ID: Subject: Re: [PATCH v2 5/8] dma-mapping: Support batch mode for dma_direct_sync_sg_for_* To: Robin Murphy Cc: Leon Romanovsky , catalin.marinas@arm.com, m.szyprowski@samsung.com, will@kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Ada Couprie Diaz , Ard Biesheuvel , Marc Zyngier , Anshuman Khandual , Ryan Roberts , Suren Baghdasaryan , Tangquan Zheng Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 7, 2026 at 8:12=E2=80=AFAM Robin Murphy = wrote: > > On 2026-01-06 6:41 pm, Barry Song wrote: > > On Mon, Dec 29, 2025 at 3:50=E2=80=AFAM Leon Romanovsky wrote: > >> > >> On Sun, Dec 28, 2025 at 09:52:05AM +1300, Barry Song wrote: > >>> On Sun, Dec 28, 2025 at 9:09=E2=80=AFAM Leon Romanovsky wrote: > >>>> > >>>> On Sat, Dec 27, 2025 at 11:52:45AM +1300, Barry Song wrote: > >>>>> From: Barry Song > >>>>> > >>>>> Instead of performing a flush per SG entry, issue all cache > >>>>> operations first and then flush once. This ultimately benefits > >>>>> __dma_sync_sg_for_cpu() and __dma_sync_sg_for_device(). > >>>>> > >>>>> Cc: Leon Romanovsky > >>>>> Cc: Catalin Marinas > >>>>> Cc: Will Deacon > >>>>> Cc: Marek Szyprowski > >>>>> Cc: Robin Murphy > >>>>> Cc: Ada Couprie Diaz > >>>>> Cc: Ard Biesheuvel > >>>>> Cc: Marc Zyngier > >>>>> Cc: Anshuman Khandual > >>>>> Cc: Ryan Roberts > >>>>> Cc: Suren Baghdasaryan > >>>>> Cc: Tangquan Zheng > >>>>> Signed-off-by: Barry Song > >>>>> --- > >>>>> kernel/dma/direct.c | 14 +++++++------- > >>>>> 1 file changed, 7 insertions(+), 7 deletions(-) > >>>> > >>>> <...> > >>>> > >>>>> - if (!dev_is_dma_coherent(dev)) { > >>>>> + if (!dev_is_dma_coherent(dev)) > >>>>> arch_sync_dma_for_device(paddr, sg->length, > >>>>> dir); > >>>>> - arch_sync_dma_flush(); > >>>>> - } > >>>>> } > >>>>> + if (!dev_is_dma_coherent(dev)) > >>>>> + arch_sync_dma_flush(); > >>>> > >>>> This patch should be squashed into the previous one. You introduced > >>>> arch_sync_dma_flush() there, and now you are placing it elsewhere. > >>> > >>> Hi Leon, > >>> > >>> The previous patch replaces all arch_sync_dma_for_* calls with > >>> arch_sync_dma_for_* plus arch_sync_dma_flush(), without any > >>> functional change. The subsequent patches then implement the > >>> actual batching. I feel this is a better approach for reviewing > >>> each change independently. Otherwise, the previous patch would > >>> be too large. > >> > >> Don't worry about it. Your patches are small enough. > > > > My hardware does not require a bounce buffer, but I am concerned that > > this patch may be incorrect for systems that do require one. > > > > Now it is: > > > > void dma_direct_sync_sg_for_cpu(struct device *dev, > > struct scatterlist *sgl, int nents, enum dma_data_dire= ction dir) > > { > > struct scatterlist *sg; > > int i; > > > > for_each_sg(sgl, sg, nents, i) { > > phys_addr_t paddr =3D dma_to_phys(dev, sg_dma_address(= sg)); > > > > if (!dev_is_dma_coherent(dev)) > > arch_sync_dma_for_cpu(paddr, sg->length, dir); > > > > swiotlb_sync_single_for_cpu(dev, paddr, sg->length, di= r); > > > > if (dir =3D=3D DMA_FROM_DEVICE) > > arch_dma_mark_clean(paddr, sg->length); > > } > > > > if (!dev_is_dma_coherent(dev)) { > > arch_sync_dma_flush(); > > arch_sync_dma_for_cpu_all(); > > } > > } > > > > Should we call swiotlb_sync_single_for_cpu() and > > arch_dma_mark_clean() after the flush to ensure the CPU sees the > > latest data and that the memcpy is correct? I mean: > > Yes, this and the equivalents in the later patches are broken for all > the sync_for_cpu and unmap paths which may end up bouncing (beware some > of them get a bit fiddly) - any cache maintenance *must* be completed > before calling SWIOTLB. As for mark_clean, IIRC that was an IA-64 thing, > and appears to be entirely dead now. Thanks, Robin. Personally, I would prefer an approach like the one below=E2= =80=94 that is, not optimizing the bounce buffer cases, as they are already slow due to hardware limitations with memcpy, and optimizing them would make the code quite messy. diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index 550a1a13148d..a4840f7e8722 100644 --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -423,8 +423,11 @@ void dma_direct_sync_sg_for_cpu(struct device *dev, for_each_sg(sgl, sg, nents, i) { phys_addr_t paddr =3D dma_to_phys(dev, sg_dma_address(sg)); - if (!dev_is_dma_coherent(dev)) + if (!dev_is_dma_coherent(dev)) { arch_sync_dma_for_cpu(paddr, sg->length, dir); + if (unlikely(dev->dma_io_tlb_mem)) + arch_sync_dma_flush(); + } swiotlb_sync_single_for_cpu(dev, paddr, sg->length, dir); I=E2=80=99d like to check with you, Leon, and Marek on your views about thi= s. Thanks Barry From xen-devel-bounces@lists.xenproject.org Tue Jan 06 20:11:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 20:11:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196477.1514281 (Exim 4.92) (envelope-from ) id 1vdDON-0000QE-CQ; Tue, 06 Jan 2026 20:10:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196477.1514281; Tue, 06 Jan 2026 20:10:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdDON-0000Q7-8t; Tue, 06 Jan 2026 20:10:59 +0000 Received: by outflank-mailman (input) for mailman id 1196477; Tue, 06 Jan 2026 20:10:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdDOL-0000Q1-SX for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 20:10: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 cea886b0-eb3b-11f0-b15e-2bf370ae4941; Tue, 06 Jan 2026 21:10:56 +0100 (CET) Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-59b679cff1fso692290e87.0 for ; Tue, 06 Jan 2026 12:10:55 -0800 (PST) Received: from [192.168.1.66] (95-24-239-83.broadband.corbina.ru. [95.24.239.83]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-59b6a2c02fcsm516228e87.33.2026.01.06.12.10.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 12:10:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cea886b0-eb3b-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767730254; x=1768335054; darn=lists.xenproject.org; h=in-reply-to:cc:from:content-language:references:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=a3UTB1lNTQeoNfnkSkfwz+TsiIQzBrduP5eAxBGpTQs=; b=gKEz0TsTgksrlsggf3QVaxl+NA/NtlXzBN5tLNDI8Zx1VvWYTz5BXGBxP2YRfsJ3Ja YrTtIcz2DXWyPKaMOskkubNbGKciiYLuCV/h+Ze6DUEEW+Ofwe6AkWBfBfy+SohQsXiM tvqD/NADb+J9SzD2YL+21XcE/gUYQ7/NKi8h/C0qgqHwi03hYwLWTLC8gBH9a/8J9NPe AuD/UyEyZvGTcqHUVwbsyA1iiCpa1IUqu/pOgXcrHbyza2j5yBxxvOYGs0W7b5jriYBl 40kW+fwY1fGVvaPajbPAXnZhw8aRihkgPbDdW8UUT7j7lf8VUx2eLKsSxLhCjyphTZpb kPfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767730254; x=1768335054; h=in-reply-to:cc:from:content-language:references:to:subject :user-agent:mime-version:date:message-id:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=a3UTB1lNTQeoNfnkSkfwz+TsiIQzBrduP5eAxBGpTQs=; b=c2lnFPNuRIY8T9dHxTYhsT8ktVTS8VSgAftw05HbUfNTnRDbzOQ8X2/gCfnm+ccf4g 0jZsjxZMLidpLpNqpH7pj4Dgf7PX+0PECRep8WP8235uvMGXfKLq+re9U915v56tzt4r 8EH1cNQAJYRyroFoTsqL2X17SjmGzWcc/fIdHtBuMrbQzmQYU3BRdFPoRAq4U24sjPn9 ua3zQbRkfS34xGOyNQnLMi9TeHnOolTRIJ2k6b5IjiWikW0sqrMZuQRrfN7wGpynRR5c xHwn7pCuFKrwjvXH0G9u0Q7CX1ClWlk1vlPZR0a9IrIE6J/lEVDC/BNaR5AIYNnXwZUO 5HZw== X-Gm-Message-State: AOJu0YyjC1uUxi3xMGF3IokE8fewcSUXZGjNNWW3smJNEIcTttoqFkxX 5kC7NJZBi1KBGopxSa8eaU2QemP5+vrUYakdvVqVXi1cmnTptrw0YxJq9M8S7yS1iwA= X-Gm-Gg: AY/fxX5tcshyV3XcU/BgNxreW8yO9rQgB23sIOpKa/yAc38jbtsjDPgaYk/psb09/AN RWQBkVVYJrCDmmqN+v52QCP9SktR3o7iYUJc+K+deAB9Piw/ZPz5QXaCtrAooNRzacJbCBSYKkO YFcaN6ERXo3MHrjbrUWVqYUfMyh7byiDjZPvAPCcIAbdQ07pdGImEnsy+UMRN2omJjbjSRgBaiS UF0IyhWPCeVl0f6idjwAXKUi7NV7nSxuwH3FJS1w6u2Nnp324q3HIl6oaRG+R/k89BfwgOQVp3N pXzZl1Iui8Bq7Zjol3QcfIRvUZxDoOcx2HBafQYpo3H3eOYzjY6XmXEbj2dacA9fEMDnhBznJwY DFI+vyhjmxsDhg3xmSBQF5O1AVr88rcTiHhFSyKG0/2SOvRiMG0qUwGuaCBiKpi6P8Enx/jSRkt /c0ptEuRj6Fr6z39fWqtB4FWlpzheBst0GmG4qO0LAiiWaGpr4t5Y47yv1Nb0K X-Google-Smtp-Source: AGHT+IHwnilKl5BndLuLZeNs0nq1DIFFkNMYA/jKYARJ6qW7pJolE5NLSvbiM/4fJQ8g0MVzZIaJmA== X-Received: by 2002:ac2:4e12:0:b0:597:cf12:bea6 with SMTP id 2adb3069b0e04-59b6f043818mr60073e87.48.1767730253926; Tue, 06 Jan 2026 12:10:53 -0800 (PST) Content-Type: multipart/alternative; boundary="------------aYSA0nJRu5if1P0AvfxZyP59" Message-ID: <4a6b6307-9014-4c4c-8c23-3673efa2d1b1@gmail.com> Date: Tue, 6 Jan 2026 23:10:52 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() To: xen-devel@lists.xenproject.org References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> Content-Language: ru From: =?UTF-8?B?0JDQvdGC0L7QvSDQnNCw0YDQutC+0LI=?= Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com In-Reply-To: <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> This is a multi-part message in MIME format. --------------aYSA0nJRu5if1P0AvfxZyP59 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I'm not sure about the other places. In hvm_load_cpu_ctxt (xen/arch/x86/hvm/hvm.c ), it was easy to catch because process_pending_softirqs is frequently called there, which in turn processes softirqs from the timer (where the timestamp is updated). After I fixed sync_tsc in hvm_load_cpu_ctxt, the problem stopped reproducing under no load. However, when the number of vCPUs is 4 times greater than the number of CPUs (under heavy load), the problem rarely reoccurs (mostly during snapshot restores during process_pending_softirqs calls), and this is no longer a simple case. If get_s_time_fixed can indeed be interrupted during execution after rdtsc_ordered, then the current fix is ​​insufficient. It's necessary to atomically copy "t->stamp" to the stack using local_irq_disable and local_irq_enable (as in local_time_calibration), and then work with the copy, confident in its lifetime and immutability. But until get_s_time_fixed is proven to be interruptible, this is premature, so your fix is ​​sufficient. I think I need more information and testing to say more. Regarding the other scale_delta calls, if they include values ​​calculated from externally saved tsc values ​​that could have become stale during the process_pending_softirqs call, this definitely needs to be fixed. Here's the problematic code from dwm.exe, if that helps: void __fastcall CPartitionVerticalBlankScheduler::UpdateCurrentTime(CPartitionVerticalBlankScheduler *this) {     uint64_t *xor_time_ptr = (uint64_t *)((char *)this + 0x3E40);     CPartitionVerticalBlankScheduler *scheduler = this;     LARGE_INTEGER *current_time_ptr = (LARGE_INTEGER *)((char *)this + 0x3E30);     uint64_t previous_time = *((_QWORD *)this + 0x7C6); // 0x3e30     uint64_t address_high = ((_QWORD)this + 0x3E40) << 32;     uint64_t xor_key = ((uint64_t)this + 0x3E40) | address_high;     // validate internal state     if ((previous_time ^ xor_key) != *((_QWORD *)this + 0x7C8)) { // 0x3e40         char exception_record[0x98];         memset(exception_record, 0, sizeof(exception_record));         *(int *)exception_record = 0x88980080; // MILERR_INTERNALERROR         uint64_t computed_xor = *xor_time_ptr ^ ((uint64_t)xor_time_ptr | address_high);         int param_count = 4;         int previous_time_high = (int)(previous_time >> 32);         uint32_t previous_time_low = (uint32_t)previous_time;         int computed_xor_high = (int)(computed_xor >> 32);         uint32_t computed_xor_low = (uint32_t)computed_xor; RaiseFailFastException((PEXCEPTION_RECORD)exception_record, nullptr, 0);         previous_time = *((_QWORD *)scheduler + 1990);     }     // get current timestamp     *((_QWORD *)scheduler + 0x7C7) = previous_time; // 0x3e38     QueryPerformanceCounter(current_time_ptr);     LARGE_INTEGER new_time = *current_time_ptr;     uint64_t last_previous_time = *((_QWORD *)scheduler + 0x7C7); // 0x3e38     // check if time go backward     if (new_time.QuadPart < last_previous_time) {         char exception_record[0x98];         memset(exception_record, 0, sizeof(exception_record));         *(int *)exception_record = 0x8898009B; // MILERR_QPC_TIME_WENT_BACKWARD         int new_time_high = new_time.HighPart;         uint32_t new_time_low = new_time.LowPart;         int last_previous_high = (int)(last_previous_time >> 32);         uint32_t last_previous_low = (uint32_t)last_previous_time;         int frequency_high = g_qpcFrequency.HighPart;         uint32_t frequency_low = g_qpcFrequency.LowPart;         int64_t time_delta = last_previous_time - new_time.QuadPart;         int64_t millis_delta = (1000 * time_delta) / g_qpcFrequency.QuadPart;         int millis_high = (int)(millis_delta >> 32);         uint32_t millis_low = (uint32_t)millis_delta;         int param_count = 8; RaiseFailFastException((PEXCEPTION_RECORD)exception_record, nullptr, 0);         new_time = *(LARGE_INTEGER *)((char *)scheduler + 15920);     }     *xor_time_ptr = new_time.QuadPart ^ xor_key; } Thanks. 06.01.2026 16:58, Jan Beulich пишет: > Callers may pass in TSC values from before the local TSC stamp was last > updated (this would in particular be the case when the TSC was latched, a > time rendezvous occurs, and the latched value is used only afterwards). > scale_delta(), otoh, deals with unsigned values, and hence would treat > negative incoming deltas as huge positive values, yielding entirely bogus > return values. > > Fixes: 88e64cb785c1 ("x86/HVM: use fixed TSC value when saving or restoring domain") > Reported-by: Антон Марков > Signed-off-by: Jan Beulich > --- > An alternative might be to have scale_delta() deal with signed deltas, yet > that seemed more risky to me. > > There could likely be more Fixes: tags; the one used is the oldest > applicable one, from what I can tell. > > A similar issue looks to exist in read_xen_timer() and its read_cycle() > helper, if we're scheduled out (and beck in) between reading of the TSC > and calculation of the delta (involving ->tsc_timestamp). Am I > overlooking anything there? > > stime2tsc() guards against negative deltas by using 0 instead; I'm not > quite sure that's correct either. > > amd_check_erratum_1474() (next to its call to tsc_ticks2ns()) has a > comment towards the TSC being "sane", but is that correct? Due to > TSC_ADJUST, rdtsc() may well return a huge value (and the TSC would then > wrap through 0 at some point). Shouldn't we subtract boot_tsc_stamp before > calling tsc_ticks2ns()? > > A similar issue looks to exist in tsc_get_info(), again when rdtsc() > possibly returns a huge value due to TSC_ADJUST. Once again I wonder > whether we shouldn't subtract boot_tsc_stamp. > > --- a/xen/arch/x86/time.c > +++ b/xen/arch/x86/time.c > @@ -1649,8 +1649,13 @@ s_time_t get_s_time_fixed(u64 at_tsc) > tsc = at_tsc; > else > tsc = rdtsc_ordered(); > - delta = tsc - t->stamp.local_tsc; > - return t->stamp.local_stime + scale_delta(delta, &t->tsc_scale); > + > + if ( tsc >= t->stamp.local_tsc ) > + delta = scale_delta(tsc - t->stamp.local_tsc, &t->tsc_scale); > + else > + delta = -scale_delta(t->stamp.local_tsc - tsc, &t->tsc_scale); > + > + return t->stamp.local_stime + delta; > } > > s_time_t get_s_time(void) > --------------aYSA0nJRu5if1P0AvfxZyP59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi, I'm not sure about the other places. In hvm_load_cpu_ctxt (xen/arch/x86/hvm/hvm.c ), it was easy to catch because process_pending_softirqs is frequently called there, which in turn processes softirqs from the timer (where the timestamp is updated). After I fixed sync_tsc in hvm_load_cpu_ctxt, the problem stopped reproducing under no load. However, when the number of vCPUs is 4 times greater than the number of CPUs (under heavy load), the problem rarely reoccurs (mostly during snapshot restores during process_pending_softirqs calls), and this is no longer a simple case. If get_s_time_fixed can indeed be interrupted during execution after rdtsc_ordered, then the current fix is ​​insufficient. It's necessary to atomically copy "t->stamp" to the stack using local_irq_disable and local_irq_enable (as in local_time_calibration), and then work with the copy, confident in its lifetime and immutability. But until get_s_time_fixed is proven to be interruptible, this is premature, so your fix is ​​sufficient. I think I need more information and testing to say more. 

Regarding the other scale_delta calls, if they include values ​​calculated from externally saved tsc values ​​that could have become stale during the process_pending_softirqs call, this definitely needs to be fixed. 

Here's the problematic code from dwm.exe, if that helps:

void __fastcall CPartitionVerticalBlankScheduler::UpdateCurrentTime(CPartitionVerticalBlankScheduler *this) {
    uint64_t *xor_time_ptr = (uint64_t *)((char *)this + 0x3E40);
    CPartitionVerticalBlankScheduler *scheduler = this;
    LARGE_INTEGER *current_time_ptr = (LARGE_INTEGER *)((char *)this + 0x3E30);
    uint64_t previous_time = *((_QWORD *)this + 0x7C6); // 0x3e30
    uint64_t address_high = ((_QWORD)this + 0x3E40) << 32;
    uint64_t xor_key = ((uint64_t)this + 0x3E40) | address_high;

    // validate internal state
    if ((previous_time ^ xor_key) != *((_QWORD *)this + 0x7C8)) { // 0x3e40
        char exception_record[0x98];
        memset(exception_record, 0, sizeof(exception_record));
        *(int *)exception_record = 0x88980080; // MILERR_INTERNALERROR

        uint64_t computed_xor = *xor_time_ptr ^ ((uint64_t)xor_time_ptr | address_high);
        int param_count = 4;
        int previous_time_high = (int)(previous_time >> 32);
        uint32_t previous_time_low = (uint32_t)previous_time;
        int computed_xor_high = (int)(computed_xor >> 32);
        uint32_t computed_xor_low = (uint32_t)computed_xor;

        RaiseFailFastException((PEXCEPTION_RECORD)exception_record, nullptr, 0);
        previous_time = *((_QWORD *)scheduler + 1990);
    }

    // get current timestamp
    *((_QWORD *)scheduler + 0x7C7) = previous_time; // 0x3e38
    QueryPerformanceCounter(current_time_ptr);

    LARGE_INTEGER new_time = *current_time_ptr;
    uint64_t last_previous_time = *((_QWORD *)scheduler + 0x7C7); // 0x3e38

    // check if time go backward
    if (new_time.QuadPart < last_previous_time) {
        char exception_record[0x98];
        memset(exception_record, 0, sizeof(exception_record));
        *(int *)exception_record = 0x8898009B; // MILERR_QPC_TIME_WENT_BACKWARD

        int new_time_high = new_time.HighPart;
        uint32_t new_time_low = new_time.LowPart;
        int last_previous_high = (int)(last_previous_time >> 32);
        uint32_t last_previous_low = (uint32_t)last_previous_time;
        int frequency_high = g_qpcFrequency.HighPart;
        uint32_t frequency_low = g_qpcFrequency.LowPart;

        int64_t time_delta = last_previous_time - new_time.QuadPart;
        int64_t millis_delta = (1000 * time_delta) / g_qpcFrequency.QuadPart;
        int millis_high = (int)(millis_delta >> 32);
        uint32_t millis_low = (uint32_t)millis_delta;

        int param_count = 8;

        RaiseFailFastException((PEXCEPTION_RECORD)exception_record, nullptr, 0);
        new_time = *(LARGE_INTEGER *)((char *)scheduler + 15920);
    }

    *xor_time_ptr = new_time.QuadPart ^ xor_key;
}

Thanks.

06.01.2026 16:58, Jan Beulich пишет:
Callers may pass in TSC values from before the local TSC stamp was last
updated (this would in particular be the case when the TSC was latched, a
time rendezvous occurs, and the latched value is used only afterwards).
scale_delta(), otoh, deals with unsigned values, and hence would treat
negative incoming deltas as huge positive values, yielding entirely bogus
return values.

Fixes: 88e64cb785c1 ("x86/HVM: use fixed TSC value when saving or restoring domain")
Reported-by: Антон Марков <akmarkov45@gmail.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
An alternative might be to have scale_delta() deal with signed deltas, yet
that seemed more risky to me.

There could likely be more Fixes: tags; the one used is the oldest
applicable one, from what I can tell.

A similar issue looks to exist in read_xen_timer() and its read_cycle()
helper, if we're scheduled out (and beck in) between reading of the TSC
and calculation of the delta (involving ->tsc_timestamp). Am I
overlooking anything there?

stime2tsc() guards against negative deltas by using 0 instead; I'm not
quite sure that's correct either.

amd_check_erratum_1474() (next to its call to tsc_ticks2ns()) has a
comment towards the TSC being "sane", but is that correct? Due to
TSC_ADJUST, rdtsc() may well return a huge value (and the TSC would then
wrap through 0 at some point). Shouldn't we subtract boot_tsc_stamp before
calling tsc_ticks2ns()?

A similar issue looks to exist in tsc_get_info(), again when rdtsc()
possibly returns a huge value due to TSC_ADJUST. Once again I wonder
whether we shouldn't subtract boot_tsc_stamp.

--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1649,8 +1649,13 @@ s_time_t get_s_time_fixed(u64 at_tsc)
         tsc = at_tsc;
     else
         tsc = rdtsc_ordered();
-    delta = tsc - t->stamp.local_tsc;
-    return t->stamp.local_stime + scale_delta(delta, &t->tsc_scale);
+
+    if ( tsc >= t->stamp.local_tsc )
+        delta = scale_delta(tsc - t->stamp.local_tsc, &t->tsc_scale);
+    else
+        delta = -scale_delta(t->stamp.local_tsc - tsc, &t->tsc_scale);
+
+    return t->stamp.local_stime + delta;
 }
 
 s_time_t get_s_time(void)
--------------aYSA0nJRu5if1P0AvfxZyP59-- From xen-devel-bounces@lists.xenproject.org Tue Jan 06 21:07:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 21:07:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196487.1514290 (Exim 4.92) (envelope-from ) id 1vdEGz-0006n7-BK; Tue, 06 Jan 2026 21:07:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196487.1514290; Tue, 06 Jan 2026 21:07: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 1vdEGz-0006n0-8V; Tue, 06 Jan 2026 21:07:25 +0000 Received: by outflank-mailman (input) for mailman id 1196487; Tue, 06 Jan 2026 21:07: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 1vdEGy-0006mu-IE for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 21:07:24 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b003ff48-eb43-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 22:07:21 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by PH7PR03MB6943.namprd03.prod.outlook.com (2603:10b6:510:15b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Tue, 6 Jan 2026 21:07:16 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9478.005; Tue, 6 Jan 2026 21:07: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: b003ff48-eb43-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vvFg4d4U1GvEwQxK69ROUerfpQZLMpx+6f/6FdGm/VoKtsODds37qwyBh5PZma/oJMnbIt0MTrXW4RwfoObTb+E7DSxo3xt9DzEk0xVPTaCoupWTGPvoGG0PllPFxD5sUjuaCiyzwVfjyCy30h3q3OYwrzOLzGI2juHLGlmiroIRq11lW+YUNmo3mKF1PAXIdg52S67nF8hxuQfXs4FJMp2hVzkZ9tUVaRe3J9KfArrfVyj5v37qT/MNRZXiT+2RWulxo7b1LxWbxTecx5LeCKPlhwkuTZGqmqkYSFt63ZSrknDyHN7lahTTMYrOfJVustRE1hB5tvKkUUSjRica1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=T+Qkxo2/murvC9IJKVYbJXH1tg93Vz2Ht9AUoo6S1LY=; b=FX0VzJFY3vJEfz1fyYBXic1Epbe2BzY6gzVQf1303QEN1KddMicuoM6RAuasj3h5vQOB5qy59zwsRG66DWz+C0b2XpUe56a38Wo3UopEioLFOOzSDc6tHKxW3itkKnRQd2kbOXXfisGB7/WE/T8jWHmZP+ZOYxvhurBbuzX/uiR5jGR1u+kR5MgIwKNqd/NmU2tb5drtn9tKaQRVxyo5CGoEzLWUiGd5oeu1djR/TEeP0IB1cPItSwNg+p7Nmt+A+PEXuRdZkHYUBuOlmjZ0Ym79QOs4AM6VfzgYYg/MZdJO6+vTfJCbKJ6SKpG7Ud6qBKSKpzR13cq2i4TyDzlUAg== 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=T+Qkxo2/murvC9IJKVYbJXH1tg93Vz2Ht9AUoo6S1LY=; b=waJO8TeEAEMxGA+G290aZzFewMNLEHWpiu6eyRlphBnmTSVbMIrXaqav8XdfS8bhOJwxg/renhi0z5+CKyWYU/G4yFZIrFQ9Y9jiIMbJDrQXxe3ynaxgA8wxwFVdEpLEgpYvrY8Azlyi8+Sn1bAAgguUYd/1IiLEMPqBgfbs5Jw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <98855b1c-2cda-467e-8b88-ff24e7862b61@citrix.com> Date: Tue, 6 Jan 2026 21:07:13 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Andrew Cooper , Roger Pau Monne , Oleksii Kurochko Subject: Re: [PATCH for-4.21 v2] x86/AMD: avoid REP MOVSB for Zen3/4 To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <8ecbf8b7-91fe-4f9e-9542-7ec22b6a47bb@suse.com> <693449f18cc4480ea2cb2161a9361354@DM4PR03MB7015.namprd03.prod.outlook.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <693449f18cc4480ea2cb2161a9361354@DM4PR03MB7015.namprd03.prod.outlook.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0071.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:153::22) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PH7PR03MB6943:EE_ X-MS-Office365-Filtering-Correlation-Id: 0eecf3ae-82e1-431c-94c4-08de4d67924f 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?cTE1SVVBN2U4aVYyODdrN2NLcFZBY0o5UUZGTUM4M1RwRE9ObVBBL2d4eGNK?= =?utf-8?B?QWhKVWRtaWtiWGxGVVVPcEdWOHQwWmhxYWdzdUVMQytZQnIxT2NQRjFITmF3?= =?utf-8?B?cmg2K0prcjJKR2xUdDMzdVIxaVc3SFFQOTcxQXpRWEdBUFNFTnZobThKYmMv?= =?utf-8?B?VFE0Y1RPamx0ZDFpeTNoWEpDVXlvZm8wVHhGVzRscE5jMG8yRkY3TnJlRll4?= =?utf-8?B?MWZvUUpZYWpYcnFJcXlPOVM2TUxRWmxYUFRrYXVNOVJhVmJFajkxSGJ5a3c1?= =?utf-8?B?eUUybXB2SGd3QjV6Z1FYWW5HdHpQeFdCaTRGNzlIaUF2TUVBWCtoUWx2MHBo?= =?utf-8?B?d0RSODJlM3VNOXZ0dDQxcUJSMXo2YzNqRDdCSTBqTGNLYXZ1b3RHeFYranpw?= =?utf-8?B?eXgrb3ZsNEdrNjVYcWc1b0pPbDYwOHV6T3FJYTlmcUdvVjhtMzhTL2lMbzVa?= =?utf-8?B?SFlaK2hRMXRHNUpQakpmZ09xOGcvQi9aUlMxMGwwaG5mYVhWUTZwQVVHNStw?= =?utf-8?B?UjQyNFpSNm5yd2ViQWxETTMrNEJnMlRENWFGMXkxbGhvbzVXRHZDeTc4K0E2?= =?utf-8?B?bkprSHgxdkE3dDZDUUhYNXVsRU5Od1gvbXBDUUozS0piQ3FaUDNqbXhRL203?= =?utf-8?B?aEpwNkpES240RE1xS3AraElFM1loTk5ZR05UQVFlRDdYSEk3SStIYlVWOVpj?= =?utf-8?B?cHZ4UDQvdFIzU01TeFE4aDZhTnR1OS95MVlpYWhkdkNQMjNQSlg0bm43VlpY?= =?utf-8?B?bXJtNVR3RmhkQ25ESjIycVd1b3JpU0dXSi9XeGNGTlUvYU9rcERyWFhyR0Zp?= =?utf-8?B?OFpLZWVPZSsvNGJ5SFpldmMvRVBOUlc4c2s2aUpDU2NYUUtvMVpsSmZQNHhp?= =?utf-8?B?Zk1ieFg1ZFNrSEYrZGpKdHh6SmF0Zk5kMWZKZW1nMGFZbUY2cWoxWkdKdndQ?= =?utf-8?B?YnA4Sy82NXdiTzVuNWN1dmtZdDhxb01sVjViODJCRDF3RktSamF0MUpFeFN5?= =?utf-8?B?dzMwYnUyQ2drTjFZZjNuQnNqQ1NmZXJZTE84WGZSOWdWMzVqQlNYNWhkeDlJ?= =?utf-8?B?MEtlUWFaVGJTVy81QTg3MTRleGNiZk0wUFo5UWZRaVNBeHk0ZmtJYzlsdGVG?= =?utf-8?B?MkEvWi9rWEVtRmlQNGpTaUlkeDUydzhQZW5CSVZxME42cnF2aG5rNGNFMjMr?= =?utf-8?B?RnlKVGgyNm1wN3lvVmZpdktrY3NyOEt6YlJKUlB3Wk5oSTV3OEhab2QxaU1W?= =?utf-8?B?MGUraVV4dEJPV3FZeDE5ekxOOGkwWXlRNzhKbXZvd0dUNitCM3hXOG5WZ1hP?= =?utf-8?B?UTFEemVRNTV4MSsrZGt0V2tEMjY4UmNCNERLRWZwMWFxODlvS3lWdDliOVRq?= =?utf-8?B?R3cwSlQycURQUjlTM005K0Q0aUx4NnJYbExVNXhaWlFmdTFBWFVvcndkY0RB?= =?utf-8?B?Mk80MEY5bVo0UXBhNGhDOVVOSzZmNFduSDBYc1FsSGNUWW1FbmRlVUZVVUR2?= =?utf-8?B?dk1WbU9pUVQ5bTR5NXZSVUVGRFJXcERwR3Y5TXBMOEFvWUlXSnpUS09aZ0ZP?= =?utf-8?B?bHRVc0RqVUFtZTFUYWc3UW42cWVHcVUxRnhUVVJzQkZoZWxWckxqSnlNNUl2?= =?utf-8?B?NHdJeXJmRS95a0tiY0MycG1lZVEveWhZWmVOb05xM2lCZTVINXdhVzZ1eFI2?= =?utf-8?B?TVkycUZpOU5tYjQxYjBnOEVlYjNtMm9qZHo0ejNKckRxRTBMVnQ1Q2EvUXFR?= =?utf-8?B?ZzYxK3BCNlcvM0d3dkFMZ1Vvek5Zb0ZRbGYrK2FybUNxQkJYSk1IS0lDTHho?= =?utf-8?B?WEpDY25meVprUHJvNDZ0YnJOYkpqQ3dWMmhVNXpvdWFqWGZSU01jKzBqc216?= =?utf-8?B?bkY5aFJ1SG5iRzlYbFhrYzZtZmZZaGVrWHhXa05LZllmc2hjRGUrdDhOU1Zr?= =?utf-8?Q?s9ImJETJNIsUeK4pV2NGCMJcw0GY6Xsh?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZWYzV1FTc3h5Z2ZPWDEyVVlQbHJubEZ3TjludW9tcFRzRU5BQzViZi8rdGNp?= =?utf-8?B?WjdTdWJFK0QxbUJQcUVURHpDeWFvSUltaEZYS0ZmNlJMeTVQTGhrSW0vQWxy?= =?utf-8?B?UWF6NHhqZUI4V3VMVDY3WlExdCt6TlA0Um5LM3hxRVozQjRSS0xQODMwVlRO?= =?utf-8?B?VGxhdU5mdHdyWkdIM3J2MzNVOFJFTzJScDVyREhIdFk2NC9KcTBEaUxtZzVX?= =?utf-8?B?RFZyL1JCVDByTlA2aGZwV0h0MU8yakx6U2w1SFBhWXpmTHoxT0ZqYk91cHpn?= =?utf-8?B?S1MxQkd5ZmNvaVFaY3JXbXd6WjBMOGxYcG1UREpMYlBVc0FyUFZ2aVVLeFpu?= =?utf-8?B?ai9zV0xXZWtxd01sMlhrMHc1R3NqRWVCb0szSDRRMkFmQ1UwdTJBUkJLaUd2?= =?utf-8?B?cWYvUHFsMktOaU1sWjBWOEJHMGFkUVRYSDE3MU91azZmZkJWSXVveHd3aVcz?= =?utf-8?B?WWt0MG5aYUdqNXBrdFVKUVZRZ3RkeGlNUzY3M2VWMnFtMTBrdEluaGx4QUhw?= =?utf-8?B?VURFWkwvVUdXQ0Y1R1YxQmY3akNDRmsxRjRkbDhiN1U3eUZLbTJ0RFV4OTJN?= =?utf-8?B?SHlWQ2hWN2thVk8xRGQvM1VHcHorVmo3azg5Qmh5TVJtZ1JpV1hlM0dJMTBL?= =?utf-8?B?QkxlTVhocjEwaGhidEJOdU1sZ1ZlV3F4WWtQUkJzOXZnNGhhVTZwM3lWZnVp?= =?utf-8?B?UnNyNjRCQVVXeUM5d1VLVER4YkJscmxZdmJURTFGMWlEN3RmNWFxYmIyTnNJ?= =?utf-8?B?Tm5EaHZsMWZEWGVrRWZDZVc3VW5Td0toNEpzTDZzV0JWektxcmpRT0lXM0d3?= =?utf-8?B?bENYNnpjMzM5TTlSS3lIam1Lc2hWLzNtQWRyOFM3ZzVOcEVzWnFsbUxUWDE1?= =?utf-8?B?SlFXUU1DYU9KREpWOUNFUGQ3WFUwMitVczJNSUVNdkR0OHRtN0JPLzhsd3pK?= =?utf-8?B?ckI1WDRDTFN3d2xmZEZIMVNSbk42WEpGdzlsVDdVODljNzAvQVozTzllZnc1?= =?utf-8?B?dEdTSm9ETDg5dlRWaFU5NWF1S3NtRVRVZm5SaUZjNXZjU2xBYnQ5VjA2RDc3?= =?utf-8?B?K1hCMXhPdHJqU2EvcklXNXZuSS9NRyswU3loTUl2N0FyeXpGaTZLSTdFTDVQ?= =?utf-8?B?ODlpSkpFSWF4YUJ6TVVMWjJhNXlhNnlKakZyVXJ0YjdGaTRNQTZUeE5tbzlh?= =?utf-8?B?L1JRU2VhV2N4S1RaZnpZRE9ob0t4Nmptc3QzZXU0K21GRStkTEF6cXVtS1dv?= =?utf-8?B?bVIwbG1BWi9SY3lwa2l4N1phbGhsbUZxcHNJTUE1aEdwVVpRUzRITTl4Qmg1?= =?utf-8?B?NHVPbjZ2bC9RNU9zZExpekI0RmczVG52dW9iM2FEa3MycUxnV2EyTWNpWHp3?= =?utf-8?B?d2NxTmIzRmdIOENVMzB6OTY1cGJSbEZoSTcwR2UwdGE4cnk1L0VyN0p1a09q?= =?utf-8?B?c1JPTUpzaENETEN1ZmtBSlpDTEh3d3hpMjJzTm82MkVFNDMwUHhta3FGMm9D?= =?utf-8?B?OU1XWmppOG1nWVF1OUl1Rk5IWHpUd1Q1cVdJL050M3cyTjc3MEx5Q05Ubm5v?= =?utf-8?B?MUNNYW9BNHVJM2tJUzNPcGFhL2IzdEZxd2wyN2VhdW04ak92UGsvaUZvMUxL?= =?utf-8?B?K3B6MCt4aHBZR090T0lmejVMYks4L2tJK0kvMTJMcWVVaFFpMVk1aHhMQVE0?= =?utf-8?B?Um1NTEVqNjFmWEdkUXZiSWZNTDI1VmpsWWZ6RWJ1cTB4SlkycHd5aGs1UHBM?= =?utf-8?B?R3NCZkV2M2owNHBZbDZrUk9xUzUwc2dlcDZjckZFYnlvdFZHZStBZkdHWXpW?= =?utf-8?B?NGVjalBlVDZkUEtVR2wyaFp1UnNlVUh0TlpoOVAvRUlCMFNFb1I3d0xydkZK?= =?utf-8?B?RFgwSzlhaEs4cHdlczZLUDVrczNGVytQdjUrd0Q1RDFCRmltM2d6NGJaQWxQ?= =?utf-8?B?UWR6aUx4SEdzSzFwSGh2U25uQTVRcHg3U1pydGpZTVU0bUxZZzJEVWlxNnFT?= =?utf-8?B?MVViUnpKMjVWLy8xb2xHZk81dXVpOGJDTXZndmZuTkVUdTVNbGNCNGs3Mzhh?= =?utf-8?B?QUVDdjZKdXZQRDJxRklwRklSSHJKRXVhY09qcUZBQkY2NEM3QStsa1g4bTJD?= =?utf-8?B?WkJ1dWxHK3NFKzhYRlNZR1NqYzlUcXh5NWQ4RG55T0VrZ3ZtZFkwekNoREVz?= =?utf-8?B?RlBQQTdHWmUvODB0b055YjZyT3NIU3lOdGFuNzR2eVFnUk9udVFwd2E5RGEv?= =?utf-8?B?TGNnd1Jka3RET3dqeXlTWGI3dWJ3dU5GekFyR3p4cWVmUnBwaFA4czViUTBP?= =?utf-8?B?M2NMNzc3OFg2L01OMFJnY296RlUzektiMzlNeUg3YmJRRS9Wdm9oT29jVUJk?= =?utf-8?Q?fh3k0A4ZkWrsQ/tE=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0eecf3ae-82e1-431c-94c4-08de4d67924f X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2026 21:07:16.6606 (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: XB3RY8rPaHwNp2uM74Pn3KS1atqZgJWAigUNwMeaRzUktusaVm705VMiKS/+3bWxcVhxJlftUe4hBorx+TakAAJlkVesfdjE+wKDcrri6IY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR03MB6943 On 13/10/2025 2:06 pm, Jan Beulich wrote: > 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 of memcpy(); copy_page_hot() is fine, as > its two pointers are always going to be having the same low 5 bits. I think this could be a bit clearer.  How about this: ---8<--- Zen2 (which doesn't expose ERMS) through Zen4 have sub-optimal aliasing detection for REP MOVS, and fall back to a unit-at-a-time loop when the two pointers have differing bottom 5 bits.  While both forms are affected, this makes REP MOVSB 8 times slower than REP MOVSQ. memcpy() has a high likelihood of encountering this slowpath, so avoid using REP MOVSB.  This undoes the ERMS optimisation added in commit d6397bd0e11c which turns out to be an anti-optimisation on these microarchitectures. However, retain the use of ERMS-based REP MOVSB in other cases such as copy_page_hot() where there parameter alignment is known to avoid the slowpath. ---8<--- ? This at least gets us back to the 4.20 behaviour. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 06 22:47:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 06 Jan 2026 22:47:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196503.1514300 (Exim 4.92) (envelope-from ) id 1vdFpl-0001Oh-BZ; Tue, 06 Jan 2026 22:47:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196503.1514300; Tue, 06 Jan 2026 22:47: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 1vdFpl-0001Oa-8z; Tue, 06 Jan 2026 22:47:25 +0000 Received: by outflank-mailman (input) for mailman id 1196503; Tue, 06 Jan 2026 22: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 1vdFpk-0001OU-0J for xen-devel@lists.xenproject.org; Tue, 06 Jan 2026 22:47:24 +0000 Received: from mail132-4.atl131.mandrillapp.com (mail132-4.atl131.mandrillapp.com [198.2.132.4]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a89646d3-eb51-11f0-9ccf-f158ae23cfc8; Tue, 06 Jan 2026 23:47:21 +0100 (CET) Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail132-4.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4dm5s26ZP0zlfgFc for ; Tue, 6 Jan 2026 22:47:18 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id b1553eb1c00644bcbb88f64e577effc2; Tue, 06 Jan 2026 22:47: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: a89646d3-eb51-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1767739638; x=1768009638; bh=uG9dkpcyxG9XGIOrcqOgWZEBQUboGOvOW5SQQsgO9JQ=; 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=rHQHdgx9W+Z7otwHoGXl8Lpr17UVSjNVNTXuPiW7JX2QyW/lhbnwhmEbtfgxzr9g2 jUF/QjdJDutsY9VgIVwnMcgjw8uGW3n/fKsxNEpoxWbvp58naXQV9FRxxXbKrxYw6n K26Gc5/IOOWzue4lX6llR/FQcd/1cabMeTDjqLfsQFNimcx2LTBCTwbZImmFl0gjD3 m0cOKuVUUWB8B5hRkKvBhvwK6EaN5UN2Tnrfjbq1GqgFxrp0RrP/Cf9Y2SJY7G+zC4 BCc+8CTrVw0d22TWucgrjAs2FbWTSLpsDWIdPBueBQ5uGKg5I0QD6b8b6u9TXOUbrA KDVBJstAWCZrA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1767739638; x=1768000138; i=teddy.astie@vates.tech; bh=uG9dkpcyxG9XGIOrcqOgWZEBQUboGOvOW5SQQsgO9JQ=; 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=jm3DRF6W4/YL0lwx/YN9qQu4XjpIMo7Zy9i3LZpzEp18mXM3GC+GKDg1Wc1cW29Ru UkirsBkBF2K2b6jaR658iI7fGXyUymDnwYw6sMmw1dBPOy/uqCd5oz8oQ+W8qBL8su bvmI2MhofW2a30Fn7RkIHsRUTxhTZf2pRcJZgTFOeB2KIlOWz6fg1+jQ7S003xLVVf ovt8UliGWkwiB5vUp/q0BccZ7mFOJPIinROBgu/dg4nt40DzfiYH9gQmRb+8ZejtdZ Wfl9r6Zap8qshad9I3pPIyFg2Vc7EUBbMVsWHu6h91HCU+Vvs+Z6dMV0E0PlmkLk0B ao3KHrpltAqnw== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH]=20xen/virtio:=20Don't=20use=20grant-dma-ops=20when=20running=20as=20Dom0?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1767739637478 Message-Id: <0b168d85-443c-4f38-92f8-8c008b2f8b82@vates.tech> To: "=?utf-8?Q?J=C3=BCrgen=20Gro=C3=9F?=" , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Cc: "Stefano Stabellini" , "Oleksandr Tyshchenko" , "Boris Ostrovsky" References: <6698564dd2270a9f7377b78ebfb20cb425cabbe8.1767720955.git.teddy.astie@vates.tech> <995f7ac8-0a8b-43d9-9cc7-63622ec52ca1@suse.com> In-Reply-To: <995f7ac8-0a8b-43d9-9cc7-63622ec52ca1@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.b1553eb1c00644bcbb88f64e577effc2?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260106:md Date: Tue, 06 Jan 2026 22:47:18 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 06/01/2026 =C3=A0 20:06, J=C3=BCrgen Gro=C3=9F a =C3=A9crit=C2=A0: > On 06.01.26 18:36, Teddy Astie wrote: >> Dom0 inherit devices from the machine and is usually in PV mode. >> If we are running in a virtual that has virtio devices, these devices >> would be considered as using grants with Dom0 as backend, while being >> the said Dom0 itself, while we want to use these devices like regular >> PCI devices. >> >> Fix this by preventing grant-dma-ops from being used when running as Dom= 0 >> (initial domain). We still keep the device-tree logic as-is. >> >> Signed-off-by: Teddy Astie >> Fixes: 61367688f1fb0 ("xen/virtio: enable grant based virtio on x86") >> --- >> CC: Juergen Gross >> CC: Stefano Stabellini >> CC: Oleksandr Tyshchenko >> CC: Boris Ostrovsky >> >> =C2=A0 drivers/xen/grant-dma-ops.c | 3 ++- >> =C2=A0 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c >> index 14077d23f2a1..c2603e700178 100644 >> --- a/drivers/xen/grant-dma-ops.c >> +++ b/drivers/xen/grant-dma-ops.c >> @@ -366,7 +366,8 @@ static int xen_grant_init_backend_domid(struct >> device *dev, >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (np) { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ret =3D xen_dt_gr= ant_init_backend_domid(dev, np, backend_domid); >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of_node_put(np); >> -=C2=A0=C2=A0=C2=A0 } else if (IS_ENABLED(CONFIG_XEN_VIRTIO_FORCE_GRANT)= || >> xen_pv_domain()) { >> +=C2=A0=C2=A0=C2=A0 } else if (!xen_initial_domain() && >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (IS_ENABLE= D(CONFIG_XEN_VIRTIO_FORCE_GRANT) || >> xen_pv_domain())) { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dev_info(dev, "Us= ing dom0 as backend\n"); >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *backend_domid = =3D 0; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ret =3D 0; > > Please make this controllable, e.g. via a boot parameter. > > It is completely valid to have a virtio device in dom0 with the backend i= n > a domU. You'll need grants in this case. > Due to > *backend_domid =3D 0 Dom0 would always be the backend, unless we introduce a new boot parameter to select which domain will be the backend. There is also another issue, as in the xen_initial_domain() case, all PCI devices come from hardware. So no virtio-pci device can't come from another domain as Linux would pick up pcifront devices only if we are not a Dom0 (!xen_initial_domain()). > > Juergen 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 Jan 07 07:23:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 07:23:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196516.1514311 (Exim 4.92) (envelope-from ) id 1vdNsT-0000P7-GC; Wed, 07 Jan 2026 07:22:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196516.1514311; Wed, 07 Jan 2026 07: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 1vdNsT-0000P0-CT; Wed, 07 Jan 2026 07:22:45 +0000 Received: by outflank-mailman (input) for mailman id 1196516; Wed, 07 Jan 2026 07:22: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 1vdNsS-0000Ou-IG for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 07:22:44 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a6e393c9-eb99-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 08:22:41 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-47775fb6c56so14829935e9.1 for ; Tue, 06 Jan 2026 23:22:41 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f668e03sm84261615e9.14.2026.01.06.23.22.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 23:22:40 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a6e393c9-eb99-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767770561; x=1768375361; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=w08qEzxsXeIfY5MglmTbkHuO1YUY66tXMm2UAY5+WNo=; b=K1Yx9HnqDyIvCapQh15UF280shxXQraVzgxm/8NhokmxP9Zcudm5gZL6ySzAwl84E2 4IzW1ZyYmJjOtWEvOynZkfyBCVeYytEVTVDfmr4A/zCZXEMyPcEZaqErkqMCoHdt2S5/ 1tkWJHZw3xux3pKmZSQ9EvfcGfeMMmWL9q7T/5UUckS9kzB+pXUC2T+sjokjOcHff1Oz bvz/G++C6vZ1U1/cHKPJEAKTVUpkT/AKWRmJcGVhXeE6IxB2PC9F54zFIjS6tpmMHQuo IPHg6wBmXyqGBB+G86sSkyreP9TSw8jGurSMvQvoTJSyYjdA8wV4QHae8Ccv1jpdvhEU qdhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767770561; x=1768375361; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=w08qEzxsXeIfY5MglmTbkHuO1YUY66tXMm2UAY5+WNo=; b=a0sKcdK0W+eTBHK/tsUKfbbGDuEgBkILkz1DBH31RBc/vBUA86Kb9WVdzrqBOvG4cU ZmAL5oe8j47OUac+aUoK0xWpv6fnyFDcL0mzFJGsklH4zNWP5kdr/86B0VdHDlY8yPhS fRZ4ADhL05WeJYRay7zhi5YH8G2yoq9nth2Y30wA87Eeg4Uky4ieZMtSzYaJVTmdQYUO tzPnAt197G4LpX6JUNqKCugyE29by+bQ8V0I6KWJERYQYVZ6+P7lgT7map+axclFk4ou TssaLn6Jzqrr1NgbO5BItcdM5tE/QmEYgiXOiGq891gFCy88ZzXZZjx6nDFTYFNyA/3O yDtw== X-Forwarded-Encrypted: i=1; AJvYcCULHRFRIfGo+tDEE8m4j1V7N+18sLstAW92+61lA0QzI8iofGAOCIAveAboW+DToQ+YRD8n8mCxFI0=@lists.xenproject.org X-Gm-Message-State: AOJu0YziQgkmEeoOxLT3TYlfJ5di+el0YfQl35YZL9TtG7xsJBYRJ2l1 oV/9/FqCFQvtcT0JaSWzxdFaPf4MWOXnAHQMfgytpAgnexKOuQBvKTxCnVOHMJv40w== X-Gm-Gg: AY/fxX6XAZZP8VPLng383hD9mOJZjrsaiK0yeVMSytCbuMY4RIXbNrq0JBOgnKLpUqY RnCqxh/LUqKjvud8LFpRjH+Cq08f8zuqgn2/UylUSAYzsKUDexJgWMr4N5tcFhINlgGq/64KUhh 8jh35am5JcRjuyyQDpAefmAiXUZin/egbpz7zTXXGftnqPLZkLzUixlAOIq1gKyg+r/ZdtH/elG gulgE+qjdF8nABeXWmFPhHqqkSEJIV6AOMjrP2tgn6qkbhUILNXbJHIQTTQq7wMZjO/l39s7y1y QzipLE7+W0775mjm01SagD1eGazM2LqUDWXekAxbKQ9NqgSZwK0cti3KIbALv+mX8Ja6FBgsomW vOQ8dH78b1OZS2CmilIFNgmF5lJ3qtPWZwFQ9uHqb2ASxHW5v0ONH2WrvqxPQDDyTswlexLl5wF XQDtyFg6wjorZTTWATHGdhpVsymRbwA52NHwkK4gkzS/d+x00TJDiMu5uMMYQfMobEWqqJtDaEI hk= X-Google-Smtp-Source: AGHT+IH7gEioYd9qII0cUkDG7O8KvpP9xIJ8Cc7v2Nnrn8FDhntJUIb6c1XICzM2+VOf7NRFSjwzVw== X-Received: by 2002:a05:600c:4ed4:b0:477:9986:5e6b with SMTP id 5b1f17b1804b1-47d84b41b53mr13884935e9.28.1767770560672; Tue, 06 Jan 2026 23:22:40 -0800 (PST) Message-ID: <0ebbc19a-724c-4e2f-89ce-58325342c4b5@suse.com> Date: Wed, 7 Jan 2026 08:22:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH for-4.21 v2] x86/AMD: avoid REP MOVSB for Zen3/4 To: Andrew Cooper Cc: Andrew Cooper , Roger Pau Monne , Oleksii Kurochko , "xen-devel@lists.xenproject.org" References: <8ecbf8b7-91fe-4f9e-9542-7ec22b6a47bb@suse.com> <693449f18cc4480ea2cb2161a9361354@DM4PR03MB7015.namprd03.prod.outlook.com> <98855b1c-2cda-467e-8b88-ff24e7862b61@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: <98855b1c-2cda-467e-8b88-ff24e7862b61@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06.01.2026 22:07, Andrew Cooper wrote: > On 13/10/2025 2:06 pm, Jan Beulich wrote: >> 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 of memcpy(); copy_page_hot() is fine, as >> its two pointers are always going to be having the same low 5 bits. > > I think this could be a bit clearer.  How about this: > > ---8<--- > Zen2 (which doesn't expose ERMS) through Zen4 have sub-optimal aliasing > detection for REP MOVS, and fall back to a unit-at-a-time loop when the > two pointers have differing bottom 5 bits.  While both forms are > affected, this makes REP MOVSB 8 times slower than REP MOVSQ. > > memcpy() has a high likelihood of encountering this slowpath, so avoid > using REP MOVSB.  This undoes the ERMS optimisation added in commit > d6397bd0e11c which turns out to be an anti-optimisation on these > microarchitectures. > > However, retain the use of ERMS-based REP MOVSB in other cases such as > copy_page_hot() where there parameter alignment is known to avoid the > slowpath. > ---8<--- > > ? Fine with me; changed. Do I take this as an okay-to-commit? Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 07 07:37:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 07:37:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196525.1514321 (Exim 4.92) (envelope-from ) id 1vdO6H-00026n-Le; Wed, 07 Jan 2026 07:37:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196525.1514321; Wed, 07 Jan 2026 07:37:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdO6H-00026g-Hq; Wed, 07 Jan 2026 07:37:01 +0000 Received: by outflank-mailman (input) for mailman id 1196525; Wed, 07 Jan 2026 07:37: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 1vdO6G-00026H-JT for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 07:37:00 +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 a5cbe471-eb9b-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 08:36:58 +0100 (CET) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-64b608ffca7so2514076a12.3 for ; Tue, 06 Jan 2026 23:36:58 -0800 (PST) Received: from ?IPV6:2003:e5:8704:4800:66fd:131f:60bd:bc29? (p200300e58704480066fd131f60bdbc29.dip0.t-ipconnect.de. [2003:e5:8704:4800:66fd:131f:60bd:bc29]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6507bf6d5absm3867891a12.33.2026.01.06.23.36.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 23:36:57 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a5cbe471-eb9b-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767771418; x=1768376218; 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=9EQ7Aa8EhGJ4mL3xJ/5yrfrQwVGovVjKHiRrRlymYzg=; b=CCd/LkAzqdyltfsKDgeWPPMhnx8Y3SfIyhdUisiQXrJjyxxZlr9HQw9Rhl9wYqeObz zM/DN6UxiCVeOf7XoBVEVRPqHhi9u6a9WbTUoC0X7WdB7ffb6wRxs1YHfhFB+pLowdUx DXDnMW45Y1EyrOqRapjtAgTpIfFamRB0gLi+w/n3h/Z9AFe/qogvjc8vCTuIOB49/Z59 XWsOw4ymOrhYE47eBoSy3xwAfNhfJNqpiZWQhbiWsGoyfEBHg9XPH6cIPVMAn1ye1CIX 4n3GyjUsrByaSoz44f7+UMng15mWD53tq44iOtFigmvP/jCkLvgbU6+oM3aErDQiqbrX N87g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767771418; x=1768376218; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9EQ7Aa8EhGJ4mL3xJ/5yrfrQwVGovVjKHiRrRlymYzg=; b=iZZgefvjQBeaVfTqfObz/1+/jTtizN5fqG8P9E/1v+7TSc49szZec+YTMMS44Vo3Fm 9r58CNxxCX0W6/giYqTNcv8/jGKvPvSlrfOU/PYw0S0PpGPaY/Jto0xdeDo8awo/5G8u B64NymqWp1fnEhXvcxwovcWm44KkWK73Veqf99VMtH3iq3IMvrGpv34vp4MHsDJ1d+V+ XZiNGvPD7U3IQ3dwFhS2r38xhibTNa5qvhrbx1kR7Fy02tOJUVL6mZN8jQe7Kj77p0wC YFHbVNDw5VtspYw15+v9MLjNYrChfnYeQrQ1Ms4BC+WZbVgkowNwuF0y4Wl8ITgUKzDD h+/Q== X-Forwarded-Encrypted: i=1; AJvYcCV8ohJdGJNcHJ01cYNIC3UJGKAODjJvYI7GYUVZyqevERnOZoW1Kc3fGW6ObVQSnLEur5OzoJAxYNc=@lists.xenproject.org X-Gm-Message-State: AOJu0YyzKimqrYdSmhuOvymHKJj+YCoS2K11Hrs5bPS5mN4DdCg43T5J Mwf6NBVKOIj3Z3LL2+Gt8SwbBWudu1IEzd0yXvCtufqB44FMoXYhOEN4Jvm4cwGDX8ooNAw3H9a cNSO/ X-Gm-Gg: AY/fxX4wHmNq8w4m62mlg/3p3W1/vuT9uNMaQ9IRq4kP4mHkfzm4mkwYB4ZH0YXW2SP pCTKR9RO4wq56VHxut2jvfsf5jUheydKQV6UrHlqwNNs41/pszwrlmyGbyMH/AQACdDSqGkyGrs AjF2eLXewiLXcNSZjph1r8/rbMnQVU2BYORnr0WLT5SmAFMifAu4vh8Z0z7pv1dx8fk6hgK5o4z iFO8HSPNYlB+xqnpFRsJofe3fS3lnsyWnmthNEKygh98mwCjJPzi32G5rtEmjyVTR0JE0LWowqX IE0v334E9O63cnRiRceKioez7B9IF+R4DYx2MCOS9/qlHFs72o0NNR1IkdbjQGd4Iw2Y9Eyuqkh 2J818+zLcRwwNklmotBcGLMstiBskzhG8gMjcgwkPGq9KjCkmH2G3aBXQb2KiJlRpIp2EPl1Ok2 4SAxqrmvaVdkkgeW4jwsdvJPH6ozoZamblMqIpTGCqA762PkXYuTFxzcepXXEBYGUDDaUGE7G3v LUyX8oHDbeu9wLz118sMLe3sEaP8M2ntB2QTgo= X-Google-Smtp-Source: AGHT+IE0IbBPQigm0vcFpZwThPhBgC/5Klo8VeUMGYOyWs2/My6c4Vy+qNVVZZqOWrWE0YDCYLyOpg== X-Received: by 2002:a05:6402:27ca:b0:64c:9e19:9831 with SMTP id 4fb4d7f45d1cf-65097de5b1fmr1498742a12.12.1767771417607; Tue, 06 Jan 2026 23:36:57 -0800 (PST) Message-ID: Date: Wed, 7 Jan 2026 08:36:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/virtio: Don't use grant-dma-ops when running as Dom0 To: Teddy Astie , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Cc: Stefano Stabellini , Oleksandr Tyshchenko , Boris Ostrovsky References: <6698564dd2270a9f7377b78ebfb20cb425cabbe8.1767720955.git.teddy.astie@vates.tech> <995f7ac8-0a8b-43d9-9cc7-63622ec52ca1@suse.com> <0b168d85-443c-4f38-92f8-8c008b2f8b82@vates.tech> 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: <0b168d85-443c-4f38-92f8-8c008b2f8b82@vates.tech> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------DLuJiwko2Kg2MIwuzsl8lMGO" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------DLuJiwko2Kg2MIwuzsl8lMGO Content-Type: multipart/mixed; boundary="------------rmmZ4eqSM2lOw0qLVTm0Qj7X"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Teddy Astie , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Cc: Stefano Stabellini , Oleksandr Tyshchenko , Boris Ostrovsky Message-ID: Subject: Re: [PATCH] xen/virtio: Don't use grant-dma-ops when running as Dom0 References: <6698564dd2270a9f7377b78ebfb20cb425cabbe8.1767720955.git.teddy.astie@vates.tech> <995f7ac8-0a8b-43d9-9cc7-63622ec52ca1@suse.com> <0b168d85-443c-4f38-92f8-8c008b2f8b82@vates.tech> In-Reply-To: <0b168d85-443c-4f38-92f8-8c008b2f8b82@vates.tech> --------------rmmZ4eqSM2lOw0qLVTm0Qj7X Content-Type: multipart/mixed; boundary="------------P0m4PEXFzTqOfClLS2QPVtlu" --------------P0m4PEXFzTqOfClLS2QPVtlu Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDYuMDEuMjYgMjM6NDcsIFRlZGR5IEFzdGllIHdyb3RlOg0KPiBMZSAwNi8wMS8yMDI2 IMOgIDIwOjA2LCBKw7xyZ2VuIEdyb8OfIGEgw6ljcml0wqA6DQo+PiBPbiAwNi4wMS4yNiAx ODozNiwgVGVkZHkgQXN0aWUgd3JvdGU6DQo+Pj4gRG9tMCBpbmhlcml0IGRldmljZXMgZnJv bSB0aGUgbWFjaGluZSBhbmQgaXMgdXN1YWxseSBpbiBQViBtb2RlLg0KPj4+IElmIHdlIGFy ZSBydW5uaW5nIGluIGEgdmlydHVhbCB0aGF0IGhhcyB2aXJ0aW8gZGV2aWNlcywgdGhlc2Ug ZGV2aWNlcw0KPj4+IHdvdWxkIGJlIGNvbnNpZGVyZWQgYXMgdXNpbmcgZ3JhbnRzIHdpdGgg RG9tMCBhcyBiYWNrZW5kLCB3aGlsZSBiZWluZw0KPj4+IHRoZSBzYWlkIERvbTAgaXRzZWxm LCB3aGlsZSB3ZSB3YW50IHRvIHVzZSB0aGVzZSBkZXZpY2VzIGxpa2UgcmVndWxhcg0KPj4+ IFBDSSBkZXZpY2VzLg0KPj4+DQo+Pj4gRml4IHRoaXMgYnkgcHJldmVudGluZyBncmFudC1k bWEtb3BzIGZyb20gYmVpbmcgdXNlZCB3aGVuIHJ1bm5pbmcgYXMgRG9tMA0KPj4+IChpbml0 aWFsIGRvbWFpbikuIFdlIHN0aWxsIGtlZXAgdGhlIGRldmljZS10cmVlIGxvZ2ljIGFzLWlz Lg0KPj4+DQo+Pj4gU2lnbmVkLW9mZi1ieTogVGVkZHkgQXN0aWUgPHRlZGR5LmFzdGllQHZh dGVzLnRlY2g+DQo+Pj4gRml4ZXM6IDYxMzY3Njg4ZjFmYjAgKCJ4ZW4vdmlydGlvOiBlbmFi bGUgZ3JhbnQgYmFzZWQgdmlydGlvIG9uIHg4NiIpDQo+Pj4gLS0tDQo+Pj4gQ0M6IEp1ZXJn ZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4NCj4+PiBDQzogU3RlZmFubyBTdGFiZWxsaW5p IDxzc3RhYmVsbGluaUBrZXJuZWwub3JnPg0KPj4+IENDOiBPbGVrc2FuZHIgVHlzaGNoZW5r byA8b2xla3NhbmRyX3R5c2hjaGVua29AZXBhbS5jb20+DQo+Pj4gQ0M6IEJvcmlzIE9zdHJv dnNreSA8Ym9yaXMub3N0cm92c2t5QG9yYWNsZS5jb20+DQo+Pj4NCj4+PiAgwqAgZHJpdmVy cy94ZW4vZ3JhbnQtZG1hLW9wcy5jIHwgMyArKy0NCj4+PiAgwqAgMSBmaWxlIGNoYW5nZWQs IDIgaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQ0KPj4+DQo+Pj4gZGlmZiAtLWdpdCBh L2RyaXZlcnMveGVuL2dyYW50LWRtYS1vcHMuYyBiL2RyaXZlcnMveGVuL2dyYW50LWRtYS1v cHMuYw0KPj4+IGluZGV4IDE0MDc3ZDIzZjJhMS4uYzI2MDNlNzAwMTc4IDEwMDY0NA0KPj4+ IC0tLSBhL2RyaXZlcnMveGVuL2dyYW50LWRtYS1vcHMuYw0KPj4+ICsrKyBiL2RyaXZlcnMv eGVuL2dyYW50LWRtYS1vcHMuYw0KPj4+IEBAIC0zNjYsNyArMzY2LDggQEAgc3RhdGljIGlu dCB4ZW5fZ3JhbnRfaW5pdF9iYWNrZW5kX2RvbWlkKHN0cnVjdA0KPj4+IGRldmljZSAqZGV2 LA0KPj4+ICDCoMKgwqDCoMKgIGlmIChucCkgew0KPj4+ICDCoMKgwqDCoMKgwqDCoMKgwqAg cmV0ID0geGVuX2R0X2dyYW50X2luaXRfYmFja2VuZF9kb21pZChkZXYsIG5wLCBiYWNrZW5k X2RvbWlkKTsNCj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKgIG9mX25vZGVfcHV0KG5wKTsNCj4+ PiAtwqDCoMKgIH0gZWxzZSBpZiAoSVNfRU5BQkxFRChDT05GSUdfWEVOX1ZJUlRJT19GT1JD RV9HUkFOVCkgfHwNCj4+PiB4ZW5fcHZfZG9tYWluKCkpIHsNCj4+PiArwqDCoMKgIH0gZWxz ZSBpZiAoIXhlbl9pbml0aWFsX2RvbWFpbigpICYmDQo+Pj4gK8KgwqDCoMKgwqDCoMKgwqDC oMKgIChJU19FTkFCTEVEKENPTkZJR19YRU5fVklSVElPX0ZPUkNFX0dSQU5UKSB8fA0KPj4+ IHhlbl9wdl9kb21haW4oKSkpIHsNCj4+PiAgwqDCoMKgwqDCoMKgwqDCoMKgIGRldl9pbmZv KGRldiwgIlVzaW5nIGRvbTAgYXMgYmFja2VuZFxuIik7DQo+Pj4gIMKgwqDCoMKgwqDCoMKg wqDCoCAqYmFja2VuZF9kb21pZCA9IDA7DQo+Pj4gIMKgwqDCoMKgwqDCoMKgwqDCoCByZXQg PSAwOw0KPj4NCj4+IFBsZWFzZSBtYWtlIHRoaXMgY29udHJvbGxhYmxlLCBlLmcuIHZpYSBh IGJvb3QgcGFyYW1ldGVyLg0KPj4NCj4+IEl0IGlzIGNvbXBsZXRlbHkgdmFsaWQgdG8gaGF2 ZSBhIHZpcnRpbyBkZXZpY2UgaW4gZG9tMCB3aXRoIHRoZSBiYWNrZW5kIGluDQo+PiBhIGRv bVUuIFlvdSdsbCBuZWVkIGdyYW50cyBpbiB0aGlzIGNhc2UuDQo+Pg0KPiBEdWUgdG8NCj4g ICA+ICpiYWNrZW5kX2RvbWlkID0gMA0KPiANCj4gRG9tMCB3b3VsZCBhbHdheXMgYmUgdGhl IGJhY2tlbmQsIHVubGVzcyB3ZSBpbnRyb2R1Y2UgYSBuZXcgYm9vdA0KPiBwYXJhbWV0ZXIg dG8gc2VsZWN0IHdoaWNoIGRvbWFpbiB3aWxsIGJlIHRoZSBiYWNrZW5kLg0KDQpBaCwgcmln aHQuIE9rYXksIGZvciBub3cgdGhpcyBpcyBjb3JyZWN0LCBzbyB5b3UgY2FuIGhhdmUgbXkN Cg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4NCg0KSW4g ZnV0dXJlIHRoaW5ncyBtaWdodCBjaGFuZ2UsIHRob3VnaC4NCg0KPiBUaGVyZSBpcyBhbHNv IGFub3RoZXIgaXNzdWUsIGFzIGluIHRoZSB4ZW5faW5pdGlhbF9kb21haW4oKSBjYXNlLCBh bGwNCj4gUENJIGRldmljZXMgY29tZSBmcm9tIGhhcmR3YXJlLiBTbyBubyB2aXJ0aW8tcGNp IGRldmljZSBjYW4ndCBjb21lIGZyb20NCj4gYW5vdGhlciBkb21haW4gYXMgTGludXggd291 bGQgcGljayB1cCBwY2lmcm9udCBkZXZpY2VzIG9ubHkgaWYgd2UgYXJlDQo+IG5vdCBhIERv bTAgKCF4ZW5faW5pdGlhbF9kb21haW4oKSkuDQoNCkkgdGhpbmsgdmlydGlvIGRldmljZXMg c2hvdWxkIG9ubHkgYmUgaGFuZGxlZCB2aWEgcGNpZnJvbnQgaW4gY2FzZSB0aGV5DQphcmUg Tk9UIGltcGxlbWVudGVkIGJ5IGEgWGVuIGJhY2tlbmQgZG9tYWluLg0KDQoNCkp1ZXJnZW4N Cg== --------------P0m4PEXFzTqOfClLS2QPVtlu 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----- --------------P0m4PEXFzTqOfClLS2QPVtlu-- --------------rmmZ4eqSM2lOw0qLVTm0Qj7X-- --------------DLuJiwko2Kg2MIwuzsl8lMGO 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/Ey8FAmleDRcFAwAAAAAACgkQsN6d1ii/Ey8O Bgf9G8+sfFm7x4hcIZlE8Zwdesn1tOhjOQ5MZGWLK9j5UDiigUzmTEpcvvoBqlW72uJjMfnv7iza wa8Hfx7RLxM2wB5NVucOIVya3FPb5MTwRgJAsLSVtsZFlXEK70wxsKtE1OetkD0vjQvawc1HNG/2 iKVWTCd3VUeaf9MaORuobhbPAtEcEtza2YFxzF0m4syNTvpavxFN60OmZw1z1jT9TI1A3ZnXJAM7 86qDx1k/q+Xt87Ap/1Rz7c/Q2rfjr03VdIGBjLt32FIdLQgYEOD28sPHQsMMwtDwLDC8UNT0L6C3 IMpWvM+MmAFrhmmSTZeaf5NaYxA2lo9lX9YL1hQTOg== =dL7J -----END PGP SIGNATURE----- --------------DLuJiwko2Kg2MIwuzsl8lMGO-- From xen-devel-bounces@lists.xenproject.org Wed Jan 07 07:54:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 07:54:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196540.1514332 (Exim 4.92) (envelope-from ) id 1vdON7-0004vy-AX; Wed, 07 Jan 2026 07:54:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196540.1514332; Wed, 07 Jan 2026 07:54: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 1vdON7-0004vr-4A; Wed, 07 Jan 2026 07:54:25 +0000 Received: by outflank-mailman (input) for mailman id 1196540; Wed, 07 Jan 2026 07:54:23 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdON5-0004vl-Bb for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 07:54:23 +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 1264e08d-eb9e-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 08:54:20 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id B8392405D3; Wed, 7 Jan 2026 07:54:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 366ADC4CEF7; Wed, 7 Jan 2026 07:54:18 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1264e08d-eb9e-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767772458; bh=IJfaPCj/Ro7N4LJzkmqwZpte1m5fLCvqEg3Yi9qSa/Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JegFElB4jfM6lIyqKfOUEJmukL5QcBuXQQCS1oWKX/mXqRH1La+ORK7qxKkRK97t1 UpXoiQVQFSfboQKHgYUuMFwg/5O3Rd81m1mG1lk7kajHvCCddaxg9zzvFJFzoCL5M9 DB6ldMtJc38E38hDgUAxRo6vz9wGXGEZncuXsCbDdWtoTWUNsvsd4MSZexskkOMrAG lmjCcWVP9uN1Gd7GSKAeLe0jYdbbdrZESH7yo63D9W5zhX9y49sK2mWwfo/1mCDcpC q+MP/ZYycMVhRnWG5yZ04253/4EDluvRHL7pltvITIR6/dH3lj7namEjrQJew9TpUd W2sBYSB/ZcG2Q== Date: Wed, 7 Jan 2026 09:54:14 +0200 From: Leon Romanovsky To: Barry Song <21cnbao@gmail.com> Cc: Robin Murphy , catalin.marinas@arm.com, m.szyprowski@samsung.com, will@kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Ada Couprie Diaz , Ard Biesheuvel , Marc Zyngier , Anshuman Khandual , Ryan Roberts , Suren Baghdasaryan , Tangquan Zheng Subject: Re: [PATCH v2 5/8] dma-mapping: Support batch mode for dma_direct_sync_sg_for_* Message-ID: <20260107075414.GA11783@unreal> References: <20251226225254.46197-1-21cnbao@gmail.com> <20251226225254.46197-6-21cnbao@gmail.com> <20251227200933.GO11869@unreal> <20251228145041.GS11869@unreal> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Jan 07, 2026 at 08:47:36AM +1300, Barry Song wrote: > On Wed, Jan 7, 2026 at 8:12 AM Robin Murphy wrote: > > > > On 2026-01-06 6:41 pm, Barry Song wrote: > > > On Mon, Dec 29, 2025 at 3:50 AM Leon Romanovsky wrote: > > >> > > >> On Sun, Dec 28, 2025 at 09:52:05AM +1300, Barry Song wrote: > > >>> On Sun, Dec 28, 2025 at 9:09 AM Leon Romanovsky wrote: > > >>>> > > >>>> On Sat, Dec 27, 2025 at 11:52:45AM +1300, Barry Song wrote: > > >>>>> From: Barry Song > > >>>>> > > >>>>> Instead of performing a flush per SG entry, issue all cache > > >>>>> operations first and then flush once. This ultimately benefits > > >>>>> __dma_sync_sg_for_cpu() and __dma_sync_sg_for_device(). > > >>>>> > > >>>>> Cc: Leon Romanovsky > > >>>>> Cc: Catalin Marinas > > >>>>> Cc: Will Deacon > > >>>>> Cc: Marek Szyprowski > > >>>>> Cc: Robin Murphy > > >>>>> Cc: Ada Couprie Diaz > > >>>>> Cc: Ard Biesheuvel > > >>>>> Cc: Marc Zyngier > > >>>>> Cc: Anshuman Khandual > > >>>>> Cc: Ryan Roberts > > >>>>> Cc: Suren Baghdasaryan > > >>>>> Cc: Tangquan Zheng > > >>>>> Signed-off-by: Barry Song > > >>>>> --- > > >>>>> kernel/dma/direct.c | 14 +++++++------- > > >>>>> 1 file changed, 7 insertions(+), 7 deletions(-) > > >>>> > > >>>> <...> > > >>>> > > >>>>> - if (!dev_is_dma_coherent(dev)) { > > >>>>> + if (!dev_is_dma_coherent(dev)) > > >>>>> arch_sync_dma_for_device(paddr, sg->length, > > >>>>> dir); > > >>>>> - arch_sync_dma_flush(); > > >>>>> - } > > >>>>> } > > >>>>> + if (!dev_is_dma_coherent(dev)) > > >>>>> + arch_sync_dma_flush(); > > >>>> > > >>>> This patch should be squashed into the previous one. You introduced > > >>>> arch_sync_dma_flush() there, and now you are placing it elsewhere. > > >>> > > >>> Hi Leon, > > >>> > > >>> The previous patch replaces all arch_sync_dma_for_* calls with > > >>> arch_sync_dma_for_* plus arch_sync_dma_flush(), without any > > >>> functional change. The subsequent patches then implement the > > >>> actual batching. I feel this is a better approach for reviewing > > >>> each change independently. Otherwise, the previous patch would > > >>> be too large. > > >> > > >> Don't worry about it. Your patches are small enough. > > > > > > My hardware does not require a bounce buffer, but I am concerned that > > > this patch may be incorrect for systems that do require one. > > > > > > Now it is: > > > > > > void dma_direct_sync_sg_for_cpu(struct device *dev, > > > struct scatterlist *sgl, int nents, enum dma_data_direction dir) > > > { > > > struct scatterlist *sg; > > > int i; > > > > > > for_each_sg(sgl, sg, nents, i) { > > > phys_addr_t paddr = dma_to_phys(dev, sg_dma_address(sg)); > > > > > > if (!dev_is_dma_coherent(dev)) > > > arch_sync_dma_for_cpu(paddr, sg->length, dir); > > > > > > swiotlb_sync_single_for_cpu(dev, paddr, sg->length, dir); > > > > > > if (dir == DMA_FROM_DEVICE) > > > arch_dma_mark_clean(paddr, sg->length); > > > } > > > > > > if (!dev_is_dma_coherent(dev)) { > > > arch_sync_dma_flush(); > > > arch_sync_dma_for_cpu_all(); > > > } > > > } > > > > > > Should we call swiotlb_sync_single_for_cpu() and > > > arch_dma_mark_clean() after the flush to ensure the CPU sees the > > > latest data and that the memcpy is correct? I mean: > > > > Yes, this and the equivalents in the later patches are broken for all > > the sync_for_cpu and unmap paths which may end up bouncing (beware some > > of them get a bit fiddly) - any cache maintenance *must* be completed > > before calling SWIOTLB. As for mark_clean, IIRC that was an IA-64 thing, > > and appears to be entirely dead now. > > Thanks, Robin. Personally, I would prefer an approach like the one below— > that is, not optimizing the bounce buffer cases, as they are already slow > due to hardware limitations with memcpy, and optimizing them would make > the code quite messy. > > diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c > index 550a1a13148d..a4840f7e8722 100644 > --- a/kernel/dma/direct.c > +++ b/kernel/dma/direct.c > @@ -423,8 +423,11 @@ void dma_direct_sync_sg_for_cpu(struct device *dev, > for_each_sg(sgl, sg, nents, i) { > phys_addr_t paddr = dma_to_phys(dev, sg_dma_address(sg)); > > - if (!dev_is_dma_coherent(dev)) > + if (!dev_is_dma_coherent(dev)) { > arch_sync_dma_for_cpu(paddr, sg->length, dir); > + if (unlikely(dev->dma_io_tlb_mem)) > + arch_sync_dma_flush(); > + } > > swiotlb_sync_single_for_cpu(dev, paddr, sg->length, dir); > > I’d like to check with you, Leon, and Marek on your views about this. I agree with your point that the non‑SWIOTLB path is the performant one and should be preferred. My concern is that you are accessing the dma_io_tlb_mem variable directly from direct.c, which looks like a layer violation. You likely need to introduce an is_swiotlb_something() helper for this. BTW, please send a v3 instead of posting incremental follow‑ups. It's hard to track the changes across multiple small additions. Thanks. > > Thanks > Barry From xen-devel-bounces@lists.xenproject.org Wed Jan 07 08:03:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 08:03:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196559.1514342 (Exim 4.92) (envelope-from ) id 1vdOVN-0007FW-Ko; Wed, 07 Jan 2026 08:02:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196559.1514342; Wed, 07 Jan 2026 08: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 1vdOVN-0007FP-Fu; Wed, 07 Jan 2026 08:02:57 +0000 Received: by outflank-mailman (input) for mailman id 1196559; Wed, 07 Jan 2026 08:02:56 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdOVM-0007FI-BG for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 08:02:56 +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 459ce70e-eb9f-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 09:02:55 +0100 (CET) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-42fb2314f52so844361f8f.0 for ; Wed, 07 Jan 2026 00:02:55 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0e16f4sm9144302f8f.11.2026.01.07.00.02.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jan 2026 00:02:54 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 459ce70e-eb9f-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767772974; x=1768377774; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=zsypaM5Uq+N9ETzIqEmeMHTI8+kHzqO5OjLxgZDUHFI=; b=RpDKZ90sC+lHqyasyXbYIGVn29WMZMe5NY6Gg9eD34+wrBcsqxniSCMCUy3rsjZ9mQ e+lC0fKd7YyvjaEH7E+5IbhCYngvPh4wtMnfXpO+r71o3BI4QKLJ1Zx56JFr530m6Cu8 a6jdN5yhZ/v64s1v2TG1FW26ncQHM+EFOQX1nMeZbrFrmxR42tQZuDDsvlTRRdvS6kWM ORxqcmSZwBWpoqhwO+w+AJ24V5nlhk2GL0fvuF1mztUIGfnhgSei4HdHOMXSZJkUy407 cunjH20vC7aURYLZ7lycCS2Y44d+w9pigUkUwR9KRegmEM7DK6uPVjfc5jZf94yZ2oRR 9Kmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767772974; x=1768377774; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=zsypaM5Uq+N9ETzIqEmeMHTI8+kHzqO5OjLxgZDUHFI=; b=YeCsB0i8vYC91UCIFgNrbQq/t111iGg9JE/Iixg+0qCZIHvhS+AmK8kLZgdgsO1KO4 h7ifs/iuLoc4enqZPGEDkcy47mG59UQPk2u1yEwLNm2m7ycxhglh/ZDxGFo0RJMGRkVq yD9An4fdNAa13TGRFpEqwkoe4d9iTBfnVqA72emtbhn8BeOIXGhFB8R+f5AmPbGUb/bs iwZzHoX+2iPnqI2BzPMFsIiDd2KpmKASPV6I43+ILGnSFfGnQxIHt/QEh0Oo3re3Fczy wELy0iNRSujoQ/nLAkWMCi4uho812Lb6ieofsNQbSZKmxWcAyHtvdOgHNCgVW2jfJEos OW0Q== X-Forwarded-Encrypted: i=1; AJvYcCVotAvav3hGizPUzn35YbI2k4221s907tTA8Gf9xtFrN8O6emmUh5VBNUIxxOt5ne0/73rimbkOy1U=@lists.xenproject.org X-Gm-Message-State: AOJu0YxcEMqjzeacXHAVs57wC7e9NM5zzueufbLrYi1ACIr3VgVvVyEt gp58j73nRf3PSP5Qa2ILA7WWg+ZhMQTw+P4d4uju8EFPJUlEA+FVTSSOWGv5OA629w== X-Gm-Gg: AY/fxX4Vf5Mnv+7Z9+qxsrNuNEsPUgmEj6PJk+LoITWKhcqaSm0NRt98SuEmPhM5MFv 2E/+ZNXtLqEOypkQQQYZ+SHTzmpOfa4gRkiDXWSukFKBl6a/hEpqueJrOTBS2L6wZPpEcNEWTyc O8dV7w6HFvZ2TH/Ec+i9x+0bXdnk0zPsfaGq/P2+rPm7dv1h4RqJRPJ8ISDPGUq77v+z3QcWQUZ gICY2O5pY8cktp5TGiBuLFuTALLTOorIJ7I6wNqGtS5x/+Mlji6jhjc/U21wYLCz80mOteSrV8u Imb8kIyNXHeqGuBDnqQC3frrfjFtYOeeWB6KOIvIUbbKYrIG0MHvj8KTYn3udHj/00CfmFnDBnM bbcdZJtuB/12Ri/gq1bn1NuEW0Y0jQDYtKAOi53dF5T2rJqCM9nfhX+G8ijlbrboTzlMKaJKVmH FvOeF6pfUWdIjFrL4nQ90L6I2r0erzA1/N6zhI0qzlmjZ8K8aQjY3Zu2kDZIEPjNNDMjjFiZHtP +g= X-Google-Smtp-Source: AGHT+IGDZ0fia1crls+ZyKobc1ypIDPxF84oxQxtD4mmUWc+2YjOH3HnDg6Q5/pT6uTTN6caUVuNIA== X-Received: by 2002:a05:6000:24c4:b0:430:f68f:ee82 with SMTP id ffacd0b85a97d-432c37a6fafmr2081220f8f.54.1767772974516; Wed, 07 Jan 2026 00:02:54 -0800 (PST) Message-ID: <794c382b-3b20-4d2a-ab70-b24d7fdf88ae@suse.com> Date: Wed, 7 Jan 2026 09:02:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() To: =?UTF-8?B?0JDQvdGC0L7QvSDQnNCw0YDQutC+0LI=?= Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> <4a6b6307-9014-4c4c-8c23-3673efa2d1b1@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: <4a6b6307-9014-4c4c-8c23-3673efa2d1b1@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06.01.2026 21:10, Антон Марков wrote: > Hi, I'm not sure about the other places. In hvm_load_cpu_ctxt > (xen/arch/x86/hvm/hvm.c ), it was easy to catch because > process_pending_softirqs is frequently called there, which in turn > processes softirqs from the timer (where the timestamp is updated). > After I fixed sync_tsc in hvm_load_cpu_ctxt, the problem stopped > reproducing under no load. However, when the number of vCPUs is 4 times > greater than the number of CPUs (under heavy load), the problem rarely > reoccurs (mostly during snapshot restores during > process_pending_softirqs calls), and this is no longer a simple case. If > get_s_time_fixed can indeed be interrupted during execution after > rdtsc_ordered, then the current fix is ​​insufficient. It's necessary to > atomically copy "t->stamp" to the stack using local_irq_disable and > local_irq_enable (as in local_time_calibration), and then work with the > copy, confident in its lifetime and immutability. But until > get_s_time_fixed is proven to be interruptible, this is premature, so > your fix is ​​sufficient. I think I need more information and testing to > say more. While the cpu_calibration per-CPU variable is updated from IRQ context, the cpu_time one isn't. Hence t->stamp's contents cannot change behind the back of get_s_time_fixed(). I wonder whether ... > Regarding the other scale_delta calls, if they include values ​​> calculated from externally saved tsc values ​​that could have become > stale during the process_pending_softirqs call, this definitely needs to > be fixed. ... another similar issue (possibly one not included in the set of remarks I have in the patch, as none of those look related to what you describe) might be causing the remaining, more rare problems you say you see. That set of remarks is actually a result of me going over all other scale_delta() calls, but of course I may have got the analysis wrong. As to using 4 times as many vCPU-s as there are pCPU-s (and then heavy load) - while I don't think we have a support statement for such upstream (when probably we should), iirc for our (SUSE's) products we would consider that unsupported. Just fyi. Also, btw, please don't top-post. Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 07 08:46:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 08:46:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196573.1514351 (Exim 4.92) (envelope-from ) id 1vdPBY-0003xL-Ih; Wed, 07 Jan 2026 08:46:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196573.1514351; Wed, 07 Jan 2026 08: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 1vdPBY-0003xE-FQ; Wed, 07 Jan 2026 08:46:32 +0000 Received: by outflank-mailman (input) for mailman id 1196573; Wed, 07 Jan 2026 08: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 1vdPBW-0003x8-OA for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 08:46:30 +0000 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [2a00:1450:4864:20::329]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 535c11de-eba5-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 09:46:15 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-47d63594f7eso10854175e9.0 for ; Wed, 07 Jan 2026 00:46:15 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d8384646fsm50965975e9.15.2026.01.07.00.46.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jan 2026 00:46:14 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 535c11de-eba5-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767775574; x=1768380374; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=zAVbi728WuF7QBuMeLZiS48gck7F1ciPMFRLqn+3jLk=; b=FQQ1/KgeWQ2xj2NEsJAsJvSguumtKljKIvmbIHUq99BFZ3cIiOwKrXqy04tx/2tppD RMfz5KrtRaB0vVjQkFAYyG58KJjOjnWBE4V/3G3Qw36LOQTkrEi1tImLHDBDeoqOqsuJ 2DsBkVgFdeEWROTX53f6ZY/C0ecqBDWkhXVtSr1NqgiwH+DnMg3Yyf/JSqQT2mpXtlpv aJ88Kan1RzOSAdLOHhHvwxD1bzaiAV6mUlJO/Miv0tiKQ7hJuPyAaTBjeAUoS8Cpkaz4 N23MN9rwBTiAAVXD57bPGshvThdNcGfPg8xAbb/KPQBoBbqCTKRtosigbXkG+h81i5Ty 5a2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767775574; x=1768380374; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=zAVbi728WuF7QBuMeLZiS48gck7F1ciPMFRLqn+3jLk=; b=CDw7zVCgivyQ7Xy7b7Lh8Qo+HxXMRegK42c8DzLxpyPeHKaO8nTyA46zw96y0O5cq9 xoT0tfEF07NSqMoR1SgYQcokZDU7osGLjiXWoCovSZY+IV6VwufE2zpZP7PGaiK/dHxK Jdz0+hbQhbF6xR06bvAY7kH4xjUPJjW1QBqnqOWxrasdkWaWoN/pm0Yeihbq6k52lGcb fDLk0wH9scNHRbwYBBzya8xydwfPTEVuhkeZLYqwZ/K6Zj3CPmkau4LHQaCAFY52IrFT R6Wjre5rux9ZiTfI1l2eDooh+HeY1YN6OMenZnKfvEuARJzUbIxWWj8+0PWSFRYE2qbQ xhxA== X-Forwarded-Encrypted: i=1; AJvYcCXPgAcixq3XjWir08MPyMJeUqTbx6pejxhQQH6qvQRHr3Rq2UbGbnUpjRnVRDr4So7nHsr0jTq8Kt0=@lists.xenproject.org X-Gm-Message-State: AOJu0YzNsqpqKuL0E6HVsZ9n88xjL82SxsUiYqx/2sJuy0Vlj58tKMb9 i8XtQrUqwYlXjPAlyC3ERtQQbe+e8WXbKZtzWdHJzvXOCDFsCS/5Qvaw28/xE11BSw== X-Gm-Gg: AY/fxX6WBiXthMK95yQWFzc7mIcHpJ8lRWjuq3q29V0odWN879gGzyoEzzB46tDI8qM 61xC1Ks/6AGiqoZ16135EGfjmwXoWoGfvVSXG8gErQpVf6q6mRWAlYxg7i5lktZqwvIp5M6/cox Sun52IDyCG5SS8jnVrDoeUNdT3WNV+Agy/CbRPSU7CLfzGb9r7xR+rTRn/2ieA6ykPkTs62SEG/ o/v7TJFaQzU6VVFJF236lwj2nUOXbXE7jWErvZYCTigfY6xCfvA+XpAy/hF3Mr/zJ10ACtaEMtC Df44AEkehfJP5ZIctqkrINAICbZA/AwdtcUJUa29f9ogHARQ9TN7asQR3fNsU3ACpJglFdBVeaD fw4cyIwX05g9unnf3Foo0NjvK7fTPSP3MD1CXAPFL+b/BLJjFjNFo5fiSyNTVkGuqb1zc3KPSGC X6Xr/k2s1w53V5RrHLwGOYE//HQGjJ2zcLlFza9pHZ2bpefKsO0pvzh03iT5pSFlHXFyYU9y2uv HFyEs+Ijpg5pg== X-Google-Smtp-Source: AGHT+IGq4J7r5weGwOCqe3LFFQpjnwuwFOqWHoNVZsv1J76WUXsJk08j08085mNsc/nRT2y/gZYhEg== X-Received: by 2002:a05:600c:4447:b0:477:3e0b:c0e3 with SMTP id 5b1f17b1804b1-47d84b3b8b9mr17239285e9.32.1767775574450; Wed, 07 Jan 2026 00:46:14 -0800 (PST) Message-ID: Date: Wed, 7 Jan 2026 09:46:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 03/15] xen/riscv: implement vcpu_csr_init() To: Oleksii Kurochko Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 24.12.2025 18:03, Oleksii Kurochko wrote: > Implement function to initialize VCPU's CSR registers to delegate handling > of some traps to VS-mode ( guest ), enable vstimecmp for VS-mode, and > allow some AIA-related register (thier vs* copies ) for VS-mode. The henvcfg setting isn't covered here at all, unless I'm failing to make the respective association. Nor is the setting of SMSTATEEN0_HSENVCFG in hstateen0. Overall it feels like the description here is too terse anyway, as the bits set (or not) are a pretty crucial thing for running guests. Then again maybe this is just me, for not being a RISC-V person ... > --- a/xen/arch/riscv/domain.c > +++ b/xen/arch/riscv/domain.c > @@ -3,6 +3,67 @@ > #include > #include > > +#include > +#include > +#include > + > +static void vcpu_csr_init(struct vcpu *v) > +{ > + unsigned long hedeleg, hideleg, hstatus; > + > + hedeleg = 0; > + hedeleg |= (1U << CAUSE_MISALIGNED_FETCH); > + hedeleg |= (1U << CAUSE_FETCH_ACCESS); > + hedeleg |= (1U << CAUSE_ILLEGAL_INSTRUCTION); > + hedeleg |= (1U << CAUSE_MISALIGNED_LOAD); > + hedeleg |= (1U << CAUSE_LOAD_ACCESS); > + hedeleg |= (1U << CAUSE_MISALIGNED_STORE); > + hedeleg |= (1U << CAUSE_STORE_ACCESS); > + hedeleg |= (1U << CAUSE_BREAKPOINT); > + hedeleg |= (1U << CAUSE_USER_ECALL); > + hedeleg |= (1U << CAUSE_FETCH_PAGE_FAULT); > + hedeleg |= (1U << CAUSE_LOAD_PAGE_FAULT); > + hedeleg |= (1U << CAUSE_STORE_PAGE_FAULT); > + v->arch.hedeleg = hedeleg; Wouldn't you better start from setting all of the non-reserved bits, to then clear the few that you mean to not delegate? Then again I'm not quite sure whether the set of CAUSE_* in the header file is actually complete: MCAUSE also can hold the values 16, 18, and 19. (Otoh you have CAUSE_MACHINE_ECALL, which I don't think can ever be observed outside of M-mode.) Also, while it may seem to not matter much, sorting the above by their numeric values would ease comparison against the full set. > + hstatus = HSTATUS_SPV | HSTATUS_SPVP; > + v->arch.hstatus = hstatus; Why would these (or in fact any) bits need setting here? Isn't hstatus written upon exit from guest context? > + hideleg = MIP_VSTIP | MIP_VSEIP | MIP_VSSIP; > + v->arch.hideleg = hideleg; Again I think having MIP_VSTIP in the middle (to establish numeric sorting) would be slightly better. Also there's a stray blank after the first |. > + /* > + * VS should access only the time counter directly. > + * Everything else should trap. > + */ > + v->arch.hcounteren |= HCOUNTEREN_TM; Why are this and ... > + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) ) > + v->arch.henvcfg |= ENVCFG_PBMTE; ... this using |= but the earlier ones simply = ? Unless there is a specific reason, consistency is likely preferable. > + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) > + { > + /* > + * If the hypervisor extension is implemented, the same three bitsare > + * defined also in hypervisor CSR hstateen0 but concern only the state > + * potentially accessible to a virtual machine executing in privilege > + * modes VS and VU: > + * bit 60 CSRs siselect and sireg (really vsiselect and vsireg) > + * bit 59 CSRs siph and sieh (RV32 only) and stopi (really vsiph, > + * vsieh, and vstopi) > + * bit 58 all state of IMSIC guest interrupt files, including CSR > + * stopei (really vstopei) > + * If one of these bits is zero in hstateen0, and the same bit is one > + * in mstateen0, then an attempt to access the corresponding state from > + * VS or VU-mode raises a virtual instruction exception. > + */ > + v->arch.hstateen0 = SMSTATEEN0_AIA | SMSTATEEN0_IMSIC | SMSTATEEN0_SVSLCT; What is SVSLCT? Bit 60 is named CSRIND in the spec I'm looking at, and the commentary above looks to confirm this. Also, wouldn't you better keep internal state in line with what hardware actually supports? CSRIND may be read-only-zero in the real register, in which case having the bit set in the "cached" copy can be misleading. (This may similarly apply to at least hedeleg and hideleg, btw.) As to consistency: Further up you use local helper variables (for imo no real reason), when here you don't. Instead this line ends up being too long. Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 07 09:27:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 09:27:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196586.1514361 (Exim 4.92) (envelope-from ) id 1vdPoh-0000S5-JD; Wed, 07 Jan 2026 09:26:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196586.1514361; Wed, 07 Jan 2026 09: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 1vdPoh-0000Ry-GD; Wed, 07 Jan 2026 09:26:59 +0000 Received: by outflank-mailman (input) for mailman id 1196586; Wed, 07 Jan 2026 09:26: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 1vdPog-0000Rs-Lq for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 09:26:58 +0000 Received: from BL2PR02CU003.outbound.protection.outlook.com (mail-eastusazlp17011000f.outbound.protection.outlook.com [2a01:111:f403:c100::f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 02e08139-ebab-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 10:26:57 +0100 (CET) Received: from SA9PR03CA0025.namprd03.prod.outlook.com (2603:10b6:806:20::30) by DS2PR12MB9663.namprd12.prod.outlook.com (2603:10b6:8:27a::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Wed, 7 Jan 2026 09:26:53 +0000 Received: from SA2PEPF00003F67.namprd04.prod.outlook.com (2603:10b6:806:20:cafe::31) by SA9PR03CA0025.outlook.office365.com (2603:10b6:806:20::30) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.2 via Frontend Transport; Wed, 7 Jan 2026 09:26:45 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SA2PEPF00003F67.mail.protection.outlook.com (10.167.248.42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.1 via Frontend Transport; Wed, 7 Jan 2026 09:26:52 +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; Wed, 7 Jan 2026 03:26:52 -0600 Received: from satlexmb08.amd.com (10.181.42.217) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 7 Jan 2026 03:26:52 -0600 Received: from [10.252.147.171] (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, 7 Jan 2026 03:26:50 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 02e08139-ebab-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=cTx9LEB5PfslRLAQGZ4/dKH2WsyQqPx8H5j/Z1fneZ6ZBEd07ZgmHLsaBigqWNyb1pGagaPzI2WZXzq8CquQvbw4lKXn7yTXa0JtXRee3e8xX/r0Vdqu4hEkwHO22EI9/MYkhxLZY0KNGK7hkdXSCjzsyOflJOXhXnFTZAhYWBqspOu9sgw8e69tH85DH5IPo3j90xHJi3rzOKju8atqpBCgMIJGvsRJpRcKK+ZD77HG1TZpmguw1GmHjLdahonXbiYfgZF0UXktWysNhYrfOMNOTix2/r0g50+AvBmuHMeqS8B8OaDzb1bTTxnwNB8VTKUAjaq+5RSIzAzmBmOCCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZYLwJKGF2Zmr9o6J084P8prhRYOwg6LglebErqqr/+c=; b=Vgx8puBCNNdVBQd8oKjTgkgvZPqXLt6KAk9pMnEUlPxiHwjq7/aDBJvoYIok1k+xdYUCoiHU8PONT2WCo8R1noqBg4awMBwYWymw/6ZmiQtFke51/+xXeJD9BeqGCJrWb7o2PC8QB00cjYU+ud/qGKLPUcEdXIBH7darymMNNRc2Yo+qfsyfC1jKMQwWvHrwEIgHUhg9bOUQCezCw0eqo8VDCYSknV2OG9QIZTUiXlWSFeRnCqk1GgcfYJEq9TlIevnf/O7Qn+pzuEgbkafJvuLBX2ddKTmDj029mSpQLHraKt3Banxc31Y5wWOsEhjhZunIt5FoIZ9u5w0Cu2hmGA== 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=ZYLwJKGF2Zmr9o6J084P8prhRYOwg6LglebErqqr/+c=; b=qzPm1a29hlLVEK28OB1lsLgscJmc5wInTpmkfKbEurWgjlUEOH6M3Q8vzMe7z9zfBRRYSY0L6N+OZKTNINhkpjoUnxyF8yYknIfgvizDsFnMd4BAUDM+i/l8iKrOLudPjycrX1BX3grsVx9TEVRBeQoJsOO9vizq6d4MHW6elnc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: Date: Wed, 7 Jan 2026 10:26:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/5] arm/time: Sort headers To: Andrew Cooper , Xen-devel CC: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Julien Grall" , Volodymyr Babchuk , Bertrand Marquis , Oleksii Kurochko References: <20251230135050.188191-1-andrew.cooper3@citrix.com> <20251230135050.188191-3-andrew.cooper3@citrix.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20251230135050.188191-3-andrew.cooper3@citrix.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA2PEPF00003F67:EE_|DS2PR12MB9663:EE_ X-MS-Office365-Filtering-Correlation-Id: 80c59efe-3716-4a1d-4ca7-08de4dcee4c4 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?ZU9MSnFRamJzR2tyV1NMV2tWSm5sc25jQnJJVmd1emkxVllzK21yNkhRbHIx?= =?utf-8?B?WUJIbjdTOUkvYmlrM0tZR3lqdkFQR1NmMmZFR2l2Tml3YU9zZWt2VXdhaUY4?= =?utf-8?B?NldLM281ZnpMZnoyZWRwV3ptS2N1MnZnbU5lcVVIeFRtdlJlcHBMRDZHNkVN?= =?utf-8?B?dHJtUjZKU0FLMkJ1NHRlZ0czaVlyUCs3ZHFCai8zRHhwK3lsTUMrcVhob21h?= =?utf-8?B?emgxY1FXL3RudGtwMklIaEpqZy9OdldQeWlTMGdPOWY1MkpZRkgwMkFsWEpt?= =?utf-8?B?cy9uTXlSTGNIbU1lcnJkejZGbXJLRSt6clVjaFkrZkxORzZnRndqZm13N0FV?= =?utf-8?B?cVBxOTJ4enZURFRVSTFDemJJbmlNVWE5SW53bDMxdWNrRWhXMXhCNGV4M0R4?= =?utf-8?B?RTR0dktyWk1OSlgvV1p6S0pLQW9vTlFhYmZqZStZVkNWYnBMZm5heFBzVU1m?= =?utf-8?B?emJ0YkI5b01tZTJnTjR4cmxkSkdLS01mWFkrL3VYcFNmTkxTM3pkdDNZTDZP?= =?utf-8?B?d2tqYUpJUmhDRkZoOU5WcExMYTE5T3pMMXZFaUFZRENUeHVzZTN6VzI1S3o2?= =?utf-8?B?ZmU2ZmN2RnN3QlpqbnpwTnJQQ2tnblFubitpdVFZdnV0Vm5HVktnV09QRTB3?= =?utf-8?B?MFB0TG95Mm9yeENUeXZiVm50cVBkWWE5ZSthRXBKVmxoWlhyYVV3TjlVc1Bo?= =?utf-8?B?NzVrU1NzRGp3eC9vYnhkQVJSTFNGcEdEcnFvNHdIV1FaakwzMnM0eHZsU1Aw?= =?utf-8?B?U0RwOWVaR0puL2ptZVB1b2owK2ozUnliM2pTRVY0bUtvVjNscVBJa3pkbUVs?= =?utf-8?B?WXZXQ1lNdXZ5WGtGTXQ1V2hQbngrQUNIWW51ejUrVjIrYlNWSExDQTAxeENm?= =?utf-8?B?Rm54K0lIOUVleThEL1RkcmY0T1Y4b0xkZUllVzVXdDRiMERBT0R5a3plNDd6?= =?utf-8?B?bTNxdWFpMGg1L3FNV29RbG40L2ZpdTkzWU9NUXZaQkNmdUJjK2FPUys4ZUFG?= =?utf-8?B?L3YvdVFVSkRPOGlpMkFYTSszcHRuWWxadmxKWVdDbVdwWFNudFZ2b1lJT2k0?= =?utf-8?B?UFdOQTZ6d0p6UmpsVTVjRG1mVU9ZRzBkWFVub05oeVQyaU84VUFNbXlLeDNa?= =?utf-8?B?eGdlZHhaM1RjdVdFSVc2bzA2Y2djZFdFcFJLU2o2K3kzTFZhc3FXS0NEZmJE?= =?utf-8?B?R0pmSkVkc2IwU29qelNhRWkvQUwyQUNmWmN0TjYyM1lzT0MxR2ttZVNncXlw?= =?utf-8?B?RUFoWFlhZ1liODNHU3VqNlB4TWwwTlhBN0tmRVhzNzk3b3QrWmZyazE4UDJE?= =?utf-8?B?ZTBqdnM2T0NiRkpEUFVRVHN2cGZBc2ppakt5T2E4UWRQUmVUVjZvaGhVZUw5?= =?utf-8?B?cUVSblhHSU52Yzk4R0NUdUlZOEs3YmEvVHAxZE9KWSsvaGRuWjFjNENnRlF0?= =?utf-8?B?YVpwcEJPOGxJY1ZNQ2RSNWxnejdsSzNmbDZxY0xuN0JjeGY1d2RncWs1RXJv?= =?utf-8?B?NUl3NTJMRTIwTDB6ZzRPYWpFcG9zd0xTUUZ0Vk9zZ1JLN2lTejkvalM0TFhR?= =?utf-8?B?M3VlOFJsSzk2a1BwWlg2MlExdFUvU1krQzIxVlJxbWR0am9RTjJSVUFUQVow?= =?utf-8?B?elJVOU9mNVVwck5obGo5K0tJZk91dEdGbWlwbWlYN3NPTDNoMndmMTdsbGFV?= =?utf-8?B?Zm1vZndDSFcyN1FzeVVYVk1KRlBzRFpNMXJjdCtSZ0RYU3lYeGpZd1ZFekZm?= =?utf-8?B?V3NNZ2dqZ1ZxLy95ODJlYlMwVDhVdUMyb1BFZHlZdSt2MlNLVXRjbEh1cEF6?= =?utf-8?B?N1p3UFd6ZkVPeUFEVkxnZ1FpUmlqeGo3RVBUN2R6bDYyRncxVmRFZHlDMGdG?= =?utf-8?B?RThmVFFNdVd4eTdyTkVlS3kyRWUwUHNXbzhuRVN1NUFJMkd5YjBFckNCdGMv?= =?utf-8?B?d2tHTXcvRHEveXRsQVRMV1JjM1d1SGhpK3FDalZZYVZQWHd6M0llU3JLd3Rv?= =?utf-8?B?ejYxcGNYdHFraGpZa0MyTUNnZ1dCWkVEbnpVODd6U01kNGZYcEpDYTE0WHFy?= =?utf-8?B?VStjZGhNWFlwUG4rWjVqdHBEOTlOMmlLNkZpVWhIa0tCYytaRUhyYjFBeG5l?= =?utf-8?Q?pgZQ=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700013)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2026 09:26:52.9152 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 80c59efe-3716-4a1d-4ca7-08de4dcee4c4 X-MS-Exchange-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: SA2PEPF00003F67.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS2PR12MB9663 On 30/12/2025 14:50, Andrew Cooper wrote: > ... in preparation for a logical change. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Wed Jan 07 09:28:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 09:28:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196601.1514370 (Exim 4.92) (envelope-from ) id 1vdPqY-00010q-WF; Wed, 07 Jan 2026 09:28:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196601.1514370; Wed, 07 Jan 2026 09:28:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdPqY-00010j-TT; Wed, 07 Jan 2026 09:28:54 +0000 Received: by outflank-mailman (input) for mailman id 1196601; Wed, 07 Jan 2026 09:28: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 1vdPqX-00010d-V1 for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 09:28:53 +0000 Received: from SA9PR02CU001.outbound.protection.outlook.com (mail-southcentralusazlp170130001.outbound.protection.outlook.com [2a01:111:f403:c10c::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 473aa49e-ebab-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 10:28:52 +0100 (CET) Received: from CH5P223CA0017.NAMP223.PROD.OUTLOOK.COM (2603:10b6:610:1f3::13) by PH8PR12MB7160.namprd12.prod.outlook.com (2603:10b6:510:228::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Wed, 7 Jan 2026 09:28:47 +0000 Received: from CH1PEPF0000AD7B.namprd04.prod.outlook.com (2603:10b6:610:1f3:cafe::70) by CH5P223CA0017.outlook.office365.com (2603:10b6:610:1f3::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.2 via Frontend Transport; Wed, 7 Jan 2026 09:28:45 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by CH1PEPF0000AD7B.mail.protection.outlook.com (10.167.244.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.1 via Frontend Transport; Wed, 7 Jan 2026 09:28:46 +0000 Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 7 Jan 2026 03:28:46 -0600 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 7 Jan 2026 03:28:46 -0600 Received: from [10.252.147.171] (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, 7 Jan 2026 03:28:44 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 473aa49e-ebab-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=RPWXYHpYGShufnPfGbuxYGQHOoK8VRQvaU8CEIC0BwLAgSyuNqH72oTKwkpa158M/BMe3U047fnBRSn0+RY8BnQh+jYUmNOfbh/V+gvJNyzectBp9undCaO8s+EfrZSNc4bAM+tYZxBSIl+rN1YasHyBQ152xr6OCXToUvFzlJGlWGxGLX2s1WGeQ4nj6FmGu7AA/QW4NqNBl55Xkzy7W/pjBDcFmpZzProRBpfjD744Qwg3di6uKuSvphpabs6Fpwq52ZMqlrqld8LTBrROsmaxuXj+inc5Unnkm65BGN8OHAASfLN8/E5ArIhbW9Xe7AdLkcxjk3ktWyn3acAwyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UoDb6Q8KguDMR7LN1tfDEbuUdx8ct0CfkvN6WWC19FU=; b=FMo2FkrMpZVXFGt3h666nKnpbx2Lsrxqv8/glRoZ9k1EROhcA2d3VcS/s7kZdYsSPVDmAuskzhocLMMXqxNBnKTWF0hc01vWPmR53m+13u+MHYwH/4DGkh8ULCyzesACkW7+uHRYm+CTpo/V3wfffrd2Lxni6C6XkRi9wVpj0cH6Eve1pGIPueWxFhUjgHjTzgvOMeSSB6pSXUOoBT9AHTNUpWhaEu9zDhQE28ecQDqh2fwFmJdXVKcE5ZzdH6HIWqJBXzw8mLo5hssXsv8pDWNjExTJzNMVFoe2A5OP03mbebSgDi4TztLteuJHqQuw+vmaUreQDi6jMe3C87GRNg== 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=UoDb6Q8KguDMR7LN1tfDEbuUdx8ct0CfkvN6WWC19FU=; b=iaFcnTcBw2RX4JBJBbL0KJWF5pL3I3qHqGVP59gULyxbXKKMRMYv3BpVVPY7PvxxIHVbhSUlJQ2oJnuqx1NT96SNauNjFT4etIrDdDL43ZiBFcwKvhUbWuZphy3gc0tPy0WyqbxcyDJcH89/KRltZo05cvBeRnVzJw84DQRbfdU= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <5e8ecd71-38c6-4844-919d-d2e97c088038@amd.com> Date: Wed, 7 Jan 2026 10:28:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 4/5] xen: Split muldiv64() out of lib.h To: Andrew Cooper , Xen-devel CC: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Julien Grall" , Volodymyr Babchuk , Bertrand Marquis , Oleksii Kurochko References: <20251230135050.188191-1-andrew.cooper3@citrix.com> <20251230135050.188191-5-andrew.cooper3@citrix.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20251230135050.188191-5-andrew.cooper3@citrix.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH1PEPF0000AD7B:EE_|PH8PR12MB7160:EE_ X-MS-Office365-Filtering-Correlation-Id: 74d6b14c-19e5-43ae-74f2-08de4dcf2899 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|376014|36860700013|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?REx0WUx3bnAxVWtzeWxvRUxxTEd2QzRocFQvS0s0UnlFSjBLWWhTeFIxZGVZ?= =?utf-8?B?NzNwd3JjaDJudTh2eS80TTM5ZlNWZ3IrRU15V3FOcTRSc28xdk55bWpvTnp4?= =?utf-8?B?U3BlUC9vT0w3NTBMR0dMdUhhblh5VWdhUVg0SnhmSjBkQVNOa25yNmNYNitF?= =?utf-8?B?Sm9IQVBCb3VxTEV2L2g4TkFNREwvMUxBcUZrSSsxRjVZN0lHeHBsd1IyeTh4?= =?utf-8?B?WU1LYWxrWjYwNGFicGJFODc2b1FTRXNjM1pDOW1ZWDh4RTB2aGJobkwvTHhl?= =?utf-8?B?OE45bi9uNDROampPQ1NqOXpuSGNIZDFJNWJqUXpZT1FRbFQ2SElhVHpWd3Fi?= =?utf-8?B?Tmp2VzJlcHZNZ20rT1BveFJYUEYzZ0t1ZEVjaUNRUGNpckt3b1A0N21qcnlE?= =?utf-8?B?MjROQUhvWVRvdTQzQnpaUUloc1BpWXJ2ZkxmUFFRUFJYVkMrbzYrWExzNExF?= =?utf-8?B?azFPbVU1VXc4MW05aklMb0ZVd3dINHNyWURqb25YVkJJYnpieFRuekRwRzQ5?= =?utf-8?B?Y2p3dmxiTEZXUzV0YUZ3WVQwbEpObDQ5TlFrbllPQXdjK2x6SHRWVXgyRkNu?= =?utf-8?B?LzlDckxic1l6OGFFc010KytGNGVtQ3JEc1JxbTRhek1qUjQ1cmttK2FOUzNp?= =?utf-8?B?VGhnSDRnbWNOMk9OcDlpdVVDcitMa3NsZXVJQVdWMjZPMmwvaWMwN2dDOC9H?= =?utf-8?B?Ri80NnR1cTRnK290UHVZUk9ySDRxcU0yN2tKcHZ3ZndFVWdQdkFZWGxCVWor?= =?utf-8?B?NzlxdDBoVm5iSUZFK1Y1V2RWUHpZaThKNk9ISDdBMU9vRmh1QjhrVlNiQ1hN?= =?utf-8?B?YzBOWHdwVjdXeXErMlo5c0FyemdrNlNaaUs2bGk0blE1R3hGZFRaQkdGN0Jx?= =?utf-8?B?NmtzNlZWbVJvQzRzczNMU1hMaGNiK3dJRVQrYUJJb3BDMGlPMmlzL0RLeFJo?= =?utf-8?B?MjZSbG00Ri9aMmhsUUFmZmU4UEozb0UrdFZHWjlIL1V1MStqeUFUWGg3TUt1?= =?utf-8?B?NzR6Q2FVTjRnR2huMGwzckROVmpGZjJGUVk3cCtia2xyMk9kN0kyUXVxU21i?= =?utf-8?B?NjgrNXZRcXF5WlZzS3FUbkRCcGJwQTNoR2E4ZDhLeUU0Z0taQ0xBNXdqNXBx?= =?utf-8?B?WDBMd3FuNUROeXZTaGpCcFJ5WVBmcDhJdERVbXdTU2lEOWpZdTJ1Mm9pbW16?= =?utf-8?B?bTBvNTF0NnBUTzFEQlVoU0Q5UlhpYnBVSWJEbzBhZlprZkF2UEFIQzFPMDF0?= =?utf-8?B?SmpjSXU5bW5JN0FCVzkwdFZzekdaN1JidVEwQks1VEdsWEQrMTVDODYzMnVO?= =?utf-8?B?WFFVYXNVU09oVmoxZklRZUpGY3hQejFyaUtCTEZ3NUltNXMvQ0c4dnNORUt4?= =?utf-8?B?T0o4TlNONHRsVWlaTE5OVDF2TitNeFhkZWxiZWlrajhTbEZGNTZaZXNVR1pk?= =?utf-8?B?MzJYRHhkVHJqdlE0b054MXh3SzVuWFdVS0hRSWlvK3d0TXlTM0dyeVBXTUxz?= =?utf-8?B?K2hmZEh2ellJRWd3VmJFNnNnWk9uMi9YbXE2aEhvRUJVL2hCaVIzZGxQTDZX?= =?utf-8?B?SW10MSs2RFcxNTllN2FKNi9GT2cwKzhqVUF6Yy9zWFhxWHZPTGMzRnkyMXBi?= =?utf-8?B?ZFM2TkNrdUxrR21kMG5GMFZqZUFQVWorRjAzeXZMMkJLTmVLUkx1V3FsZ1pL?= =?utf-8?B?SDZpZURIamdabXRwVVAxaWUzaEFDbTgzdWZwRTN1Si9tSU1IMHJ2NTc3NDRk?= =?utf-8?B?cEE2Y0V1TEluNE90WkxmS2IrMFAyLzlvVVRmMlgzbUhkVlFhRXlPaEZxcFh2?= =?utf-8?B?SE5qWlg4NmpINTVPaUpUY2xhdzYyRVNWR0RIZWpUT1hoMVM0NGtHbG1QZmlE?= =?utf-8?B?WU1Oc2FjVnRDRSsxYWw5UkRDdE56K21TNURlSUhvSUtpZm52MUtLWDJ5ZHV0?= =?utf-8?B?cUMrTk5EbUI0aUJhY2lrMjJiMjJkL1RZYkFkUkc4d2wvcnJ2bXdoWjNBbXV0?= =?utf-8?B?aHJad2hFTEE4aVZqZVk0YXhsNEFTMGhzejkveHhreExyMGlLOFppNkpjaE5h?= =?utf-8?B?eG9LWHA4RGQyY2dyZGFRb0d1Nzh2TzVDa3IzRWpnVVVURVN1MTR0ekdYMlp2?= =?utf-8?Q?d5Co=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(36860700013)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2026 09:28:46.7351 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 74d6b14c-19e5-43ae-74f2-08de4dcf2899 X-MS-Exchange-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: CH1PEPF0000AD7B.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7160 On 30/12/2025 14:50, Andrew Cooper wrote: > muldiv64() has 7 users across all architectures, and is limited to time > handling functions. Therefore, move it's declaration out of lib.h into a > dedicated header. > > Rename the library function to generic_muldiv64(), as x86 is going to provide > an arch_muldiv64() in a subsequent change. > > Explain what the function does, including the limitations; x86's version will > suffer a divide error rather than truncate the result to 64 bits. > > Annotate it with attr_const, not that this allows the optimiser to improve any > of Xen's current users. Add one selftest to check the internal precision, > putting it in bitops.c for want of any better place to locate it. > > Signed-off-by: Andrew Cooper For Arm: Acked-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Wed Jan 07 09:35:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 09:35:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196610.1514380 (Exim 4.92) (envelope-from ) id 1vdPxF-0002dV-N0; Wed, 07 Jan 2026 09:35:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196610.1514380; Wed, 07 Jan 2026 09: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 1vdPxF-0002dO-KQ; Wed, 07 Jan 2026 09:35:49 +0000 Received: by outflank-mailman (input) for mailman id 1196610; Wed, 07 Jan 2026 09:35:48 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdPxE-0002dI-QC for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 09:35:48 +0000 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170100009.outbound.protection.outlook.com [2a01:111:f403:c107::9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3cb65ea5-ebac-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 10:35:44 +0100 (CET) Received: from BLAPR03CA0178.namprd03.prod.outlook.com (2603:10b6:208:32f::32) by SJ0PR12MB6831.namprd12.prod.outlook.com (2603:10b6:a03:47d::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Wed, 7 Jan 2026 09:35:37 +0000 Received: from BL6PEPF0001AB4C.namprd04.prod.outlook.com (2603:10b6:208:32f:cafe::37) by BLAPR03CA0178.outlook.office365.com (2603:10b6:208:32f::32) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.2 via Frontend Transport; Wed, 7 Jan 2026 09:35:35 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BL6PEPF0001AB4C.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.9499.1 via Frontend Transport; Wed, 7 Jan 2026 09:35:36 +0000 Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 7 Jan 2026 03:35:36 -0600 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 7 Jan 2026 03:35:36 -0600 Received: from [10.252.147.171] (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, 7 Jan 2026 03:35:34 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3cb65ea5-ebac-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fWmKmC+xtl4FlV3ewO0AWiC4ufL2KW75CVLmQvgXsKTWxajTSF6JfAc6YCY34SlqugMY1YwB6r+fjv4FdHwf351dCr2uXL6qNTo4/bZKb6b4PJqDCirgxCQD1xxx4674XvoHTbE+nRG4vGI69jn9HXYRfYJygXjD4iw++E35jiXkaXG+G0MYG6l9innt+1t1MFWAt+K5J9zy4i1Bn1QkfwURibvq5Fj1XoIN8Y6DfIl+GNi+KQIgCVqJRP0r7vbFTddjBn6rD0+86PmNNZ8Ykrbpu3Ty1YnZTzPSNEzhxuZV4rWovmUHGtURs3gbhwpbXjZ8izbnUudDfS+cJhokpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=V6dzk1RcH/YjBJRmi/iv0tZ38UcDJzSMginZO8W/FMY=; b=KxLMcZP8YXBf1O2heeGRhfTuyIv4a+Ro6Jz9xUZn/spDyiSurHdKlymwBzIY7eue7KRX6wAvhGef4mKWhR3GBTAoLVRU+rptlIGIalFU4PAQjytjt4cQQ+m+5H6ccK60634aCyy9Gh0AJBLelogrGN2iSSnaeJFzPLgLPb+6CrdVxlJJhwYAuDpZqdaCEcaDOgwSbIcopJFZnXee28UozShe6TS3MTnrRt8/uYOgWKe9bkyEgk0RibPAFQb8mvFHrDYCkpxIw6f+J60wJ4VSWqjl1cvyxJDU3gTjezafU3wkTPxXEe/LMnB4bNZTjbnt5DPLZU1/+C3rB2qyyTJlcw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V6dzk1RcH/YjBJRmi/iv0tZ38UcDJzSMginZO8W/FMY=; b=s3Jmr4PBjqlkN8vAOv9A9syxzC4V3UX8/8FY1yfnIklWGMIeOh5KbHHBou4rO6KiRF6wHAbXiPZ8/xWIKQ1MD+eK23kHvCt6B7I1kTdXJz4K0JUtemmS6V4ggW/Us1h3MJKxmEtMZwGUklZxhN30E5imXms32efzgeF5cJGxCRs= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <0ffa723d-9391-4539-bd73-f05e1484726a@amd.com> Date: Wed, 7 Jan 2026 10:35:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/6] arm/mpu: Implement copy_from_paddr for MPU systems To: Harry Ramsey , CC: , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Hari Limaye References: <20260105113503.2674777-1-harry.ramsey@arm.com> <20260105113503.2674777-2-harry.ramsey@arm.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20260105113503.2674777-2-harry.ramsey@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB4C:EE_|SJ0PR12MB6831:EE_ X-MS-Office365-Filtering-Correlation-Id: c54fdcbb-3a3d-477c-ec1f-08de4dd01cd2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|82310400026|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?bnVIZlRHREJHM1k2VzlkeTVycHMzOUxMV25JVmpmWm1vdlVvbFo3VDR0Q1Vm?= =?utf-8?B?aENHbm53Y2JnWXdPSUpscDJPaWlYME9UNXFtYzBuV2VzN1NRaW5jdlBUdXhK?= =?utf-8?B?U0NFT3BVamN4VDJVZzRrTU1BZ2JabmlHL1g2c3pmcXJWWmdCM0ZKUzRNcGRP?= =?utf-8?B?UEtUclFuZTMrZ3hBYnpDaTVJV1VvQXVwM0R0ZWR3OHNGUHRabEZFUzZFSk5i?= =?utf-8?B?MEZ4N1cwMGhuRHMxc3FMMG5BemJGL2hQUzR3UU1Ya29QVzVGNHUwRDBKVjlS?= =?utf-8?B?eVhxNTlXOEorTzZyL0JIZGhQaUg0VXZBeVpqVTVuU1JoWHg4SDZGVE8xMUw4?= =?utf-8?B?emtFSHF4WnRWTmF0YVkyMHZJNDVoWHRhR3o1ZER3bXliWTFvNUw3MDk1TnlV?= =?utf-8?B?RHhRTG1rUU1aMmxwSjhQckZsMkZwRWdlc21wTDl3MmJQdVZiUEtPU1RzREtF?= =?utf-8?B?dXNrbWxVQXBWWWx2bTUxdmlQc25uTlp5YzNWRERodmNvQzZQNlgzblcrc3VZ?= =?utf-8?B?Qjg4ejFmSTFvTUVhQmhhTTFsR3Vsakt2UVY5clRrRXJvb2pCWXROSkUwczdN?= =?utf-8?B?UDdQS2lUandEWk0yckt5SzZMWkxZaUQwazF4aHYzY0YxOTcvTzlKSTh0cENz?= =?utf-8?B?cTdhcm1GdDFyUWtzd1puRm5UellXYUprNUFrOEQwS3FySWFiWlJGOU5kS2xS?= =?utf-8?B?eDlLWStGaFdCcExnczYzdG5OZisxYnJsOTl0TWhFeDlrRHNyL08yOW5RRVQw?= =?utf-8?B?ZHhTcVNrdVRkUEc3NGxOV3FwWEFweWtRWGVBSitxbWhwUFVzRzdSYnozcUJ2?= =?utf-8?B?S2pXYkRLRjZoclJPdndDOTlrcWZuVThYWkltUTdza3ZRc3Z5Y3JpY0lSK3c2?= =?utf-8?B?N1BITlJ1UzFzU2NFRStTT3IraGVlVnFSZnFtU1lWZG9mOVM4WmV3cVNrTFd1?= =?utf-8?B?cmYySEh2L0tzTGFHYnpneDhEbzVETkswV0NXdEVlZUVIZ1lqbGhQQXBBNFlj?= =?utf-8?B?dTFQSmI1TTRGbWdmT3Q3RzhDQ2NDOG9GMmlMNlE1UFQ4bXhqSFZBWlVqd1c0?= =?utf-8?B?NVRLeWdkMmlDa3U5dENlS1NQRTJFdTd4em9mTHhhNWF4aEthSFV6dEJTL0dX?= =?utf-8?B?d0F1SmtKbUErMnFLZzdCazVlSldodmVRcnZkbWR5V2lxNnMvRHYyOHY0d2dV?= =?utf-8?B?WXp0UVA4SHd0dmlaSklWcVVjMGpHWmhJeE9yYnl0NDhSSlVzR2pmMHIzOGlu?= =?utf-8?B?U09hOFhnK1B5T1MxK2M2LzU4djRHNXhXeGNHLzhndWZnQkR0L0lGVG1GSFpr?= =?utf-8?B?azRESGhTczdQc2RzUFZyQVFBeG4rZitON05oWmJhWitIRDF1aUVUbVdqVGcr?= =?utf-8?B?WmVEV3J4L2hqL09ORVhHZkRRV0JKOE00SXlHYTd4YVRic2dXbkt6TjFVVjRY?= =?utf-8?B?aFFRTGRDUHFnS0xQL0J0VG5VQjJIcmdzTisxbUMwOUNnWGkvN20xM2Uxc0Nu?= =?utf-8?B?WHk3MHV1UmZhdTlUb0RUamtia3h2anhwSXNJOVgzQzJ3RFJ4OTBOUzYwWld2?= =?utf-8?B?VCtOU08veXBQemdkVDRueW8wZ2tLRk5iQy9vRlUra1RCclJ3cmUycWhuRkdR?= =?utf-8?B?QnhHZ0ozYndwMWtNZHA5VTFxaE5xbUFGVklHRExYMVJidHJNTmkxbmdQdzFB?= =?utf-8?B?WU1udktRQUJYN3U4STRwNTNhSW1SRW9wRzRTb0ozTEJkeWlXNmxqbldHVTU1?= =?utf-8?B?bTJBSmNBOE5xdUdNczJQRmo1b25rS1pnT2VCVVBWaERSaDVaSCtWbDFXeWVy?= =?utf-8?B?RDRUU1FxZjdnQlMzNXBDZ2dndUFucUM4c3dDeitWb0FScDB2QW1SNkN6TE96?= =?utf-8?B?SmxUQWtpYlVBV0ZlMmJZOE1IMm1sQjBGVHU5ODY1QzJaZ00vL3MzNzN5SkNa?= =?utf-8?B?RUg3SVFiSURiamZaYUJlVXBBTm90c1c1VlhRMnhqTUV6ZnJxdFJFR0dieTA2?= =?utf-8?B?TU01WFBZV1U3QmdjS29RWGNUN25DR1hTNXBLL05aNXVFNEo0K296YS8yQjdR?= =?utf-8?B?djRqMzRNZDVJTXBaZTk0YzBwbGxYdEdPekh5d0V4bFgwZlJNTTNGNktRdWhJ?= =?utf-8?Q?fcKA=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2026 09:35:36.4884 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c54fdcbb-3a3d-477c-ec1f-08de4dd01cd2 X-MS-Exchange-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: BL6PEPF0001AB4C.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB6831 On 05/01/2026 12:34, Harry Ramsey wrote: > From: Luca Fancellu > > Implement the function copy_from_paddr variant for MPU systems, using > the map_pages_to_xen/destroy_xen_mappings to temporarily map the memory > range to be copied. > > Signed-off-by: Luca Fancellu > Signed-off-by: Hari Limaye > Signed-off-by: Harry Ramsey > Reviewed-by: default avatarMichal Orzel This tag looks to be broken. ~Michal From xen-devel-bounces@lists.xenproject.org Wed Jan 07 10:01:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 10:01:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196628.1514391 (Exim 4.92) (envelope-from ) id 1vdQLb-0006h9-IQ; Wed, 07 Jan 2026 10:00:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196628.1514391; Wed, 07 Jan 2026 10: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 1vdQLb-0006h2-Fi; Wed, 07 Jan 2026 10:00:59 +0000 Received: by outflank-mailman (input) for mailman id 1196628; Wed, 07 Jan 2026 10: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 1vdQLZ-0006gw-MQ for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 10:00:57 +0000 Received: from mail132-4.atl131.mandrillapp.com (mail132-4.atl131.mandrillapp.com [198.2.132.4]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c1f30afa-ebaf-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 11:00:56 +0100 (CET) Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail132-4.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4dmNpG3Msxzlmq2J for ; Wed, 7 Jan 2026 10:00:54 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 2caa85d02d2945c8ac2d970d7dd3ba9a; Wed, 07 Jan 2026 10:00: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: c1f30afa-ebaf-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1767780054; x=1768050054; bh=gGUPo32Yk5+6k/E+Z73kJcwOaII+molcgAUV7+E63N8=; 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=i7gMqUbIsm/65ImmyICGudkrsbJyz+lRlQJ9QLSSst/mdH+sVgfaZNG6WLqDgAj2V BSJCX9UpLS7nhkm7QpPSNhIRBcefCuAtwp9GIV6udphzmHB5s1xVZjLDduFNqHfys4 Nps08KyFSMWzsNYHSrfGcUN6T5IZLuBALC2G/ryE/IOoTqapJIPYCqoSDU7ws98NWR aspl4amqQ4+rYXExIVndm0RhmfyVtW8dch8qG6K9EJtPyGr2vKnSRfMCTdx5bECH+h vlbKYDutyhlZrK0xAeKj06fMHRy3gq2O6XunSyZ/B+wf+OReMA/8yFhDE4l9Ce5eeT y7oi3hyh+wzDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1767780054; x=1768040554; i=teddy.astie@vates.tech; bh=gGUPo32Yk5+6k/E+Z73kJcwOaII+molcgAUV7+E63N8=; 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=xk9vM3m9yQ2UAvBkiIi/suGEYp4iaiwe/PAa2yQvnblthel6a3TNLlXF99fHDgLHH Oxyk9EwOibo8aDFDdZVdc+6iJbaioAwZHSyj06GXst8+JxaY6w4nIGAz9W2WpeuONR PXCoL5Gko4g0F0vdGwbKRWOPOuqG1HOY44oBERM+xp+RsW8OetaxJRcAhMxmILtdiX G6ESS309vYnM7MtOdyEY9a0EtqfMyS5QT+tgc9di13rxoKxTuWUjH3K+eNygVTEKWS +Qiz0t48peIaQ9XL9fgHtOQHqiNK8h0dPCa+U22vqbJZ5tFGujFOZb10/ygWfdzofu w3cbmjo8qWEGA== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=201/6]=20PCI:=20determine=20whether=20a=20device=20has=20extended=20config=20space?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1767780052556 Message-Id: To: "Jan Beulich" , xen-devel@lists.xenproject.org Cc: "Andrew Cooper" , "Julien Grall" , "Stefano Stabellini" , "Anthony PERARD" , "Michal Orzel" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stewart Hildebrand" References: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@suse.com> <52eb1293-b5d4-4f7a-b53b-285e4dd274a5@suse.com> In-Reply-To: <52eb1293-b5d4-4f7a-b53b-285e4dd274a5@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.2caa85d02d2945c8ac2d970d7dd3ba9a?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260107:md Date: Wed, 07 Jan 2026 10:00:54 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 06/01/2026 =C3=A0 14:50, Jan Beulich a =C3=A9crit=C2=A0: > Legacy PCI devices don't have any extended config space. Reading any part > thereof may return all ones or other arbitrary data, e.g. in some cases > base config space contents repeatedly. > > Logic follows Linux 6.19-rc's pci_cfg_space_size(), albeit leveraging our > determination of device type; in particular some comments are taken > verbatim from there. > > Signed-off-by: Jan Beulich > --- > Note that alloc_pdev()'s switch doesn't handle DEV_TYPE_PCI2PCIe_BRIDGE a= t > all. Such bridges will therefore not have ->ext_cfg set (which is likely > wrong). Shouldn't we handle them like DEV_TYPE_LEGACY_PCI_BRIDGE (or > DEV_TYPE_PCI?) anyway (just like VT-d's set_msi_source_id() does)? > > Linux also has CONFIG_PCI_QUIRKS, allowing to compile out the slightly > risky code (as reads may in principle have side effects). Should we gain > such, too? > > --- a/xen/drivers/passthrough/pci.c > +++ b/xen/drivers/passthrough/pci.c > @@ -310,6 +310,41 @@ static void apply_quirks(struct pci_dev > * from trying to size the BARs or add handlers to trap acc= esses. > */ > pdev->ignore_bars =3D true; > + > + if ( pdev->ext_cfg ) > + { > + unsigned int pos; > + > + /* > + * PCI Express to PCI/PCI-X Bridge Specification, rev 1.0, 4.1.4= says > + * that when forwarding a type1 configuration request the bridge= must > + * check that the extended register address field is zero. The = bridge > + * is not permitted to forward the transactions and must handle = it as > + * an Unsupported Request. Some bridges do not follow this rule= and > + * simply drop the extended register bits, resulting in the stan= dard > + * config space being aliased, every 256 bytes across the entire > + * configuration space. Test for this condition by comparing th= e first > + * dword of each potential alias to the vendor/device ID. > + * Known offenders: > + * ASM1083/1085 PCIe-to-PCI Reversible Bridge (1b21:1080, rev = 01 & 03) > + * AMD/ATI SBx00 PCI to PCI Bridge (1002:4384, rev 40) > + */ > + for ( pos =3D PCI_CFG_SPACE_SIZE; > + pos < PCI_CFG_SPACE_EXP_SIZE; pos +=3D PCI_CFG_SPACE_SIZE = ) > + { > + if ( pci_conf_read16(pdev->sbdf, pos) !=3D vendor || > + pci_conf_read16(pdev->sbdf, pos + 2) !=3D device ) > + break; > + } > + > + if ( pos >=3D PCI_CFG_SPACE_EXP_SIZE ) > + { > + printk(XENLOG_WARNING > + "%pp: extended config space aliases base one\n", > + &pdev->sbdf); > + pdev->ext_cfg =3D false; > + } > + } Given that it only appears to be the case for PCIe to PCI/PCI-X bridges, do we want to check this for all devices ? > } > > static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devf= n) > @@ -351,6 +386,8 @@ static struct pci_dev *alloc_pdev(struct > unsigned long flags; > > case DEV_TYPE_PCIe2PCI_BRIDGE: > + pdev->ext_cfg =3D true; > + fallthrough; > case DEV_TYPE_LEGACY_PCI_BRIDGE: > sec_bus =3D pci_conf_read8(pdev->sbdf, PCI_SECONDARY_BUS); > sub_bus =3D pci_conf_read8(pdev->sbdf, PCI_SUBORDINATE_BUS)= ; > @@ -363,9 +400,19 @@ static struct pci_dev *alloc_pdev(struct > pseg->bus2bridge[sec_bus].devfn =3D devfn; > } > spin_unlock_irqrestore(&pseg->bus2bridge_lock, flags); > + > + fallthrough; > + case DEV_TYPE_PCI: > + pos =3D pci_find_cap_offset(pdev->sbdf, PCI_CAP_ID_PCIX); > + if ( pos && > + (pci_conf_read32(pdev->sbdf, pos + PCI_X_STATUS) & > + (PCI_X_STATUS_266MHZ | PCI_X_STATUS_533MHZ)) ) > + pdev->ext_cfg =3D true; > break; > > case DEV_TYPE_PCIe_ENDPOINT: > + pdev->ext_cfg =3D true; > + > pos =3D pci_find_cap_offset(pdev->sbdf, PCI_CAP_ID_EXP); > BUG_ON(!pos); > cap =3D pci_conf_read16(pdev->sbdf, pos + PCI_EXP_DEVCAP); > @@ -409,9 +456,9 @@ static struct pci_dev *alloc_pdev(struct > } > break; > > - case DEV_TYPE_PCI: > case DEV_TYPE_PCIe_BRIDGE: > case DEV_TYPE_PCI_HOST_BRIDGE: > + pdev->ext_cfg =3D true; > break; > > default: > @@ -420,6 +467,19 @@ static struct pci_dev *alloc_pdev(struct > break; > } > > + if ( pdev->ext_cfg && > + /* > + * Regular PCI devices have 256 bytes, but PCI-X 2 and PCI Expr= ess > + * devices have 4096 bytes. Even if the device is capable, tha= t > + * doesn't mean we can access it. Maybe we don't have a way to > + * generate extended config space accesses, or the device is be= hind a > + * reverse Express bridge. So we try reading the dword at > + * PCI_CFG_SPACE_SIZE which must either be 0 or a valid extende= d > + * capability header. > + */ > + pci_conf_read32(pdev->sbdf, PCI_CFG_SPACE_SIZE) =3D=3D 0xffffff= ffU ) > + pdev->ext_cfg =3D false; > + > apply_quirks(pdev); > check_pdev(pdev); > > @@ -717,6 +777,11 @@ int pci_add_device(u16 seg, u8 bus, u8 d > > list_add(&pdev->vf_list, &pf_pdev->vf_list); > } > + > + if ( !pdev->ext_cfg ) > + printk(XENLOG_WARNING > + "%pp: VF without extended config space?\n", > + &pdev->sbdf); > } > } > > --- a/xen/include/xen/pci.h > +++ b/xen/include/xen/pci.h > @@ -126,6 +126,9 @@ struct pci_dev { > > nodeid_t node; /* NUMA node */ > > + /* Whether the device has extended config space. */ > + bool ext_cfg; > + > /* Device to be quarantined, don't automatically re-assign to dom0 = */ > bool quarantine; > > > -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Wed Jan 07 10:27:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 10:27:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196649.1514402 (Exim 4.92) (envelope-from ) id 1vdQkx-0001Kb-PL; Wed, 07 Jan 2026 10:27:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196649.1514402; Wed, 07 Jan 2026 10:27:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdQkx-0001KU-Kl; Wed, 07 Jan 2026 10:27:11 +0000 Received: by outflank-mailman (input) for mailman id 1196649; Wed, 07 Jan 2026 10:27:10 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdQkw-0001KN-N2 for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 10:27:10 +0000 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [2a00:1450:4864:20::342]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 645bb741-ebb3-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 11:26:56 +0100 (CET) Received: by mail-wm1-x342.google.com with SMTP id 5b1f17b1804b1-47d493a9b96so11395585e9.1 for ; Wed, 07 Jan 2026 02:26:56 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f7053f5sm88092155e9.14.2026.01.07.02.26.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jan 2026 02:26:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 645bb741-ebb3-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767781616; x=1768386416; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=L09Jd0LwTx6EHCnvoboZZyb95Qnhmt0wJviUl5mKr6Q=; b=VV9ADrUeFsvGbVMn3TiVf3UZrsDIjml0r2noMECOF3vPS9QgLka+NYPLG0temBq3qD 8W3td+Nan52FqFZ51SEkw1dyrlxLQFeyRW72jpZIl3Si2j23znPuDodZUXhdTJ4s4Y4k IywPQRJONFfJctFaQInbqnNV8p64m9IRwmUckcT6fvM+3hMvflOH/QPHNrKUAeFMk8SI BflQqZP0cTx3CPnRdch/Y4WlOTeuMdz9aFcgulLEodPWgNf3xy4uYX+3lMcaUSnghe1j EfE5gbIYJHTqPTnKdN2ac3KF294RV6hG44Sjdw6xvWP1SoQBee/RaA9eUWaLqLaGi8qs n2ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767781616; x=1768386416; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=L09Jd0LwTx6EHCnvoboZZyb95Qnhmt0wJviUl5mKr6Q=; b=vKC4mA1ADEWdwKLjW6oTe1LWL2qTdhgcIgv+bS2Ln5vcDdbXT0zHJh900uceluD/KX 2zZKUsng4YPCavTMJT7NAFNXVMq7Q78BVb0np7fX8f1WmYGNKqBQahYOM9XuEobfL9WJ TM9hdgEEOtc+2wNpxDLknUnalxunR8hEpP8wlGJjiGHKTFq2ImLxmDHqtq8oaxve9nfj A8W58Zks/zxmlwEsE0Q5tlf5XKUn3ZZR+zjg19HF/80Gb+gzoqnS30+SLrCVfkpI7YkO nEUuvAE/+JWY1I0LHQPlNNJjkSj7SxObiIck6pWkeBx2i+BqaaPIUtWUhvqIRg6Lu2sr 1XEQ== X-Forwarded-Encrypted: i=1; AJvYcCWK88PDiuZXRk8bUxzkrhg4upNgxOgUPZTGDCsAqDuAE/H3biUIGOGXIGXYbDJ9PG9IbVTGlXon2fo=@lists.xenproject.org X-Gm-Message-State: AOJu0YzgDaJtqq/caUbtKuP9ghHy8xigySnsePscUflwLA1N6iWLzmeH BrnomEFr6P2RZCVyX7gV111vng3Cyt9zvfzTsEv6QFiZZpbmjuVUn4axIG519n0Byg== X-Gm-Gg: AY/fxX4WoyKg9liWduR2CXsGCKydka0LrrgC5VGH3G0S1BELeNj8/RqZNGVbbmfGfAh vns8WQBgr1kjid5gP9bamH4Hq/XIHm0R57ywRiiUUPWcd9aHn10pB/WQSBGpwcSH147e/fjF5Ig H05IsW2zc/cqgNHEOYCIuxbVoWiB+6JEZsNEIvhAhFzMmW42rcK2SW/EwWg/tsK5GU1Bdilp3J7 plGhokQQ+Glnr0yEyXsdlWCJhp8LEaYBX4pV63WbgizKDp3qR/4IXvh+DWdvkjLqAtrCgx3eRIB WWARnSRKGR0t7/IVjNdzKsIek3SC3+/cHaz92PBy1xs7+m58u/JwNJRF0syZoGYtEH6pxUgLl7O pr1kxMGnXUkm2xSQwRE97NSmHUyk0yvB2gpe7+a1k3RmvdjqBJ6mP96Pnw75+LI+FnlDptGsT+D SZRaDzbODl0efWsNvqVqtrF+S8T06T5/wOn4MJ+z0awvxvijOJm5RNWqO8lca5DQ/Ybb9uGsMJc UI= X-Google-Smtp-Source: AGHT+IG5hbHrToE7bNaafsMGZFHscGiCphH4GDRKpw+jgjFWN1z45AbD4CgBpOHwwbXSxQWmP5O4Gw== X-Received: by 2002:a05:600c:19cc:b0:47a:7fd0:9f01 with SMTP id 5b1f17b1804b1-47d84b21227mr24405365e9.16.1767781615916; Wed, 07 Jan 2026 02:26:55 -0800 (PST) Message-ID: <4f19bfd8-2177-4e1b-b5ae-cf945d213e89@suse.com> Date: Wed, 7 Jan 2026 11:26:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/6] PCI: determine whether a device has extended config space To: Teddy Astie Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand , xen-devel@lists.xenproject.org References: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@suse.com> <52eb1293-b5d4-4f7a-b53b-285e4dd274a5@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 07.01.2026 11:00, Teddy Astie wrote: > Le 06/01/2026 à 14:50, Jan Beulich a écrit : >> --- a/xen/drivers/passthrough/pci.c >> +++ b/xen/drivers/passthrough/pci.c >> @@ -310,6 +310,41 @@ static void apply_quirks(struct pci_dev >> * from trying to size the BARs or add handlers to trap accesses. >> */ >> pdev->ignore_bars = true; >> + >> + if ( pdev->ext_cfg ) >> + { >> + unsigned int pos; >> + >> + /* >> + * PCI Express to PCI/PCI-X Bridge Specification, rev 1.0, 4.1.4 says >> + * that when forwarding a type1 configuration request the bridge must >> + * check that the extended register address field is zero. The bridge >> + * is not permitted to forward the transactions and must handle it as >> + * an Unsupported Request. Some bridges do not follow this rule and >> + * simply drop the extended register bits, resulting in the standard >> + * config space being aliased, every 256 bytes across the entire >> + * configuration space. Test for this condition by comparing the first >> + * dword of each potential alias to the vendor/device ID. >> + * Known offenders: >> + * ASM1083/1085 PCIe-to-PCI Reversible Bridge (1b21:1080, rev 01 & 03) >> + * AMD/ATI SBx00 PCI to PCI Bridge (1002:4384, rev 40) >> + */ >> + for ( pos = PCI_CFG_SPACE_SIZE; >> + pos < PCI_CFG_SPACE_EXP_SIZE; pos += PCI_CFG_SPACE_SIZE ) >> + { >> + if ( pci_conf_read16(pdev->sbdf, pos) != vendor || >> + pci_conf_read16(pdev->sbdf, pos + 2) != device ) >> + break; >> + } >> + >> + if ( pos >= PCI_CFG_SPACE_EXP_SIZE ) >> + { >> + printk(XENLOG_WARNING >> + "%pp: extended config space aliases base one\n", >> + &pdev->sbdf); >> + pdev->ext_cfg = false; >> + } >> + } > > Given that it only appears to be the case for PCIe to PCI/PCI-X bridges, > do we want to check this for all devices ? Yes. Bridges are only the main examples, but in the few systems I tested this on so far I have at least one ordinary device which also aliases base config space. Also note that Linux, where the base logic is taken from, also doesn't restrict this checking (if I'm reading the code right). Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 07 10:42:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 10:42:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196659.1514411 (Exim 4.92) (envelope-from ) id 1vdQzm-00040i-Vf; Wed, 07 Jan 2026 10:42:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196659.1514411; Wed, 07 Jan 2026 10:42:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdQzm-00040b-Rz; Wed, 07 Jan 2026 10:42:30 +0000 Received: by outflank-mailman (input) for mailman id 1196659; Wed, 07 Jan 2026 10:42: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 1vdQzm-00040V-16 for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 10:42:30 +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 8df7623e-ebb5-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 11:42:26 +0100 (CET) Received: from IA1PR03MB8288.namprd03.prod.outlook.com (2603:10b6:208:59e::6) by BL1PR03MB6022.namprd03.prod.outlook.com (2603:10b6:208:312::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Wed, 7 Jan 2026 10:42:22 +0000 Received: from IA1PR03MB8288.namprd03.prod.outlook.com ([fe80::4af0:a6d4:e568:ac0e]) by IA1PR03MB8288.namprd03.prod.outlook.com ([fe80::4af0:a6d4:e568:ac0e%6]) with mapi id 15.20.9499.002; Wed, 7 Jan 2026 10:42: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: 8df7623e-ebb5-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=BeOXdQFJTa2TDDxynChQrKNt9VU6AT85FJE7zZj00a7Nul49c3YonR4EVVTScVbaP9G1UdDki388aXgfFdo03VUumeyG0GQTHHkOuC0aPheMojod99r5MwZznkJI/OH/L9B9dXocLbXLF4hDEko/CyKG+6uFh2W5eA3KxR9yqxVYj3VGh0kdyPWhLGh0vnv6EeOGwHxhF7tXJRovUYbbFrlDKf9QsxPIrAT4M0Yj8tEI1loBBwUOLsn/z8+SrSdyLh4VOh02Y0ak/9yQCFyKcVN9XZm308CwBn7GoEIROcvA8SXDHb7Leiiolfhu6K9Oj+5zchT1bUJSERDZbXwNUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WF455ridIJIOwrXs7Eu8RJ5A454cGJPrSBMOt+Y9C4o=; b=scYj990GkY/OQnb99Nv8bTW/RAWUwfHDO8TaPcfbjy2PdVJZVSFc3sY823maM1E0T/Z6AnezM78tWSFRIy9s/Em0NxIkNwJe3yrSDoeYrFrtQrk7HzYOz20ANcwrLwrBJqgXztZPYkE6Mjsi1IBoFMLVVX/5kdtX8bRqUEEppt48jQjG7v6gZatcGiIWtEpQg+9nMhnnkvvHtI6I/WXvltuwo+7/toE99dENQkGDOqteovnr/pS4sS3iBCotLvswV3ZXg3s6WkQS78V4OC0QDZt6ieEjoV0aNmoL5JNdDZ7vA+qLGV4rTO6/oQC7ZRAU0vR+GubxpIEcbzSOPVgHgg== 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=WF455ridIJIOwrXs7Eu8RJ5A454cGJPrSBMOt+Y9C4o=; b=b6uBd1WOwVdfVlKn963aBOYarAlC+urzrZL5J5QWy+qhotylqFPWD5y3UHx3VhQ0/A70LtnqG/sB1rN6KIddVXPVsz0VDKEk0Mpaiaw1iSbdXYGFmwhpi/z0EoUGEQA7G0OyzQd/1E5+KoAVkHlQNU3qFfB/KB6wC7Fa7YfiHyw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Wed, 7 Jan 2026 10:42:18 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Andrew Cooper , Roger Pau Monne , Oleksii Kurochko , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH for-4.21 v2] x86/AMD: avoid REP MOVSB for Zen3/4 To: Jan Beulich References: <8ecbf8b7-91fe-4f9e-9542-7ec22b6a47bb@suse.com> <693449f18cc4480ea2cb2161a9361354@DM4PR03MB7015.namprd03.prod.outlook.com> <98855b1c-2cda-467e-8b88-ff24e7862b61@citrix.com> <0ebbc19a-724c-4e2f-89ce-58325342c4b5@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <0ebbc19a-724c-4e2f-89ce-58325342c4b5@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0605.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:314::7) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: IA1PR03MB8288:EE_|BL1PR03MB6022:EE_ X-MS-Office365-Filtering-Correlation-Id: 72fac3c8-6a6a-4cc9-e42c-08de4dd9702d 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?VXdmQmtndlNwRkJHODJaQnZaeTFDbU05bm42aTFDY2d1VUwzZXYxNHI0b1Bt?= =?utf-8?B?UGxBODAxR2RqSU83NUloMGZ5SDAvQXB4d1BLQWp4bWpSbWpkcGZZMmxWWTJE?= =?utf-8?B?eW9mRGdYNWY3bDB5blo3a1NJWVN1M3RPaDJRRXE4aFdjQVQrNGhFbHkvTktj?= =?utf-8?B?NnBUTlg1Tm5ubjE1a1kraXB6YXVmOVVVcnFZbXVnRTc0elhPZzh5TXArNUdN?= =?utf-8?B?OGsxZzVFQ1U5MWIyZUVEZ2xQVDZ2aXRySDlTUGxKcGwxMFJZWVNOSzkzVDJE?= =?utf-8?B?TSt0cXd4d3VNYWNhVVV3U0c2ZnNjWGNLMlJBQzJnS0d0TG14WDU1V0dpaWJi?= =?utf-8?B?M2VBMjVHNG5Eb3EwMHo3b1ZhclNIMnJid3JXc3VpS3p3MXA0aEZ0b1RtS0xD?= =?utf-8?B?YU8vTmpHMVlDa3ByU2xPb042VzFpOXF6S3dLTCtzVUUyOWJYQi9YUFNnckxy?= =?utf-8?B?NVRiQlkxdzdDSnFrWTJ1SGpIVUMvNFpMZlpHdm8vWjlzVVJUZUM0ZndzRndt?= =?utf-8?B?b3pEMlN1QTQ5M1NvWkNndmdTMHhCTWk1QlM0eGlQMkVCMGpSbGx3NmJmU1pR?= =?utf-8?B?WGZTcWRvUmVtcWRMYXAwRjdHT0dMTWQrQUd1VkwxTm5YekdnOGNJaW9Cd3Js?= =?utf-8?B?Z1dVNWp0MXJlNkhOTWpoWmhjQlhuQXZzUWVnSm5PZ3dDaE1FOUJ4L2xGV0tK?= =?utf-8?B?STNoODFPNnZQV2M2TXhKWjJaYUNuVlpyQWc1SnQwMGovMXFaTjNvVzlpM3FH?= =?utf-8?B?b0VIcjdMQVpuN2Rndlo0a0dBcW9DZUFHUm1yNzdqRk8vQ3FSTE53Yi80NFBU?= =?utf-8?B?bEJkQnpheHJIMGh5RW1Nd2Z5dmFvN1REQktvdWxpSWxsS2MxZmZkRUNZRW9y?= =?utf-8?B?UWxLOG1VNm14YlM1R2N2WUNMWTAwYnpkMk8yTFRGSlU2U1BqNlNzOUEva0tW?= =?utf-8?B?d2pxNjc1MXdPenpqa2l1c3hHd0ZtZUd4YVluTTNQckNTdjZUTmlTTlZaYjhK?= =?utf-8?B?OGhPUEgzVDIzdWMycUNkNEpuUFlPbUVhWTM4S3Y0UHNFZGZ0OG9TeU5KRldK?= =?utf-8?B?eDhMUUhFNlpJZys4Rkh4TE1mL2lJdVJseGFqaU1JMXVnVEFLOEt2MkxtT0x4?= =?utf-8?B?UUVQTEdDQWlHNU5BV2MzVUM3ek84SmhZT3IvRmRlbmYzUlZ1QlIzVGc0MzUz?= =?utf-8?B?RXJBVVRzTG1pVDBScTNqaDJHd1A2UG1qYnVDVFZOM3dzQ0d3aVYvcFkwY3dq?= =?utf-8?B?TUg4a054amcvV0UySS9YU3gxb3kwMWkzQVR0QlBnL0JXdGw5VEVoVnpDMTht?= =?utf-8?B?VXhyL3NtWWIvcEN5N3hiUDNFQXFHdTNVaTRycUhTRFp0c1ZwRDVwejZKakhp?= =?utf-8?B?WlpNVkFNL2Q2QUp4cUlvWUgwbjFGL1YrV3VQY0lkNXhrNjRxdFlOQkZCbm1h?= =?utf-8?B?NGF5aDZBaXYrV0xqN3QxZ3JjRVFrMFJsZGRtc1Y2Q2dVSW0rMmlRYnRwUmND?= =?utf-8?B?a1pLbUF5Y2VOM1owcGRVUjNNMHN1d3ROZHl3Nlp2WjY5OWtkTjBEa1diU2Nt?= =?utf-8?B?Kzk1K3k5M2hLQmptV3Q5ejRVOXhHcjMxclE3aWZvQmxicEpEL3Fod3R1YkNy?= =?utf-8?B?L2xYRTl2SDhHOGlJSDc5bHZRTmhsczZlS1VoUlZTM0NLSmJWKzYzeHI2RTNl?= =?utf-8?B?ekJmUlpIWUQ2c1ZkbnhsV0hDZU9jR0RhaDRoZWVCc1BLMU44R25oVWV2Rkx0?= =?utf-8?B?bTJ4Mk1IZGJrUXg3SWJkUElscVB6WUFWbjM1eXllOVdDT0RxTVRMQkVkbkpx?= =?utf-8?B?VGZ5ZklWMFFOVDNCRCs2YktqbHp2WTc2MFphUzY2VlhlWmNMQ3RuVENXVEg5?= =?utf-8?B?eE5OS1JHaTRTSm5SS1hzMFcwcFIxdUsrUG1oTUFSOThjNSszL2N4WkZTTklE?= =?utf-8?Q?yYEf+w0fA9PnCbVGu56pmBPy4TrxVQh6?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA1PR03MB8288.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VGVrMzdFK00rRm1Zb3dJU0c3WG9ScGw4MXY5OGJrZmNod0c5WGQ4NHZ0cyty?= =?utf-8?B?bWxjblg4eU5uRTJObzRWemhhRDRyTlFORmlZMnAwSEFyYm9OekdlNkJ3MWdw?= =?utf-8?B?RFdneitBT0FYVUtoNkZjdGI2dWF2VjVMNVFFeFUybjZyUmM5b2dFMnVGZ3Yx?= =?utf-8?B?bE9jY2hFMDVWd0VwMjF3SjhCNzdZamJDZEZpSXJoVjhmcEFmUnNGYVFIckNo?= =?utf-8?B?OVAvL3dzZGVVNVJMQjBPK1BVcklNSnFzKzBVOEkzNXljUGdMajY5YnY4M1RZ?= =?utf-8?B?VVlWMkprRHFuTEJNQ3N2WTBSRmsxNUZlMU4vQlExTFU1NXBMY3N5NnNKZCtF?= =?utf-8?B?b3REUkJuazEvWVB0aDJIOVhUbW9OMzR4VGEvbzZoKzRBVGFBNFdlRDdtcVhj?= =?utf-8?B?NVZmTmY5emFmMGdWK05LdXJvTENYS3NJZWZscXowYVNNcFY0TVJVeWZzMURr?= =?utf-8?B?RS9ScFJrRUJKUGt5LzY3Y2JoR0tEb1R0M3h4bytiWVhiYXhoaFkyeHpFRjAr?= =?utf-8?B?aVdUakZTTHhWamN1SHl5VW4xcTkwclZhcHhTUS9PVkoyL1lKVXREVjAwd2E1?= =?utf-8?B?a3M1SVE5QzloWnhIZFRIYTRBUDVNUjl3dkJtS0Q3L2V3cEg3b3RUZXlqYTFk?= =?utf-8?B?VDFmQkttNmc0SXA2amJPSmxySjJrUlhHcUczMy9EbjB1cThPUEFjVkNRdXlr?= =?utf-8?B?RG91c0ZEZWQwU0lwNVM3YUtpdGxXb3FoVUNqV3M2ZVFNbjlyN0lRcGliYUtN?= =?utf-8?B?bHgrODFyVnkrR3dZZDdJUkQyd0FncDJIZitrdk1jMTYyVzAxVDBWY0hrSmda?= =?utf-8?B?bjRiWUtyL25iSXVpeWtNbUk0VTZYZzRiNm1BRTcyTkkvNjdLaGt1UnUzcW1t?= =?utf-8?B?SWVrQnIzcDBMUlZub1I1U0NqekhnRUsyS0dTNm03b0ZRcWRkNThJR2lsWDlv?= =?utf-8?B?TVBDbFNqbGhSNGNlWHZpMWo0SUFndWZoaXhUWVhiYXdCWTV1VVpPOUM0NFE0?= =?utf-8?B?cmxQSkI1bS9DWkM5OEhmQUNGU0xGQW5KUGtRc1RhRldWa1AzSnZHUTJLbVNK?= =?utf-8?B?NWlRZ1MyN09kS1dHRThtMGdraUxUK2RuQlpYdmlOcGRQRHBzandIVkYrYjdn?= =?utf-8?B?cjJGbGtBdlMzc093WkU0M0hBYUVzYzd4eVgrSGNZYnUxeGJoQXlqVkpya2ky?= =?utf-8?B?UUF1ZlBuMjJpbnN1NWZEdkRHZm11dlgwdytyYTkydDVkUkYxamQyamJRbVZD?= =?utf-8?B?UHNhRGRaejFjbGVXZzFRSWI5Z1ZxNHVoWWNBaS81OEZqeXZSRGF3N3A5R3Zx?= =?utf-8?B?VjNJWDBCNnpsWEpGWllDN1BiSWc4bmZWSnVGeHRPc1FvTEJoY1ZIYVFmQ1ZS?= =?utf-8?B?WDMxK1Jyc2NlSXIvRmx2cG90Wm9CMDlYbGJLQ0dockkxRXRWK21HdGI2YnJs?= =?utf-8?B?a2dEM2hOTzJoVGljQ3BTZEpuUmhRVUV3aXRlcjNFUktiaUF4czRSRm9ib1Nz?= =?utf-8?B?cjJndW5NNFM0YlBEcndrQ1lSSlFDd0loME5oWjhybDNYc3ZETFRpT0ZQaTU1?= =?utf-8?B?elE0QWVvZURUdThMMDRsL1piZDFHSjVKbTBQK2s2MXQyMDYrbjR6Zlc1dHRx?= =?utf-8?B?V1Z1YmpwdmUzZFlTYVdHajZVRERhVjl1TzAxZExmNjVhRTFKclZqTEs4c0xl?= =?utf-8?B?R2JQcWpTaW1tTG04TXJSaUQxTVp5UDJBd1FSQkdTeENEOWplNlVTaXlQZzd2?= =?utf-8?B?N3hlYXlkdjlXTW1VRWdWK0pVbXQ0N1FjTlYveEo5NE5kd0w4VFc2ZFFwcjRE?= =?utf-8?B?eUNtaGZqRkRrOWpzQXpadkFsT1ZYVzZGOTZQS1JVbWxFU0VrcythNzRTbkFs?= =?utf-8?B?b09BS1U2TnZpL2R1bVRnNnNpQjZCcHdoZGhnQktEQmRHdXlHQ2taeTVWcXFq?= =?utf-8?B?TUJoWWdEanJ4U1BsaGNVNm5hVnNSMU0zQ0FSb1YrY3Z2UzdtbXI1VERVYjds?= =?utf-8?B?amF2dHdrU2FUSGw1bktnQ1hTQnVhUzhIaEZPKzEyRE1xdEFQcUZ5bzZhVWFh?= =?utf-8?B?emF2NUpaekJ1VWt4L0V5aGdpRGFqQzBwRVpoczdDQ2VUR2p4Q0tEK1c0dWRF?= =?utf-8?B?YjI4ZXZKOFZYcHpGK3VCM2dBTG1UYVBrT1h1NXM2QURQMUw0YkFmSTlMVlI2?= =?utf-8?B?czZzZmNPYnhxbWdveXhNT3BxNCt2VnRXM1pLUVdPNU1NUlNramdUa0RaUkli?= =?utf-8?B?V0tEK3N5SVFQQ2pvRU5WZ2FJQTdkMWg2ZDI3bUxrNCtIWGVqZHF6c2RwSDFM?= =?utf-8?B?VU85SCtSWEVBdkhIc0ovcWFXV2FVYzNJZEl1Sks3VkVuVUNtQUt6U2pZNDFO?= =?utf-8?Q?buHsr2ccEU0G5CzE=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 72fac3c8-6a6a-4cc9-e42c-08de4dd9702d X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2026 10:42:22.6164 (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: V2Et2E7m7dofOX5OEhrXaCMSwb5Et45vCzQxmEuAlQQhWwrfNBrkXsow9e6AMu33Cw8g/K2kPlnExI+n3FEboZxzwFaIl4rUh7KBYuh8rA8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR03MB6022 On 07/01/2026 7:22 am, Jan Beulich wrote: > On 06.01.2026 22:07, Andrew Cooper wrote: >> On 13/10/2025 2:06 pm, Jan Beulich wrote: >>> 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 of memcpy(); copy_page_hot() is fine, as >>> its two pointers are always going to be having the same low 5 bits. >> I think this could be a bit clearer.  How about this: >> >> ---8<--- >> Zen2 (which doesn't expose ERMS) through Zen4 have sub-optimal aliasing >> detection for REP MOVS, and fall back to a unit-at-a-time loop when the >> two pointers have differing bottom 5 bits.  While both forms are >> affected, this makes REP MOVSB 8 times slower than REP MOVSQ. >> >> memcpy() has a high likelihood of encountering this slowpath, so avoid >> using REP MOVSB.  This undoes the ERMS optimisation added in commit >> d6397bd0e11c which turns out to be an anti-optimisation on these >> microarchitectures. >> >> However, retain the use of ERMS-based REP MOVSB in other cases such as >> copy_page_hot() where there parameter alignment is known to avoid the >> slowpath. >> ---8<--- >> >> ? > Fine with me; changed. Do I take this as an okay-to-commit? Yeah - with something to this effect, Reviewed-by: Andrew Cooper Sorry it took so long. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jan 07 13:17:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 13:17:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196699.1514440 (Exim 4.92) (envelope-from ) id 1vdTPN-0004Rl-Ob; Wed, 07 Jan 2026 13:17:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196699.1514440; Wed, 07 Jan 2026 13:17:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdTPN-0004Re-LT; Wed, 07 Jan 2026 13:17:05 +0000 Received: by outflank-mailman (input) for mailman id 1196699; Wed, 07 Jan 2026 13:17: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 1vdTPM-0004RF-4k for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 13:17:04 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id 24b97ddf-ebcb-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 14:16:58 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6C02F497; Wed, 7 Jan 2026 05:16:50 -0800 (PST) Received: from [10.57.48.49] (unknown [10.57.48.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9A0A33F5A1; Wed, 7 Jan 2026 05:16:54 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 24b97ddf-ebcb-11f0-9ccf-f158ae23cfc8 Message-ID: <551bb2e3-d7c7-4949-a9bd-ce0cf70e7134@arm.com> Date: Wed, 7 Jan 2026 13:16:52 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/8] dma-mapping: Support batch mode for dma_direct_sync_sg_for_* To: Barry Song <21cnbao@gmail.com> Cc: Leon Romanovsky , catalin.marinas@arm.com, m.szyprowski@samsung.com, will@kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Ada Couprie Diaz , Ard Biesheuvel , Marc Zyngier , Anshuman Khandual , Ryan Roberts , Suren Baghdasaryan , Tangquan Zheng References: <20251226225254.46197-1-21cnbao@gmail.com> <20251226225254.46197-6-21cnbao@gmail.com> <20251227200933.GO11869@unreal> <20251228145041.GS11869@unreal> From: Robin Murphy Content-Language: en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2026-01-06 7:47 pm, Barry Song wrote: > On Wed, Jan 7, 2026 at 8:12 AM Robin Murphy wrote: >> >> On 2026-01-06 6:41 pm, Barry Song wrote: >>> On Mon, Dec 29, 2025 at 3:50 AM Leon Romanovsky wrote: >>>> >>>> On Sun, Dec 28, 2025 at 09:52:05AM +1300, Barry Song wrote: >>>>> On Sun, Dec 28, 2025 at 9:09 AM Leon Romanovsky wrote: >>>>>> >>>>>> On Sat, Dec 27, 2025 at 11:52:45AM +1300, Barry Song wrote: >>>>>>> From: Barry Song >>>>>>> >>>>>>> Instead of performing a flush per SG entry, issue all cache >>>>>>> operations first and then flush once. This ultimately benefits >>>>>>> __dma_sync_sg_for_cpu() and __dma_sync_sg_for_device(). >>>>>>> >>>>>>> Cc: Leon Romanovsky >>>>>>> Cc: Catalin Marinas >>>>>>> Cc: Will Deacon >>>>>>> Cc: Marek Szyprowski >>>>>>> Cc: Robin Murphy >>>>>>> Cc: Ada Couprie Diaz >>>>>>> Cc: Ard Biesheuvel >>>>>>> Cc: Marc Zyngier >>>>>>> Cc: Anshuman Khandual >>>>>>> Cc: Ryan Roberts >>>>>>> Cc: Suren Baghdasaryan >>>>>>> Cc: Tangquan Zheng >>>>>>> Signed-off-by: Barry Song >>>>>>> --- >>>>>>> kernel/dma/direct.c | 14 +++++++------- >>>>>>> 1 file changed, 7 insertions(+), 7 deletions(-) >>>>>> >>>>>> <...> >>>>>> >>>>>>> - if (!dev_is_dma_coherent(dev)) { >>>>>>> + if (!dev_is_dma_coherent(dev)) >>>>>>> arch_sync_dma_for_device(paddr, sg->length, >>>>>>> dir); >>>>>>> - arch_sync_dma_flush(); >>>>>>> - } >>>>>>> } >>>>>>> + if (!dev_is_dma_coherent(dev)) >>>>>>> + arch_sync_dma_flush(); >>>>>> >>>>>> This patch should be squashed into the previous one. You introduced >>>>>> arch_sync_dma_flush() there, and now you are placing it elsewhere. >>>>> >>>>> Hi Leon, >>>>> >>>>> The previous patch replaces all arch_sync_dma_for_* calls with >>>>> arch_sync_dma_for_* plus arch_sync_dma_flush(), without any >>>>> functional change. The subsequent patches then implement the >>>>> actual batching. I feel this is a better approach for reviewing >>>>> each change independently. Otherwise, the previous patch would >>>>> be too large. >>>> >>>> Don't worry about it. Your patches are small enough. >>> >>> My hardware does not require a bounce buffer, but I am concerned that >>> this patch may be incorrect for systems that do require one. >>> >>> Now it is: >>> >>> void dma_direct_sync_sg_for_cpu(struct device *dev, >>> struct scatterlist *sgl, int nents, enum dma_data_direction dir) >>> { >>> struct scatterlist *sg; >>> int i; >>> >>> for_each_sg(sgl, sg, nents, i) { >>> phys_addr_t paddr = dma_to_phys(dev, sg_dma_address(sg)); >>> >>> if (!dev_is_dma_coherent(dev)) >>> arch_sync_dma_for_cpu(paddr, sg->length, dir); >>> >>> swiotlb_sync_single_for_cpu(dev, paddr, sg->length, dir); >>> >>> if (dir == DMA_FROM_DEVICE) >>> arch_dma_mark_clean(paddr, sg->length); >>> } >>> >>> if (!dev_is_dma_coherent(dev)) { >>> arch_sync_dma_flush(); >>> arch_sync_dma_for_cpu_all(); >>> } >>> } >>> >>> Should we call swiotlb_sync_single_for_cpu() and >>> arch_dma_mark_clean() after the flush to ensure the CPU sees the >>> latest data and that the memcpy is correct? I mean: >> >> Yes, this and the equivalents in the later patches are broken for all >> the sync_for_cpu and unmap paths which may end up bouncing (beware some >> of them get a bit fiddly) - any cache maintenance *must* be completed >> before calling SWIOTLB. As for mark_clean, IIRC that was an IA-64 thing, >> and appears to be entirely dead now. > > Thanks, Robin. Personally, I would prefer an approach like the one below— > that is, not optimizing the bounce buffer cases, as they are already slow > due to hardware limitations with memcpy, and optimizing them would make > the code quite messy. > > diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c > index 550a1a13148d..a4840f7e8722 100644 > --- a/kernel/dma/direct.c > +++ b/kernel/dma/direct.c > @@ -423,8 +423,11 @@ void dma_direct_sync_sg_for_cpu(struct device *dev, > for_each_sg(sgl, sg, nents, i) { > phys_addr_t paddr = dma_to_phys(dev, sg_dma_address(sg)); > > - if (!dev_is_dma_coherent(dev)) > + if (!dev_is_dma_coherent(dev)) { > arch_sync_dma_for_cpu(paddr, sg->length, dir); > + if (unlikely(dev->dma_io_tlb_mem)) > + arch_sync_dma_flush(); > + } > > swiotlb_sync_single_for_cpu(dev, paddr, sg->length, dir); > > I’d like to check with you, Leon, and Marek on your views about this. That doesn't work, since dma_io_tlb_mem is always initialised if a SWIOTLB buffer exists at all. Similarly I think the existing dma_need_sync tracking is also too coarse, as that's also always going to be true for a non-coherent device. Really this flush wants to be after the swiotlb_find_pool() check in the swiotlb_tbl_unmap_single()/__swiotlb_sync_single_for_cpu() paths, as that's the only point we know for sure it's definitely needed for the given address. It would then be rather fiddly to avoid potentially-redundant flushes for the non-sg cases (and the final segment of an sg), but as you already mentioned, if it's limited to cases when we *are* already paying the cost of bouncing anyway, perhaps one extra DSB isn't *too* bad if it means zero impact to the non-bouncing paths. Thanks, Robin. From xen-devel-bounces@lists.xenproject.org Wed Jan 07 14:11:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 14:11:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196722.1514459 (Exim 4.92) (envelope-from ) id 1vdUGE-0003Dl-KZ; Wed, 07 Jan 2026 14:11:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196722.1514459; Wed, 07 Jan 2026 14: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 1vdUGE-0003De-Hu; Wed, 07 Jan 2026 14:11:42 +0000 Received: by outflank-mailman (input) for mailman id 1196722; Wed, 07 Jan 2026 14: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 1vdUGD-0003DW-K0 for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 14:11:41 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c8ff43fb-ebd2-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 15:11:39 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-4775e891b5eso10048255e9.2 for ; Wed, 07 Jan 2026 06:11:39 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d87167832sm13687545e9.7.2026.01.07.06.11.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jan 2026 06:11:38 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c8ff43fb-ebd2-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767795099; x=1768399899; 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=ypGd9Yz2mBlv45UcH36jOo23VuYex6K+KrlBsHB222c=; b=F51dyi726ifoqslEwwB3bVlduwKk+kh8pNZGOM3Jz9kbKXPU0XFGaJLkKVhuOvvF43 EvGrOI1eJ/zwZ7cmlPqeRTnYa8L2z9E/h41wIIi6V3PgoxxC2wU+Z9n7AFPVDd4WG2+D gVgJYRSbTr6H6j44JefgwEs1UJfMNrMCxoGQj847t0NzU4OFKBB1k2rLs/cwggF0p7zo eTvWe3l5V5Mb5a0pFV7vfZ0/zkh0GNJCd0rYoVgjOULCB3vG6H2srPqi/M0j3huBls95 zVSZjTSCPEO7tZBm3PIDoAyW2wh7Jcz8unvlHq9dISL+u0o0ryEUAW6g/8VNuHxLBu3B xb+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767795099; x=1768399899; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ypGd9Yz2mBlv45UcH36jOo23VuYex6K+KrlBsHB222c=; b=XZ0KSxGFdAdqwHlGKLOl4HvXkxDR2xxSw5/pO0vqwjbGc0bNYgxkdYaBKWEMI3G39a 9IfuIvl/pGk0rCN+H1CV7qsXwnpEKIaHNp3wc7k/PDzcTDns4oNqzuatnJbf3iazRz6a 66rxRT9X6WO4n5wwTrh6yygeYqAgZ0RBL9y9UQbc9n2UhsgsZd0iIwz7yGKlwpTMUIec F9g7k3+00aItUSl22qR03dAQ2CPWoxD0/trV4mUxkIpEhVb1xQjTPWIRYONXmI7PkGfz qf4aMD/hSCGRkUX3VdGujAoKs/lvsUKP59N1G8BsfRsDDIjJmlHxHSBnrjkiisQcBtJM dw+A== X-Gm-Message-State: AOJu0YwkgwkcopZZcIn+eiB1DkBVpVlD3tf8WfEe83YSB/fPohv31cFo utHEuAoSa5sQkMNoLqE33e7PTUmZAT+rF4vn0jR/YRHSY/Pjgzi7L/ibP197ZH8GBXsHHLSz81p dqJQ= X-Gm-Gg: AY/fxX4u6tVN/UOOy+Nw6SpY71iGrpwZlzP7ZOr+PfY3kTZBNLWiptbWZkQdcBCTJv6 SBQvOLGR0IeTjPtHPi68/Ws0jjShvnyXzEDkSPUWfP6D2pdKJlCqycFGKPSQnhbfC5ZdVftsUzE BnbHwR1BbKiWr4atQ1m0RijEFQkSlbjdRZ396fl5Jm8yOdJbvG8PQU5LXpb0ejOpeTW3FD/7Ue4 mCHZZyIsL9YRCngA2pJM1ceXXOeGZ3HmG8WYTMc71osww/Y3DkbiLgqLevuaiPJo0I9rkiv+fFT QgrzcYMcap335KvxdhJfMaw6x6wSmx8B3RrhMsdwHSKeoRbREtQGqLYcEYoktxIuETkH3Qjwbz6 l/5iSVsyxIGjSU6msIaG0s+sL5EJKnaehBmeGA3XuNZfLJS2KhFUWOhqy857KSmL+hhncas6u7t g1RANwPbPNNjRhintRpPE7zJuvRpnJnApbOTDWuM6S9t4AF5/mFU0FZk9Ow+IUvy15E3ZL5ygNu Xws6kej66oyng== X-Google-Smtp-Source: AGHT+IEdZqCNBgtszHwJM8ODdWo62CUx8G8aX8owGhlsnlqWQawi+6BqAnTgaJDVETr1utJqg2Wr3A== X-Received: by 2002:a05:600c:1392:b0:477:6d96:b3c8 with SMTP id 5b1f17b1804b1-47d84b34673mr32171905e9.23.1767795099069; Wed, 07 Jan 2026 06:11:39 -0800 (PST) Message-ID: <239a5d80-c0af-410b-a053-5fa84273aecd@suse.com> Date: Wed, 7 Jan 2026 15:11:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk From: Jan Beulich Subject: [PATCH v2] x86: guard synthetic feature and bug enumerators Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit While 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 --- v2: Fix shim build. Use named label operand in pdx.h. --- 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(__ASSEMBLER__) && __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/guest/xen-hcall.h +++ b/xen/arch/x86/include/asm/guest/xen-hcall.h @@ -31,11 +31,13 @@ long res, tmp__; \ asm volatile ( \ ALTERNATIVE_2("call early_hypercall", \ - "vmmcall", ALT_NOT(X86_FEATURE_USE_VMCALL), \ - "vmcall", X86_FEATURE_USE_VMCALL) \ + "vmmcall", [vmmcall], \ + "vmcall", [vmcall]) \ : "=a" (res), "=D" (tmp__) ASM_CALL_CONSTRAINT \ : "0" (hcall), \ - "1" ((long)(a1)) \ + "1" ((long)(a1)), \ + [vmmcall] "i" (ALT_NOT(X86_FEATURE_USE_VMCALL)), \ + [vmcall] "i" (X86_FEATURE_USE_VMCALL) \ : "memory" ); \ (type)res; \ }) @@ -45,12 +47,14 @@ long res, tmp__; \ asm volatile ( \ ALTERNATIVE_2("call early_hypercall", \ - "vmmcall", ALT_NOT(X86_FEATURE_USE_VMCALL), \ - "vmcall", X86_FEATURE_USE_VMCALL) \ + "vmmcall", [vmmcall], \ + "vmcall", [vmcall]) \ : "=a" (res), "=D" (tmp__), "=S" (tmp__) \ ASM_CALL_CONSTRAINT \ : "0" (hcall), \ - "1" ((long)(a1)), "2" ((long)(a2)) \ + "1" ((long)(a1)), "2" ((long)(a2)), \ + [vmmcall] "i" (ALT_NOT(X86_FEATURE_USE_VMCALL)), \ + [vmcall] "i" (X86_FEATURE_USE_VMCALL) \ : "memory" ); \ (type)res; \ }) @@ -60,12 +64,14 @@ long res, tmp__; \ asm volatile ( \ ALTERNATIVE_2("call early_hypercall", \ - "vmmcall", ALT_NOT(X86_FEATURE_USE_VMCALL), \ - "vmcall", X86_FEATURE_USE_VMCALL) \ + "vmmcall", [vmmcall], \ + "vmcall", [vmcall]) \ : "=a" (res), "=D" (tmp__), "=S" (tmp__), "=d" (tmp__) \ ASM_CALL_CONSTRAINT \ : "0" (hcall), \ - "1" ((long)(a1)), "2" ((long)(a2)), "3" ((long)(a3)) \ + "1" ((long)(a1)), "2" ((long)(a2)), "3" ((long)(a3)), \ + [vmmcall] "i" (ALT_NOT(X86_FEATURE_USE_VMCALL)), \ + [vmcall] "i" (X86_FEATURE_USE_VMCALL) \ : "memory" ); \ (type)res; \ }) @@ -76,13 +82,15 @@ register long _a4 asm ("r10") = ((long)(a4)); \ asm volatile ( \ ALTERNATIVE_2("call early_hypercall", \ - "vmmcall", ALT_NOT(X86_FEATURE_USE_VMCALL), \ - "vmcall", X86_FEATURE_USE_VMCALL) \ + "vmmcall", [vmmcall], \ + "vmcall", [vmcall]) \ : "=a" (res), "=D" (tmp__), "=S" (tmp__), "=d" (tmp__), \ "=&r" (tmp__) ASM_CALL_CONSTRAINT \ : "0" (hcall), \ "1" ((long)(a1)), "2" ((long)(a2)), "3" ((long)(a3)), \ - "4" (_a4) \ + "4" (_a4), \ + [vmmcall] "i" (ALT_NOT(X86_FEATURE_USE_VMCALL)), \ + [vmcall] "i" (X86_FEATURE_USE_VMCALL) \ : "memory" ); \ (type)res; \ }) --- 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 %l[" #label "]", \ + [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 Wed Jan 07 14:15:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 14:15:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196733.1514468 (Exim 4.92) (envelope-from ) id 1vdUKL-0003mg-4F; Wed, 07 Jan 2026 14:15:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196733.1514468; Wed, 07 Jan 2026 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 1vdUKL-0003mZ-1E; Wed, 07 Jan 2026 14:15:57 +0000 Received: by outflank-mailman (input) for mailman id 1196733; Wed, 07 Jan 2026 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 1vdUKK-0003mT-A2 for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 14:15:56 +0000 Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [2a00:1450:4864:20::431]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 613075e2-ebd3-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 15:15:55 +0100 (CET) Received: by mail-wr1-x431.google.com with SMTP id ffacd0b85a97d-42b3d7c1321so1256620f8f.3 for ; Wed, 07 Jan 2026 06:15:55 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0e180csm10399322f8f.10.2026.01.07.06.15.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jan 2026 06:15:54 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 613075e2-ebd3-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767795354; x=1768400154; 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=inh0jSeo2mIZtxJK0EUO10bXoajZTBl2mmwHlqUuR1Y=; b=dYpg2sV0g8wwMD4Kr6qjWRzMWebI6hU/IyWxHNp19XY/1jvEY/L6T6y8lvUlMVwoRk VtkW2UThO0awi9PUxQMtWDazcklwmQwegVs5GLSzwM80jRSBlhUGSoYeJT3y/NYvVp3s Yb6O6pvCE6+cE25ZNAHONHddgXgaG6uEOWp5g9P82npC+r3f2kdFO15pCx2VGFFUgppT yyQCZDAlNTKT4l3I0DGf1RFFX7IZIShpPdnxya4aVOEr0EneWFuiCUfdMARC3dgFvfgu CPtSA1Li9pkhWlS03bWES2zubLTyi1uP4hq0xRgI0ELwDqEmyBeqLeYOza4dGTwGy1a7 vJYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767795354; x=1768400154; h=content-transfer-encoding:autocrypt:content-language:cc:to:subject :from:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=inh0jSeo2mIZtxJK0EUO10bXoajZTBl2mmwHlqUuR1Y=; b=kn9ms6z0Zkudf79vNzevlL1U5vx2HVOoglUTinCT+x9XSF2MNWZOnVaJ5viwcJ/4LC zSpPjIaudUpoPrmNVSPqOBy5mld1GqOwt70P5zgMH9codREO0SDBI+I8vKs1JypLaM0z 8msa6aAuWwhwNKmmnYKqp99ofSnohGRr3/DNDi5EbbsgjGuIhoXVBGfOZwGGJWgpCmCX cvf2pahGyME5rI+Ii/0jNH+DG6o5frUk9Wy7HjJmda+SZLno1SFC4fPrg56w3CIdf8QD Te4XUTnjY5zaBIx5SvyGaimImJrxONk1buejBwph9XZK8DQroj+fOPasKB+QyVqxUwQd gD/g== X-Gm-Message-State: AOJu0YwzhZQaA/LfNMW3/f6c8fHYNGRxuc4JFnJNwx/RHC4czu3cmvMw C4PRn25kR6TB84EeArbGV1nBZHcgWu9/EMS+BuSE5C07KQN14oJNjurPV/2if7z69O5c5uWtLCx UcBE= X-Gm-Gg: AY/fxX6JQWInT8U1KflLP0AlkLEvXVyzLDXMvQN+GB5MFoTmZNme30NcR+4Tf6PC4LK 7Ikysn9Ts8DEnPO99A6i64yt4zs2vIsYjJxAYQu5Avri2pi62eChcie4hz8NTdEzrt2ZxcQ+Ove x5iTyiBTM96EzlOLuapvm2bzdeZFqcYv1eww7QzLPP+3gJuCM0lnEp52uoMi0yQxVWzbVD01HTi jUIbrWZjfqOJx9KeIfARJsNWqJ6l8kfouZ2ysKiwfxdxjTnEnCHP1gngBpvmCGaONjB7mvAVIP8 r6rJe7IXmErwklFU4KLvXy/s+WOYK1o2fPm9OVdZR7yBkWolEiNonjkfpVV9TETqB0Wg+2Dm34H FVbz9nocJ/77rcrGHBBoahhWEYhk7HNSnhKrg9+E0Pz0qeK5a0X67GzTWrgQHu+W5xVWV9fRWyb zM3+00LFp8wig3IT/L5alJbP9Rvp45mhgotfnLJWXLpQ0akdTmMd1tJ/YS9NnJbzw946npil+lk jA= X-Google-Smtp-Source: AGHT+IHFY6DctEC5XrtlpeUdmBMfhXfAZetMaxV1iXewE5awWQcTXS9A+oTQojXsQaizn8E8IUs3Xg== X-Received: by 2002:a05:6000:2305:b0:430:f7ae:af3e with SMTP id ffacd0b85a97d-432c3798309mr3350400f8f.32.1767795354548; Wed, 07 Jan 2026 06:15:54 -0800 (PST) Message-ID: <4bd68e41-e665-4992-9d3c-0086bb5195ef@suse.com> Date: Wed, 7 Jan 2026 15:15:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jan Beulich Subject: [PATCH v2 0/2] x86/cpu-policy: librarify copy-in/-out To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Language: en-US Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 1: move CPU policy library code 2: split out copy-in/-out functions Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 07 14:17:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 14:17:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196745.1514479 (Exim 4.92) (envelope-from ) id 1vdULQ-0004Ll-Ff; Wed, 07 Jan 2026 14:17:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196745.1514479; Wed, 07 Jan 2026 14:17:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdULQ-0004Le-D3; Wed, 07 Jan 2026 14:17:04 +0000 Received: by outflank-mailman (input) for mailman id 1196745; Wed, 07 Jan 2026 14:17:03 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdULP-0004De-AP for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 14:17:03 +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 8936668f-ebd3-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 15:17:02 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-47d182a8c6cso13309445e9.1 for ; Wed, 07 Jan 2026 06:17:02 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f68f686sm99574385e9.3.2026.01.07.06.17.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jan 2026 06:17:01 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8936668f-ebd3-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767795422; x=1768400222; 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=SnLheoEW/Yh1PkgGyXZklN/D8HIZT01TyPTA06JIXwo=; b=XTyQD8+Dh3Qa01ZuAkXOwPbEprxD5E3Kd7JWldEpRpYl2I7eGN1g95unrDElV6d7/j kCYYPQ0w0KfLcYtO93Mc169fpig+wwzlFaUCPoH+BW1Qq5CHvL0lE1Bejnniu+l4ntvc ObZa3K1NisqENEEdiNxvf06amvqE8mMy+xwomua/v0CRvqxdV+ekUP6D7pdAqmFqHKfv s5mSnS7cbTVeeX6FZRok8f1XeaxZZ9FDKlXZixH4l6lW9RIB999yd1tIOB31RLHA17l4 Qf5i78mVGODtWInNJjBBj2MxiSQhKV0MDI4lcPfEy2MErYvMvmZlXmFXeyKcTdgGWrXw RIdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767795422; x=1768400222; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=SnLheoEW/Yh1PkgGyXZklN/D8HIZT01TyPTA06JIXwo=; b=qFhyPkHGbZUBjAExGR12OqwX5KkjZicAeqOOPYjSlQVG9p4f5LQ0nS8m50O5f0YXlY 8p66HZPWhe9IocVw7oREHJfpl4V7d7EoMiLp0CeA4czrdoT5iaYPKQjRc0qLvLOMGgUC F3jmqaB9+FubQ8cR/45OKoORB4LgHtu4Yr/MicS5kbnqjrEQUOe0a3m3GSbkwygNb0xM 9GOjIpJeZf9X9pVtjzQdvs/mU9vnH1bYBFM8QJziWHWhVMDduZ7exZPmpED5j+4NraLG 8K8gC5NuuUKhPQ58YDmzsKMZPfVhk4bVYt+Y0gb0+begIp+h3LEWaS/3h08MxOgdcsLn 0nZQ== X-Gm-Message-State: AOJu0YxD8rJ6pZ417RctCpR85Cd630oo4sZKosllYCvX0AeCNhruSIrs gTVlTy62riHC1GaobnGlnPo84W2JKpZuScWU13uMAGPE/OqEeaCfv6quuaxX26U3EgsBDqEi8Fv SNHE= X-Gm-Gg: AY/fxX7rHwbpg5uNlGExmm904T1GkiHoDdHdsI5clb/hQPY1IcdCNHOatHNLmL6x+L0 4namDBqy9wQb1qNYrM4Kj/fVb0NRMYqdcStNV3V8s4ctZS8I2R+ep5GZOOS9L5O9OHeOV8QqOfN oi5I45p9IDGfKxOx4voZ+lDoMqlyo5pzENqMGSzSDFz/g5gMquy9qpvoYX7lyYFT8ViJltarR61 GYmTQb/mO9BdTBuLknApRxwdHy0289WanuOkpgfDtWpbM6V/sBinEP9NlVomEt+t45DRzjvEh63 VogSQmOrI6piYNmZ3OEI0Xqkgtcx9HEyYJ2LszrDYncfs7g5dR9MgGxdMmCsa1duC1qhLNY+4FN qhxh9F1x2kKyvPqJHGC+RAwfRCEm5k5736VwjHSOQzm5oeDirnHT9/T4SQIY5vT1RVYmnUbdRDo BJ8UuRuiuZaGj4KC+7WjXYddSCF+lyhYlp2uMMPJsL/F2oyqsP4RcGg45WIMqLYBg4EIEZE8oYI cqHyhRnkUOfew== X-Google-Smtp-Source: AGHT+IGCI7amaymcZdP7rEvrnNfioibzSU1rmbzl2BdIQYXYOc3pNz/MXDctUUt2rW1kjUO9JaL0bw== X-Received: by 2002:a05:600c:3484:b0:479:2a0b:180d with SMTP id 5b1f17b1804b1-47d84b20fd7mr31986115e9.11.1767795421650; Wed, 07 Jan 2026 06:17:01 -0800 (PST) Message-ID: <7c06bd5e-fad2-42cb-947f-6749f647b068@suse.com> Date: Wed, 7 Jan 2026 15:17:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v2 1/2] x86/cpu-policy: move CPU policy library code From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <4bd68e41-e665-4992-9d3c-0086bb5195ef@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: <4bd68e41-e665-4992-9d3c-0086bb5195ef@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ... to a dedicated subdir of x86's private lib/ sub-tree. For the CPU policy harnesses and libxenguest use $(lib-y) as set by the new Makefile.common, whereas for the emulator harnesses stick to building just cpuid.o for the time being. Requested-by: Andrew Cooper Signed-off-by: Jan Beulich --- v2: New. --- tools/fuzz/cpu-policy/Makefile | 7 +++++-- tools/fuzz/x86_instruction_emulator/Makefile | 2 +- tools/libs/guest/Makefile.common | 7 +++++-- tools/tests/cpu-policy/Makefile | 7 +++++-- tools/tests/x86_emulator/Makefile | 2 +- xen/arch/x86/arch.mk | 1 + xen/arch/x86/lib/Makefile | 2 ++ xen/arch/x86/lib/cpu-policy/Makefile | 1 + xen/arch/x86/lib/cpu-policy/Makefile.common | 3 +++ xen/{lib/x86 => arch/x86/lib/cpu-policy}/cpuid.c | 0 xen/{lib/x86 => arch/x86/lib/cpu-policy}/msr.c | 0 xen/{lib/x86 => arch/x86/lib/cpu-policy}/policy.c | 0 xen/{lib/x86 => arch/x86/lib/cpu-policy}/private.h | 0 xen/lib/Makefile | 2 -- xen/lib/x86/Makefile | 3 --- 15 files changed, 24 insertions(+), 13 deletions(-) create mode 100644 xen/arch/x86/lib/cpu-policy/Makefile create mode 100644 xen/arch/x86/lib/cpu-policy/Makefile.common rename xen/{lib/x86 => arch/x86/lib/cpu-policy}/cpuid.c (100%) rename xen/{lib/x86 => arch/x86/lib/cpu-policy}/msr.c (100%) rename xen/{lib/x86 => arch/x86/lib/cpu-policy}/policy.c (100%) rename xen/{lib/x86 => arch/x86/lib/cpu-policy}/private.h (100%) delete mode 100644 xen/lib/x86/Makefile diff --git a/tools/fuzz/cpu-policy/Makefile b/tools/fuzz/cpu-policy/Makefile index 6e7743e0aa12..76ecf20e8dbd 100644 --- a/tools/fuzz/cpu-policy/Makefile +++ b/tools/fuzz/cpu-policy/Makefile @@ -20,9 +20,12 @@ install: all CFLAGS += $(CFLAGS_xeninclude) -D__XEN_TOOLS__ CFLAGS += $(APPEND_CFLAGS) -Og -vpath %.c ../../../xen/lib/x86 +vpath %.c $(XEN_ROOT)/xen/arch/x86/lib/cpu-policy -afl-policy-fuzzer: afl-policy-fuzzer.o msr.o cpuid.o +lib-y := +include $(XEN_ROOT)/xen/arch/x86/lib/cpu-policy/Makefile.common + +afl-policy-fuzzer: afl-policy-fuzzer.o $(lib-y) $(CC) $(CFLAGS) $^ -o $@ -include $(DEPS_INCLUDE) diff --git a/tools/fuzz/x86_instruction_emulator/Makefile b/tools/fuzz/x86_instruction_emulator/Makefile index d104b15f4fbf..4e4877a20322 100644 --- a/tools/fuzz/x86_instruction_emulator/Makefile +++ b/tools/fuzz/x86_instruction_emulator/Makefile @@ -21,7 +21,7 @@ vpath %.h ../../tests/x86_emulator CFLAGS += -iquote ../../tests/x86_emulator # Add libx86 to the build -vpath %.c $(XEN_ROOT)/xen/lib/x86 +vpath %.c $(XEN_ROOT)/xen/arch/x86/lib/cpu-policy x86_emulate: mkdir -p $@ diff --git a/tools/libs/guest/Makefile.common b/tools/libs/guest/Makefile.common index a026a2f662b0..b928a4a246a9 100644 --- a/tools/libs/guest/Makefile.common +++ b/tools/libs/guest/Makefile.common @@ -33,9 +33,12 @@ LIBELF_OBJS += libelf-dominfo.o OBJS-y += $(LIBELF_OBJS) ifeq ($(CONFIG_X86),y) # Add libx86 to the build -vpath %.c ../../../xen/lib/x86 +vpath %.c $(XEN_ROOT)/xen/arch/x86/lib/cpu-policy -OBJS-y += cpuid.o msr.o policy.o +lib-y := +include $(XEN_ROOT)/xen/arch/x86/lib/cpu-policy/Makefile.common + +OBJS-y += $(lib-y) endif # new domain builder diff --git a/tools/tests/cpu-policy/Makefile b/tools/tests/cpu-policy/Makefile index 24f87e2eca2a..d8e4d222f4e4 100644 --- a/tools/tests/cpu-policy/Makefile +++ b/tools/tests/cpu-policy/Makefile @@ -42,11 +42,14 @@ CFLAGS += $(APPEND_CFLAGS) LDFLAGS += $(APPEND_LDFLAGS) -vpath %.c ../../../xen/lib/x86 +vpath %.c $(XEN_ROOT)/xen/arch/x86/lib/cpu-policy + +lib-y := +include $(XEN_ROOT)/xen/arch/x86/lib/cpu-policy/Makefile.common %.o: Makefile -test-cpu-policy: test-cpu-policy.o msr.o cpuid.o policy.o +test-cpu-policy: test-cpu-policy.o $(lib-y) $(CC) $^ -o $@ $(LDFLAGS) -include $(DEPS_INCLUDE) diff --git a/tools/tests/x86_emulator/Makefile b/tools/tests/x86_emulator/Makefile index 376cfe244d1c..e18725d0c303 100644 --- a/tools/tests/x86_emulator/Makefile +++ b/tools/tests/x86_emulator/Makefile @@ -17,7 +17,7 @@ vpath x86_emulate/%.h $(XEN_ROOT)/xen/arch/x86 HOSTCFLAGS += -iquote $(XEN_ROOT)/xen/arch/x86 # Add libx86 to the build -vpath %.c $(XEN_ROOT)/xen/lib/x86 +vpath %.c $(XEN_ROOT)/xen/arch/x86/lib/cpu-policy CFLAGS += $(CFLAGS_xeninclude) diff --git a/xen/arch/x86/arch.mk b/xen/arch/x86/arch.mk index 0203138a819a..be6c76d2934b 100644 --- a/xen/arch/x86/arch.mk +++ b/xen/arch/x86/arch.mk @@ -4,6 +4,7 @@ export XEN_IMG_OFFSET := 0x200000 ARCH_LIBS-y += arch/x86/lib/lib.a +ALL_LIBS-y += arch/x86/lib/cpu-policy/lib.a CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFFSET) diff --git a/xen/arch/x86/lib/Makefile b/xen/arch/x86/lib/Makefile index b9a65c662a56..fe9a27187992 100644 --- a/xen/arch/x86/lib/Makefile +++ b/xen/arch/x86/lib/Makefile @@ -6,3 +6,5 @@ lib-y += generic-hweightl.o lib-y += memcpy.o lib-y += memset.o lib-y += scrub-page.o + +obj-y += cpu-policy/ diff --git a/xen/arch/x86/lib/cpu-policy/Makefile b/xen/arch/x86/lib/cpu-policy/Makefile new file mode 100644 index 000000000000..b12cf7836d4c --- /dev/null +++ b/xen/arch/x86/lib/cpu-policy/Makefile @@ -0,0 +1 @@ +include $(srcdir)/Makefile.common diff --git a/xen/arch/x86/lib/cpu-policy/Makefile.common b/xen/arch/x86/lib/cpu-policy/Makefile.common new file mode 100644 index 000000000000..35475af78048 --- /dev/null +++ b/xen/arch/x86/lib/cpu-policy/Makefile.common @@ -0,0 +1,3 @@ +lib-y += cpuid.o +lib-y += msr.o +lib-y += policy.o diff --git a/xen/lib/x86/cpuid.c b/xen/arch/x86/lib/cpu-policy/cpuid.c similarity index 100% rename from xen/lib/x86/cpuid.c rename to xen/arch/x86/lib/cpu-policy/cpuid.c diff --git a/xen/lib/x86/msr.c b/xen/arch/x86/lib/cpu-policy/msr.c similarity index 100% rename from xen/lib/x86/msr.c rename to xen/arch/x86/lib/cpu-policy/msr.c diff --git a/xen/lib/x86/policy.c b/xen/arch/x86/lib/cpu-policy/policy.c similarity index 100% rename from xen/lib/x86/policy.c rename to xen/arch/x86/lib/cpu-policy/policy.c diff --git a/xen/lib/x86/private.h b/xen/arch/x86/lib/cpu-policy/private.h similarity index 100% rename from xen/lib/x86/private.h rename to xen/arch/x86/lib/cpu-policy/private.h diff --git a/xen/lib/Makefile b/xen/lib/Makefile index efca830d924c..850efeb4c570 100644 --- a/xen/lib/Makefile +++ b/xen/lib/Makefile @@ -1,5 +1,3 @@ -obj-$(CONFIG_X86) += x86/ - lib-y += bsearch.o lib-y += ctors.o lib-y += ctype.o diff --git a/xen/lib/x86/Makefile b/xen/lib/x86/Makefile deleted file mode 100644 index 780ea05db158..000000000000 --- a/xen/lib/x86/Makefile +++ /dev/null @@ -1,3 +0,0 @@ -obj-y += cpuid.o -obj-y += msr.o -obj-y += policy.o From xen-devel-bounces@lists.xenproject.org Wed Jan 07 14:18:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 14:18:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196753.1514488 (Exim 4.92) (envelope-from ) id 1vdUMK-0004vg-OK; Wed, 07 Jan 2026 14:18:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196753.1514488; Wed, 07 Jan 2026 14:18:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdUMK-0004vZ-Lj; Wed, 07 Jan 2026 14:18:00 +0000 Received: by outflank-mailman (input) for mailman id 1196753; Wed, 07 Jan 2026 14:17: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 1vdUMJ-0004vN-4A for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 14:17:59 +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 a988fb47-ebd3-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 15:17:56 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-4775e891b5eso10088615e9.2 for ; Wed, 07 Jan 2026 06:17:56 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d865e3d22sm14836415e9.1.2026.01.07.06.17.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jan 2026 06:17:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a988fb47-ebd3-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767795476; x=1768400276; 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=B51kdTgZdEeG/nCjLbcF/Mc90bD2P9ay1J22aYRdGG8=; b=f3LIjd6SMJwA+IGNBXAmpLrn+YRheYtBAzuN45DiYYL7IVV8OgFscxAFO5k8CRT02o /Fdez4RZV5Yea2lqpTnKsMZ1kEwfsw6o0K2tZMsZrpuKkpbOVDUgcjMa0jA2YaqyHMrO UC4iklCG5IljosUSmToaTX959d0KhppOOQTZOzoXQtG7wlXHqnXG8V5aqkja3J45bCjt rN+TzPdux6yBo6ZWU8gwul77dqibkt5JrMYI1xZfXqySkWkoN5K7lHG5fL5tqZXHoQvp ei4R0qmnYt6Ix7Yj8fLdwjdjtAboxvNaC61OcxEfYtnitOgv1FyO+B4WdhXheRX5WvR8 xlkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767795476; x=1768400276; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=B51kdTgZdEeG/nCjLbcF/Mc90bD2P9ay1J22aYRdGG8=; b=b8wFp/NgPl4p2Pgg5ZhSFK7C0R8jBzCwg5e7sqXGd93S7N2oYkZNnDs6MlnxqLLnkJ CRTB535f3wTuwIsCMfEvfLKquiSERVs3zY7Jc/UVzZWi/EIbyoIJJimOPWPaTbHoHR+y nHb9sRDBmq+GBf+DgzMB9A3ST1Xu+MTHKz7sv9flYRZLQCSqDRG0FiutpiupUVutVzOW WVJI/80j9UgbudetkuVmocc39T9GHl9l6/cXhK/ZVSy5EUFXlcnUSC7U2B70xJKXxaZW zLFrAw1JHfWmNYHem6Vr3JsP5lvBLZZyqEtPjCwdBlK4AZmHSlVggdH1f4IwlEsdGrJD aDIg== X-Gm-Message-State: AOJu0YwAdiEMZEN5AM/4zK1Qj8ZafHD4mHxZJCvxTZdlMqjy8QSurYsO 2lBbRK6DSMATP4qiFBXMrtO/v7ojfi2Jkv9IFmSQVxS8WG1phTXEHdQZSBxCPrxjH/JADOgOQaC Vfrg= X-Gm-Gg: AY/fxX79lOum2QiLmySDXBAcO13/iAOgDQEFa4+jIxYVjcygQaSyW9mTwPQe63wUXLG aJWf4S+6eWr7XaX/q8eYbuRRNnrmX6A3dciwN1srcJglReatRJrtt3Y+R8ZAR8SHrgtnrn3pDGV oBbRnfZpq2ha2zp467pmQKHT1Q15ohvdiQOsPK2Rzxe06RkRskxr76yw6OpDDugWQ5RpH8JS5Ie HrD7Jcj0xd6AM9LEwTo1CFdpAWF+2FS4H0qe+NLifkz7dBMWXBqRU1/NT739DY5ywLDIhi1JgVw uEBliFpeE+DaVnIbuMhLrhzoWh+IfTIAth85e/QQVxQ8Rp68zeFw1BdQMYgC+Saz+OBYtYUtnPQ rIm7Y1vEOygg5jjvhmA4VMcB/LK0GajefnBe57MoSBYzG8H17MnV/uXqaR9nwJB4TS2c9t9y61N hLkb1eazMXwKKICWga48me4X5xxzkVwxqX0GXCyGXtGRKfb433/xyefI8jloq2Ja0AYzKapQ50A YE= X-Google-Smtp-Source: AGHT+IHmSoe83rxhwzHPP+KD5pqvo4aJb6x8vD2N1054k/CIKMHmACtTrPmbbUkHsYqblgUcKKFC0A== X-Received: by 2002:a05:600c:1991:b0:477:55c9:c3ea with SMTP id 5b1f17b1804b1-47d84b40aa4mr34943525e9.35.1767795475783; Wed, 07 Jan 2026 06:17:55 -0800 (PST) Message-ID: Date: Wed, 7 Jan 2026 15:17:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v2 2/2] x86/cpu-policy: split out copy-in/-out functions From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Penny Zheng References: <4bd68e41-e665-4992-9d3c-0086bb5195ef@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: <4bd68e41-e665-4992-9d3c-0086bb5195ef@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This is to aid with MGMT_HYPERCALL work, leaving the functions potentially unreferenced (which Misra dislikes). By moving them to separate archive members, the linker simply will not pick them up when not needed. As the CPUID and MSR ones are always used together, put the "from" and "to" variants of each together in one file respectively. Signed-off-by: Jan Beulich --- v2: Re-base over moving of the entire directory. --- xen/arch/x86/lib/cpu-policy/Makefile.common | 3 +- .../x86/lib/cpu-policy/copy-from-buffer.c | 238 ++++++++++++++++++ xen/arch/x86/lib/cpu-policy/copy-to-buffer.c | 204 +++++++++++++++ xen/arch/x86/lib/cpu-policy/cpuid.c | 226 ----------------- xen/arch/x86/lib/cpu-policy/msr.c | 130 ---------- xen/arch/x86/lib/cpu-policy/private.h | 31 --- 6 files changed, 444 insertions(+), 388 deletions(-) create mode 100644 xen/arch/x86/lib/cpu-policy/copy-from-buffer.c create mode 100644 xen/arch/x86/lib/cpu-policy/copy-to-buffer.c delete mode 100644 xen/arch/x86/lib/cpu-policy/msr.c diff --git a/xen/arch/x86/lib/cpu-policy/Makefile.common b/xen/arch/x86/lib/cpu-policy/Makefile.common index 35475af78048..aff662aae83b 100644 --- a/xen/arch/x86/lib/cpu-policy/Makefile.common +++ b/xen/arch/x86/lib/cpu-policy/Makefile.common @@ -1,3 +1,4 @@ +lib-y += copy-from-buffer.o +lib-y += copy-to-buffer.o lib-y += cpuid.o -lib-y += msr.o lib-y += policy.o diff --git a/xen/arch/x86/lib/cpu-policy/copy-from-buffer.c b/xen/arch/x86/lib/cpu-policy/copy-from-buffer.c new file mode 100644 index 000000000000..24f7bc79d2bd --- /dev/null +++ b/xen/arch/x86/lib/cpu-policy/copy-from-buffer.c @@ -0,0 +1,238 @@ +#ifdef __XEN__ + +#include +#include +#include +#include + +#include + +#define copy_from_buffer_offset copy_from_guest_offset + +#else /* !__XEN__ */ + +#include +#include +#include +#include +#include + +#include + +#include + +#define array_access_nospec(a, i) (a)[(i)] + +/* memcpy(), but with copy_from_guest_offset()'s API. */ +#define copy_from_buffer_offset(dst, src, index, nr) \ +({ \ + const typeof(*(src)) *src_ = (src); \ + typeof(*(dst)) *dst_ = (dst); \ + typeof(index) index_ = (index); \ + typeof(nr) nr_ = (nr), i_; \ + \ + for ( i_ = 0; i_ < nr_; i_++ ) \ + dst_[i_] = src_[index_ + i_]; \ + 0; \ +}) + +#endif /* __XEN__ */ + +#include + +int x86_cpuid_copy_from_buffer(struct cpu_policy *p, + const cpuid_leaf_buffer_t leaves, + uint32_t nr_entries, uint32_t *err_leaf, + uint32_t *err_subleaf) +{ + unsigned int i; + xen_cpuid_leaf_t data; + + if ( err_leaf ) + *err_leaf = -1; + if ( err_subleaf ) + *err_subleaf = -1; + + /* + * A well formed caller is expected to pass an array with leaves in order, + * and without any repetitions. However, due to per-vendor differences, + * and in the case of upgrade or levelled scenarios, we typically expect + * fewer than MAX leaves to be passed. + * + * Detecting repeated entries is prohibitively complicated, so we don't + * bother. That said, one way or another if more than MAX leaves are + * passed, something is wrong. + */ + if ( nr_entries > CPUID_MAX_SERIALISED_LEAVES ) + return -E2BIG; + + for ( i = 0; i < nr_entries; ++i ) + { + struct cpuid_leaf l; + + if ( copy_from_buffer_offset(&data, leaves, i, 1) ) + return -EFAULT; + + l = (struct cpuid_leaf){ data.a, data.b, data.c, data.d }; + + switch ( data.leaf ) + { + case 0 ... ARRAY_SIZE(p->basic.raw) - 1: + switch ( data.leaf ) + { + case 0x4: + if ( data.subleaf >= ARRAY_SIZE(p->cache.raw) ) + goto out_of_range; + + array_access_nospec(p->cache.raw, data.subleaf) = l; + break; + + case 0x7: + if ( data.subleaf >= ARRAY_SIZE(p->feat.raw) ) + goto out_of_range; + + array_access_nospec(p->feat.raw, data.subleaf) = l; + break; + + case 0xb: + if ( data.subleaf >= ARRAY_SIZE(p->topo.raw) ) + goto out_of_range; + + array_access_nospec(p->topo.raw, data.subleaf) = l; + break; + + case 0xd: + if ( data.subleaf >= ARRAY_SIZE(p->xstate.raw) ) + goto out_of_range; + + array_access_nospec(p->xstate.raw, data.subleaf) = l; + break; + + default: + if ( data.subleaf != XEN_CPUID_NO_SUBLEAF ) + goto out_of_range; + + array_access_nospec(p->basic.raw, data.leaf) = l; + break; + } + break; + + case 0x40000000: + if ( data.subleaf != XEN_CPUID_NO_SUBLEAF ) + goto out_of_range; + + p->hv_limit = l.a; + break; + + case 0x40000100: + if ( data.subleaf != XEN_CPUID_NO_SUBLEAF ) + goto out_of_range; + + p->hv2_limit = l.a; + break; + + case 0x80000000U ... 0x80000000U + ARRAY_SIZE(p->extd.raw) - 1: + if ( data.subleaf != XEN_CPUID_NO_SUBLEAF ) + goto out_of_range; + + array_access_nospec(p->extd.raw, data.leaf & 0xffff) = l; + break; + + default: + goto out_of_range; + } + } + + x86_cpu_policy_recalc_synth(p); + + return 0; + + out_of_range: + if ( err_leaf ) + *err_leaf = data.leaf; + if ( err_subleaf ) + *err_subleaf = data.subleaf; + + return -ERANGE; +} + +int x86_msr_copy_from_buffer(struct cpu_policy *p, + const msr_entry_buffer_t msrs, uint32_t nr_entries, + uint32_t *err_msr) +{ + unsigned int i; + xen_msr_entry_t data; + int rc; + + if ( err_msr ) + *err_msr = -1; + + /* + * A well formed caller is expected to pass an array with entries in + * order, and without any repetitions. However, due to per-vendor + * differences, and in the case of upgrade or levelled scenarios, we + * typically expect fewer than MAX entries to be passed. + * + * Detecting repeated entries is prohibitively complicated, so we don't + * bother. That said, one way or another if more than MAX entries are + * passed, something is wrong. + */ + if ( nr_entries > MSR_MAX_SERIALISED_ENTRIES ) + return -E2BIG; + + for ( i = 0; i < nr_entries; i++ ) + { + if ( copy_from_buffer_offset(&data, msrs, i, 1) ) + return -EFAULT; + + if ( data.flags ) /* .flags MBZ */ + { + rc = -EINVAL; + goto err; + } + + switch ( data.idx ) + { + /* + * Assign data.val to p->field, checking for truncation if the + * backing storage for field is smaller than uint64_t + */ +#define ASSIGN(field) \ +({ \ + if ( (typeof(p->field))data.val != data.val ) \ + { \ + rc = -EOVERFLOW; \ + goto err; \ + } \ + p->field = data.val; \ +}) + + case MSR_INTEL_PLATFORM_INFO: ASSIGN(platform_info.raw); break; + case MSR_ARCH_CAPABILITIES: ASSIGN(arch_caps.raw); break; + +#undef ASSIGN + + default: + rc = -ERANGE; + goto err; + } + } + + return 0; + + err: + if ( err_msr ) + *err_msr = data.idx; + + return rc; +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/x86/lib/cpu-policy/copy-to-buffer.c b/xen/arch/x86/lib/cpu-policy/copy-to-buffer.c new file mode 100644 index 000000000000..190dac746cdf --- /dev/null +++ b/xen/arch/x86/lib/cpu-policy/copy-to-buffer.c @@ -0,0 +1,204 @@ +#ifdef __XEN__ + +#include +#include +#include + +#include + +#define copy_to_buffer_offset copy_to_guest_offset + +#else /* !__XEN__ */ + +#include +#include +#include +#include +#include + +#include + +#include + +/* memcpy(), but with copy_to_guest_offset()'s API. */ +#define copy_to_buffer_offset(dst, index, src, nr) \ +({ \ + const typeof(*(src)) *src_ = (src); \ + typeof(*(dst)) *dst_ = (dst); \ + typeof(index) index_ = (index); \ + typeof(nr) nr_ = (nr), i_; \ + \ + for ( i_ = 0; i_ < nr_; i_++ ) \ + dst_[index_ + i_] = src_[i_]; \ + 0; \ +}) + +#endif /* __XEN__ */ + +#include + +/* + * Copy a single cpuid_leaf into a provided xen_cpuid_leaf_t buffer, + * performing boundary checking against the buffer size. + */ +static int copy_leaf_to_buffer(uint32_t leaf, uint32_t subleaf, + const struct cpuid_leaf *data, + cpuid_leaf_buffer_t leaves, + uint32_t *curr_entry, const uint32_t nr_entries) +{ + const xen_cpuid_leaf_t val = { + leaf, subleaf, data->a, data->b, data->c, data->d, + }; + + if ( *curr_entry == nr_entries ) + return -ENOBUFS; + + if ( copy_to_buffer_offset(leaves, *curr_entry, &val, 1) ) + return -EFAULT; + + ++*curr_entry; + + return 0; +} + +int x86_cpuid_copy_to_buffer(const struct cpu_policy *p, + cpuid_leaf_buffer_t leaves, uint32_t *nr_entries_p) +{ + const uint32_t nr_entries = *nr_entries_p; + uint32_t curr_entry = 0, leaf, subleaf; + +#define COPY_LEAF(l, s, data) \ + ({ \ + int ret; \ + \ + if ( (ret = copy_leaf_to_buffer( \ + l, s, data, leaves, &curr_entry, nr_entries)) ) \ + return ret; \ + }) + + /* Basic leaves. */ + for ( leaf = 0; leaf <= MIN(p->basic.max_leaf, + ARRAY_SIZE(p->basic.raw) - 1); ++leaf ) + { + switch ( leaf ) + { + case 0x4: + for ( subleaf = 0; subleaf < ARRAY_SIZE(p->cache.raw); ++subleaf ) + { + COPY_LEAF(leaf, subleaf, &p->cache.raw[subleaf]); + + if ( p->cache.subleaf[subleaf].type == 0 ) + break; + } + break; + + case 0x7: + for ( subleaf = 0; + subleaf <= MIN(p->feat.max_subleaf, + ARRAY_SIZE(p->feat.raw) - 1); ++subleaf ) + COPY_LEAF(leaf, subleaf, &p->feat.raw[subleaf]); + break; + + case 0xb: + for ( subleaf = 0; subleaf < ARRAY_SIZE(p->topo.raw); ++subleaf ) + { + COPY_LEAF(leaf, subleaf, &p->topo.raw[subleaf]); + + if ( p->topo.subleaf[subleaf].type == 0 ) + break; + } + break; + + case 0xd: + { + uint64_t xstates = cpu_policy_xstates(p); + + COPY_LEAF(leaf, 0, &p->xstate.raw[0]); + COPY_LEAF(leaf, 1, &p->xstate.raw[1]); + + for ( xstates >>= 2, subleaf = 2; + xstates && subleaf < ARRAY_SIZE(p->xstate.raw); + xstates >>= 1, ++subleaf ) + COPY_LEAF(leaf, subleaf, &p->xstate.raw[subleaf]); + break; + } + + default: + COPY_LEAF(leaf, XEN_CPUID_NO_SUBLEAF, &p->basic.raw[leaf]); + break; + } + } + + /* TODO: Port Xen and Viridian leaves to the new CPUID infrastructure. */ + COPY_LEAF(0x40000000, XEN_CPUID_NO_SUBLEAF, + &(struct cpuid_leaf){ p->hv_limit }); + COPY_LEAF(0x40000100, XEN_CPUID_NO_SUBLEAF, + &(struct cpuid_leaf){ p->hv2_limit }); + + /* Extended leaves. */ + for ( leaf = 0; leaf <= MIN(p->extd.max_leaf & 0xffffUL, + ARRAY_SIZE(p->extd.raw) - 1); ++leaf ) + COPY_LEAF(0x80000000U | leaf, XEN_CPUID_NO_SUBLEAF, &p->extd.raw[leaf]); + +#undef COPY_LEAF + + *nr_entries_p = curr_entry; + + return 0; +} + +/* + * Copy a single MSR into the provided msr_entry_buffer_t buffer, performing a + * boundary check against the buffer size. + */ +static int copy_msr_to_buffer(uint32_t idx, uint64_t val, + msr_entry_buffer_t msrs, + uint32_t *curr_entry, const uint32_t nr_entries) +{ + const xen_msr_entry_t ent = { .idx = idx, .val = val }; + + if ( *curr_entry == nr_entries ) + return -ENOBUFS; + + if ( copy_to_buffer_offset(msrs, *curr_entry, &ent, 1) ) + return -EFAULT; + + ++*curr_entry; + + return 0; +} + +int x86_msr_copy_to_buffer(const struct cpu_policy *p, + msr_entry_buffer_t msrs, uint32_t *nr_entries_p) +{ + const uint32_t nr_entries = *nr_entries_p; + uint32_t curr_entry = 0; + +#define COPY_MSR(idx, val) \ + ({ \ + int ret; \ + \ + if ( (ret = copy_msr_to_buffer( \ + idx, val, msrs, &curr_entry, nr_entries)) ) \ + return ret; \ + }) + + COPY_MSR(MSR_INTEL_PLATFORM_INFO, p->platform_info.raw); + COPY_MSR(MSR_ARCH_CAPABILITIES, p->arch_caps.raw); + +#undef COPY_MSR + + *nr_entries_p = curr_entry; + + return 0; +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/x86/lib/cpu-policy/cpuid.c b/xen/arch/x86/lib/cpu-policy/cpuid.c index 6298d051f2a6..3162e795bc21 100644 --- a/xen/arch/x86/lib/cpu-policy/cpuid.c +++ b/xen/arch/x86/lib/cpu-policy/cpuid.c @@ -322,232 +322,6 @@ const uint32_t *x86_cpu_policy_lookup_deep_deps(uint32_t feature) return NULL; } -/* - * Copy a single cpuid_leaf into a provided xen_cpuid_leaf_t buffer, - * performing boundary checking against the buffer size. - */ -static int copy_leaf_to_buffer(uint32_t leaf, uint32_t subleaf, - const struct cpuid_leaf *data, - cpuid_leaf_buffer_t leaves, - uint32_t *curr_entry, const uint32_t nr_entries) -{ - const xen_cpuid_leaf_t val = { - leaf, subleaf, data->a, data->b, data->c, data->d, - }; - - if ( *curr_entry == nr_entries ) - return -ENOBUFS; - - if ( copy_to_buffer_offset(leaves, *curr_entry, &val, 1) ) - return -EFAULT; - - ++*curr_entry; - - return 0; -} - -int x86_cpuid_copy_to_buffer(const struct cpu_policy *p, - cpuid_leaf_buffer_t leaves, uint32_t *nr_entries_p) -{ - const uint32_t nr_entries = *nr_entries_p; - uint32_t curr_entry = 0, leaf, subleaf; - -#define COPY_LEAF(l, s, data) \ - ({ \ - int ret; \ - \ - if ( (ret = copy_leaf_to_buffer( \ - l, s, data, leaves, &curr_entry, nr_entries)) ) \ - return ret; \ - }) - - /* Basic leaves. */ - for ( leaf = 0; leaf <= MIN(p->basic.max_leaf, - ARRAY_SIZE(p->basic.raw) - 1); ++leaf ) - { - switch ( leaf ) - { - case 0x4: - for ( subleaf = 0; subleaf < ARRAY_SIZE(p->cache.raw); ++subleaf ) - { - COPY_LEAF(leaf, subleaf, &p->cache.raw[subleaf]); - - if ( p->cache.subleaf[subleaf].type == 0 ) - break; - } - break; - - case 0x7: - for ( subleaf = 0; - subleaf <= MIN(p->feat.max_subleaf, - ARRAY_SIZE(p->feat.raw) - 1); ++subleaf ) - COPY_LEAF(leaf, subleaf, &p->feat.raw[subleaf]); - break; - - case 0xb: - for ( subleaf = 0; subleaf < ARRAY_SIZE(p->topo.raw); ++subleaf ) - { - COPY_LEAF(leaf, subleaf, &p->topo.raw[subleaf]); - - if ( p->topo.subleaf[subleaf].type == 0 ) - break; - } - break; - - case 0xd: - { - uint64_t xstates = cpu_policy_xstates(p); - - COPY_LEAF(leaf, 0, &p->xstate.raw[0]); - COPY_LEAF(leaf, 1, &p->xstate.raw[1]); - - for ( xstates >>= 2, subleaf = 2; - xstates && subleaf < ARRAY_SIZE(p->xstate.raw); - xstates >>= 1, ++subleaf ) - COPY_LEAF(leaf, subleaf, &p->xstate.raw[subleaf]); - break; - } - - default: - COPY_LEAF(leaf, XEN_CPUID_NO_SUBLEAF, &p->basic.raw[leaf]); - break; - } - } - - /* TODO: Port Xen and Viridian leaves to the new CPUID infrastructure. */ - COPY_LEAF(0x40000000, XEN_CPUID_NO_SUBLEAF, - &(struct cpuid_leaf){ p->hv_limit }); - COPY_LEAF(0x40000100, XEN_CPUID_NO_SUBLEAF, - &(struct cpuid_leaf){ p->hv2_limit }); - - /* Extended leaves. */ - for ( leaf = 0; leaf <= MIN(p->extd.max_leaf & 0xffffUL, - ARRAY_SIZE(p->extd.raw) - 1); ++leaf ) - COPY_LEAF(0x80000000U | leaf, XEN_CPUID_NO_SUBLEAF, &p->extd.raw[leaf]); - -#undef COPY_LEAF - - *nr_entries_p = curr_entry; - - return 0; -} - -int x86_cpuid_copy_from_buffer(struct cpu_policy *p, - const cpuid_leaf_buffer_t leaves, - uint32_t nr_entries, uint32_t *err_leaf, - uint32_t *err_subleaf) -{ - unsigned int i; - xen_cpuid_leaf_t data; - - if ( err_leaf ) - *err_leaf = -1; - if ( err_subleaf ) - *err_subleaf = -1; - - /* - * A well formed caller is expected to pass an array with leaves in order, - * and without any repetitions. However, due to per-vendor differences, - * and in the case of upgrade or levelled scenarios, we typically expect - * fewer than MAX leaves to be passed. - * - * Detecting repeated entries is prohibitively complicated, so we don't - * bother. That said, one way or another if more than MAX leaves are - * passed, something is wrong. - */ - if ( nr_entries > CPUID_MAX_SERIALISED_LEAVES ) - return -E2BIG; - - for ( i = 0; i < nr_entries; ++i ) - { - struct cpuid_leaf l; - - if ( copy_from_buffer_offset(&data, leaves, i, 1) ) - return -EFAULT; - - l = (struct cpuid_leaf){ data.a, data.b, data.c, data.d }; - - switch ( data.leaf ) - { - case 0 ... ARRAY_SIZE(p->basic.raw) - 1: - switch ( data.leaf ) - { - case 0x4: - if ( data.subleaf >= ARRAY_SIZE(p->cache.raw) ) - goto out_of_range; - - array_access_nospec(p->cache.raw, data.subleaf) = l; - break; - - case 0x7: - if ( data.subleaf >= ARRAY_SIZE(p->feat.raw) ) - goto out_of_range; - - array_access_nospec(p->feat.raw, data.subleaf) = l; - break; - - case 0xb: - if ( data.subleaf >= ARRAY_SIZE(p->topo.raw) ) - goto out_of_range; - - array_access_nospec(p->topo.raw, data.subleaf) = l; - break; - - case 0xd: - if ( data.subleaf >= ARRAY_SIZE(p->xstate.raw) ) - goto out_of_range; - - array_access_nospec(p->xstate.raw, data.subleaf) = l; - break; - - default: - if ( data.subleaf != XEN_CPUID_NO_SUBLEAF ) - goto out_of_range; - - array_access_nospec(p->basic.raw, data.leaf) = l; - break; - } - break; - - case 0x40000000: - if ( data.subleaf != XEN_CPUID_NO_SUBLEAF ) - goto out_of_range; - - p->hv_limit = l.a; - break; - - case 0x40000100: - if ( data.subleaf != XEN_CPUID_NO_SUBLEAF ) - goto out_of_range; - - p->hv2_limit = l.a; - break; - - case 0x80000000U ... 0x80000000U + ARRAY_SIZE(p->extd.raw) - 1: - if ( data.subleaf != XEN_CPUID_NO_SUBLEAF ) - goto out_of_range; - - array_access_nospec(p->extd.raw, data.leaf & 0xffff) = l; - break; - - default: - goto out_of_range; - } - } - - x86_cpu_policy_recalc_synth(p); - - return 0; - - out_of_range: - if ( err_leaf ) - *err_leaf = data.leaf; - if ( err_subleaf ) - *err_subleaf = data.subleaf; - - return -ERANGE; -} - /* * Local variables: * mode: C diff --git a/xen/arch/x86/lib/cpu-policy/msr.c b/xen/arch/x86/lib/cpu-policy/msr.c deleted file mode 100644 index e04b9ca01302..000000000000 --- a/xen/arch/x86/lib/cpu-policy/msr.c +++ /dev/null @@ -1,130 +0,0 @@ -#include "private.h" - -#include - -/* - * Copy a single MSR into the provided msr_entry_buffer_t buffer, performing a - * boundary check against the buffer size. - */ -static int copy_msr_to_buffer(uint32_t idx, uint64_t val, - msr_entry_buffer_t msrs, - uint32_t *curr_entry, const uint32_t nr_entries) -{ - const xen_msr_entry_t ent = { .idx = idx, .val = val }; - - if ( *curr_entry == nr_entries ) - return -ENOBUFS; - - if ( copy_to_buffer_offset(msrs, *curr_entry, &ent, 1) ) - return -EFAULT; - - ++*curr_entry; - - return 0; -} - -int x86_msr_copy_to_buffer(const struct cpu_policy *p, - msr_entry_buffer_t msrs, uint32_t *nr_entries_p) -{ - const uint32_t nr_entries = *nr_entries_p; - uint32_t curr_entry = 0; - -#define COPY_MSR(idx, val) \ - ({ \ - int ret; \ - \ - if ( (ret = copy_msr_to_buffer( \ - idx, val, msrs, &curr_entry, nr_entries)) ) \ - return ret; \ - }) - - COPY_MSR(MSR_INTEL_PLATFORM_INFO, p->platform_info.raw); - COPY_MSR(MSR_ARCH_CAPABILITIES, p->arch_caps.raw); - -#undef COPY_MSR - - *nr_entries_p = curr_entry; - - return 0; -} - -int x86_msr_copy_from_buffer(struct cpu_policy *p, - const msr_entry_buffer_t msrs, uint32_t nr_entries, - uint32_t *err_msr) -{ - unsigned int i; - xen_msr_entry_t data; - int rc; - - if ( err_msr ) - *err_msr = -1; - - /* - * A well formed caller is expected to pass an array with entries in - * order, and without any repetitions. However, due to per-vendor - * differences, and in the case of upgrade or levelled scenarios, we - * typically expect fewer than MAX entries to be passed. - * - * Detecting repeated entries is prohibitively complicated, so we don't - * bother. That said, one way or another if more than MAX entries are - * passed, something is wrong. - */ - if ( nr_entries > MSR_MAX_SERIALISED_ENTRIES ) - return -E2BIG; - - for ( i = 0; i < nr_entries; i++ ) - { - if ( copy_from_buffer_offset(&data, msrs, i, 1) ) - return -EFAULT; - - if ( data.flags ) /* .flags MBZ */ - { - rc = -EINVAL; - goto err; - } - - switch ( data.idx ) - { - /* - * Assign data.val to p->field, checking for truncation if the - * backing storage for field is smaller than uint64_t - */ -#define ASSIGN(field) \ -({ \ - if ( (typeof(p->field))data.val != data.val ) \ - { \ - rc = -EOVERFLOW; \ - goto err; \ - } \ - p->field = data.val; \ -}) - - case MSR_INTEL_PLATFORM_INFO: ASSIGN(platform_info.raw); break; - case MSR_ARCH_CAPABILITIES: ASSIGN(arch_caps.raw); break; - -#undef ASSIGN - - default: - rc = -ERANGE; - goto err; - } - } - - return 0; - - err: - if ( err_msr ) - *err_msr = data.idx; - - return rc; -} - -/* - * Local variables: - * mode: C - * c-file-style: "BSD" - * c-basic-offset: 4 - * tab-width: 4 - * indent-tabs-mode: nil - * End: - */ diff --git a/xen/arch/x86/lib/cpu-policy/private.h b/xen/arch/x86/lib/cpu-policy/private.h index aedd8e482121..57f254c3e917 100644 --- a/xen/arch/x86/lib/cpu-policy/private.h +++ b/xen/arch/x86/lib/cpu-policy/private.h @@ -12,9 +12,6 @@ #include -#define copy_to_buffer_offset copy_to_guest_offset -#define copy_from_buffer_offset copy_from_guest_offset - #else #include @@ -35,34 +32,6 @@ static inline bool test_bit(unsigned int bit, const void *vaddr) return addr[bit / 8] & (1u << (bit % 8)); } -#define array_access_nospec(a, i) (a)[(i)] - -/* memcpy(), but with copy_to_guest_offset()'s API. */ -#define copy_to_buffer_offset(dst, index, src, nr) \ -({ \ - const typeof(*(src)) *src_ = (src); \ - typeof(*(dst)) *dst_ = (dst); \ - typeof(index) index_ = (index); \ - typeof(nr) nr_ = (nr), i_; \ - \ - for ( i_ = 0; i_ < nr_; i_++ ) \ - dst_[index_ + i_] = src_[i_]; \ - 0; \ -}) - -/* memcpy(), but with copy_from_guest_offset()'s API. */ -#define copy_from_buffer_offset(dst, src, index, nr) \ -({ \ - const typeof(*(src)) *src_ = (src); \ - typeof(*(dst)) *dst_ = (dst); \ - typeof(index) index_ = (index); \ - typeof(nr) nr_ = (nr), i_; \ - \ - for ( i_ = 0; i_ < nr_; i_++ ) \ - dst_[i_] = src_[index_ + i_]; \ - 0; \ -}) - #endif /* __XEN__ */ #endif /* XEN_LIB_X86_PRIVATE_H */ From xen-devel-bounces@lists.xenproject.org Wed Jan 07 14:27:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 14:27:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196773.1514499 (Exim 4.92) (envelope-from ) id 1vdUVS-0006h3-P2; Wed, 07 Jan 2026 14:27:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196773.1514499; Wed, 07 Jan 2026 14:27:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdUVS-0006gw-LU; Wed, 07 Jan 2026 14:27:26 +0000 Received: by outflank-mailman (input) for mailman id 1196773; Wed, 07 Jan 2026 14:27:25 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdUVR-0006gl-Kr for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 14:27:25 +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 fbe72036-ebd4-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 15:27:24 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by IA1PR03MB8214.namprd03.prod.outlook.com (2603:10b6:208:5d6::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.5; Wed, 7 Jan 2026 14:27:21 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.002; Wed, 7 Jan 2026 14: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" X-Inumbo-ID: fbe72036-ebd4-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kG1aq1VUX7OkPVFF2mPLkMCrXJs0i8MJMCvPqvmNTGmlHGRS+AoeWs5NFtpMeLQrrnZJXnZ/GGikJxtU98ZM7ciZpjlL2nFiUwjORhyqYn539UUWGQfvhmrGC7a5pZWcFK6ATz4aUQ2NAk4XOEgZTDW5ggjzSPcrLOKW7quO6e4LJVewrGe5LmbnmlkC/fkNZ6/PX/nu/D1WmU3wAxewgPW3vnJXwLivsG1f66I0R6QggIheUTTlUSGTQvWt5fe8JwChjsSVLneEzQzEVomNwdANP8cnvmqD3E8fc9N60fVZkyJBscOlju+w1Im3zMmkyM2lewBVVHIPZ8klcjgjXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vVMmgP/29r9K1JzbcGoAGvMJ+s5vsTxunlavN4xtz0U=; b=bmBTiMtOwFg8H7QB5XrWMkqHrmgJNdqZTDld2WsEE4Nm76r4w77HVvLRiZQ2Dp3rRmSa2BVEvo+Mr+ekGlgJ9iRgiSrpQMH1KdsJqp30Dze9D7NFezbX8/NNOs4ZpwDhkWN1Kvbb36K8qswvuipGqtdGddWNvVdorxOfHDSWY5fq9Cr7ZDevrWB7mNnb8YTYRL7KRnZzmDTRBPh4lrtrahElC9759ojpG4rh6M+MnCLFjXminoOkuvuQCtMH9V0o/u9WRCL6xpXRlBQ3DKhcxDD//d5tM0H+Vear2WeID+wGPhFnUxOD/y/fuNtaSO9RvgqHjEDB01ldSek1Uc6fCg== 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=vVMmgP/29r9K1JzbcGoAGvMJ+s5vsTxunlavN4xtz0U=; b=o5Z6wFtQJ+RAQ4uONuAzHXUm/Um69TSkUVUrDpGfQIEGMxf+R+bTYk6YwfOSaA41wGusGEuqqX5nOv5FIkHyKIfDsnN9PT7oqscf6OhCBAs93mlh5eRHHXVfjlAYwtR9oqTU0zfz2XIHQdVGSQ91Lg3WS0JPVgBM5eyjl+yXqCE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 7 Jan 2026 15:27:16 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH v2 1/2] xen/mm: move adjustment of claimed pages counters on allocation Message-ID: References: <20251224194035.60173-1-roger.pau@citrix.com> <20251224194035.60173-2-roger.pau@citrix.com> <6ba614c0-740f-4c39-b81d-990a1d0add0a@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6ba614c0-740f-4c39-b81d-990a1d0add0a@suse.com> X-ClientProxiedBy: PR3P189CA0011.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:52::16) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|IA1PR03MB8214:EE_ X-MS-Office365-Filtering-Correlation-Id: 60685d40-ccc8-43f3-57f2-08de4df8de6b 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?M05JVDBhVTB4UUdiemg4N0xRbk81aTB3R01na0c5RXFtcDByL1hYemxBVEs2?= =?utf-8?B?SXE4SHFsK1hjN2FaTEZ0c0ZncldjK2NkN1VtRVZvQXE3QkROdk1DcVZoSXF2?= =?utf-8?B?YlRFa2pZMStCYnVEQ0JaQWkrZWNaZWdwd0tBWThtRTNkbFBXY2dtL3YrREZz?= =?utf-8?B?SEk1MWR5SWxWd0tRbDlYaGpLbnppNjk2ZXIwb2s1eHZMZlk2QVNGY3JyaU5w?= =?utf-8?B?M2ZXNXFFZkYvSVFQOFdDeDlpWnhWNkhVNDVPZlIxNVlrU2hJZjUraDBvQ013?= =?utf-8?B?ZVB4S0RrVkcyQTZLYWpJR3ZNVGlLOXBvN1JadjE5K1FPT0NXaldPMkVkRHZD?= =?utf-8?B?Q0tlR1Q1K0xTSzgraUFYcXR1US9NQmt6ajdXd0FrdVdrMVplcEJGLzVEdmhr?= =?utf-8?B?c0RiTzYxWk15L3dzek9QWjJ6dlc5c2loMm9DVHNQNUM4WHdPV2xuNGp2SEdE?= =?utf-8?B?VU5qNUhYUWdUdm5NNXJTM0FCZURYRThHa1FQYjVSNEtvcW82ZGQvSGFYRnl2?= =?utf-8?B?Z2c2akhnTEdOWG5QekoySkJEZmNRZlFSc1VMelVLazI3Y3UvZ3VpZ1F0TzNv?= =?utf-8?B?SFBldVU5S1VNMWVBN094alpTL1BwV1Z4ZVlsb0dGMCt4YmxFcEJCOURMTTE1?= =?utf-8?B?SE13OXBBM0tIcUxvTCtROWY1OXpIQ2pOZHBjUTFtaTZSMkZ2WkdVN1EvWGZO?= =?utf-8?B?eGNzVjRwQXREbG9xNDhPemZDa2NFYnY3ajI4dXllR1d0dVVNSDFiTXVMR1pL?= =?utf-8?B?SmtvV3lMRnNSWUg4NkZGZWw2RWVOYXRiTGUvU2licFcrOXBuTmxZbndwUWtv?= =?utf-8?B?K3hLTHlUSDcyOXl5cHY3RkY2ODhiZEZnRUVmS2hObmVoOUkrNlBuVGorNnhF?= =?utf-8?B?Z2JDTHBXdHRQRDdEdGd6MloyTWV6Wk95MS9HUldiMkxCcVVTWG5ubTVFR085?= =?utf-8?B?eUw5UjN0dFl5RmZSaXdkWUEvV3ZZOVVRTmhWemNHV2RYWDA1aS9RTkdaVHFn?= =?utf-8?B?amJEYU1ldlYyRnFYazN3Mm9EeFYrNUVoSHlTbzBoOTFuOUs2OFdkUmFUeHN0?= =?utf-8?B?TjNNWVRENzMrS3FzRUlLQjRsY081ZkhlQ3FhcW1RclNxS0RDcmY5dEVPS3BK?= =?utf-8?B?VlVjSXJhT3F0NVJZTVY1ZEQ3dTM4R1RPTnpaYTMxVU8xblREeFFyR1J6NHhl?= =?utf-8?B?ayt5eE1RZ21hSi8xQ3hpclI5dkdpV2VYeGNodHI3YytuYmhuYWZXNzNXV3hx?= =?utf-8?B?YzlWVFF6OThzK0pqN1RpTDdQTDhJbFBNeVZmVFBrMldRT1R6cEl1OGdHTHg0?= =?utf-8?B?N2RVUWFxamtScHViQ1kzUTdETTdBSUc0UXlzbEVQaVJCQ3RmWG5wWGZhQVlj?= =?utf-8?B?bWxnWGU3dkpEL09pWkFlK0N0OEU0d2c1NXFMMUlnSHFQMnVkNFhpekhLTlk2?= =?utf-8?B?ZHEwRUl0Y29zdFVEUGJkdUZMcUlCelA2U3RmbmFuc2NnUk5RSXprSm9tRWNB?= =?utf-8?B?clU2S3FxRzdJWis4M1N4Yk92ejg2eklOL0lQKzB3UzI3b0JrVFhMOUFMMUJF?= =?utf-8?B?aHdHZ0QzVHY2Y25iK1RBTmFOd25SelpqcE5Mc0M5TGo2azlOOXlxdFh4RFpM?= =?utf-8?B?U3dKaWdYRVpKbTdBV0txdWpsTWo4OUQwWnVuRkJXY3lNR29qeFJpQVNJem1l?= =?utf-8?B?c3IwdytmZWlzNnV5YmYxc2xWM2xEcnRiUDFCVHpwVU1jOTZXUlFOVlZ4ZG1r?= =?utf-8?B?K1E5MU56U2tBL0Yxa0Y0c2duNnVoTU5PQXhub2xrT0N4YVd4ZEZ1dmdlSk5F?= =?utf-8?B?R0FETWMzVDN2VXZPcnlYZ3ZtYTRhNkdqNnM4cVl5VkV5ZDRQUllac1ExWmMr?= =?utf-8?B?NVIrTUUzMEVQa08zbjZFVkc2N1BobW5DYjkxTUlmTnNvWHlTSHU0elZSV0hX?= =?utf-8?B?dUVHY0NaSGNNZ0RwMjRUbGp3ZFpZSW9wMnBod1dWSlVXYXlmcitPT2hMSDBL?= =?utf-8?B?enEvMzdMK2xnPT0=?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Z3Vqa2NjTVZLbWx6aXhRNVlObkR1L2wrWld5Nll0Z0NnRXlReTlCS0Iza3E1?= =?utf-8?B?cUVnNVZZYXZBRVpFT0ZKY0lLM3EyekVZeW8waHU3TTBZNGF1bjBtYTFOK0ZK?= =?utf-8?B?VU9xcCtYUytqK3RjK2t0cHFFZTV6dFlNazMyNFBTbEduOU9Ja1RRMmhIdncy?= =?utf-8?B?WWlZOE5odGQ3aEtsVWxKZEFlbnpBZGhyZEJSRVJGdVZCR2RkM2tEdGRQVHdq?= =?utf-8?B?UFl4UENmNk9weS93SU51VjNUTDVKK2ZQeXNQbkF6VFV6azBBcGwvdWFPcVpK?= =?utf-8?B?Yi9FTDQrcmlwNXZXNEdDcVlIWVozdElPSytqZTAyQ2VUV2NtdE84SWswbkpS?= =?utf-8?B?ZG1NZGkwZmxKdmxkdmtZWGdYS2hGWklGcVV5cVh1Q1FnTXFpUTlubm05Z2k5?= =?utf-8?B?cWI0Q1A2YUVjSlUyVUNvUFByenBDUE1ZUWs0OGJvN0RENkp5RnJ4MVdlQUt0?= =?utf-8?B?dkROQ0Z6SUttM21sclRSL3RicUt1UUZydld0SDVtMWpCRytVZWNoN3Q2L0xt?= =?utf-8?B?MUs3MmxvNE9CVDNmTElYcHNjcnJCSEFwSHJpYXA1RURqN3pCMFkvamRJUExz?= =?utf-8?B?WWtXRHpBSGFhMW0wb0tkakJFbVNJSzdTN0hUU0R1WUZtc3FCc29TRmI1VmQ4?= =?utf-8?B?cy82UGdyUXlwWFBlckhHNDVxQ0pOU29YbzZkVmdqaW42eGY2bWFqRVcvNUFY?= =?utf-8?B?SHJtaVpPbXFxOHJtK0VYRHhIUmRpUXRLRkpRSXF6TnVTYk1PVXNZNEkrQ3gz?= =?utf-8?B?emFZT2NnbHloeFpMa3Y2U1MvNUtJaVBqdjZoUWNtd2FCdjF2QUhiWmJBTlcr?= =?utf-8?B?aW9kWHJsOStpeVk3MUkveGdaUzNxWnh6NmxhZUFRUm1wckF3Z3dIbjFXZm1u?= =?utf-8?B?TjVQU2JtMkFuQTM5UFhMeEl0QTA0V3hheE9CSHBKME9YVC91OVJIb2hRMjNJ?= =?utf-8?B?c21YcGFpeWRuUXpzREZEZXRZMEdvRnN4Vms0aGNqMFNTU3NQWVpRYzZJdFYw?= =?utf-8?B?VUlma3FEVUk4eTBrSmU0S3RFUnBYSGUyVURBK2VQUWJ4VHJadXk4Rm5qN3Jo?= =?utf-8?B?WU4xQm5IN0ZlTVNHQi92UHBDT2VrZjBUM2pQbVoyNmVWY2dUSzVIN1F0RnhV?= =?utf-8?B?WFptZjNtMERKWERhRlhHLy9QOGFROGppd2NBNzYvMHA2d0NkU05ObWh2cHVY?= =?utf-8?B?TDVlai9wenpFVzhuR3NHclc1ZnhnUjVvZHkzWVdMQTdjcmZiYmRxblhSRUlF?= =?utf-8?B?TWh6NEdNa1hRREszTlVvVnBzajJwRHUwRFFWNEhQSkUveXl5cE1BSUE1dWJL?= =?utf-8?B?MFZCTXZYamZZSy9BNGtKNjlWQU5qcmlhUml3WEtTbEtBaVFWWkVqL2UxMWph?= =?utf-8?B?QzdpUzhRUjZocHNORFpZTDh2bEwrU0ZWU3dudUlSeHZnVWsrcEpJZzdOQmxX?= =?utf-8?B?RlpmbjRzMzlvckZBSGZEcHpsYWFFQUtUc05IOU1UWDNXMEFhVFdTdmtEMVo5?= =?utf-8?B?UVNJTWtXdU9Zc3hHRlBDVVNwcUhMTEV6Qk85dTlBdlZSWUpZMHAxVkVwM2xZ?= =?utf-8?B?RXpkVDVPRTRIK1JHMWV5bStic0FsVlJDMmNmS3piaXY3THNMMjFhNC96b1NH?= =?utf-8?B?MEk0QndvVzBVc1A0MWhEVzhOM0s5WDhRR2t1Y0xYTUMxOEN4MHVSQlNqYzNr?= =?utf-8?B?QWF4UUVJYUtMKzNMeGJOMVNkN2dKYTVtQm9zY0EzRnJWR2FYL2xsZkF5QzB1?= =?utf-8?B?L1h1c3o5MDF6a2hWNFlhcDJZekV3Y2FCTXZJVTFzeC9QeS9ybG9KQlNjaUFX?= =?utf-8?B?NFQ0bjBXNytjMXIzaFBiMlY1RGNmTWNhNHdpTmpJOC9KZ2tQYnNLOXFjYXVv?= =?utf-8?B?L1huMStlYjJEWjd6aTZsZEFXdWVxN0d3dmRRR0l6d0lJR2QzTUxTRC81T3dJ?= =?utf-8?B?U3Y5bVJwMmlQWWRmRS9odWpTOSsxRjRsUk5GNjg0cGVBQTErRDRPVU5Uajd4?= =?utf-8?B?OU1lQ3FoZzZzY3piRWVqWHgvcE5wTDk3ZVl5b2FJVjZiTXpJWTZHSDNHZjk4?= =?utf-8?B?cWltcTNONk1Ca1U4NFFJSE8wSGRiWGtmb2ZGRS9Ebm00dVM2Snc4Z2Fxd2JI?= =?utf-8?B?VlViNzhKTzRQZU5lc3ZwaVJaOFY4WTVCTktkVjJkTTZ3MTlxNSttaS81SGR1?= =?utf-8?B?ZEhsV05EYklvVmRPMk5mejNocXY1bTVLMFNjdmxCTkxQdUJreFlNR0t3V29q?= =?utf-8?B?YlRPb0g0WXNuaHZQd0RwRmY1VHA2Rm5sdmp6QnIyRnZmYmNrZEZ4bDlGQTJP?= =?utf-8?B?ZVJrTC9WdGFGZUNCOHhxWUFPeGIzbTlVWWFGYW9iaUExbWE2dTRmUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 60685d40-ccc8-43f3-57f2-08de4df8de6b X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2026 14:27:21.3579 (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: DOomhJodbFkkoOzIczGODQKU4iT/kZjjFwTlOSaEmI8Qtd/uYurMB1WiH5chagulieXaQZJbqrVLmju+HTX7Cw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR03MB8214 On Mon, Dec 29, 2025 at 09:44:49AM +0100, Jan Beulich wrote: > On 24.12.2025 23:31, Andrew Cooper wrote: > > On 24/12/2025 7:40 pm, Roger Pau Monne wrote: > >> The current logic splits the update of the amount of available memory in > >> the system (total_avail_pages) and pending claims into two separately > >> locked regions. This leads to a window between counters adjustments where > >> the result of total_avail_pages - outstanding_claims doesn't reflect the > >> real amount of free memory available, and can return a negative value due > >> to total_avail_pages having been updated ahead of outstanding_claims. > >> > >> Fix by adjusting outstanding_claims and d->outstanding_pages in the same > >> place where total_avail_pages is updated. Note that accesses to > >> d->outstanding_pages is protected by the global heap_lock, just like > >> total_avail_pages or outstanding_claims. Add a comment to the field > >> declaration, and also adjust the comment at the top of > >> domain_set_outstanding_pages() to be clearer in that regard. > >> > >> Finally, due to claims being adjusted ahead of pages having been assigned > >> to the domain, add logic to re-gain the claim in case assign_page() fails. > >> Otherwise the page is freed and the claimed amount would be lost. > >> > >> Fixes: 65c9792df600 ("mmu: Introduce XENMEM_claim_pages (subop of memory ops)") > >> Signed-off-by: Roger Pau Monné > >> --- > >> Changes since v1: > >> - Regain the claim if allocated page cannot be assigned to the domain. > >> - Adjust comments regarding d->outstanding_pages being protected by the > >> heap_lock (instead of the d->page_alloc_lock). > > > > This is a complicated patch, owing to the churn from adding extra > > parameters. > > > > I've had a go splitting this patch in half.  First to adjust the > > parameters, and second the bugfix.  > > https://gitlab.com/xen-project/hardware/xen-staging/-/commits/andrew/roger-claims > > > > I think the result is nicer to follow.  Thoughts? > > Question (from the unfinished v1 thread) being whether we actually need the > restoration, given Roger's analysis of the affected failure cases. Let's leave it out then. It's certainly possible to add the claimed amount back on failure, but given the intended usage of claims and the failures cases of assign_pages() I don't think it's worth doing it now. It adds complexity for no real value. A domain that fails in assing_pages() during domain creation physmap population is doomed to be destroyed anyway, and hence possibly dropping (part of) the claim is not relevant. I will send a new version of the series with the approach used on v1. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 07 15:21:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 15:21:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196797.1514509 (Exim 4.92) (envelope-from ) id 1vdVLy-0005rj-FP; Wed, 07 Jan 2026 15:21:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196797.1514509; Wed, 07 Jan 2026 15:21:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdVLy-0005rc-CN; Wed, 07 Jan 2026 15:21:42 +0000 Received: by outflank-mailman (input) for mailman id 1196797; Wed, 07 Jan 2026 15: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 1vdVLx-0005rW-C1 for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 15:21:41 +0000 Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [2a00:1450:4864:20::433]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8cb19851-ebdc-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 16:21:33 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-43246af170aso550931f8f.0 for ; Wed, 07 Jan 2026 07:21:33 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5df90dsm10442080f8f.20.2026.01.07.07.21.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jan 2026 07:21:32 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8cb19851-ebdc-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767799293; x=1768404093; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=ObtFpf/ESWwhgMFs0iRTF/460Gv7mXQWIOwe6+TXYjM=; b=V3PvMqHVrb5LErqjPrPSSuWHEKSdq+Ja5SmtrwbietkHxNwprJPANEQaEjT5Q//64N PGEUalJCEmU9i3M9yEyZ2tCWgy1MFtIM8eiM4tvdqxWDTdH1ztZISkQYjjDsnS0TYfS3 h29ryYoV9E6Uoll+yRABkFbcG5lawd1fDAtyINfAPMSMIJfaDF4x564Pe8/e4v8Ofyhy 4GrZQ6YH1uODB7FwqFEXxE7rBvOMn3CUkGQKjFx1SfUEoJgpv9gFCkdQPt/zpsvTG74o m5TIWy697ZisZ4txvucRr47OPEX5CLm9vGSlNUCUgRwFUCMLwVeWAJaqC+uvzOBD261m LIHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767799293; x=1768404093; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ObtFpf/ESWwhgMFs0iRTF/460Gv7mXQWIOwe6+TXYjM=; b=D6qazMWNt3sac1n2QNnRZv/KKJ1N75vMP43xLm+GPfeUg+JULfMdVB9BX6fJ+W1xfO EQ5B3qPjjLmSCm4c85VdwV3hvxC9QyEbCdkyO0bUY9/p0ixPk/tpa1VG1InB30a+5IYJ SNr0BnbiiWj2ZhDFIZrFwOVr1uQr3HCRXXi166kk8lskmYC9heFi6jeKGBQdivw89UfR ta5q5EtY4rJmcv91ZLYVu2X0DNIf4vARAG9gkzuE7AFvp+ebnw+BZRhadj7XnvjYnjKi 2eZDVv7CYHzuSWnXLWN2g3xfbuCQ97mI3EZIYcv2UrWAlO17uL7czKR493uVH/GZePHk EhrA== X-Forwarded-Encrypted: i=1; AJvYcCUkNRMzn/zYbp5+qdcx5ziIEUmD+8X/rTG4+B+EyxaFfBfxgF6apSOugnzoQNdmq6CenU57P2hc3iI=@lists.xenproject.org X-Gm-Message-State: AOJu0YyNh9+ZSBRWc2ksS+XhjMMHFMRanzdhr/6HsTyy0j85PaTyBDGE rYxSuLbObcd3A7IpU0jTgmmJwdbfaGtHtVlsJmTLMcBw2MMx3fHDZxk9ODKrJZ3Dtw== X-Gm-Gg: AY/fxX5sR8KJvQQkHM+o2s/8mwkWEn/QJxR7nBoQzZ/Ts5Fc3j7So4Wi1wwEf7A0myE jP9+rRkTFniAGWeVBqbIcVvKsrSleyzuMRhg+9iEmUK56HJkTGhXgqiZ4aXSNWF8wY2KNuIAH1X CO2cPfQkpyzazrpIuzKe6T0AXucZBwh2xzLdIOXJlbSXQKYFCxa/ev66B45W7uGov3ZIRnxuvlF roP9+euFYhq/Oz59hyV1wS3VbgmyGkzc+3Li8vjhzYlpg8o1mBQHX9xSXmt9GeeCDao4H/rUEu6 0kTj1P4q+PmrGPbbVLfzRuJf6Dp8A8xk91qJmA6E8bOMZwOTp5/NDkN1wg2aX5YXvNBZkMsW+Lg AoeD/KQrX9F0Z2HpXe65AnBTl57hCbL6kfp5qEbMftOAf0QayN1m5+Ao4UoAALknFb/K+V9n7xL +SN/7y0CFBg/NcqYGL3WvL4OCGrSsSigl6ADYJ88BL+1Ov16dDwiNhI7QHNn69s5+D940YeeQtH Mg/zm1DV7Pe4A== X-Google-Smtp-Source: AGHT+IEM8JRmJRcETcV3xxkUew572fSMCjkj6PZqhZCzMMIT7XB+pr2C8wN4tuBTqy3bKKmzqRSmmA== X-Received: by 2002:a5d:5f44:0:b0:425:86da:325f with SMTP id ffacd0b85a97d-432c3778c2bmr4380832f8f.27.1767799292945; Wed, 07 Jan 2026 07:21:32 -0800 (PST) Message-ID: Date: Wed, 7 Jan 2026 16:21:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 04/15] xen/riscv: introduce vtimer 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: <94ffc70d3050e532290126560355dc548161f466.1766595589.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: <94ffc70d3050e532290126560355dc548161f466.1766595589.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 24.12.2025 18:03, Oleksii Kurochko wrote: > Introduce a virtual timer structure along with functions to initialize > and destroy the virtual timer. > > Add a vtimer_expired() function and implement it as a stub, as the timer > and tasklet subsystems are not functional at this stage. Shouldn't those pieces of infrastructure be made work then first? I also don't quite understand why the subsystems not being functional prevents the function to be implemented as far as possible. Most if not all functions you need from both subsystems should be available, for living in common code. > --- a/xen/arch/riscv/include/asm/domain.h > +++ b/xen/arch/riscv/include/asm/domain.h > @@ -8,6 +8,7 @@ > #include > > #include > +#include > > struct vcpu_vmid { > uint64_t generation; > @@ -52,6 +53,9 @@ struct arch_vcpu > struct cpu_info *cpu_info; > void *stack; > > + struct vtimer vtimer; > + bool vtimer_initialized; Assuming the field is really needed (see remark further down), why is this not part of the struct? > --- /dev/null > +++ b/xen/arch/riscv/include/asm/vtimer.h > @@ -0,0 +1,25 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * (c) 2023-2024 Vates > + */ > + > +#ifndef ASM__RISCV__VTIMER_H > +#define ASM__RISCV__VTIMER_H > + > +#include > + > +struct domain; > +struct vcpu; I don't think this one is needed, as long as you have ... > +struct xen_arch_domainconfig; > + > +struct vtimer { > + struct vcpu *v; ... this. Question is why this is here: You should be able to get hold of the struct vcpu containing a struct vtimer using container_of(). > --- /dev/null > +++ b/xen/arch/riscv/vtimer.c > @@ -0,0 +1,39 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > + > +#include > + > +#include > + > +#include > + > +int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config) > +{ > + /* Nothing to do at the moment */ > + > + return 0; > +} The function has no caller and does nothing - why do we need it? > +static void vtimer_expired(void *data) > +{ > + panic("%s: TBD\n", __func__); > +} > + > +int vcpu_vtimer_init(struct vcpu *v) > +{ > + struct vtimer *t = &v->arch.vtimer; > + > + t->v = v; > + init_timer(&t->timer, vtimer_expired, t, v->processor); > + > + v->arch.vtimer_initialized = true; init_timer() has specific effects (like setting t->function to non-NULL and t->status to other than TIMER_STATUS_invalid). Can't you leverage that instead of having a separate boolean? (Iirc we do so elsewhere.) Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 07 15:41:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 15:41:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196825.1514546 (Exim 4.92) (envelope-from ) id 1vdVer-0000Uk-7O; Wed, 07 Jan 2026 15:41:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196825.1514546; Wed, 07 Jan 2026 15: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 1vdVer-0000Ud-4h; Wed, 07 Jan 2026 15:41:13 +0000 Received: by outflank-mailman (input) for mailman id 1196825; Wed, 07 Jan 2026 15:41:11 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdVep-0000UX-O5 for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 15:41:11 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vdVep-00DSjb-00; Wed, 07 Jan 2026 15:41:11 +0000 Received: from [2a01:cb15:80df:da00:baa:5f20:ede5:a76a] (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 1vdVep-00Cbm3-02; Wed, 07 Jan 2026 15:41:11 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=qKn+f/Ywoz78J1Yj6mzSk6SdcGfXSbSTQwwUxD2nwfc=; b=z8NVVJbrERW8RRAC2bzvMupjYD 7esH4jKbpr8I+Ja8/q1IUAEvafNRZKr1x+MlbyXM9TIHYa2aCGd1cKJUUgee192mTtAmEadfxpiUd 0UFwULjR+3M3UAu85y0LGNsEm9mITvqF02msORkG72XJo583ZHLNQpnrsvfawRoIUr9g=; Date: Wed, 7 Jan 2026 16:41:09 +0100 From: Anthony PERARD To: Roger Pau Monne Cc: xen-devel@lists.xenproject.org, Anthony PERARD , Juergen Gross Subject: Re: [PATCH v2] libs/xg: allow caller to provide extra memflags for populate physmap Message-ID: References: <20251219082532.43673-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20251219082532.43673-1-roger.pau@citrix.com> On Fri, Dec 19, 2025 at 09:25:32AM +0100, Roger Pau Monne wrote: > Introduce an additional memflags field to the xc_dom_image and > xc_sr_context structures and use it to pass additional memflags to use when > populating the domain physmap. > > No meaningful usages of this new field are added as part of the patch. The > only know usage will be from the XAPI domain builder, which lives in a > different repository. > > Signed-off-by: Roger Pau Monn Acked-by: Anthony PERARD Thanks, -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Wed Jan 07 15:47:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 15:47:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196836.1514556 (Exim 4.92) (envelope-from ) id 1vdVlC-00019D-So; Wed, 07 Jan 2026 15:47:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196836.1514556; Wed, 07 Jan 2026 15: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 1vdVlC-000196-Pw; Wed, 07 Jan 2026 15:47:46 +0000 Received: by outflank-mailman (input) for mailman id 1196836; Wed, 07 Jan 2026 15:47: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 1vdVlB-000190-2i for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 15:47:45 +0000 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [2a00:1450:4864:20::329]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 33fd0a98-ebe0-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 16:47:42 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-47a8195e515so16113735e9.0 for ; Wed, 07 Jan 2026 07:47:42 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d8718b995sm14155115e9.14.2026.01.07.07.47.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jan 2026 07:47:41 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 33fd0a98-ebe0-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767800862; x=1768405662; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=3A9oX7xvZs1/5egiBWUN+lMzAFvp/lccgPfVOyuW6oU=; b=G55EyZi6MpYFGdXGVV6Zl5GXnA4WAopT7JXqg/3/pe1hLO0i9c0BC2OjebZ+fsevQV WnL1scu2DvMeBTBItuJRRI41M6GDiskjcokhWihbdRgguZqp9thWjRq0zXHiwFe8iBJL xpVJj3ig/EGdQM2RnZYodisDV/WEKXieGI/ylzwef8doqKVWqNYragUPVkVg27+Xuep8 U4my9P3NwuN8jzs80Cw9RdTZ5yH/77gyg/nzwX4HAwtUqBkZlHGOc5Z0iTPHt3S9pW2q IXoGhR8W2Eumq6xtn1MaqhWIW7laL2NIQtBTJ+vNxkzjYZNYrrfmUXW4hMQ7FILcZa0F fXpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767800862; x=1768405662; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3A9oX7xvZs1/5egiBWUN+lMzAFvp/lccgPfVOyuW6oU=; b=G9k2T1qWFcJct6HbKoSnitj5bV12JZ/+O/3HLEBD76K8fxEuEwKOQKP/te+83cyy3s aTlQoI/25YTCFqyA0GVAGJ8WInrHsrzRC8dUhAhSCkoPPxjZPt3DcjR5h/H7oPxX/7Sw mZ9u+fUZmIJA/Y7Fkd/wK6Nw6s9co/C9WVIVenf45rzzkaN4yXGl4TDl2VL9jsya0ohr HxAq3RRbYzLhEkXJUZbNuiZlivBmsQ0g19ZMOktVP2SMRCEkMPYryOAXSV5HxI0ecw6l mrPds5KZErcCNPG9mLnrfuZrhVJWpNA/ey1pfdJmxl4kXsrziA9hb4YHq3n/k25gPiH0 FrlQ== X-Forwarded-Encrypted: i=1; AJvYcCUKsoZFXc0eua7u/OpY3jvQehpJajHQYI8mwyCPWObpq7ObvTFyNYRvY2QO3xGTyTKtFRsNXujtK58=@lists.xenproject.org X-Gm-Message-State: AOJu0YzeBLvMkqURrp68L3D0vzjBX5dLrb+OopQw9mgKtfaUzyWyeEmP /U7+2d1+qF0o4/lmIIHQjzk945/vL65tq+pUcKaHbOROsEwLr6tpEhzv2UJ4kzg/5Q== X-Gm-Gg: AY/fxX64lqyVXvIJpzbHh9qpBcRZE2Tr08VAVX93EMuozaoZYGn2CyzhLF3baOMkcsF 0wq1czxKiOjCnlmsDeOHNUHFPbnVRrGLIqBVQ6irw723L5jdJcur9N4Zs3jYSg7xXy6GOD7UCpr 8Xtv4t6vLNWAPU/egfchzrfI8Q+puH1S6aQ8DOfi7/8KfKCPjwJg0WcCy5+LFgZPGCaBLFE0ZuJ gwOUkznFvqO4xndHHgBNaI/UXNvKZXcHBOWIGUncdooMh6earR6aiW70IlzE931SvSEZg30rYiM ECz/1cf1a3dJ5cCUDpPBBQt5eASxmQdf80Zz+6CqVBUwdKKiHxmeRMxa4UmOcHpEsMPvntsBq3m PbBxMVBSzGYRijRMS+fqARAvVOEoVqXmICTZOXoqnSwHqmiXbqQ5IwnO1eCpAMwXWGrzNtg/ohs GQn2B0nHv2/4mmIymJY5CztH63YsBzYuvlfyB5k7wZkpYtI8sC/7E3Pd2Cxl7M/Bc3Wj+xAWMk7 FQ= X-Google-Smtp-Source: AGHT+IHfNuA5FeogYnNUcOKfryrmVdX9DkFD4C2MflnlyxxceUPL7ojhwBYKUm4m6A3lmkm7Bjd9SA== X-Received: by 2002:a05:600c:1392:b0:46e:4586:57e4 with SMTP id 5b1f17b1804b1-47d84b32ef1mr39116275e9.24.1767800862098; Wed, 07 Jan 2026 07:47:42 -0800 (PST) Message-ID: <319e6162-7a5b-4030-ae9f-a86a48e73605@suse.com> Date: Wed, 7 Jan 2026 16:47:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 05/15] xen/riscv: implement stub for smp_send_event_check_mask() 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: <837c863f5995cc4371e82b481211b053656ec7e7.1766595589.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: <837c863f5995cc4371e82b481211b053656ec7e7.1766595589.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 24.12.2025 18:03, Oleksii Kurochko wrote: > --- a/xen/arch/riscv/smp.c > +++ b/xen/arch/riscv/smp.c > @@ -1,3 +1,4 @@ > +#include > #include > > /* > @@ -13,3 +14,10 @@ > struct pcpu_info pcpu_info[NR_CPUS] = { [0 ... NR_CPUS - 1] = { > .processor_id = NR_CPUS, > }}; > + > +void smp_send_event_check_mask(const cpumask_t *mask) > +{ > +#if CONFIG_NR_CPUS > 1 > +# error "smp_send_event_check_mask() unimplemented" > +#endif > +} CONFIG_NR_CPUS is 64 by default for 64-bit arch-es, from all I can tell, also for RISC-V. And there's no "override" in riscv64_defconfig. How is the above going to work in CI? Then again I must be overlooking something, as the config used in CI has CONFIG_NR_CPUS=1. Just that I can't tell why that is. And no, I'm not meaning to ask that you override NR_CPUS (and wherever such an override would live, I think it would better be dropped rather sooner than later). Instead an option may be this: void smp_send_event_check_mask(const cpumask_t *mask) { #if CONFIG_NR_CPUS > 1 BUG_ON(!cpumask_subset(mask, cpumask_of(0))); #endif } (I can't tell off the top of my head whether an empty mask may be passed to this function. If not, cpumask_equal() could be used as well.) Of course the #if may then not be necessary at all, and a TODO comment may want putting there instead. Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 07 15:59:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 15:59:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196855.1514567 (Exim 4.92) (envelope-from ) id 1vdVw9-0002tA-VV; Wed, 07 Jan 2026 15:59:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196855.1514567; Wed, 07 Jan 2026 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 1vdVw9-0002sk-SR; Wed, 07 Jan 2026 15:59:05 +0000 Received: by outflank-mailman (input) for mailman id 1196855; Wed, 07 Jan 2026 15:59:04 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdVw8-0002se-MK for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 15:59:04 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vdVw3-00DT2R-1Z; Wed, 07 Jan 2026 15:58:59 +0000 Received: from [2a01:cb15:80df:da00:baa:5f20:ede5:a76a] (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 1vdVw3-00CcmW-1U; Wed, 07 Jan 2026 15:58: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=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=tt71Q6E/7VRue3ysODBeTsz9Sadsk+3qp6nS7uoqJL8=; b=ly0I4iiA+HfHUjbLN4kmLjajk3 MJgm+mRrR9exmZV+O6ZAmol7277DtNcur1OisRvlHtj1Bg7p2+wVeMglCJYCZwdyAsPpFURcQe6hD SY+/4lUuNG7Jhj0stLgN219QQK0c7lpapRfntmjSF/u5+//aeIW3UcKK2mGfytirOIC0=; Date: Wed, 7 Jan 2026 16:58:57 +0100 From: Anthony PERARD To: Teddy Astie , Julien Grall , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Cc: xen-devel@lists.xenproject.org, Oleksii Kurochko , Community Manager , Anthony PERARD , Jan Beulich Subject: Re: [PATCH v4 2/4] xenpm: Don't build outside of x86 Message-ID: References: <77dc07c4b4431fb53aa5b226d302f437e4314d8c.1766158766.git.teddy.astie@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77dc07c4b4431fb53aa5b226d302f437e4314d8c.1766158766.git.teddy.astie@vates.tech> On Fri, Dec 19, 2025 at 03:42:17PM +0000, Teddy Astie wrote: > xenpm doesn't provide any interesting usable features outside of x86, > skip building it if we are not x86. > > Suggested-by: Jan Beulich > Signed-off-by: Teddy Astie Happy with that on the Arm side? Julien suggested so on #XenDevel. For me, this seems fine: Acked-by: Anthony PERARD > --- > CHANGELOG.md | 3 +++ > tools/misc/Makefile | 2 +- > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/CHANGELOG.md b/CHANGELOG.md > index 3aaf598623..1fa58ce848 100644 > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -16,6 +16,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) > deprecated in Xen 4.7 and noted not to work correctly with AMD CPUs from > 2011 onwards. > > + - Removed xenpm on non-x86 platforms as it doesn't actually provide anything > + useful outside of x86. > + > ## [4.21.0](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.21.0) - 2025-11-19 > > ### Changed > diff --git a/tools/misc/Makefile b/tools/misc/Makefile > index c26e544e83..672df02c3b 100644 > --- a/tools/misc/Makefile > +++ b/tools/misc/Makefile > @@ -23,13 +23,13 @@ INSTALL_SBIN-$(CONFIG_X86) += xen-lowmemd > INSTALL_SBIN-$(CONFIG_X86) += xen-mceinj > INSTALL_SBIN-$(CONFIG_X86) += xen-memshare > INSTALL_SBIN-$(CONFIG_X86) += xen-mfndump > +INSTALL_SBIN-$(CONFIG_X86) += xenpm Nit: I would sort this by taking the dash `-` into account since we do so for the arch-common list, so xenpm would go after xen-vmtrace. > INSTALL_SBIN-$(CONFIG_X86) += xen-ucode > INSTALL_SBIN-$(CONFIG_X86) += xen-vmtrace > INSTALL_SBIN += xencov > INSTALL_SBIN += xenhypfs > INSTALL_SBIN += xenlockprof > INSTALL_SBIN += xenperf > -INSTALL_SBIN += xenpm > INSTALL_SBIN += xenwatchdogd > INSTALL_SBIN += xen-access > INSTALL_SBIN += xen-livepatch -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Wed Jan 07 16:05:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 16:05:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196870.1514576 (Exim 4.92) (envelope-from ) id 1vdW1o-0004yf-IU; Wed, 07 Jan 2026 16:04:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196870.1514576; Wed, 07 Jan 2026 16:04:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdW1o-0004yY-FY; Wed, 07 Jan 2026 16:04:56 +0000 Received: by outflank-mailman (input) for mailman id 1196870; Wed, 07 Jan 2026 16:04:55 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdW1n-0004yS-Qj for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 16:04:55 +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 9a56e534-ebe2-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 17:04:53 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-47775fb6c56so20385005e9.1 for ; Wed, 07 Jan 2026 08:04:53 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f4184e1sm104147965e9.4.2026.01.07.08.04.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jan 2026 08:04:52 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9a56e534-ebe2-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767801893; x=1768406693; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=tiGzRepSzXphOmw/6bi+x10Xc/ehmJ4ekTp0LoDhBgw=; b=GYTk66aY/7pJWzLRHBJaAn/jCYQuiIdzGWDNe/xvtphYWPSUneoAdwBVAm426ScdQr tq5B5cigP/cz//+EUj3B16tGVPV1ri0dzUinCwtzlywyEPUU9tr1KdgJfT2Zn9WhzxWG 57TQ2Q4bdSzA/GOiV2BURM/czY3JZqXCf/ulTOXWTdCBBqfEOPJ7YjcPE9gLYctEeCeC jCG0M8Mm2BkCv9o15OQOyTm2hcYgIZKN7mg+q3ukOm7MNLF5wN/175jjQJ4PtWN0AZPm 0Mecnsrztk123IIKfg3juf/HevIUliy0wQKCanV0NPZy6++jHIpn22FrlFBqO6bXF7o0 Z9Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767801893; x=1768406693; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=tiGzRepSzXphOmw/6bi+x10Xc/ehmJ4ekTp0LoDhBgw=; b=RoBnGPphhrnNTBAmxiVsKbI7aOdzsGI7GHCsDm8+JRKlFgVfAaqNKZSuIqI/30fmvb hgolOJv1AHQBEMcmMYCSxCNN/6aZqqabCc+mgt4U+sR80zQQ7MvMbHqjhXiyBs+qGcf9 TOGSvLtGtSnW3Ij+nJAU2qKZXDP9O4DfP9mXiZLIKzYkeoBqiDk8e2aOZpaYejDuJlLk PwgPCrusL3YcY9pKhlG1UgDul5F+Cm5Ce5P7/pJk+AOaNvUbemIon/3uPp2VaThLSdES WVxFaUXiI+hKsNVOR47kojj9UpG4bMrToXln6R6aDpDojG7cWRdZsiNvrAfPCT+0Eh/m EMeQ== X-Forwarded-Encrypted: i=1; AJvYcCWVOvhAw7GSus1zw7Y8ilpOQuh7Uc5Fc/pIRCtGmG5jRCXp/ZVJ59xZLJG6lTjOwiYJyaZBS3OxiSM=@lists.xenproject.org X-Gm-Message-State: AOJu0YzysnoJHPCsSNqoYcAjd8jGqTxW/Kmxxphj2rxBk4KtvTcv2unl /qcWH+rC9XgkWlIWkj133DDhcLs+Tw0OVrdwUwlFzNXtiLn3bspC2aQOI7dIFYibTw== X-Gm-Gg: AY/fxX4uxa2mMZvSk/WQ7xKWi/kEHtAIu++BpkP4PovAcXb1hs+huvbfVXSR5K9Hjx+ 3nq+Nu7I6TrEnboa2oCvCZGb02ZxWcoC46TNKINfsRNaWdXnYw/q0diCx85rN+2iyPtAjjB/U96 SnmotAAb9jH+voeDXqCtTfYAH/uA546IpSGsNXHGo9WBWgJurNCk6xzonR9RWdBRfJ7qH0W2ETg mmaJQtDk01betA2RzlrgvzT+oneThLAWnCvQqfPsZr1MjNyM0d03vhFCUj7sHIK9eyR0ioTsNMl sUQp6gXAURfEKDV966DtL59unt3hZszz/nJ/AgbmgfMEYHBomCZnZZ90xKKRc+7MKNBvR1fZ8qP pBKySLXN/00R89eN94+j+a+KgffWHjUHAASZEtogZEzA6uEaqMJJ4P+5NyOC/yFzZyEGRINMcSS pC2C++aC1j/K0yhx5P8cyhXH/r7E5iQLPhKseioUwUA/NvPHbplFcE3HzSfriIw7GcDZDbXUf9T ic= X-Google-Smtp-Source: AGHT+IH8/+zHg294Da7lJfq60VMTePYhJ0ulpPj8OJStj+ldOdQo8z/1OAiK/hqTZ6kEOimhxFydOA== X-Received: by 2002:a05:600c:4ed1:b0:47d:18b0:bb9a with SMTP id 5b1f17b1804b1-47d84b54031mr37511495e9.33.1767801892843; Wed, 07 Jan 2026 08:04:52 -0800 (PST) Message-ID: <98dc7b62-839a-45e3-a9a7-f8dbfa616c06@suse.com> Date: Wed, 7 Jan 2026 17:04:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 06/15] xen/riscv: introduce vcpu_kick() implementation To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 24.12.2025 18:03, Oleksii Kurochko wrote: > Add a RISC-V implementation of vcpu_kick(), which unblocks the target > vCPU and sends an event check IPI if the vCPU was running on another > processor. This mirrors the behavior of Arm and enables proper vCPU > wakeup handling on RISC-V. > > Remove the stub implementation from stubs.c, as it is now provided by > arch/riscv/domain.c. > > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Wed Jan 07 16:28:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 16:28:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196885.1514587 (Exim 4.92) (envelope-from ) id 1vdWOe-0007u2-BU; Wed, 07 Jan 2026 16:28:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196885.1514587; Wed, 07 Jan 2026 16:28:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdWOe-0007tv-7O; Wed, 07 Jan 2026 16:28:32 +0000 Received: by outflank-mailman (input) for mailman id 1196885; Wed, 07 Jan 2026 16:28: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 1vdWOc-0007tp-WA for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 16:28:30 +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 e102a924-ebe5-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 17:28:20 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-4779adb38d3so16261275e9.2 for ; Wed, 07 Jan 2026 08:28:20 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d870e80bbsm16894815e9.5.2026.01.07.08.28.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jan 2026 08:28:19 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e102a924-ebe5-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767803300; x=1768408100; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=3gzaOUTQA/yKZ/1ly4yxWQSVsO9Rv2BUC+NQ1VBNjk4=; b=FckyRK2R18gVGxoyU72xsL7ypg9YICnb6t0T+FwyOCTy/Z669gqQNmaV2UUYxe09hg jteZVe4t2w5VtC/k4tZnT72aFm3xRbf+h59D9VzplZqDXP3K/GlwzbkMgAL8QasCFvwT PZGAwCU4kCT4EXyt322Cac4YPwAgia6b6an2pCgPpCwwLAkAltYrPiVsik15w2O6wjKV Q8teufbU0bsHcPLwpWolSisjgbgV9OEkUltDQ2XmcO/nkvvAvc644ljY49D8pGQUYPLb E+cogwtbT/R183MnmxKbPQIjmGmndYg2LOcFMNu/UsRQfO+sag2xbA36dSBefczN0eR+ 9tsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767803300; x=1768408100; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3gzaOUTQA/yKZ/1ly4yxWQSVsO9Rv2BUC+NQ1VBNjk4=; b=h94I7+AQ2yjD9JkloAod9WquA8LuFWDfNpGBBJiLo/ThZp66t7fxuC1rlp1Qq/XDxG eA90Jk3gRgg5pilBfyZLZ+nKWh4rzMXT6gyuKovL3EAcBFqbXc5muY7Z4CoXLd/C9+2E ZSFNW7NwJapu+7NdZI8EKf17n45Be2SKDMmJ+nm/7xXpERrmZ94TmMuSnbvhEonREoxw IKVuixLaqT/OKSl2RwW2f4CNs3Vs8PvB5+BUVZOkzNQXEFfCk5Ub+s6Pc+w537cQSs3y iHT+usxEONCqS6KvvxDAzQxPIKmC78YKo/Vg3pqSv7bg3e5afaU/Jj9UI79VokqTOSc1 beqQ== X-Forwarded-Encrypted: i=1; AJvYcCXNGzSPiBQY1qR2VaWinq205jwCFD05zwgHBHrtlqHH+zMjqnrDukdod8RU8K9BENJ8e/VFT7nJooM=@lists.xenproject.org X-Gm-Message-State: AOJu0YxtCYLRR10YD9qZ2dbOBbQ890E9vpiUt8abH/ubdSjXJRcrxvx3 +nKEm0O9vz99ujWnMegwkEDgMt2/mPdq0kHD2KCUPUxlhgVOldMydZ2nxOOSBAvnfA== X-Gm-Gg: AY/fxX6hOMCLS2PnOdtz9nLvhq1HeGNgtZ4q/jwLGvlElo31Y16ehYGplpAn4lkheFd 0naAzwZezYvYgT+/jhIBYE4PFqWcPAFF135nVxNmropYCWmrgsqVHOa1MOE5l6WU6qoczGPvy2F 5jVo+T1RdNTmuIme5d1Sac3XFjJQ+97ec1BhqwE5GzwJdl09Mk253R60DvyH/5hPiJ0jq9iAROf 84K2QJd0fKQsHCtqeKhY441Nkb5nvI5mjV6+8liZXmj7+enNHMNj5b02oVIsKi9FHNGjkEpkAhy mUNzg5eL91ZWradzatyjQLgmXi8aApTT522rOaDFE94z+nJCT1t5wItQ2R6DkRxI73yv+tijGnP 4QBx7LLJxBEektLcxPWU+jrg/JpXHWDGket9s2zgnEDvBvNetKhPIQVh/+LabPijymgOf1bJv20 525wb7dVd9CZrA+DPOg0GyIRumVo+9tS/Ju2ABBL+w2zI6jI3FospIjQD7VDvBJIudjrpXJcXse Dg= X-Google-Smtp-Source: AGHT+IEOxDP0XsKJu3h3qZD7xvHeD/udVr5+QFWpqzO8YpL4NzXihGBHfInEOZBFEp6XQWbP639sqw== X-Received: by 2002:a05:600c:3b19:b0:45d:d97c:236c with SMTP id 5b1f17b1804b1-47d84b3b645mr37738785e9.21.1767803299921; Wed, 07 Jan 2026 08:28:19 -0800 (PST) Message-ID: Date: Wed, 7 Jan 2026 17:28:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 07/15] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 24.12.2025 18:03, Oleksii Kurochko wrote: > This patch is based on Linux kernel 6.16.0. > > Introduce a lockless mechanism for tracking pending vCPU interrupts using > atomic bit operations. The design follows a multi-producer, single-consumer > model where the consumer is the vCPU itself. > > Two bitmaps are added: > - irqs_pending — represents interrupts currently pending > - irqs_pending_mask — represents bits that have changed in irqs_pending > > Introduce vcpu_(un)set_interrupt() to mark an interrupt in irqs_pending{_mask} > bitmap(s) to notify vCPU that it has or no an interrupt. It's not becoming clear how these are going to be used. It's also not clear to me whether you really need to record these in software: Aren't there (virtual) registers where they would be more naturally tracked, much like hardware would do? Furthermore, since you're dealing with two bitmaps, there's no full atomicity here anyway. The bitmaps are each dealt with atomically, but the overall update isn't atomic. Whether that's going to be okay can only be told when also seeing the producer side. > --- a/xen/arch/riscv/domain.c > +++ b/xen/arch/riscv/domain.c > @@ -5,9 +5,11 @@ > #include > #include > > +#include > #include > #include > #include > +#include > #include > > static void vcpu_csr_init(struct vcpu *v) > @@ -100,6 +102,9 @@ int arch_vcpu_create(struct vcpu *v) > if ( is_idle_vcpu(v) ) > return rc; > > + bitmap_zero(v->arch.irqs_pending, RISCV_VCPU_NR_IRQS); > + bitmap_zero(v->arch.irqs_pending_mask, RISCV_VCPU_NR_IRQS); This is pointless, as struct vcpu starts out all zero. > @@ -135,3 +140,45 @@ void vcpu_kick(struct vcpu *v) > smp_send_event_check_mask(cpumask_of(v->processor)); > } > } > + > +int vcpu_set_interrupt(struct vcpu *v, const unsigned int irq) > +{ > + /* > + * We only allow VS-mode software, timer, and external > + * interrupts when irq is one of the local interrupts > + * defined by RISC-V privilege specification. > + */ > + if ( irq < IRQ_LOCAL_MAX && What use is this? In particular this allows an incoming irq with a huge number to ... > + irq != IRQ_VS_SOFT && > + irq != IRQ_VS_TIMER && > + irq != IRQ_VS_EXT ) > + return -EINVAL; > + > + set_bit(irq, v->arch.irqs_pending); > + smp_mb__before_atomic(); > + set_bit(irq, v->arch.irqs_pending_mask); ... overrun both bitmaps. > --- a/xen/arch/riscv/include/asm/domain.h > +++ b/xen/arch/riscv/include/asm/domain.h > @@ -85,6 +85,22 @@ struct arch_vcpu > register_t vstval; > register_t vsatp; > register_t vsepc; > + > + /* > + * VCPU interrupts > + * > + * We have a lockless approach for tracking pending VCPU interrupts > + * implemented using atomic bitops. The irqs_pending bitmap represent > + * pending interrupts whereas irqs_pending_mask represent bits changed > + * in irqs_pending. And hence a set immediately followed by an unset is then indistinguishable from just an unset (or the other way around). This may not be a problem, but if it isn't, I think this needs explaining. Much like it is unclear why the "changed" state needs tracking in the first place. > Our approach is modeled around multiple producer > + * and single consumer problem where the consumer is the VCPU itself. > + * > + * DECLARE_BITMAP() is needed here to support 64 vCPU local interrupts > + * on RV32 host. > + */ > +#define RISCV_VCPU_NR_IRQS 64 > + DECLARE_BITMAP(irqs_pending, RISCV_VCPU_NR_IRQS); > + DECLARE_BITMAP(irqs_pending_mask, RISCV_VCPU_NR_IRQS); > } __cacheline_aligned; > > struct paging_domain { > @@ -123,6 +139,9 @@ static inline void update_guest_memory_policy(struct vcpu *v, > > static inline void arch_vcpu_block(struct vcpu *v) {} > > +int vcpu_set_interrupt(struct vcpu *v, const unsigned int irq); > +int vcpu_unset_interrupt(struct vcpu *v, const unsigned int irq); Why the const-s? > --- a/xen/arch/riscv/include/asm/riscv_encoding.h > +++ b/xen/arch/riscv/include/asm/riscv_encoding.h > @@ -91,6 +91,7 @@ > #define IRQ_M_EXT 11 > #define IRQ_S_GEXT 12 > #define IRQ_PMU_OVF 13 > +#define IRQ_LOCAL_MAX (IRQ_PMU_OVF + 1) MAX together with "+ 1" looks wrong. What is 14 (which, when MAX is 14, must be a valid interrupt)? Or if 14 isn't a valid interrupt, please use NR or NUM. Also, nit: Padding doesn't match with the earlier #define-s (even if in the quoted text it appears otherwise). Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 07 16:29:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 16:29:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196893.1514598 (Exim 4.92) (envelope-from ) id 1vdWPI-0008MM-Le; Wed, 07 Jan 2026 16:29:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196893.1514598; Wed, 07 Jan 2026 16:29:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdWPI-0008MC-GU; Wed, 07 Jan 2026 16:29:12 +0000 Received: by outflank-mailman (input) for mailman id 1196893; Wed, 07 Jan 2026 16:29:11 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdWPG-0007tp-UM for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 16:29:11 +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 fe050a7f-ebe5-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 17:29:09 +0100 (CET) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-b7633027cb2so428283366b.1 for ; Wed, 07 Jan 2026 08:29:09 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a2bcd30sm564782166b.28.2026.01.07.08.29.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jan 2026 08:29:08 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fe050a7f-ebe5-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767803348; x=1768408148; 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=tjuoYdvWljUojSpx+YIWcKImnV56YQ/NbuvvvfaP9pQ=; b=ItX/uXeXjH435npqY+QEV7Bwt51rEWnc8CVcahUN2slQrtzgdl75qVizZ/Vb4Q02LL wHV+dKd+VNKkhK6Mwdr0DSDZb5+e/APqaxuggP8c8+xudbQTmCnk+aiDkI9xSix6h3QB 7Bwi0u7lrwgaPzRR9I2PHzAhq9OZipJOZ65Mgg0P5UgaI4DhgzlSrkPhtLrxLF1bpiZP hn4nZ3OXp7S58O33aemvdYH58g3OQtMQbcR3Rggautb4aDKlDB8pYykmIXHsW5BHjRJ0 3tlNcmsHSqTCxbl4GtuJ0LjIKj9WWnbUMoi+9ks/YQ9WD70YyTOVnu+29UVMGWBKAedA w5PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767803348; x=1768408148; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=tjuoYdvWljUojSpx+YIWcKImnV56YQ/NbuvvvfaP9pQ=; b=T4Ka7BNbymROD85uVFBcGexmrtVhG8ivsPKGgZ9f7TfelYLcm4KqILpUrlZll/bDwO tHKEc3M/KZ4tEn7NF/zZYiBDTiBb9rr3HiIgf4Gv1am3IC+EJOwZUepG945fOr2FP431 8MJmO4DB+qOlZCV4rECKDvCivoQzCC9Ky8bC8X5+9w9TxfpyPO/v1cGTSipZdLMFlIxH ZHcV7z1rCbYULb99g6AO1ju+givcalGVQ83dcN0KxWFLc17EWGFX5DZaeLjP8RqQDrTO Bu6ehLGHktSKTfDo90nmDrbST+YTPvTJh1rAqDRHcPGkE59kf1NhF0as4qgdjCxXvfVT cJ/w== X-Gm-Message-State: AOJu0Yy6dBQIJEmh8WGiGBXLfPmxhpL2zQENJwF7ESXHANP6fk5jUR0W YoRcUlL+Nqf8gUUHcjmk9bOk0UmshLMRuP9hdhS/pMc+LDYXYKvco3XYFirPhQ== X-Gm-Gg: AY/fxX6LYBhnca7Q2q2zsbKqvoR3DmwI3p5SvsTR8HOmKA/7CcF+CkflAM5PHk9BjMY /GKbLx3kgGXAuFEetenIejQPdUbKaOV0kEO0VS+8CbglxGcu7IsM2EqADipih1cFvWPEdBIRZfd 7OPAJ/1vXFgPUdExUsTT97ZPw3+0zqYNVeyHtL7PglM8+xeYCw9IZk1wZ2skQ8YWWHzb6LxCLXl RWjBdyhjDMzazRXizXdfofn2J05h91jv6CRuFm+ZF6NezbLzNc7FqoMPvPLOnNkJlk5Zjm2Dr9W B1gxNv7KitZ8QRoD2flyFcOFwOLeUNJrlnbVJWxqibxL2E7E01oxT9qbTD1rxsD4tX567YXORcr CVaN/3njWi3fhfsplwLjlikALOHKd4oCZ0s7a84jG5QVn23pENjDAK/xKh8PDhuGxzWJxNimiy0 OqhlB3Hb22nyZHDuLkkvpAXxAXMjnC/yT5qOrm7zLgV2GSxBwehVhQDA== X-Google-Smtp-Source: AGHT+IHXSIaRDREifRHmgI4xeNxe/ZwpXciikty4TeBm4vwRs3ZZiRa08WGypmzmoMIpWT8TNWEwRA== X-Received: by 2002:a17:907:3d42:b0:b80:46f5:cabe with SMTP id a640c23a62f3a-b8444c4d2aemr349138466b.4.1767803348315; Wed, 07 Jan 2026 08:29:08 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Timothy Pearson , Alistair Francis , Connor Davis Subject: [PATCH v5 0/3] Move alloc/free_vcpu_struct() to common code Date: Wed, 7 Jan 2026 17:28:57 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit As it was suggested in [1] it would be better to allocate one page for struct vcpu for all arch-es. To do that it is needed to align Arm code to allocate one page (as there is a case(when CONFIG_NEW_VGIC=y) when Arm64 will require to allocate two pages). As a result, the following patches for Arm have been introduced: - [PATCH v2 1/4] xen/arm: optimize the size of struct vcpu - [PATCH v2 2/4] xen/arm: drop MAX_PAGES_PER_VCPU This patches are dependency for: - [PATCH v2 3/4] xen: move alloc/free_vcpu_struct() to common code Also, as a part of this patch series another clean up is done which makes {alloc,free}_domain_struct() static. [1] https://lore.kernel.org/xen-devel/f8a9be3a-a0c6-496a-806f-40760dca5aee@suse.com/T/#m275dfcbdccef0461fa9a8acef072403f18091768 CI: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/2246917084 --- Changes in v5: - Address the comments recieved for v4. - Patch "xen/arm: vcpu_vgic_free() updates" has been merged to staging. --- Changes in v4: - Address the comments recieved for v3. --- Changes in v3: - Come up with a different way to optimize struct vcpu for Arm. - Merge patches "[PATCH v2 2/4] xen/arm: drop MAX_PAGES_PER_VCPU]" and "[PATCH v2 4/4] xen/common: make {alloc,free}_domain_struct() static" together. - Clean up vcpu_vgic_free() a little bit. --- Changes in v2: - Introduce new patches for Arm: - [PATCH v2 1/4] xen/arm: optimize the size of struct vcpu - [PATCH v2 2/4] xen/arm: drop MAX_PAGES_PER_VCPU to allocate one page for struct vcpu in common code for all the arch-es. - Introduce patch to clean up xen/domain.h a little bit: - [PATCH v2 4/4] xen/common: make {alloc,free}_domain_struct() static - Address the comments from v1: - [PATCH v2 3/4] xen: move alloc/free_vcpu_struct() to common code --- Oleksii Kurochko (3): xen/arm: optimize the size of struct vcpu xen: move alloc/free_vcpu_struct() to common code xen/common: make {alloc,free}_domain_struct() static xen/arch/arm/domain.c | 32 --------------- xen/arch/arm/include/asm/new_vgic.h | 2 +- xen/arch/arm/vgic/vgic-init.c | 7 ++++ xen/arch/ppc/stubs.c | 10 ----- xen/arch/riscv/stubs.c | 10 ----- xen/arch/x86/domain.c | 24 ----------- xen/arch/x86/include/asm/domain.h | 12 ++++++ xen/common/domain.c | 62 +++++++++++++++++++---------- xen/include/xen/domain.h | 8 ---- 9 files changed, 61 insertions(+), 106 deletions(-) -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 07 16:29:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 16:29:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196894.1514606 (Exim 4.92) (envelope-from ) id 1vdWPJ-000097-T7; Wed, 07 Jan 2026 16:29:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196894.1514606; Wed, 07 Jan 2026 16:29: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 1vdWPJ-00008y-Q7; Wed, 07 Jan 2026 16:29:13 +0000 Received: by outflank-mailman (input) for mailman id 1196894; Wed, 07 Jan 2026 16:29: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 1vdWPI-0008M3-D0 for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 16:29:12 +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 fea318b0-ebe5-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 17:29:10 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-b7cf4a975d2so391631766b.2 for ; Wed, 07 Jan 2026 08:29:10 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a2bcd30sm564782166b.28.2026.01.07.08.29.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jan 2026 08:29:08 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fea318b0-ebe5-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767803349; x=1768408149; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=6yGW8UvBWmtvRdmMTk+NgZys8X+oT8jZSBJlqpDXUFw=; b=ARZ5r4E6cU2X/Nw56kGZwi8J6GwKxcfe8Pl/4hNP+w81GBvEiGZi6OiJQCARmOjcV0 tLxDpNogtYY2Rb4DhgeU3dAJcX4GHTPq7ujJhAvx8WAn8o5LlxnGHdS25zFziplzWhcm QW0DuAsXt8hxmUroLxCOOb95HlHhKx++QC3OOYkLfPKvD4SKHOzCHD0NXr2DJFk7eNyt w5y9iG1Zv9W2jfKZM9RwjBO+mfrBvJaHdL1ZlfU1yBU+Hs72eYa5hsuJIuCE1u1Z1NlL gEt/2o7+zMtwaUSnx87WmPJU3o5oVq1CPyfMsM3STedgMWilev2MmA/WSiNQ+sHs4g/l AmnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767803349; x=1768408149; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=6yGW8UvBWmtvRdmMTk+NgZys8X+oT8jZSBJlqpDXUFw=; b=Tgsyder+QkfcaYKT3wJisjHqYTQxeCb+TH9Xf88lSQ43hpgJe8S1GvXfW22mHiOmeM YHymul01kX6RRYHAdS88Zy3df9k0Rp0G5lZKhcH+1+IBPacuzoFSjgU7AmycewFCwT6S QZj6yJPASkCVX/QE91w4QqYFbEWQlesvClhf6Iq0fXjenlAIiEsPWGsoI/Rmg0+IX9gd t/xMZpSKH1D7hL9joiOPKwP8G2cgHKqZZRmmanyE95rPaaGKyNkmaYV/9ArQf03wmwd6 xFkB9txX3UjPwFCeSJZ3gU4LYGYD+VzzGEtMd9p2na6xs0a0HAKWVXzUVTvZV0V9g6/E olFQ== X-Gm-Message-State: AOJu0YwF8fjmBepT27uWCsgQ0ZQNKZsN1do9eqj3v2jwdhpnjKf4a8O+ qdadKFCS57aIN97who9XuV2EsHg7Ng81BOiXWZY9kdO8wjdvXt7/DIAKhLT/Zw== X-Gm-Gg: AY/fxX5IDcSY9hEo3n9a0ogxuM7PzDDrHe9yaPDFE2A7QgQsBI7jvDRLRKW2J0on0R2 YMIkHeFWxmUdR4d2z43JxKmIMyCqIoLeZcNPlX1AIEMCliGwNPmv4xSrPEcQcfRXV40tyXGLYG0 RGzdpJ7WeQ5IY4b15z3aYSu3EeJYCo4Q2v9UIk0qXaYHc/9kU72LEBKWBeTrXmEcKGATGuuw5eE CuIJmXY5oEFOhFrhufYMP4X3IgbbSH4KEqGD9sXlwzrex7AiI2A05a0a0THK3Szusm8IZ1j6hP4 dUwq7PzqB3WST27jr6o+Muz9wH4apK+jqE2J7KQUU+AFopA9Z/YWEzlgORk76QdEjtLuMZOXEtW DkgbrPYjBM1kZUS9fL7i8Q7K5l9dSh7VwwGZxDNl2Z4iqQUxjY7oHX7QsG5e2cza/GNsOm46KeX Kl3OwXVPK5HBo0agq8m8ASi2Equca6VsdIw/Ywf2rgpPX2RLSrZPBwcw== X-Google-Smtp-Source: AGHT+IEq88HKeF95MEbRuBUFDBYiow8dR/PBcpgnTLj2uRlUaT1D0eK33Qc4TlRDaA6RmFlJ4mBmzw== X-Received: by 2002:a17:906:7955:b0:b7a:1bde:1221 with SMTP id a640c23a62f3a-b84451a792cmr313554766b.62.1767803349173; Wed, 07 Jan 2026 08:29:09 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper Subject: [PATCH v5 1/3] xen/arm: optimize the size of struct vcpu Date: Wed, 7 Jan 2026 17:28:58 +0100 Message-ID: <1d7f2183bd01df92445bf37ddc9d41f8bfa0ccdb.1767803084.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit When CONFIG_NEW_VGIC=y and CONFIG_ARM_64=y, the size of struct vcpu exceeds one page, which requires allocating two pages and led to the introduction of MAX_PAGES_PER_VCPU. To remove the need for MAX_PAGES_PER_VCPU, the vgic member of NEW_VGIC's struct vgic_cpu member private_irqs is changed to a pointer to struct vgic_irq. As a result, the size of struct vcpu for Arm64 is reduced to 2176 bytes in the case when CONFIG_ARM_64=y and CONFIG_NEW_VGIC=y, compared to 3840 bytes (without these changes and with CONFIG_ARM_64=y) and 4736 bytes (without these changes and with both CONFIG_ARM_64=y and CONFIG_NEW_VGIC=y). Note that all numbers are based on defconfig with the mentioned options enabled or disabled as specified. Since the private_irqs member is now a pointer, vcpu_vgic_init() and vcpu_vgic_free() are updated to allocate and free private_irqs instance. As struct vcpu now fits into one page, drop MAX_PAGES_PER_VCPU. Suggested-by: Andrew Cooper Signed-off-by: Oleksii Kurochko Reviewed-by: Andrew Cooper --- Michal gave his: Acked-by: Michal Orzel But wrote to MAX_PAGES_PER_VCPU in this patch, so probably he would like to look at how it was done. --- Change in v5: - Correct the commit message: - s/vgic_vcpu/vgic_cpu/ - s/private_irq/private_irqs/ - Drop MAX_PAGES_PER_VCPU. --- Change in v4: - Add Reviewed-by: Andrew Cooper . --- Changes in v3: - Make private_irqs member as pointer to vgic_irq in struct vgic_cpu of new_vgic instead of vgic member of arch_vcpu. --- Changes in v2: - New patch. --- xen/arch/arm/domain.c | 23 ++++------------------- xen/arch/arm/include/asm/new_vgic.h | 2 +- xen/arch/arm/vgic/vgic-init.c | 7 +++++++ 3 files changed, 12 insertions(+), 20 deletions(-) diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 47973f99d935..64b935b68000 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -473,36 +473,21 @@ void dump_pageframe_info(struct domain *d) } -/* - * The new VGIC has a bigger per-IRQ structure, so we need more than one - * page on ARM64. Cowardly increase the limit in this case. - */ -#if defined(CONFIG_NEW_VGIC) && defined(CONFIG_ARM_64) -#define MAX_PAGES_PER_VCPU 2 -#else -#define MAX_PAGES_PER_VCPU 1 -#endif - struct vcpu *alloc_vcpu_struct(const struct domain *d) { struct vcpu *v; - BUILD_BUG_ON(sizeof(*v) > MAX_PAGES_PER_VCPU * PAGE_SIZE); - v = alloc_xenheap_pages(get_order_from_bytes(sizeof(*v)), 0); + BUILD_BUG_ON(sizeof(*v) > PAGE_SIZE); + v = alloc_xenheap_page(); if ( v != NULL ) - { - unsigned int i; - - for ( i = 0; i < DIV_ROUND_UP(sizeof(*v), PAGE_SIZE); i++ ) - clear_page((void *)v + i * PAGE_SIZE); - } + clear_page(v); return v; } void free_vcpu_struct(struct vcpu *v) { - free_xenheap_pages(v, get_order_from_bytes(sizeof(*v))); + free_xenheap_page(v); } int arch_vcpu_create(struct vcpu *v) diff --git a/xen/arch/arm/include/asm/new_vgic.h b/xen/arch/arm/include/asm/new_vgic.h index 1e762138939f..6f7af0e02b2b 100644 --- a/xen/arch/arm/include/asm/new_vgic.h +++ b/xen/arch/arm/include/asm/new_vgic.h @@ -155,7 +155,7 @@ struct vgic_dist { }; struct vgic_cpu { - struct vgic_irq private_irqs[VGIC_NR_PRIVATE_IRQS]; + struct vgic_irq *private_irqs; struct list_head ap_list_head; spinlock_t ap_list_lock; /* Protects the ap_list */ diff --git a/xen/arch/arm/vgic/vgic-init.c b/xen/arch/arm/vgic/vgic-init.c index aef526f2e717..4eb49d922492 100644 --- a/xen/arch/arm/vgic/vgic-init.c +++ b/xen/arch/arm/vgic/vgic-init.c @@ -202,6 +202,11 @@ int vcpu_vgic_init(struct vcpu *v) { int ret = 0; + v->arch.vgic.private_irqs = + xzalloc_array(struct vgic_irq, VGIC_NR_PRIVATE_IRQS); + if ( !v->arch.vgic.private_irqs ) + return -ENOMEM; + vgic_vcpu_early_init(v); if ( gic_hw_version() == GIC_V2 ) @@ -244,6 +249,8 @@ void vcpu_vgic_free(struct vcpu *v) struct vgic_cpu *vgic_cpu = &v->arch.vgic; INIT_LIST_HEAD(&vgic_cpu->ap_list_head); + + XFREE(v->arch.vgic.private_irqs); } /* -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 07 16:29:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 16:29:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196895.1514616 (Exim 4.92) (envelope-from ) id 1vdWPL-0000Od-5g; Wed, 07 Jan 2026 16:29:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196895.1514616; Wed, 07 Jan 2026 16:29: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 1vdWPL-0000OS-2E; Wed, 07 Jan 2026 16:29:15 +0000 Received: by outflank-mailman (input) for mailman id 1196895; Wed, 07 Jan 2026 16:29: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 1vdWPK-0008M3-9N for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 16:29:14 +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 ffb0f3ea-ebe5-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 17:29:12 +0100 (CET) Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-64d30dc4ed7so4330057a12.0 for ; Wed, 07 Jan 2026 08:29:12 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a2bcd30sm564782166b.28.2026.01.07.08.29.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jan 2026 08:29:10 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ffb0f3ea-ebe5-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767803351; x=1768408151; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=+ez9JtZF2nCaMC9sk3cjdnVhQzElopUuISWmFxgfkIg=; b=gMSUDviglT8AuI7JEqJj33JZyB396lQQ7TbKWt0CkqlZtW4XMNPCTy48bczNcjJ9vz gkiI4V/a/G+3ga3f6s9tAvjDN5BkFIsiuqw0xn7dYc47V/vrwy+1wB5LZSB6sP5R7ucd 6dQT4hmZRlN/q+9LyK3lsUSPUTh+WgtF38LojOyTSzZJNCHIVn31B1Wo8nmn9YqN6US3 D+3ba2+gUii4WgGHfzSwKqK0Dcn2XZMzv0LEpVG55ug+YiH3KyBZObeshpxlQDAi2Mw4 x49ZsWzVeA6WfYdLSdc291uWYYOiEsFxbgLfwZnMcMfTYlShVevcjftu7gpiz2U+YskY +aAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767803351; x=1768408151; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=+ez9JtZF2nCaMC9sk3cjdnVhQzElopUuISWmFxgfkIg=; b=T5aqGMnT0lIiS/0GccVwQ320OrX7ENd/TW8ZLn2LSPLn1qYlU/nNmkUA8WloSsGMpo dc9Xb5yxNA0dXHdaOsiAcoa47mQfs4ZyacjEulkifEOwlu8F4gEqJGFnxwCINTw0+mS2 LpYG7Cc9is2troxn8x/jc3oIz395y0dzOca/wAVvFc8nJCk2DDGSVjU3jceKle6OYEIg vUiFwqoaMFupMBlYbSMpsRxD4Y3sueaB/q30j5Ljp0gPtDltt2m2jWrcac6m5y8J3tCY jx5U9QI7LFgE1/aU51Gbz6gg8TkA/5z2hW2S3Pk5kWldwyeTRFaKhaSJMt193vl2y0Ty aYug== X-Gm-Message-State: AOJu0YymjiUdv1tqdBcSYTkerUZ5CEhfoiJMCGqHTW9T8P3cbbbASDJF ihIFc/3Qk5648mJ3l69SEvJFap5jusuj0hGRdkGB+bPtPHmB7eklN3bb9wX3LA== X-Gm-Gg: AY/fxX5ia+3cRWrK/pwmgZbCH/8YLtYwWFWSxDMQix/bnSe6/uiCdURX1s8kBQhf3TR umHRSIWeLn8DQx+GgRaHIEbgZXNI0ckh3NgjkXHUPeOhrHgcSS/vQ1BRuxe/8fTZ9Z2zKH1dj3w /nRy5nKCf3RzIJTBb/f2VSgJRJty1yqAHD0pmyIxy29/p007H2QyzMBq+rFq+jONlwvW6PJbmx9 ogwF9uJK6x5B72UYXF+RT890ATzyUHuK39RN+OsqZfZYXnayb3h6iPyvhhObt9Ho3hKbMGqMAE7 r1ChBhACz7Mcix1HsUirf7qiuQKwnnN6/XMxuenGjzU+hO2PagFSALsWRoHZIbtbzl9+AUozJoI iP7rM/7G+1lrtOPQpgYShRylfFU5oWFoTyf8NVlo8CYVahiUL/JaSLtMC4l/aEKmm+WoLB0q++f P5k8FVfkpSVQSP6ULOzedyhLGqcuWJv3lzMhewC3dUL3YPueX3KYiuKQ== X-Google-Smtp-Source: AGHT+IHV63gItJh83a3Xjq66Fr6D9okyLbTXxBWVEeQ7oPpDm6Zy3VvB5Ttt/7AsQUQhSv/m0Z66yQ== X-Received: by 2002:a17:907:1c8c:b0:b83:a4a7:725e with SMTP id a640c23a62f3a-b8444c9e3c8mr352466566b.24.1767803351213; Wed, 07 Jan 2026 08:29:11 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v5 3/3] xen/common: make {alloc,free}_domain_struct() static Date: Wed, 7 Jan 2026 17:29:00 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit As {alloc,free}_domain_struct() are used only within domain.c, they can be declared static and their declarations removed from xen/domain.h. Signed-off-by: Oleksii Kurochko Acked-by: Andrew Cooper --- Changes in v5: - Nothing changed. Only rebase. --- Changes in v4: - Move implementation of alloc_domain_struct() and free_domain_struct() ahead of alloc_vcpu_struct(). --- Changes in v3: - Move alloc_domain_struct() and free_domain_struct() to not have forward declaration. - Add Acked-by: Andrew Cooper . --- Changes in v2: - New patch. --- xen/common/domain.c | 42 ++++++++++++++++++++-------------------- xen/include/xen/domain.h | 4 ---- 2 files changed, 21 insertions(+), 25 deletions(-) diff --git a/xen/common/domain.c b/xen/common/domain.c index 655d9590f846..ed4b6175de0b 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -316,6 +316,27 @@ static void vcpu_info_reset(struct vcpu *v) : &dummy_vcpu_info); } +static struct domain *alloc_domain_struct(void) +{ +#ifndef arch_domain_struct_memflags +# define arch_domain_struct_memflags() 0 +#endif + + struct domain *d = alloc_xenheap_pages(0, arch_domain_struct_memflags()); + + BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE); + + if ( d ) + clear_page(d); + + return d; +} + +static void free_domain_struct(struct domain *d) +{ + free_xenheap_page(d); +} + static struct vcpu *alloc_vcpu_struct(const struct domain *d) { #ifndef arch_vcpu_struct_memflags @@ -819,27 +840,6 @@ static int sanitise_domain_config(struct xen_domctl_createdomain *config) return arch_sanitise_domain_config(config); } -struct domain *alloc_domain_struct(void) -{ -#ifndef arch_domain_struct_memflags -# define arch_domain_struct_memflags() 0 -#endif - - struct domain *d = alloc_xenheap_pages(0, arch_domain_struct_memflags()); - - BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE); - - if ( d ) - clear_page(d); - - return d; -} - -void free_domain_struct(struct domain *d) -{ - free_xenheap_page(d); -} - struct domain *domain_create(domid_t domid, struct xen_domctl_createdomain *config, unsigned int flags) diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h index 644f5ac3f293..273717c31b3f 100644 --- a/xen/include/xen/domain.h +++ b/xen/include/xen/domain.h @@ -66,10 +66,6 @@ void domid_free(domid_t domid); * Arch-specifics. */ -/* Allocate/free a domain structure. */ -struct domain *alloc_domain_struct(void); -void free_domain_struct(struct domain *d); - /* Allocate/free a PIRQ structure. */ #ifndef alloc_pirq_struct struct pirq *alloc_pirq_struct(struct domain *d); -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 07 16:29:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 16:29:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196896.1514621 (Exim 4.92) (envelope-from ) id 1vdWPL-0000RK-Gj; Wed, 07 Jan 2026 16:29:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196896.1514621; Wed, 07 Jan 2026 16:29: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 1vdWPL-0000Pi-9h; Wed, 07 Jan 2026 16:29:15 +0000 Received: by outflank-mailman (input) for mailman id 1196896; Wed, 07 Jan 2026 16:29: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 1vdWPK-0007tp-KX for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 16:29:14 +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 ff3c6942-ebe5-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 17:29:11 +0100 (CET) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-b72b495aa81so431026466b.2 for ; Wed, 07 Jan 2026 08:29:11 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a2bcd30sm564782166b.28.2026.01.07.08.29.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jan 2026 08:29:09 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ff3c6942-ebe5-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767803350; x=1768408150; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=L8UvVrNZgvcTWva9s04sFmSLBrN7YdaYJUEfiGdAX7Q=; b=Fiq9mrR/lgPz98g/TOzqFOcc4lh94/nmHbVTSA534A6ZCebDpXD2qEsuoWW2Me7sl6 1CQBa/8Lg7vrZJoH+LUUqtJ5zV/UTdCPqAVCjZ1VJIbrV8B0ICC12xZgAn50rX497PxP LvFHl8SxPGU33I8yuT/SEogmuy0iH+gSABrGFgMkDpB23fFFesSh1VSo8HIY8Kkdlise Cn0INJvq4p8FCMXIGtaJuBtKIfKDGh6LeGYt4rXLSWbdxNGi2bj56sbhPCS2DwCV9rox 2QVUcCCzgVX37y2NywAp8nb+Uy8+yOtf/g+K+9AW1L0wgwQyBwIzb8lKM5ZGRfZiY+5s NeTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767803350; x=1768408150; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=L8UvVrNZgvcTWva9s04sFmSLBrN7YdaYJUEfiGdAX7Q=; b=k3dboSc+ah2gydUjNBDMXqiXdndkNMZCvI3Jm97IqkCkpndQHRN2pOiZ8NTVCPsImh pCpQYFHZLtoyndQ6thevVXNLMzTpKwHcKsJuEMv8j2BqA3SQg1xVYLBiiRlzJ5NMEa7x XCR2U3Ta7b2YjKdANRZnw7gPPIbEH0nNB/mI9vHXobsJ+tTwuvIQTNT/MM3heRSdB8M0 /MzcdhRyStRNKGCt4udtqywDoqMmrIwvQUNbDyElKeCBTJHlER+6lAOh/Ivueigh5atp rvU1e/wgPcAfNFgg9LDQypWxV3z8Ucm5kssC93N4fCauBnjWD0Y+e6x+h9cLHn93Ppyk 2whw== X-Gm-Message-State: AOJu0Yy2RC7PpyKaahIlL9DA4EGbCSd2kgLuNS2z3XX8XyeB86q7o+4/ uXwOX7RpKuukeGjLBPp9KQdsDrE+vfngwM6BJJW7stC6e2P7+kyww5v+apq+sw== X-Gm-Gg: AY/fxX76T0+J30IGTy/Qt7pDpTzR6VG0usk025yACnHq41PUXOb0QaG8UsVqFzfiAi5 CVCv5+lR618nMEGu07uBoBEuv8RV8boKT09EE+QdUK6leoS6YEPrb22Q39rcsAA7x4jzuhI4G6e yVHnsVTi0+BC+w2/lC/QAM9h9h3ku10fethA8S1ox3Jagm0iHygLSx4DmI7epw3DS7SUKQNIDrJ iBr3jEVDuV02BXdhaBHoVxPTA1OGFK4fZlkHBj3o2JGtAm1c/GN9nxHkJEiE+AkjajHo1AKMYLM /85Ftt5chz1dTl7diWV3IhtMoyDV/0uQEG9UeMfQI4AY9RGokXDpX4mdo6NErsCjSDn1SgiFE07 iOPdRriQ/b62FB7HllT9QojWiledQItVQAr100bl8mTMS3xo6zk1m0zrpwTYF9NkVFukjtcDRKC XQJVXOWYoOv7R/YjK0BsjQ4KOpQjimXbzpzOUrzpkudV/MOnbcTtQtW2fEhpdgpgH4 X-Google-Smtp-Source: AGHT+IEunqBkiM2UScVpXxO5HUMP2KvMWNBBtele6FJhyy5isAQRlkEX7CZN5hhcYeTwHW/KAZ+nUw== X-Received: by 2002:a17:907:7b8e:b0:b70:b93c:26cf with SMTP id a640c23a62f3a-b84451edb62mr260971566b.6.1767803350258; Wed, 07 Jan 2026 08:29:10 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Timothy Pearson , Alistair Francis , Connor Davis Subject: [PATCH v5 2/3] xen: move alloc/free_vcpu_struct() to common code Date: Wed, 7 Jan 2026 17:28:59 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit alloc_vcpu_struct() and free_vcpu_struct() contain little architecture-specific logic and are suitable for sharing across architectures. Move both helpers to common code. To support the remaining architectural differences, introduce arch_vcpu_struct_memflags(), allowing architectures to override the memory flags passed to alloc_xenheap_pages(). This is currently needed by x86, which may require MEMF_bits(32) for HVM guests using shadow paging. The ARM implementation of alloc/free_vcpu_struct() is removed and replaced by the common version. Stub implementations are also dropped from PPC and RISC-V. Now that the size of struct vcpu for Arm64 is smaller than PAGE_SIZE, MAX_PAGES_PER_VCPU is no longer needed and is removed. Finally, make alloc_vcpu_struct() and free_vcpu_struct() static to common/domain.c, as they are no longer used outside common code. No functional changes. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich Reviewed-by: Andrew Cooper --- Changes in v5: - Nothing changed. Only rebase. --- Changes in v4: - Move implementation of alloc_vcpu_struct() and free_vcpu_struct() ahead of vmtrace_free_buffer(). - Add Reviewed-by: Andrew Cooper . - Add Acked-by: Jan Beulich . --- Changes in v3: - Make from function arch_vcpu_struct_memflags() a macros in asm/domain.h. - Drop forward declaration of arch_vcpu_struct_memflags() in asm/domain.h. - Update defintion of arch_vcpu_stuct_memflags() in alloc_vcpu_struct(). --- Changes in v2: - Rework alloc/free_vcpu_struct() to work with only one page. - Return back the comment about the restriction inside x86's arch_vcpu_struct_memflags(). - Drop MAX_PAGES_PER_VCPU. --- xen/arch/arm/domain.c | 17 ----------------- xen/arch/ppc/stubs.c | 10 ---------- xen/arch/riscv/stubs.c | 10 ---------- xen/arch/x86/domain.c | 24 ------------------------ xen/arch/x86/include/asm/domain.h | 12 ++++++++++++ xen/common/domain.c | 20 ++++++++++++++++++++ xen/include/xen/domain.h | 4 ---- 7 files changed, 32 insertions(+), 65 deletions(-) diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 64b935b68000..507df807edb8 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -473,23 +473,6 @@ void dump_pageframe_info(struct domain *d) } -struct vcpu *alloc_vcpu_struct(const struct domain *d) -{ - struct vcpu *v; - - BUILD_BUG_ON(sizeof(*v) > PAGE_SIZE); - v = alloc_xenheap_page(); - if ( v != NULL ) - clear_page(v); - - return v; -} - -void free_vcpu_struct(struct vcpu *v) -{ - free_xenheap_page(v); -} - int arch_vcpu_create(struct vcpu *v) { int rc = 0; diff --git a/xen/arch/ppc/stubs.c b/xen/arch/ppc/stubs.c index 9953ea1c6c08..f7f6e7ed97af 100644 --- a/xen/arch/ppc/stubs.c +++ b/xen/arch/ppc/stubs.c @@ -152,11 +152,6 @@ void dump_pageframe_info(struct domain *d) BUG_ON("unimplemented"); } -void free_vcpu_struct(struct vcpu *v) -{ - BUG_ON("unimplemented"); -} - int arch_vcpu_create(struct vcpu *v) { BUG_ON("unimplemented"); @@ -264,11 +259,6 @@ void vcpu_kick(struct vcpu *v) BUG_ON("unimplemented"); } -struct vcpu *alloc_vcpu_struct(const struct domain *d) -{ - BUG_ON("unimplemented"); -} - unsigned long hypercall_create_continuation(unsigned int op, const char *format, ...) { diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c index 164fc091b28a..29bdb65afbdf 100644 --- a/xen/arch/riscv/stubs.c +++ b/xen/arch/riscv/stubs.c @@ -121,11 +121,6 @@ void dump_pageframe_info(struct domain *d) BUG_ON("unimplemented"); } -void free_vcpu_struct(struct vcpu *v) -{ - BUG_ON("unimplemented"); -} - int arch_vcpu_create(struct vcpu *v) { BUG_ON("unimplemented"); @@ -233,11 +228,6 @@ void vcpu_kick(struct vcpu *v) BUG_ON("unimplemented"); } -struct vcpu *alloc_vcpu_struct(const struct domain *d) -{ - BUG_ON("unimplemented"); -} - unsigned long hypercall_create_continuation(unsigned int op, const char *format, ...) { diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 7632d5e2d62d..c29a6b0decee 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -493,30 +493,6 @@ unsigned int arch_domain_struct_memflags(void) return MEMF_bits(bits); } -struct vcpu *alloc_vcpu_struct(const struct domain *d) -{ - struct vcpu *v; - /* - * This structure contains embedded PAE PDPTEs, used when an HVM guest - * runs on shadow pagetables outside of 64-bit mode. In this case the CPU - * may require that the shadow CR3 points below 4GB, and hence the whole - * structure must satisfy this restriction. Thus we specify MEMF_bits(32). - */ - unsigned int memflags = - (is_hvm_domain(d) && paging_mode_shadow(d)) ? MEMF_bits(32) : 0; - - BUILD_BUG_ON(sizeof(*v) > PAGE_SIZE); - v = alloc_xenheap_pages(0, memflags); - if ( v != NULL ) - clear_page(v); - return v; -} - -void free_vcpu_struct(struct vcpu *v) -{ - free_xenheap_page(v); -} - /* Initialise various registers to their architectural INIT/RESET state. */ void arch_vcpu_regs_init(struct vcpu *v) { diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/domain.h index 16cd45cc32c0..effb23a23416 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -15,6 +15,18 @@ unsigned int arch_domain_struct_memflags(void); #define arch_domain_struct_memflags arch_domain_struct_memflags +/* + * This structure contains embedded PAE PDPTEs, used when an HVM guest + * runs on shadow pagetables outside of 64-bit mode. In this case the CPU + * may require that the shadow CR3 points below 4GB, and hence the whole + * structure must satisfy this restriction. Thus we specify MEMF_bits(32). + */ +#define arch_vcpu_struct_memflags(d) ({ \ + const struct domain *d_ = (d); \ + \ + (is_hvm_domain(d_) && paging_mode_shadow(d_) ? MEMF_bits(32) : 0); \ +}) + #define has_32bit_shinfo(d) ((d)->arch.has_32bit_shinfo) /* diff --git a/xen/common/domain.c b/xen/common/domain.c index 93c71bc766b0..655d9590f846 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -316,6 +316,26 @@ static void vcpu_info_reset(struct vcpu *v) : &dummy_vcpu_info); } +static struct vcpu *alloc_vcpu_struct(const struct domain *d) +{ +#ifndef arch_vcpu_struct_memflags +# define arch_vcpu_struct_memflags(d) ((void)(d), 0) +#endif + struct vcpu *v; + + BUILD_BUG_ON(sizeof(*v) > PAGE_SIZE); + v = alloc_xenheap_pages(0, arch_vcpu_struct_memflags(d)); + if ( v ) + clear_page(v); + + return v; +} + +static void free_vcpu_struct(struct vcpu *v) +{ + free_xenheap_page(v); +} + static void vmtrace_free_buffer(struct vcpu *v) { const struct domain *d = v->domain; diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h index 8aab05ae93c8..644f5ac3f293 100644 --- a/xen/include/xen/domain.h +++ b/xen/include/xen/domain.h @@ -70,10 +70,6 @@ void domid_free(domid_t domid); struct domain *alloc_domain_struct(void); void free_domain_struct(struct domain *d); -/* Allocate/free a VCPU structure. */ -struct vcpu *alloc_vcpu_struct(const struct domain *d); -void free_vcpu_struct(struct vcpu *v); - /* Allocate/free a PIRQ structure. */ #ifndef alloc_pirq_struct struct pirq *alloc_pirq_struct(struct domain *d); -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 07 16:33:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 16:33:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196925.1514637 (Exim 4.92) (envelope-from ) id 1vdWTB-00033Y-Ub; Wed, 07 Jan 2026 16:33:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196925.1514637; Wed, 07 Jan 2026 16:33:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdWTB-00033R-R6; Wed, 07 Jan 2026 16:33:13 +0000 Received: by outflank-mailman (input) for mailman id 1196925; Wed, 07 Jan 2026 16: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 1vdWTA-00033L-Tn for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 16:33:12 +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 8e728775-ebe6-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 17:33:11 +0100 (CET) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-b79e7112398so392962366b.3 for ; Wed, 07 Jan 2026 08:33:11 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a27c755sm561592366b.18.2026.01.07.08.33.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jan 2026 08:33:10 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8e728775-ebe6-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767803591; x=1768408391; 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=qjPHMQuKlnfLBXFTnLWQkQyQnlc57KzaWq7A4+i6d78=; b=lN3rEqD71q+3zaiDAuAseU58wcZ6kJrnOmidgbFmvwi7eF9xMGYqe1a4HTNOj0VIGA Zq62mRo7f7yuomn5MjJ518+sFoxcRxJHXJjr8co+FT+GaDtv46NPj1vDHv72SxoIGb8t yxl5CHbHYrgSVhzKbKYxshtfuwouMhXDW/yogFFzsZ5k/lNOdga1E+VI63zTlKOj1IDZ MFJ9fYiJ45e3tuY/d1kVcV9GQUN+Zt+LNH1JprPc6vLMMTApQXVNcToxD61LbYsaTzkw CWyC75x4cRr+96Iw/h/RPXXrM02Q9eVwBmvhIplGRbQMW1ghWSMPLfGEwkkXWk+dWlWN z/7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767803591; x=1768408391; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=qjPHMQuKlnfLBXFTnLWQkQyQnlc57KzaWq7A4+i6d78=; b=LbvWK3O0ATZOBoba9Edl0rIoFefEJ83sMy+NAdCe8ZIH2xlOCUnCMnuMdPw4oA2gMn V9r1gFDp8EHDJDVjlyigzc40q1uBXXeIhmPcpGZX+hh8aEwmuiJ/WHzR4mQwmWob5jaY FZYTy99GWf07WHFEiJeACmxS0+3z/+7+7x7xWEThE8ECh4EOG7LSmvaO3GlusNmpZJb0 xPdNxpnC1F38gKQ3n78Z4CVjRl1ZlTogmd1r/lO8Q5Qk6o4VyQ2tNiCngVDJwGPYoy4P kDK7UmtzC/efvtQRa2KZVtGsx+6PlmNzzzVMtSuWhe8pC/J3t2cGaXV4jWQwQ4k2Tix5 Am+A== X-Gm-Message-State: AOJu0YyGwjYpVQyDpDQmfHLQsGfFK3ZzjrkIv0aEt27PWTTiWvm2NPm9 UzEnwWSqDlLo7lQuq1NpfK5u2D+EUmKan41ExZF1xeVanainlshaQ0WYbKAnEA== X-Gm-Gg: AY/fxX7cL1jhWPIfKmbwnzWLsJ9zWIf6BppmbtIVM+WBsBoC0RkUnpIp/h9bDj0BHHN baeuX2lugLZvR+ECSkWeFGOSCYj+Mn0k70GsXLpXTE84m7a8aGW700ECl3WCXW9XJJ/LfaaMFkr nupGlUmd6BPPKIjtwr/AWIeiNKpnG+DU5BvNmSX4SkE6jjWFv5Hwh5oQ+2p0J2QlnHZs5L2gaeJ l/yEpGMH2hoMgjTg0lb9vastfQIr6XHGIknXFbGiDsQ3sWiizpsgsYV4tx+/l+laXsCtaV1mueH Atj8r14M5ntRSB+KmLjru8V2f0gMY17NX8EyJdQGzK91/b1WBLAXNSYrLYK5rtjzQ1TUbW6J0CE EtftQclKepWD99vIAKHb1ItiLEWT60ioir7zt0CNTfZz0n1GWvxLg5G3Ukx1z2vtBOXFg7SZUbx LGbmQvvw4Q2ASOLp+gugNti3IL9+hT/Ht7gO5KVfyVTByP6Fs6ZV7xzA== X-Google-Smtp-Source: AGHT+IHZos3W2HIpr7HwitWATiO/gTKAq6zV+3hKy2A0ciIj4REgO0GMhuAFH2EkBZUyg9v64OgXdA== X-Received: by 2002:a17:907:c807:b0:b7a:18b3:7160 with SMTP id a640c23a62f3a-b84451fcfbfmr325476366b.27.1767803590726; Wed, 07 Jan 2026 08:33:10 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v9 0/3] xen/riscv: introduce p2m functionality Date: Wed, 7 Jan 2026 17:32:56 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In this patch series are introduced necessary functions to build and manage RISC-V guest page tables and MMIO/RAM mappings. CI tests: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/2247120521 --- Changes in V9: - Addressed comments for v8. --- Changes in V8: - All patches (except last three ones) are merged to staging. - Addressed comments for v7. --- Changes in V7: - Merged to staging: - xen/riscv: avoid redundant HGATP*_MODE_SHIFT and HGATP*_VMID_SHIFT - Introduce new patch: - xen/riscv: update p2m_set_entry to free unused metadata page (could be merged with previous one: xen/riscv: introduce metadata table to store P2M type ) - Addressed comments for v6. --- Changes in V6: - Addressed coment for v5. --- Changes in V5: - Addressed comments for v4. --- 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 (3): xen/riscv: add support of page lookup by GFN xen/riscv: introduce metadata table to store P2M type xen/riscv: update p2m_set_entry() to free unused metadata pages xen/arch/riscv/include/asm/flushtlb.h | 2 +- xen/arch/riscv/include/asm/mm.h | 21 ++ xen/arch/riscv/include/asm/p2m.h | 21 ++ xen/arch/riscv/mm.c | 13 + xen/arch/riscv/p2m.c | 435 ++++++++++++++++++++++++-- 5 files changed, 462 insertions(+), 30 deletions(-) -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 07 16:33:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 16:33:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196926.1514647 (Exim 4.92) (envelope-from ) id 1vdWTF-0003Il-8C; Wed, 07 Jan 2026 16:33:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196926.1514647; Wed, 07 Jan 2026 16: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 1vdWTF-0003IW-5e; Wed, 07 Jan 2026 16:33:17 +0000 Received: by outflank-mailman (input) for mailman id 1196926; Wed, 07 Jan 2026 16:33: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 1vdWTD-0003H4-9N for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 16:33:15 +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 8f12eac7-ebe6-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 17:33:12 +0100 (CET) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-b802d5e9f06so316793266b.1 for ; Wed, 07 Jan 2026 08:33:12 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a27c755sm561592366b.18.2026.01.07.08.33.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jan 2026 08:33:11 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8f12eac7-ebe6-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767803592; x=1768408392; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=6wih4LTb2ED43OLZRmlKN38NY3IqU/8TNYjFjkPFOhQ=; b=BBd0WdNc8s2IcHuEFcL88XKASvJ490zdvqxqnbwHvs8ZrCibSFraeaNvBCtJ5zoMZi t64G/l5uTbjy7vIMfPEDn+A3cEsNGiHzD2cSm4H9veksFuwcQt5/15MnBf8JhC2Q+hDY BFfbSVfK3dVsD7cE9TvEMPGNxmHaUFiRrfbL8PzOjwuUHDWKDPYLTM3ItoqrwAtZwauC DbTMTgcDguTQQV5Woadp14ADCtRxCXlLVP06310xlTcDOflOvz98F8HQbfJ2/QCI3uQR gkzvHg6yhY1zT06wy1B71WrUmeJW+YKLky4h3FzkmpMUleq2xMi0sYOqRHU7HfmYR304 dsvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767803592; x=1768408392; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=6wih4LTb2ED43OLZRmlKN38NY3IqU/8TNYjFjkPFOhQ=; b=wuJsK//HToQjxls+vX2ROpyL5A9loY0DD60ki6mKXaw2ntt9T2Q2/FuA6HOcicei94 5L3l8l+uJG2/cv70zhFWpL8MbAIjDDBW2fWPPaQVTLvQDa0GXOWiXlO6yQjpkN2vBZto ihJitO+1WkpU/ZQhWGYFxXA7pF5266SlJafIFbJFIpJ1fe/t275i8g7ypibzREe+8lgm Qj/Z7MRUFKNqvbZcxp1Q06VWPtL6ZQuBnSGRIDj1zJdsWjrPK/eiu66BYfU9vssTo/5b +eL9VsP2IfVu1tVzFuZrQXuBSE6SE7aHGh5YXs2NIKBP3Px0sxfFSGnQud6pjiclFvxF 9FNA== X-Gm-Message-State: AOJu0YzhyelOvn77SXdsRSCuABS4pMw5BMU894GYJfA+UV/M1RPrUV0P Z+yG/z7jp48N0lCqiIK+CS5ehGx+PelB/+r1W6yd64XwSohefy55ZLZtIJGOTQ== X-Gm-Gg: AY/fxX4zMMq+i5dKib2FLIyiP7qfkSqQ5eEf3yR64QxzSLdb1z2mwBIYzE1WgkUyG6R cMZ/tZtfnaoLEps6orT5V0CJK8+MijAUaPPYR14wYb668S2m6ZSGfVIeo41ehP6e7/1KJJGrLSn EuD+C86v4RWBGnQCXqXalZEcyjWQBZq+zzRDZLn0hrMn9yYf/sJoFPGH5OAtyDJ1Nw+5jE/AsLc IAgYmShrPvN4Fev2IP5gnS0387Fp/nKdjSrjzgqYALrIu6mbXHV7ERVn/aw8+EBRlQZqXCBdor/ ODxbw3FBKBoKcQShpYc8YyC9FiTZC6qVJIG83Kbo89P59xl7G0g6FRWC56t7Mgjqk/yAtXf31Lw WkRStWNSOhoOOTnFmb2u6ZJqciY06w6HdN5s/FJrZpZ9oCG9tyk0F6AWm9xeYQB76jjXWimNiiH gLk1/9ID0VT2s1FH8t8rhwfMyGVbZB5c5Tv6KUXUpcByEU9G5JcVUvS96CSQ== X-Google-Smtp-Source: AGHT+IFwdQobeN1dR5jdK2Rqc6S6Hjj/xOA8rwgLm6hY0d9udmD5D6jP9nqYd8xKER3Fk5ezFIMNew== X-Received: by 2002:a17:907:3d02:b0:b83:c81a:197e with SMTP id a640c23a62f3a-b84451c5fc6mr317327666b.24.1767803591561; Wed, 07 Jan 2026 08:33:11 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v9 1/3] xen/riscv: add support of page lookup by GFN Date: Wed, 7 Jan 2026 17:32:57 +0100 Message-ID: X-Mailer: git-send-email 2.52.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. - 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. Signed-off-by: Oleksii Kurochko --- Changes in V9: - Update check_outside_boundary() to return (P2M_MAX_ROOT_LEVEL + 1) in the case if gfn is inside range. --- Changes in V8: - Drop the local variable masked_gfn inside check_outside_boundary() and fold the is_lower conditionals into the for loop. - Initialize the local variable level in p2m_get_entry() to the root level and drop the explicit assignment when root page table wasn't found, as it now defaults to the root level. - Introduce gfn_limit_bits and use it to calculate the maximum GFN for the MMU second stage, and return the appropriate page_order when the GFN exceeds this limit. --- Changes in V7: - Refactor check_outside_boundary(). - Reword the comment above p2m_get_entry(). - As at the moment p2m_get_entry() doesn't pass `t` as NULL we could drop "if ( t )" checks inside it to not have dead code now. - Add the check inside p2m_get_entry() that requested gfn is correct. - Add "if ( t )" check inside p2m_get_page_from_gfn() as it is going to be some callers with t = NULL. --- Changes in V6: - Move if-condition with initialization up in p2m_get_page_from_gfn(). - Pass p2mt to the call of p2m_get_entry() inside p2m_get_page_from_gfn() to avoid an issue when 't' is passed NULL. With p2mt passed to p2m_get_entry() we will recieve a proper type and so the rest of the function will able to continue use a proper type. - In check_outside_boundary() in the case when is_lower == true fill the bottom bits of masked_gfn with all 1s. - Update code of check_outside_boundary() to return proper level in the case when `level` is equal to 0. - Add ASSERT(p2m) in check_outside_boundary() to be sure that p2m isn't NULL as P2M_LEVEL_MASK() depends on p2m value. --- Changes in V5: - Use introduced in earlier patches P2M_DECLARE_OFFSETS() instead of DECLARE_OFFSETS(). - Drop blank line before check_outside_boundary(). - Use more readable version of if statements inside check_outside_boundary(). - Accumulate mask in check_outside_boundary() instead of re-writing it for each page table level to have correct gfns for comparison. - Set argument `t` of p2m_get_entry() to p2m_invalid by default. - Drop checking of (rc == P2M_TABLE_MAP_NOMEM ) when p2m_next_level(...,false,...) is called. - Add ASSERT(mfn & (BIT(P2M_LEVEL_ORDER(level), UL) - 1)); in p2m_get_entry() to be sure that recieved `mfn` has cleared lowest bits. - Drop `valid` argument from p2m_get_entry(), it is not needed anymore. - Drop p2m_lookup(), use p2m_get_entry() explicitly inside p2m_get_page_from_gfn(). - Update the commit message. --- 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 | 21 ++++ xen/arch/riscv/mm.c | 13 +++ xen/arch/riscv/p2m.c | 185 +++++++++++++++++++++++++++++++ 3 files changed, 219 insertions(+) diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h index b48693a2b41c..f63b5dec99b1 100644 --- a/xen/arch/riscv/include/asm/p2m.h +++ b/xen/arch/riscv/include/asm/p2m.h @@ -41,6 +41,9 @@ #define P2M_GFN_LEVEL_SHIFT(lvl) (P2M_LEVEL_ORDER(lvl) + PAGE_SHIFT) +#define P2M_LEVEL_MASK(p2m, lvl) \ + (P2M_TABLE_OFFSET(p2m, lvl) << P2M_GFN_LEVEL_SHIFT(lvl)) + #define paddr_bits PADDR_BITS /* Get host p2m table */ @@ -234,6 +237,24 @@ static inline bool p2m_is_write_locked(struct p2m_domain *p2m) unsigned long construct_hgatp(const 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 e25f995b727f..e9ce182d066c 100644 --- a/xen/arch/riscv/mm.c +++ b/xen/arch/riscv/mm.c @@ -673,3 +673,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 8d572f838fc3..c6de785e4c4b 100644 --- a/xen/arch/riscv/p2m.c +++ b/xen/arch/riscv/p2m.c @@ -1057,3 +1057,188 @@ 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 costly 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(const struct p2m_domain *p2m, gfn_t gfn, + gfn_t boundary, bool is_lower, + unsigned int *level_out) +{ + unsigned int level = P2M_MAX_ROOT_LEVEL + 1; + bool ret = false; + + ASSERT(p2m); + + if ( is_lower ? gfn_x(gfn) < gfn_x(boundary) + : gfn_x(gfn) > gfn_x(boundary) ) + { + for ( level = P2M_ROOT_LEVEL(p2m) ; level; level-- ) + { + unsigned long mask = BIT(P2M_GFN_LEVEL_SHIFT(level), UL) - 1; + + if ( is_lower ? (gfn_x(gfn) | mask) < gfn_x(boundary) + : (gfn_x(gfn) & ~mask) > gfn_x(boundary) ) + break; + } + + ret = true; + } + + if ( level_out ) + *level_out = level; + + return ret; +} + +/* + * Get the details of a given gfn. + * + * If the entry is present, the associated MFN, the p2m type of the mapping, + * and the page order of the mapping in the page table (i.e., it could be a + * superpage) will be returned. + * + * If the entry is not present, INVALID_MFN will be returned, page_order will + * be set according to the order of the invalid range, and the type will be + * p2m_invalid. + */ +static mfn_t p2m_get_entry(struct p2m_domain *p2m, gfn_t gfn, + p2m_type_t *t, + unsigned int *page_order) +{ + unsigned int level = P2M_ROOT_LEVEL(p2m); + unsigned int gfn_limit_bits = + P2M_LEVEL_ORDER(level + 1) + P2M_ROOT_EXTRA_BITS(p2m, level); + pte_t entry, *table; + int rc; + mfn_t mfn = INVALID_MFN; + + P2M_BUILD_LEVEL_OFFSETS(p2m, offsets, gfn_to_gaddr(gfn)); + + ASSERT(p2m_is_locked(p2m)); + + *t = p2m_invalid; + + if ( gfn_x(gfn) > (BIT(gfn_limit_bits, UL) - 1) ) + { + if ( page_order ) + *page_order = gfn_limit_bits; + + return mfn; + } + + if ( check_outside_boundary(p2m, gfn, p2m->lowest_mapped_gfn, true, + &level) ) + goto out; + + if ( check_outside_boundary(p2m, 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(); + goto out; + } + + for ( level = P2M_ROOT_LEVEL(p2m); level; level-- ) + { + rc = p2m_next_level(p2m, false, level, &table, offsets[level]); + if ( rc == P2M_TABLE_MAP_NONE ) + goto out_unmap; + + if ( rc != P2M_TABLE_NORMAL ) + break; + } + + entry = table[offsets[level]]; + + if ( pte_is_valid(entry) ) + { + *t = p2m_get_type(entry); + + mfn = pte_get_mfn(entry); + + ASSERT(!(mfn_x(mfn) & (BIT(P2M_LEVEL_ORDER(level), UL) - 1))); + + /* + * 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)); + } + + out_unmap: + unmap_domain_page(table); + + out: + if ( page_order ) + *page_order = P2M_LEVEL_ORDER(level); + + 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; + mfn_t mfn; + + p2m_read_lock(p2m); + mfn = p2m_get_entry(p2m, gfn, &p2mt, NULL); + + if ( t ) + *t = p2mt; + + if ( !mfn_valid(mfn) ) + { + p2m_read_unlock(p2m); + return NULL; + } + + 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.52.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 07 16:33:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 16:33:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196927.1514652 (Exim 4.92) (envelope-from ) id 1vdWTF-0003Ly-Iu; Wed, 07 Jan 2026 16:33:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196927.1514652; Wed, 07 Jan 2026 16: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 1vdWTF-0003Ky-C5; Wed, 07 Jan 2026 16:33:17 +0000 Received: by outflank-mailman (input) for mailman id 1196927; Wed, 07 Jan 2026 16: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 1vdWTD-00033L-NB for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 16:33:15 +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 90712ea5-ebe6-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 17:33:14 +0100 (CET) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-b7cee045187so187259266b.0 for ; Wed, 07 Jan 2026 08:33:14 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a27c755sm561592366b.18.2026.01.07.08.33.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jan 2026 08:33:13 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 90712ea5-ebe6-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767803594; x=1768408394; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=iJZSiko2nJXPL9NTYScplDvXQDw7YOhI5gws96iyp7k=; b=PkAuaMwbCy0RkUAXTRC6ctxGPGqmknfHiMA5XjWrj7+NAEiO1NJ4b91K+SpWTC9Rzi R7EOqWZzChQAASZ0EIa7mM+jitJLWiMhL6XHXr5Yjz6uiQMzK7nfi3W4lgE3hKld4HuI /dmIVXrU0cpCG6GEVNU7tIbYFGSyGD9gar5q6mg8s0hqaF4tHRdZ7k84NpQ/R58W7bJ2 6OvqkacQeMlJpEdLCUXiBuazDpJvqtcom12gL0y7ap5UVWvmPBP0F/buC6bqUx6LzMhl HAKxWP2O44G5SndqcPZB0OY6JODnaaI2raT4Vksefz1IN+iTeq1Urh2+oxiuNeoauD3b Ulqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767803594; x=1768408394; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=iJZSiko2nJXPL9NTYScplDvXQDw7YOhI5gws96iyp7k=; b=ZqhkbAzVuOYPJ4dNHDvCf3Mv0sRyuGaCL+bHWtLkJy9+J7W7pnxcRrA0p9gPP62hMs FBlr1+Np6BbP2eEDW//kEBWfYECTm9E+etE8zaVcPfRvRTD2GsohkEuFbbvRN2R/k+08 ceqfYYd4o0hkOtpPq3H+ZFw/lsD+5Tz7GG6NkIxa6HH9yHOT8L7gDnwcP3Fj1DcsqObW bi1KMRk7nwAw96TfXbQoPaw62SqwB+9rFM9/tuocqLONcImkvMpu2UKlBjxizW0K11JR /5pYyflxy4qEXTrEQ5xdki89Klnhs5yOskpTuqN7Ee58v2L2zq0qNrkfiYdTFMkTza+x 14zA== X-Gm-Message-State: AOJu0Yy/Vw6XX24vFjGJAyhiGppaZIzF283XLVcYN6N5BfCKB2inz8Pd 0qawihlialuQhwOlb3EzJVh37tZA636GLxVRF3Y2tMprO6Xw8mJscamR7xLw9Q== X-Gm-Gg: AY/fxX7SMuiDKlPcPy8glDQ5GaxgiSv60QdykyjIMDQ11oF26NtzvRTOulzT/Di6QIC g4gO5OCym+or+9UvzhjaLKm+PFY7uFkKPSgfkZOZ+G5oRFdbu1iaD8f3/xX3UxrbvoiUBNxBs2X hQ9fRZksUV3Wj+2whPf47obDcYe5zTCcYIdblTht1i8mWVMTg9yRdYiF84XrWrmzfQN2dwkXnpD 4nB/+vK0LS8F9+FzpRpsk3qQw03GN7jUg3A+VZeJzRUllD4M88JpiWXNzLTGEwxGTgVKNuxdnUQ JKaS0CN61yAVNILQ32XMdDLX0gMWrNmoVcPT07DCtgSY3RiSlZfS64sOkiGBQjbtYxYfEimuhXU Qc/F+lRL8NmIvxlaIYCO+9LjKXdDMF9Qdj/I6VvYC5UeKXCXEC3WZjIQ+F1Zq6/+IDaoJ3AWdxN 5IPtWIWiWHz6HAn0Kf5zkHJiS24Qy2Iov/cxuVixZTtV/aFdHYD34vMA== X-Google-Smtp-Source: AGHT+IFAf70CmWuElP0VndkfJS2nwryxIUulDqOwebDXN3eOOcbTXkoz+7h3WjTTEfmRkEVpSZ6W+Q== X-Received: by 2002:a17:906:4fd1:b0:b80:40ea:1d65 with SMTP id a640c23a62f3a-b8444fd5896mr388290566b.31.1767803593768; Wed, 07 Jan 2026 08:33:13 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v9 3/3] xen/riscv: update p2m_set_entry() to free unused metadata pages Date: Wed, 7 Jan 2026 17:32:59 +0100 Message-ID: <842b192c9f3cadc948a194de4789c16deafc32cb.1767803451.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Introduce tracking of metadata page entries usage and if all of them are p2m_invalid then free them. Intermediate P2M page tables are allocated with MEMF_no_owner, so we are free to repurpose struct page_info fields for them. Since page_info.u.* is not used for such pages, introduce a used_entries counter in struct page_info to track how many metadata entries are in use for a given intermediate P2M page table. The counter is updated in p2m_set_type() when metadata entries transition between p2m_invalid and a valid external type. When the last metadata entry is cleared (used_entries == 0), the associated metadata page is freed and returned to the P2M pool. Refactor metadata page freeing into a new helper, p2m_free_metadata_page(), as the same logic is needed both when tearing down a P2M table and when all metadata entries become p2m_invalid in p2m_set_type(). As part of this refactoring, move the declaration of p2m_free_page() earlier to satisfy the new helper. Additionally, implement page_set_tlbflush_timestamp() for RISC-V instead of BUGing, as it is invoked when returning memory to the domheap. Suggested-by: Jan Beulich Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v5: - Nothing changed. Only rebase. --- Changes in v4: - Move implementation of alloc_domain_struct() and free_domain_struct() ahead of alloc_vcpu_struct(). --- Changes in v3: - Move alloc_domain_struct() and free_domain_struct() to not have forward declaration. - Add Acked-by: Andrew Cooper . --- Changes in v2: - New patch. --- xen/arch/riscv/include/asm/flushtlb.h | 2 +- xen/arch/riscv/include/asm/mm.h | 12 ++++++++++ xen/arch/riscv/p2m.c | 32 +++++++++++++++++++++------ 3 files changed, 38 insertions(+), 8 deletions(-) diff --git a/xen/arch/riscv/include/asm/flushtlb.h b/xen/arch/riscv/include/asm/flushtlb.h index ab32311568ac..4f64f9757058 100644 --- a/xen/arch/riscv/include/asm/flushtlb.h +++ b/xen/arch/riscv/include/asm/flushtlb.h @@ -38,7 +38,7 @@ static inline void tlbflush_filter(cpumask_t *mask, uint32_t page_timestamp) {} static inline void page_set_tlbflush_timestamp(struct page_info *page) { - BUG_ON("unimplemented"); + page->tlbflush_timestamp = tlbflush_current_time(); } static inline void arch_flush_tlb_mask(const cpumask_t *mask) diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h index 48162f5d65cd..a005d0247a6f 100644 --- a/xen/arch/riscv/include/asm/mm.h +++ b/xen/arch/riscv/include/asm/mm.h @@ -113,6 +113,18 @@ struct page_info unsigned long type_info; } inuse; + /* Page is used as an intermediate P2M page table: count_info == 0 */ + struct { + /* + * Tracks the number of used entries in the metadata page table. + * + * If used_entries == 0, then `page_info.v.md.pg` can be freed and + * returned to the P2M pool. + */ + unsigned long used_entries; + } md; + + /* Page is on a free list: ((count_info & PGC_count_mask) == 0). */ union { struct { diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c index c40ea483a7cd..0abeb374c110 100644 --- a/xen/arch/riscv/p2m.c +++ b/xen/arch/riscv/p2m.c @@ -51,6 +51,18 @@ static struct gstage_mode_desc __ro_after_init max_gstage_mode = { .name = "Bare", }; +static void p2m_free_page(struct p2m_domain *p2m, struct page_info *pg); + +static inline void p2m_free_metadata_page(struct p2m_domain *p2m, + struct page_info **md_pg) +{ + if ( *md_pg ) + { + p2m_free_page(p2m, *md_pg); + *md_pg = NULL; + } +} + unsigned char get_max_supported_mode(void) { return max_gstage_mode.mode; @@ -448,16 +460,27 @@ static void p2m_set_type(pte_t *pte, p2m_type_t t, if ( t >= p2m_first_external ) { + if ( metadata[ctx->index].type == p2m_invalid ) + ctx->pt_page->u.md.used_entries++; + metadata[ctx->index].type = t; t = p2m_ext_storage; } else if ( metadata ) + { + if ( metadata[ctx->index].type != p2m_invalid ) + ctx->pt_page->u.md.used_entries--; + metadata[ctx->index].type = p2m_invalid; + } pte->pte |= MASK_INSR(t, P2M_TYPE_PTE_BITS_MASK); unmap_domain_page(metadata); + + if ( *md_pg && !ctx->pt_page->u.md.used_entries ) + p2m_free_metadata_page(ctx->p2m, md_pg); } /* @@ -624,18 +647,13 @@ static pte_t page_to_p2m_table(const struct page_info *page) return p2m_pte_from_mfn(page_to_mfn(page), p2m_invalid, NULL); } -static void p2m_free_page(struct p2m_domain *p2m, struct page_info *pg); - /* * 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) { - if ( tbl_pg->v.md.pg ) - { - p2m_free_page(p2m, tbl_pg->v.md.pg); - tbl_pg->v.md.pg = NULL; - } + p2m_free_metadata_page(p2m, &tbl_pg->v.md.pg); + p2m_free_page(p2m, tbl_pg); } -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 07 16:33:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 16:33:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196928.1514656 (Exim 4.92) (envelope-from ) id 1vdWTF-0003Qe-Pd; Wed, 07 Jan 2026 16:33:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196928.1514656; Wed, 07 Jan 2026 16: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 1vdWTF-0003Ne-Jc; Wed, 07 Jan 2026 16:33:17 +0000 Received: by outflank-mailman (input) for mailman id 1196928; Wed, 07 Jan 2026 16:33:16 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdWTE-0003H4-4A for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 16:33:16 +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 8fc24847-ebe6-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 17:33:13 +0100 (CET) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-b76b5afdf04so433868566b.1 for ; Wed, 07 Jan 2026 08:33:13 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a27c755sm561592366b.18.2026.01.07.08.33.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jan 2026 08:33:12 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8fc24847-ebe6-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767803593; x=1768408393; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=GoF008wHiy8va9LVm53bQ2U8gJNHDUWTgOwduclPaig=; b=ByiiFLw3GHq5a+NSH0CkbwIZatjE2IIBakM6Q94eb8xszN9QX7x4+hocPJnXyu6SBc cXqsJk5zu63u7CzK/Ysq8Pxw0Jfx2fOnuPFbMMBCunUubRgB6MoOyNuk4hLehzVLWsbA kR9ouHIDPEWbOc45fR7v5RuJdfXpjSRuV3bVqTABHQSyawbuGH8dK/x0aiPMTeeF6LLL QRdZO9LL46J/sbopYyzByZBEV7NUENcTH6FI9ci9Js+sdfeu1lUDxTslKO19rSZ+OYjk +SAHhS9ZMFOltW0V5ADqCqlvBys+z7uplsmXj0QCvsRjEi28Og887PSGwNBu0anps0C+ g/eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767803593; x=1768408393; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=GoF008wHiy8va9LVm53bQ2U8gJNHDUWTgOwduclPaig=; b=rDhuClw8OdDtMhOiy0W0Sd9nLHshtNR+JfPcJa+sT6eq5sIH33Hb/uQiSrlUwep0h+ k0sJJmKl6XzY7Uf5Qj3CQBFwqZ9SHUu9Ju1kDh7yXh95Y16waK243cZca44okpB9Jhbk X2pGQOe8WA6ub/pf5bhcWgcEUzqknsfznxfSnrWGXs4O19L35Y20mCg+JKuB9Gj1lkkI CqpQJsMMnTzJX2RGSBn0KUyuPmDciKnZc4ypwPR6baI8tjxw0feAmJYCKRp65FLX3iBj yfOqNGS3EGov/2yso9D92W5U96t5sGeTCM8siJgJeDPu8FHSwHkhXZ6SHYuBb3fDYt7i GRNw== X-Gm-Message-State: AOJu0Yx8QRbCiSWIECMQB0J4mK1PZSsO8FXR0vxaCLNhPdaVc3seU7n+ UeK/iLQSkTRFW+dO++KVlQuko/3RuoiMdumhoQBDQ2AV3DbCVsfcMJeW8dvPYQ== X-Gm-Gg: AY/fxX5EJZ70WghuPGzBa5v03OXViCfmmrjw7lFBFFUnlavlruazOePO/q7lFbh6sXI YzLKGYs4u6bKTxvAHseR+e7o6bREgsx+FdRz1rCD9jiQ31LsJqBaftFUv62Wc6Vpeqct7ywadE1 eerD+n1WjKhbQ/oXUHlWM3E6oyuSzpqmemQIG/kaeIualyzKz6SFl99DbGsIYeqweQ9IKx/R5Qv Kz72B/qlMeNDHYkwpbV72VIii1WPvtP7YPICm0lZjL3HSGujdAK7Q3u45RBy2ivlIyDWdAsW9VF heS5LZYlsN0QwTbNiCiYdebNcz4g4tr8W6wph4m1V7I5RhFbCEGnZ9urhpVw/IaaM81YoWtMmsO YNffV7PJncM+5y3YRfhe8utS6xXz9iBHg8RfrF3yUinMATtIXof80gcE78UHmKkYygvAevM/Z77 0pjmhyEEeohcMjsbcSlhSDrxhmVRxcBVyCyF8RQ5G+06KosZs091LA0w== X-Google-Smtp-Source: AGHT+IH6BPqOk5crSQHUh+MpvbhUjH3yIgenTI1txyud7Esg4PDSfhf+f1s5midl92H5ZrfVquvGrQ== X-Received: by 2002:a17:907:9455:b0:b3b:5fe6:577a with SMTP id a640c23a62f3a-b8445169517mr310668466b.8.1767803592580; Wed, 07 Jan 2026 08:33:12 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v9 2/3] xen/riscv: introduce metadata table to store P2M type Date: Wed, 7 Jan 2026 17:32:58 +0100 Message-ID: <6e5008eb873efa97e9e6174165633c50f52294e0.1767803451.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 V9: - Fold ASSERT(ctx->p2m) to the previous one ASSERT() in p2m_set_type(). --- Changes in V8: - Update the comment above p2m_set_type(). - Drop BUG_ON(ctx->level ...) and "if ( ctx->level <= P2M_MAX_SUPPORTED_LEVEL_MAPPING )" as p2m_set_type() doesn't care about ctx->level and it is expected that passed `pte` is valid, and so ctx->level is expected to be valid too. - Rename p2m_pte_ctx argument to ctx for p2m_pte_from_mfn() and p2m_free_subtree(). - Initialize local variable p2m_pte_ctx inside p2m_split_superpage() with an initializer. Drop an assigment of p2m_pte_ctx->level when old pte's type is got. - Use initializer for tmp_ctx and drop an assignment of tmp_ctx.p2m inside p2m_set_type(). - Drop brackets around p2m_free_subtree() call inside p2m_set_entry(). --- Changes in V7: - Put p2m_domain * inside struct p2m_pte_ctx and update an APIs of p2m_set_type(), p2m_pte_from_mfn(). Also, move ASSERT(p2m) closer to p2m_alloc_page(ctx->p2m) inside p2m_set_type(). Update all callers of p2m_set_type() and p2m_pte_from_mfn(). - Update the comment above BUILD_BUG_ON(p2m_invalid): drop unnessary sentenses and make it shorter then 80 chars. - Drop the comment and BUILD_BUG_ON() in p2m_get_type() as it is enough to have it in p2m_set_type(). - Update the comment above p2m_set_type() about p2m argument which was droppped. - Make ctx argument of p2m_set_type() const to be able to re-use p2m_pte_ctx across multiple iterations without fully reinitializing. - Declare "struct p2m_pte_ctx tmp_ctx;" as function scope variable and rework p2m_set_entry() correspondingly. --- Changes in V6: - Introduce new type md_t to use it instead of pte_t to store metadata types outside PTE bits. - Integrate introduced struct md_t. - Drop local variable "struct domain *d" inside p2m_set_type(). - Drop __func__ printting and use %pv. - Code style fixes - Drop unnessarry check inside if-condition in p2m_pte_from_mfn() as we have ASSERT(p2m) inside p2m_set_type() anyway. - Return back the commnent inside page_to_p2m_table() as it was deleted accidently. - move the initialization of p2m_pte_ctx.pt_page and p2m_pte_ctx.level ahead of the loop - Add BUILD_BUG_ON(p2m_invalid) before the call of p2m_alloc_page() in p2m_set_type() and in p2m_get_type() before " if ( type == p2m_ext_storage )". - Set to NULL tbl_pg->v.md.pg in p2m_free_table(). - Make argument 't' of p2m_set_type() non-const as we are going to change it. - Add some explanatory comments. - Update ASSERT at the start of p2m_set_type() to verify that passed ctx->index is lesser then 512 and drop calculation of an index of root page as it is guaranteed by calc_offset() and get_root_pointer() that we will aready get proper page and proper index inside this page. --- Changes in V5: - Rename metadata member of stuct md inside struct page_info to pg. - Stray blank in the declaration of p2m_alloc_table(). - Use "<" instead of "<=" in ASSERT() in p2m_set_type(). - Move the check that ctx is provided to an earlier point in p2m_set_type(). - Set `md_pg` after ASSERT() in p2m_set_type(). - Add BUG_ON() insetead of ASSERT_UNREACHABLE() in p2m_set_type(). - Drop a check that metadata isn't NULL before unmap_domain_page() is being called. - Make const `md` variable in p2m_get_type(). - unmap correct domain's page in p2m_get_type: use `md` instead of ctx->pt_page->v.md.pg. - Add description of how p2m and p2m_pte_ctx is expected to be used in p2m_pte_from_mfn() and drop a comment from page_to_p2m_table(). - Drop the stale part of the comment above p2m_alloc_table(). - Drop ASSERT(tbl_pg->v.md.pg) from p2m_free_table() as tbl_pg->v.md.pg is created conditionally now. - Drop an introduction of p2m_alloc_table(), update p2m_alloc_page() correspondengly and use it instead. - Add missing blank in definition of level member for tmp_ctx variable in p2m_free_subtree(). Also, add the comma at the end. - Initialize old_type once before for-loop in p2m_split_superpage() as old type will be used for all newly created PTEs. - Properly initialize p2m_pte_ctx.level with next_level instead of level when p2m_set_type() is going to be called for new PTEs. - Fix identations. - Move ASSERT(p2m) on top of p2m_set_type() to be sure that NULL isn't passed for p2m argument of p2m_set_type(). - s/virt_to_page(table)/mfn_to_page(domain_page_map_to_mfn(table)) to recieve correct page for a table which is mapped by domain_page_map(). - Add "return;" after domain_crash() in p2m_set_type() to avoid potential NULL pointer dereference of md_pg. --- 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 | 234 ++++++++++++++++++++++++++++---- 2 files changed, 213 insertions(+), 30 deletions(-) diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h index 1a99e1cf0a3c..48162f5d65cd 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 *pg; + } md; } v; union { diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c index c6de785e4c4b..c40ea483a7cd 100644 --- a/xen/arch/riscv/p2m.c +++ b/xen/arch/riscv/p2m.c @@ -26,6 +26,25 @@ */ #define P2M_MAX_SUPPORTED_LEVEL_MAPPING _AC(2, U) +struct md_t { + /* + * Describes a type stored outside PTE bits. + * Look at the comment above definition of enum p2m_type_t. + */ + p2m_type_t type : 4; +}; + +/* + * 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 p2m_domain *p2m; + 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. */ +}; + static struct gstage_mode_desc __ro_after_init max_gstage_mode = { .mode = HGATP_MODE_OFF, .paging_levels = 0, @@ -37,6 +56,10 @@ unsigned char get_max_supported_mode(void) return max_gstage_mode.mode; } +/* + * If anything is changed here, it may also require updates to + * p2m_{get,set}_type(). + */ static inline unsigned int calc_offset(const struct p2m_domain *p2m, const unsigned int lvl, const paddr_t gpa) @@ -79,6 +102,9 @@ static inline unsigned int calc_offset(const struct p2m_domain *p2m, * The caller is responsible for unmapping the page after use. * * Returns NULL if the calculated offset into the root table is invalid. + * + * If anything is changed here, it may also require updates to + * p2m_{get,set}_type(). */ static pte_t *p2m_get_root_pointer(struct p2m_domain *p2m, gfn_t gfn) { @@ -370,24 +396,94 @@ static struct page_info *p2m_alloc_page(struct p2m_domain *p2m) return pg; } -static int p2m_set_type(pte_t *pte, p2m_type_t t) +/* + * `pte` – PTE entry for which the type `t` will be stored. + * + * If `t` >= p2m_first_external, a valid `ctx` must be provided. + */ +static void p2m_set_type(pte_t *pte, p2m_type_t t, + const struct p2m_pte_ctx *ctx) { - int rc = 0; + struct page_info **md_pg; + struct md_t *metadata = NULL; - if ( t > p2m_first_external ) - panic("unimplemeted\n"); - else - pte->pte |= MASK_INSR(t, P2M_TYPE_PTE_BITS_MASK); + /* + * It is sufficient to compare ctx->index with PAGETABLE_ENTRIES because, + * even for the p2m root page table (which is a 16 KB page allocated as + * four 4 KB pages), calc_offset() guarantees that the page-table index + * will always fall within the range [0, 511]. + */ + ASSERT(ctx && ctx->index < PAGETABLE_ENTRIES && ctx->p2m); - return rc; + /* + * At the moment, p2m_get_root_pointer() returns one of four possible p2m + * root pages, so there is no need to search for the correct ->pt_page + * here. + * Non-root page tables are 4 KB pages, so simply using ->pt_page is + * sufficient. + */ + md_pg = &ctx->pt_page->v.md.pg; + + if ( !*md_pg && (t >= p2m_first_external) ) + { + /* + * Since p2m_alloc_page() initializes an allocated page with + * zeros, p2m_invalid is expected to have the value 0 as well. + */ + BUILD_BUG_ON(p2m_invalid); + + *md_pg = p2m_alloc_page(ctx->p2m); + if ( !*md_pg ) + { + printk("%pd: can't allocate metadata page\n", + ctx->p2m->domain); + domain_crash(ctx->p2m->domain); + + return; + } + } + + if ( *md_pg ) + metadata = __map_domain_page(*md_pg); + + if ( t >= p2m_first_external ) + { + metadata[ctx->index].type = t; + + t = p2m_ext_storage; + } + else if ( metadata ) + metadata[ctx->index].type = p2m_invalid; + + pte->pte |= MASK_INSR(t, P2M_TYPE_PTE_BITS_MASK); + + 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"); + { + const struct md_t *md = __map_domain_page(ctx->pt_page->v.md.pg); + + type = md[ctx->index].type; + + /* + * Since p2m_set_type() guarantees that the type will be greater than + * p2m_first_external, just check that we received a valid type here. + */ + ASSERT(type > p2m_first_external); + + unmap_domain_page(md); + } return type; } @@ -477,7 +573,14 @@ 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) +/* + * If p2m_pte_from_mfn() is called with ctx = NULL, + * it means the function is working with a page table for which the `t` + * should not be applicable. Otherwise, the function is handling a leaf PTE + * for which `t` is applicable. + */ +static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t, + struct p2m_pte_ctx *ctx) { pte_t e = (pte_t) { PTE_VALID }; @@ -485,7 +588,7 @@ static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t, bool is_table) ASSERT(!(mfn_to_maddr(mfn) & ~PADDR_MASK) || mfn_eq(mfn, INVALID_MFN)); - if ( !is_table ) + if ( ctx ) { switch ( t ) { @@ -498,7 +601,7 @@ static pte_t p2m_pte_from_mfn(mfn_t mfn, p2m_type_t t, bool is_table) } p2m_set_permission(&e, t); - p2m_set_type(&e, t); + p2m_set_type(&e, t, ctx); } else /* @@ -518,7 +621,22 @@ static pte_t page_to_p2m_table(const struct page_info *page) * set to true and p2m_type_t shouldn't be applied for PTEs which * describe an intermediate table. */ - return p2m_pte_from_mfn(page_to_mfn(page), p2m_invalid, true); + return p2m_pte_from_mfn(page_to_mfn(page), p2m_invalid, NULL); +} + +static void p2m_free_page(struct p2m_domain *p2m, struct page_info *pg); + +/* + * 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) +{ + if ( tbl_pg->v.md.pg ) + { + p2m_free_page(p2m, tbl_pg->v.md.pg); + tbl_pg->v.md.pg = NULL; + } + p2m_free_page(p2m, tbl_pg); } /* Allocate a new page table page and hook it in via the given entry. */ @@ -679,12 +797,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 *ctx) { unsigned int i; pte_t *table; mfn_t mfn; struct page_info *pg; + unsigned int level = ctx->level; /* * Check if the level is valid: only 4K - 2M - 1G mappings are supported. @@ -700,7 +820,7 @@ static void p2m_free_subtree(struct p2m_domain *p2m, if ( pte_is_mapping(entry) ) { - p2m_type_t p2mt = p2m_get_type(entry); + p2m_type_t p2mt = p2m_get_type(entry, ctx); #ifdef CONFIG_IOREQ_SERVER /* @@ -719,10 +839,22 @@ 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(p2m, 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 = p2m, + }; + + p2m_free_subtree(p2m, table[i], &tmp_ctx); + } unmap_domain_page(table); @@ -734,17 +866,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; @@ -756,6 +884,14 @@ static bool p2m_split_superpage(struct p2m_domain *p2m, pte_t *entry, unsigned int next_level = level - 1; unsigned int level_order = P2M_LEVEL_ORDER(next_level); + struct p2m_pte_ctx p2m_pte_ctx = { + .p2m = p2m, + .level = level, + }; + + /* Init with p2m_invalid just to make compiler happy. */ + p2m_type_t old_type = p2m_invalid; + /* * This should only be called with target != level and the entry is * a superpage. @@ -777,6 +913,17 @@ static bool p2m_split_superpage(struct p2m_domain *p2m, pte_t *entry, table = __map_domain_page(page); + if ( MASK_EXTR(entry->pte, P2M_TYPE_PTE_BITS_MASK) == p2m_ext_storage ) + { + p2m_pte_ctx.pt_page = tbl_pg; + p2m_pte_ctx.index = offsets[level]; + + old_type = p2m_get_type(*entry, &p2m_pte_ctx); + } + + p2m_pte_ctx.pt_page = page; + p2m_pte_ctx.level = next_level; + for ( i = 0; i < P2M_PAGETABLE_ENTRIES(p2m, next_level); i++ ) { pte_t *new_entry = table + i; @@ -788,6 +935,13 @@ 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 ) + { + p2m_pte_ctx.index = i; + + p2m_set_type(&pte, old_type, &p2m_pte_ctx); + } + write_pte(new_entry, pte); } @@ -799,7 +953,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], - next_level, target, offsets); + next_level, target, offsets, page); if ( p2m->clean_dcache ) clean_dcache_va_range(table, PAGE_SIZE); @@ -840,6 +994,9 @@ static int p2m_set_entry(struct p2m_domain *p2m, * are still allowed. */ bool removing_mapping = mfn_eq(mfn, INVALID_MFN); + struct p2m_pte_ctx tmp_ctx = { + .p2m = p2m, + }; P2M_BUILD_LEVEL_OFFSETS(p2m, offsets, gfn_to_gaddr(gfn)); ASSERT(p2m_is_write_locked(p2m)); @@ -890,13 +1047,19 @@ 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 = mfn_to_page(domain_page_map_to_mfn(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) ) { + tmp_ctx.pt_page = tbl_pg; + tmp_ctx.index = offsets[level]; + tmp_ctx.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; @@ -922,6 +1085,10 @@ static int p2m_set_entry(struct p2m_domain *p2m, entry = table + offsets[level]; } + tmp_ctx.pt_page = mfn_to_page(domain_page_map_to_mfn(table)); + tmp_ctx.index = offsets[level]; + tmp_ctx.level = level; + /* * We should always be there with the correct level because all the * intermediate tables have been installed if necessary. @@ -934,7 +1101,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, false); + pte_t pte = p2m_pte_from_mfn(mfn, t, &tmp_ctx); p2m_write_pte(entry, pte, p2m->clean_dcache); @@ -970,7 +1137,7 @@ static int p2m_set_entry(struct p2m_domain *p2m, if ( pte_is_valid(orig_pte) && (!pte_is_valid(*entry) || !mfn_eq(pte_get_mfn(*entry), pte_get_mfn(orig_pte))) ) - p2m_free_subtree(p2m, orig_pte, level); + p2m_free_subtree(p2m, orig_pte, &tmp_ctx); out: unmap_domain_page(table); @@ -1171,7 +1338,14 @@ static mfn_t p2m_get_entry(struct p2m_domain *p2m, gfn_t gfn, if ( pte_is_valid(entry) ) { - *t = p2m_get_type(entry); + struct p2m_pte_ctx p2m_pte_ctx = { + .pt_page = mfn_to_page(domain_page_map_to_mfn(table)), + .index = offsets[level], + .level = level, + .p2m = p2m, + }; + + *t = p2m_get_type(entry, &p2m_pte_ctx); mfn = pte_get_mfn(entry); -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 07 16:37:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 16:37:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1196987.1514677 (Exim 4.92) (envelope-from ) id 1vdWXN-0005Pt-Gk; Wed, 07 Jan 2026 16:37:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1196987.1514677; Wed, 07 Jan 2026 16:37:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdWXN-0005Pm-E3; Wed, 07 Jan 2026 16:37:33 +0000 Received: by outflank-mailman (input) for mailman id 1196987; Wed, 07 Jan 2026 16:37:32 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdWUC-00033L-6o for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 16:34:16 +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 b4632b82-ebe6-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 17:34:15 +0100 (CET) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-b7355f6ef12so431929466b.3 for ; Wed, 07 Jan 2026 08:34:15 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a4cfd97sm531309766b.36.2026.01.07.08.34.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jan 2026 08:34:13 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b4632b82-ebe6-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767803654; x=1768408454; 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=j0do4wU9XAoJGGnLPFw9NPAw9NeZhVzIfXdHI5e2mqY=; b=XFxE+JWp8F0JxVepRe5zD0WlVuYQYYg8siaFppNMDeMF7IKmBYE3Vw6Ay5KK8MX8bo hJ3Wg4QWFIMi9DKmf7+CH3nBWj22A+Q+CvuDfdx4idaGyc8pUumKA3/3agudJP8c5RWV Bkhzj9QN+4EbGQbhX3tpisrz0Lx18OmVQRtGb8eCgRs3Qb2SMlbMbrbPXi+SaRz90TzF PaRv6tJ7njzNXIYcQPez9Tiw3aipYg8AyFGpbObKIQkO2wmQcJeG6W1ASObTuDzEXFyV gIR8L2/Knn+qogYBm1ViNHDvx0PNZlVxi65M0viAEoEUDvUbx7KXV4hqJlm7dc1TdHCb 9sEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767803654; x=1768408454; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=j0do4wU9XAoJGGnLPFw9NPAw9NeZhVzIfXdHI5e2mqY=; b=N53AJNW0xJ7xUQvFIc3p9j8i+FPqRTEbRqpnnbQPmscB1jGmz8sernu24pYonuWDLl qA4eKOP/ZGuLL/sbjDRIp7T+53lzNwmPQBMrxcYugKs2BPFTF73Pq1AoK2mIAKlUbnE6 4TKkapI/r0o4HkSJv/lI9gzNE8Wb/HEalsDpMkcVAxZOeNYTKm1eJSGGxd8IEMB1OfRi ACFBXTXK2Jbj3FSF6X4Z5eoZaAFYdXctyuI0U1oEKVq6ukl9xLTmXam4i6UQdyX3EROB 0ooYFbv0ZW4tyFgDaw7esBwAN76fSRaBR/gfrfBlF9UBxZTLvqftpidytrugfP8DFWav cOEg== X-Gm-Message-State: AOJu0YxR+5dC1RpE9xMTNcvb6MwoKymAw2irNZ56WeUQ+nipaG6JmbRm nG5i+16CvuQlmZGcveSwYCK6/3UQeV4lwQFxqkqNg/NXJZy1dL/Iwixhu4+tyw== X-Gm-Gg: AY/fxX74eRqTQ5S7QrMFvJ5pVGcIkr5NH5gicXUwWA+xNuJqCLJ0E4nGv78id0qXDm+ Edbkqyd2ANX1BphjMFHWpIi3uDCa1WQYZ2iwvYa5SRKludsE5GU77T7OwZk9GmpLbccHEQYn4XJ RrWhV0ooMiELpHnHQh6luHfiCrt5U75Zw5sCOX+8Oiuf41m6XPvb+zIw8YUm1D7Hg4ZNOOL0vsC LYZPmyZ3xD8QEhAPIbcYLCoPB39LhUIZiJzV3WdU/YntURtrETwpt2xJkUQmHAD+niPYbk12I5O Ld32h2nXlanFaOfuDQXnvIsLA3C0bvHqysSMxcTaVyN8dqT9g5+9xdRJQGQ7gMmCzRyGJFpUNBt YjQBOX48Ha6es6GdUDXhPYzTI98MfnqtbzCadolemvRTLCYHVFErpjRv1MCVrtRMWyZP6NXO5KS OEp798l+X/w542wn+8EnndSZuILErYhkO/EjRc7VIRHnc7ulW7nbhmAuPikRMVwQoh X-Google-Smtp-Source: AGHT+IGTQNpEB2UwZwEuxMVMqHBoasEhnCwPI96dDmnCa/v0k8qb6hQy0agIRqMVqWuLLGrXCJx9dA== X-Received: by 2002:a17:907:7283:b0:b83:1327:5f88 with SMTP id a640c23a62f3a-b84451da312mr317379666b.16.1767803654204; Wed, 07 Jan 2026 08:34:14 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Yann Dirson , Yann Sionneau Subject: [PATCH v2] acpi/arm: relax MADT GICC entry length check to support newer ACPI revisions Date: Wed, 7 Jan 2026 17:34:02 +0100 Message-ID: <3850c51d41b1ab67a453ca70c0a44172185274f6.1767694781.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Newer ACPI revisions define the MADT GICC entry with Length = 82 bytes [1]. The current BAD_MADT_GICC_ENTRY() check rejects entries whose length does not match the known values, which leads to: GICv3: No valid GICC entries exist. as observed on the AmpereOne platform. To fix this, import the logic from Linux commit 9eb1c92b47c7: The BAD_MADT_GICC_ENTRY check is a little too strict because it rejects MADT entries that don't match the currently known lengths. We should remove this restriction to avoid problems if the table length changes. Future code which might depend on additional fields should be written to validate those fields before using them, rather than trying to globally check known MADT version lengths. Link: https://lkml.kernel.org/r/20181012192937.3819951-1-jeremy.linton@arm.com Signed-off-by: Jeremy Linton [lorenzo.pieralisi@arm.com: added MADT macro comments] Signed-off-by: Lorenzo Pieralisi Acked-by: Sudeep Holla Cc: Will Deacon Cc: Catalin Marinas Cc: Al Stone Cc: "Rafael J. Wysocki" Signed-off-by: Will Deacon As ACPI_MADT_GICC_LENGTH is dropped, update the functions where it is used. As we rewrite the MADT for hwdom, reuse the host GICC header length instead of ACPI_MADT_GICC_LENGTH. [1] https://uefi.org/specs/ACPI/6.6/05_ACPI_Software_Programming_Model.html#gic-cpu-interface-gicc-structure Reported-By: Yann Dirson Co-developed-by: Yann Sionneau Signed-off-by: Oleksii Kurochko Reviewed-by: Stefano Stabellini --- I ran CI tests where it made sense for this patch, as I don’t see any CI job that builds Xen with CONFIG_ACPI=y: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/2229673951 I also built Xen manually with CONFIG_ACPI=y enabled and tested it on the AmpereOne platform. --- Changes in v2: - Update the commit message: - Use more characters for commit ID. - Drop 'import from'. - Add Reviewed-by: Stefano Stabellini . - Make the local variables host_gicc const in gic_get_hwdom_madt_size(). (header variable isn't const as container_of() will discard 'const' qualifier and so compilation error will occur). - Return 0 instead of panic() in gic_get_hwdom_madt_size(). --- xen/arch/arm/acpi/domain_build.c | 6 ++++++ xen/arch/arm/gic-v2.c | 3 ++- xen/arch/arm/gic-v3.c | 3 ++- xen/arch/arm/gic.c | 12 +++++++++++- xen/arch/arm/include/asm/acpi.h | 21 +++++++++++++++------ 5 files changed, 36 insertions(+), 9 deletions(-) diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c index 1c3555d814cc..959698d13ac3 100644 --- a/xen/arch/arm/acpi/domain_build.c +++ b/xen/arch/arm/acpi/domain_build.c @@ -458,6 +458,12 @@ static int __init estimate_acpi_efi_size(struct domain *d, acpi_size += ROUNDUP(sizeof(struct acpi_table_stao), 8); madt_size = gic_get_hwdom_madt_size(d); + if ( !madt_size ) + { + printk("Unable to get hwdom MADT size\n"); + return -EINVAL; + } + acpi_size += ROUNDUP(madt_size, 8); addr = acpi_os_get_root_pointer(); diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index b23e72a3d05d..aae6a7bf3076 100644 --- a/xen/arch/arm/gic-v2.c +++ b/xen/arch/arm/gic-v2.c @@ -1121,7 +1121,8 @@ static int gicv2_make_hwdom_madt(const struct domain *d, u32 offset) host_gicc = container_of(header, struct acpi_madt_generic_interrupt, header); - size = ACPI_MADT_GICC_LENGTH; + size = host_gicc->header.length; + /* Add Generic Interrupt */ for ( i = 0; i < d->max_vcpus; i++ ) { diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c index bc07f97c16ab..75b89efad462 100644 --- a/xen/arch/arm/gic-v3.c +++ b/xen/arch/arm/gic-v3.c @@ -1672,7 +1672,8 @@ static int gicv3_make_hwdom_madt(const struct domain *d, u32 offset) host_gicc = container_of(header, struct acpi_madt_generic_interrupt, header); - size = ACPI_MADT_GICC_LENGTH; + size = host_gicc->header.length; + for ( i = 0; i < d->max_vcpus; i++ ) { gicc = (struct acpi_madt_generic_interrupt *)(base_ptr + table_len); diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index ee75258fc3c3..e22feb46f5d4 100644 --- a/xen/arch/arm/gic.c +++ b/xen/arch/arm/gic.c @@ -418,8 +418,18 @@ unsigned long gic_get_hwdom_madt_size(const struct domain *d) { unsigned long madt_size; + struct acpi_subtable_header *header; + const struct acpi_madt_generic_interrupt *host_gicc; + + header = acpi_table_get_entry_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT, 0); + if ( !header ) + return 0; + + host_gicc = container_of(header, struct acpi_madt_generic_interrupt, + header); + madt_size = sizeof(struct acpi_table_madt) - + ACPI_MADT_GICC_LENGTH * d->max_vcpus + + host_gicc->header.length * d->max_vcpus + sizeof(struct acpi_madt_generic_distributor) + gic_hw_ops->get_hwdom_extra_madt_size(d); diff --git a/xen/arch/arm/include/asm/acpi.h b/xen/arch/arm/include/asm/acpi.h index 13756dd341b4..30bc446d1f75 100644 --- a/xen/arch/arm/include/asm/acpi.h +++ b/xen/arch/arm/include/asm/acpi.h @@ -53,13 +53,22 @@ void acpi_smp_init_cpus(void); */ paddr_t acpi_get_table_offset(struct membank tbl_add[], EFI_MEM_RES index); -/* Macros for consistency checks of the GICC subtable of MADT */ -#define ACPI_MADT_GICC_LENGTH \ - (acpi_gbl_FADT.header.revision < 6 ? 76 : 80) +/* + * MADT GICC minimum length refers to the MADT GICC structure table length as + * defined in the earliest ACPI version supported on arm64, ie ACPI 5.1. + * + * The efficiency_class member was added to the + * struct acpi_madt_generic_interrupt to represent the MADT GICC structure + * "Processor Power Efficiency Class" field, added in ACPI 6.0 whose offset + * is therefore used to delimit the MADT GICC structure minimum length + * appropriately. + */ +#define ACPI_MADT_GICC_MIN_LENGTH ACPI_OFFSET( \ + struct acpi_madt_generic_interrupt, efficiency_class) -#define BAD_MADT_GICC_ENTRY(entry, end) \ - (!(entry) || (unsigned long)(entry) + sizeof(*(entry)) > (end) || \ - (entry)->header.length != ACPI_MADT_GICC_LENGTH) +#define BAD_MADT_GICC_ENTRY(entry, end) \ + (!(entry) || (entry)->header.length < ACPI_MADT_GICC_MIN_LENGTH || \ + (unsigned long)(entry) + (entry)->header.length > (end)) #ifdef CONFIG_ACPI extern bool acpi_disabled; -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 07 16:55:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 16:55:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197011.1514687 (Exim 4.92) (envelope-from ) id 1vdWoH-0008Q3-Sp; Wed, 07 Jan 2026 16:55:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197011.1514687; Wed, 07 Jan 2026 16:55: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 1vdWoH-0008Pw-Pm; Wed, 07 Jan 2026 16:55:01 +0000 Received: by outflank-mailman (input) for mailman id 1197011; Wed, 07 Jan 2026 16:55: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 1vdWoF-0008Pf-Ut for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 16:55:00 +0000 Received: from mail187-9.suw11.mandrillapp.com (mail187-9.suw11.mandrillapp.com [198.2.187.9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9875ba4b-ebe9-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 17:54:57 +0100 (CET) Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail187-9.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4dmYzz6BkQzK5vgL6 for ; Wed, 7 Jan 2026 16:54:55 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 6e096f620aff42e18a629b6854069a69; Wed, 07 Jan 2026 16:54: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: 9875ba4b-ebe9-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1767804895; x=1768074895; bh=thHUAzP1js0oVbJpysXtYKJfwX2p4bisZFhZB3P7Ygk=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=zevoEF3pYz5Hu4ejbm+pR7lbMR+6LTJdDtd97L2Mybp1VPsrkLBsXutzMCnP423oK A4rpkT8WTMzs1fGRzuq1ZcaFTv1D2qMxFbPBiCaSNJ7O8c64Qk8BvNp56aSYCVgBLo 180EN+GyKS9oAjWYxzWQHSmXVZTrxD7kFmdDJu+1YFmod6SMj+hZyINtsjNUaZ8Mil 1c+wgfQ7TLLiRwmLW7EvcQm/zc2WfzxcK8Nru8tT2potSrXRd/2USyCzwU5T1/fJeJ izVb/XucnR1BsSoiX/lMoccH2ZlNzm3BJbgdYdurBNxZNm4s00cu/+tUYvc/WwQkAm FxX10ajnv2t3Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1767804895; x=1768065395; i=teddy.astie@vates.tech; bh=thHUAzP1js0oVbJpysXtYKJfwX2p4bisZFhZB3P7Ygk=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=lnLZRWTwIqjmAF9gyZx8fIMiQ2UfJJH+CNyqTDa2nPgKIpuhhyVRH5MhJO0npj2Wa 5WDqglDJx0XVA4t8VP1HPxNCl0OTP7low2gdVLk6Rmgf1D2iRGfE/cnOl9bRRe8HHO bRis/tgzkeKYcH8Xybq3W3jjIVJR7IYaF9y+hq3QMZsvFnALsuqSdkqfKiq56VasbY ZsX76zoioZnMsJHJcue8rakVckhl4cIuOEBNV/qdXzcBQKSDYr4YXzGlOtbObV8qBH ZaLhowHGNX+u+ZatYYv0ZukzncKrUlr1aMtxKodVzhr9gzHcQy6DFGqhjsPWw8gg7t 1bkZU6/DgHdTg== From: "Teddy Astie" Subject: =?utf-8?Q?[PATCH=20v1=200/2]=20x86/pci:=20MMCFG=20improvements=20and=20always=20use=20it=20if=20available?= X-Mailer: git-send-email 2.52.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1767804894854 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.6e096f620aff42e18a629b6854069a69?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260107:md Date: Wed, 07 Jan 2026 16:54:55 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Currently, Xen uses legacy method to access the configuration space unless the access cannot be made with it, where Xen fallbacks to MMCFG. This is not really great, as MMCFG is more flexible and doesn't require a dedicated lock, so it would be preferable to use it whenever possible. Teddy Astie (2): x86/pci: Improve pci_mmcfg_{read,write} error handling x86/pci: Prefer using mmcfg for accessing configuration space xen/arch/x86/x86_64/mmconfig_64.c | 10 +++--- xen/arch/x86/x86_64/pci.c | 52 ++++++++++++++----------------- 2 files changed, 28 insertions(+), 34 deletions(-) -- 2.52.0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Wed Jan 07 16:55:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 16:55:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197013.1514699 (Exim 4.92) (envelope-from ) id 1vdWoI-0008WN-DO; Wed, 07 Jan 2026 16:55:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197013.1514699; Wed, 07 Jan 2026 16: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 1vdWoI-0008V9-6P; Wed, 07 Jan 2026 16:55:02 +0000 Received: by outflank-mailman (input) for mailman id 1197013; Wed, 07 Jan 2026 16:55: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 1vdWoG-0008Pf-JV for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 16:55:00 +0000 Received: from mail132-4.atl131.mandrillapp.com (mail132-4.atl131.mandrillapp.com [198.2.132.4]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 98f6e935-ebe9-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 17:54:58 +0100 (CET) Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail132-4.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4dmZ001jfGzlfh3m for ; Wed, 7 Jan 2026 16:54:56 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 69d9506fa8e44d5ea0d5c68a30f8e736; Wed, 07 Jan 2026 16:54: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: 98f6e935-ebe9-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1767804896; x=1768074896; bh=dvpM8KfreT681wQu18BQ2I0ULSna7H2R9oVtTe2ENm4=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=e8EAewOz0fErJtY7w8S95VOq2xku94JGgLX3q5ZZ2OWilXm7DlrI/nnIQR79W8+go CTeM76XNZGxI9XM3JgKgB90wgwiufLKHcMEKV5nIX95XAu3YxS6SScaVzasFAGgwHp Kz38CC3Q+5xNeIZDkpJN9Zc78EYS1wCTj64YnhjF5IkwUCG4wWo3WQ4TVMH9ecihTd 0BMZy7SmIZxnEQnGFzw1cpU1H6Cr6aVFkTQOisA2nQmScDu68HTTG0kLHQJrzIPDR3 Cch3U6idTIzDIr9lbLlcLJF+LVdUZ7bUjW6fq7K041q4mbAPuPllejyi3R0qfXjjfp 20pvYpyuexZ8Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1767804896; x=1768065396; i=teddy.astie@vates.tech; bh=dvpM8KfreT681wQu18BQ2I0ULSna7H2R9oVtTe2ENm4=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=qpqNwKDxqFkws5MglGsiYHva3+IMoi9VsGzWj2g2czJ2lLaSNfIlQeoId7KXKQniA U2ooEGKbCzsKkQlROcmwfvEuwrUKMrhfyDuHT7xBqWJCKPvZEbZ8HltJ69JbVRdeXF C8WGqltiCZLr/bwCZLzVfWkx82n3TXJDW72P5+GX/R78yrypqM4p+ldh3NwpbRbZAp R+CIna8O08CL9i9Tu5X37QUjpUxvTyV0Yr7Gj+w2EWJn0JVlRIL3XmugdVA3cGWZL/ Xx/JkyGcMiGy3zzdq15N1hQ1fxdEjipZi1R6BnZseJJ7C2cR0Q+cefI1LptcCTjmcs SRpJstzfncccg== From: "Teddy Astie" Subject: =?utf-8?Q?[PATCH=20v1=201/2]=20x86/pci:=20Improve=20pci=5Fmmcfg=5F{read,write}=20error=20handling?= X-Mailer: git-send-email 2.52.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1767804895192 To: xen-devel@lists.xenproject.org Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" Message-Id: <1042a6163ae71527987a853e3c746c8a6633c0ee.1767804090.git.teddy.astie@vates.tech> In-Reply-To: References: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.69d9506fa8e44d5ea0d5c68a30f8e736?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260107:md Date: Wed, 07 Jan 2026 16:54:56 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return -ENODEV in case no mmcfg information is available instead of -EINVAL, that is also returned when the parameters are incorrect. It helps us distinguish between incorrect usage and no MMCFG support. Signed-off-by: Teddy Astie --- xen/arch/x86/x86_64/mmconfig_64.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/x86_64/mmconfig_64.c b/xen/arch/x86/x86_64/mmconfig_64.c index ffdc62700d..1a2803d2a3 100644 --- a/xen/arch/x86/x86_64/mmconfig_64.c +++ b/xen/arch/x86/x86_64/mmconfig_64.c @@ -60,15 +60,15 @@ int pci_mmcfg_read(unsigned int seg, unsigned int bus, { char __iomem *addr; + *value = -1; + /* Why do we have this when nobody checks it. How about a BUG()!? -AK */ - if (unlikely((bus > 255) || (devfn > 255) || (reg > 4095))) { -err: *value = -1; + if ( unlikely((bus > 255) || (devfn > 255) || (reg > 4095)) ) return -EINVAL; - } addr = pci_dev_base(seg, bus, devfn); if (!addr) - goto err; + return -ENODEV; switch (len) { case 1: @@ -96,7 +96,7 @@ int pci_mmcfg_write(unsigned int seg, unsigned int bus, addr = pci_dev_base(seg, bus, devfn); if (!addr) - return -EINVAL; + return -ENODEV; switch (len) { case 1: -- 2.52.0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Wed Jan 07 16:55:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 16:55:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197012.1514693 (Exim 4.92) (envelope-from ) id 1vdWoI-0008Sx-5G; Wed, 07 Jan 2026 16:55:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197012.1514693; Wed, 07 Jan 2026 16: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 1vdWoH-0008Rm-Vc; Wed, 07 Jan 2026 16:55:01 +0000 Received: by outflank-mailman (input) for mailman id 1197012; Wed, 07 Jan 2026 16:55: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 1vdWoG-0008Pk-HC for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 16:55:00 +0000 Received: from mail132-4.atl131.mandrillapp.com (mail132-4.atl131.mandrillapp.com [198.2.132.4]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 98f3754a-ebe9-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 17:54:58 +0100 (CET) Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail132-4.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4dmZ003Z0yzlfk13 for ; Wed, 7 Jan 2026 16:54:56 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 4b6fc8b114c14eb3aa834fc567d9a59e; Wed, 07 Jan 2026 16:54: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: 98f3754a-ebe9-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1767804896; x=1768074896; bh=GaUw0s07s4BUFWE/xvZWFDAom+ukE1VoOC1T4wtN5q8=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=x+Xb3K69hbuQW7YnvMdLTJNYJm8fF3sm6H2MO+ZVZqSrh7jRl2Qgj/N+Dv5BVqs5s DkXmgmPtdlHYUUTlBwfMP1zTKgpUxc4v6ZohghNyq6EaRH+poyTVd7mEYFAYWhCtmu hCi+IUHWfDXYy3MNlt5cfc8ZeyLGT7EqdoGz+7pY3BdBz8gdqKiA1RNdkb9QJir9k8 bLl/Ao2gzRH9busfvwBuL2P3+b6h+LaJK/u/BetvXEtxAsx2I7tCFNxqx7b67ugZYD uT+9o4EnmKEeDc9bfV55ZKG9CR5YLrP1bMwvXVprsamsP8V4ZT2zeVIYFeENnIa5X9 k/gDTBZKn6R/Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1767804896; x=1768065396; i=teddy.astie@vates.tech; bh=GaUw0s07s4BUFWE/xvZWFDAom+ukE1VoOC1T4wtN5q8=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=NNKwyWi7me6a3GkyHeVCJi3aYdOuyppU1hG6cOKVVMrWHcslWdbovjGZXG8JF4oeF f38FI34C+copDbvmpMuxWz5gkbb4/0Z05mNt3GKLL41LY2NgbYWvapGvRxrmAXHbB1 IFIWzFfcaSUV8DrHfR0ZS2WDp30bsPBVFIxte4nUTXjMLU6d2hg96bEOktbgqfHcZB NorohMrlq/rh3g4CdKmR05/9YTBYA43G8NA+sDfk1LvG0yiCBo3q9eCrS3JUPkebs7 kgSuCDQ+97XG5mdZHKVeL/yBqfaYibEf5liczsZYZtSkwuFP5pDrKOwTyLr6z8QM58 7vq28euP6L7Aw== From: "Teddy Astie" Subject: =?utf-8?Q?[PATCH=20v1=202/2]=20x86/pci:=20Prefer=20using=20mmcfg=20for=20accessing=20configuration=20space?= X-Mailer: git-send-email 2.52.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1767804895542 To: xen-devel@lists.xenproject.org Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" Message-Id: <27c85c2cded576b3d5253c6e182e24341201c3ea.1767804090.git.teddy.astie@vates.tech> In-Reply-To: References: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.4b6fc8b114c14eb3aa834fc567d9a59e?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260107:md Date: Wed, 07 Jan 2026 16:54:56 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Current logic prefer using CFC/CF8 and fallbacks on mmcfg when accessing >255 registers or a non-zero segment. Change the logic to always rely on mmcfg unless it is not available to avoid locking on pci_config_lock if possible. Signed-off-by: Teddy Astie --- Are there x86 platforms where MMCFG is the only way to access PCI configuration space ? xen/arch/x86/x86_64/pci.c | 52 +++++++++++++++++---------------------- 1 file changed, 23 insertions(+), 29 deletions(-) diff --git a/xen/arch/x86/x86_64/pci.c b/xen/arch/x86/x86_64/pci.c index 8d33429103..3b3df8014d 100644 --- a/xen/arch/x86/x86_64/pci.c +++ b/xen/arch/x86/x86_64/pci.c @@ -14,62 +14,56 @@ uint8_t pci_conf_read8(pci_sbdf_t sbdf, unsigned int reg) { uint32_t value; + int ret = pci_mmcfg_read(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 1, &value); - if ( sbdf.seg || reg > 255 ) - { - pci_mmcfg_read(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 1, &value); - return value; - } + if ( unlikely(ret == -ENODEV) && !sbdf.seg && reg <= 255 ) + return pci_conf_read(PCI_CONF_ADDRESS(sbdf, reg), reg & 3, 1); - return pci_conf_read(PCI_CONF_ADDRESS(sbdf, reg), reg & 3, 1); + return value; } uint16_t pci_conf_read16(pci_sbdf_t sbdf, unsigned int reg) { - if ( sbdf.seg || reg > 255 ) - { - uint32_t value; + uint32_t value; + int ret = pci_mmcfg_read(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 2, &value); - pci_mmcfg_read(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 2, &value); - return value; - } + if ( unlikely(ret == -ENODEV) && !sbdf.seg && reg <= 255 ) + return pci_conf_read(PCI_CONF_ADDRESS(sbdf, reg), reg & 2, 2); - return pci_conf_read(PCI_CONF_ADDRESS(sbdf, reg), reg & 2, 2); + return value; } uint32_t pci_conf_read32(pci_sbdf_t sbdf, unsigned int reg) { - if ( sbdf.seg || reg > 255 ) - { - uint32_t value; + uint32_t value; + int ret = pci_mmcfg_read(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 4, &value); - pci_mmcfg_read(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 4, &value); - return value; - } + if ( unlikely(ret == -ENODEV) && !sbdf.seg && reg <= 255 ) + return pci_conf_read(PCI_CONF_ADDRESS(sbdf, reg), 0, 4); - return pci_conf_read(PCI_CONF_ADDRESS(sbdf, reg), 0, 4); + return value; } void pci_conf_write8(pci_sbdf_t sbdf, unsigned int reg, uint8_t data) { - if ( sbdf.seg || reg > 255 ) - pci_mmcfg_write(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 1, data); - else + int ret = pci_mmcfg_write(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 1, data); + + if ( unlikely(ret == -ENODEV) && !sbdf.seg && reg <= 255 ) pci_conf_write(PCI_CONF_ADDRESS(sbdf, reg), reg & 3, 1, data); } void pci_conf_write16(pci_sbdf_t sbdf, unsigned int reg, uint16_t data) { - if ( sbdf.seg || reg > 255 ) - pci_mmcfg_write(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 2, data); - else + int ret = pci_mmcfg_write(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 2, data); + + if ( unlikely(ret == -ENODEV) && !sbdf.seg && reg <= 255 ) pci_conf_write(PCI_CONF_ADDRESS(sbdf, reg), reg & 2, 2, data); } void pci_conf_write32(pci_sbdf_t sbdf, unsigned int reg, uint32_t data) { - if ( sbdf.seg || reg > 255 ) - pci_mmcfg_write(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 4, data); - else + int ret = pci_mmcfg_write(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 4, data); + + if ( unlikely(ret == -ENODEV) && !sbdf.seg && reg <= 255 ) pci_conf_write(PCI_CONF_ADDRESS(sbdf, reg), 0, 4, data); } -- 2.52.0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Wed Jan 07 17:22:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 17:22:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197047.1514716 (Exim 4.92) (envelope-from ) id 1vdXEf-0005Rk-At; Wed, 07 Jan 2026 17:22:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197047.1514716; Wed, 07 Jan 2026 17:22:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdXEf-0005Rd-88; Wed, 07 Jan 2026 17:22:17 +0000 Received: by outflank-mailman (input) for mailman id 1197047; Wed, 07 Jan 2026 17:22: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 1vdXEe-0005RX-18 for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 17:22:16 +0000 Received: from SA9PR02CU001.outbound.protection.outlook.com (mail-southcentralusazlp170130001.outbound.protection.outlook.com [2a01:111:f403:c10c::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 68652112-ebed-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 18:22:15 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DS7PR03MB5493.namprd03.prod.outlook.com (2603:10b6:5:2cb::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Wed, 7 Jan 2026 17:22:10 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.002; Wed, 7 Jan 2026 17:22: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: 68652112-ebed-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=l+Xq+h+dOngc8N6IMxYRWxqF7csN5yjsAYx1p8E7y/nOWM5eUa1FW8yt/0oSOR46U5tJouFetzCyYfRQ2/1hgfCcvL76N3qjS/xakm25cUldqLTPQV6ckzDkP679OTjUR8KnJI6melzRaaWPNnxZz1Ad6trB3VYGNKeezHg9kRg3duT3scYDb1KaNEDYkTk8CfaoKi00y9+Gu60LBMTyyUlEdcXyHuVe25Q/Ma+q4X5tBp2NjO9Q9VzXBRifUUxOe0kmtigdQfSj7+sEIRsu3o2Zqwz7h/o9Du1UCTZ3WevaBq8KHSsL7NYI0Zimk1OZcdbVbC9Ba0HrS+cnXd339g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YPYlnYbBbiSiGYzw8Mr7Ua51lO3OKfKwABQ+pvjgi5U=; b=WAEKBmdUeHayUNxFWTlS9I3AqnYgvBEQ/5bOcbxqeNirFqWebR3aO5dwN4ASKaSL7jMpoMkjhMPAEj25sG/c7Ulq96k90sNh2K2tqqLIYCLhap8yA65FQiEOYu0huXB298G8yhQhLkfkC2OpuP4dGYGMXFJE5dltO1fZMjNrP3ZynWeal8L6Xh/17PrmwSyukac32ByXLheuyYYnqvR7KY4k11dBuJvy8hHd6cvyTJiM0V4qZFnxa/9t4cRljW6FgCNFbscO86Kk73mAvb8o5SK/YUNxcPOKhRjtfSE/mnq8gmB2DLxGh6DuhI5fuLdrsF2EakwNWuAPa/HXME6C/Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YPYlnYbBbiSiGYzw8Mr7Ua51lO3OKfKwABQ+pvjgi5U=; b=WsRfm6YjY8lufbPfv+Qwbvh18WM7HHYgrHp3bS3DmgLvUIx9nmoOZbkEjyLMNL86bWh9jvGKY4VyRWsdHFbEmks61TK+p7PVHeEqncx5q/uO1KwdYiL/GgoqZ+DqwqskjE6R142YLZgfOWqDmyGCCEHqdwOZ5j3pPRPt1JlVluY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 7 Jan 2026 18:22:05 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Teddy Astie Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper Subject: Re: [PATCH v1 0/2] x86/pci: MMCFG improvements and always use it if available Message-ID: References: Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: PA7P264CA0372.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:37c::29) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DS7PR03MB5493:EE_ X-MS-Office365-Filtering-Correlation-Id: 69ec1295-aa52-4369-8103-08de4e114a01 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?T3hVcGxJdERkeXpQVWpVTGlGaGRRaFJNQmFyTXNpUXBHcm5TdFllSFBBVWhX?= =?utf-8?B?Tk1WZVJMS1p6U3RPbjliQ0tpR2hnRFFjaHplOEZLWkl1ZWNmdTh1eit4WmY2?= =?utf-8?B?Yy9vak9EMXJlRGpybDFENHh3R0JVRFhqWEtnb09Tb3p2T3A0c3JGbjhIRUJJ?= =?utf-8?B?NENubHZWYnQ1R1A0MElBekQwdVFieDc3Y2tvbnd5UWxXM2gzdmZHNmRMN3NR?= =?utf-8?B?RUJCOGdYSjRXcld4U1FONDYzUW50N0dOeG56blpPOExvaVJ6K2Yza0RxK3lL?= =?utf-8?B?RkpkZDM5OTlUdzgzVi9tZHMvNjdrK1EwbVpTUXpTalZGVUVSN0hWWURidUhi?= =?utf-8?B?SGRFczBzK1BVUGJCR0J0bzZGSjBuaHdwSStMenN5OUdmcks2S1N4T2g3ZEtt?= =?utf-8?B?NHc4VTVMRTMxRGZlUnJkczRuZjgrQWpyTVJGVEY3YXVWdUdjWGVySVZTYVFU?= =?utf-8?B?cTM4bnZOSE1WMm1jU2lEVm82TWdWV1BNQy9RNDJuN1J0K1RKYTZ2aTVKbzF6?= =?utf-8?B?dGlHQWVqM25Rbk0rTEZQcmplWktKWTByZ3ZQVHl0UEVzcW9pQ0hFRlVGVGtw?= =?utf-8?B?RG5sTjZnSFFhWnl5akNQeE9EQ2JXbDJYREU4MFJlQ0FXRGxoSVJaeWM2NmJQ?= =?utf-8?B?Q2xuZ3pzK2VleUVJbXdwNHFhK05ZM1lKc1U2a1FnNXorSE8waDQrTFp1WEtS?= =?utf-8?B?Y3FJcmNBTXpYM2N4RlJoOWI5UGNINlNPOEFzZDR2VzBNQktzVWRlUmErajNy?= =?utf-8?B?THQ0VVh4enFxakNlbDdYN25MTVorMUtoRmtNSVlHQWdObkFyenl1c0JENTMy?= =?utf-8?B?ZU1VRFFFamlaYkI2d20yQm1HVkZ4N1o2Wlp0RlVTVk9rcE41Mm4rbjY5bmJY?= =?utf-8?B?NGZ4RHVlcDNqNkVwQ2VObS93NDVjRzdYRVRUblQzOWVpNHlDdWVkeXZwbktJ?= =?utf-8?B?ckQrY2ZJSE1nT3lLWE1JYWt2cVNjTEpSeVMvU3Z6TmFuS09Iem5rVGFSTmwx?= =?utf-8?B?eUtDd1VvRmNVK1RpayttM2hXS3Byc0JnbFd4bW5HSjBFaGNNczRBT3RoL2V0?= =?utf-8?B?b29qU05wV3IrcHJjYzVOZlhkTEc4aGVWeTVEZU5wVnVJTjVDb1Nnbm9nSXQz?= =?utf-8?B?SzNJNU95MlRhYlYzUFdyRVptcVNZbmV5dHhtU3Foa2FCc0o1NFcwNk81ZEpU?= =?utf-8?B?ci8ycU1pa1ZESkhQbDlvVG1zQmRwbWJIVGhad05hRU1FSXRvcW9ZV2FLUGox?= =?utf-8?B?Rll4NlYrSjFmendPWWh5azRYSzk3bCthV3lHeWxYczNnSy9vYXY3YlA2YkpD?= =?utf-8?B?VFJzWVUxVStidE9mNkFPYkQwTTV0a0VBTllWUFdDS0Z2bGFsNkdmZ0dhQmpO?= =?utf-8?B?Mko1R0UvRm13RkdxdWVIaHJuQ1ZsZlZ0Q3hHbVVlNDIvWDdFWldDZUEzdllp?= =?utf-8?B?Z2ZVcm9ZTFVPaGVhOXVDTjBIZGFKM2JJN2pmZHJvZjZrdXE3UFBzcVlJdjQ1?= =?utf-8?B?bktXUVppcHU2Q0tTZk00OXNNOFZUdjFPa0hOdTd1T09tV2w5RmczemoycXZE?= =?utf-8?B?VDU0Z2w2bGhmYnBYRTYxVzZxbC9yTXR2MUN4NnV4ZkZYT0djZVBKZWFWUzg0?= =?utf-8?B?YmpmWDc0Mk1la2FIenc4NFkrT210UW9tRk9IMCtTQk52UUVlZTV5UjlsZGs0?= =?utf-8?B?ZlQyMlYvZEg3cytHL24xS3dpWU9mdFhEWUNPQnZpQzg5alV1VlVxQllaWmRo?= =?utf-8?B?V1NrcENXZ0NIckQzV1d0aVRYeVA3RW9wdmZ1dUhwRThDdWFHTFJxMzF2K1gv?= =?utf-8?B?QWZmU1dkSnE0Y3lZenNyNk5Hblk4MlloU1VZMVBvUHE0NlUra3ZsRUdOT3M2?= =?utf-8?B?Q3pmeU9pdlZadzJUS3JaQXEvblJUaUl6bnFOWEtxQTFlNHhPSFNySktqRksz?= =?utf-8?Q?bGG/kyAWVOiZ9qH1lC0tfguYNO/5Skg2?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZTBYT2tPc2pTTzV0R1lkSUk2dWVDV3Z6bGlpYzd1MGZOWXlLaVVXaEVOeGM1?= =?utf-8?B?empBYjBKY242cThqQ3FmaFlEZURuZWx5ODBibHU1Y0o1dVMxUmdTNXlaR1ZK?= =?utf-8?B?ZDdMVUxJcTg1aFBUYmpyUjVjVVp0RXk3aHFOczNkSlRwZTdLaE9ZQ3BVaGgw?= =?utf-8?B?SVo1RkVMS0xZVmRYYzI2K1FmZk10UHkwRGFDRUVQTWtJamRaeXNSR3hmdXB5?= =?utf-8?B?a0hYeTNXUlBGRnR6Q2FTb003aTZCbGdRY1MxaG42dWF1MElOdCt6dUVPcDFX?= =?utf-8?B?NG1HcXVScGZmVW8vRU5rNWNxaTFOQXE0eXVWSm9HUWRDOUJwNGp1c0RNT1lk?= =?utf-8?B?bGxydHN6Vk1UZC9XMGtPNTdlT1pKVG9KcVBaeW1obytPNE5sNGJEa2FDWms2?= =?utf-8?B?QXQ0L3AwTy9YcGdScDFZRTZlV2Qvam5SOGFYaDg3MjFRMmpsVFRZc2RROTZM?= =?utf-8?B?aCtwbC9sdGJocDZUUWFLVTdIUmlwRnJnS0haNTZ0Q3NONERGYm1YY05GWFQx?= =?utf-8?B?dnhNMGV4ckJGbjFBQzRDQ3lqdDRiN1M0ZjJSSzJHUlNaVTJZOXlXbFk3RU11?= =?utf-8?B?bE9tMlc0amMvbklzT1huaTdiZ3drQnpwQUhmdE1HdHU0WENDa1dMeXhGc0RQ?= =?utf-8?B?empKVHZ4cW9EQlRNaDNzQ25tOG9sZ3VabmJvZFliMGhlK0QxdnhFR1dUTDU5?= =?utf-8?B?anF2V1lPSmxmQlRRaHlrWis5SWRXbEpQbTdkeWUwSVBsUjNZQmZTdi9XTFJj?= =?utf-8?B?MHdIMU9TQ2Njd25wSTBJaUtmWGFqSkNMRUxkM0FQcW5XQnVNR3pQSWpuY05w?= =?utf-8?B?ZlI2aHBhMGIrWiszRUpDOVZhYU9GM1NtajI2RHk4SmhXUW1WSW5TS002STVR?= =?utf-8?B?TXhRVkNvSE1nek81NHdQM3htSU1wL2ZPOENXMFVzcFY0a0w0ZXdIYTVTWHpV?= =?utf-8?B?SlJkcGsvQ2VmYXFicDY3Tndia3h4M2xjVHhZU2Z2UnIvN1BhUmxHYXJCZmFC?= =?utf-8?B?TFY4NGNJMGR0TnBRVU1Rczc0eFUwNU5hT2tkUEx4cWxQN2cwUlFvMWtKMHZO?= =?utf-8?B?SjNBbkI0ZEJxUDBQMU4vUWlkTTkxTFFDbE9HSVlpblJ4V3htemltNDU0NWdY?= =?utf-8?B?aXVPU0NCSVZwLzJ2NkpVdGk4Z1ROSVpiK0hwZEdIR2NXeDVhbC82cG1MVkJD?= =?utf-8?B?SVY4V0dJZStsSFJyZUNlK1ZMQ0N4NjRnbWRZc2luUnBDdzI2UnJ5REljMXhF?= =?utf-8?B?Rit2VkRwWmZaNHlNVEpuMkpqYXdQTW5WUnQxR0VZZk5XUE4wRnZqK0lLdXNx?= =?utf-8?B?UnJjUFRodmhXWTVXOUNVM3ZuV2xLdnNaa201L3JMckcrRXR4bkpKOG5ISlUw?= =?utf-8?B?ZG5nRWJsRyt2Q1VnZVBWbDRyK2JmOWhHVUIzSGwrM1BlMWt2VVpyWXk5OVVs?= =?utf-8?B?ZFl3cXFxNDNXNVo3VFluY3dIZzFmYjVrNHlXTE0wVGVkNWNXT3dvT01xYW14?= =?utf-8?B?WnVZNnVvM24xWXhDYmZhc3VGQm1NRHRPMGdVTU5weGdQM3M4SmlDaVZsUXhj?= =?utf-8?B?WGl5VTlxbXdJa3JkTmx6NWhrbjF1L3lDc3hZUEtyOXhyUmtiZ1hVTzJkWW1L?= =?utf-8?B?ZUpQT09PdE5yaUVDSFZvREYzTWgrOURYNE1paVc3c3pUWnpKWjhaYVNKUEMr?= =?utf-8?B?WlJyRXpRY1JYSFpGbjN2OGRWSUZNRVRHLzNocjAxZVVOcEZKQWc5dEoxS2RG?= =?utf-8?B?SWVtS2E2d3NrR3I5NXFidWlFN3dvME5NMnZpMUJicURaNjBYdTJFbmZXSDRr?= =?utf-8?B?dzROMjNxM2p4cDg4eUM1dHBQam44a1BhaTJzSXZlMXN3Zjk2TmE0a1B1LzhK?= =?utf-8?B?ZDBtVXlZbGp0NWNFTWFyTkVybnE2U0FGT1BoM0xoeGRyV25rSjdpRlIvMVE3?= =?utf-8?B?MG5lbGM1dFlhV0Zsdmd5VG5pZDZ6d3ZoOExSSEhyMXlhWThjYml3NDYwSDZq?= =?utf-8?B?ZnR3RVJpbEp0UUllV0lmUTNXdVUvZERKc0RRTlpzNGxVZmhZOVZHT0laUzQw?= =?utf-8?B?YmkxYmRXeGdVTnBHZUFianYzV2NKSjVQenh0K3VYZzB5WHlTdjhGZHdWV1U3?= =?utf-8?B?OWRQQllkdDFyQlA0WUtXZi94UXJLR3JsWUhPS2IrTUFQNFZQYUVaNTI3dm1n?= =?utf-8?B?djd5dERaYW45NklUREJmdlJpQzRoT0dJeU9IeU1iSC9tUFpGS0VIdU4xTXdh?= =?utf-8?B?QUVuaS9jR1JLUU9OUEFqUDVZdElXWnl4d2JOZ0ZmM29UTzlQd2xNaVFsUDFj?= =?utf-8?B?REpKclMvUXQzNlpEa2ErNC9vOEVoMUh6MjNKbHR2cjJmNUYzVGVKdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 69ec1295-aa52-4369-8103-08de4e114a01 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2026 17:22:09.7537 (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: Ah6t++1jc53z4MiIXnZZ4rTzYsU9ZwLoFm1mG2zxKid94Z4pVBDZvaTgmwXCpiI9VJlYCRj1vhLljTQhvq0Ofg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5493 On Wed, Jan 07, 2026 at 04:54:55PM +0000, Teddy Astie wrote: > Currently, Xen uses legacy method to access the configuration space unless the > access cannot be made with it, where Xen fallbacks to MMCFG. This is not really > great, as MMCFG is more flexible and doesn't require a dedicated lock, so it would > be preferable to use it whenever possible. > > Teddy Astie (2): > x86/pci: Improve pci_mmcfg_{read,write} error handling > x86/pci: Prefer using mmcfg for accessing configuration space AFAICT Linux is using the same approach as Xen to perform PCI accesses. Registers below 256 on segment 0 are accessed using the legacy method (IO ports), while the extended space is accessed using MMCFG. Do you know the reason for this? I fear there might be legacy devices/bridges (or root complexes?) where MMCFG is not working as expected? I think we need to understand why Xen (and Linux) do it this way so it can be properly justified why it's safe to switch to a different approach. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 07 17:35:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 17:35:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197066.1514726 (Exim 4.92) (envelope-from ) id 1vdXRV-0007J6-IT; Wed, 07 Jan 2026 17:35:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197066.1514726; Wed, 07 Jan 2026 17: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 1vdXRV-0007Iz-Ex; Wed, 07 Jan 2026 17:35:33 +0000 Received: by outflank-mailman (input) for mailman id 1197066; Wed, 07 Jan 2026 17:35:32 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdXRU-0007It-Bz for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 17:35:32 +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 423859bd-ebef-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 18:35:30 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DM6PR03MB5049.namprd03.prod.outlook.com (2603:10b6:5:1ee::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Wed, 7 Jan 2026 17:35:26 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.002; Wed, 7 Jan 2026 17:35: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: 423859bd-ebef-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DF6qbVA0oTRfGpGBXoqNW4KYz/ut3aQFF0rmTTDwOhebEbHYuyzWzZaI9CNF1WIw6YPW+AS6Oy0L6g1hPK8BYTvL40tcHJuBV+FX4ePyXdO74InnMKIX74roxeIZVRhsP7JXypr5NyZfeuTAuHF/g66zUNP6SgMQRto/ygb2VZPxHa+T9/kg1xcJJ3OYTddi9X6wv9LAPd5hSoq2ua8a0I39xWZz7XDZ8tYfHjCabbOS2rTGEW9IYe9nW4yUgIX8CVTUV92sAyvmWgFTfE0gwSlMk4YqceW0rTIXC7l0EidczEnS5d4CDNBDgSVIOULmOawMM3u+1srUEVz8sSGfBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oviRb2ui4rPxdpQAe+SAFKIeU8w+pVWM2DxTgzeU5OU=; b=c2tcG+wCtE7l3JoDQDE3pogewMV1DxSajcBwuAs3u/TpoZsKKf3x30yJc7LxPAjm9B+XBMvWnkiA+JCHSYpKZZxyboIivF/Zrnfmu6SK1oc/H8Pccc09x/+k3YAF2x+VfPcTrwpz2LXzL62Vw43mgG81w8CFMbyIcK0pU2wIywDGKQ8NRPoAyfvEC9LHTxdjIVuTGR9xkLEX6StQvntnDOrfft7YwypeLrvBKjIrFwPrT3FDa5DQTkiwXjOKirU+70UrsIW1qGx/lo+K+wGtYQfJr3mmhSg2ZYJvKrJtk7rZOrGbkXvFcrJOaS90uONeGishlOPHcX535jkQZlqf8Q== 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=oviRb2ui4rPxdpQAe+SAFKIeU8w+pVWM2DxTgzeU5OU=; b=FPdD9EYizOiMnEGnmY0Y+D6EwRXM+vWZgdoIyWkjn+HNix37KSAbiYKlwlJJ7dA27GA8c/LsWOC+kLaURT8+dIQMdHqhGpCDW1IMobDmsLHD8M7rPVlSKVgDyFj+igXdGDZLgQkRoU2yBCjPasyjthXHJMZe8R1oSh+nPTrUHD4= 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 , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH] cirrus-ci: introduce FreeBSD 15.0-RELEASE as "current" version Date: Wed, 7 Jan 2026 18:35:09 +0100 Message-ID: <20260107173509.56155-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: PAYP264CA0012.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:11e::17) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DM6PR03MB5049:EE_ X-MS-Office365-Filtering-Correlation-Id: af23d92f-217c-47da-78ca-08de4e1324e7 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?d2o0em8xeEFmaXpGSjErb1FQY1NmUTBhWkRub2taQmJpa2E0clI0bGFNVnNO?= =?utf-8?B?YjBvNkZ4ak4rRk80STVub2RtN1RRaitadTc2bnhJZENuWVJvV0FWaDhLSnZN?= =?utf-8?B?V1MydE9qczZpUGs0a0hVOGltK0pxYVh4ZW5qYWFTWUlhdlVqMi93WnZHb3hu?= =?utf-8?B?TjlhbEFaKzYzd2NRTis3N0VKODdwWDJ6c0tFZ1ZJNyt4ZXQzemdlTVZVbU5Z?= =?utf-8?B?eUpjVzVua21EaGVyMXFkdGVZOHVXNXM0bmdubmpnaCt5WFZyeG8rQkpOQkRi?= =?utf-8?B?a0ZmcVdCS1YvT0dBZGNWOEMyMHFmejFQZjVYaDFXamdaMm5WNG1kb1hEcmVI?= =?utf-8?B?OXRKWE5pT0JUL2hqWk5QNmh0RzhqMnhBeHB3WDByc3oyamVqcTJYdmdiN2hM?= =?utf-8?B?OXlyVklxN1dST3NHaDJIUHZNKzIzTnE0OU5kVVJRMFVkL0xIWW9IL2xacUs5?= =?utf-8?B?Mm5Ub0IrR2dMS3p1aXlRTWRQMlluWEVvb1VTOUg1N3h3S3ZHb3hWenM2Y0Fk?= =?utf-8?B?UDFOWWlKaklPYVVOMEdhR2dOem0wb3MxRWg1WjB4QUR0VUVNZVJCaDdtTFpz?= =?utf-8?B?YlhPSFNGY2drYVFIQ0tydmtnZEJzWStSY0NHR3d2ZlN3VE5WWlZFc2N0ZG9D?= =?utf-8?B?K05udEc4eWloZmp4M2hCOFhnREVJNFNZY0lsdjZqc0VSSmplSXVtaHNLcGZD?= =?utf-8?B?TExYbEdYU3BmbHlxRVFWOTRKVndvbnJ3Zkl3ekFvUHJ6MVRSZkV4Q3U0b1I5?= =?utf-8?B?N29qQmpldlpBeUcvRDZtaUZpRERWMHQvVEg4NVZPZmkzYmpEQzMyY3FoVEM4?= =?utf-8?B?SGc4T2ZickNlT0EzWGlpcEdQR2o2cE1FMDRaN3RFVEN6djRoQk5DaVRMMGlo?= =?utf-8?B?ZlRuMTE1eHJGN2w2TU43UmdyNjkwQUtwWnJQT3VoUlppUmxYWWtScmplZ3BX?= =?utf-8?B?eFJON3c4Rm11bFhqTjZ0azhOa1NNQjdxQmdLaWlnREYzdlZmZlNVTEFZKzFZ?= =?utf-8?B?L1UvRDh1cnZPSURDdlcrcnZVa2J4ZlBwa0ZzMFB5TXhzVGdQK01hNURYL25s?= =?utf-8?B?bTRmanNucWs3V2lnRzhjaHJ0RHJHUlVDeXZBRUhabnVxaUFpRzFIWnFnaEFZ?= =?utf-8?B?bHFJWWZUNUg0bWlYZ0g1SU0wY3RoRytyY2t4REFPOERuUWtuOVJVSDV3dFhF?= =?utf-8?B?NXQxTzN4YS9uckhMWWs5aDlwTjRDMUExays1UGZRYW41bDl1bzc2N2kxWDVi?= =?utf-8?B?TTlKT0w3eWRxWVVPYXlVWHJ3QUE1a0labWxnbDBRdWF0czRLRjk4ajhRMU1s?= =?utf-8?B?WkRqc0MzSEdFTDZXbmRsanpXODRCaHpZTm9hSHRwajFDUzQvVTdlY1Q5ZXlX?= =?utf-8?B?RmJPWDlFY0xybGdqWTVnd1haemkvZHhOUE82UGhPcmdPRnd5ZThoZzNVKzk3?= =?utf-8?B?RXBxS1VVVkIweVZJWE9sTGk3R1B6cWtabHZqZXNjclhuZXBCekJWSU9vbHlw?= =?utf-8?B?eVBWSzdGQ0k5UnczTVJ1L2ZMUm9HZkVCYS9kSmMrMFZoV1VialFlRnRiYWZO?= =?utf-8?B?OEhWOEtsM0ZTcWIveHYrYVdsb21QTk4rNjNXbVNUZDIzSzAvbEtaVnlad3ZG?= =?utf-8?B?SFkvVVVZZ2pqQzhNSDBQTTgxQ3dsS0tLeGlMZVBEalc4WWNsQkVEcEgyNytI?= =?utf-8?B?NkZySGRtUTFCc3JMTUlYZUtHWlBiS2l3OUtlZnptUDVLSWllMHlKMk5uTkh1?= =?utf-8?B?OXc2THJjMlZIODdxdDd1ZG4yazQ3WEp5TUJCOEd5aWxDNkVjT0VXMWk4YjRN?= =?utf-8?B?aENDd1VvYlY0M3BEMG5NVXl5aTIrRmh5UjduVVhiazFVa1pqUlNMbW5jR3Ja?= =?utf-8?B?azNMTkxncUFuK25HSTluck9wUVd0QVhhTXRCclhUcUY0ZG92ZnVnMVJMS3l0?= =?utf-8?Q?MQnq7n35V9iO8B/Ut5hZZ/rFvLQaL3Ua?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dTZGUGpTdmZheEpHWXRuVHFWUVYvZEx5ZWVHWkdrS0Y3VVVTdFFwbGQwTDYw?= =?utf-8?B?VDRaVEwzS3VZMktRaERvS3ByeHpjeDBjRVpqR3JnR044ZHpYcnV0L1paa1dN?= =?utf-8?B?TnkwR0JpaGhLbVBSR0I1c1Rlam9CelRXd1BsUjI4d1pBMjkvTTdGMkpwUS9x?= =?utf-8?B?eU1LQ29PVDloU0JHNGhnc1FXTTBldzJRRHdhQUE1NGR3T1VWL2k0M2xRWWpx?= =?utf-8?B?ay9SOVJjNWs4WFBWZ0hQOXJsUERrSzRJc0lsTWRNeVNkUFhOK3VNaVF5aG0x?= =?utf-8?B?d2JaL2hhYUxWVjNVelRqaTZyODY5QXFuYTJVWmVrN0RUZk40RndvZnNqQTZO?= =?utf-8?B?NW9YY3lpNlFTcnRTQ2ZwclpHYjNvZVRNbVp5T1RHalI5QTJGQW9RcUR6aVFT?= =?utf-8?B?Rm13ZnY4OWppeDBtUW1DVVRBR0JEbktrQ0ZoYTRhazhjL21IL2pCakMvbFB0?= =?utf-8?B?L3RiTWRmRVBUeEpoZmRlcEszTU1MTEliN1VRalp0eU1vVFJ2M2hmTlBEVUFy?= =?utf-8?B?SklWaUtvakltbGZVR2RaUEU4N2pZeXZ3NHcyY0ZyUTNoeE9kbFhMRzBYZFBJ?= =?utf-8?B?TEhhd1FPSEVJdkdHS3lBQ1BWTmwxMTVpbHhhcC9Sd01hMDV4QkhWdTNGU1Vh?= =?utf-8?B?MVJzekxOWDg2ZDZMQVY0TlQrZUprLzYyMnE0QW05MUl0akVMdzJnV3o0dTZG?= =?utf-8?B?cG9pRE1CUlhlRDlsRFBnYVM4ejIyWERSSGRCQ04xdGpnVGJoNmZQeWpQS0pW?= =?utf-8?B?YUw5VlprMjlaOGxMMWRjQU0vSURDT3AzU2JEb2pKZUtZYzl3UjVoQzlFZ2Uz?= =?utf-8?B?VldlOUJxejdYcVBETm1VWWhrVEhDb0ZnL2FZRG9hNnY5bGk4d2N2aE8xRlhS?= =?utf-8?B?WFBLTmJDcW5QaGZtYjRmTWYwSGhkZ0NwS1VreWFmTUt3SytiNFd5YWFHanNY?= =?utf-8?B?bUdzRHdHTTJCR0wycVFEUFBUbm9PSWh5U3MvUWxDRklVazNwU0xuNXdMdWVL?= =?utf-8?B?UDRxOENQVDVTZFNYSzA1VFU2WWh4WjVsTjgrVE1UOXpPNFBtZlVUUjdFY0Fj?= =?utf-8?B?eE1DZXhxN3BKd2NIQmRzWHZWVWFqM2Y2NzdBcVFacmdRSWpuOTQ3TUZPTXEw?= =?utf-8?B?emlFL0lYTzBTUWlXWjN4UHFscUtGblZTZVBqRVhLSzRsVk4yVG91SWdCWGsv?= =?utf-8?B?NjJqS2tUN2x5MHZzN3RPWXZnRFdZUUREbGN6eUx1Y0hwQ2dEZ0ZpZjZLUHN4?= =?utf-8?B?YU83SkxtdFptcUwvcmhPT2tMeFR4Z2xycDI0RWc4WHQxK3NBc0N3MkpTWW8r?= =?utf-8?B?WUl4YkxlbFhPZWwzOUVuMlRSUE9YQ2Q2SW1pWTJaRjZiMUJteHVBeXMrRE8v?= =?utf-8?B?S3kzTzhpUXdpM2ZLOEg2OGlWRld2VFY1eGxyL2dvQ0FqWDlENjJwM2M0SEQ5?= =?utf-8?B?amZIMmxXVkpJRnlldW1HSG1oZkhYVGs2MzhxRTlMQld6NHM0VzVYR0pvN2xj?= =?utf-8?B?K0RuQTlMMnpZa1diUFVpRDIxOUcxQkZCL0M1QUVTSituZUp5VHFHV0NDRnox?= =?utf-8?B?djl2NGxLRmFkWUhYSTNGeE5wNUhjL2ZmUjhvbnVGK094YXRVWmttVStOdFMr?= =?utf-8?B?U0IxdnZBdGNubk54V2YyY0VBSmMvdFQrRWJrQTlVRWs1V2doZGwxaHU0bEo3?= =?utf-8?B?clEyeUxVT1FJZytIcEZmRjhPd3l2dXczeGVHS0NHZnVDdGpqcHMxdFk3WlR5?= =?utf-8?B?RVhiL0d2M3ZDNzFLdUl5ZlVPc2NnZloyTzFJcHV4ZlBwNUJEa1ptdHBCM3Nz?= =?utf-8?B?WFdaN1lvczhtRGxtVlExa055M1V4amtHSmJKMHA4aUlkaWFTSmFNT1pON3RY?= =?utf-8?B?Q21ZVWthaFc2Rm8zekJIK2hYbmpuOFpHQTdBbC8wZm8yVWRubDZkWkVMNU5L?= =?utf-8?B?RTJkU3NBVVlZZmtsejh4TjZtQjR5STNqbk84TXJMYVdYVFpEMFVINmVKVGNx?= =?utf-8?B?bmZqeUJ5YnRPM0V0UEpQRC9oOERuL3RoaHFLanI2amNZOGJNM3RkY1hnOTNT?= =?utf-8?B?aEZoeE5rckhiV2ZpQjRmaFExdm4yUnhvZEVLMzBKc1AvWFlmdjZLMDlodTVC?= =?utf-8?B?SnlOSC9MQ3k1Sk9OcWVhdDhzbjZKdkR3SVpjMFdWOVNCRlVQbUNkaUFTY1FI?= =?utf-8?B?Q2pVU1F2Si8vdmMwWGIxK1RxWWdrTnYzSGJQSUhWUWZ0dWRTcVU1cWFvRmpp?= =?utf-8?B?NlNaTlVRUXhaK1NKYkhXRVhoYWFreXFsMHp1VHNzT1dWME5RemNQMHZoeVMx?= =?utf-8?B?MkdGWnpVZUhoV1BIa3FWYTAyOGl0SFJRdGlDV3d6aythbXMxRW5aQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: af23d92f-217c-47da-78ca-08de4e1324e7 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2026 17:35:26.4683 (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: s2YhDAP6FHhbSnA5kD6HWg19x65F/dFfbNzvVlJludOYcDZUogUW2U7MYv4GTFQycyR4C0CSzeOX6OiNbVgKwg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR03MB5049 Switch the current version to 15.0-RELEASE. Sadly the 16 snapshot images are not working, hence use the FREEBSD_CURRENT variable as a placeholder for 15.0 until the issues with FreeBSD 16.0 snapshot images is solved. Reported-by: Andrew Cooper Signed-off-by: Roger Pau Monné --- .cirrus.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.cirrus.yml b/.cirrus.yml index 0de1012d8c60..7bbb4f1c5c6c 100644 --- a/.cirrus.yml +++ b/.cirrus.yml @@ -3,7 +3,7 @@ freebsd_versions: &FREEBSD_VERSIONS env: FREEBSD_LEGACY: freebsd-13-5 FREEBSD_PRODUCTION: freebsd-14-3 - FREEBSD_CURRENT: freebsd-15-0-snap + FREEBSD_CURRENT: freebsd-15-0-amd64-ufs # Build jobs -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 07 17:37:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 17:37:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197077.1514737 (Exim 4.92) (envelope-from ) id 1vdXSt-0007pF-Ro; Wed, 07 Jan 2026 17:36:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197077.1514737; Wed, 07 Jan 2026 17: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 1vdXSt-0007p8-OF; Wed, 07 Jan 2026 17:36:59 +0000 Received: by outflank-mailman (input) for mailman id 1197077; Wed, 07 Jan 2026 17:36: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 1vdXSs-0007ox-Gm for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 17:36:58 +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 76de854b-ebef-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 18:36:57 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS4PR03MB8400.namprd03.prod.outlook.com (2603:10b6:8:32a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Wed, 7 Jan 2026 17:36:54 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.002; Wed, 7 Jan 2026 17:36: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: 76de854b-ebef-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Ee0v2bA9lZxZDiG5pSAiKn7AF3r5MO0MSuaFEBgSLjDiE/wjmhHVLhb5oMb8u+v4YPQapBCbCmI4htQRiUYOtDJGgpNX7LiSxUib/nH+U43IvqTr2L2kYrLmpe1QV+fAgzIHiDOdOEkB7CzJCFzrTuusOAp55RnP/VkDrTEuRj14XkMLqlbRpDkCAGLMx4g+4AP6t84w6Hrtf98YRUUPI9edBy0LbifJABJ50ayQH8Mk3aureHodj2YKlUYY4VEFsGlSgkuSUR2WCcsRV0WvXWIN2zsB9ZbOXLn5z15PEtoNd4zb6Rb2nKe/3SCP3awawmOpeigE1W1vRgzI/ISnbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Uesa2GPeb4ksot61NbQpAiq0XBW5LczxjehMUfGERmo=; b=IkKnBtRun/pixI6nIqpiI8IK9zMUshHLTJH1VeDT8LSQa9S5NY5bjUXS0vZ/msm4JukPH5DFRclsiuW/mPi7kwqW2Ddp8lYaNGh41zOG4SHLkowbbWHMVi96VkTyYuXwXnTTUDiuxrRqoPVoa7k4W3BxDoav6RdLfzEFKZm/V26eC+GiywrFIDHyJ/xim2rhxjGzSjvxUcDzmazRM65E89t6UFHgvfAZcepoc120cRC3pCv4xynoo8hm/x6lT/eno8ecXN6Is9DvLG6MPfqZSTr203BmtTpnd8CsDyxbq0q3M0Tqn0bV8xopvWDDwwPitVdjgHelw7MKwJZc/YAOZA== 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=Uesa2GPeb4ksot61NbQpAiq0XBW5LczxjehMUfGERmo=; b=SYYf7sj9oirYAIQ67+7IMf4dp7lDpIFoVNnwWOzrenqm0sTK8r/Zbwth876giQ8fmgoAmxtEvGNZEiDaFP4453cGRE+80Y4g8DjZwEJUZ42rjLTheRF+CEiqq6tXE+fWOPlOZ5CF0dbP/YRNYRmWD7yrfnuEQv/DG/Zl89rXXeM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Wed, 7 Jan 2026 17:36:49 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: Re: [PATCH] cirrus-ci: introduce FreeBSD 15.0-RELEASE as "current" version To: Roger Pau Monne , xen-devel@lists.xenproject.org References: <20260107173509.56155-1-roger.pau@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260107173509.56155-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0499.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:13b::6) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS4PR03MB8400:EE_ X-MS-Office365-Filtering-Correlation-Id: 23304312-4aac-4f8b-666a-08de4e1358cb 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?VUcra2FlTjJyR2Y0YkQrcElhRkJGY21VR0s0ODgrZXRqd1FRRHNQYXl1ZVJD?= =?utf-8?B?bnlhNHowZklVdkx1VDgycE1sU0lmOUx1Vm5USUpkYnArWCs4ekJKRU9Namtp?= =?utf-8?B?cHk5cmp4NEpaVFh6SEVSN21JL3dqdkZlTVAzZjN5RFNFWldzYlpxM1hKck4z?= =?utf-8?B?bHp2SWVBK3M5K0ZtaU02Ny9zQXFSbGV4MXBQOTVTQ1EzQVVsbnlUZ2dzMHVG?= =?utf-8?B?c081M3YyNEkxNW5xRDhjbCtqRnJILzhIYU8raVZjM2dINXloTmEyNExXa2Zn?= =?utf-8?B?Q3lDK1pJWjVFYS94ekRvalpNM1RTeW9mejhaOVRyTFc4aVRCTEtSeWRBYnp5?= =?utf-8?B?NVpkV0kvckh4bWtheDdBVHRxaDlFNmsvTzk4a1ZKWlF3UHYydlh6MGVDYkZX?= =?utf-8?B?VUpxSDdNd05JSWJoNjRvbDFmLzhQZlJ3ZkhESVY0cUtmZFVjUVV1NWFTdWsz?= =?utf-8?B?eCt1YnlmbzAxMENrZEZhS0h6Y1o3Kzg4SURGakozdGN4d1plQkxHeHQvY2do?= =?utf-8?B?YnNiMHdya3lNTFcvVzQ3Nld2czZKeVUvNmt6OFljdEZaTHZXRk9Ldlg2ZVNI?= =?utf-8?B?MUwwMGh4Z1prQ3BzUFZKVUJkalhMb05lOUR6ZGgzelE0VWZQZEszeEZhY1J5?= =?utf-8?B?enVRdzJ6Y05weGp0TzBvcGdxOUU3U1ZKZkp1bmFnVnNBOXJDSVVPZ1ZNeVpL?= =?utf-8?B?U2EwdnNYSTFmU1dFajlwR0ZqMUFoSFNjcGhTMUZlNFRaTHpxYm5jd254N3cx?= =?utf-8?B?SldNMndFcHZJVURmRmFJazdzUWFpamxuNmZMczB5Y0xpOUVoQ08zdUxCQ1dE?= =?utf-8?B?anFqMTNkOFErQmNKNjdKWWNSN25IQVNYdWQvUE9qVXFyVU05b1lrK1BjbHIv?= =?utf-8?B?eExLWjJEMGtGWWhIckVtOXlFZENnZGdieHcyVms0NUtUK1hiZE1wTU5vblV6?= =?utf-8?B?SlNxOGhwRThlZ2tIRWk2Z1dQZlQzYlc1YkFlelh0T0VTa2xIZkFBcHlzSVg1?= =?utf-8?B?TSswWGUrWmd3N0FMcnVGUFVrRmV2SVpmbzh0TitPMlQva1k2Vm5OeFRnZVNV?= =?utf-8?B?SjQxU2lxMTJwTTh6T0FLYkhsVVFMR1dZMWVnWWw0NVFzcmhXYm1KbUtqT1E5?= =?utf-8?B?MHBrSmcrdUZveE5ZdWVoaXZSNDVyMExHNzB1K1hxaWp1UzBMTDdrSUtyTkJU?= =?utf-8?B?ZFVtcHE1QitOUDdxak8xTGpCQ2JRS3I3Y2VzMFRLUDF5enpMWmdvRDFMbHFy?= =?utf-8?B?b1ptNWdubytJdHdjSzhzTTdoM1RtNERDRk1vNXlGRjJyUURpN2lTYm5ucFZZ?= =?utf-8?B?djZjOFB2TEhVTHBaaWxydy9WSlRGWXE0SWM0RUd4dmxIOXdwZUVVWFplaUdr?= =?utf-8?B?M1E0ckpROWZIWDRoZkNtSXRYeFo0c1dwMVZaSlRoVWhHZWN0TTNDVUJHaitE?= =?utf-8?B?ZUdLekgzOVlNUGRyM0M5bi9Zc0VsTUs4Y3V3SXZzamNCZFNVSXpoZTBNU3Ew?= =?utf-8?B?bllPelJuSktMVUJFVCtjZDRsenpxZEdlWEdTRFZ3czg0VHF2OGtWWmJBQjhw?= =?utf-8?B?alhscmVVejVHR29FUFNCeXN5WDRCWUFWSzZMdmVxdDl0c1RjU3NGNjVBRWFL?= =?utf-8?B?TTExcjFvQzhlK1NQb21aWWZoeWZhWm5lWjlQT3RDd2FNZlU1MitHV3QwQmNM?= =?utf-8?B?aU5IaTQzSWo3MGIxSHlKS3ZZWEpOamFIYk5NSjRxZjViaURTN1dKdnhGb1BS?= =?utf-8?B?cW96SUNPTUY4YmljT0RWSDJMeFo4QUh6WjBGM3pHZFBWYWNLUDdpeWU0cllt?= =?utf-8?B?bkZUM0JlbTMxWWxadEYxZ09PR2tZSStOdXdiK1l4YmdqQW9JVWQwQ2tlSVhQ?= =?utf-8?B?ZWF6WXRHSngzQlMrTForSHZlL3dxSGROOGZneE5EY0xtYytXdkNqYUZjZm5E?= =?utf-8?Q?sxZlBit745oz/wo5pXTZQSVcbRVbv5EC?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?d3BDVWxGM2RKRjVsUXZ1Z2JzQ3NvaHBEWm9nS2UrN1FVV1FYY2QvTXpyYzUz?= =?utf-8?B?RHQrSmxyTHA0VlpvZXpoaWJwNkNadkVTSHk3cDVQQzd4cHUxVTIvZ1ZGNE8z?= =?utf-8?B?TzFtVkpTbFdYWVZ0U3pYNGJjbEJFMW50Mm50Z2REQVBvQXFaQW1jaUlPOFNM?= =?utf-8?B?Y0hiUkZlNzlRMWEyZEQ2Wk5IOWpET0h3b21ETkhSSnVRM0taaitaVkdHdTBD?= =?utf-8?B?Zk1KeFoxdzgvWDVqTm5PTHpDTUpjSngxbHN0SFJhbGhNaUxGNkpCZEwzZkp2?= =?utf-8?B?bENMNVAyNnMzaEVSWDFqMytPY2l3SldQN0FMdjBWVlI3NUhiOG83NXE2YnN2?= =?utf-8?B?UDJkelBGMnpUUEVGUUNSVUlHY21RZ2d6L2FkbWd6QTFKRytCcEhrWnd0VjQv?= =?utf-8?B?Y3EwL3ZabkFsSWorQTF0cWRTV0lYSDdzRS8rYVdvczlRWXJSNHlKT0c2akJO?= =?utf-8?B?REdwenFNZ2pObFA3Z0VUTm9EQWd6YUppeTlzTVFHa0hDcXFqUFFzcFZ0bXhN?= =?utf-8?B?MjlBUEFKd3doaytPdGtpcHc2a3BZRlVkTzl1ZEltQzZBU1V6VG1aVURTdFph?= =?utf-8?B?TzJkNUozUUYzaVBQZm5qL0dNK2hxVVZlYlp1eThmN1l2RFlMTGl3bFV2c0NG?= =?utf-8?B?ZDZ2bUE0QmVmK3pCQ0syQnBMdXl4RmhxYWNDV3FNNXBlaUI5Uko4bXArUzht?= =?utf-8?B?dEEwSjlQTTdxQndXUlRXcEl6RTV1Tm5WY21GY2VreE1RZHlkVWtqSUl3bzBH?= =?utf-8?B?K3dyZ2lGc0hZaHBTRklDd2dxN1dQMndXNXRZMUNwY3l1dDdIa3JXMmhia2tU?= =?utf-8?B?Zm9NRE9ES2g1bE5HWUg1U0NzWHRNNGZSeWFHS3ZJVjBlQWhPU1JrcTNkOGVB?= =?utf-8?B?c3lBUkxJRnk0YXhOSFZ1Q3ZBVkYyckJqTFNkWDlsSDFmT0pyNk5XYlVEZ2cx?= =?utf-8?B?ZkdOdkRIQWNSRHMrSE9zZExpNWVKSXZLVWIwOXNTaXJtT2x5azRCUEJLUEJ1?= =?utf-8?B?U1RjSklub0VXVXMwZEVmbENQSTBkQS93NzRGb2VqSXFySTVBYWJqVlBibGZx?= =?utf-8?B?bGFBclVZZGgwbE9PM1hCcHVoMERqU29vemdOYWhyRWI4MVE0QnZNbTNSeTk3?= =?utf-8?B?T3AxblJSNENWb3ZObXBJUHpNNm55MFhZYzUwTG9pRDdBcFZJMkc0MDVIVU5P?= =?utf-8?B?VDRiVitwZmNSblNWcTFiUWZZaU93djJEOXdkY2RGQTE5Ym9GMWNJekJHVzVS?= =?utf-8?B?c2U1WGt2dzVDUXBkd20wRGNoREdwYnA0K0dwZGs0YjFoaVRoRml0ZzBaOVVz?= =?utf-8?B?TERzYjU2MTdkRlZoU1VRSHQzYkExM1orUWdCTEpFMHBCTnFkKzJjamtLVDB1?= =?utf-8?B?RkhnZDdPeTA2bU1JUzVaaUhkQVdiSVlNVE9lZDdFQTk0WGJWOTFiTmJBZXRx?= =?utf-8?B?QkxhT2hKRzFvYXJwSCtxN1l1YU5DdEZTMGpJTEEveGNKaVByY1NxbmQzZXlp?= =?utf-8?B?cTNNZzBLdk1HK0lvZys5YUxkN2RUWTlzb0YrSjY2eGtyMmtXcG4yTzJtbng3?= =?utf-8?B?OWxwd2d1QW5EZk1EZVFvSTFRdVdEYzFUMWx4TjcxVUNCMTRkL3hXRXNJRlBo?= =?utf-8?B?M2dCVDVaQ2JSWld5QW1xdEpBeVMrWEtHeHFxdHdqMUJ2MW5uMitVblNZYXFD?= =?utf-8?B?TjJjOVREaTZHT3A4ZmRLY1lOYnRZQ0x0RW84a1pld3RMRFE0RXRzU1Z4eWxl?= =?utf-8?B?ekRWRkRPK2JvMHgvcVQyMGM0OERRN1pjNDM1NkxaN210clg2WTN6QnYvenRi?= =?utf-8?B?MjR0cTUwV1Uvc1NJKy84UWt6NE1LYkpLYVhvMjdHNk1YVnNwZVFDZ20zYzBC?= =?utf-8?B?NkRFbE9lbWRTSVJxbmZLemIwUjJRR0VkVERjUmQ1WjI2NzEzUmtoTDRUbzFx?= =?utf-8?B?VGgwTTJPMVFyV2tDREhOS2h0UkpUYThrWldGRHBwazI0RGdGL0dMZ0JEMUR6?= =?utf-8?B?cGVsR1puWW1NRHFFcjFxcGExalVyekhyNE5qZDNQYzlUQTBzMThiYnhpREVT?= =?utf-8?B?QTd4SmNNM3QvcVRCNzNPczV2VTZKODdUbFhSdzdWOVBVL2xIamNRdWJ2aDYv?= =?utf-8?B?RUMwSEl5YkxvVjJ2RmhIcklZdkxSb2Q3ejk4VGFETUNkZ1FuU1lLcnZSaEhX?= =?utf-8?B?WkEwK2lpenNkWHlEbks1QU5icThvTHJURmVPVEYxYTQxWlJLM05YMmNISHpv?= =?utf-8?B?WjBmenR6b1ZYK2dQSFJZNlo2VzJsZUxCV3dwckRHYy9ZZlovQWcyNlJJN1Ex?= =?utf-8?B?d2ViRnQ0YVl1ak1CRStXYkJzb3NLbUIxOVVkZisxeDBHaGxWUjU2K0dwR2VW?= =?utf-8?Q?4kJR4WyHyp6V7ts4=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 23304312-4aac-4f8b-666a-08de4e1358cb X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2026 17:36:53.6328 (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: dF+Sabf/3hexsaRCctjAwKdTZX+oPZvYUwBD3+r2mT4a+Zc+R7HySUi8+XMbOybvQNtWxjFtPpH/2eBrrzeUr4Gp14uK+KJmITYITLjNZE4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR03MB8400 On 07/01/2026 5:35 pm, Roger Pau Monne wrote: > Switch the current version to 15.0-RELEASE. Sadly the 16 snapshot images > are not working, hence use the FREEBSD_CURRENT variable as a placeholder > for 15.0 until the issues with FreeBSD 16.0 snapshot images is solved. > > Reported-by: Andrew Cooper > Signed-off-by: Roger Pau Monné Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Wed Jan 07 17:58:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 17:58:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197094.1514746 (Exim 4.92) (envelope-from ) id 1vdXnN-0002R4-Et; Wed, 07 Jan 2026 17:58:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197094.1514746; Wed, 07 Jan 2026 17:58:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdXnN-0002Qx-CF; Wed, 07 Jan 2026 17:58:09 +0000 Received: by outflank-mailman (input) for mailman id 1197094; Wed, 07 Jan 2026 17:58: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 1vdXnM-0002Qr-VN for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 17:58:09 +0000 Received: from mail132-4.atl131.mandrillapp.com (mail132-4.atl131.mandrillapp.com [198.2.132.4]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6ac21179-ebf2-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 18:58:06 +0100 (CET) Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail132-4.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4dmbNr1q5qzlfkp6 for ; Wed, 7 Jan 2026 17:58:04 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id d6733da72a414c6aa7f71906780df762; Wed, 07 Jan 2026 17:58: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: 6ac21179-ebf2-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1767808684; x=1768078684; bh=4w9uqCFwveWg3bIxapTLy2bd4m7YU3VR9BNCoCXsIFM=; 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=EYFZuk8MrmFIbOGOO4PqWgkIuGualypc4q87h6dniRtmv2xjx3oYLXGgSh7Cpv4n/ lPnC4h0/EoWiq0FwqZw6XtllF0RS5emI/utdrw95tIu/jk8jzTvsQre8PicaEf/ZRd SD61L+e7xL3i+4imQvbZT9BOfSnYhnGmMwLLnOyKjt7KmBBwrtadbe8NkO62Z2H/WA YHIZu2fCxYR7mJSvRLuO5ITgiJhkFSXJWFVraq9SW+5+DTdtQuYqYS+/fc5m15sTJJ zZuQIg7dnpL5yMHgRXKxv3sgBpwHmqtlM0a/AQ2Sdn/I9WE4ydGr2IToHBTGr6eWp4 lFaScZL7xvX2g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1767808684; x=1768069184; i=teddy.astie@vates.tech; bh=4w9uqCFwveWg3bIxapTLy2bd4m7YU3VR9BNCoCXsIFM=; 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=g8g10w3Hf2KEyWHAeu7OveByzzIpmHGPR7HZjQ2tMZsyUR6yvfujz3sFu038ojF3L jwjN7Cr9+/NpJNt0cL6IRWkLOXC9UIwHZJxmZKxwXBZ7PxTbeRHt7DHT51WMzPlLx+ Hq411TXSAmbDs/9NwmuR3jV9nO4FDYYrb5iTJSgx/JVEx7Tw1+PduhIlLJEtHfGb64 8QuLS1uyKqFAGeDEzGcHHPBBEirbRLNMZPAcbpptXMBZVpJcthKIQzgCEZmglFfGq7 D8kwJPyPAr7Oj6y18NzY8ultEYfoJeSc6gqAbW/+dg2LRr0ARCZjY+ZRTTkPArDOZz VbSkHgCuKSDmg== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=20v1=200/2]=20x86/pci:=20MMCFG=20improvements=20and=20always=20use=20it=20if=20available?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1767808683144 Message-Id: <104d15d0-9f58-403b-ac61-dc02f4a2e097@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.d6733da72a414c6aa7f71906780df762?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260107:md Date: Wed, 07 Jan 2026 17:58:04 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 07/01/2026 =C3=A0 18:25, Roger Pau Monn=C3=A9 a =C3=A9crit=C2=A0: > On Wed, Jan 07, 2026 at 04:54:55PM +0000, Teddy Astie wrote: >> Currently, Xen uses legacy method to access the configuration space unle= ss the >> access cannot be made with it, where Xen fallbacks to MMCFG. This is not= really >> great, as MMCFG is more flexible and doesn't require a dedicated lock, s= o it would >> be preferable to use it whenever possible. >> >> Teddy Astie (2): >> x86/pci: Improve pci_mmcfg_{read,write} error handling >> x86/pci: Prefer using mmcfg for accessing configuration space > > AFAICT Linux is using the same approach as Xen to perform PCI > accesses. Registers below 256 on segment 0 are accessed using the > legacy method (IO ports), while the extended space is accessed using > MMCFG. Do you know the reason for this? I fear there might be > legacy devices/bridges (or root complexes?) where MMCFG is not > working as expected? > There is apparently a errata on some K8 chipset according to FreeBSD code that uses MMCFG whenever possible. https://github.com/freebsd/freebsd-src/blob/main/sys/amd64/pci/pci_cfgreg.c= #L261-L277 > I think we need to understand why Xen (and Linux) do it this way so it > can be properly justified why it's safe to switch to a different > approach. > > Thanks, Roger. > -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Wed Jan 07 18:02:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 18:02:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197104.1514757 (Exim 4.92) (envelope-from ) id 1vdXrE-00041y-Te; Wed, 07 Jan 2026 18:02:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197104.1514757; Wed, 07 Jan 2026 18:02:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdXrE-00041r-R2; Wed, 07 Jan 2026 18:02:08 +0000 Received: by outflank-mailman (input) for mailman id 1197104; Wed, 07 Jan 2026 18:02: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 1vdXrD-00041l-Pe for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 18:02:07 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f74701aa-ebf2-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 19:02:02 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by LV5PR03MB8411.namprd03.prod.outlook.com (2603:10b6:408:360::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Wed, 7 Jan 2026 18:01:59 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.002; Wed, 7 Jan 2026 18:01: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: f74701aa-ebf2-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vSdaQrPPas3r4DmDVsYDPbpWld91majtERyOWjFJuLHvCdDSPQ1mtSj7rNJsiEUnBqdnXbOl5HmFdBi1jUBGUZL4LQOftsTwfT8ahFfnp5pQdxopVIFObXwRKyaN+SEj1uLkJgH+9T/xq7msPhfK5YJ+bMuBKUBEpDCspHXGPBZmJV6mRSAVi9kZGs8V7/b4hy+SsSNkECt3qcFxa0h8f81XjltRultuV7flN02r+wsMhFSvsFKORpEnuWsuK089zL0/IQ3H33bluBpgFXZTtwlcpnbhT/kWo+YJlZtynISm0OJD6joBdz4j3m5rnCLIuE02EB+qf9mjn8Cbvda7yQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YHsCGsnpSWYt16lVqmzOOp06AU35khhTb5siHQs4e94=; b=pdJ/N5UGyG2zu4XebiJouXqJC4iWzyOusF0R80rXAwOEAH9ylqomDP3gULks+W4wC7p4dbMK4zqKk1pp3evs+saFK7oQX3HeaWYi4fgEDrtGRAZ/gqHaTizCasRJulZ2jSlfU7xm82vBL42QsQztSNclcAX8uVO2DymAuo98ho0BbX5OWV5cE5vjQ28eKsNjYocyAfImcVZ+RAycVvS1VYrB9Ff8SuXvCVFGA2MREJyGV8SF2uPSU5liCWsmYoEEpTj85tz3UEQFH+M3AabF+Pzu2fVUNwaojrLQxCXayd9ZyWh+mBrZeWOQWA8Ygk/Zw9BkW9cRbRAY2FLbjaSfiA== 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=YHsCGsnpSWYt16lVqmzOOp06AU35khhTb5siHQs4e94=; b=Xe03Lo6IV5WjF6E3pvQfBB/pAGmX/0hxfUaSQa+i6TKFDHFjYqDirdvq32aaVIbytryGsLz5uJkHVHPfdu74kAuEB1dlFlRmR24sX+6UPTdt0bcOJGeluCPl0y1fJ22sN3orYvlbj/JyOeo3pvLsDwTnJgVrGnDFDAUE7dWV6hA= 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 , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v3] xen/mm: move adjustment of claimed pages counters on allocation Date: Wed, 7 Jan 2026 18:56:05 +0100 Message-ID: <20260107175605.56617-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: PR1P264CA0046.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:2cb::17) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|LV5PR03MB8411:EE_ X-MS-Office365-Filtering-Correlation-Id: ef52875f-0bbe-4490-f82a-08de4e16da15 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?WWNOZWtTaEhEL3BxTWNwRG5LbHNuOHRvTVJmTXZ4SW13N3U1cHl3eTNXTkIx?= =?utf-8?B?L3JUMzR0S21WNVJwajRodjlZamxuQ2tnaG1yaWloLzBmR2Q0OE9TM25uNGJ1?= =?utf-8?B?aWVWa3QrMUpVWHBlcWJHSDY1Ulc5d3NwUU82eTh5MSszQlUzZ0U2N3BDMjMr?= =?utf-8?B?aVIrUkErTks0SHRGR1RuMTBrMDMxd3AyVFBCRXBReVp6UCsybTNEWGxKaFd3?= =?utf-8?B?TkE1c2NpU1ZiK0dsMFpBZDEyNURUclBGT2hhZk9FcjdzbUYzcXJwY1V6ejFr?= =?utf-8?B?dHpBWW5hRnA5MHJ4TlYwcTN6SWJsSlhOT1JpSkU5WlR3cUhqdGV6UG43SDIw?= =?utf-8?B?TUQ2U1BZMDFjZ2dsUjBWeVNPemFidE5rSTN2N0FjNHY5M1F1ZUVwb3lzUFZS?= =?utf-8?B?WWtXT1pFYmdTTkFmWURQR1pOTGxXWml0MDRPaWlpWVBPb3gxdUJzcCtCdlpP?= =?utf-8?B?NVdnSFplNThBbHRyaDNPNmg0RXdES0NBZW5Sb2liVjcrUUJSNlRFdisvelVy?= =?utf-8?B?QWkxUldydDVWN2d1MVZvcHovc3NmN3NkVW1iY2NGTzJ1Q2E5cldMOHVaN0Rp?= =?utf-8?B?dkJtZ01EZVBLR3gxbi80RGo1SXl4L003ZmVZdExyYzUzdXIzckdGdmFOSWhH?= =?utf-8?B?R2lBQjhIK1FXd1JRbjVuTitMZGc5WHl6N3g2TEdSVmVMckkrYnpTdXVnUXVi?= =?utf-8?B?cTdiMVNEaTNZcS9nV3F2TTBwVHVOZjhsNU00SHRSd0cxSE8rZ3lNSlRkSHNE?= =?utf-8?B?aW5peFlaNkdrWHNmWUsrY3Q5MjF6SGMybWE1MzViQzNrMjJlcjd1K05HTExK?= =?utf-8?B?NWxZSlp6Qm01N0pZbXdmQ3Z1TnlzSUFUeEpBNzJBNjJjM2JTV2QrTmZxM0N4?= =?utf-8?B?NU02SjZ6VVV0eTFiUmRUTWlTWHQ0Y0VHVm11cUROZkdsUFgrYjM1Si9ybG1v?= =?utf-8?B?QUtGaktZVlUxVWU5YTNDM1ZOdWlFaWVyOHB0SVV1MXZRSWMzSit5S08vaDZC?= =?utf-8?B?OFJpKzlUYi9nL1M5eFk1cEdsbTVTODJwZ1lmd0dFZVMra0hIRmlvUHVDTjhM?= =?utf-8?B?L1R0bGdaa1M1b2tuZUNNbEZJTWw4b0g0eG1Kdng4NFMxT1VhTXpmMzFta2s2?= =?utf-8?B?MWdNNkJGZFlzaWtIMWhzbFNwRE9CQ0VQbis2MVVlOGNoU3ZtdGw4eFI5MjVm?= =?utf-8?B?blp1UFkxQVBVZENZNmcrTkxQY3BNTjB2aThOeWtsUm10OHlhd0FPeVV5cjEy?= =?utf-8?B?Wjczb3Z1Qk9PVGZoNTlmbytFUzEzelhlQS9LNWJTOEQ2aUhhMXFsd3o4SHFs?= =?utf-8?B?ZE15blMvMmZ2S2ZmeCswU0MwZmpFZ0tRVzBMMGMvcHpwc1duY3pIcVhaV3Fa?= =?utf-8?B?VjlvRXhvN1cwOUNlQlI1ZGRqK21nMm0wbW5STWlQQk1GdmkxUHpqODNaNVFV?= =?utf-8?B?VUE4N01Sd3FDU3BEZmh2MmJtdlFJd3RCKzh0L1g4QTR3OWNQcjJRamU2dlF6?= =?utf-8?B?am1UL1libFNZSGNBZVZmZVBubDUzc0wzVHNkUkJudW0zaEU5OGJyalN3WkdS?= =?utf-8?B?c09jMS90VFhwaE9CM0hwYlZ1TVhxWmRxT3RKNXdGTjJib3pJV3NxNFlzRlFa?= =?utf-8?B?NkVxaXgzVjRHUFg1dWNJL0syNVIzZWV0akdFTTZlUndBdU05U2V4aU42Z2pJ?= =?utf-8?B?N3ZTQUtOWnVLd1k5ek5mOVNxczdxLzN2ZmNMSXZ5a1l2Nm5YTTdsdVVsYTNw?= =?utf-8?B?enRCeDZNYm9VVzd0UnRLYmc2WkQ4UmdqUThqTXNhUmZqL2pJeHZLM0xzZEZ5?= =?utf-8?B?cDlSMEdLb3lDejVkcjluN0Y5SWJjVWk0VzF2NjRPaDY4Z3kzc1pVVG1Qc0hm?= =?utf-8?B?UDM0b3p5dlpoNVBxZ0xhL3dGbTJ6Y2NXMlExWXRxQXZGNGNOcW5yRkRocU1q?= =?utf-8?Q?TEOADmeDieeFi1KGG5YTH83FX5QuzNc0?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OTBQK1Q1M00wWW02VWlFaE9vYmR2dStQbEc3RGpZQ05IVlZCR1dTUE5oT29u?= =?utf-8?B?S09uSWRlVDJHNXVTRlppR0dRTm9XNFRJbXQ0Z21QTU56ZGtWV08rRmpLTUI4?= =?utf-8?B?UzhrMWx4VEp0bXRlRFJYMW1MdDNrWllpc2FtclprRW5QVWFoK1M2dEpUWDda?= =?utf-8?B?SFhvOHNxZGtqUGpHbHdjZzV2TGV6d1NxMjdlbGwrL3RIU0t5QWhoT0hQRjZU?= =?utf-8?B?THRqWkFUaGY0YlAvVWVkZDZ6VVY0UlBNSlBMdmhVdUY1TldUOENzaVZCMktW?= =?utf-8?B?dzhIeWlZL0tzVTdsVERjd0Y2YnpPVEhyTWtPbTJtbW01WUFCcTNZaW1YdU5P?= =?utf-8?B?Y01sUUQ1U1c5clhmMXVPYWVTZ3BtcjdLa2tqcWtrSHBEcHpNSGpVTSs2cVRF?= =?utf-8?B?RUJKaHMrM2NOS1RrUys0TWc0MzRxZGhBOTYvbmxUS0owNVZpdSs2MGFYZGdI?= =?utf-8?B?Y0Y1QmhWU0Rqa3pwb1JyaDVmMHlhSW5FMlh5aXpYMkp0VktybHJyd0t0ZU1S?= =?utf-8?B?dVlxdDJtSU92RVBRNnB6MlJTU1lzQ3lIaXRpaHl2N1ExRllabElDUC9Bbkpz?= =?utf-8?B?LzNtTHRnWDV5R2ZSdlpFQ2doRWRxTGJxZHpIUmQ1ZmQ1MkxYNGZ4Q0RFR0xv?= =?utf-8?B?U3lFb1hLVXk4d1ZPZEhWTTVleFJyZmNDM1NsY211ZXB5NG51N0RtWjNLaDE5?= =?utf-8?B?dk1YdVdqMlVTUGtzOUpOcVJqMjQ5QWJDUkZ4NmM1TWd5dHp4NkZmWGlhdG9u?= =?utf-8?B?RFc3aWdhNlRxL1RoYTd2anFhbXhHRXA5SVhuWUEzQ3VHVnAzMVdmRVZXRXpD?= =?utf-8?B?VWxhZjB0VjMxdWZxOWVSbmxzck1KTjNSR2ZMYVo5UWp0OCtUL1VSY1FCaXZB?= =?utf-8?B?WThrRVIwckt6R1Zkdlo3cXBZbEl1SmJ5V1k4N0YyTUJDWE95ODRtSnkzeFA0?= =?utf-8?B?eHl0UnBKRmFxRHRJUWc4a0lWcXNIQVNvWktNVnNKQUdMU0xucFlLbTRjb1cx?= =?utf-8?B?UDRtekRHV2xiMTByazErb0t2dms5U1BWcmQrTk9oTlJpZ0oyek5tL2FkNG5q?= =?utf-8?B?RC9Sa2pDSjl1SUVPdVlnak56bU8wUVVwQVFRUUUra1ZMTGozQjFubnE5NGlm?= =?utf-8?B?UlRQNzRuR3FyVkQrcHhNb0l6c0F4SnpGNjhueFVPRTU5bk1oY1FMb1kvWkda?= =?utf-8?B?RFo5YlNUcVFsc3RvOEYvWmptdER4cXBDaHh2MTdKRk02UXhWcWV3ajVEREcy?= =?utf-8?B?d2M0TnpEelJHakdmN3h3KzdPMk9sR2c0VUJqRVVZdDR6alA4L2lPZnhPR2k1?= =?utf-8?B?cGhoOEk0aFdpMU9UdkhHLzlXSHhBVjRLNmhETmMyamdnWDRscjlVdTRsK2Fw?= =?utf-8?B?Yk44WGZoOWRPTjVwci9wRGQveGRsdkpLeEhqRHpzaFZmbXlDR3NrZkNKM2da?= =?utf-8?B?dk5QSHBZMHRkTVJUZTNPbklSQkNRRUdTWWROYXc0eHp4MmMyNE9qMGRkbFJv?= =?utf-8?B?OTYzaHh3b2lLRmRyc3N2SGZaVGcvNFJPdkxrQngzS3JyRVQ3ZTR1ZzREV1pN?= =?utf-8?B?U1I2dDRmOS9kczB3Z1ZVOWVYdHo5SytXUjZKZktOcThjdFdmay9GS0Y4SnBt?= =?utf-8?B?ZU5OOTc5MEo0ZmNUd0tOQ1A4dmtwZmVaTDhuaWxzTDhpZzJ3aXd6cGNaTXd3?= =?utf-8?B?S1U0YklXT0hlV1h6V3daNGgrcnBYR0dCTHBsNTN4KzV4bjRiMFFUK0hjK0c0?= =?utf-8?B?TWIvVDBIYVF4SGV5aE1OWUVUR2dmMWF2aE1wY1paUmRaUjEwcGJjZVU2VURz?= =?utf-8?B?MnZQN0s0cEIxaDlvbmdLaXJkYkpPNUZzMDBvU2IxczVsNGprYXVobHczd1Ni?= =?utf-8?B?NG9EZldNTDl0aUErQ1Z2YXl5TFEwS3pseUFrZTZnM0hySmRrMVZsNW12dGUz?= =?utf-8?B?MTFhOXpqd25URlFMcTl3Z0dMTGMvZFVIMDFvQ3FHRms4SVJVc3RFOFRGdUxL?= =?utf-8?B?blJIb3A1eUJJVkdKeVh4T3VGeEptT0VhL3FhNjRpRmFqdURxNk92U2FITzJr?= =?utf-8?B?RTMwbkEyTmhsNndSa1Vrd3NBZDNEVjB1ck9WNXlEbEo3ZWROYnZEK0w0MEEr?= =?utf-8?B?NFNtQ0x3N3dTNEtaSU01am5lWjExZ1cyL0RCSzJHeUJSNDVrU3NIY2dQUXRE?= =?utf-8?B?YnVwd2ZtZG52MGptRHJxSXhMU01VWmJGUTZZZzZ1ZTVoc1IyQzlBSlNQcWIw?= =?utf-8?B?NkwrT0FtQVpkZWI2NnV3NlBHZGcxTS9CaFVVb0FaYTI4cGUvYTB4c1ovc0ow?= =?utf-8?B?T1JnUWw5V1lDcWxPK0dhdmJqQ2FHTnZraDVpOHltRFFVaTgxN0ZtUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ef52875f-0bbe-4490-f82a-08de4e16da15 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2026 18:01:59.0222 (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: aizouMNBN+qSS0YOimmBlCd0PorY1dDp/+Fxr1bRp/RVbWefa3Hm9nPP/LVEKhfj+DtxXQH9zs1bGU/H6GGS3Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV5PR03MB8411 The current logic splits the update of the amount of available memory in the system (total_avail_pages) and pending claims into two separately locked regions. This leads to a window between counters adjustments where the result of total_avail_pages - outstanding_claims doesn't reflect the real amount of free memory available, and can return a negative value due to total_avail_pages having been updated ahead of outstanding_claims. Fix by adjusting outstanding_claims and d->outstanding_pages in the same place where total_avail_pages is updated. Note that accesses to d->outstanding_pages is protected by the global heap_lock, just like total_avail_pages or outstanding_claims. Add a comment to the field declaration, and also adjust the comment at the top of domain_set_outstanding_pages() to be clearer in that regard. Note that failures in assign_pages() causes the claimed amount that has been allocated to be lost, as the amount is not added back to the domain quota once pages are freed. Given the intended usage of claims is limited to initial physmap populate, and the current failure paths in assign_pages() would lead to the domain being destroyed anyway, don't add extra logic to recover the claimed amount on failure - it's just adding complexity for no real benefit. Fixes: 65c9792df600 ("mmu: Introduce XENMEM_claim_pages (subop of memory ops)") Signed-off-by: Roger Pau Monné --- Changes since v2: - Revert back to the approach in v1. - Add extra comments and justification in commit message. Changes since v1: - Regain the claim if allocated page cannot be assigned to the domain. - Adjust comments regarding d->outstanding_pages being protected by the heap_lock (instead of the d->page_alloc_lock). --- xen/common/page_alloc.c | 59 ++++++++++++++++++++++------------------- xen/include/xen/sched.h | 3 ++- 2 files changed, 33 insertions(+), 29 deletions(-) diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 1f67b88a8933..49ca70334458 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -515,30 +515,6 @@ unsigned long domain_adjust_tot_pages(struct domain *d, long pages) ASSERT(rspin_is_locked(&d->page_alloc_lock)); d->tot_pages += 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 ( !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; - } - spin_unlock(&heap_lock); - -out: return d->tot_pages; } @@ -548,9 +524,10 @@ int domain_set_outstanding_pages(struct domain *d, unsigned long pages) unsigned long claim, avail_pages; /* - * take the domain's page_alloc_lock, else all d->tot_page adjustments - * must always take the global heap_lock rather than only in the much - * rarer case that d->outstanding_pages is non-zero + * Two locks are needed here: + * - d->page_alloc_lock: protects accesses to d->{tot,max,extra}_pages. + * - heap_lock: protects accesses to d->outstanding_pages, total_avail_pages + * and outstanding_claims. */ nrspin_lock(&d->page_alloc_lock); spin_lock(&heap_lock); @@ -999,7 +976,7 @@ static struct page_info *alloc_heap_pages( { nodeid_t node; unsigned int i, buddy_order, zone, first_dirty; - unsigned long request = 1UL << order; + unsigned int request = 1UL << order; struct page_info *pg; bool need_tlbflush = false; uint32_t tlbflush_timestamp = 0; @@ -1008,6 +985,8 @@ static struct page_info *alloc_heap_pages( /* Make sure there are enough bits in memflags for nodeID. */ BUILD_BUG_ON((_MEMF_bits - _MEMF_node) < (8 * sizeof(nodeid_t))); + /* Make sure max order doesn't overflow the local storage type. */ + BUILD_BUG_ON(MAX_ORDER >= sizeof(request) * 8); ASSERT(zone_lo <= zone_hi); ASSERT(zone_hi < NR_ZONES); @@ -1071,6 +1050,30 @@ static struct page_info *alloc_heap_pages( total_avail_pages -= request; ASSERT(total_avail_pages >= 0); + if ( d && d->outstanding_pages && !(memflags & MEMF_no_refcount) ) + { + /* + * Adjust claims in the same locked region where total_avail_pages is + * adjusted, not doing so would lead to a window where the amount of + * free memory (avail - claimed) would be incorrect. + * + * Note that by adjusting the claimed amount here it's possible for + * pages to fail to be assigned to the claiming domain while already + * having been subtracted from d->outstanding_pages. Such claimed + * amount is then lost, as the pages that fail to be assigned to the + * domain are freed without replenishing the claim. This is fine given + * claims are only to be used during physmap population as part of + * domain build, and any failure in assign_pages() there will result in + * the domain being destroyed before creation is finished. Losing part + * of the claim makes no difference. + */ + unsigned int outstanding = min(d->outstanding_pages, request); + + outstanding_claims -= outstanding; + BUG_ON(outstanding > d->outstanding_pages); + d->outstanding_pages -= outstanding; + } + check_low_mem_virq(); if ( d != NULL ) diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index 1f77e0869b5d..d922c908c29f 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -413,7 +413,8 @@ struct domain unsigned int tot_pages; unsigned int xenheap_pages; /* pages allocated from Xen heap */ - unsigned int outstanding_pages; /* pages claimed but not possessed */ + /* Pages claimed but not possessed, protected by global heap_lock. */ + unsigned int outstanding_pages; unsigned int max_pages; /* maximum value for domain_tot_pages() */ unsigned int extra_pages; /* pages not included in domain_tot_pages() */ -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 07 18:08:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 18:08:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197123.1514766 (Exim 4.92) (envelope-from ) id 1vdXx1-0004nu-KR; Wed, 07 Jan 2026 18:08:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197123.1514766; Wed, 07 Jan 2026 18: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 1vdXx1-0004nn-Hn; Wed, 07 Jan 2026 18:08:07 +0000 Received: by outflank-mailman (input) for mailman id 1197123; Wed, 07 Jan 2026 18:08:06 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdXx0-0004nR-Jt for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 18:08:06 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d00d5d43-ebf3-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 19:08:05 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS4PR03MB8400.namprd03.prod.outlook.com (2603:10b6:8:32a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Wed, 7 Jan 2026 18:08:00 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.002; Wed, 7 Jan 2026 18: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" X-Inumbo-ID: d00d5d43-ebf3-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IxaZB/LiURLxp4fFfcMp/6C2db8ozNwC6f8BfuAH0/mS5VSOl+HJH9QM2fpX8Ftx71aP8A1iovIhzx9CBbFfZwC1TbaubX8cKz10HWdbKlrJWSBc+YJKDq8NmuethxJUANtSzwyj0mDJJYyR/lZ5ulprSH3Ns6PoVqdlspACB8wolYxts2tvFqJsIuTd+gy/yUMCB0w44/EjEJLr3ucvYafGzr+3cEm626xWkX1TUeU+aKWdG9g02lrIson95eksmhwweZLY9Tb2yFXVGc+Qi9Lf2QctKdPlkCyx2Ej3vNpOGcgUBzUITMI2ZAzKvqA9a2rqN/vH0DXGJJ2ZpLD0lQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gUniAz9j09liMw8KdzdGqULjOflNM1Bt11OQ/cpWik0=; b=voCeBUYXk/D9wapRf1BdzD08vT6W4C4Y+oprf0CB9knRyA3fZPczKOrbsRvbytLXDY7MCea+fMus2lkQkv7Gjs/O1ZuIaTzctwBol49UbQLPlP02k5wl9koRZVPTBXC/+Gn/y3iPPhEJmM7xbV6td/tGIuGwXpSiDnL+v95qsUhBXWZPSzCrm0fpEquAvpf7skLnAeEEhF/5n/GmT1l4yXhtCUS5xq6V5rKtlc1Npp6Cc6wgo3BdUGIBLmH5yCp/IC0gSHI4ZLaRxBIQjNBVHU2Q16e2Lyddpk04t8WkwC3J6Kllee2mWWZ8+iHQ65s+iRP1DQD9OT19Rp3pnp8VZg== 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=gUniAz9j09liMw8KdzdGqULjOflNM1Bt11OQ/cpWik0=; b=0pxY5t7bFxrgmmNpqoeIsbQbK7xicnxtEVkx0imeiLvaYh1B2BAOUpw3fOznTILpAL3KpliVNJCG1D2jKBxNhgY82bKDRSJ1MP4JMvLbjzkXaawJP9u93t9rD7FHqN1lXr53osnfLPGinmovQGtMbfjxOkE5CgjBrdyx592UQAI= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <61ca5e49-787f-4d99-b2cc-5e95d8160c39@citrix.com> Date: Wed, 7 Jan 2026 18:07:56 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , xen-devel@lists.xenproject.org, Jan Beulich Subject: Re: [PATCH v1 0/2] x86/pci: MMCFG improvements and always use it if available To: Teddy Astie , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <104d15d0-9f58-403b-ac61-dc02f4a2e097@vates.tech> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <104d15d0-9f58-403b-ac61-dc02f4a2e097@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0333.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18c::14) To IA1PR03MB8288.namprd03.prod.outlook.com (2603:10b6:208:59e::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS4PR03MB8400:EE_ X-MS-Office365-Filtering-Correlation-Id: 797d7a03-5e6a-4911-337f-08de4e17b12c 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?RXhUdFdKUklwNHA3SlBhQkw2QVkwUGZzNTJuSkhuRTVnSzlqT0ptNzltMFh2?= =?utf-8?B?Vlp6Y1RDTkFqd1FxTWxuK00xRy9aekJRbTBrYkZtT1lmTGIzb3pub2NvNnlL?= =?utf-8?B?a0RpYm5PSHpWcjBSODYvQnQ2MU51QVYrR0VVVHFpMDhqZmRGV0YySlRjR3Uz?= =?utf-8?B?dlVXWWR0Ym9SZG9OQ0lZd2hKei8xeUFDQ2pGN1hMZTJGVUV0TXdxcm1SSHJx?= =?utf-8?B?WTR5RzUwS1BkVS9xQ2RjOENNcEFXWFlLbjViUUhDOWlHbGd0empDQlE5UXNS?= =?utf-8?B?UTdRdjhWaFU4MXU2and0RVRTZjhYa3NMWVk2YW1qMk85SXhTbFFFVGZuWUQ3?= =?utf-8?B?ckQrcncxZEZ4M2YvYVRyMURSNC9XRFFyWWlSZitEREdlQ1JHeUNZSjZUeko3?= =?utf-8?B?dGRWUWYzd0dWNS9od3p2ODJuaStMZk5oMGsrRXIwZDlMRDNGOUhCRU8zWDd1?= =?utf-8?B?QitLNlFCVWEwNjdweGNhN3ptTVhPNS9pRERsNWNQclhORGhZd0oxWDJtM2h6?= =?utf-8?B?Y20yZFRLVzQyOS9sMGEvQmpHOXgzTGl1Tm8xbFdsSlFnQWRhR1ZZTlQ1dkQ5?= =?utf-8?B?NldrRTZBRk5haXYvTjJZWFJOWElwQzk5Vm9RTmd6MjhySWpzOVZvNWVMQXRY?= =?utf-8?B?U2ZQZ1NEQWJpbnQ0N3ljc0NqU2dkOW1tc3Y5aE1GL3cxaEhvTHZMaEswcHNQ?= =?utf-8?B?N1dGRVBoSjYvNSswSWxCRVQ4VDFhdnhHRVN4QlZ5VStGYzV0dnM3a2h6bm90?= =?utf-8?B?ekV5THNDSlhyaHd2S0VUUEhyNFVKMGk2OE1mMUhDTnBhTk02SHJFMVNyckZR?= =?utf-8?B?d0ljakJEd1dqUTlUYitHQ3A5bldtSnd0RVVvdWNTNVdpM0NiLzV5ZXRJbzRG?= =?utf-8?B?SENwT096bFFqQ25Sam42T0xuUGJlWDNHTEorbE1mQ2RkQkpHRE5FejJDYnBp?= =?utf-8?B?VWJlak5hNUZ2RmJLU1R4cVYzWE4zdjBkN0xqc1IrMFR2MldCby9LalJtYXpN?= =?utf-8?B?RUt2MGlKUzUxeExWc2hlR2NYSW9seVl2a0ZiOGhSUEdyQlN2dTlMd3U5VFpq?= =?utf-8?B?V2FQU1NqajJrQVk4RmdmNWphZnNvWDAyNloyTGZvUDdxNnRVd3plOFEzeVNh?= =?utf-8?B?czlLUmtPaERhWWgrWERONWpRSnk4blo4NWRwWXhlVGUxMlh5R3pZSC96WHJm?= =?utf-8?B?R3YwVW1ZZzNnTzFlSGg0SGhiT3kveGlrUjhPSm5pS3MvNFBBM2RjTmgwU2xR?= =?utf-8?B?KzkwRUZTSmJQL2hEQ3pheVNEdGFzOWlJNGpDdEVyb2REUmJQT1lMMlNSWnZC?= =?utf-8?B?ZWU2SzljbHI5WTR1OEUxNDN0M0t3ZXhMWmI4VE1qRklxc1FqeHlmdTkxSU1M?= =?utf-8?B?WUpTNFNnRGJvbXhJY0taVEVwb1VjQys4dTBVTEZkY3Bhcit3MlpiYmd2R0VC?= =?utf-8?B?WEIxbEVNOFR4anN5OGpKRWU5eXh4a01YckQ3QmlPYjROZ0Z0Uk1kRXZaRDFa?= =?utf-8?B?MjFZQUd1ZFZkK3d2Z2ZsMkIveUU2b05hS2QrN2Vja29pcFdDVUJMSklqcXRG?= =?utf-8?B?bHgzSXBzRlA5aHJWbHN4K0R4cVJOaTNrZ01sV1prTndBYlV5Y0cvVGRxY256?= =?utf-8?B?SzVHa0I0ZjBVdmE2K3pSK2NJek9yalNveWNqTldHUTc3MzB4b2p4bGd6S05z?= =?utf-8?B?SkEwTG9vSmppRGh6T3JRZ0ZPeVJRSlI3RnQ5Y2VzQ01md1ZQNmRhUWdDNHNJ?= =?utf-8?B?Z3dnZ1lnRnhJcDgzbjBWbVQvU2hnaUZ6OVlzTWRzNEVjZUtDcHhWYW92QUpX?= =?utf-8?B?SjM2VG5mU0tCKytMNEpqWG9McG1DR2RXNWRjVVhYMFhTWVNQeWtFVjl6c2Uy?= =?utf-8?B?OGlHZjRSVzVMQ2s0SVBPUDVQZ1NqTmlVRkJOUDVTbXlubzNYMGVMaEVvU1M4?= =?utf-8?B?ZDZsdGZWMlgvRitQdStNaXFmbG80aHZhZGJSVnQwTWNUb3ZvdTVZc040M3ZF?= =?utf-8?B?eUcwdDZyQzBRPT0=?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?K1FwYyttZVVHbGcxLzNZWDZiY0JCeHFuMDB6S3RaRlZDOW9KYmNyUE1iVmRj?= =?utf-8?B?T1YwdlBoMkhxOVN0cVp3ZXBrZk9vT2xTcXhPOTB3WXpWbEF4Qlg1Zjc3MzZ3?= =?utf-8?B?WHVpWFY0R1R0djV6bVllanNCazR6UDJpZkNmdTNZUXR5VitVMHBETlYrTDNJ?= =?utf-8?B?VmkwL05rRlhtQ3l1TTIySG10bWdQdTZIcFNJZXZidC85Y0N0aGhTb0FwWTdN?= =?utf-8?B?aDZPRDBFMDBJckpuMTFxNUhRakwvWVhhZk5GMTk3bjRMN2NoK0didlBuM1h3?= =?utf-8?B?MFZka2x0ZWdxR1JoNjFscklLb3VxbmRQbEpjeTR4bmtGN1U2YlJrMG1nUVlk?= =?utf-8?B?SXNwMG1CMVFVbWVPWnkzMGZCNThETVVSM2c4TVBGdm9FMVdpc1JDVEhLWXp3?= =?utf-8?B?ZXZPY25SQjVsNUxrZnRZdFVCR01Nclk1SlJqMkgzZFhYUmhuL3lxN05vVTMr?= =?utf-8?B?Mmx3SWhSblJtdEJUaisrTGZ1OERVWm9qVzJITFFzNlplMjRDMFJNODU0Z2ZB?= =?utf-8?B?b1AvaTBCUStjTitsdU5jazloTW83UWowbTVMclBjcUZyODJzUGlwd2oxWDFE?= =?utf-8?B?ZEcvUU41cWdPdkp1SEpJQ2lXWXJNU1MrTXdxN2VhYW55Z0h3RVI2Zjk4RnNp?= =?utf-8?B?Z244eGpsV0tjTjY4WWVONGNIMHNZbjBrTW4wNEJReDVnUFAzL1Y0RVk0cTl4?= =?utf-8?B?dmZZWE1jekFpSjRRenFISW5TQytJRGlrZWtneWJycWNCNWwwZmlZRjAzTWxi?= =?utf-8?B?ckp6dHdCeTZac1AwNmd3elNnQXZMTTljNXRBbDVabjlBUEpYcE0vbGlUNFZ0?= =?utf-8?B?SHFpL3ZwT2M0VWNENWJmelQrR2hwZGtmZDVoWlBId25SMU1uQ0F1NkNsNDBG?= =?utf-8?B?QjZaMFplZTFQcUp1WDJqRS9rYkh5T1pzdlVIMjZiQkVFQnJDekx2bXBKcjMy?= =?utf-8?B?SFdKb3pkVHpCUy9XeTFXOVpWb1VZOGZwZGJMakZtbUx1YzR5Y3N1RE1zMEgy?= =?utf-8?B?VXpWb09rYVlNcFdBZWlGRTNKbXBlRjlvc0tMRkR4Wm5rOUc4OHEyRWNXM3dS?= =?utf-8?B?cHRIMUNaSDB0QUUrZ3J0NThaVS9hSjE5aTN4ME5vZTlzMHJSVkE0MzRrQkZH?= =?utf-8?B?YlREd1BGQStEalNSM1daSjdiUWQxQlordUtXN1VTb3NqdlFBb0JPY3VVbnNY?= =?utf-8?B?SjduUEtzVkJvbDNnS2tvcHV6RmtBT1pJeDBTVkcxb2NzanBza3QxdnlPSG9D?= =?utf-8?B?THYzQlJTTllZcTU0bHZkeWNTamRtTFlmRWQ4WVlaUDM5MFkrb2FFUWg4S1JZ?= =?utf-8?B?bWZSZFYwUGxGS252Nk93VGpZVGFKVDM1L0dwWGFZSUUxVFptT05mamFNbkNH?= =?utf-8?B?WjVtdDcxRlpuYmhxNjE1U0VCWitncytMelRyWjJOVXFQd3pLdjdmU0NmakNp?= =?utf-8?B?blhhWnhsZDd4cFhrS3pCcTYvZ2g1L2hTeDYxbHlSUGJPa0VjZ0NIZWVrRGJL?= =?utf-8?B?Y1IwQXl5Wi94TnJXY0lFMzI1SlRGem9vTTl4Qm0rY0diS3FhcEpnT0szN2E5?= =?utf-8?B?d2dXempSUXpwMHlodGQzUnhvaEFROTc1Vm10N2JyZDJPUUo2VjYyQ3ZBVVFS?= =?utf-8?B?eXhscFhVMzE3dUJLTWQ1Yk1zWXY4TlF4WTFsekREeXFhTWlzZmEzYjkvNlBU?= =?utf-8?B?SHpyRDVUak81QVVuaFRzUDY1czBuN3YvdVBsYjJ1ZnkwY1ZRU08rejVVZ2Fj?= =?utf-8?B?MzdubEpBQjRuRlIvdzh1c3NhRmRqRHdkNnZYRDZnbW43cXF5bUhENHhKU2ln?= =?utf-8?B?OTNRc0VsaEE0RzFHamFpS1BpOGw0VXJRbytSK2Ftbjk0NHRQek9OZnArcGpu?= =?utf-8?B?RlJXLytrQXQ5WXRyWC9STkZWQmpaeVh5QXk3SDZ1L08wZVc1NFZ5L1htazA2?= =?utf-8?B?bUxFaHg1aW1pNmtNTnRXaW5VVEw1bXJrWm5xdGtJN1RaRUpTWjlneDZhMWVj?= =?utf-8?B?dE9mZk5PcWY1VXFBRFNzYmtZWXY1VVJ3VzVOSFYzOFlpQ3QrUi9NUWlwVk5K?= =?utf-8?B?MysyNnR6YjI4aVZLeGs2UXkyZ3krNXBmNUNoa0loTFdMSEtmK1FreXJFM25O?= =?utf-8?B?YVBFall2NjdWQTFxWEhXTFlMbnh4UkpFcFNVZlMrL1A2bU9QLzZZeFRjcFho?= =?utf-8?B?ODh0aERNdXh1clo2OEkxL0wxTytLdzhMcnFGcU5IbVNaWktXaFBwaVlxc2pm?= =?utf-8?B?eW5tS1dSdzhrdFBUbDFGTVJrSDJ5ZWdhaHllWXFzbmFiNjE0QW5TK3AvRnU0?= =?utf-8?B?b0RJUXh0cWRwYUc5eVJOU1M2dUkycUlkdXA0OVh4cHc4Ly9hQVJUZlN3VGor?= =?utf-8?Q?1MIrm/HtwN2TXwjc=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 797d7a03-5e6a-4911-337f-08de4e17b12c X-MS-Exchange-CrossTenant-AuthSource: IA1PR03MB8288.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2026 18:08:00.1842 (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: 0hfZ1F1Js/IldCLotuUY89UNUo/wATPXLioWhCcsR5Jr+W5QvpRwV4T1zkCrtPJRCn8pMi7sSHAjSOi/f3SfWDh4jIcAzI6nHg5Am2br01g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR03MB8400 On 07/01/2026 5:58 pm, Teddy Astie wrote: > Le 07/01/2026 à 18:25, Roger Pau Monné a écrit : >> On Wed, Jan 07, 2026 at 04:54:55PM +0000, Teddy Astie wrote: >>> Currently, Xen uses legacy method to access the configuration space unless the >>> access cannot be made with it, where Xen fallbacks to MMCFG. This is not really >>> great, as MMCFG is more flexible and doesn't require a dedicated lock, so it would >>> be preferable to use it whenever possible. >>> >>> Teddy Astie (2): >>> x86/pci: Improve pci_mmcfg_{read,write} error handling >>> x86/pci: Prefer using mmcfg for accessing configuration space >> AFAICT Linux is using the same approach as Xen to perform PCI >> accesses. I think you mean "Xen inherited it's PCI code from Linux". :) >> Registers below 256 on segment 0 are accessed using the >> legacy method (IO ports), while the extended space is accessed using >> MMCFG. Do you know the reason for this? I fear there might be >> legacy devices/bridges (or root complexes?) where MMCFG is not >> working as expected? >> > There is apparently a errata on some K8 chipset according to FreeBSD > code that uses MMCFG whenever possible. > > https://github.com/freebsd/freebsd-src/blob/main/sys/amd64/pci/pci_cfgreg.c#L261-L277 Using MMCFG is *far* more efficient than IO ports, not least because we can avoid serialising accesses across the system. If it really is only some K8's which were the problem then lets go the FreeBSD way.  Both Linux and Xen both talk about AMD Fam10h issues, which is the fact that early AMD CPUs only allow MMCFG accesses for MOV-EAX instructions. There's also loads of code improvements to be had.  The current APIs are inefficient to use, and I did some cleanup for them for Trenchboot where there is a 64k limit.  (But this can strictly come later). ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jan 07 18:44:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 18:44:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197145.1514776 (Exim 4.92) (envelope-from ) id 1vdYW0-0001R6-7g; Wed, 07 Jan 2026 18:44:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197145.1514776; Wed, 07 Jan 2026 18:44:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdYW0-0001Qz-4V; Wed, 07 Jan 2026 18:44:16 +0000 Received: by outflank-mailman (input) for mailman id 1197145; Wed, 07 Jan 2026 18:44:14 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdYVy-0001QV-MA for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 18:44:14 +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 dc1fe8be-ebf8-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 19:44:13 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id CBFD140B7B; Wed, 7 Jan 2026 18:44:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A86E3C4CEF1; Wed, 7 Jan 2026 18:44: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: dc1fe8be-ebf8-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767811451; bh=IH21crszxnBTVgvTDCeHc7bX7rRWsx2nNWiLJPSphcQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=MdCtA3FNShuf31iQMbrSF5g/ull+tA/DE1jdmZ9hC661ftP22oqKVchaJFEpJ0mMo KowB9X/s8xwE3BGfVMbC9jVoKRTW5/uPBifyunGAvBicAT71mCnUStODkPis6TJQtN x6flnBavDFX1fGFFmabCHJovgpKfavttORyphhoOmLAUlUO9JRSTGdWjUc3hg21PTe It8evnTU6S1XP0A5XVVMfsMis1nN4Izi5fCjrhcUKrYRnNPWPN+7b3O1kl9G+rlSJI QAbkWnxF+BhVhkwtJmgMw8BlaDN3MVgd0ueL+UWmNQUiFD4PWXohyPZRmj8+ba8YkV XdkFwltTD0wrA== Date: Wed, 7 Jan 2026 10:44:00 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Andrew Cooper cc: Roger Pau Monne , xen-devel@lists.xenproject.org, Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: Re: [PATCH] cirrus-ci: introduce FreeBSD 15.0-RELEASE as "current" version In-Reply-To: Message-ID: References: <20260107173509.56155-1-roger.pau@citrix.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1837582523-1767811451=:286060" 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-1837582523-1767811451=:286060 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Wed, 7 Jan 2026, Andrew Cooper wrote: > On 07/01/2026 5:35 pm, Roger Pau Monne wrote: > > Switch the current version to 15.0-RELEASE. Sadly the 16 snapshot images > > are not working, hence use the FREEBSD_CURRENT variable as a placeholder > > for 15.0 until the issues with FreeBSD 16.0 snapshot images is solved. > > > > Reported-by: Andrew Cooper > > Signed-off-by: Roger Pau Monné > > Acked-by: Andrew Cooper Acked-by: Stefano Stabellini --8323329-1837582523-1767811451=:286060-- From xen-devel-bounces@lists.xenproject.org Wed Jan 07 19:19:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 19:19:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197163.1514787 (Exim 4.92) (envelope-from ) id 1vdZ4A-0005Vb-Os; Wed, 07 Jan 2026 19:19:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197163.1514787; Wed, 07 Jan 2026 19:19:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdZ4A-0005VU-M0; Wed, 07 Jan 2026 19:19:34 +0000 Received: by outflank-mailman (input) for mailman id 1197163; Wed, 07 Jan 2026 19:19: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 1vdZ49-0005VM-8R for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 19:19:33 +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 ca59b63a-ebfd-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 20:19:31 +0100 (CET) Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfhigh.phl.internal (Postfix) with ESMTP id B9FBF14000FC; Wed, 7 Jan 2026 14:19:29 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Wed, 07 Jan 2026 14:19:29 -0500 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 7 Jan 2026 14:19:28 -0500 (EST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ca59b63a-ebfd-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1767813569; x=1767899969; bh=rjlyU6n6NQN+n4tpxvCX19FpLU8GV94niAV2v1LdhJ0=; b= bVAhzkicWTvAzPlKCKTAGL8zUdj2kqPhoPNBpPMBo0cjEzk8LzzK4lJkbBp9TygV /8dJPKu6fF9BrEAvwF245vCUzqV2ro8Rs1fETPodkMtlVyoGpukiCTRG02QfKp4h sK845QKJVpDu0G/zGK/8qOuQOr12rQFeLEKE9BolemaFla8Dwp0iIA1vcmTETx+d WZy3Y6qepcWOS+P5BYcuvNkJNG8tfPGrVI4Tky+tNA1PZZ5irJsZESqAKlAbpdU3 UCDcaaPRvlAucA0BL0aXYuZUp65Ub1D96Lgwxg0OJcKVbKGhDyE9iSi5e/Zt+NeR Wee+CMvHFkde8VsWp1PV0A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1767813569; x=1767899969; bh=rjlyU6n6NQN+n4tpxvCX19FpLU8GV94niAV 2v1LdhJ0=; b=a/v3gxW7rxsXkS5BzWw+HTsx8S48pmxKtZVKkKnjmsoGr72i7YB TZuX0/2CX2OBwjDILkvljjshVrKKtuXIfB9TY0uuIxn4PweIE1GCl8h5wjOBlU8v oAH/Q/LjC1UjsN2nGuxpDfNphJcNtVqP8/sSpR64ooGnfgQP9G12FeKM0y9ioqop Xn192c9C6JkiI4/Vh8lCHjGOnaWkvXHTX1k5Il2Gt4U66YOFjzU7OPBay/doNacS aaSRQuakRMCuQRXz7DwYbi1vgLJrqSpGusO8iVyFrOsL4PinJGCut64hNHfol5Ob ILtbWMVlnRSRGK9qUXyIXRqO1gzPbQgx2tQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddutdefkeelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcu ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfduleet feevhfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehi nhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepgedpmh houggvpehsmhhtphhouhhtpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtgho mhdprhgtphhtthhopehjrghnughrhihukhesghhmrghilhdrtghomhdprhgtphhtthhope hmihhlkhihpgifrgihpgeftdeftdeftdesphhrohhtohhnrdhmvgdprhgtphhtthhopeig vghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrgh X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Wed, 7 Jan 2026 20:19:26 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Jason Andryuk , Milky , "xen-devel@lists.xenproject.org" Subject: Re: Cpufreq drivers not working on T480S Message-ID: References: <6f02aca2-eaca-48b8-a2f3-4afff42ad264@suse.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2HGh07lK15T6GBLf" Content-Disposition: inline In-Reply-To: <6f02aca2-eaca-48b8-a2f3-4afff42ad264@suse.com> --2HGh07lK15T6GBLf Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Jan 2026 20:19:26 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Jason Andryuk , Milky , "xen-devel@lists.xenproject.org" Subject: Re: Cpufreq drivers not working on T480S On Tue, Jan 06, 2026 at 09:25:14AM +0100, Jan Beulich wrote: > On 06.01.2026 02:03, Jason Andryuk wrote: > > no-hwp failed to disable HWP. But if there is no ACPI CPU data, it > > wouldn't work either. >=20 > There isn't any "no-hwp" option that we would recognize, is there? Iirc H= WP > isn't enabled by default, so simply not saying "cpufreq=3Dhwp" should dis= able > the driver? (I already found the original report confusing in this regard, > hence why I preferred to not reply so far. I wonder if there are local > patches in use.) Qubes has a patch enabling HWP by default on supported platforms. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --2HGh07lK15T6GBLf Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmlesb8ACgkQ24/THMrX 1yzl+ggAhQ+BeDiQz/Pds/RTCcpAv/R4Lq+fwTa/ahy0ZN8kODVZ+PHo+IcJ/67s Q2tBIuf/EZFIQkzpOYd9LiPAfTNpX7nES8XW8kgq1uMwQvKj6EpuxTzjXrcIftH7 0NQC3nxzeFnWaBaorPibyk+9pRaaABLFGHS3W/LSVXykp1XzzsjdEQS+BPDHquLl g5nj9ELS2yGcGnInompHuUJZXTkWbDMcKKvE5gOLmBlq44XhvwE49xKluCjcYlSR bn6NfN/ta20b7sOudE7MLZWnodvXw4u1icPbcZTsFtXM3064TTGAlmCciPbijz51 +doT1KpfKox+xhZ0f+aeLA67W12zgA== =g0tv -----END PGP SIGNATURE----- --2HGh07lK15T6GBLf-- From xen-devel-bounces@lists.xenproject.org Wed Jan 07 20:02:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 20:02:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197193.1514807 (Exim 4.92) (envelope-from ) id 1vdZjn-0003MX-6p; Wed, 07 Jan 2026 20:02:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197193.1514807; Wed, 07 Jan 2026 20:02:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdZjn-0003MQ-3K; Wed, 07 Jan 2026 20:02:35 +0000 Received: by outflank-mailman (input) for mailman id 1197193; Wed, 07 Jan 2026 20:02:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdZjm-0003Ki-2h for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 20:02:34 +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 ccbeac17-ec03-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 21:02:32 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by BY5PR03MB5251.namprd03.prod.outlook.com (2603:10b6:a03:22b::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Wed, 7 Jan 2026 20:02:28 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.002; Wed, 7 Jan 2026 20:02: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: ccbeac17-ec03-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VsTxTBwzVhxj0G/zPiq6MeI7UqjHEOlJC11czgQR/SmwvtTCogCvQ3dCtHoyfX9TTg43bFn1qj36sG6GeJNiCqfG7llAo81ZoPrUngoZOlpowj4vlCNfPWPqTwf3pXNhYicGcsGA5JD047Z70CsIIP4a3HT7njYSQNkCWOyFhPHtjtShk4B0FsoFrvD34VBxQx5ztnK4SydQqzaKEmKJLXoMe5O3RzAhCfZg9wgW+IDGH2NYKAv4vB3KNVMi/A8hOdtat+FVpoVA+WGrVhlggoV8Ae32Db8bnT3w7G/ZPfzU1t1VIC+OrdMR1jHW8GttdD44K2IkZUY1kzsrKJ4CJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QtO4dyY2bk0OojaSqZIHZkJptRIqFJUH8tYD5NasuEU=; b=OOU4SbIzhXitcBGGMEi6+GiJmxZjSbl4tor10BYvYcmF/q7znTrtLtFzw9O8jJ6f2CS2Ki76l7Lshj/7qPHwkYRI4SUqy86p/ptgrZ9bvasABJnDXiyHr7KsHDl3H1YLZha1zN88Z++Dc2cxLKnD2IpvakmJRypzy/ISeGcpWWldQosFVLKvkek8fkIuIdC5A8TdEHwxhFD0kI12WFsmhnYQgU8mljLr7PlLvrZa9C48YSH3G2JvTHQ95Vme3TF6TMK/yEEfhhL+MYVXogaXKT0fjgnr3bhwJf6R0GstsRgdnFaIkhFDn8H6aYVDhDTEkXp0YAZV/flvYi4+jVUf0w== 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=QtO4dyY2bk0OojaSqZIHZkJptRIqFJUH8tYD5NasuEU=; b=TzhuGcUzdwVGq207xHtNMgXPK8XyzGwoUKFTcyx5XbXoqfizulHAvs09UbQiprrk9e+EY+6gYOxycn5Vb/66iFZ59odHCQ/yvY5I0WqqMbq10tIrmuVc5PcqCXqfJIe/rjQp4b+gz/Smdm/3SbI1UbuCRQCHxiEhvjxda+M8gD4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 7 Jan 2026 21:02:24 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: Teddy Astie , xen-devel@lists.xenproject.org, Jan Beulich Subject: Re: [PATCH v1 0/2] x86/pci: MMCFG improvements and always use it if available Message-ID: References: <104d15d0-9f58-403b-ac61-dc02f4a2e097@vates.tech> <61ca5e49-787f-4d99-b2cc-5e95d8160c39@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <61ca5e49-787f-4d99-b2cc-5e95d8160c39@citrix.com> X-ClientProxiedBy: PAZP264CA0088.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:1fa::6) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|BY5PR03MB5251:EE_ X-MS-Office365-Filtering-Correlation-Id: 28560052-a8f6-4769-ca45-08de4e27aecc 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?VnNlRHBJSjBqaU5QS3BpcmFpdzB1VXYrRENRempOcWt4RXdoSHord0Yvc0VF?= =?utf-8?B?Sk92YUtwT2dqNGc4TzFIZ0FpRmxwV0g1RjByUXVBYUFCRVN3a1ZwaGc1a1U2?= =?utf-8?B?ajBYdU1lMDYyZG9LL3A3bU9YakJCK1d2UE1FWjdXcFBIQVJYd0k3VEdzVkow?= =?utf-8?B?VGNCTkN5VElPVVdJalRDcnFWa0l4WlhXNlN6V3VqRDRVODBsYjVRK3l3R0Yz?= =?utf-8?B?U1JtQmVUVURtR1p6NGtIaUpUN2NRKzFJQWF5WGJ2ZThHT0xGWnpHZ0F6YllK?= =?utf-8?B?VFVJamg0OHc3RjF5bExad0xZM3ZrYTFkR3lmck5rSVhFbk5aT29DYytOemJ3?= =?utf-8?B?cks4RmtIbGtqTGJOR1FseHdtY2JNV21YV0xENG5mb291U1VaQ1ZEeGErY1hu?= =?utf-8?B?VzFRNFY0WDJNSHR3aS9CQVIwdE52NmVRVTVKbUhqZ0tMekhMbVQ4R1Q3UVJo?= =?utf-8?B?RFBKeUw1a1JvUTVZMytubjd0L0dXSXh1cm1XbmtCd1UzVjdWYTJYM29CZWRv?= =?utf-8?B?UVc5TFVxOEd3dWpQMHZKYXc0YXVER2dsZUdhRU5kaDFkY0V0Vmh4MXZNTjQ5?= =?utf-8?B?bHVnTHc5RGFpNUozM3JmMnhsQkRnTFVRb1hWb2hJUElkVVlDbWVJclFRMjRN?= =?utf-8?B?T21pS0ZrYXVaaXhSZXdZcVFBbkJseGdiMnMvblMrV2p0cU1aNDBwRVQzR1Zj?= =?utf-8?B?NDdnQy94SGZlbFFzb0JkaU1QcVROa0xvQzFZdFl6UFM2Z2FGdmljNmtqSG45?= =?utf-8?B?b2VIdWR0alJZZWxGZmFvYnNEZlJvQTNzZUNiUFhzVG5LeWZrV1hUMlowakxi?= =?utf-8?B?OEcycjU5RC82NWtXTzZ1a0EwWjYzWkFtTng0Y2VlblZzdjR4TG55NkI5YWhS?= =?utf-8?B?d1RqZFltZ0ptTllta1hVTE82UDVQSVdHd05TSGUwNVRjN1lOYnFzM3hlSGJv?= =?utf-8?B?THpydDlVdUlBWmZpUnV3clhIcXVTRUtYN0dYZXY2bVVJSVNsR1FjY3JaZGZC?= =?utf-8?B?UmdaM3p1MU5STEhtNUtJaS94dDgxRE5OMzZFN0IySHBtUFBpRHBENHp0NUpv?= =?utf-8?B?eUxpdmZLWXRPNGxnZ0E0ODZEWVZwMlhNNnpScE5CZkNQTjE1bUIzMnYrdWZR?= =?utf-8?B?ckpkdFRCMElKdEgxb3IzRnNZSTJBUEtRYWdNTDczSnowbEFrcEhGMFFwNzVB?= =?utf-8?B?UDBQTk1MenZCSnczZWY4MW9rdFZFa1hRbkVSWHJiUEg5YzBFeFJwZjdrYStu?= =?utf-8?B?akdXZW9TK1hMenFiTjJkbFRueGh0MFptcFQ5d00zUUtBMU9zbTlneXF2eWdk?= =?utf-8?B?WEE0KzB1RnI1OStMKzFnQ3hKalJLOW5aL1BTQmhEVmlaV0I1NENNSSs1by9B?= =?utf-8?B?Z0h1ZjRMWEFCSmw3cmxZRDNpQll2dTk4UWZubE5Sd1h1SFUxTGVPeCtGQ2d1?= =?utf-8?B?dXdJWDZHQVJlQk9BdzZLVEs4Q3RQQzJNQVA4RlFFUnk4NXJwODNKbVFxUGxl?= =?utf-8?B?UTRzVkluSFluVjlscDBrc1c3RUNISjJmL2xtd0RiNzFzNURPUE5oUlVWcVJ3?= =?utf-8?B?TC9McWF3L3lxQklETDFPYmFNM000QVhFenZub3kwYzhJNk8wSm0xZGdranhF?= =?utf-8?B?Z2JSeUdiSURIbStaTTJwSlp2RnZsd0tVY2djU2hHa2gveGFOUFlPbWpMTHdH?= =?utf-8?B?ZVFJT2tvdU9vWkxtb1F5ZklsRjhNRmlnU3h4ejFwbit5S1ptNVpDZGhOWEh1?= =?utf-8?B?MldrZXRrZUV0NVQvVU1UVzBsNm5zZGZkeUhLZVBkcU04UytXUE43TjBPMkxt?= =?utf-8?B?cjQ1VHdsbWxabkdOM21VNkwxZFJwSlVxVk1TZVFITDRlWHovQmExS3MwdXI4?= =?utf-8?B?c1ZuaG1HdnhmVG1OelduOXlNNkN2eks3TndUQ1ZUcWRvOGV3Y1ZXQVZtV2tR?= =?utf-8?B?OFRFanZVc0RLQ1Z4U0dLS3VPam9xMFBZMVVEMDN0MWt0SEZWdnlMUmY4RnFq?= =?utf-8?B?TFhNWENzOEVnPT0=?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZU5PUWpJenEwcUxRWmlsSWlqT2VuckM4cFJjT1RKNDRpZGlwbDZWdDVFKzY1?= =?utf-8?B?bHlDODAzUzc3WE5PV0lUcjB0WkNxcGliQU81aGhkR1R1aUZUY1hkZ2pJeC9Z?= =?utf-8?B?TU83V1d4cGlIR2FZT3NWemNyY2ZzNkRwb3I4Rmd6Ni9Lcklza3Jvbi9EdFlY?= =?utf-8?B?aktzWkt4OG5xNnMwejVtYVJjRVZoZGFIWm1ERVUra1YzMEhvRVJHSmVLb0Yx?= =?utf-8?B?cEU4S1M0SnRXSUFaTUp6dWdPUEYwTTNQeHJ3NFJzbW1HcG1uSWdsTlR3Wmtt?= =?utf-8?B?QjFKdzY3cFZqdStEeXU5TTd1L1ZpbFl0bVJRbW9ZeVhxNWFBU0xEK2VtcUN1?= =?utf-8?B?bHRhL2FtOC84S1VjZDczWmR6bnJUSGVZWXVtZFYwaWZ6a3VrSVp1RGV6ODlV?= =?utf-8?B?QjRsZEFsYkd3LzU3SDVMemtoVmFXOHJRSHg4Y3lPWmMwaFFlckxHZ2pnNUZp?= =?utf-8?B?Um03MmVTVmgwanMwSjg0MHZRR25hSzVTMnZBckwvMGczbFFLUDVsWHJtWVhj?= =?utf-8?B?MXhxb3BGVW1FMGpPR012eEdBRjRITTBTMEFpRWZhL3A3MW13V1JaODBDemM0?= =?utf-8?B?ejVPRW5xVVNUK1JNRGovOGxrK0c0b0VKeUZ2czN0emFvOUE0aXBiVHJDSWRN?= =?utf-8?B?QUJpKzU5Z2xVUzkrbFkwZkxianp4TGdNUFU1dGpONU15MkozZkdIV1k2SmJz?= =?utf-8?B?S0xabjk1M3k1ZGFNcHBCY2I5VExIVEtYa2p5TVpSN3hwRjcvZ0Y1OVNYTHVP?= =?utf-8?B?Qmd1Wjh1c3dUdzd2YUNoamVocVR6bFdkSzZCUGJleWplL29WYVREcURiR3FV?= =?utf-8?B?eVduWUxjYVJ5Rng2UlR3S0w4QmFEVi9yZE4zSHlRNmR3dEZBbURWUkZKbmQw?= =?utf-8?B?WVlWQ3VYU1JOLzhnUzcrSno4em5ERmhsYm9ZTmVZTVQycDVXai9rQzlJeGFr?= =?utf-8?B?NG84ZmI3NWppMnN5RE4yeTNqS3F3S2MxaS9zY1Ztek1HcHlmOUN1SnNnZ1B5?= =?utf-8?B?VGorNmE5WmlzWXlkcmVBSGxUUkIxYXJvZUd2ejdSOEdQR2lWakRYazg0UWJw?= =?utf-8?B?OTJPdGVTeWRBb2NIQVh1Z2dBdHpnYTUzVDVuQ1lvTmU0djV0SUtCdCtVaTR4?= =?utf-8?B?bHY4M2p6Rjg2a0gwYTg5cU1oMDE2YWw2Z2J3TFJDNVFCcXEwTUVGbEJpZ3l2?= =?utf-8?B?aGM1OWs2OVpvdDErcTlVNCtoSTgyNDA0U2ZSN2RQWk5zeW93VmlwRmc0c1BL?= =?utf-8?B?VGMzcEppcUxQcmlEUnFCM1kxdWxrdjJ3QmJQblpPQU4vd0piV3RLakxQem9k?= =?utf-8?B?TU8wNUxteXc5WVRUNUJDVHRrcytqbUhtb2NVVUVRNTVjVXRyRkFzR1JXMk5p?= =?utf-8?B?cCtkK2l3ZjcwMHZITVFCRjFFdXRDbVFPWkJWYjYyODN2cUxCTmJYMUVra0Fv?= =?utf-8?B?bVRFVVM1QnlCSUJzSDMwaURnTGJjMVdheHk2b0czZjJ3OFFGcDJ6QnlodEpH?= =?utf-8?B?Qld6eW54dWNBYUZmcWlaaG9RTjdjeHVHV3dZQ3RnUXR4WEhGWEl1VjdxNVFq?= =?utf-8?B?TVdMRWJscVppZ1NNbGJpRTFJWERVOXZJcDdJZGpzVG42YXBCNjh1bU5LcjRJ?= =?utf-8?B?TmpJMGJPQ3BJMXFDL1pCRE1lcSt6WUVFQmJrMmR2U2ZwNE1wVVUrMU9RdnV6?= =?utf-8?B?Rms2MitXaHl3cWVnNk1mZE8zVDF3N2g0a21nNEVobGdGTS9OZGF1ekZKd2FD?= =?utf-8?B?b0E4S1ZMRzk2eFYyNFJHZkxqNDVYZkczRmJPV0xndmVTbThBM1g5bHdJbFQz?= =?utf-8?B?dk9WVmdrb3VrZEIvZFpPdlRYeXZxYmtseW1tMG1OZ3hIUHBZRkI0L0twNHVP?= =?utf-8?B?R2tySVAvUGJUQXBEVTR6YVhPck5MUVpSaGI4L09hNUJRa2srRC9lYmVDeDhM?= =?utf-8?B?QjdpVFhodmZYenlsRHdSUDhRN2ZYa0FTcklScjJXVmpHeWZQQ05hTWluV2RJ?= =?utf-8?B?Qm9nWmtOV2IwRmdPVEI2dFhEWVlBVmNMalJKeFZrL2szbWpSenhqelBBSWpK?= =?utf-8?B?dWlyQVNsZ3Q1NXlUWXR0OU1zV21xVjlvanpsSU80bDIrSzNPQ29NNFhia3Yz?= =?utf-8?B?Yjk2SFEzSkorTEJDc0tXZXpFV3dpRkhhcWVKd3pTUW1XMDI4TnloZS9kYXdj?= =?utf-8?B?a29xc3ZyYnRNMVYvaFBwTE5HZS9DYk1Vd0pNT05UcGxaVUpzdWRZOUFTWkRu?= =?utf-8?B?Rk45QXhHMWF5K1BGeGdDU2RrMEJHanFYbC9mTHZuaUp6R0lDS284cGdmMnUw?= =?utf-8?B?d0ROTnVHZXpQT1QrQjBSSG8vQzM3cGxVQUZWQnlkSXZiZG9MM01NUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 28560052-a8f6-4769-ca45-08de4e27aecc X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2026 20:02:27.9115 (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: W39a7ceGVSv3cSMNBJDJ5SPP2VrgEXpjnYhyfEcfixXG8Gz518xgz+MdOB1hoYjZ2iJ6X9zXdJA3ysFhInijJw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB5251 On Wed, Jan 07, 2026 at 06:07:56PM +0000, Andrew Cooper wrote: > On 07/01/2026 5:58 pm, Teddy Astie wrote: > > Le 07/01/2026 à 18:25, Roger Pau Monné a écrit : > >> On Wed, Jan 07, 2026 at 04:54:55PM +0000, Teddy Astie wrote: > >>> Currently, Xen uses legacy method to access the configuration space unless the > >>> access cannot be made with it, where Xen fallbacks to MMCFG. This is not really > >>> great, as MMCFG is more flexible and doesn't require a dedicated lock, so it would > >>> be preferable to use it whenever possible. > >>> > >>> Teddy Astie (2): > >>> x86/pci: Improve pci_mmcfg_{read,write} error handling > >>> x86/pci: Prefer using mmcfg for accessing configuration space > >> AFAICT Linux is using the same approach as Xen to perform PCI > >> accesses. > > I think you mean "Xen inherited it's PCI code from Linux". :) > > >> Registers below 256 on segment 0 are accessed using the > >> legacy method (IO ports), while the extended space is accessed using > >> MMCFG. Do you know the reason for this? I fear there might be > >> legacy devices/bridges (or root complexes?) where MMCFG is not > >> working as expected? > >> > > There is apparently a errata on some K8 chipset according to FreeBSD > > code that uses MMCFG whenever possible. > > > > https://github.com/freebsd/freebsd-src/blob/main/sys/amd64/pci/pci_cfgreg.c#L261-L277 > > Using MMCFG is *far* more efficient than IO ports, not least because we > can avoid serialising accesses across the system. > > If it really is only some K8's which were the problem then lets go the > FreeBSD way.  Both Linux and Xen both talk about AMD Fam10h issues, > which is the fact that early AMD CPUs only allow MMCFG accesses for > MOV-EAX instructions. Sorry if my previous reply made it look the opposite, I'm all fine with switching to MMCFG by default, but we need the K8 workaround, plus this needs to be noted in the commit message. I wonder if we could use alternative calls to patch MMCFG only access on capable systems, thus removing the check for the fallback legacy access on such systems. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 07 20:02:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 20:02:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197192.1514796 (Exim 4.92) (envelope-from ) id 1vdZjk-00038u-Rx; Wed, 07 Jan 2026 20:02:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197192.1514796; Wed, 07 Jan 2026 20:02:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdZjk-00038n-Oy; Wed, 07 Jan 2026 20:02:32 +0000 Received: by outflank-mailman (input) for mailman id 1197192; Wed, 07 Jan 2026 20:02:31 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdZjh-00038h-Ip for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 20:02:31 +0000 Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c9a57512-ec03-11f0-9ccf-f158ae23cfc8; Wed, 07 Jan 2026 21:02:26 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c9a57512-ec03-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1767816144; x=1768075344; bh=x/Ic/i0CEktQ5Yo7F7Ko7SDsLFKzmOEy8wDcpfg0JUE=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=EHjdW1vJwtSWFPJ9XrJ1iCZoX3hnNoz99Vnw2y5lPxJKy4rVE10h6oadO8/eihtgr iutPv86Ra2WBYqZMFaflctqAnnwvKkkC2NCz9wbvyv0IO+oohNhDQYoIaNAOUsMVln aGbJInb30rbnV1jwnCZxFYieO5YWL38Fx+mVsJsug7kuricV3pcoSVuSzZDDAZqyOb Xu/zd6kFbT/Hlrq519BxIU4FeaTq1Cht4KImcXPWeDSr6ZEEt6VyN3CXKbVkvyLYYy +i+pVy7lETKq1bDNb/uy8E58/gtYtEKmafjSHxDrc09583S//yHjCIbREgaoVedSN/ W3KHgZu0e/xUA== Date: Wed, 07 Jan 2026 20:02:19 +0000 To: Jason Andryuk From: Milky Cc: "xen-devel@lists.xenproject.org" Subject: Re: Cpufreq drivers not working on T480S Message-ID: In-Reply-To: References: Feedback-ID: 171106842:user:proton X-Pm-Message-ID: 725be580148ccd17904489e21fd4fbbb99e08fa5 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tuesday, January 6th, 2026 at 1:06 AM, Jason Andryuk wrote: > > As suggested, I added the debug parameters to the dom0 kernel. Before o= r > > after `modprobe xen-acpi-processor dyndbg=3D=3Dpmf`, there is no useful > > debug information that I could find, apart from the > > `xen_acpi_processor:get_max_acpi_id` message as seen below. > >=20 > > ``` > > # sudo dmesg | grep xen.acpi > > [ 2.282851] Kernel command line: placeholder root=3D/dev/mapper/qubes_d= om0-root ro rd.luks.uuid=3D<...> rd.lvm.lv=3Dqubes_dom0/root rd.lvm.lv=3Dqu= bes_dom0/swap plymouth.ignore-serial-consoles 6.6.77-1.qubes.fc37.x86_64 x8= 6_64 rhgb loglevel=3D9 "dyndbg=3Dmodule xen_acpi_processor +p" "xen_acpi_pr= ocessor.dyndbg=3Dfunc * +p" rd.qubes.hide_all_usb > > [ 5.224092] xen_acpi_processor: Max ACPI ID: 6 >=20 >=20 > You successfully turned on dyndbg to get that output, but there is no > further output. This makes me think something else is wrong and > xen-acpi-processor doesn't upload anything. >=20 > The call here https://elixir.bootlin.com/linux/v6.18.2/source/drivers/xen= /xen-acpi-processor.c#L557 > to > https://elixir.bootlin.com/linux/v6.18.2/source/drivers/acpi/processor_pe= rflib.c#L421 > goes into some acpi code. Maybe there are other messages in dmesg > around the same time? Maybe you'd have to turn on more debugging to > get them. I'm dumping below a few more entries from the same dmesg log.=20 ``` [ 5.175506] xen:xen_evtchn: Event-channel device installed [ 5.208487] xen_pciback: backend is vpci [ 5.215060] xen_acpi_processor: Max ACPI ID: 6 [ 5.721955] pciback 0000:00:14.0: xen_pciback: seizing device [ 5.722265] xen: registering gsi 16 triggering 0 polarity 1 [ 5.722288] Already setup the GSI :16 [ 5.723125] pciback 0000:00:1f.6: xen_pciback: seizing device [ 5.723389] xen: registering gsi 16 triggering 0 polarity 1 [ 5.723408] Already setup the GSI :16 [ 5.829865] pciback 0000:02:00.0: xen_pciback: seizing device [ 5.832192] xen: registering gsi 18 triggering 0 polarity 1 [ 5.832214] Already setup the GSI :18 [ 7.476065] nvme nvme0: pci function 0000:03:00.0 [ 7.476438] xen: registering gsi 16 triggering 0 polarity 1 [ 7.476459] Already setup the GSI :16 [ 7.486102] nvme nvme0: 4/0/0 default/read/poll queues [ 7.489856] nvme0n1: p1 p2 [ 8.877791] xen: registering gsi 16 triggering 0 polarity 1 [ 8.877823] Already setup the GSI :16 [ 8.877910] i915 0000:00:02.0: [drm] Found KABYLAKE (device ID 5917) dis= play version 9.00 stepping C0 ``` > You could de-compile the ACPI tables and see if they have CPU info. > Something like: > mkdir acpi-tables > cd acpi-tables > cp /sys/firmware/acpi/tables/* . > iasl -d * > grep -r -e _PCT -e _PPC -e _PSS *.dsl >=20 > That could help confirm the tables are missing. Unfortunately it would appear so. Grepping doesn't return any results.=20 The same is also true under Debian Live; does it mean that frequency scalin= g, since it seems to be working under Debian Live, doesn't always rely on t= his? I'm currently trying to find someone else with a librebooted T480S to check= their ACPI tables, since I'm wondering if I botched my libreboot build. From xen-devel-bounces@lists.xenproject.org Wed Jan 07 20:33:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 20:33:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197224.1514829 (Exim 4.92) (envelope-from ) id 1vdaDk-0007q2-Jj; Wed, 07 Jan 2026 20:33:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197224.1514829; Wed, 07 Jan 2026 20:33: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 1vdaDk-0007pv-G7; Wed, 07 Jan 2026 20:33:32 +0000 Received: by outflank-mailman (input) for mailman id 1197224; Wed, 07 Jan 2026 20:33: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 1vdaDi-0007pJ-Sw for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 20:33:30 +0000 Received: from CH1PR05CU001.outbound.protection.outlook.com (mail-northcentralusazlp170100001.outbound.protection.outlook.com [2a01:111:f403:c105::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1fe9c79b-ec08-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 21:33:30 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DS1PR03MB7845.namprd03.prod.outlook.com (2603:10b6:8:21c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Wed, 7 Jan 2026 20:33:26 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.002; Wed, 7 Jan 2026 20: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" X-Inumbo-ID: 1fe9c79b-ec08-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZgUtDQ9oUgampNK88UBgjvEnAuAoGR/5iE+ZJ2B+oJMDf5nD2Qi3WKBXas4GVYjTHaB6b4HevMLST1ImnBhwqnofDJQX9Y/n4fYebq+Vd7P2pfGwTYhIijJsAzWuQquBYpsymufQmUVmnvz/wkGagi3s2UTTUYdZYl45En/bxACqcljptU3g3faNCveu6f0wUB2OPkODsjAbwCFfU4X/0wYhwOaxpo/7XdJdynSj81y96oIg/544ijsT8xFpbnvf92ak1+CUAsoRwy3Q7NhpW25f7Xp6UxQNJA2rTAENeRupLYIXENp4xxKyyMPTIfKq37/BrXLoJqa/R1RF20yCZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=S3BJtMRKxVuXEnoIV9FOzi+tgLxVenbBPFNkP9YtRQ0=; b=cW4+NsxCGEnDvWLRPx4uENGf9mfHawSqk8xgy5yo/y24afsYHYlTyqQZ9tDZqKQmT1I7Inls95k8T1J27vkGAIrfmBTLCyCkpXH+zvCNuwueY8RtXOrSId8gDct40xtubNGvpwHN0TZAXm5hffIvz2Lc5Spi16V2YJ2Q1PMZfrYPG6znPYt5Y4ynJSkQljL+c4Uf9YfjPKwjtm5hP4rmthyU/ae71NkZmXua1ppVLDEpOCqzBzr7vOuHEKYaCt9dmbVr4Z2Jn3yMH6XtYjD4hoNt1KLGu1wO5OBoNP19Gar6uGL1me5N9NqqSsCMR0x//POh28gba1aUPTBbOWThPQ== 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=S3BJtMRKxVuXEnoIV9FOzi+tgLxVenbBPFNkP9YtRQ0=; b=uzhGOkREnWooUfyjSfFF3weBScj23LtUvJcETSORL0XHbNMkDNLSvrhaPJNyM1bdh1TPB157FLAaqSC/BTQvdbREEhzThmHHzi4yBFTo7MbrLl4c3MSSCH53Gy8E2Ajs4GbMPloU6biFOjp3r2jnB/7f1uwajGq42sg9vfoIbcc= 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 , Jan Beulich , Andrew Cooper Subject: [PATCH v2] x86/hvm: be more strict with XENMAPSPACE_gmfn source types Date: Wed, 7 Jan 2026 21:32:59 +0100 Message-ID: <20260107203259.59369-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: PA7P264CA0315.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:395::13) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DS1PR03MB7845:EE_ X-MS-Office365-Filtering-Correlation-Id: 68644b76-69d4-4b1f-f371-08de4e2c02b2 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?QUJaQTBpVFRHMnN5NXlUa3dnVEVMc1hrcTg2RmRudW5VRjNtaEZueUMxaWNz?= =?utf-8?B?TnpvbFlBNnlyb2JPZ255MW9UL0hBeXJDTnJZZWJQQ2VvTVJIWlZEV3A3VHIz?= =?utf-8?B?ZUQzSEtRcStrSjRXcExqeFIvOTVvNlB0OXVoTFNxR3lDWTd6WFgrdTJsTGw2?= =?utf-8?B?TFdKSUphRHhPak9wbUlmTXM5NFZPRkNNL3RmM1A0NVdKR3ZPR29HclV5aURo?= =?utf-8?B?bWN4dDFTN1JBYXo3bHJScy9FbElDYTF6NndrbzVHcHBhRWVIZDMwZ3Jralox?= =?utf-8?B?WXFsVGM3U3krckd2VndxbXVicit4NVcxc0FzcHF3ckl2ZWZhcmgwVUdaNUND?= =?utf-8?B?b3FqZzRxUjE4WVpOTzhzM0RwS3ZGLzRVTGdrcUEwMGJzTVorUndpWjFwbWpr?= =?utf-8?B?dzRibVlDb3ZoQldGZTFvVDlrb056VGkvR3k5dXJacG9DQ0U2dENHd29xa1du?= =?utf-8?B?dng3OUg0dVJXMGFxTHNEbUd2NGhEdytVWVJvWERuUzhmdTVoOU40aE9BQjI3?= =?utf-8?B?Q0pnVGs3djBudlRuVytLdzltOXJ0MXVoWGdSbWRmOGVha1YwVTFjV2xyU2FL?= =?utf-8?B?VXdWWXJudGV4QnJRaXYyOGg0YUlzTkpvZnViVFpzNkdjQzlhNWtjSVpKeFI4?= =?utf-8?B?YVI5Szl1N2E2VU5WYzkvRm1Bd2srV2R4R1Y4SkxTN1lSS3RxcXAyNDNGOWpy?= =?utf-8?B?eVlDWDZqcVR2cDNoakovaFc0VjdIUzE2dkFZVDE0ajZ3THhnWHlOQUxuQUJk?= =?utf-8?B?RkNTbWpEUnJDNmQ5MkZjSTNCUlcvNjhjeEpMNW5uV2F1MUd1bFE0SWhoUTZR?= =?utf-8?B?bnphQ2I2VHdtbk9GU1ZiSmdZRzBqVXN0enp0QXpTQWplSThlQ0p0ZFVFcW5Q?= =?utf-8?B?MUVjTytObVFLa0kwU0IrQkR0L2wvRE9MOFJtR0NSeWVOWXJtcEhKZU9GOHZH?= =?utf-8?B?TmtyRW9JT1dybzJDT3hDTWZweER1Rk5SK3VFc1cvd1FXSVdHVnlzN2JlSGcv?= =?utf-8?B?Y0xNcFZvSC95MEYwVWphbUhia2xrdTNuSjAyRHRLQjFIYlVBSVhvZlJTS1VR?= =?utf-8?B?aWFuVnhSVEExZWg5dk4zV0RSNG02RVFPOS80d0IzTkM5aWltc2RjWThmUGlN?= =?utf-8?B?bnVWaWhTMjhxTjlVbmVsZFB6bWtGT0t3bXRBUWNKVWg1c1dQM1NVUHhLRXNW?= =?utf-8?B?VVpRSE5YMGFQZ0JjWitIUmFEdGV6Q0pqek80SnNWRWVLVkY2d1dVRFFsVHJw?= =?utf-8?B?NFh3czJTQzk2NlkrMVJ3ZjBESitXSEVFenFMTDhKazFuZFR3eHY4U0Y4ZGNP?= =?utf-8?B?RVlpakRzMWdrUTJJZjBuYXFKRGZrRXpRdzkyeDhQaVYxK0VteWpTRVRVdWlh?= =?utf-8?B?UThjNDZiWk53Q29wcWc0Z0txTmJZMXkxZ0xSRDdkcEdicktlVWZaUWthRjR4?= =?utf-8?B?TjdFN1NoMFV4S3BzSVNiN1lmamdHZjI0bGFIODdvQWRNbzEzbHFGZktrTjVJ?= =?utf-8?B?RTd3bUJFTXRHamU1eXFBalhyU0N3R3VyTGw3TjZ2NFppc0dWWGRaazFoak9H?= =?utf-8?B?MTRkNUk0KzBtTVRXQURlS29ZWjAzcFdySGQ0YXpUNFJsa09YSEFnZHd1RFFv?= =?utf-8?B?d0VrbXRqN05kOUo0YmlXT3p6Q05wWE8yNnpBeFZEYUhLem1ERitaaGxHcU5u?= =?utf-8?B?MmNXb2UyYWtybFFzYlpFdzNMOTRVbHNhZlplN0Q5dUZTamU5cGtGakFTb1Rx?= =?utf-8?B?T1QyV0xlK0JzZ2Z0NEJCdTVGclRtcFR5K0FmR3liRmRNdEovZktjY1ovVmlM?= =?utf-8?B?VnkxVVVIQlZDUnBvMkViZ3lDSEhkRTQxaEgyak5iVExBMEEvemovSkE2Mkkr?= =?utf-8?B?dFFmSVZYcTBvanZiVzdHNkVuYjFEbDgzckZhUE9Ba1Vyc0R0TmdCN01oMkJP?= =?utf-8?Q?zXI5MNzcGcCUSziEyGwJwiJAEkm6ni8X?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YXpuWHd5V25BNG10cGJTUG1IVnhQemw4aTZTUS80a1hOemx0MmNUb1FqYkxz?= =?utf-8?B?MlBRWWQ2TytBeFZodXBadTdpdEMzUGRWeFRPcWh2bUVIZGMrMTFZWWRRd2NF?= =?utf-8?B?QXc0RUhUb0l6SERnejZZcVFHUVd6djRxSlFOMmZwbFU1NlhOMTRHb1d3dFI1?= =?utf-8?B?KzBMbTRNZXVrOTB1VlZmVy9wWmRVcFF1UTl4U2l2Q1crclpoR2RlR1FybzJJ?= =?utf-8?B?SjZwa1Qzdml2MXJwUFUxRVJRQ0tMQllqZGRyazBEeEY2WHRUZWt6cGlhenZq?= =?utf-8?B?SkhvRFFUV2I2Q2h0bkRVVnZibDNNNVk2ZG1nVlZpVmltNVNqZVJPa01QQzdx?= =?utf-8?B?bTlsUk1tWnZ2clExeFBSR2RHelQxbXFJQ2Y0U0pHL2hseFhxdXlTSTlhN1Nq?= =?utf-8?B?SmpBek5wRXJmWTFrWDJqNHE2WVQyN0I5QTFaNVNIQjNoS2lCUmM5aVdkL1U5?= =?utf-8?B?QjF3VEpLYzdjeTdtbjJLWERoTHpnVEVWYk9nUi9OV08vYjdYdHdqcjF2YVB6?= =?utf-8?B?dVRrL3ZweVozcmUxaTF3OTBPSzFHRFJKdmdPVHFIYm1wQ1FOTDJHeklNaUxa?= =?utf-8?B?UW55eEpzZHYxbU5Xc2I3RWNzazVqSlZmSjUzM0t2dm1oNlBBM2g3Z1k5YjU2?= =?utf-8?B?NVpmZ1JjbDl6bGN3UWt2bktNZDJhaDNsdWhIM3l5QXdDWm9kY1RsazZBeFpS?= =?utf-8?B?cURoTGZNczdlQnRZWGlwMHZlMGw4Rm54TEJSVWxOa1BWcnJWV3RnREQxSDVh?= =?utf-8?B?Y094eG90SlFxalBNdDNpUmxPdHJPaHNLYVhWL1BaUWJNSWNCL1lxc1pmK3p3?= =?utf-8?B?RnFtNmtxc1pTSXlQQUEwbWJVQk1zeTRlVExCallCZnBoanplOE9iUkFnd2tO?= =?utf-8?B?TmRJaVFRVE9lRHUrTm1zV1ZjUUJPZno3ekdlbCs0R1h6U09qVk5zblZmdDBm?= =?utf-8?B?a3VGZzRoOXR5MXRjSGpadjFOVHUzWWZqRGpxRDlxWGNkMFNoaXhGdHFKZkta?= =?utf-8?B?WlVnQ25Nb1F5d1BrMkxXQzIxQXhZV1hTenQ0YlJIWGNGWUpBV2lpRm9KVE5N?= =?utf-8?B?ekI5d3ZHZHdkSVZVZUpNMkg0QVRjVlZzTUEyNkxwL0c2NDdRR0VZTTBHeG93?= =?utf-8?B?dmQreHh3SUdoY242aDRYbnQwVk41WDdWOTJzYWNuT0VLdU1vcXhUMUxDVDQ5?= =?utf-8?B?OE13VEVubXJINDlrWDh5aStJWWQ3L1AxOTVJSHVkUUZzYVNWRnhRbkV5ckdJ?= =?utf-8?B?SHdDTzZXM1pPWDlnUHpoaW85TDVaMElFdmRnR0t2b1FydzJBZEt1bmh4a0gy?= =?utf-8?B?SnB2dHVna1Q2bkFNdnJmOWh2RC9WTHRnbzdBZFN2YXBMRnh5V3g4Vy9Yd2FZ?= =?utf-8?B?dnlDaUJNQ002S3JyUnJlbzh4Vk5mK1VDNHZ0U2JwY0tpY0pHM1FCQ1c4aDB5?= =?utf-8?B?YTNhQThjNlBxS25nOURyT04vYTRHUVdoQXZBQkZLS29aaVNUZ3R4Ly9QcURm?= =?utf-8?B?a010MXZUU3Q5K25lTWFHdVZNTUhEK3A5VzJDMExpZFJtc0tCRXY0ZnNWZ3dP?= =?utf-8?B?N3hyYTRXSGFyTXlQTHNqWCtOQ2VXc0JkRTA1ZGI5UEhxaU5BQ05rc1k2Q0tL?= =?utf-8?B?T01vd2prT0NaY3VnRlowdEhtSGhmQXpOYmpRNmtvUHNsbUpDb09NZEhyZlU1?= =?utf-8?B?Y3Q4WVNEQ1d6bnpSR1RzNmZiVEtXWEtTaDBkUkpGenBIby8xY1dUQWlmbHND?= =?utf-8?B?N1dUeWNJZ1o5TEVNaS9SR1QyZ1FFQnNNT3l6VkRJQXlWTldQWitFOE1GR3N2?= =?utf-8?B?WlJDY255RUxTd2V5ZDRuV2Ntc09VVjUxc0JlNjIreEhLKzRjaDBPa2l1ZU4y?= =?utf-8?B?ckx4UWM3QzBSUVRmcEs1U3U4YWVUUE5COXZmNEVQMkFBVkNvcFBSa0JRNGVt?= =?utf-8?B?NmVqbE5jZFR2YWJwQlJNWUtkMW5BK1Z5dndGWDRaZ0Q4WlVOWUd0Y0hYTm1q?= =?utf-8?B?VFBldWIvOGJXTXo5c0JRVDFPK3RTblZBcUozUzBsS0t6YThodUZINU5sYXRp?= =?utf-8?B?RCtKZVM1TGEzVVRpV3N4RG9FTFlHWmRqcXZrMFlNUEIxQ3lNeFppdFpqZFZS?= =?utf-8?B?d1YvMUlVNDlGV3h0TElKRldqK2RDZmpMa3hnNkVIWlVZd28vUjhuaHUrL09j?= =?utf-8?B?T09JUXpwY0kxQU1Bd1NwUk5HOTlCUDRaNStNcjVFUVlqeDgzS3A1WjhlREox?= =?utf-8?B?WldTTzBPVHVwY1VzWVNsd3hVbkY2S2c5THdTSXh3aFBESU1sd0tLRGd3OFJo?= =?utf-8?B?Mm5VUHRsQjJVV01BZHVORXNQc0ZOUWNEeTZpaGxHRk9NeWhyZHpOdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 68644b76-69d4-4b1f-f371-08de4e2c02b2 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2026 20:33:26.5822 (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: D2KihEAulngqxtET99SonT3y6akNEmPfkw8klGA4wis4BYRwpGcZErOhbu5guW3WFNr+/njSrRUFOUTN3BDAhw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS1PR03MB7845 XENMAPSPACE_gmfn{_range} allows moving gfn around the guest p2m: the mfn behind the source gfn is zapped from the origin and mapped at the requested destination gfn. The destination p2m entries are always created with type p2m_ram_rw. With the current checking done in xenmem_add_to_physmap_one() it's possible to use XENMAPSPACE_gmfn{_range} to change the type of a p2m entry. The source gfn is only checked to be not shared, and that the underlying page is owned by the domain. Make the source checks more strict, by checking that the source gfn is of type read/write RAM or logdirty. That prevents the operation from inadvertently changing the type as part of the move. Fixes: 3e50af3d8776 ('New XENMAPSPACE_gmfn parameter for XENMEM_add_to_physmap.') Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich --- Changes since v1: - Also handle logdirty types. - Return -ENOMEM on failure to unshare. --- xen/arch/x86/mm/p2m.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index 2433230ac71c..759f3273d3d8 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -2015,11 +2015,17 @@ int xenmem_add_to_physmap_one( { gmfn = idx; mfn = get_gfn_unshare(d, gmfn, &p2mt); - /* If the page is still shared, exit early */ - if ( p2m_is_shared(p2mt) ) + /* + * The entry at the destination gfn will be created as type p2m_ram_rw. + * Only allow moving source gfns with read/write or logdirty RAM types + * to avoid unexpected p2m type changes as a result of the operation. + * Note that for logdirty source type we rely on p2m_add_page() marking + * the destination gfn as dirty. + */ + if ( p2mt != p2m_ram_rw && p2mt != p2m_ram_logdirty ) { put_gfn(d, gmfn); - return -ENOMEM; + return p2m_is_shared(p2mt) ? -ENOMEM : -EACCES; } page = get_page_from_mfn(mfn, d); if ( unlikely(!page) ) -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 07 22:56:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 07 Jan 2026 22:56:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197261.1514850 (Exim 4.92) (envelope-from ) id 1vdcRi-0007DR-Fc; Wed, 07 Jan 2026 22:56:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197261.1514850; Wed, 07 Jan 2026 22: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 1vdcRi-0007DK-Cf; Wed, 07 Jan 2026 22:56:06 +0000 Received: by outflank-mailman (input) for mailman id 1197261; Wed, 07 Jan 2026 22: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 1vdcKt-0006AW-0R for xen-devel@lists.xenproject.org; Wed, 07 Jan 2026 22:49:03 +0000 Received: from mail-yw1-x1163.google.com (mail-yw1-x1163.google.com [2607:f8b0:4864:20::1163]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0dc069a5-ec1b-11f0-b15e-2bf370ae4941; Wed, 07 Jan 2026 23:48:59 +0100 (CET) Received: by mail-yw1-x1163.google.com with SMTP id 00721157ae682-78fc520433aso29305387b3.1 for ; Wed, 07 Jan 2026 14:48:59 -0800 (PST) Received: from smtp-us-east1-p01-i01-si01.dlp.protect.broadcom.com (address-144-49-247-120.dlp.protect.broadcom.com. [144.49.247.120]) by smtp-relay.gmail.com with ESMTPS id 00721157ae682-790aa433287sm4837657b3.0.2026.01.07.14.48.57 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jan 2026 14:48:58 -0800 (PST) Received: by mail-dl1-f69.google.com with SMTP id a92af1059eb24-11f3d181ef2so10018338c88.1 for ; Wed, 07 Jan 2026 14:48:57 -0800 (PST) Received: from [10.66.193.70] ([192.19.161.250]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-121f248c246sm11503734c88.11.2026.01.07.14.48.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jan 2026 14:48:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0dc069a5-ec1b-11f0-b15e-2bf370ae4941 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767826138; x=1768430938; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:dkim-signature:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=Juxc6ADlnOHcZ+omKTaruPmPtvn8DO25aXGDHp0qX/Y=; b=hXgqQNCLECcxJZWBRyvHwtIvDBKau0vIHX/0pOieV/4bow7iNMSUREzl3CgZm6j75P d45EkrZ7E3Y3qxmuiovz66tPS5nFFE+wKDAQcmweIvIxg8CKWc0fKC5acsPD3/eAB2MR bWc0Hujj/poCfOh3weGbFkPlm92G/YP0xkMPTCf8fGLkVu1NA6QUOuuhuXwPjICWyWLH K+4swOd+5bUfXiI72eG8F78B7VNxlcuQSWwkk62/c0isr7lM70YuiMJV/8y8n13HA0if yOTumJTfvxH1Kc+9uHGL5J1G5vuLxgNlfIMhwFXB5Ei15lMETl602eBjrvAtFycMsDXW B8Eg== X-Forwarded-Encrypted: i=1; AJvYcCXx1au3MpbndtMyk5uibUO7eDeCyCzuI50lRiCueqM0ZClZrUTKuJPJBXuzGD7GT83VEV8KTbYpnYg=@lists.xenproject.org X-Gm-Message-State: AOJu0YwsRpbIyZ88ldkv4eoej6xfe2q2ar62xrsDeBXMw7yWCqObILbi 7dbTEsMxvdGrL0JJS+zL4dXJ/Ehv/vqEEgC0e77WZzvdFLvg/46C6yYyZNhnp0OzMzB+wAJi7qh Z/tM7NjUWg6PoiXZ6ibf1Sn+5Zp28xPdM6jYMESz43dBHvcqa2Cvx/8ZVqD5hUuPByVZdWL+Yxn GqULJXqskfv+mn9KocQhtVfFgkw+wnEKZknija6L5uz5RPQzUNr64Vv59d54pFiyFtq8eti9/4s ee/xLybPThbJO/xXg+ruvclfw== X-Gm-Gg: AY/fxX6eu3EnmS5p5f9cEpW6uwisvxgV4GuNkDwu+tzSvaDKTi4kDz5kgNags4cSyDN JdpG/eU94+illqOnzLwnwFIHZuaXhREO8b3vxUQebyu2YdISo7tsTn602Nxx4V3mUBSw8Gp1cDs vXLMfFfYmOa1TUbU6LIcY5uIYqz9Yp6lcZBtCYlA13vVdA5hhrh8gss4SZ1b3zQFmLlbKaNI9A9 2zDIlfqJuVM+hvIb70d3aoYxan+OgluA6J1kcCWywgVxtMTlSBTBSEJXhyj7djrKSlGQbl5MxUr Tt7D/p4hKNp8XaCkdVLPfb3pBVd6K4FVvoI/YSJQeyBkBRd8p1UBut2CYoa5esTGmB0V9RR0LSE f/PxVzlWACoVoqNxOM3RWv2a098XQMVKxep3PqVI8+vmyDx5xXqj5UkGu9d+D3bd5vj1bCSx0J8 h1AiBD/Rtjjv6VRCFtcu5wCsZr9vxprGhmLscUDmanPEV2b7xGQnI= X-Google-Smtp-Source: AGHT+IHfunGTJa2TEQNvtd/toUjjG7iVBpolV9LA6l4Y1hVFZCx+leodM3T2bqNEgEJbv8Kfif/CeW9pnjwX X-Received: by 2002:a05:690c:c528:b0:78e:646f:b6b2 with SMTP id 00721157ae682-790b58281a4mr41706157b3.54.1767826138046; Wed, 07 Jan 2026 14:48:58 -0800 (PST) X-Relaying-Domain: broadcom.com X-CFilter-Loop: Reflected DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1767826137; x=1768430937; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Juxc6ADlnOHcZ+omKTaruPmPtvn8DO25aXGDHp0qX/Y=; b=QSEvocWYGVsPsXW+rt+CZ0uYm/xksvqDemqA757397g7TNFw/jE3rPBYB+ccnQdrjT aICVV4jbaKVqdjfZRWxeZkKjuZI38oSLQoXFAZastzn7MXXXWmFWP8uUlyroioYto7Zf NAK608KQdd2xVSMmfAh3+dUwPmocRoXtWhCjE= X-Forwarded-Encrypted: i=1; AJvYcCXdRDSdP3ijpUA1HAID0AkiAPDl6Sm/2tpXUHYxmoF+CaSPO/qNdB3GgvcsrSbp/OUFbF++jgDrlGk=@lists.xenproject.org X-Received: by 2002:a05:7022:a8d:b0:11b:d4a8:d24d with SMTP id a92af1059eb24-121f8ad8096mr3559540c88.12.1767826136596; Wed, 07 Jan 2026 14:48:56 -0800 (PST) X-Received: by 2002:a05:7022:a8d:b0:11b:d4a8:d24d with SMTP id a92af1059eb24-121f8ad8096mr3559506c88.12.1767826135928; Wed, 07 Jan 2026 14:48:55 -0800 (PST) Message-ID: Date: Wed, 7 Jan 2026 14:48:51 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 06/21] sched: Move clock related paravirt code to kernel/sched To: Juergen Gross Cc: Ajay Kaher , loongarch@lists.linux.dev, x86@kernel.org, virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, kvm@vger.kernel.org, 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 References: <20251006074606.1266-1-jgross@suse.com> <20251006074606.1266-7-jgross@suse.com> Content-Language: en-US From: Alexey Makhalov Autocrypt: addr=alexey.makhalov@broadcom.com; keydata= xsFNBGVo9lkBEACeouRIm6Q3QTvjcnPczfBqgLffURstVJz5nqjnrNR4T+8dwNrZB8PTgOWA QdGV4bIyqtNG7UHQuZ7sVKr2tx0gYJyQ5uZgncEHB5YIuhQ/CyAHrVmO+5/0/xWCLI0g44rF ZJqsYw2JQ2+vayTWbR65rkOiKL8GOVFNZanDg80BRh6qCmCEMXd/tymxvgnvWpHtxMgukexk 4vV9nV4XhxRVYdpLk8mBxsh+AEbHE+nbWgIuJDrmrZDGI2Dha7JFoB0Mi6hbbYd9BdkcHKQ7 6c+S1xOrZL3jX7OIFhb4NNnEOhh8/+BDlyby478p6YsimNa7TgAUbrygGyfVG8usrZy8SvO+ vUbVQwqjcJaCK1xazK12dfuZm2kSMJUrJqa9ng6OMjkE2/WrtnK8ruFNSCdytzbuheT0nYUJ Uwy84cU4p2K/N2C4vYjcn+IT+l1BFr5FViKYruoRLVH6zK/WOoZjA+Fc6tdM5nC1pgSB9c7h XLQqDSzYPzk3nqeHWG1qJ0Hu7pscIrjxyNTIZ5le0TlpblJdoRcL5maDNw22yle8m4D18ERF VrqNoqwW8fObMCHbd6C3m75lzerq1HhrSvLyU4UfprEyAcjOI1C0319SXfYlXDjKXRQyaDZP wxln8uShSitSSnx0AsSAjcUa8Cc7km81+G2WSK3S2wVIAN11awARAQABzS5BbGV4ZXkgTWFr aGFsb3YgPGFsZXhleS5tYWtoYWxvdkBicm9hZGNvbS5jb20+wsGNBBMBCAA3FiEEjLzRtST/ a5u42vOKbM7yHr5SJ3cFAmVo9lwFCQ0oaIACGwMECwkIBwUVCAkKCwUWAgMBAAAKCRBszvIe vlInd0jTD/9bZtjehewLRrW3dRDAbLG/+J5g1K4X5qQPfAo42NrhZQlOTibL7ixwq7NSXynZ V4Iu9jHAW++KXjxJzkg7zjBf9OOvvgCpqZGKYgWNvHHnX4eIVh8Ikp5JtvGPMBcRv7lJA5co kb+RHo9iRrB1dvRIOsP1SlGS85SiNA0yvmgqwbigLDmDRSWtvvt9XPwU1iqF+1OopT3UE10i /z+qE2ogcw2ADveBovq2W4JeQEBvlETwDKOdh8Q3UBHOqrZUrL7YjpUxgmb89FcjdDzUU95I fCB5YxF0hUctxFH5Uujh2F4qk0m2rp7+aOGtxWCJUqkHXjgpOoxyn0FPZiZlDkst84NO5OSI 5ZFPwaFqxUrFF+cFCY2O/UE2gpoK9Lt3gYNK6o2WIAtufuiYVdK6lANMkBgZ+t2fDLIN147a 172zu8XnyJMTo+tVfUjxwqynoR/NSWpVPs0Ck3K0LGjQE0tJ6HZrH0vudXk3YaiqW+D4CtGh I17Pk0h6x8LCdjmWmuDXoc99ezOEFSyWuTHjAYxx3cmgSUyIhdHtimuf0CVLTcFoBErb/5pJ zjb11Cj0HP87FMH57bnD3qyfkBMOB6tztfdt3vkCBaWkxaiTGXNhwr4IiLUoi90yIdXDMcTj /gvnjXgN+31iYgPWgTOdUEQud0DwDwuDwkzx/0x4sF1Dfc7BTQRlaPZcARAAuGkoYKWcrCh8 5RffedM6uBZ4p5Z4+RVj05uq7hlAwhHUpLP/XGbgNzhJP375Lonmnuyg2x7oHxfiwOohuuiA MnhSeEXn2qWZJuHosrYxs9y2zyiE/GTUAcqKiYBFa/96zOaZjHpNuQ5qSHYL64WhqvtmCQYg fL+jes2Z4IXl2R7MrN9OE+G3A3pOAo8TZKUEmlUV85fSmgopIX+hCiSQmRNRtp2jK6hd2+38 YAXc+eRxYgXKaWX5zeBgNrfM7Oxeh/0iWRZPWstTvVH2xMlzywOB3e/fqg+Q3NlPGDrTyHoc L86ZELSLcMTFn+RXw8lX8oVjTcQA0M8sQHB5g0JEWtMsFjnQZkJGCfeh0Odbn/F8nZ6LQQtu +fjc/4n9vRun+PZjdhd3W9ZM9D87W9XJg9txIaYnoUXBLLpHK/OirFfr5cJTUf4svtE3EVXb x6P9vr7zqUbE0f76h1eDPmyMwFAuibIXhNoEoKQtEjLX9aKgKYny3hczRiuQpA+6U4oTNn4S /CEqphLPT53aMH0w4x0CebMPozf24ZE9YphdX8ECclLBlDL1/zx2xKrJNw8v6wdXMSfsybBW 98b5b1eVBk1uc1UMlpDl7AIHyCMTjL9Ha85eoya/Hk9l93aVHgK04hOBY2ED1/ZRpj0M5P5m tNX1JqZunpyvKooT1PrJr4UAEQEAAcLBfAQYAQgAJhYhBIy80bUk/2ubuNrzimzO8h6+Uid3 BQJlaPZeBQkNKGiAAhsMAAoJEGzO8h6+Uid3SDoQAI3XXqsehWKvyAVeGXPxmkk+Suos/nJC xZWjp4U2xbbegBnNWladZoNdlVW/WV+FSFsN5IWztxQTWBMI12A0dx+Ooi9PSIANnlN+gQsA 9WeQ5iDNveEHZyK1GmuqZ3M3YZ1r3T2KyzTnPPZQ1B8gMQ442bOBWe077MqtLaC0J1jHyWHU j6BbUCAyR2/OCV/n1bH4wYIm2lgrOd2WuzoAGvju+j2g7hMRxw/xeHeu8S0czHuEZ0dC6fR1 ZKUOw03+mM/xRzL1be6RVS9AF7R5oDd11RrTOb7k14z0inFqSRrRwzOPKcuMxrApcquar336 3FQuLcJLjBo/SAOh2JatOkkwkw5PZseqdwcAk5+wcCbdYy8J8ttR04iV1FzrdQp8HbVxGNo7 AlDn1qtoHzvJHSQG51tbXWfLIi1ek3tpwJWj08+Zo+M47X6B65g7wdrwCiiFfclhXhI1eJNy fqqZgi3rxgu4sc5lmR846emZ/Tx85/nizqWCv7xUBxQwmhRPZRW+37vS2OLpyrTtBj3/tEM9 m9GMmTZqaJFeK7WCpprJV4jNHpWZuNAsQrdK1MrceIxb0/6wYe0xK79lScxms+zs9pGTrO4U 5RoS4gXK65ECcBH8/mumV6oBmLrNxKUrzTczdo9PnkmRyZcAa6AndbjmQDznwxvTZu2LjMPC EuY0 In-Reply-To: <20251006074606.1266-7-jgross@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-DetectorID-Processed: b00c1d49-9d2e-4205-b15f-d015386d3d5e On 10/6/25 12:45 AM, Juergen Gross wrote: > 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 ebe08b9186ad..f310ac346fa4 100644 > --- a/arch/Kconfig > +++ b/arch/Kconfig > @@ -1051,6 +1051,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 b67d7c59dca0..d54fd2bc0402 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 198d2dd45f59..06a9a20820d4 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -769,6 +769,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 0d0fa13cab5c..72fd9268008e 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 > Acked-by: Alexey Makhalov From xen-devel-bounces@lists.xenproject.org Thu Jan 08 07:33:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 07:33:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197320.1514884 (Exim 4.92) (envelope-from ) id 1vdkVf-0002QF-E5; Thu, 08 Jan 2026 07:32:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197320.1514884; Thu, 08 Jan 2026 07:32:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdkVf-0002Q8-B9; Thu, 08 Jan 2026 07:32:43 +0000 Received: by outflank-mailman (input) for mailman id 1197320; Thu, 08 Jan 2026 07:32: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 1vdkVd-0002Q2-Ka for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 07:32:41 +0000 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [2a00:1450:4864:20::32f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 361185b0-ec64-11f0-b15e-2bf370ae4941; Thu, 08 Jan 2026 08:32:39 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4779ce2a624so23560605e9.2 for ; Wed, 07 Jan 2026 23:32:39 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d870dd5b1sm33366365e9.4.2026.01.07.23.32.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jan 2026 23:32:38 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 361185b0-ec64-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767857559; x=1768462359; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=cdFgoL7yvHhYbfibG1J618dhEbPwn1t7Kmqu1Ld2108=; b=Mzh0Un5T27roafAYx+ppV2bNqaIWLGMAvtkupMA4ss8zn/wN99suTK2Dr3hXkSrsop bt4qf3sRP7zexsv+CiUQdKwptyJPCH2/XLCY0mkrG3rlcWz9BT0qh1/1eabaDplmPlxQ LtYszsLDlc+w4yUhGxZtwXcy/dtIKgLP2KKqTjPirm7qjRnJ0s5gA4+9oGlSWukSrLZW sWvdfS3P4iOE7A4e4qT8gfzSz1aT+HfYbj+6VuHfHa+YreFJf4EFZrUsKOffsDwXkRV3 b/iAD+7ClN0HoLfLRVWw0LJ9kWGN1/abV8vMrImxuhBVmDF45529kCUT/r3sc99ZDQzV 4xlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767857559; x=1768462359; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=cdFgoL7yvHhYbfibG1J618dhEbPwn1t7Kmqu1Ld2108=; b=CdmvfX8LdeESD3JeedgkHeCwSiFw/HtzkqBJrvDkTtLaZtPewQy7QSJ2XfoG5xdlIc 28VXX3fcjbmZLPsRSVBfEmggcs6cw8bXxZldaoz7C3t4nPUfZOQsnuvUlkY012lDDXtQ UwyXI/f4JVcXTspqlLxevNa91NXwQDVH/3b4SpHzT0ayy7FjUPLchTC2QByjB+YGNVzG TC1afmCd/9OaSSv2paNTGmhBMjgbXDczSavA4EzInwXAIVsg/3W74xMluJRV+fWd1zdQ 3mJleJmW2qfTkAeNPZntvtlYxLBqbbwDvCD19X25s5DSbKXZTS0TGg4wdi+M/MDU3PT8 4CBg== X-Forwarded-Encrypted: i=1; AJvYcCX8qPaU7VD7KBXLV8Z5GpZfyryazP7TL05jx77qKD0N/xoJF7Pz7u/dogioOh4EXs7inhkhK5MpGCc=@lists.xenproject.org X-Gm-Message-State: AOJu0YwJnxShVjCPb6Db1xSjEST7YbFWpXWixeMRz4u6lSC4ep/m7+j/ tBe+ak13b7KHcX1hm1vqNs8urhca0T806Lgmhgr7OrDrnHFPvMHgSI06kReHuBhCWw== X-Gm-Gg: AY/fxX4U7ArCuZVmzSk+kCy8jjXIhYCUCFz71i1crAF9t5kfRiSwojEUmBsHfzvgBLW UocnCqrMvRRTCMf4xKhFY+/ni3km8QxW3JSC7VCQZzbesO5wuJPKWFGqJuOHhzbVlYpkZfzMOIw qMw/juxPMuphl2yZBnaKW6hzOTuPfJcXf/qCDXkmX4lGENhf08F9pLIC6wXQzPrMWDOcRj45KtO Nf2vRdijzVCigVXQLFDuKdIW4vz088FKD2ALAz56u3NS5F8rS3a0GmDQu/vMPn1blZ7tUgC/W+Y XD2NGNJ5kzSFyEnv0ledK99DhxvpTVY/n5yEUzEbyQL3UVvac1QchqwEF/0zNe5ZD9wi8fCwYvC ur798mVydpxxabJ+xYYYn1P8wSormRNg3a/RmBnxO8hlLnK1CxOjy2HWv5G8mzn/H8mXVqiQZQ5 E3mXjxGrA3BHQqzpijUIVwV9NTZ2lqk3lU8xS9a/PFije0OrD/76FOTPAES4XrbJ8wo/rGIWu54 H4= X-Google-Smtp-Source: AGHT+IGsRTxjnGsLRD11wM4O9TmEGWAMY8K77x90Mekx+c3hOlCNIkmi4eQXNUDmh1i/h1LH3v6jog== X-Received: by 2002:a05:600c:500d:b0:477:b642:9dc1 with SMTP id 5b1f17b1804b1-47d84b3baa1mr47862125e9.20.1767857559128; Wed, 07 Jan 2026 23:32:39 -0800 (PST) Message-ID: <1822f42f-9fbe-4de5-bc0b-f6e776b28ed5@suse.com> Date: Thu, 8 Jan 2026 08:32:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Cpufreq drivers not working on T480S To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= Cc: Jason Andryuk , Milky , "xen-devel@lists.xenproject.org" References: <6f02aca2-eaca-48b8-a2f3-4afff42ad264@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 07.01.2026 20:19, Marek Marczykowski-Górecki wrote: > On Tue, Jan 06, 2026 at 09:25:14AM +0100, Jan Beulich wrote: >> On 06.01.2026 02:03, Jason Andryuk wrote: >>> no-hwp failed to disable HWP. But if there is no ACPI CPU data, it >>> wouldn't work either. >> >> There isn't any "no-hwp" option that we would recognize, is there? Iirc HWP >> isn't enabled by default, so simply not saying "cpufreq=hwp" should disable >> the driver? (I already found the original report confusing in this regard, >> hence why I preferred to not reply so far. I wonder if there are local >> patches in use.) > > Qubes has a patch enabling HWP by default on supported platforms. In which case can you please tell the reporter how to properly disable use of the driver? Iirc the to-be-expected "cpufreq=xen" was already tried, with no effect. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 08 07:46:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 07:46:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197330.1514895 (Exim 4.92) (envelope-from ) id 1vdkjB-00043a-Hn; Thu, 08 Jan 2026 07:46:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197330.1514895; Thu, 08 Jan 2026 07:46:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdkjB-00043T-Eq; Thu, 08 Jan 2026 07:46:41 +0000 Received: by outflank-mailman (input) for mailman id 1197330; Thu, 08 Jan 2026 07:46:40 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdkjA-00043N-2L for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 07:46:40 +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 28c64155-ec66-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 08:46:36 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-47d493a9b96so16972805e9.1 for ; Wed, 07 Jan 2026 23:46:36 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d8717d78fsm30472935e9.9.2026.01.07.23.46.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jan 2026 23:46:35 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 28c64155-ec66-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767858396; x=1768463196; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=v/UXwuMlHkoNNlKHbuPzCDtvPmo+hVbp0oZ5TVGc/hg=; b=ecylWw1kl1hMBJr+5BbLNbQm/pDUi/AxQXO3zAztmiR0qsYzr82Bl3AdDnud/SMbcD A2wj7VRO6SqDwLmkzvihkN0hSadteCKyR61BCLsoFT6uA+NUHS6nO0gXau1vESCx1q/N Ymd6ehT72uj1YbPTMqkIuCJ27vquWtqxXJ6Zr4fvL4Hs4EQepkLh3an3YVHVDrvun91u ji1Sra2rQ7Y5kiOxIAZ+Re3u/HScAwQK+m5wTJA0hvibgicJ8ymV2wsCLDQ0geldoTaA fbreVvQyy5HZUt5nBRBP8cxhYLaV1eDsDTStsc5Ga+3XcQnzzXoHquL1DjlugcTHrIma cViw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767858396; x=1768463196; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=v/UXwuMlHkoNNlKHbuPzCDtvPmo+hVbp0oZ5TVGc/hg=; b=mixt127j73eyYcv06baMf1w2XqJ8/z3kBiTo0N3DGL6SEAtsZMfotnVM6FVdBewc4n ReL92c8iFpwe3mNG2aIFFubxUIyY7xFUwRAW6wq3ezlIPlbgbMAvaly5AAPDF77css4j 8C9m6oOxok67E38Hp3D/12yptRlO9xRR0ZdR1vrtBPTfUMSf3DLrMGZKFLtYREFqzUoP jahvFVGKJeBsNEz+Yyjca3Vqglo77MdMFvbFGDwiTq8oQIuOrRrfqh0uMglhtVu1WhL1 RxrGRyCIjAy1W/h46NLNuA1RtAmOnkg2cD3fy83hIkJhjiW06Wojv1V3RZIhbr0XMp4y t0hA== X-Gm-Message-State: AOJu0YxMpmgzylqR8HyxJ9Qhu6V/yayegd4+L03/JXkkmRpjgAzYu1Eo Q+NYd3UosBBLMPU3/g90bIR7XAXd57zsRSIvY+1po9agZlqknsmn7moxIr5FhiI05w== X-Gm-Gg: AY/fxX4KWQ0erwNXsPBBQL/o977NdjKueqAbJk6Lrugg1s1MV7Gm3fNuWQzf5/mSAzr LoOSZqYTRKvKnRdjBcDyL7nZBQJE4YPGgvP3z9pkEZO23VHAfIsoKrk3tQCi3NG6AwEmokIr+jZ foRqdHXn/s1ZXXMWadn3eAiGumz/Ip2+bf49YYs73scjkLvXlgP8Wr//2y4Ygg6KUwFv2ce032H YTRJvJi7X2Uo4aLa1EijOg3nM/BXNujGqw33nU4Vba2hWrXZVf/T2lqihiDjHCicEtxHw4LdcOX QlDfLOjgVaFutm8lAlTpG/ekOVAuteB61KD9lZtoRe0R6MBwImdAM3V2L2/rBXB/bgwup3Jq/wQ QAXNkkIUUzPAMGa76kXdW3g8u1zsOhJBTPdKloIO4Fm7EwbS+qpZ1d+u5HXd3Dzt3M5Ix35Lt4J 6GE0D1EN7xDrDG4ph7Vzl3XuSMGj/9Fw3cbPh2+SMJdyNz7tYKC3ruxOFhiAqn2oN3+ZrmQ48EN s4= X-Google-Smtp-Source: AGHT+IH+No0vPR9q250Eccs8tc9S5N6s53hZVJizMJIwtQjTBEE5WA4aYo6Af/YCk/NiUH9AH7Z8Dg== X-Received: by 2002:a05:600c:3b15:b0:45c:4470:271c with SMTP id 5b1f17b1804b1-47d84b36bcbmr56826065e9.18.1767858395749; Wed, 07 Jan 2026 23:46:35 -0800 (PST) Message-ID: <7dbd26d1-0d9a-454f-90d8-5a7f3d8e12da@suse.com> Date: Thu, 8 Jan 2026 08:46:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Cpufreq drivers not working on T480S To: Milky Cc: "xen-devel@lists.xenproject.org" , Jason Andryuk 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 07.01.2026 21:02, Milky wrote: > On Tuesday, January 6th, 2026 at 1:06 AM, Jason Andryuk wrote: >> You could de-compile the ACPI tables and see if they have CPU info. >> Something like: >> mkdir acpi-tables >> cd acpi-tables >> cp /sys/firmware/acpi/tables/* . >> iasl -d * >> grep -r -e _PCT -e _PPC -e _PSS *.dsl >> >> That could help confirm the tables are missing. > > Unfortunately it would appear so. Grepping doesn't return any results. > > The same is also true under Debian Live; does it mean that frequency scaling, since it seems to be working under Debian Live, doesn't always rely on this? Yes, that's possible afaik. Which driver is in use there? Jan > I'm currently trying to find someone else with a librebooted T480S to check their ACPI tables, since I'm wondering if I botched my libreboot build. > > From xen-devel-bounces@lists.xenproject.org Thu Jan 08 08:00:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 08:00:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197353.1514905 (Exim 4.92) (envelope-from ) id 1vdkwG-0007JK-QH; Thu, 08 Jan 2026 08:00:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197353.1514905; Thu, 08 Jan 2026 08:00: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 1vdkwG-0007JD-NS; Thu, 08 Jan 2026 08:00:12 +0000 Received: by outflank-mailman (input) for mailman id 1197353; Thu, 08 Jan 2026 08:00:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdkwG-0007J7-2A for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 08:00:12 +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 0df96766-ec68-11f0-b15e-2bf370ae4941; Thu, 08 Jan 2026 09:00:10 +0100 (CET) Received: from DU7P195CA0006.EURP195.PROD.OUTLOOK.COM (2603:10a6:10:54d::29) by AS8PR08MB8875.eurprd08.prod.outlook.com (2603:10a6:20b:5b7::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Thu, 8 Jan 2026 08:00:04 +0000 Received: from DB5PEPF00014B9B.eurprd02.prod.outlook.com (2603:10a6:10:54d:cafe::70) by DU7P195CA0006.outlook.office365.com (2603:10a6:10:54d::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.3 via Frontend Transport; Thu, 8 Jan 2026 08:00:03 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by DB5PEPF00014B9B.mail.protection.outlook.com (10.167.8.168) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Thu, 8 Jan 2026 08:00:04 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by GV2PR08MB11465.eurprd08.prod.outlook.com (2603:10a6:150:2a7::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Thu, 8 Jan 2026 07:59:01 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%4]) with mapi id 15.20.9499.003; Thu, 8 Jan 2026 07:59: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: 0df96766-ec68-11f0-b15e-2bf370ae4941 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=VL9REVPG5Fsqj802+Qp4K42959tpu02kVZ7wCWYUNlAfmP5WjEWOOfaQYRpA+lLrCwuc1eNkdi8RpWfCIq/MitNHTiO951O7vlDLamvkk+eymYUfIPenPBbmBunlANE80nkJXFajgJKStf3tykBRN973YOC0NPXANDuSDVpNiL4vEEFBx+ZM+jmDlKOdRUnio7QH/cXtbBhJbIpohCzxRhnm5JyfpqQgUiAGB8WWWobsxQkgNMenRburyDKGmzCFcF3PW2jCtyIXGLu3B6xhLGF43pw9RrW6dviHXmBE9xFovfjNwJ6l4IQmx08ma3rfoKyNHLUwUrlznw9AaguOig== 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=2Jl/nn6qt/nzdN9u1StQlIPKyXWCbxTkqoe0eDWh5MM=; b=bXQw3Sq0a3GiF0xU9KckHw1Lt76m8HowYsMDLFB8DUivZArNHzY/stoD2qAWHs8sc39HdHAuztdy7y705rQF843o8EYY3vi7Ehgn8c4/rGQgsn/CHgxxbSnENfBqlBCr7WtQ51VBy5pCbQGgyqHlIgzmeuOt9Dagm2yCigApAGnif/tsmZ6Nope3xYOdisfw/3pui7d5rycHIqg4/9n0BZsKgp9PXLRYO+pmlK8nOHBOwi2h/qki5yIaTDp/TUAm5oSs/76sjULBFCFjDVf/0UVbzIC48xuf4hk2TZu/TJkfxZ0LBeXxMDpOqvZOZQW8dw4VpfxWWLFOKxVmlOVyEQ== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=xen.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=2Jl/nn6qt/nzdN9u1StQlIPKyXWCbxTkqoe0eDWh5MM=; b=d5DAN0BNshj3fnazssDDbTK9p1AEZnFA5HFRCopOeH3nptL45LcBfciRIm004SxIDwHTE/MNfOpmSuumABgrTrFK12nZYuqoU5kP20FdinmCmSLxwfhGuQyj/XhpgpMBTU+JodULn+crPb8meyPdoRHcMxVA723OxdFBpoNpEQ8= 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=SP4zfYJbdMbfgBxZ/AkCw2SUL6G5vhz8TI7+ryB0wIogc/uGACHkj7we/uZyx2lhHxHOZT2ysqglbu4tmSL2YHrwKLEtT9sNKfDhGeCCUoOwX4jeb4/cgWPTDKdohdfEqod6CPW8p4hug2WQnK00o+6pwghP/KQjUv50CIUXExe7XOwhpYX3gJRZFU63idWSw3I1mI6rEAmoGMY85JVr7+wxE+XKqYY+4zcs9/IENd94HNzlcxPccKCUL5/sLMRmCyFNc3fHHAnZx0WprKTapsazbveaL0IPcQP+F1B/8sVp9sl7PjgYo2uqOu7ltMU3YE8/nfpdAHrZDDUjk3jp/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=2Jl/nn6qt/nzdN9u1StQlIPKyXWCbxTkqoe0eDWh5MM=; b=nTE/GEj7/aIiU6OBlC51m0NrmULaAA6Zy12IWr9T5Crs5NxTFB1bbgH3P4I8qeGs6iI3ftnV+jJObgaVx4+VWJ22omRtWNrKg1dYs2ADDlfWwR7TAzEDwlMidGnniQbFaCoDjNT+5iLXaOn+aipT74wS0sP5wU5YBMyUSRgk+jJ/R5lrudgrP361MEYcXM4CMMAm7cg3oGlElLIg5Gk968RbyAkDJU5zzPfDSwsYKXHSa6awqhJUGnapTRdL1OOIUIiZlfRZJ4dWLWxcNXJ3OJwhyiailhyQ9LQKUT/ebqriqsRPm4pCPJTxGVnBALzp17WlCdmy5gvPlNcEgdWxWw== 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=2Jl/nn6qt/nzdN9u1StQlIPKyXWCbxTkqoe0eDWh5MM=; b=d5DAN0BNshj3fnazssDDbTK9p1AEZnFA5HFRCopOeH3nptL45LcBfciRIm004SxIDwHTE/MNfOpmSuumABgrTrFK12nZYuqoU5kP20FdinmCmSLxwfhGuQyj/XhpgpMBTU+JodULn+crPb8meyPdoRHcMxVA723OxdFBpoNpEQ8= From: Bertrand Marquis To: Julien Grall , Michal Orzel CC: "jens.wiklander@linaro.org" , Volodymyr Babchuk , Stefano Stabellini , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v2 00/12] xen/arm: ffa: FF-A v1.2 support Thread-Topic: [PATCH v2 00/12] xen/arm: ffa: FF-A v1.2 support Thread-Index: AQHcbdIZ54xp46f98kibMufFF0ZVibVIDZyA Date: Thu, 8 Jan 2026 07:59:01 +0000 Message-ID: <2FA52A4C-98F2-4066-8BE7-36F37093FCD6@arm.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.300.41.1.7) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|GV2PR08MB11465:EE_|DB5PEPF00014B9B:EE_|AS8PR08MB8875:EE_ X-MS-Office365-Filtering-Correlation-Id: 0bbd54e4-8b1b-41f3-bed2-08de4e8bee82 x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|1800799024|376014|10070799003|366016|38070700021; X-Microsoft-Antispam-Message-Info-Original: =?utf-8?B?TzFwVG8zSTJUV3JpVk1wSjBOVnNjTVZvaC9pbTZIZzBuYzZjdTN0bGJwRlox?= =?utf-8?B?ZFptVGljdy9hOG9DWmdBYzZpZzBEMllXWU92OXNHY3JRL2F3bHJNM0R5NFJv?= =?utf-8?B?Qk5YMXp6MXpGYmlwRkUyek03Q3ZiSWRrQlN4czVDNmluOXB0dHdPL1pISWl0?= =?utf-8?B?TTRJK0NVVitVTllKSGoxbzNkd3N0aVZPM3FiU0doM1V2djdVRDZxYitFOFpH?= =?utf-8?B?dmNUeC92N1Fhb3FEQzFrRVJvQUp6cTJRTC82ZlQwMDl0TkQ2aSt0Y0xTblBF?= =?utf-8?B?VldDSGFKYUJMaklHZHFRV09zMjdLM3pyZVJSSzlySDBDWGF0MDdpQUo2OVhv?= =?utf-8?B?QTZFSHhFeitDaHRXdG9PWjFTNlk0dEFpM0E1L2JzeHNSaXEveTh2TGVqTHZn?= =?utf-8?B?aEZOSktqVWhBT2I5YWJLRG9wdnN2UFVZNHRlRHNCVnJ4aDA1UVBRZVJ6aHIv?= =?utf-8?B?cEVkWERSWXNGZzhoNFpUT084QS9ZZmdzQmNYaU1UUENYNkdCZ24ranFvZzhE?= =?utf-8?B?NHhVcDlPZlZFUDZuZjFnd3N0dE1kdkFVQnEzMWk3WUt3Z1BWRExOaXIvSlZv?= =?utf-8?B?M1lHTyt5YUFCOUJLbkFLaEl1KzZRWVh6dTM2MjhLcmRTT2F5YUV1bUt2WTBq?= =?utf-8?B?aFg4YmE1R0dGSFBGTW9lZVcyUGV5TUlFM2o4dXlFdHhoNkNkMDlqaFpmQ0JJ?= =?utf-8?B?d1d5Y0c5dXpXUi85bFhESDVMdysvaXRTcGFJTlZ6NWYwbEpob1QrYnZQaTlW?= =?utf-8?B?ZWpGZTNyNjRWeVJWc1UrQXc1eWplSjBMWHNJeGpZSHc4NVM0YlFqdGd4Z1Zv?= =?utf-8?B?ai93eVZ0aUkyKzVJUXgxaGUwc0ZrNzJMenhPRDRoSDMweURPdG1SSlU3Z0Jt?= =?utf-8?B?RWdFL2NHaTRwQWhxT1lVR0pwQ0x3SVR0S0ozWHF2bDBrYlhTOS9LVGlKQkVv?= =?utf-8?B?bFo5WERxVGxqdHpqYXluZC9Sa2hISVdweDdibWhQV2ZTSXVCNlVvcnBIRnJp?= =?utf-8?B?T0oxZjBjOE8rMDJoM3ZQSDVPUEZIdmplbHJWdHJIb1plSTBFaFB3V0xwek5p?= =?utf-8?B?WnVLblNkMHluSEFORnFIaktUMUJRZndYd2trcE8zbjZ2RXIwQWp0RUkzcUlZ?= =?utf-8?B?LzBwTGhPbi85MVY2bTVLRjVOeWduMVhLVmxBaHZPUTZ3czBDQTBRNXBpRDE2?= =?utf-8?B?SWxkeUxFVjFnci9sWU9iWDEvaERJYWhtaWJoRTlwT0F2OUJqTDRzU1lzVEpq?= =?utf-8?B?V1NFWUQySHk3VGIvUzArb2tDQ1p1L2JpWlA3Vis3dVBUeXgyYSsrUVd4cDZW?= =?utf-8?B?cWVqNGk4TWJGSTFjY2NzKzR4NHNHTHhRa3YzWlJTbnFWS3FQWk9KNytkN1JV?= =?utf-8?B?Vjk4VVBtekZmNkN3VG5GZStFcERuUjMwNGNlWEE1ZkljMFVScW15MmRoelZ4?= =?utf-8?B?VnJvNzA0RXFHYjdGNXVwVWtmY3FISXI5czZkT2pZSWJ3ZjN1dUZrU2pjeDdC?= =?utf-8?B?OTdSWk1DNm8zcmpEOVJUUml5SC9GMDJjZmM5K3BEek5wYVlqSGFadVBla1o5?= =?utf-8?B?dlB4Q25qR0szeFpnYnIrK1Z2MzBVWG1USndyZFhha1ZsQ0dHQ2x6MGhzU0xN?= =?utf-8?B?RlM3Q0xUMWZDQXFvMmNPSmptcHAwVE83eXY5ZW5HeC9Fc0F6RytQUGNGMmJW?= =?utf-8?B?MXhuUXlJdTV2enprdGZmSlV3STdGYlZrZ2preFRoWjdzandZaUdHazdScWJU?= =?utf-8?B?aGFNdityczM1VWRYeHI1M2lVZ2lKVG1xVjlwNnowakdwc0J0bDhYbVpQZTh5?= =?utf-8?B?QmRpeC9jejFwV2xoYUlRYmZPZjJBL1FNZlN4SlFYeVV4Z1VWOGpYVXJDVXU4?= =?utf-8?B?SlFDSXRhS0F0VHhsb0VmSFE0R1REaHFHRnhkcjg5SGpHaGk4SG4waTRTN1hn?= =?utf-8?B?MFp6L2FUUlBYU1JDSUR0U1lNVkg3aUJTWm4zWDF3WEhqUUJyYnNvZE0vN3g1?= =?utf-8?B?NmtXTnNIWXV2ZlQzRXhkY05kdWNWOUJDVzFwcmZBaWJFR1pOcCtaYUNIOUlB?= =?utf-8?B?azBkMjZyK2pJbUZpNEtFRkd0QUJqS0FET0hjdz09?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(10070799003)(366016)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="utf-8" Content-ID: <1C38EF5001B25A498F4F88FBE3B4DB4C@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR08MB11465 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5PEPF00014B9B.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: ae5da050-129d-458b-ac2a-08de4e8bc919 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|35042699022|36860700013|14060799003|376014|82310400026|13003099007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?NVFvSnZTRmNvaGpqUUpLNWgrQ0NqT0J3T01UVDkvQXp6Y3ZnZmIvWjFYRnRs?= =?utf-8?B?ME5ncWNxSnpTM3VydWI3Z1RTOTdvTjNYVUJJc0NkMVptQzdCQXNPMTJ3NW5Z?= =?utf-8?B?SGNJSFRxeW04dU1oVllLS21wRVd4eTQzeTFsdURUektpb3pMcWNQS3Y0MjhZ?= =?utf-8?B?M2xJN24vUDErL2tydUs4L09UL2xvS0psclh2NEVqQ0tZdnNDYmV2M05jZjhP?= =?utf-8?B?cGJxTzdObit3ek1nWC9hSUR4RE5DTnVROXYrRThMb1YxZ1R3UzErcmsxcVQr?= =?utf-8?B?MHRXcmVBMitFK0sxazVqTE9UU2lIcHJreVN2bE9Gb2hWZ1hMYlJYTzB5YWwr?= =?utf-8?B?V3FiTVNKOU9WUWhKMVNCUFhQVUMvZWNtREVXUTU5bXpZSjNTT3NUaUo4MTF4?= =?utf-8?B?cGdYMTBTazRyZ3VQaVJUR0JDRmIrZUZoVXVJamZTbXZBbVphT1kzRUFtOC9U?= =?utf-8?B?a2FPTzRsRVFVbDMzaFQ5bXBza1poUEY5WjRJY3NQOENLcVJYWkw4U1NDakUz?= =?utf-8?B?Y1ZDRkpycEoySlVYclZYRXhSTnV2YzN1Y0RNN2ZoWnYyRitVRUZqRWhBR2Fp?= =?utf-8?B?d2xXTHNhYS91OW1ZVjNWenpjbEwvVlVyQ2lvVlViVlovQytQQi9hbjdSQWt2?= =?utf-8?B?WDZSaDhkbTNYSHhMSk9oWVRUVFhjcDd0Y3IzbXlTelNIT1R3NDYrK0UwYWdh?= =?utf-8?B?dnNGcFRvcWdKOW1hWFFqWjJ0TmJ1aEJjSHlobU9XMmQzZTExeWVmcDZRMk5M?= =?utf-8?B?bVkzcjBoRzRrZzVqNGNsQURMNkJkOGUzaCszVUNySmJaaDQ2aEFmejBhMFFG?= =?utf-8?B?OFZmODdDMmd1ZnpjaHVYSnBSZ2JGMVJmM2h3d05JSXNIM1Zsc29WVlBqUjhk?= =?utf-8?B?NDNlL3NPczdzTXhlMm1seHBITUxIWnZjUEMwdHRWOERpazV0RTdSbVZ0TS9x?= =?utf-8?B?YXAvQis3YU51bFpnZXpKck96SEZlVHFIZDU2TkVDV1piclJXK09TTzRIdlFs?= =?utf-8?B?aUpoa3dnVTY4QldTMnp0ODhVSm85dE1mdWsvZUp1cUduSDlzVEpvUzFtSHZD?= =?utf-8?B?WUJERS8vdGdSejI3MlJLa2IwMy9VMDAyNmpHWmRoTTdhK2FjTGRMVUxOTm01?= =?utf-8?B?YVdmaFNEakkzU1FGQjV1eEpqeGdpSUp0NFpOMWU2QVRiZlQ4UldEYUVFbmpt?= =?utf-8?B?M2szbmtNNHdDQVYxY2U3YjFKakoyMzhIU0xiSVE0RlE5YklHZ29pQ1hkeUNa?= =?utf-8?B?S3hmNlRJZTVseUhZZnpORkFGOGJIZ1hMZC9TakxJRjEwU1RjUVVVTFdYdUVD?= =?utf-8?B?Q2YyUmJTZXRlSy8wN3NPdmFGYTVOczVZQkRZdGNQZ3NkMHlhRFc2SWdoS1Rz?= =?utf-8?B?OWZ3cGxrWDg4SDB6bDFuRWpBMTdwTEZQU0QvVHJkZDZIalk3MytzSVRJSEpj?= =?utf-8?B?NWtqd01wc0NPdm9TT09PVk5pNGxON05CckFEQ0pwSjJwcXhkZ1MySW90TVFZ?= =?utf-8?B?MzhrRDllVWpLWC92THpucElYL3VFQWk4QVhJK3pZMlpySXFlUkM5YUV5WkxU?= =?utf-8?B?b0l1UVpMN1lMMEtmTzc4ZjEydHFGL0tjUjhOZnAxczJ0V3NSYUxSZnAvNGg3?= =?utf-8?B?YkhEYU9Vd1pvdi9ZaCtObzA0cjFsVldZOGdLRkV2S29STGJ4T1l5UDduK1ly?= =?utf-8?B?TVl0Yk1QSTBVRDNWVnJZdC90QU5SSlN2dVJqc0dyUTVqa0JBc3RTckhTRzlL?= =?utf-8?B?VFZiRFNZVk1ldzhoOFVTVTgzeFkvTUVHQ2x3bkc2dEtzWjJvSFF3NkZRbEVG?= =?utf-8?B?MFBUU3dxdUsvOWdUdXZFMVp2UmIzOVlRR3hubS83OE9iNEk3RGZrMzB6dFRK?= =?utf-8?B?dGh2dWpJS1hvVE9yTDk4QkFDQ3VzMDBsWUxMaVZBbjVYZ2h4NFdnS1FpK05D?= =?utf-8?B?cE9lbm41amVkSFd6TXg1N01FYkY1aDVMSjY2NVBxak9HZ3FEOTR3cjdZODQy?= =?utf-8?B?VVg1SHcrMFVoRmdob1VHRjFPclN6bXdRZ1ZXWlBJWjV4UGNDY3dwT3d6ZkRY?= =?utf-8?B?SHliS2JORW9MZDZ5dlhucUFMMGtkSVFqbllvenNCaHNzUi9PS1JhcitNS2F3?= =?utf-8?Q?YbwPUt4JlxBgPl7Y5WOJCrTuI?= 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)(35042699022)(36860700013)(14060799003)(376014)(82310400026)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2026 08:00:04.1010 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0bbd54e4-8b1b-41f3-bed2-08de4e8bee82 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: DB5PEPF00014B9B.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB8875 SGksDQoNCkdlbnRsZSBwaW5nOiBUaGlzIHNlcmllIGhhcyBiZWVuIGZ1bGx5IHJldmlld2VkIGJ5 IEplbnMgYW5kIHdvdWxkIG5lZWQgYSBtYWludGFpbmVyIGFjayBvciByZXZpZXcuDQoNCkNoZWVy cw0KQmVydHJhbmQNCg0KPiBPbiAxNSBEZWMgMjAyNSwgYXQgMTU6NDksIEJlcnRyYW5kIE1hcnF1 aXMgPEJlcnRyYW5kLk1hcnF1aXNAYXJtLmNvbT4gd3JvdGU6DQo+IA0KPiBUaGlzIHNlcmllcyB1 cGRhdGVzIFhlbuKAmXMgRkYtQSBtZWRpYXRvciBvbiBBcm0gdG8gaW1wbGVtZW50IHRoZSBGRi1B DQo+IHYxLjIgaW50ZXJmYWNlIHdoaWxlIGtlZXBpbmcgZXhpc3RpbmcgdjEuMC92MS4xIGd1ZXN0 cyB3b3JraW5nLg0KPiANCj4gUGF0Y2hlcyAx4oCTNyByZXdvcmsgdGhlIGxvdy1sZXZlbCBwbHVt YmluZzoNCj4gDQo+ICAxKSBhZGQgdGhlIEZGLUEgdjEuMiBmdW5jdGlvbiBJRHMgYW5kIHByb2Jl IHRoZSBuZXcgQUJJcw0KPiAgMikgdHJhY2sgcGVyLVZNIEZGQV9WRVJTSU9OIHN0YXRlIGFuZCBl bmZvcmNlIG5lZ290aWF0aW9uDQo+ICAzKSBGaXggaXNfNjRiaXQgaW5pdGlhbGlzYXRpb24NCj4g IDQpIGhhcmRlbiBSWC9UWCBtYXBwaW5nIGFuZCB2YWxpZGF0aW9uDQo+ICA1KSByZXdvcmsgU1BN QyBSWC9UWCBidWZmZXIgbWFuYWdlbWVudCBzbyBhY2Nlc3MgaXMgc2VyaWFsaXplZCBhbmQNCj4g ICAgIFJYIGJ1ZmZlcnMgYXJlIGFsd2F5cyByZWxlYXNlZCBiYWNrIHRvIHRoZSBTUE1DDQo+ICA2 KSByZXdvcmsgVk0gUlgvVFggYnVmZmVyIHRvIGhhdmUgZ2VuZXJpYyBhY3F1aXJlL3JlbGVhc2Ug ZnVuY3Rpb24NCj4gICAgIGVxdWl2YWxlbnQgdG8gU1BNQyBhY2Nlc3MgZnVuY3Rpb25zDQo+ICA3 KSBzd2l0Y2ggdGhlIG1lZGlhdG9yIHRvIHNwZWMtY29tcGxpYW50IHNpZ25lZCAzMi1iaXQgc3Rh dHVzIGNvZGVzDQo+IA0KPiBQYXRjaGVzIDjigJMxMSB1cGRhdGUgdGhlIGRhdGEgc3RydWN0dXJl cyBhbmQgZGlyZWN0LWNhbGwgcGF0aHM6DQo+IA0KPiAgOCkgYWRkIGZmYV91dWlkIGhlbHBlcnMg YW5kIHJld29yayBwYXJ0aXRpb24taW5mbyBoYW5kbGluZw0KPiAgOSkgYWRkIEZGQV9SVU4gc3Vw cG9ydA0KPiAgMTApIGFkZCB0aGUgdjEuMS92MS4yIFNFTkQyIGhlYWRlciBsYXlvdXQNCj4gIDEx KSBhZGQgTVNHX1NFTkRfRElSRUNUX1JFUTIvUkVTUDIgc3VwcG9ydCBhbmQgbWFyc2hhbCB0aGUg ZXh0ZW5kZWQNCj4gICAgIHJlZ2lzdGVyIHNldCBmb3IgdjEuMiBndWVzdHMNCj4gDQo+IFBhdGNo IDEyIHRpZ2h0ZW5zIHRoZSBkaXNwYXRjaGVyIGFuZCBhZHZlcnRpc2VzIEZGLUEgdjEuMjoNCj4g DQo+ICAtIHJlamVjdCBTTUNDQzY0IGNhbGxzIGZyb20gQUFyY2gzMiBndWVzdHMNCj4gIC0gZXhw b3NlIFJYL1RYIGNhcGFjaXR5IGZpZWxkcw0KPiAgLSBidW1wIFhlbidzIEZGLUEgdmVyc2lvbiB0 byAxLjIgb25jZSB0aGUgaW1wbGVtZW50YXRpb24gaXMgY29tcGxldGUNCj4gDQo+IHYxLjAvdjEu MSBndWVzdHMgY29udGludWUgdG8gdXNlIHRoZSB2MS4xIEFCSSB3aXRob3V0IGJlaGF2aW91ciBj aGFuZ2VzLA0KPiB3aGlsZSB2MS4yIGd1ZXN0cyBjYW4gbmVnb3RpYXRlIHRoZSB3aWRlciBBQkkg YW5kIHVzZSBSVU4sIFNFTkQyLCBhbmQNCj4gRElSRUNUX1JFUTIvUkVTUDIgd2l0aCB0aGUgZXh0 ZW5kZWQgcmVnaXN0ZXIgc2V0Lg0KPiANCj4gVGhpcyBzZXJpZSB3YXMgdmFsaWRhdGVkIHRocm91 Z2ggZ2l0bGFiLWNpIGhlcmU6DQo+IGh0dHBzOi8vZ2l0bGFiLmNvbS94ZW4tcHJvamVjdC9wZW9w bGUvYm1hcnF1aXMveGVuLWZmYS1yZXNlYXJjaC8tL3RyZWUvZmZhLXYxLjIvdjINCj4gQnVpbGQg cGlwZWxpbmUgZm9yIHRoZSBzZXJpZToNCj4gaHR0cHM6Ly9naXRsYWIuY29tL3hlbi1wcm9qZWN0 L3Blb3BsZS9ibWFycXVpcy94ZW4tZmZhLXJlc2VhcmNoLy0vcGlwZWxpbmVzLzIyMTU0NjY5NjUN Cj4gDQo+IENoYW5nZXMgc2luY2UgdjE6DQo+IC0gUmViYXNlIG9uIHN0YWdpbmcNCj4gLSBSZW1v dmUgaW52YWxpZCBBU1NFUlQgaW4gcGF0Y2ggNQ0KPiAtIEFkZCBleHRyYSBjb21tZW50IHRvIHVz ZSBBQ0NFU1NfT05DRSBmb3IgZ3Vlc3RfdmVycyBpbiBwYXRjaCAyDQo+IC0gQWRkIEplbnMgUi1i IGluIG90aGVyIHBhdGNoZXMNCj4gDQo+IENoYW5nZXMgc2luY2UgdjA6DQo+IC0gUmV3b3JrIHZl cnNpb24gbmVnb3RpYXRpb24gdG8gcHJldmVudCBjb25jdXJyZW5jeSBpc3N1ZXMNCj4gLSBJbnRy b2R1Y2UgcGF0Y2ggMyB0byBmaXggYW4gaW5pdCBidWcNCj4gLSBJbnRyb2R1Y2UgcGF0Y2ggNSB0 byBtYWtlIFZNIFJYL1RYIGJ1ZmZlciBhY3F1aXJlL3JlbGVhc2Ugd29ya2luZyBpbg0KPiAgdGhl IHNhbWUgd2F5IGFzIFNQTUMgUlgvVFggYnVmZmVycw0KPiAtIG1pbm9yIGZpeGVzIGRlc2NyaWJl ZCBpbiBlYWNoIHBhdGNoIGNoYW5nZWxvZw0KPiANCj4gDQo+IEJlcnRyYW5kIE1hcnF1aXMgKDEy KToNCj4gIHhlbi9hcm06IGZmYTogYWRkIEZGLUEgdjEuMiBmdW5jdGlvbiBJRHMNCj4gIHhlbi9h cm06IGZmYTogcGVyLVZNIEZGQV9WRVJTSU9OIG5lZ290aWF0aW9uIHN0YXRlDQo+ICB4ZW4vYXJt OiBmZmE6IEZpeCBpc182NGJpdCBpbml0DQo+ICB4ZW4vYXJtOiBmZmE6IGhhcmRlbiBSWC9UWCBt YXBwaW5nDQo+ICB4ZW4vYXJtOiBmZmE6IHJld29yayBTUE1DIFJYL1RYIGJ1ZmZlciBtYW5hZ2Vt ZW50DQo+ICB4ZW4vYXJtOiBmZmE6IHJld29yayBWTSBSWC9UWCBidWZmZXIgbWFuYWdlbWVudA0K PiAgeGVuL2FybTogZmZhOiB1c2Ugc2lnbmVkIDMyLWJpdCBzdGF0dXMgY29kZXMNCj4gIHhlbi9h cm06IGZmYTogYWRkIFVVSUQgaGVscGVycyBmb3IgcGFydGl0aW9uIGluZm8NCj4gIHhlbi9hcm06 IGZmYTogQWRkIEZGQV9SVU4gc3VwcG9ydA0KPiAgeGVuL2FybTogZmZhOiBhZGQgdjEuMiBTRU5E MiBoZWFkZXIgbGF5b3V0DQo+ICB4ZW4vYXJtOiBmZmE6IGFkZCBNU0dfU0VORF9ESVJFQ1RfUkVR MiBzdXBwb3J0DQo+ICB4ZW4vYXJtOiBmZmE6IGFkdmVydGlzZSBGRi1BIHYxLjINCj4gDQo+IHhl bi9hcmNoL2FybS9pbmNsdWRlL2FzbS90ZWUvZmZhLmggfCAgIDMgKy0NCj4geGVuL2FyY2gvYXJt L3RlZS9mZmEuYyAgICAgICAgICAgICB8IDIwMiArKysrKysrKysrKysrKysrLS0tLS0tDQo+IHhl bi9hcmNoL2FybS90ZWUvZmZhX21zZy5jICAgICAgICAgfCAyMzIgKysrKysrKysrKysrKysrKysr Ky0tLS0tLQ0KPiB4ZW4vYXJjaC9hcm0vdGVlL2ZmYV9ub3RpZi5jICAgICAgIHwgIDE0ICstDQo+ IHhlbi9hcmNoL2FybS90ZWUvZmZhX3BhcnRpbmZvLmMgICAgfCAyNjMgKysrKysrKysrKysrKysr KystLS0tLS0tLS0tLS0NCj4geGVuL2FyY2gvYXJtL3RlZS9mZmFfcHJpdmF0ZS5oICAgICB8IDE1 NCArKysrKysrKysrKy0tLS0tLQ0KPiB4ZW4vYXJjaC9hcm0vdGVlL2ZmYV9yeHR4LmMgICAgICAg IHwgMjM3ICsrKysrKysrKysrKysrKysrKysrKy0tLS0tDQo+IHhlbi9hcmNoL2FybS90ZWUvZmZh X3NobS5jICAgICAgICAgfCAgNTIgKysrLS0tDQo+IDggZmlsZXMgY2hhbmdlZCwgODI3IGluc2Vy dGlvbnMoKyksIDMzMCBkZWxldGlvbnMoLSkNCj4gDQo+IC0tIA0KPiAyLjUxLjINCj4gDQo+IA0K DQo= From xen-devel-bounces@lists.xenproject.org Thu Jan 08 08:25:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 08:25:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197369.1514915 (Exim 4.92) (envelope-from ) id 1vdlKF-00021V-Os; Thu, 08 Jan 2026 08:24:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197369.1514915; Thu, 08 Jan 2026 08:24:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdlKF-00021O-LS; Thu, 08 Jan 2026 08:24:59 +0000 Received: by outflank-mailman (input) for mailman id 1197369; Thu, 08 Jan 2026 08:24:58 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdlKE-00021I-LE for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 08:24:58 +0000 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [2a00:1450:4864:20::330]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 81be3124-ec6b-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 09:24:53 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-477619f8ae5so23072475e9.3 for ; Thu, 08 Jan 2026 00:24:53 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0e6784sm14638093f8f.19.2026.01.08.00.24.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jan 2026 00:24:52 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 81be3124-ec6b-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767860693; x=1768465493; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=LK4SUJLgNmI6mwIC4gB+nan6RaJdNdwyeWcgaJDMTDc=; b=JxzO6MY8AJhNdE78FvI3jKLXvCQNou7FLVsEu4R9zgp986TMd53ssWFgzq5+aPTmoD ZjvqT/qovoGHyeLkzHCHp8ZQAef2P7UOSjanbgSpXQSLLtBxSFTcL+XtbPUpR5C3ELdw ZRLM2PtYs7itjovjofAqhvpfI1NlbjF1rI2eMBxhuNA8bcDWZ2AxB5Bs2EugVEPH1nX9 UT8w/w2WhdRdv23BH6InvEpILCQOTGQo50wefwldwseHbvpZHNb2pvCUEu8bcKzZooI7 i15BKvBUB9BVJWc7ZOL/w+f4DCkjMn9mjqUIcyCcnrbaq+rhFyHj2/nktqOUT7JYZXI2 MDXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767860693; x=1768465493; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=LK4SUJLgNmI6mwIC4gB+nan6RaJdNdwyeWcgaJDMTDc=; b=aTtFG6kFB28tIAYM8lC5WdmzSBRGYOX0L4sBtUrzq2V0b+6La9FM/H+g0eSOjy/XLb J442KO5d/uiJN3fbRAuB4GsrqFsu7+qf3S9WMaFvWPI4uT5RnKDrNALQfkD1H/nAP6ut rO0ocqfhFsQLxHlfwmoCZ/i1p1wcYNhxF86kuo5rna4EGB3AMXPDIOtWeijMGNIrxlsG 1onKy5ZZoNITkgWHbzp/rjhaYo+7LL9HWxvCoxrlrLZj45k69SqpSNNdMm1bWKDD6r7J sQlxLl4Wgw946dFIVhi4OVXGd37X69PaV/EVXN+exaN5KkBNt5dLelPFtdhusZoZtmLo axUA== X-Forwarded-Encrypted: i=1; AJvYcCVYHX3jR//bXcskdOgJ49W4N22VKzpe354jT5W0FfYP0+/tOpDlQ4i/3rXsc4mSbXx8XEIYeEstj8c=@lists.xenproject.org X-Gm-Message-State: AOJu0Yze+r8c7jEQcu1iuTQ0dbdCQAIJG6jCRYa2LsnkqCvYDA70VCxP e+u9h95Ack0AlVLKvTFTceTQXFpPYOOYMiLWHovchnjXd5dz1jXWqrnONY4IQbqp3Q== X-Gm-Gg: AY/fxX5BhsFFNk6tnf7hIDpkHvYYqDDot9NkjIiV/9+3GBTUA/MIfBk8sKuk9SrmG3Q +REhCjFTuLwBJK2YEZlO6vWSNU6iXUHh69ZrZCDSchHLa07YFRmEeuAUhn6yDVBsN11MNmEb9ga Jy3AJ8+DIU/Q+sEM1PgOFA7X5G68A4uj7pPgGep44HKRMo79+A6H/u9Je+vk9ajickoFOqaZCe7 LXbXRY8OFw+oLBoBCqNJo1EbxZd8JJD0wmz+CwDMXJxoBA2OdYcC72MB/aQLpjBVhxLNumBaO2M sToWLJVjw6rN0yoCP6VBGmQm8fQSbUPhHA2BWcRIms/imWTw2UEDkHqQYN8qZQ3DWUQD027AqWJ kVLlYQAzluO6Sh3iZAXgOfGoHGxbgJycPcpB14hvato9ZIarnoRCPBgyhkTXBSfCUQoD5Qs95xv 3zkSfqHSALZlVSeA823Rt90gi1M+dWFUz/iwFjJ30HuNmDqNLm+ITNBhvmsw6i5AxXLVk3xv+Gx Ws= X-Google-Smtp-Source: AGHT+IHoblTzJCRaWBApVfWBfl6ljgVp36tsrxRsODhVbnXGaaV+JMBrG6LYgYBA3JHwa0Oc8IG68A== X-Received: by 2002:a05:600c:4713:b0:477:1bb6:17de with SMTP id 5b1f17b1804b1-47d84b5b43dmr69733295e9.30.1767860692653; Thu, 08 Jan 2026 00:24:52 -0800 (PST) Message-ID: Date: Thu, 8 Jan 2026 09:24:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] xen/mm: move adjustment of claimed pages counters on allocation To: Roger Pau Monne Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260107175605.56617-1-roger.pau@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260107175605.56617-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 07.01.2026 18:56, Roger Pau Monne wrote: > The current logic splits the update of the amount of available memory in > the system (total_avail_pages) and pending claims into two separately > locked regions. This leads to a window between counters adjustments where > the result of total_avail_pages - outstanding_claims doesn't reflect the > real amount of free memory available, and can return a negative value due > to total_avail_pages having been updated ahead of outstanding_claims. > > Fix by adjusting outstanding_claims and d->outstanding_pages in the same > place where total_avail_pages is updated. Note that accesses to > d->outstanding_pages is protected by the global heap_lock, just like > total_avail_pages or outstanding_claims. Add a comment to the field > declaration, and also adjust the comment at the top of > domain_set_outstanding_pages() to be clearer in that regard. > > Note that failures in assign_pages() causes the claimed amount that has > been allocated to be lost, as the amount is not added back to the domain > quota once pages are freed. Given the intended usage of claims is limited > to initial physmap populate, and the current failure paths in > assign_pages() would lead to the domain being destroyed anyway, don't > add extra logic to recover the claimed amount on failure - it's just adding > complexity for no real benefit. > > Fixes: 65c9792df600 ("mmu: Introduce XENMEM_claim_pages (subop of memory ops)") > Signed-off-by: Roger Pau Monné > --- > Changes since v2: > - Revert back to the approach in v1. You didn't fully go back to v1. While ... > @@ -548,9 +524,10 @@ int domain_set_outstanding_pages(struct domain *d, unsigned long pages) > unsigned long claim, avail_pages; > > /* > - * take the domain's page_alloc_lock, else all d->tot_page adjustments > - * must always take the global heap_lock rather than only in the much > - * rarer case that d->outstanding_pages is non-zero > + * Two locks are needed here: > + * - d->page_alloc_lock: protects accesses to d->{tot,max,extra}_pages. > + * - heap_lock: protects accesses to d->outstanding_pages, total_avail_pages > + * and outstanding_claims. > */ > nrspin_lock(&d->page_alloc_lock); > spin_lock(&heap_lock); ... the comment improvement is of course okay to keep, ... > @@ -999,7 +976,7 @@ static struct page_info *alloc_heap_pages( > { > nodeid_t node; > unsigned int i, buddy_order, zone, first_dirty; > - unsigned long request = 1UL << order; > + unsigned int request = 1UL << order; ... this I'm less certain about (and if it was to be kept, it should also become 1U). For one, this bounds check: if ( (outstanding_claims + request > total_avail_pages) && ends up still being okay (perhaps except on Arm32, but the wrapping issue there is pre-existing, albeit possibly benign due to other constraints), but just because outstanding_claims is "long" (and it's unclear to me why it isn't "unsigned long"). And then, what exactly is it that you want the more narrow type for (the description says nothing in that regard)? The other relevant uses of the variable are avail[node][zone] -= request; total_avail_pages -= request; where both avail[][] and total_avail_pages are (unsigned) long (again unclear to me why for total_avail_pages it's plain long). Oh, wait, it is ... > @@ -1071,6 +1050,30 @@ static struct page_info *alloc_heap_pages( > total_avail_pages -= request; > ASSERT(total_avail_pages >= 0); > > + if ( d && d->outstanding_pages && !(memflags & MEMF_no_refcount) ) > + { > + /* > + * Adjust claims in the same locked region where total_avail_pages is > + * adjusted, not doing so would lead to a window where the amount of > + * free memory (avail - claimed) would be incorrect. > + * > + * Note that by adjusting the claimed amount here it's possible for > + * pages to fail to be assigned to the claiming domain while already > + * having been subtracted from d->outstanding_pages. Such claimed > + * amount is then lost, as the pages that fail to be assigned to the > + * domain are freed without replenishing the claim. This is fine given > + * claims are only to be used during physmap population as part of > + * domain build, and any failure in assign_pages() there will result in > + * the domain being destroyed before creation is finished. Losing part > + * of the claim makes no difference. > + */ > + unsigned int outstanding = min(d->outstanding_pages, request); ... the desire to avoid use of min_t() here which wants "request" to be "unsigned int". At some point we'll want to change the struct domain fields to unsigned long anyway, at which point the above would need adjustment. It's well possible that such an adjustment would end up being to then use min_t(). Imo we'd be better off using e.g. unsigned int outstanding = min(d->outstanding_pages + 0UL, request); or even typeof(d->outstanding_pages) outstanding = min(d->outstanding_pages + 0UL, request); right away. In the latter case the decl wouldn't even need touching when the struct domain fields are promoted. > + BUG_ON(outstanding > d->outstanding_pages); Unlike in v1, where the min() was different, this is now dead code. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 08 08:42:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 08:42:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197381.1514924 (Exim 4.92) (envelope-from ) id 1vdlab-0004ol-VH; Thu, 08 Jan 2026 08:41:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197381.1514924; Thu, 08 Jan 2026 08:41:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdlab-0004oe-Sb; Thu, 08 Jan 2026 08:41:53 +0000 Received: by outflank-mailman (input) for mailman id 1197381; Thu, 08 Jan 2026 08:41: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 1vdlab-0004oY-5g for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 08:41:53 +0000 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [2a00:1450:4864:20::330]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e0e407e8-ec6d-11f0-b15e-2bf370ae4941; Thu, 08 Jan 2026 09:41:51 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-47bdbc90dcaso21209635e9.1 for ; Thu, 08 Jan 2026 00:41:51 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f6ef868sm138402175e9.11.2026.01.08.00.41.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jan 2026 00:41:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e0e407e8-ec6d-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767861711; x=1768466511; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=FSd53XP5/GHgnvJv/b++KvdNlJAFLhPHwT5yv/HRIU4=; b=PtTzlXDaHBIXFfciCst2cL10JWRnd26Oh/xLo6G5BLplcbjszbhBoaR9PJ4nlSUzwt ijh2NToeegTvZ2b4YulsI97J11vY5mUkZn49Ox4DhjJn8yiBeppstFbKM/y8KQ1we/b1 H4T5GJukOnOtG3mjUlSSmNEYcipomCzup1Hu1BHhIY+WETy6F0fgKtK/A453AedRhVCy AcaJuskq/UokT/pcnW7DSlo9Tex5+SxMQcxtmDhWZJZgK5tXnvtce442TozDnElctDHa sgEN5ZdiiJTqYy8jnMQE9vfWTQmWpntesbAQkzl7LSqz7C9fWLXn4SJj3iQIFFQwfUGY qLMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767861711; x=1768466511; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=FSd53XP5/GHgnvJv/b++KvdNlJAFLhPHwT5yv/HRIU4=; b=h8clScdkcVPtQSmc0kfqnstRbyv2hfixKUNG/8aJbJiHVHbR5xt3IcOPZYcov5yKsw HKSg8N+Cp/Ud06vE/mIBuJ8Ro9gid3La5RQrflrGatqyEBugBF1J2QuLaRSGUlllMQM3 Lhx0EZbDxZRRh5nlmEPLUf9Yr7tlCmNEohEzN4vc7DiecmSvz5wlkYPBB4YQ55F4JW/d XMtUewvTlFyAk713jgytrbrFdQIj8mPt1feXb5xpV6ePYA3nTnUl00io8yzrd/yAWary UE4pFBTMceZsLSRAfymtV5GSz11S7N91UPTtSyOyAup23u5MlayP9hC6gC3j9sAP+9mW txww== X-Forwarded-Encrypted: i=1; AJvYcCXQGpduDqHFg8YKQC+Yogo/JdknC6/43Jyc6HTKONf6kvEs1nJYq4wAu/VnwN6SfvcKYcGx3LFhkg4=@lists.xenproject.org X-Gm-Message-State: AOJu0YxyKkyQvMR6JhUdI61Nk1tVQYAgocCSHhvPiMJsk/oYppz1edRa tFN2jl6PPiteP2jdMgjBMuuqiNUQwAmUMiJkjif2lzPdJn3g6h6dQG9lSq/fPO7jUg== X-Gm-Gg: AY/fxX4nqUb4ZVfpT2QUKKDMjf3fguTCaK3Cqg1I0/pOuzT+GBi8eIkN7as0WhwRgqM 44qyaRONcqB0CbNI0UP7AjrA3w4FsVhg97zLUZycbDUNwp9Ixfua3vDvys+LHRX2Jk2zsKFekr+ 0Zi60cTE+p77QBDcOUg5Yq1uESAljulQZGvRKQvYlMXj0WbCebn5qZnb/MmtzdZzNsU8pWCT4uI SSs3qWaX8sC68Yd9/NNMupX3MFpLFKMahyH1bUxXlmd6aYcaNNSVasMhdt7OJFuJ2kiZmya/N8Y Hr8xJ+kFSpleGjFLY/51nk49VWLFYx9L8pMrSbc5c7hSmwKakE1hK5GBTg2QXHjYI0QFPHXlyFu APzu9kW5q+5IXy26TKZAMtdJaaVyjEdZMbnJs/osdLEyP927HCq/yHOgwyLl51HiwnEUkdanvMM 26vGQPCp8s1rtzFo3Skhcx22z7shpznBbJOoUEm2yJEatKS5F3fuyNE1XDA4S1NfPlbVLJ61mhF Tc51F3C6vZkXA== X-Google-Smtp-Source: AGHT+IFEU2JsLKz49gL8f/AAUcx2SSczNni/oNGM3pZULGHjcrqCu1fYiRZjMXg0XnVvUQJKzUZdCw== X-Received: by 2002:a05:600c:83c9:b0:47b:e2a9:2bd9 with SMTP id 5b1f17b1804b1-47d84b3b719mr72281925e9.31.1767861711227; Thu, 08 Jan 2026 00:41:51 -0800 (PST) Message-ID: <6ac0b4d8-3762-427e-a856-be9118e90dc0@suse.com> Date: Thu, 8 Jan 2026 09:41:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] acpi/arm: relax MADT GICC entry length check to support newer ACPI revisions To: Oleksii Kurochko Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Yann Dirson , Yann Sionneau , xen-devel@lists.xenproject.org References: <3850c51d41b1ab67a453ca70c0a44172185274f6.1767694781.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: <3850c51d41b1ab67a453ca70c0a44172185274f6.1767694781.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 07.01.2026 17:34, Oleksii Kurochko wrote: > Newer ACPI revisions define the MADT GICC entry with Length = 82 bytes [1]. > The current BAD_MADT_GICC_ENTRY() check rejects entries whose length does not > match the known values, which leads to: > GICv3: No valid GICC entries exist. > as observed on the AmpereOne platform. > > To fix this, import the logic from Linux commit 9eb1c92b47c7: > The BAD_MADT_GICC_ENTRY check is a little too strict because > it rejects MADT entries that don't match the currently known > lengths. We should remove this restriction to avoid problems > if the table length changes. Future code which might depend on > additional fields should be written to validate those fields > before using them, rather than trying to globally check > known MADT version lengths. > > Link: https://lkml.kernel.org/r/20181012192937.3819951-1-jeremy.linton@arm.com > Signed-off-by: Jeremy Linton > [lorenzo.pieralisi@arm.com: added MADT macro comments] > Signed-off-by: Lorenzo Pieralisi > Acked-by: Sudeep Holla > Cc: Will Deacon > Cc: Catalin Marinas > Cc: Al Stone > Cc: "Rafael J. Wysocki" > Signed-off-by: Will Deacon > > As ACPI_MADT_GICC_LENGTH is dropped, update the functions where it is > used. As we rewrite the MADT for hwdom, reuse the host GICC header length > instead of ACPI_MADT_GICC_LENGTH. > > [1] https://uefi.org/specs/ACPI/6.6/05_ACPI_Software_Programming_Model.html#gic-cpu-interface-gicc-structure > > Reported-By: Yann Dirson > Co-developed-by: Yann Sionneau > Signed-off-by: Oleksii Kurochko > Reviewed-by: Stefano Stabellini > --- > I ran CI tests where it made sense for this patch, as I don’t see any CI job > that builds Xen with CONFIG_ACPI=y: > https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/2229673951 > > I also built Xen manually with CONFIG_ACPI=y enabled and tested it on the > AmpereOne platform. > --- > Changes in v2: > - Update the commit message: > - Use more characters for commit ID. > - Drop 'import from'. > - Add Reviewed-by: Stefano Stabellini . Was this a legitimate thing to do, considering ... > - Make the local variables host_gicc const in gic_get_hwdom_madt_size(). > (header variable isn't const as container_of() will discard 'const' qualifier > and so compilation error will occur). > - Return 0 instead of panic() in gic_get_hwdom_madt_size(). ... all of these (plus leaving partly unaddressed a comment from Julien)? > --- a/xen/arch/arm/gic.c > +++ b/xen/arch/arm/gic.c > @@ -418,8 +418,18 @@ unsigned long gic_get_hwdom_madt_size(const struct domain *d) > { > unsigned long madt_size; > > + struct acpi_subtable_header *header; Why is there a blank line left between declarations? In unusual situations (very many variables, for example) that may be okay, but otherwise the first blank line generally wants to separate decls from statements. Also Julien asked for this to be const. You claimed a compile error would occur if you do, but afaict that's only because ... > + const struct acpi_madt_generic_interrupt *host_gicc; > + > + header = acpi_table_get_entry_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT, 0); > + if ( !header ) > + return 0; > + > + host_gicc = container_of(header, struct acpi_madt_generic_interrupt, > + header); ... you don't use const properly here as well. Finally (possibly not for this patch, but mentioning since originally it was pointed out as an option) the function imo wants to become __init anyway, for (as said by Julien) its only caller being so. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 08 08:44:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 08:44:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197391.1514936 (Exim 4.92) (envelope-from ) id 1vdldB-0005KR-CX; Thu, 08 Jan 2026 08:44:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197391.1514936; Thu, 08 Jan 2026 08:44: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 1vdldB-0005KK-87; Thu, 08 Jan 2026 08:44:33 +0000 Received: by outflank-mailman (input) for mailman id 1197391; Thu, 08 Jan 2026 08:44: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 1vdld9-0005KE-DK for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 08:44:31 +0000 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170100009.outbound.protection.outlook.com [2a01:111:f403:c107::9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3de155e5-ec6e-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 09:44:29 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by CO1PR03MB7986.namprd03.prod.outlook.com (2603:10b6:303:276::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.3; Thu, 8 Jan 2026 08:44:24 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.003; Thu, 8 Jan 2026 08: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: 3de155e5-ec6e-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=a0w+MygcQ2qEMoUH5VqsRzX0XkcxY3oQU5AoaYtdYH0jvhqNe7PLKj2ZXUqqQjcjmpN1Y/qOqxMhPQ3e4xoXl3u9oh6sW2Aw6MVsgkfDJqK6Sc0tTNoehGO63Uxg83Hq7UY1UdcY8l8hKAmAsYRycpSNmsseCXFnTxBwGHOWL3/CrFmK+5wbBZUQvbZrjatamivKWwbEGev+vvwKgbBz1rp7xLCTxbCmjwj/KY15OFnv1+ynSq7UfjenLrzKHolLQtdsxi2ZWF6ehRTZfQND0QOHsMeYze9nVpPrlRf2F76/Y72a1JbhLkk4OtxIm1DqDXnChth3Kf4pNa6wkbTxlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+/T2eOW4hlqGLEqSlp0gtgrihr4y8Frr47rfOGW+7P0=; b=BTP7rzXx39BumsZJiAPTBQt5bAUNT7n2yXn6uObscibVZlwIz7Juoscp2JVpVHrF691fOf40OMkFZCOzMxtRBmt/FS1RZUrHMaGREnzp9Yv2lhsE9KS4ym466UYGimJnd8b/7wuCUdlWmhpAjVVJf6THign+KQCLm/P6dWIm7bPZpelm5Zz6ho200H8dWmyf5VAzaMLy+Wd/iQ+jc6QQOtTELli95pZ22/FLMh/prEm4i73IcRlfbPrYJ4Rr1xcFTCuhx4C+PUKj2Zge5dfabVTYSk7H3xD0gUqmxIsCICwrQHuuaeOdgILZ3RwM7PM1bcjmxuEzlUlTqF1e8q4Opg== 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=+/T2eOW4hlqGLEqSlp0gtgrihr4y8Frr47rfOGW+7P0=; b=smfnYhBYBKVhWbWQ1L1FCcjM++IThXOjiy1XfJz5mhAOqbwXubPBWtQKwJFOtt5Tiul3Nx9vzAkjgR+Sm/q6Nl/9R/fDeOn9ybm0/DGuvdoU1zMioj/8bCU9G0F5c5bc+UwY8cloAeJkIGHJwcV+gEHBHUsOJFyYcJ+6dVfwVJk= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 8 Jan 2026 09:44:20 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH v3] xen/mm: move adjustment of claimed pages counters on allocation Message-ID: References: <20260107175605.56617-1-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: PAZP264CA0015.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:21::20) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|CO1PR03MB7986:EE_ X-MS-Office365-Filtering-Correlation-Id: efee16c7-036d-4c9c-78f6-08de4e922016 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?THRJajRQWDU0MWZONUhBd0R4Q0RUOWsyWDc3WUZJY1VDSHdWMzUvYVBiTmFI?= =?utf-8?B?WTBxMjREdUZVQmtYTUJZamxFWEQxS21HNUw1cFVDN0N6a09xOVdwc1BxUHcw?= =?utf-8?B?YmdySjl0aHJYOTR3REg4ZU5sa3RjcXNDWEVXZG55R3hHeHFQVngvM1FyM2ps?= =?utf-8?B?WnpWOWRUdWVnZlhiSGN6OTVSMXZVSGNEUWl0bXNnbiswNjJRUTRuVzA4citn?= =?utf-8?B?SUYvay9KTHJ0ajVYS3NmSk5xc0dRcXprZ3RKdGFFdE9mRnRXTlMxK2dIUkFK?= =?utf-8?B?VW9EMnhyMDBUaFkxakcrRUNDQ1BYQ3piNE5RQUFKeUNsYjZ5Q1ovajNYTWNj?= =?utf-8?B?ZGREc3QwMzU0U0paZlJjcXFpdkdUWGtjZitya2dhQ2hvclZmb0xrdVBIdjAz?= =?utf-8?B?Ums2R2NpSVROelM0NE1SQVFPUTh3ckJGRk15WlE2N210OFNsQW5aT29JWFhk?= =?utf-8?B?c2lDVzBERWdyQWJhbDVuZTN1S2tVSEVVUTdNeVBTakw1Y2Mxa0x3WlFmelox?= =?utf-8?B?dUM4ZkJPTkoyVGxWbDExbkJXNnFxZHJ1QlhERXAxdjdkTWRYTVViR2hXVzVy?= =?utf-8?B?amZ3eENkanlXQ3VkOHlKRXJBWFFNaVhtakdXdjdDZ05uQ3ZrYUNCeGgyS0Rr?= =?utf-8?B?MUlGTFZVa016Wng4WEN2ZWVnZWIydXhqcGM3RHprTXJiY2hBdUt1OWtkcGh2?= =?utf-8?B?Q2N2ZVVJbE52TWZQYjZ1L1VPcU1LaXFEeW1rTVVtZ2FpZ2RlWWdKZkI1ME1l?= =?utf-8?B?bEhqd0tGT0VPSm1sdDJScFVFVGt6ejF3Zk14YkdMVGJvR2EwSlNqbXpVWXov?= =?utf-8?B?MlNZaFFyZ3prb1NhTDEzUVRZZDRiclJjNXF2cjY0Z1RReFlFSy9iRTdhanBS?= =?utf-8?B?ZkttTXJld25pd2FGaHp6VzdscmpzOEt4bml5Uyt6Y29HZzIxczRIbkF4em4r?= =?utf-8?B?OGVoYTI0K0JkK2htcWR2L1ByemkxczRjbU9PbElrU1l0SlNJa1RnWE5xYUVC?= =?utf-8?B?S2p1d3pubFNaNklBVmdOY1ZkYjRYK1VMOTFuMlFSV2R4MXQwTEtOaENEdjdH?= =?utf-8?B?MEczaWtUQ2p6c1pNS2o2Y2xJVGdoZmxPUDRWdUN3cHlmbXcwWFJTd29EYzd2?= =?utf-8?B?a243cGc2SHdrWmZpN0ptSG9BSWVET0JDRGw4a1RkNUJoQkIzbkhPVVdRSmF1?= =?utf-8?B?b25tR3hhcTllZTg1VEcxSTJQcWJLcVRzakxUQ2hIb3IwOU44SC9WbWJuVklu?= =?utf-8?B?cFZXRzlmVXQxUVp4UlhyazZ4WHkyajBmZTJOdE9BTDhXY3ZCdVdZbStqM0FP?= =?utf-8?B?N0Q0NDkvMlJTUGNsUDhIZnl2QTJpdWVQcWVtQzUyOURwRWV1MDRUZHp3ZU8v?= =?utf-8?B?K2VYbFpRNXh0bVJLNkhSbUdUcEVzTHBDbWNkakVRYWJQT1ZwSFJPcGdqcWJh?= =?utf-8?B?RWtndFhDajJqaEhickRySmZmRWlzZDNLb0FKWVVQRXk0UGxEUmt5ZFh5L2Yz?= =?utf-8?B?NWh1VTFla21UN0ZwZ2EyelM0aW9uU1YvbXMxdnlacml5dTh6cnIxMXZOa0ts?= =?utf-8?B?d0Q3cXNvNXQrUG8xMk83a21IcjlVbXpGR1NwbDFMUFkyMklkZFNpcXJsdGNn?= =?utf-8?B?MTNMbXgwQm02djNmZ21IOXh1M0JDQ3pMNFBBRVNyd1NFeDZXa0JHeDNaOFZw?= =?utf-8?B?dzRvVjZMdXhiakZtaXBBWVRPcVlMK2lNb0oyb3llUUxxOHlzUHdMWTNwTWR6?= =?utf-8?B?ODIwY1BHQjk2M0V6YzRVS3VneXozMkVqVzByNXZ6eWYrbyszYzJPZVFyNmx3?= =?utf-8?B?M1Q5U2o2WTJZL1cvS0YxU1VkVzkySFowZ3lURFp6RUE1RG9Od1pKeWJodFRX?= =?utf-8?B?RTRkVHBGZ3NsTDZlcis5YXZ6N3VCZFZCNnpCTDZEMVl5bXEreU1udGt1U3Ex?= =?utf-8?Q?Wo7WnNa3LkEysA0l6Lx9qerYKP6n0dob?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UFM2NXBNWEUrbUVPT1FiMi81b2EzQnRYYTJjMFB4dGQ0UDNCdXFFakNlTGdE?= =?utf-8?B?NnhRc25QNlpPVGxzYVhpRVE0UDFNSXZKeGY4SjR5MXZGMHdkQ0hXYXpWM0dq?= =?utf-8?B?TEpUait0S3lGdmo5c1hpVUpXK0JrQnQrUXhVMXpJWDFYS05tVHZ4Y01XcTBj?= =?utf-8?B?Y2xPUVV3a3FDTTBCU1k4QnMwU0liK0pkK0RUdVlFMG5uN0RTZ2pPMm8raEFL?= =?utf-8?B?STNPbzFaNmV0UExqRjBidTlNRDEyZnM3UDF6WVZlUmQvOUFhOFN2Mk5nVVFP?= =?utf-8?B?TGxDU21reGg5YmQ1SXludmxxVnBLcjlSK29YWDY2Vm5kNG8zMXNOZUQxUDA2?= =?utf-8?B?YXR6TS9TWDM2VVFvQ3U5WXZTTGpRUHA0MWZ5SkVXMlVyNHlXalluMkNkSHMw?= =?utf-8?B?M3R0dU1DSE1aWUJ0QXBuMmZCZFQwNlVsbGdwVlJCb2Z0cFJPSWpZVFVvSlN4?= =?utf-8?B?aldaUUxxQXRoMlBLZzRnb1VDclRoVGVJTWdTZGJzUVdRSWN3RWhsS21oR2xn?= =?utf-8?B?aTVMZ2Q4OXpFalhEUEszU3hBcUFUZDFFcGtFK3JkMW9VMHhpbndCbGRIYTln?= =?utf-8?B?L21aLzlST3lJMGtmWlpyWEI4SU45Z28yNmh4ZjFZTjdIVWY3Qy9Ka0dqYW1P?= =?utf-8?B?ZEN4REozMHUwWFVEVHR6SFdlN2hvbmE0OFFrakQzOVMxcFlEbnFFZ2l1eXJ3?= =?utf-8?B?WllJYVpzeURWMWZROGtqM0RxUDJQZlVkTkJha0h2VXQzUWdsUExBK3pEOXVo?= =?utf-8?B?SHdYaURnaGdKd2NTREIyK3hwUVlSSzk1OVA2L2YrU3I5aE1IeXdKMXByRWFZ?= =?utf-8?B?QjZBNzgvamVHTXExZXNiOU8wMTIrUHFJYmpacGZSZXBwelc5aTR5QU51RkRk?= =?utf-8?B?RHpVMURuY1l0dnlBTkNqSXBoZTZ4WFAzbWFZT1dUTDFrb3BWNWQvZStlTEhZ?= =?utf-8?B?NWppOTBYT01kSllNc0FNWk1URWQycUJIL3o1UlVnTXEydE9pQjYrQzNUT05H?= =?utf-8?B?bldNWHBON25icWpKdWVlSDhjVDBJSFhnRER4Z1NFUWY0U1cxTEd3b296a2hz?= =?utf-8?B?QUVKaW1mQmNMZWRnR3o2RHNiQzYyTi9yL0p4MVZIZEx6RjhvT1RsL2dNdzNW?= =?utf-8?B?K2hwR2JrM0pveWNWVTRPUXhheGtlOEhOcVR1azZ3Nll1RDFsa0Vkc0dQQUht?= =?utf-8?B?TE05UGFFR1V5Z2dNcmdLaFVtZC82LzNKVEZqb0czRVpWUXozeHJncEkvRnpJ?= =?utf-8?B?dk5pNFF2MEFmek1hdnpvaCtVYm1EeG55bmlFWTlSVGdsUkZPdjFKR1BtQmMz?= =?utf-8?B?VWZSeGJBanpTeWdENm5pL283YnRGcThqQW9HeXFmRUptSERHbWVWbWVNZlVU?= =?utf-8?B?SVZUWWc0cUdDV25nUklkeXdKRSt4SW0za1pMR2U5ZXJGVFFUN3lQNFlNbHRp?= =?utf-8?B?STBzcnBBVHlQMnZBcFdMWlAwbDJabGQzQ1dTZVo2aEN3K0lIQVNhQ04yVU9E?= =?utf-8?B?MW1rK1BlOHN3Ri9aZysvMzNpZGlIN3hDbG9ON3lGK0FiWFJ1ZnBqN2RrbGc0?= =?utf-8?B?T0JmL2hNVC9CN0ZSdGhlcmpoYWx6WEpMZGxIVmpHaUhRZXk0dXYzSW8yWkpE?= =?utf-8?B?Vm9LWTRrM3d6c2tndTNHckY5VFBiQ3UvRnNhMzM1QkpGamlXb0Q2MmxDZFlC?= =?utf-8?B?VXc2cW94N2N1YlNtSVh4UkFkWkVPMUdsL0hHd01Cek40SjQzTzcrZWc2YTN2?= =?utf-8?B?WnBVL0crTkVCeGxjODlZWHFkbGFIbmhseW5xRTBXOVZyNnM2U2EwaVduVmRi?= =?utf-8?B?WjdocXQxYy9maWx4YkhudlhQM3l4T2x2b1ZROEVET0UrR05rV1JPRjNORDVn?= =?utf-8?B?VGc4SlBWVU0rSVhiLzdrTmVJTU1zWFFJOC8xaHZ6V0pxSzd4S2tUWnhGS1JD?= =?utf-8?B?Zmx6UHFnSmJGZlB5cUZmZE5nR0NSSnplSUROc1p1NTRMa21LU0NqejE4bHhO?= =?utf-8?B?aEZINGRmUGNPTkErNXBKTDFDRDZkdzVndnB2MVg2bWFpVW13aEdaN3FKY1Jv?= =?utf-8?B?N3FCTW43N0xDOFZneDJpaThqckVBZXYyVW5kNitKNGoxMGMvdmxZbHArMUI0?= =?utf-8?B?REw3Q3ZwSUd1RGdWRCtHQ3FteVU5QXlaUGMxNHZERG1jeEp4RDdYbCtoNkpT?= =?utf-8?B?QnFPMnE4UzgvclppWWUvWDU2WWowVmJjRFhEMEpwdFZ3UFV3R3Fua3o2TWdv?= =?utf-8?B?SDVvUW15aGVXMXNlckhpV0RHLzlFbkVqVExBdlBGbUhDZlg0RS81QUhxKzMy?= =?utf-8?B?a29ZT2RaT0dnV3o1QTZBVE51NytpWUdUTDBUbWhJSFNtYUFibzZUUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: efee16c7-036d-4c9c-78f6-08de4e922016 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2026 08:44:24.5621 (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: YECqfVc8KZqEgQ2v5516m+QQzm90q57Z0Kzp6QDw1cS6YxcfRXRJg10T1iFbYTo6T5XJ9/YldckETK/kw8PPCQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7986 On Thu, Jan 08, 2026 at 09:24:51AM +0100, Jan Beulich wrote: > On 07.01.2026 18:56, Roger Pau Monne wrote: > > The current logic splits the update of the amount of available memory in > > the system (total_avail_pages) and pending claims into two separately > > locked regions. This leads to a window between counters adjustments where > > the result of total_avail_pages - outstanding_claims doesn't reflect the > > real amount of free memory available, and can return a negative value due > > to total_avail_pages having been updated ahead of outstanding_claims. > > > > Fix by adjusting outstanding_claims and d->outstanding_pages in the same > > place where total_avail_pages is updated. Note that accesses to > > d->outstanding_pages is protected by the global heap_lock, just like > > total_avail_pages or outstanding_claims. Add a comment to the field > > declaration, and also adjust the comment at the top of > > domain_set_outstanding_pages() to be clearer in that regard. > > > > Note that failures in assign_pages() causes the claimed amount that has > > been allocated to be lost, as the amount is not added back to the domain > > quota once pages are freed. Given the intended usage of claims is limited > > to initial physmap populate, and the current failure paths in > > assign_pages() would lead to the domain being destroyed anyway, don't > > add extra logic to recover the claimed amount on failure - it's just adding > > complexity for no real benefit. > > > > Fixes: 65c9792df600 ("mmu: Introduce XENMEM_claim_pages (subop of memory ops)") > > Signed-off-by: Roger Pau Monné > > --- > > Changes since v2: > > - Revert back to the approach in v1. > > You didn't fully go back to v1. While ... > > > @@ -548,9 +524,10 @@ int domain_set_outstanding_pages(struct domain *d, unsigned long pages) > > unsigned long claim, avail_pages; > > > > /* > > - * take the domain's page_alloc_lock, else all d->tot_page adjustments > > - * must always take the global heap_lock rather than only in the much > > - * rarer case that d->outstanding_pages is non-zero > > + * Two locks are needed here: > > + * - d->page_alloc_lock: protects accesses to d->{tot,max,extra}_pages. > > + * - heap_lock: protects accesses to d->outstanding_pages, total_avail_pages > > + * and outstanding_claims. > > */ > > nrspin_lock(&d->page_alloc_lock); > > spin_lock(&heap_lock); > > ... the comment improvement is of course okay to keep, ... > > > @@ -999,7 +976,7 @@ static struct page_info *alloc_heap_pages( > > { > > nodeid_t node; > > unsigned int i, buddy_order, zone, first_dirty; > > - unsigned long request = 1UL << order; > > + unsigned int request = 1UL << order; > > ... this I'm less certain about (and if it was to be kept, it should also > become 1U). For one, this bounds check: > > if ( (outstanding_claims + request > total_avail_pages) && > > ends up still being okay (perhaps except on Arm32, but the wrapping issue > there is pre-existing, albeit possibly benign due to other constraints), > but just because outstanding_claims is "long" (and it's unclear to me why > it isn't "unsigned long"). > > And then, what exactly is it that you want the more narrow type for (the > description says nothing in that regard)? The other relevant uses of the > variable are > > avail[node][zone] -= request; > total_avail_pages -= request; > > where both avail[][] and total_avail_pages are (unsigned) long (again > unclear to me why for total_avail_pages it's plain long). > > Oh, wait, it is ... > > > @@ -1071,6 +1050,30 @@ static struct page_info *alloc_heap_pages( > > total_avail_pages -= request; > > ASSERT(total_avail_pages >= 0); > > > > + if ( d && d->outstanding_pages && !(memflags & MEMF_no_refcount) ) > > + { > > + /* > > + * Adjust claims in the same locked region where total_avail_pages is > > + * adjusted, not doing so would lead to a window where the amount of > > + * free memory (avail - claimed) would be incorrect. > > + * > > + * Note that by adjusting the claimed amount here it's possible for > > + * pages to fail to be assigned to the claiming domain while already > > + * having been subtracted from d->outstanding_pages. Such claimed > > + * amount is then lost, as the pages that fail to be assigned to the > > + * domain are freed without replenishing the claim. This is fine given > > + * claims are only to be used during physmap population as part of > > + * domain build, and any failure in assign_pages() there will result in > > + * the domain being destroyed before creation is finished. Losing part > > + * of the claim makes no difference. > > + */ > > + unsigned int outstanding = min(d->outstanding_pages, request); > > ... the desire to avoid use of min_t() here which wants "request" to be > "unsigned int". At some point we'll want to change the struct domain fields > to unsigned long anyway, at which point the above would need adjustment. It's > well possible that such an adjustment would end up being to then use min_t(). > Imo we'd be better off using e.g. > > unsigned int outstanding = min(d->outstanding_pages + 0UL, request); > > or even > > typeof(d->outstanding_pages) outstanding = > min(d->outstanding_pages + 0UL, request); > > right away. In the latter case the decl wouldn't even need touching when the > struct domain fields are promoted. My preference would be: unsigned long outstanding = min(d->outstanding_pages + 0UL, request); If that's fine with you. > > + BUG_ON(outstanding > d->outstanding_pages); > > Unlike in v1, where the min() was different, this is now dead code. Oh, I need to adjust this so it's outstanding > outstanding_claims instead. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 08 09:17:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 09:17:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197416.1514945 (Exim 4.92) (envelope-from ) id 1vdm8b-00015p-Qd; Thu, 08 Jan 2026 09:17:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197416.1514945; Thu, 08 Jan 2026 09:17:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdm8b-00015i-Mw; Thu, 08 Jan 2026 09:17:01 +0000 Received: by outflank-mailman (input) for mailman id 1197416; Thu, 08 Jan 2026 09:17:00 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdm8Z-00015c-UW for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 09:17:00 +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 c7ce5755-ec72-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 10:16:57 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-4779adb38d3so20417045e9.2 for ; Thu, 08 Jan 2026 01:16:57 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0dacc5sm14743651f8f.5.2026.01.08.01.16.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jan 2026 01:16:56 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c7ce5755-ec72-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767863817; x=1768468617; 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=5bSZg6G2K02HYMv6dTp6lcuQv6mC9nXI1R3vXW4BMuo=; b=VO6hbUe+KGfHt+JD0ngIRgnUh8n4P0rEjXw+K+vpW7a4YX05mXKwGFBrOnuc9+/OOP I2rGa/wsqYhrkMwtcl7oL7a8i/UV/NmoRC/hXb8XphVA2KJLl6eRDnqucuavfb52vsF0 SuKhPsRHV8toV+j32hxjbJDhlvPiauhoThBtycjhA+/FBx8rJLFFYxkLvA3grHTxq3vA BtAIM73jquhh/bfFXlqhNntE+zlrFbTiszZXk0OrY28eFOFzW46n+KhnA+ZoYX0z9f5A wle+6F5n/XOa5lUOdx0oEgDYvcFmcyQlsoI9PqgWlh5e8zMa98Eny5uhcxN+PU8PKpFW DOYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767863817; x=1768468617; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5bSZg6G2K02HYMv6dTp6lcuQv6mC9nXI1R3vXW4BMuo=; b=TCqwuFc57vGgswmiTKxC+EmilhiR9lHMKrSIlR99ug03cMZQvi8JLOVzXpx4gRbv5R N/O3bXRxxqg6aPQ2m6WOx8ZlQi8pUil8WGV9bawUHEvQh+KUTK0D3+ipBQ/9eu8dCFQR lVNE92hTAhKX0/JONlMx2X7Z5SvQZGlMbvywc1ZizvYskYWII6HOpRjf09Gfdcw8KVwN hChihvGYW09f2U2WcKExYAWbz2rjdgwfUagSivVf2M1OumtZ9Ap0dfIgmNAMtj2Bf2FN ptlXJm4vH5kWUoM2pY0ZHapg0y1qtQvhub9Dq1LXjVRtDZSVFab//ea+JDNhYyxOn4lK XNvQ== X-Gm-Message-State: AOJu0Yy52ge2ms2kOgp/zJfZf7dbDSBY6K5as/w44ZpafPcECvWvRp3G VQNAtb7a+VLYllSmWcP9YWMsZVf7ds6HmVON8t2CdeL4o3rHxPseXR2T5WlBxkqr2AJnLWJszh7 37hM= X-Gm-Gg: AY/fxX761g8Hbl+tWcTc1PYjvZzTampeulmF2ouL53OCpwiPbZKyzTG5Hs8XpmrS0Lm yDbYeI0okPJElJROJtlug+NUgD3LFqEnWqOkLNdgFO5bjXfoMXfIOaQBAiS1B0G+Pzlh7rBOKHC 60dOI6vpfzuszMG2YtqnDeQBPING78twH00CjKQRa0Q5carz/fAnMkXO4zdR+oXwKcBJWpiIvZH 3o4pRra+FOTHdGknQzXI74pfz2Rm6oMPnt+Aqtc1MbqrSshuHoe5EaJjtGWo+CJKs+pchDKP/Sk Jg8uhuu5LJJTJXRhIu8BcJVOj7b72Dwl8do2QBAcT04/2Ry/jlNLAritB2eKbY0T7H5CYxK2Rit a7ejcF1QrNmIfSyrFu+WTGn5EJIAsO15HjSfVRZc3A1hFhMuPH3CySCTZEuJEUa5LxdE43iCROh MkCgZnISQ9Gkz1NKFYnSvjsLpvxiC+5CK6yEmx3f31zROUYeFFP0auLKLwwUc4uvnkiwbDW2fZf IM= X-Google-Smtp-Source: AGHT+IGWPstROHVuTt2BfhH/vFV12wJ7cCQwG+Fd26st5lAZjRHQZeSCKzCw8Eutdp1d10bnQ/YYjw== X-Received: by 2002:a05:600c:3b19:b0:45d:d97c:236c with SMTP id 5b1f17b1804b1-47d84b3b645mr67097935e9.21.1767863816633; Thu, 08 Jan 2026 01:16:56 -0800 (PST) Message-ID: <6b0fc1a8-fdee-40dd-b3c6-262c33607715@suse.com> Date: Thu, 8 Jan 2026 10:16:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH] x86/PVH: mark pvh_setup_mmcfg() __init Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Its sole caller is, and the wrong annotation would cause a build failure (non-empty .text) if the compiler chose to not inline the function when at the same time LATE_HWDOM=y. Fixes: be52cb139f57a ("x86/mmcfg: add handlers for the PVH Dom0 MMCFG areas") Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/dom0_build.c +++ b/xen/arch/x86/hvm/dom0_build.c @@ -1310,7 +1310,7 @@ static int __init pvh_setup_acpi(struct return 0; } -static void __hwdom_init pvh_setup_mmcfg(struct domain *d) +static void __init pvh_setup_mmcfg(struct domain *d) { unsigned int i; int rc; From xen-devel-bounces@lists.xenproject.org Thu Jan 08 09:18:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 09:18:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197423.1514954 (Exim 4.92) (envelope-from ) id 1vdm9w-0001dS-2C; Thu, 08 Jan 2026 09:18:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197423.1514954; Thu, 08 Jan 2026 09:18:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdm9v-0001dL-Vr; Thu, 08 Jan 2026 09:18:23 +0000 Received: by outflank-mailman (input) for mailman id 1197423; Thu, 08 Jan 2026 09:18:22 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdm9u-0001d7-4s for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 09:18:22 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f930ea0c-ec72-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 10:18:20 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-47d182a8c6cso18766975e9.1 for ; Thu, 08 Jan 2026 01:18:20 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5df96asm15021038f8f.28.2026.01.08.01.18.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jan 2026 01:18:19 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f930ea0c-ec72-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767863899; x=1768468699; 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=cu1PGF32gmkV7RT1BXwHaG+B74JdS50BdFXB9uA8is8=; b=WZuL3oVkmSYRX8ZtxQ0o7dpahz2Rz0X7RvPDvsEp69zn/28PITJqmaqojeXW2k+/XY qRFMm1jR5uiNHj0gUVlav5+nyCfyKszMvBreqvDL+MIwH66MvwfgDPtbBrCZ795LTbAF MQ6up9ZwlyyXL01RSPk4453MgO/hXhvqhkAj8XeaHZ3AJTrKM14HTadA6WXBGSel+H/d 5iXxA3zi+9RBTNRRV+0GTS9teNSYxLS+WS2yNjcHS/nJYWNqTYPcksBNKppMDoDwSIj8 tu/AD/nMYCfTpfsXrtP0xzgq58AtGW/AFZ9qm9NpU3dQhciRgmop5WB+9YPgATjQp9y/ XuXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767863899; x=1768468699; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cu1PGF32gmkV7RT1BXwHaG+B74JdS50BdFXB9uA8is8=; b=PBIo/lsvpn1zXRnK254xFl+BzeCJLhKtThte+kZFz6i9IJoLhapK0YQcfoXp1Qm2u4 /UJmOUxS44SYMmBGeX6hk5qA3jJuCKQLxcR4a65ATLO8rpFNfou4ED0VoOd2M/ukqtsr 1cq6ZMrqmGcpnCjo2XkVYjiVH2cC/JltfDTSQNM6g43PMS18Ef42Xtch/2Z7+6JS4q2e SWN/xK8yhHlWJodKIMBwP2DtgxCzpOldd4UfERouaLyBoRuxQdUPY7Ba2I7p4z9jgA70 vDYGI3e85aXh/Ap/84THSkyCQGO/X/af4sDkUN2jRRNl5tUZnI1lmcRacS77tBuVOfRJ RMJg== X-Gm-Message-State: AOJu0Yz2NLM/MVSxEvIAdJeMQnk3VEPNe5di6u3dR5tA/PVixdoyhksK OUoMictKAUfzAWU5CHpUU/a1T4k2reXJ/hh7cM4alMOnFcMpVm/1XuEWOwzMiOuK9y54c/avz5D ew3s= X-Gm-Gg: AY/fxX4MZeM1irbtiXJLUwvlHKzVOyFlkXURDSREi4y0e/ChKVL8CrAPS/HMUF5aI3P zBVd+AsBzj69lWraS98nieZZhFavLUac6dn7SuHBv7/aOF7qqrb43FYwDDYnjvysqw0HFiNkBW+ 6dGvWzfZjOoaMjp55jmTBkCfR7ABvqzQzHfDhFbBsZfNUCo0hEnNcJofJZyW9USmSa+wqDmGiZ7 aTz10I5LZi18xp9JnF8L0DLguG0VvAWilVqGbgegM+YTR10i6S1EKz/1/K69eBvCqBSp/sy7GjU J0zGA5FPDUE3O/BhqBtmVKm+98IvXAqGu7d9oWZN5KVVS4z41UsLscl/ziZV0W3R48ghKvJb/BL L/mzS8GTYsAI3WtwNaOlxgkTHpIOQhtQtjnBdsI/IUVzZCCO0fyzCvgT4U1ASbGb4cQMxqhI/pC bm7GnJXlKvXe3Bv2BXiyzZy7AbN4SuM6RI5Lx01NmwfG0//dZc2WqwcxaUWdPqAIUKKQa2im2u8 Yc= X-Google-Smtp-Source: AGHT+IHJD3lCt8ZDY178uKqW+KbDElvciEk0ONRA8CIPi4sr46p+mSspEaKgPwE+/vvdu3s/CG0tiw== X-Received: by 2002:a5d:5d13:0:b0:431:9f1:e4c8 with SMTP id ffacd0b85a97d-432c377c652mr6645515f8f.17.1767863899454; Thu, 08 Jan 2026 01:18:19 -0800 (PST) Message-ID: <875df90d-1d3a-416b-a958-3d3a31144f85@suse.com> Date: Thu, 8 Jan 2026 10:18:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Daniel Smith From: Jan Beulich Subject: [PATCH] flask: fix gcov build with gcc14+ Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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 Gcc's "threading" of conditionals can lead to undue warnings, as reported in e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116519 (no matter that the overall situation is different there). While my gcc15 complains ("buf[2] may be used uninitialized in this function") about only two of the three instances (not about the one in type_read()), adjust all three to be on the safe side. Signed-off-by: Jan Beulich --- While auditing uses of next_entry(), I noticed POLICYDB_VERSION_ROLETRANS dependent ones in policydb_read(): How come the 4th slot isn't used at all there (not even checked for being e.g. zero, i.e. holding no useful data)? Then again other instances can be found where data is read but outright ignored. --- a/xen/xsm/flask/ss/policydb.c +++ b/xen/xsm/flask/ss/policydb.c @@ -1271,7 +1271,10 @@ static int cf_check role_read(struct pol if ( ver >= POLICYDB_VERSION_BOUNDARY ) rc = next_entry(buf, fp, sizeof(buf[0]) * 3); else + { rc = next_entry(buf, fp, sizeof(buf[0]) * 2); + buf[2] = cpu_to_le32(0); /* gcc14 onwards */ + } if ( rc < 0 ) goto bad; @@ -1342,7 +1345,10 @@ static int cf_check type_read(struct pol if ( ver >= POLICYDB_VERSION_BOUNDARY ) rc = next_entry(buf, fp, sizeof(buf[0]) * 4); else + { rc = next_entry(buf, fp, sizeof(buf[0]) * 3); + buf[3] = cpu_to_le32(0); /* gcc14 onwards */ + } if ( rc < 0 ) goto bad; @@ -1436,7 +1442,10 @@ static int cf_check user_read(struct pol if ( ver >= POLICYDB_VERSION_BOUNDARY ) rc = next_entry(buf, fp, sizeof(buf[0]) * 3); else + { rc = next_entry(buf, fp, sizeof(buf[0]) * 2); + buf[2] = cpu_to_le32(0); /* gcc14 onwards */ + } if ( rc < 0 ) goto bad; From xen-devel-bounces@lists.xenproject.org Thu Jan 08 09:20:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 09:20:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197433.1514966 (Exim 4.92) (envelope-from ) id 1vdmCG-000388-G7; Thu, 08 Jan 2026 09:20:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197433.1514966; Thu, 08 Jan 2026 09: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 1vdmCG-000381-BI; Thu, 08 Jan 2026 09:20:48 +0000 Received: by outflank-mailman (input) for mailman id 1197433; Thu, 08 Jan 2026 09: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 1vdmCF-00037v-IL for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 09:20:47 +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 4de515a6-ec73-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 10:20:42 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-47775fb6c56so27289195e9.1 for ; Thu, 08 Jan 2026 01:20:42 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f653c78sm150109235e9.11.2026.01.08.01.20.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jan 2026 01:20:41 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4de515a6-ec73-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767864042; x=1768468842; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=onIWVE/IP+SB/1dZ7cWZPK9Db1hNVDuM5ILw+oXEWWA=; b=IOK8oKeVI1vi+8hEG1RMV/9atM7m0xdy0q4kQbOSCpY4ysINbN1xSPYjyePiib5fGW K8QsHq8/L+ZZWTRpnrg97R1F3ZgyeevUb2kxvoDmiixr/bM6cKxwhG7vAMaudpAUyXUH 0wDPFvRDRmRQBesnKpcgg4HjwDFnoZT8ievq0eqztINY0CZ8cA+tju0Vta51NlJTL0El +33CN0WmqJTyPBONZ+JwbuNZuxG/7VHcqVSMUIcGWTyGQq+DvC3wHrrdjkIYgsEuVMsE gHMwAoCz07QBxm4uPIQCXdYJQ42O+fvKBybKYQvK2zMnjaVVOSOeQcFJ+YUwOdn8aBL3 HmOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767864042; x=1768468842; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=onIWVE/IP+SB/1dZ7cWZPK9Db1hNVDuM5ILw+oXEWWA=; b=sOGTgtFO1oXS3MFQMGZqmkiJhDomkmW2xLaPZbLxx/fYSFB4vdsrRprNeo75GfOphg 2CYhW0quQFBCTGlYZeUaoTCOA90nLsHtwnhvwo84VlIAKdkhiqSNm+e0M6XApgN+4tzt Km7m8ZN+66FQgH3Mluea4aqCBpGadmUAI2VmegRXJH6mmruWkJDlle5F6w7LQ9GtJdWV 2RiMWN7/AFeXzPM3bK18/B1AhVwXsxUJnuUyG9CISw0pqBQKJFX0QBDjjncnHMSnmkDj lQ01WxtK7qtXySWME7XgPTZryjA3Rr5VtpHHsg0ycpxRMLV4SggM8rhGe1NvuceShX1e JAyg== X-Forwarded-Encrypted: i=1; AJvYcCWt8ZO757419buT2wTDyya7/DZiw7y7aftwPdkmQBQgYTuCqoOxSgMQak9KEmwifZYZb0FuKKGqbN8=@lists.xenproject.org X-Gm-Message-State: AOJu0YzwN1f8LOaRSRc4vhyTgjZc/esPxfFmgXiWN758o/FdpUlyCLhS /y25Z7H42PgPJqTr+hA88o4T6cq3zPQly4Tid+Jxy5oYuaa3c8nONoNWH8f+DSJVVw== X-Gm-Gg: AY/fxX5tsuiZHQIGyjDyiy94ZTcJl69ZKok/72WB9Hq7v2dYZwa5e0QkAAcaJS1mfZh dlRDiGZheOxTyvYZvqXD9eLfC4RlPStecie1xZUIq8mHEot1GavIgtqAGIE9oxfzPoyYwLyAbV3 g8aa3zqlhQ8egODlpujvQ58H7hGLDF+qAA9OXusIl8U54M4oBL7MMPvVhNIYi2/0gISE6N8ktRV DlVgJsLnNhJ84fbNZIGe8zNHZvyth6GRKdz1uec+LNDf6gJ0r5wL0H5Unvs2bb/+tf80GNIyjwq 19foMsFwI+OT1Crevcow2v1pIxWbFJ3gDz3KDru+HHpMVFekIpiYvr/+UasCuxZnonaiSq/Jf5/ ApVaQadKlDMgW9GRbD+3lIkc7z1Ppl217qBdKi8cRFiQaoTR33zMKuwzS6HNtZcfOsVvsLNHK4F N4fYJgReIahNKqHxpAFN6OVK3YdY5qtIMhSJg3Uhbcb/xK4QTHavFA1hUCVTVlMvp9AU9OFCGKE uk= X-Google-Smtp-Source: AGHT+IGc4IxeKEru9mmqM20HTHtObIoSd3upIXIBbTHVWlc9wDoNP56v6ZGho8oydFdVS1GSTQQfTg== X-Received: by 2002:a05:600c:a106:b0:47d:73a4:45a7 with SMTP id 5b1f17b1804b1-47d84b3badfmr65573355e9.24.1767864041575; Thu, 08 Jan 2026 01:20:41 -0800 (PST) Message-ID: Date: Thu, 8 Jan 2026 10:20:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] xen/mm: move adjustment of claimed pages counters on allocation To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260107175605.56617-1-roger.pau@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 08.01.2026 09:44, Roger Pau Monné wrote: > On Thu, Jan 08, 2026 at 09:24:51AM +0100, Jan Beulich wrote: >> On 07.01.2026 18:56, Roger Pau Monne wrote: >>> The current logic splits the update of the amount of available memory in >>> the system (total_avail_pages) and pending claims into two separately >>> locked regions. This leads to a window between counters adjustments where >>> the result of total_avail_pages - outstanding_claims doesn't reflect the >>> real amount of free memory available, and can return a negative value due >>> to total_avail_pages having been updated ahead of outstanding_claims. >>> >>> Fix by adjusting outstanding_claims and d->outstanding_pages in the same >>> place where total_avail_pages is updated. Note that accesses to >>> d->outstanding_pages is protected by the global heap_lock, just like >>> total_avail_pages or outstanding_claims. Add a comment to the field >>> declaration, and also adjust the comment at the top of >>> domain_set_outstanding_pages() to be clearer in that regard. >>> >>> Note that failures in assign_pages() causes the claimed amount that has >>> been allocated to be lost, as the amount is not added back to the domain >>> quota once pages are freed. Given the intended usage of claims is limited >>> to initial physmap populate, and the current failure paths in >>> assign_pages() would lead to the domain being destroyed anyway, don't >>> add extra logic to recover the claimed amount on failure - it's just adding >>> complexity for no real benefit. >>> >>> Fixes: 65c9792df600 ("mmu: Introduce XENMEM_claim_pages (subop of memory ops)") >>> Signed-off-by: Roger Pau Monné >>> --- >>> Changes since v2: >>> - Revert back to the approach in v1. >> >> You didn't fully go back to v1. While ... >> >>> @@ -548,9 +524,10 @@ int domain_set_outstanding_pages(struct domain *d, unsigned long pages) >>> unsigned long claim, avail_pages; >>> >>> /* >>> - * take the domain's page_alloc_lock, else all d->tot_page adjustments >>> - * must always take the global heap_lock rather than only in the much >>> - * rarer case that d->outstanding_pages is non-zero >>> + * Two locks are needed here: >>> + * - d->page_alloc_lock: protects accesses to d->{tot,max,extra}_pages. >>> + * - heap_lock: protects accesses to d->outstanding_pages, total_avail_pages >>> + * and outstanding_claims. >>> */ >>> nrspin_lock(&d->page_alloc_lock); >>> spin_lock(&heap_lock); >> >> ... the comment improvement is of course okay to keep, ... >> >>> @@ -999,7 +976,7 @@ static struct page_info *alloc_heap_pages( >>> { >>> nodeid_t node; >>> unsigned int i, buddy_order, zone, first_dirty; >>> - unsigned long request = 1UL << order; >>> + unsigned int request = 1UL << order; >> >> ... this I'm less certain about (and if it was to be kept, it should also >> become 1U). For one, this bounds check: >> >> if ( (outstanding_claims + request > total_avail_pages) && >> >> ends up still being okay (perhaps except on Arm32, but the wrapping issue >> there is pre-existing, albeit possibly benign due to other constraints), >> but just because outstanding_claims is "long" (and it's unclear to me why >> it isn't "unsigned long"). >> >> And then, what exactly is it that you want the more narrow type for (the >> description says nothing in that regard)? The other relevant uses of the >> variable are >> >> avail[node][zone] -= request; >> total_avail_pages -= request; >> >> where both avail[][] and total_avail_pages are (unsigned) long (again >> unclear to me why for total_avail_pages it's plain long). >> >> Oh, wait, it is ... >> >>> @@ -1071,6 +1050,30 @@ static struct page_info *alloc_heap_pages( >>> total_avail_pages -= request; >>> ASSERT(total_avail_pages >= 0); >>> >>> + if ( d && d->outstanding_pages && !(memflags & MEMF_no_refcount) ) >>> + { >>> + /* >>> + * Adjust claims in the same locked region where total_avail_pages is >>> + * adjusted, not doing so would lead to a window where the amount of >>> + * free memory (avail - claimed) would be incorrect. >>> + * >>> + * Note that by adjusting the claimed amount here it's possible for >>> + * pages to fail to be assigned to the claiming domain while already >>> + * having been subtracted from d->outstanding_pages. Such claimed >>> + * amount is then lost, as the pages that fail to be assigned to the >>> + * domain are freed without replenishing the claim. This is fine given >>> + * claims are only to be used during physmap population as part of >>> + * domain build, and any failure in assign_pages() there will result in >>> + * the domain being destroyed before creation is finished. Losing part >>> + * of the claim makes no difference. >>> + */ >>> + unsigned int outstanding = min(d->outstanding_pages, request); >> >> ... the desire to avoid use of min_t() here which wants "request" to be >> "unsigned int". At some point we'll want to change the struct domain fields >> to unsigned long anyway, at which point the above would need adjustment. It's >> well possible that such an adjustment would end up being to then use min_t(). >> Imo we'd be better off using e.g. >> >> unsigned int outstanding = min(d->outstanding_pages + 0UL, request); >> >> or even >> >> typeof(d->outstanding_pages) outstanding = >> min(d->outstanding_pages + 0UL, request); >> >> right away. In the latter case the decl wouldn't even need touching when the >> struct domain fields are promoted. > > My preference would be: > > unsigned long outstanding = min(d->outstanding_pages + 0UL, request); > > If that's fine with you. It is. >>> + BUG_ON(outstanding > d->outstanding_pages); >> >> Unlike in v1, where the min() was different, this is now dead code. > > Oh, I need to adjust this so it's outstanding > outstanding_claims > instead. And then: Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 08 09:21:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 09:21:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197441.1514975 (Exim 4.92) (envelope-from ) id 1vdmDM-0003e0-NM; Thu, 08 Jan 2026 09:21:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197441.1514975; Thu, 08 Jan 2026 09: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 1vdmDM-0003dt-KE; Thu, 08 Jan 2026 09:21:56 +0000 Received: by outflank-mailman (input) for mailman id 1197441; Thu, 08 Jan 2026 09:21: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 1vdmDL-0003dn-7S for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 09:21:55 +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 763a7225-ec73-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 10:21:49 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by CO1PR03MB5858.namprd03.prod.outlook.com (2603:10b6:303:9d::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.3; Thu, 8 Jan 2026 09:21:46 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.003; Thu, 8 Jan 2026 09:21: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: 763a7225-ec73-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=N+MmWtL5YZRMMI1333ScJR9d4UVEoBHDekAVFbn89PJNuPUtEGabFAuyWw79bKJjt+/8WkrqrW7RwdSAo1Wmn1vliHkFeIKzaHHVTQ86QjEWOkBMwTxBHnU827lGa9TBgcVtTKENHksW9c6w44eHP3dP26pTaz2otafWqmT75ImpDO32hCDE1vMbJX3Eg4p5F62d4LlpMvwlSVHSqCc65yuRs/+KpkzXdF7z439b/RIhvPsbtlp3N38HBHqcaEe+5dsQ8ostJPkcn+mYqKotdBiF3RKFZDqnp4S+35k58Sgrrfw5V/yL9D8Qu13JT4rDE1GZnfmYXlzrCM+3TCC9MQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Xot/PO7ac8jnlj2KiLt++h4zu6zxYXwglI6jnJiWen8=; b=PtXSkM/PxpkcsvmHShRNqYV7ySb7yomGVZXFqZc1NfL4WH+k1VZchlACbaPAfX8UJamm9TEtjVc+wFxVidhNqxhG53LOKeSNYaRoI/aYIuvEMbrBpABQu7O+UmDU72DidhZ2AZhjQlw8oRaL6urs0MGcyckf5gW2rLU54uN0V0KP9rHAviCzQ3PB73WfIsPQo4/OM9ih+Nz70XU3R+YSxqyGgQ2rpQhlOJGGSdYZ4WHzlIU3+okvOhQpTP5mMCnAAFtyGkMyYYWSKeW3i5H05F0aoGzIx9U6sbaHnlsc419QUCiYbS6XAP7xYQq2yWlN7J5X1BU6FHQ1IODjKHCKig== 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=Xot/PO7ac8jnlj2KiLt++h4zu6zxYXwglI6jnJiWen8=; b=BNv/yWcRigw3ds9y2ddzYlqLNW2JYgIOO6xqxA8Q1vFwn45Wl8YNOEQlrx5KlidTAKfhAi/mZbQktVUmpAT3IHkPsbvqU3Y2Lw074QKuQ/cLPvfR2e/DPD00jojonu5cwSvxKMYNgVhNzSTFxsJepOYMzzZ1+/ltB4IDI0vLBaM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 8 Jan 2026 10:21:43 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH] x86/PVH: mark pvh_setup_mmcfg() __init Message-ID: References: <6b0fc1a8-fdee-40dd-b3c6-262c33607715@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6b0fc1a8-fdee-40dd-b3c6-262c33607715@suse.com> X-ClientProxiedBy: MA3P292CA0073.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:49::13) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|CO1PR03MB5858:EE_ X-MS-Office365-Filtering-Correlation-Id: adcf0ba2-08c9-48d8-ec5b-08de4e975859 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?TWNXaUZ4NHRJUVJiRm1ZQTc4V2psOStjTmllMkNCV3VsbXVBb2MwZy9FM0tE?= =?utf-8?B?RVM5UGd5Sm1YNVQrUFdVdy9tbEl2aDk1THZQZ3ZFT0ttNEhEOTZjZVNTeVBH?= =?utf-8?B?V3lqajZPdVhhVHJkQk9vQTZOcDE4NEl6N1kwK2k1SU01eC9yWmFHTHRNbkFm?= =?utf-8?B?eFJiR25WeFI3ZEJIYXlneEhLbVR1djEzUk10STFrQ1RsSUI5SWd6dTJLWnRx?= =?utf-8?B?SUJxRFYrMWM5dFc0NXlVdTZSZklnWk1SSlNTdlpsMUpFUkhmUUQ5dFh6dTRu?= =?utf-8?B?L2RmWmN1SUVoOENIWDZLWUdYZ3BVUHBxK3hGalNCOVhjTFNGRjdUSVpTOUUr?= =?utf-8?B?U2dqdHVVU3NEenhoTENHcnh6VXlVbGwyVDRzbjRnZEtMMWxTUTlEcFh2T3lE?= =?utf-8?B?WTBoNE9ValNwbEhoUWVXT2w0Q3ZUUDRSeXlIZFVMUTE3di91S3k3VlpQdzB3?= =?utf-8?B?S1FDeTFmcTBBUzUwUlpMSUNaZFEyWFdKOEh2N0dFcHNIcXBIdWVuWkJHazVh?= =?utf-8?B?Uml3MFAxM0YwOEtYWGdoSTRwTDYrRk9oSk5qWjU4WlJpNnAwQlVTeUN6djBw?= =?utf-8?B?RUhiNDN6M0V5cTdlN0RxS1pLcWtGTUxsZm5uSENPZmljNDNLS2pud1RWVFhT?= =?utf-8?B?aFFTNTIxWEM0QXkzM0J4OThyWUpyd1h6OGdNMHlRYm01bHF2K2xLQnhUVk8x?= =?utf-8?B?Rmc0Wm5ybWh0NkdPSWxTTjUvbmNzL2xkbUwrYVdocEl3RzVzS0FpNUpQaVVN?= =?utf-8?B?OTZyL2ZtcndVdTdNbWF6am80MzV1YlIrYWRiM1o1ZkxUQVJwZi8zazRuU3Fa?= =?utf-8?B?L2lxcEwzMDBIU3JWSDU1Snp1V2JYZDc0M1dmQUh0RHNoczR3SzRmSEhxWXNr?= =?utf-8?B?ZG9pTWtGRDVCNGg0WCtFbHN1ZTd2b1RwNldaVU56dTVpNk9lUDluajlhajJY?= =?utf-8?B?TGJNWU9HVENrWkpiMmFMdUpDSU9ScEJTbTFQSXhUWWJNZElCUEdrU1JNVzAv?= =?utf-8?B?S3F0dVhaZlBERkp4cUY0QXAwWDJjejl5aGNDbitTM2t2cWo5WFl4Y2F2N1JB?= =?utf-8?B?cDkveUpOd1BzcXozUWs2eUplSjJiZVRGcXZzMWFYeG5vWnk2c0xzL3JTWEE2?= =?utf-8?B?T3hRNGJJM0FPN3prWFBTZTJGanE0dWpDem4vWlAyaE5JaUtVdW13TDA5US9v?= =?utf-8?B?SWxibThRbThiWXJoY3NvcWxpRzBSVzBlRHlYaDV4THhHbWtBdld6REp0VjUv?= =?utf-8?B?aUhDdHRhbm1FY3lQL1UxQ2VlY0wrTGhLV3V3YTUzb3R3R0JVaitWTUtWSXh6?= =?utf-8?B?ZW4yeTF5SXJPTlBKcitYVllHTUNBem9aUHNKU2JVUkhzL2dNcjJRcElkUWlm?= =?utf-8?B?VHhneWthUXhtOWJUekhHamFUa1RwQ3Nmc2pSdHlxK0ZhTmRmUlkva01xL1Rs?= =?utf-8?B?VW5FMncrRDB5WDZTSHkyQjJ5T1R3WHF1NmJ3aVFlY2FOK2N4dWZORE1pUTNC?= =?utf-8?B?KzRGb3FBZE93RlM4c0NwWnByQUdCcGlGUVFlL0RoaG9Ka2FDZE9JRGxhTnMy?= =?utf-8?B?QnRzT0ZhbmgybTFkTkhJUjNFbVhXZ1dseVdTRWpHaVBSWHpsaURYaFZiRWZP?= =?utf-8?B?d3ZFbWRUeFVxalRLZjNqWUFwVjg0dkZoNmh5WUd1MlRqRTFCU2IxN0hYZFJ4?= =?utf-8?B?SjltSFRlSGwrZW1TRzk2Q1NJcFAxNkQ0UVlRVVdEL1NTOExLMHA2SnhYeHhi?= =?utf-8?B?T0M1TnNwMFlrNkttQ2lLeXIycjloUExLQml5V3pnZjBuTkgvWEt5Q2pURDVn?= =?utf-8?B?eWJtODFpT2g2WW9KTWg4eDlrRUE0MG44TWtBUzMwc1Rqb3c0d05BU3ZSMTNy?= =?utf-8?B?YW8rRFFtTytnakNxczF3dUZCY0dTUkx6djBMU0ZzZCtGSTNyMTZWb0c0d0Zx?= =?utf-8?Q?OzLenVTjpxYRTvHTsfFZwOaX8RNbGEYS?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bjlIMVg3RGx6M1R6ZzlibmR3a1dnMjRVZWFIWW5abmp6KzdWVThsZVVqbVdj?= =?utf-8?B?QUx2ZjZYc25nYkRVQ0prblowTWhIcHZrcWNTSnlGK0NQbmx3QW1CV2V6ekdq?= =?utf-8?B?a0dYS3RJV1FjUXFDdEhINXRxbVpPUUtnRGs3WW9lRXRURHhJTTZ2V1FCbXVR?= =?utf-8?B?Q0JXY1Z1N2VsZHF1ZldqaEg3RVdzTTR3M0oxdndnWTN3aUIrc1hWV3RMV3I2?= =?utf-8?B?eDBucHlNbHd0aWNHajdVU1RmOHlMTEpoNmFGVWdGaG1XaUhVMFpuQ1RhRGxn?= =?utf-8?B?aFNOTitHeW9pSmxLbU1weUlTcWVkVmwrMVFqOVFRRkpMRjFkZGNCRUtlc0Uw?= =?utf-8?B?eWJYeTBzUEF6VVdCSUl1a2VBN21JZnc1eE40SUNTeG1td2JjQVpqM1JIYTRG?= =?utf-8?B?ZEUrL0x2a0tmcXczc0RsaElMRlJvMGRSZ1UvelRuYW1MRVkrbHV2M2NXY1I5?= =?utf-8?B?MitzQmxyRzJaYkJ0c3kwMnBLVC9ud2JqYkZKUjVxWnVBM0NwNjVwK0VPUkVH?= =?utf-8?B?YXpvVTZjdFdTQ2pJMHk1d1pWa3lSeVMzcGxBVTdQdjVtMXBlOEJMaEZya1dq?= =?utf-8?B?Yk5KT1ZWVG5UdUVUc0tvM3NQVXRDM1Z3TnRRdDVPVjNZRUlMNVhhUDc1UU5S?= =?utf-8?B?QUVsTng5WmVPbHMvS3pEcEl1SkFFdXBYRHB3QzhqSHdzNkFtYlh4bHBpemo0?= =?utf-8?B?a0kvczE1Z0oyNytzVlMrM0tyUXBNbzV5bzNlbnpnMURhWE5hNHVmZkllTnBx?= =?utf-8?B?VjZxT0ZWc3FFK3pzZFJIbmoyZnlTMzEwZmJwWVFyNnB5ckYxd09IMnV1WEV1?= =?utf-8?B?ekNRN3hZcDFva1JVS1lINXU0WjF3VytNa0phR3RRL3JLRnZkd2F4Q3FHWDBF?= =?utf-8?B?TWNOTVliWUM3dkYzOEhsdHVHYjBqc2ptMVRJbFRVOHF1NDRUWHF5NEdJM0c4?= =?utf-8?B?dm5NVE8zWnBrZGhmQXVWU0dZLzFWVXc5Vm9HUnJEMDQ4MDhyTFlPTGVBb0l5?= =?utf-8?B?bjBBaFVVak16RzkwYnhlaEFWUitVM2l5UndzWHVBTEJnQ24xYkRFTUwveWRR?= =?utf-8?B?c25QVFVOWlg5ZGFRT0tJYWo5aW9DNUQ2eVRCUCt1cTBJUXR6Rk0rQ204Wks5?= =?utf-8?B?cVhjc1hKK25BS0lML1hyNEVzRVJSY0pQTUpzcDVvRzNtbXVXK3dQMEszdDhI?= =?utf-8?B?WllzR29lV0xPaDhQNTBGOCtXancwcDhQSVdXRVBwWEVrOGw2eXhuK3lJbkZ4?= =?utf-8?B?WVdQN0Y3TTVBUDRzcERMdGt1Zzk0S2JJTlFzbzNmdHZQclh1ZFpwU1JxYTdo?= =?utf-8?B?ZERHWWVmeEltUStZdFY4MDJCQXZ6aDRRMytYTjZ1M2U5S3pBUlFZS2tvVlBL?= =?utf-8?B?L3F0WXNMNUlpY1NXV3EzbDFWU3NRVXlFOXpxb2M2QSswWWJ3MTIycmZyd2RT?= =?utf-8?B?dStiT1JzbnIzR2pqU0dMNFZodW1KVzRXN0xqSW52Z3k0ZENjVkdpK2s5UlM5?= =?utf-8?B?Z0dQS0hwVnc3SEZoTHZoUXdieEhGTnppRUltekVuUTAzSTlNMlVzajlSM2F0?= =?utf-8?B?NkU2OGhLUkw0aWhic1JIMXVGNEZkeDE2RDErWHR6bGhXTFBVMmZUdktZSnFN?= =?utf-8?B?ekk1UmxvZjFPWTIxT2ZnUHdkWVF4Q3BndGZ5bXBFaXcwSkl6WEIxWCtSVlhD?= =?utf-8?B?clk1eUdMaDJIOXg0czkwRU9iOTJTcEt1NG9TWXJmUXd3VThoS1BKUU9jTWhz?= =?utf-8?B?ZDc5RklGYVZOd0hYQ2xjZjRWZitwUEhlTFFha3h1MERxd1c5djFRc1JxdGtS?= =?utf-8?B?SStVdEh1eEZBcU9nbUdQYTd3SU1GbVlPZFgya1cwa1dqdmpKNDg1azhMN1Vv?= =?utf-8?B?TUZwaGkyQm5GTWhiVy9HeDJpZndVa1dJRDZNQ1hPeWlTSU5HUlhQOFY3TS9G?= =?utf-8?B?alp4bFJqenUxT3puV1FSRG1aOWV0YzkwYmtvMm9jOC8zbHRiVWFaZ3Z6SDNS?= =?utf-8?B?MHNrcDFZZlRNSFd3aUpGZVZZM2dqa2NzSEpNcWlINjFpaDBUQ1NTWmt1YVFy?= =?utf-8?B?amsxa21kMWpBU0pNNjQrZlZrY0R0K0VOaVNOdUhqTE0xQnRWaU05V2RyN3FW?= =?utf-8?B?bWtEY2gveU1zd0liSnhYU0tmd2VkMFlBS2NGUnRjZmExZjlaODJHT3dqNG1S?= =?utf-8?B?QTVIWnZyL1k4QkJIdDNYTjRtbWdkSVBWV1poMTRBR1FzWkxFaUJRcmx1RnhB?= =?utf-8?B?eGdsVERyTCtmdjZGR3VudU5pR29lbGdZbnJ1cE9ja051TzFTbW56YUE2Y0hL?= =?utf-8?B?MkExUzJBZ2dWaVQrK3IwMUxISDFJQlJ3K3UwVUxlaDFvQ2ZtVkthZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: adcf0ba2-08c9-48d8-ec5b-08de4e975859 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2026 09:21:46.3203 (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: Wj9iXZFw5kFpVbOzoTO0xbBzuFgHw/q5EWGpaIBsZfQ1B5afw54ckmWBP3lhzil0iqZeWhuaVpxvmkuifiAA+Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB5858 On Thu, Jan 08, 2026 at 10:16:55AM +0100, Jan Beulich wrote: > Its sole caller is, and the wrong annotation would cause a build failure > (non-empty .text) if the compiler chose to not inline the function when at > the same time LATE_HWDOM=y. > > Fixes: be52cb139f57a ("x86/mmcfg: add handlers for the PVH Dom0 MMCFG areas") > Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monné That was my oversight, sorry. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 08 09:27:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 09:27:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197458.1514984 (Exim 4.92) (envelope-from ) id 1vdmI8-0004I9-AU; Thu, 08 Jan 2026 09:26:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197458.1514984; Thu, 08 Jan 2026 09:26: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 1vdmI8-0004I2-7h; Thu, 08 Jan 2026 09:26:52 +0000 Received: by outflank-mailman (input) for mailman id 1197458; Thu, 08 Jan 2026 09:26: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 1vdmI7-0004Hw-Dv for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 09:26:51 +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 289fe4f8-ec74-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 10:26:49 +0100 (CET) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-4308d81fdf6so1484441f8f.2 for ; Thu, 08 Jan 2026 01:26:49 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ee243sm15073026f8f.31.2026.01.08.01.26.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jan 2026 01:26:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 289fe4f8-ec74-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767864408; x=1768469208; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=P4mLTwPjaI3XoEOIJqOL2BPzieIXonwB7fI7oLVG0PQ=; b=WBwuVkv7+Z1QynkrcW9amzzASenUObagICH/Gr6Preqg6cMv/Ho+eHzarMviMU5zvE xQyF7AlwlAdGnBelpGui0mYtxRXURTZKFOY3G2hyIJU0qmvSP4b5hvZkK+W++KUHqy1P eh5MHiViqsyYg6n3BPzztUZpZYUaggVSqChGTCm6jnZN5IByFaKTBe+zypPBZV7FK5Ga 2VUF0g/7z+QSsBmEC+zD4aGfBzNHkEwhAY94Ro1/S1FRqYx0r4vn+rMZAOcT9OhI/8j0 5R9XxY56Z3Ye2UgXY5WHHv3zUO2TA0KrdO2rNPKs6r6q7XcmlRT3r8eRgtpJL/AFnAPp ymTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767864408; x=1768469208; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=P4mLTwPjaI3XoEOIJqOL2BPzieIXonwB7fI7oLVG0PQ=; b=NgCLnYOezFJ0E9wPIIZygPLbO3XhBbNEGQ29RNrpK9vMYvkUvhUKv7wvbSG5yCjWCk 9wRqot4okzdaoxouBXouezK57YOR8hqgNMgh0RE1IJNcIJYjsB78uyH12n7rvRk5W93O Z4OapIShZWmVVzESkcWPP8i+HJ5NVTskVf79IwE7qIQXxahxV4JvocCDnWi2izwdx9LI 8I946tJxvh32SPIxMK+lW8RZxysWBYA4wjEo1dos6cnAqwfg1EDodYqYXWbKMTfCZ0k5 KPp0u+zpAusl7Y4NLHsxlf6FzkdI8bpZiwYtY98TuOMb7UpWcYXew/XZZXOnaMQ94RoD YZQw== X-Forwarded-Encrypted: i=1; AJvYcCUNI71CMon8QD58jRrTm+xalDfSHnC7/i+L0by5mKMMrob0FHHkGy5zBLYjBI4UMcWJjDmghMWffS8=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy543YLOz/3z0hAsjkbDvk69Ir2Ldtfmb4FlzG951DDcXILzJG9 SVyXV7XwZKIEysnsdF8pi8/Zq2jTx/Fj81/oBPHOZC9IIJpMKkF7F7j5PXht6hDeTA== X-Gm-Gg: AY/fxX6NkWXJ/+znfagfhq7wOiMyKkqXcvAVNWHRLqQ8lAOSEdNVFzHpkxm4YFoiPBp CAC+FptJfFx7tGzAPCtzgE0hUD+v3/GFUhuXMoAOKuagztV51tdzzybav2aoo+DnbUWs6h/kdIs 8mdcFOqFcIe6QFTggFMcDT+ayS7Xwnya7ex6fVoKMcb+YRYk5QQd00WLYpvtMUyIdGhMIt4EMms BWFFUTSdeviXxjjIDB6u2ggktYZjj3S2hDoqDP4W8jLHLjxXpfE4uOeTIvQQEGWWoMGsI5ugEgC pcCL0aqGGUtq6Vy7hctZxQVBAi0rwQFPcGX3dyPP9CJuAqm3LEw4anK3+aEjUINXEJ2W5MhO/dJ 3T8Nf1jzbaci9EWHncqJ40SB48dRcaM/TAFYqqbQ5Smw2SOdWfZJc+GI0ejRxIRrkRH/iSlQhXR 1SCr5ukq7/UmWEBOd2sm8u1U6hFH0THPb5K2pZ9AJPfD7FSGoz0IYd4Uq/uJN+WMViGEVLI1WB1 ZY= X-Google-Smtp-Source: AGHT+IGO3cFPPjYO0Ia2S7IQeLgWQ3I0x0/1+ldcswyragmRFM7VYampwewqbEGz9zckn2kBwmPKsA== X-Received: by 2002:a05:6000:2f87:b0:432:857d:e425 with SMTP id ffacd0b85a97d-432c374fcfbmr6128021f8f.30.1767864408562; Thu, 08 Jan 2026 01:26:48 -0800 (PST) Message-ID: Date: Thu, 8 Jan 2026 10:26:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/hvm: be more strict with XENMAPSPACE_gmfn source types To: Roger Pau Monne Cc: Andrew Cooper , xen-devel@lists.xenproject.org References: <20260107203259.59369-1-roger.pau@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260107203259.59369-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 07.01.2026 21:32, Roger Pau Monne wrote: > XENMAPSPACE_gmfn{_range} allows moving gfn around the guest p2m: the mfn > behind the source gfn is zapped from the origin and mapped at the > requested destination gfn. The destination p2m entries are always created > with type p2m_ram_rw. > > With the current checking done in xenmem_add_to_physmap_one() it's possible > to use XENMAPSPACE_gmfn{_range} to change the type of a p2m entry. The > source gfn is only checked to be not shared, and that the underlying page > is owned by the domain. > > Make the source checks more strict, by checking that the source gfn is of > type read/write RAM or logdirty. That prevents the operation from > inadvertently changing the type as part of the move. > > Fixes: 3e50af3d8776 ('New XENMAPSPACE_gmfn parameter for XENMEM_add_to_physmap.') > Signed-off-by: Roger Pau Monné > Reviewed-by: Jan Beulich > --- > Changes since v1: > - Also handle logdirty types. > - Return -ENOMEM on failure to unshare. > --- > xen/arch/x86/mm/p2m.c | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) Since this is now ready to go in, the question of backporting arises. You explicitly wanted the change here to only go in on top of what is now 98fccdf0ac7c ("x86/mm: update log-dirty bitmap when manipulating P2M"). I wouldn't have considered that for backporting, but I guess for these two it can only be both, neither, or said earlier commit shrunk to the minimum required for the change here. Thoughts on which route to take? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 08 09:51:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 09:51:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197477.1514994 (Exim 4.92) (envelope-from ) id 1vdmft-0008UO-5s; Thu, 08 Jan 2026 09:51:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197477.1514994; Thu, 08 Jan 2026 09: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 1vdmft-0008UH-2w; Thu, 08 Jan 2026 09:51:25 +0000 Received: by outflank-mailman (input) for mailman id 1197477; Thu, 08 Jan 2026 09:51:24 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdmfr-0008TV-Vt for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 09:51:23 +0000 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [2a00:1450:4864:20::332]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9673cecd-ec77-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 10:51:21 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-47d3ba3a4deso17185195e9.2 for ; Thu, 08 Jan 2026 01:51:21 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d87018bbbsm37478445e9.1.2026.01.08.01.51.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jan 2026 01:51:21 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9673cecd-ec77-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767865881; x=1768470681; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=aEyUHDBjJ769a3+Sae0aBoPq58a2gfDkOEbDVOQBYxU=; b=Cp13xJTY3twSVMdGqXtFLbD5deNMZzv42WpWaoXaGcsi4iazDzG29gkKKqNFp+t6Zd dD2Opk5aU1/i5+aZ9dAj5xxWwuaaRB7/n6K+bAam/d4gxasfo8J0tmmHtEpdcdm1xtut u1D8Tc8KhBbi0RlLl+M37Fx7Myo5mzvEQsajsrYGdUHe+z8dbUerfrrg5CulYvM3kmU9 OAPdn01VrbBRwysSAXdFKJLXcIbyov7LD10TkeQMcuIov3qQQnimjtwJYhwrDGcisZu0 BPf3uXRt7Ni913ByJ1lhLUkLA/JhIPKpSo9aynl+NPYwkg2+K+FD0F+Xpw6myLn/eIvr qwrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767865881; x=1768470681; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=aEyUHDBjJ769a3+Sae0aBoPq58a2gfDkOEbDVOQBYxU=; b=oFwK9COqRIBvWlFYRhRuWW2avaeXwIhyWm03L4c6LIDqe6wmLpE25xMf8f1o8m4ou3 0RlJX3K0edBq+DvEaN4jjloqlIz++c74POPsUPDggUYGlA3NHNeoH1lz8vy+l1GprPUL EID4QZpwSlz80fXXBFr6aW26y9kwB7rr3AmtzmXzzKrBA9asymkPXrDBAuJdnQCLUG90 SjKrvOR+rm1Uy0H5O+oFrg0X2M5SLXzt0KFon7TOecerOOB9MjLjvd0Ftj+LLti6x0vQ tO27DM0pytByEs6fTvFXZytaaVjD0r0Fc846/1lv3f9A2JtemOU65fn2RdwXwTXnSlWI 3pdA== X-Forwarded-Encrypted: i=1; AJvYcCXPe9GIPKF4X7uqmf9Y3DhIg+20W/yzajzo+fKiUkiBkvZiErBMhdFlOlkV2WicI4QwoGN+3oJTjas=@lists.xenproject.org X-Gm-Message-State: AOJu0YxXY3ky5CI40dKgT0FLRABt5xRM3toSuYX3ci+l1ZUEXfHk71qV h3EKsMY24/fSz7xj0hVBS6f6TqC0s0Nh/6mo2PZkElErqejI6GY+euIyIk37trMg9g== X-Gm-Gg: AY/fxX5WFB9WvuU4UPBkHi9eC1PIkSYYdo8gl/WJrDGzkdqqs96zfN4ULqgpyCvqLej qJAYmvciI80DGgQ01jvHpqGSaddDVqug9cT9WxA010iSJKQ3cGSuK7BnkNoewCRa7nbQH9oflF7 FFchPHNduPblEKRS8FhWCfsuzNz2aDkcVrb/hHhrPsNR9YJCQzJDbpfayE1ZwRXckh+5xruhEyE tiJ0BnLi9BYiGrfq8mRngEkmoD52cnz1jAsDeesRVdxvLe4wNoXIwWtHPD0q40gMjWXpcdB1PiE MjYhu1dQa929ArKhOAYx88Ibb7TPvk8Ifi+ljwj4DEFSRPvL3tyyXEa7371PSZxbsOeASo0f9PE R9U8+EwKVKQjCvPfqqCBIjWhFnaQp3kSntjeGVl2gwsSOCouuY/JKnJ/3VisbgWuYqP2wVzuqr/ G+09yEdVhtxa1gaQknekJVlLKDVreHCOW0YrKQlz/g+fNIgKvP8gpQQPKerjetthGBurL+xwqhy WGK4RDJhTud1g== X-Google-Smtp-Source: AGHT+IHm1VLPAgFv3OFFZvGUIcRYdSkEge78eyWO4EYUWNo+rD7CXgWYH/mDerZ2jOX3Iq6sDF4rnA== X-Received: by 2002:a05:600c:3e8e:b0:459:db7b:988e with SMTP id 5b1f17b1804b1-47d84b1820amr60012385e9.13.1767865881352; Thu, 08 Jan 2026 01:51:21 -0800 (PST) Message-ID: Date: Thu, 8 Jan 2026 10:51:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/2] x86/pci: Improve pci_mmcfg_{read,write} error handling To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <1042a6163ae71527987a853e3c746c8a6633c0ee.1767804090.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: <1042a6163ae71527987a853e3c746c8a6633c0ee.1767804090.git.teddy.astie@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 07.01.2026 17:54, Teddy Astie wrote: > --- a/xen/arch/x86/x86_64/mmconfig_64.c > +++ b/xen/arch/x86/x86_64/mmconfig_64.c > @@ -60,15 +60,15 @@ int pci_mmcfg_read(unsigned int seg, unsigned int bus, > { > char __iomem *addr; > > + *value = -1; > + > /* Why do we have this when nobody checks it. How about a BUG()!? -AK */ While it may be okay to retain this comment right here, the next patch the latest should drop it (and its counterpart below). Question though is whether earlier replies to the cover letter won't result in there not actually appearing any users of the return values, in which case the change here would be meaningless. Hence while in principle I'm okay with it, I won't ack it for the time being. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 08 09:56:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 09:56:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197487.1515005 (Exim 4.92) (envelope-from ) id 1vdmkf-0000fT-Nm; Thu, 08 Jan 2026 09:56:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197487.1515005; Thu, 08 Jan 2026 09:56:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdmkf-0000fM-K7; Thu, 08 Jan 2026 09:56:21 +0000 Received: by outflank-mailman (input) for mailman id 1197487; Thu, 08 Jan 2026 09:56:19 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdmkd-0000fE-TJ for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 09:56:19 +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 46837529-ec78-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 10:56:17 +0100 (CET) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-43246af170aso963144f8f.0 for ; Thu, 08 Jan 2026 01:56:17 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5edd51sm15337048f8f.29.2026.01.08.01.56.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jan 2026 01:56:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 46837529-ec78-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767866177; x=1768470977; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=hqOFAR/5dSs+X6gblmJlD6usFQ5OMVq3F3YVCBe0U44=; b=PdWn4McXcF7JOexjxTVZ7B4O5Ui39E7K8swpE+urFlSRbNg6BOopQR6dVOlXTH/gDs kH/FYDIOZx+F7KBgA2M5LD288Cp/Hfy/T8WrnsjIkTBoaRny9F0cI3k/gbhNFitBtXsu 1K3Q8VwoP4LPK1QQLQHiVUvd9PM1yoll3kfBZZwM4AZxHqn8aBV8CYnW1l01GQSwO3/t 3hwbldaAzNvbczGFQetoY2E5Irj5RCEVY9FMershvKdqiVKfn/vqtCU9LGPW2lnoAArI lzfXGI478fRmKWHxRl3SA6BfKWZwkzYnwAOBlffNM5susdI5Ej49jyCpUn0Sv0w0k/cR WiSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767866177; x=1768470977; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hqOFAR/5dSs+X6gblmJlD6usFQ5OMVq3F3YVCBe0U44=; b=cXITmUt8dmAdZcdRrGfUO3XDnbVpuS9sulOWUs9/6lMrHMPJ13VY9H1AhHqfgFsX9e Hx68JpsPSv6XsbMlMPBpXTFpWSKKhc/UOkhaaSuFjL4bwsRHobhbBRV7IkQZtWefDujl 8PSRupxOol3cKobz2ut0tvlj2ljfERpSEBbpaXRk++sg7KGo3PQmLN9SjbwUGdN6Prh2 htQ1hxNwCze6MAQpemK8UADYZxsSRuNZ5XAcKxeDRo2EpNe0XmqNU+rOZg4bk7c2KyxP cvdRMC2ss1BNgKW1gofbgNHbvXBI6gSMTYgbV90hOhHQtgtNyt/t7WMtLHpxAjh6/QaB msIw== X-Forwarded-Encrypted: i=1; AJvYcCWxitkLTloKKBEZL6z3VPnfkjNPmFNGeMMG1I0Dq348o+uASTrEge7z4CraNXR8VefaQbQu95snByI=@lists.xenproject.org X-Gm-Message-State: AOJu0YxjSpNuhrTkixZO6+ZCpydMQYXuoUf0wcEgX2JImVlXweFjyW9o MpPGdqFEBK5vgEwoZijE5HjWvcybpWEOn0M5/Lg3jIZ2UzkPUBIdK69zkctNwQIhlg== X-Gm-Gg: AY/fxX7hh2Rx/xpFTebnupARtv3s99BNj40UyBvpMLALcuyipKsljX6yuFU2cjSPbB5 rigKSjOkAZ0ZL6RW6PnNPYDilYhCpmi/WAJXVZ8LbcG45ExqRjYprCsFiTnx+hhtluy5dq1ksBL oi/sfF6BCPfyNFwUr4/5K7GCnDtKMeebrRYNVUSjAs0Vk5LBzNI0SdJ3lwFMQro9rDXBdI0Y4av ebltIJ9QTz4l7K8vRvkYuS+3buVmZafFHooHTZJSQ0IvyEwsznzWgO4p4/nuCtIgIWoYaWpISNM NDJR2VzOHsBzqqNotrzfGFZt29BeqsUXqvBfkBjr6hro2yld/+k2sil6HSCAp6LO/9g15cZ66Ze KaeMpzzs9ze4BwNTsqfhhrFgWz0oB3Yq8hcDDFYjRJC6VCryTx2uqWvlC9CdNgnIU41TcwS9TL4 mJh+4JgI13DV+WhovvkMO6M98yIN1/cjfq1V/ABDxBhBRHVw83zG5M88Lu4imbgasb9IBbBqPKj os= X-Google-Smtp-Source: AGHT+IHzmjkKaAO/grGEadXL71Tyj4dev7esVW0hvuQna5AKqnwwcwvLFW0OAvoecmRwC3U0JYLLuA== X-Received: by 2002:a5d:5d87:0:b0:431:de5:93c7 with SMTP id ffacd0b85a97d-432bcf9a0ffmr13486297f8f.2.1767866176745; Thu, 08 Jan 2026 01:56:16 -0800 (PST) Message-ID: Date: Thu, 8 Jan 2026 10:56:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 2/2] x86/pci: Prefer using mmcfg for accessing configuration space To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <27c85c2cded576b3d5253c6e182e24341201c3ea.1767804090.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: <27c85c2cded576b3d5253c6e182e24341201c3ea.1767804090.git.teddy.astie@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 07.01.2026 17:54, Teddy Astie wrote: > Current logic prefer using CFC/CF8 and fallbacks on mmcfg when accessing >> 255 registers or a non-zero segment. Change the logic to always rely (Minor: Many mail programs, like mine, will mistake a > in the first column as being reply quoting.) > on mmcfg unless it is not available to avoid locking on pci_config_lock > if possible. > > Signed-off-by: Teddy Astie > --- > Are there x86 platforms where MMCFG is the only way to access PCI configuration space ? If there were, how would that fact be communicated? > --- a/xen/arch/x86/x86_64/pci.c > +++ b/xen/arch/x86/x86_64/pci.c > @@ -14,62 +14,56 @@ > uint8_t pci_conf_read8(pci_sbdf_t sbdf, unsigned int reg) > { > uint32_t value; > + int ret = pci_mmcfg_read(sbdf.seg, sbdf.bus, sbdf.devfn, reg, 1, &value); Along the lines of what in particular Roger said in reply to the cover letter, I'm unconvinced we want to slow down (even if just minimally) things by unconditionally making this call (and similar ones below). Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 08 09:58:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 09:58:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197500.1515014 (Exim 4.92) (envelope-from ) id 1vdmn5-0001Ko-2R; Thu, 08 Jan 2026 09:58:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197500.1515014; Thu, 08 Jan 2026 09: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 1vdmn4-0001Kh-W3; Thu, 08 Jan 2026 09:58:50 +0000 Received: by outflank-mailman (input) for mailman id 1197500; Thu, 08 Jan 2026 09:58:50 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdmn4-0001KW-I0 for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 09:58:50 +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 a0bd8d67-ec78-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 10:58:48 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-4779cb0a33fso32144125e9.0 for ; Thu, 08 Jan 2026 01:58:48 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0e19bfsm15350612f8f.18.2026.01.08.01.58.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jan 2026 01:58:47 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a0bd8d67-ec78-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767866328; x=1768471128; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=kipGxDhK+7m0yJSSlSzqufQNYHallH725i1cxTFrfOk=; b=bERl+6+RDvTW1t6xwdiv8wcnX3Iz1FsX7ieeN9354ARDk0sKGwwZdU+BlEftc88YLQ cC/B8R9RsHOK4jCWPCwurk/2wV02TKt66KCvpTrkwG1+2SIqcmTWW4M+Y2/y4NdevSdD SN4sSpH2sNpizo8Kk2HxprJEH6ClAqZHS4wnh45IxRqwTLBRwY/b2adx+NJ9/coM7b4D bn5BqU24r0LuQ0lMMRJUmH3YFEFB/BRvfew2BfQvthzZxX6FeeU5EWIMaQxq2UTwGw/K Bnr6zLzHjQTp/v0CC6SKlV7s+KxNP3XYsUtqVuFfsTR5CuA0qskn/qrQho6Nj9cKH54R u/Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767866328; x=1768471128; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=kipGxDhK+7m0yJSSlSzqufQNYHallH725i1cxTFrfOk=; b=cPdU49Qc1DB3O2MBBUpDvenup1yZsGrAyKZVhtKmJYQxcfALaJPEhs9EnusfeYkk3T BTpgpLyFZ9cMqdaOjCqfb/P1Z2u0EnQ8fKC+N4cRgPN+EoTA6utxxbhQmFrTAtorJbnc TZcKJG0Lf/Pw3yZlsylqKkrr7HcX+nMkclAzZ7HYhaY49794iebaIBjBUVOP8wJjdxaQ almVpDre4KtdXdpVlGYQrlYx2y8qgE1g/SdozyX4X5vQrpL136YL6PL5ZWLkWtfQsR5d aa60ZjEtOCP4j9OfHXUPtiNiLY14kITUmbac52dDLKr5OVjOGeIEaiBU0pnKJ2Z+1wIr gA0g== X-Forwarded-Encrypted: i=1; AJvYcCWvh80ryw137m7PfXaSUydeTWVB0zWf0YqQyShgK4UGewxNI36iRf+KxlS8M7jXJXX8x6C8Hv+7yXQ=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxd/2GJgCz+1FYw1IbEt+xX9PV1wyVMWK08Jz6qlCN4plsRC0tZ eNVQ+MDENqGExrFUp1UuBDb4dpNgCDdC5AYjcVNk4RdDgdDro0TJNCSwGr+xRREzyw== X-Gm-Gg: AY/fxX6C+BmOBKDXUOZ3uAmPZ3iAuCnY7RtgAYPBvnx1MUnTeEBRsGctuUV8b9PJxTF JE988i7gyyuolAHO0m43qGub8F9YXMlDZJrpk6QkxUnXjl98OJazK4I9NhS9x6VQG8gtAkyH69y SJAUpjS69+94TWNPtIwr0K8kpmysDmP1RHtQAksPTi867HqGOD3hEVlQ50Cx2g/DFwKukzh4tmN Rbb1zjgI5c2ByacoVakRFsHFa2z/MLS6tmOUa8Pr6ekVRRKCsctpoUBTSKbmYJY55lEHKzHjL6T xp5eY7ShkYBkYCEFALXYmdJivlIz8RzU2OjCEXxp13P5yN08mX36qL8MSPPKRC6dCc99ovA8h7a GJC/iHqih88AmxxVThktNS44odXv7+EZTOiEt4nJHJSdBDW8Oynf9Mtiw1vBjx2vBQjrRDBYEXs KfK+pfmBzt5hrk6iDjcbZ5pVGcwXWiCq+ZkbfPfM2IkiX9JeuNIJq+s2tHtTS15grDHSDUDtxOy 24= X-Google-Smtp-Source: AGHT+IHn/+51v/BzMLL2SOPkQmk+LUGGpF8jEe7crtpFGfWaIZINsl2wgrzkSiLuGvO7CxJIt48gAg== X-Received: by 2002:a05:600c:c0c7:b0:477:c478:46d7 with SMTP id 5b1f17b1804b1-47d84b33bd7mr62400565e9.22.1767866328107; Thu, 08 Jan 2026 01:58:48 -0800 (PST) Message-ID: Date: Thu, 8 Jan 2026 10:58:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 1/3] xen/riscv: add support of page lookup by GFN To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 07.01.2026 17:32, Oleksii Kurochko wrote: > 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. > - 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. > > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Jan 08 09:59:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 09:59:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197513.1515025 (Exim 4.92) (envelope-from ) id 1vdmnn-0001rm-DV; Thu, 08 Jan 2026 09:59:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197513.1515025; Thu, 08 Jan 2026 09: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 1vdmnn-0001rf-Aq; Thu, 08 Jan 2026 09:59:35 +0000 Received: by outflank-mailman (input) for mailman id 1197513; Thu, 08 Jan 2026 09:59:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdmnm-0001cy-0G for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 09:59:34 +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 bb2fced7-ec78-11f0-b15e-2bf370ae4941; Thu, 08 Jan 2026 10:59:33 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SA1PR03MB7032.namprd03.prod.outlook.com (2603:10b6:806:331::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Thu, 8 Jan 2026 09:59:28 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.003; Thu, 8 Jan 2026 09:59: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: bb2fced7-ec78-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=E3mZRfy9RqWZatSVpjdiLDTx5oTIz4XY3C1QuawO5t+66tdewV8VljIC1e0wovw78cRpehCvg/oQMF1qRtu5pl69y2/okwe56IE569IHkAhNRBcA/XJe5Xu05wEC/7+3IY4VMiFDQGBzHX6NbBnH04BDxAZgnyESBbBY9i9NU1K/Kuz3ZdSNrp6OIRGfg0vmCeuMrgkesCFEPGw/LHtnosWBqOwM2mY+4vGV5BsexBarwkxxGW8j6wWK/nJ2LXNx25ncIL/SMKIPKTe/0UEoZ6VDkVgg7/L8gOhXRPaD/HqM0PP4Bj9Zsjhmi92QczWTxYDv9Fw6ZrzEHLNYMbIhyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ClV0gkNON2xJyWUpmDrS5WYVzPvew+jnbBMKl4qeRug=; b=Uil6xX9kLbmOcAnRqJiSt0/XfYQC3dnCY9QpiDsoWWfyWcKEHQTHq6f0CRuuU1aqSU+lfCCI4HqSq/OhJzzzR0f2MaV8xOJoLdrtHzXZ0lU8KKk1LIBPnSlBJ0KXo6dst/uTz6fv5zzzWPPuQou6ZJa4MNAYkm49yn9f9FqpP36sbS6Db8XamZPXP8V4ospFV57dRg0u1Bg7SsiyuGWaVNwLzTYTHhKlZ+Q2QUClwMQevw8zKisASlUQGfx8w9g25MUEhG2n+NRZraXBdbFpGUsuKTjZ7atv9yyCeRMwhB2suGuBOolGFZDuNV9PXNvyh81lGX7Ia6Kzdm3BPs4/gg== 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=ClV0gkNON2xJyWUpmDrS5WYVzPvew+jnbBMKl4qeRug=; b=An+yGupsLYOuRoXqVE2kTbkYW5TAAouA3cNpKSPgKZtJw8JmdcqX4nNqtovriyju/SDGP32OVuveEukaFlkVjqr4Yhw+arUtCbooxK/2sNUpO1REQqnwfxvo/Okk9zoTEzvjCDYnWbdhA4IAAkFIt+r3TxbDPZjlsJkNgB5aL2I= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 8 Jan 2026 10:59:24 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Andrew Cooper , xen-devel@lists.xenproject.org Subject: Re: [PATCH v2] x86/hvm: be more strict with XENMAPSPACE_gmfn source types Message-ID: References: <20260107203259.59369-1-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: PR1P264CA0078.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:2cc::17) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SA1PR03MB7032:EE_ X-MS-Office365-Filtering-Correlation-Id: 561cb7e8-dd07-4924-9b88-08de4e9c9ca7 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?RFcwNkZJeEVRZTBrelNvM2cwNDdFOTVBRkdkdUt2U3VKdG4xQUdhUTE4YUQ3?= =?utf-8?B?Vkh3UFV4UXpjVmRGQjE0L1U4djAzb2cvdnNnL0dSY08yajRGcGgzQlhEV2ZU?= =?utf-8?B?WlhHNkc0R1poMUl3Y25YbUdnTkpJeXBDL0ozd2tHUWlIMmF0MDVKSHR6NVdx?= =?utf-8?B?aWVSNzV3K0duT295SjVVTGQ0c1RFT1Ezb0JJV1ZoRFNRVHlzVmRrK2gvRkFI?= =?utf-8?B?cUNuTVU2OGR6aWZkYUdTMTFveWFkbUVzZFhNM21KcHJvb1NuY0ZDb010cmlT?= =?utf-8?B?YkJDSWxhcDhmVG81cWVKV3hMM3YvZzluOVA5aWxBRHhGYTdqaWFGNHBJT1VP?= =?utf-8?B?TVRCTTNjSjNRdHNwTDdjZytaSVdtckhMQ1BpRTdXVFhYRzR2L0ROcWUwRkpm?= =?utf-8?B?dDhYRC9hVHdEODlRWE1EK0preHpTYVk3WWRvMlVpT01lcEpoSXU1THZGK1R3?= =?utf-8?B?L002UTlkczBwNEg2d1hGRlpBcXpHd3pMSEFWcHJ0NUNWLy8zU3N5L0l3czhk?= =?utf-8?B?aEpKTS9seERhaUcvSml4ODBTcFNseklsWjYrMzU3QngyUi9ITVFWZEdvQTRE?= =?utf-8?B?anFNVllOUFZLVFBDZzc4djV1M3NzQlJwbS9nVm1RNGpIMVVUcG0yVVlqUTIx?= =?utf-8?B?WS9KV0dCTndVVlBiVy9oQU96b2dEV2ZzeGxQZnBKdDhQcTdnWndBRXhxL1RD?= =?utf-8?B?Ty9vZy9ncXlLU1h1RTBTV0YrUnViL243OTdUQzFPd2QvTGNwUDUyOGhCNkpu?= =?utf-8?B?d3I2cktVSU5oaXRWZjg5QXpxS0RtTUp5SmlNc1M2eXNReFhUVktMSlcyMDZL?= =?utf-8?B?cThsSXdtTHlPMWUvb1luQnhFWUQzbFZHc1c0MWpCblNEc0lEY1ZLM3d5ZXkx?= =?utf-8?B?T1d1S2g1RVQzVFhHaDB1TlhKbUtSM1N5aDFqRXVHS2dUVVpIcU1vT2Vsak50?= =?utf-8?B?OUJRcGVnb3BwZitHWUdEQVZQN2UzcW43T3ZhT1I3T0hDdE1ibmh1RCs0anEx?= =?utf-8?B?MDdUWUVQM0kvQUhYcVZ0WGtndGlacnVROHBCVXdmNzcrazFvNFpoQjA2NnBo?= =?utf-8?B?MzlYVkdUSE4waTJnUWtqTStxQUlsS0ZuUnBJR0VpOUwxNkdQci9vSHgrWnlx?= =?utf-8?B?V0NpR0NXenFCSXdJeVM4WWNEY0FTSHBVMDE1QkhJVENPaTBYeFR3VkVHWmpS?= =?utf-8?B?UkpxMzk1ZXB2N1BGV2N3M1BpbWVJV1VVbjI0Wm1uVFk5U2hCamNDL2t4Q2ZP?= =?utf-8?B?SnZNZlhxd1BuT1BMOWJuZmxHR0lkeGJiYVpuZFNQaXA2OUgycVdlcjRkVG5W?= =?utf-8?B?U083Yk0yY2NYVTBPd0lIWlpZZ2JBczMzZnU1UFBZUDV6VjIwOFI5Wmd0eUEw?= =?utf-8?B?U282ZzVxeU8ydWo1aXppTEp5WnQwdTBCQXozTlg5OFM3K1plbzgrVC8vdHZV?= =?utf-8?B?ODQxUDNYNFlDeUU3ZGlsT3Z1RkVWNVVBaFVwak1mVkU0L0tUb3EzYStvaG80?= =?utf-8?B?Vi9oK2R0dlB6MDRLcGRuYzM4Z0x3UDF2QW56c3NXc1o3eFhOMlZ1UGJqNTdr?= =?utf-8?B?Y2xVcnJhNkRldzRzWW4vWW1FK2JkeXZ1M0FOZmZ3UnMyNmJsQUpNWWF5NnlQ?= =?utf-8?B?V25BTUFJYTcrdStZNnRGc2t6QlQ1bDJsQ1VxMGpxUU9CVWJBWjBNQmxtTVNV?= =?utf-8?B?c3JYTzVmMEdCVEVib0JjUERPcVM2bjArM0lTMkw0TVVDVFRRTUtIUDBuaXZC?= =?utf-8?B?VG1TMitXN3BaSU9HUDBrVVZ4VTk1MVNaMHpOdUtCTCtCaWFkV0VnRjhnTXA4?= =?utf-8?B?RzFKbTRKTzB2cXo2Z2piU2RLT3JPMVJLYlJlRkM5elpobllKRVE3NWJZV09O?= =?utf-8?B?NkUzNFFtZHA1UnljZEx2K0VxcXQzRkhta09qWUllcXNxQ09LeGwybmlkOUV6?= =?utf-8?Q?KTYqzWZ+MhOY9mJLvllyV1x2myfmrlA5?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eGU3eEo4bzZPaUlaOW1xdHBDazBGR3hxaEZmc0Z2MzZscjlQRkpoZDBVU3JX?= =?utf-8?B?OWNpYlRtOHBKUi9pdnVSNkNYUjRPQVVHRFlOTzFwRS9kbm9seUxWcmxGNUlp?= =?utf-8?B?V0JKK1hUamVUaHlRMFJ6T3k0TWtIQXZLdWNNL0R3K213OE5BVkJlYUhRTFY0?= =?utf-8?B?aW9xcW1SY2lZaW5NdVVaY3ZadXlTelNDM090aEorSkdiei9HdUYxU2ducWJh?= =?utf-8?B?VHJhT3haNnFLRTRPcXFUWTRZelRDUXExZE5uNWRlUERyWVp6UStWT2dQVU1K?= =?utf-8?B?VjEzNW4vRkg1RUd6eGpDSWhmQTdERkFWQk14N1l5VWZPTTNLV3hkV25jckpC?= =?utf-8?B?d2lpc01WbG5aNTRUdWNjNmtWeW56M25CV1RucVlDeEx3ZXQvNDB6Z3ZJdDh1?= =?utf-8?B?dDIwVzcwQzQ4QVdpTmljNnRQSk5jZXNUdEhNL3N5S3BXQklWMzlRREc5Ulgx?= =?utf-8?B?dlZLa0ZtVmhHaGNXNnlxclV3N2lBT3ZOc24yenU0TzY3MkJvWVRhVzV2TWU2?= =?utf-8?B?VmY1L1lvUnVwNVhWRWxvcGZ3azlubVN0NCtlQ0xNNVZXcmx1VUptQjV2My9S?= =?utf-8?B?VUNoZHZwSTkzaUU1bWtWMFFxWDAzWEE1cnUwKzI5TXNreWMxdkxybkJMM3ZV?= =?utf-8?B?dW4zQkFSWU1ubWNaMjZncTJpWmRDRHpvS1htdUtDSGNPd2ZHRDlIallLOVVD?= =?utf-8?B?WVFvazVKSU5yUWxDKzJTdXA0SlpzSndTTmVzcll6TUZlRFlNL25RYU1Zc0Z3?= =?utf-8?B?NEEzcEJyWW1STG9OT2sxbExyWW9WUlhhdGxNcXRrR1VkTzYwOE1EbzRWU0xv?= =?utf-8?B?Z3RyMVU1cjhrZ3VlUTR4MDI4M0lKZUV1ZEdaVkdQbUR4QkdtRlEzWk5KWGhk?= =?utf-8?B?NHZUbHo4VnFmN1dxK3hCZHNDQUNKRGZEcy9wT1FIZjZlRllnQXBmcStMcGxG?= =?utf-8?B?MUM2VWtsMGNPYS9vRmozT1BVdjBIbi9IaFRES3JqVEEraC9razBYWEF5V2o2?= =?utf-8?B?UEVnU1gwZElOcUxsSlNhTE14V2pPbGpsbjhVMVB6UE1PYitDSFpFLzVKeTgr?= =?utf-8?B?UFp3YTF3RVN0RkNzKzNJQjNHNUk4LytMTjBrWW9SejNXUERMMVBYZFRFTmNR?= =?utf-8?B?dTQveUYvcm5wblB6Vlh3UGNQNWdXUmJwdERpRlprNGYxL0FWZW5JZlFvM0NR?= =?utf-8?B?UVFoOUU5MUxvcm8yZkFwWm8vYUxyZlNxWndnZFIrd3RNNjRlTDIxOHBOTzFr?= =?utf-8?B?bFNMSnRrSitQZVhXTFZML213SXh6Y3YvVjJwZitTb0lwNm1LRjc4SGdXUXBp?= =?utf-8?B?TGJtbml2alV4Z3NxZ2RtYXpnbEU2S0U2MWYzVFpwTFBNTzg4Q21XOVlhY09q?= =?utf-8?B?QytSV0pXaTVZTERWaGdZZmlTU0JDK2VlSi9YMEV3YzBlc29SaTlZdUtUQjVV?= =?utf-8?B?dWd5SEliQWNtYVlMbXBzblNHYjhGbTdxNWFXNHFlMlllNWVlNlAvdGx3Zlhk?= =?utf-8?B?c1NCUjFNWi93UzFTZTR2ZUVZOHV4dlhoOHl2L0ZNS0pXaWpyWkVEVW9JVnFE?= =?utf-8?B?MUZOcXNVbkxwNkpRWGVJeU9qeWhLVzJWNm4zaGdldzgveEE2S1BOL2M4c1Qy?= =?utf-8?B?dm4rSnNxL1ZzTkY2VjY2WHRoeG0xVGhzS202RWR2U1ZDWnRsZEVjZENPWHlQ?= =?utf-8?B?bEtENEh5VG1PVTQ3QmViNlREa1kzbTF1RmpIZ3VKeXljWTBwN0k0SE52TTU4?= =?utf-8?B?TjZzNnl2RWdUcXNvdUVieGFxTXVOaUlndXJJRnYyT0p3R3p5L01SN3RWakQy?= =?utf-8?B?ZHNuWlhnZnBWOFdaMW9PVWlyQnFPSGl1T3JCRnBUSXNsdUxlTDIwKzhXblpo?= =?utf-8?B?QVdQTmE1T1dTOUxjbzNMeFJhanFWb09sdGhSYW9vTTZrUVZKaS96UnlkalJk?= =?utf-8?B?a1RGQW9xT1ovMnVFWHE4ZVJrbHFoaFVoL0YzQnRWSHVlN2YwRGE3dGJNRnNJ?= =?utf-8?B?enFHVUg4Ym1oMzR1c3FHTElveTRnRHQxaVpMbERtRU96QmwvTlVrY3dWYjdH?= =?utf-8?B?WEtha1Z6WHEvMHFnaERONmJScllkYW1DMWcwM3FXS243ZHp2UjFjMDg3TTRH?= =?utf-8?B?VmpET3ZXc0M3a1FCSmdLSStCK3ZWZExMNXRUVEdzVWo5eHZieldMbUg3Vi9O?= =?utf-8?B?SXl3cUtaVXhFT2hVbFkwek5JeWp5U2V5Y3NocXhZcVZ4eEcyUXdmS0lTTnFy?= =?utf-8?B?S1g0MngwTldiT2dpbVJGcDhvMDU1TXZZQ051cWZXcktrZzdqUnFYQUFoaGlr?= =?utf-8?B?UFI1anpMb1BubDFabWdxZTVlR3NFTy9BU1VWT3FmS1I5b2w0aDNHZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 561cb7e8-dd07-4924-9b88-08de4e9c9ca7 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2026 09:59:28.5195 (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: SxrrihcPDa4Gpq6NuTK+YwnUy8VEaMBg1KoXTajwXGPycWNYvqv4ae6pbFu006v0DksOxFUq5AtOi8k4fyEUFg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR03MB7032 On Thu, Jan 08, 2026 at 10:26:47AM +0100, Jan Beulich wrote: > On 07.01.2026 21:32, Roger Pau Monne wrote: > > XENMAPSPACE_gmfn{_range} allows moving gfn around the guest p2m: the mfn > > behind the source gfn is zapped from the origin and mapped at the > > requested destination gfn. The destination p2m entries are always created > > with type p2m_ram_rw. > > > > With the current checking done in xenmem_add_to_physmap_one() it's possible > > to use XENMAPSPACE_gmfn{_range} to change the type of a p2m entry. The > > source gfn is only checked to be not shared, and that the underlying page > > is owned by the domain. > > > > Make the source checks more strict, by checking that the source gfn is of > > type read/write RAM or logdirty. That prevents the operation from > > inadvertently changing the type as part of the move. > > > > Fixes: 3e50af3d8776 ('New XENMAPSPACE_gmfn parameter for XENMEM_add_to_physmap.') > > Signed-off-by: Roger Pau Monné > > Reviewed-by: Jan Beulich > > --- > > Changes since v1: > > - Also handle logdirty types. > > - Return -ENOMEM on failure to unshare. > > --- > > xen/arch/x86/mm/p2m.c | 12 +++++++++--- > > 1 file changed, 9 insertions(+), 3 deletions(-) > > Since this is now ready to go in, the question of backporting arises. You > explicitly wanted the change here to only go in on top of what is now > 98fccdf0ac7c ("x86/mm: update log-dirty bitmap when manipulating P2M"). I > wouldn't have considered that for backporting, but I guess for these two > it can only be both, neither, or said earlier commit shrunk to the minimum > required for the change here. Thoughts on which route to take? Maybe shrink 98fccdf0ac7c so it only contains the added paging_mark_pfn_dirty() calls (not the clean ones)? That would be enough for the dependency this patch has on 98fccdf0ac7c. I think this would be my preference. Otherwise we could backport just this one, and loose the correct handling of dirty GFN, which TBH is already the case on all releases (that don't contain 98fccdf0ac7c). We won't be making the code strictly worse, but we won't also be fully fixing it. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 08 10:03:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 10:03:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197522.1515035 (Exim 4.92) (envelope-from ) id 1vdmrJ-0003Vb-T4; Thu, 08 Jan 2026 10:03:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197522.1515035; Thu, 08 Jan 2026 10:03:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdmrJ-0003VU-PC; Thu, 08 Jan 2026 10:03:13 +0000 Received: by outflank-mailman (input) for mailman id 1197522; Thu, 08 Jan 2026 10:03: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 1vdmrI-0003VN-7x for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 10:03:12 +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 3c629173-ec79-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 11:03:09 +0100 (CET) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-42fb4eeb482so1621922f8f.0 for ; Thu, 08 Jan 2026 02:03:09 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0dacdcsm15340831f8f.1.2026.01.08.02.03.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jan 2026 02:03:08 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3c629173-ec79-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767866589; x=1768471389; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=UNuYZwH8h1q2oNnu9s/lOsrMvN1+lGYi2F0HOhczA7A=; b=OwQJZO5SU0W0VIQgwBgc20l7jduy/rNYfIUExQgRnhD6d4FYHBKAJPEWd7W2YDs7jv msAjZuSIIBPk5QF1TVzwo7DnzxVjbJtzo+O6ADUoibTT3XNvP+QZ0nyvtyBGk6G3SycK waRJ/H8ezit5Yah1T6sj3zxa9PYFCgbbM4pyAFXvP7uA0TFaTU8OIUjqCkzXCJA8gQRI 9REa4LVwmfhvlDAeQ9R5fQt52Isc997ZM7OUKYVFDe/WR8p0BDsY7XOMeZx7p0s7P4cp 00n6tuRraZefpAnFiRqsSbCmFf+ywKhKZPX0+KqCp9E4RNMt8Iebsat8QUjvFJq9NQVd fgUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767866589; x=1768471389; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=UNuYZwH8h1q2oNnu9s/lOsrMvN1+lGYi2F0HOhczA7A=; b=Q9/cNd3xaBJgmuXkC9xY4enQ21mx2SrjDz5jFmwbtgaYh6S/3z1nCqAWR7li8oVFIv 2MrlYgk0k5FQZxkJxQkWJVIH5HejCiDSvEg7zXK+PLuodLWBHjbhx7PQ3GYkKfuR/cuD NvWBTwZN6yCVAdFlv9DFLRtOvIMLnTPObsvhaVAjrccyz/miWu53hmruYN27JrcUl3NS Oe4WraDlO9QlIyY0waJY5DWv323J+/EjfssuXGn7zFm87Jk7NL9N0wlHkrC0SfBwoMxe wnDAc5n+P1X0Zdz3dz548GNznl/gy468tixbQqUNbcXh4gQ7IWBapIrqvxOR0CTd6Wuy 2JtQ== X-Forwarded-Encrypted: i=1; AJvYcCWB4Mzp2DBvMdgZoEuqfUNZncLUMdQFxOUkQz4s2nm9kZWUDiZzAj2bnzYdUkIp+0bw+3O4duYGGLI=@lists.xenproject.org X-Gm-Message-State: AOJu0Yyvv/GpBEeCJlFADlGGk0RXJTw9GDOYTM2sz26jsOpDfgIgL+XV ur2ml0FD/OrIjOCb+wUThv5VxV57+CG0XVcoK7NW8/lij11W66YTQkp6r0tdvAyCcQ== X-Gm-Gg: AY/fxX7dJ1zm2ZGsHzz5mvLjHVmKG5fF0xoYcXgCppJ1/0U5SxIJ0v1r+Yp1/ErzLUu 10+UdrRY/ScPNrkAuRY22UfoNKbg4MdUpoTrp8lD1fmkDJFOs19ew3qpF1hy0l/pAW+bAFvcD0W 7FefEMsvSurpypmU39GaREDLUqZC2IIWnRRxYY8YiHs8VjFDTyz1osM2T33G1wuXdk/NltV+cQ4 RS3ooUgthvTTvdsjTit6pO49ZpQVz6xorJ2Nh6O8Rxh2VT3wPNRlTOCyHoYVkDv0MlgcZtQQsyw XDmJd1V2J8xtR6LzEYDZ4z8LTMhI+vwn7GPHjXrmYvPPlCYChaMEalOU06yPeAz4CDf/i4eLneX tS6GJckq+VwkgJfZr60fZchwKNDG+tLhXdXfYQiwOHZfQvmjrRA+2/8KUHYpp3ujjwW4sy8Lkxy OoYweGiF4sI45fMVOK1SokAWJv9mEEzqYY8Ubsnw1g9FZJKabUzgad9VpkQ6rXCpGUVajrPM/GU uY= X-Google-Smtp-Source: AGHT+IF19+UlFIfLWMBAwdJbzaux+pSkOxVIZ19BXeVovwd6a9WoQqxCrV5qu8mEAzIJ+Oxe2xjiyQ== X-Received: by 2002:a5d:5f88:0:b0:431:5ac:1ea with SMTP id ffacd0b85a97d-432c375b0d2mr7867102f8f.39.1767866589124; Thu, 08 Jan 2026 02:03:09 -0800 (PST) Message-ID: <8fc2afae-ea14-4221-9fa7-ffb35e34b56c@suse.com> Date: Thu, 8 Jan 2026 11:03:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 2/3] xen/riscv: introduce metadata table to store P2M type To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <6e5008eb873efa97e9e6174165633c50f52294e0.1767803451.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: <6e5008eb873efa97e9e6174165633c50f52294e0.1767803451.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 07.01.2026 17:32, Oleksii Kurochko wrote: > 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 Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Jan 08 10:29:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 10:29:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197544.1515044 (Exim 4.92) (envelope-from ) id 1vdnG6-0006k3-P8; Thu, 08 Jan 2026 10:28:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197544.1515044; Thu, 08 Jan 2026 10:28:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdnG6-0006jw-MP; Thu, 08 Jan 2026 10:28:50 +0000 Received: by outflank-mailman (input) for mailman id 1197544; Thu, 08 Jan 2026 10:28:49 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdnG5-0006ja-L4 for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 10:28:49 +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 d1b55c1b-ec7c-11f0-b15e-2bf370ae4941; Thu, 08 Jan 2026 11:28:48 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-42fb5810d39so1654947f8f.2 for ; Thu, 08 Jan 2026 02:28:48 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0daa84sm15450699f8f.2.2026.01.08.02.28.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jan 2026 02:28:47 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d1b55c1b-ec7c-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767868128; x=1768472928; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=zNup6adGZkuCQuKzXd+xhAU69SGktIrsd4oRrCyU8M8=; b=Zv9OglEcC47QR8ZiixddAmg/TUMg6EcAKM3xpmlWcbErqb/1/WQGDQEy4TOVb+S5P1 Mx+t8H0PzGGeRx/5RiVYp7CnPyw60FwJUuwaBvV7ik6NyvE2xE5pfUfMt+MNUa9ZCTzI QCtud1MT90KjtKhQp6ng3SHtOXsUNdRRpIaMODFCmBZNJ5Pek2BRmNaL1nlHQ0YALh65 tIdYYIi4JJJxNACPYM80PbZFdSzaI+FqUHmaOzHZJIbtedLxnCxVyh1t3a76t7W6L1qK KZqO9j/XPJZaPvtQLQOBtZ33FqOHhx+zCwGapoQLaJHRpX51I+c2hUQD60YQpUiCWBkg YSGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767868128; x=1768472928; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=zNup6adGZkuCQuKzXd+xhAU69SGktIrsd4oRrCyU8M8=; b=i5nDARy5MDdU9NfXkDQmVS0sv2Jy5j+c6FsVCYdU5f1SlJ138FUx2UAbJM6kmueMS7 xW5J8FSKqZUGpe57KPd+zKZQfjXMbrcz4uQNYkh3fqRpVCXMc6M6q22L4o3UWm35oZye CGqP+ts/SY+h0ZSU4DkT7XsJLp+v1HQfhKwxUtsYKqIWPfQtriTja98O0IR4R3o+NtOQ qF4VektkloG8E2Wbk3jbFrKiljhxcaMhRheEG/zyKnRFpe+j22UW3BZvqw38s9QD3O4c pVIoOMNKbLcpfwKaJJfiuX32xmEop/tLKVqLC4CywAgIsGl3jZODDd55ryEwZvzCNgf9 epGA== X-Forwarded-Encrypted: i=1; AJvYcCWYY3pFrPLbC/55Ljb3ptlaCbufYrxE9qpfcVfoGgOFX49h2SUYmETDuPRJamb1R8AAo+VTF4KvtlE=@lists.xenproject.org X-Gm-Message-State: AOJu0YwgY8rrl4suBpSxacdXshmlTO6cP3WCgLj3lVeggSAZ4wpU7ycv FD5yDRFKdPMhCG/QyuZ1WNo0xC0MkVBdZnpEZUEg/2HZw3lHw4U7RigZSP2C+diL0g== X-Gm-Gg: AY/fxX7X0CoyC4bWm/GfUjLgKpLYuKzCylgbFdkh/v1+Omy5gP1SyNlr8s3cxAU8BdR LRRuc0Fry8x/R/f9MCTgmU1WORRoYrrMW0ZiRsJeIRyBKqkOjYX3JnJprFo2shC2BLY2IG1uXD/ GeeaH5yQUPHyxBxQ8wM4PEYBH6N8zPStycaWOzvlLnEcHPKoSzl3ardRzIeFPREMY8AyFuxy1C7 C9muy5tROPEGaidsvh+PisdXKY7iPDX4JkSQZEkkhZG9YCWMm7Iet8VYmnbAiDf7axCI5c6Ok5n vIx4tOmhpnA1xLg6qTxPJoDXHB+0X8O074zQ230+8RBVajgStMYOshZlID50lHxGyLkp0mwXoaW aWDvcz7pSWVTm/hAV2MJLKhX4IyB37KW6BxovnsaLQSfeABAc9IrICuawOG+5Ofzf0Uh8xWopmR YH3CKUOiu7r4ksRlst8Q3gmusA6ckLX+i/H+0c9ND3ABXWPP6dzWVC1IVMLGPApCRgrCq6rkekg bpVYO1+r/jBIQ== X-Google-Smtp-Source: AGHT+IH241JPlrZpjbda0iiIDWOKjPYiM3PYgLFjJAemZquoBsXJDu5G/ikuzNdZyJGl488iPkF3mw== X-Received: by 2002:a05:6000:40df:b0:430:f742:fbc7 with SMTP id ffacd0b85a97d-432c36328c5mr7024918f8f.14.1767868128142; Thu, 08 Jan 2026 02:28:48 -0800 (PST) Message-ID: Date: Thu, 8 Jan 2026 11:28:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 08/15] xen/riscv: introduce vtimer_set_timer() and vtimer_expired() 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: <8cd3efa488b3da2a6751c92d20bbfeb87b3ba39a.1766595589.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: <8cd3efa488b3da2a6751c92d20bbfeb87b3ba39a.1766595589.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 24.12.2025 18:03, Oleksii Kurochko wrote: > --- a/xen/arch/riscv/include/asm/vtimer.h > +++ b/xen/arch/riscv/include/asm/vtimer.h > @@ -22,4 +22,6 @@ void vcpu_timer_destroy(struct vcpu *v); > > int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config); > > +void vtimer_set_timer(struct vtimer *t, const uint64_t ticks); > + > #endif /* ASM__RISCV__VTIMER_H */ > diff --git a/xen/arch/riscv/vtimer.c b/xen/arch/riscv/vtimer.c > index 5ba533690bc2..99a0c5986f1d 100644 > --- a/xen/arch/riscv/vtimer.c > +++ b/xen/arch/riscv/vtimer.c > @@ -1,6 +1,8 @@ > /* SPDX-License-Identifier: GPL-2.0-only */ > > +#include Is this really needed, when ... > #include ... this is already there? > +#include Don't you mean xen/timer.h here? > @@ -15,7 +17,9 @@ int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config) > > static void vtimer_expired(void *data) > { > - panic("%s: TBD\n", __func__); > + struct vtimer *t = data; Pointer-to-const please. > @@ -37,3 +41,27 @@ void vcpu_timer_destroy(struct vcpu *v) > > kill_timer(&v->arch.vtimer.timer); > } > + > +void vtimer_set_timer(struct vtimer *t, const uint64_t ticks) > +{ > + s_time_t expires = ticks_to_ns(ticks - boot_clock_cycles); boot_clock_cycles is known to just Xen. If the guest provided input is an absolute value, how would that work across migration? Doesn't there need to be a guest-specific bias instead? > + vcpu_unset_interrupt(t->v, IRQ_VS_TIMER); > + > + /* > + * According to the RISC-V sbi spec: > + * If the supervisor wishes to clear the timer interrupt without > + * scheduling the next timer event, it can either request a timer > + * interrupt infinitely far into the future (i.e., (uint64_t)-1), > + * or it can instead mask the timer interrupt by clearing sie.STIE CSR > + * bit. > + */ And SBI is the only way to set the expiry value? No CSR access? (Question also concerns the unconditional vcpu_unset_interrupt() above.) > + if ( ticks == ((uint64_t)~0ULL) ) Nit: With the cast you won't need the ULL suffix. > + { > + stop_timer(&t->timer); > + > + return; > + } > + > + set_timer(&t->timer, expires); See the handling of VCPUOP_set_singleshot_timer for what you may want to do if the expiry asked for is (perhaps just very slightly) into the past. There you'll also find a use of migrate_timer(), which you will want to at least consider using here as well. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 08 10:44:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 10:44:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197562.1515055 (Exim 4.92) (envelope-from ) id 1vdnUo-00015b-3L; Thu, 08 Jan 2026 10:44:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197562.1515055; Thu, 08 Jan 2026 10:44:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdnUo-00015U-0d; Thu, 08 Jan 2026 10:44:02 +0000 Received: by outflank-mailman (input) for mailman id 1197562; Thu, 08 Jan 2026 10:44: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 1vdnUn-00015N-3d for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 10:44:01 +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 f0d6089d-ec7e-11f0-b15e-2bf370ae4941; Thu, 08 Jan 2026 11:44:00 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4779adb38d3so21107515e9.2 for ; Thu, 08 Jan 2026 02:44:00 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ee5eesm15738154f8f.34.2026.01.08.02.43.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jan 2026 02:43:59 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f0d6089d-ec7e-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767869039; x=1768473839; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=glUqg2PmYit/j7nTnA+jbcoAtGVuASCfCailxWG4bDM=; b=JuZI8QQIdP8tWDQYqN0bB4S1O4vVyZCsdzGvV6E6U9JbnX45DGXXor/CEFPJcULXKK 94tftM3YzSy2m3W/xsdSAsvpOTydOmHdBPS2VCHz+oA4L4edvVipsvT6QeltSFrqPiph t2j1TrinOebHm4HU+FBVvlCi9pwMkuANSIE6COc+j+nq11hGEw9bkYyqnE28BthZk18S F+I0Yqd7FylvM3QFl+TGAAhNwVS7HuBKMAayq0MmtlkqITM3Ry6IgUx/OGxlrsPaIJ73 41q56HauTlD+fFYavVocoLufURTci6tyu1pNiuhk47C5Q7HH6IN7Xo9y0ciZM+M+kPJy o12w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767869039; x=1768473839; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=glUqg2PmYit/j7nTnA+jbcoAtGVuASCfCailxWG4bDM=; b=LZxj9aMr6l5Ie+FxRoC7QdK4E9vvfEUm85XwmVnekfzb/gbJzJtta+wmdYLCnc7/kI IY+rnrA6Pgz6WhkZYyKVERxqFTcCy+LkSfWbJuy1ZOlSYVvAc7jWZZtaFYUpWdzLLOo9 iOG1RZOlsRctc7hLAGTwyVdE9vISi09mbT/C2HORsmC7coF1yN3+SK8gDj87tzI4AhfO 7eOB7mBYUkiTtVGprvs+kWnA/FtvTu4/ES4DhMUse/fDFWuNI0kIUsddcpMjkN2W/gtW Zj1S2rlZbqNrKD0kEYDzu2IZrTbYDwBa3V8ZujcyvuDh/7jEQPE5vJPjxWcww4rqM+9o 8ekQ== X-Forwarded-Encrypted: i=1; AJvYcCU2ynhKLXpMwERSH/OC3xaBUwp83Td1GLZ1mn1z9rNtLQTDX1sgNHFc1uUIzgbomDje9Vn8rIFxOV8=@lists.xenproject.org X-Gm-Message-State: AOJu0YzLgWuU/hqnk7aqi2GGngVXd5X02yAWxKtUkwADjuR6PClZbdAB 9j0Zmj+D6+KXYkHaaXbklSwlAKTKAqQ3ouvFUPhKBTst8Fmvf591hUXH362/fOBQgg== X-Gm-Gg: AY/fxX7w5JOGM1cWsNkz44LSY0frdtGw/J4QgIj0shCwNJHO7wxunm8fZaJ+NB9uAiI 5U2K8QlC/0xwMWewv7012DbebjtbrgqZgNplOx674uK8myfBZ1+qFmj0ckCzRo676l+0c6R/Imj snqWfXjJ91nFmeThL5MQR4BiVhF8jGKkkdMY1t7aDrAJS87gNX4bRyixeDCc3KWfNWS5w8NgJ+Z NHDhNbVfnfaSwrA7vIP2BbPvJ6tkAEDPtkxt2VlUjZWltt0ovTJJ/n7Ixl4B1KSpVh3EPp5BVCQ S7kj1sRqDumfnF84zc/JIEoYomagELjht9NmWJh9bb9K55khboAHzaOmB0kAbvFYiaJD2FxDHqF a+bhUpVMgJ/dG01dM6gf722yWwzO9YsKHwjunDUsOHxQiRVJhPUwJ4kPp4OjkZsGYk/jqldHeqC 5trD68ByLdq/eIapni9HCKvqOoHdPy5L69z75PDBNvqf9KB+Ja/27Ry//yLLfSg07t3eNqVibL/ jTVJ/UNxnFAXQ== X-Google-Smtp-Source: AGHT+IGWkUdOQZX+Z7u+m7zE2yqYKekS7w/gzfjAVhuUcSIK9GQxBr2HUPba5JI/u+jT8wXDP4c4QQ== X-Received: by 2002:a05:600c:698e:b0:47b:deb9:15fb with SMTP id 5b1f17b1804b1-47d84b52c67mr58563865e9.33.1767869039386; Thu, 08 Jan 2026 02:43:59 -0800 (PST) Message-ID: <9d02934b-d448-4ec0-af0d-b4ee9a918e03@suse.com> Date: Thu, 8 Jan 2026 11:43:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 09/15] xen/riscv: add vtimer_{save,restore}() To: Oleksii Kurochko Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 24.12.2025 18:03, Oleksii Kurochko wrote: > Add implementations of vtimer_save() and vtimer_restore(). And these are going to serve what purpose? Are they for context switch, or for migration / save / restore? In the former case (supported by the naming of the function parameters), I think they want naming differently (to avoid confusion). See how x86 has e.g. ..._ctxt_switch_{from,to}() and then ..._switch_{from,to}() helpers. > At the moment, vrtimer_save() does nothing as SSTC, which provided > virtualization-aware timer, isn't supported yet, so emulated (SBI-based) > timer is used. Is "emulated" really the correct term here? You don't intercept any guest insns, but rather provide a virtual SBI. > vtimer uses internal Xen timer: initialize it on the pcpu the vcpu is > running on, rather than the processor that it's creating the vcpu. This doesn't look to describe anything this patch does. > On vcpu restore migrate (when vtimer_restore() is going to be called) > the vtimer to the pcpu the vcpu is running on. Why "going to be" when you describe what the function does? > --- a/xen/arch/riscv/include/asm/vtimer.h > +++ b/xen/arch/riscv/include/asm/vtimer.h > @@ -24,4 +24,7 @@ int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config); > > void vtimer_set_timer(struct vtimer *t, const uint64_t ticks); > > +void vtimer_save(struct vcpu *v); > +void vtimer_restore(struct vcpu *v); Misra demands that parameter names in declarations match ... > @@ -65,3 +66,17 @@ void vtimer_set_timer(struct vtimer *t, const uint64_t ticks) > > set_timer(&t->timer, expires); > } > + > +void vtimer_save(struct vcpu *p) > +{ > + ASSERT(!is_idle_vcpu(p)); > + > + /* Nothing to do at the moment as SSTC isn't supported now. */ > +} > + > +void vtimer_restore(struct vcpu *n) > +{ > + ASSERT(!is_idle_vcpu(n)); > + > + migrate_timer(&n->arch.vtimer.timer, n->processor); > +} ... the ones in the definitions. No matter that RISC-V isn't scanned by Eclair, yet, I think you want to avoid the need to later fix things up. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 08 10:45:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 10:45:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197572.1515065 (Exim 4.92) (envelope-from ) id 1vdnWS-0001ay-EL; Thu, 08 Jan 2026 10:45:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197572.1515065; Thu, 08 Jan 2026 10: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 1vdnWS-0001ar-At; Thu, 08 Jan 2026 10:45:44 +0000 Received: by outflank-mailman (input) for mailman id 1197572; Thu, 08 Jan 2026 10:45:43 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdnWR-0001al-6r for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 10:45:43 +0000 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [2a00:1450:4864:20::42b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2d11e5dd-ec7f-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 11:45:41 +0100 (CET) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-4327790c4e9so1474572f8f.2 for ; Thu, 08 Jan 2026 02:45:41 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5df9c5sm16065436f8f.22.2026.01.08.02.45.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jan 2026 02:45:40 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2d11e5dd-ec7f-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767869140; x=1768473940; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=2YR8x/rE7hoB8YL8fsqE+c+pcuL3201VtN5Ovg2PFsg=; b=JHdDiEkmsaoR/Ahkv6l0ANdppARVur3HLe8YyrUKUgALooJHvBtrkR3sCb4DbrFIvN h0MhMed7B5tLggtms3WYiP4S/cxqb7fY30MPSG5oixfETrHz6qtOMtxxxr/OHep9cAWT do3T7CHf7Fl3fjHI1qVMNS44BfRwTZ4CkefeKoEy0obgDU5yjN7BipuqTJgZqZScJROW emgQ6N36cYpE5XTOOJLUtMUgvvQZGvDvimk1Q+9ClWslZAPz5pM6HweZ6WNIsTzCWA1E SfZ4ABlNngyszwspWXanJhLsU0V7Gjox/d/Z94GadJj84vGsnSVQ40MDj466r5f6Iicr qFJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767869140; x=1768473940; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2YR8x/rE7hoB8YL8fsqE+c+pcuL3201VtN5Ovg2PFsg=; b=DIXOsN0cX0wRe5vBPCwIgwZOXOuiGdo4jIupeJ1UguewtuSEYBIFQ2xE09uETpMTzx dizsQYFIbJTa68VdGNbXn0t5T+3MImLJyeX2mUq7L1lh7Ov9izy2FVcZSWqz18l5NcAa QsltfZC7tLQ0sN37Jy9q30BnlGIlRguS3grREPwRk+lD0dGoNjPLj2N2X4t+5bKIuob8 Kklmkrss6YRYu/n5cC9dj5A4klpdwihVvDgKNwxXPyG2wFEGq9BiqaNVU7A98XvsUwD5 Ae/TzcTxgJ1rb3p6YFNAaB9V2gRTYrQ+C/8V9UYejWEsVBiAqgTjrF2ySqqkDifVzxlJ Z19A== X-Forwarded-Encrypted: i=1; AJvYcCUJcRM30+PAswLH8IwlkXsK5SZGHCpS5ggFlePGscUmQ8zMO09B1bUkvvsROssRQLGIoo1sS3EFQ9I=@lists.xenproject.org X-Gm-Message-State: AOJu0YxzpVxpiZSBBT6MWK866L1TvW8xbSVrB9oLXag/bb/FGfEes6tl ZjTAa/YZtSzvgzEAXa151UVQyxDrEZ+J06I6vH+/SRf+HVSkRX4yLMo/1qVEw6IXSw== X-Gm-Gg: AY/fxX4WyYWIxB60vKb6MfSYhzHqdZhQq5KeT9dkVgXYlMuTe6hjzq5XocZLn5+k3Aw LjcU3cq4ZFQerdoH1a/H05PNuw/OHTvPalAeXuyfU/SEK2eTe2lg+qXRLtUf0D5KgMMydfcmPDS laawPUhrgsMy+DC4wWYDLMgQ6Sc1oC9EOaGWYEnzqA62VCG7/5V0+bBy9rI8TutiSYR5UHLP5L8 GLdlHthgiYezPGFKgU5O4uX2YiKBHWE+BCWy4GKkKjayiZcVWhmwFMyRVu+yIKcWJqKseyfS6Xx aGsuDmX3cBW1/4YOtGptES4GKXsFmjYfj6zg/WhjpvZxT6Mopwvbrtjl3kGS6WXxqQJW4VMbYn7 RlsAGzWRTNjsSOP003XwGzQan6+hfOs6/I/YoJqKcVzI8AsK3zygaFKP3TKeebkdUrucUOx2J5i rt3HRdkzNGrkoQgn4I3f2zymw1UfgjLCvcI5VSRiCg8Np8eiT+oEHjcRpHzhw9GpX9ER4PPtKj7 JA= X-Google-Smtp-Source: AGHT+IGXXbRPuFmV4F7d14FKGG3UfAiqcP2XHZWmE+zCzyMoEl3mapJpaf1d/5D/gozAVd1VHgoAiQ== X-Received: by 2002:a05:6000:2483:b0:42b:3806:2ba0 with SMTP id ffacd0b85a97d-432c3627fc6mr5557476f8f.2.1767869140500; Thu, 08 Jan 2026 02:45:40 -0800 (PST) Message-ID: <53913b1f-5413-4cb8-9758-9f891a704445@suse.com> Date: Thu, 8 Jan 2026 11:45:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 10/15] xen/riscv: implement SBI legacy SET_TIMER support for guests To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 24.12.2025 18:03, Oleksii Kurochko wrote: > Add handling of the SBI_EXT_0_1_SET_TIMER function ID to the legacy > extension ecall handler. The handler now programs the vCPU’s virtual > timer via vtimer_set_timer() and returns SBI_SUCCESS. > > This enables guests using the legacy SBI timer interface to schedule > timer events correctly. > > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich What about the more modern timer extension, though? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 08 11:45:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 11:45:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197605.1515090 (Exim 4.92) (envelope-from ) id 1vdoS0-0000o0-MD; Thu, 08 Jan 2026 11:45:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197605.1515090; Thu, 08 Jan 2026 11:45:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdoS0-0000nt-IP; Thu, 08 Jan 2026 11:45:12 +0000 Received: by outflank-mailman (input) for mailman id 1197605; Thu, 08 Jan 2026 11:45:11 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdoRy-0000nl-Uo for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 11:45: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 78b8eb26-ec87-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 12:45:05 +0100 (CET) Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20260108114503euoutp02c48034d3cb6d31c0a9b6d5217b172eae~Ivtt7Ahof2079520795euoutp02A for ; Thu, 8 Jan 2026 11:45:03 +0000 (GMT) Received: from eusmtip1.samsung.com (unknown [203.254.199.221]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20260108114503eucas1p1a3e0deb0e605e7382bf16448c83ec6f8~Ivtth0YBR2914529145eucas1p1x; Thu, 8 Jan 2026 11:45:03 +0000 (GMT) Received: from [106.210.134.192] (unknown [106.210.134.192]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20260108114501eusmtip15f0fd6545e69b98729bf484cf7dc88fd~IvtsWADvp1512515125eusmtip1d; Thu, 8 Jan 2026 11:45:01 +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: 78b8eb26-ec87-11f0-9ccf-f158ae23cfc8 DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20260108114503euoutp02c48034d3cb6d31c0a9b6d5217b172eae~Ivtt7Ahof2079520795euoutp02A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1767872703; bh=80K+d4Szn6RvlP9wVPPYJwKN3aMRnNo3dCDMAoay0As=; h=Date:Subject:To:Cc:From:In-Reply-To:References:From; b=J2E4DuaCy6+4FUxry+Tn1XeH87/YA0Nm4UjVkxrph9SmNJ2a1v6zW2o9uouRlYEw2 1c9XdXUQVm5I2ZNtBxe3VoeEt91ceOeW9lZzN5rAjuzl7L+j7KDFSFmuEWTieDulaq ApUx4sYyPm8IAEoAXJLbbAvSh0YdDr+VrE/+/ohI= Message-ID: Date: Thu, 8 Jan 2026 12:45:01 +0100 MIME-Version: 1.0 User-Agent: Betterbird (Windows) Subject: Re: [PATCH v2 5/8] dma-mapping: Support batch mode for dma_direct_sync_sg_for_* To: Robin Murphy , Barry Song <21cnbao@gmail.com> Cc: Leon Romanovsky , catalin.marinas@arm.com, will@kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Ada Couprie Diaz , Ard Biesheuvel , Marc Zyngier , Anshuman Khandual , Ryan Roberts , Suren Baghdasaryan , Tangquan Zheng Content-Language: en-US From: Marek Szyprowski In-Reply-To: <551bb2e3-d7c7-4949-a9bd-ce0cf70e7134@arm.com> Content-Transfer-Encoding: 8bit X-CMS-MailID: 20260108114503eucas1p1a3e0deb0e605e7382bf16448c83ec6f8 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20260107131700eucas1p17e2d8e705c31f81d861d02588380ea16 X-EPHeader: CA X-CMS-RootMailID: 20260107131700eucas1p17e2d8e705c31f81d861d02588380ea16 References: <20251226225254.46197-1-21cnbao@gmail.com> <20251226225254.46197-6-21cnbao@gmail.com> <20251227200933.GO11869@unreal> <20251228145041.GS11869@unreal> <551bb2e3-d7c7-4949-a9bd-ce0cf70e7134@arm.com> On 07.01.2026 14:16, Robin Murphy wrote: > On 2026-01-06 7:47 pm, Barry Song wrote: >> On Wed, Jan 7, 2026 at 8:12 AM Robin Murphy >> wrote: >>> >>> On 2026-01-06 6:41 pm, Barry Song wrote: >>>> On Mon, Dec 29, 2025 at 3:50 AM Leon Romanovsky >>>> wrote: >>>>> >>>>> On Sun, Dec 28, 2025 at 09:52:05AM +1300, Barry Song wrote: >>>>>> On Sun, Dec 28, 2025 at 9:09 AM Leon Romanovsky >>>>>> wrote: >>>>>>> >>>>>>> On Sat, Dec 27, 2025 at 11:52:45AM +1300, Barry Song wrote: >>>>>>>> From: Barry Song >>>>>>>> >>>>>>>> Instead of performing a flush per SG entry, issue all cache >>>>>>>> operations first and then flush once. This ultimately benefits >>>>>>>> __dma_sync_sg_for_cpu() and __dma_sync_sg_for_device(). >>>>>>>> >>>>>>>> Cc: Leon Romanovsky >>>>>>>> Cc: Catalin Marinas >>>>>>>> Cc: Will Deacon >>>>>>>> Cc: Marek Szyprowski >>>>>>>> Cc: Robin Murphy >>>>>>>> Cc: Ada Couprie Diaz >>>>>>>> Cc: Ard Biesheuvel >>>>>>>> Cc: Marc Zyngier >>>>>>>> Cc: Anshuman Khandual >>>>>>>> Cc: Ryan Roberts >>>>>>>> Cc: Suren Baghdasaryan >>>>>>>> Cc: Tangquan Zheng >>>>>>>> Signed-off-by: Barry Song >>>>>>>> --- >>>>>>>>    kernel/dma/direct.c | 14 +++++++------- >>>>>>>>    1 file changed, 7 insertions(+), 7 deletions(-) >>>>>>> >>>>>>> <...> >>>>>>> >>>>>>>> -             if (!dev_is_dma_coherent(dev)) { >>>>>>>> +             if (!dev_is_dma_coherent(dev)) >>>>>>>> arch_sync_dma_for_device(paddr, sg->length, >>>>>>>>                                         dir); >>>>>>>> -                     arch_sync_dma_flush(); >>>>>>>> -             } >>>>>>>>         } >>>>>>>> +     if (!dev_is_dma_coherent(dev)) >>>>>>>> +             arch_sync_dma_flush(); >>>>>>> >>>>>>> This patch should be squashed into the previous one. You introduced >>>>>>> arch_sync_dma_flush() there, and now you are placing it elsewhere. >>>>>> >>>>>> Hi Leon, >>>>>> >>>>>> The previous patch replaces all arch_sync_dma_for_* calls with >>>>>> arch_sync_dma_for_* plus arch_sync_dma_flush(), without any >>>>>> functional change. The subsequent patches then implement the >>>>>> actual batching. I feel this is a better approach for reviewing >>>>>> each change independently. Otherwise, the previous patch would >>>>>> be too large. >>>>> >>>>> Don't worry about it. Your patches are small enough. >>>> >>>> My hardware does not require a bounce buffer, but I am concerned that >>>> this patch may be incorrect for systems that do require one. >>>> >>>> Now it is: >>>> >>>> void dma_direct_sync_sg_for_cpu(struct device *dev, >>>>                   struct scatterlist *sgl, int nents, enum >>>> dma_data_direction dir) >>>> { >>>>           struct scatterlist *sg; >>>>           int i; >>>> >>>>           for_each_sg(sgl, sg, nents, i) { >>>>                   phys_addr_t paddr = dma_to_phys(dev, >>>> sg_dma_address(sg)); >>>> >>>>                   if (!dev_is_dma_coherent(dev)) >>>>                           arch_sync_dma_for_cpu(paddr, sg->length, >>>> dir); >>>> >>>>                   swiotlb_sync_single_for_cpu(dev, paddr, >>>> sg->length, dir); >>>> >>>>                   if (dir == DMA_FROM_DEVICE) >>>>                           arch_dma_mark_clean(paddr, sg->length); >>>>           } >>>> >>>>           if (!dev_is_dma_coherent(dev)) { >>>>                   arch_sync_dma_flush(); >>>>                   arch_sync_dma_for_cpu_all(); >>>>           } >>>> } >>>> >>>> Should we call swiotlb_sync_single_for_cpu() and >>>> arch_dma_mark_clean() after the flush to ensure the CPU sees the >>>> latest data and that the memcpy is correct? I mean: >>> >>> Yes, this and the equivalents in the later patches are broken for all >>> the sync_for_cpu and unmap paths which may end up bouncing (beware some >>> of them get a bit fiddly) - any cache maintenance *must* be completed >>> before calling SWIOTLB. As for mark_clean, IIRC that was an IA-64 >>> thing, >>> and appears to be entirely dead now. >> >> Thanks, Robin. Personally, I would prefer an approach like the one >> below— >> that is, not optimizing the bounce buffer cases, as they are already >> slow >> due to hardware limitations with memcpy, and optimizing them would make >> the code quite messy. >> >> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c >> index 550a1a13148d..a4840f7e8722 100644 >> --- a/kernel/dma/direct.c >> +++ b/kernel/dma/direct.c >> @@ -423,8 +423,11 @@ void dma_direct_sync_sg_for_cpu(struct device *dev, >>          for_each_sg(sgl, sg, nents, i) { >>                  phys_addr_t paddr = dma_to_phys(dev, >> sg_dma_address(sg)); >> >> -               if (!dev_is_dma_coherent(dev)) >> +               if (!dev_is_dma_coherent(dev)) { >>                          arch_sync_dma_for_cpu(paddr, sg->length, dir); >> +                       if (unlikely(dev->dma_io_tlb_mem)) >> +                               arch_sync_dma_flush(); >> +               } >> >>                  swiotlb_sync_single_for_cpu(dev, paddr, sg->length, >> dir); >> >> I’d like to check with you, Leon, and Marek on your views about this. > > That doesn't work, since dma_io_tlb_mem is always initialised if a > SWIOTLB buffer exists at all. Similarly I think the existing > dma_need_sync tracking is also too coarse, as that's also always going > to be true for a non-coherent device. > > Really this flush wants to be after the swiotlb_find_pool() check in > the swiotlb_tbl_unmap_single()/__swiotlb_sync_single_for_cpu() paths, > as that's the only point we know for sure it's definitely needed for > the given address. It would then be rather fiddly to avoid > potentially-redundant flushes for the non-sg cases (and the final > segment of an sg), but as you already mentioned, if it's limited to > cases when we *are* already paying the cost of bouncing anyway, > perhaps one extra DSB isn't *too* bad if it means zero impact to the > non-bouncing paths. I agree with Robin, optimizing the swiotlb path doesn't make much sense. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland From xen-devel-bounces@lists.xenproject.org Thu Jan 08 12:01:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 12:01:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197622.1515100 (Exim 4.92) (envelope-from ) id 1vdohX-0003ds-2x; Thu, 08 Jan 2026 12:01:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197622.1515100; Thu, 08 Jan 2026 12:01:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdohX-0003dl-01; Thu, 08 Jan 2026 12:01:15 +0000 Received: by outflank-mailman (input) for mailman id 1197622; Thu, 08 Jan 2026 12:01:13 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdohV-0003de-4J for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 12:01:13 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vdohU-00Eym4-2W for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 12:01:13 +0000 Received: from mail-vk1-f173.google.com ([209.85.221.173]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vdohU-00Dx91-37 for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 12:01:12 +0000 Received: by mail-vk1-f173.google.com with SMTP id 71dfb90a1353d-563497c549cso1185580e0c.3 for ; Thu, 08 Jan 2026 04:01:12 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" 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=FlhLzpNBstRsxucMILxjs6BP+12x/tGiPqPKf+WmCIc=; b=HW2g075 XPWWqCyNDdGqGW3Nf0g9EiIrL+jG6bCij2QIfXV1eJYOawnkxhyHt7CVRxpzKPH+XbrdA9k0AQmSP yMjaef2LGOO2Qam0i3RMrbzuuvlzWITIxbqXxndoKAy8NkjYSqd5EvvG4eQfh/G0ojBpai52mXABR mueZuOAb0U=; X-Forwarded-Encrypted: i=1; AJvYcCUCFaI+FcyJq8MkVIul/3y9UtvTA5KA2hYNIimwieRx3A4wyt9V7ahhIkPqziZL+mXdx0PECJ/LSD0=@lists.xenproject.org X-Gm-Message-State: AOJu0YzKymeyJUR6d7UwwJHxAIzPriJEMQWVDguFjZXQW1X4UlY0CgC8 C0RVYxY/VllyTCLkDj+q5kq15H7rMiiT6jyYHqiW9BvNx2ZlgttwHKRuk5gUP27IDNo/a0VZRX5 w97Qf39VDORbeDiV8lh/nM27L6Nj8fek= X-Google-Smtp-Source: AGHT+IEM1TKg/HMXA0/cxC/dhQ811GQ9NFtnttIPBoFW5uPVxwVclIXlCHkllLgTlpaNduKhfgJXnTa0XK6FjepdwK0= X-Received: by 2002:a05:6122:17aa:b0:557:cbc5:ce0f with SMTP id 71dfb90a1353d-56347e8ed8amr1856528e0c.8.1767873672102; Thu, 08 Jan 2026 04:01:12 -0800 (PST) MIME-Version: 1.0 From: Cody Zuschlag Date: Thu, 8 Jan 2026 13:00:00 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AQt7F2qvu1M01nXcX-hnp-zEFrCVKsF18n6skVx0Bidaw4CwzNa5rJCu9j4x3A8 Message-ID: Subject: [ANNOUNCE] Xen Spring Meetup details & CFP To: xen-announce@lists.xenprojet.org, xen-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="0000000000003bcb460647df2a73" --0000000000003bcb460647df2a73 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Xen community =F0=9F=91=8B We=E2=80=99re happy to share that the *Xen Spring Meetup 2026* will take pl= ace on *April 2-3, 2026* in *Grenoble, France =F0=9F=87=AB=F0=9F=87=B7, hosted at Univers= it=C3=A9 Grenoble Alpes.* This is a two-day, in-person community event focused on technical exchange, real-world experience, and open discussion across the Xen ecosystem. Whether you=E2=80=99re developing Xen, running it in production or research= , or exploring new areas like embedded, safety-critical, or automotive use cases, we=E2=80=99d love to have you there. *=F0=9F=8E=A4 The Call for Proposals is now open.*We=E2=80=99re looking for= technical, experience-driven talks. This is not a sales or marketing event. What to do now: - =F0=9F=93=85 Save the date and block your calendar - =F0=9F=8E=99=EF=B8=8F Submit a talk - =F0=9F=91=A5 Share this with others in the Xen community who should be= involved Event details and CFP: =F0=9F=91=89 https://xenproject.org/resources/spring-meetup-2026/ More updates coming soon! We=E2=80=99re really looking forward to bringing = the community together in Grenoble next spring =F0=9F=90=BC =F0=9F=A5=90 Cody Zuschlag Xen Project - Community Manager --0000000000003bcb460647df2a73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Xen community =F0=9F=91=8B

We=E2=80=99re happy to share that t= he Xen Spring Meetup 2026 will take place on April 2-3, 2026 = in Grenoble, France =F0=9F=87=AB=F0=9F=87=B7, hosted at Universit=C3=A9 = Grenoble Alpes.

This is a two-day, in-person community event foc= used on technical exchange, real-world experience, and open discussion acro= ss the Xen ecosystem. Whether you=E2=80=99re developing Xen, running it in = production or research, or exploring new areas like embedded, safety-critic= al, or automotive use cases, we=E2=80=99d love to have you there.

=F0=9F=8E=A4 The Call for Proposals is now open.
We=E2=80=99re look= ing for technical, experience-driven talks. This is not a sales or marketin= g event.

What to do now:
  • =F0=9F=93=85 Save the date and b= lock your calendar
  • =F0=9F=8E=99=EF=B8=8F=C2=A0Submit a talk
    • =F0=9F=91=A5 Share this with others in the Xen community who should be inv= olved

Event details and CFP:
=F0=9F=91=89 https://xenproject.org/reso= urces/spring-meetup-2026/

More updates coming soon! We=E2=80=99r= e really looking forward to bringing the community together in Grenoble nex= t spring =F0=9F=90=BC=C2=A0=F0=9F=A5=90

Cody Zuschlag
Xen Project - Commu= nity Manager
--0000000000003bcb460647df2a73-- From xen-devel-bounces@lists.xenproject.org Thu Jan 08 12:19:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 12:19:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197640.1515112 (Exim 4.92) (envelope-from ) id 1vdozN-0005W4-JM; Thu, 08 Jan 2026 12:19:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197640.1515112; Thu, 08 Jan 2026 12: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 1vdozN-0005Vx-GZ; Thu, 08 Jan 2026 12:19:41 +0000 Received: by outflank-mailman (input) for mailman id 1197640; Thu, 08 Jan 2026 12:19: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 1vdozM-0005Vr-BO for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 12:19:40 +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 4c8197a3-ec8c-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 13:19:37 +0100 (CET) Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfout.phl.internal (Postfix) with ESMTP id 90758EC0176; Thu, 8 Jan 2026 07:19:36 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-02.internal (MEProxy); Thu, 08 Jan 2026 07:19:36 -0500 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 8 Jan 2026 07:19:35 -0500 (EST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4c8197a3-ec8c-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1767874776; x=1767961176; bh=ZyBT7EGpn1HgIDscg0sa9ORaZILVZhvzoAc7cA+rbQE=; b= lcmfO8s+/mbpfLRg3FaY/C/FWr1r4juUEcpbfpn3PqghR0vt3DC+ZWxa0Z7Wqelr jgqJvm6NWAQvBxDTLvB49C6qtQzvg0FBgGu45bLFj4jCSGiBhpGiwNXyLWqtKQM1 Y+mgxqApqIzKuTXeG3Z/p6/xXBEnpAth2A/znokPaaNMdpn8Zq9tDaXlrMzwzZjD GL5BO7zL+PyttMeF+pzTE4AwUxiLTpHdaYOW9ldEFY7HKfNGxZzWILf3TRzaVL3X EsY5ExR0LOWypAbgY+zPYsOgPtDyFSyyy+Q7FWBJCtLZYfe99UAb+tGhIyhZaWOV va6dtqO404ZeFRUH7VV0AA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1767874776; x=1767961176; bh=ZyBT7EGpn1HgIDscg0sa9ORaZILVZhvzoAc 7cA+rbQE=; b=eZlugFkanKdJ1/F4ZcTmYxMBvEjQgpNoQ5VHeJfG+Fu0+4HVwN1 bjrSDl8Vd0Z/zg5dDmG5GGXur7HyceZN+BqYLyy2SCtC66hcmG8J3aR5zHQhAhJ9 +OobBdZ8rXzG7yvddeHxxF1sqIk2buPB2lwtbwComPBttW1rt1GDS4/rcEykAP9l QDEcLcpxineGdoi7fTRToQriDP9nLTlPDf6mVPg/5zGJDKJmQIYfGapDAMQ2R9H2 pLAlGYJG4T8to86foBLGDxEIcnPB2h0x/Xo8Qmc6nAUBPPez5sqhy0qGnpqoMCd9 DjiJgtOFQHFVRgvaE5QKVzex+CBGF6JmD0A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddutdehleefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcu ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfduleet feevhfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehi nhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepgedpmh houggvpehsmhhtphhouhhtpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtgho mhdprhgtphhtthhopehjrghnughrhihukhesghhmrghilhdrtghomhdprhgtphhtthhope hmihhlkhihpgifrgihpgeftdeftdeftdesphhrohhtohhnrdhmvgdprhgtphhtthhopeig vghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrgh X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Thu, 8 Jan 2026 13:19:33 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Jason Andryuk , Milky , "xen-devel@lists.xenproject.org" Subject: Re: Cpufreq drivers not working on T480S Message-ID: References: <6f02aca2-eaca-48b8-a2f3-4afff42ad264@suse.com> <1822f42f-9fbe-4de5-bc0b-f6e776b28ed5@suse.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SANc0ADrC06CE80K" Content-Disposition: inline In-Reply-To: <1822f42f-9fbe-4de5-bc0b-f6e776b28ed5@suse.com> --SANc0ADrC06CE80K Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Jan 2026 13:19:33 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Jason Andryuk , Milky , "xen-devel@lists.xenproject.org" Subject: Re: Cpufreq drivers not working on T480S On Thu, Jan 08, 2026 at 08:32:37AM +0100, Jan Beulich wrote: > On 07.01.2026 20:19, Marek Marczykowski-G=C3=B3recki wrote: > > On Tue, Jan 06, 2026 at 09:25:14AM +0100, Jan Beulich wrote: > >> On 06.01.2026 02:03, Jason Andryuk wrote: > >>> no-hwp failed to disable HWP. But if there is no ACPI CPU data, it > >>> wouldn't work either. > >> > >> There isn't any "no-hwp" option that we would recognize, is there? Iir= c HWP > >> isn't enabled by default, so simply not saying "cpufreq=3Dhwp" should = disable > >> the driver? (I already found the original report confusing in this reg= ard, > >> hence why I preferred to not reply so far. I wonder if there are local > >> patches in use.) > >=20 > > Qubes has a patch enabling HWP by default on supported platforms. >=20 > In which case can you please tell the reporter how to properly disable us= e of > the driver? Iirc the to-be-expected "cpufreq=3Dxen" was already tried, wi= th no > effect. Looking at the code, it should be cpufreq=3Dxen,no-hwp (so ",", not ":"). --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --SANc0ADrC06CE80K Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmlfoNUACgkQ24/THMrX 1yxGNAf+O8S4HAC65hcGGKfUqrsah3uN8RNTxi/El0XR8ePgCC+W8c1oyPYdzUKS Meob/upA3yY4XHY/EQmBFq8Z3jDnpbDqG9nsXp6EurodXIj/zuVvJL8JFzONl4Rf ZF9xleZphfgJuk2oFsYOyfZyUnxd0P7qoCncplxb/KevOh9sFIidvGlM3qYKrs/V 5sL3SL4tC3odaGCdeVDbG/QFVc5fRnctofjybGNQR5TBaR9DbOTvSE6QYxnSUr2n 4A4MlNbDtExgIzLq0cjRqo2w9e2e75jXmmxT2F+eBnVDn98v5+tEytXtfLB9nLaO oKMX3ZehlzdTB2HYkv9uf1NMQ9t7pA== =9kVF -----END PGP SIGNATURE----- --SANc0ADrC06CE80K-- From xen-devel-bounces@lists.xenproject.org Thu Jan 08 13:54:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 13:54:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197682.1515157 (Exim 4.92) (envelope-from ) id 1vdqSo-0000el-GO; Thu, 08 Jan 2026 13:54:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197682.1515157; Thu, 08 Jan 2026 13:54: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 1vdqSo-0000ee-DL; Thu, 08 Jan 2026 13:54:10 +0000 Received: by outflank-mailman (input) for mailman id 1197682; Thu, 08 Jan 2026 13:54: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 1vdqSm-0000eY-Ta for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 13:54:09 +0000 Received: from mail137-3.atl71.mandrillapp.com (mail137-3.atl71.mandrillapp.com [198.2.137.3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7f88c3b9-ec99-11f0-b15e-2bf370ae4941; Thu, 08 Jan 2026 14:54:07 +0100 (CET) Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail137-3.atl71.mandrillapp.com (Mailchimp) with ESMTP id 4dn5ws1M0SzBsTph7 for ; Thu, 8 Jan 2026 13:54:05 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id dd8687acf30f42049fe384c5d2cd292a; Thu, 08 Jan 2026 13: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: 7f88c3b9-ec99-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1767880445; x=1768150445; bh=KmZMGZXkEPrMpnkrR8lVjvSw/IC8z1Te/ER/D6CzF5M=; 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=CkjQ6Wac9Fxn1KMRrqKYIzPtA9ie4qsGtNM9BoeVN/8xnnMeXtA+qvn9n/D4naKQb VOIeAv9Xr2KJ5k+Ro7k6jUXUpeJv0SoO4q68YI5PpG5TioIOzsYp0FbmYKaHW+1YV1 Wg7PvV6OZyzUfNS+56Ju4kqtIvok1SsSNgSS7N2nv7DxB5rVtXdACSGedZKXV+5/qq gJt2r0Ahfyc5+1OJS4CDBdh0L6tPcbrWkpQmG96BVEjiG8hQuUxVARcxIPUBD/PYgI Um1egE39O9mbXHEq3T5ehxwAwVm2puz/yHobyM1X0mdOdtYW6+cAKF3YyiYsrAJwJr vt4HSi6iYtVOg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1767880445; x=1768140945; i=teddy.astie@vates.tech; bh=KmZMGZXkEPrMpnkrR8lVjvSw/IC8z1Te/ER/D6CzF5M=; 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=aTYg8jVu/Wa0ZUkt4eHJ4fokwCbf6oS4SBUtQJlaf89eTpAVPm2UKPK3L/GHdlxdi VzDjQh3YGgiSURhNTRcCjBhSFD6qLukMI+PAm/8QC57T2DXCfkFyKlGrKc5eRZHdoA FP3xU1wkauHJ4/pAWTjSn5/EBU6+6rajJ6aaWU1BL6ipwce/ki9MheRXKXgY3vZLqD /xx56NwROrqDTPTPVixALovlpzVBpsD99wH2Qbnfa2Ls/zL9JLEbQD54xmWigoU6mo AjnFCQ1+N9b0xeB+SV4QGvB61uR2H7B1fXXaVv9t9pOGysFlsyWpyimS8GBbHJ6MTA 2neiL77JfgNpw== 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: 1767880443744 Message-Id: <3c6aa6e6-fddc-4b86-925d-078b3c1df765@vates.tech> To: "Anthony PERARD" Cc: xen-devel@lists.xenproject.org, "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" 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.dd8687acf30f42049fe384c5d2cd292a?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260108:md Date: Thu, 08 Jan 2026 13:54:05 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, Le 17/12/2025 =C3=A0 16:26, Anthony PERARD a =C3=A9crit=C2=A0: > On Fri, Aug 29, 2025 at 09:58:16AM +0000, Teddy Astie wrote: >> Currently, hvmloader uses SMBIOS 2.4, however, when using OVMF, the >> SMBIOS is patched to 2.8, which has clarified the UUID format (as GUID). >> >> In Linux, if the SMBIOS version is >=3D 2.6, the GUID format is used, el= se >> (undefined as per SMBIOS spec), big endian is used (used by Xen). Theref= ore, >> you have a endian mismatch causing the UUIDs to mismatch in the guest. >> >> $ cat /sys/hypervisor/uuid >> e865e63f-3d30-4f0b-83e0-8fdfc1e30eb7 >> $ cat /sys/devices/virtual/dmi/id/product_uuid >> 3fe665e8-303d-0b4f-83e0-8fdfc1e30eb7 >> $ cat /sys/devices/virtual/dmi/id/product_serial >> e865e63f-3d30-4f0b-83e0-8fdfc1e30eb7 >> >> This patch updates the SMBIOS version from 2.4 to 2.6 and does the appro= priate >> modifications of the table. This effectively fix this endianness mismatc= h with >> OVMF; while the UUID displayed by Linux is still the same for SeaBIOS. > > Just curious, why change hvmloader to generate an SMBIOS v2.6 table > when OVMF later say it's v2.8 ? Why do we change hvmloader when the > problem is OVMF making change to the table before giving it to the OS? > > As far as I can tell, OVMF doesn't take into account the version of the > SMBIOS table provided by hvmloader and just use the default set at build > time. This can be changed with the PCD > gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosVersion, it's currently set to > v2.8. The main used of the version number by OVMF seems to be to check > the max sizes. > > Before making any changes in hvmloader, we should first fix OvmfXen to > take into account the version of the SMBIOS table that is received. > Otherwise, we just add more tech dept. We might one day want to use a > newer version of SMBIOS, OVMF should be ready by then. > That would be better, but with a small issue. SMBIOS 2.4 doesn't define EFI as a way to query SMBIOS location. That probably doesn't really matter, as the table content of 2.4 still has a meaning in the next SMBIOS specifications; but is still worth noting. > > Now, for the change of SMBIOS version. I think that starting to provide > a v2.6 is a good move, but we should list the correct reason for doing > so. OVMF can mostly stay out of the picture here, and be fix separately. > One main issue we can state is that Linux and Windows interpret the UUID > in the SMBIOS differently, when the version is v2.4. I've booted Windows > with SeaBIOS and read the UUID from the SMBIOS table with > > wmic csproduct get uuid > > and the UUID return is read according to the new definition propose in > SMBIOS v2.6, even if the table is said to be v2.4, so the UUID is > different from the one set by the toolstack. Moving to v2.6 would indeed > fix this discrepancy. > On Windows, only doing the endianness change (expected for v2.6) would fix what Windows reads, as AFAIU it always considers GUID encoding. > > Next, we are going to want a way to fallback to v2.4 when a guest needs > to observe no changes across reboot. `xl` already have > `smbios_firmware=3D` which is passthrough `hvmloader` via xenstore entry > `hvmloader/smbios/{address,length}`, but that interface would allow to > only replace a structure (like replacing the type 1 structure) and > doesn't allow to change the version. (And that would duplicate SMBIOS > table generation between hvmloader and the toolstack, which isn't ideal.) > So, will need some changes to `xl`, `libxl`, and `hvmloader`. > I had in mind the idea of moving the entire SMBIOS table creation to be fully done in the toolstack (to give it full control on this); so hvmloader will no longer have to generate it. The caveats is that it implies moving various things around. > >> Fixes: c683914ef913 ("Add code to generate SMBIOS tables to hvmloader.") >> (SMBIOS versions before 2.6 has a ill-defined UUID definition) > > This space in a commit description is usually reserved for tags and > sometime comment of change made to a patch while > committing/cherry-picking. Comment about a previous commit can be before > these tags, like stating that "commit a1b2c3 made some unhelpful > changes and still have the Fixes:a1b2c3 (...) tag. > >> Signed-off-by: Teddy Astie > > Thanks, > 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 Jan 08 14:17:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 14:17:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197702.1515167 (Exim 4.92) (envelope-from ) id 1vdqpM-0003fH-5h; Thu, 08 Jan 2026 14:17:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197702.1515167; Thu, 08 Jan 2026 14: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 1vdqpM-0003fA-3E; Thu, 08 Jan 2026 14:17:28 +0000 Received: by outflank-mailman (input) for mailman id 1197702; Thu, 08 Jan 2026 14:17:26 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdqpK-0003f4-RL for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 14:17:26 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vdqpJ-00F1Mb-2S; Thu, 08 Jan 2026 14:17: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 1vdqpJ-00E7Wn-2C; Thu, 08 Jan 2026 14:17: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:Message-ID:Date: Subject:Cc:To:From; bh=ImQ7MqxymidSjXlozalBhm+UKgLeulZrSsHGIkWwiuA=; b=BZVD9F PQDS+oGn2sydZ0Fmx5Uz38Lf8SKnwtfLR32u20uL2tOzbpe3Hq5LyjDUJ5Rxq+Rpg+Z5C6HeKftGt cBhg4YRiRtzjIUq4M7aIbctXa5vOCLmz1r9YH0HItakpJC75PAesJQ2lWfWH3tH68nW2M9Zf4zHL8 JPsBdK/GLkQ=; 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 v1] INSTALL: remove unsupported XEN_CONFIG_EXPERT from documentation Date: Thu, 8 Jan 2026 06:16:42 -0800 Message-ID: <20260108141641.506534-2-dmukhin@ford.com> X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Denis Mukhin Amends: 37339ba9ef46 ("automation: Remove XEN_CONFIG_EXPERT leftovers") Signed-off-by: Denis Mukhin --- INSTALL | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/INSTALL b/INSTALL index c2e756bf4b2b..93be8e5b72db 100644 --- a/INSTALL +++ b/INSTALL @@ -33,8 +33,8 @@ small subset of the options. Attempts to change other options will be silently overridden. The only way to find which configuration options are available is to run `make menuconfig' or the like. -You can counter-override this behaviour by setting XEN_CONFIG_EXPERT=y -in your environment. However, doing this is not supported and the +You can counter-override this behaviour by setting CONFIG_EXPERT=y +in your Kconfig file. However, doing this is not supported and the resulting configurations do not receive security support. If you set this variable there is nothing stopping you setting dangerously experimental combinations of features - not even any warnings. -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 08 14:25:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 14:25:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197713.1515177 (Exim 4.92) (envelope-from ) id 1vdqwp-0005Di-Ss; Thu, 08 Jan 2026 14:25:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197713.1515177; Thu, 08 Jan 2026 14:25:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdqwp-0005Db-Q4; Thu, 08 Jan 2026 14:25:11 +0000 Received: by outflank-mailman (input) for mailman id 1197713; Thu, 08 Jan 2026 14:25: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 1vdqwn-0005DV-LK for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 14:25:09 +0000 Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [2a00:1450:4864:20::443]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id cfe93bf6-ec9d-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 15:24:59 +0100 (CET) Received: by mail-wr1-x443.google.com with SMTP id ffacd0b85a97d-430f5ecaa08so1515308f8f.3 for ; Thu, 08 Jan 2026 06:24:59 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5dfa07sm16603437f8f.25.2026.01.08.06.24.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jan 2026 06:24:58 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cfe93bf6-ec9d-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767882298; x=1768487098; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=lxenG25Sep9s1lmghyEt7tktKrVN7RqvjnA7XCs8RFI=; b=epaPugnF/MCjIuiUoJlMTZ+F3OngEy/18TIBMob3wL8Ld/fXPLJZb2MqRRaQw1u/En SQXVZoOKP16j9EMJFcArqLeVNkiFPjdAO5b9QsdRLt6j58NNX6+0iI73AyOp3Gt4zmDQ DsLkmj4nDdhm+kI26iqYZHd41x9J+JwSZ3bBf7BASq75a50XvCjtsJCoYugQSomtM3Ei cBdoKODnkq8FAaNVugz+v9HkCdG9CM1PQYOH9J8uLesiFNuvCRopcKuidxsVrplSuarT n2GXLAqyK25Bm7Ujw4fLSVGaILHRDeYdp7ln245bFXs0a+yuFh0XBbJqkFEiGQcYrKlb W6Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767882298; x=1768487098; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=lxenG25Sep9s1lmghyEt7tktKrVN7RqvjnA7XCs8RFI=; b=xUNT9215dRKDLnDR9syW00KjWHNSNAEtxcQtCs0jRr14LXadu7Rkbk9LOtJg4Npd6O mDE/Z4X+qiMePjDFoTpT7RXqQZhlfWcxekwSDMqUgH14gTsjxU+or9x78w75R6LN5Ipr CJ+uA3YnSncc2FvN+PNNs0PF2lyfUnOM36EmG1uim3XeUSWirBd/ICeDtrZXpVghpU2Z sKmZijBkohS1ZVOSRDgRqPL+dfdMUsTLzDT/dSPzlovRG2QLtBf5tDPk4WI6j8sZX7f4 dR5KTfP6uDw0uzL6hKduTWTEKhYGWrbGlFMwgwl1DlBluZ3opDIxr7wnVK0W9moYDpu7 vJ9g== X-Forwarded-Encrypted: i=1; AJvYcCUb3XqvBjMta9ichv9a+K6NEA4rdGfOpvQhSvCdVAZXRyVXeEsAJzu5xXHYB9/TtnvpoE2J9G3w/Gg=@lists.xenproject.org X-Gm-Message-State: AOJu0YwaYqr8XuUJwz7HhP7a45pCklDnILbRRO2lIOn46cW9l6ZGwhhc ePUvoCn0Uu5apRTFxjfZGEP0N3MpAO7DqrzLssiTBBOHWohHcvZ50OUZ4NurMzeWrA== X-Gm-Gg: AY/fxX5ESGaQIT4RQcvFIPzMHgE+RgkPNmJkBKRrj3C9zC+mHhuc79IaxE/xuq7McsL +WHR7prG2YWlsA5HSbmy8oJm0xl3QJ8928Jhop2MWy8o7OaKiBq6fvUrLhx6sb7eW6ETFC5VCT8 8H1Rndxj5qQtO8NhEriOFtfA9MAQX7a3PYiuk8VFM7uJ+Nqdh1BdnoXP94khLP/XMaIB3BIEkP+ L5zupx85ubwcMMtKxXsr2aq8o58Mb/v7/qySpk1y5g8c9OFrJipAM8eJD71uZa/+0SYI1WIloGW ffQC/l9lSaapDX5aVbnOTuCdsNwH2ishOHdWPf19kb6Uvb0GUcmJ3h7QcEApEItmEIDy1wKCXAa JiQ0pHIgx2EkF46yc2FSUx4YcT8n2y4L/V3mxWmZh9fVUj368vShXyQl4A4oaDN5QNtU/uGMso4 3OoSWnQpz6NkQgxJTHATjryMPTXMTqG8WvIpeTQ+pqGlLGTjOViJaKCo5p7u7TevJG3fnkBY6da 0vU74efGhx3bg== X-Google-Smtp-Source: AGHT+IHjFmfo7XdS72gmM8i6sVdjfl03H1mC/tCRTOJEmgX93SItIop4BQJN3FFHRZddKoVBs+l5fQ== X-Received: by 2002:a05:6000:4301:b0:430:f704:4ef with SMTP id ffacd0b85a97d-432c3776a9cmr7900650f8f.61.1767882298529; Thu, 08 Jan 2026 06:24:58 -0800 (PST) Message-ID: Date: Thu, 8 Jan 2026 15:24:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] INSTALL: remove unsupported XEN_CONFIG_EXPERT from documentation 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: <20260108141641.506534-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: <20260108141641.506534-2-dmukhin@ford.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 08.01.2026 15:16, dmukhin@xen.org wrote: > From: Denis Mukhin > > Amends: 37339ba9ef46 ("automation: Remove XEN_CONFIG_EXPERT leftovers") > Signed-off-by: Denis Mukhin Acked-by: Jan Beulich However, ... > --- a/INSTALL > +++ b/INSTALL > @@ -33,8 +33,8 @@ small subset of the options. Attempts to change other options will be > silently overridden. The only way to find which configuration options > are available is to run `make menuconfig' or the like. ... I don't think what is said up from here is quite right. As a result, ... > -You can counter-override this behaviour by setting XEN_CONFIG_EXPERT=y > -in your environment. However, doing this is not supported and the > +You can counter-override this behaviour by setting CONFIG_EXPERT=y > +in your Kconfig file. However, doing this is not supported and the > resulting configurations do not receive security support. If you set > this variable there is nothing stopping you setting dangerously > experimental combinations of features - not even any warnings. ... some of this is also in need of updating / correcting. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 08 14:27:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 14:27:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197727.1515188 (Exim 4.92) (envelope-from ) id 1vdqzJ-0005uk-DH; Thu, 08 Jan 2026 14:27:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197727.1515188; Thu, 08 Jan 2026 14:27: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 1vdqzJ-0005ud-9e; Thu, 08 Jan 2026 14:27:45 +0000 Received: by outflank-mailman (input) for mailman id 1197727; Thu, 08 Jan 2026 14:27: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 1vdqzI-0005uX-HK for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 14:27:44 +0000 Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [2a00:1450:4864:20::343]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3120c4f7-ec9e-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 15:27:42 +0100 (CET) Received: by mail-wm1-x343.google.com with SMTP id 5b1f17b1804b1-4775ae77516so35991815e9.1 for ; Thu, 08 Jan 2026 06:27:42 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f68f4ddsm161688015e9.2.2026.01.08.06.27.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jan 2026 06:27:41 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3120c4f7-ec9e-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767882462; x=1768487262; 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=YB1v1TRI5JUlHgV8frgde5YCA9T3Lfy2Y22nWp1iYGY=; b=bXhyqNEAvBQoJvb2+74FPo8FSyUavIrh6PH38aYcbF6B2zzW+SNUdu4IaLL4SDzUD0 sXggiPqPPJgb2Myay8U1hAkAgcyhKy+3f2NRFPBX/z3y4aUIDcfx3bHKVfwzCk2Lqrbs DJ8UhN4VqtKYQ83B3vRRkk5Lovl1zEsaDLbCNTN8tq+reaFCG0vdDssdeWLtDQSFwytr dHCMWr0azpmU0NrZoDD01UdgSFGrjjuc3FRX8+PuYZ3VjBMYmjaV3ktMpIybi/ESjRHI tqw6VYthNJKCPW+IVSZqR+zENqhRPRDT5nCB5oCQ9kVlj5ik3neckrDg3EOz7Ov7zFCz tblA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767882462; x=1768487262; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=YB1v1TRI5JUlHgV8frgde5YCA9T3Lfy2Y22nWp1iYGY=; b=EcFKrKnLVpJdpbgbywuaSLVgdOjGSlF9i+SxyiWRYR5tr+80JC+u7gEulGG5rt7pvp QNTqWEYqNwtuQ+PXkH6PcEt7C4opF4TiNYKhph6TWa2zBWh+wTfM4B+4ilnrJuP7t6MQ FXWc/RQ/Ctpl3CtRFP3NEpMKyp8w+DFYxlfrxeT2GeRiHE9FTYnmuh1yC6Cjq46fGI02 11F2O/8FZilVMqC51tFcWRHvInVVpxRj8KFGnWD6BcUwq20WVTgtI0Kk8iRTniScmEMI 5isKdffjL4vATTZ24XBx7TUiTwQSsDBGp8DWfI4ODH24nfqrGrpNsgCn6h6NpiYjdy8V oRFg== X-Forwarded-Encrypted: i=1; AJvYcCWOZLFJfAKJyGJBh/fYcG0Uy6s4LH/NLa+L/y3wd2uaz91JEdWtxSQcQWnX6wwiyZ1KdkT/W7S+oFQ=@lists.xenproject.org X-Gm-Message-State: AOJu0Yyhx1e8zKHPplsINN0RPMv89DhgvP0W7/cmDbf5CsztsU40xdah DHDeLkgi35FrMWsXw8okQ4VLyva6dq32VG7Xq+cL7VKAm78+AGceA85G4wECoTpG6A== X-Gm-Gg: AY/fxX5Xt9XnAjbVwdkydxMZo2IgRbp3otz6y4e0p9Bs6tLcdF9tQKJwUllwBT4oTPy GtDjBATTziliRlLyXM95+3QVmchYi9tdL1O2y7U6TBmzTLNJ8BFfrAZJM2fKkR4inaqpW9wvZNG +TnfhzHFZZNIPh3L/k68ZCgY/gmfBHyVpsuVJmM8AdRNtPNdyJvLd48yyGaH5padtLgX/7TGNbH UTIHqlVjaCfNJ+oQ6CU6c3CB1aJCk9i17TA2zhJCc9U7WvvX5cQJytkrgfHzdZtHm8P+0YpNUdS sf9NaqxlBYsghniqwnLduve0ziz42Sn4h1vID/Bu4/GlNRd1JbhXmS6XItPmAgTbzAE6f9+T2lN qNNUrr5+gMdvGt0WGojaQYkTRcbvWXlFL9O8exyA46x7B1/K9ooObzAU6uMhnKoZFUsBXJiqP++ LNew3wHnb64jA5O9HPQxRuYIzWhf6MrU1dOo70inS+mbR3LtrpMiZ28ehIvfukR6ef0tPtW4Tg9 2TJ73dOrKKVSg== X-Google-Smtp-Source: AGHT+IEBaOeOLFc0zKMxVONp4ibMaZCmKrS8QTqQ+wYcEaucuahaZ6+zj0spOBXR2HU2nUBipZKjeA== X-Received: by 2002:a05:600c:4747:b0:479:2a3c:f31a with SMTP id 5b1f17b1804b1-47d84b0aac6mr80298785e9.1.1767882461687; Thu, 08 Jan 2026 06:27:41 -0800 (PST) Message-ID: <4e14f1c5-bd85-4ac5-a2a3-613f9673252f@suse.com> Date: Thu, 8 Jan 2026 15:27:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] INSTALL: remove unsupported XEN_CONFIG_EXPERT from documentation From: Jan Beulich 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: <20260108141641.506534-2-dmukhin@ford.com> Content-Language: en-US Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 08.01.2026 15:24, Jan Beulich wrote: > On 08.01.2026 15:16, dmukhin@xen.org wrote: >> From: Denis Mukhin >> >> Amends: 37339ba9ef46 ("automation: Remove XEN_CONFIG_EXPERT leftovers") >> Signed-off-by: Denis Mukhin > > Acked-by: Jan Beulich Actually no, I withdraw this. It makes little sense to update ... > However, ... > >> --- a/INSTALL >> +++ b/INSTALL >> @@ -33,8 +33,8 @@ small subset of the options. Attempts to change other options will be >> silently overridden. The only way to find which configuration options >> are available is to run `make menuconfig' or the like. > > ... I don't think what is said up from here is quite right. As a result, ... > >> -You can counter-override this behaviour by setting XEN_CONFIG_EXPERT=y >> -in your environment. However, doing this is not supported and the >> +You can counter-override this behaviour by setting CONFIG_EXPERT=y ... just this reference, when things also work differently now (?). (IOW the original description ... >> +in your Kconfig file. However, doing this is not supported and the >> resulting configurations do not receive security support. If you set >> this variable there is nothing stopping you setting dangerously >> experimental combinations of features - not even any warnings. > > ... some of this is also in need of updating / correcting. ... may or may not have been correct when it was still an env var.) Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 08 14:38:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 14:38:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197743.1515198 (Exim 4.92) (envelope-from ) id 1vdr9I-0007eU-AO; Thu, 08 Jan 2026 14:38:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197743.1515198; Thu, 08 Jan 2026 14:38: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 1vdr9I-0007eN-7j; Thu, 08 Jan 2026 14:38:04 +0000 Received: by outflank-mailman (input) for mailman id 1197743; Thu, 08 Jan 2026 14:38: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 1vdr9G-0007eH-I6 for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 14:38:02 +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 a11082d4-ec9f-11f0-b15e-2bf370ae4941; Thu, 08 Jan 2026 15:38:01 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SA6PR03MB7879.namprd03.prod.outlook.com (2603:10b6:806:431::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.3; Thu, 8 Jan 2026 14:37:57 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.003; Thu, 8 Jan 2026 14: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: a11082d4-ec9f-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ov//o4MfcqhkQhcPOgI4h8Yh3zKq1dAxKKUXF/9JDdMcpunBV0JAoQuU49VFwKuNkkeyEktNvzLGuh73jOTask7qAevDit9Sa2rUbPXcpVKFQWQtlt4jX1TI01KHwQtdbNNteIsKPtdGR2lXRuqxXizKWGVjMufDBZONi5nX4xVVMnUJZwnMCIwkIwYkyLAwA2movQgOeYkgNPGKqMB/9y8zWmDmg4V2LOh92zZ2vVmCA8xG8v/u1RDVi44uJiLc9zpms2vdH5NePXQZvjdMWMMv28aVi/uF0NZQa0clR24/fogmIowEkR4ZBOJUn/r93doIskwJ8Y6nsEnyCQ/8MQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UFxlg3C3/h5QhHvzxIVc31OMINZ3mt91RFw85ov5sAY=; b=NnMokkGfkNRk67wswtOL8nEnLgmvE4KwwlafHtDFqmswuHHzJof+xZdtnhAKhQmscwOq08JVt+aOVK1kBclMr+YiL8Cqvoja89u/erjFPuox3KMR3b+G1RYWm72zrDcmTmh1/wt98t0ztZctFfvE4DBsphHYoq3FTUEBH0bV39OXZRNK0q4dW+oIRuX7DyUD3d1x4sD/9ICswmoNGtV3tEFO6e4FNR7uz1VvlOyqnoMuzWOvk5GTu9y6hod8QzsU5PmnT0pdpLiHQVKysbE5zUfzXJvoWB/gOkW9ymzszFWepMQRv3wdMGH7w1Jc2Wgh/jzwrsIEmLawJHxo5xNusQ== 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=UFxlg3C3/h5QhHvzxIVc31OMINZ3mt91RFw85ov5sAY=; b=Um/mODpiX5vusgBSc2gokWdbS4o7rbrsFld1NHAOclg9R62/6ofHLrgso1hp/0FhjTnRswYBqJToD8jcqibEhvVHHYQeoJab8Yc3R77AzehO3fk9IVphMeW9ihrm2LRfMgOca4bt2qg4Erc/M6KphCbPpmEfFRM/LjFc+y1QOs0= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 8 Jan 2026 15:37:53 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , "committers@xenproject.org" , "community.manager@xenproject.org" Subject: Re: [PATCH][security policy] embargo control and crediting of discoverer Message-ID: References: <93718ef5-bb60-4476-9936-039f11a945ad@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <93718ef5-bb60-4476-9936-039f11a945ad@suse.com> X-ClientProxiedBy: PR3P189CA0028.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:52::33) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SA6PR03MB7879:EE_ X-MS-Office365-Filtering-Correlation-Id: bbcc0759-43a1-4b29-a14c-08de4ec383a9 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?bVRDd2ozUDgxbkgwYm96SmRINlFpWC93RzVuV3h1YjNsQnFPR3ZIMFNUYm5Z?= =?utf-8?B?aXJVaW5aUEI0NS9Wb2ZqbVZHc1RCdWpZVC8rbDZzbUs0c2JiOTlNL1Z0eEFI?= =?utf-8?B?ZHN4OHVlUXRsZmdhWk5ldVdDNE10RDU5TlNxaXJvRlorOWtWN2U5Nytsd3pw?= =?utf-8?B?aUZ2cUJrY0RhaERLZFdER2s4S0hYcEh4aEl4NnBERzlZSUZPZFkxQVlzMWgv?= =?utf-8?B?UXJPUmVkVFBYY1VPc3pEaEZoaTZsTFo4Z3J6ckRtRGZKUEc1KysrQXQ0Q1kr?= =?utf-8?B?clIxaEZtdkE1MDdqcjcvcGpHR2RoTXQvQWMyZzZ0WSt3UXljYmZseXQ1ckNC?= =?utf-8?B?UXJGUHRqTFBZMjNJWWlBMjJSWkx0ZHFtNDRiQUd1MjBRb05RVmwwenh3WjV3?= =?utf-8?B?K2ZXWFdVSVYrUTM4cWxaVHFsTjUxSEE1TUprMUs5eUJ3UEFSMGZlajlKZDEr?= =?utf-8?B?N3pCTU4xbnhOdjlsdlZ2WkYwUE9PcGtsZHZTU0VpdUEvM1g1MTJ0WGFqME9S?= =?utf-8?B?NTgvVmQyMGE3eHQxRjlQK00vNGJESkswK0JUaTBsREt2OSs2TEdvV3FOd1Aw?= =?utf-8?B?RHpoQytsVllyOEJXKzhuVEdlQVo1MytWVXNhYlQyQzlBQ1JvcWZ0N0NZNUNN?= =?utf-8?B?L0ZzZnVMQ25HT0Nkd0tVNmNlQVR0bm1LRFp4VjNJeXZoUkpaeVlnYXpUVVE1?= =?utf-8?B?UlZOR0kvTG02OUh0Q2Y4S1NrbWl6ZGdBQWRpb2trU0lWYkZXd1lzODB1WWRj?= =?utf-8?B?MEF6YlliekU1YjhSSjZ6WkFzNnJJOHRvMnZ3MTRKQXNaM250cFUxZitOdDcx?= =?utf-8?B?M25vdDV6RzJaSFZoS1QxSzYwZkorNW9ORkdLR2pxcUZjR2xvWUJ4RnJOSW1k?= =?utf-8?B?eEU0bU1WdEJMRi9lc2VEbEZ4cUhiTEdHV2dmNGVaTWc1RWZJNG1HSnkzMzJF?= =?utf-8?B?dW5rakFtdUxVbzRjdHlWUVNFY0Y5NWVaWXI0QzhveXRGbkVCUFI5Qjd1bGVO?= =?utf-8?B?ZHpnaExhNVJick9UMXJBMnBxWDdCT1Jpa0xudlg0aUMxaVRrR3pyd1hXTHZk?= =?utf-8?B?amxQamxueExIU2dYWUxrZzA4Ly9DUmRYOE5CbmFPMGQybzJ0ZllONDBoNzlV?= =?utf-8?B?TzNXcnlIZmRqQTBkTXQ2UEtFR0pqcDJCTCtzTFozTUFhNXNDQU5QV1BjSnI0?= =?utf-8?B?N3VtVE5OSjRHWWUyMmVLQzA2em9rcmJKQ2JlSkx1SDNRTWFVZkNkckJKMWZq?= =?utf-8?B?dVl5ZHR0V3VKZGp4eS9KQlViOUlkNHlTcEU0T05taEMrTUs0YnZ4Rmo1Qmw0?= =?utf-8?B?L3BhbWFVRlloZ05XbTZncVVOZ0NFb1NOS09oTm4rMFI5OFZmeXFCSlk3MnR6?= =?utf-8?B?NkZ4TTY3TWZEK2NTSkVzTGkxcTYzZWdXWTdmYk1jWm94S1JUYXRkV2hnay9B?= =?utf-8?B?K2NHV05heEJ0RVVVUzRjcW5zYTdsZzVLdE1FRHl0ejIwQlpBdy9EdUdONXVn?= =?utf-8?B?M3RENHN4T09MOFNmTXdGMnUyOHBlZkJFZGVPV1E3OWRWSWdKZy9HM2t5L0I3?= =?utf-8?B?dHBDRUFCbDRzRVB6TG5VaE9odjlnaEhLOGFpUW1yNFM2ZElRZ0EyaUVMenMy?= =?utf-8?B?d0dHWmIwejNwZy9MTk1rSDVodW1BSkgxSnNtdjBmTnI3VC8wRzJMTFl5TjlC?= =?utf-8?B?SVVma3BoaURDZ0NyaC9uUmtzdHVQNFFPZzVtRlVRVXFiREZmZmhsc1BYYW1K?= =?utf-8?B?azFaMXo1WlhEdmNhc0hmQ2tZdmFkYWZ5WkQ2REluS3Y2SWovdWY0ZFNLL1p4?= =?utf-8?B?dXBocUkxYnVNRy83MlJKMGZsTGVwQm1lQVl3bWtLclpsR09xd3EvNGVDbHFM?= =?utf-8?B?cW1IclBkR2FQOFlQYVRZWk9hY2R1dTN6dWxBL1kraTNSTDkza1hndm40b2JT?= =?utf-8?B?cDMrT2dLY3ExdFlQZzIyTTJLamlhZ3h4ZnNOMnR3bXNqellrVWl6RmdVTEtu?= =?utf-8?B?OHJERW9VMGRnPT0=?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?K1NEZ3NmUXNGeW5MU3pKdDBjK0dUb0dqVi9TQjR4SDg0UHQ3Ym5iU3F0K1NV?= =?utf-8?B?eG51YmQ1QllHZWxlbUs2bXUyVk1ibURKSVUza0ErQW9EYW9IUjVqOENYYUYy?= =?utf-8?B?ZlVhcHg0TFJxK1VUbUpCNXVtaUxLa2RzaHNRdkI0d0dOanNkQkNQZDRycHZQ?= =?utf-8?B?emc2STZZZE5yOVpDdDE0L1N0ZUpObWtSZ3JjWU9NWjN6NDVCcGRhQTVYWU80?= =?utf-8?B?bml5WXFkT01UMlRpNnRqSXdMOWcxeDNyYXB2aHZva1VmZkt0eXgzTTdCUVNO?= =?utf-8?B?eC9ReWM3UVRIc3Q2SHgwVmI1OTNSQTZxV095OCtDbk1xRHBudXpBa3ZuTnpw?= =?utf-8?B?WWNDUmZvb0JZRHNOa0FsZG9KaXpCZTJVVXh0QzJ6dnJZYURBakVzaWIzeWVS?= =?utf-8?B?Zjd3ZVVjd2VQaUlaYklqUG5sNEtIcGl4K2xlQk9iUlkwT3k0Yy9GbTlFVTU4?= =?utf-8?B?YXhtaXpyT1JjNWhIdlBPTUpNNXFicWhpazBCUVZ1emhqNUNKV2pCMWswaWVK?= =?utf-8?B?U0lkNVFLZXJoRXFhVjF6QUswMUZiMDR3bXV5aGtiYXJITlhHNWxPYlFYUWs4?= =?utf-8?B?KzZza00yQzJNeTRLZ3BkUmpIa250MTBMc2l3VmhhY1FmczNZTUZTLzlLTmov?= =?utf-8?B?QWhaZnBmN1Q3dUplaUY4YXRmTzFMOHBIMTdFdk15YUdncnV6YXFJclVaRkJy?= =?utf-8?B?SUUvMEFyRkNKRS95SFhncmF2Z2tITmxTeHlkLzl0MW9lS0hQZkswK0xjamtN?= =?utf-8?B?MXN1cjV0Q1IxVU82NktvdnRUcytadDFnM2FzWjJxdlR1MUVYb1R5Zk9ZT1B1?= =?utf-8?B?K3BsT0JKRTY1czZab3BJblN1Nkc1OXJBWFgvWVV6RlBZZ2hGSWswU2RUdXFX?= =?utf-8?B?Y1E2SkZ3KzRiUzhubG96RWg5Zk94NytJQ0pINzVyV01ya0FzNXNhYXE4c2pk?= =?utf-8?B?MzVTWXRHVXhFd3pJV0VGeG92eHhCRjRwdzNpMWRpS1VUd0hrc0tRb0ZMMHJS?= =?utf-8?B?OVk0SmRweloreUJ2SDRoWXY3di9Ob2R3Nko3SlhBU3ovbUR2L3dUZDFnVm9L?= =?utf-8?B?c2FQalZZVmZwMmJydWlkL3hwWTBkc2VHRGEvYkVDWlplS2Zma1MxRXZZd0Jv?= =?utf-8?B?VFZIOVd5U0RncmRlSG5DN0xzM0RWTE1JTkVrTnY3THdKKzJmL0xTbFVMeUpB?= =?utf-8?B?R25kc1R1UW1nTjQxM3FQeDBXbnZKdVIvS1BVVE9sMWUrSE5SUkJjeVhKQXFT?= =?utf-8?B?eWZGRm5JNTY1cG9zUkFMTzBDMGRmRkF0aGRqUlRYaEhpdDUwNEJ4VVlRMnZY?= =?utf-8?B?OUVuZWtvQVY2RUpERW0yTis0ckwzNDYvVHhXL3dKVFpyanFxMWtZNWs4M0kw?= =?utf-8?B?VTZvck9PekZ0NUpKTGZnR1g0akxjNzdnUks1amNCZlJ4VS9vNGwyNHZqY1ZU?= =?utf-8?B?MjdNMGZzV3ZVTS9YdzdaZ3Q3Ung2UDBJMnVsYTcyZXZpT0RFSkg5L2hvMVRM?= =?utf-8?B?Y1h5MTNUU0o5NW5pN3lrRnZWNng5aXE3RU4ySWxkZ1kzZGdGTGI3d3J0ZkND?= =?utf-8?B?L3dpUjNtRlNCR2ttc2xaRUlLSWEwTWF3UERKZ2FBNGlhTUZzaCtrdC9scEpu?= =?utf-8?B?dGYwZkp6NXpaTGttM2hCd3NkcW0rV3o5UWMrWGYyWGJWOERWYkZya3FIZGhS?= =?utf-8?B?UlBnRkFwdWgrdS9GWXJFQ2VrclRnMmhST2ZraFBXSldZdm40YzZhalFUVk9u?= =?utf-8?B?MlAwb1NsT1hRVVpBR214RE1GRGN6S1JXdm5xRkg5c2t3L1ZiQVY2amg2TlMr?= =?utf-8?B?MDVIdEx3ZithUk5WUGg2dUhvNEhLdDBkSWVQMEc3YTVGK3c2c0JIdVFJUjh5?= =?utf-8?B?MFBRM0xBR0lkRFFXRHBwdWJYSk4vTGxSc0Q0Z0VVakNCZ0ZTSHlrZXBTUVFJ?= =?utf-8?B?UEVtQUVVdE9udVptTkd6WWtrN29oWTliYXV4UCsvUHQvV1R1SGh5ZjgzSVlQ?= =?utf-8?B?ZDkzYUVSNzNtczUzV1BHU1pDdE12NlRFL1NBTy9ZYUlQZUUrTFFrcHBvOXpZ?= =?utf-8?B?aXdtbEpCdnJrV1VZV25mZjhxVlZXQnU4SnVYUWFiRStzd1JVeWRqU01VNHRK?= =?utf-8?B?TWFPKzAzVS9QQnA2dFlkVHQ1ZnB0bnJBVE1ReC9iaDFzUTBveDhkMmhIYUNz?= =?utf-8?B?bmp1ZTJlRFV5NDJxMldSOXJGQzl4WkozRUx5U21mKzAxR1N5NUpNSUZBc2Vy?= =?utf-8?B?dGNGU1VGTHpPU2xIelVOSjBZbTM4T0txRXpQZ1BSR1dpajNvMTFCZUZmYzhC?= =?utf-8?B?b0R5OFIwRTdBN3dBenMybUlxQTA5VXZsaUkycEJuaHhLTFdWaThQQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: bbcc0759-43a1-4b29-a14c-08de4ec383a9 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2026 14:37:56.9636 (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: WKhnOspQl2Hj//0+x3i5Ak3+5cKJ6WSHM/E5HnZhIE5Cmeyj+SMohJxVdZSMm4rvH/mqnoTYf+b3ZtjgONtxwg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA6PR03MB7879 On Tue, Dec 23, 2025 at 06:03:25PM +0100, Jan Beulich wrote: > This is as per discussion at an earlier Community Call. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné > --- > Btw, what does "(b)-(f)" refer to under "Specific Process", item 3, sub- > item 5? > > --- content/about/security-policy.md > +++ content/about/security-policy.md > @@ -103,6 +103,8 @@ Vulnerabilities reported against other X > > At this stage the advisory will be clearly marked with the embargo date. > > + Unless requested otherwise, the discoverer will be credited already with the pre-release. > + > 5. **Advisory public release:**At the embargo date we will publish the advisory, and push bugfix changesets to public revision control trees.Public advisories will be posted to xen-devel, xen-users and xen-annnounce and will be added to the [Security Announcements Page](http://xenbits.xen.org/xsa/) (note that Advisories before XSA-26 were published [here](http://wiki.xenproject.org/wiki/Security_Announcements_%28Historical%29)) . Copies will also be sent to the pre-disclosure list. > 6. **Updates**If new information or better patches become available, or we discover mistakes, we may issue an amended (revision 2 or later) public advisory. This will also be sent to the pre-disclosure list. > 7. **Post embargo transparency:**During an embargo period the Security Response Team may be required to make potentially controverial decisions in private, since they cannot confer with the community without breaking the embargo. The Security Response Team will attempt to make such decisions following the guidance of this document and where necessary their own best judgement. Following the embargo period any such decisions will be disclosed to the community in the interests of transparency and to help provide guidance should a similar decision be required in the future. > @@ -118,6 +120,8 @@ As discussed, we will negotiate with dis > > When a discoverer reports a problem to us and requests longer delays than we would consider ideal, we will honour such a request if reasonable. If a discoverer wants an accelerated disclosure compared to what we would prefer, we naturally do not have the power to insist that a discoverer waits for us to be ready and will honour the date specified by the discoverer. > > +In any event at the time of pre-disclosure control over a possible late change of the public disclosure date moves from the discoverer to the Security Response Team. This is to avoid pre-disclosure list members putting pressure on the individual to extend or shorten the embargo. I would maybe add a comma between pre-disclosure and control and clarify that after pre-disclosure it's always under the control of the security team: "In any event at or after the time of pre-disclosure, control over a possible late change ..." I'm not specially fuzzed anyway. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 08 15:47:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 15:47:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197776.1515207 (Exim 4.92) (envelope-from ) id 1vdsEU-0007ys-Rk; Thu, 08 Jan 2026 15:47:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197776.1515207; Thu, 08 Jan 2026 15:47:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdsEU-0007yl-Ol; Thu, 08 Jan 2026 15:47:30 +0000 Received: by outflank-mailman (input) for mailman id 1197776; Thu, 08 Jan 2026 15:47: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 1vdsET-0007yf-6K for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 15:47:29 +0000 Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [2a00:1450:4864:20::435]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 530a9ecd-eca9-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 16:47:23 +0100 (CET) Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-4308d81fdf6so1709292f8f.2 for ; Thu, 08 Jan 2026 07:47:23 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0dacd1sm16800969f8f.4.2026.01.08.07.47.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jan 2026 07:47:22 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 530a9ecd-eca9-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767887243; x=1768492043; 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=L7DVyOTXsb3+CaG7eTe4cood4tHN4Xx26Uj7rq+UfWw=; b=Vs/6eNC5etK7k9PomdeUxiN9qA0MV4L3knklnS25POvK0T12bl+NgQzC7qrRpsgtnC oEPlcjF1mythLoK6AIQjAgDxyFBIwENSaz+1Jgw9L5TYHcRlilVhsLuKqJ/MCfq5so6L noY1dUVbF7josbM5t++cGoiQdmEU6ZemB9ulwTVB0DFEKO1vw1bdmaoLVP0BKbd8j2hF cj80rOcvspZDA48EzzdhGiQCEvhGE/JPZxx7Kpo1FSdzFIuJYyz/OZw5NFJyo0IOxrsy /uMH62ERCZFXRrTCYiza9eHnXK2sXed9pNXRkCiTVYBAyPu4xd+bi69osaiA505MO66f v8QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767887243; x=1768492043; h=content-transfer-encoding:autocrypt:content-language:cc:to:subject :from:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=L7DVyOTXsb3+CaG7eTe4cood4tHN4Xx26Uj7rq+UfWw=; b=ntISgs1q7nZUzdY2s36m3zbTBS0ExY7PaugVfaIpwpX8uFo3zvYiTkLbh9uSowvMBm 21G/oCLJM5ip1bnq8XA95IiOxL3JcT01fLJ21EPEq1p2vk9Us73eP209PcAY2W9bvepY VaM1WWmRQdUSKe9ws6nyRM9JvQ4oe4CRS2rBi0o/O1oN8GTSytV/TQ0/jAa4KqqwctVo 8w1SptNH2RUHVnMI8BQekf+qTUqnK/U2NNVA2cWwAX+BQA54a9h9VDq0XgOvsQ+w+J9K BckiMeCGEw4dOXYyyuCHZnfkguUWF9Q5bWkvxrWi8TqlYZg6cY5Zd+4a3/dLlyCgqvJ1 sKNA== X-Gm-Message-State: AOJu0YxWptDX2MG+d6puE6BCbpXMcBU0KwyQPbPCNLnhfT+NyVGQeXrG vCOAg/6q8yh3wPLELsN8O0SRT70IepYsyeQgMuL9oxrgEf0JDpxqiat638kwPCW2pr2snTZk2/+ MLns= X-Gm-Gg: AY/fxX5aKLZGLUiakWDoNJw7zstJ/ZuBky4hi8JpS8NOfLMYAXlsTrUniYhR0rAwdhF QOHePuYNPB9XxVOL4bKXlDzQsWv9EjGN3rq26HQx3qv0rAYiQqfSemUtbPvxtM8r7+Qx6iY7gp/ 9oVj8EMkft5pyZMlMPwn/laHr4qjLQYTrfDvN/tPg+gkiUy+1ACOKfMBEJOXEAnkrCoDtnUjgDw QO/DpNWv9UenHJBTb5m5H5oQbg4VyrQ68YQ38DasgL7YmkDFXUg0Ppc2pQ20UaWYxnFEQncDaBI 6gdlIRLtTADlafx/tK74HqIzUDgrpphHb9zg0gB+NTb/d2B+7tB/EWO6ZXPDrnPf2QUzFvuff75 0lB97H/55f0tvwE2Rh/E4yJm877tsw2njMx45+T8ZVAMIyiwMcbMcFCNgzvqUwyrfd1F1JKBn/f ivZ8bk405V/reN+So6qSE7GnS7gslvhyWvgPmUk9V+3H7k/QXXBdgQkHlMglJEiN52oTPTQDccr G8= X-Google-Smtp-Source: AGHT+IHBdud8VfeLIWdYQtlXU3fvvyYEZA0MIfKCjdZcaMoUAvuWLyv7caRmi9dajyAkDee4jPCmTQ== X-Received: by 2002:a05:6000:4013:b0:432:8585:6830 with SMTP id ffacd0b85a97d-432c3760f78mr8434273f8f.45.1767887243079; Thu, 08 Jan 2026 07:47:23 -0800 (PST) Message-ID: Date: Thu, 8 Jan 2026 16:47:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jan Beulich Subject: [PATCH][security policy] move past team members To: "xen-devel@lists.xenproject.org" Cc: "committers@xenproject.org" , "community.manager@xenproject.org" Content-Language: en-US Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit While this information doesn't appear on the rendered page, it probably would nevertheless better be accurate. Signed-off-by: Jan Beulich --- a/content/about/security-policy.md +++ b/content/about/security-policy.md @@ -39,10 +39,6 @@ asidePosition: before # - icon: fa-star # name: Andrew Cooper # - icon: fa-star -# name: George Dunlap -# - icon: fa-star -# name: Ian Jackson -# - icon: fa-star # name: Jan Beulich # - icon: fa-star # name: Julien Grall @@ -51,18 +47,22 @@ asidePosition: before # - icon: fa-star # name: Stefano Stabellini # - icon: fa-star -# name: Wei Liu -# - icon: fa-star # name: Roger Pau Monné # - type: members-list # name: Emeritus Team Members # items: # - icon: fa-star +# name: George Dunlap +# - icon: fa-star # name: Ian Campbell # - icon: fa-star +# name: Ian Jackson +# - icon: fa-star # name: Konrad R Wilk # - icon: fa-star # name: Tim Deegan +# - icon: fa-star +# name: Wei Liu --- {{
}} @@ -301,6 +301,7 @@ This is a list of organisations on the p ## Change History +- **v3.27 Jan 9th 2026:** Move three people to Emeritus Team Members - **v3.26 Jan 8th 2026:** Changed embargo control - **v3.25 Dec 23rd 2025:** Removed iWeb Technologies Inc. - **v3.24 Dec 5th 2024:** Added NixOS From xen-devel-bounces@lists.xenproject.org Thu Jan 08 16:07:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 16:07:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197797.1515217 (Exim 4.92) (envelope-from ) id 1vdsXn-0002rE-CJ; Thu, 08 Jan 2026 16:07:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197797.1515217; Thu, 08 Jan 2026 16:07:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdsXn-0002r7-9l; Thu, 08 Jan 2026 16:07:27 +0000 Received: by outflank-mailman (input) for mailman id 1197797; Thu, 08 Jan 2026 16: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 1vdsXl-0002r1-91 for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 16:07:25 +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 1d1c4d9e-ecac-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 17:07:23 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by BL1PR03MB6117.namprd03.prod.outlook.com (2603:10b6:208:308::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Thu, 8 Jan 2026 16:07:19 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.003; Thu, 8 Jan 2026 16:07: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: 1d1c4d9e-ecac-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=G4ZAEUQsOYsDguIQwjdnGotz7MFBB9a1yjDVw9DXNFS9Wy+Por97XJd/Vb6tmDbPU5VXau3UxC5hxRxA+csHpDqE/L/RYPTKajIps2ypimQZeDDAI0C/8y5bJ4WqAY5dBGJdp3u5bM6uDMpWuagIwbg4mpiZ+yyI3FxOe/Vulj+Yi/1E1cr19r/noTEgIkHiWEinmMsfKjUtjZG4TdoGXJ4q1VS0E/orrlhXwW7oLVdA4JHtygd12SyWmNJEs3joTH/mxn+DCXdeAnLWKNUnnT87E1WupBZ2HYbhVIorhXVlzP3Rf72wZ75oLix+sleOil1hZ9rTxDaqLUSFBxJsrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pwirbyfjPRTT1gO89bqLL7UWtwqkXp/BAHbyOm+22/c=; b=ExE+M8BVgDsnJu/fNEJpVG3RCRKX8kyP1CTLZViRLxckp7UdwPO6viRq0uMwrgPJV78ibTU9mK87JexV+Evc4PjQmdCoyL4BzGPmQhvTb5c3GjCRfz6+Uj3GY7WH6mK/wdQo/k7216RtAbeW9BX4DFpMp+uU8qnLIWz8pE517ZeuD8tgcsXvbtcHv/DR2kkAmUPSl+D+XaeFnAJWJbbGokE/6ZGPwY1U15I7E0qCfiZFzSQTpmZAnJW3Xdp24/YrHPwKzQ2qQAv0lwW/EZvYmk1B8eOo+yHP3roGVMDYAkQ1LA3mdPO5I1UQhn/kg7o1i4jI+XG+wQAr4MAbk4AaIw== 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=pwirbyfjPRTT1gO89bqLL7UWtwqkXp/BAHbyOm+22/c=; b=BnIuX2NojN0ZYSpEtuwV9IAOBMZRLpQAtHXonRCsJG7yJlGVOftSRqFbCiMByVSQwLFodPUfIDnHeHA9GrzrD3KbIMN7+wwlCokUnENYY9tgFJnGi2oMIgDZziEIBdPh6zjEHaiZVlE7swX+ZlPo1e0Y2ltvPCKfKilttdLSgkE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 8 Jan 2026 17:07:16 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , "committers@xenproject.org" , "community.manager@xenproject.org" Subject: Re: [PATCH][security policy] move past team members Message-ID: References: Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: MA2P292CA0021.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250::13) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|BL1PR03MB6117:EE_ X-MS-Office365-Filtering-Correlation-Id: 8b6bb274-279e-4a03-006c-08de4ecffffc 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?Y1hybkU4R1orVk9MUzFwMVJHeHV3UzZ5cGNiSCtMci83TU9YUmlXb2tOZ0cv?= =?utf-8?B?MDhwTElLZHc2T3BocjdNTS9oWVhUNUFtTjArV2NacTdHNzdMblUwTzlZei8x?= =?utf-8?B?N3dLOFpVWGVaTkdzQ1BRS0F3YnlvUWkxZG5YdFpmR2JtZUhoNzFxbUVyeEo5?= =?utf-8?B?dUhrRXBUQzVVbGJ1NHlSMGFoYWxHaXc3MkVmK1RTMUI0R0JjR0hOeS96WXpm?= =?utf-8?B?S250a0hJQmdSWHBUV21aNTZWN2xYMHhLZGNUT21LMzF2NjJCanFsclVYbVJO?= =?utf-8?B?am9XNTJ0dkozTkZRY2lIeDJxcDF4bk82YldYUUd1Z0sxbVpxRFZIaUV6dTlJ?= =?utf-8?B?YVhFMTI4aXlpUHZ3a1pxQkJyN2JwZ29oR0s5WHdNRHE5UDE0Vkd1NHd1blQ1?= =?utf-8?B?Tk5wZnBnMjhYQU12dm1SbWg2Yi81eW1wZmpxRG16THlZN2pZZXVuRnZXayts?= =?utf-8?B?QjdyU3JsNHM5OEdaZnhjY2k4RnUrd2hteG5iZDZsc3hMdDFtU0ZzM0JiNklO?= =?utf-8?B?T3diZHpDc2R2RmZJd3RDL1JhcElOR2RqbjdZN0RXaVYwZ1BMYnFydjM1cmxx?= =?utf-8?B?eDhZYjFtZWtidkQ1SjhpQWYrbXorRU5oRjV4cTBrRWlQYnhJQ3k3aWRQZXdV?= =?utf-8?B?QWk1QnBpQldKK2hFK0ZiQ1hSYjY4d3hOWG9CbUFuOE9NYllBRFRBbXVUbGRI?= =?utf-8?B?RmxRbmtLWFIvdlZHcjBsV2JVTHpwdzRyOXR5WS9zYWpObXZ5b1ZuQzZrRm44?= =?utf-8?B?b1BkL3o3WDdmdVhKNnJ6RDJidXNxaUhpRjN2dmg0T0FoNVpXbmI3a3Vsd3Ni?= =?utf-8?B?Lzg3M0xyZUlIc0lEcGhQRDlXd2srWEpqOHdmc28zV0hzYy9MS0p0VjVkZ3Y0?= =?utf-8?B?YlZSMENCN1hzNmNsbE1BWWw0SGpSVitNUDdrclNEOHE0TENXNFBJSVR5dmxz?= =?utf-8?B?dE44Zm9YK2NKeTZGd01LdzZUR2JRNGVEbm9scGcwMzkrTUZWRVZpVW81bTJD?= =?utf-8?B?b1l6eklpeGx4RzJRanZDMTBvdHUwaWxEMkVKbE9GOTFTTEtCNkhpS3NGYTZk?= =?utf-8?B?MnB5bTYxcHRzc21tRndYczA3NUhMZ1RiVWhSS2puZEF4Q0VQV2J6SE1BUkNG?= =?utf-8?B?MThCNE83L3JQOGJGaFdlbGZIRjY3bmpWRlFCQmxaVzRERVk2QTcwNzBUWFdp?= =?utf-8?B?TUVFaXJHa3RFZkdteUk3dzZtYXNITXFLUW1LRmpVenVWOEw1NXQ2dXpUL1gr?= =?utf-8?B?RTVUZEJKcnh5cm85M0RqWDh2em5aRlRaYngzWG02Uld6a0Zkdm4vYmc5NzJ3?= =?utf-8?B?VkI4TlFEOThBTG9QK29Ib1NBYTRjdURmY3RsNnlUSDJMSWZBeUFwRERJeVN5?= =?utf-8?B?UUVtVmtRZ0tIcEN5YmNyZEFvbVI1bjNhOE9HN3c4a3EvVGxJaXBUZStrc3dL?= =?utf-8?B?S0RvTkVqYnVTUi9GdXhROEVJWTczcDNIN2dicGlsSTdKcUFOaTB2b3FpUnY2?= =?utf-8?B?SzhuU3BvT2hqZ2l0SEkwNENnVDNjcVZEU3NIc1VQOEFNWGY1WGdnbG5pSW8w?= =?utf-8?B?NWtqYUdrcVBZamloWEt3OGlJRDFoVkQ2czZDRXNUYUxZc3hEdk9YT1I1VEha?= =?utf-8?B?bndGUm1ua0VVeDN1SXg0QjYydDR3bEhvNFc1ZVdsc3pRRnFlZ1pXQTQveVZI?= =?utf-8?B?YTVBTmsvZjY2RzZKN1pjZmp2Sk0vL0tPYTNTRmQrNGZvUUZyUm1tRWEzTHZS?= =?utf-8?B?VXo5K3BIUHNPU09leW5pdDJRaUtqZFNGV1hHVEc1eHc0b3VBZk1TZzBRY1hy?= =?utf-8?B?MmVvVFkzZU1MeEk0UzE3czVYeGZTSHVSRDdZd01ISW5RSXdxcFdNMmx4UWE2?= =?utf-8?B?aWFQVTN2RkVmZ2l0QW9uWGhPYnFrdmN2RXFaQlY3MDUybmJ0TjFuRlpIUXJZ?= =?utf-8?Q?ZltczPErIyzSQ2I/t5Xr3jL6aGKJG7xk?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dThKSWplZk5MVnZuUVdFMkNja0ZnT1pNa0V1RGxLbmlxNjQzWTY3Y2x2NUVm?= =?utf-8?B?ZVo4WTllKzBLc0pRSTUwRjNJaXBzY2pNSVBOdmFBZk93Y1FxdGtJNUd3dTRC?= =?utf-8?B?bHpCQjBBOTI5ODlvZVYwY0xJR1NXTGtDbW1lZ0JoRGsvaXg2R3R5WHlZdnJG?= =?utf-8?B?SGVYVDJjUnFVRGw0WHAzdVpRSlpiQnlKelZ6RFIrQ29YSjduUmtMNTllUjB4?= =?utf-8?B?and1STMreElRYVJ0SFlYMENLSGttc2NtL0VkMFgxT3RRYy9pOXM1ckYwTjN5?= =?utf-8?B?T0ZGc1gzRE5STkR2N1MzOEdTTUsyQ2VVWHJPN0xxSFAxbW1qbFRFNkNYaVpv?= =?utf-8?B?TDQ2WW52VFIrMXFRN09wQ0tRK1VqMk1RZWpycVJKV2wvY20vYjZuazZyZ3VQ?= =?utf-8?B?TllNcjl4ZmhVSzNGZ3ZxNEkvY3NKSTZiK3d3STA0VmRkZjRNZU5ZTW12bjM3?= =?utf-8?B?RzNmcnBNL3VyeHF0ZjdPRjRSek5ON003b3dFaHhHQUo3QWRmRkFINnhlcGpQ?= =?utf-8?B?Yll2MHlNd0RiOVIyWGdCL2JOVVE2TW1WdUtKenVjYmlyTENqaUdYY0JnMlg4?= =?utf-8?B?VGxCZ1JSMllhQlN1bmhGTGRSQTByTjFRVVhoa3puRGxFNXZPUHdQVWlhMVFv?= =?utf-8?B?MGtzTDJ0SkJWZzBZSEp4ZlVpQjBreXlJYlFzZ2xBNW5SRVlQRkJUWEVLVWlD?= =?utf-8?B?WHVlL2pCMU1DSE8rYk9sWDExejlDdDV5SUJzVWhPdG9ORmhzdG9LY2hTUnlC?= =?utf-8?B?WGRwRXJTNmlMNlBuVWFoWlVxSHdpcjFCVTNpS2JSU0lXZUJYdmJjYnJib2h2?= =?utf-8?B?dE1XUm85S2dpZGVtRjBZTEMwT1pPL3d0Q2pGQ3VxRjBXeEV5VzE1aXhHWVF1?= =?utf-8?B?dlRueTVYU0xiS3J3TjhQTGhjNEZUUDdKV2dtancxT2JZcjFleGN6d3VJR25m?= =?utf-8?B?ZlczTG9XQkkrQm1sclVEY2o4WnNGb3NxelNNRFhzajFBbElxM3JINk1OUGY5?= =?utf-8?B?dG5jUUlCNGd4S003RzdpZXhXUzRYSVAxd2x2ZnRBRkJBVGlvV0R2VjN5UW8w?= =?utf-8?B?aldXTzFzemtwb2pUL21jTldYM2piaWZQZC9yVUZaTTA0TEIwcGpzL0NFQVdk?= =?utf-8?B?SVRBcFN3UUZDdXIxTFNtQkI1YmI5TjgvM1RpMGVhcGFCUTJ6WFAxRlZEN2oz?= =?utf-8?B?SmtuTytqbDJHZGZBMUsydFhXSkh0a29xeVJqdkQ1ZlIzSENXQ1pWRVVxNlNx?= =?utf-8?B?aXBrRzdZRHEzT1FEZWhLdVFZR0VUZDdVSTZnbU1XVEl2TnZERmhTOUhUeUU1?= =?utf-8?B?RDNQOXZ5bWRCbVJLbzBRdVpjMmtmWEpvcWZ3b0NHaXhoblIyRzJEelcvcGRR?= =?utf-8?B?WkpXSFdmSW9KaG0yQnlRemFsdHVNT1pYakczUmhSWUlrdEFvQ0UrRVBaS2FW?= =?utf-8?B?MEtjSWc4bER3NXFKNWZERnB5cVNudkp5OWRrQWJQakZ0d0xrZDFKRGNBUXh0?= =?utf-8?B?RG5DblY1Mlc4cERBRkVQcER1dDhETmkxVjJ6SDRFNFNXYmRNcmtWbGd3OXRm?= =?utf-8?B?RjdpRWtDTXB3UDc5NXZ6cVBWUVhINlFoZU9mVFRhTkR3MDF5Q3UxS3piTGlI?= =?utf-8?B?QktVZTRyV3psMUQ5ZU1EMlF0QzY5dTZaVmNidUFRT2hsYldnSWxTT01wZzN1?= =?utf-8?B?OGlQdSs3QXZvRE84bDZ1WTk5OHF0TFQ1bzdyZ3RwNHYxWjIyRkZTd1lCRUt4?= =?utf-8?B?UE94Tnc4YTdoYTBTNVhCK2oyYmJFQlNLY3V5OUhudkQ2UUExdXFsWkkvL3Vl?= =?utf-8?B?bnFQQXRoRW5iZG40UitYN3ZPakNhV3Z0cVQwaGkxODEvNU1weGJUaUtjTHAx?= =?utf-8?B?THRnZmp2RmZwRHlZMTBocmZaWFMwcWhuaTh3SXZ5NmU5RXpnY2pjWC8wcXl2?= =?utf-8?B?OHVXaEVVS2lYQzYySWhvOXBkRGtYUmErR2pBNVN6OUJlM0JkNndZaGlEK21h?= =?utf-8?B?RmU3QnVnMSt1RlpzWmROT1Z4TEtzWW1mb2kwQ1ZYallZZVlkS2h0Y2ZqRE9L?= =?utf-8?B?VzZGdzY3dDE4S0g0Yk9udFlCMWxSeks0Z1orYjhlNGxCNXN6azdHNDB3eGJN?= =?utf-8?B?ZWsrcGxvN2ZYT0Q3ek1PRldDV3c5bnJFanF2QXF4ejJ3dUEvTngrMGx2cU1C?= =?utf-8?B?dnQvYURPWktlWkxYS1VpSCt5UTkyOXZzNkc4TnJZYk8zS0dZWVJJN1Bjay84?= =?utf-8?B?dzJVbW5KRk84ekVLNzNmMzN1Z2x4TDI5cjhjQm0ySHlKNkI2QkdrVUZHYjRE?= =?utf-8?B?MlBvWC9XV0ZFV0dETFc2MzZJcnVwSUVsUDRPU2lCSnhIM0pnNE5BZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8b6bb274-279e-4a03-006c-08de4ecffffc X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2026 16:07:19.4706 (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: ZmmXpP+Gng/4j6e4yU/bL8GGRewcHD8w7NBL4SkTV2NGlXEBPu6Qs17pv1U8Xx3hl6e2OwMeqM9RmZ3BG5bEww== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR03MB6117 On Thu, Jan 08, 2026 at 04:47:21PM +0100, Jan Beulich wrote: > While this information doesn't appear on the rendered page, it probably > would nevertheless better be accurate. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 08 16:29:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 16:29:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197826.1515228 (Exim 4.92) (envelope-from ) id 1vdssv-0005kb-8l; Thu, 08 Jan 2026 16:29:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197826.1515228; Thu, 08 Jan 2026 16:29:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdssv-0005kU-55; Thu, 08 Jan 2026 16:29:17 +0000 Received: by outflank-mailman (input) for mailman id 1197826; Thu, 08 Jan 2026 16:29: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 1vdssu-0005kO-Bh for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 16:29:16 +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 2a623472-ecaf-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 17:29:13 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by CH2PR03MB5287.namprd03.prod.outlook.com (2603:10b6:610:9e::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.4; Thu, 8 Jan 2026 16:29:10 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.003; Thu, 8 Jan 2026 16:29: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: 2a623472-ecaf-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lIR6qQVvOsK+mmVdq4qj1/QEcTVM2ATTzJP5LASEb1wikZ2HlQP3lmj90+IdZ1Ck9TDSZRxkXqsr6pkwPk8GThReR8xKd0s0PCs0b5PvWkUUf7UZ38wpREGeBsLtXeWQxDr9hkxaKqH9O4a1Vvhxg+8IbGQcI3MiYkPoTl0pATkg9KQ5hkizKFuVXp0QGz0B47RkyaSkCvKX3iq96SXJZXaQwgwdE6O1rG9K3dJMuMLqYOmuwF2LlWXT/3yuaEEVNQEZKc1ii4sYwTKTepnY3PwvdllewBeqoDCV25Cel2GLRbU+R3aa+pbop6/NSX7cx8FHEVmhM40OEafswc6DCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QK0XbmDjaJB9EdLs8Wl6IsRLrpv8moOY+/3MSf71hj8=; b=F8Y6kkyOnihQCLKx6qqjtkLCMKkGm8IbCm8vyEgG8LcWoM7/VQP93GQsiwU9e2QKeQzh4mHfVD0lULvKHZTUydLMmLhJCCnuNxNtXSGZm0oVVBJzZytfLYJeVU0jQQ/MH7+q21Ic23zpTFxxl4/iPjkEF9PnplE/2FYInRXa5r2pRtDaT3Hykz+vxmFUO97eQbqBPlQPMi+mns+j8GhoutrsjjlLA3q43tgcSQk2e4hLPEsD1o5F9q4KfXiY/TeMuZc5u4swjlR3GTK1pF7filY7mFTi6nFQjkHwktF6zbFJoB0ir6YoxL90zsnPX8ZFf6HsNg7OHOQUD6+LsUxxGw== 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=QK0XbmDjaJB9EdLs8Wl6IsRLrpv8moOY+/3MSf71hj8=; b=OXgV8wJsVh8fSDYRKuP44ZpCgVl+3A2739j49nr47cX7Am7GttYCpKppybtOsLtO35N2dKJE5Q962ZJYczsLNvfwxeociSLxfWMSzr05i4hxt3L7LDaRm6OXZREenbdN/2orJXbj3bxP8w0iggrmwpaaMmPF/40sMFgbVe64F8o= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 8 Jan 2026 17:29:05 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= Cc: xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini Subject: Re: [PATCH] CI: switch KBL console into polling mode Message-ID: References: <20251208153519.1198226-1-marmarek@invisiblethingslab.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20251208153519.1198226-1-marmarek@invisiblethingslab.com> X-ClientProxiedBy: PA7P264CA0202.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:36d::15) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|CH2PR03MB5287:EE_ X-MS-Office365-Filtering-Correlation-Id: c9223ed8-7a39-4167-3e87-08de4ed30d1e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?SnYzNGJiYk5OcktndE80SGZSekMrTGwzM2x6ZDVyczBJM0tKZE9FelZFVlNW?= =?utf-8?B?Qjcxc05CeVozWGVKc3luRmQ2QU8xUGlidFVQanlldEJHanRJRUZ6QTFiL0xL?= =?utf-8?B?MW1EdkVJSGhJdytNN09CZTUyNmRiNWFGTWlzQUI5LzhsZ0E3SGh5M3lxSzk1?= =?utf-8?B?SEtBc3pQK1ZVdU1VdDlUeWlDMUkxaW9ySGQ3OXZWN200bk1qbmFFdkRUNlVx?= =?utf-8?B?aU4xbXpaRThUdUQxdUpFSklPSVoxZFlzQ1luQTR2clhYM3Q1VEV6RTRMMjZW?= =?utf-8?B?THQyZTRaWmpRVCtIV1ppdmZVVG5qVSt4OXh3ZGF5MGp4U08zVTByeVRHTnVn?= =?utf-8?B?aHJrejVVOUM5Z1ppZG93N1NveHQ2K2JmeGNYYS91RlA0MUtBRCs4cWRvUGg4?= =?utf-8?B?WHUzeHlQUkhRUTUrbzBhemszendFQWFNRjNCdWpaSjRxZTc3bG1JNDJCUk1h?= =?utf-8?B?WEYwWnMxalRxUVdFbHc3Q0twcWpHbi9QYlh4blFnNW9jRDJselBmODVQUG85?= =?utf-8?B?OFhpaGJXSC9mcUJCaENodHJPSkdoUDV2dE5rbjlYdVdMdmVUZ3dNZmJ1UzI2?= =?utf-8?B?R3g1eGRVTXdBTEd4ZVl4MUZ5VzdkSEFDWnRQVGFqUEZodFZoTEJ1Vy9PbnJU?= =?utf-8?B?eVhyWEJmYW94ZGpMY0ZhQmhUNUZGdWdZSTZKb1BIQ2lYbjYwNTcxN091K2k3?= =?utf-8?B?VHBINlhScGZDWHlhb1pzd3Vpaml1aW1zMFdmR0tSN0pmWFkzU3V5aU1PZU1S?= =?utf-8?B?YnZFaVhEL3BDVHRjVkNJZG5aR1dVMzJ6eEU2S2txenV3THVwelFzSnhRVXJH?= =?utf-8?B?SVVJTGw4OExkS1NPMDNRN29CZEdZVTFxQS9BSnNmS2VDTkxib1VkU21RUzB0?= =?utf-8?B?WTJOU3Y2VE8xYytMVWdMVkVDU0d1RWNpdEVQN3g0N1Z1MnpJcW5zaUwvZTFG?= =?utf-8?B?NGNRdVBOVk52dU9uTVRGcS82d1RDZnZlNEdLbFVJZXlaRXViTGhZR0ppbU9O?= =?utf-8?B?Z1hVaWErMUF4QVJkdmszVEdCdCtFOEdoVjdsMVRYd2Z6UU1xR3k5Wm4vc0h4?= =?utf-8?B?aW1LNWx5S1k0NjhoQStiV1hwVnI3NkEwSVJmcGo2cjZhbTM3Uml6OWtYa1Vr?= =?utf-8?B?cGlNM3p5dDZqMTdUOC95azJtYzQ5V3VxNEZtZllxR0taQk9qdE1YSm1iWnFU?= =?utf-8?B?Sm9mRzlGVGRjODlZOTl2Z0N0b29qVHVGS2MxVmw4S0lpbUtuSWRVQW9zRzZp?= =?utf-8?B?blExTndrVW40S1VPdUhSM1lKdEtkK2doVDhMbTl0MEdqM3NidzBSeFNObDJw?= =?utf-8?B?VDlnd3A5MmZWZ2hNRm1IRnBNbUF2OEZ1aFU0UFlQT2VlU2dxdS9XTjZ6NndY?= =?utf-8?B?NkNUMGVnMGNTTTg1dXhZYURxVjZFS1ArWUVLSGY0WTNaZ0FZM1BEOXVNN3A5?= =?utf-8?B?a3dneW5hREh6ZXppNDFsTitGT2lueUZFZ3RMRkNCck1rRCtsMUtVeUZ0QkR6?= =?utf-8?B?KzBzU1VvdkpMVlM3Z0xGL2V4Nno4cUZMdm1xR0FmaHhsbTdpSDlWUW14M1Zp?= =?utf-8?B?cmU5VERSSjVmWnZDL2NMaGxUT1pTNUpzS0hnOFIyUk42Rk9HanhFU2hJdG00?= =?utf-8?B?L3lINHlxVXZNWUFvbGZSKzlLY2lCM0loODF2MlpyaURhNFBEaDFNbXExQWJs?= =?utf-8?B?ZHF6ZDBPREdkVWx6Ni9Wb2dzdWQrS1ZsK3FLd25lSW41TTUzY2pmS1lKaU1U?= =?utf-8?B?ZTEwMVZHSlZzQ2UrVEU5NURZbGx3WVppSmxUMG43d1JzZ2diNnh6UktKQ21G?= =?utf-8?B?VzdHTWxNMnhTUm1hNDliRlZwdjFQRHh0SzUyYkZGMWJaSEh5QlZZdkRnaWFE?= =?utf-8?B?Wkt2cEVqSUNMc0RTK0pwd1NYUWplMTEvL2E3UGlNcVRUaUlkU0JBa0FmSlcr?= =?utf-8?Q?AWl5Frf+7eMjilt6GTS1FVO9McyzYcVF?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OFBZWXZ0RnovYll3UXZiNzV3M2hNcXIzRnZobkRUeUJRaDJuay82WHNuSzVL?= =?utf-8?B?cHc2d09MNHh3T2FGbVRkNjFTVUhlTFZKdzlDMFdPK0pSY1FpYnBBa1RzQnB0?= =?utf-8?B?Tlk0emsxem5XQlovZW5zbXFhd2hNTDZJVWFSSU42TTF0MmpxK1ltMHQ4Q2Ni?= =?utf-8?B?QkhJRGYxdE11ZU5mejI0Y2s3MFhPNW1IY2xWYkliZ0dBS1gza3J5cnFPMVAz?= =?utf-8?B?MDZFbHgvSHpadHF6VjBhQzFPQTdPUnNIK0kvdWRvTkNmdEJVNTFYN0g5dTBh?= =?utf-8?B?R1N1SWZlQXNIZ3o3TmUvWjJkTUpUUWRaWnF6MWUvOStBSlhjV1YxTEYrSnJz?= =?utf-8?B?QnBOQXVXckFVV0Ivd1g5QlF1TU43SHVBMlN6enY1UDBZaDA3WEp5OCtjZnpn?= =?utf-8?B?RU5FWmV2SUxQZlI2MEdtT1NYZ0s1aElYMk5PUXdweWIyVHQ5LzBnUUxoZGFm?= =?utf-8?B?WFhTeitYYkUxK3B5S3dwRFFsbWJTSU1JMlp2ME01V1dkREZ4NzJwZFZLVVBV?= =?utf-8?B?djNLSDhNamZnNjNLOXhMaTdhS1lYTC9wM2VKeHNyWHZnTUtwK3luQ0xwVkhP?= =?utf-8?B?azZPNkNXSG9oT1BwYS9xSlZ3N3VQOFJrZlREVEN5TlBpKzVTK3Zma1J1bWhD?= =?utf-8?B?c0crbUY0Zys1Y1gzZ0lHbG1nYmd3Y3NTbUxoVXA3VFRTb3BsMkJTbVZVTS9h?= =?utf-8?B?blNLY0JzMW1jeTFBVlFtWjloTFVBSmdNMldpV1Axamo4YnBsclN2aGN1TTRJ?= =?utf-8?B?NmlIQm1iOWZOUkM5Rk1OOVhwa3d2Y1BvTXAwWTNOa3RBN2J4SXMwa0x3NzBG?= =?utf-8?B?SDNLVGQwbHhZWmNEVVYycVg2TDI4OVFoYjZaVElrVmJUdmtQNy9FOCtZeFRq?= =?utf-8?B?ZGhLd0RKc1hCMVVqcThhRGUveUNkaDVjV2hTaUxNaWxzZzdySVBrRDVOdHN1?= =?utf-8?B?cDF1cTUwTFFtWVNVVEtvWWNWMWdvRkxzck51WnU3MVozSzQyVnNlcEdpb2lV?= =?utf-8?B?OUhkWlE5RmVIdXVMdjhMVFJvWWdqYUdSZ1NYSW5rNmxheGxmQlRIRjFJcDQ0?= =?utf-8?B?RWF3aWN5bWxRa2dLcm55aUwrbjQ0eS9kdXhNOEt3TTErZG5ZUVIyaEZzcmlq?= =?utf-8?B?K2tYY3Eyd2t4QkgrZmYvT3pmT29IK3kvYTNpcHBtNlUwZUlDTStWNGRpVG9w?= =?utf-8?B?U1hqQ294MHFXOVVtOHh4bDluQ2VzUmEwWUJwU2RoRW5SMlkrRU9tdXpWOEMz?= =?utf-8?B?bDl2ZEltNE13eDAyajN2OGRVQUx3R0t4eDBlTlJuWjRuTGxlanFGdVhVVWhD?= =?utf-8?B?UGhqSlhFYXFOZjdMdkRhZjF3T3ErWmF2OFY4S3UrWmsrb3JEV29XNnZFUm5Y?= =?utf-8?B?WTRaYm5TZU1iTVZTWXJYc1BiaHBqNFVLOUlob0FyRjZqUTVob1kxeWxrOUV2?= =?utf-8?B?c2o2NWEyZ0loWUJZQVZHLzV6Q2J6L3NVNFlLMFZRVHE0U2dJWGZBbmxsZnFE?= =?utf-8?B?bUh2UGNvY09nTk5hdCsxSnk5eHNaTUdIcHN0Tk9TcnZUdzF2TGE1T1ZFZzRS?= =?utf-8?B?ckU2NzV3ZksxL3g2SG5jbnBvR1ZKZEZadDJ1THFoV0FKNnVVTk1oVHM2Qzkw?= =?utf-8?B?WUM5NVpnbngyeTNPK2treHVObmRKVjNraXBrRm5HOEsyWExsa3B6S1JBVjRD?= =?utf-8?B?QWZaU09RaG5YV3hQYThGcmx4WVpYaUJqeklHR252bk53SmxBR0NvYWlldUcr?= =?utf-8?B?K3h2a1VyNEczQjFtelFwR0hiNXJ2c1dDNlF6U09IWEVxU2JLOWgvaFZUYTFj?= =?utf-8?B?MFdjQ0poeEc1NXU0cmRpNFl5MStPaFkvYWIwekpDRmNXM2RsT1RTYUZRVFdL?= =?utf-8?B?bC9QNXlEZ2dhWVhPWFlLejQ5dmpIUXZOY2pEVHg1NXhNWk5OVlpOM3FSY3lU?= =?utf-8?B?QkxCb0pLL1RzdGM1cXhiNVB5ZStqN2RXV2JWRXQzVVR2Q29EbWNEMWdCL2s0?= =?utf-8?B?aHFCZllmQUp4Ulo5QUdiSENWY2xwTi9CQ3BZN0xyc3ZEWlcxcjN2d3pFSk84?= =?utf-8?B?WWxXTUhEYVE5TVpCOFd6c3N5RTFUQ1NHVDZDK3FpUCtFQ3d6K0IrU0NxNHU0?= =?utf-8?B?Qy9tU3lSWmhmRWIzUFNyemNncFpJNW42K0RidGVoa3lPSGRQOVB4WFE5R0F6?= =?utf-8?B?OEk3SlpHUzRUUTB3aUI3QVM4QldqS3BIWEw2WG5UdTI0SDQ5Wm1NVFRHN0Qr?= =?utf-8?B?alV2STNmVmNkKzVNZjNYSTBsN0drQUFjc1VSYlFYZnVnbVNDUDZsSU91SU13?= =?utf-8?B?ZVR3Sk9McXJDRFk1MDhibzNiOFE5WU9uSEFqczBkUnN1QVdGV2tjZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: c9223ed8-7a39-4167-3e87-08de4ed30d1e X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2026 16:29:09.9119 (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: vJkKUkXZdrSneFPKTjnqH9mhwEM7cHqS9OcA+MwCXUkcLFkITRs/UIcfWlBgkHuiTlonLZmS7XvJPjbITSz3rw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR03MB5287 On Mon, Dec 08, 2025 at 04:35:13PM +0100, Marek Marczykowski-Górecki wrote: > In an attempt to debug/workaround occasional console freeze, switch it > to polling mode. If that helps, it will narrow down the search. > > Signed-off-by: Marek Marczykowski-Górecki Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 08 16:51:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 16:51:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197849.1515238 (Exim 4.92) (envelope-from ) id 1vdtDt-000198-Sd; Thu, 08 Jan 2026 16:50:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197849.1515238; Thu, 08 Jan 2026 16:50:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdtDt-000191-Pw; Thu, 08 Jan 2026 16:50:57 +0000 Received: by outflank-mailman (input) for mailman id 1197849; Thu, 08 Jan 2026 16:50: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 1vdtDs-00018v-Hi for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 16:50:56 +0000 Received: from mail8.us4.mandrillapp.com (mail8.us4.mandrillapp.com [205.201.136.8]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3183e0b3-ecb2-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 17:50:53 +0100 (CET) Received: from pmta15.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail8.us4.mandrillapp.com (Mailchimp) with ESMTP id 4dn9rq6vzbz2K1rpT for ; Thu, 8 Jan 2026 16:50:51 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 88b4e5ae6d504fd791c0d9c8375d1a50; Thu, 08 Jan 2026 16:50: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: 3183e0b3-ecb2-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1767891052; x=1768161052; bh=7kSvgUZqq9JTtIB6SajetgP7V7nPzBwjE5AJMGZLkWE=; 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=l2EzbbAKnVCnT5X/nosRmCQO1n2jzAhVKdlCVOmaBhbel7DncXRcDBzi5jurkLvfJ TemQYYxISDLbDs4S2QG2XF21K3IHOaOHNLM+lQ5Xwqq6k+GXSu4qm4IN0ewtoiSY7i 2kffvqBiYTsCF2tPZN7Md24/rnDHDZEF5aFgLWltaS/wJ4AsdyX7QBA7dSSA5d81pc Pwtx85d2EM4mxR9tMh/Ks3pPC/d2Sdi4Kfes3DfzYpOSnpbY7HvMLC781PPIspYvlM AlklGZdhkGlXazzlvQL0oiHXfmCUEhvSqxrM1Gux8EAdJut9FjrWta7TbsO9le7fdT 1PNog47QDs4yQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1767891052; x=1768151552; i=teddy.astie@vates.tech; bh=7kSvgUZqq9JTtIB6SajetgP7V7nPzBwjE5AJMGZLkWE=; 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=RYa3d/lfAOiIYkNR3lvTfojOZQMgjaWIKEasREHtIMARu6lsaOep58aATYoHILw2C pKg62iaWEzcvHgx186VSn3bK+KlK5dpQu9BS0fk4HUyKOIOzkfcl0zXUzIiItEO5ow 6eIyQWEs3DavfwsMdvBEcKqb71dRCExVRWzPJMmyKjUNneSUEdvn4FsoDBnZOs8aEV NAp5/WifaIeTnitSTOxc1/6C9cbFvlq0Ea35VEp+ACGh2coObzZNNKMIUSv6gpy/dV bsfri85zESm3gimI4jIroZZ3WUVfcB99NIPc25gYYSAfjrEhihRJrlxWhHqJ+3Zk7w BBJv/03avSulQ== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[RFC=20PATCH]=20pvh:=20Introduce=20SIF=5FHVM=5FGHCB=20for=20SEV-ES/SNP=20guests?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1767891049478 Message-Id: <0c9c1dbb-28e1-479b-a680-e99150b3f0da@vates.tech> To: xen-devel@lists.xenproject.org Cc: "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Jan Beulich" , "Julien Grall" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" References: <3b6f5146287d3402a09836b7cf876d4f8dc9eee1.1766889890.git.teddy.astie@vates.tech> In-Reply-To: <3b6f5146287d3402a09836b7cf876d4f8dc9eee1.1766889890.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.88b4e5ae6d504fd791c0d9c8375d1a50?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260108:md Date: Thu, 08 Jan 2026 16:50:51 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 28/12/2025 =C3=A0 13:54, Teddy Astie a =C3=A9crit=C2=A0: > Under SEV, the pagetables needs to be post-processed to add the C-bit > (to make the mapping encrypted). The guest is expected to query the C-bit > through CPUID. However, under SEV-ES and SEV-SNP modes, this instruction > now triggers #VC instead. The guest would need to setup a IDT very early > and instead use the early-GHCB protocol to emulate CPUID, which is > complicated. > > Alternatively, we can signal to the guest that it is a SEV-ES/SNP through > start_info structure, which is visible to the guest early on. All SEV-ES/= SNP > guests have the GHCB MSR available, which can be trivially [1] used to ge= t the > C-bit and proceed with the initialization avoiding CPUID instruction. > > We integrate that to the PVH ABI and expect all SEV-enabled domain builde= rs > to honor this flag for simplifying the PVH entry point logic of guests. > > [1] Initial GHCB MSR value contains the C-bit. The guest can trivially re= ad this > MSR and skip CPUID logic. > > Signed-off-by: Teddy Astie > --- > Actually, C-bit itself cannot be a part of ABI as it is hardware-dependan= t > (and even firmware configuration dependant). > --- > docs/misc/pvh.pandoc | 5 +++++ > xen/include/public/xen.h | 2 ++ > 2 files changed, 7 insertions(+) > > diff --git a/docs/misc/pvh.pandoc b/docs/misc/pvh.pandoc > index 3e18789d36..6453ee21eb 100644 > --- a/docs/misc/pvh.pandoc > +++ b/docs/misc/pvh.pandoc > @@ -44,6 +44,11 @@ using HVMPARAMS, just like it's done on HVM guests. > The setup of the hypercall page is also performed in the same way > as HVM guests, using the hypervisor cpuid leaves and msr ranges. > > +## SEV-ES/SNP guests ## > + > +The domain builder must set `SIF_HVM_GHCB` in start_info if the guest us= es > +SEV-ES or SEV-SNP technologies; i.e requires the use of GHCB protocol. > + > ## AP startup ## > > AP startup can be performed using hypercalls or the local APIC if prese= nt. > diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h > index 7f15204c38..9b84df573b 100644 > --- a/xen/include/public/xen.h > +++ b/xen/include/public/xen.h > @@ -890,6 +890,8 @@ typedef struct start_info start_info_t; > #define SIF_MOD_START_PFN (1<<3) /* Is mod_start a PFN? */ > #define SIF_VIRT_P2M_4TOOLS (1<<4) /* Do Xen tools understand a virt. m= apped */ > /* P->M making the 3 level tree obso= lete? */ > +#define SIF_HVM_GHCB (1<<5) /* Domain is SEV-ES/SNP guest that re= quires */ > + /* use of GHCB. */ > #define SIF_PM_MASK (0xFF<<8) /* reserve 1 byte for xen-pm option= s */ > > /* As requested, here is how it could be used for Linux (the patch also contains plain SEV support). We check here for SEV-ES with mov 8(%ebx), %edx (start_info->flags) bt $5, %edx (SIF_HVM_GHCB) If checked, we then read GHCB MSR and extract C-bit from it and skip the CPUID checks. --- Subject: [RFC PATCH] pvh: Add SEV/SEV-ES support for PVH boot When running as a SEV guest with PVH entrypoint, we need to fixup the page tables to add the C-bit. Otherwise, the transition to long mode fails as the pagetables are invalid under SEV. Signed-off-by: Teddy Astie --- arch/x86/platform/pvh/head.S | 74 ++++++++++++++++++++++++++++++++++++ include/xen/interface/xen.h | 2 + 2 files changed, 76 insertions(+) diff --git a/arch/x86/platform/pvh/head.S b/arch/x86/platform/pvh/head.S index 1d78e5631bb8..2b4d58350346 100644 --- a/arch/x86/platform/pvh/head.S +++ b/arch/x86/platform/pvh/head.S @@ -91,6 +91,64 @@ SYM_CODE_START(pvh_start_xen) =09leal rva(early_stack_end)(%ebp), %esp +#ifdef CONFIG_AMD_MEM_ENCRYPT +=09/* Check SIF_HVM_GHCB flag in start_info informing us on SEV-ES/SNP */ +=09mov 8(%ebx), %edx +=09bt $5, %edx +=09jnc .no_ghcb + +=09/* Get C-bit through GHCB MSR. */ +=09movl $MSR_AMD64_SEV_ES_GHCB, %ecx +=09rdmsr +=09/* C-bit is in EAX[31:24] */ +=09shr $24, %eax +=09mov %eax, %ebx +=09jmp .sev_prepare_pgt + +.no_ghcb: +=09/* Check CPUID highest leaf */ +=09mov $0x80000000, %eax +=09cpuid +=09cmp $0x8000001f, %eax +=09jb .skip_sev_prepare_pgt + +=09/* Check for SEV support */ +=09mov $0x8000001f, %eax +=09cpuid +=09bt $1, %eax +=09jnc .skip_sev_prepare_pgt + +.sev_prepare_pgt: +=09/* Check if SEV is enabled */ +=09mov $MSR_AMD64_SEV, %ecx +=09rdmsr +=09bt $MSR_AMD64_SEV_ENABLED_BIT, %eax +=09jnc .skip_sev_prepare_pgt + +=09mov %ebx, %ecx +=09and $0x3f, %ecx /* Get C-bit position */ +=09sub $0x20, %ecx +=09mov $1, %eax +=09shl %cl, %eax + +=09leal rva(pvh_init_top_pgt)(%ebp), %esi +=09call set_pgtable_cbit + +=09leal rva(pvh_level3_ident_pgt)(%ebp), %esi +=09call set_pgtable_cbit + +=09leal rva(pvh_level3_kernel_pgt)(%ebp), %esi +=09call set_pgtable_cbit + +=09leal rva(pvh_level2_ident_pgt)(%ebp), %esi +=09call set_pgtable_cbit + +=09leal rva(pvh_level2_kernel_pgt)(%ebp), %esi +=09call set_pgtable_cbit + +.skip_sev_prepare_pgt: +#endif + =09/* Enable PAE mode. */ =09mov %cr4, %eax =09orl $X86_CR4_PAE, %eax @@ -223,6 +281,22 @@ SYM_CODE_START(pvh_start_xen) #endif SYM_CODE_END(pvh_start_xen) +#ifdef CONFIG_AMD_MEM_ENCRYPT +SYM_FUNC_START_LOCAL(set_pgtable_cbit) +=09.code32 +=09mov $512, %ecx +=09xor %edx, %edx +.L2: +=09testl $_PAGE_PRESENT, 0(%esi,%edx,8) +=09jz .L3 +=09or %eax, 4(%esi,%edx,8) +.L3: +=09inc %edx +=09loop .L2 +=09RET +SYM_FUNC_END(set_pgtable_cbit) +#endif + =09.section ".init.data","aw" =09.balign 8 SYM_DATA_START_LOCAL(gdt) diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h index 0ca23eca2a9c..c1a4e3dca0a3 100644 --- a/include/xen/interface/xen.h +++ b/include/xen/interface/xen.h @@ -654,6 +654,8 @@ struct start_info { #define SIF_MOD_START_PFN (1<<3) /* Is mod_start a PFN? */ #define SIF_VIRT_P2M_4TOOLS (1<<4) /* Do Xen tools understand a virt. mapped */ =09=09=09=09 /* P->M making the 3 level tree obsolete? */ +#define SIF_HVM_GHCB (1<<5) /* Domain is SEV-ES/SNP guest so require */ + /* use of GHCB protocol. */ #define SIF_PM_MASK (0xFF<<8) /* reserve 1 byte for xen-pm options */ /* -- 2.52.0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Thu Jan 08 17:18:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 17:18:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197880.1515247 (Exim 4.92) (envelope-from ) id 1vdtel-00045H-SX; Thu, 08 Jan 2026 17:18:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197880.1515247; Thu, 08 Jan 2026 17:18:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdtel-00045A-Ps; Thu, 08 Jan 2026 17:18:43 +0000 Received: by outflank-mailman (input) for mailman id 1197880; Thu, 08 Jan 2026 17:18: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 1vdtek-000454-Ne for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 17:18:42 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 12627b46-ecb6-11f0-b15e-2bf370ae4941; Thu, 08 Jan 2026 18:18:39 +0100 (CET) Received: from BN0PR02CA0060.namprd02.prod.outlook.com (2603:10b6:408:e5::35) by LV8PR12MB9136.namprd12.prod.outlook.com (2603:10b6:408:18e::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Thu, 8 Jan 2026 17:18:34 +0000 Received: from BN2PEPF000044AA.namprd04.prod.outlook.com (2603:10b6:408:e5:cafe::33) by BN0PR02CA0060.outlook.office365.com (2603:10b6:408:e5::35) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.4 via Frontend Transport; Thu, 8 Jan 2026 17:18:34 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN2PEPF000044AA.mail.protection.outlook.com (10.167.243.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Thu, 8 Jan 2026 17:18:34 +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; Thu, 8 Jan 2026 11:18:33 -0600 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 8 Jan 2026 11:18:33 -0600 Received: from [172.27.233.189] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Thu, 8 Jan 2026 09:18:33 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 12627b46-ecb6-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=sBeRhnb/5LHlINSyvlai1Vsfy4T2GVDoXaz2EKn5z+4fViweQ7iyGMJqnt+kCYWfUvYV7lCnuAbZztIppEYikPqc7c/NMJRTNxs43zr4V3jkgzUuSqup4N+rfezAfLEIvPrit9ZBagwn5k9gzNWOOdfky7VLf9Jj1ueVMTt0sm+MWUipDaHVlmsHD1YB/0XaZh3ErY5PM9Qdc9yMNgZZPJPnT+6TEr736StEEWTwQRhJ+FnizT3DtuqYT+JeINBkuaD27izta6a18fqHN4109TJSjNgSUbGUBeNtQdlDBkh7rtJcJ/bGBdbmaFydHX9JbfzXgnyVm8DV7qzJok2m4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XNHy6dwqWztWz+1vfSEuUKorK4pasF/z7XeKyakB4ic=; b=MfKwP+VhOYx/t3b6ZXD8EutbVVW9tHbYj9f7oolvi80YCTYew4gHAQHiFyNNc+3jcN8Qyn397pWEJw7SVz7sS6SxIGi357JRnfAY017pBi0EJsp0hwP/731sWlR+bnrwHDQIxVuKalQqfiROC2i3dM3Xx1mkt+GWoOtEE5c5iwEHfDJjIj5Qzlxxv3IAbMTWsxGDKQcplnTMW0/1xOCE19KQbZ5P7Wr7ZLlGluIg0/8bzToiLlpTPSItfVwl41jShGjLFqKONJLQWxuF/92zMGntqdTOno3VPZEjySNh/EgNlYjuEJcZ/nGmglrqEeSA4cv2jpnhy1zXvzUp/w9Quw== 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=XNHy6dwqWztWz+1vfSEuUKorK4pasF/z7XeKyakB4ic=; b=Kz8jeaW2zL7U8/wedW2OSjP+Zb1SmfdDumTF2c14EF1ager32Z686UafHd8hGBOHfxX3/ucArnKkk0+nUJeIMGmUaBeF4oNwjafHkiXj4AtAR/gl6zChJftCnuu3FwPygC3RESzYWbXnFTkiutC/6Pxe8r9F4beyddiHPvOKUyc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <40e8c68d-350c-4bfd-8eb8-3eccb81cf427@amd.com> Date: Thu, 8 Jan 2026 12:18:32 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] 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: <239a5d80-c0af-410b-a053-5fa84273aecd@suse.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <239a5d80-c0af-410b-a053-5fa84273aecd@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: BN2PEPF000044AA:EE_|LV8PR12MB9136:EE_ X-MS-Office365-Filtering-Correlation-Id: d2eecf6c-5e62-42eb-a126-08de4ed9f41c 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?V1l1VFB2K0xrcGVYVEhsQXZlNHVNUCt5K0NpeXpSYTNNWko0eGhzZThlcXJj?= =?utf-8?B?L1RZYUJsQTJsamk1RDdyRkdMWFNEVnVWeThSNDZLbUoxTzFKQUxzOUZIMHdn?= =?utf-8?B?cGVyS1hsVHRhdmhFVGp2SkJkSWI3N0tYZFd3Q3VlZy9JVDBnOXVIK1dmaEVo?= =?utf-8?B?TGJLUzJkWVpHdCtGb05iWjdRanpHVDNrZmJyeGIvY3J5cXRHVlF1cHZOWDM5?= =?utf-8?B?NTNXOHlQWjJzVUlnQk04d1czQlF6SUF6eVlEY3lKRVJaZ2hvKzYxNzlvTGxl?= =?utf-8?B?OEVwdE8vOTBpMWpUTnFLMjZMYUw3N3FNTDFwSWZtOE0xZ0NNUVVvY0hkbWMy?= =?utf-8?B?UDFKQTNDdWZNaHhpc1hMTHhxVjc2OVkralh2ZkxkL0lMejlyWGZVZlZtbnlM?= =?utf-8?B?bWtIM2IyN2lqVWJEMTVvMUF6VkVjU2lzUU5HM0FBK0s3Z2RuZHZLVFQ3dEg2?= =?utf-8?B?VmNid2toQTdtcWlpY25FaEpOcDRjcFYwaVdSeHo0ZGJ0QmVuQS84eTR4ZzNS?= =?utf-8?B?Rjh5YzBYMVFvTHV2SUg4eDhKUkFHNTVqalk3RE1ubThzY0JEeSs4U1A1QlRv?= =?utf-8?B?VzVQK1hVblNKait4Rk9IbWhDVWM5c1dZd0VVT09nZUtjUjRTcW83Q1BnVG9k?= =?utf-8?B?TUt3eUZvc3RGTjBxQ3lOMDZOVTltTUM4UVV5SzNjS3RuNnhxMjRXT1dvSzZD?= =?utf-8?B?VStSR1ArNENtRDhDTndialdzeFBRWmVheVJQOWdxNTFKRGlHRVBDM2NzenZv?= =?utf-8?B?ZmFuTm43Q1AwQ3ZvZGRWMkVuNFFjQS9PMmRDR3BnMDVPa3YrTzk4cG1vSk9Q?= =?utf-8?B?U0ZMK0Q3dS9GRWdiU2VOZXVteUZaQzVJeVY1VUtOMS9rWTdPd2RWMDFIejNq?= =?utf-8?B?YllBdzVrRkhOM01HUE1jT1VTWU4xUThSOS9oRXlXYXVRTnhIb1VrUjhvQmdR?= =?utf-8?B?dFhlV3IyWHQwMzBXbXNVQlRPMTNCdnhCKzdvaytxY2Q5b2NZMXd1ZWxybWp5?= =?utf-8?B?cER1ejZNYUU4ZlNEZUR1QitLSG9uSU9pMWFtYVMyaDY0ZnMyRFFUd3Vva0RB?= =?utf-8?B?MHpSNTFpQ0kvTU5rMDQ3SE5qMmJtQ2dSUndIajdRbmFGeDNzbzdSK0k5ekV2?= =?utf-8?B?WWpkOUVyTnBwb2xxa1NKVHJMZGVSdHV3QTJRdkxBYVUyOCsxbXR1aFYzOGhn?= =?utf-8?B?RVdpcmZFODRRcDdET3Nld1J1WFhRc1I3aVRjTGduN0xaelY0L3ZaWHZ2ejNj?= =?utf-8?B?QW8vOUo3OTk3WjhvSk00TVdvK0VLL3FOU3ZhQXhKU2RxK2tjVXFBNnpWTjlt?= =?utf-8?B?b3RndVVXMGlhUE1hcmNhWHMvRnZ4NW1aVmEzNlQySjdsL090bzJ5M21nU0xs?= =?utf-8?B?VHdINXc0Y04zMjEzK1lreXRabDRCNlFzcjI4S0FGRTJoWEVLaWpBY1p0VCtC?= =?utf-8?B?OEltY3hKcjRRNFArYjhJZmdCUlozVnFlUml0a21CdVUvdGpVTU0wNkRKRmFj?= =?utf-8?B?YWtEVDdhMm1PY1JSUWdXaWd0VFhwN1RKWjhpY1pnUXFRSzY3QjJNc1h6K3Uy?= =?utf-8?B?UWZ5dWRrbmMvNEpuL1B6UUMraWIrbEVkRlNuVjdTNHdyZ3JVWHl2OWRHZjEy?= =?utf-8?B?Y3BGNWZvVHRtaXJLZkVLWDVEVmZqV3lyaitmUGxzalpWMnhMM1hUYXhka283?= =?utf-8?B?S1U0WGNIaE5qRDVEaXVSMHNrVURFZ0psbGFpd042eVpmM0VNL3FpQzJNMlNF?= =?utf-8?B?N3ZSaEhSRkpIWmxYeXdLTGlJZGg1bTVySDN5Q0VZRDVCK1prTDAxc0NMWkZ1?= =?utf-8?B?ZlhsZ2NVbHhSM2dxZzBtRjZXSFJtQm5jYW5UcDVkREZYa2s0MnpPbldjNW4y?= =?utf-8?B?VSt6dWdJdHlqZlkzcmpBam4vY1RYWjh6bm1CaFJReitnODBoeTJTVkZxUVht?= =?utf-8?B?dTVjZWJ2Q3hvRTR0aEdmYjBPaElXeTN5SWJZZm52Yy9sRjRNL2pXU3duSndN?= =?utf-8?B?Ri9IeFd0elAzSUdtSjVtWFhBcitOcUhONmJHQ052WFhpUkFrd2xKTGl1L0RG?= =?utf-8?B?cFZqbVRVZWtHbXlPYUdUV0lRczZ4VnhyZGxzVlhVbWQyVlBIclBzcXhBTURa?= =?utf-8?Q?DFtU=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(36860700013)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2026 17:18:34.3146 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d2eecf6c-5e62-42eb-a126-08de4ed9f41c X-MS-Exchange-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: BN2PEPF000044AA.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR12MB9136 On 2026-01-07 09:11, 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 Reviewed-by: Jason Andryuk From xen-devel-bounces@lists.xenproject.org Thu Jan 08 17:44:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 17:44:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197916.1515257 (Exim 4.92) (envelope-from ) id 1vdu3d-0007sa-T1; Thu, 08 Jan 2026 17:44:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197916.1515257; Thu, 08 Jan 2026 17:44: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 1vdu3d-0007sT-QS; Thu, 08 Jan 2026 17:44:25 +0000 Received: by outflank-mailman (input) for mailman id 1197916; Thu, 08 Jan 2026 17:44: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 1vdu3c-0007sN-CV for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 17:44:24 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a9b7de87-ecb9-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 18:44:21 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by BN9PR03MB6202.namprd03.prod.outlook.com (2603:10b6:408:11f::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.3; Thu, 8 Jan 2026 17:44:15 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.003; Thu, 8 Jan 2026 17:44: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: a9b7de87-ecb9-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lFDNwVjsTGpOTwlWWRnEK7npt6y/Sl0ImWG71YIRjJHmSPFyj6nhnH+q0ToAFBIoDPbBrxZOyRklFuux85S6pFuCW6xzKcedsMTMGNWKwQRKiPa2RBw7JqNS2lmK7Enfg5GJYRddFW2sCauEkzmdI1fx3CSMy9q35FmnKDWo3aAP8mNJ238d4VoEcY5RReoQRPNWLE51fmIAoM4oCSZBJ8Xl8RpHjqu8NP31kLgeTkERNzTucm/Ick4thQM2/3+AldaIU+/t7Bk7k7ZedvWRdII4RiSwRMq8jcc+Pspz2D9W51ub2TwljeH7pqgEJmEWeFu2swGooQEUZhstEDRaLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LJcyTYY54PKC5kcMbnAZ52VQGc1qgvdmB5zg6R1ivj0=; b=DytjvfsVoXb8GP0tozYs6WaaNPgb/8UBFqEbjFGo+pMwxbeKHgzjUs5bvj7e9rwJFlAOeffB+tbXEcODKlj0aCpmO2l5MJeujjgSexMRB6YlpJAhphpgCQyjQUvx9X2D1RsfHO/cfweolqVXwwbTY8VqrHlrqHNuZWtb/Tg3xJRYt4TNygal9P5JS1XTTPfucvdU53pt8XlLIAxm5aVE1e1Gv1xbv0ZR0MPKiF6H7xZNdZnUD6PjoGsxweEdj190tftOe/MYOsu6sKWCrtbGVwtrKZyWRY/2MsxPxGaJxZJKPUE0idhjmwsYI8f0jGxbbzSyxGU2CBonvAjxlSZIFw== 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=LJcyTYY54PKC5kcMbnAZ52VQGc1qgvdmB5zg6R1ivj0=; b=fcjWImnicnpnRfnBlLGJZ9E1N6MpLs9YGm7jDXsjchNGd0kZLOLG/LUdUE8NOdrdHs872cvZfK6/7NlKUYorQga5KdMtFiu1bWgHq+FAQPNTx/hxWpYHLQBFJZAVs7TqaB5yzXPQp3gM/skYmNhLPplSXK8esq1k7T2XQswGKVg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 8 Jan 2026 18:44:11 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Teddy Astie Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: Re: [RFC PATCH] pvh: Introduce SIF_HVM_GHCB for SEV-ES/SNP guests Message-ID: References: <3b6f5146287d3402a09836b7cf876d4f8dc9eee1.1766889890.git.teddy.astie@vates.tech> <0c9c1dbb-28e1-479b-a680-e99150b3f0da@vates.tech> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0c9c1dbb-28e1-479b-a680-e99150b3f0da@vates.tech> X-ClientProxiedBy: PAZP264CA0244.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:239::22) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|BN9PR03MB6202:EE_ X-MS-Office365-Filtering-Correlation-Id: 9e79262a-bb38-4470-ce95-08de4edd8a5d 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?c2FJcDkzQlBzWFVzL3h0VmhRb0psWGJualhyQlkzbnRtbTJTYWJwSjQ5b01m?= =?utf-8?B?YUFrUWZJOEpDZEJzSmRIeVhhNXByQ2h1ZUdRRTZlT2dJVHBhWWhnR2hLc0Ri?= =?utf-8?B?eXQ1L3Y3cnM2b0NOa09QTHI4ZnpjSmJpOElZSm00R2NNMm9rSTRVS3pMR2dU?= =?utf-8?B?SjlyQkdHNXVrcC84dlM1YTlQeUtObGRtZFNydld6dFNHM3piVTA5dW9zektn?= =?utf-8?B?UEdZSkYzOTdNczFHRFo2a3dLSVNPay9OdzB4UTc5SFFndWRwM0ZvNlJPSkpO?= =?utf-8?B?eExDMlFrdnJHaXZTbnlmWG9qQ0owMkJjQi9jK1lYR1huNjlMcTlzKzJKcEdp?= =?utf-8?B?OGw4bzNNeUZzdm5FYk1lcWNETC80bXF5NXBjZ3Q2WDZrbDZoZWkxeVpsR2c0?= =?utf-8?B?VnA4QTR1QVNmZ2RLTzc3OE5qN2QxN0FkUnpiWEZGUm96YmhwNWpSd3dHVTBY?= =?utf-8?B?NXM2LzR1WG9Od2J2dWp2REVMSVZQYS9sTDhSRlREZEhFUE5RT2VXcDhjR3Jk?= =?utf-8?B?U0V5UzFxdnVuNW9vMWpNZmozYmhHL25rOHpSeWdEUUQ2NGVZN1FzY3BMaUFm?= =?utf-8?B?T0FLc05FeTE5amt2dmJkOTNCTGVFSXRrQisxRWJNbHpEbDg3WG0xNHU5SFMy?= =?utf-8?B?T3JETWgvZUpNR3doYTV2VzFmbHZ1VjZIaGtGeEkvVFNsYXpQWUMyVTNQTXJR?= =?utf-8?B?YmxhcGVDQ3kvVUVwTlZ2b20wSkJ2bjAwRkRyQ0k0NWh2N2IvQTlNeGpVWVdu?= =?utf-8?B?UFJLVmhiK1l5T2VkRTd1Q253dTN6bjdFUG5WQkh1K3ZCRGpWV1grbzBHdXBx?= =?utf-8?B?OFVJUnh3Mk5BWkZEYTJ3ZVdCaVpDUzljUDVVSjF2WFUzdVZTRjFrUDlSVHVD?= =?utf-8?B?MUtmVkc2K0lBQWhHay8ralNkcVg0NmZ2bHE2UGVuK05MTmVkVkRRZUMyeVc1?= =?utf-8?B?Y1VlVEhUYjcwUSt5MEIvOWFzYWhZbnZ0anVkUWRQRjRHTWNRUkxSamtUS251?= =?utf-8?B?VlUwZCtFU2d0YnhrckZUc2ljYURoRUtwaGJyMmQ2b3A4bjM2S2orN093cEpT?= =?utf-8?B?cGthejcxNG5sWUhQY3gvVVU1QVpUckhtc2FiZnpIWWgvMmt6SjJEOGZrdkNu?= =?utf-8?B?NjNoQitZbUtRQ1ltRmlpSkYrYThtOHpmeVoxYTg0MlVlU3F0QThGdGw1d2Ns?= =?utf-8?B?RVhoeWtiYTVsYXNKYjBnOHYxR0ZVTldxd1lSeXBxZ1RhUWRxUUlkYVF6UHZl?= =?utf-8?B?QkdWZ2VUaXhoT3FuUVZtb2k5NnljRU16MWFrUnd5QlZoUWUyMkRUTnBvV2wx?= =?utf-8?B?c1hzcGFTdzBPU0VPdWUrUjVTZUM3UjZpeUpCc3BHaEdBVHp1WHl4K1kwcmpV?= =?utf-8?B?N0NmUExhZThoa2hMa3pTV1gxSUpKTkdBWGZpRk9TS255YndXRjJsR1pIN1pD?= =?utf-8?B?Nmt6TW1oQkVoNHlEYkJ3eVlKQWJxR1pqQVE5dHZaVXQ4VmtMQSt1V1JVSmV3?= =?utf-8?B?YVUrQnIybjEzcmNVelB6aDJZOHUvdVhzTjNEa1VwNG9VeXowYlBQbXdQdExw?= =?utf-8?B?RVp1V1pWNG9QV0FQSXdQS1k2ZTY5NkdHRlhna0V6ZmhnMVhqTHFyUFpOTm0r?= =?utf-8?B?eURWTytmaWsxbmNOYk85TzFNSWx3U2xyNzdockNiRCtRa1I5ZVcycEZBOXZC?= =?utf-8?B?UUVOM09TSjNteFFEQ3JxZWxyMmhFa0hlRnV3Wnl2aHpxcndQT0FJNHJUNFZ2?= =?utf-8?B?RWptQjJ5cmg5M2lIa0xlalFpVFVPdzhDZFB2NHJKb0x5RS9LSGpaM0Z2UFdx?= =?utf-8?B?WDdCSmh3MUhWb2YzeXk0amUzdVV4cDZsRnozaTgrRmR0QmJiRGpINUp5OWlQ?= =?utf-8?B?UkVuRXgyQlBTc0U0MmxGM0tKVDkwK2NlTWIwSVhuN3JOTHlwME9JYWFmSlMz?= =?utf-8?Q?TtIFMBZ5HvZe1zqE5c8rlMTmvkgIYxmB?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dlIvbjMvM1FFd0Z3RlFhYVZ2VkI5bGYxY2FVdjVIVk5RdDBjS0M1Nk1ud1Q5?= =?utf-8?B?aS90ZDFtcVNjMFhVQk9QQm5SNzViU0Y3WGhWRGJJQkZ0MytpNE5BZFZTbjFD?= =?utf-8?B?OGsvTk41RlBvZmsyVHdXTjA1VEtwTjFkUWR4Zksra1dZZVJuYWc4aFBkYi83?= =?utf-8?B?aVYvbUtOQTNjazIwRDBwenJUQ3IwWnp5TGtNTGJVS3dhRWlhbXhtMURrZEdE?= =?utf-8?B?SVZkRVdsdlRzQVVHSGxVUWZMOVVUdW1SZElEb1I1eVZ0ODVIb3VoU25ZRVR6?= =?utf-8?B?Z09pZUc3dkN2Z3d5ekVJaHh5VTE0cEdrNVJVRDVua1EzV1BRVWwxeFVGY1lh?= =?utf-8?B?WUZWa1Q5WTU0THZtUmpqb1BRQ3FOd2ZyOHp5bmtORFZaRkFDUWV3N2FrWlpo?= =?utf-8?B?dXJ2c2NneWhLcFFhK2szRFFoNnBPcDdMNnBaWHcrcVdSa2cvd0p6anNNN3ZO?= =?utf-8?B?RnlQTXhGMFNNSDVoRitON0VPM21MbWlhVjJwNHpkRHVHK2tMOEpTZVhKZC9m?= =?utf-8?B?K1BTMEVHWVJ3VVRGcDBCV0FjS2VrN2ZMRUpjUmlYWE9DM2EyVWNSUnYva1Za?= =?utf-8?B?emJNWDZFSFM1ZkFlcjJMQXFpS0paMVBSM1RNU3M1ODhJSkxocktyYWF4YVJu?= =?utf-8?B?VDZUMGQ0dlZNUTRGYnNFZk5DaFZPaXR0YURPWGo1M25xOFY2aWIyRVQwalZY?= =?utf-8?B?cHRlVkREOEM3dVBsdUNVVEZvNnVMRGNXVkJOUFRUcS9nNHVxNW9nQWpkMjgw?= =?utf-8?B?YW1JRTJyblV1YWk2dTNUakdBa3BFZ3VJeG1PNXV1M3ZUdVpFMy9wRlpnMUhM?= =?utf-8?B?bHJyZUNSdDNRZlZDenQ1RkFsd1ViZGxnY0xrb1JiNzhBMEE2MzlvZXRvaVdF?= =?utf-8?B?cUd1MlQ4NS9VTkU3eC9HUWNoNzd3QzZ1em8yYlAvVm5yME5qY2JnUG9RaUV4?= =?utf-8?B?Q2tmMDFkNmhhQlFMdHFrY2R3U1czcitZVlNpTm40ZWdaTXFoVWpDV0p1ZWF3?= =?utf-8?B?cDlaeVdZd3ozWjdaL0xqWm9Dd3pRY09qaTd1blNMT2JLRmFaSkNWOHcwQmtN?= =?utf-8?B?ZEdtZ2Jxa0FyRVUzL0JhcHZTVDMyeURhL0dLSXd3cnplM2lmVjRuTXFodytC?= =?utf-8?B?dCthN1V0V3ArV0VZUnZHUmd3a0FwZGplVGVqYXh1VXhRQjQ0OVoybTgxRVlX?= =?utf-8?B?a1lXZm9qTmZiRWtEQVRhUEZ5OGFMSXFzbDgwNWR3Qkdyd3QxRTRMYy84d0RS?= =?utf-8?B?eUI4dXdhUmdXOHNid1hPRE1HcEZ0bnp3UEpOZUp3Q3lubFYwdmdMdWlLQ3Fr?= =?utf-8?B?dmR1emxFaThoakt1STdqUEdheWNKSWJHQ1l5aHVVQ2I0ZFpoci9HczVBZEJU?= =?utf-8?B?OGZtNy9ubE9lc0F4Rlp5RVdqaTFWZHJNeGM5ckQ4bmZMNm9jbE9hVHFRV1dz?= =?utf-8?B?NW9HNGdQTitLS3dPWXBUY2xDVjA4ZkVpMDNVellYNHVFVElDQU5VRGNPL29u?= =?utf-8?B?ZjA0b0hySUJpQS8vdzBqQklaKzBjOVNDOThab2d4clRxMk1FUFlwK2s0VVF6?= =?utf-8?B?SnNXZFUrZ2IzMGE0am9pTzZUZ2Fudys2UzVBSE41Q29pOHJhUHlBUFlmaVZy?= =?utf-8?B?ams4WFRDZ2N2SUFxUVJ6U0QwUFRPUFlpM2ZFanRBVDBuVlNTY1ZCY1diWE43?= =?utf-8?B?M2RZU2FuRWNiZERDOW04RG50elRxdVg4ejNJcXgyMnBMRC82ckZ3Y1pOWHJq?= =?utf-8?B?elJyUFBKZmlEcCtvem9HQzN1OFpEa0tFL3JLNHFURzR2cnpHVGFDeE5TVi9Q?= =?utf-8?B?eC9aSzZaQWpXb3NPSTVXdW5MM2V6TEFvcGhDUjhVdlgybWNvSHA5dWV0ODVk?= =?utf-8?B?ekxkcElMVlh5c0htTjVQWG42MG9seGNwK0tLQWcyWWdYZ3JTNWJnMFVVM1VE?= =?utf-8?B?TmNDVDNFRCt3OStlMkNpa0ZCbGtubExKWGhhNll4NmRCTmI0dGs2Vmx0UkZw?= =?utf-8?B?cnh6b0Y5OUJySjFqdTJlbzc0bGZmRWJlNVVsZlNUTlVQci8xcWJVc3ppbWtK?= =?utf-8?B?WGxQNnloTkd6Zk5ncVcyRmQ5T1l6ZEZGU1R4RzZFYy9OL0JxN3cwQWMvVzNo?= =?utf-8?B?eHVucTh0MU1xbXVITHQ0YndHcHFwaG9yeGd2V1gya3ZlUlhiREFXaGdVSHJx?= =?utf-8?B?K1FkeVd4b2xjN1JWMkxobHRXWUQyS28rUVJWNmk5a2pNQnNhajg4NWl4M09R?= =?utf-8?B?Z25rbHlIS3lxaWRnMCtMNUJVYTZhakEzQ1pkcHppdzBweUZNWlRqNW1zcC9U?= =?utf-8?B?MmpFRTRmK09CYzg3TVpESUpHVjZIMFcrV3h5NTJzNmt4bUJFSlgyUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9e79262a-bb38-4470-ce95-08de4edd8a5d X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2026 17:44:15.1759 (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: oN5C6Jq0J1Suj0Z/0GNERLT+Q1+tAMZsZ5Ul6tekvFQMuVvZU+h5PXqPQZYEW5ktQdqcitwU8q5ePfl/DxQSUQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR03MB6202 On Thu, Jan 08, 2026 at 04:50:51PM +0000, Teddy Astie wrote: > Le 28/12/2025 à 13:54, Teddy Astie a écrit : > > Under SEV, the pagetables needs to be post-processed to add the C-bit > > (to make the mapping encrypted). The guest is expected to query the C-bit > > through CPUID. However, under SEV-ES and SEV-SNP modes, this instruction > > now triggers #VC instead. The guest would need to setup a IDT very early > > and instead use the early-GHCB protocol to emulate CPUID, which is > > complicated. Possibly a stupid question, but how is this information expected to be propagated to the guest when there's a guest firmware and bootloader in use? How is OVMF and/or grub propagating this information between themselves and to Linux? Are they relying on the CPUID discovery logic mentioned above, or there's some shadow infra used by KVM for example to already convey it? Adding Xen side-channels when there's an architectural defined way to obtain the information is a duplication of interfaces, and could lead to issues in the long run. We can not possibly be adding all vendor SEV options to SIF_ flags just because they are cumbersome to fetch. I know this is just one right now, but we don't know whether more of those CPUID options would be needed at the start of day in the future. > > ## AP startup ## > > > > AP startup can be performed using hypercalls or the local APIC if present. > > diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h > > index 7f15204c38..9b84df573b 100644 > > --- a/xen/include/public/xen.h > > +++ b/xen/include/public/xen.h > > @@ -890,6 +890,8 @@ typedef struct start_info start_info_t; > > #define SIF_MOD_START_PFN (1<<3) /* Is mod_start a PFN? */ > > #define SIF_VIRT_P2M_4TOOLS (1<<4) /* Do Xen tools understand a virt. mapped */ > > /* P->M making the 3 level tree obsolete? */ > > +#define SIF_HVM_GHCB (1<<5) /* Domain is SEV-ES/SNP guest that requires */ > > + /* use of GHCB. */ A concern I have with this is that we are adding vendor-specific terminology to what should otherwise be a vendor-agnostic interface. There's already a fair amount of arch-specific information encoded in there, so maybe not that much of a big deal. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 08 17:56:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 17:56:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197941.1515278 (Exim 4.92) (envelope-from ) id 1vduFV-0001Ia-4b; Thu, 08 Jan 2026 17:56:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197941.1515278; Thu, 08 Jan 2026 17:56: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 1vduFV-0001IT-24; Thu, 08 Jan 2026 17:56:41 +0000 Received: by outflank-mailman (input) for mailman id 1197941; Thu, 08 Jan 2026 17: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 1vduFT-00014Y-Sb for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 17:56:39 +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 6119d25b-ecbb-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 18:56:38 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DS0PR03MB7280.namprd03.prod.outlook.com (2603:10b6:8:12c::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Thu, 8 Jan 2026 17:56:33 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.003; Thu, 8 Jan 2026 17:56: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: 6119d25b-ecbb-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ofSAmoLf2q0PdiS18M30QYAWfDXcWhWtfbwf61E1JCfIJv/FEaBpTZR7zixeOZGcdlMSD3LsR1keKGGDbp4P6eTOJvwbi/Ml5NCwGeUUHBqpytxn6aiJlB1DzB9sEFOUD6S9YeFl1jAj+0leNfh2Lo6ayIawstCv35rgW/xvxElsZXxgp1suHsBx+VisR49VVfyPi0XQ/G2uWzhHhdxfXllyEro34FjaFxTrufOuIC3ZFN7HxW532uy6holqmcK84S0ATdLcYsUjnHslFn3aocUrTzuPNdQiIoFB5y81W/MnFZos9wrIshsBsy86pnf5IpelqT8axbtILF/pNqAmlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uEiGmtpnHYUxAMzor9yJzVzpxxC+/PYjhnu5IaklfEw=; b=AC9j5UeAWYt/gkcVSP2B5LQOnvM5XCTBlKF1AR1+oVnhDMK+l6PUX26UMozIwrUvoe9QSJsuKRpRn8t+Qmi0tgpPzFragw6TBkoX7H0BzKPkG0/de6mOPOjYkvk8qQjHl6GQUj/+F/ioVVZT7a3E+ERGZrfYtaL9qciBQ4mbe50MV7Yx52OKZAtcwk+8Dd1nbZZP5Cbaa7f3MByJnT+0KDVquGHf5bhyShu3gYX6fILXCW3HyHJ5DWtceGFQTigXInuR+fsLppgzTXTuxHg7gd/vSbrqfwwzJE4oZmj3fbBMgV8x5Zs2BBk/gkVGLhDM9i8kPT+krg/C53FoPMgq8Q== 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=uEiGmtpnHYUxAMzor9yJzVzpxxC+/PYjhnu5IaklfEw=; b=By/6qH56LXONF2ptQH9gfiUbOdAnGFsPXLZxjdWVCdngrLlpAFtZJQiy4M7yChk3HCeXQyF1tTWXI9ZZnchrm4QVfaNDhbmt0OBhtAQLSa59r4fezBMZ45KH0add2HyFKmrBMtswgE2669GQcEf6XgwHHn+Z6HYpk7PDFQL2bSc= 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 , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich Subject: [PATCH 1/2] xen/mm: add a NUMA node parameter to scrub_free_pages() Date: Thu, 8 Jan 2026 18:55:35 +0100 Message-ID: <20260108175536.82153-2-roger.pau@citrix.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260108175536.82153-1-roger.pau@citrix.com> References: <20260108175536.82153-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MA4P292CA0007.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:2d::12) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DS0PR03MB7280:EE_ X-MS-Office365-Filtering-Correlation-Id: 2ad45a24-e377-4326-f1c9-08de4edf4275 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?QWE1UWJGa3RwMG1xZ2d6eTc1d0ZhcXMxVGc1d2dsUlFvS25NakdzT1hZeFlY?= =?utf-8?B?RXpZbmVWblB1RnlnZTFqbEdYVEFvOEZyWGU5NUlkMFRWandBMy9uZGgvZU5C?= =?utf-8?B?RWVBLzlnYkNXZVRFSi8zKzQyQkFGeklLWlhjREgxTHIySmxaQUV0KzFrN01P?= =?utf-8?B?emdSajExYTNaNXBrM3h0U3AwUWh5VGRiSEZYN0pUR1pJYk41UTVvQzAyajBQ?= =?utf-8?B?LzVpMThGd2g1YUYraEc0SHRhVHVvemtQTUdqRmJ1Q1h3d3ZQVjRueE9zdjhx?= =?utf-8?B?cmVoaktDQ1NZdHF0SXB5aGVCM200Wk9vSSt4Q1p5Y1FDeldmZi83MEN2U2tS?= =?utf-8?B?MHVER1hJbGpMa0VhbUZ2d2VWakY1V0xHbFRLRDFaOHptbGlkRHJudXJaTjNp?= =?utf-8?B?WFlXZmRHTkluRzlGRllBMFJPUTJEbHlTS08vSWhFdkEwYi9iSnBUVFhwMjVw?= =?utf-8?B?WXB1OWJmUTNwckc2UEgyZVRMMVBTWWxxaFp2MmwvSUxVa2xBZkRQNVRoV25s?= =?utf-8?B?bjVsRERDaDlXQ01SdGRlR2xva2MxWUZXeGw2elp6REhZL2M1MzZWQmJrWDJo?= =?utf-8?B?WG5wcU5NeGxhbWY1UUhtY3ZxNlJGYUhYek11NElXZUJtU2JaU1Y3WmpUckZL?= =?utf-8?B?RklpR0kwV3RTSlZ0VEo0WTB4d282a0lzSFhaRnBOY0dXM1VBUk92VlprdHFR?= =?utf-8?B?Y3llK2srZkhDUkFFRWNGNjhWc2N4cFowOUlQYkR4OWthYk92WklFZ3VUTGdl?= =?utf-8?B?Wk1KSk91bFB6WFFRS3l3WUdQcnpWWmRkS2s3WE4zNGk2SDlvR2RZY3BNclVU?= =?utf-8?B?S0xqVG9RTjF3RHByck1Oc1oycmRXMkxDenJpZGhhbTFJMWN0NCsrT3ZVdkF5?= =?utf-8?B?bnp4TlhkditzSkxTOVVTVlJuZzRteHVRUlpaelpUTVV3NkFuMzZISjQ4REV2?= =?utf-8?B?OVJnYzN0ZGNPRHgzQjZocTBNL3k2UWw1eFVpelVHNGJRNXlaMUUwd3dMWXlq?= =?utf-8?B?eFBjQTVpbEMyZTdvVWgvQ3h3dWhyVVNHVVpRdXRReG53a3RrZGlEWnkxVDFz?= =?utf-8?B?YlUyNHNJWVdGa1IrMUI5LzMvaEZmUER3MkVtNG9KOGtZNHRGdlNGWEFBaDJz?= =?utf-8?B?WHJ6QVlWcWVueUoyV2VnVzRzM0x0dlh0UW9wRzF5YWpoYnFaeEROdG1qa3dY?= =?utf-8?B?dDNZT3AyNUNvdFZ4TFdwRE1WbEZqWUJsZ1VUVDBON1g5cmdnVmd6NjNaR0xo?= =?utf-8?B?RG14T1JtVWwzNDVRNk5GeFFaY3R3cFJBTmFFSEd5cHN6MFhIZ2syQmFxVlBV?= =?utf-8?B?eG9qQ2ZjRVdhWllKMjZhWjNjaDQrcXpGMFFlYXFtdGxiYmdIYmR5cTFQelF5?= =?utf-8?B?ZjgxQUVCNXVUcXFJNnZ1cjI2TVpRamhnQVhTWGpSYy9JZmFIVEpSUDRoSUsy?= =?utf-8?B?bWtWUVN0dlI5V1FieDhqSkJMQm04ZitsbXFvajV6clJ1dmROYTc3UExpdDAv?= =?utf-8?B?QzNacmcxRjlMQ29pR1FsNjk3RUx2WTVJMkRPQXFQWXZnRHBlWUthYjdCcGZN?= =?utf-8?B?QVVmSHMxSTBmRnBZT1F4TE1VdU5tWStHS2pLdDFGRW05d1FIelIxdk1INjlE?= =?utf-8?B?RkVSY0lZZmZWeXJGYXJBczMwcWtUc2pCanlCM2hGcmpqMUlZcHlJYmJaSUdQ?= =?utf-8?B?TDRDNDZESGY1Qm84MDI4QWZZc0gyTjNVQ0lkSTV2dkNMTjA5eWdzcngzVnRz?= =?utf-8?B?QlVpQjV1UWlQZVIzTndEWHd1YXN3MXFXV1gzS2VPa0owZFZLN0c3NG40ZHFl?= =?utf-8?B?SnRZTDBDTlhjbU5WSWtsdFp1T2gzY3YwdEczY1Q2OVMyME8yWVg4eFpPbXMx?= =?utf-8?B?QlIzL1lFR1NldVNkOTV2eVE1ZTR3ZnM2OGw3ekErVjZ3RmQyWmEzVmZoQ0x5?= =?utf-8?Q?4Og5HwSeT1WbNhMJGhxUu6OpZwNNNLL9?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?M0tpRmEyUHc0dXpnejVCZElUZHRRSWRQcEFjWEJBR0JQMmsvRTkxVkxPR1NQ?= =?utf-8?B?aGdXZTRWVlZPZ3lxQVNtRzd4NlVvcW5QcUd0OTM3eE5aUjVrTDNQWHJCc3hx?= =?utf-8?B?MWVSMEorTHJ6bUFHS0lkaDFpeGwrSW9WMHROblFzNytWWVRaVURidFFKL0tZ?= =?utf-8?B?SlNNVmlRMlJ0bXNaUTYyaDIwYml2ZkNML1dKOEl5Tkw1MlhXNGYxNE5iUGdB?= =?utf-8?B?NDY4ZVdIYVYzdlZWb0JlaU5nUmVMTHpyOU40bjgxbURVS3kyMUYrOEhyMVFU?= =?utf-8?B?dHdZTHU1MW9vVC9KS0xkdGlEWVdwcURGWWdibEVjTEpOc2s5TkdXV1BnSVBv?= =?utf-8?B?VUtMUzlGRUZEVis1UDk0aHNNR1pmVnpneHI5ZHRyTmZjcjBnRnJxNkVaenU3?= =?utf-8?B?elpqVVp4ZGNpQnFsVUxLRGNDOTdrb1YxaXdaSkNxazZMMUx6MlRtQ1FmVXJR?= =?utf-8?B?SXNFKzNtZ3duazhFL1lnYlhoKytvRDRWcGFldVAzVTNFWHF1MjJhSXRjUUFt?= =?utf-8?B?N1dLaWRDaGZhdTE1NE50TnhwWFQxMS9zZmNPUHFUL3N0am5XSmlBS0NqRWc3?= =?utf-8?B?UVU2M2RsTStYU3VIdXNUSWh6QXZGSThsek5Jb1ZZK05JUnY1Z1V6d3BqNDJS?= =?utf-8?B?SnF4aW9Qb0xpTTZpL2xkSUVFcHZYVDk3NHJlZDgrMEp0VCtSV2RGUVNtYkJn?= =?utf-8?B?VjV1L0ZDU3hkUmZUL29qU2RXZEYvTnBXeGVLeGEzUU1RQ2l2Y2Z2NGw5Z25x?= =?utf-8?B?TTduYkhnSFBJN2xxTmdYVE9GZlREc0dzTTYvakdySG9PcGdBTVdDdFZDM1pM?= =?utf-8?B?dlFhTytEeE9ncEZUOGVSSlpxYVdFMFZkUkd5ODZlQjJyZXdxQmRwWHRxNEZo?= =?utf-8?B?QW9xTXN0bGlqa1VlM1pZcUNSQ0RSdDFZTVBCWVRDSTViaURlVXZuUzVnOCtP?= =?utf-8?B?bWQ0QXpEOEMwZ21PQkNOckhudTZaUGlFU212a0I1M0t6U3pUOWlwTnBudzI3?= =?utf-8?B?aksyWERNYWtCdHl4dHMwak9lcHdCWnYxWkNLUjZhcnpGWldkQ1NHQlBadDg0?= =?utf-8?B?dkx2QnFRdnhVV0FZVHRwRUp2a3FKd2g5UVJwS24zWnBTMmZzTFo0Ky9YUzFH?= =?utf-8?B?Q0kzVkYwZFEyRUd1RXpScnNvWmZvcDI3bTJ4RGdBc3JpMEdPQ0NPSEU1L0Ru?= =?utf-8?B?MzRGNW01NFNUMGhmQTdZTDBvU291WmhtRGI3UWNzYldaR1RXWU1DeUtKVWVL?= =?utf-8?B?Rm1KSzNTdjV5TkZUZGp4MVFRUlFvQ3B4UEdUWmNYTlRSV3ZueVZXc2xwd3Fo?= =?utf-8?B?ZGtmSUJwUHNkamQ1aHlSUmtkRzNQV2N5L2kyZmdENjlkRmFlNURoR0krbTQw?= =?utf-8?B?R05pRXNmNVVtSmpxbTdhRHhmV1czcmZSZUUySHgrOFhQYU5zRWcvdjg5Nldy?= =?utf-8?B?c2FvN1FrUDEvMmZhQlBIeTEwL25JWmtWN2FrU2FObG1MSFFwdWh3djJDQ1FR?= =?utf-8?B?SVZnd0pQQkR4NWt1VEt4eHZTVjRZVVkyTFRLQ3oxLzBRUVk1UlBRZWtqSVdT?= =?utf-8?B?bnppQTZIYzlXbld3WkhNSnhscHNEVXBJY0M2N0NFenhzTnZqSFRHZlh3SDFx?= =?utf-8?B?ZzBHamlpRitUWWNIaTJBd1BwOFZnUnFMUzJ3ODdCM3kvNTIwN3BFQ1AzWlVz?= =?utf-8?B?ODVFQldnQzhNUmtUb2MxYkxvMGxzUmlXNEpGR2k3SmVGNCtWUlVPS1hFU1g3?= =?utf-8?B?S09SL1dFME9BTUFvUWsvaW1ndHFuZmYwSlFxNDdMeVpkem5pajF6S0ViaFhp?= =?utf-8?B?MFRaSHlMVHlzODFqVlI3U3VyVGtYZ3ZIRDlTZjFZWnlodzZ4YlgyV2pyQkVR?= =?utf-8?B?R0xFaDBRdm9hTkpKL0JOdzloMTl0M083bHRDYjVXTW9Gamp5VGUxeDJwdi9P?= =?utf-8?B?UmNleGwyeUgvZTh0d1RKUFZtWlBBOUVBOEZNQXJBcFljNURJNTVuZmxoQnVI?= =?utf-8?B?RSswL3FiQnB6TDg3endJNW1aUlZTMkxLaXZIZWRnWW5HRGNSQWRJM3ZqS2FT?= =?utf-8?B?SmxXc3gzS3ZMU2RON3FicEU3Qk1XK3ZkaGNhRkllQm0yWGt1YnhldEU1NGMz?= =?utf-8?B?SEwzdlh4WkZxaElYZ2ZGTUMwS2trMHkyM2JuaWhIREVBcURIV2tqMjJsMnF2?= =?utf-8?B?NTYrcHZUQ2J0WjZFMXd0MWo1cjc5bTRpVWxVQTE3azY2YzZmeHozQU9MUVRF?= =?utf-8?B?eHB1czFNNDYxaHpqK3U5dG1aU1dWQjlhMlVuUjlCMmFGdlI5MXdPbGJRdVZ2?= =?utf-8?B?S1VhdHhnSHM0QUZDRnR3VjcwemowcnMySW9EZGFDcmJ0VXRFTWYwdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2ad45a24-e377-4326-f1c9-08de4edf4275 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2026 17:56:33.4910 (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: B439DyXzxnlW9Rg4sWi1gRHVCU7MRT7/vdfgLPQ3kswtcHSdodzSlEmS7fR/fABaAlWze/7cAUBt1ZSjxFf1Dw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB7280 Such parameter allow requesting to scrub memory only from the specified node. If there's no memory to scrub from the requested node the function returns false. If the node is already being scrubbed from a different CPU the function returns true so the caller can differentiate whether there's still pending work to do. No functional change intended. Existing callers are switched to use the new interface, albeit they all pass NUMA_NO_NODE to keep the current behavior. Signed-off-by: Roger Pau Monné --- xen/arch/arm/domain.c | 2 +- xen/arch/x86/domain.c | 2 +- xen/common/page_alloc.c | 17 ++++++++++++++--- xen/include/xen/mm.h | 3 ++- 4 files changed, 18 insertions(+), 6 deletions(-) diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 47973f99d935..dff7554417ea 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -75,7 +75,7 @@ static void noreturn idle_loop(void) * and then, after it is done, whether softirqs became pending * while we were scrubbing. */ - else if ( !softirq_pending(cpu) && !scrub_free_pages() && + else if ( !softirq_pending(cpu) && !scrub_free_pages(NUMA_NO_NODE) && !softirq_pending(cpu) ) do_idle(); diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 7632d5e2d62d..276c485a204f 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -166,7 +166,7 @@ static void noreturn cf_check idle_loop(void) * and then, after it is done, whether softirqs became pending * while we were scrubbing. */ - else if ( !softirq_pending(cpu) && !scrub_free_pages() && + else if ( !softirq_pending(cpu) && !scrub_free_pages(NUMA_NO_NODE) && !softirq_pending(cpu) ) { if ( guest ) diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 2efc11ce095f..248c44df32b3 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -1339,16 +1339,27 @@ static void cf_check scrub_continue(void *data) } } -bool scrub_free_pages(void) +bool scrub_free_pages(nodeid_t node) { struct page_info *pg; unsigned int zone; unsigned int cpu = smp_processor_id(); bool preempt = false; - nodeid_t node; unsigned int cnt = 0; - node = node_to_scrub(true); + if ( node != NUMA_NO_NODE ) + { + if ( !node_need_scrub[node] ) + /* Nothing to scrub. */ + return false; + + if ( node_test_and_set(node, node_scrubbing) ) + /* Another CPU is scrubbing it. */ + return true; + } + else + node = node_to_scrub(true); + if ( node == NUMA_NO_NODE ) return false; diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index 426362adb2f4..7067c9ec0405 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -65,6 +65,7 @@ #include #include #include +#include #include #include #include @@ -90,7 +91,7 @@ void init_xenheap_pages(paddr_t ps, paddr_t pe); void xenheap_max_mfn(unsigned long mfn); void *alloc_xenheap_pages(unsigned int order, unsigned int memflags); void free_xenheap_pages(void *v, unsigned int order); -bool scrub_free_pages(void); +bool scrub_free_pages(nodeid_t node); #define alloc_xenheap_page() (alloc_xenheap_pages(0,0)) #define free_xenheap_page(v) (free_xenheap_pages(v,0)) -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 08 17:56:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 17:56:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197940.1515268 (Exim 4.92) (envelope-from ) id 1vduFU-00015I-0H; Thu, 08 Jan 2026 17:56:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197940.1515268; Thu, 08 Jan 2026 17:56:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vduFT-00015B-RT; Thu, 08 Jan 2026 17:56:39 +0000 Received: by outflank-mailman (input) for mailman id 1197940; Thu, 08 Jan 2026 17: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 1vduFS-00014Y-1h for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 17:56:38 +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 5f3530b8-ecbb-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 18:56:36 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DS0PR03MB7280.namprd03.prod.outlook.com (2603:10b6:8:12c::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Thu, 8 Jan 2026 17:56:30 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.003; Thu, 8 Jan 2026 17:56: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: 5f3530b8-ecbb-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=EfYFPNA7m1z8GsR2AuxL3InBeulai2XHmwv9+ur2wcftbYFyy4FtPklQ86eGNq/zSZ53k7IeyJK2pjz2gssDJM/zh27x7SDjkjmVbiEbGok+vBE4xTp7TvUZqemgTFhoRUeTqtUfJyauJWmCJWk3Shu3Xs2csSlj8OCmaN12Fc2HDgdcFbBEbZePMpbrHQDxJ5mzpgC21UJUSSwY3SfwtcG3qthnLu3VNbZpVPVg/XPets0AvJ0y2vMGndQhHI3FzLziR46UTvBe9MCL0VkBUFVPSJNuTI+eMkuY1XVdIYsMC4LHKlkWzpfntosGkI67bmKKXERVHqtaIlby0Ctx3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dHF3JH2r9EdzeDRKKZ9IR6O2GGBdfVMXJ85DPH2YZJI=; b=gG4/CCnW9w1VH3qOKaT3PwYgKTfeqaJOBoPnNy0BlqCdrcr4go6fNYrhURPV0yQ0CZCSRx1hxsSkepm3Z3oX0zFVwZtuePKJBJKmTV2Ph3IDu4GQQnDCU+Upft5c78mB4NAeh8D9kUBmMCtn/sn6vc3bY0yHqAajAYaU5mY72WlBIvJdgwhO/Gd5CUk2oWn0IyvvBt4EbNf5FZ8gxoPr69lVjLIqRxMGXNoYIjfilVm3XhbCkRpgHn1rvBkvlxTmyAfkOhW80/2RHiIEwRYnvYlB6BXViwltbSIsAx+Y2+/7dv5mntwoJ+ekm2zGkzmIlDMMsFU+QP5+navPcMa9yw== 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=dHF3JH2r9EdzeDRKKZ9IR6O2GGBdfVMXJ85DPH2YZJI=; b=Lo3oZtmnqUK5RjwVzafaDGXRcYdRoYNsS7/sh5eE3yBhia1Dkp24Dbj6mDkAOQ97i0i6LzSzPUD7UgxmvoWVBLuWUjqOlzYB01RDFqNRBF3xLSrXJa5LyOij1f7dm3aJ0kW5/stNikkqNe2wHjU+QofF2/r7Z60uYrkNxREv+Vc= 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 , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich Subject: [PATCH 0/2] xen/mm: limit in-place scrubbing Date: Thu, 8 Jan 2026 18:55:34 +0100 Message-ID: <20260108175536.82153-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: MA3P292CA0026.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:47::11) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DS0PR03MB7280:EE_ X-MS-Office365-Filtering-Correlation-Id: cdc9c191-d247-48b1-d667-08de4edf4090 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?NTk2QWxVTUt3RDFzaGJmS01zS3JhQ2dqcmdIaW9KR08ySGVidExNM1VtZEl0?= =?utf-8?B?QVRjSDNqQWcvbUJqSGNFVGxPTFRrRUJ4WHAzNENvZDVqQVZLYys4SUpReE9n?= =?utf-8?B?dFFDejVqdWR0ZS9LYWx6TVlNWm85ZUJBaExGOFR5ZXNCVCtDMzFmdEpiV1h1?= =?utf-8?B?ZUtNellDNGJ0OExzM3B6OExqQ3p0N3FUWU9zUE83NHpmeHhRTHNGVFdJSTNo?= =?utf-8?B?ZVhCT2ZUMDZvUnRQcTkxZzZ4a29OLytHVWUxT1NLTUFJTzdxQURtbE54VmF6?= =?utf-8?B?dU1lMm44cGZMTHNVcEEyTnc3NFFNcHNwd2lWcTBESUxSVmk3dXhETlRtNGwx?= =?utf-8?B?VTREN3FUWTVQSlRzbmZXVmNYVHBWdVc2S1BiTXdHRGpRLzc0QTJPeW9oYlZq?= =?utf-8?B?ckZaZzdXVEMxditCZHE4emlSQW9GRlBCc01GTEErK0JNWW9BNDA1YWljT1Vn?= =?utf-8?B?Y2VxNXpHU1l6b3lKQ054QlRKZU9ObHFZZE0rSFdPdmhFb29LN24vOGl3V2o5?= =?utf-8?B?RjNOVFlKUEFSTU1XdXFhWUVFSGNXV1NLRjRoU3VrSXBSbW9Vd0pONGFlYU9W?= =?utf-8?B?dExoMVowMzdxZ2ZKbXQ1QkJjRzhvQ0diS0dPOWFlMWkyelZlekovMWhoZW1K?= =?utf-8?B?T1Mwb1d4SFczbHBWUHBTV3RjNDk4MC85SkVPVUlhOGx3TzczaS82M0hYK0hB?= =?utf-8?B?V2g3cEJ1S05wOE1sSDlKaWNZRkp6WW5Dc3NYVUczZkxNK1I1RjMwRlFsYkxk?= =?utf-8?B?T1FXcXR5WVIxQS9YWE42RlFFVzZ2WHNpRkVaUUZqTlMzZ2lYNVNOMEVudE80?= =?utf-8?B?WmU5c3ozR1FQZzQxamZXemErWWtuMWNIbjdLMGxqdFNVL01OaitSc1Q1QXMx?= =?utf-8?B?RXlwVVBlSEROdzBVUUxwSG5NWno5dnZqeENPcWJCWlQwSlZvbGhJL0QrYm9M?= =?utf-8?B?bXJsLzJDT3p3WS9DN3BXTG5BeGpwQkI2TVkvQXM1c1MwVUlXb01pZW9MQ2RV?= =?utf-8?B?eVVJWUhjZXEvN2xGaUcyV2cyR251RWNlQ1BLanQwUWRxb0NXTCtFMzVPZkxZ?= =?utf-8?B?MzNnSUNHQ0VPNUxaLzhsSWtOSTkyKzNzZk9tNjFsRUovQ1RPYWsva1VQSlVL?= =?utf-8?B?d282Q1ZDMmFmQy9MMTBxMWcrNnY4NFB5Vis1NE1hcTFCcUVlcDZEUnFzbmEx?= =?utf-8?B?Tk55V2FnNEE4Rnl4ekhGOHQvOWQrRWZGMXRnejJCRi9SOHRTd1l1WmUyMmc3?= =?utf-8?B?dWR1OTVYd28wbVBOTHdDWHo1Y0hQeEU3U09KZS9xZVhaMCsvL2w4d1FDTnpR?= =?utf-8?B?OFJadjRvQU04TlN0Mitmd0hRZ2xieVU4WmhES1ZjM0ZVM3BpWHpTbUhBUjB3?= =?utf-8?B?ajF1bmJseXNhM2dsMGo3SngwYlRnVjZxRXlmNHFXN0FwdmdFVklOajlHdldJ?= =?utf-8?B?R21EU1A1dHl5clE4bXd2bWVIK3l0Q081VGQrUlhXQXR6QTNaSTk0cHBhaW9B?= =?utf-8?B?WmM3My9uTEsxbGd5bkR4d0crNFRxcUdEU0w4dGNtMmg4WXRyRVZlekJaUWta?= =?utf-8?B?SXJUZ08xT0oySzhOaG9ONmdkK2I2c3grN3QxZWZ2VmZ5ajhLMXc3bEIvbGc1?= =?utf-8?B?c0JYTWE5QTJLenRXZWZuSUZubi9PSFllNnpIUVhxQnZodndlaW51bm9ZSU9O?= =?utf-8?B?bk5nYmRRaFMyNGZIWStDQUkwbFBLTEd4MTJUWnNNUC8wY2tNVmpndlpqejA5?= =?utf-8?B?dVlnUDc4bWhwV080NUNwTkFsRkp5eVIrSUhCeEZSdzdNWHFXa25YQklpakJS?= =?utf-8?B?d0tZWGRFR2VkM1NJdTltaXZiUCs2UGVZc1pJc01ocStMZEZjZTI1THU5TVJo?= =?utf-8?B?L1czaVVPZEpZTFMvV29kUHJqSGJzYTJhOVliVVQ2bjFkTlZkS0RyM3drVlZo?= =?utf-8?Q?Gzzl0Cskkrs/oVPo3evwIRF0XXbbAGRp?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WSs3MXUvYkVhU3cxQ2lRS1dPcnd6eTBzaGo1eUtGZ0djUy9UaXYyQnpOVmJP?= =?utf-8?B?dU1VbkNCbFpZY25kZnBqT25JNE54Vk1vNHhBSE9oRnVwaTg5TERMUWVjekVj?= =?utf-8?B?RFp6aGROUzE0WWtWcldGYTdWSFhIQlQvdElkZFhZZ3AybnZmKzdoeHIzVS9r?= =?utf-8?B?WW9WaWhGYTZTZmpkSUMrY3RsM2YvV2xpUFlBdzJHako5cmRWcnlUY2VuZk05?= =?utf-8?B?d2ZoMzRoY1dVa2JhemFCNlZVMHlQdkVuV2Z3R2tNQ1ZOaWRFNDFYb3o1Z2xy?= =?utf-8?B?RFhNMTVuRkE0ZkFBaVBCZXN3akRjRGhoWWJTZnlOYk0vV2FZTmxFRW94Y0pz?= =?utf-8?B?NmE1VlRYdDVLZTlzU1cwM1F0QXo2SExHL1JpaG1VQWRabUhMUjlTcnM5UDU2?= =?utf-8?B?RnVMTkZTdFhtYUoydnozYjFVYWVJN05KcWdzbGtxbGxSM2RpcDV6dTR0d1Iy?= =?utf-8?B?QXo4WFRrSmRJeUtnNGppdGlISDFSVzhGcURZUXZScW1vN2JTRGhQSkFST3J3?= =?utf-8?B?Wkp0dGlRa0h4R1Y1NEl6MlArZWovS3IvTWw2Y3NTajFTTEx4ZG1ranlmVGhh?= =?utf-8?B?SytsUnZRZTZoamFRWUJpN0lEaGJ6RW5wSzM1TGJ5RWExRnhNRXIxMnZPTm8v?= =?utf-8?B?VjFWcUdqU0MvNjhaZjA4NmFSdGt0N0Zab21uUktJQy9HZGxnNjZkWWdNT1kr?= =?utf-8?B?dWN6ZjlRYW10bDJwaFFYMU9lRHBlc1pVZzZpS25QcGdMV2FVbTlDZGFnTnV4?= =?utf-8?B?NE90dkN5K0dBUUF5aktKRkhNOGJkc2RYQWkyVmk2ajcvOHIwbHBFTFlBM2VZ?= =?utf-8?B?b3ZwOWduSS83dkZ0dWR0VGROVHJUNjBZYThnUjhRdnArS2JiUUdISHBNODJZ?= =?utf-8?B?elFyOGxDczl3TUpTak9SSUI0WUMxeTFQS1drUGI2YVpWL2l6dGlFK2ZRT05v?= =?utf-8?B?Unl6MU9paE03aW14WTJ5RHZxOXhQZ2YrRjkyek1mc09BajY0cFNRbUxoWWhG?= =?utf-8?B?bWdZY0IzSW9rNVlJbGZtS25ydmxVWTByTDNWTnlCZFF5Z0VmRUdDVVhQQld1?= =?utf-8?B?cUpnSC8vLzR4Qmx6UEd0TlR2NHNMd0dXQVhCUG5CTkppWDZlQ01tcWlpSDVi?= =?utf-8?B?YkM1QlN5a1FQM0hiYzJLNFN6Y0xaeFhKeXNFZ3pENlZldWZ2RWQ4ZnJTSW9n?= =?utf-8?B?NHk5V0ZiRUg2Rzd2eDhUeUFTTkVjb3ZOeUpGUXg3MlhNakJQeC9RbzdvbEZY?= =?utf-8?B?SnYxdG5GakdLdzlFdVdhcFJzVWlyN3dHTkpDaTh3Zzc0TlkxZUN6WXowZ1gr?= =?utf-8?B?bEpsVy9QYytoRlE4emk5TFVkMC9ZaDFVTjErTUs3YWRoeENvTmxNaTczaXpD?= =?utf-8?B?OUZ3ZWlvTEZVUklUd2xOWHJTYmJ5blFwSkdHVzFrczV6NUxpWTQ2NnVOWk9D?= =?utf-8?B?U013VGdUN2Fjbi9kN1BFVnIxQU1nb2JyNS8vYkpzQWRrR0R4YlJrK3Fvank0?= =?utf-8?B?TFVhaXJrZ2dYRmhGVTZZR3FjY3lCWHo4YWtSWkdtRHdSdUhSTmxFRXlSMFI3?= =?utf-8?B?di9CSGJkdzFHTTE1dFUwZTRIUWcyMXY1ZmVtLzdpTW9HYlZ1NGczcTV3Zkds?= =?utf-8?B?YnAvOXBEdVZVc0p4NUU2MXB1dXJOOHhkeGNMd3pxQ2N4TjBzT29rU2tTS28x?= =?utf-8?B?WEJFT3NvRVpNZzROc21uOVNscVhZdEtLd3loa3d0OU1DNDgyZEtESGlSNzNN?= =?utf-8?B?d0dtMXRQQTIxajhmRW9zUkJ6a3lJcExBSWlIaFlxWVVyRkI3NHZjMUVadlpr?= =?utf-8?B?cTV5RXQxbEVhcnhIQTlGMktIbms2VkJPbGR6M1l6d3JnVzFiMkZOMGQ1ZlRt?= =?utf-8?B?QlJWYk9PVytmdllnZVZGd2VGS1phckFEMmlENGtNTjRISGZNT0wxd0JhUllm?= =?utf-8?B?dW41SEtUNGZmWURZcWFoZnp3anoyampmbFJiWHBIYkZZZldQR2o1ZVBmNGRI?= =?utf-8?B?ZGwwNVdTbFNDYlIxQ2JtV2NCa1F3ZE92a2lDblB4d1NudXdqNEQ1dzNYT0FK?= =?utf-8?B?WGxtVWJNSDc1UEgzQ0tOMWVPRG4rYjdLOXRiRk1HQjFuSGNyQzlJelY5c0cz?= =?utf-8?B?bVVGVmtyOVF5VnkrOWFGK3ZNVXcxbW5VNTd4V1lsWEw4VjI3TlFLQ25WNEdE?= =?utf-8?B?WW9aTFU5YVdnMHlGdWVzMW5KNFp4SHltb0dZaU9weUR2VjRaaHFUM3dtOHhX?= =?utf-8?B?UDkxV2dPTDdzVDBDVkxXaW45V1NqU3BMcisvZ1lTR1JDU01FTENaNjIrZVFK?= =?utf-8?B?VnlSWVkrZmo3djJuYXNOdWE5UytzRjdneFBuMzBhSm8vdmNmZWpqdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: cdc9c191-d247-48b1-d667-08de4edf4090 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2026 17:56:30.3473 (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: K5XRIlI6OlTtPNIGL+oaoDdjFgbak2ZqIhi1G4IenmcKRHT4E3JZWYHJI2gpMx4+28R/tjwra9cvtV40CWbjEw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB7280 Hello, In XenServer we have seen the watchdog occasionally triggering during domain creation if 1GB pages are scrubbed in-place during physmap population. The following series attempt to mitigate this by limiting the in-place scrubbing during allocation to 2M pages, but it has some drawbacks, see the post-commit remarks in patch 2. I'm hopping someone might have a better idea, or we converge we can't do better than this for the time being. Thanks, Roger. Roger Pau Monne (2): xen/mm: add a NUMA node parameter to scrub_free_pages() xen/mm: limit non-scrubbed allocations to a specific order xen/arch/arm/domain.c | 2 +- xen/arch/x86/domain.c | 2 +- xen/common/memory.c | 12 +++++++++ xen/common/page_alloc.c | 54 +++++++++++++++++++++++++++++++++++++---- xen/include/xen/mm.h | 12 ++++++++- 5 files changed, 74 insertions(+), 8 deletions(-) -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 08 17:56:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 17:56:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197942.1515289 (Exim 4.92) (envelope-from ) id 1vduFX-0001X7-HB; Thu, 08 Jan 2026 17:56:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197942.1515289; Thu, 08 Jan 2026 17:56:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vduFX-0001Wu-CX; Thu, 08 Jan 2026 17:56:43 +0000 Received: by outflank-mailman (input) for mailman id 1197942; Thu, 08 Jan 2026 17:56: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 1vduFW-00014Y-1x for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 17:56:42 +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 62324028-ecbb-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 18:56:40 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DS0PR03MB7280.namprd03.prod.outlook.com (2603:10b6:8:12c::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Thu, 8 Jan 2026 17:56:37 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.003; Thu, 8 Jan 2026 17:56: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: 62324028-ecbb-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iHtcB3QTZON/mkBv8o7h/UnVzTSarJRYI/oqJvu9ZMllEUiy51gIhw2+I1HQlOPCta0hcVKr8GxY5gwDBAYksV3xj10Qx75q/kq9gP7l2eLwTPk7qCi6wjglCI9vhJDvrrsFJSjtDZT355WuglZB0pBXQIGD+9mJdmlgFsNE3abm4X57SJEUCoHe5JlMQkF+PThqrduIxaXMKGCKVn4KVjrF3apHqZqgP87sh9IrnT0K4yksxH5F6SVbA3HKHeIAI0OhUA5ly76lwRUdLfegJ7E7OWo+b4P5qnyL3X872TIOlQUfWfbabbCPRlWo2k0wm78OQICXJjx1DDVvToIesw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qLeYbeiYVBzspwgvGufcYntDd4XSAjSRXDth92loYbI=; b=eDTZJEMWuXuSgHsFxvHF5kl3OavfxE/nxOZqRTqKE97DKbWHPce+Cl75nmZ0fOpDO5x8M0Tuk37iT9yX3UsFm3WITISFoo+CfCElCmvJrF5MXi6EhURg9yrwYQKig0CryvVJjSS81ALlihDF8lyRvi0qv2VqxmmnwRlmqbrKDLW6t8nyGKfHhdl85k4MWHrTGoZi9pmtM05tbC7UVwccM1X+llY4aFk7ieNQBhi/Vqpv3z8iljVsqgQYrxAqwMKJOp9iNT5MVZDoCPYO+34VoRlCzvGO9FCUFNuoA1aF2DX7BP+6yVe78wNBp6VEEYXFDti0j26jf+/NWjIicM4k+A== 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=qLeYbeiYVBzspwgvGufcYntDd4XSAjSRXDth92loYbI=; b=SH/cIKFbRuLAS9+ZnwP+Vc+EvyoVG4MKisAjmb7921FQrF8oMolKrFa/dh77ZFYpcxyfcrOUQn4khM5AnBabeF548mrxjZai1/MdCmol3JEEHoGRC+zQ1KowUfUNfnNrKHiBcfN+BMBOsSaW96yIaeDx/7b7oik3phN6N+PRJMs= 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 , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH 2/2] xen/mm: limit non-scrubbed allocations to a specific order Date: Thu, 8 Jan 2026 18:55:36 +0100 Message-ID: <20260108175536.82153-3-roger.pau@citrix.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260108175536.82153-1-roger.pau@citrix.com> References: <20260108175536.82153-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MA2P292CA0023.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250::18) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DS0PR03MB7280:EE_ X-MS-Office365-Filtering-Correlation-Id: 1cfc125a-9c3b-4dc4-f0d2-08de4edf4493 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?NWtlUHZnNEpnYzJxYXlPQVQ2b1RhK0hEdUY0ZlhzM0xCTmZwcmIxaHFySm90?= =?utf-8?B?Wm5yNVdXd3g4N0drTmZXekJ4d0d4VzQwSlA4cmlQNE5YWDI2eGc5MnlaOGxR?= =?utf-8?B?TU5uYkZmaklUaWpnbTRpNERUbnRZUFdnVDRYVUdDc0JxZHV4ZmpzUXVZT0Q1?= =?utf-8?B?ME1vaFRtQ2M5TUtPd0wrQktTSWdPd0RhRG54MGxPVjV3RVVnUzRwN2hqNHVy?= =?utf-8?B?UXpPUUNkNDM3MTh2dENGN0IvZ3UrZ2NMcHRyR3NWenFkRmg4c1Via2lFZjF1?= =?utf-8?B?MTNaQ2FWRkFpMzBwYy9ibVNiRWFiYkpnL2x3OXRtMXBUaTVpYTBpbTJjUUZp?= =?utf-8?B?UXBCUVhqU0hxYkZqdUZWdGlJdkJvSG43SjlYNHBwSkU3ZXJwRWMzdi82bG5l?= =?utf-8?B?Z1NUUW1QMWcrVVgyYzZWWWRDZXFQejFYc25FUmkxZytNbkxpdWovaXFXcEls?= =?utf-8?B?bkd0OWI5WkZvRExHOXFEdGRQMVByOW9pa0xvUEVSNUhkRGgzM1czNE56dGlG?= =?utf-8?B?clNsK2Ira1c0NE0zeWJRR2EwV3J4ZDBvMHl4K2NjVktoUktGZS9JVmI2K0Q3?= =?utf-8?B?SWdiOURQaExJYlN2N1l1VkFIRkRtcTFDVnAwV1NKMWV6WDNzR05wRVNIK0Zs?= =?utf-8?B?cEQxSFNZeVVoaDhJUitxd3I2YWxiWjNBUVdFRU1Kd0FGU3FNczJyZ2lxWTgv?= =?utf-8?B?VEJTdFFOOUsrajdTb1NpT3pNSWJYUHl3Q2kyZEp3TGlrZDhUQUhNZlAzSjFt?= =?utf-8?B?anBlVVVyMCtUZlY1NnRQRkl5Q0thRlIxTzRYZnluempGdmlmM3JpT3hnWHJ3?= =?utf-8?B?dk1TZUtpbWMvdGVPcGh5dGk5RWMxd2xGRTlzTU9zVzk5OVowdUpRMkJTcEhH?= =?utf-8?B?NXdxUVRtZnlJZThzaDNIRm44MUlWUEgwallvNldZbUZZYTUxazJwcXBUR2s0?= =?utf-8?B?QTdHdldsbGtBZjVNS3o3blg0WXNnMGNONmwzMzFadGt6VHlpZWJqZjNYMXIv?= =?utf-8?B?bkM3bEw3dWRTa2FCQkw0Uk83VkxFb2tORlBCWHJyU0Vtdk5CZ2k2SytFazA3?= =?utf-8?B?M0FWVUZya0FVbFVGMDJncGF4Z3hTVnFmT0hQNGtLcFdQMVF0N3NBcmlJZitP?= =?utf-8?B?cGE3ZjAwbE9zYmJ4b3NDSHJwdE0rdWhETks2eERBQ1lNVHkxcit3L0xNa0xI?= =?utf-8?B?UHFPdExncktWQThNMXhmcGd2dzJONnFGYmNGYnV3T0swUHgvb3pOMFQ4Slpq?= =?utf-8?B?ZkRneDF2dXh1T28zS3pYb2RFdE9xamloMjN4Q01zbVRONjIzcGdGOEE1WVZG?= =?utf-8?B?UkpoQ0RqcmM2QThncDFOVUVldk8zRWtFeWFkT1RRbGVJREdvTnFiMnMrQlpG?= =?utf-8?B?YmNTRGZKOXd3QmRaa1MwOVJXbTdnL0dERUpCYnpWWXdVOW9QQmtWaWhXOTNm?= =?utf-8?B?ZnVqTFV5YjE3NU9xQUFRa1Q1RzRBUmh2bCtHdjhmYmQvZ1FWcFMxbHZ0ZEpJ?= =?utf-8?B?L1dQa0gzOU1kNlpuaTZnK1lYUjFVcElmejhGU0U1UG1rS0d5Q3lhVnFjWmFW?= =?utf-8?B?RDJtSHVYUlF2bkdReGlCU1hJdEFNZnJPdEQzRWI0V1A2ZFl1a2luczR2Y0RL?= =?utf-8?B?NzdkRmZSTWlrb3M3dHBkVkZDUjl1Q3d3d1V3R0RKck9tUXVQdDA0NHd0OG1J?= =?utf-8?B?WXpZMnJCUkdKNnhYWTBuZTEvVnJkVjVYM0RHa3pYSnI2eGJXekJvR0RWWUJC?= =?utf-8?B?VTdjcGtmZTQ5dVExb0s1OEhDT0dxYUxOMkJ5eE9MY3dYRmRoN1BTeXJldVQr?= =?utf-8?B?RC9FSUtCc3p6NFBDeUVYdTBaMnNOenBvQWVMZmdLbWdVYnhtdFZTQUFNVTZF?= =?utf-8?B?QWtURnRnT0tCS2NkZEhyWDNDQytESHpjK3hJLzMzV3gwNEI1S05SUnlxZG5U?= =?utf-8?Q?hqkjVEtXzhPQkjxQL8MQkebxti3awq9L?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZEFMTDJlVU0rSWkvWXVBYzhxNUtPNWN1cDc0MWYwUFpUVjlsTytsd1dQYWNJ?= =?utf-8?B?ZDhtT25XTUxTSFNmVkJjVXUwWTdPV1QwTW04Y28zSWtiYXJHY3R5d1dTdTJn?= =?utf-8?B?UFl6ZGJjM0dCL2pKSkNtT0xlVDV5TmVZaXBZejluTG9hclNvTUVTVmNuWXVG?= =?utf-8?B?QjFNc3BCQlQvTnNkOFFXU1ZGYTVHYXV4c2JCTEY4b1BXYktZWmEyV3l1Vngx?= =?utf-8?B?SDNyM251YzVkV2d4SnpIK0RZQWQvTnJVaFp5Uk5yaDJlR1hkb29leXpQZzEy?= =?utf-8?B?ZTQyWmxrWnBFV2pQRU9RUnNVREZPZmVTaTMzMFlVY2xDYzVXd05GOFlzZFgv?= =?utf-8?B?dmtpRE9IWGZRRW42Um13cjRUYktRNFdlRi9QdnN6YVNQY3plNnRUckVUQ1J6?= =?utf-8?B?dExUTmpMQ1FnM2ZtN3dZS2o4b2NiQkltZ1JMRGxJTEtZdXVBUitZMm56ZXNh?= =?utf-8?B?Y3luTmYxUmc1cjUzYm9CUTR3TGttTjNnR1BqMzJuV2NlaTFTWkdneWlERHFr?= =?utf-8?B?REZtdWZFZlMxN2hPMnc5RU4yQWpGT3N6MCtVVGJ3NUNzbmRSaE9CaXZkaFcy?= =?utf-8?B?bnlQZThGMEhzNE15TExOUFJDTzErUy9BZWw5elA4eU1uQ2g5djFoLzRXRFFU?= =?utf-8?B?dmJHYWxVN2szZFgwZHBGcWh4dk5JTzFsck0wQzVaUzltSmcxdW5YL2ZhaTNT?= =?utf-8?B?OXBLcjBPamdqaUdieElKVXlIRFppTUlxSWhOOFYycGpqZmpaSUNlVDczUkxP?= =?utf-8?B?b1U0a3ArNFhXeFF0Q1ZEYjdFZHR4N3RDZFhEVy9hMDBhMk82Ylc4MytVcTBL?= =?utf-8?B?b0JWWVV0bHVOQnlHaG1Lcjd5UmZLdm5KVjhGSVFqTk9Md1VCaFRLU21Xb3VJ?= =?utf-8?B?cER3R3pSRm9LZlp2cDRONjBrM1A3UEQ2S2JONzZkVVZYRC9wYWl5MHFSL3Fq?= =?utf-8?B?UXJuL0wzYTZYbFFuc1AzQVFlVHFpUld1bmFlQUFJTGJMSjdWZEZZaWVEUDh3?= =?utf-8?B?cTVHQ1ZzRVg0RENheFd6dExGdkRPclFWQmhoc1ZsclJWZGkxZVdGZU8xM3Nm?= =?utf-8?B?ZUlWRFA5V1JUS0lKY0tYM0NVdTVDRUxjSzlaQzJ2QmFsR2pSRHNNNnIrNTAr?= =?utf-8?B?ck9YQjZReGFjUWlJbWdaU0U5MktYNGFqNXpZSmx5SjBrV3dtZ3ZpVUh5djN4?= =?utf-8?B?eFpjY0p4VEZXNFFkcVIzNENJWVpNL2pFcnBkZ3JFZDJJaTZKK2VLbXJjS1Qy?= =?utf-8?B?UDVDR3NnSDAzZWRuOFpLc0RibDY1TkVWZGtQb3p4dTc0OEFUbXVnd3BGQ1B2?= =?utf-8?B?NE1mKzQzNHdBOHBCeXcrdkQ5S0MxNTNMVXhrdkY5d3JQdUswdjlQaGRYbTNr?= =?utf-8?B?a3pTVFdmZ0orRnZNOFQ0M3ZqK0VxcC9mWVRFZXRZMUc0UXdvYVdHK0JnSkhw?= =?utf-8?B?cVltcDlpZU8rdDBCeUJlb0NOTHAxS2p6YVhlWFNOMS9KVkVSYVlEQXZtcFhL?= =?utf-8?B?UmMwSTNnMDduTXYzbmdjV1NMTlh2aDNCOGRPZ3MxMUpaUVN5Mjc1WHFEb1dj?= =?utf-8?B?VEZMWHZ4NHFHcnVQQnhHMndQYS9Za3JYcEdUNnNPQTJ6QTFCMVEvVXVTVWMv?= =?utf-8?B?ZlpzUmVtYTRuSUhYZ0F6RXdoTFdiek1mNjZpOURrWXVNZlRqdG5qTnVXS3Qw?= =?utf-8?B?dVBXVExvZGxiUmtib095MitTVysxaXFoZDZwYTc2QVB3N0Zza2ljZU5zUEY3?= =?utf-8?B?eFU2ZUd6VmtnYVVtRkJpdFE0eVVBNUI4ZHdpd0xmNjBLeDRQYnpYRGRpTW14?= =?utf-8?B?LzFMVWJRd0pqNzlyUU1remhrV3BtUG15a3Z0NzA4akVoOXJPMmtqY09YVThH?= =?utf-8?B?RGVBaTNkbkxzZ3RsOUo5cjBLa3ZDUWJEdW9aZGhqV25SRUg0bFYzTWJ5UmZ3?= =?utf-8?B?QmhpUDd6Wm5WNjBYTWdhY2JKRC9OMFpUUXB6ZUJwa2lIdkJpQmVBQzVJMHdB?= =?utf-8?B?NGFnMVZIT3dsaUxIbXBSQzBkbWdYZU4vdmdqTDlhalMvMG9jcGRQQjZ4M2Rs?= =?utf-8?B?dTNVSkRWZFEyOG5ZSm1ZbGZsVDBHbEtmdGl3cnRRT1grUlo4VFJzOHNCL3NW?= =?utf-8?B?bHpaWklwQXE0SGtNeVk5SFN1UWJIMkVTSXcwblhmUkowMGpmMUFYWk01OEda?= =?utf-8?B?YzUrRTBCQ29YM0J3cklJdnpBc3lNV2h4OU93YlVyWjhQTnlEUzNZcWpuR3BN?= =?utf-8?B?b1FmVTRHbEUrR01LVnlkbmFRb2gvN2dkb0hjMlNCS3pwRVFsNHMrTWlQb1Ba?= =?utf-8?B?eGpSZjFWVXdpajVFSFltLzZCYmxLQ1k1c1NFaVJlUFp5a3RZblJHQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1cfc125a-9c3b-4dc4-f0d2-08de4edf4493 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2026 17:56:37.0161 (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: dXAe6/IDjdZk8OyIfsmv/OIvadcIOXyJHAEYVzMUHWqI9+rqyA2lkP0gImtgtGwC8EytlHNrb81ugT5KQJHWyQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB7280 The current model of falling back to allocate unscrubbed pages and scrub them in place at allocation time risks triggering the watchdog: Watchdog timer detects that CPU55 is stuck! ----[ Xen-4.17.5-21 x86_64 debug=n Not tainted ]---- CPU: 55 RIP: e008:[] clear_page_sse2+0x1a/0x30 RFLAGS: 0000000000000202 CONTEXT: hypervisor (d0v12) [...] Xen call trace: [] R clear_page_sse2+0x1a/0x30 [] S clear_domain_page+0x11/0x20 [] S common/page_alloc.c#alloc_heap_pages+0x400/0x5a0 [] S alloc_domheap_pages+0x67/0x180 [] S common/memory.c#populate_physmap+0x22f/0x3b0 [] S do_memory_op+0x728/0x1970 The maximum allocation order on x86 is limited to 18, that means allocating and scrubbing possibly 1G worth of memory in 4K chunks. Start by limiting dirty allocations to CONFIG_DOMU_MAX_ORDER, which is currently set to 2M chunks. However such limitation might cause fragmentation in HVM p2m population during domain creation. To prevent that introduce some extra logic in populate_physmap() that fallback to preemptive page-scrubbing if the requested allocation cannot be fulfilled and there's scrubbing work to do. This approach is less fair than the current one, but allows preemptive page scrubbing in the context of populate_physmap() to attempt to ensure unnecessary page-shattering. Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed") Signed-off-by: Roger Pau Monné --- I'm not particularly happy with this approach, as it doesn't guarantee progress for the callers. IOW: a caller might do a lot of scrubbing, just to get it's pages stolen by a different concurrent thread doing allocations. However I'm not sure there's a better solution than resorting to 2M allocations if there's not enough free memory that is scrubbed. I'm having trouble seeing where we could temporary store page(s) allocated that need to be scrubbed before being assigned to the domain, in a way that can be used by continuations, and that would allow Xen to keep track of them in case the operation is never finished. IOW: we would need to account for cleanup of such temporary stash of pages in case the domain never completes the hypercall, or is destroyed midway. Otherwise we could add the option to switch back to scrubbing before returning the pages to the free pool, but that's also problematic: the current approach aim to scrub pages in the same NUMA node as the CPU that's doing the scrubbing. If we scrub in the context of the domain destruction hypercall there's no attempt to scrub pages in the local NUMA node. --- xen/common/memory.c | 12 ++++++++++++ xen/common/page_alloc.c | 37 +++++++++++++++++++++++++++++++++++-- xen/include/xen/mm.h | 9 +++++++++ 3 files changed, 56 insertions(+), 2 deletions(-) diff --git a/xen/common/memory.c b/xen/common/memory.c index 10becf7c1f4c..28b254e9d280 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -279,6 +279,18 @@ static void populate_physmap(struct memop_args *a) if ( unlikely(!page) ) { + nodeid_t node = MEMF_get_node(a->memflags); + + if ( memory_scrub_pending(node) || + (node != NUMA_NO_NODE && + !(a->memflags & MEMF_exact_node) && + memory_scrub_pending(node = NUMA_NO_NODE)) ) + { + scrub_free_pages(node); + a->preempted = 1; + goto out; + } + gdprintk(XENLOG_INFO, "Could not allocate order=%u extent: id=%d memflags=%#x (%u of %u)\n", a->extent_order, d->domain_id, a->memflags, diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 248c44df32b3..d4dabc997c44 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -483,6 +483,20 @@ static heap_by_zone_and_order_t *_heap[MAX_NUMNODES]; static unsigned long node_need_scrub[MAX_NUMNODES]; +bool memory_scrub_pending(nodeid_t node) +{ + nodeid_t i; + + if ( node != NUMA_NO_NODE ) + return node_need_scrub[node]; + + for_each_online_node ( i ) + if ( node_need_scrub[i] ) + return true; + + return false; +} + static unsigned long *avail[MAX_NUMNODES]; static long total_avail_pages; @@ -1007,8 +1021,18 @@ static struct page_info *alloc_heap_pages( } pg = get_free_buddy(zone_lo, zone_hi, order, memflags, d); - /* Try getting a dirty buddy if we couldn't get a clean one. */ - if ( !pg && !(memflags & MEMF_no_scrub) ) + /* + * Try getting a dirty buddy if we couldn't get a clean one. Limit the + * fallback to orders equal or below MAX_DIRTY_ORDER, as otherwise the + * non-preemptive scrubbing could trigger the watchdog. + */ + if ( !pg && !(memflags & MEMF_no_scrub) && + /* + * Allow any order unscrubbed allocations during boot time, we + * compensate by processing softirqs in the scrubbing loop below once + * irqs are enabled. + */ + (order <= MAX_DIRTY_ORDER || system_state < SYS_STATE_active) ) pg = get_free_buddy(zone_lo, zone_hi, order, memflags | MEMF_no_scrub, d); if ( !pg ) @@ -1115,7 +1139,16 @@ static struct page_info *alloc_heap_pages( if ( test_and_clear_bit(_PGC_need_scrub, &pg[i].count_info) ) { if ( !(memflags & MEMF_no_scrub) ) + { scrub_one_page(&pg[i], cold); + /* + * Use SYS_STATE_smp_boot explicitly; ahead of that state + * interrupts are disabled. + */ + if ( system_state == SYS_STATE_smp_boot && + !(dirty_cnt & 0xff) ) + process_pending_softirqs(); + } dirty_cnt++; } diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index 7067c9ec0405..a37476a99f1b 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -92,6 +92,7 @@ void xenheap_max_mfn(unsigned long mfn); void *alloc_xenheap_pages(unsigned int order, unsigned int memflags); void free_xenheap_pages(void *v, unsigned int order); bool scrub_free_pages(nodeid_t node); +bool memory_scrub_pending(nodeid_t node); #define alloc_xenheap_page() (alloc_xenheap_pages(0,0)) #define free_xenheap_page(v) (free_xenheap_pages(v,0)) @@ -223,6 +224,14 @@ struct npfec { #else #define MAX_ORDER 20 /* 2^20 contiguous pages */ #endif + +/* Max order when scrubbing pages at allocation time. */ +#ifdef CONFIG_DOMU_MAX_ORDER +# define MAX_DIRTY_ORDER CONFIG_DOMU_MAX_ORDER +#else +# define MAX_DIRTY_ORDER 9 +#endif + mfn_t acquire_reserved_page(struct domain *d, unsigned int memflags); /* Private domain structs for DOMID_XEN, DOMID_IO, etc. */ -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 08 18:13:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 18:13:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1197992.1515298 (Exim 4.92) (envelope-from ) id 1vduVD-0005EC-PY; Thu, 08 Jan 2026 18:12:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1197992.1515298; Thu, 08 Jan 2026 18:12:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vduVD-0005E5-Mh; Thu, 08 Jan 2026 18:12:55 +0000 Received: by outflank-mailman (input) for mailman id 1197992; Thu, 08 Jan 2026 18:12:54 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vduVC-0005Dz-23 for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 18:12:54 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a58170ad-ecbd-11f0-b15e-2bf370ae4941; Thu, 08 Jan 2026 19:12:52 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS7PR03MB5589.namprd03.prod.outlook.com (2603:10b6:5:2cd::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Thu, 8 Jan 2026 18:12:49 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.002; Thu, 8 Jan 2026 18:12: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: a58170ad-ecbd-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Bn4f7H8nA+kp6zRNvc9CcE5dZ9w3gXca+Fja/xEQS1kUBQoI1k4f3DkNVrjT9AcJyN016kY8iFqcTd495qiDNgw+qePFca6/Sqsa0VJ1WI0u028XC1XgqMgR3E6OBI4+pSLoG7rRvGGRcYPMm5RUkJnAfhNvWBgMWwRmUpTwo2SYzRy73YokSptLRAmFZFiPJyKts0OY/9dd3d6O+JausZ6JZHBW9GKnoldtqZXneMf3+hVdGFySPOn2hOaUBSouoBMzNY3bjztHMe/OWlYQEPQPcKdej56NjFL34BKSd86Ras3KDQqcKdysi5UJQxWSKvgVd7XSk9LsX3i8mifVVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yIV0UM0RSzqyDTOYO61g2uqGwOb1ENaSUjQ5Ywx9RHQ=; b=OBqPHJJ1o4Ia1YeL3E0mNqp6XFsf4H6nNEkprstUtS4mGcEg3aeQnvz3GwGpxWD3yb8ACYhML/lCD0Ok9I/sAJpWgVq9HR/PTW3Rexb0fsqpExAruV9ytuOuqb8eeJ8rTk2v16P89rUBHvezxyMGRaMa2Qj2IL5sGJb5cS79qiZN37wl+mBw++qkHIaKH63JsXYlYFVkepPk9oSU+evQ7CpKvphvxpTfaCRScLHCctFhquCW8uTvRo1ipsuKJzj+mwLrRaW4JrQbjOOyklYEychD/fncvzAp5x2CRVFW02fnDChbyyLnFMqwCsgB0a8shSLV+YIFQVvukYx33lzsbQ== 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=yIV0UM0RSzqyDTOYO61g2uqGwOb1ENaSUjQ5Ywx9RHQ=; b=G4F10hxitevSzxfX6Ic5fkekluI6F4JK1azw1IprMqBhgUapkhpp6VAiKYq/eI/1jtKP6fv7F5GeXIoWmMwDoRza3owNic2bN8GTtNpZRnZirm5wcH0hQpumuMgBh/6dAM4wP636KUyg2lV0cyoh1CmR+jOQORI0rmhsgk++8mU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Thu, 8 Jan 2026 18:12:43 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk Subject: Re: [PATCH v2] x86: guard synthetic feature and bug enumerators To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <239a5d80-c0af-410b-a053-5fa84273aecd@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <239a5d80-c0af-410b-a053-5fa84273aecd@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P302CA0035.GBRP302.PROD.OUTLOOK.COM (2603:10a6:600:317::11) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS7PR03MB5589:EE_ X-MS-Office365-Filtering-Correlation-Id: 78909355-4b7a-4ac4-9e96-08de4ee187de 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?NSt5TnZ2VzJicDhZaEt3YTN2RGpnTUJJRGovVGdZWHFJOUk5Rk44NkJ3RVlT?= =?utf-8?B?bWpYQjBnQkZUWHJYTmQ4Z0EvWDY0elVsM2tHVE9lQzMweG9VcUNseTdaaldX?= =?utf-8?B?SE94ejNhMVJ1SzJjYlh5T0hsTkdNWmlBTGNGSjhLb2QydGxxdGNjVUR6SG5Y?= =?utf-8?B?SGVjcFl4cmFJek1XNENUV2pVMmlZa0c3S3NmN29CZ1ZhMk41YTI3SkU2Qy9B?= =?utf-8?B?ZjVYem1jVDljeGI0MGlaMm40WHg0Sks3cFZwRkJwNHJTZlN1cnVHWEIxQ2NY?= =?utf-8?B?WGx2aElnZURGOXZqQ3hqMVdlYmZST1ZsbnhqZ0Y1S3psSXJHajlaZGFFaHFz?= =?utf-8?B?UEJmaVorYnNWYkw5Sit2bEZ4TUxDbURibW0zbzhkbVFpWmtXSk9IY1hmOVZj?= =?utf-8?B?bVorZ2RITFFYSVNxaXRRL0hISzh2L2xxY3FqTGJGTmw5bGxhMVVkTTB4VG5r?= =?utf-8?B?bkV3TEZzbmxJK0RJUTRleHdSQTYzSUxDcGgreG9nM0hwb3E1NG9nNFVmWmcy?= =?utf-8?B?elVta0hpTjA1T241MGlNN2VUeHpDYk5QU1poanN4S0ZXTHdma2NicjRVVEov?= =?utf-8?B?OEZid3l4QjJiTktpcWowMkFZQkhsQzdzbGxvcThmbUhYSkgydm5WWFBwZVBG?= =?utf-8?B?TGl4RGtrcmxhZnBGd1NPUnByWkFCM1BVLzhzM3RZQlNUdm9MQjk1ZVpBUWFV?= =?utf-8?B?MEpNcUxCQmxRU1NRMkJHZHM3dU5YM3AxdG91T21LbWhjdFlnUVFYN2k1ay9Q?= =?utf-8?B?enVBd1NwempDVUJzZEt0NGNoU05jUUV3R2lKYUhBd1lqc004Y0lZbnpyWmVn?= =?utf-8?B?aFFPUHNZN1hubXRXNFVJUEJIZFFwejhvbEh6V2ZvODY3dWhkK1RCakxIeWVT?= =?utf-8?B?V3FnRWpBMTQxVDhUVXEvR1YyaG5nbDlSdURlek0xTFhWVFR4RGI4MU0valN0?= =?utf-8?B?RmdkR21xeWVMWnFmd3JNQlhwMWtSMFUrTmFJVmJGWG15M3hPd1VXYk05S0VD?= =?utf-8?B?NVlJU0ltYUNQd3B0V1hOUG5HbUdtS2p6d2txOFNsK0RyNXBLYURDb0lYSDRt?= =?utf-8?B?K0cwMkdXS0l2NzNRYjZudzZJRTluOTNibndEQ1BHdjhIL1hxdGtQbGw0bW9h?= =?utf-8?B?SlpJdWxZbFF6VWJxdzI5SzJtdTlMZXJJTWgvaUQ4cUZUaHp0VDE0R1J2bVpZ?= =?utf-8?B?d3FFejdZTms5UGhxV1czMmZMTU16Rk1PZFk4a25MVzhWa0ZWdnJEbHBPVjY4?= =?utf-8?B?L0NFc1ZaZkMyV3UyNUpSa2xteEU2alNDeGtYTkh0OWNTcXhnL0F2WWY1ZzlW?= =?utf-8?B?TTN3RlNjT1dGQTlGT3kxdDFlWXpvWS9UaUFudVgvMFN5VW1wN0c0SG03UUNJ?= =?utf-8?B?amh2ZWhHZTFLTXZVOWZ1b0dnVXUrSGNkRXFNQk5lZXB2azZ6d3l6MlhlOUhI?= =?utf-8?B?ZzZ0R0puMUxXS2tOK3I1RG50V3cyRXl1RG1CeG8yK0VFcFZIQTdTL2ZDcVk2?= =?utf-8?B?QVg3OEdYUVpFL3RHVVNkM2dROVljSUkrMkdkSmRyQTB5bTE3WThlMHFESjR5?= =?utf-8?B?cG0rSnBqMEZuR1ViWHNTTWx4SE1BSWtQQ3hOUlpOZXZnZmdXQktvV3RiTUU0?= =?utf-8?B?b0grR2E2Y2FRYnkxR0VSTVFJTDFRaHJjUmFIVDZNbzBMcnI0aXBqbkp5ZldO?= =?utf-8?B?elZOWXRXeklVTXV1L1JnbTJLMnUwekhQalJTNkxxbHBJbjRTT2pZWHhVWU10?= =?utf-8?B?TjE0a2trWW8vcDhLV3NNRk5lNWsvYkRrU1g5ZmNjM2JoSDRFWDJrOEFQU1o3?= =?utf-8?B?Njk2VTFRU002YjhaWERTcXdNUkUySFJQUytPbHpRYUJwRzRuRlRySlVrc21S?= =?utf-8?B?RkVCMkY3U2dqYTYwV0Y2MkpmL1JxV0xDUktXam9JL0RVOW5QT2pYOHJVNjY4?= =?utf-8?Q?43O10KKWkqrGU7C+uOkRLaR7Z7PjAPkj?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YzlqTFR6Sk05a2xXSHJGZ2MvbmVlK1NHbDNCTklIWm1MVVpDRlpOakk3Z0Y0?= =?utf-8?B?OUJyQVVqMDhSY2EwTEwwV0RFSGl2ZlltVGpJV0tTaFVqMTExcGpwNU9KM2Fz?= =?utf-8?B?NlhaNTlTQXVBKzlEOVJ2NTZSUk4wT0VxZlF3aUlyWVVxODZtdFJJcVlqaGJN?= =?utf-8?B?aU5URm9hekJmZnl0NXhnQzBnMmwxY1J2Q09UZnhIYjhHZzVpQUdOak1DNElv?= =?utf-8?B?Wmd5VjB3MmovUkZ6eS93QmpBd3dZQjJBaWtwN0NTbGQrVDhLdGZiNXRtNUVq?= =?utf-8?B?cGsreUx6aUhBcU5iSzVPeXdZd2sxbkVxTWxrWEVBUzBZRUJyNlp3aW1VSFd6?= =?utf-8?B?cCtiK0N0V2V0RS9ucFpBalY1dEZtWk4xcXp5Z1hJRzJlMURwVjgwdE5IRE9S?= =?utf-8?B?V1ZJNDR0bnhmMUhPZnJKN3cxTjFnYkFtWWpsS0pSOC9uRFpxZ2MySEFGVThD?= =?utf-8?B?YUVnQTNqU3duUjZYVnE3VHBLWUJLRTYrdzk4UXNHS2NtZmVkZm5KTFg3V2VG?= =?utf-8?B?KzdLY2tDUlBlWVBXMU4xWjU5L2VWMVdqM1h5SkVjNWdDVy9WdktHaEp0R3dr?= =?utf-8?B?dFdacW42YVZkdXJ3bmRaZ1N0YUhuNXUyRUFDWDNMWFVVaGZ0bkNNNDgvempF?= =?utf-8?B?WGl1K1EyeU44aGF6VUoyZi90YkhsYmRxdXJLbnNyV2JEblYyRkJxMmJkTnh1?= =?utf-8?B?aWJPMVRiMGNnWXBHTmZkZFVZbytHUkFRZS9VM202QlYvU2tZelRld2l0dkZs?= =?utf-8?B?YTVEMjRRSlVLVE1pbkUxUVUvLy96WExoOXNFc0dBaDhmU3prY3V5RGRtemxH?= =?utf-8?B?cHI2TEtxd09ocU15TkNqSFFsTTNqbWZuaFdhdzZXWGVMdEV3YVBMUjIwa2or?= =?utf-8?B?azFJLzhWbDkxWDB1ZHZ3MTQyc2xwNzNsM0cyS2hYQ3pSeWVpbW1lZnJ3VmRn?= =?utf-8?B?QWJ5ak9mMmlEZy96WVNkYUh1MDN1ZUlqZ0VmaWExZ1Q1S0NaQWR4a3F3bVNm?= =?utf-8?B?V3F3UHU2VGxIb0YxQ2lCc25kWkZYbHZpVWNjS1VhNE9JSHZDbWFzVExmMjQ1?= =?utf-8?B?MFRHWUdYWE1yV0JIS2Z6N0ZPTVVYUytzdzllcHdvdTFlVnd3T1ZUWFVSUjBX?= =?utf-8?B?bmg3MnNWcHBNZ3A3YkpqenpnZkJURTVrbi9uWUd5U1ZqVnRGSzFDamQ1cTZF?= =?utf-8?B?K0p2MWtuSE1ZNDZoVU9OUCtIa2ZCb0lQazN0bWdUN3RXcDlXeHZJcytPZ09t?= =?utf-8?B?NE1VenlLRWdXNVl1STkzaXdhV2NTd0Zjb3NwU1ZqeGczRzF4bTltSUovQVRT?= =?utf-8?B?bXFKekp4QWoxNGFnQmM3QTliUzFPQVpUTXhybGFBd3A4T2hFNThKL2dIa1Ay?= =?utf-8?B?OFh5M1l4MENNRjZFMTRBQTY0OFpNVjRNY0t1SU9IajJ5cHhnTDByaDNyc1ZU?= =?utf-8?B?dTdNdm1OQzlZMC8vVHQrR0taMXR2ZFdrM0xWSHhKanNMTGx1dnR4VXRhcTQr?= =?utf-8?B?aXpUVlFKRFNSM1dlRDZQYkUrTVh2TnJzNlNoRnc1ZnVTaFhpSDRya01aYmN0?= =?utf-8?B?UFNWOWc3aERGWk5ZMDIvemhFa0YvSzZqdHJnRmhYYzc5d2JBQ3FkTDRXNlV5?= =?utf-8?B?NWx1dUNTOVJNME83SzhqOFBEaFdrblV5L3UwUzVGSUk2VWdmQm9MVytvUEhJ?= =?utf-8?B?Q29hOGdHczZ2M3F4ZUpHdlJNcTYyaUk3cWd3c08yaE1SUUxMa0RiaE1ZMlJh?= =?utf-8?B?TjFMTnRPbGV1V053RE8wVlV1WC91YlE5R0cxSXQ3UTZSY1pqdXNhN2RTS0N4?= =?utf-8?B?K2N2aGE5MnRDdUlQdTltMGNrS3NETHU0SFVZeCtxSmw0YnVLR1RSRDh4aUhh?= =?utf-8?B?YUU0cUVhOElVWjEyWHoyZ3BWRmphMTQ1RStqUmlRMnI3WXNmU0ZYVnd3NUJR?= =?utf-8?B?ZzkreCtOOVMwK0c3Unh0NElNUURPaG1IWTJjKzA0aXowNlJXTlhOMUl3MUpk?= =?utf-8?B?QnhEN3o5Y1BTZGNUWFFXTnlWbTc0T2F3TUIrUVRBeU5lT1EycFJxcXRQc0RS?= =?utf-8?B?RE94VTRFT2VBQWFORVFYdForZ0JQUU1MQ2Y4cjNyZjBNSzBkZ1U1d0RzWXk4?= =?utf-8?B?T1drSEQwVU1QN2JzTCtRVnBQYTlTcC9pRUo2ZmQxQkUyVzh2VGdSa3hsQStk?= =?utf-8?B?YXlybDBYR1c5ajFvWkVEQ1FtaCtLRm9QZFdhZE5hazJqb01ZcHhJbDhHcytY?= =?utf-8?B?NmNtbmJQbGFiazJHc2RZNS9zK1Q4cmd0dUtSQUFNK2dnNmdzQmVQZXJzRG4w?= =?utf-8?B?UUl1cEpXOFIvczZaRVpOMnllREYyTmFTZ1phenozeXBkTCtqQ2xlTEpxTWpw?= =?utf-8?Q?xTWT0pVDCbd+WU3A=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 78909355-4b7a-4ac4-9e96-08de4ee187de X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2026 18:12:48.8889 (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: xMKo636Z+JsD2ec5Ag2gpZi6JLG4CMXWNuYf7sOXVfBG7h9ehshWU3i2gzxu0Odffmhmu6wzSzH1sibJjOavgLG8MR0WKrr3vuzIraqaHA4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5589 On 07/01/2026 2:11 pm, 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 > --- > v2: Fix shim build. Use named label operand in pdx.h. I'm pretty sure that will be rejected by Eclair as a Rule R20.12 violation (using a parameter as a regular value, and stringised), and is a blocking rule. But more generally...  I see why you want a guard rail here, I can't help feeling that the cure is worse than the poison. Updating every alternative is very invasive, and this in particular > --- 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"); > } > without even an explanation of why, is an immediate red flag. Could we not split X86_SYNTH()/BUG() to take a leaf/bit pair, similar to how we express regular features as a*32+b? That would at least make it more obvious than currently when a new leaf is needed, and contained it to a single header. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Jan 08 18:35:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 18:35:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198028.1515308 (Exim 4.92) (envelope-from ) id 1vdurO-0008Ij-Kw; Thu, 08 Jan 2026 18:35:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198028.1515308; Thu, 08 Jan 2026 18: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 1vdurO-0008Ic-H3; Thu, 08 Jan 2026 18:35:50 +0000 Received: by outflank-mailman (input) for mailman id 1198028; Thu, 08 Jan 2026 18:35:48 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdurM-0008IW-CR for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 18:35:48 +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 d735ee63-ecc0-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 19:35:45 +0100 (CET) Received: from SJ0PR03CA0199.namprd03.prod.outlook.com (2603:10b6:a03:2ef::24) by BY5PR12MB4273.namprd12.prod.outlook.com (2603:10b6:a03:212::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Thu, 8 Jan 2026 18:35:39 +0000 Received: from CO1PEPF000042AE.namprd03.prod.outlook.com (2603:10b6:a03:2ef:cafe::87) by SJ0PR03CA0199.outlook.office365.com (2603:10b6:a03:2ef::24) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.3 via Frontend Transport; Thu, 8 Jan 2026 18:35:37 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by CO1PEPF000042AE.mail.protection.outlook.com (10.167.243.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Thu, 8 Jan 2026 18:35:39 +0000 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.2562.17; Thu, 8 Jan 2026 12:35:36 -0600 Received: from satlexmb08.amd.com (10.181.42.217) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 8 Jan 2026 12:35:35 -0600 Received: from [10.71.192.102] (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, 8 Jan 2026 12:35:34 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d735ee63-ecc0-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=USCcS3GJ6yoKuzdz25QYXGQrilKSiHGvyi98X5U70Tun08j2yBy+8UkrtpkEy9LFm+C63GUGRvq8enY4gTwCfJndVKvm8Oc2wzpS68857b4zENUDByZAi28M72tPrzYfSslndvi6Bf5Dn0PANSvp1RHUifudxmyeko7Gqys+43oG98/W1FLNn8YlH3Q/vwawJihGeHlTGMle7VNIm+jCPOz0cwaJS6wwapKvaA1jEc6kTNslqhDIWbyB+kpGZxo+RoM/c93VcOjC3Yug1XsFOv72d4yKB2ZTkNgMYPlR22e7xAEejV3UjbzSK3dlWwEqkYOsiyPDGsZBRcXrA3Rc/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=oMa7OHhEIpfTV5Ox3qtzkLjeGIYIhXEHeOt5+S4Je3c=; b=ZsnHPA89W8ZiSzA4gb7suTYzAD3oP3cf1i26EhRtT9YJ0OLwearUFxVywR4+DjczwCy2Ci66XyVCO7153X8xv05g9jhel5D8AjNqaSxgWpPhKtkiczRqXlSqHhg2uha8aYy6p2BZlA6gSxRNwl45E4J72eSB0wp6uuFewHke+5eZtpl55TIyqYEJKMdNcJNPFOje5PTMKMNolmHC7fDjtFR+BElv3fYhhLpMnbS8cPAZSt2byDw/1+ZG8Ks1/KJrEwXF1KDGjyZEzHY4EAZeAzKu0sW7LTp2sHBitgckz5aihwFRCPowV0eDAmqBWKjvpKAc+UeRTt2Oi+37x0dfdA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oMa7OHhEIpfTV5Ox3qtzkLjeGIYIhXEHeOt5+S4Je3c=; b=Zehz5pF2Z1kd9HsooRgo5LQkmuR4zQG5hGKJfHf4NeSu4CDl3odRmw9kTFC6b3rfUThuEf3A9Yt+2wB8b+prdGX42Jtr2Akpule4VFFzCMgPoSN2yTCwOQotLxnmsUr6dws+Q6x5ICzherUZZ4ZMEB+ovvaXvCnmgZXb/icbi2I= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <3c3ffd55-9f1e-4322-b3fa-99c50da552c5@amd.com> Date: Thu, 8 Jan 2026 18:35:34 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/6] arm: Use secure hypervisor timer in MPU system To: Harry Ramsey , CC: , Penny Zheng , "Stefano Stabellini" , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , "Wei Chen" References: <20260105113503.2674777-1-harry.ramsey@arm.com> <20260105113503.2674777-6-harry.ramsey@arm.com> Content-Language: en-US From: "Halder, Ayan Kumar" In-Reply-To: <20260105113503.2674777-6-harry.ramsey@arm.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit 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: CO1PEPF000042AE:EE_|BY5PR12MB4273:EE_ X-MS-Office365-Filtering-Correlation-Id: 30e1748c-03d0-4eeb-aa4b-08de4ee4b8f7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700013|82310400026|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?ZVJxL3IrZUtla1I4UFhBTXNwcktJbTdDWHA2b0trZWV2bHJUSTJZNEJleHA0?= =?utf-8?B?WE5WQUJWam1JK0hwanVwNzVwQ29teTQyYnh3aHNMSHRYVERCZExFVjA0TGtE?= =?utf-8?B?bzczeW1STEQyaEZGbHRVcndqS2JuMHNxTUd5TnRJMHR1eXNEN2dyb2FOYkt3?= =?utf-8?B?Z3FKNGZ3ZE9zZVgwNkZWcU5IV0dwYzYvVERuWllrQ3g3WTEzZkRzTjRlY01X?= =?utf-8?B?Z29CbjhTY0Y0Vi9lU2RLMzMzR1UwWFVVV0VwVWlDMzA5NlovS09ySnMvT3Vx?= =?utf-8?B?dCt4NVc2Ty82bDQ0RkJvQk1vbWI0ZDhnbDBpUlVqVGVtdklTa1NQZTJjYUpz?= =?utf-8?B?TTlGYjZlNlpQTE10RXR1N2ZpMzJnTFdtREQwaUplMklDcnVIMnREUTRuMTJW?= =?utf-8?B?bFVYdjdtRFdRYUs2UlhhS2hNU2hMbWZEbEhKYWJUWkEzSm51WFdvQXZSS0hu?= =?utf-8?B?ME9WdmhCQ1NVRWNFelB3VkIra2kvV2t0V0RQWnExaXBxbkJrU1F2dVczTk9T?= =?utf-8?B?Z3JGTVVNR2NhS0s1OTZEN1JGZHFJcHNMYW8vUGl4NXZIcng5SVdQeWV1dG9K?= =?utf-8?B?dElyMkhHcWl3TFFabWFYTG4wcXp4WEhjSzZpdjBiaEtyREJVUjZKVjdRdTRC?= =?utf-8?B?T2MyREhaamN1TytoQk4rZ3ZSR2Yzak0yYllqanB0ZXdZYS93cUlUbnRTQUxE?= =?utf-8?B?NjExMC8yd1dCeHUyVkVVTDJ1aTBBZmpmNTFJcE1WS3BwaFZua29nRDRwdCtC?= =?utf-8?B?WXRuSURLN3lKR0NpU1pMVUZ6Y3pTenBRUmk0OE1XOGFUeU5DSFg2TXhzNndh?= =?utf-8?B?ZDJjcTZtNnVoc05vWW1qaUFHQmhCK29qVFhva3NuWFMrN1pxVUxyNENFSko3?= =?utf-8?B?NVl4dWhBTWxZeEhpWUZYYjFXNTZOUGNmYmtaUUlLa01PdVRxdGNTek5GWFNK?= =?utf-8?B?NGhVdE5ha01mMlVCQTdnZlFtcnhGYVoyaTFBWjBwd01BZm9raGsvUjlSbjFx?= =?utf-8?B?d3krY3prWUR5WkVrQkx0L0VJd2NHTmxpVXN2THByYTFUWEpaRUcxWEUvR252?= =?utf-8?B?WVdwMHJjWFdxUjc4OXR5azVra1pBU2pVcFZpclNwM3F6cEpaQjhqTCtxaUVi?= =?utf-8?B?K1o3Y2lrTGFxcTNEY2NxWE9jNTd3aXFkL2EzVEU5ejdxQVV0bEJIV1lTWmNK?= =?utf-8?B?dU1uVDJiT2JUdG1WTlJMdmVwckpUREFWMzV2Vmd3RSs2dWVUckJPNHdLMHdK?= =?utf-8?B?QTk3ZDlCM3BGeVBwSXVpenJnMjZQdS9JTVpZNUdOS3Z6SjE5YndoaCtJeXV4?= =?utf-8?B?Z09OeTUvdFFiak1jTlYyd2Ftc2k3NWF2cEw1ZjlWR09lSkgrM1ZUOVRWTXZi?= =?utf-8?B?TTB3TWhBRngrVlo2NzZYMVpzdzh1bkdVdVBLQ3V3dEswNXc2MUI5WUFNYXdp?= =?utf-8?B?ajRxcmdFQUVXYm5WOFpLVHorNnhpTytuRnJOd1RpMTV5MldMZWRTY1F3UXBs?= =?utf-8?B?RTNicFpnNVdMSUdnQXJ2KytIMTRXR0RETjFDdmhxeUZtVUZuMXRLOEkrZ0lm?= =?utf-8?B?ckx6T0ZXR05vOEppNGpzRzFxSXVicnVjY3pCTHZ3NE9WaldDb2ZBS214Wkhh?= =?utf-8?B?Nm1jNlFZdUJkUzVaZlhXNlBydkRmRG1vYVU2bjdZblRYSzR5ZEpaNUN3a0VK?= =?utf-8?B?c0FpSlB2akJjZFUybDUwUDhib1lneWhnT25XMFpQMzlwY254SFlrZHh6azZE?= =?utf-8?B?c0tkdFBwNk9YenpYS2p0dWNjQy9NclM2VDVwa1NOU21ySGJYOEllN1VFTTZP?= =?utf-8?B?RTJlRHJjZ0NSVEdLNGVyYlZ1blFzbXZ6TVQ1eHdGbm5kUkNoYjlQcWI1Nk94?= =?utf-8?B?TlA1RFRxUG5VbndIZzJjZlZranBTU2xMeERCM1dKb3ViQnB5OStSMnZ3cHMv?= =?utf-8?B?ZlU3Qi9TcFp5UXpURHNWUUNXR0NqVXlkMWxUQ2YrU0tOdXltemxqbDRzc2s5?= =?utf-8?B?OG4xUWNVbEVxM2JUU01hK0lPaXJLZzh5Mkl6SGo4WDBKK0xMa3NiVzFKVTVu?= =?utf-8?B?eThtNCtrOU5TY0hzWDJMVUlvS3k5dkVXY3Jvc2pQQkhHSmdCVituWUw1VTUy?= =?utf-8?Q?vB28=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(82310400026)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2026 18:35:39.4588 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 30e1748c-03d0-4eeb-aa4b-08de4ee4b8f7 X-MS-Exchange-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: CO1PEPF000042AE.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4273 Hi Harry, On 05/01/2026 11:35, Harry Ramsey wrote: > From: Penny Zheng > > As MPU systems only have one secure state, we have to use secure EL2 > hypervisor timer for Xen in secure EL2. > > Signed-off-by: Penny Zheng > Signed-off-by: Wei Chen > Signed-off-by: Luca Fancellu > Signed-off-by: Harry Ramsey Reviewed-by: Ayan Kumar Halder - Ayan From xen-devel-bounces@lists.xenproject.org Thu Jan 08 19:13:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 19:13:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198047.1515318 (Exim 4.92) (envelope-from ) id 1vdvRG-0004zq-6m; Thu, 08 Jan 2026 19:12:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198047.1515318; Thu, 08 Jan 2026 19:12:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdvRG-0004zj-44; Thu, 08 Jan 2026 19:12:54 +0000 Received: by outflank-mailman (input) for mailman id 1198047; Thu, 08 Jan 2026 19:12: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 1vdvRE-0004zd-HH for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 19:12:52 +0000 Received: from mail137-3.atl71.mandrillapp.com (mail137-3.atl71.mandrillapp.com [198.2.137.3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 06101c23-ecc6-11f0-b15e-2bf370ae4941; Thu, 08 Jan 2026 20:12:50 +0100 (CET) Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail137-3.atl71.mandrillapp.com (Mailchimp) with ESMTP id 4dnF0c4kgrzBsTnTy for ; Thu, 8 Jan 2026 19:12:48 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 884cca178e3844ecae15f78c544c311f; Thu, 08 Jan 2026 19:12: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: 06101c23-ecc6-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1767899568; x=1768169568; bh=DVpGMbKYvdwbRaLDKkNU+x5aQEKvdSLsNqoHHCYow3Q=; 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=ET4zdBy7Nop4JwbxnleT8RAvTWmCJF3Dui7N5yyFOl/iFJSn36gWcW8jd0AWu6ONd lWcJyQhuWH0MOZhA8W+NkaUODwcuyCMjW1MSY4CG0b8ZHggddZ+LDB1d8eZKEbw75H G/h99ubqlmMC5buYD0Ynw/9MvkrVgaoekufxBpTIVqRQUqAVPmycawNOQsy9yGDh2D eFQGWro0WwXEZdaMKnbDEfQDw54YlvFfcSxDf/fhz5qykZhsE+/2soxWXvSA2GzOuJ KjzTZpLU+LhnpLnP2RNquQNntFAG9fNWH5jawdW2sCfidZMKgFaEXtjcKcLO3AIjGn /w+hETqPlB5YQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1767899568; x=1768160068; i=teddy.astie@vates.tech; bh=DVpGMbKYvdwbRaLDKkNU+x5aQEKvdSLsNqoHHCYow3Q=; 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=0S2NcC/JwjGJJvu2Fzlq/CvN7XrrHHwaL8at6CIiJQTjbZqDwFMBD590Cnvp6wYJz YCkPN7FiRCZCH53vz6F1UnpTa+yqOO0aFnRTMRKi9ctIo1zQRVXXcrM9cx4I/4PdTk HkCAged85b0J9CWa0Sp8OU/6EUjxoOSTzzUJuKXJ8gXFCjdKtuce7AQOuljuoRuz7m OulsId4InHrUVhSfvRj2ImUJC6gPczRjW8aCxDgGOj7ZRfR0YGPZy14Fqz2iw98IYP zGMyQSCtKolIEfRaaG14j2eIGGXLtQq6uNCQ7X7hb1IeflP24fdFy+d9e40DE/zuck vmjKVRdT6Irmw== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[RFC=20PATCH]=20pvh:=20Introduce=20SIF=5FHVM=5FGHCB=20for=20SEV-ES/SNP=20guests?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1767899567042 Message-Id: To: "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" Cc: xen-devel@lists.xenproject.org, "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Jan Beulich" , "Julien Grall" , "Stefano Stabellini" References: <3b6f5146287d3402a09836b7cf876d4f8dc9eee1.1766889890.git.teddy.astie@vates.tech> <0c9c1dbb-28e1-479b-a680-e99150b3f0da@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.884cca178e3844ecae15f78c544c311f?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260108:md Date: Thu, 08 Jan 2026 19:12:48 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 08/01/2026 =C3=A0 18:46, Roger Pau Monn=C3=A9 a =C3=A9crit=C2=A0: > On Thu, Jan 08, 2026 at 04:50:51PM +0000, Teddy Astie wrote: >> Le 28/12/2025 =C3=A0 13:54, Teddy Astie a =C3=A9crit=C2=A0: >>> Under SEV, the pagetables needs to be post-processed to add the C-bit >>> (to make the mapping encrypted). The guest is expected to query the C-b= it >>> through CPUID. However, under SEV-ES and SEV-SNP modes, this instructio= n >>> now triggers #VC instead. The guest would need to setup a IDT very earl= y >>> and instead use the early-GHCB protocol to emulate CPUID, which is >>> complicated. > > Possibly a stupid question, but how is this information expected to > be propagated to the guest when there's a guest firmware and > bootloader in use? > > How is OVMF and/or grub propagating this information between > themselves and to Linux? > When booting Linux with SEV+UEFI, at least during the UEFI services, the UEFI firmware transparently handles #VC for the rest to allow it to perform CPUID operation. (with SEV-SNP CPUID page exposed with a specific UEFI mecanism) So overall, this proposal is only meaningful for PVH booting, everything that comes after can be handled differently. > Are they relying on the CPUID discovery logic mentioned above, or > there's some shadow infra used by KVM for example to already convey > it? > OVMF at its startup relies on #VC for emulating CPUID. It then relies on GHCB MSR for getting SEV info/C-bit (but only with SEV-ES). And under SEV-SNP, it uses "CPUID page" instead of GHCB (PAGE_TYPE_CPUID in SEV-SNP firmware ABI specification). This is because SEV/GHCB specification recommends using CPUID page under SEV-SNP (even though the same protocol as SEV-ES still works; but is discouraged). In GHCB Version 2 (SEV-SNP) > The hypervisor may supply the encryption bit position using the SEV Infor= mation MSR protocol, > but the guest should use the CPUID information supplied in the CPUID Page= to determine the > encryption bit position. But its location is unfortunately undefined in this specification and in the OVMF case, hardcoded in firmware metadata. > Adding Xen side-channels when there's an architectural defined way to > obtain the information is a duplication of interfaces, and could lead > to issues in the long run. We can not possibly be adding all vendor > SEV options to SIF_ flags just because they are cumbersome to fetch. > I know this is just one right now, but we don't know whether more of > those CPUID options would be needed at the start of day in the future. > That exists for SEV-ES and SEV-SNP (even though complicated) but for SEV-SNP, it would relies on discouraged mecanisms (GHCB CPUID Request). AFAIU, this flag is enough for setting up long mode and GHCB which is what matters. There are some additional structures (e.g secret page and CPUID page) which could in the future be eventually exposed as PVH modules; which would be hopefully less intrusive. -- Some specialized boot process for SEV-SNP (e.g the one used COCONUT-SVSM) relies on IGVM [1] with custom memory layouts, initial pagetables, and so on. [1] https://github.com/microsoft/igvm >>> ## AP startup ## >>> >>> AP startup can be performed using hypercalls or the local APIC if pr= esent. >>> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h >>> index 7f15204c38..9b84df573b 100644 >>> --- a/xen/include/public/xen.h >>> +++ b/xen/include/public/xen.h >>> @@ -890,6 +890,8 @@ typedef struct start_info start_info_t; >>> #define SIF_MOD_START_PFN (1<<3) /* Is mod_start a PFN? */ >>> #define SIF_VIRT_P2M_4TOOLS (1<<4) /* Do Xen tools understand a virt= . mapped */ >>> /* P->M making the 3 level tree o= bsolete? */ >>> +#define SIF_HVM_GHCB (1<<5) /* Domain is SEV-ES/SNP guest that = requires */ >>> + /* use of GHCB. */ > > A concern I have with this is that we are adding vendor-specific > terminology to what should otherwise be a vendor-agnostic interface. > > There's already a fair amount of arch-specific information encoded in > there, so maybe not that much of a big deal. > > Thanks, Roger. > -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Thu Jan 08 19:23:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 19:23:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198062.1515328 (Exim 4.92) (envelope-from ) id 1vdvbl-0006fs-4i; Thu, 08 Jan 2026 19:23:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198062.1515328; Thu, 08 Jan 2026 19:23:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdvbl-0006fl-0z; Thu, 08 Jan 2026 19:23:45 +0000 Received: by outflank-mailman (input) for mailman id 1198062; Thu, 08 Jan 2026 19:23:44 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdvbk-0006fe-6n for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 19:23:44 +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 8b29e824-ecc7-11f0-b15e-2bf370ae4941; Thu, 08 Jan 2026 20:23:42 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-b8440cb2dbeso351357366b.3 for ; Thu, 08 Jan 2026 11:23:42 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a5126d6sm886346166b.50.2026.01.08.11.23.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jan 2026 11:23:41 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8b29e824-ecc7-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767900222; x=1768505022; 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=PtjjgoXU0F5/I8+gXmjFZ3YHHHMSjoQgl8yEYuGXjJ0=; b=YpUYrhhECdF/gk2s56JjG+U8uu4AFKTe85sXGQRWlf17QIW9E9j3xWtnvlWiYoyJDS Uq+pnMovgQO5ygzls1cTXFDtsuaZoCdYh6XkjkiG/pWC4we5EiQaFZl5RpG1U+89P4mG x83mY8GwME5h3n9xURWqTyJpt2YZVS+WZC8KiUwnAZ4QB6okoTctmxQyjP0df3p2itg9 e8w6tgag+hVla0Ity6D/2jGcsyilRL3q/22PjIpgyHmIbIgbnSmweiC/NVDfAD/1pumT fEG1t5/NXaPsLVu5aBwBOZT0F/upo32UZdpgqNz0jVRK5TvrmtXBNGpbZDAsqnXWx4kN ISag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767900222; x=1768505022; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PtjjgoXU0F5/I8+gXmjFZ3YHHHMSjoQgl8yEYuGXjJ0=; b=aA4BLhn8gjSfJPoE9tiBRw3DIuVzBzjcV0UFbShogmmZ2cRUBVitspmAKfhvMDkIih lCHurDwVoj0yB7JuWSFvvBGyqDkALMMDUzFtep7cM9jHBTPVJquDXFNfDUXFqpZoGzeM AbClqHebM6WJOt6gTuzP5cC8Pjgu0C2tQjbhcvRd36htkTAPgqn+FbboibVWb57YTlCR PMsdB3YZYBguiXMLLVU8VYwNEr9fyoXQtSOzRjGubzgWswILc6RrpPLzlN5/mLmh33RK +Ym0/tJjXGcTZwX2uUJZPXW99IcNjMnpYchQmgjDi+I207sLh7ZElykvjg6WijOWWvMJ lxAA== X-Forwarded-Encrypted: i=1; AJvYcCUxPwbbgtcj75zGQMgbjvGq9EBh94Sxvk2MnbUXfykwcVUkw7JnK+WAqTY/cM3pDRmDAS96yeDZ8Tw=@lists.xenproject.org X-Gm-Message-State: AOJu0YzmOO6VgptpE3Ysl5rtAP2Bg5b/mJiv8Sp+mE8sf7tDSqUTGul/ w7FhkF4YziCriF4JcXx3LoTg4OFUAlaMQ4EwvKBXOZ9F2hoDyJfHiSBV X-Gm-Gg: AY/fxX747v0VGObbHiBdX5SmyOkdtg97veC7zhLjvqpF5mvE/ObpCPZ945Ad2xSZbk+ owcS2qVutaMPRq8pTUMSY4yGqg6T1G/sXmSXyw3BFl8ttsXoOroQD+ANI4Rn7Db7TCRgkxzvjHd bEg/Q8rtKWPtbcy8s2kmqOElFTi891UHzNf1ZnI/QFLHPv82y4d9csfZB7mTzRccGPmDdmA4tdb NAlsl+wqS/BFxmmdZqe/D3wDvIMH3VZJFKqO+N42Sw4SHphyhFD0lJAAhEsDjsqB8rSLByE3kAk /RllemPpJfnDYuZTnSgXu2fi/uv8sZ3EYtpH5Wf/+i2TS2waSO1Q4eLVc8kqnqKJV8OTwa6g/XJ 1O5olPJYTxTiIHB8BTCaBa1ep+evX+kVxyYQhmVY/RKB5CXX9AtpuyNi+vZWORAoK2j88oeBb0A YUurPZKuTPKiMT7206k0wx8hYwKcxZkZMqeXY5QZwCmpQNmNWzsJe7aliYrz8GjMs= X-Google-Smtp-Source: AGHT+IHyXB3kzGq9Y2KRpiE0WybncQNF+mg9qopLFnEgYtkqvSVddg0K9rpXfNdUw0jzTEgbMr1b7A== X-Received: by 2002:a17:907:3e20:b0:b76:5393:758d with SMTP id a640c23a62f3a-b8445345c45mr615622966b.34.1767900221923; Thu, 08 Jan 2026 11:23:41 -0800 (PST) Message-ID: Date: Thu, 8 Jan 2026 20:23:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] acpi/arm: relax MADT GICC entry length check to support newer ACPI revisions To: Jan Beulich Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Yann Dirson , Yann Sionneau , xen-devel@lists.xenproject.org References: <3850c51d41b1ab67a453ca70c0a44172185274f6.1767694781.git.oleksii.kurochko@gmail.com> <6ac0b4d8-3762-427e-a856-be9118e90dc0@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <6ac0b4d8-3762-427e-a856-be9118e90dc0@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/8/26 9:41 AM, Jan Beulich wrote: > On 07.01.2026 17:34, Oleksii Kurochko wrote: >> Newer ACPI revisions define the MADT GICC entry with Length = 82 bytes [1]. >> The current BAD_MADT_GICC_ENTRY() check rejects entries whose length does not >> match the known values, which leads to: >> GICv3: No valid GICC entries exist. >> as observed on the AmpereOne platform. >> >> To fix this, import the logic from Linux commit 9eb1c92b47c7: >> The BAD_MADT_GICC_ENTRY check is a little too strict because >> it rejects MADT entries that don't match the currently known >> lengths. We should remove this restriction to avoid problems >> if the table length changes. Future code which might depend on >> additional fields should be written to validate those fields >> before using them, rather than trying to globally check >> known MADT version lengths. >> >> Link: https://lkml.kernel.org/r/20181012192937.3819951-1-jeremy.linton@arm.com >> Signed-off-by: Jeremy Linton >> [lorenzo.pieralisi@arm.com: added MADT macro comments] >> Signed-off-by: Lorenzo Pieralisi >> Acked-by: Sudeep Holla >> Cc: Will Deacon >> Cc: Catalin Marinas >> Cc: Al Stone >> Cc: "Rafael J. Wysocki" >> Signed-off-by: Will Deacon >> >> As ACPI_MADT_GICC_LENGTH is dropped, update the functions where it is >> used. As we rewrite the MADT for hwdom, reuse the host GICC header length >> instead of ACPI_MADT_GICC_LENGTH. >> >> [1] https://uefi.org/specs/ACPI/6.6/05_ACPI_Software_Programming_Model.html#gic-cpu-interface-gicc-structure >> >> Reported-By: Yann Dirson >> Co-developed-by: Yann Sionneau >> Signed-off-by: Oleksii Kurochko >> Reviewed-by: Stefano Stabellini >> --- >> I ran CI tests where it made sense for this patch, as I don’t see any CI job >> that builds Xen with CONFIG_ACPI=y: >> https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/2229673951 >> >> I also built Xen manually with CONFIG_ACPI=y enabled and tested it on the >> AmpereOne platform. >> --- >> Changes in v2: >> - Update the commit message: >> - Use more characters for commit ID. >> - Drop 'import from'. >> - Add Reviewed-by: Stefano Stabellini . > Was this a legitimate thing to do, considering ... > >> - Make the local variables host_gicc const in gic_get_hwdom_madt_size(). >> (header variable isn't const as container_of() will discard 'const' qualifier >> and so compilation error will occur). >> - Return 0 instead of panic() in gic_get_hwdom_madt_size(). > ... all of these (plus leaving partly unaddressed a comment from Julien)? Probably you are right, it was to early. I will drop it and ask Stefano to re-review. > >> --- a/xen/arch/arm/gic.c >> +++ b/xen/arch/arm/gic.c >> @@ -418,8 +418,18 @@ unsigned long gic_get_hwdom_madt_size(const struct domain *d) >> { >> unsigned long madt_size; >> >> + struct acpi_subtable_header *header; > Why is there a blank line left between declarations? In unusual situations (very > many variables, for example) that may be okay, but otherwise the first blank line > generally wants to separate decls from statements. It was visually better for me to have header and host_gicc variable in a "separate block". I can drop a blank line. > > Also Julien asked for this to be const. You claimed a compile error would occur > if you do, but afaict that's only because ... > >> + const struct acpi_madt_generic_interrupt *host_gicc; >> + >> + header = acpi_table_get_entry_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT, 0); >> + if ( !header ) >> + return 0; >> + >> + host_gicc = container_of(header, struct acpi_madt_generic_interrupt, >> + header); > ... you don't use const properly here as well. Oh, right, I missed to add const for the second argument of container_of(). > > Finally (possibly not for this patch, but mentioning since originally it was > pointed out as an option) the function imo wants to become __init anyway, for > (as said by Julien) its only caller being so. I didn't put __init here as you mentioned it was pointed out as an option. Anyway I think I will put __init in the next patch version. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Jan 08 21:09:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 21:09:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198134.1515337 (Exim 4.92) (envelope-from ) id 1vdxFb-0001oS-98; Thu, 08 Jan 2026 21:08:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198134.1515337; Thu, 08 Jan 2026 21:08: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 1vdxFb-0001oL-64; Thu, 08 Jan 2026 21:08:59 +0000 Received: by outflank-mailman (input) for mailman id 1198134; Thu, 08 Jan 2026 21:08: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 1vdxFa-0001oF-FO for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 21:08:58 +0000 Received: from BL2PR02CU003.outbound.protection.outlook.com (mail-eastusazlp17011000f.outbound.protection.outlook.com [2a01:111:f403:c100::f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3d7f22ae-ecd6-11f0-b15e-2bf370ae4941; Thu, 08 Jan 2026 22:08:56 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by PH0PR03MB5669.namprd03.prod.outlook.com (2603:10b6:510:33::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.3; Thu, 8 Jan 2026 21:08:51 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.002; Thu, 8 Jan 2026 21:08: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: 3d7f22ae-ecd6-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Gptx12/RyU+UAJsXor04vXIeyQ2MnGIIvLlgSiu4g5kZN3RvkvDnyIuBm6oOqQU/HILFvMEd3n1R3EQcZfqazkkVUBIvVK1QWAlF/yEljLNcbUuAvrMQLBd+wxQWVh8zO+nkaT5h18GQcfY1wPM7pXL7gNCveAsZ3+tQUE073B5joz6ZLOCDxLUI/4/SFHyaEj/Y4FL3DEmIucL/YxDcuKUBVtwYJudCqKVn6JulEpDiHY+aStgRTuz+5YUPa//BrFl1T06ZqGfd2+hQetQCY2AmN1b+iHvknl2E2dG8nCR0BITsCbrJAHNo8xVWu66OQv89kYxJIfq4/n4dP3FOXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Ufw209kKfDJMc/AykLWlB6kEa/Uoa9Oo8aZrdexWpLE=; b=zJA8Iql3cNEwGLfhG2XSXODqC03ORS/ENv/+1Q3yq4f/DdyZgIepUZ+9WzTsJEMm0+GfWRQ+imaFfNNYIez3AYFDGrx6I/VhoPfRCvwQv8NAuSUIb3lZIs7Y9/4eKtgXaDK4iM+V6F4C12XZjZrUnXQGtSt17DTTWtniAJmtxqGp8i6mCt6jM1HKfwxI8T6P9ue+JqCM0LZQEGkaOo3D6gYkPn0ottsNnGbEzGZKwjG/ZxArANCq2GNzf/HisKH72+t1Y/y1xWbQIr5pGaaEattLaZL8V7iwRM/bsy1v3cU7Y0n3OFfNIPeT0XubD0XRToF2BOZE8MQa6dmmiCKelg== 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=Ufw209kKfDJMc/AykLWlB6kEa/Uoa9Oo8aZrdexWpLE=; b=ru6V81BlsWdUZHS+m4wi3Ry4JcpXSNogaTb4ez3ZCr/GEa6KfwGhcX68GAh965BqTVH+30A6BtdAP03+U8C7KBuAMaKYy2/l299xWPyKe96SsLBiEcdhODKIVGsFk6A/kbfqob0qU9iSw8mfYFgkSmHG/iQMqGWifbiuvQLw15A= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <91a64181-212b-4515-9e2e-82b3eb4b4364@citrix.com> Date: Thu, 8 Jan 2026 21:08:48 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel Subject: Re: [PATCH 2/4] x86/xstate: Rework XSAVE/XRSTOR given a newer toolchain baseline To: Jan Beulich References: <20251230135427.188440-1-andrew.cooper3@citrix.com> <20251230135427.188440-3-andrew.cooper3@citrix.com> <4b051e1f-0d99-4637-b433-bade93e67e0a@suse.com> <6062efac-8285-4062-926f-dc3ece871654@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <6062efac-8285-4062-926f-dc3ece871654@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0338.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18c::19) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PH0PR03MB5669:EE_ X-MS-Office365-Filtering-Correlation-Id: bb4be481-590d-435b-5078-08de4efa1fa1 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?dFNVVjMrb2ZKOUdiYStzQTU0REcvamNXR0lRL1BZdkpXNVcyMGhiTnVLSmNw?= =?utf-8?B?bVpqRkdocTZQMmQyUldiaUdCMVloZGRyaFdZUVI1WU9TSzM0WUp3UUkwZm9l?= =?utf-8?B?bUZQQ1RNOWlpL0dhMUZKaHhxTWxmS09GVXdkd2ZVQUQ4a0ZXb2NaMEtMM0x4?= =?utf-8?B?VWczQ25FQWU5dC9QUXNjdlR5OENZNC94YTRQc3ZpUTB1QTlDMnJiSnBtelJz?= =?utf-8?B?Y1ZwT1pIQ1pVWVVlTkNSR2J0a2s4dnlFMGlUaHFUaFYwcVY4SmFLaW5RMDBZ?= =?utf-8?B?Rnc5RmhPMnVWSVFiNlo1bmdDRmp4aTJuWkNtZk9TMGNNWWowWXZ2UGFHRGox?= =?utf-8?B?UVkyZUFmODQxM1o0NVNOdnNVZk1lZ1A1T2t0ZjA3L2ZCeXREaURQSFFIU0xs?= =?utf-8?B?b1RLMGExa3FyWDZaWGRBVFlKTkhhd2ZrWUhsbnlKbmJ3ZXFJVUh4eHVkTGd5?= =?utf-8?B?cE1CQTJlczRZTmFvTEFjM2V5Ly9XYjBkSXlUa2RKUEVJRGo3YmU4Q2I4d2c5?= =?utf-8?B?a21mZnBQeEhVT0UrWWdmTTNaKzdudDNqVnhVbWJxdjNVUk05c1Z1VlBHdFVk?= =?utf-8?B?MmJzOThuT05RWFNsOUkwYkF3eEtrNnlRYnQrYXFVSmVaYytSaXZhVS9CRjdy?= =?utf-8?B?c0lBay83N2VPSE9zS1pyVmFYdElMcWU1R3Nlanl5MzJyejJIT283OEtYNS9Y?= =?utf-8?B?RnZxUkdIMmVlU2xTZGZSbnRaZmhOVi9HR0pKbXB6NVVMY2NmN0ZZNGdLa2d0?= =?utf-8?B?a1pxeWhQZlh1dEIwSDA2bnNuZndkSlZqTER2MENlSXhtWUxEZVEzdVpEbWNn?= =?utf-8?B?R2JOSUVPbWpFZGJCdHFITUJ0aVNvSWdyRERXQlJYaVdrZlNuOEN0SCtacWdu?= =?utf-8?B?SGN5d09leHZjMmxaQ2lUOERXTFd5SEpkVERzdEx3d3VVK2h3R1Z5SDN3VTJC?= =?utf-8?B?dk9NN3VrSENZZWtPa2VJQytPY3l4ZnZMOVVUS0tTeEpRbXNya3k4Q1B3WjJn?= =?utf-8?B?WlJXbGdCanh6RjNCUkdVOGJqQ2dZZG1KNExScmhKSm5uVngwRytYcTVIS1VD?= =?utf-8?B?UzV2Z2V5YXFpdGIybVhWYmxXZlVNQVMzVEw1c1pqdlQwNktiZDlqOStDdUFK?= =?utf-8?B?amN4bzVTWXgxNnE1UVh2bmRXdGs5QU9tVEo2b2JkdU9qekhjZko1NWRBd1NX?= =?utf-8?B?U1hsWTlNaGttRVVqODN6MzdITC95bS9BT2ZHWmxWSVB5OXNxdEd1TkQ4SXVp?= =?utf-8?B?eEpYQkJiUlpPZE1qNkdXQkZLNzlYT2x1ckI2YnFjUU8xd2tpZE9rMHNmdmZM?= =?utf-8?B?cVRVaER4OTVRYUhTcVA3NjE5MmpQeXNvTGo3Nk8rdHZwajY3WmVkRDJ4Unc4?= =?utf-8?B?S3dlb1ROSUNncWpJcUFqN24xN0E1WUJUejBBVVA4a0dldUNCZFlZZEd3dGJV?= =?utf-8?B?WHdhbHAzWkpkTEVQQWhjMkRJaHJRTDFLbnVhRGpvc3NCWFo3ODBmTzRxemVP?= =?utf-8?B?clcxY3R6cWc0V2JvNjJLdFd6MmZaME1mNTJ3bDBzSnNObnprOWZMQXpNa3BF?= =?utf-8?B?UXg5UEc4RTFQQ1k2RWhZZE5HSmV2N1BXdHRBQ0YrMW90STZjOXZUZmJHOCtE?= =?utf-8?B?ZmlLaTVVU0ZaUEhYK2EwQ09CcEVtS0E2VXNnNTRWLzhOcGJTYktIQ0Z6c0hH?= =?utf-8?B?OUpNVk9SRU9DQWtlZFVpcGI5U3JEd2tFMWh4V2lnTXovU2F0azNYUmNzS2Y3?= =?utf-8?B?ZjRsM1JkdjMzVW5seVpnbk8zbXhqSXlPWExjMWlQRXhiVXJsMnFkMWh1RTF2?= =?utf-8?B?Ymt4NXMvUllVSTZEbUNSMHNIMUIwRzZPd2l0akoyTE9QWnRvYkRIMVg4MHFv?= =?utf-8?B?ejJOS3kvN0tXN0VCRGNjQWM5Zy9MNG5lTVJxUWVUY1d3U216bC8rdlVlbE1t?= =?utf-8?Q?JRE+FBfQAKDvQHAoco9SDPwyMQIK/iYR?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NGE5dmxzc1FCTFE1TWl2bHVzOCt2N3UwaUdLN0V4dEFkSmFSRytiS0tMNjd4?= =?utf-8?B?T0JpNXpXNzFkd2R5dTZDcnIvaTBOd2J5eStjRnhtb1Bya2QyMjVCdWJGWEsr?= =?utf-8?B?dnJIMStSU05DczVlZ04xdWJqNkZ6dXdLWmsyWHU4TGpNaGQ4RGpWMEhueHZh?= =?utf-8?B?NjNoOGtxbk1OTGV0NEpoemJZZ3U1bzBIbVg1NUJYdWg0T0FqZzhxL1IxdjVC?= =?utf-8?B?Z09rZ3RwVkxhb05KZDdWVHdETmpJcnQyK25MZ1FTVVJVcHZxM0QxZ3FGQ1Bu?= =?utf-8?B?Z3ZxOG9TcjEvdjljZUduSEc3dlBoOTFtaisvT3Z6dVdoVnFUL2pYeVk2MCt6?= =?utf-8?B?N2hXOHlRMkFrZGozRHhKb01qOWI3RUdFM1oyVFk3OEYxTEV5MkhTbE9pYjAw?= =?utf-8?B?MzYrMFh3bFphY2gxL1JkdEsxV2ZJcVBYaVJ1RFlyYThuZ3B6R0E5R1A0K3pq?= =?utf-8?B?NXJ1YmY2TU96dGtlZHhSZTQzL0t0cG85QWVaMWtXcXlrUkc0eXZlSDJVY1gz?= =?utf-8?B?TjkrRjV3VFlXVE1jUy9Tcy9EakQ1MDBsbi8zaW5ZOW5qaUgrK0t0Wm11cjFq?= =?utf-8?B?eXR5TlRZNDU1UU1GNW56NVh3RnhNQy9meWJOb0FUWHlFSEcyRXF5U2YrWWJQ?= =?utf-8?B?VUFkTDd3RTRhSHg5MThkczA1UStpWElLUEMxOGI1bzFwY3VWUW5idUZWVHZo?= =?utf-8?B?Q0svUWRKOFNOUHhLUk9uVGtucDBDWE5qWnFJOGMrRDZSWitHcE1uRkl2ZlBv?= =?utf-8?B?Z2JEMzhVa1pRQVYvSHljQklmVFhuVVBnelR5TnkyTDRGV29sSHZ2WW9NWXht?= =?utf-8?B?Um1pTjlZQitTWGI1UFd5Tkw3RXpCUFR6WU1HRXF5WVpFSEMxUHNsa05iMlZi?= =?utf-8?B?MlozY0cvM2V0SDJKaUdtc2E4akQwalQ2YTlhT0dpbVFlZE9XVkVMWk9TeHNp?= =?utf-8?B?TEw2MVVtSmo4VUYwRTcvUmtra3pQK3V5U0VmS3lkR1ZDdHV6YXIwTHFONFQw?= =?utf-8?B?QTNoMnVNNm84d1gyNDRVRnR6ZUJ6WlpSNHhpOE5jazhWV05nV3NEZ0duc3Ro?= =?utf-8?B?Ui9ud2tsM2VLQnArUlp3VUJzR0lYS3phT2R2bkk0dy9KazFJWEloTjMrcklx?= =?utf-8?B?c3oyQ0F6V0ZOdWRvYy95bWVwU2ZKcmltNzBPRFZRK1lZU2pHNGVYTjd6emRm?= =?utf-8?B?dE9rWHFWQ29Ua1NXOVNtOGE0WWgrVUlVQmY2ZGs0bWhCdzZ4YUhrR3NCeHFs?= =?utf-8?B?TXFSZU9kcHVuOVRlUlZzUUREaUt1djN2Ulk2eU5ySktGMGZNVXYyZ3hmSWpj?= =?utf-8?B?RTFzeE10dkhVOHd4NWVsbW0wZEVRNXNsTGl0OFRJdk5UQ0JGd29QZjhNVXRz?= =?utf-8?B?SG05elRvN3BUdE56WnovSGMvWFBiOERWaFhGclczQno1K1JqTnRxQzBCZS9t?= =?utf-8?B?aHU5dHAzZGcxeW1FdFlrQ25McW9Ua3prYzNNMitPOVAvbWNaNjFRSlNONkRV?= =?utf-8?B?bXI1VExFQWRDOXc0WFFEcXBtTUcxcUJxRzFETUY0STlhbjJZSHdsTkQ0UHpv?= =?utf-8?B?TTE3L3dMdy81Mi8zbjVodjVDV3lEYS80d25QVWpvSHN1bUlZRWJzRlI4a0Fz?= =?utf-8?B?N2dQK2pVWXE2ZHNzaHhadXk1aXR6citXOGpmNHd1VFJIQ2QyMVIzNFRhdU54?= =?utf-8?B?Zk03Y2xnZjdldXhCM1NRc1N4ZlVnN3lScUI3ZCtNcWV4MTlacnJqM3c2TmpP?= =?utf-8?B?bll3UVE1TDI2QThEMFFxYkYrcHJqTngyRXdkRHhUdTVyK0p4RE5ROXViNWVF?= =?utf-8?B?TUk0YW0zc0FzTk5xQXkvbzhmTTVsUDFEL3RiYjN0TEF5RDVsamZQTDE0d3hS?= =?utf-8?B?SUVxSWF6UElyUXhBUWZkWVVnMWFFSGNkNDUwNlh0bkxsQ0pLNFV1MTJxQytP?= =?utf-8?B?NFVQUVZyMTBBUXkyUER1L1RvbHV6cGYzNVFJVkxiOWNEaHZqSjBPeXVnQ0NS?= =?utf-8?B?UUxid0FoajhUVjk1YmUrT3lFNWltZ0JVeDI1YXJpbmhDc0ovcHJteUVlb05I?= =?utf-8?B?d0grUkdHeEdQNzV6Uk1UanZYYVhKK2xHRGFYa0VFRE5yK2tLRnlicWR1em43?= =?utf-8?B?eDJnRW11VzczdSs4dlpsTUVnZHVKdTZQeWdjNmFjUG5JYUxmQWltcGhPWXhm?= =?utf-8?B?Q2pDcFdrQXpqVXJOMGxYYSs5djdna3F3cEZva1p5bC93bmFaSDJhTnJRSWx0?= =?utf-8?B?WWZpa2VxOXczcmsvZjlxVmVZckd1S1hmYkx3MDJ2dzFGY3pXR0drMXRYdVNC?= =?utf-8?B?c1RPWnlJaWFCcjZKRTUxYU1Ma2FoYTRKLzZ3aDJzaHdmQVhZUWcwci9JWlpo?= =?utf-8?Q?jVPl274jpcJ2wcMo=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: bb4be481-590d-435b-5078-08de4efa1fa1 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2026 21:08:51.3367 (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: mTxVWpDtrAwwIOgG53sbtkDEqsI+K5fL9u38ck08aM5TBV4k0vgDFhJ+HIRUOgsjnzPP9MI3X8MwLi8EPBVjDqbZztSNRAfyJd20VDFKhvk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB5669 On 06/01/2026 7:59 am, Jan Beulich wrote: >>>> @@ -489,17 +484,17 @@ void xrstor(struct vcpu *v, uint64_t mask) >>>> ptr->xsave_hdr.xcomp_bv = 0; >>>> } >>>> memset(ptr->xsave_hdr.reserved, 0, sizeof(ptr->xsave_hdr.reserved)); >>>> - continue; >>>> + goto retry; >>>> >>>> case 2: /* Stage 2: Reset all state. */ >>>> ptr->fpu_sse.mxcsr = MXCSR_DEFAULT; >>>> ptr->xsave_hdr.xstate_bv = 0; >>>> ptr->xsave_hdr.xcomp_bv = v->arch.xcr0_accum & XSTATE_XSAVES_ONLY >>>> ? XSTATE_COMPACTION_ENABLED : 0; >>>> - continue; >>>> - } >>>> + goto retry; >>>> >>>> - domain_crash(current->domain); >>>> + default: /* Stage 3: Nothing else to do. */ >>>> + domain_crash(v->domain, "Uncorrectable XRSTOR fault\n"); >>>> return; >>> There's an unexplained change here as to which domain is being crashed. >>> You switch to crashing the subject domain, yet if that's not also the >>> requester, it isn't "guilty" in causing the observed fault. >> So dom0 should be crashed because there bad data in the migration stream? > Well, I'm not saying the behavior needs to stay like this, or that's it's > the best of all possible options. But in principle Dom0 could sanitize the > migration stream before passing it to Xen. So it is still first and foremost > Dom0 which is to blame. BNDCFGU contains a pointer which, for PV context, needs access_ok(), not just a regular canonical check.  Most supervisor states are in a similar position. Just because Xen has managed to get away without such checks (by not yet supporting a state where it matters), I don't agree that its safe to trust dom0 to do this. For this case, it's v's xstate buffer which cannot be loaded, so it's v which cannot be context switched into, and must be crashed.  More below. >> v is always curr. > Not quite - see xstate_set_init(). Also more below. > And for some of the callers of > hvm_update_guest_cr() I also don't think they always act on current. In > particular hvm_vcpu_reset_state() never does, I suppose (not the least > because of the vcpu_pause() in its sole caller). We discussed the need to not be remotely poking register state like that.  But I don't see where the connection is between hvm_update_guest_cr() and xsave()/xrstor(). Tangent: hvm_vcpu_reset_state() is terribly named as it's attempting to put the vCPU into the INIT state, not the #RESET set. But it only operates on the xstate header in memory while the target is de-scheduled.  It's not using XSAVE/XRSTOR to load the results into registers as far as I can tell. > >>   XRSTOR can't be used correctly outside of the subject context, > Then are you suggesting e.g. xstate_set_init() is buggy? No, but it switches into enough of v's context to function.  Really its neither current nor remote context. But, it's single caller is adjust_bnd() in the emulator so it's always actually current context with a no-op on xcr0. As said on Matrix, I think it's going to be necessary to remove MPX to continue the XSAVE cleanup. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Jan 08 21:14:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 08 Jan 2026 21:14:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198150.1515347 (Exim 4.92) (envelope-from ) id 1vdxLI-0003Pn-Vm; Thu, 08 Jan 2026 21:14:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198150.1515347; Thu, 08 Jan 2026 21:14:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vdxLI-0003Pg-Sc; Thu, 08 Jan 2026 21:14:52 +0000 Received: by outflank-mailman (input) for mailman id 1198150; Thu, 08 Jan 2026 21:14: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 1vdxLH-0003Pa-OI for xen-devel@lists.xenproject.org; Thu, 08 Jan 2026 21:14:51 +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 101c13b9-ecd7-11f0-9ccf-f158ae23cfc8; Thu, 08 Jan 2026 22:14:49 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by PH0PR03MB5669.namprd03.prod.outlook.com (2603:10b6:510:33::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.3; Thu, 8 Jan 2026 21:14:46 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.002; Thu, 8 Jan 2026 21:14: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: 101c13b9-ecd7-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XZ/CKN+3JISeP7pJnO5JRHtstM/06kLUfVFgQ1MYyNhjKrrVvYi8Ph5W8hsEjNp9qL3R6fPvhoS2eDdElB0Ldr0UHTbMPvqIj3SMU7gq2vOkF9JIQ/03OcgKcLpIUpzgDO7owDL1ne94nCprTDfuV0RYEe3vLhEmd2G5O0M5n01kKWOrf1VP5RpheIqXkYlUwWW4MFcQfQyEs2VI58RR1SBmoGa5JPMMxVKFiEGjok2pZi9h3+DAMqFx1csCKmhSpdvg7natM46veHuPSUA7GjGGDFxD5Q3bpgbWQ2HTzH4gStaDT1cgvnAkweDb+tQdC15/arn/znZLlEQOspSQvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0jpXeB/XVHxZbOd4fofwNGRIM3GOxc8aOGrrtgvNOXM=; b=u+T0c2VKK2aPESdXQGX5ooO7kiFd9rB4OnLZUgnS/Hh5pOYMNWpK15VzdOavCCMM7HpN+yhBCXz4wFdm6KJpVTFC55L4yVT69N+nIjTx7RqbwVYyWiIgYGNWt8Vl6/hHDhGjUcawBcmCEQ5VNdc4RrkqJx8a9bEi3Ms4QT7VJlx73tCvE1QMGGlMUWTFQL9hO9XMBJtyGxLq3SUWz7Jb+CdUa+B5hDdllKoQ2GVWwdD5orTG6RmNcS49X5JCE1ROGDDZqV6BmysxJe6J/cD7krS9ln0K4gysxsa1Td9T4tSQ0LUrw1OpxEdI78aGO2GTOfqHmIkELd4/XupE/Ffqzg== 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=0jpXeB/XVHxZbOd4fofwNGRIM3GOxc8aOGrrtgvNOXM=; b=ZcJ678WspRsclMsTAGd5AH1Jisnezhenv9S7e96PqjHubC8av+S1WQkvfWavX8fN5BQ+DYfwlACZ2cyKyoprGeZS0jhPculbcxEfFep+GsI5qSquwwNmqQBKKBUfTt/uM0Cx/wSQWOInZNQ3SFL9MRw3f9mQuR5jKvDq4cqtpX0= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <7aa65893-c0d7-4739-98df-e64e48f168e3@citrix.com> Date: Thu, 8 Jan 2026 21:14:42 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel Subject: Re: [PATCH 4/4] x86: Avoid using .byte for instructions where safe to do so To: Jan Beulich References: <20251230135427.188440-1-andrew.cooper3@citrix.com> <20251230135427.188440-5-andrew.cooper3@citrix.com> <673f05ca-39d7-4219-86bc-044a84e46699@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <673f05ca-39d7-4219-86bc-044a84e46699@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0320.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:197::19) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PH0PR03MB5669:EE_ X-MS-Office365-Filtering-Correlation-Id: d6fc3e9e-0f78-4d77-6dc3-08de4efaf30f 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?VU8zNmd6Q2I2aHRmcE14U3RydTlvNE5SQXlNMzdldTlWdlVkR1JxcmdNVkha?= =?utf-8?B?dmlHN1oyazMvYkU0OE0vRmtPVkwvK1NnN3g5VHJDQXROMUcyaHhsSmIwbGhq?= =?utf-8?B?bDU4SGI5b2NhZnViNmhHVjdJNUQ2NXZod2J6MVI4YnJyU0V5TS9vTFdZSTBG?= =?utf-8?B?NkpZaENqUkFldkVMUFNIcExTMkpoTkR4NHd4STk3Zks1aUtUMEZUZjRXaU5L?= =?utf-8?B?bWcvcWE1NFRmTW9yM2t1UEZoSkk0NnYwMy9uMGtlQ21mN0l1NzB3RkJlNzhE?= =?utf-8?B?QkNpVlJhOURVVjNFczBnSVBaUDMwWWxBR3F0aDd4dU5vRytnVllsR3B1ZHRy?= =?utf-8?B?c1JOQmFGWVBvRWk4d0RsNEVyQjIrblErS29pb00xU2ZHOTNxdVg4Q2hqQUhF?= =?utf-8?B?V1RNNEJNdUUwcy9tNlVPa1Q3dThOWlBVVnVaV0pjR3A3T1RuSm0zb2szdnNR?= =?utf-8?B?S2tDYjJzU1hOWEVKZ2FTV0xkVUxGRGZLeHYvajFVaUpJUWFOb1NnMkxaNFZD?= =?utf-8?B?cG5jRDVsSytNaVlZMGFSVjZTSzlqbzkyaDFVMzZHMWxRdU9pZFY1ZjdLcWNH?= =?utf-8?B?cDZjUFNCWHZmbVl1bVRCWWRDS2FvSElkd3o0cmNOY0piTXFUNzZRSEVXUVlk?= =?utf-8?B?TXJvYXIwMGlVdkF5bHZJdlFYSWIyOWQzN2tSWExXRWFQcDJOSkNjeU1RQWhN?= =?utf-8?B?UTlHWGtHMnF6OElLdVVBdWlVT1BONVlsV2Z3SVdrcW1ibWllZWQ2VnNFSVpm?= =?utf-8?B?M1FpdXorU2R5cU5EZVh6M0owem5XQndRS2daSlZrcmRtTFlCbm5BT2o1Yjhq?= =?utf-8?B?NkhzTExZRExEMHA2c3VEVWVCZkJHZE9PUkZVZUtuTlk4dzQzdEhGbzhrazZu?= =?utf-8?B?UnhWS2NudjY3bkhPK2VyeEhDekxjN2NjQjBpd2NNNFFyVGo4aHl6MmptQ0ND?= =?utf-8?B?K0ZHdlMvU2t1WHJyTlBCRDJiSDQ3TGJkNEhXOUg0bjVrZENRUmlaemd6Yk8w?= =?utf-8?B?R2hoMjJ2R0xVd3E2dFRJdHdFME13M3IxNFllbVdDSGpHVG44SitIR2VHaHBi?= =?utf-8?B?SUpNZVJYZUVSb015eTBFM29mTTBFOWNlckZuNXJTcSsxcGlKZEM2czYwSFZx?= =?utf-8?B?MmpsL1laK3lNdGJLcmJhTVFuTC8xbFFhTC9xUFVjanNNRzlPTElDZDA4RXJ4?= =?utf-8?B?d3lreGNUenpiRW9CRXp0MEYrVTJPeHVLQWtlYmFSQ1JXdUQ3ZWFGTi8xZUhI?= =?utf-8?B?SkxkbHkvanNWK1RMREFDSE9NTUxocWhkdHM1V2RYdWM4K0JUaFVNT2lldXJN?= =?utf-8?B?T2FKQnhmQ25EWDRySnJoWUFKK1dIQzl4bHp5dlpLaFp6MXlTSEMzU3E5WWVN?= =?utf-8?B?dzFMNDN5dkh4dndRa2VBRHZna0ZaOERtMXgvTzNycEh6aDB5ekdSR05QcDA4?= =?utf-8?B?T1hMeHZIaENjYVJ6RFBoS1IzYzFWeGdVWkdNalFEcktYSzY2TUU4OTBCNUtI?= =?utf-8?B?STliWkNQK01oRU13YnhJamx1ZTRzZHVxVFVhM3NpY1d2THRyYmVDT1RxaFlp?= =?utf-8?B?WnNyaUlzcXQrRnJjMHJzZTJSdzhXTEhPTTlCLzMwSGRwL01TTVNpU1RDN0x3?= =?utf-8?B?S1lURDZXb01CUzdybzZCK0ZIYktFUFZacUVWcTI2K1EvalpDM1JGalI4VGN1?= =?utf-8?B?SWdoU0RrRThyTzdOOHJXM2FUTlAvNncxLyszMFVvQzFERDVtYkNnZElWVmhJ?= =?utf-8?B?SVhYNGJiUlVDN3FEMmUreW1pWVZYMnNKVnFaN0tMOGdHbE0xbVZ6aTQvN2pV?= =?utf-8?B?WFJhZ2p2Y3Rra0FGU2VUaFF5Y2hCdnlBaG1WdnVOWjFOVDQwU0JmeVJ1c0h3?= =?utf-8?B?VEEzU2RVQS9ISnVmQ0VTVXg5QkIrRW52aVJBcHNtVWc5MEdKbGFoT1FsQW1R?= =?utf-8?Q?9eypZMfpupQnT8Xa08DHNRdvC2buwwZ+?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Y2xqM2NnQUNiTUM0Uk9DbWdhd2cwdUJQYnZwQWlEcTZoUmFQb0QyOERkYldS?= =?utf-8?B?V016WUlnQnhLRktCaWhSRzBuS080OHdPQ1NtaHgvUWIyeXYwZjRlSk1qdFcz?= =?utf-8?B?OTJWM2tFY3lBcjV5b0hGcklDa0J3RG1sUlIvaTQvaEwwTEhWRnlYV1BHbnlM?= =?utf-8?B?WXlIbXlMUzBienk0Uld2UVJ0U2M0b1I2bk1Ec2RuZSsrbVc4N05SQjhwd1I0?= =?utf-8?B?VlNZWWFDRE5vMmpMRWxuckhPSE84NW9LbWs5Z0lidk5sL1FPNmtNTWVLMHp5?= =?utf-8?B?QzRVRzdzRlFwYUhwNnRLWW4vUUtxcEZyamdvWk9RVERWcE1hTEc3c3AyM1Y5?= =?utf-8?B?ejUzTnlCazIvTUJXT09YZGlnTzBlY1BSaFRMSEN4MUR0MkxLczVlbFg3cjMx?= =?utf-8?B?V0llM21JTlJGQlpLelVNRnhUcWtXaG0veFREZDh6VWRrenp1cC9IZ1h6WGR0?= =?utf-8?B?WG85eFhocHpXK1JXZDFuaXRqOWZkK3BDYmcrV1EvdWJ5Z1A4MWowNE1KOE5x?= =?utf-8?B?dDJlYzZBVWpWc1NuZ1IyZzluUytiTTdZTkpNUGlFYjVueHlNSUJHNm1pbUll?= =?utf-8?B?cDZjTTczWGtIZEo5cElBVURaOWpodXhtNExmL1d0aDVIMUM3RHU1NUMvOXY5?= =?utf-8?B?WGxtcm0reWJKRHg0bWdiVjEyV2M2d3VQK0hPTTRLQnFzWkc3bHkzc1ZEWVYx?= =?utf-8?B?TStmeER0SkRLMTRrc3ppdW92R1dQWUdzM1pCMmt1N0RTcGhNMk9tQS8xZEF6?= =?utf-8?B?UXY2TFlxOUZUbnVnb2pVRHdmckd6c3ZtU0dqdURkNmV0cTBEY3JKUjdZdC9G?= =?utf-8?B?WExtK2xMRkp2Rnl1TUFtbjFJNUtzODVkZTZyYzBaTkZva01ueFpab210ZVlD?= =?utf-8?B?QXJNMCsrRFdqbVJGOXBmajkxVlJwbEQyM2xMNjRzZDBsV04wMEk3N0ZDWGpz?= =?utf-8?B?NGU5Q0JVbUtGMmtraUZySjlFNHhOd3Q2TjFPNkZOVitKNXFJOG01WDlKTmdG?= =?utf-8?B?VGcycXVqNUpxQXpUemtLeXZpcWExZ0VrcXp2c1N4eGovRlJLUVYzcCszaGNy?= =?utf-8?B?dUgzM0w4NC9KYzJQUFVpdWs3SThHRGtPWU1iTjRTNXlHaDByYzNXZXJ0Q25v?= =?utf-8?B?a2RNU0dud0t2MnhCV3pIQnAxc3V1dVlYN3JxM0FYUWUyZnVjSmFPNkhVVzhU?= =?utf-8?B?Z3ZZWkwzOEh0UldUdkppN2o4dmxtTFBoSFJDampKLzYyY0JndGpzZ3h3aFYy?= =?utf-8?B?YWx3ZDVHYXU5cDZSVUNBUVVMWmtDOVdSZWxHR2JjODFiZTQzdHdrNFlNbVZk?= =?utf-8?B?K1dnSmNvSzByQ0JiTHBmbWdwOG9aVjd2dFBFTnFMd1BTRjUyVXZvT2dySVpt?= =?utf-8?B?ak0zWXBsQnkzbkVZdHFJemVQUDRCdE1JL0wvMHRseXpkY2cvcmdzRzA0dUR5?= =?utf-8?B?ODRSelc1WlBrWkphWGhlQ2xIWitKVU9lc09vZ2gxWW5qc2VHb2lDZWNXMmE1?= =?utf-8?B?UzZCeGNmU08xTytaOTdIVXBtanNiL2Q4ZTlQZENPc01laDdvM2I0eHFHdG1H?= =?utf-8?B?SVpoSnlKc1JZTWpaMlI5QjBOeWZYdTJCd2VkcFlTTWhETHR4NENWeWw0cUFN?= =?utf-8?B?SitxUkRmUHVQWXhjSUxUYkI3ZnVER0RIdmxZUU5KUjVXVGY3Nms0elQ1Ynh1?= =?utf-8?B?bHdoQkNiR05rNlUzS25OK3ovdkV0bU9vVHR2M3pEd0o2R0pDQ2VzaXQ4eVFH?= =?utf-8?B?OFdvcmpFbUVCc3RNUFVMYzRUaEloV09VR1FCWk9ZdWs3WGgvM1BkZjV1THA4?= =?utf-8?B?RGlrektSWlkzcTEvdHMyNTErYkxXTHdXNmVFd2NYbmc0akRwVitORmc5WGVN?= =?utf-8?B?WWhQTmNpdkZPekl0TStrS29jNisvUXB3S2s2ZkVoakNCQVJuak9BUXFtTkV1?= =?utf-8?B?WnlRNVdoVzRwbXZCaTlBSE8vMXp1Z0Z2REtpRGFYTEh4VTkxTFArQjRCQ3gz?= =?utf-8?B?K3YreUQ3b3JTei81K1ZyV1J1TXM5UytKR3dXTFpCVG1pamlsbCtnWkJVY296?= =?utf-8?B?V3NNS2lRRlBjSEdsWEFDdklEZEt4UDZKMXNhRTlKaFh5MzZwajFUQXFuWGlx?= =?utf-8?B?dGgxQ2lGSkdqVXhyS29aWFp1NTc2TVFIemFSOVRPT1NkUkRsaEl5RWhBWWNT?= =?utf-8?B?UWN6K283a0JnbkRuSjAxTWprQnhncUt4OUkrN0IrYnkxUGgxc0FsTlIvTGI4?= =?utf-8?B?VmdqQ29TcmRkYUJ2dmNWUTFFU2lBajZFYnV2VlhvRVNKRlpMcjJUSU92QXRH?= =?utf-8?B?R0hGdnF1MktaKzcvVVpqdUIweVAzRU5oNzBCR2l1TWw3RytVUnV2OFcvMUxs?= =?utf-8?Q?5LphLhI4gTRor0IE=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: d6fc3e9e-0f78-4d77-6dc3-08de4efaf30f X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2026 21:14:46.0563 (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: cTYoEg05hErDXnhB6jOaMaA2bAUaCfzBMJqdr4zuEKPJ+CFhnpqJVGRFXkEpeXA+6IVitM+ZDZMduvcqURKlbSs6pSSLPKVGIVJVyjYag6s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB5669 On 05/01/2026 3:58 pm, Jan Beulich wrote: > On 30.12.2025 14:54, Andrew Cooper wrote: >> --- a/xen/arch/x86/include/asm/asm-defns.h >> +++ b/xen/arch/x86/include/asm/asm-defns.h >> @@ -1,9 +1,5 @@ >> #include >> >> -.macro clzero >> - .byte 0x0f, 0x01, 0xfc >> -.endm > This can't go away yet, as it became known to gas only in 2.26. > >> --- a/xen/arch/x86/include/asm/prot-key.h >> +++ b/xen/arch/x86/include/asm/prot-key.h >> @@ -19,16 +19,14 @@ static inline uint32_t rdpkru(void) >> { >> uint32_t pkru; >> >> - asm volatile ( ".byte 0x0f,0x01,0xee" >> - : "=a" (pkru) : "c" (0) : "dx" ); >> + asm volatile ( "rdpkru" : "=a" (pkru) : "c" (0) : "dx" ); >> >> return pkru; >> } >> >> static inline void wrpkru(uint32_t pkru) >> { >> - asm volatile ( ".byte 0x0f,0x01,0xef" >> - :: "a" (pkru), "d" (0), "c" (0) ); >> + asm volatile ( "wrpkru" :: "a" (pkru), "d" (0), "c" (0) ); >> } > Same for both of these. Oh - so they did. This is a fairly old patch, and I don't recall exactly how I did the analysis, but it was clearly wrong now I've double checked the 2.25 branch. I'll annotate these rather than dropping them. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jan 09 08:16:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 08:16:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198407.1515375 (Exim 4.92) (envelope-from ) id 1ve7fW-00020q-Pp; Fri, 09 Jan 2026 08:16:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198407.1515375; Fri, 09 Jan 2026 08:16:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ve7fW-00020j-LE; Fri, 09 Jan 2026 08:16:26 +0000 Received: by outflank-mailman (input) for mailman id 1198407; Fri, 09 Jan 2026 08:16:25 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ve7fV-00020d-Ah for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 08:16:25 +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 7b4512a8-ed33-11f0-9ccf-f158ae23cfc8; Fri, 09 Jan 2026 09:16:22 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-477ba2c1ca2so43211075e9.2 for ; Fri, 09 Jan 2026 00:16:21 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5df8besm20162733f8f.26.2026.01.09.00.16.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jan 2026 00:16:20 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7b4512a8-ed33-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767946581; x=1768551381; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=gCFlP9fxNsC6ga/seMa0KvAYvbrh+d170swkw77Is9k=; b=Ln73PTAKWlLjJEaPtjsbp23J6EbekVa/MLqe/mKUOLWUzWsvfcczgFwUk4+vzZX+AH z7ovwi/0B9DXu8p8o7JUYqW5IjGR9mHf9OJr5G6IeqG25O+liJV8ZH0YaTjmZfojBTBH eJLTb3jHAWeYN9Yw29xyqgAcO/Tkv/0GAGwX8xtI0b385fEZViFcwSqM5x1Q1G6f6c+8 jupSmFv8b86ZhcFMQNNkz9wSD5yjNxhTZ6z5ZGHR1aXJXbOLxAVWA2B4LoJzi4vzhTVJ kvKnANuumMpelFr99v3QN8GifKkAXmPxtDHoMNYqsItgl4JPwJml4YV9qZDByIjdySkw w3Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767946581; x=1768551381; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gCFlP9fxNsC6ga/seMa0KvAYvbrh+d170swkw77Is9k=; b=Oo8PmGCpQUh53sLZGG6leWmvcvZI3w8+AEFBD9EhjcLuAQADqeBxH1UVIpBPAABqTC wtpN820usuO47Foo2YQ6RRcaFtzKsDOQkH+2Kqy+0iqwVKeUzTWWlPP1yvwgA/hHuqNx A3aV+3vo1SAu8CSBHiIl+madp9FakRCT4aQmz/btXbCu7HoxVSR/AlQhrW9838uzPJrl kamVpuqdJOKkrO8TvIWqKyEfLkww+x/qEYcJ3hDQ3GaAJowtSYXhxC6CoXjvqkNU3AYP jM0ord1lVf9A1SR6w/DzppeRPtTCqYtn9tOgqLBbKOmCRcEqY2lEdqD9psUIUpbKI3/6 RXcA== X-Forwarded-Encrypted: i=1; AJvYcCXooRmC1biQX58KWgh1JdDFVGpIObWOoVpCvJuzfoOHQD9Dn76iaZoK5sh7tfoksLjAc7XyvMCx0PU=@lists.xenproject.org X-Gm-Message-State: AOJu0YwN/NCCf6S1GJvB8cTyhjujmUZlE9Nx00bQn9hVJLzWDx+p/He0 JaKobA5zvZ1enrcI1bISKL6crZKsd+DR56bgIz8z4GBdEbgVNSlMFiMboqT7lMH4nA== X-Gm-Gg: AY/fxX6ixYsRyJUU6B33x56fgDiK9/z9NFmJuWS94ecOU02GRH5j5sqz76FdAWteWkx ZbNrXT2M/JQByNIu/uxvWIpw8O7kH+hGRnYkfEyWG49By5I7sKHbCVyk99/m6V943xOG3RcrdoP mHE7ls9i5vU9ieXhu2gniuy7tTBMPa9fzjVqDqwEzj2Lc3r+OKt+eX038tHvR6GYG20Pl8vsHmH v2t3lio/IwKDlOJ8n6fcbExCnfNPm0RYgdDVVlzLO/lMLcNFYnkqV49k2dIVQFz2cJ5qHzni5gk vhpE6g9pnnmKeZYtWpemj6+lT9W+mGomWequD9twMMsetmQLuKNoJmDRENQy1T3PZ4w1y0qed1X Cm61XSZivgJrhpRLEAFotM8Mcn+A0WPD2VPIv7qHomAblP0/4tr+J3MA2N0iWdnVDVuKr0enpm1 BSTCYLp1aOJGzm6md2VOkrYqWqOpYSf78emhBG4n8NNWT15+cjFZVgTBB0eVjRw1gKEvUxCjtUo CM= X-Google-Smtp-Source: AGHT+IEL4L4x7/t3H1GGEhQLBpg2cBvQB+rN2QANV32ZXrdm8ehS8907Eg6MJ1BAzVNOoVyDjy5fCA== X-Received: by 2002:a05:6000:2891:b0:432:8651:4070 with SMTP id ffacd0b85a97d-432c3760e09mr10702350f8f.10.1767946580945; Fri, 09 Jan 2026 00:16:20 -0800 (PST) Message-ID: <336b1b84-7c03-44a8-b9d4-9652f0797886@suse.com> Date: Fri, 9 Jan 2026 09:16:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/4] x86/xstate: Rework XSAVE/XRSTOR given a newer toolchain baseline To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20251230135427.188440-1-andrew.cooper3@citrix.com> <20251230135427.188440-3-andrew.cooper3@citrix.com> <4b051e1f-0d99-4637-b433-bade93e67e0a@suse.com> <6062efac-8285-4062-926f-dc3ece871654@suse.com> <91a64181-212b-4515-9e2e-82b3eb4b4364@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: <91a64181-212b-4515-9e2e-82b3eb4b4364@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 08.01.2026 22:08, Andrew Cooper wrote: > On 06/01/2026 7:59 am, Jan Beulich wrote: >>>>> @@ -489,17 +484,17 @@ void xrstor(struct vcpu *v, uint64_t mask) >>>>> ptr->xsave_hdr.xcomp_bv = 0; >>>>> } >>>>> memset(ptr->xsave_hdr.reserved, 0, sizeof(ptr->xsave_hdr.reserved)); >>>>> - continue; >>>>> + goto retry; >>>>> >>>>> case 2: /* Stage 2: Reset all state. */ >>>>> ptr->fpu_sse.mxcsr = MXCSR_DEFAULT; >>>>> ptr->xsave_hdr.xstate_bv = 0; >>>>> ptr->xsave_hdr.xcomp_bv = v->arch.xcr0_accum & XSTATE_XSAVES_ONLY >>>>> ? XSTATE_COMPACTION_ENABLED : 0; >>>>> - continue; >>>>> - } >>>>> + goto retry; >>>>> >>>>> - domain_crash(current->domain); >>>>> + default: /* Stage 3: Nothing else to do. */ >>>>> + domain_crash(v->domain, "Uncorrectable XRSTOR fault\n"); >>>>> return; >>>> There's an unexplained change here as to which domain is being crashed. >>>> You switch to crashing the subject domain, yet if that's not also the >>>> requester, it isn't "guilty" in causing the observed fault. >>> So dom0 should be crashed because there bad data in the migration stream? >> Well, I'm not saying the behavior needs to stay like this, or that's it's >> the best of all possible options. But in principle Dom0 could sanitize the >> migration stream before passing it to Xen. So it is still first and foremost >> Dom0 which is to blame. > > BNDCFGU contains a pointer which, for PV context, needs access_ok(), not > just a regular canonical check.  Most supervisor states are in a similar > position. Yes, so exposing them to PV would require extra care. Note that MPX isn't exposed to PV. > Just because Xen has managed to get away without such checks (by not yet > supporting a state where it matters), I don't agree that its safe to > trust dom0 to do this. Yet the guest itself can't have got in place a non-canonical value, can it? Its attempts to load it into hardware would have faulted. So it's still not the target domain which is to be blamed for a fault resulting from XRSTOR encountering bogus pointers. > For this case, it's v's xstate buffer which cannot be loaded, so it's v > which cannot be context switched into, and must be crashed.  More below. Well, yes, as said - that's one possible way of treating things. My main request is not so much to undo the change, but to properly justify it in the description. (Or maybe that really wants to be a separate change, in particular if you wanted the changed behavior to also be backported.) >>> v is always curr. >> Not quite - see xstate_set_init(). > > Also more below. > >> And for some of the callers of >> hvm_update_guest_cr() I also don't think they always act on current. In >> particular hvm_vcpu_reset_state() never does, I suppose (not the least >> because of the vcpu_pause() in its sole caller). > > We discussed the need to not be remotely poking register state like > that.  But I don't see where the connection is between > hvm_update_guest_cr() and xsave()/xrstor(). At the example of svm_update_guest_cr(): It calls svm_fpu_enter(), which in turn calls vcpu_restore_fpu_lazy(). But yes, that's explicitly only when v == current. I fear I didn't look closely enough when writing the earlier reply, sorry. > Tangent: hvm_vcpu_reset_state() is terribly named as it's attempting to > put the vCPU into the INIT state, not the #RESET set. > > But it only operates on the xstate header in memory while the target is > de-scheduled.  It's not using XSAVE/XRSTOR to load the results into > registers as far as I can tell. Iirc I mentioned hvm_vcpu_reset_state() because it calls hvm_update_guest_cr() several times. >>>   XRSTOR can't be used correctly outside of the subject context, >> Then are you suggesting e.g. xstate_set_init() is buggy? > > No, but it switches into enough of v's context to function.  Really its > neither current nor remote context. > > But, it's single caller is adjust_bnd() in the emulator so it's always > actually current context with a no-op on xcr0. That's its single present caller. Who knows what else we might need it for. It would better be operating correctly in the more general case. > As said on Matrix, I think it's going to be necessary to remove MPX to > continue the XSAVE cleanup. Possibly, yes. Jan From xen-devel-bounces@lists.xenproject.org Fri Jan 09 08:53:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 08:53:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198427.1515383 (Exim 4.92) (envelope-from ) id 1ve8El-0006wf-FC; Fri, 09 Jan 2026 08:52:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198427.1515383; Fri, 09 Jan 2026 08:52: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 1ve8El-0006wY-Cd; Fri, 09 Jan 2026 08:52:51 +0000 Received: by outflank-mailman (input) for mailman id 1198427; Fri, 09 Jan 2026 08:52: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 1ve8Ej-0006wP-PI for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 08:52:49 +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 91d1d11e-ed38-11f0-9ccf-f158ae23cfc8; Fri, 09 Jan 2026 09:52:47 +0100 (CET) Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-42fbc544b09so2897247f8f.1 for ; Fri, 09 Jan 2026 00:52:47 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5fe67csm21025888f8f.40.2026.01.09.00.52.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jan 2026 00:52:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 91d1d11e-ed38-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767948766; x=1768553566; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=4wuBoEC8pXbkWBD/bTl21VJ5ojFsTXdX4usyEM4A20c=; b=GSEfpoNWKNIv5fpl20X/kFk+zeUWZxHN1nibzJcbVRuwPS8eyQnsAE27g4IEJqMcbY XHDAjGPwkZ9tzbvjRQiC7aluCtjGGVsbcGkXPxPfCXugI/CFyZrutn0E4VSzPYHOvzJy nxch/wFtgLDmd+30ukDfjaIbOUvyTDK1G5+/tMVoBRTtrhOunUXOzumx6dh6rjSn9uVP dnGhHAh5mFXvfF06GflHjCPS2FtB654WPVG2LV7uspkz0WPMECjL32GhJg1hAHCFQx3u c/RnJyb+W4oGOxQhWpCsYC0Br6iUdWjaTOpAzVzcaQstccy0vi9WjUssQyRgJY6+MxRO RC7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767948766; x=1768553566; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4wuBoEC8pXbkWBD/bTl21VJ5ojFsTXdX4usyEM4A20c=; b=JVB1iuRelmc3PL+E/Xsu1M3ZC2z06XNHfeNm6NSVIbCE6Eec7OZHhXGBEw6fMBFEa6 SvWqvYai/wzJ3YV16f3H9o9oLGq2UOWldXr9F8RcwgWYgHKrEF1DRxqfajtND4FHyWgK jPXX8SQmbKGAsZ/FC3VC6BEevGbmy7eoRZZlzVDNcFidnTRhz+FWkwZxKXfYEcouFjyX 9ElM5CvEiN/bq1DmXOXrhYPcxM6bDXyc5HlxYFhaah0P8qwReb1BX0AUF0t5C1y7qgkQ JtCoRkacJnQMzuiZCXbfw67UVHAWBKDFfkqgqEj5DF1n17/Q35AK3L311TuiBparExP6 UfIw== X-Forwarded-Encrypted: i=1; AJvYcCXNjivb5rqZNra+P5el9JtXW16AnReg7YoZHkQmU/EgojVKHSwRaMPRT04/N9cC9hp4ujzxjaNQosg=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx3VB+muER1jtmFc13NjuRbTwGv+hfd8eF+E28e3G5wim2DPQO0 1sHByk4k9huL032DFvkO0/7Q/kGmnOo/BqHF8E0QEtpsGLhXsdmTb7rf8xfRY6x3bA== X-Gm-Gg: AY/fxX5UAbYYoh8jgJDfDQaQN2c2aMvarX2TpjoZ5j8tZBHfxKHR+hvvgM0FIPJPqRL OcyydF4Rqs1M13nxOKctHGIG4tF+VvV0YZIm2tpQ6pz3b8Zpz+uy+CTNg+1MosQfilV3M+cSydR /j8ObLJGubhZc1ZsjEt9xmUGDzNqt2wC4DMOTe/9NvqDkjaCc5JkfSgI1C5Tcp20FsVuqzZhvg0 l8S1TEyEdd8OzbgJ7P0vwH4a/sY7sp6oRcpIomClluUvwKTfmVJjhZOZ6isrs8vGniTFp6py/0G xLXTJFzloZxHUf+9HKXWigUYZCiENMrVm5q00g13uU/aQE03sDe/RSlcYD30cK/qlSWZaRC8B/t arXfLfnQiIOm4EtafjPMjSFdMLTJ8So4iSqYwF97PeeF42T2Reh7v2Br9hfdKBUnezvz1QD00JY Lc3hInmFp8b+HeBlnFYdN6Qm1D9a7FAEkdVlt254p7yX0feHW5cHu0T82CMfAnWeC+Fa7o/JnF/ cI= X-Google-Smtp-Source: AGHT+IHnckDLl2ILoLgj0ZXykIDzrlo0YJP0Cx1XFakkgE9fl0GgWFFe+sqw+AQSLcftmxv+Glbg1Q== X-Received: by 2002:a05:6000:22c5:b0:431:8bf:f081 with SMTP id ffacd0b85a97d-432c3790cf7mr11062673f8f.23.1767948766300; Fri, 09 Jan 2026 00:52:46 -0800 (PST) Message-ID: <1a70284e-de5a-4e5b-9641-12be48a311f4@suse.com> Date: Fri, 9 Jan 2026 09:52:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86: guard synthetic feature and bug enumerators To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , "xen-devel@lists.xenproject.org" References: <239a5d80-c0af-410b-a053-5fa84273aecd@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.01.2026 19:12, Andrew Cooper wrote: > On 07/01/2026 2:11 pm, 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 >> --- >> v2: Fix shim build. Use named label operand in pdx.h. > > I'm pretty sure that will be rejected by Eclair as a Rule R20.12 > violation (using a parameter as a regular value, and stringised), and is > a blocking rule. I don't think so - see the difference between the non-compliant and the compliant examples in the spec. The label passed here isn't subject to further macro expansion. > But more generally...  I see why you want a guard rail here, I can't > help feeling that the cure is worse than the poison. That's a fair position to take, albeit I don't really agree. > Updating every alternative is very invasive, and this in particular Well, luckily it's far from all, but mainly those which use the upper- case macros directly. Plus the two "(ab)uses" in asm/spec_ctrl.h. The change in asm/tsc.h is actually in our favor, I would say. >> --- 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"); >> } > > without even an explanation of why, is an immediate red flag. Honestly, to me the "(ab)use" in the comment is enough of an explanation. Plus, really, the end result now looks more "normal" than before (in no longer having comma and colon next to each other). Would adding /* dummy */ after the seemingly stray input satisfy your request for "an explanation"? Else what exactly would you expect? > Could we not split X86_SYNTH()/BUG() to take a leaf/bit pair, similar to > how we express regular features as a*32+b? > > That would at least make it more obvious than currently when a new leaf > is needed, and contained it to a single header. I'm pretty sure we could, but such a split would be largely artificial. Hence why I discarded that option very early, the more that - as you say - it still would only serve as a hint, without enforcing anything. In particular I could easily see me using the next "major" index, but still forgetting that X86_NR_{SYNTH,BUG} would also need bumping. (What might help a little is if the two really moved to the end of their blocks, so they would be more likely to be spotted when adding something to the end. Bottom line: I'd prefer if we would stick to actually doing the checking (or yet better derive X86_NR_{SYNTH,BUG} from the uses of X86_{SYNTH,BUG}() [1]). I'm not particularly happy with the way the checking is done right now, so I'm all ears towards improvement suggestions. Jan [1] Some initial idea: Have XEN_CPUFEATURE(SYNTH_1ST_UNUSED, X86_SYNTH(...)) /* Must stay last. */ #define X86_NR_SYNTH ((X86_FEATURE_SYNTH_1ST_UNUSED - 1) / 32 - FSCAPINTS) From xen-devel-bounces@lists.xenproject.org Fri Jan 09 08:57:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 08:57:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198441.1515394 (Exim 4.92) (envelope-from ) id 1ve8JV-0007aF-5p; Fri, 09 Jan 2026 08:57:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198441.1515394; Fri, 09 Jan 2026 08:57:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ve8JV-0007a8-23; Fri, 09 Jan 2026 08:57:45 +0000 Received: by outflank-mailman (input) for mailman id 1198441; Fri, 09 Jan 2026 08:57: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 1ve8JS-0007Zw-TZ for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 08:57:43 +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 40276fd1-ed39-11f0-9ccf-f158ae23cfc8; Fri, 09 Jan 2026 09:57:40 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SJ0PR03MB5903.namprd03.prod.outlook.com (2603:10b6:a03:2d7::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.4; Fri, 9 Jan 2026 08:57:37 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.003; Fri, 9 Jan 2026 08:57: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: 40276fd1-ed39-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=GcjVwGmVpJMRf2Kh9HZ9V38xIwmAbB5XBM8Uj0/3ku7ZUKiNieFmi4i1FrCTVkzGS2a3lK8BjeDfJiofbKYvHEz+V1oZltbX0+ovCMNd2clv6izHk4bimfdkZ8PUUhZkvcM3E9PrGezIeVj7lTw+tKR3tJCeCT1QP5m435kdZBXQ9JnGuLXW3fwaDa5YApxNaoz3EjWGWhk8OoZPsWujPm5DAiyGGR9Dq/YrtwTSR7NpWDZifI7eF2W+MF7E9E4e5fyTGhU+70nCkpaAjUJI7DJ39nHBPfX9qWU5ntSMQTYO93Uixvva1HxhMVPglHrOfyZCCzgcgDK1k8JV9kRg6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QH7VdYlRgiQ1C2oCEOfkUSwldE30O6UsxMctrO0gtYo=; b=Wtf7mfnC3uW9EMrmJNOSyQRR2qZ6y5oyYXjQ4XWT2+0/LWZapuHbu+ScFVC+08HzQ1+9iezyutFh8fQJpE45IID8QCTmXqNsMs87iQ3SWuQ2IZhtlrpQRW5/XJhduk3hiLgD7izzSzFmiLfc+kTuZ2U/ucjge7B/OIurWCPnJu19MY5MPAvK4WYf5o++ZCwSa4dVYhJ86yDPzkyYXYTjZqSE7L/fwi1O1ycZHwnkTYbTmGlReW5FfwNf77+ab0rgTEjudoizGQPxmL7RjhPPbtjSBYHD6atQ5tQRPThmqbjLHYV9M0HoC5eyuA8prbj2Zat7NLXnfUzUlOQ1gHi77A== 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=QH7VdYlRgiQ1C2oCEOfkUSwldE30O6UsxMctrO0gtYo=; b=eIspAcMfbHm0EJac+3mD6B2WEl9v+3u/THnHhXPu8FOIXehZeC8RtjdQwHeRYjbabo4jIraTAZYD6S0/i3NV8uHRILxuHlJr3bvAZlYXZqRlsEwI7vkzQpJBUnhUjD65GiLXPWUzZLpJddO/5rgOdb0KjdvbnfGnwurBicUgaRk= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Fri, 9 Jan 2026 09:57:33 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Teddy Astie Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: Re: [RFC PATCH] pvh: Introduce SIF_HVM_GHCB for SEV-ES/SNP guests Message-ID: References: <3b6f5146287d3402a09836b7cf876d4f8dc9eee1.1766889890.git.teddy.astie@vates.tech> <0c9c1dbb-28e1-479b-a680-e99150b3f0da@vates.tech> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: PAZP264CA0136.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:1f8::6) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SJ0PR03MB5903:EE_ X-MS-Office365-Filtering-Correlation-Id: c7135668-4163-43ee-2d67-08de4f5d2304 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?bWN4U1IxQTlhT2xzSlNxWGM0S0g3NjVCWG5hTTlEUjV2OVVPd2tQMEJKZ0Fa?= =?utf-8?B?ZE1tVkhPY0RNVXYzNjUzZG92Y3hIbExlV3FNeUIwVVdHci9yVzZQSGJPaTRF?= =?utf-8?B?Skg4RGNER2hYLzZyNTR6MmxJNDNhNmNheUpBVXBqZGgvejVTM0hMUU1YMTJM?= =?utf-8?B?dTNMbVI1YlplUWs0K1BiemZ4V2NnRDlYaTk5NWt2NlJvbi96aUlCMmpDNjh3?= =?utf-8?B?WlEwaXpMdDVWaTROTzIyRGt5MjdtT0YvSmltNGJob2MzZFlYdzJ3M09DaEZW?= =?utf-8?B?bHBkS1Bxa0hMc2J6QW1RbnhFR2hCdjdsV2xvSXJ6d3JIck40Y2FLd08wTFhk?= =?utf-8?B?VUd3K3dNUm9pMEV4T1JGaSswek0yWVQ0cnQzeFRpSFArYkhNVjhwZExTVHM3?= =?utf-8?B?QVd3VjFWeTVhSU04YTAyNFFDKzI3Yk0zSytsdmtCR1RBVSsvTUhkV3Nnb0pi?= =?utf-8?B?b3BrYzMvajcveGhjYVo2M2MyZmNjSG1tTnFGVllQUWRtejY1L000M3oxZy9h?= =?utf-8?B?L2FrQnJkNzZpcG5pN3hjZGo3a1BhT1BQS2dXZS95eEh0ek90cjBBbHFTYWRI?= =?utf-8?B?akE0SFpMRHQ0c1RVdmtlSG1OQVgyZnFhbzhiSlUrOTYyTjRwekpqdDRmYlNu?= =?utf-8?B?V0lGNEZQc2ZCUUZaRGh5cnp6aHlqOU9Ud1RTQjNPenlpZlVQemxzSytiMjVX?= =?utf-8?B?SnVnUndROGhyeWk0eXBBeGFablpaNi81WmdIdHZKMFNGM0NBQ3VFdWpDSHd1?= =?utf-8?B?aWtQQ1dTTC90SFBZMnRWWUNkd2dJNUUrajhWbGt4RHhqSE1FcFFzaXJQWDJL?= =?utf-8?B?S29aNWxsUll4YmY4aTFWMmJhNTZpZnFHWGFZWEo5UnVxRFBwdWFmb1laKzJk?= =?utf-8?B?RWRWTldUVFdISU1VQm5KSnh2VnlCRnN4a0dyNk5RZVVhdVR4dG4xK21CNlVE?= =?utf-8?B?Y09FaFlYNzZTcGxxOUE4YzBocWxrQkxLRUhmTXlRSzVXNStGOFMrekcvSm96?= =?utf-8?B?Sncxc2ZkQ3V6emJuT3g0RDJCeit0MWhkM2hQUnM0T3IrMDhtcjFTME54VThO?= =?utf-8?B?OHVIUVFsNm5XZTRLbzJLZ1lOQzA1Y1BOWEhhMzZPajk1ZkVxWWZ2WlFCa0lX?= =?utf-8?B?WVdzWG9ETWY5c0FPY3BoRnJRQmJmMUtMQ2hvanhUU2loM21YWjJJbk1ORFFk?= =?utf-8?B?RHNKbFd0eXRyWjFkRWFNVldma29IRVZDWTVSbWlERFZPVjIveE9QVjFkdXFv?= =?utf-8?B?cXRmQTVJK1NhNDRvbytqOUhROVFWeTlqOUtsN21DSnpnaklBdkljbFJnUm5I?= =?utf-8?B?YkFJeWtpWDJ1dE9EOEZHL1M0ZXJERHplMUZzUmZrT2NySFgvVFFoZWdXWlhO?= =?utf-8?B?MjM0bnNOazRUTmRnS1ppaG56VXhyRGZnSkh0dUcwMlNkemdsTDNldnZhK2Fs?= =?utf-8?B?M2dvR0dVUkpnSitsbXF6Mlk3OXMveHN2NUkxdUcya0tYSGp1SDJIbkltUkpW?= =?utf-8?B?RWFOeWtocC9sbFVVZXlMSlRQTE9ScEVjQVJNTExnVXc1aGNpcU9pODNpUitS?= =?utf-8?B?VjlYMDdmVHN2TkhSVmpqeGRudlkwU2tKVjB3akZSc2h0Vk9JMWVINVNGaXYx?= =?utf-8?B?RXhkZFhDSE5KRjVGY2Rjay9zY0dIMXpITUZVT21aT1crNlZhUExURzR4VHdw?= =?utf-8?B?eElEVFFnRDdhMHgrdkwwUnBIbkdiSW9kQ2cyNEtHOUhtNS9hM1gvQzVoUDFU?= =?utf-8?B?Z0FPajQ5Rmo5RktUWi9qVE11UU9sMUdqQUJKRXRSa3VNa2UwdHZ1K1pjL3FW?= =?utf-8?B?U3RHTXpFbTFUb2tHbGMvWDVzZmVsRmxhenRTWDFuakRvWTI0Tms0OTh5QXhT?= =?utf-8?B?dlZ1S1o5Z0V3VEs3ZDZ6aFgzSmNYR3dFRmg5RFVjTmNaQTZCeVc3aWVUeWYz?= =?utf-8?Q?OFrlh2dxpiZ1KhldKQLFTkOQyr5ukcV7?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UUFGekQwR2swTW8xbHg4dVI0Qm51L2pIdGV1R09La0t5TmRINFBXT1FNeGIx?= =?utf-8?B?eHpmQlFWYlcvc000c3g5dWZzeGVuTWxHTHFwYTZtOHpnbVpjUDBSVW5QMU5x?= =?utf-8?B?OG5TanZVdHQ3K25qbHAzelRVWU8vNVluMTBWSjdEeWUvZHBzV2k4Z3BJV2xW?= =?utf-8?B?T1hkcGxFak01UmM2WDJsQXNiQ0dObk5uSWxGc3dPYnk5UkJsWmkwS2VrYWN5?= =?utf-8?B?dGJEbVhqY1k4eDZUMjU2VHA1dEpVS2NmeG9sbEh4RkhaVkdOU0MyVG4vb2RM?= =?utf-8?B?OURIajdUdHREblhnc0VLb0JBRk0wQ0FFeWgvblhYOEpoOUNaZUswTGFLTFdZ?= =?utf-8?B?MnpKQmQ4OThWaU14cjAzSDh4SVJ3dmV3UG5iL0I0bnRhcCtieUxtVm91TkRH?= =?utf-8?B?Q3VlaktSd1ZCRFZEci9nVS95TytNdFpyYmV1ekdHa1V2WW5KY0hnYWd4Rk1r?= =?utf-8?B?MmFIajI3cVpjYkhuV2xXRk94Um1pY3JSMTQ3clBqMmNjMmF2eE1DaThvNHdG?= =?utf-8?B?Ry9DTDFtUzN5UGQ5and4bHVZUGJxYWdQVUVoTktpL2xKUGQrKzMyc1UxMjNY?= =?utf-8?B?YnFJODQ4d1BZRFlJR3lOMlVocWo5ZHpUYTlXUjJzSHhxMFVXZkI3WE02Z1ZE?= =?utf-8?B?TXJSLzg3K1ByZ0hGaVI1VHZzYU9yY0pOVU4wQjErcitBVm9CMDFaU0VUMTFU?= =?utf-8?B?QlBiOUk0YUZndlNUZ21KU3pUZG9TbnhDNGlSaWVjMHduRkNsTjB4S3VDaXRq?= =?utf-8?B?UUdMSytVOWR4cWVNRlN3b3R3T2s0amFpTjM3NWNKSkptYnVCMFJjYmdBRnND?= =?utf-8?B?RUV1VXQ1RDUxSFVtOFBOVE5tTjFiRE8rSGRyWVF4d1FtREVpY0xQSUZaR2Zt?= =?utf-8?B?Q08xanhIMFpRUkNPUUVzMk1BUVpPQjBudGhrWkJXZWpsUDJKUlQ2WmdvSXYz?= =?utf-8?B?eGVOc3dpYUt4UkZldkJQZDdzZERUNUN3dmMzcERZUlByd3Uyd0tnSGlxVlBi?= =?utf-8?B?U3pGRFRCWTRkT0o1M2ZaUXZrRVJTbjJvM293V0p3NWJjOUZ6MHVnWnNHNzZt?= =?utf-8?B?T1ZsYkZQdGpSVE03ekZVQnhCTFpSdGRXa2lNVmRaSmg0SHUvQXZaZnU0T2h1?= =?utf-8?B?RHZDNXcwQXJ3QjRFZC9TSVdIa0ZvMitxU2h5K0x5eTMzbjVSVVhpNG1KMUJz?= =?utf-8?B?ajgzeUMxcWluY0xUK1lxWXRIYlAzcTZtUkp5ckd4UDZMdTk5cCsrUHJISHFs?= =?utf-8?B?TjE3UXd2QnozTUdTaWhNOUFhT21VNkJ3UWtOVTVyM2l4N0pHY1ZUMkQ1bVBZ?= =?utf-8?B?VWlnNmtLWkE1aU1oVkl6VU1WanZ2UitxbWpxdjhMd0drd0lKbGNEc2JHTmtp?= =?utf-8?B?OFA1ZEFSMEpTMDJkU3hrWFZKRVErb3VjbWoyZGk4VkRDQzhVbGt2emJFUEdL?= =?utf-8?B?Yng2ZnNOSXNtSGpCYUpuTkc2SGYzbGpaZFhGRHNKQ3BBYitJdWFzRUtGaUNT?= =?utf-8?B?WkJ1VWVwSWFmN2ZkTmpvenJMNDVUZVpBRVdLaHdrVndZSTlRR3lRSU1BeXQ2?= =?utf-8?B?anhrOU05My9IUDhzNDVIcThMM2luWGJuMmJYL0RieXhuM0grQ2hwelVabnpS?= =?utf-8?B?eWRvYU15emwwOUoveERPRjV0N0krMlhCRXBnVkRwak9SQlBpQXgzRFE4VU5V?= =?utf-8?B?SjRTcElqbVFOaGpCWXBKQjM2cGxvOXRYUmZaenYzeUp3SzlxYWNSZk51dmhw?= =?utf-8?B?aXVESlE4c2l1OW1WLy92OUlXSXkzQjRMekZkOEVEbVpERkRyNjRDK2hxU2NE?= =?utf-8?B?Y3htVjQraTRpc0hjZ0VlMzFvT1p6R2Z0dnZLUS9hbzhiL2pOUFRsYTBydTg4?= =?utf-8?B?dWFYNG0zSVV3VG53RUNYZ0Z4ZmdXczNPUHRCVFpYVHd4N1RsUjhpd2RJWDFh?= =?utf-8?B?UlkzaEJJU3kyNjNTelhPNnVTb3pxYmdMclQ5bllHZTdvWFpoQ1pic1g3UzBh?= =?utf-8?B?bWtQQksxR3IxUHZJR0cycytwYjkwZFNoN00yVlFxY296K0tWY2ZUNExJQ3VB?= =?utf-8?B?NHdzVElqRjhSN3lacElkWDhoYlRqQzBGdnl6Zzl4a3Y1SDVnTTFtTDVyK2N3?= =?utf-8?B?L0lXUWRCYlpaODhoeWNpQjFNTGVTNjRWOHNIK3FsVTJpSkdkODkrT1c1YVcx?= =?utf-8?B?VWZSc2I0WU9WbjBLd241c05DWkIrZ3pyT3Bueit5ak5OZjljVEIyTXNoSVBP?= =?utf-8?B?MUE2TmdQem4zTWVEQnVIK0tETDd2QlFDRkxNUWhSODZqOW5XYmRqc1JPOEM2?= =?utf-8?B?enZESFIyTkh2Zm5pR0x4czNvcnVNVktBRENWRTlHYUpkaWsvZ2ljdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: c7135668-4163-43ee-2d67-08de4f5d2304 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2026 08:57:37.3615 (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: 9BqJDRU0TBNscmdxKb+Mogqy3DFmRhxOANfe8HdN0wAr7m12g1X6vSVOChvrvAZsS6vjNhL3pSgt02mV4ctZ0w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5903 On Thu, Jan 08, 2026 at 07:12:48PM +0000, Teddy Astie wrote: > Le 08/01/2026 à 18:46, Roger Pau Monné a écrit : > > On Thu, Jan 08, 2026 at 04:50:51PM +0000, Teddy Astie wrote: > >> Le 28/12/2025 à 13:54, Teddy Astie a écrit : > >>> Under SEV, the pagetables needs to be post-processed to add the C-bit > >>> (to make the mapping encrypted). The guest is expected to query the C-bit > >>> through CPUID. However, under SEV-ES and SEV-SNP modes, this instruction > >>> now triggers #VC instead. The guest would need to setup a IDT very early > >>> and instead use the early-GHCB protocol to emulate CPUID, which is > >>> complicated. > > > > Possibly a stupid question, but how is this information expected to > > be propagated to the guest when there's a guest firmware and > > bootloader in use? > > > > How is OVMF and/or grub propagating this information between > > themselves and to Linux? > > > > When booting Linux with SEV+UEFI, at least during the UEFI services, the > UEFI firmware transparently handles #VC for the rest to allow it to > perform CPUID operation. > (with SEV-SNP CPUID page exposed with a specific UEFI mecanism) Hm, that's going to be cumbersome when using hvmloader in this scenario, as it makes extensive use of CPUID and hence would need to setup it's own #VC handler ahead of making use of CPUID. Or we must instead get rid of hvmloader. > So overall, this proposal is only meaningful for PVH booting, everything > that comes after can be handled differently. > > > Are they relying on the CPUID discovery logic mentioned above, or > > there's some shadow infra used by KVM for example to already convey > > it? > > > > OVMF at its startup relies on #VC for emulating CPUID. > It then relies on GHCB MSR for getting SEV info/C-bit (but only with > SEV-ES). And under SEV-SNP, it uses "CPUID page" instead of GHCB > (PAGE_TYPE_CPUID in SEV-SNP firmware ABI specification). > > This is because SEV/GHCB specification recommends using CPUID page under > SEV-SNP (even though the same protocol as SEV-ES still works; but is > discouraged). In a previous reply to Jan you mention that Linux already has such handlers, but just for the decompressing code (and hence not reachable from the PVH entry point, that's already decompressed code). Would it be possible to share the handlers with the PVH entry point? > In GHCB Version 2 (SEV-SNP) > > The hypervisor may supply the encryption bit position using the SEV Information MSR protocol, > > but the guest should use the CPUID information supplied in the CPUID Page to determine the > > encryption bit position. > > But its location is unfortunately undefined in this specification and in > the OVMF case, hardcoded in firmware metadata. > > > Adding Xen side-channels when there's an architectural defined way to > > obtain the information is a duplication of interfaces, and could lead > > to issues in the long run. We can not possibly be adding all vendor > > SEV options to SIF_ flags just because they are cumbersome to fetch. > > I know this is just one right now, but we don't know whether more of > > those CPUID options would be needed at the start of day in the future. > > > > That exists for SEV-ES and SEV-SNP (even though complicated) but for > SEV-SNP, it would relies on discouraged mecanisms (GHCB CPUID Request). > > AFAIU, this flag is enough for setting up long mode and GHCB which is > what matters. There are some additional structures (e.g secret page and > CPUID page) which could in the future be eventually exposed as PVH > modules; which would be hopefully less intrusive. If my understating is correct, this is not needed for the initial implementation of SEV (when hypervisor doesn't implement ES or SNP guests can use CPUID), and hence it might be best to wait for the basic SEV implementation to be in the hypervisor before jumping into ES or SNP details? AFAICT (from your Linux entry point patch) you end up needing both the CPUID and the GHCB ways of detecting SEV support, so one doesn't preclude the other. > -- > > Some specialized boot process for SEV-SNP (e.g the one used > COCONUT-SVSM) relies on IGVM [1] with custom memory layouts, initial > pagetables, and so on. > > [1] https://github.com/microsoft/igvm > > >>> ## AP startup ## > >>> > >>> AP startup can be performed using hypercalls or the local APIC if present. > >>> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h > >>> index 7f15204c38..9b84df573b 100644 > >>> --- a/xen/include/public/xen.h > >>> +++ b/xen/include/public/xen.h > >>> @@ -890,6 +890,8 @@ typedef struct start_info start_info_t; > >>> #define SIF_MOD_START_PFN (1<<3) /* Is mod_start a PFN? */ > >>> #define SIF_VIRT_P2M_4TOOLS (1<<4) /* Do Xen tools understand a virt. mapped */ > >>> /* P->M making the 3 level tree obsolete? */ > >>> +#define SIF_HVM_GHCB (1<<5) /* Domain is SEV-ES/SNP guest that requires */ > >>> + /* use of GHCB. */ > > > > A concern I have with this is that we are adding vendor-specific > > terminology to what should otherwise be a vendor-agnostic interface. > > > > There's already a fair amount of arch-specific information encoded in > > there, so maybe not that much of a big deal. If we end up getting this bit, I think it needs to be clear it's a vendor specific feature: SIF_AMD_SEV_GHCB or similar would be better IMO. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Jan 09 09:27:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 09:27:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198468.1515403 (Exim 4.92) (envelope-from ) id 1ve8mC-00032z-Cg; Fri, 09 Jan 2026 09:27:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198468.1515403; Fri, 09 Jan 2026 09: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 1ve8mC-00032s-9n; Fri, 09 Jan 2026 09:27:24 +0000 Received: by outflank-mailman (input) for mailman id 1198468; Fri, 09 Jan 2026 09:27: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 1ve8mA-00031V-S0 for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 09:27:22 +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 66349633-ed3d-11f0-b15e-2bf370ae4941; Fri, 09 Jan 2026 10:27:21 +0100 (CET) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-64b58553449so6088748a12.1 for ; Fri, 09 Jan 2026 01:27:21 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6507b8c4479sm9845938a12.1.2026.01.09.01.27.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Jan 2026 01:27:19 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 66349633-ed3d-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767950840; x=1768555640; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=W/a3jE5WcEeVvQVUAGeNvAnv9PSN8A+YCeqq6+pydKg=; b=PYIshAuFwnUcBY8cdWkeI661/ch4psA0Vdpe4PmB+0F0qwCcINL1v2eVDhhmu2vpVV TeQlMNXGQJGu8B8E5QuzTYUUToIQw0dYx3QpbbkI7FA8olP/DVcfnRe2qn9dkntzycRW KnpdR9tfOxrUFqdq/gtOe0FV9GRAflf02na0l1Hy4hkiB1vdxNOZRQF7gakpIa3VXGMi ixbmNDFwIJ2Ha3ypGrUxnz/47rF4WBhGOyiPHkbYQbF+BAEbKDg8XV1As9TbvowUAGeR bZXcrbejSC7nR6oLcsTyf6eIXN4NEN2mlMz16N3x85CqUXGg6fg4fVo5o8fEZedmsVgC NKWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767950840; x=1768555640; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=W/a3jE5WcEeVvQVUAGeNvAnv9PSN8A+YCeqq6+pydKg=; b=np68O6qT/wcoyFVMgfI1vNMqNrkDSGericEFXYDBVFIHXe5Q540JrPVm0RcRnM2uJa v78ndASa+cj3604DCaJ8WT388cLexsr3rG2itBOA4ILv4acojIu/L7SJPDy+oKtvoMhc d4qaj6xioNhJ9lVg3CDrIT1rw6fYji07lAyNwgMw5YO3Hg0aeOXNghNg9V81s7cdKHuS t1eUmZwBHlO+iwo/E4zxYy3qtj0CvrB0GYSifkSRqoEhLyqHpsHef0LvPc8ghe5SWnA1 2HkUZ8jGVb5ojbcZC84OMOXV0dCf8vexSZWmQYQ3rdhsJN7ZwMlkumKHRrhNn5ixbriN SfSA== X-Gm-Message-State: AOJu0Yy/FWeqJhB/NDVrLY1nJXK72WtgEMYA46R31H/8uTY/IuISfb33 fZ81Fl1RD+WbMl+QYSnN4l4GqDKPjw447hLYZTIm3Sa0hQd54c5iL+P4/sS7iw== X-Gm-Gg: AY/fxX6YcSToXTeOWKl9yQvVYLISUu0OPEjtN/c1Ul7l+pGV0qz/n/KGdlywUglC+bO RzqFSNBsYul/3PkZV6FPO05MpgqCUioNzs5EvJzwPB3hz2tHy9rDu5cQSWxXxnlGRgY5ZqEwTp0 CXh+l9WsLq6+eVt1fqMjX25PUm6Nz5Z6cthpFiE44E3o2pZqf7612vEdIBks2HmS7dVYIghxUhW NYmlg6dSetIzy8KCEDHhZvRfp0ykWCGklybSlhBI5U5jMr/KfXD+7J0PEAvZvLNHGMSLImBWR9j JCIhfgpP6hBXdj50NTcAq8wm4XEeMpJPuTw4clNuqTVRM0U8SIOhhXQT7caCKHdchsrBvxqIAik V0TlSsmTyHxZS3Xiid8WQ8THZ3eU69Tmn3XCpYTMu5Y7VaUCoVHPkowVJ0aYQNmDjh7P6qFWIYQ /rfk90fozlmk6/NzPywSe88NFggoUiPRUxU/N8hM7xVYslM9DqHebzhw== X-Google-Smtp-Source: AGHT+IHlluaofB620PGYiX8OrfaU3u30jCNoW8j+u2b28C08R4OK87MAkSPubfws1tprjgHLz1PSAA== X-Received: by 2002:a05:6402:2803:b0:64b:6330:2fee with SMTP id 4fb4d7f45d1cf-65097df5b92mr8576939a12.11.1767950840278; Fri, 09 Jan 2026 01:27:20 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Jan Beulich , Yann Dirson , Yann Sionneau Subject: [PATCH v3] acpi/arm: relax MADT GICC entry length check to support newer ACPI revisions Date: Fri, 9 Jan 2026 10:27:11 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Newer ACPI revisions define the MADT GICC entry with Length = 82 bytes [1]. The current BAD_MADT_GICC_ENTRY() check rejects entries whose length does not match the known values, which leads to: GICv3: No valid GICC entries exist. as observed on the AmpereOne platform. To fix this, import the logic from Linux commit 9eb1c92b47c7: The BAD_MADT_GICC_ENTRY check is a little too strict because it rejects MADT entries that don't match the currently known lengths. We should remove this restriction to avoid problems if the table length changes. Future code which might depend on additional fields should be written to validate those fields before using them, rather than trying to globally check known MADT version lengths. Link: https://lkml.kernel.org/r/20181012192937.3819951-1-jeremy.linton@arm.com Signed-off-by: Jeremy Linton [lorenzo.pieralisi@arm.com: added MADT macro comments] Signed-off-by: Lorenzo Pieralisi Acked-by: Sudeep Holla Cc: Will Deacon Cc: Catalin Marinas Cc: Al Stone Cc: "Rafael J. Wysocki" Signed-off-by: Will Deacon As ACPI_MADT_GICC_LENGTH is dropped, update the functions where it is used. As we rewrite the MADT for hwdom, reuse the host GICC header length instead of ACPI_MADT_GICC_LENGTH. Mark gic_get_hwdom_madt_size() as __init since its only caller is also __init. [1] https://uefi.org/specs/ACPI/6.6/05_ACPI_Software_Programming_Model.html#gic-cpu-interface-gicc-structure Reported-By: Yann Dirson Co-developed-by: Yann Sionneau Signed-off-by: Oleksii Kurochko --- I ran CI tests where it made sense for this patch, as I don’t see any CI job that builds Xen with CONFIG_ACPI=y: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/2252409762 I also built Xen manually with CONFIG_ACPI=y enabled and tested it on the AmpereOne platform. --- xen/arch/arm/acpi/domain_build.c | 6 ++++++ xen/arch/arm/gic-v2.c | 3 ++- xen/arch/arm/gic-v3.c | 3 ++- xen/arch/arm/gic.c | 13 +++++++++++-- xen/arch/arm/include/asm/acpi.h | 21 +++++++++++++++------ 5 files changed, 36 insertions(+), 10 deletions(-) diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c index 1c3555d814cc..959698d13ac3 100644 --- a/xen/arch/arm/acpi/domain_build.c +++ b/xen/arch/arm/acpi/domain_build.c @@ -458,6 +458,12 @@ static int __init estimate_acpi_efi_size(struct domain *d, acpi_size += ROUNDUP(sizeof(struct acpi_table_stao), 8); madt_size = gic_get_hwdom_madt_size(d); + if ( !madt_size ) + { + printk("Unable to get hwdom MADT size\n"); + return -EINVAL; + } + acpi_size += ROUNDUP(madt_size, 8); addr = acpi_os_get_root_pointer(); diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c index b23e72a3d05d..aae6a7bf3076 100644 --- a/xen/arch/arm/gic-v2.c +++ b/xen/arch/arm/gic-v2.c @@ -1121,7 +1121,8 @@ static int gicv2_make_hwdom_madt(const struct domain *d, u32 offset) host_gicc = container_of(header, struct acpi_madt_generic_interrupt, header); - size = ACPI_MADT_GICC_LENGTH; + size = host_gicc->header.length; + /* Add Generic Interrupt */ for ( i = 0; i < d->max_vcpus; i++ ) { diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c index bc07f97c16ab..75b89efad462 100644 --- a/xen/arch/arm/gic-v3.c +++ b/xen/arch/arm/gic-v3.c @@ -1672,7 +1672,8 @@ static int gicv3_make_hwdom_madt(const struct domain *d, u32 offset) host_gicc = container_of(header, struct acpi_madt_generic_interrupt, header); - size = ACPI_MADT_GICC_LENGTH; + size = host_gicc->header.length; + for ( i = 0; i < d->max_vcpus; i++ ) { gicc = (struct acpi_madt_generic_interrupt *)(base_ptr + table_len); diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index ee75258fc3c3..e4fcfd60205d 100644 --- a/xen/arch/arm/gic.c +++ b/xen/arch/arm/gic.c @@ -414,12 +414,21 @@ int gic_make_hwdom_madt(const struct domain *d, u32 offset) return gic_hw_ops->make_hwdom_madt(d, offset); } -unsigned long gic_get_hwdom_madt_size(const struct domain *d) +unsigned long __init gic_get_hwdom_madt_size(const struct domain *d) { unsigned long madt_size; + const struct acpi_subtable_header *header; + const struct acpi_madt_generic_interrupt *host_gicc; + + header = acpi_table_get_entry_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT, 0); + if ( !header ) + return 0; + + host_gicc = container_of(header, const struct acpi_madt_generic_interrupt, + header); madt_size = sizeof(struct acpi_table_madt) - + ACPI_MADT_GICC_LENGTH * d->max_vcpus + + host_gicc->header.length * d->max_vcpus + sizeof(struct acpi_madt_generic_distributor) + gic_hw_ops->get_hwdom_extra_madt_size(d); diff --git a/xen/arch/arm/include/asm/acpi.h b/xen/arch/arm/include/asm/acpi.h index 13756dd341b4..30bc446d1f75 100644 --- a/xen/arch/arm/include/asm/acpi.h +++ b/xen/arch/arm/include/asm/acpi.h @@ -53,13 +53,22 @@ void acpi_smp_init_cpus(void); */ paddr_t acpi_get_table_offset(struct membank tbl_add[], EFI_MEM_RES index); -/* Macros for consistency checks of the GICC subtable of MADT */ -#define ACPI_MADT_GICC_LENGTH \ - (acpi_gbl_FADT.header.revision < 6 ? 76 : 80) +/* + * MADT GICC minimum length refers to the MADT GICC structure table length as + * defined in the earliest ACPI version supported on arm64, ie ACPI 5.1. + * + * The efficiency_class member was added to the + * struct acpi_madt_generic_interrupt to represent the MADT GICC structure + * "Processor Power Efficiency Class" field, added in ACPI 6.0 whose offset + * is therefore used to delimit the MADT GICC structure minimum length + * appropriately. + */ +#define ACPI_MADT_GICC_MIN_LENGTH ACPI_OFFSET( \ + struct acpi_madt_generic_interrupt, efficiency_class) -#define BAD_MADT_GICC_ENTRY(entry, end) \ - (!(entry) || (unsigned long)(entry) + sizeof(*(entry)) > (end) || \ - (entry)->header.length != ACPI_MADT_GICC_LENGTH) +#define BAD_MADT_GICC_ENTRY(entry, end) \ + (!(entry) || (entry)->header.length < ACPI_MADT_GICC_MIN_LENGTH || \ + (unsigned long)(entry) + (entry)->header.length > (end)) #ifdef CONFIG_ACPI extern bool acpi_disabled; -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Jan 09 10:03:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 10:03:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198493.1515415 (Exim 4.92) (envelope-from ) id 1ve9Ky-0008Ax-Vt; Fri, 09 Jan 2026 10:03:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198493.1515415; Fri, 09 Jan 2026 10:03:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ve9Ky-0008Aq-SF; Fri, 09 Jan 2026 10:03:20 +0000 Received: by outflank-mailman (input) for mailman id 1198493; Fri, 09 Jan 2026 10:03:19 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ve9Kx-0008Ak-RI for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 10:03: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 6b284b65-ed42-11f0-9ccf-f158ae23cfc8; Fri, 09 Jan 2026 11:03:17 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-477770019e4so32554795e9.3 for ; Fri, 09 Jan 2026 02:03:17 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0e199bsm21506916f8f.16.2026.01.09.02.03.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jan 2026 02:03:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6b284b65-ed42-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767952996; x=1768557796; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Hha75O21d8a+w1Gr3ybwi7NRwnG6uoExBE7tw9FLn4E=; b=AinxTMRjZBywWZQB4kw8/O8J+ciiFa00k47zeykN8wdpTraEWQI8NSk0IBhctnZRe/ Cee6b6kYRu1Bwrr08Dw2cqI21C4m6R8MqE0tCyrqxJmcOkEPBOB83+cRX7ed7z+o0ikA SPqFe8cozOzgl9dDdiP2UXqunrzHOVdBHF3D2vb71nNLIHNjzPxP6u60QhNFlX6aGUUL CI18ow4sN/TT5yaGMoGKKFhmdALhPebFmbmcGQYiQdaavmxlDuAAm/ZWxJ/cDhjGsi55 Kc129dy6W1nV3yWEiTu6YK6s1XmO7a4WNnbLZzr5p+R6sBwtjyGYXRxRtPjn6i2Sbphg INyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767952996; x=1768557796; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Hha75O21d8a+w1Gr3ybwi7NRwnG6uoExBE7tw9FLn4E=; b=ppzK7bE0gNYATgfdgENDM/OTCBFS72L6MqOsacx9wmVa/x8yIrE73ZexIhGzQZxSon Vbd4V3L/IkU8iDInt4aXVTSb412f1z1dn38rUbji8Gh+lppbo2NyZ5sGvbEBiG2h4577 aUYkcKa/eK2nHJOy9usuYZjcLdGBrF/AH7xdijeCo8qpWMsx6dzAoEBxqZAUBlN1W43n 2x1ZzR8qpM67aa26X8PHQRU+ih3D1d1SN/cpGtiNEVX+E4vT351j4V3AoKKmlONvRgxv ciiaYdGIAaSMr4dIsxqM23ebWgPWfspeZb+Uun5s+QNAAo+vxCiukP5vua0V6dRhBByd BDGg== X-Forwarded-Encrypted: i=1; AJvYcCV70Mf7jbNSHcc4lmveeO0eEQW7InqTth/9hkAk3vtnvd5H9DxsOp/HsernBcC95BibszH6QXGLo04=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx3sqsX5Jsn3d1Ju3Q05Mbr7oxdQd5UqEcKqiPnweva+vBRmeAU N4+G5d6ZYvuyRmliSdrHSZzadFDFK9U9rmwq+IIsHFOsVOekLTBtcXOMkYmqvrVdQg== X-Gm-Gg: AY/fxX4YOgaW3gkBq9QsvplRb33TlmAvzSCO6mgVh/t6IP1s2jiiugjo6UxUIPpjNnV GZkOACUc9OqXBsKybJwi35QImaTiHKrwrjhqtK5wyvbfY5gWuRX88IhlF1ICybLUEovAYAhGLER kSuDjEC0gSWCgAlIcq9XTM4RvCqQaSgTO6eqtzviJ2iJ0XsbE5TTq/C6l1io/Hlad6rhr8k5xOS RBVv0nKOWIuS0/ZBhtVpopd6xAxzNTpzhwDX57/ArPNwQXCEQs4l4c7zPXznXVXWtetQq0pQegg 9qrmCE1+bR5se83sVbLQJa2uGuFWxgENWtfw/rFpFQcFEoCEz29j5YC8/b8N5y1ckc7L5IyCDex 6/Tvpq9R8eFerfTS6JJudRX9ifJ150pbyTm4R4mql6FpoyaUsd4IShpWfyaaUnJwaf3rKzVPoJQ 0Mktv7+wJ8XR5gHU9H2nsjYrEU22DfNWpgfZhfY9NNxkLUP/IGFKUL9EGNPORSAe8Vfp2esnUDr vI= X-Google-Smtp-Source: AGHT+IEpwj5fQrQnvbTvdERlbeJu0fXZH0Gh2BFfVTYlURRhWQtFo45LGXgLG+ZS2dCUpaM1mVUu1w== X-Received: by 2002:a05:6000:2209:b0:432:5bf9:cf26 with SMTP id ffacd0b85a97d-432c3761019mr11997411f8f.13.1767952996400; Fri, 09 Jan 2026 02:03:16 -0800 (PST) Message-ID: Date: Fri, 9 Jan 2026 11:03:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] acpi/arm: relax MADT GICC entry length check to support newer ACPI revisions To: Oleksii Kurochko Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Yann Dirson , Yann Sionneau , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 09.01.2026 10:27, Oleksii Kurochko wrote: > Newer ACPI revisions define the MADT GICC entry with Length = 82 bytes [1]. > The current BAD_MADT_GICC_ENTRY() check rejects entries whose length does not > match the known values, which leads to: > GICv3: No valid GICC entries exist. > as observed on the AmpereOne platform. > > To fix this, import the logic from Linux commit 9eb1c92b47c7: > The BAD_MADT_GICC_ENTRY check is a little too strict because > it rejects MADT entries that don't match the currently known > lengths. We should remove this restriction to avoid problems > if the table length changes. Future code which might depend on > additional fields should be written to validate those fields > before using them, rather than trying to globally check > known MADT version lengths. > > Link: https://lkml.kernel.org/r/20181012192937.3819951-1-jeremy.linton@arm.com > Signed-off-by: Jeremy Linton > [lorenzo.pieralisi@arm.com: added MADT macro comments] > Signed-off-by: Lorenzo Pieralisi > Acked-by: Sudeep Holla > Cc: Will Deacon > Cc: Catalin Marinas > Cc: Al Stone > Cc: "Rafael J. Wysocki" > Signed-off-by: Will Deacon > > As ACPI_MADT_GICC_LENGTH is dropped, update the functions where it is > used. As we rewrite the MADT for hwdom, reuse the host GICC header length > instead of ACPI_MADT_GICC_LENGTH. > > Mark gic_get_hwdom_madt_size() as __init since its only caller is also > __init. > > [1] https://uefi.org/specs/ACPI/6.6/05_ACPI_Software_Programming_Model.html#gic-cpu-interface-gicc-structure > > Reported-By: Yann Dirson > Co-developed-by: Yann Sionneau > Signed-off-by: Oleksii Kurochko > --- > I ran CI tests where it made sense for this patch, as I don’t see any CI job > that builds Xen with CONFIG_ACPI=y: > https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/2252409762 > > I also built Xen manually with CONFIG_ACPI=y enabled and tested it on the > AmpereOne platform. > --- > xen/arch/arm/acpi/domain_build.c | 6 ++++++ > xen/arch/arm/gic-v2.c | 3 ++- > xen/arch/arm/gic-v3.c | 3 ++- > xen/arch/arm/gic.c | 13 +++++++++++-- > xen/arch/arm/include/asm/acpi.h | 21 +++++++++++++++------ > 5 files changed, 36 insertions(+), 10 deletions(-) > > diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c > index 1c3555d814cc..959698d13ac3 100644 > --- a/xen/arch/arm/acpi/domain_build.c > +++ b/xen/arch/arm/acpi/domain_build.c > @@ -458,6 +458,12 @@ static int __init estimate_acpi_efi_size(struct domain *d, > acpi_size += ROUNDUP(sizeof(struct acpi_table_stao), 8); > > madt_size = gic_get_hwdom_madt_size(d); > + if ( !madt_size ) > + { > + printk("Unable to get hwdom MADT size\n"); > + return -EINVAL; > + } > + > acpi_size += ROUNDUP(madt_size, 8); > > addr = acpi_os_get_root_pointer(); > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c > index b23e72a3d05d..aae6a7bf3076 100644 > --- a/xen/arch/arm/gic-v2.c > +++ b/xen/arch/arm/gic-v2.c > @@ -1121,7 +1121,8 @@ static int gicv2_make_hwdom_madt(const struct domain *d, u32 offset) > host_gicc = container_of(header, struct acpi_madt_generic_interrupt, > header); > > - size = ACPI_MADT_GICC_LENGTH; > + size = host_gicc->header.length; > + > /* Add Generic Interrupt */ > for ( i = 0; i < d->max_vcpus; i++ ) > { > diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c > index bc07f97c16ab..75b89efad462 100644 > --- a/xen/arch/arm/gic-v3.c > +++ b/xen/arch/arm/gic-v3.c > @@ -1672,7 +1672,8 @@ static int gicv3_make_hwdom_madt(const struct domain *d, u32 offset) > > host_gicc = container_of(header, struct acpi_madt_generic_interrupt, > header); > - size = ACPI_MADT_GICC_LENGTH; > + size = host_gicc->header.length; > + > for ( i = 0; i < d->max_vcpus; i++ ) > { > gicc = (struct acpi_madt_generic_interrupt *)(base_ptr + table_len); > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c > index ee75258fc3c3..e4fcfd60205d 100644 > --- a/xen/arch/arm/gic.c > +++ b/xen/arch/arm/gic.c > @@ -414,12 +414,21 @@ int gic_make_hwdom_madt(const struct domain *d, u32 offset) > return gic_hw_ops->make_hwdom_madt(d, offset); > } > > -unsigned long gic_get_hwdom_madt_size(const struct domain *d) > +unsigned long __init gic_get_hwdom_madt_size(const struct domain *d) > { > unsigned long madt_size; > + const struct acpi_subtable_header *header; > + const struct acpi_madt_generic_interrupt *host_gicc; > + > + header = acpi_table_get_entry_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT, 0); > + if ( !header ) > + return 0; > + > + host_gicc = container_of(header, const struct acpi_madt_generic_interrupt, > + header); > > madt_size = sizeof(struct acpi_table_madt) > - + ACPI_MADT_GICC_LENGTH * d->max_vcpus > + + host_gicc->header.length * d->max_vcpus Just to double-check: All entries are strictly required to be of the same length? (Related question further down.) > --- a/xen/arch/arm/include/asm/acpi.h > +++ b/xen/arch/arm/include/asm/acpi.h > @@ -53,13 +53,22 @@ void acpi_smp_init_cpus(void); > */ > paddr_t acpi_get_table_offset(struct membank tbl_add[], EFI_MEM_RES index); > > -/* Macros for consistency checks of the GICC subtable of MADT */ > -#define ACPI_MADT_GICC_LENGTH \ > - (acpi_gbl_FADT.header.revision < 6 ? 76 : 80) Given this, ... > +/* > + * MADT GICC minimum length refers to the MADT GICC structure table length as > + * defined in the earliest ACPI version supported on arm64, ie ACPI 5.1. > + * > + * The efficiency_class member was added to the > + * struct acpi_madt_generic_interrupt to represent the MADT GICC structure > + * "Processor Power Efficiency Class" field, added in ACPI 6.0 whose offset > + * is therefore used to delimit the MADT GICC structure minimum length > + * appropriately. > + */ > +#define ACPI_MADT_GICC_MIN_LENGTH ACPI_OFFSET( \ > + struct acpi_madt_generic_interrupt, efficiency_class) > > -#define BAD_MADT_GICC_ENTRY(entry, end) \ > - (!(entry) || (unsigned long)(entry) + sizeof(*(entry)) > (end) || \ > - (entry)->header.length != ACPI_MADT_GICC_LENGTH) > +#define BAD_MADT_GICC_ENTRY(entry, end) \ > + (!(entry) || (entry)->header.length < ACPI_MADT_GICC_MIN_LENGTH || \ > + (unsigned long)(entry) + (entry)->header.length > (end)) ... is 76 a valid length when the FADT revision is 6 or higher? And 80 is a valid length for 6.5 or higher? Jan From xen-devel-bounces@lists.xenproject.org Fri Jan 09 10:15:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 10:15:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198509.1515424 (Exim 4.92) (envelope-from ) id 1ve9X3-0001Sg-4F; Fri, 09 Jan 2026 10:15:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198509.1515424; Fri, 09 Jan 2026 10: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 1ve9X3-0001SZ-1E; Fri, 09 Jan 2026 10:15:49 +0000 Received: by outflank-mailman (input) for mailman id 1198509; Fri, 09 Jan 2026 10:15: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 1ve9X1-0001ST-LG for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 10:15:47 +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 29b9bb4b-ed44-11f0-b15e-2bf370ae4941; Fri, 09 Jan 2026 11:15:46 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-47bdbc90dcaso29996405e9.1 for ; Fri, 09 Jan 2026 02:15:46 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f69e13bsm199378305e9.7.2026.01.09.02.15.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jan 2026 02:15:45 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 29b9bb4b-ed44-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767953746; x=1768558546; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=fVA1rSjWi6G/rtKUq1UxoQ/RhvkAp5WPuA1D7/JzIaE=; b=ICY9NjVDAUt7Ysx1bRwBhWViKkjJ7MphJbt1ftDGz+xtCD6bpjXIPgmOKjbhUs2Kou VNxpAQN+Pati+4ioRNuZkl2uT89V7VJ7a5ydo6h3tiSm2Y4Vl0T4PSAOZCOqJdAMCODB r47d+Vqi1cACN/CcAZW4Mv77R6EhCnilKtOi+eVBjtFn0GOr/TdS3Kx2raJ/YyI252nz DZ/Wmqt24xcUOmMTh0vV5B+6XZKtbd5ex/pqPs6spjwkfVJsvR3d8D4S6/QQmqpAl1eK eSX43+gZbC22bhCP4o7PcC2z/wjtpCVGTeTQD72BmIriDpzryVXgGWK/cNYRrVSqLJEs zw7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767953746; x=1768558546; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=fVA1rSjWi6G/rtKUq1UxoQ/RhvkAp5WPuA1D7/JzIaE=; b=qOHJahVols6AY1mkWDjqfs/rOBVYiDSHS6IxMJnWx5LwUvUybtwgW4Oa+y3ztbU8tc 6piZpZl1xO2E6kB6EF4FyNDCLrTp6Xj/Gpx0iUiu13GJIGYFBi2rbTXRMBPFyRuxplvl CREGqtbpiR+0k5907OTkH893LV2I4C508IAmPi8tTUFwICdzu2+LFQa4JqgesVQVOGMq Q0PgZKThBPEC0WqSDCsG7iRez0tzRNfAOklaq9jDrPKuKkcnNA1cGfCuItnztxymlrLy 6jGp6RZifndh5ZDxxw0XQROom+Xm4BUQMpKx5zP6mHcsZn1F/D2Z0Zwh7StU0HOHUwgt QMwQ== X-Forwarded-Encrypted: i=1; AJvYcCVtKfrZO4AFi+H4R00545mLrvPHw849Pdx+mGOgIMBk0nUCbu0Pa3myAGccnDMDlwxV+iSDJqTdRbw=@lists.xenproject.org X-Gm-Message-State: AOJu0YzFVmKIMNyz+KoqsN0u6wnFvcpyNTvC/HkYzTUUMx/+C1LK+Y+Z ziArpbN5/C1Rd1QmxlgQkzxFSV2Df6GT90l+7My+s+lsO5IzBFFhjgZcYdAPgUimpg== X-Gm-Gg: AY/fxX6IDAzb0Iy5hz33vxqotxMa+sScKfWLwLpKkaht4VISLBBAN8v7TCNXVqOK6Zx wp3eOarZgIvD4ni4StkXQb8oz73Ovz+zJ9WiNX/VS96QwBDWXEFlG7RiLtwahp+fEwqQ1UhI/SX Mbw74Q6mncnjkcpN8K7IZ5OFPY+EQH1H1ioEgm8v9JzG7XXS6a0TQTOYrMOiuQ/rIQIGhp/JUuV JXMnUkHsOAUhQ3VXaVDC9sCAVQisDw/lVcV3AYMXJF9tap7JKJaICdoCEgdgzFFt/sD7UObJwy8 YypRFf9dZPAfMKm1h9EA6vIRQs3XAFVT6iwlfu+71dU0p943PioXzzt0JRD6IOxbBIklXjlrqer AOhge0eWkivZPCdT4uj67viu/KoI5WE9Omr0QFVsvg+ftvwF30k4OG0S8eeuvc0iquLzLn919xZ 99pK/Nrue1jJAV07QCTIRkxY7WL3qejZIQIqarNkVe6+d+84T1We0ArpclCBuypk0mvOa0rfpnw fY= X-Google-Smtp-Source: AGHT+IGDC8CwfQT98zCZ9dybrpHU6ESX1vFIzYFnEyuxySWQjOlcUqBAx3ihqos2dn9/mJZlK8SXRw== X-Received: by 2002:a05:600c:468e:b0:477:a1a2:d829 with SMTP id 5b1f17b1804b1-47d84b1862cmr114836235e9.13.1767953745690; Fri, 09 Jan 2026 02:15:45 -0800 (PST) Message-ID: <6b4c352b-f4fd-4b81-84ac-41b7d3e04f92@suse.com> Date: Fri, 9 Jan 2026 11:15:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/2] xen/mm: limit in-place scrubbing To: Roger Pau Monne Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , xen-devel@lists.xenproject.org References: <20260108175536.82153-1-roger.pau@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260108175536.82153-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 08.01.2026 18:55, Roger Pau Monne wrote: > In XenServer we have seen the watchdog occasionally triggering during > domain creation if 1GB pages are scrubbed in-place during physmap > population. That's pretty extreme - writing to 1Gb of memory can't really take over 5s, can it? Is there lock contention involved? Or is this when very many CPUs try to do the same in parallel? Jan > The following series attempt to mitigate this by limiting > the in-place scrubbing during allocation to 2M pages, but it has some > drawbacks, see the post-commit remarks in patch 2. > > I'm hopping someone might have a better idea, or we converge we can't do > better than this for the time being. > > Thanks, Roger. > > Roger Pau Monne (2): > xen/mm: add a NUMA node parameter to scrub_free_pages() > xen/mm: limit non-scrubbed allocations to a specific order > > xen/arch/arm/domain.c | 2 +- > xen/arch/x86/domain.c | 2 +- > xen/common/memory.c | 12 +++++++++ > xen/common/page_alloc.c | 54 +++++++++++++++++++++++++++++++++++++---- > xen/include/xen/mm.h | 12 ++++++++- > 5 files changed, 74 insertions(+), 8 deletions(-) > From xen-devel-bounces@lists.xenproject.org Fri Jan 09 10:22:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 10:22:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198519.1515435 (Exim 4.92) (envelope-from ) id 1ve9dk-00035M-SG; Fri, 09 Jan 2026 10:22:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198519.1515435; Fri, 09 Jan 2026 10: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 1ve9dk-00035F-NU; Fri, 09 Jan 2026 10:22:44 +0000 Received: by outflank-mailman (input) for mailman id 1198519; Fri, 09 Jan 2026 10: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 1ve9dj-000359-Mv for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 10:22:43 +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 2170e00c-ed45-11f0-b15e-2bf370ae4941; Fri, 09 Jan 2026 11:22:42 +0100 (CET) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-432d2c7dd52so1105874f8f.2 for ; Fri, 09 Jan 2026 02:22:41 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5feaf8sm21674096f8f.39.2026.01.09.02.22.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jan 2026 02:22:41 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2170e00c-ed45-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767954161; x=1768558961; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=lsCqmuzqktYxl6WeQXdwoJ8q3loePMtShd3yE+Se1Bs=; b=aWL47M4qngho0b/1+xZptQuXlmpmZ8wUdXzw50VxPMQ3w7Rlu2z5+9/sKNqDi4OC+G 2M5XlyHcJljCuY2RuIkLzjMtI6iWc1yGVDtg4pSImyI+xDdGsbzd5i9G88AKpIqrefvw yZPASfne7OKZTDIg38m5Hu7HAaZ7oV+3zRnTqmdO6V135XZaOXIzH/9KBONlxw/XBEVw HWzeKpisAkyBH9+rF1rjWqi8dzuxpNYf/a+HOPuoBa/3GlT7adNCp1XnMwGitfTlPxIL dt949hk2wlZLlxjSLeSu7psFBMhRp8AoDFg+EoRw7bgUXO5DMbS6IZcszOV/+CWtLHAS JIWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767954161; x=1768558961; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=lsCqmuzqktYxl6WeQXdwoJ8q3loePMtShd3yE+Se1Bs=; b=I6Vb4AJIcNBN5XWxZ5/aBhyOKj8cbIbZ0eJjdDH01YxiaJP1Ww3rVO/PJmTBSiA0ss HctX5VzaRxA9XphPvDAtxj23vTTTEOGzgsupo9CWFQuU6ARC+BGc53kh7trqb3YhixrV ebfAEkynT+HWPmLzDsYqlMbGoIoPOKiipYVA4lVL9yljzKZaQ0XbSb1AfetjyoTIecCU 5WTlnMwmmd7ICE1m7+EPObEUpu4b/O34orbp4QEGd+I1InjQD3W0WvwKe5uDqIRXTMON 8DlTI7TKP5arB5TWSD1RcWg9WgeG4qc7kxKI5V0Y2qAZLvd2bsKMaZK8fO+UR3n8yQ7W GEhg== X-Forwarded-Encrypted: i=1; AJvYcCUtu/6rYEVRfZjplQ4i1GteOGZ4oAa2HwE6jmwZZPBuKWbkn6KQO48gGGQuVO18gHMiIoHk2YPvdX4=@lists.xenproject.org X-Gm-Message-State: AOJu0YyuTZ61aFHukRI1Q/ODU6/3ZI0/t2MWt2j9fSjEE4AcuG+mx7GT OHMf4IZ+T9jCjqStebu0++Wol3fUBv268yVjcXfpGlMuMNGhpwvVxAe83KNSuIpvPA== X-Gm-Gg: AY/fxX5LI32cvPM9vTKfJBbhHUzWn2Xkxj4HuQchFM+xIGWjqFiBXY+8aAeCRafZ6Oo sSSKKnZb6Pxw1gL+BDzipIPJ/dYe/fBtoLUvzylS1GQTARzUTtLLE5C8ZLxR8ri1Elzs918yWTr XmTh6+jTXSp5u2FmdhX2/PuxQrurIPtoIg2intRAyb+cFU53L5sR8XFYkvkKxYszZ5LHeAREkko AQ2gCrbzmWy6wOCGWDiEIjU2Ek1iM6Jk3pJLfgDe9oLEy0DVyuK2AoIUcmOg+6B6+8NZ5C2cE80 eLyqgS0NvP2GW6NVzUyg9hdk0pVEHZKxm0Cknw5eDuJYVhxQT2uTS5NHqtOXom+t9UVKsmtYOWI D5RMoFLQCyukE/qkxvEZN36GQFTrZPwqA58grAjuRBIrKuV2Zv0H/0dOmrFIZ6A0RGj6lW9RJVA fj+KSxE0mq0ISCdpyaA8B9xTUi/LyUod9X38fUB4z+HRLkip6dnzUp1LZGuyJk+MiJbQXHtEkoq nU= X-Google-Smtp-Source: AGHT+IEDWjj5W7I7H/yMMgwr4pePoGQeLQ1B4bXcP3lo+7E9p9gJLPEVketVHnd5GBpLmVmnyEwnIw== X-Received: by 2002:a05:6000:2584:b0:432:5bf9:cf22 with SMTP id ffacd0b85a97d-432c3760f0amr10665727f8f.3.1767954161301; Fri, 09 Jan 2026 02:22:41 -0800 (PST) Message-ID: Date: Fri, 9 Jan 2026 11:22:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/mm: add a NUMA node parameter to scrub_free_pages() To: Roger Pau Monne Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , xen-devel@lists.xenproject.org References: <20260108175536.82153-1-roger.pau@citrix.com> <20260108175536.82153-2-roger.pau@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260108175536.82153-2-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 08.01.2026 18:55, Roger Pau Monne wrote: > Such parameter allow requesting to scrub memory only from the specified > node. If there's no memory to scrub from the requested node the function > returns false. If the node is already being scrubbed from a different CPU > the function returns true so the caller can differentiate whether there's > still pending work to do. I'm really trying to understand both patches together, and peeking ahead I don't understand the above, which looks to describe ... > --- a/xen/common/page_alloc.c > +++ b/xen/common/page_alloc.c > @@ -1339,16 +1339,27 @@ static void cf_check scrub_continue(void *data) > } > } > > -bool scrub_free_pages(void) > +bool scrub_free_pages(nodeid_t node) > { > struct page_info *pg; > unsigned int zone; > unsigned int cpu = smp_processor_id(); > bool preempt = false; > - nodeid_t node; > unsigned int cnt = 0; > > - node = node_to_scrub(true); > + if ( node != NUMA_NO_NODE ) > + { > + if ( !node_need_scrub[node] ) > + /* Nothing to scrub. */ > + return false; > + > + if ( node_test_and_set(node, node_scrubbing) ) > + /* Another CPU is scrubbing it. */ > + return true; ... these two return-s. My problem being that patch 2 doesn't use the return value (while existing callers don't take this path). Is this then "just in case" for now (and making the meaning of the return values somewhat inconsistent for the function as a whole)? Jan From xen-devel-bounces@lists.xenproject.org Fri Jan 09 10:29:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 10:29:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198528.1515443 (Exim 4.92) (envelope-from ) id 1ve9kI-0003jq-Fr; Fri, 09 Jan 2026 10:29:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198528.1515443; Fri, 09 Jan 2026 10:29:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ve9kI-0003jj-D6; Fri, 09 Jan 2026 10:29:30 +0000 Received: by outflank-mailman (input) for mailman id 1198528; Fri, 09 Jan 2026 10:29: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 1ve9kH-0003jd-LQ for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 10:29:29 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 12f4adda-ed46-11f0-b15e-2bf370ae4941; Fri, 09 Jan 2026 11:29:28 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DM6PR03MB5065.namprd03.prod.outlook.com (2603:10b6:5:1e6::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.4; Fri, 9 Jan 2026 10:29:24 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.002; Fri, 9 Jan 2026 10:29: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: 12f4adda-ed46-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tOeesVOkv319W0tvcZFOHytqAiJ5YjDm4FXuAlBaNSatEXBhIAE6BBx/c/DwRrg/Ops3BDrQgHf3JSwr7uTYofp6+VFChqO2S09B9fppTqJVO/hrcuQtGLf9eD4G4eiNGvpIWRE8c0/D9Jl+2xP11uMGw2uilFIji4dmWeLV4JV2TM8WdqLb0mqZWNrp68yavZgTbE5Us8VuxwMzr0ielLKTRylz3vU0p/xQIvkXR7BIAdSAkYMEWBvshUXb5lM/ugbBrigVOL1m54iw4SEpZtFjIq/h69++KLDkgSdilXyDK9ZtdcseE1X0WiMzGGuAnnY5pKVXoe/pVocJqW3IyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=T8Kiv3g0HXuAFdz8U4Z/Yr9RVDAKlbyY5D2x8e+aL1I=; b=CmrcrhYTShwJFpaLk6BCnGxZdcoZ3tRjHv4eLdA04aOY3wPN3XwhnvIjnz3XAbhYd4B4PiUVvWZ3bs1+/xgKiAJJeJ0OLoN4iLVIIgusdn8r0SWMUWfWayvOqilHF00T964y2HQPtipuwCOH070I83VsoR7nAhUIMoFfXTiVSuzEUgUPyO6uXJhx+RT229AhwHaFoZc6HdvuSbeAG24VKdUKKsOp2nqAOjrNoaQjYPb88FzUqWFY6hqLsONc/gdGW489oIdExIiRqOOBz9uZx0jPcuKBR1oE/h/PFuLGNRjnSNGipK+0It2ZPbi2L0o26IIw9KwfKgcGJxwZCxSAgA== 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=T8Kiv3g0HXuAFdz8U4Z/Yr9RVDAKlbyY5D2x8e+aL1I=; b=HupfWUqBEchKlnxOiuAWJvL13xtswEPQklPLexv9hv+8szYsW3c7HInjkwtL0FPBPdXU864jkqIK9edeEUjwsIXFSMK6oM9TOKQGOPBjUU643f0j1u8bFRhn4RixqDw+bHW13Bb6st8ZXe+rO3KXTJSAeuNT/WLS/VXkU+8fCqA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Fri, 9 Jan 2026 10:29:20 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Anthony PERARD , xen-devel@lists.xenproject.org Subject: Re: [PATCH 0/2] xen/mm: limit in-place scrubbing To: Jan Beulich , Roger Pau Monne References: <20260108175536.82153-1-roger.pau@citrix.com> <6b4c352b-f4fd-4b81-84ac-41b7d3e04f92@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <6b4c352b-f4fd-4b81-84ac-41b7d3e04f92@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P123CA0097.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:139::12) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DM6PR03MB5065:EE_ X-MS-Office365-Filtering-Correlation-Id: b727994f-7daf-4ebe-2f34-08de4f69f598 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?Sjd0NHdTY0lYdHFkRy81UzRrWWN5WHgxeHkwM2NQUk9IRHFlYVhMTkFHVnVQ?= =?utf-8?B?ZGNwQzd0dzN0RTFHUHdodGhyYkVVNFVJK09BYitGTzk1a1B0NUpMS1REV1hp?= =?utf-8?B?RTBmR291VWpScEpUMmNDQmluWTVNdmQyM1kvbVE4cGQ0Z09zTlI3Y2ZWczNK?= =?utf-8?B?ZVUzWk43UVA3YVlxVDRWdTY4MkQ3TC9GOTdWditZWXNsc0ZpaEwwYVQzd3pO?= =?utf-8?B?R2pMYTRmM2RQcUF6MENnQWlxZmVYKzRtOEtVY3JLQ2MwbDl4YXBwSkNHNXBW?= =?utf-8?B?VTdRVHlBeTNldUM0bE9jVHQ5TER4SHNBZndHOHR3dTBIVFJrWlZaYysyQ0ZJ?= =?utf-8?B?ZUdOU050dTJWUFFBV21WNjE3dnYzR2tJMDNmTlgvdXczb0FpV21ra09ZUUY3?= =?utf-8?B?VUJDbnFlYmptKzV4SG9kSVQvSnBEY3ZrN2thVFltUjZ1NmhPNnZQZ2ZPUHVC?= =?utf-8?B?dHhnRzR1L0VjS0o2b0ZlSEdyZFA2L0QvcForNmRJeEM3YVRvNE1TbTI4eis2?= =?utf-8?B?UU5oRU1aUTc2MUpteDhGWVEwbGZZS2FUcTBBRDdwKy9IbjhraXhORkMydXB4?= =?utf-8?B?cVRnZ0RhMEtwL0p5WVBveERZV1pOWUY3NU1BKzdIckhtU3VEaU02L1dROHF1?= =?utf-8?B?cVh1czBXYUtwQUlKY3dqcyswMTRSNStrUHE0T1RrdGNpVmJnWTJucGNUUndM?= =?utf-8?B?QldFSzNmTWZpeDd2SnhVakJMZkxhaUZwWDFORHJINXg5Skk1T2hkY0RYWGV1?= =?utf-8?B?Wnp1Y1hMTW5WVlBHaTl5UlhIV0dtcEd4MXRMN1BFb1ZtOFg1cEhWUFRlS0x3?= =?utf-8?B?c1pES1JTcmphVE42Z1BrbFFjOVVjeUVQRUVxeVlzVTFISm9xRU1WbTlKaUJa?= =?utf-8?B?TnhQdGlRaGNYV282RUh5ekw0QzJBR3NPaGlmd3MzeEVKQ3dSenF3Mjk3OU5V?= =?utf-8?B?UGVWMC95ekF1V1crVUEzVFkySEhZVWwydlJNaUhQcVIzWFJkUDVIbnQ1bmg3?= =?utf-8?B?MGtraktZeHN0OHBabEg5WjlTSkFaRTZxclJXc1lGb1ZZYmczZVBEWmV5dWJo?= =?utf-8?B?Nzh5NGNna1NKViticU1kbHhUcE5KcUZkTUtYSW1WUVcrZmQ2OUQvNm1YbWZq?= =?utf-8?B?Rk1IUmdDNnY5ak1rK3dXbVJzWmZwZzVJMCs5S3lFN3dFc2RBcU5jWUtTdmo3?= =?utf-8?B?MGFjc2xwcjJXRTlCSDZEeDhXZmxmbmtGWFlxbTNyNFV4YWRXSUtES2dvUUtS?= =?utf-8?B?RGNnUHNJczlIODRhaE1YSkk1VTRrNThTYlBsVG92eDBYZjd0NzRKL2xKYzBU?= =?utf-8?B?R3VFVllMNkNENm5USzIrYTFoVFRHNE1MSCt6Mk5ZYzBZd3hMOUphZHF4SmVD?= =?utf-8?B?YmRmeXprUmZxaitva1JaSzgzMmRFMS85RFRvWG1jbzFUSXg3VzdEU3hROWlR?= =?utf-8?B?eHV3RjNvZjd0S1diR1BqMlN0RnZMdHlxZFVrVXFHWEdWS2FMZ0ZZbHAwSHBP?= =?utf-8?B?KzZpZTU1WU9aT1ZHTWZnSm10SUZqSHpyeks3M1ZBbldUY0tmNWRkbEg3bllx?= =?utf-8?B?Qm81bUx3MmVKUUhrME9yUk5OeDRmQ3ZKSTZPRmRGdmtTeUhrZlNPcE9LM0JQ?= =?utf-8?B?SGF6bkl3ZXcxTWFhaHViQkNIR3pZd01zM3dlOVJuMUkrRDdmZXl4S3IvYVg0?= =?utf-8?B?SWFEOXZTZmg2SmVEMGNxYjVZY1lSK3NtbWJVclAzTEdNVmdEaWtPYUdtdVhL?= =?utf-8?B?UFgzcUZCSVNqM0ZrUVlML2l3dExlZEZoOVBXZTMySGc2QWtPTG5SNW9yT01X?= =?utf-8?B?MEF1SUJkbUFwSjZYWWJNckRJOW9Lb2VxNDRObHYyZjQ0SnRCWE9XMVptV2wy?= =?utf-8?B?bXB1dHN1V0VMUnEzUDBFWkdPK2c3TzBDVlN4b3pyRVF1blVseUIxTGlNZGFK?= =?utf-8?Q?kY7uefgdFouji1rMHjq3To+HAEyu0piG?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VVlSUUFUMXVKa2wyQkg0RVlLRkJiSzNGbi80dVpwM2FFOFV3d0E4UDNsNGJt?= =?utf-8?B?VGRBdkZmNVd0bitmN01GV0lScW5kTUI0YWJ2TkNibGI0bjQ3UWw1NEFVZUE1?= =?utf-8?B?clFCQnY3aFBvOEFTc2NXb1RIUGljcityUW1jTWt3YlVrbVFkMllCdkd3cFYx?= =?utf-8?B?YVlrT0hqcHpRVHNmODRpaXM1RkpoOFc5L2YyK1M1QXcvRUtIK2EzaGxsRlJZ?= =?utf-8?B?K29kTjJjc3JZeVZxMjc0MXZpQU4wbXRhL1VQcG4rV1lGTitXOFROU2Vtak0x?= =?utf-8?B?U09UZXdaTGhjaG45WDBNeGxNcENuZ1oxejNuTUd5TUc3Wm1Wb2FTSzZtMmpL?= =?utf-8?B?Y2ZpQm1HVmVYSGdtQUVIcVBUNlFnVW1UZlNrRUFRRWoyaUlwZmkrbVdCTVMr?= =?utf-8?B?b2thUXBNQWxYbXQ0WUdsYnRJeDE2ZFVoM29xTnRmQ3A4V0F0a01qQlZVT3pn?= =?utf-8?B?bVY4UlRwZ2dTQitJWjZTZnR4SThqTjF6bEMrd09qazJqblE2TDhjNzhoZlp4?= =?utf-8?B?d3FtVDkzZmtqTGNTWWNaVkF0Mzc3QzJBOFhCWjFRSkVFZTJKZEFSZFVyUHAw?= =?utf-8?B?QlFZT002aExIR29XNmJVQVI3aVgyb2h1OEs3NERiRlVBd3ozNSs4YU9HbytY?= =?utf-8?B?K3VibVJYeGhDZHZ3MGx0Q09zMHZKM1J6aHA4V3RnMjRueUxtL1B0QUVPNHJy?= =?utf-8?B?cUZwM2RvdG5rcFIyOXhLWTd4S3VPeHRqYTFZME85UXpLRXFRdk5jTHdWem5z?= =?utf-8?B?SlBGWlRVOXZNWXltYWVqdnFkeDVPRk1vd2EycVJNU2o4Q0R5MldobEY5Yk5V?= =?utf-8?B?WjVpeFhvUmNIbCt1Wmh6QUYvN0R5bjE5dzVJNExDVWJHQ1BCWWhkTXRUZlZm?= =?utf-8?B?UkJqRUoyZkZMeXZLZjZOa1ZVTmdZeUYvMDJuMG91aXoyYWtDVkdkWUovWkZI?= =?utf-8?B?OVFtSnJqZDNPaHFZYlZyWkJLbjJWT01sWDRpeEZqemthT0lUVDNVTnBsL2ZL?= =?utf-8?B?K21RQUtUMG9PL2N5K2lFRXBmbE80a0RXR2FDYUc5SEZsKzhyYWt0dEZnSWNi?= =?utf-8?B?aUZ1NzV3WkhYRU0wTjVsSGN1dS9sZTNUY1pKcjZLZDVVVjdTTThsWmdpTDdP?= =?utf-8?B?UGhNakJDc05yMUF4dEZsa1NkYlkwd0JPeThmbGQ1MzZ3UEFJV2FxL0dWUHVN?= =?utf-8?B?SC9pTURhV3kxMTBQem1rSFI3Z0dKNklaWFlKUy83NGxnTnUva2FEcUw2cURl?= =?utf-8?B?RW15QlkycFdXZWxoVGw2Tm01cFZMRGRIdVI1NVZFVEw0WFpEK1Rjb2k5Q2Qw?= =?utf-8?B?LzFQaWpqTDlwS1NTdS9qQnNCb1NEVWRITDFadUhSbnY2L2JOdk95TVhyMmd3?= =?utf-8?B?b2ZDblNxdmkzakxIbkZwK29wSUppeXBvbGtWckpFYTBSTGhsVjdsNjRBbGxy?= =?utf-8?B?RlV6Nk95cWVrT1F0V0RtYis2Sy9Xd0pLYjA4YytPcmUzMWdJZGZ3MlRjU29O?= =?utf-8?B?OUhha0hTdkhZNTZXMnBJOVEza2oyLzNwMWxLMmh5Rm5jSGR6b2hHaWQyM0FK?= =?utf-8?B?bEpQbkZuQmZBNXZXSzJaSm5mbU5HOEZmNjhUbFUrOWsvdUNORUxweUs0SnNw?= =?utf-8?B?UTlkbGgyQnhEbXBMZ2dVNG1YVXFrTFpSVG9IMlErRG5rK0ErZHVWK1d0TEFL?= =?utf-8?B?SHV2eFZ2ZWlMMDYxcWxmY0h4cHprd01zVlNTM3E5Njh0ekJKeER3OWxHRjRF?= =?utf-8?B?Mm8xMm1ycURTL3R1K0RLNGg5WXJQN2c5YVZBZnRyc012OGdjQXBUcENDdDI5?= =?utf-8?B?T3RIdUl3bDFnOExhVlhtM0VPWEJGWHJFNW9GQXVza0UrMWxQdWQrT1duRFVS?= =?utf-8?B?dWlUNjRvTWxhTzJuNjNDWStXSlVHVGQyVkFjQjlNZWNhdW1haU9BNGRvTWh5?= =?utf-8?B?RDljRldDcUZaOFcxKzRKcThtMG5nODY5dm9McWVIMVFBVWc5c0FENURjOCs5?= =?utf-8?B?YlUyV3BmTC9SdE9MVlpPdTBKMmNPdUs3RzJmakx1NTRUenM4MWNMV2xxMlVX?= =?utf-8?B?QjZnbFFSMWFCNHVNQmhyMXA5eGV5SkNvR1ZrMys5ZlZTbDRmRzNmUGlIQUJY?= =?utf-8?B?SCsvNzBCeHdzRXBHbDFGSHIzOTBOdjVFQWZTMFVoZWFVbEpqMkhPSGtSRHdW?= =?utf-8?B?REloNGdaRGtoSDhETXYwdlp5TWw4L1phTGVrTmFrS3NHeHV0d3J5aFFHOEU2?= =?utf-8?B?bU41NHUrRjdTYUdpa2NVRGZCWTZKcGwyZlhxNDYrSE1NMzhrS2taczRXYmFU?= =?utf-8?B?bEtwUkxZVnErdG1Gb2YzcXNrQ2NaU0JGSisvQlovM2RmSldkWXNhZXduSG9r?= =?utf-8?Q?pQ+vMbY1Va6BPsVI=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b727994f-7daf-4ebe-2f34-08de4f69f598 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2026 10:29:24.4464 (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: 0Saa3W3k1+iOF++kIEEFI65PIc3ua6uyi+9lgtKMT+taLu0BEseMFWeU2gXqGVPfmuZSO95+uFv4rL1AcVsW1BWu0crvEy2t9MvfSkAvhww= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR03MB5065 On 09/01/2026 10:15 am, Jan Beulich wrote: > On 08.01.2026 18:55, Roger Pau Monne wrote: >> In XenServer we have seen the watchdog occasionally triggering during >> domain creation if 1GB pages are scrubbed in-place during physmap >> population. > That's pretty extreme - writing to 1Gb of memory can't really take over 5s, > can it? Sure it can. > Is there lock contention involved? Almost certainly, and it's probably the more relevant aspect in this case. > Or is this when very many CPUs > try to do the same in parallel? The scenario is reboot of a VM when Xapi is doing NUMA placement using per-node claims. In this case, even with sufficient scrubbed RAM on other nodes, you need to take from the node you claimed on which might need scrubbing. The underlying problem is the need to do a long running operation in a context where you cannot continue, and cannot (reasonably) fail. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jan 09 10:32:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 10:32:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198537.1515453 (Exim 4.92) (envelope-from ) id 1ve9mx-0005En-S9; Fri, 09 Jan 2026 10:32:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198537.1515453; Fri, 09 Jan 2026 10:32:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ve9mx-0005Eg-Pf; Fri, 09 Jan 2026 10:32:15 +0000 Received: by outflank-mailman (input) for mailman id 1198537; Fri, 09 Jan 2026 10:32: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 1ve9mw-0005Ea-EX for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 10:32:14 +0000 Received: from mail137-3.atl71.mandrillapp.com (mail137-3.atl71.mandrillapp.com [198.2.137.3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6db0d167-ed46-11f0-9ccf-f158ae23cfc8; Fri, 09 Jan 2026 11:32:00 +0100 (CET) Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail137-3.atl71.mandrillapp.com (Mailchimp) with ESMTP id 4dndPB1ttczBsTlVl for ; Fri, 9 Jan 2026 10:31:58 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 0fd3b5e820884520bf223a4b27250d9e; Fri, 09 Jan 2026 10:31: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: 6db0d167-ed46-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1767954718; x=1768224718; bh=YIknYhztqWSVrk+mnswzaptf+MwJWbjnKORblGlN2So=; 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=OxaK69xviHFfu93+1g+Q2m2Tn2BC8vadHMjEYU09t0yBZV52ALNLqbqqRUpsp79VR F4DyuDykzRL6iiz7mgVw3SiaUZReBgMmdp3oDFgV7nOyyE/a9tnQKLbrdqJEehtYIs aJLd+ux5ZUpHuF7at8kH8Yit9Fw8X3UB7WZO4pzOzsK3KYjFKZ27/soCtJMoasr1i6 P23xu9JI8fyGbaOaAZDhVdNBiuHSBGTxIKPjvCr4MA3GH3ZBT/jzfjTICtkkXbnI6c q/S61OqYYp39YRvTbyNcYmEyxjTrcYSM4M7AnX+w1VqgLRN6SqjTiQAecf78NuO7XQ 7EewIHIf1dAIA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1767954718; x=1768215218; i=teddy.astie@vates.tech; bh=YIknYhztqWSVrk+mnswzaptf+MwJWbjnKORblGlN2So=; 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=oVnm9F0NeuEoPTYj6hwfh6JAGM6VJAkavTDsGDNlNjPt4dOpBKqF+T8EABGeVLgYu T0kDf+4z4+XssYrllHpWMVUXMq+ut2eqxHAr+6IrVi1oaXAQL4TL01SxxAnb8gmk+n jIFSJYOK6x6EtW4i26MXYDyaQGh7eASA/onjYJBzoUv7mPZvvo4M8vdUAmzq4uiLuJ 6Rq6KOy7x9i6oTO6jrfBRUq8wGGB8ciE8logqZ5+xALUP/J519CsGd+f/8Iqnxx1tW jJB6KOhIRJI8QiqLkSZiVQH/Dl2O+m3Dq602/UFuaI9hT8551vYjEPWuuOthqRZO9U o6Krl7u177Llg== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[RFC=20PATCH]=20pvh:=20Introduce=20SIF=5FHVM=5FGHCB=20for=20SEV-ES/SNP=20guests?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1767954716857 Message-Id: To: "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" Cc: xen-devel@lists.xenproject.org, "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Jan Beulich" , "Julien Grall" , "Stefano Stabellini" References: <3b6f5146287d3402a09836b7cf876d4f8dc9eee1.1766889890.git.teddy.astie@vates.tech> <0c9c1dbb-28e1-479b-a680-e99150b3f0da@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.0fd3b5e820884520bf223a4b27250d9e?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260109:md Date: Fri, 09 Jan 2026 10:31:58 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 09/01/2026 =C3=A0 09:59, Roger Pau Monn=C3=A9 a =C3=A9crit=C2=A0: > On Thu, Jan 08, 2026 at 07:12:48PM +0000, Teddy Astie wrote: >> Le 08/01/2026 =C3=A0 18:46, Roger Pau Monn=C3=A9 a =C3=A9crit=C2=A0: >>> On Thu, Jan 08, 2026 at 04:50:51PM +0000, Teddy Astie wrote: >>>> Le 28/12/2025 =C3=A0 13:54, Teddy Astie a =C3=A9crit=C2=A0: >>>>> Under SEV, the pagetables needs to be post-processed to add the C-bit >>>>> (to make the mapping encrypted). The guest is expected to query the C= -bit >>>>> through CPUID. However, under SEV-ES and SEV-SNP modes, this instruct= ion >>>>> now triggers #VC instead. The guest would need to setup a IDT very ea= rly >>>>> and instead use the early-GHCB protocol to emulate CPUID, which is >>>>> complicated. >>> >>> Possibly a stupid question, but how is this information expected to >>> be propagated to the guest when there's a guest firmware and >>> bootloader in use? >>> >>> How is OVMF and/or grub propagating this information between >>> themselves and to Linux? >>> >> >> When booting Linux with SEV+UEFI, at least during the UEFI services, the >> UEFI firmware transparently handles #VC for the rest to allow it to >> perform CPUID operation. >> (with SEV-SNP CPUID page exposed with a specific UEFI mecanism) > > Hm, that's going to be cumbersome when using hvmloader in this > scenario, as it makes extensive use of CPUID and hence would need to > setup it's own #VC handler ahead of making use of CPUID. > > Or we must instead get rid of hvmloader. > For plain SEV, hvmloader would need to run with paging (PAE or 4-level) to properly handle encryption bit. But would also need Xen to handle MMIO instructions (which has some quirks due to being in encrypted memory). For SEV-ES, #VC handler + GHCB is not only required for CPUID, but also for VMMCALL, MMIO, some MSR accesses, ... It would be easier to not use hvmloader, especially since only UEFI supports SEV and guests would still need to support (Xen-specific) SEV bits to begin with. >> So overall, this proposal is only meaningful for PVH booting, everything >> that comes after can be handled differently. >> >>> Are they relying on the CPUID discovery logic mentioned above, or >>> there's some shadow infra used by KVM for example to already convey >>> it? >>> >> >> OVMF at its startup relies on #VC for emulating CPUID. >> It then relies on GHCB MSR for getting SEV info/C-bit (but only with >> SEV-ES). And under SEV-SNP, it uses "CPUID page" instead of GHCB >> (PAGE_TYPE_CPUID in SEV-SNP firmware ABI specification). >> >> This is because SEV/GHCB specification recommends using CPUID page under >> SEV-SNP (even though the same protocol as SEV-ES still works; but is >> discouraged). > > In a previous reply to Jan you mention that Linux already has such > handlers, but just for the decompressing code (and hence not reachable > from the PVH entry point, that's already decompressed code). Would it > be possible to share the handlers with the PVH entry point? > Maybe, Linux already does this for few parts of SEV code (e.g arch/x86/coco/sev/vc-shared.c being also included in arch/x86/boot/compressed/sev-handle-vc.c). Everything we would need appears to be contained in arch/x86/boot/compressed/mem_encrypt.S. >> In GHCB Version 2 (SEV-SNP) >>> The hypervisor may supply the encryption bit position using the SEV Inf= ormation MSR protocol, >>> but the guest should use the CPUID information supplied in the CPUID Pa= ge to determine the >>> encryption bit position. >> >> But its location is unfortunately undefined in this specification and in >> the OVMF case, hardcoded in firmware metadata. >> >>> Adding Xen side-channels when there's an architectural defined way to >>> obtain the information is a duplication of interfaces, and could lead >>> to issues in the long run. We can not possibly be adding all vendor >>> SEV options to SIF_ flags just because they are cumbersome to fetch. >>> I know this is just one right now, but we don't know whether more of >>> those CPUID options would be needed at the start of day in the future. >>> >> >> That exists for SEV-ES and SEV-SNP (even though complicated) but for >> SEV-SNP, it would relies on discouraged mecanisms (GHCB CPUID Request). >> >> AFAIU, this flag is enough for setting up long mode and GHCB which is >> what matters. There are some additional structures (e.g secret page and >> CPUID page) which could in the future be eventually exposed as PVH >> modules; which would be hopefully less intrusive. > > If my understating is correct, this is not needed for the initial > implementation of SEV (when hypervisor doesn't implement ES or SNP > guests can use CPUID), and hence it might be best to wait for the > basic SEV implementation to be in the hypervisor before jumping into > ES or SNP details? > Correct; CPUID is handled normally when not running with SEV-ES/SNP. > AFAICT (from your Linux entry point patch) you end up needing both the > CPUID and the GHCB ways of detecting SEV support, so one doesn't > preclude the other. > Both are needed if we want to support both SEV-ES and no-ES cases; but if only SEV-ES+ is wanted, the CPUID path would never be taken with this approach. >> -- >> >> Some specialized boot process for SEV-SNP (e.g the one used >> COCONUT-SVSM) relies on IGVM [1] with custom memory layouts, initial >> pagetables, and so on. >> >> [1] https://github.com/microsoft/igvm >> >>>>> ## AP startup ## >>>>> >>>>> AP startup can be performed using hypercalls or the local APIC if= present. >>>>> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h >>>>> index 7f15204c38..9b84df573b 100644 >>>>> --- a/xen/include/public/xen.h >>>>> +++ b/xen/include/public/xen.h >>>>> @@ -890,6 +890,8 @@ typedef struct start_info start_info_t; >>>>> #define SIF_MOD_START_PFN (1<<3) /* Is mod_start a PFN? */ >>>>> #define SIF_VIRT_P2M_4TOOLS (1<<4) /* Do Xen tools understand a v= irt. mapped */ >>>>> /* P->M making the 3 level tre= e obsolete? */ >>>>> +#define SIF_HVM_GHCB (1<<5) /* Domain is SEV-ES/SNP guest tha= t requires */ >>>>> + /* use of GHCB. */ >>> >>> A concern I have with this is that we are adding vendor-specific >>> terminology to what should otherwise be a vendor-agnostic interface. >>> >>> There's already a fair amount of arch-specific information encoded in >>> there, so maybe not that much of a big deal. > > If we end up getting this bit, I think it needs to be clear it's a > vendor specific feature: SIF_AMD_SEV_GHCB or similar would be better > IMO. > I was thinking in case another vendor (non-AMD) implements this interface, but the MSR already has AMD_SEV in its name; so I'm ok using something like SIF_AMD_SEV_GHCB. > Thanks, Roger. > -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Fri Jan 09 11:19:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 11:19:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198572.1515464 (Exim 4.92) (envelope-from ) id 1veAWj-00028c-EI; Fri, 09 Jan 2026 11:19:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198572.1515464; Fri, 09 Jan 2026 11:19:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veAWj-00028V-BY; Fri, 09 Jan 2026 11:19:33 +0000 Received: by outflank-mailman (input) for mailman id 1198572; Fri, 09 Jan 2026 11:19: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 1veAWh-00028P-MY for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 11:19:31 +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 10124b94-ed4d-11f0-9ccf-f158ae23cfc8; Fri, 09 Jan 2026 12:19:28 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-477ba2c1ca2so45150265e9.2 for ; Fri, 09 Jan 2026 03:19:28 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0e180csm21370659f8f.10.2026.01.09.03.19.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jan 2026 03:19:27 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 10124b94-ed4d-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767957568; x=1768562368; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=z5Kg0iZz2V5+JGG8wyvq+zNrYx/Z3iemfLBzPnVlScA=; b=Sx/DSJXNjkMxB8QLY+Ub8vYUS39fvLV+7zkRoJ71Z51Lw5Q9U6QyqILgpzClk5umdA Ezx70GJEINufwPV0ITljPGwapO14XNCdmpfv821/qfKGOXapsvUCovS4is18zqJxUgwP NwSv3G4GALePjWGHmd0hOeYjK0yOdkLUOxUbWRv9NejoFqNu4eoPPJp2w7+uCKJhJKNf EwZTZy8OBVNKkkP8+PURI32+zSE/9aRBtFI7UJ22SYA2yBj70M+GVVprjCivhi2/x5CO vLe4T0ZwFZ4i4X9hHWxZ4LSOsI1VnzgIbUl9YbOX7jiETcMW+hQWY31x6hjh2yEH2Iud sUEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767957568; x=1768562368; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=z5Kg0iZz2V5+JGG8wyvq+zNrYx/Z3iemfLBzPnVlScA=; b=fN5IMNTgPL6RPdjH65d6DrE8u7VQDJm1M7WnxguwnjObNcKw52iLBNy0LpahnEhVJ7 q1zcsLEeKw0Q2n7YdhSE3QcgnzrnKpBNhzgcl1SJk7erkWmcNSwRDp1cF4gfqJXRnhm2 iBrsRarTTBbEsUkLG06FNfBLbM+mXfkyWTybq59pyUmgT4dNoHzEd7lMwIN7mvuRiuvR SRXLcKk/rII64fF4hkFUzickjwEzA8txIUpjkIN16BLlm/9uFfnaay5a59pFvpDYOXk5 celipnPZTpYQdQ65NoQJ9+JJ3ruhoilMhYKO1StiXblHbDm6reGbFYDqB0V+50IIJED6 cCHQ== X-Forwarded-Encrypted: i=1; AJvYcCUZtgoaTvdOH8rVn3U6KSPauKGznWNTB8OPhz3tRD3SDxErUIW2molXm0bf9PjVl84zBrbkn1vdOYk=@lists.xenproject.org X-Gm-Message-State: AOJu0Yyx7F0AvnVqIBFaA2VONEB2R+db+oxnU9nHHGSPQhntVmh9la/a zb4DXR7UYhse6MpcegPxPCCNoA3aXlIoj20vR/rZM8Q0L7wN7WWE09CD4cdjmnt9uw== X-Gm-Gg: AY/fxX76js+vpuEgw4ere4n3U7CdkD+GVOTwIt4f+i4RoZoZO4ko6ABBQS4xAdzLg7P JIrmXmxXUrq5ASFzxbAzMPk7Wmkmkg/hoYQfBFMqnCb7yNPTYxvX4SHM7H7+WGYqu4NQweitFkd 0L/WmnO+BywBEeNQ5R8RCbis3Gbs2pZ3isx5d2RmMZkKofjBiKxJdYfwhdqvS5kztgQSjjpKzBI oS+vNKuZ4PbkWfJihiqh7kA+6BKux56j4T1WCDjIzEWdtAz2m1DlgUvikA8hkZOtUOMIyzKXzBB 1OpAXLKZZ+96LgW5wuAUuyg4C1HDNuwsHuScOkXjnPefjncb4Re5Qyc5I7qNyu4euCCaGRBHF0T L817iUmmZEQhic9Asx59MwBiKr1a7JlVoVKP3bay/9z5HroWoL9Fm68OK1ZT+wds6jizBOzhu1Q 2/Ggvw44PGVviozPSbxth/MfAUkl4in6zMmVj6nfatSsmwU/jMReaS88V9P/UCQgxGWZd9FEFmu to= X-Google-Smtp-Source: AGHT+IEdKuuOO7zAhzWM3sTT3CilzFXkWQ52lXtmErcQ5bONUWcJIJXU2/escThixxSUWm4SBFoAPA== X-Received: by 2002:a05:600c:4f53:b0:477:7991:5d1e with SMTP id 5b1f17b1804b1-47d84b3860fmr92418665e9.25.1767957568115; Fri, 09 Jan 2026 03:19:28 -0800 (PST) Message-ID: Date: Fri, 9 Jan 2026 12:19:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] xen/mm: limit non-scrubbed allocations to a specific order To: Roger Pau Monne Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260108175536.82153-1-roger.pau@citrix.com> <20260108175536.82153-3-roger.pau@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260108175536.82153-3-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 08.01.2026 18:55, Roger Pau Monne wrote: > The current model of falling back to allocate unscrubbed pages and scrub > them in place at allocation time risks triggering the watchdog: > > Watchdog timer detects that CPU55 is stuck! > ----[ Xen-4.17.5-21 x86_64 debug=n Not tainted ]---- > CPU: 55 > RIP: e008:[] clear_page_sse2+0x1a/0x30 > RFLAGS: 0000000000000202 CONTEXT: hypervisor (d0v12) > [...] > Xen call trace: > [] R clear_page_sse2+0x1a/0x30 > [] S clear_domain_page+0x11/0x20 > [] S common/page_alloc.c#alloc_heap_pages+0x400/0x5a0 > [] S alloc_domheap_pages+0x67/0x180 > [] S common/memory.c#populate_physmap+0x22f/0x3b0 > [] S do_memory_op+0x728/0x1970 > > The maximum allocation order on x86 is limited to 18, that means allocating > and scrubbing possibly 1G worth of memory in 4K chunks. > > Start by limiting dirty allocations to CONFIG_DOMU_MAX_ORDER, which is > currently set to 2M chunks. However such limitation might cause > fragmentation in HVM p2m population during domain creation. To prevent > that introduce some extra logic in populate_physmap() that fallback to > preemptive page-scrubbing if the requested allocation cannot be fulfilled > and there's scrubbing work to do. This approach is less fair than the > current one, but allows preemptive page scrubbing in the context of > populate_physmap() to attempt to ensure unnecessary page-shattering. > > Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed") > Signed-off-by: Roger Pau Monné > --- > I'm not particularly happy with this approach, as it doesn't guarantee > progress for the callers. IOW: a caller might do a lot of scrubbing, just > to get it's pages stolen by a different concurrent thread doing > allocations. However I'm not sure there's a better solution than resorting > to 2M allocations if there's not enough free memory that is scrubbed. > > I'm having trouble seeing where we could temporary store page(s) allocated > that need to be scrubbed before being assigned to the domain, in a way that > can be used by continuations, and that would allow Xen to keep track of > them in case the operation is never finished. IOW: we would need to > account for cleanup of such temporary stash of pages in case the domain > never completes the hypercall, or is destroyed midway. How about stealing a bit from the range above MEMOP_EXTENT_SHIFT to indicate that state, with the actual page (and order plus scrub progress) recorded in the target struct domain? Actually, maybe such an indicator isn't needed at all: If the next invocation (continuation or not) finds an in-progress allocation, it could simply use that rather than doing a real allocation. (What to do if this isn't a continuation is less clear: We could fail such requests [likely not an option unless we can reliably tell original requests from continuations], or split the allocation if the request is smaller, or free the allocation to then take the normal path.) All of which of course only for "foreign" requests. If the hypercall is never continued, we could refuse to unpause the domain (with the allocation then freed normally when the domain gets destroyed). As another alternative, how about returning unscrubbed pages altogether when it's during domain creation, requiring the tool stack to do the scrubbing (potentially allowing it to skip some of it when pages are fully initialized anyway, much like we do for Dom0 iirc)? > --- a/xen/common/memory.c > +++ b/xen/common/memory.c > @@ -279,6 +279,18 @@ static void populate_physmap(struct memop_args *a) > > if ( unlikely(!page) ) > { > + nodeid_t node = MEMF_get_node(a->memflags); > + > + if ( memory_scrub_pending(node) || > + (node != NUMA_NO_NODE && > + !(a->memflags & MEMF_exact_node) && > + memory_scrub_pending(node = NUMA_NO_NODE)) ) > + { > + scrub_free_pages(node); > + a->preempted = 1; > + goto out; > + } At least for order 0 requests there's no point in trying this. With the current logic, actually for orders up to MAX_DIRTY_ORDER. Further, from a general interface perspective, wouldn't we need to do the same for at least XENMEM_increase_reservation? > @@ -1115,7 +1139,16 @@ static struct page_info *alloc_heap_pages( > if ( test_and_clear_bit(_PGC_need_scrub, &pg[i].count_info) ) > { > if ( !(memflags & MEMF_no_scrub) ) > + { > scrub_one_page(&pg[i], cold); > + /* > + * Use SYS_STATE_smp_boot explicitly; ahead of that state > + * interrupts are disabled. > + */ > + if ( system_state == SYS_STATE_smp_boot && > + !(dirty_cnt & 0xff) ) > + process_pending_softirqs(); > + } > > dirty_cnt++; > } Yet an alternative consideration: When "cold" is true, couldn't we call process_pending_softirqs() like you do here ( >= SYS_STATE_smp_boot then of course), without any of the other changes? Of course that's worse than a proper continuation, especially from the calling domain's pov. > @@ -223,6 +224,14 @@ struct npfec { > #else > #define MAX_ORDER 20 /* 2^20 contiguous pages */ > #endif > + > +/* Max order when scrubbing pages at allocation time. */ > +#ifdef CONFIG_DOMU_MAX_ORDER > +# define MAX_DIRTY_ORDER CONFIG_DOMU_MAX_ORDER > +#else > +# define MAX_DIRTY_ORDER 9 > +#endif Using CONFIG_DOMU_MAX_ORDER rather than the command line overridable domu_max_order means people couldn't even restore original behavior. Jan From xen-devel-bounces@lists.xenproject.org Fri Jan 09 11:32:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 11:32:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198586.1515474 (Exim 4.92) (envelope-from ) id 1veAis-0004ly-Ez; Fri, 09 Jan 2026 11:32:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198586.1515474; Fri, 09 Jan 2026 11:32:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veAis-0004lr-CE; Fri, 09 Jan 2026 11:32:06 +0000 Received: by outflank-mailman (input) for mailman id 1198586; Fri, 09 Jan 2026 11:32:05 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veAir-0004ll-7l for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 11:32:05 +0000 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [2a00:1450:4864:20::32f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d228e040-ed4e-11f0-b15e-2bf370ae4941; Fri, 09 Jan 2026 12:32:04 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-47d3ffa5f33so19768585e9.2 for ; Fri, 09 Jan 2026 03:32:04 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5df90dsm21756440f8f.20.2026.01.09.03.32.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jan 2026 03:32:03 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d228e040-ed4e-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767958323; x=1768563123; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=DoQJtgRseuwBXnMvEZ6r1webPeZLqmRHzg+eEKzlEWs=; b=fK77ij58R4B8kghOTmWHSfCdGnibBI29tVKUcwZljHf3A5orwRpmpa03h4RAc2+8JB 0H4yO1fp1HufF/hAS0zyXxaqCC9mkTWMvjbA/1T0xw13bmZCM006sqNzVdeAZwxuluUC EflGIc3ugPArLT6qp77IQD+s1mGhgOh6Z+NO61DnKw8eqoYeTYRT7SYg50jemUxhCvgi B0zgXtaTtjw8XKggpuZq1AobjeVq2m+AWzy3BA5LsK4U4jEuzJOiT6tXqcy9o2b6lVVB RHX4CuCL0lco+DGZ8CS3JTgR0Gh7UOaaZ1G7CGt/j7q93WZNgnZwDI+l6M4SUbUVB4Bs yNiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767958323; x=1768563123; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=DoQJtgRseuwBXnMvEZ6r1webPeZLqmRHzg+eEKzlEWs=; b=WR+a9agqTBiVfjD9/CmvI4zWs2hY6NYoxRnF0+Mhs6PkB7LVF4Ex/rxRXiRMotokAn qS28ZDrJU59n+fbkv8ooat+TKl6ulWmiJAlAs8KJ4yPKuGgzqJEtLygRUlJ5dK+hR409 /BFV1SaSvyxUmPdJ1/N/5K28ZO2nZKmviKHeMGUzsj9d/azYgGiKXT10D0mdAJ+mdo5F lx6uskzCkRJK218LAkPdSNxCy4DKJlTm1Rr+8k9JUOzrL2eUFXpTT7GTaEJ2jMz+dLn7 2uIfw2XknVdgXQbAs1KgLXpDVHmWC09nkITjsjxKuRy9/GebpQbx35Ch8Zjni+JN7D5S tJCA== X-Forwarded-Encrypted: i=1; AJvYcCV7iCv0foQEuxAelYImPAtemVtLTEX/et1nounfupb7qmoMwIkTmjBdwr8xmtFtM2sVgjtmUZJvyY0=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy2SVknMlBwKfeQKlJlXrueqNSyksNAXhI7xiMGkqVB9dBApyB6 S1B2QoaWF6hYJNJIGlPWACrY8rOQlMmqiZrPimPBETqO5d6FBGtmXiER2adtCuvkdw== X-Gm-Gg: AY/fxX4awH8l30fOf2eSOjIsKnEXi+Q5EpWmpM8MvD2w3UsU+gC96A+ZQLmoW9dPbZ0 5EIjsoqnNSSKCsvyp2ApeSuh2LKDj+au3NUx7xMlx4KLJkDg3wHfyJmzuLK+R8bzibUV4xw87uJ M7lTNUU4V3cVf5/ZYbsxjuC+QnVOMxjMkzt1tMlHAvzA0F7r8WZ+q0ByU1/wecc4zQXzW3P/Jw/ fPga5M8vHOAYkfvCzBoXvoUsU/9sYylPKE0QFO827B+i8tX1IFwGsRWth9v3MIzn0f98w4Phqs1 HqiKutdpaHlA3dMDHPHlbXcHIflMoYgRzH4Q94G75trcIvF/XXpcvsl6IY+AV50JczYQAWV4jtb IVvPX3i748M8steX/D7cWHENpaW/eb6i7zrZorLz426JHAcOsX2JlWfQ2omCYWDlnOSujwu8gw5 ipasz9XxlquZ8qxVD+zgwnyaGU2jPiDG9vTvvqgV3U2NIm8iNPQME8DQOpkwnIToCjK18j3qmED 7E= X-Google-Smtp-Source: AGHT+IGUo2vPpANa8MvOHNVaexN0DWaqjktBiRrCH/0RgqnAeXF3yW2qj2AxZgd8pqhgJGjzYSUYSQ== X-Received: by 2002:a05:600c:3114:b0:456:1a69:94fa with SMTP id 5b1f17b1804b1-47d84b2d27amr104801175e9.13.1767958323271; Fri, 09 Jan 2026 03:32:03 -0800 (PST) Message-ID: <1c4592d7-6f3e-4c47-8678-ae47249deab0@suse.com> Date: Fri, 9 Jan 2026 12:32:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/2] xen/mm: limit in-place scrubbing To: Andrew Cooper Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Anthony PERARD , xen-devel@lists.xenproject.org, Roger Pau Monne References: <20260108175536.82153-1-roger.pau@citrix.com> <6b4c352b-f4fd-4b81-84ac-41b7d3e04f92@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 09.01.2026 11:29, Andrew Cooper wrote: > On 09/01/2026 10:15 am, Jan Beulich wrote: >> On 08.01.2026 18:55, Roger Pau Monne wrote: >>> In XenServer we have seen the watchdog occasionally triggering during >>> domain creation if 1GB pages are scrubbed in-place during physmap >>> population. >> That's pretty extreme - writing to 1Gb of memory can't really take over 5s, >> can it? > > Sure it can. Under what unusual circumstances, or on what extremely slow hardware? (Of course improperly set MTRRs could cause such, for example.) >> Is there lock contention involved? > > Almost certainly, and it's probably the more relevant aspect in this case. Thing is - the scrubbing happens after alloc_heap_pages() has already dropped the heap lock. And I can't spot the XENMEM_populate_physmap path to take any locks outward from alloc_heap_pages(). And the domain's page alloc lock (which in principle should be uncontended anyway unless the toolstack tries to race with itself) is acquired only later. If it was a lock contention problem, the first goal ought to be to move the scrubbing outside of any (potentially contended) locks. >> Or is this when very many CPUs >> try to do the same in parallel? > > The scenario is reboot of a VM when Xapi is doing NUMA placement using > per-node claims. > > In this case, even with sufficient scrubbed RAM on other nodes, you need > to take from the node you claimed on which might need scrubbing. Much like if there was an exact-node request without involving claims. > The underlying problem is the need to do a long running operation in a > context where you cannot continue, and cannot (reasonably) fail. Right. Jan From xen-devel-bounces@lists.xenproject.org Fri Jan 09 11:34:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 11:34:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198595.1515484 (Exim 4.92) (envelope-from ) id 1veAky-0005J6-QX; Fri, 09 Jan 2026 11:34:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198595.1515484; Fri, 09 Jan 2026 11:34:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veAky-0005Iz-N4; Fri, 09 Jan 2026 11:34:16 +0000 Received: by outflank-mailman (input) for mailman id 1198595; Fri, 09 Jan 2026 11:34:15 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veAkx-0005Io-E3 for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 11:34:15 +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 1dafc9e5-ed4f-11f0-9ccf-f158ae23cfc8; Fri, 09 Jan 2026 12:34:11 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CO1PR03MB7937.namprd03.prod.outlook.com (2603:10b6:303:271::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.4; Fri, 9 Jan 2026 11:34:08 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.002; Fri, 9 Jan 2026 11:34: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: 1dafc9e5-ed4f-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=GnWr5zvdbQj6q+JBBELphB5gyyrDg0BZgbKWcB57j1ADGR0+X4cOlrInbGkCiRSOdJZvFI37SpFab9m8/dG97cp5xzgssx1W6HIEJvE4lkT8JhA+5+hzyiA6K8P94HY4wzfYIrSMZguPwLbKDxqj9PClc3/y1jVp1ydAsKkWqgSX0r0BJyCIBO0V7M86s3NZJRsYYNrnotTRdlA4SCve5y0Z4DdlrbTxpz8Rs6Zj7S5AShwLHiaaH96ALBtD1Elobq+KFdFXdjlzx0cAflop9J3fkPQwIVmx0cxVCOIO1KFBoaqJXU61rB7RMATHD2+Xu10bHOYwFaDIasKy6Tc0rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tYMZS1jSI7kWhIw2bjOJeE1P8/Xrc98hT2g4wcaNCMc=; b=YVVzKWIBi0VfH/sYPiHQN+YxmiBZjeGuDNy2oxroXDCn/SjxTmpuw48+Hr+OfuxXACagWvvL2euEu27Uq/K32+1sKDPqkOu2N+2A43nRGwTQklImiI0XAgbp20BKWJ+O857FHLMJljmFi8VkkhmZ5PVne0E+RrbOGEhTQynO112Ex5JObASEQsVcCqC9gKRCHc7aitaLl46CSHbu8nSeM+gi+w+dvAyRbX70oEkJ9vwWP0uNo9+3JAwoian+taucGaRZr1iXVEmt/ey/0oLCwlMNZnB+AWaNhaDYBcenzyUavCU7wQHAkx67jiWbnQwUC85nV+ihdbcolLj4cem3Tg== 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=tYMZS1jSI7kWhIw2bjOJeE1P8/Xrc98hT2g4wcaNCMc=; b=XaRL76Gm4lA8gcqADkCOyWmYUtMxY0l2IsVIxCY0k64Ba00yzE7fTnxUj7NWIUhrJBSDcOz6VBDRw3gkgNf58C5RVm7qM2LxoTY5DDUwm0lXKYK6JtEq2BgkW7ozVWwJ9ozCxEZaQi4zm5soINJplxmbl20jFTbVJEaF4HwYW1Y= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Fri, 9 Jan 2026 11:34:03 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Anthony PERARD , xen-devel@lists.xenproject.org, Roger Pau Monne Subject: Re: [PATCH 0/2] xen/mm: limit in-place scrubbing To: Jan Beulich References: <20260108175536.82153-1-roger.pau@citrix.com> <6b4c352b-f4fd-4b81-84ac-41b7d3e04f92@suse.com> <1c4592d7-6f3e-4c47-8678-ae47249deab0@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <1c4592d7-6f3e-4c47-8678-ae47249deab0@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P302CA0014.GBRP302.PROD.OUTLOOK.COM (2603:10a6:600:2c2::15) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CO1PR03MB7937:EE_ X-MS-Office365-Filtering-Correlation-Id: cb049e2a-8269-4781-03de-08de4f73000f 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?b2hEakJKaVltdDBGeWJDSnM1Nld5aTlCUlFLYjRCZDNOUkRZenBiRnhPS0FO?= =?utf-8?B?VUlNYWN2TGc1RUcwYlJrRXJkalBjTUhhb0txajc0YzVKd1NDeVVWTmhxNGw3?= =?utf-8?B?WHhSaU8wNjZhc3FwbjVpVzVQckZPcUREck5CemhpbEd3SE8xR2F2ckV0UDZE?= =?utf-8?B?Q0FoR3hCektxSzgwU1kyODhZVmxtK2VPTWdEYXdnU29mQjByeXI1WGtCWXpy?= =?utf-8?B?V3lZQ09yWUxNcVlKdHVoZWU1ZG9HVFI2NXpVWThQVGMvU0ZiU0o2Z200SFNu?= =?utf-8?B?OGtkUnVMSXBKNU5zL0FFcnd3aGRPWXh3Tm8wOHM4U3hyZlUvdWtiRmJ2S2t6?= =?utf-8?B?Q0Q0c3AzVmNjMTY3RWc1M2xCb0hTT25SZHJLK01HRlo3dzg4cmM4ZVhMNmZl?= =?utf-8?B?MEVKR2xFMFRRRVd2S2RLK1h5WEJDbldiZGNObUJ1ekJPNUIxcEpoVStKZXJP?= =?utf-8?B?SzF4Q2E3ZG94MjlDSE9JNWU3NzJ6Vi92dER3dFJFTUtVS2srdXgwdU4zT1RI?= =?utf-8?B?aVUzU3FURnZwQ2I1WVVBTmk2eEI4YXlTdDExQXd3eFY4ZjN1T1VGS3hveGZi?= =?utf-8?B?b1FyRmdlbWpRUldMQ2V3RTJCSTI0eUM1STlIa212MUhGbWtBeHczeDRTMCtR?= =?utf-8?B?bU9CZHIxM0c2MHBPbXpaNDhDSHFyQnBjbjcrVklBTEVXWTBSd1BhTnprUXNs?= =?utf-8?B?dUJMQ3hTRXJDTzNxNEh2cVlwQkVFdWx3em9aakFwc2NSU1NiVjNxWSttdXFV?= =?utf-8?B?TzJ1aXVtTnhvSUZXZ1Vscis4Z2dvZ2JjNWlDaTQyVVc1TEQwZmhzN1p4RGUw?= =?utf-8?B?b0c3cFJlWVY0VU9Nd2pKVGU5Rk9aM2dmUkp5ZlRWRjQ3Szh4NVJRdnJUNDRj?= =?utf-8?B?SGZRL3MxTGJVWGcvUFE3SmNZUXhFWUZNNWwza1BFaHVMbjNNSVFZcGoxWDZF?= =?utf-8?B?R2JjVXgzZ0kzd2JtS1VpQmt2UHd1QXBNYkpEaU5vcURWTm1sY29RTzcxckc2?= =?utf-8?B?MHZrclVnZ1NtSEhGaEd3ZkhLL1FiNFUrMXRiUzJ3NjljL0Q1NkZHaDl6T0FJ?= =?utf-8?B?eFNRS0o0eDNMMXlKNjZKcW5nZzU1eVFwQTJNSklXNVhqWktpZ2NHMTE3WVo1?= =?utf-8?B?OGRNK2FTRHY4eDZPZmU5ZVdoc2R1aHJncFZ5aWZCRXRiOXV2YTdJa1NxTkUw?= =?utf-8?B?cjJnbjdVT0VzR0pmUEdvaU9TT3I5N3Y4aVRQSnpXbXpEM3E5Z3QxcjdMMEVE?= =?utf-8?B?SWVTUTBhWEl5TW9GTE5yTlhiby8vQ1RlQVZMSFQ2RmFwRmxsanZkQUVCSFFt?= =?utf-8?B?VHB5N1FOZmNLWm1Yd3BqelBJRU5LWk43a2lHeFlkSTNxK0JYU3BYQnl1b2RX?= =?utf-8?B?cXA1TkpaWVZWcHRIK243WnJCZmc5ZnkzZU94SS90MW9DWHR1Y3h3Z0dGSXQv?= =?utf-8?B?QUg0VExKSG1tWkd3cEhEZjB6VHJYY2VLaXN6VDhJM2toTWlhZ3pXMmt5QkdJ?= =?utf-8?B?VlRkVEpxajFmbjZjaE10b2VEWkMzNERzOGxxVnl0RXR4SzZBNVZ5N3pVUzNM?= =?utf-8?B?UzhWdko3MWoxdVZOTHpOY1ZQWTVvWlNZOXQ5Wkx3Rmt6SXBnelBqTCtleUhN?= =?utf-8?B?SklqdUExUG9SMVZ2dFVURVh2dlRjOGtHY05MbFp1M1hOZ1NLb3FabWp4VlJ0?= =?utf-8?B?NEJUZUtEQWhqQWJuSUVubVZPYURkYlFmejYxUjQ3ZFhYN0ZGSitQc1ZMdmRi?= =?utf-8?B?WjdEaXJ3a2RQVGtQQVlKL2FLeGZnNUkvU1NQb1B3RjJ3eHVVbUpzaCtXL3Zw?= =?utf-8?B?aTdEdVJyQU1ad2EvK0FkeEFRSVg5aXNMdjJCYUl3V1JyT3BFNnliU0dIeXI0?= =?utf-8?B?WmlSRW5Eb1BEWkJCZG5PNUxkUVFhditySW1WVlZ6MExlMnJDNFFJQTU5WTdI?= =?utf-8?Q?xrlMXB+rNumpA/sK0b1dp+41yCfEFyb/?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OW8waXVwUWpGaXpSaVBlbEJSUnY3bTY4YjJZMVVDbXNoRExscEY2Q0FQNDFp?= =?utf-8?B?UEhMM3NVK1k3d2RqYUgzblNpNTBDVEV2cEZXZXVIVERQOVVDci8rbWJnUVU1?= =?utf-8?B?SE5ad1dBQjZyK1FPeUF0TndhcVVpaTRhb0k0eG5sWFkxVDB4bDB4WFI2ZXRE?= =?utf-8?B?dC9SUWR4bWVqY20zYmZFdUpnc0NQN2VPc0ozL2ZvZngza0hDSFBLenhlK1lW?= =?utf-8?B?WVlYN1RUYmlORHN4eWkvY1JVa09GUk5JNXNoeHBmV1NxSXNmZ2ZZTzdvcHhI?= =?utf-8?B?aWlObXRuQ2hmdTJ5bHFnMUlvNWtoQ3h1dmdlcjJ6Q0tVaVZ0MlA2KzY1dFhp?= =?utf-8?B?ek41NUY3ZktSbDdETE5HOENSd0czMExLZ3BSSEFZNHo1S3dISnlIVXd5aGRO?= =?utf-8?B?SnVWbHRpM0VrYStid0kvVG9zdlhKUTV2QmdETytrU1VsT3JmN1pweVA1ditJ?= =?utf-8?B?NTJ0MU42ZkxEMDZGR21FUlVkUjk2R0NnaGJVYlVqQm80WEpjdDV4VFhMVWtJ?= =?utf-8?B?aVJtUVJBdHdmMzhTWDNzVnZHd3lzdHd6OUhyaitPT0ZndGw1SlZQWUtUd0Vk?= =?utf-8?B?eUhZSy96NE91TXFlTk5tZWZyWE9qRVBwdTFZN29Vd1d4ZnBJYVNIemdHbnpp?= =?utf-8?B?MWVOb1VTKzB4dXBiODVkSmJpMUo3dUt1ejdoL2ZuNmZVVkJ3QlY0M3pjMGp1?= =?utf-8?B?OElGMjR3ZXdTZi9JOE1NeFU4K01JUW5aRDJKNWcwQVBMSkxsRFJpVzRoKzdw?= =?utf-8?B?ejdkNS9Rdml0Vk40Uno2Z2tDd2ZvUEZVQWZOMHUrcHh2L0JtRXA2cC9xRFVn?= =?utf-8?B?VG5RMHBCY0VpTzVpMDNhUW9UM0FoQ0IxWElhNndRM256TWI2QmNXVXlRYys2?= =?utf-8?B?R2FmWGJjZFdPMXJiZXl0T1lWQXdtZnoxc0E0MWVGaFVCUjlzNElEcWRFOUkr?= =?utf-8?B?bnBZNlFZQUxzdkxLYTNmSVA3VnYzU3pHK2N0Qm9PT0N6WFk0WEtlUTNMcmRB?= =?utf-8?B?a1k1TExuSkM4cEswc0dUTnlRVjdGSUpmeUFaazUwOXJlN2Z1Qno0RlJNQXpS?= =?utf-8?B?ajUvY1RzNXA1RWRMSlQ5NVJ5aG8zSnBCRlJYWVZCbjRkUmI4NHVueGRhSCs0?= =?utf-8?B?aVptYzdDWlpkQSt5U2dUQ1dmaXRCUjdhVlhZYjl0bG4yRGVxQUQ1eGpuYSs3?= =?utf-8?B?UmdmNHBObDBuYnhoS2xicTdNdHRvSHRoY1Z5dGNHVG0xaEpkNGZYNWl4RVQv?= =?utf-8?B?UkF4Zyt6THVzZU5yZStQQ3JnRkhmYnVXQXNRZ3UwUXhLRk9CSi92d2Z5VGdQ?= =?utf-8?B?MDJrZkw2MnZLRkJFSnlGdmhpOU5hd0Q1c2FXbGs2UnpPaWlrVkZsZGkrNXI5?= =?utf-8?B?b1VhL2RzZEQ0OWxmSXpmNlNpbmk3UTJVY1k1VFdmeDdDeDF2Wno1VDQwbEZz?= =?utf-8?B?TkZIMHpPZjMrZ2R2YjJGcmcxY1JyOXZYWEFoM2dVMG5iZGRPaWtKM1A1WUlp?= =?utf-8?B?MkZUMEZjOUpXRnhGTXRPU2p4dXNEaEpCb1ZEL09kdG5oMlZPS2NmcW9QSDJZ?= =?utf-8?B?dWVESHlFVVdwNE9EY3dveGZaSndjY3gvNlEwcFc3d1pyZk9rcUVaMmcwMFl6?= =?utf-8?B?eFMzdExVZ0NELzJiN1loVkRqV1ZJczBWVUZTYU5DdkVOR1h0SkdNenhTMUVl?= =?utf-8?B?cHRUK0pva0hYMHJXODBLa05MaEo4V0U2dFl6aWtSL3YzSFVFdkVjTmFNNDFx?= =?utf-8?B?VTRUelZ1RHpSM0VzYkFuek43YVFON3czZW9TREhBUkZSd1ZpRXQydUFsbFZQ?= =?utf-8?B?QmhiNWIvLytzdkhvL3lvc1J4QncwemdvNXZsSHVjNjFQcmdNdjIwU0RneDhK?= =?utf-8?B?cHhYMVR5NWtXc2o5M3BpM24ybG1EWVFFMXdhS0dmOTcreTVDTjI2Z2dkUTlt?= =?utf-8?B?ZUR1bWVUQ0pYdVZmeTFKSEtuRXYzWXRyT2t6TFQ2WTZOLzBCTXVKd0hYSlU4?= =?utf-8?B?VEREbEVPWWFONFNHcU15cmd0ckpPY1ovemFOT1Nqa0Vic3d0RkhOMDFqRGx4?= =?utf-8?B?bHdmU3VLQnU4UVV0cUhaNGk2b280R3RUV0tBbWgrQkhEZXYzeTQ5a3dJNDND?= =?utf-8?B?N2xGTEh1U292U0lxc0NpWm5rejQ1UzdDY3g3dmFtSHNNamo4WkRncXFsc2Fi?= =?utf-8?B?dk9ROFMvb0MzdzNVVU9FV0NVVjFNRiszWnlRQXpjakIwMGZ6NTlwei8veXNm?= =?utf-8?B?b1NGVjVtMTYzQVk1blZSMHJkbURmU0tleGZTNmFRK2VkSDR5ZHBSNG81NEhv?= =?utf-8?B?WXVTZTdLQTVJVWpQT1Q2SmZmS0dnNnRhd0Y5L1E3RFdIWklQK0FiOGxvUEpP?= =?utf-8?Q?8Rauqd8Ye7UEFJ2s=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: cb049e2a-8269-4781-03de-08de4f73000f X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2026 11:34:07.5522 (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: TOptvuum4rCjqCd5FWsa5t4UbPESeS4cNj7/WwCbYWO8M/yUvYzAgXrJZxaCpEECVgUGgmZeBuik9Hrn8eLd5v2+WnES+pDoh0PkMJo4k3A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7937 On 09/01/2026 11:32 am, Jan Beulich wrote: >>> Or is this when very many CPUs >>> try to do the same in parallel? >> The scenario is reboot of a VM when Xapi is doing NUMA placement using >> per-node claims. >> >> In this case, even with sufficient scrubbed RAM on other nodes, you need >> to take from the node you claimed on which might need scrubbing. > Much like if there was an exact-node request without involving claims. > >> The underlying problem is the need to do a long running operation in a >> context where you cannot continue, and cannot (reasonably) fail. > Right. Yeah - I think this is a scenario that could happen without NUMA aspects, if the system is almost full.  I suspect we've just made it easier to hit, or we've got better testing.  Hard to say. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jan 09 11:37:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 11:37:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198615.1515493 (Exim 4.92) (envelope-from ) id 1veAoF-00064v-Ck; Fri, 09 Jan 2026 11:37:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198615.1515493; Fri, 09 Jan 2026 11:37:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veAoF-00064o-9k; Fri, 09 Jan 2026 11:37:39 +0000 Received: by outflank-mailman (input) for mailman id 1198615; Fri, 09 Jan 2026 11: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 1veAoE-0005xQ-IN for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 11:37:38 +0000 Received: from SA9PR02CU001.outbound.protection.outlook.com (mail-southcentralusazlp170130001.outbound.protection.outlook.com [2a01:111:f403:c10c::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9893b892-ed4f-11f0-b15e-2bf370ae4941; Fri, 09 Jan 2026 12:37:37 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by CO1PR03MB5761.namprd03.prod.outlook.com (2603:10b6:303:91::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Fri, 9 Jan 2026 11:37:34 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.003; Fri, 9 Jan 2026 11:37: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: 9893b892-ed4f-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kDgyLPKCveTuU0QiLFLGKgqMkZnpebNyCXXoHHYDquneRNLpakf1yh8jDPbQdg4OuVQAvbo2BpwF9QlUaSS7W+nibbUrHt9JFVCjO6HK3HdnWh4toSNeD9ixsscKyI91aQjdpmT0jYOl7GSOXFocDOyBW2KnuDtkOfw5zHDN5hUqj4P6XBZeMA0Ao2TJq3rPGUGtPC7jDYLZglk6uCZg2Ao77if5Ks5QinbYp2IM9LUb7lCCglSpn1i6HW0WOuAR2bdr05uT4wm/+AVunYjjqu734T7GCq0qpp3IF/xVCmdGs/GR6TI0sVtvNyFOQjKFclHuUSqj/oyn13ZsYCGBiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yM93/XYrl9lbCk3W4MwM71pBxzanupWWO9VvDhzXhys=; b=jngmlC9FcTfoR4N+LTUAkZHKAkJxD/3VTrLNuGfY3iPoZq+VGKvLpkBgsPdDW3E9akTQ2yLtV5MnCsTyF38h+TcskJEmZi6Dsy4RYcY3fWA/Ehkut0nI/Zy0hoOqVSrMd/0pJW+spi0b3bXdC3F6IHoHjIkwVrnSNUTd+HJKVzI0/DII5EYiRjV8aAytA86Ck/1/guOCK+eUNrnWtll9AQiNOni0QFMJNzTAl0kv8ozAzzYkCQ/xTFgXsiXMwtxgRIu3P69qWTN+2SW10GFd7HP1ygaieo+70qG7SmfHYH1nkrVEi1qoPwIHtLbAizyLW6FebyXjU0jpGs/NH4r8aQ== 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=yM93/XYrl9lbCk3W4MwM71pBxzanupWWO9VvDhzXhys=; b=bGF8zxckw0gUW5AH/1bf6qUT170FmWpfGB3IkgIWW06X97MqinzNxEVksE47bLlDzf1yAKStt/I0Z7B2n2f6FuA2mMsKUnoVnmwrNkMUVygmlIxNcZOa7pjCtEKtTn7aQv5RAt6CUAUfT9xzXZNtYgASl7dWWrSb0BJmd1Ba5Hk= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Fri, 9 Jan 2026 12:37:30 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Teddy Astie Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: Re: [RFC PATCH] pvh: Introduce SIF_HVM_GHCB for SEV-ES/SNP guests Message-ID: References: <3b6f5146287d3402a09836b7cf876d4f8dc9eee1.1766889890.git.teddy.astie@vates.tech> <0c9c1dbb-28e1-479b-a680-e99150b3f0da@vates.tech> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: PA7P264CA0149.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:377::13) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|CO1PR03MB5761:EE_ X-MS-Office365-Filtering-Correlation-Id: 217b96f9-b66e-4725-7e4b-08de4f737b14 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?T1hOMVp6UVNaNmh0QXZ4UlIxQ2J6ckZSUUptcjVxMVRndDBLOENhUnJtOUU5?= =?utf-8?B?VGM3OGdydXBMOHREYklDWkpjaHN0ZkgrZ0o3NUFRNktTSFhWa3h1cm1nQ1A4?= =?utf-8?B?Y3RtKzV1eXBwQ1pCTlkvMEJNaUJmajZqbHoxcUZRSnQ1UzVSOG50cWg0TCtF?= =?utf-8?B?dVpGcTVkc3hKd3F6MmhxSVIzSUg3M0t0dFBEL1JDMUF2V3k1VXhGc3FDMWlV?= =?utf-8?B?NEllMGJOR0pIQnpRTUxqOVFSV1lIYkhYTmRid2ROT1FXQ0JtSHdMaVJSVHQv?= =?utf-8?B?TXc0cVR5d2pkc2wvV251OUpGQ0VXOUJvK2sxMWJ1Ri9aakxteEMxVy9iOS9W?= =?utf-8?B?UldHbkN1MG1OcE5pYzd6ZkgvektobVhsb0FDeWZDMThYeWJuK3ZRWWY1L3Vo?= =?utf-8?B?NjBLeVlPUW1ZaEQ3Ny94akdjVXBkeGRwVktURTc1eXVxVStyc09OdHY5Y01U?= =?utf-8?B?N0xVRDA1b2RwZWRLTkJRblBqSy93ZkF2TG04VGhwNTlHRWJNRHkvQXNnVzZj?= =?utf-8?B?UWtkOVc2NkVVdG1IeGFqbGltWTFkcDdtMGVrQml6R3hXTWpjWG9UTUcyaGRG?= =?utf-8?B?aW10SUpZc0VTcXNmc0RKeDA3ejhSYXcxanhoeTE0RHppOFhMTTRIbzFLQnVO?= =?utf-8?B?WFgwWWNFb3pZd1FqSkd5TUxSYzdKdjRMZ28yenM3MUppTkV1Q1g1Mk02bllU?= =?utf-8?B?SzFocUJPdk9mQlBwNzBDN05XYzJyUzM5STIvLzNJY0ozQit4azN6b3pzRUsr?= =?utf-8?B?aER2ay92dlJiVjc0end0Y055MExNcmRqMXRjOWw4dlhWMlRNY0N0dzFibEFJ?= =?utf-8?B?NVdaM0JkeGtmYWQzdlgyUkJRM3MwRk50QVNwdERYNCtiWWU0dkNRWjJTb3gw?= =?utf-8?B?RlBOMG5uL2R0dkRFM1NRamkrK3lDOVdtOGF3RXMvbHdVS1RtOEFQNlBkYzZJ?= =?utf-8?B?RjR5YjdRZE1IQ0ZFZ1cycjAvdU9tUEw1TTFOaFFnVFZSbHBCTVhON0M4WWVu?= =?utf-8?B?dGh3eVE1dFdUK3hBSFg0R3NQenZoWktvUHRsMDV0UkVHMW1KRERnZlFHeEh2?= =?utf-8?B?bHdlRkhnTEFhSUR0eTI4Vk5DUVlmQStoNXgyUFV5Z2pyMjVTVFJyZkc5OGR5?= =?utf-8?B?YW5CdmQzdXBNMy9BWVUzbjVvVTM0WU9QN2lHSVRTUHMrRHczbkxEZWhxbjZX?= =?utf-8?B?clZQbWpkQmZFZm9DMkFxRGhLd3BacUFKSGI4clZudjVSeGNDS3JSQ3hkWXNr?= =?utf-8?B?ajZUOGhHaiszMW9ZaGJzeFdoTllralZHQi9Lek1WcEcvYWVkcWtNYkdEMWtt?= =?utf-8?B?aFAyZ1NDUVpoeHBmT1VIVVRXNlVSYmFpdEtuNTVwb3NjdjhQWFdFVGhkSlYr?= =?utf-8?B?cGYzSDExWGJFUWFUL0xCWFVuQmZ3M043YStweUw1bmt5OUpPMWQvMmYwTDhv?= =?utf-8?B?cm4ydHZ3dFhCUy9HQnkzVHFTL3BkaFhJV0tORmlTUXc0N1hxeDliR3ZIRm5r?= =?utf-8?B?a3ZrNlp0eGw0eEUxalI0Z1VlRTlraGlEYWUzRkphWjJQZys1R0NjWTlVS1p6?= =?utf-8?B?OUJSTCsxOEhwSThmZVA2c1NyTzZjN0ZmaUhQcklNdUJJQjZYSnVzbnhHdyts?= =?utf-8?B?R2ExQ2ZPWFA3QmpTM0RLU1owUWxqd1c3WUUwMGNZbkRCZFZVZ1AxSlg4ZmJo?= =?utf-8?B?bitzRkxpVUdyZzhDV2pKbk54THM3VHlxcmhXdjZIWFJMSUtRNEJCL1Evc0dq?= =?utf-8?B?d2NjYkpqbXBYbHM1bGlaTkp6djh4djRYSWhiR1JQUnpMZnRlNFpxVjcwd3Bn?= =?utf-8?B?Ti9KMitVbnRLOHN6NXlTbEc1Q1dwQmtVNi85N01pNytnQW85TFBYU1l5ZVpu?= =?utf-8?B?eHJSc05FSllFRTlLOGdVd1JSNVFyVGtOTE0xamR4UzhIbTBWYURkNEM3YUdX?= =?utf-8?Q?DPOel3QkIbkPt47XsXqoI7ga6lR3x4Fg?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?V21NOEJqeFY5MkZSeGovR1B0RHBjdXlWU0hXTGh1UWF0TWd5Z1RZOWRtV2d4?= =?utf-8?B?cUtwM25WbjFaTFZaYjUrTS9jRG5Fbmc2SjdLd0I1RklDZnlXdTAxY2Zlalli?= =?utf-8?B?ajZPY21xUkt2aFloajUwTVJOV05wSnIwcEM4QTkvU3NycHFUV1ROWWRvWlJs?= =?utf-8?B?THVlejE1UThxb2JrdE1xWEE3NlhrOVk2UkNnakhhWjB3bjdaS0p3VERiTXpz?= =?utf-8?B?cDB2MlZzNGs4c1YyZXptSzFkSFRUSDBhY0ZrUzJqWFdtWmRSUmZRZ0pMcUlt?= =?utf-8?B?ekFRMGVrdXY0OEJWZkJOM0pXK0Fldk1FN0tCZW9SQUk2T0gwQ2Z5RUU0SWV1?= =?utf-8?B?M3JGWjJFcHlvMTJCWU9zck45N2oyOExnV1I1a24xRDc2T3hvQTUxVENneGN6?= =?utf-8?B?azVGMHlsLzM3UEx2RklhWTJUdlNzck1ORzVkTGh4d1QrRjZQd1prcFYwYTNL?= =?utf-8?B?bE5kek1aMnpWZE9CYTB0UllvY3RsTmQ3QitYYnRIZy8yRE1yV0c0UDZRSXlp?= =?utf-8?B?VE5UZHhiWjEwTC9NT1J0YzUrUzFUbEcxQXdlUzgwaXZGNmFWNGV5OGZBVlc4?= =?utf-8?B?eUNNVzNXSGdVeWc5VlpDcWZCTHgxc2RSeldZWDIvSmRvMkU2dHdzNGEwYng0?= =?utf-8?B?K1VrRjZKcUZSbHlpZU9tK1ZnQUxPeUhpWU5idnZwa1pDZzhnN1VVR2FWU3RN?= =?utf-8?B?cXR2d0lEWTVZa201NDYxd3o4bEVieHhkd3AyWXhhTVVBQnlCaDMvSTVtMHQ5?= =?utf-8?B?SXZkblVJQU13Vnk1Y3RSN3lXMDdaandJaEd5RG9PQk50cHp4VkJjWjZ4NE9y?= =?utf-8?B?bG1xMTB0bktLVzVsNVVjZlhqOUVMbHJsRDlmV0wvYXQ2eFBjZ01UMmlmY0xD?= =?utf-8?B?dG5LTXFaSTlVSmViazQ2Q0VGVmhHRzlQeU1mSDVHeG51bjVBTll2VFg5Tzhp?= =?utf-8?B?YzFQN2M5ZDBPeWsxT01JR2VNamlUZ21HZHBxOTBlWEZYMkVSUkIvZTVsVXBQ?= =?utf-8?B?MFl5NTFiSzVWbXpXOFI3MDFoZ042eXNqNnlONmg0SVVXeEN1K1U3M1NZV1hP?= =?utf-8?B?bmVpRWRjSFp3RHlQY2hreTlIcEFKK3cxQVVIN0xzL2c5anpBc0pNcEhsREZY?= =?utf-8?B?Mm5ITXZRTE9vWk9zWEVSWXFRWG9DU1kwc2QyMS84TDh2ZitmTmFOeHQya2pO?= =?utf-8?B?KzdXekdoN20ydDlseGZTMzlnRytQamFpZVU0Q0FaSW1ZTmY0SGxHQk82Yldq?= =?utf-8?B?VUdBM2xaTmVSSHlBRTByeE02QjB5SUQ2ZFpCekI0NjZBKzhLUWVUZEtsWjNX?= =?utf-8?B?ZElHbDZNSVg0NmlaUk9xejR4Zk5scXd4RFM3N0xsMXB0RndiS2VZV24zZ2VZ?= =?utf-8?B?bTVvK0VhT2xIS2MzWHdtSWovMU54aVNjZHFFSjRnankveDN2dlhUbnZQNmg5?= =?utf-8?B?Wk5POHNuejBGc29HTzhPRUdoTVpGbUNYN3Q2Ymh4azExbVplckYwektSZkcz?= =?utf-8?B?eGlsMnBVM2orMzQ4c2JQSTYxR28wR3FRc1A3MzhndnRZU2tmc2k4cVl4NTA4?= =?utf-8?B?TFJWRDZwUGRnSnZaSGY3aTl2UnlMSXM2K2xMdDJjNWtpbkRock9ZQTA1Mk53?= =?utf-8?B?VkF6eVBRTUJSVkZuT3BsaXZmQzZUUlI5MWR6c09ZQmdLNkJad2JoRlA4MnFO?= =?utf-8?B?VzQyV1JVK1drbjNvRmMwbWsraGRTd2pqNTRRNWdjWGRob0J5V3dkRGR0dnlK?= =?utf-8?B?RHU5cmczLzY0QWhxSEp4d09EVG1rdE56SmVwUFJKWUxLMG5OZGMyMFNINUxM?= =?utf-8?B?Yml1dS8za0dNbEVBRytBdVZKUDlTMk1KRGNaamk2WVorc2tUM0FHUksrV3oy?= =?utf-8?B?Y1o0N3F4Zm55aGVJRFZiVVZqQXgxaElpL0RGNlYvM3BUMmlyYm1taklWQzdS?= =?utf-8?B?R2gwdGxwTXFlZ2Q2dlA5Q0Z4YmlpZ2UvSTdNQTFyVnhtZkJ3WU1EYjd3bnhy?= =?utf-8?B?U1plSG41cTRNRmlpU1ppSk9WRVEzb3ZwRUFCMTlHUUVqMnNvYmtrdWZPQjAw?= =?utf-8?B?eVJTUUJFNVVHbUh3NHFvNTB4VUk4NGhEMHRwSENHS1pkNktJY0JSZEJabTFu?= =?utf-8?B?YUFSMXhnUlNnTHFMcDl0clBmMjJtekdnNWo2R1BLeE5LN2o4M0NSS0dFeTNP?= =?utf-8?B?UzNtQkdIZU82VXZORW5DSmxOSzc2clRLRnRnWjZUMDVKMTBxQ3lTMzczN0xa?= =?utf-8?B?aUd2Zmhqa3dIMWlLbjRzMmtOaTczZDk5cXI4R1RET1psRXhzV1Flb1RhT3dk?= =?utf-8?B?b05GVkdlNWFjMkhwL0dyWG1hRFRQYzM4eGZFUjZVSXYyVmx0VGxVZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 217b96f9-b66e-4725-7e4b-08de4f737b14 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2026 11:37:34.0042 (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: 1hCoBVKThvZoLLGdLxrizqnUJSHbHFLaOR2hTwLBb5VhQ33bll7ftsFtJxwEGGzB++zGJ7Ahv44MTM98UByPpg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB5761 On Fri, Jan 09, 2026 at 10:31:57AM +0000, Teddy Astie wrote: > Le 09/01/2026 à 09:59, Roger Pau Monné a écrit : > > On Thu, Jan 08, 2026 at 07:12:48PM +0000, Teddy Astie wrote: > >> Le 08/01/2026 à 18:46, Roger Pau Monné a écrit : > >>> On Thu, Jan 08, 2026 at 04:50:51PM +0000, Teddy Astie wrote: > >>>> Le 28/12/2025 à 13:54, Teddy Astie a écrit : > >>>>> Under SEV, the pagetables needs to be post-processed to add the C-bit > >>>>> (to make the mapping encrypted). The guest is expected to query the C-bit > >>>>> through CPUID. However, under SEV-ES and SEV-SNP modes, this instruction > >>>>> now triggers #VC instead. The guest would need to setup a IDT very early > >>>>> and instead use the early-GHCB protocol to emulate CPUID, which is > >>>>> complicated. > >>> > >>> Possibly a stupid question, but how is this information expected to > >>> be propagated to the guest when there's a guest firmware and > >>> bootloader in use? > >>> > >>> How is OVMF and/or grub propagating this information between > >>> themselves and to Linux? > >>> > >> > >> When booting Linux with SEV+UEFI, at least during the UEFI services, the > >> UEFI firmware transparently handles #VC for the rest to allow it to > >> perform CPUID operation. > >> (with SEV-SNP CPUID page exposed with a specific UEFI mecanism) > > > > Hm, that's going to be cumbersome when using hvmloader in this > > scenario, as it makes extensive use of CPUID and hence would need to > > setup it's own #VC handler ahead of making use of CPUID. > > > > Or we must instead get rid of hvmloader. > > > > For plain SEV, hvmloader would need to run with paging (PAE or 4-level) > to properly handle encryption bit. But would also need Xen to handle > MMIO instructions (which has some quirks due to being in encrypted memory). Does hvmloader really need encryption though? What sensitive data does hvmloader deal with that would require encryption. > For SEV-ES, #VC handler + GHCB is not only required for CPUID, but also > for VMMCALL, MMIO, some MSR accesses, ... > > It would be easier to not use hvmloader, especially since only UEFI > supports SEV and guests would still need to support (Xen-specific) SEV > bits to begin with. I would be very happy to relegate hvmloader to be used with SeaBIOS only, and to load OVMF directly for HVM guests. But I don't know what's missing for OVMF to be capable of that. I would think not much, since it's already almost working for PVH guests AFAIK. Maybe PCI enumeration, but OVMF must have a way of doing that already for other platforms I expect. > >> So overall, this proposal is only meaningful for PVH booting, everything > >> that comes after can be handled differently. > >> > >>> Are they relying on the CPUID discovery logic mentioned above, or > >>> there's some shadow infra used by KVM for example to already convey > >>> it? > >>> > >> > >> OVMF at its startup relies on #VC for emulating CPUID. > >> It then relies on GHCB MSR for getting SEV info/C-bit (but only with > >> SEV-ES). And under SEV-SNP, it uses "CPUID page" instead of GHCB > >> (PAGE_TYPE_CPUID in SEV-SNP firmware ABI specification). > >> > >> This is because SEV/GHCB specification recommends using CPUID page under > >> SEV-SNP (even though the same protocol as SEV-ES still works; but is > >> discouraged). > > > > In a previous reply to Jan you mention that Linux already has such > > handlers, but just for the decompressing code (and hence not reachable > > from the PVH entry point, that's already decompressed code). Would it > > be possible to share the handlers with the PVH entry point? > > > > Maybe, Linux already does this for few parts of SEV code (e.g > arch/x86/coco/sev/vc-shared.c being also included in > arch/x86/boot/compressed/sev-handle-vc.c). > > Everything we would need appears to be contained in > arch/x86/boot/compressed/mem_encrypt.S. I don't know that much about Linux whether it would be easy for the PVH entry point to re-use that code. > >> In GHCB Version 2 (SEV-SNP) > >>> The hypervisor may supply the encryption bit position using the SEV Information MSR protocol, > >>> but the guest should use the CPUID information supplied in the CPUID Page to determine the > >>> encryption bit position. > >> > >> But its location is unfortunately undefined in this specification and in > >> the OVMF case, hardcoded in firmware metadata. > >> > >>> Adding Xen side-channels when there's an architectural defined way to > >>> obtain the information is a duplication of interfaces, and could lead > >>> to issues in the long run. We can not possibly be adding all vendor > >>> SEV options to SIF_ flags just because they are cumbersome to fetch. > >>> I know this is just one right now, but we don't know whether more of > >>> those CPUID options would be needed at the start of day in the future. > >>> > >> > >> That exists for SEV-ES and SEV-SNP (even though complicated) but for > >> SEV-SNP, it would relies on discouraged mecanisms (GHCB CPUID Request). > >> > >> AFAIU, this flag is enough for setting up long mode and GHCB which is > >> what matters. There are some additional structures (e.g secret page and > >> CPUID page) which could in the future be eventually exposed as PVH > >> modules; which would be hopefully less intrusive. > > > > If my understating is correct, this is not needed for the initial > > implementation of SEV (when hypervisor doesn't implement ES or SNP > > guests can use CPUID), and hence it might be best to wait for the > > basic SEV implementation to be in the hypervisor before jumping into > > ES or SNP details? > > > > Correct; CPUID is handled normally when not running with SEV-ES/SNP. > > > AFAICT (from your Linux entry point patch) you end up needing both the > > CPUID and the GHCB ways of detecting SEV support, so one doesn't > > preclude the other. > > > > Both are needed if we want to support both SEV-ES and no-ES cases; but > if only SEV-ES+ is wanted, the CPUID path would never be taken with this > approach. Since in Xen we do want to support plain SEV (without ES extensions), I would focus initially on the CPUID path, because it would be needed anyway. Get that working on both Xen and Linux, and then discuss about any ES/SNP ABI additions. It seems premature to do ABI changes to accommodate ES/SNP support when not even plain SEV is supported. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Jan 09 11:43:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 11:43:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198626.1515504 (Exim 4.92) (envelope-from ) id 1veAtz-0007gl-Vi; Fri, 09 Jan 2026 11:43:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198626.1515504; Fri, 09 Jan 2026 11:43:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veAtz-0007ge-So; Fri, 09 Jan 2026 11:43:35 +0000 Received: by outflank-mailman (input) for mailman id 1198626; Fri, 09 Jan 2026 11:43:34 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veAty-0007gF-Q1 for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 11:43:34 +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 6be6156a-ed50-11f0-9ccf-f158ae23cfc8; Fri, 09 Jan 2026 12:43:32 +0100 (CET) Received: from DS1PR03MB7992.namprd03.prod.outlook.com (2603:10b6:8:21b::11) by CH8PR03MB8203.namprd03.prod.outlook.com (2603:10b6:610:2c3::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Fri, 9 Jan 2026 11:43:29 +0000 Received: from DS1PR03MB7992.namprd03.prod.outlook.com ([fe80::9bcf:b438:9af9:9ba]) by DS1PR03MB7992.namprd03.prod.outlook.com ([fe80::9bcf:b438:9af9:9ba%6]) with mapi id 15.20.9499.003; Fri, 9 Jan 2026 11:43: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: 6be6156a-ed50-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=c5ecxi5Qg/5K1fybrloba/RN1gcIfHPrODDRA9TUYtLWIcsfnixDs/arvDIRQid6fH/glZwqVGFRGxnv4/EB3YA4tWo8jM4L0HvY9WOp7pMQhhbsX+QC1AcoWkJC0wtVVFacwLCD2OSd2O9scIqa84AW/MBBMGkPxcyCMxL7z0U+DCAYoDqKNqp7+zIzEfz2PzL3zuEZ/7tpB3lheadgT83A2C3R5DpWB1Os0oEvKW/PbAKwwZsKT731k58A6/Q4WQeyh4zgIoPsZ72LwJ1Xa/KX6EON4qCA/uz3FULQVaTitRgTeYz9Q1L5xPVMt+B2XVHqseaQkjv4u3IPqKSB/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=BkB6EsBblYtcdg4TthQlzoq+zGj2omHbzRe0YMZrHm0=; b=lLVSHetqKaliFVNYB3F5F51aP2bPzyFxt8GsUPWTMSW1WWRAgIUpoTtPMRqMZTqicB/i/OQC6EQ3tm55gsrYGVSxigpOVcA5jpLCQCBOyqKuLVoQvzDeyGw/gnhT1mDny7DgKJ7MPa2ewBCIrjyQIvoFnOwApXuDpNoHyEZkNTOreIi5OlxDjHXUmSzK3DotYCzC1SmLLL5daBpgE3WYFf6J/1JYpVqjfzRHX65oZRsYyApomKKxwAMoZ3TPVaKt9iKy/I4i+hDf0XNwuo1SMj7+Q1mwZNvSyLf/mgPyi3dpstRxPwPYReXcS2zxkSM8OEFb4YpJMzC9INXk2X5omg== 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=BkB6EsBblYtcdg4TthQlzoq+zGj2omHbzRe0YMZrHm0=; b=O/di4petjN7isxlDU8yF0iKjRk1rQqNEjvyIF9iYTACwpF5rGjNaaNyrjtgn+KT/Nm+KcI8y0vmixfhI8qmyNw/unsmOX5zBEnHlPO58chFzhbykJe31RRI8PMVJXVDcQb3OJ2/r5ze5I0Vr3NaLQUpEgoSZ99h6ZeREhjXMMH8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, Kevin Lampis Subject: [PATCH] x86: fix incorrect return value for has_if_pschange_mc Date: Fri, 9 Jan 2026 11:43:30 +0000 Message-ID: <20260109114330.2361144-1-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.51.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO2P123CA0004.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:a6::16) To DS1PR03MB7992.namprd03.prod.outlook.com (2603:10b6:8:21b::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS1PR03MB7992:EE_|CH8PR03MB8203:EE_ X-MS-Office365-Filtering-Correlation-Id: 51665958-21fc-4c69-26aa-08de4f744ebb 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?/QxLwuv+XDDAsj8lF7FKBj6xUhoKk3CfEVqH0qoz+zaMla9mNgRtv7wse3Jf?= =?us-ascii?Q?eVQ55xMSDjSGfOXzJc8fdni2DIqZ4l1gm4Yb/7KipihTKZwpVoRTZ7vmxWS0?= =?us-ascii?Q?SvM/iDUK9cLNsdIk+Qkx/atW4qyjZlFlDOdIsJnXrAxiXFhe7/KvI/q31aPa?= =?us-ascii?Q?yd2WNYift41bo/ySoXBwpWpJ+VE6G9htGKKQOn9t/k4DsosmkHhRoeOjBYLT?= =?us-ascii?Q?rep4OvwhshQFF51WkD1mpSLg67zsq5Jkvv+9mTMOM6riwP55me7yHKC3JO/A?= =?us-ascii?Q?GSL3Gcfvqj8uF1JbhH6ci/ShsDJ6c+kTJdpyDMQFBPMjCketoS+r1oOiWKmz?= =?us-ascii?Q?kAM3sMTIZvq1mMJlwZfS/Zta9mmgT5YPbs/JvWMULyRHwmRQ41rCVS0+cQNL?= =?us-ascii?Q?j7tLeNM/D3ZdqxGgLjbSFNRTSPMYuxgBJ2nsVohz+VXD0VpH/Gqm0CPLYJG2?= =?us-ascii?Q?H05m0jxVREuLwval0g/TsLVva+ajnMwgZaPDY3Bjfsg0ww3ijUwbuSbz+wRM?= =?us-ascii?Q?xOhDblgYk2gZZLXT8hOBJ8WuxGOcGTsl7zXFbjmDe6bqZdfvk0HbMzm+1shd?= =?us-ascii?Q?W2b8tShmmFHCKR9hm485n9Z9VPUqKFKleRNOv4yMAnL3O2/KBYsSZJUboEjO?= =?us-ascii?Q?d5M4WC3r6+Y9I3aw16UVVjO7jCh4TWI0J4vuaSq1RYg37XmBPnUieTqNsq5W?= =?us-ascii?Q?QPwxrFd7WnquunA2Hb4Znbu9RausHGy2VytOqmk8NOhv+N9nLHK8TX4eF5sR?= =?us-ascii?Q?41eBLHUaNEp/7Fn1j041sI4/fkKTLniIsy+1MvKup3YAPHBEH9kns6kG0dzr?= =?us-ascii?Q?uaTP3FlqdUMcX0/ftGb7jEQ14NZmQlRx1ymbyloE5sUI2A+ar2zJH7+LjUvp?= =?us-ascii?Q?YItcWDzcwKNEBtZ90KH5NlRUj3WANmTZDlSbql5CfyK7++xxwguz2MzlxToN?= =?us-ascii?Q?m9yGMYqWnnzIB6rG/foVy+DPc1WChGhZqvYPHkGrwDq4TPqKfbxLhLc38PF/?= =?us-ascii?Q?qUsxO65LXY1LYQVAjrNnDjVmyFQGqjsu+VdzfNifcIuT5cqUq9o3ypWnWQP8?= =?us-ascii?Q?m+WQa8kc96nbFnCBKdyczmnWKfw37hhj+cz4Zxre0a43fdyHz72raEcQFzC/?= =?us-ascii?Q?0MY7FgqMEKPhtgwim+0SvZfChUs8wyp+d9eHodYw3E54vJ1sESssI5ztcwbk?= =?us-ascii?Q?Y6dgfwy3hGHmQPSYV6AgyYv51++796i8fhQrFJ+pZad4EFMNN9GVispCLo0y?= =?us-ascii?Q?z+0UanGd1dDOGe6HG8Qraw/xWuLh+/J/jpTWSnHiNHhod/Pa7DkL6gK+hvWa?= =?us-ascii?Q?a6O4cKfgIXRrHrgBDM7YKjgBziBHb9Gks1L7b/jr2am0MEcQRaHhio5fHjJP?= =?us-ascii?Q?uQ5XD77dUPdu9dBSyvQ9aPFb3pQq7SDvl7lenPdaN+r5ZPdc/4pB7JzMBeEJ?= =?us-ascii?Q?nV0YmG2nLjPtOh4mbynuxlRKDPRAzBsH?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS1PR03MB7992.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?JiZCAdqqXLufGrU3j94C81Kvv2BAA6T+NQxR9856XqvfLTAz6j/Q2AwN9qEP?= =?us-ascii?Q?hirwEJ9UxsBx0Fh4ZY6ttLk5a7e/X1rJ1t1KLmTfhndeafvgLWAleeeenUp2?= =?us-ascii?Q?KicKr4qfq1XpnVc8+UA8U4Ec5Ol219hmG28v5L0rAsBg0yFgRipu6MS9rZfV?= =?us-ascii?Q?TO92hYyTto9G4sf47s6RCUIhpSh9WRRX59bAdNNlpI8SeMMPXLM+xLtSDYef?= =?us-ascii?Q?iHf5TvoXTI9P3UKXyhjnUZIzSiuM0w9jct/bxURhIQMYiywJGZkMvQfJEPA1?= =?us-ascii?Q?6QHyNCiSI9LUCnaaES1tIHMQOPGUEQmksUgxKIEk9Pg1qSjyF3guwKBuUYiV?= =?us-ascii?Q?pkiLMbVXP9UNsDK+nBSgd6wMyfvPBCxRPJcwtOm9/oCCbTfC8XqvTN2WrVuI?= =?us-ascii?Q?wyjlzysiIvvoi/khSXywPZ6RXsMFAJwXT6Fy9e0CZD6yhpgO+oHNc8T7u5Jm?= =?us-ascii?Q?pBN6Mnnu9HeAw506EqFFCaPyZsheWM3avLbKxWNVPxsO8Eb1/i22Nte/F4E/?= =?us-ascii?Q?E9owGty+yiD0S57NqQDb7l4/D8fa4reDMk1nDukfRV2F1KuLuwyzp78eTJYQ?= =?us-ascii?Q?w/xKmx9u8rNPVeqYotfkbIdcY5GlhdbAE9TtkRaOFZuWmvPqxSCN8HUGswFU?= =?us-ascii?Q?89N+5ZbStdlSkExRYYM7TdOakD9tRdzuF0bxdXQ2acgy4u+/BIFo5271AzzP?= =?us-ascii?Q?cHoW6dyMpu/A6Sv4w/96Po+Q/LrH2RyI3VS2la2J/vL2W1T9hUZHQTQndGoW?= =?us-ascii?Q?4nePJqYTOikoTAgKuPDFdPgRDuAWqfJwLIrjUSu3JGymhwwqC2mL6YSDucpr?= =?us-ascii?Q?1eCbPHH9Gv+K3ziKt00jarKIg5EeUYxtyV2+kMZG7+d41D2W94WRY/LcuLo8?= =?us-ascii?Q?KasiwJC426mRXpYam45GiXff1cYX9+YUT2QdW1drwDsslo2QuiNAmkamzeec?= =?us-ascii?Q?AuR6m82A5PcRT5VY2aIpUSFNzA4qeQ4R3/ISHTtvr9LSPeDdEQLIJACMIrdR?= =?us-ascii?Q?3146N/T+l3d7/wNxQRn+TPIFb/zKjERM74TdOZbyKPdM+/JsLCG1WcFmUepZ?= =?us-ascii?Q?p8P9EN0L7Z5imPPLXsMTGy90kLNiw43VbcjSAzeRty54ejwqDCNbRU07AZtB?= =?us-ascii?Q?/RKLbpszlIdL5JNfXdmiZX3TjiFWrTanV8ZHK2dfXEdoOzJn0jJ5MX5F5DRE?= =?us-ascii?Q?DUpiFD5mJPKTgQRkXV6UUqB/wSBOXS3upcInd/Jj/MPOL3CLYXfeZI7bNBZe?= =?us-ascii?Q?IUa1X+UWIEuNLxYhNrvXAksfgbewx7Boeu8ywrpU01UN+qBBKoBhMkNHF7RT?= =?us-ascii?Q?pLDIDi3X4Ale/8rYYTwrTv49iWIsnJ+DN+0alloS7PCda7A97rWxVWTGbz0+?= =?us-ascii?Q?hrhsc1Xg2yen91cJ6U3mfndvJOJWNVxtYtOelMTMKW9FeiWgpjaLnxKH1CuL?= =?us-ascii?Q?jRmdwX4I32fWkMdA+tcBwspW3Hni+uI9pM01yeTGnZsq4fMWgqVBJaT3Wcut?= =?us-ascii?Q?SXz3i+EEXVUV+BezlcHqT1iXGZQpxJS9DfqhS55Z9/fc93KqAoi7kUlY8YiD?= =?us-ascii?Q?EaWQQUXg24nyLxK/6WIGD7hzPVlqQ4BS9VjjGOVIyIEDdomxu6rAA7KLE0vp?= =?us-ascii?Q?027RQMe6uE6aNSFz08Puq5yh9TzaZdfL0viTfjhQu0JAEijs0ArFPma8sqbf?= =?us-ascii?Q?7IyXcAt5ACPLrS6vBsd6xAaXIF0YlP9nqkQR+GXAQQgChAIPXtsCiUcs7S0z?= =?us-ascii?Q?MEXNy6TH7A=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 51665958-21fc-4c69-26aa-08de4f744ebb X-MS-Exchange-CrossTenant-AuthSource: DS1PR03MB7992.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2026 11:43:29.0549 (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: +QLCkicZYarnYwjnjw0ukBEzE6xkctvNyI0yj79F0/Ay9/VfS4IKeqgdagqmmy5a3OymsisQSGAQ6kzbmW4P6Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH8PR03MB8203 A return value is missing from this function leading to safe CPUs being marked as vulnerable. Signed-off-by: Kevin Lampis --- xen/arch/x86/hvm/vmx/vmx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 05b59cb8e4..cf474ee5b3 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -3117,6 +3117,7 @@ static bool __init has_if_pschange_mc(void) case 0x75: /* Lightning Mountain */ case 0x7a: /* Gemini Lake */ case 0x86: /* Jacobsville */ + return false; default: printk("Unrecognised CPU model %#x - assuming vulnerable to IF_PSCHANGE_MC\n", -- 2.51.1 From xen-devel-bounces@lists.xenproject.org Fri Jan 09 11:48:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 11:48:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198637.1515515 (Exim 4.92) (envelope-from ) id 1veAyb-0008UF-Hh; Fri, 09 Jan 2026 11:48:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198637.1515515; Fri, 09 Jan 2026 11:48:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veAyb-0008U8-DC; Fri, 09 Jan 2026 11:48:21 +0000 Received: by outflank-mailman (input) for mailman id 1198637; Fri, 09 Jan 2026 11:48: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 1veAyZ-0008U0-PH for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 11:48:19 +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 16deacf4-ed51-11f0-b15e-2bf370ae4941; Fri, 09 Jan 2026 12:48:18 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MW5PR03MB6960.namprd03.prod.outlook.com (2603:10b6:303:1ab::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.4; Fri, 9 Jan 2026 11:48:14 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.002; Fri, 9 Jan 2026 11:48: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: 16deacf4-ed51-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=c5HStCkGJWdhWbJfMm6fBG2SNtRVaunGJXstVurZjG+nctWD6Xk5lVzX3XuR4sf59MvArJOFXoxhlGR0LeiQqcZcIDX+3vJAXJpKtTB7PIBs6HmT8o4EuZyu8/x2Jv5JPVf8wWJM53DowCFlU1PTsPYA3TXargn3m01JGmko3723GAtf/cq7w5B3RGEaHbeKqJrKgHUQQ7ORkNwIsKbaxxmsQvDsAqvZ9iy2iCU/VfiYkBU0kUD+dpANcQDIAYbk+5ctG/AOIIUOPpLrlUGOlOri2GBygsqDBeiEx4U45e3odPCmKWWEO6kNMHHfWlaQBQHowOMN/eVdhS0JcfB5+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=Di0fXrQd0DWCckfBilDbgmuzrZ0kF0UTfw4cLrbm1XQ=; b=YhiU4AOdBIdGSPTm2JoNe68pABC/gMGqf9RKo00d/LG7Sr2HGs7f0ljnIB3jVgX3mIdLHdagllzeOvu+F6YLTysYf/28i4tD3fglVzUJ27NLNcq4rw+l6Jfl8sK8bpslzMms5oE97zctSUy5wwICW8ZF78MyYLXbXKlWR05Fb+p4I/RV8nq6VGZ05hyD7MNZJATUevk/hfXoiQ9+nTR13A2uQA6oKd/+0bjw00ob8X6ec6PFWMGPgLgElkxn1NkTsCWFy8PWLa5UGu+F49exLC8KSsHJ7hy0QBS6eVQxTk5lMe1CtLVk0QuTHRYTsbTkvehtr1qt62YWVASd4DmZow== 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=Di0fXrQd0DWCckfBilDbgmuzrZ0kF0UTfw4cLrbm1XQ=; b=K11RWo9eAyapHMr/sc5hmnS0OehhRDYr0PD3gK3NcpJvjtETEOnh53zT2gCGsGzYo2BwQRBfcqN820udwXZc07VXab8l/8crCJCmomHvIa6aJKo1wxZu117jc6HLx81NrhrdMpYlH0gsfOly8snUSifP2+ZiVrXXklwgcIGMG0o= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Fri, 9 Jan 2026 11:48:11 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , jbeulich@suse.com, roger.pau@citrix.com Subject: Re: [PATCH] x86: fix incorrect return value for has_if_pschange_mc To: Kevin Lampis , xen-devel@lists.xenproject.org References: <20260109114330.2361144-1-kevin.lampis@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260109114330.2361144-1-kevin.lampis@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0067.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2af::17) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MW5PR03MB6960:EE_ X-MS-Office365-Filtering-Correlation-Id: 1c4eeddf-8ef3-4187-a9db-08de4f74f8e7 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?eC9hVFljTFRRV3FHUUltemRMUHZGNmNJVnd6YmZDazBFV0x1ZVFsdmtSNnNT?= =?utf-8?B?bUZ5R0E4YXJ0LzFzNHZScytxN2o1alFhM01mdFg3aVNaSnVsZjNleHlhQU9X?= =?utf-8?B?TXVBM2NiM1pGVkJiQ0tBRC9EVUdoQzd6TlFpdjRJZUFmbXZyeDdwWmRhanRr?= =?utf-8?B?bFV3UmlhakVRYjF5WkRYUC9PSlZSR0xMSjlqd29rM1A4UytXdXVVWFFwWnpy?= =?utf-8?B?clpvdWMwUWJWaU1MeWtEbHQ2SS9ocTNhUHJkUWN1cEpBS3RCckhOTmJKS0lp?= =?utf-8?B?aU9iZWlFMXNNZUlwaUkxRXFsUWtWNzBhOEpYR1dpK216TkhiT3Y0Rklvcnh4?= =?utf-8?B?MVRUVDNKa0ZNVnBPVzFoelVxTE5lbFdqOTJDWExvMnlHR1JWUUhMNzhGeVJ6?= =?utf-8?B?YVlVUW9EUFY1VG9kVTBMbDlLVGJYQ2R1VjVmdVU0UFV3VXhvaEFxT2JtZ1VB?= =?utf-8?B?VHdOblcvQVJzUFpyVCtUdkpmSHM2SHcxNWl1Z0VLZjhRKzg1SEFRWEdTNWNl?= =?utf-8?B?Vm9MYnpwak5ZUHlLdzVXWTVuTU1DcEtSNFNsUWQxS2tKR3lZdkJUcXNqWWVS?= =?utf-8?B?M0JBc09RZFczczMxNGZCYmdlbzJyby9GNzlyeEhhUFV5QnVVL3BhbXVlMnNS?= =?utf-8?B?RHUraXp5QVdLNzlGZ1plOEE3TnVHRTdpS1FpZ0Y5bG53OXdFSGhHZHpOcXNS?= =?utf-8?B?bmRPOTRpSTd3OE9JMUw0MnZ5QTkvMzJuVjY0UTVZYnZDSEVoa2YrWFQ3MDRy?= =?utf-8?B?ZmdtVDdtVFg2VDZJQVlQZTZSQ3R3RTVYZzdGWWVreVUxSEhCVi8rQkFKeGs3?= =?utf-8?B?bmdXMEVTWXE0R3ZHMjNDTlQzZ3hobk52d2wwWnF0NUVML0c2SG4zR1pxRUtJ?= =?utf-8?B?dWp3VE5wREdTalVQRTRpc09vUk5WQ1RyaU00MUJGQWR5bWF1eG1uUitYWlRy?= =?utf-8?B?bmY2dERMN2VIQUVoR3M0d1NnZGFzREM4S2pJcFNkbis0Y2JOVHZPMW1xT2Iw?= =?utf-8?B?cFJSbFJMR2E4bkx0VXRkSVFuZ2V0MzNOd2VPMEI2Ky84akltRERQNHpkTEJu?= =?utf-8?B?ZHJVSTZLS0o5enlLQ29xMjJQWEhnV00vTWtnV210Yjh2bTNEZWhaaktycnlK?= =?utf-8?B?RGtvN2xFN0crZmZ0QnBxNWlRUHZxOVJTeXpueVR1U29saGZweThGalc0bEhh?= =?utf-8?B?aDdYWmdGb000Z0pvOXRqSzJDTkQrcXBjaTFuTm8wTE53YzRGM21jdjd5enNv?= =?utf-8?B?cG1MRlh6YW45aDZTTmdCd2FhOHZBU0xGQm4xL3VLaHMvdU9tSUw0eU1jbXR6?= =?utf-8?B?T1pYaUxQVnVjWks0V0g5ek5UMUdCWWRMTFYzMEE2WDhlQkhMeS85eWV6NEFt?= =?utf-8?B?bFE4WUM3aXI0Uklhc3liaU9qWllJMWxrRFJUeEVqcWN6ZUR6QVZ2bFBZTCt6?= =?utf-8?B?RVJyUFlpdDJmUlRaVkFselJWeFQ0U29GWFdzR3dReTNhVmJPeVBhVnlVUTRq?= =?utf-8?B?OW13ank3SUw0S1B6ZXFPamVIWHg1RkZkVmpnaVRCVzBORHU3dWwzR1IvMFRj?= =?utf-8?B?Tll0bmVEdVZ1UllkMk1KTUIrSnlsUjhOUVNrTmpOOVQydzVSS0hFck1OdXYz?= =?utf-8?B?SVB6NTFhNjUvUHIxSjJCNW1wRVpoRTZ0eHVTaHAzM3N5TlZkbFNWVURkNklp?= =?utf-8?B?d01pcjBmNStOWllrYndneUV3QXF2TkNaN3JyV21QZDFYQlFOWmxsejhYMUpi?= =?utf-8?B?YVdRM0NCYnJLcGpBaTFWa2owSFFZc1I3Q1R2ODdENUcxYisyVTRyemN4anpZ?= =?utf-8?B?MGJrRVpEMllWblRVU096cWd2QjFUZWFTMW9XQ3ljYUVmU0NEOHB3Y05ac0Ez?= =?utf-8?B?OWFNZUZMaUxVUU90bWprM29QM0EvMjZwNmxnZEpTaDVjMmxxVG9XUmtLcUVn?= =?utf-8?Q?w2l0GwOBRcBaHQookzunXDqtQhWf92U0?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Z3V6bFNKNEpHVWkzRUd4WVBwUU5YNE5DbForREc1NHdNM2xha2s3UFl0NXV3?= =?utf-8?B?MHpWUzBhemVLcmhpSW5jVHltK2R1Vk1TTjB1QW5tMlZsNjBiZlplUThIM0RJ?= =?utf-8?B?SjJjaUw3RXJ1cnZNNXVEZ1dXNi96R0N4SDkvNStCblJ4djRGWEh4UldEU1M2?= =?utf-8?B?SU1zcXlNM0xINlFMQlFZa040em5kdlZyRzJYMGROWlFGbE8zMmsxSWo0SGJ2?= =?utf-8?B?ZFJGOFk5dlJRelNqWVMvUnM3TEZWM1RnclVIR2hQUWd0dFZqUU1aNCtZVzRo?= =?utf-8?B?RHhGSXNYSHJpWlN2OWxZU3k4RmVUZUJzdHdMei83Q09OYnQ4OFRmQmlSQ3FW?= =?utf-8?B?aldSZVdza1h5dUJVdlEydnJFT3Jad21uSWlUV080cUxoMG9qOGphVWptYjUy?= =?utf-8?B?OXk5dFhKZ3dEakZpQllwQS9mbU5UWXFQMk1CWVJIWVRPR0VEdnJtMnBiYmJT?= =?utf-8?B?cStoelJpc2xtb2VOcmNabnZBYmsxSW5yQ2Rsck0xU1ByMGs5d2xvdVEwSnhn?= =?utf-8?B?VFNqa1Z2akltNSs2bUlHdGY2amZqNlArVmRzN1NxbVFEZzNQVllZdG1BRy9M?= =?utf-8?B?R05UUEN2dE5HUkhJOWo0SVNLZkFISTRXaDRWbnRjQVFQMVpDUjFhRlY3dnNT?= =?utf-8?B?UThvalQ2dkU1ZUpKTlk2Q1RPUno3b282eWtaajRCNnZSK3FkaXRnc2xjZ1NY?= =?utf-8?B?OHVxaUpoK2NEVDZQcDJ0am8renY0M2FlMksrSDJUL201OUI5SURvdCtvdFhC?= =?utf-8?B?U2xRRTN3M3NZOVVCQWtZQkRhcHMvamhramJLVk9IL1JNK1hnVEdRU3JhZjBm?= =?utf-8?B?NkhuSlE5ZTlWL1diaTFLRi9ucWNJdzZPWTRzSnJrNTNWK2c1UmtQTWs5OC9Q?= =?utf-8?B?WFgzbGx0TmxuSkdmUFRaMHlxMW8xNjJNMnoxVFkvNGtLbXViWThOVW5kckRE?= =?utf-8?B?S2JhL2U5YXM3VVRtUXRMTXFIRUFRL2U4QjBpbGFuTWNuRUdjMU85K1oyeXhT?= =?utf-8?B?UFdWYlBBRnNwK01Wa3VuRm9MaXdQQUJFRklCMmJXMVZyZktyaXlmcE1OaXAz?= =?utf-8?B?STVPMkVKUEt3Nk9GOEJZSjBTbE5WclFOUlNXc1hJWVMwcjZ0SUFnSzIwQkJk?= =?utf-8?B?SXlNUk0wZUlCemVMK1ZlYzR0cE90T2lYNExkSmJvbjVkMFJheVhKSVUwVWd6?= =?utf-8?B?V2l5VGFqSllub1NkOXk3MjJQaUQ0VThwczQ5UG1FYy9xZmJvemVJQjBIOCtD?= =?utf-8?B?TjdMMVc2SXhhRVhINGFsQlhGZUdycFYwY1AxTVJnVFhSWm1FT3NDY0lhdEYy?= =?utf-8?B?S0g0blVEbzJZd2VkaWpJZm94dUVETUo0eHZSS2hydXlIdFdLZTZjNFdUOWdZ?= =?utf-8?B?RWNGMlZLdDlKVzdMajRmSGo5TG96T2QzMzRFYkNmU3Z1K01hTGw1SDVXOXlZ?= =?utf-8?B?cWlvTWtIUjA0UW90ZVF3ekRNUHRhR3RJY2VybHVKTUJCR05Pakl3WktJdldy?= =?utf-8?B?L0NBZFFYY3pmSjhqblJRTWZrcUR3ZlJZNG8wTHNnK040enM2MzNBb283cE93?= =?utf-8?B?WjhCODQ5K0hhcHhDTWJjU3Y1My9PRGJUcW9DQU9iOENKekJlMkxwd3RtZVc5?= =?utf-8?B?b2IrUmxNUHlFWml4azVxMnNmWldzZ0YzV28yay9ndkk0OWt0ejFEVHVmaHJr?= =?utf-8?B?NXVieVdpSkdsa0Q2RlgrUGtxVmNMdnRzODZaQ1BLYW95cmJkT1paM1R5d2JQ?= =?utf-8?B?dGQyOWVlZzlnUVJJUVZSbnRTUDh4OHpLNWYzMjhuRHNIbk1oTnBqUEliUjBG?= =?utf-8?B?VUJOUG5ldU94QnFCaGc2TERFT3N4NWdzL1MxbjZHcW5JWXZ4Vm5kb0RtZzJG?= =?utf-8?B?eWhuVnRkUGFjVk9ML0EreXNxeHdOUDIydUhxSHdnTVN4Rlg4ME9DbDdnK2pB?= =?utf-8?B?alV6YzZwS2EzeVorK0pPNmR5RTd3WEVHdVl3NzRlV1NVbHJGd0Rub3JjWXFT?= =?utf-8?B?VXdmYkFtWUUvbWFZZFRpNkwvUDJiT1Y1ejlmZEVxd0Z4Vm9mZnlkU2lCSDB3?= =?utf-8?B?TmdubWxReVRFbEpranRIeUpHbFpQZlIxclZUTk9CYVhmb1JHcHpiQU16eHZI?= =?utf-8?B?TXhlUkZPRjBnWEplMTdaRm1iZUlTakVtWTByRUh3MFhqeDN2U2hrTUc4bnh3?= =?utf-8?B?OC9MRGNYUE5jNHJjSzFUeEpJd2VWQURDNmFrUXF2SktheUI4TDhhL21jd2dk?= =?utf-8?B?VUMyZ1JtN01mWUowazBRUXdyZzNNOVBpSVJUODZWWVNqNlNEaW82Y1Z1bkxi?= =?utf-8?B?YzhCVVFsTGF4ZjdZdFBTRVN5cEt5RXp4eVJ1Nll6dkROQnphRHJYa3Vrc0Vz?= =?utf-8?Q?0ovlCW4okCrVnUnk=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1c4eeddf-8ef3-4187-a9db-08de4f74f8e7 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2026 11:48:14.5811 (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: un++iIC3oWZrhyKt/Lihy+58ElWnWUiO0S/2HH26V2Cg9Gs1rUV5o6JBLPg7TXYA7pakQ4SYFXs6IgY1IA8hkIL9qXP4zSc9lR7eauMTAwM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR03MB6960 On 09/01/2026 11:43 am, Kevin Lampis wrote: > A return value is missing from this function leading to safe CPUs being > marked as vulnerable. It's not really a return value that's missing. It's just that the Atom block used to fall through into the Phi block to get to it's return false, and this was accidentally dropped with the Phi removal. Fixes: 85191cf32180 ("x86: drop Xeon Phi support") > Signed-off-by: Kevin Lampis Reviewed-by: Andrew Cooper I can tweak the commit message on commit. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jan 09 12:08:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 12:08:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198668.1515524 (Exim 4.92) (envelope-from ) id 1veBHg-0003QA-2S; Fri, 09 Jan 2026 12:08:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198668.1515524; Fri, 09 Jan 2026 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 1veBHf-0003Q3-Va; Fri, 09 Jan 2026 12:08:03 +0000 Received: by outflank-mailman (input) for mailman id 1198668; Fri, 09 Jan 2026 12:08:02 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veBHe-0003Px-3r for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 12:08:02 +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 d7254543-ed53-11f0-9ccf-f158ae23cfc8; Fri, 09 Jan 2026 13:07:59 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id E62F95BFFC; Fri, 9 Jan 2026 12:07:58 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 383B63EA63; Fri, 9 Jan 2026 12:07:58 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 0XBzCp7vYGmiIQAAD6G6ig (envelope-from ); Fri, 09 Jan 2026 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" X-Inumbo-ID: d7254543-ed53-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1767960479; 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=4Z+d5TRTcuwLi/S5zOetEJtn8Zjhaf3WusJBplaDol4=; b=aA3Y/9KCXCEmqClV3RGYgLOys0emintyICqd2JAe/fdYrAisel9rYOc2SiHAdUyo235Iar V6V+uJKMGR4YssidBXnb53iVtigu5dcBMHammyvA6v7PdGqxdNAhZKvQf2vsuR4QoxziwU e865T+Fy69F2EAQ21+P/PTCjVUPGryA= Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=k95zaFPt DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1767960478; 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=4Z+d5TRTcuwLi/S5zOetEJtn8Zjhaf3WusJBplaDol4=; b=k95zaFPt9RDIKAZ5/+7d7pYm66zVpo3SAxF/Q0von+Okgsg+hb0gC0zkHw8EJMOE3Ee5T3 1c3GqBNI63JZ+IxDtNTnKQM4z0Yzp1LWmi6DRQFM/M/h0GGmg7DsCQxmMk2zLD0/C/IH2K V4hTV0PsFkjT1YkS7w9d2JZ1Yi20hik= Message-ID: <3102d712-8fa7-4567-bb8a-0f39fd71712d@suse.com> Date: Fri, 9 Jan 2026 13:07:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 0/5] x86: Cleanups around slow_down_io() To: linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux.dev, kvm@vger.kernel.org, linux-block@vger.kernel.org Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Paolo Bonzini , Vitaly Kuznetsov , Boris Ostrovsky , xen-devel@lists.xenproject.org, Denis Efremov , Jens Axboe References: <20251216134150.2710-1-jgross@suse.com> Content-Language: en-US From: Juergen Gross Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20251216134150.2710-1-jgross@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------6KmjgHGC0GjFkS6YvFAdgUNk" X-Spamd-Result: default: False [-5.41 / 50.00]; BAYES_HAM(-3.00)[100.00%]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_DKIM_ALLOW(-0.20)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-0.20)[-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]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; FUZZY_RATELIMITED(0.00)[rspamd.com]; RCPT_COUNT_TWELVE(0.00)[19]; 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)[]; 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] X-Spam-Flag: NO X-Spam-Score: -5.41 X-Rspamd-Queue-Id: E62F95BFFC X-Rspamd-Action: no action X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Spam-Level: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------6KmjgHGC0GjFkS6YvFAdgUNk Content-Type: multipart/mixed; boundary="------------Gs0D86kS3xPc0aUTHyn2oG1W"; protected-headers="v1" From: Juergen Gross To: linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux.dev, kvm@vger.kernel.org, linux-block@vger.kernel.org Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Paolo Bonzini , Vitaly Kuznetsov , Boris Ostrovsky , xen-devel@lists.xenproject.org, Denis Efremov , Jens Axboe Message-ID: <3102d712-8fa7-4567-bb8a-0f39fd71712d@suse.com> Subject: Re: [PATCH v2 0/5] x86: Cleanups around slow_down_io() References: <20251216134150.2710-1-jgross@suse.com> In-Reply-To: <20251216134150.2710-1-jgross@suse.com> --------------Gs0D86kS3xPc0aUTHyn2oG1W Content-Type: multipart/mixed; boundary="------------Ui1zwu9aMuM48dsP0uysbNdM" --------------Ui1zwu9aMuM48dsP0uysbNdM Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 R2VudGxlIHBpbmcuDQoNCk9uIDE2LjEyLjI1IDE0OjQxLCBKdWVyZ2VuIEdyb3NzIHdyb3Rl Og0KPiBXaGlsZSBsb29raW5nIGF0IHBhcmF2aXJ0IGNsZWFudXBzIEkgc3R1bWJsZWQgb3Zl ciBzbG93X2Rvd25faW8oKSBhbmQNCj4gdGhlIHJlbGF0ZWQgUkVBTExZX1NMT1dfSU8gZGVm aW5lLg0KPiANCj4gRG8gc2V2ZXJhbCBjbGVhbnVwcywgcmVzdWx0aW5nIGluIGEgZGVsZXRp b24gb2YgUkVBTExZX1NMT1dfSU8gYW5kIHRoZQ0KPiBpb19kZWxheSgpIHBhcmF2aXJ0IGZ1 bmN0aW9uIGhvb2suDQo+IA0KPiBQYXRjaCA0IGlzIHJlbW92aW5nIHRoZSBjb25maWcgb3B0 aW9ucyBmb3Igc2VsZWN0aW5nIHRoZSBkZWZhdWx0IGRlbGF5DQo+IG1lY2hhbmlzbSBhbmQg c2V0cyB0aGUgZGVmYXVsdCB0byAibm8gZGVsYXkiLiBUaGlzIGlzIGluIHByZXBhcmF0aW9u IG9mDQo+IHJlbW92aW5nIHRoZSBpb19kZWxheSgpIGZ1bmN0aW9uYWxpdHkgY29tcGxldGVs eSwgYXMgc3VnZ2VzdGVkIGJ5IEluZ28NCj4gTW9sbmFyLg0KPiANCj4gUGF0Y2ggNSBpcyBh ZGRpbmcgYW4gYWRkaXRpb25hbCBjb25maWcgb3B0aW9uIGFsbG93aW5nIHRvIGF2b2lkDQo+ IGJ1aWxkaW5nIGlvX2RlbGF5LmMgKGRlZmF1bHQgaXMgc3RpbGwgdG8gYnVpbGQgaXQpLg0K PiANCj4gQ2hhbmdlcyBpbiBWMjoNCj4gLSBwYXRjaGVzIDIgYW5kIDMgb2YgVjEgaGF2ZSBi ZWVuIGFwcGxpZWQNCj4gLSBuZXcgcGF0Y2hlcyA0IGFuZCA1DQo+IA0KPiBKdWVyZ2VuIEdy b3NzICg1KToNCj4gICAgeDg2L3BhcmF2aXJ0OiBSZXBsYWNlIGlvX2RlbGF5KCkgaG9vayB3 aXRoIGEgYm9vbA0KPiAgICBibG9jay9mbG9wcHk6IERvbid0IHVzZSBSRUFMTFlfU0xPV19J TyBmb3IgZGVsYXlzDQo+ICAgIHg4Ni9pbzogUmVtb3ZlIFJFQUxMWV9TTE9XX0lPIGhhbmRs aW5nDQo+ICAgIHg4Ni9pb19kZWxheTogU3dpdGNoIGlvX2RlbGF5KCkgZGVmYXVsdCBtZWNo YW5pc20gdG8gIm5vbmUiDQo+ICAgIHg4Ni9pb19kZWxheTogQWRkIGNvbmZpZyBvcHRpb24g Zm9yIGNvbnRyb2xsaW5nIGJ1aWxkIG9mIGlvX2RlbGF5Lg0KPiANCj4gICBhcmNoL3g4Ni9L Y29uZmlnICAgICAgICAgICAgICAgICAgICAgIHwgIDggKysrDQo+ICAgYXJjaC94ODYvS2Nv bmZpZy5kZWJ1ZyAgICAgICAgICAgICAgICB8IDMwIC0tLS0tLS0tLS0NCj4gICBhcmNoL3g4 Ni9pbmNsdWRlL2FzbS9mbG9wcHkuaCAgICAgICAgIHwgMzEgKysrKysrKystLQ0KPiAgIGFy Y2gveDg2L2luY2x1ZGUvYXNtL2lvLmggICAgICAgICAgICAgfCAxNyArKystLS0NCj4gICBh cmNoL3g4Ni9pbmNsdWRlL2FzbS9wYXJhdmlydC5oICAgICAgIHwgMTEgKy0tLQ0KPiAgIGFy Y2gveDg2L2luY2x1ZGUvYXNtL3BhcmF2aXJ0X3R5cGVzLmggfCAgMyArLQ0KPiAgIGFyY2gv eDg2L2tlcm5lbC9NYWtlZmlsZSAgICAgICAgICAgICAgfCAgMyArLQ0KPiAgIGFyY2gveDg2 L2tlcm5lbC9jcHUvdm13YXJlLmMgICAgICAgICAgfCAgMiArLQ0KPiAgIGFyY2gveDg2L2tl cm5lbC9pb19kZWxheS5jICAgICAgICAgICAgfCA4MSArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gICBhcmNoL3g4Ni9rZXJuZWwva3ZtLmMgICAgICAgICAgICAgICAgIHwgIDgg Ky0tDQo+ICAgYXJjaC94ODYva2VybmVsL3BhcmF2aXJ0LmMgICAgICAgICAgICB8ICAzICst DQo+ICAgYXJjaC94ODYva2VybmVsL3NldHVwLmMgICAgICAgICAgICAgICB8ICA0ICstDQo+ ICAgYXJjaC94ODYveGVuL2VubGlnaHRlbl9wdi5jICAgICAgICAgICB8ICA2ICstDQo+ICAg ZHJpdmVycy9ibG9jay9mbG9wcHkuYyAgICAgICAgICAgICAgICB8ICAyIC0NCj4gICAxNCBm aWxlcyBjaGFuZ2VkLCA1NSBpbnNlcnRpb25zKCspLCAxNTQgZGVsZXRpb25zKC0pDQo+IA0K DQo= --------------Ui1zwu9aMuM48dsP0uysbNdM 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----- --------------Ui1zwu9aMuM48dsP0uysbNdM-- --------------Gs0D86kS3xPc0aUTHyn2oG1W-- --------------6KmjgHGC0GjFkS6YvFAdgUNk 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/Ey8FAmlg750FAwAAAAAACgkQsN6d1ii/Ey+3 /wgAi5oL7xCqpILZVsO5gRJgR0CTRua+JeXEsT5vAtwtDnpA8iZZVLqBdXDmafTRfSUP0nRw7tUQ DVh9aTUpweByMdEoEXUup2HTJwvRf2u7r5yJMS+gM9kQbCqCq8KrhWhDpNzyy46+p9Z8wOnnlFu5 2FTSjCahYQIRkKgtSxyLmvtAF4kj0adGtpRterfJvgm7RV+FlIUrSHG80G331Lsh/+tRnaFVeyIW ETT8zC84K4V6DKfbiFsvmL8zg0ED79+XVtzARSK+Jm+jkXxPXMK8jVqgA9dSvF4/bzbqJckClEK5 XrBV2JpNaU398fDwvSrPDOhJh8tQYvr7jDyIY+4mRw== =fqat -----END PGP SIGNATURE----- --------------6KmjgHGC0GjFkS6YvFAdgUNk-- From xen-devel-bounces@lists.xenproject.org Fri Jan 09 12:31:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 12:31:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198689.1515535 (Exim 4.92) (envelope-from ) id 1veBeG-0007IJ-TT; Fri, 09 Jan 2026 12:31:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198689.1515535; Fri, 09 Jan 2026 12:31:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veBeG-0007IC-OL; Fri, 09 Jan 2026 12:31:24 +0000 Received: by outflank-mailman (input) for mailman id 1198689; Fri, 09 Jan 2026 12:31: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 1veBeF-0007I6-TF for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 12:31: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 1a8257dd-ed57-11f0-b15e-2bf370ae4941; Fri, 09 Jan 2026 13:31:22 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by CH2PR03MB5223.namprd03.prod.outlook.com (2603:10b6:610:9c::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.4; Fri, 9 Jan 2026 12:31:17 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.003; Fri, 9 Jan 2026 12:31:17 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1a8257dd-ed57-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Jmuz4G+qcEy/thCqChmPr+6SCb9AnzYTbXz5cPxU+tDTlTkvf1NKw9Vz0OQwb5NfzuCeS+cD+e9LEv6hmlN++9rMMdwGInD43ESRCWgCRZyCsaP3WUKw5F/MS5/NdtLfewC6VUrx/m8IuiTvHBL7iixc5AnyU7xAOXjgr7ZoRO7HBfD/E+K6o5q2A1D3z/inCBkKftSa1K8CJYBFlPjU7nMeZFWSlRl0Z+X28TwvbhIZte3bYII14eMzi0tPy6NSBffqESuIGjT/ClvDo7fkJltFXtn3MqHm+R/cmW2+pECTDDexeMBqdkcWZhHpD0aPSSQgCdcCjSt0iknyiF5s3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=f4Cf8CU1ruHvAsJmqchLSN1yCpGtBp9l387ayotkjqc=; b=UldFIDfC2HDJQFFmu0wXb9pXMQJXuyXLHsZ7fwe4R+0pBtdzTD/K+FTlL/yp4njF5poUH80kthvOAQS2FywXmvrIhOrWivH1UY6qVkOgM8DKiCa1F5/oiAowmoCb0CNDf29vwhzp1jABe0Raz4KT7p/32tNkL9r9lCw691V9kauDby36bbpovTIla9HGOouD65xuC0TP87YTMZbb9hoyuEWuxsClUBwEhpnEpXUCY/crTH43RWTURFcKJwl68ynZYlVCbvAkwRz3GCv7wd/iK5xInVRpURRpUWDhFynIET7qLuE8p1CwF0YdcXTA5Hqk+QAkkdlmWhZyGigezVFpKQ== 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=f4Cf8CU1ruHvAsJmqchLSN1yCpGtBp9l387ayotkjqc=; b=a0CXuauidSqpnQv8xAePMO4aB1eHb6bL8nfn1OBNJZ1KBYfTqpa3DXs7eXjP6w/3G/FftsKUavgcApA/5kRmeoRxqDIerirFoxF1gAYL2w2l21XzG8OMrOOuW5uYToPtnqoL56SC8OhfqnjEvSoe86XckDpXhrKlG/o0j2AcBiY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Fri, 9 Jan 2026 13:31:14 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: Jan Beulich , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Anthony PERARD , xen-devel@lists.xenproject.org Subject: Re: [PATCH 0/2] xen/mm: limit in-place scrubbing Message-ID: References: <20260108175536.82153-1-roger.pau@citrix.com> <6b4c352b-f4fd-4b81-84ac-41b7d3e04f92@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: MA2P292CA0030.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250::7) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|CH2PR03MB5223:EE_ X-MS-Office365-Filtering-Correlation-Id: cd3c39a1-018b-49d2-dc3c-08de4f7afc8c 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?M2ltNTd4K3pmVmFpa0ZxdmRBeHZZVUI4U084YlJqRzZmczN4dWY1akdVeU5Y?= =?utf-8?B?NXF0QmV5UEZTa0s3WFpOMkYrN0hiUHBhTCtKTVlpcXUySElOVkZVaE41eGFI?= =?utf-8?B?VjhBVXRySGxUdS9XWitJSkNqZmcySDRUYjBqazN2Ym9PbDl2U1hrNzE3Wk1u?= =?utf-8?B?a1BVaW1DaEt0UkJnY3RabGxPelhOWGM4K2xubnpmZmVCM3JpeEVaYjNNUDhS?= =?utf-8?B?eGdxYzRtdzA0UnZqZmoxdjU0OFlYN3NURnp4T1JhRFk2Y1RhdlM5UTVtNnpv?= =?utf-8?B?Y2N6SWcwUnVjcm5jd21lVFBscDlzWG5wZTZsenFEOHRickRVMnc1andWQ09y?= =?utf-8?B?M3E0NDh3WXI0aG9QMm12aEZPSVViRWhkVnhmWG96ZWxhdmRLZThST29VU3N4?= =?utf-8?B?cHN0NUcreTltblVCTkplcitSK3Z6bGlScjJRREF0WjByU0EyQ1pZWFp2YjZx?= =?utf-8?B?a0NRUnpFRmFxdlZVQVlKbThaRmMrUjY2ZWtuaDBRLzBtWTYvTHl1anRYbndq?= =?utf-8?B?b3Q5QkxIaVFuK25MVmRCMUNpa0FTV2F3QXNQcjgydnZKc0tyY0pLaEJQYTQr?= =?utf-8?B?Mm5abVRLeVBXRDcrbHdtWGp2WjBuOTFTU2lVM29XeDN5dll6ZDFma0VLbmNw?= =?utf-8?B?WVRXeWIxODlVUHVrbUtSUVoveGRBYmc5RzhzNjVObnNaVitHOTNNZnpwaG5k?= =?utf-8?B?ek0rcTlaZGh4S3hNaXJseHoralJVZzJRcVRMQW9nbFJZREMxYnROYkZ6eDdU?= =?utf-8?B?NThHbHUxdGg4TVZ6akt5ZVp2eTNyQXB6MElsOTFWL0dDYVdsc2RHUmMvbUJM?= =?utf-8?B?d0ZKd2VVRDdSRXZzZEYwZ1NldE1yVlE4d1F5RzNQMStWM3J2ZEhUVmszVDRI?= =?utf-8?B?bDRpQjlBVXZNdFhIaFFLMTl6a1hsd2hDbnFDR0RxOWxRNXNYTnBSY2FZVEVC?= =?utf-8?B?Sk1hT1k1YUpBdFhrR3R3akVRQ25tQUI4aTBiaUlhQlZ6Y3h2Ty9jOVhQQ2xN?= =?utf-8?B?L0UvbXoyaHJBREFtVGkyMUFCUHRZeGprT0hVUlZLS3lZR1VQdHk4M055RGZK?= =?utf-8?B?Nmp3WEd5aDNoWWlDRTQ2UlJLRmtnVndRaW5CdnJ0bXNwS09hUXRXVm9sTTNv?= =?utf-8?B?MERxMm9lTHdVTW9rcHFDM0lnVE0weGdPdndpMlJZdGxwN1YvQk1GMXY4TGZO?= =?utf-8?B?bUlEdGxybGUvZTFram1lb2JZUVpZeForMWhVZVFwRk9xMlFVK0pycjArc2xa?= =?utf-8?B?Tm51MXZaT0RObVRSNTlVd1BsUDYwWGJUL3RPcDJJdzcrMzlDNFFrUHExZTlO?= =?utf-8?B?bmhNZ0lqbUU2VWFkV2dQaE5NWnVWSXVJK0xkSTJHMnV1UTRKeDROYzJqRnBm?= =?utf-8?B?TStJT3FBdi91blptMTdnUXdSRDM2WHljRjNlMFFhc29tSlhmUldGT0FYMVl3?= =?utf-8?B?NnlvUGFxY1FHcFE1WmZwZklPdFluQ0FuUi9HVzlza3hibDJVenBib0RDbDdY?= =?utf-8?B?RUY0ak1KV1hxbUNGclE3YmRuZTdBZDBWQnZvMFdrQjgzZUtTR3RWM2ZsNjdj?= =?utf-8?B?bE1pUmo0NjhWN3ZNZlIycXNuL3RhSGxBR1VjNDQvelVjRms1d0VEQVNYVjdV?= =?utf-8?B?SFU2aVRtR1VnejZwcEh1bUVOVjlyaUNWMGxrVlhwdm9qeWhQWVZPOVc2Sjdq?= =?utf-8?B?NnVqWXlOT3ZITnZsd1oxSnZweHpUS2xEcUc5N0l4L0hycW42TlhsTVVVR3Uw?= =?utf-8?B?TkxGL2pPaUtLdUs4MkZEbXNYTzNkaStUR0RoSUdlNjhkWktBclIzaHhUaVc1?= =?utf-8?B?bkF2NC8yVVozaXg3K1prVmovR3lXVUlhM1dQTFJCZFExQytqeEFQTENjTzN5?= =?utf-8?B?RVk5SWowVk1KeGVBUGpqcis2QmF0NXhGRExLYXNSNzVuYk5IamliYWZmeTBj?= =?utf-8?Q?tAlZlMpsiXWMkBzwtyEqBPSlHCqGmd4J?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TFNJUXp6MldIVWl3WGlNeDJxZzl0YTk3SWtCQWozV29jc2ptZTZhMnJkRStR?= =?utf-8?B?RUcvMFB1ZE1EUTlYVCtGZFBhYWFERzVuMFUwOU5sZDBMcVdGZnRFY1Rja1F0?= =?utf-8?B?Z0NSMkhMUWFBOFc4NVdKRUxIdXpXcXQ3U1k2bkhlMUZvMkNKTTVydytnZWNZ?= =?utf-8?B?UnN1eHppa3dtTTJTcmVMakdGcjFXL2tSeXZ3dWo3RW9sOGdJSlQ3aGNOaS90?= =?utf-8?B?ejNkUVdwSS9ETTBsQmVzUHExU0VILzJGRGMxZ0dNQjc2ZG5ERldFV014Qlkr?= =?utf-8?B?Q3ZJQmluV2lsRDliL245VjhPajh5dGFBVmY3V20ybE1XZ1FPWnRYQnJzY05N?= =?utf-8?B?OUZYdC9QcXQybGNqVUxQTk53bVZhS0VRMk5aNDlubWRwRVoyTFZoWm9HT1Zz?= =?utf-8?B?eXFxcDJtbzZidnVQeWRUdFJ6bXNUTnl1Y3MzVnNmQ1o3L21rRUUyeG53UElI?= =?utf-8?B?YW02ZXI5eWY4dGxheEhpTmVnYnhJSDduTHlRazIvcXlLTW5TOFZ4ZmJFWnJa?= =?utf-8?B?dDlxOEI2eSt2RGx1Wkx2MDhNTk5ZZGoxSUxHZDJMNE12RU5tTlAwMUY2Rkt4?= =?utf-8?B?YWovS0Y0eWtCcmpkN0ZXMmw0K1FqZXdqYmhKWGRCaE5ESnFDSjlJSm5GV1Zz?= =?utf-8?B?Ly9SZE9IbWxWaitmT1ZjM3pSTnJVU1diMmhzb0Nhd2pYd0NNMFpZdVRrQkN1?= =?utf-8?B?dkVYcFgwNGl1aWR2UFRlRUhZMzhaRGt5djYwWXR2YUw2OG8rajVkU0JYS0VQ?= =?utf-8?B?V3VKMFNGUlBYelN0bEZQVGN4NFoxcHZvaHpOT2JsLzJVSFo5MFFvT1Q0R2ZY?= =?utf-8?B?eUtIeE94czRXQlRhdEpkSU51blJJaGpYK1Ivci9RbEo0S1MwQ0lzK0FCWFBh?= =?utf-8?B?M3pOK2JacGtVTVhXbUNvMEZ0SmM4NHd0Nm9pVlgzZ0ZleWM4blMrVS8wWUJj?= =?utf-8?B?UFArRC9YQUNJK3Qrd3JVMDVwckZQRTVpU0N6TVk1LzU2Qmp5Q0dFSy9VTi9O?= =?utf-8?B?MjlSMlF5OGNlM0tsOWluTFJrbkVxdlk0RkNqSnNycG1KUEFhN245dmhuWjVZ?= =?utf-8?B?STcwdHlmNHpiU0twVC9nMlBYcndla0t0RXlEdzV0dkpGNi9EeTIreFpBZnNQ?= =?utf-8?B?VW4zM2hjd2FiaU1Rb1FGUFFoMVlkLzBrWVdZemtoUTZLN0FiYm9INTJtd1cw?= =?utf-8?B?MFZKTG9nTG9JY3FsUW9seHVsdTRkQk11TWJ6SmNxbHg1bWZmUmlpZDd1b1dP?= =?utf-8?B?bzhib2lxSEhJWlhaK24vQnlvVm1EdkxBUzdUMGNjd2ZGL1lLN2RPLzVscjB4?= =?utf-8?B?SDNzc29OR0VhQ1dmV29Zbm92Nlc0NXd1czNIZm05UFR1RXE1eWs0SmpXRzBN?= =?utf-8?B?bWZ5Nk1DRFFHU24xY1lwdVNEVHN5YURya01ySW8wVW11YmIyenJCUHVEQzJj?= =?utf-8?B?Y2dEU3QvQWUvWlF1SnV3dVVrdzhVQlZlWTVRWEl4MnRodzU5MHZ5dWp6bjlJ?= =?utf-8?B?cDhra0cxc0hpVCswNnlPL3NKME5BMUNYTm1BN0ZuRk1ieFYxS0xadVZDZEpD?= =?utf-8?B?bmw4Nk5OWU1iN3VLMlErOXR3YitpOW8yWW1mUjR5TXI1WEhmUDN5eHMrSEl5?= =?utf-8?B?RXIzTEhwNUtVUHVCM0xqWkdKenlrUTZ3OGR2UVpQczAyTHZKWXE4ODMzN0Ur?= =?utf-8?B?clVTVFgycWxpSi91WmtHZ1pkWk5GMWFQWHdPZXloc3hXcjQxckNBZWdsMjkw?= =?utf-8?B?QTY2STBHVU9yRDFvVU91aS9JVi9ncFBhYkl4cUdoTnIzdkNIUDluQ01XMG5t?= =?utf-8?B?ZUdFQllmMVdQMUpxUzhkOVdKNFlQVytVZmtCQnhkdTd0ZTYxZlZSL1NQN0Rm?= =?utf-8?B?TUh0RVEwSWRNSDVFN1U3VUwwQkwyVEFSNHo2KzlFL1F0by9RdnVNOTAvU0Rr?= =?utf-8?B?OTJyRzlrbmZubFpoa2tTTU8xeVdWZGxkVDAzUzFzb3NRQjVlVm91VnFTeVNO?= =?utf-8?B?RUEveWpvSDN2QTUxemljN09QSFR1ejh4US9IaFdwL3d3ejZNRWZvWlhTSEYz?= =?utf-8?B?SFhrN3l0ZVV5UkZqdTB4Z2w4UU5XU1UySnJUc3FvTS8zRVFZcjYvQ2J3MFVF?= =?utf-8?B?cnUwYUpSUVdMdzJjaXRZM1kxZFJFWkFyZlZsbGJpdVRBNGg0NVc3aFZtWUpH?= =?utf-8?B?eHY3ZGxCWnJpOXRYY2pnRnRhMk5leU5xYnA3a3hyTk40ZmVSMm9ZVXBmTUVQ?= =?utf-8?B?cVlZbGpyWks3T25Sa2lsa2IvRGNUc1pSbjltaVZ2SXdYandodlZMSmxCZWxH?= =?utf-8?B?eFAybm5FSjg4M29ZWEJBY2hMTVVCSTJMcGV4bWQ1RTRmR2JvV0ExUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: cd3c39a1-018b-49d2-dc3c-08de4f7afc8c X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2026 12:31:17.6863 (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: gEbjt8zoOmiOv1MY7JIr5QbbnDchNQHORxg0vJTb0PO/VjQ2bS0/jYA9yesZv5RJCCkbQ5Om7IG4tyocgEPecg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR03MB5223 On Fri, Jan 09, 2026 at 10:29:20AM +0000, Andrew Cooper wrote: > On 09/01/2026 10:15 am, Jan Beulich wrote: > > On 08.01.2026 18:55, Roger Pau Monne wrote: > >> In XenServer we have seen the watchdog occasionally triggering during > >> domain creation if 1GB pages are scrubbed in-place during physmap > >> population. > > That's pretty extreme - writing to 1Gb of memory can't really take over 5s, > > can it? > > Sure it can. > > > Is there lock contention involved? > > Almost certainly, and it's probably the more relevant aspect in this case. Possibly. I can tell Edwin to give me his reproduction. There's also the map_domain_page() page aspect of this operation. On big enough systems this will cause a fair amount of stress to the map cache, since each page is mapped, scrubbed and unmapped. I don't think however the systems on which we have seen this to be using the map cache (it was on debug=n builds with less than 5TB of memory). > > Or is this when very many CPUs > > try to do the same in parallel? > > The scenario is reboot of a VM when Xapi is doing NUMA placement using > per-node claims. Not exclusively. We have reports of this also happening without any claims or NUMA placements being used. AFAICT it's possibly triggered when doing reboots of multiple VMs in parallel, and all reports of it I've seen it's on multi-node NUMA systems. I wonder if scrubbing a 1G remote page in 4K chunks is killing the intra-node bandwidth. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Jan 09 12:35:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 12:35:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198699.1515544 (Exim 4.92) (envelope-from ) id 1veBhZ-0007qO-8p; Fri, 09 Jan 2026 12:34:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198699.1515544; Fri, 09 Jan 2026 12: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 1veBhZ-0007qH-68; Fri, 09 Jan 2026 12:34:49 +0000 Received: by outflank-mailman (input) for mailman id 1198699; Fri, 09 Jan 2026 12: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 1veBhY-0007qB-3a for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 12:34:48 +0000 Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [2a00:1450:4864:20::343]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 947b377b-ed57-11f0-9ccf-f158ae23cfc8; Fri, 09 Jan 2026 13:34:45 +0100 (CET) Received: by mail-wm1-x343.google.com with SMTP id 5b1f17b1804b1-4775ae5684fso20075685e9.1 for ; Fri, 09 Jan 2026 04:34:45 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5fe67csm22080685f8f.40.2026.01.09.04.34.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jan 2026 04:34:44 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 947b377b-ed57-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767962085; x=1768566885; 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=D56jBZpJ8Xmrnu3z5qry1jMmpBw7OSTn5y05yZSJKwc=; b=ZzcFavtJJwI+y7Qtno5vDirP0e5Eo4XWSHmwR2IJlCPDNFwue5RZ6FMKkRGm7pmJM8 4lHh6SgIpyvdP1oNZKMQkZqSPWjsX4ZAsVagdszmWhTqNMcgvXaEL9GO3yEvRhOBIf5+ jhgiH6oknmAWfgkorBT18AoC/aZX2LlRG4VK+zP/NbYAlQmKSAmmtgGZo4V0bSpPqqAE FMjgHqrsBAYHJNh73GPW5U2bzY36w/aPv/jn8BXYIJSr9tFM+lf00M4cYoQIfEA7rAIi /BEITdz+x5SJ6U8JH9ruqq4ER+vOvHs6x5+3Dd12+nLBVc15yFbvuQTbKmeFX0VWDYr7 Mg/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767962085; x=1768566885; h=content-transfer-encoding:in-reply-to:autocrypt:from:cc :content-language:references:to:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=D56jBZpJ8Xmrnu3z5qry1jMmpBw7OSTn5y05yZSJKwc=; b=TMOOotiTsexaFOjJApJ0mgMic8v7sEdYf7fMqG2GRnEWVcLUV4ALRsDavgT1N+kRw8 fnsCoWPphQ/dDS4Bv4GQC3Dmud2NgKFDf/ChKqmRV6HYHjodXIiYywMmh4odMG8R1cV5 jTGTwYqBjVWrQKRu8yHdiV/b4L6G2iVc47lkSmzX5yzvFYABRX+7zGNu0RZL9r8BfKKW OEBhyEK+iDyLYgYQuwqmF/4PPBWCQ4ymWfdbuYrgCp3nF4PmtnqV4rC91vSzjJV7+gWB lua3Mp31pZpz3w5Y67FwwSZ6FAFg6MnH9eLgOBgXkmrLdrFHyMl5d8KpcMLjhTnIjJmP xjzQ== X-Gm-Message-State: AOJu0YxIq45vCIZttlmGwe7rg/sVOwSwmmjyjc50Rf5PWJmChY/42DvD T+nWU+SkJlRdGMv0i0H7pnBfpg9jJMHtz2NIlNVHVrsCnjxcz3L53wi8BT+Ht8BCKb1BEDPbjBD /FOGOxQ== X-Gm-Gg: AY/fxX7wTL5csNumh9EBeAlWkGdq+Yw8RJRlq8RdPNqcNU6ml3NenSHIgW5vRCDoEuE 1Csx2R8UuiiK3kIdSb3GeIKyGfsXD44LKTmRcEUKNkx6BIfm7Kh/xoGrlStuRe98BuCI86grG/B iaV8p0qbNyUJc74TW1tlaP5BJzYm1r9qzWPhhh7UE/VWbU5dmYb5MFPtkYr92dxQHbL45dajUCK Qurk4j/uhyoXYpu6mL0PC0Hrvrox55GWHGJ8aMHw0/OB5tKtD9dNKVtOt00BUcOcHpQ+ZZ9tg0U g870pi3grtb+5Im52kcHm2Cd4nKugtz7vZrXLjjeV5DGmYjSFp3GjGvqh4HvPOLYx1KxAe5bhL0 aRAZFIDFvnbhc/n+GZ7J9BXs/iPZB/cDPy0v/VfvularFspKFryRHDSJZiNRtu+29gndWe6MWCr XsSwZJQlIUwF0s6Q2PmpAKeADbIB2zYo27LsWLmqopaixVzHSx3yAZLCsAEJ4P7YAQhDQt8iFvG YTkBeZ162reTQ== X-Google-Smtp-Source: AGHT+IFoBhfh9vxrvbjS6kZEBUjlFvtP56OJG+LvBDHAvyK0eLB5B5JGnDv2MlgYxQ934ikWqbqGgw== X-Received: by 2002:a05:600c:890b:b0:47a:8088:439c with SMTP id 5b1f17b1804b1-47d84b3fa84mr87098405e9.35.1767962085246; Fri, 09 Jan 2026 04:34:45 -0800 (PST) Message-ID: <77e8a4ec-9e94-42fd-8bce-443e985a2f76@suse.com> Date: Fri, 9 Jan 2026 13:34:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] INSTALL: remove unsupported XEN_CONFIG_EXPERT from documentation To: dmukhin@xen.org References: <20260108141641.506534-2-dmukhin@ford.com> <4e14f1c5-bd85-4ac5-a2a3-613f9673252f@suse.com> Content-Language: en-US Cc: "xen-devel@lists.xenproject.org" From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit (re-adding xen-devel@) On 09.01.2026 13:17, dmukhin@xen.org wrote: > On Thu, Jan 08, 2026 at 03:27:39PM +0100, Jan Beulich wrote: >> On 08.01.2026 15:24, Jan Beulich wrote: >>> On 08.01.2026 15:16, dmukhin@xen.org wrote: >>>> From: Denis Mukhin >>>> >>>> Amends: 37339ba9ef46 ("automation: Remove XEN_CONFIG_EXPERT leftovers") >>>> Signed-off-by: Denis Mukhin >>> >>> Acked-by: Jan Beulich >> >> Actually no, I withdraw this. It makes little sense to update ... >> >>> However, ... >>> >>>> --- a/INSTALL >>>> +++ b/INSTALL >>>> @@ -33,8 +33,8 @@ small subset of the options. Attempts to change other options will be >>>> silently overridden. The only way to find which configuration options >>>> are available is to run `make menuconfig' or the like. >>> >>> ... I don't think what is said up from here is quite right. As a result, ... >>> >>>> -You can counter-override this behaviour by setting XEN_CONFIG_EXPERT=y >>>> -in your environment. However, doing this is not supported and the >>>> +You can counter-override this behaviour by setting CONFIG_EXPERT=y >> >> ... just this reference, when things also work differently now (?). (IOW >> the original description ... >> >>>> +in your Kconfig file. However, doing this is not supported and the >>>> resulting configurations do not receive security support. If you set >>>> this variable there is nothing stopping you setting dangerously >>>> experimental combinations of features - not even any warnings. >>> >>> ... some of this is also in need of updating / correcting. >> >> ... may or may not have been correct when it was still an env var.) > > Thanks for taking time to review this. > > Perhaps it will be better to remove the entire paragraph w/ original > XEN_CONFIG_EXPERT then? > > E.g. there's a brief note on EXPERT in SUPPORT.md wrt security support > and it feels that there's no need to explain that EXPERT mode may lead > to some bad config in general... I wouldn't mind if this and the earlier paragraphs were dropped, but others may disagree and prefer them to be brought up-to-date. Give them a few days to voice opinions. > I just wanted to resolve dangling reference to XEN_CONFIG_EXPERT which > I hit after reading through upstream xen yocto recipe. I understand this, but leaving incorrect information isn't the way to address this. Jan From xen-devel-bounces@lists.xenproject.org Fri Jan 09 12:43:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 12:43:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198715.1515553 (Exim 4.92) (envelope-from ) id 1veBq3-00018b-50; Fri, 09 Jan 2026 12:43:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198715.1515553; Fri, 09 Jan 2026 12:43:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veBq3-00018U-1m; Fri, 09 Jan 2026 12:43:35 +0000 Received: by outflank-mailman (input) for mailman id 1198715; Fri, 09 Jan 2026 12:43:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veBq2-00018O-AI for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 12:43:34 +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 ce9c1993-ed58-11f0-b15e-2bf370ae4941; Fri, 09 Jan 2026 13:43:33 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-477bf34f5f5so32925055e9.0 for ; Fri, 09 Jan 2026 04:43:33 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d865e3dfasm60900445e9.2.2026.01.09.04.43.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jan 2026 04:43:32 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ce9c1993-ed58-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767962612; x=1768567412; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=yZRvtd/m/5Q+hq2CsSefDSu82I5hnUU0ayplgVRq1o8=; b=KgNkIMadiTPi/EaEZEYRp36p9D7icOnC0/afUDVOV8VMe3HVjGHz1zePYDzVfedaEE i3FnK9U8KNXWgpsOIImemSxcNLzxZCJaNlvupciOoUmnf90qfQLpv4u37ftlK3cN0RSq GvZTjcH0NDa54INOosl4VF9qSKPCKm/FkKgnMFRCKBsOSXsZQ/c/D+bTUEm3uZyEES3n zyeCsOn8DrcRRUrPcHoUufklS8D0tuFxuV48U1QdiGMtMWjquso1WuYM3Ww2KOa1dyr7 pAWxT1SyPhiPY2b59cgwgTChnO7N2qNNMvmE0erpUFxHoWDW+vZbVxDF3mvvnpntdGDm ApFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767962612; x=1768567412; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yZRvtd/m/5Q+hq2CsSefDSu82I5hnUU0ayplgVRq1o8=; b=jotTZ9M8JrNA1vT1tz7Jlppddgp5jyylNibWymS6GGgqfgUiwudqt8u/GtN7fbrTR5 OWLWaEyzflG6ubNxT7sXju52EnvcEu1wjnmqf0Ge3xhOJqV52zRfmVNxwSx2zboAspnO GxdhpCoSEJWybQvsp4SaVozkt5XAqU+iPyv12Y9J373obKMFf/VtDlwQ1jajvFv8gsmp A8AK/lATfVixbCFTEpmT6u1VGVhXJgGokA6tnLALbgA76Oj1VMZ69VzheJZ1E1kNRng4 UeVBWCxLekGV8n/9HXyT577gYu3d1C7LP+LmYSAg4pV/VOgYTUH1mwLKQeMKNpceKzwR laQA== X-Forwarded-Encrypted: i=1; AJvYcCXMGa+uhxyP78Qh4dMYcywP65KepbbBEHhBFaL6kJRfCgBlCQF861Dy07mDv9XTEu+s93K8JrCfQi8=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx8SO97S3vPDidjAyRek03prIiG2XOB3dgHaxYeDwKhAtc3ocgZ 7RG6zdTLt2d/Cq5YFJdSc0xvZABT83JY1HxXq+ocIYZaeBej1i/s02Dca6PUNyK7yQ== X-Gm-Gg: AY/fxX4ZmXOdgfhhGcN5j5117ObDjSOWFIYbcxG07Z7ssNdAtqM6cN7r4DJlkfwrcby Ftx119N7qHTp75jO6pCXDz8cbnkvHsv/pm1S4U7QVe0jbBj4zFK+keA0ox1TtrH+7slurc60fxV TxFCo16ExoqgSuSw/DqFc3yzR3PiTA8vb7znRRDZTunCy2sbqkLYF/PxkiPpGDEUXwRiovJozjF DrDyZC7tfQMhVvx/Pf7pZj1Bq/Tl1f/lQunpzwcOyjg9/s+rEC5fqqvEt3WtJqGvcVe8daM2UGR zDR0jChp9yry11s5wUdrYFoalCCwM9GMNk7yfC7CPUP3fk2Hi6oATB2h8CcIZ/iCiDvWqmKoj2a jqkOVnA6dAtj9+wsI19xUZjQzHCopXthqWBGMXO+iX2viydG9iPsIDdkUYT+Uwquvy/GjBb5Ufe IHxLUkvNyK2743CD4AsgSFYDhPKw05m+/AX65U2afR0krQtDSTdrjw/hiHG/JjLOVsoM59RhS+o OM= X-Google-Smtp-Source: AGHT+IExfTw56uD5o8AWOhLZLu/NhV/9YxUAhBquT1hK0AzdRTcDFMpdiVqO8gb9eX8JmdKcGlSWMg== X-Received: by 2002:a05:600c:8715:b0:46e:6d5f:f68 with SMTP id 5b1f17b1804b1-47d84b1f839mr114354225e9.12.1767962612308; Fri, 09 Jan 2026 04:43:32 -0800 (PST) Message-ID: <7f73f21f-0c89-4c51-97d8-9d5d5a9d0e70@suse.com> Date: Fri, 9 Jan 2026 13:43:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86: fix incorrect return value for has_if_pschange_mc To: Andrew Cooper Cc: roger.pau@citrix.com, Kevin Lampis , xen-devel@lists.xenproject.org References: <20260109114330.2361144-1-kevin.lampis@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 09.01.2026 12:48, Andrew Cooper wrote: > On 09/01/2026 11:43 am, Kevin Lampis wrote: >> A return value is missing from this function leading to safe CPUs being >> marked as vulnerable. > > It's not really a return value that's missing. It's just that the Atom > block used to fall through into the Phi block to get to it's return > false, and this was accidentally dropped with the Phi removal. > Fixes: 85191cf32180 ("x86: drop Xeon Phi support") Hmm, I indeed screwed up there. However, the fact that there were two blocks of case labels with a blank line between them made them visually non-fall-through. Hence why I keep asking that blank lines only be inserted for non-fall-through situations. In the case here the comments would already have served as sufficient separation of the two groups. Jan From xen-devel-bounces@lists.xenproject.org Fri Jan 09 13:15:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 13:15:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198742.1515563 (Exim 4.92) (envelope-from ) id 1veCKq-0005Ha-9B; Fri, 09 Jan 2026 13:15:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198742.1515563; Fri, 09 Jan 2026 13: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 1veCKq-0005HT-6S; Fri, 09 Jan 2026 13:15:24 +0000 Received: by outflank-mailman (input) for mailman id 1198742; Fri, 09 Jan 2026 13:15: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 1veCKo-0005HM-F0 for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 13:15:22 +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 3e6c6701-ed5d-11f0-b15e-2bf370ae4941; Fri, 09 Jan 2026 14:15:19 +0100 (CET) Received: from CH0PR04CA0059.namprd04.prod.outlook.com (2603:10b6:610:77::34) by LV2PR12MB6016.namprd12.prod.outlook.com (2603:10b6:408:14e::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.3; Fri, 9 Jan 2026 13:15:15 +0000 Received: from DS3PEPF000099D9.namprd04.prod.outlook.com (2603:10b6:610:77:cafe::29) by CH0PR04CA0059.outlook.office365.com (2603:10b6:610:77::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.5 via Frontend Transport; Fri, 9 Jan 2026 13:15:15 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by DS3PEPF000099D9.mail.protection.outlook.com (10.167.17.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Fri, 9 Jan 2026 13:15:15 +0000 Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Fri, 9 Jan 2026 07:15:15 -0600 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Fri, 9 Jan 2026 07:15:14 -0600 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; Fri, 9 Jan 2026 05:15:13 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3e6c6701-ed5d-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vOhkKfafFbPjfUszG0sXbZ6gFNyaZZxA7hsP3CQvdhj3pOiI/0pHeo4M/Sv9+Pra0Bex4QkVTzDlsQQ+kN1sW6kJsFyr3LaTNPT9gZCkCQwnZ1mn+oqUP+izjuQRde5Uj3p6jh4asaIUpUDHgijKKi3Q2B/BkLA77OVlKH+qQjQIeMQuMLjd3PHzy0VmltPUkYhKEHxixpB7vZaaBLeSesrNRWgCXS5RAHIee2QtW76BAmIjFUsWpYtzi16esH+rEYSsibE6VP28YHKO0gtzFn60tDEz9nUWFYQrywpmKa4dC11s6S7C5glD0Lb1Fa1rKNgqTpFVAMPP/5a5kOunZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7u4j0eVqzsyHEcdV/QAGnaH1kJdOdx0WpRzV6JBzlow=; b=JR/0GVADUbC/EXbZCOvdY+L1Slg357sChpHkQO9Q9bPi8SW9cqRlBIsq81UoD3vk/qdARt2VKNg/oKfXKJ/hKseVgwKh42myQf8R2Vlj9rLLrz6MGZWmX8Lsrv494wklKfKeEPBdr78iBDZWIu2Nz5muVxqL39LPSXiOIslsM5I26mP+U18sUhAHUICCV8FCSus53roUH/IGLlgHsYXNswLl3M7HYhEznva6+b7Z/BB/a0n4lnmeuyiJ0dFCfODGiJ05ISQ10PFnkQRzQwINNJDe5I5r/IgGRAckxPEAwc0itAAAmuPeajWeofezhDKEs5wxvRKSBRmmwO0WLtyVig== 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=7u4j0eVqzsyHEcdV/QAGnaH1kJdOdx0WpRzV6JBzlow=; b=uLkO6bDqFAm+9xAWnNv9NQ4ij+yVbiQfgpFxnw0/qZyiirUdgJD4sP6x+xTtmhG2ep6p4zomTpoYxB9I2fH3Rz1wHgSSFZvC8kSkHAjDeRG6uJ4QXxt/WjkZbJ0qkMA9K6V0t8YHkEKCE1+1ICAtQ1CAVGCVaGIBCAwNUA8ILbs= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: Date: Fri, 9 Jan 2026 14:15:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/3] xen/arm: optimize the size of struct vcpu To: Oleksii Kurochko , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" , Andrew Cooper References: <1d7f2183bd01df92445bf37ddc9d41f8bfa0ccdb.1767803084.git.oleksii.kurochko@gmail.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <1d7f2183bd01df92445bf37ddc9d41f8bfa0ccdb.1767803084.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS3PEPF000099D9:EE_|LV2PR12MB6016:EE_ X-MS-Office365-Filtering-Correlation-Id: 837d2a5e-3ba2-46fa-b850-08de4f8120e4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|376014|82310400026|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?V3BUUnNxL1U1Q0ZTVGozejVrbEFBalExZjNiY2VGS1RibnhYSEo1M2VpZ2RY?= =?utf-8?B?N2MzWjZ4M1dFUEZTZzJpZWR5Y1g4VmxQRlNaa3dQVHc1OWN6RXRsYld5ZHRr?= =?utf-8?B?dHd2TXZjdENsR2VPSEVEK0xiNzBzSjhWYkVwNEx6R0MrUGZ2dGhZUUNSK1lw?= =?utf-8?B?RUdIRm9DRkFHM3BXWmJUajZQTDUzdE9RbUVWdk53Sjh0MG9DSngwTGc0Ti80?= =?utf-8?B?UmtMNWd5WkIxTHRGUnh3UHNjZ01wakJMblN6R2JsRlhjUHlqZ0s3TXE2M3Ns?= =?utf-8?B?UGc4ZlNyUmVOaXlvQWQ4dXVUUHRWRCs5cjdCUnVBb2EvN2hEZG4rbWIyUDZJ?= =?utf-8?B?SHVnR0k2Z3l1UUNJajRLYmZhZmMzb2x5ZXBHMTVhdXpRRGJuenREbWw1WXVS?= =?utf-8?B?MzVIN0ZyYlk3REJEdnRpeHhjUGNFV2Qvc3Q5eVAzcjZJMEFqSVFja1Q1S25s?= =?utf-8?B?dk5KeE5FTVpzZTlNSTJtSllMV01BYWM5Tm1YQzZhRjNIUm5zZ1oxS1pKVlJP?= =?utf-8?B?SnltUzduZXYrZWgvY3VqQlRJUjJYaGtyRnJwV3hLMmd0RU9VT3FJZlZMaUFs?= =?utf-8?B?ai8zSzRPY0pCTnh1WDV4M3d3dVEwRTRlbzd6VjJsUzY0ZWJ6MDk3aUpRSERh?= =?utf-8?B?cXkzQWFteDd0WDBMWlM4WmlWNnVyWHdwc0l2U3dlRTRjemNXRXEvZVpVZUU5?= =?utf-8?B?NnJ2aDdRSGRGbWRxQVVWa3NpUEJMTU13WlRrS0E5NUVqYys2aTdZN0VKMVNU?= =?utf-8?B?c3hYSWxsSDE2MU0vZEJFNVBEek5hMjkwNURja2UyTVZBdE9ObjRnWkt0M3NF?= =?utf-8?B?Nzl1ZmJRL3ZsNEZJVERndFlxNmdSMW5WZU9vTllDL3plR2YxQ1NZSzRVa0g3?= =?utf-8?B?Rmk1NVhkYU9KZFdyUG5mRWZFS3ZVbnJNRkdjYk1jSVpmSDJkNTEwRis5bWUw?= =?utf-8?B?TTBTVEFYcUNha2VEdk5wQy9DZmdIc3I1T2lxL0dWdExVSTNpT0MrTm40a2xy?= =?utf-8?B?SnlER0IvOHFBSldseWFwYjVpV0krZU5saWRlYmo4TkpjSWZWTGxnb0lLbGh6?= =?utf-8?B?M0REemtsMHM3L2NvQ1RsdDd5ZmdQRHJMUDd5NGhHUng5Y0M0TUxaOVI3MFJq?= =?utf-8?B?MnFJS0puZFZENlBqUHpuMDEzMW9JaEF4TXRZYng1RG5hZ3FPZmpOaUVGUzFV?= =?utf-8?B?L1hQOEhKYlloQmVuaHErVXo1QVFrVjFZQmVsZE1yT2o3a1Z2dDUvTkZldElD?= =?utf-8?B?V2V3VmliamlQK3pTN3JvWkYxUEQ5OHA1aHdvZXlHSElWUUZJTmN2Y1BlWXZ3?= =?utf-8?B?QmxiNkVjUktjTEJjN3o5dGRNUFJ1YUdkL0hsTGs0M3hmSXVxdEpDQS9XSWN0?= =?utf-8?B?WTVNa0RrRC84VldjTkdDZ2hxUG1hMEcrZ1A4ZGhMMFhmMi94bEpSN0d4WnpP?= =?utf-8?B?NFQ4ajM0VS81YjlKMDBHSWtyUERWMEE0YkIrTitWWWRNcVhoQVBXS3FwVlM3?= =?utf-8?B?c21Ra2hORXhEUkpyT3pSRXhCblZqWG0xMG53UHhRcksvOEx1aHRrT3AxNEp6?= =?utf-8?B?OHhvMXBPc0NSQkRZUlpheWFIRCttOEoyQVVoQUZIUlBTZ3E3eS9oUXVId2ts?= =?utf-8?B?YlBUMWNkc3pSOTkyT2N2TUQxcUlNQXFYWFlmUnA2RFNhVS9DY2UwL2RuVmdU?= =?utf-8?B?UGt1OTVZZUFCZnFlejJzS0RTVG9kbGdoZGpzdFF2aURISDcvSXd6ekFQbjkv?= =?utf-8?B?bHNDOUZkS2FHMEwrcEVwckpEQS9zNjg3R2VReUZtNlZYVGxXTHJTa051NFZi?= =?utf-8?B?eS9FNE5rZVUxOFQ2U2FGRXE3MGoxcTl5TGtzMkpGcVdYUWxnUVlUSkNNK1Zr?= =?utf-8?B?MWExNER0MmJ5T0hocFhEZVFSSm9hM0c2SmMyRTEzajdSRnI5dkx1a3FXNWE4?= =?utf-8?B?NDFBVG1sZm5sZ0JWYWI4SFovYXNVaUhud1BCa3UvR3VvYVNRbktyaEhzVDNs?= =?utf-8?B?K1I0U0w2UWRNZ2VhY0dyZkttM2VNTndnOFJlRkx5L1Bwa0ZicVBxT2RLNE4w?= =?utf-8?B?eXpPTTYvKzdBZDlKejhlaEJjZkV2eitMZXNyeFpuc0FDanJzV05UV25reld6?= =?utf-8?Q?oax8=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2026 13:15:15.3694 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 837d2a5e-3ba2-46fa-b850-08de4f8120e4 X-MS-Exchange-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: DS3PEPF000099D9.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR12MB6016 On 07/01/2026 17:28, Oleksii Kurochko wrote: > When CONFIG_NEW_VGIC=y and CONFIG_ARM_64=y, the size of struct vcpu > exceeds one page, which requires allocating two pages and led to the > introduction of MAX_PAGES_PER_VCPU. > > To remove the need for MAX_PAGES_PER_VCPU, the vgic member of NEW_VGIC's > struct vgic_cpu member private_irqs is changed to a pointer to struct > vgic_irq. > As a result, the size of struct vcpu for Arm64 is reduced to 2176 bytes > in the case when CONFIG_ARM_64=y and CONFIG_NEW_VGIC=y, compared to 3840 > bytes (without these changes and with CONFIG_ARM_64=y) and 4736 bytes > (without these changes and with both CONFIG_ARM_64=y and CONFIG_NEW_VGIC=y). > Note that all numbers are based on defconfig with the mentioned options > enabled or disabled as specified. > > Since the private_irqs member is now a pointer, vcpu_vgic_init() and > vcpu_vgic_free() are updated to allocate and free private_irqs instance. > > As struct vcpu now fits into one page, drop MAX_PAGES_PER_VCPU. > > Suggested-by: Andrew Cooper > Signed-off-by: Oleksii Kurochko > Reviewed-by: Andrew Cooper > --- > Michal gave his: > Acked-by: Michal Orzel > But wrote to MAX_PAGES_PER_VCPU in this patch, so probably he would > like to look at how it was done. Looks ok, you can retain the tag. ~MichaL From xen-devel-bounces@lists.xenproject.org Fri Jan 09 13:16:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 13:16:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198751.1515575 (Exim 4.92) (envelope-from ) id 1veCM1-0005lp-JE; Fri, 09 Jan 2026 13:16:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198751.1515575; Fri, 09 Jan 2026 13:16:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veCM1-0005li-FW; Fri, 09 Jan 2026 13:16:37 +0000 Received: by outflank-mailman (input) for mailman id 1198751; Fri, 09 Jan 2026 13:16:35 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veCLz-0005ji-LM for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 13:16:35 +0000 Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [2607:f8b0:4864:20::102f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6ae59f5a-ed5d-11f0-9ccf-f158ae23cfc8; Fri, 09 Jan 2026 14:16:33 +0100 (CET) Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-34f62e71769so496443a91.0 for ; Fri, 09 Jan 2026 05:16:33 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6ae59f5a-ed5d-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767964592; x=1768569392; darn=lists.xenproject.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=BgvTqzeSjXT31U6pknG/MiPGWoCqcBMZzzA9zGh77GQ=; b=ifeMD7gVcD8EMxehCzPA6FPZauzSSfUBVaa6mYfzkPKK6TYFg/R6yBi5Gc9AdBWTwU Lb7+5PwJ8A631frJzJaF1rH0/Yz7N4N0PgwZ2A4+ITSbOEHSfVa6f1dMmTEGE+W67Lvt //Ca/HjdZoSe3lR/3eEiOdz/isgB+vQgGKRhCvXILnlHsPNgdLsPhJzKkz6EYaGNexRl 7K0CZnexwLklAVA68f/NwbSHNAUBBH5psSvB7rZT1kOqQy5u5ZWZ/5PNB5t3MEONh/7T atitxeDpY5kjYAjvD7g6jmhF+fsYUuZ2vD+3qMt+5+6B3fPeaeQRh5iI/KZCEyR4VdeF LyDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767964592; x=1768569392; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BgvTqzeSjXT31U6pknG/MiPGWoCqcBMZzzA9zGh77GQ=; b=ktbStaxA5EFzRDRC6HezvmvQvL+Zf8pPjEUBSXxERHj6d0ValjAVEe2i4wGbU9Nadf uje4zklZBajxyTsbgPiHt+zhmHeONPFra99j/Qkq/B96zayq2b1KnxZyEQnT2MJLeAqe zeDAAK7P6LLNWtb6+JRdwJejC91sn3qjiSD8G6kEmcl6BWxFoQ6EN919bzqzaxg4sVKK VkuuyWdqy4FpwBZxGFAzlzdhcg6s8TrfGtXKsU35Uk0xeOiKg9/otZeZM42lt9ELLpZL FUbqaTaJe23dAQYRenAlZEejQPrvWlAuNuL3PJPXLUvqOfz9xQrpWC+6LIuDBQfGGyQc cvcA== X-Gm-Message-State: AOJu0YyEBvJyKC7+cEnHKITNxFcf1jneH3URVKL9WgbrAWEKpF+Jiytv 6or6Cb8PO0VV2dzh5f12yB2GbwNJww/a7SpOPFRuPcT5ZP78i0vGp+zvm1lN2OXHie1sZWWwdKq PSoAUcKtqAbo7bf3Yo651Dev/aSyfgPDLa6WG X-Gm-Gg: AY/fxX5LaMPSfVzeIIwFMAJveufbuAKoLxxzaaDuDqRQ3fjNjXprtGaXmNRKWCTMcKD rrelero2Cx4slFlUGNPadzmJ2yYQwI5wRgmq/nEeMiNeJBLlpTElTp++AzgArQFY49bmCHcgiQn ev61iFX3+S1YtLS+cA+g7d5wnlRvBJS/XfWD5BVMaDLXUzB8U8zspUZ8//E93yIfpyD1OpkrkEb 0TwogvQtDUTWQCIMccQieYfKZPgQUrMEtoLExAC85L/HvOvKYaXkWwU210OBcYV8sQQcQ== X-Google-Smtp-Source: AGHT+IEU3DlGDx9ojU+Rvf1Pl0EZloHCsR0BBiJ1SfuceVsAgIpJdofHEnpLXm4HpFsbU1Hd84qjEZyhBzp3VN2aakI= X-Received: by 2002:a17:90a:e706:b0:341:8bda:f04b with SMTP id 98e67ed59e1d1-34f68cd1fccmr6084490a91.7.1767964592067; Fri, 09 Jan 2026 05:16:32 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?Q?Petr_Bene=C5=A1?= Date: Fri, 9 Jan 2026 21:16:20 +0800 X-Gm-Features: AQt7F2oRce0KZKMFpZgHnNBXthOJOPhcQJGlwS4rIUZGEyZ2dldlV3w2hu5hh8o Message-ID: Subject: Resuming with superpages broke VMI/altp2m workflow To: Xen-devel Content-Type: text/plain; charset="UTF-8" Hi, After updating to RELEASE-4.21.0 my VMI tool stopped working. My VMI tool extensively uses altp2m and sets specific access rights to various pages in the alt-views (e.g. X-only rights to achieve "invisible breakpoints"). In RELEASE-4.21.0, I noticed that the memory-access events were hitting for nonsensical pages. After git bisecting, the offending commit appears to be 50baf2d (tools/libs/guest: Use superpages where possible on migrate/resume). I don't think the issue is really there - reverted VMs work always fine. Instead, I suspect the issue will be in incorrectly splitting altp2m superpages, since the issue always appears after manually setting memory-access rights for altp2m pages. Best, Petr From xen-devel-bounces@lists.xenproject.org Fri Jan 09 13:16:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 13:16:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198752.1515583 (Exim 4.92) (envelope-from ) id 1veCME-00065R-OW; Fri, 09 Jan 2026 13:16:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198752.1515583; Fri, 09 Jan 2026 13:16:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veCME-00065K-M2; Fri, 09 Jan 2026 13:16:50 +0000 Received: by outflank-mailman (input) for mailman id 1198752; Fri, 09 Jan 2026 13:16: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 1veCMD-00064g-2E for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 13:16:49 +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 72d3c20c-ed5d-11f0-b15e-2bf370ae4941; Fri, 09 Jan 2026 14:16:46 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-430f9ffd4e8so1460918f8f.0 for ; Fri, 09 Jan 2026 05:16:46 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0dacdcsm22423033f8f.1.2026.01.09.05.16.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Jan 2026 05:16:45 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 72d3c20c-ed5d-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1767964605; x=1768569405; 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=5VfkchlJ/9TrBejggw+pB6naFdzYvQ/o4hvcC4styY0=; b=H4theXJjxuwEqTgBtuZMlKlhHlT1v8+0IsioPuG7Bvf3GU7y24y5sx5szCUP0s7OwC ZqgP/KEATzSihA2wDNYQlqkI15bjFCehBDmDd+3mAqnHcpaKM3Z7i6tb0NgL3ygr4Ty5 iO/kTldmvYSILGPQ2YeBk8cNgZYfEv8+Gi0ro= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767964605; x=1768569405; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5VfkchlJ/9TrBejggw+pB6naFdzYvQ/o4hvcC4styY0=; b=KooV2i5p66dslnW27MFpxlutKl1ZL8v3vkGqnmYidESPNtkUPusWjL0HFNlTwzclCt FBIEp7dfu2JExqvSpDURtwtcKI1Xc9RfYI0q4zb1leLKSyEZBvoq1wDkdoVHuKlESxvb eSo9CXe+zjnKylykecsgWsbm8xW/+p+wOJOUg/7d8skLsVtQwGt8UgU8rOeNbXBX7Ulm 9TRQhUiBIY0VWLLXKlVxI+UT5U0irpd1uKyLKhDo7DNbZFXblge8ymQTiLT2Zu+GnszQ 3bgrmDH+2S1oOvCpmAOjjv1nbvZxvB7HMX3plAkLkBlPbLrN1okAihYn362J8VroCWXC MVaQ== X-Gm-Message-State: AOJu0YwitiX3zxXxw/CSvaaoZYjvU6BiVM9esM9xKYHLKFNyOOD+XaAi AwNBFNyMiGnYUu7unK1CYuQbCpjEKWQ9VEIjI9TqfAQALhsru8lPycsNdJrgIsBX+gIYwHQ504k MzG62 X-Gm-Gg: AY/fxX75tmfhLEPrbuKl7fQqZj8J31B8JrkM63LCMh/rEuYxYMG7TyMLyZ3O49aKtoH 7BLd4t8yIXMyxCREBF/U7aRUsDjEyG+N/SSTN19X+qd5fy2/6VSGTME5dQtB9oCDLE87PGQ+VFs c3D4MzxXrWSNDyWRvTs0Sx75Moc+C3qqqpErbX+PAteThM5BOZLof3ljty7P3WwIrlWpJCEQw6K 6cFB95bUZXtM50e45EEt5+3962pwFhDUmYnndWvrSWy1vzhufykYcxk+LTL2oJ198fHSo1Lsa4T pCO8q+SXC8GOPf9AhkXERo0EG9XBTc01gNJULqtHtw8gz68ApR7+ntE4x6xT5tue7gZsNPqnlJD N+bioP+XYPgHxN5GmlpqxRTASctKgaoENeLzQpSIwRQfW+bSyPvJmNkgasNmpWkXORuzid+KBza 6HsQr+xL5/DL2+kWbtMvZeH2Dorua6wHHXr/pdDYZEkRrarbYaZguPxd6UMQmhKA== X-Google-Smtp-Source: AGHT+IFNv1UR8MFvAUVKR1eJ1Q1ff206ybolzcabnGhpA5DKWETAsojYJXQukJ8a5/JxYdlI1eO+WQ== X-Received: by 2002:a05:6000:2c0f:b0:430:fca5:7353 with SMTP id ffacd0b85a97d-432bcfa1031mr17037740f8f.8.1767964605471; Fri, 09 Jan 2026 05:16:45 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Juergen Gross Subject: [PATCH] xen/gen_hypercall: Leave a breadcrumb in xen-hypercall-defs.h Date: Fri, 9 Jan 2026 13:16:43 +0000 Message-Id: <20260109131643.859509-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 When Cscope-ing through Xen, one occasionally finds themselves in xen-hypercall-defs.h and needing to find the originating file. This is substantially magic, and even reading the Makefile that produces xen-hypercall-defs.h is of little help if you're not aware of of the %.i : %.c pattern rule, and that the header is generated from a .c file in practice. 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 --- xen/scripts/gen_hypercall.awk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/scripts/gen_hypercall.awk b/xen/scripts/gen_hypercall.awk index b544fe1c4df7..c137f8fc4e6d 100644 --- a/xen/scripts/gen_hypercall.awk +++ b/xen/scripts/gen_hypercall.awk @@ -4,7 +4,7 @@ BEGIN { printf("#ifndef XEN_HYPERCALL_DEFS_H\n"); printf("#define XEN_HYPERCALL_DEFS_H\n\n"); - printf("/* Generated file, do not edit! */\n\n"); + printf("/* Automatically generated from xen/include/hypercall-defs.c - do not edit! */\n\n"); e = 0; n = 0; p = 0; -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Fri Jan 09 13:17:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 13:17:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198764.1515594 (Exim 4.92) (envelope-from ) id 1veCMh-0006i9-22; Fri, 09 Jan 2026 13:17:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198764.1515594; Fri, 09 Jan 2026 13:17:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veCMg-0006i2-Tr; Fri, 09 Jan 2026 13:17:18 +0000 Received: by outflank-mailman (input) for mailman id 1198764; Fri, 09 Jan 2026 13:17:17 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veCMf-00064g-FG for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 13:17:17 +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 84b3824c-ed5d-11f0-b15e-2bf370ae4941; Fri, 09 Jan 2026 14:17:16 +0100 (CET) Received: from CH0PR04CA0056.namprd04.prod.outlook.com (2603:10b6:610:77::31) by IA0PPF12042BF6F.namprd12.prod.outlook.com (2603:10b6:20f:fc04::bc8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.4; Fri, 9 Jan 2026 13:17:11 +0000 Received: from DS3PEPF000099D9.namprd04.prod.outlook.com (2603:10b6:610:77:cafe::9f) by CH0PR04CA0056.outlook.office365.com (2603:10b6:610:77::31) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.5 via Frontend Transport; Fri, 9 Jan 2026 13:17:11 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by DS3PEPF000099D9.mail.protection.outlook.com (10.167.17.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Fri, 9 Jan 2026 13:17:11 +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; Fri, 9 Jan 2026 07:17:11 -0600 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Fri, 9 Jan 2026 05:17:11 -0800 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; Fri, 9 Jan 2026 05:17:08 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 84b3824c-ed5d-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Bd/3U2e5NZXTp4a79zwf1Ev2TzQN6g1ZqB/vlKjWADUqoCaD/TYBj6OCqv0qGEUDsyYHljc2SZ+JWyttW3RO1TTJzlcbNi7++K1puwSKY8Bhbig/T/Qc1w7+2HAU1eMfcasHbJe29xyF/3BkZL4I4h/ZUeZNjdl/D3GTQrhdNHykZ8zd+1Gk3/Nfo3MTGeNZmqZ74KfG+O4h9+e6l3Wu2zyUxqVTGe9dRO97q5ppD431bYfM18V3V6Hhnaz3xDWSvW81eSD69Oq7G2roBqBZpNeKEQ6UsPpMrOYTsg9CRX5HonOBTCTx8TUTMCwXJ748fmq9aWJZ3hTUgoWEw3zQaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PXzj5snBkHhZomySM8tnBeVK9MbSz5xlbWA1TLEawqs=; b=uf34DKLDmtxDCcEgOlwQdXL3IvNgdrjiciCjS/iW4W3dtz8f9ggTelkitMJ3tO5HqdIzyPI8MgA0Ip/l3i/XqFH1b+WsFnqTEqSpc9fpadEVRKruTkKJgPoKSS2yU97+wimNjTdzMnVrbWYP3fBBuhH53L08B8vGwQz+XqFpYMo5MA9iQT/Po1IK705IjdYMj/UwCwgGNWJZugorXk2avvN+Gl2GC8OKJNsQPBqufFIQyCaqEN52XsQiphm2aafV74iX3NlBvL4s/s3F/GmcEJVGgGoEqXF8uR0R0qZOa/DUtyMQh6TVogpKVTTFtTp43ca2Ym0bGyKpHiknD4tppA== 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=PXzj5snBkHhZomySM8tnBeVK9MbSz5xlbWA1TLEawqs=; b=Hto/FGQd3DZ76hHswATxL+7FPtUk3naQAgKtiFEeKuNlRJotn1jJhNKKvnGXqtOp5fChTd+IDPrevLebZQyS5AzDdX5quEFGGO0U7tcGCocJKcNVA2qncfeB4oJfzFjFV9m1IuyLA9dMM73MWIfX+IgBiceO6CWRcaWDwpDy9AA= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <4b2e9f4c-ce8e-4090-afd5-45af183b9497@amd.com> Date: Fri, 9 Jan 2026 14:17:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 2/3] xen: move alloc/free_vcpu_struct() to common code To: Oleksii Kurochko , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , "Volodymyr Babchuk" , Andrew Cooper , Anthony PERARD , "Jan Beulich" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Timothy Pearson , Alistair Francis , Connor Davis References: 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: DS3PEPF000099D9:EE_|IA0PPF12042BF6F:EE_ X-MS-Office365-Filtering-Correlation-Id: f711b839-d560-4e4c-72cf-08de4f81661a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|36860700013|1800799024|82310400026|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?SHlHN0djMXBZWHlpZU1saGJEdVpLM2hrNitWaTlvZGcwV0k2Qm5NRUpQdTlL?= =?utf-8?B?SUNiQlR5eW9oZ3NmVWVsTG1XOTdIQkc1ampvUllwNUJIWTNsbm1YdldWdzVG?= =?utf-8?B?YzV3cWFaUlFhLytuRFFJWkVmWlNWSUJlWGszMmx3d0VGSWxkZ1JlQWJ3TW1V?= =?utf-8?B?ZXc5L2ZBeFBhdk1DWU5CRE05Mis5bVlzZm1DQUFabFFrU1BFckxmdWtuUFBJ?= =?utf-8?B?SnA5VHlmZjZEYnVFNjNtM0N1dnQ5V004OWlZV1hiWEw4QzVmcjdIK2lOeGRD?= =?utf-8?B?S2VmTmV0dERzWEYxWFg0MmM1cVB3UFpaVURUajJJUlRoZmxQVnhScm9GL2ZL?= =?utf-8?B?UFFNYzM2UTEwRk5aZ1NXaG1IclBBTkhDVmRwZUZoaHVieXdzWU9uZ1dsdE1t?= =?utf-8?B?dHN6UFVoSDdhdXhJQ2ovZ2l5Y0Q0Sm1aNno4S3pTRkpSUDFJcXAzeVA1Szcy?= =?utf-8?B?eGJyZTA5NDZYa21rNmw1SkJPYllHdjgzNEkzYnpZSElmWVAwdENsQ0RqUmJr?= =?utf-8?B?N1JEdzVxSzZXTzEvU2duTStIQ0UwOU04Q1BHV3h0N1BjVERnaHYyZkRjYTJu?= =?utf-8?B?QUNoQnd5ZjJWZFVPOUFKTmFHYXlXQkZDLzlwN09rUlE4Y09pZlFaNWdDQ2p5?= =?utf-8?B?Zm5PTEpVbHBualRhVFU4VmxzNDFGQ2JkakpNcHNEU1RYZm90SmJkMHJJd1gx?= =?utf-8?B?ZGRncVdpeHhkOFVjK2grWCt6Z0lpckx3M3d5K1AySmlOdjE2WSs4SGltL2Qw?= =?utf-8?B?QmZKL1FEM0IrUW4wWFFuU3p2WHh2aDJTVmcrK3lXTWxvMzM0T3ZHWDRoU0ZX?= =?utf-8?B?YmsxYzVGZGJNcXNBTFdadm1yZ0h1SW5aM3FNZzN6dU5xQkhXSnJkWE5QMEVo?= =?utf-8?B?YmEvQWR2Mmd6NHp5NUhLeFdVem1zenJZVGZIOTJ4NnplT1FiMXF5Qklid0Jh?= =?utf-8?B?algxb2MxQ1U0RXpFVGhqejB1RkZhL2hNaEt4STJXdkJqUUFzQkV4M2RMTGNy?= =?utf-8?B?bXQ5R1MvSC9FS1pRd01BMmZwcGIwdm82YzArWlBHb3F3eHlqQWNwZ09IREZI?= =?utf-8?B?ZFhEdFFzeE1wYVNNNlBjcE84UnFKK0JyZU50S0pseExpbWl4Z1N6MTZ4cGFZ?= =?utf-8?B?ZGZqbTlzYm1OWEkxNDc4MFlFY3BlS1dtV0Q3ODFhL245aFByMnJwRUpsUjcv?= =?utf-8?B?Tk1Zd1F2ZlpRTzQ1RjRNcE5LcER1M0VDbno4c0FMQWJlZzhZSFFTZDhMY0J4?= =?utf-8?B?UWdacC9XMiswL2tjaFlRNEt6SjVQcDJxeVREV3FYK0txUTVWaVpHdHZDTzJV?= =?utf-8?B?aVl2RGExTnFLQ0JUcDI3VFR0UTJWbDhTamZFeGFva2RNTVpVWnBZaElidnA1?= =?utf-8?B?SFdKT0J6THBCc3pMTldEUzBGTkx5c3hxSkhhVlliM3FGNmpUSGVnQ1c5VmlH?= =?utf-8?B?MlYvZHBNQkREZ0xvR1lEQk9EZldTMVV1bU5jMEsrb01UeW1WZjJ5VlhVYTh3?= =?utf-8?B?Uyt0Mjk0MWwwOHdvRERmajAyTXlWNlhmZUZmTWNESkMzZnJQU2wyTE84M1hD?= =?utf-8?B?UE03Y2pIUngxWmxoOVBlRmpGRzFTazk3RTlpOHVBZnppUXkyZWlhaUthNVRh?= =?utf-8?B?Q0grOElFcENtcUxoT0FKMTJzdE5XbkVNUlRRQWsvZlNLQmdFcmRvemdHcm9o?= =?utf-8?B?aUF1NG5zU3NUcGhoRW03aTFtNWMzL0t2QytrV3gxQVJHSXZWc0VUVDNNNWlp?= =?utf-8?B?bUtlUzFwL1dIRlBHZFRQNUp3WS9ObFhoT0JCQjF6c2xPd3Y2ZDMwQ09zRW5O?= =?utf-8?B?T1VyQkF6OVRpZ2lSY1hDUjJGZUNiZ3RlaGFCVXAxRVlsTGErYjhnWVpHQUw5?= =?utf-8?B?anFnWGcwckRDYWhkcm45OVRCMVZ4QXVUbE9BZWhaRGNyZzJTK3R3MVMydTFX?= =?utf-8?B?c282WGdKcUtCRVRvMzRXbTJEbitEd2NaV3p4RHdmMWNIVm94Qm4zMm5ORHJQ?= =?utf-8?B?VEZsdUNxalQwNkp2SmwyMmo3bmJFWFczQ3NlOGFScndKcDRIKytsVVBKV2dr?= =?utf-8?B?ZURpYU91ZWdYalAxbWR6ZTJXTkJCQnR2UXVkU3V0NUpoUERMNEs5RUt4dWlw?= =?utf-8?Q?NlsE=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(376014)(36860700013)(1800799024)(82310400026)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2026 13:17:11.4834 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f711b839-d560-4e4c-72cf-08de4f81661a X-MS-Exchange-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: DS3PEPF000099D9.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PPF12042BF6F On 07/01/2026 17:28, Oleksii Kurochko wrote: > alloc_vcpu_struct() and free_vcpu_struct() contain little > architecture-specific logic and are suitable for sharing across > architectures. Move both helpers to common code. > > To support the remaining architectural differences, introduce > arch_vcpu_struct_memflags(), allowing architectures to override the > memory flags passed to alloc_xenheap_pages(). This is currently needed > by x86, which may require MEMF_bits(32) for HVM guests using shadow > paging. > > The ARM implementation of alloc/free_vcpu_struct() is removed and > replaced by the common version. Stub implementations are also dropped > from PPC and RISC-V. > > Now that the size of struct vcpu for Arm64 is smaller than PAGE_SIZE, > MAX_PAGES_PER_VCPU is no longer needed and is removed. > > Finally, make alloc_vcpu_struct() and free_vcpu_struct() static to > common/domain.c, as they are no longer used outside common code. > > No functional changes. > > Signed-off-by: Oleksii Kurochko > Acked-by: Jan Beulich > Reviewed-by: Andrew Cooper In case you need Arm tag here: Acked-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Fri Jan 09 13:18:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 13:18:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198779.1515603 (Exim 4.92) (envelope-from ) id 1veCNZ-0007VW-CQ; Fri, 09 Jan 2026 13:18:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198779.1515603; Fri, 09 Jan 2026 13:18:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veCNZ-0007VP-9q; Fri, 09 Jan 2026 13:18:13 +0000 Received: by outflank-mailman (input) for mailman id 1198779; Fri, 09 Jan 2026 13:18:12 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veCNY-0007TV-ME for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 13:18:12 +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 a51a27c7-ed5d-11f0-9ccf-f158ae23cfc8; Fri, 09 Jan 2026 14:18:10 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-47bdbc90dcaso31256745e9.1 for ; Fri, 09 Jan 2026 05:18:10 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f410c6csm220118875e9.1.2026.01.09.05.18.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Jan 2026 05:18:09 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a51a27c7-ed5d-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1767964690; x=1768569490; 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=kl0mcpss+Yj4Rz2fFKzFGghxaUBOVqZE+VeCnWQvcfk=; b=Vcwx4iAsIS2X2+v1F2fIB98uGghLlfUfw/BF0wXMONF/ER+RzN3XE3Ebe0Kql+VlV5 j5rxm1eco8Vjn2VFg0E+eQUXnivvTkXYYnE67UMyJwiPUyTYTDmi24zvmvlLCA+B4vWI hAgkmUofxPcWDOe0Wz2GZdN9OhUebfCPolwtk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767964690; x=1768569490; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=kl0mcpss+Yj4Rz2fFKzFGghxaUBOVqZE+VeCnWQvcfk=; b=QEH/+UMYrfg6VHj9ZNfauWbkGUBbpQPON4sBEDOx4bp3QcPCOkD0tm6+hXBkjEvcGe LrSthNWW4AYBPBsNJKqC8Glt3jjc247AGF99bDjQ7iQnkXReFSvHrqHO+qbOUh5FHNMj L/42xuWFzIwRLtnMDoYv7k3iSEX+tXJ/GtEen5KFsk8yHEm9w+jt8ivgjDfDsvcELtQg Cjcy62kwKqoQthDDIMrauGOoyZLtSpjxXiORFQDZvI212ZGPV0NPHwFIr3By93IhI/XV j4+NQMwyQO1gWT9CqLKofUOCUnAgscGUQpEXAQK8CPZE5szMvzdl+9DdbU/VvkPbu896 d0QQ== X-Gm-Message-State: AOJu0YwB3pdGHJ+R0C041B+NbEdyOMDboBAxY6AsKZw4SpiwtMVhL7sT Ev+wVeh97pCLLhQxt/0BwX9nrXQARP32Z4TscYqyAGw4ZIF7Mlvv4393iHOBi/b962qX5qwqDk1 6qlxx X-Gm-Gg: AY/fxX4heGbWVwYXKCIE0qahjC0Z/Hlt9MuwhLM+wrbPPxtnZh+I92NCGDWxG32flWg iMJ3Byjmopnicmhkg0oGcj3T6n6cgjFqWqcU5LhOGUX6T/Q9Ot4/OI6FMdU5+c6OXzLVnAncMuj 9aAMh8DCvzzUGa9XiiGOMOdPsVnGlgm2pNQcNvjpTJ1yP+iOi0QnRinM7HRopOqDBvllcV9b7uT 837I6/pGZQ1qIex0oqwT8rXkL65SSwmrHAOSKyBjCTRDyOsRSzX/mlaGkakyRBmHx7caKkjz6K+ PVkXQ3ZFqKhij3mRzVn8qcP+tMleG7lqwv05WNd6AQ7/C4CZrIwvwEqrFM3i6Vs42noX/QPoHDL lbKGICkbXj3KrnCM5c4TVqb9lzlfQMKHb+8dCccGoz1CSSKG7NrOy0he/g3xcN/DbNCMgRwR0PS qr/EwI/Mb2p73vs05YVmYQxZrhNGdPDvXmKdbwTiFYhGr2laPE6KuLi12gFswxzw== X-Google-Smtp-Source: AGHT+IEXUKxQNnEmVexB1DU52hvk7oO4A2mDEWWZHwxmA5zZxAy2XWbblqpu5X95eNW3Qo+lEvjcNg== X-Received: by 2002:a05:600c:190e:b0:477:7c7d:d9b7 with SMTP id 5b1f17b1804b1-47d84b4099amr111919755e9.33.1767964689909; Fri, 09 Jan 2026 05:18:09 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , "consulting @ bugseng . com" , Nicola Vetrini Subject: [PATCH] MISRA: Extend the R3.1 deviation for URLs to include git:// Date: Fri, 9 Jan 2026 13:18:07 +0000 Message-Id: <20260109131807.860397-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 xen/drivers/passthrough/arm/ipmmu-vmsa.c contains a git:// URL in a block comment. This is also not an example of commented out code, so shouldn't be considered a R3.1 violation. Extend the regex to include git://, and swap hyperlink for URL in the associated documentation to be more precise. Signed-off-by: Andrew Cooper --- CC: Anthony PERARD CC: Michal Orzel CC: Jan Beulich CC: Julien Grall CC: Roger Pau Monné CC: Stefano Stabellini CC: consulting@bugseng.com CC: Nicola Vetrini https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2252341951 --- automation/eclair_analysis/ECLAIR/deviations.ecl | 4 ++-- docs/misra/deviations.rst | 4 ++-- docs/misra/rules.rst | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl index 7dee4a488d45..30c323906924 100644 --- a/automation/eclair_analysis/ECLAIR/deviations.ecl +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl @@ -58,9 +58,9 @@ removed by the compiler, the resulting slowdown is negligible." # Series 3. # --doc_begin="Comments starting with '/*' and containing hyperlinks are safe as +-doc_begin="Comments starting with '/*' and containing URLs are safe as they are not instances of commented-out code." --config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*https?://.*$))"} +-config=MC3A2.R3.1,reports+={safe, "first_area(text(^.*(https?|git)://.*$))"} -doc_end # diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst index 0d90f5886e7e..17c21537f286 100644 --- a/docs/misra/deviations.rst +++ b/docs/misra/deviations.rst @@ -117,8 +117,8 @@ Deviations related to MISRA C:2012 Rules: - Tagged as `deliberate` for ECLAIR. * - R3.1 - - Comments starting with '/\*' and containing hyperlinks are safe as they - are not instances of commented-out code. + - Comments starting with '/\*' and containing URLs are safe as they are + not instances of commented-out code. - Tagged as `safe` for ECLAIR. * - R5.3 diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst index 4e9425188742..b3e929307d51 100644 --- a/docs/misra/rules.rst +++ b/docs/misra/rules.rst @@ -143,7 +143,7 @@ maintainers if you want to suggest a change. - Required - The character sequences /* and // shall not be used within a comment - - Comments containing hyperlinks inside C-style block comments are safe + - Comments containing URLs inside C-style block comments are safe * - `Rule 3.2 `_ - Required -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Fri Jan 09 13:18:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 13:18:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198786.1515614 (Exim 4.92) (envelope-from ) id 1veCOJ-00081n-Kd; Fri, 09 Jan 2026 13:18:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198786.1515614; Fri, 09 Jan 2026 13:18: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 1veCOJ-00081g-Hm; Fri, 09 Jan 2026 13:18:59 +0000 Received: by outflank-mailman (input) for mailman id 1198786; Fri, 09 Jan 2026 13:18: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 1veCOI-000818-O5 for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 13:18:58 +0000 Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [2607:f8b0:4864:20::1032]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c03da016-ed5d-11f0-9ccf-f158ae23cfc8; Fri, 09 Jan 2026 14:18:57 +0100 (CET) Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-34b3f61fd0cso362338a91.0 for ; Fri, 09 Jan 2026 05:18:57 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c03da016-ed5d-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767964735; x=1768569535; darn=lists.xenproject.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=6t/Cifft840y39/XW/BuBtpWahZrOOLTBzsSlfmHR0A=; b=VGiHgJbXauEiZpRQO6gVCCPNhvcvuXMUI/7wIi6i9soRcdJWYlfDbNtiL3F3dPNK3j 4CUgFVyTz9RTSVBQgLO5qYRyi7lnDiJ0M8OlaIUFocSrdDEcdnhMTZbVeSQg0N8/WpvY YrXsJw8qShx2y9e/gmCpe+Z6qEKZeosxXXWNAy13VEzgO6DFJqabRsI1bCnAnv3AO5Uu aeQeitnbNB18OhCs0aXF6REXSnbnXi6dUeFTMyIbwUN3+VYSktFnk9sXlX/OFjXvRo2t 3hUmZtN9d+WyQkCayyHGfkDi4dSJNuZEQWiwBzr5eBI5yMpEddXSc/es0nn6E/qCGAOk K4Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767964735; x=1768569535; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6t/Cifft840y39/XW/BuBtpWahZrOOLTBzsSlfmHR0A=; b=YXKhowGpA5RDwLEmLEUURNjtUmNSGC77i1asQ+Zsjx0NgbkCBD+H2rNuQLyfPhLCFR OxcgNBoPsipIV/1SzH4sWzlrohblKL4764igafVaGtLdNFO9z1uvCjOh+41FGfl6I+Oz klZgHoXc2t0gNQJ4DgaNAVfKyPKC6IwNLOzjW7woMG7k0+PY+BNX26eNT+LN3Uwm5BOs Sm1w5VxTfVypVoIfZeR023YvMnKYenvGvJYMSeF0MrqoumHjhv+re/EL492+aECT0Wck gu900VqE7Q4PnEKDIEWAHx1TgtgNKI7WG0N6hiTL3VtAID9oD3vL94DT/Zbgl5+jldtN 3qKA== X-Gm-Message-State: AOJu0YxFtbx2W5ccKtBd4mArMKaw5ZcqSdZ+I6Hb7wryEURJQ4ZC5aHB xVqrFIP7+5Fq2Wm/L4LdAsiPkXbaKgpvQQTZzvNLYbnOabEQiIclnbfguqwaiWGee2YbewTVIAl Pm8L/OT8pG6fQJUx6DY1bvw3QXDb3l7C29lv2 X-Gm-Gg: AY/fxX6wa9VjXhZZyDQ94Z3tKrXpYIacwH2w8IGl8kx7bb5MGdc5xTeEbR0oTysOeiA N2x76PnI+5mOwPBEF9oHaXf9CChb/MqZnMFUfNKYfKeTvYdjL+8zglq8X+Dp+DowiAr7HF6ftdz Z2FsfZWS2sA7XR38R7h9k/ZY3tqfY7FS3lWkYizHcZxgdo3i6XAefi2ZF1P9UObCIq3t3z2f/5z 9OOx5dsRq/u73vu74G932606XCIHozTsmqyVfALruCI+Jnt2fQ16HiMghuxjyLShQjvOw== X-Google-Smtp-Source: AGHT+IFeG+dsvCu7XX24D82/I7/EiIOCEOo/OauQX6CsH8jNzGC0MTpI75x6b5PbqfAp145zFtliFDV3te4TvZTWQGs= X-Received: by 2002:a17:90b:57c4:b0:340:e0f3:8212 with SMTP id 98e67ed59e1d1-34f68c37a6cmr7136299a91.8.1767964735277; Fri, 09 Jan 2026 05:18:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Petr_Bene=C5=A1?= Date: Fri, 9 Jan 2026 21:18:44 +0800 X-Gm-Features: AQt7F2rk9apY19ZvSxCEjWj15kV9F4fFjn1GJzm8i4_AvOyIdPbyfmr261u9LaE Message-ID: Subject: Re: Resuming with superpages broke VMI/altp2m workflow To: Xen-devel Content-Type: text/plain; charset="UTF-8" I forgot to point out that when booting with "hap_1gb=0 hap_2mb=0" the issue disappears with RELEASE-4.21.0 and my VMI tool is working fine. P. From xen-devel-bounces@lists.xenproject.org Fri Jan 09 13:32:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 13:32:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198803.1515624 (Exim 4.92) (envelope-from ) id 1veCb1-0002XD-Ne; Fri, 09 Jan 2026 13:32:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198803.1515624; Fri, 09 Jan 2026 13:32:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veCb1-0002X6-KE; Fri, 09 Jan 2026 13:32:07 +0000 Received: by outflank-mailman (input) for mailman id 1198803; Fri, 09 Jan 2026 13:32: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 1veCb0-0002Wy-B5 for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 13:32:06 +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 953c7114-ed5f-11f0-b15e-2bf370ae4941; Fri, 09 Jan 2026 14:32:03 +0100 (CET) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-b8018eba13cso703103066b.1 for ; Fri, 09 Jan 2026 05:32:03 -0800 (PST) Received: from ?IPV6:2003:e5:8717:e400:64e3:e61f:e58e:3a09? (p200300e58717e40064e3e61fe58e3a09.dip0.t-ipconnect.de. [2003:e5:8717:e400:64e3:e61f:e58e:3a09]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a22ff58sm1120302266b.6.2026.01.09.05.32.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jan 2026 05:32:02 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 953c7114-ed5f-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767965522; x=1768570322; 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=mmkJPOGyF4aO94es/BNEQq5w9S0UDTnTx7FYZg/mwpM=; b=JFzjl6vQ30whLxwAioK96KmnBbAwlzqVIDkqqIVYl/rLGJsTvoU5VCpZU4TnL756aS 3QUmLPX9GkUAj559P+oGT2h4hDmw9q+IFWU67C9fvwN8Ut/zz87KQ23mRUzntQ11AbPY G5ATJotqtVL1gQ7pj5JU1wxcg6gC+aI1ED8Rvl0iOa2mBdna/Gp9N4ZDJAljhlq0NYSn spOSwQ2phOHUon7Qidfo+ERbnMcfSliXZm+FpC4TMWLbHWBU30V1vZaQqGGteyrGRxdJ o7ckDEJxIAmhsLnZ1cwiUhv3Kq18Wda76Cvg1f5uIQ4+caKTdz2KO/01oNn5wZktOfZA 38bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767965522; x=1768570322; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mmkJPOGyF4aO94es/BNEQq5w9S0UDTnTx7FYZg/mwpM=; b=RMNas6o5xzjO2m1hT+U3TP8fUyacIWGnqB9kaHwVePy2B0XFw4v0zqHX/3LpvoV7wu VarCpQzyLhVHNWeYJyoWg/U14CHts1JyGkMgwxlkpNiSQp1ix6gsi6UtfXMfDrHXTMhH 5DtTpiyEQaLRD/nSvhnXyi1yd9XR6EPRNmcN+Iuo09XwGDUbTxPyS17YCLHK89SFrkxe qd7UFNlnbQgKaJxVF4oYuFd3UDNp8ssLw6+AFGAg/FubblC/55j4wjEHY7/lrKuHYjnv PWyoyX12wOGMZq/0LbhMRhNDVj4K5A6IDaR2pHZSpvwQDPTFfPQjUmsYXDXFE0kF/dek 2ytQ== X-Forwarded-Encrypted: i=1; AJvYcCWxZ6opT5auJX4B+6mg2M5lX5zguAGLusuSPLWnf6aLX/edrtzRaCjU4nMwjPVBJ46uIwr0rLigxOc=@lists.xenproject.org X-Gm-Message-State: AOJu0YyFPcel17T+qWDLCgyk+XTVUCLSS6JBjBLdIFSoDG9KbyAEIPbg 5z1kI50udAKY+U4q9TO932LUf6RED1QpB9HJ112ymNM3luA0U+wl278bcUZdld2RaWw= X-Gm-Gg: AY/fxX69oBZ2jwnVd5Q3IRlfh9tTM5K8RWU/P/BTvmIjQKUvLWl5C5+F8wlXh7eNCA3 jghdyhpV8JQIjlLnvLTPIjlOKLniV9LhgwSkayLcH+KgTJvbQe1Zy2KT5XDDkC1rLo5///BSQHH TxjuHysAN06kT2vSfIFLmvk9xrTclPXl8rS2z6eH8CyPyv/1je/fQJfXzzCQLWFabhfLSqr0q1r rCtkhOvtpQ5WBNpYDlfHdT8U0sEAvU71QNEcQP8ASYiqJ4oFlQbQtoIGSGrQs75QyI3kQpFaASr /7uZfsMOp0AdBXTbJ3Tcrv2MhteDxpjg8wb8Kzwu/eRoeCngToEIX/gv8trxm1iPcyctzTA3Asb qNTGnGuU8A8zYFgvDZcEHN52unMscMB0U1xP+2KMYUvihV6/c34MkAKlgfgHsUDFCH4o6AQpzZj prjXSpsOZL003rqu+xBIwDA2qnjsF/njUKksxiBLjzrfFuq3SJ4T7TsJgVifXf3o2ies1aEN/MF KBQlZ8chbfh5ZRcAeCXwezOI9Fjo1Z5iDmUEj0= X-Google-Smtp-Source: AGHT+IF9M48yU9Kc3TqHugRq130WE4t2jGmBoDByqvkWYm8L8lWkHy7Z8uMuhy3osQkPD0B7tuKApg== X-Received: by 2002:a17:907:9483:b0:b80:3101:cd13 with SMTP id a640c23a62f3a-b8444d4eb13mr1129047566b.10.1767965522519; Fri, 09 Jan 2026 05:32:02 -0800 (PST) Message-ID: Date: Fri, 9 Jan 2026 14:32:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/gen_hypercall: Leave a breadcrumb in xen-hypercall-defs.h 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: <20260109131643.859509-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: <20260109131643.859509-1-andrew.cooper3@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------ZGN7lTvv3C17m0CA9QLSB7BO" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------ZGN7lTvv3C17m0CA9QLSB7BO Content-Type: multipart/mixed; boundary="------------uSYC4M01VIcedcjqZSTg7qzV"; 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] xen/gen_hypercall: Leave a breadcrumb in xen-hypercall-defs.h References: <20260109131643.859509-1-andrew.cooper3@citrix.com> In-Reply-To: <20260109131643.859509-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= --------------uSYC4M01VIcedcjqZSTg7qzV Content-Type: multipart/mixed; boundary="------------f0ZvvZIPaAxzbY0FmibSV5lv" --------------f0ZvvZIPaAxzbY0FmibSV5lv Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDkuMDEuMjYgMTQ6MTYsIEFuZHJldyBDb29wZXIgd3JvdGU6DQo+IFdoZW4gQ3Njb3Bl LWluZyB0aHJvdWdoIFhlbiwgb25lIG9jY2FzaW9uYWxseSBmaW5kcyB0aGVtc2VsdmVzIGlu DQo+IHhlbi1oeXBlcmNhbGwtZGVmcy5oIGFuZCBuZWVkaW5nIHRvIGZpbmQgdGhlIG9yaWdp bmF0aW5nIGZpbGUuDQo+IA0KPiBUaGlzIGlzIHN1YnN0YW50aWFsbHkgbWFnaWMsIGFuZCBl dmVuIHJlYWRpbmcgdGhlIE1ha2VmaWxlIHRoYXQgcHJvZHVjZXMNCj4geGVuLWh5cGVyY2Fs bC1kZWZzLmggaXMgb2YgbGl0dGxlIGhlbHAgaWYgeW91J3JlIG5vdCBhd2FyZSBvZiBvZiB0 aGUgJS5pIDogJS5jDQo+IHBhdHRlcm4gcnVsZSwgYW5kIHRoYXQgdGhlIGhlYWRlciBpcyBn ZW5lcmF0ZWQgZnJvbSBhIC5jIGZpbGUgaW4gcHJhY3RpY2UuDQo+IA0KPiBObyBmdW5jdGlv bmFsIGNoYW5nZS4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJl dy5jb29wZXIzQGNpdHJpeC5jb20+DQoNClJldmlld2VkLWJ5OiBKdWVyZ2VuIEdyb3NzIDxq Z3Jvc3NAc3VzZS5jb20+DQoNCg0KSnVlcmdlbg0K --------------f0ZvvZIPaAxzbY0FmibSV5lv 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----- --------------f0ZvvZIPaAxzbY0FmibSV5lv-- --------------uSYC4M01VIcedcjqZSTg7qzV-- --------------ZGN7lTvv3C17m0CA9QLSB7BO 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/Ey8FAmlhA1EFAwAAAAAACgkQsN6d1ii/Ey+A Bgf9FPlhrVAMQn4VNIefLuISyvhH9DuMsJEeBhDiz6qcimDqUcKEBp/XKpEs0Gd0xrNgnXr5XQP5 kE0Wx3Hu/ZmTDeMavjPZRh5nIfzXU9Wr5eASBKCPHcDegRgt6dhKQSWnle2IXv2DjDPa9kaMaEjL D5hdeM7ilc8uGtOM7hox/hmgQwng+TG8IVN2etRc5wTfSat9K50e8/yfsQ+GsseBJlptnAXbkmqV S0A8JHZe+/6zkhtQdXXHK5n4bdgixeRlHzw4qf6L4BiCcOXc0h2XuoGPvX0CjNEaKvWrKnJkNGv6 hbdHf6ZbsxVYtExjVfuJbIBKLaADn7PR+PGPeH6FzA== =tp+H -----END PGP SIGNATURE----- --------------ZGN7lTvv3C17m0CA9QLSB7BO-- From xen-devel-bounces@lists.xenproject.org Fri Jan 09 13:35:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 13:35:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198812.1515633 (Exim 4.92) (envelope-from ) id 1veCeH-00033Q-48; Fri, 09 Jan 2026 13:35:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198812.1515633; Fri, 09 Jan 2026 13:35: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 1veCeH-00033J-1S; Fri, 09 Jan 2026 13:35:29 +0000 Received: by outflank-mailman (input) for mailman id 1198812; Fri, 09 Jan 2026 13:35: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 1veCeF-00033D-EY for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 13:35:27 +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 0d9e70a2-ed60-11f0-b15e-2bf370ae4941; Fri, 09 Jan 2026 14:35:26 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BY5PR03MB5031.namprd03.prod.outlook.com (2603:10b6:a03:1f0::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.4; Fri, 9 Jan 2026 13:35:21 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.002; Fri, 9 Jan 2026 13: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: 0d9e70a2-ed60-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kmJ2MhcD/t6EiZ5B+n/EYLYxaLB+2jzFUTtnOCBY9xWPxqFAuIotHfobmi1J8/cqIOqDhJv97JSJ7zEdxIj3Z3HYiXg0soChLQjkgPFZoRlr1OETgbcY4aC5uF2/hCZkwBFN8mKHqh28bPZxfYGWE55MO9T+Vr1zWMbEhDL0Qx/9Imi6wx7LGbCwePa+1TcDtBqEYf2KJY3BfUq+RgZBbEOPDTByQ1l3PEjH7XRm4PWq7gOaYgYziBaOyhCYXuJCjG1XPa8XhlNvNYGsxKPrqG8yL9SNO2892JbIBMI6RuoDVqabFBCkE8ziKzHdX9uHZhjpkuiqVLVnnmVEVJnlPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YdL9bBnj8vt/gvQGyqnFLv6d4zNpW2N5Ve6nKesWXGI=; b=AWH93QfolJYzdBcEqwa1qTz99fwcKj0sgq8ZlzytAAea4z2dNZbqSXEmX3WT7JT1S9Y7L9QXM4gZen5Wji3xDicTUZ1EYGLQzBexvIqPOVj0R/VGM0cZ5kL85yI0TMm9sGG9ed/mgOTpSfSDZEVcZyidZG/wldamoYX/rSxzjMuCEa1CH5SQEu7LyOmnZR6HDqL+q/djWIK5+ULdDrJoaeBzsKspEssgNOMHGxY74y+TPvDcvjZXA4kn1MMb2T5a2OtgffGtaDVNuVWgwHczVdTSKvdvlCwZWacN8bIOgDrRQ2eKTGk5mz1VwDU2nHiJ2eSFGXWpRe4twu6Aj4UjFw== 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=YdL9bBnj8vt/gvQGyqnFLv6d4zNpW2N5Ve6nKesWXGI=; b=p+wUJTGpECv0UPDZ2t37qhfsTsHUGghV3F4ThVd+aGY94P4UUbBXZpBrkmThYPXCGGdLxeq8ABnLyodi6DJQ4TowKSbL7o5mDzPtOuY67WVV/4h+sGbgkT5kzHkx2sBJu4JmHBCqGqRad5MRgwwL4hItjxrsSvW6UHyBzfNZiL0= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <7f430ef2-ee29-43e9-85cd-21a8c450ee22@citrix.com> Date: Fri, 9 Jan 2026 13:35:17 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Timothy Pearson , Alistair Francis , Connor Davis Subject: Re: [PATCH v5 2/3] xen: move alloc/free_vcpu_struct() to common code To: "Orzel, Michal" , Oleksii Kurochko , xen-devel@lists.xenproject.org References: <4b2e9f4c-ce8e-4090-afd5-45af183b9497@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <4b2e9f4c-ce8e-4090-afd5-45af183b9497@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0298.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:391::8) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BY5PR03MB5031:EE_ X-MS-Office365-Filtering-Correlation-Id: 90c9d9d0-5b4a-47d0-f22f-08de4f83efd7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7416014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?Zm5yVVRRVkIyTzcycTJFNDcyVElMbEtLQWtBK1ZxWTFXTUc5b1hreGxvWFRP?= =?utf-8?B?eDJFV0kyM1ZTTVRCSmZETHdtd2kvUER5dUdhK3cwRVd0NXBQUVgzTnZCcmFy?= =?utf-8?B?dGxDU1NaUjVIaXRQaVY1c0pEY3lETE0vVWdabU51YmtjOFRXMXlrYXFsQkpn?= =?utf-8?B?R3JlQTRRZEFmdnF1eE8vRWJpZE1tRFRNM09QUUQrc0ZtNlN5SWpPdEh0RnVS?= =?utf-8?B?TCszTXBkY1VMUVFwQ1Z6blFnS0g4aklOZWhjejNzSWVlbHpUNFBKNGxha3Az?= =?utf-8?B?YUg1YSs1UytNMFY1N2ZkUEpBazVlTC84WWxEN0NxbzlRL0R4VGYrbWVTOUJT?= =?utf-8?B?TDZmdklQUnhTRmRudk1HTUdCdDNMb29lNDRGRGtDb1NzWjV0d1F6TmZ3cWtO?= =?utf-8?B?RjhoVW9YdWdwaTRpOHhmMUhFdC93c1ZqSThWMEJOOC8rY0xIVWRBa3RsTTVt?= =?utf-8?B?akcxNHpyRk0wSUJlZXpSblpJRjEvQk1LY1NQMTNrcVY3dUtqanN5ZGFHYWZW?= =?utf-8?B?aFY4R3RSVVBVNVRJMXo1TTk5YXl2N2tPNGFXaXJweVZJN2FnOFFXNG9CSlF0?= =?utf-8?B?TlUvdGROODZqVGsxdUl3U0JDOHUvdGZnVElTWlRNNGw2MEJWd0ZNZnVZdHlC?= =?utf-8?B?cUE3NDMycmhySjRQYy9wVEZ3UnJmdlhHTzhqQ2ViYTlxZkVYc2FDWklrTkIz?= =?utf-8?B?U1A2WnArRU5oaVhJUHI0SnBYRWZpQVJPRWsxV2E5TzEyYzR4N3NpL3dYUDBQ?= =?utf-8?B?Z1NNSXhzQ1VqK1lCbkY3RmlQb1pFMnVpMGo2UURCZ0VYb1VaR2dkRUZManlN?= =?utf-8?B?VTFSMjBFRXVZVVE0RExFRXFFNjBCcjlOSGp2Z2lnRVJpdVRrY1BKbG5waVFa?= =?utf-8?B?YTJKam5vdW1WYUpoTVFsbWg4NFRiQUZEaUlKTEc1NkN5dDM0RCtiYmkwL1d5?= =?utf-8?B?a0ZuQ3pLOUVSRHA5MFZ4LzZLa1dCeGxHSlRCSFB5S0FhS1dTbnV1cmZCa0dv?= =?utf-8?B?S0VMRXUrYkxXbzNPb0tVWE9Va2ViMUdmelJmc3EydWw2TDBhVFFjSWFXUDBx?= =?utf-8?B?Q0hPOTVvK3FiZWZuNnhscjdST1VyYVNJL1dGZFNHRkxFaHRxbEpUMGVoVmJr?= =?utf-8?B?c3BHUnZXSmM0TXJVVnhjT3A5WFMrSjFYVXl1bnhiSE5RaERYejl5Q3ZtQk9U?= =?utf-8?B?UmwwbVRybERaWnp3N3F3Umh4dUd1cE4zalozME1RVzk1K2ZvQ0Y4K0RkSjRu?= =?utf-8?B?VEg0dFFoOXZhYkN2VnFZUEg2eWI0VjQxNzNoRkc5a3pxdE1YcG5vamdUWTBr?= =?utf-8?B?SnovelJyZ1BNcEdCeUZiUVdtY21UYU54Q0xCeG4yQS9wbUdsRlk3MUdNWXRm?= =?utf-8?B?cjJDdnpoQyszYStJZkRucGZldytQampjdDJxL3VwMHR5eTNwYmRwcVExNVk4?= =?utf-8?B?TjJ3T0htZ2hpYks0NUo1VnhyRnIybTdiVHp1b1QvYzVzVjNBYVJLRXZHOWJu?= =?utf-8?B?dVIzMVFvOWZ1UUNtS3h5TXNIWnVRUGtHdXZRVVlpMDdXeFpiUTNtWXhpUGto?= =?utf-8?B?RWpuYnBMN1F6YWNWb05JQjd2dWs5TUcrRkFqNEEvdVlQMnVXSzNSdHB0M053?= =?utf-8?B?cngwRDU1aHJQVy9jcmNOQTZaelova3JITG9XOTRDa0J3UWJvb1RiREFVMmN0?= =?utf-8?B?cjlqTFROTHgwK2FORklacGo3YjZ2MXNJcmwrSFJ4OEV0TWlNSEFwa1RBSVZv?= =?utf-8?B?anhaUzRtNCtUenB3MWUxYWZWcGk1V0N3bm1RbG9ZdzdNUDNXcGVtWnI3UXBL?= =?utf-8?B?bjNPTTc3aVljTU1DeVcwU2lXYkw4WWwxVWZwRFMyQ212ZG5JbzBWSVFNK3lu?= =?utf-8?B?QytHNm9KNVF4NTJDQmhidVZFaEh0RnFTa1dFM1lCRDJCUCtJa2g5QktuN05i?= =?utf-8?Q?ie0NjMbVpVB+EwTvk/4dF5YbN60qSa/3?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7416014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?R0RKZFY5T3ZGUGZYZFdHeFhMZDZ1akdIbXd6a3Npb0VScC9HTFZudTcrRFNl?= =?utf-8?B?bjN2ejJaT3dkRDA1T01KSmU2Vnh6ZW5SdUxTMlNPekZaQzl2SzVGTGJobUp3?= =?utf-8?B?MUw2TEE3WlV6Z0Fhd256K1lTNkFVTWhESUFFN1Uwbi90d1lHT1FObHNrSFNx?= =?utf-8?B?TGE4WUJnR0RHbEdSVkRJZXZjZEFabmF0YVUxL1pkQjQvQjZoc0hYMDdheno0?= =?utf-8?B?UnNIMVUrUVlsaFJXMFVvWjM4ekx3SUlKOHlNYVdEZGpDRFIzY09JZ3dzOVk4?= =?utf-8?B?dGdoSGtFRlQwTkNIQ29IbDBKbzhzWXlVYlFjNWJJTU5qQ2pMZ2lzQzRrRThh?= =?utf-8?B?cWZ5N0w3czF0VWVyMUMrVTVyVFJTbnhGckVNTXFjWUpmMGNJRXBGK1FBazZw?= =?utf-8?B?a3NRMGZjcSswQ2hhaExWZFJONVZTR3BFczhHOUk5Qk1FM1djOEhpZHF0UlUv?= =?utf-8?B?N3ZuRUNoQjIwSENhMElESTRncUF2ajRkaS9qdjd2dlFYUzFDSDlLYXhCL1l0?= =?utf-8?B?UFYyOUwyTWhYR282d3h3K0p0bXZTMzdHUDBpNFI4QmlzWlg3L01VS3NPQUln?= =?utf-8?B?ejdac3pVZno4aWFNVEtwYTJsOHJMYmdVU1lCeVVoZGpqMzhsZnJvTTRrZHZw?= =?utf-8?B?ZVNLbGkxS1dhMjQzQnB4NjFId1dmQ2lURE03ZHZkYkhFQ0RBUFE4b3Q5TUlI?= =?utf-8?B?T0RmclJObVgyTGZQcGh2NTdhSjJLY3JVbkl5blVwYlJTWmVxL2J1RWZCcUY3?= =?utf-8?B?azZmazB5bEZOeThJUmF4SUk3UDJWR25CelU1ajhUanZxRER1QWxRNzZVZXVt?= =?utf-8?B?aUNkdjErTEVscTZKcENtSFJvTlkrVHE3RnloYXBrbEREWlFQekRvNzNpK3ow?= =?utf-8?B?UUg1b0tZUjR2elZDM3NUbnF6S2RxaDU0VGtUaXN2bE5EQm4rQlFnYjZCYmQy?= =?utf-8?B?VVZibEtoNG9PVTRtSkx6UUQwaU1aQXVJWHhtdWZYOGZEMHFpUUVoSkF6YXZT?= =?utf-8?B?di9qUHFGSHkvZk9IWXFuYXJQNitDQzRsMTFDL203L1I5bjNyZlV4TnppRTNG?= =?utf-8?B?Q2I5NzZoMHdac05MSzRLQVBKUkRManR3TGt2dVZxdkUyK0ZoL2FUZkRPOHZh?= =?utf-8?B?YWZsSDZibWxFdzZGRGZlc1YwVWtTTVArRk5Rc2tYcDhJUUIydnRXSnh3Q1A0?= =?utf-8?B?dEFzaVNsaDBhbVFoNVluOWd0a3lQVUlYV1kybm94NTVUME1zRWtzSG8wNDIr?= =?utf-8?B?eWptbEJWbUxQdFVub0sxbXZNQ1loZFB2N2RzRU4vTytFQS9EUndyTTVURk9u?= =?utf-8?B?YmJ3bkRvWFYzeE5OR0Q5a1pLUnZsQlBmcVEvSktpcjVwM2wza1hWSzBPa0xH?= =?utf-8?B?SVZMTTRkMlFuNm5RUFVLZzNCc1lsaUlrZVZ0aXVQM0pzSzdwd3RPUHUwS092?= =?utf-8?B?TWk2ZmR2SjJXaGdIY1dmdUREaFU3ZGM0b0R3SEdvL21WYzMvVnZqQ2RqOHVu?= =?utf-8?B?YkJuQ0w4UlVNNDRBOUVSK3ROSzFMSGNXM1hMK0FMTjdkck5nSnhjS2xjeVdQ?= =?utf-8?B?WEgzNFN4WkV6eWtQbzRhWTFUSDFmMXdHUHc4V0R5SStGazRWMWYvbGpqRnpB?= =?utf-8?B?cldpNGs3Y2cxUjVsd2ZIbldoYlFOcG10OVdjWkVRMjgwNWcwSmFPY1o4ajM4?= =?utf-8?B?ZWFsU1I3K1N3TklmdzRaUUFDN3g4dG5DRlJuaDJBdE51dlc1MkMrSWRuaTUr?= =?utf-8?B?bmhGeWhJalVuY2FUWkUrMEhlVjFFRU9Qd3FScm0veVhad3pYWnZVSDMvK3Q4?= =?utf-8?B?RDlxWHB5QVd2dVIzUGNqcEROeTA4dmFmVmt5bEc4SmEvMlpaR0RpRHlBK0li?= =?utf-8?B?bmtZNHFCKzJyRkVVWU1mRjZPM3dqMHFpUjlNUGFzVWlaRzdzSFl0dmJnNDBm?= =?utf-8?B?eEZYMzQvLzdHWVFtOWJuRGNaVWViVEdGU01MQjRLUldQeDNFcXBYZVRjQ1Fw?= =?utf-8?B?UFBKS3FIN1dISldsT0V2djlWVGJwZDZKZFZ0Nzg1Y2JWZm1kcXJCUGIrUW5R?= =?utf-8?B?eFdQekFCYlFxWFhnT3lkOER0cUlVZGc0MXplUVdHMGcxRmxHdWQ1Ylh0cnBr?= =?utf-8?B?WHV3NG1iSFd5VmZ1RXlFVXNTdzF2NXBGQjR2T0x2SWhlV0kvSzdTa1h1TTFR?= =?utf-8?B?OXZIeXQ1TUZNa21TcWQyNk8xcHBoczhDMUw4SEtxY1k5WWlrc29oMUlwUHUz?= =?utf-8?B?ZWxwTTRoRjZnaWhVYzIvRitPQmNqeU5tVm1hWWlrOFltdWp5RmRaZGJELzJE?= =?utf-8?B?eWRnZkwyMU1FZkpRdHFwNEFnQjNhcnpCSlladWd0bU9jYU9JaFlVVGFTdEhQ?= =?utf-8?Q?zRM2XTzKjZM+dTEI=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 90c9d9d0-5b4a-47d0-f22f-08de4f83efd7 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2026 13:35:21.7201 (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: 2PNcqfxotMcCuzlaUCga+wO01TMxr2rgRF0CTWsaT405WPT4NT6INe3HFXFj5SLI3uNb+8qCeC/znt1IFcsPR3QU8MOd2YYh+/yuwoklync= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB5031 On 09/01/2026 1:17 pm, Orzel, Michal wrote: > > On 07/01/2026 17:28, Oleksii Kurochko wrote: >> alloc_vcpu_struct() and free_vcpu_struct() contain little >> architecture-specific logic and are suitable for sharing across >> architectures. Move both helpers to common code. >> >> To support the remaining architectural differences, introduce >> arch_vcpu_struct_memflags(), allowing architectures to override the >> memory flags passed to alloc_xenheap_pages(). This is currently needed >> by x86, which may require MEMF_bits(32) for HVM guests using shadow >> paging. >> >> The ARM implementation of alloc/free_vcpu_struct() is removed and >> replaced by the common version. Stub implementations are also dropped >> from PPC and RISC-V. >> >> Now that the size of struct vcpu for Arm64 is smaller than PAGE_SIZE, >> MAX_PAGES_PER_VCPU is no longer needed and is removed. >> >> Finally, make alloc_vcpu_struct() and free_vcpu_struct() static to >> common/domain.c, as they are no longer used outside common code. >> >> No functional changes. >> >> Signed-off-by: Oleksii Kurochko >> Acked-by: Jan Beulich >> Reviewed-by: Andrew Cooper > In case you need Arm tag here: > Acked-by: Michal Orzel Thanks.  I think that's now sufficient to finish this series.  I'll queue it in my next sweep. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jan 09 13:39:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 13:39:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198827.1515644 (Exim 4.92) (envelope-from ) id 1veChw-0003vq-N5; Fri, 09 Jan 2026 13:39:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198827.1515644; Fri, 09 Jan 2026 13: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 1veChw-0003vj-K6; Fri, 09 Jan 2026 13:39:16 +0000 Received: by outflank-mailman (input) for mailman id 1198827; Fri, 09 Jan 2026 13:39: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 1veChu-0003vd-Hk for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 13:39:14 +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 93794438-ed60-11f0-b15e-2bf370ae4941; Fri, 09 Jan 2026 14:39:11 +0100 (CET) Received: from SA9PR13CA0024.namprd13.prod.outlook.com (2603:10b6:806:21::29) by LV3PR12MB9167.namprd12.prod.outlook.com (2603:10b6:408:196::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9478.4; Fri, 9 Jan 2026 13:39:03 +0000 Received: from SA2PEPF00003F68.namprd04.prod.outlook.com (2603:10b6:806:21:cafe::3e) by SA9PR13CA0024.outlook.office365.com (2603:10b6:806:21::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.0 via Frontend Transport; Fri, 9 Jan 2026 13:38:59 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by SA2PEPF00003F68.mail.protection.outlook.com (10.167.248.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Fri, 9 Jan 2026 13:39:03 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Fri, 9 Jan 2026 07:39:02 -0600 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Fri, 9 Jan 2026 05:39:02 -0800 Received: from [10.252.147.171] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Fri, 9 Jan 2026 07:39:01 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 93794438-ed60-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=WBYAN1Fsfe3VEv88xux4NKI5UKRsJZ/rgfafmTdpsu0CWFFI4zErVjczexGZl6NXgjFqGhVK40wSCgASVWfUtB/vcnf7Vg2UNoChAI4vg+51VUarHfUAtqvX8tQE1mjPzPhPsUZsbvxt7DALosmvLHu1hVpH+f7p4kpNM/e+VOxC9EkWxu1JgbehSUcyaV4Q5yO3KyQEhYldR7ls7+zrl8f7iMYsMFHmKEgOncXjX3cnepLaFDf77oD+ejSsqPVEjrdaqjHOGur/WuO73tVpepr2QL3uSmSUIt+n5VnF6ldiHWRnjbWJcSwwJJwl4PsSAE6JW2PiGNNXJRjpFsK1DA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/97QvYe2/F0Hn9azJhZ1OEYQhRSgO+YRIB7L6Spx60c=; b=emAnK1MgCGVJnkqGfgKWdhxhF7E7iivgjCB9l0bgGHGmGxhZk4plDfRkM05AXvG2g3kiBmijIWNa0CUtr4gVjOKxQcfeEHo0iQGmY1RWV5YHwYfuO8qlYBj7lCsD+cgbPYDgqDCsOh6MdDCP6lJwhBbDp20Hny3xGYRuDJr/VJgzd8BJj8o+JG96HpnLUCuD9Za4E66fWWxalKVkxb66VvyjGGj+PHXcO+JxapCLBP+4wXI6+rVMWcjbkBJEPhkcDLo6MrhjxNWCqWbk4LdcOsYxYTcb+wdUER1JZpTQjx5n+jMUOwEsx3S47J7uJ4mk1XP4Xzh4Nzzxlx0PefOmsg== 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=/97QvYe2/F0Hn9azJhZ1OEYQhRSgO+YRIB7L6Spx60c=; b=qEA+PNf1oOW13a6uOoGlu/1ndU4EUA/SLqXgRBIp0rQ8V83YIx5LukXbZXivSCnAxDctYowgmRABBPRGE1DTZsBO5GEFCLfpgOUSQ5bycItJVAlgg9rovNYx1htWF8clcWGFgHY46g1tEJnUcNUtYdsKAbsY0I+8CGCyeVFqvPw= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <09de85de-5d49-4dec-bb9a-db7afa22a858@amd.com> Date: Fri, 9 Jan 2026 14:39:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] MISRA: Extend the R3.1 deviation for URLs to include git:// To: Andrew Cooper , Xen-devel CC: Anthony PERARD , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "consulting @ bugseng . com" , Nicola Vetrini References: <20260109131807.860397-1-andrew.cooper3@citrix.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20260109131807.860397-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA2PEPF00003F68:EE_|LV3PR12MB9167:EE_ X-MS-Office365-Filtering-Correlation-Id: 6598d673-169d-4594-ec4f-08de4f84741e 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?NVB2c1Jqa1JBVkhZZzhhWnV5MWxLZHIwN21aWFVLS0VjQVlHNnRjS2w4SkdU?= =?utf-8?B?K01PRHkvTFhoWlk1dCtzdnpCMU5hVFlWU0pDajBrQWhJbEF2ZjRjcVBvdDVL?= =?utf-8?B?L3crM2pvV3lzMk9hQXc0WlhINHBRaDQ1MmtVNlVyTWFlTnB5dVZRMUNQdkYr?= =?utf-8?B?dkphdWlzOVk1OGlyYkdZR3JDNkZDZzdtcERQODB4eEp1aVh6N053QWtEdGpE?= =?utf-8?B?VG10S3g3MUNkVnlBNE1JZkZoaUJVdXpEN0V4UmVadHJOZWFUT2M4SGYyZ0tJ?= =?utf-8?B?ZWNwMzg4N042ZWs3TzFIREFwNXdUakF4WTg4aC9XcDdzd21XdjhGdmxHYjJX?= =?utf-8?B?SlhBQjJPcFJIeHdaamk2L3psQnpmRWEvQW5laVE3SXJkcmJVN3p3YllSaTNX?= =?utf-8?B?VHZ1aFEvbmRkMndZR0xKSW5DQ04vM0QzVGUySWxtMDlnQ080bG9wZnVtQVZp?= =?utf-8?B?S3ZPR3ZnV1dBY2VWY1RqZ2s1QkJ2UzZlZTF0LzJsWFdUalRjVWl4QUVGazBG?= =?utf-8?B?Mm8yV1MrWlJrTnllc3g1VTR2YXAvKzQ4KzJQeEtUbWVBMzJrYnlhRmF4SlFu?= =?utf-8?B?N2NnRU8vcm16bSs1WGZrZFpIT1oxMUFMQTJ4Z1N0c21kNnluemNVWDM0Nzdp?= =?utf-8?B?dHl1dXEzMmhZWDQ2czRQMkowYnRhbCswdkJlR3h1RDBjWGRxSWpZOEtTVWpM?= =?utf-8?B?K3dqWjU5dmlXQ0QxeGxtVjZwK3owWkcyK3drbFNCc3VFT1p5bkJhK3NGbUdo?= =?utf-8?B?QXlBbFlKbEtlUzdETVZKbnBiRnVNRzNKUXQzSEIveUVKUFA3Um9UTFh3b0tt?= =?utf-8?B?MDllbnBNZkVOR0xUbGVoaVlIQUdWV0lqSVo1elRhWlBzaTJpbE9XU3haelhp?= =?utf-8?B?QitjWjJtNzlhMVNuQTg1MVpyYUVCbG5RcUVCZllxRzdVZ3dhc2JGeHd5NlRN?= =?utf-8?B?bnR3WWFRb1JZRzZJVDZEOHZ1dGJHU0s5Nmpadm14WTAyU1MrVk1wSmxFc1lP?= =?utf-8?B?UC9ZYVE1ZE5yZnpyMk5yRXhLQlBSWTgraktSWHJqdXlQZmdGekczcEhkYld4?= =?utf-8?B?aHRrZDNOMTM3VU4vQUhzOHFBMm9jc1JITzNtOVZZL2dqVTlKU0xmMStWektv?= =?utf-8?B?b1Z0RnBWREZXZjZEaGNUNlNjYmpzekN4bXgrMGNGV3BYQ2pjVkgrUGliUDlF?= =?utf-8?B?MXBISUlkM1lIYk9vdUFKSHJ3L3hEOHFaTHhmOHBIdVJ5MHRnUDlNZ2dZUCt2?= =?utf-8?B?QWVQMlQrZjhkWWtjazJkNDh2bzdJTm9tZTNqMnQxUUI1SnFCWjgvdlRkamdI?= =?utf-8?B?LzhkV2E2Q3J0WVVDbWJuZzlzT0F6aFpmYnVVb3QrOVVWa0Zzd3NlRHVweWR4?= =?utf-8?B?dkhoQkd2YmZUb1dEekhDM3hpZUFiZDJzbHludDhnMmtOZGdEdEtIWjFLSCtl?= =?utf-8?B?KzlWUWJaK2VpbDFCVlBlKzErSTVIcE4yQksrS2taWmpTekdwdDdzZGVCckMr?= =?utf-8?B?M2hvR2dnb3JWcWY5R05sQWdQOS92QUxsRnl0VDVMMXg4NDNqV2U0MnNxSXJX?= =?utf-8?B?eXBvQ2NlZVRLS0gxNy96LzA4dDR3ZXJVUjVJNi9rR0NkWE91bkpHY0NDZThX?= =?utf-8?B?UFNoNVFtRnBaM0pGTEJGZFRhNmxIU1RjQ2JKREhONEsrNHhsWmIzL0Z0MGhZ?= =?utf-8?B?Z2tTRDVVZTVrZzloMlV2Q0JJZXFVWDN5bm5uVUxudGg2bXF0NDB6MzBGN0FP?= =?utf-8?B?NU15em9VcXNJNEZKZUNyYkhOOElEa1FPeHc3ajFqSW9yQWtlenVEL2VLQXhz?= =?utf-8?B?Z2JpdExnR1hCZlBxbnpBdkM4NHBzV2R0NmlTS2xRblFzaGYwcDRhOTB2dG5E?= =?utf-8?B?ZnFYWDQ4djVpSktnNTg4QzVXaWc3c1l6Mk5tVTRyRksyYVBjVUFEakgxRW5I?= =?utf-8?B?d016TUw2WWVBZlNiRTJYWnVuRlZ6MUtKc1VQZXhxcndZU2J4dzZhZEZoN2ll?= =?utf-8?B?TVUrR1Rwc0oyR1JlYTZKalQ5VVpNKzM0T29Kdmh2d0QxdDYyc1VsY1gvbjJo?= =?utf-8?B?R0tBU0RCWjRSVU9LQjB2T081NWY2ZXA2Y2xjdXZuNjVNV3FsZ3lxWlJja0RJ?= =?utf-8?Q?utd0=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(36860700013)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2026 13:39:03.5040 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6598d673-169d-4594-ec4f-08de4f84741e X-MS-Exchange-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: SA2PEPF00003F68.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9167 On 09/01/2026 14:18, Andrew Cooper wrote: > xen/drivers/passthrough/arm/ipmmu-vmsa.c contains a git:// URL in a block > comment. This is also not an example of commented out code, so shouldn't be > considered a R3.1 violation. > > Extend the regex to include git://, and swap hyperlink for URL in the > associated documentation to be more precise. > > Signed-off-by: Andrew Cooper Acked-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Fri Jan 09 13:47:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 13:47:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198840.1515655 (Exim 4.92) (envelope-from ) id 1veCpy-0005fq-Ft; Fri, 09 Jan 2026 13:47:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198840.1515655; Fri, 09 Jan 2026 13:47:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veCpy-0005fj-Bh; Fri, 09 Jan 2026 13:47:34 +0000 Received: by outflank-mailman (input) for mailman id 1198840; Fri, 09 Jan 2026 13:47: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 1veCpx-0005eH-6A for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 13:47:33 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id be70e011-ed61-11f0-b15e-2bf370ae4941; Fri, 09 Jan 2026 14:47:31 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 216514EE3C11; Fri, 9 Jan 2026 14:47:30 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: be70e011-ed61-11f0-b15e-2bf370ae4941 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=1767966450; b=0zjHDCjrRtxvZoRQweEQBTwrfH1OdmsJBONZI4neZfm7G8iWkqRir4utSl2m89/yCT8Q 3lOV7sSk/mqaCk+RQw0xqDPzn0A11Jnrkogn0ZLFjH+7ud5rhIq7BpdICVb1KUAKo5nZt CF/GPZb7asY9WF1Y4LhnuV51+T9ghnsjosy3NNDfhyvjPWBYcc1Lrt5FDTK9Bj8ZapqAR GbxGT5yGrreQnYdD77myUmXsRSy1/Fywq24u0D50DoFk9LU2E80AS9xdFc4ZxpJp/kxoA kncL/r5eT4R3FNUKhfgwm5HLHGw/Eyk8Gp4UCpG52NyBt60nLBpr2/IvQ84uVwdGcVz0p I3MYURPk4DbbtSDEHOo+aly77cq6twvygt1vCJrLv6UrdppeZRmvCX9z8xfJjyUWMjgc2 qJGZ+Wk/OaAUR21QdSBOCUl/3melupWdEIkx021Q1Zgn01PCugkmWabVOHL6TWPbhXcWb MD8cHrtL2V3YsLUA2DvPntbY+OSU/ZkSvr4g0iMs2/nrbztyTi8btoDJWEzaB6o4zibW3 Tw4D9ZTR+iKIbC4urCIJ/8IXTE/qFGLsE2A/zNP3ub14FAcysL3exae4oUQtPPLFL4als mDoC97QxL9YylHOWwH8MaDdUx/hb6Et+cMYk1ZfTbPsm3Qmh6fk35GmE3F2Tio0= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1767966450; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=43uGOl9QcAOHv+wuK+FTtpUjHIexCK/0igWh8XWoB48=; b=U3x6diUhVX3RQXpoW49Mt6Ix+wYy4cZcqoyZEiDXQ3W/t+jyA5TpJDINFGiqE5Ad/SCV J+Qjvc/XKkMcZ4UvglsIT65rHicQwFNZm9uLs5zCZkRXDgEoqpTz11yJwYTmqwye2g1hN qySwBlkBCgc7pDrxzRlpN4OhFPvQFHUoskHGX2bRTciM6hgIZPHiTgmO79e46wKzJyzHi dbt5534UNW6FfTebj2BGFuoYviXh26J/mij7PBaxA6WPxsndLo7jkcrA8AxKin3tyLiOw SqCoMIsZAW4OER2sV48yLxZwkfqfdd2ieWmvJjxPJWbFPEWwtIRrIsTsrQUoQMV2YafsO qpZB6A1vH2f5urjHylG4qCtc10SCYT9soRVqkO+eRg0+hijl6JzK+x8M3LGS0RxBYdMOO cZt4/sRVIIOnOCkarlQtGMQlgyGGiak3OXy9J00YNi+SNdyZRZJc2Q0UofZ9KlFAs//rt FdltMJKXVkE0ETpIXEReSEE93CM6+0DdxUxAXQGo8Co8IvDcCZ4ZW+dwMr+c9l52RLkPd cAHrP7lw+kiGqyw/yBZ+Q/sBHdBvrT0ll4LrMMnQB6tmZbEgNsEvSe0ivtJRQhO7L0v9c 3Jv+rCYNAuKhrQaAVgAUlzkbfrzWU9FIUVvCCiGMuqb+9oIG3DcnJhC1ujYibAk= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Fri, 09 Jan 2026 14:47:30 +0100 From: Nicola Vetrini To: Andrew Cooper Cc: Xen-devel , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "consulting @ bugseng . com" Subject: Re: [PATCH] MISRA: Extend the R3.1 deviation for URLs to include git:// In-Reply-To: <20260109131807.860397-1-andrew.cooper3@citrix.com> References: <20260109131807.860397-1-andrew.cooper3@citrix.com> Message-ID: <3708b916520ba100cbf931d632c990b1@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2026-01-09 14:18, Andrew Cooper wrote: > xen/drivers/passthrough/arm/ipmmu-vmsa.c contains a git:// URL in a > block > comment. This is also not an example of commented out code, so > shouldn't be > considered a R3.1 violation. > > Extend the regex to include git://, and swap hyperlink for URL in the > associated documentation to be more precise. > > Signed-off-by: Andrew Cooper Reviewed-by: Nicola Vetrini > --- > CC: Anthony PERARD > CC: Michal Orzel > CC: Jan Beulich > CC: Julien Grall > CC: Roger Pau Monné > CC: Stefano Stabellini > CC: consulting@bugseng.com > CC: Nicola Vetrini > > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2252341951 > --- > automation/eclair_analysis/ECLAIR/deviations.ecl | 4 ++-- > docs/misra/deviations.rst | 4 ++-- > docs/misra/rules.rst | 2 +- > 3 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl > b/automation/eclair_analysis/ECLAIR/deviations.ecl > index 7dee4a488d45..30c323906924 100644 > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl > @@ -58,9 +58,9 @@ removed by the compiler, the resulting slowdown is > negligible." > # Series 3. > # > > --doc_begin="Comments starting with '/*' and containing hyperlinks are > safe as > +-doc_begin="Comments starting with '/*' and containing URLs are safe > as > they are not instances of commented-out code." > --config=MC3A2.R3.1,reports+={safe, > "first_area(text(^.*https?://.*$))"} > +-config=MC3A2.R3.1,reports+={safe, > "first_area(text(^.*(https?|git)://.*$))"} > -doc_end > > # > diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst > index 0d90f5886e7e..17c21537f286 100644 > --- a/docs/misra/deviations.rst > +++ b/docs/misra/deviations.rst > @@ -117,8 +117,8 @@ Deviations related to MISRA C:2012 Rules: > - Tagged as `deliberate` for ECLAIR. > > * - R3.1 > - - Comments starting with '/\*' and containing hyperlinks are safe > as they > - are not instances of commented-out code. > + - Comments starting with '/\*' and containing URLs are safe as > they are > + not instances of commented-out code. > - Tagged as `safe` for ECLAIR. > > * - R5.3 > diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst > index 4e9425188742..b3e929307d51 100644 > --- a/docs/misra/rules.rst > +++ b/docs/misra/rules.rst > @@ -143,7 +143,7 @@ maintainers if you want to suggest a change. > - Required > - The character sequences /* and // shall not be used within a > comment > - - Comments containing hyperlinks inside C-style block comments > are safe > + - Comments containing URLs inside C-style block comments are safe > > * - `Rule 3.2 > `_ > - Required -- 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 Jan 09 14:00:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 14:00:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198857.1515664 (Exim 4.92) (envelope-from ) id 1veD2j-0008Vq-HC; Fri, 09 Jan 2026 14:00:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198857.1515664; Fri, 09 Jan 2026 14:00:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veD2j-0008Vj-EX; Fri, 09 Jan 2026 14:00:45 +0000 Received: by outflank-mailman (input) for mailman id 1198857; Fri, 09 Jan 2026 14:00:44 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veD2i-0008Vd-9Z for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 14:00:44 +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 95910fd9-ed63-11f0-b15e-2bf370ae4941; Fri, 09 Jan 2026 15:00:42 +0100 (CET) Received: from SN1PR12CA0107.namprd12.prod.outlook.com (2603:10b6:802:21::42) by SJ1PR12MB6170.namprd12.prod.outlook.com (2603:10b6:a03:45b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.4; Fri, 9 Jan 2026 14:00:34 +0000 Received: from SA2PEPF00003F65.namprd04.prod.outlook.com (2603:10b6:802:21:cafe::60) by SN1PR12CA0107.outlook.office365.com (2603:10b6:802:21::42) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.4 via Frontend Transport; Fri, 9 Jan 2026 14:00:29 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by SA2PEPF00003F65.mail.protection.outlook.com (10.167.248.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Fri, 9 Jan 2026 14:00:34 +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; Fri, 9 Jan 2026 08:00:33 -0600 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Fri, 9 Jan 2026 08:00:33 -0600 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; Fri, 9 Jan 2026 06:00:32 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 95910fd9-ed63-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=s1Ca1uYZt3W73jRCaU6BovtPc9dXvrps6QdK0rhgsW5rtDKRNKBBD25gpJLHpxRoXWKk6wfr4bZOkEcFKA/6rcXtUML96U/xYA9UqnoYSewLSJbanr2NsuKeJ3NoctOKt22haIjsy0P4yCm7Th/+j50Lrx/20j/Qd1KIEVpslWx1cJ9VcqiGoGnEx0IL4LX7pndlvMzGyemnGxNI2bsT/57mMcqhOwsjI475P3qs8X2HiarbCIps9Bt95gtgQjbNSk0hTUqdtjWz4YosuWy4eOv4GTPudOWT0u5CZChxvj1V+Wi8z5OrXrIX36RCF9ApvJwnEhSJNWcLTHB6/1UPRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zoh4EwKW9YxCQ33jFSp1dJ7kfjtLB/Zxu3IDJVm1oqk=; b=eZl8noODiMxvdTMnvII8peUTRfongVdTXAY87cF1EHuAp4my1iXgTcsORWqrbM7CUHO7EYGMmJiMcc1XjhvGX2X8tvH+RPStW21G98tEeve5DMq89nNttev/7Tj2/EYKVmO44NUoRnepugkhrucWyIj/fZef5QffGPUuCEGyAUndsgfbftBbMGQKq6EyvTVyRPWM8j4cng4fObVHsghqcR9t4dprfRjUSjbgTL/vsGqEqRENNnVExWByejsg8i6U8kBNhWrNKbWDRqID2PddN3fC/lWxoJPann3nwZL/VcM2pe5mu9fg2JuOkak1FDC6XVH0WXKlCWn6koaXsKkIdA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zoh4EwKW9YxCQ33jFSp1dJ7kfjtLB/Zxu3IDJVm1oqk=; b=Fzxtjv6SNKbmH90dZDFjAsQ2S/fcCIoQ/vnHIfFOGolwQj47reZp/p2HdonNchTMfimqu94Ig2gHzdR4Hz0MkFXMxPE30sN1Wq7kIv3Jh2A1wAlI+u6BkXL1ZCgSJdVIPlWA3toL5jB70p0buvceSdAhr9v/3xzpoUEvAH1075M= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <40677f79-8e3a-4c0c-876d-d57e9b230eca@amd.com> Date: Fri, 9 Jan 2026 15:00:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/6] arm/mpu: Implement vmap functions for MPU To: Harry Ramsey , CC: , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk References: <20260105113503.2674777-1-harry.ramsey@arm.com> <20260105113503.2674777-3-harry.ramsey@arm.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20260105113503.2674777-3-harry.ramsey@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA2PEPF00003F65:EE_|SJ1PR12MB6170:EE_ X-MS-Office365-Filtering-Correlation-Id: c9f8c597-0b9e-49a8-e4e6-08de4f87756a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?a1JuS0JHNjB2emVEWWVjZitCbkMwVzh6dEdpZEdDemFBVEZlRzBLNTdMaWQ0?= =?utf-8?B?S29CbEhmZWFLYjJHSzhDcm9PRVQ4OE9UanYvbS9jTVljMWxBcDVCUVBRc3dz?= =?utf-8?B?K3VNVHk5VUt4Zm02Lzg1Z0o3MDVLUVBSMTIwZm1TbEoxTU9Ob01qaFNHSGRt?= =?utf-8?B?dUE0b0k4NU80ZHYvRERFWDhxQ3FxcFpkVUFyWGxxZ2x5Nk5jZnI1Nm1mYW5i?= =?utf-8?B?L1o0SnF5SUcraEFrZlpPNXAyVnRER1VjMjJsK1ZGaldWcGJ2Yml4MTk2YmhK?= =?utf-8?B?WGtLbjJGaDFTRHlUWEJzMEZWdGlsNFo1V2xtZ0NTQTZtNUduN3ZONHdDSlVW?= =?utf-8?B?Nis0VzJSNWJtWjMvN2xMSE5EbjZRT0p0aUZjSnNLNTdVMjcyV3ZTZHpuRFkv?= =?utf-8?B?cklJK1hOdnFoN3U0WENreDBsTlZJOXE0Mmxlc213NG5OS0ZnZmFBV1JPSUEx?= =?utf-8?B?dnlzd2plQTNScWt3UytWZmtKMm8xOFZ0VUJCSzNsdWRqMWdrbjczNzU2R3ZZ?= =?utf-8?B?STY5Y1lERmZlL041a0gvRklHdjdhWWJKNHE1d3JlcUE5TVhxVG9jSUg0UEJ5?= =?utf-8?B?TjFRWVFBR29zTDY3b3BoTkVhRGVoNVl6dGFFdE1UZnhPYjlBd2pQWGdBc2Rv?= =?utf-8?B?bmZjT3UzamVKWkk1U0VZK2ZaMXk4aE05MnVsZ0xjQWhPSGE3cWoxS2hTeXo3?= =?utf-8?B?bmlSVlJjQmh2bCt3ZFJxOGswb1oycGM0S2xvdXYxdXhFY053YmdqQUV2NDRQ?= =?utf-8?B?eVkyNkNyVmxaN1RybitzcVBMWTFYaGtJODhPZW9HeHRqQnlUWGwydHc1c0Qv?= =?utf-8?B?OUZFcHRZb0R6MG02VCtpNnNEQ1lRWVpKUlRzM2Jja0h6SG9KeVFEbTJGUmdQ?= =?utf-8?B?SEFOdDNhUmhOakk5V3cvWGg3ajkxQUxMdjNUaEtHaS8xTHBZQ1RXK1hhT1lW?= =?utf-8?B?bmVpWEZkTGExa3NmcUV6TGxTRVlFeEU2VXc1Y3NBMW85b3UwK0VrZmJuZ04w?= =?utf-8?B?c2VtODRXTTkrN2QvN0s3SHQvdE1MY1JpUlRRNlV0WVNZN0did256UStBQ0RI?= =?utf-8?B?eDV3VGg5Q0tMVDVrendEMGxpZFQvYkRVblZNK0lXRStiYi9KVERVOS9kOTRx?= =?utf-8?B?c0FDNVc0eU02d0NEYnd5Y3dsNEtPR0RQVW9aNCtpaEpsOVErdG9xREFLa2dm?= =?utf-8?B?b1F5ZCtycjhzTm9KbjV4RFd2K21YWUNydXplSDZSZ2lwelJvZUpsNFU3dE52?= =?utf-8?B?K3RDSENWNWprczRUNjFQNk9Va0RpdTlvK0F0UFhlSzZoZksvVUFKd1h1Tncz?= =?utf-8?B?U29FR2xScW43clFxSTZlUDIrcGRTNGVramJFMFJNSFdkTEdINEtSM0FZMzFj?= =?utf-8?B?eTl4OGZLNVltSDluRlNaZXJXMVlEelBldFFvMnlmUjV5eTBKQ2NkMHdWNldj?= =?utf-8?B?YlpZRlp1cUd2QTNwRWtnQkRYeWJUckpHeld4cytmTzluUEY3VDhVVTdtT1Nl?= =?utf-8?B?N3ZiN2ppNFJqSUZySEdEcElYSFBpS25DSDRvd09zQy9JRVlRbS9DamE3RkdM?= =?utf-8?B?MzI0QTB0dmJNcVFHb0dXNURweUxROG4vdDdNNnFiMGptNHp0SlVxQ1NIWm16?= =?utf-8?B?Y3RwV1d4RUthTGF0VStsTlVFSk9vMUdOY1Q1QnNJUVFQWk92ejg1NXVaVTY1?= =?utf-8?B?ZXByZFp6dUZGTlcvZ2dMcmJWY3REbS9HbU41TUJWNXNWU1NhK0g3M09wVjZp?= =?utf-8?B?L3NNNitIUE1SSVVrd005NHdPZjZ1NCtocUFHNlFPY0dBYjBDUG9RS3MzQzAw?= =?utf-8?B?ZENEQzFvU1JRTnp1QzkxZHlTTnFMVk5tY0JGS1BvMXhxZlUyQXdkNVlPd0s0?= =?utf-8?B?NS9KNGhwUCsydWZ3U2x6WFJLZ0F4UkNsRUE2SkYwMENOZVBWR240dHU1RzVW?= =?utf-8?B?Q1FWcGh5QnY0QmJYS24wWWgxNEhsQkpPM21OUEkweTkyNHdGTVpwd3gwL0VE?= =?utf-8?B?YndIaE8xS0Q5cEhzZzg2VFZjUGUveEw1eUxlQUxxd0pTdkZkcGNNelV5WnlJ?= =?utf-8?B?Q3NhcitXODcyT1haK0l4K2VTMG1VS1RwcUlnNk05WXhyTXl4QTJFM3RzeURS?= =?utf-8?Q?gqvY=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2026 14:00:34.1684 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c9f8c597-0b9e-49a8-e4e6-08de4f87756a X-MS-Exchange-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: SA2PEPF00003F65.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6170 On 05/01/2026 12:34, Harry Ramsey wrote: > From: Luca Fancellu > > HAS_VMAP is not enabled on MPU systems, but the vmap functions are used > in places across common code. In order to keep the existing code and > maintain correct functionality, implement the `vmap_contig` and `vunmap` > functions for MPU systems. > > Introduce a helper function `destroy_xen_mapping_containing` to aid with > unmapping an entire region when only the start address is known. > > Signed-off-by: Luca Fancellu > Signed-off-by: Harry Ramsey > --- > v2: > - Rename `destroy_entire_xen_mapping` to `destroy_xen_mapping_containing` > - Improve code documentation. > - Refactor nested code. > - Fix ignored rc error code in `destroy_xen_mapping_containing`. > --- > xen/arch/arm/include/asm/mpu/mm.h | 10 +++++ > xen/arch/arm/mpu/mm.c | 74 ++++++++++++++++++++++++++----- > xen/arch/arm/mpu/vmap.c | 14 ++++-- > 3 files changed, 83 insertions(+), 15 deletions(-) > > diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h > index e1ded6521d..1b5ffa5b64 100644 > --- a/xen/arch/arm/include/asm/mpu/mm.h > +++ b/xen/arch/arm/include/asm/mpu/mm.h > @@ -111,6 +111,16 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags); > int mpumap_contains_region(pr_t *table, uint8_t nr_regions, paddr_t base, > paddr_t limit, uint8_t *index); > > + > +/* > + * Destroys and frees (if reference count is 0) an entire xen mapping on MPU > + * systems where only the start address is known. > + * > + * @param s Start address of memory region to be destroyed. > + * @return: 0 on success, negative on error. > + */ > +int destroy_xen_mapping_containing(paddr_t s); > + > #endif /* __ARM_MPU_MM_H__ */ > > /* > diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c > index 687dec3bc6..207e8d2d91 100644 > --- a/xen/arch/arm/mpu/mm.c > +++ b/xen/arch/arm/mpu/mm.c > @@ -290,6 +290,42 @@ static void disable_mpu_region_from_index(uint8_t index) > write_protection_region(&xen_mpumap[index], index); > } > > +/* > + * Free a xen_mpumap entry given the index. A mpu region is actually disabled > + * when the refcount is 0 and the region type is MPUMAP_REGION_FOUND. > + * > + * @param idx Index of the mpumap entry. > + * @param region_found_type MPUMAP_REGION_* value. > + * @return 0 on success, otherwise negative on error. > + */ > +static int xen_mpumap_free_entry(uint8_t idx, int region_found_type) > +{ > + ASSERT(spin_is_locked(&xen_mpumap_lock)); > + ASSERT(idx != INVALID_REGION_IDX); > + > + if ( MPUMAP_REGION_OVERLAP == region_found_type ) > + { > + printk(XENLOG_ERR "Cannot remove an overlapping region\n"); > + return -EINVAL; > + } > + > + if ( xen_mpumap[idx].refcount ) > + { > + xen_mpumap[idx].refcount -= 1; > + return 0; > + } > + > + if ( MPUMAP_REGION_FOUND == region_found_type ) > + disable_mpu_region_from_index(idx); > + else > + { > + printk(XENLOG_ERR "Cannot remove a partial region\n"); Shouldn't this be moved above refcount checking? Do we expect this function to be called with region_found_type being MPUMAP_REGION_INCLUSIVE? > + return -EINVAL; > + } > + > + return 0; > +} > + > /* > * Update the entry in the MPU memory region mapping table (xen_mpumap) for the > * given memory range and flags, creating one if none exists. > @@ -357,18 +393,7 @@ static int xen_mpumap_update_entry(paddr_t base, paddr_t limit, > return -EINVAL; > } > > - if ( xen_mpumap[idx].refcount == 0 ) > - { > - if ( MPUMAP_REGION_FOUND == rc ) > - disable_mpu_region_from_index(idx); > - else > - { > - printk("Cannot remove a partial region\n"); > - return -EINVAL; > - } > - } > - else > - xen_mpumap[idx].refcount -= 1; > + return xen_mpumap_free_entry(idx, rc); > } > > return 0; > @@ -418,6 +443,31 @@ int destroy_xen_mappings(unsigned long s, unsigned long e) > return xen_mpumap_update(s, e, 0); > } > > +int destroy_xen_mapping_containing(paddr_t s) > +{ > + int rc; > + uint8_t idx; > + > + ASSERT(IS_ALIGNED(s, PAGE_SIZE)); > + > + spin_lock(&xen_mpumap_lock); > + > + rc = mpumap_contains_region(xen_mpumap, max_mpu_regions, s, s + PAGE_SIZE, > + &idx); > + if ( rc == MPUMAP_REGION_NOTFOUND ) > + { > + printk(XENLOG_ERR "Cannot remove entry that does not exist"); Why do we split sanity checking between this and xen_mpumap_free_entry? What are the possible region types that xen_mpumap_free_entry is expected to work with? I thought that it should only be MPUMAP_REGION_FOUND. ~Michal From xen-devel-bounces@lists.xenproject.org Fri Jan 09 14:03:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 14:03:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198871.1515674 (Exim 4.92) (envelope-from ) id 1veD5b-0000lS-1r; Fri, 09 Jan 2026 14:03:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198871.1515674; Fri, 09 Jan 2026 14:03: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 1veD5a-0000lL-Un; Fri, 09 Jan 2026 14:03:42 +0000 Received: by outflank-mailman (input) for mailman id 1198871; Fri, 09 Jan 2026 14:03:42 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veD5a-0000lC-2m for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 14:03:42 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1veD5W-00Gb6q-1V; Fri, 09 Jan 2026 14:03: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 1veD5V-00FZAX-2B; Fri, 09 Jan 2026 14:03: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-Transfer-Encoding:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:Date:From; bh=ycbTpcP2rEIQcuL8GJhr2lp78qmfFmpjbhJwB8/Zpwo=; b=JfSCEld3avjKAMXHiCHmENUh+A I3ztVggcU4L4qeYZOGnyiPxXCNgzBMcrPEcJNpT6AQxbhlIOAn1VyYkM/RVkJe3xhrZgWLxxvJ5dT of3yd2wF/J1EMK60DTbR+Fp0d2ctO+w+5jF01SHrtbW2lSZLH9zuJjDmPook9mS+0pjU=; From: dmukhin@xen.org Date: Fri, 9 Jan 2026 06:03:36 -0800 To: Roger Pau =?iso-8859-1?Q?Monn=E9?= Cc: Jan Beulich , Stefano Stabellini , xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, dmukhin@ford.com Subject: Re: [PATCH v3] xen/domain: introduce DOMID_ANY Message-ID: References: <20250924030630.122229-2-dmukhin@ford.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Dec 10, 2025 at 10:56:50AM +0100, Roger Pau Monn wrote: > On Wed, Dec 10, 2025 at 08:36:37AM +0100, Jan Beulich wrote: > > On 10.12.2025 02:04, Stefano Stabellini wrote: > > > On Tue, 23 Sep 2025, 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 > > > > > > Reviewed-by: Stefano Stabellini > > > > The other day concern was voiced over aliasing DOMID_ANY with DOMID_INVALID. > > I don't recall though who it was or where. > > I'm afraid it was me (at least) that voiced such concern. But then I > completely forgot to reply to the patch. I don't think this is a good > idea, aliasing DOMID_ANY with DOMID_INVALID is likely to be dangerous > in the long run. In the example here it's fine, because the function > itself doesn't use DOMID_INVALID (iow: all usages of DOMID_INVALID are > replaced with DOMID_ANY). > > However I could see a function wanting to use both DOMID_INVALID and > DOMID_ANY for different purposes. Having both aliased to the same > value is not going to work as expected. If we have to introduce > DOMID_ANY it must use a different value than DOMID_INVALID. And given > the context here I would be fine leaving domid_alloc() to handle > getting passed DOMID_INVALID as a signal to search for an empty domid > to use, I don't see a compelling reason to introduce DOMID_ANY. Thanks for the feedback! I agree with having a dedicated reservation for DOMID_ANY. I think introducing a new DOMID_ANY symbol improves code readability a bit. > > Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Jan 09 14:08:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 14:08:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198883.1515684 (Exim 4.92) (envelope-from ) id 1veD9y-0001Uw-I3; Fri, 09 Jan 2026 14:08:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198883.1515684; Fri, 09 Jan 2026 14:08:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veD9y-0001Up-Ep; Fri, 09 Jan 2026 14:08:14 +0000 Received: by outflank-mailman (input) for mailman id 1198883; Fri, 09 Jan 2026 14:08:12 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veD9w-0001Uh-MX for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 14:08:12 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1veD9v-00GbCg-0C; Fri, 09 Jan 2026 14:08: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 1veD9v-00FZLi-0H; Fri, 09 Jan 2026 14:08: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:MIME-Version:Message-ID:Date: Subject:Cc:To:From; bh=qjgtr4bC7APkZhNKrkEmz/ndAIWVoimDzoPnpMO29/Y=; b=wQnZC+ /xZQaAvCmgybtpUxVlYHS+2lWz77qObyvzA2lm5gM6i+Km/l136LnH1JZcHj+wCbNrP8W3DluvHMd 0TwJ3Z4UDl/fLxDHHVWERGrD3kEjEuvNoPjZVnq1VwoEJ9TRdb5QMVu7zX+u0RuBstFNh4D1Dm2NY SKsh+iS4B2I=; 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 v4] xen/domain: introduce DOMID_ANY Date: Fri, 9 Jan 2026 06:07:48 -0800 Message-ID: <20260109140747.195460-2-dmukhin@ford.com> X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Denis Mukhin Add a new symbol DOMID_ANY 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 v3: - new value for DOMID_ANY instead of aliasing DOMID_INVALID - Link to v3: https://lore.kernel.org/xen-devel/20250924030630.122229-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..65da0d075a2b 100644 --- a/tools/tests/domid/harness.h +++ b/tools/tests/domid/harness.h @@ -41,6 +41,7 @@ extern unsigned long find_next_zero_bit(const unsigned long *addr, #define DOMID_FIRST_RESERVED (100) #define DOMID_INVALID (101) +#define DOMID_ANY (102) #endif /* _TEST_HARNESS_ */ diff --git a/tools/tests/domid/test-domid.c b/tools/tests/domid/test-domid.c index 5915c4699a5c..71cc4e7fd86d 100644 --- a/tools/tests/domid/test-domid.c +++ b/tools/tests/domid/test-domid.c @@ -41,20 +41,20 @@ int main(int argc, char **argv) domid_free(expected); /* - * Test that that two consecutive calls of domid_alloc(DOMID_INVALID) + * Test that that two consecutive calls of domid_alloc(DOMID_ANY) * will never return the same ID. * NB: ID#0 is reserved and shall not be allocated by - * domid_alloc(DOMID_INVALID). + * domid_alloc(DOMID_ANY). */ for ( expected = 1; expected < DOMID_FIRST_RESERVED; expected++ ) { - allocated = domid_alloc(DOMID_INVALID); + allocated = domid_alloc(DOMID_ANY); verify(allocated == expected, "TEST 3: expected %u allocated %u\n", expected, allocated); } for ( expected = 1; expected < DOMID_FIRST_RESERVED; expected++ ) { - allocated = domid_alloc(DOMID_INVALID); + allocated = domid_alloc(DOMID_ANY); verify(allocated == DOMID_INVALID, "TEST 4: expected %u allocated %u\n", DOMID_INVALID, allocated); } @@ -64,7 +64,7 @@ int main(int argc, char **argv) domid_free(expected); for ( expected = 1; expected < DOMID_FIRST_RESERVED / 2; expected++ ) { - allocated = domid_alloc(DOMID_INVALID); + allocated = domid_alloc(DOMID_ANY); verify(allocated == expected, "TEST 5: expected %u allocated %u\n", expected, allocated); } @@ -72,7 +72,7 @@ int main(int argc, char **argv) /* Re-allocate last ID from [1..DOMID_FIRST_RESERVED - 1]. */ expected = DOMID_FIRST_RESERVED - 1; domid_free(DOMID_FIRST_RESERVED - 1); - allocated = domid_alloc(DOMID_INVALID); + allocated = domid_alloc(DOMID_ANY); verify(allocated == expected, "TEST 6: expected %u allocated %u\n", expected, allocated); diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c index 495ef7b16aa0..9130c38681df 100644 --- a/xen/common/device-tree/dom0less-build.c +++ b/xen/common/device-tree/dom0less-build.c @@ -842,7 +842,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 29a7726d32d0..e2c8990531ad 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 7f15204c3885..b5789c32ae1f 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 xen_mk_uint(0x7FF5) +#endif + /* Idle domain. */ #define DOMID_IDLE xen_mk_uint(0x7FFF) -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Jan 09 14:47:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 14:47:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198917.1515693 (Exim 4.92) (envelope-from ) id 1veDlU-0006mo-AR; Fri, 09 Jan 2026 14:47:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198917.1515693; Fri, 09 Jan 2026 14: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 1veDlU-0006mh-7k; Fri, 09 Jan 2026 14:47:00 +0000 Received: by outflank-mailman (input) for mailman id 1198917; Fri, 09 Jan 2026 14:46: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 1veDlS-0006mb-JW for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 14:46:58 +0000 Received: from CH1PR05CU001.outbound.protection.outlook.com (mail-northcentralusazlp170100001.outbound.protection.outlook.com [2a01:111:f403:c105::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0b91d0a1-ed6a-11f0-b15e-2bf370ae4941; Fri, 09 Jan 2026 15:46:57 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by LV3PR03MB7478.namprd03.prod.outlook.com (2603:10b6:408:197::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.4; Fri, 9 Jan 2026 14:46:53 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.003; Fri, 9 Jan 2026 14:46: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: 0b91d0a1-ed6a-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lsx/s1oSOEfAOCPodMUoS2dwN5pIMY6ji8+ID5L7rNWuId6hVZ2pYsn4e05QySncoODFVyqiQOjj5fPAt+mo4A8Yq7iEy6rIPRpnz2yCF3nFwFGigzmqITaNyZijKXR06ktD+h2W1eCZuWx+jYXhug4iaD9NBqpqwAwr2McGIu1bJc+yRKFOLI8qzyWSiOh2bD32mqzdvHQffrCka0oOHxo3t2Awqa3cQeFLlS+y/a6kcCXKUr5f+mR5pzU6RT6Z7G6EJpoIGwHP29pCfpn1lRKXBgm7Q8FcmdIf51b9Du/Bi7Eadnw4vVS4gCCgL/ae9+Ie4LFHFb8uOLtFnaxfxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qHm14Zsieid21GtiDfTQPG6U+ZFeb1sFsD9NGsh1ClM=; b=X2Zx+mznZMptYZChMmv770Wv0LzHcz1Ko5IuOPM7of0cRau6CuZqg1ZYNWgLOD+X1rThlKz29D4ORf7K536asHqejvz2oNPvcPvIWZcCvexf3leACunaV9AHpnvDOoub9lsSpw0mITFq08gTOZdTTxhkecLdN5hWKgm2oIC4vDf5zASCeeFcujCGsxZhUsFmQIAGRIMQAitNGH7arSj2tsvc4TVw6tKZj5gh49x9chp/6YZOTVLGjavSWia3sk7ar88j2rxxsnFYV6ECGuFA+OxYimfbfydx8B6jPpuD+anV6zaFeCWBPaMlV+NRAQBiBLpnU3/ZWHuNgnlWOjgUUw== 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=qHm14Zsieid21GtiDfTQPG6U+ZFeb1sFsD9NGsh1ClM=; b=EUei4FsvfOrHEkMkqYaWzy4tWM2waP9gehbjo+dOdEzw+nkNQepH0b6ITFW0Fw6so+7hXmgjUf3aDFBTAY/7Oel2/JKfvrKYNKgsEogpgYVGWddEdHn2CTqXsUuU7PxdW9lM+1bA7er+Uecay6YYAsFfw/JteDF63ewrxTcTpCE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Fri, 9 Jan 2026 15:46:50 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , xen-devel@lists.xenproject.org Subject: Re: [PATCH 1/2] xen/mm: add a NUMA node parameter to scrub_free_pages() Message-ID: References: <20260108175536.82153-1-roger.pau@citrix.com> <20260108175536.82153-2-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: MA4P292CA0007.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:2d::12) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|LV3PR03MB7478:EE_ X-MS-Office365-Filtering-Correlation-Id: 311c70fd-4949-4696-8d93-08de4f8dedf6 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?SHdYclgzQVZJN1piRXdhNVkxQU56OFZReHdKdi81eU9BUFNEWUFrMVVJb3ZZ?= =?utf-8?B?WVRVYyttWFViKzZoQWp2cnNMdnBZYWdKbjRQbGQyajlmMXJzci8vUDdiaVc5?= =?utf-8?B?Z1RtanJxSUhTaytiVU91MlBjaXJDOHFST0VEUW12L1lMWGlLWm03NWUzd0JT?= =?utf-8?B?WDVpeVZPUy9ORXdLNThSR1hWZ1R1RkZROUIvb0dpdi9Dd0RTODFZdWFadEFs?= =?utf-8?B?Nlh1ZXdUV1RaWkNZd2lCU2ozQkI2MDNxQWdQdWpjVjZWRWxRSDVYR1BjTmpr?= =?utf-8?B?NWpzd0tQcDdmeTJPNXN2K0JtR3RYL0hrUnkwbWY4RVovQWNVeWRzNEVtSHhK?= =?utf-8?B?d3c2SkRMaWJzOHkrS0lrZ0x6amRmNmtHTzB0T2svQ0hycTFNZEhFU21vcW9Z?= =?utf-8?B?N3hOZWFmUGs5NWIzOFpqZEllOUJUL3ljeWJYZXVUZW10dlNXRXQ4TUVJeVVD?= =?utf-8?B?clUweGozZzdWSWxxeG5jT2hOc0hSQTJWZXNRMjlhaVQveENKYVpwWXVXQ0Vn?= =?utf-8?B?OG94OTBEWElOU2FDNW1QbEVpc29pWTJXN0Y0RFlWRVVmbmtScjBUcDl1Zlk2?= =?utf-8?B?bXZ6NUVzT2YzdzNvUXg5clVMVXZKeTVKeFd6ZWxWdTZ0Z0NKOTdGUDFnb3JE?= =?utf-8?B?RTZaWFgraHB1RGxTbUZzbzJtMDF3RW1ta1gyYXQ3Q3VvNmp4TjJRS2s0MktD?= =?utf-8?B?RFliYmpYR2cyNjE2aHBnTEhuRGQwMU84bFhmQ0J6T2tHNkV3ZnYyZnN3K1F6?= =?utf-8?B?eW5Pb0lrM3BNa2J4K2lqdWZTSithOU9kenVNVlJnMnEwamczbnJ2ZzBBQmQz?= =?utf-8?B?eWYxVkt0dUt6MmpTSk9LN1JBMndXeHJmTzcrSGlGbFEzRm41VWdudTlzTllL?= =?utf-8?B?TDJHL1pVQ2lxUWU4V0tRMURGWTRxYzlibG9ncVZMeklSWFlYNDF4OW02NDEy?= =?utf-8?B?Ym5KOUdISUFKaTZBZ3RUTVMzdEZFNEpBbUNydm1wNU10cGFqcFI1ZUFBK3gw?= =?utf-8?B?YXNzdWFYVnlROXkrRDBqd3NENFZKVHZkdVlhSCtZYXlWSW83WHlKU3FtVjBQ?= =?utf-8?B?RkFaTVlYd08xWGdrQ3FxOVY3S0RwUEtxdzBvS0VSbDlFaGxQRzlJUndlNER5?= =?utf-8?B?cEE5cXFqdzcvQUkrajR3VytTQVZFcSsramRmTldTc3BqUFV5cmpBTDAyTi9k?= =?utf-8?B?RDZ1OGw4cFlONTdWUUN1NEEzZlRJcGdPZGVtb0VpTFZQcndrL002dUhsOXZO?= =?utf-8?B?b0trb2dpV09wdlJDR1NmdXdvcFZkQXpQSG1ta3RkWHhuMk90K29VYjFaZ1hN?= =?utf-8?B?SklSSTNVS3J5SWFhZ2lWL2x2SmV5alNMN3lSb3ZDOGFpZ0QvU1puaENFRmxZ?= =?utf-8?B?ajM2eTVUL2wyNnR4ZG04ZEhhVDRNVzk0QzZRMXVvRENONllUaG9ITlpIeDFE?= =?utf-8?B?eGxoQzA3Vmc0V1JRT0ZVYWNmOC96NTdlUDc4a2gyeCtEUVhJYURTdXExaFpw?= =?utf-8?B?Y0ZxWXdKVVRkbEh3RFlLSTFrOENXaDZpNEhXSUx0SzJQUVFKZXpUN0FTenJQ?= =?utf-8?B?OGtGcng2a3VCamVZMGdyV1lCd2I2c2hHaWIxajNYbGZ4V3I4am5TTHViRG1Z?= =?utf-8?B?SkdVTTVFQXRnWHAraWg0RC9yd2w4djdhRHh6WE9aMjh4dUNudnhzSUx0RUNR?= =?utf-8?B?RDZFc1JCWVJMcTZvMVhXUDRGNEhnSnBZZ0w5WTRuNXRkK3FFTjdTQkxHMCtH?= =?utf-8?B?eXhncGpFeGFDdDZBaUlqdjBBeFhCNi9EOGFxQXp5VmJSdU5xbk5icCtWSlM1?= =?utf-8?B?dnU5Mm9BUmZrS3pRdFRKZXN0L2hTZ3ZjaEdleEhMQ1NhY21FT1V5eEM3THNq?= =?utf-8?B?Y01BdDQ5Vmh1SjAvWEFYUThUTmNBSktvT3lhbUhEYnZEalZtR2k2VWhXZWVk?= =?utf-8?Q?n5JRe+f2YxjBAXeoGvNrjYugGx6AXFym?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZTNDMU1qdFBqZkdXb2kzdy82MHVhRG00Z1IrNUg4OXBsekx1dFd6bE5Fd3A2?= =?utf-8?B?b1FyakVEaERKdGxjWUZwTDI4Uk84MENjbU5sN0ZEcmczRDEzbG5PSVoyWTMy?= =?utf-8?B?bytpdlFZUno2cW9uejdKZ1ozaE1OWUpiQTNCWU41eWsyTjRzVDFuQm1ZOUlh?= =?utf-8?B?QTBadkU1NnU2ZmdhLy9ESDNhUUJOYnVUZ1RTNDlpdTlhZXkwSlEwZ1VtS1hK?= =?utf-8?B?UTVFNEpFcnUzQXVlTFhpd2lJTGQra29kaG1zckRPTkpjSzJ6T2JicmcyS2xH?= =?utf-8?B?UXk4VzJJNmlScGQwc2MyaHBPNjBYdjFsS0E1eGxCRHc4TkJpS3JYa2N6bk1n?= =?utf-8?B?YUJJZUIxTUVPNGpLK3YwRjlBYVJtdC9YN3JtYXEySVIzczFmM3dFVy9Wa3FH?= =?utf-8?B?a1J2T1Z3K0wwclN4bjhCNE1qUkplMFJtc3FpNXBzMFNQaEdGendHcVZtTWsw?= =?utf-8?B?SkJjdGY2aUR0QlVJalJlNkY4elF6aUlaRVZwVjZ3SjFqMHpVRE1ySzJnNVc0?= =?utf-8?B?am02QjlaU3JWSWxDenhTOG50blVjUEN5T1ZJa2V3T1BJS1J3ZjNBMGdheWUx?= =?utf-8?B?SjQvcWxkQ1ArVjVHNFp1VGx0RUd1dnp2ajgyT2dFYndmZGxDRVRJcWYzeW92?= =?utf-8?B?L1lnamFRWmJpMFdsSEFFelZSZXl2T0Q2L2xVNndGdG8rVHlCMjZJakJhWVV4?= =?utf-8?B?VkRzaThiV1RTRTEvL09BZG1YajBHM3VFVmxwUFJPTGtzaERIRnBFclVka1lK?= =?utf-8?B?YWVTVERJMXVwYjNHNlRoa2pIeWFXTWNMbm5qeEtTU1lyS3FRaEFMVjJFd1RM?= =?utf-8?B?SnhVZFBWOGtnRDF0djZiMWRjWTJOTGQ1UDk2dVZseW9PaFk4YXpaZmVldWhW?= =?utf-8?B?bmZ4SW1hRFFtd0sxUHZIMTVleGJaVTBJU0R0VExOSW1vVGhDblJXb0pFMit4?= =?utf-8?B?WE5rTjhCd3oyNE9BNFVWM3hWU1pQNnFleWVoS3BCcGcwL1Y1Rjljc1hOTmZ6?= =?utf-8?B?eGdMK3dUK0h6WUVIa3Q1VmpYeE5tSytiUlRCc21xOXhVNEcvazlTYnI0dFpW?= =?utf-8?B?V0YrOXJOSFZHOVFobEI3Mi9ad2Z4Mm5iOVFIMjAvTXpLb1pwSzFKRTlyLzUy?= =?utf-8?B?azJ4cWNzNzhHSDBpSEhISlVjR1NnUUk0enVjcUZlMWFDMThLcnUxczZmYVpI?= =?utf-8?B?NkprbWp2UTVLZXgxNjRwOHVIcGh2MGNpQ0RuVThZZi85bVVjY0hWaFhrU1J0?= =?utf-8?B?eU95OCtnWHE1MVVPOElDZFNYMlo0QzlZcHQveDdyY1JiMDdlNUREazl1ekZH?= =?utf-8?B?UG0vV3VXS2dROXNaUzU0UWhlYTVZTjdTMm1ML2U1bEFJVnlWa3Jvd0VHZE1L?= =?utf-8?B?ZHBsTjdMeHhDeTZtLzJMc3hPRE50Q1dFR1lGdTRxY0I2YTNGWE1xdm1qK2li?= =?utf-8?B?RGxsaFljdTlQZjFQU2c5dzZ6N2xOQUxLWkpvUW9jZEZ0dk9pRXBtTGVmaW5I?= =?utf-8?B?V0ZqWjFyUXRvZjhveWE2dTBZVTJBN3hwU3RPNmZRczBLTko5NU9DcGx1RDJZ?= =?utf-8?B?NStHa2xTVFg1dkNrVkJOem9BS3NiWXR2aTV4UXJoVkRIZXE2YTBCRTdHcFZN?= =?utf-8?B?Tnhwdys5VVFqMGl5VXNOeFlOUTVic1o5Z1Nza0t1RHR5ZU5KczRHNUMxaGxY?= =?utf-8?B?bDFIeFNMbEJ5SVZjVjJ6Y3dlblZTb09BbXhucGd2UGNQU3J1d25KQ2hkSHlT?= =?utf-8?B?eDBUQXFxWVBQYk9NVndzR1krRWUvd1hKZ2QwTjhIUGdnVmFNVVFnR25MWmJS?= =?utf-8?B?Mk5rbmFBZ0lZZ3RldjM1RHhTTWJ2NkRNdld3b01xVitXeEFIQ1k5NDNRZnV2?= =?utf-8?B?bVhlUmFCOFAvaHEvVndxbHgrRHY1bUxkdXFyRndBUHVnOWszcU9OcUpNTERt?= =?utf-8?B?MUlwL0pYaVhNbUNPUTg0MlNpWTZWd0lIcmZGVGt0bTZ5NEVud3lkWEwydkdk?= =?utf-8?B?bjFqM3dKV1V3UW5QM1l0NlhWZy9QY2V6NFN1dWZOTTlWTmNrSk4yc1pycG0r?= =?utf-8?B?WVhFNDJGcnJLU0NlRXIrZ0YrQkE4cUZuSE9zMXNDNGNMdVNwb08vZWw2dlNY?= =?utf-8?B?cEorRkxxekxMTDZpVkZYakgxWWVySWtOUUpnY2dEZWVmYlVYdEp6Qk10Y0kw?= =?utf-8?B?S3M5MzFpZm1ONldUcXNoMVBNS3ZhMk9BSXFPcFhTUUZ1Q2R4WVE4TnhvYThP?= =?utf-8?B?ZGxia0hFRUEvWHJkcVlabUczWmRHZDZ0VHliclJlR0tnQlZrbkhOL2dNQXkr?= =?utf-8?B?bXNKdDd4YXJMQzVwd3UybUZQZTc1MWhpMFRVVUN6VER2TWFnVW0rQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 311c70fd-4949-4696-8d93-08de4f8dedf6 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2026 14:46:53.6567 (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: /R33oR7yDAYR0Fw5sUdDAqHUXM5FECdxjC2J84JZ8g6UCyNKHf7hMk7I/1ve4lLF8rftYEMCvLrc/2DLwlUOHQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7478 On Fri, Jan 09, 2026 at 11:22:39AM +0100, Jan Beulich wrote: > On 08.01.2026 18:55, Roger Pau Monne wrote: > > Such parameter allow requesting to scrub memory only from the specified > > node. If there's no memory to scrub from the requested node the function > > returns false. If the node is already being scrubbed from a different CPU > > the function returns true so the caller can differentiate whether there's > > still pending work to do. > > I'm really trying to understand both patches together, and peeking ahead I > don't understand the above, which looks to describe ... > > > --- a/xen/common/page_alloc.c > > +++ b/xen/common/page_alloc.c > > @@ -1339,16 +1339,27 @@ static void cf_check scrub_continue(void *data) > > } > > } > > > > -bool scrub_free_pages(void) > > +bool scrub_free_pages(nodeid_t node) > > { > > struct page_info *pg; > > unsigned int zone; > > unsigned int cpu = smp_processor_id(); > > bool preempt = false; > > - nodeid_t node; > > unsigned int cnt = 0; > > > > - node = node_to_scrub(true); > > + if ( node != NUMA_NO_NODE ) > > + { > > + if ( !node_need_scrub[node] ) > > + /* Nothing to scrub. */ > > + return false; > > + > > + if ( node_test_and_set(node, node_scrubbing) ) > > + /* Another CPU is scrubbing it. */ > > + return true; > > ... these two return-s. My problem being that patch 2 doesn't use the > return value (while existing callers don't take this path). Is this then > "just in case" for now (and making the meaning of the return values > somewhat inconsistent for the function as a whole)? I've added those so that the function return values are consistent, even if not consumed right now, it would make no sense for the return values to have different meaning when the node parameter is != NUMA_NO_NODE. Or at least that was my impression. In fact an earlier version of patch 2 did consume those values. I've moved to a different approach, but I think it's good to keep the return values consistent regardless of the input parameters. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Jan 09 14:50:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 14:50:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198926.1515705 (Exim 4.92) (envelope-from ) id 1veDoj-0008Iq-Or; Fri, 09 Jan 2026 14:50:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198926.1515705; Fri, 09 Jan 2026 14:50: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 1veDoj-0008Ij-LI; Fri, 09 Jan 2026 14:50:21 +0000 Received: by outflank-mailman (input) for mailman id 1198926; Fri, 09 Jan 2026 14:50:20 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veDoi-0008Id-UB for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 14:50:20 +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 83d703cc-ed6a-11f0-9ccf-f158ae23cfc8; Fri, 09 Jan 2026 15:50:18 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-4327790c4e9so2192305f8f.2 for ; Fri, 09 Jan 2026 06:50:18 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0dacdcsm22809504f8f.1.2026.01.09.06.50.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jan 2026 06:50:17 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 83d703cc-ed6a-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767970218; x=1768575018; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=9cy2chGiAyYIggTragQXQxt+EIWxHkStfsPg6ed+OJw=; b=Sp8Veq7HnTAyAX9OTxwvyZenLLdfJDZr7NMIfiGXErKbh6mZmvDp37Aqn+PftWseBs kGe6EvMJeLl4ibemDi6b2FxkLXtTuAtOwCfh8J94ocLVrn4hU5H9nwY5/609O0VshEtk iT48jmzhJlArBKRfW2gIa355/4VdB7tm0hgUiZc27Q9IYPDxIMl/8FnUs/JM/aCzGWIp z/ukQ11Fm6Z74sZR7e8ntAhaFEhDHTdq1bUD8zcDa7g9xrdHFA/gb5MQd/rnWtfDpFWX PMmnDZlYRyOLGiE+q6pQJE5n29lSFIx1FwkZn6Tk0RY0FSWqd7PgiYB6dc4iNyKCXgzm O3Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767970218; x=1768575018; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=9cy2chGiAyYIggTragQXQxt+EIWxHkStfsPg6ed+OJw=; b=uasyb9GnheKf5rMQvmsTzlFGLAa59ph/wwTRE7R9+/N44xmYzv/0dHMqKOqQjfamxC KXzGdBlobfY4MGfSUfQs6yFhTOCnklq1vn/Zdi8QTI+y8/dq75pnx+hj42GRMoivb7Rn z/b16VixkILJP203Rp4IPkxUYp5NRTnhVUjgRTQo4Ct3/+oRTeeWHXKUJmPNj7v6cw+D fZV+SzgFftEg1TSXVBXFNGU4mRQNiK+QHzSSLojusuUCz2CTU+3p24DRo/BLmcei87kb KBwACTJ62V6ADy63X/9SIZ4MhLXKXoAUvdwPMm3rMJUP34r5vPg3bpO6ACYHGL8STAL0 kE1g== X-Forwarded-Encrypted: i=1; AJvYcCV7VCzAUggZSvSHNhC/q/xD73D8BAlGFwkQjjC+pvmMPwNYd8ORTRx1qdD67WHjBHD6e2Oygbs08A0=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy+lUk1FyWrN29pkHnNZVIyofsQLXLcXaRLxOM5l/ak4mvOqUls 4uyN3huDo3jDGKLfMEnSkf/N1trjkfztHeQY6qOspPU/MiZWgDqhEV8hStQi87b8bA== X-Gm-Gg: AY/fxX663yeyOiputOQk8++QdSOF99C7G4YldItCFATLWie6midZV0aayE0J13VsTK/ tA9/sUtPEO/DVjeE+Ap91Vq3Nxz7jnlGOWQpZVDunU4QGL/xNNOJpYOnYEuy7bOQIldbpUfvl3e RjQ5a4IIWwHyhj6nwAOS6nceKWdH43xQs+XbkQh5E2sWiKFRw/axaQbVriuMiqtivmkEpsGJows ChfsQacijynKwIvAsXpm/ufIFAWpgvcnMHTQIkDI5PKBDGGhaQKDkoAZVtzWG1y/aSH/rsYUBRP gamf168GO04Sc51dRweSXtoCF7yMk85ezhruwD2YtHFplmYyRrhAseWaXXKTIDatlM139YKxCtX zoNNd10LV+YBnRreeLWIl3qBK5zGcihoYjylIelUmKqPo3i/7eBkiaV/WSgImpr6CLWr2SOIyW2 9+RDgrW/PejeP++ar9E4CyBvY8lcjjumsZg4jM0CGQ7dLPuU8K1A2bmGCuW/IbdoU7HXOEIycOu jM= X-Google-Smtp-Source: AGHT+IF5HFPZEYq9rDjfXNCZ/JpLSa3X1xHn+Px8GTwboA7pK+xzhHmB1wRTAoX66BFRuLbmBLxDFA== X-Received: by 2002:a05:6000:4008:b0:431:53:1f49 with SMTP id ffacd0b85a97d-432c374f461mr13445922f8f.41.1767970217649; Fri, 09 Jan 2026 06:50:17 -0800 (PST) Message-ID: <2cf49422-99e5-44de-ba5c-3b0c54eb13fd@suse.com> Date: Fri, 9 Jan 2026 15:50:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/mm: add a NUMA node parameter to scrub_free_pages() To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , xen-devel@lists.xenproject.org References: <20260108175536.82153-1-roger.pau@citrix.com> <20260108175536.82153-2-roger.pau@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 09.01.2026 15:46, Roger Pau Monné wrote: > On Fri, Jan 09, 2026 at 11:22:39AM +0100, Jan Beulich wrote: >> On 08.01.2026 18:55, Roger Pau Monne wrote: >>> Such parameter allow requesting to scrub memory only from the specified >>> node. If there's no memory to scrub from the requested node the function >>> returns false. If the node is already being scrubbed from a different CPU >>> the function returns true so the caller can differentiate whether there's >>> still pending work to do. >> >> I'm really trying to understand both patches together, and peeking ahead I >> don't understand the above, which looks to describe ... >> >>> --- a/xen/common/page_alloc.c >>> +++ b/xen/common/page_alloc.c >>> @@ -1339,16 +1339,27 @@ static void cf_check scrub_continue(void *data) >>> } >>> } >>> >>> -bool scrub_free_pages(void) >>> +bool scrub_free_pages(nodeid_t node) >>> { >>> struct page_info *pg; >>> unsigned int zone; >>> unsigned int cpu = smp_processor_id(); >>> bool preempt = false; >>> - nodeid_t node; >>> unsigned int cnt = 0; >>> >>> - node = node_to_scrub(true); >>> + if ( node != NUMA_NO_NODE ) >>> + { >>> + if ( !node_need_scrub[node] ) >>> + /* Nothing to scrub. */ >>> + return false; >>> + >>> + if ( node_test_and_set(node, node_scrubbing) ) >>> + /* Another CPU is scrubbing it. */ >>> + return true; >> >> ... these two return-s. My problem being that patch 2 doesn't use the >> return value (while existing callers don't take this path). Is this then >> "just in case" for now (and making the meaning of the return values >> somewhat inconsistent for the function as a whole)? > > I've added those so that the function return values are consistent, > even if not consumed right now, it would make no sense for the return > values to have different meaning when the node parameter is != > NUMA_NO_NODE. Or at least that was my impression. > > In fact an earlier version of patch 2 did consume those values. I've > moved to a different approach, but I think it's good to keep the > return values consistent regardless of the input parameters. My point was though: The present "true" return doesn't mean "Another CPU is scrubbing it." Instead it means "More work to do" aiui. That's similar in a way, but not identical. Jan From xen-devel-bounces@lists.xenproject.org Fri Jan 09 15:04:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 15:04:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198944.1515714 (Exim 4.92) (envelope-from ) id 1veE1z-0001ji-VW; Fri, 09 Jan 2026 15:04:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198944.1515714; Fri, 09 Jan 2026 15:04:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veE1z-0001jb-Sl; Fri, 09 Jan 2026 15:04:03 +0000 Received: by outflank-mailman (input) for mailman id 1198944; Fri, 09 Jan 2026 15:04: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 1veE1y-0001jV-Pc for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 15:04:02 +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 6d00f8a9-ed6c-11f0-9ccf-f158ae23cfc8; Fri, 09 Jan 2026 16:04:00 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 1F23D41AAF; Fri, 9 Jan 2026 15:03:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B859DC4CEF1; Fri, 9 Jan 2026 15:03: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: 6d00f8a9-ed6c-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767971038; bh=9LFMVxyFsOw43Q6k6Eff0i7Pwixa+RzRx4DsbI5AqD4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Uu2xDZmK3PKrblsrsZL8LIcmnB0lca1ztGkSrwKnR3k1T+w3GGUw72vEWmRnJLC84 04PN8WJ3tZU0qJxzKPXK/jIY9eHM/FkWJFfqFlKmAMwFCu8bAOMnLGGisVhDa+VPC1 Hkm58qx6FwRjuIwh2iTdkxqN5OiOQDU6WIuS4LlqAy4eDc3QabNZxuLBa/iS/+tV6V fS5P07RUWs0rl3AKweG2OOOgL7ak053o/aoA2ECEjLInVqvpv88XZvchTU2IlUt4fg Y4VqP9kXVaCjmME3a4NjLke27874qGSfQHgAkzTpVnrAxfNYoR24aDyxZOKRFuYlCS Zo9TfPAXHUzMg== Message-ID: <0c72913e-9708-4675-a421-06ed82b7802a@kernel.org> Date: Fri, 9 Jan 2026 16:03:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 05/14] mm: clarify lazy_mmu sleeping constraints To: Kevin Brodsky , linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, Alexander Gordeev , Andreas Larsson , Andrew Morton , Anshuman Khandual , Boris Ostrovsky , Borislav Petkov , Catalin Marinas , Christophe Leroy , Dave Hansen , "David S. Miller" , David Woodhouse , "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 , "Ritesh Harjani (IBM)" , Ryan Roberts , Suren Baghdasaryan , Thomas Gleixner , Venkat Rao Bagalkote , 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, x86@kernel.org References: <20251215150323.2218608-1-kevin.brodsky@arm.com> <20251215150323.2218608-6-kevin.brodsky@arm.com> From: "David Hildenbrand (Red Hat)" Content-Language: en-US Autocrypt: addr=david@kernel.org; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAa2VybmVsLm9yZz7CwY0EEwEIADcWIQQb2cqtc1xMOkYN/MpN3hD3 AP+DWgUCaKYhwAIbAwUJJlgIpAILCQQVCgkIAhYCAh4FAheAAAoJEE3eEPcA/4Naa5EP/3a1 9sgS9m7oiR0uenlj+C6kkIKlpWKRfGH/WvtFaHr/y06TKnWn6cMOZzJQ+8S39GOteyCCGADh 6ceBx1KPf6/AvMktnGETDTqZ0N9roR4/aEPSMt8kHu/GKR3gtPwzfosX2NgqXNmA7ErU4puf zica1DAmTvx44LOYjvBV24JQG99bZ5Bm2gTDjGXV15/X159CpS6Tc2e3KvYfnfRvezD+alhF XIym8OvvGMeo97BCHpX88pHVIfBg2g2JogR6f0PAJtHGYz6M/9YMxyUShJfo0Df1SOMAbU1Q Op0Ij4PlFCC64rovjH38ly0xfRZH37DZs6kP0jOj4QdExdaXcTILKJFIB3wWXWsqLbtJVgjR YhOrPokd6mDA3gAque7481KkpKM4JraOEELg8pF6eRb3KcAwPRekvf/nYVIbOVyT9lXD5mJn IZUY0LwZsFN0YhGhQJ8xronZy0A59faGBMuVnVb3oy2S0fO1y/r53IeUDTF1wCYF+fM5zo14 5L8mE1GsDJ7FNLj5eSDu/qdZIKqzfY0/l0SAUAAt5yYYejKuii4kfTyLDF/j4LyYZD1QzxLC MjQl36IEcmDTMznLf0/JvCHlxTYZsF0OjWWj1ATRMk41/Q+PX07XQlRCRcE13a8neEz3F6we 08oWh2DnC4AXKbP+kuD9ZP6+5+x1H1zEzsFNBFXLn5EBEADn1959INH2cwYJv0tsxf5MUCgh Cj/CA/lc/LMthqQ773gauB9mN+F1rE9cyyXb6jyOGn+GUjMbnq1o121Vm0+neKHUCBtHyseB fDXHA6m4B3mUTWo13nid0e4AM71r0DS8+KYh6zvweLX/LL5kQS9GQeT+QNroXcC1NzWbitts 6TZ+IrPOwT1hfB4WNC+X2n4AzDqp3+ILiVST2DT4VBc11Gz6jijpC/KI5Al8ZDhRwG47LUiu Qmt3yqrmN63V9wzaPhC+xbwIsNZlLUvuRnmBPkTJwwrFRZvwu5GPHNndBjVpAfaSTOfppyKB Tccu2AXJXWAE1Xjh6GOC8mlFjZwLxWFqdPHR1n2aPVgoiTLk34LR/bXO+e0GpzFXT7enwyvF FFyAS0Nk1q/7EChPcbRbhJqEBpRNZemxmg55zC3GLvgLKd5A09MOM2BrMea+l0FUR+PuTenh 2YmnmLRTro6eZ/qYwWkCu8FFIw4pT0OUDMyLgi+GI1aMpVogTZJ70FgV0pUAlpmrzk/bLbRk F3TwgucpyPtcpmQtTkWSgDS50QG9DR/1As3LLLcNkwJBZzBG6PWbvcOyrwMQUF1nl4SSPV0L LH63+BrrHasfJzxKXzqgrW28CTAE2x8qi7e/6M/+XXhrsMYG+uaViM7n2je3qKe7ofum3s4v q7oFCPsOgwARAQABwsF8BBgBCAAmAhsMFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAmic2qsF CSZYCKEACgkQTd4Q9wD/g1oq0xAAsAnw/OmsERdtdwRfAMpC74/++2wh9RvVQ0x8xXvoGJwZ rk0Jmck1ABIM//5sWDo7eDHk1uEcc95pbP9XGU6ZgeiQeh06+0vRYILwDk8Q/y06TrTb1n4n 7FRwyskKU1UWnNW86lvWUJuGPABXjrkfL41RJttSJHF3M1C0u2BnM5VnDuPFQKzhRRktBMK4 GkWBvXlsHFhn8Ev0xvPE/G99RAg9ufNAxyq2lSzbUIwrY918KHlziBKwNyLoPn9kgHD3hRBa Yakz87WKUZd17ZnPMZiXriCWZxwPx7zs6cSAqcfcVucmdPiIlyG1K/HIk2LX63T6oO2Libzz 7/0i4+oIpvpK2X6zZ2cu0k2uNcEYm2xAb+xGmqwnPnHX/ac8lJEyzH3lh+pt2slI4VcPNnz+ vzYeBAS1S+VJc1pcJr3l7PRSQ4bv5sObZvezRdqEFB4tUIfSbDdEBCCvvEMBgoisDB8ceYxO cFAM8nBWrEmNU2vvIGJzjJ/NVYYIY0TgOc5bS9wh6jKHL2+chrfDW5neLJjY2x3snF8q7U9G EIbBfNHDlOV8SyhEjtX0DyKxQKioTYPOHcW9gdV5fhSz5tEv+ipqt4kIgWqBgzK8ePtDTqRM qZq457g1/SXSoSQi4jN+gsneqvlTJdzaEu1bJP0iv6ViVf15+qHuY5iojCz8fa0= In-Reply-To: <20251215150323.2218608-6-kevin.brodsky@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/15/25 16:03, Kevin Brodsky wrote: > The lazy MMU mode documentation makes clear that an implementation > should not assume that preemption is disabled or any lock is held > upon entry to the mode; however it says nothing about what code > using the lazy MMU interface should expect. > > In practice sleeping is forbidden (for generic code) while the lazy > MMU mode is active: say it explicitly. > > Signed-off-by: Kevin Brodsky > --- > include/linux/pgtable.h | 14 +++++++++----- > 1 file changed, 9 insertions(+), 5 deletions(-) > > diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h > index 652f287c1ef6..1abc4a1c3d72 100644 > --- a/include/linux/pgtable.h > +++ b/include/linux/pgtable.h > @@ -225,11 +225,15 @@ static inline int pmd_dirty(pmd_t pmd) > * up to date. > * > * In the general case, no lock is guaranteed to be held between entry and exit > - * of the lazy mode. So the implementation must assume preemption may be enabled > - * and cpu migration is possible; it must take steps to be robust against this. > - * (In practice, for user PTE updates, the appropriate page table lock(s) are > - * held, but for kernel PTE updates, no lock is held). Nesting is not permitted > - * and the mode cannot be used in interrupt context. > + * of the lazy mode. (In practice, for user PTE updates, the appropriate page > + * table lock(s) are held, but for kernel PTE updates, no lock is held). > + * The implementation must therefore assume preemption may be enabled upon > + * entry to the mode and cpu migration is possible; it must take steps to be > + * robust against this. An implementation may handle this by disabling > + * preemption, as a consequence generic code may not sleep while the lazy MMU > + * mode is active. > + * > + * Nesting is not permitted and the mode cannot be used in interrupt context. > */ > #ifndef __HAVE_ARCH_ENTER_LAZY_MMU_MODE > static inline void arch_enter_lazy_mmu_mode(void) {} Acked-by: David Hildenbrand (Red Hat) -- Cheers David From xen-devel-bounces@lists.xenproject.org Fri Jan 09 15:08:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 15:08:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198951.1515724 (Exim 4.92) (envelope-from ) id 1veE63-0002Qo-EU; Fri, 09 Jan 2026 15:08:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198951.1515724; Fri, 09 Jan 2026 15:08:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veE63-0002Qh-BJ; Fri, 09 Jan 2026 15:08:15 +0000 Received: by outflank-mailman (input) for mailman id 1198951; Fri, 09 Jan 2026 15:08:14 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veE62-0002Qb-5y for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 15:08:14 +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 035222f7-ed6d-11f0-b15e-2bf370ae4941; Fri, 09 Jan 2026 16:08:12 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 7CEBC42AC6; Fri, 9 Jan 2026 15:08:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1067FC4CEF1; Fri, 9 Jan 2026 15:07: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: 035222f7-ed6d-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767971290; bh=3Z8L26dcTskZ3ZdCQN0iSI+dIODX6q9MdBtGUwgu/Fc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=D5A49i8XZ+WWgc3yo8WpoToMpiFiiYIORsD5kdhtfLHgOWLJ+teHa3YKmPfqvZQto EOjbH06xY/Y2D1tuKVkl4Bn9mfBj2pRUINZJHsmiBlwwDKMfmgPNBdydHY/WcoODaP hXTbfv9bYAipERXqMFeW7thazUf0MBtEe10dcKDUEhB49l5TpS6DuQJGLnLWIPw35L /A7EpMCyhB3OpiWJ4xcCGJauiqHLzHAPYo90gEXDJEGp6mJ/mQ/yOKD0hyaBuAIhmW 2g9u3gE5rzMBGVklkmAIGwRJV3u8nzhfd1IwpNssclwPUhgU0okSyNsciYIOrvSviH Q73z6sh0NFzwA== Message-ID: <1e123306-0efe-457f-953b-d4a27ce6bc60@kernel.org> Date: Fri, 9 Jan 2026 16:07:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 14/14] mm: Add basic tests for lazy_mmu To: Kevin Brodsky , linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, Alexander Gordeev , Andreas Larsson , Andrew Morton , Anshuman Khandual , Boris Ostrovsky , Borislav Petkov , Catalin Marinas , Christophe Leroy , Dave Hansen , "David S. Miller" , David Woodhouse , "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 , "Ritesh Harjani (IBM)" , Ryan Roberts , Suren Baghdasaryan , Thomas Gleixner , Venkat Rao Bagalkote , 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, x86@kernel.org References: <20251215150323.2218608-1-kevin.brodsky@arm.com> <20251215150323.2218608-15-kevin.brodsky@arm.com> From: "David Hildenbrand (Red Hat)" Content-Language: en-US Autocrypt: addr=david@kernel.org; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAa2VybmVsLm9yZz7CwY0EEwEIADcWIQQb2cqtc1xMOkYN/MpN3hD3 AP+DWgUCaKYhwAIbAwUJJlgIpAILCQQVCgkIAhYCAh4FAheAAAoJEE3eEPcA/4Naa5EP/3a1 9sgS9m7oiR0uenlj+C6kkIKlpWKRfGH/WvtFaHr/y06TKnWn6cMOZzJQ+8S39GOteyCCGADh 6ceBx1KPf6/AvMktnGETDTqZ0N9roR4/aEPSMt8kHu/GKR3gtPwzfosX2NgqXNmA7ErU4puf zica1DAmTvx44LOYjvBV24JQG99bZ5Bm2gTDjGXV15/X159CpS6Tc2e3KvYfnfRvezD+alhF XIym8OvvGMeo97BCHpX88pHVIfBg2g2JogR6f0PAJtHGYz6M/9YMxyUShJfo0Df1SOMAbU1Q Op0Ij4PlFCC64rovjH38ly0xfRZH37DZs6kP0jOj4QdExdaXcTILKJFIB3wWXWsqLbtJVgjR YhOrPokd6mDA3gAque7481KkpKM4JraOEELg8pF6eRb3KcAwPRekvf/nYVIbOVyT9lXD5mJn IZUY0LwZsFN0YhGhQJ8xronZy0A59faGBMuVnVb3oy2S0fO1y/r53IeUDTF1wCYF+fM5zo14 5L8mE1GsDJ7FNLj5eSDu/qdZIKqzfY0/l0SAUAAt5yYYejKuii4kfTyLDF/j4LyYZD1QzxLC MjQl36IEcmDTMznLf0/JvCHlxTYZsF0OjWWj1ATRMk41/Q+PX07XQlRCRcE13a8neEz3F6we 08oWh2DnC4AXKbP+kuD9ZP6+5+x1H1zEzsFNBFXLn5EBEADn1959INH2cwYJv0tsxf5MUCgh Cj/CA/lc/LMthqQ773gauB9mN+F1rE9cyyXb6jyOGn+GUjMbnq1o121Vm0+neKHUCBtHyseB fDXHA6m4B3mUTWo13nid0e4AM71r0DS8+KYh6zvweLX/LL5kQS9GQeT+QNroXcC1NzWbitts 6TZ+IrPOwT1hfB4WNC+X2n4AzDqp3+ILiVST2DT4VBc11Gz6jijpC/KI5Al8ZDhRwG47LUiu Qmt3yqrmN63V9wzaPhC+xbwIsNZlLUvuRnmBPkTJwwrFRZvwu5GPHNndBjVpAfaSTOfppyKB Tccu2AXJXWAE1Xjh6GOC8mlFjZwLxWFqdPHR1n2aPVgoiTLk34LR/bXO+e0GpzFXT7enwyvF FFyAS0Nk1q/7EChPcbRbhJqEBpRNZemxmg55zC3GLvgLKd5A09MOM2BrMea+l0FUR+PuTenh 2YmnmLRTro6eZ/qYwWkCu8FFIw4pT0OUDMyLgi+GI1aMpVogTZJ70FgV0pUAlpmrzk/bLbRk F3TwgucpyPtcpmQtTkWSgDS50QG9DR/1As3LLLcNkwJBZzBG6PWbvcOyrwMQUF1nl4SSPV0L LH63+BrrHasfJzxKXzqgrW28CTAE2x8qi7e/6M/+XXhrsMYG+uaViM7n2je3qKe7ofum3s4v q7oFCPsOgwARAQABwsF8BBgBCAAmAhsMFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAmic2qsF CSZYCKEACgkQTd4Q9wD/g1oq0xAAsAnw/OmsERdtdwRfAMpC74/++2wh9RvVQ0x8xXvoGJwZ rk0Jmck1ABIM//5sWDo7eDHk1uEcc95pbP9XGU6ZgeiQeh06+0vRYILwDk8Q/y06TrTb1n4n 7FRwyskKU1UWnNW86lvWUJuGPABXjrkfL41RJttSJHF3M1C0u2BnM5VnDuPFQKzhRRktBMK4 GkWBvXlsHFhn8Ev0xvPE/G99RAg9ufNAxyq2lSzbUIwrY918KHlziBKwNyLoPn9kgHD3hRBa Yakz87WKUZd17ZnPMZiXriCWZxwPx7zs6cSAqcfcVucmdPiIlyG1K/HIk2LX63T6oO2Libzz 7/0i4+oIpvpK2X6zZ2cu0k2uNcEYm2xAb+xGmqwnPnHX/ac8lJEyzH3lh+pt2slI4VcPNnz+ vzYeBAS1S+VJc1pcJr3l7PRSQ4bv5sObZvezRdqEFB4tUIfSbDdEBCCvvEMBgoisDB8ceYxO cFAM8nBWrEmNU2vvIGJzjJ/NVYYIY0TgOc5bS9wh6jKHL2+chrfDW5neLJjY2x3snF8q7U9G EIbBfNHDlOV8SyhEjtX0DyKxQKioTYPOHcW9gdV5fhSz5tEv+ipqt4kIgWqBgzK8ePtDTqRM qZq457g1/SXSoSQi4jN+gsneqvlTJdzaEu1bJP0iv6ViVf15+qHuY5iojCz8fa0= In-Reply-To: <20251215150323.2218608-15-kevin.brodsky@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/15/25 16:03, Kevin Brodsky wrote: > Add basic KUnit tests for the generic aspects of the lazy MMU mode: > ensure that it appears active when it should, depending on how > enable/disable and pause/resume pairs are nested. > > Signed-off-by: Kevin Brodsky > --- > mm/Kconfig | 12 ++++++ > mm/Makefile | 1 + > mm/tests/lazy_mmu_mode_kunit.c | 71 ++++++++++++++++++++++++++++++++++ > 3 files changed, 84 insertions(+) > create mode 100644 mm/tests/lazy_mmu_mode_kunit.c > > diff --git a/mm/Kconfig b/mm/Kconfig > index 62073bd61544..ac48deb44884 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -1471,6 +1471,18 @@ config ARCH_HAS_LAZY_MMU_MODE > MMU-related architectural state to be deferred until the mode is > exited. See for details. > > +config LAZY_MMU_MODE_KUNIT_TEST > + tristate "KUnit tests for the lazy MMU mode" if !KUNIT_ALL_TESTS > + depends on ARCH_HAS_LAZY_MMU_MODE > + depends on KUNIT > + default KUNIT_ALL_TESTS > + help > + Enable this option to check that the lazy MMU mode interface behaves > + as expected. Only tests for the generic interface are included (not > + architecture-specific behaviours). > + > + If unsure, say N. > + > source "mm/damon/Kconfig" > > endmenu > diff --git a/mm/Makefile b/mm/Makefile > index 2d0570a16e5b..9175f8cc6565 100644 > --- a/mm/Makefile > +++ b/mm/Makefile > @@ -147,3 +147,4 @@ obj-$(CONFIG_SHRINKER_DEBUG) += shrinker_debug.o > obj-$(CONFIG_EXECMEM) += execmem.o > obj-$(CONFIG_TMPFS_QUOTA) += shmem_quota.o > obj-$(CONFIG_PT_RECLAIM) += pt_reclaim.o > +obj-$(CONFIG_LAZY_MMU_MODE_KUNIT_TEST) += tests/lazy_mmu_mode_kunit.o > diff --git a/mm/tests/lazy_mmu_mode_kunit.c b/mm/tests/lazy_mmu_mode_kunit.c > new file mode 100644 > index 000000000000..2720eb995714 > --- /dev/null > +++ b/mm/tests/lazy_mmu_mode_kunit.c > @@ -0,0 +1,71 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +#include > +#include > + > +static void expect_not_active(struct kunit *test) > +{ > + KUNIT_EXPECT_FALSE(test, is_lazy_mmu_mode_active()); > +} > + > +static void expect_active(struct kunit *test) > +{ > + KUNIT_EXPECT_TRUE(test, is_lazy_mmu_mode_active()); > +} > + > +static void lazy_mmu_mode_active(struct kunit *test) > +{ > + expect_not_active(test); > + > + lazy_mmu_mode_enable(); > + expect_active(test); > + > + { > + /* Nested section */ > + lazy_mmu_mode_enable(); > + expect_active(test); > + > + lazy_mmu_mode_disable(); > + expect_active(test); > + } > + > + { > + /* Paused section */ > + lazy_mmu_mode_pause(); > + expect_not_active(test); > + > + { > + /* No effect (paused) */ > + lazy_mmu_mode_enable(); > + expect_not_active(test); > + > + lazy_mmu_mode_disable(); > + expect_not_active(test); > + > + lazy_mmu_mode_pause(); > + expect_not_active(test); > + > + lazy_mmu_mode_resume(); > + expect_not_active(test); > + } > + > + lazy_mmu_mode_resume(); > + expect_active(test); > + } > + > + lazy_mmu_mode_disable(); > + expect_not_active(test); > +} > + > +static struct kunit_case lazy_mmu_mode_test_cases[] = { > + KUNIT_CASE(lazy_mmu_mode_active), > + {} > +}; > + > +static struct kunit_suite lazy_mmu_mode_test_suite = { > + .name = "lazy_mmu_mode", > + .test_cases = lazy_mmu_mode_test_cases, > +}; > +kunit_test_suite(lazy_mmu_mode_test_suite); > + > +MODULE_DESCRIPTION("Tests for the lazy MMU mode"); > +MODULE_LICENSE("GPL"); Very nice test :) I think I prefer the EXPORT_SYMBOL_IF_KUNIT over disabling the test for PPC and over making lazy_mmu_mode_enable() non-inlined functions with an exported symbol. With the EXPORT_SYMBOL_IF_KUNIT stuff added Acked-by: David Hildenbrand (Red Hat) -- Cheers David From xen-devel-bounces@lists.xenproject.org Fri Jan 09 16:12:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 16:12:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1198998.1515758 (Exim 4.92) (envelope-from ) id 1veF5g-0003Jz-0u; Fri, 09 Jan 2026 16:11:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1198998.1515758; Fri, 09 Jan 2026 16: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 1veF5f-0003Jr-Tk; Fri, 09 Jan 2026 16:11:55 +0000 Received: by outflank-mailman (input) for mailman id 1198998; Fri, 09 Jan 2026 16:11:54 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veF5e-0003Jl-Bf for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 16:11:54 +0000 Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [2607:f8b0:4864:20::1035]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e78b91dd-ed75-11f0-9ccf-f158ae23cfc8; Fri, 09 Jan 2026 17:11:51 +0100 (CET) Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-34c2f335681so2668978a91.1 for ; Fri, 09 Jan 2026 08:11:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e78b91dd-ed75-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767975109; x=1768579909; 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=gEH9Q0bFt+Qq2mQMmJFh6QASYza1Bi55SwhtogIKItk=; b=APMrJDxfpqv67D8OJu2TbmZxllOuuWOfAc2QqHnOe4Tz86zYb1ch8h8kUOuD1NjDhc GT87sEj7saFbxNFUqEaEWmt5A0SyVxlvfsi5FldautvoKeaAAJl95ZQzZoXoIRuv4O82 WenaDpyzQH68Yf0GYGh5BOrOijaJFgXdL4/hnS6I3UlCxs6zsZca8Tu/8SK5TSpb+UyB tkJAenIUJDGXWSlMaDtEXeq2KyOx7ZKr05oKnbnitkMZl7GxexECUqUTzp3sg8U7DYJO JrJ2Na9CUSp4T18Q0UUR1D5bz8hbXhgf928cQNWC6ioCU9nIff0ZfbheDKVDP2hMe6Xd XQ6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767975109; x=1768579909; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gEH9Q0bFt+Qq2mQMmJFh6QASYza1Bi55SwhtogIKItk=; b=RCaiXoOBiQQXygqfQkXry3tV76BApKtLHHEyhVo3BrJHnoUAONkz1F1e6wmbZG/963 1Klb3/6VyKhNnFFkNl4QSo22oRh6HfhqutkUtdR1WNr59qJX0MIkWl2oG8blIUzdOoiX 2ClUg1X9E7qmAi6YO+p1W8Yy4nyGs5bWa5iJI7sYIC99CPlJBjY1t63N3qCX/aJR+Ecm J3OPcsJnXyRmk8At9PyQ8d0gGA6UgmFHHP4TjGP6OAtWK0vmCEbrCk+cTCt4mdSVDAxU rOnVt+Sb99yc2su+JBSWwFgPhD90HLEUKPqGAQ7h3GlUigBdLgcchM665E81FugHJIyc UzOg== X-Forwarded-Encrypted: i=1; AJvYcCUfhlbnn+8Jp9wcA2ddNb1PRz4YfiD8WhKnWk5P0dgLIsQD5USv78A2p0cISN5Z/fOmpx/Rk9gGObY=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzzan6hBZ0o4aQZH0EVXquq2F0SuNmrAVUquLOLpNSun5kluyzz cc2Di2uUr7np7EItpQ3FbCNYIi8CjkIKXGHjgymNYgspy+EHRDJ1WSoHdQoNv7BBh/kQKTrIPm7 Iazurwr1JcFeRRHCwHvs8Y2Q+vnMzd+8= X-Gm-Gg: AY/fxX4Eobd17sirPli/mDGaqHJGGVT/UZbC9YSdwkJAiMiJMHkZGSZqiiAIlCMEI+F NWJ+P/z2Yb49ap2rywlZCYJSSP1Tz+s6wPMLXpjBQXym0Ey33c31W1r+d5ldIJ/AkqlXLSj81h3 N6lBU0R3upG0eC/ShSOTpX41feYriixEHnp8WAK/9sg5zoI/xL6tYIkOQHBRndLgv+4XfqUZWce DPPxDgOlQwsLxIFSfCquCkj6nAkKHr4g/uLR7TSqVLCDuU59sTwLTmYXzfjOtzs3q43BgfH X-Google-Smtp-Source: AGHT+IH2wb+FwZvJbgNRmwy0W13B7yvAacE0Iz1I8KRT5um0OT/N47DnZApdMIeTjWmfSVe8qjZ+L0Ms2IHiJ8Ld6cQ= X-Received: by 2002:a17:90b:5708:b0:34a:b459:bd10 with SMTP id 98e67ed59e1d1-34f68cc2ab3mr10225709a91.24.1767975107789; Fri, 09 Jan 2026 08:11:47 -0800 (PST) MIME-Version: 1.0 References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> <4a6b6307-9014-4c4c-8c23-3673efa2d1b1@gmail.com> <794c382b-3b20-4d2a-ab70-b24d7fdf88ae@suse.com> In-Reply-To: <794c382b-3b20-4d2a-ab70-b24d7fdf88ae@suse.com> From: Anton Markov Date: Fri, 9 Jan 2026 19:11:35 +0300 X-Gm-Features: AQt7F2oJu1fyDisoxNbS6cyfB0pi5gA3GNhJxlYcG2-cDlx-qLWdlmth3nCNQOw Message-ID: Subject: Re: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() To: Jan Beulich Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="0000000000004592620647f6c838" --0000000000004592620647f6c838 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You're right. These aren't interrupts in get_s_time_fixed, but rather a cumulative error in the sequence due to integer rounding. I added logging of the current local_stime to local_time_calibration and noticed that the timestamp between cores is gradually increasing. If the server has been running for weeks, this could be a very large value. ``` @@ -1732,6 +1753,8 @@ static void cf_check local_time_calibration(void) if ( boot_cpu_has(X86_FEATURE_CONSTANT_TSC) ) { /* Atomically read cpu_calibration struct and write cpu_time struct. */ + printk("update stime on time calibrate %d, %lu -> %lu (%lu, %lu)\n", smp_processor_id(), t->stamp.local_stime, c->local_stime, + t->last_seen_ns, t->last_seen_tsc); local_irq_disable(); t->stamp =3D *c; local_irq_enable(); ``` 2 hours of work: ``` (XEN) update stime on time calibrate 0, 8564145820102 -> 8565145861597 (8565145862216, 0) (XEN) update stime on time calibrate 1, 8564145820129 -> 8565145861609 (8565145863957, 0) (XEN) update stime on time calibrate 3, 8564145819996 -> 8565145861491 (8565145864800, 0) (XEN) update stime on time calibrate 2, 8564145820099 -> 8565145861609 (8565145865372, 0) 8565145861609 - 8565145861491 =3D 115 * 3 (3.00 GHz) =3D 345 lag ``` 6 hours of work: ``` (XEN) update stime on time calibrate 0, 22914730829200 -> 22915730869993 (22915730870665, 0) (XEN) update stime on time calibrate 1, 22914730829073 -> 22915730869889 (22915730870693, 0) (XEN) update stime on time calibrate 2, 22914730829052 -> 22915730869841 (22915730872231, 0) (XEN) update stime on time calibrate 3, 22914730828892 -> 22915730869696 (22915730872096, 0) 22915730869993 - 22915730869696 =3D 297 * 3 (3.00 GHz) =3D 891 lag ``` Clarification, according to my xen settings: ``` ucode=3Dscan dom0_mem=3D53923M,max:53923M dom0_max_vcpus=3D4-96 dom0_vcpus_= pin=3D0 force-ept=3D1 ept=3Dno-ad,no-pml hap_1gb=3D0 hap_2mb=3D0 altp2m=3D1 hpet=3Dlegacy-replacement smt=3D1 spec-ctrl=3Dno gnttab_max_frames=3D512 cpufreq=3Dxen:performance max_cstate=3D1 sched=3Dcredit sched-gran=3Dcpu ap= icv=3D0 sched_credit_tslice_ms=3D5 sched_ratelimit_us=3D500 ``` Processors I tested on: ``` Intel(R) Core(TM) i5-3330 CPU @ 3.00GHz Flags: fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid tsc_known_freq pni pclmulqdq monitor est ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c hypervisor lahf_lm cpuid_fault fsgsbase erms xsaveopt arch_capabilities ``` ``` Intel(R) Xeon(R) Gold 5318Y CPU @ 2.10GHz x2 (NUMA) Flags: fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid tsc_known_freq pni pclmulqdq monitor est ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault ibpb fsgsbase bmi1 avx2 bmi2 erms rtm avx512f avx512dq rdseed adx avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 avx512vbmi avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid fsrm md_clear arch_capabilities ``` Next I moved the code to r3 to speed up playback: ``` #include #include static __inline__ unsigned long long rdtsc(void) { unsigned hi, lo; __asm__ __volatile__ ("rdtsc" : "=3Da"(lo), "=3Dd"(hi)); return ( (unsigned long long)lo)|( ((unsigned long long)hi)<<32 ); } #define MILLISECS(_ms) ((int64_t)((_ms) * 1000000ULL)) struct cpu_time_stamp { uint64_t local_tsc; int64_t local_stime; int64_t master_stime; }; struct time_scale { int shift; uint32_t mul_frac; }; static inline uint32_t div_frac(uint32_t dividend, uint32_t divisor) { uint32_t quotient, remainder; asm ( "divl %4" : "=3Da" (quotient), "=3Dd" (remainder) : "0" (0), "1" (dividend), "r" (divisor) ); return quotient; } void set_time_scale(struct time_scale *ts, uint64_t ticks_per_sec) { uint64_t tps64 =3D ticks_per_sec; uint32_t tps32; int shift =3D 0; while ( tps64 > (MILLISECS(1000)*2) ) { tps64 >>=3D 1; shift--; } tps32 =3D (uint32_t)tps64; while ( tps32 <=3D (uint32_t)MILLISECS(1000) ) { tps32 <<=3D 1; shift++; } ts->mul_frac =3D div_frac(MILLISECS(1000), tps32); ts->shift =3D shift; } uint64_t scale_delta(uint64_t delta, const struct time_scale *scale) { uint64_t product; if ( scale->shift < 0 ) delta >>=3D -scale->shift; else delta <<=3D scale->shift; asm ( "mulq %2 ; shrd $32,%1,%0" : "=3Da" (product), "=3Dd" (delta) : "rm" (delta), "0" ((uint64_t)scale->mul_frac) ); return product; } #define _TS_MUL_FRAC_IDENTITY 0x80000000UL static inline struct time_scale scale_reciprocal(struct time_scale scale) { struct time_scale reciprocal; uint32_t dividend; dividend =3D _TS_MUL_FRAC_IDENTITY; reciprocal.shift =3D 1 - scale.shift; while ( dividend >=3D scale.mul_frac ) { dividend >>=3D 1; reciprocal.shift++; } asm ( "divl %4" : "=3Da" (reciprocal.mul_frac), "=3Dd" (dividend) : "0" (0), "1" (dividend), "r" (scale.mul_frac) ); return reciprocal; } int64_t get_s_time_fixed(const struct cpu_time_stamp *t, const struct time_scale *ts, uint64_t at_tsc) { uint64_t tsc, delta; if ( at_tsc ) tsc =3D at_tsc; else tsc =3D rdtsc(); delta =3D tsc - t->local_tsc; return t->local_stime + scale_delta(delta, ts); } int main() { struct cpu_time_stamp ct; struct time_scale ts; struct time_scale back; uint64_t start =3D rdtsc(); set_time_scale(&ts, 3000000000); back =3D scale_reciprocal(ts); ct.local_tsc =3D start; ct.local_stime =3D scale_delta(start, &ts); while (1) { uint64_t new_tsc =3D rdtsc(); ct.local_stime =3D get_s_time_fixed(&ct, &ts, new_tsc); ct.local_tsc =3D new_tsc; uint64_t tmp_tsc =3D rdtsc(); printf("%lu %lu\n", tmp_tsc, scale_delta(get_s_time_fixed(&ct, &ts, tmp_tsc), &back)); } return 0; } ``` It's enough to run the loop for 10-20 seconds to see the problem. scale_delta rounds the least significant bits during calculation, which causes the error to accumulate, at different rates on different cores, depending on the least significant bits at the time of calibration. Now let's talk about why dwm reacts this way. When a snapshot is reversed, last_guest_time in hvm_get_guest_time_fixed is set to 0, which doesn't prevent time from flowing backwards. This means that cache_tsc_offset in hvm_get_guest_tsc_fixed may be configured correctly on one physical core, but due to shedding on a physical core with a lagging tsc, the guest may occasionally see a tsc value lower than it saw before the snapshot was reversed. If this happens to the dwm code, it terminates with an error. A quick solution to this problem might be to save the last_seen_tsc parameter in a snapshot for each core, followed by validation. The correct solution is to remove the rounding of the least significant bits from the sequence. On Wed, Jan 7, 2026 at 11:02=E2=80=AFAM Jan Beulich wro= te: > On 06.01.2026 21:10, =D0=90=D0=BD=D1=82=D0=BE=D0=BD =D0=9C=D0=B0=D1=80=D0= =BA=D0=BE=D0=B2 wrote: > > Hi, I'm not sure about the other places. In hvm_load_cpu_ctxt > > (xen/arch/x86/hvm/hvm.c ), it was easy to catch because > > process_pending_softirqs is frequently called there, which in turn > > processes softirqs from the timer (where the timestamp is updated). > > After I fixed sync_tsc in hvm_load_cpu_ctxt, the problem stopped > > reproducing under no load. However, when the number of vCPUs is 4 times > > greater than the number of CPUs (under heavy load), the problem rarely > > reoccurs (mostly during snapshot restores during > > process_pending_softirqs calls), and this is no longer a simple case. I= f > > get_s_time_fixed can indeed be interrupted during execution after > > rdtsc_ordered, then the current fix is =E2=80=8B=E2=80=8Binsufficient. = It's necessary to > > atomically copy "t->stamp" to the stack using local_irq_disable and > > local_irq_enable (as in local_time_calibration), and then work with the > > copy, confident in its lifetime and immutability. But until > > get_s_time_fixed is proven to be interruptible, this is premature, so > > your fix is =E2=80=8B=E2=80=8Bsufficient. I think I need more informati= on and testing to > > say more. > > While the cpu_calibration per-CPU variable is updated from IRQ context, > the cpu_time one isn't. Hence t->stamp's contents cannot change behind > the back of get_s_time_fixed(). I wonder whether ... > > > Regarding the other scale_delta calls, if they include values > =E2=80=8B=E2=80=8B> calculated from externally saved tsc values =E2=80=8B= =E2=80=8Bthat could have become > > stale during the process_pending_softirqs call, this definitely needs t= o > > be fixed. > > ... another similar issue (possibly one not included in the set of > remarks I have in the patch, as none of those look related to what you > describe) might be causing the remaining, more rare problems you say you > see. That set of remarks is actually a result of me going over all other > scale_delta() calls, but of course I may have got the analysis wrong. > > As to using 4 times as many vCPU-s as there are pCPU-s (and then heavy > load) - while I don't think we have a support statement for such upstream > (when probably we should), iirc for our (SUSE's) products we would > consider that unsupported. Just fyi. > > Also, btw, please don't top-post. > > Jan > --0000000000004592620647f6c838 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=09 =09 =09

You're right. These aren't interrupts in get_s_time_fixed, but rather a cumulative error in the sequence due to integer rounding. I added logging of the current local_stime to local_time_calibration and noticed that the timestamp between cores is gradually increasing. If the server has been running for weeks, this could be a very large value.


```<= /p>

@@ -1732,6 +1753,8 @@ static void cf_check local_time_calibration(void)=

if ( boot_cpu_has(X86_FEATURE_CONSTANT_TSC) )

{

/* Atomically read cpu_calibration struct and write cpu_time struct. */=

+ printk("update stime on time calibrate %d, %lu -> %lu (%lu, %lu)\n", smp_processor_id(), t->stamp.local_stime, c->local_stime,

+ t->last_seen_ns, t->last_seen_tsc);

=20 local_irq_disable();

=20 t->stamp =3D *c;

=20 local_irq_enable();

```


2 hours of work:


```

(XEN= ) update stime on time calibrate 0, 8564145820102 -> 8565145861597 (8565145862216, 0)

(XEN= ) update stime on time calibrate 1, 8564145820129 -> 8565145861609 (8565145863957, 0)

(XEN= ) update stime on time calibrate 3, 8564145819996 -> 8565145861491 (8565145864800, 0)

(XEN= ) update stime on time calibrate 2, 8564145820099 -> 8565145861609 (8565145865372, 0)


8565= 145861609 -=20 8565145861491 =3D 115 * 3 (3.00 GHz) =3D 345 lag

```<= /p>


6 hours of work:

```<= /p>

(XEN= ) update stime on time calibrate 0, 22914730829200 -> 22915730869993 (22915730870665, 0)

(XEN= ) update stime on time calibrate 1, 22914730829073 -> 22915730869889 (22915730870693, 0)

(XEN= ) update stime on time calibrate 2, 22914730829052 -> 22915730869841 (22915730872231, 0)

(XEN= ) update stime on time calibrate 3, 22914730828892 -> 22915730869696 (22915730872096, 0)


2291= 5730869993 -=20 22915730869696 =3D 297 * 3 (3.00 GHz) =3D 891 lag

```<= /p>


Clarification, according to my xen settings:

```

ucod= e=3Dscan dom0_mem=3D53923M,max:53923M dom0_max_vcpus=3D4-96 dom0_vcpus_pin=3D0 force-ept=3D1 ept=3Dno-ad,no-pml hap_1gb=3D0 hap_2mb=3D0 altp2m=3D1 hpet=3Dlegacy-replacement smt=3D1 spec-ctrl=3Dno gnttab_max_frames=3D512 cpufreq=3Dxen:performance max_cstate=3D1 sched=3Dcredit sched-gran=3Dcpu apicv=3D0 sched_credit_tslice_ms=3D5 sched_ratelimit_us=3D500

```<= /p>


Proc= essors I tested on:


```<= /p>

Inte= l(R) Core(TM) i5-3330 CPU @ 3.00GHz


Flag= s: =20 fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid tsc_known_freq pni pclmulqdq monitor est ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c hypervisor lahf_lm cpuid_fault fsgsbase erms xsaveopt arch_capabilities

```<= /p>

```<= /p>

Inte= l(R) Xeon(R) Gold 5318Y CPU @ 2.10GHz x2 (NUMA)


Flag= s: =20 fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid tsc_known_freq pni pclmulqdq monitor est ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault ibpb fsgsbase bmi1 avx2 bmi2 erms rtm avx512f avx512dq rdseed adx avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 avx512vbmi avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid fsrm md_clear arch_capabilities

```<= /p>


Next= I moved the code to r3 to speed up playback:


```<= /p>

#inc= lude <stdint.h>

#inc= lude <stdio.h>


stat= ic __inline__ unsigned long long rdtsc(void)

{

= unsigned hi, lo;

= __asm__ __volatile__ ("rdtsc" : "=3Da"(lo), "=3Dd"(hi= ));

= return ( (unsigned long long)lo)|( ((unsigned long long)hi)<<32 );

}


#def= ine MILLISECS(_ms) ((int64_t)((_ms) * 1000000ULL))


stru= ct cpu_time_stamp {

= uint64_t local_tsc;

= int64_t local_stime;

= int64_t master_stime;

};


stru= ct time_scale {

= int shift;

= uint32_t mul_frac;

};



stat= ic inline uint32_t div_frac(uint32_t dividend, uint32_t divisor)

{

= uint32_t quotient, remainder;

= asm (

= "divl %4"

= : "=3Da" (quotient), "=3Dd" (remainder)

= : "0" (0), "1" (dividend), "r" (divisor) );

= return quotient;

}



void set_time_scale(struct time_scale *ts, uint64_t ticks_per_sec)

{

= uint64_t tps64 =3D ticks_per_sec;

= uint32_t tps32;

= int shift =3D 0;


= while ( tps64 > (MILLISECS(1000)*2) )

= {

= tps64 >>=3D 1;

= shift--;

= }


= tps32 =3D (uint32_t)tps64;

= while ( tps32 <=3D (uint32_t)MILLISECS(1000) )

= {

= tps32 <<=3D 1;

= shift++;

= }


= ts->mul_frac =3D div_frac(MILLISECS(1000), tps32);

= ts->shift =20 =3D shift;

}



uint= 64_t scale_delta(uint64_t delta, const struct time_scale *scale)

{

= uint64_t product;


= if ( scale->shift < 0 )

= delta >>=3D -scale->shift;

= else

= delta <<=3D scale->shift;


= asm (

= "mulq %2 ; shrd $32,%1,%0"

= : "=3Da" (product), "=3Dd" (delta)

= : "rm" (delta), "0" ((uint64_t)scale->mul_frac) );


= return product;

}


#def= ine _TS_MUL_FRAC_IDENTITY 0x80000000UL


stat= ic inline struct time_scale scale_reciprocal(struct time_scale scale)

{

= struct time_scale reciprocal;

= uint32_t dividend;


= dividend =3D _TS_MUL_FRAC_IDENTITY;

= reciprocal.shift =3D 1 - scale.shift;

= while ( dividend >=3D scale.mul_frac )

= {

= dividend >>=3D 1;

= =20 reciprocal.shift++;

= }


= asm (

= "divl %4"

= : "=3Da" (reciprocal.mul_frac), "=3Dd" (dividend)

= : "0" (0), "1" (dividend), "r" (scale.mul_frac) );


= return reciprocal;

}



int6= 4_t get_s_time_fixed(const struct cpu_time_stamp *t, const struct time_scale *ts, uint64_t at_tsc)

{

= uint64_t tsc, delta;


= if ( at_tsc )

= tsc =3D at_tsc;

= else

= tsc =3D rdtsc();

= delta =3D tsc - t->local_tsc;

= return t->local_stime + scale_delta(delta, ts);

}


int = main() {


= struct cpu_time_stamp ct;

= struct time_scale ts;

= struct time_scale back;


= uint64_t start =3D rdtsc();


= =20 set_time_scale(&ts, 3000000000);

= back =3D scale_reciprocal(ts);


= ct.local_tsc =3D start;

= ct.local_stime =3D scale_delta(start, &ts);


= while (1) {

= uint64_t new_tsc =3D rdtsc();

= =20 ct.local_stime =3D get_s_time_fixed(&ct, &ts, new_tsc);

= ct.local_tsc =3D new_tsc;


= uint64_t tmp_tsc =3D rdtsc();

= printf("%lu %lu\n", tmp_tsc, scale_delta(get_s_time_fixed(&ct, &ts, tmp_tsc), &back));

= }


= return 0;

}

```<= /p>


It&#= 39;s enough to run the loop for 10-20 seconds to see the problem. scale_delta rounds the least significant bits during calculation, which causes the error to accumulate, at different rates on different cores, depending on the least significant bits at the time of calibration.


Now = let's talk about why dwm reacts this way. When a snapshot is reversed, last_guest_time in hvm_get_guest_time_fixed is set to 0, which doesn't prevent time from flowing backwards. This means that cache_tsc_offset in hvm_get_guest_tsc_fixed may be configured correctly on one physical core, but due to shedding on a physical core with a lagging tsc, the guest may occasionally see a tsc value lower than it saw before the snapshot was reversed. If this happens to the dwm code, it terminates with an error.=20


A qu= ick solution to this problem might be to save the last_seen_tsc parameter in a snapshot for each core, followed by validation.


The = correct solution is to remove the rounding of the least significant bits from the sequence.


On Wed, Jan 7, 2026 at 11:02=E2=80=AFAM Jan Beulich &= lt;jbeulich@suse.com> wrote:
On 06.01.2026 21:1= 0, =D0=90=D0=BD=D1=82=D0=BE=D0=BD =D0=9C=D0=B0=D1=80=D0=BA=D0=BE=D0=B2 wrot= e:
> Hi, I'm not sure about the other places. In hvm_load_cpu_ctxt
> (xen/arch/x86/hvm/hvm.c ), it was easy to catch because
> process_pending_softirqs is frequently called there, which in turn > processes softirqs from the timer (where the timestamp is updated). > After I fixed sync_tsc in hvm_load_cpu_ctxt, the problem stopped
> reproducing under no load. However, when the number of vCPUs is 4 time= s
> greater than the number of CPUs (under heavy load), the problem rarely=
> reoccurs (mostly during snapshot restores during
> process_pending_softirqs calls), and this is no longer a simple case. = If
> get_s_time_fixed can indeed be interrupted during execution after
> rdtsc_ordered, then the current fix is =E2=80=8B=E2=80=8Binsufficient.= It's necessary to
> atomically copy "t->stamp" to the stack using local_irq_d= isable and
> local_irq_enable (as in local_time_calibration), and then work with th= e
> copy, confident in its lifetime and immutability. But until
> get_s_time_fixed is proven to be interruptible, this is premature, so =
> your fix is =E2=80=8B=E2=80=8Bsufficient. I think I need more informat= ion and testing to
> say more.

While the cpu_calibration per-CPU variable is updated from IRQ context,
the cpu_time one isn't. Hence t->stamp's contents cannot change = behind
the back of get_s_time_fixed(). I wonder whether ...

> Regarding the other scale_delta calls, if they include values
=E2=80=8B=E2=80=8B> calculated from externally saved tsc values =E2=80= =8B=E2=80=8Bthat could have become
> stale during the process_pending_softirqs call, this definitely needs = to
> be fixed.

... another similar issue (possibly one not included in the set of
remarks I have in the patch, as none of those look related to what you
describe) might be causing the remaining, more rare problems you say you see. That set of remarks is actually a result of me going over all other scale_delta() calls, but of course I may have got the analysis wrong.

As to using 4 times as many vCPU-s as there are pCPU-s (and then heavy
load) - while I don't think we have a support statement for such upstre= am
(when probably we should), iirc for our (SUSE's) products we would
consider that unsupported. Just fyi.

Also, btw, please don't top-post.

Jan
--0000000000004592620647f6c838-- From xen-devel-bounces@lists.xenproject.org Fri Jan 09 16:23:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 16:23:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1199014.1515768 (Exim 4.92) (envelope-from ) id 1veFGX-00053A-2x; Fri, 09 Jan 2026 16:23:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1199014.1515768; Fri, 09 Jan 2026 16:23: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 1veFGW-000533-Vx; Fri, 09 Jan 2026 16:23:08 +0000 Received: by outflank-mailman (input) for mailman id 1199014; Fri, 09 Jan 2026 16:23:08 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veFGW-00052x-7g for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 16:23:08 +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 7ac27f48-ed77-11f0-b15e-2bf370ae4941; Fri, 09 Jan 2026 17:23:06 +0100 (CET) Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-64b7318f1b0so6189015a12.2 for ; Fri, 09 Jan 2026 08:23:06 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6507b8c4454sm10870768a12.3.2026.01.09.08.23.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jan 2026 08:23:05 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7ac27f48-ed77-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767975786; x=1768580586; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=8SP4g6xKEmy1Piy8k2hQRTNGClSTpFc8kS3x04C1uek=; b=fuktFrBeSQWnAhbkcZ+T8F/Z9aeMVScOHctMOQrMD1TSQA+D5lx/j+9RajItl069Az se9W3/pz4dUTzMNHcr/Rw1v7xBde8tiWRlDceNl8u+cGZos2s6VySLh1lSAf8emaH3wl mnP1PccQugqMFdM69v4z3wZqwwdF6uXhTECAo/lhittWMqFDW2gQkkpVQWrKUx8n3Mnc g69bQrHWJT9IwNGgXMUCFaWk8mFG/AeSfT2sZbu8H8DM5w3gGGKOt6c9hCRAF00nvMK5 0XR4ruuMVUj2kkLpthmGdgh/uKtwfmIwK/Ttw+VJVjAq6MX7vf3m9TarxND9MKblWWZT xgWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767975786; x=1768580586; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8SP4g6xKEmy1Piy8k2hQRTNGClSTpFc8kS3x04C1uek=; b=Apg29w5843PzgiimL77bRSsv24/jcghinOM1Smioi/Hyp//FA7hwiBozfGbu4YcyWl rniywoUzlb6z6B29XASg0IqveF5O9ZfbHpbdbNEocm2UsCZpzRbXXGrEoL6HMyvSzLgE 3C+qpV3kAti8i/qerm+nlKbEspfGwNKWEbSltIz2IfMWWd1B5wByKTC/yORld0vsxpCv Qu+ZK/3x0MDQsER1PB2UuYcDr+4IW9k9gNtKE2gBMdBda73O+iCgN+Ej+qa4cZQJYMy3 CTGDjTS93hG+01Ds67HvOhoctVwB0hxO99xAmlQDEKh9fMpSaCcsvPj1xFykG82XSSqh 0vLQ== X-Forwarded-Encrypted: i=1; AJvYcCUBvX7RD5glvjp9njFepbeEZF5RFlybkyo5sdEJSPAUJGAEdF72GxvN/qMBEkTD8o/H9eN8bUizBHM=@lists.xenproject.org X-Gm-Message-State: AOJu0YydkH+TVwXT7ZXAxa5hM7gT8qeQHd+JUiC4Dr7RsH+vrqxDZoOS Q9qYMwMoKfphR0YEek7A4/L9JKXR/Ln1qKvV0psgUgnHxXInMDyz2uAP X-Gm-Gg: AY/fxX7aiO/U6LlCN1PXBPck4b3665Bx+BbGltodAN5sq+Lm80bmicKaw2w3ciAeeyN ceJRNpPErzgP6NyAoonBXX6Mlhip6OBVBXCERO/kWmAqrTiyJxnEUKmubZKU0zSs8KjRo8L1oXz MV6j53lW31ZNb6rWsa3rkZo+ATOJOznc24UvhRUrsGP9YEVL3WZFAQVVdc2o8TbM9J4l2NaeVTI CLY/G5VQTAJsmtT7s9OdFlE5zqAU5jjIRzDuqII9J0DioalfJv4TQy8ZMIK7EZJdUPGOQO0M+X0 iMJGXEtj6uzfgK6IgdwfrN6lUiuvwQeudpxsd/WmRQwggggTIkDHtC30xdrrYfLG4F2ZnJCaZnz i9H36gFnGbuhOYZt6S3bMEwxGwovyCjfEH9aMaSvzeleMLVxC4oquZj94maZ5gHlVcdj6v59AXN Hv0CXOJW9h/v+OPckxiGnOQX5t8V4847xvV1b1AZ4fLtnlxE05XykERfpU2YsmL8A= X-Google-Smtp-Source: AGHT+IGRHZk1LG8FKDOR1B7Q/+EHi7FTpi8oRnpe4hOVE1phkaG/lxcsXYSV32JC7d3F4VlnSJzpqw== X-Received: by 2002:a05:6402:1453:b0:650:2820:38bd with SMTP id 4fb4d7f45d1cf-65097de5b35mr10311835a12.11.1767975785826; Fri, 09 Jan 2026 08:23:05 -0800 (PST) Message-ID: Date: Fri, 9 Jan 2026 17:23:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Oleksii Kurochko Subject: Re: [PATCH v3] acpi/arm: relax MADT GICC entry length check to support newer ACPI revisions To: Jan Beulich Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Yann Dirson , Yann Sionneau , xen-devel@lists.xenproject.org References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/9/26 11:03 AM, Jan Beulich wrote: > On 09.01.2026 10:27, Oleksii Kurochko wrote: >> Newer ACPI revisions define the MADT GICC entry with Length = 82 bytes [1]. >> The current BAD_MADT_GICC_ENTRY() check rejects entries whose length does not >> match the known values, which leads to: >> GICv3: No valid GICC entries exist. >> as observed on the AmpereOne platform. >> >> To fix this, import the logic from Linux commit 9eb1c92b47c7: >> The BAD_MADT_GICC_ENTRY check is a little too strict because >> it rejects MADT entries that don't match the currently known >> lengths. We should remove this restriction to avoid problems >> if the table length changes. Future code which might depend on >> additional fields should be written to validate those fields >> before using them, rather than trying to globally check >> known MADT version lengths. >> >> Link:https://lkml.kernel.org/r/20181012192937.3819951-1-jeremy.linton@arm.com >> Signed-off-by: Jeremy Linton >> [lorenzo.pieralisi@arm.com: added MADT macro comments] >> Signed-off-by: Lorenzo Pieralisi >> Acked-by: Sudeep Holla >> Cc: Will Deacon >> Cc: Catalin Marinas >> Cc: Al Stone >> Cc: "Rafael J. Wysocki" >> Signed-off-by: Will Deacon >> >> As ACPI_MADT_GICC_LENGTH is dropped, update the functions where it is >> used. As we rewrite the MADT for hwdom, reuse the host GICC header length >> instead of ACPI_MADT_GICC_LENGTH. >> >> Mark gic_get_hwdom_madt_size() as __init since its only caller is also >> __init. >> >> [1]https://uefi.org/specs/ACPI/6.6/05_ACPI_Software_Programming_Model.html#gic-cpu-interface-gicc-structure >> >> Reported-By: Yann Dirson >> Co-developed-by: Yann Sionneau >> Signed-off-by: Oleksii Kurochko >> --- >> I ran CI tests where it made sense for this patch, as I don’t see any CI job >> that builds Xen with CONFIG_ACPI=y: >> https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/2252409762 >> >> I also built Xen manually with CONFIG_ACPI=y enabled and tested it on the >> AmpereOne platform. >> --- >> xen/arch/arm/acpi/domain_build.c | 6 ++++++ >> xen/arch/arm/gic-v2.c | 3 ++- >> xen/arch/arm/gic-v3.c | 3 ++- >> xen/arch/arm/gic.c | 13 +++++++++++-- >> xen/arch/arm/include/asm/acpi.h | 21 +++++++++++++++------ >> 5 files changed, 36 insertions(+), 10 deletions(-) >> >> diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c >> index 1c3555d814cc..959698d13ac3 100644 >> --- a/xen/arch/arm/acpi/domain_build.c >> +++ b/xen/arch/arm/acpi/domain_build.c >> @@ -458,6 +458,12 @@ static int __init estimate_acpi_efi_size(struct domain *d, >> acpi_size += ROUNDUP(sizeof(struct acpi_table_stao), 8); >> >> madt_size = gic_get_hwdom_madt_size(d); >> + if ( !madt_size ) >> + { >> + printk("Unable to get hwdom MADT size\n"); >> + return -EINVAL; >> + } >> + >> acpi_size += ROUNDUP(madt_size, 8); >> >> addr = acpi_os_get_root_pointer(); >> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c >> index b23e72a3d05d..aae6a7bf3076 100644 >> --- a/xen/arch/arm/gic-v2.c >> +++ b/xen/arch/arm/gic-v2.c >> @@ -1121,7 +1121,8 @@ static int gicv2_make_hwdom_madt(const struct domain *d, u32 offset) >> host_gicc = container_of(header, struct acpi_madt_generic_interrupt, >> header); >> >> - size = ACPI_MADT_GICC_LENGTH; >> + size = host_gicc->header.length; >> + >> /* Add Generic Interrupt */ >> for ( i = 0; i < d->max_vcpus; i++ ) >> { >> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c >> index bc07f97c16ab..75b89efad462 100644 >> --- a/xen/arch/arm/gic-v3.c >> +++ b/xen/arch/arm/gic-v3.c >> @@ -1672,7 +1672,8 @@ static int gicv3_make_hwdom_madt(const struct domain *d, u32 offset) >> >> host_gicc = container_of(header, struct acpi_madt_generic_interrupt, >> header); >> - size = ACPI_MADT_GICC_LENGTH; >> + size = host_gicc->header.length; >> + >> for ( i = 0; i < d->max_vcpus; i++ ) >> { >> gicc = (struct acpi_madt_generic_interrupt *)(base_ptr + table_len); >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c >> index ee75258fc3c3..e4fcfd60205d 100644 >> --- a/xen/arch/arm/gic.c >> +++ b/xen/arch/arm/gic.c >> @@ -414,12 +414,21 @@ int gic_make_hwdom_madt(const struct domain *d, u32 offset) >> return gic_hw_ops->make_hwdom_madt(d, offset); >> } >> >> -unsigned long gic_get_hwdom_madt_size(const struct domain *d) >> +unsigned long __init gic_get_hwdom_madt_size(const struct domain *d) >> { >> unsigned long madt_size; >> + const struct acpi_subtable_header *header; >> + const struct acpi_madt_generic_interrupt *host_gicc; >> + >> + header = acpi_table_get_entry_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT, 0); >> + if ( !header ) >> + return 0; >> + >> + host_gicc = container_of(header, const struct acpi_madt_generic_interrupt, >> + header); >> >> madt_size = sizeof(struct acpi_table_madt) >> - + ACPI_MADT_GICC_LENGTH * d->max_vcpus >> + + host_gicc->header.length * d->max_vcpus > Just to double-check: All entries are strictly required to be of the same > length? (Related question further down.) If I understood the ACPI spec correctly, then yes, it should be the same length, as|GICC->length| is defined as a well defined constant value (82 in ACPI 6.6): https://uefi.org/specs/ACPI/6.6/05_ACPI_Software_Programming_Model.html#gic-cpu-interface-gicc-structure >> --- a/xen/arch/arm/include/asm/acpi.h >> +++ b/xen/arch/arm/include/asm/acpi.h >> @@ -53,13 +53,22 @@ void acpi_smp_init_cpus(void); >> */ >> paddr_t acpi_get_table_offset(struct membank tbl_add[], EFI_MEM_RES index); >> >> -/* Macros for consistency checks of the GICC subtable of MADT */ >> -#define ACPI_MADT_GICC_LENGTH \ >> - (acpi_gbl_FADT.header.revision < 6 ? 76 : 80) > Given this, ... > >> +/* >> + * MADT GICC minimum length refers to the MADT GICC structure table length as >> + * defined in the earliest ACPI version supported on arm64, ie ACPI 5.1. >> + * >> + * The efficiency_class member was added to the >> + * struct acpi_madt_generic_interrupt to represent the MADT GICC structure >> + * "Processor Power Efficiency Class" field, added in ACPI 6.0 whose offset >> + * is therefore used to delimit the MADT GICC structure minimum length >> + * appropriately. >> + */ >> +#define ACPI_MADT_GICC_MIN_LENGTH ACPI_OFFSET( \ >> + struct acpi_madt_generic_interrupt, efficiency_class) >> >> -#define BAD_MADT_GICC_ENTRY(entry, end) \ >> - (!(entry) || (unsigned long)(entry) + sizeof(*(entry)) > (end) || \ >> - (entry)->header.length != ACPI_MADT_GICC_LENGTH) >> +#define BAD_MADT_GICC_ENTRY(entry, end) \ >> + (!(entry) || (entry)->header.length < ACPI_MADT_GICC_MIN_LENGTH || \ >> + (unsigned long)(entry) + (entry)->header.length > (end)) > ... is 76 a valid length when the FADT revision is 6 or higher? And 80 is a > valid length for 6.5 or higher? I'm not ACPI expert but my understanding that it isn't "very valid" values as I mentioned above GICC->length is defined as a constant value. But the idea here is to provide forward compatibility so only minumum MADT GICC length is checked and as mentioned here [1] by one of ACPI for Arm64 maintainer: > - (acpi_gbl_FADT.header.revision < 6 ? 76 : 80) > +#define ACPI_MADT_GICC_MIN_LENGTH ACPI_OFFSET( \ > + struct acpi_madt_generic_interrupt, efficiency_class) > > This makes it 76 always which is fine, just that the first user of > efficiency_class should check for the length before accessing it. > No user of efficiency_class yet, so I am fine with this change. And I think the same is true for ACPI 6.3 which adds spe_interrupt and ACPI 6.5 trbe_interrupt. [1]https://lore.kernel.org/all/20181015092919.GA1778@e107155-lin/ ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Jan 09 16:57:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 16:57:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1199057.1515804 (Exim 4.92) (envelope-from ) id 1veFnu-00013a-Rx; Fri, 09 Jan 2026 16:57:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1199057.1515804; Fri, 09 Jan 2026 16:57:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veFnu-00013T-P5; Fri, 09 Jan 2026 16:57:38 +0000 Received: by outflank-mailman (input) for mailman id 1199057; Fri, 09 Jan 2026 16:57: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 1veFnt-0000yu-T8 for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 16:57:38 +0000 Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4aed26d2-ed7c-11f0-9ccf-f158ae23cfc8; Fri, 09 Jan 2026 17:57:35 +0100 (CET) Received: by mx.zohomail.com with SMTPS id 1767977839225707.6571521088505; Fri, 9 Jan 2026 08:57:19 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4aed26d2-ed7c-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; t=1767977843; cv=none; d=zohomail.com; s=zohoarc; b=NrvQZ+WEsNu3od5jRs8K+Y25SXxrndtw+ZWhW11HsPZrx/s9uwXx7lItsm/ivCsnOMqwf20df60MbQn2HxB+TpGP61/Fyz2gbuT4jYK8qXTRKSDpMtgjx9MavZ3Djm+Khzz7T9UoVeZywRy3xlaJrbENBn4K2R0iCZKIefTigq4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1767977843; 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=FqrQZsDWWC9rsLw4KZMTRKa+EtTjkMhOkcSh5eOTJVM=; b=lV0wtzf6RQ7rQTRyqqb++1fclfwWuk47dkY1CqQErMStK7x7HcpHLgzvJa8JoYbs6TDLSaEYCuatW5Ll1Ft3f23BERG08mOVuT3zZEzDYzcY7a7eKOHTAVfbSj4h9SksP53VddCTmlzB0r0DzgYoEK1haARL7+oaA7ocZSllEw0= 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=1767977843; s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=FqrQZsDWWC9rsLw4KZMTRKa+EtTjkMhOkcSh5eOTJVM=; b=FyC3G/FzSx0tWtm9MY+oteMphH3eYzYbdsr0uavrEtVOy0Qv1D+8zKxn3BPomTd9 hedci016IDf9zaIbTM3hjNvJMt0hxwZz/0A1sBzF6Ljfe9YQmR3hLDrlO3jheXDRNnY jxcFYGoufvkurgRoUDu0Y45yQsQcNWE9mgpr0lXs= Message-ID: <789062cc-d2e2-4aa5-b70a-384d5fa34a71@apertussolutions.com> Date: Fri, 9 Jan 2026 11:57:15 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen: Drop xenoprofile support To: Andrew Cooper , Xen-devel Cc: Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Oleksii Kurochko References: <20260105195717.601500-1-andrew.cooper3@citrix.com> Content-Language: en-US From: "Daniel P. Smith" In-Reply-To: <20260105195717.601500-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ZohoMailClient: External On 1/5/26 2:57 PM, Andrew Cooper wrote: > The most recent xenoprof change was 300ef0cb4fde ("x86: Add Xenoprofile > support for AMD Family16h") in 2013, despite there being 42 changes worth of > other cleanup/rearranging since then. > > Oprofile themselves dropped Xen support in commit 0c142c3a096d ("Remove > opcontrol and the GUI and processor models dependent on it") in 2014, as part > of releasing version 1.0 and switching over to using operf based on the Linux > perf_event subsystem. Linux's version of this patch was merged in commit > 24880bef417f ("Merge tag 'oprofile-removal-5.12'") in 2021. > > Drop xenoprof and all supporting infrastructure, including the hypercall, the > XSM hook and flask vectors which lose their only caller, and even shrinks > struct domain by one pointer which wasn't properly excluded in > !CONFIG_XENOPROF builds. > > Retain the public xenoprof.h header as it is ABI, but note that the > functionality is removed.there's also a patch of > > 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: Daniel P. Smith > > Despite appearing to be architecture neutral, the internals of Xenoprof were > entirely x86-specific. Another curiosity is that only the VMX MSR hooks > called passive_domain_do_{rd,wr}msr(), and I can't see how this was correct > for SVM. > > The real reason for finally getting around to this is the number of MISRA > violations reported by the eclair-x86_64-allcode job that I don't feel like > fixing. > --- > CHANGELOG.md | 3 + > docs/misc/xen-command-line.pandoc | 6 - > tools/flask/policy/modules/dom0.te | 2 - > xen/arch/x86/Makefile | 1 - > xen/arch/x86/cpu/vpmu_amd.c | 7 - > xen/arch/x86/cpu/vpmu_intel.c | 6 - > xen/arch/x86/hvm/svm/entry.S | 1 - > xen/arch/x86/hvm/svm/svm.c | 2 - > xen/arch/x86/hvm/vmx/vmx.c | 9 - > xen/arch/x86/include/asm/xenoprof.h | 95 --- > xen/arch/x86/oprofile/Makefile | 6 - > xen/arch/x86/oprofile/backtrace.c | 145 ---- > xen/arch/x86/oprofile/nmi_int.c | 485 ------------ > xen/arch/x86/oprofile/op_counter.h | 41 - > xen/arch/x86/oprofile/op_model_athlon.c | 547 ------------- > xen/arch/x86/oprofile/op_model_p4.c | 721 ----------------- > xen/arch/x86/oprofile/op_model_ppro.c | 348 --------- > xen/arch/x86/oprofile/op_x86_model.h | 58 -- > xen/arch/x86/oprofile/xenoprof.c | 106 --- > xen/arch/x86/traps.c | 4 - > xen/common/Kconfig | 11 - > xen/common/Makefile | 1 - > xen/common/compat/xenoprof.c | 42 - > xen/common/domain.c | 6 - > xen/common/xenoprof.c | 977 ------------------------ > xen/include/Makefile | 1 - > xen/include/hypercall-defs.c | 6 - > xen/include/public/xen.h | 2 +- > xen/include/public/xenoprof.h | 2 +- > xen/include/xen/sched.h | 3 - > xen/include/xen/xenoprof.h | 49 -- > xen/include/xsm/dummy.h | 7 - > xen/include/xsm/xsm.h | 7 - > xen/xsm/dummy.c | 2 - > xen/xsm/flask/hooks.c | 35 - > xen/xsm/flask/policy/access_vectors | 4 - > 36 files changed, 5 insertions(+), 3743 deletions(-) > delete mode 100644 xen/arch/x86/include/asm/xenoprof.h > delete mode 100644 xen/arch/x86/oprofile/Makefile > delete mode 100644 xen/arch/x86/oprofile/backtrace.c > delete mode 100644 xen/arch/x86/oprofile/nmi_int.c > delete mode 100644 xen/arch/x86/oprofile/op_counter.h > delete mode 100644 xen/arch/x86/oprofile/op_model_athlon.c > delete mode 100644 xen/arch/x86/oprofile/op_model_p4.c > delete mode 100644 xen/arch/x86/oprofile/op_model_ppro.c > delete mode 100644 xen/arch/x86/oprofile/op_x86_model.h > delete mode 100644 xen/arch/x86/oprofile/xenoprof.c > delete mode 100644 xen/common/compat/xenoprof.c > delete mode 100644 xen/common/xenoprof.c > delete mode 100644 xen/include/xen/xenoprof.h > > diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h > index e801dbcdbaef..b8fd7aeedd9e 100644 > --- a/xen/include/xsm/dummy.h > +++ b/xen/include/xsm/dummy.h > @@ -278,13 +278,6 @@ static XSM_INLINE int cf_check xsm_console_io( > return xsm_default_action(XSM_PRIV, d, NULL); > } > > -static XSM_INLINE int cf_check xsm_profile( > - XSM_DEFAULT_ARG struct domain *d, int op) > -{ > - XSM_ASSERT_ACTION(XSM_HOOK); > - return xsm_default_action(action, d, NULL); > -} > - > static XSM_INLINE int cf_check xsm_kexec(XSM_DEFAULT_VOID) > { > XSM_ASSERT_ACTION(XSM_PRIV); > diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h > index 2d831d774541..cc32a6c09104 100644 > --- a/xen/include/xsm/xsm.h > +++ b/xen/include/xsm/xsm.h > @@ -101,8 +101,6 @@ struct xsm_ops { > > int (*console_io)(struct domain *d, int cmd); > > - int (*profile)(struct domain *d, int op); > - > int (*kexec)(void); > int (*schedop_shutdown)(struct domain *d1, struct domain *d2); > > @@ -450,11 +448,6 @@ static inline int xsm_console_io(xsm_default_t def, struct domain *d, int cmd) > return alternative_call(xsm_ops.console_io, d, cmd); > } > > -static inline int xsm_profile(xsm_default_t def, struct domain *d, int op) > -{ > - return alternative_call(xsm_ops.profile, d, op); > -} > - > static inline int xsm_kexec(xsm_default_t def) > { > return alternative_call(xsm_ops.kexec); > diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c > index 96dc82ac2e29..244ef557528b 100644 > --- a/xen/xsm/dummy.c > +++ b/xen/xsm/dummy.c > @@ -61,8 +61,6 @@ static const struct xsm_ops __initconst_cf_clobber dummy_ops = { > > .console_io = xsm_console_io, > > - .profile = xsm_profile, > - > .kexec = xsm_kexec, > .schedop_shutdown = xsm_schedop_shutdown, > > diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c > index 9f3915617cc8..b250b2706535 100644 > --- a/xen/xsm/flask/hooks.c > +++ b/xen/xsm/flask/hooks.c > @@ -19,7 +19,6 @@ > #include > #include > #include > -#include > #include > #ifdef CONFIG_HAS_PCI_MSI > #include > @@ -512,38 +511,6 @@ static int cf_check flask_console_io(struct domain *d, int cmd) > return domain_has_xen(d, perm); > } > > -static int cf_check flask_profile(struct domain *d, int op) > -{ > - uint32_t perm; > - > - switch ( op ) > - { > - case XENOPROF_init: > - case XENOPROF_enable_virq: > - case XENOPROF_disable_virq: > - case XENOPROF_get_buffer: > - perm = XEN__NONPRIVPROFILE; > - break; > - case XENOPROF_reset_active_list: > - case XENOPROF_reset_passive_list: > - case XENOPROF_set_active: > - case XENOPROF_set_passive: > - case XENOPROF_reserve_counters: > - case XENOPROF_counter: > - case XENOPROF_setup_events: > - case XENOPROF_start: > - case XENOPROF_stop: > - case XENOPROF_release_counters: > - case XENOPROF_shutdown: > - perm = XEN__PRIVPROFILE; > - break; > - default: > - return avc_unknown_permission("xenoprof op", op); > - } > - > - return domain_has_xen(d, perm); > -} > - > static int cf_check flask_kexec(void) > { > return domain_has_xen(current->domain, XEN__KEXEC); > @@ -1930,8 +1897,6 @@ static const struct xsm_ops __initconst_cf_clobber flask_ops = { > > .console_io = flask_console_io, > > - .profile = flask_profile, > - > .kexec = flask_kexec, > .schedop_shutdown = flask_schedop_shutdown, > > diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors > index 51a1577a66c7..ce907d50a45e 100644 > --- a/xen/xsm/flask/policy/access_vectors > +++ b/xen/xsm/flask/policy/access_vectors > @@ -38,10 +38,6 @@ class xen > readapic > # PHYSDEVOP_apic_write > writeapic > -# Most XENOPROF_* > - privprofile > -# XENOPROF_{init,enable_virq,disable_virq,get_buffer} > - nonprivprofile > # kexec hypercall > kexec > # XENPF_firmware_info, XENPF_efi_runtime_call > > base-commit: c36ddba28e314e9350f4024972023b52e34ec73e Acked-By: Daniel P. Smith From xen-devel-bounces@lists.xenproject.org Fri Jan 09 18:28:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 18:28:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1199112.1515816 (Exim 4.92) (envelope-from ) id 1veHDs-0003G1-58; Fri, 09 Jan 2026 18:28:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1199112.1515816; Fri, 09 Jan 2026 18:28:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veHDs-0003Fu-1M; Fri, 09 Jan 2026 18:28:32 +0000 Received: by outflank-mailman (input) for mailman id 1199112; Fri, 09 Jan 2026 18: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 1veHDp-0003Fi-WE for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 18:28:30 +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 fd73ae4e-ed88-11f0-9ccf-f158ae23cfc8; Fri, 09 Jan 2026 19:28:27 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-4308d87782dso386846f8f.2 for ; Fri, 09 Jan 2026 10:28:27 -0800 (PST) Received: from lab.home (dynamic-2a00-1028-83a4-4bca-c0bb-96ff-feed-9d50.ipv6.o2.cz. [2a00:1028:83a4:4bca:c0bb:96ff:feed:9d50]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0e16f4sm24411728f8f.11.2026.01.09.10.28.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Jan 2026 10:28:25 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fd73ae4e-ed88-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767983306; x=1768588106; 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=qCiBUHR9GUmV1iDaApd4GQnbRtt5KA9W3cMN2DSAagc=; b=YTG+PIcM2cBhYEZuJATxOPxrR1xUYZQjv4Q2FIuVuabXIQ8qCo1cm6Ob7JTT3SRNgM 6NieO7x98epP9FViAJ7WhpFvuoHfzGqNk1/lzuF1Z0bjkX2LlRjtBoeW6ZlAIRV5MYQw dsVCz/lBkX2nooXeBf4aAIPv+En02FL91BWhy6ciX9KQaIvdHpYQ9ArDTEhiUbHwUgzW jy8dbSefF3KArk/gOyjbgqhWJSzMC439k3ldr2qohZBf+rRyxbA/GnMftFVce7WZZP70 RT62N6IzKz+9Xn/GsmJme7ag+GooCDBIRHw+lqR3Gyg6QARBQsrlnTNFcwJuK7EJc1ON G1Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767983306; x=1768588106; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=qCiBUHR9GUmV1iDaApd4GQnbRtt5KA9W3cMN2DSAagc=; b=KcVcvOIqPP02PnAj7miYB83agpaeEtt9zK9UTbS41wG++EN8Jjt6Wh3nkKEq6z46Ve w3/fdcA2CNInHmbY3+Khi4O4VwEPuO2ImZvUMFU6dJEV+kc0W8IELk2x16IxwpsVutPP uefjDtKsQmP1SPjog9zIJIz9zbn+gZKSsNJSjRVNVBCx4y73EZky8Hu/HJFgdbubo5Cj 6BebD470/u7AbVvH26+FZnT0BvH2tks3k+cpDTMcJDMakDPAiNSeX2DjXlBo7VUtE9my VwpfIlX220CzihXuf7WG9mwveHdfCd0TUR2oIIQIDe2LImSuKOy7hVcBb5zsxlYucQL1 0Ejw== X-Gm-Message-State: AOJu0YzmjBqrGtnk/lwRgfF2qZxhQTYFUg78qhquTld1+m8Ym0RdLPB8 ooB/wHUFCfPPthNnK0RLiQThJPMTKi18YQZda21bEAffn2mJJ2NlzulrK5AHaQ== X-Gm-Gg: AY/fxX748T6Sa6IiWIqESlENGdlNbjbzobd1jfT6zbJHnF8baiOjk1Zg6XSlAkFkS27 WDe3dDtD6+Axi9gNptH28gU9uJRNEStG85n39OhOVJX0xniEk7QcpFLiF0npkqrGmByCG6Qa2Td +p19/bOhgJwGHPxtaQ4CpaFurpm3dXLdV0WBiCKZ4gJE+D2yuhJa503L25s5835P2BxrxYilalg kEal2huxc2DmEuROKlTfpi22J7i2rJjV/+L/TTdvRdYD8ja9ThHazxs7A0Y8YsDRtZhhMQQDz3n qrPW8CWx4iqQ1Jaf2c0vEuNN+d9Mi0lhN8bg6g5SCCdSJb+7fwkY0dGTXzOxmxiLRrrM68at9TT AkanPXZl4wcxQhtcgxyh7uPaXvYiv/O57T2F39ac9pEls+vObE9//mS+xrKFc6Hj3Y3KWRm8YRm 4/UXyaiwAGHy3I3Xp2ZgBVSCm2tcVrKBRrFz08elOOG/ulPuHr577TsWKnzy8gMYh14Jh1c0imF u1+2QSbP3Ixd7s= X-Google-Smtp-Source: AGHT+IHjAjG9+x8tuHWmGR6vgWBaQIRYyWhXNF6DWbFscEYVN6wqkZllXh0KlYAv/GA/YZSiKbZagQ== X-Received: by 2002:a05:6000:180f:b0:432:c37c:ec04 with SMTP id ffacd0b85a97d-432c37cec1bmr6149656f8f.0.1767983306096; Fri, 09 Jan 2026 10:28:26 -0800 (PST) From: "=?UTF-8?q?Petr=20Bene=C5=A1?=" X-Google-Original-From: =?UTF-8?q?Petr=20Bene=C5=A1?= To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Petr=20Bene=C5=A1?= , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH] x86/altp2m: altp2m_get_effective_entry() should honor ap2m->default_access Date: Fri, 9 Jan 2026 18:28:22 +0000 Message-Id: X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Petr Beneš Commit 7e5b662 fixed p2m_altp2m_get_or_propagate() to use the altp2m's default_access when propagating entries from the host p2m. However, the same fix was not applied to altp2m_get_effective_entry(), which has the same issue. When altp2m_get_effective_entry() prepopulates a superpage from the host p2m, it incorrectly uses the host p2m's access permissions instead of the altp2m's default_access. This causes problems when the superpage is later split (e.g., when setting mem_access on a specific 4K page): all 512 entries inherit the host p2m's access rights instead of the altp2m's default_access. This issue became apparent after commit 50baf2d, which causes the host p2m to use superpages more frequently. Before that commit, the host p2m typically had 4K entries after VM restore, so the prepopulate branch was rarely taken. Symptoms include memory-access events firing for unexpected pages when using VMI tools with altp2m, particularly after VM resume. The issue can be worked around by booting with "hap_1gb=0 hap_2mb=0". Fixes: 7e5b662 ("x86/altp2m: p2m_altp2m_get_or_propagate() should honor ap2m->default_access") Signed-off-by: Petr Beneš --- xen/arch/x86/mm/altp2m.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xen/arch/x86/mm/altp2m.c b/xen/arch/x86/mm/altp2m.c index 0261360aae..0bc9b9ad2f 100644 --- a/xen/arch/x86/mm/altp2m.c +++ b/xen/arch/x86/mm/altp2m.c @@ -194,6 +194,9 @@ int altp2m_get_effective_entry(struct p2m_domain *ap2m, gfn_t gfn, mfn_t *mfn, gfn_t gfn_aligned = _gfn(gfn_x(gfn) & mask); mfn_t mfn_aligned = _mfn(mfn_x(*mfn) & mask); + /* Override the altp2m entry with its default access. */ + *a = ap2m->default_access; + rc = ap2m->set_entry(ap2m, gfn_aligned, mfn_aligned, page_order, *t, *a, 1); if ( rc ) return rc; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Jan 09 22:35:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 22:35:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1199236.1515836 (Exim 4.92) (envelope-from ) id 1veL4u-0006J4-6s; Fri, 09 Jan 2026 22:35:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1199236.1515836; Fri, 09 Jan 2026 22:35:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veL4u-0006Ix-3z; Fri, 09 Jan 2026 22:35:32 +0000 Received: by outflank-mailman (input) for mailman id 1199236; Fri, 09 Jan 2026 22:35: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 1veL4t-0006Ir-B4 for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 22:35:31 +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 7de3d039-edab-11f0-9ccf-f158ae23cfc8; Fri, 09 Jan 2026 23:35:27 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id E14A141967; Fri, 9 Jan 2026 22:35:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7B306C4CEF1; Fri, 9 Jan 2026 22:35: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: 7de3d039-edab-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767998124; bh=X/vRzRZWLUwYDzodjQulZ5IvQIgKleYTtC7NTW/JlRI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=MJu6is3r4C5LMyPSFI5SGk/sm6qiWQhimlBU6w7i7B3qEmFSzYChRUffSRftuYv1N TK8gQj4HR7TJlSSest9oCpbfEASTuRNfVAJW4K1dMMVOPjs4YASMAGo56bjG349j8N Lld8VZtQZCpWsZZOPJ8E+g3w6nFlmIo9jObTrv/BYARDa7I7Q2krxBy4riBbluxFzv VRRO3vhugUbeoPuHumM7qfOrriZg9LPf9M65j+evv7qreTIFTzDV+gk0RT1oja2Gva tf9DtLGnWNgc8G7BWYeSp2jWRcw/kRIp/OZnF0QA5BFzT2B+CVcfatOiZPhahx24yb whQcZSFPMoFiQ== Date: Fri, 9 Jan 2026 14:35:17 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Grygorii Strashko 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 , Jason Andryuk , Victor Lira Subject: Re: [XEN][PATCH] console/consoleio: account for xen serial input focus during write In-Reply-To: <20251204233211.980862-1-grygorii_strashko@epam.com> Message-ID: References: <20251204233211.980862-1-grygorii_strashko@epam.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Thu, 4 Dec 2025, Grygorii Strashko wrote: > From: Grygorii Strashko > > When 2 or more domains are created and: > - one is hwdom with "hvc0" (console_io) console > - other DomUs with vpl011 or "hvc0" (console_io) console > console output from hwdom may mix with output from other domains. > > Example: > [ 2.288816] Key type id_legacy registered > [ 2.291894] n(XEN) DOM1: [ 1.016950] DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations > fs4filelayout_init: NFSv4 File Layout Driver Registering... > (XEN) DOM1: [ 1.018846] audit: initializing netlink subsys (disabled) > > This happens because for hwdom the console output is produced by domain and > handled by Xen as stream of chars, which can be interrupted when hwdom is > scheduled out and so, cause console output mix. > The Xen consoleio code trying to mimic serial HW behavior for hwdom > unconditionally by sending available data to serial HW on arrival. > Xen consoleio code does not account for Xen console input focus, comparing > to emulated serial hw, like vpl011, which does the same for domain with > active Xen console input focus only. > > Switching console input focus to Xen improves situation, but not enough. > > This patch changes consoleio code to account for domain with active Xen > console input focus - console output will be sent directly to serial HW > only if domain has active Xen console input focus. For other domains - > console output will be buffered and sync on per-line basis. > > Example output: > (d2) [ 4.263417] Key type id_legacy registered > (XEN) DOM1: [ 4.658080] Advanced Linux Sound Architecture Driver Initialized. > (d2) [ 4.277824] nfs4filelayout_init: NFSv4 File Layout Driver Registering... > > Signed-off-by: Grygorii Strashko I independently wrote this patch which also supports console reads. Sorry about the mixed messages. --- xen/console: handle multiple domains using console_io hypercalls Allow multiple dom0less domains to use the console_io hypercalls to print to the console. Handle them in a similar way to vpl011: only the domain which has focus can read from the console. All domains can write to the console but the ones without focus have a prefix. In this case the prefix is applied by using guest_printk instead of printk or console_puts which is what the original code was already doing. Signed-off-by: Stefano Stabellini --- xen/drivers/char/console.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index dcc31170f2..826bee3848 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -729,6 +729,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, unsigned int flags = opt_console_to_ring ? CONSOLE_ALL : CONSOLE_DEFAULT; struct domain *cd = current->domain; + struct domain *input; while ( count > 0 ) { @@ -741,17 +742,26 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, if ( copy_from_guest(kbuf, buffer, kcount) ) return -EFAULT; - if ( is_hardware_domain(cd) ) + input = console_get_domain(); + if (input && cd == input) { + if ( cd->pbuf_idx ) + { + cd->pbuf[cd->pbuf_idx] = '\0'; + console_send(cd->pbuf, cd->pbuf_idx + 1, flags); + cd->pbuf_idx = 0; + } /* Use direct console output as it could be interactive */ nrspin_lock_irq(&console_lock); console_send(kbuf, kcount, flags); nrspin_unlock_irq(&console_lock); + console_put_domain(input); } else { char *kin = kbuf, *kout = kbuf, c; + console_put_domain(input); /* Strip non-printable characters */ do { @@ -793,6 +803,7 @@ long do_console_io( { long rc; unsigned int idx, len; + struct domain *d; rc = xsm_console_io(XSM_OTHER, current->domain, cmd); if ( rc ) @@ -813,6 +824,13 @@ long do_console_io( if ( count > INT_MAX ) break; + d = console_get_domain(); + if ( d != current->domain ) + { + console_put_domain(d); + return 0; + } + rc = 0; while ( (serial_rx_cons != serial_rx_prod) && (rc < count) ) { @@ -824,12 +842,14 @@ long do_console_io( len = count - rc; if ( copy_to_guest_offset(buffer, rc, &serial_rx_ring[idx], len) ) { + console_put_domain(d); rc = -EFAULT; break; } rc += len; serial_rx_cons += len; } + console_put_domain(d); break; default: rc = -ENOSYS; -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Fri Jan 09 23:18:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 09 Jan 2026 23:18:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1199259.1515847 (Exim 4.92) (envelope-from ) id 1veLkb-0002xE-BX; Fri, 09 Jan 2026 23:18:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1199259.1515847; Fri, 09 Jan 2026 23:18:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veLkb-0002x7-82; Fri, 09 Jan 2026 23:18:37 +0000 Received: by outflank-mailman (input) for mailman id 1199259; Fri, 09 Jan 2026 23:18:35 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veLkZ-0002wy-L8 for xen-devel@lists.xenproject.org; Fri, 09 Jan 2026 23:18:35 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 83811437-edb1-11f0-b15e-2bf370ae4941; Sat, 10 Jan 2026 00:18:34 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 12EFE60052; Fri, 9 Jan 2026 23:18:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 34351C4CEF1; Fri, 9 Jan 2026 23:18: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: 83811437-edb1-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768000710; bh=/pIlUHnomRLXkxg7uCnGEwQ46UlBpSTXqN7vfY7hMfQ=; h=Date:From:To:cc:Subject:From; b=kwuVzJ2MJ3QgBem3kgciEE+Jpg2jREU1Ggbb47D24d0PsA23XPAUxOiuEDuSd28Pf k+RBePVhHjn+q+xZrR1yfOArDwEgoOT6uVl3yzKdzVxD/MCmg7aRkfWhX7SikZQ8C2 KY0/9bzu4HFHoT2skCU0Bq7lLTiPmhVMwXXVUfLn97r2CwSthSBd1lhU2iyI0WAtB0 X6IxvQT0RTRiBbd0eL6zN/Lb+tt+oVTTSBYuMpHuYDiECudf2B3HdmT0DD2XiN+KMn 4hTBhnE4RXJOS3cVuRJHhfe4JaG75Xx6kmJi0p4I7GhI3xrf/EPymciLlVUAO72jF9 7/0LSj+LBGArw== Date: Fri, 9 Jan 2026 15:18:29 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: jgross@suse.com cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, xen-devel@lists.xenproject.org Subject: [PATCH] xen: introduce xen_console_io option Message-ID: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Xen can support console_io hypercalls for any domains, not just dom0, depending on DEBUG and XSM policies. These hypercalls can be very useful for development and debugging. Introduce a kernel command line option xen_console_io to enable the usage of console_io hypercalls for any domain upon request. When xen_console_io is not specified, the current behavior is retained. Signed-off-by: Stefano Stabellini --- .../admin-guide/kernel-parameters.txt | 5 +++ drivers/tty/hvc/hvc_xen.c | 33 ++++++++++++++++--- 2 files changed, 34 insertions(+), 4 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index e88505e945d52..953d3f597f007 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -7620,6 +7620,11 @@ save/restore/migration must be enabled to handle larger domains. + xen_console_io [XEN,EARLY] + Boolean option to enable/disable the usage of the Xen + console_io hypercalls to read and write to the console. + Mostly useful for debugging and development. + xen_emul_unplug= [HW,X86,XEN,EARLY] Unplug Xen emulated devices Format: [unplug0,][unplug1] diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c index 388a71afd6efe..299b08c90bab1 100644 --- a/drivers/tty/hvc/hvc_xen.c +++ b/drivers/tty/hvc/hvc_xen.c @@ -51,6 +51,28 @@ static DEFINE_SPINLOCK(xencons_lock); /* ------------------------------------------------------------------ */ +static bool xen_console_io = false; +static int __initdata opt_console_io = -1; + +static int __init parse_xen_console_io(char *arg) +{ + if (!arg) + return -EINVAL; + + if (strcmp(arg, "off") == 0 || + strcmp(arg, "disabled") == 0 || + strcmp(arg, "0") == 0) { + opt_console_io = 0; + } + else if (strcmp(arg, "on") == 0 || + strcmp(arg, "enabled") == 0 || + strcmp(arg, "1") == 0) { + opt_console_io = 1; + } + return 0; +} +early_param("xen_console_io", parse_xen_console_io); + static struct xencons_info *vtermno_to_xencons(int vtermno) { struct xencons_info *entry, *ret = NULL; @@ -331,7 +353,7 @@ static int xen_initial_domain_console_init(void) struct xencons_info *info; unsigned long flags; - if (!xen_initial_domain()) + if (!xen_console_io) return -ENODEV; info = vtermno_to_xencons(HVC_COOKIE); @@ -369,7 +391,7 @@ void xen_console_resume(void) { struct xencons_info *info = vtermno_to_xencons(HVC_COOKIE); if (info != NULL && info->irq) { - if (!xen_initial_domain()) + if (!xen_console_io) xen_console_update_evtchn(info); rebind_evtchn_irq(info->evtchn, info->irq); } @@ -601,7 +623,7 @@ static int __init xen_hvc_init(void) if (!xen_domain()) return -ENODEV; - if (xen_initial_domain()) { + if (xen_console_io) { ops = &dom0_hvc_ops; r = xen_initial_domain_console_init(); if (r < 0) @@ -651,10 +673,13 @@ static int xen_cons_init(void) { const struct hv_ops *ops; + xen_console_io = opt_console_io >= 0 ? opt_console_io : + xen_initial_domain(); + if (!xen_domain()) return 0; - if (xen_initial_domain()) + if (xen_console_io) ops = &dom0_hvc_ops; else { int r; -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Sat Jan 10 00:33:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Jan 2026 00:33:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1199282.1515861 (Exim 4.92) (envelope-from ) id 1veMuo-0004O3-DK; Sat, 10 Jan 2026 00:33:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1199282.1515861; Sat, 10 Jan 2026 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 1veMuo-0004Nw-9N; Sat, 10 Jan 2026 00:33:14 +0000 Received: by outflank-mailman (input) for mailman id 1199282; Sat, 10 Jan 2026 00:33:12 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veMum-0004Nq-M1 for xen-devel@lists.xenproject.org; Sat, 10 Jan 2026 00:33:12 +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 ef296f89-edbb-11f0-9ccf-f158ae23cfc8; Sat, 10 Jan 2026 01:33:09 +0100 (CET) Received: from CY8P222CA0010.NAMP222.PROD.OUTLOOK.COM (2603:10b6:930:6b::24) by CH2PR12MB4038.namprd12.prod.outlook.com (2603:10b6:610:7b::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Sat, 10 Jan 2026 00:33:03 +0000 Received: from CY4PEPF0000E9CF.namprd03.prod.outlook.com (2603:10b6:930:6b:cafe::db) by CY8P222CA0010.outlook.office365.com (2603:10b6:930:6b::24) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.5 via Frontend Transport; Sat, 10 Jan 2026 00:32:59 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by CY4PEPF0000E9CF.mail.protection.outlook.com (10.167.241.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Sat, 10 Jan 2026 00:33:03 +0000 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.2562.17; Fri, 9 Jan 2026 18:33:02 -0600 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; Fri, 9 Jan 2026 18:33:02 -0600 Received: from [172.27.23.102] (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, 9 Jan 2026 16:33:01 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ef296f89-edbb-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HHVfCkK3JHhDVJ0vvogfReXujRlOkJv+kiG04vTPW04G0/2CiQPruvWPoH/bVp4piHfr+0z7J4icopt4udT/m+XgALTfUUlC22c2ygHU2C/cIHKtZsHaTeFNvwyqACcdlJd5ZVcagOBjltMXoGc1+7n9KeALiqQFLIpBo3M0YmdgMtnRrNhBqD+vMhXag+85ykL7x+fjn63TB6ay5g7pvoGJJ3VOR9zMmEauwWwa28Fneop1yNNYO13ZUK6wRbZVnadRgEg6NXj/bidyv5KcNI6fKBU4O/Y/fhO+Quym+3VUVZU4nmGDWRyJNQpZyS99kJclc5h7vaBrAeOrWSezHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WTPdD+wsNFbIreyF1eJxYrPMA7/rnYYOGUgwVpftcbs=; b=u6cHYBXqOSV0mEBGVa8lthAzvVE18jE491UdHcNcOOHjEEV+0BuXDZNUFKuu3fJOKDngKy/aGO1u2LQGlluP59ZZXlbqw11WKU7dos8mQqJqS0PexJNpBDRfDTLcSsU6nHuviwlZPnOeLU8Z197Y+Ap2E3ELvvLGg05pQm46VPALIWDKAx2n7Ht8mH8izOImzgAuN/H3wvhOSj5QpAkTjmWB69aUfZ/7GeAEHryyFUF+6eD4M29AamubwjzrSbZAOfpkd3ykbEA48KJwGBWvY4K1HgdFHWRRFv4gHCd2u0H1ahQm3up+aGgmhxZswW8OI42bECYtJYGuv2VrGl5d4g== 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=WTPdD+wsNFbIreyF1eJxYrPMA7/rnYYOGUgwVpftcbs=; b=eyMEAUbagfq8PNehuLsTq45r/MrkURiEVa69yaQFii1ItCrURWSl2SYUvcWdM3mORPti9w9Y1t8PTBW+CRHPbKORMB3gHwVA4u8AhXzohc5IohzbY1EpM7F2XZs7AdSGgdKajiS94IFECarKpruHG3wiLEcF4BibOWJa5ObP4UM= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <1beace12-8364-4808-b817-7705f0dd9d79@amd.com> Date: Fri, 9 Jan 2026 18:32:37 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: KEEP Re: [PATCH 2/2] xen: Add CONFIG_GC_SECTIONS To: Jan Beulich CC: Victor Lira , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Grygorii Strashko , , Andrew Cooper References: <20251209214728.278949-1-jason.andryuk@amd.com> <20251209214728.278949-3-jason.andryuk@amd.com> <43d30e02-f818-4cf2-98c9-4182a2f65f64@amd.com> <13a270cd-b0bd-4565-9158-0e1728aef84e@citrix.com> <7514a67c-d140-43b6-bed0-3467530a086d@suse.com> <83eedd0c-dcaf-4e28-ac0f-f4991f053350@suse.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <83eedd0c-dcaf-4e28-ac0f-f4991f053350@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: CY4PEPF0000E9CF:EE_|CH2PR12MB4038:EE_ X-MS-Office365-Filtering-Correlation-Id: 4cc2c19c-cb31-4014-69be-08de4fdfd0e1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|376014|82310400026|1800799024|13003099007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?dXJraDFzcGJTdE1PS2ZSOThySlltYXEySzlQTFd6bk9Yc3RGM3h5YUhTTisy?= =?utf-8?B?YTIwRHhlTDBoSHV2b3E2MTJ1Y0QxRDJSMFRjaG5qb1hwUk1GMk95b1FOOFVq?= =?utf-8?B?N3NvaHZHWG9sUm9vU05qSXdtcjlBZkxFVXBFYmswZ29FdE5WNkh1dW5rSHdL?= =?utf-8?B?NjZMOWpmQ0xPMnN3bVlpNnJNOUJ1UlhNY0dHM0hBK29lVEFmSVVhcEM5amFt?= =?utf-8?B?VFBEejlqTjMzOTNMM0J1R0UwS2NsSmIwQWNsSW5YSVl4MGcwZFJFK1ZMbFJ5?= =?utf-8?B?UjBMeVpMRlN3M0VlUTVyZkNIakNzKzVRaTViZHlpYkNCM3JlZEJQRUhDcmFm?= =?utf-8?B?SVRua3dPSDR6dWlJczFrc054dmFpVVlsc1I5bmg0c0ZBYXVmaVNYVmd1S1hG?= =?utf-8?B?YmlPRTNSQzJkK0dvRHZVRnE5MHVHTG9NN1NCcXdvcTFvOGtPYytmb2VzeldT?= =?utf-8?B?K0tmNDNzZCtwOUpmemdZeHU1Mit0NTdYaUxFVURLcDZYcFZiVU5HNklzVWcw?= =?utf-8?B?T21xK2wwcnRCV3RFb0FCZUhQRWNPTC91QjlNL2l2M0J0UnNac2c3M2E0M3NP?= =?utf-8?B?SjczU3lJeFZYRUZUYU5kL0IrdC9SY1FJOGhnM3pWeVBENDB1SGk4aSt2RlRF?= =?utf-8?B?Q0k2b2VJa0lnNytFVVRYTjAycyswOHBoZjVBZFlnaGxQdW9QZ0pEUEdObXI4?= =?utf-8?B?cnF4cWlCb3dBeFpUOGxnNlhtTjZYaHl2ek54eWVQR0FRK1VvWGZEdzlPWDZI?= =?utf-8?B?ZnFlbG9VbSt3aDRBVzZMSlhSWUtHZ3dxTTJYOEFtd3JuMlhGZy9IOGw5NVZQ?= =?utf-8?B?SlMyakxSa3M5aWs0UnQ2SWtYWkp0M2tlenU1eUV4UkpNQmZwTndnamc5NzYx?= =?utf-8?B?MTJyaVNoNDZVc01jQU5RT05jWlFneG9KYmJSOGxMVExoUjMvTmtxQ3BuejJI?= =?utf-8?B?L295SWZTbGZMTTRqM3NtMjBhZ1ZXck8rOEtDbGlpb3F4OHlycWRMUUt0d2FK?= =?utf-8?B?NWtzNDNBbnhkQjlDM1BPbE9oYVhYcm40OFVNY0ZjMEFyWktvTXRSMlZYUjg1?= =?utf-8?B?VEYrSkFseVU3dVdKOWVZN3lNQ0lrTjBaWlVFS2pCemRFbUIyL292S1ZkbFVQ?= =?utf-8?B?eVp3OThGSWNqN05sV3hMMlhuZDQxVGlabFZGRloxWm1GOUszU0NVWThwMDBi?= =?utf-8?B?UDA1VmowanYwbFVUakpKZHpuSVNENTRxOVRidmlCR1NybEY1cTgrMDZKZEJo?= =?utf-8?B?ZGltMEJEaEtvaDBUZU9zaWVHTkNBY2VMZ2xRN3YzT1l1SjgxUEFEZExGbnVv?= =?utf-8?B?NmQ0UldvOTE2b3oxRklWVDdxTDZVbkd4eEZEdEEwaGNZd3BzS2pTUVVueUJt?= =?utf-8?B?WkxpZGdadXFuUm4wN1NSeXBSL1gwMWgraDgrUFVUVFVKV0VSVEpQT2FCcGZ1?= =?utf-8?B?NDJQV3BWTlRHaDVFNHNZMzRuQUthUGJLajlza2xTZmtSTlJjZTVaUWRZdWlQ?= =?utf-8?B?TW84bTFMV2hDb2tFNTlLWnhOQmxYb1FPbFlMODQreTA4b05TbWI1bTVuUUJj?= =?utf-8?B?UEQwYVdoL3gwNmxXVWg3YVUrcHNyaDluaEV3a1hhdVhOaTlEeDVoaDU5ZDBo?= =?utf-8?B?SjZ3NVlmVlowenlwTGpicFBOWUVyUHdrYW9pelBsOGFFdytnM3BXMkZ0Ymxw?= =?utf-8?B?NHRVRTJWNVhmRmlBTlNvWlRUTkJzT2plS21hV3NLYllIdGVaemRTWDJwMEJL?= =?utf-8?B?QUZKYVR0azVhZ2FCTjNCRDlpSTdSMkV0QVpsSUVBcnNvandLcXRjSVQ2RC9P?= =?utf-8?B?MGR3a2d1Vi80R2NyQ2tRMTNLUS9Zb0FHZXM5K2owVUoyeXNEVVRyaUJXWWRm?= =?utf-8?B?bUNiaFdJMzE0Wk1qQUNuVzRXOEs5cFNsUFZBUUdPT05VOGlBOHZVY3pqT2Nj?= =?utf-8?B?WlJmbmRKVzNYaHc2RU53dGdJd0ZTbnJWWmpiYk9IcDdOMEhiWDhhK1FhUFlw?= =?utf-8?B?aEI0elBNbno0TUpRRHJlU2N0Yjh0amk0SzA0bEJvWmp2R2hzR3REdDd2dmc5?= =?utf-8?B?UHFEYW5PSThhUFRuNHhzQ3lIMTlxWlJ4SFdLQmNsVXVMZFdHN0NDVEF3a2Y5?= =?utf-8?Q?ar/I=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(1800799024)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jan 2026 00:33:03.2986 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4cc2c19c-cb31-4014-69be-08de4fdfd0e1 X-MS-Exchange-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: CY4PEPF0000E9CF.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4038 (trimmed the CC list down) On 2025-12-12 08:22, Jan Beulich wrote: > On 12.12.2025 02:34, Jason Andryuk wrote: >> The alternative is section groups? I'm trying that, and it kinda works >> sometimes, but .attach_to_group fails when .init.text is involved. >> >> Here's an example that I think would work, I could make it to >> --gc-sectrions: >> group section [ 3] `.group' [.text.vpmu_do_msr] contains 5 sections: >> [Index] Name >> [ 43] .text.vpmu_do_msr >> [ 44] .rela.text.vpmu_do_msr >> [ 45] .altinstructions..text.vpmu_do_msr >> [ 46] .rela.altinstructions..text.vpmu_do_msr >> [ 47] .altinstr_replacement..text.vpmu_do_msr >> >> But I don't make it that far. Other files blow up with tons of: >> {standard input}:9098: Warning: dwarf line number information for >> .init.text ignored >> and >> {standard input}:50083: Error: leb128 operand is an undefined symbol: >> .LVU4040 >> >> Line 9098 of apic.s is .loc below: >> """ >> .section .init.text Earlier in the file, there is .section .init.text,"ax",@progbits but the later .section .init.text entries don't have the extra string. tl;dr: If I add "ax",@progbits to all the .init.text entries, the file assembles. I opened a bug here: https://sourceware.org/bugzilla/show_bug.cgi?id=33779 Regards, Jason From xen-devel-bounces@lists.xenproject.org Sat Jan 10 04:00:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 10 Jan 2026 04:00:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1199325.1515870 (Exim 4.92) (envelope-from ) id 1veQ9Q-0002Ea-W1; Sat, 10 Jan 2026 04:00:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1199325.1515870; Sat, 10 Jan 2026 04:00:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veQ9Q-0002ET-T8; Sat, 10 Jan 2026 04:00:32 +0000 Received: by outflank-mailman (input) for mailman id 1199325; Sat, 10 Jan 2026 04:00:31 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1veQ9O-0002ED-Ve for xen-devel@lists.xenproject.org; Sat, 10 Jan 2026 04:00:31 +0000 Received: from out28-77.mail.aliyun.com (out28-77.mail.aliyun.com [115.124.28.77]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e39f1a0b-edd8-11f0-9ccf-f158ae23cfc8; Sat, 10 Jan 2026 05:00:26 +0100 (CET) Received: from localhost(mailfrom:houwenlong.hwl@antgroup.com fp:SMTPD_---.g2udv12_1768017621 cluster:ay29) by smtp.aliyun-inc.com; Sat, 10 Jan 2026 12:00:21 +0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e39f1a0b-edd8-11f0-9ccf-f158ae23cfc8 DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=antgroup.com; s=default; t=1768017623; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=A6dPHnR7FvaayZTlFNBJHodwAg7ZKvD60GtSZKVizUI=; b=kr0oejG0VHA98SVlNkPKz0CRuH2liazdL+MHNYTI2m4bKCXgyalJlsILGigcPXmIgmlOJ1Dc/n838lcuHVggu5PcpxTvN1ZvEKs+CghsCam3xNV578Ksg0j7Ig1OvCa+uGIxFB+9we7TUCGO8Ki6RGqN56At+yAXXzerzCnVN5s= From: Hou Wenlong To: linux-kernel@vger.kernel.org Cc: Hou Wenlong , Juergen Gross , Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , xen-devel@lists.xenproject.org Subject: [PATCH RESEND v2] x86/xen/pvh: Enable PAE mode for 32-bit guest only when CONFIG_X86_PAE is set Date: Sat, 10 Jan 2026 12:00:08 +0800 Message-Id: X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The PVH entry is available for 32-bit KVM guests, and 32-bit KVM guests do not depend on CONFIG_X86_PAE. However, mk_early_pgtbl_32() builds different pagetables depending on whether CONFIG_X86_PAE is set. Therefore, enabling PAE mode for 32-bit KVM guests without CONFIG_X86_PAE being set would result in a boot failure during CR3 loading. Signed-off-by: Hou Wenlong Reviewed-by: Juergen Gross --- I resend this because I encountered the 32-bit KVM guest PVH booting failure again. I hope this can be fixed. original v2: https://lore.kernel.org/all/0469c27833be58aa66471920aa77922489d86c63.1713873613.git.houwenlong.hwl@antgroup.com --- arch/x86/platform/pvh/head.S | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/platform/pvh/head.S b/arch/x86/platform/pvh/head.S index 344030c1a81d..53ee2d53fcf8 100644 --- a/arch/x86/platform/pvh/head.S +++ b/arch/x86/platform/pvh/head.S @@ -91,10 +91,12 @@ SYM_CODE_START(pvh_start_xen) leal rva(early_stack_end)(%ebp), %esp +#if defined(CONFIG_X86_64) || defined(CONFIG_X86_PAE) /* Enable PAE mode. */ mov %cr4, %eax orl $X86_CR4_PAE, %eax mov %eax, %cr4 +#endif #ifdef CONFIG_X86_64 /* Enable Long mode. */ base-commit: b7dccac786071bba98b0d834c517fd44a22c50f9 prerequisite-patch-id: 590fa7e96c6bb8e0b9d15017cfa5ce1eb314957a -- 2.31.1 From xen-devel-bounces@lists.xenproject.org Sun Jan 11 04:12:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 11 Jan 2026 04:12:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1199669.1515901 (Exim 4.92) (envelope-from ) id 1vemo6-0004pg-1h; Sun, 11 Jan 2026 04:12:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1199669.1515901; Sun, 11 Jan 2026 04: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 1vemo5-0004ny-RZ; Sun, 11 Jan 2026 04:12:01 +0000 Received: by outflank-mailman (input) for mailman id 1199669; Sun, 11 Jan 2026 04:12:01 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vemo5-0004eg-53 for xen-devel@lists.xenproject.org; Sun, 11 Jan 2026 04:12:01 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vemo4-001xp8-1k; Sun, 11 Jan 2026 04: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 1vemo4-000Y6C-1v; Sun, 11 Jan 2026 04: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=I1QkihUJOTF7JtgRUB5yX7oCjGpry5xRBIdICxe+gYk=; b=MxyA8O4DxFbU3PEJIfevcftBz+ Rzphjx6t27+g4MdrzScdGOpFv+c3gLxD9h/a2cZUjSFv+qvYVfLkd0+1LqtkJO0DGhOI0AVVjFYFV NAI2/NpQk2PfSOuT104fQRvc5YqiSmChOylympOMKQoQGCUippF+bDSQwudQqkCqiAdI=; 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 3/4] tests: use unit test fragment in PDX test Date: Sat, 10 Jan 2026 20:11:44 -0800 Message-ID: <20260111041145.553673-4-dmukhin@ford.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260111041145.553673-1-dmukhin@ford.com> References: <20260111041145.553673-1-dmukhin@ford.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Denis Mukhin Use the new make fragment to generate test harness code for the PDX unit test. Move earlier in xen/common/pdx.c to ensure harness.h is included before triggering the #ifndef MAX_PFN_RANGES check when building a unit test. Additionally, use real in harness.h instead of a locally copied version. Update .gitignore to exclude generated test build-time dependencies. Not a functional change. Signed-off-by: Denis Mukhin --- Changes since v1: - new patch --- tools/tests/pdx/.gitignore | 2 +- tools/tests/pdx/Makefile | 55 +++++++++----------------------------- tools/tests/pdx/harness.h | 2 +- tools/tests/pdx/test-pdx.c | 2 -- xen/common/pdx.c | 3 ++- 5 files changed, 16 insertions(+), 48 deletions(-) diff --git a/tools/tests/pdx/.gitignore b/tools/tests/pdx/.gitignore index 1202a531a7fd..1bf9c05985c4 100644 --- a/tools/tests/pdx/.gitignore +++ b/tools/tests/pdx/.gitignore @@ -1,3 +1,3 @@ -/pdx.h +/generated /test-pdx-mask /test-pdx-offset diff --git a/tools/tests/pdx/Makefile b/tools/tests/pdx/Makefile index 3c431d7c7822..178b451cb611 100644 --- a/tools/tests/pdx/Makefile +++ b/tools/tests/pdx/Makefile @@ -1,50 +1,19 @@ -XEN_ROOT=$(CURDIR)/../../.. -include $(XEN_ROOT)/tools/Rules.mk +# SPDX-License-Identifier: GPL-2.0-only +# +# Unit tests for PDX (Page inDeX). +# -TARGETS := test-pdx-mask test-pdx-offset +TESTS := test-pdx-mask test-pdx-offset -.PHONY: all -all: $(TARGETS) +XEN_ROOT = $(CURDIR)/../../.. -.PHONY: run -run: $(TARGETS) -ifeq ($(CC),$(HOSTCC)) - set -e; \ - for test in $? ; do \ - ./$$test ; \ - done -else - $(warning HOSTCC != CC, will not run test) -endif +CFLAGS += -DCONFIG_PDX_MASK_COMPRESSION -.PHONY: clean -clean: - $(RM) -- *.o $(TARGETS) $(DEPS_RM) pdx.h +include $(XEN_ROOT)/tools/tests/Rules.mk -.PHONY: distclean -distclean: clean - $(RM) -- *~ +CFLAGS += -I $(XEN_ROOT)/xen/include/ -.PHONY: install -install: all - $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)/tests - $(INSTALL_PROG) $(TARGETS) $(DESTDIR)$(LIBEXEC)/tests +$(eval $(call vpath-with-harness-deps,pdx.c,$(XEN_ROOT)/xen/common/)) -.PHONY: uninstall -uninstall: - $(RM) -- $(patsubst %,$(DESTDIR)$(LIBEXEC)/tests/%,$(TARGETS)) - -pdx.h: $(XEN_ROOT)/xen/include/xen/pdx.h - sed -e '/^#[[:space:]]*include/d' <$< >$@ - -CFLAGS += -D__XEN_TOOLS__ -CFLAGS += $(APPEND_CFLAGS) -CFLAGS += $(CFLAGS_xeninclude) - -test-pdx-mask: CFLAGS += -DCONFIG_PDX_MASK_COMPRESSION -test-pdx-offset: CFLAGS += -DCONFIG_PDX_OFFSET_COMPRESSION - -test-pdx-%: test-pdx.c pdx.h - $(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -o $@ $< $(APPEND_CFLAGS) - --include $(DEPS_INCLUDE) +test-pdx-%: test-pdx.o pdx.o + $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ diff --git a/tools/tests/pdx/harness.h b/tools/tests/pdx/harness.h index e49d6bcf92c2..4cdda931feb2 100644 --- a/tools/tests/pdx/harness.h +++ b/tools/tests/pdx/harness.h @@ -84,7 +84,7 @@ typedef uint64_t paddr_t; qsort(elem, nr, size, cmp); \ }) -#include "pdx.h" +#include #endif diff --git a/tools/tests/pdx/test-pdx.c b/tools/tests/pdx/test-pdx.c index eefd54c76815..3633c231abaa 100644 --- a/tools/tests/pdx/test-pdx.c +++ b/tools/tests/pdx/test-pdx.c @@ -7,8 +7,6 @@ #include "harness.h" -#include "../../xen/common/pdx.c" - struct range { /* Ranges are defined as [start, end). */ unsigned long start, end; diff --git a/xen/common/pdx.c b/xen/common/pdx.c index 7e070ff962e8..068a2098b41b 100644 --- a/xen/common/pdx.c +++ b/xen/common/pdx.c @@ -15,11 +15,12 @@ * along with this program; If not, see . */ +#include + /* Trim content when built for the test harness. */ #ifdef __XEN__ #include #include -#include #include #include #include -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Sun Jan 11 04:12:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 11 Jan 2026 04:12:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1199667.1515890 (Exim 4.92) (envelope-from ) id 1vemo5-0004gc-Ew; Sun, 11 Jan 2026 04:12:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1199667.1515890; Sun, 11 Jan 2026 04: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 1vemo5-0004gS-Ba; Sun, 11 Jan 2026 04:12:01 +0000 Received: by outflank-mailman (input) for mailman id 1199667; Sun, 11 Jan 2026 04:12:00 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vemo4-0004US-7N for xen-devel@lists.xenproject.org; Sun, 11 Jan 2026 04:12:00 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vemo3-001xp0-1P; Sun, 11 Jan 2026 04: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 1vemo3-000Y66-1a; Sun, 11 Jan 2026 04: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=Z0BRzvSQDE7UJZD2daLQhudqHPC6UC9KqBQjEA1pAzs=; b=mgyg3C6YsbCXZFaBrHz+riy+N+ HfIJurtobX+6Bmy5GAepH2bL2pzL1w43IVmaRJjdhkZd5qykQt2+JKl++bgtD8ZoGC+1S/prDcxfV zNLa+VTOJEGIRwNCDR+u2EYptnEb1m7ivYyyD/rRCrEtVRpDm2Ye21+SK6MRx0/AmA/0=; 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 2/4] tests: introduce common fragment for unit tests Date: Sat, 10 Jan 2026 20:11:43 -0800 Message-ID: <20260111041145.553673-3-dmukhin@ford.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260111041145.553673-1-dmukhin@ford.com> References: <20260111041145.553673-1-dmukhin@ford.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Denis Mukhin Move test harness generation into a new shared make fragment so that it can be reused by other unit tests. Signed-off-by: Denis Mukhin --- Changes from v1: - moved fragment to tools/tests/ --- tools/tests/Rules.mk | 91 ++++++++++++++++++++++++++++++++++++++ tools/tests/domid/Makefile | 85 +---------------------------------- 2 files changed, 92 insertions(+), 84 deletions(-) create mode 100644 tools/tests/Rules.mk diff --git a/tools/tests/Rules.mk b/tools/tests/Rules.mk new file mode 100644 index 000000000000..daa9e69301e4 --- /dev/null +++ b/tools/tests/Rules.mk @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: GPL-2.0-only +# +# Common unit test fragment. +# +# Copyright 2025 Ford Motor Company + +include $(XEN_ROOT)/tools/Rules.mk + +define list-c-headers +$(shell sed -n \ + 's/^[ \t]*# *include[ \t]*[<"]\([^">]*\)[">].*/\1/p' $(1) 2>/dev/null) +endef + +# Generate mock environment by replicating header file hierarchy; +# each header file will point to a harness header. +# +# $1 target +# $2 list of test harnesses +define emit-harness-nested-rule +$(1): $(2) + set -e; \ + mkdir -p $$(@D); \ + for i in $(2); do [ -e $$@ ] || ln -s $$$$i $$@; done + +endef + +# Helper function to emit mocked hypervisor code dependencies. +# +# $1 Harness file name. +# $2 Mocked hypervisor file name. +# $3 List of dependencies to mock. +define emit-harness-rules +$(foreach x,$(3),$(call emit-harness-nested-rule,\ + $(CURDIR)/generated/$(x),\ + $(addprefix $(CURDIR)/,$(1)))) +$(2:.c=.o): $(addprefix $(CURDIR)/generated/,$(3)) +endef + +define emit-harness-deps +$(if $(strip $(3)),$(call emit-harness-rules,$1,$2,$3),) +endef + +# Emit dependencies for mocked hypervisor code. +# +# $1 Hypervisor file name. +# $2 Hypervisor source path. +# $3 Harness header file name (optional). +define vpath-with-harness-deps +vpath $(1) $(2) +$(call emit-harness-deps,$(or $(strip $(3)),harness.h),\ + $(1),\ + $(call list-c-headers,$(2)$(1))) +endef + +.PHONY: all +all: $(TESTS) + +.PHONY: run +run: $(TESTS) +ifeq ($(CC),$(HOSTCC)) + set -e; $(foreach t,$(TESTS),./$(t);) +else + $(warning HOSTCC != CC, will not run test) +endif + +.PHONY: clean +clean: + $(RM) -r generated + $(RM) -- *.o $(TESTS) $(DEPS_RM) + +.PHONY: distclean +distclean: clean + $(RM) -- *~ + +.PHONY: install +install: all + $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)/tests + set -e; $(foreach t,$(TESTS),$(INSTALL_PROG) $t $(DESTDIR)$(LIBEXEC)/tests;) + +.PHONY: uninstall +uninstall: + set -e; $(foreach t,$(TESTS),$(RM) -- $(DESTDIR)$(LIBEXEC)/tests/$t;) + +CFLAGS += -D__XEN_TOOLS__ +# Honor mocked hypervisor header over tools/include/xen symlinks +CFLAGS += -I$(CURDIR)/generated/ +CFLAGS += $(CFLAGS_xeninclude) + +ifeq ($(filter clean distclean,$(MAKECMDGOALS)),) +-include $(DEPS_INCLUDE) +endif diff --git a/tools/tests/domid/Makefile b/tools/tests/domid/Makefile index dd22a25b038a..2f8cc5380462 100644 --- a/tools/tests/domid/Makefile +++ b/tools/tests/domid/Makefile @@ -7,84 +7,7 @@ TESTS := test-domid XEN_ROOT = $(CURDIR)/../../.. -include $(XEN_ROOT)/tools/Rules.mk - -define list-c-headers -$(shell sed -n \ - 's/^[ \t]*# *include[ \t]*[<"]\([^">]*\)[">].*/\1/p' $(1) 2>/dev/null) -endef - -# Generate mock environment by replicating header file hierarchy; -# each header file will point to a harness header. -# -# $1 target -# $2 list of test harnesses -define emit-harness-nested-rule -$(1): $(2) - set -e; \ - mkdir -p $$(@D); \ - for i in $(2); do [ -e $$@ ] || ln -s $$$$i $$@; done - -endef - -# Helper function to emit mocked hypervisor code dependencies. -# -# $1 Harness file name. -# $2 Mocked hypervisor file name. -# $3 List of dependencies to mock. -define emit-harness-rules -$(foreach x,$(3),$(call emit-harness-nested-rule,\ - $(CURDIR)/generated/$(x),\ - $(addprefix $(CURDIR)/,$(1)))) -$(2:.c=.o): $(addprefix $(CURDIR)/generated/,$(3)) -endef - -define emit-harness-deps -$(if $(strip $(3)),$(call emit-harness-rules,$1,$2,$3),) -endef - -# Emit dependencies for mocked hypervisor code. -# -# $1 Hypervisor file name. -# $2 Hypervisor source path. -# $3 Harness header file name (optional). -define vpath-with-harness-deps -vpath $(1) $(2) -$(call emit-harness-deps,$(or $(strip $(3)),harness.h),\ - $(1),\ - $(call list-c-headers,$(2)$(1))) -endef - -.PHONY: all -all: $(TESTS) - -.PHONY: run -run: $(TESTS) -ifeq ($(CC),$(HOSTCC)) - set -e; $(foreach t,$(TESTS),./$(t);) -else - $(warning HOSTCC != CC, will not run test) -endif - -.PHONY: clean -clean: - $(RM) -r generated - $(RM) -- *.o $(TESTS) $(DEPS_RM) - -.PHONY: distclean -distclean: clean - $(RM) -- *~ - -.PHONY: install -install: all - $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)/tests - set -e; $(foreach t,$(TESTS),$(INSTALL_PROG) $t $(DESTDIR)$(LIBEXEC)/tests;) - -.PHONY: uninstall -uninstall: - set -e; $(foreach t,$(TESTS),$(RM) -- $(DESTDIR)$(LIBEXEC)/tests/$t;) - -CFLAGS += -D__XEN_TOOLS__ +include $(XEN_ROOT)/tools/tests/Rules.mk # find-next-bit.c CFLAGS-find-next-bit.c += '-DEXPORT_SYMBOL(x)=' \ @@ -96,10 +19,6 @@ CFLAGS-find-next-bit.c += '-DEXPORT_SYMBOL(x)=' \ find-next-bit.o: CFLAGS += $(CFLAGS-find-next-bit.c) -# Honor mocked hypervisor header over tools/include/xen symlinks -CFLAGS += -I$(CURDIR)/generated/ -CFLAGS += $(CFLAGS_xeninclude) - vpath find-next-bit.c $(XEN_ROOT)/xen/lib/ # Point to the hypervisor code and generate test harness dependencies @@ -109,5 +28,3 @@ $(eval $(call vpath-with-harness-deps,domid.c,$(XEN_ROOT)/xen/common/)) test-domid: domid.o find-next-bit.o test-domid.o $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ - --include $(DEPS_INCLUDE) -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Sun Jan 11 04:12:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 11 Jan 2026 04:12:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1199668.1515895 (Exim 4.92) (envelope-from ) id 1vemo5-0004kw-NO; Sun, 11 Jan 2026 04:12:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1199668.1515895; Sun, 11 Jan 2026 04: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 1vemo5-0004jX-JR; Sun, 11 Jan 2026 04:12:01 +0000 Received: by outflank-mailman (input) for mailman id 1199668; Sun, 11 Jan 2026 04:12:00 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vemo4-0004c9-U8 for xen-devel@lists.xenproject.org; Sun, 11 Jan 2026 04:12:00 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vemo2-001xog-19; Sun, 11 Jan 2026 04: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 1vemo2-000Y62-1F; Sun, 11 Jan 2026 04: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=/m1LF2NtAIDgbIpy2Al8n60LY4uT2dvKj7zYoQhSDbo=; b=CUAl6W3UatzdFdEXzrnO6uITi1 5AaHssv4pclOCF7xrV739auHVlzo7QXZP3AkfWJe3PQGhlAo3Zwf6WwumunB3OH8Xwi9QyUR3t/ik nxBAHU9gzsS34J+fbJigMuALA9Mf9MgLuYxPyCXCXoIG7xq60dr7IlVhCSf+WJYXmZXQ=; 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 1/4] tests: fixup domid make fragment Date: Sat, 10 Jan 2026 20:11:42 -0800 Message-ID: <20260111041145.553673-2-dmukhin@ford.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260111041145.553673-1-dmukhin@ford.com> References: <20260111041145.553673-1-dmukhin@ford.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Denis Mukhin There can be multiple test harnesses per one test target (e.g. harness.h and harness2.h). Account for that by further parametrizing existing emit-harness-nested-rule(). Add guard against HOSTCC != CC (similarly to how its done in PDX unit test). Account for multiple test targets in install and uninstall make targets. Introduce CFLAGS dedicated for find-next-bit.c only to avoid contaminating global CFLAGS. Honor mocked hypervisor header over tools/include/xen symlinks. Finally, add some clarifications for the functions. Amends: 2d5065060710 ("xen/domain: unify domain ID allocation") Signed-off-by: Denis Mukhin --- Changes since v1: - updated commentaries - added ability to select the harness header filename - fixup for picking up mocked header files --- tools/tests/domid/Makefile | 63 ++++++++++++++++++++++++++------------ 1 file changed, 44 insertions(+), 19 deletions(-) diff --git a/tools/tests/domid/Makefile b/tools/tests/domid/Makefile index 753129029ed9..dd22a25b038a 100644 --- a/tools/tests/domid/Makefile +++ b/tools/tests/domid/Makefile @@ -4,36 +4,55 @@ # # Copyright 2025 Ford Motor Company -XEN_ROOT=$(CURDIR)/../../.. -include $(XEN_ROOT)/tools/Rules.mk - TESTS := test-domid +XEN_ROOT = $(CURDIR)/../../.. +include $(XEN_ROOT)/tools/Rules.mk + define list-c-headers $(shell sed -n \ 's/^[ \t]*# *include[ \t]*[<"]\([^">]*\)[">].*/\1/p' $(1) 2>/dev/null) endef -# NB: $1 cannot be a list +# Generate mock environment by replicating header file hierarchy; +# each header file will point to a harness header. +# +# $1 target +# $2 list of test harnesses define emit-harness-nested-rule -$(1): $(CURDIR)/harness.h - mkdir -p $$(@D); - ln -sf $$< $$@; +$(1): $(2) + set -e; \ + mkdir -p $$(@D); \ + for i in $(2); do [ -e $$@ ] || ln -s $$$$i $$@; done endef +# Helper function to emit mocked hypervisor code dependencies. +# +# $1 Harness file name. +# $2 Mocked hypervisor file name. +# $3 List of dependencies to mock. define emit-harness-rules -$(foreach x,$(2),$(call emit-harness-nested-rule,$(CURDIR)/generated/$(x))) -$(1:.c=.o): $(addprefix $(CURDIR)/generated/,$(2)) +$(foreach x,$(3),$(call emit-harness-nested-rule,\ + $(CURDIR)/generated/$(x),\ + $(addprefix $(CURDIR)/,$(1)))) +$(2:.c=.o): $(addprefix $(CURDIR)/generated/,$(3)) endef define emit-harness-deps -$(if $(strip $(2)),$(call emit-harness-rules,$1,$2),) +$(if $(strip $(3)),$(call emit-harness-rules,$1,$2,$3),) endef +# Emit dependencies for mocked hypervisor code. +# +# $1 Hypervisor file name. +# $2 Hypervisor source path. +# $3 Harness header file name (optional). define vpath-with-harness-deps vpath $(1) $(2) -$(call emit-harness-deps,$(1),$(call list-c-headers,$(2)$(1))) +$(call emit-harness-deps,$(or $(strip $(3)),harness.h),\ + $(1),\ + $(call list-c-headers,$(2)$(1))) endef .PHONY: all @@ -41,7 +60,11 @@ all: $(TESTS) .PHONY: run run: $(TESTS) +ifeq ($(CC),$(HOSTCC)) set -e; $(foreach t,$(TESTS),./$(t);) +else + $(warning HOSTCC != CC, will not run test) +endif .PHONY: clean clean: @@ -55,25 +78,27 @@ distclean: clean .PHONY: install install: all $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)/tests - $(INSTALL_PROG) test-domid $(DESTDIR)$(LIBEXEC)/tests + set -e; $(foreach t,$(TESTS),$(INSTALL_PROG) $t $(DESTDIR)$(LIBEXEC)/tests;) .PHONY: uninstall uninstall: - $(RM) -- $(DESTDIR)$(LIBEXEC)/tests/test-domid + set -e; $(foreach t,$(TESTS),$(RM) -- $(DESTDIR)$(LIBEXEC)/tests/$t;) CFLAGS += -D__XEN_TOOLS__ + # find-next-bit.c -CFLAGS += '-DEXPORT_SYMBOL(x)=' \ +CFLAGS-find-next-bit.c += '-DEXPORT_SYMBOL(x)=' \ -Dfind_first_bit \ -Dfind_first_zero_bit \ -Dfind_next_bit \ -Dfind_next_bit_le \ -Dfind_next_zero_bit_le -CFLAGS += $(APPEND_CFLAGS) -CFLAGS += $(CFLAGS_xeninclude) -CFLAGS += -I./generated/ -LDFLAGS += $(APPEND_LDFLAGS) +find-next-bit.o: CFLAGS += $(CFLAGS-find-next-bit.c) + +# Honor mocked hypervisor header over tools/include/xen symlinks +CFLAGS += -I$(CURDIR)/generated/ +CFLAGS += $(CFLAGS_xeninclude) vpath find-next-bit.c $(XEN_ROOT)/xen/lib/ @@ -83,6 +108,6 @@ vpath find-next-bit.c $(XEN_ROOT)/xen/lib/ $(eval $(call vpath-with-harness-deps,domid.c,$(XEN_ROOT)/xen/common/)) test-domid: domid.o find-next-bit.o test-domid.o - $(CC) $^ -o $@ $(LDFLAGS) + $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ -include $(DEPS_INCLUDE) -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Sun Jan 11 04:12:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 11 Jan 2026 04:12:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1199670.1515921 (Exim 4.92) (envelope-from ) id 1vemo8-0005NY-84; Sun, 11 Jan 2026 04:12:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1199670.1515921; Sun, 11 Jan 2026 04: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 1vemo8-0005NR-4z; Sun, 11 Jan 2026 04:12:04 +0000 Received: by outflank-mailman (input) for mailman id 1199670; Sun, 11 Jan 2026 04:12:02 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vemo6-00056N-G8 for xen-devel@lists.xenproject.org; Sun, 11 Jan 2026 04:12:02 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vemo5-001xpY-21; Sun, 11 Jan 2026 04: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 1vemo5-000Y6K-2F; Sun, 11 Jan 2026 04: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=foxDb3geIou8JW8wuomGx2/i1qOo8eC7hBk0Ml/97QE=; b=U7mKRMHeM/Nu8OcpI71xY6D1sK hjbmlC8XouXkW3q6JlNMFecLWP/1Shj1wCzHf8W96hWwTr/UfrST5S8ZnlBpPvoX1YlZWsboOjPvL Oo7nhKw8JxSZ3zRpEvwY1Rwko1nmaJ0VecAjWog1NXw2PHlSU0u0Vwz/XD9vJemkrKKk=; 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 4/4] tests: use unit test fragment in vPCI test Date: Sat, 10 Jan 2026 20:11:45 -0800 Message-ID: <20260111041145.553673-5-dmukhin@ford.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260111041145.553673-1-dmukhin@ford.com> References: <20260111041145.553673-1-dmukhin@ford.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Denis Mukhin Use the new make fragment to generate test harness code for the vPCI unit test. Add new prepare-harness target to tests/Rules.mk as an optional step for setting up mocked environment for building a test. Fix hypervisor headers used to compile vpci.c against host environment where necessary. Fixup emul.h by adding missing mocks to account for new unit test infra. Update .gitignore to exclude generated test build-time dependencies. Not a functional change. Signed-off-by: Denis Mukhin --- Changes since v1: - new patch --- tools/tests/Rules.mk | 5 +++- tools/tests/vpci/.gitignore | 2 ++ tools/tests/vpci/Makefile | 52 ++++++++++++------------------------- tools/tests/vpci/emul.h | 50 +++++++++++++---------------------- tools/tests/vpci/main.c | 2 -- xen/include/xen/irq.h | 2 ++ xen/include/xen/list.h | 2 ++ xen/include/xen/numa.h | 2 ++ xen/include/xen/pci.h | 2 ++ xen/include/xen/pfn.h | 2 ++ xen/include/xen/spinlock.h | 2 ++ xen/include/xen/types.h | 4 +++ 12 files changed, 56 insertions(+), 71 deletions(-) create mode 100644 tools/tests/vpci/.gitignore diff --git a/tools/tests/Rules.mk b/tools/tests/Rules.mk index daa9e69301e4..26f3d00b5fb9 100644 --- a/tools/tests/Rules.mk +++ b/tools/tests/Rules.mk @@ -11,13 +11,16 @@ $(shell sed -n \ 's/^[ \t]*# *include[ \t]*[<"]\([^">]*\)[">].*/\1/p' $(1) 2>/dev/null) endef +.PHONY: prepare-harness +prepare-harness: + # Generate mock environment by replicating header file hierarchy; # each header file will point to a harness header. # # $1 target # $2 list of test harnesses define emit-harness-nested-rule -$(1): $(2) +$(1): prepare-harness $(2) set -e; \ mkdir -p $$(@D); \ for i in $(2); do [ -e $$@ ] || ln -s $$$$i $$@; done diff --git a/tools/tests/vpci/.gitignore b/tools/tests/vpci/.gitignore new file mode 100644 index 000000000000..d66c2cd56be6 --- /dev/null +++ b/tools/tests/vpci/.gitignore @@ -0,0 +1,2 @@ +/generated +test-vpci diff --git a/tools/tests/vpci/Makefile b/tools/tests/vpci/Makefile index 97359ff67f86..695a275675f8 100644 --- a/tools/tests/vpci/Makefile +++ b/tools/tests/vpci/Makefile @@ -1,43 +1,23 @@ -XEN_ROOT=$(CURDIR)/../../.. -include $(XEN_ROOT)/tools/Rules.mk +# SPDX-License-Identifier: GPL-2.0-only +# +# Unit tests for vPCI. +# -TARGET := test_vpci +TESTS := test-vpci -.PHONY: all -all: $(TARGET) +XEN_ROOT = $(CURDIR)/../../.. +CFLAGS += -DCONFIG_HAS_VPCI -.PHONY: run -run: $(TARGET) -ifeq ($(CC),$(HOSTCC)) - ./$(TARGET) -else - $(warning HOSTCC != CC, will not run test) -endif +include $(XEN_ROOT)/tools/tests/Rules.mk -$(TARGET): vpci.c vpci.h list.h main.c emul.h - $(CC) $(CFLAGS_xeninclude) -g -o $@ vpci.c main.c +# Do not mock xen/vpci.h header for the test +prepare-harness: + set -e; mkdir -p $(CURDIR)/generated/xen; \ + ln -sf $(XEN_ROOT)/xen/include/xen/vpci.h $(CURDIR)/generated/xen -.PHONY: clean -clean: - rm -rf $(TARGET) *.o *~ vpci.h vpci.c list.h +CFLAGS += -I $(XEN_ROOT)/xen/include/ -.PHONY: distclean -distclean: clean +$(eval $(call vpath-with-harness-deps,vpci.c,$(XEN_ROOT)/xen/drivers/vpci/,emul.h)) -.PHONY: install -install: all - $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)/tests - $(INSTALL_PROG) $(TARGET) $(DESTDIR)$(LIBEXEC)/tests - -.PHONY: uninstall -uninstall: - $(RM) -- $(DESTDIR)$(LIBEXEC)/tests/$(TARGET) - -vpci.c: $(XEN_ROOT)/xen/drivers/vpci/vpci.c - # Remove includes and add the test harness header - sed -e '/#include/d' -e '1s/^/#include "emul.h"/' <$< >$@ - -list.h: $(XEN_ROOT)/xen/include/xen/list.h -vpci.h: $(XEN_ROOT)/xen/include/xen/vpci.h -list.h vpci.h: - sed -e '/#include/d' <$< >$@ +test-vpci: vpci.o main.o + $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ diff --git a/tools/tests/vpci/emul.h b/tools/tests/vpci/emul.h index dd048cffbf9d..979e86e2692e 100644 --- a/tools/tests/vpci/emul.h +++ b/tools/tests/vpci/emul.h @@ -34,8 +34,16 @@ #define ASSERT(x) assert(x) #define __must_check __attribute__((__warn_unused_result__)) #define cf_check +#define always_inline inline -#include "list.h" +typedef int64_t s_time_t; +typedef uint8_t nodeid_t; +typedef uint8_t u8; +typedef uint16_t u16; +typedef uint32_t u32; +typedef uint64_t u64; + +#include typedef bool rwlock_t; @@ -43,10 +51,6 @@ struct domain { rwlock_t pci_lock; }; -struct pci_dev { - struct vpci *vpci; -}; - struct vcpu { struct domain *domain; @@ -57,35 +61,17 @@ extern const struct pci_dev test_pdev; typedef bool spinlock_t; #define spin_lock_init(l) (*(l) = false) -#define spin_lock(l) (*(l) = true) -#define spin_unlock(l) (*(l) = false) -#define read_lock(l) (*(l) = true) -#define read_unlock(l) (*(l) = false) -#define write_lock(l) (*(l) = true) -#define write_unlock(l) (*(l) = false) +#define spin_lock(l) (assert(!*(l)), *(l) = true) +#define spin_unlock(l) (assert(*(l)), *(l) = false) +#define read_lock(l) (assert(!*(l)), *(l) = true) +#define read_unlock(l) (assert(*(l)), *(l) = false) +#define write_lock(l) (assert(!*(l)), *(l) = true) +#define write_unlock(l) (assert(*(l)), *(l) = false) -typedef union { - uint32_t sbdf; - struct { - union { - uint16_t bdf; - struct { - union { - struct { - uint8_t func : 3, - dev : 5; - }; - uint8_t extfunc; - }; - uint8_t bus; - }; - }; - uint16_t seg; - }; -} pci_sbdf_t; +#define lock_evaluate_nospec(l) (l) +#define block_lock_speculation() -#define CONFIG_HAS_VPCI -#include "vpci.h" +#include #define __hwdom_init diff --git a/tools/tests/vpci/main.c b/tools/tests/vpci/main.c index 2ef8d4e03f1d..3753417e866d 100644 --- a/tools/tests/vpci/main.c +++ b/tools/tests/vpci/main.c @@ -189,8 +189,6 @@ main(int argc, char **argv) uint32_t r24 = 0; uint8_t r28, r30; struct mask_data r32; - unsigned int i; - int rc; INIT_LIST_HEAD(&vpci.handlers); spin_lock_init(&vpci.lock); diff --git a/xen/include/xen/irq.h b/xen/include/xen/irq.h index 6071b00f621e..f7fa1d0fa29b 100644 --- a/xen/include/xen/irq.h +++ b/xen/include/xen/irq.h @@ -1,5 +1,6 @@ #ifndef __XEN_IRQ_H__ #define __XEN_IRQ_H__ +#ifdef __XEN__ #include #include @@ -208,4 +209,5 @@ unsigned int arch_hwdom_irqs(const struct domain *d); void arch_evtchn_bind_pirq(struct domain *d, int pirq); #endif +#endif /* __XEN__ */ #endif /* __XEN_IRQ_H__ */ diff --git a/xen/include/xen/list.h b/xen/include/xen/list.h index 98d8482daba1..06d2fa3aed15 100644 --- a/xen/include/xen/list.h +++ b/xen/include/xen/list.h @@ -7,8 +7,10 @@ #ifndef __XEN_LIST_H__ #define __XEN_LIST_H__ +#ifdef __XEN__ #include #include +#endif /* * These are non-NULL pointers that will result in faults under normal diff --git a/xen/include/xen/numa.h b/xen/include/xen/numa.h index f6c1f27ca105..80d60fd49178 100644 --- a/xen/include/xen/numa.h +++ b/xen/include/xen/numa.h @@ -1,5 +1,6 @@ #ifndef _XEN_NUMA_H #define _XEN_NUMA_H +#ifdef __XEN__ #include @@ -152,4 +153,5 @@ static inline nodeid_t mfn_to_nid(mfn_t mfn) #define page_to_nid(pg) mfn_to_nid(page_to_mfn(pg)) +#endif /* __XEN__ */ #endif /* _XEN_NUMA_H */ diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h index 130c2a8c1a65..f5965a68ae33 100644 --- a/xen/include/xen/pci.h +++ b/xen/include/xen/pci.h @@ -14,7 +14,9 @@ #include #include #include +#ifdef __XEN__ #include +#endif /* * The PCI interface treats multi-function devices as independent diff --git a/xen/include/xen/pfn.h b/xen/include/xen/pfn.h index 1ca9b095e0df..98ff669d7def 100644 --- a/xen/include/xen/pfn.h +++ b/xen/include/xen/pfn.h @@ -1,7 +1,9 @@ #ifndef __XEN_PFN_H__ #define __XEN_PFN_H__ +#ifdef __XEN__ #include +#endif #define PFN_DOWN(x) ((x) >> PAGE_SHIFT) #define PFN_UP(x) (((x) + PAGE_SIZE-1) >> PAGE_SHIFT) diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h index ca9d8c7ec0a1..ad5094c4eb92 100644 --- a/xen/include/xen/spinlock.h +++ b/xen/include/xen/spinlock.h @@ -1,5 +1,6 @@ #ifndef __SPINLOCK_H__ #define __SPINLOCK_H__ +#ifdef __XEN__ #include #include @@ -360,4 +361,5 @@ static always_inline void nrspin_lock_irq(rspinlock_t *l) #define nrspin_unlock_irqrestore(l, f) _nrspin_unlock_irqrestore(l, f) #define nrspin_unlock_irq(l) _nrspin_unlock_irq(l) +#endif /* __XEN__ */ #endif /* __SPINLOCK_H__ */ diff --git a/xen/include/xen/types.h b/xen/include/xen/types.h index 73ddccbbd5dc..e5d702b48ac0 100644 --- a/xen/include/xen/types.h +++ b/xen/include/xen/types.h @@ -4,6 +4,7 @@ #include #include +#ifdef __XEN__ /* Linux inherited types which are being phased out */ typedef uint8_t u8; typedef uint16_t u16; @@ -15,6 +16,7 @@ typedef uint64_t u64; typedef __SIZE_TYPE__ size_t; typedef signed long ssize_t; +#endif /* __XEN__ */ typedef __PTRDIFF_TYPE__ ptrdiff_t; typedef __UINTPTR_TYPE__ uintptr_t; @@ -33,6 +35,7 @@ typedef __UINTPTR_TYPE__ uintptr_t; #define NULL ((void*)0) #endif +#ifdef __XEN__ #define INT8_MIN (-127-1) #define INT16_MIN (-32767-1) #define INT32_MIN (-2147483647-1) @@ -52,6 +55,7 @@ typedef __UINTPTR_TYPE__ uintptr_t; #define LONG_MAX ((long)(~0UL>>1)) #define LONG_MIN (-LONG_MAX - 1) #define ULONG_MAX (~0UL) +#endif /* __XEN__ */ typedef uint16_t __le16; typedef uint16_t __be16; -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Sun Jan 11 04:12:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 11 Jan 2026 04:12:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1199666.1515881 (Exim 4.92) (envelope-from ) id 1vemo4-0004Uf-9T; Sun, 11 Jan 2026 04:12:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1199666.1515881; Sun, 11 Jan 2026 04: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 1vemo4-0004UK-4U; Sun, 11 Jan 2026 04:12:00 +0000 Received: by outflank-mailman (input) for mailman id 1199666; Sun, 11 Jan 2026 04:11:58 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vemo2-0004UC-Df for xen-devel@lists.xenproject.org; Sun, 11 Jan 2026 04:11:58 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vemo1-001xoa-0r; Sun, 11 Jan 2026 04: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 1vemo1-000Y5y-0s; Sun, 11 Jan 2026 04: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:Message-ID:Date: Subject:Cc:To:From; bh=e4pIYjP2h/50F/x23N8hbdKtxfDFcaZRQX30wz6A4ws=; b=m5uBMm yMR+7p4g9ED+Aw8vFaOpzuGgRf0cU3QWCwXXpBpqEwnwWq4yWGbvWb+/fbP84a/K5o5qiCBFt4/To fszZfFJa7WyKxRTfrDShTLReHaQ+swZSc3jACP3ZH4yKGorWsP7BHil1D32OLditMZRv0dX3Rsro6 Cm4zV32NqKU=; 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 0/4] tools/tests: test harness fragment Date: Sat, 10 Jan 2026 20:11:41 -0800 Message-ID: <20260111041145.553673-1-dmukhin@ford.com> X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This series introduces the use of a new common unit test fragment across several existing unit tests. Patch 1 contains assorted fixups for the domid Makefile. Patch 2 adds a new fragment for auto-generating test harness dependencies. Patch 3 switches the PDX unit test to the new common fragment. Patch 4 switches the vPCI unit test to the new common fragment. [1] Link to v1: https://lore.kernel.org/xen-devel/20251204123712.721443-1-dmukhin@ford.com/ [2] CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2256052244 Denis Mukhin (4): tests: fixup domid make fragment tests: introduce common fragment for unit tests tests: use unit test fragment in PDX test tests: use unit test fragment in vPCI test tools/tests/Rules.mk | 94 +++++++++++++++++++++++++++++++++++++ tools/tests/domid/Makefile | 68 ++------------------------- tools/tests/pdx/.gitignore | 2 +- tools/tests/pdx/Makefile | 55 +++++----------------- tools/tests/pdx/harness.h | 2 +- tools/tests/pdx/test-pdx.c | 2 - tools/tests/vpci/.gitignore | 2 + tools/tests/vpci/Makefile | 52 +++++++------------- tools/tests/vpci/emul.h | 50 +++++++------------- tools/tests/vpci/main.c | 2 - xen/common/pdx.c | 3 +- xen/include/xen/irq.h | 2 + xen/include/xen/list.h | 2 + xen/include/xen/numa.h | 2 + xen/include/xen/pci.h | 2 + xen/include/xen/pfn.h | 2 + xen/include/xen/spinlock.h | 2 + xen/include/xen/types.h | 4 ++ 18 files changed, 167 insertions(+), 181 deletions(-) create mode 100644 tools/tests/Rules.mk create mode 100644 tools/tests/vpci/.gitignore -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Sun Jan 11 08:44:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 11 Jan 2026 08:44:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1199739.1515931 (Exim 4.92) (envelope-from ) id 1ver3p-00079m-0c; Sun, 11 Jan 2026 08:44:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1199739.1515931; Sun, 11 Jan 2026 08:44: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 1ver3o-00079f-TM; Sun, 11 Jan 2026 08:44:32 +0000 Received: by outflank-mailman (input) for mailman id 1199739; Sun, 11 Jan 2026 08:44: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 1ver3m-00079X-AE for xen-devel@lists.xenproject.org; Sun, 11 Jan 2026 08:44:31 +0000 Received: from mail-24427.protonmail.ch (mail-24427.protonmail.ch [109.224.244.27]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id bcd28f24-eec9-11f0-b15e-2bf370ae4941; Sun, 11 Jan 2026 09:44:27 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bcd28f24-eec9-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1768121066; x=1768380266; bh=sevsMZJLYMUqtxnrgORxu7J5MIpUODntARyXXjPMWlw=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=VTBYt5Gh4H1qJVAU8V3AdsemGp3UCx71qthh+QaR8dJYUCcEmu37sucpe4A1fHsUf abV+CKhnv7Mslzx+ox1ie+EohccuAg2qWzgQIsEyQt5uWkPB/t3oSGDpXj1XhxfnkW HsCqtkJTFAmM8sYpUhqZKCyzjLZIT2D51kikeP+dNlTi1lnC5Zx1oHrHbR8u6npEHW ZHaCjSPBbZNnhn308E9fg3fDZYu2HAmyeg6TJON5ml/EU6Lr3XLhOb/qaJ7b5g+MEL xYjUNeoXNH2INmc3X+jvsgSqzEPHLXnPUejn/gefiPMm5Xk+1hJRSs7/jjQgnMrDWJ wa62kLGRzuJ3g== Date: Sun, 11 Jan 2026 08:44:22 +0000 To: Jan Beulich From: Milky Cc: "xen-devel@lists.xenproject.org" , Jason Andryuk Subject: Re: Cpufreq drivers not working on T480S Message-ID: In-Reply-To: <7dbd26d1-0d9a-454f-90d8-5a7f3d8e12da@suse.com> References: <7dbd26d1-0d9a-454f-90d8-5a7f3d8e12da@suse.com> Feedback-ID: 171106842:user:proton X-Pm-Message-ID: d1e2ba194983e9292fa5991c3edc236d5e3bcb41 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thursday, January 8th, 2026 at 7:46 AM, Jan Beulich = wrote: > > The same is also true under Debian Live; does it mean that frequency sc= aling, since it seems to be working under Debian Live, doesn't always rely = on this? >=20 >=20 > Yes, that's possible afaik. Which driver is in use there? `/sys/devices/system/cpu/cpu0/scaling_driver` shows `intel_pstate`; confirm= ed also using `dmesg`, which shows Intel P-state initialisation and HWP bei= ng enabled. > > Maybe also with Xen's command line try cpufreq=3Dxen:no-hwp to disable > > HWP and see if the regular ACPI cpufreq driver works better Following from Marek's message elsewhwere in the thread, I now tried adding= in grub the correct Xen flag to disable HWP on Qubes: `cpufreq=3Dxen,no-hw= p`. I am pasting below the output of `xl dmesg`. It seems it no longer repo= rts HWP being enabled. However, `xenpm get-cpufreq-para` still says "failed= to get cpufreq parameter", `xenpm get-cpufreq-states` returns nothing. ``` (XEN) Built-in command line: ept=3Dexec-sp spec-ctrl=3Dunpriv-mmio Xen 4.17.5 (XEN) Xen version 4.17.5 (mockbuild@[unknown]) (gcc (GCC) 12.3.1 20230508 (= Red Hat 12.3.1-1)) debug=3Dn Fri Aug 22 16:12:56 CEST 2025 (XEN) Latest ChangeSet:=20 (XEN) build-id: d2dd0684651dcc833d35869ad2259cb6f0ba1d19 (XEN) Bootloader: GRUB 2.13 (XEN) Command line: placeholder cpufreq=3Dxen,no-hwp,verbose loglvl=3Dall d= om0_mem=3Dmin:1024M dom0_mem=3Dmax:4096M ucode=3Dscan smt=3Doff gnttab_max_= frames=3D2048 gnttab_max_maptrack_frames=3D4096 no-real-mode edd=3Doff (XEN) Xen image load base address: 0x79200000 (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) Disc information: (XEN) Found 0 MBR signatures (XEN) Found 0 EDD information structures (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 142 (0x8e), Stepping 10 (raw= 000806ea) (XEN) Multiboot-e820 RAM map: (XEN) [0000000000000000, 0000000000000fff] (reserved) (XEN) [0000000000001000, 000000000009ffff] (usable) (XEN) [00000000000a0000, 00000000000fffff] (reserved) (XEN) [0000000000100000, 000000007aa06fff] (usable) (XEN) [000000007aa07000, 000000007fffffff] (reserved) (XEN) [00000000e0000000, 00000000efffffff] (reserved) (XEN) [00000000fd000000, 00000000fe00ffff] (reserved) (XEN) [00000000fed10000, 00000000fed19fff] (reserved) (XEN) [00000000fed80000, 00000000fed84fff] (reserved) (XEN) [00000000fed90000, 00000000fed91fff] (reserved) (XEN) [0000000100000000, 0000000a7fffffff] (usable) (XEN) ACPI: RSDP 000F6010, 0024 (r2 COREv4) (XEN) ACPI: XSDT 7AA0F0E0, 0064 (r1 COREv4 COREBOOT 0 CORE 20241212) (XEN) ACPI: FACP 7AA13020, 0114 (r6 COREv4 COREBOOT 0 CORE 20241212) (XEN) ACPI: DSDT 7AA0F280, 3D98 (r2 COREv4 COREBOOT 20110725 INTL 20241212) (XEN) ACPI: FACS 7AA0F240, 0040 (XEN) ACPI: SSDT 7AA13140, 08EA (r2 COREv4 COREBOOT 0 CORE 20241212) (XEN) ACPI: MCFG 7AA13A30, 003C (r1 COREv4 COREBOOT 0 CORE 20241212) (XEN) ACPI: LPIT 7AA13A70, 0094 (r0 COREv4 COREBOOT 0 CORE 20241212) (XEN) ACPI: APIC 7AA13B10, 0072 (r3 COREv4 COREBOOT 0 CORE 20241212) (XEN) ACPI: SPCR 7AA13B90, 0058 (r4 COREv4 COREBOOT 0 CORE 20241212) (XEN) ACPI: DMAR 7AA13BF0, 0088 (r1 COREv4 COREBOOT 0 CORE 20241212) (XEN) ACPI: HPET 7AA13C80, 0038 (r1 COREv4 COREBOOT 0 CORE 20241212) (XEN) System RAM: 40873MB (41854616kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-0000000a80000000 (XEN) Domain heap initialised (XEN) SMBIOS 3.0 present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x1808 (24 bits) (XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0] (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:1804,1:0], pm1x_evt[1:1800,1:0] (XEN) ACPI: wakeup_vec[7aa0f24c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-119 (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) (XEN) ACPI: IRQ0 used by override. (XEN) ACPI: IRQ2 used by override. (XEN) ACPI: IRQ9 used by override. (XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000 (XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - ff (XEN) PCI: MCFG area at e0000000 reserved in E820 (XEN) PCI: Using MCFG for segment 0000 bus 00-ff (XEN) Using ACPI (MADT) for SMP configuration information (XEN) SMP: Allowing 4 CPUs (0 hotplug CPUs) (XEN) IRQ limits: 120 GSI, 840 MSI/MSI-X (XEN) Switched to APIC driver x2apic_mixed (XEN) BSP microcode revision: 0x000000f6 (XEN) FIRMWARE BUG: CPU 06-8e-0a, ucode 0x000000f6: RTM_ALWAYS_ABORT vs RTM= mismatch (XEN) CPU0: TSC: ratio: 150 / 2 (XEN) CPU0: bus: 100 MHz base: 1800 MHz max: 3400 MHz (XEN) CPU0: 400 ... 1800 MHz (XEN) xstate: size: 0x440 and states: 0x1f (XEN) CPU0: Intel machine check reporting enabled (XEN) Speculative mitigation facilities: (XEN) Hardware hints: RSBA RFDS_NO (XEN) Hardware features: IBPB IBRS STIBP SSBD L1D_FLUSH MD_CLEAR SRBDS_CT= RL GDS_CTRL (XEN) Compiled-in support: INDIRECT_THUNK RETURN_THUNK HARDEN_ARRAY HARDE= N_BRANCH HARDEN_GUEST_ACCESS HARDEN_LOCK (XEN) Xen settings: BTI-Thunk: JMP, SPEC_CTRL: IBRS+ STIBP+ SSBD-, Other:= SRB_LOCK+ IBPB-ctxt L1D_FLUSH VERW BRANCH_HARDEN (XEN) L1TF: believed vulnerable, maxphysaddr L1D 46, CPUID 39, Safe addre= ss 8000000000 (XEN) Support for HVM VMs: MSR_SPEC_CTRL MSR_VIRT_SPEC_CTRL RSB EAGER_FPU (XEN) Support for PV VMs: MSR_SPEC_CTRL EAGER_FPU VERW (XEN) XPTI (64-bit PV only): Dom0 enabled, DomU enabled (with PCID) (XEN) PV L1TF shadowing: Dom0 disabled, DomU enabled (XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2) (XEN) Initializing Credit2 scheduler (XEN) load_precision_shift: 18 (XEN) load_window_shift: 30 (XEN) underload_balance_tolerance: 0 (XEN) overload_balance_tolerance: -3 (XEN) runqueues arrangement: socket (XEN) cap enforcement granularity: 10ms (XEN) load tracking window length 1073741824 ns (XEN) Disabling HPET for being unreliable (XEN) Platform timer is 3.580MHz ACPI PM Timer (XEN) Detected 1799.991 MHz processor. (XEN) Freed 1024kB unused BSS memory (XEN) alt table ffff82d04042bf70 -> ffff82d04043b3f2 (XEN) cpu0: spurious 8259A interrupt: IRQ7 (XEN) Intel VT-d iommu 0 supported page sizes: 4kB, 2MB, 1GB (XEN) Intel VT-d iommu 1 supported page sizes: 4kB, 2MB, 1GB (XEN) Intel VT-d Snoop Control not enabled. (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) Intel VT-d Queued Invalidation enabled. (XEN) Intel VT-d Interrupt Remapping enabled. (XEN) Intel VT-d Posted Interrupt not enabled. (XEN) Intel VT-d Shared EPT tables enabled. (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) Interrupt remapping enabled (XEN) nr_sockets: 1 (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) Enabling APIC mode. Using 1 I/O APICs (XEN) ENABLING IO-APIC IRQs (XEN) -> Using old ACK method (XEN) ..TIMER: vector=3D0xF0 apic1=3D0 pin1=3D2 apic2=3D0 pin2=3D0 (XEN) TSC deadline timer enabled (XEN) Allocated console ring of 32 KiB. (XEN) HWP: 1 notify: 1 act-window: 1 energy-perf: 1 pkg-level: 0 peci: 0 (XEN) HWP: Hardware Duty Cycling (HDC) supported, enabled (XEN) HWP: HW_FEEDBACK not supported (XEN) mwait-idle: MWAIT substates: 0x11142120 (XEN) mwait-idle: v0.4.1 model 0x8e (XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff (XEN) VMX: Supported advanced features: (XEN) - APIC MMIO access virtualisation (XEN) - APIC TPR shadow (XEN) - Extended Page Tables (EPT) (XEN) - Virtual-Processor Identifiers (VPID) (XEN) - Virtual NMI (XEN) - MSR direct-access bitmap (XEN) - Unrestricted Guest (XEN) - VM Functions (XEN) - Virtualisation Exceptions (XEN) - Page Modification Logging (XEN) HVM: ASIDs enabled. (XEN) HVM: VMX enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB (XEN) alt table ffff82d04042bf70 -> ffff82d04043b3f2 (XEN) Brought up 4 CPUs (XEN) Scheduling granularity: cpu, 1 CPU per sched-resource (XEN) Initializing Credit2 scheduler (XEN) load_precision_shift: 18 (XEN) load_window_shift: 30 (XEN) underload_balance_tolerance: 0 (XEN) overload_balance_tolerance: -3 (XEN) runqueues arrangement: socket (XEN) cap enforcement granularity: 10ms (XEN) load tracking window length 1073741824 ns (XEN) Adding cpu 0 to runqueue 0 (XEN) First cpu on runqueue, activating (XEN) Adding cpu 1 to runqueue 0 (XEN) Adding cpu 2 to runqueue 1 (XEN) First cpu on runqueue, activating (XEN) Adding cpu 3 to runqueue 1 (XEN) mcheck_poll: Machine check polling timer started. (XEN) NX (Execute Disable) protection active (XEN) d0 has maximum 744 PIRQs (XEN) *** Building a PV Dom0 *** (XEN) Xen kernel: 64-bit, lsb (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x200000 -> 0x3c00000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000a58000000->0000000a5c000000 (1022144 pages to = be allocated) (XEN) Init. ramdisk: 0000000a7d8c0000->0000000a7ffff5b7 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff80200000->ffffffff83c00000 (XEN) Phys-Mach map: 0000008000000000->0000008000800000 (XEN) Start info: ffffffff83c00000->ffffffff83c004b8 (XEN) Page tables: ffffffff83c01000->ffffffff83c24000 (XEN) Boot stack: ffffffff83c24000->ffffffff83c25000 (XEN) TOTAL: ffffffff80000000->ffffffff84000000 (XEN) ENTRY ADDRESS: ffffffff82b0de00 (XEN) Dom0 has maximum 4 VCPUs (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Scrubbing Free RAM in background (XEN) Std. Loglevel: All (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) (XEN) Freed 668kB init memory (XEN) PCI add device 0000:00:00.0 (XEN) PCI add device 0000:00:02.0 (XEN) PCI add device 0000:00:04.0 (XEN) PCI add device 0000:00:14.0 (XEN) PCI add device 0000:00:14.2 (XEN) PCI add device 0000:00:1c.0 (XEN) PCI add device 0000:00:1c.6 (XEN) PCI add device 0000:00:1d.0 (XEN) PCI add device 0000:00:1f.0 (XEN) PCI add device 0000:00:1f.2 (XEN) PCI add device 0000:00:1f.3 (XEN) PCI add device 0000:00:1f.6 (XEN) PCI add device 0000:02:00.0 (XEN) PCI add device 0000:03:00.0 (XEN) PCI add device 0000:00:1f.1 (XEN) PCI remove device 0000:00:1f.1 ``` From xen-devel-bounces@lists.xenproject.org Mon Jan 12 08:43:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 08:43:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1199909.1515941 (Exim 4.92) (envelope-from ) id 1vfDW3-000124-2n; Mon, 12 Jan 2026 08:43:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1199909.1515941; Mon, 12 Jan 2026 08: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 1vfDW3-00011x-08; Mon, 12 Jan 2026 08:43:11 +0000 Received: by outflank-mailman (input) for mailman id 1199909; Mon, 12 Jan 2026 08:43:09 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfDW1-00011r-9D for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 08:43:09 +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 b4c87f3d-ef92-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 09:43:02 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-4779aa4f928so62860985e9.1 for ; Mon, 12 Jan 2026 00:43:02 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f68f686sm341713815e9.3.2026.01.12.00.43.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 00:43:01 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b4c87f3d-ef92-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768207382; x=1768812182; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=+oUtbrT3/VK7ixul3bKTwExavRHv8vag5XdwonnMG/E=; b=KjBiC5x7zKX4mCS9FvHPrbM44A3R3aSQx37+58p+m94aPvc2035MKHc/ibSN7RFCK1 ts4gZ+K39NSC+I+GmgtCHN4918ojzDxMrf2OWF03LurR/2MZlGa6uRiVu4GidnV2pzFa ZTeKM44pqnCHe48pyLecVsLxlJvuJik4LpoXEP6BiLkgWlFJT1l8Bxkc0dyGjXfJzdp1 oEA45UfANvA5fGeNu1swrOv+bKq1nTWjkAt/lO8CJrD8wrEvt2PQJSWAT8FOLhIhWlJ3 aTROV2qD1hA1okl/jjbaxvj0X8ECOVeksiLkfbvfigI9+VPEOeoTeX9plbaeRaHFL5h4 RZsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768207382; x=1768812182; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+oUtbrT3/VK7ixul3bKTwExavRHv8vag5XdwonnMG/E=; b=vpbFZDvxuxdI1BUN3K8CLewT9wTVdYqeph/AqoB9rL7sKyyPbOwmpNVR1PLufC+LoI DZbPwlVdoILhXUDKQp57B4rVMhKFKflPeZC4LJ+i1UUY6R9NVzgBKW4TTttTvJKvGaea DkRc7EoGGC2Mb9fpa6J5ACSIJp/Lah/j81oMMsxeKkj3tWHh/0LbNfNTafFTX21Q5fBB 4ufQK1yqeX+VEzkVsXjj/Kh1hh+bxfIBZ5xhk3cWjuXn3G0m4uVGmEdcu9bw/sBDKe8w GMne8Se2n/uw5WRHmLRht7FGx3iOouImqdDjjcSIrdk35Y/1FTguHCTVkPepg4GaWeAl 42uA== X-Gm-Message-State: AOJu0YzwHRMcCFxSIxKe4LKwAXyquWx6pe1QGZZpMNcioXIWGfMd2ezq 4Omu7IrNZprxIyBMNnmq5cEPr30AjCem9WMaiFBXanPfbddEQtMT0OsQTQtDBLyVzA== X-Gm-Gg: AY/fxX5wN04eD52RpOXNwxSSoyHYsKDyk9RbdowyJYrFMUHER8KXFT5FnTV4eMJlobR EJMQgDBdKbUyG8mWILImArfCqApEHZtmlVKY7LHCexjO2SQ4vxVaBa6OHvXcpQLo3iJjX4/kaT9 92+HTG/JqRFWRPI7TdLgCFW5MEODfZ5P3QxBCBSdScO48yaFDJOKrK0cPWPQenKbMqPo2KOid4K NJmTxdzkOGZz6wpOYkYlyDqdHo5Ixx7OgWYPVWI5zWnjAoHpsN2jBTXKu5WJu+Ws5HDlyGVgzXS V93UlndAzqYSO9eC177mwbrNV4So9lIBFUyeoEeCBN1Iwk0Vvbh8DKSQnSteY7pXlZVjwtZnncU veUmRFBhpy2TElfhtTlj2p2bAkfipejzTON0HCShLXVozZEDeTmtALww+AP3Ydt4GQy9rpJpKwI 1SWRPwfEMK2NoJ4oqE1Tu+wggIfC8ZRskT6bpOPJZxtq3GGjW8gXksHsiZZmhT0hdmeoOnHcnRd JxuF/63TshLCQ== X-Google-Smtp-Source: AGHT+IEweAC+rlhcy5i5NRxELR50Y4/nSt1dqxGH81AOkk2/aXvhX1D9nlR48EF6dvli2FR22ZSJdw== X-Received: by 2002:a05:600c:34c5:b0:47a:80f8:82ab with SMTP id 5b1f17b1804b1-47d84b3275fmr228218325e9.24.1768207382136; Mon, 12 Jan 2026 00:43:02 -0800 (PST) Message-ID: <8a2125c7-c5ec-4be1-a7a5-61b2936cc90f@suse.com> Date: Mon, 12 Jan 2026 09:43:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Cpufreq drivers not working on T480S To: Milky Cc: "xen-devel@lists.xenproject.org" , Jason Andryuk References: <7dbd26d1-0d9a-454f-90d8-5a7f3d8e12da@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.01.2026 09:44, Milky wrote: > On Thursday, January 8th, 2026 at 7:46 AM, Jan Beulich wrote: > >>> The same is also true under Debian Live; does it mean that frequency scaling, since it seems to be working under Debian Live, doesn't always rely on this? >> >> >> Yes, that's possible afaik. Which driver is in use there? > > `/sys/devices/system/cpu/cpu0/scaling_driver` shows `intel_pstate`; confirmed also using `dmesg`, which shows Intel P-state initialisation and HWP being enabled. > >>> Maybe also with Xen's command line try cpufreq=xen:no-hwp to disable >>> HWP and see if the regular ACPI cpufreq driver works better > > Following from Marek's message elsewhwere in the thread, I now tried adding in grub the correct Xen flag to disable HWP on Qubes: `cpufreq=xen,no-hwp`. I am pasting below the output of `xl dmesg`. It seems it no longer reports HWP being enabled. However, `xenpm get-cpufreq-para` still says "failed to get cpufreq parameter", `xenpm get-cpufreq-states` returns nothing. And was is meanwhile checked that ACPI provides the necessary tables, and xen-processor-acpi manages to processes and upload them? Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 09:46:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 09:46:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1199922.1515951 (Exim 4.92) (envelope-from ) id 1vfEUj-0008UV-Es; Mon, 12 Jan 2026 09:45:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1199922.1515951; Mon, 12 Jan 2026 09: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 1vfEUj-0008UO-BL; Mon, 12 Jan 2026 09:45:53 +0000 Received: by outflank-mailman (input) for mailman id 1199922; Mon, 12 Jan 2026 09:45:52 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfEUi-0008UI-2O for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 09:45:52 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id 772a6530-ef9b-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 10:45:45 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5A486339; Mon, 12 Jan 2026 01:45:37 -0800 (PST) Received: from [10.57.48.185] (unknown [10.57.48.185]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D5C6F3F694; Mon, 12 Jan 2026 01:45:36 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 772a6530-ef9b-11f0-9ccf-f158ae23cfc8 Message-ID: Date: Mon, 12 Jan 2026 10:45:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 14/14] mm: Add basic tests for lazy_mmu To: "David Hildenbrand (Red Hat)" , linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, Alexander Gordeev , Andreas Larsson , Andrew Morton , Anshuman Khandual , Boris Ostrovsky , Borislav Petkov , Catalin Marinas , Christophe Leroy , Dave Hansen , "David S. Miller" , David Woodhouse , "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 , "Ritesh Harjani (IBM)" , Ryan Roberts , Suren Baghdasaryan , Thomas Gleixner , Venkat Rao Bagalkote , 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, x86@kernel.org References: <20251215150323.2218608-1-kevin.brodsky@arm.com> <20251215150323.2218608-15-kevin.brodsky@arm.com> <1e123306-0efe-457f-953b-d4a27ce6bc60@kernel.org> From: Kevin Brodsky Content-Language: en-GB In-Reply-To: <1e123306-0efe-457f-953b-d4a27ce6bc60@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 09/01/2026 16:07, David Hildenbrand (Red Hat) wrote: > > Very nice test 🙂 Thanks! > > I think I prefer the EXPORT_SYMBOL_IF_KUNIT over disabling the test > for PPC and over making lazy_mmu_mode_enable() non-inlined functions > with an exported symbol The EXPORT_SYMBOL_IF_KUNIT approach is what's currently in mm-unstable (with the fixes from Ritesh and me). - Kevin From xen-devel-bounces@lists.xenproject.org Mon Jan 12 10:09:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 10:09:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1199933.1515961 (Exim 4.92) (envelope-from ) id 1vfErb-0002xO-84; Mon, 12 Jan 2026 10:09:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1199933.1515961; Mon, 12 Jan 2026 10: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 1vfErb-0002xH-4C; Mon, 12 Jan 2026 10:09:31 +0000 Received: by outflank-mailman (input) for mailman id 1199933; Mon, 12 Jan 2026 10:09: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 1vfErZ-0002xB-QC for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 10:09:29 +0000 Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [2a00:1450:4864:20::432]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c53f3176-ef9e-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 11:09:24 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-42fb4eeb482so3477016f8f.0 for ; Mon, 12 Jan 2026 02:09:24 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0e16f4sm38680118f8f.11.2026.01.12.02.09.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 02:09:23 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c53f3176-ef9e-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768212564; x=1768817364; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=RyUWjuReO2HT3zEu/zgDiLMwqzTVZVcSD9+UUhBsXOw=; b=Poq2hMBq/PfSaEC9gJB70fZfsb/jOrz7s0em8vmVr0u3SHcxbh1soCq5GkUM8SsiW6 3DvrzJNb9AbcbWqE+6wB9yx9yPVDVrpTx+YB8W+JLuCipSlQkPNyAUm+OXpcMBLxbJxQ kTqRPApWI4maf01MQ94WFEISng+/S5RRc7y9keR7UR8sfql1onoJi3agxJq4G4doLzbK j5VC7F3UjpfKwfjcVXLeIghvWTUpaSqQzTSmjmfqux5abLRAkw6ao84n8+7hRSygNz+0 pyOawfOGo88ywWUc0a1uUNsN3k0HEFeVPQc/pjM6gKqmJ7K94L0PdxRKwmpaS3y7OmEb Vr7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768212564; x=1768817364; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=RyUWjuReO2HT3zEu/zgDiLMwqzTVZVcSD9+UUhBsXOw=; b=NkEad/e7qFkc5VwajxTGbCjaN3tg38SzmZbcs8ItkvkTkPwXiBAMJ2DaFVQzz404vx ntj+Afos3Lpszm7rVIv4KqM/OiB5y8wUgZKGN5nv78yX5s/PsJ0YGLf0H6Z1OgTA95qv NSc9C4kvJqzufbKCMpBwTQ+f5KBBfsoVfjAHIymA/aJy7PVjCHunJorPu29Ws8YTamfj 2J4xY+EoHbxgH/V2zqLNmaiF0lx9MHEePLJrtp4SBGlqbb/8WU1j63sERzezYTdPkUV2 kapz9OtwFJsJNAeV051xVtlqVfvKBObuvpMRs7l3Ps2vYgqI5LRHXX3U5SFDBsAlcw/V XNZg== X-Gm-Message-State: AOJu0Yz0ut0NL14W3FR1ecCKYzPdXiZohXcSkQq7w7HGuRLMsb/Fg4+P n7Zit9xYHcRwzNVP1WjGOXXzHJgjfyyLjxMp2EY4vrXGXeqyngTxyPwBsjL4R1LGOw== X-Gm-Gg: AY/fxX7380dv9Ko8V+/4mS9eGZPQz8F+9+vCXST4QokxIl2ro80rLjZYKVQHwYNawl4 NcFcHyK9AK2Gzj9rvlJxVKhmPyR1lvov43WIO6bnrR1yzT94/lsO57FX+/uryKfYzHtPJY6s1MY EU34YvdUaL2fNxHsVXbfpdQpyaVE4s+Ba3DzqAWf10ST02cHMqO/RY23pkwY7oqqun6Gi3HX6S7 paD1p3fxfUH93mMW6sBUyxMrNGMndpFVjZoA8NHPRY16qT7w5QeXEGWfQAhcauaNmllgxqE+2cT n9ZdZMQyF+4m+OhcU3hI4/mDIaHUvqxBkmIPiUsZDXZVlnLex+sn6LsQGfAr+ZTm7aauWvUKulc SL5BicM1OiUA8UZTIlAKrnxaKNxceojWZEz4oqssrTLs7lilgp24hhjbwo8Wcc4uwbOIV/3Q3kr vXwwOuo4WaOVBfgblAvGbSmLWusheI1Os3qmM5C5P0pLfIM6J+MZhP7gN9XSLouMbicl3ojeJEH qM= X-Google-Smtp-Source: AGHT+IGs/FOAMa8Kt6DANF8r7+CzagRCuMnNn3oAAs7Ac712feB4rHr5MRbvOl4vfdEdf1n3FdEM9A== X-Received: by 2002:a05:600c:c8a:b0:479:3a88:de5e with SMTP id 5b1f17b1804b1-47d84b4a079mr179227465e9.37.1768212563643; Mon, 12 Jan 2026 02:09:23 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2026 11:09:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN][PATCH] console/consoleio: account for xen serial input focus during write To: Stefano Stabellini Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Victor Lira , Grygorii Strashko References: <20251204233211.980862-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 09.01.2026 23:35, Stefano Stabellini wrote: > I independently wrote this patch which also supports console reads. > Sorry about the mixed messages. > > --- > > > xen/console: handle multiple domains using console_io hypercalls > > Allow multiple dom0less domains to use the console_io hypercalls to > print to the console. Handle them in a similar way to vpl011: only the > domain which has focus can read from the console. All domains can write > to the console but the ones without focus have a prefix. In this case > the prefix is applied by using guest_printk instead of printk or > console_puts which is what the original code was already doing. > > Signed-off-by: Stefano Stabellini > --- > xen/drivers/char/console.c | 22 +++++++++++++++++++++- > 1 file changed, 21 insertions(+), 1 deletion(-) > > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c > index dcc31170f2..826bee3848 100644 > --- a/xen/drivers/char/console.c > +++ b/xen/drivers/char/console.c > @@ -729,6 +729,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, > unsigned int flags = opt_console_to_ring > ? CONSOLE_ALL : CONSOLE_DEFAULT; > struct domain *cd = current->domain; > + struct domain *input; > > while ( count > 0 ) > { > @@ -741,17 +742,26 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, > if ( copy_from_guest(kbuf, buffer, kcount) ) > return -EFAULT; > > - if ( is_hardware_domain(cd) ) > + input = console_get_domain(); > + if (input && cd == input) Nit: Style (losing blanks). > { > + if ( cd->pbuf_idx ) > + { > + cd->pbuf[cd->pbuf_idx] = '\0'; > + console_send(cd->pbuf, cd->pbuf_idx + 1, flags); > + cd->pbuf_idx = 0; > + } What is pbuf_idx? I can't find any such field in present staging. With that it is also unclear what is actually being done here. In any event I don't think you want to print/send the trailing nul char that you insert. With that (and with console_send() taking the length anyway) it's further unclear why the nul needs inserting in the first place (and thus, as it looks, risking a buffer overrun). > @@ -793,6 +803,7 @@ long do_console_io( > { > long rc; > unsigned int idx, len; > + struct domain *d; > > rc = xsm_console_io(XSM_OTHER, current->domain, cmd); > if ( rc ) > @@ -813,6 +824,13 @@ long do_console_io( > if ( count > INT_MAX ) > break; > > + d = console_get_domain(); > + if ( d != current->domain ) > + { > + console_put_domain(d); > + return 0; > + } > + > rc = 0; > while ( (serial_rx_cons != serial_rx_prod) && (rc < count) ) > { > @@ -824,12 +842,14 @@ long do_console_io( > len = count - rc; > if ( copy_to_guest_offset(buffer, rc, &serial_rx_ring[idx], len) ) > { > + console_put_domain(d); > rc = -EFAULT; > break; > } > rc += len; > serial_rx_cons += len; > } > + console_put_domain(d); > break; > default: > rc = -ENOSYS; Hmm, this looks insufficient to me. Unconsumed input at the point focus switches should not blindly go to the next domain. It was intended for what was the focus at the time of typing. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 10:19:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 10:19:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1199943.1515971 (Exim 4.92) (envelope-from ) id 1vfF1H-0004dl-45; Mon, 12 Jan 2026 10:19:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1199943.1515971; Mon, 12 Jan 2026 10:19:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfF1H-0004de-0G; Mon, 12 Jan 2026 10:19:31 +0000 Received: by outflank-mailman (input) for mailman id 1199943; Mon, 12 Jan 2026 10:19:29 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfF1F-0004dY-LZ for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 10:19:29 +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 2c8c50e2-efa0-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 11:19:28 +0100 (CET) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-64b9d01e473so10316433a12.2 for ; Mon, 12 Jan 2026 02:19:27 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6507bf6648fsm17204943a12.28.2026.01.12.02.19.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 02:19:25 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2c8c50e2-efa0-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768213166; x=1768817966; 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=S8cNnMgGRzbmVNuAN76xJOWMAaiFOowG5vdLwJVgWDI=; b=HxMQodqxmMPozQoKt0HSHzCjlcN7Z8cNVc2ZlSGV37b81DeVArBvcF1rA4JG9omtpC oHiff9vpCvRlYPOOLZntnQPwt6uaZ4JA+Y+k+ifhuqBQlQiFL+b+mvssoYPo02IPJOv5 nX6U5/otS7A9RgqQpwxD5gp2Vq1oHBhpGAx1GpVMlqBJr/fF8PUJnAbAduhFbe93TKnJ tMOEUJfUocC/zgBpNDwvxaYgcVWgkvk/sy9pqGPPLsoDKBReo7b2CUrYlrasTec6PcuQ ogjqenmexIXptz3sUGCDtnKLVwVp15G5dU0R2AhBN8niaqFtzYfK6nS/U/pJtywgwWBI BVJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768213166; x=1768817966; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=S8cNnMgGRzbmVNuAN76xJOWMAaiFOowG5vdLwJVgWDI=; b=QlzNK+udgoo7aX5241QpgLGM4Jwty9PE7/qLAV3cEFjyrLmUlggqi3szL/Jg9wJrgT PyyY462uDjwtRw47Msx25BL+XnqZkKEfkOqyliQA/BQ1+4KOBOB5+HFDmlzNHX746phS aSclGC1eiBQZ/v5jeu+TNtUma/Zmy4M7ZZlzD1lDpjKSt4uw1XhsFk6cECK84j5vn6pp vT0kMHwfriLMxiXBeoQ8GQ9LTjuucsPGFPY24InjmFC/Ot57/9IChyCi/NWcAEcjq4dd gbt51UFCbHLP5WT9MP+FY5RQqUXleTj+JxoLrZBhMKJnVGhSRRR1UIZ3l3LLcqfzkvgL AZ3Q== X-Forwarded-Encrypted: i=1; AJvYcCXxiRe+tweP6phupre9PR3ixfD6p/Addyfq55CRetPVdUp+vTiNYeGrFEwohJcdL/jxagOq6VrTDDQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YyHhp1Ipv+JC1r+LnkbXQDT2spO6bhbrMGrV/Gfy+pHUfyxt/PD crrSTs9gkSx4rfs848Qfhr+paGHBcMbx2DC8XgEt8+h/iQufOfbGeOCG X-Gm-Gg: AY/fxX6fgM4FZ1jdxg7OoRp36MPKoCasqB6PChZ2Quu0AXH261j924k3E6HUW6Nd3Jt NxvxPtfrr79W/Ia6HllgSiYQ98p0KzhkeLEXJ74o7Mp/A6HDxsNNz+q2AR2Kn0NBKkcHfuTDNVr qOt65pZYFdk4WwtnYH1mjRz/BREb0rGFio76mjKnB5L0vZjFoflQQvNexdU6FKBNovKizPgu48F K3krrbsbMbAXno/5N0LRdMhghkBNyXv4boyaCMu+rjKApXACYAt6itf+434c4XiWMLddDRMdKj5 H/yG52bAMhWt2IR4JHw/GrIdhVKPipIJCW/lmlI7Sm7CbyC5BgGJYm8U0/j5l/UaEb45kSyQyie aTeM0VbRdxePZyxlJVXZLN0VVZumR902/4nZSuhx5bAc+MrB7k5mk9xQaCOL5YLjvF7DPpG/WFe o+Z+OyqRYt3o6ScS/3otjT+V75S9PqPaWBbhXuFL/UqCS6ukLDl7L1pnM9IQ5oHak= X-Google-Smtp-Source: AGHT+IEzblSRHenzGT1D9WFy+qk/RZC7irbon66oklI20cDD0wMf79Z+kqfuGQ6uaxvhlxQMS8Wvlw== X-Received: by 2002:a05:6402:524c:b0:647:9380:103c with SMTP id 4fb4d7f45d1cf-65097df5672mr17321412a12.13.1768213166248; Mon, 12 Jan 2026 02:19:26 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2026 11:19:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 02/15] xen/riscv: implement arch_vcpu_{create,destroy}() 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: <2e7ab738-6b5d-4ac4-a46b-1eef1cd09fb1@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <2e7ab738-6b5d-4ac4-a46b-1eef1cd09fb1@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/6/26 4:56 PM, Jan Beulich wrote: > (some or even all of the comments may also apply to present Arm code) > > On 24.12.2025 18:03, Oleksii Kurochko wrote: >> --- /dev/null >> +++ b/xen/arch/riscv/domain.c >> @@ -0,0 +1,56 @@ >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> + >> +#include >> +#include >> + >> +static void continue_new_vcpu(struct vcpu *prev) >> +{ >> + BUG_ON("unimplemented\n"); >> +} >> + >> +int arch_vcpu_create(struct vcpu *v) >> +{ >> + int rc = 0; >> + >> + BUILD_BUG_ON(sizeof(struct cpu_info) > STACK_SIZE); > I fear you're in trouble also when == or when only a few bytes are left on > the stack. IOW I'm unconvinced that this is a useful check to have. > >> + v->arch.stack = alloc_xenheap_pages(STACK_ORDER, MEMF_node(vcpu_to_node(v))); >> + if ( !v->arch.stack ) >> + return -ENOMEM; > You don't really need contiguous memory, do you? In which case why not > vmalloc()? This would then also use the larger domheap. There is really no need for contiguous memory, and|vmalloc()| could be used. I expect that|vmalloc()| is more expensive and may make hardware prefetching less effective, with more TLB pressure since it allocates 4 KB pages. However, the latter two points do not really matter in this case, as only a single 4 KB page is allocated, so we are unlikely to see any performance issues. > >> + v->arch.cpu_info = (struct cpu_info *)(v->arch.stack >> + + STACK_SIZE >> + - sizeof(struct cpu_info)); > Why the cast? Just for readability, from compiler point of view it could be just dropped. > >> + memset(v->arch.cpu_info, 0, sizeof(*v->arch.cpu_info)); >> + >> + v->arch.xen_saved_context.sp = (register_t)v->arch.cpu_info; >> + v->arch.xen_saved_context.ra = (register_t)continue_new_vcpu; >> + >> + printk("Create vCPU with sp=%#lx, pc=%#lx, cpu_info(%#lx)\n", >> + v->arch.xen_saved_context.sp, v->arch.xen_saved_context.ra, >> + (unsigned long)v->arch.cpu_info); > Please don't, as this is going to get pretty noisy. (And if this wanted > keeping, use %p for pointers rather than casting to unsigned long.) I didn’t consider the case where a large number of vCPUs are created, as I have only tested with 2 vCPUs. However, if the number of vCPUs is large, this could indeed get quite noisy. I will keep these lines of code in downstream for debugging purposes and drop them from upstream version of this patch. >> --- a/xen/arch/riscv/include/asm/current.h >> +++ b/xen/arch/riscv/include/asm/current.h >> @@ -21,6 +21,12 @@ struct pcpu_info { >> /* tp points to one of these */ >> extern struct pcpu_info pcpu_info[NR_CPUS]; >> >> +/* Per-VCPU state that lives at the top of the stack */ >> +struct cpu_info { >> + /* This should be the first member. */ >> + struct cpu_user_regs guest_cpu_user_regs; >> +}; > You may want to enforce what the comment says by way of a BUILD_BUG_ON(). Makes sense, I will add: BUILD_BUG_ON(offsetof(struct cpu_info, guest_cpu_user_regs) != 0); in|arch_vcpu_create()|, somewhere around the initialization of|v->arch.cpu_info = ... . |I noticed that there is no|BUILD_BUG_ON()| variant that can be used outside of a function, or does such a variant exist and I’m just missing it? Or there is no such sense at all for such variant? > >> --- a/xen/arch/riscv/include/asm/domain.h >> +++ b/xen/arch/riscv/include/asm/domain.h >> @@ -49,6 +49,9 @@ struct arch_vcpu >> register_t ra; >> } xen_saved_context; >> >> + struct cpu_info *cpu_info; >> + void *stack; > Do you really need both fields, when one is derived from the other? No, I don't need. I think we can just keep cpu_info and it would be enough. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Jan 12 10:32:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 10:32:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1199959.1515980 (Exim 4.92) (envelope-from ) id 1vfFDa-0007KA-Ay; Mon, 12 Jan 2026 10:32:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1199959.1515980; Mon, 12 Jan 2026 10:32:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfFDa-0007K3-8F; Mon, 12 Jan 2026 10:32:14 +0000 Received: by outflank-mailman (input) for mailman id 1199959; Mon, 12 Jan 2026 10:32:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfFDY-0007Jx-N4 for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 10:32:12 +0000 Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [2607:f8b0:4864:20::431]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f31d437f-efa1-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 11:32:10 +0100 (CET) Received: by mail-pf1-x431.google.com with SMTP id d2e1a72fcca58-81dbc0a99d2so1357584b3a.1 for ; Mon, 12 Jan 2026 02:32:10 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f31d437f-efa1-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768213929; x=1768818729; 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=xJq36P2xRSabsBXWh2dg89QFZQwklsnQcHo/bBHzHZk=; b=RvKGCW15Fc6n9IW5rsGk31xnU0ILakRvV9exDodtaw0SZzaqXhzYMaMC8nrlDAVjNM D7CMKziPgJzGpc6kibTIerUN1eSxvgSFX7f7geKXxzInIkqHpWH8nXjVqEz5QxPawNWz 4nSlVLrApUnd38YSS3gHT26ZdcQbRna6lXlJzdEaWkgp8xDtuoa7HUqKmyJAagzXZ9UM YmceE1ZPo0/+q9oT2JjfQZkIMC5T/1pml3mEXHkq9MMcX9QZgEB83/1b8SxhcXrSW6yz j8ZrqW2IWhNvuSVYtvhzCFiKXgJwRPLMkUw1SV7iRsE6fbU8dkqto5KqUMlzparDnizQ w/eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768213929; x=1768818729; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xJq36P2xRSabsBXWh2dg89QFZQwklsnQcHo/bBHzHZk=; b=pNGVAwj9S1MfoKk0HCFA+EhY5PRq43cXiSZohONreHY1fjBgpUohI4shGP38c7N1A8 Iwfjv4gc7DQhswD8aRVIFepC01V3yZXLgAW7qfsPxskMR4OYpvCFxocF6oJ+7u1eATHu Gtw9g7euSp5tDB7wC602ZJeOyqUAUZJ10HN6cOTp7wEhyFJQSMX2VDSmShjbK2RpAm9k M9H2G5HWCsV3sIfcEDbOWv1ZOQHbdYjYeCC37xfEUYo4JKUobuUUjnTiyLT6Fiv+crO/ /OGiKgISAu0ilwzBozlcxXh3oxpAhRAUUgB5TJskh6T4DQEEldO7q206Na7135Obl+ID Zj9Q== X-Forwarded-Encrypted: i=1; AJvYcCX/X9Rr6g9UeiI4PE1F8eDujh6VGeqvXvNf+pHWunxnySd35qU4xmLBCC1ecsGY/hyurg8fqs/EL+k=@lists.xenproject.org X-Gm-Message-State: AOJu0Yyakizi1e7D81qrOP4EA5/UHQsJLOT/sLxULMvhztIYzPaFlKem 4SRd6Gjg9GGA8OQy7AOi0uuH9jTh+lq3ZKriLM2eymqANKA6OkLHOmjr7aD0TMQ3t/Qc7Xi6nL2 XgQO2kGTtf8ysdwQ7Jq5PK4MmJIOCi/Q= X-Gm-Gg: AY/fxX6/wGKImOWC9Ybbhgsk7ogiusuCEiTxU223Rnt8hzyfbc98E34ywudq7E4MBP+ 0uyWERs/K/gZhEAFGGDlzYoFJtXEPtkUMluzpB+lIMX0W9xmZYVGEfuSGL2iziAzhQF63QeImw3 FYj9EofdGkOOdYZ7dD9/oe6RxdrGA25iE5cJSSgn83zYHP18NzB+uT/PfBhCcEJ4mIZvxV0KFFV 91RwyvXATkXaJ8ZyBldO+6FaJBsVY525dh4PkmlcMP+fdSZNdU7aY+/W2Ef+qrBbp4vLjSn X-Google-Smtp-Source: AGHT+IGIk7ybTN/CU/uqoNQ5yuHm+2aOq/7Nzsh+4Gr4qqCJ+RCbIxHjVlQ8/J5rcAu/Oiz5bGt1PNnMSODq/PESAtU= X-Received: by 2002:a05:6a20:918a:b0:2cd:a43f:78fb with SMTP id adf61e73a8af0-3898f9b9970mr15606765637.48.1768213928792; Mon, 12 Jan 2026 02:32:08 -0800 (PST) MIME-Version: 1.0 References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> <4a6b6307-9014-4c4c-8c23-3673efa2d1b1@gmail.com> <794c382b-3b20-4d2a-ab70-b24d7fdf88ae@suse.com> In-Reply-To: From: Anton Markov Date: Mon, 12 Jan 2026 13:31:57 +0300 X-Gm-Features: AZwV_QhlyStrZaa1rsKzHe5dZ7Rz5Ujlvr4YDPI1g7JaDKeWliSqan7tNweQPZ8 Message-ID: Subject: Re: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() To: Jan Beulich Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="0000000000001cd62d06482e6369" --0000000000001cd62d06482e6369 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Bit rounding isn't the main issue; the difference in ipi delivery to the cores accumulates due to the ordering. Replacing get_s_time_fixed with scale_delta in time_calibration_rendezvous_tail should be sufficient. This configuration won't accumulate errors, but bit rounding can still cause a significant difference from calibration to calibration, but it's not as significant. On Fri, Jan 9, 2026 at 7:11=E2=80=AFPM Anton Markov = wrote: > You're right. These aren't interrupts in get_s_time_fixed, but rather a > cumulative error in the sequence due to integer rounding. I added logging > of the current local_stime to local_time_calibration and noticed that the > timestamp between cores is gradually increasing. If the server has been > running for weeks, this could be a very large value. > > > ``` > > @@ -1732,6 +1753,8 @@ static void cf_check local_time_calibration(void) > > if ( boot_cpu_has(X86_FEATURE_CONSTANT_TSC) ) > > { > > /* Atomically read cpu_calibration struct and write cpu_time struct. */ > > + printk("update stime on time calibrate %d, %lu -> %lu (%lu, %lu)\n", > smp_processor_id(), t->stamp.local_stime, c->local_stime, > > + t->last_seen_ns, t->last_seen_tsc); > > local_irq_disable(); > > t->stamp =3D *c; > > local_irq_enable(); > > ``` > > > 2 hours of work: > > > ``` > > (XEN) update stime on time calibrate 0, 8564145820102 -> 8565145861597 > (8565145862216, 0) > > (XEN) update stime on time calibrate 1, 8564145820129 -> 8565145861609 > (8565145863957, 0) > > (XEN) update stime on time calibrate 3, 8564145819996 -> 8565145861491 > (8565145864800, 0) > > (XEN) update stime on time calibrate 2, 8564145820099 -> 8565145861609 > (8565145865372, 0) > > > 8565145861609 - 8565145861491 =3D 115 * 3 (3.00 GHz) =3D 345 lag > > ``` > > > 6 hours of work: > > ``` > > (XEN) update stime on time calibrate 0, 22914730829200 -> 22915730869993 > (22915730870665, 0) > > (XEN) update stime on time calibrate 1, 22914730829073 -> 22915730869889 > (22915730870693, 0) > > (XEN) update stime on time calibrate 2, 22914730829052 -> 22915730869841 > (22915730872231, 0) > > (XEN) update stime on time calibrate 3, 22914730828892 -> 22915730869696 > (22915730872096, 0) > > > 22915730869993 - 22915730869696 =3D 297 * 3 (3.00 GHz) =3D 891 lag > > ``` > > > Clarification, according to my xen settings: > > ``` > > ucode=3Dscan dom0_mem=3D53923M,max:53923M dom0_max_vcpus=3D4-96 dom0_vcpu= s_pin=3D0 > force-ept=3D1 ept=3Dno-ad,no-pml hap_1gb=3D0 hap_2mb=3D0 altp2m=3D1 > hpet=3Dlegacy-replacement smt=3D1 spec-ctrl=3Dno gnttab_max_frames=3D512 > cpufreq=3Dxen:performance max_cstate=3D1 sched=3Dcredit sched-gran=3Dcpu = apicv=3D0 > sched_credit_tslice_ms=3D5 sched_ratelimit_us=3D500 > > ``` > > > Processors I tested on: > > > ``` > > Intel(R) Core(TM) i5-3330 CPU @ 3.00GHz > > > Flags: fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx > fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nopl > nonstop_tsc cpuid tsc_known_freq pni pclmulqdq monitor est ssse3 cx16 > sse4_1 sse4_2 popcnt aes xsave avx f16c hypervisor lahf_lm cpuid_fault > fsgsbase erms xsaveopt arch_capabilities > > ``` > > ``` > > Intel(R) Xeon(R) Gold 5318Y CPU @ 2.10GHz x2 (NUMA) > > > Flags: fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx > fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nopl > nonstop_tsc cpuid tsc_known_freq pni pclmulqdq monitor est ssse3 fma cx16 > sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm a= bm > 3dnowprefetch cpuid_fault ibpb fsgsbase bmi1 avx2 bmi2 erms rtm avx512f > avx512dq rdseed adx avx512ifma clflushopt clwb avx512cd sha_ni avx512bw > avx512vl xsaveopt xsavec xgetbv1 avx512vbmi avx512_vbmi2 gfni vaes > vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid fsrm md_clear > arch_capabilities > > ``` > > > Next I moved the code to r3 to speed up playback: > > > ``` > > #include > > #include > > > static __inline__ unsigned long long rdtsc(void) > > { > > unsigned hi, lo; > > __asm__ __volatile__ ("rdtsc" : "=3Da"(lo), "=3Dd"(hi)); > > return ( (unsigned long long)lo)|( ((unsigned long long)hi)<<32 ); > > } > > > #define MILLISECS(_ms) ((int64_t)((_ms) * 1000000ULL)) > > > struct cpu_time_stamp { > > uint64_t local_tsc; > > int64_t local_stime; > > int64_t master_stime; > > }; > > > struct time_scale { > > int shift; > > uint32_t mul_frac; > > }; > > > > static inline uint32_t div_frac(uint32_t dividend, uint32_t divisor) > > { > > uint32_t quotient, remainder; > > asm ( > > "divl %4" > > : "=3Da" (quotient), "=3Dd" (remainder) > > : "0" (0), "1" (dividend), "r" (divisor) ); > > return quotient; > > } > > > > void set_time_scale(struct time_scale *ts, uint64_t ticks_per_sec) > > { > > uint64_t tps64 =3D ticks_per_sec; > > uint32_t tps32; > > int shift =3D 0; > > > while ( tps64 > (MILLISECS(1000)*2) ) > > { > > tps64 >>=3D 1; > > shift--; > > } > > > tps32 =3D (uint32_t)tps64; > > while ( tps32 <=3D (uint32_t)MILLISECS(1000) ) > > { > > tps32 <<=3D 1; > > shift++; > > } > > > ts->mul_frac =3D div_frac(MILLISECS(1000), tps32); > > ts->shift =3D shift; > > } > > > > uint64_t scale_delta(uint64_t delta, const struct time_scale *scale) > > { > > uint64_t product; > > > if ( scale->shift < 0 ) > > delta >>=3D -scale->shift; > > else > > delta <<=3D scale->shift; > > > asm ( > > "mulq %2 ; shrd $32,%1,%0" > > : "=3Da" (product), "=3Dd" (delta) > > : "rm" (delta), "0" ((uint64_t)scale->mul_frac) ); > > > return product; > > } > > > #define _TS_MUL_FRAC_IDENTITY 0x80000000UL > > > static inline struct time_scale scale_reciprocal(struct time_scale scale) > > { > > struct time_scale reciprocal; > > uint32_t dividend; > > > dividend =3D _TS_MUL_FRAC_IDENTITY; > > reciprocal.shift =3D 1 - scale.shift; > > while ( dividend >=3D scale.mul_frac ) > > { > > dividend >>=3D 1; > > reciprocal.shift++; > > } > > > asm ( > > "divl %4" > > : "=3Da" (reciprocal.mul_frac), "=3Dd" (dividend) > > : "0" (0), "1" (dividend), "r" (scale.mul_frac) ); > > > return reciprocal; > > } > > > > int64_t get_s_time_fixed(const struct cpu_time_stamp *t, const struct > time_scale *ts, uint64_t at_tsc) > > { > > uint64_t tsc, delta; > > > if ( at_tsc ) > > tsc =3D at_tsc; > > else > > tsc =3D rdtsc(); > > delta =3D tsc - t->local_tsc; > > return t->local_stime + scale_delta(delta, ts); > > } > > > int main() { > > > struct cpu_time_stamp ct; > > struct time_scale ts; > > struct time_scale back; > > > uint64_t start =3D rdtsc(); > > > set_time_scale(&ts, 3000000000); > > back =3D scale_reciprocal(ts); > > > ct.local_tsc =3D start; > > ct.local_stime =3D scale_delta(start, &ts); > > > while (1) { > > uint64_t new_tsc =3D rdtsc(); > > ct.local_stime =3D get_s_time_fixed(&ct, &ts, new_tsc); > > ct.local_tsc =3D new_tsc; > > > uint64_t tmp_tsc =3D rdtsc(); > > printf("%lu %lu\n", tmp_tsc, scale_delta(get_s_time_fixed(&ct, &ts, > tmp_tsc), &back)); > > } > > > return 0; > > } > > ``` > > > It's enough to run the loop for 10-20 seconds to see the problem. > scale_delta rounds the least significant bits during calculation, which > causes the error to accumulate, at different rates on different cores, > depending on the least significant bits at the time of calibration. > > > Now let's talk about why dwm reacts this way. When a snapshot is reversed= , > last_guest_time in hvm_get_guest_time_fixed is set to 0, which doesn't > prevent time from flowing backwards. This means that cache_tsc_offset in > hvm_get_guest_tsc_fixed may be configured correctly on one physical core, > but due to shedding on a physical core with a lagging tsc, the guest may > occasionally see a tsc value lower than it saw before the snapshot was > reversed. If this happens to the dwm code, it terminates with an error. > > > A quick solution to this problem might be to save the last_seen_tsc > parameter in a snapshot for each core, followed by validation. > > > The correct solution is to remove the rounding of the least significant > bits from the sequence. > > On Wed, Jan 7, 2026 at 11:02=E2=80=AFAM Jan Beulich w= rote: > >> On 06.01.2026 21:10, =D0=90=D0=BD=D1=82=D0=BE=D0=BD =D0=9C=D0=B0=D1=80= =D0=BA=D0=BE=D0=B2 wrote: >> > Hi, I'm not sure about the other places. In hvm_load_cpu_ctxt >> > (xen/arch/x86/hvm/hvm.c ), it was easy to catch because >> > process_pending_softirqs is frequently called there, which in turn >> > processes softirqs from the timer (where the timestamp is updated). >> > After I fixed sync_tsc in hvm_load_cpu_ctxt, the problem stopped >> > reproducing under no load. However, when the number of vCPUs is 4 time= s >> > greater than the number of CPUs (under heavy load), the problem rarely >> > reoccurs (mostly during snapshot restores during >> > process_pending_softirqs calls), and this is no longer a simple case. >> If >> > get_s_time_fixed can indeed be interrupted during execution after >> > rdtsc_ordered, then the current fix is insufficient. It's necessary to >> > atomically copy "t->stamp" to the stack using local_irq_disable and >> > local_irq_enable (as in local_time_calibration), and then work with th= e >> > copy, confident in its lifetime and immutability. But until >> > get_s_time_fixed is proven to be interruptible, this is premature, so >> > your fix is sufficient. I think I need more information and testing to >> > say more. >> >> While the cpu_calibration per-CPU variable is updated from IRQ context, >> the cpu_time one isn't. Hence t->stamp's contents cannot change behind >> the back of get_s_time_fixed(). I wonder whether ... >> >> > Regarding the other scale_delta calls, if they include values >> > calculated from externally saved tsc values that could have become >> > stale during the process_pending_softirqs call, this definitely needs >> to >> > be fixed. >> >> ... another similar issue (possibly one not included in the set of >> remarks I have in the patch, as none of those look related to what you >> describe) might be causing the remaining, more rare problems you say you >> see. That set of remarks is actually a result of me going over all other >> scale_delta() calls, but of course I may have got the analysis wrong. >> >> As to using 4 times as many vCPU-s as there are pCPU-s (and then heavy >> load) - while I don't think we have a support statement for such upstrea= m >> (when probably we should), iirc for our (SUSE's) products we would >> consider that unsupported. Just fyi. >> >> Also, btw, please don't top-post. >> >> Jan >> > --0000000000001cd62d06482e6369 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= span class=3D"gmail-jCAhz gmail-ChMk0b">Bit ro= unding isn't the main issue; the difference in ipi delivery to the core= s accumulates due to the ordering. Replacing get_s_time_fixed with= scale_delta in time_calibration_rendezvous_tail should be sufficient. This configuration won't accumulate errors, but bit rounding can s= till cause a significant difference from calibration to calibration, but it= 's not as significant.

On Fri= , Jan 9, 2026 at 7:11=E2=80=AFPM Anton Markov <akmarkov45@gmail.com> wrote:
=09 =09 =09

You're right. These aren't interrupts in get_s_time_fixed, but rather a cumulative error in the sequence due to integer rounding. I added logging of the current local_stime to local_time_calibration and noticed that the timestamp between cores is gradually increasing. If the server has been running for weeks, this could be a very large value.


```<= /p>

@@ -1732,6 +1753,8 @@ static void cf_check local_time_calibration(void)=

if ( boot_cpu_has(X86_FEATURE_CONSTANT_TSC) )

{

/* Atomically read cpu_calibration struct and write cpu_time struct. */=

+ printk("update stime on time calibrate %d, %lu -> %lu (%lu, %lu)\n", smp_processor_id(), t->stamp.local_stime, c->local_stime,

+ t->last_seen_ns, t->last_seen_tsc);

=20 local_irq_disable();

=20 t->stamp =3D *c;

=20 local_irq_enable();

```


2 hours of work:


```

(XEN= ) update stime on time calibrate 0, 8564145820102 -> 8565145861597 (8565145862216, 0)

(XEN= ) update stime on time calibrate 1, 8564145820129 -> 8565145861609 (8565145863957, 0)

(XEN= ) update stime on time calibrate 3, 8564145819996 -> 8565145861491 (8565145864800, 0)

(XEN= ) update stime on time calibrate 2, 8564145820099 -> 8565145861609 (8565145865372, 0)


8565= 145861609 -=20 8565145861491 =3D 115 * 3 (3.00 GHz) =3D 345 lag

```<= /p>


6 hours of work:

```<= /p>

(XEN= ) update stime on time calibrate 0, 22914730829200 -> 22915730869993 (22915730870665, 0)

(XEN= ) update stime on time calibrate 1, 22914730829073 -> 22915730869889 (22915730870693, 0)

(XEN= ) update stime on time calibrate 2, 22914730829052 -> 22915730869841 (22915730872231, 0)

(XEN= ) update stime on time calibrate 3, 22914730828892 -> 22915730869696 (22915730872096, 0)


2291= 5730869993 -=20 22915730869696 =3D 297 * 3 (3.00 GHz) =3D 891 lag

```<= /p>


Clarification, according to my xen settings:

```

ucod= e=3Dscan dom0_mem=3D53923M,max:53923M dom0_max_vcpus=3D4-96 dom0_vcpus_pin=3D0 force-ept=3D1 ept=3Dno-ad,no-pml hap_1gb=3D0 hap_2mb=3D0 altp2m=3D1 hpet=3Dlegacy-replacement smt=3D1 spec-ctrl=3Dno gnttab_max_frames=3D512 cpufreq=3Dxen:performance max_cstate=3D1 sched=3Dcredit sched-gran=3Dcpu apicv=3D0 sched_credit_tslice_ms=3D5 sched_ratelimit_us=3D500

```<= /p>


Proc= essors I tested on:


```<= /p>

Inte= l(R) Core(TM) i5-3330 CPU @ 3.00GHz


Flag= s: =20 fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid tsc_known_freq pni pclmulqdq monitor est ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c hypervisor lahf_lm cpuid_fault fsgsbase erms xsaveopt arch_capabilities

```<= /p>

```<= /p>

Inte= l(R) Xeon(R) Gold 5318Y CPU @ 2.10GHz x2 (NUMA)


Flag= s: =20 fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid tsc_known_freq pni pclmulqdq monitor est ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault ibpb fsgsbase bmi1 avx2 bmi2 erms rtm avx512f avx512dq rdseed adx avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 avx512vbmi avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid fsrm md_clear arch_capabilities

```<= /p>


Next= I moved the code to r3 to speed up playback:


```<= /p>

#inc= lude <stdint.h>

#inc= lude <stdio.h>


stat= ic __inline__ unsigned long long rdtsc(void)

{

= unsigned hi, lo;

= __asm__ __volatile__ ("rdtsc" : "=3Da"(lo), "=3Dd"(hi= ));

= return ( (unsigned long long)lo)|( ((unsigned long long)hi)<<32 );

}


#def= ine MILLISECS(_ms) ((int64_t)((_ms) * 1000000ULL))


stru= ct cpu_time_stamp {

= uint64_t local_tsc;

= int64_t local_stime;

= int64_t master_stime;

};


stru= ct time_scale {

= int shift;

= uint32_t mul_frac;

};



stat= ic inline uint32_t div_frac(uint32_t dividend, uint32_t divisor)

{

= uint32_t quotient, remainder;

= asm (

= "divl %4"

= : "=3Da" (quotient), "=3Dd" (remainder)

= : "0" (0), "1" (dividend), "r" (divisor) );

= return quotient;

}



void set_time_scale(struct time_scale *ts, uint64_t ticks_per_sec)

{

= uint64_t tps64 =3D ticks_per_sec;

= uint32_t tps32;

= int shift =3D 0;


= while ( tps64 > (MILLISECS(1000)*2) )

= {

= tps64 >>=3D 1;

= shift--;

= }


= tps32 =3D (uint32_t)tps64;

= while ( tps32 <=3D (uint32_t)MILLISECS(1000) )

= {

= tps32 <<=3D 1;

= shift++;

= }


= ts->mul_frac =3D div_frac(MILLISECS(1000), tps32);

= ts->shift =20 =3D shift;

}



uint= 64_t scale_delta(uint64_t delta, const struct time_scale *scale)

{

= uint64_t product;


= if ( scale->shift < 0 )

= delta >>=3D -scale->shift;

= else

= delta <<=3D scale->shift;


= asm (

= "mulq %2 ; shrd $32,%1,%0"

= : "=3Da" (product), "=3Dd" (delta)

= : "rm" (delta), "0" ((uint64_t)scale->mul_frac) );


= return product;

}


#def= ine _TS_MUL_FRAC_IDENTITY 0x80000000UL


stat= ic inline struct time_scale scale_reciprocal(struct time_scale scale)

{

= struct time_scale reciprocal;

= uint32_t dividend;


= dividend =3D _TS_MUL_FRAC_IDENTITY;

= reciprocal.shift =3D 1 - scale.shift;

= while ( dividend >=3D scale.mul_frac )

= {

= dividend >>=3D 1;

= =20 reciprocal.shift++;

= }


= asm (

= "divl %4"

= : "=3Da" (reciprocal.mul_frac), "=3Dd" (dividend)

= : "0" (0), "1" (dividend), "r" (scale.mul_frac) );


= return reciprocal;

}



int6= 4_t get_s_time_fixed(const struct cpu_time_stamp *t, const struct time_scale *ts, uint64_t at_tsc)

{

= uint64_t tsc, delta;


= if ( at_tsc )

= tsc =3D at_tsc;

= else

= tsc =3D rdtsc();

= delta =3D tsc - t->local_tsc;

= return t->local_stime + scale_delta(delta, ts);

}


int = main() {


= struct cpu_time_stamp ct;

= struct time_scale ts;

= struct time_scale back;


= uint64_t start =3D rdtsc();


= =20 set_time_scale(&ts, 3000000000);

= back =3D scale_reciprocal(ts);


= ct.local_tsc =3D start;

= ct.local_stime =3D scale_delta(start, &ts);


= while (1) {

= uint64_t new_tsc =3D rdtsc();

= =20 ct.local_stime =3D get_s_time_fixed(&ct, &ts, new_tsc);

= ct.local_tsc =3D new_tsc;


= uint64_t tmp_tsc =3D rdtsc();

= printf("%lu %lu\n", tmp_tsc, scale_delta(get_s_time_fixed(&ct, &ts, tmp_tsc), &back));

= }


= return 0;

}

```<= /p>


It&#= 39;s enough to run the loop for 10-20 seconds to see the problem. scale_delta rounds the least significant bits during calculation, which causes the error to accumulate, at different rates on different cores, depending on the least significant bits at the time of calibration.


Now = let's talk about why dwm reacts this way. When a snapshot is reversed, last_guest_time in hvm_get_guest_time_fixed is set to 0, which doesn't prevent time from flowing backwards. This means that cache_tsc_offset in hvm_get_guest_tsc_fixed may be configured correctly on one physical core, but due to shedding on a physical core with a lagging tsc, the guest may occasionally see a tsc value lower than it saw before the snapshot was reversed. If this happens to the dwm code, it terminates with an error.=20


A qu= ick solution to this problem might be to save the last_seen_tsc parameter in a snapshot for each core, followed by validation.


The = correct solution is to remove the rounding of the least significant bits from the sequence.


= On Wed, Jan 7, 2026 at 11:02=E2=80=AFAM Jan Beulich <jbeulich@suse.com> wrote:
On 06.01.2026 21:10, = =D0=90=D0=BD=D1=82=D0=BE=D0=BD =D0=9C=D0=B0=D1=80=D0=BA=D0=BE=D0=B2 wrote:<= br> > Hi, I'm not sure about the other places. In hvm_load_cpu_ctxt
> (xen/arch/x86/hvm/hvm.c ), it was easy to catch because
> process_pending_softirqs is frequently called there, which in turn > processes softirqs from the timer (where the timestamp is updated). > After I fixed sync_tsc in hvm_load_cpu_ctxt, the problem stopped
> reproducing under no load. However, when the number of vCPUs is 4 time= s
> greater than the number of CPUs (under heavy load), the problem rarely=
> reoccurs (mostly during snapshot restores during
> process_pending_softirqs calls), and this is no longer a simple case. = If
> get_s_time_fixed can indeed be interrupted during execution after
> rdtsc_ordered, then the current fix is insufficient. It's necessar= y to
> atomically copy "t->stamp" to the stack using local_irq_d= isable and
> local_irq_enable (as in local_time_calibration), and then work with th= e
> copy, confident in its lifetime and immutability. But until
> get_s_time_fixed is proven to be interruptible, this is premature, so =
> your fix is sufficient. I think I need more information and testing to=
> say more.

While the cpu_calibration per-CPU variable is updated from IRQ context,
the cpu_time one isn't. Hence t->stamp's contents cannot change = behind
the back of get_s_time_fixed(). I wonder whether ...

> Regarding the other scale_delta calls, if they include values
> calculated from externally saved tsc values that could have become > stale during the process_pending_softirqs call, this definitely needs = to
> be fixed.

... another similar issue (possibly one not included in the set of
remarks I have in the patch, as none of those look related to what you
describe) might be causing the remaining, more rare problems you say you see. That set of remarks is actually a result of me going over all other scale_delta() calls, but of course I may have got the analysis wrong.

As to using 4 times as many vCPU-s as there are pCPU-s (and then heavy
load) - while I don't think we have a support statement for such upstre= am
(when probably we should), iirc for our (SUSE's) products we would
consider that unsupported. Just fyi.

Also, btw, please don't top-post.

Jan
--0000000000001cd62d06482e6369-- From xen-devel-bounces@lists.xenproject.org Mon Jan 12 10:33:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 10:33:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1199972.1515991 (Exim 4.92) (envelope-from ) id 1vfFEl-0007ry-OV; Mon, 12 Jan 2026 10:33:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1199972.1515991; Mon, 12 Jan 2026 10:33: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 1vfFEl-0007rr-Lm; Mon, 12 Jan 2026 10:33:27 +0000 Received: by outflank-mailman (input) for mailman id 1199972; Mon, 12 Jan 2026 10:33:26 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfFEk-0007rj-Mw for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 10:33:26 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id 1f590850-efa2-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 11:33:24 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9EF30497; Mon, 12 Jan 2026 02:33:16 -0800 (PST) Received: from [10.57.94.20] (unknown [10.57.94.20]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 791FB3F59E; Mon, 12 Jan 2026 02:33:22 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1f590850-efa2-11f0-9ccf-f158ae23cfc8 Message-ID: Date: Mon, 12 Jan 2026 10:33:21 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/6] arm/mpu: Implement vmap functions for MPU Content-Language: en-GB To: "Orzel, Michal" , xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk References: <20260105113503.2674777-1-harry.ramsey@arm.com> <20260105113503.2674777-3-harry.ramsey@arm.com> <40677f79-8e3a-4c0c-876d-d57e9b230eca@amd.com> From: Harry Ramsey In-Reply-To: <40677f79-8e3a-4c0c-876d-d57e9b230eca@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 09/01/2026 14:00, Orzel, Michal wrote: > > On 05/01/2026 12:34, Harry Ramsey wrote: >> From: Luca Fancellu >> >> HAS_VMAP is not enabled on MPU systems, but the vmap functions are used >> in places across common code. In order to keep the existing code and >> maintain correct functionality, implement the `vmap_contig` and `vunmap` >> functions for MPU systems. >> >> Introduce a helper function `destroy_xen_mapping_containing` to aid with >> unmapping an entire region when only the start address is known. >> >> Signed-off-by: Luca Fancellu >> Signed-off-by: Harry Ramsey >> --- >> v2: >> - Rename `destroy_entire_xen_mapping` to `destroy_xen_mapping_containing` >> - Improve code documentation. >> - Refactor nested code. >> - Fix ignored rc error code in `destroy_xen_mapping_containing`. >> --- >> xen/arch/arm/include/asm/mpu/mm.h | 10 +++++ >> xen/arch/arm/mpu/mm.c | 74 ++++++++++++++++++++++++++----- >> xen/arch/arm/mpu/vmap.c | 14 ++++-- >> 3 files changed, 83 insertions(+), 15 deletions(-) >> >> diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h >> index e1ded6521d..1b5ffa5b64 100644 >> --- a/xen/arch/arm/include/asm/mpu/mm.h >> +++ b/xen/arch/arm/include/asm/mpu/mm.h >> @@ -111,6 +111,16 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags); >> int mpumap_contains_region(pr_t *table, uint8_t nr_regions, paddr_t base, >> paddr_t limit, uint8_t *index); >> >> + >> +/* >> + * Destroys and frees (if reference count is 0) an entire xen mapping on MPU >> + * systems where only the start address is known. >> + * >> + * @param s Start address of memory region to be destroyed. >> + * @return: 0 on success, negative on error. >> + */ >> +int destroy_xen_mapping_containing(paddr_t s); >> + >> #endif /* __ARM_MPU_MM_H__ */ >> >> /* >> diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c >> index 687dec3bc6..207e8d2d91 100644 >> --- a/xen/arch/arm/mpu/mm.c >> +++ b/xen/arch/arm/mpu/mm.c >> @@ -290,6 +290,42 @@ static void disable_mpu_region_from_index(uint8_t index) >> write_protection_region(&xen_mpumap[index], index); >> } >> >> +/* >> + * Free a xen_mpumap entry given the index. A mpu region is actually disabled >> + * when the refcount is 0 and the region type is MPUMAP_REGION_FOUND. >> + * >> + * @param idx Index of the mpumap entry. >> + * @param region_found_type MPUMAP_REGION_* value. >> + * @return 0 on success, otherwise negative on error. >> + */ >> +static int xen_mpumap_free_entry(uint8_t idx, int region_found_type) >> +{ >> + ASSERT(spin_is_locked(&xen_mpumap_lock)); >> + ASSERT(idx != INVALID_REGION_IDX); >> + >> + if ( MPUMAP_REGION_OVERLAP == region_found_type ) >> + { >> + printk(XENLOG_ERR "Cannot remove an overlapping region\n"); >> + return -EINVAL; >> + } >> + >> + if ( xen_mpumap[idx].refcount ) >> + { >> + xen_mpumap[idx].refcount -= 1; >> + return 0; >> + } >> + >> + if ( MPUMAP_REGION_FOUND == region_found_type ) >> + disable_mpu_region_from_index(idx); >> + else >> + { >> + printk(XENLOG_ERR "Cannot remove a partial region\n"); > Shouldn't this be moved above refcount checking? Do we expect this function to > be called with region_found_type being MPUMAP_REGION_INCLUSIVE? This function is expected to be given MPUMAP_REGION_INCLUSIVE and in doing so decrease refcount by 1. If however refcount is already 0, the region can only be freed by calling the entire region bounds. This message is moreso a debug error that our MPU API has been used in an incorrect way, it should not generally occur but I would prefer to keep it for sanity checking. > >> + return -EINVAL; >> + } >> + >> + return 0; >> +} >> + >> /* >> * Update the entry in the MPU memory region mapping table (xen_mpumap) for the >> * given memory range and flags, creating one if none exists. >> @@ -357,18 +393,7 @@ static int xen_mpumap_update_entry(paddr_t base, paddr_t limit, >> return -EINVAL; >> } >> >> - if ( xen_mpumap[idx].refcount == 0 ) >> - { >> - if ( MPUMAP_REGION_FOUND == rc ) >> - disable_mpu_region_from_index(idx); >> - else >> - { >> - printk("Cannot remove a partial region\n"); >> - return -EINVAL; >> - } >> - } >> - else >> - xen_mpumap[idx].refcount -= 1; >> + return xen_mpumap_free_entry(idx, rc); >> } >> >> return 0; >> @@ -418,6 +443,31 @@ int destroy_xen_mappings(unsigned long s, unsigned long e) >> return xen_mpumap_update(s, e, 0); >> } >> >> +int destroy_xen_mapping_containing(paddr_t s) >> +{ >> + int rc; >> + uint8_t idx; >> + >> + ASSERT(IS_ALIGNED(s, PAGE_SIZE)); >> + >> + spin_lock(&xen_mpumap_lock); >> + >> + rc = mpumap_contains_region(xen_mpumap, max_mpu_regions, s, s + PAGE_SIZE, >> + &idx); >> + if ( rc == MPUMAP_REGION_NOTFOUND ) >> + { >> + printk(XENLOG_ERR "Cannot remove entry that does not exist"); > Why do we split sanity checking between this and xen_mpumap_free_entry? > What are the possible region types that xen_mpumap_free_entry is expected to > work with? I thought that it should only be MPUMAP_REGION_FOUND. I will move the region checks to xen_mpumap_free_entry since we only want xen_mpumap_update_entry and xen_mpumap_free_entry to modify our refcount properties. These functions should then account for all potential values of MPUMAP_REGION_*. > > ~Michal Thanks, Harry Ramsey. From xen-devel-bounces@lists.xenproject.org Mon Jan 12 10:37:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 10:37:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1199983.1516001 (Exim 4.92) (envelope-from ) id 1vfFIe-0008Ut-7H; Mon, 12 Jan 2026 10:37:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1199983.1516001; Mon, 12 Jan 2026 10: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 1vfFIe-0008Um-45; Mon, 12 Jan 2026 10:37:28 +0000 Received: by outflank-mailman (input) for mailman id 1199983; Mon, 12 Jan 2026 10:37: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 1vfFIc-0008TO-Nb for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 10:37:26 +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 aea53b99-efa2-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 11:37:24 +0100 (CET) Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-432d2c7a8b9so2800242f8f.2 for ; Mon, 12 Jan 2026 02:37:24 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432dfa6dc4esm16111779f8f.23.2026.01.12.02.37.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 02:37:23 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: aea53b99-efa2-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768214244; x=1768819044; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Nsy5JRy52pNUjoI5qh5aqHNljieCFgusvqeG3TQZs4E=; b=aHGuIS0tz6E34lhnLNKdlliCNjNLXHHcCOgltSjpFC0t8qJGfbaa3f4iQ8ojiFDI9O SrTFfCg5y+YcNXz3jVNSa0OcrWYelya+41OW1fDYeXwEYybqOGvO25osY/fOuUKPkIL1 PYAKBvTZsbvkHZfRHKvxIm6dZAutjO2d+vGZJHH840JJUrmNBthj3OWO99XWgD0qTPLB CL9GnTyJDHyUdDj6KtCLDYGzHJ8lUdEuXf+4SSn2HTkUL7/N9wyTe8TC3Av2pvfmRReO Djgq9FXbKS21bX0IhDljPqWC1FdRsTA5TuAWDB41NwPl/CNL3cnW9Th6jcid6JFebgdN R0+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768214244; x=1768819044; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Nsy5JRy52pNUjoI5qh5aqHNljieCFgusvqeG3TQZs4E=; b=jEX9cD37u3KLbP1cem8kPGdZ4eewIkflvcZ0PjrDkvPdfVY6YotwgASsbJXNCdE/4I PEHO2g29ABE1up9OaGIHKAWqKy5hYoYdRKhZTS9hmfVbjbsNzs2mBN9JET2s9pkHZmOv JKHeh4ptQJwkgyG2d6/Mu3FdalrfcKBo2wLyiLrOi0aMpjjzDOI3+5FQAgqfLJe7Xlbh 3EnBy0DlhZ0mCsRDN7hgeZbUcao14OYzmpm7m1L4zgw7pdqwuR4Q6j4PyAOOOyx8EDdu JW/NbIuo0DeyzfwCsh2/JYOnauVMY2CQmp79McAkImG8E7swYCvvs2Sze+LbGRajYd6O 0O8g== X-Forwarded-Encrypted: i=1; AJvYcCUOWjoZlGbbXfIq5QmS/jY3NewRk0WfNqOT20MkzpDZOEnbYbC1z0173aq9lAjyg/Y8urnwQfKYqtk=@lists.xenproject.org X-Gm-Message-State: AOJu0YxO3bYmeDB4+094cPpT2noDklSIHhXv5LgXBZvP5Uc+Xyw6ef42 gNRKakITdK58BIWkV9A8d/l/Ys8t4SDLLh+QwefXDqtoiJGCnSryioUOIszG9gsIjA== X-Gm-Gg: AY/fxX66MBAtWiB7SflXHTbdG+HCAAMO1v4nNpsX0UxuS6QSOyCvNsQ2tW/zeCsTenb UMIEmwfS+ilpe+zFTtBwBIHeaVcv24CECBKXpPMzEILEFbI8/pRBP0YDvSyVBT/7gfmwW0578Ff C3IdKUVBb66hn20pAnWng8H6O7a2LEoSHhXIyDkJ2fNbl4v64M7jJ2ygcVYX7UMIuvON+1C3Gfh 8sBpdF9D2LNpdTs4Zh+08AFIaUZ08nDt8drA9ylKYrAdr0QOxNuhPNSPLtWYFr15ropOTTohHgV tUjAC8pPcU75CmE5SfkKEnITtoyVpoNbxYxh/RsbcHFohc5pmQWnBvthPkIoRwvLynlBj469kaE r0EUsNf0bQtG0dzFjzlzb6FWVKbTHv9CTI4MnkoFXzUZOFSJXPhzAzErmd58wZkoTe7CHl1oBj6 nFHCtfp6RrMqQrgioD/EUSlRoAfvJoB6TZDE9aHHRbCuW+DFlEBp4l1PA/0gq/gzfkcGlhWK4j0 w4= X-Google-Smtp-Source: AGHT+IH4pOuerbgRrBL4gD+bvtxu23H+Anm2q5brzBDifNpuxcOIcnmKbnLQVDH0Pjhhx6swzMj8+A== X-Received: by 2002:a05:6000:178f:b0:430:b100:f594 with SMTP id ffacd0b85a97d-432c379b6acmr21873107f8f.50.1768214243770; Mon, 12 Jan 2026 02:37:23 -0800 (PST) Message-ID: <9d65a2d6-12b5-481f-a4c3-47829815908d@suse.com> Date: Mon, 12 Jan 2026 11:37:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: KEEP Re: [PATCH 2/2] xen: Add CONFIG_GC_SECTIONS To: Jason Andryuk Cc: Victor Lira , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Grygorii Strashko , xen-devel@lists.xenproject.org, Andrew Cooper References: <20251209214728.278949-1-jason.andryuk@amd.com> <20251209214728.278949-3-jason.andryuk@amd.com> <43d30e02-f818-4cf2-98c9-4182a2f65f64@amd.com> <13a270cd-b0bd-4565-9158-0e1728aef84e@citrix.com> <7514a67c-d140-43b6-bed0-3467530a086d@suse.com> <83eedd0c-dcaf-4e28-ac0f-f4991f053350@suse.com> <1beace12-8364-4808-b817-7705f0dd9d79@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: <1beace12-8364-4808-b817-7705f0dd9d79@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 10.01.2026 00:32, Jason Andryuk wrote: > (trimmed the CC list down) > > On 2025-12-12 08:22, Jan Beulich wrote: >> On 12.12.2025 02:34, Jason Andryuk wrote: >>> The alternative is section groups? I'm trying that, and it kinda works >>> sometimes, but .attach_to_group fails when .init.text is involved. >>> >>> Here's an example that I think would work, I could make it to >>> --gc-sectrions: >>> group section [ 3] `.group' [.text.vpmu_do_msr] contains 5 sections: >>> [Index] Name >>> [ 43] .text.vpmu_do_msr >>> [ 44] .rela.text.vpmu_do_msr >>> [ 45] .altinstructions..text.vpmu_do_msr >>> [ 46] .rela.altinstructions..text.vpmu_do_msr >>> [ 47] .altinstr_replacement..text.vpmu_do_msr >>> >>> But I don't make it that far. Other files blow up with tons of: >>> {standard input}:9098: Warning: dwarf line number information for >>> .init.text ignored >>> and >>> {standard input}:50083: Error: leb128 operand is an undefined symbol: >>> .LVU4040 >>> >>> Line 9098 of apic.s is .loc below: >>> """ >>> .section .init.text > > Earlier in the file, there is > .section .init.text,"ax",@progbits > but the later .section .init.text entries don't have the extra string. > > tl;dr: If I add "ax",@progbits to all the .init.text entries, the file > assembles. > > I opened a bug here: https://sourceware.org/bugzilla/show_bug.cgi?id=33779 And I've replied there. I think gas is working correctly here. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 10:40:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 10:40:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1199994.1516010 (Exim 4.92) (envelope-from ) id 1vfFLR-0001fk-Iy; Mon, 12 Jan 2026 10:40:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1199994.1516010; Mon, 12 Jan 2026 10:40:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfFLR-0001fd-GO; Mon, 12 Jan 2026 10:40:21 +0000 Received: by outflank-mailman (input) for mailman id 1199994; Mon, 12 Jan 2026 10:40: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 1vfFLQ-0001fC-ER for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 10:40:20 +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 16d4ef99-efa3-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 11:40:19 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-47d3ffa5f33so28027705e9.2 for ; Mon, 12 Jan 2026 02:40:19 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0860f5sm37789313f8f.0.2026.01.12.02.40.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jan 2026 02:40:17 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 16d4ef99-efa3-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1768214418; x=1768819218; 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=LykZeEOPrv64xvtZjRuGWxA+y3dRZD2O4sxtxa360vI=; b=Q48rjkl8+LB5QEnKtPWEMEgM72KZzoNFkljYe5M28cZvDofZBeHl3RABWwfGNj8stO P+aGxDpIvHDM1h3mXz9fn8e9BQWrPOZzj4d4YOV1bKXg5sP6Gn1cKezvgV/KH3lYykZ4 sAIypLTlAhxWmtSVQ0cT/yrK2BqMWWH0ThZW4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768214418; x=1768819218; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=LykZeEOPrv64xvtZjRuGWxA+y3dRZD2O4sxtxa360vI=; b=K95RBm9X9NOniYmyGdl2f5z10eUV+Z01JtNG03YoB1cJ7TVTRznQxpRsvwLtIfZGCE ka1AJt7puZGEDT6DwtioeqOkF3CwEm2N0pNi6+VZHtnXyjBOA4Y6jwRmj07C1R8hdCaO WIm3LqAmQY6UEoejhgbboqpd/7La24H4xWbmdefNw+89mavtOU72SFgX4lSLgseMDnSk /QjGBy5ygPUjAIUkX1HK7jH+JxqqftSOMnVUNbkTajThAOAZBFeGsWE3my3hDvjuVNHk sb11DttplEClubjr5OWi2bsW03Am8Go8aBbr2FIOXuhP4K4OoUNI/thJcNRw48Qx7PPX FGng== X-Gm-Message-State: AOJu0YyIvPeb3Pvd5kLnJGHs63ZkG/JkhT11nMy9D7JVWH6Wlqb5U6zH /mZkXG83nfIU5JVyNHgx6nTy5TjpeWF3oNRN92XvbNIYW7Rj5d00YKi6ZUzztaRvkmWKIrQccId ZNfDh X-Gm-Gg: AY/fxX4uP3VQz6kz2eH4QBUpwHj5M0Zy15RyrxdAfOPhwcHVGcwDgBMbAgAKgZb3Nra OaU/JRl0W1KaWzzhNxPjIO3p5MXf9CuovTUGeNrOTaY00/UsSJEL4MlRcRaPTwrrH570RSN+hTb gM/X+oYygcQ2aF/zXLAEm9/gyMauK8o9vuZN7dJOvqAnylFECBKzTPk51GNY3PoI0iUwaknrir7 nJ41BuX1BPB8fZRYubvJcFPLgggw2hV3lu4JRE6+3FuR+g+D/Om+H+/WLcKTMFKRtSZLCeI+DoD sP8UIMvpm0HUjrW5Cchm5sEqywkDds1Y9ZN8wqae39gO7pdjInCFBgJrR7oXLy/tMHi/EzC2Qn5 Pk6uG0YXc1+ZiiEefREBEr2rbSakhQrJOGr5zrzeFWFVPQmKcKPhl6rfVn64YXpMif83X7w17rm UwNgNe/IiiI94NFOgJh7Vx9QjxmxX542Wg0xDma6g3zI2EnyJz2teEu0IYzY2AjA== X-Google-Smtp-Source: AGHT+IHytOuQy5U0zHra82QWExPtPdLByvnFvDNZZy1tOjBUrCvc3b21W1UE4YZxhwIX2sWLH/mcVg== X-Received: by 2002:a5d:64e3:0:b0:42b:3dfb:644c with SMTP id ffacd0b85a97d-432c3628287mr20325272f8f.10.1768214418204; Mon, 12 Jan 2026 02:40:18 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH] xen/nodemask: Remove _unused_nodemask_arg_ Date: Mon, 12 Jan 2026 10:40:15 +0000 Message-Id: <20260112104015.1001907-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This only exists to have it's type taken, despite there being a perfectly good concrete type to use. 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 --- xen/include/xen/nodemask.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/xen/include/xen/nodemask.h b/xen/include/xen/nodemask.h index 1dd6c7458e77..c9b18c47aace 100644 --- a/xen/include/xen/nodemask.h +++ b/xen/include/xen/nodemask.h @@ -67,8 +67,6 @@ typedef struct { DECLARE_BITMAP(bits, MAX_NUMNODES); } nodemask_t; #define nodemask_bits(src) ((src)->bits) -extern nodemask_t _unused_nodemask_arg_; - #define node_set(node, dst) __node_set((node), &(dst)) static inline void __node_set(int node, volatile nodemask_t *dstp) { @@ -215,7 +213,7 @@ static inline int __last_node(const nodemask_t *srcp, int nbits) #define nodemask_of_node(node) \ ({ \ - typeof(_unused_nodemask_arg_) m; \ + nodemask_t m; \ if (sizeof(m) == sizeof(unsigned long)) { \ m.bits[0] = 1UL<<(node); \ } else { \ -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 12 10:42:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 10:42:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200002.1516021 (Exim 4.92) (envelope-from ) id 1vfFNG-0002BA-Tw; Mon, 12 Jan 2026 10:42:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200002.1516021; Mon, 12 Jan 2026 10: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 1vfFNG-0002B3-QN; Mon, 12 Jan 2026 10:42:14 +0000 Received: by outflank-mailman (input) for mailman id 1200002; Mon, 12 Jan 2026 10:42:14 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfFNG-0002Av-3J for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 10:42:14 +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 59b7c7f0-efa3-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 11:42:11 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-432d2c96215so3143747f8f.3 for ; Mon, 12 Jan 2026 02:42:11 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ff0b2sm37875883f8f.42.2026.01.12.02.42.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 02:42:10 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 59b7c7f0-efa3-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768214531; x=1768819331; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=mQxHxdZKA8MI9tF3OkyjB3iEm/ry45hM4hkXuxq/Dfw=; b=CS1vKeFhMxKazwz8MNOXR/ICcEQ7MeP7z17waY7FhmxKaiCpUQ+Et8ba0MMgES98lP lwb6r3rACgXeNMbkFT8uVhApajOX9+wVEb9sIKt832wBTqskVRTfcXHQL/s464SeZqBw faaOsWDBNGweVghbV0mvNztgGzwkk6odBRoBzibAJZrZieCQYCziq+/1bj0yk7FpoCvx K24MZYNEolXYDktiPuHc2ZXkMlunex5TTJgRhOoQm1slFqaAgUUNnUoHtAppXst6mK/a ecCJ+hTQoOw6VHVSMyEApHE+iiC68xQuA16Z9KDsgmIfa7V+6efn1vcNK34UDc2IX3G2 wyYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768214531; x=1768819331; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mQxHxdZKA8MI9tF3OkyjB3iEm/ry45hM4hkXuxq/Dfw=; b=GrfwJt3eCG4gvSdhAtfNmqPymrQu1CYWgYNC0ZI8O/6PlXwH0eJkWUbNCo0wOli1ZD em4QM4+AYEZ8AiljicqsEGgg+6skJakjxjG02+9hkIp9CXLbIJ7bZ35EfEFXG8Sibpab XCuC/hyuh+oe9hlpiu2kITg1m65sstv0kzXsuYZxzpe30rcpRnPyQ4LYbA+95F7tz4Yg RNAD91/JDIhdLm5tgDatiFlUKteXaarGoC3O1LPY4lf4rFpUZnWJAVR3f8Q+0WAmY5xh 8Hu+YOrM+mddLmO0zjdrrGFbKKvb+7hyg9hyqTmhudYUCmR1zhIt6ryofVI+Kknr02+w nvUA== X-Forwarded-Encrypted: i=1; AJvYcCU3cmWtCDgIoXOyjvsL9Wo1cRYA0nhqQH7hEAkPMuYD4BsMyhOxnzvi55xX4SQRoh7PNcIiQ2Xs/4s=@lists.xenproject.org X-Gm-Message-State: AOJu0YxQ7ZMvJO1YhwoJx4E1x2lF6zhTEwX/2ZKNEJI5aKdLl4Qq/b+0 4/v2tc6V28gICyGCr4YUVySiq+9GJ6638J1I86dREWyKZu502FLbqCbW2u9+vESPWA== X-Gm-Gg: AY/fxX6RBV56w+u4lKRoh/r+9kgyWbLK0hUwQKbbGnEfMpL25vABFAOb8ef+ZqoiSFN g3CjiKtT5V6HOHfb36IDfwYw1A1HUCYuM9gaI7mq/UTHDCi0IsWO4frD/I1A/+Cb6ZmUDYw0Zt+ qUbU6juX5Jhx5KKTrNvRMNrerw8gWJsNOn5G0fcOmebK3LyzdQcMuH3ea/3hJmXhUhdnBTCdB/L hnaqA/eFfDlLaC+qleKeQ5Fl2sB4qAi7FyD20j2eAZL0FALXNYHEmy6xn2FktMe+fE1UQO3Gdr9 TEnOvyjG+wlnpd22OHGucDSf7IBPWwYQCNW/E9anrguoQ6CAx8nKVHg33ouBCOVPoYglzxkNVsv Bluop+7bNaOwy/iCra5LqavuA0/IPvcia06VXe5JpFfF1EOPWpAWqjMuYyhmyXItEGawK0YWG3/ Vri9E2DOgJgYgfELwFEQ5oUnnXghJSfs3idyiUKX66nQOYUNbF1Jj5jHCgd3AZIjQlmIrqn2hQU kg= X-Google-Smtp-Source: AGHT+IHYytF6QP50y8X4gpEhZi7iuv6sdsPI/dNHz7zoSldkUhSn/PjSTDb6HtVV7zX/Unk03TJJqw== X-Received: by 2002:a5d:5f86:0:b0:42b:39ee:2858 with SMTP id ffacd0b85a97d-432c37d2ebfmr22651611f8f.42.1768214530769; Mon, 12 Jan 2026 02:42:10 -0800 (PST) Message-ID: <9fa77da5-ca63-4c5f-9b6d-1bc7305c5b8e@suse.com> Date: Mon, 12 Jan 2026 11:42:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 02/15] xen/riscv: implement arch_vcpu_{create,destroy}() 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: <2e7ab738-6b5d-4ac4-a46b-1eef1cd09fb1@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.01.2026 11:19, Oleksii Kurochko wrote: > On 1/6/26 4:56 PM, Jan Beulich wrote: >> (some or even all of the comments may also apply to present Arm code) >> >> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>> + v->arch.cpu_info = (struct cpu_info *)(v->arch.stack >>> + + STACK_SIZE >>> + - sizeof(struct cpu_info)); >> Why the cast? > > Just for readability, from compiler point of view it could be just dropped. Sorry, for me readability suffers from the cast and the then necessary parentheses. Plus I've been keeping to tell you that casts can be dangerous, and hence they would better only ever be used when really unavoidable. >>> --- a/xen/arch/riscv/include/asm/current.h >>> +++ b/xen/arch/riscv/include/asm/current.h >>> @@ -21,6 +21,12 @@ struct pcpu_info { >>> /* tp points to one of these */ >>> extern struct pcpu_info pcpu_info[NR_CPUS]; >>> >>> +/* Per-VCPU state that lives at the top of the stack */ >>> +struct cpu_info { >>> + /* This should be the first member. */ >>> + struct cpu_user_regs guest_cpu_user_regs; >>> +}; >> You may want to enforce what the comment says by way of a BUILD_BUG_ON(). > > Makes sense, I will add: > BUILD_BUG_ON(offsetof(struct cpu_info, guest_cpu_user_regs) != 0); > in|arch_vcpu_create()|, somewhere around the initialization of|v->arch.cpu_info = ... . |I noticed that there is no|BUILD_BUG_ON()| variant that can be used outside > of a function, or does such a variant exist and I’m just missing it? Or there > is no such sense at all for such variant? There's none, correct. hence why in a few places we have build_assertions() functions. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 10:42:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 10:42:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200013.1516031 (Exim 4.92) (envelope-from ) id 1vfFNr-0002iK-8i; Mon, 12 Jan 2026 10:42:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200013.1516031; Mon, 12 Jan 2026 10: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 1vfFNr-0002iD-5E; Mon, 12 Jan 2026 10:42:51 +0000 Received: by outflank-mailman (input) for mailman id 1200013; Mon, 12 Jan 2026 10:42: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 1vfFNp-0002b6-RX for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 10:42:49 +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 6b37e30e-efa3-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 11:42:41 +0100 (CET) Received: from SN6PR2101CA0008.namprd21.prod.outlook.com (2603:10b6:805:106::18) by IA1PR12MB8467.namprd12.prod.outlook.com (2603:10b6:208:448::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Mon, 12 Jan 2026 10:42:37 +0000 Received: from SN1PEPF000397AE.namprd05.prod.outlook.com (2603:10b6:805:106:cafe::84) by SN6PR2101CA0008.outlook.office365.com (2603:10b6:805:106::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.1 via Frontend Transport; Mon, 12 Jan 2026 10:42:32 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by SN1PEPF000397AE.mail.protection.outlook.com (10.167.248.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Mon, 12 Jan 2026 10:42:36 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 12 Jan 2026 04:42:35 -0600 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 12 Jan 2026 02:42:35 -0800 Received: from XIR-MICHALO-L1.xilinx.com (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Mon, 12 Jan 2026 04:42:34 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6b37e30e-efa3-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZQzdDNjHn4M2yxZo4TtBWnH/mLROr1exfxG4prZOL5AHEdXg/sD0DSXo3V1k2pzJnJbV1lIDnVovfSyp84x0+1Afn8xxpMrjCU276432kmxdRajV5HP1imPJuosyIbBxpMsA0O2q2Gx+lC2Szasao+HwzWrl0hXIAVlT04x78KaqDX8plS60KTdGEnB7GeCJaYIlo4Zc/kcsN3Ht8F8EjV9Jjt4TQsrMSrrvRZG2vLtk5Uyv4gXnsBLOtqXID27YYaHzPVH6kQO4aYKNT9kBPTqmYPjYH/hVUwMpJc3yejVJdooA+PnlTwRkxc+J1SbPgAExZpMlLaNWMTN3fUyZZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=K8Z8tMEL18pzb7Go51wP5wIZcdCu9OhODICjfie3kbA=; b=BjacwQikCj+5gv97HMeg9TlvmiFB7UbmxfhTwcvKZhhvNGWaS1rR/LaGXi3O5mAKRl/gHdrooJigwJy9o5UVE5cr6I60Q32JIT/zchs6ogjBVIqkkC/rDamJzBlP9Lt5UJNIl6COBq3U6URfGE7K+1FbRZKj5PLx4Ls10qhadlmmivTdw8vQM3ddKZclcI0I0QbpYmLDbxFvhuTFzkRofxWfbt0gGjl/K5ldJH5S2x3hZ/yLV9D4Bj546r8CJtAEv2fq9xd4QxJ4Ho4paqb3P0AyNvUsWbC3T6t5eLP4gUa1xOIwVz0tEgNjcKCxnwVVvaBOuAqFqS1ua4AElXUXQw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K8Z8tMEL18pzb7Go51wP5wIZcdCu9OhODICjfie3kbA=; b=dXJL4clPVOUO8DjOXl/XZvgGuH7kroFEn9DcFS05BWiTsz5YeJWgYG7eccT4KHsQoDvBHcBcBRdVgjPZ50sc3KgLEQRgnyUGIuLUacZ4dhTH5+alSLS7kvO74hCofpZmL+t4N5DjXojRsz7DDgxjdVyVaQNGpKaAQ5iVYzXm22Y= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C From: Michal Orzel To: CC: Michal Orzel , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Subject: [PATCH] xen/arm: Print correct domid in allocate_memory_11 Date: Mon, 12 Jan 2026 11:42:32 +0100 Message-ID: <20260112104233.86482-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: SN1PEPF000397AE:EE_|IA1PR12MB8467:EE_ X-MS-Office365-Filtering-Correlation-Id: 142285ae-a067-42eb-b4dc-08de51c74cb4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?UzLkXOYcAcAY92GP10Bg/F+nImhmzLlhHUJe+alnVBVo+A4byhA07siHWrC1?= =?us-ascii?Q?rNC+6I8vzJ1GxRJQaCIPOQ/w3Zyy5007wfZqwLWkdITxydaeEdzkiLIlpiFR?= =?us-ascii?Q?omCumx5CbUmG+zUuAkgr+Q15HVi5K7kzLlfBzUyC/ZSTmCOKWYinEPhnkiPQ?= =?us-ascii?Q?Gaq388ZniUiq+MWbyEqS+bYC7G9UjpHfZbM5/UMz3HoGn7392r8f11QZ80P2?= =?us-ascii?Q?X7HeYixoDxmDKNhOab81NwHqGlBtwp/d0KKqJSki73H/KouoYg0jLh3BmUzf?= =?us-ascii?Q?l6yCZW4Jne6pQtX4/C0A5RzS75cJy1QmS6ABMn3I9G8U3QdrY9jeqevQVUeo?= =?us-ascii?Q?czRyHtN8kPUsJ1zHRscuzGtC2HdXQG9yNIVvGsFlEHhlTWuPPQTo3/bE58cN?= =?us-ascii?Q?9SCy/VRGPiU1Po7EHqpFU7zhHI4Zdip8Pj2tlgzuiqXqQptJRfTi0CcSWoHU?= =?us-ascii?Q?+Cszry9GLb2m399rYhYcllDwCFG5+XIZQyMAlnGE0jO2IxNec0Ow65RtTXCl?= =?us-ascii?Q?g0EBNVA+dr+UTvhfksKFrlhv9LiMk8FMYh1+AHXCn09WT+n6CuNUGXom8J8w?= =?us-ascii?Q?4dKhnHPNdbCUeIHNPWiRULyJglogA2S49qa+5+NbA95tbJ1xrug5B0kdTh9z?= =?us-ascii?Q?JddtJIIXL8cJJ0OVsTiR7GcH9JV17qv6lngubY6w4ijbu9pDlQAnKk+xn14h?= =?us-ascii?Q?ssiZAW+6FkY12wLuNZHZBGrMaNY/XjjeCs6UPlQX/pBITNpGRTUHOr4220/6?= =?us-ascii?Q?xS+w1iAsshH8OAlZIVk22YHGo2LKjawxaazTURGkcNW0mtdJRAxNO24vduW2?= =?us-ascii?Q?Oc2T0WrM6+0n5gRj+M5AW+eVBWENiUwTDppdvRxhBHYppzPAQbgC4XiyyTgc?= =?us-ascii?Q?NO3D21PqfcHwF8CvDzHQ6UM6MUrT5zSLK/yBfc2jSnegbXOkPimJFkAO/+Un?= =?us-ascii?Q?UjHtu6HP5PtoI0wfEl3UxgE+9jqiH6f5l0aVPXvvJuZxFhJijApianHLrTFc?= =?us-ascii?Q?NMIV1TJujWFG35SZWTk9VaR8k/pxS4hvhwuc71y9ptoNqXjNf51J2XqyhUeF?= =?us-ascii?Q?ZqHxU6hWCFc/YBVk0JNeMq62RfST9lqMsWxQoyg0LfiD53ZFuLHDmLtm7F2p?= =?us-ascii?Q?JpM7xOEQPwnIrJIdzNXAx+apLhsDp+1sHESZulhchz7+04kBm7L6m6TPtdPn?= =?us-ascii?Q?rpD+Oeuh1kSlUwRE1rp9/Lviy3mchJMmfKhsnLBIyeimxoLIX0mDUC7yss/N?= =?us-ascii?Q?UJ2dsTlYO78gXiaAZ6zo0V0SIjikszqKEhUPJW5CDUiMFBUpmUE/8xF/X1/7?= =?us-ascii?Q?YqzT7U7ohkiVhzjys2ZzRHoNOZe01kRqLBRCVFLrFMXvk+cVW26mrG+5D2bP?= =?us-ascii?Q?+tYu7KqmWOrf/AEGXHmOpP0eyGXezBEePeiDzPrvrrBa/qjAfHuCtGjw9rV7?= =?us-ascii?Q?w5oKEYCF4I6yx7dSkR7TuDpWXLThZWwii3w/2ulMraOPfOcWRIr1DZ7Kqa5K?= =?us-ascii?Q?+E6/CP5Mq8OTZqNs9rioOIiUCOF4dWZnzOXhUv0xL7+VlLJcyS3fEst4EcxJ?= =?us-ascii?Q?IV2cPf386RwmRia/Qg8=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2026 10:42:36.0026 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 142285ae-a067-42eb-b4dc-08de51c74cb4 X-MS-Exchange-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: SN1PEPF000397AE.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8467 allocate_memory_11() can be called for dom0 and direct-mapped hwdom domU. In the latter scenario, a log message would still mention dom0 instead of the correct domid. Fixes: 52cb53f1816a ("xen/arm: dom0less hwdom construction") Signed-off-by: Michal Orzel --- xen/arch/arm/domain_build.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 986a456f171b..e8795745ddc7 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -296,9 +296,9 @@ static void __init allocate_memory_11(struct domain *d, */ BUG_ON(!is_domain_direct_mapped(d)); - printk("Allocating 1:1 mappings totalling %ldMB for dom0:\n", + printk("Allocating 1:1 mappings totalling %ldMB for %pd:\n", /* Don't want format this as PRIpaddr (16 digit hex) */ - (unsigned long)(kinfo->unassigned_mem >> 20)); + (unsigned long)(kinfo->unassigned_mem >> 20), d); mem->nr_banks = 0; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Jan 12 10:47:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 10:47:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200028.1516040 (Exim 4.92) (envelope-from ) id 1vfFS0-0003Ki-NZ; Mon, 12 Jan 2026 10:47:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200028.1516040; Mon, 12 Jan 2026 10:47:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfFS0-0003Kb-Kq; Mon, 12 Jan 2026 10:47:08 +0000 Received: by outflank-mailman (input) for mailman id 1200028; Mon, 12 Jan 2026 10:47:07 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfFRz-0003KV-I0 for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 10:47: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 09847b0c-efa4-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 11:47:06 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-42fb2314f52so3243523f8f.0 for ; Mon, 12 Jan 2026 02:47:06 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0e16f4sm38858048f8f.11.2026.01.12.02.47.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 02:47:05 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 09847b0c-efa4-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768214826; x=1768819626; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=hSgzgogByJA0bhNgue5KWtK+QgUZVM56BoRqgl+g2ng=; b=NcypBjpfKm58R3jJZTHP7UDWfI7HZvMxOaY2FQMP3JyEDaqkPMV1jPoTLOQzQ42vcB kBifM+G5X3FJ4MypS0WgO4qjdwPsRawnY0D1Go4P7K8Wh9Gy5yXuEiZY1T//DJAHDthS Bo5zg07CU65SN2vg8DtmG3z/MqUzh+siqJE7ius/qez1cScIafpKQZBIoStJuITFkeTA XouMVic1mOCt0/kFdhl12hH3ShpW8HEA/K3wVQNWKZ9w/w3P0Mn5nWIttW3fzVw/u+Z2 NrdXLII3qLbKrsPzoKLATCQGb9FFfn4tjJycOyGneExLsfAWKLajHtP/UNP2Ndli34E0 XEiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768214826; x=1768819626; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hSgzgogByJA0bhNgue5KWtK+QgUZVM56BoRqgl+g2ng=; b=J3yxCAHQ8lYmeYtc58AXrUR7D24eTEVmtpULuWDyeUIczOyHpsxaPvlrgrDB09Bwz3 aYTz1rfoCujVCzb5cos/XuStHfAD7Ltx8EFXJKFVR+HdzL4A7YkiKgIoNHbO6Swqf4nS yPRjwjvlfF3Pif5WU1Ae4ZsLix5gx2XEX9ATjPlfrNgE/Z8XgIxHLCn564T2XzyqaeCM lkwVpLC105y/XvlzUNyNJWVlhOaZ+eKI5aK1VgBeB/Dy5b/WLcneHE/NPKDwYZDvr3fA 2mLWZeOc9GZFCdqOSrS4g/OBo+yp9w6qBkrO9IJnm6YMGkMuzWdO9t5abyfKneAIyAkp kHtw== X-Forwarded-Encrypted: i=1; AJvYcCUmXH723TXWGw6nsvsFL7XyIP/tJ1+uzZSsOS2QgBrG2EmpfzdsSH8wPwE902gVSYNrQcZQ3Sm8Jl0=@lists.xenproject.org X-Gm-Message-State: AOJu0YypMILnpawRin0xfrU7lRmJn4wFiNi8xBsl3a8sJuubMl2N9qtA OsKcRgeXo7gmugpxwgmE4M73VWeBBmBvPzfazP7JDyYnHUsP+6SlsJKJgLgSinZ9Kw== X-Gm-Gg: AY/fxX7X/1NW32fx5HIZOuPOc8o8NrzTk8KOSYHk8+wdn6lfS5tHpg/0+Dn3q0+OuIW 0bmseXh6dOToB7+mplQ+v0X2A+3X2MK1j0/kUFfn6xS1zjSVNhHQxZJjYuvgBd7fGrhTxwSWxFI JK2OgcQeqcyOlO858zCupRBp9BaKgBgCUC+O30iMY49659W4j2NwZ0BS6VqdH1EhVdfOEp7Vx3z Qwmbq5AUtEU9/Ye2VGb75rMp51SvdhBflnXPHfsxvUEhGR3/HKarIDxRUegDawMTPcP1Ig/xKzc M15uc25tYKQG5/GHaJkHPFWy4Mwao2yojhjJk19bT2p+im1j6XujJzUcB7HCWmT+AgQpKz6P0N5 9e/nbbBWTlH1MIetkh/8RD+mmFZ0scZmZf0N2aKFMIbrSGYtCE9jwUsp/oY2A8ybsf7fd5+y3gY b5wAwUV+3+o9yTh4fJ4qEB0VMIZAW9contxyaYei9aNX6TjbNThl4QNNbXzSsZq8YMojJasxd6N Lc= X-Google-Smtp-Source: AGHT+IHtmF67vVUWTm1s73XX0DZQ5BH0QcGols75jR7Cd4NJiGJIVsYT2I4KwpTi6f3xN8LaQ4iXIw== X-Received: by 2002:a05:6000:4287:b0:432:851d:35ef with SMTP id ffacd0b85a97d-432c37a3b62mr23488201f8f.42.1768214825738; Mon, 12 Jan 2026 02:47:05 -0800 (PST) Message-ID: <3b0d3397-cffd-4017-89da-6850101d5f9a@suse.com> Date: Mon, 12 Jan 2026 11:47:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/nodemask: Remove _unused_nodemask_arg_ To: Andrew Cooper Cc: Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Xen-devel References: <20260112104015.1001907-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: <20260112104015.1001907-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12.01.2026 11:40, Andrew Cooper wrote: > This only exists to have it's type taken, despite there being a perfectly good > concrete type to use. > > No functional change. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich > --- a/xen/include/xen/nodemask.h > +++ b/xen/include/xen/nodemask.h > @@ -67,8 +67,6 @@ typedef struct { DECLARE_BITMAP(bits, MAX_NUMNODES); } nodemask_t; > > #define nodemask_bits(src) ((src)->bits) > > -extern nodemask_t _unused_nodemask_arg_; > - > #define node_set(node, dst) __node_set((node), &(dst)) > static inline void __node_set(int node, volatile nodemask_t *dstp) > { > @@ -215,7 +213,7 @@ static inline int __last_node(const nodemask_t *srcp, int nbits) > > #define nodemask_of_node(node) \ > ({ \ > - typeof(_unused_nodemask_arg_) m; \ > + nodemask_t m; \ > if (sizeof(m) == sizeof(unsigned long)) { \ > m.bits[0] = 1UL<<(node); \ > } else { \ Hard to see why Linux would have introduced that either. (It still has it, btw.) Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 10:48:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 10:48:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200036.1516052 (Exim 4.92) (envelope-from ) id 1vfFTO-00045b-2I; Mon, 12 Jan 2026 10:48:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200036.1516052; Mon, 12 Jan 2026 10:48:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfFTN-00045U-Uh; Mon, 12 Jan 2026 10:48:33 +0000 Received: by outflank-mailman (input) for mailman id 1200036; Mon, 12 Jan 2026 10:48: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 1vfFTM-00045G-AB for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 10:48:32 +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 3c0b1412-efa4-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 11:48:31 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 734B8336D7; Mon, 12 Jan 2026 10:48: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 53E6C3EA63; Mon, 12 Jan 2026 10:48: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 knaNEn7RZGn/CgAAD6G6ig (envelope-from ); Mon, 12 Jan 2026 10:48:30 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3c0b1412-efa4-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1768214910; 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=RKzCs3EHfscXaf27uIc/6u29nG95jbTHMErvKP3MT5Q=; b=qPeo3UuRHWvz5kAYrbnCNRAfq9cB9P0k6VB4KW7BIXunBYaW1s2rn1iynrAoNmamoMC3Gb GSx5FqPVbg76s7/kcJJ8QnePps69/dXImD2W/ktXhK7OvxpMFNWvgrpcg7Iux/wKf/m2GZ yWN+mmy4poMB5bco2N3yBbdKZB0emCk= Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=qPeo3UuR DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1768214910; 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=RKzCs3EHfscXaf27uIc/6u29nG95jbTHMErvKP3MT5Q=; b=qPeo3UuRHWvz5kAYrbnCNRAfq9cB9P0k6VB4KW7BIXunBYaW1s2rn1iynrAoNmamoMC3Gb GSx5FqPVbg76s7/kcJJ8QnePps69/dXImD2W/ktXhK7OvxpMFNWvgrpcg7Iux/wKf/m2GZ yWN+mmy4poMB5bco2N3yBbdKZB0emCk= Message-ID: <20e1bbdf-da94-48ed-84d0-7050436c3b6e@suse.com> Date: Mon, 12 Jan 2026 11:48:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen: introduce xen_console_io option To: Stefano Stabellini Cc: oleksandr_tyshchenko@epam.com, 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="------------PGQlewguDXdt21TBRvFJvcjw" X-Spam-Score: -5.41 X-Spamd-Result: default: False [-5.41 / 50.00]; BAYES_HAM(-3.00)[100.00%]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_BASE64_TEXT_BOGUS(1.00)[]; 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]; FUZZY_RATELIMITED(0.00)[rspamd.com]; ARC_NA(0.00)[]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; 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)[]; HAS_ATTACHMENT(0.00)[]; DKIM_TRACE(0.00)[suse.com:+]; 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-Level: X-Rspamd-Action: no action X-Rspamd-Queue-Id: 734B8336D7 X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Spam-Flag: NO This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------PGQlewguDXdt21TBRvFJvcjw Content-Type: multipart/mixed; boundary="------------9wlGni05LTNQe0IgfptKbKsi"; protected-headers="v1" From: Juergen Gross To: Stefano Stabellini Cc: oleksandr_tyshchenko@epam.com, xen-devel@lists.xenproject.org Message-ID: <20e1bbdf-da94-48ed-84d0-7050436c3b6e@suse.com> Subject: Re: [PATCH] xen: introduce xen_console_io option References: In-Reply-To: --------------9wlGni05LTNQe0IgfptKbKsi Content-Type: multipart/mixed; boundary="------------oja8Yxxh93BJdDnSK4Gr4k6e" --------------oja8Yxxh93BJdDnSK4Gr4k6e Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTAuMDEuMjYgMDA6MTgsIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4gWGVuIGNh biBzdXBwb3J0IGNvbnNvbGVfaW8gaHlwZXJjYWxscyBmb3IgYW55IGRvbWFpbnMsIG5vdCBq dXN0IGRvbTAsDQo+IGRlcGVuZGluZyBvbiBERUJVRyBhbmQgWFNNIHBvbGljaWVzLiBUaGVz ZSBoeXBlcmNhbGxzIGNhbiBiZSB2ZXJ5IHVzZWZ1bA0KPiBmb3IgZGV2ZWxvcG1lbnQgYW5k IGRlYnVnZ2luZy4NCj4gDQo+IEludHJvZHVjZSBhIGtlcm5lbCBjb21tYW5kIGxpbmUgb3B0 aW9uIHhlbl9jb25zb2xlX2lvIHRvIGVuYWJsZSB0aGUNCj4gdXNhZ2Ugb2YgY29uc29sZV9p byBoeXBlcmNhbGxzIGZvciBhbnkgZG9tYWluIHVwb24gcmVxdWVzdC4gV2hlbg0KPiB4ZW5f Y29uc29sZV9pbyBpcyBub3Qgc3BlY2lmaWVkLCB0aGUgY3VycmVudCBiZWhhdmlvciBpcyBy ZXRhaW5lZC4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IFN0ZWZhbm8gU3RhYmVsbGluaSA8c3Rl ZmFuby5zdGFiZWxsaW5pQGFtZC5jb20+DQo+IC0tLQ0KPiAgIC4uLi9hZG1pbi1ndWlkZS9r ZXJuZWwtcGFyYW1ldGVycy50eHQgICAgICAgICB8ICA1ICsrKw0KPiAgIGRyaXZlcnMvdHR5 L2h2Yy9odmNfeGVuLmMgICAgICAgICAgICAgICAgICAgICB8IDMzICsrKysrKysrKysrKysr KystLS0NCj4gICAyIGZpbGVzIGNoYW5nZWQsIDM0IGluc2VydGlvbnMoKyksIDQgZGVsZXRp b25zKC0pDQo+IA0KPiBkaWZmIC0tZ2l0IGEvRG9jdW1lbnRhdGlvbi9hZG1pbi1ndWlkZS9r ZXJuZWwtcGFyYW1ldGVycy50eHQgYi9Eb2N1bWVudGF0aW9uL2FkbWluLWd1aWRlL2tlcm5l bC1wYXJhbWV0ZXJzLnR4dA0KPiBpbmRleCBlODg1MDVlOTQ1ZDUyLi45NTNkM2Y1OTdmMDA3 IDEwMDY0NA0KPiAtLS0gYS9Eb2N1bWVudGF0aW9uL2FkbWluLWd1aWRlL2tlcm5lbC1wYXJh bWV0ZXJzLnR4dA0KPiArKysgYi9Eb2N1bWVudGF0aW9uL2FkbWluLWd1aWRlL2tlcm5lbC1w YXJhbWV0ZXJzLnR4dA0KPiBAQCAtNzYyMCw2ICs3NjIwLDExIEBADQo+ICAgCQkJc2F2ZS9y ZXN0b3JlL21pZ3JhdGlvbiBtdXN0IGJlIGVuYWJsZWQgdG8gaGFuZGxlIGxhcmdlcg0KPiAg IAkJCWRvbWFpbnMuDQo+ICAgDQo+ICsJeGVuX2NvbnNvbGVfaW8JW1hFTixFQVJMWV0NCj4g KwkJCUJvb2xlYW4gb3B0aW9uIHRvIGVuYWJsZS9kaXNhYmxlIHRoZSB1c2FnZSBvZiB0aGUg WGVuDQo+ICsJCQljb25zb2xlX2lvIGh5cGVyY2FsbHMgdG8gcmVhZCBhbmQgd3JpdGUgdG8g dGhlIGNvbnNvbGUuDQo+ICsJCQlNb3N0bHkgdXNlZnVsIGZvciBkZWJ1Z2dpbmcgYW5kIGRl dmVsb3BtZW50Lg0KPiArDQo+ICAgCXhlbl9lbXVsX3VucGx1Zz0JCVtIVyxYODYsWEVOLEVB UkxZXQ0KPiAgIAkJCVVucGx1ZyBYZW4gZW11bGF0ZWQgZGV2aWNlcw0KPiAgIAkJCUZvcm1h dDogW3VucGx1ZzAsXVt1bnBsdWcxXQ0KPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy90dHkvaHZj L2h2Y194ZW4uYyBiL2RyaXZlcnMvdHR5L2h2Yy9odmNfeGVuLmMNCj4gaW5kZXggMzg4YTcx YWZkNmVmZS4uMjk5YjA4YzkwYmFiMSAxMDA2NDQNCj4gLS0tIGEvZHJpdmVycy90dHkvaHZj L2h2Y194ZW4uYw0KPiArKysgYi9kcml2ZXJzL3R0eS9odmMvaHZjX3hlbi5jDQo+IEBAIC01 MSw2ICs1MSwyOCBAQCBzdGF0aWMgREVGSU5FX1NQSU5MT0NLKHhlbmNvbnNfbG9jayk7DQo+ ICAgDQo+ICAgLyogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICovDQo+ICAgDQo+ICtzdGF0aWMgYm9vbCB4ZW5f Y29uc29sZV9pbyA9IGZhbHNlOw0KPiArc3RhdGljIGludCBfX2luaXRkYXRhIG9wdF9jb25z b2xlX2lvID0gLTE7DQo+ICsNCj4gK3N0YXRpYyBpbnQgX19pbml0IHBhcnNlX3hlbl9jb25z b2xlX2lvKGNoYXIgKmFyZykNCj4gK3sNCj4gKwlpZiAoIWFyZykNCj4gKwkJcmV0dXJuIC1F SU5WQUw7DQo+ICsNCj4gKwlpZiAoc3RyY21wKGFyZywgIm9mZiIpID09IDAgfHwNCj4gKwkg ICAgc3RyY21wKGFyZywgImRpc2FibGVkIikgPT0gMCB8fA0KPiArCSAgICBzdHJjbXAoYXJn LCAiMCIpID09IDApIHsNCj4gKwkJb3B0X2NvbnNvbGVfaW8gPSAwOw0KPiArCX0NCj4gKwll bHNlIGlmIChzdHJjbXAoYXJnLCAib24iKSA9PSAwIHx8DQo+ICsJCSBzdHJjbXAoYXJnLCAi ZW5hYmxlZCIpID09IDAgfHwNCj4gKwkJIHN0cmNtcChhcmcsICIxIikgPT0gMCkgew0KPiAr CQlvcHRfY29uc29sZV9pbyA9IDE7DQo+ICsJfQ0KDQpJJ2QgcHJlZmVyIHVzZSBvZiBrc3Ry dG9ib29sKCkgaW5zdGVhZCBvZiBvcGVuLWNvZGluZyBzb21ldGhpbmcgc2ltaWxhci4NCg0K DQpKdWVyZ2VuDQo= --------------oja8Yxxh93BJdDnSK4Gr4k6e 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----- --------------oja8Yxxh93BJdDnSK4Gr4k6e-- --------------9wlGni05LTNQe0IgfptKbKsi-- --------------PGQlewguDXdt21TBRvFJvcjw 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/Ey8FAmlk0X0FAwAAAAAACgkQsN6d1ii/Ey+Q lgf/Vvy1tljOBN2IxBYLvT+I+2bYLm4rhr1X30l0o+CA6u+ouNyi1ajWjp34J1hbMqYq5IhGz6vz Pj2C4wjiMeiEU+IBVvBsinc/iAEsFHexYQ3PvUjf9SPpYLHey51OiSTSDn5Oby2772i/ngiYHRFT z/1WNAaDuvlVxUWV20Yg7SoBZ+8MrfT7CNiCtkFO4ZAzKzTxWzIybCeoRi/q8zScnEcNfig39TkN M+0pjEMnT11Vf/RiMbnX76oykaZ5/E+jlZogKd1vP3BeX1wmAF6ePup9rkYmoST/s9JO/pEAkCUM 86CM/tG5uMmsLAgUJXLTrSd/72FrMejTlBebv9ddvQ== =CS5j -----END PGP SIGNATURE----- --------------PGQlewguDXdt21TBRvFJvcjw-- From xen-devel-bounces@lists.xenproject.org Mon Jan 12 10:49:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 10:49:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200049.1516061 (Exim 4.92) (envelope-from ) id 1vfFUZ-0004gr-FW; Mon, 12 Jan 2026 10:49:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200049.1516061; Mon, 12 Jan 2026 10:49: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 1vfFUZ-0004gk-BQ; Mon, 12 Jan 2026 10:49:47 +0000 Received: by outflank-mailman (input) for mailman id 1200049; Mon, 12 Jan 2026 10:49: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 1vfFUY-0004ga-2Z for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 10:49:46 +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 6739b950-efa4-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 11:49:43 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-477a2ab455fso57018215e9.3 for ; Mon, 12 Jan 2026 02:49:43 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d8636e588sm137320895e9.0.2026.01.12.02.49.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 02:49:42 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6739b950-efa4-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768214983; x=1768819783; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=nLQganLMBoeE7/Xz9tgB4N14tSzNp/xN8SUtKQ8gP0I=; b=ZA1xqmtHOLSAPKSl49Xz/VBm3lkTvWuJwx+vvVa8Fcuyk3ORGeoJsNuld43IcqMGIN BX7kafcPc2gCXXISepMEAhotbwjA090KQaJJyK3dWHw88BejEbhuT4O3sz76O4BP20no jWjiTYp7kXQ3xQkYgwNonDa2Iz/kPAhV9xUOYa2NG1jPYV6e2LXUx1zHS8Ln/UCxamAX lb4iAJxPFOAqLrEkXl2fzJa5KlYLIdZgV6IhxuqNWpdiTUs2rQXIq1pwmOjbHCtmPIq5 NuDGdRmfgHvd0s2GxYVuVksoywGWS/xgU+41MV72W+OwW55Xftit60SZ+sG1Z49oufyU v+Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768214983; x=1768819783; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nLQganLMBoeE7/Xz9tgB4N14tSzNp/xN8SUtKQ8gP0I=; b=NcN0bY0PIKkTZV2DtBITGpjs3nPoAvBUdkK5Ab5jrnJv4/yraWLJm8mw1BhRjFdvu8 dX69L07X8HyZAHMC5hJmHTfOl+ePe7wq0MLYEwdT75Ym1bzqO+VPFl7g12jnG1nWMl7s 7Ae9OXOrvvcfVdJVOxE7KNWFopCMMgxPd5hzUi7NYJAsJcMrS9PB2hujSNmB+yBzP+uc kdwhPEwSQwxTG7/sSez1E8VuFiK++S9G9qtgQLKzxe5motOxUXs3zOfJmB7HiN5igTll U0l4vgMA8XYOVcsPHTqV6bAdt8MFEY2Ey92KqAPSQmhekB7ecZcNZnVIJL4isoAMUGKR Cqyg== X-Forwarded-Encrypted: i=1; AJvYcCVQfW5hdjF90BZnXqjHMUdh/G5VwcdRZi6O9On7dgvQvdQQwcRKDKB0I/igYM1ExAROL5BcHgxQiSQ=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywssuqd1TiR3QQzyDz9Ln7r5kt4TmkQAPG8T+uwdPGGaaNw623t OrZK9u2WSSaP4uj/hwzf/N8iS10uvN0FMBx+DTo0hcHPB0fNitQtK8S/VRZ9czXrFA== X-Gm-Gg: AY/fxX6lto29VvKZpqYTAr4G0X36Gbwbgj10s9k2l2vTFsoDYIE6o9Lrd2s56C332uU 6Wf31ChbksVCZ5uB0FWzYET2+82qQ5t6mq7fglz/f/5lr7PETHb3r6F6d5pmFuG6SuLYWs/JNUb T6zLyIpykDQ8zDxE8iocy57zyfSr7zPoohIPH8WZf/gNeky/1HH2B3/N8omEQSHYTcpMMaJl9Jx JrFc3TjaxGC/6ymuQ7xWHlblXsGaYbhxYFpjuTwsLaOkOqgUKAK2MGn7QhqosTZ+REJ97H49x8L 1XCX85ynQGB8qvYljpyUWkxXigo2+XAhyLkYzUgVtmdAv3QROsmUkZGgOWxzHpUzkewuwXCIoVf sXefLezGaCRvsy4wRxjC9Stpqohpb5zV/FIXg5GRUVNSDHKCHbSkFeUMSQSjWtRiKYafEHG44/m NwjWu3ppKWLbXtyUidw25WcC0QOqsz1kgDy46lbiuLZpLZxk+84td1ifGNdflUxJSbTXFCYVQa8 bk= X-Google-Smtp-Source: AGHT+IFRyxlk85ePILke1/Z9tzh7zoD0dvnHhNOhnYsrxWGHGY0mZBQOzPnpj0tD3qRzwuoxbndseg== X-Received: by 2002:a05:600c:1f13:b0:47d:3ead:7440 with SMTP id 5b1f17b1804b1-47d84b3b772mr198537255e9.32.1768214982872; Mon, 12 Jan 2026 02:49:42 -0800 (PST) Message-ID: <9eda3a84-2a29-416d-80d6-ea0e5c9b4bb5@suse.com> Date: Mon, 12 Jan 2026 11:49:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] acpi/arm: relax MADT GICC entry length check to support newer ACPI revisions To: Oleksii Kurochko Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Yann Dirson , Yann Sionneau , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 09.01.2026 17:23, Oleksii Kurochko wrote: > > On 1/9/26 11:03 AM, Jan Beulich wrote: >> On 09.01.2026 10:27, Oleksii Kurochko wrote: >>> Newer ACPI revisions define the MADT GICC entry with Length = 82 bytes [1]. >>> The current BAD_MADT_GICC_ENTRY() check rejects entries whose length does not >>> match the known values, which leads to: >>> GICv3: No valid GICC entries exist. >>> as observed on the AmpereOne platform. >>> >>> To fix this, import the logic from Linux commit 9eb1c92b47c7: >>> The BAD_MADT_GICC_ENTRY check is a little too strict because >>> it rejects MADT entries that don't match the currently known >>> lengths. We should remove this restriction to avoid problems >>> if the table length changes. Future code which might depend on >>> additional fields should be written to validate those fields >>> before using them, rather than trying to globally check >>> known MADT version lengths. >>> >>> Link:https://lkml.kernel.org/r/20181012192937.3819951-1-jeremy.linton@arm.com >>> Signed-off-by: Jeremy Linton >>> [lorenzo.pieralisi@arm.com: added MADT macro comments] >>> Signed-off-by: Lorenzo Pieralisi >>> Acked-by: Sudeep Holla >>> Cc: Will Deacon >>> Cc: Catalin Marinas >>> Cc: Al Stone >>> Cc: "Rafael J. Wysocki" >>> Signed-off-by: Will Deacon >>> >>> As ACPI_MADT_GICC_LENGTH is dropped, update the functions where it is >>> used. As we rewrite the MADT for hwdom, reuse the host GICC header length >>> instead of ACPI_MADT_GICC_LENGTH. >>> >>> Mark gic_get_hwdom_madt_size() as __init since its only caller is also >>> __init. >>> >>> [1]https://uefi.org/specs/ACPI/6.6/05_ACPI_Software_Programming_Model.html#gic-cpu-interface-gicc-structure >>> >>> Reported-By: Yann Dirson >>> Co-developed-by: Yann Sionneau >>> Signed-off-by: Oleksii Kurochko >>> --- >>> I ran CI tests where it made sense for this patch, as I don’t see any CI job >>> that builds Xen with CONFIG_ACPI=y: >>> https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/2252409762 >>> >>> I also built Xen manually with CONFIG_ACPI=y enabled and tested it on the >>> AmpereOne platform. >>> --- >>> xen/arch/arm/acpi/domain_build.c | 6 ++++++ >>> xen/arch/arm/gic-v2.c | 3 ++- >>> xen/arch/arm/gic-v3.c | 3 ++- >>> xen/arch/arm/gic.c | 13 +++++++++++-- >>> xen/arch/arm/include/asm/acpi.h | 21 +++++++++++++++------ >>> 5 files changed, 36 insertions(+), 10 deletions(-) >>> >>> diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c >>> index 1c3555d814cc..959698d13ac3 100644 >>> --- a/xen/arch/arm/acpi/domain_build.c >>> +++ b/xen/arch/arm/acpi/domain_build.c >>> @@ -458,6 +458,12 @@ static int __init estimate_acpi_efi_size(struct domain *d, >>> acpi_size += ROUNDUP(sizeof(struct acpi_table_stao), 8); >>> >>> madt_size = gic_get_hwdom_madt_size(d); >>> + if ( !madt_size ) >>> + { >>> + printk("Unable to get hwdom MADT size\n"); >>> + return -EINVAL; >>> + } >>> + >>> acpi_size += ROUNDUP(madt_size, 8); >>> >>> addr = acpi_os_get_root_pointer(); >>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c >>> index b23e72a3d05d..aae6a7bf3076 100644 >>> --- a/xen/arch/arm/gic-v2.c >>> +++ b/xen/arch/arm/gic-v2.c >>> @@ -1121,7 +1121,8 @@ static int gicv2_make_hwdom_madt(const struct domain *d, u32 offset) >>> host_gicc = container_of(header, struct acpi_madt_generic_interrupt, >>> header); >>> >>> - size = ACPI_MADT_GICC_LENGTH; >>> + size = host_gicc->header.length; >>> + >>> /* Add Generic Interrupt */ >>> for ( i = 0; i < d->max_vcpus; i++ ) >>> { >>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c >>> index bc07f97c16ab..75b89efad462 100644 >>> --- a/xen/arch/arm/gic-v3.c >>> +++ b/xen/arch/arm/gic-v3.c >>> @@ -1672,7 +1672,8 @@ static int gicv3_make_hwdom_madt(const struct domain *d, u32 offset) >>> >>> host_gicc = container_of(header, struct acpi_madt_generic_interrupt, >>> header); >>> - size = ACPI_MADT_GICC_LENGTH; >>> + size = host_gicc->header.length; >>> + >>> for ( i = 0; i < d->max_vcpus; i++ ) >>> { >>> gicc = (struct acpi_madt_generic_interrupt *)(base_ptr + table_len); >>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c >>> index ee75258fc3c3..e4fcfd60205d 100644 >>> --- a/xen/arch/arm/gic.c >>> +++ b/xen/arch/arm/gic.c >>> @@ -414,12 +414,21 @@ int gic_make_hwdom_madt(const struct domain *d, u32 offset) >>> return gic_hw_ops->make_hwdom_madt(d, offset); >>> } >>> >>> -unsigned long gic_get_hwdom_madt_size(const struct domain *d) >>> +unsigned long __init gic_get_hwdom_madt_size(const struct domain *d) >>> { >>> unsigned long madt_size; >>> + const struct acpi_subtable_header *header; >>> + const struct acpi_madt_generic_interrupt *host_gicc; >>> + >>> + header = acpi_table_get_entry_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT, 0); >>> + if ( !header ) >>> + return 0; >>> + >>> + host_gicc = container_of(header, const struct acpi_madt_generic_interrupt, >>> + header); >>> >>> madt_size = sizeof(struct acpi_table_madt) >>> - + ACPI_MADT_GICC_LENGTH * d->max_vcpus >>> + + host_gicc->header.length * d->max_vcpus >> Just to double-check: All entries are strictly required to be of the same >> length? (Related question further down.) > > If I understood the ACPI spec correctly, then yes, it should be the same length, > as|GICC->length| is defined as a well defined constant value (82 in ACPI 6.6): > https://uefi.org/specs/ACPI/6.6/05_ACPI_Software_Programming_Model.html#gic-cpu-interface-gicc-structure It's not entirely explicit there, but my reading would concur. Then ... >>> --- a/xen/arch/arm/include/asm/acpi.h >>> +++ b/xen/arch/arm/include/asm/acpi.h >>> @@ -53,13 +53,22 @@ void acpi_smp_init_cpus(void); >>> */ >>> paddr_t acpi_get_table_offset(struct membank tbl_add[], EFI_MEM_RES index); >>> >>> -/* Macros for consistency checks of the GICC subtable of MADT */ >>> -#define ACPI_MADT_GICC_LENGTH \ >>> - (acpi_gbl_FADT.header.revision < 6 ? 76 : 80) >> Given this, ... >> >>> +/* >>> + * MADT GICC minimum length refers to the MADT GICC structure table length as >>> + * defined in the earliest ACPI version supported on arm64, ie ACPI 5.1. >>> + * >>> + * The efficiency_class member was added to the >>> + * struct acpi_madt_generic_interrupt to represent the MADT GICC structure >>> + * "Processor Power Efficiency Class" field, added in ACPI 6.0 whose offset >>> + * is therefore used to delimit the MADT GICC structure minimum length >>> + * appropriately. >>> + */ >>> +#define ACPI_MADT_GICC_MIN_LENGTH ACPI_OFFSET( \ >>> + struct acpi_madt_generic_interrupt, efficiency_class) >>> >>> -#define BAD_MADT_GICC_ENTRY(entry, end) \ >>> - (!(entry) || (unsigned long)(entry) + sizeof(*(entry)) > (end) || \ >>> - (entry)->header.length != ACPI_MADT_GICC_LENGTH) >>> +#define BAD_MADT_GICC_ENTRY(entry, end) \ >>> + (!(entry) || (entry)->header.length < ACPI_MADT_GICC_MIN_LENGTH || \ >>> + (unsigned long)(entry) + (entry)->header.length > (end)) >> ... is 76 a valid length when the FADT revision is 6 or higher? And 80 is a >> valid length for 6.5 or higher? > > I'm not ACPI expert but my understanding that it isn't "very valid" values as I mentioned > above GICC->length is defined as a constant value. But the idea here is to provide > forward compatibility so only minumum MADT GICC length is checked and as mentioned > here [1] by one of ACPI for Arm64 maintainer: > > - (acpi_gbl_FADT.header.revision < 6 ? 76 : 80) > +#define > ACPI_MADT_GICC_MIN_LENGTH ACPI_OFFSET( \ > + struct > acpi_madt_generic_interrupt, efficiency_class) > > > This makes it 76 always which is fine, just that the first user of > > efficiency_class should check for the length before accessing it. > > No user of efficiency_class yet, so I am fine with this change. > > And I think the same is true for ACPI 6.3 which adds spe_interrupt and ACPI 6.5 > trbe_interrupt. ... imo precise checks for the version dependent length should be done. Jan > [1]https://lore.kernel.org/all/20181015092919.GA1778@e107155-lin/ > > ~ Oleksii > From xen-devel-bounces@lists.xenproject.org Mon Jan 12 10:55:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 10:55:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200060.1516071 (Exim 4.92) (envelope-from ) id 1vfFZX-0006FE-0B; Mon, 12 Jan 2026 10:54:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200060.1516071; Mon, 12 Jan 2026 10:54: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 1vfFZW-0006F7-TH; Mon, 12 Jan 2026 10:54:54 +0000 Received: by outflank-mailman (input) for mailman id 1200060; Mon, 12 Jan 2026 10:54: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 1vfFZV-0006F1-K0 for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 10:54:53 +0000 Received: from DM1PR04CU001.outbound.protection.outlook.com (mail-centralusazlp170100005.outbound.protection.outlook.com [2a01:111:f403:c111::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1e9fa923-efa5-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 11:54:52 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA6PR03MB7830.namprd03.prod.outlook.com (2603:10b6:806:42a::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Mon, 12 Jan 2026 10:54:49 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.005; Mon, 12 Jan 2026 10:54: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: 1e9fa923-efa5-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Yb/z1CJwoU5WYGzp/oBg4gXF5zY+lHU3uDEMZNE1SrZTOuiOrHjjyAlhz5ZOxiMSLrUffds9mj/7iPju4Ar3nSnO2zxNHBWU8OexvlLhfRWnpPbCI5kUj0TfzlLtV1oYkyCgQUIxLMd7KqjI1xq1TzUFbRxpHrjIF1a8CH+U8kfY+7KsseBKOyqq286YK3blc9yhhweHl6X+NkT0du0tzNjqSTpLJpBrJapDVD+9Eq9Zsp7550SP9Pq6zJZh9yJyleqv6A92eP/FYvUDQpAQG5oJupAxT8/WLOKNWTxe1fePSYUcx/AIHa9HjcgfeOqJBTNrrEpkFtENfgEwVn2xQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1F0M4p72c5SHMduF9LQk8+im1xAO5oViXJluA9ACvfA=; b=O7rJEACfuhbiJHaFzZypmjYQkKwQGrGaSVUkeotHAfnET9kTKKXVue4un3PeaM6fp4dAsnNQHELUapiS2K2osN6WUS/Ax72ylF2OYddppQj5G4ag9NVK6ledex/q3sqMJLk+R7NwxmRsacbQp/KjAEt2jtag6apuZ3rcsUXHHnmSCQD/bQb0R9lMtLiY9qJnenDIqbLIQMHYHBzXIbjjzO8flJICxL58KMOODikFdaUJM/jTCCzPsw+u0S8mygCOwDsh8Gw0wGiojM8TDG2atfze/UYndtVxaO9ukjtr3YICXHzqriNMgEPfh65M3AatK73USTkTzNmX0oPGWfagLA== 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=1F0M4p72c5SHMduF9LQk8+im1xAO5oViXJluA9ACvfA=; b=KOgYeweUuof13ljpwkyg2tgu2X21n7pcNBd0tCsknVowiTkEtt9eDXURr+rSSqjykTAzkPaZqyOs4GzMXF4vlFjuCc1IDwoCVnneU2KSAQ/ekSB9r9Gy25cEX8YsOkxqduU+rcHO+7j2ENVhis9dQSzmrPJAba1PXZew2DIrWRo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <2b0b3c25-c504-4e5f-b995-cde41093f560@citrix.com> Date: Mon, 12 Jan 2026 10:54:45 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Subject: Re: [PATCH] xen/arm: Print correct domid in allocate_memory_11 To: Michal Orzel , xen-devel@lists.xenproject.org References: <20260112104233.86482-1-michal.orzel@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260112104233.86482-1-michal.orzel@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0121.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:192::18) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA6PR03MB7830:EE_ X-MS-Office365-Filtering-Correlation-Id: 111884fd-6dea-43fe-3cde-08de51c90160 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?bUhQRUljTDZsMEhLZEJ5eHlPK3Z6Q1p4dXFueGxqSUpncG8yTmxEb0wybUd3?= =?utf-8?B?blc0NE40dFh1QzlqUmpnYUJVSk14a0dRYlpEK0Q1aGI2dHVxN2UzdWhRdi9Y?= =?utf-8?B?VGVJRjdKYjgrUnlMTmNPNXF1clJrODFnWlRLbkZjVGFBZDdvb3VuWUtrYWN2?= =?utf-8?B?V3o1bEVjTEtCR2g3bmJKc1ZYSnV1UHorQTBSMlEvVVZvUFRTTml4b00xRWQ3?= =?utf-8?B?a1MydE5BZzZXODVwTFRoMDlsV0tSRExFUTZJYnlHUlVlVnM3dks5ODlXejNn?= =?utf-8?B?ZXMzRU1RdHhldnNWbGpCOS85S1dWRzBMcHFUMnYvOG92RURwNW8yUjJLZ2x3?= =?utf-8?B?S0J2U3lLZTZ0b1pCcGZxU3RoZ00xbmJpMmlIOUh5enZycndReE5rQ2M5RHNs?= =?utf-8?B?QUsxNHRFQ2tURnZaSHhvdkZFZVRxQ1FmUnQxdGpDV1Z6UGhTb3BuL0p3L1hH?= =?utf-8?B?bGtKcm9Yd2NuajdJZjFzaVdVTUNiZlFpLzRZSlgvMlcwaVBuTzhucWVOMU10?= =?utf-8?B?d0l3TGlBYkxYQllhUXJaWC9LSmRFb3NBMHQwMDZJS0dlRjNMcUNsbzZOTFNF?= =?utf-8?B?bGtzU2p3ZkswYWpFZjRLbFR4a2pkdG45eWtxNE0wMHNmdEFVMWVpbVFpVEt1?= =?utf-8?B?TndFYTFXeHN3d0lPcXNWK2NnL3lOUnhBWFBNcTlZNHdJUDBPOFFHZFVieFoy?= =?utf-8?B?eXVRWGVoRC9mYVBaUDFhWllVSGJmcHRDR096eFE5WURJdjI1RTRqMHpwRW1j?= =?utf-8?B?SlJPdDVORmRMeVJjMTd1YjRIT2RsdDJXSnVZalZrNG95cGFxVHlTODA3YzZ5?= =?utf-8?B?Yk10WW9ES3hoVFJYTmVUY2tZOHQ4eStEc2M2aG1NaVNZOWxGdjNodCtONXBO?= =?utf-8?B?NE1XaDhUVUkzL0FxaUt5S1F2Z0ZreGpMQmhXb1d2SUZ5OVJwSXVrUEJMenhu?= =?utf-8?B?akFnNzJmTW9zVGM1YlJOb3VEMnROdG9NbU56UCtPREFSUW5OMS8wTDVzY2Iz?= =?utf-8?B?azI0aVAvRk1ybGJSVDNIQXlhTTd2dWpUZ0s4T08zTUVrTXV3RCtWNHBJcmNw?= =?utf-8?B?ZDBnRkM4MUZXSjk3cFdPci9zZ3g2bmh5d1JwWDZaMUdrcFE2c015SW9yMW1H?= =?utf-8?B?T0pSRDZJVzh6b2xKM1M3YUdSMmtiQUk2ODE4TVIrRFErRVFoYWtlc2hVd0Zo?= =?utf-8?B?TWdwRmVJcUZ5NlJEeGpOMXR5Rm5aVjZXaE9zak9PdUk2M05QTmdqZnNsMFEy?= =?utf-8?B?NUdJUWdpU1ZEYVVvM2ttcXRRM251eHNncU43QnVnRWFmTldIaktudTl5TlhD?= =?utf-8?B?c3dCS1dPeTQ2a3V2cW1RZmRkMzNlLzlOTDJnT2pUY1dwRERRaEtuSzJvYlJJ?= =?utf-8?B?OTF0Smo0VGorUHF5RGFIV1NOayszMXJMc3cwTjl6dkthclJwYjRHMEdoK0Fj?= =?utf-8?B?WTcvS2pSSkYxZjdRYWtFQ2VMM0xIUG1SbnZhRkE2QU9Icks1eGJOZUd6U1Fi?= =?utf-8?B?emFKSmF1TFlaUHdXWEtvcUlhem9tNTZ3bEdiU002TE5QTkpZZHRRZ2w5NVJP?= =?utf-8?B?a1Y4cGFQbDZVdEl6L29ZSEtDOFQzZ2dnb3p3amJjVUppQjkzZHZhU2xzaXpJ?= =?utf-8?B?RlhIbTBRa1lrRUdWbTA1ZENMYVB1a0hYUzlRb3RubE1jd3UwS3dMOGk3MFJM?= =?utf-8?B?T3pvZlYrVFlsUzVScnZEdXRwd3YzSXJqUXVrWVM4WkEvKzJSRm5QU1RuZFhD?= =?utf-8?B?VmliRTJTdkxrZlNzdkRIY2hTaTIxeDdNb2NEWisyT085amIvVjV5bnZkWjNO?= =?utf-8?B?QithcklXSmR4bmJEbExDeE1MeGhZc1M0eC85OXRpdElPd2Q0NFdacUpSVXI3?= =?utf-8?B?K0x0dGpGbXlHUHFURmtwdWVuYzBoYWk2WHFsem1USVU3VEVxTUFlT01GQm9r?= =?utf-8?Q?1QY3AHEipvjhdY0pfgvFNOA+T9V7TkNz?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OVU0ZlNRWmRTMHdkMHVITk4vR29wMWRXYXVCY2VFbTA1V2lKdHNvM204emZi?= =?utf-8?B?M3RraENBSkdXemVLUnBCVHVpK1RlbGIzenhOZ1BudHM0ZlJERVIxTFdDNEZL?= =?utf-8?B?dllHMjRWbVp4YUhlOEwxRFMzUk43SVlvT3FMS2JyaHNyeTRFaENrV3puWDdn?= =?utf-8?B?d0F5eWFYY2xIdEJGcmF4SzBDOXg1T1pYYlBDUWo1elJWNUluaFpPamY1dVZG?= =?utf-8?B?ZU03N1JuU0hzMUdnNklFampkZTRERWluRVVpMm5RRk1reHJyd2FmQkpCQkg1?= =?utf-8?B?UFpMcG1USDVyNTkyYXFIQ3UwQmZ6aTFzNnljODZpMitKVlhzOGptM1A5UkJD?= =?utf-8?B?bDdHdnRTdThRMTlrQ3RFUW5PaTNiS0g2YXZHM0ZhaUI5RHF5eWQ0eE9JOFdD?= =?utf-8?B?VXpkZitnVTRndHFCOWJZd3ZveDlKRDB1cEg2bWJNNmFJSDcxSG9XUS9oSGpC?= =?utf-8?B?WURIdkUveitXTW1kYlhpeEk3ZGlYdzlpVjZFMmFBR1FUelM2a1h2UEp6RHFi?= =?utf-8?B?elo1QU0zdTVrZzB3bW5oSjRwQ1RtSTIwcGhlbW96VXc3SkhZUnBwUGpHakY3?= =?utf-8?B?aVB2NUhidnZyUEs4bmVjc2Ztbm9sTlpydmxmMGdVYVR1eEwyY1U4cmRUZENx?= =?utf-8?B?ZUY2OTNHWVRIdzJHd1pLWW1NNGpuWnBHdUZPUWpaZ0lRK1FoNUdzNjJHMnVG?= =?utf-8?B?QTZVVjJxTFdTTXEvYmtSRmpac0Z2UDBuNVdYaXlndDYzTXAwOHFOVmpPZFdZ?= =?utf-8?B?Q1M3WkFEYWh5b0g2ZlNIS2ZjTFNFVDdrSFY5TzNldVNzRHFrdWo0bzV4RStx?= =?utf-8?B?TVZ3NWlIUkpFL3NoU21hOFFlcW5GY1QydG00UWh0Q2VGTGo2WVFTYStvNitX?= =?utf-8?B?d2ZIMTYwL1Z1TFdVbld2Z3RsUWpZY2dzK3JwbHJOS0pseGZ4OE1BNitIKzVp?= =?utf-8?B?NkxvUHhLN2dndFJMakpiVy9iRXg2d3YwaStNeE1KOHdiN0RkYjZNOGk2bzlX?= =?utf-8?B?ODh0RmRGZG14ZGlrN010UzlhcWJORjgwZUxlV3JvY29iWHROOUdXeFk2Vjlv?= =?utf-8?B?OEFGMFNiNFAzMkxFMnBLOS9nSm50dFkxeTN2MnNkVWdHRWpGNWRDUHpwc2Zu?= =?utf-8?B?d1k1OXNYbWFtNXNNRHQrbW0wTWMrQkZsTEVNZ2E2L2E2Z0c3UkdlM2dyZkhE?= =?utf-8?B?UEV4VHltWk5MWVZ3OS8ra1d2VGxhU1N4cnBuNktrNzdFR3hVSElKLzIrRUYy?= =?utf-8?B?ZmR1bGgrcEFaUUdwaDhjRkRrS0RqZVlFV2ZKcnlSZ3lTanh1aGR3ZWJEUHpF?= =?utf-8?B?dWhIWkNGSGwrQWlCRjRzUGl3NUovSDRqdWU1N3paYnJkRUptaFZDaS82dzdH?= =?utf-8?B?cXZCNmpKMk1vZ1ZKbGM4WXdBRmVaalRyL2NyU2daNkZuQ0pPbWs3TUZKOFpW?= =?utf-8?B?M3NpZThNOW1ka1R2L0xYQm5mVHlmRUEwOW04TzNyTWdlelJXRXRzMWx4cGJ4?= =?utf-8?B?OGhOWVZuT3BwWTFFajBIYysrR1l5WCtrdGFNOVpxdld2RDJsRW1FUHNtZTVs?= =?utf-8?B?VWZEbUVlazhFZ0VOWUw5RGpIbU82TnpXS09OblJnQlNqUVFIcEVkc2xBb1hD?= =?utf-8?B?c3NBTVBXZk1jZmc5R3BZY01pdFRwekRHRVl0WUN4aEhScythVEJCVEtFbFZn?= =?utf-8?B?V2FvWi9nZGFjSFNLVVFVSmJ5K29hSFc5WEFWd01jS1lKZDhnMjllUmg0U0ox?= =?utf-8?B?YjV1SHNuWDQvTVArMWlkNG9lWkZrNmdrSXBRWGoyMGlZa0RsS2pGRXMxNkxR?= =?utf-8?B?VHl5dDMxWno5Zkp3NEFLSlN4VjR5NUJZdlZIQ2Y1b0xrbWJZWmJVc0dUWkVY?= =?utf-8?B?UzJJRURoSzRKeXZSS1Mwb3c4Tk9VOVFGeGh2REQ2UHNRd2U3L0pjVnRpdU1h?= =?utf-8?B?K3BKaUlleEdSZmcrYy9hZjBJWms5T1d5VTcxdGMrRjVNVnlWVUtpNUdSTkYr?= =?utf-8?B?Lzd2Ym1RVFRodTA2emkxZE45VERwUEprZk96TFdjM3FlQWZHU29ZWXkwZ3pq?= =?utf-8?B?QmU1N0g5NTBtRDU4YWRjc0NCeEFHVE90Qit5YlV1M1dzdWN4KzY3MjRpRXFk?= =?utf-8?B?cXdrMzEvTGIvblk4RXo3L1dHU21BR0NNNGRsa2FsQk9Ta2dqYU5NWEZPR2pw?= =?utf-8?B?aVltWTAwY2xOak9qK0FQa0E2Zi8rUFZmSzRwdms5NEh0SmdmS1MwQzBhNGIx?= =?utf-8?B?c1EzRERNTTA0ZmRXL0lQYm9zMjRnZ1lLSFFUdmZOUk02RGd3UGdjQjhvOFAr?= =?utf-8?B?WDVRRUc0TXgwMWJUSnVzTXY4ejRzMTcwTUE4NndKQUdDb1UzeFkrZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 111884fd-6dea-43fe-3cde-08de51c90160 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2026 10:54:48.8694 (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: burHj8mi7X5F84VkQTEZ7T8ermqsisd0UQYJ5/k79fcRbGW75xj7qvjjz1tMMxr3Lx/nOdhoZMiMKGKnnFZm9RuYr+Sb7nuMGIUB8xiHUhA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA6PR03MB7830 On 12/01/2026 10:42 am, Michal Orzel wrote: > allocate_memory_11() can be called for dom0 and direct-mapped hwdom > domU. In the latter scenario, a log message would still mention dom0 > instead of the correct domid. > > Fixes: 52cb53f1816a ("xen/arm: dom0less hwdom construction") > Signed-off-by: Michal Orzel Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Mon Jan 12 10:55:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 10:55:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200069.1516081 (Exim 4.92) (envelope-from ) id 1vfFaN-0006j1-8V; Mon, 12 Jan 2026 10:55:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200069.1516081; Mon, 12 Jan 2026 10:55: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 1vfFaN-0006iu-5R; Mon, 12 Jan 2026 10:55:47 +0000 Received: by outflank-mailman (input) for mailman id 1200069; Mon, 12 Jan 2026 10: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 1vfFaL-0006gt-KH for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 10:55:45 +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 3e188738-efa5-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 11:55:45 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA6PR03MB7830.namprd03.prod.outlook.com (2603:10b6:806:42a::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Mon, 12 Jan 2026 10:55:41 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.005; Mon, 12 Jan 2026 10:55: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: 3e188738-efa5-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=l4lD4Dn7P5q0a/C7SVB2drz2Osy1nQJ7DwsER/44G4h4DeEhdNyZnpbW+Lz5JaTGCF0OVUHdRppt7aWcxq0MbICXsJbWAfcNbMFmJQcBXPm5Tslx38+ZmXSe+XzLv0sQyPNyXBb14a6Bu5RjNLVAwkXgquleqyW7DqB0HLTsEe6dTHlmytFD0LZmMq9nxaaA02BFhqslUPBSBQyvGTwgIT0DW704TttNV6MUVyvNe9POSdAjpysO2eIAF6kS7J0FedCYyQD2PmW8pzkbPZCg7lsQqCJUHjpO0AyRh/cexBW/Xecuui72Gf5RDfATT2Rq2lkGn5m42NlgLO3TZLh4Yw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fGMd9dCw2jxOIgg6Aa7j+76NQID7VHLeTGk8VWtlkIA=; b=s4zEdShDhLcx/wrx5+1shzADKSwmNJ4JJhpZIv7b9BJJYeDqsgHq2ZitPTsKoJaeRwYOUqH3eF9Y/Fc8vaPnI/gzzlg40mAHt/roLGAW+xC7XSxJ6VPg1gCJBlVPwrQPfdTurPGJG0iBlEMLR2AU8TcECtxIrDHmiZ3VbUW2XcepzOIwCyvtDvlqKXnGTAC6IA7RpCrKCTZMCYbQRQWzos/+Xu+H4OkEVl9mrYTe5yMcPGSeipl/1sVwL1AU9pjO1ge6V8BwheJGBB5injbyxxRLBaMtk7ok69slh5+Bh0luCfskbuOIxgDOCqRdRYL8ImUOlDT8i31CzScRAmcN+A== 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=fGMd9dCw2jxOIgg6Aa7j+76NQID7VHLeTGk8VWtlkIA=; b=0dhbCql4cfEje2F+R30/6yvOtIKc57Gfj1oWeFZtccgB6UBB4LHhoYOIAziqi8vO9YU/XZ/3Vy8kGWtM2WTU0MAMN5EMvIizAV6qWrLjCzlWDmoCMl42mXsy/y+TVBaKuU/+UJRMiV+bHhx53DPWQq4N86RFsPB5NZajq5zGg9k= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Mon, 12 Jan 2026 10:55:38 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Xen-devel Subject: Re: [PATCH] xen/nodemask: Remove _unused_nodemask_arg_ To: Jan Beulich References: <20260112104015.1001907-1-andrew.cooper3@citrix.com> <3b0d3397-cffd-4017-89da-6850101d5f9a@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <3b0d3397-cffd-4017-89da-6850101d5f9a@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0117.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:192::14) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA6PR03MB7830:EE_ X-MS-Office365-Filtering-Correlation-Id: 1c63836a-d14f-40fc-b2c4-08de51c920f1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?d0VpOG9mQzhwTURwLzM2eUtoak5YdFk0S1ZOeHFwQitrYnM4RnpLS0R6d2Y4?= =?utf-8?B?TmNPalptVGpBNlJDRzlYWklxRFJVOGowcEt3d0NFRGJZV0Z4NzJCSFNVZzF4?= =?utf-8?B?YVZhOVBaWEdtLzRobkpxZFlaalQ1N1B3dFhDRVFXQ3JpOHFlcG92UUtqT0o4?= =?utf-8?B?akEwRHRwamxXTWdyUmU3VWQ2cFVKQkxMY2tZL2ZoS1daaCtQZEd1UUlmZElF?= =?utf-8?B?cEVhaW5jWW5BcEJKaG9vR3o5UG9sNFNrc1dEQzg1QVpMVjBJZFhaSTdDYktM?= =?utf-8?B?ZHlFU2xVMFpRcXU3VXpBQk9iZEoxczVabS83a1Nra1RYWEdHS2hDN3BlUThJ?= =?utf-8?B?VWY1c0lCOCtBZjFoVThvNXRjbGMxbFJNS1dHUTRtdEZhNDZrb2w0dm54VEx5?= =?utf-8?B?aEpvcTFrVWZpZ1F5TWhOSmdGdGZWdkVIQTNweC9ybzJFMzNTL3Z4OUpnY05S?= =?utf-8?B?Ymx2RGdIOGNzU0FYanc5RndDMUErV0Q3WDFyRnBlYVFaeUVwZkx2eGdKTG9V?= =?utf-8?B?VW5aZXFiamZ6REk5M3IyNDRyNytNRzI3Q3J6WE83UWVxZXpTeVdYYzdDcWlN?= =?utf-8?B?SlZkWWR6bkFxWDhSSndPM3hkRExrWUJEbzhMekF1dmMwNDMraTNpNE1sdWNP?= =?utf-8?B?TUhqVG1uVVFaNGJJeXlvYnM4U2YxQy9YaHZsMWgzOXJPZEQ1V3FsTEtBaDBO?= =?utf-8?B?T1R6QmpHclNTMkErdW1LZGoyVHNycnF3RnAxMGNKVmlRbTFVZFpnVmlyMXZH?= =?utf-8?B?Z0pkYlBLSmhyMzBXUVB5TjlySzRvaEwzSGRqTlJ3cGpDUzNzNFJlcEwyYzA5?= =?utf-8?B?N0J6YXdCdXN5S0YvVGRWVG5Cd3NKeHpZdzY5bjV0L1NLM2ZidUxIbG9iZ04x?= =?utf-8?B?U1g1SFNreVhnT1RVWXZjT0l2UGdNOFBpdmRJeU1zL2lSOWtjZjNvdWFGTUE1?= =?utf-8?B?azMxbWtoM2VuNkZsYjcwVnhBd2NnM0FTaDUrc3hjMFlJaTREek1HbTlFbmdJ?= =?utf-8?B?bTE0RTJIbEJwSmoyRnRyY1luY1JON1FtQ0tpNkRCY1JKcVhKT3Z5M1FSVFNP?= =?utf-8?B?NnNrZXNNUVFBanREUmsyQU16RnB4ZDF1TWIwSTllV1FoemFJUDhkcUNMWkVF?= =?utf-8?B?OHUrVytTQTU0SGc1TkNOZlRDMEtjMTdFV3hhRS9VRGdwU3UyZURUV05mVGNI?= =?utf-8?B?Z0VtZGN3cFQwVkxOMG0waDN2UkRtYnE0ZHBVMjRYTUpJSzdvTUxKUXBuRldY?= =?utf-8?B?WDJFZDQ4MUdINFJGNHpkeGQ4V3ZSZDRIcmNYSEpncktRVWVsUzBmSjczZ3Bl?= =?utf-8?B?S016ZnZ2NUllckJ4YVM5dkk2VnF5V0tudUtjdDQwVmhqNVkrQ09nZVRaWFQz?= =?utf-8?B?K1FDaUZ2WjZNcWdHdjJKT0VxOVVjMDF0Mm9pTXFzS0xLMjJYNjRBWCt4a3I4?= =?utf-8?B?OW5leGdpTC9FMDNWRnZDSVNqcUZXMzhNZUxiczNQRStFQzcxUnhWeldtM0dF?= =?utf-8?B?MkJrOWE5UVEvR3VEYVU4TTdTUGdHZW5kR3RCdUE3ZXZyaUI4N2M4NVRsUlNC?= =?utf-8?B?NXcrdlhOMUNzaFVEd09sZzlEMWRJTWRLdkF6VTVPVmgyTDVWQStSSnREeFhN?= =?utf-8?B?c2RwQkpwby9EcWgvSVZ6eFpXbjRCS0FlUm9QN3Q4TE53YTB6c1VjNy9FdklJ?= =?utf-8?B?aUgvMTRPem0rbGpVRnFNbERyVElhd1lVK0g1L0h3czNac25ReVA1YlprL0Iy?= =?utf-8?B?cTQxRkYwVjU5Q1ZhSjZrMzlIN09hSTZ6OEt6U21kQ1FiRXNxa1FRRi9kKzh6?= =?utf-8?B?OEVrb2FNYkdJZUZXUGlOWTJrRHhXNDRJYXowVmUyZXVhbS9ldjFHVnRIaGdy?= =?utf-8?B?ZFBnRjNWTWNMN3hSY09XVk90ZTM5UzV1dEZyRXR0MlZYREpMbUVHVU1UM0RI?= =?utf-8?Q?3UpBPxJJwNNwzeMrIs4mrPNp2tgsviIH?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?a3grejdnL2lIdytPeFRpNVV2amNuV254WEY3V1hzWjJZNUtlcmM2SzBqMENC?= =?utf-8?B?YlZSZ1p0dThhQmtMMEU4azYrenhEdzNvcWlnempHSTh0OXdvQlJBbUhKVzNO?= =?utf-8?B?WjlOMFFkaE5JVmpOaGF5V2lKRFN5TTBsYmNZdXhsSEtId0taeHRmM0Nud1c3?= =?utf-8?B?V21mb1NvYVRNTENuWjRlQXQwRlU1Z2R3Q2JLU1BRQ0l4TXdvYi9pVDhNUnRZ?= =?utf-8?B?THNMUlA2eldjZDNtdGZxeE5BWEFIMnpUcHZaY3FJZUQzUU9tSFN5ejRoZmpE?= =?utf-8?B?ZFh5MVpXUWNDQm1RbHo5Vk9mYXpLWUh1QUY0VDVtNXpLVFRwb2p3QmNqdDFx?= =?utf-8?B?Rm5UV2dHb1dTWmNxODQwSGhtUlQyR2dPdGJxWjFCZHd2WjZ4RW0xeXZXVEti?= =?utf-8?B?ZUlhMkI2U3NRL09IaGhmdVd3aXFDdmhxV1VBeWRNQlkrVG9SMFFIaXlidVVq?= =?utf-8?B?eiticnJJcURvTE54eThBVlZuL3MwTThFVnQvMlE2VEZvQjdhRXc1bWZMOGpn?= =?utf-8?B?THFTR0FGNitMTXdjZ3hCMVVsbnlwZGR1QVpLdlJuVjFwWWFXZ3h4WE5RczJ1?= =?utf-8?B?M1lCdmhVTnRyUlpGMzk4WlF6VHcrSmpUR2I5MmVlWWp5am5DeVJsOVp0RCtz?= =?utf-8?B?My8ram9kR0pTbWZoM0laU0lpbzB6NmRhOEg5TmRuNGs3RVBSeWsvZjNaa2pD?= =?utf-8?B?Q1NKbzNGMDdmYXFhQjlqQWI1bTlaOWpDeFhoVDl2SXhJSUdoVTlzb2s5UnUv?= =?utf-8?B?eE9XRHdqQm45eFRveW4vNDBxNm1NL1RCc1hIZERTRnFKUldEWVV6Q0FSdWFt?= =?utf-8?B?L3lmQithMDUyVERrSkJVbnlqMkJKRS9DQ3pGbm9WaDhNTzNIbEN5NS9YVFkv?= =?utf-8?B?S0dndGQ4aklZV2ZNRVZFN1kvMEIraGlzQmRpSm9lTFpBOXBWQWJpMVpHWG1h?= =?utf-8?B?Ty8vRWJXZ2tUd0p3RjBDTHZ4RE4zc3NrN2c3VW5NVHNxa2NacTFHQmFLamN2?= =?utf-8?B?ZS9TZWRWOGRrSXZ2VXE0T2M0RjRIY3J5b05wYU1VcVdub1VQQzd2NWoyRE5r?= =?utf-8?B?c1NabUFDMFk3Vk1IOUMrUG96Ynp6bGhTTDNzOG8zRG1nd3dRTEV6alVLT0Vj?= =?utf-8?B?cjJhU29yY1Z1NWtFb3M2Nm1OZmYvU2ZJKzU0T1I0Q3pzaElSdmJDeXBJSllp?= =?utf-8?B?RGRXWTFDS2x0dnY3UFpvVkt2d21WbnZsWTkvNlpWTUFjdzRmamdqZmhrR3R3?= =?utf-8?B?V21KODlkUVFnVFVkZWQ5akJ1L0ZBcHpCL2htSXY4SW5zUFlGWEozVWYrN3dp?= =?utf-8?B?ZXMzOHI1SjhWNXhPV1V4OE1GVVdYazg0aFltMmxodDlIS0RyWldxb3h2TVFW?= =?utf-8?B?NHZvaWxxb0x4ZzVKTGc4SjZON0NsMy9FV3pha0wzZEhrWi9RYzNtUno4ZW04?= =?utf-8?B?NDZGdUJDdDBjK1RmVVB5YXlTRlVOZ2ZlM29velZkVWRFTkg0MGUvOUZRRzhI?= =?utf-8?B?cWVjeVdyOGRPcER1b1JUTGFiK1VGTjBPYWRaZEZ2M3p2Tk0yTlYzMFhiQ0x6?= =?utf-8?B?L0w1MU1HQ3VtRk1kZ0F5VEs3TXZxam5lNXlzNFVxaGI1NVBpTlczNWd3VjlL?= =?utf-8?B?V2pkYjhjaGFOV1BIdFNsRERBUE54Z3lKMStFYVZ6OWdyQkJpbEF1aUEyaUZp?= =?utf-8?B?OTIvSXNzS1FCU3pjTzlWNTJHd0loL0l0WVEvTFF1dmFzcW5FWWxEZmVsaDRC?= =?utf-8?B?WVZNVlRlUmlWeE9wSHgreFRvNFN1TzNxdm1tcmxoQ2xYT0FscXJyaUFORU10?= =?utf-8?B?ZWNkVldZQlczUHhKODMreGt2b21CTDZLaGd1MzRKcExDZ044Ym5HVnhqNEY3?= =?utf-8?B?V2NHY2ZZZ3BsNjBaWUFld3lOL3VJdGE5NjJuWUZvWVVCNW8xYVErdWRBVEhh?= =?utf-8?B?THRGOUsxUXFpM2MwMVVjRGNhVzUybDMrSGZpZVJWR3NhWi92d1VkRldSTW4x?= =?utf-8?B?anV1aXZtYk1ReUFEUkwxNHBkZzNTMk1KNWxWaDU1VC9OR2g1RXlyVUJqZjFT?= =?utf-8?B?TzF4UmtGWmd1dG9VVVJ5OERMQzhnaUNQbFRMb3AvWFExbGtFS1FIZDVmVDVq?= =?utf-8?B?REduL1Z2aXBwZFA4T0J2QnJ3di91U1B5WW4xM1V2ZUJOYmhYaDFUbmFzNWJZ?= =?utf-8?B?L1ovSjVZTU55SG9vUjRtS1ZydUs4bWk2VFB2d1FDRWQ2R2Ixb25IUkdlRVdU?= =?utf-8?B?c3V2UDVidzNFZTRTeStFWklWMmxXYUxVQXRrb09NYzRUTmx1VXZDc0VPeklQ?= =?utf-8?B?ZFpaTWd0MS9iTU9oNERyR1poN3pxUy9wL0huVmVmZFJkaDFvazlpS091VHFQ?= =?utf-8?Q?/SBJirwcIF3URsDk=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1c63836a-d14f-40fc-b2c4-08de51c920f1 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2026 10:55:41.7639 (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: N1JcuOSJ6Mfbq/F3wX8QvT504dhGGRV1x5ZoREMmQZtkwtPUq4i9r7k1cKtr67kA2TmrobUs0rYxKTYyuaaHansXDcpa+xSK0MzQIPrru8k= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA6PR03MB7830 On 12/01/2026 10:47 am, Jan Beulich wrote: > On 12.01.2026 11:40, Andrew Cooper wrote: >> This only exists to have it's type taken, despite there being a perfectly good >> concrete type to use. >> >> No functional change. >> >> Signed-off-by: Andrew Cooper > Acked-by: Jan Beulich Thanks. > >> --- a/xen/include/xen/nodemask.h >> +++ b/xen/include/xen/nodemask.h >> @@ -67,8 +67,6 @@ typedef struct { DECLARE_BITMAP(bits, MAX_NUMNODES); } nodemask_t; >> >> #define nodemask_bits(src) ((src)->bits) >> >> -extern nodemask_t _unused_nodemask_arg_; >> - >> #define node_set(node, dst) __node_set((node), &(dst)) >> static inline void __node_set(int node, volatile nodemask_t *dstp) >> { >> @@ -215,7 +213,7 @@ static inline int __last_node(const nodemask_t *srcp, int nbits) >> >> #define nodemask_of_node(node) \ >> ({ \ >> - typeof(_unused_nodemask_arg_) m; \ >> + nodemask_t m; \ >> if (sizeof(m) == sizeof(unsigned long)) { \ >> m.bits[0] = 1UL<<(node); \ >> } else { \ > Hard to see why Linux would have introduced that either. (It still has it, btw.) Yeah, it is a bizarre construct.  I only noticed it when trying to do some more typeof cleanup. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jan 12 11:10:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 11:10:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200088.1516091 (Exim 4.92) (envelope-from ) id 1vfFo2-0000iv-Ip; Mon, 12 Jan 2026 11:09:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200088.1516091; Mon, 12 Jan 2026 11:09:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfFo2-0000io-FL; Mon, 12 Jan 2026 11:09:54 +0000 Received: by outflank-mailman (input) for mailman id 1200088; Mon, 12 Jan 2026 11:09: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 1vfFo0-0000ii-V3 for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 11:09:52 +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 35fb855c-efa7-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 12:09:49 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-47d6a1f08bbso25189355e9.2 for ; Mon, 12 Jan 2026 03:09:49 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d8636cb0dsm145224695e9.0.2026.01.12.03.09.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 03:09:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 35fb855c-efa7-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768216189; x=1768820989; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=nm8iEbogXW+I4NZ0oLtTvYx6OEt6tCFiFjB53NtPnLY=; b=BegrDdt2bDOv8MUQrIn5SPN210hUsqBvHX1Eh0syoa/coQdU2+6gw5poRMRHrfXo/1 th2FkaNVD2WLngYuCzBwHKLChQtISvxNoc5ARO4u5t1ckxiNfQ9f8d1uERwZTA5z4B8C 2saKh/kucBQlwTTJHPJ8z90Z5Dn+UpNE4+DnEtYeNkpjLDYannZW4oqnCeJZNwNVixMJ 0U8tQ5nAnQtE0ZKriRc1sAWoa+/AvY9SY34hU/is8jcHNH9zLsfDZuMHn7fJjGZpB1PC FPKmXTBekRPw5EgvPmI2SIlM4L9uDgTgoPu49GuCI1gJRKiLvFRJPhUQpb4/rpiNP/+j 0FPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768216189; x=1768820989; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nm8iEbogXW+I4NZ0oLtTvYx6OEt6tCFiFjB53NtPnLY=; b=JdMfRf9KlAJO4VYUcKLkuLOb9Rhft/GuFl/lq3VfZC3BtVb/dX/67NBV/nN1QtKt4E sh2r5CbcUhViixgYqIxvzAqoR39BHV01O+1PXCeO994KvvDLAxPTobIjtCkTgAbsy9sd chdO/xpt3N70T7+lAO0s3vlPWsF5A3GM4wy6Ek4wS0e+VO2Ldx/V7PvS2aOkRlJOxfEs UTdkE7FgCFciTXAQwggxluKRCTSiwloz7Oh3iN8yDli8lQPQHsmChTrvcnMhFRQyQc0Y dUYahUH+w+j25Uh+HwixxeMKU6mm927CvYHVw67du31NoMXEEwieS3o7cy3M5xSiX9bl fJow== X-Forwarded-Encrypted: i=1; AJvYcCXyw8R5rw3hZpINraJ5WUDEmr5o3F9OENvOY5ed/rTUvfN+htzUXCwyAMbCdp1EMryeoQNDpES1M6Y=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz6NwhRogfdalEd0F6YSFAZgOzDIM/sud22m5kshJSYiPLjRKM8 PP/gsCBuCOOEIaFVpdHcfC2aMPw70W8eXMqKnYTuDmkLcJMfL1XkDoh1b7BPmJaFmA== X-Gm-Gg: AY/fxX5Y+LoHeizFBCooCGp/7h6Aoad0exqqxoO/j6ZLNC1jZ/PkhbN9c1MPksLUrjj u9prYk6ueK2iI2t0wTvmyNUCpFjoK/P94K34HWL7N5lwBoix0bQpitkQU6t10+4vjWU/pN+Emdl jxVQzyc5WRGJf8zWkunpZ04WOW1si8T5kRRDJheCMTv1x6nBWywnmUzEOV77A409M1m/F1hZIya 7TuI1gghgYkLonLvRnRFP1kq4liUDLh0U5lIRg2F7J4ZN55uNqmt6QDXKf+clSfwqmKTnLWPiDD mt3ozA8xHJU1OgL4ruq9NHT7hQlO301cXxPaJPtAiOfdS9vGKEcEXRaF1dZl9uyp3O+h0nKoNv4 Bre7jcWObqNEazEq30VqYdIhBtEpHHdeleTQxiQ/FqhEHRLL66C13RDYpdnZGSxGPXYj8P5PQNJ rgR/TmCvMQU+MJVgkn2XaNf8xi/LHD4wNyEVaDrliqzF0nGmFDNkYyxzIeFC2t3Wq4/3Ro2kBir 2E= X-Google-Smtp-Source: AGHT+IGHyMrWlUenyvhRqmDx19vLYJnz0K3B5KZMnIRr82BYzqLLMKrSMvqjA6Zw/IV4UlYhjZDMRQ== X-Received: by 2002:a05:600c:8b33:b0:47a:81b7:9a20 with SMTP id 5b1f17b1804b1-47d84b19f5emr179483225e9.9.1768216188803; Mon, 12 Jan 2026 03:09:48 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2026 12:09:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/altp2m: altp2m_get_effective_entry() should honor ap2m->default_access To: =?UTF-8?Q?Petr_Bene=C5=A1?= Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org, Tamas K Lengyel References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 09.01.2026 19:28, Petr Beneš wrote: > From: Petr Beneš > > Commit 7e5b662 fixed p2m_altp2m_get_or_propagate() to use the altp2m's > default_access when propagating entries from the host p2m. However, the same > fix was not applied to altp2m_get_effective_entry(), which has the same issue. > > When altp2m_get_effective_entry() prepopulates a superpage from the host > p2m, it incorrectly uses the host p2m's access permissions instead of > the altp2m's default_access. This causes problems when the superpage is > later split (e.g., when setting mem_access on a specific 4K page): all > 512 entries inherit the host p2m's access rights instead of the altp2m's > default_access. > > This issue became apparent after commit 50baf2d, which causes the host p2m > to use superpages more frequently. Before that commit, the host p2m > typically had 4K entries after VM restore, so the prepopulate branch was > rarely taken. > > Symptoms include memory-access events firing for unexpected pages when > using VMI tools with altp2m, particularly after VM resume. > The issue can be worked around by booting with "hap_1gb=0 hap_2mb=0". > > Fixes: 7e5b662 ("x86/altp2m: p2m_altp2m_get_or_propagate() should honor ap2m->default_access") You didn't even Cc Tamas, who I think once again will need to ack this. Already with the referenced change I didn't quite understand the reasoning. However, two formal points: Please use 12-digit hashes, as demanded by sending-patches.pandoc. Plus I don't think Fixes: is quite right here. That earlier change of yours didn't mean to do more than it did, by its title and description. We relatively recently introduced Amends:, which may be a suitable fit here. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 11:16:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 11:16:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200100.1516101 (Exim 4.92) (envelope-from ) id 1vfFuk-0002HP-77; Mon, 12 Jan 2026 11:16:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200100.1516101; Mon, 12 Jan 2026 11:16:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfFuk-0002HI-4L; Mon, 12 Jan 2026 11:16:50 +0000 Received: by outflank-mailman (input) for mailman id 1200100; Mon, 12 Jan 2026 11:16:48 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfFui-0002HA-U5 for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 11:16:48 +0000 Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [2a00:1450:4864:20::434]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2f1a59a5-efa8-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 12:16:47 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-43277900fb4so2149775f8f.1 for ; Mon, 12 Jan 2026 03:16:47 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5feaf8sm38518550f8f.39.2026.01.12.03.16.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 03:16:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2f1a59a5-efa8-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768216607; x=1768821407; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=QOdR60esiavkJ9vN4GBJxy2Nm6qULhfC+ajga9F0Mlo=; b=dPLytwKFTPSg/TNnVb/w7T2S3pGW2zoI6BJWd1f0o3klr2FzhGMbj1XtuzcM+U+Z3u KMal3T/XEDk0fl5RFKqGdvWthCoMs1oHePGw/wNR1FLUOholQYzAA4BdK8D5jlkdggcE oTw89NAOlx6YHD88rPOaFDJ5dCpvlLUKE4tQ0jJT3Xu2l1sxxKTbyDpGhPYhzdQER37z sj417zYCMwJPa09BUmzCmlWfEchz6ZgEdwdzqZ8ZpyHSdLBj/ZqnjIvxcvkUwTdveBen nEBhN4MYj/giid7KLhgEAvG9VpOk8fq1U2Ast+GPvjNTEz1RO/0tirvTHfA5f5R+rrYX 9XWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768216607; x=1768821407; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=QOdR60esiavkJ9vN4GBJxy2Nm6qULhfC+ajga9F0Mlo=; b=AhxLwqZ5gmcn7t4UiYIjbCEfRg0qtFoYambhVTkae9+0w1LavIksiHPxB3yp/yNxrZ xOhH9vRoV/ZSBFz0oZEmKgVwGuzrggBG9ZGqqG67tDz7CVJLsfrg5pQ/N8I2g+zclK3g KXtyZCKZcio3s9uedByohIOfui1wTzwJPZpN6whY8wv4beYfNgRQbLRdG2xUs1/K2CqW MGMGzLpBFx3+CWxEzOOfDxz5DGHEqkz77/OKxn6OlHVwxDIFaI1Pdc4KorrAQmPXp+QZ 8h87WqCWIPL4wEieClh7+YfRzov6IW9ct+Q9vxZ7zkttU+Dj7iavwLSAu8VPPwd9t5+2 0hKA== X-Forwarded-Encrypted: i=1; AJvYcCWCTTKzFa9fNwkaCmM419oOllT1XGQJ1r2jIKkduLUD1a4WVLzokBnBcdJr8QyHrBD4Nd0CkRjjH5c=@lists.xenproject.org X-Gm-Message-State: AOJu0YwK2wANPWkFjoSWhWScoC1+F/781ZlCKyJpV1NeKOZjRlFOFACq Dq3YdyMoRJ8KoLbTDZGJQmeDN+zTevMwEynDbHoL3w6s+9DKWm8jHFZTbdt8BK7ZRA== X-Gm-Gg: AY/fxX41QEO6ZD3cZ/aVFQ3Qn5sXJ2UmmCGVdrmdIfVnWzo1RO48cw3iff41u91HUHX YUPlQ+X1N/Xb+++j1GCxRNL/FgUsRmlihoLiITP3lTM3L5kFSib+vgF9xPb/Q/CsIMMyBgCZC5X GrB9k+jVyeJx5lzVUpHT5138j2HyOxEtkyf+zjlLiUBOlgSToe36uh2W3XbCXZwy3cp0UMvP4bC slg3EgIMw50qNcNA/KN1obF6N6B3eR6BjiuvQY7CJRcv68ANNBzPvG14hNMq+IWDkpOZvZHpTuM utLL37dqPrTtSTLrRBrwTwPV/MCVSSFruB1stemcOQQKmfP3wIkbuWYdoi8NjacIQr5mBmBT3A9 beQT/33dJiiGiSg7owkChZ0ZUHPJykpM/nWOmLOP46q19gYwMVbVZ8r3eSOUsy4s2++XJ3hAlFq lgwF5v/gUZQ7jj9KIIOKjnZ1YlIrLDhRW68QnBFX4/lhjlGjA3u3L8xf82th+9xHNHt9oDXHHvG kzwMh2xAOm0wg== X-Google-Smtp-Source: AGHT+IGlHb658LVo76iKA7O1iDQnJyY05JmTpoaoPyxSCZKIawAnrCVyRZkKbwBOZXX/I+DG50G1ng== X-Received: by 2002:a05:6000:438a:b0:430:fdc8:8bd6 with SMTP id ffacd0b85a97d-432c37792edmr21420932f8f.31.1768216606687; Mon, 12 Jan 2026 03:16:46 -0800 (PST) Message-ID: <2badbc33-f78c-47d9-acef-9383a5aa3387@suse.com> Date: Mon, 12 Jan 2026 12:16:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/4] tests: fixup domid make fragment 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: <20260111041145.553673-1-dmukhin@ford.com> <20260111041145.553673-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: <20260111041145.553673-2-dmukhin@ford.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.01.2026 05:11, dmukhin@xen.org wrote: > From: Denis Mukhin > > There can be multiple test harnesses per one test target (e.g. harness.h > and harness2.h). Account for that by further parametrizing existing > emit-harness-nested-rule(). Multiple harnesses within a single dir imo likely would share headers, but use different .c files. Also, why would dependencies on headers need recording at all? The Makefile includes $(DEPS_INCLUDE), so all dependency concerns should be covered (or else the generic machinery would need fixing). Imo all of this wants simplifying (dropping?) rather than further complicating. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 11:18:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 11:18:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200109.1516110 (Exim 4.92) (envelope-from ) id 1vfFwW-000344-H3; Mon, 12 Jan 2026 11:18:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200109.1516110; Mon, 12 Jan 2026 11:18: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 1vfFwW-00033x-ES; Mon, 12 Jan 2026 11:18:40 +0000 Received: by outflank-mailman (input) for mailman id 1200109; Mon, 12 Jan 2026 11:18:39 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfFwV-00033p-5C for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 11:18:39 +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 706a21af-efa8-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 12:18:38 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BL1PR03MB6038.namprd03.prod.outlook.com (2603:10b6:208:312::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Mon, 12 Jan 2026 11:18:34 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.005; Mon, 12 Jan 2026 11:18: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: 706a21af-efa8-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=OaM6qaGFDXu6WRuE7hbY03NU1HrmQm7QlnQIe5qKKE9H90Lj5MG1oSRwtrGqMr0mY8/eZcCdIRJjpQxBSHVn7ptkX7+gECmm/NoqLnGzDyeLKb/0+YI8VkR5tGNBdTPayMTaUvslECrjOaVwj0m5lb1nBTbyQFTnBDMmITk/scOXoS5mRcPkV1kZAZOTCW8DjmVczDrDm+bUGmzwO0c4d45QwK5u11B2S62DwXUTpBtzYi7huNfhj6fHAKJhI5O+kkI2RAhZbQmVWPreBRkiLn2coicDEJ6+eisph+ml0r0cdoctdYPpaMyTN0CIKpx05x9weF/3NFmKTNQmbq8aZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tD9iY4rSE7EyT600PIX6S3WDj8tSiSxjNJoP/AQQt14=; b=Sic8I8A2M3iVvACiKja8iuRYBGAEiSCLZYKF5kbplr5oP75uH5b88cD5j+o8+EXR9eGbs+rSgSxjVQgwN6UZR1szqze4vFKVvEPB3oDCYiY6gFOtvaeZTbJS62U0JhQy5XgwbGqEOTPZf9FAMYKOiBbqom8+vUbgsC0WcRp/E3BabiVSssLETL4L3HnUc2BHEvAXfVI1cf4mbfhoaDLaialMXaHuI/yViJat/JcIoWHSMvoCFD5sP2MGZ8yJZqygiLdYlHUqpVoWL7Fd0eQqTEFGoxm9sByHG9/3k7HM0kqIXfv3bOD1Eef6uoLfNQr8/TROeQhXUG43MidtbkrFXw== 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=tD9iY4rSE7EyT600PIX6S3WDj8tSiSxjNJoP/AQQt14=; b=kBJ66QnowHc4EEKLrGOEakZq/PQCxmNz1w6iD26kcGnRxSiFk3vnMETDkpJp6apehxkAXmlSh3dKMTwIyPDVKr3Vwe4iVdHGqkbfg6hHDLarq/FzR60SGox3GchwPI7Q9OerulQ360pcDQamHYFqF/pnMyZI3C7QK6zJYFVRHNs= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <1916d0a7-ff9a-49f1-8564-2767226fca9c@citrix.com> Date: Mon, 12 Jan 2026 11:18:30 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org, Tamas K Lengyel Subject: Re: [PATCH] x86/altp2m: altp2m_get_effective_entry() should honor ap2m->default_access To: Jan Beulich , =?UTF-8?Q?Petr_Bene=C5=A1?= References: Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0409.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:189::18) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BL1PR03MB6038:EE_ X-MS-Office365-Filtering-Correlation-Id: 50af8d50-f9a9-41f3-cf0c-08de51cc52ec 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?Q1dTTHNlOUhiTmVqTTZGSFhIdTdTbnZvOGx1bE5MS3prTmplMmEyVHFMRnJW?= =?utf-8?B?Mm02RnFSNE5XQ0ticHExR0J1OCtkcXArc3poNlNpNXdCMy9PelJWZmdQME5r?= =?utf-8?B?Z2pCcGN6SlBxbFBJcU1Scmw3TGxuZ0pnN3lUS2hXV1U4bjZMdlNVK0UxNWZv?= =?utf-8?B?NDhocEViWTg4dmlQQklSQ3h4NGZUcXAyN3kwWTk2ckgxQURZRHh0NlQrWHFr?= =?utf-8?B?UTJLdXJNT0ZHcFN5NjFLMlIyZ3pkNktra0U1YmtpczBzMUtIeldLS3ozeFJh?= =?utf-8?B?M3h3QkVLZHZyTkRkVWxRMHF1M2hTZEM5S0hlVy9oSkd2OVdJVlRIM3lla1kv?= =?utf-8?B?QkVRSkV0TnB6ekpQQmpobVBrcjVMSTdmSmNSSnAweldUaFJ5cnhXMlF2OVhx?= =?utf-8?B?ZEtyK1BUM090b1JSSll5KzFVRHpoRXZtOW1HTGVTVEJWQ3dSTmRiS2l3dTZP?= =?utf-8?B?K0QyNFNZdjlUcmJOd1NrVVdxdDc1OWN0emVrdXU3YWoxMDJyQnlRVkFScGNv?= =?utf-8?B?QVNHM0xRc1lCanJPT08xQ0dBZjRlRFgwL3ZESUlCVmsvdVFEeWk3UWp6cmxC?= =?utf-8?B?dDM0S1QyMkhNcGlVT25HMnYyNUlKV1hGR0x3bGIyeFF1MVNYajFQRUp5dDZN?= =?utf-8?B?d3BHMDZWOVpsTk9mY1IzRmVlZ0c2NEFVSzNrUlNMOUIxYjBrSnNERE1UTGdy?= =?utf-8?B?MzhuaUlzaks0SHp6NVN4djlCdFY0VmdPM1N2SHk0OWZPeWtudU4wQmYzQVoy?= =?utf-8?B?TDFodHVSZlBQUndsa3hDdzVjZ0RRYTFIbnVxTHdYOXBmR2JVNElCSjJMa2Fm?= =?utf-8?B?ZnJmQVpvUENYWjRhOVU1dTlXbjFMSkp3dWpwYmtpZHhKdnE5Y2R5V25XVGxT?= =?utf-8?B?aW1NdWVVdHhxbVZydEdPWnF6VWpydkU3bCtTdWJVOU9kMUwzUGtPVXd3TFBq?= =?utf-8?B?eWFNS0pvenQzVDFlb3J1OXpTdDhUQnd5NG9UT051dHhFekZlNHViWXlSK2s5?= =?utf-8?B?UnptQW1JdGh4WDR2ZlcxZmlGdUNjRVdBTjd1aWlCamhNdzJRbkxlRGhiVVJR?= =?utf-8?B?WitGcVVWckhCYndRTHBuTWdhblovT2NuWDZacEFvM0ZRNWl0ZUZpMFpwdlRV?= =?utf-8?B?Q05XVWZpTnpJTVV0djFoN29LV2Rwa3R5WlJPT0lyVzB0R04ySlF6SXNPOHo0?= =?utf-8?B?NExUc0RrWnF5Z0o5S0FWcTlRTkpVdmdLbSszZTdEK3hqb0Ric0lSZ2k2Z3ow?= =?utf-8?B?KytvaUFYT0JVZkpBbEhwaGdTQXZlN3RLN2NhN1RwQnJzWGUrcWhYa3BVQWE3?= =?utf-8?B?N21DWXBFUnFMN2hpUmkzZHRWK2ZtZXE2NnI4UVF2UEdYM0l0MXlxWnJqYW1v?= =?utf-8?B?MmpQL3dNTkhhZWkxa3hudkswNC9pYzF2eElLZUJadDBkdnkzdnQ5bGN4QWdY?= =?utf-8?B?VXdKSCtlVXBNRFk5dEFXdWN3RUhCNUU1ZGxJbU4yOEJqVS9OZ3JjR3g4U0xG?= =?utf-8?B?MHFKMFVXMmREQnJQR3E5czFkRXdaZGJxTmJSVHBpSnBwVDBtREJBT0txT1Iy?= =?utf-8?B?SjduZFFJYm0waTJMaXNyMk1OZWFxdG8zU1d2emxpVm8zNFJjMDJKS0pSa2I3?= =?utf-8?B?OU5yZDY2T0dkc1JmL1hBaHAzMk9QYm5CN0FaU0RsSjg5WVUxeTlSenREZ3BU?= =?utf-8?B?cXAxTngySUVrQ3BYYzRLaUpvdkVCTlpqTWlnY2xXdlNMMk5wUlBDaWM3YjlH?= =?utf-8?B?RnVEN1NYNkJzdXQ0MXZjd04zejFDbFRhQWQrU0RaWTIyRjFCUEIwSjlUVGQ2?= =?utf-8?B?WnFkVU5LZGQ5VUJtVy9kclg0ci9kOURCTUVuVU5FdHprY3lacjNlbnRrdGF1?= =?utf-8?B?bEtFK2FPVy9sd0VLUGhBbmJ6NFpMSDVCaENnU0ZUYXNPOHZYR25iVHFaclBQ?= =?utf-8?Q?S9BGYWe50FqDPnM3BJ8z3XdYd+tc5d40?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YlY3ck5BYlZwdFF2S1N0em8xUldUbHpqMVp2T2trdk5oVzQxaVA1RW1VaGQw?= =?utf-8?B?Q3hhazU3VlIvV2JmNmNxZ3BXc3RtUWhVMDZyYzhiQkpaT0ZGZUlwaTVKUkVm?= =?utf-8?B?T1A5c2Fmb0s0aE1Lbk1ycG1xWGJxMnpIT2FXanN0ZlNZaGJsWkE2b3QvKzlk?= =?utf-8?B?eWZzeHdTbFdubFdsZ2pPU0Q4NzkzS2RNOXpIUzVSa01yNEcrYk1hRFVBdmlz?= =?utf-8?B?VDlMQXVQa2lMM3M1ZWtXRnZYaDVyby9mSnB6dC8yYURndU1HVDN4ajVEcmE5?= =?utf-8?B?NU16dWN2d0Fma0JNcXh5aHk5UExkV0l6N0YwK0tra0dBR3lrc1lYc0hRWmxS?= =?utf-8?B?ckRPdFBuOFdESHB6Y1JzZDZDNC9kL3ZqenFGL2xVeU81M0l3Y2tWTlZxMC9u?= =?utf-8?B?ZE9Kb1A1SS9iQWVOcGVnZlRFVEtWUzVpQ3k2bXhxODVWM3AyNXAyQnUxVUpz?= =?utf-8?B?M1Z2eEFNRVFoeDJOcVdxdDFUSzR1cEM5VUtXcU5aRVhjaUNlT3RHczEweVFM?= =?utf-8?B?K3ZrMU44WUNRdityRUVsK0JqaFdEVUJ1VUk1bWVkSDc5S3k2eXpKWUJHZjdN?= =?utf-8?B?UGdLdy9udzZYL3RrTkg4eVdUN2w1aXBtVm5ZeTRacEJ1cnV2cWRNdmxMRkcx?= =?utf-8?B?UFhnd1h1aWloQm1sMzhtVXc0ckx1bWdDUDByazIrQ3NMOUNCN092NVdrVnZR?= =?utf-8?B?ajZrdW41UkZZTXA1WkVDNkZzNW92RE8wR0ZOZUErSDNlT1ArSm1ManlTN0FE?= =?utf-8?B?cFI1aHFoaUlZYjdvSEZ5SE1KTjZtclVtM21wTUVHc3RwaXVGK3ozQmZ1N3Y1?= =?utf-8?B?KzQrUi83YXlwVEFsVTgzWVJoZXRFTXorUWdsem5mQ29oR2RYOElJZUxVRGNL?= =?utf-8?B?N2Y5TlZQTHBEWmE5U3lVSDUxYXBBaWdqTFZOZ0U2T3JNSHFWb21YdG9JWFYx?= =?utf-8?B?UiswdWlHb3pQOWVYS1BJWFhldHJObFJKTTd6YmpKSDRxd21URzdoWmZrQ1lS?= =?utf-8?B?NkxJUXUyMEN6bUZZbldSVWJjZG1FQmxFWDFLQWMxN09EQWRHSXYxc2pPK2xZ?= =?utf-8?B?MFpUT3pLSUt0bmRmSGpud2IvRzdWOTVKSEtOM2xLZUFHamZDSERzdmU3OEUz?= =?utf-8?B?cjQ5ZEl5KzlJOVpLWndmdUliZENCZ2JnQ2N5Mjc3dUhjRGRHaFc1cTRpSmNl?= =?utf-8?B?V1pPZkFnYVYrWW15Nnh0SGhLaWJiTWhnaFliMisrcTJaeGxaTmd5YldMUjZK?= =?utf-8?B?d2MzM1o5Rk5laVN1UVhybUxPNllzaG5oMDBsMkxQTDU4aXB6SXdtNVNvV083?= =?utf-8?B?OHJ6amRzbW9mTlJ5S0Vkbjc0S1dOQmxKNWFZdDc2dVhBVkVac1VXc3FWSW5H?= =?utf-8?B?aDVzYk5yWi9SSCtuU0tHZ01WeXNmQWVlNW5qWjBJTTF1TWZ2aTNCUG1EVXhZ?= =?utf-8?B?cHhtR3p6VHQzbGdQRWFtSjMyb2VmZmt0eW1OTlpkbDV6TnBOK1FqWnhXQjY0?= =?utf-8?B?NkJnQlJpTmpoRFpyZ3AwNmQ4dUlWM2hISDNEYnJ3MFBJOG91djlhY1BMdjhj?= =?utf-8?B?WXduREkwc09XZjgwWWpMYll5VFZ3U0F1NEhoamFxMG00NHFua3JGejNTRHgy?= =?utf-8?B?ZGR6dUNTclRtLzVBbEtPcTBUWG55Y3p4eU9rYVplQ3ZwRlRoakkvSW1wTjhT?= =?utf-8?B?Y3prR2p0UmExcXp6VGVYYmJNNVlVcVczSG96Z1NmNWt1ajBDWVoyM1pCZ3kv?= =?utf-8?B?bXFhNENOWUtlTFNzOXpEOGhPc3lPNFlRajJ0YmVLcjFrcXJHRnBXMklHSjdX?= =?utf-8?B?SmN5dG5MUjhXaWwyWkhwNnRMN2tCZmxkSTdySFp2VXZRZ296M0daN21vd0cx?= =?utf-8?B?QmNWdThhenF5cW53MHg3LzBPK2VMU2lQTjJlWGRsNU9HMHZLc1REQWhBNUFX?= =?utf-8?B?VytQdDlHRVkveC9OKy8raHpnNWI2UDJ2ZHNRU0lPbVNHMDgzbGVPWEtaaHlC?= =?utf-8?B?R1NORTg1cHd6cVhtdjF1NU1Qc3EyM2pTckM3aVYyQWVQUHRFL3FSeVkwa1NX?= =?utf-8?B?blFxMWlTNFNsMlhJK0NQa05rMGVFOVhjMm94aWkxZ09NQXZaTjBuSlg3TFBC?= =?utf-8?B?M0J1VzFXckROS3N4REtFcGdpQzNzYXp6K3VHdHRKaHgxTUw4YW0yVVhycGRH?= =?utf-8?B?Z0dlRjNERXV5M0xwVzNMMWtVRXBPSlA3L3ZKZFJ4L3d0Y0x2Y044MXlJT0dT?= =?utf-8?B?ZDlJbC92OWk1anRIZi9oaHVid2xiM0ZQcTgzU08xc05TZDEyVkNBa1RYS21q?= =?utf-8?B?bHFmMVZiT0U5clNuSjRCaGl6UHdDN2tZTTJOMG1VQXRQSTgzTUF3QT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 50af8d50-f9a9-41f3-cf0c-08de51cc52ec X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2026 11:18:34.0265 (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: YKR5+q4xVktAiQBwJq/aP/LXO0Qubx4rcaY3JAABs6Iqbx/QG9RdLfTr5NRzA/0zNI538NM4YuT8GiQ/oh9fFlRI/+ixcAWcS22sEbfNKlc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR03MB6038 On 12/01/2026 11:09 am, Jan Beulich wrote: > On 09.01.2026 19:28, Petr Beneš wrote: >> From: Petr Beneš >> >> Commit 7e5b662 fixed p2m_altp2m_get_or_propagate() to use the altp2m's >> default_access when propagating entries from the host p2m. However, the same >> fix was not applied to altp2m_get_effective_entry(), which has the same issue. >> >> When altp2m_get_effective_entry() prepopulates a superpage from the host >> p2m, it incorrectly uses the host p2m's access permissions instead of >> the altp2m's default_access. This causes problems when the superpage is >> later split (e.g., when setting mem_access on a specific 4K page): all >> 512 entries inherit the host p2m's access rights instead of the altp2m's >> default_access. >> >> This issue became apparent after commit 50baf2d, which causes the host p2m >> to use superpages more frequently. Before that commit, the host p2m >> typically had 4K entries after VM restore, so the prepopulate branch was >> rarely taken. >> >> Symptoms include memory-access events firing for unexpected pages when >> using VMI tools with altp2m, particularly after VM resume. >> The issue can be worked around by booting with "hap_1gb=0 hap_2mb=0". >> >> Fixes: 7e5b662 ("x86/altp2m: p2m_altp2m_get_or_propagate() should honor ap2m->default_access") > You didn't even Cc Tamas, who I think once again will need to ack this. > Already with the referenced change I didn't quite understand the > reasoning. > > However, two formal points: Please use 12-digit hashes, as demanded by > sending-patches.pandoc. Plus I don't think Fixes: is quite right here. > That earlier change of yours didn't mean to do more than it did, by its > title and description. We relatively recently introduced Amends:, which > may be a suitable fit here. I beg your pardon?  Fixes are and Amends are synonyms.  You cannot use them like this, and you absolutely cannot expect contributors to know your personal interpretation of the words. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jan 12 11:24:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 11:24:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200119.1516120 (Exim 4.92) (envelope-from ) id 1vfG2T-0004f0-4L; Mon, 12 Jan 2026 11:24:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200119.1516120; Mon, 12 Jan 2026 11:24:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfG2T-0004et-1J; Mon, 12 Jan 2026 11:24:49 +0000 Received: by outflank-mailman (input) for mailman id 1200119; Mon, 12 Jan 2026 11:24: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 1vfG2S-0004en-7h for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 11:24:48 +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 4ce0658f-efa9-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 12:24:46 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-47795f6f5c0so38135825e9.1 for ; Mon, 12 Jan 2026 03:24:46 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d8715b5d9sm133081265e9.5.2026.01.12.03.24.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 03:24:45 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4ce0658f-efa9-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768217086; x=1768821886; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=JPecrGbU0W+UNpV7R2wFfYgDjoCPL04H5/Dm0sZMGO4=; b=egH43rmLcpAuWR2g6VI1MMRDRajEFpt9ohZm4I/If6SQu3jZMWgNCcZKUqFvffwmcg 1QWmoy/KVScbL7F8zO4E5UyH+Io8dNQ0R1O7Bf4Y3qIr93g1K8Qs7/Nh64Wplv7iHaLB IqCAPH3H9zlCzLDH2yXuAykfcrnMb1b7bnemWbffyp4sHhv7oaSFF7vH2etWtHO2jgk5 SelpO4E+rK+sO4738ueW8AvYDqBmF/5I4kH6r8/xa9O7NkMqh10W/oC75AcK3B/ZDp4e nyXrfKTCxyVpL9EaPC/FzBh/UcGfOahGNlx/7Ag5Kwg9d6ycoKfbivv3E/VwECIT95tB lzYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768217086; x=1768821886; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=JPecrGbU0W+UNpV7R2wFfYgDjoCPL04H5/Dm0sZMGO4=; b=VGik+JEXv9h3d1ZrEXkwqSdRS21jVN998+rMkWBfrycE4RieTtnJ9U/6dcfs0kku11 ol13p9WSC+RnQ6IhS6lGTHl89OvEtJZaUESxfM0QEJwRbU6X6ehEjeHzfirYlx8zN8n4 0qgCu/remPAw7b4wqR/PnKnZDplyKlpqaVlgGJ/gD+rLOaFWIVe14cKb8UmWJdAOlGcZ X1fyv1nvehSCyherxcWNvG76rxQU6O8S/81rOANfNFfHKJRtJ//hORxutCh12DYetB6P XW7Ms2UIGcjJtDmgD9MfGlfxc30ZEtqjW2yQcHHYUxHc34QvpDLKVi4QyJ7Z0B6C00la pYWA== X-Forwarded-Encrypted: i=1; AJvYcCUOOBETez89K+fT4w/fo5gVREPCMN6wgy1z7DU+/XbKlAt6VVPkzwAGFhHYbMIict+0gLIX2l6dpGs=@lists.xenproject.org X-Gm-Message-State: AOJu0YwU62+pezodPwiQYCZmdOjGoiDsl3W7JtvlMqG8XMyfU4XTHJ33 cH0yA6DStIRwLFLQs65ZdidOwq7RafXxbW9KKfDzOUVL7oYTk8bwgZkYVDGXpRRx0Q== X-Gm-Gg: AY/fxX4Dq3Im+MfFd1UG8SOkGonK5F6fn6o4WbC8riD7nr98vJLv5Xs3F7t/pT6y13s mIPXK1ZIGPahFtjdZnXOFNvPfWSgMzBZAe7/dILTcOv1amF+lp1GWDCsNLETUNzmheihp8gktXx 00oPRSJ3qMQoJStan/v38yRv+EonysQ+C/S5A38SINlmIrMVYOTIrELyhpS5WnzZ5TW09QSMkYe Z2LE7mQsLoDapgkIQ/PT6J43pKei1+Jwqs6O+AMy+PdV6FfdFnUxblyvsUCRxgGfcpy2XXqsMwc AES/UrKlhYzsHF6nJGBIumoTO0lDrsh1bfnPRBSFoS5neHKdhZzkihK0OcdwPKmYCrG1wQC4+yE wdHeddQyh4wflLtXGauGInbmGFu9k60MU8FMbQPvJDP7f6/mK30Xi4IFgoeik2k6PRhEJHSIW33 0Sk7ythyPvyrpK6RPETAnnDRiyqVd6bu9B78qDj40umtLddVWYoteMkwJi/IfMSvA2IG2gU1AP+ 0Q= X-Google-Smtp-Source: AGHT+IH432z5H5gsj5zkDnT/1Jxoo9DGAL4oQA+m//LxTQ/HmvyZq+/OZMUKDD/tPCZskt+2vVCi5w== X-Received: by 2002:a05:600c:a314:b0:479:3876:22a8 with SMTP id 5b1f17b1804b1-47d84b2d285mr181768245e9.16.1768217086164; Mon, 12 Jan 2026 03:24:46 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2026 12:24:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/altp2m: altp2m_get_effective_entry() should honor ap2m->default_access To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org, Tamas K Lengyel , =?UTF-8?Q?Petr_Bene=C5=A1?= References: <1916d0a7-ff9a-49f1-8564-2767226fca9c@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: <1916d0a7-ff9a-49f1-8564-2767226fca9c@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12.01.2026 12:18, Andrew Cooper wrote: > On 12/01/2026 11:09 am, Jan Beulich wrote: >> On 09.01.2026 19:28, Petr Beneš wrote: >>> From: Petr Beneš >>> >>> Commit 7e5b662 fixed p2m_altp2m_get_or_propagate() to use the altp2m's >>> default_access when propagating entries from the host p2m. However, the same >>> fix was not applied to altp2m_get_effective_entry(), which has the same issue. >>> >>> When altp2m_get_effective_entry() prepopulates a superpage from the host >>> p2m, it incorrectly uses the host p2m's access permissions instead of >>> the altp2m's default_access. This causes problems when the superpage is >>> later split (e.g., when setting mem_access on a specific 4K page): all >>> 512 entries inherit the host p2m's access rights instead of the altp2m's >>> default_access. >>> >>> This issue became apparent after commit 50baf2d, which causes the host p2m >>> to use superpages more frequently. Before that commit, the host p2m >>> typically had 4K entries after VM restore, so the prepopulate branch was >>> rarely taken. >>> >>> Symptoms include memory-access events firing for unexpected pages when >>> using VMI tools with altp2m, particularly after VM resume. >>> The issue can be worked around by booting with "hap_1gb=0 hap_2mb=0". >>> >>> Fixes: 7e5b662 ("x86/altp2m: p2m_altp2m_get_or_propagate() should honor ap2m->default_access") >> You didn't even Cc Tamas, who I think once again will need to ack this. >> Already with the referenced change I didn't quite understand the >> reasoning. >> >> However, two formal points: Please use 12-digit hashes, as demanded by >> sending-patches.pandoc. Plus I don't think Fixes: is quite right here. >> That earlier change of yours didn't mean to do more than it did, by its >> title and description. We relatively recently introduced Amends:, which >> may be a suitable fit here. > > I beg your pardon?  Fixes are and Amends are synonyms. This is news to me. To me a "fix" addresses a bug in the referenced commit. Whereas making a related change which isn't strictly a bugfix to the referenced earlier change is what Amends: was introduced for. If both were synonyms, why would you not have objected to the introduction of Amends:? >  You cannot use > them like this, and you absolutely cannot expect contributors to know > your personal interpretation of the words. "My personal interpretation of the words" has become the community's with the committing of the change introducing Amends:. And I think I can expect contributors to read sending-patches.pandoc? Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 11:45:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 11:45:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200136.1516131 (Exim 4.92) (envelope-from ) id 1vfGMJ-00082m-SH; Mon, 12 Jan 2026 11:45:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200136.1516131; Mon, 12 Jan 2026 11:45:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfGMJ-00082f-Ol; Mon, 12 Jan 2026 11:45:19 +0000 Received: by outflank-mailman (input) for mailman id 1200136; Mon, 12 Jan 2026 11:45:18 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfGMH-00082Z-UK for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 11:45:18 +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 296f8990-efac-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 12:45:16 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-43284ed32a0so3158429f8f.3 for ; Mon, 12 Jan 2026 03:45:16 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0dadcfsm37687906f8f.3.2026.01.12.03.45.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 03:45:14 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 296f8990-efac-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768218315; x=1768823115; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=DP/rj83J9h2HGMzSIS2/JNlabRM3uvkqd3D0lsJPkOM=; b=fQzLYYI+g61ripbEUnaqSO91pWYzGaXXSwA2T3xexB9PKbL3ko8AWTbaxMw3F3NwFp LVX0hRbok1rUufyVMKu0SLOX0ojH0H5beyaNUxQdi+aVPDhIAOCXIl+U2LkALuIUSUiQ 3GULi6J6uSxykKHvnIlIWnGS8bwKGF7uf+xKy/5mZsS6nMcgQTCG4Q6q6BXCucZAzmge mHiuxjpJZNXSpGv5eyMULdZgmvfv0aPTetXDcQXR+40ZdV0GIT9DJK1XObfgCZWhuo2z P9pa4st9WxaV4EWPAGCQhhwXACukM4ilGkeRgaHc95JzSnojEx1w2/+AlrLCAYV0yHot mdWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768218315; x=1768823115; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=DP/rj83J9h2HGMzSIS2/JNlabRM3uvkqd3D0lsJPkOM=; b=fEbv+KfNtOihYFkcNp+W+TgssOEH4WUjUOwver5RRr0/j7LicUOYJygjm5awcMOYf6 wQjUBH78cGUvcczphpRFIFVr6XzLyYkg0688ivG1WAzbiU97VCm0O5X+iRrkF4hlMMam M8+iFtWJCYVZzvhS7KNRscY86HWHao7e0I0MU7vaVd7+1I8c562vV2vZyAiMD+A8BVPG Aww+7zokCjUp0Fhgj14CYClwZ1pvrDaJGTkbuMgMDlVrK1qrV/0BAOen9xc05G/by22D Wg/NY/9v/AAsbjcQu/WFz9tDbxbUMgnjyErzmsnst1PgqgSqsFX6ArhSMuXqTwpbgvOz GEDg== X-Forwarded-Encrypted: i=1; AJvYcCUD5EIzfrmcktrnJkeETLxsWSxlTG3UACuxsK4xRgDFBj9WcML/E91HhRkoRLeS+6T5OZsRbSBVsyw=@lists.xenproject.org X-Gm-Message-State: AOJu0YzYq9QA/gNCq0neyPqxNbP+5gJa0xspRmfi8uL5m+VvGVB4OY8c omh46P/9OpmmXFZBLPCa8wscBicTr1ADuEFH9btNwLFnaLReAXVjF0BVDEk/I2uvOQ== X-Gm-Gg: AY/fxX7GrjvcFmoS4zSOAr7WzxDeWhQLSbGCnDeMNsVXxn8Njgdw+jsf4lUFQGSxUWr JRfXQYWt5uEhqPTRHCACDhJHnoBIDmC/1Zm9XUUfnGaknRV1WtHSQKlVQ63wP7K3lmRxr+4Is6p 0MaPqlyK+vOutVtpmy74Cp6caJO0gXdmE9sQCp7F5SEHc0hh3qAUFDlKMDECaKWx6T2sQ0xURSF hRr3TTkQr0OtUcSpJvLSZZeMSXqSRAuHCQgT9d7x5zpt2NR5zI+Hj26w0xNUmywX2cLgu8kwzQO 2gZ8UTp5EeXwm6JcRCGfnQF/JRCnhQwOMTqYlEBC0FiEorQdnOoyUvMbD171nGbeCkD65s3kW4H NNNMDxLDiXXGtb0YUM6klKI6Vs1/J1/oWBFyPX3BUtLOE/l4/lHK4qJqhb1gYcj1ZTf6s6Wdx2v ZvDRarov71rYGjcYnxwdzkigegUTEUnIljtxUjCfOWncGLlusKQgCBwc5/uLerCoNspD8BVUiVz 3eSwV8z0i1zZg== X-Google-Smtp-Source: AGHT+IGAoUaHw0ZQUpxudaCqdGTnx81wymlEijFVngf0f7NPihpWhmduuNh3HpkvGip/WwJfIxcQWA== X-Received: by 2002:a5d:64e7:0:b0:432:5c43:53 with SMTP id ffacd0b85a97d-432c374f248mr17967581f8f.36.1768218315092; Mon, 12 Jan 2026 03:45:15 -0800 (PST) Message-ID: <4b03cf36-d2d8-420c-82df-55d6a9ac9d68@suse.com> Date: Mon, 12 Jan 2026 12:45:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() To: Anton Markov Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> <4a6b6307-9014-4c4c-8c23-3673efa2d1b1@gmail.com> <794c382b-3b20-4d2a-ab70-b24d7fdf88ae@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.01.2026 11:31, Anton Markov wrote: > Bit rounding isn't the main issue; the difference in ipi delivery to the > cores accumulates due to the ordering. Replacing get_s_time_fixed with > scale_delta in time_calibration_rendezvous_tail should be sufficient. This > configuration won't accumulate errors, but bit rounding can still cause a > significant difference from calibration to calibration, but it's not as > significant. That invocation of get_s_time_fixed() reduces to scale_delta() (without further rdtsc_ordered()), as non-zero at_tsc is passed in all cases. IOW it's not quite clear to me what change you are suggesting (that would actually make a functional difference). Btw, your prior response was too hard to properly read, due to excess blank lines with at the same time squashed leading blanks. Together with your apparent inability to avoid top-posting, I think you really want to adjust your mail program's configuration. Jan > On Fri, Jan 9, 2026 at 7:11 PM Anton Markov wrote: > >> You're right. These aren't interrupts in get_s_time_fixed, but rather a >> cumulative error in the sequence due to integer rounding. I added logging >> of the current local_stime to local_time_calibration and noticed that the >> timestamp between cores is gradually increasing. If the server has been >> running for weeks, this could be a very large value. >> >> >> ``` >> >> @@ -1732,6 +1753,8 @@ static void cf_check local_time_calibration(void) >> >> if ( boot_cpu_has(X86_FEATURE_CONSTANT_TSC) ) >> >> { >> >> /* Atomically read cpu_calibration struct and write cpu_time struct. */ >> >> + printk("update stime on time calibrate %d, %lu -> %lu (%lu, %lu)\n", >> smp_processor_id(), t->stamp.local_stime, c->local_stime, >> >> + t->last_seen_ns, t->last_seen_tsc); >> >> local_irq_disable(); >> >> t->stamp = *c; >> >> local_irq_enable(); >> >> ``` >> >> >> 2 hours of work: >> >> >> ``` >> >> (XEN) update stime on time calibrate 0, 8564145820102 -> 8565145861597 >> (8565145862216, 0) >> >> (XEN) update stime on time calibrate 1, 8564145820129 -> 8565145861609 >> (8565145863957, 0) >> >> (XEN) update stime on time calibrate 3, 8564145819996 -> 8565145861491 >> (8565145864800, 0) >> >> (XEN) update stime on time calibrate 2, 8564145820099 -> 8565145861609 >> (8565145865372, 0) >> >> >> 8565145861609 - 8565145861491 = 115 * 3 (3.00 GHz) = 345 lag >> >> ``` >> >> >> 6 hours of work: >> >> ``` >> >> (XEN) update stime on time calibrate 0, 22914730829200 -> 22915730869993 >> (22915730870665, 0) >> >> (XEN) update stime on time calibrate 1, 22914730829073 -> 22915730869889 >> (22915730870693, 0) >> >> (XEN) update stime on time calibrate 2, 22914730829052 -> 22915730869841 >> (22915730872231, 0) >> >> (XEN) update stime on time calibrate 3, 22914730828892 -> 22915730869696 >> (22915730872096, 0) >> >> >> 22915730869993 - 22915730869696 = 297 * 3 (3.00 GHz) = 891 lag >> >> ``` >> >> >> Clarification, according to my xen settings: >> >> ``` >> >> ucode=scan dom0_mem=53923M,max:53923M dom0_max_vcpus=4-96 dom0_vcpus_pin=0 >> force-ept=1 ept=no-ad,no-pml hap_1gb=0 hap_2mb=0 altp2m=1 >> hpet=legacy-replacement smt=1 spec-ctrl=no gnttab_max_frames=512 >> cpufreq=xen:performance max_cstate=1 sched=credit sched-gran=cpu apicv=0 >> sched_credit_tslice_ms=5 sched_ratelimit_us=500 >> >> ``` >> >> >> Processors I tested on: >> >> >> ``` >> >> Intel(R) Core(TM) i5-3330 CPU @ 3.00GHz >> >> >> Flags: fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx >> fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nopl >> nonstop_tsc cpuid tsc_known_freq pni pclmulqdq monitor est ssse3 cx16 >> sse4_1 sse4_2 popcnt aes xsave avx f16c hypervisor lahf_lm cpuid_fault >> fsgsbase erms xsaveopt arch_capabilities >> >> ``` >> >> ``` >> >> Intel(R) Xeon(R) Gold 5318Y CPU @ 2.10GHz x2 (NUMA) >> >> >> Flags: fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx >> fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nopl >> nonstop_tsc cpuid tsc_known_freq pni pclmulqdq monitor est ssse3 fma cx16 >> sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm >> 3dnowprefetch cpuid_fault ibpb fsgsbase bmi1 avx2 bmi2 erms rtm avx512f >> avx512dq rdseed adx avx512ifma clflushopt clwb avx512cd sha_ni avx512bw >> avx512vl xsaveopt xsavec xgetbv1 avx512vbmi avx512_vbmi2 gfni vaes >> vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid fsrm md_clear >> arch_capabilities >> >> ``` >> >> >> Next I moved the code to r3 to speed up playback: >> >> >> ``` >> >> #include >> >> #include >> >> >> static __inline__ unsigned long long rdtsc(void) >> >> { >> >> unsigned hi, lo; >> >> __asm__ __volatile__ ("rdtsc" : "=a"(lo), "=d"(hi)); >> >> return ( (unsigned long long)lo)|( ((unsigned long long)hi)<<32 ); >> >> } >> >> >> #define MILLISECS(_ms) ((int64_t)((_ms) * 1000000ULL)) >> >> >> struct cpu_time_stamp { >> >> uint64_t local_tsc; >> >> int64_t local_stime; >> >> int64_t master_stime; >> >> }; >> >> >> struct time_scale { >> >> int shift; >> >> uint32_t mul_frac; >> >> }; >> >> >> >> static inline uint32_t div_frac(uint32_t dividend, uint32_t divisor) >> >> { >> >> uint32_t quotient, remainder; >> >> asm ( >> >> "divl %4" >> >> : "=a" (quotient), "=d" (remainder) >> >> : "0" (0), "1" (dividend), "r" (divisor) ); >> >> return quotient; >> >> } >> >> >> >> void set_time_scale(struct time_scale *ts, uint64_t ticks_per_sec) >> >> { >> >> uint64_t tps64 = ticks_per_sec; >> >> uint32_t tps32; >> >> int shift = 0; >> >> >> while ( tps64 > (MILLISECS(1000)*2) ) >> >> { >> >> tps64 >>= 1; >> >> shift--; >> >> } >> >> >> tps32 = (uint32_t)tps64; >> >> while ( tps32 <= (uint32_t)MILLISECS(1000) ) >> >> { >> >> tps32 <<= 1; >> >> shift++; >> >> } >> >> >> ts->mul_frac = div_frac(MILLISECS(1000), tps32); >> >> ts->shift = shift; >> >> } >> >> >> >> uint64_t scale_delta(uint64_t delta, const struct time_scale *scale) >> >> { >> >> uint64_t product; >> >> >> if ( scale->shift < 0 ) >> >> delta >>= -scale->shift; >> >> else >> >> delta <<= scale->shift; >> >> >> asm ( >> >> "mulq %2 ; shrd $32,%1,%0" >> >> : "=a" (product), "=d" (delta) >> >> : "rm" (delta), "0" ((uint64_t)scale->mul_frac) ); >> >> >> return product; >> >> } >> >> >> #define _TS_MUL_FRAC_IDENTITY 0x80000000UL >> >> >> static inline struct time_scale scale_reciprocal(struct time_scale scale) >> >> { >> >> struct time_scale reciprocal; >> >> uint32_t dividend; >> >> >> dividend = _TS_MUL_FRAC_IDENTITY; >> >> reciprocal.shift = 1 - scale.shift; >> >> while ( dividend >= scale.mul_frac ) >> >> { >> >> dividend >>= 1; >> >> reciprocal.shift++; >> >> } >> >> >> asm ( >> >> "divl %4" >> >> : "=a" (reciprocal.mul_frac), "=d" (dividend) >> >> : "0" (0), "1" (dividend), "r" (scale.mul_frac) ); >> >> >> return reciprocal; >> >> } >> >> >> >> int64_t get_s_time_fixed(const struct cpu_time_stamp *t, const struct >> time_scale *ts, uint64_t at_tsc) >> >> { >> >> uint64_t tsc, delta; >> >> >> if ( at_tsc ) >> >> tsc = at_tsc; >> >> else >> >> tsc = rdtsc(); >> >> delta = tsc - t->local_tsc; >> >> return t->local_stime + scale_delta(delta, ts); >> >> } >> >> >> int main() { >> >> >> struct cpu_time_stamp ct; >> >> struct time_scale ts; >> >> struct time_scale back; >> >> >> uint64_t start = rdtsc(); >> >> >> set_time_scale(&ts, 3000000000); >> >> back = scale_reciprocal(ts); >> >> >> ct.local_tsc = start; >> >> ct.local_stime = scale_delta(start, &ts); >> >> >> while (1) { >> >> uint64_t new_tsc = rdtsc(); >> >> ct.local_stime = get_s_time_fixed(&ct, &ts, new_tsc); >> >> ct.local_tsc = new_tsc; >> >> >> uint64_t tmp_tsc = rdtsc(); >> >> printf("%lu %lu\n", tmp_tsc, scale_delta(get_s_time_fixed(&ct, &ts, >> tmp_tsc), &back)); >> >> } >> >> >> return 0; >> >> } >> >> ``` >> >> >> It's enough to run the loop for 10-20 seconds to see the problem. >> scale_delta rounds the least significant bits during calculation, which >> causes the error to accumulate, at different rates on different cores, >> depending on the least significant bits at the time of calibration. >> >> >> Now let's talk about why dwm reacts this way. When a snapshot is reversed, >> last_guest_time in hvm_get_guest_time_fixed is set to 0, which doesn't >> prevent time from flowing backwards. This means that cache_tsc_offset in >> hvm_get_guest_tsc_fixed may be configured correctly on one physical core, >> but due to shedding on a physical core with a lagging tsc, the guest may >> occasionally see a tsc value lower than it saw before the snapshot was >> reversed. If this happens to the dwm code, it terminates with an error. >> >> >> A quick solution to this problem might be to save the last_seen_tsc >> parameter in a snapshot for each core, followed by validation. >> >> >> The correct solution is to remove the rounding of the least significant >> bits from the sequence. >> >> On Wed, Jan 7, 2026 at 11:02 AM Jan Beulich wrote: >> >>> On 06.01.2026 21:10, Антон Марков wrote: >>>> Hi, I'm not sure about the other places. In hvm_load_cpu_ctxt >>>> (xen/arch/x86/hvm/hvm.c ), it was easy to catch because >>>> process_pending_softirqs is frequently called there, which in turn >>>> processes softirqs from the timer (where the timestamp is updated). >>>> After I fixed sync_tsc in hvm_load_cpu_ctxt, the problem stopped >>>> reproducing under no load. However, when the number of vCPUs is 4 times >>>> greater than the number of CPUs (under heavy load), the problem rarely >>>> reoccurs (mostly during snapshot restores during >>>> process_pending_softirqs calls), and this is no longer a simple case. >>> If >>>> get_s_time_fixed can indeed be interrupted during execution after >>>> rdtsc_ordered, then the current fix is insufficient. It's necessary to >>>> atomically copy "t->stamp" to the stack using local_irq_disable and >>>> local_irq_enable (as in local_time_calibration), and then work with the >>>> copy, confident in its lifetime and immutability. But until >>>> get_s_time_fixed is proven to be interruptible, this is premature, so >>>> your fix is sufficient. I think I need more information and testing to >>>> say more. >>> >>> While the cpu_calibration per-CPU variable is updated from IRQ context, >>> the cpu_time one isn't. Hence t->stamp's contents cannot change behind >>> the back of get_s_time_fixed(). I wonder whether ... >>> >>>> Regarding the other scale_delta calls, if they include values >>>> calculated from externally saved tsc values that could have become >>>> stale during the process_pending_softirqs call, this definitely needs >>> to >>>> be fixed. >>> >>> ... another similar issue (possibly one not included in the set of >>> remarks I have in the patch, as none of those look related to what you >>> describe) might be causing the remaining, more rare problems you say you >>> see. That set of remarks is actually a result of me going over all other >>> scale_delta() calls, but of course I may have got the analysis wrong. >>> >>> As to using 4 times as many vCPU-s as there are pCPU-s (and then heavy >>> load) - while I don't think we have a support statement for such upstream >>> (when probably we should), iirc for our (SUSE's) products we would >>> consider that unsupported. Just fyi. >>> >>> Also, btw, please don't top-post. >>> >>> Jan >>> >> > From xen-devel-bounces@lists.xenproject.org Mon Jan 12 11:48:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 11:48:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200146.1516141 (Exim 4.92) (envelope-from ) id 1vfGP6-0000MI-8H; Mon, 12 Jan 2026 11:48:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200146.1516141; Mon, 12 Jan 2026 11:48:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfGP6-0000MB-5V; Mon, 12 Jan 2026 11:48:12 +0000 Received: by outflank-mailman (input) for mailman id 1200146; Mon, 12 Jan 2026 11:48: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 1vfGP3-0000Ly-HK for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 11:48:10 +0000 Received: from mail-106101.protonmail.ch (mail-106101.protonmail.ch [79.135.106.101]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8c2a163e-efac-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 12:48:01 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8c2a163e-efac-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1768218480; x=1768477680; bh=hMZ7ISbAZAdB9j2g7jiY9n4psbr6tMeEGXfsapPyD+M=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=O2npQbciQ/fOZBw9B6XGgoAZMw6d7qEBUMXMYbTU6twokp4ebieqOdCfXfn6iF4xb wQDcXDAjvQqRAUJhkIFqFbucy4UonJf0yBLECSVatDoKeA864Up0knVwoR+vSNY7il f4gAiUuiJEXONKw2LTLptqeTAWLzgnQ1H/WGlPMiWCe73NRbWcgJmlspIWdnK1BW9I Qcc6m425eaV0JrSW20CB1U7dq+zb6yDZ+tWYb9uo0+nmjJKAep1umP97xs8KgYKOlH Gtilnb7zz4jjVoxRibl6ITCL2cTOXFypyaR/JiHRBoxr4p+KVoMpz3dVME2pJMZIxd Ar9UMRnlUqXnA== Date: Mon, 12 Jan 2026 11:47:53 +0000 To: Jan Beulich From: Milky Cc: "xen-devel@lists.xenproject.org" , Jason Andryuk Subject: Re: Cpufreq drivers not working on T480S Message-ID: In-Reply-To: <8a2125c7-c5ec-4be1-a7a5-61b2936cc90f@suse.com> References: <7dbd26d1-0d9a-454f-90d8-5a7f3d8e12da@suse.com> <8a2125c7-c5ec-4be1-a7a5-61b2936cc90f@suse.com> Feedback-ID: 171106842:user:proton X-Pm-Message-ID: 135c2f6b552a31190d1a0a745a34ce2fa1dfd8f3 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Monday, January 12th, 2026 at 8:43 AM, Jan Beulich w= rote: > And was is meanwhile checked that ACPI provides the necessary tables, and > xen-processor-acpi manages to processes and upload them? With `cpufreq=3Dxen,no-hwp`, the `xen-acpi-processor` kernel module continu= es not to load. Decompiling the ACPI tables from `/sys/firmware/acpi/tables= ` using iasl and grepping for `_PCT`, `_PPC` and `_PSS` returns no results.= From xen-devel-bounces@lists.xenproject.org Mon Jan 12 11:54:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 11:54:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200155.1516151 (Exim 4.92) (envelope-from ) id 1vfGV4-0001vR-TH; Mon, 12 Jan 2026 11:54:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200155.1516151; Mon, 12 Jan 2026 11: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 1vfGV4-0001vK-Pu; Mon, 12 Jan 2026 11:54:22 +0000 Received: by outflank-mailman (input) for mailman id 1200155; Mon, 12 Jan 2026 11:54: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 1vfGV3-0001uv-R2 for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 11:54:21 +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 6d7a7c18-efad-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 12:54:19 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-432d256c2e6so3012337f8f.3 for ; Mon, 12 Jan 2026 03:54:19 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0dacdcsm37744762f8f.1.2026.01.12.03.54.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 03:54:18 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6d7a7c18-efad-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768218859; x=1768823659; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=jwWw97Vb+USIfgM6nN7v8myQ2HrpTiLfCwyLKZ1PtVc=; b=Jn8PRvrLWjVyPIX35TAr8MJYPENJoZU83JJpU21ZTQgt+Ikh/oZfW5KnU8oinrgyVG aJtWUWEQRRBeSKmdV0xCuVEPoxvSR6/6UbF/fn7JnI5qG01GQnJXu9bR4CPgZOZz3+ky zHKFk142lwE9iIFHcSRSycBD54KDlya0IPgLDSTOFnUDNaW7B/qRktoif3lpBNFF2hrh xmm+Myw2qbiiD5UoUDjmImK8Ohn1HJTwbhZZS405PenFPD4ssEqHkCoKiI+lSNOt2d/b IOvNX748gKoJJWsR1AEuXy6qbTNeCObCzkcSbYP0+QY9mtSJfqzfxdhuiWnnS8j38DXH x8YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768218859; x=1768823659; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=jwWw97Vb+USIfgM6nN7v8myQ2HrpTiLfCwyLKZ1PtVc=; b=DXCfSAZY1E4Ha59V4+C6vhnHqgaYi8evQEwhhiCI8ZtJXmRQ+E71UY4narWclWHoyo rRPqVPmW0i6205f9MZq/kRTCzLNDkwFk4lTDNscIaKD8N6+f+aXxwjrB8AKkxG9jdlCn qHMQ5D52mPC6cXrLVm14nD/FZXtP/RCrY9ejyAAQojJXnMBfxuoMetKrye3BrV/UCt8K oAt4QfxOUPDqifq46Bo9ei3i677mxVo34wCgYoFiSTlm7Ye+lCHMqz1SvX+povZxE/oq GxvjSG1fzu2dPUIr3xkGqZSk2Bu9KUbwxEw+gA9FD+mn22tPWgYV//XjLuhlS/f9KZzt cIxQ== X-Gm-Message-State: AOJu0Yxt33mplqcvHdtExctXDGhAQQiTr0V+hYNHITh9QvvMZYk1yKzF 5Zrn5sYKoHjEnh75QY2adHbJm3gfMd8PTXu95bjj0PL4550nUXRXSPaAKH9M7BSMmg== X-Gm-Gg: AY/fxX5GKVJhalTjuZOYh6eEM9pNfZtKgZ9a7hzfDYFGaqAvru/fu8foj+h60R8zsKn XiCZAb5ehCjpt9zcE6IJCxC0urum2nQfIQ0f7lfJ4tXn7jhB/U210EdwBnkFeT6jWkuXYCfYlr4 Z4PpJKMrVHxNgRlwVQr6Crei+c1giJ0SpIeUhK0aXNA+tmVs8UlvG3wmyg/3LVIKWHKX6b8HhX4 ny0xEgXxhGY9N17c76pjJl7FCDvGN0Ho+7Fxh0EQGz778ymbz00AtJIkeFxWx5R/xovnBe+OkeY 0LgfPxrOAhYRrqiZ9NyUtJbPu2tHowlgbLU9RfTWn4kZNOlkTAp0uXchHkOg5VKibcDgXbzcwyX ZrCZNR2bRuXurR/yPTUUraJKQsjeiFCq9FVpcKWivaMMtsKcO0mFGCv9b/vovn3fqlORYsOXaF8 i3Hyj01BB2q9Oo8Xqy2lNATQIGK/wOfmvF0SzyO7qBJYe6LsbM3wxOdHVheycO8ixMUAbamLRsw uA= X-Google-Smtp-Source: AGHT+IFjM82r+52sJgkVCHt24myO6WA2E9TdFudM88b1vqjNcHFBHjC5BLtkqMznB0tWm0/n9brmGQ== X-Received: by 2002:adf:fe8f:0:b0:430:f97a:6f43 with SMTP id ffacd0b85a97d-432c379f3c9mr18414287f8f.53.1768218858820; Mon, 12 Jan 2026 03:54:18 -0800 (PST) Message-ID: <87031758-8385-4b06-8c96-06457992755b@suse.com> Date: Mon, 12 Jan 2026 12:54:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/4] xenpm: Don't build outside of x86 To: Anthony PERARD , Teddy Astie , Julien Grall , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Cc: xen-devel@lists.xenproject.org, Oleksii Kurochko , Community Manager , Anthony PERARD References: <77dc07c4b4431fb53aa5b226d302f437e4314d8c.1766158766.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: 7bit On 07.01.2026 16:58, Anthony PERARD wrote: > On Fri, Dec 19, 2025 at 03:42:17PM +0000, Teddy Astie wrote: >> --- a/tools/misc/Makefile >> +++ b/tools/misc/Makefile >> @@ -23,13 +23,13 @@ INSTALL_SBIN-$(CONFIG_X86) += xen-lowmemd >> INSTALL_SBIN-$(CONFIG_X86) += xen-mceinj >> INSTALL_SBIN-$(CONFIG_X86) += xen-memshare >> INSTALL_SBIN-$(CONFIG_X86) += xen-mfndump >> +INSTALL_SBIN-$(CONFIG_X86) += xenpm > > Nit: I would sort this by taking the dash `-` into account since we do > so for the arch-common list, so xenpm would go after xen-vmtrace. Not really; imo it's coincidental that all present x86-only ones have a dash. I think this simply wants to ... >> INSTALL_SBIN-$(CONFIG_X86) += xen-ucode >> INSTALL_SBIN-$(CONFIG_X86) += xen-vmtrace >> INSTALL_SBIN += xencov >> INSTALL_SBIN += xenhypfs >> INSTALL_SBIN += xenlockprof >> INSTALL_SBIN += xenperf >> -INSTALL_SBIN += xenpm ... stay in its present place, merely becoming conditional. >> INSTALL_SBIN += xenwatchdogd >> INSTALL_SBIN += xen-access >> INSTALL_SBIN += xen-livepatch The three entries with dashes quite likely were blindly added to the tail, without paying attention to sorting. Imo they want moving up into their respective positions. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 12:09:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 12:09:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200171.1516161 (Exim 4.92) (envelope-from ) id 1vfGjZ-00040W-7T; Mon, 12 Jan 2026 12:09:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200171.1516161; Mon, 12 Jan 2026 12:09:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfGjZ-00040P-3j; Mon, 12 Jan 2026 12:09:21 +0000 Received: by outflank-mailman (input) for mailman id 1200171; Mon, 12 Jan 2026 12:09:20 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfGjX-00040J-Tk for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 12:09:20 +0000 Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [2607:f8b0:4864:20::52a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 85083c71-efaf-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 13:09:18 +0100 (CET) Received: by mail-pg1-x52a.google.com with SMTP id 41be03b00d2f7-c03ea3b9603so192193a12.2 for ; Mon, 12 Jan 2026 04:09:18 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 85083c71-efaf-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; t=1768219757; cv=none; d=google.com; s=arc-20240605; b=dNg8M295M+AqSjLfrfk6mVfqIPNcnXGJ4xMEJ98EU5bOVL4koBf5e7h4HEcoV7f7wZ xcFZaULluewxDH+7+yTr2nUBplQD671ci5yiBrvRJu4AO08qigQNikcXeeKcpXzXORtq 8iRBYrW7eTvKgOTVios6+wS+lkArGyP3Z3My/uWfrZUzmvrtG3377mxEj1SISCR6fFU/ D7FAUJ2rIVR2JPdyyNxkqMiGLK0A08Vst6/MIEUQCTzGLAifXrCnqpfCD01lGnCZSFHd 4/GmyoMVXmoNE7QLH8a9etX45TrkYrMA3XhqAQUAYu9LXNAsKFAZ4/moA2UBsICatYOA UOug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=hqE0n/BHfuGpBhKc4gDOFo1HDXq1DAZHir7z66JW3p0=; fh=64sy4YBgBXGN17F8up8usSaCG+1UZhpwtGHg+RL4oUw=; b=VoMBHQy7DOQu6hA8MJZdYuiOlxD/cTwJh0voi+yAy+SUa1HOQWJCRj50jQtGBqtNSf k9irlCpYf8QBOcaSp013XWpADLuBhZkF01A/kb6jwsrheHfOgoexuk7h+P9jmnTynqo8 EaKFRw4F/XxnzHnVwbC465wXQAYQKLN1V+ZedPc17TwzYH4A9566L244i3mqZUe8fDw1 xa4vHzFBwk8EXbMYOGH4mha0ka7y1rLSbJbeeUMR5N8yM48vEYQm2OfW396j1DHVqKj7 xQdyrb9VMVs5WEN/YxhJ5wNAh2GJ9BKg2MdUzI5lXNjvPqR5exGs2Svi3BC5zvcXuD7H L0KQ==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768219757; x=1768824557; 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=hqE0n/BHfuGpBhKc4gDOFo1HDXq1DAZHir7z66JW3p0=; b=OpnJ/NPFQQjxouuF7Z51IjwBd1FW0NYL+RJ/3MFO5h1SJPKNVWHmFhFOUrFSnbrrQS ZUWaIQQRW2eMYB+6vIDieA8ZJ6KVMhWTB8Q1XBfzCnIRXsz8hzAfEfoMoB+sMykOKboc h7fKMAo3Mm4UwsMpAxEnjtCAknb9vmOAciFlplNJ1SwCMkdljltkFqi0LZ74v+vaPEYL Ti4THAyM7MGU4g+Pb29Djxdai7g777SiPVXq749YTK5dUZVUeor2kqlPRLj/Tg0pfAQW wBXlqslNmaGa3/uS+wTXHM+i5k/Vq1R2fhXobt7dR7MEBdrCG4g4BLGCqmjDz++oG3n2 u37Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768219757; x=1768824557; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=hqE0n/BHfuGpBhKc4gDOFo1HDXq1DAZHir7z66JW3p0=; b=G6Qj/vuYww4NjYyRVqxbvzXKy3pk6TVHTnk5WHhIwFcDBDF7xxIHtO0/UHRFb5/KXI Nds4XV1ydTYsD+LrdYCwTyFtWH3ja23wRvGCjNNW8JWL9/R8gcJB+UHoTf817NKZI/DG b4dNJUYidVytWx/9oSx4O9ie8O5oUufxYGGGglCfuWc91whlu65tbvPuVMP538tQhzyC 9FzcICbf0uWhABwurq1d3TSwHuYOQzq//U8ZBqKOkfXG4iFIvjNCzOHwon6DzrbSCQTN z7RLus7KBsQCO0YkTdWLYdQryCik3iemvTwcZr/glMutfh6TE+7M5M1+lMJYvzRJUiBN F/IQ== X-Forwarded-Encrypted: i=1; AJvYcCUtxUi38KhbYtpf1hqbzjExq7AQ4lVMRzh61zlkpmJ0R9HaDoGlP7fdQYu7SlxFXyLsWRqLfKOLj6k=@lists.xenproject.org X-Gm-Message-State: AOJu0YzgQYn+HkUaoYQZy6ZCJjvvcmvrKzldgGYubj1HigslJZVq6LF3 Jg2sO0UWoIgChkt127jeb1ER3JR6P/njAoV86Kn/uHorIfEeOUGyx1o+4kTMxxBZhNcepoJz2nw 3BuSmVg50FrHWb9wWAdpEiPC9bjj7794= X-Gm-Gg: AY/fxX7yN3lqS3r5gfuYaL+CVjQzFZfMT9xMV3cu8sFAEKw1mSU1BqjxeToUv77jT8w ayoembKrKnZYGFxML6loJCFjeqYi6msuIfZ2ppT/FkvKzOAqfftsECwtbrrrLOXDTD+HxYDitPU ye6+6cgUamAAMg+5O22jp9tROAmQm2MGKjO0CHdi0lHyigbClaK2WY+G97NDSr8NHqh0GY0wwa8 wcjoVxkSz3bIJ17JOvknAkCm6JeLGdDfCnPXZcVz26zrAiJnB8SH3NP3PGQXZBPnZH43w== X-Google-Smtp-Source: AGHT+IGsoiuSKDEZkzPc+RQK/fg69BzYwaTbBV5Bxe6h/NwWMA9EvRBgHQOVQxh73MMosCF39OGG7AG3SnAebiiaEVs= X-Received: by 2002:a17:90b:4a46:b0:340:29cd:dce with SMTP id 98e67ed59e1d1-34f68d3a4d6mr11635797a91.8.1768219757156; Mon, 12 Jan 2026 04:09:17 -0800 (PST) MIME-Version: 1.0 References: <1916d0a7-ff9a-49f1-8564-2767226fca9c@citrix.com> In-Reply-To: From: =?UTF-8?Q?Petr_Bene=C5=A1?= Date: Mon, 12 Jan 2026 20:09:06 +0800 X-Gm-Features: AZwV_Qjp5V6qCcZpodbmtwCpIohPHZlCtKOUexN9NWe90LYUlohn5CyEMWPxdu0 Message-ID: Subject: Re: [PATCH] x86/altp2m: altp2m_get_effective_entry() should honor ap2m->default_access To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org, Tamas K Lengyel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 12, 2026 at 12:24=E2=80=AFPM Jan Beulich wr= ote: > > On 12.01.2026 12:18, Andrew Cooper wrote: > > On 12/01/2026 11:09 am, Jan Beulich wrote: > >> You didn't even Cc Tamas, who I think once again will need to ack this= . I _considered_ Ccing Tamas when I saw add_maintainers.pl didn't add him. I couldn't remember if I added him manually at that time or not. However, in the end, I just trusted the add_maintainers.pl and didn't modify it. > >> However, two formal points: Please use 12-digit hashes, as demanded by > >> sending-patches.pandoc. I apologize. This is the first time I'm learning of the existence of sending-patches.pandoc. Up until now I was following the "Submitting_Xen_Project_Patches" wiki page where nothing about how many characters of the hash should be included. I'll keep that in mind. > >> That earlier change of yours didn't mean to do more than it did, by it= s > >> title and description. True. Had I known at that time that the fix is needed to be applied in multiple places, the commit message would look different. > >> We relatively recently introduced Amends:, which > >> may be a suitable fit here. So, what should be my next steps? Should I re-send the patch where I Cc Tamas, use 12-char hashes and replace Fixes with Amends? P. From xen-devel-bounces@lists.xenproject.org Mon Jan 12 12:12:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 12:12:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200182.1516171 (Exim 4.92) (envelope-from ) id 1vfGmW-0005Uk-Ip; Mon, 12 Jan 2026 12:12:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200182.1516171; Mon, 12 Jan 2026 12:12:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfGmW-0005Ud-Fr; Mon, 12 Jan 2026 12:12:24 +0000 Received: by outflank-mailman (input) for mailman id 1200182; Mon, 12 Jan 2026 12: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 1vfGmU-0005UX-TK for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 12:12:22 +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 f1cb3853-efaf-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 13:12:20 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-477619f8ae5so46728165e9.3 for ; Mon, 12 Jan 2026 04:12:20 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d8718c610sm129136875e9.15.2026.01.12.04.12.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 04:12:19 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f1cb3853-efaf-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768219940; x=1768824740; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=7MvvYEpsg7S+kbCm6tGaQfySBW5tRxWaL/bNIa6EYVc=; b=bw9BYdCsUrlLcA3RAywaf0Yu2x8abFXjwtHWZzM6U2iTOdvk/1YUMUSRtn4uShRWAt UYMzQMvU2l3K7McqIS8CAwBOyM8BBIBvlw9HmIDX4758HxvQ5UDAMDHb1dbM1WodYIsA 3RN8A6MMGtAZ0vQFplLBdD1kXm1Nqb+KXxiNLbvHYwkXgMfkgvczJ/YVZSamhiIAL38c IMMyGJt0ypsvEq7ZpFfMOfL0kGk4Yy6UrlVyFAY6tCGhN5npz3bs0p2MckA8pVd2Mhe0 hYGG5ZoP0pPVViHjbL4cLxWba6P7WBJHMh1DoIDoSyZeHbIYtGDLalI7o8LbEJ+HEjv8 SasQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768219940; x=1768824740; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7MvvYEpsg7S+kbCm6tGaQfySBW5tRxWaL/bNIa6EYVc=; b=twrjRUOVfosAF4BNiTGo1DJ7FzUIEsZVCVcK9zzXeQvwadsG4iVxdIAtm1zj+Sfm/g 8qboHHqOE+ZrNzu81tZYjbwe99x5jLIK0tC3HmMh75MQp1z/ev2UXPFadcXpT4qf+oJD d0QgO+SoJfmQEAVAVI8G481ADZQB1qeuiF/7+bhTxQ2l3zRq11HNMuxP9lSalxC7ngwf 1IEzJmvDPIpwN4oEFSkj4lHQCng0J9EHLOHXtvjMNHde/yRdoll9PD4us6twAiUm3nhQ hx+PXhsP0VZ5MQ8GrpeGcztKn3K+bGdSuQG92w6mt7NI3Z3AFfiulY+Cv2vpqanir0hb haig== X-Forwarded-Encrypted: i=1; AJvYcCW2kx3B0b4C2rTp2WJjWJXAT1OpbEY9CnecwQ618ML1ztF2wkQRLAHN6mJhCzMJ9fL6czcwEDCehM4=@lists.xenproject.org X-Gm-Message-State: AOJu0YzwZJA9HJ1pze/ygLEhTjgOsBkRXaWg6w+UDzVj/6C8NGnvu7Rj Sh2HaYZKTWzNvhwrLJjBMWREy4AjJdlL6Xf+ASoTIOqcvvFcKeHZaTV1omPZOElEVw== X-Gm-Gg: AY/fxX77ZPGAbD6oLR1ODXnvCTud7pZs5pWOu92XCj0oVnzItu/JhKL1g8Tec4E6Ki3 Qr04wwmlBOdXRzAI+bVmAdmvvphxI5gykLHp+2BzjL/gjRbbVbsz0Q5NBwKlbEqZEOUkvmmDTrI FbfmNHu2tOxxgLS0vIj83LeKHCV804JEK3CTiiYBL5luWN7auAbVtYb/8cy1IMdKA0Aj81z7Nyp RB8yRq5colhuu+bJRnkmoJS/Y79OLl2N2pVbd3j7kQMY0Db7Ldh0rfG5fwYT172TcrwuABu9iDe iflZR5QVOueWI5UPGwEsO0EYx+SiSWI2Ir21t9/B3nElny9jCQT1KIXAekre2V96GM7j9lgXgyR NDGv6ane/25IOSG9PIqfdWiPv+g4V9DCAr8oOupYRJLJIr7Wcchz0RbmEknbF59sC0TLo6I06eb 36uIMB4Tvn+HVCvNNJfZD24aDhaCy27KAuNtjqkFLFx5AEMeokJvrsm9UF9a03pax2bkCDgGKnk /0= X-Google-Smtp-Source: AGHT+IHeQKBkCPaoEmii6uAHSnaxtq5wgRndx1dwx/xm7FGQRGK8vuVVemZ//tK01uB1rZQwFIJeeQ== X-Received: by 2002:a05:600c:4fc3:b0:479:3a2a:94e7 with SMTP id 5b1f17b1804b1-47d84b2cd24mr220653675e9.10.1768219939924; Mon, 12 Jan 2026 04:12:19 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2026 13:12:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/altp2m: altp2m_get_effective_entry() should honor ap2m->default_access To: =?UTF-8?Q?Petr_Bene=C5=A1?= Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org, Tamas K Lengyel References: <1916d0a7-ff9a-49f1-8564-2767226fca9c@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12.01.2026 13:09, Petr Beneš wrote: > On Mon, Jan 12, 2026 at 12:24 PM Jan Beulich wrote: >> On 12.01.2026 12:18, Andrew Cooper wrote: >>> On 12/01/2026 11:09 am, Jan Beulich wrote: >>>> We relatively recently introduced Amends:, which >>>> may be a suitable fit here. > > So, what should be my next steps? Should I re-send the patch where I > Cc Tamas, use 12-char hashes and replace Fixes with Amends? I'd give Tamas a little bit of time to possibly comment, which might then save one round of re-submission. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 12:48:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 12:48:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200193.1516182 (Exim 4.92) (envelope-from ) id 1vfHKt-0001CS-5u; Mon, 12 Jan 2026 12:47:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200193.1516182; Mon, 12 Jan 2026 12: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 1vfHKt-0001CL-1K; Mon, 12 Jan 2026 12:47:55 +0000 Received: by outflank-mailman (input) for mailman id 1200193; Mon, 12 Jan 2026 12:47:53 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfHKr-0001CF-L9 for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 12:47:53 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vfHKr-000480-14; Mon, 12 Jan 2026 12:47:52 +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 1vfHKq-000Cn4-20; Mon, 12 Jan 2026 12: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" 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=B1ZjuILSJSpX8cg9BDkGUVHLqYxlznCrFFIKjmQsCyo=; b=5DEElnsTDUOBFFmlK1M8+5vEyx xhXETqrZkeL4BZQao6A2TaEcwTBr1TKA0q9X1I2FXC+dWhUol1ExTDPpKiq0wMRngerR9NZydxccW Il58ViFdrMf6Ppr8MoDJPJI7dgCAH1WpeL3/YAu7noB+8Q5RukWOcDHYsm0NtyAUpEX0=; Date: Mon, 12 Jan 2026 13:47:50 +0100 From: Anthony PERARD To: Roger Pau =?iso-8859-1?Q?Monn=E9?= Cc: Teddy Astie , xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: Re: [RFC PATCH] pvh: Introduce SIF_HVM_GHCB for SEV-ES/SNP guests Message-ID: References: <3b6f5146287d3402a09836b7cf876d4f8dc9eee1.1766889890.git.teddy.astie@vates.tech> <0c9c1dbb-28e1-479b-a680-e99150b3f0da@vates.tech> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Fri, Jan 09, 2026 at 12:37:30PM +0100, Roger Pau Monn wrote: > On Fri, Jan 09, 2026 at 10:31:57AM +0000, Teddy Astie wrote: > > It would be easier to not use hvmloader, especially since only UEFI > > supports SEV and guests would still need to support (Xen-specific) SEV > > bits to begin with. > > I would be very happy to relegate hvmloader to be used with SeaBIOS > only, and to load OVMF directly for HVM guests. But I don't know > what's missing for OVMF to be capable of that. I would think not > much, since it's already almost working for PVH guests AFAIK. OvmfXen works in PVH, and you can start guest ;-), the last change was to remove the use of the hypercall page so the shutdown hypercall could be called from UEFI Runtime Service. > Maybe PCI enumeration, but OVMF must have a way of doing that already > for other platforms I expect. Yes, that would probably be the main thing, I believe. It might just be a setting to enable enumeration when OvmfXen is started via the PVH entry point, I haven't really try to boot OVMF in HVM without hvmloader yet, and we would need to change the tool stack to boot an HVM guest via the PVH entry point. But, I already have a prototype of OvmfXen that could boot (modified) Linux in an SEV guest, it's based on SEV work from sometime ago so might not work anymore (and I don't remember if linux could start userspace): https://xenbits.xenproject.org/gitweb/?p=people/aperard/ovmf.git;a=log;h=refs/heads/wip.sev Cheers, -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Mon Jan 12 12:49:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 12:49:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200203.1516200 (Exim 4.92) (envelope-from ) id 1vfHMU-0001x5-KL; Mon, 12 Jan 2026 12:49:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200203.1516200; Mon, 12 Jan 2026 12: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 1vfHMU-0001wt-HQ; Mon, 12 Jan 2026 12:49:34 +0000 Received: by outflank-mailman (input) for mailman id 1200203; Mon, 12 Jan 2026 12:49: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 1vfHMS-0001i6-NF for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 12:49:32 +0000 Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [2607:f8b0:4864:20::102c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2216c733-efb5-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 13:49:29 +0100 (CET) Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-34f2a0c4574so4918506a91.1 for ; Mon, 12 Jan 2026 04:49:29 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2216c733-efb5-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768222168; x=1768826968; 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=4OuE4gLYnwfBXsvLGWtR4uU8s4Prde5wsYcTBvDjBzo=; b=calBBLOVI8eupJxY1fPWN3zQyi/9YfZxCvYq2GgV1OULarqNaGYxNO27YX6E7U/839 lm5umQDy+7RLpnDQ7D+oUF2gZ6uaIBG3gnetm0NkgyyQta9TV9T8WPe0d1yv77IbfYRj Ze/9bsBVN1Fx1bpYk4SY/9Eelr0HCGakITm26Ua6cw0ntx8B1mjR3BwzNVgQAo407mEm tOZFgL1D1TuaZvI3GJABpSJ8yTUM14bG+BzM9VwrPghS6Vc7v6LXjEwmo4OODt0HwDom VF2u5a4jrfi3MCTDfTfNXRoejwDKLs8vAul7CVtVTVzWFBMjh5+Cxeiuy9G+714E01ib DyFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768222168; x=1768826968; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4OuE4gLYnwfBXsvLGWtR4uU8s4Prde5wsYcTBvDjBzo=; b=hBhzApo/gfkSHo7rkdYKQK9zKDvE8OGGOCLazBsouMgeNjMQZUuThdVplvbthlT/dG tmdTKfmwZcwWn42iBW6ctzvYJV3kLq7s/PfB/SmU4eGmqZ9ascYinF3Aym0LjCWcITGp Li1lQOJqrT783VeopiupYC7gc6Lyo6jCuIwCmWx0IkXyefFucrPbPSecm70jB4V184n9 pqssMZY+IFS0bcFXrUPiPV6Zlw5UxTWUg1rg0obdIU/cvMp3jQLMqQhdY23zPqfPLWAr B7+VbgI1Gkjnk94Y8NejVlaUyOnxoTRYPHu8aN6fLqK6z96vQd8VTG9C51zqlHXaWr1R ZJvw== X-Forwarded-Encrypted: i=1; AJvYcCUFi7LPos3HKMK/44I+BeR1qOOQ2FbBPh02/FgBwehKpOZaYr13CzLWvrMNed1mJcB+ItUT5h2/e3c=@lists.xenproject.org X-Gm-Message-State: AOJu0YxSPqkURjkaWmLAWAscwt2wS6+eBsD6W2R/jq1LH4u6SyCjnwMM 2zfR3+Y+bXMk0tJIrKi7HW4qtwpeNOhCcjxNMLvzrgBjqmU5Xy0MpiLZZz+NPDu48/NKQHoRcBW V/uAsZLvQtfejt0Nc1ICUXyYLf1kf8p4= X-Gm-Gg: AY/fxX54fuTaTfF7hJ9xKBswYy/sh9Rpn9slT9XvxIp3CgeWv3GTdrHOUxVtCby4cTz i2ZKj2PYHGEr9lsRAWESfKOWi9Js0wtz99/I3EIXHZ39vQwEAQYg3zmf3VV25rZN+2RIfxcw+lr KJJJl1kWf35Qn70xLOsuI3YZVOvhWAyClnfSkhjB4MEpkRfCN+KwzO26KoV3LjjUehBc2f1O88M 3dexFhrenJJ10ktlGFIcFZTZsQ1Sx7vmptM2Tw1CBbFrY5RF4ptW/C3H85BIlCVldPpYoGg X-Google-Smtp-Source: AGHT+IFfRLJVaTNc81g1dnaKL8Ft+AbtVGjwJirVENjf2LIZ3y31NgOXlAlG7qZthXFabJIY7kwA6VfMgXIW6MXgyDc= X-Received: by 2002:a17:90b:2b8f:b0:33b:b020:597a with SMTP id 98e67ed59e1d1-34f68a73087mr14784863a91.0.1768222168049; Mon, 12 Jan 2026 04:49:28 -0800 (PST) MIME-Version: 1.0 References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> <4a6b6307-9014-4c4c-8c23-3673efa2d1b1@gmail.com> <794c382b-3b20-4d2a-ab70-b24d7fdf88ae@suse.com> <4b03cf36-d2d8-420c-82df-55d6a9ac9d68@suse.com> In-Reply-To: <4b03cf36-d2d8-420c-82df-55d6a9ac9d68@suse.com> From: Anton Markov Date: Mon, 12 Jan 2026 15:49:17 +0300 X-Gm-Features: AZwV_QhjKwbyF1nQXXBzLkOuqSS0nHfHtSQblLG2KdQkJhgvHZykhM-heiejtI4 Message-ID: Subject: Re: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() To: Jan Beulich Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="00000000000035eda40648304e7a" --00000000000035eda40648304e7a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > Btw, your prior response was too hard to properly read, due to excess bla= nk > lines with at the same time squashed leading blanks. Together with your > apparent inability to avoid top-posting, I think you really want to adjus= t > your mail program's configuration. I suggest we skip the discussion of formatting and the number of spaces in messages and instead focus on the topic of the thread. I have a very difficult time troubleshooting difficult-to-reproduce bugs, and the fact that their descriptions are difficult to read due to the number of spaces is probably the least of the difficulties. That invocation of get_s_time_fixed() reduces to scale_delta() (without > further rdtsc_ordered()), as non-zero at_tsc is passed in all cases. IOW > it's not quite clear to me what change you are suggesting (that would > actually make a functional difference). Replacing get_s_time_fixed with scale_delta will remove the calculation dependency on the previous local_stime value, which accumulates lag between cores. This is because: rdtsc_ordered is not called synchronously on the cores, but by the difference offset by the ipi speed. Therefore, we get: core0: current_rdtsc; core1: current_rdtsc + ipi speed; coreN: current_rdtsc + ipi speed * N; Since ipi values are sent alternately in a loop to core0, in the version with get_s_time_fixed, we get the following local_stime calculation format. coreN: local_stime =3D local_stime + scale_delta((current_rdtsc + (ipi_spee= d * N)) =E2=80=93 local_rdtsc); This means the time on each core will differ by ipi_speed * N. And since we're using the values of the previous local_stime, the difference will accumulate because the previous local_stime was also offset. In the version with scale_delta, we get: coreN: local_stime =3D scale_delta(current_rdtsc + (ipi_speed * N)); This means there will still be a difference, but it won't accumulate, and the offsets will remain within normal limits. If it's still unclear: If your local_stime in get_s_time_fixed is offset relative to other cores, then the fact that rdtsc_ordered and local_tsc are not offset doesn't change anything, since you're using the delta relative to local_stime. core0_local_stime + (rdtsc_ordered() - local_tsc) !=3D core1_local_stime + (rdtsc_ordered() - local_tsc); // Even if rdtsc_ordered() and local_tsc are equal across cores. On 96-core configurations, up to a millisecond of latency can accumulate in local_stime over a week of operation, and this is a significant difference. This is due to the fact that I use cpufreq=3Dxen:performance max_cstate=3D1 , meaning that in my configuration, local_stime is never overwritten by master_stime. Thanks. On Mon, Jan 12, 2026 at 2:45=E2=80=AFPM Jan Beulich wro= te: > On 12.01.2026 11:31, Anton Markov wrote: > > Bit rounding isn't the main issue; the difference in ipi delivery to th= e > > cores accumulates due to the ordering. Replacing get_s_time_fixed with > > scale_delta in time_calibration_rendezvous_tail should be sufficient. > This > > configuration won't accumulate errors, but bit rounding can still cause= a > > significant difference from calibration to calibration, but it's not as > > significant. > > That invocation of get_s_time_fixed() reduces to scale_delta() (without > further rdtsc_ordered()), as non-zero at_tsc is passed in all cases. IOW > it's not quite clear to me what change you are suggesting (that would > actually make a functional difference). > > Btw, your prior response was too hard to properly read, due to excess bla= nk > lines with at the same time squashed leading blanks. Together with your > apparent inability to avoid top-posting, I think you really want to adjus= t > your mail program's configuration. > > Jan > > > On Fri, Jan 9, 2026 at 7:11=E2=80=AFPM Anton Markov > wrote: > > > >> You're right. These aren't interrupts in get_s_time_fixed, but rather = a > >> cumulative error in the sequence due to integer rounding. I added > logging > >> of the current local_stime to local_time_calibration and noticed that > the > >> timestamp between cores is gradually increasing. If the server has bee= n > >> running for weeks, this could be a very large value. > >> > >> > >> ``` > >> > >> @@ -1732,6 +1753,8 @@ static void cf_check local_time_calibration(void= ) > >> > >> if ( boot_cpu_has(X86_FEATURE_CONSTANT_TSC) ) > >> > >> { > >> > >> /* Atomically read cpu_calibration struct and write cpu_time struct. *= / > >> > >> + printk("update stime on time calibrate %d, %lu -> %lu (%lu, %lu)\n", > >> smp_processor_id(), t->stamp.local_stime, c->local_stime, > >> > >> + t->last_seen_ns, t->last_seen_tsc); > >> > >> local_irq_disable(); > >> > >> t->stamp =3D *c; > >> > >> local_irq_enable(); > >> > >> ``` > >> > >> > >> 2 hours of work: > >> > >> > >> ``` > >> > >> (XEN) update stime on time calibrate 0, 8564145820102 -> 8565145861597 > >> (8565145862216, 0) > >> > >> (XEN) update stime on time calibrate 1, 8564145820129 -> 8565145861609 > >> (8565145863957, 0) > >> > >> (XEN) update stime on time calibrate 3, 8564145819996 -> 8565145861491 > >> (8565145864800, 0) > >> > >> (XEN) update stime on time calibrate 2, 8564145820099 -> 8565145861609 > >> (8565145865372, 0) > >> > >> > >> 8565145861609 - 8565145861491 =3D 115 * 3 (3.00 GHz) =3D 345 lag > >> > >> ``` > >> > >> > >> 6 hours of work: > >> > >> ``` > >> > >> (XEN) update stime on time calibrate 0, 22914730829200 -> 229157308699= 93 > >> (22915730870665, 0) > >> > >> (XEN) update stime on time calibrate 1, 22914730829073 -> 229157308698= 89 > >> (22915730870693, 0) > >> > >> (XEN) update stime on time calibrate 2, 22914730829052 -> 229157308698= 41 > >> (22915730872231, 0) > >> > >> (XEN) update stime on time calibrate 3, 22914730828892 -> 229157308696= 96 > >> (22915730872096, 0) > >> > >> > >> 22915730869993 - 22915730869696 =3D 297 * 3 (3.00 GHz) =3D 891 lag > >> > >> ``` > >> > >> > >> Clarification, according to my xen settings: > >> > >> ``` > >> > >> ucode=3Dscan dom0_mem=3D53923M,max:53923M dom0_max_vcpus=3D4-96 > dom0_vcpus_pin=3D0 > >> force-ept=3D1 ept=3Dno-ad,no-pml hap_1gb=3D0 hap_2mb=3D0 altp2m=3D1 > >> hpet=3Dlegacy-replacement smt=3D1 spec-ctrl=3Dno gnttab_max_frames=3D5= 12 > >> cpufreq=3Dxen:performance max_cstate=3D1 sched=3Dcredit sched-gran=3Dc= pu apicv=3D0 > >> sched_credit_tslice_ms=3D5 sched_ratelimit_us=3D500 > >> > >> ``` > >> > >> > >> Processors I tested on: > >> > >> > >> ``` > >> > >> Intel(R) Core(TM) i5-3330 CPU @ 3.00GHz > >> > >> > >> Flags: fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi m= mx > >> fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nopl > >> nonstop_tsc cpuid tsc_known_freq pni pclmulqdq monitor est ssse3 cx16 > >> sse4_1 sse4_2 popcnt aes xsave avx f16c hypervisor lahf_lm cpuid_fault > >> fsgsbase erms xsaveopt arch_capabilities > >> > >> ``` > >> > >> ``` > >> > >> Intel(R) Xeon(R) Gold 5318Y CPU @ 2.10GHz x2 (NUMA) > >> > >> > >> Flags: fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi m= mx > >> fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nopl > >> nonstop_tsc cpuid tsc_known_freq pni pclmulqdq monitor est ssse3 fma > cx16 > >> sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_l= m > abm > >> 3dnowprefetch cpuid_fault ibpb fsgsbase bmi1 avx2 bmi2 erms rtm avx512= f > >> avx512dq rdseed adx avx512ifma clflushopt clwb avx512cd sha_ni avx512b= w > >> avx512vl xsaveopt xsavec xgetbv1 avx512vbmi avx512_vbmi2 gfni vaes > >> vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid fsrm > md_clear > >> arch_capabilities > >> > >> ``` > >> > >> > >> Next I moved the code to r3 to speed up playback: > >> > >> > >> ``` > >> > >> #include > >> > >> #include > >> > >> > >> static __inline__ unsigned long long rdtsc(void) > >> > >> { > >> > >> unsigned hi, lo; > >> > >> __asm__ __volatile__ ("rdtsc" : "=3Da"(lo), "=3Dd"(hi)); > >> > >> return ( (unsigned long long)lo)|( ((unsigned long long)hi)<<32 ); > >> > >> } > >> > >> > >> #define MILLISECS(_ms) ((int64_t)((_ms) * 1000000ULL)) > >> > >> > >> struct cpu_time_stamp { > >> > >> uint64_t local_tsc; > >> > >> int64_t local_stime; > >> > >> int64_t master_stime; > >> > >> }; > >> > >> > >> struct time_scale { > >> > >> int shift; > >> > >> uint32_t mul_frac; > >> > >> }; > >> > >> > >> > >> static inline uint32_t div_frac(uint32_t dividend, uint32_t divisor) > >> > >> { > >> > >> uint32_t quotient, remainder; > >> > >> asm ( > >> > >> "divl %4" > >> > >> : "=3Da" (quotient), "=3Dd" (remainder) > >> > >> : "0" (0), "1" (dividend), "r" (divisor) ); > >> > >> return quotient; > >> > >> } > >> > >> > >> > >> void set_time_scale(struct time_scale *ts, uint64_t ticks_per_sec) > >> > >> { > >> > >> uint64_t tps64 =3D ticks_per_sec; > >> > >> uint32_t tps32; > >> > >> int shift =3D 0; > >> > >> > >> while ( tps64 > (MILLISECS(1000)*2) ) > >> > >> { > >> > >> tps64 >>=3D 1; > >> > >> shift--; > >> > >> } > >> > >> > >> tps32 =3D (uint32_t)tps64; > >> > >> while ( tps32 <=3D (uint32_t)MILLISECS(1000) ) > >> > >> { > >> > >> tps32 <<=3D 1; > >> > >> shift++; > >> > >> } > >> > >> > >> ts->mul_frac =3D div_frac(MILLISECS(1000), tps32); > >> > >> ts->shift =3D shift; > >> > >> } > >> > >> > >> > >> uint64_t scale_delta(uint64_t delta, const struct time_scale *scale) > >> > >> { > >> > >> uint64_t product; > >> > >> > >> if ( scale->shift < 0 ) > >> > >> delta >>=3D -scale->shift; > >> > >> else > >> > >> delta <<=3D scale->shift; > >> > >> > >> asm ( > >> > >> "mulq %2 ; shrd $32,%1,%0" > >> > >> : "=3Da" (product), "=3Dd" (delta) > >> > >> : "rm" (delta), "0" ((uint64_t)scale->mul_frac) ); > >> > >> > >> return product; > >> > >> } > >> > >> > >> #define _TS_MUL_FRAC_IDENTITY 0x80000000UL > >> > >> > >> static inline struct time_scale scale_reciprocal(struct time_scale > scale) > >> > >> { > >> > >> struct time_scale reciprocal; > >> > >> uint32_t dividend; > >> > >> > >> dividend =3D _TS_MUL_FRAC_IDENTITY; > >> > >> reciprocal.shift =3D 1 - scale.shift; > >> > >> while ( dividend >=3D scale.mul_frac ) > >> > >> { > >> > >> dividend >>=3D 1; > >> > >> reciprocal.shift++; > >> > >> } > >> > >> > >> asm ( > >> > >> "divl %4" > >> > >> : "=3Da" (reciprocal.mul_frac), "=3Dd" (dividend) > >> > >> : "0" (0), "1" (dividend), "r" (scale.mul_frac) ); > >> > >> > >> return reciprocal; > >> > >> } > >> > >> > >> > >> int64_t get_s_time_fixed(const struct cpu_time_stamp *t, const struct > >> time_scale *ts, uint64_t at_tsc) > >> > >> { > >> > >> uint64_t tsc, delta; > >> > >> > >> if ( at_tsc ) > >> > >> tsc =3D at_tsc; > >> > >> else > >> > >> tsc =3D rdtsc(); > >> > >> delta =3D tsc - t->local_tsc; > >> > >> return t->local_stime + scale_delta(delta, ts); > >> > >> } > >> > >> > >> int main() { > >> > >> > >> struct cpu_time_stamp ct; > >> > >> struct time_scale ts; > >> > >> struct time_scale back; > >> > >> > >> uint64_t start =3D rdtsc(); > >> > >> > >> set_time_scale(&ts, 3000000000); > >> > >> back =3D scale_reciprocal(ts); > >> > >> > >> ct.local_tsc =3D start; > >> > >> ct.local_stime =3D scale_delta(start, &ts); > >> > >> > >> while (1) { > >> > >> uint64_t new_tsc =3D rdtsc(); > >> > >> ct.local_stime =3D get_s_time_fixed(&ct, &ts, new_tsc); > >> > >> ct.local_tsc =3D new_tsc; > >> > >> > >> uint64_t tmp_tsc =3D rdtsc(); > >> > >> printf("%lu %lu\n", tmp_tsc, scale_delta(get_s_time_fixed(&ct, &ts, > >> tmp_tsc), &back)); > >> > >> } > >> > >> > >> return 0; > >> > >> } > >> > >> ``` > >> > >> > >> It's enough to run the loop for 10-20 seconds to see the problem. > >> scale_delta rounds the least significant bits during calculation, whic= h > >> causes the error to accumulate, at different rates on different cores, > >> depending on the least significant bits at the time of calibration. > >> > >> > >> Now let's talk about why dwm reacts this way. When a snapshot is > reversed, > >> last_guest_time in hvm_get_guest_time_fixed is set to 0, which doesn't > >> prevent time from flowing backwards. This means that cache_tsc_offset = in > >> hvm_get_guest_tsc_fixed may be configured correctly on one physical > core, > >> but due to shedding on a physical core with a lagging tsc, the guest m= ay > >> occasionally see a tsc value lower than it saw before the snapshot was > >> reversed. If this happens to the dwm code, it terminates with an error= . > >> > >> > >> A quick solution to this problem might be to save the last_seen_tsc > >> parameter in a snapshot for each core, followed by validation. > >> > >> > >> The correct solution is to remove the rounding of the least significan= t > >> bits from the sequence. > >> > >> On Wed, Jan 7, 2026 at 11:02=E2=80=AFAM Jan Beulich wrote: > >> > >>> On 06.01.2026 21:10, =D0=90=D0=BD=D1=82=D0=BE=D0=BD =D0=9C=D0=B0=D1= =80=D0=BA=D0=BE=D0=B2 wrote: > >>>> Hi, I'm not sure about the other places. In hvm_load_cpu_ctxt > >>>> (xen/arch/x86/hvm/hvm.c ), it was easy to catch because > >>>> process_pending_softirqs is frequently called there, which in turn > >>>> processes softirqs from the timer (where the timestamp is updated). > >>>> After I fixed sync_tsc in hvm_load_cpu_ctxt, the problem stopped > >>>> reproducing under no load. However, when the number of vCPUs is 4 > times > >>>> greater than the number of CPUs (under heavy load), the problem rare= ly > >>>> reoccurs (mostly during snapshot restores during > >>>> process_pending_softirqs calls), and this is no longer a simple case= . > >>> If > >>>> get_s_time_fixed can indeed be interrupted during execution after > >>>> rdtsc_ordered, then the current fix is insufficient. It's necessary = to > >>>> atomically copy "t->stamp" to the stack using local_irq_disable and > >>>> local_irq_enable (as in local_time_calibration), and then work with > the > >>>> copy, confident in its lifetime and immutability. But until > >>>> get_s_time_fixed is proven to be interruptible, this is premature, s= o > >>>> your fix is sufficient. I think I need more information and testing = to > >>>> say more. > >>> > >>> While the cpu_calibration per-CPU variable is updated from IRQ contex= t, > >>> the cpu_time one isn't. Hence t->stamp's contents cannot change behin= d > >>> the back of get_s_time_fixed(). I wonder whether ... > >>> > >>>> Regarding the other scale_delta calls, if they include values > >>>> calculated from externally saved tsc values that could have become > >>>> stale during the process_pending_softirqs call, this definitely need= s > >>> to > >>>> be fixed. > >>> > >>> ... another similar issue (possibly one not included in the set of > >>> remarks I have in the patch, as none of those look related to what yo= u > >>> describe) might be causing the remaining, more rare problems you say > you > >>> see. That set of remarks is actually a result of me going over all > other > >>> scale_delta() calls, but of course I may have got the analysis wrong. > >>> > >>> As to using 4 times as many vCPU-s as there are pCPU-s (and then heav= y > >>> load) - while I don't think we have a support statement for such > upstream > >>> (when probably we should), iirc for our (SUSE's) products we would > >>> consider that unsupported. Just fyi. > >>> > >>> Also, btw, please don't top-post. > >>> > >>> Jan > >>> > >> > > > > --00000000000035eda40648304e7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Btw, your prior response was too hard to properly read, due to e= xcess blank
lines with at the same time squashed leading blanks. Togethe= r with your
apparent inability to avoid top-posting, I think you really = want to adjust
your mail program's configuration.
<= span class=3D"gmail-jCAhz gmail-ChMk0b">I sugg= est we skip the discussion of formatting and the number of spaces in messag= es and instead focus on the topic of the thread. I have a very di= fficult time troubleshooting difficult-to-reproduce bugs, and the fact that= their descriptions are difficult to read due to the number of spaces is pr= obably the least of the difficulties.

That invocation o= f get_s_time_fixed() reduces to scale_delta() (without
further rdtsc_ord= ered()), as non-zero at_tsc is passed in all cases. IOW
it's not qui= te clear to me what change you are suggesting (that would
actually make = a functional difference).
Replacing get_s_time_fixed with scale= _delta will remove the calculation dependency on the previous local_stime v= alue, which accumulates lag between cores. This is because: rdtsc_ordered is not called synchronously on the cores, but by the differen= ce offset by the ipi speed. Therefore, we get:

core0: current_rdtsc;
core1: current_rdtsc + ipi speed= ;
coreN: current_rdtsc + ipi speed * N;

Since ipi values are sent alternately in a loop = to core0, in the version with get_s_time_fixed, we get the following local_= stime calculation format.

<= span class=3D"gmail-jCAhz gmail-ChMk0b">coreN:= local_stime =3D local_stime + scale_delta((current_rdtsc + (ipi_speed * N)= ) =E2=80=93 local_rdtsc);

<= span class=3D"gmail-jCAhz gmail-ChMk0b">This m= eans the time on each core will differ by ipi_speed * N. And since we'r= e using the values of the previous local_stime, the difference will accumul= ate because the previous local_stime was also offset. In the versi= on with scale_delta, we get:

cor= eN: local_stime =3D scale_delta(current_rdtsc + (ipi_speed * N));

This means there will still be a differen= ce, but it won't accumulate, and the offsets will remain within normal = limits.

If it's still unclea= r: If your local_stime in get_s_time_fixed is offset relative to other core= s, then the fact that rdtsc_ordered and local_tsc are not offset doesn'= t change anything, since you're using the delta relative to local_stime= .

core0_local_stime + (rdtsc_ord= ered() - local_tsc) !=3D core1_local_stime + (rdtsc_ordered() - local_tsc);= //=C2=A0Even if rdtsc_ordered() and local_tsc are equal acro= ss cores.

On 96-core configurations, up to a m= illisecond of latency can accumulate in local_stime over a week of operatio= n, and this is a significant difference. This is due to the fact t= hat I use cpufreq=3Dxen:performance max_cstate=3D1 , meaning that in my con= figuration, local_stime is never overwritten by master_stime.=

Thanks.=C2=A0

On= Mon, Jan 12, 2026 at 2:45=E2=80=AFPM Jan Beulich <jbeulich@suse.com> wrote:
On 12.01.2026 11:31, Anton Markov wrote: > Bit rounding isn't the main issue; the difference in ipi delivery = to the
> cores accumulates due to the ordering. Replacing get_s_time_fixed with=
> scale_delta in time_calibration_rendezvous_tail should be sufficient. = This
> configuration won't accumulate errors, but bit rounding can still = cause a
> significant difference from calibration to calibration, but it's n= ot as
> significant.

That invocation of get_s_time_fixed() reduces to scale_delta() (without
further rdtsc_ordered()), as non-zero at_tsc is passed in all cases. IOW it's not quite clear to me what change you are suggesting (that would actually make a functional difference).

Btw, your prior response was too hard to properly read, due to excess blank=
lines with at the same time squashed leading blanks. Together with your
apparent inability to avoid top-posting, I think you really want to adjust<= br> your mail program's configuration.

Jan

> On Fri, Jan 9, 2026 at 7:11=E2=80=AFPM Anton Markov <akmarkov45@gmail.com> wr= ote:
>
>> You're right. These aren't interrupts in get_s_time_fixed,= but rather a
>> cumulative error in the sequence due to integer rounding. I added = logging
>> of the current local_stime to local_time_calibration and noticed t= hat the
>> timestamp between cores is gradually increasing. If the server has= been
>> running for weeks, this could be a very large value.
>>
>>
>> ```
>>
>> @@ -1732,6 +1753,8 @@ static void cf_check local_time_calibration(= void)
>>
>> if ( boot_cpu_has(X86_FEATURE_CONSTANT_TSC) )
>>
>> {
>>
>> /* Atomically read cpu_calibration struct and write cpu_time struc= t. */
>>
>> + printk("update stime on time calibrate %d, %lu -> %lu (%= lu, %lu)\n",
>> smp_processor_id(), t->stamp.local_stime, c->local_stime, >>
>> + t->last_seen_ns, t->last_seen_tsc);
>>
>> local_irq_disable();
>>
>> t->stamp =3D *c;
>>
>> local_irq_enable();
>>
>> ```
>>
>>
>> 2 hours of work:
>>
>>
>> ```
>>
>> (XEN) update stime on time calibrate 0, 8564145820102 -> 856514= 5861597
>> (8565145862216, 0)
>>
>> (XEN) update stime on time calibrate 1, 8564145820129 -> 856514= 5861609
>> (8565145863957, 0)
>>
>> (XEN) update stime on time calibrate 3, 8564145819996 -> 856514= 5861491
>> (8565145864800, 0)
>>
>> (XEN) update stime on time calibrate 2, 8564145820099 -> 856514= 5861609
>> (8565145865372, 0)
>>
>>
>> 8565145861609 - 8565145861491 =3D 115 * 3 (3.00 GHz) =3D 345 lag >>
>> ```
>>
>>
>> 6 hours of work:
>>
>> ```
>>
>> (XEN) update stime on time calibrate 0, 22914730829200 -> 22915= 730869993
>> (22915730870665, 0)
>>
>> (XEN) update stime on time calibrate 1, 22914730829073 -> 22915= 730869889
>> (22915730870693, 0)
>>
>> (XEN) update stime on time calibrate 2, 22914730829052 -> 22915= 730869841
>> (22915730872231, 0)
>>
>> (XEN) update stime on time calibrate 3, 22914730828892 -> 22915= 730869696
>> (22915730872096, 0)
>>
>>
>> 22915730869993 - 22915730869696 =3D 297 * 3 (3.00 GHz) =3D 891 lag=
>>
>> ```
>>
>>
>> Clarification, according to my xen settings:
>>
>> ```
>>
>> ucode=3Dscan dom0_mem=3D53923M,max:53923M dom0_max_vcpus=3D4-96 do= m0_vcpus_pin=3D0
>> force-ept=3D1 ept=3Dno-ad,no-pml hap_1gb=3D0 hap_2mb=3D0 altp2m=3D= 1
>> hpet=3Dlegacy-replacement smt=3D1 spec-ctrl=3Dno gnttab_max_frames= =3D512
>> cpufreq=3Dxen:performance max_cstate=3D1 sched=3Dcredit sched-gran= =3Dcpu apicv=3D0
>> sched_credit_tslice_ms=3D5 sched_ratelimit_us=3D500
>>
>> ```
>>
>>
>> Processors I tested on:
>>
>>
>> ```
>>
>> Intel(R) Core(TM) i5-3330 CPU @ 3.00GHz
>>
>>
>> Flags: fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush ac= pi mmx
>> fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nop= l
>> nonstop_tsc cpuid tsc_known_freq pni pclmulqdq monitor est ssse3 c= x16
>> sse4_1 sse4_2 popcnt aes xsave avx f16c hypervisor lahf_lm cpuid_f= ault
>> fsgsbase erms xsaveopt arch_capabilities
>>
>> ```
>>
>> ```
>>
>> Intel(R) Xeon(R) Gold 5318Y CPU @ 2.10GHz x2 (NUMA)
>>
>>
>> Flags: fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush ac= pi mmx
>> fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nop= l
>> nonstop_tsc cpuid tsc_known_freq pni pclmulqdq monitor est ssse3 f= ma cx16
>> sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor la= hf_lm abm
>> 3dnowprefetch cpuid_fault ibpb fsgsbase bmi1 avx2 bmi2 erms rtm av= x512f
>> avx512dq rdseed adx avx512ifma clflushopt clwb avx512cd sha_ni avx= 512bw
>> avx512vl xsaveopt xsavec xgetbv1 avx512vbmi avx512_vbmi2 gfni vaes=
>> vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid fsrm m= d_clear
>> arch_capabilities
>>
>> ```
>>
>>
>> Next I moved the code to r3 to speed up playback:
>>
>>
>> ```
>>
>> #include <stdint.h>
>>
>> #include <stdio.h>
>>
>>
>> static __inline__ unsigned long long rdtsc(void)
>>
>> {
>>
>> unsigned hi, lo;
>>
>> __asm__ __volatile__ ("rdtsc" : "=3Da"(lo), &q= uot;=3Dd"(hi));
>>
>> return ( (unsigned long long)lo)|( ((unsigned long long)hi)<<= ;32 );
>>
>> }
>>
>>
>> #define MILLISECS(_ms) ((int64_t)((_ms) * 1000000ULL))
>>
>>
>> struct cpu_time_stamp {
>>
>> uint64_t local_tsc;
>>
>> int64_t local_stime;
>>
>> int64_t master_stime;
>>
>> };
>>
>>
>> struct time_scale {
>>
>> int shift;
>>
>> uint32_t mul_frac;
>>
>> };
>>
>>
>>
>> static inline uint32_t div_frac(uint32_t dividend, uint32_t diviso= r)
>>
>> {
>>
>> uint32_t quotient, remainder;
>>
>> asm (
>>
>> "divl %4"
>>
>> : "=3Da" (quotient), "=3Dd" (remainder)
>>
>> : "0" (0), "1" (dividend), "r" (divi= sor) );
>>
>> return quotient;
>>
>> }
>>
>>
>>
>> void set_time_scale(struct time_scale *ts, uint64_t ticks_per_sec)=
>>
>> {
>>
>> uint64_t tps64 =3D ticks_per_sec;
>>
>> uint32_t tps32;
>>
>> int shift =3D 0;
>>
>>
>> while ( tps64 > (MILLISECS(1000)*2) )
>>
>> {
>>
>> tps64 >>=3D 1;
>>
>> shift--;
>>
>> }
>>
>>
>> tps32 =3D (uint32_t)tps64;
>>
>> while ( tps32 <=3D (uint32_t)MILLISECS(1000) )
>>
>> {
>>
>> tps32 <<=3D 1;
>>
>> shift++;
>>
>> }
>>
>>
>> ts->mul_frac =3D div_frac(MILLISECS(1000), tps32);
>>
>> ts->shift =3D shift;
>>
>> }
>>
>>
>>
>> uint64_t scale_delta(uint64_t delta, const struct time_scale *scal= e)
>>
>> {
>>
>> uint64_t product;
>>
>>
>> if ( scale->shift < 0 )
>>
>> delta >>=3D -scale->shift;
>>
>> else
>>
>> delta <<=3D scale->shift;
>>
>>
>> asm (
>>
>> "mulq %2 ; shrd $32,%1,%0"
>>
>> : "=3Da" (product), "=3Dd" (delta)
>>
>> : "rm" (delta), "0" ((uint64_t)scale->mul_f= rac) );
>>
>>
>> return product;
>>
>> }
>>
>>
>> #define _TS_MUL_FRAC_IDENTITY 0x80000000UL
>>
>>
>> static inline struct time_scale scale_reciprocal(struct time_scale= scale)
>>
>> {
>>
>> struct time_scale reciprocal;
>>
>> uint32_t dividend;
>>
>>
>> dividend =3D _TS_MUL_FRAC_IDENTITY;
>>
>> reciprocal.shift =3D 1 - scale.shift;
>>
>> while ( dividend >=3D scale.mul_frac )
>>
>> {
>>
>> dividend >>=3D 1;
>>
>> reciprocal.shift++;
>>
>> }
>>
>>
>> asm (
>>
>> "divl %4"
>>
>> : "=3Da" (reciprocal.mul_frac), "=3Dd" (divide= nd)
>>
>> : "0" (0), "1" (dividend), "r" (scal= e.mul_frac) );
>>
>>
>> return reciprocal;
>>
>> }
>>
>>
>>
>> int64_t get_s_time_fixed(const struct cpu_time_stamp *t, const str= uct
>> time_scale *ts, uint64_t at_tsc)
>>
>> {
>>
>> uint64_t tsc, delta;
>>
>>
>> if ( at_tsc )
>>
>> tsc =3D at_tsc;
>>
>> else
>>
>> tsc =3D rdtsc();
>>
>> delta =3D tsc - t->local_tsc;
>>
>> return t->local_stime + scale_delta(delta, ts);
>>
>> }
>>
>>
>> int main() {
>>
>>
>> struct cpu_time_stamp ct;
>>
>> struct time_scale ts;
>>
>> struct time_scale back;
>>
>>
>> uint64_t start =3D rdtsc();
>>
>>
>> set_time_scale(&ts, 3000000000);
>>
>> back =3D scale_reciprocal(ts);
>>
>>
>> ct.local_tsc =3D start;
>>
>> ct.local_stime =3D scale_delta(start, &ts);
>>
>>
>> while (1) {
>>
>> uint64_t new_tsc =3D rdtsc();
>>
>> ct.local_stime =3D get_s_time_fixed(&ct, &ts, new_tsc); >>
>> ct.local_tsc =3D new_tsc;
>>
>>
>> uint64_t tmp_tsc =3D rdtsc();
>>
>> printf("%lu %lu\n", tmp_tsc, scale_delta(get_s_time_fixe= d(&ct, &ts,
>> tmp_tsc), &back));
>>
>> }
>>
>>
>> return 0;
>>
>> }
>>
>> ```
>>
>>
>> It's enough to run the loop for 10-20 seconds to see the probl= em.
>> scale_delta rounds the least significant bits during calculation, = which
>> causes the error to accumulate, at different rates on different co= res,
>> depending on the least significant bits at the time of calibration= .
>>
>>
>> Now let's talk about why dwm reacts this way. When a snapshot = is reversed,
>> last_guest_time in hvm_get_guest_time_fixed is set to 0, which doe= sn't
>> prevent time from flowing backwards. This means that cache_tsc_off= set in
>> hvm_get_guest_tsc_fixed may be configured correctly on one physica= l core,
>> but due to shedding on a physical core with a lagging tsc, the gue= st may
>> occasionally see a tsc value lower than it saw before the snapshot= was
>> reversed. If this happens to the dwm code, it terminates with an e= rror.
>>
>>
>> A quick solution to this problem might be to save the last_seen_ts= c
>> parameter in a snapshot for each core, followed by validation.
>>
>>
>> The correct solution is to remove the rounding of the least signif= icant
>> bits from the sequence.
>>
>> On Wed, Jan 7, 2026 at 11:02=E2=80=AFAM Jan Beulich <jbeulich@suse.com> wrot= e:
>>
>>> On 06.01.2026 21:10, =D0=90=D0=BD=D1=82=D0=BE=D0=BD =D0=9C=D0= =B0=D1=80=D0=BA=D0=BE=D0=B2 wrote:
>>>> Hi, I'm not sure about the other places. In hvm_load_c= pu_ctxt
>>>> (xen/arch/x86/hvm/hvm.c ), it was easy to catch because >>>> process_pending_softirqs is frequently called there, which= in turn
>>>> processes softirqs from the timer (where the timestamp is = updated).
>>>> After I fixed sync_tsc in hvm_load_cpu_ctxt, the problem s= topped
>>>> reproducing under no load. However, when the number of vCP= Us is 4 times
>>>> greater than the number of CPUs (under heavy load), the pr= oblem rarely
>>>> reoccurs (mostly during snapshot restores during
>>>> process_pending_softirqs calls), and this is no longer a s= imple case.
>>> If
>>>> get_s_time_fixed can indeed be interrupted during executio= n after
>>>> rdtsc_ordered, then the current fix is insufficient. It= 9;s necessary to
>>>> atomically copy "t->stamp" to the stack using= local_irq_disable and
>>>> local_irq_enable (as in local_time_calibration), and then = work with the
>>>> copy, confident in its lifetime and immutability. But unti= l
>>>> get_s_time_fixed is proven to be interruptible, this is pr= emature, so
>>>> your fix is sufficient. I think I need more information an= d testing to
>>>> say more.
>>>
>>> While the cpu_calibration per-CPU variable is updated from IRQ= context,
>>> the cpu_time one isn't. Hence t->stamp's contents c= annot change behind
>>> the back of get_s_time_fixed(). I wonder whether ...
>>>
>>>> Regarding the other scale_delta calls, if they include val= ues
>>>> calculated from externally saved tsc values that could hav= e become
>>>> stale during the process_pending_softirqs call, this defin= itely needs
>>> to
>>>> be fixed.
>>>
>>> ... another similar issue (possibly one not included in the se= t of
>>> remarks I have in the patch, as none of those look related to = what you
>>> describe) might be causing the remaining, more rare problems y= ou say you
>>> see. That set of remarks is actually a result of me going over= all other
>>> scale_delta() calls, but of course I may have got the analysis= wrong.
>>>
>>> As to using 4 times as many vCPU-s as there are pCPU-s (and th= en heavy
>>> load) - while I don't think we have a support statement fo= r such upstream
>>> (when probably we should), iirc for our (SUSE's) products = we would
>>> consider that unsupported. Just fyi.
>>>
>>> Also, btw, please don't top-post.
>>>
>>> Jan
>>>
>>
>

--00000000000035eda40648304e7a-- From xen-devel-bounces@lists.xenproject.org Mon Jan 12 12:49:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 12:49:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200202.1516190 (Exim 4.92) (envelope-from ) id 1vfHMO-0001iN-Di; Mon, 12 Jan 2026 12:49:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200202.1516190; Mon, 12 Jan 2026 12:49:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfHMO-0001iG-B3; Mon, 12 Jan 2026 12:49:28 +0000 Received: by outflank-mailman (input) for mailman id 1200202; Mon, 12 Jan 2026 12:49: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 1vfHMM-0001i6-NB for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 12:49:26 +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 1c780a4a-efb5-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 13:49:20 +0100 (CET) Received: by mx.zohomail.com with SMTPS id 1768222156672430.2579407866401; Mon, 12 Jan 2026 04:49:16 -0800 (PST) Received: by mail-oi1-f176.google.com with SMTP id 5614622812f47-459a258561cso3304680b6e.0 for ; Mon, 12 Jan 2026 04:49:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1c780a4a-efb5-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; t=1768222157; cv=none; d=zohomail.com; s=zohoarc; b=hXk2cYuCAVD7S3fOsXKJ6SUcL0t0JHcjy/xvIM0piGzS7Ro8DeKCkWO5LdHyYBl0pSo6iI3UxOci3IxOFQneXebqi/Y3IFGe4bAmlCC+bVeOvaCUhOzsBR6wBNGRQnJwDqO0sL2fSZbQyZccudWG7dAVOpEKOwCOhRY6GJ7ESJ4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1768222157; 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=u1kWYzkrU0/j8va/sM5e2F77znTAOuhK0E5ZWCTNux4=; b=Q81VOyiC0Q4rTl4cIRpWs4i4GJvGCfHHYHsU0WGBxm3yHBIO0QeoHVvd2feijlbIzd3j5KAX1lhR/zaOB4YpN+0FSjNSlVu/OruW9Ur6XCM+dx3ddS9XS/SHwXdjmEWg+ORjWHUDoFpfwquSKhBTVt0NTjkUs8EHjXDOlEHBMJM= 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=1768222157; 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=u1kWYzkrU0/j8va/sM5e2F77znTAOuhK0E5ZWCTNux4=; b=KMUokDXNApLWuLd8Vw4iez4mNxn8OFJu9yqjDNKUPff0RD2udHN7qYCAjshlshrJ 0wKpU6P16uR9DOlB/48cjt2qKlepm3vSYqRnRGvENMo8nRmycbVTabwKcGf23rjOoJc uuIN5G+7beIcJmpucJ4lcVmTBL/2jpsCFw4vF0OY= X-Forwarded-Encrypted: i=1; AJvYcCXcg0u28iQ0tskpHywRcPg3CDxX74A9ZDavqXCStfHsQ/9geyPJjFb4eO7Vf5VOuZryCyVkTVrCPcE=@lists.xenproject.org X-Gm-Message-State: AOJu0YwHBGR+tOg8NCE1h+qD9xT8V2Xw4qB49kSIamsPOPzKSAR3By4p 4Hu57JEMhYT0YPkAkE9kBQoYt2s2ladx1XkJsiAfMgoAljkVOetwow5mFTY/3V8HKCQopRFAFsx KJD3xvpbk99RhlRAOLjnIB/MXe+tlXjQ= X-Google-Smtp-Source: AGHT+IE98rGreMUq3ALEK9FZHHogEn1el6PAbKJCG4SZ9qhsPFatThPDU5uihdL6qVpmHO0eNKJP0btqha1LKtCBVIE= X-Received: by 2002:a05:6808:c165:b0:450:826e:5df1 with SMTP id 5614622812f47-45a6b82101bmr8606193b6e.19.1768222155807; Mon, 12 Jan 2026 04:49:15 -0800 (PST) MIME-Version: 1.0 References: <1916d0a7-ff9a-49f1-8564-2767226fca9c@citrix.com> In-Reply-To: From: Tamas K Lengyel Date: Mon, 12 Jan 2026 07:48:39 -0500 X-Gmail-Original-Message-ID: X-Gm-Features: AZwV_QiiwpTU35XuNFWwR1rCbzj4AhNNdad04B2U7AnJbgtn_YJPmfoCsxgdifY Message-ID: Subject: Re: [PATCH] x86/altp2m: altp2m_get_effective_entry() should honor ap2m->default_access To: Jan Beulich Cc: =?UTF-8?Q?Petr_Bene=C5=A1?= , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="0000000000007b247d0648304d98" --0000000000007b247d0648304d98 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 12, 2026 at 7:12=E2=80=AFAM Jan Beulich wro= te: > On 12.01.2026 13:09, Petr Bene=C5=A1 wrote: > > On Mon, Jan 12, 2026 at 12:24=E2=80=AFPM Jan Beulich wrote: > >> On 12.01.2026 12:18, Andrew Cooper wrote: > >>> On 12/01/2026 11:09 am, Jan Beulich wrote: > >>>> We relatively recently introduced Amends:, which > >>>> may be a suitable fit here. > > > > So, what should be my next steps? Should I re-send the patch where I > > Cc Tamas, use 12-char hashes and replace Fixes with Amends? > > I'd give Tamas a little bit of time to possibly comment, which might then > save one round of re-submission. Thanks for waiting for my review, appreciated! Acked-by: Tamas K Lengyel --0000000000007b247d0648304d98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 12,= 2026 at 7:12=E2=80=AFAM Jan Beulich <jbeulich@suse.com> wrote:
On 12.01.2026 13:09, Petr Bene=C5=A1 wrote:
> On Mon, Jan 12, 2026 at 12:24=E2=80=AFPM Jan Beulich <jbeulich@suse.com> wrote:<= br> >> On 12.01.2026 12:18, Andrew Cooper wrote:
>>> On 12/01/2026 11:09 am, Jan Beulich wrote:
>>>> We relatively recently introduced Amends:, which
>>>> may be a suitable fit here.
>
> So, what should be my next steps? Should I re-send the patch where I > Cc Tamas, use 12-char hashes and replace Fixes with Amends?

I'd give Tamas a little bit of time to possibly comment, which might th= en
save one round of re-submission.

Thanks for= waiting for my review, appreciated!

Acked-by: Tam= as K Lengyel <tamas@tklengyel.com= >=C2=A0
--0000000000007b247d0648304d98-- From xen-devel-bounces@lists.xenproject.org Mon Jan 12 12:57:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 12:57:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200229.1516211 (Exim 4.92) (envelope-from ) id 1vfHTv-0003rs-FL; Mon, 12 Jan 2026 12:57:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200229.1516211; Mon, 12 Jan 2026 12:57:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfHTv-0003rl-CS; Mon, 12 Jan 2026 12:57:15 +0000 Received: by outflank-mailman (input) for mailman id 1200229; Mon, 12 Jan 2026 12:57:14 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfHTu-0003rf-69 for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 12:57:14 +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 3687a98c-efb6-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 13:57:12 +0100 (CET) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-65089cebdb4so8429107a12.0 for ; Mon, 12 Jan 2026 04:57:12 -0800 (PST) Received: from EPUAKYIW02F7.. (pool185-5-252-44.as6723.net. [185.5.252.44]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b86ebfd007fsm736803866b.31.2026.01.12.04.57.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jan 2026 04:57:11 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3687a98c-efb6-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768222632; x=1768827432; 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=zBY9S+KFYmQiPJ56+D97Psmms27C+LWFU82ctDGNHow=; b=UYWt1dndNihBF2JHPs/U9JhGkT4FbdE7ZDKek/chfdUhSyXa66Q3Ah81MqWq1OVfph 7JSIk7TvyXA1fX+xB6mvL+WlSdLuEhxbi+EOyan/v/OpVFQsasZuK2k7sGNvrqucQcCW enOjd76TywYkabxIIwhQpdX4t4gKGOl8yX0xxP3kvjNaRgyFIRW36Xa4sM8DOt/XmsOk EfMEul5B1CZ8jS/UrjQ+TbaoQIBF+zjKqj/BPSk0gzS6R+LfZD/xaBzlVYUpZ4RSLpGZ Z6gBj/va/cCZwOyHU/p+zYwdonhYebo2qbocqukx+cnFSw2hw99UAkSEWHTDUzU15Vgn BAoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768222632; x=1768827432; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=zBY9S+KFYmQiPJ56+D97Psmms27C+LWFU82ctDGNHow=; b=HVZBO0S47QFtmBiNekZASNgH1bLQCTsyc/bvq9yXkELoYENgte/s1+luhKv3vDvjrs rmPGbm35QoeHjMYJ0jEwide4ICtJrPo15teA6SULfz4tK2KTuv9as0p12oqQXa5uMjl7 DfgMi9rlAFIb6lpf4NdrypVeN8Ej7YkFyxWylQjEtt/7bfMOvhfFKYNK4krfLxUeiZMR k4dYPjYvSpcwwzmEVbxiKGDiD0C86Hu0mtyqRH8NsYjkhPL3fpGR8DFRgFcyMr/ou8vG P0P9LNjTKxu9J9/5kvRjQFcekdZ1ZnC3q46Vs+Sf1WwekYh7veyDiG1Eek79jO9ghnMt 3R6g== X-Gm-Message-State: AOJu0Yw30CtT5L5Xe7bLw7Rsjf3ztstTKF9Z93tyCRS22F0wghfvpmQm v9BvartqfBc6+yW+v16e1E1dGjYw8xYMIqUNsF0hHsC/nVoclvZX3wtbhVt/Uw== X-Gm-Gg: AY/fxX4MiHeiYIdm0PjDdC0g+p+kRWDVk3qzolKMSCdEhiXYwa46+oiS1of5FLKYFUv RiHqqO7W2Y9+AckES1qSFSVFC3hCtoYlk1sf6XJc3hmIkjVi8xaRYsZ0Ma2u+86LyHLlIFb6Vwr 3CXxJLPO7jtQmE8MVzVccI1f/IHHbAoU0aCKyUKcYu5P6B4OezafB5ja75JJ5jzwHfYMgDuRRaI Zj38wpLKbkfMNGPEN+QKgCbV9Bvsb3Tq3hvlsXw/QFLLdMrmLGQMg5h+ecTpiMkOKbb4x3mIBTM 1u2SYBTP8n/48N6EKhO90C2HdWzYEGQ5/zWb/acADcpk/K898Sp60GN38iKqlDBQCdIBvl2FxST wEwTASunYtgxNV37iCUzocMcAZtAZ+neJpICNN3ivOhPvz555eRiqXQJZ31/9MlKqKkNxcapQ48 xgCEbtVK651aQsH7/g+t/dBZxHD2vZujOzSDMPPi4ujxk= X-Google-Smtp-Source: AGHT+IE4Y1tT+YwHM8rTCpBoriXh/dfRZwckJV0pJNuP8LyW1+Hqfz9HVOPxinrnk9+Ri0M5sTdf3A== X-Received: by 2002:a17:907:3d0b:b0:b83:1326:7d45 with SMTP id a640c23a62f3a-b8445345f6dmr1801522866b.32.1768222631515; Mon, 12 Jan 2026 04:57:11 -0800 (PST) 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: ignore spurious interrupts from virtual timer Date: Mon, 12 Jan 2026 14:50:02 +0200 Message-ID: <436a0405a9482dadce7f7cdb1e9721ee461f26a7.1768219676.git.mykola_kvach@epam.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Mykola Kvach If a spurious virtual timer interrupt occurs (i.e. the interrupt fires but CNTV_CTL_EL0 does not report it as pending), Xen masks the virtual timer and injects the vtimer IRQ into the guest. For Linux guests, the timer interrupt is unmasked only after programming a new CVAL value from the timer interrupt handler. When the interrupt is not reported as pending, the handler can skip that programming step, leaving the timer masked and stalling the affected CPU. This patch mirrors the Linux arm generic timer handler: if the interrupt fires but the pending bit is not set, treat it as spurious and ignore it. This issue is reproducible under heavy load on the R-Car X5H board (Cortex-A720AE r0p0). Signed-off-by: Mykola Kvach --- xen/arch/arm/include/asm/perfc_defn.h | 7 ++++--- xen/arch/arm/time.c | 11 ++++++++++- 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/xen/arch/arm/include/asm/perfc_defn.h b/xen/arch/arm/include/asm/perfc_defn.h index effd25b69e..f83989d95a 100644 --- a/xen/arch/arm/include/asm/perfc_defn.h +++ b/xen/arch/arm/include/asm/perfc_defn.h @@ -69,9 +69,10 @@ PERFCOUNTER(ppis, "#PPIs") PERFCOUNTER(spis, "#SPIs") PERFCOUNTER(guest_irqs, "#GUEST-IRQS") -PERFCOUNTER(hyp_timer_irqs, "Hypervisor timer interrupts") -PERFCOUNTER(virt_timer_irqs, "Virtual timer interrupts") -PERFCOUNTER(maintenance_irqs, "Maintenance interrupts") +PERFCOUNTER(hyp_timer_irqs, "Hypervisor timer interrupts") +PERFCOUNTER(virt_timer_irqs, "Virtual timer interrupts") +PERFCOUNTER(virt_timer_spurious_irqs, "Virtual timer spurious interrupts") +PERFCOUNTER(maintenance_irqs, "Maintenance interrupts") PERFCOUNTER(atomics_guest, "atomics: guest access") PERFCOUNTER(atomics_guest_paused, "atomics: guest paused") diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c index cc3fcf47b6..d18d6568bb 100644 --- a/xen/arch/arm/time.c +++ b/xen/arch/arm/time.c @@ -258,6 +258,8 @@ static void htimer_interrupt(int irq, void *dev_id) static void vtimer_interrupt(int irq, void *dev_id) { + register_t ctl; + /* * Edge-triggered interrupts can be used for the virtual timer. Even * if the timer output signal is masked in the context switch, the @@ -271,9 +273,16 @@ static void vtimer_interrupt(int irq, void *dev_id) if ( unlikely(is_idle_vcpu(current)) ) return; + ctl = READ_SYSREG(CNTV_CTL_EL0); + if ( unlikely(!(ctl & CNTx_CTL_PENDING)) ) + { + perfc_incr(virt_timer_spurious_irqs); + return; + } + perfc_incr(virt_timer_irqs); - current->arch.virt_timer.ctl = READ_SYSREG(CNTV_CTL_EL0); + current->arch.virt_timer.ctl = ctl; WRITE_SYSREG(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL_EL0); vgic_inject_irq(current->domain, current, current->arch.virt_timer.irq, true); } -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Jan 12 12:59:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 12:59:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200238.1516222 (Exim 4.92) (envelope-from ) id 1vfHW1-0004YE-Sg; Mon, 12 Jan 2026 12:59:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200238.1516222; Mon, 12 Jan 2026 12:59:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfHW1-0004Y7-OY; Mon, 12 Jan 2026 12:59:25 +0000 Received: by outflank-mailman (input) for mailman id 1200238; Mon, 12 Jan 2026 12:59:24 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfHW0-0004Xy-3s for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 12:59:24 +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 7dc5ae35-efb6-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 13:59:12 +0100 (CET) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-b79f8f7ea43so1339890766b.2 for ; Mon, 12 Jan 2026 04:59:12 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a27c760sm1967564466b.24.2026.01.12.04.59.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 04:59:11 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7dc5ae35-efb6-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768222752; x=1768827552; 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=YcLjaSDmt8zdixcAkv3iQEjuW1yWLXi7sYbeFkeBBK8=; b=Q7u71d0Nb+Rovqk+UZB9d7kIGyPkPLJEwt3vaU6a5osCzP0o+qZ/AgRPK7CRLeqZ6Y N/WRDy3YKUaSn6tbGEIvrAf/CI0n6+M55H/dn2ew5HPdhgBc8wDEibqAmsmEj6zgzMq1 lBX65s6wIZWYHbpOmU6/ozVN2HgWVizcWZqGJdqqWt+5F5gXH0gCKYVkZque/G6fjaik obT4AKyOUAO5iEQ689qQC2NOvo4aF2u85/bwX1OzMqS9GSqyimmi4r3xKV1/FaGZRcpG eUDvPV14wuE4D4A13KA+R8Ex4e7+TDna7Mh3Jt25t5yxUXCFvxlUYjBY6cjkr0wB9XWv lqBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768222752; x=1768827552; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YcLjaSDmt8zdixcAkv3iQEjuW1yWLXi7sYbeFkeBBK8=; b=vR7YuduIB3WKfCbvkSCU25ctq0OezUkrygVm3CeIDKeZReCA5c7CJm/QO/FboJbdGm GwZEaqoTue5CydqopWomIV2NEY1kQBe/uDUHcsYcM2QhJ8j4A6WdlmCPuRSt+QEcG0Pz 01vvzAZK02CDbU5SoVdA91hWa/gynu+3HyDTUW3OD3Gge3FqepJEskGytkZzQgBR/CQ1 zA6pW0G9VF15OLrdXkeR7TFON3OiC5OpZzkAJcfSUOORwEpKum+DIIchdmcMrMmK+OS0 WGikHH0BQfaBifxnliztjNrCekTCQmPCT+cqCpKfnF0RfpVdoYXxXyYWUCogP/g6XPYF psrA== X-Forwarded-Encrypted: i=1; AJvYcCWE2vtnldGBkHiMok/ZnihNVKtnkBxebkPQTsS2V5KspuavofNLOYHTo+3glNak06HwtOxwsPwgf0w=@lists.xenproject.org X-Gm-Message-State: AOJu0YygQ+D8L/OMAZHkBd72ghs/4W+tbwIubQWy02eNdpel6H67iWPY 8HAOGzbW8HS2bXSjpeerSx3bZcx2fRYLHWioleRr+uk4sumbrTGEkoY4 X-Gm-Gg: AY/fxX4fLo5sEifHD1alJtVylR1hp9w9moMTAP4CLlFYEdjR1pL8M5Ozwp+GGdn9DaA 4vVsF31QbXktB5Co0MARurZZFx0thBboUcNORucCVAnky4zg6r/E+XGvNDEVrpVh1jwk/VsS1pE 7GsJQUcdsPrNyCIl7v/y7s8/A3iLyNFu/Gb+xajycyvtO06HMrCMlbid/LcegLzgZ665VzhoZrY 5VZvhqMBCPgSFfJcideQ7YIOTwPkIbviY8s2CUYNCRU5epnhuU2zJ0ZluV0FYm6k4vC+RMH4BLv NxWiVLAi7Ez4hW4s+H14sCJYKRM2Eaua5AdwhHZAYviapJZj87wQCDCqvBj5LXCR38iCeq3qHdz CZeiGG8eyZpaaseM6e0yod6ucqKfqdg31+5cg+RBreE9LjEnRgqGFHgcHLe77qkycQgIXcBFXdG 3YC8l6X92pf5XXDJWFncDDdr81C1hf1WbDXrevwAn4opntqVxa1n2WC++C8aIapmI= X-Google-Smtp-Source: AGHT+IHTRMgeK+LK5effZyjh5DKTZshLCckLCGliGW9d0NZDvXw60JbQj237teQWc9zfv133lRMa+g== X-Received: by 2002:a17:906:fe4c:b0:b73:826a:9102 with SMTP id a640c23a62f3a-b8444fd0a3dmr1775800666b.49.1768222751304; Mon, 12 Jan 2026 04:59:11 -0800 (PST) Message-ID: <7ba4bcfe-59d3-43f3-adb4-207424dc1713@gmail.com> Date: Mon, 12 Jan 2026 13:59:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 03/15] xen/riscv: implement vcpu_csr_init() To: Jan Beulich Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/7/26 9:46 AM, Jan Beulich wrote: > On 24.12.2025 18:03, Oleksii Kurochko wrote: >> Implement function to initialize VCPU's CSR registers to delegate handling >> of some traps to VS-mode ( guest ), enable vstimecmp for VS-mode, and >> allow some AIA-related register (thier vs* copies ) for VS-mode. > The henvcfg setting isn't covered here at all, unless I'm failing to make the > respective association. Nor is the setting of SMSTATEEN0_HSENVCFG in hstateen0. > > Overall it feels like the description here is too terse anyway, as the bits > set (or not) are a pretty crucial thing for running guests. Then again maybe > this is just me, for not being a RISC-V person ... I will add more details to commit message then. > >> --- a/xen/arch/riscv/domain.c >> +++ b/xen/arch/riscv/domain.c >> @@ -3,6 +3,67 @@ >> #include >> #include >> >> +#include >> +#include >> +#include >> + >> +static void vcpu_csr_init(struct vcpu *v) >> +{ >> + unsigned long hedeleg, hideleg, hstatus; >> + >> + hedeleg = 0; >> + hedeleg |= (1U << CAUSE_MISALIGNED_FETCH); >> + hedeleg |= (1U << CAUSE_FETCH_ACCESS); >> + hedeleg |= (1U << CAUSE_ILLEGAL_INSTRUCTION); >> + hedeleg |= (1U << CAUSE_MISALIGNED_LOAD); >> + hedeleg |= (1U << CAUSE_LOAD_ACCESS); >> + hedeleg |= (1U << CAUSE_MISALIGNED_STORE); >> + hedeleg |= (1U << CAUSE_STORE_ACCESS); >> + hedeleg |= (1U << CAUSE_BREAKPOINT); >> + hedeleg |= (1U << CAUSE_USER_ECALL); >> + hedeleg |= (1U << CAUSE_FETCH_PAGE_FAULT); >> + hedeleg |= (1U << CAUSE_LOAD_PAGE_FAULT); >> + hedeleg |= (1U << CAUSE_STORE_PAGE_FAULT); >> + v->arch.hedeleg = hedeleg; > Wouldn't you better start from setting all of the non-reserved bits, to then > clear the few that you mean to not delegate? Maybe that would be better, but I don’t see much difference, especially if we use the following define: #define HEDELEG_DEFAULT ( BIT(CAUSE_MISALIGNED_FETCH, U) | ... ) It would still be just one instruction to write the value to|hedeleg|. (I think the compiler will likely produce the same optimization with the current implementation.) > Then again I'm not quite sure > whether the set of CAUSE_* in the header file is actually complete: MCAUSE > also can hold the values 16, 18, and 19. Then 14 and 17 could be added as well. I see the sense in adding 18 and 19, since they are defined as "software check" and "hardware error." However, I don’t see much value in providing|CAUSE_*| for 14 and 16–17, as they are just reserved and have no specific meaning. I could add something like|CAUSE_RES_14|,|CAUSE_RES_16|,|CAUSE_RES_17|, but since we aren’t actually handling them, I think it’s fine to update|CAUSE_* |only when there is a real use for them, like with 18 and 19. > (Otoh you have CAUSE_MACHINE_ECALL, > which I don't think can ever be observed outside of M-mode.) Good point, It seems like you are right and M-ecall can't be observed outside of M-mode and even more it is marked as read only 0 so it is not expected to be delegated to lower privilige mode, but then I don't know why it was added to "Table 29 Bits of hedeleg that must be writable or must be read-only zero.". > > Also, while it may seem to not matter much, sorting the above by their numeric > values would ease comparison against the full set. I will move "hedeleg |= (1U << CAUSE_BREAKPOINT);" up; all others seems are sorted properly. > >> + hstatus = HSTATUS_SPV | HSTATUS_SPVP; >> + v->arch.hstatus = hstatus; > Why would these (or in fact any) bits need setting here? It could be moved to continue_new_vcpu() where now (in downstream) I have: csr_write(CSR_HSTATUS, vcpu_guest_cpu_user_regs(current)->hstatus); reset_stack_and_jump(return_to_new_vcpu); But I put it here to have vCPU state (all or as much as possible) initialized in one place. > Isn't hstatus written > upon exit from guest context? Setting these bits manually is necessary for the initial entry into a guest context. While it is true that hardware updates hstatus during a trap from a guest, software must set these bits to define the destination state for the subsequent SRET instruction. When a hypervisor prepares to run a guest for the first time, there has been no previous "exit" from that guest to automatically populate the CSRs. Setting these bits is essential for the following reasons: - Defining the target Virtualization Mode (SPV): The SPV bit is used by the SRET instruction to determine the new virtualization mode. If the hypervisor is in HS-mode (V=0) and executes SRET, the hardware sets the new V to the current value of hstatus.SPV. Without manually setting HSTATUS_SPV, the SRET would return the hart to V=0 instead of entering the guest (V=1). - Defining the target Privilege Level (SPVP): The SPVP bit tracks the nominal privilege level (S or U) of the guest. When V=1, this determines if the guest is in VS-mode or VU-mode. - Controlling Hypervisor Load/Store Instructions: SPVP specifically controls the effective privilege of explicit memory accesses made by hypervisor virtual-machine load/store instructions (HLV, HLVX, and HSV). If the hypervisor needs to use these instructions to access guest memory as if it were the guest supervisor, SPVP must be set to 1. But maybe there is no too much sense in this instructions before guest is ran. > >> + hideleg = MIP_VSTIP | MIP_VSEIP | MIP_VSSIP; >> + v->arch.hideleg = hideleg; > Again I think having MIP_VSTIP in the middle (to establish numeric sorting) > would be slightly better. > > Also there's a stray blank after the first |. > >> + /* >> + * VS should access only the time counter directly. >> + * Everything else should trap. >> + */ >> + v->arch.hcounteren |= HCOUNTEREN_TM; > Why are this and ... > >> + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) ) >> + v->arch.henvcfg |= ENVCFG_PBMTE; > ... this using |= but the earlier ones simply = ? Unless there is a specific > reason, consistency is likely preferable. This was overlooked during refactoring; it seems I simply used|=| instead of||=|. The idea is that if it’s the first initialization,|=| should be used; otherwise, for subsequent writes,||=| is used to avoid clearing previous values. I will update this part to use the same pattern consistently throughout this function. > >> + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) >> + { >> + /* >> + * If the hypervisor extension is implemented, the same three bitsare >> + * defined also in hypervisor CSR hstateen0 but concern only the state >> + * potentially accessible to a virtual machine executing in privilege >> + * modes VS and VU: >> + * bit 60 CSRs siselect and sireg (really vsiselect and vsireg) >> + * bit 59 CSRs siph and sieh (RV32 only) and stopi (really vsiph, >> + * vsieh, and vstopi) >> + * bit 58 all state of IMSIC guest interrupt files, including CSR >> + * stopei (really vstopei) >> + * If one of these bits is zero in hstateen0, and the same bit is one >> + * in mstateen0, then an attempt to access the corresponding state from >> + * VS or VU-mode raises a virtual instruction exception. >> + */ >> + v->arch.hstateen0 = SMSTATEEN0_AIA | SMSTATEEN0_IMSIC | SMSTATEEN0_SVSLCT; > What is SVSLCT? Bit 60 is named CSRIND in the spec I'm looking at, and the > commentary above looks to confirm this. This is how OpenSBI called this bit from where riscv_encoding.h was taken. SVSLCT stands for Supervisor Virtual Select, referring to the access control of the siselect and vsiselect registers. > > Also, wouldn't you better keep internal state in line with what hardware > actually supports? CSRIND may be read-only-zero in the real register, in > which case having the bit set in the "cached" copy can be misleading. According to the AIA spec: If extension Smstateen is implemented together with the Advanced Interrupt Architecture (AIA), three bits of state-enable register mstateen0 control access to AIA-added state from privilege modes less privileged than M-mode: bit 60 CSRs siselect, sireg, vsiselect, and vsireg bit 59 all other state added by the AIA and not controlled by bits 60 and 58 bit 58 all IMSIC state, including CSRs stopei and vstopei What I read as if Smstateen is supported then all the bits are supported by hardware, and that is why it is enough to check if Smstateen is supported. But I decided to check what KVM does in the similar case and it seems that I incorrectly read the first line of the mentioned about AIA's spec and it is need another one if-condition: if (riscv_has_extension_unlikely(RISCV_ISA_EXT_SMSTATEEN)) { cfg->hstateen0 |= SMSTATEEN0_HSENVCFG; if (riscv_isa_extension_available(isa, SSAIA)) cfg->hstateen0 |= SMSTATEEN0_AIA_IMSIC | SMSTATEEN0_AIA | SMSTATEEN0_AIA_ISEL; if (riscv_isa_extension_available(isa, SMSTATEEN)) cfg->hstateen0 |= SMSTATEEN0_SSTATEEN0; } > (This may similarly apply to at least hedeleg and hideleg, btw.) Regarding the previous bits, I can understand that it would be an issue: if SSAIA isn’t supported, then it is incorrect to update the corresponding bits of|hstateen0|. However, I’m not really sure I understand what the issue is with|h{i,e}deleg|. All writable bits there don’t depend on hardware support. Am I missing something? > > As to consistency: Further up you use local helper variables (for imo no real > reason), when here you don't. Instead this line ends up being too long. I will update the code to have consistency. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Jan 12 14:04:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 14:04:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200284.1516267 (Exim 4.92) (envelope-from ) id 1vfIXM-0005gp-0O; Mon, 12 Jan 2026 14:04:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200284.1516267; Mon, 12 Jan 2026 14:04:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfIXL-0005gi-Ti; Mon, 12 Jan 2026 14:04:51 +0000 Received: by outflank-mailman (input) for mailman id 1200284; Mon, 12 Jan 2026 14:04:50 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfIXK-0005gW-I9 for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 14:04:50 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vfIXK-0005Zv-1V; Mon, 12 Jan 2026 14:04:50 +0000 Received: from [2a02:8012:3a1:0:11a8:e394:f10a:8204] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vfIXJ-000Gbn-2o; Mon, 12 Jan 2026 14:04:49 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" 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=dqxSLqwpLb9KqemAnIXZnxtoCwfav7em5Y1hfUHJlnY=; b=wYJajwUttQyp8rlSBaBlrzcGBU vbFN2zrt4wsYpVidq/1fw31/QG8zHvOGTO8uxc5SBzx9NaVFkyU0lXw5Q/rxYP0xMOd/ZehQOOspX OX9QFxGIM8bskv5a5X3WS1g02DMnAgrchrurHxpA3S3UkXYwHpmlsX+v3m1oUYhbW4K0=; Message-ID: Date: Mon, 12 Jan 2026 14:04:47 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/arm: ignore spurious interrupts from virtual timer To: Mykola Kvach , xen-devel@lists.xenproject.org Cc: Mykola Kvach , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <436a0405a9482dadce7f7cdb1e9721ee461f26a7.1768219676.git.mykola_kvach@epam.com> Content-Language: en-US From: Julien Grall In-Reply-To: <436a0405a9482dadce7f7cdb1e9721ee461f26a7.1768219676.git.mykola_kvach@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, On 12/01/2026 12:50, Mykola Kvach wrote: > From: Mykola Kvach > > If a spurious virtual timer interrupt occurs (i.e. the interrupt fires > but CNTV_CTL_EL0 does not report it as pending), Xen masks the virtual > timer and injects the vtimer IRQ into the guest. For Linux guests, the > timer interrupt is unmasked only after programming a new CVAL value from > the timer interrupt handler. When the interrupt is not reported as > pending, the handler can skip that programming step, leaving the timer > masked and stalling the affected CPU. I guess this is happening if Linux is trying to modify CVAL with the local interrupt masked? > > This patch mirrors the Linux arm generic timer handler: if the interrupt > fires but the pending bit is not set, treat it as spurious and ignore it. Have you considered fixing properly our virtual timer emulation? I know this requires more code, but at least we are not adding more non-compliant code which requires patching the Guest OS. IIRC there was a series from Stewart to solve it and it was in pretty good shape at the time it was posted. > > This issue is reproducible under heavy load on the R-Car X5H board > (Cortex-A720AE r0p0). > Signed-off-by: Mykola Kvach > --- > xen/arch/arm/include/asm/perfc_defn.h | 7 ++++--- > xen/arch/arm/time.c | 11 ++++++++++- > 2 files changed, 14 insertions(+), 4 deletions(-) > > diff --git a/xen/arch/arm/include/asm/perfc_defn.h b/xen/arch/arm/include/asm/perfc_defn.h > index effd25b69e..f83989d95a 100644 > --- a/xen/arch/arm/include/asm/perfc_defn.h > +++ b/xen/arch/arm/include/asm/perfc_defn.h > @@ -69,9 +69,10 @@ PERFCOUNTER(ppis, "#PPIs") > PERFCOUNTER(spis, "#SPIs") > PERFCOUNTER(guest_irqs, "#GUEST-IRQS") > > -PERFCOUNTER(hyp_timer_irqs, "Hypervisor timer interrupts") > -PERFCOUNTER(virt_timer_irqs, "Virtual timer interrupts") > -PERFCOUNTER(maintenance_irqs, "Maintenance interrupts") > +PERFCOUNTER(hyp_timer_irqs, "Hypervisor timer interrupts") > +PERFCOUNTER(virt_timer_irqs, "Virtual timer interrupts") > +PERFCOUNTER(virt_timer_spurious_irqs, "Virtual timer spurious interrupts") > +PERFCOUNTER(maintenance_irqs, "Maintenance interrupts") > > PERFCOUNTER(atomics_guest, "atomics: guest access") > PERFCOUNTER(atomics_guest_paused, "atomics: guest paused") > diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c > index cc3fcf47b6..d18d6568bb 100644 > --- a/xen/arch/arm/time.c > +++ b/xen/arch/arm/time.c > @@ -258,6 +258,8 @@ static void htimer_interrupt(int irq, void *dev_id) > > static void vtimer_interrupt(int irq, void *dev_id) > { > + register_t ctl; > + > /* > * Edge-triggered interrupts can be used for the virtual timer. Even > * if the timer output signal is masked in the context switch, the > @@ -271,9 +273,16 @@ static void vtimer_interrupt(int irq, void *dev_id) > if ( unlikely(is_idle_vcpu(current)) ) > return; > > + ctl = READ_SYSREG(CNTV_CTL_EL0); > + if ( unlikely(!(ctl & CNTx_CTL_PENDING)) ) For the others, the Armv8 specification names this field ISTATUS. Regardless what I wrote above, the change look alright. Before I ack, can you confirm whether you checked other OSes (I am thinking at least Zephyr) will also ignore spurious interrupt? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Jan 12 14:09:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 14:09:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200315.1516276 (Exim 4.92) (envelope-from ) id 1vfIbZ-0006a6-GD; Mon, 12 Jan 2026 14:09:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200315.1516276; Mon, 12 Jan 2026 14: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 1vfIbZ-0006Zz-D9; Mon, 12 Jan 2026 14:09:13 +0000 Received: by outflank-mailman (input) for mailman id 1200315; Mon, 12 Jan 2026 14:09:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfIbY-0006Ze-ET for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 14:09:12 +0000 Received: from SA9PR02CU001.outbound.protection.outlook.com (mail-southcentralusazlp170130001.outbound.protection.outlook.com [2a01:111:f403:c10c::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 43a1d22a-efc0-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 15:09:10 +0100 (CET) Received: from MN2PR11CA0014.namprd11.prod.outlook.com (2603:10b6:208:23b::19) by IA0PPFAF4999BF6.namprd12.prod.outlook.com (2603:10b6:20f:fc04::be0) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Mon, 12 Jan 2026 14:09:06 +0000 Received: from BL02EPF00021F68.namprd02.prod.outlook.com (2603:10b6:208:23b:cafe::9a) by MN2PR11CA0014.outlook.office365.com (2603:10b6:208:23b::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Mon, 12 Jan 2026 14:08:36 +0000 Received: from satlexmb07.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_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Mon, 12 Jan 2026 14:09:05 +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; Mon, 12 Jan 2026 08:09:03 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 43a1d22a-efc0-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lg5o7Hqbux9j/KCvQ5kgjekaDgyi709z8o9SBGAJyEADr+uElrQcZ12NtbNFYR/19JDmTGJydyjtxkuuj0gWUI/VXGHOVNSMCfDHFa/5OqzFVwywbpSVJZyLITAGwfUwNvndJS8pMFxZenm0sThxb75iTWV37Gx7cyNdKAqGOJkUJKb1wpZCLEv8Ae0GlT+I0ZhA5RFWyBXMG3tKvtHS/PZKQ+frdk0HUFhcHRRVfBx2Ni3y1r+Jljc3/B1eQmONFY2GSBR81eCJfkzRhf7MEFCbpEEnQObVB3zz3fx2SXoRg9bQGeEkp/Yyvh6uAlEeBEnIN+m9TQ9US5VSNxi/hQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=E3pxIqWYN/jIUsRS+Yl3k11oyQPxieIYHxnURhwQgLs=; b=u/ifNzNDWp3Q3nGEcLEoLGDtfAEOWgU5rJl+6r0Bgjz5C4FwIHwbS8Ve8Y0WC1D1lI0//oh9yb2+ZLpTbUkA+mnM8flcQJsV5Vc+r/beD26Z5pw6qSRDZObwQaXjxbZSnB9WuJEPX/+4saGKRmkfijNdpXuzZ2zmlR5nwDGsFICaLC9PufiZ0/BdgPxGczbbHUbpjk+B6vVgfmRL4rfRswSRyrc89TldjcAlIQx77mK1aTRhNnr5VLuuk64+GdMrqNEcY4lt/uKrtSsnyZcpg1JuO3u/9hokaplYOzquH/+w8kp+Sm3ipXvKVZP/wMcw26xYa/4k37Z03sQZKNa8MA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E3pxIqWYN/jIUsRS+Yl3k11oyQPxieIYHxnURhwQgLs=; b=k06SBM3V+doJ2WFna3r+NP0PsLX1u7ve8mzSkRDXZaOHwTaUt5h8gY8OL/mdEp9qWIPE9T9nWWA5yyj/vJdAlXjp4FYM5y4LNLvVaH3esh0bU6O/jIfDpm+rfAyns8Zwuq0qpadjruxtMgpEvTw2RmvNkmVIpdo9rm2HR3MpmuY= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Stefano Stabellini" Subject: [PATCH] x86: Add Kconfig option to use a 32bit TLB clock on debug Date: Mon, 12 Jan 2026 15:08:44 +0100 Message-ID: <20260112140851.55590-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: BL02EPF00021F68:EE_|IA0PPFAF4999BF6:EE_ X-MS-Office365-Filtering-Correlation-Id: e87d31a5-6de5-4e84-571b-08de51e42553 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?4lz40WER0M99L8gwkIHu4aA5k5X4gMNKAASuC40HOJwaSjRSUSed64uuhPA9?= =?us-ascii?Q?prhk5j+9+2lw4LrlV4QYoDEBhjhzqnvyTt6Lb2LMQE+fA1afq6WqquYeQP5d?= =?us-ascii?Q?iVBNdMtUecMmcf5knpJTPuVuyFb3jinE4l2UJixJdZJQvZGKN9DhkKNVtzL4?= =?us-ascii?Q?U6b5tq+8Ysz/hXUsndBa4rmtEPbNkuL04nBVj5RufCnHksQXBTrYXz3Y6kiJ?= =?us-ascii?Q?1gXVNOCyjMbW32te4iFjOb2GlN25T4U4rlLnhiTQ4asPNEzSiTQi60AtxRIH?= =?us-ascii?Q?OP8cJw5rWxURpEIBl84742jQrS3ZBY7ml15JuEEj+BUgEg1eShaDBYi8KxqO?= =?us-ascii?Q?+y3lYHdC3JhGN2zcmMERP3jDZ7PV2KO2/DQFM/h1ihdvo6s7e4Yq5XT2btmc?= =?us-ascii?Q?b42l92vxrBTmRbI48rTa90GqFcULsSJDHty/675mkTU8tCmCERz843Gxqx/P?= =?us-ascii?Q?49EbDptR99v1sxC8hhJQqmfdQCVrJSxlAmamTBL8DLGWiLBL2XC75P56FJuV?= =?us-ascii?Q?dEhDHNC1XMloYv8WWiTVHtkmqr1BIpUPIjlzOau58UJp08/KAWNgzE8SayUY?= =?us-ascii?Q?d8FnEd0mDysKBGeAi+ZHnVtdBO77UMfhf6OQlGnLyqseeOdVTF3f9IrBIRK1?= =?us-ascii?Q?U9ZZ/QkRrNroga8tWBTsuotvCCtWd+/vh17t/ddyL1jIVWnMYV3MxlgDfAUG?= =?us-ascii?Q?fChiLlcWbpYxFMaRUlLKUFgmnbGKjPCo05pwRPdGVAj6xwwQx13EbHrHZuDX?= =?us-ascii?Q?vp582pcKutJ65NyjAcBeVWtRkTyxSKm81+2niv6iP7s0V7ZYvw5NZ1iG+mH0?= =?us-ascii?Q?sNJBjKkUNA6eaYH8+gcqCdLj+rTE8ti6EzGEs0vEl7vPxV4WC21WymXgxLXx?= =?us-ascii?Q?Wb/7Ynr+IXiC4TLZfdT07olkA51ZuE2pCDmZOm1koE8LhUmOq+huJjMPuYyN?= =?us-ascii?Q?4OXGy1UJlU+5SCeMjkK5Yq4g+ydIIXnsBnWrzMdyYILmpsay5skht91rQAJ1?= =?us-ascii?Q?rXudiezFUCRcGKZCfK7mkQqLfbOnzXOkoFo4j1HgvGmjmvBGoLm6OAH02jOJ?= =?us-ascii?Q?KyHWvG55pJHVf6BFB9WiRU4mUW3ulaNkPn5iMYzt+djUlvu/QZXzMGJ7OrQm?= =?us-ascii?Q?KL0g9UyJhCz42SiYiKVH2a91H6x4c0IOp3COdwLHOi/epi6yUJQlUiOPy4nx?= =?us-ascii?Q?HGA5PeqGTWx0qq+wqNnGd1HVP1OA9VXSN3DZX+mGPNjQtQtt9CcHEYZlgV1Y?= =?us-ascii?Q?T0Z1AwVIxA9vSYr4qce6ceHJucOAOhvmgxk9DBypoEpzBo+4qeAlf+6fW0ky?= =?us-ascii?Q?5I6Pg/zSBcSurJWjNsaFzhLEtNz6FesBYXjfuEBVmncnMXlnU5WPY9RH2P9x?= =?us-ascii?Q?qABctdhdtbZ/C0btglX+8/Y+XBgb6uBbdl4/F+pCP8CKkqGHaJ3lY4ZlJ6iQ?= =?us-ascii?Q?tyGRfS4MgjMcPlyxPBdhdK7I09XZ2cbiKuBmhxJsQp88aTb69zbV3VIkXDHl?= =?us-ascii?Q?Jk+Rse2ca80p2hh9chx/uxMxhJkLBH/ytAcbDeIFinkzlgMoNzC89ncwbqfZ?= =?us-ascii?Q?m1LKjc9largGpIJjbMw=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2026 14:09:05.3365 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e87d31a5-6de5-4e84-571b-08de51e42553 X-MS-Exchange-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: BL02EPF00021F68.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PPFAF4999BF6 Debug builds stress the wrapping logic of the TLB clock by narrowing it down to 10 bits. This is inconvenient to test real time workloads on such builds. Add Kconfig option to be able to selectively use the non-stressed behaviour on debug. Signed-off-by: Alejandro Vallejo --- xen/arch/x86/Kconfig.debug | 8 ++++++++ xen/arch/x86/flushtlb.c | 6 +----- 2 files changed, 9 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/Kconfig.debug b/xen/arch/x86/Kconfig.debug index e69de29bb2..ecf5aa4336 100644 --- a/xen/arch/x86/Kconfig.debug +++ b/xen/arch/x86/Kconfig.debug @@ -0,0 +1,8 @@ +config DEBUG_TLB_CLK + bool "TLB clock stressing" + default DEBUG + help + Stress the TLB clock wrapping logic by narrowing down the counter to + just a few bits. On wrap-around a global TLB shootdown takes place. + + Disable to run real-time workloads more reliably on debug builds. diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c index 09e676c151..0d788047c5 100644 --- a/xen/arch/x86/flushtlb.c +++ b/xen/arch/x86/flushtlb.c @@ -20,11 +20,7 @@ #include /* Debug builds: Wrap frequently to stress-test the wrap logic. */ -#ifdef NDEBUG -#define WRAP_MASK (0xFFFFFFFFU) -#else -#define WRAP_MASK (0x000003FFU) -#endif +#define WRAP_MASK (IS_ENABLED(CONFIG_DEBUG_TLB_CLK) ? 0x3FFU : UINT32_MAX) #ifndef CONFIG_PV # undef X86_CR4_PCIDE base-commit: 6238c97ea430706cb4a959b1474ad40a57ed1033 -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Jan 12 14:13:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 14:13:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200348.1516287 (Exim 4.92) (envelope-from ) id 1vfIfP-0008Db-4V; Mon, 12 Jan 2026 14:13:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200348.1516287; Mon, 12 Jan 2026 14:13:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfIfP-0008DU-10; Mon, 12 Jan 2026 14:13:11 +0000 Received: by outflank-mailman (input) for mailman id 1200348; Mon, 12 Jan 2026 14:13:09 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfIfN-0008Ct-9W for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 14:13:09 +0000 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [2a00:1450:4864:20::32f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d1716d36-efc0-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 15:13:07 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-47a95efd2ceso56701935e9.2 for ; Mon, 12 Jan 2026 06:13:07 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d8718b995sm128589425e9.14.2026.01.12.06.13.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 06:13:06 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d1716d36-efc0-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768227187; x=1768831987; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Iu2RZxy2eSFAzQuloT198riRuTgrfD4yqhklsvv3Qfk=; b=KqJj+Y47Uz7AsxpbJRpeMlPS7695e46iYWkyqBFA6ZGZ3BjH/k+OOjVk2TDwussH4z egacukR4iW3fiHV4dMRMCworFW92Kr++vmhb5UtFqwS9mGZTR0lr98QIKTnMLbDxznxQ /nuJ5wDW+2w9/dl/9euSuoK6OrnkqBNFPS1CCQr0hL9cHCQGoTdfYL0z2Vu1/Za+VuGO 5AZbHY7QQfM5e7PP9JcFMfDwY2XTYL5k52+wmgsgLBplJePKzncWKwARqkrWcQ2CZU09 ReMA4g+JxWYijG5hWVI2YeN8JzBRac9fNinqXttlQvWOowt3ytDxHL8dp7089Zs8nQVV 5sPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768227187; x=1768831987; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Iu2RZxy2eSFAzQuloT198riRuTgrfD4yqhklsvv3Qfk=; b=qDzKHX6HyY92shutHOpb7ChB67OOZJIMJdUKNPa9o5TJizCBq9VzCfQDkd9rkBlWwJ bF/99kz1ofujG3JjxVH9z/bwxVoDgRx4AX81RGofLrDX0WvS/ImU9xFeMiu/2A5cZhfT n6BquxVc1hyMpTeNC3gISP8ko4mjkWcFplXWU9nymi7XeHGOFesjkUXIoiMBELZjOnjl ThNnAFGv/JzO2cWSJWxX329OQ2Q1zVCmXH9CArVPHPLNOcAtCtSCDJvnqFhXyROgA7h1 sGK1n8fPHVn0fxlfUOE1yR421z6i8vjxy+rTnpVzJByZ0XJHO4e2GEkYF2+lIABaX5Pp GwDA== X-Forwarded-Encrypted: i=1; AJvYcCVuHGiMoS8W8KznKSlctsN1mpDcfQL+jKYFj/d9qSsY5KRfoQkqvnFDhb6ya2TjnS1CBRN5qdZqcIQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YxH6gAuB6YVuviEQ5vZXfAMLfdPM+8JJMp/TQXy8sUw+LweFhe3 Hm6YHxc/LmdQqCvpJpnTPz3Ct2JpoihWpHP4sbs0lqku8ALB9ozYHfRh2iHOXuvErQ== X-Gm-Gg: AY/fxX6ZB2DV2/aYgTHN0GQ9b5n/q8eAszkve95LKU4MiMDXc3iiMXPrwHQ/Nymuvs3 ir9heLw8nTIhFhkFcAdaVDgmLxtrKHE9L2JM0xfl8RMMwupwFVN+e0+8fKookMq9RWpzv/3PGox UFR4zCiSaWUP0fbFRRQtEZ01bX7x2/hDM74tWROgEKXa/51/q15EI8/B1Ql+EmL9TP+pnE5BM1n Zr1tBwtU0ZTcbl/HkdJmR6h4RWRi81P5WMTGFnGyAAXqeqXGslSdPgWGrzsDjjxfn6yV3N/a9Zs zb2x+NRXUEW4fNzzWIDKM+jwtUc9pgf7Py0QOzFZNNON77vsyEVWirzbApIVBsUrcYVvhb72Vcu zd6T1wh9rj2yj5neVTJeGcOvtTksNUsWinvu5aytc+ud7qehZYsMOLEV8GdgPzAB7Jqelh/I1Us gkrWqnsQ5CRDHFKGsBuyV8wnXbpw2lpGyKpQBS3lOr7W/HsUhO1BTitoSg/dh616iZ25nfhtiBj Ys= X-Google-Smtp-Source: AGHT+IHoem9EvRRQ2b/F2IzOHi6BRBLBkW71FjhL9CHoip0Y9UwHKv9sNtAOyKyDd3Jl6gjS3JkTjQ== X-Received: by 2002:a05:600c:c0c7:b0:477:c478:46d7 with SMTP id 5b1f17b1804b1-47d84b33bd7mr183359155e9.22.1768227186956; Mon, 12 Jan 2026 06:13:06 -0800 (PST) Message-ID: <6ea436ce-6ecb-47f8-8d8a-98b0badeb14e@suse.com> Date: Mon, 12 Jan 2026 15:13:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() To: Anton Markov Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> <4a6b6307-9014-4c4c-8c23-3673efa2d1b1@gmail.com> <794c382b-3b20-4d2a-ab70-b24d7fdf88ae@suse.com> <4b03cf36-d2d8-420c-82df-55d6a9ac9d68@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.01.2026 13:49, Anton Markov wrote: >> Btw, your prior response was too hard to properly read, due to excess blank >> lines with at the same time squashed leading blanks. Together with your >> apparent inability to avoid top-posting, I think you really want to adjust >> your mail program's configuration. > > I suggest we skip the discussion of formatting and the number of spaces in > messages and instead focus on the topic of the thread. I have a very > difficult time troubleshooting difficult-to-reproduce bugs, and the fact > that their descriptions are difficult to read due to the number of spaces > is probably the least of the difficulties. Perhaps, yet it still makes dealing with things more difficult. > That invocation of get_s_time_fixed() reduces to scale_delta() (without >> further rdtsc_ordered()), as non-zero at_tsc is passed in all cases. IOW >> it's not quite clear to me what change you are suggesting (that would >> actually make a functional difference). > > Replacing get_s_time_fixed with scale_delta will remove the calculation > dependency on the previous local_stime value, which accumulates lag between > cores. This is because: rdtsc_ordered is not called synchronously on the > cores, but by the difference offset by the ipi speed. Therefore, we get: > > core0: current_rdtsc; > core1: current_rdtsc + ipi speed; > coreN: current_rdtsc + ipi speed * N; That's if IPIs are sent sequentially. In the most common case, they aren't, though - we use the all-but-self shorthand. Actually, even if IPIs are sent sequentially, I can't see where you spot this effect: Both callers of time_calibration_rendezvous_tail() signal all secondary CPUs to continue at the same time. Hence they'll all execute time_calibration_rendezvous_tail() in parallel. > Since ipi values are sent alternately in a loop to core0, Are they? I fear I don't know which part of the code you're talking about. > in the version > with get_s_time_fixed, we get the following local_stime calculation format. > > coreN: local_stime = local_stime + scale_delta((current_rdtsc + (ipi_speed > * N)) – local_rdtsc); One of the reasons we (iirc) don't do that is that since the scaling factor is also slightly imprecise, we'd prefer to avoid scaling very big values. IOW by changing as you suggest we'd trade one accumulating error for another. Jan > This means the time on each core will differ by ipi_speed * N. And since > we're using the values of the previous local_stime, the difference will > accumulate because the previous local_stime was also offset. In the version > with scale_delta, we get: > > coreN: local_stime = scale_delta(current_rdtsc + (ipi_speed * N)); > > This means there will still be a difference, but it won't accumulate, and > the offsets will remain within normal limits. > > If it's still unclear: If your local_stime in get_s_time_fixed is offset > relative to other cores, then the fact that rdtsc_ordered and local_tsc are > not offset doesn't change anything, since you're using the delta relative > to local_stime. > > core0_local_stime + (rdtsc_ordered() - local_tsc) != core1_local_stime + > (rdtsc_ordered() - local_tsc); // Even if rdtsc_ordered() and local_tsc are > equal across cores. > > On 96-core configurations, up to a millisecond of latency can accumulate in > local_stime over a week of operation, and this is a significant > difference. This > is due to the fact that I use cpufreq=xen:performance max_cstate=1 , > meaning that in my configuration, local_stime is never overwritten by > master_stime. > > Thanks. From xen-devel-bounces@lists.xenproject.org Mon Jan 12 14:28:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 14:28:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200361.1516298 (Exim 4.92) (envelope-from ) id 1vfIuV-0001dr-Dj; Mon, 12 Jan 2026 14:28:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200361.1516298; Mon, 12 Jan 2026 14:28:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfIuV-0001dk-99; Mon, 12 Jan 2026 14:28:47 +0000 Received: by outflank-mailman (input) for mailman id 1200361; Mon, 12 Jan 2026 14:28:45 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfIuT-0001dc-CZ for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 14:28:45 +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 ff874636-efc2-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 15:28:44 +0100 (CET) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-430f5ecaa08so3057331f8f.3 for ; Mon, 12 Jan 2026 06:28:44 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0daa78sm39459517f8f.6.2026.01.12.06.28.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 06:28:42 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ff874636-efc2-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768228123; x=1768832923; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=w58LwGC29cXmcYaQei+vF9ga2UmuyamuAiGBm8q72Go=; b=SiD5KG6q9eH+4o3/k42Jqfffmf+HyWeDTtvcbEt2KD1a0wNQ43vriIVAqZcDzWZxN9 YKbd4C9sUNkL5504Po8x5cydWfFaaEfVSVLuDIIZoMWQNaz76lf3A1ngfhoiicjBVuq6 ZBC2Fqe8d2JqdvU+0lDJPVCxzPeIli3G2iBdXX95uEbJ1vOVSPHhbitBcGhVzbHG4tVe HJMwktFg+cK0oczO1B9exfhkf5wHzAkY2qdVJr4Z/yFQjJ74fuEAITf3CybBEb89ISn4 sPNgDHn8MD3VvwmNmrqzVlQMeiuevXrkhjiAksovrVwGKkvY6zG1+AGq0D7shCv4jvV1 j1fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768228123; x=1768832923; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=w58LwGC29cXmcYaQei+vF9ga2UmuyamuAiGBm8q72Go=; b=YJS3Y33xUe7dP0mDXVqsoH/EEKECL3bgaZImiFTUDA64PYdVyPrwKdAu5716qn5tKe PdRjIJVaFWMZzUZiJSiuzsNTE9G4qgkq7zHx/TEh/isj7ZtFaSYCYbapoK11B8kWdfJ+ gNGfdKDnkL7RNJahC17Ifjt3su0nzmYA5/O8qK2t+sEWYddYTGGwMKdeejc6PiypX7Yl tpE+X7FYgC9T5My1hECePDPsXpDGP8wqPT7lBJtNSl1AGELQW4VDl1rqLO4C3zmc9xYm jKW+9ULb5Y07N1tK7vPVSVtVaLGxWYPtfqL4zrywbTXm5htPTAXLgn0bkh5B8E7yC718 5LBQ== X-Forwarded-Encrypted: i=1; AJvYcCVn7f1hgMJv6KSqC3Jv4Yk0mCeJFwO5YfE+fUzcTXWNahoR5Y6r3zW2EFngvcgQcrv5WdAdXKFRcIo=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywi7rWcHNEdjqX8+9Yh5YzEs7vz4JvZZ3tjWYPG2Nog/l+P5ctJ ERJmJbsL9WT+HE1zF29OHOIJDeus+zCmRL8inplIGDOogZmd9ktc8zhMtLB/3CA9Ig== X-Gm-Gg: AY/fxX5g/wFw0lYsFzCS/Rry6ePp3JTgiWzz2Zh5n7Ur5sStkkplz2f6LZeUXDPggjw fi/zZYGDUw9HhauqZOid9xsL7suXeywcHQ6ZT/LO4cjOkAB/QVVM5oPmIWmZEvlKE0MF3rmLEBy UuPoiRuppUsRMs5zT6mhy/AqhUtm7yQgnpSdb52v9hIF7QyLRYJ5Tg3dO8OxjXSb9Is5T7vpeOO DWL40ZXMyGNUn9VKGvJuIXlf64UQOEWvWcoTqihFuPZl9pkSwXtqWpIo9ZZjIiIDPx4kMHtlgvR P1n3R+Ub3nH3rDO6FApmPaowhqB+ugG7fBsuz+4ZaAV6TpELeYJUSzYp+cVVn60EpXRt9W/AAwh 7LSJFrkP8tTEwOQk0vmvFU4KJbMLnGvPtPtevjzr3cLhluwar5TirjLH635IH86FGGmEPAQm0TG HAH4wgd7zkJCrrovged4jidYUDFNHtH5gQqkPE/VYxJnlc7uGvG6N91z2Anxd8zQCzar5c3qnsL vnW73bKcnWH1Q== X-Google-Smtp-Source: AGHT+IHMYxVqy0QBLvkUWPVhbOSnofZ3KRZAC5rwj0zS/EJLJK1PTWAW5xZJ4P0AK1k+i3RGlab96Q== X-Received: by 2002:a5d:5888:0:b0:42f:edb6:3642 with SMTP id ffacd0b85a97d-432c37767acmr22696655f8f.60.1768228123300; Mon, 12 Jan 2026 06:28:43 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2026 15:28:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 03/15] xen/riscv: implement vcpu_csr_init() 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: <7ba4bcfe-59d3-43f3-adb4-207424dc1713@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: <7ba4bcfe-59d3-43f3-adb4-207424dc1713@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12.01.2026 13:59, Oleksii Kurochko wrote: > On 1/7/26 9:46 AM, Jan Beulich wrote: >> Also, wouldn't you better keep internal state in line with what hardware >> actually supports? CSRIND may be read-only-zero in the real register, in >> which case having the bit set in the "cached" copy can be misleading. > > [...] > >> (This may similarly apply to at least hedeleg and hideleg, btw.) > > Regarding the previous bits, I can understand that it would be an issue: > if SSAIA isn’t supported, then it is incorrect to update the corresponding > bits of|hstateen0|. > > However, I’m not really sure I understand what the issue is with|h{i,e}deleg|. > All writable bits there don’t depend on hardware support. Am I missing something? My reading of the doc was that any of the bits can be r/o 0, with - yes - no dependencies on particular extensions. In which case you'd need to do the delegation in software. For which it might be helpful to know what the two registers are actually set to in hardware (i.e. the cached values wanting to match the real ones). Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 14:43:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 14:43:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200385.1516323 (Exim 4.92) (envelope-from ) id 1vfJ91-00053R-TJ; Mon, 12 Jan 2026 14:43:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200385.1516323; Mon, 12 Jan 2026 14:43:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfJ91-00053K-Pk; Mon, 12 Jan 2026 14:43:47 +0000 Received: by outflank-mailman (input) for mailman id 1200385; Mon, 12 Jan 2026 14:43:46 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfJ90-0004yQ-Rc for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 14:43:46 +0000 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [2a00:1450:4864:20::32d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 18250a8d-efc5-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 15:43:44 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-47795f6f5c0so39837245e9.1 for ; Mon, 12 Jan 2026 06:43:44 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d8718b995sm129101615e9.14.2026.01.12.06.43.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 06:43:42 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 18250a8d-efc5-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768229024; x=1768833824; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=atW9LGhWmyL1Patznkx1C39oW9O64HaBTlrMK3pFtOs=; b=NttQIZazrGqmf4RdpOJhJOh+qr7iIKJjm9jfBpGTvs0mWZ8FWMZoUeBRAkjRpurRHF zOLftkLeAw++BEfc6smYvWfltVquSk32XcMd5GQN6vptrAIIaRRjYpPj71wTbsRVFpYO wBaRRux/uYsK1ovc1Y5MLrRJK+elVwk+dKWoCRIk3fkIw1UjKDqgaEVlre+6opKzczXC udVaHKoxVvNKPH/uYr6yktmz5q6VxUQnZdCVoht7RIDIDeO6htnJjFFWZppFb0mSsIfZ pge0t9LhZcAoVim/TgWkqWHpHR7No+Xq3oDXRCMZQo+GAeb5jFF2HeidQU2x8nlbr+kT WftQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768229024; x=1768833824; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=atW9LGhWmyL1Patznkx1C39oW9O64HaBTlrMK3pFtOs=; b=QorhLWyZQ0cJE6ykm0XZJBsoOJ6LTar9b0f5eLN02G1w4OF3IPmljnDRe5y1/ZyP/s 3abc1O2T4qigdQ9RnY37LYpYMJDzWQWWlSLZHlJzI6+mOSxqWvx7ggXih0EBl8kHBTPM w3nMCQCvGVQw9k6Ginu2lAugVQFDGjsYREtC0p9bzYAXxQILE2cIQLgSgREhrBlHavFV 3MhkS9G97aHb7L+TmrFqFo1BKxPUDvp7Qf0fB6b1ZPuxHSgh3N720Oq7xK8vivoSFbyJ 9Yxg9pKEQK3kOm42TMpc6HA05/pWmS6tjkqrsU3yjRiXkcSgGAK36W2KGX98Fz3BbQoP teTQ== X-Forwarded-Encrypted: i=1; AJvYcCWVNigoNP5LgZ+qD90WTKSQ0iql/kmbE9DZ9cI5cIs8z/YRJcnjFV/ql2VQKA7WZS1o9waeFUMrQYw=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywql8p7t2xAYt/ZoFwad1G/gqG/KlrKDjGhcJlSDzZQIvMVIGNv hKDXHPZWVoeSs1SHQNk8pyJgh+PkYUlvh0vT/hPRwo38fUP2+4bb+K4eltBVB1vQpc0IcKjfL67 x4SA= X-Gm-Gg: AY/fxX4eO/H0YWqW5GG+JRbM9QBmvzJeDpGswTsvJ8qu7bKXkbSVUtUHhP7AR2Yw/Tw 1k4r/m629VEX+rfA26Q38Gz8ByIWMoMLhJd3nIxQ/nMQEK9hy2PB6LBz52wS1Oqk8d5xiAKbuNB ldlofA1y6RcNTDBlDzQnqSpJ//L50KUhVahkkIMYDAb9idNWG/eLXeqvK5VgS1HpV9r5+qnR49I ifPgh/rD+/abj5W21ZAM+M+R0/96qcUdnhibJWE2uX+VWgnffkIhQsHQdW4qayzTYN5fb+8z8Dq KkHXZAjcezu4LKsICcFtH64UYexRtmLhqxrfW1JmbW/l4MfiC1RQCSdcNvvQuv923+6vVLlNZLL 2Xmg5MH4FsgSK462RPwXyGvbYfruoZ6UB3xoe1zS7qWih+xfhP2iKBB7oFYmArxybK4KX/htYcD B1lL+60uPlJxu8uuLuB6tXfvwp0MPWfx97LE8VL53F7KDC6Od0E2qQifTQ2gv4keZ/mudaQ4oV6 H8= X-Google-Smtp-Source: AGHT+IFhWdynesM+Fy6pkBus/1i6OYxUu6I5nDsyDupGfu7+QDMTRxB7ly0ldVyyTJRmYcXIdmIrbw== X-Received: by 2002:a05:600c:3114:b0:456:1a69:94fa with SMTP id 5b1f17b1804b1-47d84b2d27amr199995395e9.13.1768229023547; Mon, 12 Jan 2026 06:43:43 -0800 (PST) Message-ID: <2a903c72-633d-4c91-938b-443628ac37cd@suse.com> Date: Mon, 12 Jan 2026 15:43:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86: Add Kconfig option to use a 32bit TLB clock on debug To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260112140851.55590-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: <20260112140851.55590-1-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12.01.2026 15:08, Alejandro Vallejo wrote: > Debug builds stress the wrapping logic of the TLB clock by narrowing it > down to 10 bits. This is inconvenient to test real time workloads on > such builds. > > Add Kconfig option to be able to selectively use the non-stressed > behaviour on debug. > > Signed-off-by: Alejandro Vallejo Hmm, yes, why not. However, ... > --- a/xen/arch/x86/flushtlb.c > +++ b/xen/arch/x86/flushtlb.c > @@ -20,11 +20,7 @@ > #include > > /* Debug builds: Wrap frequently to stress-test the wrap logic. */ > -#ifdef NDEBUG > -#define WRAP_MASK (0xFFFFFFFFU) > -#else > -#define WRAP_MASK (0x000003FFU) > -#endif > +#define WRAP_MASK (IS_ENABLED(CONFIG_DEBUG_TLB_CLK) ? 0x3FFU : UINT32_MAX) ... the comment then will want updating as well, I'd say. It doesn't go terribly stale this way, but at least slightly. I'd suggest to minimally drop "builds". Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 14:48:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 14:48:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200434.1516352 (Exim 4.92) (envelope-from ) id 1vfJDB-0006ED-Iq; Mon, 12 Jan 2026 14:48:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200434.1516352; Mon, 12 Jan 2026 14: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 1vfJDB-0006E6-Fk; Mon, 12 Jan 2026 14:48:05 +0000 Received: by outflank-mailman (input) for mailman id 1200434; Mon, 12 Jan 2026 14: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 1vfJDA-0006Dx-36 for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 14:48:04 +0000 Received: from CH4PR04CU002.outbound.protection.outlook.com (mail-northcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c105::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b1d5ae88-efc5-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 15:48:03 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BY5PR03MB5202.namprd03.prod.outlook.com (2603:10b6:a03:220::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Mon, 12 Jan 2026 14:47:58 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.005; Mon, 12 Jan 2026 14:47:55 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b1d5ae88-efc5-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=BRx83vtypfDKFsufgxAvyKJ4lB3sS+Fe4P1DXIhor0lPO3UMbPXlxXA/6piwM2Hd2NhFjk5wfKkSyP01aTUlHkIAUMyNYnBUXUJwkhfElqnxksJto0b71IXyjeDRTy5mCevlkLXZuEs3fuelXwVHmwnOx6xagc/fUbmfqSv/OGQLfZTuertK+8WgsFEG6WFvXJVF1xy92KAC+6s6g8vMm5t2XT8u4cFOdZuK3EZWMK7uIPoPJ+HKirLvDq2viDALg8opYIk5ASsz1DB3ijy+mKdkk+Rirok3KmQCbReI/q8Zix5FUgQuSpVgLvnbVfYcMgzMU1zqBor4KufICNrByQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HYoH2pENNa1CA/KKc3Q5DHGXVD+RjMLMytystKpY/m8=; b=quwS/2iSq50QaoJhwUsaNL+xUCvhbtsUT6KayfXulJrMhqKdKIQtIi26djgFXcBQ4eoCTU4XtgQEPohk3HDzXbEWV292YioXUCpAYy6it6UChM4gr9eTIa9B+ZkA1PHo4tbB387NSQhLFQmtdkcsjlexRKdfFMETPJeBfP8Nrz0Umsvgm9pvcrlJ47OY5zhRQqP5IyjpS9vOrTkLGX3b0IqMYVgIPAHcySPccDSWle2wP6UeSzCMZMnPxMo+znHURnnkJQOo+X7LeEY0EuQ2QSdlAFWH9+tWFs/BTpSD9th7dyx7pLmhqqrL7duUE6RQl+MT7ghKARdDGN9Yev1cqw== 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=HYoH2pENNa1CA/KKc3Q5DHGXVD+RjMLMytystKpY/m8=; b=hXfjYuhqX6z7/z2DeGit+4mbRyXbkysdt/lzyf3plw2gRAGx9b/WZeIS6DPWHJ9mEu8xro6fHl8qEZXyc6kMT78vSnUrc105dry5mz+sA/9eskM8mwNvSUQpXgi2upY52GbMGDCw1vHMRs//cdbWpvMcX83+XTVwRTv7LGnVtJI= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <05372ffc-c1b6-4d65-a13b-cd28de6248b5@citrix.com> Date: Mon, 12 Jan 2026 14:47:52 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH] x86: Add Kconfig option to use a 32bit TLB clock on debug To: Jan Beulich , Alejandro Vallejo References: <20260112140851.55590-1-alejandro.garciavallejo@amd.com> <2a903c72-633d-4c91-938b-443628ac37cd@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <2a903c72-633d-4c91-938b-443628ac37cd@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0287.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:38f::15) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BY5PR03MB5202:EE_ X-MS-Office365-Filtering-Correlation-Id: eea220ce-6ce5-4680-75bd-08de51e991f2 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?UEFPQ0hnd3VWWG10cnRFSnd0MURWYkNWdWVkRWgzNysybXdMNVp6K01KanNF?= =?utf-8?B?WkxNUEdpbFZua2F1S1BpYU52clZSTTZhVHVoYVBwWGZmVmZhNnQ0UzJoa0ZN?= =?utf-8?B?SGU4MjhvOUgyaHVlNHdYZ2JzT3RISlVBalMrL0o2MmlhY2JZcVZuTzloeDBS?= =?utf-8?B?WUUwMGsvMjdBd09rZ1Q5SENtYWI1VnVORVB6SnFPc3BkdmxBdFVnSDZzbG9X?= =?utf-8?B?aEtzZWM2dzJyYzh4Y1RUdjE0cUZ3S3dqbGtkb3BqcmRESVRVTGdTY2xETit2?= =?utf-8?B?OE5kOVA3aDRoZStFTnBPUGVEellIOFFMQ1FTUGpZVSswb2QvRjN1d2RzOWJ0?= =?utf-8?B?THgyajVzQ3dqU3B4RlY0Nk10WmNVNlBBc1p4SHg4UDFFaTI4RVJTam5tdGJx?= =?utf-8?B?Y0hFbUtRTE5TcUFXc1hFZlRJRlNSTmNsRG0rQmpGVm5TTTlnaEhVMk5nU3Vq?= =?utf-8?B?cWpPZmdnWDE0L2E4S2dTczhZcG56Tk51cG1TQ0t4MlduVHZDZjFwWEg5eDdy?= =?utf-8?B?STl4cDFNWUhpckd6Y2xtcGZhVFlXZW5RODlaSkFzVlNmZ0dEVmN5RU5FZDRR?= =?utf-8?B?dyt1Q1NmWkNxeHFSS1NabStvMzl5Y2xWSXVvUi9QYVhId0Vwem1qWVc1S3pv?= =?utf-8?B?Vy9Zd1JUK0dPb2x3eDdkRzBOSldtenVRcVl6MFRBNzZuam9IL2xiZ0V0Rm1p?= =?utf-8?B?NzVqR3BIN2FWcE9tdE5sUEdKakNlZUgrclc0SjZ2L3RCR0ZCdXBQcEVhWXBU?= =?utf-8?B?anY2ZmNBakVNSjVVTkJCSUh1V1BVU2VWUXdDaFFJVkpLU1hoaE1NOWZyT0N6?= =?utf-8?B?NmMxdkErK1RKb3dYUVcrcXBzNnovY05qUzE3YkhSL3UxODRBSGZ0VGdvNTBs?= =?utf-8?B?bzIyY1EvWWpxWG5Jd2hVZlNNSWU5Tk9uLzUyUmdtUGtpVGpTeXc3eURYdDV5?= =?utf-8?B?cU4rbUNrMVNEVVVhT1drVzAxNUJqbmZ2TlhnSWZDUjZ6a29kWHB4SHlQcXNE?= =?utf-8?B?RUxyT3Jjak5EbHIrRWpiUHIxYlhTcjZ3YnlUNm9nODRPeUdjMVpldEhCTmVu?= =?utf-8?B?QXhtUVRqNE9kMjd3YVZtV1NIWmFFLzFLczNsaFVsemZuUmYwenlneGUxMGcy?= =?utf-8?B?cG9IYmYxaHJTc2Q4UFpyd0lEemZwVFYxRTJXNllNYUtxekxXV1N4NDhpMUpT?= =?utf-8?B?RHNiZVp3L3dTWHlCSTEzeVpPVGRNOVcxZ0VhR0dhK2ZoQS9WRkNvc2oyelhK?= =?utf-8?B?bEd6U2N5Mk5TUTZkQ1RSSE5JaUVsZk1YVGR0SjZ2T2xCR1djbDR0SndNbkFE?= =?utf-8?B?cXN2dFdKZTg5YXUzTkl2MEx5bDlnUnhRaEh1UWZ4S3pUb3FRK2V0cGU0ayto?= =?utf-8?B?RG1PVktBYXZ2eGZORzhaNG8rcEQzWUQ5cC9BYnZZcFc3Q0M2Qi9ON3E5Qk5m?= =?utf-8?B?ejg2YnFMbDZ3TDRwdjBZUDdBaXJKTDBoWS9sU0VhVC9FazBzTTRLKzllUllm?= =?utf-8?B?L3I3c1k4MExTMGU4cVdmdzRIV2ZYMnJiNzh0VUM3Z1p0WFZWUVUzSkZka2h4?= =?utf-8?B?WFZCYnFmZ0VsZzJhUlRwL3hOVFVmVnNSNFIwSnU4ZDVxTUpxUEhlTVM1T0ZJ?= =?utf-8?B?WVM2VWFRTUNCZU42ZS8wYnNPS1VRNUMyTFEwQ1dNak9YeWl5RzY4SEh0OUNY?= =?utf-8?B?WTNrYU9ldEdUZCtNVEx0ZjJsR2Y5c0xlaTNiU3g3VnAzODZLaW5veFRKUGdz?= =?utf-8?B?WHYyMEN6SkZZZ0xVUU1KTGN4R1dpV2JoVi9nWkV3VHltTzF5UXE4dTJoTHNB?= =?utf-8?B?ODFDUzdyOFpMdnhQN0VVQlhlbFpVL3k0RW8wYmRmSzJpYkk3b1FCRmhHcnA0?= =?utf-8?B?dEM0VWwxQkE0THhrRHA1OXFEQ0k2dXNlMmVqbUZoMlU3eXFWbmhSUm5jbGQw?= =?utf-8?Q?zVFg5a0BhbDxOnTZz4vEyny9oyv/L5dw?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bkdDTUEzc0pGRG5qdFBJRnpkSGQ4dFF4K3F4UUVyVUptVnE2a2xvY2lKNis4?= =?utf-8?B?NmlCWUxDVmhUUVY0b1hTTXE1RTBLelpCMU1LNGVVTElMQS81eHkySDFRdFRK?= =?utf-8?B?L0Vib0JNbFU1YWg3c1JGT1FCQUpid040eTU2NHNjbHhsVHFpZ1VtZEt1T3ZI?= =?utf-8?B?L2ZZdnlJdWUzTWo1Nks1Q2RwV1FXaTlERTBldkR4cE40dEZjRlhqM1k3TTVq?= =?utf-8?B?SWZUelZzZ0dHNG1YNDRCRExDZ291SmdpUURsbmIzWkt6VnhrNjRRdVZuTERr?= =?utf-8?B?UnZ2SGdtSlFqOGlCTUh6VUYxMWlHSS9PNTh5UGhwaVEwTzVNWUJJNmVSbzJP?= =?utf-8?B?cUtZeDlKdlNGQTdlZDYrRDU2ajlTZHpIU2tmV2w3amsrWlBrT2dRVURoSEVa?= =?utf-8?B?cE03VUxWOHlpOGRXZUh4V2t6T1VRc2laMXU4NzZXWGV1bjEyWWJRMEFoRnFl?= =?utf-8?B?QUdRdWxlaXZ5OW1Gazc2cmc2cDBHVTloQ2I1NkFFN21UVlo3ZUEvOHBGYUJU?= =?utf-8?B?c2VyanBOWlBqcUlMeWZlS2h3Vm5oL1hOMU5XUTUrU2lwdVBvMHdjZm1XV2pk?= =?utf-8?B?R2l4cXZQcktyME5JSnN3VG9Cekp6dG5aMC8vK1pGM1grNzc1M0RQZnBZWkdL?= =?utf-8?B?NlVjeElXV2s2Sit2dEhFbmpoTGNiR1g2VXhqK3dBdjVJTGJ5a2hNWGNtVktq?= =?utf-8?B?U015ZTI3cjVoOE5DNnpHSUlhbEIzS2w0bDlablRqQlFyYmRuMHJsOW5HNm8r?= =?utf-8?B?Y3R1OXlTOWRIWU5QYVJHck1UWE9UTkVGRjRhbkZ6eXBZSjNROUdySm45TEty?= =?utf-8?B?RW9GZ0dlV045MFhCd01DZi9OS3JpUk5RY3dLYzhIaUtoR1JSNFVaSmdXUVFl?= =?utf-8?B?UW4zd0FtVDNnV291Wmx1UjdnMnFQSGZkbXZoUXFlcFBML2ZSdHFqZE5vTXRP?= =?utf-8?B?S3F4RktMOWV6NjVnTkZKWUdlZ24vWU1DdVp3aFFVTDFEdUhwQWRUSVgvdGox?= =?utf-8?B?WHIzM3JISWJEeHBVZ1VGcTVzb3NFQWdSU1JqTkdMQzh5a0VTVk95empCTlFP?= =?utf-8?B?cUlyd2JZOWNGMmpMWnhRcVRCNE9uSDJiVU9SY3dPL0VieXpXSXhyckcrbUtr?= =?utf-8?B?QWpURXBSd0xGWGtSSEZVaHZWamUvbFM5WVk0OXg1OEEwcGR5ZmkySWdXSlNM?= =?utf-8?B?R0pmY3R5SHZUMWVVU3VQN2xrS0xSaWxqVk1zN2hIMUxsdW1ubTU1QkFteE9o?= =?utf-8?B?ZisxQ0hCa0gzeHlzdGkrVkV2VFhqbG1rRU9JSmo0UGNrR3NmMkcvdmRGcWpK?= =?utf-8?B?N1ZkanZ5NTVCZzUyRUZPMHVueHhmMmU3cWZUaVNBcStvQmFDeTY0d1JSV0d4?= =?utf-8?B?b0dRb21BcUhNNXUwNjdQTFdZeUZkMVYxSW9QNU5tUnV4QUlrOEU1Z05QcVRa?= =?utf-8?B?SXB4cEdMY2VQeEVHZ0RGSFpYWHlnM2J0dnprWDZmcmdpbEZjbVMyVVo3Z0I1?= =?utf-8?B?dHpQQkt6SlAwTEJ0ZmpnRDloNmlkYnVlRFdrNWpWMUdsY0FXUUZtbFU2aUxz?= =?utf-8?B?Njl2bFZ5N1dIVnlHYkw1RTB2dlBPb05MVm4zdEVGVXV3b001Y01FdXRYdWs2?= =?utf-8?B?dFhNb0dMZmxQN0l3eTM5b010b3lNMnpWWjVheUNkMnlObVFxMG1sS3VpNzJp?= =?utf-8?B?MG52VkxrNS8wRHZleXRGbGFVNEVnY1BXT0p4MmZyYmd4Mm16SEx3c1gwOU1J?= =?utf-8?B?aHBWc1QzR0FOeG94eDRKT1ZKdkorbmc5MDllcGFTM1ZqSmN0OU40MVdYamhP?= =?utf-8?B?dXU4YzlLV3RYRUVzckc0T1RpZFlKRFRtMk5oMGFMbnlmbHBLS2Z0czNOd1Jk?= =?utf-8?B?ZEpEOGp1UFlHREtyUjNXQURDRWZNOE5MWCtNanJBdloxTjhrU0t0YTh3dlNV?= =?utf-8?B?aVE2eDI3cVhUZmZ1M3RDMkNLWG5XVUNhdTNoWnQ1N1lLeFc0Y2c2ODN2OWF3?= =?utf-8?B?Uk9ONE9Qc2xwODNYMnRLTGF2Q3l4V29jdWYyOER0RUZvcVdrZTlmRE44eU5n?= =?utf-8?B?dURrbE9qVjYvRzZiZUhsL3JiQUF6TUhUdDNUbWVLZlNrbllKYlk5bXdDQmZq?= =?utf-8?B?OFhZczhicjdEQmQ0ODcyaUd0emxrZ1Q4VTgyNWQyandYNityVkIyRUMyZExs?= =?utf-8?B?SUFZRW1uZVZjTFptcm1lSGdMeEhrZGljUVprbVQya1JrR0V3eUVNcWd4anAy?= =?utf-8?B?UWkzd0gxYnpxNVhWcWdGZ2ZBcXYvTkVoVkVEUksxa01hNzZWMndrQno0V1BS?= =?utf-8?B?UnpWRHZIeWd3cnQrQXZURDMwN01IQnpmcXI4T3I1a3U5b3g1K24wdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: eea220ce-6ce5-4680-75bd-08de51e991f2 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2026 14:47:55.2776 (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: HT2COtQRpugvmsH7i4oIrnu9yuRhkgCOkQCKBgA5smPNr9YNfJE3woSHFMz6Ae/vNjYBADtO+mXsiNpi0CUqM1whSbOYA0u1BuT2aHEajvg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB5202 On 12/01/2026 2:43 pm, Jan Beulich wrote: > On 12.01.2026 15:08, Alejandro Vallejo wrote: >> Debug builds stress the wrapping logic of the TLB clock by narrowing it >> down to 10 bits. This is inconvenient to test real time workloads on >> such builds. >> >> Add Kconfig option to be able to selectively use the non-stressed >> behaviour on debug. >> >> Signed-off-by: Alejandro Vallejo > Hmm, yes, why not. However, ... > >> --- a/xen/arch/x86/flushtlb.c >> +++ b/xen/arch/x86/flushtlb.c >> @@ -20,11 +20,7 @@ >> #include >> >> /* Debug builds: Wrap frequently to stress-test the wrap logic. */ >> -#ifdef NDEBUG >> -#define WRAP_MASK (0xFFFFFFFFU) >> -#else >> -#define WRAP_MASK (0x000003FFU) >> -#endif >> +#define WRAP_MASK (IS_ENABLED(CONFIG_DEBUG_TLB_CLK) ? 0x3FFU : UINT32_MAX) > ... the comment then will want updating as well, I'd say. It doesn't go > terribly stale this way, but at least slightly. I'd suggest to minimally > drop "builds". I'm suggest just dropping WRAP_MASK. We've done this locally in the XenServer patchqueue since 2011 or so due to the overhead, and I don't think it's interesting enough to warrant a separate option. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jan 12 14:52:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 14:52:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200453.1516362 (Exim 4.92) (envelope-from ) id 1vfJGw-0007qi-6C; Mon, 12 Jan 2026 14:51:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200453.1516362; Mon, 12 Jan 2026 14: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 1vfJGw-0007qb-3E; Mon, 12 Jan 2026 14:51:58 +0000 Received: by outflank-mailman (input) for mailman id 1200453; Mon, 12 Jan 2026 14:51: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 1vfJGu-0007qG-Kd for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 14:51:56 +0000 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [2607:f8b0:4864:20::62b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3c15c848-efc6-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 15:51:54 +0100 (CET) Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-2a09757004cso59574805ad.3 for ; Mon, 12 Jan 2026 06:51:54 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3c15c848-efc6-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768229513; x=1768834313; 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=JmF2/VLCbeIWUuEssKcguK7EHciUZv8vmpc8vZUr/Ic=; b=NtGjqcc79bD4b58ybLzM9N+++6u/xUO9q0dc/+Vt1xqgeKUWg7BmWesxxs/UVDou4T VPZjk63aKLoDXBxT5MAEInOLbezSWZ5pLUCQXSaVPTChuI7cahOQQnnl10+jAAG3Ij+2 hWBzBI4x0fC+43a4G65h/6LV8TJZwb9zjlSbCrZsj6IYd4jqTK22wbKpuy43jxyvTAtx ux6FnGZ7xHgR5J4tW4cpNl18HMQpTR3xfqf1H/EMiqDS7755SJNKFegLmREao6Vf4q6L tSjMceA6CDOZ83Ftm739lRbIRzkRNZLT7i1+d74f/YF4itTXeWKNiAFMbleSQZfYz3Zr hj6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768229513; x=1768834313; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=JmF2/VLCbeIWUuEssKcguK7EHciUZv8vmpc8vZUr/Ic=; b=Me8W8IwKHjqQvUrfEst69d20eNQSA1zvynSaO/QSuyFD8D1TnJX+fnArY2Mdx3K3Il HkmQenSlCcowsBNJMNNjZKQeZ5TXGd4e/eNWHWPDj8xbe5oTWTIIG6KY+dDCAJmCE5Zp 1bz1Rkvpb46TlYxj5OABksXql3XE4yWcJyfh6VY27/6hPGEhyPQMvUKLG2o1pz+xnA7R qzWarSvYRJOXvpcF6ar0QUKZK8sf9g/yXReT4e0SS22bXQwT2Bw6K2QkSzUAs7lwnI9Z RYZzzwi7oGhlwKAi2XmWURitEPhihUh2NmBqRXf3HaURigMk3d75o7gNmv6ZqOnYpDoE cqGQ== X-Forwarded-Encrypted: i=1; AJvYcCUYRa8eBcEjZ+K2wGm8mg9hRhfmMDJtAbeyFnD2Vs2XG5jYFgAvlt9rvgeycWk3lu7HPr0wJncRAGA=@lists.xenproject.org X-Gm-Message-State: AOJu0YzUG665GjHkF4jGLstH/Ilen1N39qU30wmz4A6+4zl0x4bXyEFa 9x6qZYirR09SasQX9pmFQsAY6Bl2HQ8SZaaqfpbYS+3CKuNROvD1kYdJS/bGpgxoEip9k2xzZC0 d0M+stKPpfDOpmPGTOYWRI7ZG+wN0oWI= X-Gm-Gg: AY/fxX4V6tTnol//xU58hwNxOwStAjqHqySp1Ml24jDWiNveM43rxfQhhTdE/dVWQ61 dLRu3yb6TXrB8+uycj4PzwuWuugJqiakN/n+OsfSTSy1aRWw9vR7/h2m0HHWxDz6yfLcXgeBEKK 30iikNsmBHrOxMJy+v2aBOMSTc0cHf2XHFibfZid8zzffQ7E29Px39jPYxqB8jQmDO8ddpVCqCa Ylw9KhqusHqFcoTGpWcSdO3YUPwkS4pcIBPg4eTBU6vNEY+b0u1rLrGJrchm8AVzN6Cghp8 X-Google-Smtp-Source: AGHT+IFC7KL+ECw6y2Nk7292WpJiWEApxRMGhTWyIXVRzo/9co/nor4bGNKz7DfwEMe5BXBVuUoZYkQp03/0nVWwdJ0= X-Received: by 2002:a17:903:4765:b0:2a0:c1be:f436 with SMTP id d9443c01a7336-2a3ee4bfe10mr182051565ad.59.1768229513048; Mon, 12 Jan 2026 06:51:53 -0800 (PST) MIME-Version: 1.0 References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> <4a6b6307-9014-4c4c-8c23-3673efa2d1b1@gmail.com> <794c382b-3b20-4d2a-ab70-b24d7fdf88ae@suse.com> <4b03cf36-d2d8-420c-82df-55d6a9ac9d68@suse.com> <6ea436ce-6ecb-47f8-8d8a-98b0badeb14e@suse.com> In-Reply-To: <6ea436ce-6ecb-47f8-8d8a-98b0badeb14e@suse.com> From: Anton Markov Date: Mon, 12 Jan 2026 17:51:41 +0300 X-Gm-Features: AZwV_QjrZzprkref4W33SGy92BuWGFTGnuSlxk-PPYr9r2I2N5wiARzzC-sGrC8 Message-ID: Subject: Re: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() To: Jan Beulich Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="00000000000001b5d70648320431" --00000000000001b5d70648320431 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > Perhaps, yet it still makes dealing with things more difficult. Sorry. I just spent too much time on this bug to stay in my mind. That's if IPIs are sent sequentially. In the most common case, they aren't, > though - we use the all-but-self shorthand. Actually, even if IPIs are sent sequentially, I can't see where you spot > this effect: Both callers of time_calibration_rendezvous_tail() signal al= l > secondary CPUs to continue at the same time. Hence they'll all execute > time_calibration_rendezvous_tail() in parallel. In parallel, but with a slight delay. Are they? I fear I don't know which part of the code you're talking about. In the function "time_calibration" (xen/arch/x86/time.c) Sorry, I don't take into account that you don't stay in context, being distracted by other threads. One of the reasons we (iirc) don't do that is that since the scaling factor > is also slightly imprecise, we'd prefer to avoid scaling very big values. > IOW by changing as you suggest we'd trade one accumulating error for > another. As I wrote above, there will be an error when using scale_delta, but it won't accumulate between calls to time_calibration_rendezvous_tail. In the current version, the old error (ipi lag + rounding error) persists due to the use of the old local_stime in the get_s_time_fixed function, and it's added to the new error and accumulates with each call. If c->local_stime =3D get_s_time_fixed(old_tsc ?: new_tsc); replaced with: c->local_stime =3D scale_delta(old_tsc ?: new_tsc); Then we'll only be dealing with the error due to the current ipi lag and rough rounding, within a single call. If I understand you correctly, you fixed the rough rounding of scale_delta by reducing the values using get_s_time_fixed . But the problem is, that didn't help. The error now accumulates gradually because we're relying on old calculations. Furthermore, while the old rounding error was limited, now the error accumulates infinitely, albeit very slowly. If this is so, then the solution to the problem becomes less obvious. Roughly speaking, my servers start to go crazy after a week of continuous operation, as the time lag between cores reaches 1 millisecond or more. On Mon, Jan 12, 2026 at 5:13=E2=80=AFPM Jan Beulich wro= te: > On 12.01.2026 13:49, Anton Markov wrote: > >> Btw, your prior response was too hard to properly read, due to excess > blank > >> lines with at the same time squashed leading blanks. Together with you= r > >> apparent inability to avoid top-posting, I think you really want to > adjust > >> your mail program's configuration. > > > > I suggest we skip the discussion of formatting and the number of spaces > in > > messages and instead focus on the topic of the thread. I have a very > > difficult time troubleshooting difficult-to-reproduce bugs, and the fac= t > > that their descriptions are difficult to read due to the number of spac= es > > is probably the least of the difficulties. > > Perhaps, yet it still makes dealing with things more difficult. > > > That invocation of get_s_time_fixed() reduces to scale_delta() (without > >> further rdtsc_ordered()), as non-zero at_tsc is passed in all cases. I= OW > >> it's not quite clear to me what change you are suggesting (that would > >> actually make a functional difference). > > > > Replacing get_s_time_fixed with scale_delta will remove the calculation > > dependency on the previous local_stime value, which accumulates lag > between > > cores. This is because: rdtsc_ordered is not called synchronously on th= e > > cores, but by the difference offset by the ipi speed. Therefore, we get= : > > > > core0: current_rdtsc; > > core1: current_rdtsc + ipi speed; > > coreN: current_rdtsc + ipi speed * N; > > That's if IPIs are sent sequentially. In the most common case, they aren'= t, > though - we use the all-but-self shorthand. > > Actually, even if IPIs are sent sequentially, I can't see where you spot > this effect: Both callers of time_calibration_rendezvous_tail() signal al= l > secondary CPUs to continue at the same time. Hence they'll all execute > time_calibration_rendezvous_tail() in parallel. > > > Since ipi values are sent alternately in a loop to core0, > > Are they? I fear I don't know which part of the code you're talking about= . > > > in the version > > with get_s_time_fixed, we get the following local_stime calculation > format. > > > > coreN: local_stime =3D local_stime + scale_delta((current_rdtsc + > (ipi_speed > > * N)) =E2=80=93 local_rdtsc); > > One of the reasons we (iirc) don't do that is that since the scaling fact= or > is also slightly imprecise, we'd prefer to avoid scaling very big values. > IOW by changing as you suggest we'd trade one accumulating error for > another. > > Jan > > > This means the time on each core will differ by ipi_speed * N. And sinc= e > > we're using the values of the previous local_stime, the difference will > > accumulate because the previous local_stime was also offset. In the > version > > with scale_delta, we get: > > > > coreN: local_stime =3D scale_delta(current_rdtsc + (ipi_speed * N)); > > > > This means there will still be a difference, but it won't accumulate, a= nd > > the offsets will remain within normal limits. > > > > If it's still unclear: If your local_stime in get_s_time_fixed is offse= t > > relative to other cores, then the fact that rdtsc_ordered and local_tsc > are > > not offset doesn't change anything, since you're using the delta relati= ve > > to local_stime. > > > > core0_local_stime + (rdtsc_ordered() - local_tsc) !=3D core1_local_stim= e + > > (rdtsc_ordered() - local_tsc); // Even if rdtsc_ordered() and local_tsc > are > > equal across cores. > > > > On 96-core configurations, up to a millisecond of latency can accumulat= e > in > > local_stime over a week of operation, and this is a significant > > difference. This > > is due to the fact that I use cpufreq=3Dxen:performance max_cstate=3D1 = , > > meaning that in my configuration, local_stime is never overwritten by > > master_stime. > > > > Thanks. > --00000000000001b5d70648320431 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Perhaps, yet it still makes dealing with things more difficult.<= /blockquote>
Sorry. I just spent too much time on this bug to stay in m= y mind.=C2=A0

That's if IPIs are sent sequentially. In the most common= case, they aren't,
though - we use the all-but-self shorthand.
Actually, even if= IPIs are sent sequentially, I can't see where you spot
this effect:= Both callers of time_calibration_rendezvous_tail() signal all
secondary= CPUs to continue at the same time. Hence they'll all execute
time_c= alibration_rendezvous_tail() in parallel.
In parallel, but= with a slight delay.

Are they? I fear I don't know which part of the code y= ou're talking about.
In the function "time_calibr= ation" (xen/arch/x86/time.c) Sorry, I don't take into account that= you don't stay in context, being distracted by other threads.

One of the re= asons we (iirc) don't do that is that since the scaling factor
is al= so slightly imprecise, we'd prefer to avoid scaling very big values.IOW by changing as you suggest we'd trade one accumulating error foranother.
As I wrote above, there will be an error when using = scale_delta, but it won't accumulate between calls to time_calibration_= rendezvous_tail. In the current version, the old error (ipi lag + rounding error) persists d= ue to the use of the old local_stime in the get_s_time_fixed function, and = it's added to the new error and accumulates with each call.
If

c->local_stime =3D= get_s_time_fixed(old_tsc ?: new_tsc);

replaced with:

c->loc= al_stime =3D scale_delta(old_tsc ?: new_tsc);

Then we'll only be dealing with the error due to the current ipi lag a= nd rough rounding, within a single call.

If I understand you correctly, you fixed the rough rounding of sca= le_delta by reducing the values using get_s_time_fixed . But the p= roblem is, that didn't help. The error now accumulates gradual= ly because we're relying on old calculations. Furthermore, whi= le the old rounding error was limited, now the error accumulates infinitely= , albeit very slowly.=C2=A0If this is so, then the solution t= o the problem becomes less obvious.

Roughly sp= eaking, my servers start to go crazy after a week of continuous operation, = as the time lag between cores reaches 1 millisecond or more.= =C2=A0
=C2=A0
On Mon, Jan 12, 2026 at 5:13=E2=80= =AFPM Jan Beulich <jbeulich@suse.co= m> wrote:
On 12.01.2026 13:49, Anton Markov wrote:
>> Btw, your prior response was too hard to properly read, due to exc= ess blank
>> lines with at the same time squashed leading blanks. Together with= your
>> apparent inability to avoid top-posting, I think you really want t= o adjust
>> your mail program's configuration.
>
> I suggest we skip the discussion of formatting and the number of space= s in
> messages and instead focus on the topic of the thread. I have a very > difficult time troubleshooting difficult-to-reproduce bugs, and the fa= ct
> that their descriptions are difficult to read due to the number of spa= ces
> is probably the least of the difficulties.

Perhaps, yet it still makes dealing with things more difficult.

> That invocation of get_s_time_fixed() reduces to scale_delta() (withou= t
>> further rdtsc_ordered()), as non-zero at_tsc is passed in all case= s. IOW
>> it's not quite clear to me what change you are suggesting (tha= t would
>> actually make a functional difference).
>
> Replacing get_s_time_fixed with scale_delta will remove the calculatio= n
> dependency on the previous local_stime value, which accumulates lag be= tween
> cores. This is because: rdtsc_ordered is not called synchronously on t= he
> cores, but by the difference offset by the ipi speed. Therefore, we ge= t:
>
> core0: current_rdtsc;
> core1: current_rdtsc + ipi speed;
> coreN: current_rdtsc + ipi speed * N;

That's if IPIs are sent sequentially. In the most common case, they are= n't,
though - we use the all-but-self shorthand.

Actually, even if IPIs are sent sequentially, I can't see where you spo= t
this effect: Both callers of time_calibration_rendezvous_tail() signal all<= br> secondary CPUs to continue at the same time. Hence they'll all execute<= br> time_calibration_rendezvous_tail() in parallel.

> Since ipi values are sent alternately in a loop to core0,

Are they? I fear I don't know which part of the code you're talking= about.

> in the version
> with get_s_time_fixed, we get the following local_stime calculation fo= rmat.
>
> coreN: local_stime =3D local_stime + scale_delta((current_rdtsc + (ipi= _speed
> * N)) =E2=80=93 local_rdtsc);

One of the reasons we (iirc) don't do that is that since the scaling fa= ctor
is also slightly imprecise, we'd prefer to avoid scaling very big value= s.
IOW by changing as you suggest we'd trade one accumulating error for another.

Jan

> This means the time on each core will differ by ipi_speed * N. And sin= ce
> we're using the values of the previous local_stime, the difference= will
> accumulate because the previous local_stime was also offset. In the ve= rsion
> with scale_delta, we get:
>
> coreN: local_stime =3D scale_delta(current_rdtsc + (ipi_speed * N)); >
> This means there will still be a difference, but it won't accumula= te, and
> the offsets will remain within normal limits.
>
> If it's still unclear: If your local_stime in get_s_time_fixed is = offset
> relative to other cores, then the fact that rdtsc_ordered and local_ts= c are
> not offset doesn't change anything, since you're using the del= ta relative
> to local_stime.
>
> core0_local_stime + (rdtsc_ordered() - local_tsc) !=3D core1_local_sti= me +
> (rdtsc_ordered() - local_tsc); // Even if rdtsc_ordered() and local_ts= c are
> equal across cores.
>
> On 96-core configurations, up to a millisecond of latency can accumula= te in
> local_stime over a week of operation, and this is a significant
> difference. This
> is due to the fact that I use cpufreq=3Dxen:performance max_cstate=3D1= ,
> meaning that in my configuration, local_stime is never overwritten by<= br> > master_stime.
>
> Thanks.
--00000000000001b5d70648320431-- From xen-devel-bounces@lists.xenproject.org Mon Jan 12 14:59:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 14:59:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200478.1516373 (Exim 4.92) (envelope-from ) id 1vfJO0-0000Et-Sh; Mon, 12 Jan 2026 14:59:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200478.1516373; Mon, 12 Jan 2026 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 1vfJO0-0000Em-Pm; Mon, 12 Jan 2026 14:59:16 +0000 Received: by outflank-mailman (input) for mailman id 1200478; Mon, 12 Jan 2026 14:59:16 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfJO0-0000Ee-9k for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 14:59:16 +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 42371117-efc7-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 15:59:13 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-432da746749so1559116f8f.0 for ; Mon, 12 Jan 2026 06:59:13 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5dfa07sm38910472f8f.25.2026.01.12.06.59.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 06:59:12 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 42371117-efc7-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768229953; x=1768834753; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=MvRS3OvQ+3rJa8qQEn+n7UgtFCNgDPAlLqo6ioakeyo=; b=NxQsAZI5R/06/KyKR7v4EBh8f2pmzULHlMKAxJFvOeoobg1wvWyvvXQ2OBRdSiEh1w XJvKrDG7RAMkdxN4q7SW9ZJt33yoI4a5ZzxYdzCKWa18RnUr4uRJt8SoixxJc5OjAG1N 7At8OIHBDvcyzc//6AKRWksbyGRMBJLtOHIRfcJ6tUnP55XiD1J+CsE+flj3uFWKLzS3 MD+9o2npGKA5BM/ImfYwGT1oMk9oQAzbb6LYjN9RyTnMrRhrWfrJ0jgFyheKIyqTrGFk aukHBwTBQSGL7X1aCqNRXtxZaU0VLyNyDt8NbtbnnfxywJglQvTgq4w/eu8/30u2g9xG UgBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768229953; x=1768834753; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=MvRS3OvQ+3rJa8qQEn+n7UgtFCNgDPAlLqo6ioakeyo=; b=Cylsy+6vCMBCMoLnqeVzURT8QmAknWCGyHnUD0nWm1zJ4dS+Dmy3LqwmHf0Zee747f Q3AErU+3UT+/gFjHGf9hTbkw32nNqEZPINefIXJ9+nNc1IRCE7hyQflzs5s3E2Gqm9VZ AaILwTwvgF1UZPXoaYHGeAy3kL3xU7Drd/s/ms1YJtjrwEw7fqF+NhjbFEmlMre5qFWV aUnjpKXHR9zvIGHVCII88mhzlS2MKpWgMdZzVGSrfASMQcZdtwm+vY+EWxp2Z335/EUf JJmatBS9FATzKGkk3dV9DAZngHPwxv+l6pjiP67iaiwDmZ4XbuHqaSZbWo02bAWJGwCQ /IRQ== X-Forwarded-Encrypted: i=1; AJvYcCWVieNeuITS6eLSChDxqOAtiQb3WATNl0RgquwK6sBqFitPKUC6CjhH64seUi6CuhxPa+9niDVelrE=@lists.xenproject.org X-Gm-Message-State: AOJu0YxZMsZqMWoRiz4fcjJ+12Cd1nVYpuwGdrrwbcjqO6NWadOpTGdj bNq33tDxsOsQ0ZKbmHIaI3JmS5O3jhwEX/CnodoFWNtIAhmul+sFH1y0GspgBZsKJw== X-Gm-Gg: AY/fxX4baZNlnH6/HRUO791Y7NppAYU4zuHWFPGiBG0Huepimd0tgXCCOgzQKWNph/C ul454x/+nsFInZYTH3hv1oiw2kVcsA79nyYa4kvPzd4Z+hpcWKmBiahcw+w7JWZn4wg0U7+YJEI l4JjrN+YLMJKin0K9RVNqjCY0fugOtTTVNQW5txlbSdLxooGQlhbGJSfODHNYJTfnmvPucNCfBW WKqweXX0u9BYhIn5g/72Tb0JDRjT0WrJ37wfFNE6FX+Sfr8o/IJujpIOEnCP3d4DGzl7jfCiBgE jO4gI+luEuxg68P7iNKFI6P4bVqPsEEa+9nCJA0mqR3LhPWblPAVQEvB8QuUEeZy+eKwMWJvbtu SN2sMRd7p8oWNP/LLOEDNTwp8W3IT3Vi3BFpCJIya23gH6OwxI+0LuLninsqMk+aw+d2pXisdCW XfGVMAXjZl0CDW5e6FEUG0tZ/v9UQ8FB5ClRx5bA2HxO8D4DpS/cQICzG3oI+j8ikITwdh960Tg VA= X-Google-Smtp-Source: AGHT+IFJkv2Kuc6iR2VEHgae0KujIBE4UcurYZNruOj8OAowsLQpqhvT+fFCRTd/HgZYjLfeI7FIng== X-Received: by 2002:a05:6000:2dc2:b0:42f:bb08:d1ef with SMTP id ffacd0b85a97d-432c363281cmr22142987f8f.17.1768229953150; Mon, 12 Jan 2026 06:59:13 -0800 (PST) Message-ID: <369eb1d7-864e-4432-9729-57786d0c191f@suse.com> Date: Mon, 12 Jan 2026 15:59:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [Arm] Re: [PATCH v1 11/15] xen/riscv: introduce ns_to_ticks() To: Oleksii Kurochko , Michal Orzel , Julien Grall , Stefano Stabellini Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 24.12.2025 18:03, Oleksii Kurochko wrote: > Signed-off-by: Oleksii Kurochko > --- > xen/arch/riscv/include/asm/time.h | 5 +++++ > 1 file changed, 5 insertions(+) Looks okay and read to go in as is (no dependencies on earlier patches afaics), but: > --- a/xen/arch/riscv/include/asm/time.h > +++ b/xen/arch/riscv/include/asm/time.h > @@ -29,6 +29,11 @@ static inline s_time_t ticks_to_ns(uint64_t ticks) > return muldiv64(ticks, MILLISECS(1), cpu_khz); > } > > +static inline uint64_t ns_to_ticks(s_time_t ns) > +{ > + return muldiv64(ns, cpu_khz, MILLISECS(1)); > +} It's hard to see what's arch-dependent about this or ticks_to_ns(). They're similar but not identical to Arm's version, and I actually wonder why that difference exists. Questions to Arm people: 1) Why are they out-of-line functions there? 2) Why the involvement of the constant 1000 there? 1000 * cpu_khz can actually overflow in 32 bits. The forms above aren't prone to such an issue. If the delta isn't justified, I think we'd better put RISC-V's functions in common code (xen/time.h). They're not presently needed by x86, but as inline functions they also shouldn't do any harm. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 15:03:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 15:03:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200488.1516383 (Exim 4.92) (envelope-from ) id 1vfJRy-0001lo-Bh; Mon, 12 Jan 2026 15:03:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200488.1516383; Mon, 12 Jan 2026 15:03: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 1vfJRy-0001lh-8C; Mon, 12 Jan 2026 15:03:22 +0000 Received: by outflank-mailman (input) for mailman id 1200488; Mon, 12 Jan 2026 15:03: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 1vfJRw-0001lb-QZ for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 15:03:20 +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 d2e0a50a-efc7-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 16:03:17 +0100 (CET) Received: from MN0P220CA0017.NAMP220.PROD.OUTLOOK.COM (2603:10b6:208:52e::10) by DS0PR12MB9060.namprd12.prod.outlook.com (2603:10b6:8:c4::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Mon, 12 Jan 2026 15:03:13 +0000 Received: from BL02EPF0001A104.namprd05.prod.outlook.com (2603:10b6:208:52e:cafe::4b) by MN0P220CA0017.outlook.office365.com (2603:10b6:208:52e::10) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Mon, 12 Jan 2026 15:03:03 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BL02EPF0001A104.mail.protection.outlook.com (10.167.241.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Mon, 12 Jan 2026 15:03:13 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 12 Jan 2026 09:03:12 -0600 Received: from xcbagarciav01.xilinx.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_256_GCM_SHA384) id 15.2.2562.17; Mon, 12 Jan 2026 07:03:10 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d2e0a50a-efc7-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=sR7o0qQ7viZhiNwNAQlNrtdE96pTeBrKOqUktVOp8Nj6u7xc8syKYMZP/TB//J2E0iN4CMsPgmbDsvv/AdKYlVPh7gxp3eOyMO8AQpRBrqGtHrZGVZd7ESjvSQPgViMAOr3mUYblc+erWdDJgBdg0t2VHWVWX3QCF6sn7imOqtxMWHa/4lB3tpJwilbWHvELy5XPjHIrV3djJHxIrZMJSSzPhOK3cSN5B9FETKhpBZpcLngTqcQeLBlxA42Ak8/8672/xoUuXSUFfpJAQRuTKKB0ugDGj9dMfD6e4pw/o9edesFPwSJlhlka7iSGcHfPf7GupNxwQ7WEQETunLZAdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/pLOSTgowp564qhw/IuxOEayZcT2eLsgWW+FjWEzN18=; b=nEp5YKjHEJkASbNs4QH2OAaOCFpPPCfcaYZ4elVcqjZQf9ZHCLfMsclIqAq2ZGQGJgms9BmAQZ8Io48th5yFaroi9DmOQHBVr/IXiP9pNThnunVPRFQZxVyPsqv2sFfQ7ldfWBpjNYPZKNftNgBTBrwa/URb49OkNvHVtiMkyov38weaV2+XwFCFKnMDmS2IsPtYPdgLFWlyvNRnSATg3KJY3Op+7u5qhkG8Q0SAI4M/2+MmM9Ht6k502kOyYqUvBEsy+0O7/QwHNR84uz2KbKtJe4jLFwfRvIInbXiWCq5mSQNmsx97zf0rA60k20ircY/QRQ6PKnl/XCbJMh5TFg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/pLOSTgowp564qhw/IuxOEayZcT2eLsgWW+FjWEzN18=; b=28SUYLr5zSL0DU5irah7LxkCqXBBrhWrQ7o4fRlbzJx78YFlXKy3+F1STWvRcJzN2eCWLFqC3gcdJ9vlxA81yl78dr55GVcVidFmtGZla+PwAMml4YUJ1UW4+NkLrlsGQ7dCgcMqe7KNewTV8jmInXQf6sZ3X9ZVNQHu8peF4Dc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Doug Goldstein , Stefano Stabellini , "Anthony PERARD" , Michal Orzel , Julien Grall , "Daniel P. Smith" , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Subject: [PATCH v2 0/2] Add Kconfig option to remove microcode loading support Date: Mon, 12 Jan 2026 16:02:54 +0100 Message-ID: <20260112150259.74535-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 satlexmb09.amd.com (10.181.42.218) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF0001A104:EE_|DS0PR12MB9060:EE_ X-MS-Office365-Filtering-Correlation-Id: ae9eae4b-f8ac-4d58-3521-08de51ebb53c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|376014|7416014|36860700013; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?yCZmC8z36KxVTQC4VVE8SYZhmKoUdAuc86aton6Ri6qYlUhJZHpN2GRhXqH4?= =?us-ascii?Q?4C0Ng5PKddfpI3Y9xD70ZOYGiDMMkUWW7L432l9CRCEYtWod02Y5cZqDnwLU?= =?us-ascii?Q?WlfKh5YoCr1bg5C7uqKBwM3McGS4W7DBo7IeIa7l4NDsBACTcap3Dh9z8QXC?= =?us-ascii?Q?zSOv0cFE8tKHJQ3eqGIjyylyYWV40hQbQ8neXiN+i2ermJsuz1tmH/4jxG4m?= =?us-ascii?Q?d8NNYlOTprukMkmMZFb2COfhOHc1aJIbFbsrjcYO5qSdZLpb/Uq3u4l4XuAk?= =?us-ascii?Q?/G72b+WKLQtzLuJ1YFWK0zTbLXzNtzQUpzbBS8wpQII8wZbXEDJ2UvA3NTht?= =?us-ascii?Q?DnMhnIDlv5KBFe9menhzj7scm6WtVFDeEG1wt4OXd6OmhXE8BpS/nr6VZZWp?= =?us-ascii?Q?BvExdP/OpPXrp88HeTknQjrjxOn/yS+chvizXLxBPnLgqYjcun241Nowf9ea?= =?us-ascii?Q?Qtq2C3Nb91SyqTMI6GQa+qbuqwCTuHBaCtKglYUFKKQDq4ZldJh12vEbruoa?= =?us-ascii?Q?QcYeJFdmAWRMeUlzc7HXEziRKxnerJtXplF7LnBHCFHcI0jE6bsHUq2SuqYF?= =?us-ascii?Q?Wf817jAXtepwzDZfNbFbjMCNaUC2TfD5dPB0te+4vQyvd0BtdN0HKYIdPnED?= =?us-ascii?Q?cxFtogEcZ+jSdY1OK1VuMsClxgzUCjmYZccgFpGxBIFOSJJKVQAFRE7uNQ9J?= =?us-ascii?Q?6GjgbN9VocfelvcoHhlevhG7OWinMr4oxVq8Fa4S3upZDmkYvJckO6qhXTur?= =?us-ascii?Q?P8ZAhRjCutRpjidT3ZnZBDx1o47cNQbVVdxs8QZF+t3EpQHLXHBBLvUIik7P?= =?us-ascii?Q?4jdauOCQJc0aesXtxIoZOzMqVDhj9m1MBK5s1hip/GiLhNNJgQOgC9cIqc2N?= =?us-ascii?Q?2APcPBCooeF8zPx4Ks0frwAysVi5xQ3AcusNDOx/el0neyOtvCdwWV/MxOTU?= =?us-ascii?Q?6MJVcjrdSRoxiXoXs53+Pvqc7v/lBpnvwfP42gNkQRCtPWIGxfOsh/Qiekb5?= =?us-ascii?Q?OZMi5YuBXBLxkVn6xFi1S/jfW7d59OW82ednTZs83CHWkwL7ZoTTCaDCzn0f?= =?us-ascii?Q?iXLqNkIgi0JSJcb4b8/8IppuyRlSNzwN5JSvje7ASnsz1swki5Q+gMlZYe1N?= =?us-ascii?Q?vxNHfJoOmyA4ROhGGZrCx81BVRFuUL9oP969NnZxrNkGplFSc9mRnmlyusTg?= =?us-ascii?Q?BT3Le9aUmle1OHa2U9kFyLMdZM/7xt55NfZc1bxu1cW8k9IDMLjQoUmdlB32?= =?us-ascii?Q?WVcUt7OpkQ//C1B48dvOG5/xEMDLJgb4nZAIdcmsd7F9cQeXVNy9ttLYu8Lr?= =?us-ascii?Q?ejzLYD+P0RAVOUUd7wJkz6JBWsRGT4csU5OkafVN1ELfeb90Zly50jt3lmxo?= =?us-ascii?Q?4qHqVl6YjHI60LRv8WqqVDorZ7W/jKENSotOVhZ50qxzrw6VKY5xUALsq//f?= =?us-ascii?Q?q9ek7oTjZE/a2TJCaEwrt/SQxdfhp/6y0m8yCvxDoYZM9LIKwujhe6sYFpgx?= =?us-ascii?Q?1F4pIzUXfWOKkMMNwMOmJ92o9B2965KRmFuZfPhZkTBP7CRK+H/C+EC+4o07?= =?us-ascii?Q?MS3IeSJt50ilyHkc1ZI5XrPTGhwYVnowx77yIsMd?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(376014)(7416014)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2026 15:03:13.2531 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ae9eae4b-f8ac-4d58-3521-08de51ebb53c X-MS-Exchange-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: BL02EPF0001A104.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB9060 Hi, This is v2 of the series I sent back in November, now condensed in a single patch with heavier use of DCE, and with earlycpio removed too. While doing this I spotted a typo, thus the new patch1. Patch 2 has all the meat, fat and bone of the old series at a fraction of the diffstat. v1: https://lore.kernel.org/xen-devel/20251112162219.226075-1-alejandro.garciavallejo@amd.com/ pipeline (still running at time of send): https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/2258163170 Cheers, Alejandro Alejandro Vallejo (2): x86/ucode: Fix typo s/mitigiated/mitigated/ x86/ucode: Add Kconfig option to remove microcode loading automation/gitlab-ci/build.yaml | 2 +- docs/misc/efi.pandoc | 2 ++ docs/misc/xen-command-line.pandoc | 4 ++-- xen/arch/x86/Kconfig | 14 +++++++++++++- xen/arch/x86/cpu/microcode/amd.c | 28 ++++++++++++++++------------ xen/arch/x86/cpu/microcode/core.c | 25 ++++++++++++++++++------- xen/arch/x86/cpu/microcode/intel.c | 16 +++++++++------- xen/arch/x86/efi/efi-boot.h | 3 ++- xen/arch/x86/platform_hypercall.c | 2 ++ xen/common/Makefile | 3 ++- 10 files changed, 67 insertions(+), 32 deletions(-) base-commit: a2a34d76643e49ccc949296c9a45888034e50b55 -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Jan 12 15:03:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 15:03:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200489.1516393 (Exim 4.92) (envelope-from ) id 1vfJS0-000207-M4; Mon, 12 Jan 2026 15:03:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200489.1516393; Mon, 12 Jan 2026 15:03:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfJS0-000200-JM; Mon, 12 Jan 2026 15:03:24 +0000 Received: by outflank-mailman (input) for mailman id 1200489; Mon, 12 Jan 2026 15: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 1vfJRz-0001lb-32 for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 15:03:23 +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 d4d9e88a-efc7-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 16:03:20 +0100 (CET) Received: from BL1PR13CA0341.namprd13.prod.outlook.com (2603:10b6:208:2c6::16) by BL1PR12MB5922.namprd12.prod.outlook.com (2603:10b6:208:399::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Mon, 12 Jan 2026 15:03:16 +0000 Received: from BL02EPF0001A106.namprd05.prod.outlook.com (2603:10b6:208:2c6:cafe::c5) by BL1PR13CA0341.outlook.office365.com (2603:10b6:208:2c6::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.4 via Frontend Transport; Mon, 12 Jan 2026 15:02:58 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BL02EPF0001A106.mail.protection.outlook.com (10.167.241.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Mon, 12 Jan 2026 15:03:16 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 12 Jan 2026 09:03:16 -0600 Received: from xcbagarciav01.xilinx.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_256_GCM_SHA384) id 15.2.2562.17; Mon, 12 Jan 2026 07:03:14 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d4d9e88a-efc7-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VIOWvf9llHrf7CgvOdcvbewC39l5qyE+5XP3vn/8qku5mGjLxXrSxkOpwtJ7siop2of9eWACBoecvuUhU18rPLPZnkvwaKLn3mjyxPAGDStaTVG0uOVihkEKS4se6a0Bh76WtO/JWCWS4bwCLiNrV9Ygy9vCzcmv/bniObvKRsgdr7WdtnzVaB31paa5LK20kBKBGYKN9zfNi88Sr2oBZLh+HFvX30R+FWcaLhnqohNlotOEjE7iJy/yVaxglC1fdYLBnvtiS31/gK/avNSu7+iqW4kQYAdFSoHXair3EvDTCGG5jOzsx5rBGCoZ6ErjAq3+Z+1EXqgOnClv0yQyfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ybbTcCzVlltRMz1WEtFiCbnEPeRN28eyOOsctOIRu60=; b=c7Y8IaeQ79cABvJpdyycDKPxNk3r4WlJChd6YfWdaHiRZy2FT9Q/AQveRbhWvqGaOXDhv3ribkvtuQThVuF7Pti7YSeG78+9Dpp+vT42BZoiFCNtfXmGOgP1JjyhrPSHqY47O+QX5lv6CAEKFEZwSgxlSF+wwxsXmNXcptTq9Jl9RRNW6RrTW4ocKcN8FypVnS3a9d10Yppf4FLFYRLYZQH1GZBhVsQ39xDN3FGolX3b/md7n5yhJ4VOFStz1cbd+Au2yFPruupC28u6h/7ppTqQ/nykaMfC5LVJo66yCQrE5O34/cQjw7qta5whSBQ1axFL5Kwva/cO9K1b0NENoA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ybbTcCzVlltRMz1WEtFiCbnEPeRN28eyOOsctOIRu60=; b=HGz4s91IENQWxhiKD4G6grahQzeFvaDo28X5/pvkqVKIPuxUP9dh5R/e0ovQkUihSUwRzBYOhyRq30AM837enIVEG8j4iqRYQUc8L3IJfD63EsDErKJyqxGQICpy1rkcocGdRDqD72AZSgy4nVHxIpn1Du6mMjPNkwdCdD0W7hI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: Alejandro Vallejo To: CC: Alejandro Vallejo , Doug Goldstein , Stefano Stabellini , "Andrew Cooper" , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , "Daniel P. Smith" , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Subject: [PATCH v2 2/2] x86/ucode: Add Kconfig option to remove microcode loading Date: Mon, 12 Jan 2026 16:02:56 +0100 Message-ID: <20260112150259.74535-3-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260112150259.74535-1-alejandro.garciavallejo@amd.com> References: <20260112150259.74535-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 satlexmb09.amd.com (10.181.42.218) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF0001A106:EE_|BL1PR12MB5922:EE_ X-MS-Office365-Filtering-Correlation-Id: c843b0ac-36d2-4fa6-eee0-08de51ebb71e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|376014|7416014|1800799024|82310400026; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?lqEZFPsI9oVRxXBZfIaTS2B/OhXC/POf1rpauSXktFwHPOJRqweYOaFV09D5?= =?us-ascii?Q?iq+MkEgEoSq3I6P/1fezj0Y+o3rCHn22HMZxzWFkLQR2gdYayl3OnXeW3b8s?= =?us-ascii?Q?MZwYTNopKWo04UyAgN6rzsUnO001x1Zgawl5cbKR6kic2HuTgvUrQK69Ma+o?= =?us-ascii?Q?QB5gIu6c3/F3NLvKJ6P425AxTG3MGY4x3Ji6V6SiR0mmHGJe0RX3tPfClvCc?= =?us-ascii?Q?mp7Z8oa8ki5FLXWBnIKpty2XNQxL9rAM/lEUsDJDw9QdA1d8rX0jhWcqaAfc?= =?us-ascii?Q?kuN/9rk+VIt4KdD5FM8ni+eX3/dLxKG/9kOSiXQzBwbKocipeH7bqA9V+aqX?= =?us-ascii?Q?0RcxeOPCrH2uSUpvkIjt4d2nSt7qRoLmypUVElg570SXhWf2onJ0Exwfc/4o?= =?us-ascii?Q?naUO4Dz8c0ROZvTf6dqR5Uo7uFgqSOzA4JcSzt9h8qKEUZ3o++EaB5VAr2pP?= =?us-ascii?Q?tN1vl+tJzfmPPL8bW1YdP2BzxgNSzTB9dR7u0LgxQ88xxrGFSGvmqvFK9pNg?= =?us-ascii?Q?H7VwIwGcuBzdGZI+Kxup/TIxPyL3p+kHJ0rrz6izh0UitsHvcKTt76y+l31I?= =?us-ascii?Q?D9tw14HhYLu4Gm1vuOY1pmI0G2G5Lylj3mpUabrAQ6SWqg6kYeRihXaEaoe7?= =?us-ascii?Q?z65TcP6KCluWqnhVefgMKlN3W79S4R0qGg/8IyO1K37FyiaGw9N/Wm99mvHY?= =?us-ascii?Q?SqNcZGJlzeP4HAI18c3GVI6g7G6rpjUAt69Xv91VLCn8W4eTe69dthP6TtGZ?= =?us-ascii?Q?Ugdj+Kx4xKC4WqHE53hn1u5L3yI58HmGwrFssyEiPgLhQvI9srxcVUgUm0bs?= =?us-ascii?Q?VxHqYELqzvSBpofxcU9Rvr8e1b0YOnw/BwvzXxhu/rivlGuxi70ldakTYM9t?= =?us-ascii?Q?P24OXpYM9EEpwHyW/gBOp1TeGW920Fhu8ndxgEa6u1X00CJvLcL4U3ID1oyy?= =?us-ascii?Q?2nEVZD2sO6YyuecddqOaMDnxabXaa3NT6MJZc6g2QUk5MKhEONSnS958SD7N?= =?us-ascii?Q?PC2IUoCZhCOAnyv0v8Vvy35EeY8Gmjlf1GPZnLFioQZzlR5GITEChfhCP/xx?= =?us-ascii?Q?qnZGEr0mCCapy0R410hoALA1zQT6AHzS6GphWtLmIlpE5exCEnqjnEb/0T2b?= =?us-ascii?Q?2qD4APAPpnWYkfayGncRCRvxSy2FNpf9sitIIvcs004r9M+iOM+rFCKUuKUo?= =?us-ascii?Q?OHkLqK9U6p/0NELyl6RzrjYmhzTRmxgIV+YBE1JvpDhgrQD6SGhBOHtKLj8W?= =?us-ascii?Q?3DBLvVY//MDaUgvnlIUzVB83OfZ6DqFRK5611WwAIXgtCVc2Ic3uJN+SXecN?= =?us-ascii?Q?G9XA/bAl+wZl/CzcQmyIDgn2w48uRkNhK5g+TcsN6RSW3LZrDnIYmaJKxgX/?= =?us-ascii?Q?Dtf0ypnfRHu8TNYlccmAWx8OA+hDOaLWGf+1A6DgWSvszoDtYqIlDT3AwcSQ?= =?us-ascii?Q?DB01wE8l/25axpPvE9i5Kz5ZdBtB4tEFeFoKOGh+8dlgsd/n21B9NSPvG/DQ?= =?us-ascii?Q?uVt/1fhPC/HB5M5LAUvfUJyU32UaRC9hOLfHToX61uZqy+BUI4T0DA8MqhxT?= =?us-ascii?Q?DMVNvYTNZAYKWhyt2yE=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(7416014)(1800799024)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2026 15:03:16.4164 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c843b0ac-36d2-4fa6-eee0-08de51ebb71e X-MS-Exchange-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: BL02EPF0001A106.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5922 Amend docs to reflect ucode= commands depend on MICROCODE_LOADING being set. While at it, rename UCODE_SCAN_DEFAULT to MICROCODE_SCAN_DEFAULT for consistency. Signed-off-by: Alejandro Vallejo --- v2: * Rely aggressively on DCE and ifdef/IS_ENABLED rather than file refactoring * Add a note about CONFIG_MICROCODE_LOADING to xen-command-line.pandoc * Rename UCODE to MICROCODE_LOADING * Rename UCODE_SCAN_DEFAULT to MICROCODE_SCAN_DEFAULT in order to avoid having some options with UCODE and some with MICROCODE. * Remove earlycpio.init.o from the build when !CONFIG_MICROCODE_LOADING --- automation/gitlab-ci/build.yaml | 2 +- docs/misc/efi.pandoc | 2 ++ docs/misc/xen-command-line.pandoc | 4 ++-- xen/arch/x86/Kconfig | 14 +++++++++++++- xen/arch/x86/cpu/microcode/amd.c | 22 +++++++++++++--------- xen/arch/x86/cpu/microcode/core.c | 25 ++++++++++++++++++------- xen/arch/x86/cpu/microcode/intel.c | 16 +++++++++------- xen/arch/x86/efi/efi-boot.h | 3 ++- xen/arch/x86/platform_hypercall.c | 2 ++ xen/common/Makefile | 3 ++- 10 files changed, 64 insertions(+), 29 deletions(-) diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml index a6fc55c2d5..b69bad9202 100644 --- a/automation/gitlab-ci/build.yaml +++ b/automation/gitlab-ci/build.yaml @@ -310,7 +310,7 @@ alpine-3.18-gcc-debug: CONFIG_ARGO=y CONFIG_UBSAN=y CONFIG_UBSAN_FATAL=y - CONFIG_UCODE_SCAN_DEFAULT=y + CONFIG_MICROCODE_SCAN_DEFAULT=y CONFIG_XHCI=y debian-13-x86_64-gcc-debug: diff --git a/docs/misc/efi.pandoc b/docs/misc/efi.pandoc index 11c1ac3346..c3fb1f3a30 100644 --- a/docs/misc/efi.pandoc +++ b/docs/misc/efi.pandoc @@ -104,6 +104,8 @@ Specifies an XSM module to load. Specifies a CPU microcode blob to load. (x86 only) +Only available when Xen is compiled with CONFIG_MICROCODE_LOADING. + ###`dtb=` Specifies a device tree file to load. The platform firmware may provide a diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 50d7edb248..866fa2f951 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -2748,7 +2748,7 @@ performance. ### ucode > `= List of [ | scan=, nmi=, digest-check= ]` - Applicability: x86 + Applicability: x86 with CONFIG_MICROCODE_LOADING active Default: `scan` is selectable via Kconfig, `nmi,digest-check` Controls for CPU microcode loading. For early loading, this parameter can @@ -2773,7 +2773,7 @@ microcode in the cpio name space must be: - on AMD : kernel/x86/microcode/AuthenticAMD.bin When using xen.efi, the `ucode=` config file setting takes precedence over `scan`. The default value for `scan` is set with -`CONFIG_UCODE_SCAN_DEFAULT`. +`CONFIG_MICROCODE_SCAN_DEFAULT`. 'nmi' determines late loading is performed in NMI handler or just in stop_machine context. In NMI handler, even NMIs are blocked, which is diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index c808c989fc..1353ec9a3f 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -331,8 +331,20 @@ config REQUIRE_NX was unavailable. However, if enabled, Xen will no longer boot on any CPU which is lacking NX support. -config UCODE_SCAN_DEFAULT +config MICROCODE_LOADING + bool "Microcode loading" + default y + help + Support updating the microcode revision of available CPUs with a newer + vendor-provided microcode blob. Microcode updates address some classes of + silicon defects. It's a very common delivery mechanism for fixes or + workarounds for speculative execution vulnerabilities. + + If unsure, say Y. + +config MICROCODE_SCAN_DEFAULT bool "Scan for microcode by default" + depends on MICROCODE_LOADING help During boot, Xen can scan the multiboot images for a CPIO archive containing CPU microcode to be loaded, which is Linux's mechanism for diff --git a/xen/arch/x86/cpu/microcode/amd.c b/xen/arch/x86/cpu/microcode/amd.c index 71b041c84b..6abdc7813b 100644 --- a/xen/arch/x86/cpu/microcode/amd.c +++ b/xen/arch/x86/cpu/microcode/amd.c @@ -264,7 +264,7 @@ static bool microcode_fits_cpu(const struct microcode_patch *patch) return equiv.id == patch->processor_rev_id; } -static int cf_check amd_compare( +static int cf_check __maybe_unused amd_compare( const struct microcode_patch *old, const struct microcode_patch *new) { /* Both patches to compare are supposed to be applicable to local CPU. */ @@ -310,8 +310,8 @@ static bool check_min_rev(const struct microcode_patch *patch) return this_cpu(cpu_sig).rev >= patch->min_rev; } -static int cf_check apply_microcode(const struct microcode_patch *patch, - unsigned int flags) +static int cf_check __maybe_unused apply_microcode( + const struct microcode_patch *patch, unsigned int flags) { int hw_err, result; unsigned int cpu = smp_processor_id(); @@ -422,7 +422,7 @@ static int scan_equiv_cpu_table(const struct container_equiv_table *et) return -ESRCH; } -static struct microcode_patch *cf_check cpu_request_microcode( +static __maybe_unused struct microcode_patch *cf_check cpu_request_microcode( const void *buf, size_t size, bool make_copy) { const struct microcode_patch *saved = NULL; @@ -557,15 +557,17 @@ static struct microcode_patch *cf_check cpu_request_microcode( return patch; } -static const char __initconst amd_cpio_path[] = +static const char __initconst __maybe_unused amd_cpio_path[] = "kernel/x86/microcode/AuthenticAMD.bin"; static const struct microcode_ops __initconst_cf_clobber amd_ucode_ops = { - .cpu_request_microcode = cpu_request_microcode, .collect_cpu_info = collect_cpu_info, +#ifdef CONFIG_MICROCODE_LOADING + .cpu_request_microcode = cpu_request_microcode, .apply_microcode = apply_microcode, .compare = amd_compare, .cpio_path = amd_cpio_path, +#endif /* CONFIG_MICROCODE_LOADING */ }; void __init ucode_probe_amd(struct microcode_ops *ops) @@ -574,7 +576,8 @@ void __init ucode_probe_amd(struct microcode_ops *ops) * The Entrysign vulnerability (SB-7033, CVE-2024-36347) affects Zen1-5 * CPUs. Taint Xen if digest checking is turned off. */ - if ( boot_cpu_data.family >= 0x17 && boot_cpu_data.family <= 0x1a && + if ( IS_ENABLED(CONFIG_MICROCODE_LOADING) && + boot_cpu_data.family >= 0x17 && boot_cpu_data.family <= 0x1a && !opt_digest_check ) { printk(XENLOG_WARNING @@ -614,8 +617,9 @@ void __init amd_check_entrysign(void) unsigned int curr_rev; uint8_t fixed_rev; - if ( boot_cpu_data.vendor != X86_VENDOR_AMD || - boot_cpu_data.family < 0x17 || + if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) || + boot_cpu_data.vendor != X86_VENDOR_AMD || + boot_cpu_data.family < 0x17 || boot_cpu_data.family > 0x1a ) return; diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c index fe47c3a6c1..aec99834fd 100644 --- a/xen/arch/x86/cpu/microcode/core.c +++ b/xen/arch/x86/cpu/microcode/core.c @@ -44,6 +44,9 @@ #include "private.h" +#define can_apply_microcode(ops) (IS_ENABLED(CONFIG_MICROCODE_LOADING) && \ + (ops).apply_microcode) + /* * Before performing a late microcode update on any thread, we * rendezvous all cpus in stop_machine context. The timeout for @@ -58,7 +61,7 @@ */ #define MICROCODE_UPDATE_TIMEOUT_US 1000000 -static bool __initdata ucode_mod_forced; +static bool __initdata __maybe_unused ucode_mod_forced; static unsigned int nr_cores; /* @@ -101,9 +104,10 @@ static struct microcode_patch *microcode_cache; * location we require that they are not both active together. */ static int __initdata opt_mod_idx; -static bool __initdata opt_scan = IS_ENABLED(CONFIG_UCODE_SCAN_DEFAULT); +static bool __initdata opt_scan = IS_ENABLED(CONFIG_MICROCODE_SCAN_DEFAULT); bool __ro_after_init opt_digest_check = true; +#ifdef CONFIG_MICROCODE_LOADING /* * Used by the EFI path only, when xen.cfg identifies an explicit microcode * file. Overrides ucode=|scan on the regular command line. @@ -162,6 +166,7 @@ static int __init cf_check parse_ucode(const char *s) return rc; } custom_param("ucode", parse_ucode); +#endif /* CONFIG_MICROCODE_LOADING */ static struct microcode_ops __ro_after_init ucode_ops; @@ -469,7 +474,7 @@ struct ucode_buf { char buffer[]; }; -static long cf_check ucode_update_hcall_cont(void *data) +static long cf_check __maybe_unused ucode_update_hcall_cont(void *data) { struct microcode_patch *patch = NULL; int ret, result; @@ -613,6 +618,7 @@ static long cf_check ucode_update_hcall_cont(void *data) return ret; } +#ifdef CONFIG_MICROCODE_LOADING int ucode_update_hcall(XEN_GUEST_HANDLE(const_void) buf, unsigned long len, unsigned int flags) { @@ -622,7 +628,7 @@ int ucode_update_hcall(XEN_GUEST_HANDLE(const_void) buf, if ( flags & ~XENPF_UCODE_FORCE ) return -EINVAL; - if ( !ucode_ops.apply_microcode ) + if ( !can_apply_microcode(ucode_ops) ) return -EINVAL; buffer = xmalloc_flex_struct(struct ucode_buf, buffer, len); @@ -645,6 +651,7 @@ int ucode_update_hcall(XEN_GUEST_HANDLE(const_void) buf, */ return continue_hypercall_on_cpu(0, ucode_update_hcall_cont, buffer); } +#endif /* CONFIG_MICROCODE_LOADING */ /* Load a cached update to current cpu */ int microcode_update_one(void) @@ -658,7 +665,7 @@ int microcode_update_one(void) if ( ucode_ops.collect_cpu_info ) alternative_vcall(ucode_ops.collect_cpu_info); - if ( !ucode_ops.apply_microcode ) + if ( !can_apply_microcode(ucode_ops) ) return -EOPNOTSUPP; spin_lock(µcode_mutex); @@ -678,6 +685,7 @@ int microcode_update_one(void) */ static int __initdata early_mod_idx = -1; +#ifdef CONFIG_MICROCODE_LOADING static int __init cf_check microcode_init_cache(void) { struct boot_info *bi = &xen_boot_info; @@ -734,6 +742,7 @@ static int __init cf_check microcode_init_cache(void) return rc; } presmp_initcall(microcode_init_cache); +#endif /* CONFIG_MICROCODE_LOADING */ /* * There are several tasks: @@ -907,10 +916,12 @@ int __init early_microcode_init(struct boot_info *bi) * * Take the hint in either case and ignore the microcode interface. */ - if ( !ucode_ops.apply_microcode || this_cpu(cpu_sig).rev == ~0 ) + if ( !can_apply_microcode(ucode_ops) || this_cpu(cpu_sig).rev == ~0 ) { printk(XENLOG_INFO "Microcode loading disabled due to: %s\n", - ucode_ops.apply_microcode ? "rev = ~0" : "HW toggle"); + !IS_ENABLED(CONFIG_MICROCODE_LOADING) ? "not compiled in" : + ucode_ops.apply_microcode ? "rev = ~0" : + "HW toggle"); ucode_ops.apply_microcode = NULL; return -ENODEV; } diff --git a/xen/arch/x86/cpu/microcode/intel.c b/xen/arch/x86/cpu/microcode/intel.c index 281993e725..d9895018b4 100644 --- a/xen/arch/x86/cpu/microcode/intel.c +++ b/xen/arch/x86/cpu/microcode/intel.c @@ -273,7 +273,7 @@ static bool microcode_fits_cpu(const struct microcode_patch *mc) return false; } -static int cf_check intel_compare( +static int __maybe_unused cf_check intel_compare( const struct microcode_patch *old, const struct microcode_patch *new) { /* @@ -286,8 +286,8 @@ static int cf_check intel_compare( return compare_revisions(old->rev, new->rev); } -static int cf_check apply_microcode(const struct microcode_patch *patch, - unsigned int flags) +static int cf_check __maybe_unused apply_microcode( + const struct microcode_patch *patch, unsigned int flags) { uint64_t msr_content; unsigned int cpu = smp_processor_id(); @@ -333,7 +333,7 @@ static int cf_check apply_microcode(const struct microcode_patch *patch, return 0; } -static struct microcode_patch *cf_check cpu_request_microcode( +static __maybe_unused struct microcode_patch *cf_check cpu_request_microcode( const void *buf, size_t size, bool make_copy) { int error = 0; @@ -404,21 +404,23 @@ static bool __init can_load_microcode(void) return !(mcu_ctrl & MCU_CONTROL_DIS_MCU_LOAD); } -static const char __initconst intel_cpio_path[] = +static const char __initconst __maybe_unused intel_cpio_path[] = "kernel/x86/microcode/GenuineIntel.bin"; static const struct microcode_ops __initconst_cf_clobber intel_ucode_ops = { - .cpu_request_microcode = cpu_request_microcode, .collect_cpu_info = collect_cpu_info, +#ifdef CONFIG_MICROCODE_LOADING + .cpu_request_microcode = cpu_request_microcode, .apply_microcode = apply_microcode, .compare = intel_compare, .cpio_path = intel_cpio_path, +#endif /* CONFIG_MICROCODE_LOADING */ }; void __init ucode_probe_intel(struct microcode_ops *ops) { *ops = intel_ucode_ops; - if ( !can_load_microcode() ) + if ( IS_ENABLED(CONFIG_MICROCODE_LOADING) && !can_load_microcode() ) ops->apply_microcode = NULL; } diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h index 0194720003..42a2c46b5e 100644 --- a/xen/arch/x86/efi/efi-boot.h +++ b/xen/arch/x86/efi/efi-boot.h @@ -295,7 +295,8 @@ static void __init efi_arch_cfg_file_late(const EFI_LOADED_IMAGE *image, { union string name; - if ( read_section(image, L"ucode", &ucode, NULL) ) + if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) || + read_section(image, L"ucode", &ucode, NULL) ) return; name.s = get_value(&cfg, section, "ucode"); diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c index 79bb99e0b6..5e83965d21 100644 --- a/xen/arch/x86/platform_hypercall.c +++ b/xen/arch/x86/platform_hypercall.c @@ -307,6 +307,7 @@ ret_t do_platform_op( break; } +#ifdef CONFIG_MICROCODE_LOADING case XENPF_microcode_update: { XEN_GUEST_HANDLE(const_void) data; @@ -327,6 +328,7 @@ ret_t do_platform_op( op->u.microcode2.flags); break; } +#endif /* CONFIG_MICROCODE_LOADING */ case XENPF_platform_quirk: { diff --git a/xen/common/Makefile b/xen/common/Makefile index 92c97d641e..1e6c92e554 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -65,7 +65,8 @@ obj-y += wait.o obj-bin-y += warning.init.o obj-y += xmalloc_tlsf.o -obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo unlz4 unzstd earlycpio,$(n).init.o) +obj-bin-$(CONFIG_MICROCODE_LOADING) += earlycpio.init.o +obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo unlz4 unzstd,$(n).init.o) obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Jan 12 15:03:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 15:03:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200491.1516403 (Exim 4.92) (envelope-from ) id 1vfJS6-0002IN-U1; Mon, 12 Jan 2026 15:03:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200491.1516403; Mon, 12 Jan 2026 15: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 1vfJS6-0002IG-R4; Mon, 12 Jan 2026 15:03:30 +0000 Received: by outflank-mailman (input) for mailman id 1200491; Mon, 12 Jan 2026 15:03: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 1vfJS5-0002Gh-J1 for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 15:03:29 +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 d4e9da5b-efc7-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 16:03:21 +0100 (CET) Received: from MN0P220CA0018.NAMP220.PROD.OUTLOOK.COM (2603:10b6:208:52e::16) by MN0PR12MB6319.namprd12.prod.outlook.com (2603:10b6:208:3c0::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Mon, 12 Jan 2026 15:03:14 +0000 Received: from BL02EPF0001A104.namprd05.prod.outlook.com (2603:10b6:208:52e:cafe::c4) by MN0P220CA0018.outlook.office365.com (2603:10b6:208:52e::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Mon, 12 Jan 2026 15:03:05 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BL02EPF0001A104.mail.protection.outlook.com (10.167.241.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Mon, 12 Jan 2026 15:03:14 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 12 Jan 2026 09:03:14 -0600 Received: from xcbagarciav01.xilinx.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_256_GCM_SHA384) id 15.2.2562.17; Mon, 12 Jan 2026 07:03:12 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d4e9da5b-efc7-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qq7DU7JBv3op++sJHlFa2HdjdwXg26BcJj++veM1BCH7inmVtzAQsek+wUFbs77z5duD65TwOtGJf/eBXzaw/FGD2EJW0lzp/+X0AqsxtNu7hQIQZXQMcHARf7LPZ3xCVV86hECiN9f2/utIx8r0wxnkWvjbqb31HKgxJupC9wS+4xkOwUHN4wxwqQG910LKXensV2PKr4cvKbh5rbf40A31fsoSaYn0XThE1SylXIBhNUnEAAPZAmI5YVwHlH8PHK1mqHDutRuM358eNpxyUXHnwIY6XhEzBfc45jK5WNFjDTNulnDLQTjkXWQ0Y7CHvhDAuNwl+rmusSSOBs82tA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=phk+SV0NvzOuegtvacWtWxrgPC5vdBqZsS7cba8pcHo=; b=grmxCvAkJquPa1YQaYNOQXkhmq5bxqlrjUIqJtjiogfrSCFHwnwZ9QiHTRIm8PJbTnKHHMe8Ufdkg9JchM22y1SFGRNIDPDLQFFDmVWil56gGfn+HdDdNGMjptMmD+sizdbVqWlcFLGXePN1B6bbs/Hoqkz95RFy4wD6k9h++pwVd+tWGeG3FAie6P5QkQhLabGpnRAMGN4MfK0/xl/tfeoR8RbJIWhlIBHPry4yVDp9lEDEvJpx00LT+jo9epnlgDoOKaZWEo9NEFOWPUB/wbjsg0dU8NX9vRvUYCNe2rkdI0v8/RaGgWDBMQ+Iwxge+eaRGd8ThP+DvpPEvA4Gmg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=phk+SV0NvzOuegtvacWtWxrgPC5vdBqZsS7cba8pcHo=; b=2/Ble8uQA6IzkoW+a6+1sNEnTgScG7YfsV6OZhPKDblbc+Ux+JtaSf6sWio5tYmTwwxA+VciEogWm7zfelk9rxc8au6qOGAX8PUkAgZ3LmO76d/OuWr5unFvesPf73fxCOJvWHBe/10e2t8gCixqAz8sZTOJsatU0gXbvl5CKOk= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v2 1/2] x86/ucode: Fix typo s/mitigiated/mitigated/ Date: Mon, 12 Jan 2026 16:02:55 +0100 Message-ID: <20260112150259.74535-2-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260112150259.74535-1-alejandro.garciavallejo@amd.com> References: <20260112150259.74535-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 satlexmb09.amd.com (10.181.42.218) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF0001A104:EE_|MN0PR12MB6319:EE_ X-MS-Office365-Filtering-Correlation-Id: 6032fdb2-e864-408b-a766-08de51ebb5e2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?O8BmwpvLsr+zr/wyyZbQxl1f10kolt2Yx4kxGH5+njOQzlPFtzevo/bNU8C3?= =?us-ascii?Q?ApBVPPwxMdycxISGL+lQnzdKjhranQIdmXDSDDZptXjKp+EE9PiHF7784lOo?= =?us-ascii?Q?fo5gtgeWRCWCAm0KXdKhD/+HdwGiSfA7nKDysQSAyf7loVj0U9UV2m3WX74z?= =?us-ascii?Q?XPXFBaUIdkdp+G5cOSyaoNL+/wVutouSaJM5fq6FLxNCAF94/9UxRoFI1wf6?= =?us-ascii?Q?4rr6BPQsgakutZaBjEUMHuA4va77yI76UdCOYf1p+L6lGakWp4sIaVHMKYBL?= =?us-ascii?Q?8eWjPlhBhje5A50Kmkm3ovaTD04nhchAEnlIUQnwgwSlX2AzU1yFYgebrSDf?= =?us-ascii?Q?XGMwP1wn5aPHJCxBIdMX4sAXBcZqqlpxGKyRd42hHEoGsOuJvxuG+B53P3c3?= =?us-ascii?Q?IO6zTPRviwQ3wKOurIYlJY7NN3SPI77qz+zDhtX3KA2A1aTcln0+3NHQyyPF?= =?us-ascii?Q?pWQQ3chWXJwbE04JZQjMPTDIrrv0FTVVtruT2d4wdgEcwHoqG0zyoLwG+bK4?= =?us-ascii?Q?p0RckKVczyTwnqfZt7lHuuEU+46OUW3aiPQasExVFDkIcUOT5MHTRW9TM+D2?= =?us-ascii?Q?D5Fm7xqCXQcebxUwkJu5N3oiVf/HpSxFuuxuM/o+6Is5e5av0MGN1zLKTNHH?= =?us-ascii?Q?YT+ly0k6AlSifwUaSjBWRWxrj/bnKgcZOAGDx/KUfI3Ycdsyft3haY///mai?= =?us-ascii?Q?gIC9yxf4KlZvV+YfHcTYf1XOQrm26sXeOme+tZyGh8NJi8zVI4SkgdqW8v9C?= =?us-ascii?Q?y0s6wH7n53vaQB205v0X+t+9QInuRw9m4h4eN4kQhGRBxZ/Mj0r4D6N8H3SJ?= =?us-ascii?Q?Z7mQ/d8zdR0hRKNhgI/UUxo6IDNpkohjFyq8IVqSt1vGS/SN0AwrhrxgapDa?= =?us-ascii?Q?/CqxaM8JP8nbq2VoQZGH6kKnOrQ6C6ozIQKQKmz2wYiV3/IEdEH7e0Vb1K8T?= =?us-ascii?Q?WvaxrGRl056y+9y4elTQ8sg3rqenXxDTIttfzD4f9ZcC7J5l/xVV7Slgsfub?= =?us-ascii?Q?i7c50lU4UpG+wM65AqsoG0FmbeWgsgi63seZIGz4kIbm149IcZD0q2/MI7T4?= =?us-ascii?Q?WYxcdaYY7+kgIg+Sol7WXRaECltj4VhSsqY//IGcO5GU6cBvZjUH3w8ehRe1?= =?us-ascii?Q?p9D3R9gRGgLuw2rH+Fe0rDdRQ+loVH5wZ31IcsSRsf/Wr1uR6eYtlnzTmh+9?= =?us-ascii?Q?YdD72VlD/PoomPeUJ27mSxZAVRgAQt6r2HxUKRI9dqM03/FXrHt1k8GkmQGy?= =?us-ascii?Q?iJN0JFZ9V+k/npSuekpK8MWb3w7Cpi+/dA80R02xW4k+x+0u9RwSV4dGd8vp?= =?us-ascii?Q?TZ/dfXLwXGNA4VnSulSIYNL/leb2BC8vmblNcXJR5ue8RxVieSVbSKQTT4zG?= =?us-ascii?Q?NBdCxZ+Hd6ZKAlHTC87Sz7ow7aGCNsnRSw4iHUWK8W0ShyB8EcbR+fosVAmR?= =?us-ascii?Q?/3Bb3A0NSgMkgKtsmdogb0tCWN9genFWgMtvCM7XPvlYzlalnQOMU3UqqQVU?= =?us-ascii?Q?IeixhD/z2Un3QyKBZIV8g7d5aVOBVDtHjtnINTo24gJEPc0+6kgsc8hkR2OQ?= =?us-ascii?Q?hjdDraLqTgUL2GqaR4Y=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2026 15:03:14.3451 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6032fdb2-e864-408b-a766-08de51ebb5e2 X-MS-Exchange-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: BL02EPF0001A104.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6319 Not a functional change. Signed-off-by: Alejandro Vallejo --- xen/arch/x86/cpu/microcode/amd.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/cpu/microcode/amd.c b/xen/arch/x86/cpu/microcode/amd.c index 2760ace921..71b041c84b 100644 --- a/xen/arch/x86/cpu/microcode/amd.c +++ b/xen/arch/x86/cpu/microcode/amd.c @@ -101,7 +101,7 @@ static const struct patch_digest { } patch_digests[] = { #include "amd-patch-digests.c" }; -static bool __ro_after_init entrysign_mitigiated_in_firmware; +static bool __ro_after_init entrysign_mitigated_in_firmware; static int cf_check cmp_patch_id(const void *key, const void *elem) { @@ -127,7 +127,7 @@ static bool check_digest(const struct container_microcode *mc) * the digest of the patch against a list of known provenance. */ if ( boot_cpu_data.family < 0x17 || boot_cpu_data.family > 0x1a || - entrysign_mitigiated_in_firmware || !opt_digest_check ) + entrysign_mitigated_in_firmware || !opt_digest_check ) return true; pd = bsearch(&patch->patch_id, patch_digests, ARRAY_SIZE(patch_digests), @@ -676,7 +676,7 @@ void __init amd_check_entrysign(void) */ if ( (uint8_t)curr_rev >= fixed_rev ) { - entrysign_mitigiated_in_firmware = true; + entrysign_mitigated_in_firmware = true; return; } -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Jan 12 15:13:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 15:13:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200527.1516413 (Exim 4.92) (envelope-from ) id 1vfJbA-0004kL-Up; Mon, 12 Jan 2026 15:12:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200527.1516413; Mon, 12 Jan 2026 15:12:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfJbA-0004kE-SC; Mon, 12 Jan 2026 15:12:52 +0000 Received: by outflank-mailman (input) for mailman id 1200527; Mon, 12 Jan 2026 15:12:52 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfJbA-0004k8-0P for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 15:12:52 +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 28669820-efc9-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 16:12:49 +0100 (CET) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-42fbad1fa90so5602236f8f.0 for ; Mon, 12 Jan 2026 07:12:49 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5df939sm38765247f8f.21.2026.01.12.07.12.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 07:12:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 28669820-efc9-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768230769; x=1768835569; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=QN91mTdjZK1Ghls/nOSb3R2+DqKlpvdGpHv0sCbsnAU=; b=V1JXWUCtc7lSsWToL5x5V6Msyw3Rcw44QkLz2JzXf0Ka9IGmSGLdrUu0VUqBdDBFSe f7vzUUnmG5RFZNdm96ee6UPSqe1RX/GdstqOVhuPD+scIQpC5QmJMKTVNKPTpiLJr/js a6g4ENsNwE5zc6Rk4q7DlCkYFlDRj2VeCe2NdBSB7lGlsbrHAy0GNn0DPcuK6DpTA4lh nWvu8uu11zJDzcd7INs/ZhzL1yG2LPpzkKvGnzUW0nAS169Lb6vFxD2PlOZdvYLB6POQ nRs+wTXh7BcU15wlaL8WTHSc/QuuxtPfFh8zEKMsesCVdtJG6FZioY/Eu7PV2U7Dp1y0 SAlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768230769; x=1768835569; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=QN91mTdjZK1Ghls/nOSb3R2+DqKlpvdGpHv0sCbsnAU=; b=LqpNF7vMsh8EtXdKeR35xR37USrTymSyTy4Zs3iIWj997tIhhi69Uxub85Im1qXcp9 HuEl/gWqDte2Pl6IAimbxDqLyihI6WcxTVSoKOJx3nLethR2IGE5Rovc49aLVjvo1KIj GHfMZofIA/n5eN44fOK6IVvB4kniMvNwPpL1NGPsCjpnV0v9QYp7HAaNvYymuQfSvcP6 i+1CuFVIiSnmy6DuCOui6oUTanzPkDqf8kKtyk/KJKTp8wrQSNp0pJ1d4Mo0OzqLD/Gn MkAvBOHOhKpW1u9gLFJoEdOW8l7uZa3yxGuSwVZNt145oj4cpxMMPUKWxFtuKIfzMBFj S7yg== X-Forwarded-Encrypted: i=1; AJvYcCU/Yy9QmMbUL0j0qsCXkiwWa+9zOo8EFsZntl3p1K3RU80lDPWKV6UNLW/VRw90WwTQkbIpm4VF3wI=@lists.xenproject.org X-Gm-Message-State: AOJu0YxGPevVpG9tmiqYC6L0mM+VK7DmD0slfXKdl+ND38AqFyrYhdK6 Hulx+OLxK0F0bl2ZLuISVgPEL2WaLUkHm5d9WCKk5+DgwIPRSUTWZPavzuC3fHm0WA== X-Gm-Gg: AY/fxX7zmeIzbEAU7GitWkVfRBhEmvdH1iJFwXpemwyb+yRkXwJU9xCt5c7wqm6AsE/ cK5R1uGsxH++omJFOrH6iRZuTDBn/JBW3sq56RQ+X9LuH7atKl73mhuSQ9/7VZujtSZo7dMZCpR yFCOqElZVnsNZWQ3ql8aYcM5SG+GUrpBpfIrDQ1nhU7yLe2X38ITfluTdLvNYuce3X9sLH7m5fR 8dCmPKITlw6riIG4Pk+h1jnIxKB5alDYCrsFeON4V4QelWKrZBt89ZE4eTwxGE0Z8W19syB6mcv pXZpad00+2DHTwf5OOnzeOaUsle32dIfQI1HtYat7r3XApDeCNyGekMucFoP5QJMGyM9WAwGSyn E+Ik+pgFS4gaQ02EF9zE1A0eZsI3aIGv9TgWknV4XHShJSJhZd5VdleamqkWFRQBRXe3cXTRXOi bJ2EFMnhhY6lum/3vOpNfdasLZ279uc66VAwuUMNOkEAHvzk/1z20tsva9Ar0qIQaWuSEMOR9pT 2g= X-Google-Smtp-Source: AGHT+IF4/92KVn+U24L6KHlLu/MnYpFidyCTPpxgIV5wiztXTZC58FaUH8O48WnsF1KYuGfQU04CWg== X-Received: by 2002:a05:6000:1865:b0:432:857d:e42c with SMTP id ffacd0b85a97d-432c37c87famr19821138f8f.34.1768230768780; Mon, 12 Jan 2026 07:12:48 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2026 16:12:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 12/15] xen/riscv: introduce sbi_set_timer() 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: <84cf8fb2331614c6d0cc6e9030571f42bfc6d928.1766595589.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: <84cf8fb2331614c6d0cc6e9030571f42bfc6d928.1766595589.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 24.12.2025 18:03, Oleksii Kurochko wrote: > Introduce pointer to function which points to a specific sbi_set_timer() > implementation. It is done in this way as different OpenSBI version can > have different Extenion ID and/or funcion ID for TIME extension. > > sbi_set_time() programs the clock for next event after stime_value > time. This function also clears the pending timer interrupt bit. > > Introduce extension ID and SBI function ID for TIME extension. > > Implement only sbi_set_timer_v02() as there is not to much sense > to support earlier version and, at the moment, Xen supports only v02. Besides this somewhat contradicting the use of a function pointer: What about the legacy extension's equivalent? > --- a/xen/arch/riscv/include/asm/sbi.h > +++ b/xen/arch/riscv/include/asm/sbi.h > @@ -33,6 +33,7 @@ > > #define SBI_EXT_BASE 0x10 > #define SBI_EXT_RFENCE 0x52464E43 > +#define SBI_EXT_TIME 0x54494D45 > > /* SBI function IDs for BASE extension */ > #define SBI_EXT_BASE_GET_SPEC_VERSION 0x0 > @@ -65,6 +66,9 @@ > > #define SBI_SPEC_VERSION_DEFAULT 0x1 > > +/* SBI function IDs for TIME extension */ > +#define SBI_EXT_TIME_SET_TIMER 0x0 Move up besides the other SBI_EXT_* and use the same amount of padding? > @@ -138,6 +142,19 @@ int sbi_remote_hfence_gvma(const cpumask_t *cpu_mask, vaddr_t start, > int sbi_remote_hfence_gvma_vmid(const cpumask_t *cpu_mask, vaddr_t start, > size_t size, unsigned long vmid); > > +/* > + * Programs the clock for next event after stime_value time. This function also > + * clears the pending timer interrupt bit. > + * If the supervisor wishes to clear the timer interrupt without scheduling the > + * next timer event, it can either request a timer interrupt infinitely far > + * into the future (i.e., (uint64_t)-1), or it can instead mask the timer > + * interrupt by clearing sie.STIE CSR bit. > + * > + * This SBI call returns 0 upon success or an implementation specific negative > + * error code. > + */ > +extern int (*sbi_set_timer)(uint64_t stime_value); Despite the pretty extensive comment, the granularity of the value to be passed isn't mentioned. > --- a/xen/arch/riscv/sbi.c > +++ b/xen/arch/riscv/sbi.c > @@ -249,6 +249,26 @@ static int (* __ro_after_init sbi_rfence)(unsigned long fid, > unsigned long arg4, > unsigned long arg5); > > +static int cf_check sbi_set_timer_v02(uint64_t stime_value) > +{ > + struct sbiret ret; > + > +#ifdef CONFIG_RISCV_64 > + ret = sbi_ecall(SBI_EXT_TIME, SBI_EXT_TIME_SET_TIMER, stime_value, 0, > + 0, 0, 0, 0); > +#else > + ret = sbi_ecall(SBI_EXT_TIME, SBI_EXT_TIME_SET_TIMER, stime_value, > + stime_value >> 32, 0, 0, 0, 0); > +#endif How about ret = sbi_ecall(SBI_EXT_TIME, SBI_EXT_TIME_SET_TIMER, stime_value, #ifdef CONFIG_RISCV_64 0, #else stime_value >> 32, #endif 0, 0, 0, 0); ? Granted some may say this looks a little m ore clumsy, but it's surely less redundancy. Also I'd suggest to use CONFIG_RISCV_32 with the #ifdef, as then the "else" covers both RV64 and RV128. > + if ( ret.error ) > + return sbi_err_map_xen_errno(ret.error); > + else > + return 0; > +} While I understand this is being debated, I continue to think that this kind of use of if/else isn't very helpful. Function's main return statements imo benefit from being unconditional. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 15:16:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 15:16:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200538.1516422 (Exim 4.92) (envelope-from ) id 1vfJeh-0005Kt-D3; Mon, 12 Jan 2026 15:16:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200538.1516422; Mon, 12 Jan 2026 15:16:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfJeh-0005Km-AW; Mon, 12 Jan 2026 15:16:31 +0000 Received: by outflank-mailman (input) for mailman id 1200538; Mon, 12 Jan 2026 15:16: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 1vfJef-0005Kg-Ob for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 15:16:29 +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 a6a00a22-efc9-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 16:16:21 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by AM7PR03MB6627.eurprd03.prod.outlook.com (2603:10a6:20b:1be::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Mon, 12 Jan 2026 15:16:19 +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.9499.005; Mon, 12 Jan 2026 15:16: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: a6a00a22-efc9-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rNjRm6kXmZj40gch0gu9Cio66cWIfKVzOBdthxwutgNxYZhIDm8ZBXm/UqaIBrAVGoNiDSntvb1pXMWBXwrL0c9OfBV67S0z7NSAu7OfiQuDhuX2imbcnrLO5nCwDM+YP7zcg8/0M2negSuHLlHBn65aanxfcLc8EgIZAxMAfV7xPsMe2U8jZTN1aLqn54DJP38kMusvlKwGpac8g6YZ5OcU6YsbgFqZeHtx8Gap668vcMfLtSDbe3Ywl3v3+xKJWhOBj0hNOxF2HvYRFwYsrSjxH5ymUqMjj2V6cmCAFufkcOLJzJJJyB6xPw2AFcMqyBKM4AjJu9y4YnQt9wObcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9mWGS+L361xhqia19vi8YLSgRAMLD2/gMJg3VkdUYZY=; b=Ole1fLcDg7NtVFySRWBoLO4xaYMawl12/TDGU9LJJTp01c5vt50EAXJYpm3eHYucLaZHVZkBc5f0uKjS48bl0RgOkSDqGUiQN94+k07mHW65SwOhw16OROOZ02NrwPeVP6NIG3bXqKYWa/5iLRiWhw6NhVSSjKb5JDrCqwWsyFhlCzqcRR/SbwVJVGB3LQrvwDqbSaCDV/iWa7XLZWV0ekKmQMZDlxCw88GOhLHuQJtXcr9mPofcQ0p8dt6FzX6t9H2mR0Q8O8iD69ulIUNuN0l6fEz3BQwKd+4FkW2Cjo9beaXcIR9NXJKsnRBn1P5CIO+HFgbxb4StrWJtxl881w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9mWGS+L361xhqia19vi8YLSgRAMLD2/gMJg3VkdUYZY=; b=N2QJaSw+WF/d1L5yEipZo5Bm5ZFQ/CNFc6R7dY30da/nhuDl0pjt9dP1BRENtuwAvTHMk+yoByN7wRGa4C7EnOx94DDI169H95SVro/EPB0ZDnl9XEolBBpWOntix2F2+n2YZC1kbnasz9MZ+rr0DYNKe2otBdUn2eTfWUu58qXUjI3dANpF1GDUN+hk8jBTSB/7uOGd1XsRLDgtWZLEL1k4Yq55bGoPxWO/tYmU0zXzKt+zL7ST7Ert59KP3hcAEjzDU2IzKsAvEQ9zNjmSiltCVhe8jlicafL7SINE5Bfs53Nlmn8SOzEyNoUdSCb81uTtbcd64h3ORnafYk4GVw== From: Oleksii Moisieiev To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v6 1/5] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu Thread-Topic: [PATCH v6 1/5] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu Thread-Index: AQHcSyafS16SOr0Uk0OkeRdy8jd8Cg== Date: Mon, 12 Jan 2026 15:16:18 +0000 Message-ID: <5d8f55a6-7182-4e9d-a139-96fddb9450f8@epam.com> References: <9598b2e2-7df8-40c5-82cb-c097121af763@suse.com> In-Reply-To: <9598b2e2-7df8-40c5-82cb-c097121af763@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_|AM7PR03MB6627:EE_ x-ms-office365-filtering-correlation-id: 66bb91bc-adca-4536-336e-08de51ed897b x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|7416014|376014|1800799024|38070700021; x-microsoft-antispam-message-info: =?utf-8?B?akJxM3ZGbHhNOWtjMHJvWTJWQWxUdjVXZ2JqWlMvWWVPRWZKL294bnp1SGZE?= =?utf-8?B?ejJleTI3bGhXYkFCQVBRa3NybXBOTThBdmhwZGVvYVVBdjRCaGt6RFNCVXc5?= =?utf-8?B?UFZGZXNkYTcycnNNQkNSaDJFSmdaWG5FSzRpMVVOMC9Zdy90d0RFY29zeExq?= =?utf-8?B?SmhkanZkcEtEWHA1REsydi9FMTc3NC9yZVpVWUpyZTBya1c0ZjBJRVpNSE5L?= =?utf-8?B?VndoRnFud05ER01JZm40aHE4aTJaUjh4anhjQythUUYrRUt4Wm04QzUzQUdw?= =?utf-8?B?Z0NDbHFiSjdrZDVsZnRTZ0xTNmpSaThpQWRtU0Q0cklIdWRRd2FiVWJ3RmZB?= =?utf-8?B?YXJpSmM4cGlHSnhOYXk0MDJraDdDQmdxcEp4VG1CSWM2bUYxbHAyZ2R3dE9N?= =?utf-8?B?OTdPUjlaenpqS040U2NQYVNySk5hQ1hEYWJESUlHMXJkcm9RbEhpbDRFQkM1?= =?utf-8?B?aXl6Qk9lZWNYZEtOOFh6SmR4T0FHVkZldmE0NlYrOFVVZ21zWlQ0WllsRit5?= =?utf-8?B?MFJuLzhtVDl2czVzbUswMi9reDhVQWxYT3ZNV0VxeCtwb0FxcU1CbS94T0xx?= =?utf-8?B?ZHlLWXpRNjlUYzVaUlQzWTRVMXVkOHJ5d1hJUEo1ektkMWlOVWMxdVR6eUhY?= =?utf-8?B?YUdLNytXQUV0a1U3cm9LejdhR3hQYXpreUJMNVNuWEUrelQyc2xWSTJBUGQz?= =?utf-8?B?STgwUEFHMllaWUZWckI2YVJRNVNiRWJvL1NJcjN5M1lMQk00SnBUd0QyZ29m?= =?utf-8?B?SDRNZ0ROdndBc3BHSHVGalRaWVpuL0lEaFJZdFN2bWVBYnRob2xxa1p1SUEz?= =?utf-8?B?L2N2Z1hDYkVzMGxzY21ER2dDSmcvUElTdk5tcEkvTytFQ0RjT1I1VlBoWUJv?= =?utf-8?B?Q1FpZ3EwODNibnBSRnI0VFU3SlRad04wWURaSERKRDVQTHJXRFFPUnBSbGlB?= =?utf-8?B?MkVOSkhzWjU0K2syZTZRd2RHRUdnODc1Q1VBNSs3R1lvajhwNGU1YlpoMzN0?= =?utf-8?B?K09aVExrakxSYXVNWHlneDVoS0ZSMFhzMFErMUUxTHZIdUtJcGpMN3lFcGkx?= =?utf-8?B?ckMxZ0N2L25xWFpGakNjRzNYcU54YjZxa2pQbi9zWUQ1aVd5c2E5eVljQ0JC?= =?utf-8?B?UEpIOUdjMlRCdUlGWm9FMit5QmtVRmEvZExUc0F2VUpGL0NHTkNnY2NpQXNi?= =?utf-8?B?TXBMRDRzYWhURkxPdUg3OUxOQmx4NzBZSEx2WDFUVzJGL3k3MnlEWFpqanIr?= =?utf-8?B?eFpsRHdxZ3RDL2hBaVlpNktRSFFFUXFIbzFwckZuUEJCREJCOUxYZnF2SmZp?= =?utf-8?B?SFV0cEZsWUV2VVBBbmFDeXBROGZZQitCR1lWK1htOUVNQWNvb2lpNGFaeCsz?= =?utf-8?B?UWxKQUZiVUJwVGFNZ1FzNWwvMnBnampEOEtZRHN5TGN1V1JUSDZ1UDhtcTlm?= =?utf-8?B?bm5NblF0d3FtejFhOWhWTUZSOGZubVRXUWVIVVlreEtNSHhUUk1TcmR2bjRO?= =?utf-8?B?SUVxdyttcVRXV3lPS0RvYUd3NFUxTjZ5VHozejFrcXJtSndXejRKUis3RkZT?= =?utf-8?B?bzlFc09keEgzRW9BQVZPOHR1cFhkb2xLNUVFVE1EVk9YajRtYTl5MmRHOVFD?= =?utf-8?B?c3NSQjE4TlJZOWpSdmxoR29icUx3dDV3ekdGY0xuMUcyMUI2MkJyMXpJaHQz?= =?utf-8?B?RVAyZWw2R05HZGJBMnhEZ25zZjBnaEVFMFY0Sm41NGU0MVlxNVBibjNCYjcv?= =?utf-8?B?bytjTzFzUnV4VWJYTmFOWnhhSDUrcERKZ0hvWjVucE1vQ1I3K042T2EwRjgw?= =?utf-8?B?ZmtSVFVWWXM3MlNmVUpSR1BLYWhHN1RKb0J5aUdmTm5Qb0I0bStDNEdDMmJO?= =?utf-8?B?TEE1TmFIZHVsT3BLV3RySWg5ZWN1ZDlibzU0MTZDWkppSzN1ZXlJbGFFVVNq?= =?utf-8?B?U095Zk1seWNoYnp2elRmVDhwcUtYRjFxTXRYdkoxNmlsWFQxdVJ6OHFOK0E0?= =?utf-8?B?bzJPU1VEWnVFdThOWnV4QXRaYlVIMnRBYU9rQjhVOFlIb0d2cFIwTyszQURD?= =?utf-8?Q?WWNpVv?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(7416014)(376014)(1800799024)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?YUZlSmJtV2cvRGZXNk9zT29lcm5wUlk5dlI3aXoyT2x6ajVhZ1hlNDNQSmFH?= =?utf-8?B?UFEvaHV2TGhTeVVxcFg1Z01LSldHekN0TWZCeTdzR0Ftb3FNRHlZSmRGRmRX?= =?utf-8?B?Y2NvVGFVVHpqVGRrSDR4L0xTcFNMMmN2dzlTZHExcytuVGROb1ZteGtnc3hX?= =?utf-8?B?RWsxVnVXZVhETTU4dDd4TTgwelpVdmRWWHJhNnlUVmtXWWluSTJjV0ZUbkJI?= =?utf-8?B?RERCOTNzcTF5S25pZStCUkxVTWVYci9jekRWNHhjU0xVRE16VlI1aFlPL0ls?= =?utf-8?B?MnNEeEFxeU5BNkFsdWxzd2ozd2QwTkN3b0FMSXB4aHMyM1h6TzhEVVJsOEZ4?= =?utf-8?B?UStiQWNwKzlBTmROL1lwSmlRei9YeUFBN2Z3TXBYbmJNaTFvMWgzTDRFVzNO?= =?utf-8?B?TUVoaVJqTER1aXd1a0d1dWRNZ0k1Z05MU3NxZVVtSXdzR2lOVnUwbnp3bWJ1?= =?utf-8?B?MFNzQ0VaSE5xL1QxUGVrMHc4MFBaSllmNCsyaDE3M000eXdONnJQTUM2bnlQ?= =?utf-8?B?Yzh2dDBjc0NQMy9BckhqZW96ZHZ4QjNHejgrbjduUnl4OVovK2IrdWhtc2Np?= =?utf-8?B?MlN4Um90aWtraXJoaVFrWktFQjBqQmNyOWM2Z1BHY0JFL2p4bHAzMnVqT2po?= =?utf-8?B?TEtTamVnQ0FXT2VNZnJKMDBEZDAxa1pVZGl0eUk3QkQ4aWtNcDhnbW5OYkp3?= =?utf-8?B?TWhHNHoyRFZyMDduaGlUalNadit4OW9Ra3ZFeEhmbURtYU5NYU4veHNTMk8z?= =?utf-8?B?TmUzVi91eWRTcUpXNitqYUFuS0pIVElOMnA4YittZXUrR2N0Zi85S2s3NHdi?= =?utf-8?B?ZnpYanE1TTRmMGtHdnUrTXd6czdiNFRWMkZzTkdWaFIvUEc0YmovUmYwVEJX?= =?utf-8?B?eDZJSmh4QlpoNE1LdFpjcEZoRDdHdW9sRGIwR2kxVWNWbERYYjhMbkx0cVhD?= =?utf-8?B?L05tVWo0dEVkYmJoWVFJSTBIWWRNVGNIZVF3TkNtb2lFeFlZZEJSdnkxUjRC?= =?utf-8?B?ME1OcG9lS09tRHVkUWZPVHBxRDVlMEU1Nm1JWU9oc3k3RHRqZEZsV2d5WHlK?= =?utf-8?B?MSt2VThJTldxMk00dXhxbXhid01sbUlrdE1qc0lCdk9wdis0dzBSZmpxUkRv?= =?utf-8?B?OE5BN3JCTnNqemNHYmhQdHNCV2RlQjB2c25KcEx4SFFkQnVtemNXMDByaGE5?= =?utf-8?B?T213dE5lUUhQUXljVkFjVmNuU2tlU3dOU0F1RUxEY0FpaDU3TGVteVBmYmk5?= =?utf-8?B?Z1RMRHVQdDZtWEhFTWFreDFmUG1NTVUwVDB0OXh2K1FoM3BXZVZteHlvVVNk?= =?utf-8?B?VUFodnpZWkNmT3hJMXZjd1dMWDQyc3cvMjFTZ3JzbHBhYk8rN2FGUWt1MzNj?= =?utf-8?B?bzk4L1laWWdaeEh6OG8xaTdpdHlRN1pHQUo1dUJSbDJMbTJJUlYxS1VzazRT?= =?utf-8?B?Q0F4RStSZUVDYm9KK0ROdzVSbkVSMzFKSmlpZWhmWWp6MkFxak1GNVliT3BU?= =?utf-8?B?NWxDcy9RcUZGQjdoUkk2V3FOZWNqU0JTbnY4RE5NczNMSTh3YVZucWc5N0Z3?= =?utf-8?B?dU5mS2VpTERHTm1Lc2dSZFBjWjZRMWUzZzRTdzFEVmhPNzc3cXZqNzFVM0lK?= =?utf-8?B?Q3RiaWlRSWFKUW1lcUZGRmdMblVHeC9SWVRvMkJrZkR0R1lndDBIanhwc3NK?= =?utf-8?B?ZVhNanFIay8zaGtGR0lyTXNnUW1LQ25XNDA5QjNpbEFaMTRUTGM4M2lnWnM1?= =?utf-8?B?SU0zS05rMWhpZ3lvbTBncXRxQnRFc1hHc0hFbm9panpKblRDTXdXd1dPZUFQ?= =?utf-8?B?TEdBYjRPcGgvK1dpS3lhbEh5V05ZOTVjYmRNWHJKR21YWERlK2gyS2s4bUIx?= =?utf-8?B?OW1EVVQzQlMzbUR0V3lkeXdkSFBJNGgrT0tiY0N6SlA0c3VWR0QzSzJEcUQ5?= =?utf-8?B?Q2lycHIzeHBvTkRYNzVidEZNSVNWTSt3YXJHSkRCajVDN3pXcXcrY29aZXlQ?= =?utf-8?B?YkI5VitsRlBTaTlOOHlXZzVYSWppYzFnSU02ZkhCWlp4TXp5dTVteHRkdUZP?= =?utf-8?B?YyszdlFVTkNKZDNGM3RmRldPZ2pOa1NkSW1vWUhQSHZmYkVUNVJ2TkNTOUFC?= =?utf-8?B?SG5Tc0hCREdwOHRoV3hScCtBWTd1NWw0UnRSVlM5NFF6bHNqN2hHcGtUVU9N?= =?utf-8?B?MzM3OTVRNjdVdkNtUXN4blVURlhFU1VLRFJneVlPT2dqSkFoM1ptQzI3ZnFD?= =?utf-8?B?cm04R2NmVDJmbG5Oa3BjakF0amtnMndiZzB0KytpTmRhbExvdUJNYlZ2UmtN?= =?utf-8?B?MDU5VjdacmVXcnVkU1Q3a2VMY01VZllwbUc1M1dBUlA4Z25pakRPQ1RvMXl2?= =?utf-8?Q?SzqZndr1BeTMJSqg=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <0F4250CADFED214CBAEF866D9F108F3D@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: 66bb91bc-adca-4536-336e-08de51ed897b X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2026 15:16:18.8319 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WzNKpW5CejYx6+aAWhjVnxmb8AMrgM/SyyWO+sQPfCCVQf5fvHTiwQKD0/jEOEVYCrO5Wbv8Ruxv+QGBtXF5phco61Oik4dM+m0vGPLDokI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR03MB6627 SGkgSmFuLA0KDQpTb3JyeSBmb3IgYSBsb25nIHNpbGVuY2UuIFBsZWFzZSBzZWUgbXkgYW5zd2Vy cyBiZWxvdzoNCg0KT24gMDYvMTEvMjAyNSAxMjowOSwgSmFuIEJldWxpY2ggd3JvdGU6DQo+IE9u IDAxLjExLjIwMjUgMTI6NTYsIE9sZWtzaWkgTW9pc2llaWV2IHdyb3RlOg0KPj4gLS0tIGEveGVu L2NvbW1vbi9kb21jdGwuYw0KPj4gKysrIGIveGVuL2NvbW1vbi9kb21jdGwuYw0KPj4gQEAgLTI5 LDYgKzI5LDcgQEANCj4+ICAgI2luY2x1ZGUgPHhlbi94dm1hbGxvYy5oPg0KPj4gICANCj4+ICAg I2luY2x1ZGUgPGFzbS9jdXJyZW50Lmg+DQo+PiArI2luY2x1ZGUgPGFzbS9maXJtd2FyZS9zY2ku aD4NCj4+ICAgI2luY2x1ZGUgPGFzbS9pcnEuaD4NCj4+ICAgI2luY2x1ZGUgPGFzbS9wYWdlLmg+ DQo+PiAgICNpbmNsdWRlIDxhc20vcDJtLmg+DQo+IERvZXMgdGhpcyBidWlsZCBhdCBhbGwgb24g bm9uLUFybT8NCkdvb2QgZmluZGluZy4gVGhhbmtzIC0gd2lsbCBmaXguDQo+PiBAQCAtODI3LDcg KzgyOCwzMiBAQCBsb25nIGRvX2RvbWN0bChYRU5fR1VFU1RfSEFORExFX1BBUkFNKHhlbl9kb21j dGxfdCkgdV9kb21jdGwpDQo+PiAgICAgICBjYXNlIFhFTl9ET01DVExfdGVzdF9hc3NpZ25fZGV2 aWNlOg0KPj4gICAgICAgY2FzZSBYRU5fRE9NQ1RMX2RlYXNzaWduX2RldmljZToNCj4+ICAgICAg IGNhc2UgWEVOX0RPTUNUTF9nZXRfZGV2aWNlX2dyb3VwOg0KPj4gKyAgICAgICAgaW50IHJldDE7 DQo+PiArDQo+PiArICAgICAgICAvKg0KPj4gKyAgICAgICAgICogQWRkIGNoYWluZWQgaGFuZGxp bmcgb2YgYXNzaWduZWQgRFQgZGV2aWNlcyB0byBzdXBwb3J0DQo+PiArICAgICAgICAgKiBhY2Nl c3MtY29udHJvbGxlciBmdW5jdGlvbmFsaXR5IHRocm91Z2ggU0NJIGZyYW1ld29yaywgc28NCj4+ ICsgICAgICAgICAqIERUIGRldmljZSBhc3NpZ24gcmVxdWVzdCBjYW4gYmUgcGFzc2VkIHRvIEZX IGZvciBwcm9jZXNzaW5nIGFuZA0KPj4gKyAgICAgICAgICogZW5hYmxpbmcgVk0gYWNjZXNzIHRv IHJlcXVlc3RlZCBkZXZpY2UuDQo+PiArICAgICAgICAgKiBUaGUgYWNjZXNzLWNvbnRyb2xsZXIg RFQgZGV2aWNlIHByb2Nlc3NpbmcgaXMgY2hhaW5lZCBiZWZvcmUgSU9NTVUNCj4+ICsgICAgICAg ICAqIHByb2Nlc3NpbmcgcHJlc2VydmluZyByZXR1cm4gY29kZSBhbmQgZXhwZWN0ZWQgdG8gYmUg ZXhlY3V0ZWQgZm9yDQo+PiArICAgICAgICAgKiBhbnkgRFQgZGV2aWNlIHJlZ2FyZGxlc3MgaWYg RFQgZGV2aWNlIGlzIHByb3RlY3RlZCBieSBJT01NVSBvcg0KPj4gKyAgICAgICAgICogbm90IChv ciBJT01NVSBpcyBkaXNhYmxlZCkuDQo+PiArICAgICAgICAgKi8NCj4+ICsgICAgICAgIHJldDEg PSBzY2lfZG9fZG9tY3RsKG9wLCBkLCB1X2RvbWN0bCk7DQo+IFdoeSB3b3VsZCB0aGlzIG5vdCBi ZSB0aGUgaW5pdGlhbGl6ZXIgb2YgdGhlIG5ldyB2YXJpYWJsZT8gKEkgYWxzbyBkb24ndCB0aGlu aw0KPiB0aGF0IHdlJ3ZlIGRlY2lkZWQgdG8gcGVybWl0IHZhcmlhYmxlIGRlY2xhcmF0aW9ucyBh dCBvdGhlciB0aGFuIHRoZSB0b3Agb2YNCj4gc2NvcGVzIG9yIHdpdGhpbiBlLmcuIGEgZm9yKCkg bG9vcCBjb250cm9sIGNvbnN0cnVjdC4pDQo+DQorDQo+PiAgICAgICAgICAgcmV0ID0gaW9tbXVf ZG9fZG9tY3RsKG9wLCBkLCB1X2RvbWN0bCk7DQo+PiArICAgICAgICBpZiAoIHJldCA8IDAgKQ0K Pj4gKyAgICAgICAgICAgIHJldHVybiByZXQ7DQo+IFdoeSB3b3VsZCB5b3UgaW52b2tlIGJvdGgg aW4gYWxsIGNhc2VzPyBJZiBzY2lfZG9fZG9tY3RsKCkgaGFuZGxlZCB0aGUgcmVxdWVzdCwNCj4g dGhlcmUgaXNuJ3QgYW55IHBvaW50IGluIGFsc28gaW52b2tpbmcgaW9tbXVfZG9fZG9tY3RsKCks IGlzIHRoZXJlPyBPciBlbHNlIGlzDQo+IHRoZXJlIG1heWJlIHNvbWUgY3J1Y2lhbCBhc3BlY3Qg bWlzc2luZyBmcm9tIHRoZSBkZXNjcmlwdGlvbiAob3Igbm90IGV4cGxpY2l0DQo+IGVub3VnaCB0 aGVyZSBmb3IgYSBub24tU0NJIHBlcnNvbiBsaWtlIG1lKT8NCj4NCj4gQWxzbyB0aGlzIGRvZXNu J3QgbG9vayB0byBmaXQgdGhlIGRlc2NyaXB0aW9uIHNheWluZyAiVGhlIFNDSSBhY2Nlc3MtY29u dHJvbGxlcg0KPiBEVCBkZXZpY2UgcHJvY2Vzc2luZyBpcyBjaGFpbmVkIGFmdGVyIElPTU1VIHBy b2Nlc3NpbmcgLi4uIg0KPg0KV2UgY2FsbCBib3RoIGJlY2F1c2UgU0NJIGFuZCBJT01NVSBjb3Zl ciBkaWZmZXJlbnQgY29uY2VybnMgYW5kIGEgRFQgDQpkZXZpY2UgbWF5IG5lZWQNCmJvdGg6IFND SSBmb3IgRlctbWVkaWF0ZWQgYWNjZXNzIGNvbnRyb2wgKHBvd2VyL2Nsb2Nrcy9yZXNldCkgYW5k IElPTU1VIA0KZm9yIERNQSBpc29sYXRpb24uDQpTQ0kgcmV0dXJuaW5nIHN1Y2Nlc3MgZG9lcyBu b3QgbWVhbiB0aGUgSU9NTVUgd29yayBpcyByZWR1bmRhbnQuDQoNCi0gc2NpX2RvX2RvbWN0bCgp IHJldHVybnMgLUVOWElPIHdoZW4gaXQgaGFzIG5vdGhpbmcgdG8gZG8gKG5vbi1EVCwgbm8gDQpt ZWRpYXRvciwgbWVkaWF0b3IgbGFja3MgYXNzaWduIGhvb2spLg0KVGhhdCBpcyB0aGUg4oCcbm90 IGhhbmRsZWQgYnkgU0NJ4oCdIHNlbnRpbmVsOyBpbiB0aGF0IGNhc2UgdGhlIGNvZGUgDQpwcm9j ZWVkcyB0byBJT01NVSBub3JtYWxseS4NCi3CoCBXaGVuIHNjaV9kb19kb21jdGwoKSBzdWNjZWVk cyAoMCksIHRoZSBkZXZpY2UgbWF5IHN0aWxsIHJlcXVpcmUgSU9NTVUgDQpwcm9ncmFtbWluZw0K KGUuZy4sIERUIGRldmljZSBoYXMgYW4gaW9tbXVzIHByb3BlcnR5KS4gU2tpcHBpbmcgaW9tbXVf ZG9fZG9tY3RsKCkgDQp3b3VsZCBsZWF2ZSBETUEgaXNvbGF0aW9uIHVucHJvZ3JhbW1lZC4NCg0K VGhlIGZpbmFsIGlmIChyZXQxICE9IC1FTlhJTykgcmV0ID0gcmV0MTsgZW5zdXJlcyB0aGF0IGlm IGJvdGggcGF0aHMgcmFuIA0KYW5kIElPTU1VIHN1Y2NlZWRlZCwNCmFuIFNDSSBmYWlsdXJlIGlz IHN0aWxsIHJlcG9ydGVkIHRvIHRoZSBjYWxsZXIuDQoNCkRldmljZS10cmVlIGV4YW1wbGVzIHRv IGlsbHVzdHJhdGUgdGhlIGR1YWwgcm9sZXM6DQoxLiBBY2Nlc3MtY29udHJvbGxlZCBEVCBkZXZp Y2UgKG5vdCBuZWNlc3NhcmlseSBJT01NVS1wcm90ZWN0ZWQpOg0KDQppMmMzOiBpMmNAZTY1MDgw MDAgew0KIMKgwqDCoCBjb21wYXRpYmxlID0gInJlbmVzYXMscmNhci1nZW4zLWkyYyI7DQogwqDC oMKgIHJlZyA9IDwwIDB4ZTY1MDgwMDAgMCAweDQwPjsNCiDCoMKgwqAgcG93ZXItZG9tYWlucyA9 IDwmc2NtaV9wZCA1PjvCoMKgwqDCoMKgIC8vIEZXLW1hbmFnZWQgcG93ZXIgZG9tYWluDQogwqDC oMKgIGNsb2NrcyA9IDwmc2NtaV9jbGsgMTI+Ow0KIMKgwqDCoCBjbG9jay1uYW1lcyA9ICJmY2si Ow0KIMKgwqDCoCBhY2Nlc3MtY29udHJvbGxlcnMgPSA8JnNjbWlfeGVuIDA+Ow0KIMKgwqDCoCAv LyBubyBpb21tdXMgcHJvcGVydHk6IFNDSSBtYXkgbmVlZCB0byBhdXRob3JpemUvcG93ZXIgdGhp cyBkZXZpY2U7IA0KSU9NTVUgaGFzIG5vdGhpbmcgdG8gZG8NCn07DQoNCjIuIElPTU1VLXByb3Rl Y3RlZCBEVCBkZXZpY2UgdGhhdCBzdGlsbCBtYXkgbmVlZCBTQ0kgbWVkaWF0aW9uOg0KdnB1OiB2 aWRlb0BlNmVmMDAwMCB7DQogwqDCoMKgIGNvbXBhdGlibGUgPSAicmVuZXNhcyxyY2FyLXZwdSI7 DQogwqDCoMKgIHJlZyA9IDwwIDB4ZTZlZjAwMDAgMCAweDEwMDAwPjsNCiDCoMKgwqAgaW9tbXVz ID0gPCZpcG1tdSAwIDA+O8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAvLyBuZWVkcyBJT01NVSBt YXBwaW5nIGZvciBETUEgDQppc29sYXRpb24NCiDCoMKgwqAgcG93ZXItZG9tYWlucyA9IDwmc2Nt aV9wZCA3PjvCoMKgwqDCoMKgIC8vIEZXLW1hbmFnZWQgcG93ZXIvY2xvY2svcmVzZXQNCiDCoMKg wqAgY2xvY2tzID0gPCZzY21pX2NsayAzND47DQogwqAgwqAgYWNjZXNzLWNvbnRyb2xsZXJzID0g PCZzY21pX3hlbiAwPjsNCiDCoMKgwqAgY2xvY2stbmFtZXMgPSAidnB1IjsNCn07DQo+PiAtLS0g YS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9kZXZpY2VfdHJlZS5jDQo+PiArKysgYi94ZW4vZHJp dmVycy9wYXNzdGhyb3VnaC9kZXZpY2VfdHJlZS5jDQo+PiBAQCAtMzc5LDYgKzM3OSwxMiBAQCBp bnQgaW9tbXVfZG9fZHRfZG9tY3RsKHN0cnVjdCB4ZW5fZG9tY3RsICpkb21jdGwsIHN0cnVjdCBk b21haW4gKmQsDQo+PiAgICAgICAgICAgICAgIGJyZWFrOw0KPj4gICAgICAgICAgIH0NCj4+ICAg DQo+PiArICAgICAgICBpZiAoICFkdF9kZXZpY2VfaXNfcHJvdGVjdGVkKGRldikgKQ0KPj4gKyAg ICAgICAgew0KPj4gKyAgICAgICAgICAgIHJldCA9IDA7DQo+PiArICAgICAgICAgICAgYnJlYWs7 DQo+PiArICAgICAgICB9DQo+PiArDQo+PiAgICAgICAgICAgcmV0ID0gaW9tbXVfYXNzaWduX2R0 X2RldmljZShkLCBkZXYpOw0KPj4gICANCj4+ICAgICAgICAgICBpZiAoIHJldCApDQo+IEhvdyBh cmUgRFQgYW5kIFBDSSBkaWZmZXJlbnQgaW4gdGhpcyByZWdhcmQ/DQpQbGVhc2UgZmluZCBleGFt cGxlcyBhYm92ZS4NCg0KQlIsDQoNCk9sZWtzaWkNCj4NCj4gSmFuDQo= From xen-devel-bounces@lists.xenproject.org Mon Jan 12 15:25:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 15:25:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200551.1516433 (Exim 4.92) (envelope-from ) id 1vfJmx-0007H9-62; Mon, 12 Jan 2026 15:25:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200551.1516433; Mon, 12 Jan 2026 15: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 1vfJmx-0007H2-2F; Mon, 12 Jan 2026 15:25:03 +0000 Received: by outflank-mailman (input) for mailman id 1200551; Mon, 12 Jan 2026 15: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 1vfJmv-0007Gw-Dv for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 15:25:01 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id db363500-efca-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 16:24:59 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-47d3ffa5f33so29549645e9.2 for ; Mon, 12 Jan 2026 07:24:59 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0dade5sm39519692f8f.9.2026.01.12.07.24.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 07:24:58 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: db363500-efca-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768231498; x=1768836298; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=itywUnXv8BR4nil1XxfuQoV9fIeZOLEdrI2V48Pa7xQ=; b=RJnGtUP07IyHEoMQIcUPj3GHganv6ALkPzWdcsRaCLz2nY/AoluxXE2ilxTx4Ewu3w JyCbPR4PsWcGUT823+16C3aoc16uhY1829S4DmOZiaMFGar2VyzWxLcbMd0B/1LbIZ7x hPwZtw3fwRyOZCiNwDUeP3pDKziicLrqiwHEyqHJU9LWvowcWC/sViNt7mFXYmTNQgtu ZiX/mIoXSKDGStozJ7GCJY0cnXDEIg7bHM3hDA6z55CgPqG8sORRYedosyA+uaTF770g taafJx+AV/T9FQuXGQPrQVyJr3ktXh8kaoVUlvStXVucqrC4OAJdCwRGzboPVbL0ngfR aUlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768231498; x=1768836298; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=itywUnXv8BR4nil1XxfuQoV9fIeZOLEdrI2V48Pa7xQ=; b=CNqbxOVhbZDMk2PlHpSiKi20DFk8JXuQndIBF8FgipkFRimooGz1GqqOxDEryG93eF Tt8PRcjgUP21c3brlfWqx2Ok0Jh1WcUjf4wthz+ZvmSfqv36N9bgaZCAjji+1wegdTNo 4Nr0+hEjDSO2qSX2K0Mhc1E+BIoYGfLaVPk0qv5wmBPrBSdcEkVTXPadeT9PCEGk6xRa OOXPY6qU0VAuF9AlniOUZrlTppcq2wWewG6HTw1O5K6EpHb3pVVqi9C6X54Fn53/dgaV bwlQQxFHlOw1tsvHjfY7ky8Z7PItzPSV7Mwk37kmeRzw6of/xy2WMPkCV/PyMDFrMd7U 1ePQ== X-Forwarded-Encrypted: i=1; AJvYcCXtXaESOaZLx/GwA8PecfSBYb5aP6693u23SInr6EKJh/2vN99ni1KDkJqc3OPuHcVwRYdXhfhNfXA=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx367yW8V/Vq8bci8SMJJK13u/mb3Ia5ekEKbF7zPllr276ju1d 7sDehrNftLLyHnA6Oc6vxqaTDcsRsz+7MdhmAkk+yAtcQFH3CJp/j1ntMkfYNSsgvg== X-Gm-Gg: AY/fxX4rqfhbZElc3VDJEzDbkIB7WtQznVMOKFlwkt6HCnmlyTzipVTmb2Tnhi9w6d3 hcMqxjRXjYis4nwmOKz1avLbunRrAitMEFyk+SDWZR96AZTw7GgHcIAIkEIA7vpu+LriaBG9wts ygfde0gTAvVCqVT9Yz28vQcIdQknk4kTiJPz0X7rXUTD4qGP3Zsk4KAPdHpnxaOcd6Z6zeKC+W6 OPGSf1fyVXDWw2Se2KwqVxV/QShE0Vb63GQBs8AG3qjb6DkMuS4mgJwIAnMlQhIaL/U3jCybt0+ CjQuyhaR9JF//T/SccvUZHNDaLe0PMK1b389rdS5tLRC0iL55FnpHyMAJapWBWMZjXs+HKQcRWk r+CsI/duDyv1r4Ei/QX4oYmQDBL338NMv3uqXkN1ugKOrS5LbfUEGbZOqzcb6c5HS41YY+pU136 rx0jckQPJFHcCxO0iBFX3AcxEJE1aCeJvRzvtmiIjmYal6Xoe+wwMORnMhNRMvsn1qHViLs2HOY NQ= X-Google-Smtp-Source: AGHT+IEhf5BG6GnZXHMF3REJmTWbESIuWeD69DTDCIvINSEckAQibqg/vwkt92i2DKyL0h1BKy41lw== X-Received: by 2002:a05:600c:4e86:b0:46f:b32e:5094 with SMTP id 5b1f17b1804b1-47d84b5b4fcmr198945715e9.32.1768231498412; Mon, 12 Jan 2026 07:24:58 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2026 16:24:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 13/15] xen/riscv: implement reprogram_timer() using SBI 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: <43249171def325c49541ebdac141fe99d159b60f.1766595589.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: <43249171def325c49541ebdac141fe99d159b60f.1766595589.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 24.12.2025 18:03, Oleksii Kurochko wrote: > @@ -39,6 +43,33 @@ static void __init preinit_dt_xen_time(void) > cpu_khz = rate / 1000; > } > > +int reprogram_timer(s_time_t timeout) > +{ > + uint64_t deadline, now; > + int rc; > + > + if ( timeout == 0 ) > + { > + /* Disable timers */ > + csr_clear(CSR_SIE, BIT(IRQ_S_TIMER, UL)); > + > + return 1; > + } > + > + deadline = ns_to_ticks(timeout) + boot_clock_cycles; > + now = get_cycles(); > + if ( deadline <= now ) > + return 0; > + > + /* Enable timer */ > + csr_set(CSR_SIE, BIT(IRQ_S_TIMER, UL)); Still learning RISC-V, so question for my understanding: Even if the timeout is short enough to expire before the one SIE bit will be set, the interrupt will still occur (effectively immediately)? (Else the bit may need setting first.) > + if ( (rc = sbi_set_timer(deadline)) ) > + panic("%s: timer wasn't set because: %d\n", __func__, rc); Hmm, if this function ends up being used from any guest accessible path (e.g. a hypercall), such panic()-ing better shouldn't be there. > + return 1; > +} Finally, before we get yet another instance of this de-fact boolean function: Wouldn't we better globally switch it to be properly "bool" first? Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 15:28:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 15:28:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200567.1516443 (Exim 4.92) (envelope-from ) id 1vfJqH-0007xu-MN; Mon, 12 Jan 2026 15:28:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200567.1516443; Mon, 12 Jan 2026 15: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 1vfJqH-0007xn-JC; Mon, 12 Jan 2026 15:28:29 +0000 Received: by outflank-mailman (input) for mailman id 1200567; Mon, 12 Jan 2026 15:28:27 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfJqF-0007xh-NX for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 15:28:27 +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 55314ff0-efcb-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 16:28:24 +0100 (CET) Received: from BN1PR13CA0029.namprd13.prod.outlook.com (2603:10b6:408:e2::34) by SA3PR12MB7877.namprd12.prod.outlook.com (2603:10b6:806:31b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Mon, 12 Jan 2026 15:28:16 +0000 Received: from BN2PEPF000044A0.namprd02.prod.outlook.com (2603:10b6:408:e2:cafe::6e) by BN1PR13CA0029.outlook.office365.com (2603:10b6:408:e2::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.4 via Frontend Transport; Mon, 12 Jan 2026 15:28:00 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN2PEPF000044A0.mail.protection.outlook.com (10.167.243.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Mon, 12 Jan 2026 15:28:16 +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, 12 Jan 2026 09:28:12 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 55314ff0-efcb-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=E4P9i1wOqEG8il/gVYLjCWqDP67bljK1JNf7gAzGDLDfdJAcjZUriI7z0/qdzLMOdSV9Jlgwkv8AqdEo1ZpdCnAc2ssmgd6T5sC4uDW68hLFAjdt0vgtZa0zM/fdRcwj2/XFIZJtb9iM4RCqI/olXTKUGETnwvf+2xt7iTm9X1dlIzAAD9pOi3Une9WmlXj4NQl8bp1P6Nlo7lk7+lYZOZ5GPIk87UAViIFOvgL3XnN8RmCWN5RMqMVs/VZHoQGLLsiZHeLnsqoIyaYewJwLtzGg7qyO/jT+gEnuHelJ6Bt3dUxZkj5VosRuMuP8iC3o7D5/pY+FtcOcKywx3skswA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=p5lPGmFvbpaE9gwdlvLa/CMdfRxAynaR5zdCd6X2C4E=; b=A2xusC+uzthIaK/iAoBltoO49PCQzsgmNXPsk3/EE87LK67LqO+vWjnSPAbTow9PXJsZ67hf4oFlJUKqKW7aGxtY1s14kwygrsWb6v8We6G1FYeydNYT0m7aiTO4p3dP+hIIpiJGNx3wFud9DCVF+S/1prPCCO1K1QfAebiFukpPb3+hb4GxMgmNjp4hDe/lrrZO7dI9A5VMp5O6wndO1PVe9e/Klg9HOxklyV527upjsx3YLZtPkH5eR0wzCE+kt24Xf9JUiTIF8Fhof8KFIdUYBofX/A2LeBW96vo8SaBU/hWkXmYCPEzad9f5qijf7Aoav5MGrjKvSXs8ooWfCA== 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=p5lPGmFvbpaE9gwdlvLa/CMdfRxAynaR5zdCd6X2C4E=; b=NRaUcworzxdTLZ0biw0BakrD9jSPFI9tCw/DCu4UFqHs0ldeW+zw5JxJoOuyTlEXW4Qa1KWViCs36Z+HuYos/qxG+tuh4nfZKvfa1UXVrZBhD+oBoOaawnLOgvUSZOnjf56ZEy0hThyh0+zE4bcnE3PC3IpgoSbrX1I++wvBmrE= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 12 Jan 2026 16:28:11 +0100 Message-ID: CC: =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Stefano Stabellini" , Subject: Re: [PATCH] x86: Add Kconfig option to use a 32bit TLB clock on debug From: Alejandro Vallejo To: Andrew Cooper , Jan Beulich X-Mailer: aerc 0.20.1 References: <20260112140851.55590-1-alejandro.garciavallejo@amd.com> <2a903c72-633d-4c91-938b-443628ac37cd@suse.com> <05372ffc-c1b6-4d65-a13b-cd28de6248b5@citrix.com> In-Reply-To: <05372ffc-c1b6-4d65-a13b-cd28de6248b5@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: BN2PEPF000044A0:EE_|SA3PR12MB7877:EE_ X-MS-Office365-Filtering-Correlation-Id: 7a07d463-a3d5-4751-b54e-08de51ef351b 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?Z1dYZ25tNVF4VTZ5TkJQdUpxMm96YTZENmtsa3BRNkRhU0w3TXJ5RjZqZWE4?= =?utf-8?B?cXRIMTcxd2FIempuZzN1ZEYrdGJETTR2Mk50YWhRNmlHZVQwYUVtVWl4NEt3?= =?utf-8?B?VzdxWTVRbFliVnV1SFJUN2pXdWlFL2RJbTBlQ2kvcDR2R3BzNldZYW5VTUE2?= =?utf-8?B?WUN0NlZXSVhLQ3I2dWx4NHVwMERDVDdDeG9vU0t5QWIvb0pZeko4NG1qNXZ0?= =?utf-8?B?Rmpwd2Q3bnVRNDRBdFpITzFLckdDdDhjUklKclNLV3dleFJFVWZaVXBZbHhW?= =?utf-8?B?RWtNa1V6ZWJ6L3NuTVBzZGJkWW1zT3NEeUVyNXh0cEkzNEJ5d0FIR3lHajls?= =?utf-8?B?VmtmTVFiT1JQRHdsNEZiMjNsQkhiTEt5ZTZlVTlkTjJyUnQvZWI0aWpHMXhr?= =?utf-8?B?N3NhNi9pNmxyRlVnYlhQZlVDcE45Ty9jaEpWRWZZYndSVGFlekZiTk1zZ3du?= =?utf-8?B?Z2FVMXRuOTlaSXFFRjJndDhaTWt1VXR5bHFUcG1LbmJOVEZqSFJURVdhYWRm?= =?utf-8?B?bm1wWkxrb0kxWlRVamEwMDhTNjE4S3daUU14Vnp5S2VrRlZUTGpwVDRVdTdz?= =?utf-8?B?MUhYelJNTEpKVCtoZVdVVTNTaUtYUTJaOG9WQUxKRXNqaUQ4NnA1TmpYZWgr?= =?utf-8?B?c0JXUFBUekNKd2FHUFNubkMyZXN4MytYUE8waGErN3ZYbmwveHJoYW9MUHda?= =?utf-8?B?d1Rta1d0ZVE5OEJXaEZ0c0krYnVOelFlQmFUSnhHZHZjRVRWM2o4UTZSdE1Q?= =?utf-8?B?OU9oQldRZHJzOEo3cFVNWFd4WGNJc1pnam93Umd5aFAyWE8rcjQxaS80c2pS?= =?utf-8?B?cGVkVDNxOTJNdFdtejUwTjkwTVZFYXRtYjRBQjYrTXdlQml5bE41akpTcU5N?= =?utf-8?B?MmY0dHd4SzRiVDM4OXdoOWVMcmxESkZWZWNBaUpsMGpBOUx3eFl5SWNLWDRI?= =?utf-8?B?N1gwZjZPb0FSNStrVDNhbHFYWEwvZW5rQmlWSDlBWC9VcWRMOEpweDdmMXo5?= =?utf-8?B?QzBGKzZZNDdKUGFBMnBTQjREanlFb2pkYWVTTktIUU9vUXhzc1pFSW0wRHJw?= =?utf-8?B?WVowZE9la0RaS2dVQnBQL2tlMVFMYjF5WDRlUUNERUE2MXY1bXl1NFp0OXFI?= =?utf-8?B?V2Y5QlFTdk9JdUc0ZjVOUUNoU3NHRGxtbDE3VlRNYjhVWnhWZUZNOHdMY2xV?= =?utf-8?B?RUlwTnpHUVlOck9ad0ttcWQ0dzY4RnBETVEwaCtTOGppckhZY3VlMkF3N1Rq?= =?utf-8?B?bnBsOExGWWl4djJZL3dXZXhZaDUvYlI4ZSt6Z3dPMjZJdHRMZzl3bk9pa01j?= =?utf-8?B?OFdJQ3BWbE56QVM5UVh3NkpTV2dEeHpBM2lHcmZuUnhXTTRxK1lZRitudHFM?= =?utf-8?B?TjMrR1QxUHhST01YZnU0U25BODRoeDJnMTQrV1R2QnJZdXNVUUY2U0FUYTI2?= =?utf-8?B?azBiTnhRWDhKV3JIOE1sdlBnRTZLZHRzNDdOUUxtaDVnSVVHZEtwY2JVVnEx?= =?utf-8?B?aFJvL3ZORWRtQUNSdUlmTEVVSkZ2NHpRbWhKS2FjdlNiUGRDYzZKTThmbXBL?= =?utf-8?B?Vk5pOFA2dGNGS3VtVmg5ZmpVaUtjTUtjTGRVSjA0YTgyT0ZyL2tkWmdXQ0N5?= =?utf-8?B?R2p5SHhoc2F4VmZwcHJlenVSZksxM0QwYkJtcjVGV0dTRlpCVE9HTTJPTVE0?= =?utf-8?B?bFZORDZQWTEyUmVVTGc1ckFCMStuVG81TjdFZWxDZytpcmdZeFIxRXhhaTZB?= =?utf-8?B?M3JsdmRwOHh0cmZSeTc2ZUJCSFdRTVpBZE9jQkZwRFgyeTVRamduWS8vajlG?= =?utf-8?B?UVJFekVFOFd4YkFFb1V4ZU13MzU4YmRXWXFXWThlTGtwK3VFYTlBdzlxRW9V?= =?utf-8?B?citySWt0RmZlQUR2WUFVMldpbWxaTU05TGhrSjZrN2ovUkgyWk5OZTZjQytL?= =?utf-8?B?aUtSWG5ROTV1RVhYVmswaG5yL2VqSFp1dlZHWGgzV0RQT1kxTWV6NXFIOWxm?= =?utf-8?B?UTFjWldJTHB5Z2l5Yno4aW11a01VMWVlaDdSWC9xWW9nQXFFeTdVc210UERB?= =?utf-8?B?dzJFOTNtL2VtdkZycVRSZ2Q5cEFjdi9iMXdqZWthNGV0WkZ5YU9Sd2lWNVVs?= =?utf-8?Q?tJaY=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2026 15:28:16.2803 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7a07d463-a3d5-4751-b54e-08de51ef351b X-MS-Exchange-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: BN2PEPF000044A0.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB7877 On Mon Jan 12, 2026 at 3:47 PM CET, Andrew Cooper wrote: > On 12/01/2026 2:43 pm, Jan Beulich wrote: >> On 12.01.2026 15:08, Alejandro Vallejo wrote: >>> Debug builds stress the wrapping logic of the TLB clock by narrowing it >>> down to 10 bits. This is inconvenient to test real time workloads on >>> such builds. >>> >>> Add Kconfig option to be able to selectively use the non-stressed >>> behaviour on debug. >>> >>> Signed-off-by: Alejandro Vallejo >> Hmm, yes, why not. However, ... >> >>> --- a/xen/arch/x86/flushtlb.c >>> +++ b/xen/arch/x86/flushtlb.c >>> @@ -20,11 +20,7 @@ >>> #include >>> =20 >>> /* Debug builds: Wrap frequently to stress-test the wrap logic. */ >>> -#ifdef NDEBUG >>> -#define WRAP_MASK (0xFFFFFFFFU) >>> -#else >>> -#define WRAP_MASK (0x000003FFU) >>> -#endif >>> +#define WRAP_MASK (IS_ENABLED(CONFIG_DEBUG_TLB_CLK) ? 0x3FFU : UINT32_= MAX) >> ... the comment then will want updating as well, I'd say. It doesn't go >> terribly stale this way, but at least slightly. I'd suggest to minimally >> drop "builds". I left the comment because the rationale still holds. Dropping "builds" sou= nds good to me. > > I'm suggest just dropping WRAP_MASK. > > We've done this locally in the XenServer patchqueue since 2011 or so due > to the overhead, and I don't think it's interesting enough to warrant a > separate option. > > ~Andrew I don't mind much either way. I need it gone for my needs and I don't care = much how it happens. Jan + Roger, do you have strong opinions on the matter? Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Mon Jan 12 15:41:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 15:41:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200581.1516452 (Exim 4.92) (envelope-from ) id 1vfK2I-0002jR-On; Mon, 12 Jan 2026 15:40:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200581.1516452; Mon, 12 Jan 2026 15:40:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfK2I-0002jK-Lp; Mon, 12 Jan 2026 15:40:54 +0000 Received: by outflank-mailman (input) for mailman id 1200581; Mon, 12 Jan 2026 15:40:53 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfK2H-0002jE-3t for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 15:40:53 +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 128992a1-efcd-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 16:40:50 +0100 (CET) Received: by mail-wm1-x344.google.com with SMTP id 5b1f17b1804b1-47d493a9b96so37835645e9.1 for ; Mon, 12 Jan 2026 07:40:50 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d8719d057sm131736625e9.16.2026.01.12.07.40.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 07:40:49 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 128992a1-efcd-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768232450; x=1768837250; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=i1Zly8kgHSY/soQCzgJnDNON8HOmCRWVbLSbq2T2iyE=; b=M9JqPa2KJtIWq+N8BOr0uRK/AShUP5W8ZJ0o/kbAym6bVngtDUAXbf+6GqZ+jkXvyR Db5cBUBD1K4h6aPdTbBFthxmN8hB81oTUtMFV8R0sxQ5WZR6iATXj4XmxJSDJnVeXiip rluHPnueiS3UjLPIGx9VZJdK3DSr8i7HLvquyYNQgViG6LGbT+6+ktGAslgojVSdPF6/ gFiUjpCbAnfeq6K8Se3VOrBcWjbbIZgrHz8wM3S1eKvrP/d4DpnGUi/Kqx+MGRoUHYoI 6c0C70p65sI61HFqpeHoWTBX5J2tHLYg9l/58hTYDSWPh6+JntD3liqCJEOjIn5istSu QbXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768232450; x=1768837250; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=i1Zly8kgHSY/soQCzgJnDNON8HOmCRWVbLSbq2T2iyE=; b=ii6Y4jx60e6JYXSKb1f0sDUUA1erHJ+yr3VMUo3km06dk1HzqTPKDBXUTI1K3eiXJQ bl+BogW//qzCmyMznFfwTwH4Or1lAdth238zgYJpxc9m4waVVZJFSe7YLr3VgMYzq7Hr yLsuVKpmJVq6VWJ9OlDfpIBhp518+iyPm6wRGxWL9PrBnnS1PBbZsakkfMe3AV7gz8TV EGEJvQq7t+ES0uUExdGySeql73EV+wsQTZdIIBUOFZthpvRomehDTaz+jF6f7NgPLGtE vmLsnDtIqUgPeKQ1+6E4XwEwf6XGy5cMBZF3lgWFX4T3ANzz0hE2ueDVnLvxpd8qS/YR 7njw== X-Forwarded-Encrypted: i=1; AJvYcCV/mfS8L5Hek7/reQdBDqHeewvtDNIhjrG5NS+h6YPjKWogspRdGcQ3EtSSYF4IQSajgnTzXp5HwG8=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy6pbLPjTJ9s4wmqFjI6zS7zZ6uAhwEZBZZjpVyqtM+8Wn8QeOh 3Ug2fXJ7RpSp6T9TO63N26rZhWPKm9/bnhE5LvfNJHOnzx8nBUZMT/iz+TdLsBHf5A== X-Gm-Gg: AY/fxX5Tetal7YsSGfmPVTkrQ2TDMWmWKCJHuLukLldba9kzYi7uEnMyg2wR2ntXOJF qaYqprbHWH8hm+0Zh5PQx2qSRz6UUkxUfEkPYnabKmXwmANhC1qK8wBwwKkW3oTdrRhjMlTT7Ca cMAamZLWdHMcIv78ZtMeHqqhW9obvXmmBrEa842GQ2g3dGBxYzO4qaEd4g/CVF2YmeLWizihp39 y6BWhbYTjsAI4VzMDHKA/tGjrUoxdrT3Ix2rrMyiTemOcE4GQdV+j+OPwdRdNMNy7+aOTlHGISi V/3vvmgKzd2P/wYQJLbtvIF0ggpFNstOPxXUS4hkiturdRncTIPVNtp3WLv3MGCOCPbriM1PUB9 UpDAEibRq987m/XUQRqDWckTVkz3uzGCikA7SWmyMF4bE92J5/21mAHKhEB9Jpi9DRliCXG+5Va noROe4psuF1pHirmoeonFg5JySkIgHJhcqFCczkOfFYb9yjXUt3N8TY6IbnDB57UZdTY77kPCZ9 Vc= X-Google-Smtp-Source: AGHT+IFSB8c8eJBEPp925v5gMKTjgV+sii12KtyoArjNywIfRXbH1a+hCKoLjanxPsGZs2f/46QVdA== X-Received: by 2002:a05:600c:8119:b0:477:7ae0:cd6e with SMTP id 5b1f17b1804b1-47d84b0afe1mr185896525e9.5.1768232450208; Mon, 12 Jan 2026 07:40:50 -0800 (PST) Message-ID: <98f5e8f0-070c-4be5-9baf-46278de8093d@suse.com> Date: Mon, 12 Jan 2026 16:40:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/5] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu To: Oleksii Moisieiev Cc: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" References: <9598b2e2-7df8-40c5-82cb-c097121af763@suse.com> <5d8f55a6-7182-4e9d-a139-96fddb9450f8@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: <5d8f55a6-7182-4e9d-a139-96fddb9450f8@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12.01.2026 16:16, Oleksii Moisieiev wrote: > On 06/11/2025 12:09, Jan Beulich wrote: >> On 01.11.2025 12:56, Oleksii Moisieiev wrote: >>> @@ -827,7 +828,32 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) >>> case XEN_DOMCTL_test_assign_device: >>> case XEN_DOMCTL_deassign_device: >>> case XEN_DOMCTL_get_device_group: >>> + int ret1; >>> + >>> + /* >>> + * Add chained handling of assigned DT devices to support >>> + * access-controller functionality through SCI framework, so >>> + * DT device assign request can be passed to FW for processing and >>> + * enabling VM access to requested device. >>> + * The access-controller DT device processing is chained before IOMMU >>> + * processing preserving return code and expected to be executed for >>> + * any DT device regardless if DT device is protected by IOMMU or >>> + * not (or IOMMU is disabled). >>> + */ >>> + ret1 = sci_do_domctl(op, d, u_domctl); >> Why would this not be the initializer of the new variable? (I also don't think >> that we've decided to permit variable declarations at other than the top of >> scopes or within e.g. a for() loop control construct.) >> > + >>> ret = iommu_do_domctl(op, d, u_domctl); >>> + if ( ret < 0 ) >>> + return ret; >> Why would you invoke both in all cases? If sci_do_domctl() handled the request, >> there isn't any point in also invoking iommu_do_domctl(), is there? Or else is >> there maybe some crucial aspect missing from the description (or not explicit >> enough there for a non-SCI person like me)? >> >> Also this doesn't look to fit the description saying "The SCI access-controller >> DT device processing is chained after IOMMU processing ..." >> > We call both because SCI and IOMMU cover different concerns and a DT > device may need > both: SCI for FW-mediated access control (power/clocks/reset) and IOMMU > for DMA isolation. > SCI returning success does not mean the IOMMU work is redundant. Can the comment then please be updated to properly call out this dual requirement? > - sci_do_domctl() returns -ENXIO when it has nothing to do (non-DT, no > mediator, mediator lacks assign hook). > That is the “not handled by SCI” sentinel; in that case the code > proceeds to IOMMU normally. > -  When sci_do_domctl() succeeds (0), the device may still require IOMMU > programming > (e.g., DT device has an iommus property). Skipping iommu_do_domctl() > would leave DMA isolation unprogrammed. > > The final if (ret1 != -ENXIO) ret = ret1; ensures that if both paths ran > and IOMMU succeeded, > an SCI failure is still reported to the caller. > > Device-tree examples to illustrate the dual roles: > 1. Access-controlled DT device (not necessarily IOMMU-protected): > > i2c3: i2c@e6508000 { >     compatible = "renesas,rcar-gen3-i2c"; >     reg = <0 0xe6508000 0 0x40>; >     power-domains = <&scmi_pd 5>;      // FW-managed power domain >     clocks = <&scmi_clk 12>; >     clock-names = "fck"; >     access-controllers = <&scmi_xen 0>; >     // no iommus property: SCI may need to authorize/power this device; > IOMMU has nothing to do > }; > > 2. IOMMU-protected DT device that still may need SCI mediation: > vpu: video@e6ef0000 { >     compatible = "renesas,rcar-vpu"; >     reg = <0 0xe6ef0000 0 0x10000>; >     iommus = <&ipmmu 0 0>;             // needs IOMMU mapping for DMA > isolation >     power-domains = <&scmi_pd 7>;      // FW-managed power/clock/reset >     clocks = <&scmi_clk 34>; >     access-controllers = <&scmi_xen 0>; >     clock-names = "vpu"; > }; >>> --- a/xen/drivers/passthrough/device_tree.c >>> +++ b/xen/drivers/passthrough/device_tree.c >>> @@ -379,6 +379,12 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d, >>> break; >>> } >>> >>> + if ( !dt_device_is_protected(dev) ) >>> + { >>> + ret = 0; >>> + break; >>> + } >>> + >>> ret = iommu_assign_dt_device(d, dev); >>> >>> if ( ret ) >> How are DT and PCI different in this regard? > Please find examples above. Sorry, but I can't spot anything PCI-ish in the examples above. Then again I also no longer recall why I compared with PCI here. Oh, perhaps because the PCI side isn't being modified at all. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 15:41:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 15:41:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200589.1516463 (Exim 4.92) (envelope-from ) id 1vfK38-0003CO-1w; Mon, 12 Jan 2026 15:41:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200589.1516463; Mon, 12 Jan 2026 15:41:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfK37-0003CH-Ud; Mon, 12 Jan 2026 15:41:45 +0000 Received: by outflank-mailman (input) for mailman id 1200589; Mon, 12 Jan 2026 15:41:44 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfK36-00039s-KE for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 15:41:44 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 32270971-efcd-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 16:41:43 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-477bf34f5f5so52488595e9.0 for ; Mon, 12 Jan 2026 07:41:43 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d86641e99sm131298275e9.7.2026.01.12.07.41.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 07:41:42 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 32270971-efcd-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768232503; x=1768837303; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=QlQXK7ZPTWsRSubVyxVhUCxXQJy1OtnO5JB1fpP30/M=; b=SCiS+ub+xYjF62kZK8FRoGU1AO5unc9EJZNmXOWCNTk+2VtUTMhP0EQMuE2rOxRZA/ 1zcO6bboeiiurgdDgE8dgkm5Tlg2e5VflpGmgUul9XJMJff0XkRZXtwrVny7alHbOWQQ IWnAG6vWQeO3ktG5w9rnDnIWTb04PTeX9U9mFp/1v9sQ/l+6ExLZdMCdTlQLuwdUxt2U vmalvkOx5icQSoETFumcJwBBZOIe5+DOcGVixa9uX0EN7Ni4n0MoTtBjL574UwNcbkMG cGi+aYXlxVGQTZjG5UpJSRdEAobjH7g2JpYZMJkIjQGoOJMvzSLAG3pJzKzjvhdAP5oq ns+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768232503; x=1768837303; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=QlQXK7ZPTWsRSubVyxVhUCxXQJy1OtnO5JB1fpP30/M=; b=K3VpwooD8AJkqbzMZpPY4/Nc/P34sBxtto50kIDmyJR21PG1czPMc0tQc3JDgIuKCP rGFMm5ushSNzXcmN2SMhRr0YnFalfJOOOixpnqy9KBgQjJYXk8QB6cAuMpBJnKRrNe70 eD5rcm5jEOVl6xeNy5eY9BxJJPYW3MUKrCLIFv553F08TxYGFixIAlYc3oS9fgriJrlO tSPtoLj6f4crEM1A2CEx0Jnu1rbyaor4KjpTRCYuK27X0snG5QY2JYXclPeJheCN5ywS 0M3/APueubnl4M7/psJaAilH0z8SKudzxudgVQ2DoF0ArgdgWSIQtQdyJ7BB1b7HYmih n2uQ== X-Forwarded-Encrypted: i=1; AJvYcCUORn2bYiNL6kE9kVCa5MgoKJml++HXpkX023ptWg27ukzU7f6vsLf6XU90oSC7M3Ws1kPtvOw1v+Y=@lists.xenproject.org X-Gm-Message-State: AOJu0YzFpVsByJSoHDPbrLvwZpYV1YLW2rt1KnAKwa/YaA4LNC0Yx/e5 sRw1b+9nGbEmTbYeU4fWnaCUgQwvEuzL7ZzXvZc50P3VARdB5zNUrAGx0678AUtVrg== X-Gm-Gg: AY/fxX5UyMtbCLq8pMveHnt5Bwd/3bYn4WGr38xXBIiDCdUiUx1BLwtVMteHZJUUnoO 1a2LXuq056yF6YMLhSbk/o3eKPjbqyJgJuPmwPrT9mvgOhoy06PkZm7ZRffm2Mbkw6/LeRRYgh7 DKxy/u9arujmNCyTEpP/e7+vKoTFMfR/E2jsg5Bv6fGEr64g52aTtkB0QFNOg1VRkRkEKF/6MLZ n+d95jFbRZ0i8Drf4WPIOh6pabeKRpFZcpJtjM91unZMMuPHjOsZUtaNiSquSx6DmQyJ+3MVL97 3fxpcUNf2Nq2aWOrhBta6UgrBt3xSwTkR/uB/BwKH7bUQZZhldJZJtxJhVoRp/CTYQocIbKCvM6 Kl65kIaLT0T9oOmCc3wXyFHcCbewkDgBEMMGyJC0Z+JDW3IF39bDCL+IKLP5P0ldWF04pZkpjns pF/kD0O530QoiRazpZpHBI2RDdX8dmVM/PKgll542ZXlT/EjrVN+Mp5voz6jsLZGXtvTCob4559 KQ= X-Google-Smtp-Source: AGHT+IEi/0pymrjGPzXTXmODoEX3mx0zkjDXjpGbFwdvm0aYiXly7HSy7rUrp4gn69vZtuEsVZQTEw== X-Received: by 2002:a05:600c:c8a:b0:477:af8d:203a with SMTP id 5b1f17b1804b1-47d84b41b69mr204804215e9.27.1768232503203; Mon, 12 Jan 2026 07:41:43 -0800 (PST) Message-ID: <4f206c26-bc70-4435-81ff-a8c035cef398@suse.com> Date: Mon, 12 Jan 2026 16:41:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86: Add Kconfig option to use a 32bit TLB clock on debug To: Alejandro Vallejo Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org, Andrew Cooper References: <20260112140851.55590-1-alejandro.garciavallejo@amd.com> <2a903c72-633d-4c91-938b-443628ac37cd@suse.com> <05372ffc-c1b6-4d65-a13b-cd28de6248b5@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12.01.2026 16:28, Alejandro Vallejo wrote: > On Mon Jan 12, 2026 at 3:47 PM CET, Andrew Cooper wrote: >> On 12/01/2026 2:43 pm, Jan Beulich wrote: >>> On 12.01.2026 15:08, Alejandro Vallejo wrote: >>>> Debug builds stress the wrapping logic of the TLB clock by narrowing it >>>> down to 10 bits. This is inconvenient to test real time workloads on >>>> such builds. >>>> >>>> Add Kconfig option to be able to selectively use the non-stressed >>>> behaviour on debug. >>>> >>>> Signed-off-by: Alejandro Vallejo >>> Hmm, yes, why not. However, ... >>> >>>> --- a/xen/arch/x86/flushtlb.c >>>> +++ b/xen/arch/x86/flushtlb.c >>>> @@ -20,11 +20,7 @@ >>>> #include >>>> >>>> /* Debug builds: Wrap frequently to stress-test the wrap logic. */ >>>> -#ifdef NDEBUG >>>> -#define WRAP_MASK (0xFFFFFFFFU) >>>> -#else >>>> -#define WRAP_MASK (0x000003FFU) >>>> -#endif >>>> +#define WRAP_MASK (IS_ENABLED(CONFIG_DEBUG_TLB_CLK) ? 0x3FFU : UINT32_MAX) >>> ... the comment then will want updating as well, I'd say. It doesn't go >>> terribly stale this way, but at least slightly. I'd suggest to minimally >>> drop "builds". > > I left the comment because the rationale still holds. Dropping "builds" sounds > good to me. > >> >> I'm suggest just dropping WRAP_MASK. >> >> We've done this locally in the XenServer patchqueue since 2011 or so due >> to the overhead, and I don't think it's interesting enough to warrant a >> separate option. >> >> ~Andrew > > I don't mind much either way. I need it gone for my needs and I don't care much > how it happens. > > Jan + Roger, do you have strong opinions on the matter? Dropping altogether is fine with me. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 15:44:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 15:44:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200604.1516473 (Exim 4.92) (envelope-from ) id 1vfK5W-0003qX-Fg; Mon, 12 Jan 2026 15:44:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200604.1516473; Mon, 12 Jan 2026 15:44: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 1vfK5W-0003qQ-CV; Mon, 12 Jan 2026 15:44:14 +0000 Received: by outflank-mailman (input) for mailman id 1200604; Mon, 12 Jan 2026 15: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 1vfK5V-0003qK-IL for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 15:44:13 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 89fa4b77-efcd-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 16:44:12 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by LV5PR03MB8458.namprd03.prod.outlook.com (2603:10b6:408:360::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Mon, 12 Jan 2026 15:44:08 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.005; Mon, 12 Jan 2026 15:44: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: 89fa4b77-efcd-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UM+gAmZFXeXrtw7GX3QObwoZ0o2fzWW3wDVYJMXMVw4oRKbDsxry+u4UwjkIoQqbNl3PK7nZe2Ebz6jaTAqWiCqZsG1ec9hJ4542q84pCZEnc2OCSce81T1E4HabEf5htOarIIf0QCvXHOlnVGBRS7MZRBFexEhywf1JNvkt5pMtJ/sfG+eqd8/3Y9eUy3dCv3WWdQK+YwIjJ+gVRYGnvSkcvoffzIIHXUc0+Gm5NwpWdHaP+RkiA2AM3j+QUac8aEHkYLhAQJJ0Uo92d2/A2hg3qqBxTsJtTiXRrHP9+RpmpM88QZv3680EhsZ7+fId9mSvN2IvZuoUirJdXJs3Lg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HyoWAi6eInynUxeCQCkvdupEhitQPHlm6s9xJHkS6Cs=; b=SUyk5+HKFi+mjMzjDikE5d9wOoOWw9K65hizWcULx2JhYFMxMuFZBvM1VEWH/ccSVdXSRd1aj16MSwD0Z9kfeVCM4YD6+wxlfCCet++egh0sLGCcbh9IOBFLyQX7OwKSHPeym63BqwaQo+eb2b/ValMtAY1NIWVxSSKtKcE897uPHXcH7NT/LXhugR3bgATn78+SE8xYehXofzWw9nVe+LOVXJT6iOsG4t6oPFxI69lNFq7ugLgtyfPO5qu8DJnJKsyIg8F7psRyDH4tL/7pvC4E4o42jKWImM4YShV95R8nV4MgUCPUDB7I/Ft5p8wtxBLN0eod3HqOCuDcm3YdCQ== 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=HyoWAi6eInynUxeCQCkvdupEhitQPHlm6s9xJHkS6Cs=; b=Qeirf+glgtM0w4jdATEeTHP0EgLpZ7Z0Ot/xIGazKGxNheMM0+/AAFL68BBZPAUHECZVse7b9oJtFvvPUrocb75mEQzEV4In16jAmlEWXRuBnGJHz6GKKHa1V1DDE/n0o75IOrSrjrpiZksdY9B9u8QA2+FAe4cgxoY5M31Z04g= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <0770d48c-ba38-4480-ae96-a16de8cc9bf1@citrix.com> Date: Mon, 12 Jan 2026 15:44:05 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH v2 1/2] x86/ucode: Fix typo s/mitigiated/mitigated/ To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260112150259.74535-1-alejandro.garciavallejo@amd.com> <20260112150259.74535-2-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260112150259.74535-2-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0637.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:296::14) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|LV5PR03MB8458:EE_ X-MS-Office365-Filtering-Correlation-Id: 682ebf30-6c1f-42f3-e8f2-08de51f16cbe 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?YWhWOW1kS1NHZzZiK21oTS9BQ2hrSXVJYUxXOXpKMU5lNVArWmIzdzY2TlVL?= =?utf-8?B?K3gzOTZlUkFsSGt5NGk4UXAwNnowV0tjN0diMTBUNW5VMkJwNUd2cEZJVHJ5?= =?utf-8?B?blV3ZHFabmtxMlNpMHJ6dGRhNjd3ZVhWTDF2UjVQTDRTL0d1Skk3UkxGZUpH?= =?utf-8?B?UDduZ1prVHpvVko0ZGM4NmpMVE9uTUVsRmVIaUVzQ1ZyOTBBWmhxUjI4TzNU?= =?utf-8?B?bktVMXl1NUJ3Y1N5QXlHcHl3a2MxdkU1cXkwSjZrTVpuR1d1dHg3MEY2Kzhi?= =?utf-8?B?cXNLaFB1cW40T29zOSs0cHdRUUd5U254YzU4UEp1Z1lUdjF0eXVlVHhHMXdu?= =?utf-8?B?bDI2bk9paVBqRFdkVVFUMEhvNTdhZGZkN0lGU0V3SC9EQ0V5ZWFjRFFUZVp0?= =?utf-8?B?NTkwclE2MFZnZnpmYXp0VTIvMjZPSlZEUFVlVTQveVltSTFLcHVHQ0VIMWgr?= =?utf-8?B?Q0NIVGVncm1uT09mMEUycnNPQXZKOW44ODVTbnk5TGIwY2NBek5SVyttTTRv?= =?utf-8?B?eVNicDhMc1VUem5WeWVrbGhteHRXekJZa2VRLzNyZkxvRkthaW1GeU5ndmxK?= =?utf-8?B?VXBEeS9sTUNzSEM5UzFnSzBvb0F4MWliZUU4azJaYWhld3RoREJZK2w1YUZD?= =?utf-8?B?TnZFSDBIZmtjQnJLaDFMQ09BMFpRa0d4TXFFR1ZIZVQyTnpvUkduNlFNWTlh?= =?utf-8?B?dTRUL0RyNFI0WXhxR2NtdWVIWnUyVXlzdGlVSURtMUsyTzJ6M2pjVzgvcE1C?= =?utf-8?B?cHNzWXJ0Y1BNMElnUWRuRzVsRGg0VjlPdkJUMTg2M081NUJ0RXNsZkpNdlJD?= =?utf-8?B?anFNSHlUamFCQldJWGJHTkJabEpGazRXaG5Va2FMWnBlbGdWYy83QjNudkEw?= =?utf-8?B?azYzaGF6ak42WG8rWGNFQmF0ZUVlWjFoYVpYbnkzOU56Sm9KSjFXUHZnM09p?= =?utf-8?B?TUw5V09RNjVjTU80UURSeFpnNEl0RHRiTnFWQWdOSEpEWnhiWVZheFpuakFz?= =?utf-8?B?Tmlqb3RoMHdIRjRJQUorVTVYTk9UbVlPRTlaeGhyOTFkbnY1ZVk1L2hESHRl?= =?utf-8?B?OGNwRDFNWFhacUNlMk9NMnM1TFdoZmViUHhjMHZXaWQ2b3g0RHpQaC9SOWZl?= =?utf-8?B?cWU4K05SNmhuQ2FSUXo4c0F3ekpUbW9kMGFONlpUUkhJLzBZYy8rakxkWmtv?= =?utf-8?B?cXBFOHp2VGpvNXdhMHRubnFUcWdPZTBGNXlYTWRDbnQyaVZQd1dsK2cxY1Rx?= =?utf-8?B?RTV6VmdqWml0RHM4Y1ZhSHRNeGczaDRFdDEzakw2U3hydUZSQ2FyU1ZMeFRI?= =?utf-8?B?STBTRHZjWVpXd1p2bUpWamJuOHN3M0NzWTNXbnZiUVU4b3ZHRnJVTlc3VURs?= =?utf-8?B?azR4YnZzL0hYc25HaFRlN2paM3g0N2ZJR0hBa0tkRFhMUWVxdmtoeDVPWlgw?= =?utf-8?B?Vy9mVFhOS1ZlRXUvSFA0dk52SU0zTnZ4TUY3cUlhSml0MVVuMGJ2aUVNTjlR?= =?utf-8?B?akpDeGJqbUw0eFBBVm93ak1OT09wbDJmR0FaSzdRSkN2alBBV05jT2FYV0Zp?= =?utf-8?B?QnR2Zk1pZGRzUnJKVm13QjNqbzZRRThzQ0RLdEE3bVZTYlNyaUM1WjJWSTFk?= =?utf-8?B?MjZRUzQ4ajdYeWFCM0tUTit1ait4S1JZcTRPS1B0aDZpMUE0WWp0ZGZheWlF?= =?utf-8?B?ZVErOVB1a3dQZVpxc0wvVm5DMzZONWVUeFdsWnNteHpzWHp6VHczU053UWlj?= =?utf-8?B?MzBmdHNabk1pT2c4UEw2NmtRbmtLN213OVhYamJYcTRDR0FuZ0FqNUpKbWpl?= =?utf-8?B?aDVMbUxOUE5zOExGZUQ4QnZkOENncjdRd3ZDNHNiYTQ2a2t3NXlCalIwZWhB?= =?utf-8?B?bEtvb1N3c3VnaGtMOG1ybnE5TVFudGF0M3VwM0hQUE1ndEowQjBGMVZRa2pT?= =?utf-8?Q?k4H3ynt2bKyClzuxo+DIAOT9UODwm6Ay?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SzhzSDloakgvVUUxZlloa012Mk5nekFHaTVOaTEwMmQxeGVST3ZBN2o2Z29N?= =?utf-8?B?WWRWcHFwaEhITWpETU9QRUFlUk1Nb3JVemZtUDI1VmZhaFAxNVVYZGdLKzVn?= =?utf-8?B?aHUwdzZnd2RFMDc3TzZvMTN2L1JHLzRrSUViRE85eGFCL2gxa2IwZnVXc290?= =?utf-8?B?OUlhbzFqYlFURDV1TmdWOExxWXJnalRrcTNWV0p4WVpJajdORzFqZzBnZ3Bw?= =?utf-8?B?NVJickRTSW9kZjJ3TDAxZFBSZ2VtckF3U1R6SG45dUREVm5UekkyMlBlOEtQ?= =?utf-8?B?bjBNdVpYU0IxREdNejFQdXpIQkIyNDY5anlMaXd5T0VIanJ1bnpHQk5ibUJi?= =?utf-8?B?L3pCM0hBZldUT2xITTFZSlNVallaOEFLWWFuZk8rUFBTNTVydGhSLzZNanBC?= =?utf-8?B?cTZ5R2JsdS9pOFVKQ09iMUdJR1VWd2M4N2dUK2NTd2QwdnBhKzlVNVl4bjNT?= =?utf-8?B?SEg5REMzdkNPSWRPWm41cExvVmU5ZGtwNDYrWWtoTFp0L25aSXgyTUlISjJR?= =?utf-8?B?TEk4QjVqOFhLVmR0aVQwV2FEc05VZElja1M2VUtiQ0ludnJtYkVNazBxRTAv?= =?utf-8?B?ZHhObndqd0oyZmh6Ny9GWFd4MnhnVHFPQmdLMnJGUFpRSFVtWGsvVTlPTE95?= =?utf-8?B?Q1ovUU1tUm8va21xOFdLN1dtOVFxdVUyTUgwMkxXNkx5UlNCcU8yalJFZGxL?= =?utf-8?B?QkQ4Y3ZqNm1xdkUyRGhRdGRKMFRtLzVjWHlFZG5PTDhzWVNvQm9nK3k4dWwr?= =?utf-8?B?dnZ6RytxU1NnSkZPTVRUMVZuYWRBdnJlRUIwbXc3MkxNSGd5Y0VmSDRNUnVU?= =?utf-8?B?S1RJaWxHWkdDazI4c2NHQUpWbjVrSTBIZjN0MVN1azdCb01WTGtqclN3RDhV?= =?utf-8?B?NS9wS0tYY2tDdEp2b2RBQnVCYVJqMDR4dGttWVZjUFl1ZndPTkZDcUxxZUdo?= =?utf-8?B?Nm9LTnFKK0szK053UmM2QTk4dThtTEE5aGVJbUpiQ3hBMThGazJrNWtiT0x5?= =?utf-8?B?U3lGbnRKS0JvV1V0K2xYQUFDcGV1REdRZndpTEZDcGw1M3dYWmlNTC82dU1X?= =?utf-8?B?UTFNeGoxdUR3UWV2OVBzU2F3ZDhqcHZjRDhKM3JSYmpLRHY0NmkrSUcwVUsz?= =?utf-8?B?blpJVlFEd1NpczQzNjI1TW5iU1ZrcXRJTXRxaGZZcTZyQmRsZGVZZjIwZXB1?= =?utf-8?B?MzM4MFRkdVBwaERTV3JTVVVkK3R2Rm9nM21RYWxlMk1wR0tYSzFydCtGZmpH?= =?utf-8?B?R3Y3NktjMVhoOFd0eFY0SUp2TmNKTTdDTm54b3dHZ2xWSE1Udm4xdXREQUF4?= =?utf-8?B?d2o3Z21mcW5lczFBSVNVM2Fjekp4RHhuWExXanV1SFBxWG5rSjg4TjFjWTU4?= =?utf-8?B?MFdFWmI3L2h6OFFXMGcwcm80MjExa2EvNXVVL1Z0VXVHeWp5Z2REdjN5ZGVa?= =?utf-8?B?S1UzL0VJYVJzandkaTdkWTYwV3RCUmFDTzdqOGxrYlF4R3d6Yy90cjEyWFVt?= =?utf-8?B?bm5YZ0J4YktjWDU0ZDFEek4vN2xseW1Xb3pIL3ZkaHNVQ3lYem5XZFJVYzV5?= =?utf-8?B?M0Zvcm9DSTFvbnFzRklDditBbDJNTldBbGYrVXZocS82dFp0aXpBeW1RY1ZH?= =?utf-8?B?cVRXMk8wZUNiUUdsdnR1VzBkZG0vSmxJdUtGUkF3UUN1M2c1RlVxRzlSQlVO?= =?utf-8?B?bXdYaCtPRGU0TzVtb0RXeGs1NTNmTjdlOExmdUcrUEQ4Uk1yNy9QK3o0bnIz?= =?utf-8?B?em91Y29HQnNUWUV2OG43N012MjdTM3h1RG1ZVjdHMjBSSndRMWtLZnIzNmFK?= =?utf-8?B?U3JCamZyby9RTzRuUUFVUUJQbGNCVGhmaExIYm83VUdNQUF1YmZOVyswQzJu?= =?utf-8?B?REdtaThuRXUrdTRkQXRkeTlKdHY2WVFiWjJrV3NKS0picnQ1MVBqdHp4SXVu?= =?utf-8?B?dG5JUGlsQU5waTB3ZEZPUlYvY2U4NHRYc2lqb2VuWm5ubkV5SzIvalcvcVVz?= =?utf-8?B?dytzSEYvVXdoWlpCbUlrcGtGMExJamZPWjE2aHFaMGlsUU5aMDNIbDMxajVF?= =?utf-8?B?K25Ib0tJOEdnWHJUejNVOGYwbDBPL1Y5QnNoVElXVUtjZEx0WmIwSzd5dFA4?= =?utf-8?B?N1YyaGY4Mi9mRkhXa05ZUXAxZkV3RUVjbXAzdFBES2FMK3hvd29MQ29pZENz?= =?utf-8?B?QWpHNjIrNmxndzV0NEhFaHo1VWc1YXVvaXJYOFRQRUNiZ0s5NW90eVRwZWtH?= =?utf-8?B?QTVNUTc2V2tscVVUS2dZUUpDK2Uvb3ZyaTYxdVJPbHNwQ3FnendIcEdNaTlG?= =?utf-8?B?dEhzeUFkOGZRQ1ROMXFRUGw1ekZSRFdzWG0xV1QrZThmUXplanVZQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 682ebf30-6c1f-42f3-e8f2-08de51f16cbe X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2026 15:44:08.7375 (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: QPuUTL17QkZsK26+6fMQ0r3ER39QlS/QUf5N1rEA1yqiEn7zNLD175nLJGdS/B93q87oLChuVlsi4Ek5uwkIBv0CNi52zfbVPaz13NSVbT4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV5PR03MB8458 On 12/01/2026 3:02 pm, Alejandro Vallejo wrote: > Not a functional change. > > Signed-off-by: Alejandro Vallejo Oops.  Clearly my fault... Reviewed-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Mon Jan 12 15:46:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 15:46:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200617.1516483 (Exim 4.92) (envelope-from ) id 1vfK7R-0004N0-T0; Mon, 12 Jan 2026 15:46:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200617.1516483; Mon, 12 Jan 2026 15:46: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 1vfK7R-0004Mt-Q5; Mon, 12 Jan 2026 15:46:13 +0000 Received: by outflank-mailman (input) for mailman id 1200617; Mon, 12 Jan 2026 15:46: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 1vfK7Q-0004Mm-5Y for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 15:46:12 +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 d1472330-efcd-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 16:46:10 +0100 (CET) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-6505d141d02so10526435a12.3 for ; Mon, 12 Jan 2026 07:46:10 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8701e1d467sm599212066b.70.2026.01.12.07.46.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 07:46:09 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d1472330-efcd-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768232770; x=1768837570; 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=ikEEWpfdYkg+GHrVMJZ0H5ltKeP8OLweL9QsXVCaoDs=; b=m5aTI7sJYGMLq4l0v9Ejlu+EWLuMM2VS4+S5UnI2ObGkmr4XZkmpDJFSn32BghchqO ZknSJft8nmjQmmHFrch+LXCdao48sjRo4lRA9ZZEUFK9EmJQ9qaPXa6SDOhxhRzasbyJ 2WtbfYJp75I5hv9slVo0fiOgdP2XX5PkaNb3NvwWXDNVfPCBJto3WxL+dd/zQLYQrH4f 4PBRvcd/wEP42aKdqoEcAPUVNDRdqz4H6lPgxTRjTsnENw1lf2XizIj152azWl21yXoM SH2M3ooLhuWROFfU5pGEReMtYE+nHFULRoH17ueXownDKlOC1EjLQ7t5io3FwJpozIWg bUsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768232770; x=1768837570; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ikEEWpfdYkg+GHrVMJZ0H5ltKeP8OLweL9QsXVCaoDs=; b=uFjvjU0/e0/9PSuY6Ekh/uiDog7KUgnpAGIQjg2bG5ruVUHlcVOBstIssURSTS+SFt /Yz8K5trUTcKwkws4I/oXN1XSkJdJ2r+3smWrGC8VrF8G+P71maFDrgOGaV5RBWJZTny Sr4oCgQQBNy5OIwgjLhPvhmZ4QkCFIo7MHgN5PUWysNE430xaj3/jj5luLmL30S8gdEC e6pRE9V4hOVTqK8WIfCzhDvpDyBiBjQkxNGsLFyNUEvbhjfuyOetYYWZhjCpCvdePYj5 vLlTplxmOUAyKdAIRSLs+pOvB1jpk7KnqLRNuj7g0UFcQTeTwmwFq4Kmq3rFkQI2PS1h Z/DA== X-Forwarded-Encrypted: i=1; AJvYcCXddYSzJZCLX+eTJWNSTpMJd4igd2YIa2Btbn3XijBKjNfjWlviz7vg5j2nHI2Q6lXO4/lUSMOAtPI=@lists.xenproject.org X-Gm-Message-State: AOJu0YwM5sB3XI4/we1K3qpgXnKBSqWJzoU+HObwIWdKsC3Xrg5YJr9z 4PUT2tjNKmI2Ku2cN8I4cwixj+vPppQ/C4WOANcCKaxUbJR/vFAn+4QP X-Gm-Gg: AY/fxX6hXh5kunvSar3ss+D7BtNEqC3WK1QM4av+ZN0NcnT+8gkter4ozBCXIOOyUkW kT6bjS0TlJfBf0PManzm+F3+xvnENGxlADj4E7Pd+hWHtMD5e9tw1cgHXOZZgB9MMuJRT4ywbkt S0aFn3cVjf8pLOe1Gq5o7ihQSaoy9VBbrARWodFpRQaDZcWXJHB/VEu3GzfhJ9ijf/0+khtNii8 BXQwuoKZ/2CPmVE/JgGCAXv1k1MCoDQz/0wgqTwr372m5rlEaBqP0/0cGuzGyUMrU+nl7ZRf7vs 2HvhX5MKDCD7uZX13Xrv9ysbU2/LOqgx02ecfCQ5ngiC23LhWd0Y/AOXWOl/tDDe14zhKrjs6iq vk6FE4cM9HWxHMDLdbaFowT7CosOgVUNywLsCx57iClPjyR0eGYqO2rSf7bVU0ENYPaktxg9YGa AaXatjb+BEpKXTYAiaLXXnZmEtrdQS/KFkU50X5nPew/WHrl3rjM7swGmxb4l6fj0= X-Google-Smtp-Source: AGHT+IFlPxsMhO4uxy4cfaJlR6l6ZRYJlp94VG4eZlAASC2wRDVSMJsH3wWUMgI0XYBttQ4HtgFiEg== X-Received: by 2002:a17:906:fe42:b0:b72:a899:169f with SMTP id a640c23a62f3a-b8444c3fad9mr1941439666b.4.1768232769967; Mon, 12 Jan 2026 07:46:09 -0800 (PST) Message-ID: <988ba581-5503-45d4-a621-18cdc3b14cab@gmail.com> Date: Mon, 12 Jan 2026 16:46:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 03/15] xen/riscv: implement vcpu_csr_init() 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: <7ba4bcfe-59d3-43f3-adb4-207424dc1713@gmail.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 1/12/26 3:28 PM, Jan Beulich wrote: > On 12.01.2026 13:59, Oleksii Kurochko wrote: >> On 1/7/26 9:46 AM, Jan Beulich wrote: >>> Also, wouldn't you better keep internal state in line with what hardware >>> actually supports? CSRIND may be read-only-zero in the real register, in >>> which case having the bit set in the "cached" copy can be misleading. >> [...] >> >>> (This may similarly apply to at least hedeleg and hideleg, btw.) >> Regarding the previous bits, I can understand that it would be an issue: >> if SSAIA isn’t supported, then it is incorrect to update the corresponding >> bits of|hstateen0|. >> >> However, I’m not really sure I understand what the issue is with|h{i,e}deleg|. >> All writable bits there don’t depend on hardware support. Am I missing something? > My reading of the doc was that any of the bits can be r/o 0, with - yes - > no dependencies on particular extensions. Just to be sure that I get your idea correctly. Based on the priv. spec: Each bit of hedeleg shall be either writable or read-only zero. Many bits of hedeleg are required specifically to be writable or zero, as enumerated in Table 29. Now let’s take hedeleg.bit1, which is marked as writable according to Table 29. Your point is that even though hedeleg.bit1 is defined as writable, it could still be read-only zero, right? In general, I agree with that. It is possible that M-mode software decides, for some reason (for example, because the implementation does not support delegation of bit1 to a lower mode), not to delegate medeleg.bit1 to HS-mode. In that case, hedeleg.bit1 would always be read-only zero. > In which case you'd need to do > the delegation in software. For which it might be helpful to know what > the two registers are actually set to in hardware (i.e. the cached values > wanting to match the real ones). Does it make sense then to have the following ... v->arch.hedeleg = hedeleg; vcpu->arch.hedeleg = csr_read(CSR_HEDELEG); in arch_vcpu_create()? Or I can just add the comment that it will be sync-ed with the corresponding hardware CSR later as ,actually, there is some h{i,e}deleg synchronization happening during context_switch() (this code is at the moment in downstream), because restore_csr_regs() is executed and re-reads CSR_H{I,E}DELEG: static void restore_csr_regs(struct vcpu *vcpu) { csr_write(CSR_HEDELEG, vcpu->arch.hedeleg); csr_write(CSR_HIDELEG, vcpu->arch.hideleg); ... As a result, vcpu->arch.h{I,E}deleg is kept in sync with the corresponding hardware CSR. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Jan 12 15:54:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 15:54:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200629.1516493 (Exim 4.92) (envelope-from ) id 1vfKFB-0006In-K6; Mon, 12 Jan 2026 15:54:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200629.1516493; Mon, 12 Jan 2026 15:54:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfKFB-0006Ig-HF; Mon, 12 Jan 2026 15:54:13 +0000 Received: by outflank-mailman (input) for mailman id 1200629; Mon, 12 Jan 2026 15:54:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfKFA-0006IZ-1g for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 15:54:12 +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 ef1b6b91-efce-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 16:54:10 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-477ba2c1ca2so72210835e9.2 for ; Mon, 12 Jan 2026 07:54:10 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432d286cdecsm25599921f8f.7.2026.01.12.07.54.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 07:54:09 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ef1b6b91-efce-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768233250; x=1768838050; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=OI2oT5If4p3Fzj5mygStk/l4C9+d9IsfmYyxvoHmGNw=; b=bLBlvFJjU6dcQ3FK8gsok0HYFQorGZe0QU8YqeNEOka5DhsO9LUoE181FH5zimXcIA drNSLfjvDJ2YqRUaF6XziLofcfu2DOejVGJ/8wZ+0OBGLmMcTlMFws1urowRdyv5SUQn LQsTY3Av9TD1D3qMsrgLIcA+GMfcxUhn9h4CiyquYnldmfLD5sLo2GHsxnMGFxMam+eL KtpulA2bSTUyzVvzO1bFtkLneEwuXo4xfs3Pb1BFGu7fcwH9yuQ0HxhEoqt5/gRQJLP3 eh0IOnlxq2aep8HataUMV0gx09Ny4otG04+rUl3z4QmtUH4VfBv6lWZ+eOPnslP+BSrN xRHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768233250; x=1768838050; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=OI2oT5If4p3Fzj5mygStk/l4C9+d9IsfmYyxvoHmGNw=; b=Dn0PsWQ8qnm7uTL64LBa7lttZcQAlv2tkeFhWJvT8RhijUeuy4eAOGGW8vrYsMiuIC s3HLoV52YttArxTbk3e16WIrtEGby871x9COvCVJRucpNJ/Ana4Bu/d66Jyl0lZFS+MH oS5jjp+olXMy59huvQukEABu5sUZ+VvEcq4vQU9B7qNZCxz3DhVw3ec+pZke5RPEbg/j lJi4WhGlZFWCktANxKylpxGY+lsHa1FhoLnTMexRKHck9mIyWSUjTxfb5+O02gx9/FQ4 2taHz+JLCXSw+kG3v08U+NSK4CmQeBDhoNClpxRbSfSt+KB+DBGvgO+J4O3SG8rU4gWy azHw== X-Forwarded-Encrypted: i=1; AJvYcCU7DUOF59U0/qvh2nGEyREpMxPybeX/v7MmGlNAwX9qOASQD0zkFZPD8M/w20A6eQkV817EiAyZIHQ=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxqeg8r5Yn2M7iRsQKu8GSs5yPYk+BOnn1EiF9x3BSsBxvZNpAF m9116mTiXGX8xNRzUkmHpayWpDM5FsqbskjT7XtTRrqyt0o7vzvr6tBXmLLc6rtCEA== X-Gm-Gg: AY/fxX5eVK34w1JGI00KsfQom0cR1k/CQBK0z5y2VUdkaBGlq5PmWgf6ujMqG10pT5A O+TxdoVu1+ANgviPRzmT9MzNlsVdrXZHCLaxkMbZBVHaTFeJ+9OkCdIcGQwHhyFc525Tx55sUfX XXLoOrRFoB4fcDSwftX4d9PfRw2meGgagS5q/YS1VkkadCHwI3EviBLxuyK4urCQaq5a7etB7/F m2wak6ue+B6LMYCfvFGH1PqRHqdsaYX7GJWIorPVaIBG4CrXCxSlIijXsNFekr5nq6UBno8a1vn CsrPnHyA2s7uug5vfY56+I56LITy5dwY/Lif3BdF4svJi10qDUyTGbOL3lKmnPjtWbQp0zYjZ+p Xl9wuK5NewwBjQ9UfmZ4SCOI+L8ihaf3FN00KrOpLXRTojoZteGke3DIxProQMCm2ryCMrA3XsU uAM4Lk0HmH9aeOsgw4myV13ShpXSm8Z/mOJzbsPwuOs4uQ3d699A+8ZeBGtMgzq16S9NqtXgzfT Ic= X-Google-Smtp-Source: AGHT+IHXzMZAx2KYU922PSm7rsAkuOAnOO+mOurxfNz9YH6YXM3rP5FVQxBzWPx+d/eeNtRC//wJxw== X-Received: by 2002:a05:600c:a48:b0:477:9eb8:97d2 with SMTP id 5b1f17b1804b1-47d84b08652mr217833285e9.8.1768233249768; Mon, 12 Jan 2026 07:54:09 -0800 (PST) Message-ID: <30dbd0b0-2a2b-4064-b39c-4dfa438af15b@suse.com> Date: Mon, 12 Jan 2026 16:54:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 03/15] xen/riscv: implement vcpu_csr_init() 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: <7ba4bcfe-59d3-43f3-adb4-207424dc1713@gmail.com> <988ba581-5503-45d4-a621-18cdc3b14cab@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: <988ba581-5503-45d4-a621-18cdc3b14cab@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12.01.2026 16:46, Oleksii Kurochko wrote: > On 1/12/26 3:28 PM, Jan Beulich wrote: >> On 12.01.2026 13:59, Oleksii Kurochko wrote: >>> On 1/7/26 9:46 AM, Jan Beulich wrote: >>>> Also, wouldn't you better keep internal state in line with what hardware >>>> actually supports? CSRIND may be read-only-zero in the real register, in >>>> which case having the bit set in the "cached" copy can be misleading. >>> [...] >>> >>>> (This may similarly apply to at least hedeleg and hideleg, btw.) >>> Regarding the previous bits, I can understand that it would be an issue: >>> if SSAIA isn’t supported, then it is incorrect to update the corresponding >>> bits of|hstateen0|. >>> >>> However, I’m not really sure I understand what the issue is with|h{i,e}deleg|. >>> All writable bits there don’t depend on hardware support. Am I missing something? >> My reading of the doc was that any of the bits can be r/o 0, with - yes - >> no dependencies on particular extensions. > > Just to be sure that I get your idea correctly. > > Based on the priv. spec: > Each bit of hedeleg shall be either writable or read-only zero. Many bits of > hedeleg are required specifically to be writable or zero, as enumerated in > Table 29. > > Now let’s take hedeleg.bit1, which is marked as writable according to Table 29. > Your point is that even though hedeleg.bit1 is defined as writable, it could still > be read-only zero, right? > > In general, I agree with that. It is possible that M-mode software decides, for > some reason (for example, because the implementation does not support delegation > of bit1 to a lower mode), not to delegate medeleg.bit1 to HS-mode. In that case, > hedeleg.bit1 would always be read-only zero. > >> In which case you'd need to do >> the delegation in software. For which it might be helpful to know what >> the two registers are actually set to in hardware (i.e. the cached values >> wanting to match the real ones). > > Does it make sense then to have the following > ... > v->arch.hedeleg = hedeleg; > vcpu->arch.hedeleg = csr_read(CSR_HEDELEG); > in arch_vcpu_create()? The above makes no sense to me, with or without s/vcpu/v/. > Or I can just add the comment that it will be sync-ed with the corresponding > hardware CSR later as ,actually, there is some h{i,e}deleg synchronization > happening during context_switch() (this code is at the moment in downstream), > because restore_csr_regs() is executed and re-reads CSR_H{I,E}DELEG: > static void restore_csr_regs(struct vcpu *vcpu) > { > csr_write(CSR_HEDELEG, vcpu->arch.hedeleg); > csr_write(CSR_HIDELEG, vcpu->arch.hideleg); > ... > As a result, vcpu->arch.h{I,E}deleg is kept in sync with the corresponding > hardware CSR. No, the r/o bits will continue to be out-of-sync between the hw register and the struct arch_vcpu field. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 15:54:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 15:54:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200630.1516502 (Exim 4.92) (envelope-from ) id 1vfKFP-0006aD-Qp; Mon, 12 Jan 2026 15:54:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200630.1516502; Mon, 12 Jan 2026 15: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 1vfKFP-0006a4-Ns; Mon, 12 Jan 2026 15:54:27 +0000 Received: by outflank-mailman (input) for mailman id 1200630; Mon, 12 Jan 2026 15:54:25 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfKFN-0006IZ-Ju for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 15:54:25 +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 f06d8582-efce-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 16:54:12 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by PAWPR03MB10072.eurprd03.prod.outlook.com (2603:10a6:102:360::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.6; Mon, 12 Jan 2026 15:54: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.9499.005; Mon, 12 Jan 2026 15:54: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: f06d8582-efce-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iJdeRu7uBldq23dVPVVkKtCXCEkJ+lSloucfQnx+lZAZf70FhLelg4PkUSB68IlUtG6iY+1LytdLzORHNU6zkCK/KeFt/vasqt2sY4r/peuBKOQzZY7ccO2arzAq5cZGn2xeMojzDcNHevkdbhGQCD5AQetuLk/QWMTKT9+w9czK/qxhcWttxbTw+gJW/Z25awbv8YygC9tV74Rg2DfrHIk+/oN3+SazDMl6wrFi8+l+Gf/sNuHepob3e3q5TjqYGqOUUuB9QfPYkOP4Wnkb0kvbt8JQrCG1VP5aZtQeH+Xp8E+iAKNl+wp5TNBSxtyQOodZuu6/Bb7SllqjbceGWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/Ql83DLzwt2KYkFDfneGGmEtBaBuXc+nDX+/yAANOHI=; b=vOEM3Z4LxgdVVAQYosCINrt/0otIDp9fhmuqKQjKpwN74NDmmGzDrl7BRjiuNSA5OSlHIt8YTsz+0anajCFZk+2+hhcJVBccGsgUTuo9Uf6CbFzTFxrn56EzcElaPWfeY+/pOFhggF14t9d+sDHgLJfouMIuifHHKhrynhZEuj3dHr94VABJ1xmSqZ8UVq55b5swjJ5e1OW/0+za3d0ju9T0ssL/zoEqwKidGXuN5XzVnZmCcvVJq9j2w64nU9dMTWXLpc60DycK86dHp9Kw0EWNdiXBLUNFu6lEnVjLg8L7DMxg2/pKcCmcYCm+XWuQDlVcYr4TAAIDa/KAO7ehxQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/Ql83DLzwt2KYkFDfneGGmEtBaBuXc+nDX+/yAANOHI=; b=V6g2vEtAXfhLt+IZyliV3NXXbudFhjac2WHKrhEIY06YryUCAjXOxy5wViQL2HrDZaBjUAfKnLTQy/0y7ZguLHeZhUGXE1tJhQBsEbDq+5pFaB45w4jVUN+35xALSwvKFR9bp8iC1jO1+Rrh8APCy0snjiBHkzOaS5MvLEiN+SsQcyRILFAOzLgNmFXAq99NW1DkeG/KVNCLHLu/iBwt7ZJESDl8E77+LBqL9wpE8/dxkXlzeKoFXON6i7KDQkfI6/Yzfz7ZD6PtyHj1nJhxXEdWx6putxmOsWuMGkXhqMAIyRoW+BZ847syo0U7sAjOIof7moxj1hoVvT0DfhGsYQ== From: Oleksii Moisieiev To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v6 1/5] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu Thread-Topic: [PATCH v6 1/5] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu Thread-Index: AQHcSyafS16SOr0Uk0OkeRdy8jd8CrVPHVoAgAADtoA= Date: Mon, 12 Jan 2026 15:54:08 +0000 Message-ID: <99586f5c-d76b-4cbe-9fbd-c87e86bb236a@epam.com> References: <9598b2e2-7df8-40c5-82cb-c097121af763@suse.com> <5d8f55a6-7182-4e9d-a139-96fddb9450f8@epam.com> <98f5e8f0-070c-4be5-9baf-46278de8093d@suse.com> In-Reply-To: <98f5e8f0-070c-4be5-9baf-46278de8093d@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_|PAWPR03MB10072:EE_ x-ms-office365-filtering-correlation-id: 430ff6ab-e178-40de-3315-08de51f2d253 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?YnlIZHhMdzFhRkUrVDRtdVVzUUtUcEdCMUVKZGlyZVJZeDhXdnlPWmd4NHRu?= =?utf-8?B?aXNJSU1FYXJwRFQ3OEtoYmFpU1RXTEZqZXpCT3lpV2ZhWjZ2aHVLL1BoUHhZ?= =?utf-8?B?MHRxWWszVjN3YkZVSXpXT2FoZEZXR000UWZPd2ptUXRKUG5jQmh3UlJSTURW?= =?utf-8?B?RlJYcTFBalp6anBTVWJRWmp3Y3VZTlBpZEE3djFsRkE3NFRxdEYrWG11Z0RZ?= =?utf-8?B?TU1YNWpKTHVqQ1dsT0MwMUh3MVg0aDFVekZ6VE14KzA0bFRKdVpaMy9GQ1pG?= =?utf-8?B?RVpjbUZBTzR1S0dSRlFiM0paYXR6K0sxVGRkM1BjNGZNd1BkOWRoTGlTNHJr?= =?utf-8?B?ODA0djk2bUpZemd2eUxPOElybGZhcGZUcW5YUGVRaHpNZVByeE8vT1BudFlu?= =?utf-8?B?cFFTdS9mN2hVWGRuZVI1ekk0M0tqa3pleVI5TENuWGlzcUR0RXcyZEM2NDhL?= =?utf-8?B?VWRNUHFVZDlmeUN2S3RSSjZSelR0R2Z2ZDhwd1hHOGMyMldFQS8yeUlGZzlM?= =?utf-8?B?V2k5QSs1cWdQcnVpVHRPRU1CU2dwRjdvbzZGcHhJWkFEN2dHazlHb2pKL2xz?= =?utf-8?B?dTlnNWhrOEhkeUY2ajlkREZ0cFdRVGxoTzVXOFd4VFI0OElqbHBBbWlCcVhG?= =?utf-8?B?dkozaFJtaWc1cDY5VEJ0RTh4KzE2WTFiOEx6Ykt0N2FMeTlRMmJPRTRKWGFN?= =?utf-8?B?WWp6RDhHdHowTS92MlJzME1kalN3bWRpTHoxUDVUUGFkTDlka3d3K2Q0Skxp?= =?utf-8?B?QTl6N29WQkV0OFlCRXp3Q1l6SVhGc0ZTb0pSMlVsQlhyVlFVWjZ3dllJVHNZ?= =?utf-8?B?eWRMYjhwWnZGSnMzM2tPSVBENmxXQWVpY09EdUw5L2pNeXdURjRqV3YwTXBE?= =?utf-8?B?RzJPa1Zld0VXNVVNbGFFWXFsUmUxL05PbEZ0UUxFN285VUIzWGUrNTdROStM?= =?utf-8?B?K3h4UVZkL3kxV1I1ZjNwMGs2RWdCVFNwalMwSllhejJiS0Roc2VQdVRWVGFE?= =?utf-8?B?akVselNkdktPRys0M1dWM2trYVVGeDhMQTJ1T1AyUytpaGFlQWkxUVBNT3o2?= =?utf-8?B?RE5ER2ZyS09udmFoR0c1L083ODYvLzUyWGpPbGdXa1RaeVl4RU5TLzhkUUJ5?= =?utf-8?B?YVZIS1k3dkdMNFhSempwVkhJcjdHVDhMenp1TkxjS1Z2TW1zVVhJZUdlY2ND?= =?utf-8?B?MlIwbzFlU1dPTCtZcTVZWGJDalRWV25qQlE1WWFUZ3hzNmxPVjI5SWVVdS93?= =?utf-8?B?VU9LMGVSL0NKRmhRNE9xS042R0V1N2x5bXRtZjQ4U2RjQ1N6MUtiQ0VmS1pX?= =?utf-8?B?ZlBuSTJJeUp3VnRxWDZlZGtjcWpxTVB3SWpCRDgrcGVleERsemxHY2JtbnNm?= =?utf-8?B?VVNaS2c1Kzd5WTVuamp6N2Z2UHZGajhsUERrcEg4cEpjT0lyaWt6VkR6VGdK?= =?utf-8?B?YkkzV0dtZnhIa2hhekpyRlJHbnVEZWpXak5mZVNPNjczcjJ3cmd5MEV1aGgw?= =?utf-8?B?Y0Q2cm5EZkNYc1VWNXBPUVh2RlMwN1FYU092ajVteUVNeTlNd0M0OFkwbjJK?= =?utf-8?B?WUFrRmhib1NiUVg2NHAreUQxMWtXSUpVWjJLbG11M3BoL2tiZ3dEQ2g1V3o2?= =?utf-8?B?RWJzOWhUZzV0Q0R5T3pNTGdURWxndG5ubUg3TjI0TVNqMkpwTWk2NUtCSWZY?= =?utf-8?B?OHdLY2hTcC9ZR2FmLzhFV29oWHowL3VXaExsNVhTOEhCQXovUkx1cXJwVVFW?= =?utf-8?B?UXV6amtHRVRsS0VQZzBIR1pYZytpMTh2YUI5cjFzWHdCZHJsZFh4OUx6VUp4?= =?utf-8?B?OVlTdjVyQVluZVgza3BtOXYzS1YzS2todUplM2RmUlBxM0pISEQvMERnT1lo?= =?utf-8?B?RVh1WUczUjdwN3hTZUIwZ1U2bW5pVHJoRWVaSUJiOFd4eXNiYTNXVUtZUnpX?= =?utf-8?B?eEVZbHpiWnN3bFQzTVVEckdFd0Y1YXlUeEVKaWJvQmx5eGwwbE5vU3J2c21Z?= =?utf-8?B?L3JoRmIwZG0wMmI2L2NmWjNHSGV2SGRYMVhVQkdlT1poc1ZtYnZIUkNiRGdM?= =?utf-8?Q?DQi1vQ?= 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?MkdlYXJrUjFNdzhKNmRaVC9OOVVpWXBnd3dXdDFhQldudFNsRkFvK1lFYnVx?= =?utf-8?B?V1cwZG5vOTJmbVM3NXhCMll4RmZsNFIxZ3h6Nk9qNlF3dis0NG1KM0pCS1RK?= =?utf-8?B?NGZQUHcxVVlzM2diTUl1eWVqaFRJZU9YM1dWeUVCcjVEeG02bjJHaFZpdWps?= =?utf-8?B?UWVnNEdCOThYazhLY0h2elBEdGZVL29icnVOZWVCU29kNXlGZ2xGWW1ZR3ZW?= =?utf-8?B?QzlDcS9HQkY5Y0xrUTQ3Ym1NajJheUxkM0N2ZUpwMHpodzEzUSs1K2c1ZjI5?= =?utf-8?B?TEQxMjZ3ZEhGdnFTQUMyUU1hQVRZa1JKcFNTcEJseHgxeURGdDRKdjBBcWFK?= =?utf-8?B?MzZ4cjVoeUw4Qno0WG5uTG1xd3Z2Y2I3d3BwRnhjMW12VGNEYUdkTzZEOERq?= =?utf-8?B?eFB2eHRVT3NLN1NQZnpRVVlvd1ZLUHRSVFRQYnBnMDZMU0VDRTh5Mm5VUDdG?= =?utf-8?B?NnNqOGtzRXYrK1NPQ3RrWHpORDdvT0U2ek5uekIyYWdOUlBCcmM3c1hhc283?= =?utf-8?B?Vnd5MWFoTjBSbTZXMXhXcVZKVGNNeU5GRnVzakgrM2xiREtjbFIwUWQySmZY?= =?utf-8?B?Rk4rZ2lLZTA3NGE1RTJPQ2YybmxUV21sOVltVSs4UmJrOEZyOUIzUzRvRTl5?= =?utf-8?B?UHI1SHZMK2Z6Qkt1ZGtSK3pOaFNJL0kxK05UT2lOOGJ0SElOclFWTUxGRXdq?= =?utf-8?B?MGh6MnQxRzNtRkJtUWpyK1c4LzlHbTdUUGtrWTlOUzVzNnBzOUNWZXFrSjNZ?= =?utf-8?B?ODRqckVZaFVrTlBaWVBpMmxWM2JOcHJMc0VmZHFTT0hNeFExK0E0QW03Z1hn?= =?utf-8?B?ek9YcDFnK0RJTXNFQ3VTUWFEUDdHekRPVGZlaGdGT3JWdGZYcjltbzJSYjJB?= =?utf-8?B?b1pBRVlha0RnNDdPTzFvbk5hYWxGVGJDYlZkUUlUazQ1dytTQWFnQzFlWWhT?= =?utf-8?B?Szd3MUR3MTV3bUorcEN3dGNyalZOMCtzdGdiVHRPeE9acFpLcjVITy9QWkta?= =?utf-8?B?SFZDL0htYU9rK1I2dVovRlpGUG90VktvNXBwblIwbEduTTJoSnYwMUovcTNZ?= =?utf-8?B?YVhleDRGdmpDN3g0L3NIQkgvUDZ6b2g1T3gvSlIySm9yYUZoU1dlaFhmZnhN?= =?utf-8?B?dGh5dUFCelRkSzhyZzZIWi9adzZoMGVtYW84Y2dKdGpUTGRkNUVxWE5WOS9Z?= =?utf-8?B?ZjUyVUN2SzRlbFZNUlZ3QjhHRUhPM1dSTE9nVGpKVnZKbkcybUY3UHl0c1la?= =?utf-8?B?YXhSbWdSemR1eTJ4bUQrZmVZTnJPekp1SGF6S25pRHRxdFZhQ21jQnA1ZTla?= =?utf-8?B?Z3Y0a0drVHE1eHV6RDljSm8xTXpkL0I4cGtydVVsYlVvSExpbnNGY3Bvd3lr?= =?utf-8?B?SWhXQ3lZc0NIaFNqYmlOakUzd0JoUm5BWmQwaXRRVmtnMFVwOTRxazZMQkl5?= =?utf-8?B?OXdvVHh1UmVFL0dMK08xNTdSMUtRZ0Y2SHM2SXRRNU0rZGVERHNnak5kWUsw?= =?utf-8?B?aVkxRDI4WktGQmhGWjdPRVFMMG03anMyNVo0NCtscnNSTENOQmxqL05yWmwx?= =?utf-8?B?dFNxKzFxcFB6VGh0cG82OXEzMkNLY3VVVklpeFRKYTE3NVdPcUwyMVk0eEw0?= =?utf-8?B?c1hxLzNpUVRIUXU5d0NtQjRWYTZsczdxbVBqOG9ESjV2RFJmTzd6TVJPaEs0?= =?utf-8?B?RHJHMmJoVVYzdXJkZlZDeTV5Q3RYTUxHUXJDVG9DaUMzcTNvdVFteUI3UVlm?= =?utf-8?B?dHlVaE8wTWVscTdkMjNKc0d5WnExNHVNSlpUQUxuV1lkUG00YWlPSkEvTUd3?= =?utf-8?B?c0poRGFnMzVkb3dzdEN3RXduRDQ3U0lOMDZTZjNpanFTK0dJTTdVRzl6VHNR?= =?utf-8?B?YW9DY29BSDZNay9kZVlGMFVtdHJ4eHNDdWVPWjc1KzE2eWFRdVFlN2Z0dldx?= =?utf-8?B?a2c1bkFMMzZuanZ1czJoWHZFbjNBWTJYTmNucmNzRkl5US8wMXpsYmhueUMr?= =?utf-8?B?TVlkQytheGtEbDZ3Q3B0NVNLQ3hZN0h2ZDdsVUR2L3lBQ0tVWEE4NkxRcGQ4?= =?utf-8?B?a2RwUFRFMDJYb2NpaG1aY21lODgxcnpOdzNnSG56K2Q0MHc4Tm92VmlGdWZq?= =?utf-8?B?RFJlVE5hQXpEbFk3Y01iWU1OeWw2MVZ4VWNZSlVteUhvdFVRM3FnMlZkbDNu?= =?utf-8?B?S01EZ2ZtTlVlMzVxZTFxT1grenFDeXBzdGpzcGNpSkNHaVZ2YTMrOGJoblJq?= =?utf-8?B?MkVmY2dBb3dQODNlZHhXZjMrNTVDc2dLWXprODNjdHVQbkUzL0tKOC9KR1hD?= =?utf-8?B?ZWlOQ3g4SktydDhueG83L3dOL2wwb0RxOGtpU1JwUmFicFpGTUgwZVhFUmpm?= =?utf-8?Q?rv40Lo039gjR9xHw=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: PAVPR03MB8946.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 430ff6ab-e178-40de-3315-08de51f2d253 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2026 15:54:08.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: QmsUwlG1XFFFU4gvc4fBYw2rMbC0sS3i/o56udTrsGVggGcSa+eDmGtY6uVz++tUi2gnr6jimY+TPGpZ9S67X5BpJ9Ov4LKmjnY0uEagd2A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR03MB10072 DQoNCk9uIDEyLzAxLzIwMjYgMTc6NDAsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxMi4wMS4y MDI2IDE2OjE2LCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToNCj4+IE9uIDA2LzExLzIwMjUgMTI6 MDksIEphbiBCZXVsaWNoIHdyb3RlOg0KPj4+IE9uIDAxLjExLjIwMjUgMTI6NTYsIE9sZWtzaWkg TW9pc2llaWV2IHdyb3RlOg0KPj4+PiBAQCAtODI3LDcgKzgyOCwzMiBAQCBsb25nIGRvX2RvbWN0 bChYRU5fR1VFU1RfSEFORExFX1BBUkFNKHhlbl9kb21jdGxfdCkgdV9kb21jdGwpDQo+Pj4+ICAg ICAgICBjYXNlIFhFTl9ET01DVExfdGVzdF9hc3NpZ25fZGV2aWNlOg0KPj4+PiAgICAgICAgY2Fz ZSBYRU5fRE9NQ1RMX2RlYXNzaWduX2RldmljZToNCj4+Pj4gICAgICAgIGNhc2UgWEVOX0RPTUNU TF9nZXRfZGV2aWNlX2dyb3VwOg0KPj4+PiArICAgICAgICBpbnQgcmV0MTsNCj4+Pj4gKw0KPj4+ PiArICAgICAgICAvKg0KPj4+PiArICAgICAgICAgKiBBZGQgY2hhaW5lZCBoYW5kbGluZyBvZiBh c3NpZ25lZCBEVCBkZXZpY2VzIHRvIHN1cHBvcnQNCj4+Pj4gKyAgICAgICAgICogYWNjZXNzLWNv bnRyb2xsZXIgZnVuY3Rpb25hbGl0eSB0aHJvdWdoIFNDSSBmcmFtZXdvcmssIHNvDQo+Pj4+ICsg ICAgICAgICAqIERUIGRldmljZSBhc3NpZ24gcmVxdWVzdCBjYW4gYmUgcGFzc2VkIHRvIEZXIGZv ciBwcm9jZXNzaW5nIGFuZA0KPj4+PiArICAgICAgICAgKiBlbmFibGluZyBWTSBhY2Nlc3MgdG8g cmVxdWVzdGVkIGRldmljZS4NCj4+Pj4gKyAgICAgICAgICogVGhlIGFjY2Vzcy1jb250cm9sbGVy IERUIGRldmljZSBwcm9jZXNzaW5nIGlzIGNoYWluZWQgYmVmb3JlIElPTU1VDQo+Pj4+ICsgICAg ICAgICAqIHByb2Nlc3NpbmcgcHJlc2VydmluZyByZXR1cm4gY29kZSBhbmQgZXhwZWN0ZWQgdG8g YmUgZXhlY3V0ZWQgZm9yDQo+Pj4+ICsgICAgICAgICAqIGFueSBEVCBkZXZpY2UgcmVnYXJkbGVz cyBpZiBEVCBkZXZpY2UgaXMgcHJvdGVjdGVkIGJ5IElPTU1VIG9yDQo+Pj4+ICsgICAgICAgICAq IG5vdCAob3IgSU9NTVUgaXMgZGlzYWJsZWQpLg0KPj4+PiArICAgICAgICAgKi8NCj4+Pj4gKyAg ICAgICAgcmV0MSA9IHNjaV9kb19kb21jdGwob3AsIGQsIHVfZG9tY3RsKTsNCj4+PiBXaHkgd291 bGQgdGhpcyBub3QgYmUgdGhlIGluaXRpYWxpemVyIG9mIHRoZSBuZXcgdmFyaWFibGU/IChJIGFs c28gZG9uJ3QgdGhpbmsNCj4+PiB0aGF0IHdlJ3ZlIGRlY2lkZWQgdG8gcGVybWl0IHZhcmlhYmxl IGRlY2xhcmF0aW9ucyBhdCBvdGhlciB0aGFuIHRoZSB0b3Agb2YNCj4+PiBzY29wZXMgb3Igd2l0 aGluIGUuZy4gYSBmb3IoKSBsb29wIGNvbnRyb2wgY29uc3RydWN0LikNCj4+Pg0KPj4gKw0KPj4+ PiAgICAgICAgICAgIHJldCA9IGlvbW11X2RvX2RvbWN0bChvcCwgZCwgdV9kb21jdGwpOw0KPj4+ PiArICAgICAgICBpZiAoIHJldCA8IDAgKQ0KPj4+PiArICAgICAgICAgICAgcmV0dXJuIHJldDsN Cj4+PiBXaHkgd291bGQgeW91IGludm9rZSBib3RoIGluIGFsbCBjYXNlcz8gSWYgc2NpX2RvX2Rv bWN0bCgpIGhhbmRsZWQgdGhlIHJlcXVlc3QsDQo+Pj4gdGhlcmUgaXNuJ3QgYW55IHBvaW50IGlu IGFsc28gaW52b2tpbmcgaW9tbXVfZG9fZG9tY3RsKCksIGlzIHRoZXJlPyBPciBlbHNlIGlzDQo+ Pj4gdGhlcmUgbWF5YmUgc29tZSBjcnVjaWFsIGFzcGVjdCBtaXNzaW5nIGZyb20gdGhlIGRlc2Ny aXB0aW9uIChvciBub3QgZXhwbGljaXQNCj4+PiBlbm91Z2ggdGhlcmUgZm9yIGEgbm9uLVNDSSBw ZXJzb24gbGlrZSBtZSk/DQo+Pj4NCj4+PiBBbHNvIHRoaXMgZG9lc24ndCBsb29rIHRvIGZpdCB0 aGUgZGVzY3JpcHRpb24gc2F5aW5nICJUaGUgU0NJIGFjY2Vzcy1jb250cm9sbGVyDQo+Pj4gRFQg ZGV2aWNlIHByb2Nlc3NpbmcgaXMgY2hhaW5lZCBhZnRlciBJT01NVSBwcm9jZXNzaW5nIC4uLiIN Cj4+Pg0KPj4gV2UgY2FsbCBib3RoIGJlY2F1c2UgU0NJIGFuZCBJT01NVSBjb3ZlciBkaWZmZXJl bnQgY29uY2VybnMgYW5kIGEgRFQNCj4+IGRldmljZSBtYXkgbmVlZA0KPj4gYm90aDogU0NJIGZv ciBGVy1tZWRpYXRlZCBhY2Nlc3MgY29udHJvbCAocG93ZXIvY2xvY2tzL3Jlc2V0KSBhbmQgSU9N TVUNCj4+IGZvciBETUEgaXNvbGF0aW9uLg0KPj4gU0NJIHJldHVybmluZyBzdWNjZXNzIGRvZXMg bm90IG1lYW4gdGhlIElPTU1VIHdvcmsgaXMgcmVkdW5kYW50Lg0KPiBDYW4gdGhlIGNvbW1lbnQg dGhlbiBwbGVhc2UgYmUgdXBkYXRlZCB0byBwcm9wZXJseSBjYWxsIG91dCB0aGlzIGR1YWwNCj4g cmVxdWlyZW1lbnQ/DQpZZXMsIGZvciBzdXJlLg0KPj4gLSBzY2lfZG9fZG9tY3RsKCkgcmV0dXJu cyAtRU5YSU8gd2hlbiBpdCBoYXMgbm90aGluZyB0byBkbyAobm9uLURULCBubw0KPj4gbWVkaWF0 b3IsIG1lZGlhdG9yIGxhY2tzIGFzc2lnbiBob29rKS4NCj4+IFRoYXQgaXMgdGhlIOKAnG5vdCBo YW5kbGVkIGJ5IFNDSeKAnSBzZW50aW5lbDsgaW4gdGhhdCBjYXNlIHRoZSBjb2RlDQo+PiBwcm9j ZWVkcyB0byBJT01NVSBub3JtYWxseS4NCj4+IC3CoCBXaGVuIHNjaV9kb19kb21jdGwoKSBzdWNj ZWVkcyAoMCksIHRoZSBkZXZpY2UgbWF5IHN0aWxsIHJlcXVpcmUgSU9NTVUNCj4+IHByb2dyYW1t aW5nDQo+PiAoZS5nLiwgRFQgZGV2aWNlIGhhcyBhbiBpb21tdXMgcHJvcGVydHkpLiBTa2lwcGlu ZyBpb21tdV9kb19kb21jdGwoKQ0KPj4gd291bGQgbGVhdmUgRE1BIGlzb2xhdGlvbiB1bnByb2dy YW1tZWQuDQo+Pg0KPj4gVGhlIGZpbmFsIGlmIChyZXQxICE9IC1FTlhJTykgcmV0ID0gcmV0MTsg ZW5zdXJlcyB0aGF0IGlmIGJvdGggcGF0aHMgcmFuDQo+PiBhbmQgSU9NTVUgc3VjY2VlZGVkLA0K Pj4gYW4gU0NJIGZhaWx1cmUgaXMgc3RpbGwgcmVwb3J0ZWQgdG8gdGhlIGNhbGxlci4NCj4+DQo+ PiBEZXZpY2UtdHJlZSBleGFtcGxlcyB0byBpbGx1c3RyYXRlIHRoZSBkdWFsIHJvbGVzOg0KPj4g MS4gQWNjZXNzLWNvbnRyb2xsZWQgRFQgZGV2aWNlIChub3QgbmVjZXNzYXJpbHkgSU9NTVUtcHJv dGVjdGVkKToNCj4+DQo+PiBpMmMzOiBpMmNAZTY1MDgwMDAgew0KPj4gICDCoMKgwqAgY29tcGF0 aWJsZSA9ICJyZW5lc2FzLHJjYXItZ2VuMy1pMmMiOw0KPj4gICDCoMKgwqAgcmVnID0gPDAgMHhl NjUwODAwMCAwIDB4NDA+Ow0KPj4gICDCoMKgwqAgcG93ZXItZG9tYWlucyA9IDwmc2NtaV9wZCA1 PjvCoMKgwqDCoMKgIC8vIEZXLW1hbmFnZWQgcG93ZXIgZG9tYWluDQo+PiAgIMKgwqDCoCBjbG9j a3MgPSA8JnNjbWlfY2xrIDEyPjsNCj4+ICAgwqDCoMKgIGNsb2NrLW5hbWVzID0gImZjayI7DQo+ PiAgIMKgwqDCoCBhY2Nlc3MtY29udHJvbGxlcnMgPSA8JnNjbWlfeGVuIDA+Ow0KPj4gICDCoMKg wqAgLy8gbm8gaW9tbXVzIHByb3BlcnR5OiBTQ0kgbWF5IG5lZWQgdG8gYXV0aG9yaXplL3Bvd2Vy IHRoaXMgZGV2aWNlOw0KPj4gSU9NTVUgaGFzIG5vdGhpbmcgdG8gZG8NCj4+IH07DQo+Pg0KPj4g Mi4gSU9NTVUtcHJvdGVjdGVkIERUIGRldmljZSB0aGF0IHN0aWxsIG1heSBuZWVkIFNDSSBtZWRp YXRpb246DQo+PiB2cHU6IHZpZGVvQGU2ZWYwMDAwIHsNCj4+ICAgwqDCoMKgIGNvbXBhdGlibGUg PSAicmVuZXNhcyxyY2FyLXZwdSI7DQo+PiAgIMKgwqDCoCByZWcgPSA8MCAweGU2ZWYwMDAwIDAg MHgxMDAwMD47DQo+PiAgIMKgwqDCoCBpb21tdXMgPSA8JmlwbW11IDAgMD47wqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIC8vIG5lZWRzIElPTU1VIG1hcHBpbmcgZm9yIERNQQ0KPj4gaXNvbGF0aW9u DQo+PiAgIMKgwqDCoCBwb3dlci1kb21haW5zID0gPCZzY21pX3BkIDc+O8KgwqDCoMKgwqAgLy8g RlctbWFuYWdlZCBwb3dlci9jbG9jay9yZXNldA0KPj4gICDCoMKgwqAgY2xvY2tzID0gPCZzY21p X2NsayAzND47DQo+PiAgIMKgIMKgIGFjY2Vzcy1jb250cm9sbGVycyA9IDwmc2NtaV94ZW4gMD47 DQo+PiAgIMKgwqDCoCBjbG9jay1uYW1lcyA9ICJ2cHUiOw0KPj4gfTsNCj4+Pj4gLS0tIGEveGVu L2RyaXZlcnMvcGFzc3Rocm91Z2gvZGV2aWNlX3RyZWUuYw0KPj4+PiArKysgYi94ZW4vZHJpdmVy cy9wYXNzdGhyb3VnaC9kZXZpY2VfdHJlZS5jDQo+Pj4+IEBAIC0zNzksNiArMzc5LDEyIEBAIGlu dCBpb21tdV9kb19kdF9kb21jdGwoc3RydWN0IHhlbl9kb21jdGwgKmRvbWN0bCwgc3RydWN0IGRv bWFpbiAqZCwNCj4+Pj4gICAgICAgICAgICAgICAgYnJlYWs7DQo+Pj4+ICAgICAgICAgICAgfQ0K Pj4+PiAgICANCj4+Pj4gKyAgICAgICAgaWYgKCAhZHRfZGV2aWNlX2lzX3Byb3RlY3RlZChkZXYp ICkNCj4+Pj4gKyAgICAgICAgew0KPj4+PiArICAgICAgICAgICAgcmV0ID0gMDsNCj4+Pj4gKyAg ICAgICAgICAgIGJyZWFrOw0KPj4+PiArICAgICAgICB9DQo+Pj4+ICsNCj4+Pj4gICAgICAgICAg ICByZXQgPSBpb21tdV9hc3NpZ25fZHRfZGV2aWNlKGQsIGRldik7DQo+Pj4+ICAgIA0KPj4+PiAg ICAgICAgICAgIGlmICggcmV0ICkNCj4+PiBIb3cgYXJlIERUIGFuZCBQQ0kgZGlmZmVyZW50IGlu IHRoaXMgcmVnYXJkPw0KPj4gUGxlYXNlIGZpbmQgZXhhbXBsZXMgYWJvdmUuDQo+IFNvcnJ5LCBi dXQgSSBjYW4ndCBzcG90IGFueXRoaW5nIFBDSS1pc2ggaW4gdGhlIGV4YW1wbGVzIGFib3ZlLiBU aGVuIGFnYWluIEkNCj4gYWxzbyBubyBsb25nZXIgcmVjYWxsIHdoeSBJIGNvbXBhcmVkIHdpdGgg UENJIGhlcmUuIE9oLCBwZXJoYXBzIGJlY2F1c2UgdGhlDQo+IFBDSSBzaWRlIGlzbid0IGJlaW5n IG1vZGlmaWVkIGF0IGFsbC4NCj4NCj4gSmFuDQpDb3JyZWN0LCBwY2kgY29kZSB3YXNuJ3QgdG91 Y2hlZCBieSB0aGVzZSBjaGFuZ2VzLg0KDQpCUiwNCk9sZWtzaWk= From xen-devel-bounces@lists.xenproject.org Mon Jan 12 15:56:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 15:56:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200652.1516514 (Exim 4.92) (envelope-from ) id 1vfKHT-0007O2-Ap; Mon, 12 Jan 2026 15:56:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200652.1516514; Mon, 12 Jan 2026 15: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 1vfKHT-0007Nv-6w; Mon, 12 Jan 2026 15:56:35 +0000 Received: by outflank-mailman (input) for mailman id 1200652; Mon, 12 Jan 2026 15: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 1vfKHS-0007Np-PG for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 15:56:34 +0000 Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [2a00:1450:4864:20::341]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4460b892-efcf-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 16:56:33 +0100 (CET) Received: by mail-wm1-x341.google.com with SMTP id 5b1f17b1804b1-47d5e021a53so48413005e9.3 for ; Mon, 12 Jan 2026 07:56:33 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f410c6csm373463475e9.1.2026.01.12.07.56.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 07:56:32 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4460b892-efcf-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768233393; x=1768838193; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=ewxnBaxkEZmaU9gpOowpu+m6pnznGAAv/rdTc8xpueI=; b=eAdoYSMtUWveAnrM249JUkdFmoorKfT0qbM/EIhCHsFaQ+Zci5k+bcCs2SBizYw1KR MkULkRmMm5J+Sh1L2bGS8HNSeJZoz3TmwmYuTjD1UP9GNsv31Og2ehAT3sZC2Mxq4F3F njdoxG8Wni2i63MQIrksXrVD9Vp3DAKXMtPG5iq6AZd4lQsCABLrxTloSo3Base+x5oS WmVgqn2CCAdT/+i3fdHfLtFHja/UVGcJJ2ZkGy5masqEDvMW4d05dsS837oFmFPgBa4D 2/IL19cgqGyG42+TzgAVqJHqSkqwuRpZdQFxRBnw/zejykohfvZZ7TIVIBf97yF6+UYG dTmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768233393; x=1768838193; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ewxnBaxkEZmaU9gpOowpu+m6pnznGAAv/rdTc8xpueI=; b=rlMkHG0H5I7Le5ooGpUYprTdQk6uwdzOWP2Q3OSzPNJxkn9lsdiMvYEbaYxBl5wPpZ 0Ai53rrryXulYoos/pqmP+MI3e/g/cGs5cNc3tb8iGRjPvQQlkUsQtoDl9nOmrGs4YEZ lEgYiyGmktGumAfiXSdY1zLqcQgkWD7oK9tl6EjUeAu8B0/HOP9gfamMJgKyIpAiozOr 9bp3rloXi05uNqKGvDuYIQ38LkU4nhFLUmKuU0q3TXoBgsWFOYueiO0dM4FQ6k3xRphk KKEeaGnvx190eauPA5+drHSGN8y/sy5SSCeJRHtBU4JewBmIyi05/fYA72bgECZQbiFH bvqQ== X-Forwarded-Encrypted: i=1; AJvYcCWWVMQG/91m/enrByxp8JT9PlWfq2Kl7oKe+ntJ4Qm3DiVezUePkJ//wQcBN1wtzdjQp9yX4HyveJ4=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywr3UT/4fVCYwGwyL56LvN62vLn8+Nq1CSi8vIBvHCBqAd0izNz 9HtGWqm5SwRWTwoYWfegDfQjZPjWmrE519vFAPDnkIxAER6wJfq4Tem+C4yiALXa0g== X-Gm-Gg: AY/fxX7lHmpqED98gj9AXXUujiY0B6Vto173UTPy1LCne8IYKZVBRjna8y5G+TugGyR NBvf8CvtxcNwK0qhjii8UUkp5eoDXnYyNsZ8/39f1b94VLUJMMu+6oGiVzNfLURcxEwRgR4mXyu 18b1Il85gtKJ4mjuWpdghCABZD+uPL7XqPZBcGPewWVLKn5RsInTJyYIzKpb6xZZyIWaQfMFMRA aaJOg1iYJKQq7ZwbNeG1P5meLNAFGf5MdwLixY0KACKswTIA8qmIYbWGb7PNcxZtiHvjBXNA++F csmPkUwBeP8wMzsLiol7FSfodzXN1LPyWgnCqINaESwNbgsdXdvqw8jfLSZBbtbmR3AVJmE0A/A DLStHeCJVNomV61kum5r/F6Nyg1rKX+7Kke3bRTBt3CaNrvQzAP4V/c8V1I56ZEgemm/erGmo3x Ok9a1CaWN4xfoG5nRfw6GXt90jauItXRYEl8jaKQ627lWwM852nQenW/PF4cUsgaUzeOwM7j5Bq uw= X-Google-Smtp-Source: AGHT+IHw4mmlempgE0Yw/AObsToSevvBL5AY5mh/Y8veom4AvJIVCtMY/ZI3qCnJhfYZtok8GR4gEw== X-Received: by 2002:a05:600c:470c:b0:477:7a78:3016 with SMTP id 5b1f17b1804b1-47d84b0a5bemr201540245e9.8.1768233392826; Mon, 12 Jan 2026 07:56:32 -0800 (PST) Message-ID: <7cbda859-4257-499e-86e0-a0d001fd49c9@suse.com> Date: Mon, 12 Jan 2026 16:56:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/5] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu To: Oleksii Moisieiev Cc: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" References: <9598b2e2-7df8-40c5-82cb-c097121af763@suse.com> <5d8f55a6-7182-4e9d-a139-96fddb9450f8@epam.com> <98f5e8f0-070c-4be5-9baf-46278de8093d@suse.com> <99586f5c-d76b-4cbe-9fbd-c87e86bb236a@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: <99586f5c-d76b-4cbe-9fbd-c87e86bb236a@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12.01.2026 16:54, Oleksii Moisieiev wrote: > > > On 12/01/2026 17:40, Jan Beulich wrote: >> On 12.01.2026 16:16, Oleksii Moisieiev wrote: >>> On 06/11/2025 12:09, Jan Beulich wrote: >>>> On 01.11.2025 12:56, Oleksii Moisieiev wrote: >>>>> @@ -827,7 +828,32 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) >>>>> case XEN_DOMCTL_test_assign_device: >>>>> case XEN_DOMCTL_deassign_device: >>>>> case XEN_DOMCTL_get_device_group: >>>>> + int ret1; >>>>> + >>>>> + /* >>>>> + * Add chained handling of assigned DT devices to support >>>>> + * access-controller functionality through SCI framework, so >>>>> + * DT device assign request can be passed to FW for processing and >>>>> + * enabling VM access to requested device. >>>>> + * The access-controller DT device processing is chained before IOMMU >>>>> + * processing preserving return code and expected to be executed for >>>>> + * any DT device regardless if DT device is protected by IOMMU or >>>>> + * not (or IOMMU is disabled). >>>>> + */ >>>>> + ret1 = sci_do_domctl(op, d, u_domctl); >>>> Why would this not be the initializer of the new variable? (I also don't think >>>> that we've decided to permit variable declarations at other than the top of >>>> scopes or within e.g. a for() loop control construct.) >>>> >>> + >>>>> ret = iommu_do_domctl(op, d, u_domctl); >>>>> + if ( ret < 0 ) >>>>> + return ret; >>>> Why would you invoke both in all cases? If sci_do_domctl() handled the request, >>>> there isn't any point in also invoking iommu_do_domctl(), is there? Or else is >>>> there maybe some crucial aspect missing from the description (or not explicit >>>> enough there for a non-SCI person like me)? >>>> >>>> Also this doesn't look to fit the description saying "The SCI access-controller >>>> DT device processing is chained after IOMMU processing ..." >>>> >>> We call both because SCI and IOMMU cover different concerns and a DT >>> device may need >>> both: SCI for FW-mediated access control (power/clocks/reset) and IOMMU >>> for DMA isolation. >>> SCI returning success does not mean the IOMMU work is redundant. >> Can the comment then please be updated to properly call out this dual >> requirement? > Yes, for sure. >>> - sci_do_domctl() returns -ENXIO when it has nothing to do (non-DT, no >>> mediator, mediator lacks assign hook). >>> That is the “not handled by SCI” sentinel; in that case the code >>> proceeds to IOMMU normally. >>> -  When sci_do_domctl() succeeds (0), the device may still require IOMMU >>> programming >>> (e.g., DT device has an iommus property). Skipping iommu_do_domctl() >>> would leave DMA isolation unprogrammed. >>> >>> The final if (ret1 != -ENXIO) ret = ret1; ensures that if both paths ran >>> and IOMMU succeeded, >>> an SCI failure is still reported to the caller. >>> >>> Device-tree examples to illustrate the dual roles: >>> 1. Access-controlled DT device (not necessarily IOMMU-protected): >>> >>> i2c3: i2c@e6508000 { >>>     compatible = "renesas,rcar-gen3-i2c"; >>>     reg = <0 0xe6508000 0 0x40>; >>>     power-domains = <&scmi_pd 5>;      // FW-managed power domain >>>     clocks = <&scmi_clk 12>; >>>     clock-names = "fck"; >>>     access-controllers = <&scmi_xen 0>; >>>     // no iommus property: SCI may need to authorize/power this device; >>> IOMMU has nothing to do >>> }; >>> >>> 2. IOMMU-protected DT device that still may need SCI mediation: >>> vpu: video@e6ef0000 { >>>     compatible = "renesas,rcar-vpu"; >>>     reg = <0 0xe6ef0000 0 0x10000>; >>>     iommus = <&ipmmu 0 0>;             // needs IOMMU mapping for DMA >>> isolation >>>     power-domains = <&scmi_pd 7>;      // FW-managed power/clock/reset >>>     clocks = <&scmi_clk 34>; >>>     access-controllers = <&scmi_xen 0>; >>>     clock-names = "vpu"; >>> }; >>>>> --- a/xen/drivers/passthrough/device_tree.c >>>>> +++ b/xen/drivers/passthrough/device_tree.c >>>>> @@ -379,6 +379,12 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d, >>>>> break; >>>>> } >>>>> >>>>> + if ( !dt_device_is_protected(dev) ) >>>>> + { >>>>> + ret = 0; >>>>> + break; >>>>> + } >>>>> + >>>>> ret = iommu_assign_dt_device(d, dev); >>>>> >>>>> if ( ret ) >>>> How are DT and PCI different in this regard? >>> Please find examples above. >> Sorry, but I can't spot anything PCI-ish in the examples above. Then again I >> also no longer recall why I compared with PCI here. Oh, perhaps because the >> PCI side isn't being modified at all. >> > Correct, pci code wasn't touched by these changes. Yet my question boils down to "why", not "whether". Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 16:08:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 16:08:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200665.1516523 (Exim 4.92) (envelope-from ) id 1vfKTE-0001Vd-9U; Mon, 12 Jan 2026 16:08:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200665.1516523; Mon, 12 Jan 2026 16:08:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfKTE-0001VW-6n; Mon, 12 Jan 2026 16:08:44 +0000 Received: by outflank-mailman (input) for mailman id 1200665; Mon, 12 Jan 2026 16:08: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 1vfKTC-0001VQ-Qf for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 16:08:42 +0000 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [2a00:1450:4864:20::331]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f4ef6df4-efd0-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 17:08:39 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-47d182a8c6cso39025475e9.1 for ; Mon, 12 Jan 2026 08:08:39 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f661a03sm376363985e9.13.2026.01.12.08.08.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 08:08:38 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f4ef6df4-efd0-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768234118; x=1768838918; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=VKV6Ly1AzxRcAR3RvXMyZrr2y9yUwnfw167XiWvLG4s=; b=IaEzBl2pOZQCbK65df/CnOqgBxYhZvHkG+gLepih0Yqzb3Gzi2dyY6smk1q7y9bS8V PfgHKMNbfyHL1GlHeJeiUzOdhBkByPIJ37Udge4A1LCMnuiyCx+yjW8u2i+cG/SzeYnx Y9JTNvuIkDjgW9GSdaqRZ1xE3Josvs6yx9OHLuBH4Wwx/LLbRCJ9pO4kj7zVOmYovj25 6/9mM3agp1ICNQ4UcA7aErteX33Dd4Gp44jkqoCMBpZIJlNhLpEOPx9QzNbQgzvdmNpg 5w0OPMbb49XjE+oTovoTivYHp5Tmd/+pPg3GG/4+zIFIkfZZwAV3/rkw6bsTYJl1n+GB KS6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768234118; x=1768838918; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=VKV6Ly1AzxRcAR3RvXMyZrr2y9yUwnfw167XiWvLG4s=; b=KEQjaZpJ+Djzl2f0/MIjok/Wc1qHT/8c61OicKSmcgHTOfsDd1UfbAwuU7uu2idLWZ H/8uK5NEaaAXgxkOE94hs/nNtbtVy3ivEkT0nXktSt5BvG9Xek3avt3MiXCGgRkSqNdV wwTfR7z6Ic242VHIoGxblU1Kfef5MJJ4mqV6Sg/gB1SHxJYHdbdbnL+8dBJ+06M+hiro z8CfvBWoED/Iqxj+kms9ZGuqtKRiZz9F4qZNxFcifTrptsXOYY9WDQE2Hjt5FaB9LmWz 3FqP0VTO9XzHPw6ek+1XPp8Z6jalEOaSoww2uNPlGDb63iTSmdPXSnuhDuPLieHOFoCw Viow== X-Forwarded-Encrypted: i=1; AJvYcCWdhhHpsmJj2QLoPK/RE5F4DjqXQh2SWFe/D28P8uSSIKopMbhuM3ZK6wRtb0xXCQNrdLzEeIEcFCg=@lists.xenproject.org X-Gm-Message-State: AOJu0YzDYBfDXYgdHwcLx2CMX4/tepmyfx4VPV46jiQgP5ez76ptlAOV aL3PAtr6YRqTDElfILdA6+zmlm2zTUxAPn6tPM22teWVR4w909WOEQIP08rFLYMPag== X-Gm-Gg: AY/fxX67koXhspRs1OJCNLC9W9IgbaemRdTmMXXGK0zmI82Svb+5tmYWrrPO2fGI/zn rVUESHvJuAm+tmSlTvUWz8ERYopqnXMoVeRr1dYlaFSNrMRSYg52YhQzan6q5F1W6ga6y5mWVJ0 BsZT1HcGooQLqlrrAmihPUeHLpIyEicGduVfT5iEYgmT6XpJlxdrCZYgBEJ34i7XA+6nuVzUkKI 9QsMG/UZsOFI7kleCDqHzlFo/HQ3QezqT8Pl+uHucGCWNmIEYlj0tGvotN9pfqJ/awyg0Xq4881 gm9Zo8OyVEL7kaQpgH+iVoD+0HN/ldaf6gYNyaqQdRNq8aHTJLs+9yH5Qg68o49dckQ1tVMoaRv sd4SI4Hd9RnXpWm5RcJwFefchaAe7XfDlUMMFCmsyr5xIBoQz4pFqB+qHM5GHxwmP+TcAjCudNH vG+/1okfCx9gY7/V8z0fgs1Sfof7yjPC6Mfa2ZfV687nY7J99gXfhsi0++iDysiUJX3NLNY9Bsi 5ayWX0OQJ2kmg== X-Google-Smtp-Source: AGHT+IHCfUfEz0zjGeBNkTaQI9T8adA8nx2ruT58ln2fWEMITMGBHDYY6qhIlsTtG3dK+9dCOOqXxA== X-Received: by 2002:a05:600c:1991:b0:477:b48d:ba7a with SMTP id 5b1f17b1804b1-47d84b4119amr192870345e9.32.1768234118459; Mon, 12 Jan 2026 08:08:38 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2026 17:08:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() To: Anton Markov Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> <4a6b6307-9014-4c4c-8c23-3673efa2d1b1@gmail.com> <794c382b-3b20-4d2a-ab70-b24d7fdf88ae@suse.com> <4b03cf36-d2d8-420c-82df-55d6a9ac9d68@suse.com> <6ea436ce-6ecb-47f8-8d8a-98b0badeb14e@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.01.2026 15:51, Anton Markov wrote: > That's if IPIs are sent sequentially. In the most common case, they aren't, >> though - we use the all-but-self shorthand. > > Actually, even if IPIs are sent sequentially, I can't see where you spot >> this effect: Both callers of time_calibration_rendezvous_tail() signal all >> secondary CPUs to continue at the same time. Hence they'll all execute >> time_calibration_rendezvous_tail() in parallel. > > In parallel, but with a slight delay. > > Are they? I fear I don't know which part of the code you're talking about. > > In the function "time_calibration" (xen/arch/x86/time.c) Sorry, I don't > take into account that you don't stay in context, being distracted by other > threads. That calls on_selected_cpus(), but send_IPI_mask() may then still resort to all-but-self. In that case all IPIs are sent in one go. Plus as said, how IPIs are sent doesn't matter for the invocation of time_calibration_rendezvous_tail(). They'll all run at the same time, not one after the other. Since further down you build upon that "IPI lag", I fear we first need to settle on this aspect of your theory. Jan > One of the reasons we (iirc) don't do that is that since the scaling factor >> is also slightly imprecise, we'd prefer to avoid scaling very big values. >> IOW by changing as you suggest we'd trade one accumulating error for >> another. > > As I wrote above, there will be an error when using scale_delta, but it > won't accumulate between calls to time_calibration_rendezvous_tail. In the > current version, the old error (ipi lag + rounding error) persists due to > the use of the old local_stime in the get_s_time_fixed function, and it's > added to the new error and accumulates with each call. > If > > c->local_stime = get_s_time_fixed(old_tsc ?: new_tsc); > > replaced with: > > c->local_stime = scale_delta(old_tsc ?: new_tsc); > > Then we'll only be dealing with the error due to the current ipi lag and > rough rounding, within a single call. > > If I understand you correctly, you fixed the rough rounding of scale_delta > by reducing the values using get_s_time_fixed . But the problem is, that > didn't help. The error now accumulates gradually because we're relying on > old calculations. Furthermore, while the old rounding error was limited, > now the error accumulates infinitely, albeit very slowly. If this is so, > then the solution to the problem becomes less obvious. > > Roughly speaking, my servers start to go crazy after a week of continuous > operation, as the time lag between cores reaches 1 millisecond or more. > > On Mon, Jan 12, 2026 at 5:13 PM Jan Beulich wrote: > >> On 12.01.2026 13:49, Anton Markov wrote: >>>> Btw, your prior response was too hard to properly read, due to excess >> blank >>>> lines with at the same time squashed leading blanks. Together with your >>>> apparent inability to avoid top-posting, I think you really want to >> adjust >>>> your mail program's configuration. >>> >>> I suggest we skip the discussion of formatting and the number of spaces >> in >>> messages and instead focus on the topic of the thread. I have a very >>> difficult time troubleshooting difficult-to-reproduce bugs, and the fact >>> that their descriptions are difficult to read due to the number of spaces >>> is probably the least of the difficulties. >> >> Perhaps, yet it still makes dealing with things more difficult. >> >>> That invocation of get_s_time_fixed() reduces to scale_delta() (without >>>> further rdtsc_ordered()), as non-zero at_tsc is passed in all cases. IOW >>>> it's not quite clear to me what change you are suggesting (that would >>>> actually make a functional difference). >>> >>> Replacing get_s_time_fixed with scale_delta will remove the calculation >>> dependency on the previous local_stime value, which accumulates lag >> between >>> cores. This is because: rdtsc_ordered is not called synchronously on the >>> cores, but by the difference offset by the ipi speed. Therefore, we get: >>> >>> core0: current_rdtsc; >>> core1: current_rdtsc + ipi speed; >>> coreN: current_rdtsc + ipi speed * N; >> >> That's if IPIs are sent sequentially. In the most common case, they aren't, >> though - we use the all-but-self shorthand. >> >> Actually, even if IPIs are sent sequentially, I can't see where you spot >> this effect: Both callers of time_calibration_rendezvous_tail() signal all >> secondary CPUs to continue at the same time. Hence they'll all execute >> time_calibration_rendezvous_tail() in parallel. >> >>> Since ipi values are sent alternately in a loop to core0, >> >> Are they? I fear I don't know which part of the code you're talking about. >> >>> in the version >>> with get_s_time_fixed, we get the following local_stime calculation >> format. >>> >>> coreN: local_stime = local_stime + scale_delta((current_rdtsc + >> (ipi_speed >>> * N)) – local_rdtsc); >> >> One of the reasons we (iirc) don't do that is that since the scaling factor >> is also slightly imprecise, we'd prefer to avoid scaling very big values. >> IOW by changing as you suggest we'd trade one accumulating error for >> another. >> >> Jan >> >>> This means the time on each core will differ by ipi_speed * N. And since >>> we're using the values of the previous local_stime, the difference will >>> accumulate because the previous local_stime was also offset. In the >> version >>> with scale_delta, we get: >>> >>> coreN: local_stime = scale_delta(current_rdtsc + (ipi_speed * N)); >>> >>> This means there will still be a difference, but it won't accumulate, and >>> the offsets will remain within normal limits. >>> >>> If it's still unclear: If your local_stime in get_s_time_fixed is offset >>> relative to other cores, then the fact that rdtsc_ordered and local_tsc >> are >>> not offset doesn't change anything, since you're using the delta relative >>> to local_stime. >>> >>> core0_local_stime + (rdtsc_ordered() - local_tsc) != core1_local_stime + >>> (rdtsc_ordered() - local_tsc); // Even if rdtsc_ordered() and local_tsc >> are >>> equal across cores. >>> >>> On 96-core configurations, up to a millisecond of latency can accumulate >> in >>> local_stime over a week of operation, and this is a significant >>> difference. This >>> is due to the fact that I use cpufreq=xen:performance max_cstate=1 , >>> meaning that in my configuration, local_stime is never overwritten by >>> master_stime. >>> >>> Thanks. >> > From xen-devel-bounces@lists.xenproject.org Mon Jan 12 16:10:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 16:10:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200675.1516533 (Exim 4.92) (envelope-from ) id 1vfKVM-000305-KY; Mon, 12 Jan 2026 16:10:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200675.1516533; Mon, 12 Jan 2026 16: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 1vfKVM-0002zx-Hu; Mon, 12 Jan 2026 16:10:56 +0000 Received: by outflank-mailman (input) for mailman id 1200675; Mon, 12 Jan 2026 16:10:55 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfKVK-0002zp-Ug for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 16:10:55 +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 4293c955-efd1-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 17:10:49 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by PAXPR03MB7732.eurprd03.prod.outlook.com (2603:10a6:102:208::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Mon, 12 Jan 2026 16:10:47 +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.9499.005; Mon, 12 Jan 2026 16:10: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: 4293c955-efd1-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UHCF7UdKZahL3NotBmKm/M2w0iSOxuadM955wnAjp/IzFK+1Vm7QMQZ91h0Pvzgz7zYg/zCAAV8WDbdMCL1+c5aSaUKRv/WhOpX3wzYvMGGCBSnqA9CIldpYdDbdhNu9b0AleWdMBXpjL/JHggoPirZDyYmYP+cMJqQA2OsTNol3mg1tjgOcWAqr3vIX7RoY7BmVaykNKGgMuSdcjgctCZ65hIY/HvDq786MUrC2+gxqeW17T2Z5TwoQKhFUycgKtDgVo16lhypiXRjaoBV7aXe/8sYitI9B2N8maLrgWlwb0wV/Cul6dvBV20UEccnrf4X0Y6WR+ufUwOsigSS60Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3F2+mk0Oyw++ehCgnEpr6wttlxTm37blWi7nZ0c8SAw=; b=sRTUzk+msYa187xQ1WgCN7wCpzPdYfKbafAbU+0EdlyOBeLEON4R72Cu56f9qwmav8Y4CEGppyH6DWHWH44db0d+ZJtzH1R4OD42N2Rti+UGXtIoyo/jMeITMe2aEkGNxUEdZgrd4WDAVYnUc74ASjC6btx5qBjq3refk3cjRccuaGiEmPeAIz4YG9THrhKlWxwR2iBWpfUhLMpzSXxCatEny2mKm/k6KOVAqUbfegrwMOO7iFRohMOgWmzzqpLYULBBfiroLytmyNhqNgRWESesEbtMuzvIRtTEr4dVlmWmKsaxl24xwJ8IAvCa/xnGdTHY8ZiX4ju9ELV3PSg3Qw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3F2+mk0Oyw++ehCgnEpr6wttlxTm37blWi7nZ0c8SAw=; b=sn/+bj6UJW0mhRDiY3NSn28XFP52QMKdwSCSmufuEJtXaZJuEvRQWme353Yfpn0kK2bJ+ljfs0ZYojYZcPLGWnVFQCUtJrWeOAXwkdHoaAcBdbdW4ywl6deM/sDJY9Qqw2qld8+RcATGPCPeFlKUhYQ7+orOWdSLSLM4OKJ4tNkcNt+kYhXUGSp6i6RjpVcqQa8BJZrmVaV7PH1TddpFaCjrgVV7x/vE3brWeU72GO68OTA8DHWt6nGI4Ryh+aPhDwc3adci2V9jnhqwJJZOXqR4xK/5XenmKPmJrZfYxcR2uRGvBeQsSmvtEpSbUwv1LU+gE8Y/mbfSOS5L6YsWlw== From: Oleksii Moisieiev To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v6 1/5] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu Thread-Topic: [PATCH v6 1/5] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu Thread-Index: AQHcSyafS16SOr0Uk0OkeRdy8jd8CrVPHVoAgAADtoCAAACtAIAAA/oA Date: Mon, 12 Jan 2026 16:10:47 +0000 Message-ID: <9631b854-2fc6-41aa-8b12-1e7283b22246@epam.com> References: <9598b2e2-7df8-40c5-82cb-c097121af763@suse.com> <5d8f55a6-7182-4e9d-a139-96fddb9450f8@epam.com> <98f5e8f0-070c-4be5-9baf-46278de8093d@suse.com> <99586f5c-d76b-4cbe-9fbd-c87e86bb236a@epam.com> <7cbda859-4257-499e-86e0-a0d001fd49c9@suse.com> In-Reply-To: <7cbda859-4257-499e-86e0-a0d001fd49c9@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_|PAXPR03MB7732:EE_ x-ms-office365-filtering-correlation-id: 53a6b0c1-2515-4527-8b98-08de51f52598 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|7416014|366016|38070700021; x-microsoft-antispam-message-info: =?utf-8?B?aHBFTmhFZzB4L3RKa0hCQk12SEpLTi85UE1MSE00TmNxNk9NTi9HR2R2SFdx?= =?utf-8?B?NXBYcWNhVURvWjlMMXNHSGRNRVpBNkJFVlQrd2ErYUVaUHMwZHA3SEgwVDB4?= =?utf-8?B?VjY3cVNyZ3ZwYlo2dG5NY1RlYW5LUXNBTFU0ZUJzSmR4MTd6eFVZL2dHQ3ZN?= =?utf-8?B?MUlYd2dxNTR0MVkzc2JVbi9tME9kNFJVSUdtbTRvMGRzR3ZyT241c2ZxRWtq?= =?utf-8?B?S0ZEREhzY2JmV0xhYUxTdC9YR05XSUwzUE1JaTFaNUMxekRMOXZBWlczTG5n?= =?utf-8?B?Unhxbk5UZEFUcWtvMExaZVFtZVpLdEF4dXF0NHR3bStab0w0S2VMa1lnRDd6?= =?utf-8?B?MHhkMnZLVlFoT2RyanhUQm1VRlJia2Y2cVJ0TzBHcFVkY0YxQkd2Qm1CNUhj?= =?utf-8?B?cWI3dXIxSjd6d2pHWTd1bnQ5K1BqUk5tbkgyNEtFWXVPRmplc29zeVB1SGdW?= =?utf-8?B?SnhGVk52WXkvYTkwVi9JSTFhS3gxa2k0ZGNnVXVWc2xuSVFsaW1SYzc3cmpS?= =?utf-8?B?Qm5CcWJ0Y2xvSVkyTndBU2xJbVlJVThaSTVsL3BPajBPTi85MEIzM1lnWDZr?= =?utf-8?B?NFJna2hIMStWY21uL1lxT1I1dFFhOFhZay94cVJEMVlWSk5NbHhHdE1FZ0d2?= =?utf-8?B?dngyVEVYcXhUblhzUjVGSjZBOXV6N1k3a2h2TlhMMDFBK1VhWk8yeFhDYUxO?= =?utf-8?B?L0h2bVI2blFDMGx0aGlFdTdibG4xSmNjendOTUZKL3FQNWw1L1c2OHZYbkli?= =?utf-8?B?a2hmRmpFWFJpOEZHSnFac0V0cUJscjlSN0ZEUWtzaFpCZktFRE8zbldLUWJ6?= =?utf-8?B?NU1zNS9pOU4zcUM1cTJwdXlxQzA0MkZmaVBJaWJ4ZENJZ2FaMUZyN0JyUnpq?= =?utf-8?B?Rk1BYWhuZW1jQzQ5d2ZyVFREUlpIVnVhOGR2RVRJRGtkYWQ1d2ZlbnNLSGtH?= =?utf-8?B?ZnpScmx4MFNZVXNUV0IxL2Q3dzl1dUhmVDVFVmUwVm5POEI4aERmNlF1cmZS?= =?utf-8?B?ampWWVpWQ09tckNoaGZuQnhEVkt4UWlRWWRTTTJVdEdQaW8xUGs5WlJIOUdQ?= =?utf-8?B?UzZYYzY3SGtsY1RXNkZtd0lpcWRMQThDMWkzakNsY09YKzNVT0piRklNYVhL?= =?utf-8?B?RU8xekdEUEs2aWVXRGZjV0NFL0lpRkgxdnJDOStoZEFKN0Z6TjBqYldaRGRv?= =?utf-8?B?cS9sQUltM1JOb3V5M29NQW1kZDNxdm0yUDVGcHk2VktoYkY3NDlNTDBzbzIy?= =?utf-8?B?b2owZ29rVmpPNnM3dnk0ZXByYzlsbzMwQ1FNSUtGd05uNnlEZ0gxbEJvOWMv?= =?utf-8?B?blErSnRDLzRrZjFLVXZmanNobjNrTENtSDNiSG5RLzVYeFUvYWRsNmZ1MmVt?= =?utf-8?B?VnBzaGlRcWtCcWVtTVJKbStyWmVxT0daNTBiOVFUQlhac2Q2ZUZ3dU00SHVv?= =?utf-8?B?RVdwY2p4eVpWRXlyZDV0a2RLamlaTXltOEU1ZmthUTlqK2M5aFN1SmZOMzc1?= =?utf-8?B?VktVQnA2VUFJMktPU0hSSVNyS3A1T1RnUHBieGFiMEVGYmMyYllzazVza3Nn?= =?utf-8?B?OExvQ0JyYzdreG1pcCtGWVhWNlRYZVFianM1QmtJZDdQa29jWWVxeW1QeGNM?= =?utf-8?B?cGRIMkIwK25hTXZiYVRQZk51NHpxQTlkY1ZnYU9JNCtrZFJibVR0eG41bnp4?= =?utf-8?B?aTdtMzM2SVY1azVWaklKazJjV0h5UFhtc0MxYlpVQk52ZWt3Qitoak95MlJZ?= =?utf-8?B?Y3Jaa2YzR3FhYnkvU0pvYlJCMlFXVGFaZW1QMjEwNFIzQ3hzeFdpM1c1bCs1?= =?utf-8?B?MnNxVnlHWldTQ25kc1h1bnAveEVMYStVTmxzdkUwVkpEQzhIYWpkMVV1UWxw?= =?utf-8?B?dXRBYlR4UEFNWDlZcDI2ZGZKOVZlOVozaFdlVE1kNGtTeDRmcUg0S0lXTmQ2?= =?utf-8?B?WFdkMGtTbklUdjBSNXlpVUNmSTRwd054enM4VEZuWDl3TElmL21RMERsNWJF?= =?utf-8?B?cklZRFlGWS9zSVFRd0xPMDdUY294bGV0SXFZaGNZUEh2bUZqTmJuUW5RQTFE?= =?utf-8?Q?1aG93Q?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(366016)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Sm4vc0haRzZKK3V3V1ZWVVB2b1ZocXBoRjVaTWpsdWFXMUlsQ3VqbHltWXNE?= =?utf-8?B?R1o2a2pLcGZ4WnVqRThRV1llQlRyVk9GQytpcXJRTnpkcmh3bTlXRXNocklw?= =?utf-8?B?VTJRZS9nZlJaaUUvYVRqNmNvV3hTdk0xbXNCMTh4d2FNOHVXbU4xR0RIUVB3?= =?utf-8?B?ZTN6YXFFY29MSlQ4cFd5WUxEeWVXVitPK2tXdENmblU3UXNDemc4Z1ZtdjND?= =?utf-8?B?cUVYN093YU1UbHRob29HMmlNdHdUQnJRdWlwN0o5NG9tZ0hKSUdweTBqZEhm?= =?utf-8?B?Yis1QUx1MGJVRGIxaHllbms2ZHhmNUtMRnEycXgwSlB2dFY1bEt6cU53L3Bw?= =?utf-8?B?cHE0UVpiZkNZcDRlbUF4clpHSForWFZLMW9FTisxOTVlV21ma2U4K0pnbWVq?= =?utf-8?B?WW5tS1QySWVCNHFMTWNQMC9MdzE3VzB5bGRveXhPOW9ORmtrWDNBa3Q3aElT?= =?utf-8?B?SXV1eVZxVllZelZnMVBaSmF4WnB0OWdHdEp4WTN4RjhqS1VHeVdibkdlZDc3?= =?utf-8?B?Unc5bWtXaktxK3E3STNmYnZHT0xvNGtEbG5zYTZGT2EyV1VKRjNkaWNKMDZ5?= =?utf-8?B?ajU0dVU3dlBXV3RES2YwNDZZV2hBU0lrNTlpUEZtOTFmSlZna00zc3QrL0xt?= =?utf-8?B?R3h1dDNOZFYxVmRub1UxbXVndkJvWndpcnNEMEhmR0ZLd0hLSU0wZ2tOMDdS?= =?utf-8?B?WklkVFlEM3hueHR0RkEya0R1bEw0SFU4cWM5MVBCbURrODVyOTMvcmU5bUpY?= =?utf-8?B?azhjcndncDhrRmMzdkdWdkhmbEhHNmN2d1g2Ynk0MnlweTVvVXBMZ3o0TTg3?= =?utf-8?B?UVVUSmFXenp6ckVDVlFkK3VoM2F3MXN2TENFTGJjY2FvYWJ3WXFtMXptbHl6?= =?utf-8?B?NU9adUJ1d3R0YmNoR216Z3FoRnFYdE5tZEN6WEpTbGlsR1BNZmJpcWlZaXF6?= =?utf-8?B?VWpjNzhJUitDMFBCYmlzbzZtQ2k3N01Sc0dWUnI4VkliVFFTaDBrakUwZGlh?= =?utf-8?B?dnRGU0VadlZVQURPaDE0dzg0eDFGVG9tNkFHZFJCb2dxRll0RC96N1E3UFZD?= =?utf-8?B?R1NIYnBtblZ4bElhcjFWOTA1M0RPU0tMeXdPZjNabXBLUzNhQmUySVkyU1Zq?= =?utf-8?B?UFduMUsybkRCN2JBMlB2YWVUVlhzL0E1NVlXOHUvSU9uci94K3k4TFZFVndN?= =?utf-8?B?Z0g0MDdxTC85YUk1WjF4K2k4Rld1c2REWHozMk9NUnBXblRDYVd5bHZqQ1RG?= =?utf-8?B?VmhYU3hZUmNISW9td0NoMU0vOURuZ2JhOFJWSmw1anN2VHVkZlk2VTIvMDhw?= =?utf-8?B?M0RoWkQ3ai9NYnl5b3d1Q0FxQ0FGTU1qV084OUpXdHgrQ293VENpeUdybG1k?= =?utf-8?B?cjArYWFnZVRjNlpKcFNrdGtLUEd1cHV5dzVrUUdKa0t6OXBJRnh0SkNWMWc2?= =?utf-8?B?Qm9kYkJhenhHN0hyVnE0d00xTnlNL1U2QzM1eU9ld1BVbVdhZ2VuM2VVNVox?= =?utf-8?B?WGt2emxKbEdaejd4UWpRQmpnRi90SEw3bS9mYWsyUnM1dGFhZ2JJU3VHZEt2?= =?utf-8?B?Sm90eXNmZ2lldjBydGVtYTdNV2VHd0pnNGdSRncyZFUydXFBakhGcUkxcm9u?= =?utf-8?B?dk9USGl1aXZxdzNZWVhud1pmbjVzK2VuZ2h3NVRnUmJGM1g0MG8zR1VmNTM5?= =?utf-8?B?MVQ2WFNxQWFzaHEvV2JTRWRtWTZoTzNkL1F1ODRZUTJoSWtaODY4MkF2Vzhu?= =?utf-8?B?RVBWNXJWWi83ckxFbUEzVlRMbjBnV0x5dDZUNUxNVkxMTlBSdU5LUmM0SUZF?= =?utf-8?B?UnRnTkhORncrSUZJQVEwOWY0aUtiSVZ1UEtIOTk0K1ZkTFBrTWJWM2VOdW5i?= =?utf-8?B?MDB2cGtFYmpCVUo3RWt3KzliRnJqcmRPSlVyajRyMVJjL2ZpVnl5Y2xLM3hL?= =?utf-8?B?R3VhQ24wVlFaUnAvVXYxRGxFaEZXYnFoeFNVQmZUWG9hTTkrZEhKOTFiUWZM?= =?utf-8?B?U1FJZElmYlQ4aE5tTFBVRjlWbDFCU25XdzZpN25HRVdKYmQ5Qk05WjVyTFZr?= =?utf-8?B?SzQwTlI5akc5RVJaclhCVWlZemc0aUk3UDdqbklWNnR1SFFvVjYrUTVsblNH?= =?utf-8?B?OEwyNWI5a1FRZUJseDFPbTc0Nk1KbTl0c2dvMnJwTjF0VjNmbnlFZW1vZzQ3?= =?utf-8?B?R2ovNVpXNWFlZERKM0lzU1E5NTB5bFQxMWJZbThKR2oxblJTRFU1K0xqVnpy?= =?utf-8?B?UVlySjZna2puMG1GYVNsRUtZYi9HaFd0QTNaenlhWDdhTWh1bnJNeXBRMktG?= =?utf-8?B?V25yNUVxS0lNV3NvL3N4QmlGNEUyeWh5bjJISnhhTHF1RngxNTkvQUtLcVJP?= =?utf-8?Q?hmMx2uZnDQtJLGfo=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <5F0EE00AA70ECB45A352B0A89F7777C5@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: 53a6b0c1-2515-4527-8b98-08de51f52598 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2026 16:10:47.2260 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: p5vSvyD9k0394bDFv7L0cEktVmOfjvTFFED01UnCjaZASpF7x9LSuThk6QDyGCoF/vgr+uiDQAN2HpvYs9jBolDejJMwSRaljWu2sjilPmk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR03MB7732 DQoNCk9uIDEyLzAxLzIwMjYgMTc6NTYsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxMi4wMS4y MDI2IDE2OjU0LCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToNCj4+DQo+PiBPbiAxMi8wMS8yMDI2 IDE3OjQwLCBKYW4gQmV1bGljaCB3cm90ZToNCj4+PiBPbiAxMi4wMS4yMDI2IDE2OjE2LCBPbGVr c2lpIE1vaXNpZWlldiB3cm90ZToNCj4+Pj4gT24gMDYvMTEvMjAyNSAxMjowOSwgSmFuIEJldWxp Y2ggd3JvdGU6DQo+Pj4+PiBPbiAwMS4xMS4yMDI1IDEyOjU2LCBPbGVrc2lpIE1vaXNpZWlldiB3 cm90ZToNCj4+Pj4+PiBAQCAtODI3LDcgKzgyOCwzMiBAQCBsb25nIGRvX2RvbWN0bChYRU5fR1VF U1RfSEFORExFX1BBUkFNKHhlbl9kb21jdGxfdCkgdV9kb21jdGwpDQo+Pj4+Pj4gICAgICAgICBj YXNlIFhFTl9ET01DVExfdGVzdF9hc3NpZ25fZGV2aWNlOg0KPj4+Pj4+ICAgICAgICAgY2FzZSBY RU5fRE9NQ1RMX2RlYXNzaWduX2RldmljZToNCj4+Pj4+PiAgICAgICAgIGNhc2UgWEVOX0RPTUNU TF9nZXRfZGV2aWNlX2dyb3VwOg0KPj4+Pj4+ICsgICAgICAgIGludCByZXQxOw0KPj4+Pj4+ICsN Cj4+Pj4+PiArICAgICAgICAvKg0KPj4+Pj4+ICsgICAgICAgICAqIEFkZCBjaGFpbmVkIGhhbmRs aW5nIG9mIGFzc2lnbmVkIERUIGRldmljZXMgdG8gc3VwcG9ydA0KPj4+Pj4+ICsgICAgICAgICAq IGFjY2Vzcy1jb250cm9sbGVyIGZ1bmN0aW9uYWxpdHkgdGhyb3VnaCBTQ0kgZnJhbWV3b3JrLCBz bw0KPj4+Pj4+ICsgICAgICAgICAqIERUIGRldmljZSBhc3NpZ24gcmVxdWVzdCBjYW4gYmUgcGFz c2VkIHRvIEZXIGZvciBwcm9jZXNzaW5nIGFuZA0KPj4+Pj4+ICsgICAgICAgICAqIGVuYWJsaW5n IFZNIGFjY2VzcyB0byByZXF1ZXN0ZWQgZGV2aWNlLg0KPj4+Pj4+ICsgICAgICAgICAqIFRoZSBh Y2Nlc3MtY29udHJvbGxlciBEVCBkZXZpY2UgcHJvY2Vzc2luZyBpcyBjaGFpbmVkIGJlZm9yZSBJ T01NVQ0KPj4+Pj4+ICsgICAgICAgICAqIHByb2Nlc3NpbmcgcHJlc2VydmluZyByZXR1cm4gY29k ZSBhbmQgZXhwZWN0ZWQgdG8gYmUgZXhlY3V0ZWQgZm9yDQo+Pj4+Pj4gKyAgICAgICAgICogYW55 IERUIGRldmljZSByZWdhcmRsZXNzIGlmIERUIGRldmljZSBpcyBwcm90ZWN0ZWQgYnkgSU9NTVUg b3INCj4+Pj4+PiArICAgICAgICAgKiBub3QgKG9yIElPTU1VIGlzIGRpc2FibGVkKS4NCj4+Pj4+ PiArICAgICAgICAgKi8NCj4+Pj4+PiArICAgICAgICByZXQxID0gc2NpX2RvX2RvbWN0bChvcCwg ZCwgdV9kb21jdGwpOw0KPj4+Pj4gV2h5IHdvdWxkIHRoaXMgbm90IGJlIHRoZSBpbml0aWFsaXpl ciBvZiB0aGUgbmV3IHZhcmlhYmxlPyAoSSBhbHNvIGRvbid0IHRoaW5rDQo+Pj4+PiB0aGF0IHdl J3ZlIGRlY2lkZWQgdG8gcGVybWl0IHZhcmlhYmxlIGRlY2xhcmF0aW9ucyBhdCBvdGhlciB0aGFu IHRoZSB0b3Agb2YNCj4+Pj4+IHNjb3BlcyBvciB3aXRoaW4gZS5nLiBhIGZvcigpIGxvb3AgY29u dHJvbCBjb25zdHJ1Y3QuKQ0KPj4+Pj4NCj4+Pj4gKw0KPj4+Pj4+ICAgICAgICAgICAgIHJldCA9 IGlvbW11X2RvX2RvbWN0bChvcCwgZCwgdV9kb21jdGwpOw0KPj4+Pj4+ICsgICAgICAgIGlmICgg cmV0IDwgMCApDQo+Pj4+Pj4gKyAgICAgICAgICAgIHJldHVybiByZXQ7DQo+Pj4+PiBXaHkgd291 bGQgeW91IGludm9rZSBib3RoIGluIGFsbCBjYXNlcz8gSWYgc2NpX2RvX2RvbWN0bCgpIGhhbmRs ZWQgdGhlIHJlcXVlc3QsDQo+Pj4+PiB0aGVyZSBpc24ndCBhbnkgcG9pbnQgaW4gYWxzbyBpbnZv a2luZyBpb21tdV9kb19kb21jdGwoKSwgaXMgdGhlcmU/IE9yIGVsc2UgaXMNCj4+Pj4+IHRoZXJl IG1heWJlIHNvbWUgY3J1Y2lhbCBhc3BlY3QgbWlzc2luZyBmcm9tIHRoZSBkZXNjcmlwdGlvbiAo b3Igbm90IGV4cGxpY2l0DQo+Pj4+PiBlbm91Z2ggdGhlcmUgZm9yIGEgbm9uLVNDSSBwZXJzb24g bGlrZSBtZSk/DQo+Pj4+Pg0KPj4+Pj4gQWxzbyB0aGlzIGRvZXNuJ3QgbG9vayB0byBmaXQgdGhl IGRlc2NyaXB0aW9uIHNheWluZyAiVGhlIFNDSSBhY2Nlc3MtY29udHJvbGxlcg0KPj4+Pj4gRFQg ZGV2aWNlIHByb2Nlc3NpbmcgaXMgY2hhaW5lZCBhZnRlciBJT01NVSBwcm9jZXNzaW5nIC4uLiIN Cj4+Pj4+DQo+Pj4+IFdlIGNhbGwgYm90aCBiZWNhdXNlIFNDSSBhbmQgSU9NTVUgY292ZXIgZGlm ZmVyZW50IGNvbmNlcm5zIGFuZCBhIERUDQo+Pj4+IGRldmljZSBtYXkgbmVlZA0KPj4+PiBib3Ro OiBTQ0kgZm9yIEZXLW1lZGlhdGVkIGFjY2VzcyBjb250cm9sIChwb3dlci9jbG9ja3MvcmVzZXQp IGFuZCBJT01NVQ0KPj4+PiBmb3IgRE1BIGlzb2xhdGlvbi4NCj4+Pj4gU0NJIHJldHVybmluZyBz dWNjZXNzIGRvZXMgbm90IG1lYW4gdGhlIElPTU1VIHdvcmsgaXMgcmVkdW5kYW50Lg0KPj4+IENh biB0aGUgY29tbWVudCB0aGVuIHBsZWFzZSBiZSB1cGRhdGVkIHRvIHByb3Blcmx5IGNhbGwgb3V0 IHRoaXMgZHVhbA0KPj4+IHJlcXVpcmVtZW50Pw0KPj4gWWVzLCBmb3Igc3VyZS4NCj4+Pj4gLSBz Y2lfZG9fZG9tY3RsKCkgcmV0dXJucyAtRU5YSU8gd2hlbiBpdCBoYXMgbm90aGluZyB0byBkbyAo bm9uLURULCBubw0KPj4+PiBtZWRpYXRvciwgbWVkaWF0b3IgbGFja3MgYXNzaWduIGhvb2spLg0K Pj4+PiBUaGF0IGlzIHRoZSDigJxub3QgaGFuZGxlZCBieSBTQ0nigJ0gc2VudGluZWw7IGluIHRo YXQgY2FzZSB0aGUgY29kZQ0KPj4+PiBwcm9jZWVkcyB0byBJT01NVSBub3JtYWxseS4NCj4+Pj4g LcKgIFdoZW4gc2NpX2RvX2RvbWN0bCgpIHN1Y2NlZWRzICgwKSwgdGhlIGRldmljZSBtYXkgc3Rp bGwgcmVxdWlyZSBJT01NVQ0KPj4+PiBwcm9ncmFtbWluZw0KPj4+PiAoZS5nLiwgRFQgZGV2aWNl IGhhcyBhbiBpb21tdXMgcHJvcGVydHkpLiBTa2lwcGluZyBpb21tdV9kb19kb21jdGwoKQ0KPj4+ PiB3b3VsZCBsZWF2ZSBETUEgaXNvbGF0aW9uIHVucHJvZ3JhbW1lZC4NCj4+Pj4NCj4+Pj4gVGhl IGZpbmFsIGlmIChyZXQxICE9IC1FTlhJTykgcmV0ID0gcmV0MTsgZW5zdXJlcyB0aGF0IGlmIGJv dGggcGF0aHMgcmFuDQo+Pj4+IGFuZCBJT01NVSBzdWNjZWVkZWQsDQo+Pj4+IGFuIFNDSSBmYWls dXJlIGlzIHN0aWxsIHJlcG9ydGVkIHRvIHRoZSBjYWxsZXIuDQo+Pj4+DQo+Pj4+IERldmljZS10 cmVlIGV4YW1wbGVzIHRvIGlsbHVzdHJhdGUgdGhlIGR1YWwgcm9sZXM6DQo+Pj4+IDEuIEFjY2Vz cy1jb250cm9sbGVkIERUIGRldmljZSAobm90IG5lY2Vzc2FyaWx5IElPTU1VLXByb3RlY3RlZCk6 DQo+Pj4+DQo+Pj4+IGkyYzM6IGkyY0BlNjUwODAwMCB7DQo+Pj4+ICAgIMKgwqDCoCBjb21wYXRp YmxlID0gInJlbmVzYXMscmNhci1nZW4zLWkyYyI7DQo+Pj4+ICAgIMKgwqDCoCByZWcgPSA8MCAw eGU2NTA4MDAwIDAgMHg0MD47DQo+Pj4+ICAgIMKgwqDCoCBwb3dlci1kb21haW5zID0gPCZzY21p X3BkIDU+O8KgwqDCoMKgwqAgLy8gRlctbWFuYWdlZCBwb3dlciBkb21haW4NCj4+Pj4gICAgwqDC oMKgIGNsb2NrcyA9IDwmc2NtaV9jbGsgMTI+Ow0KPj4+PiAgICDCoMKgwqAgY2xvY2stbmFtZXMg PSAiZmNrIjsNCj4+Pj4gICAgwqDCoMKgIGFjY2Vzcy1jb250cm9sbGVycyA9IDwmc2NtaV94ZW4g MD47DQo+Pj4+ICAgIMKgwqDCoCAvLyBubyBpb21tdXMgcHJvcGVydHk6IFNDSSBtYXkgbmVlZCB0 byBhdXRob3JpemUvcG93ZXIgdGhpcyBkZXZpY2U7DQo+Pj4+IElPTU1VIGhhcyBub3RoaW5nIHRv IGRvDQo+Pj4+IH07DQo+Pj4+DQo+Pj4+IDIuIElPTU1VLXByb3RlY3RlZCBEVCBkZXZpY2UgdGhh dCBzdGlsbCBtYXkgbmVlZCBTQ0kgbWVkaWF0aW9uOg0KPj4+PiB2cHU6IHZpZGVvQGU2ZWYwMDAw IHsNCj4+Pj4gICAgwqDCoMKgIGNvbXBhdGlibGUgPSAicmVuZXNhcyxyY2FyLXZwdSI7DQo+Pj4+ ICAgIMKgwqDCoCByZWcgPSA8MCAweGU2ZWYwMDAwIDAgMHgxMDAwMD47DQo+Pj4+ICAgIMKgwqDC oCBpb21tdXMgPSA8JmlwbW11IDAgMD47wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIC8vIG5lZWRz IElPTU1VIG1hcHBpbmcgZm9yIERNQQ0KPj4+PiBpc29sYXRpb24NCj4+Pj4gICAgwqDCoMKgIHBv d2VyLWRvbWFpbnMgPSA8JnNjbWlfcGQgNz47wqDCoMKgwqDCoCAvLyBGVy1tYW5hZ2VkIHBvd2Vy L2Nsb2NrL3Jlc2V0DQo+Pj4+ICAgIMKgwqDCoCBjbG9ja3MgPSA8JnNjbWlfY2xrIDM0PjsNCj4+ Pj4gICAgwqAgwqAgYWNjZXNzLWNvbnRyb2xsZXJzID0gPCZzY21pX3hlbiAwPjsNCj4+Pj4gICAg wqDCoMKgIGNsb2NrLW5hbWVzID0gInZwdSI7DQo+Pj4+IH07DQo+Pj4+Pj4gLS0tIGEveGVuL2Ry aXZlcnMvcGFzc3Rocm91Z2gvZGV2aWNlX3RyZWUuYw0KPj4+Pj4+ICsrKyBiL3hlbi9kcml2ZXJz L3Bhc3N0aHJvdWdoL2RldmljZV90cmVlLmMNCj4+Pj4+PiBAQCAtMzc5LDYgKzM3OSwxMiBAQCBp bnQgaW9tbXVfZG9fZHRfZG9tY3RsKHN0cnVjdCB4ZW5fZG9tY3RsICpkb21jdGwsIHN0cnVjdCBk b21haW4gKmQsDQo+Pj4+Pj4gICAgICAgICAgICAgICAgIGJyZWFrOw0KPj4+Pj4+ICAgICAgICAg ICAgIH0NCj4+Pj4+PiAgICAgDQo+Pj4+Pj4gKyAgICAgICAgaWYgKCAhZHRfZGV2aWNlX2lzX3By b3RlY3RlZChkZXYpICkNCj4+Pj4+PiArICAgICAgICB7DQo+Pj4+Pj4gKyAgICAgICAgICAgIHJl dCA9IDA7DQo+Pj4+Pj4gKyAgICAgICAgICAgIGJyZWFrOw0KPj4+Pj4+ICsgICAgICAgIH0NCj4+ Pj4+PiArDQo+Pj4+Pj4gICAgICAgICAgICAgcmV0ID0gaW9tbXVfYXNzaWduX2R0X2RldmljZShk LCBkZXYpOw0KPj4+Pj4+ICAgICANCj4+Pj4+PiAgICAgICAgICAgICBpZiAoIHJldCApDQo+Pj4+ PiBIb3cgYXJlIERUIGFuZCBQQ0kgZGlmZmVyZW50IGluIHRoaXMgcmVnYXJkPw0KPj4+PiBQbGVh c2UgZmluZCBleGFtcGxlcyBhYm92ZS4NCj4+PiBTb3JyeSwgYnV0IEkgY2FuJ3Qgc3BvdCBhbnl0 aGluZyBQQ0ktaXNoIGluIHRoZSBleGFtcGxlcyBhYm92ZS4gVGhlbiBhZ2FpbiBJDQo+Pj4gYWxz byBubyBsb25nZXIgcmVjYWxsIHdoeSBJIGNvbXBhcmVkIHdpdGggUENJIGhlcmUuIE9oLCBwZXJo YXBzIGJlY2F1c2UgdGhlDQo+Pj4gUENJIHNpZGUgaXNuJ3QgYmVpbmcgbW9kaWZpZWQgYXQgYWxs Lg0KPj4+DQo+PiBDb3JyZWN0LCBwY2kgY29kZSB3YXNuJ3QgdG91Y2hlZCBieSB0aGVzZSBjaGFu Z2VzLg0KPiBZZXQgbXkgcXVlc3Rpb24gYm9pbHMgZG93biB0byAid2h5Iiwgbm90ICJ3aGV0aGVy Ii4NCj4NCj4gSmFuDQpJIGhhdmUgcmV2aWV3ZWQgdGhlIHByZXZpb3VzIHZlcnNpb25zIG9mIHRo ZSBwYXRjaCBzZXJpZSBhbmQgY291bGQgbm90IA0KZmluZCBhbnkgcXVlc3Rpb25zIHJlbGF0ZWQg dG8gUENJIHByaW9yIHRvIHRoaXMgc2VyaWVzLiBUaGVyZWZvcmUsICJIb3cgDQphcmUgRFQgYW5k IFBDSSBkaWZmZXJlbnQgaW4gdGhpcyByZWdhcmQ/IiBhcHBlYXJzIHRvIGJlIHRoZSBmaXJzdCAN CnF1ZXN0aW9uIGNvbmNlcm5pbmcgUENJLg0KDQpCUiwNCk9sZWtzaWkuDQo= From xen-devel-bounces@lists.xenproject.org Mon Jan 12 16:13:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 16:13:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200691.1516542 (Exim 4.92) (envelope-from ) id 1vfKXZ-0003gk-3Z; Mon, 12 Jan 2026 16:13:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200691.1516542; Mon, 12 Jan 2026 16: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 1vfKXZ-0003gd-0O; Mon, 12 Jan 2026 16:13:13 +0000 Received: by outflank-mailman (input) for mailman id 1200691; Mon, 12 Jan 2026 16:13: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 1vfKXX-0003gT-Ku for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 16:13:11 +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 966f5574-efd1-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 17:13:10 +0100 (CET) Received: by mail-wm1-x344.google.com with SMTP id 5b1f17b1804b1-47d493a9b96so38067555e9.1 for ; Mon, 12 Jan 2026 08:13:10 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d86c6ff40sm291223085e9.2.2026.01.12.08.13.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 08:13:09 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 966f5574-efd1-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768234389; x=1768839189; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=jx1dZXRM1A0pEJ3m/5Bxc2ZGwDlTpl7OLP4BEe21ByE=; b=M93MwTtcATpdGfV6Au96V8lvQN8nYcqwyV5WFZczFcjCgVKTCnqQ+FlibYjhW6oJKF J62uLaHfp1WcWhvuCGvGSCmPD27DIPPJZjSqvukiAqqYoGeA6k4fjuKcnvm4XgaYop/Y tiV6MbW1+xljmiJ3Z/jH3Avss6jGwVyndsK+pupztnFMRRpBasL4gog2ncq7uzEcnWnv KtJ9aSGcSW0K+8L/biLCqnY3RhgCpkxbvNTmtGJ0O1oRFnKoLYwMQicSXR9eVl4sZCTX Xf7ADe7Pol1rvbeNhmFlYEUVqoYFtclm+ySRGP47sMZnBmVnbhprDULaeXZX3c6LyYUq GCEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768234389; x=1768839189; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=jx1dZXRM1A0pEJ3m/5Bxc2ZGwDlTpl7OLP4BEe21ByE=; b=GB+UqOUoN4swLo67vS0HUtIuWXZ1K7pz8/V524TyDVeb7KhTN5T6+krUjkjm09JhDf aW4vKDCdfIkTI6bEZneXqs46oDNwOr41kdew9SUzEC0OGm4+46pUId+tQOvq42blhCVJ UW5vwyDDZLcXLzRVXibIWrFWvjpRKTaHgLFpGz04J0M5mY0cdUMeLDYvfMUwIj3M7hSO T9vEuN3ltmhIOX8ff1kkvN9s0QgtAX0lVN/CdQ0Xq0pPRtH3IWDFxMEj5wl0+OOzuDtm 5fLN2O0KGJyDcitUnLbspzi3K74tC93Dkfrg6jXGycUFFbGQ9cF4cTsuW8IVUBFz1zNS nDww== X-Forwarded-Encrypted: i=1; AJvYcCUwZblLDCM1Ee51h53MeDUjb6v/YGv2lqo5oeq2DLmhNBUnI4jAT6G47O30BByUp9ySbofp2+04PlU=@lists.xenproject.org X-Gm-Message-State: AOJu0YyDex46TdQ6vnF1kwbfGxeCGaUIklle9SyH7rVccy6zkCB4O0fU lMr7AwEROYlwTI6QAkMtoDlf5F5IYW6n2S8NNxXc9P+oMsUpR5DZaALoOT0/AXyt6A== X-Gm-Gg: AY/fxX59Xx0t4UYQrcsGSyXDcKxPNue424pJ2obJgJtVkhbmJBwV6VrCBHAsaVNGVke 7e9Gd/+mVtSr2pK4vZ9c6NMCphT5jLFq6uSNkaHpr6Ll4VLvLoImL3K2asD8BwH0iSoi8dHStej GOrTE3cSbRSkD/CuIT4/V0jvsrZWt8S3OqpDi1nSiLeaHMK4PiWaWUPiqAl5sF6JqSQZOnAOMBX O5U3sFrMhCQ6GjHmeThWcv3zRAelbWURZtMke9DpdyEKI4tBhcQkj50MMkOuMBZC3+Yv9qes7QF qCNNret4YGE49nZ4+CzghOFvzl5hJHib7WFpxsSGgmzNQJeUboG1pwOWnOa+5i5t6VYARyfluY7 FIwNbHmfJJ9WQiAPUwN+zhRKgyuWjV2iEz7KBpOR2U1vvA9PN2+2QHr5PLi4RHjVvwpAj6K+wG6 ZmnzisaHpfvcVYLq745dkGUZXUPHZpYOqiuFnMcIReo9lyy73ArosQsiCD17gUjtbIWhciiUJu2 M4= X-Google-Smtp-Source: AGHT+IG7OfI3kF7k5L6BdMMoWGOlBt7rjBV4OS/a2u6qsQacWVCQxvU6rqJyS30j1JAOWROLj1Z5Gg== X-Received: by 2002:a05:600c:1e24:b0:475:de14:db1e with SMTP id 5b1f17b1804b1-47d84b36a1emr225505175e9.24.1768234389443; Mon, 12 Jan 2026 08:13:09 -0800 (PST) Message-ID: <4807d2d3-fae7-45a4-b7c7-e101a95a6b58@suse.com> Date: Mon, 12 Jan 2026 17:13:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/5] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu To: Oleksii Moisieiev Cc: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" References: <9598b2e2-7df8-40c5-82cb-c097121af763@suse.com> <5d8f55a6-7182-4e9d-a139-96fddb9450f8@epam.com> <98f5e8f0-070c-4be5-9baf-46278de8093d@suse.com> <99586f5c-d76b-4cbe-9fbd-c87e86bb236a@epam.com> <7cbda859-4257-499e-86e0-a0d001fd49c9@suse.com> <9631b854-2fc6-41aa-8b12-1e7283b22246@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: <9631b854-2fc6-41aa-8b12-1e7283b22246@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12.01.2026 17:10, Oleksii Moisieiev wrote: > On 12/01/2026 17:56, Jan Beulich wrote: >> On 12.01.2026 16:54, Oleksii Moisieiev wrote: >>> On 12/01/2026 17:40, Jan Beulich wrote: >>>> On 12.01.2026 16:16, Oleksii Moisieiev wrote: >>>>> On 06/11/2025 12:09, Jan Beulich wrote: >>>>>> On 01.11.2025 12:56, Oleksii Moisieiev wrote: >>>>>>> @@ -827,7 +828,32 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) >>>>>>> case XEN_DOMCTL_test_assign_device: >>>>>>> case XEN_DOMCTL_deassign_device: >>>>>>> case XEN_DOMCTL_get_device_group: >>>>>>> + int ret1; >>>>>>> + >>>>>>> + /* >>>>>>> + * Add chained handling of assigned DT devices to support >>>>>>> + * access-controller functionality through SCI framework, so >>>>>>> + * DT device assign request can be passed to FW for processing and >>>>>>> + * enabling VM access to requested device. >>>>>>> + * The access-controller DT device processing is chained before IOMMU >>>>>>> + * processing preserving return code and expected to be executed for >>>>>>> + * any DT device regardless if DT device is protected by IOMMU or >>>>>>> + * not (or IOMMU is disabled). >>>>>>> + */ >>>>>>> + ret1 = sci_do_domctl(op, d, u_domctl); >>>>>> Why would this not be the initializer of the new variable? (I also don't think >>>>>> that we've decided to permit variable declarations at other than the top of >>>>>> scopes or within e.g. a for() loop control construct.) >>>>>> >>>>> + >>>>>>> ret = iommu_do_domctl(op, d, u_domctl); >>>>>>> + if ( ret < 0 ) >>>>>>> + return ret; >>>>>> Why would you invoke both in all cases? If sci_do_domctl() handled the request, >>>>>> there isn't any point in also invoking iommu_do_domctl(), is there? Or else is >>>>>> there maybe some crucial aspect missing from the description (or not explicit >>>>>> enough there for a non-SCI person like me)? >>>>>> >>>>>> Also this doesn't look to fit the description saying "The SCI access-controller >>>>>> DT device processing is chained after IOMMU processing ..." >>>>>> >>>>> We call both because SCI and IOMMU cover different concerns and a DT >>>>> device may need >>>>> both: SCI for FW-mediated access control (power/clocks/reset) and IOMMU >>>>> for DMA isolation. >>>>> SCI returning success does not mean the IOMMU work is redundant. >>>> Can the comment then please be updated to properly call out this dual >>>> requirement? >>> Yes, for sure. >>>>> - sci_do_domctl() returns -ENXIO when it has nothing to do (non-DT, no >>>>> mediator, mediator lacks assign hook). >>>>> That is the “not handled by SCI” sentinel; in that case the code >>>>> proceeds to IOMMU normally. >>>>> -  When sci_do_domctl() succeeds (0), the device may still require IOMMU >>>>> programming >>>>> (e.g., DT device has an iommus property). Skipping iommu_do_domctl() >>>>> would leave DMA isolation unprogrammed. >>>>> >>>>> The final if (ret1 != -ENXIO) ret = ret1; ensures that if both paths ran >>>>> and IOMMU succeeded, >>>>> an SCI failure is still reported to the caller. >>>>> >>>>> Device-tree examples to illustrate the dual roles: >>>>> 1. Access-controlled DT device (not necessarily IOMMU-protected): >>>>> >>>>> i2c3: i2c@e6508000 { >>>>>     compatible = "renesas,rcar-gen3-i2c"; >>>>>     reg = <0 0xe6508000 0 0x40>; >>>>>     power-domains = <&scmi_pd 5>;      // FW-managed power domain >>>>>     clocks = <&scmi_clk 12>; >>>>>     clock-names = "fck"; >>>>>     access-controllers = <&scmi_xen 0>; >>>>>     // no iommus property: SCI may need to authorize/power this device; >>>>> IOMMU has nothing to do >>>>> }; >>>>> >>>>> 2. IOMMU-protected DT device that still may need SCI mediation: >>>>> vpu: video@e6ef0000 { >>>>>     compatible = "renesas,rcar-vpu"; >>>>>     reg = <0 0xe6ef0000 0 0x10000>; >>>>>     iommus = <&ipmmu 0 0>;             // needs IOMMU mapping for DMA >>>>> isolation >>>>>     power-domains = <&scmi_pd 7>;      // FW-managed power/clock/reset >>>>>     clocks = <&scmi_clk 34>; >>>>>     access-controllers = <&scmi_xen 0>; >>>>>     clock-names = "vpu"; >>>>> }; >>>>>>> --- a/xen/drivers/passthrough/device_tree.c >>>>>>> +++ b/xen/drivers/passthrough/device_tree.c >>>>>>> @@ -379,6 +379,12 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d, >>>>>>> break; >>>>>>> } >>>>>>> >>>>>>> + if ( !dt_device_is_protected(dev) ) >>>>>>> + { >>>>>>> + ret = 0; >>>>>>> + break; >>>>>>> + } >>>>>>> + >>>>>>> ret = iommu_assign_dt_device(d, dev); >>>>>>> >>>>>>> if ( ret ) >>>>>> How are DT and PCI different in this regard? >>>>> Please find examples above. >>>> Sorry, but I can't spot anything PCI-ish in the examples above. Then again I >>>> also no longer recall why I compared with PCI here. Oh, perhaps because the >>>> PCI side isn't being modified at all. >>>> >>> Correct, pci code wasn't touched by these changes. >> Yet my question boils down to "why", not "whether". >> > I have reviewed the previous versions of the patch serie and could not > find any questions related to PCI prior to this series. Therefore, "How > are DT and PCI different in this regard?" appears to be the first > question concerning PCI. Quite possible, yet does that somehow eliminate the need to address it? I'm trying to understand why the respective PCI code isn't being touched. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 16:15:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 16:15:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200701.1516553 (Exim 4.92) (envelope-from ) id 1vfKa2-0004Ec-FR; Mon, 12 Jan 2026 16:15:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200701.1516553; Mon, 12 Jan 2026 16:15: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 1vfKa2-0004EV-Ck; Mon, 12 Jan 2026 16:15:46 +0000 Received: by outflank-mailman (input) for mailman id 1200701; Mon, 12 Jan 2026 16:15: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 1vfKa1-0004EP-5o for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 16:15:45 +0000 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [2a00:1450:4864:20::332]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f20fed4a-efd1-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 17:15:43 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-477619f8ae5so49119765e9.3 for ; Mon, 12 Jan 2026 08:15:43 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ede7esm40100612f8f.32.2026.01.12.08.15.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 08:15:42 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f20fed4a-efd1-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768234543; x=1768839343; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=uEkmx1T5Cp99HNbDPXu+PpKGAcURXg7oy00l4aR8aKs=; b=VZEyZ/LIatXRIVdsTT0crGNaLdKiTrFW/0E+rvq5cxYzxNjqC3B0f8qF5eAvyz1v/5 yqpg4F7OoVvtDQzoTPTU+vdLrejq/tgMLPvBG+y8yAejEnLrd86vPlp6AZuW9Y32gO6p av4R1n2jxSXZNil9mCJgjRXR5Whu5uhYmngqF6D0SyjilzFyE2WwcnUJiK7UDCdJsFBf kDgGny/m/aSRk3LzdEglhOwW0wj/gD90EOdWqiHqgS7R/uaiQOwG390f4iZQQ+kNElUG wXwd3tpMxe6MTeQF4N1j4B8AbCK0GWDXeH0ckhhMbuV0LRqd50Rox37ivZKZ0A4G8EB8 rnQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768234543; x=1768839343; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uEkmx1T5Cp99HNbDPXu+PpKGAcURXg7oy00l4aR8aKs=; b=h2mzCnDrr9DlsA+ILwVe7m4Fon9+l3n9WtFF1W1zrjCnbz1BlKT5id3ImofWITjyxx q+hAtZdYYPucbDidxU01jfUQ2sca2zpWMZIBw99qakM/A93oCLJ4l8rIRG3o2MdnAVzW ewkY1h+pKOPFGWuHBJCdHrhVaVDzCTGouh98zdcpb7KYzO8UkYUA4Hf8Qk4XzPH0IDQs LBULvgXYYGjPS8wAkDeCBYCq2LpTqoLFMVbrseyy4JmCoF2uUysXPzltnjv261RG6Hzf 1XBu7y/h0RScuLWXKHR/ToHSy8kNJNh+GHIXlzt2+bXpFjbkc2Al4E+C34xVKd4+K/It 3TQw== X-Forwarded-Encrypted: i=1; AJvYcCXnCyjEh6R1dX+aBwZNWABeEj/MKBKr7olibLQTDoVNbNEgpSioLwkxddLJFLLcYl/L9uv3oiQ8loY=@lists.xenproject.org X-Gm-Message-State: AOJu0YwvUO1haYyPNyhvuyadMiO2Y4Gw3PlBYdkmvz5QxRIqEsMoQBz8 cgGuxe28Nwo0yWt3UdfMK4QGxXPYwzhw2vqhWsnCBv8EQhAAP66ey6mt7s3DrVCfYw== X-Gm-Gg: AY/fxX6ttH51LWVCI5a6vd5s1JQuyjlemrZAcE+WXbEP7UiUl8fm+VzOP9tW9udn/Im dR+Rg9rfYuy6PjY7jxlrTrdt9l2qnO/tHzvfBTKUKeZt2+YYfDWn2ukMDKN6N/9yY3i0gkMLR3s cF/w56XTsAzTZuf6+KzBnqtrIma8tqkavukitLxfSDkBBIneVr5ulV2RrbuiY81DIIVD7xumZ4K YJBOvdXKewg0WW7AZB40DEyFRENDg4LRhm2znYLaa9FOF55eCyFGs0INFd2ebufOIpyqaje5MWf kyvAhYrwq9D/g0lY7aq9NY0D8SClnD/pzgb4LWHowZIOEwIz0XdSDUO2XQZbNSwZjWoptsNSeJp 8L1DYT1iDvTuZ91+IlQPHGhfhePUzDXIpzsmlKXwV5KgFMryjpV1+7HBsYi78/ev/DeH36swYAH 1y8tRgOuD5yayQviAu/8pOhlU5PFXjjFn5FeaZ6DFoPz1qa+hyiJ2xdv7krzpGNfbfpitdYZ5kc UvxMYfHiWgRXQ== X-Google-Smtp-Source: AGHT+IFCt6DfzOJNDSYT9mOIyBwixze053Gvn3sQg4YqObZyG+yXKeJkOrLsgoff8RIdFJ8pXWVOiA== X-Received: by 2002:a05:600c:46cb:b0:47a:810f:1d06 with SMTP id 5b1f17b1804b1-47d84b26da4mr203601915e9.4.1768234543117; Mon, 12 Jan 2026 08:15:43 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2026 17:15:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 14/15] xen/riscv: handle hypervisor timer interrupts To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 24.12.2025 18:03, Oleksii Kurochko wrote: > @@ -108,6 +109,15 @@ static void do_unexpected_trap(const struct cpu_user_regs *regs) > die(); > } > > +static void timer_interrupt(unsigned long cause) > +{ > + /* Disable the timer to avoid more interrupts */ > + csr_clear(CSR_SIE, BIT(IRQ_S_TIMER, UL)); > + > + /* Signal the generic timer code to do its work */ > + raise_softirq(TIMER_SOFTIRQ); > +} Why is "cause" being passed when it's not used? Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 16:20:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 16:20:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200714.1516562 (Exim 4.92) (envelope-from ) id 1vfKef-00060m-W3; Mon, 12 Jan 2026 16:20:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200714.1516562; Mon, 12 Jan 2026 16: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 1vfKef-00060f-T7; Mon, 12 Jan 2026 16:20:33 +0000 Received: by outflank-mailman (input) for mailman id 1200714; Mon, 12 Jan 2026 16:20: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 1vfKef-00060X-08 for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 16:20:33 +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 9d134c8d-efd2-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 17:20:30 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-4779adb38d3so45473775e9.2 for ; Mon, 12 Jan 2026 08:20:30 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0e180csm38499723f8f.10.2026.01.12.08.20.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 08:20:29 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9d134c8d-efd2-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768234830; x=1768839630; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=OwSWM+LVf9aA20YwA1MIlGX5Irhs0FNaE8nTqtAkxek=; b=O96b+jFHGO3fWyLuInwNPfXK9HxUWng78KjtFZ5bivb0u8vA4gU/YgLmGHqeszFxxR Y9csdAuENYXgPLj9cEG0hjpbMKKVSKC/hJi1OgYuOTZhiXSNlNUMR4lxhUlfbNP9GgB/ zE51e6r8tWS+Qczid9sFFmnnnpRqbE0cdZYj26YXbxTcoO7rZDm0TT+H0m23DzkDNhno El6yl/nfQ4DRoZ9CWGkiZkNZ7/xBGgJdQ2BolIbN5NAxagylIkJ0NjHuiroEbuzd1sWk E0d57ECaj73aKTpvVS8xVo+lBV96sr48FzNPh7jYBEYLnJaCSBataoVwjb0Et6+o5fJ1 jmrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768234830; x=1768839630; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=OwSWM+LVf9aA20YwA1MIlGX5Irhs0FNaE8nTqtAkxek=; b=I6LF8uijO5DS5rDlKcFl5dFcR3iLqdR6kKmpoP/UDjl/GVx5emeOX/amAFubqsu+FO LBF/IqfSzxTRZvq8pW7ZhYNHRrThzS33gaBO+KMRbI4a5fZH0AuhyXhKzFir1opjRwjU Goo+lw+8goIEFhNGFC+ER7wz3ZoNv2DQG9eQzt0RKgozn65kW8+ViChIHN8GqJR8XGux mqfqcRt5RY7AvT71qRwEXkFl8Z/fAUdAIrKems+s5ZGa7+kizYD8vATBSfCulyXIEsGg gBnY52MfO8KU+pY5LHLRFcmgjCWn+ANVlWkQNtKMB9DG43IneHQq9GlQUnhTmBYAB39r WwGQ== X-Forwarded-Encrypted: i=1; AJvYcCXAS0QlbiLrFC3sY5WoqTbpcdNdoTSW7Td441ZssWEsAdwMrBB2GLVjZurKlu54gdkFyEnfYiUov/0=@lists.xenproject.org X-Gm-Message-State: AOJu0YyPTSqpIBaYhD5EB2LUffscz+0/UDDl1+6Osa7n/VvG51jPf5og 2hcNmsoj/75YksgPKpu0whmOYWds81NOuP4SJCIv4mXkDzs/T2FmKfVlzHIpiWZpnw== X-Gm-Gg: AY/fxX5NMnFl0CirNG3FmihaoxDmi9VJTHki6frbNL5p64bL9RxAr7ZIA8xbA/k5LH7 PqkSs9szw7fjDrO6tHIB4SWGMMqpQSbs8qBHVOW6qaYtRygddHgQM4H6IdF/m6kLPrVWqA6/omr 7sEXftpKa+Ku7cEH6y/KDVG7VuuEOGuXdwPvXlIlRMV0cnAkD7ijz+jFRcq2Ay1IpUqNolSTCh/ VqEQHPh7/HmSHyql9c/hzyZxqeThkUfNKQIzlFtVC4RhSOqbxpwCSgb/vtqDUuXKWgGUHBNq6y6 ru0p9Fj5Nx9XZopngJrs5jRlanF8QaUy4NHyyFwkq3TXQ11sO6gHVTNJemjr2wtWzcQcCGSADMU i3DaIHVwgpMPPn3d87VuD47oEeNerQ4TpNYCzbrquHWpqg9K/J91DraiPcjQnuWmLDmPZa4Opkq J9jRSUaoBmfHShE3jESxvWG9li0DpzyRJAWXPGOWON0KNprcMUxtLXYJqC3vkEk6+6J7N91rJO4 gA= X-Google-Smtp-Source: AGHT+IEyZ5yNm6NKEk+9HdQWcXylAU8xwJPOWfOUdQkk3QOe23d8NgDCBL0IPn+vJuo80ulwR4k2Ew== X-Received: by 2002:a05:600c:4ed4:b0:471:d2f:7987 with SMTP id 5b1f17b1804b1-47d84b40ae5mr214895275e9.26.1768234830161; Mon, 12 Jan 2026 08:20:30 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2026 17:20:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 15/15] xen/riscv: init tasklet subsystem 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: <7fd154cda45466ca4bd425bc05d191caccc7d96d.1766595589.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: <7fd154cda45466ca4bd425bc05d191caccc7d96d.1766595589.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 24.12.2025 18:03, Oleksii Kurochko wrote: > As the tasklet subsystem is now initialized, it is necessary to implement > sync_local_execstate(), since it is invoked when something calls > tasklet_softirq_action(), which is registered in tasklet_subsys_init(). > > After introducing sync_local_execstate(), the following linker issue occurs: > riscv64-linux-gnu-ld: prelink.o: in function `bitmap_and': > /build/xen/./include/xen/bitmap.h:147: undefined reference to > `sync_vcpu_execstate' > riscv64-linux-gnu-ld: ./.xen-syms.0: hidden symbol > `sync_vcpu_execstate' isn't defined > riscv64-linux-gnu-ld: final link failed: bad value How that when ... > --- a/xen/arch/riscv/stubs.c > +++ b/xen/arch/riscv/stubs.c > @@ -91,16 +91,6 @@ void continue_running(struct vcpu *same) > BUG_ON("unimplemented"); > } > > -void sync_local_execstate(void) > -{ > - BUG_ON("unimplemented"); > -} > - > -void sync_vcpu_execstate(struct vcpu *v) > -{ > - BUG_ON("unimplemented"); > -} ... there was a (stub) implementation? (The code changes look okay, it's just that I can't make sense of that part of the description.) Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 16:28:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 16:28:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200725.1516574 (Exim 4.92) (envelope-from ) id 1vfKma-0006sM-Oc; Mon, 12 Jan 2026 16:28:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200725.1516574; Mon, 12 Jan 2026 16: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 1vfKma-0006sF-Ka; Mon, 12 Jan 2026 16:28:44 +0000 Received: by outflank-mailman (input) for mailman id 1200725; Mon, 12 Jan 2026 16:28: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 1vfKmZ-0006s9-US for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 16:28:44 +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 c23f83f4-efd3-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 17:28:42 +0100 (CET) Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-64b9b0b4d5dso13783725a12.1 for ; Mon, 12 Jan 2026 08:28:42 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6507bf6d5d4sm18008906a12.32.2026.01.12.08.28.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 08:28:41 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c23f83f4-efd3-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768235322; x=1768840122; 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=rE6yV5imzukGfSPD6lBGrgoUU53xvGqUNYJYiiMKies=; b=fzMa+Q5A10Uol5bRpsODSmehEG0uAGOzRFfT9juUVOYCwwJ8r0xKJe9MCj3cI6n8nr HG002rKyFTimecyaFTjJkutaltj8QsGS3HOMgXV3U2kkMmK/QTK9dftd6KrUSFOFx3mr dwg81bguX4zwu+CtRpUjdFTols4leE6xSAbxRhdmRvAvq03a4VpQiD2eDP6K9IELogij KYG5n+ARfQBcHppT/qOZ/jU7cpWv5hQDlo/qoB+qiHcFdCTu/sOe/lHNofXFzECInxwb gY9s6pt/PmjHLZjEuFu7J1xiBMYeePKSw6pQjcmoJ9sYp/vo3RnZdfKzznDKTlyN6tp+ y35Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768235322; x=1768840122; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rE6yV5imzukGfSPD6lBGrgoUU53xvGqUNYJYiiMKies=; b=iDICxVzt/aRChoUww5Ce5IIqWNkCxgbWjWTDAyBitBtxL4ZCHOS+HlydpbE5CkZCUA h95QC9k29OQKAOWnUSiM1GajD+Pi0/C/IXg4Z+e967/71EmJ1XGyyoZwWLHOLlE6DXmc lOFY82RaipaDgBFUcODVE6MSeXDgQSzOBGyC/t2/KcWOKhWwIV88pXsUiFjFtvO3hpTd bip4bmwZP1yBSMz3CbobQncINhZrwEc7EOpSaUmnZyROZosqSXBlOUokDKyJmW42+X2p qeGtdVk4JLKU4cTdNAVnp9cPpzS4hg+eeNTvz8hT48QXv0PJDEzmhiLTSnRJbYJ5eaLU Byzg== X-Forwarded-Encrypted: i=1; AJvYcCXe25XwNmKlo7KLWpJ1aPj/wWeF4UYIejXtSTSsIO27eoOPX2vSJJlo9jje1GJ7m7/mtAJhH6gAd84=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx0VQ14qTIffb+ASn19a4PZnP9n0nfkHZ5ZYrKlh0u87VsJgecz 1HVEFQsqG8oUK7cpVXl9cK0KCrkwR1mPn+JmAAe3YyU7m9QujAdEEcUK X-Gm-Gg: AY/fxX7nG/fEvSBuVfBIhFdG4B+O2TS4mpS92qQwpKj/3TifTP0z2TumAbfDH8VZZ1y kLvRy29ysIgrQJkMvIDXc4jkPqHxcmW3jcFGoMAWfjc3RaZMzTL5AjHmy/NzI4gN+ZVMNtx7g+i nTLel9w1o16alMeb2fEBkwuHlTWs699rlHbTbgZ1xXtfo7ZuyPiPHEU98y57WYHlmrZkYIX4MXo sROKwMtvGpx/6nasGlNtiMrqhiHr2/2iAGq6DFUpO09DT90lcWSAx3nimKU3a5aAmwPUCx7pW2Z 8CjzyY1fd8RA9r3EJ9nL3owZbsb3dHrreDcsCL183HPglmNKgOiYGP3Ae34Pab+2INsJOtY4ske zAGK/w/5P5sg7nvDM4rDVaseBwRBS8tKQnDXE+gcfQfw0hXD4tsJjbHS5E+d7ljD9w7sIwJ4ndA QgL+wxuxz9r3UTHZFRt5sRytzASNpMESTYkmBCIw/p4cIWg84sNOMXpVOTNdCJ6TU= X-Google-Smtp-Source: AGHT+IFoAhvsg2/W5nDRaxMO1muF8GQxquWD77duxoXlrb1wnVj6s8wnXEg+WP45cdQTYc9IGQFOFQ== X-Received: by 2002:a17:907:e10d:b0:b87:205c:1aa7 with SMTP id a640c23a62f3a-b87205c1d96mr226774466b.44.1768235321702; Mon, 12 Jan 2026 08:28:41 -0800 (PST) Message-ID: <131d5d1d-f13c-486a-beac-59f7f7b45606@gmail.com> Date: Mon, 12 Jan 2026 17:28:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 04/15] xen/riscv: introduce vtimer 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: <94ffc70d3050e532290126560355dc548161f466.1766595589.git.oleksii.kurochko@gmail.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 1/7/26 4:21 PM, Jan Beulich wrote: > On 24.12.2025 18:03, Oleksii Kurochko wrote: >> Introduce a virtual timer structure along with functions to initialize >> and destroy the virtual timer. >> >> Add a vtimer_expired() function and implement it as a stub, as the timer >> and tasklet subsystems are not functional at this stage. > Shouldn't those pieces of infrastructure be made work then first? It could be an option; it’s just not really critical until a guest is running. I actually considered adding this in the current patch series, but decided to introduce it later to avoid making the series too large. (On the other hand, it would be only one additional patch, IIRC) > I also > don't quite understand why the subsystems not being functional prevents > the function to be implemented as far as possible. Most if not all > functions you need from both subsystems should be available, for living > in common code. I chose the wrong words here; this is not the main (that some subsystems isn't fully functional) reason why I’m using a stub here instead of something functional. Basically, implementing this requires vcpu_kick() and vcpu_set_interrupt(), which are introduced later in this patch series. As an alternative, I could drop vtimer_expired() and the related code from this patch and reintroduce them after vcpu_kick() and vcpu_set_interrupt() are available. > >> --- a/xen/arch/riscv/include/asm/domain.h >> +++ b/xen/arch/riscv/include/asm/domain.h >> @@ -8,6 +8,7 @@ >> #include >> >> #include >> +#include >> >> struct vcpu_vmid { >> uint64_t generation; >> @@ -52,6 +53,9 @@ struct arch_vcpu >> struct cpu_info *cpu_info; >> void *stack; >> >> + struct vtimer vtimer; >> + bool vtimer_initialized; > Assuming the field is really needed (see remark further down), why is this > not part of the struct? Agree, it would be better to have it as a part of struct vtimer if it will be used in future. > >> --- /dev/null >> +++ b/xen/arch/riscv/include/asm/vtimer.h >> @@ -0,0 +1,25 @@ >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> +/* >> + * (c) 2023-2024 Vates >> + */ >> + >> +#ifndef ASM__RISCV__VTIMER_H >> +#define ASM__RISCV__VTIMER_H >> + >> +#include >> + >> +struct domain; >> +struct vcpu; > I don't think this one is needed, as long as you have ... > >> +struct xen_arch_domainconfig; >> + >> +struct vtimer { >> + struct vcpu *v; > ... this. Question is why this is here: You should be able to get hold of the > struct vcpu containing a struct vtimer using container_of(). Good point, I haven't thought about that. It could really be done using container_of(). > >> --- /dev/null >> +++ b/xen/arch/riscv/vtimer.c >> @@ -0,0 +1,39 @@ >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> + >> +#include >> + >> +#include >> + >> +#include >> + >> +int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config) >> +{ >> + /* Nothing to do at the moment */ >> + >> + return 0; >> +} > The function has no caller and does nothing - why do we need it? It will be called later in arch_domain_create(). It will be needed if SSTC extension will be supported but could be dropped now. > >> +static void vtimer_expired(void *data) >> +{ >> + panic("%s: TBD\n", __func__); >> +} >> + >> +int vcpu_vtimer_init(struct vcpu *v) >> +{ >> + struct vtimer *t = &v->arch.vtimer; >> + >> + t->v = v; >> + init_timer(&t->timer, vtimer_expired, t, v->processor); >> + >> + v->arch.vtimer_initialized = true; > init_timer() has specific effects (like setting t->function to non-NULL > and t->status to other than TIMER_STATUS_invalid). Can't you leverage > that instead of having a separate boolean? (Iirc we do so elsewhere.) Nice, it could be used instead of having vtimer_initialized in struct vtimer. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Jan 12 16:38:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 16:38:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200743.1516583 (Exim 4.92) (envelope-from ) id 1vfKw4-0000K2-NA; Mon, 12 Jan 2026 16:38:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200743.1516583; Mon, 12 Jan 2026 16: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 1vfKw4-0000Jv-KB; Mon, 12 Jan 2026 16:38:32 +0000 Received: by outflank-mailman (input) for mailman id 1200743; Mon, 12 Jan 2026 16: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 1vfKw3-0000Jp-Mr for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 16:38:31 +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 207e7bfc-efd5-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 17:38:30 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-42fbad1fa90so5687016f8f.0 for ; Mon, 12 Jan 2026 08:38:30 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ede7esm40211880f8f.32.2026.01.12.08.38.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jan 2026 08:38:28 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 207e7bfc-efd5-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1768235909; x=1768840709; 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=fsYepr6llrngVjLksK/0nWVIboj9pVEDeNz8G0+4fyE=; b=VuMsmwmuKz2Uxp6l86/YUn+YsPQ2oyajA3z6x8+a5Mp3NbUjmVJIYRTr3PpyultnLR sQUqRQRXbvbckg7gCPorbpjaoUgwGotpczvk3kCBL0H/8iLe2A9QVZijGCED5gryfYI0 3e5q/ajmbZB7H5cHwJFXpI1oDSYmEgXR2o7ms= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768235909; x=1768840709; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=fsYepr6llrngVjLksK/0nWVIboj9pVEDeNz8G0+4fyE=; b=Ro29pcRKtYVLUVNtTKDMAyiHxSwrtP4gBfs0ylhwnDijwhSTO513jFTBycEMjMq9X0 XOKRAHMggcP6mQtcUz9kzIgQ4OmE7AV8T0nBnZnnE/abgSUtAkk5g6BZcmNJ8tfnaRLm gW5qCTIXsfI6ezP/6WP1Y/hDdKnHzD+y77kMJhaRRgOirV2BhV6tRnVvwf31RFQ+/um5 EDl32r1nfynYP4nfQ6soEXu0R0aTPzLPMANQNru062Lq87CBo8whwxLDk5Ud1lWweXQj yrFTyLK8niGxfVAmo5xpM14RHQUeVo441qNMziS1xB06bDGIMEKHmpdzInPnM4RxQi7D gFlw== X-Gm-Message-State: AOJu0Yx4aOnk+t4/EyFDYo/wuwWEiKNtxu8+4KFhFc9OrhNnWnNrHTq5 K6ftPvTZAcjuz3L77VN52b+x29B6mH7AcE19CvG7C5FK1C2VNF5IP6vfdidhQ6PNNotJJF1U416 Hz+f5 X-Gm-Gg: AY/fxX7IxErCA8koxWhqNQ5yhVxXlYhwdIrQz5cFaCAYGNEHbHpf9wM9n27LskkgbbU n+lOF+cFxjzc7JnIOW/LS0TeDzEd6QVdO8dhuty5oDwQcdWTSx+DykmdOyx5xNiVdQWCpS6hMgH CLZuHUhHptXR6BEV3fhh0culzR1iQImxUJwbWg/hgxFbN+3Dc9/iAXayim7mldvG/sPIFqbH06b ppGAR/tdckyygHOzDqhzzyX8kPAwij07J4Vhfsl9q/TA0h+nhg541D/ZNvgaEAXmsj+5zKhmcVC VSFIeamq7wTn/JYj9a43hXYEH0sjMitd2Q02fLkisdXClmyCxEBUgMpah8WNR7FAh4o+yjTm0hP Btt0LCRXo1LIvvNqs1kjSQjjALslbrPMMzAm2UbPo8XJ+3RFLH+YIThMhLCSj3Nyzp6NZ0Fae9l 2W3LpIPxPNPZJOjT1zzOSbmOiS60Ro4fq2IuGWbMa9lUS5eyrwbT8Zu8U6WEyw/w== X-Google-Smtp-Source: AGHT+IF/EszdEveiQaMQPb3vAjwk8ur1K4N+LjI2wMVNroSCVFnZJScXibk+stQVA0GwNGl2jR3EPg== X-Received: by 2002:a05:6000:2c0c:b0:42b:55a1:2158 with SMTP id ffacd0b85a97d-432c378fc28mr20892435f8f.17.1768235909252; Mon, 12 Jan 2026 08:38:29 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Nicola Vetrini Subject: [PATCH] CI/randconfig: Disable CONFIG_CONDITION_COVERAGE Date: Mon, 12 Jan 2026 16:38:27 +0000 Message-Id: <20260112163827.1023401-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 In addition to GCC not liking x86_emulate(), it turns out that Clang is still rather more a work in progress than a usable feature, causing failures in the FreeBSD builds: https://cirrus-ci.com/task/5934059060199424 Exclude CONFIG_CONDITION_COVERAGE from Ranconfig until it gets a bit more stable. 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: Nicola Vetrini --- xen/tools/kconfig/allrandom.config | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/tools/kconfig/allrandom.config b/xen/tools/kconfig/allrandom.config index f04b589a80af..8127ebb57090 100644 --- a/xen/tools/kconfig/allrandom.config +++ b/xen/tools/kconfig/allrandom.config @@ -1,2 +1,2 @@ # Explicit option choices not subject to regular RANDCONFIG - +CONFIG_CONDITION_COVERAGE=n base-commit: a2a34d76643e49ccc949296c9a45888034e50b55 -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 12 16:39:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 16:39:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200751.1516593 (Exim 4.92) (envelope-from ) id 1vfKx6-0000qL-0P; Mon, 12 Jan 2026 16:39:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200751.1516593; Mon, 12 Jan 2026 16: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 1vfKx5-0000qE-Td; Mon, 12 Jan 2026 16:39:35 +0000 Received: by outflank-mailman (input) for mailman id 1200751; Mon, 12 Jan 2026 16:39:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfKx4-0000pm-UO for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 16:39:34 +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 4678d6e4-efd5-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 17:39:34 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-b87124c6295so191498766b.3 for ; Mon, 12 Jan 2026 08:39:34 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b873051cc88sm85181066b.7.2026.01.12.08.39.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 08:39:32 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4678d6e4-efd5-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768235973; x=1768840773; 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=f6Ibodr9gIUr10HeyX4IOp2enq6/vYD5VI+IHDt8lqQ=; b=YrCar92Ji9Qx4oiZXxbTKN2wPaqMuUYz3k2XINg6Hew62efvIfXssB72Vulxo5FcUH KU1GLzwrsBb+Bie++lSQDz9cInTvRQDEG4ombDciqhpT3UUWnZ378eAZ3s4a/hPzck+H rM2J8uYrTGP6mqmyDI+/rhHRTMp6u4RzUcv2GcktUVrq+ef+Tdxk9/4nogRqfJeM9dmt 9ggd28Rg8Ek/3AhcKBe7yC55s/rQqW7EsDZZ66AfuDU8COFDfbo+bWByGutcLcO5itLu SYczfnY3rz7QwaPjDXdbgA9R+w9czdXv06kxW3YQCrvp7IOn/9vmDfFi4Q8GA1ReLe7j uNcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768235973; x=1768840773; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=f6Ibodr9gIUr10HeyX4IOp2enq6/vYD5VI+IHDt8lqQ=; b=D/4LZHVlDmW4gBZil1q8BlgHYyhzxFczmFwGNAIPW4YdI20q7AvE4gc5sOi2M2m2HP WZEIbQuklU9JfHU/SW5uDp80xvfjvH++OQtcanXWyxxDHYn2SGpVvKecD7TITSAnL+d+ kAOo1e5y/HBo+2zr3c7Z1DOxFZdOP2AbKXay2/iXWdBdshXBbVyTlmBueAIq0fWoudsy kCyLe/X/EV45NkvR+N+0dAo/YAABVUo59haFI9fFldvKpqIF+btHjnc0ANK1S/PxkOJ8 3X1mumYgrBYTKHpHu1/qw09ScGl2eFniWkAGDJIEzpaLDEwKmhU3bzbtIWXO/Iiy16wm TQ6A== X-Forwarded-Encrypted: i=1; AJvYcCUu/p2goDYTIhWUOf+06xfwYKE+UB/3B0VXmNumnarO2xUcWxAc+pT8oy04/DJpELLRTWZKVvp24zI=@lists.xenproject.org X-Gm-Message-State: AOJu0YxHe/uaxxLI5aBkzHvk5LfLgUvwXNqpjZBPBenreGf8sfEyLGgY AsjM/IYZwVRSbtrE+3gY5/38vssSxgTvV9UCGTTz1wUFpB6WbRVLpWnb X-Gm-Gg: AY/fxX4+zPfyT9h1HAMgNI3fgLaL9M5DjvJxJijLh2Vt6riCnxF+jJowVc+BKORVeBB t1L3xdQxTWUSDEi5rxsW9omL8rwXCCzfDfVkWoIQQipJy64TlBz10NW9CereZhAJC4C/dF+GeQ3 1+f7pWn0v4nD1+XZGx50WAvPEe0J37tmUqyE/ziuaw+g4i+MJNOEv92NfEY3vCMM/7cblRvpCW8 nXz7ISiiA7EbGDlNTuRnQCUP2b0yIo57WcwWL3u5tNZHaV0A/T54qN5BV5OS76AKn6N7qEQm9Jh 9jdHb4DnQtBFyffqOCXzHF4PXHgz64gI88DyECEjqmWjmo39NE9x8ztKBfb67gKppHsY9UG9iQD 9swsdBSCK3EwFDI9i+4hkqltxExHTeEUG0leGzbxDKqqhEnmKOf95P69vyuvaNNn46WRWodD89y MpVZ3znPrOBoNUj2n37vU5252T9kb+W+QipI0s5qpAyLY8jVW+jP104XkLlOBQxWM= X-Google-Smtp-Source: AGHT+IGnBIbf+pwz7VWcODCXvnB8m1R5rLQj1iCmfgvOuKYyLxGUzKJUVkzHnqJlc8YjXfJdxAUQUw== X-Received: by 2002:a17:907:94cc:b0:b87:124c:5f54 with SMTP id a640c23a62f3a-b87124c62dbmr470287966b.59.1768235973035; Mon, 12 Jan 2026 08:39:33 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2026 17:39:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 03/15] xen/riscv: implement vcpu_csr_init() 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: <7ba4bcfe-59d3-43f3-adb4-207424dc1713@gmail.com> <988ba581-5503-45d4-a621-18cdc3b14cab@gmail.com> <30dbd0b0-2a2b-4064-b39c-4dfa438af15b@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <30dbd0b0-2a2b-4064-b39c-4dfa438af15b@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/12/26 4:54 PM, Jan Beulich wrote: > On 12.01.2026 16:46, Oleksii Kurochko wrote: >> On 1/12/26 3:28 PM, Jan Beulich wrote: >>> On 12.01.2026 13:59, Oleksii Kurochko wrote: >>>> On 1/7/26 9:46 AM, Jan Beulich wrote: >>>>> Also, wouldn't you better keep internal state in line with what hardware >>>>> actually supports? CSRIND may be read-only-zero in the real register, in >>>>> which case having the bit set in the "cached" copy can be misleading. >>>> [...] >>>> >>>>> (This may similarly apply to at least hedeleg and hideleg, btw.) >>>> Regarding the previous bits, I can understand that it would be an issue: >>>> if SSAIA isn’t supported, then it is incorrect to update the corresponding >>>> bits of|hstateen0|. >>>> >>>> However, I’m not really sure I understand what the issue is with|h{i,e}deleg|. >>>> All writable bits there don’t depend on hardware support. Am I missing something? >>> My reading of the doc was that any of the bits can be r/o 0, with - yes - >>> no dependencies on particular extensions. >> Just to be sure that I get your idea correctly. >> >> Based on the priv. spec: >> Each bit of hedeleg shall be either writable or read-only zero. Many bits of >> hedeleg are required specifically to be writable or zero, as enumerated in >> Table 29. >> >> Now let’s take hedeleg.bit1, which is marked as writable according to Table 29. >> Your point is that even though hedeleg.bit1 is defined as writable, it could still >> be read-only zero, right? >> >> In general, I agree with that. It is possible that M-mode software decides, for >> some reason (for example, because the implementation does not support delegation >> of bit1 to a lower mode), not to delegate medeleg.bit1 to HS-mode. In that case, >> hedeleg.bit1 would always be read-only zero. >> >>> In which case you'd need to do >>> the delegation in software. For which it might be helpful to know what >>> the two registers are actually set to in hardware (i.e. the cached values >>> wanting to match the real ones). >> Does it make sense then to have the following >> ... >> v->arch.hedeleg = hedeleg; >> vcpu->arch.hedeleg = csr_read(CSR_HEDELEG); >> in arch_vcpu_create()? > The above makes no sense to me, with or without s/vcpu/v/. Right... It should be also csr_write() before csr_read(): csr_write(CSR_HEDELEG, hedeleg); v->arch.hedeleg = csr_read(CSR_HEDELEG); > >> Or I can just add the comment that it will be sync-ed with the corresponding >> hardware CSR later as ,actually, there is some h{i,e}deleg synchronization >> happening during context_switch() (this code is at the moment in downstream), >> because restore_csr_regs() is executed and re-reads CSR_H{I,E}DELEG: >> static void restore_csr_regs(struct vcpu *vcpu) >> { >> csr_write(CSR_HEDELEG, vcpu->arch.hedeleg); >> csr_write(CSR_HIDELEG, vcpu->arch.hideleg); >> ... >> As a result, vcpu->arch.h{I,E}deleg is kept in sync with the corresponding >> hardware CSR. > No, the r/o bits will continue to be out-of-sync between the hw register and > the struct arch_vcpu field. Yes, it would be out-of-sync until|save_csr_regs()| is called, where |csr_read(CSR_HEDELEG)| is executed. So the value remains out-of-sync until a trap to the hypervisor occurs and a vCPU context switch happens, which triggers |save_csr_regs()|. So that’s not an option. The best choice is the one mentioned above. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Jan 12 16:41:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 16:41:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200762.1516603 (Exim 4.92) (envelope-from ) id 1vfKzI-0002L7-DM; Mon, 12 Jan 2026 16:41:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200762.1516603; Mon, 12 Jan 2026 16:41:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfKzI-0002L0-AV; Mon, 12 Jan 2026 16:41:52 +0000 Received: by outflank-mailman (input) for mailman id 1200762; Mon, 12 Jan 2026 16:41: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 1vfKzH-0002Ku-0D for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 16:41:51 +0000 Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [2607:f8b0:4864:20::102a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 964531ff-efd5-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 17:41:48 +0100 (CET) Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-34c3cb504efso5160110a91.2 for ; Mon, 12 Jan 2026 08:41:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 964531ff-efd5-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768236107; x=1768840907; 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=LmQxRaEfTzRUlFieKT5pobgQa+TD62w/YBtexOYyobY=; b=AyY9rUXTRke+oJ5CgKe5svf+KUOU+o1QMVTvBn8TWFWKatDXYFJasrUWO8AEpF5O4s HSflnd0s5n+DHXJuts8RXbglMzQEnWqrhDumQ66gvx6lhwD42TalwrfKmJwFcLDOxtzL QaJSB/gb8cNr4xo081PTKIVStml81kMOaELcdw0DyFIxR+S+UOo0ee0FuwYN24XLLg02 QREyMxDd7PneweqPi2ZxpDJMiaIi4tM3R6iLXcJj6xfGtcZSA/oIEJyB3bGUkQ+6BRhL +gph7dqHD4QaNSqfS8yjV+Bzmg7i/tkOeeq4g9i+KWCvT6yPOoS8XU+OXfJft+jjj2MC GA9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768236107; x=1768840907; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=LmQxRaEfTzRUlFieKT5pobgQa+TD62w/YBtexOYyobY=; b=pI8s7mzfDQikk66o4ELdwMHwg0HbEwp0tqCSiBMUydGcSvxGienG5cX5IXIN0myqup k5xehKI80oWqxP/NlAmW2wnbP3vvcIKnfx5Rw1KW52XUcs18bLQDBbHN6YT5OUKx7cYw a9HyrD9ennpdKlNdbgUMRdSRlphbSgg5Fm+FtqW93QTNGirbwjtDj9+En7tipawT0M5w Wx49Kv+5Rp40eL4hD0shx4eKA2IaDkqAQphRAMMl+S+h16p/71eA9RP1+Ce7F/i522xV O2Dk3hrEP8V8tJt0DTMwELblA3AsfMwqtHSgvRQQkHjxkQvi/GBX1NNtA3xuivTxPazB kJkQ== X-Forwarded-Encrypted: i=1; AJvYcCVSR9OVr3UcozI7WCZpwq6qV/gHmtJyzP4sCop5Z6ArOeQm5umaNpee0avrQmrNLcd9qpMvFXNoxgg=@lists.xenproject.org X-Gm-Message-State: AOJu0YzZU3e/HogD0bWQnKTPTyRmsS8I0QrQNC2L/PfgZKZlkA+0avDs GvjWbImEFEfsNpNESbB/f2t3M32bCyuKkG014tXF8A9DOTQsQC52xY8mvWcN1+ovBrOiPir/+TJ YIibKuCoADJJWnEvhHgYZ+RYc13SUyag= X-Gm-Gg: AY/fxX73auJjCNJ2SosEHuY9EHrMSxojnRu8h4KZRVtERabwUOTVn5fQ2I/EPoFTnld zQ374I9kUrZ0ehvW6XlBRbI5AxIboL5pYpUc0OHn4PV5+Ws1AAgJLytAGaMMLWIGeXDIVOS6BN9 ho6o0fPHQH065sRubSzGSk/sG6Ah/CTCp9pSukAdOBVH9M8gW/Vp8Q/dK0x8+Zt5lpdtgCEvzzo xKU5OGLq7dEhx7ivulyZnKKAurzj43W4/eKHzssU1d6aBn95Jc3lagZ+QX+rRgzTFy4PZNKRBco BMO7wRw= X-Google-Smtp-Source: AGHT+IFlPDAli0uXr8IAVaKgjql6bSoNIJofERIyICw5d7P0xyQfwr+VtJWCUUunM2q2vLmC7m0D71tjwDB86+YbsIM= X-Received: by 2002:a17:90b:4f92:b0:343:f509:aa4a with SMTP id 98e67ed59e1d1-34f68d3b229mr17293008a91.36.1768236106847; Mon, 12 Jan 2026 08:41:46 -0800 (PST) MIME-Version: 1.0 References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> <4a6b6307-9014-4c4c-8c23-3673efa2d1b1@gmail.com> <794c382b-3b20-4d2a-ab70-b24d7fdf88ae@suse.com> <4b03cf36-d2d8-420c-82df-55d6a9ac9d68@suse.com> <6ea436ce-6ecb-47f8-8d8a-98b0badeb14e@suse.com> In-Reply-To: From: Anton Markov Date: Mon, 12 Jan 2026 19:41:35 +0300 X-Gm-Features: AZwV_QjPU3l-_ebHzf2wMLw_kWIk4rQxmVrKxU_xWi48ezWuWDoghQInI6IaLHE Message-ID: Subject: Re: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() To: Jan Beulich Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000071bf40648338dfc" --000000000000071bf40648338dfc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > That calls on_selected_cpus(), but send_IPI_mask() may then still resort = to > all-but-self. In that case all IPIs are sent in one go. Plus as said, how IPIs are sent doesn't matter for the invocation of > time_calibration_rendezvous_tail(). They'll all run at the same time, not > one after the other. At the hardware level, no one can guarantee that the processors will simultaneously respond to the signal and execute your code nanosecond after you send the ipi. Especially when we're talking about NUMA configurations. = I'm afraid the possible and impossible in the laws of physics is also beyond the scope of this thread. Since further down you build upon that "IPI lag", I fear we first need to > settle on this aspect of your theory. I've already provided the delay logs. It's not hard for me to repeat. The patch: > @@ -1732,6 +1753,8 @@ static void cf_check local_time_calibration(void) > > if ( boot_cpu_has(X86_FEATURE_CONSTANT_TSC) ) > > { > > /* Atomically read cpu_calibration struct and write cpu_time struct. */ > > + printk("update stime on time calibrate %d, %lu -> %lu (%lu, %lu)\n", > smp_processor_id(), t->stamp.local_stime, c->local_stime, > > + t->last_seen_ns, t->last_seen_tsc); > > local_irq_disable(); > > t->stamp =3D *c; > > local_irq_enable(); > 2 hours of work: > (XEN) update stime on time calibrate 0, 8564145820102 -> 8565145861597 > (8565145862216, 0) > (XEN) update stime on time calibrate 1, 8564145820129 -> 8565145861609 > (8565145863957, 0) > (XEN) update stime on time calibrate 3, 8564145819996 -> 8565145861491 > (8565145864800, 0) > (XEN) update stime on time calibrate 2, 8564145820099 -> 8565145861609 > (8565145865372, 0) > > 8565145861609 - 8565145861491 =3D 115 * 3 (3.00 GHz) =3D 345 lag > 3 hours of work: > (XEN) update stime on time calibrate 0, 22914730829200 -> 22915730869993 > (22915730870665, 0) > (XEN) update stime on time calibrate 1, 22914730829073 -> 22915730869889 > (22915730870693, 0) > (XEN) update stime on time calibrate 2, 22914730829052 -> 22915730869841 > (22915730872231, 0) > (XEN) update stime on time calibrate 3, 22914730828892 -> 22915730869696 > (22915730872096, 0) > > 22915730869993 - 22915730869696 =3D 297 * 3 (3.00 GHz) =3D 891 lag > 2-3 day of work: > (XEN) update stime on time calibrate 0, 254477161980127 -> 25447816202092= 0 > (254478162021549, 0) > (XEN) update stime on time calibrate 2, 254477161977638 -> 25447816201842= 9 > (254478162022187, 0) > (XEN) update stime on time calibrate 1, 254477161978192 -> 25447816201897= 2 > (254478162022776, 0) > (XEN) update stime on time calibrate 3, 254477161976832 -> 25447816201763= 6 > (254478162021394, 0) > > 254478162020920 - 254478162017636 =3D 3284 * 3 (3.00 GHz) =3D 9852 lag As you can see, the core lag is strictly determined by their sequence number. I won't argue about what percentage of this delay is due to rounding error and what percentage is due to ipi lag. To reproduce this, simply add the patch (excluding t->last_seen_ns and t->last_seen_tsc , which were necessary for my own understanding). Then enable the hypervisor with the settings cpufreq=3Dxen:performance max_cstate=3D1 . Clocksource is left at the default (i.e., hpet). On Mon, Jan 12, 2026 at 7:08=E2=80=AFPM Jan Beulich wro= te: > On 12.01.2026 15:51, Anton Markov wrote: > > That's if IPIs are sent sequentially. In the most common case, they > aren't, > >> though - we use the all-but-self shorthand. > > > > Actually, even if IPIs are sent sequentially, I can't see where you spo= t > >> this effect: Both callers of time_calibration_rendezvous_tail() signal > all > >> secondary CPUs to continue at the same time. Hence they'll all execute > >> time_calibration_rendezvous_tail() in parallel. > > > > In parallel, but with a slight delay. > > > > Are they? I fear I don't know which part of the code you're talking > about. > > > > In the function "time_calibration" (xen/arch/x86/time.c) Sorry, I don't > > take into account that you don't stay in context, being distracted by > other > > threads. > > That calls on_selected_cpus(), but send_IPI_mask() may then still resort = to > all-but-self. In that case all IPIs are sent in one go. > > Plus as said, how IPIs are sent doesn't matter for the invocation of > time_calibration_rendezvous_tail(). They'll all run at the same time, not > one after the other. > > Since further down you build upon that "IPI lag", I fear we first need to > settle on this aspect of your theory. > > Jan > > > One of the reasons we (iirc) don't do that is that since the scaling > factor > >> is also slightly imprecise, we'd prefer to avoid scaling very big > values. > >> IOW by changing as you suggest we'd trade one accumulating error for > >> another. > > > > As I wrote above, there will be an error when using scale_delta, but it > > won't accumulate between calls to time_calibration_rendezvous_tail. In > the > > current version, the old error (ipi lag + rounding error) persists due = to > > the use of the old local_stime in the get_s_time_fixed function, and it= 's > > added to the new error and accumulates with each call. > > If > > > > c->local_stime =3D get_s_time_fixed(old_tsc ?: new_tsc); > > > > replaced with: > > > > c->local_stime =3D scale_delta(old_tsc ?: new_tsc); > > > > Then we'll only be dealing with the error due to the current ipi lag an= d > > rough rounding, within a single call. > > > > If I understand you correctly, you fixed the rough rounding of > scale_delta > > by reducing the values using get_s_time_fixed . But the problem is, tha= t > > didn't help. The error now accumulates gradually because we're relying = on > > old calculations. Furthermore, while the old rounding error was limited= , > > now the error accumulates infinitely, albeit very slowly. If this is so= , > > then the solution to the problem becomes less obvious. > > > > Roughly speaking, my servers start to go crazy after a week of continuo= us > > operation, as the time lag between cores reaches 1 millisecond or more. > > > > On Mon, Jan 12, 2026 at 5:13=E2=80=AFPM Jan Beulich = wrote: > > > >> On 12.01.2026 13:49, Anton Markov wrote: > >>>> Btw, your prior response was too hard to properly read, due to exces= s > >> blank > >>>> lines with at the same time squashed leading blanks. Together with > your > >>>> apparent inability to avoid top-posting, I think you really want to > >> adjust > >>>> your mail program's configuration. > >>> > >>> I suggest we skip the discussion of formatting and the number of spac= es > >> in > >>> messages and instead focus on the topic of the thread. I have a very > >>> difficult time troubleshooting difficult-to-reproduce bugs, and the > fact > >>> that their descriptions are difficult to read due to the number of > spaces > >>> is probably the least of the difficulties. > >> > >> Perhaps, yet it still makes dealing with things more difficult. > >> > >>> That invocation of get_s_time_fixed() reduces to scale_delta() (witho= ut > >>>> further rdtsc_ordered()), as non-zero at_tsc is passed in all cases. > IOW > >>>> it's not quite clear to me what change you are suggesting (that woul= d > >>>> actually make a functional difference). > >>> > >>> Replacing get_s_time_fixed with scale_delta will remove the calculati= on > >>> dependency on the previous local_stime value, which accumulates lag > >> between > >>> cores. This is because: rdtsc_ordered is not called synchronously on > the > >>> cores, but by the difference offset by the ipi speed. Therefore, we > get: > >>> > >>> core0: current_rdtsc; > >>> core1: current_rdtsc + ipi speed; > >>> coreN: current_rdtsc + ipi speed * N; > >> > >> That's if IPIs are sent sequentially. In the most common case, they > aren't, > >> though - we use the all-but-self shorthand. > >> > >> Actually, even if IPIs are sent sequentially, I can't see where you sp= ot > >> this effect: Both callers of time_calibration_rendezvous_tail() signal > all > >> secondary CPUs to continue at the same time. Hence they'll all execute > >> time_calibration_rendezvous_tail() in parallel. > >> > >>> Since ipi values are sent alternately in a loop to core0, > >> > >> Are they? I fear I don't know which part of the code you're talking > about. > >> > >>> in the version > >>> with get_s_time_fixed, we get the following local_stime calculation > >> format. > >>> > >>> coreN: local_stime =3D local_stime + scale_delta((current_rdtsc + > >> (ipi_speed > >>> * N)) =E2=80=93 local_rdtsc); > >> > >> One of the reasons we (iirc) don't do that is that since the scaling > factor > >> is also slightly imprecise, we'd prefer to avoid scaling very big > values. > >> IOW by changing as you suggest we'd trade one accumulating error for > >> another. > >> > >> Jan > >> > >>> This means the time on each core will differ by ipi_speed * N. And > since > >>> we're using the values of the previous local_stime, the difference wi= ll > >>> accumulate because the previous local_stime was also offset. In the > >> version > >>> with scale_delta, we get: > >>> > >>> coreN: local_stime =3D scale_delta(current_rdtsc + (ipi_speed * N)); > >>> > >>> This means there will still be a difference, but it won't accumulate, > and > >>> the offsets will remain within normal limits. > >>> > >>> If it's still unclear: If your local_stime in get_s_time_fixed is > offset > >>> relative to other cores, then the fact that rdtsc_ordered and local_t= sc > >> are > >>> not offset doesn't change anything, since you're using the delta > relative > >>> to local_stime. > >>> > >>> core0_local_stime + (rdtsc_ordered() - local_tsc) !=3D core1_local_st= ime > + > >>> (rdtsc_ordered() - local_tsc); // Even if rdtsc_ordered() and local_t= sc > >> are > >>> equal across cores. > >>> > >>> On 96-core configurations, up to a millisecond of latency can > accumulate > >> in > >>> local_stime over a week of operation, and this is a significant > >>> difference. This > >>> is due to the fact that I use cpufreq=3Dxen:performance max_cstate=3D= 1 , > >>> meaning that in my configuration, local_stime is never overwritten by > >>> master_stime. > >>> > >>> Thanks. > >> > > > > --000000000000071bf40648338dfc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That cal= ls on_selected_cpus(), but send_IPI_mask() may then still resort to
all-= but-self. In that case all IPIs are sent in one go.
Plus as said, how IPIs are sent does= n't matter for the invocation of
time_calibration_rendezvous_tail().= They'll all run at the same time, not
one after the other.
At the hardware level, no one can guarantee that the processors will si= multaneously respond to the signal and execute your code nanosecond after y= ou send the ipi. Especially when we're talking about NUMA conf= igurations. I'm afraid the possible and impossible in the laws= of physics is also beyond the scope of this thread.
Sinc= e further down you build upon that "IPI lag", I fear we first nee= d to
settle on this aspect of your theory.
=C2=A0I've al= ready provided the delay logs. It's not hard for me to repeat.=

The patch:

@@ -1732,6 +1753,8 @@ static void cf_check local_time_calibration(void)=

if ( boot_cpu_has(X86_FEATURE_CONSTANT_TSC) )

{

/* Atomically read cpu_calibration struct and write cpu_time struct. */=

+ printk("update stime on time calibrate %d, %lu -> %lu (%lu, %lu)\n", smp_processor_id(), t->stamp.local_stime, c->local_stime,

+ t->last_seen_ns, t->last_seen_tsc);

=20 local_irq_disable();

=20 t->stamp =3D *c;

=20 local_irq_enable();


=C2=A02 hours of work:

(XEN) update stime on time calibrate 0, 85= 64145820102 -> 8565145861597 (8565145862216, 0)
(XEN) update stime on= time calibrate 1, 8564145820129 -> 8565145861609 (8565145863957, 0)
= (XEN) update stime on time calibrate 3, 8564145819996 -> 8565145861491 (= 8565145864800, 0)
(XEN) update stime on time calibrate 2, 8564145820099 = -> 8565145861609 (8565145865372, 0)

8565145861609 - 8565145861491= =3D 115 * 3 (3.00 GHz) =3D 345 lag


3 h= ours of work:

(XEN) upda= te stime on time calibrate 0, 22914730829200 -> 22915730869993 (22915730= 870665, 0)
(XEN) update stime on time calibrate 1, 22914730829073 -> = 22915730869889 (22915730870693, 0)
(XEN) update stime on time calibrate = 2, 22914730829052 -> 22915730869841 (22915730872231, 0)
(XEN) update = stime on time calibrate 3, 22914730828892 -> 22915730869696 (22915730872= 096, 0)

22915730869993 - 22915730869696 =3D 297 * 3 (3.00 GHz) =3D 8= 91 lag


2-3 day of work:
(XEN) update stime on time calibrat= e 0, 254477161980127 -> 254478162020920 (254478162021549, 0)
(XEN) up= date stime on time calibrate 2, 254477161977638 -> 254478162018429 (2544= 78162022187, 0)
(XEN) update stime on time calibrate 1, 254477161978192 = -> 254478162018972 (254478162022776, 0)
(XEN) update stime on time ca= librate 3, 254477161976832 -> 254478162017636 (254478162021394, 0)
254478162020920 - 254478162017636 =3D 3284 * 3 (3.00 GHz) =3D 9852 lag
=C2=A0
=C2=A0As you can see, the core lag is strictly d= etermined by their sequence number.=C2=A0I won't argue ab= out what percentage of this delay is due to rounding error and what percent= age is due to ipi lag.=C2=A0To reproduce this, simply add the patch (excluding t= ->last_seen_ns and t->last_seen_tsc , which were necessary for my own= understanding). Then enable the hypervisor with the settings cpuf= req=3Dxen:performance max_cstate=3D1 . Clocksource is left at the = default (i.e., hpet).

On Mon, Jan = 12, 2026 at 7:08=E2=80=AFPM Jan Beulich <jbeulich@suse.com> wrote:
On 12.01.2026 15:51, Anton Markov wrote:
> That's if IPIs are sent sequentially. In the most common case, the= y aren't,
>> though - we use the all-but-self shorthand.
>
> Actually, even if IPIs are sent sequentially, I can't see where yo= u spot
>> this effect: Both callers of time_calibration_rendezvous_tail() si= gnal all
>> secondary CPUs to continue at the same time. Hence they'll all= execute
>> time_calibration_rendezvous_tail() in parallel.
>
> In parallel, but with a slight delay.
>
> Are they? I fear I don't know which part of the code you're ta= lking about.
>
> In the function "time_calibration" (xen/arch/x86/time.c) Sor= ry, I don't
> take into account that you don't stay in context, being distracted= by other
> threads.

That calls on_selected_cpus(), but send_IPI_mask() may then still resort to=
all-but-self. In that case all IPIs are sent in one go.

Plus as said, how IPIs are sent doesn't matter for the invocation of time_calibration_rendezvous_tail(). They'll all run at the same time, n= ot
one after the other.

Since further down you build upon that "IPI lag", I fear we first= need to
settle on this aspect of your theory.

Jan

> One of the reasons we (iirc) don't do that is that since the scali= ng factor
>> is also slightly imprecise, we'd prefer to avoid scaling very = big values.
>> IOW by changing as you suggest we'd trade one accumulating err= or for
>> another.
>
> As I wrote above, there will be an error when using scale_delta, but i= t
> won't accumulate between calls to time_calibration_rendezvous_tail= . In the
> current version, the old error (ipi lag + rounding error) persists due= to
> the use of the old local_stime in the get_s_time_fixed function, and i= t's
> added to the new error and accumulates with each call.
> If
>
> c->local_stime =3D get_s_time_fixed(old_tsc ?: new_tsc);
>
> replaced with:
>
> c->local_stime =3D scale_delta(old_tsc ?: new_tsc);
>
> Then we'll only be dealing with the error due to the current ipi l= ag and
> rough rounding, within a single call.
>
> If I understand you correctly, you fixed the rough rounding of scale_d= elta
> by reducing the values using get_s_time_fixed . But the problem is, th= at
> didn't help. The error now accumulates gradually because we're= relying on
> old calculations. Furthermore, while the old rounding error was limite= d,
> now the error accumulates infinitely, albeit very slowly. If this is s= o,
> then the solution to the problem becomes less obvious.
>
> Roughly speaking, my servers start to go crazy after a week of continu= ous
> operation, as the time lag between cores reaches 1 millisecond or more= .
>
> On Mon, Jan 12, 2026 at 5:13=E2=80=AFPM Jan Beulich <jbeulich@suse.com> wrote: >
>> On 12.01.2026 13:49, Anton Markov wrote:
>>>> Btw, your prior response was too hard to properly read, du= e to excess
>> blank
>>>> lines with at the same time squashed leading blanks. Toget= her with your
>>>> apparent inability to avoid top-posting, I think you reall= y want to
>> adjust
>>>> your mail program's configuration.
>>>
>>> I suggest we skip the discussion of formatting and the number = of spaces
>> in
>>> messages and instead focus on the topic of the thread. I have = a very
>>> difficult time troubleshooting difficult-to-reproduce bugs, an= d the fact
>>> that their descriptions are difficult to read due to the numbe= r of spaces
>>> is probably the least of the difficulties.
>>
>> Perhaps, yet it still makes dealing with things more difficult. >>
>>> That invocation of get_s_time_fixed() reduces to scale_delta()= (without
>>>> further rdtsc_ordered()), as non-zero at_tsc is passed in = all cases. IOW
>>>> it's not quite clear to me what change you are suggest= ing (that would
>>>> actually make a functional difference).
>>>
>>> Replacing get_s_time_fixed with scale_delta will remove the ca= lculation
>>> dependency on the previous local_stime value, which accumulate= s lag
>> between
>>> cores. This is because: rdtsc_ordered is not called synchronou= sly on the
>>> cores, but by the difference offset by the ipi speed. Therefor= e, we get:
>>>
>>> core0: current_rdtsc;
>>> core1: current_rdtsc + ipi speed;
>>> coreN: current_rdtsc + ipi speed * N;
>>
>> That's if IPIs are sent sequentially. In the most common case,= they aren't,
>> though - we use the all-but-self shorthand.
>>
>> Actually, even if IPIs are sent sequentially, I can't see wher= e you spot
>> this effect: Both callers of time_calibration_rendezvous_tail() si= gnal all
>> secondary CPUs to continue at the same time. Hence they'll all= execute
>> time_calibration_rendezvous_tail() in parallel.
>>
>>> Since ipi values are sent alternately in a loop to core0,
>>
>> Are they? I fear I don't know which part of the code you'r= e talking about.
>>
>>> in the version
>>> with get_s_time_fixed, we get the following local_stime calcul= ation
>> format.
>>>
>>> coreN: local_stime =3D local_stime + scale_delta((current_rdts= c +
>> (ipi_speed
>>> * N)) =E2=80=93 local_rdtsc);
>>
>> One of the reasons we (iirc) don't do that is that since the s= caling factor
>> is also slightly imprecise, we'd prefer to avoid scaling very = big values.
>> IOW by changing as you suggest we'd trade one accumulating err= or for
>> another.
>>
>> Jan
>>
>>> This means the time on each core will differ by ipi_speed * N.= And since
>>> we're using the values of the previous local_stime, the di= fference will
>>> accumulate because the previous local_stime was also offset. I= n the
>> version
>>> with scale_delta, we get:
>>>
>>> coreN: local_stime =3D scale_delta(current_rdtsc + (ipi_speed = * N));
>>>
>>> This means there will still be a difference, but it won't = accumulate, and
>>> the offsets will remain within normal limits.
>>>
>>> If it's still unclear: If your local_stime in get_s_time_f= ixed is offset
>>> relative to other cores, then the fact that rdtsc_ordered and = local_tsc
>> are
>>> not offset doesn't change anything, since you're using= the delta relative
>>> to local_stime.
>>>
>>> core0_local_stime + (rdtsc_ordered() - local_tsc) !=3D core1_l= ocal_stime +
>>> (rdtsc_ordered() - local_tsc); // Even if rdtsc_ordered() and = local_tsc
>> are
>>> equal across cores.
>>>
>>> On 96-core configurations, up to a millisecond of latency can = accumulate
>> in
>>> local_stime over a week of operation, and this is a significan= t
>>> difference. This
>>> is due to the fact that I use cpufreq=3Dxen:performance max_cs= tate=3D1 ,
>>> meaning that in my configuration, local_stime is never overwri= tten by
>>> master_stime.
>>>
>>> Thanks.
>>
>

--000000000000071bf40648338dfc-- From xen-devel-bounces@lists.xenproject.org Mon Jan 12 16:43:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 16:43:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200777.1516614 (Exim 4.92) (envelope-from ) id 1vfL0R-0002tb-T3; Mon, 12 Jan 2026 16:43:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200777.1516614; Mon, 12 Jan 2026 16:43: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 1vfL0R-0002tU-PS; Mon, 12 Jan 2026 16:43:03 +0000 Received: by outflank-mailman (input) for mailman id 1200777; Mon, 12 Jan 2026 16:43: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 1vfL0Q-0002tO-KC for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 16:43:02 +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 c16e6c95-efd5-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 17:43:00 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-47775fb6c56so63256795e9.1 for ; Mon, 12 Jan 2026 08:43:00 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0860f5sm39432041f8f.0.2026.01.12.08.42.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 08:42:59 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c16e6c95-efd5-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768236180; x=1768840980; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=aodtCCYQHv77xQMPNm9MvtkCMQFK6CqUOHOhIfnR5Hs=; b=gkHnNu8lgeZqtgmKmfgvYLFWdrsZEgUhakufs/aj1IKRWONzVpErvjvED20fEcCvI7 Qoej6Bpzqi8LTMY1ez1Cnb0/fX940MeTIrFGDoHedFgU1B5wdrsi1tY9pRy/RThKY4q7 dJNvmyRPWa5Tz0pRtAdspHR/C12Fj3IEbQJGn5GSMO2BidYi6syuXP8rGbmmMVSRjaWS jNk7rjt+RAnkHa40AHi2sjNk/EICjFbltdgzGgAaOkfEaKf/poplIRLwSLc9IoPkuLXo XjaBqzWXNCkPQBoVYGNgK111gmsZqt4zBGrPwoV/MmV1bdPoJg+Zzp8y2+6TkcW8TWws QemQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768236180; x=1768840980; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=aodtCCYQHv77xQMPNm9MvtkCMQFK6CqUOHOhIfnR5Hs=; b=J+uMElegLpREOBv9TxmYfWqaTl+IL/Jfah124BUeLwICpsplFxP2cB9TBkd9LSGl3J yBDwgRZkDwvFVZ4mgeHhMIYsBwiy7Sls9odUungMVZVcm3Rq1c+ybS66QJlGT2JqwLfb H7tXrduAxZ17GiCQoM1qzUlJvMqturbDtHHYKyWf20gb3ZIfldO01CRvH/sNh4ESysD+ kysJIogpf/BaYfV4ZxJH6PmI3yLHqJwnPKfwHuKzSZzvGQl0hXMvTcqg63buQ1QRpmFP zhS1mpYWkeGAiZI85AQupWVz6dxtNRs8fQ4iRO1ptaiU5EnUYew9eRJl7LcDB6UPEg12 /cKQ== X-Forwarded-Encrypted: i=1; AJvYcCUhKMGxu+PZBpUNPWxU7eJ1/JCNQAiRMKJ1wvmZoBZXRf8ebUi+d9Cu+BpPpuLHIs5ci8AaxnDfxD8=@lists.xenproject.org X-Gm-Message-State: AOJu0YxqSQ3eWyJPjMR2jcg45cX4SaTNVQx2I1K9SKxMWPOByK4F3vwB W/FmGrmzdcd5Em1/hNGkSGNvOEn9KxuoXAc0o5h4VF/f60HIgdCCDKNDQy7PD4eWcw== X-Gm-Gg: AY/fxX7UOSpq42wSjJm6fd+U/U6bcPvJYiJHZb4elJUC3BJNJYYdWFcc+XXbV+V1Lfi +jlTqCN4Yuhpcq4BkVOvYM4DQE6+yNk6HzCKbthX1YuWsMftqlNrT5yJevnDL82YOkuVR2Tul0O vOVpJY5P3Xt0Hwn/fb8o5MezT5YJj0p6blFZSHfF9t/I5k6s7AB8CJL/4WRrHQgDJlTQ6kG1w01 U0zxFUpKe0sXns6mm/YklINIUUFafqFhM4KEY30exZE4rp9SC1bO1LPC5nFtyXGVJjB5e8ULuw2 4mkqD+PA9L3BmHLnhLAjKBs1EkRi7vEgISfCsK2hvdhW41qs9EtBiFNP+TcFg/XX5VkiW/nVMuf 0rpjHocruQW7d244hoqFTxy61OqDRNU3FBUvapxYTSF7rOHzJRz6AoVH5UAs+ZBLLE8n8OkhTEo pfFJiug73FzNgTurapFk6nf7ddzCKQsKIPDXA9UTsnRX2eV9JX/EtGh5MuOPo3YkgoYgQHwvY35 vc= X-Google-Smtp-Source: AGHT+IHlwh93TCtO8IqHNHC/MbVo+JsrZatcg6YIGCqsaGfL1l7Ci1sNVzYwddTnDcJlnmFXrXQLxQ== X-Received: by 2002:a5d:5f43:0:b0:430:f3fb:35fa with SMTP id ffacd0b85a97d-432c38d22fbmr22858680f8f.57.1768236179567; Mon, 12 Jan 2026 08:42:59 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2026 17:42:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 03/15] xen/riscv: implement vcpu_csr_init() 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: <7ba4bcfe-59d3-43f3-adb4-207424dc1713@gmail.com> <988ba581-5503-45d4-a621-18cdc3b14cab@gmail.com> <30dbd0b0-2a2b-4064-b39c-4dfa438af15b@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.01.2026 17:39, Oleksii Kurochko wrote: > > On 1/12/26 4:54 PM, Jan Beulich wrote: >> On 12.01.2026 16:46, Oleksii Kurochko wrote: >>> On 1/12/26 3:28 PM, Jan Beulich wrote: >>>> On 12.01.2026 13:59, Oleksii Kurochko wrote: >>>>> On 1/7/26 9:46 AM, Jan Beulich wrote: >>>>>> Also, wouldn't you better keep internal state in line with what hardware >>>>>> actually supports? CSRIND may be read-only-zero in the real register, in >>>>>> which case having the bit set in the "cached" copy can be misleading. >>>>> [...] >>>>> >>>>>> (This may similarly apply to at least hedeleg and hideleg, btw.) >>>>> Regarding the previous bits, I can understand that it would be an issue: >>>>> if SSAIA isn’t supported, then it is incorrect to update the corresponding >>>>> bits of|hstateen0|. >>>>> >>>>> However, I’m not really sure I understand what the issue is with|h{i,e}deleg|. >>>>> All writable bits there don’t depend on hardware support. Am I missing something? >>>> My reading of the doc was that any of the bits can be r/o 0, with - yes - >>>> no dependencies on particular extensions. >>> Just to be sure that I get your idea correctly. >>> >>> Based on the priv. spec: >>> Each bit of hedeleg shall be either writable or read-only zero. Many bits of >>> hedeleg are required specifically to be writable or zero, as enumerated in >>> Table 29. >>> >>> Now let’s take hedeleg.bit1, which is marked as writable according to Table 29. >>> Your point is that even though hedeleg.bit1 is defined as writable, it could still >>> be read-only zero, right? >>> >>> In general, I agree with that. It is possible that M-mode software decides, for >>> some reason (for example, because the implementation does not support delegation >>> of bit1 to a lower mode), not to delegate medeleg.bit1 to HS-mode. In that case, >>> hedeleg.bit1 would always be read-only zero. >>> >>>> In which case you'd need to do >>>> the delegation in software. For which it might be helpful to know what >>>> the two registers are actually set to in hardware (i.e. the cached values >>>> wanting to match the real ones). >>> Does it make sense then to have the following >>> ... >>> v->arch.hedeleg = hedeleg; >>> vcpu->arch.hedeleg = csr_read(CSR_HEDELEG); >>> in arch_vcpu_create()? >> The above makes no sense to me, with or without s/vcpu/v/. > > Right... > > It should be also csr_write() before csr_read(): > csr_write(CSR_HEDELEG, hedeleg); > v->arch.hedeleg = csr_read(CSR_HEDELEG); Ah yes. Alternatively you could obtain a mask of modifiable bits once, and then simply apply that here in place of the CSR read/write. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 16:47:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 16:47:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200788.1516622 (Exim 4.92) (envelope-from ) id 1vfL4T-0003T0-Cl; Mon, 12 Jan 2026 16:47:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200788.1516622; Mon, 12 Jan 2026 16: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 1vfL4T-0003St-98; Mon, 12 Jan 2026 16:47:13 +0000 Received: by outflank-mailman (input) for mailman id 1200788; Mon, 12 Jan 2026 16:47: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 1vfL4R-0003Sn-KU for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 16:47:11 +0000 Received: from mail8.us4.mandrillapp.com (mail8.us4.mandrillapp.com [205.201.136.8]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5560393f-efd6-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 17:47:09 +0100 (CET) Received: from pmta15.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail8.us4.mandrillapp.com (Mailchimp) with ESMTP id 4dqdZg4KB1z2K1rly for ; Mon, 12 Jan 2026 16:47:07 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id eb65e341abdf4b68ae7d17db6fc25cd3; Mon, 12 Jan 2026 16:47: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: 5560393f-efd6-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1768236427; x=1768506427; bh=qI61iBlkqBdvAojoqvM3anqTtKbYE9EY4wLfqLBcqUE=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=PBO/AiuimQ1AcR62ne/P5CNEgDAE0g3PZ4AMBZw9R/JeW25PzUBlStFZrikCsCxNE BMBV7yLnjxcQa4UcMyoCkYPnzRiTd9CTWZiKcLmnHwCgH9lWpkOrflkbyCFSIp/MqR 0QIkA49Uo0VNA3B+nrejHKY3K619FLY32taMjO0A6WP++bcX9oGy3tQmyXEHHFH5jm u4o5Ck7DRsfmbrUbLIMYRsDcxnpQb6yQMMgPgxAZb/HMU7oDYpk917RPSSzuaS+nLg 1lUv5XBYeT7zFc1ENbJM/SHAVLLXW84JwnN1CHbhaATm8PbYBinjPCwF+PKJtTJO06 ZJC1x37tBUqYA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1768236427; x=1768496927; i=teddy.astie@vates.tech; bh=qI61iBlkqBdvAojoqvM3anqTtKbYE9EY4wLfqLBcqUE=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=YiDRlMG3oXkG3sjmTYotmI+utaac9D5eo7cDZGSqH3L6eGVMAYKF4l5+3S3ehcP/C SCj0LnAHbFtAVZe3zZfKs+HKWUYwoCIOIvoEcH4uKuRV6j55DgBxTkialD2wPlbgyx mCViOb8Z3u9IBmxeRQ69j9jPMIltNSAcdR/s00JyZOE4Y6C7KM0V9gbiqdp28iUXJt waqRHmuGarqhk+yZcfubN3fx05T4XRvENWYZDleO14SbJfKHyE2mx2iHZQXVX0yraH iqVjS6omhGf4w9zTLxymsNZoifuwlLLfxyNk0naehOubAytACLeIfhlJ5tsAeLlYWv cH+K5I1ac/Rzw== From: "Teddy Astie" Subject: =?utf-8?Q?[PATCH=20v5=202/2]=20xenpm:=20Add=20get-intel-temp=20subcommand?= X-Mailer: git-send-email 2.52.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1768236426293 To: xen-devel@lists.xenproject.org Cc: "Teddy Astie" , "Oleksii Kurochko" , "Community Manager" , "Anthony PERARD" , "Jan Beulich" Message-Id: <7ae6ca6f93e81cb0b5a71db90913dc3f67e6b763.1768235932.git.teddy.astie@vates.tech> In-Reply-To: <7dfa012b734f3c769da88f0f1c989d07b724bdaa.1768235932.git.teddy.astie@vates.tech> References: <7dfa012b734f3c769da88f0f1c989d07b724bdaa.1768235932.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.eb65e341abdf4b68ae7d17db6fc25cd3?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260112:md Date: Mon, 12 Jan 2026 16:47:07 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable get-intel-temp allows querying the per-core CPU temperature and per-package one on Intel processors (as usual Dom0 drivers cannot work due to misalignment between Dom0 vCPU and pCPUs). Signed-off-by: Teddy Astie --- Cc: Jan Beulich v5: Applied Jan proposed changes (removed bracket in changes and added newl= ines). CHANGELOG.md | 3 ++ tools/misc/xenpm.c | 115 ++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 117 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 7de34f64d1..568a8cebaa 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -9,6 +9,9 @@ The format is based on [Keep a Changelog](https://keepachan= gelog.com/en/1.0.0/) ### Changed ### Added + - On x86: + - Introduce get-intel-temp to xenpm to query CPU temperatures on Intel + platforms. ### Removed - On x86: diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c index 682d092479..d20a213c71 100644 --- a/tools/misc/xenpm.c +++ b/tools/misc/xenpm.c @@ -32,11 +32,14 @@ #include +#include + #define MAX_PKG_RESIDENCIES 12 #define MAX_CORE_RESIDENCIES 8 static xc_interface *xc_handle; static unsigned int max_cpu_nr; +static xc_physinfo_t physinfo; /* help message */ void show_help(void) @@ -93,6 +96,7 @@ void show_help(void) " units default to \= "us\" if unspecified.\n" " truncates un-repre= sentable values.\n" " 0 lets the hardwar= e decide.\n" + " get-intel-temp [cpuid] get Intel CPU temperatur= e of or all\n" " start [seconds] start collect Cx/Px stat= istics,\n" " output after CTRL-C or S= IGINT or several seconds.\n" " enable-turbo-mode [cpuid] enable Turbo Mode for pr= ocessors that support it.\n" @@ -1354,6 +1358,115 @@ void enable_turbo_mode(int argc, char *argv[]) errno, strerror(errno)); } +static int fetch_dts_temp(xc_interface *xch, uint32_t cpu, bool package, i= nt *temp) +{ + xc_resource_entry_t entries[] =3D { + { .idx =3D package ? MSR_PACKAGE_THERM_STATUS : MSR_IA32_THERM_STA= TUS }, + { .idx =3D MSR_TEMPERATURE_TARGET }, + }; + struct xc_resource_op ops =3D { + .cpu =3D cpu, + .entries =3D entries, + .nr_entries =3D ARRAY_SIZE(entries), + }; + int tjmax; + + int ret =3D xc_resource_op(xch, 1, &ops); + + switch ( ret ) + { + case -1: + /* xc_resource_op returns -1 in out of memory scenarios */ + return -ENOMEM; + + case 0: + /* This CPU isn't online or can't query this MSR */ + return -ENODATA; + + case 1: + { + /* + * The CPU doesn't support MSR_TEMPERATURE_TARGET, we assume it's = 100 + * which is correct aside a few selected Atom CPUs. Check Linux + * kernel's coretemp.c for more information. + */ + static bool has_reported_once =3D false; + + if ( !has_reported_once ) + { + fprintf(stderr, "MSR_TEMPERATURE_TARGET is not supported, assu= me " + "tjmax =3D 100, readings may be incorrect.\n")= ; + has_reported_once =3D true; + } + + tjmax =3D 100; + break; + } + + case 2: + tjmax =3D (entries[1].val >> 16) & 0xff; + break; + + default: + if ( ret > 0 ) + { + fprintf(stderr, "Got unexpected xc_resource_op return value: %= d", + ret); + return -EINVAL; + } + return ret; + } + + *temp =3D tjmax - ((entries[0].val >> 16) & 0xff); + return 0; +} + +static void get_intel_temp(int argc, char *argv[]) +{ + int temp =3D -1, cpu =3D -1; + unsigned int socket; + bool has_data =3D false; + + if ( argc > 0 ) + parse_cpuid(argv[0], &cpu); + + if ( cpu !=3D -1 ) + { + if ( !fetch_dts_temp(xc_handle, cpu, false, &temp) ) + printf("CPU%d: %d=C2=B0C\n", cpu, temp); + else + printf("No data\n"); + return; + } + + /* Per socket measurement */ + for ( socket =3D 0, cpu =3D 0; cpu < max_cpu_nr; + socket++, cpu +=3D physinfo.cores_per_socket * physinfo.threads_= per_core ) + { + if ( !fetch_dts_temp(xc_handle, cpu, true, &temp) ) + { + has_data =3D true; + printf("Package%u: %d=C2=B0C\n", socket, temp); + } + } + + if ( has_data ) + /* Avoid inserting a trailing line if we have nothing */ + printf("\n"); + + for ( cpu =3D 0; cpu < max_cpu_nr; cpu +=3D physinfo.threads_per_core = ) + { + if ( fetch_dts_temp(xc_handle, cpu, false, &temp) ) + continue; + + has_data =3D true; + printf("CPU%d: %d=C2=B0C\n", cpu, temp); + } + + if ( !has_data ) + printf("No data\n"); +} + void disable_turbo_mode(int argc, char *argv[]) { int cpuid =3D -1; @@ -1618,12 +1731,12 @@ struct { { "set-max-cstate", set_max_cstate_func}, { "enable-turbo-mode", enable_turbo_mode }, { "disable-turbo-mode", disable_turbo_mode }, + { "get-intel-temp", get_intel_temp }, }; int main(int argc, char *argv[]) { int i, ret =3D 0; - xc_physinfo_t physinfo; int nr_matches =3D 0; int matches_main_options[ARRAY_SIZE(main_options)]; -- 2.52.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 Jan 12 16:47:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 16:47:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200789.1516633 (Exim 4.92) (envelope-from ) id 1vfL4Z-0003hu-J7; Mon, 12 Jan 2026 16:47:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200789.1516633; Mon, 12 Jan 2026 16:47:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfL4Z-0003hn-FH; Mon, 12 Jan 2026 16:47:19 +0000 Received: by outflank-mailman (input) for mailman id 1200789; Mon, 12 Jan 2026 16:47: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 1vfL4X-0003hB-Mj for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 16:47:17 +0000 Received: from mail137-3.atl71.mandrillapp.com (mail137-3.atl71.mandrillapp.com [198.2.137.3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 552e0326-efd6-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 17:47:08 +0100 (CET) Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail137-3.atl71.mandrillapp.com (Mailchimp) with ESMTP id 4dqdZf6ySfzBsV8Zg for ; Mon, 12 Jan 2026 16:47:06 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 5c8b13a73ebf4ddaa406de2a0ff265a9; Mon, 12 Jan 2026 16:47:06 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 552e0326-efd6-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1768236427; x=1768506427; bh=p5kqd4khOY+qV68/kVI7ESMpsYgEQqqOTOVsgjsvx2c=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=m6jdMX8KTBQYQF6/aZcDbmf3ETnDa51Xxs7jVOLky3ZPLaYNGVc1NcnWr0xl3/g6H qq4Kv9BBjhqUAOzVt9LEejJDiw8y7vqxgRWxkSKvogMy9LtYKEUkk9cub8eQ+yr4nb jf8AWQ9LwxIU1HG+tCl4qIFjkmi54u+WYG5WXnfJXTVK+48jHO9CsFmTbM4nV5Rum9 q5nx+H+1/uVHm9MQYgzhp9xxwFMVXj33baOUvEjp38sb/ITqohAwQTIuEdxnR3jRhT Qkn0oTWHOucCMdvMgC2rmPac08ZpmHn/A1Zk5E784Bxu5MYYgcrWdqre+JpU6s1NWr D/hwzP0JYI0YQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1768236427; x=1768496927; i=teddy.astie@vates.tech; bh=p5kqd4khOY+qV68/kVI7ESMpsYgEQqqOTOVsgjsvx2c=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=TGhx+Hir8WsKv11K/OgnT1ZtVjVFlYJ6iESSxCKg6bCK4fshN1NzGJrg8GKuqsAM2 Ak6lPxUWCTIPufo32raa3lKdzh5JrWTjEMaLLYJimp/78ymEIs85eC+ZAunqs3tu1N NeIepgqBxKgjIg/JSGQagBUZQ8SfigV9bZEJEp1Ol74n/dUkAhfW2eO9uZYxl1iraG kcQkhO2ahkzfcYUeST6gxfNeYO+GjLAPxrq+XsDhLKDxofXhVKhah1/9WYkU0VF7S9 /REYFKV+ZobsUoepAFXcFLk+uDszKqieFea05CFesZ23Y/BLnShfVD3Q3/dMpc4t/O UM0FETJDn5fRg== From: "Teddy Astie" Subject: =?utf-8?Q?[PATCH=20v5=201/2]=20x86/platform:=20Expose=20DTS=20sensors=20MSR?= X-Mailer: git-send-email 2.52.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1768236425925 To: xen-devel@lists.xenproject.org Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" Message-Id: <7dfa012b734f3c769da88f0f1c989d07b724bdaa.1768235932.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.5c8b13a73ebf4ddaa406de2a0ff265a9?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260112:md Date: Mon, 12 Jan 2026 16:47:06 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Intel provide CPU sensors through "DTS" MSRs. As these MSR are core-specific (or package-specific), we can't reliably fetch them from Dom0 directly. Expose these MSR (if supported) through XENPF_resource_op so that it is accessible through hypercall. Suggested-by: Jan Beulich Signed-off-by: Teddy Astie Reviewed-by: Jan Beulich --- Needs x86/cpu-policy: Infrastructure for CPUID leaf 0x6. v4: https://lore.kernel.org/xen-devel/cover.1766158766.git.teddy.astie@vates.tech/ v5: Removed trailing whitespace. xen/arch/x86/include/asm/msr-index.h | 3 +++ xen/arch/x86/platform_hypercall.c | 6 ++++++ xen/include/xen/lib/x86/cpu-policy.h | 2 +- 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h index df52587c85..b92a278611 100644 --- a/xen/arch/x86/include/asm/msr-index.h +++ b/xen/arch/x86/include/asm/msr-index.h @@ -115,6 +115,9 @@ #define MCU_OPT_CTRL_GDS_MIT_DIS (_AC(1, ULL) << 4) #define MCU_OPT_CTRL_GDS_MIT_LOCK (_AC(1, ULL) << 5) +#define MSR_TEMPERATURE_TARGET 0x000001a2 +#define MSR_PACKAGE_THERM_STATUS 0x000001b1 + #define MSR_FRED_RSP_SL0 0x000001cc #define MSR_FRED_RSP_SL1 0x000001cd #define MSR_FRED_RSP_SL2 0x000001ce diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c index 79bb99e0b6..bbd8ce71f5 100644 --- a/xen/arch/x86/platform_hypercall.c +++ b/xen/arch/x86/platform_hypercall.c @@ -27,6 +27,7 @@ #include #include #include +#include #include #include #include @@ -86,6 +87,11 @@ static bool msr_read_allowed(unsigned int msr) case MSR_MCU_OPT_CTRL: return cpu_has_srbds_ctrl; + + case MSR_IA32_THERM_STATUS: + case MSR_TEMPERATURE_TARGET: + case MSR_PACKAGE_THERM_STATUS: + return host_cpu_policy.basic.dts; } if ( ppin_msr && msr == ppin_msr ) diff --git a/xen/include/xen/lib/x86/cpu-policy.h b/xen/include/xen/lib/x86/cpu-policy.h index 8772ef80e3..0362f1cb24 100644 --- a/xen/include/xen/lib/x86/cpu-policy.h +++ b/xen/include/xen/lib/x86/cpu-policy.h @@ -123,7 +123,7 @@ struct cpu_policy uint64_t :64, :64; /* Leaf 0x5 - MONITOR. */ /* Leaf 0x6 - Therm/Perf. */ - bool :1, + bool dts:1, turbo:1, arat:1, :1, -- 2.52.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 Jan 12 16:53:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 16:53:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200808.1516643 (Exim 4.92) (envelope-from ) id 1vfLAn-0005jo-6V; Mon, 12 Jan 2026 16:53:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200808.1516643; Mon, 12 Jan 2026 16:53:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfLAn-0005jh-3S; Mon, 12 Jan 2026 16:53:45 +0000 Received: by outflank-mailman (input) for mailman id 1200808; Mon, 12 Jan 2026 16:53: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 1vfLAl-0005jb-Kz for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 16:53:43 +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 3c0795ee-efd7-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 17:53:35 +0100 (CET) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-64d30dc4ed7so12944776a12.0 for ; Mon, 12 Jan 2026 08:53:35 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6507b8c4454sm18295706a12.3.2026.01.12.08.53.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 08:53:34 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3c0795ee-efd7-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768236815; x=1768841615; 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=TFrzOfuWuR3wvKFK6Eo3qR7ND40QowhwHk3UwhZm65o=; b=i1xrYZUn6ajImJhWi6D7I4WE+RRRSYJ+BOUyZ8L7d06aZgkV10xRaoGMg6F+wBhaqf MFeYaaXJJW2RHFBSe0an7RPiRKSImIskbeaPQZ86QKZZM4q5PX/FH2lcXCs27Tnu5/ew q/WsRw7zrX5CNtG1I0ptFyn2m/0BcIScACXbRg1G5YMUzUZcE/e2TvC9UhntSRDhWbZQ XIW3ZM3IJTQzwipQXUHXR16v3ShyDuQO0x0xlgTF0I9IhpljykeyrAJSFjl5qVekUGn+ nWTnBiQgVmFjtdEz0kKWrldqM/w3aR2hDWl2I1tC+7jUzmPuL568RGEOiYGb7Il8CExf s7hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768236815; x=1768841615; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TFrzOfuWuR3wvKFK6Eo3qR7ND40QowhwHk3UwhZm65o=; b=RlXqqYugmGdFsjb5MOYqAWfD3YWsoVoLMWJp02A0q5j8fS1Q53WttREomuDafBy5Yl IIfXL7tIK56tjuS/payKBW74E8PgEw+ADcxwNh/k7/k2rb2nl4dnw27Ps/IsGkYWfkmf KaInGbQXC2lVunBzn1tMJA3GTAeqSB5R4U+NaP8eVZKlRAdEIs7FJ3NCFoUBHcgTAR45 amdHtc61TERUWRZTR/j2oStj18MoCw65egIqmQAwNEadzppbR7ZRQAoaKSVgr8lm0gXf sYyXMyjWdyYhVifZwql0gz/dw3ey1OmiDc2wRtREvtx1ypbs0Xl7D0+6QSTTabOjzU7c p3iA== X-Forwarded-Encrypted: i=1; AJvYcCW6mhcQHWWcUchEU83KKRhpz4Oxry4gUTu25FqExWzVQOF5MkQjLsAgfzarovjKOyDFiJ1Wyd568HQ=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz0n2IbE5fWa+2YBz4grYGKWsN5QLj4wgAXK8rHVzQMg/Adkie9 dsEqaTf3Nk6BUQVRMDjBU8B4g44Mdq9ci+szm43B8jA28DQ0JSI1G8Ok X-Gm-Gg: AY/fxX4ynETMmuNayMtQdEEJAwUdO8ojgh2E2Wr/UeD+RUyS9n9KX7Kl8aQw2/Yq5PJ i1o3OD88+wSZVKWYQ0O+4mbOft6oqBLdo8XqaJomNhGa+XAfXCOmt2dj6sieiCXsADmhHmTmcrS odieBJKPi+u4Y7XgHDp5LzWcNqWdqxdy3/sG7/3/Zutd9qBkYmGjd3nnNUGDgN9SzDV7aNZ7/PM eGoOZYLx+d1MNGRERU9gTMTl3UXVrbr9JmilC6MydJ8uv8PgdQTl23LpFhOpC6qq7KOBRXaCS46 ZmUc+rW0NL8ZXCpeuWSz5DHBhozYj15FZ/rZvdN2UrhjFT+j058ydY5737wAE5dLR7D9BhoNkkh F6ASNUpT156P/3dIvRyDjllQjm4jDiWfu72y7MAowHyQLpZ3P/P5JuUBMTeCrmDV+OZU2N840o8 ykDKhK2KfzN/xyvkSMsNBaxehvbDsAOH0hIn6Qg8F2SO2pNifMsmdNKbTxE0IxiVo= X-Google-Smtp-Source: AGHT+IE57ZREPJoTg+Fk7nuAJg5v8ePwSfUd62260AhHEQWuEEELGY378zBqu8v3buCpmQ8W8m38rA== X-Received: by 2002:a05:6402:42c7:b0:64d:498b:aeec with SMTP id 4fb4d7f45d1cf-65097df8139mr18519113a12.12.1768236814639; Mon, 12 Jan 2026 08:53:34 -0800 (PST) Message-ID: <94c0cd09-7aaa-4ae1-913e-57d883916682@gmail.com> Date: Mon, 12 Jan 2026 17:53:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 05/15] xen/riscv: implement stub for smp_send_event_check_mask() 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: <837c863f5995cc4371e82b481211b053656ec7e7.1766595589.git.oleksii.kurochko@gmail.com> <319e6162-7a5b-4030-ae9f-a86a48e73605@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <319e6162-7a5b-4030-ae9f-a86a48e73605@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/7/26 4:47 PM, Jan Beulich wrote: > On 24.12.2025 18:03, Oleksii Kurochko wrote: >> --- a/xen/arch/riscv/smp.c >> +++ b/xen/arch/riscv/smp.c >> @@ -1,3 +1,4 @@ >> +#include >> #include >> >> /* >> @@ -13,3 +14,10 @@ >> struct pcpu_info pcpu_info[NR_CPUS] = { [0 ... NR_CPUS - 1] = { >> .processor_id = NR_CPUS, >> }}; >> + >> +void smp_send_event_check_mask(const cpumask_t *mask) >> +{ >> +#if CONFIG_NR_CPUS > 1 >> +# error "smp_send_event_check_mask() unimplemented" >> +#endif >> +} > CONFIG_NR_CPUS is 64 by default for 64-bit arch-es, from all I can tell, also > for RISC-V. And there's no "override" in riscv64_defconfig. How is the above > going to work in CI? Then again I must be overlooking something, as the config > used in CI has CONFIG_NR_CPUS=1. Just that I can't tell why that is. It is 1 because of the defintion of NR_CPUS in KConfig: config NR_CPUS int "Maximum number of CPUs" range 1 1 if ARM && MPU range 1 16383 .... ( all other range props are condtional and there is no RISC-V in dependency) so for RISC-V "range 1 16383" used and CONFIG_NR_CPUS is set to the minimal of this range, so it is 1. > > And no, I'm not meaning to ask that you override NR_CPUS (and wherever such an > override would live, I think it would better be dropped rather sooner than > later). Instead an option may be this: > > void smp_send_event_check_mask(const cpumask_t *mask) > { > #if CONFIG_NR_CPUS > 1 > BUG_ON(!cpumask_subset(mask, cpumask_of(0))); > #endif > } > > (I can't tell off the top of my head whether an empty mask may be passed to this > function. If not, cpumask_equal() could be used as well.) I will double-check. Thanks for such hint. > > Of course the #if may then not be necessary at all, and a TODO comment may want > putting there instead. With suggested above approach, I think it isn't really needed to use #if. Thanks! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Jan 12 17:05:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 17:05:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200826.1516653 (Exim 4.92) (envelope-from ) id 1vfLM3-0007jR-8L; Mon, 12 Jan 2026 17:05:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200826.1516653; Mon, 12 Jan 2026 17:05:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfLM3-0007jK-4k; Mon, 12 Jan 2026 17:05:23 +0000 Received: by outflank-mailman (input) for mailman id 1200826; Mon, 12 Jan 2026 17:05: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 1vfLM1-0007jE-Hp for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 17:05:21 +0000 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [2a00:1450:4864:20::42f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id df5ce4f5-efd8-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 18:05:19 +0100 (CET) Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-432dc56951eso1988353f8f.0 for ; Mon, 12 Jan 2026 09:05:19 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5fe67csm39547094f8f.40.2026.01.12.09.05.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 09:05:17 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: df5ce4f5-efd8-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768237518; x=1768842318; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=wTtmBTU4kNH1IWb+Xjd+xM8qXCkvXEN9Ou6kdUhR6ZE=; b=Ky6ktDt/FtQHZjXx7hve8l8ZAA8v0K72bFC53eZdc10tAC0pqQQP62I/nUVq7iNElz RVqWMIZUcvR3qkICFkPvSgpUefBc1CokupMOcBfyfyCt81y6SVu/nKx8hQTdiGE5y4ZO AHV/+steWBfnUh3+omfEitusuJfkmoSsvakyL6VGOIj6vOfJkCVN53njmpEUmRSzwiNm 5sGqEHhIWX5Tes5VnxpeS0/x93MvnYWuwDYHAy/djgFVlHv2FZamUDtyANatxCXqrIzk JWpyEXWQ4rhVbzuyw0spaCM4BfwTsKReMxYLnqtP9hqZZ/8f4PSgxub0z4JSAM72ok+n oB1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768237518; x=1768842318; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=wTtmBTU4kNH1IWb+Xjd+xM8qXCkvXEN9Ou6kdUhR6ZE=; b=En2PDIISwiItZ+XRiCiFkQpS3ybaZ/1yGT4zSJAHdRGf/Ojx3XzJeH5kayU2v5z4ny x/yfoX0ycJ4B+ZkWyTF77uN4wZZc9HAT2yyzcjUJz8sW675wEwtX0tjQnH+P0evIQZPk XH0f7b5JcSiiwyzA2+QDAqtA4UdX3Ua8vKW8VwqrmBP3XqqFtEUAMgnQ5P91W4+YadPs X0Dl/pp1s8IjXegWLYnVosnNl8yVt1vqwLjMkO2L1Ph5LJ717HImMXEFIVobQMPq1hMl jwNvhFT8bY9DvD6qKjqf0Fr4pYoCSt4vkFGsJH3Cf+InfDYGP3+fkW2twfUUPp1a4zg3 SxNg== X-Forwarded-Encrypted: i=1; AJvYcCW4Uflqpfk20RQdIRfggE/hGHMTxa5k12lUQ1ut0V+osXuT4yb63Rwgt7n9sXfQ/c/Y0y9tOEqj3Wc=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz6m3LQWmYBjQNM4sRU15US0gzCAFN3Kr1GWXlEPUyv4CYLCKuJ tqel84coL/T/QZ5XPDLGeX+ep+yevK66jYOXohx2et0G1q/Jy3+l86Z60zWqTtaRew== X-Gm-Gg: AY/fxX4igsK8Hh39nkKIXZZq0Rq9IWq6eP25GED0IP0x1Oq0mUymJk8asubK26vV9L2 X/2S99Lk7KoSep/vb0/pNQsdb51H5+iyBrKvwW0LOHwcWU4ait5pikUxwCA+gJmVpCRGanPrpN4 2vFLk0zf9ShYZvLmYQM1GltoG7ulFoBBzuJ0f9FGhSuzQMh66gxgUS00w9teliakez6yEw8atgj 6DOYsZASKMvShKKY/nmAhR2iIFUqIBNLFxpS0RdY4ncngg92hLeXcZnxUb9Mo7AzwxkFsTDh99h 2zVeZrL98QznA6Qsx2laofr3o3NkCPfzpvrrjNt6kjG213Cu3o7tFIsU6snrU3Lv5/EzJBc7F4d HkWeQvCmno304Q4+jI9Lm5IQhdL7YsCplzo0xSEizRkJOc7GzfwiaBqkX7IZv4QVOea4AIrZDZv tujOWJy/cTh7JqVskWQI6iEW5P2CLEQhIiDaf42IcQduy4MTUZQDEE2nEMT3j3lRlJap/HqOlrv ZI= X-Google-Smtp-Source: AGHT+IETQYhU7EnTreROmbs2yYrYabD3sprTvXoeMXy+d1jgNmAZUaXONIeprSoTjqIFlnSx/NSKSg== X-Received: by 2002:a05:6000:2508:b0:432:b951:ea00 with SMTP id ffacd0b85a97d-432c37d2f37mr21534861f8f.51.1768237518243; Mon, 12 Jan 2026 09:05:18 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2026 18:05:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 05/15] xen/riscv: implement stub for smp_send_event_check_mask() 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: <837c863f5995cc4371e82b481211b053656ec7e7.1766595589.git.oleksii.kurochko@gmail.com> <319e6162-7a5b-4030-ae9f-a86a48e73605@suse.com> <94c0cd09-7aaa-4ae1-913e-57d883916682@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: <94c0cd09-7aaa-4ae1-913e-57d883916682@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12.01.2026 17:53, Oleksii Kurochko wrote: > On 1/7/26 4:47 PM, Jan Beulich wrote: >> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>> @@ -13,3 +14,10 @@ >>> struct pcpu_info pcpu_info[NR_CPUS] = { [0 ... NR_CPUS - 1] = { >>> .processor_id = NR_CPUS, >>> }}; >>> + >>> +void smp_send_event_check_mask(const cpumask_t *mask) >>> +{ >>> +#if CONFIG_NR_CPUS > 1 >>> +# error "smp_send_event_check_mask() unimplemented" >>> +#endif >>> +} >> CONFIG_NR_CPUS is 64 by default for 64-bit arch-es, from all I can tell, also >> for RISC-V. And there's no "override" in riscv64_defconfig. How is the above >> going to work in CI? Then again I must be overlooking something, as the config >> used in CI has CONFIG_NR_CPUS=1. Just that I can't tell why that is. > > It is 1 because of the defintion of NR_CPUS in KConfig: > config NR_CPUS > int "Maximum number of CPUs" > range 1 1 if ARM && MPU > range 1 16383 > .... ( all other range props are condtional and there is no RISC-V in dependency) > so for RISC-V "range 1 16383" used and CONFIG_NR_CPUS is set to the minimal of this range, > so it is 1. I fear I don't follow: Why would the lowest value be picked, rather than the specified default (which would be 64 for RV64)? That's what I thought the default values are there (among other purposes). Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 12 17:15:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 17:15:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200836.1516664 (Exim 4.92) (envelope-from ) id 1vfLVl-00013D-47; Mon, 12 Jan 2026 17:15:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200836.1516664; Mon, 12 Jan 2026 17:15: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 1vfLVk-000136-VM; Mon, 12 Jan 2026 17:15:24 +0000 Received: by outflank-mailman (input) for mailman id 1200836; Mon, 12 Jan 2026 17:15: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 1vfLVj-00012z-U6 for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 17:15:24 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 46b8ff98-efda-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 18:15:22 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CO1PR03MB7963.namprd03.prod.outlook.com (2603:10b6:303:270::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Mon, 12 Jan 2026 17:15:18 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.005; Mon, 12 Jan 2026 17: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: 46b8ff98-efda-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lMaTElTkJWbHiQviaqaYE4Ntx3Gy6J1b4GvcPxo/KhSbwfa3SLsE7XopA/WwtJmU8EtmzqyjXJBcAI/60lcsx43XJJzixAJOG6k3TSR5eIOBDKIjTaFYV89pwCB6VpO8nckqZx3rPUO6j1QeRepaypMHYM91sAGVBMCoGMPfrP9i5zyaWy8kvwn7Ex+M+Pw1jDnL7bySPFvSTjUCy2OGTdJJ6taqWVJsK9W6XkjJ9dWwU1sp8PLrJaLdWfXoZUAaBAzaIPaFbHTwG9B5BLI74ilYENnCTx1jVr3iML1CPDCFrx+Y1/AkH3MdOpHHOKER/Tu7jgYLR+5dE8M3DLMOeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Wdmw36I2Tjr5R9rmVJUMCaGAEE59qwfqkksNPRBCrSc=; b=q5J8Ht15IaDUrxAkL3Dv6egfTRA2hnIvw9oGypsgfjsI4yrxTwsAbjjYC+WO8iOpqRcwMtwBPI4X8iUGtu5YsGyyPA/4nfL5+wX9rhvnRGFA3taXLFTmbZG0XqjJ1EKrv/tPK9c+HLcMem4CDRCInmRPxtsT7yY/rxNCzBBougXSD5hEgbLWafqO13dis0x57/KE8aDHv8Dvg1Z/MlqBkSJh098eOx31UOT1eqfE6u1RXCxshH5g8ipUYKUXUDam8oNPKvpn3tTHXK/+NtTW7loOyGF2RZYoqDFxuLT1MSwjSVlEFlakUm79NYWAS+L0xl+2oA2TAZ2qvMtwA+yQUQ== 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=Wdmw36I2Tjr5R9rmVJUMCaGAEE59qwfqkksNPRBCrSc=; b=sGulPUJTnPpdZFu9i7sAPogawY7gIAexpKmXeTKp7+/irEmYrqBghNcd7WjUiggqwwNHemYJG0a/RmrSPvWq7Ym04dnsKHcE4KEAkQcCn7NV4mgu+m+BlEXmw19vb7Bgmqd34q32PNYEWzZGqy0RClLTYVO23TwuHM5LIZBdd1E= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <96f4f3fe-46c4-4854-af55-d5adea07c847@citrix.com> Date: Mon, 12 Jan 2026 17:15:14 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Doug Goldstein , Stefano Stabellini , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= Subject: Re: [PATCH v2 2/2] x86/ucode: Add Kconfig option to remove microcode loading To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260112150259.74535-1-alejandro.garciavallejo@amd.com> <20260112150259.74535-3-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260112150259.74535-3-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0081.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:190::14) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CO1PR03MB7963:EE_ X-MS-Office365-Filtering-Correlation-Id: fbd884c1-c503-4904-03b0-08de51fe28fb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|366016; X-Microsoft-Antispam-Message-Info: =?utf-8?B?Z1VmQytJZnNGYXNBUXdBSjRtSlM3dVlqUDljS3pyQkU5dlFURmEyQzdiWlBZ?= =?utf-8?B?ZGxZclRXSVkwQVpkTFZyS0FodkRBZFA1d3lmM1hkT2xoZlFTUm5zOE5BckRv?= =?utf-8?B?WnRJMTZ6U2dNMUZSMEVIZGhDd1BDS0ZyRmljMCtGTEVaS2RrS095alNISU9P?= =?utf-8?B?Q3hrQ0Y3Wm1TQi9hSStBa3Z5amUyR2xkYzdvZHg1ZmE0Y2kvaXNQYllzQUZq?= =?utf-8?B?SFVvS1FIVGxaVVF1cUVPdU5sbWFWOVBucGgxU3pKcmtwMXBncHMxYzJrd2Fj?= =?utf-8?B?ZjBFZnB2Y28yQkhYNGd1OGZJRHc3eFh3eW8waEszd0t3dnFhaXFNRndsZmhR?= =?utf-8?B?dGlZbWFOZ2hqck50ckpxQXF5cEVyb1VhMVQxaDNCOE5BU3NOcURsdWJseDF5?= =?utf-8?B?aHpvbmkxL1o1SVFFSVovbVpkQkpWK3k4RU5vMGM5SUZWN3NnNzc3RlM5K2ZD?= =?utf-8?B?dkNQTUlqUVdoTDBLbzMzZmt1M3lzY0pqYVNVeW5QTVBSVjhxbjVXTTBDVm5o?= =?utf-8?B?WnpCWU5VVitTcVBCRFpyY29RK2lDNS85WGR1WmlOZ3JYTkM0cXdLeHdQYjFS?= =?utf-8?B?S0hYOVVGNndkUUVpTHFuUUdSTURpR0wxV3ZJR0oxTHo0VGxtMFNPaXY3Y1V5?= =?utf-8?B?WXRVRkkzdjBFU2Q0K0Z0OUNQUzByaFI0cXlQL1ArVk5ycFNldUEzSVdlNmNE?= =?utf-8?B?N2xXZElXZ0lEVGJQRk5WZDlpS29QUjRUODZpcUFpdkpoLzI4b3F5dTM3Mk9O?= =?utf-8?B?Q21paHhRNlBOdHl0dHZ1MFpjRytXOTUrZEd5ZzRQZHZiNlkyM0ZycnkvYzFW?= =?utf-8?B?SDlpZjU5SjUxWXgwUENxcW9EeGpIODdCL3d1alkvSE05dVF2bThYTExkYXFV?= =?utf-8?B?WHJjSStPNDhGRXI0YU9FdnF4bGZGaEppbS9TaTh3K09ZSlozZS9YWDd5Uysx?= =?utf-8?B?WEhxSlNrSnVibldrcndpNmE5V3RLM3o2MnkvQkNMRXZxWG8wUDZDVERDRHVl?= =?utf-8?B?VjVnZldIVlJXSjdqNHJlSVJtTWI3MGc5Q25IUE1Va2xobWEzRlpNalRKckRI?= =?utf-8?B?MDI2cEhIZkxJMFUwWi9Vbm85RlBjNGhGcFh2MzlHYi9Kenpxc3ljT3dDKzZk?= =?utf-8?B?YXQzOHdteWZ6VGdnNnhJek5FYWpmUjFES1EvQjFnUFlJY1BjUXpaZkFUK0VY?= =?utf-8?B?cGt1T1hWSTViQzk4UHhJNG84VWYraUJEZyt1YnhTL2ExZ3djTmhsUVp0ZWZi?= =?utf-8?B?dmdTYnBLS2Z0M1FVRTZiaG9oc3ppQlhJdmdtYnY4ZWpENUZtL1h0aDlDc1Yw?= =?utf-8?B?QVRXSjErend6ZHpKQnJOajlIeHJLRStid3dnYTRhcGU1L3BKTEx6WHZjRjI3?= =?utf-8?B?MVlPRTdkbGlPY3FoMG5ORm4wKy9QS2F1NnIzcWlObGRacDlUb3RSNk04U0Nk?= =?utf-8?B?S1U5ZERjWHFXWHp3QkpDU0NuUHovWE9yZGFXYmlRLzBVRlhEQXZibURWRmdx?= =?utf-8?B?N3RrSzRRbEd5TkZZSkp6ZG96SW9FTXJTUllIZHlCZjlVN0FSRXNzZGcrczdG?= =?utf-8?B?dzJZMU9FWi9YU25kSkNacUFTK1NReTJIbmNFS1JUcXM4ZHRJQ1QyOVd1M0lQ?= =?utf-8?B?VXZGV3VpdXlpSWVCUGNtbDl4ZjdhYmRSL3ZRZjREMzFWSnZIMkJOODRJRG1I?= =?utf-8?B?QXkvVGNKYk5hOFNxWlJMNGtnZlc3NlBPa25wa3oxZldRdDVCQ1J1ZzdRYmlO?= =?utf-8?B?R0FRaW5WdldHZzNhN0g4ZWVVNVg5TWZRZDBONngvQ04zNXlLd0NUeEh4WDFO?= =?utf-8?B?aEYveUQ0UkIzS015NVYzdWNFUnhxNzR1R3czNXlnWmFHL2hyMHlRRnBJSE83?= =?utf-8?B?OHNJS0YzTnhOOW9JOU9iTTdOVjBodkY4RG5Rc2MwcHBjUHR6UTRNSXN0MVhB?= =?utf-8?Q?krH+ziPCGAk21m5q9qmXW6N4Xaj11+7g?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WXVmTy9EQ3NrOTZpNGZkRktTNXR5TlNXN0FESmtpZWQyd3d2Z2hRSjBENm94?= =?utf-8?B?aitXbEYzd3A0ejd4aWsvS2lRTExIVGVjV0JkLzJvZWlkUzRPSUpXYS9iRkFp?= =?utf-8?B?MzdhRVo3VjIwd2Y4Lzgza29ja1VHSTJEYkZaMGkwT29JWkd6S2VRT2pTblhJ?= =?utf-8?B?YytvK1hOQjNQdXI0YnJYazZjY2JkVVBwMTFJN1VzVWRNc3Q5WGlqRWY1bEQ5?= =?utf-8?B?WHI5QkgxRXVjNlVZZm1jNWdTbWZmNkw2ZlBxT211OVEvSkg5UjZzZVhJYnIr?= =?utf-8?B?bUxWZUNrR2tQUG16WWQ1R0x1N2hueW1EKzgraWszTlh3VGc0bE1OYWp4Qity?= =?utf-8?B?YUhjeVZxUTVEQzVwcURUNEtOVEo4RHhOdFRaUVdJQUZGdlNzLytRb3pnVWxF?= =?utf-8?B?STlzTHZBYVBXc0hkdWphdkQ4dHNGeU9BNDA1Tm5JL20vSGVzZmxUMGxxYjlp?= =?utf-8?B?amVNRGRhV2ZMbHdYaXBCSWdGNllRQk5Pak5VazNyYUd0Smc3VXZjQWQ2c2x4?= =?utf-8?B?eEc1Q2lSNENaMW9mU1RQMENMK2t1N1lvRW0rd2EyMmlIa0xEeTZnZU5FVkNp?= =?utf-8?B?ditHbmZRL2wwc2VhZkZDSHd5eU1NVTZyWlo0dENuVjRjZ2FtQktUemZkaHpi?= =?utf-8?B?OXFab0dBeVN2SVB0eE1SbUJZLzBRMmVwWldickNiSkluRWMwWXpEZUpSODJC?= =?utf-8?B?ekN6TFNISFBjWkg3WHBoVWo5c0J3N29laDFSa1ZVaVZCYjk0QWRXMXQrMGJU?= =?utf-8?B?Y1pvdVZOTW9kRlZudVlTaTh5NHRFZUhpUlhoMlNJaFVyTXFBaTdPYk5KY1Fi?= =?utf-8?B?SlJ2TUhTQlRGSW9aRFpRY3Zyd0dCckRMVUJaVXA3Vzg5SnRjZCtYVWIwWloz?= =?utf-8?B?aXpSb0pzT3plRVlPc1l4ZWh5TzkybTdsb2dqdmFqaWdoaVROWmNYM0tsWGdo?= =?utf-8?B?c1RoSHFUSEtVaHJ3M3R6RmFLQUtFQ0lqMnpKZGN0L1UxRU85NkVsVzV1NWJu?= =?utf-8?B?S2JDZ2pJa1hsaHAvT1ViV3djdytzTlJqRXRRQlpGN3FQS09JWkJudmt6SmZn?= =?utf-8?B?UThSWnI1aEVtT0QyUVBEMVdXam5JdWE0WlIvSzdudWJUWGZFZU80TVVuc2Jz?= =?utf-8?B?TWJrc2F0ZDNmZ2htS3UxTGpsVFJxcE9FbWdHZXdRdWRYL0F6d3BnRmN5R1VE?= =?utf-8?B?YXdMcG00R3dJbUpHRTNlMjNTV3dQS3VjWnNrVU44aURqMmplZ09Xek11dmZj?= =?utf-8?B?OTZ1THpMbWJQeDBwOGNUMWtmZHdaS20xUDlMV1RSUUtqQVhBSFU4MXREK2lO?= =?utf-8?B?ajhNbmxCY3hzUzhzaXVzR2hoeEx2cEQ1WjlqWTIyTmZsVEpOY1BBckdWakt1?= =?utf-8?B?T3VpdmcvMG16ZTZ2WEFnQ3ljc1NOVU5URVJ1TGczVk1iOUx6MjgxV3VITTQ3?= =?utf-8?B?Rkx6aTUvclY5dnlRcEVqeGpoOFNTRjcxUnhyNmFlaURhcHl5R3VncDV2OVdn?= =?utf-8?B?VWx4Z1hSTjJiakprcVJlZXJWWG9LOVJ4d21jM01CUmpUNVdCRWVnV0NxMVhL?= =?utf-8?B?MUdMS29jNSthTkVhK0U3cThScUxxU1k3MS8rVTBCY0d1d3Q4UE1tOTNXdTBC?= =?utf-8?B?Myt1LzhITlROUDRwZVZBUFlLS3JuUTErdGVnYmNVYjhXenJkbUdTRmJac0F6?= =?utf-8?B?RmhOYlBqWjYzaSs2bVlscjdFQ2pPNHdGbVhzdUJkSkJhN0JuYjhqQjZxNFhS?= =?utf-8?B?QVVJL2RRZGM5ME9iaXp1MVgzTXpPSjlqZ2tXY2UzZXFtdGJacGpjZGlNQjNJ?= =?utf-8?B?VHJQazN1VUovV3FFNmlQZkhveW9Ieks2bGY5WjhlaUUwWGlZSFdVV3RkK0lo?= =?utf-8?B?bm83T3ZJNUo3cXVodmxaMXg2a0VhSmMrTThWZmFmS3hMcTBIZ21kK2Urb2Nn?= =?utf-8?B?SmpVTnVQWWVsRjJQSXIyVXZoaW1XckoyWHhzQTU3cUs2d0JjSHFzNkVLdysz?= =?utf-8?B?TFhSQy8rNngvaW4rUFdTdWFjdnRpU0hDaDNLWnFHU0JCVEZSNWZ2QXR0ZVpO?= =?utf-8?B?UksyY3BrUUs4TWlmcWQyenRCRVpnZSt3UFpTcWZINDJrYXBlK2ppV2VBU0Z6?= =?utf-8?B?M0MrSElNM0VCR3BhaXpRdUpGcmFVd1Y1MXhLWlF1Uk0xVnBvU1VEMUpvRmpt?= =?utf-8?B?K0ZxTmtEUHl2OWsxU1pGTEE4ZTI2RzFDaFBBUWszWitNZTAxZjdTeHZSMFlF?= =?utf-8?B?VmdhZkZmZDdGRVFyMzVNcjRneHVRQVpSN2pKVTBMVEhyaWxoSXN5MTJmSzlk?= =?utf-8?B?NWQvenEzZm5oRnRheVprSHdmMFVhM3ZsVTZJd3NXV0JPMFNMY0ZNUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: fbd884c1-c503-4904-03b0-08de51fe28fb X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2026 17:15:18.5968 (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: iUbG6NhKWlHo9g+qjmzhiuIlISpcKS1O7dPVgzw2zE16LTgkepIMdjpp3q+N3f6FiGifJz+GldIr6JH5mYgEcwZAc5xm3aDVS5thVs4pP0U= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7963 On 12/01/2026 3:02 pm, Alejandro Vallejo wrote: > automation/gitlab-ci/build.yaml | 2 +- > docs/misc/efi.pandoc | 2 ++ > docs/misc/xen-command-line.pandoc | 4 ++-- > xen/arch/x86/Kconfig | 14 +++++++++++++- > xen/arch/x86/cpu/microcode/amd.c | 22 +++++++++++++--------- > xen/arch/x86/cpu/microcode/core.c | 25 ++++++++++++++++++------- > xen/arch/x86/cpu/microcode/intel.c | 16 +++++++++------- > xen/arch/x86/efi/efi-boot.h | 3 ++- > xen/arch/x86/platform_hypercall.c | 2 ++ > xen/common/Makefile | 3 ++- > 10 files changed, 64 insertions(+), 29 deletions(-) Much nicer in terms of (non) invasiveness. First, please split the rename of CONFIG_UCODE_SCAN_DEFAULT into an earlier patch. > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc > index 50d7edb248..866fa2f951 100644 > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -2748,7 +2748,7 @@ performance. > ### ucode > > `= List of [ | scan=, nmi=, digest-check= ]` > > - Applicability: x86 > + Applicability: x86 with CONFIG_MICROCODE_LOADING active > Default: `scan` is selectable via Kconfig, `nmi,digest-check` You want to include this too: diff --git a/docs/admin-guide/microcode-loading.rst b/docs/admin-guide/microcode-loading.rst index a07e25802fab..91668e6f9b3f 100644 --- a/docs/admin-guide/microcode-loading.rst +++ b/docs/admin-guide/microcode-loading.rst @@ -23,6 +23,9 @@ TSX errata which necessitated disabling the feature entirely), or the addition  of brand new features (e.g. the Spectre v2 controls to work around speculative  execution vulnerabilities).   +Microcode loading support in Xen is controlled by the +``CONFIG_MICROCODE_LOADING`` Kconfig option. +    Boot time microcode loading  --------------------------- while changing the docs. > > Controls for CPU microcode loading. For early loading, this parameter can > @@ -2773,7 +2773,7 @@ microcode in the cpio name space must be: > - on AMD : kernel/x86/microcode/AuthenticAMD.bin > When using xen.efi, the `ucode=` config file setting takes > precedence over `scan`. The default value for `scan` is set with > -`CONFIG_UCODE_SCAN_DEFAULT`. > +`CONFIG_MICROCODE_SCAN_DEFAULT`. > > 'nmi' determines late loading is performed in NMI handler or just in > stop_machine context. In NMI handler, even NMIs are blocked, which is > diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig > index c808c989fc..1353ec9a3f 100644 > --- a/xen/arch/x86/Kconfig > +++ b/xen/arch/x86/Kconfig > @@ -331,8 +331,20 @@ config REQUIRE_NX > was unavailable. However, if enabled, Xen will no longer boot on > any CPU which is lacking NX support. > > -config UCODE_SCAN_DEFAULT > +config MICROCODE_LOADING > + bool "Microcode loading" > + default y > + help > + Support updating the microcode revision of available CPUs with a newer > + vendor-provided microcode blob. Microcode updates address some classes of > + silicon defects. It's a very common delivery mechanism for fixes or > + workarounds for speculative execution vulnerabilities. > + > + If unsure, say Y. Please don't re-iterate the default.  It's a waste.  As to the main text, that's not great for the target audience of a distro packager / power user.  How about: --8<-- Microcode updates for CPUs fix errata and provide new functionality for software to work around bugs, such as the speculative execution vulnerabilities.  It is common for OSes to carry updated microcode as software tends to get updated more frequently than firmware. For embedded environments where a full firmware/software stack is being provided, it might not be necessary for Xen to need to load microcode itself. --8<-- > diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c > index fe47c3a6c1..aec99834fd 100644 > --- a/xen/arch/x86/cpu/microcode/core.c > +++ b/xen/arch/x86/cpu/microcode/core.c > @@ -44,6 +44,9 @@ > > #include "private.h" > > +#define can_apply_microcode(ops) (IS_ENABLED(CONFIG_MICROCODE_LOADING) && \ > + (ops).apply_microcode) I don't think this is a useful macro.  It's used 3 times, despite ... > @@ -613,6 +618,7 @@ static long cf_check ucode_update_hcall_cont(void *data) > return ret; > } > > +#ifdef CONFIG_MICROCODE_LOADING > int ucode_update_hcall(XEN_GUEST_HANDLE(const_void) buf, > unsigned long len, unsigned int flags) > { > @@ -622,7 +628,7 @@ int ucode_update_hcall(XEN_GUEST_HANDLE(const_void) buf, > if ( flags & ~XENPF_UCODE_FORCE ) > return -EINVAL; > > - if ( !ucode_ops.apply_microcode ) > + if ( !can_apply_microcode(ucode_ops) ) > return -EINVAL; > > buffer = xmalloc_flex_struct(struct ucode_buf, buffer, len); > @@ -645,6 +651,7 @@ int ucode_update_hcall(XEN_GUEST_HANDLE(const_void) buf, > */ > return continue_hypercall_on_cpu(0, ucode_update_hcall_cont, buffer); > } > +#endif /* CONFIG_MICROCODE_LOADING */ ... this use being redundant.  Just expand it for the two other cases and consistently use IS_ENABLED() in view. > @@ -907,10 +916,12 @@ int __init early_microcode_init(struct boot_info *bi) > * > * Take the hint in either case and ignore the microcode interface. > */ > - if ( !ucode_ops.apply_microcode || this_cpu(cpu_sig).rev == ~0 ) > + if ( !can_apply_microcode(ucode_ops) || this_cpu(cpu_sig).rev == ~0 ) > { > printk(XENLOG_INFO "Microcode loading disabled due to: %s\n", > - ucode_ops.apply_microcode ? "rev = ~0" : "HW toggle"); > + !IS_ENABLED(CONFIG_MICROCODE_LOADING) ? "not compiled in" : > + ucode_ops.apply_microcode ? "rev = ~0" : > + "HW toggle"); > ucode_ops.apply_microcode = NULL; > return -ENODEV; > } Don't complicate this messy printk() further.  Just exit early; it's not interesting to read "not loading microcode because it's not compiled in". This is a rare example of a subsystem where it remains partially compiled in, and it's even possible to write such a printk(). > diff --git a/xen/arch/x86/cpu/microcode/intel.c b/xen/arch/x86/cpu/microcode/intel.c > index 281993e725..d9895018b4 100644 > --- a/xen/arch/x86/cpu/microcode/intel.c > +++ b/xen/arch/x86/cpu/microcode/intel.c > @@ -404,21 +404,23 @@ static bool __init can_load_microcode(void) > return !(mcu_ctrl & MCU_CONTROL_DIS_MCU_LOAD); > } > > -static const char __initconst intel_cpio_path[] = > +static const char __initconst __maybe_unused intel_cpio_path[] = > "kernel/x86/microcode/GenuineIntel.bin"; > > static const struct microcode_ops __initconst_cf_clobber intel_ucode_ops = { > - .cpu_request_microcode = cpu_request_microcode, > .collect_cpu_info = collect_cpu_info, > +#ifdef CONFIG_MICROCODE_LOADING > + .cpu_request_microcode = cpu_request_microcode, > .apply_microcode = apply_microcode, > .compare = intel_compare, > .cpio_path = intel_cpio_path, > +#endif /* CONFIG_MICROCODE_LOADING */ > }; > > void __init ucode_probe_intel(struct microcode_ops *ops) > { > *ops = intel_ucode_ops; > > - if ( !can_load_microcode() ) > + if ( IS_ENABLED(CONFIG_MICROCODE_LOADING) && !can_load_microcode() ) > ops->apply_microcode = NULL; > } ! ||, surely? > diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c > index 79bb99e0b6..5e83965d21 100644 > --- a/xen/arch/x86/platform_hypercall.c > +++ b/xen/arch/x86/platform_hypercall.c > @@ -307,6 +307,7 @@ ret_t do_platform_op( > break; > } > > +#ifdef CONFIG_MICROCODE_LOADING > case XENPF_microcode_update: > { > XEN_GUEST_HANDLE(const_void) data; > @@ -327,6 +328,7 @@ ret_t do_platform_op( > op->u.microcode2.flags); > break; > } > +#endif /* CONFIG_MICROCODE_LOADING */ You mustn't #ifdef out a case like this, because it causes the op to fall into the default case, and some of the default chains go a long way and make unwise assumptions, like hitting a BUG(). Always use this form:     if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) )         // EOPNOTSUPP and leave the case intact. > > case XENPF_platform_quirk: > { > diff --git a/xen/common/Makefile b/xen/common/Makefile > index 92c97d641e..1e6c92e554 100644 > --- a/xen/common/Makefile > +++ b/xen/common/Makefile > @@ -65,7 +65,8 @@ obj-y += wait.o > obj-bin-y += warning.init.o > obj-y += xmalloc_tlsf.o > > -obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo unlz4 unzstd earlycpio,$(n).init.o) > +obj-bin-$(CONFIG_MICROCODE_LOADING) += earlycpio.init.o > +obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo unlz4 unzstd,$(n).init.o) > > obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o) > In a prereq patch, please move earlycpio out of common/ into xen/lib/.  It shouldn't be tied to CONFIG_MICROCODE_LOADING like this, and it can simply be discarded at link time when it's librified and unreferenced. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jan 12 18:47:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 18:47:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200859.1516673 (Exim 4.92) (envelope-from ) id 1vfMx5-0003kQ-KS; Mon, 12 Jan 2026 18:47:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200859.1516673; Mon, 12 Jan 2026 18: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 1vfMx5-0003kJ-H8; Mon, 12 Jan 2026 18:47:43 +0000 Received: by outflank-mailman (input) for mailman id 1200859; Mon, 12 Jan 2026 18: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 1vfMx3-0003k8-QV for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 18:47:42 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2ac9cd09-efe7-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 19:47:39 +0100 (CET) Received: from SJ0PR13CA0110.namprd13.prod.outlook.com (2603:10b6:a03:2c5::25) by BN7PPF9C6E5285F.namprd12.prod.outlook.com (2603:10b6:40f:fc02::6db) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Mon, 12 Jan 2026 18:47:31 +0000 Received: from CO1PEPF000042A9.namprd03.prod.outlook.com (2603:10b6:a03:2c5:cafe::4a) by SJ0PR13CA0110.outlook.office365.com (2603:10b6:a03:2c5::25) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.4 via Frontend Transport; Mon, 12 Jan 2026 18:47:30 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CO1PEPF000042A9.mail.protection.outlook.com (10.167.243.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Mon, 12 Jan 2026 18:47:30 +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, 12 Jan 2026 12:47:27 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2ac9cd09-efe7-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=r3aomvotn7PhLjs2Mtflzzst6dc3d13FN8kncbmWZUVeuF/cFbUgjX6uP8mT8McP+7nvyhoCIlr0CjUQoqDHJ+HXyhlG5LCFJXB7vaR4Avg0RNBEAuJm8zHaRDoxSDWhNkg6k/fEMbSZdDN6lvg7PZsWPgKWxPbpkNHAQLBbdRaAYRvoqLKjGeoU9Ib0HzvoynK3hpgoy0HYTbsRfgDIEiMoAKlSKLcfOhiRUCmSeVSOnU3GOoIGpwVZ4fAlsHOcJ+D+YBCsbtuS8+mNkA7IO1xn5I8U6/D25Z7TbWzUqeJkX8D9RaC+lWEm9tLlhrS5oZRRllI8CkZFlbxZpTwR+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=1cLo5ZJJgR+kUYhxe4pP2dcgzYsXbhOtqolvYjrLMq0=; b=K/jqZ0Fx5j5Aajmu5Zc5en/oZjlNstEX1TICgZpVaLmuykz2gGKmyTn1GbuxR0LRUxPf3E5yZhJFhQwzTY/8Osf5OYiRLSGihFMbNuXH3ePsnJ0OMotkk3aaF9Y1x6ffncltMDg0i3/5Qinv+5VsydSFIlTQ8VjE6ijH7l7Su3LiG474aEmxCUFKcb/H0ZlcYkggKGJsVeQEQNMjLtY7EkDFc0zvA9/8oERkzIPW+h02kIO7LO+BRwdVhdRNlpqFT1+yfIVAPG+o1LZbnQwvBuMxbNCKwf0pFX413CZKA40jrdp2E6JIglZtUWJGySK7mg9rfThZS0ERGjIYGIugoA== 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=1cLo5ZJJgR+kUYhxe4pP2dcgzYsXbhOtqolvYjrLMq0=; b=K77cTFgWBXR5rfUdFf2PhGwgmMz8nHykXl0wZdg5g/m1gdhMgYwoANUztFRU3OgxcFKrh4VN2suwq1DTfPXX7xNqNG3xRJEK4t4oGNUrE/vsRmX2r+2MW+bvLfbiM9AK+Hmjp+7UCqmArpIUzraZZqnylG1fbzKO5fVF6K/cmIs= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 12 Jan 2026 19:47:24 +0100 Message-ID: From: Alejandro Vallejo To: Andrew Cooper , CC: Doug Goldstein , Stefano Stabellini , Anthony PERARD , "Michal Orzel" , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" , =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?= , Xen-devel Subject: Re: [PATCH v2 2/2] x86/ucode: Add Kconfig option to remove microcode loading X-Mailer: aerc 0.20.1 References: <20260112150259.74535-1-alejandro.garciavallejo@amd.com> <20260112150259.74535-3-alejandro.garciavallejo@amd.com> <96f4f3fe-46c4-4854-af55-d5adea07c847@citrix.com> In-Reply-To: <96f4f3fe-46c4-4854-af55-d5adea07c847@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: CO1PEPF000042A9:EE_|BN7PPF9C6E5285F:EE_ X-MS-Office365-Filtering-Correlation-Id: 56e89b3c-e484-4eaf-291d-08de520b0a65 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700013|1800799024|7416014|376014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?NkVPanVWK1I0aUlRUTVDYTZZeHhrd1IyN3VOdG5Banp4bWphT0NwSVdETnJo?= =?utf-8?B?S1I1MDlva1U4b1BkY2N4MWpiNGFoUzRNYjZBUWhLck0wVVBiS0YrczZRTHlp?= =?utf-8?B?ME10c0pYSE11eXgvQk1mSGdPRjdKaW1va3ZadFN2VWNKK0llMmR2emZNUjRE?= =?utf-8?B?VFhvQUZGWHlPUmFGQklnN3hubjU2MFNrRVVRUHQwN1U1VHB1U3E1TFBxLzJr?= =?utf-8?B?V2ZJamwvMTZEOW1oOXdHcEQ3TkJWdnE1dXMxZWxNem1WVUZ2WHNkMUV4Zk81?= =?utf-8?B?TDZuczdiVUN2anMrWWJKWlU2RUplMllCWU1hVHlCcU81MkdWSkkrYXMvU1NY?= =?utf-8?B?RTQrM0JPcXlGcTBsTExhdHFDYk9GMGJ6WGNHZWx6Z252dFUwZTZNLzFQRVh6?= =?utf-8?B?eDgvYWRHbWhHZFFneEU2QWxoR0xlSldnaDVZbk5laVdlanRla29RMmwzS1d2?= =?utf-8?B?bm94SXRBQjcwTDB4aGYyaHVXWmlRTUYwbWZ4Ri95SENMVkorZVg5NGhwRmov?= =?utf-8?B?S0VzRGtPRU5xZnR2ZGFxSjhoNWJwWDZBaENZYmNweVRYeUg3ak91ZGlpVWgx?= =?utf-8?B?WXlDNG5rRC9EUVQ2UVB5L1Z2U1doY1NOOXNKWWtIV083N2FDMm1HVlhmUkhw?= =?utf-8?B?YzRkNDNOTUp6S0dXN3BWbWpOUFRqVlkwT3dUSVFXWnZKUE4zQTdpdGUxRGNs?= =?utf-8?B?Ty9nYW5mVWg0a3h0TnRmZCtobWZPdG5lK25ZTXRCMG5LNm5taS9zLzhHaFRy?= =?utf-8?B?UWdpWVNaczJZM3hlblEwdzltTXJQa0ppdlRKTDNBUWE1RWYwcHExdjFNbk44?= =?utf-8?B?a1dhVTdJdWRUaERjRW9zVy9LQmdDMjZLVHN2SVB0K1VLMDcrR1AzZUNjMWxm?= =?utf-8?B?RUFkQTZ3Q2ZmN0p4RUpKWHFCR2ZteGMycGp5TUlVd01DN1F6Y1VKYnlEN1dM?= =?utf-8?B?Qmk3dTc1bmFRMGtBMVRWL2IvMUo2NFZNVCtJVW9MRzl0YnN0WjRlakh2OENh?= =?utf-8?B?L3RaYjN4bkp6elFCR2Y3Mm1FdXlZOXh5M1J2VXRMTytKTGtZRE5pK0VBRHpY?= =?utf-8?B?RzBDZWl0c0pPVTJhdVF5ZmtPVVE2blc5NGNsT0FBOTlpQjFkQXZJbzA4Q2Fm?= =?utf-8?B?YzVDYktCNjRia3lIQS9pRkw0OGVsd0haSHdXT3E4MDhPUmxpVElTNXBhd3cy?= =?utf-8?B?YkQxd1drK1BRZTBlc2VwTUJuOHpMc3hYWFhwWWs5OWpsREV6aFdjNU5yNWpS?= =?utf-8?B?c0haVGIyU1R1T0ZDalc4SjUzSCtlZlZ3RXh0dkNMU2NXTUtRajRBS1J1Ynpy?= =?utf-8?B?cWVDRlR4Uk9iNUltdFBKNEpXSmlxdWV6V1UxMHdwOUtWYi9IaUhURXNTWkhm?= =?utf-8?B?anZ3L09HN1QrQTlaY3lIbzRReU42Ry9PMFY0RlZiK0t1d1V1N2dHallmZ2hE?= =?utf-8?B?d1kyTU1mejFybk9EQVlHZlZlZ1VXY1ZPUGx1U3p5cHN6Z1ZRZjBleDFoNXdm?= =?utf-8?B?eHJKWUZOZDhSd05YZGs1UFBmMFg2K3M0VURqYXhHM05JcU1EbExPNVdncHFi?= =?utf-8?B?SlEzSlNPblF1NTNQcmk5b1lRWldIUklzVy9uNFhwMkVpMUs1N0lqSlRjc0Qr?= =?utf-8?B?bThUN3UrZFMrYWJzMTE2LytjNkRFMlJ4bGVOdkZVZzhpZVR6VS9DNHRja2dS?= =?utf-8?B?dG1uZm9rVVRCYjY0ck5wUVZoWFhLK01QOUUyVW5qU3A1cjVabnJxZDV2Z2VT?= =?utf-8?B?TDB0WVZvejZIU2ovbFNJTjg4ZnhVVDEvVk93Wi9YL0M3c3FuaWF1RVdTd1Vm?= =?utf-8?B?TUJLR1luSXZIelBUOVdnYjMvU0xQVHh1bTVKejRmaGxySEx5aHRBL3RjZVJT?= =?utf-8?B?ejRKRVFacy9aanNSY1ptdDRwZnRDbndBYjV2aGhoS3E2RUlKUDdTbUFnRHpJ?= =?utf-8?B?RHdqd2YrOGFUMHROT2lJYjRuVjBqMXRkRHlQUktoRFJwTG0wTEQ5WkpPMWpT?= =?utf-8?B?cllOdEFzZUY1WWE5clN4dnp2WW5TSWcrUktWTTUwN1pWcVNmU0tsZmVjc0FJ?= =?utf-8?B?SmVHUmROL0ZBSC9KNWtZS2tpTXhpNmNaSko5ZWMzV3MzN0tKTXhrZFhRRFZI?= =?utf-8?Q?72oY=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(7416014)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2026 18:47:30.4377 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 56e89b3c-e484-4eaf-291d-08de520b0a65 X-MS-Exchange-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: CO1PEPF000042A9.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PPF9C6E5285F On Mon Jan 12, 2026 at 6:15 PM CET, Andrew Cooper wrote: > On 12/01/2026 3:02 pm, Alejandro Vallejo wrote: >> automation/gitlab-ci/build.yaml | 2 +- >> docs/misc/efi.pandoc | 2 ++ >> docs/misc/xen-command-line.pandoc | 4 ++-- >> xen/arch/x86/Kconfig | 14 +++++++++++++- >> xen/arch/x86/cpu/microcode/amd.c | 22 +++++++++++++--------- >> xen/arch/x86/cpu/microcode/core.c | 25 ++++++++++++++++++------- >> xen/arch/x86/cpu/microcode/intel.c | 16 +++++++++------- >> xen/arch/x86/efi/efi-boot.h | 3 ++- >> xen/arch/x86/platform_hypercall.c | 2 ++ >> xen/common/Makefile | 3 ++- >> 10 files changed, 64 insertions(+), 29 deletions(-) > > Much nicer in terms of (non) invasiveness. > > First, please split the rename of CONFIG_UCODE_SCAN_DEFAULT into an > earlier patch. Sure > >> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-l= ine.pandoc >> index 50d7edb248..866fa2f951 100644 >> --- a/docs/misc/xen-command-line.pandoc >> +++ b/docs/misc/xen-command-line.pandoc >> @@ -2748,7 +2748,7 @@ performance. >> ### ucode >> > `=3D List of [ | scan=3D, nmi=3D, digest-check= =3D ]` >> =20 >> - Applicability: x86 >> + Applicability: x86 with CONFIG_MICROCODE_LOADING active >> Default: `scan` is selectable via Kconfig, `nmi,digest-check` > > You want to include this too: > > diff --git a/docs/admin-guide/microcode-loading.rst b/docs/admin-guide/mi= crocode-loading.rst > index a07e25802fab..91668e6f9b3f 100644 > --- a/docs/admin-guide/microcode-loading.rst > +++ b/docs/admin-guide/microcode-loading.rst > @@ -23,6 +23,9 @@ TSX errata which necessitated disabling the feature ent= irely), or the addition > =C2=A0of brand new features (e.g. the Spectre v2 controls to work around = speculative > =C2=A0execution vulnerabilities). > =C2=A0 > +Microcode loading support in Xen is controlled by the > +``CONFIG_MICROCODE_LOADING`` Kconfig option. Ack > + > =C2=A0 > =C2=A0Boot time microcode loading > =C2=A0--------------------------- > > > while changing the docs. > >> =20 >> Controls for CPU microcode loading. For early loading, this parameter c= an >> @@ -2773,7 +2773,7 @@ microcode in the cpio name space must be: >> - on AMD : kernel/x86/microcode/AuthenticAMD.bin >> When using xen.efi, the `ucode=3D` config file setting takes >> precedence over `scan`. The default value for `scan` is set with >> -`CONFIG_UCODE_SCAN_DEFAULT`. >> +`CONFIG_MICROCODE_SCAN_DEFAULT`. >> =20 >> 'nmi' determines late loading is performed in NMI handler or just in >> stop_machine context. In NMI handler, even NMIs are blocked, which is >> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig >> index c808c989fc..1353ec9a3f 100644 >> --- a/xen/arch/x86/Kconfig >> +++ b/xen/arch/x86/Kconfig >> @@ -331,8 +331,20 @@ config REQUIRE_NX >> was unavailable. However, if enabled, Xen will no longer boot on >> any CPU which is lacking NX support. >> =20 >> -config UCODE_SCAN_DEFAULT >> +config MICROCODE_LOADING >> + bool "Microcode loading" >> + default y >> + help >> + Support updating the microcode revision of available CPUs with a new= er >> + vendor-provided microcode blob. Microcode updates address some class= es of >> + silicon defects. It's a very common delivery mechanism for fixes or >> + workarounds for speculative execution vulnerabilities. >> + >> + If unsure, say Y. > > Please don't re-iterate the default.=C2=A0 It's a waste.=C2=A0 As to the = main > text, that's not great for the target audience of a distro packager / > power user.=C2=A0 How about: > > --8<-- > Microcode updates for CPUs fix errata and provide new functionality for > software to work around bugs, such as the speculative execution > vulnerabilities.=C2=A0 It is common for OSes to carry updated microcode a= s > software tends to get updated more frequently than firmware. > > For embedded environments where a full firmware/software stack is being > provided, it might not be necessary for Xen to need to load microcode > itself. > --8<-- Sure. I don't mind. > >> diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microc= ode/core.c >> index fe47c3a6c1..aec99834fd 100644 >> --- a/xen/arch/x86/cpu/microcode/core.c >> +++ b/xen/arch/x86/cpu/microcode/core.c >> @@ -44,6 +44,9 @@ >> =20 >> #include "private.h" >> =20 >> +#define can_apply_microcode(ops) (IS_ENABLED(CONFIG_MICROCODE_LOADING) = && \ >> + (ops).apply_microcode) > > I don't think this is a useful macro.=C2=A0 It's used 3 times, despite ..= . > >> @@ -613,6 +618,7 @@ static long cf_check ucode_update_hcall_cont(void *d= ata) >> return ret; >> } >> =20 >> +#ifdef CONFIG_MICROCODE_LOADING >> int ucode_update_hcall(XEN_GUEST_HANDLE(const_void) buf, >> unsigned long len, unsigned int flags) >> { >> @@ -622,7 +628,7 @@ int ucode_update_hcall(XEN_GUEST_HANDLE(const_void) = buf, >> if ( flags & ~XENPF_UCODE_FORCE ) >> return -EINVAL; >> =20 >> - if ( !ucode_ops.apply_microcode ) >> + if ( !can_apply_microcode(ucode_ops) ) >> return -EINVAL; >> =20 >> buffer =3D xmalloc_flex_struct(struct ucode_buf, buffer, len); >> @@ -645,6 +651,7 @@ int ucode_update_hcall(XEN_GUEST_HANDLE(const_void) = buf, >> */ >> return continue_hypercall_on_cpu(0, ucode_update_hcall_cont, buffer= ); >> } >> +#endif /* CONFIG_MICROCODE_LOADING */ > > ... this use being redundant.=C2=A0 Just expand it for the two other case= s > and consistently use IS_ENABLED() in view. Ack. > >> @@ -907,10 +916,12 @@ int __init early_microcode_init(struct boot_info *= bi) >> * >> * Take the hint in either case and ignore the microcode interface. >> */ >> - if ( !ucode_ops.apply_microcode || this_cpu(cpu_sig).rev =3D=3D ~0 = ) >> + if ( !can_apply_microcode(ucode_ops) || this_cpu(cpu_sig).rev =3D= =3D ~0 ) >> { >> printk(XENLOG_INFO "Microcode loading disabled due to: %s\n", >> - ucode_ops.apply_microcode ? "rev =3D ~0" : "HW toggle"); >> + !IS_ENABLED(CONFIG_MICROCODE_LOADING) ? "not compiled in= " : >> + ucode_ops.apply_microcode ? "rev =3D ~0" = : >> + "HW toggle"); >> ucode_ops.apply_microcode =3D NULL; >> return -ENODEV; >> } > > Don't complicate this messy printk() further.=C2=A0 Just exit early; it's= not > interesting to read "not loading microcode because it's not compiled in". > > This is a rare example of a subsystem where it remains partially > compiled in, and it's even possible to write such a printk(). Ack. > >> diff --git a/xen/arch/x86/cpu/microcode/intel.c b/xen/arch/x86/cpu/micro= code/intel.c >> index 281993e725..d9895018b4 100644 >> --- a/xen/arch/x86/cpu/microcode/intel.c >> +++ b/xen/arch/x86/cpu/microcode/intel.c >> @@ -404,21 +404,23 @@ static bool __init can_load_microcode(void) >> return !(mcu_ctrl & MCU_CONTROL_DIS_MCU_LOAD); >> } >> =20 >> -static const char __initconst intel_cpio_path[] =3D >> +static const char __initconst __maybe_unused intel_cpio_path[] =3D >> "kernel/x86/microcode/GenuineIntel.bin"; >> =20 >> static const struct microcode_ops __initconst_cf_clobber intel_ucode_op= s =3D { >> - .cpu_request_microcode =3D cpu_request_microcode, >> .collect_cpu_info =3D collect_cpu_info, >> +#ifdef CONFIG_MICROCODE_LOADING >> + .cpu_request_microcode =3D cpu_request_microcode, >> .apply_microcode =3D apply_microcode, >> .compare =3D intel_compare, >> .cpio_path =3D intel_cpio_path, >> +#endif /* CONFIG_MICROCODE_LOADING */ >> }; >> =20 >> void __init ucode_probe_intel(struct microcode_ops *ops) >> { >> *ops =3D intel_ucode_ops; >> =20 >> - if ( !can_load_microcode() ) >> + if ( IS_ENABLED(CONFIG_MICROCODE_LOADING) && !can_load_microcode() = ) >> ops->apply_microcode =3D NULL; >> } > > ! ||, surely? When !CONFIG_MICROCODE_LOADING apply_microcode is already NULL. It's a need= less assignment. This is strictly so the compiler can avoid assigning anything. Functionally it's irrelevant. > > >> diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_h= ypercall.c >> index 79bb99e0b6..5e83965d21 100644 >> --- a/xen/arch/x86/platform_hypercall.c >> +++ b/xen/arch/x86/platform_hypercall.c >> @@ -307,6 +307,7 @@ ret_t do_platform_op( >> break; >> } >> =20 >> +#ifdef CONFIG_MICROCODE_LOADING >> case XENPF_microcode_update: >> { >> XEN_GUEST_HANDLE(const_void) data; >> @@ -327,6 +328,7 @@ ret_t do_platform_op( >> op->u.microcode2.flags); >> break; >> } >> +#endif /* CONFIG_MICROCODE_LOADING */ > > You mustn't #ifdef out a case like this, because it causes the op to > fall into the default case, and some of the default chains go a long way > and make unwise assumptions, like hitting a BUG(). It's normally more convenient for us (AMD) to physically remove code where possible for coverage reasons, but in this case it probably doesn't matter. That said, I think we can both agree if dom0 can crash the hypervisor reque= sting a non existing op the bug is probably in such a BUG() statement and not elsewhere. Note CONFIG_VIDEO already removes an op in this way in this very file. The default case returns with ENOSYS, with BUG() being in helpers for other data, as far as I can see. > > Always use this form: > > =C2=A0=C2=A0=C2=A0 if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) ) > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 // EOPNOTSUPP > > and leave the case intact. ... but sure. > >> =20 >> case XENPF_platform_quirk: >> { >> diff --git a/xen/common/Makefile b/xen/common/Makefile >> index 92c97d641e..1e6c92e554 100644 >> --- a/xen/common/Makefile >> +++ b/xen/common/Makefile >> @@ -65,7 +65,8 @@ obj-y +=3D wait.o >> obj-bin-y +=3D warning.init.o >> obj-y +=3D xmalloc_tlsf.o >> =20 >> -obj-bin-$(CONFIG_X86) +=3D $(foreach n,decompress bunzip2 unxz unlzma l= zo unlzo unlz4 unzstd earlycpio,$(n).init.o) >> +obj-bin-$(CONFIG_MICROCODE_LOADING) +=3D earlycpio.init.o >> +obj-bin-$(CONFIG_X86) +=3D $(foreach n,decompress bunzip2 unxz unlzma l= zo unlzo unlz4 unzstd,$(n).init.o) >> =20 >> obj-$(CONFIG_COMPAT) +=3D $(addprefix compat/,domain.o memory.o multica= ll.o xlat.o) >> =20 > > In a prereq patch, please move earlycpio out of common/ into xen/lib/.=C2= =A0 > It shouldn't be tied to CONFIG_MICROCODE_LOADING like this, and it can > simply be discarded at link time when it's librified and unreferenced. > > ~Andrew That would preclude having it in the init section though, AIUI. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Mon Jan 12 19:13:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 19:13:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200882.1516683 (Exim 4.92) (envelope-from ) id 1vfNLt-0007iS-Mt; Mon, 12 Jan 2026 19:13:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200882.1516683; Mon, 12 Jan 2026 19:13:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfNLt-0007iL-JX; Mon, 12 Jan 2026 19:13:21 +0000 Received: by outflank-mailman (input) for mailman id 1200882; Mon, 12 Jan 2026 19:13: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 1vfNLr-0007i8-SN for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 19:13:19 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bc690cf9-efea-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 20:13:12 +0100 (CET) Received: from SA9PR13CA0176.namprd13.prod.outlook.com (2603:10b6:806:28::31) by DS4PR12MB9682.namprd12.prod.outlook.com (2603:10b6:8:27f::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Mon, 12 Jan 2026 19:13:04 +0000 Received: from SN1PEPF00036F43.namprd05.prod.outlook.com (2603:10b6:806:28:cafe::2f) by SA9PR13CA0176.outlook.office365.com (2603:10b6:806:28::31) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.3 via Frontend Transport; Mon, 12 Jan 2026 19:13:03 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SN1PEPF00036F43.mail.protection.outlook.com (10.167.248.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Mon, 12 Jan 2026 19:13:04 +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, 12 Jan 2026 13:13:01 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bc690cf9-efea-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DxMDUJ8W+x63N7c1uclnCBhUGrXKDfDs9v7hXAOLulznpO171F3fMbqRhRQ2XREoSXfRNWhsH8S8vCAcwLjvZvdKdE7zV7oJyWPmMv0JbCq6/yrGKxIvO4EBHrqOIJcLahbvnxVjSahwWYio3xLUdPS76pXwym1gP5xT9Mjhau8fAm7/9rjGsKM9TbYQ5U57AOz4bs8RS8ipZpAEbrmc67vyaTn8OtJt9r3iS4ly5u6juMd+2xdtlidgelIVFa9HpYGiAEMEcyywy7eVOdqd/9NaBxdrytV/+eEXClPo+IEXGZcamP7+kJhbhorlye5U6/E6pH1WkE/P9kS9xaEoLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Diup30xjS7Ne/xG0UQc2yl/qK6JjSrERes/xZyIbWQo=; b=MRtLngvBsG03jwXvhd39KSe5KvC7Atb7aObLtjEUns8kYAqzxyVXN04TH45nUeFdaDftlcwHMVm+VRmoQ7Vv8EH0iakZLON9rBfq9KGfxAa+fEpi6ibsaxI5RGciUA+8LDZgse/mAFwFekzPIKIWp7iP8v7Lbgk5annsVID12iaJiefEttRSLxvZv9RoHfdjupdIEPK+swgl65DOng07sK3WdxiODT7T1QNS2RvI3EDhcSYVuePK4MP3aOaMSx6UpxRBk4vyyeiMnnK28wespUZo0HLRBuokDiEsqeBAV0ZZud/Q3rAUoUByLdaetdE7h865MFIo/PPMp73PHeax/Q== 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=Diup30xjS7Ne/xG0UQc2yl/qK6JjSrERes/xZyIbWQo=; b=xgjImUwNWcd+StGNFOiw//GfGCubb6wLj/rZsYu40tY/k3/pvM/ihBhMmx/UTiJeHy7P7b1BILBIzOZc6e7Sv1NEspS7i+K9guWD/EPnY+aAtyG8xf7UUg6wyj4YhI1ohZ1Sfdc66LIlJMP8MLoSwyG1gZ8CE/hG79SHKu6RdrU= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 12 Jan 2026 20:12:59 +0100 Message-ID: CC: Doug Goldstein , Stefano Stabellini , Anthony PERARD , "Michal Orzel" , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" , =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?= , Xen-devel Subject: Re: [PATCH v2 2/2] x86/ucode: Add Kconfig option to remove microcode loading From: Alejandro Vallejo To: Alejandro Vallejo , Andrew Cooper , X-Mailer: aerc 0.20.1 References: <20260112150259.74535-1-alejandro.garciavallejo@amd.com> <20260112150259.74535-3-alejandro.garciavallejo@amd.com> <96f4f3fe-46c4-4854-af55-d5adea07c847@citrix.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: SN1PEPF00036F43:EE_|DS4PR12MB9682:EE_ X-MS-Office365-Filtering-Correlation-Id: 66c114c5-7d1f-40ab-f432-08de520e9c98 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|82310400026|7416014|376014|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?UEF3U2tmQm1GL2l3QzNhNVoySjdjY2F5Ry84RHVQYkJrQlFWQzV5N1pOWklV?= =?utf-8?B?TEE2MHYrTGlCbEdTdVAwWU4wbjBLcDROTnBPcnZPbEE5bW1mVEF3SkE5cDVa?= =?utf-8?B?QkYxUTVpRnR0VkJBbWg2c1RoU3hYZHdHNE16K3Q0SEczVDB4UlZZcWhwaGNr?= =?utf-8?B?dW5BRXhrcy82QjRRTkdJQWUxWEZTUmJNemY2YThMMEhseE83OGg5MGFZUG5Q?= =?utf-8?B?bzgzL1doVGpCc2lMaHEwWGJUOURTU085RVJGcG4rbjM1OUdzZFZzbWw2ZkJi?= =?utf-8?B?YzNjd1BMRElaRm5ZclVlRlIzM0FtenYza1V1eDRiVmo0K0I3by9Td0dkempk?= =?utf-8?B?OWhIVG1SNEdVYmtwV0hBd0RUUm5na2Q3eEUrZll5a3RrcG56NVBUbFBmMVdi?= =?utf-8?B?ZnFOUW5DVHBISWpSYjRlM0hPNFAxK3BLVVJKem5pbHhkOGFQam50REoxVjcv?= =?utf-8?B?bXdXSGxXeHNmK2NLV1JKVnhSb3hXTXNYMGlSYi94NW5vQjFGRC8weS9QZXBR?= =?utf-8?B?bW1BU21PVk84dHdKZVFtUng0VkxwUWIwaTRaT0RXdmNrTnlHODJWUXFYVkxY?= =?utf-8?B?cFIyRDdHQzN0eGVMM0hiWGtxUTZhZ3FnZTFJTGpONDhONkNhQ0JQaUp0bXRw?= =?utf-8?B?alJyNjdXandpUFdDU1JtZ0hhZ2hyU1dBdGtCV0FwT213RElGTDMzb0RNTW96?= =?utf-8?B?KzFEVG5tRktOZDNIb0U2M0ZkQklxM1NaWm90NjVvcnJKVXF5OHY5dzZLdDlx?= =?utf-8?B?ZDdHdzhrYjl6cGpYOEVBZ0dKemxralBQL2RvS0ZXRWkxOUpxMU5FQU0yeDhN?= =?utf-8?B?MFd3UUM3a2Z1REFMaHRvZlNPQkx5UVZMNWZLaWRnQml1VkpZdGJHL216WWZh?= =?utf-8?B?SkMzUnh4VXlWdWVESlBMR3U1ekxTb2tkTFk4UUV4Ym4xd2ZpM093SXBWNWtP?= =?utf-8?B?Qi8xQ2RsZ3JLTmJldjNqd1NNemlSNnFwaWlxaklEK0xmdGR1QWN2aklqYnlW?= =?utf-8?B?QVppb21JNkhuSmp3WldvS001d0RBc2xJQitkWUI5emhvUUNBemhDRTlsenQ3?= =?utf-8?B?QzM5bTRlTGJsREdyY0dJSjE1blV5QzBRazZEUW96UUtCTkNoU2NZaGc5Vitx?= =?utf-8?B?blIwYUgza1p2d3lmckR6WisxQUtUNnJQTFN4ZU1ZbmdPUE5EYVVEVmlWRWlJ?= =?utf-8?B?NmFyV1RzQkJ6bkdnbk9ZL0xTeFR2cW5sY3hrSFJxWGZxcFdOUVIyTVg3OWZL?= =?utf-8?B?WHBEU3ZDbi9VKzB0aDZ0UU9DSkhWb2F3Vzh0c0VzbldjcWtMbjNBZVVrTEdU?= =?utf-8?B?YmZGK0dXNU5tV0xpK0ZBbVlzLzl0OXExVHhuYW1Ob0w1ZFFrZXBZZmxGa3B3?= =?utf-8?B?UHVTR1lFdUxPQVpLUVVRbGU4UmRianVaM1hpWU4yL1VIKzJHcDA0NDZ6VnJS?= =?utf-8?B?eXZGZkxsWTZ5Q29ERkp0YzBlbVBYWVVSajd3R0tXYm9ucE1Xblgxc0Exbzg1?= =?utf-8?B?d0VIb2QwY2tjQldGaWZZQkR1SmNzcTgrUUJLQ0dnRzE0Y3IrMUwvRmZJdXlt?= =?utf-8?B?Ry9UeWdLZ3ZHS25XUnVkSm5RZGZLZWlPTGROS2FsdHU0MEVlWURJQllSNFpC?= =?utf-8?B?WmwwcWxYTGNmNEhOdEY4SDduSVhLWmlQdGQvWVhyRjRJbWIxQk92SE9HRjNJ?= =?utf-8?B?NGdTVGFVd01JNDA2QmJodWlHdUI1ZkRSWjc0WmpPL1V3ODVvSEdOeWVldHNu?= =?utf-8?B?bi9vQ2F5UDllM3JNTEhKTkhPVlA4QkJOckt0NjE3RE1XVGx0SUQxeGpNMFVB?= =?utf-8?B?dXREeCtWL0dVaWFtYlZEdUdwQnNEL01xQzN6aUlDVWJmMDJaTUpvNXorczZs?= =?utf-8?B?WitsL09mcGNwVENrQzVNSnljNVV5a3VvNlIvQzduT0hZUWFQcG1GL08zSnRi?= =?utf-8?B?bmxHWVJqUEJTMjM1ZjlDK3RSTWt1WUdvcnpNSGRsU2pQaUdFYUp5SGRabHVF?= =?utf-8?B?b3I0dW5qUFZaSndjd1lmeGJPLzhQNzc2ajJFTEt2NjFQMGhrRzdtakFZdjhY?= =?utf-8?B?MmppVU45V2pMVmZwbGRzWFplcUdQM05ZRHFsb0hZYk44TERIcWxPL2k5RTVX?= =?utf-8?Q?uMEg=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(7416014)(376014)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2026 19:13:04.2821 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 66c114c5-7d1f-40ab-f432-08de520e9c98 X-MS-Exchange-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: SN1PEPF00036F43.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR12MB9682 Hi, On Mon Jan 12, 2026 at 7:47 PM CET, Alejandro Vallejo wrote: > On Mon Jan 12, 2026 at 6:15 PM CET, Andrew Cooper wrote: >> On 12/01/2026 3:02 pm, Alejandro Vallejo wrote: >>> automation/gitlab-ci/build.yaml | 2 +- >>> docs/misc/efi.pandoc | 2 ++ >>> docs/misc/xen-command-line.pandoc | 4 ++-- >>> xen/arch/x86/Kconfig | 14 +++++++++++++- >>> xen/arch/x86/cpu/microcode/amd.c | 22 +++++++++++++--------- >>> xen/arch/x86/cpu/microcode/core.c | 25 ++++++++++++++++++------- >>> xen/arch/x86/cpu/microcode/intel.c | 16 +++++++++------- >>> xen/arch/x86/efi/efi-boot.h | 3 ++- >>> xen/arch/x86/platform_hypercall.c | 2 ++ >>> xen/common/Makefile | 3 ++- >>> 10 files changed, 64 insertions(+), 29 deletions(-) >> >> Much nicer in terms of (non) invasiveness. An interesting fact came to my attention. If you set a function pointer as IS_ENABLED(x) ? foo : NULL, rather than ifdeffing out the compiler doesn't = even need __maybe_unused to eliminate the statics. I'm adjusting as needed and creating something so that... custom_param_if("ucode", parse_ucode, IS_ENABLED(CONFIG_MICROCODE_LOADING= )); ... does the right thing. I'm sure it'll have uses outside this (minor) pat= ch to remove a number of cmdline handlers when the feature they control isn't act= ive. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Mon Jan 12 19:48:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 19:48:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200901.1516698 (Exim 4.92) (envelope-from ) id 1vfNtX-0003iC-B0; Mon, 12 Jan 2026 19:48:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200901.1516698; Mon, 12 Jan 2026 19:48:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfNtX-0003i5-7v; Mon, 12 Jan 2026 19:48:07 +0000 Received: by outflank-mailman (input) for mailman id 1200901; Mon, 12 Jan 2026 19:48: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 1vfNtW-0003hu-LX for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 19:48:06 +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 9b67c63e-efef-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 20:48:04 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MN2PR03MB5006.namprd03.prod.outlook.com (2603:10b6:208:1a4::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Mon, 12 Jan 2026 19:48:01 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.005; Mon, 12 Jan 2026 19:48: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: 9b67c63e-efef-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HDst3h3+Z/h9LsRy2Efz2d8g4v+5iKvziF91uw4ycCpMo2nf8eeGBSzil3Jf6JTvcHgYg1Ow+Kmw/6qB2s02XOLV4mgmUxJAZGbnVsSHFM5kdZhB2MATQ8E+Ag2aZrtClrwhT1LL/S+qVACQyQs8P5p4SlxHuTP+a3UMJhON6ZMCvxg9gB6yfdD3y6qsnmXloeBq/7O+ULB2BQ1McHukuCH/lZuFX4NZC4hmfbDPA3p47BcFANudTwf1dlyqUqSwgNbAmTZJVzW7K7Za/c3i5WSj1tlXa1PNNW8d21iBXatWxNKIxDF0rjgRlh7R26eZ+iXt+DlcFCRbQSDzTbjC1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aGFSLgufLfE9CX6u8fKiIHw+tYINxDcfnClVxMxGJFQ=; b=CrItimKwODd+aHnoiR5vSBJWKRzvbLnacMq/1jakaW0Ce6ZnXZcVb3pxhhVX6olf/qhzcp1tiQRt6PDPOEYDBFen8ir8a6GidX5D56l8U6Nm+1367lu8WcV1dTXWSbdL9TPcNNQE2Wcw9QZGbYe+ZROUoz5m0b9SGlb4H9GMpbY6aQMCw3tNzn9qBOIgm4vmU5iQMptyeO2rg5LRZQlkmG9Ds7/UbWOEHhF0l8DSiDiargtvJdaaKhcXd88Y6yojbnIbdLdJOmLtBYUEj+BXH9c98nchuptAAYCy4PMr7wSWnYm/mS4t3Dm0QmBGTZER8pWe9wJ6PMQ556nckBqUUQ== 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=aGFSLgufLfE9CX6u8fKiIHw+tYINxDcfnClVxMxGJFQ=; b=xZ82i1dzHy9+J7mrAeQdmvGCbNx0rye+RfVh9IL3HvN6W0HiTrr6B9WUfS0hjOn91H0bO4zqYx3iPXOE3is9712vjDLGSkgMnydZNxS3XLLE3XBELxC85T1KLXfuTjZpc+WXWPp4KxQOfafxk7shWDA7l9BkVj/dRhOg9MhL7lg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <5fb97540-0b29-40b9-ac9b-039a41e30add@citrix.com> Date: Mon, 12 Jan 2026 19:47:56 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Doug Goldstein , Stefano Stabellini , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Xen-devel Subject: Re: [PATCH v2 2/2] x86/ucode: Add Kconfig option to remove microcode loading To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260112150259.74535-1-alejandro.garciavallejo@amd.com> <20260112150259.74535-3-alejandro.garciavallejo@amd.com> <96f4f3fe-46c4-4854-af55-d5adea07c847@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0164.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9::32) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MN2PR03MB5006:EE_ X-MS-Office365-Filtering-Correlation-Id: 75a5f03c-79af-4ecb-2fc9-08de52137e1a 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?ZFpIeHo0TnVVZTRxeFFvL2RzSFNaWGtDMm9kbVR2UHRpbmNoVDZJR21FNUtK?= =?utf-8?B?Q0FZUlBwYzJRL2dTNG5KSHV0VThqSThHOE9LYUpaRjhHTVJsT0pQUk5Qdi96?= =?utf-8?B?ZXZ2ektOdEdOYnExYXl3WVo3b3VlcThPMFcyb3NRWUM4YVM4eUpLenVydmdo?= =?utf-8?B?aHc2MUhVRzdZd3k1eWNVbTFYbFplcEsvMHBhR1lJOHowaUNpK0w2U2Q4SHlW?= =?utf-8?B?Wmt6R1BPaER0TURMbDNaWWpKblRoSEJOZGo1V2hXVFAwODdNSzRxRXNrcURk?= =?utf-8?B?bTlveEFZQVhsYVN1ckRhZlBKZTRsY1B4Y04vR2VRMTVBQ0x3WGZQUWZBUStJ?= =?utf-8?B?eWxGRFp0UTIvL2lTRWxZMmdtQkhJczZpRW1zQ1h5eVM3ZTIzY3c0eWRjdFNn?= =?utf-8?B?eXEvL0Y3bXhBcmJNTkhLM0RDdEduVVI5TmZsVkJ0czB1UGh2ZXR2TzRmcHNq?= =?utf-8?B?QUVIY09EUDNDRVU5ZUxlbW1xZ2hzOHI4OXBhNHBYZzlzRUxxTjViUlRkL2tV?= =?utf-8?B?amcrc3RBYzZiWXBrUnpqNStmS2pxTS9uelNybWdrR2kyQ0xHMkpXNzZVTkpI?= =?utf-8?B?OWYwZWh3eldEc0hoYnBmSnkzd096WG5tOTN6eExtOEQwNEErVXJkYVBzTEJO?= =?utf-8?B?U0hvc1JEc21sd0FPTlJmQThYTXB1SjliekpUdGRrOU9DTmZneHkxbis5VjAy?= =?utf-8?B?Tld5QmJZNU1qaFExU1dhVDRZWjVkV1Q1UkVGblhDVUE1c1FCS1hlWlVYRVFI?= =?utf-8?B?akVsSDQzeVk2TFN5cjlwb3YwY1FhYXYxQWRTN0lWRVc4SFRTS0Qzb29MNGpq?= =?utf-8?B?NnJWOERTdzRMejlwanQyRUgweVZqLzBRWTFiODF5TTU1enUvWjNTVWxHbXJS?= =?utf-8?B?ZHdBYW9leVQyWUJwT3dQMVU0M0kwZjNITjdiYmE4RDlSdVgzWHpZZ3h1WmlM?= =?utf-8?B?ckpsQi84a3huVXYxSXV1eW55NmY1S0tudDVnL2tVTm93OUE4QW5FUVZQMWUz?= =?utf-8?B?eXpTMWVlenNmSzVlZzFKMk5hSklBUmhHcHJUUUZ6SHkzanh0dVFEUVd1QUVr?= =?utf-8?B?anhUV0djOW5DdHhUdUhpL2ZtSC9QcHFJakx2N2E2RHNOU0RzOXNnRU5yMHdo?= =?utf-8?B?OFA5a0tGUzVFdUZvNVBTc3BkYmp6cmNhMitNSng1T3lESXduZUxUTk1pSldG?= =?utf-8?B?NUJvVElQM2RCRUZvS2IyemNobzlRckdCM1lwUHlpb2g1TjdRZUpPYXh3RVdv?= =?utf-8?B?UnVPNWQ1RVByblV0SEVPeWFOSDdKZEd4WTdjazFkNWtpaDdxaTgzaFc0dVBV?= =?utf-8?B?UTVEQTdVVUFDZXc0eDRldW5uOUVQTkNhM3dZWEhHZWcrbXlyOWppaDQwc1JL?= =?utf-8?B?OFNlUTR2RElaUmdYOTRwSXI3OVVEVWcxVndTbkVKcGlMWkd2N3VzdHAveW9U?= =?utf-8?B?RC8raXMrY0ovMEFPUXlTaUNPeVR4cC83Vmd4N3U4QXV2NWFCMHZFVC9xNkUv?= =?utf-8?B?bjB5N3FsWDBLNXRnamhQVnlpc3pZZktxbnQ0SVZId084ZHRWZ2MyeHBkSGZC?= =?utf-8?B?bGlyaVhwR2tBQTJ5VzA0YlU2eHowTE55KzNoRlc4NUZjcXFlZUFucTZMUkZH?= =?utf-8?B?ZFArV25ORUdSQzFRWWcyellrRGZCa2tmSDJPbjdVcVhGbG8yYW9VN21QTkZU?= =?utf-8?B?ZnVQQzN5Z1kzM2gvODFqNVNPU3ZMRmhNN2liSTVzZzJzcVNlY1JQa3JVTG9G?= =?utf-8?B?anU4TzdWR0VlMjVLVTFjUklPMElET3NOYTRYT2xxMjdYcnB2V09Ic0Voa3R2?= =?utf-8?B?S1gxcHUwN2JabmFzZEZ0VjkzR3dXVkVyK3JyNitPKzR1UTJPOXpJSEF2a0sy?= =?utf-8?B?SXhLVml5aEthR3NPczQ1RVhGOHhWeWJ6MjdTU3ZzUXF2UktMeW1adjNrNXVT?= =?utf-8?Q?Ki2dNo75OUv/+yDEXFPmifI2bP0Zopqt?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?djU4NjQ5NWZSWVhxNkY0VHJFdG9VTlVaUkczNnRGRm5rZkd5SkVaeDdyS2p1?= =?utf-8?B?UCswUm9jVG5jS201UVZqY0J2Zyszcmw3R1lyVThQWWhMc0hiQnJYcjllN1FC?= =?utf-8?B?bnhJR2JrOVRKN0l5eEcyNjBPTFQvM3BxQUUwNWhRVHlkcWlGY2ViQmcvT3I3?= =?utf-8?B?Z08wOHJQbHRHQ3MrdG9BemxtMHFYN1lkWUJJVzQ1NENjc2Y1REw5eHFIRHBQ?= =?utf-8?B?Qk1KbVNIck1PWVozaEVsT3h4bjRiSEZsT2wxRnMvZlRyS2o5cW9BRW9mSkZt?= =?utf-8?B?bTJUWS9wdEV2Z3JaNHczZGJ2M0ZkcTFZSzB2a1dSSTF2bVBtZmQrK09NZkdW?= =?utf-8?B?LzJLbTc4Nks3anp1WTlMdldIeUxUa29ETHNRbDhZMmZVMGNUc3hXSkFYalpQ?= =?utf-8?B?WXB6bmpFMzI3VmdBcHFKT0RCeVZmdFlaUFNocmYxVldXL0gyMGVPcTFZTXAw?= =?utf-8?B?ZWExTUo0eHovN2cvbkkwODNlS09DeFFWaCtVS1Q4WVBLQVBFdjNVNmxvb1RT?= =?utf-8?B?Zk9WMGRGYmJ3cU9ENGlKbmh2MGFPeXU0UWlLNm54cWtGVWZIZTUzRS9lczkw?= =?utf-8?B?R21EVFFyZW1NTXlNZXVQcmkzci9FcHpzOWVDOCsramtwUFpESnM2L0hZVFNs?= =?utf-8?B?ZVU0Yks3bW9sNUpNeVl4WVM2NnhCV1FiNGwvcnpiU2NWVk8rNlF5bXRBVmhq?= =?utf-8?B?dUZ6MWl5aGpyandBVUhmNURud2h5TlE0U0F5SFNlZDdBRmhBS1dwUlFIVG43?= =?utf-8?B?TjRYMHdGWjdjTEdsSDRDN3I3Ungyd1Y5TVA1RDNiZWpsVzhvWjhxUmovaEdL?= =?utf-8?B?NjZyRXdSZ2xZd0prVVo2elp6SnRhRnMyUm9kcmRENjRCNnVKZDR3UnZZSzBu?= =?utf-8?B?STlWSUJwdkxKZ1ZFVGg1U09SVDB6dDQ5SG9uREIvQUkxOVJ6amhzcXBNQlZX?= =?utf-8?B?a09TS0Q1VHU4dm9kVUx6U1ptaG14TjdFL29wekNrcXAyZWlFL1M2WFd5ZlhP?= =?utf-8?B?cFA2SWRmQTJGR0ZlTGRadDQvbUF0dkFtVm1HTWtHK3JCYi92L1BXeWp1eTlr?= =?utf-8?B?UjhMRTBHZUoxNE9lRlRDRndxRVgzQStaUSsvUmk2YjgrOXQ5MkpjQW8wVnlq?= =?utf-8?B?UDlYNkIyTGg5c2NxY0V0R2pQa0QrT1NBMmczeUVGcER0ZzhGSjVTaUZuMi9K?= =?utf-8?B?eXFqMytWWEgwUUVjTHIyR2hnU25UK2ZxdjNIOGNOUVVLaXFWdHRuM3lNRmxD?= =?utf-8?B?c0lBaDFkTXFSRDI3d3BjVDkyQStVSG1hVkVsRlJ5NjlyRDFWZCt2OVFvVmFC?= =?utf-8?B?RmM3TUFvWTlTcngyYmhPYnJNZytXVlA4QXhvc21HT3IwRWJlWldUcjl0Tmo0?= =?utf-8?B?dmpISEc1U1RJQ0FLajZkOTJEZ01mR2pCTFlyUHZHRXZEVnVWMHhyZkl5Wi9p?= =?utf-8?B?L0QydU9mQ25TblBOR1F0dm5qYnRUcTBLNFJ4eW11UUV0NER2ZGlyNFNjZ0sw?= =?utf-8?B?amt0Vnl2N1p4bjRldzE3ZDQ4OHNUNmJGMzVYVlg2NFVzellKcUF1aWYyakZ4?= =?utf-8?B?Y3dCV3pJZjBZaFdzc05KVXNETHhOcytlQytsakNjMy9iVHhWclI2K2FpOVl2?= =?utf-8?B?Rkx3QjZtdjRqNGE2N2VCbzRpY3JaeHRjd25pVEFQdStaRWVYVjc2a05uVWdr?= =?utf-8?B?U1YrakJKaDhhS0dOd1Uvd0pGSytUTHFhczFNeXFWSm1UL2JtRERSQWZtNzhD?= =?utf-8?B?aVRZT1YveEJCUEZLMVhkbHlsQWpseFk4M0UvL2ZDSHpFQ2xPaEd6R2hRa0xq?= =?utf-8?B?TFhuWkJVVzNTOFFQWmFiN083RTBUa0JqZFhwUXMwQ1FLcjVGK3FYQ2QrODdt?= =?utf-8?B?UjYzNXowTDBaeURLQ2s4NXF3R1BMb3hJUEppMG5ZdDVDZVVPS2ppMzVnclVE?= =?utf-8?B?b3U0QytUelp4cDV2U2xSQzVtSmg0a2VvU1JsbUcxWU00RFBWS01YUzRQR0Iy?= =?utf-8?B?QVJFQStLRXV3QzIvZzFPYW8yZ1EzQTIrQlBHVzU4em91cUVIZzJqSEtueHhn?= =?utf-8?B?WHVnNXc1am5iWXFKNmM5d1dIOXAyRTdNVVB4QUxJQ25WWWpOOG9GeWEzOTNi?= =?utf-8?B?WGQ4ZEFLU2NOYlhmZ2lFVE1vRnkxTkUzWVoxdHlrY2JiTUFBeXBzd1d4dXZu?= =?utf-8?B?eHJzd214cm5NaWRjZ2NDNjdpT3RMUzFhZlZpa2h3bXhhRW5hTTR0QnhjR0NT?= =?utf-8?B?azVGeEMyRlNEbnlPU2IwdHA0UzBrYmZFSG9qSFVHa2VSWmg3SVcyaGJ5ZEJu?= =?utf-8?B?M0xtWG9EUDA4S0srYzVFSThSdC9aRFlaQ2c0RDB3cnFrY0VWdlc5QT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 75a5f03c-79af-4ecb-2fc9-08de52137e1a X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2026 19:48:00.7665 (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: 2VKPUbuMwMcVo8wr8TLDt5DRAc1wBLfu2xew+P0u6YUeF3R8bXpAcwsqusAjkwXfGtUkivJfdDC3hmcgRAa+EAaq/kRdBYAPcN0Gnao7Mh0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR03MB5006 On 12/01/2026 6:47 pm, Alejandro Vallejo wrote: > On Mon Jan 12, 2026 at 6:15 PM CET, Andrew Cooper wrote: >> On 12/01/2026 3:02 pm, Alejandro Vallejo wrote: >>> diff --git a/xen/arch/x86/cpu/microcode/intel.c b/xen/arch/x86/cpu/microcode/intel.c >>> index 281993e725..d9895018b4 100644 >>> --- a/xen/arch/x86/cpu/microcode/intel.c >>> +++ b/xen/arch/x86/cpu/microcode/intel.c >>> @@ -404,21 +404,23 @@ static bool __init can_load_microcode(void) >>> return !(mcu_ctrl & MCU_CONTROL_DIS_MCU_LOAD); >>> } >>> >>> -static const char __initconst intel_cpio_path[] = >>> +static const char __initconst __maybe_unused intel_cpio_path[] = >>> "kernel/x86/microcode/GenuineIntel.bin"; >>> >>> static const struct microcode_ops __initconst_cf_clobber intel_ucode_ops = { >>> - .cpu_request_microcode = cpu_request_microcode, >>> .collect_cpu_info = collect_cpu_info, >>> +#ifdef CONFIG_MICROCODE_LOADING >>> + .cpu_request_microcode = cpu_request_microcode, >>> .apply_microcode = apply_microcode, >>> .compare = intel_compare, >>> .cpio_path = intel_cpio_path, >>> +#endif /* CONFIG_MICROCODE_LOADING */ >>> }; >>> >>> void __init ucode_probe_intel(struct microcode_ops *ops) >>> { >>> *ops = intel_ucode_ops; >>> >>> - if ( !can_load_microcode() ) >>> + if ( IS_ENABLED(CONFIG_MICROCODE_LOADING) && !can_load_microcode() ) >>> ops->apply_microcode = NULL; >>> } >> ! ||, surely? > When !CONFIG_MICROCODE_LOADING apply_microcode is already NULL. It's a needless > assignment. This is strictly so the compiler can avoid assigning anything. > > Functionally it's irrelevant. Oh, that's subtle. As can_load_microcode() is a local static function anyway, it might be better to have an early return false in there. That will get the same DCE, but be easier to follow. > >> >>> diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c >>> index 79bb99e0b6..5e83965d21 100644 >>> --- a/xen/arch/x86/platform_hypercall.c >>> +++ b/xen/arch/x86/platform_hypercall.c >>> @@ -307,6 +307,7 @@ ret_t do_platform_op( >>> break; >>> } >>> >>> +#ifdef CONFIG_MICROCODE_LOADING >>> case XENPF_microcode_update: >>> { >>> XEN_GUEST_HANDLE(const_void) data; >>> @@ -327,6 +328,7 @@ ret_t do_platform_op( >>> op->u.microcode2.flags); >>> break; >>> } >>> +#endif /* CONFIG_MICROCODE_LOADING */ >> You mustn't #ifdef out a case like this, because it causes the op to >> fall into the default case, and some of the default chains go a long way >> and make unwise assumptions, like hitting a BUG(). > It's normally more convenient for us (AMD) to physically remove code where > possible for coverage reasons, but in this case it probably doesn't matter. > > That said, I think we can both agree if dom0 can crash the hypervisor requesting > a non existing op the bug is probably in such a BUG() statement and not > elsewhere. Note CONFIG_VIDEO already removes an op in this way in this very > file. The default case returns with ENOSYS, with BUG() being in helpers for > other data, as far as I can see. The existing bad practice are the ones I haven't had time to fix yet. As I recall, we did have a guest reachable BUG_ON() at one point caused by this pattern, hence the "never again" position. >>> >>> case XENPF_platform_quirk: >>> { >>> diff --git a/xen/common/Makefile b/xen/common/Makefile >>> index 92c97d641e..1e6c92e554 100644 >>> --- a/xen/common/Makefile >>> +++ b/xen/common/Makefile >>> @@ -65,7 +65,8 @@ obj-y += wait.o >>> obj-bin-y += warning.init.o >>> obj-y += xmalloc_tlsf.o >>> >>> -obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo unlz4 unzstd earlycpio,$(n).init.o) >>> +obj-bin-$(CONFIG_MICROCODE_LOADING) += earlycpio.init.o >>> +obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo unlz4 unzstd,$(n).init.o) >>> >>> obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o) >>> >> In a prereq patch, please move earlycpio out of common/ into xen/lib/.  >> It shouldn't be tied to CONFIG_MICROCODE_LOADING like this, and it can >> simply be discarded at link time when it's librified and unreferenced. >> >> ~Andrew > That would preclude having it in the init section though, AIUI. There's already lib stuff placed in init.  It works fine. (What does get complicated is conditionally-init, conditionally-not, but that's complicated irrespective of lib/) ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jan 12 19:51:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 19:51:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200911.1516708 (Exim 4.92) (envelope-from ) id 1vfNx7-0005EF-Rh; Mon, 12 Jan 2026 19:51:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200911.1516708; Mon, 12 Jan 2026 19: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 1vfNx7-0005E8-Ne; Mon, 12 Jan 2026 19:51:49 +0000 Received: by outflank-mailman (input) for mailman id 1200911; Mon, 12 Jan 2026 19: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 1vfNx6-0005Dx-IB for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 19:51:48 +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 1f197859-eff0-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 20:51:45 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MN2PR03MB5006.namprd03.prod.outlook.com (2603:10b6:208:1a4::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Mon, 12 Jan 2026 19:51:42 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.005; Mon, 12 Jan 2026 19:51: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: 1f197859-eff0-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=zAj6v9b/5I6iHbVo+TNiAr+GWsvpNWxCwAPuz0wcKxae/pab0sgpVTU0iHqIaGhftGjnBUQxC51O+yo6Xw8Trx71a0v2mOY7ZksedZhTYweUSSaOV3gIriUMZAPE6yHjfXvuJnqRwKfGUkR2Kkp2GZqR/4g8BB/Co+7XpX+tttP7+Uw6fdFncbmjGihId0mq1IkUeydhL9VcV+RhkyvHSryEGtrTywPhlfF3GWn+rnL5daOBf07OxA80kMhtJPdwS/UI3SRmOMHR8KNFgkhtbW8PbQ+4IJPX+HE+F0wZa7OZlcObuJohqp28tF73al1QsvmpaYv06W6vCEfsbz6ZXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vWFk+q3EFqAXyrK3dawiPlj98LVzN7Lf6nZXfrgFruU=; b=lcOYEVb9sOJgBYUe+6ct4LOyYzAEwNS83G2fLMK524M+sD1BVaKGfjNdmJBC8XBcGYu+jVGXS/w4VzuTRBMDPMZpzbWjO1tkCbjAoGW+72BMs7BYMqzhVnb5GJVOQEoglHdo6v4JdrZ1jzLrd0P6Z26Zsb4R/+O/enWyY7hM2NwzOVV2u/rsArfTgjAU/tFN7n84dJf/xDh7/h7SjKq+Is/f/ZDJBcLDClgIlyU+X9TZ80YPwCkAWOuv9XZdSZhXxopkumWZKRRi5q7TkRmObv06qWu4m5HDRn7FmYqwSnlBni+mpopg8wtFTjkQjscpXqlsFG3e74so2UU8GBay7g== 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=vWFk+q3EFqAXyrK3dawiPlj98LVzN7Lf6nZXfrgFruU=; b=lBaP0yQrybpcyfqoGEVlzWIz2gUFSUr7woPok4fzPRB4CFC/evbzu0EQHktDrdcZ/C9PPCgGSuJmr/BRbmJx4oAxG9PNttQbUj1Bj4HJAuEHuVwxWFUWTkzWrWEUX3WqqC2FSIOv8cSWa/rbIyLTxiEOX/xZSu4eLEXbFiiR2rQ= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <2c471e14-e2c8-4117-a7ef-9d8abe859fbe@citrix.com> Date: Mon, 12 Jan 2026 19:51:38 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Doug Goldstein , Stefano Stabellini , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Xen-devel Subject: Re: [PATCH v2 2/2] x86/ucode: Add Kconfig option to remove microcode loading To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260112150259.74535-1-alejandro.garciavallejo@amd.com> <20260112150259.74535-3-alejandro.garciavallejo@amd.com> <96f4f3fe-46c4-4854-af55-d5adea07c847@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0202.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:318::8) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MN2PR03MB5006:EE_ X-MS-Office365-Filtering-Correlation-Id: 2bf4d0a3-cbc7-4c62-8903-08de5214023b 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?WGo1UTB3cGtZQXltQkozYzByWWFSL0o4ODgweE9nZTRpUk5DMXRxWDZTU0pt?= =?utf-8?B?QU15cW5veERhYmVXY0ZmT3drdXgyak54bk03T2pKYytXcm4rall3UkpCeStn?= =?utf-8?B?RExYZmxibjQ0dkV1K1BPbWN0UkU5dmtRQ2I3NmlPdzI1OUwrc05MRCtoL2Zv?= =?utf-8?B?R3BkVmp3YmFBY2ZqQlg4SWswSDdRckM5SXpGNFYrSnhlekJSVFkvbklUN0pk?= =?utf-8?B?VkcvTnVZejdFdnRJM3hWZ1k4OHlYZlBwUVJ6RktpT29qZllJSXlVNFF3dlBo?= =?utf-8?B?MTBzdnliZkl0aVNtWDJyYkdDdHhWODBmYjRqNWtmV0t4V3VyVExHcW1SWWgv?= =?utf-8?B?S1JIVGpUT0IzbVdxSUcxOVBhU0JXR0FYVjZIbk03MWF5QXZKVytTQXhIc0Yy?= =?utf-8?B?RitNWklUT3J6WWR2MWdWUW80cVp6OTZNVUljMHZET0h3d1pISUsxa0cwa1N3?= =?utf-8?B?YUV2QzY2cGdyL1k1WkZZTkRWMTYxaFFSWklQODNmalYzZm9iaUFlTkFOMXhu?= =?utf-8?B?T2t0S1hmUEtNRS9yd0tPZkdKV3ZNRFdBcks1b0xyYTloaVNYM0t2WEFXV1gz?= =?utf-8?B?TXF3U2N4V0Q2dTFla2NyaFNMczBJSHQ5NzU5WTk5azF6UTUvQ3F1OFNBdXh5?= =?utf-8?B?WGZ3YW01NjFHQjlBR21CSG1ObTM3blZkWTJJSnNleW5lcVBSKzE5WU5tNWVj?= =?utf-8?B?amcvNW9rQjZLRDlEdE10azlLYS9rWmE0Q3NpajBBYVdUOWEyMGF4YWg2K3Rm?= =?utf-8?B?aDYrUUtOYnRQU24xZzM1YS9LOVpXT2dmLzg4am5NNDRSRXlxNDZ3bVBUNXlM?= =?utf-8?B?Q0NONld0ZGdEVzIza2c5dERGd3B6TmVpNk1NZUIvTFpJRW9EYmNPSmpCbldL?= =?utf-8?B?dzZJMENVWklyRTkrRmhEdFF3dk05YXBkekpXbS9pSVU0QzgvSTVvS3pnS0lZ?= =?utf-8?B?UlZDQWhyUDVUL0FuZk5vSDRJTHdsMmdBNXFPNDBFbTZRRm1zQ0FCTkxOS3VP?= =?utf-8?B?NmQxS1NEeTBmdHV4RHRpSkdVMy9GMFp0elhSV05keTQ3dzZwbW5QdkE4UGRF?= =?utf-8?B?RzJpNnY5dDNhSU1KYmI4akhSSGdXaTV6dGllRlZlMUhLVVZ4SnhnTlBUcUdH?= =?utf-8?B?U09RYzBtV2hPVmZvcXB4alRCT2lSSW55MGFqVWtwYlcrTXVnTGtyY0VhMEgy?= =?utf-8?B?RDkxa2w1OTA5SmVDSmhIMFNSSlgwN0s0SU5RVGI2cmVHblBjL25LL25jNGx1?= =?utf-8?B?c29XdUdzY0dhUnZyUHdzWTd5MUdkQ2hCOW5lL3cwRXQ1Qk9Fd2pURzJmT2Ja?= =?utf-8?B?K1pZVkkxaFR1NzB4ZG0rZ3F2WndkdUtjc200R1VKMW13b1lRdStpbWgvTmhT?= =?utf-8?B?UUNtOXQvOFNoTVZ3UUtqMEpkSTlmN2hpUCt5SGxYQWlzdWhTZ1JiSTJSZDlX?= =?utf-8?B?TUQvUHRmdVJNL3VzdDRBVHVWYUVQZDRwdElUb3lrdXFuN0xXRERWUDdEdWxI?= =?utf-8?B?VzY2Y2FMQjFyL1daR0pkWGpFbDQrRDhIWkxlT1Z5dFNYNmNoU1RqUVBaRlhL?= =?utf-8?B?S0NHdlYrMFMrU1kzY25hNHBzZHNhUWVJVDErOXBIakorK0pGNVgyV1hMajN4?= =?utf-8?B?RXVXY0hkVk8zdFZaL1RrTStsamdHWS8yekpYR1JQbVl1cWRMem9xandLcThj?= =?utf-8?B?cWNsaUpIK2JVWjc0SXNQLzVMVTl0NnJBRkxBS2V3UUNVbWo0SlVIMHpVa3BI?= =?utf-8?B?UURVaWdPQlZpTjVzTjJXdDZEVmVka0lQVE1iWmpIeXN1QmtxbUpwa1JsSGI3?= =?utf-8?B?aUNZRXpDQmFuaDhwQW1HczZCWVFodFcxUkdla2NGM3BuSUQyTFJ5ZTJpdUo1?= =?utf-8?B?MWNEaGRkUjNjd2FSQllReDZRVnpTSExzSVJPbjdYOUNvNXZvTEthazZzWS9x?= =?utf-8?Q?HBO5vR844aOT9xCoyI/SOZ+veRDNBsxA?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bE9ySFdML0hWdE9vNHhNZHphMFJ2Si9IM3FLTGlPc3p1UmFSQ3g0bFdWM1FU?= =?utf-8?B?Y0IreGJub3NiSWFTSjFiUXA2RXNYVzFkaXRJejg4T1BwTDVtWE1wcXc1S1Qx?= =?utf-8?B?NVlqN1RNaVNiUVRLQmtmZkZSSWpnUU1WNE9FRXI1RW0xSzRJS3NOTVJad2lH?= =?utf-8?B?dkFsYmhTOTUzc20vcFR0amZNMkwvSjNTOXRqNkt0SUozdmNoTGQzYlhMWlRN?= =?utf-8?B?dnR3emtPWERTU3NwMjFjb1FVNFMyZkRneTdhUHhveE5LRnZkTmFlbHNFMkJR?= =?utf-8?B?YWtKU0l3Q3E1T3lQTUxDTjNQeW5ITkVST2k4bU0rZTMxY1RpUjJ0RXBEMHZQ?= =?utf-8?B?ZWtGb3ZMWWRXVzBGNkNBM1ovRHc3K0wwTDdXaHh0c0JBN1ViQUxoRzk4SlJ0?= =?utf-8?B?QStJeWpDUU1SMWIvRlZTTTZJMmd3L0lTRWpKaEl4clJqSHo5bnoxdGQ3dmg2?= =?utf-8?B?MTBra2RlV3VEc2YveWNDSnlYYVF6RFNQc1JaK1hrQ29kbzFFUGo3VFZITWhH?= =?utf-8?B?QmRhcWFudHVvYjl5OUFYWkIxL2dYS3hCenU1eDlrYmorYlNtajFJN2g2MTFm?= =?utf-8?B?cW42VzZ1RERpNGMyNk5NelNCU2JFTm9Qb2tZdVZQcjlVdGtHNDZDTFVUcnph?= =?utf-8?B?UGwzUm1OWTJjYmZpS2QwTTlVbkpuZjFBNTJRZnQ1TUJ2dUwxZWM3Q2dzYmNK?= =?utf-8?B?bXRtR0RVOGdkelY0WUFHUndlV3AxY1FqajRWMWk3ZlhwaVByYy9nMzJRZStP?= =?utf-8?B?dTI2Z2Q1SlRzOVVZd0lqczA3eTJUeHcxMlpkVy9iNERhNEJBOFJQQnlTN29m?= =?utf-8?B?cVBRSW9sMVdVTWNUVVFzZHNCRzZPQW1xL1pDSzhsMUxyV0lhVFJjeFJXMFpV?= =?utf-8?B?LytjNEV3M2hFQkVOUG00RmFqUmZUNVJpamRQYU9pUzlybjdjeEl0blo0MStT?= =?utf-8?B?dEw2SXhubVpkZkhOdEIzWFlIcnlkZVJpQmUzbVF1NGlqOEdIU3JuSFR4VDBy?= =?utf-8?B?U2JCaFpJRG1xYzBDMmRuMElCTHhPR2lrM3lYVmhDVzg4QlZ2cDlQL3VsZE80?= =?utf-8?B?SWpaMXEvMGFpbjR0UHNhRHcrQ1lZT2VMMkJ6N3V0YzRSOUFwUTVoY2p1VzlE?= =?utf-8?B?YVdFRWpFaTVYYng4aTErQ1U5RHJUdW1leW8yZ05pT0lGL0FDanFyWUNNU0xI?= =?utf-8?B?STczYXNCZi9XbDRPS3FmaHZyTGt1aVpUT0huR01UM0NsbnhmUTFiZ0sxU2ls?= =?utf-8?B?Ly9lTjduaGNMbEwzSVR1OGNGOFNNUjg2U3grTTdJV2dUL1VBeDB6VkJuL2Ft?= =?utf-8?B?TVpJRC82TGx5VkxNT3VDRFljaVNLM2xTMVNRclA3RnRaekNiK2RjTGVrajVS?= =?utf-8?B?TDRWMWRKM1JsSFkycmlLOE0wN0dUT2ladExDbytnOUxXbEV3aDRBbzJEUlBk?= =?utf-8?B?eHcvSjNtU0d1ZkM3c0JLWFZHZk1JaXFFRTNDeENwTlVoSVRiK1djWEFkeldC?= =?utf-8?B?a3NnVVN6M2RwaGl1bE81NWhqOTd6VEdkdkhMQnFBY25qamNtV2JZdmp0MTNK?= =?utf-8?B?Z1FubUFncU8zUlJxdWlFNzc4R0xHTFB0aGIxdzRmWmxpaFNhUkRtRFBQYytQ?= =?utf-8?B?Q0pycVBrUUpxVWFKTE15SjZUOE5rOTdjZStHUlhpZVdLVXFTL2dRTkJJMWFh?= =?utf-8?B?UDNjbEFrK1lQa3MxeURQQmdlMUZJbW53c0gvWkpWNFNXQTFvejdMQStDVnp4?= =?utf-8?B?Q1JkV1padWJ6blEySTBPZzdSS1N1OFpoMjhzcENPelNkUWJyK0d6U0tES3RN?= =?utf-8?B?UlFCTXd6dFV6Wkpiazl1Vm83SmUzT0x3d0FWVmxjK0szdUt5K1AvQmFNTHRM?= =?utf-8?B?emVDWmp1aEw4NGRrZzg3cG14cDF1V3M4UWhJeGxXWnR0WmlKT1UxUlZYc3Ro?= =?utf-8?B?S3hwLys0RTdHZ1BUcGc2dHc4WmFTdHNTT2hSaVVRc3NmcmZsV21lcWtPOWlq?= =?utf-8?B?c1JHWGpVcFdMUlRtOHpGeGVKK0d6MWduZTFCMG83U3g1MHdCdmMycjhYUW80?= =?utf-8?B?RmlJYi80TDVNOEhyZXZiMDl1U0w1dlRrVTRDQVd4K1NTVUJKSWl6QVM0RExw?= =?utf-8?B?eEQ2TmVpVEFQQVVsNndMRmtScmJPUldjNW5rQmpXVnJ1OUJWQmRIWmdDdmdZ?= =?utf-8?B?UnB5emJyODArcEtxcVdFY2Yra1NiUXhWQzhGbGt6R2VxeDhUQy91RlFsbnQ2?= =?utf-8?B?cmpCTFcySlNkazkwdEFOL2RXcjNnQ29USFBoZFVFaVVIRFpBWDFVcGg0UWZi?= =?utf-8?B?T0RRaDBaUHl3bCsrVFVsZFRETnNkdXhIR21tUk9uN3VGNFdxUGVNSTdNTFhi?= =?utf-8?Q?bD1cjK15hvd0PLl4=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2bf4d0a3-cbc7-4c62-8903-08de5214023b X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2026 19:51:42.4962 (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: tJhzIXqv/TBl9Evuk1b3l2twbyHV4skuX8Wu7PLRUv28yUv9k611GgVZkOaFcWlSLFuPO6WbLT6p5qQcpzDzdPfBUD3ejmnfg7HAdrfSWds= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR03MB5006 On 12/01/2026 7:12 pm, Alejandro Vallejo wrote: > Hi, > > On Mon Jan 12, 2026 at 7:47 PM CET, Alejandro Vallejo wrote: >> On Mon Jan 12, 2026 at 6:15 PM CET, Andrew Cooper wrote: >>> On 12/01/2026 3:02 pm, Alejandro Vallejo wrote: >>>> automation/gitlab-ci/build.yaml | 2 +- >>>> docs/misc/efi.pandoc | 2 ++ >>>> docs/misc/xen-command-line.pandoc | 4 ++-- >>>> xen/arch/x86/Kconfig | 14 +++++++++++++- >>>> xen/arch/x86/cpu/microcode/amd.c | 22 +++++++++++++--------- >>>> xen/arch/x86/cpu/microcode/core.c | 25 ++++++++++++++++++------- >>>> xen/arch/x86/cpu/microcode/intel.c | 16 +++++++++------- >>>> xen/arch/x86/efi/efi-boot.h | 3 ++- >>>> xen/arch/x86/platform_hypercall.c | 2 ++ >>>> xen/common/Makefile | 3 ++- >>>> 10 files changed, 64 insertions(+), 29 deletions(-) >>> Much nicer in terms of (non) invasiveness. > An interesting fact came to my attention. If you set a function pointer as > IS_ENABLED(x) ? foo : NULL, rather than ifdeffing out the compiler doesn't even > need __maybe_unused to eliminate the statics. Oh, yes.  I'd forgotten that trick when I suggested __maybe_unused.  Sorry. > > I'm adjusting as needed and creating something so that... > > custom_param_if("ucode", parse_ucode, IS_ENABLED(CONFIG_MICROCODE_LOADING)); > > ... does the right thing. I'm sure it'll have uses outside this (minor) patch to > remove a number of cmdline handlers when the feature they control isn't active. This I'm rather less sure about.  The lockdown patches are also competing for a 3rd parameter in the param() APIs. Again, I think microcode is a weird (i.e. rare) subsystem where we're only compiling out part of it.  Personally I'd leave it as you had in this patch.  It was minimally invasive. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jan 12 21:08:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 21:08:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200940.1516717 (Exim 4.92) (envelope-from ) id 1vfP8h-0005bi-FM; Mon, 12 Jan 2026 21:07:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200940.1516717; Mon, 12 Jan 2026 21:07:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfP8h-0005bb-Ba; Mon, 12 Jan 2026 21:07:51 +0000 Received: by outflank-mailman (input) for mailman id 1200940; Mon, 12 Jan 2026 21:07: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 1vfP8g-0005bR-1Y for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 21:07:50 +0000 Received: from CH1PR05CU001.outbound.protection.outlook.com (mail-northcentralusazlp170100001.outbound.protection.outlook.com [2a01:111:f403:c105::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id be8d3e67-effa-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 22:07:47 +0100 (CET) Received: from BLAP220CA0022.NAMP220.PROD.OUTLOOK.COM (2603:10b6:208:32c::27) by CY8PR12MB7731.namprd12.prod.outlook.com (2603:10b6:930:86::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Mon, 12 Jan 2026 21:07:40 +0000 Received: from BL02EPF00021F6E.namprd02.prod.outlook.com (2603:10b6:208:32c:cafe::8b) by BLAP220CA0022.outlook.office365.com (2603:10b6:208:32c::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Mon, 12 Jan 2026 21:07:29 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BL02EPF00021F6E.mail.protection.outlook.com (10.167.249.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Mon, 12 Jan 2026 21:07: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; Mon, 12 Jan 2026 15:07:40 -0600 Received: from [172.19.137.210] (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, 12 Jan 2026 15:07:39 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: be8d3e67-effa-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=cHY244aeXZsb/k+l+EWeOBpGfEG0M3IYg3kpp2zN6sG400KhfWHzD8yDuQ03SNzy4xHN9xc7caU6f++ZJZkeLoaC+q3F+nsfZhGd8QJnSfTa1Lxr+s2FoMuLMwJc7xcW2c4OBvgh2/j5Iou0RsKl2vJOiiTJBR9KXxZZO7cgyGpDmLKEMxE+zuF6qESP0JhNw7/TGutR7Kp6TKWdkfx771wHtfFDpX8k06xvP6xsLpozICj9IP8D/hQ0Suco5XwmwLGSNRA54NQRDOWrcdEILvdP/hmucRnqu81rGFQLIGFEHALlq1cST/9zUAseL5bR/F8fF6pzh0o1OTg7s+jGGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=v1jsb76Nq0Wf6mBgjoKGQ1mv+0FByU8MvTVOwIFyp+0=; b=LCx2pRDBXNJzgMC5TvFZitbatX/m/aemzQd6xg4KXhkWN7pkJP1ltOYLKdytWxFfqz3DoOXCxkuazMEfkIrNTLsGuuf+lZeU1hSOdpBljT/kRM6EOSRASgn+nOoO5rk2KnGTzbg8+4Y0Qt3yJZgUfxno168u4ZlSuiLij/GJxl3g/Nt+ENr4GPcvstGAcG0jNngQ3C+XR+MaXBrddn7o8AnQ2OJ5A60nHbU/pcPDGakUiMSB0fEMlduNaA2gpUvCf06eJr41tBIRiormYrHZYLqQNUsE6jFzH1TAuC6DNnkM34eZMd5dSNyBh1FmwoYX3i7Zkwt70Bf8HJVBp5/7aQ== 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=v1jsb76Nq0Wf6mBgjoKGQ1mv+0FByU8MvTVOwIFyp+0=; b=uO42cvuZE2J+Z4hJM7mu3kid+8NI+O8WGn/QXWWflajQAUuzYIonmfTr6F/hZCeUtqNSkZVRm7MVQNUKc/dw/0m+mayF8laFamdZJD3nP483pSUxk3tAsqqE+ipkZlXPjtRGyTfEbmuJXYOU6TdFbquFNQQr3hNo4+VdS2TFFaE= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 12 Jan 2026 16:07:33 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/6] PCI: determine whether a device has extended config space 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: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@suse.com> <52eb1293-b5d4-4f7a-b53b-285e4dd274a5@suse.com> Content-Language: en-US From: Stewart Hildebrand In-Reply-To: <52eb1293-b5d4-4f7a-b53b-285e4dd274a5@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF00021F6E:EE_|CY8PR12MB7731:EE_ X-MS-Office365-Filtering-Correlation-Id: 533e71aa-4b9f-4b8b-50a6-08de521e9f3e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700013|376014|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?eVgzSUlWcGZ5VkpkMkpOOG5vbk4ydXZOOHZBVjRybkwwYzRsN2h0dnFlUk5i?= =?utf-8?B?NWRMTzErdXZKZDVvb1VnRXAvNTl0R2p6K2FkN2x2R2VmeXo1U0YwNUI5QmdP?= =?utf-8?B?VmVNRzh5aGM4Z3l4TWFKQ1B1S1Q1Y3VvNE4vRjdacXdTSXRQc04vT3JLZDFK?= =?utf-8?B?QjBrRHJWRFFQYmx5TlJzTTV4Rm5nWWo0eWdTWlZtQjRxeXI2QWU3UERobVl2?= =?utf-8?B?Q3U1R2pqeDdLSnRHOGpERW5PZTJmZWgyS0k2SU1RcTZ4YmhYdW9rQjBRUitL?= =?utf-8?B?d012eXFuK2svNVcyc3pjeU5zdjAzdHNPVFllYzczZzQyYjhMTzMwcHdBZEJR?= =?utf-8?B?OUVvL1dqUnAvWWtJNmg4RHk1V0lLTU1rVUxLNjlnSlltbkdzN1JkZFI5QkIv?= =?utf-8?B?Z3VIQ1d6SUFZdGRWb1dBcFYwM3poRmN0MU5lWVA4dTdxTzVHRjVMWi82UWhC?= =?utf-8?B?NG5NV0RocHhlNm95MUNtSEpaajJBUG1Nd3haZUE3NEY1WU9YU05YcmN1bHVC?= =?utf-8?B?dy9Jc0RlcEFMRXFkdFR0a0Y2U2ZUeHNRRDdpdk01ek1GWklUck9UOUs5am1V?= =?utf-8?B?SGRnVys5bit6YnFsSmRVakJ4WC96aGIvSnQrYUZpTHNqK0FZNUpsYVNmZHk3?= =?utf-8?B?RzIrZkhvVmJuVm9KNnNwZDBpQnlobWx4c0dpRXBoUGYwZEovdzBHSU5KdXFj?= =?utf-8?B?TXBtNk9HM0VaNnk3SDBsV0lsbGJudVBHQ0N6Y3MvU2wzS2x4MHdCL3JsYVZn?= =?utf-8?B?Yk5DN0tjNXJlR1l5dy9SQzc5M0c3MHRzUEVhT1RITWdTS21wdk5WckRaZGlS?= =?utf-8?B?WnlCQzRwa2VmblZqd3ZkeVFhYmNvMkdXL0R2aWJjdHkvNUd3TnRWQ3d5a09i?= =?utf-8?B?c0RtY0tFQlQ1SXlwcyt5bVJacEY2Vm9WQUxMNVhzRlgzUmI5V3hCOGNtajVv?= =?utf-8?B?dUt6RldnMmptbys3VklqTmQ4SVl4WW9XTjFyYWM5NW1STVJmRDEzRTdxa09s?= =?utf-8?B?M2F2UG54eXFCblNTcURYdXFPM0lWV1JMZVRhT3F3bnNlNDdiVlJBTmdUZy9o?= =?utf-8?B?NWxuT1JsTTdxeXZDdCtsamprMDhZTUluTXFiN1FJSitJS0N5c3pLUHVsUlQ1?= =?utf-8?B?dW9mODZKNUovQUVNZ1lmeDNaYTNTdERNT3EwOXpOcExFQnl1Y2lVbnp2STds?= =?utf-8?B?eWdFbE9HbkdvcE1vYmNnR1FpWHo1SzUvVGJtcmcwUnR4akF1Ym5DTFlRcmww?= =?utf-8?B?a1Z2VHJucHBRQ3A4VTZpMytDeEowdnJzVkRobnJiVld6S0JaVUZsWWxLeTdy?= =?utf-8?B?TUg5d0JnWWdhcUlTc0VQeHpobHBzTnhWUGpIN2xLZFdTK3NsL055OEEvbm53?= =?utf-8?B?SDhZcXo4S3R4aytYOG13MU1rNUZhUXBuejYreXlKUWhJVGpQRndmYWozaWg3?= =?utf-8?B?YjAvR2RvRTJETnRHM214Y09sV3FCQUNBR2hpUEtoVmtObjdTVEFPeUlzbWgw?= =?utf-8?B?VnpiQWpaSDVJTVphVlVXUjExV0pzOEJNbzhhTE1zV3dpZ29PZXZKU2RpQ0V1?= =?utf-8?B?U1QwQkVOVFBqdUd3UzVBTGpQZCthYklUOVBMUDdNS2lBaFkzVDZoS3FEbU1r?= =?utf-8?B?NlI1cTZkUmY0eWxQTW85bTZyLzZ4VjU0dVBJVWs4bEw2KzZDMkVMZFdoUUNM?= =?utf-8?B?Uko0UkhlNnVDODd6SzdscThUajA1NGFUWnBPSFh4dGJlZUwvR3pIQ0hVdnBv?= =?utf-8?B?RWFWTEhsbUExRkRmYmV5L25uSkJ1UmhhajdMVWkxNlVZc1pxQ0w1TmRsTitk?= =?utf-8?B?dm9EbVVVMDk1ZXUvNmlkNWljVERhM1BKZGFSMUhEYWVHcUxrVm1oZXRScm85?= =?utf-8?B?bTlSWkg0UXBtdjdiQ3NrQjhhek9WVFdyc2FNNXZKV3FOWUlqSnFEbElzLytR?= =?utf-8?B?NHRxcFVmVGtPay9sdXY3bkhOK1ZMU0NIbS9aZmJ2WnJyTWdqYWw0N1R5bldN?= =?utf-8?B?WkFpSFRuTmlQajF0NjVzOE42aXcxNng4ZGZjNitJc254YW0yb3lZRUJPRWdY?= =?utf-8?B?MytFUDlSZy9QT0tNYXllWXRYRC9rTFQyOUs2aWFlRUgrVkQwSEpsMUhMci9l?= =?utf-8?Q?Ve2w=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2026 21:07:40.6978 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 533e71aa-4b9f-4b8b-50a6-08de521e9f3e X-MS-Exchange-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: BL02EPF00021F6E.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7731 On 1/6/26 08:47, Jan Beulich wrote: > Legacy PCI devices don't have any extended config space. Reading any part > thereof may return all ones or other arbitrary data, e.g. in some cases > base config space contents repeatedly. > > Logic follows Linux 6.19-rc's pci_cfg_space_size(), albeit leveraging our > determination of device type; in particular some comments are taken > verbatim from there. > > Signed-off-by: Jan Beulich > --- > Note that alloc_pdev()'s switch doesn't handle DEV_TYPE_PCI2PCIe_BRIDGE at > all. Such bridges will therefore not have ->ext_cfg set (which is likely > wrong). I initially read "set" as in "set to true", but I think you mean that ext_cfg isn't assigned at all. Though perhaps it should actually be set to true, because ... > Shouldn't we handle them like DEV_TYPE_LEGACY_PCI_BRIDGE (or > DEV_TYPE_PCI?) anyway (just like VT-d's set_msi_source_id() does)? ... in pdev_type(), we will only reach DEV_TYPE_PCI2PCIe_BRIDGE if it has PCI_CAP_ID_EXP, which would indicate the device has extended config. So maybe it would be better to handle it similar to DEV_TYPE_PCIe2PCI_BRIDGE in alloc_pdev(). > Linux also has CONFIG_PCI_QUIRKS, allowing to compile out the slightly > risky code (as reads may in principle have side effects). Should we gain > such, too? I don't have a strong opinion here. > --- a/xen/drivers/passthrough/pci.c > +++ b/xen/drivers/passthrough/pci.c > @@ -310,6 +310,41 @@ static void apply_quirks(struct pci_dev > * from trying to size the BARs or add handlers to trap accesses. > */ > pdev->ignore_bars = true; > + > + if ( pdev->ext_cfg ) > + { > + unsigned int pos; > + > + /* > + * PCI Express to PCI/PCI-X Bridge Specification, rev 1.0, 4.1.4 says > + * that when forwarding a type1 configuration request the bridge must > + * check that the extended register address field is zero. The bridge > + * is not permitted to forward the transactions and must handle it as > + * an Unsupported Request. Some bridges do not follow this rule and > + * simply drop the extended register bits, resulting in the standard > + * config space being aliased, every 256 bytes across the entire > + * configuration space. Test for this condition by comparing the first > + * dword of each potential alias to the vendor/device ID. > + * Known offenders: > + * ASM1083/1085 PCIe-to-PCI Reversible Bridge (1b21:1080, rev 01 & 03) > + * AMD/ATI SBx00 PCI to PCI Bridge (1002:4384, rev 40) > + */ > + for ( pos = PCI_CFG_SPACE_SIZE; > + pos < PCI_CFG_SPACE_EXP_SIZE; pos += PCI_CFG_SPACE_SIZE ) > + { > + if ( pci_conf_read16(pdev->sbdf, pos) != vendor || > + pci_conf_read16(pdev->sbdf, pos + 2) != device ) > + break; > + } > + > + if ( pos >= PCI_CFG_SPACE_EXP_SIZE ) > + { > + printk(XENLOG_WARNING > + "%pp: extended config space aliases base one\n", > + &pdev->sbdf); > + pdev->ext_cfg = false; > + } > + } > } > > static struct pci_dev *alloc_pdev(struct pci_seg *pseg, u8 bus, u8 devfn) > @@ -351,6 +386,8 @@ static struct pci_dev *alloc_pdev(struct > unsigned long flags; > > case DEV_TYPE_PCIe2PCI_BRIDGE: > + pdev->ext_cfg = true; > + fallthrough; > case DEV_TYPE_LEGACY_PCI_BRIDGE: > sec_bus = pci_conf_read8(pdev->sbdf, PCI_SECONDARY_BUS); > sub_bus = pci_conf_read8(pdev->sbdf, PCI_SUBORDINATE_BUS); > @@ -363,9 +400,19 @@ static struct pci_dev *alloc_pdev(struct > pseg->bus2bridge[sec_bus].devfn = devfn; > } > spin_unlock_irqrestore(&pseg->bus2bridge_lock, flags); > + > + fallthrough; > + case DEV_TYPE_PCI: > + pos = pci_find_cap_offset(pdev->sbdf, PCI_CAP_ID_PCIX); > + if ( pos && > + (pci_conf_read32(pdev->sbdf, pos + PCI_X_STATUS) & > + (PCI_X_STATUS_266MHZ | PCI_X_STATUS_533MHZ)) ) > + pdev->ext_cfg = true; > break; > > case DEV_TYPE_PCIe_ENDPOINT: > + pdev->ext_cfg = true; > + > pos = pci_find_cap_offset(pdev->sbdf, PCI_CAP_ID_EXP); > BUG_ON(!pos); > cap = pci_conf_read16(pdev->sbdf, pos + PCI_EXP_DEVCAP); > @@ -409,9 +456,9 @@ static struct pci_dev *alloc_pdev(struct > } > break; > > - case DEV_TYPE_PCI: > case DEV_TYPE_PCIe_BRIDGE: > case DEV_TYPE_PCI_HOST_BRIDGE: > + pdev->ext_cfg = true; > break; > > default: > @@ -420,6 +467,19 @@ static struct pci_dev *alloc_pdev(struct > break; > } > > + if ( pdev->ext_cfg && > + /* > + * Regular PCI devices have 256 bytes, but PCI-X 2 and PCI Express > + * devices have 4096 bytes. Even if the device is capable, that > + * doesn't mean we can access it. Maybe we don't have a way to > + * generate extended config space accesses, or the device is behind a > + * reverse Express bridge. So we try reading the dword at > + * PCI_CFG_SPACE_SIZE which must either be 0 or a valid extended > + * capability header. > + */ > + pci_conf_read32(pdev->sbdf, PCI_CFG_SPACE_SIZE) == 0xffffffffU ) > + pdev->ext_cfg = false; I'm using a machine where xen/arch/x86/x86_64/mmconfig-shared.c:is_mmconf_reserved() will initially return false during Xen boot: (XEN) PCI: MCFG configuration 0: base f0000000 segment 0000 buses 00 - 3f (XEN) PCI: Not using MCFG for segment 0000 bus 00-3f Then, during dom0 boot, dom0 will call PHYSDEVOP_pci_mmcfg_reserved, after which MCFG becomes enabled in Xen: (XEN) PCI: Using MCFG for segment 0000 bus 00-3f On such machines where mmcfg/ECAM is initially disabled, this will effectively set ->ext_cfg to false for all devices discovered at Xen boot. I'm not really sure if I have any good suggestions, but perhaps we could add a macro or small function that returns something like ( pdev->ext_cfg && pci_conf_read32(pdev->sbdf, PCI_CFG_SPACE_SIZE) != 0xffffffffU ) to allow this checking to happen dynamically (but this still wouldn't handle the aliasing quirk). Maybe re-run the ext_cfg detection logic at the end of PHYSDEVOP_pci_mmcfg_reserved? Regardless, I'd be happy to provide my R-b without this addressed, but I am curious if others think this as an issue? > + > apply_quirks(pdev); > check_pdev(pdev); > > @@ -717,6 +777,11 @@ int pci_add_device(u16 seg, u8 bus, u8 d > > list_add(&pdev->vf_list, &pf_pdev->vf_list); > } > + > + if ( !pdev->ext_cfg ) > + printk(XENLOG_WARNING > + "%pp: VF without extended config space?\n", > + &pdev->sbdf); > } > } > > --- a/xen/include/xen/pci.h > +++ b/xen/include/xen/pci.h > @@ -126,6 +126,9 @@ struct pci_dev { > > nodeid_t node; /* NUMA node */ > > + /* Whether the device has extended config space. */ Nit: it would be nice to clearly state if this means the extended config is accessible, or whether the device merely has it (but might not be accessible). > + bool ext_cfg; > + > /* Device to be quarantined, don't automatically re-assign to dom0 */ > bool quarantine; > > From xen-devel-bounces@lists.xenproject.org Mon Jan 12 21:19:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 21:19:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200951.1516728 (Exim 4.92) (envelope-from ) id 1vfPJm-0007FR-DR; Mon, 12 Jan 2026 21:19:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200951.1516728; Mon, 12 Jan 2026 21:19:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfPJm-0007FK-Af; Mon, 12 Jan 2026 21:19:18 +0000 Received: by outflank-mailman (input) for mailman id 1200951; Mon, 12 Jan 2026 21:19:16 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfPJk-0007FE-RI for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 21:19: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 57482c6a-effc-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 22:19:13 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id BAAB46000A; Mon, 12 Jan 2026 21:19:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8AF97C116D0; Mon, 12 Jan 2026 21:19: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: 57482c6a-effc-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768252751; bh=8YIm2mjYvImlnR/TA3qCvrzUgrrwDkBwcChNR/m79wE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=WnM5VaC7NJI8LGV6MW0olTcx8NqsH7iwZqud7q6uwf82LFnN57mCPspC8NifAWvh8 nawuQVF9Ii5FE61W98pNTxHTp9RuvVPdeRcp51fU5lILpXcuAj8tk5wZi50sGdFtM/ LI3DUC6BB7N5c1L5YatopDc2fgggnfxv+sRMkkZcZZY1lpbnx4odkISeYHwY7QurUK ZaUjQoX3EKmsSzQ/PdQTnv6r6rAGpEaPIfVAFLRIiVkOTsjHLvDWxMituIrDB//KmC rWHplp1YFRZAfkff9Qg5l+0t5NmbbBn0yAbMWTo62tuoevSjUIJgWi9qcOaeqPG/G/ uJ09kT3K2JNgg== Date: Mon, 12 Jan 2026 13:19:08 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Andrew Cooper cc: Michal Orzel , xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Subject: Re: [PATCH] xen/arm: Print correct domid in allocate_memory_11 In-Reply-To: <2b0b3c25-c504-4e5f-b995-cde41093f560@citrix.com> Message-ID: References: <20260112104233.86482-1-michal.orzel@amd.com> <2b0b3c25-c504-4e5f-b995-cde41093f560@citrix.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Mon, 12 Jan 2026, Andrew Cooper wrote: > On 12/01/2026 10:42 am, Michal Orzel wrote: > > allocate_memory_11() can be called for dom0 and direct-mapped hwdom > > domU. In the latter scenario, a log message would still mention dom0 > > instead of the correct domid. > > > > Fixes: 52cb53f1816a ("xen/arm: dom0less hwdom construction") > > Signed-off-by: Michal Orzel > > Acked-by: Andrew Cooper Acked-by: Stefano Stabellini From xen-devel-bounces@lists.xenproject.org Mon Jan 12 21:25:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 12 Jan 2026 21:25:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1200961.1516738 (Exim 4.92) (envelope-from ) id 1vfPPN-0000OL-Vz; Mon, 12 Jan 2026 21:25:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1200961.1516738; Mon, 12 Jan 2026 21:25:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfPPN-0000OE-T7; Mon, 12 Jan 2026 21:25:05 +0000 Received: by outflank-mailman (input) for mailman id 1200961; Mon, 12 Jan 2026 21: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 1vfPPN-0000O8-JY for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 21:25: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 2814db26-effd-11f0-b15e-2bf370ae4941; Mon, 12 Jan 2026 22:25:03 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id F3EA543C9D; Mon, 12 Jan 2026 21:25:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A3527C116D0; Mon, 12 Jan 2026 21:25: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: 2814db26-effd-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768253101; bh=9TJ2zq5kVoWmdfkYndTPjlMxuq+AXg1uQo5D5++arps=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=NrQXjvbQr8q3cKvjwuvZvhQfaKOX/Uotvz1v7VbOtwNxYvpoE1L07X7Olw4NtrILK KAeNaXOT/OvQcOoOmdI7BqO84DtX7Dyxy2oWxkGTTGhpxxKnFBfofir9dTmUBRAwe9 9O9JSfqe7ZwSQasWV/FrSXsr6zF1TuDncpj8zx/I4AE0VOe48uMZj30YqNBLgpAIGs MaALMVEx4k3OyTlagUg5w+gRe5p8mok6Sh+I92hTV146m42MxwQQnnzDigRgZix7xK Eq4y6uJxrmj0bZZWBcJhmGYQaPoaLcyP4yQvC/OUtj2vyqI15AyDVWxunHvau8aW/l TQB7XLICD9wog== Date: Mon, 12 Jan 2026 13:24:58 -0800 (PST) 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 , Nicola Vetrini Subject: Re: [PATCH] CI/randconfig: Disable CONFIG_CONDITION_COVERAGE In-Reply-To: <20260112163827.1023401-1-andrew.cooper3@citrix.com> Message-ID: References: <20260112163827.1023401-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-1006624351-1768253101=:992863" 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-1006624351-1768253101=:992863 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Mon, 12 Jan 2026, Andrew Cooper wrote: > In addition to GCC not liking x86_emulate(), it turns out that Clang is still > rather more a work in progress than a usable feature, causing failures in the > FreeBSD builds: > > https://cirrus-ci.com/task/5934059060199424 > > Exclude CONFIG_CONDITION_COVERAGE from Ranconfig until it gets a bit more > stable. > > Signed-off-by: Andrew Cooper Acked-by: Stefano Stabellini > --- > CC: Anthony PERARD > CC: Michal Orzel > CC: Jan Beulich > CC: Julien Grall > CC: Roger Pau Monné > CC: Stefano Stabellini > CC: Nicola Vetrini > --- > xen/tools/kconfig/allrandom.config | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/tools/kconfig/allrandom.config b/xen/tools/kconfig/allrandom.config > index f04b589a80af..8127ebb57090 100644 > --- a/xen/tools/kconfig/allrandom.config > +++ b/xen/tools/kconfig/allrandom.config > @@ -1,2 +1,2 @@ > # Explicit option choices not subject to regular RANDCONFIG > - > +CONFIG_CONDITION_COVERAGE=n > > base-commit: a2a34d76643e49ccc949296c9a45888034e50b55 > -- > 2.39.5 > --8323329-1006624351-1768253101=:992863-- From xen-devel-bounces@lists.xenproject.org Tue Jan 13 00:25:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 00:25:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201019.1516764 (Exim 4.92) (envelope-from ) id 1vfSDR-0006E5-LN; Tue, 13 Jan 2026 00:24:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201019.1516764; Tue, 13 Jan 2026 00:24:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfSDR-0006Dy-Ih; Tue, 13 Jan 2026 00:24:57 +0000 Received: by outflank-mailman (input) for mailman id 1201019; Tue, 13 Jan 2026 00:24:56 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfSDQ-0006Ds-Af for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 00:24:56 +0000 Received: from sea.source.kernel.org (sea.source.kernel.org [2600:3c0a:e001:78e:0:1991:8:25]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 47ae45b8-f016-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 01:24:54 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 76ADC436C1; Tue, 13 Jan 2026 00:24:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1FC5C116D0; Tue, 13 Jan 2026 00:24: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: 47ae45b8-f016-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768263892; bh=LBbnNiXXF6SclRkMeM12iA6wEoNZB+xJTpKWfGbDusw=; h=Date:From:To:cc:Subject:From; b=WOPvHi6mujQxXx1EFQ7JefvrxhVbJfGcRcCvMAkNh9LMV8jAlBObiJZA7X1UeDDi0 CGPp1kRgCCsBzLwOFaY7b91HZnHxcd9DhWnMNdw8sWG0WtQv7f+olx/vkv5FQfiO1p 60FPA5nOqvxvWLGm1SjeNe1CXTECyON44faA7ggjNL7EOYv8Q6REC/7Vhez3mYGYfp ZKIp1aLcc07O1syieVMFbJMs0hyqt6792Fpt19MEEDa2+ojS3slbsP6YQm+EhSLmBo F+YOkN8YFH6EUKCi9DLgI4bwBTDGroHjqch3lwCikgM9J6Exm3jeCet7lYr7+KxH+t 8E3qhPrspMb6g== Date: Mon, 12 Jan 2026 16:24:50 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: jgross@suse.com cc: sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, xen-devel@lists.xenproject.org Subject: [PATCH v2] xen: introduce xen_console_io option Message-ID: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Xen can support console_io hypercalls for any domains, not just dom0, depending on DEBUG and XSM policies. These hypercalls can be very useful for development and debugging. Introduce a kernel command line option xen_console_io to enable the usage of console_io hypercalls for any domain upon request. When xen_console_io is not specified, the current behavior is retained. Signed-off-by: Stefano Stabellini --- Changes in v2: - use kstrtobool --- .../admin-guide/kernel-parameters.txt | 5 ++++ drivers/tty/hvc/hvc_xen.c | 27 ++++++++++++++++--- 2 files changed, 28 insertions(+), 4 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index a8d0afde7f85a..68ab6fa72b685 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -8414,6 +8414,11 @@ Kernel parameters save/restore/migration must be enabled to handle larger domains. + xen_console_io [XEN,EARLY] + Boolean option to enable/disable the usage of the Xen + console_io hypercalls to read and write to the console. + Mostly useful for debugging and development. + xen_emul_unplug= [HW,X86,XEN,EARLY] Unplug Xen emulated devices Format: [unplug0,][unplug1] diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c index 388a71afd6efe..c94cc7df78d36 100644 --- a/drivers/tty/hvc/hvc_xen.c +++ b/drivers/tty/hvc/hvc_xen.c @@ -51,6 +51,22 @@ static DEFINE_SPINLOCK(xencons_lock); /* ------------------------------------------------------------------ */ +static bool xen_console_io = false; +static int __initdata opt_console_io = -1; + +static int __init parse_xen_console_io(char *arg) +{ + bool val; + int ret; + + ret = kstrtobool(arg, &val); + if (ret == 0) + opt_console_io = (int)val; + + return ret; +} +early_param("xen_console_io", parse_xen_console_io); + static struct xencons_info *vtermno_to_xencons(int vtermno) { struct xencons_info *entry, *ret = NULL; @@ -331,7 +347,7 @@ static int xen_initial_domain_console_init(void) struct xencons_info *info; unsigned long flags; - if (!xen_initial_domain()) + if (!xen_console_io) return -ENODEV; info = vtermno_to_xencons(HVC_COOKIE); @@ -369,7 +385,7 @@ void xen_console_resume(void) { struct xencons_info *info = vtermno_to_xencons(HVC_COOKIE); if (info != NULL && info->irq) { - if (!xen_initial_domain()) + if (!xen_console_io) xen_console_update_evtchn(info); rebind_evtchn_irq(info->evtchn, info->irq); } @@ -601,7 +617,7 @@ static int __init xen_hvc_init(void) if (!xen_domain()) return -ENODEV; - if (xen_initial_domain()) { + if (xen_console_io) { ops = &dom0_hvc_ops; r = xen_initial_domain_console_init(); if (r < 0) @@ -651,10 +667,13 @@ static int xen_cons_init(void) { const struct hv_ops *ops; + xen_console_io = opt_console_io >= 0 ? opt_console_io : + xen_initial_domain(); + if (!xen_domain()) return 0; - if (xen_initial_domain()) + if (xen_console_io) ops = &dom0_hvc_ops; else { int r; -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 01:30:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 01:30:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201034.1516774 (Exim 4.92) (envelope-from ) id 1vfTEe-0005Yg-8S; Tue, 13 Jan 2026 01:30:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201034.1516774; Tue, 13 Jan 2026 01:30: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 1vfTEe-0005YY-3X; Tue, 13 Jan 2026 01:30:16 +0000 Received: by outflank-mailman (input) for mailman id 1201034; Tue, 13 Jan 2026 01:30: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 1vfTEd-0005YS-1o for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 01:30: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 670faf60-f01f-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 02:30:12 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 85AB142A6F; Tue, 13 Jan 2026 01:30:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EBCB1C116D0; Tue, 13 Jan 2026 01:30: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: 670faf60-f01f-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768267810; bh=SiWZQYRKLJAqHCntm3wrDbeXCBsTGpiRR4DYrso5ExU=; h=Date:From:To:cc:Subject:From; b=higinGka6b6qYNL72znTsEsJ2nzghu61V1rjnLRcIAjwsJZA1MnIeb0Fcm/6ANPAi 0kvssPUIAgJAvcHhw5ngwasB+oJH7Gbb7P7/8ZYNrJZGR90cSUVfjB+LMnPw8FSV7c QklHC0WRStR8gYP3/wRqbpRsVr+yRloLrxkTc6n5dxEWyuHAFIOI+pAgNxhvFUwSvS RTNdH+xK0f1KQw0SYUsqdquxJJxL4A9j7vwtgXzeJOAAAN35y9SQiEyKkgSGyPoD4o IAl42rQl5ZD2JqgquKxYT1L8zMkibztFXG7rZ8fLupfu0dm8WZXhCJjTsUD+zlqiLb mmkWyazYTBsDQ== Date: Mon, 12 Jan 2026 17:30:06 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: xen-devel@lists.xenproject.org cc: sstabellini@kernel.org, jbeulich@suse.com, grygorii_strashko@epam.com, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Victor Lira , andrew.cooper3@citrix.com Subject: [PATCH v2] xen/console: handle multiple domains using console_io hypercalls Message-ID: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Allow multiple dom0less domains to use the console_io hypercalls to print to the console. Handle them in a similar way to vpl011: only the domain which has focus can read from the console. All domains can write to the console but the ones without focus have a prefix. In this case the prefix is applied by using guest_printk instead of printk or console_puts which is what the original code was already doing. Signed-off-by: Stefano Stabellini --- Changes in v2: - fix code style - pbuf_idx/idx after ada53067083e - don't add extra \0 - clear input on console switch --- xen/drivers/char/console.c | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 2bdb4d5fb4..6c7a6592c5 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -576,6 +576,8 @@ static void console_switch_input(void) rcu_unlock_domain(d); console_rx = next_rx; + /* don't let the next dom read the previous dom's unread data */ + serial_rx_cons = serial_rx_prod; printk("*** Serial input to DOM%u", domid); break; } @@ -730,6 +732,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, unsigned int flags = opt_console_to_ring ? CONSOLE_ALL : CONSOLE_DEFAULT; struct domain *cd = current->domain; + struct domain *input; while ( count > 0 ) { @@ -742,18 +745,28 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, if ( copy_from_guest(kbuf, buffer, kcount) ) return -EFAULT; - if ( is_hardware_domain(cd) ) + input = console_get_domain(); + if ( input && cd == input ) { + struct domain_console *cons = cd->console; + + if ( cons->idx ) + { + console_send(cons->buf, cons->idx, flags); + cons->idx = 0; + } /* Use direct console output as it could be interactive */ nrspin_lock_irq(&console_lock); console_send(kbuf, kcount, flags); nrspin_unlock_irq(&console_lock); + console_put_domain(input); } else { char *kin = kbuf, *kout = kbuf, c; struct domain_console *cons = cd->console; + console_put_domain(input); /* Strip non-printable characters */ do { @@ -795,6 +808,7 @@ long do_console_io( { long rc; unsigned int idx, len; + struct domain *d; rc = xsm_console_io(XSM_OTHER, current->domain, cmd); if ( rc ) @@ -815,6 +829,13 @@ long do_console_io( if ( count > INT_MAX ) break; + d = console_get_domain(); + if ( d != current->domain ) + { + console_put_domain(d); + return 0; + } + rc = 0; while ( (serial_rx_cons != serial_rx_prod) && (rc < count) ) { @@ -826,12 +847,14 @@ long do_console_io( len = count - rc; if ( copy_to_guest_offset(buffer, rc, &serial_rx_ring[idx], len) ) { + console_put_domain(d); rc = -EFAULT; break; } rc += len; serial_rx_cons += len; } + console_put_domain(d); break; default: rc = -ENOSYS; -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 06:10:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 06:10:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201012.1516784 (Exim 4.92) (envelope-from ) id 1vfXbz-0004rX-NH; Tue, 13 Jan 2026 06:10:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201012.1516784; Tue, 13 Jan 2026 06:10:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfXbz-0004rO-IQ; Tue, 13 Jan 2026 06:10:39 +0000 Received: by outflank-mailman (input) for mailman id 1201012; Mon, 12 Jan 2026 22: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 1vfQeQ-0002eS-LS for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 22:44:42 +0000 Received: from srv1.deutnet.info (srv1.deutnet.info [2a01:4f8:c2c:6846::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4579850c-f008-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 23:44:37 +0100 (CET) Received: from agriveaux by srv1.deutnet.info with local (Exim 4.98.2) (envelope-from ) id 1vfQeJ-00000003wpx-1VY7; Mon, 12 Jan 2026 23:44:35 +0100 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4579850c-f008-11f0-9ccf-f158ae23cfc8 Date: Mon, 12 Jan 2026 23:44:35 +0100 From: Alexandre GRIVEAUX To: xen-devel@lists.xenproject.org Cc: Anthony PERARD , agriveaux@deutnet.info Subject: [PATCH XEN] tools: Update files examples PV&PVH with pygrub. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Update files exemples PV&PVH for non direct kernel boot with pygrub. Signed-off-by: Alexandre GRIVEAUX --- tools/examples/xlexample.pvhlinux | 3 +++ tools/examples/xlexample.pvlinux | 3 +++ 2 files changed, 6 insertions(+) diff --git a/tools/examples/xlexample.pvhlinux b/tools/examples/xlexample.pvhlinux index 18305b80af..2bdd43c2c5 100644 --- a/tools/examples/xlexample.pvhlinux +++ b/tools/examples/xlexample.pvhlinux @@ -25,6 +25,9 @@ kernel = "/boot/vmlinuz" # Kernel command line options extra = "root=/dev/xvda1" +# Enable to use a grub2 emulation inside guest instead of direct kernel boot. +#bootloader="pygrub" + # Initial memory allocation (MB) memory = 512 diff --git a/tools/examples/xlexample.pvlinux b/tools/examples/xlexample.pvlinux index bb5996b29f..1a6b91fb47 100644 --- a/tools/examples/xlexample.pvlinux +++ b/tools/examples/xlexample.pvlinux @@ -22,6 +22,9 @@ kernel = "/boot/vmlinuz" # Kernel command line options extra = "root=/dev/xvda1" +# Enable to use a grub2 emulation inside guest instead of direct kernel boot. +#bootloader="pygrub" + # Initial memory allocation (MB) memory = 128 -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 06:10:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 06:10:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201014.1516787 (Exim 4.92) (envelope-from ) id 1vfXbz-0004t5-Sr; Tue, 13 Jan 2026 06:10:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201014.1516787; Tue, 13 Jan 2026 06:10:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfXbz-0004rx-PB; Tue, 13 Jan 2026 06:10:39 +0000 Received: by outflank-mailman (input) for mailman id 1201014; Mon, 12 Jan 2026 22:45: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 1vfQf0-0002f2-3N for xen-devel@lists.xenproject.org; Mon, 12 Jan 2026 22:45:18 +0000 Received: from srv1.deutnet.info (srv1.deutnet.info [2a01:4f8:c2c:6846::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5d0feeac-f008-11f0-9ccf-f158ae23cfc8; Mon, 12 Jan 2026 23:45:16 +0100 (CET) Received: from agriveaux by srv1.deutnet.info with local (Exim 4.98.2) (envelope-from ) id 1vfQex-00000003wqR-0nRg; Mon, 12 Jan 2026 23:45:15 +0100 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5d0feeac-f008-11f0-9ccf-f158ae23cfc8 Date: Mon, 12 Jan 2026 23:45:15 +0100 From: Alexandre GRIVEAUX To: xen-devel@lists.xenproject.org Cc: Anthony PERARD , agriveaux@deutnet.info Subject: [PATCH XEN] tools: Update HVM example whith AHCI, stdvga, tablet and UEFI. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Update HVM example file whith options: - AHCI - stdvga - tablet - UEFI Signed-off-by: Alexandre GRIVEAUX --- tools/examples/xlexample.hvm | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/tools/examples/xlexample.hvm b/tools/examples/xlexample.hvm index df9fe07653..8b615edb5c 100644 --- a/tools/examples/xlexample.hvm +++ b/tools/examples/xlexample.hvm @@ -41,7 +41,20 @@ vif = [ '' ] # A list of `diskspec' entries as described in # docs/misc/xl-disk-configuration.txt disk = [ '/dev/vg/guest-volume,raw,xvda,rw' ] +# Enable to use an AHCI emulated disk instead of IDE +# (AHCI via emulated ich9 disk controller) +#hdtype=ahci + +# Enable standard vga card for resolution better than 1280x1024 at 32bpp. +#vga="stdvga" # Guest VGA console configuration, either SDL or VNC sdl = 1 #vnc = 1 + +# Enable to use a pointer device using absolute coordinates +# (VNC work better in this mode). +#usbdevice=['tablet'] + +# Enable UEFI via ovmf firmware. +#firmware="ovmf" -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 06:16:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 06:16:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201091.1516804 (Exim 4.92) (envelope-from ) id 1vfXhA-0005wq-Hv; Tue, 13 Jan 2026 06:16:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201091.1516804; Tue, 13 Jan 2026 06: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 1vfXhA-0005wj-Ew; Tue, 13 Jan 2026 06:16:00 +0000 Received: by outflank-mailman (input) for mailman id 1201091; Tue, 13 Jan 2026 06: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 1vfXh9-0005wd-De for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 06:15:59 +0000 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5325619d-f047-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 07:15:57 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 1E29A33684; Tue, 13 Jan 2026 06:15: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 E5F163EA63; Tue, 13 Jan 2026 06:15:56 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id LkrVNRzjZWlBdwAAD6G6ig (envelope-from ); Tue, 13 Jan 2026 06:15: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: 5325619d-f047-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1768284957; 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=N6qVQ0nHGp6RjwB0XhblBT+n+oLc32TNfGJ/O1aT/+4=; b=sZLELZAdFnEP0iCVCGYkWqdSdoIPw55iVUkfm9OzK3Ie1Mj6mc7zQkjY/FKVFySIdhZKzt tiPDQhMmI8/bcaruuGJDzKq8Mrx5Vm1PVVqp6ccC//K8yr1j2sF72ngfddoaQ/qtwKTwDy 14VAFzUf1zn8PvIetli6NH7zNDQlyO4= Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=sZLELZAd DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1768284957; 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=N6qVQ0nHGp6RjwB0XhblBT+n+oLc32TNfGJ/O1aT/+4=; b=sZLELZAdFnEP0iCVCGYkWqdSdoIPw55iVUkfm9OzK3Ie1Mj6mc7zQkjY/FKVFySIdhZKzt tiPDQhMmI8/bcaruuGJDzKq8Mrx5Vm1PVVqp6ccC//K8yr1j2sF72ngfddoaQ/qtwKTwDy 14VAFzUf1zn8PvIetli6NH7zNDQlyO4= Message-ID: Date: Tue, 13 Jan 2026 07:15:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH XEN] tools: Update files examples PV&PVH with pygrub. To: Alexandre GRIVEAUX , xen-devel@lists.xenproject.org Cc: Anthony PERARD 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="------------kYiv9R3obFW7jOCHDLXlGRYW" X-Spam-Score: -5.41 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)[]; DKIM_TRACE(0.00)[suse.com:+]; HAS_ATTACHMENT(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)[]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo] X-Spam-Level: X-Rspamd-Action: no action X-Rspamd-Queue-Id: 1E29A33684 X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Spam-Flag: NO This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------kYiv9R3obFW7jOCHDLXlGRYW Content-Type: multipart/mixed; boundary="------------LqNx42wCo2MDvnFwHThz6K4k"; protected-headers="v1" From: Juergen Gross To: Alexandre GRIVEAUX , xen-devel@lists.xenproject.org Cc: Anthony PERARD Message-ID: Subject: Re: [PATCH XEN] tools: Update files examples PV&PVH with pygrub. References: In-Reply-To: --------------LqNx42wCo2MDvnFwHThz6K4k Content-Type: multipart/mixed; boundary="------------t08IAxPJlJtiSotmLvcyX2cQ" --------------t08IAxPJlJtiSotmLvcyX2cQ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTIuMDEuMjYgMjM6NDQsIEFsZXhhbmRyZSBHUklWRUFVWCB3cm90ZToNCj4gVXBkYXRl IGZpbGVzIGV4ZW1wbGVzIFBWJlBWSCBmb3Igbm9uIGRpcmVjdCBrZXJuZWwgYm9vdCB3aXRo IHB5Z3J1Yi4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IEFsZXhhbmRyZSBHUklWRUFVWCA8YWdy aXZlYXV4QGRldXRuZXQuaW5mbz4NCj4gLS0tDQo+ICAgdG9vbHMvZXhhbXBsZXMveGxleGFt cGxlLnB2aGxpbnV4IHwgMyArKysNCj4gICB0b29scy9leGFtcGxlcy94bGV4YW1wbGUucHZs aW51eCAgfCAzICsrKw0KPiAgIDIgZmlsZXMgY2hhbmdlZCwgNiBpbnNlcnRpb25zKCspDQo+ IA0KPiBkaWZmIC0tZ2l0IGEvdG9vbHMvZXhhbXBsZXMveGxleGFtcGxlLnB2aGxpbnV4IGIv dG9vbHMvZXhhbXBsZXMveGxleGFtcGxlLnB2aGxpbnV4DQo+IGluZGV4IDE4MzA1YjgwYWYu LjJiZGQ0M2MyYzUgMTAwNjQ0DQo+IC0tLSBhL3Rvb2xzL2V4YW1wbGVzL3hsZXhhbXBsZS5w dmhsaW51eA0KPiArKysgYi90b29scy9leGFtcGxlcy94bGV4YW1wbGUucHZobGludXgNCj4g QEAgLTI1LDYgKzI1LDkgQEAga2VybmVsID0gIi9ib290L3ZtbGludXoiDQo+ICAgIyBLZXJu ZWwgY29tbWFuZCBsaW5lIG9wdGlvbnMNCj4gICBleHRyYSA9ICJyb290PS9kZXYveHZkYTEi DQo+ICAgDQo+ICsjIEVuYWJsZSB0byB1c2UgYSBncnViMiBlbXVsYXRpb24gaW5zaWRlIGd1 ZXN0IGluc3RlYWQgb2YgZGlyZWN0IGtlcm5lbCBib290Lg0KDQpJIGRvbid0IHRoaW5rIHRo aXMgaXMgY29ycmVjdC4NCg0KcHlncnViIGlzIHJ1bm5pbmcgaW4gZG9tMCwgbm90IGluIHRo ZSBndWVzdC4NCg0KDQpKdWVyZ2VuDQo= --------------t08IAxPJlJtiSotmLvcyX2cQ 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----- --------------t08IAxPJlJtiSotmLvcyX2cQ-- --------------LqNx42wCo2MDvnFwHThz6K4k-- --------------kYiv9R3obFW7jOCHDLXlGRYW 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/Ey8FAmll4xwFAwAAAAAACgkQsN6d1ii/Ey/w KQf/Q/hCeZSIJdr98d2ctIOnu9wM29d6NSrETCKl++YuTObYlqbw+PqKzvp1Kc0bupf+4Rzb7hPD YsamLeErds6/NXcBl+FXlWElegH66SXnOsuvRTPzeR35ou8JRQN/5pWZM1vbP4jf8pc14pnivq3M Y+feMPFq4OwI4431DUV2fkLu0uBBqyZ8vFqPW6imoA4LqjmCUGPxrivFYWdhLhgskMsSOS3BORGJ cVQBGHE872nVtjwuRw7BBIsvDQ0XQNu+wQL3k72FcMuqpj3q5R9Q128ijCUxl9NtiOcyw8m/H9af xRT2pmzTwFMdzYmASPVfDvZTGORYp/4pSQGpuJ1nxQ== =5cMA -----END PGP SIGNATURE----- --------------kYiv9R3obFW7jOCHDLXlGRYW-- From xen-devel-bounces@lists.xenproject.org Tue Jan 13 06:55:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 06:55:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201122.1516814 (Exim 4.92) (envelope-from ) id 1vfYJa-0002e6-Cp; Tue, 13 Jan 2026 06:55:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201122.1516814; Tue, 13 Jan 2026 06:55: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 1vfYJa-0002dz-9v; Tue, 13 Jan 2026 06:55:42 +0000 Received: by outflank-mailman (input) for mailman id 1201122; Tue, 13 Jan 2026 06:55:41 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfYJY-0002dt-UH for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 06:55: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 dd3d163c-f04c-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 07:55:37 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id E7C6360017; Tue, 13 Jan 2026 06:55:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 536E5C116C6; Tue, 13 Jan 2026 06:55: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: dd3d163c-f04c-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768287335; bh=n2q+fJWEyo0mV6AKyU2NgixjB8rQdCeFy7wPDNt7Ixw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mwX9VvXcjdrskeQKOvbcv2HC+NL/RDz4FppQ9fnPtBQA1h/lZM5QudZv4iKoKJl1C VQCaQU+hiUKx7q8EgGpIzV1Hn20fsOFwG6zqcIn/vl3U4GG2DoZuoBCdSCc9MIrVi6 2MHpiBSZFVQlABThX/kX+VNSm9NEDG583BF3gZqeCl8YnVq3DfJ/UB2vR++2E2jQ+/ fLslrBi9sfsC0XXL368jTALZsIRyCVk19M0zkW8jJecDCMGw6Svd8eEi3+2ow4H/MN ppPLXp3SH5miS5Kp+TM4ntM0fIhbOm6ktZD6rGbuzWn5lDVqcsC7+tqrUBLCvxlmzQ QPuSOGbMm9j6Q== Date: Tue, 13 Jan 2026 06:55:34 +0000 From: Wei Liu To: Juergen Gross Cc: linux-kernel@vger.kernel.org, x86@kernel.org, linux-hyperv@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 , Long Li , Peter Zijlstra , Will Deacon , Boqun Feng , Waiman Long , Jiri Kosina , Josh Poimboeuf , Pawan Gupta , Boris Ostrovsky , xen-devel@lists.xenproject.org Subject: Re: [PATCH v5 01/21] x86/paravirt: Remove not needed includes of paravirt.h Message-ID: <20260113065534.GB3099059@liuwe-devbox-debian-v2.local> References: <20260105110520.21356-1-jgross@suse.com> <20260105110520.21356-2-jgross@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260105110520.21356-2-jgross@suse.com> On Mon, Jan 05, 2026 at 12:05:00PM +0100, Juergen Gross wrote: > 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) > --- > V3: > - reinstate the include in mmu_context.h (kernel test robot) > V4: > - reinstate the include in arch/x86/kernel/x86_init.c (Boris Petkov) > --- > arch/x86/entry/entry_64.S | 1 - > arch/x86/entry/vsyscall/vsyscall_64.c | 1 - > arch/x86/hyperv/hv_spinlock.c | 1 - Acked-by: Wei Liu (Microsoft) From xen-devel-bounces@lists.xenproject.org Tue Jan 13 06:56:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 06:56:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201130.1516823 (Exim 4.92) (envelope-from ) id 1vfYKS-00037M-Lg; Tue, 13 Jan 2026 06:56:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201130.1516823; Tue, 13 Jan 2026 06:56:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfYKS-00037F-Ip; Tue, 13 Jan 2026 06:56:36 +0000 Received: by outflank-mailman (input) for mailman id 1201130; Tue, 13 Jan 2026 06:56: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 1vfYKR-00035y-DK for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 06:56:35 +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 ff06fbff-f04c-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 07:56:34 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 4A6026000A; Tue, 13 Jan 2026 06:56:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A0A50C116C6; Tue, 13 Jan 2026 06:56: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: ff06fbff-f04c-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768287393; bh=B5TuD3XfjPDj4HUep1TvfY2MvFwdAw7YS2657wMNiSg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lGNrts5Oca/aw3q0q5G9mJdI79ntZnSFN2BEgu1O0ms5lYmLwwJ1YPIF6EEPklpgr +QQ4skyvnbzmXZBmahvdwsqPKH3rNyzL5ZXy/cZIkrjxX/X+KO9w1Guwm1Of66iU72 O97Ftehsqk1saj9YHIGjyC9rUQ41F78egDvfrJsbtPoJM26zsxHw98M7bGffFWX/CA PVTrJ3e0syJtu51Wd+9bLX0sh+2qqE0Rtrx0EHeNcwFL4xaTEvxP+RfG2fMIatb1st IJ8L1u4eL2DtzrQhSUwXWuhgnaDmoNxrvgE7+PaHJvxYfcV/LVsWTLMo138SZvJ6lM sq8Tg4Nhe5Trw== Date: Tue, 13 Jan 2026 06:56:31 +0000 From: Wei Liu To: Juergen Gross Cc: linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux.dev, kvm@vger.kernel.org, linux-hyperv@vger.kernel.org, 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 , Long Li , Daniel Lezcano , xen-devel@lists.xenproject.org, "Peter Zijlstra (Intel)" Subject: Re: [PATCH v5 12/21] x86/paravirt: Move paravirt_sched_clock() related code into tsc.c Message-ID: <20260113065631.GC3099059@liuwe-devbox-debian-v2.local> References: <20260105110520.21356-1-jgross@suse.com> <20260105110520.21356-13-jgross@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260105110520.21356-13-jgross@suse.com> On Mon, Jan 05, 2026 at 12:05:11PM +0100, Juergen Gross wrote: > 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 ++ Acked-by: Wei Liu (Microsoft) From xen-devel-bounces@lists.xenproject.org Tue Jan 13 06:57:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 06:57:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201142.1516834 (Exim 4.92) (envelope-from ) id 1vfYLE-0003nm-2L; Tue, 13 Jan 2026 06:57:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201142.1516834; Tue, 13 Jan 2026 06:57: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 1vfYLD-0003nf-Vg; Tue, 13 Jan 2026 06:57:23 +0000 Received: by outflank-mailman (input) for mailman id 1201142; Tue, 13 Jan 2026 06:57: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 1vfYLC-00035y-9k for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 06:57:22 +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 1b07e99d-f04d-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 07:57:21 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 46CF46001D; Tue, 13 Jan 2026 06:57:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5D12C116C6; Tue, 13 Jan 2026 06:57: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: 1b07e99d-f04d-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768287440; bh=60SPyWB8vDd2rUgvHslTdiPd0EofSPJHlT4QUyPma6A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=R1NApMXhnqwRdTk2bbAImX9NrjtIDbtzQx9IWe8no+TStcOX4nHWBNhBtEh+GTKfh 5D2bVETHk3k4qJ3TfhxNbgsDzI/0L7N9K5AjJ5ICcWGg61rv3Y+R7jL66oh0Suq20c 8ibdQVDTHWMXjBYyAHqG+dWbXUn3ynN5ePye7vIIG+VWbvicoe4q/j99LOhZgBjKP2 urczlgGE8vb5kkt9cvhYHL4DJkbBf/GmURlHuhpD78NJaytElj/4UwAT5yTfTkSnZY EQclNoU14InQbSaOyIdaYIGps5fgK3GMHmyi1TJsMHNXkh66lxmk3y2lLgljPPwTfN Lb2RJ8DPFS6dg== Date: Tue, 13 Jan 2026 06:57:18 +0000 From: Wei Liu To: Juergen Gross Cc: linux-kernel@vger.kernel.org, x86@kernel.org, linux-hyperv@vger.kernel.org, virtualization@lists.linux.dev, kvm@vger.kernel.org, "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , 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 v5 21/21] x86/pvlocks: Move paravirt spinlock functions into own header Message-ID: <20260113065718.GD3099059@liuwe-devbox-debian-v2.local> References: <20260105110520.21356-1-jgross@suse.com> <20260105110520.21356-22-jgross@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260105110520.21356-22-jgross@suse.com> On Mon, Jan 05, 2026 at 12:05:20PM +0100, Juergen Gross wrote: > 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 > V3: > - hide native_pv_lock_init() with CONFIG_SMP (kernel test robot) > V4: > - don't reference pv_ops_lock without CONFIG_PARAVIRT_SPINLOCKS > (kernel test robot) > V5: > - move paravirt_set_cap() declaration into paravirt-base.h > (kernel test robot) > --- > arch/x86/hyperv/hv_spinlock.c | 10 +- Acked-by: Wei Liu (Microsoft) Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 07:01:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201157.1516844 (Exim 4.92) (envelope-from ) id 1vfYPQ-0005R6-J6; Tue, 13 Jan 2026 07:01:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201157.1516844; Tue, 13 Jan 2026 07: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 1vfYPQ-0005Qz-FI; Tue, 13 Jan 2026 07:01:44 +0000 Received: by outflank-mailman (input) for mailman id 1201157; Tue, 13 Jan 2026 07:01: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 1vfYPP-0005Qo-J0 for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 07:01:43 +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 b29fae62-f04d-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 08:01:34 +0100 (CET) Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-59b67388c9cso9175677e87.2 for ; Mon, 12 Jan 2026 23:01:34 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b29fae62-f04d-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768287694; x=1768892494; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=6aB1YMGQen4QeppxKa0CPKNwdwfaYo/Ol0NlViX1KGM=; b=dlGBdA5GRu8IeJqi1VVRa4eEc/uLiBSLaUlr0FBfbKo50xCmivZLqYGwo7WrSV5UZP a3VT5cZBIIPcUPFD0M2tACKsYfigUCf+4glpjMIOhTJatcwhhzd8dbPg3Xfyh4NSNLVm qFiEAzytJ0Ygss0iE7aBV3Cd0u0kqAXbTbsLYkfF8nAqhpmtfPboJvyD3jYCYx6C4DgZ xAfB4GlEGV+caqUjUKIRx7i4tsk8c7gOqBHHzMWbKmrpJ//WqdnLTV5LzkIwIq8ymx0I oRIw1Ka0MmxZnJ/yZF6qfS8chPHna4J61Vc0bzf2GO1zl2EORjJl2tJv3Ym6H4PQrHG1 4qcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768287694; x=1768892494; h=cc:to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6aB1YMGQen4QeppxKa0CPKNwdwfaYo/Ol0NlViX1KGM=; b=DH3mrjoCeHA2wLV4NSKWtzDsQhJjetvWsqIudaBTzzwya3JkVkxNDtqG/QQZESe6wh ZwrOEjvuM0gbGWrPVZL3kaxU68cTTUbojazn3+tVR5E5ssGVtfsjKnqmqA+of2NkYaPR Bwopg7Otm3Rp9C7Mm7tsn3W46+VyZOnxAMAq4DbJ07/ciE9x2udJ+mraG1sqyoEyxxwy I0LL1XkVAZVMpJgmvOyQHYasjmf1YKo9DsrRRl3D0x7lMCL38rX4E62DraO5Go5pHLkA ZswHYw/zWJzoM6Kp+pFb4H3we+Nxuk6eP9KzEsOJkD+H4jaDp3VbNVxm7VP7fmlisst/ mJyg== X-Gm-Message-State: AOJu0YxuOsZQ83YOvp8mjc1VCKDoZQTacpDkGuH4RXux5yo5ttq2sOpB L7HGMEArFZKHTPuUvdK8do2QhT97C+JUjA9UfQETW2F0nvEY5mIbH0+sjSmP8ql93Dpoe1jLPZN oXGtHvree4W+PdZWBNQ7+dI+H3CNNRRMfh7hr X-Gm-Gg: AY/fxX7Yv9pKR2Qn9JW7vsyksywEwuWpDfgafMIfJCTz7eP1AUMEtrycgAem+HSTSFj lHXvUH/YihX5sDNNG4HJxiyrSr8EJ3BGgxRUe8oB0XFeVcEh5Nlh6UqyP8+s8XDC1V3mvRu7oaO 8aQMOYhhzxDurBaNRb/JGCBFXoOqVeGoj1UAH5k9gp5ihCFfChi3itdWCvocQLxFEdzJKC0P/N/ d3UPXDE5RWsYOfoNscWF7w/Qjq+IGAGQmKbmTSUUWSKmad9Rsdwtw10f2kICd6msRKjJuGC7DwM nHUhzw== X-Google-Smtp-Source: AGHT+IHXe5iS39ifWI9d/jz3fbERUbKn2mgIzfvLDdiLxgkT2YcWgcUmk/Fx4qhqa7Jn6++lQCp+qYvEwYOQcHB2s5s= X-Received: by 2002:a05:6512:2305:b0:59a:11a4:4c29 with SMTP id 2adb3069b0e04-59b6f0410a5mr6699306e87.41.1768287693757; Mon, 12 Jan 2026 23:01:33 -0800 (PST) MIME-Version: 1.0 From: Mykola Kvach Date: Tue, 13 Jan 2026 09:00:00 +0200 X-Gm-Features: AZwV_QgAYBsA0hR4qP-pywTefCHjanYu4qjkMitQa2hRhd1-g1r5EjisWWoHD4g Message-ID: Subject: [DISCUSS] xen/arm: CLIDR Ctype scan order in get_llc_way_size() To: Xen-devel Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk , Carlo Nonato Content-Type: text/plain; charset="UTF-8" Hi all, While investigating current Xen code, I noticed that get_llc_way_size() scans CLIDR_EL1 Cache Type (CtypeN) fields in reverse order to locate a unified cache level. According to the Arm ARM (DDI 0487J.a, D19.2.27): If software reads the Cache Type fields from Ctype1 upwards, once it has seen a value of 000, no caches that can be managed using the architected cache maintenance instructions that operate by set/way exist at further-out levels of the hierarchy. So, for example, if Ctype3 is the first Cache Type field with a value of 000, the values of Ctype4 to Ctype7 must be ignored. This reads to me as an architectural constraint on software: fields above the first 0b000 are not architecturally meaningful for decisions (regardless of what bit patterns might appear there in a given implementation). With our current reverse scan, we could (at least in theory) mis-detect a "unified cache" at a level whose Ctype field is required to be ignored. Discussion points: 1. Is the reverse scan intentional? In particular, do we rely on the assumption that Ctype fields above the first 0b000 are effectively RES0 in practice, or that they may legitimately describe caches which exist but are not manageable via the architected set/way maintenance instructions? 2. Would it be more correct to scan from Ctype1 upwards and stop at the first 0b000, tracking the outermost unified cache seen prior to that point? If there is agreement, I can send a small fix patch with "Fixes:" adjusting the scan order/termination accordingly. Thanks, Mykola From xen-devel-bounces@lists.xenproject.org Tue Jan 13 07:57:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 07:57:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201170.1516854 (Exim 4.92) (envelope-from ) id 1vfZHM-0003pq-FN; Tue, 13 Jan 2026 07:57:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201170.1516854; Tue, 13 Jan 2026 07: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 1vfZHM-0003pj-Cj; Tue, 13 Jan 2026 07:57:28 +0000 Received: by outflank-mailman (input) for mailman id 1201170; Tue, 13 Jan 2026 07:57: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 1vfZHL-0003pd-Ad for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 07:57:27 +0000 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [2a00:1450:4864:20::536]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7e962e02-f055-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 08:57:23 +0100 (CET) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-64b608ffca7so11315583a12.3 for ; Mon, 12 Jan 2026 23:57:23 -0800 (PST) Received: from ?IPV6:2a00:12d0:af5b:2f01:96c4:9745:9e8c:b1e8? (2a00-12d0-af5b-2f01-96c4-9745-9e8c-b1e8.ip.tng.de. [2a00:12d0:af5b:2f01:96c4:9745:9e8c:b1e8]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6507b22c3absm19583558a12.0.2026.01.12.23.57.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jan 2026 23:57:22 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7e962e02-f055-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768291043; x=1768895843; 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=udupZtdAsPzlrIdfOCuKMf+Aba1CLTE+bnyLTRSaJoY=; b=EKqGK4JuqFkDU3zzmnx/GfJwjX21iub0a8r4OFAz6JjRXDdetcgBHoZ7XfRPJwEDV9 bWviVb4Wr9J/28rrHkLRFLAt2685/Ugbv9gQ2cez3RUxOlEJIEeDefux2TXrAnR4re2x 19KgXnpwOGBzCR6BVTfaniKdrLkJw/Qyw/mSRvpy/6YycMSjx6BZQPHvHxM7ub3UA9O6 R9AsBZU9hdTmy/DQ68wP4Ted6mXGGqUiCtxPcWp0lRz4kDjH6QJIKLtAxvpI93n+I9Go CxDuOn1GatajNeaSG8vebEK8q3248gQnRnwWNzxKd8TQobQ9DGMk5hHuI6ESKy5cXqWu 8hjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768291043; x=1768895843; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=udupZtdAsPzlrIdfOCuKMf+Aba1CLTE+bnyLTRSaJoY=; b=i7eP8WyVmYr19yx7Q1wmY1efUTOaQG+KiSkVPacqL4T7+ILh5owj04cfwU30pHPmQR LTIo2eQUywdrboS+gF5n1HNEPDEVdKPf2d6xV0nLrBRYaghzv4rvrS7x5kx6cZjIVNHx b3J3sIT4Oh3DxgJTX2FsfcNH1IzMuB0Ft89Lb0zmsZrIPlCgx4Bjx42vSiauBsNmcKap 3yDkTUqoKoH0069k2V+VDh7ets4HZZ+wWiD2Mp1vKwDIi1dw0Ei7Qfe0Vhaqq5H3JoPg ihipyfaMM81OYdVMSXB70HcUYi59zyTMbUS97SUbSS8odNGxs/mxHafFtQO1hFkR6AcH IHdg== X-Forwarded-Encrypted: i=1; AJvYcCWXi9aPPdsaQjTe+hAAIha5VvzvROELFzl8OQvPLtoA13U8MHIUd6odo6XbMrBTvk0/HZRhXMhgMD0=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywtl+2zTyM0EMCti/GAUt5OI7JSWBavM7fMRT5X0bLCEw3HM7gc XrZTPRxcdUNkj/t4eacw2CT8MuT2lNROQW+IKG0s8YagkNLGtGAfFQBx4UDA9ldaclo= X-Gm-Gg: AY/fxX5vnlO+v+bsBVwDAouQ+uY0UNj3xE/d2rMT8xtyt94blAgjh1rvRxrlkX/ZUDc wjmmTkJK9AS4bHTvZJOflt6WdRcqKQ75DcjcQIKjFGlcxVO5QtxDHUKRq3RsPD5d67cduwbHbuO Qzg9RtIUxkmMEmEY/p6pcDqFsvF6/xd0OQr088UUDrVtVrqQuog+FKAkM4rXRYAtL5QuV2aE506 CelQCmlloQ/yqB3WeKaYX2nsQQjzEqe4n3G1zq2ACLU7zbbLsQ+MIUhKK/VJ6XgpncHvfws/Swp 9b8nKbh1E9u1VX+WUaGddkLcEFuGQNL5TfJlkXdegnQ6B4FkGa54LO3rBEFnVSBqrwarHwef8m4 iSGtSS5smCadHmHt/okOgua7Ek1B1dqU3K/3W2/2cobR2ZuBnNnZSyJxAHoHtWhd9N/MJ8a4eJj KeNlpIXeGWJSbf44QjKQSxYa3fYbtWK7WBegF2kAL/Dr0CjH5GJJHyXPAfZXIeYYz5bzZQUqHrZ UM6g4iEKWGbRir4XXqxtILF+x51xqyOauyzzZA= X-Google-Smtp-Source: AGHT+IHVR/bd0P4qXwmWclbr1WTM7yPgnnr97onn6wf/cfvPSeCpos1AvfrsVD0L7aGVtaOLzc3XFg== X-Received: by 2002:a05:6402:3494:b0:649:cec1:6cf1 with SMTP id 4fb4d7f45d1cf-65097ce2c86mr18036355a12.0.1768291043048; Mon, 12 Jan 2026 23:57:23 -0800 (PST) Message-ID: Date: Tue, 13 Jan 2026 08:57:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen: introduce xen_console_io option To: Stefano Stabellini Cc: oleksandr_tyshchenko@epam.com, xen-devel@lists.xenproject.org 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="------------LSSFxxtpIYj0v0pIT9Z82sKZ" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------LSSFxxtpIYj0v0pIT9Z82sKZ Content-Type: multipart/mixed; boundary="------------sHv0zXIgQHppjk0LX4uXAWBV"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Stefano Stabellini Cc: oleksandr_tyshchenko@epam.com, xen-devel@lists.xenproject.org Message-ID: Subject: Re: [PATCH v2] xen: introduce xen_console_io option References: In-Reply-To: --------------sHv0zXIgQHppjk0LX4uXAWBV Content-Type: multipart/mixed; boundary="------------KUzPBRftuXCtXIG825Nrhkag" --------------KUzPBRftuXCtXIG825Nrhkag Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTMuMDEuMjYgMDE6MjQsIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4gWGVuIGNh biBzdXBwb3J0IGNvbnNvbGVfaW8gaHlwZXJjYWxscyBmb3IgYW55IGRvbWFpbnMsIG5vdCBq dXN0IGRvbTAsDQo+IGRlcGVuZGluZyBvbiBERUJVRyBhbmQgWFNNIHBvbGljaWVzLiBUaGVz ZSBoeXBlcmNhbGxzIGNhbiBiZSB2ZXJ5IHVzZWZ1bA0KPiBmb3IgZGV2ZWxvcG1lbnQgYW5k IGRlYnVnZ2luZy4NCj4gDQo+IEludHJvZHVjZSBhIGtlcm5lbCBjb21tYW5kIGxpbmUgb3B0 aW9uIHhlbl9jb25zb2xlX2lvIHRvIGVuYWJsZSB0aGUNCj4gdXNhZ2Ugb2YgY29uc29sZV9p byBoeXBlcmNhbGxzIGZvciBhbnkgZG9tYWluIHVwb24gcmVxdWVzdC4gV2hlbg0KPiB4ZW5f Y29uc29sZV9pbyBpcyBub3Qgc3BlY2lmaWVkLCB0aGUgY3VycmVudCBiZWhhdmlvciBpcyBy ZXRhaW5lZC4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IFN0ZWZhbm8gU3RhYmVsbGluaSA8c3Rl ZmFuby5zdGFiZWxsaW5pQGFtZC5jb20+DQoNClJldmlld2VkLWJ5OiBKdWVyZ2VuIEdyb3Nz IDxqZ3Jvc3NAc3VzZS5jb20+DQoNCg0KSnVlcmdlbg0K --------------KUzPBRftuXCtXIG825Nrhkag 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----- --------------KUzPBRftuXCtXIG825Nrhkag-- --------------sHv0zXIgQHppjk0LX4uXAWBV-- --------------LSSFxxtpIYj0v0pIT9Z82sKZ 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/Ey8FAmll+uIFAwAAAAAACgkQsN6d1ii/Ey8x NAf+J3YY4/KEUAnLPqVn7/0N0ssf2J5VzF4VMEhuQL8awfn173n3CcNfodCOHQDyQO07aI9Hf4+Y eOlCxTCrMLK8W/hIs4kdawmgV9W1Hf82l6nqmRAWDeEaFYv/dj3BhgHTJRinzwl6j8wZxAOPrssm Gdy8w6259xY0HFqbJhbhiKi6hAU8xalYJQOjDl6mclqKOpM1ZI0zHN6pbHpaRROUwGJ9+ATww6N3 7mTryuc1cJNL65wW3M5Jgtuh8pgGUqGT4jeTB3FQDcjTh/pTuCM9uynQtmpbAfH3yKVW8Ny9j9NY cc/SHLfOUdRCTTy+HtKyOKHZumbLGTmhO3IEQJ4xew== =jRIk -----END PGP SIGNATURE----- --------------LSSFxxtpIYj0v0pIT9Z82sKZ-- From xen-devel-bounces@lists.xenproject.org Tue Jan 13 08:10:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 08:10:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201187.1516863 (Exim 4.92) (envelope-from ) id 1vfZTi-0007AC-VC; Tue, 13 Jan 2026 08:10:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201187.1516863; Tue, 13 Jan 2026 08: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 1vfZTi-0007A5-Sa; Tue, 13 Jan 2026 08:10:14 +0000 Received: by outflank-mailman (input) for mailman id 1201187; Tue, 13 Jan 2026 08:10: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 1vfZTg-00079z-Q6 for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 08:10:12 +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 4722a92b-f057-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 09:10:09 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 09B6D5BCCC; Tue, 13 Jan 2026 08:10:09 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id D72443EA63; Tue, 13 Jan 2026 08:10:08 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id NerRMuD9ZWkyZQAAD6G6ig (envelope-from ); Tue, 13 Jan 2026 08:10: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: 4722a92b-f057-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1768291809; 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=iSeTos3KFRAw0G/tPHi4AxnXfVlaq9WlMN4TeOYpOUI=; b=kc+/3uPO6ILoGCnTuV+2chJEoRr0ghJ0js5ytV6EVoFPn3ggprPs/FIe9tDmMlM5RMfCtL 2w+Cji1PBA7DlGhtwHtQYr5cwwLGbiiL1eIQu5/KlePv67IEI881UvYF37WYKsxDJwGBNw JvmuygvGSRTdyVm/4lSiMVFixD1W2q8= Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b="kc+/3uPO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1768291809; 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=iSeTos3KFRAw0G/tPHi4AxnXfVlaq9WlMN4TeOYpOUI=; b=kc+/3uPO6ILoGCnTuV+2chJEoRr0ghJ0js5ytV6EVoFPn3ggprPs/FIe9tDmMlM5RMfCtL 2w+Cji1PBA7DlGhtwHtQYr5cwwLGbiiL1eIQu5/KlePv67IEI881UvYF37WYKsxDJwGBNw JvmuygvGSRTdyVm/4lSiMVFixD1W2q8= Message-ID: <4f22683f-8fd4-4db6-ac74-83c6f6460924@suse.com> Date: Tue, 13 Jan 2026 09:10:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen: introduce xen_console_io option From: Juergen Gross To: Stefano Stabellini Cc: oleksandr_tyshchenko@epam.com, xen-devel@lists.xenproject.org References: 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="------------SK2LT5FgRd0nxkYYjvEEjAKK" 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]; 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)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; FUZZY_RATELIMITED(0.00)[rspamd.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[suse.com:+]; HAS_ATTACHMENT(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)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; 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] X-Spam-Flag: NO X-Spam-Score: -6.41 X-Rspamd-Queue-Id: 09B6D5BCCC X-Rspamd-Action: no action X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Spam-Level: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------SK2LT5FgRd0nxkYYjvEEjAKK Content-Type: multipart/mixed; boundary="------------eF3WZ57hKAMerFmIO00Wiraz"; protected-headers="v1" From: Juergen Gross To: Stefano Stabellini Cc: oleksandr_tyshchenko@epam.com, xen-devel@lists.xenproject.org Message-ID: <4f22683f-8fd4-4db6-ac74-83c6f6460924@suse.com> Subject: Re: [PATCH v2] xen: introduce xen_console_io option References: In-Reply-To: --------------eF3WZ57hKAMerFmIO00Wiraz Content-Type: multipart/mixed; boundary="------------u7P0oc2qk9EcIVU0mKi4wxpP" --------------u7P0oc2qk9EcIVU0mKi4wxpP Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTMuMDEuMjYgMDg6NTcsIErDvHJnZW4gR3Jvw58gd3JvdGU6DQo+IE9uIDEzLjAxLjI2 IDAxOjI0LCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+PiBYZW4gY2FuIHN1cHBvcnQg Y29uc29sZV9pbyBoeXBlcmNhbGxzIGZvciBhbnkgZG9tYWlucywgbm90IGp1c3QgZG9tMCwN Cj4+IGRlcGVuZGluZyBvbiBERUJVRyBhbmQgWFNNIHBvbGljaWVzLiBUaGVzZSBoeXBlcmNh bGxzIGNhbiBiZSB2ZXJ5IHVzZWZ1bA0KPj4gZm9yIGRldmVsb3BtZW50IGFuZCBkZWJ1Z2dp bmcuDQo+Pg0KPj4gSW50cm9kdWNlIGEga2VybmVsIGNvbW1hbmQgbGluZSBvcHRpb24geGVu X2NvbnNvbGVfaW8gdG8gZW5hYmxlIHRoZQ0KPj4gdXNhZ2Ugb2YgY29uc29sZV9pbyBoeXBl cmNhbGxzIGZvciBhbnkgZG9tYWluIHVwb24gcmVxdWVzdC4gV2hlbg0KPj4geGVuX2NvbnNv bGVfaW8gaXMgbm90IHNwZWNpZmllZCwgdGhlIGN1cnJlbnQgYmVoYXZpb3IgaXMgcmV0YWlu ZWQuDQo+Pg0KPj4gU2lnbmVkLW9mZi1ieTogU3RlZmFubyBTdGFiZWxsaW5pIDxzdGVmYW5v LnN0YWJlbGxpbmlAYW1kLmNvbT4NCj4gDQo+IFJldmlld2VkLWJ5OiBKdWVyZ2VuIEdyb3Nz IDxqZ3Jvc3NAc3VzZS5jb20+DQoNClNvcnJ5LCBJIG5lZWQgdG8gcmV2b2tlIG15IFItYi4N Cg0KSSBnZXQ6DQoNCldBUk5JTkc6IG1vZHBvc3Q6IHZtbGludXg6IHNlY3Rpb24gbWlzbWF0 Y2ggaW4gcmVmZXJlbmNlOiB4ZW5fY29uc19pbml0KzB4MCANCihzZWN0aW9uOiAudGV4dCkg LT4gb3B0X2NvbnNvbGVfaW8gKHNlY3Rpb246IC5pbml0LmRhdGEpDQoNCkkgdGhpbmsgeGVu X2NvbnNfaW5pdCgpIHNob3VsZCBiZSBfX2luaXQsIHRvby4NCg0KDQpKdWVyZ2VuDQo= --------------u7P0oc2qk9EcIVU0mKi4wxpP 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----- --------------u7P0oc2qk9EcIVU0mKi4wxpP-- --------------eF3WZ57hKAMerFmIO00Wiraz-- --------------SK2LT5FgRd0nxkYYjvEEjAKK 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/Ey8FAmll/eAFAwAAAAAACgkQsN6d1ii/Ey9U Owf/RmMXh97idPBwpjiMFdfXjSRtrcD+Oznt0kifMOiqXca5BYtDPts+RTfM64JiEcTsGig9JZFP vGicKEtKYh4UI6BbIL0jyy4jzyOVSLu7lg160vwT/JDiR6ciBsg1JBL7A2qtadW51naC9o6T9NXD VAS1W11rmja1j3hZwMHP5My8qINSEg6c9s+1DmHo2NNlefOtsMNP90hl9HRtNqXOmAvNBAO2Lk5E h0e7MJFBvEvTqTvQhx0VvARQumaJFoAmznt67aSxviLsOtWA7rEQUFdMyo8aRUcGkhc3myrHAde8 XCHpNn4yvSx/MWjH8756Dd5Z5NdpRQqJr7An738+5g== =XgKh -----END PGP SIGNATURE----- --------------SK2LT5FgRd0nxkYYjvEEjAKK-- From xen-devel-bounces@lists.xenproject.org Tue Jan 13 08:45:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 08:45:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201204.1516879 (Exim 4.92) (envelope-from ) id 1vfa21-0003Eo-PG; Tue, 13 Jan 2026 08:45:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201204.1516879; Tue, 13 Jan 2026 08:45:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfa21-0003Ds-Kq; Tue, 13 Jan 2026 08:45:41 +0000 Received: by outflank-mailman (input) for mailman id 1201204; Tue, 13 Jan 2026 08:45:40 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfa20-0003C7-Jw for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 08:45: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 3c5d379f-f05c-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 09:45:39 +0100 (CET) Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by GV1PR03MB8709.eurprd03.prod.outlook.com (2603:10a6:150:93::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Tue, 13 Jan 2026 08:45: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.9499.005; Tue, 13 Jan 2026 08:45: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: 3c5d379f-f05c-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Ypizxbr9KlA+Zq9DFI2qYw89EvG7F2bIF5rKWMqP3VidpxpqSkyYSoCtJC3szlLISU7BicAKzUab+6cqAVrKiHBzGGlmpoul9L0pngoSfD2vDg59+gj7HBpWzJJRUpHAz9n2Vx2iHOxDQTdeb/4m3giEG86spbaTZmOS8JX+1ypr7GpjdYbiLoE5dmY72wEmJtBgX/FfuYiSZV/0AtoBliyhZyeO0NuEFUfrJ525FkT3sYRNJVaYG7VoFn1j7pPPqLSHE9jLp45ORfFggIMcfYVYv7LwGuB7LODr22bSp8FpY6OpNc+TS7O7hgGHuQsBKnB+vt9pIG+Z9KAJCSxIfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7iajnySkeHDY98iHHfq/Pdiht495trLBHcrNlpd8yI4=; b=D/1L+154ZlsVkafhb1gryXt8XBN9Ssmfa6DkTLhU3Z5+FPDSHQiG8o9LKSGKYFumDghYNz9wXbRUvdHYWplEtDN7cmYP/xcojy203tMNuwQRpDqYT0V99zxJFZ0zBKzdjdeEH3vtg29WRYdj2J8EBUcNFYIqvBNn/v2t+C4LJMCl7ZLOjyu5ejZrziTYf7MWqaNqpKCMckuT4PVfZaoVYimnz33sLyhqRDnx3eTlUy6V0fbCBh4NEcraVzncI6EoKAGtXTiQai+x3xBoed/SR+msg4Wlka2thKXGRUjq0NQKfOsshHgazvq5I/OaqzhqxJH+XhPUUMUr3b4de25qGw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7iajnySkeHDY98iHHfq/Pdiht495trLBHcrNlpd8yI4=; b=Fzd4Dit2PzwL85jpwEjL6jIv+EX60T6acR3HJXZb3Cl5mM3ZzvKf+X4/NnuZC7RraK9CnIHOa7qBICRQnvPVXOhjhBOOAdsNXaiMn/BYPgvZMHxbVZBKnWlAtWqSAAv7r4hQitpY+E/52uSqguRUFGUrdWu7qJnN72p/f92PdS6a6Pw46cBzPfAFHQ+rq7Dom0v7zEKIPjxDblraNuTMvGXYjdIfNF5u0rSNJGt3qTAVWpKP21+s1o9PA84djUsMHYgx71rvSlbEtyFyHds7lsQnbOP7fEgFr1BSsF/uugj5pKofpE24jDIUfn92TtQnUhJrkLNSQavUks8WjzlcEw== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v5 1/5] arm/irq: Keep track of irq affinities Thread-Topic: [PATCH v5 1/5] arm/irq: Keep track of irq affinities Thread-Index: AQHchGj7DB4SczePiEuTZHuufPnk+w== Date: Tue, 13 Jan 2026 08:45:34 +0000 Message-ID: <2991ec1845868940488c912c5dd34798a58bbf87.1768293759.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_|GV1PR03MB8709:EE_ x-ms-office365-filtering-correlation-id: 8aa5e9b3-9ad2-41fe-2c23-08de52801ded 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?4Uts1prxA9ysJmAl9V6XCt3l8Z49AyI0qks4R+CS856C87dBsy8tYUtzJG?= =?iso-8859-1?Q?hrNkRJdfThMe3GuJTJc/Z5ryYIgrQemhkXZb+Gvo36m0G9KISUsgr8YABB?= =?iso-8859-1?Q?Orp+iSPbriO1s3dbifQxs/qZw/4rmRbqXwLC5sHowidhFz95WZN7KeCw1c?= =?iso-8859-1?Q?Tlo578XNwspEpuHjR52sLK7QxPHGZ9zuEmnQW6i1qBnpz12b8xaEuzPkUH?= =?iso-8859-1?Q?5JIIrMljmeKo3bO4aH3R9G4MP80SdvZSUif4CKp88fb3tTjkFrimbOed7V?= =?iso-8859-1?Q?ALGMYgIvrm7jOStqsSEkXHKkK/KJKzWyP6M3HaxmvbhgoXffSAkTDJgYm+?= =?iso-8859-1?Q?8bziGP3JHRUerkBwQfIoR9Vz3H+Q2oxmDb9K6L5FeILc/td/zrfS/PhN2F?= =?iso-8859-1?Q?93GrszqdwqCPXbCicdL9+CQw78//KglvXGAwW3Gy87lJvm6PPKEZIX7eZY?= =?iso-8859-1?Q?JjTDyIzMmrIouITXjfhEtY98lPLJ4amCXvL9Z1K8JoKZZFH8a5WSMQ4U4n?= =?iso-8859-1?Q?Jm/kArSzjaFiT8q5CWBUlKQfYaDlxroIk1n5rWlheBiE/R0TlTN5GtzVFs?= =?iso-8859-1?Q?nO/FGidKK4yNPSoDIh1a4mbmTDfUTElCKNofjqG4D0ewCkNOT9vLB0orkX?= =?iso-8859-1?Q?0nbfQ3IHtp6Ax/ihkD/Mm2YUNxYrQYKZPXdS+uts58fVqA8UGKZ/GbrkrK?= =?iso-8859-1?Q?RhLq4cWON5u53SojWn4Zu4eLubd2MIE3tk55JfdldeHXqPhsqQefyP9CUj?= =?iso-8859-1?Q?qWG48VncCabBZBpxoqzSN2mC8YgZlkYVFt0ByzM8z0BXoJtFtEbl90LDMK?= =?iso-8859-1?Q?jWrTIrIcS1q6hpYOvlQxO79+iK1KlfPFK5Fu7S8k4+teoOq8c6gzjUZxtH?= =?iso-8859-1?Q?K4zM05yxqUHz1Zhdf5uZh5aGqwYIziAsCIxFRa3B5hH7dTib3DlypAzR70?= =?iso-8859-1?Q?ha1SwrCFE+Sh2dJFEWSl5SzokiZnCtB4v/35BGYJkgIuMeA5i2J1ahZgo3?= =?iso-8859-1?Q?ZPfTqF8XDJsd0WcnYl+SAIyQ1TIvm5V1qjdQT97UAsoy8KRmMCpov/1fg9?= =?iso-8859-1?Q?H2YSOT//wGDLY+WwylFTLUaqRYpg4K/K587ELs8yaT5xLHzHs+Mges8Jfv?= =?iso-8859-1?Q?LEWEVl7bl8V2xugskctQ4ABrm91FzLi260jliUIAPjd0El+lr+SFEaHd3X?= =?iso-8859-1?Q?+FgapLSwBgcRlb1OCYzFbrEekuCoe1G4PNiqQP7BQH1cj77MY4PIM1rQgT?= =?iso-8859-1?Q?K2r7j+K9tO3TOe/kZmyImTrvLey++7b+711AixnvAoBADGJUe4x47/2t7P?= =?iso-8859-1?Q?Z6sUTTyzhCu9Z7SZQ/iq9tsFq5cXlJGVBwnmAvAqpU8cRzlpp+ubyDnfz+?= =?iso-8859-1?Q?ZuRnSqEd62hy4uov8f1QEh9z6To2GrCXgHnbpbYRrjss5doPlYr2mUbpxC?= =?iso-8859-1?Q?jr3qvP2PDjbXNZIeJskBMMAFyY62cPTHODVUpHLFkeBEkefNC7YhDpJcn9?= =?iso-8859-1?Q?BTB1M2Vut6tIEIHdTES0bvVFrFVplpdWnjz5HrSg5rutb6kbKF877tuaWm?= =?iso-8859-1?Q?n4+y36xiqW9MHRgnwRn4Xejdt13/?= 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?jozKfmSJ2acrxFlm63e3XX8zV1Aq+FSD3PHn1dLi2ip1frcirDui2yiMxx?= =?iso-8859-1?Q?6avmpdNYF4rWPdlLblFp93dbum5u/IHIktw6wLeHDH/e6bSahb1ypyM0Kh?= =?iso-8859-1?Q?SN/VPGu3GqgK1aeU7YQkCb303RLTFOEnYT2C0U49ivLCFbTGQQ0zkemL+L?= =?iso-8859-1?Q?s6P32Cx7sTrEzJjCgT73Tm6kTKsubkrIypd5anc1IN2yIkNi1bibZXS7l2?= =?iso-8859-1?Q?3qVflnOuXxVbpmXkkET5cHCWgR8u88pegHZlXeV9dQkvZrpqdoYkdqhrI3?= =?iso-8859-1?Q?KUnwmLeIi06sxeicx32RGEq1b3U/bECilYetXcCnUTwP+CfJjNCckDR13x?= =?iso-8859-1?Q?qRE8yqUz53dQn5cqDKlPfziqA6UmF9SAnRhkmTMGCOeN5MEFjHvydX91iC?= =?iso-8859-1?Q?c1k6RFQqNWrTXwG0buipazgFKU0HY0cgz3kt0I+uZXDm4WdAVlrAgywXi9?= =?iso-8859-1?Q?gx293IZ2x6TOI02PFovkQf0W1niv8qQ8h7YtVHu6zYyusC787I257QQPpj?= =?iso-8859-1?Q?i46GWKYGDPHsThcx2XilbSzSTahYWQ0n9BM13wJ+EC8lfQwkKAK10ycS05?= =?iso-8859-1?Q?OuQoRzzUdMWQygqZYw2d8G4F69ipdXqhyEhtHb3lKzRrDGqfeEBJe9IxPW?= =?iso-8859-1?Q?o5R/RQp4bbFJi5ycoG+hIgwbApqGd2Y/myGWaqFpw6NlJBtV35q/nwsyTM?= =?iso-8859-1?Q?yIKFMMw8JW15bJMiZiPYJWd6QGVaCEbLS24eLbC63Fcictpy0Nq1jT5ZB4?= =?iso-8859-1?Q?ICwcasvcfwrFYjvRJnoVpXIu0+BPT7PWfyGmFkEfUtWZ0mFGsMF67eBDZd?= =?iso-8859-1?Q?dKZH9ArrqKIlGMx8x0HefhhpbYIZEfv2k5EzBGmpC7UDd8LyaiAQ3N/stT?= =?iso-8859-1?Q?YDDOJF3QfOtdZV1RbjOVt8XEtmRE8lycMoXIsHcxIGtvw+TMpJj433pYOa?= =?iso-8859-1?Q?XGpJKvXP64UyMTJe/MWqfOBrpRvXtNIwfzRT5WIBlaugTeElz3P+uUaje6?= =?iso-8859-1?Q?lBNqaRfZSvraGiCQQAIYZnyHsDCUGgQL8v/YGX6kQ/izH1h/yws1OX0RPt?= =?iso-8859-1?Q?otn+u9AzNH2Uvx5+3imKPlKIhbw/8c4OeXjMqUWsTa5kVrq+t/2Kq+85vD?= =?iso-8859-1?Q?PwKWuQc8gkmQ2eTb3lIoiNQptdtCcu/Es5E4LbhOsv9epP+GyDu9ch/uDK?= =?iso-8859-1?Q?n4YVYioanVlYKlZlneGysQHj1e7XgiLM75Xh0DaDfYYjedDCxLrnA1YNRl?= =?iso-8859-1?Q?G2jH7JsVFdfglBoTp+wLNjQVGK6Pswss+XaBkU6DyIxkzwuATrizAt42jy?= =?iso-8859-1?Q?NWuwPG6PVMNT62fkY0S7HrFpkekoqBbGsU/bj7c5gGi2TQFoc8at9+ApfZ?= =?iso-8859-1?Q?MrAL+rp5OJI4qERu6Qvd5MqmB9MCeehVoVPqNj2HNfzM6iqQfg3X5Cuz35?= =?iso-8859-1?Q?ONMb3JaCUSVcJ68nE3tvjwG8bqYW/+EqI3cbvk1sU6oQzXj6nPMfRVK9mR?= =?iso-8859-1?Q?rfncCm3A+4RE8OuilDCztQOnWqoG/+8pUMTgT67MbjFVlesuxjHCwpSjBB?= =?iso-8859-1?Q?cHjIswqjLn6X3YG6AxptSLMTaLTdJJFgaX+8QhyIT7g8t5mmPEK8v/Bu7b?= =?iso-8859-1?Q?tHfpNkwUKxynvsVl8cSiJvmJk8lJqil01XaAh8lVpr5N69kBSkeQcnKiby?= =?iso-8859-1?Q?3eOt/QCFELz/YgJTbpq7CP4tzmf5P/ED3uhmHzWCz4FIaNjKwFOMOSCmBm?= =?iso-8859-1?Q?4vkM3DNpI4kq9mgH4Y+c2rfIdpt14pC8sq+QNh4EZtm0jGLqpxd3uANvmy?= =?iso-8859-1?Q?ovsx78EDLk+e61Qij10o140gsNzdXQU=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: 8aa5e9b3-9ad2-41fe-2c23-08de52801ded X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2026 08:45:34.3555 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: d7thUQ5nrObzP7dVDPKtRu3izYidJjTv86goA+9IUE4yt6oO9TOKckV+rCzsKHWPuX2GgVr+Gzl+VVQX55oqnw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB8709 Currently on Arm the desc->affinity mask of an irq is never updated, which makes it hard to know the actual affinity of an interrupt. Fix this by updating the field in irq_set_affinity. Signed-off-by: Mykyta Poturai --- v4->v5: * add locking v3->v4: * patch introduced --- xen/arch/arm/gic-vgic.c | 2 ++ xen/arch/arm/irq.c | 9 +++++++-- xen/arch/arm/vgic.c | 14 ++++++++++++-- 3 files changed, 21 insertions(+), 4 deletions(-) diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c index ea48c5375a..5253caf002 100644 --- a/xen/arch/arm/gic-vgic.c +++ b/xen/arch/arm/gic-vgic.c @@ -232,7 +232,9 @@ static void gic_update_one_lr(struct vcpu *v, int i) if ( test_bit(GIC_IRQ_GUEST_MIGRATING, &p->status) ) { struct vcpu *v_target =3D vgic_get_target_vcpu(v, irq); + spin_lock(&p->desc->lock); irq_set_affinity(p->desc, cpumask_of(v_target->processor))= ; + spin_unlock(&p->desc->lock); clear_bit(GIC_IRQ_GUEST_MIGRATING, &p->status); } } diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c index 73e58a5108..7204bc2b68 100644 --- a/xen/arch/arm/irq.c +++ b/xen/arch/arm/irq.c @@ -216,10 +216,15 @@ static inline struct domain *irq_get_domain(struct ir= q_desc *desc) return irq_get_guest_info(desc)->d; } =20 +/* Must be called with desc->lock held */ void irq_set_affinity(struct irq_desc *desc, const cpumask_t *mask) { - if ( desc !=3D NULL ) - desc->handler->set_affinity(desc, mask); + if ( desc =3D=3D NULL ) + return; + + ASSERT(spin_is_locked(&desc->lock)); + cpumask_copy(desc->affinity, mask); + desc->handler->set_affinity(desc, mask); } =20 int request_irq(unsigned int irq, unsigned int irqflags, diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c index 6647071ad4..c59f6873db 100644 --- a/xen/arch/arm/vgic.c +++ b/xen/arch/arm/vgic.c @@ -445,7 +445,9 @@ bool vgic_migrate_irq(struct vcpu *old, struct vcpu *ne= w, unsigned int irq) =20 if ( list_empty(&p->inflight) ) { + spin_lock(&p->desc->lock); irq_set_affinity(p->desc, cpumask_of(new->processor)); + spin_unlock(&p->desc->lock); spin_unlock_irqrestore(&old->arch.vgic.lock, flags); return true; } @@ -453,7 +455,9 @@ bool vgic_migrate_irq(struct vcpu *old, struct vcpu *ne= w, unsigned int irq) if ( !list_empty(&p->lr_queue) ) { vgic_remove_irq_from_queues(old, p); + spin_lock(&p->desc->lock); irq_set_affinity(p->desc, cpumask_of(new->processor)); + spin_unlock(&p->desc->lock); spin_unlock_irqrestore(&old->arch.vgic.lock, flags); vgic_inject_irq(new->domain, new, irq, true); return true; @@ -473,6 +477,7 @@ void arch_move_irqs(struct vcpu *v) struct domain *d =3D v->domain; struct pending_irq *p; struct vcpu *v_target; + unsigned long flags; int i; =20 /* @@ -494,7 +499,13 @@ void arch_move_irqs(struct vcpu *v) p =3D irq_to_pending(v_target, virq); =20 if ( v_target =3D=3D v && !test_bit(GIC_IRQ_GUEST_MIGRATING, &p->s= tatus) ) + { + if ( !p->desc ) + continue; + spin_lock_irqsave(&p->desc->lock, flags); irq_set_affinity(p->desc, cpu_mask); + spin_unlock_irqrestore(&p->desc->lock, flags); + } } } =20 @@ -574,8 +585,8 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, unsig= ned int n) spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags); if ( p->desc !=3D NULL ) { - irq_set_affinity(p->desc, cpumask_of(v_target->processor)); spin_lock_irqsave(&p->desc->lock, flags); + irq_set_affinity(p->desc, cpumask_of(v_target->processor)); /* * The irq cannot be a PPI, we only support delivery of SPIs * to guests. @@ -944,4 +955,3 @@ void vgic_check_inflight_irqs_pending(struct vcpu *v, u= nsigned int rank, uint32_ * indent-tabs-mode: nil * End: */ - --=20 2.51.2 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 08:45:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 08:45:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201206.1516900 (Exim 4.92) (envelope-from ) id 1vfa24-0003gk-7W; Tue, 13 Jan 2026 08:45:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201206.1516900; Tue, 13 Jan 2026 08: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 1vfa24-0003g8-1s; Tue, 13 Jan 2026 08:45:44 +0000 Received: by outflank-mailman (input) for mailman id 1201206; Tue, 13 Jan 2026 08: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 1vfa22-0003C7-MG for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 08:45:42 +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 3d674ab5-f05c-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 09:45:40 +0100 (CET) Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by GVXPR03MB10705.eurprd03.prod.outlook.com (2603:10a6:150:21f::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 08:45:37 +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.9499.005; Tue, 13 Jan 2026 08:45:37 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3d674ab5-f05c-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vD08+DdqUTmdIoeU3gbIz/t6JWAO9aUQzknblf4QkQS7PpulRxCB5faGnh86d9EMCQ5xB+t8o5jma+zQlWR5kchxUUO/2IzfxzTOKrRIn5Vtac1h7m58naSbo2immhBnYmPaMT88MpcnrgruRYs1OVT7/qwFi6IMg0ostyXaMiYtk7SWCZRvUEtxubpFBq8OdP/nys9Y01nvhldnnYFGS5ClDAktP3mClNO6LglcZ5I4TQzy5CsaJ/MJnbxqJ6N151yVbJbda4Wx9ycPEFlzKnpU+0LkukuoqREhNXVPU8GGSNB1Geidm4Q35aEK/Bdp1hZ6PGENL02Sk1tHi+KE/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=RBC+MU20Th/zS5Uxes6um30jksYuWzUOw6w+4COUtC8=; b=rdkn8Pn3fKbe09xflt1sCo/hsY+dYiOTwVrorOTl2bEYVYBQFN551AiOA3ciT5bkd6CJEt5Ei51c2fPOLYRQKN6bWbbqkkkuA0ww+xrhuEvKlH1oWZ73KAOFIRHMfUlpzQaPVzGF7xV5jkzIaSZZN+GoR9Uq08Lqv3J08B9XGGsjtMGNJnpLS9Irbn+qe80gW97W62LLTgE/QsYi+0S8yRQO6600H7YGhtif4mjgRZ1nAmYbOFIo5+jxiZ8cMySrIue5IZ7Fz8P1DyR6DnZ/OrDhh40mpYct+76szogmTEpGCgkWWg7Fc+XvV2NAr3IsF7FK+pCVBMBLHIDKk8AwMw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RBC+MU20Th/zS5Uxes6um30jksYuWzUOw6w+4COUtC8=; b=uqMOO0roc6/qUZD1r6+2mmpxsbVYk2MlnaGsnjQbLhYzD97zgeA7TYihA1ckTBFEkqG0IVAvy7WZS8DaPgoc+o9iqkYIe6UO5dctHscM0wMwcbiCWiTP6QT00GRT4Iq+pugVxoKjSxqkhKhV2bgFvLnyeDkYoS+pegJndIe9CRLCQeNT2jKODBNuBho0Mmwi+CeEf6IMlwG5dlEeDA/pkjDIspTy0OzX9LLpsHK3cPyYJb7XxLweTU5hlAgz6nI8E4XHKCMBqx5qXpTSdwNzNF+blAT5PpIk8CUO9Jgol5h1dVcYppnkfmmPWCx6RpeOfpON69/+KLXuvVOw6WF0wg== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini Subject: [PATCH v5 5/5] docs: Document CPU hotplug Thread-Topic: [PATCH v5 5/5] docs: Document CPU hotplug Thread-Index: AQHchGj8vwoLQF87MUGoty+ABjFapg== Date: Tue, 13 Jan 2026 08:45:36 +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_|GVXPR03MB10705:EE_ x-ms-office365-filtering-correlation-id: a45c291b-3a10-4651-dd0f-08de52801fcd 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?tIbk/NRak+OGlXTbGSTn3VhRJFH2+b8ft5noD3+J8aOJSw+zCj7na0PZKc?= =?iso-8859-1?Q?z/kLPPwt47/8oTiyC9DTe56yW0obxQ1cnzWrHHJyfsDbiJyWydG1xij8ps?= =?iso-8859-1?Q?DtmgT+nPYYwytg2s/DXWyVIKaeu/M5hnQZXfCYa0pSBWAG/vc/5KEoWUKH?= =?iso-8859-1?Q?Lu9qe4re1sMhkDYFASrk0id2BNhyadqMN/RnxDeqcRyF9eeC2ZZiuLZoV0?= =?iso-8859-1?Q?d92jJzcwAJc88rO+egZ2kz7kzjPM+NltHZ8IWlT9JjkGs2TawsHdTOhnjL?= =?iso-8859-1?Q?hKsgVXL02Hy4CPtqPd0cKMbfw11Co7htlZCbJtpHqLxTwWZ8QJvhuvHXvI?= =?iso-8859-1?Q?jTv6c/Tn5O3eGJ3q2Rc6A8ow0pZ1Q2PTxGB7BW217o6Xt/v6wO0ZmErBix?= =?iso-8859-1?Q?KklwK3KkQ4zTGnc519UUKJ/cvLL6/yLKF7jLijJf/dsbci10p2THeXFEeP?= =?iso-8859-1?Q?xqiYWmCCDXb2FxaToQIcmc2kh5F7uyloM5OicOOQWGkY4mtZ0WB11r0NCC?= =?iso-8859-1?Q?kGO+fdfoxUIOXhnTRCaBipi1M0lsrS11VnNY/aH+LY4nflnhXHkZGtzeCU?= =?iso-8859-1?Q?E8na+PyVDcHpfCWFM+SvRWdqAEVlwUjCn7xDZ2xRQBxzjUbBpXwXs+oLRE?= =?iso-8859-1?Q?jIDOrI0FR+pior28lx76hRmY2EOs+yNHVZm66Xnj8dZqBrWBjC8Abos2YP?= =?iso-8859-1?Q?uqk85ZsFuct/pNWrojS0BkudihbEPfNh1xPXcmTW0ksfrxlo34po5WSlEL?= =?iso-8859-1?Q?mSuUyR3tjmBZ1sndsIKWz0cUYELGYt38vXCtEUb5aM1YqSiiFDvZ4yaNJ0?= =?iso-8859-1?Q?bMppuGW38T500Kt9pqOrJYLkDd05ASjliRyuK3UQUPBRK5hYu2Qv0z0saK?= =?iso-8859-1?Q?J3cRvIjm7v2wmq/POrgAPNRxtpXvnQZLA5isay5c/ndQAeebdDsXkxVz8d?= =?iso-8859-1?Q?ygDIGnpq+QgLneRay04HiGAPG6GqBgACoWkoaDSQdAxREakoQwBSm4EBsa?= =?iso-8859-1?Q?Qh5wPNYNFhcKuTuEsEIppGkjCh+6qCVgHVWj9Mub8Z/EJS3S8E4OH+VpRY?= =?iso-8859-1?Q?uxpgmjAdTreqcm3prYbR7CL8Ijig4MYKENR2JdaK7Vpp/6sImvT5HgvrzF?= =?iso-8859-1?Q?T1mdtnMgyry0BdEAgT8maPDd0dF9WqngSp8FhZUpExHMtxFQJ/6FB192z6?= =?iso-8859-1?Q?J4CJXQUz8UFBKeNnQzOV/Cm680wbjt4AfBtuKa+q4uxvQyi0/IwEEiFlgL?= =?iso-8859-1?Q?g+nnPP5yUA2fGlxTSgQFsZLoi7ZEJ+n1qt/L2fucuxwlby0v5/dcDXGNqK?= =?iso-8859-1?Q?ESBheC7dVD6uuz3QhHMFWfP9VxrH/5FnuUHK67j2qT9T+FpUwmTdrwJvPH?= =?iso-8859-1?Q?6go71Sajgkw1N87QN9GF7XKZ8nGzcVBJQL0TfpN3RxqmAhpdraCkjH0xRw?= =?iso-8859-1?Q?j2qu++n0N4LEBiXtIujyTJ2RNbOJ2FuPkpw+ycsnAH6K9y4kF+UAzF4rvz?= =?iso-8859-1?Q?PMG78x7nBPM/pJuxbWpE+CLlMRlTmO6diVk1dvVLUB4xB90Gpup7k8sthc?= =?iso-8859-1?Q?NAUKY7AIB3/pY2IBASiEsIZ8eZ6M?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB10102.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?Xq9Hy0oNutWriZlYhe/SHrteH6pYAftnUl6CZ+b/TT8vawDiH7IO1ee095?= =?iso-8859-1?Q?Tif+8AkmJN1XmEEkAfMUJF3utowJAlkATc7CVavv5tnOrG2DE4OtTLTMoE?= =?iso-8859-1?Q?lYdZFM5/DHeCfvVgsA7LCXentlmHYMXF/HiWUY9l2kr7iWSZxXfuerKUls?= =?iso-8859-1?Q?a0ndsakhjai8QNHvKB1xTBaIv5GIbR74ZOMIypVrwUoFbJpA93Z3GfwTMg?= =?iso-8859-1?Q?Oc+1XWALl+PHzyqChxxyzerYpnbRsA8Gqpsos57Dz1OXJpSBd6f4kvpCqg?= =?iso-8859-1?Q?gcAxjkZW69mVBA2RZfQu7v6pRaUnoL9JyOM4FkGZzW31G4QV1JcklMIM8i?= =?iso-8859-1?Q?2ZB1DSWOnHvUsL9DnYxLEFvMi2cP6CreF+BIhvZZRcNQPFski12tci0w9A?= =?iso-8859-1?Q?6YUDFoAQcVxSoRClbq9QsRiKY6F2XJ9lDbAgsvRrGDrgGDwenM7ew7VWWr?= =?iso-8859-1?Q?0YMB3emGM2qFF3EJJvLRasOPh+y3Gd5uJ+g5mW4Pb05Ev+GM6WHOCNv5i7?= =?iso-8859-1?Q?CFfboSyhz5ZPGMjjbmwLbQ53ongzY2x6nrw3eo96RyZN//XfXG0GoP43qM?= =?iso-8859-1?Q?g/JWEuaC5UC4NWCJYAPcZmrKcsJmSjNJWFbmf7JusA/t700Bl+ckJzftdE?= =?iso-8859-1?Q?6QP9TZqCUs4IPVe8WJ/MTN6pjTjkFJr1S9NoYa7S+s1kb5ipmvMqWmLQq7?= =?iso-8859-1?Q?TeYFX22KsYWLdzP4sCucMno7JFY+mxIT9FSO1SFI9e525Yrvu9gjFjg9OC?= =?iso-8859-1?Q?/CIV4PeM/OHZEDSWWXQzygi2RNrQciJLyNgFPyDSw17NwfG6HBiMFYqy2Q?= =?iso-8859-1?Q?DRCFP7rmOnCw+9pxi7/wjE9tgk5lali/1bUqWnFYde5HidfVMNp1ZeHveX?= =?iso-8859-1?Q?z54VrzKvahUOyKDkL8OvGx8iOxgL4LnVOEQnH8x2MFJFw4sdJWD58f2syw?= =?iso-8859-1?Q?HZVfRfjrgVlfULsNJWsGL+Uh1wVwp2M6xZWuE9mtNcBCQjltlZBx9kFzIt?= =?iso-8859-1?Q?qRcCluHuBI9crQkEKB2xQtIrbv7Ub7kReUQFzsquDGdZavZ4qWZYy0M7C5?= =?iso-8859-1?Q?RHE9YlSc4ryAjBvNO74b9hSiojjLPqgGy/dXuVnx0GVlCpHfD0LCVwWmCt?= =?iso-8859-1?Q?L4B0GQfCr0iQNqhR1x0vgbC+QzQHcPZLiYFEXn2r38J6ufXsVP0CJVb+ZT?= =?iso-8859-1?Q?dPw1ifn4Vvs88+CcsB88Y1o7RmHCEk+WDBMpwefIt7DEuEzDLBIP8QQGBZ?= =?iso-8859-1?Q?KZSSBDRkfnsf7qaX9kFsB3dxnXDZDCGMQ0fumkmIP9aekNT8n9fjPod9Q0?= =?iso-8859-1?Q?RPgL2Yxw7M9L7xX3Qc7vfVyS7Bhor7nL6/fBJd7MMOYsIdaTHuPp/QqA1d?= =?iso-8859-1?Q?m+Ok1EcFvYeL9TE73SQhjju7fzAFW/CSrxC4+A91xVVu9mM6O4EYyGvfLt?= =?iso-8859-1?Q?7TbFs8VTtbQiT4VJfm6Fg8m/sIue2yeyF3KEqWImHA3k1HoFNn2M3hOGk5?= =?iso-8859-1?Q?ffHKs33OkzMaRL/WP+karxJFxkvdQoP/hEEG25o+8nStUgeCKGWX15J3a4?= =?iso-8859-1?Q?jKy7FRyxHpjTkl0QO3+nQDp9j1rwhWO//gS4xCMn/Cy9CCFo82VtxtinjO?= =?iso-8859-1?Q?FAc+nxKr81KtQbmCzUXsOqGHkSUVuYLQjDZao0W3/Ky6fgeelbK36nVoji?= =?iso-8859-1?Q?ReHwMqZ5zuhH/cPVvg49QKOwiZdwlzSnoHdgmp8/wQeV4QDYoJz4u6E3FM?= =?iso-8859-1?Q?2C4hSby77i36u0cXNKs7++FC7FIxlaIS7gIDJbgN9qXVbG9ouCrj4K0qGH?= =?iso-8859-1?Q?2wxBf6yvlwScoWH0f8Tge7r8vUe3rqQ=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: a45c291b-3a10-4651-dd0f-08de52801fcd X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2026 08:45:36.4156 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iAg0xaEtr/onplm6aO/E8GaAo0NKnAtkqJmX15PYWQ3ZgogwVJimLZEAnWmloLvghr0bul1cieJdpSRmrzMDJQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR03MB10705 Signed-off-by: Mykyta Poturai --- v4->v5: * s/supported/implemented/ * update SUPPORT.md v3->v4: * update configuration section v2->v3: * patch introduced --- SUPPORT.md | 1 + docs/misc/cpu-hotplug.txt | 50 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 51 insertions(+) create mode 100644 docs/misc/cpu-hotplug.txt diff --git a/SUPPORT.md b/SUPPORT.md index d441bccf37..7b93ae69e7 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -52,6 +52,7 @@ For the Cortex A77 r0p0 - r1p0, see Errata 1508412. ### ACPI CPU Hotplug =20 Status, x86: Experimental + Status, Arm64: Experimental =20 ### Physical Memory =20 diff --git a/docs/misc/cpu-hotplug.txt b/docs/misc/cpu-hotplug.txt new file mode 100644 index 0000000000..c34fc66361 --- /dev/null +++ b/docs/misc/cpu-hotplug.txt @@ -0,0 +1,50 @@ +CPU Hotplug +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +CPU hotplug is a feature that allows pCPU cores to be added to or removed = from a +running system without requiring a reboot. It is implemented on x86 and Ar= m64 +architectures. + +Implementation Details +---------------------- + +CPU hotplug is implemented through the `XEN_SYSCTL_CPU_HOTPLUG_*` sysctl c= alls. +The specific calls are: + +- `XEN_SYSCTL_CPU_HOTPLUG_ONLINE`: Brings a pCPU online +- `XEN_SYSCTL_CPU_HOTPLUG_OFFLINE`: Takes a pCPU offline +- `XEN_SYSCTL_CPU_HOTPLUG_SMT_ENABLE`: Enables SMT threads (x86 only) +- `XEN_SYSCTL_CPU_HOTPLUG_SMT_DISABLE`: Disables SMT threads (x86 only) + +All cores can be disabled, assuming hardware support, except for the boot = core. +Sysctl calls are routed to the boot core before doing any actual up/down +operations on other cores. + +Configuration +------------- + +The presence of the feature is controlled by CONFIG_CPU_HOTPLUG option. It= is +enabled unconditionally on x86 architecture. On Arm64, the option is enabl= ed by +default when ITS, FFA, and TEE configs are disabled. +xen-hptool userspace tool is built unconditionally. + +Usage +----- + +Disable core: + +$ xen-hptool cpu-offline 2 +Prepare to offline CPU 2 +(XEN) Removing cpu 2 from runqueue 0 +CPU 2 offlined successfully + +Enable core: + +$ xen-hptool cpu-online 2 +Prepare to online CPU 2 +(XEN) Bringing up CPU2 +(XEN) GICv3: CPU2: Found redistributor in region 0 @00000a004005c000 +(XEN) CPU2: Guest atomics will try 1 times before pausing the domain +(XEN) CPU 2 booted. +(XEN) Adding cpu 2 to runqueue 0 +CPU 2 onlined successfully --=20 2.51.2 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 08:45:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 08:45:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201205.1516894 (Exim 4.92) (envelope-from ) id 1vfa23-0003dQ-U3; Tue, 13 Jan 2026 08:45:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201205.1516894; Tue, 13 Jan 2026 08:45: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 1vfa23-0003dJ-Qz; Tue, 13 Jan 2026 08:45:43 +0000 Received: by outflank-mailman (input) for mailman id 1201205; Tue, 13 Jan 2026 08: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 1vfa22-0003C7-8j for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 08:45:42 +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 3d58556c-f05c-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 09:45:40 +0100 (CET) Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by GV1PR03MB8709.eurprd03.prod.outlook.com (2603:10a6:150:93::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Tue, 13 Jan 2026 08:45: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.9499.005; Tue, 13 Jan 2026 08:45: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: 3d58556c-f05c-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZtUpDEEsjsY9yUano1cwJNw6/cP53dtvs9Vpytuntxua1ZIjRHTazCT0VZPPd2va+2aIR93vLPoJjm8HQ+M5XXfEKcxFVteiNRh3N+qo+nyiEAk3T0FVO9iWnnhrgOWJuA/YmXrScqYXhkCcFK6kYQUhq2JOtfQzq3aZyc2BLYaYgTv0WDDfknRaGTc73f4Zr4vFLO6vQCX6yAcSyOpS8eQ/+q5rcSvza/Nshb7RvErXA1byMIKXNbQGb33Wvh8l+FGy6lbSGfPucLEQMsFWgev2ihfkNRWQBwSlQ/aOsmUzzYMCzkUcOEWwZo97vJfsJfKylXbFZ7I44NkbwJWYTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WifUOeJgqNlDzh/YVDJM7F9LX69JT6jLySabIGEh2KY=; b=rnmtutq6gT2JanYRSPmY7BLlwb/YGoh+E3FxA2vSaCk4+m5CALs0M+viP26kz8lhCLIte3gGuwH4nbZ2IXiEOXU4nWItzULeKwpa+0g5+6KykAKUH/FTNPIkOEx5NDGAQZQhTxKhcFz0D/iSoiu0wkzAiutZVvflIi8V3yR+9XhHRiHrisu1XeA93QybJWrFtjOi/c2ti1wSPXKFoHhdK0Bbr1piJXgnDEXAWDVQeHNynma8d7KoaRkk9KdZJnb8oHgE273T96e1Slf5P3U4T72Pu8B+VBv1PXRrHFJKXKQf4eU37W0ZU/SBf+A8QJPlabKKaHXbHk4MMUGHQmOifw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WifUOeJgqNlDzh/YVDJM7F9LX69JT6jLySabIGEh2KY=; b=AK4Jrpy86J8uhLc0dRinVNzhzwnaL4GyxBOA+0CRsnzdtebmre4QXNBEXy19ycDHwmnkIXxRB8/9QXiiMaVm3o1jX5arNyC2lpO1bI7t810TRwxwWHIBAK72rzmZIRFySCZaUUU0IzL94OvH2H9BbJsUkPkphUhWwZe5eHt1/cMpKDg7tlynBM7UblkIpwT9xiRrhRCtBVXTeNkK4DSO8q8nR8Sd2V+/d3JfvJy7/QCmZXzfHzq80OsdMSWjiuK1nCMLwiG4reL3TaPGFyd6GlYRFvOLi/v4HvtY8kj251NqL+OdfPub7qeQKg23JRUS7jGpE5rlCOaUFMmA5qUt8Q== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v5 2/5] arm/irq: Migrate IRQs during CPU up/down operations Thread-Topic: [PATCH v5 2/5] arm/irq: Migrate IRQs during CPU up/down operations Thread-Index: AQHchGj73A4kTs3O/EWyR3N/eFmlXg== Date: Tue, 13 Jan 2026 08:45:34 +0000 Message-ID: <63892f56f227fae75d78e2ef2ee63887e74c523a.1768293759.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_|GV1PR03MB8709:EE_ x-ms-office365-filtering-correlation-id: a5ad89dc-f3bf-4a1a-0864-08de52801e3e 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?ZSK1d/FmJjW25s6MSw1hJvXmSJ3H71JYUIkeKrIOOMQluibrA04SdcPQkc?= =?iso-8859-1?Q?ESJGsevrp9RgB2ofK57IgBDt87GhcWkM3nCH5dNQiqUcSmIJxf6OH2HcXF?= =?iso-8859-1?Q?vhb2vFCCfeIAVwRfMRbYVG3hbZutyQh/cFHZUVd0h/mM0YAJyVPjZRYxWc?= =?iso-8859-1?Q?ijHHDKbSDWGOzFtNk6hTTFC2EY18XVHFlmODZMbh7s9rZD0LbPsUVc3z5z?= =?iso-8859-1?Q?LdcrpaSsFbrQEF/MGrEfDJPuda7FADw6B+5FiuySHGYeS0q66PNCYcwK/L?= =?iso-8859-1?Q?iikm1k5Fg+qn5GTwmaDSEQ3kZGsGCjkLqAJYGwQs4GI7XX4G8LE5l1VW9o?= =?iso-8859-1?Q?VwZFozJypE60m0YIDQJCCDIJlZySoZq6zCeuGfeaRNvhrxL8zFn4ePOJAm?= =?iso-8859-1?Q?uMIQZtO/s2aQsORxz490F1zaGkzL87hkKVYQpLOGXTs7eeCJ2t3hJs3UeN?= =?iso-8859-1?Q?Ty3zMvAXx4MTlLokOBE7FZ4xd3I+gcxlAn95dRKmPOikdb150++HO12P4i?= =?iso-8859-1?Q?nB9dssXZPSnE5lWLMDfUWk+O3dqkoxvYkVjpOAnn7c9yvvB1F0MUqFd5gA?= =?iso-8859-1?Q?u94i2Nzo+04Aw9eWWShSWpK8D6WW0Y50tDaU5CE60sY78V2F+CSwVybq8P?= =?iso-8859-1?Q?ncINAcGiWfnWAYIQ07qH+pOnBcseUhp/TLdTJTgFgPNIKDazJXRxslwVHN?= =?iso-8859-1?Q?eGlqV+kdiSqbDXAiKyHDTHannEG1Q4ql/uleI0HSL29GuH37BfaUKbprnN?= =?iso-8859-1?Q?Oq93ubvPQiCMenTpnweKnj334qxrIkUWY37hx1kEgtldZvqPeoCkUE56JI?= =?iso-8859-1?Q?zTCS/D/OvakiAEUrBdiBRLN38Bpnh/Mocfjo2bbJS3N6oolcykyPudqkk7?= =?iso-8859-1?Q?JApR6hgTRhKKwRcflce4zg+54jyW2FC60vwqzR7niGbVj7RSy64rTpO9q4?= =?iso-8859-1?Q?7gBw90GPi1tKVXsAR1KPuz/E+hdWMvmQ901i9rmGoPoOL2TYqn7wmpzHu0?= =?iso-8859-1?Q?UaoylHOQHPq2EwDYXO7UsOaT+R/wHwylWFbglvDJ9fUGO3eR7Do29TsWCO?= =?iso-8859-1?Q?NkFeBoq+w7aX9PH4N5WdFqdBixkusyihBbBMeQQSEJfHMZeJGLqIBS/zr9?= =?iso-8859-1?Q?54yHkBP/KjJu8wcmoXwT9Eh0BxFUEVKUS854FPXxZtdVgz/RO5WeFp5r31?= =?iso-8859-1?Q?mEahHV65XHeSUUEKF2Ts+ZzNXL41rXIXSicHgFgKNhjNvTJVy1prUIGxZn?= =?iso-8859-1?Q?9F3w6tG85/2OEv7NxqBzSSCalAR2hOLfv6qfbxkL/ID0DveHjddnyCtKFu?= =?iso-8859-1?Q?cDUEi4aThNigN7byNaoqcrUT0MfsPRsGRZfHypUvRC+nYXGVu5DwLB1AWd?= =?iso-8859-1?Q?lWjMKQpdnpDiK4yKO842vd850dHHJied0tVrNicPZ9dNPO9Kp1SICs6uct?= =?iso-8859-1?Q?FR+7s1MlOHfbjnQYN8goF8X5CJF8tGHNDX7EJ7T1GauqCVpEPvuB+iY8oI?= =?iso-8859-1?Q?z4HCzat6iVXWIl6WT0KMRG+ouciNhgriNbjSoGxvE6QlBjvQ/yK0pctFw0?= =?iso-8859-1?Q?xx9lu6+skcYdZPJaYKQ5QKMnWLFn?= 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?HnPXaj9VqTziWChYbjXvpZ2sfShRsPTJP9QqsPSz1vP9MSuLncuuTv3wiI?= =?iso-8859-1?Q?ioFncBR3ADeX4Ln727ZDtZY378XkPJY1YvWdM17ZdGa5JUFQQf8UJd8JQx?= =?iso-8859-1?Q?61ar2IYnLoDRvkBbzBuuk3rtR0sHyKZtH/idBM8erielUHxL/djU7sinki?= =?iso-8859-1?Q?gowR+1elULXPIKjP1ksO7qMImzwSGsB4GjesXt7Cmde1Ce0JxKKc27dcKG?= =?iso-8859-1?Q?4I80cu3UUnTIEP7+V1RRP58xH0KxCwHdZM9hhMEMT2UWIU2PQDEMatvncq?= =?iso-8859-1?Q?OEGqTzXFRNjiTJdKg30czyKsD3ElpDR1rWOr3pf11p1k1oUsChydoex/m1?= =?iso-8859-1?Q?mdyrBlXU/E3uDtyKrgFtQp0QU/4X6yP9dsTkkodqHakWSJCzECx3crnS45?= =?iso-8859-1?Q?6kUj9oZQMDnJ7KfqXs05uRJt+fkGzJ3c3Tur8yrxj+oZEUhQv/qPp0IUKI?= =?iso-8859-1?Q?qNt5g0sR++cKKsSmotfVggtEguFtIQg4ntdAMXGke6X4NaZhGrkmO1mQr2?= =?iso-8859-1?Q?nOlz4gl/48pFLcTyB6EMZb8lTNL/t778CHTgKRYk2UFeH4l5rZfz7oZjWU?= =?iso-8859-1?Q?TiflnxVzt8Tx82bdHZpXdMo48rzsEWt00IqXvtg9U0AqDa/mFHUNajzsYp?= =?iso-8859-1?Q?lg0mC+KZ7W5yBEdNq8sSte84GKIrAS1nLwtP+ojGdap0I4QS2pOYI99jd1?= =?iso-8859-1?Q?Cjciy8pXxsqfWFsFWGbQr2os1AsPVct7ps9I/DwlxlkeHdLmFuEqRno7EF?= =?iso-8859-1?Q?TX+bbivUgQaxGGVjI/wmTUPBHq7hjf0uN8/rkNflAjQ1bAskRU20M30euK?= =?iso-8859-1?Q?K9LBBEf5K7vTKL6bZD2VyBBLuHcjVy+4gsv4PjL61MbHRxQaKk2GNrOufg?= =?iso-8859-1?Q?2e3YoDNVXqes1iva9IE3wCa38U3/yFwwHXQ75NFvpeRBSFopmi/JqM+qyk?= =?iso-8859-1?Q?7ijb8NAiWHiwnhcjfCNH/8J0XOY1FADZRMVZEgsgdBqmAFlgEgf0AYZL2l?= =?iso-8859-1?Q?+JxYF8jP1J67tEOhBxDhJKpG9HNYhvz35mhkNFForBymf5nhzaHxvBhqAz?= =?iso-8859-1?Q?NUMx+FPy9tlRDWU7e0zs2X6+74Jlievv4aAFrwOej6eR9k9Jae7vRZK3AL?= =?iso-8859-1?Q?R8aFCJ32Lxpwhwon1+fgF+gGeNcQvOoCyvwrGSTFelTO+hSQttOho/R5py?= =?iso-8859-1?Q?/XePxqZwAxo76ZmsiVyiySED7xWEH78YGyORXgtoNoRoIFLqDOEbkmgipW?= =?iso-8859-1?Q?nDdIRnMyRbQekeAnJaM7a7hwZkjafnnVDQtcukP5e29L2AlayGI08wPyB7?= =?iso-8859-1?Q?yFBkospSgtUa1sinH+b7cmNTGbswE6l87fK9LapN7I5OrV/Y8KA3cJoZXd?= =?iso-8859-1?Q?w99u+GO4GAnKWuyV5T1xrjxlQiH77JGmTIQcJ6FHDBo+ymjw6FrqB5qf5S?= =?iso-8859-1?Q?anADlCTKDr/Ru/Xh0W9F0HGpW9vpf5NCCGvHCzspl01aO+WPcMos5rbHRO?= =?iso-8859-1?Q?zTGQbe7Ijq13lFJDQlEdI0+SEb/fmJlmFYLOLEGJNy6trDtTCsOM0a6dn+?= =?iso-8859-1?Q?9bUqs9EZr7VkwQT2wu6PL8ds0e0slTUAlegZu9Rebl6AqXNrk5m00pVKIF?= =?iso-8859-1?Q?4WpAKb4gRBU8J/j7YatIn2ZsMQH5Gf6j3m8/i6IPThzDppAuWEvBkmm6Sm?= =?iso-8859-1?Q?chMTVxoRl9Bz0aDiCnnK0mpoosBzCTptLoRWvUUTakjgZ5Tfayc0E46bJN?= =?iso-8859-1?Q?0prjL7X1M7l31ObfWAas6RK1p5F9MHOxtyX+SpgyhWsOm/FD6B1MSHP9gy?= =?iso-8859-1?Q?jXJzYL6lrdks3G26rYBr1Lun+fhjJ0w=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: a5ad89dc-f3bf-4a1a-0864-08de52801e3e X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2026 08:45:34.8464 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nneXLAvNx/qNE0/i1jaA9Zn3mSzv+iMZoseRK1l8rYnjyF5sI6ojOoURBf8HMhN6HciFkgFBMAsielrU7xdGzg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB8709 Move IRQs from dying CPU to the online ones when a CPU is getting offlined. When onlining, rebalance all IRQs in a round-robin fashion. Guest-bound IRQs are already handled by scheduler in the process of moving vCPUs to active pCPUs, so we only need to handle IRQs used by Xen itself. Signed-off-by: Mykyta Poturai --- v4->v5: * handle CPU onlining as well * more comments * fix crash when ESPI is disabled * don't assume CPU 0 is a boot CPU * use insigned int for irq number * remove assumption that all irqs a bound to CPU 0 by default from the commit message v3->v4: * patch introduced --- xen/arch/arm/include/asm/irq.h | 2 ++ xen/arch/arm/irq.c | 54 ++++++++++++++++++++++++++++++++++ xen/arch/arm/smpboot.c | 6 ++++ 3 files changed, 62 insertions(+) diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.= h index 09788dbfeb..a0250bac85 100644 --- a/xen/arch/arm/include/asm/irq.h +++ b/xen/arch/arm/include/asm/irq.h @@ -126,6 +126,8 @@ bool irq_type_set_by_domain(const struct domain *d); void irq_end_none(struct irq_desc *irq); #define irq_end_none irq_end_none =20 +void rebalance_irqs(unsigned int from, bool up); + #endif /* _ASM_HW_IRQ_H */ /* * Local variables: diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c index 7204bc2b68..a32dc729f8 100644 --- a/xen/arch/arm/irq.c +++ b/xen/arch/arm/irq.c @@ -158,6 +158,58 @@ static int init_local_irq_data(unsigned int cpu) return 0; } =20 +static int cpu_next; + +static void balance_irq(int irq, unsigned int from, bool up) +{ + struct irq_desc *desc =3D irq_to_desc(irq); + unsigned long flags; + + ASSERT(!cpumask_empty(&cpu_online_map)); + + spin_lock_irqsave(&desc->lock, flags); + if ( likely(!desc->action) ) + goto out; + + if ( likely(test_bit(_IRQ_GUEST, &desc->status) || + test_bit(_IRQ_MOVE_PENDING, &desc->status)) ) + goto out; + + /* + * Setting affinity to a mask of multiple CPUs causes the GIC drivers = to + * select one CPU from that mask. If the dying CPU was included in the= IRQ's + * affinity mask, we cannot determine exactly which CPU the interrupt = is + * currently routed to, as GIC drivers lack a concrete get_affinity AP= I. So + * to be safe we must reroute it to a new, definitely online, CPU. In = the + * case of CPU going down, we move only the interrupt that could resid= e on + * it. Otherwise, we rearrange all interrupts in a round-robin fashion= . + */ + if ( !up && !cpumask_test_cpu(from, desc->affinity) ) + goto out; + + cpu_next =3D cpumask_cycle(cpu_next, &cpu_online_map); + irq_set_affinity(desc, cpumask_of(cpu_next)); + +out: + spin_unlock_irqrestore(&desc->lock, flags); +} + +void rebalance_irqs(unsigned int from, bool up) +{ + int irq; + + if ( cpumask_empty(&cpu_online_map) ) + return; + + for ( irq =3D NR_LOCAL_IRQS; irq < NR_IRQS; irq++ ) + balance_irq(irq, from, up); + +#ifdef CONFIG_GICV3_ESPI + for ( irq =3D ESPI_BASE_INTID; irq < ESPI_MAX_INTID; irq++ ) + balance_irq(irq, from, up); +#endif +} + static int cpu_callback(struct notifier_block *nfb, unsigned long action, void *hcpu) { @@ -172,6 +224,8 @@ static int cpu_callback(struct notifier_block *nfb, uns= igned long action, printk(XENLOG_ERR "Unable to allocate local IRQ for CPU%u\n", cpu); break; + case CPU_ONLINE: + rebalance_irqs(cpu, true); } =20 return notifier_from_errno(rc); diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c index 7f3cfa812e..e1b9f94458 100644 --- a/xen/arch/arm/smpboot.c +++ b/xen/arch/arm/smpboot.c @@ -425,6 +425,12 @@ void __cpu_disable(void) =20 smp_mb(); =20 + /* + * Now that the interrupts are cleared and the CPU marked as offline, + * move interrupts out of it + */ + rebalance_irqs(cpu, false); + /* Return to caller; eventually the IPI mechanism will unwind and the= =20 * scheduler will drop to the idle loop, which will call stop_cpu(). *= / } --=20 2.51.2 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 08:45:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 08:45:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201207.1516914 (Exim 4.92) (envelope-from ) id 1vfa25-00045q-II; Tue, 13 Jan 2026 08:45:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201207.1516914; Tue, 13 Jan 2026 08:45: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 1vfa25-00045h-FC; Tue, 13 Jan 2026 08:45:45 +0000 Received: by outflank-mailman (input) for mailman id 1201207; Tue, 13 Jan 2026 08:45: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 1vfa24-0003C7-4B for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 08:45:44 +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 3e547a47-f05c-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 09:45:42 +0100 (CET) Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by GV1PR03MB8709.eurprd03.prod.outlook.com (2603:10a6:150:93::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Tue, 13 Jan 2026 08:45:36 +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.9499.005; Tue, 13 Jan 2026 08:45: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: 3e547a47-f05c-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=u/mxvbTpXmvssP/xamsf6nFj8YFrKjM/YGdvy5MuNF6oqO4nyn6CkjPKBECdwusCdcO3AoL202JXaDSyaB7R17cm7h+v++waIrAiiBZyKKTp+LxJiTz2Zfmp0i4+SSoGk6AJJ8GFpPZH9YwIAI9vOJJ5MWaM1JhkwGvPkAQhWqNqGKSUFqxo7alGdVcX/fftIFWKnzGlW+WyyXg+XG+CcbTwP0XaruJBSK1T151mr+erGtCBqjA/CIcFU6KDuwEkZQ6sWHN/+ZvJyMA7JYAYS9sgjjq2W2R+oOrpN6ZpI8Q/WjCfeh4PKxuSuMXUFfZtsD6bo9Lo8c34tvvFXBjL+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=VvckS9ldcLzbpoTF9qv6Ooqf4GkybykL0RagTPbQCLg=; b=WaWnDoMZYm+QPNgMNHlXzW7+KE8Q/we/zHlsLAgZYjIRRTIUBHMoLFcHOxMscRlsyLPeojFL3omZZeC6aGdB6NiCO1aLOAHEixkt3g613fFFtA05Xspnyy39Vmd1/W55s64gK7iE1rb/ymzi8TPHvjF6PMDPNokE8dymXCBS/a8RSg2cr9ZVVw9AEh3c+0lwIjOPf3UhESkmL7uM2r3ERxZl9+vDaJS9KQgQBYg5GVBH9kMm8UqJod/fpucRQIoN8N3OqIGwX49aZRMdSM0Ut3QJzaIDCHWi9ss/4x588lMSOmZMgENTZPAO024cSfS90Z3olMhew/6VrtQC2vgB5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VvckS9ldcLzbpoTF9qv6Ooqf4GkybykL0RagTPbQCLg=; b=jdwAqGXriNZPP4m+j+oLz8TYsGij2ay7vKex8xHUbceTDNtR5J+lXwC1Hvtg9e1Fo+MZhAaEqhs3w/OLSo1TLT1kqyW7cJIdw1DMP6KoxeACeClmuRw+Gl8UDqar1CrX9qTrwZ8YHfGunuUQ/xBo08V7+bgclsQzHeBCyDRqDto/lYMURtYoDs3byGaStM8l5dliSRfjQHOusrNXvDO+4GEibRZSav94duPl/iTHd2LcTKACxmYx6qh9QiksmsLcnsyeMM0gbVTgutB9d1bdVVymwqcqAOFnyZVHtZT9cz4xOiWhFYzp8LKowq5Cv5t0MK5AtCdP8ekSiTG0aHbdZg== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Timothy Pearson , Alistair Francis , Connor Davis , Oleksii Kurochko , "Daniel P. Smith" Subject: [PATCH v5 3/5] arm/sysctl: Implement cpu hotplug ops Thread-Topic: [PATCH v5 3/5] arm/sysctl: Implement cpu hotplug ops Thread-Index: AQHchGj873UPBMyph02N0fqNmGIWEw== Date: Tue, 13 Jan 2026 08:45:35 +0000 Message-ID: <54a015e0e47ea311471bad7f13fbf21e14389ef3.1768293759.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_|GV1PR03MB8709:EE_ x-ms-office365-filtering-correlation-id: 37387cb5-5ce1-4d97-c16d-08de52801f37 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?0UZfJUcgAzywTLUphRNrJEDfqBwdpK4V4jx8HWtYdXB5ygAYgBPF/mHn6d?= =?iso-8859-1?Q?lnFPDNKXYcAbpPoZRjevHcz+j9mqUask2rVzprZBKrxD0NNdbS72FLcCmu?= =?iso-8859-1?Q?BiCtAN5SsGJMbsxiKFBhy8BXmmAe93UbMPZ52NKQEMu9Q3drVnXUi3wn4l?= =?iso-8859-1?Q?2PPwMW3OEKeRFokDqtHAsaTKRUGuF1T4ToxaasMqEVmoIzQerHo90zfV5i?= =?iso-8859-1?Q?6KTcpOiqYUTJW5+Q8Hy6knbKX28sgoxIEOR8vHcx3q0Hw1XN/Ay4F8uqZn?= =?iso-8859-1?Q?Ja3e3NimFYotMhJAPwIV/bYKAcECXohdGbqvOOcDqDfdngXk5nARLa2y5T?= =?iso-8859-1?Q?P/xaId2Lf5leMeQYr52OXxRnbAhVuL4tWdinIW5yxmS/8JRrGd6J6RlP/m?= =?iso-8859-1?Q?SFT6NZVdpY/Mz5Iz80BD8Mi1eSkqXe7ET429tXbxuE+4peJd74SEFH/g6I?= =?iso-8859-1?Q?4zH0WI7KFeYI4u8aRdjQH4Yumx9UD82TBMjAD57c9SYwTkJpUSyWcKiQ+l?= =?iso-8859-1?Q?dV0Zh5GNY7Yo3Zw4sXSkCbd79XZdO0nq8wVl6bDfKJgpIZuBVsJ5EIoMSk?= =?iso-8859-1?Q?GtMWhsV6g3YuG04QFwDTWiPCG4HLF83oG1NsiqcYiJz0cFP0kJX3daNFUf?= =?iso-8859-1?Q?wyAwp4rAEyqGbkBJO+vhJmT+CtPfQAvdBIDbJVuKHIHhv1Ncm/VeSKwM+8?= =?iso-8859-1?Q?vs9rCz5UFYp7sPXYPiemIGyEysD5DZLg9m+Vl5k7geSfPXQT3t/p6yr9Ev?= =?iso-8859-1?Q?T3B81KDzOXPKAeIY2KobvNxE/rTGWryrrFGpkuw304oS57KX+lLq051wDK?= =?iso-8859-1?Q?wECuQ0qHHQyoraH8yaLtgecunqtqJDHtdKA63f5R50pKe9Bud1qMs0+jSI?= =?iso-8859-1?Q?lKSqTbN5uQ6P+rxdBKjTOn+41NYOn9a8dsp/CKuyZWSMCfTHu3TiMdQqwm?= =?iso-8859-1?Q?TO5dWPzyw+APi/YteR8DgrfcVmSQLosZbtYAYXeYVQdzUVEsT9ze5sIXdA?= =?iso-8859-1?Q?XGHD5f8MbRHcFFMOi4zbsdzqYG5pE4GvA18UJ4ViBKnK5DyDXdrYxLqBzn?= =?iso-8859-1?Q?W8GHaSPTXccmcXMx7pYvqlHQ8Q1XTPx6PfAMZEP4rP70p4vFh/pNlJckx2?= =?iso-8859-1?Q?2BzXfx7OMbi1IENINp+bKIZWnxoFK9zu0KPVBqf59CFhuVWi+WRaM9TNUP?= =?iso-8859-1?Q?Mdb7viZRRdTlYn4nts2XDv2U7eI1Ujw7k4C5bJvgeATfl7OPt9Wsi+BR5+?= =?iso-8859-1?Q?5x5pZkqKDMkNx7ZqWElGNAp08R3ej17LG8QSzgagkNb5H2QeeS2n2/qUfz?= =?iso-8859-1?Q?WCC/nX42QRwQqwqCMYxxJ5vKG/HtMyOJI8i3ao7t9sc4Uw6iUQJ5oy4ZhU?= =?iso-8859-1?Q?yXtKcFuIeYeHiwQa6zFdD+oRbwq9xtlXgcC4Qnx1EX8XzvF8tVIio7OFY5?= =?iso-8859-1?Q?ee50x4e3LMbj0wGh+73B0TBUslMktLklePqflLOirzMnphomrN+pa4hmkM?= =?iso-8859-1?Q?kkQOBFc1umhRiTCtsrGP1DnTMwP9soaVV3U+hgi+nCrBtYTxb+uY3b89Wa?= =?iso-8859-1?Q?6e/7kc5XvpA65pcAfggUvj8/qRup?= 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?+hwyT5IKQGVgEONCUUNB5CFiErum5Zk0pTJElJLX4OegAxeVvyJu698RFl?= =?iso-8859-1?Q?4AB4AmtwqMotnHC3wLbK36TfUCqFSqfHQuZ38h4F6qQgqFcbUaRMtkLx5M?= =?iso-8859-1?Q?nANR0bKmR4IHCW9WnmwlazT6+T8VFxbnmupGH8ibOC8B793vUa7Oh+pRv1?= =?iso-8859-1?Q?lUmiTh+OgWSr5NEVXvR00rLzwX89yXHwC9R1tiozPwsOZP2iNhok7CShUN?= =?iso-8859-1?Q?qwVx+dwo9RHd+bajKqyxgfkCMUczqK9D29ntdpZggRfHeKdL+jqh1TJ1Og?= =?iso-8859-1?Q?Xf8mTHZfAWfdfp07futGIeSWwCJJnIwd5zJBScI2HuMIfxe53IEV9LYf4A?= =?iso-8859-1?Q?TTxh2E+dyqpXxhlVKhEqn5SXZyiH67UXI4/LCYHj5dKaXW+D4T73nNPyXl?= =?iso-8859-1?Q?w3h2ksUf0q6MEGY7bUVEwL71XFpzpFEqakD7JFzWwTIr/S6k9YKG2Wc4qX?= =?iso-8859-1?Q?FKnSte2oGLeHpOlN32zC7h9tm6XpceKLfwibNAhiNP9o38uKivAGEoP3M+?= =?iso-8859-1?Q?rcHlKvwP2cOjsnb7QRgpncxDZVGWn194WnKHHXvTsHHuekSgxGc/fsfjtF?= =?iso-8859-1?Q?MOeZ4LKZVJzvzdHdD/7y0e22S54t1SFj0rVmkkW3Y2+9KSpWtx+XqeHnkI?= =?iso-8859-1?Q?N78hJtRrPsuP9ME6gZlGueLyoxKnGjkBHNIk8qhSJzDQ6+jPPJ48OahiHU?= =?iso-8859-1?Q?IOLBCKjS3tAlSBeKzUp5tNsKYk27eMTRtkzbuY8SibD2IhcYbhXHIf0d8z?= =?iso-8859-1?Q?qAvBvAHk38YLZqa3MsP/kdQ3QLsxfZCRytqc4CqJSuWH+9tWxQU+WwaySd?= =?iso-8859-1?Q?02FuHRtWDqqIlerqSKaLWRGv0ogAZcRJGToSwQLuy0W6ISSC+EuGmj8SfX?= =?iso-8859-1?Q?v1/4W4pGMn6kyn774n1vn2o2xQ7JWUHQDAcO913fJDw9i9BrvkNIo2MUFE?= =?iso-8859-1?Q?zKNruv5A8Bp5eJwipKfeI/tjlKUQ8v/AeQG3c0iXvSpb1YTB+x1bb4nSXM?= =?iso-8859-1?Q?i6OVkdTfDe8dOlFA1ldQoyVsiqmtTtt4AWPF55r9prvV9ZN1NuOD0fo+h2?= =?iso-8859-1?Q?iBE4jSoYGYTysOVwIg3HxsSBCTXPLh9aqhQfkLsKwWfwVeELCQaRMSxHdL?= =?iso-8859-1?Q?m3Yhhp0rFKemfINrtUArPBv4aet9AVwsXvqUD17m2KcVEwd7Ue6oazfUiB?= =?iso-8859-1?Q?g3ABQJt7pqHK+4gnSYnLKdmVCnC47+xjITLkUbNEEGgPmu0c2XYPWKHBkt?= =?iso-8859-1?Q?RbauFWRPeSpIRtQQS6dUOHTlecwdjhaVROFwQqXp5MZDfOhKi3rG+2y1mR?= =?iso-8859-1?Q?Cgth4Q+OvyGe6HKN/JUioKq7P/sSJTC24nYpvclFMSxvgmQtn/v0G0welN?= =?iso-8859-1?Q?vCS+hKN9IBy3Ued0LgnhcfWSPTDKHVUXrN0jY+3dNQPH1X/TJJj5AkXWI0?= =?iso-8859-1?Q?/EC+tZbZSIUBqrUMB6eRFpeLy7ytnzBSkWoz2r0Zxzwo4bK1BcM4+t1Bba?= =?iso-8859-1?Q?KLWGJXHuM65PjD7GO6sgdDffLHZqcIxIiw3uXO0dQdhMC2HTCmgUaMMmww?= =?iso-8859-1?Q?varlCckxSTiVM3U/abPy+7lutytQUcjUCY2dMvUGg0G8xO/n6muJMjixMi?= =?iso-8859-1?Q?Zo1pPltM7V+CioyDzGWrBuKmnBGK0pttMiC6BKZxD5t6rYYAVdbzRQQEI/?= =?iso-8859-1?Q?VpiMQdbuRNQ0fToUS94M+3h+rYxXWAzB2pp4nuzQHcCbKbn47QunFvzauv?= =?iso-8859-1?Q?Mg9Sne7ncIp2Zdx5nBXYrfsDzMTcdohzguJdw3TCweXZLmVaV9N3XDz8sy?= =?iso-8859-1?Q?C6P/QApG+jC5lhkKc+pDjvZuZ1VNdx8=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: 37387cb5-5ce1-4d97-c16d-08de52801f37 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2026 08:45:35.4309 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XN2qRR6qbPali77jrImMAOdCMj8KPfou41+bWhRqKlJSpC96ofElcJBY35+Q0ogbLOj8A/L17d3kFH3ez2YhAQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB8709 Move XEN_SYSCTL_CPU_HOTPLUG_{ONLINE,OFFLINE} handlers to common code to allow for enabling/disabling CPU cores in runtime on Arm64. SMT-disable enforcement check is moved into a separate architecture-specific function. For now this operations only support Arm64. For proper Arm32 support, there needs to be a mechanism to free per-cpu page tables, allocated in init_domheap_mappings. Also, hotplug is not supported if ITS, FFA, or TEE is enabled, as they use non-static IRQ actions. Create a Kconfig option CPU_HOTPLUG that reflects this constraints. On X86 the option is enabled unconditionally. Signed-off-by: Mykyta Poturai --- v4->v5: * move handling to common code * rename config to CPU_HOTPUG * merge with "smp: Move cpu_up/down helpers to common code" v3->v4: * don't reimplement cpu_up/down helpers * add Kconfig option * fixup formatting v2->v3: * no changes v1->v2: * remove SMT ops * remove cpu =3D=3D 0 checks * add XSM hooks * only implement for 64bit Arm --- xen/arch/arm/Kconfig | 1 + xen/arch/arm/smp.c | 9 +++++++ xen/arch/ppc/stubs.c | 4 +++ xen/arch/riscv/stubs.c | 5 ++++ xen/arch/x86/Kconfig | 1 + xen/arch/x86/include/asm/smp.h | 3 --- xen/arch/x86/smp.c | 33 +++---------------------- xen/arch/x86/sysctl.c | 12 +++------ xen/common/Kconfig | 3 +++ xen/common/smp.c | 34 +++++++++++++++++++++++++ xen/common/sysctl.c | 45 ++++++++++++++++++++++++++++++++++ xen/include/xen/smp.h | 4 +++ 12 files changed, 112 insertions(+), 42 deletions(-) diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index cf6af68299..5144e9c8d5 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -7,6 +7,7 @@ config ARM_64 def_bool y depends on !ARM_32 select 64BIT + select CPU_HOTPLUG if !TEE && !FFA && !HAS_ITS select HAS_FAST_MULTIPLY select HAS_VPCI_GUEST_SUPPORT if PCI_PASSTHROUGH =20 diff --git a/xen/arch/arm/smp.c b/xen/arch/arm/smp.c index b372472188..075da9aeb3 100644 --- a/xen/arch/arm/smp.c +++ b/xen/arch/arm/smp.c @@ -44,6 +44,15 @@ void smp_send_call_function_mask(const cpumask_t *mask) } } =20 +/* + * We currently don't support SMT on ARM so we don't need any special logi= c for + * CPU disabling + */ +bool arch_smt_cpu_disable(unsigned int cpu) +{ + return false; +} + /* * Local variables: * mode: C diff --git a/xen/arch/ppc/stubs.c b/xen/arch/ppc/stubs.c index f7f6e7ed97..ed75d06dd9 100644 --- a/xen/arch/ppc/stubs.c +++ b/xen/arch/ppc/stubs.c @@ -101,6 +101,10 @@ void smp_send_call_function_mask(const cpumask_t *mask= ) BUG_ON("unimplemented"); } =20 +bool arch_smt_cpu_disable(unsigned int cpu) +{ + BUG_ON("unimplemented"); +} /* irq.c */ =20 void irq_ack_none(struct irq_desc *desc) diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c index 29bdb65afb..8a9503ec94 100644 --- a/xen/arch/riscv/stubs.c +++ b/xen/arch/riscv/stubs.c @@ -75,6 +75,11 @@ void smp_send_call_function_mask(const cpumask_t *mask) BUG_ON("unimplemented"); } =20 +bool arch_smt_cpu_disable(unsigned int cpu) +{ + BUG_ON("unimplemented"); +} + /* irq.c */ =20 void irq_ack_none(struct irq_desc *desc) diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index c808c989fc..826aa2512d 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -12,6 +12,7 @@ config X86 select ARCH_PAGING_MEMPOOL select ARCH_SUPPORTS_INT128 imply CORE_PARKING + select CPU_HOTPLUG select FUNCTION_ALIGNMENT_16B select GENERIC_BUG_FRAME select HAS_ALTERNATIVE diff --git a/xen/arch/x86/include/asm/smp.h b/xen/arch/x86/include/asm/smp.= h index 3f16e62696..cb3e0fed19 100644 --- a/xen/arch/x86/include/asm/smp.h +++ b/xen/arch/x86/include/asm/smp.h @@ -50,9 +50,6 @@ int cpu_add(uint32_t apic_id, uint32_t acpi_id, uint32_t = pxm); =20 void __stop_this_cpu(void); =20 -long cf_check cpu_up_helper(void *data); -long cf_check cpu_down_helper(void *data); - long cf_check core_parking_helper(void *data); bool core_parking_remove(unsigned int cpu); uint32_t get_cur_idle_nums(void); diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c index 7936294f5f..d64b533cc0 100644 --- a/xen/arch/x86/smp.c +++ b/xen/arch/x86/smp.c @@ -418,35 +418,8 @@ void cf_check call_function_interrupt(void) smp_call_function_interrupt(); } =20 -long cf_check cpu_up_helper(void *data) +bool arch_smt_cpu_disable(unsigned int cpu) { - unsigned int cpu =3D (unsigned long)data; - int ret =3D cpu_up(cpu); - - /* Have one more go on EBUSY. */ - if ( ret =3D=3D -EBUSY ) - ret =3D cpu_up(cpu); - - if ( !ret && !opt_smt && - cpu_data[cpu].compute_unit_id =3D=3D INVALID_CUID && - cpumask_weight(per_cpu(cpu_sibling_mask, cpu)) > 1 ) - { - ret =3D cpu_down_helper(data); - if ( ret ) - printk("Could not re-offline CPU%u (%d)\n", cpu, ret); - else - ret =3D -EPERM; - } - - return ret; -} - -long cf_check cpu_down_helper(void *data) -{ - int cpu =3D (unsigned long)data; - int ret =3D cpu_down(cpu); - /* Have one more go on EBUSY. */ - if ( ret =3D=3D -EBUSY ) - ret =3D cpu_down(cpu); - return ret; + return !opt_smt && cpu_data[cpu].compute_unit_id =3D=3D INVALID_CUID &= & + cpumask_weight(per_cpu(cpu_sibling_mask, cpu)) > 1; } diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c index 1b04947516..87a4b7ac63 100644 --- a/xen/arch/x86/sysctl.c +++ b/xen/arch/x86/sysctl.c @@ -115,7 +115,6 @@ long arch_do_sysctl( =20 case XEN_SYSCTL_cpu_hotplug: { - unsigned int cpu =3D sysctl->u.cpu_hotplug.cpu; unsigned int op =3D sysctl->u.cpu_hotplug.op; bool plug; long (*fn)(void *data); @@ -124,15 +123,10 @@ long arch_do_sysctl( switch ( op ) { case XEN_SYSCTL_CPU_HOTPLUG_ONLINE: - plug =3D true; - fn =3D cpu_up_helper; - hcpu =3D _p(cpu); - break; - case XEN_SYSCTL_CPU_HOTPLUG_OFFLINE: - plug =3D false; - fn =3D cpu_down_helper; - hcpu =3D _p(cpu); + /* Handled by common code */ + ASSERT_UNREACHABLE(); + ret =3D -EOPNOTSUPP; break; =20 case XEN_SYSCTL_CPU_HOTPLUG_SMT_ENABLE: diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 38320b248a..1a28c2dafe 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -176,6 +176,9 @@ config LIBFDT config MEM_ACCESS_ALWAYS_ON bool =20 +config CPU_HOTPLUG + bool + config VM_EVENT def_bool MEM_ACCESS_ALWAYS_ON prompt "Memory Access and VM events" if !MEM_ACCESS_ALWAYS_ON diff --git a/xen/common/smp.c b/xen/common/smp.c index a011f541f1..8ff81197cb 100644 --- a/xen/common/smp.c +++ b/xen/common/smp.c @@ -16,6 +16,7 @@ * GNU General Public License for more details. */ =20 +#include #include #include #include @@ -104,6 +105,39 @@ void smp_call_function_interrupt(void) irq_exit(); } =20 +#ifdef CONFIG_CPU_HOTPLUG +long cf_check cpu_up_helper(void *data) +{ + unsigned int cpu =3D (unsigned long)data; + int ret =3D cpu_up(cpu); + + /* Have one more go on EBUSY. */ + if ( ret =3D=3D -EBUSY ) + ret =3D cpu_up(cpu); + + if ( !ret && arch_smt_cpu_disable(cpu) ) + { + ret =3D cpu_down_helper(data); + if ( ret ) + printk("Could not re-offline CPU%u (%d)\n", cpu, ret); + else + ret =3D -EPERM; + } + + return ret; +} + +long cf_check cpu_down_helper(void *data) +{ + int cpu =3D (unsigned long)data; + int ret =3D cpu_down(cpu); + /* Have one more go on EBUSY. */ + if ( ret =3D=3D -EBUSY ) + ret =3D cpu_down(cpu); + return ret; +} +#endif /* CONFIG_CPU_HOTPLUG */ + /* * Local variables: * mode: C diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c index 5207664252..2acf47723d 100644 --- a/xen/common/sysctl.c +++ b/xen/common/sysctl.c @@ -483,6 +483,51 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_= sysctl) copyback =3D 1; break; =20 +#ifdef CONFIG_CPU_HOTPLUG + case XEN_SYSCTL_cpu_hotplug: + { + unsigned int cpu =3D op->u.cpu_hotplug.cpu; + unsigned int hp_op =3D op->u.cpu_hotplug.op; + bool plug; + long (*fn)(void *data); + void *hcpu; + + switch ( hp_op ) + { + case XEN_SYSCTL_CPU_HOTPLUG_ONLINE: + plug =3D true; + fn =3D cpu_up_helper; + hcpu =3D _p(cpu); + break; + + case XEN_SYSCTL_CPU_HOTPLUG_OFFLINE: + plug =3D false; + fn =3D cpu_down_helper; + hcpu =3D _p(cpu); + break; + + case XEN_SYSCTL_CPU_HOTPLUG_SMT_ENABLE: + case XEN_SYSCTL_CPU_HOTPLUG_SMT_DISABLE: + /* Use arch specific handlers as SMT is very arch-dependent */ + ret =3D arch_do_sysctl(op, u_sysctl); + copyback =3D 0; + goto out; + + default: + ret =3D -EOPNOTSUPP; + break; + } + + if ( !ret ) + ret =3D plug ? xsm_resource_plug_core(XSM_HOOK) + : xsm_resource_unplug_core(XSM_HOOK); + + if ( !ret ) + ret =3D continue_hypercall_on_cpu(0, fn, hcpu); + break; + } +#endif + default: ret =3D arch_do_sysctl(op, u_sysctl); copyback =3D 0; diff --git a/xen/include/xen/smp.h b/xen/include/xen/smp.h index 2ca9ff1bfc..c734033bfb 100644 --- a/xen/include/xen/smp.h +++ b/xen/include/xen/smp.h @@ -76,4 +76,8 @@ extern void *stack_base[NR_CPUS]; void initialize_cpu_data(unsigned int cpu); int setup_cpu_root_pgt(unsigned int cpu); =20 +bool arch_smt_cpu_disable(unsigned int cpu); +long cf_check cpu_up_helper(void *data); +long cf_check cpu_down_helper(void *data); + #endif /* __XEN_SMP_H__ */ --=20 2.51.2 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 08:45:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 08:45:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201203.1516873 (Exim 4.92) (envelope-from ) id 1vfa21-0003CP-H5; Tue, 13 Jan 2026 08:45:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201203.1516873; Tue, 13 Jan 2026 08:45:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfa21-0003CI-EU; Tue, 13 Jan 2026 08:45:41 +0000 Received: by outflank-mailman (input) for mailman id 1201203; Tue, 13 Jan 2026 08:45:40 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfa20-0003C7-2c for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 08:45: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 3b0cfc8d-f05c-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 09:45:37 +0100 (CET) Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by GV1PR03MB8709.eurprd03.prod.outlook.com (2603:10a6:150:93::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Tue, 13 Jan 2026 08:45: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.9499.005; Tue, 13 Jan 2026 08:45: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: 3b0cfc8d-f05c-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Gvtl0Cf1J381/sEb988NfW7LBOwqwdcNQIKmfKwPzujeogFwcHSfjI8AaFPYo9H6mE5eIenTMwQJJwJqki519E4lLaFf5dglIQCqsAYZ4l0s6rVZr6Z38cZU/ujLSjlyiEu4Rt6sT1DizRK03vxCeND1V1Svs/Cy4WiqVZytn5g7f4/KXhJe7mGZKZgOa2sr9LH2xUhfKUTOxK0U3raeMI5/NkVnLimuwc8d9unukwrd1D8LTZiIShN7DDKVjd1fnUZnymjjq/bxpJtMwP4xNA6RUVw9vt9OIIYz5wq7JJtGvK3HP6YgQujGG8SxCtfzp30xsBj/wnE5W5fjlXwcCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sJlY5ZCmZJOWgV9E5StvmeERj3PpIDnEnWSrTZAGkVw=; b=OMLdNiDCVT8NhqfVn/Nkh1gZTvhXbn6X6TXQfJ6hvr7OQ65BkpnTWIUeB0yV4vwAxlbp38yAXCoboNHdoI+2esFaOfyWlQ1JtXtGU2VdpJdfJwqEGCooNXS1vU/jtHdmAOVmNreJVfPEwmtjWyj+BGCCsLjBXLug1XumT52FL1bfTb4u96KDergiO94xivDP0hNGwxBTgWTQ9OwPCsiWEFItICoqlkxoz7ckg7otoZ86biPCUEM1qU871XoA7tEjYmrALVSwbXoK9vMZsipgeifbFqF5z0DKQybH+t+QfRvlYmUHjqNjr0Ai9+2xGTiS3gOEqKWEdDwfdWMYwNAjTA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sJlY5ZCmZJOWgV9E5StvmeERj3PpIDnEnWSrTZAGkVw=; b=CCGSv/JcsOKxBsf2ixKB0g9A2E3EK9945Q5gxnjMYArKOj0kA4tvalGtjTvpta1Lw1ZLeer9dml47+JCeou4/m62xRQbfjYiRZKgXcxlgznl9Egl9ExLx1nexm2Uouy7TUY16cb6nkSGX3r4erA2h+jLwQcxZpTYGRW9wpcmf1ByL7VoBgfwY2pdVaMRx+M0JaBrmemIu0T3t/4AXbJwhco6dypUL9sxPBz5HiPcrbl2gNlbkOZ19FU8zIDQkrrNekH9zN8sjjfyhDvYAm/vDXmyHu+9jbMr7rUPEsmk2V2kRiNfO502CqZYEeaDCz53bOXIy+OL+CNsZeTpTzvdSg== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Timothy Pearson , Alistair Francis , Connor Davis , Oleksii Kurochko , "Daniel P. Smith" , Juergen Gross Subject: [PATCH v5 0/5] Implement CPU hotplug on Arm Thread-Topic: [PATCH v5 0/5] Implement CPU hotplug on Arm Thread-Index: AQHchGj6Bf8iLxj9KkKeGyrpjQwglA== Date: Tue, 13 Jan 2026 08:45:33 +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_|GV1PR03MB8709:EE_ x-ms-office365-filtering-correlation-id: af8e9791-4b8f-47e3-e06c-08de52801d7a 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?yjB50VIXcJfNkIvLJaYd0tCtEwFr2E1dgSP5OEeDtl1ZGpiXdcnALoBkdL?= =?iso-8859-1?Q?r66F2LNkvpnOLep/aTz6zJLhnRnJ+pfUrYiJPD+w1i1cNHRq05cuJbU2JU?= =?iso-8859-1?Q?iF0T79uTtCzeDAi2PmKZCzCV2Sskhzuj/W5tip89/2AVULlCGGTgihs1+8?= =?iso-8859-1?Q?kSemhkKRsk8nkqEq1Z6vVE9f97xytke8BGzc0Ce9ZUrnbWu3l4nxiJIv5J?= =?iso-8859-1?Q?enxYzXrC8K/k2j/VWmJKQnk6vA8mnC+04T3ElXqjCqIsigVtTpqff44ees?= =?iso-8859-1?Q?4wwTRDtnl0xkF3WNbtP1dJBlgC0jWWYhEBViWxDX1P3Hc10CMejzn56thH?= =?iso-8859-1?Q?xslyXZH0OTWAW+1qNxB8ELuv3oXITEWai6VsN9jWjL8iNa8d6LdoW1spLm?= =?iso-8859-1?Q?sEb5wpkJgowjFMBx/re0HBZ11+KVFSHRBelxPo0FjwawCo96K83PPzAHAa?= =?iso-8859-1?Q?JB9Sm2ChFM6SM3gVS+JbCIBuYcYSKE8F9G4as6ylfsFZk3J3aNOZuo4LzQ?= =?iso-8859-1?Q?dgu02mLCad6c5pU7PeHHm6m9RziJ6i9qCQKX4rYQtpMuHUdkL5iJK1/Iwn?= =?iso-8859-1?Q?oyKQ+/p2DrYjBQ/wpIetm9uHHFkbKGwoyvYb5h+TxqbEhcTiPdzefu280A?= =?iso-8859-1?Q?1C9cmQguCskzGoidOShJwuSrhpS6wZxJuapSzZpXEdW6sgKVH69dh84oQF?= =?iso-8859-1?Q?CNY25ISDI3BoslwepYWQZ+tNonSIMsMYnmIuqLssPQtVhGcM+ohLgmjiwF?= =?iso-8859-1?Q?tChEYsZtj1zILFkFj3NGnaspf/b097zBsdJc87JkIVkBtdS7AyVDbLjZ2U?= =?iso-8859-1?Q?YggmqlGU8OF468fEMdvnj+p/thHtoriysIlZ9astf8asml7yYy1urcKSgo?= =?iso-8859-1?Q?osO/kDSiIHfMlN4vHYVAq9xil/k/YyXc6gQD42SBDAfOt6MTSsOrstuh6b?= =?iso-8859-1?Q?vNksJ9PXK8OuaCyZOxb4fGq/SThisNv2zSut1FTXYlY0rBoX6sDIYct7Vj?= =?iso-8859-1?Q?6zkLIZiLfNMKYclSbIahaz57XJ5lVgkSae9cHzBK6nk0zrmZcE2NSSjviM?= =?iso-8859-1?Q?sAhq57VbR3R63y1sAIMuryowenFz9k2LD6R4uawUJzP656ve3ZiOiJ/FPP?= =?iso-8859-1?Q?L2XORH1tBv6+vJp12kzAdFaubOFOFN4NQPw9TmsyolUAUOn+dR5WgyoHr4?= =?iso-8859-1?Q?wN0ZSKLiVHBnFUGrulE+npH5EZInHXCJWUxdI+nn7N28+TIMKBkh8SGn4F?= =?iso-8859-1?Q?I2ZiVj0eBCPAgFKeR4BF8aadnavVXL6OhbLQu+zNToAOR2hC8uJM9bh7OK?= =?iso-8859-1?Q?S/zrDGb1xOyXV+8TS77N8DcWgVr8ooaZIs3cb92GqMkjFHVAXI0go0MuRa?= =?iso-8859-1?Q?uknUWlFW/hKHael2xYvNpl4AhSvjiM11s+2faXbU6yTI7hBJBkVIfxcl8X?= =?iso-8859-1?Q?2CVaqF1fBl0sp0YGBAaWCErV/ZmGJRByx3cZOMvK1l4KCWBixB5Rf5Un8p?= =?iso-8859-1?Q?rnoVpht+rkBmbA+JRAbW+BeiDPlBa5lEWRzzkWPlqupuOD/QfMYoLE4x9S?= =?iso-8859-1?Q?OZKp2U+8qXF/zM9jVgXD/eVoVGC4?= 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?gpC2+MPX/5zDcN6uySrwARPP4jLtabI7zh5ZzBxG389r6y3kLw6/CDN8tB?= =?iso-8859-1?Q?xFgb7OXvZDWe787VCI6HTBiPxNJqs+a26VYLCN9t6QQ0Z6xQ2oQgc8JArp?= =?iso-8859-1?Q?0RRgU7pIEGbr1uHsGSLW4VvTEA9Iu1lzvr/W4vWi5tpC1/eGp0yEDrA10N?= =?iso-8859-1?Q?ycT5XdCXkajP3+21Bz5zNUJo3qqoNbGtZn5WFbiuDIUDgbw9oFw2DuwH3s?= =?iso-8859-1?Q?EmODRljIqzfBIPoYuuc08si09ZLXTlgwSPTPWLmeJ9C4JWw2bDCRiRJUNy?= =?iso-8859-1?Q?U7joM17UKObSDw71Fc23L6kVCrVt799Eglu/rkmH7oOU9sIya0Ya/yV+iq?= =?iso-8859-1?Q?+bqiXCdm48TrNGRXwAOdsB5ZWcpAjeuboB+z6OJbseiLLMw7dnCljnYBrz?= =?iso-8859-1?Q?aCxvd/a9RaAmc1NpR2i5qBFPGZQAs4ICKSZwSfF495J5nQBYBIThUd7uME?= =?iso-8859-1?Q?bfVF4PAoHxnhD1tOOBnCLmccFOxaTLsHVmn8Q9ocgBs6/IC9t+tQlOJee2?= =?iso-8859-1?Q?1iDHZtj04wd2QrPO20Q3FvntiDMOeBomBbLGv4GlEi1TxiY9GOxmMD0H1C?= =?iso-8859-1?Q?IbcW+Y2BctmbjqyFxS0AUBATHKA79gwmdFayzut8t/tyDMEL7fzCmXuSBA?= =?iso-8859-1?Q?GIGIBzmJ8JqNPiwKL1TeYA9LtyHFfnxwbSJWlg9lMyeGlB2LaIjgBtKOVV?= =?iso-8859-1?Q?gLieF7ltjFjtGvKtJjMlLLEm2I8Dy3q2TUZ8iYDeEVtkxHXhbPje+gnyrE?= =?iso-8859-1?Q?PSelc5jI/wIOXAxX8MB1O3ue3dxshT/9VR/IX6c9QYNf8RWPQjBWZnOAQ+?= =?iso-8859-1?Q?wgbsY1CtTHai0YQFN7Z2qp4k31Z//MDg9SHBTyHVpuxvWxYYNmC/hFglFV?= =?iso-8859-1?Q?/sHX1AlwtdaIcpgOYJMuVr1r7nW/m/UhAVwIx/rW/+JL/Ggs0JTJFaML1H?= =?iso-8859-1?Q?4Nkh+xW98btQ1jt4a4QJK4GpiZJOuo3+6LtFm/bjDQUACLiGExS/0uBIZr?= =?iso-8859-1?Q?vmaE1j4eW4q10llwky5gFxXnrg5Nw2kbDaTO3tovyxK0tM2GgSM/m+oXoS?= =?iso-8859-1?Q?p2sDeuuOytu9cNBW0AZbVPpS1y2f2Nj1nk7GcKR2EEupb+hEuSRC9Obeb2?= =?iso-8859-1?Q?TbtmosxZBx6EIo++hdteLjOdcc27QKHjd9DgJWIBdibOvzIDJtXGmHqQw5?= =?iso-8859-1?Q?q87Q026FtM/Oii4JhokCZuvm8uxxMc+BstZs/rlZe0+gomEUXX/cNI4M6h?= =?iso-8859-1?Q?WiHO3mVaUloJ11NKhLORZJIaWBWQqCzigoTSC0PTJaMdEhC2nHDaFiz0rh?= =?iso-8859-1?Q?lIz/CFNa+OMH1uBF2IM+b7wuye85k4QrXPnaEv+ybnhzb+WETCjIhrlubG?= =?iso-8859-1?Q?+bXTeTQQXTGdwi3zz3ddRGft5DubJ4L+wGtFI3rz6WUSvCU4XAQuQsfFYt?= =?iso-8859-1?Q?yRgi1FSK5HopMxNo4x2z8UQsivGUIlcIM7TbMkdwsgOy0/dgu9o4AThsxu?= =?iso-8859-1?Q?LPZEgMidbR0c0XTNoTuKLz6OOftxtsPCGL60Sr6FHwjiptHGEr2wJEn8zG?= =?iso-8859-1?Q?JzaIC+aFyAW0P1UBVfPwIlzb26BZRwtQDPtBAsVBM9AiDy9BI1accqRCk1?= =?iso-8859-1?Q?xDrZscCkhvEd6Xd0pRpQvxEVrYtF6fLdlF7eQkceCVwnIOUBmU1PyPGSXu?= =?iso-8859-1?Q?qCZXmZQJeuByrXwLKb0xixSI8QGbu5veoY0GIrJ7VDnyeERYEJfpT2hAoc?= =?iso-8859-1?Q?1Bj0KvSXs7zlTfLQ4wOJzwypEqngc7H/E0xFkfrNYzf4iLWl4clnaf9V1K?= =?iso-8859-1?Q?JbguJ9dD17ysfP1iSPXwJsnh0y341Ec=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: af8e9791-4b8f-47e3-e06c-08de52801d7a X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2026 08:45:33.6658 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hDBBUFvm9pm9hrTBtOtN/yG4UPBEo/YGKd7QP+2AbqAzSmk7xy/+ZiCEwpV6CusJUMvPBSSXGMRN5KlOItrLZw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB8709 This series implements support for CPU hotplug/unplug on Arm. To achieve th= is, several things need to be done: 1. XEN_SYSCTL_CPU_HOTPLUG_* calls implemented on Arm64. 2. Enabled building of xen-hptool. 3. Migration of irqs from dying CPUs implemented. Tested on QEMU. v4->v5: * drop merged patches * combine "smp: Move cpu_up/down helpers to common code" with=20 "arm/sysctl: Implement cpu hotplug ops" * see individual patches v3->v4: * add irq migration patches * see individual patches v2->v3: * add docs v1->v2: * see individual patches Mykyta Poturai (5): arm/irq: Keep track of irq affinities arm/irq: Migrate IRQs during CPU up/down operations arm/sysctl: Implement cpu hotplug ops tools: Allow building xen-hptool without CONFIG_MIGRATE docs: Document CPU hotplug SUPPORT.md | 1 + docs/misc/cpu-hotplug.txt | 50 +++++++++++++++++++++++++ tools/libs/guest/Makefile.common | 2 +- tools/misc/Makefile | 2 +- xen/arch/arm/Kconfig | 1 + xen/arch/arm/gic-vgic.c | 2 + xen/arch/arm/include/asm/irq.h | 2 + xen/arch/arm/irq.c | 63 +++++++++++++++++++++++++++++++- xen/arch/arm/smp.c | 9 +++++ xen/arch/arm/smpboot.c | 6 +++ xen/arch/arm/vgic.c | 14 ++++++- xen/arch/ppc/stubs.c | 4 ++ xen/arch/riscv/stubs.c | 5 +++ xen/arch/x86/Kconfig | 1 + xen/arch/x86/include/asm/smp.h | 3 -- xen/arch/x86/smp.c | 33 ++--------------- xen/arch/x86/sysctl.c | 12 ++---- xen/common/Kconfig | 3 ++ xen/common/smp.c | 34 +++++++++++++++++ xen/common/sysctl.c | 45 +++++++++++++++++++++++ xen/include/xen/smp.h | 4 ++ 21 files changed, 248 insertions(+), 48 deletions(-) create mode 100644 docs/misc/cpu-hotplug.txt --=20 2.51.2 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 08:45:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 08:45:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201208.1516924 (Exim 4.92) (envelope-from ) id 1vfa27-0004Lc-4x; Tue, 13 Jan 2026 08:45:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201208.1516924; Tue, 13 Jan 2026 08: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 1vfa26-0004LT-W3; Tue, 13 Jan 2026 08:45:46 +0000 Received: by outflank-mailman (input) for mailman id 1201208; Tue, 13 Jan 2026 08:45: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 1vfa25-0003C7-Mi for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 08:45:45 +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 3f70102c-f05c-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 09:45:44 +0100 (CET) Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by GV1PR03MB8709.eurprd03.prod.outlook.com (2603:10a6:150:93::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Tue, 13 Jan 2026 08:45:37 +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.9499.005; Tue, 13 Jan 2026 08:45:37 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3f70102c-f05c-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Zvtdd/z8f0VyyoPuqak0y2J1+7rSt+rl2KAy7m/rLAiebpuJK2maU3VqvqIOioTbv0rwpSIIvkIVZ4pXwfGD3+YJQGz6VKBQeee/AFNw3/me9vNm5C4+nfLtjyqxZsdEyzI7zIq4Yv48nrbqqf5brz4tHausNssjLMhEFZjj9P7YydgzpgJPMZLTgM7aAmCTban8d5NR4sWgXEbBjJEDC6rxiaxpd9mGZBnrwzmz46QwyJaItEdkVtt1ColYe1PB9Im+/wROFt7L8zUfNM43Kfha0yFE0PQfQ3QjERx+5CQy8nelY67JO3VLHdNG9IcSTqwBnbDGOg1S0bCzsHLv3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YB3Z/ya+URTPFlZ29ONQyLs0kh0H7smiC37/7tWuSeA=; b=mSEQ60jcoiv+hvnToDkEnWlRaTV1yeHQAax06lwEioy/OqxTVt52MGrB6OddGQ0oxBHIoOmvHg8xYd10oS8mCiycv4kqfe+ELERGL1G+zEYykMLCNLfHXOpjFyhZpZmOaMMw/LoSqSs72A+57R2+3/uTfjX6JafazsK0QygQz5/g7mlmsFgn6UIbpzlEvpTBzWwMvrubmEEAs+4Lcl0EOynC9cEIb2iLRfEmGbbuCMSAivEOJkep4rlx2DSwf0m2+Pc5JA5dZk6OlMtrbOaQHoFqL03aZGiIXzYXhL46TLxYOGUhIGfaLhAW0N3zhdstxGbai7qLgfIPdXjt9xxdMg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YB3Z/ya+URTPFlZ29ONQyLs0kh0H7smiC37/7tWuSeA=; b=rTqLjwK6cBA3soLAAS9NHMop8NXwARXAP9wPfasomMH54BPM82JLmw+rQldIlolFQjKBCcxdEgdvqUSqDVI//YSG+HJ8+AkRXCL0I95S14Su2o1hSVefn0Kkx3/g8Gpk7Oy5OciQuLOfuKkQcNCTKr/UVs3H8J+9Es4LJwf9ivhMgkNJcf6la3TFEAOK6SpGvSl5YQHxirGkDAb6iRFkpgVu5Tb84YFCatSNdS7rUwWE5eS+nqNPOowpWvUjBX1tlCYcqdP6jeXjxNZq9jd8Nplb97QWdLRV855RodEcGGYo28Iak1jFnHW7fs8VRBQfi44YGpnNrmaIHhy5YlwmZA== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Anthony PERARD , Juergen Gross Subject: [PATCH v5 4/5] tools: Allow building xen-hptool without CONFIG_MIGRATE Thread-Topic: [PATCH v5 4/5] tools: Allow building xen-hptool without CONFIG_MIGRATE Thread-Index: AQHchGj8MU41z39/G0qN5OQ5+p9ktA== Date: Tue, 13 Jan 2026 08:45:35 +0000 Message-ID: <76a8969cd7b8bd956605662edcf2ec3c4af3a178.1768293759.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_|GV1PR03MB8709:EE_ x-ms-office365-filtering-correlation-id: feaa1e88-4b54-4a4c-8ca8-08de52801f82 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?BVFTJ6Y+ZD4n9Tz/jHcelH07BPUGZUaS1b7sdMwx72X7/k1k/W3lgNLxTv?= =?iso-8859-1?Q?PMKSBlOQbClhOa3w/vnigtLvjhDJYt9Eo1MEG3akqlYznrRtiYb/SEvsTa?= =?iso-8859-1?Q?DWLh//n4iZBzB45wkC1/fGWOaG+opQR3LEnmp8Tz0/ERjIZVKs6rbgIrab?= =?iso-8859-1?Q?+ulZncMoo7ZibjtnI2EhQqmHtCcbozDdcbM9+dMk/qLkSOH2wy99b/cSHo?= =?iso-8859-1?Q?OJy/osQg2B7bpbIkLNKLNkjkpH46fsbhzKuj/+wxH6hCQo3MT+Gis/yfSk?= =?iso-8859-1?Q?CHRIXniRusdw39aP0U7X8JBpGQK+F+CsbW5jX7qDR7XPi15VpL1Xh0NTfk?= =?iso-8859-1?Q?VXID2ag1c0IMSE81Dt1Osx2T1S75yPtA2nMkEpPfpyNv745v8+SeA0DQ6M?= =?iso-8859-1?Q?4ccaTHp7hWEQkruRwp8DkpRMdczNydEHGosm/EoPVAbm7kNGFGST+nzRba?= =?iso-8859-1?Q?x9JnZug/f4fKt59ynGixtgegaNgfCFOJN2zEL9Yz2+K9oeAFccofN7sfdU?= =?iso-8859-1?Q?SxnqyfHfKjsSEqvdlPOYETIs9h7Qb8kJ+2OlUD4yKiaSY+nD9kGWY3Utw5?= =?iso-8859-1?Q?U2jpIVRJCU+bxZUy3PiIvIAOW7vSiverTQ1lwLKwmn0fq9yf8+ODvuQ176?= =?iso-8859-1?Q?Ht2s2rCoPVzL2rJmFp53RlkiB7mDjHxPPLXt2et+A8BLNIhCQhU6ND3iMa?= =?iso-8859-1?Q?QGn44MIMLTMO6XM3NsfzodKTDJ0irF6lndSi7LVteDGDH0/JO4Z8JhcVJl?= =?iso-8859-1?Q?Km8mfK+qxnTmo/CjByIbjfH6cEK37F2tVD/HcLkS3byCCGmiveHz7Rol4a?= =?iso-8859-1?Q?XscdA1hf4tI+3UAqpP+izv25NbDS1AyTnCT3jrWeozrvTD+Ro9BoDqVMoR?= =?iso-8859-1?Q?nadqi7HVvpNf3bmWDYILSxoQOMtleQF+sq5uiuu7lhrQzeBA1u8erkB+vW?= =?iso-8859-1?Q?fiBgS9bDagFicwX8KIh4GoXNbHm6KWnZq4FDdWANmqnhEPbDsaN+MGwv6L?= =?iso-8859-1?Q?U4nThInokyRn9ifGW2t3rAS6xPDGCjDuedVeIqfEhECIOHA64/SYizfAwm?= =?iso-8859-1?Q?94y0clkTtoOrKgrxnzrOA2a39U4j+H3o2Xcze6Afk/FXbN8Mv7buDBjAbs?= =?iso-8859-1?Q?Q5hvvC99tKqmLStzaui9udJndwc2d7sn6VGINIZaXaPbKTbVm6BJcnwabN?= =?iso-8859-1?Q?v1b/TOqHysKNjGZmX/MfjhZ77xH6ip8M9fkfbn7iMbRnHyhJSpTvQDp5xA?= =?iso-8859-1?Q?inM+UzILaRy7zoJf7BcN6yy7Oxstw7Sjv1Wml3KEj8Fr6L4mGaw0QKX11B?= =?iso-8859-1?Q?XgeKpJytN118J47OJzQsiZ1ug24KRXh2jTqA5rQqlhO2Sc5gpitcUZzTA1?= =?iso-8859-1?Q?IOzRfju3Pozl/h/EX+UIQrB3w6ftl75KKEAzFLh5cm26kBs+VS33GgP0Rr?= =?iso-8859-1?Q?jzLyT5xnpTnHNkk4PKAJySYgeDa/gjopTSHgvTQWyUclFXdk9qpZvhlGLh?= =?iso-8859-1?Q?9U4/7FAdx3/1vpLCiNzjfu0yFCbbPoxSWnWVCtO11AM1nuJq77FLfmxn+L?= =?iso-8859-1?Q?nv6Z5irKzCDDH5O1IQk3UOu94pyq?= 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?d8wXfNiEOr44A2f/+OwPP6GBR1TrEpvr4ujfMxunkOsrJOB49vs0k0XwCk?= =?iso-8859-1?Q?UXEr9DFSMRNCKx+8dCFAUppxbNT4VTOW5uPnqvbAhhM1NuwwWRg9fj/zyI?= =?iso-8859-1?Q?tt0MSxVvcmMu/7Zdc5YAZeuPgmoqe6JLdU8MAtXh+cn6Cx+koPJeRY4fL3?= =?iso-8859-1?Q?A2esSSJSW78LU5euibmV9MgXYb/qR/KA/m/rbk20bpWQLQwVXMI64AXDax?= =?iso-8859-1?Q?7DQY2XNIz7aN0Hr9M14ZUPT3RkUVMgjObX3Ld+fcyuNZWkowzx5JsDTsY7?= =?iso-8859-1?Q?13UN7KMM6OT+UWj0/f0XOQATTmHK/woylwYOGbhwIlxRwmyRMF6RbMO/Zg?= =?iso-8859-1?Q?neELWqPuafjLR/zEETUOF4/Od0AxX9LGI/dLJHr0dOy9jbd6UnZ/rjqIVs?= =?iso-8859-1?Q?ZrmaTR4SMKbZgdLa2uVb1Gd5ZY1MBksuuv1l4X1fkkBWWqj+HcfURGQOkj?= =?iso-8859-1?Q?um4I/7JCJx9HG66YT+cakoPavW8P4b0I97+GLIjMi8RaUsII48VuQEhRcC?= =?iso-8859-1?Q?Dge7U5XXyCDXLzy41MONJAIgtimvRfvoJgOsaGY4stzsjyl5bvRG4b6PzV?= =?iso-8859-1?Q?NpYvYjUYQD3xcXg0vbc8izIfLigho2OQii1PpXla3ZaNR2O7xKk8ddby2t?= =?iso-8859-1?Q?WuUYuH7Z4DK49r8VN5fgSvSfli8gMOrfQcrynL6UJ6AadXSMgLnFUQ1mln?= =?iso-8859-1?Q?+M53AsDpjgL8dMdA8VVPw77XyfwtOB18wcVY9u98MrRYBKAY48vgFRcd2F?= =?iso-8859-1?Q?E+yq2uzRtIfVjwjdDJpwRIYDMhhFzqlYxQGJ4gWIJ6AVzHIomOtKAnRmYy?= =?iso-8859-1?Q?8OFYHkwjzJq1kY24ogqLYeXNvZsK5p46yyk3MlASHtalV2TbrdxaGdThhd?= =?iso-8859-1?Q?QZRnnjvbZVB5hfZlsDXEpeSWENKGCec+IrtZ+/wUcXPILqaz2aP8ahSDHz?= =?iso-8859-1?Q?egAqx84hyWWHGhguOtYPBzeqxgCwtVGTu/w12tp0tQt1EzwtH8rQ/FqB41?= =?iso-8859-1?Q?hCxsMAqymam3d0CrzL9kN7h1AzDeZR1aLqX9PQg2o+i8bn4KJMR4GHwm43?= =?iso-8859-1?Q?TTe+3C/QRb/gWKR6wyJkykn9aL91i3OzULEK0oi3UVGKjSYOMSA1OSriWs?= =?iso-8859-1?Q?9xHitZDSuo1p/bdWBZtlW3eFzprIie1snG+lMZDzjiAhdw/jVqn9683YlL?= =?iso-8859-1?Q?iBIKRn3EKPN6NNkS4jKyG1/Rx4EzDjRMtTVXf1v1DJoXnJFWnh1joDqhbX?= =?iso-8859-1?Q?Ot8gWR1j4gr/X+hTGybIajLGL4ljmzsXwr5HD0wvl4ekvSq3GXxxpFLM9D?= =?iso-8859-1?Q?4fQe+fey6yMJtB9wI+Pj6/uIjuX4G4vyIN5HK/T8V3MPN96s60OdLcH1Q8?= =?iso-8859-1?Q?Pq612K/GbceeNOY3OPsL+nBBVH1+LEuZZpgANKsxVswWoNWCyG2x2jN5q9?= =?iso-8859-1?Q?ujwZbdRNkK8EJPPUGKpl+fQyX1J09kjUgLeKcAafSJcof7qnNu3Ncl1Xhp?= =?iso-8859-1?Q?AN6zhkHLzHky6gCf5Ck11KCLSDbwYtDFBRP7iRPOx8TLPjUJuyT3yeQN9f?= =?iso-8859-1?Q?iw6yCBCLYOjtK+uHG3oavUw1ovTwxvmFv6gdFOB1pQ0z9vxI+J3jWoQc97?= =?iso-8859-1?Q?9lUUA3SSito09qbQTjrH20vPScIhaq5aMR2T+//vNzcOxkvb+yAkjpWr9l?= =?iso-8859-1?Q?228uxvkoQ0hhBQU2zbwDhOn8v9YYuIb6B4xZBjYeSc/7dDDj4DmHgbvSJq?= =?iso-8859-1?Q?zMEj+9ExM+cufNhW2Fk54VoeisWKJaRLDbyqSSW1HjjbTL+xSVbFVq/ohD?= =?iso-8859-1?Q?sPrMqSyq8lX09lN5HUT01j54gvMc4Cs=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: feaa1e88-4b54-4a4c-8ca8-08de52801f82 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2026 08:45:35.8098 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ho4ueOmxvqpTo0UgfBXw1Rp1QC6qbrAOmtpkh1qS9TlNun+19Jeidh6HCwt7ofl3xm+0Wbv0z/ms2go1MluEGA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB8709 With CPU hotplug sysctls implemented on Arm it becomes useful to have a tool for calling them. According to the commit history it seems that putting hptool under config MIGRATE was a measure to fix IA64 build. As IA64 is no longer supported it can now be brought back. So build it unconditionally. Signed-off-by: Mykyta Poturai --- v4->v5: * make hptool always build v3->v4: * no changes v2->v3: * no changes v1->v2: * switch to configure from legacy config --- tools/libs/guest/Makefile.common | 2 +- tools/misc/Makefile | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/libs/guest/Makefile.common b/tools/libs/guest/Makefile.c= ommon index a026a2f662..db268da68e 100644 --- a/tools/libs/guest/Makefile.common +++ b/tools/libs/guest/Makefile.common @@ -7,6 +7,7 @@ OBJS-y +=3D xg_private.o OBJS-y +=3D xg_domain.o OBJS-y +=3D xg_suspend.o OBJS-y +=3D xg_resume.o +OBJS-y +=3D xg_offline_page.o ifeq ($(CONFIG_MIGRATE),y) OBJS-y +=3D xg_sr_common.o OBJS-$(CONFIG_X86) +=3D xg_sr_common_x86.o @@ -17,7 +18,6 @@ OBJS-$(CONFIG_X86) +=3D xg_sr_save_x86_pv.o OBJS-$(CONFIG_X86) +=3D xg_sr_save_x86_hvm.o OBJS-y +=3D xg_sr_restore.o OBJS-y +=3D xg_sr_save.o -OBJS-y +=3D xg_offline_page.o else OBJS-y +=3D xg_nomigrate.o endif diff --git a/tools/misc/Makefile b/tools/misc/Makefile index c26e544e83..6cd8785cf1 100644 --- a/tools/misc/Makefile +++ b/tools/misc/Makefile @@ -16,7 +16,6 @@ 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_X86) +=3D xen-hvmcrash INSTALL_SBIN-$(CONFIG_X86) +=3D xen-hvmctx INSTALL_SBIN-$(CONFIG_X86) +=3D xen-lowmemd @@ -34,6 +33,7 @@ INSTALL_SBIN +=3D xenwatchdogd INSTALL_SBIN +=3D xen-access INSTALL_SBIN +=3D xen-livepatch INSTALL_SBIN +=3D xen-diag +INSTALL_SBIN +=3D xen-hptool INSTALL_SBIN +=3D $(INSTALL_SBIN-y) =20 # Everything to be installed --=20 2.51.2 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 08:47:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 08:47:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201254.1516934 (Exim 4.92) (envelope-from ) id 1vfa3l-0006Vf-H2; Tue, 13 Jan 2026 08:47:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201254.1516934; Tue, 13 Jan 2026 08:47:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfa3l-0006VW-Ce; Tue, 13 Jan 2026 08:47:29 +0000 Received: by outflank-mailman (input) for mailman id 1201254; Tue, 13 Jan 2026 08:47: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 1vfa2b-0003C7-NN for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 08:46:17 +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 51d26b8d-f05c-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 09:46:15 +0100 (CET) Received: from DM6PR18CA0021.namprd18.prod.outlook.com (2603:10b6:5:15b::34) by PH8PR12MB7027.namprd12.prod.outlook.com (2603:10b6:510:1be::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 08:46:08 +0000 Received: from DS3PEPF0000C37C.namprd04.prod.outlook.com (2603:10b6:5:15b:cafe::38) by DM6PR18CA0021.outlook.office365.com (2603:10b6:5:15b::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Tue, 13 Jan 2026 08:46:09 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by DS3PEPF0000C37C.mail.protection.outlook.com (10.167.23.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Tue, 13 Jan 2026 08:46:08 +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; Tue, 13 Jan 2026 02:46:08 -0600 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 13 Jan 2026 02:46:07 -0600 Received: from [10.71.194.215] (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, 13 Jan 2026 02:46:05 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 51d26b8d-f05c-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=C7rPML9cHNdAOEpITlNSARhe+FYyhRKAvGUWhcYjfzJxjVmI0QR01Z6Pa5t3MCTG5DxXo9T3He9X7kBZFLdutROXsH5/eKdGHc1qoCnX3Ux8HPdKqjDpRgNRzuxh19CuPU+SCNFbBiVRuqtBBhtp8ioUPzJnNdPvBZfjJw1DMOP9Ri9FiWXIWWaMVdgRQ0uRzC8dmhZ/udqTvLxl3CwzOI2jlF37r9FtO8BhvO7BDHBGDTp91VNY4Tu6pI4MmAggchIqsYhU+EcajHPCeXuQrQJlc9oyZgOIysrroFkjmJeDLgU6rLpbx1TtKLkD8ruWTmj1otkMqLvPPOsqjF1E+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4s8yzkIgbumej70kjP3ByTRzIi6fvqlQRmrtmuUF1AE=; b=jy6apFIVKnw5HBZdKao8tRuHrksyT/bOJ5NOh407a82K6As4MOPZeusijdWvFEHkTMRlHtwaifydRdVO3ePLli9JJ3tLPn5xKikgm1r9mP7twOGO86YGlQcc6SbvRgQwYUPMoZAIOg173ctlhP5J63Da09OnkPMGQYOvw2Bo2HxILi9newOTth5YNpqRwfbvYe+JiiNyuyZdsORyJ1O8EEw0fdKbfK3kdXc189ghdRNbDBeNcdw94qKBk/RfwfDYrvTUPpA8cOiCNhYPiTt1Ueh3+xIouClXmyqtwCFjvcTRJ9N68J8j7hrnzWqurs4A+Vz2jMFPEvAdlt3E80HLVw== 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=4s8yzkIgbumej70kjP3ByTRzIi6fvqlQRmrtmuUF1AE=; b=x9w9FsPLC9tXfPERAHPZc9Pk/tgyljmIN+rYjGiaRVBCRufoek5mmONnlLvfTX4yyTwrs86sAhz2KLQRyVHZHjJg5/FYjHzEtL5gWqyGxbccZ5BYBu5yh8+BqnorZF5koo8mnBg3+A4qVRL65lVgStLxcDcxt7LnMIdPHf7n7IY= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <05e9d883-f130-4a69-b2f2-deda9379c591@amd.com> Date: Tue, 13 Jan 2026 09:46:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [DISCUSS] xen/arm: CLIDR Ctype scan order in get_llc_way_size() To: Mykola Kvach , Xen-devel CC: , , "Andrew Cooper" , Anthony PERARD , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk , Carlo Nonato References: 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: DS3PEPF0000C37C:EE_|PH8PR12MB7027:EE_ X-MS-Office365-Filtering-Correlation-Id: c39d95d5-35b4-477b-36ec-08de5280323b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|36860700013|1800799024|82310400026; X-Microsoft-Antispam-Message-Info: =?utf-8?B?SlVNNkNVTTJKSC9qMHFVS3lXTkRCRm9aa0xLSlBMNkh1RXIvRVEyb1pZWXMv?= =?utf-8?B?ZmhqTWpCS2ZZNlpKTnBiYk1abXNCMndxbFd6T1FJSVZRejlBb2hPbEVBcG5l?= =?utf-8?B?Ry94ZHBIdEc1VmFmSGx3T25FeG1WZzFFeTFoeG4vQUhORkxDTk4zWG9GVDBN?= =?utf-8?B?QzdJU1VydC9OZWxiaGFUcGx2Z0dYQXhnRnVTSFlqekxtZ2tKTERCc3JCZnpG?= =?utf-8?B?di9EbkhDQjlhZDZvUVFZUkUraklDZUppSExVZ05GcWNaTmVmd3FRTUxDa1Uw?= =?utf-8?B?MUFKTmZTckFYc1RGR0hjaTdJYUZlNlAvZEZ0c3F6bER2NU5Fcnp0OWppVWUr?= =?utf-8?B?c0E0dFBiNVErcmJpSzVFU09CcURpeXJPQUVMQlJXRlV1Vk9RNW9wZ3dXbHNx?= =?utf-8?B?RUxONWtkd2ZCZElvRmNNNDB4ZG1pbFU4MCt5eE5sbXFQOXFWd1RYMk1abDZu?= =?utf-8?B?dVlPTmVIK050TlRGV0lRUEdLazZ5cG1vUVNkT0pkMEpoem5KOVpveE50dy9o?= =?utf-8?B?UFBONWROdVZiYy9JVUIvUHE5OVNMQkpHN3JFY1FPZGlFVXpvdisyU3paN0pN?= =?utf-8?B?Y2NRN3Y1bWh3eHpxZlF5aEdzRTFaOFRsa0k0cTlOMS9UREFSWWFyaEhNRFc2?= =?utf-8?B?SDhxMWZWdmlieHBiZGVCaWMzWDRCZnhHbHZha0M2Q1JZaUlpOVhYS0xLOTh4?= =?utf-8?B?YUtOMk0ya1pXaHFkM2hnaVlsd3pxSTAwYU8wZzl6Y3dZOXpTU2p5ZEhiUzZZ?= =?utf-8?B?Tm81OUJzcVQ0QnJ1VCt0RFNuNGs4bkI5WEZwc2pVcHZzejJhVjhGTXQ2QlQr?= =?utf-8?B?aHZ3MitXRGJBWEcxYmVqbHNLSUlndGlQVkVjc0dFMklNR1lyOU1aSlFrazBv?= =?utf-8?B?NlRKajRHdExZQVl2L3JiMGZMaDNzZ0RkTGcxZnJWVGlvQTNQNU1JWkFRY2Ex?= =?utf-8?B?RXp2bENtN0tBWXFQY2JoT2FackF2ZHBpSXFoMEZ2bkdGZ1pGVnhBWFhtTGxn?= =?utf-8?B?Y0dvemk0RTRvd0lSTk1GOEpRQmtidVI2Zkk5d3IzWERuNHpuRXJ2ajNVbGp5?= =?utf-8?B?Y0R5NFZlRy9JZHNieCtrRkEvT1RFOVBpOTZUL0hRdnlnMEJTUXIzM0lOYnJl?= =?utf-8?B?Kzg5dUI3Z0ZvVXVLRi9zeDZQWnpBKzFRSkNma1BwTkpUZk11MXhBR0xudmFV?= =?utf-8?B?cWsrTytvUm1Pa0ZGZ1gzM0JFNzhkcFNGZFVoK0xGYmtDTDZxQUorRitadk9L?= =?utf-8?B?OU9NNU5qOVM5dzVMakNEeHVERFBCOU9NYi9vY1RGZlg3M1ZvMjd4dEpEVHMy?= =?utf-8?B?QWJweFZsdXk4Q0Nsck90aTFaRm5QRmZsSHF3aWhTN3dIOEpVUzY5Z0d2dWpU?= =?utf-8?B?M3RWM1RNbWxyVXpsZmw3WHdqYVhhcTAyMGgzUWlZVTRUVmtCaTNxSGp1dVRB?= =?utf-8?B?SGVnazBRSGFOOUt3THV2bTYycnlZOXppUWF3OG1tWHgveDBsUEJEWE93RTU4?= =?utf-8?B?RVViRlVHc0twOUQyd1VZMFJzZUIvWjBaZkVIZk1LOTcrTHNnSWdkTVNIYmNl?= =?utf-8?B?bFhCNXVXSHpQUjFhemV4WE9JUUNTUGZjbndKSFQvZ01pUVVMbVFIT05UTVZC?= =?utf-8?B?cjZFZUk1K0VvaW5YNGZydlM5TzVjaFlXRTRNQ1dzVGFwemJFQUVxRFBNb28y?= =?utf-8?B?a3M1QW04MiszK21OL1dYOHdXRXBzdFI3RGNqTkZzMTI2TVJMM2NMYVltYWpY?= =?utf-8?B?V0ZkZitsQzZHUXlVQ1ZPeHJwQzUrbzlmYUFSRzZIbFovZ0hxWFRMOGkzNDFh?= =?utf-8?B?N3p3dDFVTmpucTVZQWZhMUUrM1J3Unh2d1BTYmRZelFuUHhKUXU3N3VnQWto?= =?utf-8?B?eC9TT2p4cEhZR0F4WmdBcjBGNDVFbEFEdkVBNStwWDFOUCtzbjVCR1BTL05z?= =?utf-8?B?MGJOM0V4VmgyWGFrWU1zSHpYcGhrelJ0bkN3ak42a1kzUWdqZ0ZQV2ZTbFp6?= =?utf-8?B?YlRMeFZKaEhTaWxJOVIzZWFVR1AxMndONWxSOWwvL1FnVVBpNFVpWkRtb3pX?= =?utf-8?B?V0tnN1IzaEUrcitBcklCQ1p6dHQvbU9WaXI4WXJESDBybWY2MVhCaExhWHZH?= =?utf-8?Q?GBhM=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(7416014)(36860700013)(1800799024)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 08:46:08.4369 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c39d95d5-35b4-477b-36ec-08de5280323b X-MS-Exchange-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: DS3PEPF0000C37C.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7027 On 13/01/2026 08:00, Mykola Kvach wrote: > Hi all, > > While investigating current Xen code, I noticed that get_llc_way_size() > scans CLIDR_EL1 Cache Type (CtypeN) fields in reverse order to locate > a unified cache level. > > According to the Arm ARM (DDI 0487J.a, D19.2.27): > > If software reads the Cache Type fields from Ctype1 upwards, once it has > seen a value of 000, no caches that can be managed using the architected > cache maintenance instructions that operate by set/way exist at > further-out levels of the hierarchy. So, for example, if Ctype3 is the > first Cache Type field with a value of 000, the values of Ctype4 to > Ctype7 must be ignored. > > This reads to me as an architectural constraint on software: fields above > the first 0b000 are not architecturally meaningful for decisions (regardless > of what bit patterns might appear there in a given implementation). With our > current reverse scan, we could (at least in theory) mis-detect a "unified > cache" at a level whose Ctype field is required to be ignored. > > Discussion points: > 1. Is the reverse scan intentional? In particular, do we rely on the > assumption that Ctype fields above the first 0b000 are effectively > RES0 in practice, or that they may legitimately describe caches which > exist but are not manageable via the architected set/way maintenance > instructions? It is intentional in the sense that it makes the implementation easier but it looks like we did not pay too much attention to the statement you provided. > 2. Would it be more correct to scan from Ctype1 upwards and stop at the > first 0b000, tracking the outermost unified cache seen prior to that > point? Maybe it would. At the same time I don't necessarily view this as a hard requirement (the sentence starts from "IF the software reads from upwards" which does not mean that reading downwards should not be done). I'm ok if you want to change the implementation. > > If there is agreement, I can send a small fix patch with "Fixes:" adjusting > the scan order/termination accordingly. > > Thanks, > Mykola ~Michal From xen-devel-bounces@lists.xenproject.org Tue Jan 13 08:58:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 08:58:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201278.1516944 (Exim 4.92) (envelope-from ) id 1vfaEC-0008WQ-E2; Tue, 13 Jan 2026 08:58:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201278.1516944; Tue, 13 Jan 2026 08:58:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfaEC-0008WJ-A9; Tue, 13 Jan 2026 08:58:16 +0000 Received: by outflank-mailman (input) for mailman id 1201278; Tue, 13 Jan 2026 08:58: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 1vfaEA-0008Uv-WD for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 08:58:15 +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 f8c9dbe6-f05d-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 09:58:04 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-47d6a1f08bbso29845115e9.2 for ; Tue, 13 Jan 2026 00:58:04 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5df9afsm45503714f8f.24.2026.01.13.00.58.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 00:58:03 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f8c9dbe6-f05d-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768294684; x=1768899484; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=fGlKdero6n3cHpvHk8T+zZ5OcAUXGfpJ3+5ydXJc6VU=; b=bKCGN/ExNSh89pOFCbWkMTWY9tH04QDjNrA6xIUQ78D3MlfDLNP/TzK4bdyUrklmlU 4up0M6VEzdtlUTqL9w2SZxYbvX9wT6viiDmNqY+EdUwWvvInhnn48OSb+TGctEjPvUo3 1lQG5UrPv880WdYdbHK7sve9N7PO376XxdnF+w+S9QzRomFuRx00A5LmDpW2iUedQKWZ p5ZA5Whj5LWs/vF8SDAnu1+8MoWCoLQyyXNgYnRVnYhwULHVMbkK7SKTJgZVTCjeDZHe Gr+5Ool7dR8V0MR1fKy0Jg6zeGqAZ6H+SI8A+LTNQ1JfbwTA82zYENDeY4PUFX6WmsEY xdzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768294684; x=1768899484; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=fGlKdero6n3cHpvHk8T+zZ5OcAUXGfpJ3+5ydXJc6VU=; b=KdGMK68RaIk0+5qrg9rmHmhFq/vQpOfLqYzHIj8CN18XNwmMWpyWMXzN/TIvWKrCpe lJ6x9OOnffIp5+r6lQYl7ZJ88gsS0e9XcER76IUrcP1vkuchsAyl7mDFc5y4vUkuy3z5 rKU3Cnw4bWCpzvlttEsQPVzYxrc4kD8fIiA7QZWrVnWQ9gYS7FEIlCaBYx24gWuy7SnD 9OjtRfcUJtQ8GMfnEdz+pm4y/yGovZL8orWfR8va69pnnc0CG6bVUZnlJXjw1jvLfTjs +FTcrXuKBeHV3srCEFH1878uP+QD8LA1ZyFt6uKBrlMq9M6syzuUgcoeH61c7BY70XQl yfmQ== X-Forwarded-Encrypted: i=1; AJvYcCXhD8KNTgW8GCKONJ/h7buP7IGWV6PzKsI/63bh8NKRsvU5UMOqTRMq/VQ7i+NZ4JNt1QOE4UFRHko=@lists.xenproject.org X-Gm-Message-State: AOJu0YyDkKGg+jXQjl3/hxpZDqaUOll2kS/KMU+xHcz1EF5crK+/XwGz tRq8i2IrYu/TFzpgOUjOX4avuKKgDjyCsGbC6C2qpsdg+BQUME1gjGx1mmMNqNKVwg== X-Gm-Gg: AY/fxX4NEdOEUzNjYeH0jFtBccCfPV5tEdZz4KStHE5TC+jGemlucU7SPSZBMUxHBff UpBb6Fl7KkyVLptmO9RgoxyBHJmiNqYN7GJ0JXI5Sifkvo5wAbclPAC3SY7fNIzQx7f3zZIxczx PDjsD8CQca6ywOgHU0GwzrmSIlQl7WfhAAayTp0DysBHtI49DwzeLcd2uoJgbfpv0L1uU8tF8xz am8P68MSwBeCTjhBg9xewAOukZf4JK1uVZ9UjISuuXdE0Y2+3IP2HwP6AKl+Is7Ak6rSifucj20 qag520+R9c4634uYGtxulmrW/ppQndRCakrmmkLyJ9h75o9TrTvXtheTFGfvnRzgHDtHWndHKh0 CReD03o4VgDBGAlNxDN2Fx+v31kiFlhXQ9Xe1R+k651byYchTpN1pgbODpMmrqGSJ+DHhYWn0u7 ghDgp5YocvoyOTlhwNwg3cFIrWgJ3OOBGiVBVoWgdQ1Gbc/AKOLO6lAqOPT9CKSVieIXNHZFzzu Go= X-Google-Smtp-Source: AGHT+IGnWEC7LPDCeLZOt8Q04Q60618nj45/7lP2Z/u5gYGioafnPcRfuvcI2t2vLHYEyaryqTCWsg== X-Received: by 2002:a05:600c:620c:b0:46e:33b2:c8da with SMTP id 5b1f17b1804b1-47d84b3be47mr225661325e9.32.1768294684053; Tue, 13 Jan 2026 00:58:04 -0800 (PST) Message-ID: <5b00ab27-5ad8-46c0-92fa-a1fa4b65bd99@suse.com> Date: Tue, 13 Jan 2026 09:58:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] x86/ucode: Add Kconfig option to remove microcode loading To: Andrew Cooper Cc: Doug Goldstein , Stefano Stabellini , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260112150259.74535-1-alejandro.garciavallejo@amd.com> <20260112150259.74535-3-alejandro.garciavallejo@amd.com> <96f4f3fe-46c4-4854-af55-d5adea07c847@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: <96f4f3fe-46c4-4854-af55-d5adea07c847@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12.01.2026 18:15, Andrew Cooper wrote: > On 12/01/2026 3:02 pm, Alejandro Vallejo wrote: >> --- a/xen/arch/x86/Kconfig >> +++ b/xen/arch/x86/Kconfig >> @@ -331,8 +331,20 @@ config REQUIRE_NX >> was unavailable. However, if enabled, Xen will no longer boot on >> any CPU which is lacking NX support. >> >> -config UCODE_SCAN_DEFAULT >> +config MICROCODE_LOADING >> + bool "Microcode loading" >> + default y >> + help >> + Support updating the microcode revision of available CPUs with a newer >> + vendor-provided microcode blob. Microcode updates address some classes of >> + silicon defects. It's a very common delivery mechanism for fixes or >> + workarounds for speculative execution vulnerabilities. >> + >> + If unsure, say Y. > > Please don't re-iterate the default.  It's a waste. Well, first of all we should be consistent: Either we always have such a brief sentence in the help texts of boolean options, or we never have. Who knows - cleaning this up thoughout the tree may even address some anomalies (where the sentence and the default setting disagree). Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 13 09:23:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 09:23:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201298.1516954 (Exim 4.92) (envelope-from ) id 1vfacV-0004Np-CB; Tue, 13 Jan 2026 09:23:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201298.1516954; Tue, 13 Jan 2026 09:23:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfacV-0004Ni-9K; Tue, 13 Jan 2026 09:23:23 +0000 Received: by outflank-mailman (input) for mailman id 1201298; Tue, 13 Jan 2026 09:23: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 1vfacU-0004Nc-Mr for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 09:23:22 +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 80ce9336-f061-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 10:23:21 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-47d5e021a53so53856025e9.3 for ; Tue, 13 Jan 2026 01:23:21 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432dd78f5a8sm23323552f8f.27.2026.01.13.01.23.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 01:23:20 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 80ce9336-f061-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768296201; x=1768901001; 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=VtR/nz8wgGMX8gGZMJlyO/c1Tg8Ef9r9iiBmR57GcMo=; b=ZndAboNPTA5jg7dlN9bz0wBgNqRR3EydUvogmdhex1wQotQEEOAI2PdenJ0JmuIH0F EtBqczpnVLE5Ifj7IGD93OAZm68zBUfjt5JZH5FWEjX3eHrfoHGBmSfxiJnB7iaHGPYm leV1QpHmLtm7hZtfSY/IDORADTHKk1afoGkCVpKYLeZDuMYyHJcuMk+aJi0L/OBO/2lx LWbVoIiyE8gW9iZfxOResVQ5/FQ+pxEn+u5RLapsRJrFyaQPJlHkFUQ+JMmoGrGvKnY6 jLbxrhQJl7JsFc3wsTyQUiy0NPbB8fpaBSjqtF8BaQSAmDZR1bSmelUHJ5E4IsHYG4v0 uM4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768296201; x=1768901001; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=VtR/nz8wgGMX8gGZMJlyO/c1Tg8Ef9r9iiBmR57GcMo=; b=sA8T9D3cK9+c7BBTC5JDQ9LmuoBX/wliFSW9nH8U7H8OGcnkS5eHPFl+PgvFAwnga3 /TRykjnBntiwQel8wIRhqWNjBUFG2Ow//2rFwLdn7WfzbAkBlvhhN+F+/8qR6wjkuk2l Qgof3FHoaNSaZNPSQRjnF14QbtdkgAOJOB6VXdZP8S7932vEHiCz0iMaSmac9XISpeNA yxzF7TC05fs0maZ9gdW/AeRBf7v8yQT2nzqHHMVYUg3z/ZYFNdDmrsQy94Kn6OAd7GDw n07XvrLU/yYJziLYc8m4whIIxN0sOIPiPfJfDo6EJ6wGip67niMf7UnxSAymFqNmDP0E 2Ltg== X-Gm-Message-State: AOJu0YzIoix353+I1tP7cJlOQUscq7JPMLXkkfB1ZeJBKMlFKw+sbFy4 kfXuv0iUNbI3xso/cRI0jjdrnUISz61o6x8sY7BfJRzERtbEglgEeWYSRYPXCIb+fznpVx/0Cfi 0Qms= X-Gm-Gg: AY/fxX4fgOlIJibmVi3fnnIIO55/NfxyqfwkS3nZilPxkTzIVmbj7Nt243+vLdcivnM f/l6X/odmJ/TtW/FsJD46+DXiqnVxWiSJvh77hPsuBX462rhm0DKOf3XXCcT+LxpDxGUf30iMd4 jiOhG5bjgvDiH4LY5tSN1iMsn1bekgzekeEQjJ14ljtVqJaQg4IDYNsMnQGYVFAZG1G7UFbDjRb Nky2pD69l4nNGqyVE8F1RHfHlShhV3mmH6VeQ6mGtl7w6STyHQpnVs669xnWoRbI0HBkzGshU2V zEtST67v9BVnFdolRvyRFRBUpGzaZ1czG+xcFABy1Io8VMyiQXF0ZczteVWshiWCyhNtywXI9GD cDjAZJ9fSI2XRF5GjPIeQYgIA6+s0/rJyfsJJPL8gxl4zup0tzOcdcNlYvig/PeBe2XUteCvjro zd6kMyxdxgIrWUXRu9PEcIwXZLNECbITHZDAMlfiTctzUsv0RS89PXyreAMvjb8VxAIoso2bqwG ss= X-Google-Smtp-Source: AGHT+IGHmrU3Z3EtWomp4yvEcbiAt6VhTJS+oJSj3DAMbEuxrhw/F4tPwRKiZt1gh/q1dDg1fe17vA== X-Received: by 2002:a05:600c:1991:b0:477:55c9:c3ea with SMTP id 5b1f17b1804b1-47d84b40aa4mr267981935e9.35.1768296200788; Tue, 13 Jan 2026 01:23:20 -0800 (PST) Message-ID: <54667383-d1ff-467f-9dfc-95d23aa600cc@suse.com> Date: Tue, 13 Jan 2026 10:23:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH] x86/platform: adjust CONFIG_VIDEO usage Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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 Switch to using IS_ENABLED() in both places, thus in particular making sure XENPF_get_dom0_console handling doesn't take the "default" path: The behavior better wouldn't differ between VIDEO=y and there not being VGA vs VIDEO=n. For this to work, fill_console_start_info() needs to be unconditionally declared; extend that to vga_console_info as well. Signed-off-by: Jan Beulich --- I'm not quite certain whether to have Fixes: 11b4ff64841e ("x86/platform: protect XENPF_get_dom0_console if CONFIG_VIDEO not set") here. Opinions? --- a/xen/arch/x86/platform_hypercall.c +++ b/xen/arch/x86/platform_hypercall.c @@ -415,10 +415,9 @@ ret_t do_platform_op( } case XEN_FW_VBEDDC_INFO: ret = -ESRCH; -#ifdef CONFIG_VIDEO - if ( op->u.firmware_info.index != 0 ) - break; - if ( *(u32 *)bootsym(boot_edid_info) == 0x13131313 ) + if ( !IS_ENABLED(CONFIG_VIDEO) || + op->u.firmware_info.index != 0 || + *(uint32_t *)bootsym(boot_edid_info) == 0x13131313 ) break; op->u.firmware_info.u.vbeddc_info.capabilities = @@ -434,7 +433,6 @@ ret_t do_platform_op( copy_to_compat(op->u.firmware_info.u.vbeddc_info.edid, bootsym(boot_edid_info), 128) ) ret = -EFAULT; -#endif break; case XEN_FW_EFI_INFO: ret = efi_get_info(op->u.firmware_info.index, @@ -905,20 +903,19 @@ ret_t do_platform_op( break; } -#ifdef CONFIG_VIDEO case XENPF_get_dom0_console: BUILD_BUG_ON(sizeof(op->u.dom0_console) > sizeof(op->u.pad)); - ret = sizeof(op->u.dom0_console); - if ( !fill_console_start_info(&op->u.dom0_console) ) - { - ret = -ENODEV; + + ret = -ENODEV; + if ( !IS_ENABLED(CONFIG_VIDEO) || + !fill_console_start_info(&op->u.dom0_console) ) break; - } + + ret = sizeof(op->u.dom0_console); if ( copy_field_to_guest(u_xenpf_op, op, u.dom0_console) ) ret = -EFAULT; break; -#endif default: ret = -ENOSYS; --- a/xen/include/xen/vga.h +++ b/xen/include/xen/vga.h @@ -11,9 +11,10 @@ #include -#ifdef CONFIG_VGA extern struct xen_vga_console_info vga_console_info; int fill_console_start_info(struct dom0_vga_console_info *ci); + +#ifdef CONFIG_VGA void vesa_init(void); void vesa_early_init(void); void vesa_endboot(bool keep); From xen-devel-bounces@lists.xenproject.org Tue Jan 13 09:33:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 09:33:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201308.1516964 (Exim 4.92) (envelope-from ) id 1vfall-00064W-7R; Tue, 13 Jan 2026 09:32:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201308.1516964; Tue, 13 Jan 2026 09: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 1vfall-00064P-4V; Tue, 13 Jan 2026 09:32:57 +0000 Received: by outflank-mailman (input) for mailman id 1201308; Tue, 13 Jan 2026 09:32: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 1vfalk-00064J-7D for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 09:32:56 +0000 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [2a00:1450:4864:20::342]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d61dc032-f062-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 10:32:54 +0100 (CET) Received: by mail-wm1-x342.google.com with SMTP id 5b1f17b1804b1-47775fb6c56so69873765e9.1 for ; Tue, 13 Jan 2026 01:32:54 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ed9b3aa99sm12825095e9.0.2026.01.13.01.32.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 01:32:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d61dc032-f062-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768296773; x=1768901573; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Xe98Dtl2+pp2XcPfTk3G1Xuv4ZAGxJ7JxTbli3Z1kWY=; b=XjkFKego4KFEEnlb4pf6rSk/RtmpA+Kt1OhrDH7KRHiLHXkoBEY9kzXOE1aMzj2acQ CenThXUGpUepa+tTfjopuSYiSLgnebWJLIph7LCMbnu1jymfIaOoR0r9YZUf90c7yIbJ l0HCVGQ9X9/r+Fam1m94h1bYnBNpbcXKv1V8eWkQbAid8b3cxdwD9sBPANzY6ClNrf++ hUWAsGFtLNEXnuBzeVAKEgXIwcwPPKaA9aM4UpyAtbm/OsJRWcxrL397Z28gg+zVzRwo jZ9YCG3Gi7A1XcMjoYod9PRd/XWm0YpHF8oVcr6Kc+ngs9Hn7OCA59bJpW+h7raXd5iJ Q6wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768296773; x=1768901573; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Xe98Dtl2+pp2XcPfTk3G1Xuv4ZAGxJ7JxTbli3Z1kWY=; b=ms0exi50+sn59jUrCPTdYpzTZstGSQtJuETOjNiUKFKSIF33lrpt12CF7XpvuSZUU0 l4sR9cYcYMNbu5L6fvslEI9MxH3f9rtVN9Ldbi6J9PmJZhMNRU5qDl+3eJFZoYpjvxhX 0GLvBaSJvvGv/mXwq2ybLDOMDe9grdz7P2JyzNCDGEMKL+ssC70JndtiPX1vUJNpWFIK PxWlQCPRHF2S6xlbmmxwFyYiGJBIcItCzVn1i+QtBG7AEhVTxIssS2xLA8kX1VGiXhg+ 27SCH3QijiPyvDff5W7uR/cNfBOZfWxTSv5jV1GiB+klfN1I5QJk4LHkofp6xoEndcg+ L98A== X-Forwarded-Encrypted: i=1; AJvYcCUyh91eKaVRw0JhxNyerFNNF/9qR5INf0iSMP7EfpJm1L4f34HYMmu9utia0txsjEveeNrtHe9Tfus=@lists.xenproject.org X-Gm-Message-State: AOJu0YyS3h/ypy0ul/kKXJXJ6FnN8CfjmBjr4SHJh6Ll9Ssz8t0/kZo0 Ir7J+wzozvP3pbUCFA5X5QswiU6LNHEX+zxU+BraNYIOVL03DUgZW659FQ5Y0yAMMQ== X-Gm-Gg: AY/fxX4caqIyq+oLrFPgC6lb8b32qmm3Uc7+U/doZCbdjtvbJ3MlnAsCmY+82vc5y/N kx9no3gBS1wIKkM+d/Oud9FrsJrrDCi8zWNQALwIxwcrNMh+lzrnwTTA+Uh1Rsf9uajbzf9o3LD tgPPA4snM87zabuw05MrE1U+iStAVfVJSscM2mSexW+x12EP7mnFHR0U1gr5tlsnyhl750laOjq I4nkEOVuzHzGNqzlMsUGnYCyL2I7SVqCG7ImJjV9mYyaWyf3QNC41OIYhiuhMZjos2ua8KkgPbL vZgm4RDCXgxJWWchvizU9kwECDIQCT/9upbjvJZ/C4xIUWCf+d0sPDLSWNGRtytjDyBNSAmZKME lGMnMZUicc1eDPmxGF1Nx/gmFiL9jwL2qkpNmEVCMM24OSwaj14Ce3LVvp7GjN3N93dQl+qcNQL fByeQ44HX7DtwBTj4SA8L2W1vW64lrBIQ4il8roIB6cu6eJPn/r+Xhqq4U7dCUJM4dzlQTYu31j 7U= X-Google-Smtp-Source: AGHT+IEjDCtwbElFR8X6BWvyOthu6ddo5vHBMTT4lsxrhBQJ1eLrbuzbfL40NOge6CKMzxpvw2AgNA== X-Received: by 2002:a05:600c:3114:b0:477:76c2:49c9 with SMTP id 5b1f17b1804b1-47d84b18954mr206879575e9.2.1768296773329; Tue, 13 Jan 2026 01:32:53 -0800 (PST) Message-ID: <89ee7840-b8a4-4354-8a94-ebe92824bf44@suse.com> Date: Tue, 13 Jan 2026 10:32:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 4/5] tools: Allow building xen-hptool without CONFIG_MIGRATE To: Mykyta Poturai Cc: Anthony PERARD , Juergen Gross , "xen-devel@lists.xenproject.org" References: <76a8969cd7b8bd956605662edcf2ec3c4af3a178.1768293759.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: <76a8969cd7b8bd956605662edcf2ec3c4af3a178.1768293759.git.mykyta_poturai@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 13.01.2026 09:45, Mykyta Poturai wrote: > --- a/tools/misc/Makefile > +++ b/tools/misc/Makefile > @@ -16,7 +16,6 @@ INSTALL_BIN += xencov_split > INSTALL_BIN += $(INSTALL_BIN-y) > > # Everything to be installed in regular sbin/ > -INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool > INSTALL_SBIN-$(CONFIG_X86) += xen-hvmcrash > INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx > INSTALL_SBIN-$(CONFIG_X86) += xen-lowmemd > @@ -34,6 +33,7 @@ INSTALL_SBIN += xenwatchdogd > INSTALL_SBIN += xen-access > INSTALL_SBIN += xen-livepatch > INSTALL_SBIN += xen-diag > +INSTALL_SBIN += xen-hptool > INSTALL_SBIN += $(INSTALL_SBIN-y) As per [1] I think the line should be edited in place. Jan [1] https://lists.xen.org/archives/html/xen-devel/2026-01/msg00285.html From xen-devel-bounces@lists.xenproject.org Tue Jan 13 09:56:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 09:56:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201324.1516978 (Exim 4.92) (envelope-from ) id 1vfb8d-0000nm-22; Tue, 13 Jan 2026 09:56:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201324.1516978; Tue, 13 Jan 2026 09: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 1vfb8c-0000nf-Vh; Tue, 13 Jan 2026 09:56:34 +0000 Received: by outflank-mailman (input) for mailman id 1201324; Tue, 13 Jan 2026 09:56:33 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfb8b-0000nZ-Ap for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 09:56:33 +0000 Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [2a00:1450:4864:20::42d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 228a69c1-f066-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 10:56:30 +0100 (CET) Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-430f2ee2f00so4212251f8f.3 for ; Tue, 13 Jan 2026 01:56:30 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0e1adbsm43770271f8f.17.2026.01.13.01.56.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 01:56:29 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 228a69c1-f066-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768298190; x=1768902990; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=uV6nfva8JBAZ5PG8F0nf4vcX0Xle/KSnoVk9aMOcdBs=; b=E9p+rGS6Dcnjy4jbKSa6QKNZy7IZMXPl4eFP8bCB17wkLxz/GFAhI++FVDHqiB2RE6 JEYMnL4VEubUk9aP1fPuea/oJggyJS7cnNHBRsMf8/4NMld4Q58b/ExjfZTSZnjdmUhh LDkIjn40mGrHh8oSzTnxP73FBCD/7mT61mc2LHAxocFdgTYOjy1e2+utACuolbnEzUVA SCa8xbTxy9kMtziVFy+uhwcebn8e3Y4OtF0tCKabGInS+cSZRVBMucuNNkVfiz2zdBjt 1yKYLK2gpm2JvDfC2n0+Y0i1eD3346AzFV3o48QCKLletDWkOblCEplhsxaXxcL5lVia nMUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768298190; x=1768902990; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uV6nfva8JBAZ5PG8F0nf4vcX0Xle/KSnoVk9aMOcdBs=; b=Btr4iw8RhUa33e0/d9DL/K3Emx/T+Y/zab84L+8j2b09q6C6so/43LMXKqpR9sZM5R 9dTgH/wa/WGUS5gh5mxauy/6z3z7N7sAN2F0Jbj8zUvpT5uYW+V1SVbPGvXumQWqRnE5 O7+UYConfceuz9jgc5Z20CBPDBRB/jeLP9Yc+sPEKYX9KS5+a9OLzD4Tcrk+iIUe7G6V crQ+DQHblMltXzs21QSbgjaLsG8qH0sxwwY7z3FvS+2N+DiTFs5elEXzagvt7cW5P+Cb JAftDfZPib1RkvmQyGPkLsDkX+CWsLkPd8iYE0Mv/2Tnne7oiWJEt5f+MK/jXrSg5oxz 9EMw== X-Forwarded-Encrypted: i=1; AJvYcCXHsHL/bdzAJExJ0Cz9Y8WTqW30qvc8QDnxtQKwUd9EP1+gUvg1ciOHXgmdcfpcNHpQd3SKPp4b6vw=@lists.xenproject.org X-Gm-Message-State: AOJu0YzcnkdoVFar1oV/1e4mO/dVOye2gKN2idgfuVu871DI2I9rj20v EMJsjKPAAfATisysx46PW5fO2/FDOLC9v6n1Wjw752Yv6b91T3j8A8T5UIMP7etoSA== X-Gm-Gg: AY/fxX6rckoWkanAKEAAEwyBquqHxA9j7E9j6EUllKz1hi81q5lIB20FJGZW81p4d5A r+7/xxoEyNs77iuXBpGcRmASDFht7Eee1ikGFkRxIqSJLxx+o0S4F9+u9VdzPvzlAqHHL2+otrv qAxPVGnipp3/Akti2QYuNcpD/jt3nLLkQozloN8mTVFiQ7jJmKbjbgj1Y63bVSd7Epc3CfvZgTZ bQry4nSYkjrqPhrXTH3zF6fxau1r/baitUmesMUoDw1rwlJSL4RrLY9gsjorCFaQdQZhS5dj53Z 9l2SrkaizbW+UWQLgkUiSLMC0Gz6wHWegoNDUJcRni1w3Tn7Al3cDpOKDKj/Jad0NGWSk2nQ7QL mrIi5MoZmlugibFBFjud+RPQ5k+4cVY/gUEkgsoLF6wHOpZiHd97c776VmGkPGPDhqSmQTf1k6O OoTwzLIXJcwuQaAD0jOt4RoiCsQwJ0efnU60j6n2KyXdyp2VG/J8L3NTCZ9XGalyqCIfkX0aKtd ko= X-Google-Smtp-Source: AGHT+IGh+2aY6/6oggXGNFiDMYVlrWtHoR9yuEh//1hJB9Ds8atlJjYtdn4Ez/WDsriILji5VlbB/g== X-Received: by 2002:a05:6000:420a:b0:431:266:d132 with SMTP id ffacd0b85a97d-432c37a505bmr28735653f8f.46.1768298189927; Tue, 13 Jan 2026 01:56:29 -0800 (PST) Message-ID: <3376e95d-8da5-4bc8-893f-4f9c84404a32@suse.com> Date: Tue, 13 Jan 2026 10:56:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/console: handle multiple domains using console_io hypercalls To: Stefano Stabellini Cc: grygorii_strashko@epam.com, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Victor Lira , andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 13.01.2026 02:30, Stefano Stabellini wrote: > Allow multiple dom0less domains to use the console_io hypercalls to > print to the console. Handle them in a similar way to vpl011: only the > domain which has focus can read from the console. All domains can write > to the console but the ones without focus have a prefix. In this case > the prefix is applied by using guest_printk instead of printk or > console_puts which is what the original code was already doing. > > Signed-off-by: Stefano Stabellini > --- > Changes in v2: > - fix code style > - pbuf_idx/idx after ada53067083e > - don't add extra \0 > - clear input on console switch > --- > xen/drivers/char/console.c | 25 ++++++++++++++++++++++++- > 1 file changed, 24 insertions(+), 1 deletion(-) > > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c > index 2bdb4d5fb4..6c7a6592c5 100644 > --- a/xen/drivers/char/console.c > +++ b/xen/drivers/char/console.c > @@ -576,6 +576,8 @@ static void console_switch_input(void) > rcu_unlock_domain(d); > > console_rx = next_rx; > + /* don't let the next dom read the previous dom's unread data */ Nit: Comment style. > + serial_rx_cons = serial_rx_prod; > printk("*** Serial input to DOM%u", domid); Imo the flushing of input needs to come after the printk(), as it's only then that the user gets confirmation of the change. As to flushing (rather than storing) leftover input: That's strictly an improvement over v1, but imo unhelpful. I may not be willing to ack this (still need to think about it some more), but at the very least this somewhat odd behavior needs calling out (and perhaps also justifying) in the description. Further, did you think through the interaction with a racing CONSOLEIO_read? Right now that's the only place where serial_rx_cons is updated, and hence there was no issue with there being multiple reads of the variable (perhaps unless a domain issued racing CONSOLEIO_read). That changes now. I can't convince myself (yet) that's entirely safe, and hence if it is that also wants discussing in the description. > @@ -730,6 +732,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, > unsigned int flags = opt_console_to_ring > ? CONSOLE_ALL : CONSOLE_DEFAULT; > struct domain *cd = current->domain; > + struct domain *input; > > while ( count > 0 ) > { > @@ -742,18 +745,28 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, > if ( copy_from_guest(kbuf, buffer, kcount) ) > return -EFAULT; > > - if ( is_hardware_domain(cd) ) > + input = console_get_domain(); > + if ( input && cd == input ) > { > + struct domain_console *cons = cd->console; > + > + if ( cons->idx ) > + { > + console_send(cons->buf, cons->idx, flags); > + cons->idx = 0; > + } I probably should have said so on v1 already: What is this about? There's no comment and nothing in the description that I could associate with this code. And then - is this safe without holding cons->lock? > @@ -815,6 +829,13 @@ long do_console_io( > if ( count > INT_MAX ) > break; > > + d = console_get_domain(); > + if ( d != current->domain ) > + { > + console_put_domain(d); > + return 0; > + } As of here d == current domain. Why are you holding onto ... > rc = 0; > while ( (serial_rx_cons != serial_rx_prod) && (rc < count) ) > { > @@ -826,12 +847,14 @@ long do_console_io( > len = count - rc; > if ( copy_to_guest_offset(buffer, rc, &serial_rx_ring[idx], len) ) > { > + console_put_domain(d); > rc = -EFAULT; > break; > } > rc += len; > serial_rx_cons += len; > } > + console_put_domain(d); > break; ... the domain for this long (requiring multiple console_put_domain() invocations)? The current domain can't go away under your feet. Hence imo a single (early) call will do. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 13 09:58:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 09:58:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201334.1516990 (Exim 4.92) (envelope-from ) id 1vfbAh-0001PT-FG; Tue, 13 Jan 2026 09:58:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201334.1516990; Tue, 13 Jan 2026 09:58:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfbAh-0001PM-AU; Tue, 13 Jan 2026 09:58:43 +0000 Received: by outflank-mailman (input) for mailman id 1201334; Tue, 13 Jan 2026 09: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 1vfbAg-0001PC-7F for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 09:58:42 +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 6fa0823a-f066-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 10:58:40 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-b872b588774so229214666b.1 for ; Tue, 13 Jan 2026 01:58:40 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a4cfe60sm2167668366b.45.2026.01.13.01.58.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 01:58:38 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6fa0823a-f066-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768298319; x=1768903119; 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=ZeHND3fA0DNMCgGWGUXtopoOxfkaIwFxkfRbh5fbUfM=; b=AfTW8xswj+u0XEbHBa7rxXQY47B0tPaLE6nCgsC/Th695ryE1UPgN2HJxn1jgzG1+N YzQLkUSLbCzuIlIfgoExvT/fD0sADMqdxkSFi+01yEovyeHJoRACBkHuS/e0L8xmL7w3 jjLCNmN4GtL3GQ4EhZFc6f5MafpHgsydCTt1mw8OybSq2Gw+n2aFG8RUiRu68FGY5aso rvttXsYksXIodvYEeOKZPa0qMGcS3R9k8FkFK4gV6dV3DNKJl2GO4+q/Hhfh8EAa6YQ9 QDaHRCYNU+zsJ0j31+Ek7Denyd54n75915Cb4R2eP59hPrG0e9sX771CV7I6tra7uZ4Y qKNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768298319; x=1768903119; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZeHND3fA0DNMCgGWGUXtopoOxfkaIwFxkfRbh5fbUfM=; b=dL6WrA4YvFRd5MUs1zqHbjbkO7CsXAZMRiMMFlOgWp7sKFou075u6/97Vs5MUCzI7b W8Qsno+VrtC7c1Vxjs0SwtvDviNgKu1HsvOw3jUWL2nevhMDtW+e46Oe5QCZlczVxCXs oyButySvLnwqQwH4lBYwc/LbbONRBUO63tpNWpG4jC/6flGLY7dz6CQQ5d8EldirOUlb LYJHsr/bjsdAZHTXhvj9f5qTnBwyQP/vFs3FxyJiL6Ag7STNwzYva+DrZYqqm7bvX25w dxee2Mh5DAIQf9w65dDD0ppaE9zhJFOfGGm21TOvuuPCeQB9yya6hY1njWRKXnLKa+ua uP3w== X-Forwarded-Encrypted: i=1; AJvYcCVDXFFra4gHDjNl3XWTvLAWj/On5sBh1OypmTKDu2usnGRkIOyO8QYrG6amYBdtkEWwAlaJvJA1SGs=@lists.xenproject.org X-Gm-Message-State: AOJu0YxH4TF5I6L5JBtgHq2/2EYO02+Y7M4sfdo3Woo+UuirDO3JQP1b DuRethnlLkMADjFlN7zbAROxYF13ShFr/FX1W997dMSDn2kHfLlyOtGw X-Gm-Gg: AY/fxX586mmcmExxRUc2qoqbwGYYjM4YPe60SQ7oumJI6Zqzqw1LhOAwRCQFM+A9QLu fcl2qtGjJQVKCQFaa6BxpNDV5qkC2AgxjZiXIp8jS6yEzhMChhOjDhDfQ1d34WeyRZG9rSbJuge ElkfraEai7Ww3s5V2FKYe9Iy9H8Nwlr4GRcPbK3JwBD9w1rX7tOly6Nf7S/+HAUzNpm2zNPdEPc USsm0XrV74SixLucaNuMYrQ1d90mP4MaS8akjggLVdNxqFXXXNOZo5lr2s5zTRcXtlfZKUxMoU/ gts0Sycb+AVwfLJR3OeySCgFXTdzWqPfKoOpJy6wFo3yUL9X1WvdjKRXeK86ZoLsj0KnjEhPxQs mLFmnRm9eTKBDeB5D7jX+IB9n2dF29yDkZ2bE+V5G4W10GlgUkQqs2CAYTRXWlJdwRdSu9OtGq1 RTWGtndIm+sPXRs/vBIOaxA7RrVOTtf0vFHey3Np9y5tqNt0bCc5mgUJEW2Ze5uq8= X-Google-Smtp-Source: AGHT+IHaf5y6DbZ2r5fmz1rL9xYPQEyHKGJjCUvGaN6FJuCIAYRnViw+IumY+u/3ERZEcaATmXtqzQ== X-Received: by 2002:a17:907:9603:b0:b80:a31:eb08 with SMTP id a640c23a62f3a-b84450205e1mr2070475866b.55.1768298319060; Tue, 13 Jan 2026 01:58:39 -0800 (PST) Message-ID: <92cfc028-cabd-4686-b6b9-7cc047a909c9@gmail.com> Date: Tue, 13 Jan 2026 10:58:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 05/15] xen/riscv: implement stub for smp_send_event_check_mask() 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: <837c863f5995cc4371e82b481211b053656ec7e7.1766595589.git.oleksii.kurochko@gmail.com> <319e6162-7a5b-4030-ae9f-a86a48e73605@suse.com> <94c0cd09-7aaa-4ae1-913e-57d883916682@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/12/26 6:05 PM, Jan Beulich wrote: > On 12.01.2026 17:53, Oleksii Kurochko wrote: >> On 1/7/26 4:47 PM, Jan Beulich wrote: >>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>> @@ -13,3 +14,10 @@ >>>> struct pcpu_info pcpu_info[NR_CPUS] = { [0 ... NR_CPUS - 1] = { >>>> .processor_id = NR_CPUS, >>>> }}; >>>> + >>>> +void smp_send_event_check_mask(const cpumask_t *mask) >>>> +{ >>>> +#if CONFIG_NR_CPUS > 1 >>>> +# error "smp_send_event_check_mask() unimplemented" >>>> +#endif >>>> +} >>> CONFIG_NR_CPUS is 64 by default for 64-bit arch-es, from all I can tell, also >>> for RISC-V. And there's no "override" in riscv64_defconfig. How is the above >>> going to work in CI? Then again I must be overlooking something, as the config >>> used in CI has CONFIG_NR_CPUS=1. Just that I can't tell why that is. >> It is 1 because of the defintion of NR_CPUS in KConfig: >> config NR_CPUS >> int "Maximum number of CPUs" >> range 1 1 if ARM && MPU >> range 1 16383 >> .... ( all other range props are condtional and there is no RISC-V in dependency) >> so for RISC-V "range 1 16383" used and CONFIG_NR_CPUS is set to the minimal of this range, >> so it is 1. > I fear I don't follow: Why would the lowest value be picked, rather than the > specified default (which would be 64 for RV64)? That's what I thought the > default values are there (among other purposes). But there is no default for RISC-V for config NR_CPUS: config NR_CPUS int "Maximum number of CPUs" range 1 1 if ARM && MPU range 1 16383 default "256" if X86 default "1" if ARM && MPU default "8" if ARM && RCAR3 default "4" if ARM && QEMU default "4" if ARM && MPSOC default "128" if ARM help ... So a value from range [1, 16383] is chosen and based on the code of sym_validate_range(): ... val = strtoll(sym->curr.val, NULL, base); val2 = sym_get_range_val(prop->expr->left.sym, base); if (val >= val2) { val2 = sym_get_range_val(prop->expr->right.sym, base); if (val <= val2) return; } if (sym->type == S_INT) sprintf(str, "%lld", val2); else sprintf(str, "0x%llx", val2); sym->curr.val = xstrdup(str); First initialization of val2 it is the left value of the range [1, 16383],so it is 1 and val is 0 (I assume so that it is by initialization 0), thereby val2 = 1 will be used as a value for NR_CPUS. I also experimented by trying to update it to the range|2 16383|, and|CONFIG_NR_CPUS| became 2. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Jan 13 10:21:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 10:21:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201350.1516999 (Exim 4.92) (envelope-from ) id 1vfbWj-0005NJ-9b; Tue, 13 Jan 2026 10:21:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201350.1516999; Tue, 13 Jan 2026 10:21:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfbWj-0005NC-5n; Tue, 13 Jan 2026 10:21:29 +0000 Received: by outflank-mailman (input) for mailman id 1201350; Tue, 13 Jan 2026 10:21: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 1vfbWi-0005N6-Kl for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 10:21:28 +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 9db8cdb9-f069-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 11:21:27 +0100 (CET) Received: from BLAPR05CA0011.namprd05.prod.outlook.com (2603:10b6:208:36e::26) by IA4PR12MB9809.namprd12.prod.outlook.com (2603:10b6:208:54f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Tue, 13 Jan 2026 10:21:23 +0000 Received: from BL02EPF00021F6F.namprd02.prod.outlook.com (2603:10b6:208:36e:cafe::ad) by BLAPR05CA0011.outlook.office365.com (2603:10b6:208:36e::26) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.5 via Frontend Transport; Tue, 13 Jan 2026 10:21:18 +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.9520.1 via Frontend Transport; Tue, 13 Jan 2026 10:21:22 +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, 13 Jan 2026 04:21:22 -0600 Received: from [10.71.194.215] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Tue, 13 Jan 2026 02:21:21 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9db8cdb9-f069-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=GWzEQWDi6gBlyXQr1RaF2qJht3tVH/9GnELItBCqk52HTz2884A0GY5jRqGT6M/6btXxmhYLKAPaoiUSjxo7fs5bZvmDQ6pfK7qNP9s/LT7hGtR+FkCu+oVDB8mc1Aa8HD2yHdAEp7bNnr8+Y8YEnPSE28uXIyRKC8GtRWK407dLp/IAFzcwLJLvPetyN7uA+zQYwr+IvgKXd7iqY+1ga9mejZ7hgsYQeDptYp08FGV4lTe5DCcHT4cakmfPQwPWZAn/0mfjqBgG4mEOd16X6ptHF0XwgWITrsks5/y6TOsz8NBqe+IiwqgB1SDFRFTBdmX6eBsEVlkwGmShMVNbGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=RD9rrVHE8SNXkEpOMG/orsgKMfHvEtAl6NzTZVZHihg=; b=ytbe5K2fbIEO78yKcVAWT0b4//XkTfZFDiBBMvov0u1zUDTIMqKU/5Ah6VwSiNw/xTl52ga23D3wE+KAyDk9tEkoyFO0OCxa5O9yb+sWbW9rdd9MXPZCIo1Z3F2gImFpIA5YLjq+hzQNuURZjNk7gI1VbVccOcEN1/kfWIy0zEYvxrAIZKTGzlX13Y8WBe8+W9/fAP1rr3ONcaHxLkaUokLccCnLtVRcYi/0aN0ntqlVxiEWS+S9u2U5t7Upr5ppSOXmyh/YXZ7mwyka1LkwTi7TjJznGDmctfDv8UlwIwVMXDZ1nNr5P6Kh2gBsPZjed49jl3NtdqkCqDOykcSM9A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RD9rrVHE8SNXkEpOMG/orsgKMfHvEtAl6NzTZVZHihg=; b=2ZkJ7qtpD8u4Nk2SFI+kxHDbom3l8zyHHxEhgaOSrk12AtfT+46SY3cmc4i9vADvZF4zCQsMgHjzHA7Nj9QRmUZDUWEDvdjsFs8Nuibdy8Q0Spbeb31tfU8Xk5Y7OCHrqn8WcFN/7RmXVV7fvq+fwNQuSSZQdDrlFbF93BPFx+o= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: Tue, 13 Jan 2026 11:21:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/6] arm/mpu: Implement vmap functions for MPU To: Harry Ramsey , CC: , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk References: <20260105113503.2674777-1-harry.ramsey@arm.com> <20260105113503.2674777-3-harry.ramsey@arm.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20260105113503.2674777-3-harry.ramsey@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF00021F6F:EE_|IA4PR12MB9809:EE_ X-MS-Office365-Filtering-Correlation-Id: d1074f59-76e8-47e4-5883-08de528d8056 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?NE4wSkhJRmhyaVZLVTNwbE5veFo0ZmpRK3pZN29EbkVTZGUyZ1FhSENpRUhs?= =?utf-8?B?TXpjV1RGaGJOOVpyMmRHaHBxZTMvanFTbmJFTlRMM3pQUDZWREhBNkpMdVhy?= =?utf-8?B?RVdOeThjbHY2enJVcDdRRFBOVTZuT245YzliajB6bnlVUnFBaFVSand1MzBp?= =?utf-8?B?MExsbjBmSkJJbS9CY0hENzdPMzRQN2wwTUM4cFQrQnBrMWw1bmZyYXpuZXR0?= =?utf-8?B?Z0xiWHVHMXBiWHZvRFVRWkVDZkNIWll3WWk2dnlZTkkvLzJKNlZDNzZCaTdY?= =?utf-8?B?SW4vZ2o4Zktvc3l6UXRLV1BpcnFnODRkeTF6S0kyRXA1VmFJdGtPTUNFYUtH?= =?utf-8?B?M0tHTG9PeGVaSlBxRHplYU1TcHM1aUg4TXIyeFprSHNIOU9jTjU5R3hzTmZF?= =?utf-8?B?YzgrelRwa3ZKanhFTzhaVnJXbWpXUFdXSmlwQzdtTUdCME5hVnpFNGQxR1VP?= =?utf-8?B?NnV2TWtpd0ZpVXBpWjhiWFo1OFVMRmhDSkRVY3lVTnl3QmFhcUxWNklxVnBE?= =?utf-8?B?R3ZLYzl0SldRSE1RNExUSDN2RkdzeXlpZkVHcnJrN0piRGd3SnBvU0pubU1T?= =?utf-8?B?aWVkbEhIZnpWZWozMEQ4OER2Qjc4MUhhRlFzWWloVXRkY0tZMHRIWkVtVWJC?= =?utf-8?B?SVNrd3kvVzYrKzAwOUFERHJVMzB2RW9ldzlpY1Y4VUtVVXgvTWZxejRsWjFX?= =?utf-8?B?cElBL1hHZVV4SHVWOWl6b1hyZXFXZlZTUmlST2JLeVcvcGw3a2xvL1lIdXU3?= =?utf-8?B?QzJXcGE1U1lDNlU1V0xZU2dteWR5MjVGMFFqYU1oeWN5dmNGdEFqWktBSlFv?= =?utf-8?B?UmMzaUJhK2l1a0NPNGpsZGEwV2JwWEM5aTQ0R3ZOb2ZxZmRKSklzYzZXN3Yz?= =?utf-8?B?VldIWGIvUEpxZEhITEIzeGR2Nm81ZnV5SFlRRlFyc2VpV0NyVkNveEZleFpZ?= =?utf-8?B?M2loWERaSExXckN0MXVyMjJIRkwvRVM0RS9RZ1I1dm9OcWZLUDJMb3phUThK?= =?utf-8?B?ellFUDBVSUFXUmMrSGw2em9Oc2R1TkVYOVZJUmVKeFZ5ckZQR0JCL21rY2hE?= =?utf-8?B?NkcxYUljL1NkTDNjWTBNUGx5MDBsTVdWcVZhcTdKVzlLTGc2VHU2ZUs0WDBY?= =?utf-8?B?Y2dRVTQ0UkRHeHVzbVpjL3FJaXd3YzJERmNxU3ZEb1dVOGZEdEovKzlidlBU?= =?utf-8?B?NFRWeUxUY2w2RkV5bzF4Um9KdTNQejd1VjBaN3FKNmhYSzhHOGc3c3BLK3lt?= =?utf-8?B?TjdQbUNOdE04Z0lZNnhValMzNmxCdmZQSExzMXR3WDBYek9ubzFOLzUxY1dJ?= =?utf-8?B?LzhPRU8xNEJOYzgrTUpOdXhoemd2NlpRZTBwMG9neVN2REZDaENjek42b2po?= =?utf-8?B?a0kzc2xVNzV1N3JTR2JxelZ6TkxmL2RtQzFnK3ZaKzM0b3BtOENSbVNkTmx3?= =?utf-8?B?bHU5ZU4zcXkzb2FLMEhUaUg1OU5sOVhUOE13VVpXcmx0bFVJRFVMNDFGdTBO?= =?utf-8?B?ay92eW5sWjJDSWhzRlVrRlUrcU50d3NKd0VzaEZDN3k1OFNCTUg2OFVtRWhv?= =?utf-8?B?dEtidm4xdUJyUXR4cFNCcVZhTzBnajZSY3o1NVVmc1VML3JOWFA4L05FaUZC?= =?utf-8?B?RG9JSGFmRloxbk1XR3crekVoaGRKQjJrcUNXYlBTR0pkTUdnZjhzZHF2cFRm?= =?utf-8?B?b1BHbG1oWGVkam5yVjJ5NVVIR251UUFqWWlpMGZUSkpGQkV5SGp2Rk1VaFN3?= =?utf-8?B?S1Q2N2poL1Nsd2hlTGRGU0M1UmFzZ0VFY2h3b1UvVlBNR2dtWXJBK1NYZWVH?= =?utf-8?B?NUhoMm1iRGFXMDlzMnBNTlRJRVNJT1ZBdHRIQnFzVldNbE8xWCtxd0RqMWo5?= =?utf-8?B?bGt2SXQxN0NpNVh0ckMvTnRMbFh2aGdQdTRkQkZoTXFDY3dpWTJ1QjZKbURy?= =?utf-8?B?ZU1tZ3lzMzV1bElvOWt1OUI4TVRxV2treGlNTHhFSFdkMHl1WFJmZFQ1NVM0?= =?utf-8?B?VmJIdTltZGpJelkzTHp5b1BSakFOaWJoNXp3YWdsYWJLWXJ0UnQ5ZmxGZ2I5?= =?utf-8?B?U2E5cFdZUTBPdzhpd0FSKzJnRTh5NnMvY0l5K1ZlVVZMN2EzeW9kb1VPZGhE?= =?utf-8?Q?6Rc4=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(376014)(36860700013)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 10:21:22.9748 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d1074f59-76e8-47e4-5883-08de528d8056 X-MS-Exchange-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: IA4PR12MB9809 Also, two more things here apart from my other remarks. On 05/01/2026 12:34, Harry Ramsey wrote: > From: Luca Fancellu > > HAS_VMAP is not enabled on MPU systems, but the vmap functions are used > in places across common code. In order to keep the existing code and > maintain correct functionality, implement the `vmap_contig` and `vunmap` > functions for MPU systems. > > Introduce a helper function `destroy_xen_mapping_containing` to aid with > unmapping an entire region when only the start address is known. > > Signed-off-by: Luca Fancellu > Signed-off-by: Harry Ramsey > --- > v2: > - Rename `destroy_entire_xen_mapping` to `destroy_xen_mapping_containing` > - Improve code documentation. > - Refactor nested code. > - Fix ignored rc error code in `destroy_xen_mapping_containing`. > --- ... > > +int destroy_xen_mapping_containing(paddr_t s) > +{ > + int rc; > + uint8_t idx; > + > + ASSERT(IS_ALIGNED(s, PAGE_SIZE)); > + > + spin_lock(&xen_mpumap_lock); Here you take a lock... > + > + rc = mpumap_contains_region(xen_mpumap, max_mpu_regions, s, s + PAGE_SIZE, > + &idx); > + if ( rc == MPUMAP_REGION_NOTFOUND ) > + { > + printk(XENLOG_ERR "Cannot remove entry that does not exist"); > + return -EINVAL; and here you would return while still holding the lock i.e. deadlock. > + } > + > + /* As we are unmapping entire region use MPUMAP_REGION_FOUND instead */ > + rc = xen_mpumap_free_entry(idx, MPUMAP_REGION_FOUND); Why don't you perform context_sync_mpu() here? ~Michal From xen-devel-bounces@lists.xenproject.org Tue Jan 13 10:22:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 10:22:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201357.1517009 (Exim 4.92) (envelope-from ) id 1vfbXd-0005pi-I5; Tue, 13 Jan 2026 10:22:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201357.1517009; Tue, 13 Jan 2026 10:22:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfbXd-0005pb-Eo; Tue, 13 Jan 2026 10:22:25 +0000 Received: by outflank-mailman (input) for mailman id 1201357; Tue, 13 Jan 2026 10:22:24 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfbXc-0005ds-MS for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 10:22:24 +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 bfa0ecc0-f069-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 11:22:22 +0100 (CET) Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-42fbbc3df8fso3889016f8f.2 for ; Tue, 13 Jan 2026 02:22:22 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ee5e3sm43108976f8f.35.2026.01.13.02.22.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 02:22:21 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bfa0ecc0-f069-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768299742; x=1768904542; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=L95vZiSfr8055GhKSrBi/zrW9/uFZkjsgBOfStb58Bg=; b=Pjaeui2EJg8X4WHZhMEU3tncbw2IWVutaEDuaV851BiiJVWc0VNSoRDlzqB513vLP8 8HHt3GjaWn+i4JuiqKLn1+T6awHfUdm3PEjlrvrYDaqqeuiIzbPeCqs044mA52TTr/99 +8QPf8L1qHWNwuzc77OjaUlGqTRqlb/YWJ1JKqEjgh2Hv7LHjZ7AECVpOa3Ww+R7kdSn tSili/zL2xT/UX22WpIccD/SNZ3IoZHOvVMmIFSGIANg2pmpcqy+A8YXM/nHaBbzXdls qe3W1JxOhzGis3o67JQyhZ4P0YeJjB53puX3qzdNZoleKVVAUYVgX66EzU0wg0ykePLa nnuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768299742; x=1768904542; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=L95vZiSfr8055GhKSrBi/zrW9/uFZkjsgBOfStb58Bg=; b=koC6OISIaDsnilWItRJDGl7abIGV96lXoUNmQZss5TTRabJu2V7JoEjTTF8MVWYVVL Yq6kNKv1S8jA3y5d2AaxKj/eZHWgmFmyWPCwjZxtiPQ6jpyWgTxZnY4AwF4ao7A5O1Qt fkmkg0XR2jU0TzeXBmNFtvPaGS+1V1stGzIm2VJfKFr61DAGIOrtc35kNIZTXjG5DDjZ seRl4QdgI6mujOSuNU+5lJkjhuXqS0snxoQf2oeM/ToQebtjYzQ2Bicaz31vhOSDsdFF RLW0uUJEIQIYy6gAr1ud6tBO8L52uWTkjfOjYG14u4ddn2nr85Dx0/y2G9W5e/cIFoSg tLag== X-Forwarded-Encrypted: i=1; AJvYcCVvWDkTSRmG7zxAzjZI5tJ6FmWWbgXz8pJ4ntPJuYfZ65SdCCcAnpm4lVeh+mBxtmi3QRFbfwUL9iw=@lists.xenproject.org X-Gm-Message-State: AOJu0YwjEccgfri4R3O9meYyofq51UAuRpVkhNPuLKzbhlhwydH89TgF J+ZyTzPXz4vIqDO7s8c2yTyO5W1nUpkzcJFPKLmBccemd9lqxcYX4wsWiofjV4rnUg== X-Gm-Gg: AY/fxX4Ce20UqW2b2QlEi/GxsIdSWBYduM+EMuAi0WLNs5U3A+PZYqoggJsZbB34v1t kXkoOon3hWHyPQYIkNvzKyRX/lcB/ra7qdbogx1l1IoRynYnDHNLGH1/5eZ7QnABT+mAvL7hplS V7yPi7IcjeXoo4lBOCUxosBpgWYMFZoNmQ/EcFdYfxzE0Ops24FhtYVs74EaxclksJHwXAoHnav rys14LuqzPMIwp6tXT5qgcNRQdf0Pv2ML4o1ctvWPcTWza7aF4jSXVf/JrRXTQuzXCobUiBMs1V P6fxeY2BnSrJGzX50TfAAfQmTKPXJNcxgU2jetF7fAdxhGSXlBVUG8CbrsVLiGCmUR3YkcTo8Qj ShQ7nN4orQRxEpym079LrMrHUO9/+RdbnjETC7n8IEsM5tKRTK2uU9ILJQ5r7g+MAqIQ0sQ97w7 B4zFI5rrvvMdWVM6EB0J2ZNtgQcFUxiTk8wfd5wh7NhANFf3O2yOzfTVMUoiPPQjZ5Qw8zQ9zHC tc= X-Google-Smtp-Source: AGHT+IFPLPGTyTMGDx3F7z+aGHH7tJwtCt0nSbgA9qFf5q1q1KKz+9SyaG1Yu5yB21l8Idx4FzB9sQ== X-Received: by 2002:a05:6000:240f:b0:431:864:d4a9 with SMTP id ffacd0b85a97d-432c3772035mr20632079f8f.8.1768299741905; Tue, 13 Jan 2026 02:22:21 -0800 (PST) Message-ID: <2786eab5-ff25-4d8d-b0d1-84a1d2727f9f@suse.com> Date: Tue, 13 Jan 2026 11:22:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 05/15] xen/riscv: implement stub for smp_send_event_check_mask() 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: <837c863f5995cc4371e82b481211b053656ec7e7.1766595589.git.oleksii.kurochko@gmail.com> <319e6162-7a5b-4030-ae9f-a86a48e73605@suse.com> <94c0cd09-7aaa-4ae1-913e-57d883916682@gmail.com> <92cfc028-cabd-4686-b6b9-7cc047a909c9@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: <92cfc028-cabd-4686-b6b9-7cc047a909c9@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 13.01.2026 10:58, Oleksii Kurochko wrote: > > On 1/12/26 6:05 PM, Jan Beulich wrote: >> On 12.01.2026 17:53, Oleksii Kurochko wrote: >>> On 1/7/26 4:47 PM, Jan Beulich wrote: >>>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>>> @@ -13,3 +14,10 @@ >>>>> struct pcpu_info pcpu_info[NR_CPUS] = { [0 ... NR_CPUS - 1] = { >>>>> .processor_id = NR_CPUS, >>>>> }}; >>>>> + >>>>> +void smp_send_event_check_mask(const cpumask_t *mask) >>>>> +{ >>>>> +#if CONFIG_NR_CPUS > 1 >>>>> +# error "smp_send_event_check_mask() unimplemented" >>>>> +#endif >>>>> +} >>>> CONFIG_NR_CPUS is 64 by default for 64-bit arch-es, from all I can tell, also >>>> for RISC-V. And there's no "override" in riscv64_defconfig. How is the above >>>> going to work in CI? Then again I must be overlooking something, as the config >>>> used in CI has CONFIG_NR_CPUS=1. Just that I can't tell why that is. >>> It is 1 because of the defintion of NR_CPUS in KConfig: >>> config NR_CPUS >>> int "Maximum number of CPUs" >>> range 1 1 if ARM && MPU >>> range 1 16383 >>> .... ( all other range props are condtional and there is no RISC-V in dependency) >>> so for RISC-V "range 1 16383" used and CONFIG_NR_CPUS is set to the minimal of this range, >>> so it is 1. >> I fear I don't follow: Why would the lowest value be picked, rather than the >> specified default (which would be 64 for RV64)? That's what I thought the >> default values are there (among other purposes). > > But there is no default for RISC-V for config NR_CPUS: > > config NR_CPUS > int "Maximum number of CPUs" > range 1 1 if ARM && MPU > range 1 16383 > default "256" if X86 > default "1" if ARM && MPU > default "8" if ARM && RCAR3 > default "4" if ARM && QEMU > default "4" if ARM && MPSOC > default "128" if ARM > help > ... Oh, indeed, that's what I was overlooking. > So a value from range [1, 16383] is chosen and based on the code of sym_validate_range(): > ... > val = strtoll(sym->curr.val, NULL, base); > val2 = sym_get_range_val(prop->expr->left.sym, base); > if (val >= val2) { > val2 = sym_get_range_val(prop->expr->right.sym, base); > if (val <= val2) > return; > } > if (sym->type == S_INT) > sprintf(str, "%lld", val2); > else > sprintf(str, "0x%llx", val2); > sym->curr.val = xstrdup(str); > > First initialization of val2 it is the left value of the range [1, 16383],so it is 1 > and val is 0 (I assume so that it is by initialization 0), thereby val2 = 1 will be > used as a value for NR_CPUS. But is this behavior documented anywhere? Wouldn't RISC-V (and PPC) better gain suitable defaults, making explicit what is wanted (for the time being)? E.g. config NR_CPUS int "Maximum number of CPUs" range 1 1 if ARM && MPU range 1 16383 default "256" if X86 default "1" if !ARM || MPU default "8" if RCAR3 default "4" if QEMU default "4" if MPSOC default "128" Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 13 10:22:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 10:22:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201358.1517019 (Exim 4.92) (envelope-from ) id 1vfbXl-00066f-Nx; Tue, 13 Jan 2026 10:22:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201358.1517019; Tue, 13 Jan 2026 10:22: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 1vfbXl-00066Y-LD; Tue, 13 Jan 2026 10:22:33 +0000 Received: by outflank-mailman (input) for mailman id 1201358; Tue, 13 Jan 2026 10:22:32 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfbXk-00065s-DY for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 10:22:32 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c47f5511-f069-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 11:22:30 +0100 (CET) Received: from BL1PR13CA0277.namprd13.prod.outlook.com (2603:10b6:208:2bc::12) by MN2PR12MB4143.namprd12.prod.outlook.com (2603:10b6:208:1d0::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 10:22:27 +0000 Received: from BL02EPF00021F68.namprd02.prod.outlook.com (2603:10b6:208:2bc:cafe::56) by BL1PR13CA0277.outlook.office365.com (2603:10b6:208:2bc::12) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.4 via Frontend Transport; Tue, 13 Jan 2026 10:22:27 +0000 Received: from satlexmb07.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_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Tue, 13 Jan 2026 10:22:26 +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; Tue, 13 Jan 2026 04:22:24 -0600 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 13 Jan 2026 02:22:24 -0800 Received: from [10.71.194.215] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Tue, 13 Jan 2026 02:22:22 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c47f5511-f069-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=NUluQbvx4VOPpnm3k7ZdEXOq0lCeHcPk0ndsSV2m4gxR2M4KJBXH0Y5q0HjcLJshpv8FV+ZR2kSZXea4Vri7lQMOzmnWjjK1/8Xv0RbFM7wfCInNWpVrxjbP7y4S3iCRQPeO89Ny2aZG8RqnxWnwz5B5Wbjdv1q4WDVoUBYwWNBd0yMWGUsjcX+BJ69OeefZArEWDGOXZAUmRpPLxOqmaDZzAmkiFnWXi/cl/2ciBanIJaaotAp9GFVTvOjj5+8KMfz5HaJMU8JqAcnc75//vuYyu2FN+eHv2yfLBvhafEouB8l5GiAZ6jUVhYYXPkRICsv4fUfvtmM/E2gWkvu8NQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=cw/MD7tweZ5roVeaoCfXZCAAEFyqM4QLZKYRT14mSzI=; b=UHt64SSXWg8NUMOIMem3dGGm6pza3dQCP2pMEqQ7UM8N5WugJDGSZ//AwGvf4Hl/KTJhjs60uLXGf7y50DtDbsi/IfHVqOUbasfxh87TT/LI2GuK2SaO+BZVRVXq9f4FfRK9kvBPCttOz0rE6hSyUuXzf9+ly1gAuy8hlXUWvjiwo8mQVB753XmZHezWbNHBilOCSkR9/sa37VNGJhqivFpKZAMXfC5eg1H2QOljEgAw7LbqecvjuEAlTLyNdQ7f0ygR9/UNJGiT0QG9QQgRsENX25NGIETzslHIQFjMk17NskFYObEgjS1Sl6JXje1Mj6dbGeD8Vsb9C9AnSh7I4g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cw/MD7tweZ5roVeaoCfXZCAAEFyqM4QLZKYRT14mSzI=; b=2OX11Qmp22KKvCH8z82ElgncleRbJl5oR13RifAh/m3Tb/OrcNN292ilBDQxMTXbl5qNBVNP8x8k8pZBGL9QBIfWtVg3Bw2UNblL1OMykKRjjMOtHZolNWqb9LmVvh3aQPv5PcKAUxJft2MKb6ybkkxULCIJp6ExyuMhRxd5jjU= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: Tue, 13 Jan 2026 11:22:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/6] arm/mpu: Implement free_init_memory for MPU systems To: Harry Ramsey , CC: , Penny Zheng , "Stefano Stabellini" , Julien Grall , "Bertrand Marquis" , Volodymyr Babchuk , Wei Chen , Hari Limaye References: <20260105113503.2674777-1-harry.ramsey@arm.com> <20260105113503.2674777-4-harry.ramsey@arm.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20260105113503.2674777-4-harry.ramsey@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF00021F68:EE_|MN2PR12MB4143:EE_ X-MS-Office365-Filtering-Correlation-Id: 4063010c-18e2-4d1b-f130-08de528da664 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700013|1800799024|7416014|82310400026|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?aGtnZGtDRldseHhESVFvSjJrbEcrVWllNnVjUThjOUwxQ0k2cFFMdlZJUlQv?= =?utf-8?B?dkQ5MHpyZUhpOFRBSkF5ajlSNGs1NVZ3bjZKTlRrNlFpeDRmV2xPdm0vSkIx?= =?utf-8?B?ZjZKTXpManJrQjVmQmoxcnI5TlRzYUZSQUpTaGIvQ3ovZmF3bUNFa1pnQXcw?= =?utf-8?B?STNrbWhpS2d0bkRVeE5jQWNZazhCZWljMXdVdDZZSG83VHprZGlBeHZuZDJF?= =?utf-8?B?YWFTb1VySW81NTR1N2RBZUFzM0xnQlQ2UG1xSHBQL1EwRU4wMXhIZEJFaVhr?= =?utf-8?B?cjQ0b1JYdFhRVXhLN2Q0UjM2a1pDRnNNeHY4TUQweTJZSWdOY2dnQmJjQVlt?= =?utf-8?B?YWlxQkdrUkxoZG1PckFieEhYTHBUVUFmMFZSQ1g3NzU5SG50WnN1b2l3UDFq?= =?utf-8?B?QzlXS0xCd2Fxc01zUWdGcWpZeHJMMTV2MjVkYVgxcVMwcEdmTm0xd2trSWtq?= =?utf-8?B?M1ZhTnhQcExSMExrOEdPdHRzSDd3VkJJSXVndURIaGRTT2RPenNWbE5PbW5K?= =?utf-8?B?WEk5NXFGUy91Q3hmQUFvOEhHVk1PaXdMUEo0SlRiMkRCMHdLUExGVDhIeHNq?= =?utf-8?B?akpnNmNDQTNEQVVnQU9jWjBPMlJscStWUjVCdkZxR0tQWitnRTNvdXNBWjJm?= =?utf-8?B?VlA1QmpocHJDS0xIQ1IwTlVoWkRVK24reDZLS0VzNFFlclcyZVNNM1FLRXJ3?= =?utf-8?B?SmJmSWsrK3NsNjhRaEJLQ25MbmVFYk9SciswMC9NT3dzd2RnbnUxcFlVcTVJ?= =?utf-8?B?UzZiZGRwOXY2b1B5bGRKVCtPVWlLUTNQRW1HVUtQT3V0bUZLR2g4V1huV0tW?= =?utf-8?B?SzRXVkRzL3RIYzdvWndHQ05GakVjMTJ5VVd6Yk1YTWx1NXRvWmswNG5qak43?= =?utf-8?B?NUp5T3ZrMGxvUVdRbUsyWUZNeVlESks1RXZzeHRTcEJEVUlrU0FwOEFPZk1E?= =?utf-8?B?OHczbk9EbjdxR1JjdjNiNzdteWFFdFdxSFBVeXZlWCtDazRPdytoOFdOdENX?= =?utf-8?B?TElaQTk0R0NmNGFpcmtVdndXUGh6aXYybzBQYVNFUzNYZzBRMGRNVVJDU0lZ?= =?utf-8?B?TnpLZjFyc3dVOFVWbG1Lclk4RDJUbWk1Z1BQVi9adjQ5Tm54Y2tscVROcXFw?= =?utf-8?B?cmM2UW55UWpVVFYrdzNGMGwvNEFXNDVleG5UeWlFeVBkcThscS9DdnR6M2x5?= =?utf-8?B?bll6bEZpV2FuVzhyQXc4QkpneVAxMUFBckY5R3J6d0pQYUVKZlBOK25ETW14?= =?utf-8?B?V0RRWHJ0eVFSQ2hWYnhwdU9OeEpJQTFuSEk5QXhsR1MvUmdyam1kRitFZTFh?= =?utf-8?B?Z1E5eHRFaDVjSE1pNnhweDlvcjdrU1Vta0hoZUljdE9kVmhtUVVnWitKQWZi?= =?utf-8?B?UkFUSGJrNko2RWttMDBQd09Rc00wQ2pZRk54ZVBKRW9nTkZ5bmdiVzBzSW00?= =?utf-8?B?S3BXb0pkWSt0V2piMnZYMkcwaEFnckp4WkNCRmJsYmxWdU02dVVBaWhqMDI3?= =?utf-8?B?aGVNSFhyWG1RWTdyaGsyOGd2ZkFnZ2RLZEROL1duUk9WcTIwQW1pTkE4TFFE?= =?utf-8?B?NW1Xd2lqNzZQY1NkUzU2eFd3ek1MWmV1NVhRL1h4UDJpU1ljUzVXaTFYK1Vh?= =?utf-8?B?c09vOG1SN01iTWl3TmQ2WEs0bWNLOGNuRWUwVEc1UEZkaEI5KzdpSms5K0E3?= =?utf-8?B?b3hIYTBlaStSRVlyRmFJRG82TGpmTGM5cDVFY3g4YTR5UHhrWmZnT2lWSEZF?= =?utf-8?B?RFdrMitpTlA5WWFvZTJrVmVUVHRrSDdNNGpyWVdCZHVtcXJ5YXllZ2l2MmFV?= =?utf-8?B?bXhVQWNUR3p4NkVWTzVwUWZDVVh6cHlxbTNDNVg2bG9qWnUxdFV0K3JwaXhw?= =?utf-8?B?VUlVOGs0S2RnVFZVRlZmaWRvam1rcjYwMms0MVhHOW0yRHZHMVJoZzI2WGJh?= =?utf-8?B?L01qak5OSTh0a1RUYXUwemJZM25QMWE3ajFxWVIvY0hINWVrRjAxVVNCM09u?= =?utf-8?B?TktvYjRrbzA3U29mR1U3ajdkeTk5d0J3cng1SDR3QkhsRHo0Y0JjcXAxUGF2?= =?utf-8?B?M0l3L04yK09iKzBrbGNUaG45aXNqc1lxTk1LaW5vSXBHSHVtU2NJKyt1STFI?= =?utf-8?Q?tCTw=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(7416014)(82310400026)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 10:22:26.8248 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4063010c-18e2-4d1b-f130-08de528da664 X-MS-Exchange-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: BL02EPF00021F68.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4143 On 05/01/2026 12:35, Harry Ramsey wrote: > From: Penny Zheng > > Implement the function `free_init_memory` for MPU systems. In order to > support this, the function `modify_xen_mappings` is implemented. > > On MPU systems, we map the init text and init data sections using > separate MPU memory regions. Therefore these are removed separately in > `free_init_memory`. > > Additionally remove warning messages from `is_mm_attr_match` as some > permissions can now be updated by `xen_mpumap_update_entry`. > > Signed-off-by: Penny Zheng > Signed-off-by: Wei Chen > Signed-off-by: Luca Fancellu > Signed-off-by: Hari Limaye > Signed-off-by: Harry Ramsey > --- > v2: > - Refactor `is_mm_attr_match` to return logical values regarding the > permission mismatch. > - Improve code documentation. > --- > xen/arch/arm/include/asm/mpu/mm.h | 6 +- > xen/arch/arm/include/asm/setup.h | 2 + > xen/arch/arm/mpu/mm.c | 113 +++++++++++++++++++++++------- > 3 files changed, 95 insertions(+), 26 deletions(-) > > diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h > index 1b5ffa5b64..f0941de295 100644 > --- a/xen/arch/arm/include/asm/mpu/mm.h > +++ b/xen/arch/arm/include/asm/mpu/mm.h > @@ -15,7 +15,11 @@ > #define MPUMAP_REGION_FOUND 1 > #define MPUMAP_REGION_INCLUSIVE 2 > > -#define INVALID_REGION_IDX 0xFFU > +#define MPU_ATTR_RO_MISMATCH -1 > +#define MPU_ATTR_XN_MISMATCH -2 > +#define MPU_ATTR_AI_MISMATCH -3 You don't seem to use these outside of mm.c, so I would suggest to move them there. > + > +#define INVALID_REGION_IDX 0xFFU > > extern struct page_info *frame_table; > > diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h > index 1eaf13bd66..005cf7be59 100644 > --- a/xen/arch/arm/include/asm/setup.h > +++ b/xen/arch/arm/include/asm/setup.h > @@ -65,6 +65,8 @@ int map_irq_to_domain(struct domain *d, unsigned int irq, > int map_range_to_domain(const struct dt_device_node *dev, > uint64_t addr, uint64_t len, void *data); > > +extern const char __init_data_begin[], __bss_start[], __bss_end[]; > + > struct init_info > { > /* Pointer to the stack, used by head.S when entering in C */ > diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c > index 207e8d2d91..4194d4fefd 100644 > --- a/xen/arch/arm/mpu/mm.c > +++ b/xen/arch/arm/mpu/mm.c > @@ -171,33 +171,18 @@ int mpumap_contains_region(pr_t *table, uint8_t nr_regions, paddr_t base, > return MPUMAP_REGION_NOTFOUND; > } > > -static bool is_mm_attr_match(pr_t *region, unsigned int attributes) > +static int is_mm_attr_match(pr_t *region, unsigned int attributes) > { > if ( region->prbar.reg.ro != PAGE_RO_MASK(attributes) ) > - { > - printk(XENLOG_WARNING > - "Mismatched Access Permission attributes (%#x instead of %#x)\n", > - region->prbar.reg.ro, PAGE_RO_MASK(attributes)); > - return false; > - } > + return MPU_ATTR_RO_MISMATCH; > > if ( region->prbar.reg.xn != PAGE_XN_MASK(attributes) ) > - { > - printk(XENLOG_WARNING > - "Mismatched Execute Never attributes (%#x instead of %#x)\n", > - region->prbar.reg.xn, PAGE_XN_MASK(attributes)); > - return false; > - } > + return MPU_ATTR_XN_MISMATCH; Later below you don't seem to differentiate between MPU_ATTR_RO_MISMATCH and MPU_ATTR_XN_MISMATCH. Therefore I would suggest to keep them as one to simplify the code. > > if ( region->prlar.reg.ai != PAGE_AI_MASK(attributes) ) > - { > - printk(XENLOG_WARNING > - "Mismatched Memory Attribute Index (%#x instead of %#x)\n", > - region->prlar.reg.ai, PAGE_AI_MASK(attributes)); > - return false; > - } > + return MPU_ATTR_AI_MISMATCH; > > - return true; > + return 0; > } > > /* Map a frame table to cover physical addresses ps through pe */ > @@ -357,12 +342,45 @@ static int xen_mpumap_update_entry(paddr_t base, paddr_t limit, > */ > if ( flags_has_page_present && (rc >= MPUMAP_REGION_FOUND) ) > { > - if ( !is_mm_attr_match(&xen_mpumap[idx], flags) ) > + int attr_match = is_mm_attr_match(&xen_mpumap[idx], flags); > + > + /* We do not support modifying AI attribute. */ > + if ( MPU_ATTR_AI_MISMATCH == attr_match ) > { > - printk("Modifying an existing entry is not supported\n"); > + printk(XENLOG_ERR > + "Modifying memory attribute is not supported\n"); > return -EINVAL; > } > > + /* > + * Permissions RO and XN can be changed only by the full region. > + * Permissions that match can continue and just increment refcount. > + */ > + if ( MPU_ATTR_RO_MISMATCH == attr_match || Enlcose in brackets () || () > + MPU_ATTR_XN_MISMATCH == attr_match ) > + { > + if ( rc == MPUMAP_REGION_INCLUSIVE ) > + { > + printk(XENLOG_ERR > + "Cannot modify partial region permissions\n"); > + return -EINVAL; > + } > + > + if ( xen_mpumap[idx].refcount != 0 ) > + { > + printk(XENLOG_ERR > + "Cannot modify memory permissions for a region mapped multiple times\n"); Memory permission? Here you are checking for XN/RO. > + return -EINVAL; > + } > + > + /* Set new permission */ > + xen_mpumap[idx].prbar.reg.ro = PAGE_RO_MASK(flags); > + xen_mpumap[idx].prbar.reg.xn = PAGE_XN_MASK(flags); Here you always change both, that's why there is no need to provide two separate macros as I mentioned above. ~Michal From xen-devel-bounces@lists.xenproject.org Tue Jan 13 10:37:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 10:37:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201385.1517029 (Exim 4.92) (envelope-from ) id 1vfbmW-0008Ml-5y; Tue, 13 Jan 2026 10:37:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201385.1517029; Tue, 13 Jan 2026 10:37:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfbmW-0008Me-1O; Tue, 13 Jan 2026 10:37:48 +0000 Received: by outflank-mailman (input) for mailman id 1201385; Tue, 13 Jan 2026 10:37:46 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfbmU-0008MY-JP for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 10:37:46 +0000 Received: from CH4PR04CU002.outbound.protection.outlook.com (mail-northcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c105::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e47640fd-f06b-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 11:37:44 +0100 (CET) Received: from BN0PR04CA0138.namprd04.prod.outlook.com (2603:10b6:408:ed::23) by IA1PR12MB8587.namprd12.prod.outlook.com (2603:10b6:208:450::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 10:37:40 +0000 Received: from BN2PEPF00004FBF.namprd04.prod.outlook.com (2603:10b6:408:ed:cafe::54) by BN0PR04CA0138.outlook.office365.com (2603:10b6:408:ed::23) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Tue, 13 Jan 2026 10:37:25 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN2PEPF00004FBF.mail.protection.outlook.com (10.167.243.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Tue, 13 Jan 2026 10:37:39 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 13 Jan 2026 04:37:39 -0600 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 13 Jan 2026 02:37:19 -0800 Received: from [10.71.194.215] (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, 13 Jan 2026 04:37:18 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e47640fd-f06b-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SH7dJwwKtx/DDIJTESEG9aVak6Wt4SbPiRCCXwlkSsSKtdouK8Cf66S/4qDXBkI5GZlpc3rhU25gUARWlP9RiKORjCWxwCJotpT0RrKguWQgxC7w7etqPJsBm3PLPls8chrzaIElDqhrs8P+fw9tPKUw9aZTjMLDPaihUALCm8FKgJXQa/ujMN2ufRxZRfkfTZxfwHxPTr3sHGOROmDBd8iiIlym4ICmuaS/b0gJBxulr87AwopROVevKgOaqoIqyEl2QolASS0TwFNRUivOqX12QTqF68JhuWaAOrK8hnmK2wDJbqDYYsZ+tr2Rlm0fNMrdR3Vei4KNdfG+uoRsMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SgGxVNYG8YELeYIgfqBCNDjHyU1LsBL7L6iSbZP7FxI=; b=mFnt3JqZlpBiVvHkmuZ6Cy7TokFkLdmLYAGXyOPsjypLf485yZLnXz6vpHSmFa66A3Tm51fjM8q2biFJAI2NWHLK6OeE+aXl+0bR/c5Uw4BJv9ZRQwI3C9yJcyZf+w0VyqiQFLn6EgpvMoQWdNsqWOCQBSVAmv5DqxROLpRM+QW31n6A3xo1mW0BYYA9aVQhynOGo15/dygP1/msAbjkGLqUkVEvYrT0PzeuI+SHePWcb9zyd3dvRNnXhe8Thqyl5t+KPf/HSlc36Z3Cgt6ultPr/738dO0ya79Qi/rsT5/Ysrn1ThHoRr2JNJ93x0KZeJW8F3UpvueOwOspOR8lag== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SgGxVNYG8YELeYIgfqBCNDjHyU1LsBL7L6iSbZP7FxI=; b=db59u33DjcU8uoZYjxht1s9j6OCc5VvwVr1mPQHl3euQI/Vu464JETlWDn30wDC57IOYuRVI6vaAzjKYBsKhqlwzA6UFevi+UkVpditPg5E2X4hPj9bYI8CDnGc0ALGDQTL9N97v5qUQ/ggqEceRl3t4WOy/zMrTtiMBcb1QKKQ= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: Tue, 13 Jan 2026 11:37:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/6] arm/mpu: Introduce modify_after_init_mappings To: Harry Ramsey , CC: , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Hari Limaye References: <20260105113503.2674777-1-harry.ramsey@arm.com> <20260105113503.2674777-5-harry.ramsey@arm.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20260105113503.2674777-5-harry.ramsey@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN2PEPF00004FBF:EE_|IA1PR12MB8587:EE_ X-MS-Office365-Filtering-Correlation-Id: 9650a3e8-30c6-48e4-8d68-08de528fc689 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700013|82310400026|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?dFBTeXg0L0FhZm1HdWdxSThxTTlrNy9UaGY1Y0VjNVkvOWtDVTVPVklWVGZV?= =?utf-8?B?SlFtR053K3JENmhDOWh6MTVQTXlOeHJTNU10M2JudGp0Y1hlNTNrLzVrWnFn?= =?utf-8?B?UmxVMkRTUlY5UlppQ1ZheGlpSi9aWVBFS2xRNFFISi9UWDd5WmV6US9TUWQv?= =?utf-8?B?azB0SjJJZ1ZCNUsyVXVQZnVMeVJ5QzBuWjVUMHZNNGxYdGduVUZlTGMxcjQv?= =?utf-8?B?WFEyNGc5ZzRMbHJSWGZZZVQ4cDdyR2I1cHdUTGViR2U2UFY0aUlheTQvZWlD?= =?utf-8?B?QllFS2J2YnVPcmhnOHY4UW91bXNSOERUNEVzQ2g2OXRPVUZ4cFJYVlUrYStn?= =?utf-8?B?RGp5cXdJekt6L016YWppMDlaanhFY2pUM2M2b3IxeVhGWS9CL3FQRFFUL3RM?= =?utf-8?B?ZnJYYjM1eWtHN0QvQWNpaVlVMUhHQ0xXWmpPZHJPdDBDS25SZC9ITEw3ckpl?= =?utf-8?B?SnMzcXhzeDVtZjFua1ZVNGJ0MXRxSUluL0dtdnU2UklJYTQvb3dYSUVXQ0pT?= =?utf-8?B?K05teUpkZ0N1RjFIcUdQN3UzQ2pIT050aXIyeTVRYis3VTJ1aUh6YWZUVzNt?= =?utf-8?B?U3I0Y1hDSWxPNGRRenBlbjg3RjcxQzFnSVR0aUwwRVR4cm0xcG9xazVsUkJj?= =?utf-8?B?TU1FbHRncXVGaDdOOE5wOExtWHJUOW5jK2NTVnE2STFCMEEvVVdLY1Y2dTVI?= =?utf-8?B?Unozb0h3bzl0Q0tWR0Z4UEt2QVpXZHpGUlkxdjZHWUhUUktTOHlJNlpJN29Y?= =?utf-8?B?RVZrc2hYMDJWVlZGeStvS1VQV2NIaGY5ZjVoOTVnUEhpRGRYOHpCcXdDa3Zs?= =?utf-8?B?TnhzcWRiSkVTWUovTlVxN2lWbUhDWFhNelV3cGREcENjTStmZVRDOXZjUXg5?= =?utf-8?B?MzlrUkFxeVRWUUFjZU13T1hibWEwZEgwSS83OElzZHhlSHA4QjRxQkl2Z3NS?= =?utf-8?B?WDVJZG5ibEZtVWhYMWZ6Yk1BRGlSRGhsWENJbEp0bFY4eXcxZHlnSlF4UnBq?= =?utf-8?B?Tk05MEVRWmovWFdOcDZ3bVVqTjhVb2U5OE13REs4ekZ2anRRVWJDRFJ2SkJP?= =?utf-8?B?VzVzY1pZSFdKQ2o1VXc2N2lsSDFGcU9ScU5LenJEck8wNGdZWW1JZXBMYWtR?= =?utf-8?B?RVdZTGZudGMvNEowNXFiNTJSQmhncVZjY3BYY2ZmcnZUd2MxWnZDSGp1U29a?= =?utf-8?B?d2dFYTRPRmt1dVJPZkxsNDhXTWQ0bGhFWlp3SUVyNERDMjBWdklkbXRDam03?= =?utf-8?B?MHRvYWxpOG41SzUzTHZabFdSUVVvTThXOFhJL2JUNVN0VHppM0c3M0xhUHMy?= =?utf-8?B?NHBBVUQ2MmtDeldGUFZuME00UXB2MTJoZzBxSDYxM0lXeFQySGRhVUFFTjlq?= =?utf-8?B?bmtNWWJKVTlNVkRMbXN2TnBZcDV4blI4cWpJMlYwZ0VNLzA0cmM0bGxXaE52?= =?utf-8?B?bEk1cDlkdHlEa21ZVCtucXBlNjBWTFdjVjA2dE1pWXhubjNkMlBWMFBUYmVX?= =?utf-8?B?SkNFZ0h4VFZUUFdTcXdiT1MybE5BQWsvNWQzVzdIVHJ2UmwyRU5nRDZTT0xn?= =?utf-8?B?UFc5emd5eFpDNnZ4dlVKSnVXTzN5K2lGcVcyaHY5RzRNelpFNnN6VnZTVVdT?= =?utf-8?B?YmhlQUNXbngxNGkwMFJaVG9iYzhhdUUrTFgzTFZrZitVcmV1dGwybE9vdXNk?= =?utf-8?B?bm90L1JrcWFDY09Ca0JJVVVtekU3NU84ZjVTTmk4RDczb0JpakZ4M0FGb0wr?= =?utf-8?B?SlVWSDROQ3Foa0ZOSW11NWF3dHltbG5HZVJyUGVKUTlHMVI4U3BOUmZOWkN3?= =?utf-8?B?ZEpIaG11NElmVUIrRXg0Qkl0YTRIRmxNYXVtZXBKakZhS0xQMjFsNmViKzds?= =?utf-8?B?YkJRNUgvcTFQeCtydHdRNlpxQ0E4cUQyUG9sVCt5ZzBEWGQvS1NrcEEyYTBZ?= =?utf-8?B?Q1UwUjkzWFpRUTJ2bERjUWwybUErMnRndmFqVU5SQ2VvL3hpczVvWmFzM0VZ?= =?utf-8?B?cmQ2RWZxc0FUQllSTklxa2pxNlNzUnR2a0l0ckxpVU14MnR1ZXY5TEF3R04r?= =?utf-8?B?cGNhSjJGWEk5SnZZZVB4Vzgrc2xuSWxuQW1YV0E1cFNUWFp2ZURCV3ZHNmlp?= =?utf-8?Q?qaGY=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(82310400026)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 10:37:39.7465 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9650a3e8-30c6-48e4-8d68-08de528fc689 X-MS-Exchange-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: BN2PEPF00004FBF.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8587 On 05/01/2026 12:35, Harry Ramsey wrote: > From: Luca Fancellu > > During `init_done`, Xen sets the permissions of all symbols marked with > __ro_after_init to be read-only. This does not work on MPU systems at > present because part-region modification is not supported. > > Therefore introduce the function `modify_after_init_mappings` for MMU > and MPU, to handle the divergent approaches to setting permissions of > __ro_after_init symbols. > > For MPU systems `modify_xen_mappings` will shrink the RW mapping on one > side and extend the RO mapping on the other. This approach prevents > wasting an additional region between RW and RO mappings. > > As the new function is marked with __init, it needs to be called before > `free_init_memory`. > > Signed-off-by: Luca Fancellu > Signed-off-by: Hari Limaye > Signed-off-by: Harry Ramsey Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Tue Jan 13 10:38:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 10:38:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201388.1517038 (Exim 4.92) (envelope-from ) id 1vfbmr-0000L4-Be; Tue, 13 Jan 2026 10:38:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201388.1517038; Tue, 13 Jan 2026 10:38:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfbmr-0000Ku-8S; Tue, 13 Jan 2026 10:38:09 +0000 Received: by outflank-mailman (input) for mailman id 1201388; Tue, 13 Jan 2026 10:38: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 1vfbmq-0000Ke-2a for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 10:38:08 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id eeed2199-f06b-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 11:38:02 +0100 (CET) Received: from MN2PR19CA0035.namprd19.prod.outlook.com (2603:10b6:208:178::48) by SJ2PR12MB8941.namprd12.prod.outlook.com (2603:10b6:a03:542::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 10:37:57 +0000 Received: from BL6PEPF0001AB59.namprd02.prod.outlook.com (2603:10b6:208:178:cafe::ba) by MN2PR19CA0035.outlook.office365.com (2603:10b6:208:178::48) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Tue, 13 Jan 2026 10:37:57 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF0001AB59.mail.protection.outlook.com (10.167.241.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Tue, 13 Jan 2026 10:37:56 +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, 13 Jan 2026 04:37:56 -0600 Received: from [10.71.194.215] (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, 13 Jan 2026 04:37:55 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: eeed2199-f06b-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qBSmF008nTaczfMj0Y+uOC0IS1XgQhJtqoB6d4QbBfbTp23vuK028x59seUu4hC8TcqVRkA3QyujP6r1JErO0H+5TMQcQK3a+kjdIQgB1rTnLJdmalLgNurwkdGh1HYPq6OxCvj2aLTqyxb4WMlu3/qgfCr3P2FzbP0FO6CNJGVBlEIjQQS1BR521vETyPiKmqr8ivt1oofE8fr0sVdqYWRd4GVkIlWpfS/YqBuMEIZIYcbqKIus8RUkeWu8pUci3LNlMAZZerT9k9LhTmKl25hG4bnvd2hdlpOwZZIhkCIHnFMCOLh6FhcsLpaUgDG+f80/mCJBta+Xpo56yOWhXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Hoq7dWv6A5rvTbw3ZzfJyhr0J5AUmN39uhaH7ZdrGvo=; b=T0jLL+FeEwunOfar7GEXmXvqkz6PhCoF9/oNUJKeVFGFBM0PCx83CJFsLkXuIljVTU2Orep8j6j8oW88iATNN29X9aHLZvobLr/bp6XVkBUrsps7V3UaYKYrexTSfCUu3g4/ndGJ8CLCLkaNZnAejNkO+H9+83EjhlFc+3CKhiqEjw4bBU8xB2R16uA0ShcGB1jWAtVDFrIeKPgKvBUDhlYb2j24GVfcpCLkbyAUyfQGzwICSB9aFnWDeeKICh7yTk5gjF5rfapjMmU0sOv6OkiSr0ECLtEBC32eJS8cu7NXIDSoPRZiE4T/j1+5Jy+FoLWWFvS3/DX560s76xNw+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Hoq7dWv6A5rvTbw3ZzfJyhr0J5AUmN39uhaH7ZdrGvo=; b=DOPG6W1aQdqw7hQoAtUBYJUI52BP9kl2KzS1M8KAPfBMJcvkCMHx83w6Ynu/4FafufNkIGSdvVffIDnRf19OIfVvAg9OMCaqHVqbMLoK5QIAJh1AmKmOpnWcahCCPfge91X9iOjktkwvM1UQhBfuXh3Is8Z/KL6eEv6rhf4KwEI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <43213cae-5c1d-46bb-8c28-869b92a20a32@amd.com> Date: Tue, 13 Jan 2026 11:37:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/6] arm: Use secure hypervisor timer in MPU system To: Harry Ramsey , CC: , Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Wei Chen References: <20260105113503.2674777-1-harry.ramsey@arm.com> <20260105113503.2674777-6-harry.ramsey@arm.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20260105113503.2674777-6-harry.ramsey@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB59:EE_|SJ2PR12MB8941:EE_ X-MS-Office365-Filtering-Correlation-Id: db71e0a0-3841-47d2-7e98-08de528fd0b5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|36860700013|82310400026|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?V2IzbktGbjdrRVJEc29QVWVTV1l6VTNaTU1nbmtxeFl3QitLei9oa0F5dXc3?= =?utf-8?B?SnVoVGdMaVJTR1JqQjBJZlVhanVEa0JxMWdqeTVCLzgyWGxvYzk5ZFdZNXM3?= =?utf-8?B?NFBkVG1QWlRoQmpqc3hNTE5ta28wREFMSmdkNkdkKzhLOHQyTzhsdjVzOUZQ?= =?utf-8?B?RWtVU1RacjFpMFJIKzJUU0FqMmgvS3ZaUjNvYmJxQWtJYjh3NEczV2VXcjll?= =?utf-8?B?eXdqck1GMjEyYWJDMU96Rzk5VWhkWEJ2R0ZTczdKVVlwVHpUbTNObU9PQWEw?= =?utf-8?B?K3NPRW1PdnBHV3d5Y08zalNqcTRPdVljTUh3enVHQlR5VWRMckpsUExtdVow?= =?utf-8?B?LzB6d1VDRnBtUlVnUU56RDNnQ2Vub3I1R0x1MTdzZHJrc3VtYm92L2VOQ2Rm?= =?utf-8?B?UGoyWDROYU5kS25PS1NidkNVc3FsK0lNR1BnelV5QTZxSWovaDZscTdNbVUz?= =?utf-8?B?RmtHZXhjWVJzOXFzaXAySHVwWDZCUUh4NEFDblZzb0JsRVhRbHVjdjI4RkY5?= =?utf-8?B?K0thL3VEMXlES2VXbnZMYzVKWndOR2hxbGkybXNUd09oK2hQdVBDSU1jQ3A1?= =?utf-8?B?L09pNktoZ21UeDl1UFliZjVzU3FTaXRxL0ZIdmNPZ1NHRWxiczNjVEx6bkxB?= =?utf-8?B?NHlMVEI3MmFlclpyQ0ttRFVTZkt1QkZLNDVKQUhlak04SkF0ZFhkbWJsUm5X?= =?utf-8?B?NmE4SlRRclBmTzNjaU53dFBPT2llc1A0WStIRTdaQVZ1dGpTRUEzdFF2OUY2?= =?utf-8?B?b0lBMVJibmRlNDllVVhQQmsvSWF1bUgxYldwTVJHSnFmbldQQTFPM2wzeHc2?= =?utf-8?B?dXM4SU10RTNTekd5V3RiSHBLQ3dNZHZhQit6VGxSSy9zdlBEZG04MUoxU2Zk?= =?utf-8?B?RzRBQkx5Y2xhcDhCUGRvUWhsZkpEVDcvSW9uTVRnTFJXSFJxNnJjL1V0ZUJ6?= =?utf-8?B?RzhhUjJwRVl5dlgxSHlteDQ3VXVqZFYrQ1NnQ2t5blR6Z0VLQ2FRVUNjN2xs?= =?utf-8?B?eUNhbkxjR1RqVXE5b0haR3IxMU11RW14RXhHdVh0QjViWE01Tjd0UFR2R0JS?= =?utf-8?B?ZFphR2JsTXE2eW94b3NrMnZ5SkNRdWZFeW02SzVXUUxWbjdCQ1hreHhWY0VC?= =?utf-8?B?RTJwcjZZOHVndnZDVWcrWGJNcVJaV0gxNUlHQWYxK09zRDJZdnJlazNVWlND?= =?utf-8?B?UXZsaFNHU0ovWnh0RExvNy9hQy9sajZheVdyRi94aStLclNMQkVYbW1KcDc4?= =?utf-8?B?MXNIUVNZdDh0K1BYdVdtSVhtVEZlK1o5OFZ0RW02azY0SHlMY2tKUEpHYXNM?= =?utf-8?B?d2NuNG55b1FyS0ZjTVNPNHBacTZtNU9hcU9RU0pCZmVXQ05KeHgvZXI0b0hi?= =?utf-8?B?RkdJWlcyVVB2S2RmWVJVNlZVMUo0VGhQc3VCeURvb1NwNHJkSzEzbng0OWRl?= =?utf-8?B?MDlUZUQ4a1g1Q09sZGNxRmRxdDhDcUE2ZFFvSFIvbEhjQzRxZ2p1eE9sbnBH?= =?utf-8?B?eGpmVGlPUWRxZWJEeVNRbTQ0NEJmMjB4N3RaYjB2eHZkVjZmeHBkWWI5Ni9I?= =?utf-8?B?Mld6ZTJhMUpYcTlycjlXR2JteSs1b0tWM28wdXAyWnlhdUxEYzB6TTllcGlL?= =?utf-8?B?eC9WOFc0M0swNE1MVUJHMXVKUmUvR1dUUmx6cnRSenAwZVA4bUlGeWI2V2g0?= =?utf-8?B?ZitnYTlwZnJzWU9MYkpjQXF5TGtPRDBTc2V1N3FvMEVjMVQrY0RybWZpVFkx?= =?utf-8?B?Z2FYbi9rOEhENmpkZXI1UjFpbjl6TFk2WEJNcGtNU3hhVU5heWxJZU1Vbm1E?= =?utf-8?B?Q1pNWU42a0dVNW40OUJaZTNkZ09yMHpQSG1LeERyVklwcUswby9lMEFlanFp?= =?utf-8?B?NHNaV1dxbFg1MTdSQWxDOVZIeWxSQ0VyQlBrNmtsc2xrczltUHFmUVowOFlz?= =?utf-8?B?UEhPM3hTNkhMeWRLMWhnSnYybTBhQUpBeUhDSkhxUlB5RjZpVnd6YmxFczZX?= =?utf-8?B?MGI0N29YT3ZlQ2FiNk42bmlVa3RjalkydDZDeGo0QkY1T0hId2dFdGxSQ2Jp?= =?utf-8?B?Mk9YdzdKaTl0VjNsTzI0MG1BSktJdGNrb09aSVhDMTdLZGdiZUdyUXdTczRn?= =?utf-8?Q?VgbI=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(36860700013)(82310400026)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 10:37:56.8188 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: db71e0a0-3841-47d2-7e98-08de528fd0b5 X-MS-Exchange-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: BL6PEPF0001AB59.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8941 On 05/01/2026 12:35, Harry Ramsey wrote: > From: Penny Zheng > > As MPU systems only have one secure state, we have to use secure EL2 > hypervisor timer for Xen in secure EL2. > > Signed-off-by: Penny Zheng > Signed-off-by: Wei Chen > Signed-off-by: Luca Fancellu > Signed-off-by: Harry Ramsey Acked-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Tue Jan 13 10:43:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 10:43:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201406.1517049 (Exim 4.92) (envelope-from ) id 1vfbsB-00021q-VN; Tue, 13 Jan 2026 10:43:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201406.1517049; Tue, 13 Jan 2026 10: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 1vfbsB-00021j-SP; Tue, 13 Jan 2026 10:43:39 +0000 Received: by outflank-mailman (input) for mailman id 1201406; Tue, 13 Jan 2026 10:43:39 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfbsB-00021b-C8 for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 10:43:39 +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 b5c43f79-f06c-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 11:43:35 +0100 (CET) Received: from PH0P220CA0026.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:d3::7) by DM6PR12MB4466.namprd12.prod.outlook.com (2603:10b6:5:2ae::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Tue, 13 Jan 2026 10:43:31 +0000 Received: from CY4PEPF0000EE35.namprd05.prod.outlook.com (2603:10b6:510:d3:cafe::c7) by PH0P220CA0026.outlook.office365.com (2603:10b6:510:d3::7) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Tue, 13 Jan 2026 10:43:31 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY4PEPF0000EE35.mail.protection.outlook.com (10.167.242.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Tue, 13 Jan 2026 10:43:30 +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, 13 Jan 2026 04:43:28 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b5c43f79-f06c-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xHSJo1m2W1Hp8Ud7TJyNr+j0PxmJTU2IdcCkKACzTBvd4QoiIsj2TTrc2so35VhZX4infd77VZ5D7PcXxNEyjABdp33SZw93SMToRt1xhjUs9PQ5mbtb1IRhQj/KG39IoS4GgpGfNH8y4+tV88fyQnjYzSD89qs6ZzFL6cnHW/rpiVn91cUXfariY4PdaGqI/MeZSquPnd+pXb5gq73GZHI/Cu85wejJpDV76vftgs6+EZxmkIZmKP0bZ3SP4/E5Umf1GUgFiL6RsqfWsb8wHDjQlN7kgxYawpgiRBLDI4vwTfJPR5yVYfljzcbYRMqwdZ6SoRfK8U/eu9yp4upXBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KxBAupTg2kQOCyR9dcm+ZDQE2IHBtAaR3DA0JJCHbSY=; b=T3WlOvX3X/hRMoXRbwW72k3fpm6XXj4OBmFHgvByoFKpItBOgDjzMrPum9jLM7+m/DUTA6drQKFFanbp2WUEOvQVkJq4Glz3P2Vn2thTf3EHQkrmX1t5usLzwp9rAHNNiFgLUTyxooti3vC4l2DC/+X2V3JPXCjqWOtW/kXGPe4BnWU+7Fcjc0lDvOuIsUQobRp4q+26LkbGAE4RmlrrtqGvXrfsAgfOSz5lbLGH/cXZejx5X1NXw/lhVPQW4p+iECyPBY3YFy9ZKozFYH8Bb72b7KAgFRcs57lsx054ox8v7sdgpVi5tm5WVKiZfuS6qBkuOdiLZGcw8mImtEaEfA== 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=KxBAupTg2kQOCyR9dcm+ZDQE2IHBtAaR3DA0JJCHbSY=; b=LA5E4+JyVCea8XG3YNcCwZ6eVFOq6z3LMYWhZ68Vo21GBDBLEkotY2mDXBqkVIEJLdzqqGFovIYjrP9+dz1kgI1mw9McsuyxSr6hFdpoYYcgaNyrj8L2FXXiNtF/S8gHYFYl+1P359pU1aMUgM9mo5emkaMsQoxXt/ZTiTN4+Ws= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 13 Jan 2026 11:43:27 +0100 Message-ID: Subject: Re: [PATCH v2 2/2] x86/ucode: Add Kconfig option to remove microcode loading From: Alejandro Vallejo To: Andrew Cooper , CC: Doug Goldstein , Stefano Stabellini , Anthony PERARD , "Michal Orzel" , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" , =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?= , Xen-devel X-Mailer: aerc 0.20.1 References: <20260112150259.74535-1-alejandro.garciavallejo@amd.com> <20260112150259.74535-3-alejandro.garciavallejo@amd.com> <96f4f3fe-46c4-4854-af55-d5adea07c847@citrix.com> <5fb97540-0b29-40b9-ac9b-039a41e30add@citrix.com> In-Reply-To: <5fb97540-0b29-40b9-ac9b-039a41e30add@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: CY4PEPF0000EE35:EE_|DM6PR12MB4466:EE_ X-MS-Office365-Filtering-Correlation-Id: 9e2d999c-0edb-4fed-b80c-08de529097ab X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|36860700013|82310400026|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?WXlqNENsaUNPdUNCR3BtRHk4V1ZXNGF3YnVUYUIyUmpQYitRU3lzSVBROC8r?= =?utf-8?B?L05idG1SdTFkNjZzU2FIdFdlb0RUWlZPQjlPaGYzdHMyMVBJanRZbWZya2ZS?= =?utf-8?B?c1RQcUx3ZGZNbzZWcHZIdk5xcFYzUE5qTlFaNFhNSzVHSVZ1aWIwandaYmFv?= =?utf-8?B?Wnh0U256VTVBUzZWVTRjNmhXbXFyUC85eXU4ZWVGVmU2U3ZqNDNOK2lpeHdu?= =?utf-8?B?RUdpVzRGMnNDV0l1RnRPZHB2LzlWMkZQWFlQb1l1SFJ4dWVxbkMxekM5a0gx?= =?utf-8?B?NjJTeXNwamkzSGhaSGRZY01vVWtvQ1U2ZzZsNDQ3VVdDbW02eVNxeEYwR0V0?= =?utf-8?B?WENLYTVKSzJsZGtOd1ZGR0NUTzQ5YW9leXNEVW13VmpuSUNaYUQ0WE14akV6?= =?utf-8?B?RFNLa0kxdHhVcFJJeUVjb05mdUVDeFVVcnlaUFdJOGhveisyeGlUMCsrTFBM?= =?utf-8?B?TzFib3Nydk9lUmloWXRSbXRqejdXazh0N1IwdzlXZlNhNlRTYUYrVmJaRk53?= =?utf-8?B?YTJLS2tJZG9rT21rNW9abnI3a0lkV0dOT1kzUVQxMFd2TE5Hcnk0ZDM1S1Q2?= =?utf-8?B?YXQ5WTZ1ZHJrSFJXTGh0SUJlQWg3Z1pzVzdhQTgxa21KeEVRWWx0eHdoZ3VN?= =?utf-8?B?dytxd0tOa3RkZXkwenNydVBuenN6dkFvR3IxaUc5SmVkaElCdlhLRVM2UWdr?= =?utf-8?B?dmN0bUZ6TmtWVUpFZDFvZG5lRGgvL21DUXdERU5ZN0xhZmVJVk5qYVBJQ1Q1?= =?utf-8?B?Y0Vvd053dGRVZ2tadnBMZmZCeVJhK01kNnFuUCtnbEFzTDVMSW9SVXZPWnps?= =?utf-8?B?em1KdUE3azZyK25CSHJPeTRCWU52RUJzeVIxQld1eDhLVHFpYm1WMmFnWkxR?= =?utf-8?B?ZlFBdXJVdGgxTU04OThXaWJwTXJiMWE4dFk2aDkzME1jVlRGc0ppWlVXOUQ2?= =?utf-8?B?cnVRYit6N1JyYjMrM0lhZTkvU3AyYUZoR2FSaGV0UGlmdW0wWURtakZzUnNm?= =?utf-8?B?dkc0YkF3UkFsYTc0UHFRckR3Y3NTc1h5SkVQd2liY0FWSDJYRE8vcVVxaVFJ?= =?utf-8?B?b3NGMjBWVlUvb0RsRGlYeW5Sdml2NmF5eS80MERwN3gwZWhoVWNVZ2loUXFJ?= =?utf-8?B?cWFRTE9JSWY5NVlSS3BUZ29FRTZLbTA3ZmVjamRha2hZVnpYdDFnN1dzUStk?= =?utf-8?B?dkJnVmMyWDVLN0ZpczVPT3AwdG41K3BPc2ppQjFFdWRQMFR6Q0I4NGtGQmxn?= =?utf-8?B?UHhpNU04NlVweDBXbWdRdnlrbVRuUThyL0xTbUV6UWI4ekxXUUtxWlFERFVM?= =?utf-8?B?OXh1TVpZS0tNUjk3cHhWbGs2ZTArYmRyV2V6RnZ1SjlBbklZcjZZaWRKMWpF?= =?utf-8?B?VEhxOTBYejlnM1lxVU0rWnhoT2NjVy8zRzlLN2prMWpJZ2dqSEMxZmhjZ05M?= =?utf-8?B?WUk5MUJWRlBqai9GQjRMSloxb1JVYStVUjF1aFVqVHRVSW8xb2kzYVVSdVo5?= =?utf-8?B?UHFsZ3pvV1ZjYVh0RUgvbjlQYnBJbnZ5ZXZyMUp2ZDgvOFRRT28rV1BLWEtk?= =?utf-8?B?d1VDSW40eXlDU2tPMW05OFV4TFhJYmorMmg1Z0hsR0NzRnVJcVVWL0p4TjZY?= =?utf-8?B?RFVTVHZITm9PM2JIVG42T1JwV0ZvRVVkbWVaTUhvakRiMm5adWMxcEYxbVZX?= =?utf-8?B?b25VejVLUWRJSXhOQlF6QXE4ZGM1Um9LTEgvdERLeWJSZHRiSzdTUWJmTUdk?= =?utf-8?B?VEZJeGoxcVlhWFViVEEvRjFCWWpYK25xRFR0WnMrRGRZUmZ6YmhxYUVTODVx?= =?utf-8?B?UHJCWXFMTmtDMXJYT1JjVVp1TDlyNXZ6UDE3RWdBOWZUZXplTWhBNnJ6ZUp0?= =?utf-8?B?c0Y3OW4yd1ovZzcySUJWUTdCdU5TY3BxNnpxcUM5TTJUR2ZoanpBcnFxNldw?= =?utf-8?B?dlJKQ0o3c2xKNktZVjNGRHpDT1RXRzlxNUZwejdZWncwOXZWenRaZmJ1SGFz?= =?utf-8?B?WjIvTms1TjNPNFFxWWJUMDdrUG8xL2tNeFFMQTJneVNuOWVRc0pmMGIwckJy?= =?utf-8?B?eWRBSWlPeGNEckZYeXVuTFdXOHpmV1pTc0dSYkZPZ3gyUlhuQTNLeGFLNmxs?= =?utf-8?Q?RIkA=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(376014)(36860700013)(82310400026)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 10:43:30.5701 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9e2d999c-0edb-4fed-b80c-08de529097ab X-MS-Exchange-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: CY4PEPF0000EE35.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4466 Hi, On Mon Jan 12, 2026 at 8:47 PM CET, Andrew Cooper wrote: > On 12/01/2026 6:47 pm, Alejandro Vallejo wrote: >> On Mon Jan 12, 2026 at 6:15 PM CET, Andrew Cooper wrote: >>> On 12/01/2026 3:02 pm, Alejandro Vallejo wrote: >>>> diff --git a/xen/arch/x86/cpu/microcode/intel.c b/xen/arch/x86/cpu/mic= rocode/intel.c >>>> index 281993e725..d9895018b4 100644 >>>> --- a/xen/arch/x86/cpu/microcode/intel.c >>>> +++ b/xen/arch/x86/cpu/microcode/intel.c >>>> @@ -404,21 +404,23 @@ static bool __init can_load_microcode(void) >>>> return !(mcu_ctrl & MCU_CONTROL_DIS_MCU_LOAD); >>>> } >>>> =20 >>>> -static const char __initconst intel_cpio_path[] =3D >>>> +static const char __initconst __maybe_unused intel_cpio_path[] =3D >>>> "kernel/x86/microcode/GenuineIntel.bin"; >>>> =20 >>>> static const struct microcode_ops __initconst_cf_clobber intel_ucode_= ops =3D { >>>> - .cpu_request_microcode =3D cpu_request_microcode, >>>> .collect_cpu_info =3D collect_cpu_info, >>>> +#ifdef CONFIG_MICROCODE_LOADING >>>> + .cpu_request_microcode =3D cpu_request_microcode, >>>> .apply_microcode =3D apply_microcode, >>>> .compare =3D intel_compare, >>>> .cpio_path =3D intel_cpio_path, >>>> +#endif /* CONFIG_MICROCODE_LOADING */ >>>> }; >>>> =20 >>>> void __init ucode_probe_intel(struct microcode_ops *ops) >>>> { >>>> *ops =3D intel_ucode_ops; >>>> =20 >>>> - if ( !can_load_microcode() ) >>>> + if ( IS_ENABLED(CONFIG_MICROCODE_LOADING) && !can_load_microcode(= ) ) >>>> ops->apply_microcode =3D NULL; >>>> } >>> ! ||, surely? >> When !CONFIG_MICROCODE_LOADING apply_microcode is already NULL. It's a n= eedless >> assignment. This is strictly so the compiler can avoid assigning anythin= g. >> >> Functionally it's irrelevant. > > Oh, that's subtle. > > As can_load_microcode() is a local static function anyway, it might be > better to have an early return false in there. > > That will get the same DCE, but be easier to follow. > Sure > >> >>> >>>> diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform= _hypercall.c >>>> index 79bb99e0b6..5e83965d21 100644 >>>> --- a/xen/arch/x86/platform_hypercall.c >>>> +++ b/xen/arch/x86/platform_hypercall.c >>>> @@ -307,6 +307,7 @@ ret_t do_platform_op( >>>> break; >>>> } >>>> =20 >>>> +#ifdef CONFIG_MICROCODE_LOADING >>>> case XENPF_microcode_update: >>>> { >>>> XEN_GUEST_HANDLE(const_void) data; >>>> @@ -327,6 +328,7 @@ ret_t do_platform_op( >>>> op->u.microcode2.flags); >>>> break; >>>> } >>>> +#endif /* CONFIG_MICROCODE_LOADING */ >>> You mustn't #ifdef out a case like this, because it causes the op to >>> fall into the default case, and some of the default chains go a long wa= y >>> and make unwise assumptions, like hitting a BUG(). >> It's normally more convenient for us (AMD) to physically remove code whe= re >> possible for coverage reasons, but in this case it probably doesn't matt= er. >> >> That said, I think we can both agree if dom0 can crash the hypervisor re= questing >> a non existing op the bug is probably in such a BUG() statement and not >> elsewhere. Note CONFIG_VIDEO already removes an op in this way in this v= ery >> file. The default case returns with ENOSYS, with BUG() being in helpers = for >> other data, as far as I can see. > > The existing bad practice are the ones I haven't had time to fix yet. > > As I recall, we did have a guest reachable BUG_ON() at one point caused > by this pattern, hence the "never again" position. > Fine. > >>>> =20 >>>> case XENPF_platform_quirk: >>>> { >>>> diff --git a/xen/common/Makefile b/xen/common/Makefile >>>> index 92c97d641e..1e6c92e554 100644 >>>> --- a/xen/common/Makefile >>>> +++ b/xen/common/Makefile >>>> @@ -65,7 +65,8 @@ obj-y +=3D wait.o >>>> obj-bin-y +=3D warning.init.o >>>> obj-y +=3D xmalloc_tlsf.o >>>> =20 >>>> -obj-bin-$(CONFIG_X86) +=3D $(foreach n,decompress bunzip2 unxz unlzma= lzo unlzo unlz4 unzstd earlycpio,$(n).init.o) >>>> +obj-bin-$(CONFIG_MICROCODE_LOADING) +=3D earlycpio.init.o >>>> +obj-bin-$(CONFIG_X86) +=3D $(foreach n,decompress bunzip2 unxz unlzma= lzo unlzo unlz4 unzstd,$(n).init.o) >>>> =20 >>>> obj-$(CONFIG_COMPAT) +=3D $(addprefix compat/,domain.o memory.o multi= call.o xlat.o) >>>> =20 >>> In a prereq patch, please move earlycpio out of common/ into xen/lib/.= =C2=A0 >>> It shouldn't be tied to CONFIG_MICROCODE_LOADING like this, and it can >>> simply be discarded at link time when it's librified and unreferenced. >>> >>> ~Andrew >> That would preclude having it in the init section though, AIUI. > > There's already lib stuff placed in init.=C2=A0 It works fine. > > (What does get complicated is conditionally-init, conditionally-not, but > that's complicated irrespective of lib/) It handles __init fine, but not "lib-y +=3D foo.init.o", AFAICS. It may be = 3 lines worth of fix, but seeing how earlycpio.c has a single function already tagg= ed with __init, I'll just drop the .init.o part and let the compiler place tha= t single function in the right section. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Tue Jan 13 10:45:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 10:45:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201419.1517059 (Exim 4.92) (envelope-from ) id 1vfbu4-0002cJ-Dd; Tue, 13 Jan 2026 10:45:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201419.1517059; Tue, 13 Jan 2026 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 1vfbu4-0002cC-Ab; Tue, 13 Jan 2026 10:45:36 +0000 Received: by outflank-mailman (input) for mailman id 1201419; Tue, 13 Jan 2026 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 1vfbu2-0002bf-S6 for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 10:45:34 +0000 Received: from CH4PR04CU002.outbound.protection.outlook.com (mail-northcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c105::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f8695718-f06c-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 11:45:29 +0100 (CET) Received: from PH0P220CA0010.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:d3::20) by MW3PR12MB4378.namprd12.prod.outlook.com (2603:10b6:303:52::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Tue, 13 Jan 2026 10:45:22 +0000 Received: from CY4PEPF0000EE35.namprd05.prod.outlook.com (2603:10b6:510:d3:cafe::9d) by PH0P220CA0010.outlook.office365.com (2603:10b6:510:d3::20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Tue, 13 Jan 2026 10:45:22 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY4PEPF0000EE35.mail.protection.outlook.com (10.167.242.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Tue, 13 Jan 2026 10:45:21 +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, 13 Jan 2026 04:45:19 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f8695718-f06c-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MJMl787VAtXyazFIFRy/ZRIBBlYH9kTSuwmFlYi4CJhyMx3T6TV+xmUIu88qWOhUIpSQC8eqLoKp9Rc+kV9phGT4UzXmHj12SfpipNzOolpX0RPBEHUO7R1SwAERt1XEEA5BjEZYQ0v/5uqqnnm8kisSzxL1WJ6TCEbL5Oc+Hsk2umTzG/ZWAdFLNd5OX/7sxIBRI2QoxEr+jfmX9nP0zypdWZoYwPeSggl6WMEeXZUwGdFcHsH4GD1JWxVQKEnozedZ5ShvXmM8IlnuJTVg0L+YuOW70ZeRV7cWjSQvX+fdmIdhQNoBWkH9irq9a3+p5dR0W9GMWNwdZ6cRvD+Yzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BI+OPCVlYQD0pRPpKV4vMAP82C8jdRQjuG7ThRlKxLQ=; b=ptCKT64Asrfka69/eITgHXacaxAqWm+PHKxOeE0/030q3lU0cFtiW19XFyLnxKzDG0+pORQsahEPgSw9JJm4sLyY+1WeieXobtQIHbFgPABEkjqTiRPMsdB9ymdJTj4CXzJ+jJfduznl102glTlekrSej4eEZs/20RZGD5ize94H+IZUTTx2sKG58kLlXLNYndGwfYZ4ikmE3FDRQ8/b4x+uFK9gGiE68f4XXp5a3w2WsX5zhZQgYmG9zwMRXjHkGhkASNHO4oOhPOGMkwCZNlU9TweK5L05kAErgOvUaEhT2TfUbY83oH1myz6rL99Q989+TgjAB8Z7+4USYcbHoQ== 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=BI+OPCVlYQD0pRPpKV4vMAP82C8jdRQjuG7ThRlKxLQ=; b=gpXo9BncdwkhBCmQqhE5qQeQGVKY24XDeNBeiQFsMxzvL8demn9rTWCbpU+rYO6xXIAhlgOROL6K30ZrEOACxUDiko9z9akZnWfZW9wQO/lctb2xryJht8oO/P419VTzsCqwWrCjk4uURU1CsVI5juw2+3sd9xMH+f3pIKKf3yA= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 13 Jan 2026 11:45:13 +0100 Message-ID: From: Alejandro Vallejo To: Jan Beulich , Andrew Cooper CC: Doug Goldstein , Stefano Stabellini , Anthony PERARD , "Michal Orzel" , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" , =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?= , Subject: Re: [PATCH v2 2/2] x86/ucode: Add Kconfig option to remove microcode loading X-Mailer: aerc 0.20.1 References: <20260112150259.74535-1-alejandro.garciavallejo@amd.com> <20260112150259.74535-3-alejandro.garciavallejo@amd.com> <96f4f3fe-46c4-4854-af55-d5adea07c847@citrix.com> <5b00ab27-5ad8-46c0-92fa-a1fa4b65bd99@suse.com> In-Reply-To: <5b00ab27-5ad8-46c0-92fa-a1fa4b65bd99@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: CY4PEPF0000EE35:EE_|MW3PR12MB4378:EE_ X-MS-Office365-Filtering-Correlation-Id: 2d3ddd68-aa40-4f9c-aeac-08de5290da0f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|36860700013|82310400026|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?M1ZLVEwySVZCaldIT2RSOFJabWtEUzBuSE5HMkdSUElNSmRoUmxLMytTWGxm?= =?utf-8?B?d21WVStjQmZyTnhwRTJqRjdYR1pEc1VTZmcvQk4rNlh1b0YvTmpIVzF3UlZ5?= =?utf-8?B?NjlGNDAvaXFGQnhjeHh6YitxaXRIM1dRakZUdzluVTNySUNxNnJ6KzdlUXZa?= =?utf-8?B?bFZlcUpTcUo4OFkwWUdIRk5ZNUd5cjlMbHVtalZZVk96ZDlFQ2ZVMWIxYVcr?= =?utf-8?B?OUZKbnlidW1pTlJ6RmkwTTVES29wMWZ2eFZVdGJwblYyOHhWM3VVQjhDMExY?= =?utf-8?B?Y0x3UDBBNTNjcmovNGhrK2VZRUZkNEpqY3BTTFRQem1TY2gwRktGN2ViZkVz?= =?utf-8?B?a1BqYXNWOGx4dE94T0M5TjFzSkVPbWFEbFBvK3ZTZzVad3lFcXorVkpnS01x?= =?utf-8?B?cjhGd3pDdENBL3BuOVFWNTJoZkl4V1BRVmh0MHlOR3kxc0NyRGlXRmNlWm11?= =?utf-8?B?N3NWWkU0Ym5ZeFlxaEtZTXQwNXQyWWtsNTRoU295WjVvc3FVd0hpUmtUR3Rs?= =?utf-8?B?cTZsUGJUa1hHY2FiNVNobCt5MWlwQlRya1FQZ0szRTRwejVPdWFrTE5sK3B2?= =?utf-8?B?WHVPcXdNdk5acXpmNFFwaEZWY1BXZk9nc3E1NzBlYWxDbGpyekx2bGl2K0pD?= =?utf-8?B?RUlxbnEzOVoyeGR1QXZvQVNITGtVNThmRC9VYzZBUkljdkt4MXlYZ20wR1JV?= =?utf-8?B?Z2tmK0RGWHRxS3RXZVhwNXhhRjdZbk5sQjZNWmIxSHJ1NUFnczU2QzdhRGw1?= =?utf-8?B?TEc2dE9Zc05WQ3JzSm1uRlBrSWtnZUY1by9lbnVkVWQ3cStITVNlbVoycTFZ?= =?utf-8?B?WmtIU3R4Z0tldkMwbGNGVXNHN2RVZDlZMDhjK0J4dDhObzI2SDNFdzcrUmxa?= =?utf-8?B?RnRrNG45NXdJNUpnTmQvOGtmeHVLSlo3N3Uzek41VUljUGxyaWNZYUlnOGp5?= =?utf-8?B?ZitGSGxtdjF1VHNnQzAzMlhWY0Z1Q0dkZHdXRUI4RU1BSjdFRTE0M1cvK2xJ?= =?utf-8?B?SkMzRStseU4vcU5VMG0zeHgwbEhyWWFXN2ZCbHNUUDlzSyt1alQxSGNHYi9k?= =?utf-8?B?bGdwa3RLYUxtZDV3cDhoOFIzRmNRR0xxOUpZUkhxSmFnL0FvRk1sS0tZVkdR?= =?utf-8?B?R2FjN0pkRzRUY0ZzVFdKYlJScU5LdStLWTduMi94UW5Wb1JLampPYWtGVlZk?= =?utf-8?B?UE14Q1NxZHk4NGFBT0VpYVJ5Q2F0VmVRR1ZQamdhSFYvRkRzSEg5N3ZwNXJ1?= =?utf-8?B?em5EQ2x0bGZyMWdaWFJ1TWhBMWtGaERSZENpV1NyV0F1Zy9jMENrM1Z1ejV2?= =?utf-8?B?YWRZZVdZQkFvK1VUZnhUTVZsdDloWGwzM2RUaGpMZVBLbVVzWlRYc0E0bklO?= =?utf-8?B?VmJGV3NXMlVwQ3NjRXYzeTMwdCtWUlVoN3NUSHpSNksxOE1XVzhLR0pPbWxi?= =?utf-8?B?UHMzU2xsNklnNHpzNWNJT3ZRQUtjaXdVNUtJZUg0Q290WUlJeDNDTnRvcTNL?= =?utf-8?B?RWh5alZXandvRE9NVHJyQjZxTDJwQjNRQWM2Q0VETDZGcTV4YU4rMlhTNVA1?= =?utf-8?B?S3d0ai9PWEZybGNmMWk2cWdTZlk3VXh3djVtdHR6ZHZicDA3S204aDJDcGsw?= =?utf-8?B?RWpUTGhjSGtoVUV6eDdBN0hhUlZQZXpGOURaclh4cHF5b3hlNzhVdllld2JT?= =?utf-8?B?ekxnV1ZDREdQRGZkaitOVHl3NXNTZlZwaVA1NC9ZcFpMaG13eEJWYnNYOXBw?= =?utf-8?B?TTU1cWVYYlZwTVdjdThuN3dLZXR6REVVNWZTeGsweDhWTWtmWEI4cjI0RnA4?= =?utf-8?B?UHNHeG85S1lVdm5BTmR4SnlBQlRiRDMyQjM2VmhxdG14bVRQT0hKZmVacXhY?= =?utf-8?B?K1FjQWkrVno4WkJ2b3NqQnlkV0d5NmlYdzZqNlpaYlRrVDZJV0FPamJDdnVj?= =?utf-8?B?ZmxKc3BWRTZHL0dZOVVSV2ZtNGxrZUQ0T2trNVVKeUJRRzZaOXR0elJKVHhU?= =?utf-8?B?Ui84RGRvS2E5bEVYS21DbXpyZEF3RTNoWU9ITk1BNWpZZmhScEFycXJUVkRr?= =?utf-8?B?anFUcC9EL1ppUFNYc2RHZmRoc0xZUm1tOVNieG8vOWhGS3pMcW84SmNTSW5M?= =?utf-8?Q?UZrw=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(376014)(36860700013)(82310400026)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 10:45:21.9540 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2d3ddd68-aa40-4f9c-aeac-08de5290da0f X-MS-Exchange-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: CY4PEPF0000EE35.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR12MB4378 On Tue Jan 13, 2026 at 9:58 AM CET, Jan Beulich wrote: > On 12.01.2026 18:15, Andrew Cooper wrote: >> On 12/01/2026 3:02 pm, Alejandro Vallejo wrote: >>> --- a/xen/arch/x86/Kconfig >>> +++ b/xen/arch/x86/Kconfig >>> @@ -331,8 +331,20 @@ config REQUIRE_NX >>> was unavailable. However, if enabled, Xen will no longer boot on >>> any CPU which is lacking NX support. >>> =20 >>> -config UCODE_SCAN_DEFAULT >>> +config MICROCODE_LOADING >>> + bool "Microcode loading" >>> + default y >>> + help >>> + Support updating the microcode revision of available CPUs with a ne= wer >>> + vendor-provided microcode blob. Microcode updates address some clas= ses of >>> + silicon defects. It's a very common delivery mechanism for fixes or >>> + workarounds for speculative execution vulnerabilities. >>> + >>> + If unsure, say Y. >>=20 >> Please don't re-iterate the default.=C2=A0 It's a waste. > > Well, first of all we should be consistent: Either we always have such a = brief > sentence in the help texts of boolean options, or we never have. Who know= s - > cleaning this up thoughout the tree may even address some anomalies (wher= e the > sentence and the default setting disagree). > > Jan Is that a request to add missing ones while fixing existing mismatches or r= emove them? Not as part of this series in any case, but do you have agreement on = the course of action? Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Tue Jan 13 10:46:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 10:46:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201429.1517069 (Exim 4.92) (envelope-from ) id 1vfbvK-000386-Np; Tue, 13 Jan 2026 10:46:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201429.1517069; Tue, 13 Jan 2026 10:46:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfbvK-00037z-Ki; Tue, 13 Jan 2026 10:46:54 +0000 Received: by outflank-mailman (input) for mailman id 1201429; Tue, 13 Jan 2026 10: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 1vfbvI-00037q-Ut for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 10:46:52 +0000 Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [2a00:1450:4864:20::444]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2b36678c-f06d-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 11:46:51 +0100 (CET) Received: by mail-wr1-x444.google.com with SMTP id ffacd0b85a97d-42fb6ce71c7so6253294f8f.1 for ; Tue, 13 Jan 2026 02:46:51 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ee243sm43675352f8f.31.2026.01.13.02.46.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 02:46:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2b36678c-f06d-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768301211; x=1768906011; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=5U0AiMomd6hbs2G3hf8fB/84mrZcrRs8c70BTXP2QVk=; b=b1r33Yo3wrk9cXmS2FdU3rv5SZ/qdoa1YPmqxdcns/EMuPJvzl2bsWZUORKeKD9t5q YL+f5H7dlG5GV8x6Ocx41ydUtw3E+VBiSKDw67WbhNyf4YEJ4RcloSWBup0Sw96Pswik TJqTzD0sIc3wTa0DlkDjGvG/IOlv8E94SsXyx4GLngybdz7J3GbaVxu82JVLoIs8VKKG /yLT+Je5Kwd6XjrC9Xyzu+D1+hfl1lK2Qs095ftupaYGOYPFOI58Z3jk5Tu4d+7GP0jL wtE53+yjxR6phnW7b7sTWzbAbLC0wF5tDuabAm9oMDx54j7F2+E5TxSTASUhwk1V8hkB /x3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768301211; x=1768906011; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5U0AiMomd6hbs2G3hf8fB/84mrZcrRs8c70BTXP2QVk=; b=fgE59GwWZmqjH4bhw+UxNuwdceyXYxLM6Za/viNsjZexw3qo7sR2MfZnpTUe419G+N WqzC15IFFmzTB2VUOGIpT5j+fQ2wpmfjrTa9QWuO1F6aOiQMNaeMZmFuUwIFUUjLR1ne SCse3nHTLm4nguSoTwhmJo0QUu3ZaBwjfOhYCp5g1WAapYKoH9JtgFloyBf8zdLULlM4 +3/J3Fx+3F0/2Uz3qwRLBjVqLlu10OLB2fL18I5+e3k8mKQHoehq2CN0n9dN5nSBA9eo FMoLM2DD+bPXqU7RJw4A5MD+vaNQBnsuDv4PPF7q4EkRc3MLrkfnUfPJo+VsFhTU+iha 0n7w== X-Forwarded-Encrypted: i=1; AJvYcCUsh7NB8kBK2lKqgHeKeDAR/WbcPcepk2i4vvelcw7rvArfJBAjEWxykB1mL3CjeWcrRT6xsOUpMRQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YwU8z5c4J9EhthCa6KvKTN3zh8dzHZ9hrIxEiofM7IckNl9aXJ7 exE965oKvZJqVGQdtfN4nLyyzoVZmFAAfknXgZArYnY7KWX8oonHOPpzdpnFaCqd0w== X-Gm-Gg: AY/fxX4dDCEAvHyWpVxZJWFgXepA99xtgwcEUhs6cAM8+ILXBAHqd2k7/zJE7QijUz8 ZGrSGZCffDPThDewh+kHC2L4ewJMIIEG/ewgyD4w/ViMBJESUCYVob1nwyMJd/Pvm5fwvltzXGB VBdYcmOxuxNhRxKWYgXxqpHFf8TTOKQJnXX1immlQFEUjFBeD9e7pUEJ+R291tnkaOVYFyg+/1c zdg+Q1GpSePqOIeafEGybnpCv+G+MlZJAkxPOz30XRylwQwMtOKbka9z+BwcK0T2ff75wZKwciJ ceXI9ig/QVhd1ifMUfHGNgFOuUfN/8v5PCX7T0G49x4L0z3gVAFba/LaNmrW6Ntni1eJVgmq7Q4 pZtjupaZBgqte+XxPbI/MNb+mjEx84uLikhB2SCeyV/gtMF2i8/HRl9s3BL0ihFugg5Dr3TR+JO WuZxh/BXnjiKSCG6Xa9fbwJzV6fYWLx4MAOUwyaLdsPjlfz4P6Qg/5B4Nim9czQdM1wvO6gfu6f 4k= X-Google-Smtp-Source: AGHT+IHX//L0Apb17iDGkowW4NwxM1ADyh12wPTyr1I5Ay4cKE440xSSzfY9o5UcqqBT/0Uh5VeSMA== X-Received: by 2002:a05:6000:2411:b0:431:c2:c632 with SMTP id ffacd0b85a97d-432c38d22f0mr25915882f8f.57.1768301211011; Tue, 13 Jan 2026 02:46:51 -0800 (PST) Message-ID: Date: Tue, 13 Jan 2026 11:46:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/6] PCI: determine whether a device has extended config space To: Stewart Hildebrand 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: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@suse.com> <52eb1293-b5d4-4f7a-b53b-285e4dd274a5@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.01.2026 22:07, Stewart Hildebrand wrote: > On 1/6/26 08:47, Jan Beulich wrote: >> --- >> Note that alloc_pdev()'s switch doesn't handle DEV_TYPE_PCI2PCIe_BRIDGE at >> all. Such bridges will therefore not have ->ext_cfg set (which is likely >> wrong). > > I initially read "set" as in "set to true", but I think you mean that ext_cfg > isn't assigned at all. Both are the same really, due to alloc_pdev() using xzalloc(). > Though perhaps it should actually be set to true, because ... > >> Shouldn't we handle them like DEV_TYPE_LEGACY_PCI_BRIDGE (or >> DEV_TYPE_PCI?) anyway (just like VT-d's set_msi_source_id() does)? > > ... in pdev_type(), we will only reach DEV_TYPE_PCI2PCIe_BRIDGE if it has > PCI_CAP_ID_EXP, which would indicate the device has extended config. So maybe it > would be better to handle it similar to DEV_TYPE_PCIe2PCI_BRIDGE in > alloc_pdev(). Hence my question. Since apparently you agree, I'll make that change. Maybe in a separate, prereq patch. >> @@ -420,6 +467,19 @@ static struct pci_dev *alloc_pdev(struct >> break; >> } >> >> + if ( pdev->ext_cfg && >> + /* >> + * Regular PCI devices have 256 bytes, but PCI-X 2 and PCI Express >> + * devices have 4096 bytes. Even if the device is capable, that >> + * doesn't mean we can access it. Maybe we don't have a way to >> + * generate extended config space accesses, or the device is behind a >> + * reverse Express bridge. So we try reading the dword at >> + * PCI_CFG_SPACE_SIZE which must either be 0 or a valid extended >> + * capability header. >> + */ >> + pci_conf_read32(pdev->sbdf, PCI_CFG_SPACE_SIZE) == 0xffffffffU ) >> + pdev->ext_cfg = false; > > I'm using a machine where > xen/arch/x86/x86_64/mmconfig-shared.c:is_mmconf_reserved() will initially return > false during Xen boot: > > (XEN) PCI: MCFG configuration 0: base f0000000 segment 0000 buses 00 - 3f > (XEN) PCI: Not using MCFG for segment 0000 bus 00-3f > > Then, during dom0 boot, dom0 will call PHYSDEVOP_pci_mmcfg_reserved, after which > MCFG becomes enabled in Xen: > > (XEN) PCI: Using MCFG for segment 0000 bus 00-3f > > On such machines where mmcfg/ECAM is initially disabled, this will effectively > set ->ext_cfg to false for all devices discovered at Xen boot. > > I'm not really sure if I have any good suggestions, but perhaps we could add a > macro or small function that returns something like > ( pdev->ext_cfg && pci_conf_read32(pdev->sbdf, PCI_CFG_SPACE_SIZE) != 0xffffffffU ) > to allow this checking to happen dynamically (but this still wouldn't handle the > aliasing quirk). Maybe re-run the ext_cfg detection logic at the end of > PHYSDEVOP_pci_mmcfg_reserved? > > Regardless, I'd be happy to provide my R-b without this addressed, but I am > curious if others think this as an issue? Hmm, no, I forgot to consider that case (which in principle I'm well aware of). Will need to fix in v2. >> --- a/xen/include/xen/pci.h >> +++ b/xen/include/xen/pci.h >> @@ -126,6 +126,9 @@ struct pci_dev { >> >> nodeid_t node; /* NUMA node */ >> >> + /* Whether the device has extended config space. */ > > Nit: it would be nice to clearly state if this means the extended config is > accessible, or whether the device merely has it (but might not be accessible). Well. Would the indicator be of any use if it wasn't accessible? Because if it isn't accessible, we may not even be certain it exists. But yes, I can surely make it "... has (accessible) extended ...". Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 13 10:50:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 10:50:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201441.1517079 (Exim 4.92) (envelope-from ) id 1vfby9-00040J-5w; Tue, 13 Jan 2026 10:49:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201441.1517079; Tue, 13 Jan 2026 10: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 1vfby9-00040C-2P; Tue, 13 Jan 2026 10:49:49 +0000 Received: by outflank-mailman (input) for mailman id 1201441; Tue, 13 Jan 2026 10:49: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 1vfby8-000406-0H for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 10:49:48 +0000 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [2a00:1450:4864:20::333]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 91ae0f8d-f06d-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 11:49:43 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-47edd6111b4so2767465e9.1 for ; Tue, 13 Jan 2026 02:49:43 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f418538sm402117265e9.5.2026.01.13.02.49.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 02:49:42 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 91ae0f8d-f06d-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768301383; x=1768906183; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=NPdN5854aDZtJwMwF5HuddLMf/w8UhIX2kIB6bT6G7I=; b=Orlto4wxhA0Z6t+2QmP/W7vTh+m0/xZH5FsJEAF8nVmWHURSLWDJfp62g08chLXlT2 X3408MCN8fbI2XCGPs6viMApcPZ2PVesQp1XdmMDWruGPsnW/6bD+B7/n0vnDXkPZmj5 t+2k45pqS1/J7OZ35rHK+mZBoQI7cmZCIIJDgQWaY+duLcsypQFZ5cz6f+/Zb3wDBYXG Fy/hel9twvpc/QEuHfDBrxYj0QIZnSWhagqWmL76lqT0OLG3NbChVGAcS16glMm/tOhJ NNwt51BY4WPgviv/2AHr1uSWRK8xyasgdS2NmwQ7F+2gXwpqdPaOo93tpnpQtYUAPW0/ oKOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768301383; x=1768906183; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=NPdN5854aDZtJwMwF5HuddLMf/w8UhIX2kIB6bT6G7I=; b=RWctp6zdXljgEmYEd31CsJcPVa+HjKtlbQPthKFkT0yVH0AOXrgwoJ3JcYRfL/tqSp fxCwqkbENjw509z2A6Tm9fpk8jde1eTdWu6T8ISF7ZQOvLy9VPpb+B6bq/TsnfTMnYHi N2B137PtFvl4QV1TfBtegMZH3Lh3hTnERNs86wMMkOKjMHy83zgqGNkgGIJ8aDGt9tiX sycZn3F1ee3oVH7+WAvlEmNWVz3ZGJ2uFTa7vy4pyA9MyvGwr9mHINdVlhDFBsGwztbo C8nHSgfSAM0Y35GO2p5OzL6PQoJtm2s1jyEcFwHCNZtPB9RRLL2C+/UOaJhbc046QL09 5qNw== X-Forwarded-Encrypted: i=1; AJvYcCUYt6SGN2XRG73J5oY42+DduQD1y0NvWVrHPdn34VJcAn9XzmHH7m5ruMb1nHs3sNr2C6aBCBx2QHY=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxw6qBOYp6UKo02eAr9dA0Bm5Wgaa6Ni5UfcSD6veVA2qaVITul +RpbCGwfVsHT+QO+QYKIzum6EryOm53mZnSk/CbNJAkfZ0jXD8KEGu26ujddvmKpog== X-Gm-Gg: AY/fxX72Urm176AYAf923MeS8L4sUwJZurqwKwmQHVdPgSDG1cpW5Q1r9zNg5jBAt40 UBvfQzVF8z5tGW7vEVUmvqwaKRBk0jO3wgQ+NnJZrhwVcIyVjP+3WpbWtGoASekFAmZZS4Cd1hv 8SO9WZDXDGtVTzZqfTzkF3AXLkutXAuaUbctPbjHPxrq2qt6WAOtx0/rUoUeIrtY6CGns4ShaRs Zvl8I3v+PJ2HG7rXTlrxpiZjijRx+l5gvi4KuwqekstEzhzj23KD12/Ru1LYFfAie7PAP4soxsI THrTTxk6RycpSHe7CkmQZ6oTZEFFcjR8/uPir+NndSWuAyOBenug46vqlLxHkG8uVfqZ9U/aNi8 wMnL2APvhNpfjPSmdkH2f2b+9T0O66rIfgMlHNVjzBnw5wr1fn6nSevQF+oyo3ADezkyeNDCmrP NfuQ1nsTcw0yK1OcEY3n6lhw26uTCY9lPryueId4KXH7Jy0bFcpTEGFVJB5gShNR+kl6R+RZO29 mk= X-Google-Smtp-Source: AGHT+IGdQ7YrpAxDPiYcDUqNzeQ7+6//p77Xu52rres6PcH9CyHGUoNP6fQIjR3fWx21HzG9wWY/OA== X-Received: by 2002:a05:600c:630f:b0:477:7a87:48d1 with SMTP id 5b1f17b1804b1-47d84b3b4d7mr237090045e9.30.1768301383039; Tue, 13 Jan 2026 02:49:43 -0800 (PST) Message-ID: <866ca08c-fb7c-4950-92b6-61368f567fe1@suse.com> Date: Tue, 13 Jan 2026 11:49:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] x86/ucode: Add Kconfig option to remove microcode loading To: Alejandro Vallejo , Andrew Cooper Cc: Doug Goldstein , Stefano Stabellini , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P. Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , xen-devel@lists.xenproject.org References: <20260112150259.74535-1-alejandro.garciavallejo@amd.com> <20260112150259.74535-3-alejandro.garciavallejo@amd.com> <96f4f3fe-46c4-4854-af55-d5adea07c847@citrix.com> <5b00ab27-5ad8-46c0-92fa-a1fa4b65bd99@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 13.01.2026 11:45, Alejandro Vallejo wrote: > On Tue Jan 13, 2026 at 9:58 AM CET, Jan Beulich wrote: >> On 12.01.2026 18:15, Andrew Cooper wrote: >>> On 12/01/2026 3:02 pm, Alejandro Vallejo wrote: >>>> --- a/xen/arch/x86/Kconfig >>>> +++ b/xen/arch/x86/Kconfig >>>> @@ -331,8 +331,20 @@ config REQUIRE_NX >>>> was unavailable. However, if enabled, Xen will no longer boot on >>>> any CPU which is lacking NX support. >>>> >>>> -config UCODE_SCAN_DEFAULT >>>> +config MICROCODE_LOADING >>>> + bool "Microcode loading" >>>> + default y >>>> + help >>>> + Support updating the microcode revision of available CPUs with a newer >>>> + vendor-provided microcode blob. Microcode updates address some classes of >>>> + silicon defects. It's a very common delivery mechanism for fixes or >>>> + workarounds for speculative execution vulnerabilities. >>>> + >>>> + If unsure, say Y. >>> >>> Please don't re-iterate the default.  It's a waste. >> >> Well, first of all we should be consistent: Either we always have such a brief >> sentence in the help texts of boolean options, or we never have. Who knows - >> cleaning this up thoughout the tree may even address some anomalies (where the >> sentence and the default setting disagree). > > Is that a request to add missing ones while fixing existing mismatches or remove > them? Not as part of this series in any case, but do you have agreement on the > course of action? While I agree with Andrew that these statements are redundant, I wouldn't call this "agreement" across all maintainers, at least not until a little more time has passed. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 13 11:00:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 11:00:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201455.1517089 (Exim 4.92) (envelope-from ) id 1vfc8a-0006pA-23; Tue, 13 Jan 2026 11:00:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201455.1517089; Tue, 13 Jan 2026 11: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 1vfc8Z-0006p3-UW; Tue, 13 Jan 2026 11:00:35 +0000 Received: by outflank-mailman (input) for mailman id 1201455; Tue, 13 Jan 2026 11:00: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 1vfc8Y-0006ox-7H for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 11:00:34 +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 14045f7d-f06f-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 12:00:31 +0100 (CET) Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-59b685d2b79so7128609e87.3 for ; Tue, 13 Jan 2026 03:00:31 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 14045f7d-f06f-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768302031; x=1768906831; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0gnlK1/Td8avc+cb1w5mS2e0lT26/bH6sbsF4/FYnvA=; b=Sf9yxpJBPZmDxIF7W4xQI3QRQYsU0jdnnyhA0ohypTXnAh98aiY7/kzN3gwuFhkxdF Bhse01CqlkSesmE1qF+5mQc/GClBXTaS9DnU+BqjsaD3R0sinmhhZ87B3afyvcSnKU65 APp3DjlAXZ0Ca3aVr48xoPrBsD9lwacUDJnxdWNRc6QDbdiXQcERR2Z0D32+a/ZTOXbQ zCFId6QKOxC1zAwBFMmm+T27IBZVqTgpVAhiPtfys9ltI0SWM/SbDCQbz1RrVQM0QqzN gI5dMYF6HmBNw0yTVH+svyqkLCDe0XUOifPtACXdPoPpGq2CSWIc/3F+iJoS1/X7vlxs iwXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768302031; x=1768906831; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0gnlK1/Td8avc+cb1w5mS2e0lT26/bH6sbsF4/FYnvA=; b=au/lTeD8oLBZeheQ6i84oW/lBlJXc4PodYXElDU1+Pkji7P8zZcJupotqmVGCKin/y b3Zrl1dBhoC2wp6hNDTIRGTrCEoMgF9RRcOOFQQmi+NgE+ynCbVX38vhmvbYV8a346H4 oSIDRH580b86JnNe8NdPydjOGvoWtuUcD+JGWEHE50jE5bb+X24jepmLLRj/FPjQTANW uH4G6M+lCLNMDl2sQPk0vN6Y/e4kLQ8uHF6gOBhdsmE81fI6Dc/lymqzscXL1/gpmUr5 FPgM1tQHc/qRcSxxMuG32/BXmt6XYVlxs5FXazahwCnsUU840Me9KIxlb5F+OV0quj1I zO5g== X-Gm-Message-State: AOJu0YzPuOOnWbxuxB/nylJpNIm6/Wm1QkLC2xeNFD4+HIZleLO5GOC7 /Ge5nqXHifTLrojY4tNYWU9pKqhEPT+0vsNFywzzyCKUB6GqhAvXkgt2TRdVBaDaWIkG8nLCgio xaHwlbFFRRmeLthVs0UHNGJUetlo2/LshGwLq X-Gm-Gg: AY/fxX5WX8NE4fC5YRSRct3CFKmx7TOyzqgLKnJ7CGGya6mCs+B27AofdZ7BQ/J98DW U00tt5hpLnRIn0FtakneoX1ncLfmffOqAF6Va0KoLoFYN2uNtaLHRegcZo7tBMohIcP4KGHNOde Vr/mXBwYNlvCMDcm15KMRsphgy+X170Ty7C1w5hLjCkL8iP6W5rch5Pi1mbjuGKQx7ot1lX+4zY W1tkaxM3SbXDsa+23KeZ2MwyZnQ+fpgUv+/TqWOzgHpRIvlPMWYXWJb2elMkZe3rZw9oQ== X-Google-Smtp-Source: AGHT+IGsfxQGiZJPZpv/ChWQS78nbpbCLpKJyCHDX7eqDB6Bqx6IkHw24ioTPD5ffpQxpue5vNWI83nXQth7KF/+H+g= X-Received: by 2002:a05:6512:3c88:b0:59b:8cca:9546 with SMTP id 2adb3069b0e04-59b8cca9a9amr2647366e87.30.1768302030439; Tue, 13 Jan 2026 03:00:30 -0800 (PST) MIME-Version: 1.0 From: Mykola Kvach Date: Tue, 13 Jan 2026 13:00:00 +0200 X-Gm-Features: AZwV_QgWQXcD146F7QjCdEH4X5JB3HIdcMaFLl10QUnnnn44Sk6YUlxeGDTtUvM Message-ID: Subject: [BUG] LLC coloring: parse_color_config shorthand/UINT_MAX/partial configs + missing newline To: Xen-devel Cc: andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk , Carlo Nonato Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, While investigating the Arm cache coloring, I noticed a few issues in parse_color_config() and one minor logging issue in the DT-related changes. 1) parse_color_config() appears to accept "shorthand" forms not described by the documented grammar The function documents: COLOR_CONFIGURATION ::=3D COLOR | RANGE,...,COLOR | RANGE RANGE ::=3D COLOR-COLOR However, as implemented, inputs starting with a delimiter may be accepted and interpreted as if a leading 0 was present. For example: ",2-6" -> interpreted as "0,2-6" "-10,2-6" -> interpreted as "0-10,2-6" The reason is that the parser calls simple_strtoul(s, &s, 0) and then directly checks for '-'/',' at *s. If no digits were consumed, start becomes 0 and s can remain at the delimiter, which then gets treated as a range or separator. Questions/proposed direction: - Is accepting these shorthand forms intentional? If yes, I think we should document them explicitly (both in the comment above parse_color_config() and in user-visible docs). - If not intentional, we likely want to reject by verifying that at least one digit was consumed for each number before accepting '-' or ','. 2) Potential infinite loop/hang for ranges ending at UINT_MAX The range expansion loop uses: for (color =3D start; color <=3D end; color++) If end =3D=3D UINT_MAX, incrementing color wraps back to 0, and (color <=3D end) remains true, resulting in an infinite loop inside early parsing. The current bounds checks do not prevent (start=3DUINT_MAX-some_small_number, end=3DUINT_MAX) from passing. 3) Partial global state on parse error can leak into later init/config use parse_color_config() writes into the provided array and increments *num_colors as it goes. On a parse error it returns -EINVAL, but the partially updated outputs remain. his is particularly problematic for the cmdline parameters, because the utputs are global and can later be consumed by llc_coloring_init() or dom0_set_llc_colors(). A concrete example is "1,w,3-5": - "1" is parsed and committed - at "w", simple_strtoul() returns 0 and does not advance 's' - the code then treats this as a single color 0, commits it, and breaks out with *s !=3D '\0' - the function returns -EINVAL, but num_colors and the array already contain a partial configuration In other words, a rejected configuration can still leave xen_num_colors or dom0_num_colors non-zero and the corresponding colors[] partially populated, which risks the feature being initialized/applied with an unintended set of colors. I think the parser should be fail-closed here. Minimally: reset *num_colors to 0 on any error path (including the final "*s ? -EINVAL" case). Ideally: parse transactionally into a temporary buffer and only commit outputs on full success. 4) Cosmetic: missing newline in printk in domain_set_llc_colors_from_str() printk(XENLOG_ERR "Error parsing LLC color configuration"); without a trailing '\n'. I wanted to flag these issues in case you=E2=80=99d like to address them in= the next revision/follow-up. Thanks, Mykola From xen-devel-bounces@lists.xenproject.org Tue Jan 13 11:15:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 11:15:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201474.1517099 (Exim 4.92) (envelope-from ) id 1vfcMn-0000L2-BH; Tue, 13 Jan 2026 11:15:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201474.1517099; Tue, 13 Jan 2026 11:15:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfcMn-0000Kv-7X; Tue, 13 Jan 2026 11:15:17 +0000 Received: by outflank-mailman (input) for mailman id 1201474; Tue, 13 Jan 2026 11: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 1vfcMl-0000Kp-SZ for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 11:15:16 +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 1de7170d-f071-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 12:15:07 +0100 (CET) Received: from DB3PR08CA0010.eurprd08.prod.outlook.com (2603:10a6:8::23) by DU0PR08MB7691.eurprd08.prod.outlook.com (2603:10a6:10:3a5::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Tue, 13 Jan 2026 11:15:03 +0000 Received: from DU6PEPF00009527.eurprd02.prod.outlook.com (2603:10a6:8:0:cafe::ed) by DB3PR08CA0010.outlook.office365.com (2603:10a6:8::23) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Tue, 13 Jan 2026 11:14:57 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by DU6PEPF00009527.mail.protection.outlook.com (10.167.8.8) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Tue, 13 Jan 2026 11:15:03 +0000 Received: from DU2PR08MB7272.eurprd08.prod.outlook.com (2603:10a6:10:2d7::16) by AM8PR08MB5698.eurprd08.prod.outlook.com (2603:10a6:20b:1c6::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 11:13:59 +0000 Received: from DU2PR08MB7272.eurprd08.prod.outlook.com ([fe80::5d34:206f:373:a323]) by DU2PR08MB7272.eurprd08.prod.outlook.com ([fe80::5d34:206f:373:a323%6]) with mapi id 15.20.9499.005; Tue, 13 Jan 2026 11:13: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: 1de7170d-f071-11f0-b15e-2bf370ae4941 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=arwg0xz2NrZW1PCaZ3BiYEYDS8PlfavOOgCr5tTS4pyeLgkdIt1KPNQ5UVFkZ1eeAmV8gR5w/UyZSe9xyvqQzd9uzs0epKXZ8CgkZO2UXbYaLDwtNdmhsEECJLYnb58mgnDqooguXtNm81ZSvuRYWidZAHUq+hXkuVdRGUIJ/SGNfqPs9YL6ZZ+53Ri20qto37YePWRlWQgooVB8R144RPlLmxhNax/x5gNUZGCybCG9Y3W4xKjGYg5O+5n2ihAcT8ctoXJQWbi/jg3KdVCG+VKSbTDSKGaGg5aVhXMUV9NUnNnEo0NBmZhNm63HZav+aGF0IiEb8o9PLvqsLfYU7g== 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=zPWre7sAnBTZifT2hNwGgG9mgoLyl51TBLLYiiBMSV0=; b=zMkATIw1TAF5py8loXQ/AGhl7Tce1XSPowWWcdpPpbxmSZiZv2cSSx5AZZY4AKeNitAXWr4PosPRvXnHsSAaLei30Hmo16U7x+PBJCbu7sTUVwsDlHvzIxJOS8gSmb1gG1XFS3mR73bufIi72sstD6V0VSV+qF+EQff8zOtIiLlEgLTp1fjzzRCz0odmgerBgMZMdUaxgwjNXCpbA8vfHrfr2qq4d/MUstEQroOn2DfWnzLflgN0irWaZrRI2nD8baMbw8Uw0eOez8EP5AEe4tyElw3a2OIFaIu655HOMbOQ9UdjSIRkQ/XT8RqgP1KpP1kaDZALEyqmliQC9x9q0A== 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=zPWre7sAnBTZifT2hNwGgG9mgoLyl51TBLLYiiBMSV0=; b=LhlrwdEI7mYHlmcpSVkJHgNp5rbvcx28z1AuvjgTA73no24zWHiVIyC1kulDoOQk8W+n/3twcssY4QzujbqzKjFmVttp8M5iYAqpqTUteDmm7C1Zv0eF48ZWSPvL2FFuGDmrCmkp9QQdvtkUAnOVG2XdEOVcaSVifUXdfYPICas= 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=bPTfgCUCk4N0QZy8KhEAwPYE0nKwsevlt/bWmfjRmKlC3+nWKuMqwPMFlEcqQyZAi0RPzUZX8/lWgBTuBjqhLG9oHGsDC7KF0QRA9wP3hekR8s7p7InxA2Es1FCdGh7CqY+Y7hPE0CKsFmbWiWfVjDrqUwzNgcwsZ/uNXWIRmQp4oGYm9Asau4jGNQw3ncAhk9ktQAYd5jMGr7o4OwNAtWGlYN6tRJxPkupqHhofrlspa0uEeFzL4tYVy45uAbUrx+qz/A2T1vxUfawq8J/bU/pGfzXB4eOYJ0lfzJgxFjbCSZrZAqi2ifESVxqQbGuv68KVvPurq9ug2XtFiujJrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zPWre7sAnBTZifT2hNwGgG9mgoLyl51TBLLYiiBMSV0=; b=GKCxTZj3cHIM3nRs21IAaL9HRI9D9Tt75SnhBXAjjOeh39fhSZYC9vknOHylAcBJmipv8j7fLvOcb9ZGVwywWRnyvW6osN2MT4xDUEi9A04gtzlBqXw6GpaZfYqptWSlEekhqqiZF9/B8vtDJzQ3Wxlu964S5P7OWJ1PA6icT5Cfo+Ht+53dSQcdpyGgVO/OCeWJ7dFH9wCtFi3zZnRT2L1m2lCxrTjN7CIoyN7knnlbOrkIKgzZalMthTK/055qmt6PZHZ8NDFLQJQAtxTpGCeLBVo9szMAG+bUlBfEodw7O+Hsd3RuDEVN87bEO48UeFKfvkSeEOoPkWwE/WNIPA== 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=zPWre7sAnBTZifT2hNwGgG9mgoLyl51TBLLYiiBMSV0=; b=LhlrwdEI7mYHlmcpSVkJHgNp5rbvcx28z1AuvjgTA73no24zWHiVIyC1kulDoOQk8W+n/3twcssY4QzujbqzKjFmVttp8M5iYAqpqTUteDmm7C1Zv0eF48ZWSPvL2FFuGDmrCmkp9QQdvtkUAnOVG2XdEOVcaSVifUXdfYPICas= From: Luca Fancellu To: "Orzel, Michal" CC: Harry Ramsey , "xen-devel@lists.xenproject.org" , Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Wei Chen , Hari Limaye Subject: Re: [PATCH v2 3/6] arm/mpu: Implement free_init_memory for MPU systems Thread-Topic: [PATCH v2 3/6] arm/mpu: Implement free_init_memory for MPU systems Thread-Index: AQHchHaKLhHT1ERV8EebnAsLklGjCrVP8l2A Date: Tue, 13 Jan 2026 11:13:59 +0000 Message-ID: References: <20260105113503.2674777-1-harry.ramsey@arm.com> <20260105113503.2674777-4-harry.ramsey@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3826.700.81) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DU2PR08MB7272:EE_|AM8PR08MB5698:EE_|DU6PEPF00009527:EE_|DU0PR08MB7691:EE_ X-MS-Office365-Filtering-Correlation-Id: 5ac5382c-fcca-42ce-9bcc-08de5294ffb0 x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|376014|366016|1800799024|38070700021; X-Microsoft-Antispam-Message-Info-Original: =?utf-8?B?SUZUTkN1aVdrQ3g1NC9VK1VzY2J1T1JRZ0FqWEp4a3orVDFCRGd0TE5TMDJX?= =?utf-8?B?OE9EZHc4d0xieUp6Slc3VllHMUsrVStvMWhyTzArRGdZcWN4eDkyb3JxK3BX?= =?utf-8?B?dEdDazAvQURuQlFCN0NTK21NREgvd2JWR1Zqa1FCN1lFWmsrVTFkMnphbUFm?= =?utf-8?B?T1Bhc3R6RlRWbGpqNWFWOWdzQzZUUUFEVm12bzBZdExwbng0WkxTQ2NoWm53?= =?utf-8?B?WnBjdko4UWlSL3JFUW91dWd1OWJRVVlISTNVTjdhNElXNlhIMXEzeG1pZjJP?= =?utf-8?B?U2VSU3pZNWUrWmZySWhJVmZmck9XUVJmMTBIdkJTWFRWMjFKMGRZSHdRWXl3?= =?utf-8?B?Vkc2YSt6bkhrb1BoaFJYNnhXQVdjMkRucXNwVWpGOWc3encreUF0UGx3VVUv?= =?utf-8?B?MWZIQUg1SDVDN3hhYW92OHcrd1E4TXdFRE80aVp1Q0NDUnY1RDdRSEdQN3Qr?= =?utf-8?B?MUd2Ujl5OEZ5MXk1bDh3SnRYNDROampNNC8rKzFzWGxUK0ZLVjg3dGJNQnNJ?= =?utf-8?B?RVkycGhZd0N3a3VGY2RCT0l6UnFrT2hKNHhwUURUUTdrMUU2Qmh2cC8zak1K?= =?utf-8?B?b3ZJenFmMXBYb2VieTlXT21KRnoyVTVmNVlOakZJcHhsTnlWTHB3YklkT2F3?= =?utf-8?B?ZzFRbzZtL2RkZmxmelhJWU9hSTFZcU1meFhaa1N2NENFRURxYzhYR2dBazQz?= =?utf-8?B?UGwzWWptNnAxdkVyTHVmWE5GRXg4Zm1NRDk5RzdLQjIycnNsZHAwNDBHOEx3?= =?utf-8?B?UTdCU2J3c0tJNjFvSFg4enhRc1hCSzNoTTkreDJSTUkzWkJQeTl0NDg5RmI3?= =?utf-8?B?cGZ0QkszM0NUb3k5RWlJdCtwbzREMHF3ZElYbHhVL2dPREtyajA0U29DOHcw?= =?utf-8?B?QjdVNU1WeCsvZXo3OHp4L0NmbjlJSzJYd1BGSXBlT0p4SUF4NWJjYVFmWU12?= =?utf-8?B?OHNGZWNBZXM4RTJ2NTRPdmVFNC8rR0pxY3BKZnFHOGx3WnBMdjNteEJzT0k1?= =?utf-8?B?NHVVTisraEc1YkZ0WXBQaHhpUWc3L1V5NWpTRzdVeTFCRnpqSkpRMXd0SW16?= =?utf-8?B?VjJOU3ljOUlxb2hvRnJCK1lFWlpxd3E0WTRXVkRRWjhmeFVVL1hkZ1QyaFVR?= =?utf-8?B?UlYxanlMWVRiRTgrVXFBOXdZN1g5WEk5eUdFbUNkenZHbGlrRm5YKzFsRWpG?= =?utf-8?B?R0Fud253dnU1Uyt4ZXdvQWs1Z28vSXhxYU5hNHk2N3RUNmRSZnZkbFVDckh0?= =?utf-8?B?VWRFcW1vOTZ0N3l2Sy9HODNvRHdtclFvR21GdzFCaFdobERiS3ZMby9PZmRv?= =?utf-8?B?U0hvRFltNGRwaFRHeWxwTkp5UnRpcktNMFcwWGlXYXNmVittRk9aa0hJRHV3?= =?utf-8?B?SzJuQzNNT1c5czU0MUtUZWU0em1VTm1ibytlcFNIV2xDU3BOZWNTRnc2RUJJ?= =?utf-8?B?Q3paYmp6dmFDSUY5elRaSHZ2WUZ6SUVPQW5DcUdDMHVtSmZtUWRGNzhoZUQz?= =?utf-8?B?V01HNHJrVUZTS0lrc0tGK3F2M2QweDhHZnlwbENaREtvN28reW1UbEVkVTQx?= =?utf-8?B?WTFKQWhCaEZhQzNmQk50cTJVdVIyRVk2MCswUFdtYlcxSHdRaFF0OWoyZHAr?= =?utf-8?B?ZWZieE1vZlVMdUNXNVA4MkI1MlUxVThWQTlvekVmNGJXam13M0c5dHZVSEZj?= =?utf-8?B?eWdxY2k2R0VJTTNDci9oU1c0UXM5Q255ci9PZ3gvTy9mOStLVFlFdVA5TWZO?= =?utf-8?B?RFMwSk5IMU5jQjVyeGlyZEtUaXVFZG01MndtRElsc3llcWNBMWFHY0JrMngr?= =?utf-8?B?b0JBTHZUeEN3ZC96WHJyeXpsWlFqMzU5N2hyV0RmRXZhclNmSDg5ZU5maEtS?= =?utf-8?B?dWtHYzRzWVpGSC9aZVRBaGFZbUJJTXVlY2lrYzEyT05NeWNtYkpkNWZTN2VQ?= =?utf-8?B?NnZYcXVRRlNHNmdzQkcrNlRSVEp1WkM2NXk5Nm5PekV2S09BVVhHejNhaWF6?= =?utf-8?B?dHBKTitySnVGOWl0Q0Q1ekxMUTB2VDFrdDgvVkRZRFMyU1VpeSs4N04wbFMy?= =?utf-8?Q?JEAUYI?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU2PR08MB7272.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB5698 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DU6PEPF00009527.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 393f8ac3-117a-4de4-71e7-08de5294d9e6 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700013|35042699022|376014|14060799003; X-Microsoft-Antispam-Message-Info: =?utf-8?B?SllGWkZRanZLVXFXOXFnMStBaFFMN2YxcnlwL2ZpYkRCaEsraEo4Y3hoNUph?= =?utf-8?B?ZXladVZpa01HYm04QytyS1hPWWVtRUhIMXBuUUxBQmwxOFZIbUxlZFI3a0F1?= =?utf-8?B?M1FFbjhUOG9wZmZ6ZzJ1Zm0rY2IvQWdnU0htUEpZTXc0YkZ3NDlmWnh1Y24z?= =?utf-8?B?RnQ4WGZydXpnY2R2T1ArSTJNZXdxWUlIYjZGdFZLZUxuaVc3ayszUm9xYUJ0?= =?utf-8?B?Q3YwRmI4K05vWTdMeC9sSE52L084VjJDUktOZTNYR3dhWWxSamhxZGZkSXBl?= =?utf-8?B?YnBvdzZwamxzUkFsN0xhdG1ObDBTN2tTd0RLUFVTM1B6Q2drbmNwRkJWR3dC?= =?utf-8?B?eEhYblMvaGl2R3FhK3NSbTNzaStqVURreEp3enNzME50eDhhUWNGR00zTG9I?= =?utf-8?B?QmJsRFZpODR5Y3M2UjVFNXh6NnA5YXlUK3hiYUo1dDBFY1BpY2RBMmF2UnV2?= =?utf-8?B?QlBacHk3aXc3UW9FTlorTzZPUUQraCtqMm1Td0pqTEs2Ui9uUC9KVk5Eaytx?= =?utf-8?B?dWhzbXJNZmtRZ3FVaE5wWEtLYk1GSmd0RVNrMG5zdXVSdGRDVnRtS3B4RjFN?= =?utf-8?B?YWN2WUFSaTU5OGJXKzNYK20vZFh1SUtTV0ZpdG9LdVpTS2xrcFBrTjZ0UjJt?= =?utf-8?B?UVk1Q3E2ci9sclFQcnRHN2w5SjAwWUNiS0FnQWJjSnRJWC9CQUNTQjJMZC82?= =?utf-8?B?V0U3Z0MvVGI3UEMydmplTXh4RDcrVkhET0x1QlFaVWxFcnZ1VU9obFRVRWNT?= =?utf-8?B?Nk5hNUFnYkUvcTRWOFlSdGkvZ1RjdTRidUFsZ253RzJEcE92cjVkZis5S1pR?= =?utf-8?B?N1pzQy9YeU92RUROQjhpaEtMWGlhMmhweVlNUktFL2VlZmlVRVJUYUZjdDdt?= =?utf-8?B?UkEwL2JTK01aNThjT2p3dlFrK3FqUFdFQmhtbHdFNW5mNHhiUThEemVlWDlH?= =?utf-8?B?TDhvb0Q3NW5rc2N5M0Vsc3hHenZBQWtJRlc2ZFgzRlNKbEs3dTJLR0RYVEJu?= =?utf-8?B?dGRQbzhzb2RVYkZEOXdweXpCdUhBc1MwbTRmb2NGVU1lUC9rMUhENDFBRVkr?= =?utf-8?B?V0tzcDduRi9OOFJocjNrR0xidjlYRnJ6eVRtcGN4UDV2SGVGY0ZmTkpNb1lF?= =?utf-8?B?WXZNbEZ4VngvQ3VTbUJvWGxnYUJvS3A4K3RsRnFib09vNFgvSXBmb0VVdWxG?= =?utf-8?B?ZWdYYjZXUUpQcUVCcm5KdmgwQVRNZyswWkN2V005Wk81SVlva2M3Ylo0MC9G?= =?utf-8?B?dHozZTZ6M3YxbEI0YkxTREtZTURFeFowNlVDb3hqWFpTNWVialRtL1VqVFhz?= =?utf-8?B?Q2l0ZEJhK2tabWYvRUM3UWp5SzRJSjRjZGFKV0pmMXh6TmxFMkY0d1lQcnp2?= =?utf-8?B?WjE1Y3RHT29lczdVZzRxaUUzQ0VRSDJKR1BrNk5RSHdHSXJkSFJMc09abmRx?= =?utf-8?B?NXRFNUd5ZVBsN2dhOThCaCtiSmFOVzhjMGJsaGVoT0dMT05Sa2cvUVcwK3JL?= =?utf-8?B?dkdldXN3ZnVBa1NlZ0VYQ1NIWUhuTEpyMlZRdlppeGNYeFBkTlVocGVOQkRN?= =?utf-8?B?VElOd3RkYVJ5MmhqZUZQaDRJSXo2TWVBb0RLWW0wR3BXRlZmSlNTWkRtWTZx?= =?utf-8?B?KzdMU1JHdnc5bkh1aDlhamIzY05ZTzVRM1FwMzM2dExvc251dGttUmhKMmI1?= =?utf-8?B?Zm5zY1BDOHIyMlpWUXBYVTRQUE8xaE5NRGxadHBxU3A4WmRFbEE5aTlMSWpp?= =?utf-8?B?anRYVTBFUm9weVNta0N3aHlJZ2JsRjNUam9oZW1QRmZrVDQ1bnZ3MzlDL2dq?= =?utf-8?B?WHNYUk1VV1RPdEczN0N1OGxwSFI3REF6SmcvTnVicDdtTGZISHFJS3BvZ3Rq?= =?utf-8?B?RlQ2eDZyNVJ5ejhCa0h0OC83VjNjQ05qM1NGZ0FJV0RmVVliV1JGbmlZNlo0?= =?utf-8?B?L2ZWZEwwaGcrOURzSGxmRWRyZW9iZ1FILzBBeG5TNllYUnBXQ3R6LzFjendQ?= =?utf-8?B?QVZwbzZxZENQT240YTJqL25zSWRzMExpaURoQktzNG1nZUNNUk44OUI2OENB?= =?utf-8?B?c2YrZ3dSMVQ4akdHWGh4a3JvUGxCc1luTkQ2cW1zcTFZWXgxUkpHMmJZN2lm?= =?utf-8?Q?4KoQ=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)(1800799024)(82310400026)(36860700013)(35042699022)(376014)(14060799003);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 11:15:03.0469 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5ac5382c-fcca-42ce-9bcc-08de5294ffb0 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: DU6PEPF00009527.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB7691 SGkgTWljaGFsLA0KDQo+PiANCj4+IC1zdGF0aWMgYm9vbCBpc19tbV9hdHRyX21hdGNoKHByX3Qg KnJlZ2lvbiwgdW5zaWduZWQgaW50IGF0dHJpYnV0ZXMpDQo+PiArc3RhdGljIGludCBpc19tbV9h dHRyX21hdGNoKHByX3QgKnJlZ2lvbiwgdW5zaWduZWQgaW50IGF0dHJpYnV0ZXMpDQo+PiB7DQo+ PiAgICAgaWYgKCByZWdpb24tPnByYmFyLnJlZy5ybyAhPSBQQUdFX1JPX01BU0soYXR0cmlidXRl cykgKQ0KPj4gLSAgICB7DQo+PiAtICAgICAgICBwcmludGsoWEVOTE9HX1dBUk5JTkcNCj4+IC0g ICAgICAgICAgICAgICAiTWlzbWF0Y2hlZCBBY2Nlc3MgUGVybWlzc2lvbiBhdHRyaWJ1dGVzICgl I3ggaW5zdGVhZCBvZiAlI3gpXG4iLA0KPj4gLSAgICAgICAgICAgICAgIHJlZ2lvbi0+cHJiYXIu cmVnLnJvLCBQQUdFX1JPX01BU0soYXR0cmlidXRlcykpOw0KPj4gLSAgICAgICAgcmV0dXJuIGZh bHNlOw0KPj4gLSAgICB9DQo+PiArICAgICAgICByZXR1cm4gTVBVX0FUVFJfUk9fTUlTTUFUQ0g7 DQo+PiANCj4+ICAgICBpZiAoIHJlZ2lvbi0+cHJiYXIucmVnLnhuICE9IFBBR0VfWE5fTUFTSyhh dHRyaWJ1dGVzKSApDQo+PiAtICAgIHsNCj4+IC0gICAgICAgIHByaW50ayhYRU5MT0dfV0FSTklO Rw0KPj4gLSAgICAgICAgICAgICAgICJNaXNtYXRjaGVkIEV4ZWN1dGUgTmV2ZXIgYXR0cmlidXRl cyAoJSN4IGluc3RlYWQgb2YgJSN4KVxuIiwNCj4+IC0gICAgICAgICAgICAgICByZWdpb24tPnBy YmFyLnJlZy54biwgUEFHRV9YTl9NQVNLKGF0dHJpYnV0ZXMpKTsNCj4+IC0gICAgICAgIHJldHVy biBmYWxzZTsNCj4+IC0gICAgfQ0KPj4gKyAgICAgICAgcmV0dXJuIE1QVV9BVFRSX1hOX01JU01B VENIOw0KPiBMYXRlciBiZWxvdyB5b3UgZG9uJ3Qgc2VlbSB0byBkaWZmZXJlbnRpYXRlIGJldHdl ZW4gTVBVX0FUVFJfUk9fTUlTTUFUQ0ggYW5kDQo+IE1QVV9BVFRSX1hOX01JU01BVENILiBUaGVy ZWZvcmUgSSB3b3VsZCBzdWdnZXN0IHRvIGtlZXAgdGhlbSBhcyBvbmUgdG8gc2ltcGxpZnkNCj4g dGhlIGNvZGUuDQo+IA0KPj4gDQo+PiAgICAgaWYgKCByZWdpb24tPnBybGFyLnJlZy5haSAhPSBQ QUdFX0FJX01BU0soYXR0cmlidXRlcykgKQ0KPj4gLSAgICB7DQo+PiAtICAgICAgICBwcmludGso WEVOTE9HX1dBUk5JTkcNCj4+IC0gICAgICAgICAgICAgICAiTWlzbWF0Y2hlZCBNZW1vcnkgQXR0 cmlidXRlIEluZGV4ICglI3ggaW5zdGVhZCBvZiAlI3gpXG4iLA0KPj4gLSAgICAgICAgICAgICAg IHJlZ2lvbi0+cHJsYXIucmVnLmFpLCBQQUdFX0FJX01BU0soYXR0cmlidXRlcykpOw0KPj4gLSAg ICAgICAgcmV0dXJuIGZhbHNlOw0KPj4gLSAgICB9DQo+PiArICAgICAgICByZXR1cm4gTVBVX0FU VFJfQUlfTUlTTUFUQ0g7DQo+PiANCj4+IC0gICAgcmV0dXJuIHRydWU7DQo+PiArICAgIHJldHVy biAwOw0KPj4gfQ0KPj4gDQo+PiAvKiBNYXAgYSBmcmFtZSB0YWJsZSB0byBjb3ZlciBwaHlzaWNh bCBhZGRyZXNzZXMgcHMgdGhyb3VnaCBwZSAqLw0KPj4gQEAgLTM1NywxMiArMzQyLDQ1IEBAIHN0 YXRpYyBpbnQgeGVuX21wdW1hcF91cGRhdGVfZW50cnkocGFkZHJfdCBiYXNlLCBwYWRkcl90IGxp bWl0LA0KPj4gICAgICovDQo+PiAgICAgaWYgKCBmbGFnc19oYXNfcGFnZV9wcmVzZW50ICYmIChy YyA+PSBNUFVNQVBfUkVHSU9OX0ZPVU5EKSApDQo+PiAgICAgew0KPj4gLSAgICAgICAgaWYgKCAh aXNfbW1fYXR0cl9tYXRjaCgmeGVuX21wdW1hcFtpZHhdLCBmbGFncykgKQ0KPj4gKyAgICAgICAg aW50IGF0dHJfbWF0Y2ggPSBpc19tbV9hdHRyX21hdGNoKCZ4ZW5fbXB1bWFwW2lkeF0sIGZsYWdz KTsNCj4+ICsNCj4+ICsgICAgICAgIC8qIFdlIGRvIG5vdCBzdXBwb3J0IG1vZGlmeWluZyBBSSBh dHRyaWJ1dGUuICovDQo+PiArICAgICAgICBpZiAoIE1QVV9BVFRSX0FJX01JU01BVENIID09IGF0 dHJfbWF0Y2ggKQ0KPj4gICAgICAgICB7DQo+PiAtICAgICAgICAgICAgcHJpbnRrKCJNb2RpZnlp bmcgYW4gZXhpc3RpbmcgZW50cnkgaXMgbm90IHN1cHBvcnRlZFxuIik7DQo+PiArICAgICAgICAg ICAgcHJpbnRrKFhFTkxPR19FUlINCj4+ICsgICAgICAgICAgICAgICAgICAgIk1vZGlmeWluZyBt ZW1vcnkgYXR0cmlidXRlIGlzIG5vdCBzdXBwb3J0ZWRcbiIpOw0KPj4gICAgICAgICAgICAgcmV0 dXJuIC1FSU5WQUw7DQo+PiAgICAgICAgIH0NCj4+IA0KPj4gKyAgICAgICAgLyoNCj4+ICsgICAg ICAgICAqIFBlcm1pc3Npb25zIFJPIGFuZCBYTiBjYW4gYmUgY2hhbmdlZCBvbmx5IGJ5IHRoZSBm dWxsIHJlZ2lvbi4NCj4+ICsgICAgICAgICAqIFBlcm1pc3Npb25zIHRoYXQgbWF0Y2ggY2FuIGNv bnRpbnVlIGFuZCBqdXN0IGluY3JlbWVudCByZWZjb3VudC4NCj4+ICsgICAgICAgICAqLw0KPj4g KyAgICAgICAgaWYgKCBNUFVfQVRUUl9ST19NSVNNQVRDSCA9PSBhdHRyX21hdGNoIHx8DQo+IEVu bGNvc2UgaW4gYnJhY2tldHMgKCkgfHwgKCkNCj4gDQo+PiArICAgICAgICAgICAgIE1QVV9BVFRS X1hOX01JU01BVENIID09IGF0dHJfbWF0Y2ggKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAg ICAgIGlmICggcmMgPT0gTVBVTUFQX1JFR0lPTl9JTkNMVVNJVkUgKQ0KPj4gKyAgICAgICAgICAg IHsNCj4+ICsgICAgICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlINCj4+ICsgICAgICAgICAg ICAgICAgICAgICAgICJDYW5ub3QgbW9kaWZ5IHBhcnRpYWwgcmVnaW9uIHBlcm1pc3Npb25zXG4i KTsNCj4+ICsgICAgICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArICAgICAgICAgICAg fQ0KPj4gKw0KPj4gKyAgICAgICAgICAgIGlmICggeGVuX21wdW1hcFtpZHhdLnJlZmNvdW50ICE9 IDAgKQ0KPj4gKyAgICAgICAgICAgIHsNCj4+ICsgICAgICAgICAgICAgICAgcHJpbnRrKFhFTkxP R19FUlINCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICJDYW5ub3QgbW9kaWZ5IG1lbW9yeSBw ZXJtaXNzaW9ucyBmb3IgYSByZWdpb24gbWFwcGVkIG11bHRpcGxlIHRpbWVzXG4iKTsNCj4gTWVt b3J5IHBlcm1pc3Npb24/IEhlcmUgeW91IGFyZSBjaGVja2luZyBmb3IgWE4vUk8uDQoNClJpZ2h0 LCBpcyBpdCBiZXR0ZXIg4oCcbWVtb3J5IGF0dHJpYnV0ZXPigJ0/DQoNCj4gDQo+PiArICAgICAg ICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gKyAgICAgICAgICAgIH0NCj4+ICsNCj4+ICsg ICAgICAgICAgICAvKiBTZXQgbmV3IHBlcm1pc3Npb24gKi8NCj4+ICsgICAgICAgICAgICB4ZW5f bXB1bWFwW2lkeF0ucHJiYXIucmVnLnJvID0gUEFHRV9ST19NQVNLKGZsYWdzKTsNCj4+ICsgICAg ICAgICAgICB4ZW5fbXB1bWFwW2lkeF0ucHJiYXIucmVnLnhuID0gUEFHRV9YTl9NQVNLKGZsYWdz KTsNCj4gSGVyZSB5b3UgYWx3YXlzIGNoYW5nZSBib3RoLCB0aGF0J3Mgd2h5IHRoZXJlIGlzIG5v IG5lZWQgdG8gcHJvdmlkZSB0d28gc2VwYXJhdGUNCj4gbWFjcm9zIGFzIEkgbWVudGlvbmVkIGFi b3ZlLg0KDQpnb29kIHBvaW50Lg0KDQpDaGVlcnMsDQpMdWNhDQoNCg== From xen-devel-bounces@lists.xenproject.org Tue Jan 13 11:21:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 11:21:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201483.1517110 (Exim 4.92) (envelope-from ) id 1vfcSQ-00021n-VG; Tue, 13 Jan 2026 11:21:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201483.1517110; Tue, 13 Jan 2026 11:21: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 1vfcSQ-00021g-Qu; Tue, 13 Jan 2026 11:21:06 +0000 Received: by outflank-mailman (input) for mailman id 1201483; Tue, 13 Jan 2026 11:21: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 1vfcSP-00021a-N6 for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 11:21:05 +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 f261ca61-f071-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 12:21:03 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-477a2ab455fso67996685e9.3 for ; Tue, 13 Jan 2026 03:21:03 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d8384646fsm366812425e9.15.2026.01.13.03.21.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 03:21:02 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f261ca61-f071-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768303263; x=1768908063; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Dv2fMYB5hXbUhgUcJfGY2lZ7/ed8hkB0GLSLrm4lgq0=; b=YnsVdG7xrH4KXsT6sreXz7k/IVFeLIfv+NQq8Xl/toneMO0ydQ3+Ir/wSSck8Syxd9 J1EHgi+cD+1O20MAjuQiyT4hL9pE8TGj1WOD720buNjzxwJFbMSxm8DJVDH1Kgxf+U59 P0DmkL68OHMVj8P2f/6WfcPAL3qdZfK6UZa29UD+Pjo2chBeUaRXLrmri2O+1RAFQ4SQ EfiwH+YI/qB2bnyOOvyp9z4+8xzqldPWBrkeROfbHZMw47UNhh8Q5K2lsYzdwCfJIwDw FXBVHedF4lsnxr0uN6caYtiasvZTfm0EKgiZKXNiAk8i5YuMS9kPDeBIicxAhzf4RBh1 64rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768303263; x=1768908063; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Dv2fMYB5hXbUhgUcJfGY2lZ7/ed8hkB0GLSLrm4lgq0=; b=rONbsXq7/1n71yQdsZ8aVHOpZJtU/Ypv+bxdHrowIep9XPnPE07LijWYl4bwecYIwq m16s0E+9qxF9/gzPDyP6fiPDDG7naeDnz9c2W7HACXgb7ndUemCdbpo5DglxID9+f/Cn NfsEoKo/1RTMn8bEJr2XYJ0VV23N1X0xzaI8dZQIVjj9jPp1PMUchJIWBFkFLDF6IkBJ uax9Veioh5/MTQoXqTxsQCjxwaUmk3c9AuIuOWmOaL7iCeZUFbJ7zhLm8LoX7QbPYMOR cZ+upMZMiwWqHmdOFtSsnDnhb7ngLwei/5jJ6tqlra/CfcXh2LtvD3tkEXyrN4K5xvn6 4Plg== X-Forwarded-Encrypted: i=1; AJvYcCUCr8YPZgrjr+loQ+godVC0UA6f/9pzsll2rONiNSGcLMVagVetgcGwtfLRwb/DEI+11FN9RXyf2XU=@lists.xenproject.org X-Gm-Message-State: AOJu0YxVWZS896zRi74Ip5rNiXNbz09jUgqb4y6XMDB5U5E7m6z1VYnm iI2n28BFe1FTj4hqS4CTdoDt8813iTvbfw51c1d2uVs1VxfTm0kS1a7WgYKj5dku7w== X-Gm-Gg: AY/fxX7CEXELSjYNYPz+7ZyVoD8n6asMNUT2O9mW7pLZkqong/Ck3S+1cQraA5o/5KP ONdcZTYzhCLE4WxCo4nIC3NKInMVUKAHK3tZbRFcIRShwTy9+HT7rI5zh5OhMG6hIv6WbQkY95/ 07R3+DSSb4rMXm9/jGZEG1mnBtr2n9p14OKzUi0MMiiM33llTbpItIarHFU/Bohc6RrrIoMmWIu U51uvPAzFeov0W3lIXMEZbbUY9ofKse07agdj56b0J8FLw3D0HvEFczzhFdV9vX0HH4eFxWHjQj hqMrk4C2sTaGaCK0Gg/CeEJFkQh0CraGtsm2pZhWOtstrT895BSf/Xwwk4Cy1Xsb9NG9O/bTYgL IDi9+Y1uzS/OIaveO2vpWoIpRBo74DRe1xQmAkU/oefRKXOTAGHq4uGnloi2FsUDniaI4l+AX+t Ggr8anFrIR8QxVnej8HpahE+vU1ofcMNam5g3MCqWavKzGeQAEfuM/Ss/yDXBXd/PRBfzbKfU/i Us= X-Google-Smtp-Source: AGHT+IGIJRuX67/wERrWdvomKYNqbZi/bFpj1d5NQ9VUq1panRFoHql6VTFIYlOkgVajF2gHQ+D+xA== X-Received: by 2002:a05:600c:1992:b0:477:b734:8c53 with SMTP id 5b1f17b1804b1-47d84b18eecmr263758425e9.12.1768303263194; Tue, 13 Jan 2026 03:21:03 -0800 (PST) Message-ID: Date: Tue, 13 Jan 2026 12:21:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() To: Anton Markov Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> <4a6b6307-9014-4c4c-8c23-3673efa2d1b1@gmail.com> <794c382b-3b20-4d2a-ab70-b24d7fdf88ae@suse.com> <4b03cf36-d2d8-420c-82df-55d6a9ac9d68@suse.com> <6ea436ce-6ecb-47f8-8d8a-98b0badeb14e@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.01.2026 17:41, Anton Markov wrote: >> >> That calls on_selected_cpus(), but send_IPI_mask() may then still resort to >> all-but-self. In that case all IPIs are sent in one go. > > Plus as said, how IPIs are sent doesn't matter for the invocation of >> time_calibration_rendezvous_tail(). They'll all run at the same time, not >> one after the other. > > At the hardware level, no one can guarantee that the processors will > simultaneously respond to the signal and execute your code nanosecond after > you send the ipi. Especially when we're talking about NUMA configurations. I'm > afraid the possible and impossible in the laws of physics is also beyond > the scope of this thread. You did read my recurring explanation beyond the IPI sending, didn't you? Of course IPI arrival may vary across cores / threads. Yet the term "rendezvous" is used because CPUs having received the IPI are then held in a waiting loop, until _all_ CPUs have made it there. Then CPU0 indicates to all of them simultaneously to move to the next step. There's going to again be some variance (especially on NUMA, where the memory write needs to propagate to all nodes), but at least within a single node that should be pretty low. The main source of variance I would expect there would by hyperthreads competing with one another in a single core. > Since further down you build upon that "IPI lag", I fear we first need to >> settle on this aspect of your theory. > > I've already provided the delay logs. It's not hard for me to repeat. Sure, I don't doubt you make those observations. But we're still trying to converge on a theory on what these may be caused by. > 2 hours of work: > >> (XEN) update stime on time calibrate 0, 8564145820102 -> 8565145861597 >> (8565145862216, 0) >> (XEN) update stime on time calibrate 1, 8564145820129 -> 8565145861609 >> (8565145863957, 0) >> (XEN) update stime on time calibrate 3, 8564145819996 -> 8565145861491 >> (8565145864800, 0) >> (XEN) update stime on time calibrate 2, 8564145820099 -> 8565145861609 >> (8565145865372, 0) >> >> 8565145861609 - 8565145861491 = 115 * 3 (3.00 GHz) = 345 lag The log entries aren't in CPU order, and CPUs 1 and 2 actually have identical values on the rhs. That doesn't quite fit what you have said so far. CPU3's value is also lower than CPU0's. > 3 hours of work: > >> (XEN) update stime on time calibrate 0, 22914730829200 -> 22915730869993 >> (22915730870665, 0) >> (XEN) update stime on time calibrate 1, 22914730829073 -> 22915730869889 >> (22915730870693, 0) >> (XEN) update stime on time calibrate 2, 22914730829052 -> 22915730869841 >> (22915730872231, 0) >> (XEN) update stime on time calibrate 3, 22914730828892 -> 22915730869696 >> (22915730872096, 0) >> >> 22915730869993 - 22915730869696 = 297 * 3 (3.00 GHz) = 891 lag While CPU numbers happen to be in sequence here, the rhs values aren't equally ordered. Also really here it is 22915730869696 - 22915730869993 = -297 * 3 (3.00 GHz) = 891 ahead > 2-3 day of work: > >> (XEN) update stime on time calibrate 0, 254477161980127 -> 254478162020920 >> (254478162021549, 0) >> (XEN) update stime on time calibrate 2, 254477161977638 -> 254478162018429 >> (254478162022187, 0) >> (XEN) update stime on time calibrate 1, 254477161978192 -> 254478162018972 >> (254478162022776, 0) >> (XEN) update stime on time calibrate 3, 254477161976832 -> 254478162017636 >> (254478162021394, 0) >> >> 254478162020920 - 254478162017636 = 3284 * 3 (3.00 GHz) = 9852 lag Similarly here. Yes, the gap increases, yet that's not a lag of CPU3 past CPU0, but exactly the other way around. > As you can see, the core lag is strictly determined by their sequence > number. As per above - no, I don't think I can see that. Or maybe I'm misreading the numbers as well as what you have been saying. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 13 11:35:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 11:35:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201500.1517119 (Exim 4.92) (envelope-from ) id 1vfcfw-0003uZ-53; Tue, 13 Jan 2026 11:35:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201500.1517119; Tue, 13 Jan 2026 11:35:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfcfw-0003uS-1c; Tue, 13 Jan 2026 11:35:04 +0000 Received: by outflank-mailman (input) for mailman id 1201500; Tue, 13 Jan 2026 11:35:02 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfcfu-0003uM-Rw for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 11:35:02 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id e2c3f1f6-f073-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 12:34:57 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 56476497; Tue, 13 Jan 2026 03:34:49 -0800 (PST) Received: from [10.1.25.129] (unknown [10.1.25.129]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BE4023F5A1; Tue, 13 Jan 2026 03:34:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e2c3f1f6-f073-11f0-9ccf-f158ae23cfc8 Message-ID: Date: Tue, 13 Jan 2026 11:34:54 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/6] arm/mpu: Implement vmap functions for MPU Content-Language: en-GB From: Harry Ramsey To: "Orzel, Michal" , xen-devel@lists.xenproject.org References: <20260105113503.2674777-1-harry.ramsey@arm.com> <20260105113503.2674777-3-harry.ramsey@arm.com> <40677f79-8e3a-4c0c-876d-d57e9b230eca@amd.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/01/2026 10:33, Harry Ramsey wrote: > On 09/01/2026 14:00, Orzel, Michal wrote: >> >> On 05/01/2026 12:34, Harry Ramsey wrote: >>> +        return -EINVAL; >>> +    } >>> + >>> +    return 0; >>> +} >>> + >>>   /* >>>    * Update the entry in the MPU memory region mapping table >>> (xen_mpumap) for the >>>    * given memory range and flags, creating one if none exists. >>> @@ -357,18 +393,7 @@ static int xen_mpumap_update_entry(paddr_t >>> base, paddr_t limit, >>>               return -EINVAL; >>>           } >>>   -        if ( xen_mpumap[idx].refcount == 0 ) >>> -        { >>> -            if ( MPUMAP_REGION_FOUND == rc ) >>> -                disable_mpu_region_from_index(idx); >>> -            else >>> -            { >>> -                printk("Cannot remove a partial region\n"); >>> -                return -EINVAL; >>> -            } >>> -        } >>> -        else >>> -            xen_mpumap[idx].refcount -= 1; >>> +        return xen_mpumap_free_entry(idx, rc); >>>       } >>>         return 0; >>> @@ -418,6 +443,31 @@ int destroy_xen_mappings(unsigned long s, >>> unsigned long e) >>>       return xen_mpumap_update(s, e, 0); >>>   } >>>   +int destroy_xen_mapping_containing(paddr_t s) >>> +{ >>> +    int rc; >>> +    uint8_t idx; >>> + >>> +    ASSERT(IS_ALIGNED(s, PAGE_SIZE)); >>> + >>> +    spin_lock(&xen_mpumap_lock); >>> + >>> +    rc = mpumap_contains_region(xen_mpumap, max_mpu_regions, s, s + >>> PAGE_SIZE, >>> +                                &idx); >>> +    if ( rc == MPUMAP_REGION_NOTFOUND ) >>> +    { >>> +        printk(XENLOG_ERR "Cannot remove entry that does not exist"); >> Why do we split sanity checking between this and xen_mpumap_free_entry? >> What are the possible region types that xen_mpumap_free_entry is >> expected to >> work with? I thought that it should only be MPUMAP_REGION_FOUND. > > I will move the region checks to xen_mpumap_free_entry since we only > want xen_mpumap_update_entry and xen_mpumap_free_entry to modify our > refcount properties. These functions should then account for all > potential values of MPUMAP_REGION_*. Sorry, after looking back at this code the reason the sanity checking happens here is because we require MPUMAP_REGION_FOUND to be used in `destroy_xen_mapping_containing` to actually remove the region. In `destroy_xen_mapping_containing` we are forcibly setting the region type to be MPUMAP_REGION_FOUND to ensure it is removed and thus we require the check here too. Thanks, Harry Ramsey. From xen-devel-bounces@lists.xenproject.org Tue Jan 13 11:39:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 11:39:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201510.1517129 (Exim 4.92) (envelope-from ) id 1vfck7-0004bc-Ks; Tue, 13 Jan 2026 11:39:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201510.1517129; Tue, 13 Jan 2026 11: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 1vfck7-0004bV-Gl; Tue, 13 Jan 2026 11:39:23 +0000 Received: by outflank-mailman (input) for mailman id 1201510; Tue, 13 Jan 2026 11:39: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 1vfck6-0004bP-Ez for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 11:39:22 +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 7fb4dce9-f074-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 12:39:19 +0100 (CET) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-b872b588774so243786066b.1 for ; Tue, 13 Jan 2026 03:39:19 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b870e33259esm697935066b.8.2026.01.13.03.39.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 03:39:18 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7fb4dce9-f074-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768304359; x=1768909159; 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=WxW/Bi8YXCerp6fENlNPiTLE6uiSEZIC+yyayAUgB0o=; b=iv2+I4fIWQ0Hxx+ARsa/nX4PO0gi8G1MHG8CDGANlZOtmphVCABcERMF9742FKthbY McL3IkEMpzmJrftyuTUklBVNKemutc/sAbHK9RRMSuumvWW68SHq0UokCNP13ypmA8yH 8s6etkM+JMHSLKUFc5UZ33FdhOCKm9CiS8kkSaCzZKyhuJOBZGa7HoOW8wDP5+jT+F7G uqMkdtl8vO4j6sKyTFrUJpOgeQXjUI6V1Ky5kE24clb34KTtINvqTRsILnInvTEpSQhG fLbqjhNZwn2czKS42iWfq55Tmf2iqF0+Da0fl1sO8E3zxarR31tgqYV3UYJKBtKgrs+R KZwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768304359; x=1768909159; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WxW/Bi8YXCerp6fENlNPiTLE6uiSEZIC+yyayAUgB0o=; b=c/G/APdFymOBy1R22LIIdHOsiyNZyuXZeobGucokWgKLWR7KIrLFvaassBdyvOQU3q G5537ocJJrV15aa21yszHd/S2OmwqykwkMxGv3Huv/Yujor4sPG2FNy6aUqN5o+io7GK J78pHrbN/0m3JTDvpRzwjPvZUqrj6tTKNQknjC9iwEWM24FJEdePeoRi3jcn6B6Rhk5d /iLT82LVSr7S/SE6MBboGHWhFRN70DnH53cznlXAiH9r4AF742JFzTLStpy1BSOqps0s rw7JUBbNrANTsWgNcOLBpLuSSnwxZM27TrnAQHVED7tbTEefO/cZJ4x5XmWav/uocnbH OvxA== X-Forwarded-Encrypted: i=1; AJvYcCWDxpJvJZaRN0dpPdXhRJNyIx5hGGW+k5xoBAyNzrCcCctKqdpfniMHNiqkBDkx8L+85dqaKii357k=@lists.xenproject.org X-Gm-Message-State: AOJu0YzMt7Fa9XZTJAxFBoNzHT5SzCxIVwyXQjcWbK981VGOZslfJ3vz RwSRGW6Rq3mFL4zMRJ/s3CJc0oR+DRPGlPTEyplvX++jvaEXY5IVgVxM X-Gm-Gg: AY/fxX7exNUBWYEZQX3ElDh0OzLfcgwEw3FJHSuyadGpbiX8RtmQB5gRhphHSsKqcyR S2LH+zidIg8p9VThGpSWyWQbMrZfrVrdXi0obuYXB2UUQpXdzJ3EDgozTdIwplEgEsPYX0AJ6IL Gl1L1BXkjH3py6U8Ag2UXwveZOSymM2FWm9ZcGeE7iq8BOXrSHprj/mh1VMQF2qAhEpYwSqceMX Wl3+NyII/92ZdMp2zcdX6yJGEp6WcanqBqC2byUlP02uZiRngxWeMDMt7l+FQVNi6upHBAXb03d eyw7jvf9pAtZsrFwM4Xe1mtlgvnkC+ajUXWQak1i8uU2wru8xWgXP73+n3wFDpFQn/ADyt9hOzL FVU4XvzRF++zEFq+KrnGhMivfSJs1q/VS+Dmd/iqkT5NyAGx0Ri90Y33+joAGl0V3F+VjuMWS3e 6OClm/zF3Nii37Cf7FcRZr2biEI5XT9KM2b67/ND+0nx52i+EUD/8OfrZPfjWSOjE= X-Google-Smtp-Source: AGHT+IEjaL8obUVDyMLgiNW/+NkhGXD9GLLfvYNaESBtQmV+V9SwiJY5sb9NDAFAX8npemETX6PmEw== X-Received: by 2002:a17:907:3d88:b0:b87:4bdb:1061 with SMTP id a640c23a62f3a-b874bdb232dmr60506466b.1.1768304359161; Tue, 13 Jan 2026 03:39:19 -0800 (PST) Message-ID: Date: Tue, 13 Jan 2026 12:39:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 05/15] xen/riscv: implement stub for smp_send_event_check_mask() 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: <837c863f5995cc4371e82b481211b053656ec7e7.1766595589.git.oleksii.kurochko@gmail.com> <319e6162-7a5b-4030-ae9f-a86a48e73605@suse.com> <94c0cd09-7aaa-4ae1-913e-57d883916682@gmail.com> <92cfc028-cabd-4686-b6b9-7cc047a909c9@gmail.com> <2786eab5-ff25-4d8d-b0d1-84a1d2727f9f@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <2786eab5-ff25-4d8d-b0d1-84a1d2727f9f@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/13/26 11:22 AM, Jan Beulich wrote: > On 13.01.2026 10:58, Oleksii Kurochko wrote: >> On 1/12/26 6:05 PM, Jan Beulich wrote: >>> On 12.01.2026 17:53, Oleksii Kurochko wrote: >>>> On 1/7/26 4:47 PM, Jan Beulich wrote: >>>>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>>>> @@ -13,3 +14,10 @@ >>>>>> struct pcpu_info pcpu_info[NR_CPUS] = { [0 ... NR_CPUS - 1] = { >>>>>> .processor_id = NR_CPUS, >>>>>> }}; >>>>>> + >>>>>> +void smp_send_event_check_mask(const cpumask_t *mask) >>>>>> +{ >>>>>> +#if CONFIG_NR_CPUS > 1 >>>>>> +# error "smp_send_event_check_mask() unimplemented" >>>>>> +#endif >>>>>> +} >>>>> CONFIG_NR_CPUS is 64 by default for 64-bit arch-es, from all I can tell, also >>>>> for RISC-V. And there's no "override" in riscv64_defconfig. How is the above >>>>> going to work in CI? Then again I must be overlooking something, as the config >>>>> used in CI has CONFIG_NR_CPUS=1. Just that I can't tell why that is. >>>> It is 1 because of the defintion of NR_CPUS in KConfig: >>>> config NR_CPUS >>>> int "Maximum number of CPUs" >>>> range 1 1 if ARM && MPU >>>> range 1 16383 >>>> .... ( all other range props are condtional and there is no RISC-V in dependency) >>>> so for RISC-V "range 1 16383" used and CONFIG_NR_CPUS is set to the minimal of this range, >>>> so it is 1. >>> I fear I don't follow: Why would the lowest value be picked, rather than the >>> specified default (which would be 64 for RV64)? That's what I thought the >>> default values are there (among other purposes). >> But there is no default for RISC-V for config NR_CPUS: >> >> config NR_CPUS >> int "Maximum number of CPUs" >> range 1 1 if ARM && MPU >> range 1 16383 >> default "256" if X86 >> default "1" if ARM && MPU >> default "8" if ARM && RCAR3 >> default "4" if ARM && QEMU >> default "4" if ARM && MPSOC >> default "128" if ARM >> help >> ... > Oh, indeed, that's what I was overlooking. > >> So a value from range [1, 16383] is chosen and based on the code of sym_validate_range(): >> ... >> val = strtoll(sym->curr.val, NULL, base); >> val2 = sym_get_range_val(prop->expr->left.sym, base); >> if (val >= val2) { >> val2 = sym_get_range_val(prop->expr->right.sym, base); >> if (val <= val2) >> return; >> } >> if (sym->type == S_INT) >> sprintf(str, "%lld", val2); >> else >> sprintf(str, "0x%llx", val2); >> sym->curr.val = xstrdup(str); >> >> First initialization of val2 it is the left value of the range [1, 16383],so it is 1 >> and val is 0 (I assume so that it is by initialization 0), thereby val2 = 1 will be >> used as a value for NR_CPUS. > But is this behavior documented anywhere? I wasn't able to find that and it was a reason why I checked the code. > Wouldn't RISC-V (and PPC) better > gain suitable defaults, making explicit what is wanted (for the time being)? > E.g. > > config NR_CPUS > int "Maximum number of CPUs" > range 1 1 if ARM && MPU > range 1 16383 > default "256" if X86 > default "1" if !ARM || MPU > default "8" if RCAR3 > default "4" if QEMU > default "4" if MPSOC > default "128" Maybe, it would be better. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Jan 13 11:54:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 11:54:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201523.1517139 (Exim 4.92) (envelope-from ) id 1vfcyw-0007L6-Qv; Tue, 13 Jan 2026 11:54:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201523.1517139; Tue, 13 Jan 2026 11:54:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfcyw-0007Kz-Nv; Tue, 13 Jan 2026 11:54:42 +0000 Received: by outflank-mailman (input) for mailman id 1201523; Tue, 13 Jan 2026 11:54: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 1vfcyu-0007Kq-HT for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 11:54:40 +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 a2c02691-f076-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 12:54:37 +0100 (CET) Received: from MN2PR17CA0024.namprd17.prod.outlook.com (2603:10b6:208:15e::37) by LV5PR12MB9804.namprd12.prod.outlook.com (2603:10b6:408:303::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 11:54:33 +0000 Received: from BL6PEPF00020E61.namprd04.prod.outlook.com (2603:10b6:208:15e:cafe::40) by MN2PR17CA0024.outlook.office365.com (2603:10b6:208:15e::37) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Tue, 13 Jan 2026 11:54:35 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF00020E61.mail.protection.outlook.com (10.167.249.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Tue, 13 Jan 2026 11:54:33 +0000 Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 13 Jan 2026 05:54:33 -0600 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 13 Jan 2026 05:54:33 -0600 Received: from [10.71.194.215] (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, 13 Jan 2026 05:54:31 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a2c02691-f076-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=uCaP90a0wJtCnN+o6vkhcnmtBK9T+iv2rR+I5phwrPWULPWru+pug0Np2MQD6Rp7d9HslcMFsVbkbaz8P1D4ghRKFSHsOiLP4p+YNdvnh3rK1TpJeMwD8EBy2FlVLR4tS5w1CUN6PrRK21z6NlCrhpnVo6BSYdQZeV06RwvkpQjPBAFqnRzUoOWy3gaekycjvyhVVp5MWcO90Erqr6KKXjDoQvxQ/ZG+o4XkY7pcOCaBWIe3Y2HqwRCEDLQfDFFvMhdOVXLKmabaf8nph477T5ydeF2d1ej1rBOEfjJzODZ0I6oTGTNAjRPui4Du9rkAxAQDVPe3ivz5qEvrPG68PA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nWFwnq/uGaUTjhyQQzwUypW8vL6iA0epU0MrIm4lGiM=; b=ykryeajqrI9xTrhL/VVUTBuMrpBbp/tp1rpofrHVzf2FC19ByLFxvx+rcV8lSA+gXI61mWRjNOY/S4J2KFrJ9c4eFxzmSs5UdUjwv6dIPfFafJfZK4D40OMHROL3L1xyATaArl+IPaNfARx0PV9jLjtu5P9Q1Th+f+kaOcIalBmIPzy4Re5Q0dIMfa5kLx3tSxT+RjAPt324omNBJO33PFzGvRrg9SB6O2xA7yHWL8XqzBkGOzXbMQ9Aub0pzeyrWx48Pkeb5uMIVXptl5m56vVWM2Ot8iipGm4VLVGFmvozEbbP0A2zbys/4YyVpF5rRrV+zEIVrpbch3T38E+2cw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nWFwnq/uGaUTjhyQQzwUypW8vL6iA0epU0MrIm4lGiM=; b=QNCh3kQO9HyzE5Pplv21ef+Q5ocym2aMBQy5AAxjha8W5bX82nyMJluBWG9SzYQpzbz/DHChERVFDn/+lKhyeUtCm2++UMC+5QnSJUqhl+1+Fq/slU5xTQWZaE1ttHcqxTNkYrAKGejOvmTNC0JzrZpkQH81oYRt96NIBtIKO3I= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <84be01b8-9f13-4adf-8613-8658f46f3260@amd.com> Date: Tue, 13 Jan 2026 12:54:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/6] arm/mpu: Implement free_init_memory for MPU systems To: Luca Fancellu CC: Harry Ramsey , "xen-devel@lists.xenproject.org" , Penny Zheng , "Stefano Stabellini" , Julien Grall , "Bertrand Marquis" , Volodymyr Babchuk , Wei Chen , Hari Limaye References: <20260105113503.2674777-1-harry.ramsey@arm.com> <20260105113503.2674777-4-harry.ramsey@arm.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL6PEPF00020E61:EE_|LV5PR12MB9804:EE_ X-MS-Office365-Filtering-Correlation-Id: 5894e9f6-1cf0-424a-04f1-08de529a8493 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|7416014|376014|82310400026; X-Microsoft-Antispam-Message-Info: =?utf-8?B?aXFUNUNmbHFaM0V4SE1wWWtBNUhQbXdQMGJ1dmZIWWw4VjZoRlcvTlRZNmpN?= =?utf-8?B?YitxWThwcVdRQ041K2FSaUc0VzByKzhoTHZyd1Jra0h2TjhnYXpZTzBrbGhN?= =?utf-8?B?Z2hSQVdEYTloQzRPLzAxWlVXeldQK3hTaWt1RlgybGJiVVZtTDdKZ2Y1SGcx?= =?utf-8?B?VWNXQnV0N2JFODY1a1didWZuaStDbmVwTE9McTl3R25nMTlva3FWSjF2OURQ?= =?utf-8?B?MDZzbFRtYjlnbFZZRmZ3dmQ0NExnMDEwR042ZXdabFAzenZmY01xbUVoL1Ur?= =?utf-8?B?TDVJdFgrNVhEZmRxMGF1aWgwSG9weUE1M1ZKMDRneE9haEFYbGlzQlNqNUR1?= =?utf-8?B?RnFrQU11MlhwNjdIdkpQSnFIaDdVdGU5YUNYNHVLMkxQLzdvdVRGNmtoSjRE?= =?utf-8?B?bC9sZndTWFo4RCs4ZEkwZnMxWXZyT1lRM2JLQk9SYkYzeDFtMGh3UEw5Tmpa?= =?utf-8?B?SHZnVGFwaWVHZ2FxaXhIanpucit3TVlmK1N1bTZKWXFXU0taZVlIRktpL0lO?= =?utf-8?B?ckpKblYrVm9GMSthUndEVFkyT25mMW1LcytiUmtqN0kxVHQwbWR6emNGRkNW?= =?utf-8?B?UmRjZjFoNW91L1B0NTIrSER4N0Y1RUdIcHZTdHRpQzd6UXcrbW5EMlE1dnRT?= =?utf-8?B?N0pJVG1ROXdFRGswN2RNM0Q3aGw0Z1N6T1NFNzAwTDZHZHJKM241d0ZCaTRu?= =?utf-8?B?L3ZuUXVoVUpOQytvUWhENXI5SzM2cmVTSGNiZUhMcmpReWVzdkJvZ2IrRVg1?= =?utf-8?B?L2FHY2ZhclBtcDhvZXRSYjkyTjByYVpQN0hYSTJjU2dxaWxvUWQ0RW5mMm9u?= =?utf-8?B?TkxwcHJvYkpSYlFjZ3hXRWtreVIzajF2Yk9ONTVuYzBpUzkrOEpKdEtuTjR6?= =?utf-8?B?anZ2VEFiVGlhWnR0a3JPcVNGYXNxSlVYeEhDb0lOb1VTZ3lORjNPRnkzZUw3?= =?utf-8?B?UVByc3pGaEV6QjcxQWcva1pBZk9zdGFoa2EwSGhIK3lHZE1wNkFCRm9NV09r?= =?utf-8?B?SkRDdlY5b2lHbVFodDlrV0J5RTB0UkVWU2tLWVZSK1J0K2wrcmxWTUZXS0Nm?= =?utf-8?B?QjhvZlMvWFRCUmh4SjRBWWhwdXVIZzhZY0kvYWVVSUVOcnJja1dScWZvaUt1?= =?utf-8?B?WWppSGRrelFmcW03Q2lGMGdFM0VHdjRRNWN1dEJKc3dQczVQWW8zT0NFaGJr?= =?utf-8?B?NmtKM0xwQXVYclZlSVd4UWp4MEJTc01TZVRDOER4OTZwbis0WWJYV092Yk1I?= =?utf-8?B?Y3djcjJGWWRtOTQ3dmwrUmdEeFFsYW5RUlp6TjFvQ1JFRnJGNHVtb01xNDQ4?= =?utf-8?B?SUlGSDNkWnJ4UjdKRlBvR2MwbzU0YWlYcXhtRDBmVzdxQ25xMzVMMzVFaDk0?= =?utf-8?B?cnpFc2ltK0kyZ1VTa29PeGFFQzNXcjZJOHRMYzgzNXJscXVNMkFSUXRyUXZI?= =?utf-8?B?a0QxZ1dVUFUwM3A4d0RGbm9jaUsxTzJJcDJmYVJBWW9qTzFYRFdiQWpzeS9n?= =?utf-8?B?NFpVaTBrdDJaNTdrWXhpOVQyeTFlOXE0MjJ4NGNjak5COXBWcFFzaG1Odmk2?= =?utf-8?B?VlFCNGpkK25HTGgwRTJRVHVPaFFPbEUyZWVhVDlZWHR5a1U1VTQ0RmhXZWw2?= =?utf-8?B?UTVNVytLOEpQditDemdZMTdEemZUd1Btdm9hMnl4Mk5UK0dwY3dlOTFMSUxX?= =?utf-8?B?YnV6cnZWd0RUOVd6RUtiUGhaSUVXVWdOTGpUUUhqd3BGakFJWUpka3NhenNY?= =?utf-8?B?YXdOSEp6SjZlL1VoZUZsZWI5aVVqck9uWENqbXhZOWRqZlJkdy9XUlVDejAx?= =?utf-8?B?VCtaY2Z0dmZTL0JrZjBTRTJqRXVvS0NOYkVCWXFGNUI0R3UvRXFxWGNUd0Nk?= =?utf-8?B?aEswUU9aQ0lpWHZXaUpZbkZyN0pwUUxCQUJLNjNVVUtOeklzY0xkZkFTWi9S?= =?utf-8?B?a3JmU3ZQMnVHM2FnRVFxRmlUVkd3SGJySjdBMTIzV0FjNC9sS0UxcThRd1Np?= =?utf-8?B?bjFrc0huM1BKbFNTaTFzQUowZHdiT1FPaVo3MGpCc3VSbVI0b3dzU3A2MEhm?= =?utf-8?B?MUQ2b0p2RXVQNldVUDNxTnJFeGQ4Q3dJd01BVnV2aUxuNTVNeVhEeVA3eVZv?= =?utf-8?Q?+1Ww=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(7416014)(376014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 11:54:33.5428 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5894e9f6-1cf0-424a-04f1-08de529a8493 X-MS-Exchange-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: BL6PEPF00020E61.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV5PR12MB9804 On 13/01/2026 12:13, Luca Fancellu wrote: > Hi Michal, > >>> >>> -static bool is_mm_attr_match(pr_t *region, unsigned int attributes) >>> +static int is_mm_attr_match(pr_t *region, unsigned int attributes) >>> { >>> if ( region->prbar.reg.ro != PAGE_RO_MASK(attributes) ) >>> - { >>> - printk(XENLOG_WARNING >>> - "Mismatched Access Permission attributes (%#x instead of %#x)\n", >>> - region->prbar.reg.ro, PAGE_RO_MASK(attributes)); >>> - return false; >>> - } >>> + return MPU_ATTR_RO_MISMATCH; >>> >>> if ( region->prbar.reg.xn != PAGE_XN_MASK(attributes) ) >>> - { >>> - printk(XENLOG_WARNING >>> - "Mismatched Execute Never attributes (%#x instead of %#x)\n", >>> - region->prbar.reg.xn, PAGE_XN_MASK(attributes)); >>> - return false; >>> - } >>> + return MPU_ATTR_XN_MISMATCH; >> Later below you don't seem to differentiate between MPU_ATTR_RO_MISMATCH and >> MPU_ATTR_XN_MISMATCH. Therefore I would suggest to keep them as one to simplify >> the code. >> >>> >>> if ( region->prlar.reg.ai != PAGE_AI_MASK(attributes) ) >>> - { >>> - printk(XENLOG_WARNING >>> - "Mismatched Memory Attribute Index (%#x instead of %#x)\n", >>> - region->prlar.reg.ai, PAGE_AI_MASK(attributes)); >>> - return false; >>> - } >>> + return MPU_ATTR_AI_MISMATCH; >>> >>> - return true; >>> + return 0; >>> } >>> >>> /* Map a frame table to cover physical addresses ps through pe */ >>> @@ -357,12 +342,45 @@ static int xen_mpumap_update_entry(paddr_t base, paddr_t limit, >>> */ >>> if ( flags_has_page_present && (rc >= MPUMAP_REGION_FOUND) ) >>> { >>> - if ( !is_mm_attr_match(&xen_mpumap[idx], flags) ) >>> + int attr_match = is_mm_attr_match(&xen_mpumap[idx], flags); >>> + >>> + /* We do not support modifying AI attribute. */ >>> + if ( MPU_ATTR_AI_MISMATCH == attr_match ) >>> { >>> - printk("Modifying an existing entry is not supported\n"); >>> + printk(XENLOG_ERR >>> + "Modifying memory attribute is not supported\n"); >>> return -EINVAL; >>> } >>> >>> + /* >>> + * Permissions RO and XN can be changed only by the full region. >>> + * Permissions that match can continue and just increment refcount. >>> + */ >>> + if ( MPU_ATTR_RO_MISMATCH == attr_match || >> Enlcose in brackets () || () >> >>> + MPU_ATTR_XN_MISMATCH == attr_match ) >>> + { >>> + if ( rc == MPUMAP_REGION_INCLUSIVE ) >>> + { >>> + printk(XENLOG_ERR >>> + "Cannot modify partial region permissions\n"); >>> + return -EINVAL; >>> + } >>> + >>> + if ( xen_mpumap[idx].refcount != 0 ) >>> + { >>> + printk(XENLOG_ERR >>> + "Cannot modify memory permissions for a region mapped multiple times\n"); >> Memory permission? Here you are checking for XN/RO. > > Right, is it better “memory attributes”? Yet in a if() block for MPU_ATTR_AI_MISMATCH == attr_match you already have the same message. ~Michal > >> >>> + return -EINVAL; >>> + } >>> + >>> + /* Set new permission */ >>> + xen_mpumap[idx].prbar.reg.ro = PAGE_RO_MASK(flags); >>> + xen_mpumap[idx].prbar.reg.xn = PAGE_XN_MASK(flags); >> Here you always change both, that's why there is no need to provide two separate >> macros as I mentioned above. > > good point. > > Cheers, > Luca > From xen-devel-bounces@lists.xenproject.org Tue Jan 13 11:55:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 11:55:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201529.1517150 (Exim 4.92) (envelope-from ) id 1vfczO-0007kR-4H; Tue, 13 Jan 2026 11:55:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201529.1517150; Tue, 13 Jan 2026 11:55:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfczN-0007kH-Vz; Tue, 13 Jan 2026 11:55:09 +0000 Received: by outflank-mailman (input) for mailman id 1201529; Tue, 13 Jan 2026 11:55: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 1vfczN-0007cP-6D for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 11:55:09 +0000 Received: from mail-yx1-xb12e.google.com (mail-yx1-xb12e.google.com [2607:f8b0:4864:20::b12e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b4bd3cdf-f076-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 12:55:08 +0100 (CET) Received: by mail-yx1-xb12e.google.com with SMTP id 956f58d0204a3-64476c85854so7307866d50.0 for ; Tue, 13 Jan 2026 03:55:08 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b4bd3cdf-f076-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768305307; x=1768910107; 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=9Us33qgBVO+A1iQtvWJPQe2C4rxDTACfd5FFGkIpXXc=; b=I5Lkq4Y/fSaUME/a7yaOvpiycOiNwmrW9ZOVGc7W97WWHsW2j7PQ0hmmYx5KurEqaA YKfMcW4/PcHG368tm/VHPIc7E2oX6Egk6nVP2wZKShKoeMfCD+T3wlx9tbLFfmFgNwba yVE+X+KOiA48ZJFdXSp17gPPClUvNDbT42kgcwobG7XStQuBszem302HVacoWEth7QNw KdXrY0BTjuGBopBCexsPlDQbeIX3cQF/jw3oIb35rSNM0uSYGyUYRkxHIpmhkMfHwHCh O/CJxFo0ypepJSs2tbJA/J3RmYwzwQV99Q6Lfe68bMygEVU0wibw0lxLgYa3kUNzb39j hFxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768305307; x=1768910107; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=9Us33qgBVO+A1iQtvWJPQe2C4rxDTACfd5FFGkIpXXc=; b=aQVQJeBqqArhWz/TkL96EbOj0hx5c11EVwogBJoAcL10gMS4lUKmFnLz+7IJJsQ6Xj 2ABkcIW2yQPUvZ/MyjTA0NkdskhZ0+gVei5XDFn/VEZjTDj8vgIixAi82D0Rd307/R3l ctzyuEYLondDAtONlSVHR7XzKw/WRtBZ4525taeul3ZIH0rj2knf/9wk4uIdWAqvN233 JesL7Gh79eR98uA1HQz42aioVLbtxJG24+EKH4FPuvdA964w6bT12XDzw/4HUBG8Fd2m 9CxsSAq61hI832nlksyl9lJFBaH2+jpeaup6wamgLcrsGYCy392tA716MI+UghtSgmmE EDhQ== X-Gm-Message-State: AOJu0YyBfZX2Hzazys7ta21oqVT37siuBl2Yy08NmuQ1efnIg/bAhCW+ SyDLZWYijyjBZNDCfAD8IqXrMHWIYbINxy6ygqD/PusLNpb4yGcq99sbSu8p025/6rh6WBWSrUF wvibLf2x0DRvj+wgVRyCq+GJKLzZnDNdKfQ== X-Gm-Gg: AY/fxX7gap1npXv5eTVnj52YpqnEcu/uZNsCYpemMgFibH6IuVmuGiYs4LZipaHn+tb XYRLHKdRQOJ3NpWJXjWVTmlwQXWQdTpmUAWEQMXF1LNxz791bA2sYu2fMiOkAOMTwVQ0tIEY7ay W1V17FfJD8PRZ1p5YItd8KbUlPtrRCRCHWNsoemvT4y+C6UGL2jJ1XxL1+3VN7/auAecJg2RAoV wBHgMCBfaLiwCKrPCTekObvAaS+TBXgWl4lxMQdgG62pbCIvPS8aWmJh+V7A2zI4fmz93o= X-Google-Smtp-Source: AGHT+IHVB62tyqm3pUYJXW8fN3sjX8zI8b9GNXly6vMPbAdICfcNqJ624zYC/JxTVYq5uoUyNcWT6KeMm7RTcY3E7wc= X-Received: by 2002:a05:690c:7341:b0:787:deea:1ba8 with SMTP id 00721157ae682-790b5828f50mr398994227b3.50.1768305306869; Tue, 13 Jan 2026 03:55:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Frediano Ziglio Date: Tue, 13 Jan 2026 11:54:55 +0000 X-Gm-Features: AZwV_QhgtoESeD24oifWcl42CyTbxdjkT5u4ilNc88rsPGempFyWkOECqVLosXU Message-ID: Subject: Re: [PATCH livepatch-build-tools v2] Treat constant sections as string sections To: xen-devel Cc: Frediano Ziglio , Ross Lagerwall , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Konrad Rzeszutek Wilk Content-Type: text/plain; charset="UTF-8" On Tue, 18 Nov 2025 at 10:44, Frediano Ziglio wrote: > > > > 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 > > > > Reviewed-by: Ross Lagerwall > > > > Thanks, > > Ross > > Hi, > any update on this change? Could it be merged? > Any update? Frediano From xen-devel-bounces@lists.xenproject.org Tue Jan 13 12:10:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 12:10:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201564.1517159 (Exim 4.92) (envelope-from ) id 1vfdED-0002j8-Lv; Tue, 13 Jan 2026 12:10:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201564.1517159; Tue, 13 Jan 2026 12: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 1vfdED-0002j1-IR; Tue, 13 Jan 2026 12:10:29 +0000 Received: by outflank-mailman (input) for mailman id 1201564; Tue, 13 Jan 2026 12:10: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 1vfdEC-0001lv-F5 for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 12:10:28 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d79e5570-f078-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 13:10:26 +0100 (CET) Received: from BL1PR13CA0210.namprd13.prod.outlook.com (2603:10b6:208:2be::35) by LV2PR12MB5991.namprd12.prod.outlook.com (2603:10b6:408:14f::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 12:10:19 +0000 Received: from BL02EPF0001A103.namprd05.prod.outlook.com (2603:10b6:208:2be:cafe::af) by BL1PR13CA0210.outlook.office365.com (2603:10b6:208:2be::35) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.4 via Frontend Transport; Tue, 13 Jan 2026 12:10:02 +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.9520.1 via Frontend Transport; Tue, 13 Jan 2026 12:10:19 +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, 13 Jan 2026 06:10:18 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d79e5570-f078-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=c/ChUGSV9ysFJ1ovKnGrhf3STPsmSrsyOZLJYxTPlHkTqDScLszvVtSlSUCa43Q+ByAM43zUZCpRi+r5Z9jCeJYGv3/57D5h2IyIAetHb1Hyd/2GdYr4MfCMK2fVXdXYj9pX0WF9Xyt6pblldgTsdMBNehB6CDf040K2iSu5f65CfDFgBk900CVzjNTsBTnCQdlwsDQ4GSHLUAbFNUiXezXC77yP5XDS70lQHKP+vEG6SGo0nHZ5++xeRjsDombO+PJr9FQsW605WQwpysy5P8hwYriWeX1ww+QAOBBFg5Epeh39xGRov+OiIU8K/f5NU6cSx7qRrp16A9RMn6YYhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hjNoEE2GthoCnN8zbgJAlOqjqa6jb2XEHOuLDiKN3Jg=; b=d1Op28cd8AmL7ONOMsQUmpxFqPXVIgxmnN+Ev3793EUBg2sT3WHRrsL9SsWClnfpY1ajYb+yIBssuneJyeoTbYXt3+dPmnQTPlE/b0cHWFesjoAP4Esrw1kKsGmhKlB3A05NRKB4WeZtdcpfU0++NQ0/UMmNKMLJMo0TNCzZsGRRdC5zZB8XIZ4SnvvPhQMYcjT/aOVUiXWVdFM0uLT7Mlo+KYAdG5f2FExI3XadQZVnCL5utARFZgEUoXQdb3VY+NxKAki24FUdLLPwojudb2SbuuPuiZ2hWx+tb97j1My8gFD+ntMLjNzjjcVsKlyoIHNKNkRSN3lpVz/xLBAw1Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hjNoEE2GthoCnN8zbgJAlOqjqa6jb2XEHOuLDiKN3Jg=; b=eKUCt0/qUM1ZnKVNjbpeOCdvDKAMJrIELy6IcOHlcMJW43QuKy2A7kfCmny2slWQDANTTObZKIDo3ciqxbhZuPgNWAyRvT9Pq598LM7fD8grV8iOL8s0w4ePhFZ/NXqE7zhSJqyEVFQrfmaQiVnpmikxkM6o8wYaPEh3g0HaDDE= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v2] x86: Use 32-bit counter for TLB clock on debug builds Date: Tue, 13 Jan 2026 13:09:58 +0100 Message-ID: <20260113120959.55156-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: BL02EPF0001A103:EE_|LV2PR12MB5991:EE_ X-MS-Office365-Filtering-Correlation-Id: 2abb9a0b-7d02-4e75-9347-08de529cb878 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: =?us-ascii?Q?RVgyaSzUUaZgwNR2Urra/zXWDCWYqEKRVq4BAA8raPpkbdgkgQyYwcXX8NXQ?= =?us-ascii?Q?5zyT8zmE5Pq6+wFaFquJDazWYHBSGj6KDXn404xN0rIqNFR7k+PaosUgk1XI?= =?us-ascii?Q?RPTPWqh8nuKROf3EAFDC6DqUkXrhCa4FPDLBJpertXqi/Yu5RCNZoNl6A0VM?= =?us-ascii?Q?KSXxqKSBU0iOGwrW7c1xbQPid/ZhxuUKHFGzLDYk83PQUxk8HhqvgShEgfcd?= =?us-ascii?Q?U3O1UTyaQzBuUY26HUYkYS1wujsJPux0ryqMOStRq7gnznK0pKXJZKIl+vkn?= =?us-ascii?Q?ZdeWpoGutlKL8fP3D4wJiV9dq/cEye/v0b7k8+n93oGaUFL8lLj7yCYr7u0v?= =?us-ascii?Q?QT60vCt6s6j1pcgVp3tokQGJB0n0O5Qb1fq5YmRJ0whLU7JrPB3Io7DxHo1k?= =?us-ascii?Q?6+49bW7hXpjtLNo8f/2JfmT7iUnZG3MOQIDfU3H6xDa1q5bdcfx3kuEpRz/x?= =?us-ascii?Q?/6qfh42seIB7Bd4zhDiHYFcLaTPmGx4qPoOGZ/Q5fEnKxvA2vtYXrtdUvpTl?= =?us-ascii?Q?aEPWtcfY/c5mD17SxY2ykZF8qqukIqspS69Z6usXnLDmAJWDXPx+DBfddHOe?= =?us-ascii?Q?S6nFLB/rX+dACGxLT1ewToh5KnloDtX8tWmZfWcRw0j+oNA3a84ITssIcJxc?= =?us-ascii?Q?Y9VqDt4vGNhMGOjydlDb7xFVwFzpvlJ12vgUTiaiyK7ev91Ln5SYvHdIOmmR?= =?us-ascii?Q?3Gmcnb0iSfizvApySQ+wKjThuWLmaoOE7L2aDiLGfixy6opVQW582/eaq7yV?= =?us-ascii?Q?fdkvikfCJr95H0bdDrUNtc6WxQ5ywefBEI/eixTJr2U/hqa1Iz17BTASaTmU?= =?us-ascii?Q?WS9VIO4f/0TBecZSf+/J7RuejqMwLZLQSIlmBbvN2nukrPEweRsyI86JBs14?= =?us-ascii?Q?faN6vQyVm4LvF3lUKb9nbppBQno2+ktMz3o/V+5Baz+/NgPqu9TXWMNalcxf?= =?us-ascii?Q?dHKFLIkua7nhMG/787I4XJV+B++H83RQUHGTbxD97zGtQZUVfCMCN8ME0crf?= =?us-ascii?Q?ecehWnNdnM3MDAV4gUJgpluLlaFuIkKS2kqmGQyUmdKzCo82ONmv9p4ftWqw?= =?us-ascii?Q?wzot4+rwpVIFJX1MzyAKl/Srb8xDHWxBBN69T63k2AwlJHfFmYwVwdOVlYdl?= =?us-ascii?Q?cJtOYq6q+YnO11i5K/LeyLIbU/UwnHzKifZi0+AnTJ56EvS6YaJGkq8f2R3r?= =?us-ascii?Q?F17K9YozLokokJjqlCVEwqJFZjIoUhJh6maqJ3Yf+dUGHiL9NTjvTPBZxtoV?= =?us-ascii?Q?uu9uPSapWYBeSjXxdrk1IxnjLK84JqL8QSaDenMLm38/ceqTiD7qh44uMkj6?= =?us-ascii?Q?gysUiCrDmZ86PUvXZ/G/h4SlMcrXheIuZgSzWX0ym8K2ej/o5lx60YvqPPyf?= =?us-ascii?Q?ufpTtCELIwWmzfaaIb3BPuovYQ4P1mAk5FvqiL7fJSb83lL1gPlKOiX1d/xu?= =?us-ascii?Q?nlQ+pUc2zOp390nLIBa8PXUR4eTgIeGlzlqxcRxteJV3CKQ7MA4xY4j1eRgC?= =?us-ascii?Q?SJfGfE9FYQQI4dhn21jF65vUgKK0y5YA6Y/+oBGZwfkYztoexHSU+HfODL0F?= =?us-ascii?Q?wg3W2e9lO8lTJhR4Pec=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(82310400026)(1800799024)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 12:10:19.6118 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2abb9a0b-7d02-4e75-9347-08de529cb878 X-MS-Exchange-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: LV2PR12MB5991 Debug builds traditionally ship with a 10-bit counter for the TLB clock. This forces global TLB shootdowns with high frequency, making debug builds unsuitable for any form of real time testing. Remove this quirk, unifying release and debug under a wide counter. Signed-off-by: Alejandro Vallejo --- v1: https://lore.kernel.org/xen-devel/20260112140851.55590-1-alejandro.garciavallejo@amd.com/ v2: * Remove WRAP_MASK instead. * Commit message/title rewrites. --- xen/arch/x86/flushtlb.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c index 09e676c151..23721bb52c 100644 --- a/xen/arch/x86/flushtlb.c +++ b/xen/arch/x86/flushtlb.c @@ -19,13 +19,6 @@ #include #include -/* Debug builds: Wrap frequently to stress-test the wrap logic. */ -#ifdef NDEBUG -#define WRAP_MASK (0xFFFFFFFFU) -#else -#define WRAP_MASK (0x000003FFU) -#endif - #ifndef CONFIG_PV # undef X86_CR4_PCIDE # define X86_CR4_PCIDE 0 @@ -55,7 +48,7 @@ static u32 pre_flush(void) /* Clock wrapped: someone else is leading a global TLB shootdown. */ if ( unlikely(t1 == 0) ) goto skip_clocktick; - t2 = (t + 1) & WRAP_MASK; + t2 = t + 1; } while ( unlikely((t = cmpxchg(&tlbflush_clock, t1, t2)) != t1) ); base-commit: a2a34d76643e49ccc949296c9a45888034e50b55 -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 12:21:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 12:21:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201588.1517184 (Exim 4.92) (envelope-from ) id 1vfdP2-0004pW-Tj; Tue, 13 Jan 2026 12:21:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201588.1517184; Tue, 13 Jan 2026 12: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 1vfdP2-0004pL-Qt; Tue, 13 Jan 2026 12:21:40 +0000 Received: by outflank-mailman (input) for mailman id 1201588; Tue, 13 Jan 2026 12:21: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 1vfdP2-0004bu-Cb for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 12:21:40 +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 68bf6443-f07a-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 13:21:39 +0100 (CET) Received: from MN2PR16CA0054.namprd16.prod.outlook.com (2603:10b6:208:234::23) by BY5PR12MB4308.namprd12.prod.outlook.com (2603:10b6:a03:20a::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 12:21:34 +0000 Received: from BL6PEPF0001AB53.namprd02.prod.outlook.com (2603:10b6:208:234:cafe::66) by MN2PR16CA0054.outlook.office365.com (2603:10b6:208:234::23) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Tue, 13 Jan 2026 12:21:34 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF0001AB53.mail.protection.outlook.com (10.167.241.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Tue, 13 Jan 2026 12:21:33 +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, 13 Jan 2026 06:21:31 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 68bf6443-f07a-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZOE3n/ylmwFo8M3Ifm/7N8YuOhlkaZULvGMtnIAuEF8b2nxzsENWMBIlf4cfcOzhS1DrdzI/cc0d16y3fnDEwOcKibqfiMcVMT6o/ju/PRYc61y1RJe/vLED/jCa10w+95f5OVCakGHzTej5FDHceAJK8rWyY+dR3bqcTxlrGRbR2lwDD1tMmJyAENVXmxkdaVzg62vRps03JK3ankVkfhNbz/11zkdkG7aCEs/1fphSr2JYcnegbM+9WDqXx+2BwPUlj+Vu4TACpTa+fpirUVNR/R519Fy62gFrgn8x3getEjHscq0AKR5r8V7Mp2Bnm9lfIfBeJ9WtrJwJV6/VpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Hd63tS65+pkJnhvg7m7v40+QJW9Mib6yuJizuBKbNkQ=; b=ijx2UEsvn33k4IPrEd/jUoNVzSMZLjhK8U9kRhLmKTPcWF0j+gONgfNKGxfygp1P13ojOiikHFNBeJ/+giKPnZAqoAvIg1j13o8MdFSfu9JKcK6vzbuCa+I6ckpeFqG/OSzV0yA5sUEJhAjgpncASF82gChVzvOw5HcJnxikXhBM/P7zDTQaCf2ZaiNhfCwfv1W9dnfeCKu3nkoG+mdmlQSpUDXY1sb6KcdGQPz6csWbuaY6IVXm4SxQSrFPM7okNG9HfNOvdEXAF/rHqzRDckS2eJwhS/6Yo2+bTkUs5yM3lYgaB18X+n0h3U59jRIAsR701FVBkX1ajI5Q6dYtqQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Hd63tS65+pkJnhvg7m7v40+QJW9Mib6yuJizuBKbNkQ=; b=OI5L4QVjCi13eqvStaGifek5WQ8sJjD6d59dhCm6HASs7sUN/XcvNmUxD57GBm5XGX6a6LuPhWwhq5jOrAScr3wKaFgvfjavQFZhluqlNcpvbkntzTrYBl6ivbxCn6WKeraBRZLJk90z/mxHecU8xmhwlXTXMblI2gKqgMz1NlA= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v3 1/4] x86/ucode: Fix typo s/mitigiated/mitigated/ Date: Tue, 13 Jan 2026 13:21:01 +0100 Message-ID: <20260113122109.62399-2-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260113122109.62399-1-alejandro.garciavallejo@amd.com> References: <20260113122109.62399-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: BL6PEPF0001AB53:EE_|BY5PR12MB4308:EE_ X-MS-Office365-Filtering-Correlation-Id: 45976c8d-4da6-417a-120b-08de529e4a20 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?Tg1GfHx9uB9ef6jLwB7zQUV3q0AB7tdwL+vMt1ypWdn7do+rJJ7FlkTzU/Qv?= =?us-ascii?Q?RT4CoL2VXSxGBR5ekPSdAN3FInxjbtrGNWtb0KLZTCcC3RgEl9dXn89LnXkF?= =?us-ascii?Q?9aS1SPHMA42cVkCRj7V+mGXI+rRiCWdFCYdd1FpMYLmR5/sdAV4dIDFdONBY?= =?us-ascii?Q?8VJ+zXUryniIGS7HxZtDlmPorJD2tbDTZHwS2G/WU5BgmJeSFvnib6bhH3M3?= =?us-ascii?Q?lHJRwFwOax+B7NDa61mDPvLr56MbH1X2+SMYlbE4dTXi8O9SP7kqgN06P0Jd?= =?us-ascii?Q?pZjH9MNtfT0dXC3JHhcVjmmVh9ayPfgDdFRykPhF3P8DviPakQRfI+91wlQf?= =?us-ascii?Q?Dam3OUb/BgGxRPURlKW/9eo3sGVGTt9GIWKali6KQgBQhStmPY09Z7h3lhAK?= =?us-ascii?Q?i8vZS+heifbuAai21tolG80FffzxxWOVEiQT+hzEwhmk/P8JxrhEQ6X6Nrgh?= =?us-ascii?Q?xRGK5KBORA6RmzmxP8Cw8+9RSX98VTL7m3s0S0cVw1YQXLN1ZirACAMmww+O?= =?us-ascii?Q?MNYpvVXwy+yOuwhlsaYjOViMWdZomgdNYSOcIAhQ+ZAvhH4qf2jCYquxdZcZ?= =?us-ascii?Q?TIfWhc363pCvtZ13qD+3D4R0JTW/274ui2TsmBY9lJMRAR2QbTeTyArz+22q?= =?us-ascii?Q?/2k8K3uvg2oOUfHt157cHsqd0FVjzdTrLh7n06FhfpwuA8LOfzoEKKVhQJjB?= =?us-ascii?Q?u7IEPrwoixb+GUmV+EM0fxVQYv73hSKbhUhwRsuFP8JDM3aORl7f1fHxWUyL?= =?us-ascii?Q?i3MbqKZLjCd8+dg/iaIRqDN9CkAaGcYBLA5ymP6RuZTkUhCQ4Vih+expqA3E?= =?us-ascii?Q?+Kbr0qSXyKaUyLrxaaPqjOTogn3JMxsHif7DVuEoXhyDEZ8QjrHuGSXsd2mC?= =?us-ascii?Q?BZhRqa6zzYNFqDpM/GjLGZSF1tUoGfa1QnKJMN/gQ94Krrd86gQuWLE4Xnvr?= =?us-ascii?Q?22h11E+eM+23HR4DYyC1nPmgjDfiABGyZRazRa/d4FYVKrLKAf8ZdBm+RCJk?= =?us-ascii?Q?DfjquSP3hddrhwaNUdlgVEr7Mu2tCyOPrWMlX9iaiXN1J9qZO05+fsQkQ/bJ?= =?us-ascii?Q?2ljo0+Y5qA0z6oGn89WL7t0YWgqeWRfgLMH5hibllyD1sQFxYcXHpWaaWyig?= =?us-ascii?Q?bnX04vFXSxYpgdJyZu1W4dxbCdhRHszB7HqNog1okkYHeh2FXh+MtClZNbnr?= =?us-ascii?Q?E3A/ydMoBvl4gXqpc+1hD+oxpkUBM3eshSRPImyOD85i8MpNmMVIl9HK7LhG?= =?us-ascii?Q?z9JEOEvhZNmmQg9OMBrSwuoihm5nVw2X+qdK2JkwWYpIA2CGFBiQo2DlMaDc?= =?us-ascii?Q?w71sAQX6gmqCyl097W7t1S3Q+1Ye3Ts/5ZKHhjC8b+qmFPPFnGPfvl5oLwBA?= =?us-ascii?Q?8IOJDOlxf/M+2FhOImdzwOfag4H00K1/5iS9c23tGEw+DkY7WdeX1Vjttn08?= =?us-ascii?Q?4FDDnbb84WkUiVgYGS/E/UHwlEcrey4IAntEFMtLAtY9PjkqCPvgUmB3zg26?= =?us-ascii?Q?FYs7qj4uctozXG0bHzLSps/wVPY8l+EMYB2tkjEI8gEGQORAYsnXJ/OqbHS7?= =?us-ascii?Q?ux5WXe6zLPN7DLNSbk8=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 12:21:33.4664 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 45976c8d-4da6-417a-120b-08de529e4a20 X-MS-Exchange-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: BL6PEPF0001AB53.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4308 Not a functional change. Signed-off-by: Alejandro Vallejo Reviewed-by: Andrew Cooper --- v3: * No changes --- xen/arch/x86/cpu/microcode/amd.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/cpu/microcode/amd.c b/xen/arch/x86/cpu/microcode/amd.c index 2760ace921..71b041c84b 100644 --- a/xen/arch/x86/cpu/microcode/amd.c +++ b/xen/arch/x86/cpu/microcode/amd.c @@ -101,7 +101,7 @@ static const struct patch_digest { } patch_digests[] = { #include "amd-patch-digests.c" }; -static bool __ro_after_init entrysign_mitigiated_in_firmware; +static bool __ro_after_init entrysign_mitigated_in_firmware; static int cf_check cmp_patch_id(const void *key, const void *elem) { @@ -127,7 +127,7 @@ static bool check_digest(const struct container_microcode *mc) * the digest of the patch against a list of known provenance. */ if ( boot_cpu_data.family < 0x17 || boot_cpu_data.family > 0x1a || - entrysign_mitigiated_in_firmware || !opt_digest_check ) + entrysign_mitigated_in_firmware || !opt_digest_check ) return true; pd = bsearch(&patch->patch_id, patch_digests, ARRAY_SIZE(patch_digests), @@ -676,7 +676,7 @@ void __init amd_check_entrysign(void) */ if ( (uint8_t)curr_rev >= fixed_rev ) { - entrysign_mitigiated_in_firmware = true; + entrysign_mitigated_in_firmware = true; return; } -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 12:21:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 12:21:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201587.1517174 (Exim 4.92) (envelope-from ) id 1vfdP1-0004c7-NV; Tue, 13 Jan 2026 12:21:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201587.1517174; Tue, 13 Jan 2026 12:21:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfdP1-0004c0-K1; Tue, 13 Jan 2026 12:21:39 +0000 Received: by outflank-mailman (input) for mailman id 1201587; Tue, 13 Jan 2026 12: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 1vfdP1-0004bu-12 for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 12:21:39 +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 67fa6e01-f07a-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 13:21:37 +0100 (CET) Received: from BL1PR13CA0398.namprd13.prod.outlook.com (2603:10b6:208:2c2::13) by SJ0PR12MB7065.namprd12.prod.outlook.com (2603:10b6:a03:4ae::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 12:21:32 +0000 Received: from BL6PEPF0001AB54.namprd02.prod.outlook.com (2603:10b6:208:2c2:cafe::f5) by BL1PR13CA0398.outlook.office365.com (2603:10b6:208:2c2::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.4 via Frontend Transport; Tue, 13 Jan 2026 12:21:06 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF0001AB54.mail.protection.outlook.com (10.167.241.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Tue, 13 Jan 2026 12:21:32 +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, 13 Jan 2026 06:21:29 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 67fa6e01-f07a-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=hCZSdt+g+kk8uxu/+8pUhFO39A+9o+G0nyKFbsT7hxMKr8+4PPh1jYtyWB1QXQe272IHw2Zc3seK7GhWn7OT0NO9TS7fC9eGcko44SW0iRJqO58SqtHIyqiSV42Vn1XdphHSLcmQIVsVWak8fTIYyHZyJ/6tAOs9MLrFYDQCHOKKtJ/Toqk7QFgUZAGdnH6e7TU26Cd8co/xFsJJSLy9eVwQHJOP1d3FosKLM7ax8n/wV62+zitTKtn6RP6Oyuq7P8rmRsNuxVpTRjI9FURIiSOZ0H2e++dTNrjN8fldfoXymBZr3qjBW1Rd6fhL1jhZ2ydn12qYNI3CSYgwSERecQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+m1iPvZUmvo84mbHL/Cn+u0RykzSub1/cEsen6YwdAU=; b=vfeQcB7l6Azna4EVGFtAiSbgaygh4OMLElwrJXGDCiLkr0rOELKYeBx9SVWsvlt7GJ2kkvSEncFU7UBVKQln5Ymd8ezYgtGlor2d1ls8lUe402VKExvsxU/wRS6K8soPpxK7WALGVqHqfnm4K6fz9ymiBaFqJaNzBiCRy5gKWOXl7G+MtRtLq0PNqq2fjo4dlX0Fcym6TGPcvFbCnd2hwhnGcDjcv7bryvVkZdAtJug/nXQ2XWjqUZ9NLsmyiqvFkx+BNGgkg98kEqTEgZWBFTxhTJ2q0kmWq7Gw14smqXHIWZLft2vGD8J9YsGjko7B7ldvwvHq6aCEcXpUv0f5HA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+m1iPvZUmvo84mbHL/Cn+u0RykzSub1/cEsen6YwdAU=; b=jisB1GYUHNT/SivInIsEt1L1zT/G3xcytHlbClIy5hfB79XmotP8Kfa0MIJ68IMfsJPlEmeRtTmvWybEYAk0RQ3kDbHIX+vKQLJRrHHYfR+NjuPF9MU+QMQET7x2q0I2tX1RPWyuS0msII8UXAexZ3jVVCb8HTyt9Qd2isvXpvE= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Doug Goldstein , Stefano Stabellini , "Anthony PERARD" , Michal Orzel , Julien Grall , "Daniel P. Smith" , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Subject: [PATCH v3 0/4] Add Kconfig option to remove microcode loading support Date: Tue, 13 Jan 2026 13:21:00 +0100 Message-ID: <20260113122109.62399-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: BL6PEPF0001AB54:EE_|SJ0PR12MB7065:EE_ X-MS-Office365-Filtering-Correlation-Id: a7c5f678-d020-4cd4-a60d-08de529e494a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700013|7416014|376014|13003099007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?kaVKAmd3DzcSu0dJlGmeHl2O/mNtzZ3Q+HMPJzLOJYZTtJv0dU3/NPHBGTn9?= =?us-ascii?Q?gtRndF0yqZXfS61vMunQuEzV6BdnTfuLunhifl/kASokJ90kUCIEWTKNV9gQ?= =?us-ascii?Q?llA+U2mhhF44QWK6GBK2PrtUvzPJxFj9AYnad0k8OzklKpyIc1v9N+r8Lkk+?= =?us-ascii?Q?KphzTjsh2VzvSxmqS6ZURmgIseDsIYW+QzWBcqNQiQvMSbb6fAadG2leGSRu?= =?us-ascii?Q?oSsNQh8xP6rhRHA7atxNT3FjGart72XTRgSu5Hez7SbZFDlYfhToIpWY/uuY?= =?us-ascii?Q?0W2w8arVLZ2MYO2Uv67NRyKEKqAE8K+yYJNkay5kvrh8PPpdj3Lkkfe3pO+Z?= =?us-ascii?Q?1xtr2GYtilaj6F8BA7norzvXPrs+qQZWgSZyRcsvbK76tTg/0gx1O7rKtF2e?= =?us-ascii?Q?oyb1akk4whgtyryvM2LuF2zP8/9w9dvU5t3DvMxqeibCYpAACmoBrJ0OO+Xr?= =?us-ascii?Q?6kozCppmAeHuqePXC2M/eG4DxnBHYMA3E3ELigKa2JqNvEZY2xcw3MDr0S/B?= =?us-ascii?Q?YxtAQY0Nno9+TOaHaYrxJ50OuWHqaYW2Y7uGfGUDoIBvy0J5bPihcAdAbbbJ?= =?us-ascii?Q?ZPIOKBOT5V+24nf1wkj0TuCCRFpqn9/E0rFaoWUdXsfVuUiB6VoF0AvkPUQn?= =?us-ascii?Q?xTqOT1+cV7D4E9mtmN8c67VkctmrPH5Z66WGXz+BCKXPZf5JA7aZXZB5K67f?= =?us-ascii?Q?E2jF2mdAfExsp1a31Pjx+55mWCYEk/Szg3ZCBSgOPhCus0rZmoU2rHcNXaFg?= =?us-ascii?Q?x45IpZBOabiz8dm8idCULoSn+XWp4bR8A4u6K5t8R9cL56XX81FatmXMe9FT?= =?us-ascii?Q?EyPP71ulyGQsIEBlgyJgf/7p9d+c5bROMlZdVO1CbasJs+vp7WY3IpujAUSv?= =?us-ascii?Q?aU7UzED9qYjBLHMWQyu9KDVUEUhSE8VNshPbBoDn54XJHYF5xyIrY4vRZdCw?= =?us-ascii?Q?e0/0QCpC7BQUiatMA173Jx8ZIHASv9rGJAlD+aL10qsHFkdQCo7b/utpPlzl?= =?us-ascii?Q?toGPDgJHNObS8qb6Bju2FdFqA2zrmIaZvAiunrv11FjZTMOZqdVDwZCCebmw?= =?us-ascii?Q?kgBxWHVOu3rWiC2wmLCuzy5qXvr/G8iYKEL1jXLnBSUm38jefyAL8ec2ZYvC?= =?us-ascii?Q?CRI0BVHRCfmyTNh1yhFAmxETvhi3TQxQeb30l2pWlD/6EaeCKBvrIG8bs7Hx?= =?us-ascii?Q?vMZ0+3qm0BDFB+5xRd1gX3OR+wMb/IwHobWxl1rK8rAJfiPw7cvVTIK/sD5E?= =?us-ascii?Q?vtzfvwqE34sloxQxiHGsFvME/PuImpBYUrD21hlDp9lo1wxoHRWKlIOdhqhj?= =?us-ascii?Q?cXXY65p3nv/+bW+cSATAuViWE1jMx7XaNSd/V8H9KtBD48KCFqhvmx/GE2Fi?= =?us-ascii?Q?lP23gQKtHgVjwY6UoQ8GUv978EAXdwvPYGHMhFWEzMhCTVUcQCB79m0+wWUH?= =?us-ascii?Q?Cl3S3SCvatSGeQfRv/fUlekuom8Ijnp2R/6XkuzAO5z+9v0eBxCt2BCB3eWs?= =?us-ascii?Q?sNIjPuuolOYTpPVhLAugF7whOsNrTzskgj0L7iJ30pab1ArG7hrpUYE3J9Jl?= =?us-ascii?Q?sm4Mj8Nrk1h+PiBOKAk5eVpFI7PbpKfM56G5dJle?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(7416014)(376014)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 12:21:32.0700 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a7c5f678-d020-4cd4-a60d-08de529e494a X-MS-Exchange-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: BL6PEPF0001AB54.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB7065 Hi, One more day, one more revision. Same as v2 with feedback addressed. v1: https://lore.kernel.org/xen-devel/20251112162219.226075-1-alejandro.garciavallejo@amd.com/ v2: https://lore.kernel.org/xen-devel/20260112150259.74535-1-alejandro.garciavallejo@amd.com/ pipeline (green): https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/2260019646 Cheers, Alejandro Alejandro Vallejo (4): x86/ucode: Fix typo s/mitigiated/mitigated/ x86/ucode: Rename UCODE_SCAN_DEFAULT to MICROCODE_SCAN_DEFAULT earlycpio: lib-ify earlycpio.c x86/ucode: Add Kconfig option to remove microcode loading automation/gitlab-ci/build.yaml | 2 +- docs/admin-guide/microcode-loading.rst | 2 ++ docs/misc/efi.pandoc | 2 ++ docs/misc/xen-command-line.pandoc | 4 ++-- docs/misra/exclude-list.json | 8 ++++---- xen/arch/x86/Kconfig | 16 +++++++++++++++- xen/arch/x86/cpu/microcode/amd.c | 22 ++++++++++++---------- xen/arch/x86/cpu/microcode/core.c | 17 +++++++++++++---- xen/arch/x86/cpu/microcode/intel.c | 11 +++++++---- xen/arch/x86/cpu/microcode/private.h | 2 ++ xen/arch/x86/efi/efi-boot.h | 3 ++- xen/arch/x86/platform_hypercall.c | 22 +++++++++++++++------- xen/common/Makefile | 2 +- xen/lib/Makefile | 1 + xen/{common => lib}/earlycpio.c | 0 15 files changed, 79 insertions(+), 35 deletions(-) rename xen/{common => lib}/earlycpio.c (100%) base-commit: a2a34d76643e49ccc949296c9a45888034e50b55 -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 12:21:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 12:21:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201589.1517194 (Exim 4.92) (envelope-from ) id 1vfdP6-00055Y-9x; Tue, 13 Jan 2026 12:21:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201589.1517194; Tue, 13 Jan 2026 12:21:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfdP6-00055Q-64; Tue, 13 Jan 2026 12:21:44 +0000 Received: by outflank-mailman (input) for mailman id 1201589; Tue, 13 Jan 2026 12:21: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 1vfdP5-0004bR-EI for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 12:21:43 +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 69ffe719-f07a-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 13:21:41 +0100 (CET) Received: from MN2PR16CA0055.namprd16.prod.outlook.com (2603:10b6:208:234::24) by DM4PR12MB6181.namprd12.prod.outlook.com (2603:10b6:8:a9::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 12:21:37 +0000 Received: from BL6PEPF0001AB53.namprd02.prod.outlook.com (2603:10b6:208:234:cafe::a6) by MN2PR16CA0055.outlook.office365.com (2603:10b6:208:234::24) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.4 via Frontend Transport; Tue, 13 Jan 2026 12:21:37 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF0001AB53.mail.protection.outlook.com (10.167.241.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Tue, 13 Jan 2026 12:21:37 +0000 Received: from xcbagarciav01.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 13 Jan 2026 06:21:34 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 69ffe719-f07a-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=r4x9Bz3kINVh/FeVvZq08z/WtS2Uktnn25zZ9RiRErV8A7wa3Wo3DtL5TLJBcfot63psUnvu3MKHetqkecPzGbVM1A3mSshJhx2y9DNg0mVh+89JfDpeeeSUG1RW8FrZCKQaIKoQfei/PnpQ5t7CDY/fzl1uj+laKeLff9zgH78mSTIYzohZ7UX1ko89Qy1i6ICHzf+CUK4oUugHYCH8esnS2kHE5RO4swKbigo+V2yeLO9WWDwFVTyIpKO8abMlvRdTuzH1o7FPJ1v2MBEdZt2FxDmojgr2fyVSVFvdPv6JVpUZtuc0iRJFQWBj3h/JOXg3ozyD1mibZ2TmhaQG/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=dWp8DZG/eGZsi9jg+Gber251xIS5sXUS7XbDSzbTugk=; b=hSFQi6IgwB6RDyrPiVD3eYdxgilO4x/SDOj4avI+YYKo0Ue+ZpXU6WEHu9wkUaC5KEjWK3iSX6rci1RulvCB8+Y/mVbVfO1lR7zXh8J4Sl++NLx7kRulh39DuhLaYS2jMjiMWXEHtrWOn6tj0/DOGAZ4HdIU1hNb+OhSkgtbWgd0Ydi2nE0hIVYzv/94+LA4W1k3e9Zn5+0bNbYGGq2FGlKnQNTOCyi+WHHHhsFpuTgINQYvNwBtFTFv59XAb6PXvDBn4Kjifz93yxRiaEffuuZLV4bROkKjfcna1U+u6Qh3DOOAgAK72U6sC0ahHXtW9CZ9MenMAEVgIBd04jC5tw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dWp8DZG/eGZsi9jg+Gber251xIS5sXUS7XbDSzbTugk=; b=0ycaEQaKymNtbrIpawnq5xhJjJyGJ4c83KIBvnRfi4FdfehMjP42075+Ww3xFGS3Ye9NOfpXKYOy8d/BLwqidJM4OJI/IG62XJd//ifW+ebFQigS0jbp0yOn9Dt5T7e+Xenr0E1NYo7Po4X3ClVYxcrG1CVothNYK0aet1CTxbM= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v3 3/4] earlycpio: lib-ify earlycpio.c Date: Tue, 13 Jan 2026 13:21:03 +0100 Message-ID: <20260113122109.62399-4-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260113122109.62399-1-alejandro.garciavallejo@amd.com> References: <20260113122109.62399-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: BL6PEPF0001AB53:EE_|DM4PR12MB6181:EE_ X-MS-Office365-Filtering-Correlation-Id: d21156ef-730a-4c7c-0e6c-08de529e4c76 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?Ilzf2mVMOrVafu8e4YNN1uKRfS7jZhfexCu/OEhHt3ZtiIzPRRk5V/Ssjzn7?= =?us-ascii?Q?zei7IBltip60vblZEpfBAWcuW7i4olE+9MOAuLhXdxXLoSR2CK/TrHeuN1FR?= =?us-ascii?Q?Loz3yQ3kcAKyEO84cp+vjB07T8LA1I3sxJsLlxzOG7MVee99Ek4zydSWIDcb?= =?us-ascii?Q?N/nVVFU4X+N1xaY6yAUreYYTMqvfB6KBxLQ2Aot0JYmU5XeksUrnTqEblYAH?= =?us-ascii?Q?mCdI/ECSg13lsVpiNbqpbvX6uvNY/wYRjAwtddobKhvRC5el8xG9KcvSzdc+?= =?us-ascii?Q?gDhkeOAQs7D71dIJnfpfafAEZdY6NTfsKwLKW662vBcgYY8XncTo8YlDY4Wh?= =?us-ascii?Q?a48vITU0DNse1HM9vkmPQ1EU/EbJ+ehWfNiiT8rlxefbxFjPFml2S1I+Jlq0?= =?us-ascii?Q?0ojw/8m+ejOOaE97bY9CC3kCav7m9KC1v7ID4I8jspzfuY+YsOJwm11GwEtW?= =?us-ascii?Q?tV2To9DpzTBWDSomIuDhMinIBKTUo2fpakuu3UJA67RB4Tuni7udePebn22F?= =?us-ascii?Q?NvaknS9CGua8U5PIop7pZCQaWcmDRuQr6JgKo+qUNt6dS1gGwd1M88/YU9OP?= =?us-ascii?Q?8dur5zLzsP3E1JAzf9dh5TcJmpgufjICrzOTdsXrRi1PSlhXYVTpds55/dGv?= =?us-ascii?Q?bghz8iDxggGDlAoLZZ7VttfSVP19P4srSIlGzdyTsGlAc0DkfsGwNxPvg506?= =?us-ascii?Q?A9n2iUiDUvi/up8HlAkYI8k7NcRSbzTRKKFmN0axxxBb+2asYlCwUvAnU+DV?= =?us-ascii?Q?/zp4pz49ra7WnEGhV//NlfS5tkBN9BJ5b9B6wmokUBxkERXfxGX0ZYJYWHnQ?= =?us-ascii?Q?EtNKDZiHGMwu3GLWMqm5FsBgeREAwDuKbKy95XBpv61NOmzZnRIcvuTINwEu?= =?us-ascii?Q?zayhVDQMF1VOlsUfHXOtSH7UW7cDwQMnySAdpN8uizqBltMy4jkqL7GC9jsy?= =?us-ascii?Q?hg+HupKdh7mDVKR/tyCaQUpcURMbhF5wBx8t5g0tUWs2t8Ye4DN+CBASVpMb?= =?us-ascii?Q?CeRe5hR783cD5VlPJXUNL0bARSAfGl17VixEWMEXpxy712iIKNlKHpU4VD79?= =?us-ascii?Q?HL037okEqntYwafNnHRwTZ4MeYsoiEX1xdj5Z2x90rj7iynJN7UgX3etPBnP?= =?us-ascii?Q?lHmXBclJTdUV4yp1nCrOz8sXD1ZnGeHHAwuMl0CtbA6KSiIK/7YI6AL41ORv?= =?us-ascii?Q?EcEodlRax5tmKVu9IqQOH4eHqWDufmcFhx/QW98lhtz0V1/XaU/xAJ4TjkSV?= =?us-ascii?Q?R7sfBolqwVc33gGFV9FjnqJq+aeOn5rzOWIX7M4cY6cHZaRR67OeoYN/fzWM?= =?us-ascii?Q?pPv4miW9OX/u8IBlt9rnnTkWPS9zgp8lm7umIhH5zBMT3FzKjTan57vDXigm?= =?us-ascii?Q?ZlTt+MDMN0NGg9G8Em6llbHE9qOGgFSjRzqMrGp0esYBrLN+062bLGnFrEzY?= =?us-ascii?Q?rNPXMf9Cmwz7wmfXdrn7tRuxVD2ctzV5cgPvapHKGzt+Feyom/hN0Z1dwEaI?= =?us-ascii?Q?n1/a8wKxeazXMDxBldarHrq8EGcu8NWTgutQq+asPFJ0IIGBltUoUOWN6L/2?= =?us-ascii?Q?S7/MvMayGuW6gMblPaI=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(36860700013)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 12:21:37.3367 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d21156ef-730a-4c7c-0e6c-08de529e4c76 X-MS-Exchange-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: BL6PEPF0001AB53.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6181 It's only used for microcode loading on x86. By lib-ifying it we can make it go away automatically when microcode loading becomes an optional feature in follow-up patches. Signed-off-by: Alejandro Vallejo --- v3: * New patch. Subsumes earlier conditionalisation of earlycpio.c on CONFIG_MICROCODE_LOADING. --- docs/misra/exclude-list.json | 8 ++++---- xen/common/Makefile | 2 +- xen/lib/Makefile | 1 + xen/{common => lib}/earlycpio.c | 0 4 files changed, 6 insertions(+), 5 deletions(-) rename xen/{common => lib}/earlycpio.c (100%) diff --git a/docs/misra/exclude-list.json b/docs/misra/exclude-list.json index 388397dd3b..2b874dfd3b 100644 --- a/docs/misra/exclude-list.json +++ b/docs/misra/exclude-list.json @@ -121,10 +121,6 @@ "rel_path": "common/bunzip2.c", "comment": "Imported from Linux, ignore for now" }, - { - "rel_path": "common/earlycpio.c", - "comment": "Imported from Linux, ignore for now" - }, { "rel_path": "common/gzip/*", "comment": "Imported from Linux, ignore for now" @@ -225,6 +221,10 @@ "rel_path": "include/xen/decompress.h", "comment": "Imported from Linux, ignore for now" }, + { + "rel_path": "lib/earlycpio.c", + "comment": "Imported from Linux, ignore for now" + }, { "rel_path": "lib/find-next-bit.c", "comment": "Imported from Linux, ignore for now" diff --git a/xen/common/Makefile b/xen/common/Makefile index 92c97d641e..4fc0c15088 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -65,7 +65,7 @@ obj-y += wait.o obj-bin-y += warning.init.o obj-y += xmalloc_tlsf.o -obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo unlz4 unzstd earlycpio,$(n).init.o) +obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo unlz4 unzstd,$(n).init.o) obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o) diff --git a/xen/lib/Makefile b/xen/lib/Makefile index efca830d92..60cfda4dfc 100644 --- a/xen/lib/Makefile +++ b/xen/lib/Makefile @@ -3,6 +3,7 @@ obj-$(CONFIG_X86) += x86/ lib-y += bsearch.o lib-y += ctors.o lib-y += ctype.o +lib-y += earlycpio.o lib-y += find-next-bit.o lib-y += generic-ffsl.o lib-y += generic-flsl.o diff --git a/xen/common/earlycpio.c b/xen/lib/earlycpio.c similarity index 100% rename from xen/common/earlycpio.c rename to xen/lib/earlycpio.c -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 12:21:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 12:21:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201590.1517203 (Exim 4.92) (envelope-from ) id 1vfdP7-0005KZ-Hj; Tue, 13 Jan 2026 12:21:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201590.1517203; Tue, 13 Jan 2026 12: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 1vfdP7-0005KQ-EV; Tue, 13 Jan 2026 12:21:45 +0000 Received: by outflank-mailman (input) for mailman id 1201590; Tue, 13 Jan 2026 12:21:44 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfdP6-0004bR-EP for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 12:21:44 +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 6a4f0484-f07a-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 13:21:42 +0100 (CET) Received: from MN2PR16CA0043.namprd16.prod.outlook.com (2603:10b6:208:234::12) 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.9499.7; Tue, 13 Jan 2026 12:21:35 +0000 Received: from BL6PEPF0001AB53.namprd02.prod.outlook.com (2603:10b6:208:234:cafe::41) by MN2PR16CA0043.outlook.office365.com (2603:10b6:208:234::12) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Tue, 13 Jan 2026 12:21:35 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF0001AB53.mail.protection.outlook.com (10.167.241.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Tue, 13 Jan 2026 12:21:35 +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, 13 Jan 2026 06:21:32 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6a4f0484-f07a-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AilEAogS4ja1pODbCOBOKMS4Cx1w8bFan3u0bIkw+CeuDjNuLz+93FmT+Wyks7M83Hp6sHE9Qc4c7cEIJB3t2KPqC9Cj9XnNs2j3yhbdHlbbYu2l/VJsvN3FbtV3Ib+W+fRiP9gHmwpNhjbdgSt2xq1M+uIhDgyUNtOo7tOg0eB+lGTc6R9BOBW9PzkJ04ADfYPm3qCDN6Xe4UGTeK8cTavtAzUzPBgIq5Dkz+Ki+Gio5YrVx9djkl+CFrDk5EldeFbOdQQwwiSihuRjBf47Pg1AugbZFike4GZK6ZtVWM5ZGBI9anC0pNCEqjkYuXQeURALpnLVp03lloKrdp6psQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hUv6GaP4ZnzcennMc/wtXjho6dE/fymYbH5erIs2GIc=; b=wTJxP/jFTcvfxGh1ey4vOeQztLdcGYWjDxkZbRCs6mTXP8Lx9AFtg1w74AoZAOd+TfRoDHSyEVrTkATPl0snOxFwAuy7aw2cIUSPq02EzqRhozUcqpCh7vrDSe+5cmKatsc1BXFa47mv2jKqYOa5oCMxYUebTFqM/qAPyiy0eOMF5kR4ytS4LsZwiYS+3tuNmKlqcHWDrl8jyLlNGkgWV15yR6Lpu2rYS5+lodtGdpZgztyTGNwS8zxK9c+Iz7N/UK6HjwZMBGYgAC1nDab80Nzoi4LbkHK0oQ8s3wEPvK5bvKBnyyOyWVmGlnG01fWXgfAwMzfuNLuN05TKI06Kmw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hUv6GaP4ZnzcennMc/wtXjho6dE/fymYbH5erIs2GIc=; b=H9aZxTLL/1TTsBN1TPAIUjwj8T8C2bmsTW+NDrtrDiiB7FyP+MI8Y0ju01HzJ7M5dCm2Q8kpmiKVO/q6l4MvbgU+ivOI5GxrU+8eb5TdYziv58wf6Kz72993dApjq+J96p7yY0fcHBBOTxjVf/2PcEnKUeBtqwxDW3DaF6fEnOY= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 , Doug Goldstein , Stefano Stabellini , "Andrew Cooper" , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v3 2/4] x86/ucode: Rename UCODE_SCAN_DEFAULT to MICROCODE_SCAN_DEFAULT Date: Tue, 13 Jan 2026 13:21:02 +0100 Message-ID: <20260113122109.62399-3-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260113122109.62399-1-alejandro.garciavallejo@amd.com> References: <20260113122109.62399-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: BL6PEPF0001AB53:EE_|DS7PR12MB9042:EE_ X-MS-Office365-Filtering-Correlation-Id: 337c51fb-67f2-4f78-dbbd-08de529e4b64 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?YUcsi54qLmSMqVSpk5TKbCSNEg5ZQLpc7p6jYsQZACCm9I6C2pMVULJB6gUA?= =?us-ascii?Q?5xaeirQiJVAggZPrY6hV2mdeZjuIr3Uj6eu+he92/UGCFzbVLn1WrvF7g2nS?= =?us-ascii?Q?tAmPAjedSFieTB3hmw5tFytk1Hp65GcNkKkySBbtZEL8W5Bz57GY+rcUXFZN?= =?us-ascii?Q?9o+0sTlZmP3sv5Q6XWuOt9pHr4zcJTn6eiM/TZZTF+umC2J0wg8qOxSfZjS5?= =?us-ascii?Q?lMXOQeXZr3uacKw0gvPIK1Y1IFXm93cKNAHhPxd+ukiPeGErjCxuIzaY8N/A?= =?us-ascii?Q?dknx+neE0CGjPBt3jmFW2EJtKkQSbcgJ+826hJpY1M3M1gqrLpyEuPUdiGkM?= =?us-ascii?Q?+//oqLCsSRFmAMAMVzJi1ZweT/ztqOMkaZcg406pYsz7dDP656lYL8HhJom1?= =?us-ascii?Q?ELZANx/Mi56efk7XSq+OzkDwMTyWPBpx5avBcJO9SXXOzsd6O1QOZCJwg8Pa?= =?us-ascii?Q?5+nCnMKJmHNRCHvVhWhSZ7N4nqfS0jnsDO8CWPCa7yUJcsjaogbFcPBqdzwJ?= =?us-ascii?Q?ERtWnJBZT8SFkMsDnL4jm2vEMaSIrpL1Jzp7RBl6ZIASo0RvDXjpRn08xj+Q?= =?us-ascii?Q?3PoVSbpHC5W/714s/Utp5vzHHsVkS94Z8kgLGfHi9jM7HILIxGSx9tNRb5MV?= =?us-ascii?Q?lEOmeRRVKBoVOUVNAjerXShIOm1vNUu7IQmwW+DegcuQ2Y7cfpcYtHcIK2yW?= =?us-ascii?Q?/SYMzK8bmDxW001bCFvDV9VUZDaxRXQ4EuJ+LWZlhcPcvUEFSP13HhHhWV49?= =?us-ascii?Q?SQu8r0vUiEwkx192IT+JedRT1sOcNLSchcw5icIKgtkQbgIy4x98BSq32dFx?= =?us-ascii?Q?gLWUbJ+WunK4pEdlKPrXttQn1ZinSc/uLALGMxQmQNZBD0QNtf5MrbLlDsAT?= =?us-ascii?Q?rMiAkQ/tbuGeTB+y8lHuX64hlw6kFTQMgx+Bhcd6SPW3x51fK+LrWy00TsbQ?= =?us-ascii?Q?W9/1XJTHKaHzJ6iT43Cn6bLkt7VZl8HB469XFSvsOu961KJnWPP4DKsWk3br?= =?us-ascii?Q?ZC8GK8aQlPVK2Ymxs4jx5lOoHNWx6DoDoERemxBInmC1RUSluuMM37ODsf+F?= =?us-ascii?Q?9arjnqCPhAeAVWI1HEkZncXxTnDcZHV9ZneozhspSRPQoznbKdaB4WDEuR8d?= =?us-ascii?Q?t4Evwnr59EPCU52RzK2MuObDYzJxxn5uCmRoPo5GzwtmtuQznvApYjRgD0Tx?= =?us-ascii?Q?1OFTe/NKehlK3ZPzi915uC43A/vkoo2ouxxieTr2/ugs6zUySwryyohf83GR?= =?us-ascii?Q?KLjOusdh+/mVEs9ww3wfPHNb1rUy0R43Ze4L13nivnx/EvCLhMxfLLWG4zqa?= =?us-ascii?Q?qjiyX4DwfNlBNcHM745BOzkafCQjtjl0ty66JT6YJe/xu2fBW3dIdXANerP0?= =?us-ascii?Q?af6/wDsIZiLgfo9RYHO96tMWwof0FNpGBWarUz9XqsZMBnlwoNEY4o91HeOr?= =?us-ascii?Q?vIZ6VOeSnc2zGi0XBIGir8+H2P1WtoHHB2oki9BXWrfczKSQ/Awwc8CNVnlZ?= =?us-ascii?Q?LhoYhNgb67jmLgcrWW1iXvOwL9H4xZNH1nuxb42ZZaQLPoDBUmD/dd9Nyjbu?= =?us-ascii?Q?AVjMRi+g1JoveSLgrSA=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(82310400026)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 12:21:35.5954 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 337c51fb-67f2-4f78-dbbd-08de529e4b64 X-MS-Exchange-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: BL6PEPF0001AB53.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB9042 We'd rather have the full spelling in Kconfig. Adjusts every other reference to the name too. Not a functional change. Signed-off-by: Alejandro Vallejo --- v3: * New patch. Previously integrated in larger patch. --- automation/gitlab-ci/build.yaml | 2 +- docs/misc/xen-command-line.pandoc | 2 +- xen/arch/x86/Kconfig | 2 +- xen/arch/x86/cpu/microcode/core.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml index a6fc55c2d5..b69bad9202 100644 --- a/automation/gitlab-ci/build.yaml +++ b/automation/gitlab-ci/build.yaml @@ -310,7 +310,7 @@ alpine-3.18-gcc-debug: CONFIG_ARGO=y CONFIG_UBSAN=y CONFIG_UBSAN_FATAL=y - CONFIG_UCODE_SCAN_DEFAULT=y + CONFIG_MICROCODE_SCAN_DEFAULT=y CONFIG_XHCI=y debian-13-x86_64-gcc-debug: diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 50d7edb248..15f7a315a4 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -2773,7 +2773,7 @@ microcode in the cpio name space must be: - on AMD : kernel/x86/microcode/AuthenticAMD.bin When using xen.efi, the `ucode=` config file setting takes precedence over `scan`. The default value for `scan` is set with -`CONFIG_UCODE_SCAN_DEFAULT`. +`CONFIG_MICROCODE_SCAN_DEFAULT`. 'nmi' determines late loading is performed in NMI handler or just in stop_machine context. In NMI handler, even NMIs are blocked, which is diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index c808c989fc..d5705e4bff 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -331,7 +331,7 @@ config REQUIRE_NX was unavailable. However, if enabled, Xen will no longer boot on any CPU which is lacking NX support. -config UCODE_SCAN_DEFAULT +config MICROCODE_SCAN_DEFAULT bool "Scan for microcode by default" help During boot, Xen can scan the multiboot images for a CPIO archive diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c index fe47c3a6c1..dabdb95b4c 100644 --- a/xen/arch/x86/cpu/microcode/core.c +++ b/xen/arch/x86/cpu/microcode/core.c @@ -101,7 +101,7 @@ static struct microcode_patch *microcode_cache; * location we require that they are not both active together. */ static int __initdata opt_mod_idx; -static bool __initdata opt_scan = IS_ENABLED(CONFIG_UCODE_SCAN_DEFAULT); +static bool __initdata opt_scan = IS_ENABLED(CONFIG_MICROCODE_SCAN_DEFAULT); bool __ro_after_init opt_digest_check = true; /* -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 12:21:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 12:21:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201591.1517214 (Exim 4.92) (envelope-from ) id 1vfdPA-0005dG-Ol; Tue, 13 Jan 2026 12:21:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201591.1517214; Tue, 13 Jan 2026 12: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 1vfdPA-0005d9-LG; Tue, 13 Jan 2026 12:21:48 +0000 Received: by outflank-mailman (input) for mailman id 1201591; Tue, 13 Jan 2026 12:21: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 1vfdP9-0004bu-4L for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 12:21:47 +0000 Received: from DM1PR04CU001.outbound.protection.outlook.com (mail-centralusazlp170100005.outbound.protection.outlook.com [2a01:111:f403:c111::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6c9e9e51-f07a-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 13:21:45 +0100 (CET) Received: from BL1PR13CA0322.namprd13.prod.outlook.com (2603:10b6:208:2c1::27) by CH3PR12MB8484.namprd12.prod.outlook.com (2603:10b6:610:158::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Tue, 13 Jan 2026 12:21:39 +0000 Received: from BL6PEPF0001AB56.namprd02.prod.outlook.com (2603:10b6:208:2c1:cafe::b9) by BL1PR13CA0322.outlook.office365.com (2603:10b6:208:2c1::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.4 via Frontend Transport; Tue, 13 Jan 2026 12:21:27 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF0001AB56.mail.protection.outlook.com (10.167.241.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Tue, 13 Jan 2026 12:21:39 +0000 Received: from xcbagarciav01.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 13 Jan 2026 06:21:36 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6c9e9e51-f07a-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ng+iPC8was9vFPbprLLfnyPjlkaDwzGtD6wR5CSI0Suy1f0iWW/G+2qq2gMkOsvE4vnTHpBrGOjh7+EQ0n/iI09ueRtQr4V1FrohiYgldGRapzXGNTww9xFilQxUlFP90M7KyuvTfgunE44isJcZ4M2d3CYm4ZnwqVd5zuLDcNGd+ZHeddo8KSnb4SQP/LX/3tcnhDEuRiNAXilsO1cyt/nFYaj8bHyNZVwELFAEkP+1FYmDINht0UBDoWKTm7Q+QCTzjLLALP8Z6b2Aj+HNhe+MnlufgMYnTWyAEwB0r7ljrkqOyiDXkWqCe3kmDnYZ8AidJRBb9tQ7KdX+lMct4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=c651OyNI/1pUox+oVe25mxjBq9KfipSq30mm7zQRpPc=; b=Ts95KS6H4YbDoZdfG+qUTmVJviTkLs6HdskxPbZSpkzQqjxoklH0/COcFQLdlJdEh51MnDIxwz75ZZ0k0ufJCoBOBewTZvm7xgeDbmmc1u/DW0lxVcuZClEsEOuZ7LMVXEU/EPzyDSagj/yA7XhkTcuPpZ+FDFRPMwCMPXhbclc0+aGjs5u3Ri42cj5C2mdjWuwlbywUT0FHxb5YsZmxbuVJHyUWr8/oKO/NU4s5oPT/pOOC0o5EVX3qP/Zda2HqHJqNtg3AILXBJn9IxnS1EOMnY7xsZdVpi73xNZl0GLgsfD5aeGDewbtjYeONysUoKjqsuVPm9BD7NRckKptiZg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c651OyNI/1pUox+oVe25mxjBq9KfipSq30mm7zQRpPc=; b=daDN+tUuI0jNWf8KaWQvF801TzhCn/tR10sPJM+4tRiZq8zChWpwNe6/EtvHvfLLpQ3mwNp/HW2wS6LpC032ipIxyKMhitD+2NYYpGdpY4tePIyvzp2Sl/0G0k9jZuWe6uUFtGJ4ANvEw7o+QGd0pICmDzWIhuBADBh2wa5iAcc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Subject: [PATCH v3 4/4] x86/ucode: Add Kconfig option to remove microcode loading Date: Tue, 13 Jan 2026 13:21:04 +0100 Message-ID: <20260113122109.62399-5-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260113122109.62399-1-alejandro.garciavallejo@amd.com> References: <20260113122109.62399-1-alejandro.garciavallejo@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: BL6PEPF0001AB56:EE_|CH3PR12MB8484:EE_ X-MS-Office365-Filtering-Correlation-Id: ff043a9a-1009-434d-2a06-08de529e4d7c 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?M1RBVk9uY2FjbTRaOGNEUktadUFTLzZ4RzRPQ1R4blh2NGJ6NS9xczA1R1pP?= =?utf-8?B?UWNrQ0JJVm9McmxxSU5mS2hyaEJMbXd6aUhkNTRTN01tcEViMFBzRkl4eUJ0?= =?utf-8?B?U2JZWk1KYSt4RmlGc1dTblRXOFlXQXBOSmhJK1o5Q2JCYUhEbnhZMFZidlB0?= =?utf-8?B?WjVDeTRNMGFOWmtwZ256MndvRk13N3dPRmNnRk91eCtxd1d4NDk4MzVlTnpi?= =?utf-8?B?TEFCTml2UG1CL29VMm05eVdYSnUzaEtaOEJVRWJkM3BkdXpMZTJrMm9GbnVu?= =?utf-8?B?V2FKYldKUkdKS2xMcVorbkpNZkFiVUdiN1NFMVEybVJ3TUhzY25RaC9GVmlw?= =?utf-8?B?ay8yWUhsRmVjN2JMSURWcDR4MGNJZ1JQR2lBTjZaY2NyaFhwNlkxUGpSZW5w?= =?utf-8?B?a09aem1ZdGNBaE5tVlhQUjh1WS9HK3lZeVUyU1FoU2hMYkRkWGZLZ2JlRFNN?= =?utf-8?B?UWxMR09DN3dpUXN2blI0azRuelBxSXlzNWZtU05zMVlTU0NCUzRXdnN3NWh6?= =?utf-8?B?d0xrbTNJcEVhNFZ3M1VVb2FXcFBsVGxzMXU3NFlCOXRLby9lOFZBNDdybldB?= =?utf-8?B?aHVwMTIvUWt5QWJCQ041d1VyZTczTXRhVFByVVFSSzNzNVRJNGxva2oybHJQ?= =?utf-8?B?aHkrWVY0ZjJyRytRakNrTkdhYUx2bHBWK0l2cEpxNWNUY2xadDMxVUIvSlM1?= =?utf-8?B?RjUyblBWQVdiaDNZVWlzSzcrRnhkZXVBT3NkL1hRbVlpZU1IY3pvb25RWUZu?= =?utf-8?B?T01CRURLS09ZMUczbnlFRlpZN2tvUzJzTlBTb3EzU3pkTVdiNDBZSUh0aWx4?= =?utf-8?B?c0VxTFpIdHpRQlVnS2VVTUFBWTVZRGJQVFYySEIveXZRenlKL3R5T3NoQVh4?= =?utf-8?B?OUl0Z1lTMHJMQ0dIOUtOWXJ3OC8vb25pTWRsZGxPa0J3cFpFK0lneTI5ZFJm?= =?utf-8?B?UFlaYUwrSW1TY3RxYjVPaWlKbGlDWXZPRlI5RkpSZ1p1dTQ4ZHMzR2EyZmcw?= =?utf-8?B?RXZEZDN6bGVYQUh0eWlDcXhob3V6UzFTSDF2NElGZWZITFZWVmV3YjVWamdn?= =?utf-8?B?Ny8zMXVpMmxaR0g4anRwNDMydFdMeE9SZTJyWXpaeFdCeDRCdFNSem1ONWlv?= =?utf-8?B?bUxYVGhvbDA4OGtyVGdaQk9YVU5DbU9uZkk4N0tiSDZvV2pDTjJaWTJXK1BP?= =?utf-8?B?SFo5aG5GUFpqYmVuVWlLZG1IaVVvOHkrSmgzM0JnM0ppb1VSa05pVy9sM1oz?= =?utf-8?B?d1ZXNWlpUkxHVGhNNVh4Mm1EeEtTYWRXUHBxNzZGc2dVSzJYYXpSNTIvS0NV?= =?utf-8?B?d2szbVhKV3lITC9YZHp6RVJRUmdZN0dBRVh2WEZEOFptTW9MSTNQY24xcFo3?= =?utf-8?B?L2NoZE55ajVwRGtMV1pRNW1INFJnOE91NzU1QTh3Ulo1aVhsYTB4ODk0cEI0?= =?utf-8?B?TWFEZ1JmTkpSeE9NNW5pdVhGZnhIalJQOHFlY3JWcVB2RjFtVldpYnpCRW1W?= =?utf-8?B?Z0o2WXRqM0VxUHVlR2dCNlVvSHZZM0VtSFNTQzdJaktrY2Z0Mmh0ZnFualhS?= =?utf-8?B?RzZ4MVd4d010U2l0VFlSaEhIYXpxZGNsM0ZlSXlPT0pyei8rbitySmM1WHVo?= =?utf-8?B?TStvMi92UnFFRk5OSzhnNUNHbkZQeFpkaW0yNjFSVnh5UEF1QVAwTHVYZFg1?= =?utf-8?B?RjF2REtFQnlIWWlMMVp3U05qUU5SdWJEZUliVW11dmJhbzRyT204WkRIQk5s?= =?utf-8?B?Y1FuUERoSFg0ZndYa2t2UlpjQXFvRUVrRFV5SGZnWEFsb295eTdSS0kwSVcy?= =?utf-8?B?YjcyT0dwaUFxS0I4cTZTdmI1dU9VQzJvRFNLTG9iREpUS1YvSXYvbjU3bWhM?= =?utf-8?B?MUp5YXNiOHljZEFoSk1oSTRRY1J1ZHNSTVVKVGFveHFxME55NHRxYVdwVy83?= =?utf-8?B?cmIyY3lVUFd0aVN5QjRwUVdObWgxOGp1T09nazBCVThoQVFaM09reWxGcFpP?= =?utf-8?B?Z29YcE8xaDFvQy85eldRaFpSbjFCdC9pWU04cC9JWnQvMWJXeElFaVJZdSt6?= =?utf-8?B?QlNpOWliZVRVTHpDWnNlM3dEUERlcWMybGc2dXZKLzkvYWJ3S2d1OXNhelps?= =?utf-8?Q?Whh4=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(376014)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 12:21:39.1043 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ff043a9a-1009-434d-2a06-08de529e4d7c X-MS-Exchange-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: BL6PEPF0001AB56.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8484 Amend docs to reflect ucode= command/stanza depend on MICROCODE_LOADING being set. The new MICROCODE_OP() is a conditional setter for the microcode_ops struct. By using IS_ENABLED() there ratehr than ifdef we allow DCE to remove all statics no longer used when microcode loading is disabled without tagging them with __maybe_unused. Signed-off-by: Alejandro Vallejo --- v3: * Moved MICROCODE_SCAN_DEFAULT to a separate patch * Added doc change to admin-guide * Added Andrew's suggestion for Kconfig help text * Inlined can_apply_microcode() macro in core.c * Kept the platform-ops, gating them on CONFIG_MICROCODE_LOADING through the new MICROCODE_OP() macro. --- docs/admin-guide/microcode-loading.rst | 2 ++ docs/misc/efi.pandoc | 2 ++ docs/misc/xen-command-line.pandoc | 2 +- xen/arch/x86/Kconfig | 14 ++++++++++++++ xen/arch/x86/cpu/microcode/amd.c | 16 +++++++++------- xen/arch/x86/cpu/microcode/core.c | 15 ++++++++++++--- xen/arch/x86/cpu/microcode/intel.c | 11 +++++++---- xen/arch/x86/cpu/microcode/private.h | 2 ++ xen/arch/x86/efi/efi-boot.h | 3 ++- xen/arch/x86/platform_hypercall.c | 22 +++++++++++++++------- 10 files changed, 66 insertions(+), 23 deletions(-) diff --git a/docs/admin-guide/microcode-loading.rst b/docs/admin-guide/microcode-loading.rst index a07e25802f..148bc8559b 100644 --- a/docs/admin-guide/microcode-loading.rst +++ b/docs/admin-guide/microcode-loading.rst @@ -23,6 +23,8 @@ TSX errata which necessitated disabling the feature entirely), or the addition of brand new features (e.g. the Spectre v2 controls to work around speculative execution vulnerabilities). +Microcode loading support in Xen is controlled by the +``CONFIG_MICROCODE_LOADING`` Kconfig option. Boot time microcode loading --------------------------- diff --git a/docs/misc/efi.pandoc b/docs/misc/efi.pandoc index 11c1ac3346..c3fb1f3a30 100644 --- a/docs/misc/efi.pandoc +++ b/docs/misc/efi.pandoc @@ -104,6 +104,8 @@ Specifies an XSM module to load. Specifies a CPU microcode blob to load. (x86 only) +Only available when Xen is compiled with CONFIG_MICROCODE_LOADING. + ###`dtb=` Specifies a device tree file to load. The platform firmware may provide a diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 15f7a315a4..866fa2f951 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -2748,7 +2748,7 @@ performance. ### ucode > `= List of [ | scan=, nmi=, digest-check= ]` - Applicability: x86 + Applicability: x86 with CONFIG_MICROCODE_LOADING active Default: `scan` is selectable via Kconfig, `nmi,digest-check` Controls for CPU microcode loading. For early loading, this parameter can diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index d5705e4bff..61f58aa829 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -331,8 +331,22 @@ config REQUIRE_NX was unavailable. However, if enabled, Xen will no longer boot on any CPU which is lacking NX support. +config MICROCODE_LOADING + bool "Microcode loading" + default y + help + Microcode updates for CPUs fix errata and provide new functionality for + software to work around bugs, such as the speculative execution + vulnerabilities. It is common for OSes to carry updated microcode as + software tends to get updated more frequently than firmware. + + For embedded environments where a full firmware/software stack is being + provided, it might not be necessary for Xen to need to load microcode + itself. + config MICROCODE_SCAN_DEFAULT bool "Scan for microcode by default" + depends on MICROCODE_LOADING help During boot, Xen can scan the multiboot images for a CPIO archive containing CPU microcode to be loaded, which is Linux's mechanism for diff --git a/xen/arch/x86/cpu/microcode/amd.c b/xen/arch/x86/cpu/microcode/amd.c index 71b041c84b..86706a21a6 100644 --- a/xen/arch/x86/cpu/microcode/amd.c +++ b/xen/arch/x86/cpu/microcode/amd.c @@ -561,11 +561,11 @@ static const char __initconst amd_cpio_path[] = "kernel/x86/microcode/AuthenticAMD.bin"; static const struct microcode_ops __initconst_cf_clobber amd_ucode_ops = { - .cpu_request_microcode = cpu_request_microcode, + .cpu_request_microcode = MICROCODE_OP(cpu_request_microcode), .collect_cpu_info = collect_cpu_info, - .apply_microcode = apply_microcode, - .compare = amd_compare, - .cpio_path = amd_cpio_path, + .apply_microcode = MICROCODE_OP(apply_microcode), + .compare = MICROCODE_OP(amd_compare), + .cpio_path = MICROCODE_OP(amd_cpio_path), }; void __init ucode_probe_amd(struct microcode_ops *ops) @@ -574,7 +574,8 @@ void __init ucode_probe_amd(struct microcode_ops *ops) * The Entrysign vulnerability (SB-7033, CVE-2024-36347) affects Zen1-5 * CPUs. Taint Xen if digest checking is turned off. */ - if ( boot_cpu_data.family >= 0x17 && boot_cpu_data.family <= 0x1a && + if ( IS_ENABLED(CONFIG_MICROCODE_LOADING) && + boot_cpu_data.family >= 0x17 && boot_cpu_data.family <= 0x1a && !opt_digest_check ) { printk(XENLOG_WARNING @@ -614,8 +615,9 @@ void __init amd_check_entrysign(void) unsigned int curr_rev; uint8_t fixed_rev; - if ( boot_cpu_data.vendor != X86_VENDOR_AMD || - boot_cpu_data.family < 0x17 || + if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) || + boot_cpu_data.vendor != X86_VENDOR_AMD || + boot_cpu_data.family < 0x17 || boot_cpu_data.family > 0x1a ) return; diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c index dabdb95b4c..efaf808f1a 100644 --- a/xen/arch/x86/cpu/microcode/core.c +++ b/xen/arch/x86/cpu/microcode/core.c @@ -58,7 +58,7 @@ */ #define MICROCODE_UPDATE_TIMEOUT_US 1000000 -static bool __initdata ucode_mod_forced; +static bool __initdata __maybe_unused ucode_mod_forced; static unsigned int nr_cores; /* @@ -104,6 +104,7 @@ static int __initdata opt_mod_idx; static bool __initdata opt_scan = IS_ENABLED(CONFIG_MICROCODE_SCAN_DEFAULT); bool __ro_after_init opt_digest_check = true; +#ifdef CONFIG_MICROCODE_LOADING /* * Used by the EFI path only, when xen.cfg identifies an explicit microcode * file. Overrides ucode=|scan on the regular command line. @@ -162,6 +163,7 @@ static int __init cf_check parse_ucode(const char *s) return rc; } custom_param("ucode", parse_ucode); +#endif /* CONFIG_MICROCODE_LOADING */ static struct microcode_ops __ro_after_init ucode_ops; @@ -469,7 +471,7 @@ struct ucode_buf { char buffer[]; }; -static long cf_check ucode_update_hcall_cont(void *data) +static long cf_check __maybe_unused ucode_update_hcall_cont(void *data) { struct microcode_patch *patch = NULL; int ret, result; @@ -613,6 +615,7 @@ static long cf_check ucode_update_hcall_cont(void *data) return ret; } +#ifdef CONFIG_MICROCODE_LOADING int ucode_update_hcall(XEN_GUEST_HANDLE(const_void) buf, unsigned long len, unsigned int flags) { @@ -645,6 +648,7 @@ int ucode_update_hcall(XEN_GUEST_HANDLE(const_void) buf, */ return continue_hypercall_on_cpu(0, ucode_update_hcall_cont, buffer); } +#endif /* CONFIG_MICROCODE_LOADING */ /* Load a cached update to current cpu */ int microcode_update_one(void) @@ -658,7 +662,7 @@ int microcode_update_one(void) if ( ucode_ops.collect_cpu_info ) alternative_vcall(ucode_ops.collect_cpu_info); - if ( !ucode_ops.apply_microcode ) + if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) || !ucode_ops.apply_microcode ) return -EOPNOTSUPP; spin_lock(µcode_mutex); @@ -678,6 +682,7 @@ int microcode_update_one(void) */ static int __initdata early_mod_idx = -1; +#ifdef CONFIG_MICROCODE_LOADING static int __init cf_check microcode_init_cache(void) { struct boot_info *bi = &xen_boot_info; @@ -734,6 +739,7 @@ static int __init cf_check microcode_init_cache(void) return rc; } presmp_initcall(microcode_init_cache); +#endif /* CONFIG_MICROCODE_LOADING */ /* * There are several tasks: @@ -898,6 +904,9 @@ int __init early_microcode_init(struct boot_info *bi) printk(XENLOG_INFO "BSP microcode revision: 0x%08x\n", this_cpu(cpu_sig).rev); + if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) ) + return -ENODEV; + /* * Some hypervisors deliberately report a microcode revision of -1 to * mean that they will not accept microcode updates. diff --git a/xen/arch/x86/cpu/microcode/intel.c b/xen/arch/x86/cpu/microcode/intel.c index 281993e725..ba99f4ffdc 100644 --- a/xen/arch/x86/cpu/microcode/intel.c +++ b/xen/arch/x86/cpu/microcode/intel.c @@ -408,17 +408,20 @@ static const char __initconst intel_cpio_path[] = "kernel/x86/microcode/GenuineIntel.bin"; static const struct microcode_ops __initconst_cf_clobber intel_ucode_ops = { - .cpu_request_microcode = cpu_request_microcode, + .cpu_request_microcode = MICROCODE_OP(cpu_request_microcode), .collect_cpu_info = collect_cpu_info, - .apply_microcode = apply_microcode, - .compare = intel_compare, - .cpio_path = intel_cpio_path, + .apply_microcode = MICROCODE_OP(apply_microcode), + .compare = MICROCODE_OP(intel_compare), + .cpio_path = MICROCODE_OP(intel_cpio_path), }; void __init ucode_probe_intel(struct microcode_ops *ops) { *ops = intel_ucode_ops; + if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) ) + return; + if ( !can_load_microcode() ) ops->apply_microcode = NULL; } diff --git a/xen/arch/x86/cpu/microcode/private.h b/xen/arch/x86/cpu/microcode/private.h index e6c965dc99..1167b79db1 100644 --- a/xen/arch/x86/cpu/microcode/private.h +++ b/xen/arch/x86/cpu/microcode/private.h @@ -93,4 +93,6 @@ void ucode_probe_intel(struct microcode_ops *ops); static inline void ucode_probe_intel(struct microcode_ops *ops) {} #endif +#define MICROCODE_OP(x) (IS_ENABLED(CONFIG_MICROCODE_LOADING) ? (x) : NULL) + #endif /* ASM_X86_MICROCODE_PRIVATE_H */ diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h index 0194720003..42a2c46b5e 100644 --- a/xen/arch/x86/efi/efi-boot.h +++ b/xen/arch/x86/efi/efi-boot.h @@ -295,7 +295,8 @@ static void __init efi_arch_cfg_file_late(const EFI_LOADED_IMAGE *image, { union string name; - if ( read_section(image, L"ucode", &ucode, NULL) ) + if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) || + read_section(image, L"ucode", &ucode, NULL) ) return; name.s = get_value(&cfg, section, "ucode"); diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c index 79bb99e0b6..a55060e662 100644 --- a/xen/arch/x86/platform_hypercall.c +++ b/xen/arch/x86/platform_hypercall.c @@ -309,22 +309,30 @@ ret_t do_platform_op( case XENPF_microcode_update: { - XEN_GUEST_HANDLE(const_void) data; + ret = -EOPNOTSUPP; + if ( IS_ENABLED(CONFIG_MICROCODE_LOADING) ) + { + XEN_GUEST_HANDLE(const_void) data; - guest_from_compat_handle(data, op->u.microcode.data); + guest_from_compat_handle(data, op->u.microcode.data); + ret = ucode_update_hcall(data, op->u.microcode.length, 0); + } - ret = ucode_update_hcall(data, op->u.microcode.length, 0); break; } case XENPF_microcode_update2: { - XEN_GUEST_HANDLE(const_void) data; + ret = -EOPNOTSUPP; + if ( IS_ENABLED(CONFIG_MICROCODE_LOADING) ) + { + XEN_GUEST_HANDLE(const_void) data; - guest_from_compat_handle(data, op->u.microcode2.data); + guest_from_compat_handle(data, op->u.microcode2.data); + ret = ucode_update_hcall(data, op->u.microcode2.length, + op->u.microcode2.flags); + } - ret = ucode_update_hcall(data, op->u.microcode2.length, - op->u.microcode2.flags); break; } -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 12:29:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 12:29:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201648.1517223 (Exim 4.92) (envelope-from ) id 1vfdWh-0007ge-Mv; Tue, 13 Jan 2026 12:29:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201648.1517223; Tue, 13 Jan 2026 12:29:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfdWh-0007gX-Jx; Tue, 13 Jan 2026 12:29:35 +0000 Received: by outflank-mailman (input) for mailman id 1201648; Tue, 13 Jan 2026 12:29: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 1vfdWg-0007gR-7z for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 12:29:34 +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 82b48425-f07b-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 13:29:32 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MN6PR03MB7549.namprd03.prod.outlook.com (2603:10b6:208:4ff::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 12:29:28 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.005; Tue, 13 Jan 2026 12:29: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: 82b48425-f07b-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DdawEElySxKa6ltDCnhL0pmNKPrirIgDbbarUI02viUMhQwtkueV2ozZqvXT6OJNWOG2ZlpQ03cSkOvEW0SZWu9aQhNHmmo4mtDHcYBSKk43h2qJ1vBIxHU506mLbiJnUaD2aa/hjAfWEXyuLtl7Dv1uB2Oyk9H7duuKV4GaXIO00x+GW4vK2+DCeqmypSYJ40LE9tEwEjExsvcf/3UlYNfM+RCpxDTbLUhpV4Lg8K2nqfOZp7jp9MxUU+T24I5cofR113TDGes5oSo6keePCLKku8+L5VGpCv/DrRu+MsdrHakVVzjUzm4giBF+ejL0WiTkOLxUMbst9gNDg/FadQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=y6bD/w6JXot9y4TDrlAFH+egyNANng1WkJ8ahwGb/tg=; b=w/cS/RHEynN5cnUlbyHQ3KR2s8uyiaTEG6NF66g+fKerYdkgGshYdM+gBaB6tn7fX2Y6D1Rlc1hQvokAWUXN2Mmrz8O+WCa3NW0NJVEQqbxDgvEdRr8L3YpD/gJZrrO9yS30JaqHaM1TN40NyBx0n8e8cJRhqcn9loFqGV0KyW2I7prElS5dwmbpNgp9W085iulFZQ68bsVabEPSQXKO17wLL0ecTdv+6Llu3eOC/4+xwgNaEqi2GYzontstx4bgmKJw57W8heMnwXR0Gtot+WpYbXIUTDV01JJqzGB1XxAQWwxqGK5cYERvk79f+PqgizWbiRq9dOmzX/rPxTvdiA== 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=y6bD/w6JXot9y4TDrlAFH+egyNANng1WkJ8ahwGb/tg=; b=oSDf28rD0vjYx/5T5MXWnHWnpyHOw0ejTJ+fAzGquo9MWP/dfxAqoew9RljjiWgeOj5EW9PhUEH0FiK+LkmnNK5nwgKPuW5US5Thr2qT8o9HrIPwCZixzKJt95MHq7NtKteAQGL0t2ThGqC5l8IlC0+mCrybwzd5XQGG9p+2WGw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <5735aa32-0840-4fda-82ce-27a3f63af628@citrix.com> Date: Tue, 13 Jan 2026 12:29:24 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Doug Goldstein , Stefano Stabellini , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH v3 2/4] x86/ucode: Rename UCODE_SCAN_DEFAULT to MICROCODE_SCAN_DEFAULT To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260113122109.62399-1-alejandro.garciavallejo@amd.com> <20260113122109.62399-3-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260113122109.62399-3-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LNXP265CA0029.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5c::17) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MN6PR03MB7549:EE_ X-MS-Office365-Filtering-Correlation-Id: bbf0d48c-b8ab-45d0-07eb-08de529f6536 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?Qnk1cGc1SDhJaWJwdVZkWFZZS3ZHVkdqWFJSRjArZ1lac002VlVMYmluWmFJ?= =?utf-8?B?VDE2R2lvRytoSmYwcmFGaGo2MjhSUzN4SFg1R3Z6LzRwN212S0VpUUc3TjJh?= =?utf-8?B?U203Q2J0WnBQbFBxRmFpa2NHblpxZXRjdGRTbG1xOUFMalZlc2M2R0pSMXhk?= =?utf-8?B?N0JpZWo1TER6SUxXYStUN2p3R2RzR1lodktHZ2NvN0VCdE5uY0RQTEJDUXdW?= =?utf-8?B?ZCtubWUrY2ZOeE43czFRbXVYckNUWklpajNydCt6NFFlVno2OUhNUW8zd3pF?= =?utf-8?B?c3ZWRnhrRDcyWGxKTHpkMDcxNTJYdzFJRWpLTUFUSHlObHNtblRzcnpzallV?= =?utf-8?B?NTViSmYyWTdmWVNGYUdrNmxFdzhRTHZSbWUzc2c0WWtrZlF6VHVPQUxLNjN3?= =?utf-8?B?USt4amlvYlFWMjBmOTlRMktvS2diSFpLeXp2WVhTdFQ0LzNZNC9NRzkrQWs5?= =?utf-8?B?V2lsSFp6RVNoR21vKzVzbTlESTdRM3dJQnE3azZ2VW9objV2TGhHM3UrTTY0?= =?utf-8?B?S3o0TUFaRFhySmFCZTFabEdwZktOQUpLQmpNc2tKS0NjZklhclJNZk9FemZH?= =?utf-8?B?bElUd3I0MTZ6TEhTa2swOEFERVhlQUFpeDlobkU0VjV3VE5pcGE2TUZSeFk4?= =?utf-8?B?ZWg2V3F6SXVjdWlrQjRGK21hb3NQQiswaXlQTUZMUGk0dmdrVGJpQzU3ZUpi?= =?utf-8?B?NHJrejZnTFNOUlE0T3h0YUVkNUQ3NmZBNVVvbU8vdFhVU0JJQmxvelppdHZ4?= =?utf-8?B?MnE0TERSWXZXVFdFaGJZbmF5NytwMzExbUZDTTV0UUFFRnhKZ2hXOFBKVS9M?= =?utf-8?B?VXk0QkhLNXNyV1oyMmRwQW5kUERyVDYwaVQ0ODJsK1NES1lKN0huZkJlMjRq?= =?utf-8?B?cFMzTEhzU0NKNHRIUDZmOEJDWXNLcFFUWUpVQ2wvNnl4UllwUFdOTXhuZVRU?= =?utf-8?B?YVdiYjJMeTJBUnZOSzNJaml0QXVueDc1QlNXKzJLSW4rZnc0NXRLUmRjaVp3?= =?utf-8?B?MkRUTElaaGc0czlBZy9Hcmt0V2pqaFBHZUpTbmdKK0hpdmp2UGtzZ2RIWHVk?= =?utf-8?B?Um5pcVk5VjlFcG5qbVlZU0lCVlBSbitSbGF4bWtOWU5kTU83UDFHS0RFK250?= =?utf-8?B?bDZhZUhrQ0xpTHd2aHFLWkJubE8wYldyR2d4aDkvTGxZc2s1VnIxT0NtU2NP?= =?utf-8?B?SlA4UTFJZEhEYW9QMG4wRnlFOFppMEpYSThBWG90WG1WWGFZL296Q3RZRW9B?= =?utf-8?B?WG9VL2FmOVROS2N6bm1XK3kwUzRhcVBmS1ZMcDJJUHhMRGlqZFYrYkMrMHpj?= =?utf-8?B?NTgrNFYrcmkxT0t3d0F3eEszZXlFdjdjaXozaDRTZTB2Zk1KYjVITXExUE9Q?= =?utf-8?B?TldDVU0wbytwaVFZTEozcWVNQklJRGpENVJoNGFsT08yaXh0dlVCNFh4ME10?= =?utf-8?B?dzdwTlF1djBQSEVTUlZibXdFUGdCL2RyT21GK3hHaXBqRklUTk5zNUNRa1pj?= =?utf-8?B?aE52a0oxcjE4dk5FZzVtTHRkUnM1ZnpjMVZPVEtLT25SczVEckZGWFRNeHNI?= =?utf-8?B?WVF5RXREd0FackNkN2RGUmpLRlEyc3RrSWxHdVNJYmFiWkkzbHRZbHRMUVVi?= =?utf-8?B?di96Rm5uSnFBQjRtSEk4b2NyMktLcVpxZ0IxUG9MWVV6eldLQ1ZWakp4bzZC?= =?utf-8?B?eE14MktXRm1EWGdzSWNhQnRYaHFqM1M1VTBLV0h3eklaWnFHTkl5TXdwOHBx?= =?utf-8?B?R2cwbTJKVmY2NzF3dWUxcWpRUkpxbFdYa0NTRTc0ejRmYTRjSFc1TFR3cTZX?= =?utf-8?B?MjE2SWF2VVU2Y2dYbmlzWWpiYUpRYkNWdjBkc2ZoZHhoaFE3RXl4YU9IZWZC?= =?utf-8?B?NnVReHBmRWZCQlY2WC9MOWZOMS8vL2JSOWl4czBlbjlTbExXUlZwSExBN1Nn?= =?utf-8?Q?cdz9cwbslU6LGNm/z8IHUyyU/j6TDmXW?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UG84SlRIL3g2QS9iYUMyU1NhMm1oY20vUFVrMkxVRTNValdwclVNOEh6YzdZ?= =?utf-8?B?WGFEUlAwTDF2aXJDeTFlWVZoNk85Z003a3QrUUtxZ2swUlI3R3VSZDlzSlVY?= =?utf-8?B?ZWR2WjZqMkxwM3V5SFB3anlCak4vUW9vZk80UHRyY1R2T3RULzhJbjRHd3My?= =?utf-8?B?M2ZXOUtUclRsK2krZk1xdFBDNGVHM0RhNERrNm51Zi8xVlRWdmN5MzFoZDd2?= =?utf-8?B?OUtsaHpxaWo2TzNBaEhDTENrZ3BiUXNwckVoaTBzWGZXelFUcGloekZ5RmlE?= =?utf-8?B?aWUrZTljOFZvWGVTSlZ0OThXWWl6clNKNEROUU1BR1J0QWRxRVFlZitWMTJI?= =?utf-8?B?cGZWallwUG91NGg2YXVQRnFYT3NsWFc2Y0hBaW1vTENsUnk5MTZiUXV1aDgv?= =?utf-8?B?bmpUZVg4MVFuaDRSaG8rdldSU2g5SzRGNDYyQlg0Sjd3ZTJieG5pQ1ZIdC9l?= =?utf-8?B?ZW5FeDlVZGpiZi9GQWpPdUhXd1YyTmNSbFBYOWRNZ093US9BU3BZN0FKVzZ5?= =?utf-8?B?V3FSVkNLOU9pM09qamdXVFR2RzNvY2t5TytCaTJlQkg4Y0k2eG5PQlppT3hR?= =?utf-8?B?eDZjWFQ5UWNHMVVWbmJ5NjgwaU1LODFEVGJKTkFUa1QzMERZKzNhZDlsck4z?= =?utf-8?B?WklXS3Y4bGlKbXQxclBlU2RGb0xaM1doQ0lLa3htVG4zMVpNYmYybWIrMDFS?= =?utf-8?B?VUJCQVlGS0dNZ3FDVE14R3llY20vTHNYNzl3OFhLYXdlMWUrYTVIbzFhd2Fi?= =?utf-8?B?ZDU2NkxFb05PcVFBZmVoWVJEaDFGSitsWmZ1T0QzdllSbWRrMGRhVTBEVTQ5?= =?utf-8?B?ZkVwWUlMMWQ2MlZBTGxNLy9wL0p5ZjZlYktJaWpOcGFQdFV6ZHJQbUpWblQ3?= =?utf-8?B?cklNRS9LS0pDZHFYT01DdXVmdDdkTnNaK1cxZGQyODhPdERiREIxVVlBQ2Jw?= =?utf-8?B?U2l0cTdLYXZnSHlxUnkvb2JMaTdGaDJrMTYvek1WYmY2UkNOU1huTE9YOXZy?= =?utf-8?B?RmVla2p2OCsyRjRxUDhGK1BMcURuTVVoVjZ3QVpiMWVVVU1TbThlR0l0UUtw?= =?utf-8?B?L1lRd3RFWmhiZWRKOUNDSE1lQ050V0VLYXdEKzdaQVF6ZmZWQmpVcE13WXMx?= =?utf-8?B?L3hXblhkYmhpdlZIOHZTdWNKeDNnZGE4K0toYXJBQkxZMzdkN2hlcDdyZXFx?= =?utf-8?B?aVpCT2V2TEs3ZVJyZ2ZQa0IyTmpCdUpydjJnd3RNUW9KZzNna1BhbWhjYktQ?= =?utf-8?B?YTA0UGFrclc2aXNDWGhWUXNadW1vYjZqSWVpUXJhT3Y2T1BoTldlaGx4NVB3?= =?utf-8?B?U2pOdjl6YzU0dlVHL3M5SzJ2SFFHQ0VpVXBrRmwxdk5kVW5GaGZ1SWFCcE9P?= =?utf-8?B?VTQwaFF0VEJ1eTlxMEtjVnNCOVl4VVZDR01sTjZvZDRYeXZXMGtITlpmV2dq?= =?utf-8?B?cUFzUndGU1R3Z00reFBROW5ZbVowZnd1ZGp1SkZUaVdtc1NkUDVTZS9RNW55?= =?utf-8?B?UkNBR295ZWU0d0YwbnRhMHZWYTd6clk4YTd0SUdLTHJWMlk3TDZQN05sa1h3?= =?utf-8?B?K1R3MHk0L2tVZGRzRmUyOFZoQVdhV1ZiZzhVSHVvQUxmVmlabVU1enNHSG13?= =?utf-8?B?MFN5aE1tRlZaK3RKVUcvY3F2RjNtL1hmZUd0c2JEalBFci9Ic2VVdmpOR0po?= =?utf-8?B?eEgwYTY2SkJQL2JlYUd4a3BZbUVmandobCs3VWp6Ym15TTdNREc4N3RJYnhD?= =?utf-8?B?WmJuTDZLWEVTMnBuUXZhaVdhR2EyYkIxQVNheWdQOUFadllUalN5OURtZnBZ?= =?utf-8?B?cUFPWE5BbXcraUU0VmRYa2dFaVJVcytDKzB1Q1dHOFloWHpzK1lHb3Jyb2Nt?= =?utf-8?B?cnNqS0w1YXQ3dWgxSHp2MGo0Vld4YUk5QlJQY1lsbzRUZW9XQWppamJXQUpp?= =?utf-8?B?VXBXQzdFTi9CWjBiZzBXaHlseFJVV2tvejgyalMxcEM4eW51RjdwKzJMSk1j?= =?utf-8?B?VGtMRFhmdWlrNDZ5dktFQnNtYXUvRk1mMTZlZUVrcWVuUnpjb0YzOUdnRkV4?= =?utf-8?B?eGtqRTNGcWltbXMxOTVYR0xOMkFIL1lPbS9FU1VqRFh0NUxJWVBMZ1NESDl0?= =?utf-8?B?UkZCZUo4QWY3Zm5BeUNmOFZWMkxvcHN2TjhQaW85UCtRTHZZR3JaVkp5b3Zr?= =?utf-8?B?eWN3K1BTUUlRYnJxTWxhVzVVdE55U3h6TkFKbzBwekJid0ZZbGhDQ29hejkv?= =?utf-8?B?dW43NW5wSXZpelBMTVF3NlZMQXowZmJkcXA3dW5pckNCQlB3d0J4TTVWU2li?= =?utf-8?B?MmdCMGlVMW1IQW4waEhZMTEwL3AwWDVHSnB5MXRLQVEzamNkSDk5dz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: bbf0d48c-b8ab-45d0-07eb-08de529f6536 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 12:29:28.6491 (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: n1Ox6mvn1Js/NHItrZMaPyT40oxX8o+HFbRhAeyVsyKiXXQrbq25UsBgbwD3wApfYOyTUqIlSiTZQ7uQV11ON66jXn/M1NI74LJbs+agP1w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR03MB7549 On 13/01/2026 12:21 pm, Alejandro Vallejo wrote: > We'd rather have the full spelling in Kconfig. Adjusts every other > reference to the name too. > > Not a functional change. > > Signed-off-by: Alejandro Vallejo Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Tue Jan 13 12:35:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 12:35:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201660.1517234 (Exim 4.92) (envelope-from ) id 1vfdci-0000ni-CI; Tue, 13 Jan 2026 12:35:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201660.1517234; Tue, 13 Jan 2026 12: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 1vfdci-0000nb-7i; Tue, 13 Jan 2026 12:35:48 +0000 Received: by outflank-mailman (input) for mailman id 1201660; Tue, 13 Jan 2026 12:35: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 1vfdch-0000nV-8a for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 12:35:47 +0000 Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [2607:f8b0:4864:20::62d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 60847301-f07c-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 13:35:44 +0100 (CET) Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-2a09d981507so48547365ad.1 for ; Tue, 13 Jan 2026 04:35:44 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 60847301-f07c-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768307743; x=1768912543; 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=Ny3fIW64a8n6LNuRuq9w3JproVg2pbuStVj1bgw/1jY=; b=cXinUNxLUHGjGfHfhw2cEOjIdYlBawMl85hKTJIw08h8w6sU2cRWsEa1asTUAXzMPM N9Z/+8/gFqR3jfi6yYWajF/MbM2JuiLidLb+oBuiaN7emWaUDiHUkVW/T+caS+xlOmWx P+D/TqGdZVGDkWgbc4xFJdWSQrC/LXx6ox9R2aVixvcwpXoyqt2OzhKXDM4VbjIZxaqG dEDJNjYcx2LJDmPdBtiaAK4qDAP6ErmCvykyjISUPxAjIPel0+PsJGgIcXHdq7vwwXz7 jIb9j+cPAYOAnTgc+ot1g8vqDqH2LKoegGsK8B+/zgVV+7Dr+vUfjkz+dBB8tMyM8WM2 +4iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768307743; x=1768912543; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Ny3fIW64a8n6LNuRuq9w3JproVg2pbuStVj1bgw/1jY=; b=a2SmixTS/PynEObdRSJWJ3Psh7mbPJQlIJ0u5MqNM/TYjMxYPJ9f78D3mIc7QkNvG3 iew5XkW6xmELhStZ0BtF7jYoJuA1zRhkheiyhG37EUfdVbYcbMcuTlwsieuSMKNPFNZ8 D35bqWPjyP3EN+FiIeO+OvmQVkj08QLiinoIjme/SiEkHDCOfLaPtZj4EmPb+po6QMnD xXKtOSlxVX5wpvKaHBnZ2g7rdow97NAx9g/u0OoM+rozUyYKDEEdzqojVBEGtPsJkBtI n8OjWxxkTBZeWedsDncoYtVXsdrrSyIR9tpb6gzm4io+4nj4rvskp3Iypz3yN1dOMTmI DLtQ== X-Forwarded-Encrypted: i=1; AJvYcCU8vH7gHCsnzSqLPcNHn8sgxMJ+5I9qjK5rhh3nZnpBntPh8s3z8UPp2S7hlVanVXhp/ob6SnoNf/Q=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz5j0ETuY+RJ4Ad3t/S/M58jyXyyygS7Ga/B3lwlpl2VmdyTsJy mAoGSXqLONsvtwbw2IDaAJskiltwgpKK9kztQyH/ePZVEeG6+MX0uZ5x4DcWHX1+fFsdchpfR4X nrB71ljwZcrXygro/hn73Q973YqtjODQ= X-Gm-Gg: AY/fxX6+p8aCTf6QUQOc7f4e9fRwS9Btv5d/k2NlpwspuY7aSGs0d59VMIuvw0ib7r+ hb5o8kolxbbpM7lSehwCL558R7kU6FDwImEnGPhYAmw/J+4afF5mdpd6DRl/R3ZdOKevwY5XKxu 8I70VQmv6cIzmg7Psw+THPBWA172HszEPjNdJHxzRgAkfwH1hUiq9Am3vqk8OnfUasFFs6JKUxQ p38JZoGDcaqzWIXOyxfKWOvQlTJt5c10kR9qutsEoT2KIFgtQZG3/XnR3kaiDssTkvemjqBtOh8 7hrFmh8= X-Google-Smtp-Source: AGHT+IECiNf0+0iVPZhsREN4UnvfMdi7iEU51O0n4w27xGEEEwflBKIky7oxFV7+coYJOD9CoMTJ8S4EgfpnJxqlJvk= X-Received: by 2002:a17:902:fc84:b0:295:592f:9496 with SMTP id d9443c01a7336-2a58b5015afmr23183315ad.20.1768307742594; Tue, 13 Jan 2026 04:35:42 -0800 (PST) MIME-Version: 1.0 References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> <4a6b6307-9014-4c4c-8c23-3673efa2d1b1@gmail.com> <794c382b-3b20-4d2a-ab70-b24d7fdf88ae@suse.com> <4b03cf36-d2d8-420c-82df-55d6a9ac9d68@suse.com> <6ea436ce-6ecb-47f8-8d8a-98b0badeb14e@suse.com> In-Reply-To: From: Anton Markov Date: Tue, 13 Jan 2026 15:35:31 +0300 X-Gm-Features: AZwV_Qgzeunb-h-9WuEQeTPRhtsdcHFLBYMj31NUMoR7eJYuWhGK_MX9B6MP7jE Message-ID: Subject: Re: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() To: Jan Beulich Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="000000000000d9dad50648443a5d" --000000000000d9dad50648443a5d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You did read my recurring explanation beyond the IPI sending, didn't you? Of course IPI arrival may vary across cores / threads. Yet the term "rendezvous" is used because CPUs having received the IPI are then held in a waiting loop, until _all_ CPUs have made it there. Then CPU0 indicates to all of them simultaneously to move to the next step. There's going to again be some variance (especially on NUMA, where the memory write needs to propagate to all nodes), but at least within a single node that should be pretty low. The main source of variance I would expect there would by hyperthreads competing with one another in a single core. Yes, I saw it. I'm not trying to dispute your understanding of the situation. The difference may be small, but it adds up. Sure, I don't doubt you make those observations. But we're still trying to > converge on a theory on what these may be caused by. > I can't tell you exactly what the main cause of the delay is. I can only list possible factors: 1. Rounding error, which varies for each core; 2. Delay in IPI delivery speed (even at the hardware level, signal delivery shouldn't happen simultaneously, and some cores may have interrupts disabled); 3. CPU frequency boost, which allows some cores to execute code faster. On modern CPUs, this doesn't affect the TSC frequency, but the problem is that the counter will be read at different times. 4. The initial difference in TSC counter values, which for cores within a single CPU should be no more than 100 ns. In the case of NUMA, no more than 1000 ns; I can't speak about percentages; I wasn't involved in CPU development, but there are many reasons not to allow cores to compete in sequence increment speed. The log entries aren't in CPU order, and CPUs 1 and 2 actually have > identical values on the rhs. That doesn't quite fit what you have said so > far. CPU3's value is also lower than CPU0's. > While CPU numbers happen to be in sequence here, the rhs values aren't > equally > ordered. > Also really here it is > 22915730869696 - 22915730869993 =3D -297 * 3 (3.00 GHz) =3D 891 ahead > Similarly here. Yes, the gap increases, yet that's not a lag of CPU3 past > CPU0, but exactly the other way around. > As per above - no, I don't think I can see that. Or maybe I'm misreading > the > numbers as well as what you have been saying. > During the first few hours, the situation can be blurred due to possible race conditions. After two days, it becomes more or less clear: 254478162020920 (core 0) > 254478162018972 (core 1) > 254478162018429 (core 2) > 254478162017636 (core 3) The lower the core number, the more it pulls ahead. It's possible that this is indeed related to which core is most heavily loaded (which one activates CPU boost more often). In my configuration, the first three cores are dedicated to DOM0, and the fourth is reserved for virtual machines. The first core ends up being the most heavily loaded due to interrupt handling, etc. I can also add that after replacing get_s_time_fixed with scale_delta, the difference stops accumulating. At this point, it's clear to me that the problem is the use of previous last_stime values. The nature of this CPU behavior is unlikely to be understood at the software level. Of course, all the processors I tested on have the constant_tsc, nonstop_tsc, and tsc_known_freq flags. On Tue, Jan 13, 2026 at 2:21=E2=80=AFPM Jan Beulich wro= te: > On 12.01.2026 17:41, Anton Markov wrote: > >> > >> That calls on_selected_cpus(), but send_IPI_mask() may then still > resort to > >> all-but-self. In that case all IPIs are sent in one go. > > > > Plus as said, how IPIs are sent doesn't matter for the invocation of > >> time_calibration_rendezvous_tail(). They'll all run at the same time, > not > >> one after the other. > > > > At the hardware level, no one can guarantee that the processors will > > simultaneously respond to the signal and execute your code nanosecond > after > > you send the ipi. Especially when we're talking about NUMA > configurations. I'm > > afraid the possible and impossible in the laws of physics is also beyon= d > > the scope of this thread. > > You did read my recurring explanation beyond the IPI sending, didn't you? > Of course IPI arrival may vary across cores / threads. Yet the term > "rendezvous" is used because CPUs having received the IPI are then held > in a waiting loop, until _all_ CPUs have made it there. Then CPU0 > indicates to all of them simultaneously to move to the next step. There's > going to again be some variance (especially on NUMA, where the memory > write needs to propagate to all nodes), but at least within a single node > that should be pretty low. The main source of variance I would expect > there would by hyperthreads competing with one another in a single core. > > > Since further down you build upon that "IPI lag", I fear we first need = to > >> settle on this aspect of your theory. > > > > I've already provided the delay logs. It's not hard for me to repeat. > > Sure, I don't doubt you make those observations. But we're still trying t= o > converge on a theory on what these may be caused by. > > > 2 hours of work: > > > >> (XEN) update stime on time calibrate 0, 8564145820102 -> 8565145861597 > >> (8565145862216, 0) > >> (XEN) update stime on time calibrate 1, 8564145820129 -> 8565145861609 > >> (8565145863957, 0) > >> (XEN) update stime on time calibrate 3, 8564145819996 -> 8565145861491 > >> (8565145864800, 0) > >> (XEN) update stime on time calibrate 2, 8564145820099 -> 8565145861609 > >> (8565145865372, 0) > >> > >> 8565145861609 - 8565145861491 =3D 115 * 3 (3.00 GHz) =3D 345 lag > > The log entries aren't in CPU order, and CPUs 1 and 2 actually have > identical values on the rhs. That doesn't quite fit what you have said so > far. CPU3's value is also lower than CPU0's. > > > 3 hours of work: > > > >> (XEN) update stime on time calibrate 0, 22914730829200 -> 229157308699= 93 > >> (22915730870665, 0) > >> (XEN) update stime on time calibrate 1, 22914730829073 -> 229157308698= 89 > >> (22915730870693, 0) > >> (XEN) update stime on time calibrate 2, 22914730829052 -> 229157308698= 41 > >> (22915730872231, 0) > >> (XEN) update stime on time calibrate 3, 22914730828892 -> 229157308696= 96 > >> (22915730872096, 0) > >> > >> 22915730869993 - 22915730869696 =3D 297 * 3 (3.00 GHz) =3D 891 lag > > While CPU numbers happen to be in sequence here, the rhs values aren't > equally > ordered. > > Also really here it is > > 22915730869696 - 22915730869993 =3D -297 * 3 (3.00 GHz) =3D 891 ahead > > > 2-3 day of work: > > > >> (XEN) update stime on time calibrate 0, 254477161980127 -> > 254478162020920 > >> (254478162021549, 0) > >> (XEN) update stime on time calibrate 2, 254477161977638 -> > 254478162018429 > >> (254478162022187, 0) > >> (XEN) update stime on time calibrate 1, 254477161978192 -> > 254478162018972 > >> (254478162022776, 0) > >> (XEN) update stime on time calibrate 3, 254477161976832 -> > 254478162017636 > >> (254478162021394, 0) > >> > >> 254478162020920 - 254478162017636 =3D 3284 * 3 (3.00 GHz) =3D 9852 lag > > Similarly here. Yes, the gap increases, yet that's not a lag of CPU3 past > CPU0, but exactly the other way around. > > > As you can see, the core lag is strictly determined by their sequence > > number. > > As per above - no, I don't think I can see that. Or maybe I'm misreading > the > numbers as well as what you have been saying. > > Jan > --000000000000d9dad50648443a5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You did read my recurring explanation beyond the IPI sending, d= idn't you? Of course IPI arrival may vary across cores / threads. Yet the term "rendezvous" is used because CPUs having received the IPI are the= n held in a waiting loop, until _all_ CPUs have made it there. Then CPU0 indicates to all of them simultaneously to move to the next step. There'= ;s going to again be some variance (especially on NUMA, where the memory write needs to propagate to all nodes), but at least within a single node that should be pretty low. The main source of variance I would expect there would by hyperthreads competing with one another in a single core.
Yes, I saw it. I'm no= t trying to dispute your understanding of the situation. The diffe= rence may be small, but it adds up.

Sure, I don't = doubt you make those observations. But we're still trying to
converge on a theory on what these may be caused by.
I can't tell you exactly what the main cause of the d= elay is. I can only list possible factors:
1. Rounding error, which varies = for each core;
2. Delay in IPI=C2=A0delivery= =C2=A0speed (even at the hardware level, signa= l=C2=A0delivery=C2= =A0shouldn't happen simultaneously, and some cores may have interrupts = disabled);
3. CPU frequency boost, which allows some cores to execute c= ode faster. On modern CPUs, this doesn't affect the TSC freque= ncy, but the problem is that the counter will be read at different times.
4. The initial difference in TSC counter values, which for cores within = a single CPU should be no more than 100 ns. In the case of NUMA, n= o more than 1000 ns;=
I can't speak about percentages; I wasn't = involved in CPU development, but there are many reasons not to allow cores = to compete in sequence increment speed.

The log entries aren't in CPU= order, and CPUs 1 and 2 actually have
identical values on the rhs. That doesn't quite fit what you have said = so
far. CPU3's value is also lower than CPU0's.
While CPU numbers happen to be= in sequence here, the rhs values aren't equally
ordered.
Also really here it is
22915730869696 - 22915730869993 =3D -297 * 3 (3.00 GHz) =3D 891 ahead
Similarly her= e. Yes, the gap increases, yet that's not a lag of CPU3 past
CPU0, but exactly the other way around.
= As per above - no, I don't think I can = see that. Or maybe I'm misreading the
numbers as well as what you have been saying.
During the first few hours, the situation can be blurred due to = possible race conditions. After two days, it becomes more or less = clear:
<= span class=3D"gmail-jCAhz gmail-ChMk0b">254478= 162020920 (core 0) > 254478162018972 (core 1) > 254478162018429 (core= 2) > 254478162017636 (core 3)

The lower the core number, the more it pulls ahead. It= 's possible that this is indeed related to which core is most heavily l= oaded (which one activates CPU boost more often). In my configurat= ion, the first three cores are dedicated to DOM0, and the fourth is reserve= d for virtual machines. The first core ends up being the most heav= ily loaded due to interrupt handling, etc.
<= span class=3D"gmail-HwtZe" lang=3D"en">I can also add that after replacing get_s= _time_fixed with scale_delta, the difference stops accumulating. At this point,= it's clear to me that the problem is the use of previous last_stime va= lues. The nature of this CPU behavior is unlikely to be understood at the s= oftware level. Of course, all the processors I tested on have the constant_tsc,= nonstop_tsc, and tsc_known_freq flags.


On Tue, Jan 13, 2026 at 2:21=E2=80=AFPM Jan Beulich <jbeulich@suse.com> wrote:
On 12.01.2026 17:41, An= ton Markov wrote:
>>
>> That calls on_selected_cpus(), but send_IPI_mask() may then still = resort to
>> all-but-self. In that case all IPIs are sent in one go.
>
> Plus as said, how IPIs are sent doesn't matter for the invocation = of
>> time_calibration_rendezvous_tail(). They'll all run at the sam= e time, not
>> one after the other.
>
> At the hardware level, no one can guarantee that the processors will > simultaneously respond to the signal and execute your code nanosecond = after
> you send the ipi. Especially when we're talking about NUMA configu= rations. I'm
> afraid the possible and impossible in the laws of physics is also beyo= nd
> the scope of this thread.

You did read my recurring explanation beyond the IPI sending, didn't yo= u?
Of course IPI arrival may vary across cores / threads. Yet the term
"rendezvous" is used because CPUs having received the IPI are the= n held
in a waiting loop, until _all_ CPUs have made it there. Then CPU0
indicates to all of them simultaneously to move to the next step. There'= ;s
going to again be some variance (especially on NUMA, where the memory
write needs to propagate to all nodes), but at least within a single node that should be pretty low. The main source of variance I would expect
there would by hyperthreads competing with one another in a single core.
> Since further down you build upon that "IPI lag", I fear we = first need to
>> settle on this aspect of your theory.
>
>=C2=A0 I've already provided the delay logs. It's not hard for = me to repeat.

Sure, I don't doubt you make those observations. But we're still tr= ying to
converge on a theory on what these may be caused by.

>=C2=A0 2 hours of work:
>
>> (XEN) update stime on time calibrate 0, 8564145820102 -> 856514= 5861597
>> (8565145862216, 0)
>> (XEN) update stime on time calibrate 1, 8564145820129 -> 856514= 5861609
>> (8565145863957, 0)
>> (XEN) update stime on time calibrate 3, 8564145819996 -> 856514= 5861491
>> (8565145864800, 0)
>> (XEN) update stime on time calibrate 2, 8564145820099 -> 856514= 5861609
>> (8565145865372, 0)
>>
>> 8565145861609 - 8565145861491 =3D 115 * 3 (3.00 GHz) =3D 345 lag
The log entries aren't in CPU order, and CPUs 1 and 2 actually have
identical values on the rhs. That doesn't quite fit what you have said = so
far. CPU3's value is also lower than CPU0's.

> 3 hours of work:
>
>> (XEN) update stime on time calibrate 0, 22914730829200 -> 22915= 730869993
>> (22915730870665, 0)
>> (XEN) update stime on time calibrate 1, 22914730829073 -> 22915= 730869889
>> (22915730870693, 0)
>> (XEN) update stime on time calibrate 2, 22914730829052 -> 22915= 730869841
>> (22915730872231, 0)
>> (XEN) update stime on time calibrate 3, 22914730828892 -> 22915= 730869696
>> (22915730872096, 0)
>>
>> 22915730869993 - 22915730869696 =3D 297 * 3 (3.00 GHz) =3D 891 lag=

While CPU numbers happen to be in sequence here, the rhs values aren't = equally
ordered.

Also really here it is

22915730869696 - 22915730869993 =3D -297 * 3 (3.00 GHz) =3D 891 ahead

> 2-3 day of work:
>
>> (XEN) update stime on time calibrate 0, 254477161980127 -> 2544= 78162020920
>> (254478162021549, 0)
>> (XEN) update stime on time calibrate 2, 254477161977638 -> 2544= 78162018429
>> (254478162022187, 0)
>> (XEN) update stime on time calibrate 1, 254477161978192 -> 2544= 78162018972
>> (254478162022776, 0)
>> (XEN) update stime on time calibrate 3, 254477161976832 -> 2544= 78162017636
>> (254478162021394, 0)
>>
>> 254478162020920 - 254478162017636 =3D 3284 * 3 (3.00 GHz) =3D 9852= lag

Similarly here. Yes, the gap increases, yet that's not a lag of CPU3 pa= st
CPU0, but exactly the other way around.

>=C2=A0 As you can see, the core lag is strictly determined by their seq= uence
> number.

As per above - no, I don't think I can see that. Or maybe I'm misre= ading the
numbers as well as what you have been saying.

Jan
--000000000000d9dad50648443a5d-- From xen-devel-bounces@lists.xenproject.org Tue Jan 13 12:43:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 12:43:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201675.1517243 (Exim 4.92) (envelope-from ) id 1vfdkG-0002cK-32; Tue, 13 Jan 2026 12:43:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201675.1517243; Tue, 13 Jan 2026 12:43:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfdkG-0002cD-0Y; Tue, 13 Jan 2026 12:43:36 +0000 Received: by outflank-mailman (input) for mailman id 1201675; Tue, 13 Jan 2026 12:43:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfdkE-0002c7-7a for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 12:43:34 +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 77cd3824-f07d-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 13:43:33 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by IA3PR03MB7593.namprd03.prod.outlook.com (2603:10b6:208:50c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 12:43:29 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.005; Tue, 13 Jan 2026 12:43: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: 77cd3824-f07d-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qktuLXAkBIctGvWW5OHcdE01eipJj9N/B6KXHRGPs5b1TzrtZUbaxIeCY5AgB8knUDzDpv0jT+cgWVtuqVyy1dUtu8hS3YMNDlpsUluC6jduzoTTurnmzSqE1yukoM053R1xnnskSAdYuXswoDCsopoTUTuSjCG0OCJqdvm9YOAI6rFMSmleZOf82Q1FOngtP3xE/l8eN2u3XqCONN20JESv9h0FFqJnFuNDa9Yw/wSC6nkDj+oiKZzkISsOAECs90ejksvtAR3lALtstAzbHk40g/jxX0ZhqNx+gTLXsm7HvCaHvnWOVwynDBn7mu3mCkTjTrkMskufMPNbVxdD9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=huRGABghhDDApfv3LQIBFoyrw4+2bvl1ZmoOSc6ciyk=; b=R1rIVzkC/hJCss66q9/1X242+5f1GLglH6Da2gQdkUFYU5x6HVErNPet/lu1WiiVpFp94i2KpbxPZcjqk1foT8BZtRvU9MIju+aMPfO2F1/cfTpraku3ZCJo9fC79FPpKJvN+HcCcORyilRi+E52JzY57lnv/arDgNnxfu15pYUE+bQuPtzpuCVjcq6FHkSq2nb9zxEnbMlRn/3mgLH8uccJjvoBWJbhmbhh9j1xigCHTjnjDIWnOmpIfkfnfWbI+ahuxIst7LqObhxGgyxfC22ARMl420i+ZrvmNn322JMqnwX1BQQLIFx4YkYpHrv76h9uxxPFW3XRuQpyq4TaPA== 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=huRGABghhDDApfv3LQIBFoyrw4+2bvl1ZmoOSc6ciyk=; b=GUx4rZtcdKlRPdgZf0aZNM8HUuBuEaLAywAmnEXd1d+0J7nrbr037s/g5XvIMGDsFc8TsfiH52MAOKXrfxmSjvC5DPw/83SLN31mm6peh59RtUgzBC/+hFSTS8YjrKstdv3vQCEXGbnAT5peTgN3p8XweDTazZ039VqfG1t0lh0= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <15233b0a-2cad-4263-8e54-3ad17037ad60@citrix.com> Date: Tue, 13 Jan 2026 12:43:25 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH v2] x86: Use 32-bit counter for TLB clock on debug builds To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260113120959.55156-1-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260113120959.55156-1-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0462.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1aa::17) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|IA3PR03MB7593:EE_ X-MS-Office365-Filtering-Correlation-Id: b6e65028-b6de-4cfd-6634-08de52a15a59 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?bUdJSm1vNmhMZmJaYjhTZkR0QkpFSU1KZEh4OGY1clR3WFRXV1JtTDVScDls?= =?utf-8?B?WEl6NHFRSzlSQkNsckorZWxHLzloYlNNYWpGWVh3Qk9jelpSTEJmTkRWbHVB?= =?utf-8?B?Y1l6NlhGN21hNzlIMHlOS2JmZ1JWV0FVam9VM1RKTHZwOStzL1hqTlRlTVNx?= =?utf-8?B?aWovc1FZQ1hKODdnTWI0dlEvSENZbDlTY090Ykx1bzZIR1RLQ2xGUGhhd0Zn?= =?utf-8?B?bFZib3FhUk01aEFEYVJjRC90aVhKVjFUTDB4WG9DMHZvNGZteE1lTzBjQU9G?= =?utf-8?B?MDBvQXRMdy9vWDFaaVcyQStaZ2o0R080WmRZK21HUE5uL1Nnejk5a3JZNVFN?= =?utf-8?B?SzN2MURWQ2FOOE5VRG1oODkvUGhyakFUbDBhNm1hcHQ2MlRZQTdMZ0locnYw?= =?utf-8?B?WEJzVFc4eEQ1QUt2M0JWNTJtSTQzelVjK0hMd211SEkvNythSFoxSFFFVW4z?= =?utf-8?B?QWh3aHpIUmJvRFFINW9rOXNmc1VlU1Vtd05GbklMV2kwcjRveTNGS0JxK1ph?= =?utf-8?B?b2FaTzF4QmtUR2F0VkxyUHUzSTVScDZBMmpZT1N0WUFKZkNjNjRUMDBpZ2pt?= =?utf-8?B?ZmUyZ25FdU9FQnFkYStWb05rTFJpMWQyNnBnbFVlUEFEdmoyTTlhZXpIMGFE?= =?utf-8?B?R2c5U3NreVBQTGxrbXdxL0FSRE9wWVhLMjVnODkwK0JiUUllLytHTzVmc3Bi?= =?utf-8?B?alpBaTZoTWRnaFE0WjVaSklndmhtMHBCZExTVUp2VUxOSS9DQ2xscjVQTUYv?= =?utf-8?B?QjJ3NS9XeTRUMENuRVNGQUpJbnRIV2NXeUo0a1UyUWVjNDRHUEJtejB0RWFJ?= =?utf-8?B?VDVQSnY0bStueTRjSGJSOGF2YmhhMFltSmhqYk9YWEZXcm1uWnhxK3NwVmgw?= =?utf-8?B?bmNrWlJwVnBhcGZQMjZJQkZsUlVwUjlKVWFKcEJJUWdCMzRVbmR3WXhVdFlO?= =?utf-8?B?Tlpkc0htTVlwRlpRbHoxaUF6ajJoQXNMN1BBclczMTQxdXlad0lsdlFRZ1BX?= =?utf-8?B?K2ZuZkVhbW13Tm5KSnJKclVVRWxnb3lzVWRRQnhkNUZLZ0NDbW9TejQrVUxo?= =?utf-8?B?VXpXVVcreFg1RVJ2dWhZUmxma1p3emFlYVdJYW9sRVgvTncvY3pkM04zU0xU?= =?utf-8?B?R3lROUdOTzdUbko1RWo0N1NON2ludzkwVmpjb2ZqTGt3OG5QNTV6UUZaakht?= =?utf-8?B?UWJrdUIyUW1VYWZ2VUF1ZDRqMkFqNmlYZzRYRndlOGNvOW16SUxHMlpUUUJH?= =?utf-8?B?VWRTNmFydjkxN1UvVjdmakdkQy9FbWdGUWdKd3JBaEdRTXVjZ3FXZSt5Z1Jq?= =?utf-8?B?b0lJYW9VaXZGckVRdHNtN3diQ1dLZ3VuSlZwTEdCNTl4YmNlM2NxNlI1am1U?= =?utf-8?B?RjhhQnRRRldrckU5T3VQb0NON0YzbzhrTW80akdvanNXMDhVb01HaEpJMWNs?= =?utf-8?B?Yk9zbmNtYUZXMlhzY0JVUzBpNFhjV2FWbTQza09mNGp0VitkSU95MDNwYkd6?= =?utf-8?B?U1UwTjBIOUdsUkZOUU9YQXA3T1ZRSHdzUVh0bytBY1dENDVDL1BKaFFjNWZC?= =?utf-8?B?dnAzUysrTzFsaEUyNXNaVFI5VTJmZUNNT1NST2E1dmpOQk02UHVFT3hsYXdk?= =?utf-8?B?Y2gzbGFFUmhDbHNGZWQ4QS8rYWE3a1Z4ZXAxNCtYTW53THpuMnp6OEtOc1R2?= =?utf-8?B?MlpjRGlrUzJxTVB6cEtuSGNGdlBuS1JhOTJ4dnZsakttTjF6THgvQUIxUnNI?= =?utf-8?B?VUdlNGgvSkNXSzN4aVFqcnZLQ3VGRHBpQ3FrWE5LaDREczZVL2hHOTZHK1lK?= =?utf-8?B?K1FEaTkvTEZKemhMV0U0dHJFLzhZdm5ONWowWWc4TGhOcjhTQlZVWEk3RGtv?= =?utf-8?B?T2FFVmZWYWg3UDNSWFVLb29rcmZqNjgwU1JTczVVTHUyRU95S3NEOFd3cVVx?= =?utf-8?Q?jKmX4LuB6iaVcCQebO6czNYkE3MyHpAH?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZnlENEhiUWpqeEhjaXBJYzNhdTZOSUdYUkNwNFNML0RxRDZlME01K0V5ckVV?= =?utf-8?B?SjFXalJNN2N4MG41cTFKeDcrOVdkZWMwaDBEV2RPY3VyTUFNaGtmOFN3Rkkv?= =?utf-8?B?VEZyUGFzcDY0dllxQTIyOWJoSW11OEdXR1Jub3M5ZkQ3dDhDcnJrVDlKaFFt?= =?utf-8?B?dk9sSjEzVVgzditld3BnNHVYM1FmWUZEL1lGKzIrNTRUMjN0V1N0N3FmUkNv?= =?utf-8?B?TDFzVVg3cnAwOFZod0JBSFRqQlhMcW5qUVlpRWoyNCs4L2ptSUR1eTROb2Fr?= =?utf-8?B?R1hlS2pCVFVtYjdGdTVHUkVsbGYxQ2tkUm94d1ZFOFRTTnBHNmR5T012N3dR?= =?utf-8?B?VDBnMUJEWEZmK0lrQlRkVU55Mm9RelBoQXByWUtlQ0l6d3l1RlQvMk1TakZO?= =?utf-8?B?UzZZelNNMmVONytGR0l4YXZoV1dBcFVRTzhZYUdIbmZFS3NMY2ZEZGNMMlho?= =?utf-8?B?Q1FwYk9SWU9MS3NwT2NrTXhnamJhTHE2em5QTjZWYVgxcy9ZSzVTc2FpY29p?= =?utf-8?B?OWlRbFR6SzFYMTBiTGtVd1lCV2xSSHFrUm1FTDN2Wjk4OFJmbC8xR1RtYllL?= =?utf-8?B?cEo0L3Y1L1RkdFA1OU5qUnhYS21Hb2Z2UHhaNzg2ZVNCWkpUaG5OY1Z3ODlE?= =?utf-8?B?NitjYnpkcHNhdnBPUzF0Z0JhT2NTa3BmR1pvdG9MRDdSMmVVOEFzYWNpendP?= =?utf-8?B?ZGdRa0cyZnI5bUlLaDJIMm5kazJNUDZ1d1FJVlNqMUpCeWRadWs5OFVjUzhG?= =?utf-8?B?RlpibURRZElEYXl2QzhOdGVpVXU4TW9KejFyUlF2RktyZ0o1Tm4zaC9NNTA1?= =?utf-8?B?STNkZzFaVzEzc1NWeC9kcVhvekFRWXE5Zk5ETyt6UWs0RVBEK0lxdkJCaUsv?= =?utf-8?B?ekJFT3M4UkJaRW10VEgwdWZpMldtdjkrajZDczRJZ0pWT2ZQR3lqaDB4cmUz?= =?utf-8?B?eXJUUGhYUGZFT1B2WWNhSTR3aXV6MWJxRUJ0dGdYUjMrWC9SN1lweHBwaG5P?= =?utf-8?B?WlVQelJ6TkJPeHJUMHMzM2NOd2JsWlJLTzArYng3dVpINGtUeEhzektHc3Rp?= =?utf-8?B?czhMRlA5WlMxUCtPdHoydG1oL2UwdGFlY0t3L1dSRlJ2bE94KzFhWW9HSVcx?= =?utf-8?B?VWJUaVZZNEJhaTFTRkpwbWhyWnQvcXJ3cUZMNUhBajNMN1BzV0I4Q2hkNDVa?= =?utf-8?B?T2JYWHlpR21TMFhNbGpzTHdpNExBN2QvMENrWHFSMTVpc0N4V0pyOWdjUklm?= =?utf-8?B?VWE2dk96NXdvT1JSeDBnU01CWE0rQUxNNTdFSWo3Q3pwd3p2YTdjbmJMM2xO?= =?utf-8?B?WWtPSlJ6YWNSTDhIdUd0c2ZlclZwTURvVGU0R3pFRXNXQVNIK1Bic1VrdXhH?= =?utf-8?B?c3RGcU1ITzZFSVMrTnZaRHlOM2ZEeko1NVE0WHZWbUNsQWFHSEJuNXpWNWk1?= =?utf-8?B?S1BGdGxiQjlESHdKaEZJZ05ZSkR1U1FKNkFiTDUwdnVNQVV0OWJjb1A3cXNV?= =?utf-8?B?dnA1UmlGOGJWUUNyenhTb1dDbG9OTDJkdlhjY3ZnSXU3cEN0c044VGkyaHBJ?= =?utf-8?B?WXJ6V1hJNjFHeUNBcW9LY1J1VVYzNlJhZXl5N0JUbkwwa05qbjFHSFlKdUla?= =?utf-8?B?Rk9VVWVsc01tbFZoZXdsbGZJTExvcTZCcEwrK0JVZE1TZitXVTlKUEtMcWpS?= =?utf-8?B?U3pIUGlSMXdKenpNYzdUMVE3cjh0WkhiN3lVYnhUbGtDQXV5NHAvQXcxWlN4?= =?utf-8?B?VlRCdkVPTFJwU0NiTEVKclB5QWJWSERhMUIrYTBzR1NWaEFrSkFheHU3K3FT?= =?utf-8?B?SWVMbGU3Y1lkOXRBd043SmRhR0xnaEtoSlp0dHNwZTJQbTBUYlJRNDU5ejF1?= =?utf-8?B?dEZpS0l1L2tGRFNadVpoekh6cEgvM1NOMWJ6T3JIRW1SRDRjdzlCbHZ3Q1JZ?= =?utf-8?B?ZFdreGpHTlV6WGhiS1Z3cHdNVkNxYURLakYzYm9GS1F1d1Q0QUx5VDJ6cHR2?= =?utf-8?B?Z2dZcGNrMHlQLzNVMUdEN0l0V0w1RWh4bCtldUJIQ2FycDJremIwYVIvUnpj?= =?utf-8?B?WldRajZLWFphQml0Q014Y0tkNzd1M3libE93WUdoUnhOQ0JkN014QzFmcjgv?= =?utf-8?B?R0lZZk44M3d0NGY0M1JERlIzODBkNSs2eUVqT2ZjSzRlUGFPcnE4UndCejV6?= =?utf-8?B?Z2JVdGxNTFRGNjlOU1ZBeHVSMkNGcXdGenpKR1lsVWJsVllUTTFVbFE2RXZl?= =?utf-8?B?Tm4wL3IvOEZ5eHRiSVJiN1ZGQUF2VjlCRm5hRzltbHpCMG5UVGZrSFRZeTQ0?= =?utf-8?B?SWl0ajJ6WjFvbjV4dDh2T3Nsdm5oSVkwWjQvai9ZTldQNVByeXVLQmF2UTVR?= =?utf-8?Q?XJrEucKeE30wwnzs=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b6e65028-b6de-4cfd-6634-08de52a15a59 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 12:43:29.4281 (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: XOYw+sV/UC5En8xOv5yyycNub/nbWkeojWs9aOtuvHoHmBzx4te1WE7EKXv8fJg7TSczApJeBHflwF+sypB7EU5NAmvfcVAaqR6uVAz4jOE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA3PR03MB7593 On 13/01/2026 12:09 pm, Alejandro Vallejo wrote: > Debug builds traditionally ship with a 10-bit counter for the TLB > clock. This forces global TLB shootdowns with high frequency, making > debug builds unsuitable for any form of real time testing. > > Remove this quirk, unifying release and debug under a wide counter. > > Signed-off-by: Alejandro Vallejo Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Tue Jan 13 12:51:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 12:51:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201687.1517253 (Exim 4.92) (envelope-from ) id 1vfdrn-0004KS-RU; Tue, 13 Jan 2026 12:51:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201687.1517253; Tue, 13 Jan 2026 12:51:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfdrn-0004KL-Oz; Tue, 13 Jan 2026 12:51:23 +0000 Received: by outflank-mailman (input) for mailman id 1201687; Tue, 13 Jan 2026 12:51: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 1vfdrm-0004KC-BP for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 12:51:22 +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 898f5082-f07e-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 13:51:11 +0100 (CET) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-653781de668so591107a12.2 for ; Tue, 13 Jan 2026 04:51:11 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8731f0718asm303503166b.67.2026.01.13.04.51.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 04:51:10 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 898f5082-f07e-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768308671; x=1768913471; 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=rc+00Iz/VNwj12qtx2UFz2wSnCxu9Xw7NrDdCTd38hM=; b=DeJVhnNBnj7OmRpn+QEt9qhrZIG1KO67yLF45dhgIdqG6M6zATQBXIOE4Tu6GSy6fQ mY+hmPU+XeQyL14ERQEmaF9BmIQmE6oLw2Ohfg6KEECie4kvcab85dM4dIerhNoVCKDg 76/ZJrYZHJwqr2NNrYXD2ciaB8wdDwpJWcKQuDRVRObVdGmNlEto0v+x3NZJ+x8znUcr JmyDE2JGzMSIHT02QpB/81rq46xFv5+VJC0WWkI3kO7eQwazUdpJFj9Uhr3J7XoaPYlx Y3BKEuEzbm6XicuSMtc6qT++Cn/Qzp3n14tLm2p4No1J88sRNVzQhWLG5U5QOd16KrbR jvOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768308671; x=1768913471; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rc+00Iz/VNwj12qtx2UFz2wSnCxu9Xw7NrDdCTd38hM=; b=nlEZTlnknZkqQhtYn/1hBLc4E8r/+JDyLazbKObedQ2QqbRdmf63zSf5xDegW7fCa3 AhSrdAELaD0pQoeIQ2LKSv25Ht1vECjVoD4FU5MIdI800dV5amH3rlwEWCMF11ALmyut UkM4GKZKBvwHCTBW7hBJBWyCu36svmsBgNOYf7nNdEpupZOp4kPEJBHz7dUPU9D9Cq6U YaE0nKz4CmR78qnGwC6NUAau3bRwW57d43/woa1bN1LJjtkN3WpA9xe9AOhVPGdAV+lI k7F620QMsRIR15sNDWolk5fZ80bJCcfA/XL5JZR9a+rj3RXkGv/ZZtwx6pg/Xw1mcIn0 MRPQ== X-Forwarded-Encrypted: i=1; AJvYcCWngFdc70rNXFRR0IChNhGhgNOTZDACjPGvnqVChMDmI12wp4/2dVxIC4cXqD0NpXH8jCGvv64hZx0=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy8+yZqmLeVbQ7LAxuUPo9c1//UIeGLPquU1otYyTs7fajxJRfp b9M2b0/156up/VTnHt6jSnIekMdvDKDfsWQdkmLlQ0rrgduAPDelb7Z9 X-Gm-Gg: AY/fxX7xrqdiYgdoNhBj8GIdfAJPkJyFsKMCk660EPWEXHF6wcy2rMJdqd5Ddj7BGka 27uVW8l9SUIgeYlnhRQm4ypVKqSBotKww7p9OyKLoWFhJcCK6VwOKTY2O9nPsl0IXQfs+zEBxxx +ldCK/YGnoaCNAgjenE1RKaKrf+QNWDEj+T/TceWLskdm+y/PK6E6NiNzNeho7QDgqCsk574KeP DhUIfRHVaxuPgNMK2IZTLH7UvPxleiD0y4p2FgSBQ2EoE1by+BYLFZxcbbaDuBZA9i7/lMssas0 5clz/7PFM2J3YSG2g9bZbyEDLhxw4X1/0IFw/fkUQKwmn2/xrWjTP5i2TUbsarJDNzLxNA84+sU ehsj+iVDiqqzOSztPOXDQeIWPrPlp1MmX01SbCauoMLOimGxhK1Hk11Vw7DqJkl33w+c7QQ6Gwm r7iw7wEI6s4WxydLHF7ilnQoDaMumYHwOrnJXZ3PCORgy20d3pzlg/0hVe7muuqnA= X-Google-Smtp-Source: AGHT+IHncNc7a6dHmmle2NYf3jdUgD++hEj21S6BYblCjzvDgJdMqacZXYG0KQa4v42TaZpHeL3wlw== X-Received: by 2002:a17:907:a4a:b0:b7c:e320:5228 with SMTP id a640c23a62f3a-b84451bf352mr1919554766b.22.1768308670414; Tue, 13 Jan 2026 04:51:10 -0800 (PST) Message-ID: Date: Tue, 13 Jan 2026 13:51:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 07/15] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/7/26 5:28 PM, Jan Beulich wrote: > On 24.12.2025 18:03, Oleksii Kurochko wrote: >> This patch is based on Linux kernel 6.16.0. >> >> Introduce a lockless mechanism for tracking pending vCPU interrupts using >> atomic bit operations. The design follows a multi-producer, single-consumer >> model where the consumer is the vCPU itself. >> >> Two bitmaps are added: >> - irqs_pending — represents interrupts currently pending >> - irqs_pending_mask — represents bits that have changed in irqs_pending >> >> Introduce vcpu_(un)set_interrupt() to mark an interrupt in irqs_pending{_mask} >> bitmap(s) to notify vCPU that it has or no an interrupt. > It's not becoming clear how these are going to be used. It's also not clear > to me whether you really need to record these in software: Aren't there > (virtual) registers where they would be more naturally tracked, much like > hardware would do? Guest (virtual) registers are not used to inject interrupts on RISC-V; for that purpose, the HVIP register is provided. Even without considering HVIP, using guest (virtual) registers has a downside: if a bit in hideleg is zero, the corresponding bit in VSIP is read-only zero. During a context_switch(), when CSRs are saved, this means we would not obtain correct values, since some VSIP bits may read as zero during csr_read(). In fact, this is one of the reasons why we want to track interrupts to be injected separately. For example, a vtimer may expire while the vCPU is running on a different pCPU, so we update vCPU->hvip while the vCPU is active elsewhere. When the vCPU is later switched in during a context_switch(), we would lose the fact that vCPU->hvip.vtimer was set to 1, because the CSR save function will do: vCPU->hvip = csr_read(CSR_HVIP); and the pending interrupt state would be overwritten. > > Furthermore, since you're dealing with two bitmaps, there's no full > atomicity here anyway. The bitmaps are each dealt with atomically, but > the overall update isn't atomic. Whether that's going to be okay can only > be told when also seeing the producer side. You're correct that the two-bitmap update isn't fully atomic, but this design is intentional. Here [1], other is the part 2 of introduction of pending vCPU interrupts and as it requires more stuff to introduce (for example, [2]) I decided not to introduce it now with some stubs and introduce it when all will be ready for it. If a producer is interrupted between updating the two bitmaps the worst case is: vCPU might process stale state for one cycle, this is resolved on the next flush when the mask indicates the bit changed. No interrupt is permanently lost or spuriously generated. [1] https://gitlab.com/xen-project/people/olkur/xen/-/commit/31022d515789a032fd994f9ca90965db089dbbd5 void vcpu_flush_interrupts(struct vcpu *v) { register_t *hvip = &v->arch.hvip; unsigned long mask, val; if ( ACCESS_ONCE(v->arch.irqs_pending_mask[0]) ) { mask = xchg(&v->arch.irqs_pending_mask[0], 0UL); val = ACCESS_ONCE(v->arch.irqs_pending[0]) & mask; *hvip &= ~mask; *hvip |= val; } /* Flush AIA high interrupts */ vcpu_aia_flush_interrupts(v); vcpu_update_hvip(v); } void vcpu_sync_interrupts(struct vcpu *v) { unsigned long hvip; /* Read current HVIP and VSIE CSRs */ v->arch.vsie = csr_read(CSR_VSIE); /* Sync-up HVIP.VSSIP bit changes does by Guest */ hvip = csr_read(CSR_HVIP); if ( (v->arch.hvip ^ hvip) & BIT(IRQ_VS_SOFT, UL) ) { if ( hvip & BIT(IRQ_VS_SOFT, UL) ) { if ( !test_and_set_bit(IRQ_VS_SOFT, &v->arch.irqs_pending_mask) ) set_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); } else { if ( !test_and_set_bit(IRQ_VS_SOFT, &v->arch.irqs_pending_mask) ) clear_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); } } /* Sync-up AIA high interrupts */ vcpu_aia_sync_interrupts(v); /* Sync-up timer CSRs */ vtimer_sync(v); } [2] https://gitlab.com/xen-project/people/olkur/xen/-/commit/1c06b8b1d1eadfe009a4d6b1a1902fac64d080e9 > >> --- a/xen/arch/riscv/domain.c >> +++ b/xen/arch/riscv/domain.c >> @@ -5,9 +5,11 @@ >> #include >> #include >> >> +#include >> #include >> #include >> #include >> +#include >> #include >> >> static void vcpu_csr_init(struct vcpu *v) >> @@ -100,6 +102,9 @@ int arch_vcpu_create(struct vcpu *v) >> if ( is_idle_vcpu(v) ) >> return rc; >> >> + bitmap_zero(v->arch.irqs_pending, RISCV_VCPU_NR_IRQS); >> + bitmap_zero(v->arch.irqs_pending_mask, RISCV_VCPU_NR_IRQS); > This is pointless, as struct vcpu starts out all zero. > >> @@ -135,3 +140,45 @@ void vcpu_kick(struct vcpu *v) >> smp_send_event_check_mask(cpumask_of(v->processor)); >> } >> } >> + >> +int vcpu_set_interrupt(struct vcpu *v, const unsigned int irq) >> +{ >> + /* >> + * We only allow VS-mode software, timer, and external >> + * interrupts when irq is one of the local interrupts >> + * defined by RISC-V privilege specification. >> + */ >> + if ( irq < IRQ_LOCAL_MAX && > What use is this? In particular this allows an incoming irq with a huge > number to ... > >> + irq != IRQ_VS_SOFT && >> + irq != IRQ_VS_TIMER && >> + irq != IRQ_VS_EXT ) >> + return -EINVAL; >> + >> + set_bit(irq, v->arch.irqs_pending); >> + smp_mb__before_atomic(); >> + set_bit(irq, v->arch.irqs_pending_mask); > ... overrun both bitmaps. Agree, it would be better just to drop "irq < IRQ_LOCAL_MAX &&". > >> --- a/xen/arch/riscv/include/asm/domain.h >> +++ b/xen/arch/riscv/include/asm/domain.h >> @@ -85,6 +85,22 @@ struct arch_vcpu >> register_t vstval; >> register_t vsatp; >> register_t vsepc; >> + >> + /* >> + * VCPU interrupts >> + * >> + * We have a lockless approach for tracking pending VCPU interrupts >> + * implemented using atomic bitops. The irqs_pending bitmap represent >> + * pending interrupts whereas irqs_pending_mask represent bits changed >> + * in irqs_pending. > And hence a set immediately followed by an unset is then indistinguishable > from just an unset (or the other way around). I think it is distinguishable with the combination of irqs_pending_mask. > This may not be a problem, but > if it isn't, I think this needs explaining. Much like it is unclear why the > "changed" state needs tracking in the first place. It is needed to track which bits are changed, irqs_pending only represents the current state of pending interrupts.CPU might want to react to changes rather than the absolute state. Example: - If CPU 0 sets an interrupt, CPU 1 needs to notice “something changed” to inject it into the VCPU. - If CPU 0 sets and then clears the bit before CPU 1 reads it, irqs_pending alone shows 0, the transition is lost. By maintaining irqs_pending_mask, you can detect “this bit changed recently,” even if the final state is 0. Also, having irqs_pending_mask allows to flush interrupts without lock: if ( ACCESS_ONCE(v->arch.irqs_pending_mask[0]) ) { mask = xchg(&v->arch.irqs_pending_mask[0], 0UL); val = ACCESS_ONCE(v->arch.irqs_pending[0]) & mask; *hvip &= ~mask; *hvip |= val; } Without it I assume that we should have spinlcok around access to irqs_pending. > >> Our approach is modeled around multiple producer >> + * and single consumer problem where the consumer is the VCPU itself. >> + * >> + * DECLARE_BITMAP() is needed here to support 64 vCPU local interrupts >> + * on RV32 host. >> + */ >> +#define RISCV_VCPU_NR_IRQS 64 >> + DECLARE_BITMAP(irqs_pending, RISCV_VCPU_NR_IRQS); >> + DECLARE_BITMAP(irqs_pending_mask, RISCV_VCPU_NR_IRQS); >> } __cacheline_aligned; >> >> struct paging_domain { >> @@ -123,6 +139,9 @@ static inline void update_guest_memory_policy(struct vcpu *v, >> >> static inline void arch_vcpu_block(struct vcpu *v) {} >> >> +int vcpu_set_interrupt(struct vcpu *v, const unsigned int irq); >> +int vcpu_unset_interrupt(struct vcpu *v, const unsigned int irq); > Why the const-s? As irq number isn't going to be changed inside these functions. > >> --- a/xen/arch/riscv/include/asm/riscv_encoding.h >> +++ b/xen/arch/riscv/include/asm/riscv_encoding.h >> @@ -91,6 +91,7 @@ >> #define IRQ_M_EXT 11 >> #define IRQ_S_GEXT 12 >> #define IRQ_PMU_OVF 13 >> +#define IRQ_LOCAL_MAX (IRQ_PMU_OVF + 1) > MAX together with "+ 1" looks wrong. What is 14 (which, when MAX is 14, > must be a valid interrupt)? Or if 14 isn't a valid interrupt, please use > NR or NUM. I didn’t fully understand your idea. Are you suggesting having|IRQ_LOCAL_NR|? That sounds unclear, as it’s not obvious what it would represent. Using|MAX_HART| seems better, since it represents the maximum number allowed for a local interrupt. Any IRQ below that value is considered local, while values above it are implementation-specific interrupts. > Also, nit: Padding doesn't match with the earlier #define-s (even if in the > quoted text it appears otherwise). Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Jan 13 13:47:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 13:47:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201710.1517287 (Exim 4.92) (envelope-from ) id 1vfek2-0002X8-1j; Tue, 13 Jan 2026 13:47:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201710.1517287; Tue, 13 Jan 2026 13: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 1vfek1-0002X1-UX; Tue, 13 Jan 2026 13:47:25 +0000 Received: by outflank-mailman (input) for mailman id 1201710; Tue, 13 Jan 2026 13:47: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 1vfek1-0002Wv-B7 for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 13:47:25 +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 6309efba-f086-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 14:47:22 +0100 (CET) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-42fbc305882so4091402f8f.0 for ; Tue, 13 Jan 2026 05:47:22 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ee5e3sm44058501f8f.35.2026.01.13.05.47.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Jan 2026 05:47:20 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6309efba-f086-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1768312042; x=1768916842; 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=YTxMpK8blmmBv4ftj07xwrXcPyB8EDLdkKosz0jgWTo=; b=e/LoCEa2nGUjgYIz6jANKDCmv1rErDu8lEl4ulWN90ECxH7VUjY53rlKVGJtnQcwZc BKdqQeZd9BgDZkfco0WLqBEFIWd1RBa5GQp2bFkmaM567GdtCVSIHwzMbhU/J54ZRPgW Pce8jJNTCQu/8wiAbc2J5qYhssHb8jYMb5enM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768312042; x=1768916842; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=YTxMpK8blmmBv4ftj07xwrXcPyB8EDLdkKosz0jgWTo=; b=H8isO6aZheZGYP/L6bMtiR7YSuoEeq9v5JUsDeHW8bnVNP4ZGLj/MPaM68rWfionm8 1aHDRCYod6MUQBD4utTOaf3b0nhLZJ6pMDbbcOAkX+Ei1c0IfamVKuI82jyJXkHj5uPY b3kqa5KiPJmVm/Tro9ly4jKBonU/rsvT3AkK7gxugN6yXM2WwzGuWVBtwZVq3GQfnBlZ /OqdG0Rjcti7xSgx+V8L1mRLr2+lyShAlhPvW6mHSkOmpK3YDjh4AKiZq1xdg7Nau714 4Jify3wJqLZIoby1+NKRxlQhHoPhuof/EoPF4TF4r7R6Xr3LZMhKsA7WF/6U5wwgah/B ntkA== X-Gm-Message-State: AOJu0YxxUQa6aWyflep1b3Ty5MaS2u3KbO5y/EQ0e2+7NTXpqc7VTXRS G4XU2KJp5ONJlTvWZI4NMIdVYS6BcKa84VJz2Sxo2gYlJ/bomrgwQoOY5MRqFpVoxp0C+DZJdQk omYJr X-Gm-Gg: AY/fxX60x6Y58QPJvX91Knk/iWOC0lbS+RJcD+UPXaDkFzVkma////IIB/xMjcXWejw VJnflS3A8X4O+TQOPyv7k9+kI6lcutyj6+JkF6NKO7uREbaJU2arznnMOY1mhBDulq7XZ9Az4Ls /1DKE5uwEpQu1rIJRsRCqaV7/fq9oRSelWf1uQSORjh7tRaexzryBF8OoGtVAhhHpbVK5uFjFT4 ZqHO/h69T403R9OvFy5zEBpdXxBHNvLZ6Cme8mvZZENAlKqyMPh84p9Xr4W5b9XR8QghhbNTJF6 3lpRI1vdi+E4tSioKiNYCe2XIHIaaOGXyzgOoNHHcBqk7pGCV9/ZjSOJ/XZqSIGK/2LzryXJcCR pjUXNgnb4Q19ZloidMZY0wiu4iWvlZMo86ys5CWnfPB1riWFRzhz/E+5+LyFja4B+VrGcmGRRs0 xvSgLet5aRcZyLPxtvAnL/lIP3eC0MTZWqB/4UvRnAwDQIE3f/wYah2vrS8IzH/mhqnb46nZeY X-Google-Smtp-Source: AGHT+IHApcp1nxuWpmQGXYgRHTGzSofPbLDAbGRb2yHGwShyLvgxCXeyRnTfcU+5U64i5YXxvrIl7w== X-Received: by 2002:a5d:64e6:0:b0:432:851d:3676 with SMTP id ffacd0b85a97d-432c3774267mr28006416f8f.57.1768312041503; Tue, 13 Jan 2026 05:47:21 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH] x86/cpu-policy: Filter out OS{XSAVE,PKE} in calculate_raw_cpu_policy() Date: Tue, 13 Jan 2026 13:47:19 +0000 Message-Id: <20260113134719.1047476-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 They're dynamic too, and don't have named fields because no (other) logic in Xen ought to operate on them. In particular, OSPKE being visible depending on whether we're in HVM or PV vCPU context when scanning. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné More fallout from XenServer's rescan capability, this time running with a PVH dom0. OSXSAVE was accounted for before by being force-enabled, and is wrong, hence the adjustment here too. The othe two fields Intel list as dynamic are AESKLE (which we don't have infrsatructure for yet), and SYSCALL (based on %cs.l) which I have no interest in treating like a generally variable bit. --- xen/arch/x86/cpu-policy.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c index 372d11f2ff20..5273fe0ae435 100644 --- a/xen/arch/x86/cpu-policy.c +++ b/xen/arch/x86/cpu-policy.c @@ -345,9 +345,13 @@ void calculate_raw_cpu_policy(void) ASSERT(p->x86_vendor == boot_cpu_data.vendor); /* - * Clear the truly dynamic fields. These vary with the in-context XCR0 - * and MSR_XSS, and aren't interesting fields in the raw policy. + * Clear the truly dynamic fields. + * + * - The OS* bits are forwards from CR4. + * - The xstate fields are calculated from XCR0 and MSR_XSS. */ + p->basic.raw[1].c &= ~cpufeat_mask(X86_FEATURE_OSXSAVE); + p->feat.raw[0].c &= ~cpufeat_mask(X86_FEATURE_OSPKE); p->xstate.raw[0].b = 0; p->xstate.raw[1].b = 0; base-commit: 6d1180b1499145fcb8f3099c1ab4b7305aba2ed4 prerequisite-patch-id: c5070338424f36d973c1b0fb9f6419682c48ee03 -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 13:54:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 13:54:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201725.1517297 (Exim 4.92) (envelope-from ) id 1vfer4-0004AO-Q9; Tue, 13 Jan 2026 13:54:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201725.1517297; Tue, 13 Jan 2026 13:54:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfer4-0004AH-NI; Tue, 13 Jan 2026 13:54:42 +0000 Received: by outflank-mailman (input) for mailman id 1201725; Tue, 13 Jan 2026 13: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 1vfer3-0004AB-EY for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 13:54:41 +0000 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [2a00:1450:4864:20::336]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 675aa815-f087-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 14:54:39 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-47774d3536dso55875945e9.0 for ; Tue, 13 Jan 2026 05:54:39 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0e175csm43887878f8f.14.2026.01.13.05.54.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 05:54:38 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 675aa815-f087-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768312479; x=1768917279; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=5fmgD9pYTMjmLHabb3x41OsejSd/WIRlxeSMMp34Cpg=; b=OCTld1O8/kUrsNJXBviXniPP0IwETppZdYjYjNwSXl1t/N9QDK+6ghFUdcFNnt+ASc GCz38gMBNcC1SN3E5s9vc46zKu5z2tI9JFmn+YHxjMPjUGYl99dtDJknhReAJIdzZ9os d8GnUYlzYFoBiUUXpjIHuo+qOmclYsJBwUGHIEBCA+0woBHYl/JJn7yZJTO9qV6bKr9o 7G8QA+w5GB9Fy9iACHg1yE77rir9h9y/YCe2larlBIOBMP4RojHCAg1tAOZP6sCy8LDt lTRLrQcDXhCssg98YEVYL5Budu5UCIfX1piUf+dPVl2C2NG5bN38N/QtrTk21rpD0Db/ mnrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768312479; x=1768917279; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5fmgD9pYTMjmLHabb3x41OsejSd/WIRlxeSMMp34Cpg=; b=i0J4/IZQJ+t1W+hUvybpPUmEYZT8DURbfPKSjmt3umsPXQ/A7ZMslEEqguO0sJDfOg tGoBkLq5i4tqq4yr5RQz4LZeco4O6b50KAo66k9pvJyVw2fd6XQfjXOQNDk6lahJWA3A NVVHVGpx2GU0Hfsx0Kt7jLFr8CgCZxY4mx5xNp7OMI/aKc2hGGCk5Wz6EJRiu7h9UqPR X5r1hj3MFvW/etcpFfzm1gqmKTJQ2oiX5bhwwslaIzrwkSZkxBieJM1sWltvEa3mf21c oqOS9Fre7E1R139kRdNYvCDrH8IvGIq9BYtNrDhYVYimDOB6PydqBI3gQa/KZvsYQfdI /u8g== X-Forwarded-Encrypted: i=1; AJvYcCXUy2bzasNSmVA6+jGF8hfS8qDdlWSfVSFLkp86RnkluFDveQWLITJJyQwdsC64twkwYyJMu3EdOgw=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw5Ika3iz9PaIdKCrykdwWP0AXEBprYtI7mwhX6J1Wh0DSPasPp EJ4JJ0Utoy4GYSho4SISusd5KJaX49iymUnuA99jTVoVhl9u/KZuG066x/NiMesOAg== X-Gm-Gg: AY/fxX4I2rhr5ZCWLHStGrzpgDQ/3Bk3KqaUUuJST0O5hLv1tb93r/tDgkq5vw9ABmt Ziun5BrvTYn/jTdTwW40ljoIDSgbCB7j9iq7wBTOeL1fTSoDjdri7drXQILF8wmfQJCaECm/Rj/ JctK1mbS9gywiwjPsGmPQbY9EQjxr/2VigmYzfc0BAwN55EOrWQ6b5GXmSOXfp5GeNSsi9tE2Hk t/uj1ElVXLcZdyMgLCqDFd+vOk+U1NhcX+HUzHXcPzabTZiwQS8eC2IlZ7CoqzaEfN2TzNIYi/A XzWjqTR0YWApZkVgO3Z0VNBJSCVWUYPcXPonedbcpXpgrSIhKI/KDDj02KPxLX95Zlejvl1irso jXaaIo8AM4GC6JozKkinaiy6mFMOlH2bpThihRq0bs5QXObOkuCP1X8ud/K871PhNzR661PXR0m mLcjcUGAe3TzKU0GCp61M/5y7kkhjhdrW3hd/9H7X3gCOVri2pdc/C8PYfYil9Xduc2bqIW2S3J oY= X-Received: by 2002:a05:600c:1410:b0:47b:d5ab:3ce2 with SMTP id 5b1f17b1804b1-47ed7c52049mr27560625e9.18.1768312478825; Tue, 13 Jan 2026 05:54:38 -0800 (PST) Message-ID: Date: Tue, 13 Jan 2026 14:54:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 07/15] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 13.01.2026 13:51, Oleksii Kurochko wrote: > On 1/7/26 5:28 PM, Jan Beulich wrote: >> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>> --- a/xen/arch/riscv/include/asm/domain.h >>> +++ b/xen/arch/riscv/include/asm/domain.h >>> @@ -85,6 +85,22 @@ struct arch_vcpu >>> register_t vstval; >>> register_t vsatp; >>> register_t vsepc; >>> + >>> + /* >>> + * VCPU interrupts >>> + * >>> + * We have a lockless approach for tracking pending VCPU interrupts >>> + * implemented using atomic bitops. The irqs_pending bitmap represent >>> + * pending interrupts whereas irqs_pending_mask represent bits changed >>> + * in irqs_pending. >> And hence a set immediately followed by an unset is then indistinguishable >> from just an unset (or the other way around). > > I think it is distinguishable with the combination of irqs_pending_mask. No. The set mask bit tells you that there was a change. But irqs_pending[] records only the most recent set / clear. >> This may not be a problem, but >> if it isn't, I think this needs explaining. Much like it is unclear why the >> "changed" state needs tracking in the first place. > > It is needed to track which bits are changed, irqs_pending only represents > the current state of pending interrupts.CPU might want to react to changes > rather than the absolute state. > > Example: > - If CPU 0 sets an interrupt, CPU 1 needs to notice “something changed” > to inject it into the VCPU. > - If CPU 0 sets and then clears the bit before CPU 1 reads it, > irqs_pending alone shows 0, the transition is lost. The fact there was any number of transitions is recorded in _mask[], yes, but "the transition" was still lost if we consider the "set" in your example in isolation. And it's not quite clear to me what's interesting about a 0 -> 0 transition. (On x86, such a lost 0 -> 1 transition, i.e. one followed directly by a 1 -> 0 one, would result in a "spurious interrupt": There would be an indication that there was a lost interrupt without there being a way to know which one it was.) > By maintaining irqs_pending_mask, you can detect “this bit changed > recently,” even if the final state is 0. > > Also, having irqs_pending_mask allows to flush interrupts without lock: > if ( ACCESS_ONCE(v->arch.irqs_pending_mask[0]) ) > { > mask = xchg(&v->arch.irqs_pending_mask[0], 0UL); > val = ACCESS_ONCE(v->arch.irqs_pending[0]) & mask; > > *hvip &= ~mask; > *hvip |= val; > } > Without it I assume that we should have spinlcok around access to irqs_pending. Ah yes, this would indeed be a benefit. Just that it's not quite clear to me: *hvip |= xchg(&v->arch.irqs_pending[0], 0UL); wouldn't require a lock either. What may be confusing me is that you put things as if it was normal to see 1 -> 0 transitions from (virtual) hardware, when I (with my x86 background) would expect 1 -> 0 transitions to only occur due to software actions (End Of Interrupt), unless - see above - something malfunctioned and an interrupt was lost. That (the 1 -> 0 transitions) could be (guest) writes to SVIP, for example. Talking of which - do you really mean HVIP in the code you provided, not VSVIP? So far I my understanding was that HVIP would be recording the interrupts the hypervisor itself has pending (and needs to service). >>> Our approach is modeled around multiple producer >>> + * and single consumer problem where the consumer is the VCPU itself. >>> + * >>> + * DECLARE_BITMAP() is needed here to support 64 vCPU local interrupts >>> + * on RV32 host. >>> + */ >>> +#define RISCV_VCPU_NR_IRQS 64 >>> + DECLARE_BITMAP(irqs_pending, RISCV_VCPU_NR_IRQS); >>> + DECLARE_BITMAP(irqs_pending_mask, RISCV_VCPU_NR_IRQS); >>> } __cacheline_aligned; >>> >>> struct paging_domain { >>> @@ -123,6 +139,9 @@ static inline void update_guest_memory_policy(struct vcpu *v, >>> >>> static inline void arch_vcpu_block(struct vcpu *v) {} >>> >>> +int vcpu_set_interrupt(struct vcpu *v, const unsigned int irq); >>> +int vcpu_unset_interrupt(struct vcpu *v, const unsigned int irq); >> Why the const-s? > > As irq number isn't going to be changed inside these functions. You realize though that we don't normally use const like this? This use of qualifiers is meaningless to callers, and of limited meaning to the function definition itself. There can be exceptions of course, when it is important to clarify that a parameter must not change throughout the function. >>> --- a/xen/arch/riscv/include/asm/riscv_encoding.h >>> +++ b/xen/arch/riscv/include/asm/riscv_encoding.h >>> @@ -91,6 +91,7 @@ >>> #define IRQ_M_EXT 11 >>> #define IRQ_S_GEXT 12 >>> #define IRQ_PMU_OVF 13 >>> +#define IRQ_LOCAL_MAX (IRQ_PMU_OVF + 1) >> MAX together with "+ 1" looks wrong. What is 14 (which, when MAX is 14, >> must be a valid interrupt)? Or if 14 isn't a valid interrupt, please use >> NR or NUM. > > I didn’t fully understand your idea. Are you suggesting having|IRQ_LOCAL_NR|? > That sounds unclear, as it’s not obvious what it would represent. > Using|MAX_HART| seems better, since it represents the maximum number allowed > for a local interrupt. Any IRQ below that value is considered local, while > values above it are implementation-specific interrupts. Not quite. If you say "max", anything below _or equal_ that value is valid / covered. When you say "num", anything below that value is valid / covered. That is, "max" is inclusive for the upper bound of the range, while "num" is exclusive. Hence my question whether 14 is a valid local interrupt. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 13 14:01:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 14:01:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201741.1517326 (Exim 4.92) (envelope-from ) id 1vfexj-00062y-Kq; Tue, 13 Jan 2026 14:01:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201741.1517326; Tue, 13 Jan 2026 14:01:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfexj-00062r-IA; Tue, 13 Jan 2026 14:01:35 +0000 Received: by outflank-mailman (input) for mailman id 1201741; Tue, 13 Jan 2026 14:01: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 1vfexh-00062l-Fs for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 14:01:33 +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 5d08beec-f088-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 15:01:32 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SA6PR03MB7735.namprd03.prod.outlook.com (2603:10b6:806:43c::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Tue, 13 Jan 2026 14:01:27 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.005; Tue, 13 Jan 2026 14:01: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: 5d08beec-f088-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mQ1M/waEsnI8GeQTLxFT3j1ZtpkNd2V9bNPGe1BuPoGI0I/yBFH0QunLAKvSpAeB94ahkYyiO2hlz5dWQfsuaCUXEfh9Sk2/q6skpWVoOIeWscDh2siClyXyE98WKWZF44eL83OW14NFQYi/FftUtXFab1dLEmHehOAZ0qTDH+6FPjCCB9x45fzrwurXJHU53OQ9K+eQbzCzWC/KO0LDThU+xtyE5dABcrGf7LryVnjiOov9rn941uNR2CTEYmO73Eyz4H3Fn1kob3aEmNmQlrzaiOwjJbYljoAzsqOFiuXa2oJmA2g/l9hYX8ZO5aW8eeUZfU9GUpliOdRZO0h3oA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2DuMkhpSsc0/+mMpGd2m3Wpu6gUezUsD1TdTB/KCR+k=; b=hdrWRH7Z9cpPhHIOyOYNCH7z9KkobCMiKWxWNmzBOqc+LxFojtq7W9Nz6ijGo9xeoPBPS+wUefYWY39ywkCon5LDzyUW84OxqPHG9NZxiqRVqWtnavpl8Ve9E/+LnnGfBKgKV2xmOChOzO1qXFFH9Dyo9qOc1WlWloNLA9he6sG0oLTdkZjfGTbYM3bTAskz1bo2TOt2kfhKNTBoQkSFRT0uUag1IJwhxpaLL4siP4RU3WyQCFjsE6r6K2sBMHO8IC0FSusec6rmzpx3gEKsM5sWj9tjNfKubOdLGBJGPRjdlVV/0gM40eZt0GE9yJOsEktXVK6nnGoNKJJCh7mFHw== 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=2DuMkhpSsc0/+mMpGd2m3Wpu6gUezUsD1TdTB/KCR+k=; b=IWu08B7Mpa/1KBs4Lb7qR8Vf09HlYXcDKiNbsD43oU5cRl0nz3A0Jo6b9/Sv+1+P3WdwFs7cJqTkGz9g6crv+9uislkQPtK+GoacCzmzUSj7oplmwUMqvXP2n37AMG8PcGQ1qYYdvdttPO6yhMIT5VUMQEZ5ZR7EZrw30ZONopQ= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Tue, 13 Jan 2026 15:01:16 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH 2/2] xen/mm: limit non-scrubbed allocations to a specific order Message-ID: References: <20260108175536.82153-1-roger.pau@citrix.com> <20260108175536.82153-3-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: PAZP264CA0125.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:1ef::16) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SA6PR03MB7735:EE_ X-MS-Office365-Filtering-Correlation-Id: 3bca35b1-6b21-4adb-06d1-08de52ac3aa0 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?VmJ2aE5FSXpnOEJsKzRVa0tjcDkvMStienlLZE5wWkhSV2cyanlEL1ppLzZD?= =?utf-8?B?enNPYisrUUdBei9NK0VqeERUL0NTdWJGQTcvYkhvU3RzaDZ4MjBKSVhoQUpu?= =?utf-8?B?YmI4djhFWUoweGxwaEUrOVliTnFBVUQ5QTN1OVB6cXUvS0QwNUtnTjFncG5Z?= =?utf-8?B?QXNET1JJdFVxVHFYUnJtM2c1NmpMVklmM1dKaDRWZTV2UlFyTkZ0eFN5clVk?= =?utf-8?B?Wld6Z3MxNGlaWTIzckZvbTdxS3h6S2RRSXNHWlJWYm1paVRHT0pML0RSTlVN?= =?utf-8?B?TzNSVy8zM0FwR0lsTVI0c2lBamFFY0N0Zkp0SjF5Q3lVdzJpK3ZYb2FjNWJ0?= =?utf-8?B?YmcxOWJ4ZUNwSlQwY0ZVK3hKdW9uRHoyQ1F4TkZsOGc2QUZhMGRPVEViczFp?= =?utf-8?B?Q0FIUFFmYlh0MitPNnc0akRDdjJCQUhvSjJrN2ZGcmNkWCs1Uyt0b2NNYzRG?= =?utf-8?B?ZVJsVTB5Sm41TnRqUzBJWlBWOS9RcXdWSE4zdGhJajdXdjE3TlI4OXJjelMz?= =?utf-8?B?UVRQTm5tMWR2TmR2T1pmUE1lOVZiRjQ2TG5iVWpCTFI2c2FsWFliWEZmMThZ?= =?utf-8?B?OWNmOEY5dDhqbG5aRVdoWmNwWkdzUDl3NStSQlNlMXlWeTBicmtPeDhwZ0Ru?= =?utf-8?B?c1lOODdWL3praHZqM3NvdXRyMFRPUG1IZ0NlM2hnUjNIR1MyV29tSjg4ejBk?= =?utf-8?B?RUk0ODFTYkJUYjgza0g5THBPaFgzZFhLYS9iTVNNRE9UWVVqUkFhQVpiS2ly?= =?utf-8?B?RkZLcDl4YnhpQVYwQlh3WEhScm5WNGdvdUJvRitKYk5JeVlFVFVsSjlCWHF5?= =?utf-8?B?KzNmSEJJWjMvTzFiUFREMWIvK1UyRDNXSXQzdXpSenlxUWdRYnA4Q3lqeFhH?= =?utf-8?B?L0VwUGRBYXJaTUhnZWhNMDZMS1U3a3BZOWNNb1g4VHVNTU50SXlPODhqeEg5?= =?utf-8?B?WHl1RDdNd0dmMHd6U21zdUN5YUhNc3dmNWNnWUNZMUZlcEpUQ0hMR256YkZM?= =?utf-8?B?RmxhTGpJSkRodmtWKzFzM3YvQlV2R3dYLzl6cGduSkJEc3Q3K2tNRUEyQzlw?= =?utf-8?B?NGdGQzcrU2ZtMWFVTWtPZUdFalh2VHZjbndrWmFxR21QQThrMTZSNzZPNitV?= =?utf-8?B?TWdqV0k5Y2dxb3MzMkJFSVBHTU93VWVWMDI2Nk5LNGpFNzBmOHZMSis0TXZO?= =?utf-8?B?M3NCWUxGV0U4VkxZNWE1ZnNtTW05TTJENkhLVEJHcG8vK28xV2tGaTVNQWZk?= =?utf-8?B?WTZkV3RYdTNvWWdpTG90cEZPNFhKai9PR1VOeGdFY3NESnh4RFMzNzdzN3Az?= =?utf-8?B?L1Q2cGczaFFXVFFqbmdZOFRtUHRYeFBsajFSMVA2aWhTK2JkeDJ0bXBJSUV5?= =?utf-8?B?bjE1R1cyVHduZUFVbWlQZTJ1aW53dGtmRGZsNGRpdnBiRVZsbHErM0JXTytM?= =?utf-8?B?dTJxUXpicURkMEVYUmgvMmJJNlZ2S3M4L25UWHFtRUhqeEN2bFVVUHp2SXI4?= =?utf-8?B?RlFad3l6c3dmbFRsSHJoREhPTjlibHhmc1YvYTd6dDNhdXVzRXFQUEhVL1JP?= =?utf-8?B?U0Z0d3R5WWR4aGk5SlVld295SHNXVFlkOTJEeVJOU21lb1dZZ1hIbGhpS1VW?= =?utf-8?B?VXp6SExMOHBCZDRyTEZWczZISVJTank1MjBJMkVmSFVCRUpuVllMQ04rNlB2?= =?utf-8?B?Z3lOa250UHhoajBpaFFubndnTGJRSGJWWmJaWExlakpVcHJwVUNxV21FWnVG?= =?utf-8?B?bVl1V1NYaVY5bUFFVklNZ05GNzByTFhGMFBScDdmbFJzWVZiank5ZWhKcENY?= =?utf-8?B?RDBxdWtOcW1BSGN6Znc0MzBVRjFZQ0c0NmpGbmNKak1UMnpFZ1hlL1ptUkNp?= =?utf-8?B?ckhkeUdvMXpOQ0phK0liNVpJNEw4U0F1Z3pGVkwrU29WTXRodGZiNVpSL1I0?= =?utf-8?Q?sn0fy10H1s30U/aKQLGqfMrjXnK2KAjk?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QjkyT1V5M0xlWHRLQUJ0eFpCbGhsWk5yZ0p6TWF0QUFNcHY1WDlDSXp6NzZk?= =?utf-8?B?R3NEbEhoL1JtbW52TnhOcmRKMU5uT2VVOUxvaStTRyt1V211VnhJWkhnV3hD?= =?utf-8?B?Yjh5N3ZlOWEyYVVIWUpwTTdIb29YYnZXNlZ6UzQ5bmhTMG5Vd2xLY2pFNEh4?= =?utf-8?B?OXRPbGhQSkVUMXpRNndZUG9nalJyV3ArNWRXUS95OVFyYzBhMGU2T1ZjQk9N?= =?utf-8?B?dDJCYkRjem83NnA2WEI2SkJUZU1SSHhPQzRUR0JOVUh5Vjl1Qnd1dWlBdUxv?= =?utf-8?B?QTBmMnlNQlYrTWJPNnMrNkMyTlNzRllmZUVRZjg4MzdFYjBkRnNXZGxYTlE0?= =?utf-8?B?Nks4Z3ROblBPOXNXUWlVVG9xQWw3RlFScTZBRkEzTHJtYlNFSnFjSjlDYUtr?= =?utf-8?B?T0trR2lZbjdyc0ovU25qRmJ6MmZPMTE0d0lsbmJPSnEzWHUxWWpSVjlBMldG?= =?utf-8?B?L1VuK3JDRnpSaXhsMzZ5QzdWamVOdVlqWk03R21iY1ZqZFJNTUpzSUNESk5Q?= =?utf-8?B?M3VYVnVDRnJuRUMyanVNSlludkRYRFM2NGwvK1R1eEFUNUhQVUYzMHBxaXBU?= =?utf-8?B?TjQ3T1A0aVRhc2N6b25pM3Q1K1pXQ1Q5bXkwM29OQ0I1VDNXUlo5eUYrL241?= =?utf-8?B?bHNJTk9vOVRXbURud0hoM01QZ3J6aGU5RGYzcnNUR1ZZWHVJbHpxQzFWcDRL?= =?utf-8?B?YS83YVc5UEZRcUdKbFY0cGlvKzJDd1RvREpwTkNyNjVsRmxoQXNac0F1dTFM?= =?utf-8?B?blF3OTF2SFRobmJGak81SVgrZUFKbkg4cGhzS29tS2ZNU1ZiRmZkMDJzRmFl?= =?utf-8?B?OURBTmE4NlJrSDZCamZpcjVJZmVWeXhodTdSSG4rMHphUWgzL25SamYva0tL?= =?utf-8?B?RDQvejlGV0dUZXVTRXZEc0hUQmxiblAvNDBqMDFsL1Y3djV1cEZTR291bXdB?= =?utf-8?B?dkdLRkNqSEZCQjRhTHdXeDViOEltb0wwallITjBzdG0zOEtUN2N1UkZoQnpY?= =?utf-8?B?SlcwejVmU2lRNm15ZjVNQUxxSFFkUUc0aGowUURiWTVLM2N1K09FZE5rOFNy?= =?utf-8?B?YU5zb0JGbzNvZ295ZS9TSG9ydzVpUU43dTZuTmRMU3lJYSt4TDUyczI4WDFH?= =?utf-8?B?ajhENklaem1Ka1RLMkpMZW1HdnVod1FycjN3WCs1T3BUNDlTZnRoRXVYRjdo?= =?utf-8?B?Zm05TXVzaHk4YnJ3dFRCQVMxRkhQTXh3TmlWLzk2V0EzOXdNQkJYRjdyRjhG?= =?utf-8?B?SEM2bGsxQnJUMUJ0YW9lOEpTQnZLaURMTU1UcHdQdHhpcm9NMGRHc1RTOUp2?= =?utf-8?B?ODdXZjc1eEJJWmlEQW5WZlJ4Ky9DT1lEODBHZDdnRytMK2N2N0lYSU1NSTFt?= =?utf-8?B?MWRUZXRDZCtlK3l6STJNczFLYUpmc25LcjhCQ0kzYVh2WDg5ZVlYV2pGRHlE?= =?utf-8?B?cjk0QlJXa0xJMUFZdjZUTW5pRi9uc1lIT3N1bU8yVTFONkM2clJDdCtQNDI0?= =?utf-8?B?STdYcE1IYkFaV2FOUHlwTlJTQ2d4enYxMzZmMVFCQVV2QlNUc1RZTGExQWtK?= =?utf-8?B?ZzdzekRFVjJzbGthZGRISUR1dFpTQ1NuWk91aTlyTXBUR2xPZURnblBjWmNq?= =?utf-8?B?ZEVUd0llbVBZRmpBc2xzRVp5ZDBkcEVaQmlQc055TDVPdVFSZ1p4QTB6bDhj?= =?utf-8?B?L3RSMS9sajdtVVM5bk55SGV2RmxNeXdFWkhuVFpKY3ArV3NoRFBlNGFpK0tB?= =?utf-8?B?ekd3SU1SUjNuK1QyU1lpeExOSXhIYkM4dmhUZ0VUdEtPZyt6dHRNUFN5amxY?= =?utf-8?B?U1ViUU50NFJqNWV3aHJDQi9XWUxRQkFVZWhXRWtSZng2MkZ4K0VoSVNHYjVX?= =?utf-8?B?OTI5Nlh5YU1ndjFBT2dYVFpCNW9yKzViOTN3TEs5TVhBYlVZMWlkMTY1TVky?= =?utf-8?B?Q2tlR1pQM3hjUUMrUkFMcERUR2xDelpOOHh0ZCt1aFdEYmVKWHJLcFBWRU5I?= =?utf-8?B?KzVrc3lSRHM0WTZWcjdvN3lPNmp1RCt0dnhHMTlldTF3K0RqMG5veExpWU5i?= =?utf-8?B?TWxVd1dGU1dPT2psVERJRk9yQjV5Q1pGRTVPekgwWjhmNTFaOG11cHZSL2FF?= =?utf-8?B?Z2JQUWxTSGJPSUhETnAvaWk5d0N5YVRVNFJkL2RTYkpWalBpdWZQQkRZK3E1?= =?utf-8?B?bWJxNXpGRUdBaDBmTkFGVmxQeUVnY1VQUmVZNFJPUUxBR2xRcTllVXVGV242?= =?utf-8?B?S3pNbXNvRkhDUmxUL3ljOU1JQkFvanhIN3hSdkJvWEZpUzVCclNyN0ZGaVN6?= =?utf-8?B?TnhTdUVoRGZVRU1ycGlEdXVrWU1Dbk5CRExOMmlObzN3SlBvRkoyZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3bca35b1-6b21-4adb-06d1-08de52ac3aa0 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 14:01:20.6994 (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: D0fbmlCDYETZP68rsBcv2ApdGgWOr+gEht298GVnJpBo3F8d9iXmgFBxTR5vU0XfIixZBAOuATNdAfZ6KlaltQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA6PR03MB7735 On Fri, Jan 09, 2026 at 12:19:26PM +0100, Jan Beulich wrote: > On 08.01.2026 18:55, Roger Pau Monne wrote: > > The current model of falling back to allocate unscrubbed pages and scrub > > them in place at allocation time risks triggering the watchdog: > > > > Watchdog timer detects that CPU55 is stuck! > > ----[ Xen-4.17.5-21 x86_64 debug=n Not tainted ]---- > > CPU: 55 > > RIP: e008:[] clear_page_sse2+0x1a/0x30 > > RFLAGS: 0000000000000202 CONTEXT: hypervisor (d0v12) > > [...] > > Xen call trace: > > [] R clear_page_sse2+0x1a/0x30 > > [] S clear_domain_page+0x11/0x20 > > [] S common/page_alloc.c#alloc_heap_pages+0x400/0x5a0 > > [] S alloc_domheap_pages+0x67/0x180 > > [] S common/memory.c#populate_physmap+0x22f/0x3b0 > > [] S do_memory_op+0x728/0x1970 > > > > The maximum allocation order on x86 is limited to 18, that means allocating > > and scrubbing possibly 1G worth of memory in 4K chunks. > > > > Start by limiting dirty allocations to CONFIG_DOMU_MAX_ORDER, which is > > currently set to 2M chunks. However such limitation might cause > > fragmentation in HVM p2m population during domain creation. To prevent > > that introduce some extra logic in populate_physmap() that fallback to > > preemptive page-scrubbing if the requested allocation cannot be fulfilled > > and there's scrubbing work to do. This approach is less fair than the > > current one, but allows preemptive page scrubbing in the context of > > populate_physmap() to attempt to ensure unnecessary page-shattering. > > > > Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed") > > Signed-off-by: Roger Pau Monné > > --- > > I'm not particularly happy with this approach, as it doesn't guarantee > > progress for the callers. IOW: a caller might do a lot of scrubbing, just > > to get it's pages stolen by a different concurrent thread doing > > allocations. However I'm not sure there's a better solution than resorting > > to 2M allocations if there's not enough free memory that is scrubbed. > > > > I'm having trouble seeing where we could temporary store page(s) allocated > > that need to be scrubbed before being assigned to the domain, in a way that > > can be used by continuations, and that would allow Xen to keep track of > > them in case the operation is never finished. IOW: we would need to > > account for cleanup of such temporary stash of pages in case the domain > > never completes the hypercall, or is destroyed midway. > > How about stealing a bit from the range above MEMOP_EXTENT_SHIFT to > indicate that state, with the actual page (and order plus scrub progress) > recorded in the target struct domain? Actually, maybe such an indicator > isn't needed at all: If the next invocation (continuation or not) finds > an in-progress allocation, it could simply use that rather than doing a > real allocation. (What to do if this isn't a continuation is less clear: > We could fail such requests [likely not an option unless we can reliably > tell original requests from continuations], or split the allocation if > the request is smaller, or free the allocation to then take the normal > path.) All of which of course only for "foreign" requests. > > If the hypercall is never continued, we could refuse to unpause the > domain (with the allocation then freed normally when the domain gets > destroyed). I have done something along this lines, introduced a couple of stashing variables in the domain struct and stored the progress of scrubbing in there. > As another alternative, how about returning unscrubbed pages altogether > when it's during domain creation, requiring the tool stack to do the > scrubbing (potentially allowing it to skip some of it when pages are > fully initialized anyway, much like we do for Dom0 iirc)? It's going to be difficult for the toolstack to figure out which pages need to be scrubbed, we would need a way to tell it the unscrubbed regions in a domain physmap? > > --- a/xen/common/memory.c > > +++ b/xen/common/memory.c > > @@ -279,6 +279,18 @@ static void populate_physmap(struct memop_args *a) > > > > if ( unlikely(!page) ) > > { > > + nodeid_t node = MEMF_get_node(a->memflags); > > + > > + if ( memory_scrub_pending(node) || > > + (node != NUMA_NO_NODE && > > + !(a->memflags & MEMF_exact_node) && > > + memory_scrub_pending(node = NUMA_NO_NODE)) ) > > + { > > + scrub_free_pages(node); > > + a->preempted = 1; > > + goto out; > > + } > > At least for order 0 requests there's no point in trying this. With the > current logic, actually for orders up to MAX_DIRTY_ORDER. Yes, otherwise we might force the CPU to do some scrubbing work when it won't satisfy it's allocation request anyway. > Further, from a general interface perspective, wouldn't we need to do the > same for at least XENMEM_increase_reservation? Possibly yes. TBH I would also be fine with strictly limiting XENMEM_increase_reservation to 2M order extents, even for the control domain. The physmap population is the only that actually requires bigger extents. > > @@ -1115,7 +1139,16 @@ static struct page_info *alloc_heap_pages( > > if ( test_and_clear_bit(_PGC_need_scrub, &pg[i].count_info) ) > > { > > if ( !(memflags & MEMF_no_scrub) ) > > + { > > scrub_one_page(&pg[i], cold); > > + /* > > + * Use SYS_STATE_smp_boot explicitly; ahead of that state > > + * interrupts are disabled. > > + */ > > + if ( system_state == SYS_STATE_smp_boot && > > + !(dirty_cnt & 0xff) ) > > + process_pending_softirqs(); > > + } > > > > dirty_cnt++; > > } > > Yet an alternative consideration: When "cold" is true, couldn't we call > process_pending_softirqs() like you do here ( >= SYS_STATE_smp_boot then > of course), without any of the other changes? Of course that's worse > than a proper continuation, especially from the calling domain's pov. Overall I think it would be best to solve this with hypercall continuations, in case we even want to support pages bigger than 1G. I know this has a lot of other implications, but would be nice to not add more baggage here. The "cold" case is the typical scenario for domain building, and we would block a control domain CPU for more than 5s which seems undesirable. > > @@ -223,6 +224,14 @@ struct npfec { > > #else > > #define MAX_ORDER 20 /* 2^20 contiguous pages */ > > #endif > > + > > +/* Max order when scrubbing pages at allocation time. */ > > +#ifdef CONFIG_DOMU_MAX_ORDER > > +# define MAX_DIRTY_ORDER CONFIG_DOMU_MAX_ORDER > > +#else > > +# define MAX_DIRTY_ORDER 9 > > +#endif > > Using CONFIG_DOMU_MAX_ORDER rather than the command line overridable > domu_max_order means people couldn't even restore original behavior. We likely want a separate command line option for this one, but given your comments above we might want to explore other options. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jan 13 14:13:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 14:13:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201761.1517337 (Exim 4.92) (envelope-from ) id 1vff8s-0007q1-PX; Tue, 13 Jan 2026 14:13:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201761.1517337; Tue, 13 Jan 2026 14:13:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vff8s-0007pu-Li; Tue, 13 Jan 2026 14:13:06 +0000 Received: by outflank-mailman (input) for mailman id 1201761; Tue, 13 Jan 2026 14:13:05 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vff8r-0007po-FR for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 14:13:05 +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 f8489090-f089-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 15:13:04 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by PH8PR03MB7198.namprd03.prod.outlook.com (2603:10b6:510:25e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 14:12:58 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.005; Tue, 13 Jan 2026 14:12: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: f8489090-f089-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vbmYkImxet441lVOcXZPciKKEYzkysjiet3zah3qMPOFOtwBeVe3yUofbdvq7e4r1ea3P1MGjaWp9dyMU6yfb2Y7R/oBBLmy212VBK4n6RynUgB6cUCBzydk+hEUcf8iFIxgoBIlB3p9SPRZ26cQVW7G0/uEfb72I0ktXYQ9+IXtbDIoCeMv4W9insPZuwP7D2flpxGTysSlWYxuB+wz0kdvDfyfifTKCpLWzfe7YU1ig/7IBV+wHPdQUYtNCH9JpAyBZlma+vR4acmtVTo0JRKjrJOmePABtCRtQtZKvualSrAWaGRz8P9x+bxst3dz1/zqS3oRHTj78XjaXwXEAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Yu8I3qWsT+y72B0Q+OIT3HO85vcIczPXvDL3gMdtiFI=; b=AuUKbf6wJIass4AQy65eZKJPmvDCA4TPbs70QiAcM9CNUd/utj/JRKiTjGeiIVXxbGlX//d3K4fZw1QKgKrZ45Em0Jf+G9HZn6DfxrPo74nQwQd9gqwCUVlEycuHb0j2FvJixgaErrZ/dTskeiEIeOPijwx8vRnORRR9xmkDvxdRNZHjntPCp3eezTB7dbTHFdgEId6/MtvZxIb5hWSMUdS2be6ktZ0b5ZLpcW0+kBggnvXGFvRin/4od5NhLd/4zi+18b0Pn8JE++AzgjMQfeEoMfwR3nwyjnQ8xhJ8ZIYbl9odq87/VU6C3pCTH9f9yK4dW66JBcIkGAKuRUNebw== 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=Yu8I3qWsT+y72B0Q+OIT3HO85vcIczPXvDL3gMdtiFI=; b=ZhYy+GhGpDoaFoJiX1tUOakoXK7gUrSL5zystqLN9BSlQd3jVNPxX+CjqTQAk6kAmBoHZIbnOzSAaQY5sS3NY9DOo0WLOP0ENyKFSKG90yZ+Jcj9EGD0qOkp9lMqsEJbptNHX8YEimcSFxAkd1qVpiR7HCn5thx/9hraoxcf5Vs= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Tue, 13 Jan 2026 15:12:55 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: Xen-devel , Jan Beulich Subject: Re: [PATCH] x86/cpu-policy: Filter out OS{XSAVE,PKE} in calculate_raw_cpu_policy() Message-ID: References: <20260113134719.1047476-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260113134719.1047476-1-andrew.cooper3@citrix.com> X-ClientProxiedBy: BL1PR13CA0331.namprd13.prod.outlook.com (2603:10b6:208:2c6::6) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|PH8PR03MB7198:EE_ X-MS-Office365-Filtering-Correlation-Id: 5d747693-e2c6-4855-d453-08de52adda4d 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?Ykh0dHJWeDJha1FPYnJiTDVRaS9CQ3EvR3lWemJLZWRjcTlpb3RRbG1mUXQ4?= =?utf-8?B?dGRWQ0dQOGNEdVF4cmt4RURtbHNGSjRtbitqRmtrR1ptcUFZcWtrN01UV3ZD?= =?utf-8?B?SmQvNmJQUUxkbjZ1dnhmZjlWT0dyZWVmYkVhYjEzMlJEbUpPd0hhMDRaVFlm?= =?utf-8?B?OFBWNnpkVEp5cTlBSXJaMlJLQ2dpVDl4SVdSeVJaYnV2bU9oajFyT2pKZGJa?= =?utf-8?B?eUNNUzFZQWVMc0U1b2k5bHQ4MlVZSXdRMk14bUlhV2VuOU9FcG45NjN2c1ds?= =?utf-8?B?NHN5blhDUVFtc2cvL1VpV29OL1NFTkJQcUcvRzFiNW5wb0dIVUMrbFBLL1JL?= =?utf-8?B?SmxVa01UMFlPRWQ5eVQ4b0JQMmJ0Vml5MHprbmNONll3Si9HN1paLzErN01u?= =?utf-8?B?SEd3c09DZi90cFArUy9DRnNOTGRlSUgvb1RMMmtDYXVieG9wVnBxMmh0RWlo?= =?utf-8?B?bXpiU0NrS2p6cWxlNXJxV2hSd1FENkR0T1l3K2xmZUhkdEVrcDR4Vzl5Y2hN?= =?utf-8?B?RGJkcVFvUWpXQ0xuNkV5Q253cEhiVDc5T0JZQ3cwMVpDYnJxS0puRUtDWE1h?= =?utf-8?B?eHNRNTdDUXgvQjVrYk9WVWc2ZWNRdlNGZHUrd3A1SXA1eldYUDZQalFaRUFQ?= =?utf-8?B?V0JraEh5MFZ1L0JIT3lGWDh5Z2IvWjRHaXQzZUdpcnFmbEF1M3hIZTZpL3Zr?= =?utf-8?B?UktIMVM3cUVGRng1SXdJdWZIMGVnQ01wSXh0VTQxZ1hyTnFoWnZ0OXl5SXRT?= =?utf-8?B?OENJNFpVZU1acXhrdG41dmwrZTBpa2RtMnAybmsxS2xCUjFFS0gra3hyQVdu?= =?utf-8?B?RVBmUGtzMGtFTm4wUjdrbUZmMk5mWTNtUkFQN0M3SmJ5ZElvWW04UTVTKy96?= =?utf-8?B?NFNpUlRoUEc0OUh6YnRtdnQ4bDRjeDdEZjcwcnF6ekpSY0RXUUNiTjNlNHNW?= =?utf-8?B?eDdPRHQwTTM4SDFBaWowcm9xaW9vZmNyc3BNRTE2RzNSeXdBS1lHa2tDZTZM?= =?utf-8?B?WlUxc05rMzlsa1JtV0hPbmZjVWo5SEtNV29qeTB3WmRnbmM5U1lSdHpNUGZY?= =?utf-8?B?c1NQU01sTmw4T3dTZE1IRXR4a1U2aEVzdStpZkN3M3JnRjNCNlRtUzZMZXFE?= =?utf-8?B?WnArQzZjWGhobHp2WHNvZit2ZUNKVTl6NDRnd2NoY0MwM29Vc25NdFF0U0VQ?= =?utf-8?B?Nmt2WFEzRHVZL2lOd0hQLzZkd1dkQWZjTzVOYnEwSlVMV0taTW5iRHQwYUdC?= =?utf-8?B?Nm0vLy85ekpuM2E0c2Y1UGxUQXM0RTFDdEtLYU5NWnF5THNnR0dtbWNnU2Uv?= =?utf-8?B?bTNjb2NBYTAxTGpvcmVQTjZXY0Z2ZnFJbEt4SEZVdWNIZGxFYWNIaW1Sd3dM?= =?utf-8?B?S2JFWWFYTnpqaHJ6aEloVmgxNm1nVVNRR2xLWklsUkpiTmtrOGFvVFc4bjFI?= =?utf-8?B?a1pRSjFlb2FhS3BOSmpRZXk1bncwcFg5azVsMnhsa3F6OWl3b2F4U1ZTWFlz?= =?utf-8?B?R0FudUJmN3pwSGNnV2l6MEFZUEEzdEcrL0ZlVlpwNjhlVWVDOFBpSUx6bDBo?= =?utf-8?B?VU0vUUJKSjRoZnFROHpxeUlQSlN4azR3RnROdnpYdmtQdmRIaXM5eFJ1d0dr?= =?utf-8?B?cWp6SDZZaGo1V3h1dWp6S2VKd0YzMjFaK1JnK2FtMUw1b1cyNXQzWXo1a3hP?= =?utf-8?B?WXZvRCtpUDFLZEtsODcyZEFrVndHYzRYb2dVeDJxdENtUSt0dkx1bHBsNklX?= =?utf-8?B?MnBmcXcyUzBzN1h3UG9URFBUa1RDUWxyTEJzYk16aXVxQW52Wml0cklSMVIx?= =?utf-8?B?aWEvNWMxODEySnFRdWZpdThySUNaREhmeTBZS2pvTE5ybURKS2ZXWXRIZ3Zw?= =?utf-8?B?M04veDYxOU1YbHg5ajlPY3lZN0NFczBTc1RET2k4SFlsWVE1SVVZc2FURzJL?= =?utf-8?Q?XXVMkNWfqqp/qxlVWjpdTRH7zMRJHN5h?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cFlMN1l4WklweGUzRm5VRHg1b0J3YnpUVXNjODJDM3VWNXV1bURLM2VjQkpx?= =?utf-8?B?MHJ1ZEhsVWhuUXdPOFFEdUtIbWlNWDE0SkxqZnBZNGt3dXNBMlBhWit0aTJI?= =?utf-8?B?c0RhbXp4SExISVA2d0VoRVdZQW9JUjdDbjg1TXhSeXZRSXl4em8wNy96SCtK?= =?utf-8?B?RkFPVmdxMlFZVFVXZXVUdTJQWkdOcnRBRWRNQThzK2ZURkdtVHlLaGdWUDhW?= =?utf-8?B?c1NIRWJub3BlQVJ3QlVDVWJpNVlZL3NRZEcxR3FhcFJETEhuYUZKc0x5bGZ1?= =?utf-8?B?ZjV1RklsdjZIbHFsYWMveDNEamVpSTlQT3B4Wjlxd21pbmwrMEx6YnhpaldO?= =?utf-8?B?cUhSZ2dGWmUzVUxxME0yVktIYnU4SHhFYi9rdHN4QWluZDdjcGZ1ejdHK1ow?= =?utf-8?B?dEhHUFA1VTFuRFJyVC91Q1BoRkxia2FnOXFTWFlDVGI0cTROaE5TT1FjWWFZ?= =?utf-8?B?QnRmSUd6VlJ6UC9XTFRCNVlucG5mVDFRdCtqc3p4MWpWS0R1R05qOUhpcXlh?= =?utf-8?B?UlJ4ci9LZCtRVlZuMUJOZHJIaGNoWnlId0hBdVU0b2R2alpYTVVkMzB2eHFT?= =?utf-8?B?bnJLRnZEbFNIVWRpMXpVWDAvM2phUlpmVVhSbC9pSFhVL291NUtaYi9NajdH?= =?utf-8?B?M0htb0dEcUxYVXlZaUVoYk1XSWs3Q0FjOW55c2ltdDVsOFk1cnJ5R1E4QTZs?= =?utf-8?B?VTR1Mngra0FaNVoxUzNZQ0pyTmw1VW1nU0lQZS9TcFpYZGtkRktjRnh0RVpG?= =?utf-8?B?RGE2dUF0OWt2NnVHUTAva1lNbHRYZVZibWR0bnE4U3g3T09ndDAvelB1dmhC?= =?utf-8?B?dXUwb1pEWEhEMzJ6UHcwWlgxdHlNMEFqbXFEREJVa0lTNjF5ZmhSTW9SUy9p?= =?utf-8?B?SkRRbk40VWd0VGxLUStjaUliUmROVCtLVzExNzMxSng5Y0YwMGgwamhEbnpn?= =?utf-8?B?NWFvajlWeXpydHpyaEk2ckRBV3RqZnhCdWNmalFhYVJUdXpQT05QOU4yb0dZ?= =?utf-8?B?MHZTeTR2TnVWQUYxbjVTMVBKYXhxZFBFVlczL0k3dXhNbEdqRmVNYWg4VGFF?= =?utf-8?B?Y3p1ZStnTTV2aHVxcEhIN2ZUemF1czNqWjI4eU03ZGw2c0ttTUFhZWNRY2VL?= =?utf-8?B?QytlaUtyUkZyYThIVWJPU1VaMG1MOSsxRm9lSGFKV05LZVcrSWVKMzlrWGNE?= =?utf-8?B?Tk5hOHYza3NRYzBvcnp0TFRVMTdoSjNuRzJldC9UVjNPWUdWZzlIRCtYUlFT?= =?utf-8?B?VFN3RVhMeXpQTklGazdJcFVyOUxNeTdXUVpURTg1eG1ScE5qbW9oa3BWTm5B?= =?utf-8?B?VUgxaDlYM1I2bC9lc0c3cUxvU3B1TUdaR2lsVnZWQU5QdVpFczloODIzYWpt?= =?utf-8?B?Q3pVeCsrQmVNdDd5a2gzdTVyWFZhekEvQ3BnL1pocTd3c294YWVJZ3NFKzkw?= =?utf-8?B?bVhUNFI1eGdiZTQyeGRXd3o0VGdITXZMTWZ5aEo5cHhDQjhEcHhQSkE1blFr?= =?utf-8?B?SXNSM3RYcnBFS2tsNTVLWk1UaHJpN2d1aWxKUjVnbFlOTlBFbXN0bHVKYUdT?= =?utf-8?B?RFhmSjBZYUo1ZjhIaE1RMHJ5RlpDOGY4OVF2YS84WlQ4Yk5oQlowWC9DRjg0?= =?utf-8?B?R2dnaGFlNHZJMHFwL1BBcU14alNUZThGVGhwYVRDOUVLYlJsK1hIRWxQSW1Q?= =?utf-8?B?bkJtWk02ZzNNVHVaM1FTNCtURkpTc3lKd1lSdnBYOWVTRTRuUVFlc2FIcGZs?= =?utf-8?B?YVJQMmREbWU3MU9UM1lzZ2ljNzE1bUJURHJsWnZrT1ljVDAxWk9yY1F3OFJH?= =?utf-8?B?eW9xSDFDQldxUW5zb1pvNGFyLzRtd0lNM3hxTk5XdUMrOGpRTmFQOHArUWph?= =?utf-8?B?bEVIZXpMR0tFSzljbmluMytiOFM2QUJEZEhEaDBrMCs4Zjg0QytQYUVweDFG?= =?utf-8?B?dTRvWWhkSjBZdkZya3NXU2tXNHVhcjJxUTlva0FGMGM2SnVQejRYdHd5ZHlY?= =?utf-8?B?RlhIYk9TTjJxOVVnL08xMnVTam1HdHoyNFkvTWpwbzdoZG0ybm1aOUNOdjFV?= =?utf-8?B?cW5ENGJTeHJlMlcveU51Sm5TS0xPK1hOdGxlYnoyUE1HalFOTDVNYTROdURi?= =?utf-8?B?c29Kelk2Uy85aWJZbDA0eE96THRMb3FseURGRmV5Z3owc0U5bDFvVXl1YWI1?= =?utf-8?B?dzMvSzNJcFg0Y09ubS9nSTBZTlo2WGxJWlp0cURiR3RRUjZ0WUllOEhaNnhm?= =?utf-8?B?bDErUWhEYStrK3lxemhyWjZvZVkxTXY0M2FUSFRuRFA2OE1tUkdXMkFWQUhX?= =?utf-8?B?MHNmTzNEL0pRbDExTTV2d1o5NmtRL2ZJdGcvTk1uRDR2WmVWMFo1Zz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5d747693-e2c6-4855-d453-08de52adda4d X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 14:12:58.0445 (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: PLc67SiuUp5KZ7uXvCW32aXc/gV4FX7s5ixfx22I7v3VOUS3OP9qeQEp/R1ZN5mKCwWr0BERojOjt8yacj/9xA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR03MB7198 On Tue, Jan 13, 2026 at 01:47:19PM +0000, Andrew Cooper wrote: > They're dynamic too, and don't have named fields because no (other) logic in > Xen ought to operate on them. In particular, OSPKE being visible depending on > whether we're in HVM or PV vCPU context when scanning. > > Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jan 13 14:17:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 14:17:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201772.1517346 (Exim 4.92) (envelope-from ) id 1vffDM-0008Ux-8U; Tue, 13 Jan 2026 14:17:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201772.1517346; Tue, 13 Jan 2026 14:17: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 1vffDM-0008Uq-5v; Tue, 13 Jan 2026 14:17:44 +0000 Received: by outflank-mailman (input) for mailman id 1201772; Tue, 13 Jan 2026 14:17: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 1vffDL-0008Uk-7u for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 14:17:43 +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 9e8dbb36-f08a-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 15:17:40 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by MW4PR03MB6865.namprd03.prod.outlook.com (2603:10b6:303:1b5::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 14:17:36 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.005; Tue, 13 Jan 2026 14:17: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: 9e8dbb36-f08a-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=WbUcC+3Aygqb9EmFy6w1uwPsnq/vTRE0nliwTxMmrNrrACECXyGhBZ4yRgdxkscnGMQl1xaPZS7DKYjk02ao7MCTaGUfNx6bfoFbpVKIBCyyhkpSR1lsj89C+JbAmDSPL8c6ZSHj4CvL65uopOjG9W7hKKgc4ehZINnsQLWz4CBULCSB3kzg4KJwjvUHHcCQ9BEeehRyQOi1rTPo4yrOGwXme8lPbgApArN1M1JoCDYIavGFGj5Gi3FJpcewYOK8dU8pJ4NTqBQKa4iBLhLbR+0Vx0v25IuaneNgLKj0oDDtb4XQZ+o/7WQWUR+bjA2LR+cOFERF/D8s5HhlGvLT1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=58bMqXgpPTnxmQ/kqdDpy8DKpQ6x+tmiCu3NwDspKi4=; b=Glsaxbch5cvjwV6eKLlN8k1F+zLnxquljOzlxzxRtnltAqgZsos2nzJXSfSqm2+UcBmgde2KUK5GO/jqs3snxJ+CI4mr8oEbnJAaqAL8I2nFEPbugNtksTMjBqgamLxJ1FTUmcGwTBri2foRusGgIXvIzM2JpYzWfUs+kkSNwEF0+w+qtq/XbW6mr4jCQjOqSgGGUzGhuIaFFbhSaWJqI7Xs0vFaQ+cNWcQhcgPfmdOmqRsfsp/Z97Ax6jr8p1R9rc1snJ6LnucGCtrk52ZmslYR6io2Do5wQPM8H+LunFwNizOHIOL6hWK8R7Gz69OD8vqY+tmLgjUq/RjszKi2bA== 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=58bMqXgpPTnxmQ/kqdDpy8DKpQ6x+tmiCu3NwDspKi4=; b=aFqhScK9VzL3jGBN3m+bIkjpsuhXlfodWx8uGCElj7/l7p1Svd41VTMuIEs05oDiQjlqkMZ8eVsrFi43gf3A0AGyIYVmbKxIxmqEtJhQd4CkQzFyNyNl0os6fsfldFLFvviH3M+G62G3sTBgdlsSArQnp4GnYbDuRoQwgEhx7Ag= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Tue, 13 Jan 2026 15:17:29 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Alejandro Vallejo Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper Subject: Re: [PATCH v2] x86: Use 32-bit counter for TLB clock on debug builds Message-ID: References: <20260113120959.55156-1-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260113120959.55156-1-alejandro.garciavallejo@amd.com> X-ClientProxiedBy: PA7P264CA0116.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:34c::7) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|MW4PR03MB6865:EE_ X-MS-Office365-Filtering-Correlation-Id: 4e43476b-f854-40be-8dab-08de52ae7ecd 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?a1pibFdxN0ZVSEVvRjlwUTFUTXJtQWl1RDRLczlDR2JNYmNCVFV0K3Y4Y3hB?= =?utf-8?B?Y2lWMytMZURmemRFTytFaFl4OHhOejJVL09LWEh2M21kdStEUlE5OENzVU1n?= =?utf-8?B?dko2S1lTY0tFZitrNFpKOUJLZDZNemZhSGY2QTVJYjRGbFpUQWNtUTJGTVJy?= =?utf-8?B?ZU93N3pJTkx4ZVBXNmM0bVlyWXVNUmVTM21mS0Uwc1V4WkZlZWhadHNwYWZh?= =?utf-8?B?Tk1jNW1vSTQ1eFYzMVo0Rlc1K3FVb25XVG5nV2ZVYmZoOFBkQWVIWDZXTVo1?= =?utf-8?B?NWhRb3BXMWZQSjgvVUpTTXB3QVJUVklCQWkwdWF6aXNoMXlQamxLYUxqQkNq?= =?utf-8?B?WitDU2Fac3h1cm5hSUwrdUZoQTd6TFAvV1lNR2o0VERaSzVxZ3E2TTNhQi9F?= =?utf-8?B?aEZwSHFmZ3E5VmtqSTNtL2U3Sld3eXhlZ2x3NVB3UFZVVnptWkExcVdVVmpp?= =?utf-8?B?UytaVWNPeHNxNXBTd0VnK1FxSFNQWTNRd0N1T1luWXNKeXVxY0pOWERmSHZX?= =?utf-8?B?U2t1bGY3T1NDTitXemRTNFNORkp2MGUrUUFjWGhTS2RQaFlaYW1pMFpFK0xU?= =?utf-8?B?eWFXblMzZXYySUp2WWxMOHVSdUZXZm13OENENWVwbHNFYXVaSXhvN3c2b2dp?= =?utf-8?B?SFRHRlpkaGk0N3lZRTF6WjVBWDJxY0RJNE1NNkNoVTJJcVh1TmJSNWVYZTZq?= =?utf-8?B?bG9WS1U1ckY2VHhtREo2dS91NnhCQllMbDhxOTRKTTlxK3lBMHBrM2pzZUZR?= =?utf-8?B?Z0tBVEZrZXhoTGxiZEV0ZFNJQjNLUGtja1pkYmE0cDNocVpLZzhLSU9YQkwv?= =?utf-8?B?NmFDVnBmSnhOYW9rdkUzbXBkYlkzcS9kM1hnZHh0Y0QySnkxcDM5SHJoNlR1?= =?utf-8?B?MVB6VURwSlJPR0FaNmpYbmFLU3ZYeEUvRHN5OHFjUDN5dEhVT1JReEpRdEQ2?= =?utf-8?B?QUJta0tPK1JRZ3duMFU0NWlwQ0xPNnpDczhiQkQ2UnhjLzZ5MWR1djVnVVo2?= =?utf-8?B?Mk9UeWdwTTdxa2VqRGR3NHFTYm9SRGwxQ3drcEZLUE9KeFJleUdKeGdLVmt4?= =?utf-8?B?dEU4djFDcEtLOS84cWgyZnVoazlPU1NWL0ltc1Y2aUo4MmN0ejFpZ2ZSUVJC?= =?utf-8?B?RmovZnRyeVhYb3dhaFIzbHBnaThLM2Jyamd6OXg5QlZnbWJvK2NucFdVbkQ2?= =?utf-8?B?TXFub1BkUWlMV3J4Y3ViNFFLMVhWazE4TVBlSm9WeGN1ek9VMmREMWtUVDRa?= =?utf-8?B?MTBUN09XYitKSTdrMElHSDFRbXVrTnFsQkI5SlQvV2FDcTZoYW1pM1ZFWWVR?= =?utf-8?B?TDRkbkdFZmdtZ0Z4eHlWdkh0QjVaT2x2dUhCQ1JIQlpyOUlKV0MrbGVXNjZQ?= =?utf-8?B?UmRPWHpRd1IzZzlHZlhtY0tyNm9UUDVJYzgzV1ozZDlmM1g2QXZrMUFSY05M?= =?utf-8?B?Z0RIQXlXRGg2M1lXY3VYaE9BYW53RVpRT1NGcnlOWHpDbmRvN0JSdGFXaW1I?= =?utf-8?B?SmJHR1JSUzdwQzlUQTc5VFRiYS83bm14SFZQNm9ZNkY0LzBpdHpBYzZ3b1cx?= =?utf-8?B?MlZsSnNENjNJWWZUZlM3dGk1ZWZENm1oRTU3ZkljZmxJYllrYU5ORUY5bmpu?= =?utf-8?B?L0F0Z3M0bUpvUGRqZHFGY0c4dlgxVE45ZFFoVVMxclVNMk5MMUlDN2M5Tncv?= =?utf-8?B?RjNlUHhrTW83UVBQVkFmRmdZTmhkUmR0eS9zMDUvZUdaTklnbHdSczhOYzhl?= =?utf-8?B?aEV1K1ltb2dDdklIeUJ5VWZNeGt5ZWhCMTFsdmxweUhIaDMyeVZ1d2V4dEkx?= =?utf-8?B?THJkMzVhVUlhQzY2UFJQZ3cyelRhbmtnTCtFelJKSWM4MlhNM2gyYUhWOVVl?= =?utf-8?B?cmg0MEprK0tkbGRTTmJtNUhoQVd1SFd1V3pJWUgvMmJkRXFodXpSZzFCV1Zn?= =?utf-8?Q?D8kTmK8yAdFhPRoD21fBvxFDPz85v7i2?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RGlhNVRDTUdaMkk1RStZempNejFMVXBza25GNnRuS0R4Tk1nSE4rdkpYaGZD?= =?utf-8?B?OWtvY1p3YjBGS3ZROHcvTnRLL3J4MUZzMFh6L1pHa2x4dE9WaklCaGcyTGEz?= =?utf-8?B?OE80VU1iUm5JbHlCYkxNa1dCdGNkMENpMlI2TUQ0eVhXSXJ4VlpDSjc5dStM?= =?utf-8?B?aXBBbGNvYWpGWUZVa0hhMklkcTBmQ2d2eTV3NHBKVWw4a0x0QWttUkh1Z3dK?= =?utf-8?B?cmFtcURzR0Y5UXdZblRkbzRIcXlnc3dDSU9KSUQ2YWZyTnlaMjJqcHU2bkR6?= =?utf-8?B?a1I4N2hOQVhLMGhwT1AxZ29kTXZvM1VpQ0M4OXNnbTVaT2NScThjMElWbUxR?= =?utf-8?B?TmM0UjRReVNzUTY0Vm1XQm44SkRTVE14TEtodEVjYmY4NHUrVmVZVGVFS1U5?= =?utf-8?B?Ly9sOUpKbG1sT090d0Z5VG1xTUFNd1FGUGU1dE8xSTdYakxuSjdMRVVHSG1z?= =?utf-8?B?SjZlbnAvYnQyWVAzRVFSeFRucFAxeXc5eHZ5NGVlbWlQODRzT2thOXU1MEZt?= =?utf-8?B?UXpLby8xNXZJWk1RcUMwZlROWm5WZkozR3Z1UWZtTk52SVlpdGs1aWM4WDAy?= =?utf-8?B?TVRBajludkQ1OXNVRklibGxnMUNIL2JVOFBGT3ZjMnBiU3N6RlhMMWhleXRv?= =?utf-8?B?QTQyTjE4RGpUSWIrZDJ5S3MwU1Z2bnEwcDJVTCtpLzYvVVlIVGxWby9kUWJi?= =?utf-8?B?MGp1WFhqbVR3Z2NPVVJ6eDc5MmtQUlRQVjR4SUFuRFd4MThkY0x1ZVZMcXEv?= =?utf-8?B?SG1pQUtOSGx1OWtIemVzZEtxL2Y5VWg3blBHZFRmRVBaWElYeVFjTHlmU25W?= =?utf-8?B?THJNMGpHZXZNS05SY2psNkxIRitPZ0FBeERENWtZa3BnQ1cwdWh6YWRJOU5n?= =?utf-8?B?Q3FZQ3RwWjNtVC9KNUhWazlpVm8xaGNzR2tNZ3A5RURtUkxyWGhlamdSWURI?= =?utf-8?B?bXU1VThoWlY1ZEJPdk12VnBYSXpYTktrYnFlbUJ1QkovM2gxNFZZZFdWendF?= =?utf-8?B?SG1jSDVxM1VuMGV3cWRuNFZGSTdPVE1CQ0FaRmUrZ2R3R0o1VVJPWGVkMHph?= =?utf-8?B?UzJUTEdidmxUeGk1SG93OFlzclZlQTBETm9pOFhaQ3k2VU5Udmlrb2ZxM2lP?= =?utf-8?B?Z1U2VHpxZzBtR2FXQ1JjT2lISEFSQlJ4SEJuN2ZqeHRMQjRMVkplUUdkWDRa?= =?utf-8?B?MVNIdjNPM0ZsSzAvZlpLMmlIRWZTRlMwZXI3Y2owQmZjWW84blRZcnpCQTEx?= =?utf-8?B?ZmxuMUxDTFk1TEErVWk4MFVia3hRRmU5KzVNVXdkMGJUQm16UmNEREphZ2d1?= =?utf-8?B?V0s1N2tVNXpqblJQaW1CNWpVS0hnR1FOOW1BS1JRUW13WVd3ZVJmWjBxWXJW?= =?utf-8?B?TkRBL3gxblluSmNVL0JJZkQvK2JaN1ZSNFpuNW9LdGNxQkNqby85Z01XS3du?= =?utf-8?B?RDBpcy9VMlBFREVUTFZWWkVGTkowcHRlSTIzTXVpR2FQeEVEQmN2bStka1d0?= =?utf-8?B?TlVuYjVNWCtreGEvTWJkRGJZem1pSE8zZnF4ZGY1Y1lkbGxnRC9tbzJpZlVx?= =?utf-8?B?QXJ2N0hMVHVaY0ladmZVUy9UcWRXV2lKU2VTVzBmejJ0V3JiZFdLREduOVVH?= =?utf-8?B?ODZaWTZ6OG9rSm5ndUlvUXVLUkpDMG1UbGtEaDBGdVZEYzlEMFBiblJqenpB?= =?utf-8?B?YStNaU5hT1lrTGhJVXlKazVQZnZCdVUxMENJcWlWTnFkYTlISVR0UnFZcmZp?= =?utf-8?B?RWd2cnRBc05OTStXS2JyazVyMTRSR0xhVlVLM1JXUHVZY1BtSFNhaVRzU1JK?= =?utf-8?B?UG9uMnY3RTRNWWcxaERDRnhHUzN0QWlPczRITk9pQ0VFTUJUVDlhZ1lpejdI?= =?utf-8?B?aXpuL2FaMHgzTUpIdnlYVjlZbE91LzlEV3BqU2JqK2s0R1JwVUhqcGpwTkdR?= =?utf-8?B?SjJneE4vTnNZaW5jS1FJVDNrUHJ6ZENJUEdkY3hhakZ1NEFkV0pvMWZ3eGRN?= =?utf-8?B?cnlpRVRJU25HWkRVVjg2dkFucXdHWkRiNk94eXUwZlZHdXJpcEd0U3NqZVlH?= =?utf-8?B?ajh0N05mak9BWGFNNG85QmpzQ2NlRW5WWjFUSllXNkpEeVFYdWNWVHZpSzFJ?= =?utf-8?B?Vy8vNG1hRmZPOHZjUXNuemY0NlZuVW15Tm5xRHMrVW80Z21XTTYzMkVDeDdT?= =?utf-8?B?QzFFdWxIOFZ6ejdHVWxMQzBsd1pxR1pVZE1wM1RmYS9DUDRORkRWcEVjcmRX?= =?utf-8?B?RUYxb3RqWGNUaVlJc09rNHZ6WmdBUnBNSVc4cEdSNFJKbHowZ3NVOTZlWjhF?= =?utf-8?B?L1g1UGw5dUM4cFNBS3NmOE5EaTMwY1FTYXF6dzFIUkNRK1gxVXRsQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4e43476b-f854-40be-8dab-08de52ae7ecd X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 14:17:33.9407 (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: HBiApLRnkuP1roafz1Uljy3aGm53r8QMxNTQIsLFM2qwjqFvZH6BQrmm9wcsw+grXqeasRkMSpU2zVos7Y1FZw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR03MB6865 On Tue, Jan 13, 2026 at 01:09:58PM +0100, Alejandro Vallejo wrote: > Debug builds traditionally ship with a 10-bit counter for the TLB > clock. This forces global TLB shootdowns with high frequency, making > debug builds unsuitable for any form of real time testing. > > Remove this quirk, unifying release and debug under a wide counter. I wonder if it makes any sense to provide this as a Kconfig tunable, set to 32bit width for both debug and release builds? Not sure whether there's a ton of interest in stressing the flushing however, and by then it's a small hack to adjust the code itself. Regards, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jan 13 14:18:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 14:18:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201780.1517357 (Exim 4.92) (envelope-from ) id 1vffE7-0000XD-H0; Tue, 13 Jan 2026 14:18:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201780.1517357; Tue, 13 Jan 2026 14: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 1vffE7-0000X6-Do; Tue, 13 Jan 2026 14:18:31 +0000 Received: by outflank-mailman (input) for mailman id 1201780; Tue, 13 Jan 2026 14: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 1vffE6-0000T1-0M for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 14:18:30 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id bb0f409a-f08a-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 15:18:29 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS7PR03MB5624.namprd03.prod.outlook.com (2603:10b6:5:2d1::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 14:18:26 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.005; Tue, 13 Jan 2026 14:18: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: bb0f409a-f08a-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=V4aaWnrL5YI4wo++tUSFnXE6OLj1lK8jUkQEMcTOhMZ6rBEjf7IGQ+symKeu1uoHMecmTyb0gtdrla/kgTNH3KEiJODW0FlhKq0XU0aruRkFSe75jd/0oj9WdPD2iexBszyB/p6tuDeOyy7vzAo4KRnFwiheB1AcX2kPD2gtzyEKBYU0zmz5xnZACyc0bhCxoOu4cXpEuB+a6wqttvXD2gvmgLPpB1Tde/Xf1yr5WMMh8I8husDFc1AI1m0ZpseDnJXxjSLH7DooiihsWcHEAuD0l1bq30L517JkDsdwR4UA0CXql8zV81APtbsID3khVYk9dezoEYALOl8O9n+u9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BP7E1rSjoVW0LODQUbv7IOGNs39mTUraxKy+L+4uw1E=; b=RfvLMNgQ7GXKl/yB40LBuUQm2Nr9eXJ6bQoOoQ2X546IeCN5UUdFa1hjVgn17+wKAB/vCKEVfUH668VKm5hPS2PNrihDqV4Dvsj2Q+qip3WU5kFgMtEwubfGrURjjmpogynxnNp0D95R1e0gwsWr2qpbDZ0TqQ207ucuxY7JFwSW9gZPsXxF+rccvhpiLR+06Tw3UBRZsLxcVaSoLW42giwVqEo70/GGw25kW4cDntT7KeGgDl5yhVvNGO14bJmpl3sSBNjobjpKL+cO0k/G25bFjSBJbcsE42VgAv7FFyz8yRefBY7ooKdGnUgvA469KA+lQTWyiKtomFwkxyZZfQ== 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=BP7E1rSjoVW0LODQUbv7IOGNs39mTUraxKy+L+4uw1E=; b=mH6gwoNkePlieeB/QXJWRBdemSZLKLkoC+A6Q4f5+WIebhzOZfCdn5WXXoISKxunC1SzvZC8Cu2W/X8bdxFfSXVQr+TLVjbtrnSYzBT4bUSAppB2ko7/6hkXS32V0szdlzqeLs9D+xQ/P8otdKqhXtKkzrG9ipM/2q9VZscAzVA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Tue, 13 Jan 2026 14:18:22 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , xen-devel@lists.xenproject.org, Jan Beulich Subject: Re: [PATCH v2] x86: Use 32-bit counter for TLB clock on debug builds To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo References: <20260113120959.55156-1-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0198.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a4::23) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS7PR03MB5624:EE_ X-MS-Office365-Filtering-Correlation-Id: 8120f88e-1b36-4df8-0489-08de52ae9dc9 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?Vm5LTElsak5hVzRxTm11dENYRlU5UGErcHdHczZ5cndlWkdOU21raTk2cXpx?= =?utf-8?B?akxpYnEvam1MMkJsaWJIUkFMTG0xZGZrWkRXVlhGT1F5blNDbHFUYWMvL0JV?= =?utf-8?B?YmE4cXcva2dnUnAyVjZpQng3SVBDZXI3a0c2N254TGJCdXlkNEdFd3NBZDVT?= =?utf-8?B?dTZ1TlFKQ0huVm0vT29XV3RQUDd3eFMwcndCcGtyTXkwS1FPdVhBRFd2bDBx?= =?utf-8?B?Mm83OXhHYTQzZzZ5QzZldnVkeGpaMCtXNi9FM0oxSm1PK1NRd3JVZCthRXdY?= =?utf-8?B?RXJCZG9TNlpKWWY1bkRsWG1od2JFeVROaFZQdVovazlMQVFHWXRSeEpnK1pv?= =?utf-8?B?RnJucGR6VjJnZkVJTHBaYUJiMzFXWWJ0bzdsTm5tSVZPNCt3cVArNUxvZVVU?= =?utf-8?B?WnkrVlVGaFdMVGgzWkxnbFdkM0hPTmV3bFkwV3ozdlpGbEY5ZTVzK2NLUFU3?= =?utf-8?B?VDA2U1FzVk5Nc0MxUm1TcHdaQVVENkp0dTFUQXFJcmpJT2V6a2Q1bVRLcENv?= =?utf-8?B?d296WklsQi92d21YbmhsWjY0dEgrNDV3NCtjZjJnL3pEWnpqRDU4d1BISURq?= =?utf-8?B?Ujl0TUJRam9hUFpYQ1NRdHFLVmJhaGZtT2RjdU0wbUZkYTE3VHRUb05tUXhV?= =?utf-8?B?RkpZa2hhakNGTFFkRTBxaWxWUWxtcmlZZXVnR1J1bTR0TGMzUjhVWG51UTNu?= =?utf-8?B?b1BlRm1IamJLN0YvSTVSZHdyc0pVNzVhdjlwNWdnUVhicmc2a2ZrZnFjeGRC?= =?utf-8?B?bjk5Znh5bFNTYzBxeUVYL0ZLdmdSMWl0YzRmNDZ1M3lIRVJDT290dGh0MHpC?= =?utf-8?B?b3hwSmdzT2thOGIyZGg5Qy9MNndqMWxFWUlTcHpkVGN5ZlUydlgrUzMrZTAx?= =?utf-8?B?dm8xdWdvaDhST3JVQkpJZGZrMGlZT3NROHFrR1A3OWtzS2Z1UGdDS1hPQ08r?= =?utf-8?B?RTFDczJuWlJjZ29iTmRTUTFqRE1EZjB6emFJbTJmUSsrdE9OblhYYlpKV0Z2?= =?utf-8?B?cUUyaW9FNW1jMXNmL0x6NFE3OHNrWUw2R0N3OUc3N1NZdXNHRWc5WEhIWXZR?= =?utf-8?B?SVpEVlM1MDVXcEhoeisvcW0zNEcvTkxiYU5tQklrdktnaVhpQStzUzFzYzJQ?= =?utf-8?B?V3hMTWpCMTVhVDkzZGtKdzFwaXRmZE12YitsWkhMWlUvS0JOOE5NU0VJSnRF?= =?utf-8?B?Wk5zZ3NwQUJ3UXRQcVdZRTJVRE5yWGhXaW1XOG1hUUI3dVFPY1QrY0xwZ3c4?= =?utf-8?B?UW5TMnY2aWZmWWxlZEpQckEwM2tGYWVOOFVubFY3NERtOXN6c2QybExNUVR0?= =?utf-8?B?UWVjOUxyakpXM0U1clpHait6WjVyYjVvTEdobWtYcVg3Q1NLK000VEUzamh0?= =?utf-8?B?MU9qM0FaSERFcXVLYWdoTm1sS2JoWmVnbFpoYmJ2ZXUwQW5oU3l5aHdLNXY3?= =?utf-8?B?K2tHVVpCRG5vQ2tlcUVwWDREOHZCUTVwVDE4SEhNa1JVb1E1b2taeE9KZ0h4?= =?utf-8?B?SUNFM1lvNlpUZngyMTdVb0MzWHVlUUpJMGVtTUlaSHRxZVNrUDZOMWdmNlRs?= =?utf-8?B?TFJqTGZUNVR6akdNZjB5cHVkNXB0SW15U2I1cVZoRWNlS29iQTQ4Vk42RGJV?= =?utf-8?B?OWpNN0tMa2Z3bDVYY3VFTWFLSDVYNFFVT0JIT0txQUhIYUZrcFBtNGdGN1pI?= =?utf-8?B?VThjYWNSekdqY0ZYY0VwbzJLc1gxU25kWWw0WFpSN2FLSEFzNDNVYTVYdVF2?= =?utf-8?B?Wk13akhyTFUyK2VtbktmUkE3TGpLekJ5VnkyZGdoNHk1aW82aTFaRnFGbUhz?= =?utf-8?B?VGtENXJ2bkpzTVk3Z1QxQlE5OFZIVHB1aG0xRGYxcTh3bnIwTWpZeTJuY3ov?= =?utf-8?B?Y1UybW5hMzlYdS95RHA2MkZSaFdmNnYyaUhOUE00RlhDRms5NHlDMnc0QjdC?= =?utf-8?Q?fGbbLizosh5/TE/T+7loU89mRn8tq+Nh?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZVk3b3Z3ZE15V2p3NEptVkdvTEp4U2JJaTFCRXMvZFI5UHprU2R6MnEwT0Fx?= =?utf-8?B?dnF0ZytwVHc0dm9xcEtmb1d5allJUUZhNDlLL3BCdEdrRlk1V2tRSHlwYzdB?= =?utf-8?B?NWY0SHQ5Rk4wVXRxU0RTbjdJbU4rZlBJVWx0Q2hISDlFcnpiVHkyWVBZSVhV?= =?utf-8?B?OTd1QkdIRkdjQXFoMXM2Y1ZiRytQVmVicGcxYUNUeUwrUnRXWHdTcmU2WGNy?= =?utf-8?B?V2t1OHBjQWZwenpPZUpNbzFCU0ltSU9UT1l0dTlhSUNCckVQakdDMTRSOGZw?= =?utf-8?B?ano3dmF5eDUvOUVsNVdnNlRBaUlkdW1wSzMrb0VNNDh6MTZiYUFIeVVRdUNN?= =?utf-8?B?MnJXS01RbTRUMGRGTitBU2drNGZLWGV2Nm1LYWEwSjNCWW41QXE1d1k0WWZX?= =?utf-8?B?OTVCb051SldrQkJkeWRReGRKcExnaCtJaWZ6MmgyL1JFelErYmtiT0RlNTIx?= =?utf-8?B?UW9US2N1bmlaQWVnL0xENGlJZVQ1bnJxbjY1WEw2eGNnUURuMG5xUW9ORk9x?= =?utf-8?B?S2EwQ2FEd0lHZzZVdlptU3NyY25CMTNRZ2tmN2lQY0pHTzJoUWlNREZnWXY2?= =?utf-8?B?T21WcUpremNzV0hhKzc3NllvY09iYjZmdUY4ZU54OS82blB3NFVXWjNQT29D?= =?utf-8?B?cjhETmRMSkhTTmx4NEFWZElvRStXTldySXVPOWFneEZwM1dycnk0Z3c1T0hN?= =?utf-8?B?ejZPSmkrbFZ6UGo1QnZ1b3NPTWtJdGZicXdjY1lNNk0xMU85U1MwU0VEaTJK?= =?utf-8?B?VDA4TWpxZkU2L2xJTVBkTkJPMUJuL28yQzJ6ejhDK3YwQy81b0R0aUdqSmNz?= =?utf-8?B?c2ViNmUvYnM5azE1SHp2REdsTEpvNE5raE9YOW9ySTZiMG8zTTZaekoxc0Nk?= =?utf-8?B?aWx4Y2lyS1g2WkNJQThjTWhLdy9rWTlwQ041MjJWVE00dWRMclQzcUZ4WXBn?= =?utf-8?B?Y3BBaVk2ekNKVEpCZnh5Y1ErSUU1d3o3SUlBRWVqRHdEbWtjWUpVTTVhbzVk?= =?utf-8?B?QitIK2JQQ1pBNW5ZTWYzZWR6TjErSHhWSkUwTVFvNjlqcEJ1ZWdqN3E2WnFI?= =?utf-8?B?Qmo2MkR4VDlBd3JpbGFYUDJlaXJkMmwvSngzQUVTaTFnOWRHZkhwSGVxV3FH?= =?utf-8?B?ZWxrMHBzYlo2U1p0OVBXTTJqczNteVlDbXpwaVVXWklMN09pQ1VmdUt0K1FJ?= =?utf-8?B?ZVhrZy9QcU1ZcHhKaFpZVUZ5U0svOWc5VXhZK0EvaWM0Nyt6U0pMV1hFa0Rw?= =?utf-8?B?RThuYlU3U0EyVnR4WGpMRGdNVlZIRkovZVhMSGUyWTA4RzBPa1hnL1hZVXN3?= =?utf-8?B?Sll0MllXZGJSODB6SnVBeHgwMkR1dGNDaXYrTGc0dDNRcXZBT1doK2l0ZUdG?= =?utf-8?B?dUhCT3Q1LzIvZk53bkxxRlcwTDhVdjhXUDdKajlYTEJ0ZEEyK2kvcVdPME1j?= =?utf-8?B?NGVKQkJNZVkrRHFNMzd1bTlMaDlxM2dvYThieUk3alo1SElsOG4xQVFFWk1v?= =?utf-8?B?Y3VyeWVTVTkzUmxwOVgvTld3RzdSeGM1cTArUmJRVTFjWFRWNzE3alJqaXJL?= =?utf-8?B?dWVnNjk3YjMrTDlZN014eUxCaXVSdnVqN1NzSmthL01VRTY1azF3SG9wZ01j?= =?utf-8?B?b0lYdG5pUm52SlRYWHVuVmJlTjkxekpldHJqa3RPNzJLbDVhaW9kRTl5bE1T?= =?utf-8?B?WisyYlBBSUd3WVUzYi9MdDliV21DRmU2aDFBWWlaNnI5dGVOcXoxZ1RFdVpQ?= =?utf-8?B?bG11bTBqQlFJWm1Wai9TOFBzV3cwWjRDeTV6NE50YjR4S0JEb2czRFRZOWtX?= =?utf-8?B?aHp1c2NLc0RzK0Q3U01VMXFhMnVyaGpiL0E2UTZNTnhWSTdOTWR3QXFCcFJn?= =?utf-8?B?c0xsOThuZFJLRE9HYU5VYThTdEFrOFNQNFpKd2RKWE42UWN1OGxNRks1UTNP?= =?utf-8?B?WWszaExpN3BvdWRJSDgrZE1oMVBaYm50R2RiM3kzNHhHQWEwcldEc0lobFJK?= =?utf-8?B?bS9ib2lDSlBPaGJ5akp2THNSdWw1TXdVZFd4OWs0N0JaTUdOT3lvczRLeVEx?= =?utf-8?B?bENLckJ1RWxHRUJzZGc0cWxobG1kWHJkSTRDamE3ZUZQMFNmK05zTlRlcXJz?= =?utf-8?B?Ry9qZHQ1cUlxeFVCS1lWWXFmeUx3MTg1SzRIbkZuNGRUbU01bE1PR2ZUSzZB?= =?utf-8?B?b05vOERORU1VTGV5cGd6MG5RQStteVdVR2V1cGxqOWR3cGlNY1FmZkZCWUV0?= =?utf-8?B?UmJFV2JORzlvSHBGUWQ0TVBaaDJiSUhWZkVZTmozZmZnWm0vWURtODBjTVFm?= =?utf-8?B?RFpFd3F0U1JqbUJ1dnVFVUFTWXhPL0ZKYVJMT0FpaE4vSVhmNk5PQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8120f88e-1b36-4df8-0489-08de52ae9dc9 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 14:18:26.0502 (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: 7gx76e1AUDJvAgUmCwBABYMiC0HcqDA1wzzvzqEiC9qpClugAxPAZuIjG1+j3DmRGgcgr1Vs8qEAhSdwgPrbmLtQgiFli8dlOf5xaUfYoHI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5624 On 13/01/2026 2:17 pm, Roger Pau Monné wrote: > On Tue, Jan 13, 2026 at 01:09:58PM +0100, Alejandro Vallejo wrote: >> Debug builds traditionally ship with a 10-bit counter for the TLB >> clock. This forces global TLB shootdowns with high frequency, making >> debug builds unsuitable for any form of real time testing. >> >> Remove this quirk, unifying release and debug under a wide counter. > I wonder if it makes any sense to provide this as a Kconfig tunable, > set to 32bit width for both debug and release builds? That was v1, and both Jan and myself said "prefer not". ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 13 14:24:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 14:24:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201797.1517368 (Exim 4.92) (envelope-from ) id 1vffJw-0002Bw-78; Tue, 13 Jan 2026 14:24:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201797.1517368; Tue, 13 Jan 2026 14:24:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vffJw-0002Bp-3P; Tue, 13 Jan 2026 14:24:32 +0000 Received: by outflank-mailman (input) for mailman id 1201797; Tue, 13 Jan 2026 14:24: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 1vffJu-0002Bj-U2 for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 14:24:30 +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 91c64d38-f08b-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 15:24:29 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS7PR03MB5624.namprd03.prod.outlook.com (2603:10b6:5:2d1::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 14:24:26 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.005; Tue, 13 Jan 2026 14:24: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: 91c64d38-f08b-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Y8Q1pFL+buXQsmPKzO6AhXIwkcWIhUJsXm/87puEyr6e636T4qX5fVRpS3q8YoS8Ai6ZRVAqV7BkwEH39MVJbfnKN9rDiAPyJ0nnA6WcWZt1/TyRvNGmNGdWLfqTvIpwDME9J7JGyVhH0nRFRoQQYSfzhZJyUwPwC4PhCoOJiJVPorWpicG423KeYLQDYYAE/Oygg1AJzFkUIJOcduaDxVvf0sEDbDGdENAntRwpk3Lo/StF+xcvFYZVwsb4MlThgPSSHaPwQsMXP/h5aemnj1ybNeadLkZDB8iwQBRNot2iuZMabt7wyxH0KfNca3B2dgRQZXC2iPdlabcNoFnmqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=cX5A1ANZzn9/mqtn7tzNPdPcetc2xNdNAQvgWczm29U=; b=toSc84IXf2VGlrOi9cOoG7BafNs0Zo68hD8KOrT9L2MkAwQ1bSx/QmsIWgsztJNTI8snwrt8j26UWOS7CPzvli12ag4RW0WVERIxpPdi6Fpt7/HDpVUa1w7ZkoumfFKJYU5txA4tJzBbh+A9MTGk5pM69zIevSXE/sNvrAeY7yofauDi8oDkY5YyQu+GZGG/th0qvArzCOlMfcrPxOzXpjTev08yUwxY77NYdcpvSh84wey2q7ySa1S36ZKkBBM3B4j1h9H4R5CPVY+m/T0tU4NPGDdoN9ynTPOSK6fOHWmFI+TuTGMo/OTGn5j0KlG7wY1WTp/lA32BKMN3JQNj2A== 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=cX5A1ANZzn9/mqtn7tzNPdPcetc2xNdNAQvgWczm29U=; b=qrbYzpsMSAPMloEbxF3OMPiJzws7fcORRsjRfW7WmDF9wV9CIoND+MuGUWWvCbyah0H1RXsXbnyiqZRX53Hwc1qJtfgWUl9SJZfAeH11Ys2L5TFq2na1mYAK6q8VhpWb6WATqTDL9KcQRoSViUHpc4e3LckjhXb6UaVRP9TIQco= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Tue, 13 Jan 2026 14:24:22 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Subject: Re: [PATCH v3 3/4] earlycpio: lib-ify earlycpio.c To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260113122109.62399-1-alejandro.garciavallejo@amd.com> <20260113122109.62399-4-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260113122109.62399-4-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0412.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:189::21) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS7PR03MB5624:EE_ X-MS-Office365-Filtering-Correlation-Id: 36b499e7-1a0b-4332-b5f0-08de52af74ac 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?UmtqSExBM0liN3JHODE3K0FONFA3OG1BcjZrbEpNWk9SSStlekRUdUUrNW1i?= =?utf-8?B?WDJDQk1xRUx1NCt2cnZRTVo1VmhHR2xIbHF2WndvRU91dmQ5cDA1K3ZNd2Rk?= =?utf-8?B?SUVUNk8wQys0dmRqaGQ0bGF0YlRrUGliV1RnTFhoZWh4SGE5R0hDRVczY0dk?= =?utf-8?B?dmVsdHEzUExWNWdHTS93bXlzUmNRb3NncjRIS1NqMUFEek1wQUpKY0ZZUXVr?= =?utf-8?B?ZUNBbUFFTjJPa29SOWlxdjhuNHBkQzI2QjEwU2ovd1FqVVZWNFZzcmVJczFh?= =?utf-8?B?UTNYRVpETmpqZytGUmpEaXNSMTArV3hBekQxTERoZG83QXc5aHloMU9BUE9V?= =?utf-8?B?STY2ZjJhUCtFOXJvMVVhYkhHZUdEam0wcHNEMFArQitvVW5zTlhnTEtJalJN?= =?utf-8?B?R3Y2aXpPbHpWdStFOUZDWXJabzh6NXFkZ2ZqOWJMVDE5QTEyNzlVaEk3ZTJJ?= =?utf-8?B?QnpIamlJdlQ4YWRjT2NCSDdGWGdPNzRpMERIcEdWUy91UkRwWUoyNmJraXJT?= =?utf-8?B?S1JwZE5ES2svN0FXYlA2UzA3YVN5Nlk4Q2tJYWZTWXFRdlhCa3JoY2NhSHh3?= =?utf-8?B?bHNvUElZSXNTYXNWdHg2WXpDcHdiR01pcTdUd3VubGpXalEvOUNMSnNvOUtK?= =?utf-8?B?dG9ZZGcrMUlSc0h3ZFhSaUkwVytmN3FCazlHSjJGa3ZGdjJEM0dlMDhCdWhD?= =?utf-8?B?QWpHMnljU3BDNWlkQ2dJQ0dlQlR3Y0k4Q2hiWVhmQUozWnlVWE9RQ29jSjUw?= =?utf-8?B?dE5KZjUzYm9qT3BHNEx5SG1ISWF0NFgrOWM2Y0JjZmhkTjhmbXdrMW5wT1lz?= =?utf-8?B?ZTJMRGxLRjVxRWQrajhCQW9UOTFIRlA1Q1IzR0lBaWZ0ODN0QnAvdk1tb0dH?= =?utf-8?B?TlJid2hsdzAxYkFYRjFxeHpheHk2eDU4YWs5R3RNYmtGc0o3dmJJWUxWL3BP?= =?utf-8?B?ZDRCU2F1cVNvWVRkbDI4VnFnb0FlRGRKWXhzSHB1ZDhCTWFkQU9vTzQrQWpZ?= =?utf-8?B?THFMZnZFQUE0U3c3SkhGS2dlcjBPbDdmYXlmTWo5R0MrU0dubkRGNmIveE11?= =?utf-8?B?TDNtTGtOWFljREgzWjl1a1BQMVZwTk9ZRzJ0QWpXb1kxMWxtdUEySVBNSVlh?= =?utf-8?B?b1JoS1FvUUM4ZDIweXh6djJYY3BDQTJpbTVFWUtoL3B4WW5INHNNNk9aQzR5?= =?utf-8?B?VFV4ZXdFY3UzUVBQQzdBN0NwUG43RWRoK0VOT0VhK3NrWithVjlLdVJKNWhz?= =?utf-8?B?RG1RZVovYlRyekZiazNBaFNJSGU0aHI4Z05lbEhtMXovczVFeElqWFhPSkFn?= =?utf-8?B?N083aVo2bG1OeGZSa2pjS3F6NTJSVEpXSUZJUGhETnR2dDJmc2kwMU4yRkRG?= =?utf-8?B?SGhRbUUzYXlFZFpQWXBEcEs2UndIampoRnpwRjNybk1qaGxGVHVudkNsb0hn?= =?utf-8?B?N09JQnZyYjE5TnJsUDlNanVjUEVvemJUTVJpQjBnNy9VQURPZWNQcE1qRHZK?= =?utf-8?B?UmM5SE5LTXM1eTFWYWliWFR1VVRTbFJsRVZJY2RLVjcrdERDcEF4NEpESTdt?= =?utf-8?B?c2hVYU9Cd1ZSalVvekUzLy9zdlhnTzFGd2dCMnZoZ3dyVDdIMC96LzdyQmhp?= =?utf-8?B?NVdSV3BvQ0pSVnZzYzduVFEwWjBLNkxWZVV1Q2dPWERqamxkZzFHR1BKa0tS?= =?utf-8?B?Z0xtTVhsTlJBYmUrN2czcjh1LzBhMUhwQVlGOFArcWkvWG9XVld0cjRuWngz?= =?utf-8?B?VWwzWHhrSjI3TlRpbHVTRUtCT1ZOYzFRVzZxZTQxeEpkL2RvV05taFJUZU1m?= =?utf-8?B?ZTFFbUZPdUx0N3RVRzJSZlkvZUR2ay9Fa0ZaZW8yN3BzVUhQWi8xZjZZNTVU?= =?utf-8?B?L1Z3TmNMcDBGT1piUU03VEhWcU9VQ0ZHSFVUc3pxcDJmU3FtYm5oNDAzNG1u?= =?utf-8?Q?xG9ODPCBuyWmYmwct5J0uyvfERmlrxRr?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dW9nS2lSOWMrVWoxM211WnZkRCtHT01sM0lhVk45NWxsdkhHZTQ1eFdDZXFq?= =?utf-8?B?UU5VTFM4TjhZRHhWQWtZSkdTa1BwRDU1NzQ2elNiejJVR3o2WjM5Szl6S1Bj?= =?utf-8?B?R01XU2hyaEVsRVA2QS9FSEMrR0paRGJVUTBtVnRrVUlFYnMyVFNjdURxYTVu?= =?utf-8?B?alVaa3BiT0k2VndCd2syUTlEZ0I5L1QxeEw3clBSd0tpQ3ZzT3podVk0SkQ1?= =?utf-8?B?NHcxNStWT0k3aFNMdnRtREVQNmUxL2dDQWppei8xNGQwQlI5bWlpd0lhWExK?= =?utf-8?B?UUlqdmFuT1ZFR1BjT0ZXVWR0V09HSDNpT0xwbnc4Qk9GNStycWRhTktqLzVi?= =?utf-8?B?MEJZMFJOaHlZVittUTNpYWxWWmNuaWFzQ25NQlFIRVp2MU5FSk1FZ0tTMDBF?= =?utf-8?B?Z3Z0bmc2dHdPbDEvUFo2S1JzUWdML3M0eHl2T1VzZjEzRUl2bnQyT0doUURv?= =?utf-8?B?Ym5CNU1sWXZmUStOemtsWjZQYTZmcTFGUzltdlNycFZ1NHQxRzJHSnhiRlRK?= =?utf-8?B?M0xORFJrVFNWMHh1QlRTTE1rc1l1T2N1dDZkaXRiRm8yVTlwMWMrU3VOekdv?= =?utf-8?B?RzRtbUdMNlgwOUh4bitqcWxSRm5vUnhZUnBqb1I3WDMyQjFVakVtWHA4YmlS?= =?utf-8?B?bEdlb25QVzVHZU4xRjlRNEhDQUxySVpSSTdTcXZtYjU5L0lNb3VORjZNaGp4?= =?utf-8?B?VzhvR2lOY3RkUkpNNVkyZ2Fzdk9FUVVyN3E0MndTc29LYkRjeDRrSktOUzlP?= =?utf-8?B?SUM4aEUrbFIyakppQlVyR0VPVVFFenlBdzJRZUxEQU9jd052dzFPVkxKV1Ev?= =?utf-8?B?MTQvblloQVBURUNsb2swMStJSnJjSEl2N1dJMG85SlhNSElxSGFRdEhMajVP?= =?utf-8?B?dlMxNG54OU1VczZGd2xZdzFpUzA3dWxkcE1LMW0vVGY5dGpIRWprV0tLVVpV?= =?utf-8?B?Rk85M21pSGpOUWpNaDlzUzR3endYRFhMbmhPRGxnVlZwSW5RNzhsNmR1Q01U?= =?utf-8?B?VmdNTjBzaHJOdUhnTFZhTlNyQTJZa2RybWQzM1N6YSs1WS8zVWw2OGc3eS92?= =?utf-8?B?L3ZoSVQvcHAyUFRhQUNSN0c3RFVlL2xZcEx5VCs4UmkxTzNPNEpaY3E3ZUFC?= =?utf-8?B?NXZGRmNLUDc0T3h3bFpvakw0TDVzYnptS1BiR29xRm8vSFZDVUdaRHA2QzFD?= =?utf-8?B?aGFaZ0pJV05xWFFWT3lhZkNIdXMyYmtnRlFFVURYWHdBbXk4MFFVN0NPbERL?= =?utf-8?B?RitIbWhkd2E5ZVpPQ0N3Q0M0RlpzTUdQU3lkbVpxbW44ZS9GMGRxMlR3cGNm?= =?utf-8?B?NDBsTTBRdWhnWWwwT21PMG84VzNFNjh5UU4zdHEybDlReFhIdFJIZkNJVVA0?= =?utf-8?B?L2NIcU9MejVmajBlMDJlZVYvWHhnU2xyZERPWi91cmxMbDJFV0FEL1dValVM?= =?utf-8?B?QXp0aDRTZTQraUJ5ckIwYWs4bUFxR3NYcUJZQzQ5LzBxcVBCRHlFNVBNV0R5?= =?utf-8?B?QUNLS0ZuSTZrbUdjZVdJSGpLSWVackpCLzNxZXdvNW1pOTJCQ2t0Mkh1bHRj?= =?utf-8?B?RmRXVXV3WTZZNzlkQXkxVnh5ZmQwbXZFbWNoZnFHUlptODQrd2E5OEJqWnd4?= =?utf-8?B?cUhmd0VqWVV6TkVRam93VEtqQ0pIZjJRWGNlOVo1TmxKK3NJajY2NlExbktx?= =?utf-8?B?SXFTU1JLVGhOUmVib0c0bm1vUWwwUkE3UkJOTmptZGN5RmpuY0dCaTRPbjQz?= =?utf-8?B?UjRLWWhzeGpTa05pd2hPRVhId2xTN2NSOTVCSmM5cllvMWdseVNQeGk5QWRC?= =?utf-8?B?bVloQ3VlQnRQMWpZblVmTHUwS0VmUjhlSDlLMDZhdnYvQmJnZ3dxS2Z0MmVt?= =?utf-8?B?U3E5OGZMMmNqaEhLVENRR1UzTnErb0U2RWhuSENBdHdEKzJSM3g3M3ZtdzJj?= =?utf-8?B?TkF5Ni9LQkdHMHVSeVNBRXpnQ3VhOFQzbXMwbEJUbnV2WTdEa3RmT29DdEIz?= =?utf-8?B?MmRpTE9RMHJMaVhKN0FEblFSdVJ1Ym1aT0Y1THdIelp0QTBhUTAyQU5mYzJ2?= =?utf-8?B?bHV1clhnSlVpUjR3MXNsbnQzRnNhdlpSQnY0N200MTBncTBxS0dCaHhQTjhq?= =?utf-8?B?MU5sTS90YTVPUmxZeHdVUmFhYXZ1Uy9TcEVUVjB1VlVETWxtQ2E5VVNFSmdB?= =?utf-8?B?amo5MTdHaU5JNkRjaW1ORmZEMmQ0VEM2YkJnNVM0YTVISldDa2VWWVRPaEZ2?= =?utf-8?B?dGZvSGFsNVRDYzd6NGRkUnJaMDRJZFdqMmpJdEZrekpnYTBLMzNCWHFhUEs2?= =?utf-8?B?VGhSNitzeWRKWEUxNGphdUxsWXVKOFdmb3NYek1VMkdaeE1IdTluZk8waTk3?= =?utf-8?Q?S1gBzUMnnh5uWBt8=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 36b499e7-1a0b-4332-b5f0-08de52af74ac X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 14:24:26.4150 (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: dNVTPF8Y0MmwLOcV5EYwrKE4kLgOHYQx+M3hnohjy1YmzzC0jRBURT43pse2uOIg4IrHEqzSCZxSlmnO5cob6ClkhRHCjHnibrAH0S2Qzxo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5624 On 13/01/2026 12:21 pm, Alejandro Vallejo wrote: > It's only used for microcode loading on x86. By lib-ifying it we can make > it go away automatically when microcode loading becomes an optional > feature in follow-up patches. > > Signed-off-by: Alejandro Vallejo > --- > v3: > * New patch. Subsumes earlier conditionalisation of earlycpio.c on > CONFIG_MICROCODE_LOADING. > --- > docs/misra/exclude-list.json | 8 ++++---- > xen/common/Makefile | 2 +- > xen/lib/Makefile | 1 + > xen/{common => lib}/earlycpio.c | 0 > 4 files changed, 6 insertions(+), 5 deletions(-) > rename xen/{common => lib}/earlycpio.c (100%) > > diff --git a/docs/misra/exclude-list.json b/docs/misra/exclude-list.json > index 388397dd3b..2b874dfd3b 100644 > --- a/docs/misra/exclude-list.json > +++ b/docs/misra/exclude-list.json > @@ -121,10 +121,6 @@ > "rel_path": "common/bunzip2.c", > "comment": "Imported from Linux, ignore for now" > }, > - { > - "rel_path": "common/earlycpio.c", > - "comment": "Imported from Linux, ignore for now" > - }, > { > "rel_path": "common/gzip/*", > "comment": "Imported from Linux, ignore for now" > @@ -225,6 +221,10 @@ > "rel_path": "include/xen/decompress.h", > "comment": "Imported from Linux, ignore for now" > }, > + { > + "rel_path": "lib/earlycpio.c", > + "comment": "Imported from Linux, ignore for now" > + }, > { > "rel_path": "lib/find-next-bit.c", > "comment": "Imported from Linux, ignore for now" Honestly, I think this needs simply dropping.  "ignore for now" isn't going to cut it with any competent evaluators. By libryfing it, it's no longer part of the AMD target build, but it does want covering by *-allcode. Given that you noticed it for v2, I presume there's something in the file that Eclair doesn't like? > diff --git a/xen/common/Makefile b/xen/common/Makefile > index 92c97d641e..4fc0c15088 100644 > --- a/xen/common/Makefile > +++ b/xen/common/Makefile > @@ -65,7 +65,7 @@ obj-y += wait.o > obj-bin-y += warning.init.o > obj-y += xmalloc_tlsf.o > > -obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo unlz4 unzstd earlycpio,$(n).init.o) > +obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo unlz4 unzstd,$(n).init.o) > > obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o) > > diff --git a/xen/lib/Makefile b/xen/lib/Makefile > index efca830d92..60cfda4dfc 100644 > --- a/xen/lib/Makefile > +++ b/xen/lib/Makefile > @@ -3,6 +3,7 @@ obj-$(CONFIG_X86) += x86/ > lib-y += bsearch.o > lib-y += ctors.o > lib-y += ctype.o > +lib-y += earlycpio.o > lib-y += find-next-bit.o > lib-y += generic-ffsl.o > lib-y += generic-flsl.o > diff --git a/xen/common/earlycpio.c b/xen/lib/earlycpio.c > similarity index 100% > rename from xen/common/earlycpio.c > rename to xen/lib/earlycpio.c What's wrong with .init here?  There's only a single string which will end up unmerged so I'm not worried on this side of things, but we now have series doing safety things getting tangled with .init and I want to get it fixed. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 13 14:27:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 14:27:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201807.1517377 (Exim 4.92) (envelope-from ) id 1vffMN-0002iW-IX; Tue, 13 Jan 2026 14:27:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201807.1517377; Tue, 13 Jan 2026 14:27:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vffMN-0002iP-Ez; Tue, 13 Jan 2026 14:27:03 +0000 Received: by outflank-mailman (input) for mailman id 1201807; Tue, 13 Jan 2026 14:27:01 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vffML-0002iJ-NV for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 14:27:01 +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 eb24ce1a-f08b-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 15:26:59 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by BL1PR03MB6072.namprd03.prod.outlook.com (2603:10b6:208:316::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 14:26:56 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.005; Tue, 13 Jan 2026 14:26:56 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: eb24ce1a-f08b-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JeMcRH3O24QAUalZVeT6phgIa0BaeKTpd96FNZOq+fDxhEK+EXjHNYqE1m9FLoLivcHGGpcXgiPK4tWquuYXe5iUFbM+SC9nF1bl8LLrM0mQKC5fEy5KtntTRq9HoTNAkddcfJUidAFFoSfQXYWBZjG3i5xN+ojx2mPVxXQeg7tYrJlW5dotnl/T3nC3cBs/d5NTncbS4G2nwg2zgvA6GXekDh4QC2KiykJm5k9j7OZ6XE7igO+BGOBuK6MmASN2SzzDPndKe7x2g89KHIYavpt2O0ZYCoYguVheeLtSAHpw2dDEdRo+anrLnb/3lM+rufyMfAw5s64Kto0xDg1K0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Nb3v8a6zrTjpwBjifYFB/lDV0uVk6Krj+AlTm40hQ7Y=; b=n330NjwdSfFZDPSsJIUt8fcXk47/ZjNKKjwmxiqyh1ieZ2jEQvj8N35ejVpKMoHzeGQEuMaWueWojOFg++OtavhMKbYHpY5j4FgPc7IH+dPkVkzRwDG+jiQtlVCKboZ4Z82s+7k440TUeIzlvDAKT4aOeSYDqWGGlZ/3eJ5OpG9aE842qksH2Z27bP+jR9UJjcaggOSC1O9NZgOP2FXciYK9d5lxwjnm67m77BFJ9HkjjbCgEEzmJDM+72lb4kOgyjJZcDU7mDmfEWFT3WbHYDEOW7ew/tOSX/0z/1lNrkgQmnD8LdIjo0H0BBW4tFMWRY4s7vlWAN/BPwEtpachpw== 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=Nb3v8a6zrTjpwBjifYFB/lDV0uVk6Krj+AlTm40hQ7Y=; b=tMZ69Twll9HCBRWI0L9x8PJyxj/wCmYQYay7kXAgqIxC9wMY8Q4uM1EKHVm4Ki9W88EkSQsgYAo8cYeuLweFUzHj9eGal0PLcI6lmrz5JfJz8H6JfqDD9E9A7BYr/2U5mSCL4xlhmz4dpzip9DbTJCXYnsw/32uJsoyHypTnGsQ= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Tue, 13 Jan 2026 15:26:51 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: Alejandro Vallejo , xen-devel@lists.xenproject.org, Jan Beulich Subject: Re: [PATCH v2] x86: Use 32-bit counter for TLB clock on debug builds Message-ID: References: <20260113120959.55156-1-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: PR3P251CA0002.EURP251.PROD.OUTLOOK.COM (2603:10a6:102:b5::28) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|BL1PR03MB6072:EE_ X-MS-Office365-Filtering-Correlation-Id: 2922341c-389e-4610-7533-08de52afcdce 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?eDBac3NUMjlFRGVXQmY1M2hQWUV3Y3ptNEJsa1BNcnZHVEdueE92ZGo2REVx?= =?utf-8?B?U3BXQmM1dXRWcUd4Wml5WEo2dVcwVXRJc21zOFF3Z2JhUUV6NDl2ZnphQzhS?= =?utf-8?B?UktWMkNqUzh3TW9XbDFKVlJLbnlGaG1Bb2pFSkZBOS9oNjhxUFVBYmdWRTN1?= =?utf-8?B?VzEvckdqQmdia2JLZ3ZvaHVjUFJsaXJmTnZabzZyQXoyNlZ2R2dyeVhnSTBI?= =?utf-8?B?NG9DeTBoSU9PZUhNakFpcVpVenlBRHJIbERSekU0bW9COUlSMVlvUDVGcDMy?= =?utf-8?B?aDJNK2xZMDF1Yitjc3JUYXJlcmh3b1Z3V3liSGtSMGdWU1NmOEg3YjR3YXZI?= =?utf-8?B?YUp3cVRZWCszTTJTQlpOQU8zMzJPRXlqY0Q5U1c4Z21TZHdrRVBjU3ZydGpO?= =?utf-8?B?VC94ZWhXRWE5NURqQVFIcFZCeGxEWFIrby9zTjh2Zlo3M3BBTW9lK054eVlr?= =?utf-8?B?blZGNExDMmlvaFRacllNcjRvQ2VLMldrcFI1Q2FWVWIxczREbnpvTXNPa1lr?= =?utf-8?B?UGxUczd5SE9xYTNWZ0tBS1dDbzlLUEt3TS9zYXRVNmVSUlQ2STMxOUJWMkx1?= =?utf-8?B?a2JEckJvekQzWERPb0pRU3RIWm9ZN2dYNk1LZzZOZVNINjZyM3VlRkN5RjRj?= =?utf-8?B?TTNRYm9scVkzdFRTcXFjbHNEVVY5WDZaTmpvTWFwNXVudmt3d0oycXg0dkRG?= =?utf-8?B?VGNMQ0ZSK2t4Z3ZBbStsNHMzUVplUlNyTC9xZ0owR1drT0lma3BMQWZJcHFx?= =?utf-8?B?Um41VXZXRCtTQXhMR0UycEwwYjYrU2hkWGZDNmpOS2lzbTRTSXBXUlB1SnVJ?= =?utf-8?B?cllnZmVJbGEyK1o1VVdGS2FsMGgzMjVvZnh5TkdVdWxqWWtTUFFVNHhYNGVI?= =?utf-8?B?T3lVVlBQZHVES3c5VzlONk1KUG04MFFhc1BGNlV2OGNaZGxlZlZKMEQrQnpX?= =?utf-8?B?MlExSUVLSDRiUVN4S0dJUG9tMlBBTi9NdWtkcVVSWHQvQ1NycnhLa1ZkM2Ey?= =?utf-8?B?NDYrblNvazRrZ2xCOEZIOFBCSXFZUUdyblBxc3FBSUxVNTZqaG85TDh6UWlk?= =?utf-8?B?eCtwVG5MSWtpdG5RTkQvdU4zVldobkU5ZEw3QnJyQzlxQnNqV2JyakcrMDJu?= =?utf-8?B?ZVpUVzEwNkFzbitBeHJvdDRvM25CL0VZU1MxYnZhREtaR0FXQzE0dmpEZlFt?= =?utf-8?B?dTNYMDB0RldEVVRteUJ2Tk96YkFtZEpmZHdjOTMzRHdyQTZ1MS9GREVYbHcz?= =?utf-8?B?VFdnYXlIaDlGYVg4eS9zQWtsdzQvaldiK0xkUzVZbENQOWdKZmc4dHp6Wmsy?= =?utf-8?B?SE5Tb2lJRjVkaXJKZnppQzFmRFFtU0RGdFdRcng4SDdITkswcklZaU4ydnZl?= =?utf-8?B?Yi96N0NqdXlxWmFEaDYrNUhlaXNFcmpTNloyUkRaaExyOHR3cWJycUp1L01F?= =?utf-8?B?aG9tWGNwVkJqT0pQbWh5K3NRWFhtYk1BMldzQnVDdklEZ0poU2lHaTBJRUxP?= =?utf-8?B?MGlKKyswUlhwVjJ2eUN4WXFRc2U1RFYzQ2M2MEtaMjc3MXd0RW1PdmF6ZnhK?= =?utf-8?B?SlA4ME9nQUtiNUFFL3ZrUlc2Vlp1cTU5dktMekxQRlU5VTBHR082SUhSSFV5?= =?utf-8?B?NVpHUlhvWWtFNXJIZm1QeWIrZm84QWNLRXVnc05tNjhWSnZTbXZRUmFsOU96?= =?utf-8?B?Ukg1MjBvcmZiN042bmMzaTAxS04rWHJXcCtyS0hodG81cUpIY1VERHA1MW1R?= =?utf-8?B?eEpOZ2dEMkRUUVVlcmRpZktEWVZQQU5IUmo2eHpGY1hDRGFwcjFneW4xRnM4?= =?utf-8?B?K0IrZXJtNHpyaWNoZGdNRFJBcEI4aFlRaTNqaTZvSHRHdVB5djRpWkVJdGVM?= =?utf-8?B?LzdCNVNCWjUxWEZCUk5oeDBtemVNTTVHYmVKSFk3S1YzbStDWXFSelIyNFFC?= =?utf-8?Q?2dZOHOaP8d6+H4wH+Lbur8TGiMzWBcCl?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MDlPNjRGTEMzRWs4cVNNWU1RaDdZSnE0Rm9PRFR3dWlCSFNLWDErMVYxSkpO?= =?utf-8?B?NTFLb0QrMlpNWUQ2L2dMSHJQeC9NOHF3cFVudjF4bjBlYUYxZ2dLaUEvSkR5?= =?utf-8?B?MFpTV0phalJmMjM5YS9PQWloZFNHT3BEVUd1b1hZbEowZzVrajF1cVZHVyt4?= =?utf-8?B?dEhReEZJYTFtNGlOVlVGUjIrUm9IMXdEeTJib3NXNEJXSWFDSXU3L2QxbGV1?= =?utf-8?B?dmhXb1I0bEgrYlM2ditHOGdBa2JJK01scDd4eGVEc2NQS1BnMG1MT1Jxd2Mw?= =?utf-8?B?TmV6cjFrOUN3ZjlsV3drTmQrWTN5UHNhWms4c0txZ0d2ZUl5OWdsbjBsYW5Z?= =?utf-8?B?RE1ZbjFxOXFId2NnWndpelljdlcwWnc4MkV6RlBkbkozaFV0S0kyVy9JSFRU?= =?utf-8?B?TDlyb3VnRDM0VUZWQVFlMDBvK1J6RXlYZG9KRnlaSzJKRU1oNEZnYnpXNjhq?= =?utf-8?B?Tk1YWTFCTnE1c3pkMDdLZW11aWVmNWdIRXVGNzhKQ045Q3RrYjIrTDNZZCtJ?= =?utf-8?B?VFE1a0FHT0FRZ1BTOWRuVnJrU3RBYlZ2UXp0bkxKUUVtbkZXZFNBWEhld0dL?= =?utf-8?B?WkIvWGlPT0ZXMERwbVhzWlp0L2IvOFNUL3MzWEhpVm93UVQwZThEKzI3eEJv?= =?utf-8?B?S0NTSEgwTiszWGFhU25pelR6WW01SERvWW5wWmFaL3k0UmpDRTYrYk4vbDNr?= =?utf-8?B?b3hCSFlxVVhQM2J5T0U2ZTZVUmdOUHVCZkZGYWlpWWxvS0F4SWlIdkRDNFJZ?= =?utf-8?B?eGtjVHBSMkRXY05IeUZ1djhTNXExTDJPQUFRL1B2anhjL0lzelJhRmxNcHR4?= =?utf-8?B?YVo5QzlEQTNZVmJtRmFTN1BMUnFLME5ORFNLcDI5dTVObzBCNkxIcjBMTlFR?= =?utf-8?B?RnNUV0RFaXhsRUhHRmxwWnRMKzJBeUkwWURTSUpoSmpCcWFkRzBCeHNqc1lZ?= =?utf-8?B?NW5jY2RJVFluSVRVZXJIVjQ2Nm03cnBuVjgxVHk5cTNWd0tJZlU4N2VyWERN?= =?utf-8?B?dU1IOGc1K1BWY0tGVUtUTzlUSXlPcnBCL3ZlblI1Z2hwYUNoNTFsM2xYMjNC?= =?utf-8?B?ZUhURnBVSitkQUFnT3JBaGh6TlcrL0tFdi8yQUtaR0dnSFFOdVRjM3VXTHY4?= =?utf-8?B?Zll6ajA4T2N1ZEtPQ0hrdXVOQ1ZFY1A4Q2NYTEwyUmhGRi80cUdheWdwNTlG?= =?utf-8?B?alhoU1dUdXpHKytFaEhNeXBPb3hNSzQ5UGxHdnQ2M0NWa09rb2U5OXFsUzc2?= =?utf-8?B?azVoZ2hjU0ZuanBEUVhmL0NRZyswMFJuNlJkUlNScDRiVnB4aVJyU1BsOHpu?= =?utf-8?B?cmY1L0hoTkovVlUwNHpXTjNHMkdKWEpDaGJ4TTZYYnR5cW5tZENQNWREaXBu?= =?utf-8?B?MXVVbWFpRll4dVpXY05ZYzlVbFgzUjRRL2xIQWdpOVY4YWM0RzNDYm03U0N1?= =?utf-8?B?ZjcvamNBQzdQeFBydDYvaVB6WTFpR3FZNFFhSWtaZlZPNkFEbi9TU1k3K0Ez?= =?utf-8?B?NUN1K05EVlI5YkhQeThXYkVqZHpqajV1NU5yajlTRCs0Tldpc0ZoWHZBSCtZ?= =?utf-8?B?aURrL3pmb0dkS2tkWFpJSkpVZjErbjA4TnZiNWp5MXF0Z2djY0NOYUdmRlVR?= =?utf-8?B?aDMzbEgzUlFuM3F4MVVDdC9veXczVllxQVhGQVlzRkdHNlZBTTAyNmhQdjVq?= =?utf-8?B?UFJ5eEI5WHJqWnRDUVdCS1ZyMWU2U1Vramo2NVg4M0FNUDA0bzNhZ0doS0pQ?= =?utf-8?B?ZFF2ZkZtMWQ3cm1uS0JZOHV0bVF4SjAwZHFCSnJPbDEwKzRUanB1NnJpV1dR?= =?utf-8?B?Y3lNZVY4VWxUSlk3dG5VK3JuQVdjRHBLelBQUkYyRzBzTkNIRzRPb0VjNUF6?= =?utf-8?B?MUVzc1VyTjJ5RXlEbW1hUitwMTM1cTBwQjRGenM1U21UUk4ybkQvSGl5akt5?= =?utf-8?B?MXpXVWU1SjVDc1JzbjNreXpuTGJMUjJoaDE5a1p3d1lCMVZCdFNBOWdDNkdP?= =?utf-8?B?ZTgwYjBuOGxYV0NtQ1JEYUJ2RW5VaW95YWtjOTEyMTc3eFBEMUNnQTRsMk96?= =?utf-8?B?TUdrbWtRUGxlbnhlUzRkRnZqeWpDSmlQaWpuSE5CMGlHaHZnVHJHcXRwMHhs?= =?utf-8?B?WDJlRmZuc3RMeXM0a25EeGlLMkpaU2NpTzJsanQrWWhoaWhudFNEZnlYeWtJ?= =?utf-8?B?N1RKS1VjdGpVcmFpWGVTbHNCZVVmZlQvcXgzdW5TL2lvN0MwVFpmSEpvU1pN?= =?utf-8?B?Ry9aSWNleWFVaEo4dVpVZ3J2RjI3ZUNRa3FCT2dkdlhJQnRqRDh2VkYwejhr?= =?utf-8?B?Nk82aHRZKzE4RkhGMUdLak81d0lOUkFiRnhtSFlkK01CZEZheDlRZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2922341c-389e-4610-7533-08de52afcdce X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 14:26:56.1140 (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: WoC7LP9a5+ePZZ33EreZ+WUdt2TQgwO2aP4OZG9N1K4TD9ALNRFRTxspNahxEYyP9bcmSmGegX4Z3xYait0kUg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR03MB6072 On Tue, Jan 13, 2026 at 02:18:22PM +0000, Andrew Cooper wrote: > On 13/01/2026 2:17 pm, Roger Pau Monné wrote: > > On Tue, Jan 13, 2026 at 01:09:58PM +0100, Alejandro Vallejo wrote: > >> Debug builds traditionally ship with a 10-bit counter for the TLB > >> clock. This forces global TLB shootdowns with high frequency, making > >> debug builds unsuitable for any form of real time testing. > >> > >> Remove this quirk, unifying release and debug under a wide counter. > > I wonder if it makes any sense to provide this as a Kconfig tunable, > > set to 32bit width for both debug and release builds? > > That was v1, and both Jan and myself said "prefer not". We already have this fixed to 32-bit width in XenServer patch queue for both release and debug builds. Certainly no strong opinion, I never had the need to tweak this, and anyone that has to will likely be perfectly fine with adjusting the code. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jan 13 14:37:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 14:37:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201820.1517387 (Exim 4.92) (envelope-from ) id 1vffWa-0004ct-IB; Tue, 13 Jan 2026 14:37:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201820.1517387; Tue, 13 Jan 2026 14:37:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vffWa-0004cm-D1; Tue, 13 Jan 2026 14:37:36 +0000 Received: by outflank-mailman (input) for mailman id 1201820; Tue, 13 Jan 2026 14:37: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 1vffWX-0004b9-Nv for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 14:37: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 628b371a-f08d-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 15:37:29 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by AM9PR03MB7283.eurprd03.prod.outlook.com (2603:10a6:20b:273::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 14:37:25 +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.9499.005; Tue, 13 Jan 2026 14: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" X-Inumbo-ID: 628b371a-f08d-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xpSq4AuwBlflqhotO0ef3K1Vk6hFhEL3lFWSRClYlN6KMH9Hn15he8CZTy8lLUftevVJDkkXli8Er6FvXpzeFJY7Ad/SefO1CCIGCny7bBE7kkfuXtwCwTfgONwh8TQ11t+gtLhv+2c6bLqhjy8U4lwvGjlPytdtX1lsttuRhfHb2+n7NfsZjMAKnQzDifz6sisC/Whj1ZTTaRTpWQ/1nJuSSg6DbdZm2Xf0wjvWS1CgoLXlUW3lWQrH5r4B1F1zr6R9ve0+xeQ/SJKZf3WngTE+kBEYLJoGtEFkuzxdTqbQv2y7/qkiVujNtmT8MRvGYDFtbKcPAyhRAmhUbVfCOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Sab3lt7M3qgOTBecFprpzTUeeIa+07jq58UinBeVZMI=; b=c+qEpbrGa0QNWrBZ9KQwTEL2z23DcAOlyc2rYXHQaYdeyyMrLHjbvkso5hL5tXdAgQ/A+H0MZY10zc7dRY+V31JKJXpFBiKbSQnx70ng/PRGEqdlrWx2x79R3YFTb9iVqBoz+U7eNUYRHrp3UrYfmpEyj3T4yxANgPIwlE7MPAXTftYFRXH8+y7tBOTBmuD3bAqqjJHIUJcsMKBcy5yBO6/H7Pibg4PZbmHOUsAxTPqCrZSb/5YbEpKX4Z581A3m+NV7qiqTYW3qcGSMc+/pyqa+v/7t3sfdsR7k6wFM475e1Zl2J8MlJ3T/ouKSITbVt+cnmXh1ykUm37Clh1qPAg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Sab3lt7M3qgOTBecFprpzTUeeIa+07jq58UinBeVZMI=; b=EIRKl8pHTwaQujeSwBA5ue3h0BagFjPAxVEIN/saKltfjXG5x1wjTx0KamVMtY03tt6DfJSxdd7X1NlX6naNxbUvCTdAEvRUu0Z0ySqmdVCyFHcrXEG8dHqXhgvZNG8GWOM7cO5/BLdJSqK7CyGitQKbnIXqnpoWSzFcZcxPrFi3Ku+/2OudCKgnUWwuGJbrk8DbiwXLoZIggdebSi1kOY1dGy1liRmTOFIrePtM8yggafJFTIilULHcqI2/oU6398KcClAfi+ap1lxXE9iQTGauH//B4MKTeXwd+Bcr+vnLE8vUUrquJfvdqUn8Gi1uy0lDdoe5FQQF9PIyS1IRRg== From: Oleksii Moisieiev To: "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 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [PATCH v6 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHcSyafF7w2yrI9QUiIBj5xG1SGAbTdt+CAgHLmDAA= Date: Tue, 13 Jan 2026 14:37:25 +0000 Message-ID: <0e805633-4e68-43b5-8201-81dc5135010a@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_|AM9PR03MB7283:EE_ x-ms-office365-filtering-correlation-id: 25e98efa-743b-4238-5071-08de52b1451e x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|7416014|366016|38070700021; x-microsoft-antispam-message-info: =?utf-8?B?aGVPa3h1TDVtWFM4Z1VMbkZMdHRUODhOb01xdUY5ZE45WndUaEgwWmhvenh0?= =?utf-8?B?MjdBU2RTSUc4eFVTeTNIYnZ4cENENnJCckhnSVdDZDh3MXQ4YkVPNkxBWnlY?= =?utf-8?B?Vk5UTEgwTXhkclBDVVJlTkNwOXJveEtWb0VzcVdHbHViYmxLY0EzWWc2eTRY?= =?utf-8?B?Ym9qSW5jY20zYlRMelZid0tpRnl4V1RJcVNxbWErV25ianAraXZSUmloTzFP?= =?utf-8?B?aE5lTnRycTJJcnc3L0VTSVlmR3BEanFCWnZJSjRtVWZkMEpmL2xiV2ZvNmwx?= =?utf-8?B?ZmtwNitqT1dweWl2STk1OGphaU9jY1VPbDhQazlyczFDR3h6QnV2aTNMeHhp?= =?utf-8?B?aDlHeEV6YlMveksrYlRyR0NSUG0zWkJHWGhIUjVzYTJvK3BJNmQ0SWNnNGxS?= =?utf-8?B?SUhSZXhFTlY4d3M2R1RNOU1EWm5hbStCai93NjdiKzRXVGVIUGVuUWsyNUZn?= =?utf-8?B?TFRxMFpIUlhxK3ZmT2svbW5PRDdHZzc3UEViQURGb1Z5QlZ1YUhGcXE0cXBM?= =?utf-8?B?SENRUkYra1RtTjQ2TS8xMDRRRmhmQTByZWF4aGQ2Q0szejI4TTBVWHFOWDVw?= =?utf-8?B?dGZWTW83Smd3cHV1SXpMbFUwM1FOZUdqNjBRNE03QWxVdzdIeW5lVE9MU1NE?= =?utf-8?B?a205SS9ZdXRCcFVyampqTjVJcGxHN1B3Y1pVdE84V1o5T1RkVUFQR0NuZXBO?= =?utf-8?B?Mjc3NGVDd2xuU3JOY3hmUzdqa3BzMHlEdzBMWjRSazdYMFdFKzA3aXFUN3R6?= =?utf-8?B?VmhGQ0dyeEZ1cGVwRzU1U0F5VVcrdDVKSzdpS1RSekdpam1TTDJMNW8xeHUz?= =?utf-8?B?TVk0NVlPV0dDVytuOGZtZlV1bTZoQkRNRGRUT296VTQvV1FIQndWbUpBWnJG?= =?utf-8?B?S3p2L3dyMTBKeHpZU2JNTHRia3hLekJWNW9nSCt1dGdtU3hxK0dIN2tsWHdG?= =?utf-8?B?UDlMZGh5WjhzdzVLb0V1ell5WEVxTWJEYy9XT1h2SFRBaWwybUtsb2JRNXpU?= =?utf-8?B?R055a1Q1Z3JOQlJlSGl5V2tDY1dicW1ZZHlJSHR2Ky9IUFUrckUwWWRhZkFF?= =?utf-8?B?bHVuUTNNWFZkQjN1emZGSSt1blovRzArS0R1RHI2UU5WK3QxemdISFJuU1R2?= =?utf-8?B?TmJKZ25KMVBLcVB3MFgydzdQU0tpNDMxMXFIaXR2VHZMMndtNVhBTklxM3Rp?= =?utf-8?B?Mk9FOURNeERzc1F3OWhuUGVobm9kSDM3cC80eFRTbWxIZ1ZmUllJL2gzNEEv?= =?utf-8?B?eFFaWW5EN0ZFeHBXeUlIR3kxdVRGVEQ5TnZvR0MvSGFUeVFHckU5Ym95aXBF?= =?utf-8?B?NkdUeDBDMm5QSVVrT3lzclRtSlY2d1I4ZVJ0SkxyVGJvWVhkbWpsSFV6WDdw?= =?utf-8?B?V2Zta2dRS0FLT3I3V3hMdWJLbXgzMDNldmpPRW42U2dlUnptRVNJK1RpYmRy?= =?utf-8?B?T0trb09XbFhMYlJoSDNHVVBsVHRQM3QyWGEybVpvQjF3ZVhwdEMreHdNUVFa?= =?utf-8?B?ZDFFNVI0NzU3YTNOVk1RcVZBbEpHSDFxMnNtaEprelhxaDhlWVRUTHVqUXVD?= =?utf-8?B?T3ZwRk9DUkhSSXRoY3NwbGJIYksvTWNBQzRBM0ZxUi9BeGhGRncvWU1uOW1G?= =?utf-8?B?K1prR0JLU2pHdUJOZC9aczQ5RVNzeGZzRGIxNXF1MlU4eTZHdGlrem5iUHNE?= =?utf-8?B?UEpPeFAvd1R1elFHbWpwblNuZG9mSlJrS3orWHloZzI1TENWa3grZmgvTnpm?= =?utf-8?B?UTlLVVpuOEtzaVBHM0RlcFhPMU0xVFVMRllWdTRlcU5FR01YemxqMUpuQVJC?= =?utf-8?B?cjhFTEdoNkpRbExhQ1lyMWY5RFRSTUhBeW15U2ZCTWRZVjhCM0ZBb0g2NzBH?= =?utf-8?B?NE5LVkRZK1VFc05jTXJWaDZOWkhBRnY1NzAyTGhGWU5TTEl2elpFS2NzeDZv?= =?utf-8?B?QnhqclQ2ZUlJTkc0LzRhYk9GQzk1VU1teWhHU3pDemh6L05WQ1pzQ0tDRmNJ?= =?utf-8?B?V2FycXo1TjRnK244bW5FZlhqcWY2Qmk3ZTZXSVhZVVc3aE9zQmtLNlA4c1M1?= =?utf-8?Q?OsjJpL?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(7416014)(366016)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?OUh6RisyWTR6d0RCS0JzM2VieXVuWDQ1WXJvN1J4WTZmalVCSkVPQXFHbjEy?= =?utf-8?B?Q2xYeFQ2S1pubXoreXpncEhsQkJIVDFVbUFxdFBGZ0tNVW9ISzZtMFF6c1dE?= =?utf-8?B?czlGUE9qVE9zeFBjQ01WK2x2YUI2R3NmUzV1NDE4YVkzZTlTaHVjc0h3aE1y?= =?utf-8?B?aTZOQjNBcHBFYzVvMzA4Q0R1YTdmWU1rUmRpL08zTTNRdTd2SnRsL3J3c1oz?= =?utf-8?B?MGtLNVBqbForbXo4UmkyRnlUL2xCVDR3bWhzQU9Layt0aCtmM09UOGVoeWZF?= =?utf-8?B?b2R2cjNMQ0daTEhUdklzL255bWp5NXlqYjZaUXFsVml2M2FRaC9UU0NKbDFV?= =?utf-8?B?bGZNZDltQWkxd0FMYXlEZXFZZ3p4SVBsWm5tdWwrUUdOdXhlL1pBeWpMZTdw?= =?utf-8?B?TXY3VDlGOTM4Q25yT01qMXRDb1Z2OERucjIrOGlwL2M0QVZvQmwyRVVKK3lO?= =?utf-8?B?cUxXS3FuRDZoQm5DRi96UGVPZmlPL0lOMlh6bDJaQVRNNHBvdkUzdFNZMGFk?= =?utf-8?B?VlhnYnNIRzdrb0dkakVjRWpvTzFtZG04OXE3a1diR2RxdEhENlpzdnlGZStJ?= =?utf-8?B?Zk1VQ21XajhoejRFTitrRTRrZ2lHVFEvUTRldDVFa3NTTm9ZWllMZXRUWVR6?= =?utf-8?B?Z0NiVE1sVUZ2Q0tvMStLc1FtN2lVazBzUUtLRzJ5Q3pVd3g3YnE2ZGhZeVk0?= =?utf-8?B?L0x3S1ZwQ0FMM0N5NFpFTGxaTXkrcmhKaGJ4NGs0SU9QWHNNVmE1TmFIbzFv?= =?utf-8?B?Q3N1Y3oyL21vOVVGZnN6KzA2MDJITlR0RS9COWZkdUtVMjZ4UnNKK3p3SDJx?= =?utf-8?B?YllTNEd6Ti9USTUyRGs1NlNha091TjhZUFJBbzlYVDFHdXhIOUpmV0FNSzIz?= =?utf-8?B?SklHc3M2TTZ3TzY4OXZoTWhUV1hOWEZrakZBVTRMUlBaT2lzSml5cEVyNWYy?= =?utf-8?B?QXcxNitGNVo0RUxpZm1BMmR0SFNPS1RmMC9CUVRCVjd0bmk1dWtGakJvOTY1?= =?utf-8?B?VFJBMlNJMnVjOFhRdS9rU2JVbzZvbVBVWGM5bzQ2TG5kUjB6MCsyTFp0WE9B?= =?utf-8?B?TVF4cDlTMDBvS2UvSUVmdlUvVm54WGhlZE56bXhxUkVJaTVldnZNQTIvc2pj?= =?utf-8?B?dHBXcmhkdVo2OHJaWEJQNGlPNDlta2RFVFo0ZlpKUFZHMnYvMUFoL1ArcTlx?= =?utf-8?B?S1dvaEdwSDVuNkhqanZuR29uYnRUNnA1amtrT2FhY0txeWZGeTBaTk9RSHBl?= =?utf-8?B?UWU3ODYyb1AybEJaVTd5TjF0a3FGay9JU3dIUVk5R2xHR0xJSlp6QXJrSk83?= =?utf-8?B?WEtwSks3V3d0N0lFVFBVYVovMXJ6V1RZbWtYL2kzOGk1Ulg1TE9vN1VTNTdZ?= =?utf-8?B?OUF3UzdjQXYxWTdYOGZsZzR5aWd5MGJSeWE4NW9kU0tEMFZpbWE5REhTNHg2?= =?utf-8?B?SXhWcmRUWWhyakVQUUtSalhQTklFNzJsVlFBQWczRVdIcDJMV3ZDOGRBQ3hV?= =?utf-8?B?NDZsRmVGQzdpL25UV1preDNjSGY1MHhCOUk2cERaNlFwcEZEZlI0d0VjOG9a?= =?utf-8?B?ZC8zOVJQNjRDRm14Ny9QVWo3V1lrMGNmYXExRU0rUXhrRjM4NFh2MXRqV09C?= =?utf-8?B?UU1Jb2Nwa3BvYjVxaU96SEFGbFdKVlZQU1plL2xxZnBrNWtBdDRqOHR2cmVF?= =?utf-8?B?UktwdmFRb2FTbnN4RU82TVhjeUNsZktBeE5NaWRDSFdTUXdlajBNbGFCRksv?= =?utf-8?B?WWtMNVNYQzVxTFNYa3hzVmorZXBpZnRGVERIdURNSkhaV29kOTI2Z2tIZHJS?= =?utf-8?B?YlJWMCtzNUNUWmdxSVpoOW4wb3RuL05scVdId2NXZVFpKzNoL0N4a1A4Q3o1?= =?utf-8?B?NDc5Z0VPK1ZBeC9kT0VFa3JYTlFwTWdnT2d0aDlubmttK2JPTXRXWHFyMFZh?= =?utf-8?B?aFFVMzM5dHN2K2FuSEljaGluZHI5MGp2aTZqK2xIdytGTVNYYTFOWVhwc1li?= =?utf-8?B?KzRqTXdnbm5NN01XY2RQOW04eUZNV0o5UUNyUzViUjlzMzEvRnhRcWI5OTcz?= =?utf-8?B?WUdHZ0R2Zjc2aGNTc0pBSG5aYzZQU1MzU052MGZ6eWQ4U3ZPbitySm84ZG9X?= =?utf-8?B?ekhqVzZiSUhhQWMwL3I2ZTZSMHN1N1poTmphZUN4MzFNMUlENGwzdCt3T1RY?= =?utf-8?B?NmZNQXVOOUlmZHNJbG4wUkJEVjBQUWJwRm5ZaVNUdjlrcDJLUzk5VWhuaEVz?= =?utf-8?B?QzZ6VmhHMmpyaHI2UmladnA5VmN0d1VIRmsvRzRkeExzeDI0Uks1aVp6VWw4?= =?utf-8?B?Z1M4SUN6dHFPbmtTUTQxV3E4YWZEbHBkZWd5L2ZCTGgvZlo2aHVkMGduKzl2?= =?utf-8?Q?kK098PqJQEH3Vrzc=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <87A64D9830A6D54C832BCDF28F3CA3BC@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: 25e98efa-743b-4238-5071-08de52b1451e X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2026 14:37:25.5359 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YSOsHdJXKUF1TgKLjopLumfYS4u/RmPjRftw8AB9NBqxvSYK3lJD7AD79CSrBUmcIsxCM8qpeJYDOzAcDhdD0CHETrZN67Isgyo4RbRwhWU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB7283 SGkgQFN0ZWZhbm8sDQoNCkJlbG93LCBJIGhhdmUgcHJvdmlkZWQgbXkgYW5zd2VycyAobWFya2Vk IGFzIFtPTV0pIHRvIHlvdXIgcXVlc3Rpb25zDQpyZWdhcmRpbmcgdGhlIG5vZGUgaW1wbGVtZW50 YXRpb24uDQpJZiB5b3UgaGF2ZSBubyBmdXJ0aGVyIGNvbW1lbnRzLCBJIHdpbGwgcHJvY2VlZCB3 aXRoIHRoZSBpbXBsZW1lbnRhdGlvbi4NCg0KQmVzdCByZWdhcmRzLA0KT2xla3NpaQ0KDQoNCk9u IDAxLzExLzIwMjUgMTQ6MDAsIE9sZWtzaWkgTW9pc2llaWV2IHdyb3RlOg0KPiBIaSBhbGwsDQo+ IEZvbGxvd2luZyB1cCB1bmNvdmVyZWQgY29tbWVudHMgZnJvbSB2NS4gUXVlc3Rpb25zIGFyZSBt YXJrZWQgYXMgUToNCj4gYW5kIGFuc3dlcnMgYXMgQToNCj4gcGxlYXNlIHNlZSBiZWxvdzoNCj4N Cj4gT24gMDEvMTEvMjAyNSAxMzo1NiwgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+PiBUaGlz IHBhdGNoIGludHJvZHVjZXMgU0NJIGRyaXZlciB0byBzdXBwb3J0IGZvciBBUk0gRUwzIFRydXN0 ZWQNCj4+IEZpcm13YXJlLUENCj4+IChURi1BKSB3aGljaCBwcm92aWRlcyBTQ01JIGludGVyZmFj ZSB3aXRoIG11bHRpLWFnZW50IHN1cHBvcnQsIGFzIHNob3duDQo+PiBiZWxvdy4NCj4+DQo+PiAg ICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+PiAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+PiAgICB8IEVMMyBURi1B IFNDTUkgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+PiAgICArLS0tLS0tLSstLSstLS0t LS0tKy0tKy0tLS0tLS0rLS0rLS0tLS0tLSsrDQo+PiAgICB8c2htZW0xIHwgIHxzaG1lbTAgfCAg fHNobWVtMiB8ICB8c2htZW1YIHwNCj4+ICAgICstLS0tLSstKyAgKy0tLSstLS0rICArLS0rLS0t LSsgICstLS0rLS0tKw0KPj4gc21jLWlkMSB8ICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAg fA0KPj4gYWdlbnQxICB8ICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgfA0KPj4gICAgKy0t LS0tdi0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tKw0KPj4gICAgfCAgICAgICAg ICAgICAgfCAgICAgICAgIHwgICAgICAgICAgIHwgICAgfA0KPj4gICAgfCAgICAgICAgICAgICAg fCAgICAgICAgIHwgICAgICAgICAgIHwgICAgfA0KPj4gICAgKy0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLSstLS0tLS0tLS0tLSstLS0tKw0KPj4gICAgICAgICAgIHNtYy1pZDAgfCAgc21jLWlkMnwg ICAgc21jLWlkWHwNCj4+ICAgICAgICAgICBhZ2VudDAgIHwgIGFnZW50MiB8ICAgIGFnZW50WCB8 DQo+PiAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgfA0KPj4gICAgICAg ICAgICAgICstLS0tdi0tLSsgICstLXYtLS0tLSsgICstLXYtLS0tLSsNCj4+ICAgICAgICAgICAg ICB8ICAgICAgICB8ICB8ICAgICAgICB8ICB8ICAgICAgICB8DQo+PiAgICAgICAgICAgICAgfCBE b20wICAgfCAgfCBEb20xICAgfCAgfCBEb21YICAgfA0KPj4gICAgICAgICAgICAgIHwgICAgICAg IHwgIHwgICAgICAgIHwgIHwgICAgICAgIHwNCj4+ICAgICAgICAgICAgICB8ICAgICAgICB8ICB8 ICAgICAgICB8ICB8ICAgICAgICB8DQo+PiAgICAgICAgICAgICAgKy0tLS0tLS0tKyAgKy0tLS0t LS0tKyAgKy0tLS0tLS0tKw0KPj4NCj4+IFRoZSBFTDMgU0NNSSBtdWx0aS1hZ2VudCBmaXJtd2Fy ZSBpcyBleHBlY3RlZCB0byBwcm92aWRlIFNDTUkgU01DIHNoYXJlZA0KPj4gbWVtb3J5IHRyYW5z cG9ydCBmb3IgZXZlcnkgQWdlbnQgaW4gdGhlIHN5c3RlbS4NCj4+DQo+PiBUaGUgU0NNSSBBZ2Vu dCB0cmFuc3BvcnQgY2hhbm5lbCBkZWZpbmVkIGJ5IHBhaXI6DQo+PiAgIC0gc21jLWlkOiBTTUMg aWQgdXNlZCBmb3IgRG9vcmJlbGwNCj4+ICAgLSBzaG1lbTogc2hhcmVkIG1lbW9yeSBmb3IgbWVz c2FnZXMgdHJhbnNmZXIsIFhlbiBwYWdlDQo+PiAgIGFsaWduZWQuIFNoYXJlZCBtZW1vcnQgaXMg bWFwcGVkIHdpdGggdGhlIGZvbGxvd2luZyBmbGFnczoNCj4+ICAgTVRfREVWSUNFX25HblJFLg0K Pj4NCj4+IFRoZSBmb2xsd29pbmcgU0NNSSBBZ2VudHMgYXJlIGV4cGVjdGVkIHRvIGJlIGRlZmlu ZWQgYnkgU0NNSSBGVyB0bw0KPj4gZW5hYmxlIFNDTUkNCj4+IG11bHRpLWFnZW50IGZ1bmN0aW9u YWxpdHkgdW5kZXIgWGVuOg0KPj4gLSBYZW4gbWFuYWdlbWVudCBhZ2VudDogdHJ1c3RlZCBhZ2Vu dHMgdGhhdCBhY2Nlc3NlcyB0byB0aGUgQmFzZQ0KPj4gUHJvdG9jb2wNCj4+IGNvbW1hbmRzIHRv IGNvbmZpZ3VyZSBhZ2VudCBzcGVjaWZpYyBwZXJtaXNzaW9ucw0KPj4gLSBPU1BNIFZNIGFnZW50 czogbm9uLXRydXN0ZWQgYWdlbnQsIG9uZSBmb3IgZWFjaCBHdWVzdCBkb21haW4gd2hpY2ggaXMN Cj4+ICAgIGFsbG93ZWQgZGlyZWN0IEhXIGFjY2Vzcy4gQXQgbGVhc3Qgb25lIE9TUE0gVk0gYWdl bnQgaGFzIHRvIGJlDQo+PiBwcm92aWRlZA0KPj4gICAgYnkgRlcgaWYgSFcgaXMgaGFuZGxlZCBv bmx5IGJ5IERvbTAgb3IgRHJpdmVyIERvbWFpbi4NCj4+DQo+PiBUaGUgRUwzIFNDTUkgRlcgaXMg ZXhwZWN0ZWQgdG8gaW1wbGVtZW50IGZvbGxvd2luZyBCYXNlIHByb3RvY29sDQo+PiBtZXNzYWdl czoNCj4+IC0gQkFTRV9ESVNDT1ZFUl9BR0VOVCAob3B0aW9uYWwgaWYgYWdlbnRfaWQgd2FzIHBy b3ZpZGVkKQ0KPj4gLSBCQVNFX1JFU0VUX0FHRU5UX0NPTkZJR1VSQVRJT04gKG9wdGlvbmFsKQ0K Pj4gLSBCQVNFX1NFVF9ERVZJQ0VfUEVSTUlTU0lPTlMgKG9wdGlvbmFsKQ0KPj4NCj4+IFRoZSBT Q0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJpdmVyIGltcGxlbWVudHMgZm9sbG93aW5nDQo+PiBm dW5jdGlvbmFsaXR5Og0KPj4gLSBUaGUgZHJpdmVyIGlzIGluaXRpYWxpemVkIGJhc2VkIG9uIHRo ZSBgYHhlbixjb25maWdgYCBub2RlIHVuZGVyDQo+PiBgYGNob3NlbmBgDQo+PiAgICAob25seSBv bmUgU0NNSSBpbnRlcmZhY2UgaXMgc3VwcG9ydGVkKSwgd2hpY2ggZGVzY3JpYmVzIHRoZSBYZW4N Cj4+IG1hbmFnZW1lbnQNCj4+ICAgIGFnZW50IFNDTUkgaW50ZXJmYWNlLg0KPj4NCj4+IHNjbWlf c2htXzE6IHNyYW1ANDdmZjEwMDAgew0KPj4gICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxz Y21pLXNobWVtIjsNCj4+ICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYxMDAwIDB4MCAweDEw MDA+Ow0KPj4gfTsNCj4+IHNjbWlfeGVuOiBzY21pIHsNCj4+ICAgICAgICAgIGNvbXBhdGlibGUg PSAiYXJtLHNjbWktc21jIjsNCj4+ICAgICAgICAgIGFybSxzbWMtaWQgPSA8MHg4MjAwMDAwMz47 IDwtLS0gWGVuIG1hbmFnZW1lbnQgYWdlbnQgc21jLWlkDQo+PiAgICAgICAgICAjYWRkcmVzcy1j ZWxscyA9IDwgMT47DQo+PiAgICAgICAgICAjc2l6ZS1jZWxscyA9IDwgMD47DQo+PiAgICAgICAg ICAjYWNjZXNzLWNvbnRyb2xsZXItY2VsbHMgPSA8IDE+Ow0KPj4gICAgICAgICAgc2htZW0gPSA8 JnNjbWlfc2htXzE+OyA8LS0tIFhlbiBtYW5hZ2VtZW50IGFnZW50IHNobWVtDQo+PiB9Ow0KPj4N Cj4+IC0gVGhlIGRyaXZlciBvYnRhaW5zIFhlbiBzcGVjaWZpYyBTQ01JIEFnZW50J3MgY29uZmln dXJhdGlvbiBmcm9tIHRoZQ0KPj4gSG9zdCBEVCwgcHJvYmVzIEFnZW50cyBhbmQNCj4+ICAgIGJ1 aWxkcyBTQ01JIEFnZW50cyBsaXN0LiBUaGUgQWdlbnRzIGNvbmZpZ3VyYXRpb24gaXMgdGFrZW4g ZnJvbQ0KPj4gInNjbWktc2Vjb25kYXJ5LWFnZW50cyINCj4+ICAgIHByb3BlcnR5IHdoZXJlIGZp cnN0IGl0ZW0gaXMgImFybSxzbWMtaWQiLCBzZWNvbmQgLQ0KPj4gImFybSxzY21pLXNobWVtIiBw aGFuZGxlIGFuZCB0aGlyZCBpcw0KPj4gICAgb3B0aW9uYWwgImFnZW50X2lkIjoNCj4+DQo+PiBj aG9zZW4gew0KPj4gICAgcmFuZ2VzOw0KPj4gICAgeGVuLGNvbmZpZyB7DQo+IFE6IFtTdGVmYW5v XSBUaGUgbm9kZSBuYW1lIGNvdWxkIGJlIHhlbi1jb25maWcsIGJ1dCBpdCBkb2Vzbid0IG1hdHRl cg0KPiBiZWNhdXNlIHdlDQo+IHNob3VsZCBjaGVjayBmb3IgdGhlIGNvbXBhdGlibGUgc3RyaW5n IGluc3RlYWQgKG5vIGNoZWNrIG9uIG5vZGUgbmFtZSkuDQo+DQo+IFdlIG5lZWQgdG8gYWRkIGEg Y29tcGF0aWJsZSBzdHJpbmcgaGVyZSwgSSB3b3VsZCB1c2UgInhlbixzY21pIjoNCj4NCj4gICAg IGNvbXBhdGlibGUgPSAieGVuLHNjbWkiOw0KPg0KPg0KPiBBOiBbT01dIHRoaXMgaXMgYSBncmVh dCBmaW5kaW5nLiBBZnRlciBsb29raW5nIGludG8gaHlwZXJsYXVjaCBjb2RlIEkNCj4gc2VlIHRo ZSBmb2xsb3dpbmcgaW1wbGVtZW50YXRpb246DQo+DQo+DQo+IGNvbmZpZyB7DQo+ICAgICAgICAg Y29tcGF0aWJsZSA9ICJ4ZW4sY29uZmlnIjsNCj4gICAgIC4uLg0KPiB9Ow0KPg0KPiBJIHdhcyB0 aGlua2luZyBhYm91dCBjaGFuZ2luZyBjdXJyZW50IGFwcHJvYWNoIHRvIGhhdmUgdGhlIGZvbGxv d2luZw0KPiBmb3JtYXQ6DQo+DQo+IGNvbmZpZyB7DQo+ICAgICAgICAgY29tcGF0aWJsZSA9ICJ4 ZW4sY29uZmlnIjsNCj4gICAgIC4uLg0KPiAgICAgc2NtaV9jb25maWcgew0KPiAgICAgICAgIGNv bXBhdGlibGUgPSAieGVuLHNjaSI7IDwtLSBtb3JlIGdlbmVyaWMgY29tcGF0aWJsZSBzdHJpbmcN Cj4gdGhhbiAieGVuLHNjbWkiDQo+ICAgICAgICAgc2NtaS1zZWNvbmRhcnktYWdlbnRzID0gPA0K PiAgICAgICAgICAgICAgICAgICAweDgyMDAwMDAzICZzY21pX3NobV8wIDANCj4gICAgICAgICAg ICAgICAgICAgMHg4MjAwMDAwNCAmc2NtaV9zaG1fMiAyDQo+ICAgICAgICAgICAgICAgICAgIC4u Lj47DQo+ICAgICAgICAgICAgICAgICAjc2NtaS1zZWNvbmRhcnktYWdlbnRzLWNlbGxzID0gPDM+ OyA8LS0tIG9wdGlvbmFsLA0KPiBkZWZhdWx0IDMNCj4gICAgICAgICAgICAgICAgIHNjbWlfc2ht XzAgOiBzcmFtQDQ3ZmYwMDAwIHsNCj4gICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJt LHNjbWktc2htZW0iOw0KPiAgICAgICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYwMDAwIDB4 MCAweDEwMDA+Ow0KPiAgICAgICAgICAgICB9Ow0KPg0KPiAgICAgICAgIHNjbWlfc2htXzI6IHNy YW1ANDdmZjIwMDAgew0KPiAgICAgICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNj bWktc2htZW0iOw0KPiAgICAgICAgICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYyMDAwIDB4 MCAweDEwMDA+Ow0KPiAgICAgICAgICAgICB9Ow0KPiAgICAgICAgICAgICBzY21pX3hlbjogc2Nt aSB7DQo+ICAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxzY21pLXNtYyI7DQo+ICAg ICAgICAgICAgICAgICBhcm0sc21jLWlkID0gPDB4ODIwMDAwMDI+OyA8LS0tIFhlbiBtYW5lZ2Vt ZW50IGFnZW50DQo+IHNtYy1pZA0KPiAgICAgICAgICAgICAgICAgI2FkZHJlc3MtY2VsbHMgPSA8 IDE+Ow0KPiAgICAgICAgICAgICAgICAgI3NpemUtY2VsbHMgPSA8IDA+Ow0KPiAgICAgICAgICAg ICAgICAgI2FjY2Vzcy1jb250cm9sbGVyLWNlbGxzID0gPCAxPjsNCj4gICAgICAgICAgICAgICAg IHNobWVtID0gPCZzY21pX3NobV8xPjsgPC0tLSBYZW4gbWFuZWdlbWVudCBhZ2VudCBzaG1lbQ0K PiAgICAgICAgICAgICB9Ow0KPiAgICAgfTsNCj4gICAgIC4uLg0KPiB9Ow0KPg0KPiBhbmQgdXBk YXRlIHNjbWktbXVsdGlhZ2VudCBkcml2ZXIgdG8gbWF0Y2ggInhlbixzY2kiIGNvbXBhdGlibGUg YW5kDQo+IHByb2Nlc3MgYWxsIHN1Ym5vZGVzIGR1cmluZyBwcm9iZS4NCj4gV2hhdCBkbyB5b3Ug dGhpbmsgYWJvdXQgdGhpcyBhcHByb2FjaD8NCj4NCj4+ICAgICAgcmFuZ2VzOw0KPj4gICAgICBz Y21pLXNlY29uZGFyeS1hZ2VudHMgPSA8DQo+PiAgICAgICAgICAgICAgICAgICAgMHg4MjAwMDAw MyAmc2NtaV9zaG1fMCAwDQo+PiAgICAgICAgICAgICAgICAgICAgMHg4MjAwMDAwNCAmc2NtaV9z aG1fMiAyDQo+PiAgICAgICAgICAgICAgICAgICAgMHg4MjAwMDAwNSAmc2NtaV9zaG1fMyAzDQo+ PiAgICAgICAgICAgICAgICAgICAgMHg4MjAwMDAwNiAmc2NtaV9zaG1fNCA0PjsNCj4+ICAgICAg I3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxscyA9IDwzPjsgPC0tLSBvcHRpb25hbCwgZGVmYXVs dCAzDQo+Pg0KPj4gICAgICBzY21pX3NobV8wIDogc3JhbUA0N2ZmMDAwMCB7DQo+PiAgICAgICAg ICBjb21wYXRpYmxlID0gImFybSxzY21pLXNobWVtIjsNCj4+ICAgICAgICAgIHJlZyA9IDwweDAg MHg0N2ZmMDAwMCAweDAgMHgxMDAwPjsNCj4+ICAgICAgfTsNCj4+DQo+PiAgICAgIHNjbWlfc2ht XzI6IHNyYW1ANDdmZjIwMDAgew0KPj4gICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNj bWktc2htZW0iOw0KPj4gICAgICAgICAgICAgIHJlZyA9IDwweDAgMHg0N2ZmMjAwMCAweDAgMHgx MDAwPjsNCj4+ICAgICAgfTsNCj4+ICAgICAgc2NtaV9zaG1fMzogc3JhbUA0N2ZmMzAwMCB7DQo+ PiAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+PiAgICAgICAg ICAgICAgcmVnID0gPDB4MCAweDQ3ZmYzMDAwIDB4MCAweDEwMDA+Ow0KPj4gICAgICB9Ow0KPj4g ICAgICBzY21pX3NobV80OiBzcmFtQDQ3ZmY0MDAwIHsNCj4+ICAgICAgICAgICAgICBjb21wYXRp YmxlID0gImFybSxzY21pLXNobWVtIjsNCj4+ICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdm ZjQwMDAgMHgwIDB4MTAwMD47DQo+PiAgICAgIH07DQo+Pg0KPj4gICAgICAvLyBYZW4gU0NNSSBt YW5hZ2VtZW50IGNoYW5uZWwNCj4+ICAgICAgc2NtaV9zaG1fMTogc3JhbUA0N2ZmMTAwMCB7DQo+ PiAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+PiAgICAgICAg ICAgICAgcmVnID0gPDB4MCAweDQ3ZmYxMDAwIDB4MCAweDEwMDA+Ow0KPj4gICAgICB9Ow0KPj4N Cj4+ICAgICAgc2NtaV94ZW46IHNjbWkgew0KPj4gICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0s c2NtaS1zbWMiOw0KPj4gICAgICAgICAgYXJtLHNtYy1pZCA9IDwweDgyMDAwMDAyPjsgPC0tLSBY ZW4gbWFuYWdlbWVudCBhZ2VudCBzbWMtaWQNCj4+ICAgICAgICAgICNhZGRyZXNzLWNlbGxzID0g PCAxPjsNCj4+ICAgICAgICAgICNzaXplLWNlbGxzID0gPCAwPjsNCj4+ICAgICAgICAgICNhY2Nl c3MtY29udHJvbGxlci1jZWxscyA9IDwgMT47DQo+PiAgICAgICAgICBzaG1lbSA9IDwmc2NtaV9z aG1fMT47IDwtLS0gWGVuIG1hbmFnZW1lbnQgYWdlbnQgc2htZW0NCj4+ICAgICAgfTsNCj4+ICAg IH07DQo+PiB9Ow0KPj4NCj4+IC97DQo+PiAgICAgIC8vIEhvc3QgU0NNSSBPU1BNIGNoYW5uZWwg LSBwcm92aWRlZCB0byB0aGUgRG9tMCBhcyBpcyBpZiBTQ01JDQo+PiBlbmFibGVkIGZvciBpdA0K Pj4gICAgICBzY21pX3NobTogc3JhbUA0N2ZmMDAwMCB7DQo+PiAgICAgICAgICAgICAgY29tcGF0 aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+PiAgICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3 ZmYwMDAwIDB4MCAweDEwMDA+Ow0KPj4gICAgICB9Ow0KPj4NCj4+ICAgICAgZmlybXdhcmUgew0K Pj4gICAgICAgICAgc2NtaTogc2NtaSB7DQo+PiAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJh cm0sc2NtaS1zbWMiOw0KPj4gICAgICAgICAgICAgIGFybSxzbWMtaWQgPSA8MHg4MjAwMDAwMj47 IDwtLS0gSG9zdCBPU1BNIGFnZW50IHNtYy1pZA0KPj4gICAgICAgICAgICAgICNhZGRyZXNzLWNl bGxzID0gPCAxPjsNCj4+ICAgICAgICAgICAgICAjc2l6ZS1jZWxscyA9IDwgMD47DQo+PiAgICAg ICAgICAgICAgc2htZW0gPSA8JnNjbWlfc2htPjsgPC0tLSBIb3N0IE9TUE0gYWdlbnQgc2htZW0N Cj4+DQo+PiAgICAgICAgICAgICAgcHJvdG9jb2xAWHsNCj4+ICAgICAgICAgICAgICB9Ow0KPj4g ICAgICAgICAgfTsNCj4+ICAgICAgfTsNCj4+IH07DQo+Pg0KPj4gVGhpcyBhcHByb2FjaCBhbGxv d3MgZGVmaW5pbmcgbXVsdGlwbGUgU0NNSSBBZ2VudHMgYnkgYWRkaW5nDQo+PiBYZW4tc3BlY2lm aWMgcHJvcGVydGllcyB1bmRlcg0KPj4gdGhlIGBgL2Nob3NlbmBgIG5vZGUgdG8gdGhlIEhvc3Qg RGV2aWNlIFRyZWUsIGxlYXZpbmcgdGhlIG1haW4gcGFydA0KPj4gdW5jaGFuZ2VkLiBUaGUgSG9z dCBEVA0KPj4gU0NNSSBjaGFubmVsIHdpbGwgYmUgcGFzc2VkIHRvIERvbTAuDQo+Pg0KPj4gVGhl IFhlbiBtYW5hZ2VtZW50IGFnZW50IGlzIGRlc2NyaWJlZCBhcyBhIGBgc2NtaV94ZW5gYCBub2Rl IHVuZGVyDQo+PiB0aGUgYGAvY2hvc2VuYGAgbm9kZSwgd2hpY2gNCj4+IGlzIHVzZWQgYnkgWGVu IHRvIGNvbnRyb2wgb3RoZXIgU0NNSSBBZ2VudHMgaW4gdGhlIHN5c3RlbS4NCj4+DQo+PiBBbGwg c2Vjb25kYXJ5IGFnZW50cycgY29uZmlndXJhdGlvbnMgYXJlIHByb3ZpZGVkIGluIHRoZQ0KPj4g YGBzY21pLXNlY29uZGFyeS1hZ2VudHNgYCBwcm9wZXJ0eSB3aXRoDQo+PiBhbiBvcHRpb25hbCBg YGFnZW50X2lkYGAgZmllbGQuDQo+Pg0KPj4gVGhlIGBgYWdlbnRfaWRgYCBmcm9tIHRoZSBgYHNj bWktc2Vjb25kYXJ5LWFnZW50c2BgIHByb3BlcnR5IGlzIHVzZWQNCj4+IHRvIGlkZW50aWZ5IHRo ZSBhZ2VudCBpbiB0aGUNCj4+IHN5c3RlbSBhbmQgY2FuIGJlIG9taXR0ZWQgYnkgc2V0dGluZyBg YCNzY21pLXNlY29uZGFyeS1hZ2VudHMtY2VsbHMgPQ0KPj4gPDI+YGAsIHNvIHRoZSBTZWNvbmRh cnkNCj4+IEFnZW50cyBjb25maWd1cmF0aW9uIHdpbGwgbG9vayBsaWtlIHRoaXM6DQo+Pg0KPj4g Y2hvc2VuIHsNCj4+ICAgIHhlbixjb25maWcgew0KPj4gICAgICBzY21pLXNlY29uZGFyeS1hZ2Vu dHMgPSA8DQo+PiAgICAgICAgICAgICAgICAgICAgMHg4MjAwMDAwMyAmc2NtaV9zaG1fMA0KPj4g ICAgICAgICAgICAgICAgICAgIDB4ODIwMDAwMDQgJnNjbWlfc2htXzINCj4+ICAgICAgICAgICAg ICAgICAgICAweDgyMDAwMDA1ICZzY21pX3NobV8zDQo+PiAgICAgICAgICAgICAgICAgICAgMHg4 MjAwMDAwNiAmc2NtaV9zaG1fND47DQo+PiAgICAgICNzY21pLXNlY29uZGFyeS1hZ2VudHMtY2Vs bHMgPSA8Mj47DQo+PiAgICB9Ow0KPj4gfQ0KPj4NCj4+IEluIHRoaXMgY2FzZSwgWGVuIHdpbGwg dXNlIHRoZSBgYFNDTUlfQkFTRV9ESVNDT1ZFUl9BR0VOVGBgIGNhbGwgdG8NCj4+IGRpc2NvdmVy IHRoZSBgYGFnZW50X2lkYGANCj4+IGZvciBlYWNoIHNlY29uZGFyeSBhZ2VudC4gUHJvdmlkaW5n IHRoZSBgYGFnZW50X2lkYGAgaW4gdGhlDQo+PiBgYHNjbWktc2Vjb25kYXJ5LWFnZW50c2BgIHBy b3BlcnR5DQo+PiBhbGxvd3Mgc2tpcHBpbmcgdGhlIGRpc2NvdmVyeSBjYWxsLCB3aGljaCBpcyB1 c2VmdWwgd2hlbiB0aGUNCj4+IHNlY29uZGFyeSBhZ2VudCdzIHNoYXJlZCBtZW1vcnkgaXMNCj4+ IG5vdCBhY2Nlc3NpYmxlIGJ5IFhlbiBvciB3aGVuIGJvb3QgdGltZSBpcyBpbXBvcnRhbnQgYmVj YXVzZSBpdA0KPj4gYWxsb3dzIHNraXBwaW5nIHRoZSBhZ2VudA0KPj4gZGlzY292ZXJ5IHByb2Nl ZHVyZS4NCj4+DQo+PiAgICBOb3RlIHRoYXQgWGVuIGlzIHRoZSBvbmx5IG9uZSBlbnRyeSBpbiB0 aGUgc3lzdGVtIHdoaWNoIG5lZWQgdG8ga25vdw0KPj4gICAgYWJvdXQgU0NNSSBtdWx0aS1hZ2Vu dCBzdXBwb3J0Lg0KPj4NCj4+IC0gSXQgaW1wbGVtZW50cyB0aGUgU0NJIHN1YnN5c3RlbSBpbnRl cmZhY2UgcmVxdWlyZWQgZm9yIGNvbmZpZ3VyaW5nIGFuZA0KPj4gZW5hYmxpbmcgU0NNSSBmdW5j dGlvbmFsaXR5IGZvciBEb20wL2h3ZG9tIGFuZCBHdWVzdCBkb21haW5zLiBUbyBlbmFibGUNCj4+ IFNDTUkgZnVuY3Rpb25hbGl0eSBmb3IgZG9tYWluIGl0IGhhcyB0byBiZSBjb25maWd1cmVkIHdp dGggdW5pcXVlDQo+PiBzdXBwb3J0ZWQNCj4+IFNDTUkgQWdlbnRfaWQgYW5kIHVzZSBjb3JyZXNw b25kaW5nIFNDTUkgU01DIHNoYXJlZCBtZW1vcnkgdHJhbnNwb3J0DQo+PiBbc21jLWlkLCBzaG1l bV0gZGVmaW5lZCBmb3IgdGhpcyBTQ01JIEFnZW50X2lkLg0KPj4gLSBPbmNlIFhlbiBkb21haW4g aXMgY29uZmlndXJlZCBpdCBjYW4gY29tbXVuaWNhdGUgd2l0aCBFTDMgU0NNSSBGVzoNCj4+ICAg IC0tIHplcm8tY29weSwgdGhlIGd1ZXN0IGRvbWFpbiBwdXRzIFNDTUkgbWVzc2FnZSBpbiBzaG1l bTsNCj4+ICAgIC0tIHRoZSBndWVzdCB0cmlnZ2VycyBTTUMgZXhjZXB0aW9uIHdpdGggc21jLWlk IChkb29yYmVsbCk7DQo+PiAgICAtLSB0aGUgWGVuIGRyaXZlciBjYXRjaGVzIGV4Y2VwdGlvbiwg ZG8gY2hlY2tzIGFuZCBzeW5jaHJvbm91c2x5DQo+PiBmb3J3YXJkcw0KPj4gICAgaXQgdG8gRUwz IEZXLg0KPj4gLSB0aGUgWGVuIGRyaXZlciBzZW5kcyBCQVNFX1JFU0VUX0FHRU5UX0NPTkZJR1VS QVRJT04gbWVzc2FnZSB0byBYZW4NCj4+ICAgIG1hbmFnZW1lbnQgYWdlbnQgY2hhbm5lbCBvbiBk b21haW4gZGVzdHJveSBldmVudC4gVGhpcyBhbGxvd3MgdG8NCj4+IHJlc2V0DQo+PiAgICByZXNv dXJjZXMgdXNlZCBieSBkb21haW4gYW5kIHNvIGltcGxlbWVudCB1c2UtY2FzZSBsaWtlIGRvbWFp bg0KPj4gcmVib290Lg0KPj4NCj4+IERvbTAgRW5hYmxlIFNDTUkgU01DOg0KPj4gICAtIHBhc3Mg ZG9tMF9zY21pX2FnZW50X2lkPTxhZ2VudF9pZD4gaW4gWGVuIGNvbW1hbmQgbGluZS4gaWYgbm90 DQo+PiBwcm92aWRlZA0KPj4gICAgIFNDTUkgd2lsbCBiZSBkaXNhYmxlZCBmb3IgRG9tMCBhbmQg YWxsIFNDTUkgbm9kZXMgcmVtb3ZlZCBmcm9tDQo+PiBEb20wIERULg0KPj4gICAgIFRoZSBkcml2 ZXIgdXBkYXRlcyBEb20wIERUIFNDTUkgbm9kZSAiYXJtLHNtYy1pZCIgdmFsdWUgYW5kIGZpeA0K Pj4gdXAgc2htZW0NCj4+ICAgICBub2RlIGFjY29yZGluZyB0byBhc3NpZ25lZCBhZ2VudF9pZC4N Cj4+DQo+PiBHdWVzdCBkb21haW5zIGVuYWJsZSBTQ01JIFNNQzoNCj4+ICAgLSB4bC5jZmc6IGFk ZCBjb25maWd1cmF0aW9uIG9wdGlvbiBhcyBiZWxvdw0KPj4NCj4+ICAgICBhcm1fc2NpID0gInR5 cGU9c2NtaV9zbWNfbXVsdGlhZ2VudCxhZ2VudF9pZD0yIg0KPj4NCj4+ICAgLSB4bC5jZmc6IGVu YWJsZSBhY2Nlc3MgdG8gdGhlICJhcm0sc2NtaS1zaG1lbSIgd2hpY2ggc2hvdWxkDQo+PiBjb3Jy ZXNwb25kIGFzc2lnbmVkIGFnZW50X2lkIGZvcg0KPj4gICAgIHRoZSBkb21haW4sIGZvciBleGFt cGxlOg0KPj4NCj4+IGlvbWVtID0gWw0KPj4gICAgICAiNDdmZjIsMUAyMjAwMSIsDQo+PiBdDQo+ Pg0KPj4gICAtIERUOiBhZGQgU0NNSSBub2RlcyB0byB0aGUgRHJpdmVyIGRvbWFpbiBwYXJ0aWFs IGRldmljZSB0cmVlIGFzIGluDQo+PiB0aGUNCj4+ICAgYmVsb3cgZXhhbXBsZS4gVGhlICJhcm0s c21jLWlkIiBzaG91bGQgY29ycmVzcG9uZCBhc3NpZ25lZCBhZ2VudF9pZA0KPj4gZm9yIHRoZSBk b21haW46DQo+Pg0KPj4gcGFzc3Rocm91Z2ggew0KPj4gICAgIHNjbWlfc2htXzA6IHNyYW1AMjIw MDEwMDAgew0KPj4gICAgICAgICBjb21wYXRpYmxlID0gImFybSxzY21pLXNobWVtIjsNCj4+ICAg ICAgICAgcmVnID0gPDB4MCAweDIyMDAxMDAwIDB4MCAweDEwMDA+Ow0KPj4gICAgIH07DQo+Pg0K Pj4gICAgIGZpcm13YXJlIHsNCj4+ICAgICAgICAgIGNvbXBhdGlibGUgPSAic2ltcGxlLWJ1cyI7 DQo+PiAgICAgICAgICAgICAgc2NtaTogc2NtaSB7DQo+PiAgICAgICAgICAgICAgICAgIGNvbXBh dGlibGUgPSAiYXJtLHNjbWktc21jIjsNCj4+ICAgICAgICAgICAgICAgICAgYXJtLHNtYy1pZCA9 IDwweDgyMDAwMDA0PjsNCj4+ICAgICAgICAgICAgICAgICAgc2htZW0gPSA8JnNjbWlfc2htXzA+ Ow0KPj4gICAgICAgICAgICAgICAgICAuLi4NCj4+ICAgICAgICAgICAgICB9DQo+PiAgICAgIH0N Cj4+IH0NCj4+DQo+PiBTQ01JICI0LjIuMS4xIERldmljZSBzcGVjaWZpYyBhY2Nlc3MgY29udHJv bCINCj4+DQo+PiBUaGUgWEVOIFNDSSBTQ01JIFNNQyBtdWx0aS1hZ2VudCBkcml2ZXIgcGVyZm9y bXMgImFjY2Vzcy1jb250cm9sbGVyIg0KPj4gcHJvdmlkZXIgZnVuY3Rpb24NCj4+IGluIGNhc2Ug RUwzIFNDTUkgRlcgaW1wbGVtZW50cyBTQ01JICI0LjIuMS4xIERldmljZSBzcGVjaWZpYyBhY2Nl c3MNCj4+IGNvbnRyb2wiIGFuZCBwcm92aWRlcyB0aGUNCj4+IEJBU0VfU0VUX0RFVklDRV9QRVJN SVNTSU9OUyBjb21tYW5kIHRvIGNvbmZpZ3VyZSB0aGUgZGV2aWNlcyB0aGF0IGFuDQo+PiBhZ2Vu dHMgaGF2ZSBhY2Nlc3MgdG8uDQo+PiBUaGUgRFQgU0NNSSBub2RlIHNob3VsZCAiI2FjY2Vzcy1j b250cm9sbGVyLWNlbGxzPTwxPiIgcHJvcGVydHkgYW5kDQo+PiBEVCBkZXZpY2VzIHNob3VsZCBi ZSBib3VuZA0KPj4gdG8gdGhlIFhlbiBTQ01JLg0KPj4NCj4+ICZpMmMxIHsNCj4+ICAgICBhY2Nl c3MtY29udHJvbGxlcnMgPSA8JnNjbWkgMD47DQo+PiB9Ow0KPj4NCj4+IFRoZSBEb20wIGFuZCBk b20wbGVzcyBkb21haW5zIERUIGRldmljZXMgd2lsbCBiZSBwcm9jZXNzZWQNCj4+IGF1dG9tYXRp Y2FsbHkgdGhyb3VnaA0KPj4gc2NpX2Fzc2lnbl9kdF9kZXZpY2UoKSBjYWxsLCBidXQgdG8gYXNz aWduIFNDTUkgZGV2aWNlcyBmcm9tDQo+PiB0b29sc3RhY2sgdGhlIHhsLmNmZzoiZHRkZXYiIHBy b3BlcnR5DQo+PiBzaGFsbCBiZSB1c2VkOg0KPj4NCj4+IGR0ZGV2ID0gWw0KPj4gICAgICAiL3Nv Yy9pMmNAZTY1MDgwMDAiLA0KPj4gXQ0KPj4NCj4+IHhsLmNmZzpkdGRldiB3aWxsIGNvbnRhaW4g YWxsIG5vZGVzIHdoaWNoIGFyZSB1bmRlciBTQ01JIG1hbmFnZW1lbnQNCj4+IChub3Qgb25seSB0 aG9zZSB3aGljaCBhcmUgYmVoaW5kIElPTU1VKS4NCj4+DQo+PiBbMV0NCj4+IGh0dHBzOi8vd2Vi LmdpdC5rZXJuZWwub3JnL3B1Yi9zY20vbGludXgva2VybmVsL2dpdC90b3J2YWxkcy9saW51eC5n aXQvdHJlZS9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvZmlybXdhcmUvYXJtLHNj bWkueWFtbA0KPj4gWzJdDQo+PiBodHRwczovL3dlYi5naXQua2VybmVsLm9yZy9wdWIvc2NtL2xp bnV4L2tlcm5lbC9naXQvdG9ydmFsZHMvbGludXguZ2l0L3RyZWUvRG9jdW1lbnRhdGlvbi9kZXZp Y2V0cmVlL2JpbmRpbmdzL2FjY2Vzcy1jb250cm9sbGVycy9hY2Nlc3MtY29udHJvbGxlcnMueWFt bA0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6IEdyeWdvcmlpIFN0cmFzaGtvIDxncnlnb3JpaV9zdHJh c2hrb0BlcGFtLmNvbT4NCj4+IFNpZ25lZC1vZmYtYnk6IE9sZWtzaWkgTW9pc2llaWV2IDxvbGVr c2lpX21vaXNpZWlldkBlcGFtLmNvbT4NCj4+IC0tLQ0KPj4NCj4+IENoYW5nZXMgaW4gdjY6DQo+ PiAtIHVwZGF0ZWQgc2NtaS1zaG1lbSB0byB1c2UgaW8uaCBmcm9tIGdlbmVyaWMgbG9jYXRpb24N Cj4+IC0gdXBkYXRlIHNjbWlfYWdlbnRfaWQgcGFyYW1ldGVyIHRvIGJlIHByb3ZpZGVkIGluc2lk ZSBkb20wPSBwYXJhbWV0ZXINCj4+IGxpc3QgYW5kIGhhdmUgdGhlIGZvbGxvd2luZyBmb3JtYXQg ImRvbTA9c2NpLWFnZW50LWlkPTAiDQo+PiBUaGlzIGNoYW5nZSB3YXMgZG9uZSBhcyBhIHJlc3Bv bnNlIGZvciBTdGVmYW5vIGNvbW1lbnQgYW5kDQo+PiByZXF1aXJlcyBhIGxvdCBvZiBjb2RlIGNo YW5nZXMsIGJ1dCBwcm9kdWNlcyBtdWNoIGNsZWFuZXIgc29sdXRpb24NCj4+IHRoYXQncyB3aHkg SSd2ZSBhZGRlZCBpdCB0byB0aGUgY29kZS4NCj4+IC0gZml4IGZpbGUgY29tbWVudHMgYW5kIHJl dHVybiBjb2Rlcw0KPj4gLSBmaXggbGVuZ2h0IGNoZWNrcyBpbiBzaG1lbV97Z2V0LHB1dH1fbWVz c2FnZSB0byB1c2Ugb2Zmc2V0b2YNCj4+IC0gcmVtb3ZlIGxlbiBtZW1iZXIgZnJvbSBzY21pX2No YW5uZWwgc3RydWN0dXJlIGFzIGl0IGlzIG5vdCB1c2VkDQo+PiAtIHNldCBzY21pLXNlY29uZGFy eS1hZ2VudHMgcHJvcGVydHkgdG8gYmUgbWFuZGF0b3J5IHNpbmNlIGlmIG5vDQo+PiBzZWNvbmRh cnkgYWdlbnRzIHdlcmUgcHJvdmlkZWQgdGhlbiB0aGVyZSBpcyBubyBzZW5jZSB0byBlbmFibGUg c2NtaQ0KPj4gd2hlbiBubyBzZWNvbmRhcnkgYWdlbnRzIGFyZSBwb3B1bGF0ZWQgdG8gdGhlIERv bWFpbnMNCj4+IC0gdXBkYXRlIGRvY3VtZW50YXRpb24gaW4gYm9vdGluZy50eHQsIGFkZGVkIHhl bl9zY21pIG5vZGUgdG8gdGhlDQo+PiBleGFtcGxlDQo+PiAtIGFkanVzdCBkLT5hcmNoLnNjaV9l bmFibGVkIHZhbHVlIGluIHNjbWlfZG9tYWluX2Rlc3Ryb3kNCj4+IC0gZml4IGxvY2sgbWFuYWdl bWVudCBpbiBzbWNfY3JlYXRlX2NoYW5uZWwgY2FsbA0KPj4gLSBhdm9pZCBleHRyYSBtYXBfY2hh bm5lbF9tZW1vcnkgY29tbWFuZCBmb3IgWGVuIG1hbmFnZW1lbnQgY2hhbm5lbA0KPj4gYmVjYXVz ZSBjb2xsZWN0X2FnZW50X2lkIGNhbGwgdW5tYXBzIG1lbW9yeSBpZiBET01JRF9YRU4gaXMgbm90 DQo+PiBzZXQuIFNvIGZvciBYZW4gbWFuYWdlbWVudCBjaGFubmVsIHdlIGNhbiBpbml0IGRvbWFp bl9pZCBhZCBET01JRF9YRU4NCj4+IGJlZm9yZSBjYWxsaW5nIGNvbGxlY3RfYWdlbnRfaWQgc28g bWVtb3J5IHNob3VsZG4ndCBiZSB1bm1hcHBlZC4NCj4+DQo+PiBDaGFuZ2VzIGluIHY1Og0KPj4g LSBmaXggZGV2aWNlLXRyZWUgZXhhbXBsZSBmb3JtYXQgaW4gYm9vdGluZy50eHQsIGFkZGVkICI7 IiBhZnRlciAifSIuDQo+PiAtIHVwZGF0ZSBkZWZpbmUgaW4gc2NtaS1wcm90by5oDQo+PiAtIHVw ZGF0ZSBkZWZpbmUgaW4gc2NtaS1zaG1lbS5oIGZpbGUNCj4+IC0gc2NtaV9hc3NpZ25fZGV2aWNl IC0gZG8gbm90IGlnbm9yZSAtRU9QTk9UU1VQUCByZXR1cm4NCj4+IGNvZGUgb2YgdGhlIGRvX3Nt Y194ZmVyDQo+PiAtIHJlbW92ZSBvdmVyd3JpdGluZyBhZ2VudF9jaGFubmVsLT5hZ2VudF9pZCBh ZnRlcg0KPj4gU0NNSV9CQVNFX0RJU0NPVkVSX0FHRU5UIGNhbGwNCj4+IC0gYWRkIG11bHRpLWFn ZW50IGZpbGVzIHRvIHRoZSBNQUlOVEFJTkVSUw0KPj4gLSBhZGQgU0NNSSBtdWx0aS1hZ2VudCBk ZXNjcmlwdGlvbiB0byB0aGUgU1VQUE9SVC5tZA0KPj4gLSBoYW5kbGUgQVJNX1NNQ0NDX0lOVkFM SURfUEFSQU1FVEVSIHJldHVybiBjb2RlIGFuZCByZXR1cm4gLUVJTlZBTA0KPj4gZm9yIHNtYyBj YWxsDQo+PiAtIHVwZGF0ZWQgY29sbGVjdF9hZ2VudHMgZnVuY3Rpb24uIFNldCBhZ2VudF9pZCBw YXJhbWV0ZXIgYXMgb3B0aW9uYWwNCj4+IGluIHNjbWktc2Vjb25kYXJ5LWFnZW50cyBkZXZpY2Ut dHJlZSBwcm9wZXJ0eQ0KPj4gLSBpbnRyb2R1Y2UgIiNzY21pLXNlY29uZGFyeS1hZ2VudHMtY2Vs bHMiIHBhcmFtZXRlciB0byBzZXQgaWYNCj4+IGFnZW50X2lkIHdhcyBwcm92aWRlZA0KPj4gLSBy ZWFubWUgeGVuLHNjbWktc2Vjb25kYXJ5LWFnZW50cyBwcm9wZXJ0eSB0byBzY21pLXNlY29uZGFy eS1hZ2VudHMNCj4+IC0gbW92ZSBtZW1jcHVfdG9pby9mcm9taW8gZm9yIHRoZSBnZW5lcmljIHBs YWNlDQo+PiAtIHVwZGF0ZSBYZW4gdG8gZ2V0IG1hbmFnZW1lbnQgY2hhbm5lbCBmcm9tIC9jaG9z ZW4veGVuLGNvbmZpZyBub2RlDQo+PiAtIGdldCBoeXBlcnZpc29yIGNoYW5ubmVsIGZyb20gbm9k ZSBpbnN0ZWFkIG9mIHVzaW5nIGhhcmRjb2RlZA0KPj4gLSB1cGRhdGUgaGFuZGxpbmcgc2NtaSBh bmQgc2htZW0gbm9kZXMgZm9yIHRoZSBkb21haW4NCj4+IC0gU2V0IG11bHRpLWFnZW50IGRyaXZl ciB0byBzdXBwb3J0IG9ubHkgQXJtNjQNCj4+DQo+PiBDaGFuZ2VzIGluIHY0Og0KPj4gLSB0b29s c3RhY2sgY29tbWVudHMgZnJvbSBBbnRob255IFBFUkFSRA0KPj4gLSBhZGRlZCBkb20wbGVzcyBz dXBwb3J0DQo+PiAtIGFkZGVkIGRvYyBmb3IgInhlbixzY21pLXNlY29uZGFyeS1hZ2VudHMiDQo+ Pg0KPj4gICBNQUlOVEFJTkVSUyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICA0 ICsNCj4+ICAgU1VQUE9SVC5tZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAx MSArDQo+PiAgIGRvY3MvbWFuL3hsLmNmZy41LnBvZC5pbiAgICAgICAgICAgICAgICAgICAgfCAg MTMgKw0KPj4gICBkb2NzL21pc2MvYXJtL2RldmljZS10cmVlL2Jvb3RpbmcudHh0ICAgICAgIHwg MTAzICsrKw0KPj4gICBkb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MgICAgICAgICAg IHwgIDE5ICstDQo+PiAgIHRvb2xzL2xpYnMvbGlnaHQvbGlieGxfYXJtLmMgICAgICAgICAgICAg ICAgfCAgIDQgKw0KPj4gICB0b29scy9saWJzL2xpZ2h0L2xpYnhsX3R5cGVzLmlkbCAgICAgICAg ICAgIHwgICA0ICstDQo+PiAgIHRvb2xzL3hsL3hsX3BhcnNlLmMgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgMTIgKw0KPj4gICB4ZW4vYXJjaC9hcm0vZG9tMGxlc3MtYnVpbGQuYyAgICAgICAg ICAgICAgIHwgIDExICsNCj4+ICAgeGVuL2FyY2gvYXJtL2RvbWFpbl9idWlsZC5jICAgICAgICAg ICAgICAgICB8ICAyNiArLQ0KPj4gICB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvS2NvbmZpZyAgICAg ICAgICAgICAgIHwgIDEyICsNCj4+ICAgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL01ha2VmaWxlICAg ICAgICAgICAgICB8ICAgMSArDQo+PiAgIHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXByb3Rv LmggICAgICAgICAgfCAxNjQgKysrKw0KPj4gICB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1z aG1lbS5jICAgICAgICAgIHwgMTE1ICsrKw0KPj4gICB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2Nt aS1zaG1lbS5oICAgICAgICAgIHwgIDQ1ICsrDQo+PiAgIHhlbi9hcmNoL2FybS9maXJtd2FyZS9z Y21pLXNtYy1tdWx0aWFnZW50LmMgfCA3OTQgKysrKysrKysrKysrKysrKysrKysNCj4+ICAgeGVu L2luY2x1ZGUvcHVibGljL2FyY2gtYXJtLmggICAgICAgICAgICAgICB8ICAgMyArDQo+PiAgIDE3 IGZpbGVzIGNoYW5nZWQsIDEzMzggaW5zZXJ0aW9ucygrKSwgMyBkZWxldGlvbnMoLSkNCj4+ICAg Y3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXByb3RvLmgNCj4+ ICAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmMN Cj4+ICAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVt LmgNCj4+ICAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNt Yy1tdWx0aWFnZW50LmMNCj4+DQo+PiBkaWZmIC0tZ2l0IGEvTUFJTlRBSU5FUlMgYi9NQUlOVEFJ TkVSUw0KPj4gaW5kZXggZWNkM2Y0MGRmOC4uNGFkMWQ4MThhNiAxMDA2NDQNCj4+IC0tLSBhL01B SU5UQUlORVJTDQo+PiArKysgYi9NQUlOVEFJTkVSUw0KPj4gQEAgLTUzMiw2ICs1MzIsMTAgQEAg UjogICAgT2xla3NpaSBNb2lzaWVpZXYNCj4+IDxvbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbT4N Cj4+ICAgUzogICAgU3VwcG9ydGVkDQo+PiAgIEY6ICAgIHhlbi9hcmNoL2FybS9maXJtd2FyZS9z Y2kuYw0KPj4gICBGOiAgICB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZmlybXdhcmUvc2NpLmgN Cj4+ICtGOiAgICB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zbWMtbXVsdGlhZ2VudC5jDQo+ PiArRjogICAgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uYw0KPj4gK0Y6ICAgIHhl bi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmgNCj4+ICtGOiAgICB4ZW4vYXJjaC9hcm0v ZmlybXdhcmUvc2NtaS1wcm90by5oDQo+PiAgICAgU0VBQklPUyBVUFNUUkVBTQ0KPj4gICBNOiAg ICBXZWkgTGl1IDx3bEB4ZW4ub3JnPg0KPj4gZGlmZiAtLWdpdCBhL1NVUFBPUlQubWQgYi9TVVBQ T1JULm1kDQo+PiBpbmRleCA0OTFmOWVjZDFiLi43Yzg5NTFkNjdiIDEwMDY0NA0KPj4gLS0tIGEv U1VQUE9SVC5tZA0KPj4gKysrIGIvU1VQUE9SVC5tZA0KPj4gQEAgLTk1Niw2ICs5NTYsMTcgQEAg YnkgaHdkb20uIFNvbWUgcGxhdGZvcm1zIHVzZSBTQ01JIGZvciBhY2Nlc3MgdG8NCj4+IHN5c3Rl bS1sZXZlbCByZXNvdXJjZXMuDQo+PiAgICAgICAgIFN0YXR1czogU3VwcG9ydGVkDQo+PiAgICsj IyMgQXJtOiBTQ01JIFNNQyBtdWx0aS1hZ2VudCBzdXBwb3J0DQo+PiArDQo+PiArRW5hYmxlIHN1 cHBvcnQgZm9yIHRoZSBtdWx0aS1hZ2VudCBjb25maWd1cmF0aW9uIG9mIHRoZSBFTDMNCj4+IEZp cm13YXJlLCB3aGljaA0KPj4gK2FsbG93cyBYZW4gdG8gcHJvdmlkZSBhbiBTQ01JIGludGVyZmFj ZSB0byB0aGUgRG9tYWlucy4NCj4+ICtYZW4gbWFuYWdlcyBhY2Nlc3MgcGVybWlzc2lvbnMgdG8g dGhlIEhXIHJlc291cmNlcyBhbmQgcHJvdmlkZXMgYW4NCj4+IFNDTUkgaW50ZXJmYWNlDQo+PiAr dG8gdGhlIERvbWFpbnMuIEVhY2ggRG9tYWluIGlzIHJlcHJlc2VudGVkIGFzIGEgc2VwYXJhdGUg QWdlbnQsDQo+PiB3aGljaCBjYW4NCj4+ICtjb21tdW5pY2F0ZSB3aXRoIEVMMyBGaXJtd2FyZSB1 c2luZyBhIGRlZGljYXRlZCBzaGFyZWQgbWVtb3J5DQo+PiByZWdpb24sIGFuZA0KPj4gK25vdGlm aWNhdGlvbnMgYXJlIHBhc3NlZCB0aHJvdWdoIGJ5IFhlbi4NCj4+ICsNCj4+ICsgICAgU3RhdHVz LCBBUk02NDogVGVjaCBQcmV2aWV3DQo+PiArDQo+PiAgICMjIyBBUk06IEd1ZXN0IFBTQ0kgc3Vw cG9ydA0KPj4gICAgIEVtdWxhdGVkIFBTQ0kgaW50ZXJmYWNlIGV4cG9zZWQgdG8gZ3Vlc3RzLiBX ZSBzdXBwb3J0IGFsbCBtYW5kYXRvcnkNCj4+IGRpZmYgLS1naXQgYS9kb2NzL21hbi94bC5jZmcu NS5wb2QuaW4gYi9kb2NzL21hbi94bC5jZmcuNS5wb2QuaW4NCj4+IGluZGV4IGFkMTU1M2M1ZTku LjRmYzNlMTI5MzkgMTAwNjQ0DQo+PiAtLS0gYS9kb2NzL21hbi94bC5jZmcuNS5wb2QuaW4NCj4+ ICsrKyBiL2RvY3MvbWFuL3hsLmNmZy41LnBvZC5pbg0KPj4gQEAgLTMxNTYsOCArMzE1NiwyMSBA QCBzaW5nbGUgU0NNSSBPU1BNIGFnZW50IHN1cHBvcnQuDQo+PiAgIFNob3VsZCBiZSB1c2VkIHRv Z2V0aGVyIHdpdGggQjxzY21pLXNtYy1wYXNzdGhyb3VnaD4gWGVuIGNvbW1hbmQgbGluZQ0KPj4g ICBvcHRpb24uDQo+PiAgICs9aXRlbSBCPHNjbWlfc21jX211bHRpYWdlbnQ+DQo+PiArDQo+PiAr RW5hYmxlcyBBUk0gU0NNSSBTTUMgbXVsdGktYWdlbnQgc3VwcG9ydCBmb3IgdGhlIGd1ZXN0IGJ5 IGVuYWJsaW5nDQo+PiBTQ01JIG92ZXINCj4+ICtTTUMgY2FsbHMgZm9yd2FyZGluZyBmcm9tIGRv bWFpbiB0byB0aGUgRUwzIGZpcm13YXJlIChsaWtlIFRydXN0ZWQNCj4+IEZpcm13YXJlLUEpDQo+ PiArd2l0aCBhIG11bHRpIFNDTUkgT1NQTSBhZ2VudCBzdXBwb3J0LiBUaGUgU0NNSSBCPGFnZW50 X2lkPiBzaG91bGQgYmUNCj4+ICtzcGVjaWZpZWQgZm9yIHRoZSBndWVzdC4NCj4+ICsNCj4+ICAg PWJhY2sNCj4+ICAgKz1pdGVtIEI8YWdlbnRfaWQ9TlVNQkVSPg0KPj4gKw0KPj4gK1NwZWNpZmll cyBhIG5vbi16ZXJvIEFSTSBTQ0kgYWdlbnQgaWQgZm9yIHRoZSBndWVzdC4gVGhpcyBvcHRpb24g aXMNCj4+IG1hbmRhdG9yeQ0KPj4gK2lmIHRoZSBTQ01JIFNNQyBzdXBwb3J0IGlzIGVuYWJsZWQg Zm9yIHRoZSBndWVzdC4gVGhlIGFnZW50IGlkcyBvZg0KPj4gZG9tYWlucw0KPj4gK2V4aXN0aW5n IG9uIGEgc2luZ2xlIGhvc3QgbXVzdCBiZSB1bmlxdWUgYW5kIGluIHRoZSByYW5nZSBbMS4uMjU1 XS4NCj4+ICsNCj4+ICAgPWJhY2sNCj4gUTogW1N0ZWZhbm9dIFdoeSBpcyB0aGUgb3B0aW9uIG1h bmRhdG9yeSBpZiB0aGUgY29tbWl0IGRlc2NyaXB0aW9uDQo+IGV4cGxhaW5zIHRoYXQgdGhlDQo+ IGFnZW50X2lkIGNhbiBiZSBwcm9iZWQgYnkgWGVuPyBJbiB0aGUgY29tbWl0IG1lc3NhZ2UsIHRo ZSBtYW5kYXRvcnkNCj4gZmllbGQgaXMgc21jLWlkIGluc3RlYWQ/DQo+DQo+IEkgZ3Vlc3MgaXQg aXMgYmVjYXVzZSB3ZSBleHBlY3QgWGVuIHRvIGhhdmUgYWxyZWFkeSB0aGUgYWdlbnRfaWQtPnNt Yy1pZA0KPiBtYXBwaW5nIGFuZCB3ZSBleHBlY3QgdGhlIGFnZW50X2lkIHRvIGJlIGVhc2llciB0 byByZW1lbWJlciBhbmQgdG8gd3JpdGUNCj4gaW4gdGhlIGNvbmZpZyBmaWxlPw0KPg0KPiBBOiBb T01dIGNvcnJlY3QuIGR1cmluZyBmaXJzdCBpdGVyYXRpb25zIHdlIGRpZCBhdXRvbWF0aWMgYWdl bnRfaXMNCj4gYXNzaWdubWVudC4gQnV0IHN3aXRjaGVkIHRvIHNldHRpbmcgYWdlbnRfaWQgYmVj YXVzZSBpdCBzaW1waWZpZXMNCj4gbG9naWMgYW5kIGNvdmVycyBtb3JlIGNhc2VzIGZvciBleGFt cGxlIHdoZW4gWGVuIGRvZXNuJ3QgaGF2ZSBhbg0KPiBhY2Nlc3MgdG8gdGhlIGFnZW50IGRpc2Nv dmVyIG9yIHdoZW4gbWFpbGJveGVzIGFyZSB1c2VzLg0KPg0KPiBBbHNvLCBzbWMtaWQgaXMgcmVs YXRlZCB0byBTTUMgY2FsbCwgbm90IFNDTUkgaXRzZWxmLiBBZ2VudF9pZCBpcyBTQ01JDQo+IHRl cm0gd2hpY2ggc2VlbXMgdG8gYmUgbW9yZSBnZW5lcmljIGFuZCB3aWxsIGJlIHN1aXRhYmxlIGZv ciBhbGwNCj4gaW1wbGVtZW50YXRpb24sIHN1Y2ggYXMgbWFpbGJveGVzIG9yIG90aGVyIG1lY2hh bmlzbS4gVGhpcyBpcyBiZWNhdXNlDQo+IHdlIGNhbiBiZSBzdXJlIHRoYXQgZWFjaCBTQ01JIHNl cnZlciB3aWxsIGZvbGxvdyBTQ01JIHNwZWNpZmljYXRpb24NCj4gdGhlcmVmb3JlIGFnZW50X2lk IGVudGl0eSB3aWxsIGJlIHByZXNlbnQuDQo+DQo+PiAgICAgPWJhY2sNCj4+IGRpZmYgLS1naXQg YS9kb2NzL21pc2MvYXJtL2RldmljZS10cmVlL2Jvb3RpbmcudHh0DQo+PiBiL2RvY3MvbWlzYy9h cm0vZGV2aWNlLXRyZWUvYm9vdGluZy50eHQNCj4+IGluZGV4IDk3N2I0Mjg2MDguLjZmZDdlNGEx NmIgMTAwNjQ0DQo+PiAtLS0gYS9kb2NzL21pc2MvYXJtL2RldmljZS10cmVlL2Jvb3RpbmcudHh0 DQo+PiArKysgYi9kb2NzL21pc2MvYXJtL2RldmljZS10cmVlL2Jvb3RpbmcudHh0DQo+PiBAQCAt MzIyLDYgKzMyMiwyMCBAQCB3aXRoIHRoZSBmb2xsb3dpbmcgcHJvcGVydGllczoNCj4+ICAgICAg IFNob3VsZCBiZSB1c2VkIHRvZ2V0aGVyIHdpdGggc2NtaS1zbWMtcGFzc3Rocm91Z2ggWGVuIGNv bW1hbmQgbGluZQ0KPj4gICAgICAgb3B0aW9uLg0KPj4gICArICAgIC0gInNjbWlfc21jX211bHRp YWdlbnQiDQo+PiArDQo+PiArICAgIEVuYWJsZXMgQVJNIFNDTUkgU01DIG11bHRpLWFnZW50IHN1 cHBvcnQgZm9yIHRoZSBndWVzdCBieQ0KPj4gZW5hYmxpbmcgU0NNSSBvdmVyDQo+PiArICAgIFNN QyBjYWxscyBmb3J3YXJkaW5nIGZyb20gZG9tYWluIHRvIHRoZSBFTDMgZmlybXdhcmUgKGxpa2Ug QVJNDQo+PiArICAgIFRydXN0ZWQgRmlybXdhcmUtQSkgd2l0aCBhIG11bHRpIFNDTUkgT1NQTSBh Z2VudCBzdXBwb3J0Lg0KPj4gKyAgICBUaGUgU0NNSSBhZ2VudF9pZCBzaG91bGQgYmUgc3BlY2lm aWVkIGZvciB0aGUgZ3Vlc3Qgd2l0aA0KPj4gInhlbixzY2ktYWdlbnQtaWQiDQo+PiArICAgIHBy b3BlcnR5Lg0KPj4gKw0KPj4gKy0gInhlbixzY2ktYWdlbnQtaWQiDQo+PiArDQo+PiArICAgIFNw ZWNpZmllcyBBUk0gU0NNSSBhZ2VudCBpZCBmb3IgdGhlIGd1ZXN0LiBUaGlzIG9wdGlvbiBpcw0K Pj4gbWFuZGF0b3J5IGlmIHRoZQ0KPj4gKyAgICBTQ01JIFNNQyAic2NtaV9zbWNfbXVsdGlhZ2Vu dCIgc3VwcG9ydCBpcyBlbmFibGVkIGZvciB0aGUgZ3Vlc3QuDQo+PiBUaGUgYWdlbnQgaWRzDQo+ PiArICAgIG9mIGd1ZXN0IG11c3QgYmUgdW5pcXVlIGFuZCBpbiB0aGUgcmFuZ2UgWzAuLjI1NV0u DQo+PiArDQo+PiAgIFVuZGVyIHRoZSAieGVuLGRvbWFpbiIgY29tcGF0aWJsZSBub2RlLCBvbmUg b3IgbW9yZSBzdWItbm9kZXMgYXJlDQo+PiBwcmVzZW50DQo+PiAgIGZvciB0aGUgRG9tVSBrZXJu ZWwgYW5kIHJhbWRpc2suDQo+PiAgIEBAIC04MjQsMyArODM4LDkyIEBAIFRoZSBhdXRvbWF0aWNh bGx5IGFsbG9jYXRlZCBzdGF0aWMgc2hhcmVkDQo+PiBtZW1vcnkgd2lsbCBnZXQgbWFwcGVkIGF0 DQo+PiAgIDB4ODAwMDAwMDAgaW4gRG9tVTEgZ3Vlc3QgcGh5c2ljYWwgYWRkcmVzcyBzcGFjZSwg YW5kIGF0IDB4OTAwMDAwMDANCj4+IGluIERvbVUyDQo+PiAgIGd1ZXN0IHBoeXNpY2FsIGFkZHJl c3Mgc3BhY2UuIERvbVUxIGlzIGV4cGxpY2l0bHkgZGVmaW5lZCBhcyB0aGUNCj4+IG93bmVyIGRv bWFpbiwNCj4+ICAgYW5kIERvbVUyIGlzIHRoZSBib3Jyb3dlciBkb21haW4uDQo+PiArDQo+PiAr U0NNSSBTTUMgbXVsdGktYWdlbnQgc3VwcG9ydA0KPj4gKz09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCj4+ICsNCj4+ICtGb3IgZW5hYmxpbmcgdGhlIEFSTSBTQ01JIFNNQyBtdWx0aS1hZ2Vu dCBzdXBwb3J0IChlbmFibGVkIGJ5DQo+PiBDT05GSUdfU0NNSV9TTUNfTUEpDQo+PiArdGhlIFhl biBzcGVjaWZpYyBTQ01JIEFnZW50J3MgY29uZmlndXJhdGlvbiBzaGFsbCBiZSBwcm92aWRlZCBp biB0aGUNCj4+IEhvc3QgRFQNCj4+ICthY2NvcmRpbmcgdG8gdGhlIFNDTUkgY29tcGxpYW50IEVM MyBGaXJtd2FyZSBzcGVjaWZpY2F0aW9uIHdpdGgNCj4+ICtBUk0gU01DL0hWQyB0cmFuc3BvcnQg dXNpbmcgcHJvcGVydHkgInNjbWktc2Vjb25kYXJ5LWFnZW50cyIgcGxhY2VkDQo+PiBpbiAieGVu LGNvbmZpZyINCj4+ICtub2RlIHVuZGVyICJjaG9zZW4iIG5vZGU6DQo+PiArDQo+PiArLSBzY21p LXNlY29uZGFyeS1hZ2VudHMNCj4+ICsNCj4+ICsgICAgRGVmaW5lcyBhIHNldCBvZiBTQ01JIGFn ZW50cyBjb25maWd1cmF0aW9uIHN1cHBvcnRlZCBieSBTQ01JIEVMMw0KPj4gRlcgYW5kDQo+PiAr ICAgIGF2YWlsYWJsZSBmb3IgWGVuLiBFYWNoIEFnZW50IGRlZmluZWQgYXMgdHJpcGxlIGNvbnNp c3Rpbmcgb2Y6DQo+PiArICAgIFNNQy9IVkMgZnVuY3Rpb25faWQgYXNzaWduZWQgZm9yIHRoZSBh Z2VudCB0cmFuc3BvcnQNCj4+ICgiYXJtLHNtYy1pZCIpLA0KPj4gKyAgICBwaGFuZGxlIHRvIFND TUkgU0hNIGFzc2lnbmVkIGZvciB0aGUgYWdlbnQgdHJhbnNwb3J0DQo+PiAoImFybSxzY21pLXNo bWVtIiksDQo+PiArICAgIFNDTUkgYWdlbnRfaWQgKG9wdGlvbmFsKSBpZiBub3Qgc2V0IC0gWGVu IHdpbGwgZGV0ZXJtaW5lIEFnZW50DQo+PiBJRCBmb3INCj4+ICsgICAgZWFjaCBwcm92aWRlZCBj aGFubmVsIHVzaW5nIEJBU0VfRElTQ09WRVJfQUdFTlQgbWVzc2FnZS4NCj4+ICsNCj4+ICtBcyBh biBleGFtcGxlOg0KPj4gKw0KPj4gKy97DQo+PiArY2hvc2VuIHsNCj4+ICsgICAgeGVuLGNvbmZp ZyB7DQo+PiArICAgICAgICBzY21pX3NobV8wIDogc3JhbUA0N2ZmMDAwMCB7DQo+PiArICAgICAg ICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+PiArICAgICAgICAgICAgcmVn ID0gPDB4MCAweDQ3ZmYwMDAwIDB4MCAweDEwMDA+Ow0KPj4gKyAgICAgICAgfTsNCj4+ICsgICAg ICAgIC8vIFhlbiBTQ01JIG1hbmFnZW1lbnQgY2hhbm5lbA0KPj4gKyAgICAgICAgc2NtaV9zaG1f MTogc3JhbUA0N2ZmMTAwMCB7DQo+PiArICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJt LHNjbWktc2htZW0iOw0KPj4gKyAgICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjEwMDAg MHgwIDB4MTAwMD47DQo+PiArICAgICAgICB9Ow0KPj4gKyAgICAgICAgc2NtaV9zaG1fMjogc3Jh bUA0N2ZmMjAwMCB7DQo+PiArICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWkt c2htZW0iOw0KPj4gKyAgICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjIwMDAgMHgwIDB4 MTAwMD47DQo+PiArICAgICAgICB9Ow0KPj4gKyAgICAgICAgc2NtaV9zaG1fMzogc3JhbUA0N2Zm MzAwMCB7DQo+PiArICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0i Ow0KPj4gKyAgICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjMwMDAgMHgwIDB4MTAwMD47 DQo+PiArICAgICAgICB9Ow0KPj4gKyAgICAgICAgc2NtaV9zaG1fMzogc3JhbUA0N2ZmNDAwMCB7 DQo+PiArICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4g KyAgICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjQwMDAgMHgwIDB4MTAwMD47DQo+PiAr ICAgICAgICB9Ow0KPj4gKyAgICAgICAgc2NtaS1zZWNvbmRhcnktYWdlbnRzID0gPA0KPj4gKyAg ICAgICAgICAgIDB4ODIwMDAwMDIgJnNjbWlfc2htXzAgMA0KPj4gKyAgICAgICAgICAgIDB4ODIw MDAwMDQgJnNjbWlfc2htXzIgMg0KPj4gKyAgICAgICAgICAgIDB4ODIwMDAwMDUgJnNjbWlfc2ht XzMgMw0KPj4gKyAgICAgICAgICAgIDB4ODIwMDAwMDYgJnNjbWlfc2htXzQgND47DQo+PiArICAg ICAgICAgICAgI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxscyA9IDwzPjsNCj4+ICsgICAgICAg IH07DQo+PiArDQo+PiArICAgICAgICBzY21pX3hlbjogc2NtaSB7DQo+PiArICAgICAgICAgICAg Y29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zbWMiOw0KPj4gKyAgICAgICAgICAgIGFybSxzbWMtaWQg PSA8MHg4MjAwMDAwMj47IDwtLS0gWGVuIG1hbmFnZW1lbnQgYWdlbnQgc21jLWlkDQo+PiArICAg ICAgICAgICAgI2FkZHJlc3MtY2VsbHMgPSA8IDE+Ow0KPj4gKyAgICAgICAgICAgICNzaXplLWNl bGxzID0gPCAwPjsNCj4+ICsgICAgICAgICAgICAjYWNjZXNzLWNvbnRyb2xsZXItY2VsbHMgPSA8 IDE+Ow0KPj4gKyAgICAgICAgICAgIHNobWVtID0gPCZzY21pX3NobV8xPjsgPC0tLSBYZW4gbWFu YWdlbWVudCBhZ2VudCBzaG1lbQ0KPj4gKyAgICAgICAgfTsNCj4+ICsNCj4+ICsgICAgfTsNCj4+ ICt9Ow0KPj4gKw0KPj4gKy0gI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxscw0KPj4gKw0KPj4g KyAgICBEZWZpbmVzIHdoZXRoZXIgQWdlbnRfaWQgaXMgc2V0IGluIHRoZSAic2NtaS1zZWNvbmRh cnktYWdlbnRzIg0KPj4gcHJvcGVydHkuDQo+PiArICAgIFBvc3NpYmxlIHZhbHVlcyBhcmU6IDIs IDMuDQo+PiArICAgIFdoZW4gc2V0IHRvIDMgKHRoZSBkZWZhdWx0KSwgZXhwZWN0IGFnZW50X2lk IHRvIGJlIHByZXNlbnQgaW4NCj4+IHRoZSBzZWNvbmRhcnkNCj4+ICsgICAgYWdlbnRzIGxpc3Qu DQo+PiArICAgIFdoZW4gc2V0IHRvIDIsIGFnZW50X2lkIHdpbGwgYmUgZGlzY292ZXJlZCBmb3Ig ZWFjaCBjaGFubmVsIHVzaW5nDQo+PiArICAgIEJBU0VfRElTQ09WRVJfQUdFTlQgbWVzc2FnZS4N Cj4+ICsNCj4+ICsNCj4+ICtFeGFtcGxlOg0KPj4gKw0KPj4gKy97DQo+PiArY2hvc2VuIHsNCj4+ ICsgICAgeGVuLGNvbmZpZyB7DQo+PiArICAgICAgICBzY21pLXNlY29uZGFyeS1hZ2VudHMgPSA8 DQo+PiArICAgICAgICAgICAgMHg4MjAwMDAwMyAmc2NtaV9zaG1fMQ0KPj4gKyAgICAgICAgICAg IDB4ODIwMDAwMDQgJnNjbWlfc2htXzINCj4+ICsgICAgICAgICAgICAweDgyMDAwMDA1ICZzY21p X3NobV8zDQo+PiArICAgICAgICAgICAgMHg4MjAwMDAwNiAmc2NtaV9zaG1fND47DQo+PiArICAg ICAgICAgICAgI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxscyA9IDwyPjsNCj4+ICsgICAgICAg IH07DQo+PiArICAgIH07DQo+PiArfTsNCj4+IGRpZmYgLS1naXQgYS9kb2NzL21pc2MveGVuLWNv bW1hbmQtbGluZS5wYW5kb2MNCj4+IGIvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9j DQo+PiBpbmRleCAzNDAwNGNlMjgyLi41NTQxYzRhNGVkIDEwMDY0NA0KPj4gLS0tIGEvZG9jcy9t aXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jDQo+PiArKysgYi9kb2NzL21pc2MveGVuLWNvbW1h bmQtbGluZS5wYW5kb2MNCj4+IEBAIC04MzUsNyArODM1LDcgQEAgU3BlY2lmeSB0aGUgYml0IHdp ZHRoIG9mIHRoZSBETUEgaGVhcC4NCj4+ICAgICAgICAgICAgICAgICAgIGNwdWlkLWZhdWx0aW5n PTxib29sPiwgbXNyLXJlbGF4ZWQ9PGJvb2w+LA0KPj4gICAgICAgICAgICAgICAgICAgcGYtZml4 dXA9PGJvb2w+IF0gKHg4NikNCj4+ICAgLSAgICA9IExpc3Qgb2YgWyBzdmU9PGludGVnZXI+IF0g KEFybTY0KQ0KPj4gKyAgICA9IExpc3Qgb2YgWyBzdmU9PGludGVnZXI+LCBzY2ktYWdlbnQtaWQ9 PGludGVnZXI+IF0gKEFybSkNCj4+ICAgICBDb250cm9scyBmb3IgaG93IGRvbTAgaXMgY29uc3Ry dWN0ZWQgb24geDg2IHN5c3RlbXMuDQo+PiAgIEBAIC05MjMsNiArOTIzLDE0IEBAIEVuYWJsZXMg ZmVhdHVyZXMgb24gZG9tMCBvbiBBcm0gc3lzdGVtcy4NCj4+ICAgICAgIG9wdGlvbiBpcyBwcm92 aWRlZCB3aXRoIGEgcG9zaXRpdmUgbm9uIHplcm8gdmFsdWUsIGJ1dCB0aGUNCj4+IHBsYXRmb3Jt IGRvZXNuJ3QNCj4+ICAgICAgIHN1cHBvcnQgU1ZFLg0KPj4gICArKiAgIFRoZSBgc2NpLWFnZW50 LWlkYCBpbnRlZ2VyIHBhcmFtZXRlciBlbmFibGVzIEFSTSBTQ01JIChTeXN0ZW0NCj4+IENvbnRy b2wgYW5kDQo+PiArICAgIE1hbmFnZW1lbnQgSW50ZXJmYWNlKSBmdW5jdGlvbmFsaXR5IGZvciBE b20wIHdoZW4NCj4+IGBDT05GSUdfU0NNSV9TTUNfTUFgIGlzDQo+PiArICAgIGNvbXBpbGVkIGlu LiBUaGlzIHBhcmFtZXRlciBzcGVjaWZpZXMgdGhlIFNDTUkgYWdlbnQgSUQgZm9yIERvbTAuDQo+ PiArICAgIEEgdmFsdWUgZXF1YWwgdG8gMHhGRiAob3Igb21pdHRlZCkgZGlzYWJsZXMgU0NNSSBm b3IgRG9tMCwgd2hpY2gNCj4+IGlzIHVzZWZ1bA0KPj4gKyAgICBmb3IgdGhpbiBEb20wIG9yIGRv bTBsZXNzIHVzZS1jYXNlcy4gVmFsdWVzIGZyb20gMCB0byAyNTQNCj4+IHNwZWNpZnkgdGhlIFND TUkNCj4+ICsgICAgYWdlbnQgSUQuIFRoZSBhZ2VudCBJRHMgb2YgZG9tYWlucyBleGlzdGluZyBv biBhIHNpbmdsZSBob3N0DQo+PiBtdXN0IGJlIHVuaXF1ZS4NCj4+ICsgICAgRXhhbXBsZTogYGRv bTA9c2NpLWFnZW50LWlkPTBgIHRvIGVuYWJsZSBTQ01JIHdpdGggYWdlbnQgSUQgMA0KPj4gZm9y IERvbTAuDQo+PiArDQo+PiAgICMjIyBkb20wLWNwdWlkDQo+PiAgICAgICA9IExpc3Qgb2YgY29t bWEgc2VwYXJhdGVkIGJvb2xlYW5zDQo+PiAgIEBAIC0xMTA3LDYgKzExMTUsMTUgQEAgYWZmaW5p dGllcyB0byBwcmVmZXIgYnV0IGJlIG5vdCBsaW1pdGVkIHRvDQo+PiB0aGUgc3BlY2lmaWVkIG5v ZGUocykuDQo+PiAgICAgUGluIGRvbTAgdmNwdXMgdG8gdGhlaXIgcmVzcGVjdGl2ZSBwY3B1cw0K Pj4gICArIyMjIHNjbWktc21jLXBhc3N0aHJvdWdoIChBUk0pDQo+PiArPiBgPSA8Ym9vbGVhbj5g DQo+PiArDQo+PiArVGhlIG9wdGlvbiBpcyBhdmFpbGFibGUgd2hlbiBgQ09ORklHX1NDTUlfU01D YCBpcyBjb21waWxlZCBpbiwgYW5kDQo+PiBhbGxvd3MgdG8NCj4+ICtlbmFibGUgU0NNSSBTTUMg c2luZ2xlIGFnZW50IGludGVyZmFjZSBmb3IgYW55LCBidXQgb25seSBvbmUgZ3Vlc3QNCj4+IGRv bWFpbiwNCj4+ICt3aGljaCBzZXJ2ZXMgYXMgRHJpdmVyIGRvbWFpbi4gVGhlIFNDTUkgd2lsbCBi ZSBkaXNhYmxlZCBmb3INCj4+IERvbTAvaHdkb20gYW5kDQo+PiArU0NNSSBub2RlcyByZW1vdmVk IGZyb20gRG9tMC9od2RvbSBkZXZpY2UgdHJlZS4NCj4+ICsoZm9yIGV4YW1wbGUsIHRoaW4gRG9t MCB3aXRoIERyaXZlciBkb21haW4gdXNlLWNhc2UpLg0KPj4gKw0KPj4gICAjIyMgZHR1YXJ0IChB Uk0pDQo+PiAgID4gYD0gcGF0aCBbOm9wdGlvbnNdYA0KPj4gICBkaWZmIC0tZ2l0IGEvdG9vbHMv bGlicy9saWdodC9saWJ4bF9hcm0uYw0KPj4gYi90b29scy9saWJzL2xpZ2h0L2xpYnhsX2FybS5j DQo+PiBpbmRleCBlNDQwN2Q2ZTNmLi5iZTBlNjI2M2FlIDEwMDY0NA0KPj4gLS0tIGEvdG9vbHMv bGlicy9saWdodC9saWJ4bF9hcm0uYw0KPj4gKysrIGIvdG9vbHMvbGlicy9saWdodC9saWJ4bF9h cm0uYw0KPj4gQEAgLTI0MCw2ICsyNDAsMTAgQEAgaW50IGxpYnhsX19hcmNoX2RvbWFpbl9wcmVw YXJlX2NvbmZpZyhsaWJ4bF9fZ2MNCj4+ICpnYywNCj4+ICAgICAgIGNhc2UgTElCWExfQVJNX1ND SV9UWVBFX1NDTUlfU01DOg0KPj4gICAgICAgICAgIGNvbmZpZy0+YXJjaC5hcm1fc2NpX3R5cGUg PQ0KPj4gWEVOX0RPTUNUTF9DT05GSUdfQVJNX1NDSV9TQ01JX1NNQzsNCj4+ICAgICAgICAgICBi cmVhazsNCj4+ICsgICAgY2FzZSBMSUJYTF9BUk1fU0NJX1RZUEVfU0NNSV9TTUNfTVVMVElBR0VO VDoNCj4+ICsgICAgICAgIGNvbmZpZy0+YXJjaC5hcm1fc2NpX3R5cGUgPQ0KPj4gWEVOX0RPTUNU TF9DT05GSUdfQVJNX1NDSV9TQ01JX1NNQ19NQTsNCj4+ICsgICAgICAgIGNvbmZpZy0+YXJjaC5h cm1fc2NpX2FnZW50X2lkID0NCj4+IGRfY29uZmlnLT5iX2luZm8uYXJjaF9hcm0uYXJtX3NjaS5h Z2VudF9pZDsNCj4+ICsgICAgICAgIGJyZWFrOw0KPj4gICAgICAgZGVmYXVsdDoNCj4+ICAgICAg ICAgICBMT0coRVJST1IsICJVbmtub3duIEFSTV9TQ0kgdHlwZSAlZCIsDQo+PiAgICAgICAgICAg ICAgIGRfY29uZmlnLT5iX2luZm8uYXJjaF9hcm0uYXJtX3NjaS50eXBlKTsNCj4+IGRpZmYgLS1n aXQgYS90b29scy9saWJzL2xpZ2h0L2xpYnhsX3R5cGVzLmlkbA0KPj4gYi90b29scy9saWJzL2xp Z2h0L2xpYnhsX3R5cGVzLmlkbA0KPj4gaW5kZXggNGE5NThmNjlmNC4uOWJmYmYwOTE0NSAxMDA2 NDQNCj4+IC0tLSBhL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfdHlwZXMuaWRsDQo+PiArKysgYi90 b29scy9saWJzL2xpZ2h0L2xpYnhsX3R5cGVzLmlkbA0KPj4gQEAgLTU1NCwxMSArNTU0LDEzIEBA IGxpYnhsX3N2ZV90eXBlID0gRW51bWVyYXRpb24oInN2ZV90eXBlIiwgWw0KPj4gICAgIGxpYnhs X2FybV9zY2lfdHlwZSA9IEVudW1lcmF0aW9uKCJhcm1fc2NpX3R5cGUiLCBbDQo+PiAgICAgICAo MCwgIm5vbmUiKSwNCj4+IC0gICAgKDEsICJzY21pX3NtYyIpDQo+PiArICAgICgxLCAic2NtaV9z bWMiKSwNCj4+ICsgICAgKDIsICJzY21pX3NtY19tdWx0aWFnZW50IikNCj4+ICAgICAgIF0sIGlu aXRfdmFsID0gIkxJQlhMX0FSTV9TQ0lfVFlQRV9OT05FIikNCj4+ICAgICBsaWJ4bF9hcm1fc2Np ID0gU3RydWN0KCJhcm1fc2NpIiwgWw0KPj4gICAgICAgKCJ0eXBlIiwgbGlieGxfYXJtX3NjaV90 eXBlKSwNCj4+ICsgICAgKCJhZ2VudF9pZCIsIHVpbnQ4KQ0KPj4gICAgICAgXSkNCj4+ICAgICBs aWJ4bF9yZG1fcmVzZXJ2ZSA9IFN0cnVjdCgicmRtX3Jlc2VydmUiLCBbDQo+PiBkaWZmIC0tZ2l0 IGEvdG9vbHMveGwveGxfcGFyc2UuYyBiL3Rvb2xzL3hsL3hsX3BhcnNlLmMNCj4+IGluZGV4IDFj YzQxZjFiZmYuLjBjMzg5ZDI1ZjkgMTAwNjQ0DQo+PiAtLS0gYS90b29scy94bC94bF9wYXJzZS5j DQo+PiArKysgYi90b29scy94bC94bF9wYXJzZS5jDQo+PiBAQCAtMTMwNiw2ICsxMzA2LDE4IEBA IHN0YXRpYyBpbnQgcGFyc2VfYXJtX3NjaV9jb25maWcoWExVX0NvbmZpZw0KPj4gKmNmZywgbGli eGxfYXJtX3NjaSAqYXJtX3NjaSwNCj4+ICAgICAgICAgICAgICAgfQ0KPj4gICAgICAgICAgIH0N Cj4+ICAgKyAgICAgICAgaWYgKE1BVENIX09QVElPTigiYWdlbnRfaWQiLCBwdHIsIG9wYXJnKSkg ew0KPj4gKyAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgdmFsID0gcGFyc2VfdWxvbmcob3Bhcmcp Ow0KPj4gKw0KPj4gKyAgICAgICAgICAgIGlmICghdmFsIHx8IHZhbCA+IDI1NSkgew0KPj4gKyAg ICAgICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIkFuIGludmFsaWQgQVJNX1NDSSBhZ2VudF9p ZA0KPj4gc3BlY2lmaWVkICglbHUpLiBWYWxpZCByYW5nZSBbMS4uMjU1XVxuIiwNCj4+ICsgICAg ICAgICAgICAgICAgICAgICAgICB2YWwpOw0KPj4gKyAgICAgICAgICAgICAgICByZXQgPSBFUlJP Ul9JTlZBTDsNCj4+ICsgICAgICAgICAgICAgICAgZ290byBvdXQ7DQo+PiArICAgICAgICAgICAg fQ0KPj4gKyAgICAgICAgICAgIGFybV9zY2ktPmFnZW50X2lkID0gdmFsOw0KPj4gKyAgICAgICAg fQ0KPj4gKw0KPj4gICAgICAgICAgIHB0ciA9IHN0cnRvayhOVUxMLCAiLCIpOw0KPj4gICAgICAg fQ0KPj4gICBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2RvbTBsZXNzLWJ1aWxkLmMNCj4+IGIv eGVuL2FyY2gvYXJtL2RvbTBsZXNzLWJ1aWxkLmMNCj4+IGluZGV4IDQxODFjMTA1MzguLmRkYWRj ODkxNDggMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vZG9tMGxlc3MtYnVpbGQuYw0KPj4g KysrIGIveGVuL2FyY2gvYXJtL2RvbTBsZXNzLWJ1aWxkLmMNCj4+IEBAIC0yOTksNiArMjk5LDE3 IEBAIHN0YXRpYyBpbnQgX19pbml0IGRvbXVfZHRfc2NpX3BhcnNlKHN0cnVjdA0KPj4gZHRfZGV2 aWNlX25vZGUgKm5vZGUsDQo+PiAgICAgICAgICAgZF9jZmctPmFyY2guYXJtX3NjaV90eXBlID0g WEVOX0RPTUNUTF9DT05GSUdfQVJNX1NDSV9OT05FOw0KPj4gICAgICAgZWxzZSBpZiAoICFzdHJj bXAoc2NpX3R5cGUsICJzY21pX3NtYyIpICkNCj4+ICAgICAgICAgICBkX2NmZy0+YXJjaC5hcm1f c2NpX3R5cGUgPSBYRU5fRE9NQ1RMX0NPTkZJR19BUk1fU0NJX1NDTUlfU01DOw0KPj4gKyAgICBl bHNlIGlmICggIXN0cmNtcChzY2lfdHlwZSwgInNjbWlfc21jX211bHRpYWdlbnQiKSApDQo+PiAr ICAgIHsNCj4+ICsgICAgICAgIHVpbnQzMl90IGFnZW50X2lkID0gMDsNCj4+ICsNCj4+ICsgICAg ICAgIGlmICggIWR0X3Byb3BlcnR5X3JlYWRfdTMyKG5vZGUsICJ4ZW4sc2NpLWFnZW50LWlkIiwN Cj4+ICZhZ2VudF9pZCkgfHwNCj4+ICsgICAgICAgICAgICAgYWdlbnRfaWQgPiBVSU5UOF9NQVgg KQ0KPj4gKyAgICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gKw0KPj4gKyAgICAgICAgZF9j ZmctPmFyY2guYXJtX3NjaV90eXBlID0NCj4+IFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfU0NN SV9TTUNfTUE7DQo+PiArICAgICAgICBkX2NmZy0+YXJjaC5hcm1fc2NpX2FnZW50X2lkID0gYWdl bnRfaWQ7DQo+PiArICAgIH0NCj4+ICAgICAgIGVsc2UNCj4+ICAgICAgIHsNCj4+ICAgICAgICAg ICBwcmludGsoWEVOTE9HX0VSUiAieGVuLHNjaV90eXBlIGluIG5vdCB2YWxpZCAoJXMpIGZvcg0K Pj4gZG9tYWluICVzXG4iLA0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9kb21haW5fYnVp bGQuYyBiL3hlbi9hcmNoL2FybS9kb21haW5fYnVpbGQuYw0KPj4gaW5kZXggZmI4ZmJiMTY1MC4u Nzk0ZWExYWE0MiAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS9kb21haW5fYnVpbGQuYw0K Pj4gKysrIGIveGVuL2FyY2gvYXJtL2RvbWFpbl9idWlsZC5jDQo+PiBAQCAtNTUsNiArNTUsMTAg QEAgYm9vbGVhbl9wYXJhbSgiZXh0X3JlZ2lvbnMiLCBvcHRfZXh0X3JlZ2lvbnMpOw0KPj4gICBz dGF0aWMgdTY0IF9faW5pdGRhdGEgZG9tMF9tZW07DQo+PiAgIHN0YXRpYyBib29sIF9faW5pdGRh dGEgZG9tMF9tZW1fc2V0Ow0KPj4gICArLyogU0NNSSBhZ2VudCBJRCBmb3IgZG9tMCwgcGFyc2Vk IGZyb20gZG9tMD1zY2ktYWdlbnQtaWQ9PHZhbHVlPiAqLw0KPj4gKyNkZWZpbmUgU0NNSV9BR0VO VF9JRF9JTlZBTElEIDB4RkYNCj4+ICtzdGF0aWMgdWludDhfdCBfX2luaXRkYXRhIG9wdF9kb20w X3NjbWlfYWdlbnRfaWQgPQ0KPj4gU0NNSV9BR0VOVF9JRF9JTlZBTElEOw0KPj4gKw0KPj4gICBz dGF0aWMgaW50IF9faW5pdCBwYXJzZV9kb20wX21lbShjb25zdCBjaGFyICpzKQ0KPj4gICB7DQo+ PiAgICAgICBkb20wX21lbV9zZXQgPSB0cnVlOw0KPj4gQEAgLTgzLDYgKzg3LDE2IEBAIGludCBf X2luaXQgcGFyc2VfYXJjaF9kb20wX3BhcmFtKGNvbnN0IGNoYXIgKnMsDQo+PiBjb25zdCBjaGFy ICplKQ0KPj4gICAjZW5kaWYNCj4+ICAgICAgIH0NCj4+ICAgKyAgICBpZiAoICFwYXJzZV9zaWdu ZWRfaW50ZWdlcigic2NpLWFnZW50LWlkIiwgcywgZSwgJnZhbCkgKQ0KPj4gKyAgICB7DQo+PiAr ICAgICAgICBpZiAoICh2YWwgPj0gMCkgJiYgKHZhbCA8PSBVSU5UOF9NQVgpICkNCj4+ICsgICAg ICAgICAgICBvcHRfZG9tMF9zY21pX2FnZW50X2lkID0gdmFsOw0KPj4gKyAgICAgICAgZWxzZQ0K Pj4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfSU5GTyAiJ3NjaS1hZ2VudC1pZD0lbGxkJyB2 YWx1ZSBvdXQgb2YNCj4+IHJhbmdlIVxuIiwgdmFsKTsNCj4+ICsNCj4+ICsgICAgICAgIHJldHVy biAwOw0KPj4gKyAgICB9DQo+PiArDQo+PiAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICAgfQ0K Pj4gICBAQCAtNTA5LDcgKzUyMyw4IEBAIHN0YXRpYyBpbnQgX19pbml0IHdyaXRlX3Byb3BlcnRp ZXMoc3RydWN0DQo+PiBkb21haW4gKmQsIHN0cnVjdCBrZXJuZWxfaW5mbyAqa2luZm8sDQo+PiAg ICAgICAgICAgICAgICAgICAgZHRfcHJvcGVydHlfbmFtZV9pc19lcXVhbChwcm9wLA0KPj4gImxp bnV4LHVlZmktbW1hcC1zdGFydCIpIHx8DQo+PiAgICAgICAgICAgICAgICAgICAgZHRfcHJvcGVy dHlfbmFtZV9pc19lcXVhbChwcm9wLA0KPj4gImxpbnV4LHVlZmktbW1hcC1zaXplIikgfHwNCj4+ ICAgICAgICAgICAgICAgICAgICBkdF9wcm9wZXJ0eV9uYW1lX2lzX2VxdWFsKHByb3AsDQo+PiAi bGludXgsdWVmaS1tbWFwLWRlc2Mtc2l6ZSIpIHx8DQo+PiAtICAgICAgICAgICAgICAgICBkdF9w cm9wZXJ0eV9uYW1lX2lzX2VxdWFsKHByb3AsDQo+PiAibGludXgsdWVmaS1tbWFwLWRlc2MtdmVy IikpDQo+PiArICAgICAgICAgICAgICAgICBkdF9wcm9wZXJ0eV9uYW1lX2lzX2VxdWFsKHByb3As DQo+PiAibGludXgsdWVmaS1tbWFwLWRlc2MtdmVyIikgfHwNCj4+ICsgICAgICAgICAgICAgICAg IGR0X3Byb3BlcnR5X25hbWVfaXNfZXF1YWwocHJvcCwgInhlbixjb25maWciKSApDQo+PiAgICAg ICAgICAgICAgICAgICBjb250aW51ZTsNCj4+ICAgICAgICAgICAgICAgICBpZiAoIGR0X3Byb3Bl cnR5X25hbWVfaXNfZXF1YWwocHJvcCwNCj4+ICJ4ZW4sZG9tMC1ib290YXJncyIpICkNCj4+IEBA IC0yMDY3LDYgKzIwODIsMTUgQEAgdm9pZCBfX2luaXQgY3JlYXRlX2RvbTAodm9pZCkNCj4+ICAg ICAgIGRvbTBfY2ZnLmFyY2gudGVlX3R5cGUgPSB0ZWVfZ2V0X3R5cGUoKTsNCj4+ICAgICAgIGRv bTBfY2ZnLm1heF92Y3B1cyA9IGRvbTBfbWF4X3ZjcHVzKCk7DQo+PiAgICsgICAgLyogU2V0IHVw IFNDTUkgYWdlbnQgSUQgaWYgc3BlY2lmaWVkIGluIGRvbTA9IGNvbW1hbmQgbGluZSAqLw0KPj4g KyAgICBpZiAoIG9wdF9kb20wX3NjbWlfYWdlbnRfaWQgIT0gU0NNSV9BR0VOVF9JRF9JTlZBTElE ICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgZG9tMF9jZmcuYXJjaC5hcm1fc2NpX3R5cGUgPQ0K Pj4gWEVOX0RPTUNUTF9DT05GSUdfQVJNX1NDSV9TQ01JX1NNQ19NQTsNCj4+ICsgICAgICAgIGRv bTBfY2ZnLmFyY2guYXJtX3NjaV9hZ2VudF9pZCA9IG9wdF9kb20wX3NjbWlfYWdlbnRfaWQ7DQo+ PiArICAgIH0NCj4+ICsgICAgZWxzZQ0KPj4gKyAgICAgICAgZG9tMF9jZmcuYXJjaC5hcm1fc2Np X3R5cGUgPSBYRU5fRE9NQ1RMX0NPTkZJR19BUk1fU0NJX05PTkU7DQo+PiArDQo+PiAgICAgICBp ZiAoIGlvbW11X2VuYWJsZWQgKQ0KPj4gICAgICAgICAgIGRvbTBfY2ZnLmZsYWdzIHw9IFhFTl9E T01DVExfQ0RGX2lvbW11Ow0KPj4gICBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2Zpcm13YXJl L0tjb25maWcNCj4+IGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL0tjb25maWcNCj4+IGluZGV4IDVj NWYwODgwYzQuLjk3MmNkOWIxNzMgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vZmlybXdh cmUvS2NvbmZpZw0KPj4gKysrIGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL0tjb25maWcNCj4+IEBA IC0yOSw2ICsyOSwxOCBAQCBjb25maWcgU0NNSV9TTUMNCj4+ICAgICAgICAgZHJpdmVyIGRvbWFp bi4NCj4+ICAgICAgICAgVXNlIHdpdGggRUwzIGZpcm13YXJlIHdoaWNoIHN1cHBvcnRzIG9ubHkg c2luZ2xlIFNDTUkgT1NQTQ0KPj4gYWdlbnQuDQo+PiAgICtjb25maWcgU0NNSV9TTUNfTUENCj4+ ICsgICAgYm9vbCAiRW5hYmxlIEFSTSBTQ01JIFNNQyBtdWx0aS1hZ2VudCBkcml2ZXIiDQo+PiAr ICAgIGRlcGVuZHMgb24gQVJNXzY0DQo+PiArICAgIHNlbGVjdCBBUk1fU0NJDQo+PiArICAgIGhl bHANCj4+ICsgICAgICBFbmFibGVzIFNDTUkgU01DL0hWQyBtdWx0aS1hZ2VudCBpbiBYRU4gdG8g cGFzcyBTQ01JIHJlcXVlc3RzDQo+PiBmcm9tIERvbWFpbnMNCj4+ICsgICAgICB0byBFTDMgZmly bXdhcmUgKFRGLUEpIHdoaWNoIHN1cHBvcnRzIG11bHRpLWFnZW50IGZlYXR1cmUuDQo+PiArICAg ICAgVGhpcyBmZWF0dXJlIGFsbG93cyB0byBlbmFibGUgU0NNSSBwZXIgRG9tYWluIHVzaW5nIHVu aXF1ZQ0KPj4gU0NNSSBhZ2VudF9pZCwNCj4+ICsgICAgICBzbyBEb21haW4gaXMgaWRlbnRpZmll ZCBieSBFTDMgZmlybXdhcmUgYXMgYW4gU0NNSSBBZ2VudCBhbmQNCj4+IGNhbiBhY2Nlc3MNCj4+ ICsgICAgICBhbGxvd2VkIHBsYXRmb3JtIHJlc291cmNlcyB0aHJvdWdoIGRlZGljYXRlZCBTTUMv SFZDIFNoYXJlZA0KPj4gbWVtb3J5IGJhc2VkDQo+PiArICAgICAgdHJhbnNwb3J0Lg0KPj4gKw0K Pj4gICBlbmRjaG9pY2UNCj4+ICAgICBlbmRtZW51DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gv YXJtL2Zpcm13YXJlL01ha2VmaWxlDQo+PiBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9NYWtlZmls ZQ0KPj4gaW5kZXggNzFiZGVmYzI0YS4uMzc5MjdlNjkwZSAxMDA2NDQNCj4+IC0tLSBhL3hlbi9h cmNoL2FybS9maXJtd2FyZS9NYWtlZmlsZQ0KPj4gKysrIGIveGVuL2FyY2gvYXJtL2Zpcm13YXJl L01ha2VmaWxlDQo+PiBAQCAtMSwyICsxLDMgQEANCj4+ICAgb2JqLSQoQ09ORklHX0FSTV9TQ0kp ICs9IHNjaS5vDQo+PiAgIG9iai0kKENPTkZJR19TQ01JX1NNQykgKz0gc2NtaS1zbWMubw0KPj4g K29iai0kKENPTkZJR19TQ01JX1NNQ19NQSkgKz0gc2NtaS1zaG1lbS5vIHNjbWktc21jLW11bHRp YWdlbnQubw0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXByb3Rv LmgNCj4+IGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktcHJvdG8uaA0KPj4gbmV3IGZpbGUg bW9kZSAxMDA2NDQNCj4+IGluZGV4IDAwMDAwMDAwMDAuLjQ5ZjYzY2ZjMGENCj4+IC0tLSAvZGV2 L251bGwNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXByb3RvLmgNCj4+IEBA IC0wLDAgKzEsMTY0IEBADQo+PiArLyogU1BEWC1MaWNlbnNlLUlkZW50aWZpZXI6IEdQTC0yLjAt b25seSAqLw0KPj4gKy8qDQo+PiArICogQXJtIFN5c3RlbSBDb250cm9sIGFuZCBNYW5hZ2VtZW50 IEludGVyZmFjZSBkZWZpbml0aW9ucw0KPj4gKyAqIFZlcnNpb24gMy4wIChERU4wMDU2QykNCj4+ ICsgKg0KPj4gKyAqIENvcHlyaWdodCAoYykgMjAyNSBFUEFNIFN5c3RlbXMNCj4+ICsgKi8NCj4+ ICsNCj4+ICsjaWZuZGVmIEFSTV9GSVJNV0FSRV9TQ01JX1BST1RPX0hfDQo+PiArI2RlZmluZSBB Uk1fRklSTVdBUkVfU0NNSV9QUk9UT19IXw0KPj4gKw0KPj4gKyNpbmNsdWRlIDx4ZW4vc3RkaW50 Lmg+DQo+PiArDQo+PiArI2RlZmluZSBTQ01JX1NIT1JUX05BTUVfTUFYX1NJWkUgMTYNCj4+ICsN Cj4+ICsvKiBTQ01JIHN0YXR1cyBjb2Rlcy4gU2VlIHNlY3Rpb24gNC4xLjQgKi8NCj4+ICsjZGVm aW5lIFNDTUlfU1VDQ0VTUyAgICAgICAgICAgICAgMA0KPj4gKyNkZWZpbmUgU0NNSV9OT1RfU1VQ UE9SVEVEICAgICAgKC0xKQ0KPj4gKyNkZWZpbmUgU0NNSV9JTlZBTElEX1BBUkFNRVRFUlMgKC0y KQ0KPj4gKyNkZWZpbmUgU0NNSV9ERU5JRUQgICAgICAgICAgICAgKC0zKQ0KPj4gKyNkZWZpbmUg U0NNSV9OT1RfRk9VTkQgICAgICAgICAgKC00KQ0KPj4gKyNkZWZpbmUgU0NNSV9PVVRfT0ZfUkFO R0UgICAgICAgKC01KQ0KPj4gKyNkZWZpbmUgU0NNSV9CVVNZICAgICAgICAgICAgICAgKC02KQ0K Pj4gKyNkZWZpbmUgU0NNSV9DT01NU19FUlJPUiAgICAgICAgKC03KQ0KPj4gKyNkZWZpbmUgU0NN SV9HRU5FUklDX0VSUk9SICAgICAgKC04KQ0KPj4gKyNkZWZpbmUgU0NNSV9IQVJEV0FSRV9FUlJP UiAgICAgKC05KQ0KPj4gKyNkZWZpbmUgU0NNSV9QUk9UT0NPTF9FUlJPUiAgICAgKC0xMCkNCj4+ ICsNCj4+ICsvKiBQcm90b2NvbCBJRHMgKi8NCj4+ICsjZGVmaW5lIFNDTUlfQkFTRV9QUk9UT0NP TCAweDEwDQo+PiArDQo+PiArLyogQmFzZSBwcm90b2NvbCBtZXNzYWdlIElEcyAqLw0KPj4gKyNk ZWZpbmUgU0NNSV9CQVNFX1BST1RPQ09MX1ZFUlNJT04gICAgICAgICAgICAweDANCj4+ICsjZGVm aW5lIFNDTUlfQkFTRV9QUk9UT0NPTF9BVFRJQlVURVMgICAgICAgICAgMHgxDQo+PiArI2RlZmlu ZSBTQ01JX0JBU0VfUFJPVE9DT0xfTUVTU0FHRV9BVFRSSUJVVEVTIDB4Mg0KPj4gKyNkZWZpbmUg U0NNSV9CQVNFX0RJU0NPVkVSX0FHRU5UICAgICAgICAgICAgICAweDcNCj4+ICsjZGVmaW5lIFND TUlfQkFTRV9TRVRfREVWSUNFX1BFUk1JU1NJT05TICAgICAgMHg5DQo+PiArI2RlZmluZSBTQ01J X0JBU0VfUkVTRVRfQUdFTlRfQ09ORklHVVJBVElPTiAgIDB4Qg0KPj4gKw0KPj4gK3R5cGVkZWYg c3RydWN0IHNjbWlfbXNnX2hlYWRlciB7DQo+PiArICAgIHVpbnQ4X3QgaWQ7DQo+PiArICAgIHVp bnQ4X3QgdHlwZTsNCj4+ICsgICAgdWludDhfdCBwcm90b2NvbDsNCj4+ICsgICAgdWludDMyX3Qg c3RhdHVzOw0KPj4gK30gc2NtaV9tc2dfaGVhZGVyX3Q7DQo+PiArDQo+PiArLyogVGFibGUgMiBN ZXNzYWdlIGhlYWRlciBmb3JtYXQgKi8NCj4+ICsjZGVmaW5lIFNDTUlfSERSX0lEICAgIEdFTk1B U0soNywgMCkNCj4+ICsjZGVmaW5lIFNDTUlfSERSX1RZUEUgIEdFTk1BU0soOSwgOCkNCj4+ICsj ZGVmaW5lIFNDTUlfSERSX1BST1RPIEdFTk1BU0soMTcsIDEwKQ0KPj4gKw0KPj4gKyNkZWZpbmUg U0NNSV9GSUVMRF9HRVQoX21hc2ssDQo+PiBfcmVnKSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgXA0KPj4gKyAgICAoKHR5cGVvZihfbWFzaykpKCgoX3JlZykgJiAo X21hc2spKSA+PiAoZmZzNjQoX21hc2spIC0gMSkpKQ0KPj4gKyNkZWZpbmUgU0NNSV9GSUVMRF9Q UkVQKF9tYXNrLA0KPj4gX3ZhbCkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgXA0KPj4gKyAgICAoKCh0eXBlb2YoX21hc2spKShfdmFsKSA8PCAoZmZzNjQoX21hc2sp IC0gMSkpICYgKF9tYXNrKSkNCj4+ICsNCj4+ICtzdGF0aWMgaW5saW5lIHVpbnQzMl90IHBhY2tf c2NtaV9oZWFkZXIoc2NtaV9tc2dfaGVhZGVyX3QgKmhkcikNCj4+ICt7DQo+PiArICAgIHJldHVy biBTQ01JX0ZJRUxEX1BSRVAoU0NNSV9IRFJfSUQsIGhkci0+aWQpIHwNCj4+ICsgICAgICAgICAg IFNDTUlfRklFTERfUFJFUChTQ01JX0hEUl9UWVBFLCBoZHItPnR5cGUpIHwNCj4+ICsgICAgICAg ICAgIFNDTUlfRklFTERfUFJFUChTQ01JX0hEUl9QUk9UTywgaGRyLT5wcm90b2NvbCk7DQo+PiAr fQ0KPj4gKw0KPj4gK3N0YXRpYyBpbmxpbmUgdm9pZCB1bnBhY2tfc2NtaV9oZWFkZXIodWludDMy X3QgbXNnX2hkciwNCj4+IHNjbWlfbXNnX2hlYWRlcl90ICpoZHIpDQo+PiArew0KPj4gKyAgICBo ZHItPmlkID0gU0NNSV9GSUVMRF9HRVQoU0NNSV9IRFJfSUQsIG1zZ19oZHIpOw0KPj4gKyAgICBo ZHItPnR5cGUgPSBTQ01JX0ZJRUxEX0dFVChTQ01JX0hEUl9UWVBFLCBtc2dfaGRyKTsNCj4+ICsg ICAgaGRyLT5wcm90b2NvbCA9IFNDTUlfRklFTERfR0VUKFNDTUlfSERSX1BST1RPLCBtc2dfaGRy KTsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIGlubGluZSBpbnQgc2NtaV90b194ZW5fZXJybm8o aW50IHNjbWlfc3RhdHVzKQ0KPj4gK3sNCj4+ICsgICAgaWYgKCBzY21pX3N0YXR1cyA9PSBTQ01J X1NVQ0NFU1MgKQ0KPj4gKyAgICAgICAgcmV0dXJuIDA7DQo+PiArDQo+PiArICAgIHN3aXRjaCAo IHNjbWlfc3RhdHVzICkNCj4+ICsgICAgew0KPj4gKyAgICBjYXNlIFNDTUlfTk9UX1NVUFBPUlRF RDoNCj4+ICsgICAgICAgIHJldHVybiAtRU9QTk9UU1VQUDsNCj4+ICsgICAgY2FzZSBTQ01JX0lO VkFMSURfUEFSQU1FVEVSUzoNCj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gKyAgICBj YXNlIFNDTUlfREVOSUVEOg0KPj4gKyAgICAgICAgcmV0dXJuIC1FQUNDRVM7DQo+PiArICAgIGNh c2UgU0NNSV9OT1RfRk9VTkQ6DQo+PiArICAgICAgICByZXR1cm4gLUVOT0VOVDsNCj4+ICsgICAg Y2FzZSBTQ01JX09VVF9PRl9SQU5HRToNCj4+ICsgICAgICAgIHJldHVybiAtRVJBTkdFOw0KPj4g KyAgICBjYXNlIFNDTUlfQlVTWToNCj4+ICsgICAgICAgIHJldHVybiAtRUJVU1k7DQo+PiArICAg IGNhc2UgU0NNSV9DT01NU19FUlJPUjoNCj4+ICsgICAgICAgIHJldHVybiAtRU5PVENPTk47DQo+ PiArICAgIGNhc2UgU0NNSV9HRU5FUklDX0VSUk9SOg0KPj4gKyAgICAgICAgcmV0dXJuIC1FSU87 DQo+PiArICAgIGNhc2UgU0NNSV9IQVJEV0FSRV9FUlJPUjoNCj4+ICsgICAgICAgIHJldHVybiAt RU5YSU87DQo+PiArICAgIGNhc2UgU0NNSV9QUk9UT0NPTF9FUlJPUjoNCj4+ICsgICAgICAgIHJl dHVybiAtRUJBRE1TRzsNCj4+ICsgICAgZGVmYXVsdDoNCj4+ICsgICAgICAgIHJldHVybiAtRUlO VkFMOw0KPj4gKyAgICB9DQo+PiArfQ0KPj4gKw0KPj4gKy8qIFBST1RPQ09MX1ZFUlNJT04gKi8N Cj4+ICsjZGVmaW5lIFNDTUlfVkVSU0lPTl9NSU5PUiBHRU5NQVNLKDE1LCAwKQ0KPj4gKyNkZWZp bmUgU0NNSV9WRVJTSU9OX01BSk9SIEdFTk1BU0soMzEsIDE2KQ0KPj4gKw0KPj4gK3N0cnVjdCBz Y21pX21zZ19wcm90X3ZlcnNpb25fcDJhIHsNCj4+ICsgICAgdWludDMyX3QgdmVyc2lvbjsNCj4+ ICt9IF9fcGFja2VkOw0KPj4gKw0KPj4gKy8qIEJBU0UgUFJPVE9DT0xfQVRUUklCVVRFUyAqLw0K Pj4gKyNkZWZpbmUgU0NNSV9CQVNFX0FUVFJfTlVNX1BST1RPIEdFTk1BU0soNywgMCkNCj4+ICsj ZGVmaW5lIFNDTUlfQkFTRV9BVFRSX05VTV9BR0VOVCBHRU5NQVNLKDE1LCA4KQ0KPj4gKw0KPj4g K3N0cnVjdCBzY21pX21zZ19iYXNlX2F0dHJpYnV0ZXNfcDJhIHsNCj4+ICsgICAgdWludDMyX3Qg YXR0cmlidXRlczsNCj4+ICt9IF9fcGFja2VkOw0KPj4gKw0KPj4gKy8qDQo+PiArICogQkFTRV9E SVNDT1ZFUl9BR0VOVA0KPj4gKyAqLw0KPj4gKyNkZWZpbmUgU0NNSV9CQVNFX0FHRU5UX0lEX09X TiAweEZGRkZGRkZGDQo+PiArDQo+PiArc3RydWN0IHNjbWlfbXNnX2Jhc2VfZGlzY292ZXJfYWdl bnRfYTJwIHsNCj4+ICsgICAgdWludDMyX3QgYWdlbnRfaWQ7DQo+PiArfSBfX3BhY2tlZDsNCj4+ ICsNCj4+ICtzdHJ1Y3Qgc2NtaV9tc2dfYmFzZV9kaXNjb3Zlcl9hZ2VudF9wMmEgew0KPj4gKyAg ICB1aW50MzJfdCBhZ2VudF9pZDsNCj4+ICsgICAgY2hhciBuYW1lW1NDTUlfU0hPUlRfTkFNRV9N QVhfU0laRV07DQo+PiArfSBfX3BhY2tlZDsNCj4+ICsNCj4+ICsvKg0KPj4gKyAqIEJBU0VfU0VU X0RFVklDRV9QRVJNSVNTSU9OUw0KPj4gKyAqLw0KPj4gKyNkZWZpbmUgU0NNSV9CQVNFX0RFVklD RV9BQ0NFU1NfQUxMT1cgICAgICAgICAgIEJJVCgwLCBVTCkNCj4+ICsNCj4+ICtzdHJ1Y3Qgc2Nt aV9tc2dfYmFzZV9zZXRfZGV2aWNlX3Blcm1pc3Npb25zX2EycCB7DQo+PiArICAgIHVpbnQzMl90 IGFnZW50X2lkOw0KPj4gKyAgICB1aW50MzJfdCBkZXZpY2VfaWQ7DQo+PiArICAgIHVpbnQzMl90 IGZsYWdzOw0KPj4gK30gX19wYWNrZWQ7DQo+PiArDQo+PiArLyoNCj4+ICsgKiBCQVNFX1JFU0VU X0FHRU5UX0NPTkZJR1VSQVRJT04NCj4+ICsgKi8NCj4+ICsjZGVmaW5lIFNDTUlfQkFTRV9BR0VO VF9QRVJNSVNTSU9OU19SRVNFVCAgICAgICBCSVQoMCwgVUwpDQo+PiArDQo+PiArc3RydWN0IHNj bWlfbXNnX2Jhc2VfcmVzZXRfYWdlbnRfY2ZnX2EycCB7DQo+PiArICAgIHVpbnQzMl90IGFnZW50 X2lkOw0KPj4gKyAgICB1aW50MzJfdCBmbGFnczsNCj4+ICt9IF9fcGFja2VkOw0KPj4gKw0KPj4g KyNlbmRpZiAvKiBBUk1fRklSTVdBUkVfU0NNSV9QUk9UT19IXyAqLw0KPj4gKw0KPj4gKy8qDQo+ PiArICogTG9jYWwgdmFyaWFibGVzOg0KPj4gKyAqIG1vZGU6IEMNCj4+ICsgKiBjLWZpbGUtc3R5 bGU6ICJCU0QiDQo+PiArICogYy1iYXNpYy1vZmZzZXQ6IDQNCj4+ICsgKiB0YWItd2lkdGg6IDQN Cj4+ICsgKiBpbmRlbnQtdGFicy1tb2RlOiBuaWwNCj4+ICsgKiBFbmQ6DQo+PiArICovDQo+PiBk aWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uYw0KPj4gYi94ZW4v YXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zaG1lbS5jDQo+PiBuZXcgZmlsZSBtb2RlIDEwMDY0NA0K Pj4gaW5kZXggMDAwMDAwMDAwMC4uYzY4MWUzYzQ3Ng0KPj4gLS0tIC9kZXYvbnVsbA0KPj4gKysr IGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uYw0KPj4gQEAgLTAsMCArMSwxMTUg QEANCj4+ICsvKiBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogR1BMLTIuMC1vbmx5ICovDQo+PiAr LyoNCj4+ICsgKiBTTUMvSFZDIHNobWVtIHRyYW5zcG9ydCBpbXBsZW1lbnRhdGlvbiB1c2VkIGJ5 DQo+PiArICogU0NJIFNDTUkgbXVsdGktYWdlbnQgZHJpdmVyLg0KPj4gKyAqDQo+PiArICogT2xl a3NpaSBNb2lzaWVpZXYgPG9sZWtzaWlfbW9pc2llaWV2QGVwYW0uY29tPg0KPj4gKyAqIENvcHly aWdodCAoYykgMjAyNSBFUEFNIFN5c3RlbXMNCj4+ICsgKi8NCj4+ICsvKiBTUERYLUxpY2Vuc2Ut SWRlbnRpZmllcjogR1BMLTIuMC1vbmx5ICovDQo+PiArDQo+PiArI2luY2x1ZGUgPHhlbi9lcnIu aD4NCj4+ICsjaW5jbHVkZSA8eGVuL2xpYi9pby5oPg0KPj4gKyNpbmNsdWRlIDxhc20vaW8uaD4N Cj4+ICsNCj4+ICsjaW5jbHVkZSAic2NtaS1wcm90by5oIg0KPj4gKyNpbmNsdWRlICJzY21pLXNo bWVtLmgiDQo+PiArDQo+PiArc3RhdGljIGlubGluZSBpbnQNCj4+ICtzaG1lbV9jaGFubmVsX2lz X2ZyZWUoY29uc3Qgdm9sYXRpbGUgc3RydWN0IHNjbWlfc2hhcmVkX21lbSBfX2lvbWVtDQo+PiAq c2htZW0pDQo+PiArew0KPj4gKyAgICByZXR1cm4gKHJlYWRsKCZzaG1lbS0+Y2hhbm5lbF9zdGF0 dXMpICYNCj4+ICsgICAgICAgICAgICBTQ01JX1NITUVNX0NIQU5fU1RBVF9DSEFOTkVMX0ZSRUUp ID8gMCA6IC1FQlVTWTsNCj4+ICt9DQo+PiArDQo+PiAraW50IHNobWVtX3B1dF9tZXNzYWdlKHZv bGF0aWxlIHN0cnVjdCBzY21pX3NoYXJlZF9tZW0gX19pb21lbSAqc2htZW0sDQo+PiArICAgICAg ICAgICAgICAgICAgICAgIHNjbWlfbXNnX2hlYWRlcl90ICpoZHIsIHZvaWQgKmRhdGEsIGludCBs ZW4pDQo+PiArew0KPj4gKyAgICBpbnQgcmV0Ow0KPj4gKw0KPj4gKyAgICBpZiAoIChsZW4gKyBv ZmZzZXRvZihzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtLCBtc2dfcGF5bG9hZCkpID4NCj4+ICsgICAg ICAgICBTQ01JX1NITUVNX01BUFBFRF9TSVpFICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJp bnRrKFhFTkxPR19FUlIgInNjbWk6IFdyb25nIHNpemUgb2Ygc21jIG1lc3NhZ2UuIERhdGEgaXMN Cj4+IGludmFsaWRcbiIpOw0KPj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArICAgIH0N Cj4+ICsNCj4+ICsgICAgcmV0ID0gc2htZW1fY2hhbm5lbF9pc19mcmVlKHNobWVtKTsNCj4+ICsg ICAgaWYgKCByZXQgKQ0KPj4gKyAgICAgICAgcmV0dXJuIHJldDsNCj4+ICsNCj4+ICsgICAgd3Jp dGVsX3JlbGF4ZWQoMHgwLCAmc2htZW0tPmNoYW5uZWxfc3RhdHVzKTsNCj4+ICsgICAgLyogV3Jp dGluZyAweDAgcmlnaHQgbm93LCBidXQgInNobWVtIl9GTEFHX0lOVFJfRU5BQkxFRCBjYW4gYmUN Cj4+IHNldCAqLw0KPj4gKyAgICB3cml0ZWxfcmVsYXhlZCgweDAsICZzaG1lbS0+ZmxhZ3MpOw0K Pj4gKyAgICB3cml0ZWxfcmVsYXhlZChzaXplb2Yoc2htZW0tPm1zZ19oZWFkZXIpICsgbGVuLCAm c2htZW0tPmxlbmd0aCk7DQo+PiArICAgIHdyaXRlbChwYWNrX3NjbWlfaGVhZGVyKGhkciksICZz aG1lbS0+bXNnX2hlYWRlcik7DQo+PiArDQo+PiArICAgIGlmICggbGVuID4gMCAmJiBkYXRhICkN Cj4+ICsgICAgICAgIF9fbWVtY3B5X3RvaW8oc2htZW0tPm1zZ19wYXlsb2FkLCBkYXRhLCBsZW4p Ow0KPj4gKw0KPj4gKyAgICByZXR1cm4gMDsNCj4+ICt9DQo+PiArDQo+PiAraW50IHNobWVtX2dl dF9yZXNwb25zZShjb25zdCB2b2xhdGlsZSBzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtIF9faW9tZW0N Cj4+ICpzaG1lbSwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgIHNjbWlfbXNnX2hlYWRlcl90 ICpoZHIsIHZvaWQgKmRhdGEsIGludCBsZW4pDQo+PiArew0KPj4gKyAgICBpbnQgcmVjdl9sZW47 DQo+PiArICAgIGludCByZXQ7DQo+PiArICAgIGludCBwYWQgPSBzaXplb2YoaGRyLT5zdGF0dXMp Ow0KPj4gKw0KPj4gKyAgICBpZiAoIGxlbiA+PSBTQ01JX1NITUVNX01BUFBFRF9TSVpFIC0NCj4+ ICsgICAgICAgICBvZmZzZXRvZihzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtLCBtc2dfcGF5bG9hZCkg KQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBwcmludGsoWEVOTE9HX0VSUg0KPj4gKyAgICAgICAg ICAgICAgICJzY21pOiBXcm9uZyBzaXplIG9mIGlucHV0IHNtYyBtZXNzYWdlLiBEYXRhIG1heSBi ZQ0KPj4gaW52YWxpZFxuIik7DQo+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsgICAg fQ0KPj4gKw0KPj4gKyAgICByZXQgPSBzaG1lbV9jaGFubmVsX2lzX2ZyZWUoc2htZW0pOw0KPj4g KyAgICBpZiAoIHJldCApDQo+PiArICAgICAgICByZXR1cm4gcmV0Ow0KPj4gKw0KPj4gKyAgICBy ZWN2X2xlbiA9IHJlYWRsKCZzaG1lbS0+bGVuZ3RoKSAtIHNpemVvZihzaG1lbS0+bXNnX2hlYWRl cik7DQo+PiArDQo+PiArICAgIGlmICggcmVjdl9sZW4gPCAwICkNCj4+ICsgICAgew0KPj4gKyAg ICAgICAgcHJpbnRrKFhFTkxPR19FUlINCj4+ICsgICAgICAgICAgICAgICAic2NtaTogV3Jvbmcg c2l6ZSBvZiBzbWMgbWVzc2FnZS4gRGF0YSBtYXkgYmUNCj4+IGludmFsaWRcbiIpOw0KPj4gKyAg ICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgdW5wYWNrX3Nj bWlfaGVhZGVyKHJlYWRsKCZzaG1lbS0+bXNnX2hlYWRlciksIGhkcik7DQo+PiArDQo+PiArICAg IGhkci0+c3RhdHVzID0gcmVhZGwoJnNobWVtLT5tc2dfcGF5bG9hZCk7DQo+PiArICAgIHJlY3Zf bGVuID0gcmVjdl9sZW4gPiBwYWQgPyByZWN2X2xlbiAtIHBhZCA6IDA7DQo+PiArDQo+PiArICAg IHJldCA9IHNjbWlfdG9feGVuX2Vycm5vKGhkci0+c3RhdHVzKTsNCj4+ICsgICAgaWYgKCByZXQg KQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBwcmludGsoWEVOTE9HX0RFQlVHICJzY21pOiBFcnJv ciByZWNlaXZlZDogJWRcbiIsIHJldCk7DQo+PiArICAgICAgICByZXR1cm4gcmV0Ow0KPj4gKyAg ICB9DQo+PiArDQo+PiArICAgIGlmICggcmVjdl9sZW4gPiBsZW4gKQ0KPj4gKyAgICB7DQo+PiAr ICAgICAgICBwcmludGsoWEVOTE9HX0VSUg0KPj4gKyAgICAgICAgICAgICAgICJzY21pOiBOb3Qg ZW5vdWdoIGJ1ZmZlciBmb3IgbWVzc2FnZSAlZCwgZXhwZWN0aW5nDQo+PiAlZFxuIiwNCj4+ICsg ICAgICAgICAgICAgICByZWN2X2xlbiwgbGVuKTsNCj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFM Ow0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIGlmICggcmVjdl9sZW4gPiAwICkNCj4+ICsgICAg ICAgIF9fbWVtY3B5X2Zyb21pbyhkYXRhLCBzaG1lbS0+bXNnX3BheWxvYWQgKyBwYWQsIHJlY3Zf bGVuKTsNCj4+ICsNCj4+ICsgICAgcmV0dXJuIDA7DQo+PiArfQ0KPj4gKw0KPj4gKy8qDQo+PiAr ICogTG9jYWwgdmFyaWFibGVzOg0KPj4gKyAqIG1vZGU6IEMNCj4+ICsgKiBjLWZpbGUtc3R5bGU6 ICJCU0QiDQo+PiArICogYy1iYXNpYy1vZmZzZXQ6IDQNCj4+ICsgKiB0YWItd2lkdGg6IDQNCj4+ ICsgKiBpbmRlbnQtdGFicy1tb2RlOiBuaWwNCj4+ICsgKiBFbmQ6DQo+PiArICovDQo+PiBkaWZm IC0tZ2l0IGEveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uaA0KPj4gYi94ZW4vYXJj aC9hcm0vZmlybXdhcmUvc2NtaS1zaG1lbS5oDQo+PiBuZXcgZmlsZSBtb2RlIDEwMDY0NA0KPj4g aW5kZXggMDAwMDAwMDAwMC4uNzMxM2NiNmIyNg0KPj4gLS0tIC9kZXYvbnVsbA0KPj4gKysrIGIv eGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uaA0KPj4gQEAgLTAsMCArMSw0NSBAQA0K Pj4gKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4wLW9ubHkgKi8NCj4+ICsvKg0K Pj4gKyAqIEFybSBTeXN0ZW0gQ29udHJvbCBhbmQgTWFuYWdlbWVudCBJbnRlcmZhY2UgZGVmaW5p dGlvbnMNCj4+ICsgKiBWZXJzaW9uIDMuMCAoREVOMDA1NkMpDQo+PiArICogU2hhcmVkIE1lbW9y eSBiYXNlZCBUcmFuc3BvcnQNCj4+ICsgKg0KPj4gKyAqIENvcHlyaWdodCAoYykgMjAyNCBFUEFN IFN5c3RlbXMNCj4+ICsgKi8NCj4+ICsNCj4+ICsjaWZuZGVmIEFSTV9GSVJNV0FSRV9TQ01JX1NI TUVNX0hfDQo+PiArI2RlZmluZSBBUk1fRklSTVdBUkVfU0NNSV9TSE1FTV9IXw0KPj4gKw0KPj4g KyNpbmNsdWRlIDx4ZW4vc3RkaW50Lmg+DQo+PiArDQo+PiArI2RlZmluZSBTQ01JX1NITUVNX0NI QU5fU1RBVF9DSEFOTkVMX0ZSRUUgIEJJVCgwLCBVTCkNCj4+ICsjZGVmaW5lIFNDTUlfU0hNRU1f Q0hBTl9TVEFUX0NIQU5ORUxfRVJST1IgQklUKDEsIFVMKQ0KPj4gKw0KPj4gK3N0cnVjdCBzY21p X3NoYXJlZF9tZW0gew0KPj4gKyAgICB1aW50MzJfdCByZXNlcnZlZDsNCj4+ICsgICAgdWludDMy X3QgY2hhbm5lbF9zdGF0dXM7DQo+PiArICAgIHVpbnQzMl90IHJlc2VydmVkMVsyXTsNCj4+ICsg ICAgdWludDMyX3QgZmxhZ3M7DQo+PiArICAgIHVpbnQzMl90IGxlbmd0aDsNCj4+ICsgICAgdWlu dDMyX3QgbXNnX2hlYWRlcjsNCj4+ICsgICAgdWludDhfdCBtc2dfcGF5bG9hZFtdOw0KPj4gK307 DQo+PiArDQo+PiArI2RlZmluZSBTQ01JX1NITUVNX01BUFBFRF9TSVpFIFBBR0VfU0laRQ0KPj4g Kw0KPj4gK2ludCBzaG1lbV9wdXRfbWVzc2FnZSh2b2xhdGlsZSBzdHJ1Y3Qgc2NtaV9zaGFyZWRf bWVtIF9faW9tZW0gKnNobWVtLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICBzY21pX21zZ19o ZWFkZXJfdCAqaGRyLCB2b2lkICpkYXRhLCBpbnQgbGVuKTsNCj4+ICsNCj4+ICtpbnQgc2htZW1f Z2V0X3Jlc3BvbnNlKGNvbnN0IHZvbGF0aWxlIHN0cnVjdCBzY21pX3NoYXJlZF9tZW0gX19pb21l bQ0KPj4gKnNobWVtLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgc2NtaV9tc2dfaGVhZGVy X3QgKmhkciwgdm9pZCAqZGF0YSwgaW50IGxlbik7DQo+PiArI2VuZGlmIC8qIEFSTV9GSVJNV0FS RV9TQ01JX1NITUVNX0hfICovDQo+PiArDQo+PiArLyoNCj4+ICsgKiBMb2NhbCB2YXJpYWJsZXM6 DQo+PiArICogbW9kZTogQw0KPj4gKyAqIGMtZmlsZS1zdHlsZTogIkJTRCINCj4+ICsgKiBjLWJh c2ljLW9mZnNldDogNA0KPj4gKyAqIHRhYi13aWR0aDogNA0KPj4gKyAqIGluZGVudC10YWJzLW1v ZGU6IG5pbA0KPj4gKyAqIEVuZDoNCj4+ICsgKi8NCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9h cm0vZmlybXdhcmUvc2NtaS1zbWMtbXVsdGlhZ2VudC5jDQo+PiBiL3hlbi9hcmNoL2FybS9maXJt d2FyZS9zY21pLXNtYy1tdWx0aWFnZW50LmMNCj4+IG5ldyBmaWxlIG1vZGUgMTAwNjQ0DQo+PiBp bmRleCAwMDAwMDAwMDAwLi44ZTUzMjc5OGE2DQo+PiAtLS0gL2Rldi9udWxsDQo+PiArKysgYi94 ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zbWMtbXVsdGlhZ2VudC5jDQo+PiBAQCAtMCwwICsx LDc5NCBAQA0KPj4gKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4wLW9ubHkgKi8N Cj4+ICsvKg0KPj4gKyAqIFNDSSBTQ01JIG11bHRpLWFnZW50IGRyaXZlciwgdXNpbmcgU01DL0hW QyBzaG1lbSBhcyB0cmFuc3BvcnQuDQo+PiArICoNCj4+ICsgKiBPbGVrc2lpIE1vaXNpZWlldiA8 b2xla3NpaV9tb2lzaWVpZXZAZXBhbS5jb20+DQo+PiArICogQ29weXJpZ2h0IChjKSAyMDI1IEVQ QU0gU3lzdGVtcw0KPj4gKyAqLw0KPj4gKw0KPj4gKyNpbmNsdWRlIDx4ZW4vYWNwaS5oPg0KPj4g Kw0KPj4gKyNpbmNsdWRlIDx4ZW4vZGV2aWNlX3RyZWUuaD4NCj4+ICsjaW5jbHVkZSA8eGVuL2lu aXQuaD4NCj4+ICsjaW5jbHVkZSA8eGVuL2lvY2FwLmg+DQo+PiArI2luY2x1ZGUgPHhlbi9lcnIu aD4NCj4+ICsjaW5jbHVkZSA8eGVuL2xpYmZkdC9saWJmZHQuaD4NCj4+ICsjaW5jbHVkZSA8eGVu L3BhcmFtLmg+DQo+PiArI2luY2x1ZGUgPHhlbi9zY2hlZC5oPg0KPj4gKyNpbmNsdWRlIDx4ZW4v dm1hcC5oPg0KPj4gKw0KPj4gKyNpbmNsdWRlIDxhc20vZmlybXdhcmUvc2NpLmg+DQo+PiArI2lu Y2x1ZGUgPGFzbS9zbWNjYy5oPg0KPj4gKw0KPj4gKyNpbmNsdWRlICJzY21pLXByb3RvLmgiDQo+ PiArI2luY2x1ZGUgInNjbWktc2htZW0uaCINCj4+ICsNCj4+ICsjZGVmaW5lIFNDTUlfQUdFTlRf SURfSU5WQUxJRCAweEZGDQo+PiArDQo+PiArI2RlZmluZSBTQ01JX1NFQ09OREFSWV9BR0VOVFMg InNjbWktc2Vjb25kYXJ5LWFnZW50cyINCj4+ICsNCj4+ICtzdHJ1Y3Qgc2NtaV9jaGFubmVsIHsN Cj4+ICsgICAgdWludDMyX3QgYWdlbnRfaWQ7DQo+PiArICAgIHVpbnQzMl90IGZ1bmNfaWQ7DQo+ PiArICAgIGRvbWlkX3QgZG9tYWluX2lkOw0KPj4gKyAgICB1aW50NjRfdCBwYWRkcjsNCj4+ICsg ICAgc3RydWN0IHNjbWlfc2hhcmVkX21lbSBfX2lvbWVtICpzaG1lbTsNCj4+ICsgICAgc3Bpbmxv Y2tfdCBsb2NrOw0KPj4gKyAgICBzdHJ1Y3QgbGlzdF9oZWFkIGxpc3Q7DQo+PiArfTsNCj4+ICsN Cj4+ICtzdHJ1Y3Qgc2NtaV9kYXRhIHsNCj4+ICsgICAgc3RydWN0IGxpc3RfaGVhZCBjaGFubmVs X2xpc3Q7DQo+PiArICAgIHNwaW5sb2NrX3QgY2hhbm5lbF9saXN0X2xvY2s7DQo+PiArICAgIHVp bnQzMl90IGZ1bmNfaWQ7DQo+PiArICAgIGJvb2wgaW5pdGlhbGl6ZWQ7DQo+PiArICAgIHVpbnQz Ml90IHNobWVtX3BoYW5kbGU7DQo+PiArICAgIHVpbnQzMl90IGh5cF9jaGFubmVsX2FnZW50X2lk Ow0KPj4gKyAgICBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKmR0X2RldjsNCj4+ICt9Ow0KPj4gKw0K Pj4gK3N0YXRpYyBzdHJ1Y3Qgc2NtaV9kYXRhIHNjbWlfZGF0YTsNCj4+ICsNCj4+ICtzdGF0aWMg aW50IHNlbmRfc21jX21lc3NhZ2Uoc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbl9pbmZvLA0KPj4g KyAgICAgICAgICAgICAgICAgICAgICAgICAgICBzY21pX21zZ19oZWFkZXJfdCAqaGRyLCB2b2lk ICpkYXRhLCBpbnQNCj4+IGxlbikNCj4+ICt7DQo+PiArICAgIHN0cnVjdCBhcm1fc21jY2NfcmVz IHJlc3A7DQo+PiArICAgIGludCByZXQ7DQo+PiArDQo+PiArICAgIHJldCA9IHNobWVtX3B1dF9t ZXNzYWdlKGNoYW5faW5mby0+c2htZW0sIGhkciwgZGF0YSwgbGVuKTsNCj4+ICsgICAgaWYgKCBy ZXQgKQ0KPj4gKyAgICAgICAgcmV0dXJuIHJldDsNCj4+ICsNCj4+ICsgICAgYXJtX3NtY2NjXzFf MV9zbWMoY2hhbl9pbmZvLT5mdW5jX2lkLCAwLCAwLCAwLCAwLCAwLCAwLCAwLCAmcmVzcCk7DQo+ PiArDQo+PiArICAgIGlmICggcmVzcC5hMCA9PSBBUk1fU01DQ0NfSU5WQUxJRF9QQVJBTUVURVIg KQ0KPj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArDQo+PiArICAgIGlmICggcmVzcC5h MCApDQo+PiArICAgICAgICByZXR1cm4gLUVPUE5PVFNVUFA7DQo+PiArDQo+PiArICAgIHJldHVy biAwOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgaW50IGRvX3NtY194ZmVyKHN0cnVjdCBzY21p X2NoYW5uZWwgKmNoYW5faW5mbywNCj4+IHNjbWlfbXNnX2hlYWRlcl90ICpoZHIsDQo+PiArICAg ICAgICAgICAgICAgICAgICAgICB2b2lkICp0eF9kYXRhLCBpbnQgdHhfc2l6ZSwgdm9pZCAqcnhf ZGF0YSwNCj4+IGludCByeF9zaXplKQ0KPj4gK3sNCj4+ICsgICAgaW50IHJldCA9IDA7DQo+PiAr DQo+PiArICAgIEFTU0VSVChjaGFuX2luZm8gJiYgY2hhbl9pbmZvLT5zaG1lbSk7DQo+PiArDQo+ PiArICAgIGlmICggIWhkciApDQo+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsNCj4+ ICsgICAgc3Bpbl9sb2NrKCZjaGFuX2luZm8tPmxvY2spOw0KPj4gKw0KPj4gKyAgICBwcmludGso WEVOTE9HX0RFQlVHDQo+PiArICAgICAgICAgICAic2NtaTogYWdlbnRfaWQgPSAlZCBtc2dfaWQg PSAleCB0eXBlID0gJWQsIHByb3RvID0gJXhcbiIsDQo+PiArICAgICAgICAgICBjaGFuX2luZm8t PmFnZW50X2lkLCBoZHItPmlkLCBoZHItPnR5cGUsIGhkci0+cHJvdG9jb2wpOw0KPj4gKw0KPj4g KyAgICByZXQgPSBzZW5kX3NtY19tZXNzYWdlKGNoYW5faW5mbywgaGRyLCB0eF9kYXRhLCB0eF9z aXplKTsNCj4+ICsgICAgaWYgKCByZXQgKQ0KPj4gKyAgICAgICAgZ290byBjbGVhbjsNCj4+ICsN Cj4+ICsgICAgcmV0ID0gc2htZW1fZ2V0X3Jlc3BvbnNlKGNoYW5faW5mby0+c2htZW0sIGhkciwg cnhfZGF0YSwgcnhfc2l6ZSk7DQo+PiArDQo+PiArY2xlYW46DQo+PiArICAgIHByaW50ayhYRU5M T0dfREVCVUcNCj4+ICsgICAgICAgICAgICJzY21pOiBnZXQgc21jIHJlc3BvbnNlIGFnZW50X2lk ID0gJWQgbXNnX2lkID0gJXggcHJvdG8gPQ0KPj4gJXggcmVzPSVkXG4iLA0KPj4gKyAgICAgICAg ICAgY2hhbl9pbmZvLT5hZ2VudF9pZCwgaGRyLT5pZCwgaGRyLT5wcm90b2NvbCwgcmV0KTsNCj4+ ICsNCj4+ICsgICAgc3Bpbl91bmxvY2soJmNoYW5faW5mby0+bG9jayk7DQo+PiArDQo+PiArICAg IHJldHVybiByZXQ7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBzdHJ1Y3Qgc2NtaV9jaGFubmVs ICpnZXRfY2hhbm5lbF9ieV9pZCh1aW50MzJfdCBhZ2VudF9pZCkNCj4+ICt7DQo+PiArICAgIHN0 cnVjdCBzY21pX2NoYW5uZWwgKmN1cnI7DQo+PiArICAgIGJvb2wgZm91bmQgPSBmYWxzZTsNCj4+ ICsNCj4+ICsgICAgc3Bpbl9sb2NrKCZzY21pX2RhdGEuY2hhbm5lbF9saXN0X2xvY2spOw0KPj4g KyAgICBsaXN0X2Zvcl9lYWNoX2VudHJ5KGN1cnIsICZzY21pX2RhdGEuY2hhbm5lbF9saXN0LCBs aXN0KQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBpZiAoIGN1cnItPmFnZW50X2lkID09IGFnZW50 X2lkICkNCj4+ICsgICAgICAgIHsNCj4+ICsgICAgICAgICAgICBmb3VuZCA9IHRydWU7DQo+PiAr ICAgICAgICAgICAgYnJlYWs7DQo+PiArICAgICAgICB9DQo+PiArICAgIH0NCj4+ICsNCj4+ICsg ICAgc3Bpbl91bmxvY2soJnNjbWlfZGF0YS5jaGFubmVsX2xpc3RfbG9jayk7DQo+PiArICAgIGlm ICggZm91bmQgKQ0KPj4gKyAgICAgICAgcmV0dXJuIGN1cnI7DQo+PiArDQo+PiArICAgIHJldHVy biBOVUxMOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgc3RydWN0IHNjbWlfY2hhbm5lbCAqYWNx dWlyZV9zY21pX2NoYW5uZWwoc3RydWN0IGRvbWFpbiAqZCwNCj4+ICsgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgYWdlbnRfaWQpDQo+PiAr ew0KPj4gKyAgICBzdHJ1Y3Qgc2NtaV9jaGFubmVsICpjdXJyOw0KPj4gKyAgICBzdHJ1Y3Qgc2Nt aV9jaGFubmVsICpyZXQgPSBFUlJfUFRSKC1FTk9FTlQpOw0KPj4gKw0KPj4gKyAgICBzcGluX2xv Y2soJnNjbWlfZGF0YS5jaGFubmVsX2xpc3RfbG9jayk7DQo+PiArICAgIGxpc3RfZm9yX2VhY2hf ZW50cnkoY3VyciwgJnNjbWlfZGF0YS5jaGFubmVsX2xpc3QsIGxpc3QpDQo+PiArICAgIHsNCj4+ ICsgICAgICAgIGlmICggY3Vyci0+YWdlbnRfaWQgPT0gYWdlbnRfaWQgKQ0KPj4gKyAgICAgICAg ew0KPj4gKyAgICAgICAgICAgIGlmICggY3Vyci0+ZG9tYWluX2lkICE9IERPTUlEX0lOVkFMSUQg KQ0KPj4gKyAgICAgICAgICAgIHsNCj4+ICsgICAgICAgICAgICAgICAgcmV0ID0gRVJSX1BUUigt RUVYSVNUKTsNCj4+ICsgICAgICAgICAgICAgICAgYnJlYWs7DQo+PiArICAgICAgICAgICAgfQ0K Pj4gKw0KPj4gKyAgICAgICAgICAgIGN1cnItPmRvbWFpbl9pZCA9IGQtPmRvbWFpbl9pZDsNCj4+ ICsgICAgICAgICAgICByZXQgPSBjdXJyOw0KPj4gKyAgICAgICAgICAgIGJyZWFrOw0KPj4gKyAg ICAgICAgfQ0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIHNwaW5fdW5sb2NrKCZzY21pX2RhdGEu Y2hhbm5lbF9saXN0X2xvY2spOw0KPj4gKw0KPj4gKyAgICByZXR1cm4gcmV0Ow0KPj4gK30NCj4+ ICsNCj4+ICtzdGF0aWMgdm9pZCByZWxpbnF1aXNoX3NjbWlfY2hhbm5lbChzdHJ1Y3Qgc2NtaV9j aGFubmVsICpjaGFubmVsKQ0KPj4gK3sNCj4+ICsgICAgQVNTRVJUKGNoYW5uZWwgIT0gTlVMTCk7 DQo+PiArDQo+PiArICAgIHNwaW5fbG9jaygmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdF9sb2NrKTsN Cj4+ICsgICAgY2hhbm5lbC0+ZG9tYWluX2lkID0gRE9NSURfSU5WQUxJRDsNCj4+ICsgICAgc3Bp bl91bmxvY2soJnNjbWlfZGF0YS5jaGFubmVsX2xpc3RfbG9jayk7DQo+PiArfQ0KPj4gKw0KPj4g K3N0YXRpYyBpbnQgbWFwX2NoYW5uZWxfbWVtb3J5KHN0cnVjdCBzY21pX2NoYW5uZWwgKmNoYW5u ZWwpDQo+PiArew0KPj4gKyAgICBBU1NFUlQoY2hhbm5lbCAmJiBjaGFubmVsLT5wYWRkcik7DQo+ PiArICAgIGNoYW5uZWwtPnNobWVtID0gaW9yZW1hcF9ub2NhY2hlKGNoYW5uZWwtPnBhZGRyLA0K Pj4gU0NNSV9TSE1FTV9NQVBQRURfU0laRSk7DQo+PiArICAgIGlmICggIWNoYW5uZWwtPnNobWVt ICkNCj4+ICsgICAgICAgIHJldHVybiAtRU5PTUVNOw0KPj4gKw0KPj4gKyAgICBjaGFubmVsLT5z aG1lbS0+Y2hhbm5lbF9zdGF0dXMgPSBTQ01JX1NITUVNX0NIQU5fU1RBVF9DSEFOTkVMX0ZSRUU7 DQo+PiArICAgIHByaW50ayhYRU5MT0dfREVCVUcgInNjbWk6IEdvdCBzaG1lbSAlbHggYWZ0ZXIg dm1hcCAlcFxuIiwNCj4+IGNoYW5uZWwtPnBhZGRyLA0KPj4gKyAgICAgICAgICAgY2hhbm5lbC0+ c2htZW0pOw0KPj4gKw0KPj4gKyAgICByZXR1cm4gMDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGlj IHZvaWQgdW5tYXBfY2hhbm5lbF9tZW1vcnkoc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5lbCkN Cj4+ICt7DQo+PiArICAgIEFTU0VSVChjaGFubmVsICYmIGNoYW5uZWwtPnNobWVtKTsNCj4+ICsg ICAgaW91bm1hcChjaGFubmVsLT5zaG1lbSk7DQo+PiArICAgIGNoYW5uZWwtPnNobWVtID0gTlVM TDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIHN0cnVjdCBzY21pX2NoYW5uZWwgKnNtY19jcmVh dGVfY2hhbm5lbCh1aW50MzJfdCBhZ2VudF9pZCwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGZ1bmNfaWQsDQo+PiB1aW50NjRfdCBh ZGRyKQ0KPj4gK3sNCj4+ICsgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5lbCwgKmN1cnI7 DQo+PiArDQo+PiArICAgIHNwaW5fbG9jaygmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdF9sb2NrKTsN Cj4+ICsNCj4+ICsgICAgLyogQ2hlY2sgaWYgY2hhbm5lbCBhbHJlYWR5IGV4aXN0cyB3aGlsZSBo b2xkaW5nIHRoZSBsb2NrICovDQo+PiArICAgIGxpc3RfZm9yX2VhY2hfZW50cnkoY3VyciwgJnNj bWlfZGF0YS5jaGFubmVsX2xpc3QsIGxpc3QpDQo+PiArICAgIHsNCj4+ICsgICAgICAgIGlmICgg Y3Vyci0+YWdlbnRfaWQgPT0gYWdlbnRfaWQgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAg ICAgIHNwaW5fdW5sb2NrKCZzY21pX2RhdGEuY2hhbm5lbF9saXN0X2xvY2spOw0KPj4gKyAgICAg ICAgICAgIHJldHVybiBFUlJfUFRSKC1FRVhJU1QpOw0KPj4gKyAgICAgICAgfQ0KPj4gKyAgICB9 DQo+PiArDQo+PiArICAgIGNoYW5uZWwgPSB4bWFsbG9jKHN0cnVjdCBzY21pX2NoYW5uZWwpOw0K Pj4gKyAgICBpZiAoICFjaGFubmVsICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgc3Bpbl91bmxv Y2soJnNjbWlfZGF0YS5jaGFubmVsX2xpc3RfbG9jayk7DQo+PiArICAgICAgICByZXR1cm4gRVJS X1BUUigtRU5PTUVNKTsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBzcGluX2xvY2tfaW5pdCgm Y2hhbm5lbC0+bG9jayk7DQo+PiArICAgIGNoYW5uZWwtPmFnZW50X2lkID0gYWdlbnRfaWQ7DQo+ PiArICAgIGNoYW5uZWwtPmZ1bmNfaWQgPSBmdW5jX2lkOw0KPj4gKyAgICBjaGFubmVsLT5kb21h aW5faWQgPSBET01JRF9JTlZBTElEOw0KPj4gKyAgICBjaGFubmVsLT5zaG1lbSA9IE5VTEw7DQo+ PiArICAgIGNoYW5uZWwtPnBhZGRyID0gYWRkcjsNCj4+ICsgICAgbGlzdF9hZGRfdGFpbCgmY2hh bm5lbC0+bGlzdCwgJnNjbWlfZGF0YS5jaGFubmVsX2xpc3QpOw0KPj4gKw0KPj4gKyAgICBzcGlu X3VubG9jaygmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdF9sb2NrKTsNCj4+ICsgICAgcmV0dXJuIGNo YW5uZWw7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyB2b2lkIGZyZWVfY2hhbm5lbF9saXN0KHZv aWQpDQo+PiArew0KPj4gKyAgICBzdHJ1Y3Qgc2NtaV9jaGFubmVsICpjdXJyLCAqX2N1cnI7DQo+ PiArDQo+PiArICAgIGxpc3RfZm9yX2VhY2hfZW50cnlfc2FmZShjdXJyLCBfY3VyciwgJnNjbWlf ZGF0YS5jaGFubmVsX2xpc3QsDQo+PiBsaXN0KQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBsaXN0 X2RlbCgmY3Vyci0+bGlzdCk7DQo+PiArICAgICAgICB4ZnJlZShjdXJyKTsNCj4+ICsgICAgfQ0K Pj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgaW50IF9faW5pdA0KPj4gK3NjbWlfZHRfcmVhZF9oeXBf Y2hhbm5lbF9hZGRyKHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqc2NtaV9ub2RlLCB1NjQNCj4+ICph ZGRyLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHU2NCAqc2l6ZSkNCj4+ICt7 DQo+PiArICAgIHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqc2htZW1fbm9kZTsNCj4+ICsgICAgY29u c3QgX19iZTMyICpwcm9wOw0KPj4gKw0KPj4gKyAgICBwcm9wID0gZHRfZ2V0X3Byb3BlcnR5KHNj bWlfbm9kZSwgInNobWVtIiwgTlVMTCk7DQo+PiArICAgIGlmICggIXByb3AgKQ0KPj4gKyAgICAg ICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArDQo+PiArICAgIHNobWVtX25vZGUgPSBkdF9maW5kX25v ZGVfYnlfcGhhbmRsZShiZTMyX3RvX2NwdSgqcHJvcCkpOw0KPj4gKyAgICBpZiAoIElTX0VSUl9P Ul9OVUxMKHNobWVtX25vZGUpICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJpbnRrKFhFTkxP R19FUlINCj4+ICsgICAgICAgICAgICAgICAic2NtaTogRGV2aWNlIHRyZWUgZXJyb3IsIGNhbid0 IHBhcnNlIHJlc2VydmVkIG1lbW9yeQ0KPj4gJWxkXG4iLA0KPj4gKyAgICAgICAgICAgICAgIFBU Ul9FUlIoc2htZW1fbm9kZSkpOw0KPj4gKyAgICAgICAgcmV0dXJuIFBUUl9FUlIoc2htZW1fbm9k ZSk7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcmV0dXJuIGR0X2RldmljZV9nZXRfYWRkcmVz cyhzaG1lbV9ub2RlLCAwLCBhZGRyLCBzaXplKTsNCj4+ICt9DQo+PiArDQo+PiArLyoNCj4+ICsg KiBIYW5kbGUgRG9tMCBTQ01JIHNwZWNpZmljIERUIG5vZGVzDQo+PiArICoNCj4+ICsgKiBNYWtl IGEgZGVjaXNpb24gb24gY29weWluZyBTQ01JIHNwZWNpZmljIG5vZGVzIGludG8gRG9tMCBkZXZp Y2UNCj4+IHRyZWUuDQo+PiArICogRm9yIFNDTUkgbXVsdGktYWdlbnQgY2FzZToNCj4+ICsgKiAt IHNobWVtIG5vZGVzIHdpbGwgbm90IGJlIGNvcGllZCBhbmQgZ2VuZXJhdGVkIGluc3RlYWQgaWYg U0NNSQ0KPj4gKyAqICAgaXMgZW5hYmxlZCBmb3IgRG9tMA0KPj4gKyAqIC0gc2NtaSBub2RlIHdp bGwgYmUgY29waWVkIGlmIFNDTUkgaXMgZW5hYmxlZCBmb3IgRG9tMA0KPj4gKyAqLw0KPj4gK3N0 YXRpYyBib29sIHNjbWlfZHRfaGFuZGxlX25vZGUoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0DQo+ PiBkdF9kZXZpY2Vfbm9kZSAqbm9kZSkNCj4+ICt7DQo+PiArICAgIHN0YXRpYyBjb25zdCBzdHJ1 Y3QgZHRfZGV2aWNlX21hdGNoIHNobWVtX21hdGNoZXNbXSBfX2luaXRjb25zdCA9IHsNCj4+ICsg ICAgICAgIERUX01BVENIX0NPTVBBVElCTEUoImFybSxzY21pLXNobWVtIiksDQo+PiArICAgICAg ICB7IC8qIHNlbnRpbmVsICovIH0sDQo+PiArICAgIH07DQo+PiArICAgIHN0YXRpYyBjb25zdCBz dHJ1Y3QgZHRfZGV2aWNlX21hdGNoIHNjbWlfbWF0Y2hlc1tdIF9faW5pdGNvbnN0ID0gew0KPj4g KyAgICAgICAgRFRfTUFUQ0hfUEFUSCgiL2Zpcm13YXJlL3NjbWkiKSwNCj4+ICsgICAgICAgIHsg Lyogc2VudGluZWwgKi8gfSwNCj4+ICsgICAgfTsNCj4+ICsNCj4+ICsgICAgaWYgKCAhc2NtaV9k YXRhLmluaXRpYWxpemVkICkNCj4+ICsgICAgICAgIHJldHVybiBmYWxzZTsNCj4+ICsNCj4+ICsg ICAgLyogc2tpcCBzY21pIHNobWVtIG5vZGUgZm9yIGRvbTAgaWYgc2NtaSBub3QgZW5hYmxlZCAq Lw0KPj4gKyAgICBpZiAoIGR0X21hdGNoX25vZGUoc2htZW1fbWF0Y2hlcywgbm9kZSkgJiYNCj4+ ICFzY2lfZG9tYWluX2lzX2VuYWJsZWQoZCkgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBkdF9k cHJpbnRrKCIgIFNraXAgc2NtaSBzaG1lbSBub2RlXG4iKTsNCj4+ICsgICAgICAgIHJldHVybiB0 cnVlOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIC8qIGRyb3Agc2NtaSBpZiBub3QgZW5hYmxl ZCAqLw0KPj4gKyAgICBpZiAoIGR0X21hdGNoX25vZGUoc2NtaV9tYXRjaGVzLCBub2RlKSAmJg0K Pj4gIXNjaV9kb21haW5faXNfZW5hYmxlZChkKSApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIGR0 X2RwcmludGsoIiAgU2tpcCBzY21pIG5vZGVcbiIpOw0KPj4gKyAgICAgICAgcmV0dXJuIHRydWU7 DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcmV0dXJuIGZhbHNlOw0KPj4gK30NCj4+ICsNCj4+ ICtzdGF0aWMgaW50IHNjbWlfYXNzaWduX2RldmljZSh1aW50MzJfdCBhZ2VudF9pZCwgdWludDMy X3QgZGV2aWNlX2lkLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90 IGZsYWdzKQ0KPj4gK3sNCj4+ICsgICAgc3RydWN0IHNjbWlfbXNnX2Jhc2Vfc2V0X2RldmljZV9w ZXJtaXNzaW9uc19hMnAgdHg7DQo+PiArICAgIHN0cnVjdCBzY21pX2NoYW5uZWwgKmNoYW5uZWw7 DQo+PiArICAgIHNjbWlfbXNnX2hlYWRlcl90IGhkcjsNCj4+ICsNCj4+ICsgICAgY2hhbm5lbCA9 IGdldF9jaGFubmVsX2J5X2lkKHNjbWlfZGF0YS5oeXBfY2hhbm5lbF9hZ2VudF9pZCk7DQo+PiAr ICAgIGlmICggIWNoYW5uZWwgKQ0KPj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArDQo+ PiArICAgIGhkci5pZCA9IFNDTUlfQkFTRV9TRVRfREVWSUNFX1BFUk1JU1NJT05TOw0KPj4gKyAg ICBoZHIudHlwZSA9IDA7DQo+PiArICAgIGhkci5wcm90b2NvbCA9IFNDTUlfQkFTRV9QUk9UT0NP TDsNCj4+ICsNCj4+ICsgICAgdHguYWdlbnRfaWQgPSBhZ2VudF9pZDsNCj4+ICsgICAgdHguZGV2 aWNlX2lkID0gZGV2aWNlX2lkOw0KPj4gKyAgICB0eC5mbGFncyA9IGZsYWdzOw0KPj4gKw0KPj4g KyAgICByZXR1cm4gZG9fc21jX3hmZXIoY2hhbm5lbCwgJmhkciwgJnR4LCBzaXplb2YodHgpLCBO VUxMLCAwKTsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIGludCBzY21pX2R0X2Fzc2lnbl9kZXZp Y2Uoc3RydWN0IGRvbWFpbiAqZCwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBzdHJ1Y3QgZHRfcGhhbmRsZV9hcmdzICphY19zcGVjKQ0KPj4gK3sNCj4+ICsgICAgc3RydWN0 IHNjbWlfY2hhbm5lbCAqYWdlbnRfY2hhbm5lbDsNCj4+ICsgICAgdWludDMyX3Qgc2NtaV9kZXZp Y2VfaWQgPSBhY19zcGVjLT5hcmdzWzBdOw0KPj4gKyAgICBpbnQgcmV0Ow0KPj4gKw0KPj4gKyAg ICBpZiAoICFkLT5hcmNoLnNjaV9kYXRhICkNCj4+ICsgICAgICAgIHJldHVybiAwOw0KPj4gKw0K Pj4gKyAgICAvKiBUaGUgYWNjZXNzLWNvbnRyb2xsZXJzIGlzIHNwZWNpZmllZCBmb3IgRFQgZGV2 LCBidXQgaXQncyBub3QNCj4+IGEgU0NNSSAqLw0KPj4gKyAgICBpZiAoIGFjX3NwZWMtPm5wICE9 IHNjbWlfZGF0YS5kdF9kZXYgKQ0KPj4gKyAgICAgICAgcmV0dXJuIDA7DQo+PiArDQo+PiArICAg IGFnZW50X2NoYW5uZWwgPSBkLT5hcmNoLnNjaV9kYXRhOw0KPj4gKw0KPj4gKyAgICBzcGluX2xv Y2soJmFnZW50X2NoYW5uZWwtPmxvY2spOw0KPj4gKw0KPj4gKyAgICByZXQgPSBzY21pX2Fzc2ln bl9kZXZpY2UoYWdlbnRfY2hhbm5lbC0+YWdlbnRfaWQsIHNjbWlfZGV2aWNlX2lkLA0KPj4gKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgU0NNSV9CQVNFX0RFVklDRV9BQ0NFU1NfQUxMT1cp Ow0KPj4gKyAgICBpZiAoIHJldCApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHByaW50ayhYRU5M T0dfRVJSDQo+PiArICAgICAgICAgICAgICAgInNjbWk6IGNvdWxkIG5vdCBhc3NpZ24gZGV2IGZv ciAlcGQgYWdlbnQ6JWQNCj4+IGRldl9pZDoldSAoJWQpIiwNCj4+ICsgICAgICAgICAgICAgICBk LCBhZ2VudF9jaGFubmVsLT5hZ2VudF9pZCwgc2NtaV9kZXZpY2VfaWQsIHJldCk7DQo+PiArICAg IH0NCj4+ICsNCj4+ICsgICAgc3Bpbl91bmxvY2soJmFnZW50X2NoYW5uZWwtPmxvY2spOw0KPj4g KyAgICByZXR1cm4gcmV0Ow0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgaW50IGNvbGxlY3RfYWdl bnRfaWQoc3RydWN0IHNjbWlfY2hhbm5lbCAqYWdlbnRfY2hhbm5lbCkNCj4+ICt7DQo+PiArICAg IGludCByZXQ7DQo+PiArICAgIHNjbWlfbXNnX2hlYWRlcl90IGhkcjsNCj4+ICsgICAgc3RydWN0 IHNjbWlfbXNnX2Jhc2VfZGlzY292ZXJfYWdlbnRfcDJhIGRhX3J4Ow0KPj4gKyAgICBzdHJ1Y3Qg c2NtaV9tc2dfYmFzZV9kaXNjb3Zlcl9hZ2VudF9hMnAgZGFfdHg7DQo+PiArDQo+PiArICAgIHJl dCA9IG1hcF9jaGFubmVsX21lbW9yeShhZ2VudF9jaGFubmVsKTsNCj4+ICsgICAgaWYgKCByZXQg KQ0KPj4gKyAgICAgICAgcmV0dXJuIHJldDsNCj4+ICsNCj4+ICsgICAgaGRyLmlkID0gU0NNSV9C QVNFX0RJU0NPVkVSX0FHRU5UOw0KPj4gKyAgICBoZHIudHlwZSA9IDA7DQo+PiArICAgIGhkci5w cm90b2NvbCA9IFNDTUlfQkFTRV9QUk9UT0NPTDsNCj4+ICsNCj4+ICsgICAgZGFfdHguYWdlbnRf aWQgPSBhZ2VudF9jaGFubmVsLT5hZ2VudF9pZDsNCj4+ICsNCj4+ICsgICAgcmV0ID0gZG9fc21j X3hmZXIoYWdlbnRfY2hhbm5lbCwgJmhkciwgJmRhX3R4LCBzaXplb2YoZGFfdHgpLA0KPj4gJmRh X3J4LA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgIHNpemVvZihkYV9yeCkpOw0KPj4gKyAg ICBpZiAoIGFnZW50X2NoYW5uZWwtPmRvbWFpbl9pZCAhPSBET01JRF9YRU4gKQ0KPj4gKyAgICAg ICAgdW5tYXBfY2hhbm5lbF9tZW1vcnkoYWdlbnRfY2hhbm5lbCk7DQo+PiArICAgIGlmICggcmV0 ICkNCj4+ICsgICAgICAgIHJldHVybiByZXQ7DQo+PiArDQo+PiArICAgIHByaW50ayhYRU5MT0df REVCVUcgImlkPTB4JXggbmFtZT0lc1xuIiwgZGFfcnguYWdlbnRfaWQsDQo+PiBkYV9yeC5uYW1l KTsNCj4+ICsgICAgYWdlbnRfY2hhbm5lbC0+YWdlbnRfaWQgPSBkYV9yeC5hZ2VudF9pZDsNCj4+ ICsgICAgcmV0dXJuIDA7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBfX2luaXQgaW50IGNvbGxl Y3RfYWdlbnRzKHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqc2NtaV9ub2RlKQ0KPj4gK3sNCj4+ICsg ICAgY29uc3Qgc3RydWN0IGR0X2RldmljZV9ub2RlICpjb25maWdfbm9kZTsNCj4+ICsgICAgY29u c3QgX19iZTMyICpwcm9wOw0KPj4gKyAgICB1aW50MzJfdCBsZW47DQo+PiArICAgIGNvbnN0IF9f YmUzMiAqZW5kOw0KPj4gKyAgICB1aW50MzJfdCBjZWxsc19wZXJfZW50cnkgPSAzOyAvKiBEZWZh dWx0IHRvIDMgY2VsbHMgaWYgcHJvcGVydHkNCj4+IGlzIGFic2VudC4gKi8NCj4+ICsNCj4+ICsg ICAgY29uZmlnX25vZGUgPSBkdF9maW5kX25vZGVfYnlfcGF0aCgiL2Nob3Nlbi94ZW4sY29uZmln Iik7DQo+PiArICAgIGlmICggIWNvbmZpZ19ub2RlICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAg cHJpbnRrKFhFTkxPR19XQVJOSU5HICJzY21pOiAvY2hvc2VuL3hlbixjb25maWcgbm9kZSBub3QN Cj4+IGZvdW5kLCBubyBhZ2VudHMgdG8gY29sbGVjdC5cbiIpOw0KPj4gKyAgICAgICAgcmV0dXJu IC1FTk9FTlQ7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgLyogQ2hlY2sgZm9yIHRoZSBvcHRp b25hbCAnI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxscycNCj4+IHByb3BlcnR5LiAqLw0KPj4g KyAgICBpZiAoIGR0X3Byb3BlcnR5X3JlYWRfdTMyKGNvbmZpZ19ub2RlLA0KPj4gIiNzY21pLXNl Y29uZGFyeS1hZ2VudHMtY2VsbHMiLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICZjZWxsc19wZXJfZW50cnkpICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgaWYgKCBjZWxsc19w ZXJfZW50cnkgIT0gMiAmJiBjZWxsc19wZXJfZW50cnkgIT0gMyApDQo+PiArICAgICAgICB7DQo+ PiArICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgInNjbWk6IEludmFsaWQNCj4+ICNzY21p LXNlY29uZGFyeS1hZ2VudHMtY2VsbHMgdmFsdWU6ICV1XG4iLA0KPj4gKyAgICAgICAgICAgICAg ICAgICBjZWxsc19wZXJfZW50cnkpOw0KPj4gKyAgICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0K Pj4gKyAgICAgICAgfQ0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIHByb3AgPSBkdF9nZXRfcHJv cGVydHkoY29uZmlnX25vZGUsIFNDTUlfU0VDT05EQVJZX0FHRU5UUywgJmxlbik7DQo+PiArICAg IGlmICggIXByb3AgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAi c2NtaTogTm8gJXMgcHJvcGVydHkgZm91bmQsIG5vIGFnZW50cyB0bw0KPj4gY29sbGVjdC5cbiIs DQo+PiArICAgICAgICAgICAgICAgU0NNSV9TRUNPTkRBUllfQUdFTlRTKTsNCj4+ICsgICAgICAg IHJldHVybiAtRUlOVkFMOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIC8qIFZhbGlkYXRlIHRo YXQgdGhlIHByb3BlcnR5IGxlbmd0aCBpcyBhIG11bHRpcGxlIG9mIHRoZSBjZWxsDQo+PiBzaXpl LiAqLw0KPj4gKyAgICBpZiAoIGxlbiA9PSAwIHx8IGxlbiAlIChjZWxsc19wZXJfZW50cnkgKiBz aXplb2YodWludDMyX3QpKSAhPSAwICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJpbnRrKFhF TkxPR19FUlIgInNjbWk6IEludmFsaWQgbGVuZ3RoIG9mICVzIHByb3BlcnR5OiAldQ0KPj4gZm9y ICV1IGNlbGxzIHBlciBlbnRyeVxuIiwNCj4+ICsgICAgICAgICAgICAgICBTQ01JX1NFQ09OREFS WV9BR0VOVFMsIGxlbiwgY2VsbHNfcGVyX2VudHJ5KTsNCj4+ICsgICAgICAgIHJldHVybiAtRUlO VkFMOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIGVuZCA9IChjb25zdCBfX2JlMzIgKikoKGNv bnN0IHU4ICopcHJvcCArIGxlbik7DQo+PiArDQo+PiArICAgIGZvciAoIDsgcHJvcCA8IGVuZDsg KQ0KPj4gKyAgICB7DQo+PiArICAgICAgICB1aW50MzJfdCBhZ2VudF9pZDsNCj4+ICsgICAgICAg IHVpbnQzMl90IHNtY19pZDsNCj4+ICsgICAgICAgIHVpbnQzMl90IHNobWVtX3BoYW5kbGU7DQo+ PiArICAgICAgICBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKm5vZGU7DQo+PiArICAgICAgICB1NjQg YWRkciwgc2l6ZTsNCj4+ICsgICAgICAgIGludCByZXQ7DQo+PiArICAgICAgICBzdHJ1Y3Qgc2Nt aV9jaGFubmVsICphZ2VudF9jaGFubmVsOw0KPj4gKw0KPj4gKyAgICAgICAgc21jX2lkID0gYmUz Ml90b19jcHUoKnByb3ArKyk7DQo+PiArICAgICAgICBzaG1lbV9waGFuZGxlID0gYmUzMl90b19j cHUoKnByb3ArKyk7DQo+PiArDQo+PiArICAgICAgICBpZiAoIGNlbGxzX3Blcl9lbnRyeSA9PSAz ICkNCj4+ICsgICAgICAgICAgICBhZ2VudF9pZCA9IGJlMzJfdG9fY3B1KCpwcm9wKyspOw0KPj4g KyAgICAgICAgZWxzZQ0KPj4gKyAgICAgICAgICAgIGFnZW50X2lkID0gU0NNSV9CQVNFX0FHRU5U X0lEX09XTjsNCj4+ICsNCj4+ICsgICAgICAgIG5vZGUgPSBkdF9maW5kX25vZGVfYnlfcGhhbmRs ZShzaG1lbV9waGFuZGxlKTsNCj4+ICsgICAgICAgIGlmICggIW5vZGUgKQ0KPj4gKyAgICAgICAg ew0KPj4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJzY21pOiBDb3VsZCBub3QgZmlu ZCBzaG1lbSBub2RlIGZvcg0KPj4gYWdlbnQgJXVcbiIsDQo+PiArICAgICAgICAgICAgICAgICAg IGFnZW50X2lkKTsNCj4+ICsgICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsgICAgICAg IH0NCj4+ICsNCj4+ICsgICAgICAgIHJldCA9IGR0X2RldmljZV9nZXRfYWRkcmVzcyhub2RlLCAw LCAmYWRkciwgJnNpemUpOw0KPj4gKyAgICAgICAgaWYgKCByZXQgKQ0KPj4gKyAgICAgICAgew0K Pj4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSDQo+PiArICAgICAgICAgICAgICAgICAg ICJzY21pOiBDb3VsZCBub3QgcmVhZCBzaG1lbSBhZGRyZXNzIGZvciBhZ2VudCAldToNCj4+ICVk XG4iLA0KPj4gKyAgICAgICAgICAgICAgICAgICBhZ2VudF9pZCwgcmV0KTsNCj4+ICsgICAgICAg ICAgICByZXR1cm4gcmV0Ow0KPj4gKyAgICAgICAgfQ0KPj4gKw0KPj4gKyAgICAgICAgaWYgKCAh SVNfQUxJR05FRChzaXplLCBTQ01JX1NITUVNX01BUFBFRF9TSVpFKSApDQo+PiArICAgICAgICB7 DQo+PiArICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgInNjbWk6IHNobWVtIG1lbW9yeSBp cyBub3QgYWxpZ25lZFxuIik7DQo+PiArICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiAr ICAgICAgICB9DQo+PiArDQo+PiArICAgICAgICBhZ2VudF9jaGFubmVsID0gc21jX2NyZWF0ZV9j aGFubmVsKGFnZW50X2lkLCBzbWNfaWQsIGFkZHIpOw0KPj4gKyAgICAgICAgaWYgKCBJU19FUlIo YWdlbnRfY2hhbm5lbCkgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAgICAgIHByaW50ayhY RU5MT0dfRVJSICJzY21pOiBDb3VsZCBub3QgY3JlYXRlIGNoYW5uZWwgZm9yDQo+PiBhZ2VudCAl dTogJWxkXG4iLA0KPj4gKyAgICAgICAgICAgICAgICAgICBhZ2VudF9pZCwgUFRSX0VSUihhZ2Vu dF9jaGFubmVsKSk7DQo+PiArICAgICAgICAgICAgcmV0dXJuIFBUUl9FUlIoYWdlbnRfY2hhbm5l bCk7DQo+PiArICAgICAgICB9DQo+PiArDQo+PiArICAgICAgICBpZiAoIGNlbGxzX3Blcl9lbnRy eSA9PSAyICkNCj4+ICsgICAgICAgIHsNCj4+ICsgICAgICAgICAgICByZXQgPSBjb2xsZWN0X2Fn ZW50X2lkKGFnZW50X2NoYW5uZWwpOw0KPj4gKyAgICAgICAgICAgIGlmICggcmV0ICkNCj4+ICsg ICAgICAgICAgICAgICAgcmV0dXJuIHJldDsNCj4+ICsgICAgICAgIH0NCj4+ICsNCj4+ICsgICAg ICAgIHByaW50ayhYRU5MT0dfREVCVUcgInNjbWk6IEFnZW50ICV1IFNNQyAlWCBhZGRyICVseFxu IiwNCj4+IGFnZW50X2NoYW5uZWwtPmFnZW50X2lkLA0KPj4gKyAgICAgICAgICAgICAgIHNtY19p ZCwgKHVuc2lnbmVkIGxvbmcpYWRkcik7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcmV0dXJu IDA7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBpbnQgc2NtaV9kb21haW5faW5pdChzdHJ1Y3Qg ZG9tYWluICpkLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgeGVuX2Rv bWN0bF9jcmVhdGVkb21haW4gKmNvbmZpZykNCj4+ICt7DQo+PiArICAgIHN0cnVjdCBzY21pX2No YW5uZWwgKmNoYW5uZWw7DQo+PiArICAgIGludCByZXQ7DQo+PiArDQo+PiArICAgIGlmICggIXNj bWlfZGF0YS5pbml0aWFsaXplZCApDQo+PiArICAgICAgICByZXR1cm4gMDsNCj4+ICsNCj4+ICsg ICAgLyoNCj4+ICsgICAgICogU0NNSSBzdXBwb3J0IGlzIGNvbmZpZ3VyZWQgdmlhOg0KPj4gKyAg ICAgKiAtIEZvciBkb20wOiBkb20wPXNjaS1hZ2VudC1pZD08dmFsdWU+IGluIFhlbiBjb21tYW5k IGxpbmUNCj4+ICsgICAgICogLSBGb3IgZG9tMGxlc3M6IHhlbixzY2ktYWdlbnQtaWQgaW4gZGV2 aWNlIHRyZWUNCj4+ICsgICAgICogVGhlIGNvbmZpZy0+YXJjaC5hcm1fc2NpX3R5cGUgYW5kIGNv bmZpZy0+YXJjaC5hcm1fc2NpX2FnZW50X2lkDQo+PiArICAgICAqIGFyZSBhbHJlYWR5IHNldCBi eSBkb21haW5fYnVpbGQuYyBvciBkb20wbGVzcy1idWlsZC5jDQo+PiArICAgICAqLw0KPj4gKw0K Pj4gKyAgICBpZiAoIGNvbmZpZy0+YXJjaC5hcm1fc2NpX3R5cGUgPT0gWEVOX0RPTUNUTF9DT05G SUdfQVJNX1NDSV9OT05FICkNCj4+ICsgICAgICAgIHJldHVybiAwOw0KPj4gKw0KPj4gKyAgICBj aGFubmVsID0gYWNxdWlyZV9zY21pX2NoYW5uZWwoZCwgY29uZmlnLT5hcmNoLmFybV9zY2lfYWdl bnRfaWQpOw0KPj4gKyAgICBpZiAoIElTX0VSUihjaGFubmVsKSApDQo+PiArICAgIHsNCj4+ICsg ICAgICAgIHByaW50ayhYRU5MT0dfRVJSDQo+PiArICAgICAgICAgICAgICAgInNjbWk6IEZhaWxl ZCB0byBhY3F1aXJlIFNDTUkgY2hhbm5lbCBmb3IgYWdlbnRfaWQNCj4+ICV1OiAlbGRcbiIsDQo+ PiArICAgICAgICAgICAgICAgY29uZmlnLT5hcmNoLmFybV9zY2lfYWdlbnRfaWQsIFBUUl9FUlIo Y2hhbm5lbCkpOw0KPj4gKyAgICAgICAgcmV0dXJuIFBUUl9FUlIoY2hhbm5lbCk7DQo+PiArICAg IH0NCj4+ICsNCj4+ICsgICAgcHJpbnRrKFhFTkxPR19JTkZPDQo+PiArICAgICAgICAgICAic2Nt aTogQWNxdWlyZSBjaGFubmVsIGlkID0gMHgleCwgZG9tYWluX2lkID0gJWQgcGFkZHIgPQ0KPj4g MHglbHhcbiIsDQo+PiArICAgICAgICAgICBjaGFubmVsLT5hZ2VudF9pZCwgY2hhbm5lbC0+ZG9t YWluX2lkLCBjaGFubmVsLT5wYWRkcik7DQo+PiArDQo+PiArICAgIC8qDQo+PiArICAgICAqIERv bTAgKGlmIHByZXNlbnQpIG5lZWRzIHRvIGhhdmUgYW4gYWNjZXNzIHRvIHRoZSBndWVzdCBtZW1v cnkNCj4+IHJhbmdlDQo+PiArICAgICAqIHRvIHNhdGlzZnkgaW9tZW1fYWNjZXNzX3Blcm1pdHRl ZCgpIGNoZWNrIGluDQo+PiBYRU5fRE9NQ1RMX2lvbWVtX3Blcm1pc3Npb24NCj4+ICsgICAgICog ZG9tY3RsLg0KPj4gKyAgICAgKi8NCj4+ICsgICAgaWYgKCBoYXJkd2FyZV9kb21haW4gJiYgIWlz X2hhcmR3YXJlX2RvbWFpbihkKSApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHJldCA9IGlvbWVt X3Blcm1pdF9hY2Nlc3MoaGFyZHdhcmVfZG9tYWluLA0KPj4gcGFkZHJfdG9fcGZuKGNoYW5uZWwt PnBhZGRyKSwNCj4+ICsgcGFkZHJfdG9fcGZuKGNoYW5uZWwtPnBhZGRyICsgUEFHRV9TSVpFIC0g MSkpOw0KPj4gKyAgICAgICAgaWYgKCByZXQgKQ0KPj4gKyAgICAgICAgICAgIGdvdG8gZXJyb3I7 DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgZC0+YXJjaC5zY2lfZGF0YSA9IGNoYW5uZWw7DQo+ PiArICAgIGQtPmFyY2guc2NpX2VuYWJsZWQgPSB0cnVlOw0KPj4gKw0KPj4gKyAgICByZXR1cm4g MDsNCj4+ICsNCj4+ICtlcnJvcjoNCj4+ICsgICAgcmVsaW5xdWlzaF9zY21pX2NoYW5uZWwoY2hh bm5lbCk7DQo+PiArICAgIHJldHVybiByZXQ7DQo+PiArfQ0KPj4gKw0KPj4gK2ludCBzY21pX2Rv bWFpbl9zYW5pdGlzZV9jb25maWcoc3RydWN0IHhlbl9kb21jdGxfY3JlYXRlZG9tYWluICpjb25m aWcpDQo+PiArew0KPj4gKyAgICBpZiAoIGNvbmZpZy0+YXJjaC5hcm1fc2NpX3R5cGUgIT0gWEVO X0RPTUNUTF9DT05GSUdfQVJNX1NDSV9OT05FICYmDQo+PiArICAgICAgICAgY29uZmlnLT5hcmNo LmFybV9zY2lfdHlwZSAhPQ0KPj4gWEVOX0RPTUNUTF9DT05GSUdfQVJNX1NDSV9TQ01JX1NNQ19N QSApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIGRwcmludGsoWEVOTE9HX0lORk8sICJzY21pOiBV bnN1cHBvcnRlZCBBUk1fU0NJIHR5cGVcbiIpOw0KPj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7 DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcmV0dXJuIDA7DQo+PiArfQ0KPj4gKw0KPj4gK3N0 YXRpYyBpbnQgc2NtaV9yZWxpbnF1aXNoX3Jlc291cmNlcyhzdHJ1Y3QgZG9tYWluICpkKQ0KPj4g K3sNCj4+ICsgICAgaW50IHJldDsNCj4+ICsgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5l bCwgKmFnZW50X2NoYW5uZWw7DQo+PiArICAgIHNjbWlfbXNnX2hlYWRlcl90IGhkcjsNCj4+ICsg ICAgc3RydWN0IHNjbWlfbXNnX2Jhc2VfcmVzZXRfYWdlbnRfY2ZnX2EycCB0eDsNCj4+ICsNCj4+ ICsgICAgaWYgKCAhZC0+YXJjaC5zY2lfZGF0YSApDQo+PiArICAgICAgICByZXR1cm4gMDsNCj4+ ICsNCj4+ICsgICAgYWdlbnRfY2hhbm5lbCA9IGQtPmFyY2guc2NpX2RhdGE7DQo+PiArDQo+PiAr ICAgIHNwaW5fbG9jaygmYWdlbnRfY2hhbm5lbC0+bG9jayk7DQo+PiArICAgIHR4LmFnZW50X2lk ID0gYWdlbnRfY2hhbm5lbC0+YWdlbnRfaWQ7DQo+PiArICAgIHNwaW5fdW5sb2NrKCZhZ2VudF9j aGFubmVsLT5sb2NrKTsNCj4+ICsNCj4+ICsgICAgY2hhbm5lbCA9IGdldF9jaGFubmVsX2J5X2lk KHNjbWlfZGF0YS5oeXBfY2hhbm5lbF9hZ2VudF9pZCk7DQo+PiArICAgIGlmICggIWNoYW5uZWwg KQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBwcmludGsoWEVOTE9HX0VSUg0KPj4gKyAgICAgICAg ICAgICAgICJzY21pOiBVbmFibGUgdG8gZ2V0IEh5cGVydmlzb3Igc2NtaSBjaGFubmVsIGZvcg0K Pj4gZG9tYWluICVkXG4iLA0KPj4gKyAgICAgICAgICAgICAgIGQtPmRvbWFpbl9pZCk7DQo+PiAr ICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBoZHIuaWQg PSBTQ01JX0JBU0VfUkVTRVRfQUdFTlRfQ09ORklHVVJBVElPTjsNCj4+ICsgICAgaGRyLnR5cGUg PSAwOw0KPj4gKyAgICBoZHIucHJvdG9jb2wgPSBTQ01JX0JBU0VfUFJPVE9DT0w7DQo+PiArDQo+ PiArICAgIHR4LmZsYWdzID0gMDsNCj4+ICsNCj4+ICsgICAgcmV0ID0gZG9fc21jX3hmZXIoY2hh bm5lbCwgJmhkciwgJnR4LCBzaXplb2YodHgpLCBOVUxMLCAwKTsNCj4+ICsgICAgaWYgKCByZXQg PT0gLUVPUE5PVFNVUFAgKQ0KPj4gKyAgICAgICAgcmV0dXJuIDA7DQo+PiArDQo+PiArICAgIHJl dHVybiByZXQ7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyB2b2lkIHNjbWlfZG9tYWluX2Rlc3Ry b3koc3RydWN0IGRvbWFpbiAqZCkNCj4+ICt7DQo+PiArICAgIHN0cnVjdCBzY21pX2NoYW5uZWwg KmNoYW5uZWw7DQo+PiArDQo+PiArICAgIGlmICggIWQtPmFyY2guc2NpX2RhdGEgKQ0KPj4gKyAg ICAgICAgcmV0dXJuOw0KPj4gKw0KPj4gKyAgICBjaGFubmVsID0gZC0+YXJjaC5zY2lfZGF0YTsN Cj4+ICsgICAgc3Bpbl9sb2NrKCZjaGFubmVsLT5sb2NrKTsNCj4+ICsNCj4+ICsgICAgcmVsaW5x dWlzaF9zY21pX2NoYW5uZWwoY2hhbm5lbCk7DQo+PiArICAgIHByaW50ayhYRU5MT0dfREVCVUcg InNjbWk6IEZyZWUgZG9tYWluICVkXG4iLCBkLT5kb21haW5faWQpOw0KPj4gKw0KPj4gKyAgICBk LT5hcmNoLnNjaV9kYXRhID0gTlVMTDsNCj4+ICsgICAgZC0+YXJjaC5zY2lfZW5hYmxlZCA9IGZh bHNlOw0KPj4gKw0KPj4gKyAgICBzcGluX3VubG9jaygmY2hhbm5lbC0+bG9jayk7DQo+PiArfQ0K Pj4gKw0KPj4gK3N0YXRpYyBib29sIHNjbWlfaGFuZGxlX2NhbGwoc3RydWN0IGNwdV91c2VyX3Jl Z3MgKnJlZ3MpDQo+PiArew0KPj4gKyAgICB1aW50MzJfdCBmaWQgPSAodWludDMyX3QpZ2V0X3Vz ZXJfcmVnKHJlZ3MsIDApOw0KPj4gKyAgICBzdHJ1Y3Qgc2NtaV9jaGFubmVsICphZ2VudF9jaGFu bmVsOw0KPj4gKyAgICBzdHJ1Y3QgZG9tYWluICpkID0gY3VycmVudC0+ZG9tYWluOw0KPj4gKyAg ICBzdHJ1Y3QgYXJtX3NtY2NjX3JlcyByZXNwOw0KPj4gKyAgICBib29sIHJlcyA9IGZhbHNlOw0K Pj4gKw0KPj4gKyAgICBpZiAoICFzY2lfZG9tYWluX2lzX2VuYWJsZWQoZCkgKQ0KPj4gKyAgICAg ICAgcmV0dXJuIGZhbHNlOw0KPj4gKw0KPj4gKyAgICBhZ2VudF9jaGFubmVsID0gZC0+YXJjaC5z Y2lfZGF0YTsNCj4+ICsgICAgc3Bpbl9sb2NrKCZhZ2VudF9jaGFubmVsLT5sb2NrKTsNCj4+ICsN Cj4+ICsgICAgaWYgKCBhZ2VudF9jaGFubmVsLT5mdW5jX2lkICE9IGZpZCApDQo+PiArICAgIHsN Cj4+ICsgICAgICAgIHJlcyA9IGZhbHNlOw0KPj4gKyAgICAgICAgZ290byB1bmxvY2s7DQo+PiAr ICAgIH0NCj4+ICsNCj4+ICsgICAgYXJtX3NtY2NjXzFfMV9zbWMoZmlkLA0KPj4gKyAgICAgICAg ICAgICAgICAgICAgICBnZXRfdXNlcl9yZWcocmVncywgMSksDQo+PiArICAgICAgICAgICAgICAg ICAgICAgIGdldF91c2VyX3JlZyhyZWdzLCAyKSwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAg Z2V0X3VzZXJfcmVnKHJlZ3MsIDMpLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICBnZXRfdXNl cl9yZWcocmVncywgNCksDQo+PiArICAgICAgICAgICAgICAgICAgICAgIGdldF91c2VyX3JlZyhy ZWdzLCA1KSwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgZ2V0X3VzZXJfcmVnKHJlZ3MsIDYp LA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICBnZXRfdXNlcl9yZWcocmVncywgNyksDQo+PiAr ICAgICAgICAgICAgICAgICAgICAgICZyZXNwKTsNCj4+ICsNCj4+ICsgICAgc2V0X3VzZXJfcmVn KHJlZ3MsIDAsIHJlc3AuYTApOw0KPj4gKyAgICBzZXRfdXNlcl9yZWcocmVncywgMSwgcmVzcC5h MSk7DQo+PiArICAgIHNldF91c2VyX3JlZyhyZWdzLCAyLCByZXNwLmEyKTsNCj4+ICsgICAgc2V0 X3VzZXJfcmVnKHJlZ3MsIDMsIHJlc3AuYTMpOw0KPj4gKyAgICByZXMgPSB0cnVlOw0KPj4gK3Vu bG9jazoNCj4+ICsgICAgc3Bpbl91bmxvY2soJmFnZW50X2NoYW5uZWwtPmxvY2spOw0KPj4gKw0K Pj4gKyAgICByZXR1cm4gcmVzOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgY29uc3Qgc3RydWN0 IHNjaV9tZWRpYXRvcl9vcHMgc2NtaV9vcHMgPSB7DQo+PiArICAgIC5kb21haW5faW5pdCA9IHNj bWlfZG9tYWluX2luaXQsDQo+PiArICAgIC5kb21haW5fZGVzdHJveSA9IHNjbWlfZG9tYWluX2Rl c3Ryb3ksDQo+PiArICAgIC5yZWxpbnF1aXNoX3Jlc291cmNlcyA9IHNjbWlfcmVsaW5xdWlzaF9y ZXNvdXJjZXMsDQo+PiArICAgIC5oYW5kbGVfY2FsbCA9IHNjbWlfaGFuZGxlX2NhbGwsDQo+PiAr ICAgIC5kb20wX2R0X2hhbmRsZV9ub2RlID0gc2NtaV9kdF9oYW5kbGVfbm9kZSwNCj4+ICsgICAg LmRvbWFpbl9zYW5pdGlzZV9jb25maWcgPSBzY21pX2RvbWFpbl9zYW5pdGlzZV9jb25maWcsDQo+ PiArICAgIC5hc3NpZ25fZHRfZGV2aWNlID0gc2NtaV9kdF9hc3NpZ25fZGV2aWNlLA0KPj4gK307 DQo+PiArDQo+PiArc3RhdGljIGludCBfX2luaXQgc2NtaV9jaGVja19zbWNjY192ZXIodm9pZCkN Cj4+ICt7DQo+PiArICAgIGlmICggc21jY2NfdmVyIDwgQVJNX1NNQ0NDX1ZFUlNJT05fMV8xICkN Cj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HDQo+PiArICAgICAg ICAgICAgICAgInNjbWk6IE5vIFNNQ0NDIDEuMSBzdXBwb3J0LCBTQ01JIGNhbGxzIGZvcndhcmRp bmcNCj4+IGRpc2FibGVkXG4iKTsNCj4+ICsgICAgICAgIHJldHVybiAtRU5PU1lTOw0KPj4gKyAg ICB9DQo+PiArDQo+PiArICAgIHJldHVybiAwOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgaW50 IF9faW5pdCBzY21pX2R0X2h5cF9jaGFubmVsX3JlYWQoc3RydWN0IGR0X2RldmljZV9ub2RlDQo+ PiAqc2NtaV9ub2RlLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBzdHJ1Y3Qgc2NtaV9kYXRhICpzY21pX2RhdGEsDQo+PiArICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHU2NCAqYWRkcikNCj4+ICt7DQo+PiArICAgIGludCBy ZXQ7DQo+PiArICAgIHU2NCBzaXplOw0KPj4gKw0KPj4gKyAgICBpZiAoICFkdF9wcm9wZXJ0eV9y ZWFkX3UzMihzY21pX25vZGUsICJhcm0sc21jLWlkIiwNCj4+ICZzY21pX2RhdGEtPmZ1bmNfaWQp ICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgInNjbWk6IHVuYWJs ZSB0byByZWFkIHNtYy1pZCBmcm9tIERUXG4iKTsNCj4+ICsgICAgICAgIHJldHVybiAtRU5PRU5U Ow0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIHJldCA9IHNjbWlfZHRfcmVhZF9oeXBfY2hhbm5l bF9hZGRyKHNjbWlfbm9kZSwgYWRkciwgJnNpemUpOw0KPj4gKyAgICBpZiAoIElTX0VSUl9WQUxV RShyZXQpICkNCj4+ICsgICAgICAgIHJldHVybiAtRU5PRU5UOw0KPj4gKw0KPj4gKyAgICBpZiAo ICFJU19BTElHTkVEKHNpemUsIFNDTUlfU0hNRU1fTUFQUEVEX1NJWkUpICkNCj4+ICsgICAgew0K Pj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgInNjbWk6IHNobWVtIG1lbW9yeSBpcyBub3Qg YWxpZ25lZFxuIik7DQo+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsgICAgfQ0KPj4g Kw0KPj4gKyAgICByZXR1cm4gMDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIF9faW5pdCBpbnQg c2NtaV9wcm9iZShzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKnNjbWlfbm9kZSwgY29uc3QNCj4+IHZv aWQgKmRhdGEpDQo+PiArew0KPj4gKyAgICB1NjQgYWRkcjsNCj4+ICsgICAgaW50IHJldDsNCj4+ ICsgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5lbDsNCj4+ICsgICAgdW5zaWduZWQgaW50 IG5fYWdlbnRzOw0KPj4gKyAgICBzY21pX21zZ19oZWFkZXJfdCBoZHI7DQo+PiArICAgIHN0cnVj dCBzY21pX21zZ19iYXNlX2F0dHJpYnV0ZXNfcDJhIHJ4Ow0KPj4gKw0KPj4gKyAgICBBU1NFUlQo c2NtaV9ub2RlICE9IE5VTEwpOw0KPj4gKw0KPj4gKyAgICBJTklUX0xJU1RfSEVBRCgmc2NtaV9k YXRhLmNoYW5uZWxfbGlzdCk7DQo+PiArICAgIHNwaW5fbG9ja19pbml0KCZzY21pX2RhdGEuY2hh bm5lbF9saXN0X2xvY2spOw0KPj4gKw0KPj4gKyAgICBpZiAoICFhY3BpX2Rpc2FibGVkICkNCj4+ ICsgICAgew0KPj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HICJzY21pOiBpcyBub3Qg c3VwcG9ydGVkIHdoZW4gdXNpbmcNCj4+IEFDUElcbiIpOw0KPj4gKyAgICAgICAgcmV0dXJuIC1F SU5WQUw7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcmV0ID0gc2NtaV9jaGVja19zbWNjY192 ZXIoKTsNCj4+ICsgICAgaWYgKCByZXQgKQ0KPj4gKyAgICAgICAgcmV0dXJuIHJldDsNCj4+ICsN Cj4+ICsgICAgcmV0ID0gc2NtaV9kdF9oeXBfY2hhbm5lbF9yZWFkKHNjbWlfbm9kZSwgJnNjbWlf ZGF0YSwgJmFkZHIpOw0KPj4gKyAgICBpZiAoIHJldCApDQo+PiArICAgICAgICByZXR1cm4gcmV0 Ow0KPj4gKw0KPj4gKyAgICBzY21pX2RhdGEuZHRfZGV2ID0gc2NtaV9ub2RlOw0KPj4gKw0KPj4g KyAgICBjaGFubmVsID0gc21jX2NyZWF0ZV9jaGFubmVsKFNDTUlfQkFTRV9BR0VOVF9JRF9PV04s DQo+PiBzY21pX2RhdGEuZnVuY19pZCwgYWRkcik7DQo+PiArICAgIGlmICggSVNfRVJSKGNoYW5u ZWwpICkNCj4+ICsgICAgICAgIGdvdG8gb3V0Ow0KPj4gKw0KPj4gKyAgICAvKiBNYXJrIGFzIFhl biBtYW5hZ2VtZW50IGNoYW5uZWwgYmVmb3JlIGNvbGxlY3RpbmcgYWdlbnQgSUQgKi8NCj4+ICsg ICAgY2hhbm5lbC0+ZG9tYWluX2lkID0gRE9NSURfWEVOOw0KPj4gKw0KPj4gKyAgICAvKiBSZXF1 ZXN0IGFnZW50IGlkIGZvciBYZW4gbWFuYWdlbWVudCBjaGFubmVsICAqLw0KPj4gKyAgICByZXQg PSBjb2xsZWN0X2FnZW50X2lkKGNoYW5uZWwpOw0KPj4gKyAgICBpZiAoIHJldCApDQo+PiArICAg ICAgICBnb3RvIGVycm9yOw0KPj4gKw0KPj4gKyAgICAvKiBTYXZlIHRoZSBhZ2VudCBpZCBmb3Ig WGVuIG1hbmFnZW1lbnQgY2hhbm5lbCAqLw0KPj4gKyAgICBzY21pX2RhdGEuaHlwX2NoYW5uZWxf YWdlbnRfaWQgPSBjaGFubmVsLT5hZ2VudF9pZDsNCj4+ICsNCj4+ICsgICAgaGRyLmlkID0gU0NN SV9CQVNFX1BST1RPQ09MX0FUVElCVVRFUzsNCj4+ICsgICAgaGRyLnR5cGUgPSAwOw0KPj4gKyAg ICBoZHIucHJvdG9jb2wgPSBTQ01JX0JBU0VfUFJPVE9DT0w7DQo+PiArDQo+PiArICAgIHJldCA9 IGRvX3NtY194ZmVyKGNoYW5uZWwsICZoZHIsIE5VTEwsIDAsICZyeCwgc2l6ZW9mKHJ4KSk7DQo+ PiArICAgIGlmICggcmV0ICkNCj4+ICsgICAgICAgIGdvdG8gZXJyb3I7DQo+PiArDQo+PiArICAg IG5fYWdlbnRzID0gU0NNSV9GSUVMRF9HRVQoU0NNSV9CQVNFX0FUVFJfTlVNX0FHRU5ULCByeC5h dHRyaWJ1dGVzKTsNCj4+ICsgICAgcHJpbnRrKFhFTkxPR19ERUJVRyAic2NtaTogR290IGFnZW50 IGNvdW50ICVkXG4iLCBuX2FnZW50cyk7DQo+PiArICAgIHJldCA9IGNvbGxlY3RfYWdlbnRzKHNj bWlfbm9kZSk7DQo+PiArICAgIGlmICggcmV0ICkNCj4+ICsgICAgICAgIGdvdG8gZXJyb3I7DQo+ PiArDQo+PiArICAgIHJldCA9IHNjaV9yZWdpc3Rlcigmc2NtaV9vcHMpOw0KPj4gKyAgICBpZiAo IHJldCApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJTQ01JOiBt ZWRpYXRvciBhbHJlYWR5IHJlZ2lzdGVyZWQgKHJldCA9DQo+PiAlZClcbiIsDQo+PiArICAgICAg ICAgICAgICAgcmV0KTsNCj4+ICsgICAgICAgIHJldHVybiByZXQ7DQo+PiArICAgIH0NCj4+ICsN Cj4+ICsgICAgc2NtaV9kYXRhLmluaXRpYWxpemVkID0gdHJ1ZTsNCj4+ICsgICAgZ290byBvdXQ7 DQo+PiArDQo+PiArZXJyb3I6DQo+PiArICAgIHVubWFwX2NoYW5uZWxfbWVtb3J5KGNoYW5uZWwp Ow0KPj4gKyAgICBmcmVlX2NoYW5uZWxfbGlzdCgpOw0KPj4gK291dDoNCj4+ICsgICAgcmV0dXJu IHJldDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIGNvbnN0IHN0cnVjdCBkdF9kZXZpY2VfbWF0 Y2ggc2NtaV9zbWNfbWF0Y2hbXSBfX2luaXRjb25zdCA9IHsNCj4+ICsgICAgRFRfTUFUQ0hfUEFU SCgiL2Nob3Nlbi94ZW4sY29uZmlnL3NjbWkiKSwNCj4+ICsgICAgeyAvKiBzZW50aW5lbCAqLyB9 LA0KPj4gK307DQo+PiArDQo+PiArRFRfREVWSUNFX1NUQVJUKHNjbWlfc21jX21hLCAiU0NNSSBT TUMgTUVESUFUT1IiLCBERVZJQ0VfRklSTVdBUkUpDQo+PiArICAgICAgICAuZHRfbWF0Y2ggPSBz Y21pX3NtY19tYXRjaCwNCj4+ICsgICAgICAgIC5pbml0ID0gc2NtaV9wcm9iZSwNCj4+ICtEVF9E RVZJQ0VfRU5EDQo+PiArDQo+PiArLyoNCj4+ICsgKiBMb2NhbCB2YXJpYWJsZXM6DQo+PiArICog bW9kZTogQw0KPj4gKyAqIGMtZmlsZS1zdHlsZTogIkJTRCINCj4+ICsgKiBjLWJhc2ljLW9mZnNl dDogNA0KPj4gKyAqIHRhYi13aWR0aDogNA0KPj4gKyAqIGluZGVudC10YWJzLW1vZGU6IG5pbA0K Pj4gKyAqIEVuZDoNCj4+ICsgKi8NCj4+IGRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9wdWJsaWMv YXJjaC1hcm0uaA0KPj4gYi94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC1hcm0uaA0KPj4gaW5kZXgg MDk1YjFhMjNlMy4uMzBlNDZkZTZkNyAxMDA2NDQNCj4+IC0tLSBhL3hlbi9pbmNsdWRlL3B1Ymxp Yy9hcmNoLWFybS5oDQo+PiArKysgYi94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC1hcm0uaA0KPj4g QEAgLTMyOSw2ICszMjksNyBAQCBERUZJTkVfWEVOX0dVRVNUX0hBTkRMRSh2Y3B1X2d1ZXN0X2Nv bnRleHRfdCk7DQo+PiAgICAgI2RlZmluZSBYRU5fRE9NQ1RMX0NPTkZJR19BUk1fU0NJX05PTkUg ICAgICAwDQo+PiAgICNkZWZpbmUgWEVOX0RPTUNUTF9DT05GSUdfQVJNX1NDSV9TQ01JX1NNQyAg MQ0KPj4gKyNkZWZpbmUgWEVOX0RPTUNUTF9DT05GSUdfQVJNX1NDSV9TQ01JX1NNQ19NQSAgMg0K Pj4gICAgIHN0cnVjdCB4ZW5fYXJjaF9kb21haW5jb25maWcgew0KPj4gICAgICAgLyogSU4vT1VU ICovDQo+PiBAQCAtMzU1LDYgKzM1Niw4IEBAIHN0cnVjdCB4ZW5fYXJjaF9kb21haW5jb25maWcg ew0KPj4gICAgICAgdWludDMyX3QgY2xvY2tfZnJlcXVlbmN5Ow0KPj4gICAgICAgLyogSU4gKi8N Cj4+ICAgICAgIHVpbnQ4X3QgYXJtX3NjaV90eXBlOw0KPj4gKyAgICAvKiBJTiAqLw0KPj4gKyAg ICB1aW50OF90IGFybV9zY2lfYWdlbnRfaWQ7DQo+PiAgIH07DQo+PiAgICNlbmRpZiAvKiBfX1hF Tl9fIHx8IF9fWEVOX1RPT0xTX18gKi8NCj4NCg== From xen-devel-bounces@lists.xenproject.org Tue Jan 13 14:40:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 14:40:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201835.1517396 (Exim 4.92) (envelope-from ) id 1vffZq-0006M3-50; Tue, 13 Jan 2026 14:40:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201835.1517396; Tue, 13 Jan 2026 14: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 1vffZq-0006Lw-2S; Tue, 13 Jan 2026 14:40:58 +0000 Received: by outflank-mailman (input) for mailman id 1201835; Tue, 13 Jan 2026 14:40:57 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vffZp-0006Lq-4G for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 14:40:57 +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 dce5716d-f08d-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 15:40:54 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB5422.namprd03.prod.outlook.com (2603:10b6:a03:27b::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 14:40:50 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.005; Tue, 13 Jan 2026 14:40: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: dce5716d-f08d-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=D0J0+hEZJI8/X/BpPEsMYerACWK3zSJmVXcvZFUdLhMgy4Yx41kGxf34JXbr6Bh/doS1nBkrqSttbiMvEvLdRyg+Dk00hZsP76GTr2+NH8ust5zmyYx7jLpHE3Kj3rzE/qNKfjPiOWz/kYYICV45UP5hzaJIn+unvWQKtHuoMGEeSHffI9BjE5arBX8zmpdF/PiPjwuxaEN+un8HZP1LgKPphCAN2rWREtWKR4z0cCgzCuOmO/L6oDgpPDh5NkoriIfWmljufJY+jCqqsRwpgQ72dMf6fu1+V8vkDS6EVvyb3Ah1t8NHI3MnJJbxlUpR+AqFRArpR8ptRhpYRUfLRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=n4uE4TuaosuHx1ZcfmsmJ7OxEFtfON5KHQSsae2zFmE=; b=qnp5L1q9fc3e7cgH760P6wpwbcX8sDWJe8jWauSUEmkybvwkV6Hsnsm97DQRZZyMmPce8A1qskAsPELy8yu1Kvxi89CiiYQviXhllDMBVCSBL64tqdmi4R5RsHy8RK+XDX6/Ex3cealuv8clXjEoWM99e7yIFeLoJA1081mJGobh7qR7uUS2s/y8F0YRY8JQNfWGCfIibb5f1/XMGuXsQYD/wqFdqReO5PulbrOu1OZrUORLplrMBH7na3RvLG8pku0egSa0YuqEWRiJpAo4A5b3zStG6t0A3lAXeun0kbty+vc8PYA1ER+dYidZyBK2S04yQJeIfZj96qURzCAEYg== 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=n4uE4TuaosuHx1ZcfmsmJ7OxEFtfON5KHQSsae2zFmE=; b=cZfvVj1b5y81AqdDVnX20qwh1MBpDQATjPnnIsSIe6t5UBvQMgWtBqBHtEO1hXdXllXw8pil2ilLJMG8hMq2hBmqX+/36zz9Qg5vzQLhiQp9gGpbwp2lqmCf6BW7zeolwDLGZLeGkPbofTAghPMH1GCdQrhuIXzmiVTNfjrR7xo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <2b3b7a14-6d44-480c-a3e3-d320c7a2c931@citrix.com> Date: Tue, 13 Jan 2026 14:40:47 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] x86/platform: adjust CONFIG_VIDEO usage To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <54667383-d1ff-467f-9dfc-95d23aa600cc@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <54667383-d1ff-467f-9dfc-95d23aa600cc@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0118.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2c6::8) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ0PR03MB5422:EE_ X-MS-Office365-Filtering-Correlation-Id: b418a5bf-b2b9-4857-9e73-08de52b1bf05 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?U1E0TjI1RmxTenlHZTZqdEorb29Qb21mWHArdXhBci9lNjRlSExhZTg5aE1D?= =?utf-8?B?dlFJVi8wTHlMSFdlS1hyY2VsZEJmQTNSUlhId0xDQnp0ZlVaRENwb0kwQnZB?= =?utf-8?B?ZDVwNWs3ZWlCektlTGZyUk5QRVlnR2EvbHNuZVV0Tm9yZmJiMDFSTjBZczlI?= =?utf-8?B?Wk5NS3dXTHlwZTUvekRIR29uUyt1bWJoOHRsT0FqZDdyblBtTWFCOWhqKzM2?= =?utf-8?B?RE00M0VtMVhEaVE3YUsvaG5aQmxQSCtubHRxNmFNNThJMDY3amtWWWpMYms0?= =?utf-8?B?RTV2VHo0QjA5QTVxRGJ6bTA3OU1CYUpjcmozRzFHMnN2YzQ0eVcwbmFhc294?= =?utf-8?B?S2FkQXlLakRWbVhTOTFHQnJ0ZUZIZzgwSDBybFZydXdTdW5Ba0RSbGUxZkdt?= =?utf-8?B?MnRhY3FOYVFyZnNpb2VEY1dYbmFCVVZSbDZGVDlGWlVRdEt5TXg5YTZXMFJi?= =?utf-8?B?eHIwa3pPTExVYlBBejFCUGhlUHdyY3lmY21HTTlNR1drSmN1WkFnL1ZWRUhp?= =?utf-8?B?ZkdHYlRwTkRPRHNMbWdya2JJVEpuZTFnUVVsNk9PWE5wL2Z0dWtNUWVZT2xp?= =?utf-8?B?Y2t3TmhycjNjTHU5bVBxcVI1OW1ORWJhWXBueWhVbkpKU3JhRzFHMUlIRXhx?= =?utf-8?B?eGNWSFVXd0NJVnZ1R0xEWDB6RysyYTlEelNIR2xhbjNpcklhRzc2Tmg4L0dP?= =?utf-8?B?MkZ1d0lxNDcvQUhGSm4vbEFTRk9zYnBJdXBtaExNUm54SGdLdXdGTlQxRThh?= =?utf-8?B?TkF6WEoydHAzSy84U0FZd1pLTktIbTNtd09razNBL1hZRndQZ1Z4VlFpWDh5?= =?utf-8?B?MW9Nd2xwQlRnejE1Tms3TW5FR2xZcDVIWVFZYXVjWkZGYVZrbVphVTErUHJC?= =?utf-8?B?cVU2L2N6VmpDUlZjWDhJS0pNbm1jb0NuVVdjbTlrVTdNUzQ5aE5nOTNXLyty?= =?utf-8?B?TGtQMkRlTFVkRTQzK2ZWaGJWWEJNZGU3NnpHRjAyb21hMFcyVmlWL0I0cVdX?= =?utf-8?B?Um55Y05qS3EwRTZUY1ludFM3c2Q1K3ZDYUVhQ1lmazBPYnJjNkp1bG5VN1M1?= =?utf-8?B?b2orVzA3cGoxSXR5QjlPNEgwdi8zd2VFbnVNNEhHZklHYmYzN2dCaWF6WjYr?= =?utf-8?B?bEVtZXhEOVplcFNIdjFNTGk4R2EvVmRmc2FaL1JSV0Nqakg5M1J1RlNMbnIr?= =?utf-8?B?KzFIVFVEOVNKNit6bkk0eFl0bVBxZkw5WDltZkttODc1TzQ3OUpuSTZsNlRD?= =?utf-8?B?S2tQUnVxSkpmSmYxaldDbDNzL0RVU2RsdXE3Z2xnZUZhRi9DTllBTHdTQ1ZN?= =?utf-8?B?WDBYWmxiYjYyVmNqMldSczdvV2NVOW00aTgrN2d3N0dFM2JJY0xackZDV0VK?= =?utf-8?B?SHVvc3VZekxaOHY1Z09RVlZKMXJiOTB6SUVVcE9MdnVWZFc5R3hVUWp5d0ph?= =?utf-8?B?L3oyWmVWcjlwK2szR1RxZG5xcFkxWDRyUFRBZ1VmRGJnem1kR3MzM1FlR0Rp?= =?utf-8?B?WWFXMkczZmlMeVJHSW9mY3FzdU9XUXBtRjZWRXUyQnNUWFNZbDI0aVNpZTNv?= =?utf-8?B?MVM2UUxFaW1QQzBOdklZU3g1MXNsK3pVcFY4VmNDN052Tkkva3JpcWRQNy9Y?= =?utf-8?B?TXJjNGJvRFFQU2lGZ1dhM0FpVkgxZ0FZSHJ4M3BMbm1NYlFCTmlaQkQrRmxE?= =?utf-8?B?RVNoVVpESjc1c2U0clQ1UTJkUzFLelV6c05hT2UwZEQ1ay83bzVrYVJiSE94?= =?utf-8?B?Wnd4WHlDZVdLemgvMWR2UGt4YTAvUXowcXp1TjB4anQ1NTJKSjdYT1BaL0Vi?= =?utf-8?B?Y09aTUp4YTVPbGs0UE5jNEJ5d2pXY1ZjVUtLY2dKdWYwdmJMMnR1dXBIa0Nn?= =?utf-8?B?elpwODJUdmJPSGE0VFp4NmhSZk5nRnV3Q2p2Nys0SEpmZ0FUTzZXU0pkWkFZ?= =?utf-8?Q?wAbBjUN+VCNYn0bM+psSgYZfl8auVk1c?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MnpKYUxvcklBWDM0RHhpS0Urb0x0T2trTXpUZ2s4c1RjQjRpbUZyVVFqeFlG?= =?utf-8?B?VFBRY2VFNmxrVkR6STVLVi9BaUdNdkpGWTlDSlNnYUliSDk2dlJaZjRGcmVN?= =?utf-8?B?bU11cEw2YTArRWxieTlPZWpPTXdsd0hjcHBzc2UwVTduSW1YdlhYei9wbkdp?= =?utf-8?B?bnJ5TlVNOHFybFFyVkFTb2lhUGlIaUhZNVRkNGhiVGxXcGppb3BZNElsZHJ4?= =?utf-8?B?OVZGU0lLQUk4S0Yzci96ZlRudEJ1d2xRbmNNeXc4cGNuNUczNFhqbHB5RUpB?= =?utf-8?B?aDNwOGRsMG55NEgwMWxxZWZsSENCVTh1UGFENzJwamlic3E1WFZTQlMyR0NQ?= =?utf-8?B?S2pvelpRdEVPdHlMZ0Fja1NTUkcvRVpEaHUyQjBMcDV1enV6R1ZBVzh4alpG?= =?utf-8?B?bWhtQ1Nhb05kWXVHYlBXSDBZdVRGQVcyZXhWeURNam9Yc081Si9XTkZ1aUIz?= =?utf-8?B?L0FaL2oxVW5XSUtyV05TUk1yaWt6S0ZBbDQ0S040TG5Ta2p4dXNXL3VnT3o3?= =?utf-8?B?blZ6cEI4T0Y2elhqTnJvZFp2dnB2Q3NaQ1FxSEQ4NWIrNnpYY1RFUmtIZDFm?= =?utf-8?B?ck55WEhVKy9pZm1McXJUTVA5bHFTSDNWdU11bEU5dVlkQlgyaC84VVYvKzhO?= =?utf-8?B?VncxSHpCeGdGeFNNb0h1SStmQlB6VkRaZ0xhKzBRTmdYQTViZEg1VUNDaW50?= =?utf-8?B?ZEFOeldwMGlQY3grVktnVzVFMnpNSDJiRkdqYmFLMjR2YzZBWll6Z2kvN0k2?= =?utf-8?B?Vzk2ZmRSQVh4S21STEhtWStoUWp4MmxPcXJGd05FandoU29WNWtXK0dER0FS?= =?utf-8?B?VHJ4RUVzOEVNRFE3blQ5eWFBdGh4Y3ZPaUF0UjA3bEwzTyswN3NEME5HY2to?= =?utf-8?B?ZXVVODdpRTF6UlBMbU5BejRPV2J6NEl5ai9nMi9GKy9EK3Y5NzlXTXVDWTBM?= =?utf-8?B?bU5sSjlvZUpPcTJnaHIrVmlmdEFSK3FvMmRRdjJiRWRYeitmY2RTeVRxU0dK?= =?utf-8?B?VmFxOHlPK0l3UWhXY2oweTFGRnFFWVR5dUJqQWZKWEsxbEJPVXlkMS9WU0xx?= =?utf-8?B?elNJS3d0Q09QdWdrMUtHL3o1WUIrRy9SVTZ4dmxINmJML0lWQzliMm9wanlE?= =?utf-8?B?c1JJY2pzOHArSU5XRG5iM3NPeTd3L00vUk9ETGhoMkVISXBka25Na1FwNUhh?= =?utf-8?B?bHFFWlJmOWxGN1NiUjdJcFZDOWRZWDVLdUJObG5BM2w3R0lBWC8zWHhFNkRH?= =?utf-8?B?ZXBzNFJqTEI1dk9NWGk4emp3bXZWWFNrcEVYOUdna3YxYkJSakZ5NFJTSUtu?= =?utf-8?B?L2d1UU1yVWd4b1lxODdFaUFxdStFblhhcjBweEY1VWNaaVRYZnJlOU92dGdH?= =?utf-8?B?S3FCWklNZmd4eEtYb1I4cEVadXkvUm1JSXRNWFRCTFhqN0hoQVhqVUs0VnB4?= =?utf-8?B?eVk1MFZmWTY0SVVzbFFFdG12Q0l2cE5ieFBHb0ZQRGkvamNveG0rMGZwTnAz?= =?utf-8?B?VU1qNGh3MjJpcDlOWFZ2ckNGYlNaRWUvV3hZUjVCTDBQRmZtc2FvSG5DdHZZ?= =?utf-8?B?T3NKMFpFTDBaVEVtYnlQMy9VbjBjR2Z3VTZzbW4rUm1nUTVIQkJaS3c2Rmhv?= =?utf-8?B?dWhVTEpqbGtDbjlpanVMblNrSVlVV01ibkw1WGk5bFhoVWJnTmJkYzlJdlNP?= =?utf-8?B?aVhKS1FERm9VN0NCYTRSRHZRSXRFUnFDZ205Snl1KzJoVkViZjEzQWtiNW1N?= =?utf-8?B?cTFRQk5SOUNpZk1jWi9jditNdndVOGZBWVI4SEpqTlpaOVNFclFNU2hUTk9q?= =?utf-8?B?Z2dtam8xcEh5OEE5dytuMmRSTVdlUllxMmVmaTJLQnV6YUhoaG5xSlhCTDRU?= =?utf-8?B?VFJHdUVoUjI1UjB6MFUxdWJ6OE9ubU02WFlFQjZ4YWYzdUorWjdPNlUyTjV6?= =?utf-8?B?YUY5QmpCVlZna1c3UmorRE5WTndEdzA5cWZHcExTb2RrNXV2bzkxcDNQd1ZK?= =?utf-8?B?dlR1aFplUWJhOXAyc0s4M3BhZ1pBYnk3bStZN3lablYzb09BNXNLZnNuQVF2?= =?utf-8?B?ZzZscXdMN0t3VXlUeVEvWXRld1I5VE9scEYvUmQrN0pQLzhmYStzcjB0R3Q0?= =?utf-8?B?SHBaTW5TNTB3UC9EUFZKeFc5YW0vYlpIWXREaUlsV0E5c0xOR1VxcGVOR3RQ?= =?utf-8?B?WGo0cm8rR3U5R2hFYStCbDVMdkFSWjVoMFppUUh2V1NtMTBKdGgvZmR6N0Vh?= =?utf-8?B?Q1lJaEcxQU1hcTBpOXRtOXZHY3F5NDFKdTkvTXZvS054bVNXbStWUmJzZE53?= =?utf-8?B?QjBiMzNNVVNQMWhWemZROHJlUTFBa2ZGT1luZkJRTENzbWphYU9UZWkvdCt4?= =?utf-8?Q?sYWuDi+RAJSc9LTs=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b418a5bf-b2b9-4857-9e73-08de52b1bf05 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 14:40:50.2439 (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: qifMQUICx/DT3Fs+aOlhedjtrz89b+/qYkb1bSt8/sXtbaAVinqGyLIVmArD/q0tosAwdwZEzuUt3d5KtP55d04pozyx8SpCpenAUYECWFY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5422 On 13/01/2026 9:23 am, Jan Beulich wrote: > Switch to using IS_ENABLED() in both places, thus in particular making > sure XENPF_get_dom0_console handling doesn't take the "default" path: The > behavior better wouldn't differ between VIDEO=y and there not being VGA vs > VIDEO=n. For this to work, fill_console_start_info() needs to be > unconditionally declared; extend that to vga_console_info as well. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper > --- > I'm not quite certain whether to have Fixes: 11b4ff64841e ("x86/platform: > protect XENPF_get_dom0_console if CONFIG_VIDEO not set") here. Opinions? That's up to you.  I doubt you're going to backport it, so it really doesn't matter does it? ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 13 14:44:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 14:44:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201844.1517406 (Exim 4.92) (envelope-from ) id 1vffdR-0006uf-Jm; Tue, 13 Jan 2026 14:44:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201844.1517406; Tue, 13 Jan 2026 14:44:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vffdR-0006uY-Gp; Tue, 13 Jan 2026 14:44:41 +0000 Received: by outflank-mailman (input) for mailman id 1201844; Tue, 13 Jan 2026 14:44: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 1vffdQ-0006uP-KM for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 14:44: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 5f29138e-f08e-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 15:44:32 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-b7cf4a975d2so1292990666b.2 for ; Tue, 13 Jan 2026 06:44:32 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b871b5e60dasm607106666b.63.2026.01.13.06.44.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 06:44:31 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5f29138e-f08e-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768315472; x=1768920272; 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=F1naa2jGZWbm/wr+OPD7p+au0bc4zmtsr95R3a2jp+s=; b=gFfOvT9uUaU8hqoQ0gwFCL0/iKfIRH6rPg9Fm9Rc7T60401kUOXO5faLEjfVy9lyZJ YMeRYKmzzLS/YkcOQvriCIUdGhA4d9h+zbJgK5icyqFkqjUFsClBamHCeGytbjAe2bbM vwz+4voTMd5h8JaAD8TS0+bxsxe1hW+ZRJfF9hhqWVhdo/s+LZhIx+QkbZdvEWEV0mGP F5HNWit8RtU0v8E8dR5ElGLhtZGCdjWoLVFWttsmsx8p/TIbHz/usaSSrk3OPg2zN2ZY sDnzf0DrNZb3GSrBR+wtAasGe5ebtY4RSGiFL+aBTGxuA5k1unhe71EZC9r1/8do8ilx tYHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768315472; x=1768920272; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=F1naa2jGZWbm/wr+OPD7p+au0bc4zmtsr95R3a2jp+s=; b=vcNesyPg+Rp2iJoDSW5y+h1WvOrVlgzC4gSm0skhGQ/vUha6xLtgjRgAyX7DOZ98eV I4nWOA2E93fee/GYQGaaJtaW8TsNwmn5XTOeD69rcCdLI2Ax1reAQ2QgmngyFAR5RIam xbgKKXJMezB3Cgq+tHTwyL8mjn90MeqZ4KmgjnBCKEapU6lwLksVorqCcKurNqEUGW87 JnpOJij0R8Toef8TtzYykftYz6SPQVLXQ+zeuxGmrp68RrxQJI98Ma6rmqy2O4wiQGal HBPgOwdNWCnoUD6WhVArdwpEPBoYzg/AkOgVHQ7zODJ4nvQjycTHY9mSOZkZA8JFy3ie +7Ug== X-Forwarded-Encrypted: i=1; AJvYcCW1k7mJ6h2DD8JLQzrPy+Z6xtZxI2kVwCJKq2sF3ysUZ2Y2H0MNWpliWHvLHG/XwJjUYucipSjD1Z4=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywm7CCm/HxngReoIGewirVRjkTJAHCvLTZA1w6jwfDLXsJdmfYI v+3msd9W7Cbbn8j1g/SsxZ+yYOqMKaVTrETldK1ilJHqudX7WFL/t+FY X-Gm-Gg: AY/fxX440o3sqU3LQkhsVLp/EyMV6Gk5426UrfNqqKXkhfOKMhM+eVDB2ORmEdFOzAX JkPiqzBqzR7tz2ZKY4WDIqyD9ojIKR232/sS7dExF2bptPT6TWcWaNg2IKr2dzWQIE1UUog26S6 CQbhvvNhrmzXWg7y0D5SUVz6ZDA2gUHcIEOAeeTYG0A0VZBcIjS1Jdk1cMwNsZ8sFRvP5TRG/0o vP3UQ13tXCSVRXcdldM6XLKPRg8Q40E6tj/whT5AJ2Du0E9OxggIwfY7hiTofxwlS9Sk72O1z96 q3FAEXf0BF4DmQE+hlLhm1eLfA+whvMbbUmIVZ1O7EZlkYE0iD0OWq/fvGJ8QzUOM2uYRS+jdkS y3sHrNqHfNglSRJ8Om1DMjoiaOyzFubOB2vN2NiFXq0CY8gOA/uBO2SL3fmHlqUeUqfOdBSJ7zI 9CrPyYG9+IM3i9DL5wY6cY+h1qO1oyIjQrjWnjLt0QJoJcVgdkwK55XYVKJWgpkpDPnoDoWwz1e w== X-Google-Smtp-Source: AGHT+IGP5Nk2fJxTLG8rXR9+J/DTISt2Xo5iTf5uCmw8XZD/WfO9uh+pDyITMpZ15UEAP+146QdmIA== X-Received: by 2002:a17:907:6d1a:b0:b73:99f7:8134 with SMTP id a640c23a62f3a-b8444fabdc4mr1923017066b.45.1768315471318; Tue, 13 Jan 2026 06:44:31 -0800 (PST) Message-ID: <4e18e4fc-de62-44fc-8ea0-517f6c7ef47f@gmail.com> Date: Tue, 13 Jan 2026 15:44:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 08/15] xen/riscv: introduce vtimer_set_timer() and vtimer_expired() 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: <8cd3efa488b3da2a6751c92d20bbfeb87b3ba39a.1766595589.git.oleksii.kurochko@gmail.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 1/8/26 11:28 AM, Jan Beulich wrote: > On 24.12.2025 18:03, Oleksii Kurochko wrote: >> --- a/xen/arch/riscv/include/asm/vtimer.h >> +++ b/xen/arch/riscv/include/asm/vtimer.h >> @@ -22,4 +22,6 @@ void vcpu_timer_destroy(struct vcpu *v); >> >> int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config); >> >> +void vtimer_set_timer(struct vtimer *t, const uint64_t ticks); >> + >> #endif /* ASM__RISCV__VTIMER_H */ >> diff --git a/xen/arch/riscv/vtimer.c b/xen/arch/riscv/vtimer.c >> index 5ba533690bc2..99a0c5986f1d 100644 >> --- a/xen/arch/riscv/vtimer.c >> +++ b/xen/arch/riscv/vtimer.c >> @@ -1,6 +1,8 @@ >> /* SPDX-License-Identifier: GPL-2.0-only */ >> >> +#include > Is this really needed, when ... > >> #include > ... this is already there? With the way how includes look in xen/sched.h - no. > >> +#include > Don't you mean xen/timer.h here? You are right, it should be xen/timer.h as set_timer(), stop_timer() and migrate_timer() are from xen/timer.h. > >> @@ -15,7 +17,9 @@ int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config) >> >> static void vtimer_expired(void *data) >> { >> - panic("%s: TBD\n", __func__); >> + struct vtimer *t = data; > Pointer-to-const please. > >> @@ -37,3 +41,27 @@ void vcpu_timer_destroy(struct vcpu *v) >> >> kill_timer(&v->arch.vtimer.timer); >> } >> + >> +void vtimer_set_timer(struct vtimer *t, const uint64_t ticks) >> +{ >> + s_time_t expires = ticks_to_ns(ticks - boot_clock_cycles); > boot_clock_cycles is known to just Xen. If the guest provided input is an > absolute value, how would that work across migration? Doesn't there need > to be a guest-specific bias instead? I think that I don't understand fully your questions, but it sounds like it is a job for htimedelta register. > >> + vcpu_unset_interrupt(t->v, IRQ_VS_TIMER); >> + >> + /* >> + * According to the RISC-V sbi spec: >> + * If the supervisor wishes to clear the timer interrupt without >> + * scheduling the next timer event, it can either request a timer >> + * interrupt infinitely far into the future (i.e., (uint64_t)-1), >> + * or it can instead mask the timer interrupt by clearing sie.STIE CSR >> + * bit. >> + */ > And SBI is the only way to set the expiry value? No CSR access? (Question > also concerns the unconditional vcpu_unset_interrupt() above.) If we don't have SSTC extension support then I suppose yes, as CSR_MI{E,P} could be accessed only from M-mode: (code from OpenSBI) void sbi_timer_event_start(u64 next_event) { sbi_pmu_ctr_incr_fw(SBI_PMU_FW_SET_TIMER); /** * Update the stimecmp directly if available. This allows * the older software to leverage sstc extension on newer hardware. */ if (sbi_hart_has_extension(sbi_scratch_thishart_ptr(), SBI_HART_EXT_SSTC)) { #if __riscv_xlen == 32 csr_write(CSR_STIMECMP, next_event & 0xFFFFFFFF); csr_write(CSR_STIMECMPH, next_event >> 32); #else csr_write(CSR_STIMECMP, next_event); #endif } else if (timer_dev && timer_dev->timer_event_start) { timer_dev->timer_event_start(next_event); csr_clear(CSR_MIP, MIP_STIP); } csr_set(CSR_MIE, MIP_MTIP); } > >> + if ( ticks == ((uint64_t)~0ULL) ) > Nit: With the cast you won't need the ULL suffix. > >> + { >> + stop_timer(&t->timer); >> + >> + return; >> + } >> + >> + set_timer(&t->timer, expires); > See the handling of VCPUOP_set_singleshot_timer for what you may want to > do if the expiry asked for is (perhaps just very slightly) into the past. I got an idea why we want to check if "expires" already expired, but ... > There you'll also find a use of migrate_timer(), which you will want to > at least consider using here as well. ... I don't get why we want to migrate timer before set_timer() here. Could you please explain that? Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Jan 13 15:00:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 15:00:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201885.1517517 (Exim 4.92) (envelope-from ) id 1vffsl-0002YQ-PN; Tue, 13 Jan 2026 15:00:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201885.1517517; Tue, 13 Jan 2026 15:00:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vffsl-0002YJ-Mm; Tue, 13 Jan 2026 15:00:31 +0000 Received: by outflank-mailman (input) for mailman id 1201885; Tue, 13 Jan 2026 15:00:30 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vffsk-0002YD-HK for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 15:00:30 +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 98a9ee53-f090-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 16:00:28 +0100 (CET) Received: from BYAPR08CA0066.namprd08.prod.outlook.com (2603:10b6:a03:117::43) by DS0PR12MB8480.namprd12.prod.outlook.com (2603:10b6:8:159::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 15:00:17 +0000 Received: from SJ5PEPF000001F5.namprd05.prod.outlook.com (2603:10b6:a03:117:cafe::4a) by BYAPR08CA0066.outlook.office365.com (2603:10b6:a03:117::43) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.5 via Frontend Transport; Tue, 13 Jan 2026 15:00:15 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ5PEPF000001F5.mail.protection.outlook.com (10.167.242.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Tue, 13 Jan 2026 15:00: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, 13 Jan 2026 09:00:12 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 98a9ee53-f090-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=F4jycobY8y6LaBFgHeH26s54NNyfRAGIcfySfjcPHlx2fplaNNoaeW9jZFd2jN4EqzHlV1DuHW3qah+NkCjjHh2mEk+N5rESfRbCgwtq16BHJpWhMiXmlY4802qaFGf36kR+2MoMmHlpYQS/9YSCFGREAsfpKXgUHnbBqpsPMfQnr/OBxtqK+Fih+a3kAyVCoKBqt9mcugDR8+heji3EezxQwSO1658gDNCOliSpIlQ407tAorKp9Xn5meYRJlraPT/JQG1XNRn2y3rC/gJJEhICRKDwXQGtoo/voeXQHiar5m8/raJqfbhxqKaKR5DCShnCcIjt/MIL1ZfFMVlzRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6QD+IhtFWiEwGJgIssVsWbrtrgcjCh4UTtw73d/oNM4=; b=GLmceAb93sgFDNgtQv9XZn+foTNBZ/X8HYRINzlw1JOBAWgby99EI1mbvAYgNMF30Bl0EVdoWM3Z6HaY7LjADP37hXFCtgl3OSOVmclW7wWnJNT/DT7wKBLGAIM3HEBsIhBaBzBJZHwNAil7uqV0vM8ULVOb5lQ+VgVo4eEo/eAGmAGYAoA+3LJKtcI990Tvfs/cgLzFCOS5mugt6VWihAPSbrMXIk6QNuUzwkui7RUnFcL7BMY0kxgRm6Gk1TER45gvoQnjkEgt8/F+Xv+YVCQ2jzGs41DGS8bMFPrlobptAl4xgGwb8mjIM01VI+d31b1HidHUQvWN3iBO6TyLug== 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=6QD+IhtFWiEwGJgIssVsWbrtrgcjCh4UTtw73d/oNM4=; b=ZyeVYW1nj4tX4wyXFRzCl49qgu8+H6Vw9QsanBPkzQKFCatLnNi9Sl9AFiTSbECTNWksTss+rthFEZKLHheLuzf/qZ7pGwNnEhbIWEU67IJQKfoMYHZPIxmfZ2GdYsEgHLntcF0n11HdfAnGM5qQDIFOJyBf3S4s3XYdjEmS9p8= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 13 Jan 2026 16:00:06 +0100 Message-ID: Subject: Re: [PATCH v3 3/4] earlycpio: lib-ify earlycpio.c From: Alejandro Vallejo To: Andrew Cooper , CC: Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini X-Mailer: aerc 0.20.1 References: <20260113122109.62399-1-alejandro.garciavallejo@amd.com> <20260113122109.62399-4-alejandro.garciavallejo@amd.com> In-Reply-To: X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001F5:EE_|DS0PR12MB8480:EE_ X-MS-Office365-Filtering-Correlation-Id: 7af95650-4268-479d-9144-08de52b47559 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?SWx0R1hMakVvWC9CZDJzTnZtRVVGcUMvTkhQRmtrWXkyNnAvQ0M1blQyRWor?= =?utf-8?B?eVN1bTg2bXp1OWdXUHMwNUlPMEtwMVFBVXRSKzBKeFNjaW9VT2luRVhodnI5?= =?utf-8?B?VUNWekFvRzhZVkpocEFEZmFTd2FHeTRKaFEvL3IwNWV2TTNwRG85T203NmdU?= =?utf-8?B?dTkxYTRic21lczdwTTNNcUdITWJqYmltK0pYK1lQV2hOY3d0OE5pNFR0L0tX?= =?utf-8?B?WjJQUXFxYVl2aFJKekZJQ0JUR0hFdHRqdWV2aDVQc1kwN0k4V0UzOWNndlVH?= =?utf-8?B?VEFBZjJyRFhlZEpKYVhCd0w3Ni9ublp6bzRRTVdIaUVFY1dnbkp6Nk9IbmJr?= =?utf-8?B?VE1oTDdmcDNqdmR1V0JyVkRHTXE1ZnM4T01FcDFic0xUZTY1amF2SDZxVUk2?= =?utf-8?B?RE5SbU0zeVZPZWtkTXlndVRtVDkzcERHS1dIckFKZlo1L3Y1N1ZTVGZZVUE4?= =?utf-8?B?YTlOZlV5ZC9mUmgvTGFIY0hTbGR0Z1FQMEJMUC8vSHU3aXlpc1I4dTN0dGxW?= =?utf-8?B?QkwvZnNOcmlBU0RXY3R0Qm9RWUpwcitlcFBTMEZqMHAwSDg4cjBtUWJwb0Ry?= =?utf-8?B?UjhOaDhaaGg0Vkg3UzZMUytLemxncDFyeGRlYWFNVWFzdnJqd2RhQ0hYSCtM?= =?utf-8?B?SEJqdG5lNFptbW5TWjNHVHVFOGFYQnZ3YXdrWm5MRm8zQVpXaXlONjEvU0p5?= =?utf-8?B?cUZKZVFZWjVJRFRIdy9pcCsrSURUcG1PaVRQYUFaa0t2alNLb081bk1pVGVY?= =?utf-8?B?enZvbjk2cEJhY2tBN2E5MHd0aFZZL0JTb2FTR0Rab1MyYVcxWEIvT3RmYXRp?= =?utf-8?B?VGxSQnZTQkJHcWh6N1JaeXlnWHpKTUZIQ0MvakJ1NXJxUTlKY29xSEpFRVhP?= =?utf-8?B?Y1BMOXYyTmVPcjJEZkNjR25CbEpEQUpveEpHdXBFREZZcU95UW9Pb3daS2pE?= =?utf-8?B?djFCQzdBOWJRSEhpUHY1NE9DeE9NZlp0OXBqWTZNTnRhNkNKVUUrVGl1NktH?= =?utf-8?B?U1BDYUt4UXNVTDRYRHdUVWFweVJ5ZkhjVXZkbTd5Tk91czdQM1JadjZSQXN3?= =?utf-8?B?amQ3b3hxT1ppWWQ0TjN5MGRWR212NElaYmN5VysxQ2xWY1FjR0kyZS9XMlNa?= =?utf-8?B?ekk2UnA3R2g0eVJhQkMvQnplRTBHdHBMWmVlMnBPbnZ6Qm1jOVNRVnZNWk5s?= =?utf-8?B?cEtNYzlBclk2R01Tbm0yelZ5b1NlVTE3M3RvRjloWWMwSEFCbzlGVVdSOHFR?= =?utf-8?B?c0NTNjJxbXp5bmlYL29VbTYxRTJHSE9ZM3F0WmNpVzYva2ZOTHpWTHgrem9q?= =?utf-8?B?WEVwME1DOXl2cVhabkl6NWxtZWRyUDIzTWJxRVZlUldBdi92TVJ0L0M1OXlE?= =?utf-8?B?L1hBN3VNUDlzbm1GczM4K3RERlQycXJpeEd5QnFBMUVXdDVtYmc4NnIyM3RI?= =?utf-8?B?MTFsSDBvVFR6Z0F5aWhmT2ZzQk91WUlMTzc3L29jSitZdnlKQnl1RkhGdFJm?= =?utf-8?B?VjNrd0F1Y013VHVqa0lVRm5wVFhpSkRnM3NMYU9YMFBFWTRWS2xMLzZIUnRw?= =?utf-8?B?TDZ2QXNONjQyUVZjT2swdWVCWllkcjR6V2pwaWxacy9LZEttNFFTTEMrSWpO?= =?utf-8?B?VGk4eExhZUNFRTZza3g5VjdYMHpTSHdVWVNsQlVwdDdUb1YvTmZGRjcyQjdk?= =?utf-8?B?aGI3dTVFWXlTd3BOZTZCdjNHcDJsUkxHcXZOM2w5MVR3Z3NRZFJzN29NV2NE?= =?utf-8?B?ejdmTVpybWsyUEp5TXJCWFcxdS9LcG5tZTFUM1NsbGRrd3RXeXp2VzZuWmhC?= =?utf-8?B?aVlackV5R0xMQWExQnpvdnI5STVYQ1ZpWTZsRHNvb3lqdWpFOVRCYStZcU1s?= =?utf-8?B?Q0F3TWlKc2RqQnNYd0NNMWFzeTBUV01JVVFMdGpNU2xUTHA2V2RnZjY0WTNu?= =?utf-8?B?MDB6NUE0SnpRS3Z2Z2sxUDBlT0QrYVVnMDBpTm1VK05WV3lsZVVnQWROb0lk?= =?utf-8?B?RXJPVzgycVVCNnF0N3FaVm95YjVTV3lXSVc1RFplNmw0Qk1yWUZUa05IL0tZ?= =?utf-8?B?NTArNkhHL2dZNWZzVW5ZemtxKzF4R0VGeUQyNUJLcTNsU0dmeVlSYXNMREtH?= =?utf-8?Q?e3Fg=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 15:00:14.8805 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7af95650-4268-479d-9144-08de52b47559 X-MS-Exchange-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: SJ5PEPF000001F5.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8480 On Tue Jan 13, 2026 at 3:24 PM CET, Andrew Cooper wrote: > On 13/01/2026 12:21 pm, Alejandro Vallejo wrote: >> It's only used for microcode loading on x86. By lib-ifying it we can mak= e >> it go away automatically when microcode loading becomes an optional >> feature in follow-up patches. >> >> Signed-off-by: Alejandro Vallejo >> --- >> v3: >> * New patch. Subsumes earlier conditionalisation of earlycpio.c on >> CONFIG_MICROCODE_LOADING. >> --- >> docs/misra/exclude-list.json | 8 ++++---- >> xen/common/Makefile | 2 +- >> xen/lib/Makefile | 1 + >> xen/{common =3D> lib}/earlycpio.c | 0 >> 4 files changed, 6 insertions(+), 5 deletions(-) >> rename xen/{common =3D> lib}/earlycpio.c (100%) >> >> diff --git a/docs/misra/exclude-list.json b/docs/misra/exclude-list.json >> index 388397dd3b..2b874dfd3b 100644 >> --- a/docs/misra/exclude-list.json >> +++ b/docs/misra/exclude-list.json >> @@ -121,10 +121,6 @@ >> "rel_path": "common/bunzip2.c", >> "comment": "Imported from Linux, ignore for now" >> }, >> - { >> - "rel_path": "common/earlycpio.c", >> - "comment": "Imported from Linux, ignore for now" >> - }, >> { >> "rel_path": "common/gzip/*", >> "comment": "Imported from Linux, ignore for now" >> @@ -225,6 +221,10 @@ >> "rel_path": "include/xen/decompress.h", >> "comment": "Imported from Linux, ignore for now" >> }, >> + { >> + "rel_path": "lib/earlycpio.c", >> + "comment": "Imported from Linux, ignore for now" >> + }, >> { >> "rel_path": "lib/find-next-bit.c", >> "comment": "Imported from Linux, ignore for now" > > Honestly, I think this needs simply dropping.=C2=A0 "ignore for now" isn'= t > going to cut it with any competent evaluators. That would depend on justifications and such. But regardless clearing the exclusion list is a different matter aside from removing microcode loading. > > By libryfing it, it's no longer part of the AMD target build, but it > does want covering by *-allcode. > > Given that you noticed it for v2, I presume there's something in the > file that Eclair doesn't like? I didn't run Eclair on it. It's ignored as part of common, and the build fails in CI if the file in common is absent. That's how I noticed it. I'd rather not gate this particular change on earlycpio playing ball with Eclair. > >> diff --git a/xen/common/Makefile b/xen/common/Makefile >> index 92c97d641e..4fc0c15088 100644 >> --- a/xen/common/Makefile >> +++ b/xen/common/Makefile >> @@ -65,7 +65,7 @@ obj-y +=3D wait.o >> obj-bin-y +=3D warning.init.o >> obj-y +=3D xmalloc_tlsf.o >> =20 >> -obj-bin-$(CONFIG_X86) +=3D $(foreach n,decompress bunzip2 unxz unlzma l= zo unlzo unlz4 unzstd earlycpio,$(n).init.o) >> +obj-bin-$(CONFIG_X86) +=3D $(foreach n,decompress bunzip2 unxz unlzma l= zo unlzo unlz4 unzstd,$(n).init.o) >> =20 >> obj-$(CONFIG_COMPAT) +=3D $(addprefix compat/,domain.o memory.o multica= ll.o xlat.o) >> =20 >> diff --git a/xen/lib/Makefile b/xen/lib/Makefile >> index efca830d92..60cfda4dfc 100644 >> --- a/xen/lib/Makefile >> +++ b/xen/lib/Makefile >> @@ -3,6 +3,7 @@ obj-$(CONFIG_X86) +=3D x86/ >> lib-y +=3D bsearch.o >> lib-y +=3D ctors.o >> lib-y +=3D ctype.o >> +lib-y +=3D earlycpio.o >> lib-y +=3D find-next-bit.o >> lib-y +=3D generic-ffsl.o >> lib-y +=3D generic-flsl.o >> diff --git a/xen/common/earlycpio.c b/xen/lib/earlycpio.c >> similarity index 100% >> rename from xen/common/earlycpio.c >> rename to xen/lib/earlycpio.c > > What's wrong with .init here?=C2=A0 There's only a single string which wi= ll > end up unmerged so I'm not worried on this side of things, but we now > have series doing safety things getting tangled with .init and I want to > get it fixed. .init.o doesn't work with lib-y; only obj-y, obj-bin-y and extra-y. See bel= ow: $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS-y +=3D -DINIT= _SECTIONS_ONLY [snip] non-init-objects =3D $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(extra= -y)) [snip] $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): $(obj)/%.init.o: $(o= bj)/%.o FORCE $(call if_changed,obj_init_o) That's just what I eyeballed. There might be more hidden elsewhere. It might want fixing, specially if something like libfdt is to turn into a library. But it's just not relevant for this particular change where the single contained function is already __init. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Tue Jan 13 15:09:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 15:09:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201903.1517526 (Exim 4.92) (envelope-from ) id 1vfg0z-0003QK-Ku; Tue, 13 Jan 2026 15:09:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201903.1517526; Tue, 13 Jan 2026 15:09: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 1vfg0z-0003QD-I9; Tue, 13 Jan 2026 15:09:01 +0000 Received: by outflank-mailman (input) for mailman id 1201903; Tue, 13 Jan 2026 15:09: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 1vfg0x-0003Q7-Vl for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 15:09:00 +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 c7ee8454-f091-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 16:08:57 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by LV9PR03MB8440.namprd03.prod.outlook.com (2603:10b6:408:377::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 15:08:53 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.005; Tue, 13 Jan 2026 15:08: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: c7ee8454-f091-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lgUJex87QsX2qpzJooBkB7xxKpKr9TZDXuTbzSUWLNEiOCT131Lbv6STmrbk0VUSnR9WLDhph1mV9NDaGvpLdBCXkPp1MKW4lVbwxC73Dh/tfcGJ2li61M/CiCrrvarPgjSExEEx/y43DCZsLeZ7ina2a8aSGpfKp648Ndodk7lxkbxGzdRMlTrDOqmWNqWUBoOeee9JZYaFhcoSGdgJ8+P+Ros3qPn7EJAnbGno+wv/JBXAcKkHRyklKoiu4wG0qCiUmsk4K+/K4SnhfiwNeu1OJZViODyq1Lb5/dir4fkbFGItC7K8e4SQ9LO3xc4LkwQ7YLTptOerTCxzPU+nJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HMDPfp7rSO2Fl2qHgPd3JWOZBGjaTGgH7mazWOQEVE4=; b=N+FRfslUr0wRTsV2EqH+oR4WYv+j9g+ggCdrVvQBNW7DFpAMYTGI8WrtokufQLe2a1HoXcunPcmkgvss1fTxv3dyxQx1KnEru8E8YFnroVrdXZm2kQeQTP1293HM4ikvtUAo+yiDgGy1dtyOJG+8p2Ajqd+nG0aFg4aRXUL+PVanoOTB2zvBS5HtbSQk/QrMd0Plad9zFaBIPKM92L8In3qeF3cQaHR/2Dk2XDxlx73i8Q3Qp8rOcjDrfQsU6JJ4VgeZm/fKKJ8sFS9rYaD/5xHMJN2Zm7bvq9Ezx7fE0Hkw/DSmhSeg8E89ek+eHJX21aKEvZQmxlYhsRh4fP7Kkg== 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=HMDPfp7rSO2Fl2qHgPd3JWOZBGjaTGgH7mazWOQEVE4=; b=u5nYlCGZVgUvcXOEBX7dfCZGw6ZvDRkCD4UibTSuoaxPdwjL2WA9bKNwsKkttVQ3r/ihPFf9LiTCvZe+KXpcxhtK1ooRZN+QGSOm4og8EFdTAdZDQVzU/zZNvLbXorOKmO5+jKQOZam3z2afY4VGP7T/ieMJS2FVc7Aj+tk78GY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <4353bfa1-6fb6-4755-a922-d0330e61fb4c@citrix.com> Date: Tue, 13 Jan 2026 15:08:49 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= Subject: Re: [PATCH v3 4/4] x86/ucode: Add Kconfig option to remove microcode loading To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260113122109.62399-1-alejandro.garciavallejo@amd.com> <20260113122109.62399-5-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260113122109.62399-5-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0119.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2c6::6) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|LV9PR03MB8440:EE_ X-MS-Office365-Filtering-Correlation-Id: df12d1fa-ee0c-4111-f2ac-08de52b5aa71 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?eXBWRnA0UGpqeWJuSU80b3doalZlYmJzR2pxdmRQSTJiUlBGQlFIZXpHeXhQ?= =?utf-8?B?K2RzMUhPVHFYSzlnczQyUU5LTjhiWHFSWTJiTUp6VW1DblpuK3lnOVl3RGRU?= =?utf-8?B?SlZpeDB3dnVkK0llK2JFeEh1QnhiL21DNC9xSlk1NE8zVmJsN1ZpVzVpalBW?= =?utf-8?B?emZMb2JNZEtQaENOc1dSL1MzYStvTUtOcW5KMTl2SFFibzJtRUk4Zy8zS0NY?= =?utf-8?B?TitHOFdNWjN5Zy9rQnhnaUpOWnRTY3VmSTlzMllmWVFDNXp3clMrQjFPRm85?= =?utf-8?B?VnFKbkp0bVlaaS8zOHM0R3pVOXZlQVRmM0Vzdk9ZVGhLRVpOcWZZZDhyQTJS?= =?utf-8?B?eHRFYkdCRTBwVGF0ZjM0bnNJRFJFaXB5K0UzRnp4TE9ELzNxdncwTUdiRXpE?= =?utf-8?B?SjB0SEtyMDFXVWRmeWdES3p0WWl6TS9SMmw1VEdUbXN1QlJsa1JMa040NFNT?= =?utf-8?B?WWptbzRHY3ZVa0FxYXVNbnBaM1E4ZmY0SFF2OG01RmRibUU0T0ZkeE1QV0FT?= =?utf-8?B?WG1ZbVJIM2NNT3RuOUdxTlJ6WDgwSGhiNlgzb3lkOFMwWGFEUUhKNHNla1hm?= =?utf-8?B?SG11NzZCTm95L1diSFhXQzAxY3MxTE1LSDJJOTJJcGRkN3RaU2JFc3E4QnNQ?= =?utf-8?B?S0t6eUQxQlpVbjVXT01YZzI1bG4xTTMzMzlTSDZwT1F4THp5TkRhSzJWMGxH?= =?utf-8?B?TjFmOFVVQVVkUERXSlB5dWFYeVlsQjM3ZXZBRlluZEVoWW84bCsxYU9GRldN?= =?utf-8?B?SE92MWV2Rk10THBPTVBOOHRudWoveTFhTHNvSEprQTk5U0NGVkpGM00rTlIz?= =?utf-8?B?bWZyN0ZEdldGSC8yMU12bU51c3BUR1RlNFRtNGw2YTdNNkpRRmtVbkF3ZHJv?= =?utf-8?B?Z0E1aFhvWnNoSCsvc2ZSZ2dkUkd1bS9qMHdoSzMvWFEwZE1kZ1IxZHZTV1ZC?= =?utf-8?B?emwraWQ0bGQvZ1VWTzFWY3dkcVdpZWdYaWFmSHEyUTRxWjd2bldMemxLUDdR?= =?utf-8?B?ajVCNGlXMUFBSlErSWhDNndQV3VaNUcvdWxuMEZ6V3dscHRLNkt0b2kyYjdn?= =?utf-8?B?VzRPZHdhVitITmU1VFYwN1poWjlaejd3cHQ5ZDZCYjlVUnhla2x3OFpRc0dM?= =?utf-8?B?a0pjRm4zS1VmOUhWMDBLcjl1TlM1eHhFdFAwVko1OE5oRkk3dmk4ZnJuQzF6?= =?utf-8?B?VnozUzg5U1NLNUNMYjFRV1lzcmtDUlBNdjJJUHYyMXNGSldZbXk5ZnRFRkNG?= =?utf-8?B?Qk1saER5Y2NXNE5ibVdFdk9VcGFjeEt0WXdkOWhOVG1pVitmU3MxK3ZNRG9X?= =?utf-8?B?dUJIQnNGbGliQ200MEFVOTRCaXQ5MUtLTTJ2S0VkL1dKSGlzcXZtY3JxbTFj?= =?utf-8?B?UUV6WmtVMzJuRk1aemZLRTVUak54MmpCYUwreWFjOW5VUm5lYVBnOERYM2V5?= =?utf-8?B?SmJVMzAxbzdjMS8zeUFldEE5enQ1RWwxeFh5NGUvU2FkNlRMY21rdklLbmxX?= =?utf-8?B?cUxwV1VMVCs3Y0dPVStRYWxiNSsvT3c3VUZpZjQ0SXpsZHB4cFpXZXJvaksw?= =?utf-8?B?MTNoQ3Zsd3h4K2pEQmQwNDdoVFRTaFRTcjNBRXNXV2RoMVZQcmxvUEg2eEc2?= =?utf-8?B?Qm5wbVB5bENBUmJkT3dBVnNrdGVYR21zdG5kTXB1UzE4WUdKREd4MEhxSElD?= =?utf-8?B?bDRZVXRzTk5Dc1dPN0ZjVmJkakprRnhudytZQUNadFZseXBRRVU3T2V2Qkt4?= =?utf-8?B?bzJHTTVRTmQzbzhCM3JFU0duWExQUEw1cEtFbzRBeERuc1ZVUG5pSE95cTlY?= =?utf-8?B?ejR2MzA4VENtUDVjdFM5MkJVQlJUVmRvSjM4TUVxRllkb2lYclNDN0Frcm1Z?= =?utf-8?B?Z2hoNzVGd2VxZWt3ZlJVL0tRWUFkZEdYN1c5Z2t0ODEwR2RBTG55elFYaXNj?= =?utf-8?Q?RZc1Rpn5Puqfz880CNFeBEWhgntZ4RAN?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TzdvUTNpM0NoSWY2TE1kZzR1MnBBcnZ4aEtJZkRyM0RQS0pJbW1aL1F5eU1T?= =?utf-8?B?bHcyLzYxbXhxNVdqNG9vY1VQd1ZLZVVzd2FXVFZNa2dXdDl2dXlDamliT3dx?= =?utf-8?B?YVQrQzZDM3J2TmVDeDYwT2dYTGZOcFpWRGJydW9ocFVpMnhIMmRPalhkUFNZ?= =?utf-8?B?cGRsaWNHNXljV3M2RDMwTkk3VlBvd2tlRHI0czBHTDA1NGNlb0RyK21VYUhR?= =?utf-8?B?blNXdURHOGNDRHVZNnB5c3hYNXhpZGpyL3hSTnpzeVcvTFYvckViUmxDNURy?= =?utf-8?B?eGVoSU5wR3FmeUs1UjJFb1pOQW5wMjVLTkVKREhzbXNqODJFaCt3dnVjZFRJ?= =?utf-8?B?aGl0YVcySG1MbXg0dFJWRjhYOFBWN1lQeDdzMmhBUUdkdmhCMGU5RVVOZXI4?= =?utf-8?B?Rlp5SkIyb0luU0pGWkRsQVdPcVNVbVU3K1AxeEJXTU9KV1JvcTZCRk05UlM4?= =?utf-8?B?eW5UNDluOThjSU93S3lLdVRTbHlaOVZoL0FRS0NERTEyazVKdGI2T1l3Wnlt?= =?utf-8?B?ekZTWmx4UW1DY01IeGFaLzczZm5qYjdxUzQzMVZZU0J1am91blZLL1ZBQkVJ?= =?utf-8?B?L3YxaG0zY3BPS1QzZllzRFRTa2VhYTJtdVJuTVlTRUd5OVZ2ZkVGbHpNNFpX?= =?utf-8?B?ZldRNDdPbzVNL3BCS1V2UE1QWjRaQUlDSW5GWWRYdTJPOW1jTUNKam1NZFow?= =?utf-8?B?TUY2YUNMODA1TXZDbTlmU09ZN2pPdnNIdWh3NHo0VEdkemREcnhFL0gvUzMw?= =?utf-8?B?c2RFMEIwV1k0RG1qcHhNS3BsSDNoWDZvaFhBMWw5S3JnM3dKRXFKOHg2bjIr?= =?utf-8?B?K3hUS2ZrTXdrR1NoWkNkRzJuRlBUZkVCQ3Fud3ZsbEFiek01ZktiU3RkMmhl?= =?utf-8?B?K2lCM09KTjcxSk9IbFhkMVdFdXlmQ3hzSXZjKzM5bi9GbmZ6OHFhTTd3NmVY?= =?utf-8?B?RVhlem1ycS9YQ2N2di8zYTNFSXJkdDAzTWhnYThyOHUwRjdrQzZVSTlOeUFl?= =?utf-8?B?RWlNOWtrN0FUY28xVjR3S0hRTnplTkRrR01CVWxzTE4xZVJJUUhCYUNqbms0?= =?utf-8?B?eE55NGkzWjV3SjZaYVA1bWR5Wk12SnZkS0pmWE1pUnorbXQ4c29oSnZOSlZy?= =?utf-8?B?MGNxUWk1R1RodWFCZ2tCTWpGR0w4aStmdUZVMS9pQ3krc2d3ZnFHQ2twRm15?= =?utf-8?B?ZXRvaUU4U20wcXBnUVpzSHJJeU1udDJIOVRtcWxXYzRXbExwMkRwNFlBVlJN?= =?utf-8?B?dHltT2dRMXk2RGN4Ris5Nm9aVTVqRTlDWGVoTncxbmZnZTFEdnNHVUlSY3R1?= =?utf-8?B?VERLWDM0WkUyTjdHODZyQitVK3FBdzQ0MDh1UnN0SEpOUWltUjg4cnNlNDBn?= =?utf-8?B?WWU5dkc1WEdBb05IY0htZnJmekg1b0tCL01zYVlyWU1ZMUlKWDVON2Z4bmVQ?= =?utf-8?B?NzNGN2xPY1pib1Y5ODU1eWFGSnZxeHVhV1ZHSWxjVTBVQTZxWmNpQlMvTUhL?= =?utf-8?B?WkRTWnMwaGVXQW9YdldjME9tWkdjWkNkaERTOEhiQ1FyWm5pN3pPejVHMEVW?= =?utf-8?B?dXB1THhERFY5Z0Z1MVorNDlmdjR3Y1FuZGE2dDZaSVVkT083R29nMGIzejhm?= =?utf-8?B?TytJdHdFemFjZFJPMUVqNFdxMnppeTd1UW44dmg1UmdaWk4zVXgyOWw4eWxt?= =?utf-8?B?UEl0RnRzRGJhQzNYUTg4RVg1a05xWitTaGxTUWI1WUhzYVF2aGYwanRXd3Zn?= =?utf-8?B?TktWL3RYci81YndkcHpTMTQ2UWVDNERtNFo2TkhUQzBtdjJ3NnplODVqWlZx?= =?utf-8?B?Y0dJYkEvYnFYSSsxeEh4bU1zRHRlWHRub0dmMlBUUUV4M1pLK05vem1WUXJE?= =?utf-8?B?MnYxS0ZkUDRoU3BEcXVpS1RobDdHMVV5a3loTlVUWlJ3bkhmM29yUktBYTJX?= =?utf-8?B?VDh0cmZEWHgrNXBlNFN6dGlYbTVjSjhBalFoaXU1MVU2K1ZqSTd0aHJ2WDE4?= =?utf-8?B?MmdibHNHMDk0YXptUklyODZhcWg0LzRJbDlsQUJwdXg2eG5iaG1sbzVITWI4?= =?utf-8?B?dU5BdUdGenVPeG83YnZYT0RKbWYzZ1dpYThVa1cwY1kzRFNiem9sNVp2M3hs?= =?utf-8?B?d3JaOENObGliYUJvVHFrL3R0L0hVV0k2TzIweFdJWU83eG9GcG82OEh6SElN?= =?utf-8?B?Vld2bE1wTDk5V255M0VDQWo0c2pTLzRPYWpMZ1pBVWV6MVpudTBSY0FFMWN5?= =?utf-8?B?ZFdxbmR4ZjJJK0Vxc1Q2MDFJVGpQRVRPbm5PUlRlVFdESmM3N2pVd0hnMEtQ?= =?utf-8?B?MmRPUGlEZWdtV1lhYWIrKzhJUUxUdnI0L2pmYUY1Z29nV2lZeWtndz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: df12d1fa-ee0c-4111-f2ac-08de52b5aa71 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 15:08:53.6253 (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: 9ZdehVhL8pNfXX31EpuI9pu+DqdIOOVcy/IGM44bC+OaGXT+/B6Lq353Bbn0q86+RPQ7vF7nGGeDU4lkpDvTCTA8LuLVr3oS9IJv1QlMovY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV9PR03MB8440 On 13/01/2026 12:21 pm, Alejandro Vallejo wrote: > Amend docs to reflect ucode= command/stanza depend on MICROCODE_LOADING > being set. > > The new MICROCODE_OP() is a conditional setter for the microcode_ops > struct. By using IS_ENABLED() there ratehr than ifdef we allow DCE to rather > remove all statics no longer used when microcode loading is disabled > without tagging them with __maybe_unused. > > Signed-off-by: Alejandro Vallejo Reviewed-by: Andrew Cooper with a couple more minor points, all of which I can fix on commit. AFAICT, this can be reordered with the earlycpuio patch 3 ? > diff --git a/docs/misc/efi.pandoc b/docs/misc/efi.pandoc > index 11c1ac3346..c3fb1f3a30 100644 > --- a/docs/misc/efi.pandoc > +++ b/docs/misc/efi.pandoc > @@ -104,6 +104,8 @@ Specifies an XSM module to load. > > Specifies a CPU microcode blob to load. (x86 only) > > +Only available when Xen is compiled with CONFIG_MICROCODE_LOADING. enabled. > + > ###`dtb=` > > Specifies a device tree file to load. The platform firmware may provide a > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc > index 15f7a315a4..866fa2f951 100644 > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -2748,7 +2748,7 @@ performance. > ### ucode > > `= List of [ | scan=, nmi=, digest-check= ]` > > - Applicability: x86 > + Applicability: x86 with CONFIG_MICROCODE_LOADING active > Default: `scan` is selectable via Kconfig, `nmi,digest-check` This isn't actually how we provide such information.  It's usually a sentence in the first paragraph. diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 50d7edb2488e..5b6ff94f441a 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -2751,9 +2751,10 @@ performance.      Applicability: x86      Default: `scan` is selectable via Kconfig, `nmi,digest-check`   -Controls for CPU microcode loading. For early loading, this parameter can -specify how and where to find the microcode update blob. For late loading, -this parameter specifies if the update happens within a NMI handler. +Controls for CPU microcode loading, available when `CONFIG_MICROCODE_LOADING` +is enabled.  For early loading, this parameter can specify how and where to +find the microcode update blob. For late loading, this parameter specifies if +the update happens within a NMI handler.    'integer' specifies the CPU microcode update blob module index. When positive,  this specifies the n-th module (in the GrUB entry, zero based) to be used which is the re-wrapped version of inserting ', available when `CONFIG_MICROCODE_LOADING` is enabled'. > diff --git a/xen/arch/x86/cpu/microcode/amd.c b/xen/arch/x86/cpu/microcode/amd.c > index 71b041c84b..86706a21a6 100644 > --- a/xen/arch/x86/cpu/microcode/amd.c > +++ b/xen/arch/x86/cpu/microcode/amd.c > @@ -561,11 +561,11 @@ static const char __initconst amd_cpio_path[] = > "kernel/x86/microcode/AuthenticAMD.bin"; > > static const struct microcode_ops __initconst_cf_clobber amd_ucode_ops = { > - .cpu_request_microcode = cpu_request_microcode, > + .cpu_request_microcode = MICROCODE_OP(cpu_request_microcode), > .collect_cpu_info = collect_cpu_info, > - .apply_microcode = apply_microcode, > - .compare = amd_compare, > - .cpio_path = amd_cpio_path, > + .apply_microcode = MICROCODE_OP(apply_microcode), > + .compare = MICROCODE_OP(amd_compare), > + .cpio_path = MICROCODE_OP(amd_cpio_path), > }; Reordering cpu_request_microcode and collect_cpu_info like before makes this easier to read. > diff --git a/xen/arch/x86/cpu/microcode/private.h b/xen/arch/x86/cpu/microcode/private.h > index e6c965dc99..1167b79db1 100644 > --- a/xen/arch/x86/cpu/microcode/private.h > +++ b/xen/arch/x86/cpu/microcode/private.h > @@ -93,4 +93,6 @@ void ucode_probe_intel(struct microcode_ops *ops); > static inline void ucode_probe_intel(struct microcode_ops *ops) {} > #endif > > +#define MICROCODE_OP(x) (IS_ENABLED(CONFIG_MICROCODE_LOADING) ? (x) : NULL) > + This wants /* Aids dead-code elimination of the static hooks */ and wants to be up beside struct microcode_ops. > diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c > index 79bb99e0b6..a55060e662 100644 > --- a/xen/arch/x86/platform_hypercall.c > +++ b/xen/arch/x86/platform_hypercall.c > @@ -309,22 +309,30 @@ ret_t do_platform_op( > > case XENPF_microcode_update: > { > - XEN_GUEST_HANDLE(const_void) data; > + ret = -EOPNOTSUPP; > + if ( IS_ENABLED(CONFIG_MICROCODE_LOADING) ) > + { > + XEN_GUEST_HANDLE(const_void) data; > > - guest_from_compat_handle(data, op->u.microcode.data); > + guest_from_compat_handle(data, op->u.microcode.data); > + ret = ucode_update_hcall(data, op->u.microcode.length, 0); > + } > > - ret = ucode_update_hcall(data, op->u.microcode.length, 0); > break; > } > > case XENPF_microcode_update2: > { > - XEN_GUEST_HANDLE(const_void) data; > + ret = -EOPNOTSUPP; > + if ( IS_ENABLED(CONFIG_MICROCODE_LOADING) ) > + { > + XEN_GUEST_HANDLE(const_void) data; > > - guest_from_compat_handle(data, op->u.microcode2.data); > + guest_from_compat_handle(data, op->u.microcode2.data); > + ret = ucode_update_hcall(data, op->u.microcode2.length, > + op->u.microcode2.flags); > + } > > - ret = ucode_update_hcall(data, op->u.microcode2.length, > - op->u.microcode2.flags); > break; > } > Both these hunks will be smaller as:     ret = -EOPNOTSUPP;     if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) )         break; and that's the preferred style too. Otherwise, Reviewed-by: Andrew Cooper and I can fix all of these con commit. AFAICT, this can be reordered with the earlycpio patch 3 ? ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 13 15:12:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 15:12:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201911.1517537 (Exim 4.92) (envelope-from ) id 1vfg4T-0004uc-4P; Tue, 13 Jan 2026 15:12:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201911.1517537; Tue, 13 Jan 2026 15:12:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfg4T-0004uU-04; Tue, 13 Jan 2026 15:12:37 +0000 Received: by outflank-mailman (input) for mailman id 1201911; Tue, 13 Jan 2026 15:12:35 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfg4R-0004uN-MO for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 15:12:35 +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 491a87f7-f092-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 16:12:33 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-47d3ffa5f33so34851195e9.2 for ; Tue, 13 Jan 2026 07:12:33 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d8384646fsm376030365e9.15.2026.01.13.07.12.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 07:12:32 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 491a87f7-f092-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768317153; x=1768921953; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=k+AX2P/aEwR6Jzik9nbZgyFYQIUWOTVqxYkfzWuPbRA=; b=aW6cQX5+UafDEWoz0Kyk1H8K+ckPHulJpR7C2mBHdGobZAqN1ZkeufJh77aPP1gTct xfSx0/V6d8aYWmSIUxpjlC4YlUStLgpGJq74bCfSYmZAvRZdYdv0KQ02Ra0OwqwYuDIs SHjV21ffILYGJyjVSK3QVDzAJc16Bf08tks9+x14+d+o5Ql+/FgIQ/ynxKjsiTemZo3g b6sMd6iB7zuMc82ZVNnbIn6brpNFF+iBLQet8S3kVxrHJaUXsqvQLW2CZlv7nN/bgBSa Vruwb/cIo2cxYmn5UzMH++lIzjSAoF2CtxlmpvHHEqgmkt85rR0CCp0pN4bTw6TFJdqv Qing== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768317153; x=1768921953; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=k+AX2P/aEwR6Jzik9nbZgyFYQIUWOTVqxYkfzWuPbRA=; b=w6DuOpCVziqkPb5h2JypqQADavr8a3zCRBxKg145y4ajPLzsNVmQ+nMg/RnA0wXldX EUYFZmghHQNLFiCC76kcMrbBwcDu+qOwjBq0tNKRS5w6YPFiYCJ/4OtyCu++hyAR7JOu lO5i+RHo6llPZe7M2gooIif9d1cbcX+i8rke5abZxISDuUDxI+Gw4PxBlPyq2dVVHRET k00X7ltZnup/D6tp1Yq9otE5ahS2pCX0Uv+2fZUNiKIyK56G95bb5pSsSuAWbn3lllhv RJR3OtKhCdYvaWV3plKi9hLvK46kyEKVPOVr8LBLZhD8KNEMDCQJIPsRYnyXE5sVcSvH Z/mA== X-Forwarded-Encrypted: i=1; AJvYcCVlyPYB0ecSVfXyp9bVhp7RPpdJrGPjCaaODe7YzWutbSEnmBWcy/qREGsfTyKtlYEG+KokL+ZhWoM=@lists.xenproject.org X-Gm-Message-State: AOJu0YzoaX8lkbkCnJoEsd5V++lmmb3ReWZSc/tcbK2xROyIAt2Ka/83 2ks3KwLVS5VjySs6F5/2v4Z4RYG6WgqSf5yH4GfAQg+ADzCVlSGr/K+4v56TCFXq3A== X-Gm-Gg: AY/fxX75865XdbghrbebHoAPfudrJhHHEVAhP3sgRxdIpVghwl+ojVCov/Aq5hmFO0a jaSEDu+GR5neuNcGz0UwoZeCdmBhvfr21EXVj9JhiZRqoBCL34GGpUJcljFXLug8P2nEfdxYXF5 MwY+OEtsEW+kJdVrcaihm7jbwQZNRRu7NJsd0NmfeeRhEPOvA3CXquPwyHwRgXxg/3WtJmcKIuK daxyqQZMQZucleekXy51MbROvHMnKGrSq69J7k5jJh2RwlfKq7xzO7dWacqATyxMTmc6NZLomaG ouu1ivUj3RA0PG+v4yC54ISDGefxm11Rehhbpn4GzeD/mTrSuIgaBf3c1ylaGwZpATdorziU4QK CTDdjYAhIGjw7ylaPCZI/DXUc4Y9wdOETEDdLzWmMSgp3tUF4IHpkweClYgue3lscUhGC92pbeq sxvoEFMhplJv9V7ekj49OJQ/AHiKDJ08ZH7miMaYEircpC9fIifG2usB8Bzhkx3goKL0FMt3Dxr N4= X-Google-Smtp-Source: AGHT+IEBLZpeMjeUUF6BWX/ud2bEiNAeU5uwc3qkou6XLPsDMV8XJTFg3J+Idrh6K+MZP4pviQ0n7w== X-Received: by 2002:a05:600c:3b90:b0:477:a02d:397a with SMTP id 5b1f17b1804b1-47d84b26cccmr232837135e9.2.1768317152576; Tue, 13 Jan 2026 07:12:32 -0800 (PST) Message-ID: Date: Tue, 13 Jan 2026 16:12:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 08/15] xen/riscv: introduce vtimer_set_timer() and vtimer_expired() 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: <8cd3efa488b3da2a6751c92d20bbfeb87b3ba39a.1766595589.git.oleksii.kurochko@gmail.com> <4e18e4fc-de62-44fc-8ea0-517f6c7ef47f@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: <4e18e4fc-de62-44fc-8ea0-517f6c7ef47f@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 13.01.2026 15:44, Oleksii Kurochko wrote: > On 1/8/26 11:28 AM, Jan Beulich wrote: >> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>> @@ -15,7 +17,9 @@ int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config) >>> >>> static void vtimer_expired(void *data) >>> { >>> - panic("%s: TBD\n", __func__); >>> + struct vtimer *t = data; >> Pointer-to-const please. >> >>> @@ -37,3 +41,27 @@ void vcpu_timer_destroy(struct vcpu *v) >>> >>> kill_timer(&v->arch.vtimer.timer); >>> } >>> + >>> +void vtimer_set_timer(struct vtimer *t, const uint64_t ticks) >>> +{ >>> + s_time_t expires = ticks_to_ns(ticks - boot_clock_cycles); >> boot_clock_cycles is known to just Xen. If the guest provided input is an >> absolute value, how would that work across migration? Doesn't there need >> to be a guest-specific bias instead? > > I think that I don't understand fully your questions, but it sounds like it is a job > for htimedelta register. Ah yes. As said, still learning RISC-V while reviewing your work. >>> + vcpu_unset_interrupt(t->v, IRQ_VS_TIMER); >>> + >>> + /* >>> + * According to the RISC-V sbi spec: >>> + * If the supervisor wishes to clear the timer interrupt without >>> + * scheduling the next timer event, it can either request a timer >>> + * interrupt infinitely far into the future (i.e., (uint64_t)-1), >>> + * or it can instead mask the timer interrupt by clearing sie.STIE CSR >>> + * bit. >>> + */ >> And SBI is the only way to set the expiry value? No CSR access? (Question >> also concerns the unconditional vcpu_unset_interrupt() above.) > > If we don't have SSTC extension support then I suppose yes, as CSR_MI{E,P} could > be accessed only from M-mode: How do M-mode CSRs come into play here? My question was rather towards ... > (code from OpenSBI) > void sbi_timer_event_start(u64 next_event) > { > sbi_pmu_ctr_incr_fw(SBI_PMU_FW_SET_TIMER); > > /** > * Update the stimecmp directly if available. This allows > * the older software to leverage sstc extension on newer hardware. > */ > if (sbi_hart_has_extension(sbi_scratch_thishart_ptr(), SBI_HART_EXT_SSTC)) { > #if __riscv_xlen == 32 > csr_write(CSR_STIMECMP, next_event & 0xFFFFFFFF); > csr_write(CSR_STIMECMPH, next_event >> 32); > #else > csr_write(CSR_STIMECMP, next_event); > #endif ... what if a guest did these CSR writes directly. Besides intercepting access to them, you'd also need to synchronize both paths, I suppose. >>> + { >>> + stop_timer(&t->timer); >>> + >>> + return; >>> + } >>> + >>> + set_timer(&t->timer, expires); >> See the handling of VCPUOP_set_singleshot_timer for what you may want to >> do if the expiry asked for is (perhaps just very slightly) into the past. > > I got an idea why we want to check if "expires" already expired, but ... > >> There you'll also find a use of migrate_timer(), which you will want to >> at least consider using here as well. > > ... I don't get why we want to migrate timer before set_timer() here. > Could you please explain that? Didn't I see you use migrate_timer() in other patches (making me assume you understand)? Having the timer tied to the pCPU where the vCPU runs means the signalling to that vCPU will (commonly) be cheaper. Whether that actually matters depends on what vtimer_expired() will eventually contain. Hence why I said "consider using". Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 13 15:20:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 15:20:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201923.1517547 (Exim 4.92) (envelope-from ) id 1vfgBk-0006gH-Pl; Tue, 13 Jan 2026 15:20:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201923.1517547; Tue, 13 Jan 2026 15:20:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfgBk-0006gA-Ml; Tue, 13 Jan 2026 15:20:08 +0000 Received: by outflank-mailman (input) for mailman id 1201923; Tue, 13 Jan 2026 15:20:06 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfgBi-0006Zt-Jo for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 15:20:06 +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 554d04bb-f093-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 16:20:04 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DM6PR03MB5275.namprd03.prod.outlook.com (2603:10b6:5:24c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Tue, 13 Jan 2026 15:20:00 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.005; Tue, 13 Jan 2026 15:20: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: 554d04bb-f093-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lwD0SjS28+HbEbFZk0cIs9ZgaTSObrxynUy4kA/tXVxzxCPmxW4sFOlxqgCSj0vm07Yh4cCA2wzMZhJsDonLC8KkPP3Bs8AXvIBNESz6og/lkQWqjIShQTvhKO+DblfQSGLrjpaHTSvLWZeLJ+Pdt4UNPwM+38e+mKDSZ86cLHSEJh20uUGFEEnAIMvO4DiN2emuXAedfT0OPc2uWcg+nFRLxrtefz7j8vtHRYrmfwCXNtGntdfFWNdixYNB+KUyYHoUBVpo2PXmHAiV7oi3w8pBLbutnl1Wi+YRK8wukoEHlkIpeMnoBCoYkETz5gh9qzGOUItjTcYWkkj2B58fxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Et3bOKdU5PKLrpHylRAxFOQ4KZufKx7MSU6LrFLEpRY=; b=DAvi1zfkVwDWNnGYBZfRuOpCBZwSJaISkTJ+D/tQlJxi1uhLGcV+vPPHDiLgNfHGO6g4QQkFFDu+1/syxuADoxjaoBMct1UKBFAGxJFn5124jAakVtdX8bGMinXEfzFY/5C048K2WvGjOX5KzJUD1zVgxnn2VH25Asgh/MPugTzzNRMFYzjaI80eo/cUoW1kLAojoR1sbxQ3iDV+NIKTtP51CfLR5hiqEYCLIPSHPgHfVivK4a5gg0aV0dFRNWPhmzBy3UDwQmk3Lb2aATkOPK2TNg7FJk2/FiM8v1w2IfjdPMJOGllLd6fmDO+pY60rmUV2eFbaUUZTfWHPj5Wf0A== 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=Et3bOKdU5PKLrpHylRAxFOQ4KZufKx7MSU6LrFLEpRY=; b=aW5uKVx/Znimt0yJ9h+Dv6y0WOmYbBBVuKSlv4okuAR4y6IbGmMIlriCW38lC4Ad1c/7PHjKp58Us1Tb71slcIEhCz0HCkPrDl272U1Zh+eMThnV4X4g3M1eRCA5Kj+uu8pG/Ymvu44ppMc+cAQjngyXMkGSvFyVKVmMu9pPc9w= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Tue, 13 Jan 2026 15:19:56 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Subject: Re: [PATCH v3 3/4] earlycpio: lib-ify earlycpio.c To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260113122109.62399-1-alejandro.garciavallejo@amd.com> <20260113122109.62399-4-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0109.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:c::25) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DM6PR03MB5275:EE_ X-MS-Office365-Filtering-Correlation-Id: 0719d717-30bc-4a5c-7181-08de52b737df 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?YzlnRjROdnBsMDlNclVDRXVuUHo3S1lOVldLdXVQQzhvKzZwMVNua1I4STEv?= =?utf-8?B?TkVhUzdQaFMrSzE2Tlh4MERncWlpWWNVaVhJdVBUai9RWFNZdXVCZU5xcVlo?= =?utf-8?B?RVBZcFhXYUVRcGpRSlBNK2pxL29KRS9DQmhIcC94VllOc3BoeDY1QkVkbEdH?= =?utf-8?B?VUdPeE1XSmRPRDRySVdHb0ZheU1jUVlzNlpvVXlvNnBMcFJTTy90WWxqUm5q?= =?utf-8?B?ZFVnZmNqSWdDSFRiQmcwbStVZDRrR1V0VmtUdUx6UmNkOG1KaFRvSzBOVEVy?= =?utf-8?B?cnUzQ2hlOUJxZVlOWDdEY2R3ekVINFZRM2NKL0l2OEdlV2ovdGtCTWdoOEti?= =?utf-8?B?cmkwYndzaGs2bU40NWxXS0FRSGNiNDE5U2dUSCtUc1o4bUpNa09rOTJLMVFL?= =?utf-8?B?NGVPSjlRMnl0bGRQU2Q5eEN0SHVwODlpWjBoSWRJYXdmNG54ejQwbElpQnJF?= =?utf-8?B?MFpGSHVmRU43dWdPNU11ODM1djQwYVVSY3l5b3hJZWU3c3lkaFVlMnNjMm9N?= =?utf-8?B?eEI5cjNvZ2tweXBqM3VpbEQ0TTJCbjhTU3VwSWV6OGl5amZHNXhyMW94blFh?= =?utf-8?B?ZUUyN1RNSkk3NzVOd1hvMlNrS3cvWXg4aW9SUVc0RU9DVFdTNW9LWFIvNWo3?= =?utf-8?B?cENqUDREaUZYUlNYMGhTMk5ueGwrY0x5bEE3ZXJGTERxcW9WZEpDRVNKV3Bm?= =?utf-8?B?ejhuQXpwS2kvaFd0TFhNQURKZFlQQ0hjSkJmNHREMWMrT0JDR1ZWL0VVZ1lo?= =?utf-8?B?N1Q5bDAwOXBwS2czajNrV3JHTjlLZlUxSHFteCtOZTUvei9Rc3M4ejhucHBZ?= =?utf-8?B?YTNEYy96Tml3OEtEWDhhSjNJOEhrUXVZN0dJZ2pOS0Fsb3hSUHRYSW5CQmli?= =?utf-8?B?T0dRREw2OWlWVXdXS0hMbzlZSU8rK2N0dEZYNzVnanc5aXhDdlUxenJWdVd5?= =?utf-8?B?QSs2TVBGUjJuMkRsMjRPN0s0U0VWNmFmbkEvVSsvbXJ0ODFNQjhDbkcvY1Jk?= =?utf-8?B?Zk1PZ01ZWDBOTUNuRUNMT0xJdG1uYkV0bEk5TjlVZkZobnFzNnJyVENZTGlV?= =?utf-8?B?aHgybUQwaTR6b3h1c2ZsSXVJNFYzVE1Wem1DNEtpUE9DZUMxSWpmZkxVOEUv?= =?utf-8?B?SnZ2RzFNS0dPcU5TQ0dCLysxYkZEbzR3MlRLcHZ4MkpZcjRrd0wzcDZlVENI?= =?utf-8?B?MVpKaXBZcUIzZHhwSDB2RGxlaUpac2wzNGdObmY0cS9GZG9rNnB4d3RtcW5U?= =?utf-8?B?aVZMVWNVNnRJT2dYbHpPalVKb01LZFlra2NIalVUcHhVclo0c3V1bVoraVdx?= =?utf-8?B?cnM3Z1EvZmdBbkZpUVNiaDZvUlJxQkQyZ0JiaHl0WjJSM0VySklVWENBWGN0?= =?utf-8?B?VnAveGRnVkF3ZUZ5SnVjQlBsUGYwdnIvQUNYa0VQeFU1TVpkRlFYNmdUOFd3?= =?utf-8?B?YU13cnRQY3lkQmtQbzdraWNUMG5sN0VuaS82RWcvcmRxT0JSajZzQWRKMFZ5?= =?utf-8?B?TUNPcmFHOVJsTkc2bEluWTRHS1A3bFBTMzF0bmJRRndkZEpzZHlPV1MrbXVQ?= =?utf-8?B?RHduUEp6MVJPR2J2NFJEdTZPTEFTM2hhTHFvZ2YyTEsxWm5LNjRqM3hGaS9o?= =?utf-8?B?Nlk0YXl4MjcvYVpKZ09LRnRpeGpPeTZlNkdDVWtoR3dwSzRHQktOVVVNSGl0?= =?utf-8?B?Q1cvdDREWjc4bGpZTnhhaHdOamFUaHprUmxzT1NGTkhnRnRDMk1peThVZUtJ?= =?utf-8?B?K3grQTA4U1NLNWk2N3dIVXdzK3hGODA5RFpQWiszRFdCd1lpYklHQ2VCU25M?= =?utf-8?B?QXBodzdHUUZJQ2hQZEExWndJRC9udU52YXAyVmdBTFgwVmxpYWNwbmptcER5?= =?utf-8?B?THM0SjJkeVVCRkl1ckdqTWJHQytUUlYxT2pTQm5NK0k4cHFtblZyNFhEZlZk?= =?utf-8?Q?6qxf3jELIrDGJ74uhvJdtcCpl08zzsY1?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZGpIZWZnUUgxbm1qZjdVMCswUHoraXZWWExRbkpKOUQ5OFlsRHhwRGhUSHhl?= =?utf-8?B?eHViMC9qMWlRNElDTDZLVUZhQjdNemZrVVQ2QUhPODVKRkJaMVhtMHB0K0dv?= =?utf-8?B?Tm0zaHdwTzhlbEduLzRUcXQwSld2Q3ZCbjIxQ2VuMGhxVFJmeDNoSE1XK1Ri?= =?utf-8?B?b0pJZ1orN20vdUJCS1pLbGc2WDJCQ1ZNYVpCQ2hWNlVaM3pwYmdNMVdkN3dJ?= =?utf-8?B?UXhJc0QwN0kwSHAzbWJlUVFya2hvaHRVMWpreHZSQ0hyRXNCcG53S00wMWVU?= =?utf-8?B?bWE1R1lVeGVQandpdHowNXk4Ym1MTDBvRldaQksxTWNYVk9WYzVlazhVTmtv?= =?utf-8?B?UlJzMDNsdmR5bDA3UTYwUDVoL245dGxsdkJGazNFV0lSWjNLWWl6Wm5mSVB4?= =?utf-8?B?V1RjUWs3SThQUHNmb0tiS1ZHQTdxMzlDQlByaVVrdTgwWjBVN1ZuVnJTRURP?= =?utf-8?B?cWxyNHd3VWI0VUx3clpBdFk5cmUzWmhNbytTN05QZStWMkgyZyt5TXJuTzB0?= =?utf-8?B?ZStNK1dHcFJ3T1pMaDFuQ0RkK3dCai9XajE5QjlKQkYyUldRdFpTemVwWFh2?= =?utf-8?B?NFhwczRueEFzS042aTJ3elArUXdjdHU0dDdqVHNCOUJkZG1RRTUrUjhVOGlS?= =?utf-8?B?UnhwUk95ckdhM2pENW5ZOEhlVGw3MUFrSjQxalc0M3FFQ3pGcEdVUVkwRkZ5?= =?utf-8?B?Z3VhWE5EUFJVWFcxVEZqSy9yLzR0ZlM0bmY5bVhuUkhIUGp0NVpaTHVnZ1FH?= =?utf-8?B?R3pPNWtDektENCsyWlV2TnVuWEhMOHY4cVBzTFNsZk9JaElLVU9pejY4c0ww?= =?utf-8?B?MzZZSFR2b3lEMy9LdWRkQmpxZUNESU1CaVB0WEhzK0RWcHRUQTRzS2k1L3Zk?= =?utf-8?B?a2tjMmlOUHM5TlRhdkd4V1o4MWdJTUZtR0VUcW05MzVjYnQweUpicFV1b3JK?= =?utf-8?B?bEs2b1A2eDBGTjVId1EzNVJPUUtYY2ZHcUlLTFJIclZhM2s1TE55UnN5aXY0?= =?utf-8?B?bjFEYk5uQ2Z2SnVHamRIQy92WXZmS1hUTHVOQ2ZpM2RMek5SKzk4N3d5cklZ?= =?utf-8?B?Yi9OcGpBRFkvYWtjZTY3ZFE1cHhKcjRiNS9Ta1R2ZGpES1hrYVVqM3YzL3Ir?= =?utf-8?B?N3VIWWpoSC83TEUwRUhTd3NTZVpPVmNQcGxxOEFrN1YydDZrSjBFUU81Y1ZP?= =?utf-8?B?c2p4QVRuRjlzcDFCRVltQ2lGdE1QVDhiNTdueCsrZnQzbVI1d2IvZE95Z1Vp?= =?utf-8?B?eEhMUGc3Y3ovU3RvYi9qSFlrNW4wZFhPcWpJUWdWcDZTTk5HRlAwRnlNZXVm?= =?utf-8?B?VDBwRDFCeDFuOENWWUpJS1dFQURuYUVDT3cvMUxhREFpTUxXVEpjYjQvaWYw?= =?utf-8?B?TEJlZEJsdU1jMTR1OWFXakVFS0N5L3J0bmY2WGRyOGYySVZsZmZsZHNMTmtG?= =?utf-8?B?QXA4L2U5QVlZY0VpME9YWDh1S20rSUt3K2pFdlQwcGdDdm1xSjZFZHh1TFJW?= =?utf-8?B?bzNBQ1o4OUI0S2hXZXpkWExLcHpHa3MzODhNdExVZXY3N0ljYmRuNFNmeTlq?= =?utf-8?B?OXBPdXphU3RScmxaUGdTYThvWkcweiswdXRWWGdwZDNkOHNSYzV4aUZBYnAx?= =?utf-8?B?SUtBRmFaZTZYdStOMXpsekU4YnVtM1VUbmgzaUFmYVdPa0MyK2E5VDErdmh3?= =?utf-8?B?Y2U0Q0RWNUpIaUsxQTZ2eERwcFNyMGNta1VxZDlBTkJ0WDN5RFNsMFZCWHNh?= =?utf-8?B?L3Q1dXEvNTYyZ2Z3YWt1TzBkakdPWFNkOFdZWWJYZDJMNG9pdHVYVmxJYUxO?= =?utf-8?B?TzdjOGR2WnFYMHpVeHRQUTc0dVN5TG5XVy9vTGR2SElYdHVlNzdLc2R1NmJy?= =?utf-8?B?eHJCbExPTTkraUdSZU0wb0NCeTJKaGtMUjQyQmF1ZlRUanNQM0pRUU93eGlR?= =?utf-8?B?NEMyMmhXVFZsblFTTUhybEpLd2pmcW0xMExVTjFrZnVockZMc0grSkRYTlh1?= =?utf-8?B?eDg0WlU1ZXRiZHFSZWdyaDNuUVFTdlc2dzFHL1ZuQ2xEanlKQXg5ZmU2UWYx?= =?utf-8?B?TkU1QWdxRk1OUXE2MHdkczZ1SXc3aTM0VkVzR0VRVVpza0lYdnNLZUEvcTVz?= =?utf-8?B?YW0wU3BCN0N2U1VXZWRwVlhyQXlNckdCVXpCNk1NdzNhS2J1V3U2OEhjZ3pn?= =?utf-8?B?MnVzaCt0Nnl5K0F1VmNndG5KMVFLUDRJUnJickZvVUN3eEl0ZFk0TmdtVnBS?= =?utf-8?B?WU1zZEYwNnQxeVRYT1J0K05RS281cjc0a1dHMlRmU1BGRGYyMGFMbG1CQlIx?= =?utf-8?B?MUtyQjlpOWJvSGJYa1VSMzJwUGVTblZPQmJ2OFBoSFBnTWJKNkRqTCtmYm5H?= =?utf-8?Q?lUTRVAG8xjCXVA5E=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0719d717-30bc-4a5c-7181-08de52b737df X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 15:20:00.3677 (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: 5obzAMvYOrhPzMq/byW91xRjJYhCNEguuYLpG47fppxLiYbY7Hu7z0b0A6CkE9UTyhEvouptMRsMjgFmhlTZ3wRdPMEdZmHMaLP1NAKQw1Q= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR03MB5275 On 13/01/2026 3:00 pm, Alejandro Vallejo wrote: > On Tue Jan 13, 2026 at 3:24 PM CET, Andrew Cooper wrote: >> On 13/01/2026 12:21 pm, Alejandro Vallejo wrote: >>> It's only used for microcode loading on x86. By lib-ifying it we can make >>> it go away automatically when microcode loading becomes an optional >>> feature in follow-up patches. >>> >>> Signed-off-by: Alejandro Vallejo >>> --- >>> v3: >>> * New patch. Subsumes earlier conditionalisation of earlycpio.c on >>> CONFIG_MICROCODE_LOADING. >>> --- >>> docs/misra/exclude-list.json | 8 ++++---- >>> xen/common/Makefile | 2 +- >>> xen/lib/Makefile | 1 + >>> xen/{common => lib}/earlycpio.c | 0 >>> 4 files changed, 6 insertions(+), 5 deletions(-) >>> rename xen/{common => lib}/earlycpio.c (100%) >>> >>> diff --git a/docs/misra/exclude-list.json b/docs/misra/exclude-list.json >>> index 388397dd3b..2b874dfd3b 100644 >>> --- a/docs/misra/exclude-list.json >>> +++ b/docs/misra/exclude-list.json >>> @@ -121,10 +121,6 @@ >>> "rel_path": "common/bunzip2.c", >>> "comment": "Imported from Linux, ignore for now" >>> }, >>> - { >>> - "rel_path": "common/earlycpio.c", >>> - "comment": "Imported from Linux, ignore for now" >>> - }, >>> { >>> "rel_path": "common/gzip/*", >>> "comment": "Imported from Linux, ignore for now" >>> @@ -225,6 +221,10 @@ >>> "rel_path": "include/xen/decompress.h", >>> "comment": "Imported from Linux, ignore for now" >>> }, >>> + { >>> + "rel_path": "lib/earlycpio.c", >>> + "comment": "Imported from Linux, ignore for now" >>> + }, >>> { >>> "rel_path": "lib/find-next-bit.c", >>> "comment": "Imported from Linux, ignore for now" >> Honestly, I think this needs simply dropping.  "ignore for now" isn't >> going to cut it with any competent evaluators. > That would depend on justifications and such. But regardless clearing the > exclusion list is a different matter aside from removing microcode loading. > >> By libryfing it, it's no longer part of the AMD target build, but it >> does want covering by *-allcode. >> >> Given that you noticed it for v2, I presume there's something in the >> file that Eclair doesn't like? > I didn't run Eclair on it. It's ignored as part of common, and the build > fails in CI if the file in common is absent. That's how I noticed it. > > I'd rather not gate this particular change on earlycpio playing ball with > Eclair. I'm explicitly not gating it.  *-allcode is non-blocking, but I want earlycpio being scanned. Simply omitting the second hunk should do this, and not explode the AMD target build.  (Once this patch is reordered to the end of the series.) > >>> diff --git a/xen/common/Makefile b/xen/common/Makefile >>> index 92c97d641e..4fc0c15088 100644 >>> --- a/xen/common/Makefile >>> +++ b/xen/common/Makefile >>> @@ -65,7 +65,7 @@ obj-y += wait.o >>> obj-bin-y += warning.init.o >>> obj-y += xmalloc_tlsf.o >>> >>> -obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo unlz4 unzstd earlycpio,$(n).init.o) >>> +obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo unlz4 unzstd,$(n).init.o) >>> >>> obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o) >>> >>> diff --git a/xen/lib/Makefile b/xen/lib/Makefile >>> index efca830d92..60cfda4dfc 100644 >>> --- a/xen/lib/Makefile >>> +++ b/xen/lib/Makefile >>> @@ -3,6 +3,7 @@ obj-$(CONFIG_X86) += x86/ >>> lib-y += bsearch.o >>> lib-y += ctors.o >>> lib-y += ctype.o >>> +lib-y += earlycpio.o >>> lib-y += find-next-bit.o >>> lib-y += generic-ffsl.o >>> lib-y += generic-flsl.o >>> diff --git a/xen/common/earlycpio.c b/xen/lib/earlycpio.c >>> similarity index 100% >>> rename from xen/common/earlycpio.c >>> rename to xen/lib/earlycpio.c >> What's wrong with .init here?  There's only a single string which will >> end up unmerged so I'm not worried on this side of things, but we now >> have series doing safety things getting tangled with .init and I want to >> get it fixed. > .init.o doesn't work with lib-y; only obj-y, obj-bin-y and extra-y. See below: > > $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS-y += -DINIT_SECTIONS_ONLY > > [snip] > > non-init-objects = $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(extra-y)) > > [snip] > > $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): $(obj)/%.init.o: $(obj)/%.o FORCE > $(call if_changed,obj_init_o) > > That's just what I eyeballed. There might be more hidden elsewhere. > > It might want fixing, specially if something like libfdt is to turn into > a library. But it's just not relevant for this particular change where the > single contained function is already __init. *.init.o does two things: 1) For things we can tag, check everything is tagged 2) For things we can't tag with __section(), such as string literals, move them into .init Fixing lib init properly should just be a case of sprinkling lib-y through those places you mention.  If you want me to do the patch then fine, but I want it fixed rather than keeping on going around in circles. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 13 15:28:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 15:28:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201942.1517557 (Exim 4.92) (envelope-from ) id 1vfgJL-0007V7-Mq; Tue, 13 Jan 2026 15:27:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201942.1517557; Tue, 13 Jan 2026 15: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 1vfgJL-0007V0-Jz; Tue, 13 Jan 2026 15:27:59 +0000 Received: by outflank-mailman (input) for mailman id 1201942; Tue, 13 Jan 2026 15:27:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfgJK-0007Uu-G2 for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 15:27:58 +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 6ead847f-f094-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 16:27:55 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-47d1d8a49f5so49115715e9.3 for ; Tue, 13 Jan 2026 07:27:55 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee119aa2asm2315045e9.4.2026.01.13.07.27.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 07:27:54 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6ead847f-f094-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768318075; x=1768922875; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=agfOTtwRw0RjOf4q5IyshfB7YKBfCI5EDUHz0VnYqrc=; b=Rz/cZJciSIGSKHyWHmeVj64slw0cW0MsH0CKaPt/k3fAQ/gOqCEkWmchHxpP8wkyt7 neEj1jpUm+TqSyuM/golIxCqRcW4q24c2lfqLRgzMNtymFzjpgyLJ82O4MwT5dLVehZ3 DtScqnrKY2faGi9M9tRxDogBDBWGuNd2Vf1wEcQCGMxlFhCamrZeOujdRw/Ar2QXK5Q3 +z60yOAP3YqudVid2ci0XTe4LCz9LIEG5GQvJvLDIw4gqx5ZF0cMkl6oZhgmOOHaabJg qVn/DSSYm/mJAiNdFTobpjCg+shPyI7QppKLK6/+OHGRh/8Fkaq5/m7GWzMaWI02Kq9s GLrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768318075; x=1768922875; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=agfOTtwRw0RjOf4q5IyshfB7YKBfCI5EDUHz0VnYqrc=; b=R+igMu3oNKmoFfW5MAwGrOw++51yjpK1qBOhVa47+gcdl4yLSCiBKL7apKMwAmGsRe vaeRXdUW+lrinD6Yuz04AsruwAFZFQep8IEdk8UdAZh5NazR1ys+TTnAe/n7iNqyKDEW euolXA6EqeZubrUi8h7Mo+l+WSrNHKsTkz6ofvMyHOFGj1kHGtye3pxO7MZ0ufeKNDBf BY7eUAt8G0aRZRiNyMxbtqVICVKb8eqbHUg0Mt5GZmi3vI+hfO8W9MwUERvyKlRDJViP plXf44sub+HZeOcuL1uAFDSXfx6+cNNepKuh5+adPGj6D3LkSkz78xidt0qY8rc7SDus ic1w== X-Forwarded-Encrypted: i=1; AJvYcCWH6tu70UxE6S05EWd4QWxD1DRNQGmuTx1YNufjS2lxDEcM++lHOCeADu3DqsDo/XzeI8YfAYjYhKU=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz4Jy3xElUPAGKUtFhc7ZTW37ET97BrXqb/jEjMr+LOQ02hHgHP cVoVOL47qdmSMPAa3jiqNZ3SWLbNC0QUGaCd1dRJ8wsxeSmQbVSUaJQ1T3x/ZUJLDg== X-Gm-Gg: AY/fxX6N6lGdsMhkR4vyRcX/i010h/pFqCA988VEqHJjCfQsThbOJWl25xMZpnqKJMC aVPjsBPJbUqkC624qwgF9WPxBWSo2UvQD6kttj397G9o+uLAPT6Nw0occSYTJ7ZtIH06OBiVvCi VQjwLdMwUXXVM8D8RtyNHT7gj25trcDaUDZibjSoZmTugJ8xbxFSkB6yXlEUX7XkLPXkhCCQIbr mzhUTObT8F3QNoanjSydirIs4Qjp98R8ND7K+ErgEzvAf7a9kQCaM/ar0r6OP+OGIq88NLogn3o dA5HbIg0ChVhyDT9T6wFOfr3z9dLZn5YCYjjMK6p0QPQt04RF9kqG6CholTgDdQPOXkf2iPYrAJ 9FHO//ZeUPj4fGGiKNQLHufyl9l0uNynKdhz7M0O7BIpskid2zo9bcrojuWvmknLqNTokqz1nD0 mab5GZNDz2/0Tke1BR1dBD7OtPR+Cf/aLCM8OlPWm5dI68bKzYv2t+VAvagj/I+sRv8MDV5l1sl UA= X-Google-Smtp-Source: AGHT+IG59xKq1nS9a5CN1lXHfo5fdq/o4i7VXEA3OY+gJOdANvkJxD8x039yqPUkxlC4i9f6D90QTw== X-Received: by 2002:a05:600c:8b52:b0:477:abea:9028 with SMTP id 5b1f17b1804b1-47d84b1a348mr230139645e9.6.1768318074635; Tue, 13 Jan 2026 07:27:54 -0800 (PST) Message-ID: <0706617f-fdb8-47c1-94f4-6aa92abd07ec@suse.com> Date: Tue, 13 Jan 2026 16:27:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 4/4] x86/ucode: Add Kconfig option to remove microcode loading To: Alejandro Vallejo Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , xen-devel@lists.xenproject.org References: <20260113122109.62399-1-alejandro.garciavallejo@amd.com> <20260113122109.62399-5-alejandro.garciavallejo@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260113122109.62399-5-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 13.01.2026 13:21, Alejandro Vallejo wrote: > @@ -469,7 +471,7 @@ struct ucode_buf { > char buffer[]; > }; > > -static long cf_check ucode_update_hcall_cont(void *data) > +static long cf_check __maybe_unused ucode_update_hcall_cont(void *data) > { > struct microcode_patch *patch = NULL; > int ret, result; Why this change when ... > @@ -613,6 +615,7 @@ static long cf_check ucode_update_hcall_cont(void *data) > return ret; > } > > +#ifdef CONFIG_MICROCODE_LOADING ... this can simply be moved up accordingly? After all ... > int ucode_update_hcall(XEN_GUEST_HANDLE(const_void) buf, > unsigned long len, unsigned int flags) > { > @@ -645,6 +648,7 @@ int ucode_update_hcall(XEN_GUEST_HANDLE(const_void) buf, > */ > return continue_hypercall_on_cpu(0, ucode_update_hcall_cont, buffer); ... this is the only user of that other function. > --- a/xen/arch/x86/cpu/microcode/intel.c > +++ b/xen/arch/x86/cpu/microcode/intel.c > @@ -408,17 +408,20 @@ static const char __initconst intel_cpio_path[] = > "kernel/x86/microcode/GenuineIntel.bin"; > > static const struct microcode_ops __initconst_cf_clobber intel_ucode_ops = { > - .cpu_request_microcode = cpu_request_microcode, > + .cpu_request_microcode = MICROCODE_OP(cpu_request_microcode), > .collect_cpu_info = collect_cpu_info, > - .apply_microcode = apply_microcode, > - .compare = intel_compare, > - .cpio_path = intel_cpio_path, > + .apply_microcode = MICROCODE_OP(apply_microcode), > + .compare = MICROCODE_OP(intel_compare), > + .cpio_path = MICROCODE_OP(intel_cpio_path), > }; While I appreciate the intention with MICROCODE_OP(), I'm not really happy with function pointer members left in place just for them to be NULL everywhere. What if a call site remains unguarded? With PV guests that would be a privilege escalation XSA. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 13 15:32:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 15:32:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201953.1517567 (Exim 4.92) (envelope-from ) id 1vfgNw-0000at-7I; Tue, 13 Jan 2026 15:32:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201953.1517567; Tue, 13 Jan 2026 15: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 1vfgNw-0000am-46; Tue, 13 Jan 2026 15:32:44 +0000 Received: by outflank-mailman (input) for mailman id 1201953; Tue, 13 Jan 2026 15: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 1vfgNu-0000ag-I8 for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 15:32: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 1924dcdc-f095-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 16:32:41 +0100 (CET) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-64b5ed53d0aso11341674a12.3 for ; Tue, 13 Jan 2026 07:32:41 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6507b8c4c15sm20438885a12.4.2026.01.13.07.32.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 07:32:40 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1924dcdc-f095-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768318361; x=1768923161; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=P2uMcWi4FiTHA8GDmA4Tql4mVTb/WHCmilSUeqLJnKU=; b=U6Y29kaqT1ogyJByLRRAht92rNkk/D7bNxfH/w6sYkeBGBdYK4MIwuRPt/haXvoiJO m69XTCgMMLUyMi2DO1nVDgOcOKOKwoc1VHIne5aeuJse//ChbqCw9MXM8Us9GvQzD/6l jw8t7IwFB7VBxwdaCCIJn42wVvBHSl/1jVy156slIh25SDrZgbSkUOD/YHm6qrAuyMW/ F6Zsb3iIXNVIlIy2D+wcrwALqTFtQ9zZs6DLiV8XlDH+xbLAu5nm71VBvj3r9PL+zF7W QtpAHGNUHmMim8XP+MRgLc73CMe0tp+5DHTiOT57vV+jtmHIa+2OL1hQVYsgPDqvZEKh YGKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768318361; x=1768923161; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=P2uMcWi4FiTHA8GDmA4Tql4mVTb/WHCmilSUeqLJnKU=; b=f9WSKyWdiIHedkvOwLIhni4sXztF3pS2taor1fYB/Jv0Ot6OmZNrKhNoWKsdqcq8gD lWCzF0kuRbVh4RFdzGUzdgctXG6oWr/j8JG7ua92LA54/3bD4EZ5lzw25DInhh+6uQdV PbwB499uGp9SRW565pd4ZMFp2ZqUIv+k3fuDhRDkEiqm7sVxJW4EW3oefTlGr6jEHO2a DmS/nZeqwCuHFC+QzVC3w7w9zyX8bUlZRQP4tZmUZ4xhClU259eBS762qFcwMHtBXhlp zfth398av7Xz6TTvZwAQXe8+7NgTrDh1dA2jWPZx5pqCSV3NztqOSEvVPU5sshRUxhX5 R0zQ== X-Forwarded-Encrypted: i=1; AJvYcCXA3xSZaBUFQeG/iuBz6brfbM834J1K5/Uc4lfWHRKAd2iLeSXxOCVXcUrDdQK8XemvzrAHL5UqbC4=@lists.xenproject.org X-Gm-Message-State: AOJu0YzkrykU8z0wKdvowfLSbHtQAtfIfM0sRbHyAcbb2oYW3TMiHlEO Z2HECuR9vTPg8KAp4uEehLSjsu7WWOz6ys4AIJA2UX/PV/nlPBNvXixO X-Gm-Gg: AY/fxX4ISzBr+/pu9j88H2+eKwkR/n2BdDqa/LmnT3jNJV72sI0v75qM5zuUuNmmYob 41mKvmfcW8pYSymWj2WeJhxtfBTuL9aSltuGoKyExcSI1XMPe1yLhuWZcT1bVBv7GDgzS/qIWnX MnKZYeF0E6nikpxTCSRLOZehNuVHrnhE+MDcFRq/Who5lHPsS2WmyWYoIjCILa3JWQa5XDlLj71 vyfof/JIPjaMbBl63DXarJcpkh/S2g1cf9kTArioBX6Ysz66+05g436X3aNrpkJNSsSBDnlnGdP IQZKb4NQ/YAFe/jz/jVi1Fd2etb5bYbqoliIj8rL/bOHG4PDoj6XID0sJB7PZtfcwTgTMP/3MkD Q7moHIzgU6TUT7u5ljZH1sXt8hwQk4AEiA0ux0hbDAaVOC0idWpDHSxCJmmo92vK+cbHuVz/NvH JWnNhp1YMuhmRDfNG4y7Pnuu59nRM7LFiMTYWI+ylRcHk6GqTa+RtYB7Yp+MmEVFQ= X-Google-Smtp-Source: AGHT+IFpW5QQqNUz/oJj/+xCcH1TnefRzaIiw5OIDQtHuTisSSPF8I7dIvXbf/K8JbdxiGa5Um+urQ== X-Received: by 2002:a05:6402:2811:b0:649:927c:337c with SMTP id 4fb4d7f45d1cf-65097dfd568mr19112396a12.14.1768318360383; Tue, 13 Jan 2026 07:32:40 -0800 (PST) Message-ID: <1acea58d-79f5-4fca-bd6a-1eaca72093f3@gmail.com> Date: Tue, 13 Jan 2026 16:32:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Oleksii Kurochko Subject: Re: [PATCH v1 09/15] xen/riscv: add vtimer_{save,restore}() 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: <9d02934b-d448-4ec0-af0d-b4ee9a918e03@suse.com> Content-Language: en-US In-Reply-To: <9d02934b-d448-4ec0-af0d-b4ee9a918e03@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/8/26 11:43 AM, Jan Beulich wrote: > On 24.12.2025 18:03, Oleksii Kurochko wrote: >> Add implementations of vtimer_save() and vtimer_restore(). > And these are going to serve what purpose? Are they for context switch, or > for migration / save / restore? In the former case (supported by the naming > of the function parameters), I think they want naming differently (to avoid > confusion). See how x86 has e.g. ..._ctxt_switch_{from,to}() and then > ..._switch_{from,to}() helpers. Based only on the name it is clear for what ..._ctxt_switch_{from,to}() will be used, ..._switch_{from,to}() isn't clear just based on the name how it will be used. Anyway, I am okay to change vtimer_{save,restore}() to vtimer_ctx_switch_{from,to}() and then follow for other stuff to follow the same approach (as I used for everything *_save() *_store()). >> At the moment, vrtimer_save() does nothing as SSTC, which provided >> virtualization-aware timer, isn't supported yet, so emulated (SBI-based) >> timer is used. > Is "emulated" really the correct term here? You don't intercept any guest > insns, but rather provide a virtual SBI. I wasn't sure that it is the best one term. Probably then just "virtual (SBI-based) timer" is better to use. > >> vtimer uses internal Xen timer: initialize it on the pcpu the vcpu is >> running on, rather than the processor that it's creating the vcpu. > This doesn't look to describe anything this patch does. Hm, and why not? In vcpu_vtimer_init() we're initializing timer (it was incorrect to use "internal Xen timer" though) on CPU is stored in vcpu->processor by calling init_timier(). I will update this part then to: Initialize the timer contained in|struct vtimer| by calling|init_timer()|. > >> On vcpu restore migrate (when vtimer_restore() is going to be called) >> the vtimer to the pcpu the vcpu is running on. > Why "going to be" when you describe what the function does? Because it isn't called now. The part inside (...) could be dropped. > >> --- a/xen/arch/riscv/include/asm/vtimer.h >> +++ b/xen/arch/riscv/include/asm/vtimer.h >> @@ -24,4 +24,7 @@ int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config); >> >> void vtimer_set_timer(struct vtimer *t, const uint64_t ticks); >> >> +void vtimer_save(struct vcpu *v); >> +void vtimer_restore(struct vcpu *v); > Misra demands that parameter names in declarations match ... > >> @@ -65,3 +66,17 @@ void vtimer_set_timer(struct vtimer *t, const uint64_t ticks) >> >> set_timer(&t->timer, expires); >> } >> + >> +void vtimer_save(struct vcpu *p) >> +{ >> + ASSERT(!is_idle_vcpu(p)); >> + >> + /* Nothing to do at the moment as SSTC isn't supported now. */ >> +} >> + >> +void vtimer_restore(struct vcpu *n) >> +{ >> + ASSERT(!is_idle_vcpu(n)); >> + >> + migrate_timer(&n->arch.vtimer.timer, n->processor); >> +} > ... the ones in the definitions. No matter that RISC-V isn't scanned by Eclair, > yet, I think you want to avoid the need to later fix things up. Sure, I'll fix that. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Jan 13 15:32:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 15:32:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201954.1517576 (Exim 4.92) (envelope-from ) id 1vfgNy-0000oj-Dx; Tue, 13 Jan 2026 15:32:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201954.1517576; Tue, 13 Jan 2026 15:32: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 1vfgNy-0000oc-BD; Tue, 13 Jan 2026 15:32:46 +0000 Received: by outflank-mailman (input) for mailman id 1201954; Tue, 13 Jan 2026 15:32: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 1vfgNw-0000hn-TS for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 15:32:44 +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 19efce51-f095-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 16:32:42 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-47edd9024b1so4361585e9.3 for ; Tue, 13 Jan 2026 07:32:42 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f69e13bsm416535935e9.7.2026.01.13.07.32.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 07:32:41 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 19efce51-f095-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768318362; x=1768923162; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=kQFGthPvhhaDl4fJbDZWvrToOoUtZp50V1V3UduJxAk=; b=BtzhzR5lzT+bIGaV1DJ/4z/buorg0RmiuLxafS639+mxoCOcadklP7iVjNgUSZD2EJ RAQ0zZPzClDECh7Pofn/rWcHNvIAHMh/lWwGMMW+l1zuZq6smmUv1ROlBeUKPKa08oXO VJjzNSrjo0zKHNvizy3aNi1N0/w2qyuyFrJ3kYs0Td7fTJWeVfXNgkcAcu2YITnOLH6b NN2SwABbuhOAcrPIRUXw+EYl7vSLRqUy6vKmU9HZAVSS7eB2FL514EImuUIv/9DPIclx Blv3+e8CsNdWB8sBzNxDxr5QUJ5w99SV2KHzYpIAgYIQiMEQ7OxfqxS+vhXMP9jy9yLu 2HLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768318362; x=1768923162; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=kQFGthPvhhaDl4fJbDZWvrToOoUtZp50V1V3UduJxAk=; b=sKpJXm54vQvtjcTrs3BGdZuwh2BEzKpEvTe6LrGxSQtbXnoxGs1VpqgDC3UZt76Tez 5RyCvEqxsjK8oG4+nyRENnIbWq+rNFgGEc0hYx9ZQUF6KtH6ED0SSXq1j3On4C5YgHld JD2buFn0MJO7pnWw/wv2mbUuWnAEh2uqO4vDdBzvmCwiXp1RHWcAXaElKW4FfK+d1qrm foy9rx9tC2lp0GV7JeiwIV0hAdcoT1Po2qQGqBQ9H623VhVd//SFdN+f8JNWJ0WMN0BT VZ4Le+iMJrb5kHWocgvsspSzP9ZAxhM7Tw3uX69WNxUFipl0BW5E8xeGvsNETMCK7ZIH 2Bng== X-Forwarded-Encrypted: i=1; AJvYcCXPVNh8NYg4oUto4cxyGV5AxNCgXXADmBXE7PVr0md6cB2YenHPHoSBzjvOlbizMP/QYuj5WsrfI7Y=@lists.xenproject.org X-Gm-Message-State: AOJu0YxSIngXj41as/FCF/8Ngza7QzzEYOf7iRZmaT98jEDy2WbMjIk7 3chNM0rdk3ilqcvDG9GVnLn6fb6+ecziusuSC2ZaW0X7DjC8q/HAjTkVv+Zy2M90+w== X-Gm-Gg: AY/fxX5s9kh2qZ3SbdftY9R9IA6ehqcgt/FrRbz3Rm1w/MuT7LVb/a4GT0XT+Buf9TE TT4hqhx71diY2QDABnbBeFCo4h4preH7erh3m0q2kynI9JXPTff/alCcOLw5adVtQJoTh9BFyrf uD14/FTgceL1iu5JpztqsdAoQosGwI+Z+jco14okHKFH/qO+5jlTISwk3vYZRWLpnA5S9HOeQav adu6WlayB4gciTUhw5hsn4DcIB2vlCbY7jCE6HQOqI/5XfxwQXgmazltnIFM59HXx4WfBVrC3t1 t9BjjJaUjfnda9bG6wB9JChxxcNE68N1lRqr6T1anZ48++lnJqUhkxZT8DxU3Ik8PK/2t7sEOWe LQ7cVyl3MlyTJoF5AImAtXfq0BVXJgdJ3DVD/JONZLy1RGZSBl0aQz7DvbgF1/jI0mxIQQHibHV RmkqDWTMkOJiu6jb8sd/S9Pnt2sJQKi+ZEJ7FuvDnN9ev8BOlQmm6fqwBjrkAIW5u8DRxdMdMmj F58dknTo5bnWA== X-Google-Smtp-Source: AGHT+IHrKqLwh88xf5/yJLZX5jajlv91B5ENLDzhzlxtdKbdfkB9MLU2GJIO6eOfCmTWbScfs76iZA== X-Received: by 2002:a05:600c:1d14:b0:477:97c7:9be7 with SMTP id 5b1f17b1804b1-47d84b0a7bdmr239498635e9.1.1768318361921; Tue, 13 Jan 2026 07:32:41 -0800 (PST) Message-ID: Date: Tue, 13 Jan 2026 16:32:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/4] earlycpio: lib-ify earlycpio.c To: Andrew Cooper Cc: Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260113122109.62399-1-alejandro.garciavallejo@amd.com> <20260113122109.62399-4-alejandro.garciavallejo@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 13.01.2026 16:19, Andrew Cooper wrote: > On 13/01/2026 3:00 pm, Alejandro Vallejo wrote: >> On Tue Jan 13, 2026 at 3:24 PM CET, Andrew Cooper wrote: >>> On 13/01/2026 12:21 pm, Alejandro Vallejo wrote: >>>> It's only used for microcode loading on x86. By lib-ifying it we can make >>>> it go away automatically when microcode loading becomes an optional >>>> feature in follow-up patches. >>>> >>>> Signed-off-by: Alejandro Vallejo >>>> --- >>>> v3: >>>> * New patch. Subsumes earlier conditionalisation of earlycpio.c on >>>> CONFIG_MICROCODE_LOADING. >>>> --- >>>> docs/misra/exclude-list.json | 8 ++++---- >>>> xen/common/Makefile | 2 +- >>>> xen/lib/Makefile | 1 + >>>> xen/{common => lib}/earlycpio.c | 0 >>>> 4 files changed, 6 insertions(+), 5 deletions(-) >>>> rename xen/{common => lib}/earlycpio.c (100%) >>>> >>>> diff --git a/docs/misra/exclude-list.json b/docs/misra/exclude-list.json >>>> index 388397dd3b..2b874dfd3b 100644 >>>> --- a/docs/misra/exclude-list.json >>>> +++ b/docs/misra/exclude-list.json >>>> @@ -121,10 +121,6 @@ >>>> "rel_path": "common/bunzip2.c", >>>> "comment": "Imported from Linux, ignore for now" >>>> }, >>>> - { >>>> - "rel_path": "common/earlycpio.c", >>>> - "comment": "Imported from Linux, ignore for now" >>>> - }, >>>> { >>>> "rel_path": "common/gzip/*", >>>> "comment": "Imported from Linux, ignore for now" >>>> @@ -225,6 +221,10 @@ >>>> "rel_path": "include/xen/decompress.h", >>>> "comment": "Imported from Linux, ignore for now" >>>> }, >>>> + { >>>> + "rel_path": "lib/earlycpio.c", >>>> + "comment": "Imported from Linux, ignore for now" >>>> + }, >>>> { >>>> "rel_path": "lib/find-next-bit.c", >>>> "comment": "Imported from Linux, ignore for now" >>> Honestly, I think this needs simply dropping.  "ignore for now" isn't >>> going to cut it with any competent evaluators. >> That would depend on justifications and such. But regardless clearing the >> exclusion list is a different matter aside from removing microcode loading. >> >>> By libryfing it, it's no longer part of the AMD target build, but it >>> does want covering by *-allcode. >>> >>> Given that you noticed it for v2, I presume there's something in the >>> file that Eclair doesn't like? >> I didn't run Eclair on it. It's ignored as part of common, and the build >> fails in CI if the file in common is absent. That's how I noticed it. >> >> I'd rather not gate this particular change on earlycpio playing ball with >> Eclair. > > I'm explicitly not gating it.  *-allcode is non-blocking, but I want > earlycpio being scanned. In fairness to Alejandro - you're asking for an entirely unrelated change. If it was really just ... > Simply omitting the second hunk should do this, and not explode the AMD > target build.  (Once this patch is reordered to the end of the series.) ... this, then probably okay(ish). But afaict MICROCODE_LOADING needs to then be turned off for *-amd, which patch 4 doesn't do (yet) afaics. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 13 15:41:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 15:41:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201972.1517587 (Exim 4.92) (envelope-from ) id 1vfgWg-0002lN-8O; Tue, 13 Jan 2026 15:41:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201972.1517587; Tue, 13 Jan 2026 15:41:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfgWg-0002lG-5Q; Tue, 13 Jan 2026 15:41:46 +0000 Received: by outflank-mailman (input) for mailman id 1201972; Tue, 13 Jan 2026 15:41:45 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfgWe-0002l9-W0 for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 15:41:44 +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 5c5fc91c-f096-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 16:41:43 +0100 (CET) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-64b9d01e473so12923661a12.2 for ; Tue, 13 Jan 2026 07:41:43 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6507b8c4048sm20891759a12.2.2026.01.13.07.41.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 07:41:42 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5c5fc91c-f096-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768318903; x=1768923703; 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=LTZVzT2/QMWTHb01rWpmc2mXtzalprZmDt3PPYaGzIw=; b=hpf/6vVx2VFIPLsLd6hx3sKFWIys/2IYv1uYYy05ghMvb60zcrLLOMXW/Jap335Td2 SuLAwYzUc9GHA/Kg+/pl1y+FEV5aCetHteBqE+XszIOOIMYfclotvADqcP9c2LcaXvjy LTwMmAdShy3GSxHhBbZ/n3lcEm9t8JkuMZYloYDNPuttAR1uTRD57wC7elHXJMvku7Vq jxa5eLiZps9tUwUgU4K73l48HUh//qYYrFaI3ppRPJJ8/IU9sx6MDMZSq0f74Yz9QZbB TRoVQYI+kcTK0K8Et+RHLfFbbO5NAsGJTei654nPReiXGLB87BHaTZ5xAKv1Rinow2yZ r7Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768318903; x=1768923703; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LTZVzT2/QMWTHb01rWpmc2mXtzalprZmDt3PPYaGzIw=; b=fL270vbBOisfeCzokpGk6qG6cFJkX22dn0s5wjw9nijm8hRU/ymHpgsJk8LQoWiAYA pVRjUJZsIkiPyiwO/IUFk0naALghCHtfsYEZqMqGPINDsfwCCJv2gdJjRHnvxHxliFcT gKSypkSTrsz+glNr7OPnEsdHW9aYFsghp/s0SRiCwLA9S2glQl/S5XlnjF/gB2cFEJXy jRyDY9VeE8+qYpeMmFCHyF8iZZrJ/d9l8yfw1m14u7YCf4PcBJiXMlVleo24tb+WAFgZ Zfy6wGo3krcQExtMaDAaethIMIH2o5qsIC+hi7vNEF1IxZfpye0coR06YoOqPLaZEKhe R6wA== X-Forwarded-Encrypted: i=1; AJvYcCWEiNqgQ773Q4jIap2I+nmYiSIqGrImQOcL+XTDukXFoFd8xSDrd2CKm6PbzjNiHdY2dVvWXXGowiA=@lists.xenproject.org X-Gm-Message-State: AOJu0YzMKi/w5rheaOSTusKTgVTeObFGBzK7U4ogAEhlyvEDcA6tDl/Q czicKnbVgmxhTFLzTeXYmeqA1rOPlo+8WlEOn1QaDm8of158QFsnhPU1 X-Gm-Gg: AY/fxX7tNFYob1Zi1I64i/WqklxEoMyb4X3zypFg388h5RzCn4KHJi3rmFSYyg4wKek aizfC47eKjOBqaq9wg51SUrUB/Y1IB7Yeub+YkwqBSKddz6+t3iRz8An2wvsfWNflHH8X4Htzto W2Zok3gaAhY9GTR+4z8fXMpP+IfGPxDcb3PUjlSahT5cELTisR4viAlzyvjjvWn5tYMwlfU+/Pz YobxjG5z7/mBgP2znad0e/wtlQkIJ6hsJjGlhW0EctKw9w2JGhX5ADDXtcyzFC5w7qP8Vg1Jp7D aWnC+Gro9mcMjJAc51HPNHsKlj3JPI7Frus4h57P0NadsKqfy560Ls+TZ80cHgsTvbqR8Zqs1eD pcVjQqmgn/22zUV5TdOm9qhsmyUSNM4gmTCvSosWNXqUfBRYpNbbm6OpNpcebwalZmr3vbtd6PD HEz6ECYRbc1ol4qvqJsfQf0y6enDZsAkeFQ0qRHhCVtprE4CxJDEKTyqrM8EsJHPN1D5Flr/kgz Q== X-Google-Smtp-Source: AGHT+IE8QuKlQdgRmTHkjRPscmCuWQ9D6w9z/VgR5PyaVZpXvZw6ojiPqQLRMFKrZOXMhPEhM9NW0Q== X-Received: by 2002:a05:6402:b01:b0:64b:60e4:f898 with SMTP id 4fb4d7f45d1cf-65097df5b9dmr16783596a12.15.1768318902811; Tue, 13 Jan 2026 07:41:42 -0800 (PST) Message-ID: <3bae3547-dbff-4d1d-b5b3-827101ea2467@gmail.com> Date: Tue, 13 Jan 2026 16:41:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 10/15] xen/riscv: implement SBI legacy SET_TIMER support for guests To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <53913b1f-5413-4cb8-9758-9f891a704445@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <53913b1f-5413-4cb8-9758-9f891a704445@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/8/26 11:45 AM, Jan Beulich wrote: > On 24.12.2025 18:03, Oleksii Kurochko wrote: >> Add handling of the SBI_EXT_0_1_SET_TIMER function ID to the legacy >> extension ecall handler. The handler now programs the vCPU’s virtual >> timer via vtimer_set_timer() and returns SBI_SUCCESS. >> >> This enables guests using the legacy SBI timer interface to schedule >> timer events correctly. >> >> Signed-off-by: Oleksii Kurochko > Acked-by: Jan Beulich Thanks. > > What about the more modern timer extension, though? Handling will be the same, as the API is identical: struct sbiret sbi_set_timer(uint64_t stime_value) The only additional work needed is to add handling for the new extension with EID|0x54494D45| (“TIME”), which was introduced in SBI v0.2. Interestingly, we currently report to the guest that OpenSBI v0.2 is available, so technically this modern timer extension should be usable. However, the guest still tries to use the Legacy extension, as it has not yet received an indication in Xen that the EID|0x54494D45| (“TIME”) isn't implemented. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Jan 13 15:50:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 15:50:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1201988.1517597 (Exim 4.92) (envelope-from ) id 1vfgfV-0004Xv-4A; Tue, 13 Jan 2026 15:50:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1201988.1517597; Tue, 13 Jan 2026 15:50:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfgfV-0004Xo-1F; Tue, 13 Jan 2026 15:50:53 +0000 Received: by outflank-mailman (input) for mailman id 1201988; Tue, 13 Jan 2026 15:50:52 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfgfU-0004Xi-Ap for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 15:50:52 +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 a2958142-f097-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 16:50:50 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by PAWPR03MB10091.eurprd03.prod.outlook.com (2603:10a6:102:368::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 15:50:46 +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.9499.005; Tue, 13 Jan 2026 15:50: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: a2958142-f097-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=LuQE/YXhLVcjj7yFX1gJHA7B12mHFp33I7xImwhwncQPuuP1G0Cyqn975xS53C+1Fo46O2haRlMAL+QqBpECIZHmHiZUOGZMRF5PUd/B1/66kCOsL78H6WnAEdDq01FCoIGhyCidlpC9VeZxDI5EOPcRomxT8R6CZ9uB6qkofUI3KFFugPDBJ5DdVY2Up0rsnRqYJ65bJGT159/48AguVxCmMsBrvOrWHcQJ33MTeDvPauljKaiADK7euJmcbddyxizMU39qmvydzsLH74fCL97Sq4GHMh7Npw+ywHiFbBEsljzKo7ASgTBfCM9Es0/HmmLbNqEpsvbk6XSDLKt/mA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dZvjKgStKPMde36gAL6tBXrsBvuvEBoAVsQmNafFi4I=; b=v8YZPgeEJ5yQ32jDuIsyfjchEYTNBU++YgtEiMJs+BtzTP9ArK0oKgnYjX7Eb7qFbHhbermcslrufzSk+fLYp8lq5u+AVQC8lR2tz8LtSo1B60LGcQPTosuG9p3LGQRtyXFG4GTRBG4/MO2tL7S9s/zA1uahx0IxKZYjzMnaKtNjSCmaj1mEbwJzQ0/1NsNR22Pl7/Y2XPxX12BZXob0sEgjWBgPGKuy+iDDyw8niKrN2bpGXJ5tu2uw5CA9KyxtjEBNqy8U0rn+AOMCTxmyqCzT34hWvekvj99dFsfeMHVqan0OMVEoeC/M4rj81EF9oCZBz2I5EK9GWyJuio+NMQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dZvjKgStKPMde36gAL6tBXrsBvuvEBoAVsQmNafFi4I=; b=abhpVnfHSQLL2Devb9/KmgMrC6UL5xFEuIUGC82kF+Lf/Rq+oqZVtJvAljM+gMH4jRb4D2jVsDn/p2xXzIz6YSBVuQ+P/QN2z5p5DSzegNVtKPbphxEF/tN6tqFWQFJJ+fz1MLJjZ4MGoRyHA1R82oMH7pH2tdnNmeFXo5v0xfISFsWuMZCBLLokKtAmJhUCOWYKtvXUX8uu3Fyhk6lgPm7EXZt+Pc4lebs6tTbKf9j00MK2YxaJN3JJqaftaGhA00C03wMNQZvaC4mrRrU3WsRGR4ofCDYcLKa1I133fmcAoHJUHxHus8pdYV6frOTGhfFi5WlFel/2iYDep+uAvg== From: Oleksii Moisieiev To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v6 1/5] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu Thread-Topic: [PATCH v6 1/5] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu Thread-Index: AQHcSyafS16SOr0Uk0OkeRdy8jd8CrVPHVoAgAADtoCAAACtAIAAA/oAgAAAqoCAAYwTgA== Date: Tue, 13 Jan 2026 15:50:45 +0000 Message-ID: <87ba1c35-f1f3-4a52-ba76-306a538ad0c6@epam.com> References: <9598b2e2-7df8-40c5-82cb-c097121af763@suse.com> <5d8f55a6-7182-4e9d-a139-96fddb9450f8@epam.com> <98f5e8f0-070c-4be5-9baf-46278de8093d@suse.com> <99586f5c-d76b-4cbe-9fbd-c87e86bb236a@epam.com> <7cbda859-4257-499e-86e0-a0d001fd49c9@suse.com> <9631b854-2fc6-41aa-8b12-1e7283b22246@epam.com> <4807d2d3-fae7-45a4-b7c7-e101a95a6b58@suse.com> In-Reply-To: <4807d2d3-fae7-45a4-b7c7-e101a95a6b58@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_|PAWPR03MB10091:EE_ x-ms-office365-filtering-correlation-id: 593fd846-7aa5-46f4-c6a4-08de52bb83f6 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|7416014|366016|38070700021; x-microsoft-antispam-message-info: =?utf-8?B?KzB0d1RNK1prZ1VoY2F0TVVPODQ1OXFRSDBJMDdtVW9OczlyQnZDRU9xeSsy?= =?utf-8?B?bFgvRFg3UG1xWGl3Ly9KS0k1QVdwN25VTWJlQzlIbXVXZkU2SVNpRVR4V1gr?= =?utf-8?B?WFIzaHRlTzdtWU0wVXUxdDMwU3JHRXpnYVFjc0c4aHRvanUzVUsrVDl1VjFN?= =?utf-8?B?SlUvNDk3VUdJb21DSlRKeWU0eDlqMlRTR2lIa05rZU1PMGlSWFVBSzZFRVlP?= =?utf-8?B?RnBnR2J0b3pkbU5xcVQ5L1N0UzJPcXc1TG1zTDFsUm5uT2xLcGl5Y0wxM2lo?= =?utf-8?B?eWxySS9oNGZVVEt2S1lYYkVIYkU0Rkx0RGdwbjcyNnlTd1M0NWVscFVSY2F4?= =?utf-8?B?bnA4YWx4cE1ZdWdnMXNBUndzVFJHQ0dIVTB5SmIzeTlWaERxS2tEd3k5Nm5Y?= =?utf-8?B?VzVtMjRsVWlwQWNpaFRIS3FEdjBNYUpBSkx5Mk5UTUswREtFc1NmRlRoMlJz?= =?utf-8?B?NEg4QnptZ2M3bXh0eUVaNEpjNVdGakEwTDFxTjFaY1dTUlowRlp5Qkd4dktF?= =?utf-8?B?MmFIYlRaVG5CSkgrVndTSVo2ays1S09Ec1dQZ1JwOFR2MVhaWDBhdXpHRFhu?= =?utf-8?B?MzFMZGNaV0RFRUtkT2tPK2VORkwzTXdRazJJWDNBdjNUdnZTRGZDUStRNFNH?= =?utf-8?B?eWJSQXhTdVplY0tEc1N2UEM3T2FJb1JuSzRQSDJreENUQnlzbHFYQURBSzAy?= =?utf-8?B?c2l1c2E4MkFaWTE1M2J3SU45TnBmSUhvQVBIbTUzK2FJdzZqNU1hbVNxQ1VP?= =?utf-8?B?VXpEc3ZqYXdMMjNYWnQwZWpMaUlPNU9WZTlvYWcvWjE1aXMrUjBCenN0SGFG?= =?utf-8?B?anR0a09zSzgyVU12VkZJS3F1RCtUcjlTUitLU1QrVzlhRkl1aWRiWC8zRGl1?= =?utf-8?B?U2kzMlJWTGkzQVpvMnBOQnl3ejVZNjlSZ0ZEMU4wMklxR2lMbEIwV2xkenJM?= =?utf-8?B?ME9aUUIySWVTV2wyc3M2Tk10MWREalRpR1NLMXZPZXh6WXltaEdnVlhuVDlO?= =?utf-8?B?Q0JmY1hyVG40ZmVzQ001MElTMHBBdE1rTURSLy9KUklCQS9lQXEraVQ4NEE5?= =?utf-8?B?VkppRlVyMVNoZHRwVkFDV3JqVzI4UW1wOU9YUHQ0dks1UlNNZTB3STRRSU5L?= =?utf-8?B?eU5xQW9FMzJIV2czZys1ZXZsRnRxSWFCSzdLTEJpTEJjbllsMkNPOUJ3TlBJ?= =?utf-8?B?VnNSTWZnUFU1TlJVd2dzS0NFaDRQUnRrOHZ6ZU9IZ1ZjOGQ4aWtVTUV3RG1o?= =?utf-8?B?NDltNnJpWkVBNWtVU3RXRTduc1U2UFlQaEI0TktEQm44cEhUamJUckd6RXFw?= =?utf-8?B?SUZHODArdUdvdGI5V0J4RFZDelAyRDUzNXRZZVVsQjcvcVp1bDlnSzNMMHhZ?= =?utf-8?B?Y0c4WGtGeWFCMm5JTCtDQkQrajJKdTl6ZzRlclVtb3RZM3UxYzRPR0YrbDEr?= =?utf-8?B?YVFaeG1ycTFFcWoxVXNjVXZncjVZZDR5bm5DVGpxS1g4TVp2MmJVdGw2OFcw?= =?utf-8?B?OVY0RWxyMHRCTDlFZmYvOHJzM2hNWHdzSG5SWm0xdnV6SGZXTndsZlNMTmYr?= =?utf-8?B?WkthZjFUREpOMmxNQ1RZL0hIT2dIbHowNERQdmxWMUE5VGZzM284amJsdTBa?= =?utf-8?B?YUNNNTYyZ1RqenJET2F4QmFvemhLWVljV3V0MVRLWVd4em53dGczN3E1SGtv?= =?utf-8?B?N1NPMXlFRkZnckppQm1rSG5ZV3BYcnpFdlc1eXRhcFFWakFFWC9oVXBiRm05?= =?utf-8?B?bjV4ZnJKT3I3QWZ6Y3lKdXo1dmlPQStFMkhHcjQ0U2dERlBCQTFnUlZUV2Z5?= =?utf-8?B?QzByT2tJd3ZrTm9ncXQ0dzFMaTA1eHN0b3k5OFpKTDFuRVZoU2VteXFxMGh1?= =?utf-8?B?RERoc2d1KzJVVWFoeTc0R0hKVkJFVDBiOGpSTkVTSVNsYnBHTFI1b2EzMVNY?= =?utf-8?B?anRraGVkR2RLakJqS1FacXpUc0NxakxCcllzUmcwTWpZWStDczkzZi9wbFlp?= =?utf-8?B?U04zcWc2ZmhSSVp5L1VYNTl2aVE5UEs1bXgvZ3puRUlLdXJkQUI4SzFlMUJF?= =?utf-8?Q?G7beyJ?= 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)(7416014)(366016)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ckVCQktVTVJHVCs3dld1Zzd4cDlyL3FtKzYxV2c1QmNIS2Z0MVVueHNXM0lE?= =?utf-8?B?emZmd0g3eWJLaGZhSWJiT1RVcmpJaVBOQUU1ZWo1b2Zya3NJd3FnendqdjNL?= =?utf-8?B?OGZQdXRRZ3Y3Wk56RC9yZklpKzlJNGh1UGg2YkIzdlBNaERZZjNnMUE2aFM5?= =?utf-8?B?b3JKL0FjNDBtY20vMTM2aHFpdFZDUENXaHhFNXdGN205eXdxVG1oK2w1ZVNS?= =?utf-8?B?eFQ3anBhWXNwYjZQUXF2SlF1MTZuYzQyY0JTR3dOdVkvSUhhTnFwaE1BcVNC?= =?utf-8?B?aEltQlFNZ3RBUWVoODFOeFpRTlV1L0JMZlN2c1IyRCtUeTRoWmRGOCt4SEN5?= =?utf-8?B?WnF2VS8zYi9TekVxZkJFdGZBR2tVNU94WXA4U08waCtaTkdNRFB4UGpkQjJG?= =?utf-8?B?MGdsSWZGWGM1SW9CNGc5aHJyYlhRWGhybnVvWE1mVG43cFk4c2ZoU1JRZW81?= =?utf-8?B?OFZjeE1WU2lpTTlzQTRGTHh2MjFjVXBpeEEvdGJPUXhLWWdvVSs2dnFaajdj?= =?utf-8?B?cnN1M2tZMVBvV2txc2ozM3BzOExRSkt4NCtXYlM5bDhOM1UzOGRqdC8vUTNn?= =?utf-8?B?Y0RwaUkySXplSUFSaWo0QTZvMkdJd1BvS0p2djBUci81RUFjRG5jUFBTRFNa?= =?utf-8?B?alQvWnZhcTJtL3RicjFRNlRwT0NQWjZ6dXk3Mk1PdmxtU3pMMEhpK2tlYnVn?= =?utf-8?B?K3N1WlRyS0Vmb3AyblI2ejJXUE5RQm9zZkVNZ2x2VnVKZkZmK2UvNjFUT0FX?= =?utf-8?B?dGs0SnA4cW1IWktMRlhMbENzY0JKUkJlRlB1VVdjTkxrRThHVjlFbFduL1N4?= =?utf-8?B?RnlMWGgzM250UXk0QUFTQjBJemcvaU9rclhDZ0ZQeElsSUl0ZUQ3ZXZWT2No?= =?utf-8?B?ZHBaaENaeUtxYmVFZVIyeVdxekdSdmR5eURkNjRKcjR1UUpKUDR4QUhrR3Ry?= =?utf-8?B?Umx2TzlaQ2daUGg3ZWZuN0loaDVaZ1VIalBKaVpCUWNHRmx2N1QwZ2dLMnVJ?= =?utf-8?B?YnVQb3htejhsSmRnenBoOTBJZytzcGFQTFZkUjJYUmNscnQvaXVvTFZXUEw0?= =?utf-8?B?VlVnTUQxMXcvTGVzRFBpNVdlWTkzQzQ4L1FzUHViN3owdUxOU2FJK3YwQVVE?= =?utf-8?B?YWplSEd6Wm1saEpLSU1XbzZtU2VuL3pXYWE3cFV1MjBNOVp3VW5FUWUzekcr?= =?utf-8?B?RHQwMFRuZmdvT2FQNkU1anhEOHYydktOV0x6MUVpSXgxdUQ1WThIRGZkamo4?= =?utf-8?B?U3dkeFdxdVp6bGI1NGdjRkR3TGdNTVJhZEZXYmVaUWlWZFQ4WWhsdWRVQnFB?= =?utf-8?B?SHdDVnBPSThaL0lsYVNsVVBCeDdyQmVEY1U5d05rQVloUUMwKy80UksrWWRT?= =?utf-8?B?RTdkRjE4cjVKRERHZCt0SFJ1SDVlZUp3eVlWOGNUQnRzcXBSM1lGejlTL0V6?= =?utf-8?B?SkE5YXJUYXZOaVh5cVN3UkNGRU9LU21UMTNaWCtINW9ZZGJZWWpOemQzZlRW?= =?utf-8?B?aVNlWUJLalM5enVVMFZyOTh0MnRRNlRKNloya2liVFlUQ0ZSYXNEanI5cFdE?= =?utf-8?B?RGF1b25mbW8xQ1RyTUVkb0RHSjlncXN0NlJWbS80NDJUdW9wOXdFd2ZHL25B?= =?utf-8?B?UGxrY21ZNTAyMUNQLzJZWU12MnBYb1Fza2dMcGQ3cmNlNm9IUVhSWTJDK3ky?= =?utf-8?B?S3dCbWFnU3RtdXJxNkZ4c3RTNTgrdFNFNmx2QzEyNDYxSHZmaXBLc1NQajV3?= =?utf-8?B?YVB4ZldtREh2eTV2RU9WUVNUNkJXdFF5L2FLNVlLTVRvRUtvdlQzTUY5OTRM?= =?utf-8?B?QzcxK0UvOC9ES0ZpQ3FISGh1Y2U3L09TZzQySDlsVXpvZXBkRXBZa0NocHYx?= =?utf-8?B?eXFyL1dQL21mUDZTV3E1dTJxZVhGclJ5TVE5Z292bE5xbCtUREl3VGR6RHVD?= =?utf-8?B?OG5xWkdabUh5d0NVSEh5MUp4cWZPNWxtd2dyNmJjeFlEbVl3MmUvS0hieGZi?= =?utf-8?B?Smw0N1NleXNLR1pzR3BZRTRPTE11QmpZMFRIREJISEpCUGJVTngvVGpjcHVG?= =?utf-8?B?MHh6SkFvTDl6cUJ4Um1iOEF4ZU1NcjkvSnJIaGRsQllyMHczcFpJc1QwTmgy?= =?utf-8?B?bFByMjFPbWZscDBSZXlEcm9keXVLNktIdnUyTW80emZXVHlaZWFjZnhWYmZz?= =?utf-8?B?MjRrS2U5STEvZk1SVCtmQ05ZL2xHcEoyYXlRY0laa0FIMFlmWTZDUmRlc3I4?= =?utf-8?B?NVRCajBxaWF2TU00Qlo5azNLN2ZualpCT3dWSUU0YlhQNmhHZk5lZy9zTlhW?= =?utf-8?B?SXl0MWpKTTlueHc2YnE3K1ExdnNzdUhpYTdaZmZKa0ppSm04VEVkV2lkano4?= =?utf-8?Q?Pwjoa7fZkfzot1t0=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <231143C9ADE90C41B09879F3D40639D7@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: 593fd846-7aa5-46f4-c6a4-08de52bb83f6 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2026 15:50:45.9193 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ef1Rb0LGQvcAucEjsB9aDGXYlqAOdcE9OWKnVGwk6rAe+e/8A8NDPY9++WYRPB2ABZ33ycPNB3hUWpRiFdpFOTAHvH/J1TdQ4Ribaw1E39A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR03MB10091 DQoNCk9uIDEyLzAxLzIwMjYgMTg6MTMsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxMi4wMS4y MDI2IDE3OjEwLCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToNCj4+IE9uIDEyLzAxLzIwMjYgMTc6 NTYsIEphbiBCZXVsaWNoIHdyb3RlOg0KPj4+IE9uIDEyLjAxLjIwMjYgMTY6NTQsIE9sZWtzaWkg TW9pc2llaWV2IHdyb3RlOg0KPj4+PiBPbiAxMi8wMS8yMDI2IDE3OjQwLCBKYW4gQmV1bGljaCB3 cm90ZToNCj4+Pj4+IE9uIDEyLjAxLjIwMjYgMTY6MTYsIE9sZWtzaWkgTW9pc2llaWV2IHdyb3Rl Og0KPj4+Pj4+IE9uIDA2LzExLzIwMjUgMTI6MDksIEphbiBCZXVsaWNoIHdyb3RlOg0KPj4+Pj4+ PiBPbiAwMS4xMS4yMDI1IDEyOjU2LCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToNCj4+Pj4+Pj4+ IEBAIC04MjcsNyArODI4LDMyIEBAIGxvbmcgZG9fZG9tY3RsKFhFTl9HVUVTVF9IQU5ETEVfUEFS QU0oeGVuX2RvbWN0bF90KSB1X2RvbWN0bCkNCj4+Pj4+Pj4+ICAgICAgICAgIGNhc2UgWEVOX0RP TUNUTF90ZXN0X2Fzc2lnbl9kZXZpY2U6DQo+Pj4+Pj4+PiAgICAgICAgICBjYXNlIFhFTl9ET01D VExfZGVhc3NpZ25fZGV2aWNlOg0KPj4+Pj4+Pj4gICAgICAgICAgY2FzZSBYRU5fRE9NQ1RMX2dl dF9kZXZpY2VfZ3JvdXA6DQo+Pj4+Pj4+PiArICAgICAgICBpbnQgcmV0MTsNCj4+Pj4+Pj4+ICsN Cj4+Pj4+Pj4+ICsgICAgICAgIC8qDQo+Pj4+Pj4+PiArICAgICAgICAgKiBBZGQgY2hhaW5lZCBo YW5kbGluZyBvZiBhc3NpZ25lZCBEVCBkZXZpY2VzIHRvIHN1cHBvcnQNCj4+Pj4+Pj4+ICsgICAg ICAgICAqIGFjY2Vzcy1jb250cm9sbGVyIGZ1bmN0aW9uYWxpdHkgdGhyb3VnaCBTQ0kgZnJhbWV3 b3JrLCBzbw0KPj4+Pj4+Pj4gKyAgICAgICAgICogRFQgZGV2aWNlIGFzc2lnbiByZXF1ZXN0IGNh biBiZSBwYXNzZWQgdG8gRlcgZm9yIHByb2Nlc3NpbmcgYW5kDQo+Pj4+Pj4+PiArICAgICAgICAg KiBlbmFibGluZyBWTSBhY2Nlc3MgdG8gcmVxdWVzdGVkIGRldmljZS4NCj4+Pj4+Pj4+ICsgICAg ICAgICAqIFRoZSBhY2Nlc3MtY29udHJvbGxlciBEVCBkZXZpY2UgcHJvY2Vzc2luZyBpcyBjaGFp bmVkIGJlZm9yZSBJT01NVQ0KPj4+Pj4+Pj4gKyAgICAgICAgICogcHJvY2Vzc2luZyBwcmVzZXJ2 aW5nIHJldHVybiBjb2RlIGFuZCBleHBlY3RlZCB0byBiZSBleGVjdXRlZCBmb3INCj4+Pj4+Pj4+ ICsgICAgICAgICAqIGFueSBEVCBkZXZpY2UgcmVnYXJkbGVzcyBpZiBEVCBkZXZpY2UgaXMgcHJv dGVjdGVkIGJ5IElPTU1VIG9yDQo+Pj4+Pj4+PiArICAgICAgICAgKiBub3QgKG9yIElPTU1VIGlz IGRpc2FibGVkKS4NCj4+Pj4+Pj4+ICsgICAgICAgICAqLw0KPj4+Pj4+Pj4gKyAgICAgICAgcmV0 MSA9IHNjaV9kb19kb21jdGwob3AsIGQsIHVfZG9tY3RsKTsNCj4+Pj4+Pj4gV2h5IHdvdWxkIHRo aXMgbm90IGJlIHRoZSBpbml0aWFsaXplciBvZiB0aGUgbmV3IHZhcmlhYmxlPyAoSSBhbHNvIGRv bid0IHRoaW5rDQo+Pj4+Pj4+IHRoYXQgd2UndmUgZGVjaWRlZCB0byBwZXJtaXQgdmFyaWFibGUg ZGVjbGFyYXRpb25zIGF0IG90aGVyIHRoYW4gdGhlIHRvcCBvZg0KPj4+Pj4+PiBzY29wZXMgb3Ig d2l0aGluIGUuZy4gYSBmb3IoKSBsb29wIGNvbnRyb2wgY29uc3RydWN0LikNCj4+Pj4+Pj4NCj4+ Pj4+PiArDQo+Pj4+Pj4+PiAgICAgICAgICAgICAgcmV0ID0gaW9tbXVfZG9fZG9tY3RsKG9wLCBk LCB1X2RvbWN0bCk7DQo+Pj4+Pj4+PiArICAgICAgICBpZiAoIHJldCA8IDAgKQ0KPj4+Pj4+Pj4g KyAgICAgICAgICAgIHJldHVybiByZXQ7DQo+Pj4+Pj4+IFdoeSB3b3VsZCB5b3UgaW52b2tlIGJv dGggaW4gYWxsIGNhc2VzPyBJZiBzY2lfZG9fZG9tY3RsKCkgaGFuZGxlZCB0aGUgcmVxdWVzdCwN Cj4+Pj4+Pj4gdGhlcmUgaXNuJ3QgYW55IHBvaW50IGluIGFsc28gaW52b2tpbmcgaW9tbXVfZG9f ZG9tY3RsKCksIGlzIHRoZXJlPyBPciBlbHNlIGlzDQo+Pj4+Pj4+IHRoZXJlIG1heWJlIHNvbWUg Y3J1Y2lhbCBhc3BlY3QgbWlzc2luZyBmcm9tIHRoZSBkZXNjcmlwdGlvbiAob3Igbm90IGV4cGxp Y2l0DQo+Pj4+Pj4+IGVub3VnaCB0aGVyZSBmb3IgYSBub24tU0NJIHBlcnNvbiBsaWtlIG1lKT8N Cj4+Pj4+Pj4NCj4+Pj4+Pj4gQWxzbyB0aGlzIGRvZXNuJ3QgbG9vayB0byBmaXQgdGhlIGRlc2Ny aXB0aW9uIHNheWluZyAiVGhlIFNDSSBhY2Nlc3MtY29udHJvbGxlcg0KPj4+Pj4+PiBEVCBkZXZp Y2UgcHJvY2Vzc2luZyBpcyBjaGFpbmVkIGFmdGVyIElPTU1VIHByb2Nlc3NpbmcgLi4uIg0KPj4+ Pj4+Pg0KPj4+Pj4+IFdlIGNhbGwgYm90aCBiZWNhdXNlIFNDSSBhbmQgSU9NTVUgY292ZXIgZGlm ZmVyZW50IGNvbmNlcm5zIGFuZCBhIERUDQo+Pj4+Pj4gZGV2aWNlIG1heSBuZWVkDQo+Pj4+Pj4g Ym90aDogU0NJIGZvciBGVy1tZWRpYXRlZCBhY2Nlc3MgY29udHJvbCAocG93ZXIvY2xvY2tzL3Jl c2V0KSBhbmQgSU9NTVUNCj4+Pj4+PiBmb3IgRE1BIGlzb2xhdGlvbi4NCj4+Pj4+PiBTQ0kgcmV0 dXJuaW5nIHN1Y2Nlc3MgZG9lcyBub3QgbWVhbiB0aGUgSU9NTVUgd29yayBpcyByZWR1bmRhbnQu DQo+Pj4+PiBDYW4gdGhlIGNvbW1lbnQgdGhlbiBwbGVhc2UgYmUgdXBkYXRlZCB0byBwcm9wZXJs eSBjYWxsIG91dCB0aGlzIGR1YWwNCj4+Pj4+IHJlcXVpcmVtZW50Pw0KPj4+PiBZZXMsIGZvciBz dXJlLg0KPj4+Pj4+IC0gc2NpX2RvX2RvbWN0bCgpIHJldHVybnMgLUVOWElPIHdoZW4gaXQgaGFz IG5vdGhpbmcgdG8gZG8gKG5vbi1EVCwgbm8NCj4+Pj4+PiBtZWRpYXRvciwgbWVkaWF0b3IgbGFj a3MgYXNzaWduIGhvb2spLg0KPj4+Pj4+IFRoYXQgaXMgdGhlIOKAnG5vdCBoYW5kbGVkIGJ5IFND SeKAnSBzZW50aW5lbDsgaW4gdGhhdCBjYXNlIHRoZSBjb2RlDQo+Pj4+Pj4gcHJvY2VlZHMgdG8g SU9NTVUgbm9ybWFsbHkuDQo+Pj4+Pj4gLcKgIFdoZW4gc2NpX2RvX2RvbWN0bCgpIHN1Y2NlZWRz ICgwKSwgdGhlIGRldmljZSBtYXkgc3RpbGwgcmVxdWlyZSBJT01NVQ0KPj4+Pj4+IHByb2dyYW1t aW5nDQo+Pj4+Pj4gKGUuZy4sIERUIGRldmljZSBoYXMgYW4gaW9tbXVzIHByb3BlcnR5KS4gU2tp cHBpbmcgaW9tbXVfZG9fZG9tY3RsKCkNCj4+Pj4+PiB3b3VsZCBsZWF2ZSBETUEgaXNvbGF0aW9u IHVucHJvZ3JhbW1lZC4NCj4+Pj4+Pg0KPj4+Pj4+IFRoZSBmaW5hbCBpZiAocmV0MSAhPSAtRU5Y SU8pIHJldCA9IHJldDE7IGVuc3VyZXMgdGhhdCBpZiBib3RoIHBhdGhzIHJhbg0KPj4+Pj4+IGFu ZCBJT01NVSBzdWNjZWVkZWQsDQo+Pj4+Pj4gYW4gU0NJIGZhaWx1cmUgaXMgc3RpbGwgcmVwb3J0 ZWQgdG8gdGhlIGNhbGxlci4NCj4+Pj4+Pg0KPj4+Pj4+IERldmljZS10cmVlIGV4YW1wbGVzIHRv IGlsbHVzdHJhdGUgdGhlIGR1YWwgcm9sZXM6DQo+Pj4+Pj4gMS4gQWNjZXNzLWNvbnRyb2xsZWQg RFQgZGV2aWNlIChub3QgbmVjZXNzYXJpbHkgSU9NTVUtcHJvdGVjdGVkKToNCj4+Pj4+Pg0KPj4+ Pj4+IGkyYzM6IGkyY0BlNjUwODAwMCB7DQo+Pj4+Pj4gICAgIMKgwqDCoCBjb21wYXRpYmxlID0g InJlbmVzYXMscmNhci1nZW4zLWkyYyI7DQo+Pj4+Pj4gICAgIMKgwqDCoCByZWcgPSA8MCAweGU2 NTA4MDAwIDAgMHg0MD47DQo+Pj4+Pj4gICAgIMKgwqDCoCBwb3dlci1kb21haW5zID0gPCZzY21p X3BkIDU+O8KgwqDCoMKgwqAgLy8gRlctbWFuYWdlZCBwb3dlciBkb21haW4NCj4+Pj4+PiAgICAg wqDCoMKgIGNsb2NrcyA9IDwmc2NtaV9jbGsgMTI+Ow0KPj4+Pj4+ICAgICDCoMKgwqAgY2xvY2st bmFtZXMgPSAiZmNrIjsNCj4+Pj4+PiAgICAgwqDCoMKgIGFjY2Vzcy1jb250cm9sbGVycyA9IDwm c2NtaV94ZW4gMD47DQo+Pj4+Pj4gICAgIMKgwqDCoCAvLyBubyBpb21tdXMgcHJvcGVydHk6IFND SSBtYXkgbmVlZCB0byBhdXRob3JpemUvcG93ZXIgdGhpcyBkZXZpY2U7DQo+Pj4+Pj4gSU9NTVUg aGFzIG5vdGhpbmcgdG8gZG8NCj4+Pj4+PiB9Ow0KPj4+Pj4+DQo+Pj4+Pj4gMi4gSU9NTVUtcHJv dGVjdGVkIERUIGRldmljZSB0aGF0IHN0aWxsIG1heSBuZWVkIFNDSSBtZWRpYXRpb246DQo+Pj4+ Pj4gdnB1OiB2aWRlb0BlNmVmMDAwMCB7DQo+Pj4+Pj4gICAgIMKgwqDCoCBjb21wYXRpYmxlID0g InJlbmVzYXMscmNhci12cHUiOw0KPj4+Pj4+ICAgICDCoMKgwqAgcmVnID0gPDAgMHhlNmVmMDAw MCAwIDB4MTAwMDA+Ow0KPj4+Pj4+ICAgICDCoMKgwqAgaW9tbXVzID0gPCZpcG1tdSAwIDA+O8Kg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAvLyBuZWVkcyBJT01NVSBtYXBwaW5nIGZvciBETUENCj4+ Pj4+PiBpc29sYXRpb24NCj4+Pj4+PiAgICAgwqDCoMKgIHBvd2VyLWRvbWFpbnMgPSA8JnNjbWlf cGQgNz47wqDCoMKgwqDCoCAvLyBGVy1tYW5hZ2VkIHBvd2VyL2Nsb2NrL3Jlc2V0DQo+Pj4+Pj4g ICAgIMKgwqDCoCBjbG9ja3MgPSA8JnNjbWlfY2xrIDM0PjsNCj4+Pj4+PiAgICAgwqAgwqAgYWNj ZXNzLWNvbnRyb2xsZXJzID0gPCZzY21pX3hlbiAwPjsNCj4+Pj4+PiAgICAgwqDCoMKgIGNsb2Nr LW5hbWVzID0gInZwdSI7DQo+Pj4+Pj4gfTsNCj4+Pj4+Pj4+IC0tLSBhL3hlbi9kcml2ZXJzL3Bh c3N0aHJvdWdoL2RldmljZV90cmVlLmMNCj4+Pj4+Pj4+ICsrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0 aHJvdWdoL2RldmljZV90cmVlLmMNCj4+Pj4+Pj4+IEBAIC0zNzksNiArMzc5LDEyIEBAIGludCBp b21tdV9kb19kdF9kb21jdGwoc3RydWN0IHhlbl9kb21jdGwgKmRvbWN0bCwgc3RydWN0IGRvbWFp biAqZCwNCj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgYnJlYWs7DQo+Pj4+Pj4+PiAgICAgICAg ICAgICAgfQ0KPj4+Pj4+Pj4gICAgICANCj4+Pj4+Pj4+ICsgICAgICAgIGlmICggIWR0X2Rldmlj ZV9pc19wcm90ZWN0ZWQoZGV2KSApDQo+Pj4+Pj4+PiArICAgICAgICB7DQo+Pj4+Pj4+PiArICAg ICAgICAgICAgcmV0ID0gMDsNCj4+Pj4+Pj4+ICsgICAgICAgICAgICBicmVhazsNCj4+Pj4+Pj4+ ICsgICAgICAgIH0NCj4+Pj4+Pj4+ICsNCj4+Pj4+Pj4+ICAgICAgICAgICAgICByZXQgPSBpb21t dV9hc3NpZ25fZHRfZGV2aWNlKGQsIGRldik7DQo+Pj4+Pj4+PiAgICAgIA0KPj4+Pj4+Pj4gICAg ICAgICAgICAgIGlmICggcmV0ICkNCj4+Pj4+Pj4gSG93IGFyZSBEVCBhbmQgUENJIGRpZmZlcmVu dCBpbiB0aGlzIHJlZ2FyZD8NCj4+Pj4+PiBQbGVhc2UgZmluZCBleGFtcGxlcyBhYm92ZS4NCj4+ Pj4+IFNvcnJ5LCBidXQgSSBjYW4ndCBzcG90IGFueXRoaW5nIFBDSS1pc2ggaW4gdGhlIGV4YW1w bGVzIGFib3ZlLiBUaGVuIGFnYWluIEkNCj4+Pj4+IGFsc28gbm8gbG9uZ2VyIHJlY2FsbCB3aHkg SSBjb21wYXJlZCB3aXRoIFBDSSBoZXJlLiBPaCwgcGVyaGFwcyBiZWNhdXNlIHRoZQ0KPj4+Pj4g UENJIHNpZGUgaXNuJ3QgYmVpbmcgbW9kaWZpZWQgYXQgYWxsLg0KPj4+Pj4NCj4+Pj4gQ29ycmVj dCwgcGNpIGNvZGUgd2Fzbid0IHRvdWNoZWQgYnkgdGhlc2UgY2hhbmdlcy4NCj4+PiBZZXQgbXkg cXVlc3Rpb24gYm9pbHMgZG93biB0byAid2h5Iiwgbm90ICJ3aGV0aGVyIi4NCj4+Pg0KPj4gSSBo YXZlIHJldmlld2VkIHRoZSBwcmV2aW91cyB2ZXJzaW9ucyBvZiB0aGUgcGF0Y2ggc2VyaWUgYW5k IGNvdWxkIG5vdA0KPj4gZmluZCBhbnkgcXVlc3Rpb25zIHJlbGF0ZWQgdG8gUENJIHByaW9yIHRv IHRoaXMgc2VyaWVzLiBUaGVyZWZvcmUsICJIb3cNCj4+IGFyZSBEVCBhbmQgUENJIGRpZmZlcmVu dCBpbiB0aGlzIHJlZ2FyZD8iIGFwcGVhcnMgdG8gYmUgdGhlIGZpcnN0DQo+PiBxdWVzdGlvbiBj b25jZXJuaW5nIFBDSS4NCj4gUXVpdGUgcG9zc2libGUsIHlldCBkb2VzIHRoYXQgc29tZWhvdyBl bGltaW5hdGUgdGhlIG5lZWQgdG8gYWRkcmVzcyBpdD8gSSdtDQo+IHRyeWluZyB0byB1bmRlcnN0 YW5kIHdoeSB0aGUgcmVzcGVjdGl2ZSBQQ0kgY29kZSBpc24ndCBiZWluZyB0b3VjaGVkLg0KPg0K PiBKYW4NClhFTl9ET01DVExfYXNzaWduX2RldmljZSBkaXNwYXRjaDogd2Ugbm93IGNoYWluIHNj aV9kb19kb21jdGwgZmlyc3QsIA0KdGhlbiBpb21tdV9kb19kb21jdGwuDQppb21tdV9kb19kb21j dGwgZmlyc3QgdHJpZXMgaW9tbXVfZG9fcGNpX2RvbWN0bCAod2hlbiBDT05GSUdfSEFTX1BDSSkg DQphbmQgZmFsbHMgYmFjayB0byBpb21tdV9kb19kdF9kb21jdGwgb25seSBpZiBQQ0kgcmV0dXJu cyAtRU5PREVWLg0KVGhlIG5ldyBkdF9kZXZpY2VfaXNfcHJvdGVjdGVkKCkgYnlwYXNzIGluIGlv bW11X2RvX2R0X2RvbWN0bCBvbmx5IA0KYXBwbGllcyB0byBEVC1kZXNjcmliZWQgZGV2aWNlczsg U0NJIHBhcmFtZXRlcnMgYXJlIGNhcnJpZWQgdmlhIERUIG5vZGVzLg0KUENJIGRldmljZXMgaGFu ZGxlZCBieSBpb21tdV9kb19wY2lfZG9tY3RsIGRvIG5vdCBjYXJyeSBEVC9TQ0kgbWV0YWRhdGEg DQppbiB0aGlzIHBhdGgsIHNvIHRoZXJlIGlzIG5vIG5vdGlvbiBvZiDigJxTQ0kgcGFyYW1ldGVy cyBvbiBhIA0Kbm9uLUlPTU1VLXByb3RlY3RlZCBQQ0kgZGV2aWNl4oCdIGZvciBpdCB0byBpbnRl cnByZXQgb3IgdG8gc2tpcC4gVGhlIFBDSSANCnBhdGggc2hvdWxkIGNvbnRpbnVlIHRvIHJlcG9y dCBlcnJvcnMgaWYgYXNzaWdubWVudCBjYW5ub3QgYmUgcGVyZm9ybWVkIA0KYnkgdGhlIElPTU1V IGxheWVyLg0KU28gd2Ugc2hvdWxkIGxlYXZlIGlvbW11X2RvX3BjaV9kb21jdGwgdW5jaGFuZ2Vk OyB0aGUgU0NJL0RULXNwZWNpZmljIA0KcmVsYXhhdGlvbnMgYmVsb25nIG9ubHkgaW4gdGhlIERU IHBhdGguDQpBbHNvwqAgU0NJIGhhbmRsaW5nIG9ubHkgZXhpc3RzIHdoZW4gRFQgaXMgcHJlc2Vu dC4NCg0KQlIsIE9sZWtzaWkuDQo= From xen-devel-bounces@lists.xenproject.org Tue Jan 13 16:08:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 16:08:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202003.1517607 (Exim 4.92) (envelope-from ) id 1vfgwM-0006zU-GH; Tue, 13 Jan 2026 16:08:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202003.1517607; Tue, 13 Jan 2026 16:08:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfgwM-0006zN-Cu; Tue, 13 Jan 2026 16:08:18 +0000 Received: by outflank-mailman (input) for mailman id 1202003; Tue, 13 Jan 2026 16:08: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 1vfgwL-0006zF-Ax for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 16:08:17 +0000 Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [2a00:1450:4864:20::441]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1117fe21-f09a-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 17:08:15 +0100 (CET) Received: by mail-wr1-x441.google.com with SMTP id ffacd0b85a97d-432d256c2a9so4086499f8f.3 for ; Tue, 13 Jan 2026 08:08:15 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5df9c5sm46202980f8f.22.2026.01.13.08.08.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 08:08:14 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1117fe21-f09a-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768320495; x=1768925295; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=AbU4BY2euF9GgZDEbcuk9Z4wbGADyfZOyW34Xh2W4Yo=; b=LEkBvESIJMHLc0+77XYQ9AFv+mHf9dtseyIZ2la/WdXhVG2M5kyg6NeJee64Mr45HS 7Ev8+5ObW8LA1kkFuU084OSawcmYbWB2pVIlPr++1DUmPjR1oES44xC5HSM3ye+FPTDg QsWeei7KA6paRSBS66H0TqFytReKhue5E6iVSNlchvhgqQM2liNgkT8Yuo+8KHJfyoQX dXKbVABCVZzwzYQIFzmskHLTHOMfKbxcUUqFh5cCgj9ljR/qn79/B+4+D67jsdXBYjjY qNsMPRsmWwgNORwbhnVXaQ4TykrAb/zrUgrSjUNsHUfV5HTI/rIQZQdzxQhhxwg0YCiV 2aVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768320495; x=1768925295; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=AbU4BY2euF9GgZDEbcuk9Z4wbGADyfZOyW34Xh2W4Yo=; b=cJwmC8iBau8gofRJVY21NEWAH1+3olaM78Yc35RfAzQlhHsiCkCWZNygUJhR03081V ANTAocCcAbRKtPwulWtXlR/cofXDcCfTfAO6dyvPb4A1gfY0rYcJUKT52obPtiKR969Y ItU3HTkRdx9LGz67vuywUx4lmolAUuYeQ28/cVUshit0XUEP9a7BnqkOJA4uG0pAnOtu cF6PmcTPlUwhih6CbZj481XL4HhbLRxpBpd+S3KLU/dujZol0TgCyOEz/PwnOsRfu/qz Auz43u3oqZoc8TNdKVxfaKlXal3Qky8naDnDJVBvseGHTI5xEGhhV3EqnuleuTTljixL e5Yw== X-Forwarded-Encrypted: i=1; AJvYcCWe2+t40w13qG1ImBne+xxCLHh3ULOlxWaS6EPwVX3+wb1Iop9dY0b4HCKa2q6X/SvVfNWZbOOJ9Hg=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzi6H+y/JXvdQENi+fABsdO0iX21xX8RupgthiHSnbS1JY0zwlG OAIH6djrVoW8dZsxILM5GpCB9HnAsVW6mfsQcr2+TQ8kZ2yP+NwvU96oPF6ejqudww== X-Gm-Gg: AY/fxX7H2td8rRxQUCdCyMwYeAo3G3DJpP6Z21NRYdl7B+f2ihYkfCqn3fNWsWtF4Cw qvv6tuvy7bZMdQA2KJ/2HiIOzY1qHHQNW3VsVca0gJN19iTkrHTqa3nQAms+dIYYs/eMOiM1v4u p7AtqqBwPSbIOYPYXiousZQTSwQrRHkMFpjtSd78M7VngInId8C0lqYCc3oKMJzzGi+PxMehIAu 93ciN6v+il5q72JAbSac5samvZbMsY69icT9dKnpyC7Qcmu7NhBZg3kDg6YY/48a2EYYsKy0yQ6 5YSXpo9JpG2ijAoqHGSUcdIMe/r2PqhI58+oNhtHAbMaphS+zNqbaZe5+u5akGbSqr5qFDDTUuc hjKJoO7aOr6ffS4KSl9U8f8bIhv1fGiB7uxfMBh1ldwIKrljakcjXZfFjADfPyH8roO58CV4pUG wTiWBgYhwfDI/hwFd80zZ45cgXLBW3ScLv9zr3aHymz7+SfMneTjPFjENsCsdfVdOcH4k1f5rwy sg= X-Google-Smtp-Source: AGHT+IEaGzmZuj5vrsrc8lKuzDGqnhkeeZthSUWtmLXmrWQpsKjXgSgeqpkHk9PVx8M7Z4yaJeuzTA== X-Received: by 2002:a5d:64e3:0:b0:430:f68f:ee7d with SMTP id ffacd0b85a97d-432c379b79cmr29190345f8f.47.1768320494490; Tue, 13 Jan 2026 08:08:14 -0800 (PST) Message-ID: <93cf250d-864d-4375-b05a-e48d3d56dac9@suse.com> Date: Tue, 13 Jan 2026 17:08:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/5] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu To: Oleksii Moisieiev Cc: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" References: <9598b2e2-7df8-40c5-82cb-c097121af763@suse.com> <5d8f55a6-7182-4e9d-a139-96fddb9450f8@epam.com> <98f5e8f0-070c-4be5-9baf-46278de8093d@suse.com> <99586f5c-d76b-4cbe-9fbd-c87e86bb236a@epam.com> <7cbda859-4257-499e-86e0-a0d001fd49c9@suse.com> <9631b854-2fc6-41aa-8b12-1e7283b22246@epam.com> <4807d2d3-fae7-45a4-b7c7-e101a95a6b58@suse.com> <87ba1c35-f1f3-4a52-ba76-306a538ad0c6@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: <87ba1c35-f1f3-4a52-ba76-306a538ad0c6@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 13.01.2026 16:50, Oleksii Moisieiev wrote: > > > On 12/01/2026 18:13, Jan Beulich wrote: >> On 12.01.2026 17:10, Oleksii Moisieiev wrote: >>> On 12/01/2026 17:56, Jan Beulich wrote: >>>> On 12.01.2026 16:54, Oleksii Moisieiev wrote: >>>>> On 12/01/2026 17:40, Jan Beulich wrote: >>>>>> On 12.01.2026 16:16, Oleksii Moisieiev wrote: >>>>>>> On 06/11/2025 12:09, Jan Beulich wrote: >>>>>>>> On 01.11.2025 12:56, Oleksii Moisieiev wrote: >>>>>>>>> @@ -827,7 +828,32 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) >>>>>>>>> case XEN_DOMCTL_test_assign_device: >>>>>>>>> case XEN_DOMCTL_deassign_device: >>>>>>>>> case XEN_DOMCTL_get_device_group: >>>>>>>>> + int ret1; >>>>>>>>> + >>>>>>>>> + /* >>>>>>>>> + * Add chained handling of assigned DT devices to support >>>>>>>>> + * access-controller functionality through SCI framework, so >>>>>>>>> + * DT device assign request can be passed to FW for processing and >>>>>>>>> + * enabling VM access to requested device. >>>>>>>>> + * The access-controller DT device processing is chained before IOMMU >>>>>>>>> + * processing preserving return code and expected to be executed for >>>>>>>>> + * any DT device regardless if DT device is protected by IOMMU or >>>>>>>>> + * not (or IOMMU is disabled). >>>>>>>>> + */ >>>>>>>>> + ret1 = sci_do_domctl(op, d, u_domctl); >>>>>>>> Why would this not be the initializer of the new variable? (I also don't think >>>>>>>> that we've decided to permit variable declarations at other than the top of >>>>>>>> scopes or within e.g. a for() loop control construct.) >>>>>>>> >>>>>>> + >>>>>>>>> ret = iommu_do_domctl(op, d, u_domctl); >>>>>>>>> + if ( ret < 0 ) >>>>>>>>> + return ret; >>>>>>>> Why would you invoke both in all cases? If sci_do_domctl() handled the request, >>>>>>>> there isn't any point in also invoking iommu_do_domctl(), is there? Or else is >>>>>>>> there maybe some crucial aspect missing from the description (or not explicit >>>>>>>> enough there for a non-SCI person like me)? >>>>>>>> >>>>>>>> Also this doesn't look to fit the description saying "The SCI access-controller >>>>>>>> DT device processing is chained after IOMMU processing ..." >>>>>>>> >>>>>>> We call both because SCI and IOMMU cover different concerns and a DT >>>>>>> device may need >>>>>>> both: SCI for FW-mediated access control (power/clocks/reset) and IOMMU >>>>>>> for DMA isolation. >>>>>>> SCI returning success does not mean the IOMMU work is redundant. >>>>>> Can the comment then please be updated to properly call out this dual >>>>>> requirement? >>>>> Yes, for sure. >>>>>>> - sci_do_domctl() returns -ENXIO when it has nothing to do (non-DT, no >>>>>>> mediator, mediator lacks assign hook). >>>>>>> That is the “not handled by SCI” sentinel; in that case the code >>>>>>> proceeds to IOMMU normally. >>>>>>> -  When sci_do_domctl() succeeds (0), the device may still require IOMMU >>>>>>> programming >>>>>>> (e.g., DT device has an iommus property). Skipping iommu_do_domctl() >>>>>>> would leave DMA isolation unprogrammed. >>>>>>> >>>>>>> The final if (ret1 != -ENXIO) ret = ret1; ensures that if both paths ran >>>>>>> and IOMMU succeeded, >>>>>>> an SCI failure is still reported to the caller. >>>>>>> >>>>>>> Device-tree examples to illustrate the dual roles: >>>>>>> 1. Access-controlled DT device (not necessarily IOMMU-protected): >>>>>>> >>>>>>> i2c3: i2c@e6508000 { >>>>>>>     compatible = "renesas,rcar-gen3-i2c"; >>>>>>>     reg = <0 0xe6508000 0 0x40>; >>>>>>>     power-domains = <&scmi_pd 5>;      // FW-managed power domain >>>>>>>     clocks = <&scmi_clk 12>; >>>>>>>     clock-names = "fck"; >>>>>>>     access-controllers = <&scmi_xen 0>; >>>>>>>     // no iommus property: SCI may need to authorize/power this device; >>>>>>> IOMMU has nothing to do >>>>>>> }; >>>>>>> >>>>>>> 2. IOMMU-protected DT device that still may need SCI mediation: >>>>>>> vpu: video@e6ef0000 { >>>>>>>     compatible = "renesas,rcar-vpu"; >>>>>>>     reg = <0 0xe6ef0000 0 0x10000>; >>>>>>>     iommus = <&ipmmu 0 0>;             // needs IOMMU mapping for DMA >>>>>>> isolation >>>>>>>     power-domains = <&scmi_pd 7>;      // FW-managed power/clock/reset >>>>>>>     clocks = <&scmi_clk 34>; >>>>>>>     access-controllers = <&scmi_xen 0>; >>>>>>>     clock-names = "vpu"; >>>>>>> }; >>>>>>>>> --- a/xen/drivers/passthrough/device_tree.c >>>>>>>>> +++ b/xen/drivers/passthrough/device_tree.c >>>>>>>>> @@ -379,6 +379,12 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d, >>>>>>>>> break; >>>>>>>>> } >>>>>>>>> >>>>>>>>> + if ( !dt_device_is_protected(dev) ) >>>>>>>>> + { >>>>>>>>> + ret = 0; >>>>>>>>> + break; >>>>>>>>> + } >>>>>>>>> + >>>>>>>>> ret = iommu_assign_dt_device(d, dev); >>>>>>>>> >>>>>>>>> if ( ret ) >>>>>>>> How are DT and PCI different in this regard? >>>>>>> Please find examples above. >>>>>> Sorry, but I can't spot anything PCI-ish in the examples above. Then again I >>>>>> also no longer recall why I compared with PCI here. Oh, perhaps because the >>>>>> PCI side isn't being modified at all. >>>>>> >>>>> Correct, pci code wasn't touched by these changes. >>>> Yet my question boils down to "why", not "whether". >>>> >>> I have reviewed the previous versions of the patch serie and could not >>> find any questions related to PCI prior to this series. Therefore, "How >>> are DT and PCI different in this regard?" appears to be the first >>> question concerning PCI. >> Quite possible, yet does that somehow eliminate the need to address it? I'm >> trying to understand why the respective PCI code isn't being touched. >> > XEN_DOMCTL_assign_device dispatch: we now chain sci_do_domctl first, > then iommu_do_domctl. > iommu_do_domctl first tries iommu_do_pci_domctl (when CONFIG_HAS_PCI) > and falls back to iommu_do_dt_domctl only if PCI returns -ENODEV. > The new dt_device_is_protected() bypass in iommu_do_dt_domctl only > applies to DT-described devices; SCI parameters are carried via DT nodes. > PCI devices handled by iommu_do_pci_domctl do not carry DT/SCI metadata > in this path, so there is no notion of “SCI parameters on a > non-IOMMU-protected PCI device” for it to interpret or to skip. The PCI > path should continue to report errors if assignment cannot be performed > by the IOMMU layer. > So we should leave iommu_do_pci_domctl unchanged; the SCI/DT-specific > relaxations belong only in the DT path. > Also  SCI handling only exists when DT is present. Can an abridged variant of this please be added to the description? Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 13 16:10:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 16:10:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202015.1517616 (Exim 4.92) (envelope-from ) id 1vfgyR-000056-U5; Tue, 13 Jan 2026 16:10:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202015.1517616; Tue, 13 Jan 2026 16:10: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 1vfgyR-00004y-RR; Tue, 13 Jan 2026 16:10:27 +0000 Received: by outflank-mailman (input) for mailman id 1202015; Tue, 13 Jan 2026 16:10: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 1vfgyQ-00004q-91 for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 16:10: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 5bbff2f7-f09a-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 17:10:20 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by VI2PR03MB10666.eurprd03.prod.outlook.com (2603:10a6:800:27d::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 16:10: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%5]) with mapi id 15.20.9499.005; Tue, 13 Jan 2026 16:10: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: 5bbff2f7-f09a-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=y5YnTkuMRMqBi1UyU/xVLoOsTHDWp0e8uTmsFqS448DMNYvKSDfngTvSsHeCSMQVLepLuUYtZ60w8t9Fi0XvLvnsXca67EDfybjpEBAVYcogBiiBBkoTjFmSOvTikza/PLz6kWFG9ztH8TbTKTzgqj/AebTpWQuCIy9w0ylUAKJ5F6KD+N4PfN90i/OupLFbqhTYb+j/BWElqfSJq03vRSW6BN2+3aKJujofyhYmDMLRBkrwjmHcJXlN5UjPq8FpFBUmE7HprQHiG34oIhenqbbzNaQt1rvmBgq/xA4N+er8x8F5oC97jYt2X1kH3RttyI/R22+Ns+mQqx8e/Tcg9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=n6m8eW87yuYQZbQyAsea/G2lMKbjXSvEJZzdQaTxWZk=; b=WSw8qUERXeO7u0IEt0rVEyfKh8NVxwFr+QB/eiAEkVBEWNhy/n502jfHDuwXR0ENdxYAw/cTbCwR0wGxt/eZM/ba6/g8XQ8okWGtqGtOE+qIOUSwNLTtpeTHJYQCTy9HfBuGgEOJ3Zv/C6ErsHnsH5oUHn1XyES8e4tnpkPxEHkSQtAeBOgu0RvuK8kdXG33jpvoqFESP14OvL79CRW1I4zeevOPYFlyzUejAwfkxVa23EpwSeLNZQ51LGLC0nIghqpgF7CHarU/KcnAj32Ncc6PVwj6C7HjnYLUgv/abVlYDFliH9v8XDFTWWMBJxhpYnIkf7yx3WMBbLoYFSSaxA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n6m8eW87yuYQZbQyAsea/G2lMKbjXSvEJZzdQaTxWZk=; b=C8CjESClvZxGdbZMg25QUO4IrfQw+PVYEhHOx20PnonN+ibtS5fpCD+r36HDRLWhxZKqVaWZc8/+l0SJn+Eflb4G2CHWDIDltCulf3OFiVf7/3/pX0piELmfHWrvinWKjPN2kgjEhIQPrdQnpNi0c0LfZ1W8cFo3OnHOueQ3eTVT+vVwsckNda2/25qrs0c8Oo4KnYaA8zPOHm/0mRzzoRYDCGrjieQDNt34FtY6fQQ2qyRMxp5AfOlD3uCB7cZHfIL0372l9fdrYYnHWjSvu21itTwS8wfUvEJHl70QJ0OeWcDrLrBNM2UXPGbfjH4fL7yn572zx1Mj+T+4yIQTfg== From: Oleksii Moisieiev To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v6 1/5] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu Thread-Topic: [PATCH v6 1/5] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu Thread-Index: AQHcSyafS16SOr0Uk0OkeRdy8jd8CrVPHVoAgAADtoCAAACtAIAAA/oAgAAAqoCAAYwTgIAABOMAgAAAkQA= Date: Tue, 13 Jan 2026 16:10:17 +0000 Message-ID: <22477428-9eee-423a-9260-545154ffd007@epam.com> References: <9598b2e2-7df8-40c5-82cb-c097121af763@suse.com> <5d8f55a6-7182-4e9d-a139-96fddb9450f8@epam.com> <98f5e8f0-070c-4be5-9baf-46278de8093d@suse.com> <99586f5c-d76b-4cbe-9fbd-c87e86bb236a@epam.com> <7cbda859-4257-499e-86e0-a0d001fd49c9@suse.com> <9631b854-2fc6-41aa-8b12-1e7283b22246@epam.com> <4807d2d3-fae7-45a4-b7c7-e101a95a6b58@suse.com> <87ba1c35-f1f3-4a52-ba76-306a538ad0c6@epam.com> <93cf250d-864d-4375-b05a-e48d3d56dac9@suse.com> In-Reply-To: <93cf250d-864d-4375-b05a-e48d3d56dac9@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_|VI2PR03MB10666:EE_ x-ms-office365-filtering-correlation-id: 9f59ef5f-8d9b-458e-60f4-08de52be3e49 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?MGVMVUpZMm5rR1U0TDU5cDN0NUFSZ2gzb1Y0S2VxVlRkazY5Q0M4RTZucGxN?= =?utf-8?B?NmNLeWxPMml4TkJ3TVB2c0VVWXpiQTZNd2RSd0lkbGdwV09hNC9qa0hua1Zv?= =?utf-8?B?cllYUWpKU2pqd2RjeTdvUVI5RURXS2NYSjBMQjVONDA0bHFxNWJQZWxwczd2?= =?utf-8?B?YVVNWGx1bWZMVEhGWXJGclpmak1PR0dRZ1hPQ3Y0U3BVLzZtS3NEYkZOZm9i?= =?utf-8?B?MkY4SXFKSllWYmRtcm80QkhnUjdYSSsyUzB6K1ovRVQ0Mnl3dDl3VXNpbzda?= =?utf-8?B?azJCa05PMU9yUTdjSjFPa1BHU1Vua1dHTi9UVWI0bFdxRi9CQkhmMHFoM3hi?= =?utf-8?B?dkN4RTFmZTNwNlB2Vm5mc2NqV2xHTzdha3JmamdSRVVRVTZUYW5jVVorTkZy?= =?utf-8?B?M0p3ZnFZaE0wMkRQbzlpNkdvWThRbkNZNG9raThmdCttK3RkbE9oQTJoQm12?= =?utf-8?B?K21IZFRvU1pqd2xzb011MkdrdDY5RnB2c0drdlhEcTNvd2ZreUlvRmNXWmFM?= =?utf-8?B?Zk1NQVRZRDF3TVh2bWNYdzdQYnBYWVdWekFhbFl4N0dHd3pNTGRUbURuMEJD?= =?utf-8?B?ZXIwaG5aeXJBK0xHYlhDWi8wMFRKNXUyRnZ3aWRNaTljWXlYTUVHTEtUTFlV?= =?utf-8?B?SEhEWGVWQzQ0NW1RRVBEMHVSSEtBd3FlTy9LZnhGQ2xIUmQzdm5YUzk4RElu?= =?utf-8?B?YlAvdVNSU1VvZk5YRzFNKy9FN1lTblpKNG00ak9sTytsbFFyeUJHZ05XcjZF?= =?utf-8?B?MG94OHF0Vi9RajNaZU9ZaFlRNWZXT1ZxREp6YUZaK25RYkcyb1FYZlBobXNH?= =?utf-8?B?bVdmVnB2Y1Bra2dhbHh2WnRZczBNbWZ4MENhWHd4dXF1Y0VCa2pteUQwSjNS?= =?utf-8?B?M01kYlYvN25ud3BNZEdjZnRobzBPekZDZzlEaXVnclZ0UlpQb2RvbGVDTWtT?= =?utf-8?B?VHo3Q25GYXBkSkN1TEsvTlZCaTF3ckFLaFhmbXZDV3E5M0pYNXZya21maVZ3?= =?utf-8?B?R01uTDNTU3ZPbmFMOFlyVG1qd1d3RFNoOWxkQjB2MUhpT1ovdFFyc1RyR3A2?= =?utf-8?B?dnppcS93c3FpcHVqaFIzWmdyVEtGOVE5QXhmZUJVUG1SeC9tVE1od241SGt2?= =?utf-8?B?U3NKSytuZVAvVHZmcGtVSHV4WnZrOVVBbExqREwrT0tKTVlUUnlYcklENmZw?= =?utf-8?B?WVF3ZnA5MXgwT2VTTnV1R1NzYkhlb0k5ZGhCb3MwVVh3eTdnMkRNUEVUWWVa?= =?utf-8?B?OGxIR0h5bCtOZ09XVm9tRDRKNUhsblJyY2dEcDV6UUs0RmFSRmZ6MThvZVN1?= =?utf-8?B?Y1REVmZaL3BFQkkraVpCV1dycWRzQjhybmJKM0pxTEU2aUR0Q25RMGM1Ly9H?= =?utf-8?B?OHM1R3BlYzJaaVU1ZmNZQ3BQOXZqMzJaM1lTMi9QZllvMjVhZUxlK3ZCbEt4?= =?utf-8?B?MXh3dW56dDFjODVMeHNYZTJzTUJVSjVmZlVSUURKYUNIbk4yYnUraU5PL3dV?= =?utf-8?B?TUx0QUJBRE5rSmltZ242cDNGRkxKaDFSOU5BM2FteXptdXNSRFBpUW5qdlU3?= =?utf-8?B?L0JYT3pNaGRXczZ4UTNISkFZZzJTMExOakZxTm13SkxJTUZpemRqQUJqU3Nq?= =?utf-8?B?K3ZtdEw2ZHN2U3RjOVlOYmZVRWh5USt4dXR2Wjgwd3BWb1J0c2xYS3ltdzBH?= =?utf-8?B?OHY4d2t6RzVSeG1DT2xtLzl4QTFUQ3RqWllaRnptZTdXbjAwaEhEL2VRTjRo?= =?utf-8?B?SVJIZjFiNGpkQ3l4WllTelV6aTRmQXZzZlIwU2RWeWo2Y0NZc3NZZDdkQWpo?= =?utf-8?B?NWNsTHFVVVk4Q3N4UTVsWlg0S2QreG1pMHg2YXkvbG0yL0Z6cERWMVlHaytH?= =?utf-8?B?cWFONTFUVE94K29mTFlOMTdxb01lZjVqb1V2K3pxYzVYMHh1OCtjUHBkUVlu?= =?utf-8?B?cmw3cFRKcktRd2d2Mk8vQUU5bk8vRzN5L3NyVmNTNFdKaFcwS1lCV3hiM2tU?= =?utf-8?B?YndVbVhiTUFybEhTRWQrdzlETW10RnNJM2NsKzcwUlRXcXlFL2lMek5yNE9n?= =?utf-8?Q?5lh8PQ?= 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)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ak1vVlpmU1I3dmxIWTBvVVdZWmhqV3poRmoyaFhwRDZWS25KRFJMNEVTb0Fh?= =?utf-8?B?UThseGR5MkQ3V2xvbU1uTzdZa3ZEQ3RtU0xCVzlTY1F0VWg0V1VrYmp6U2tm?= =?utf-8?B?UWRiNlh3OWlMVzAwL001THBQQnBHNXRtQVBWOVhZejg2dWRPNmlKcktKcFJI?= =?utf-8?B?RUoraVNua09ra212STZYa3ZBVlNQcHlETGE0djRZbnhtaEhjTy8rSUliY0NK?= =?utf-8?B?amd2OXZvTXBtUHJZVTAxNHFBZTlWbEE5N3BCS2FmUHJVQVdEQlhZYlpyQTZR?= =?utf-8?B?SHhhVjQyZFJQdzV3NmNTNVU4ODZNMHBHeWJHUmRGcy90cmR0dWM3aExrREFv?= =?utf-8?B?ejNmRElFTkNSRnREaUpoMy9DcWx2eDRXZVhjbXJiVFNYVy85MVBPU0FIeVNG?= =?utf-8?B?VUkzM0xDWWNkTXpMOEhHaURsQTV1OWg0UG9xdkNjNnRaSE1NenVkNGpBZDRo?= =?utf-8?B?eGtITlNzYnZ6d3dEbVJpYXFYZExlTHh3cmFyeTh0cXRJMTR5dDdHNnB4aFp3?= =?utf-8?B?NUdrQTZvZkxmQ2dBM3psRkhnT3N0NUlJK2xtcmh1TThhOCszb0hOSUZ0MVU2?= =?utf-8?B?dndQZnR0cDB2Y3dBNzZXYjJMc3BzYWNwQXhUUXdWRVl6Zy92aVlEaXVsRUZJ?= =?utf-8?B?NTRja3I0VHdhVENsemtUSU5kem1ZYklMWGhlMHlUbk1WRjc3UkZLV1B4azlB?= =?utf-8?B?MWNrUU11ODJubUJsalp5dTFsaWRSTjZSUmpBZGRMdi9GT0FyY0dTdWdORThh?= =?utf-8?B?SWZxeEJxcHQvdlhGZGkxQVdSZXFBUUVFVjZTeks2Z1lmZ1E4NHNac1pDNDlW?= =?utf-8?B?VjVydkJLeHpJSzVYQVRvVElnWnVjRXJ6eUNRb0hmK0hFaWpjbk4rQTFpZmFJ?= =?utf-8?B?NlM1Z0hETW9hVVNOT3F0NmI3QVhTMnk0WHNtYmk4UFBrbERZTWNPcXZoZXNE?= =?utf-8?B?L0ZuZjFNUURPR3d5Z0xMb2xoU0FoeTJ1UTJERm92QnA2UHNuS3hlcHh5RCt1?= =?utf-8?B?eGgxT0lQNUozYmUzTHo4eEZSRW9STFFZdUQ2NGRKcVM4MTlkaC9IcWZyckZF?= =?utf-8?B?dkF6MzVhUE8rRitSN1lNSWZ3Tng4NTFaVXlSUzNVTDF1amV5TVdZOWVEQlFJ?= =?utf-8?B?S1VialZndUZFR3c2SzkwbEZHZzRmZVoyQVhiL1ZEVHEzTitFalo1MkFuZ09p?= =?utf-8?B?VC9YRlV5eDI2cTArU2gyaW1DYUMrM0FPc2NSUmdCY1QvNE5hV09rYnZWQXJt?= =?utf-8?B?VndPQ1Erbk1QanY0Q2hZaS9PelRwd2t5N0RucFJnRUxzQ0lWQ2d4ckxLQmgy?= =?utf-8?B?K3FWQnIybnNNcEhwZk9MZlBoNk9TRzlMTTg1Z28zNFduSU9yNGQ5VU5ubnRz?= =?utf-8?B?Y3dVZUpRbGNEMnlNVURra0RSOTRoZjJLclZsTE51NVVVbWExdkVHNU5tUFJ4?= =?utf-8?B?Yzdxam1SU0N0Q2V1S1FtZU5EMk80WjNUVEthWVV3NXcvaDlrTHdOQ1lFODlo?= =?utf-8?B?TksvVFhkcVM2RldSVnBPTDhJVFJPWGtsSzJ4YndFTjI4aGswOXBacEZ6MlhO?= =?utf-8?B?L3NsUzMzemVkSzVKSjA2MTdtczdzVENZVXdCei8xclYzdXdsZWYyTk5BcytY?= =?utf-8?B?RGZvOFA4SFVEWU8yYit4VGlTSnZOVE9qclhFd3h2NEVCQlBHR0lpaEkzU1hQ?= =?utf-8?B?dXNSWU43UGMvZlNzWTQvUXdrRktIQmNsT1AydlNWVm9yUmRoQ0pwd0RvSVdt?= =?utf-8?B?TmllSGtvWjZYalVyWE91MnE1aFZOVmo2WUQvaThRYmhJKzBxQndKTTVCR2xI?= =?utf-8?B?UHI5VnhnK3dwcFNWZnRLc2tLRnJXV2g3SFU0Q2ZFaTEvSmhwV1d1cmVBMlpE?= =?utf-8?B?Qy80UkdWSFdJLzZibUxIMkYzWmVXMFVETHc1NkdXcXdkaTBlbE12anN6VEIx?= =?utf-8?B?QkpCVE5NaTRqaTJ0bExzaHQ3TFNqSDljUWhqV3VhZ3dIR2MwREs0eUZMR1Ey?= =?utf-8?B?TC9iTXp5MFRzeFM0U0JTbDAyZlhTR1EzWkVpK3g2cVVNY2N0SFFSQ2ozdUVW?= =?utf-8?B?RDBUT3JCQmdIbDJmM0hST0NyYkZaUVFmeGtKQ0hSRjdYektsbm5rUkgvVXha?= =?utf-8?B?N0YveVBOcEJUSTdTY1JxakU0ZEYvSmhJVTVreGMveWJ4TTRFeFR1OHpzZDdy?= =?utf-8?B?Y04wUXRIOXJPVUpXek1hWlZJdXQvMzY1TE1wR3VoUWg5ODd1aWVabVZQMHhK?= =?utf-8?B?NkFqYk0raFkxZEFLdDQ4a0YxakJ4MjFmK0FwNHVPanBtdmkzenJ5V0lsdE8x?= =?utf-8?B?R016QzBJeW5Kcjhub3ZWaUZnbFk1RnRSTHRMZmozUVRIWEhTQ2hScTBXb2JG?= =?utf-8?Q?Gz1oz6p1ezuaNYSw=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <3E9DA7570A6F1644941F43447179E58D@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: 9f59ef5f-8d9b-458e-60f4-08de52be3e49 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2026 16:10:17.4990 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xCeC1nOSb25lAXWjm2Xzfq3vW0j44yNPovsveS3dsp9l7fTtPvMzltlHf05MUF/VJNZSJtSgO14t2YAcwV+JBtrOe3B23nZwfIogEl3dp/M= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI2PR03MB10666 DQoNCk9uIDEzLzAxLzIwMjYgMTg6MDgsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxMy4wMS4y MDI2IDE2OjUwLCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToNCj4+DQo+PiBPbiAxMi8wMS8yMDI2 IDE4OjEzLCBKYW4gQmV1bGljaCB3cm90ZToNCj4+PiBPbiAxMi4wMS4yMDI2IDE3OjEwLCBPbGVr c2lpIE1vaXNpZWlldiB3cm90ZToNCj4+Pj4gT24gMTIvMDEvMjAyNiAxNzo1NiwgSmFuIEJldWxp Y2ggd3JvdGU6DQo+Pj4+PiBPbiAxMi4wMS4yMDI2IDE2OjU0LCBPbGVrc2lpIE1vaXNpZWlldiB3 cm90ZToNCj4+Pj4+PiBPbiAxMi8wMS8yMDI2IDE3OjQwLCBKYW4gQmV1bGljaCB3cm90ZToNCj4+ Pj4+Pj4gT24gMTIuMDEuMjAyNiAxNjoxNiwgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+Pj4+ Pj4+PiBPbiAwNi8xMS8yMDI1IDEyOjA5LCBKYW4gQmV1bGljaCB3cm90ZToNCj4+Pj4+Pj4+PiBP biAwMS4xMS4yMDI1IDEyOjU2LCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToNCj4+Pj4+Pj4+Pj4g QEAgLTgyNyw3ICs4MjgsMzIgQEAgbG9uZyBkb19kb21jdGwoWEVOX0dVRVNUX0hBTkRMRV9QQVJB TSh4ZW5fZG9tY3RsX3QpIHVfZG9tY3RsKQ0KPj4+Pj4+Pj4+PiAgICAgICAgICAgY2FzZSBYRU5f RE9NQ1RMX3Rlc3RfYXNzaWduX2RldmljZToNCj4+Pj4+Pj4+Pj4gICAgICAgICAgIGNhc2UgWEVO X0RPTUNUTF9kZWFzc2lnbl9kZXZpY2U6DQo+Pj4+Pj4+Pj4+ICAgICAgICAgICBjYXNlIFhFTl9E T01DVExfZ2V0X2RldmljZV9ncm91cDoNCj4+Pj4+Pj4+Pj4gKyAgICAgICAgaW50IHJldDE7DQo+ Pj4+Pj4+Pj4+ICsNCj4+Pj4+Pj4+Pj4gKyAgICAgICAgLyoNCj4+Pj4+Pj4+Pj4gKyAgICAgICAg ICogQWRkIGNoYWluZWQgaGFuZGxpbmcgb2YgYXNzaWduZWQgRFQgZGV2aWNlcyB0byBzdXBwb3J0 DQo+Pj4+Pj4+Pj4+ICsgICAgICAgICAqIGFjY2Vzcy1jb250cm9sbGVyIGZ1bmN0aW9uYWxpdHkg dGhyb3VnaCBTQ0kgZnJhbWV3b3JrLCBzbw0KPj4+Pj4+Pj4+PiArICAgICAgICAgKiBEVCBkZXZp Y2UgYXNzaWduIHJlcXVlc3QgY2FuIGJlIHBhc3NlZCB0byBGVyBmb3IgcHJvY2Vzc2luZyBhbmQN Cj4+Pj4+Pj4+Pj4gKyAgICAgICAgICogZW5hYmxpbmcgVk0gYWNjZXNzIHRvIHJlcXVlc3RlZCBk ZXZpY2UuDQo+Pj4+Pj4+Pj4+ICsgICAgICAgICAqIFRoZSBhY2Nlc3MtY29udHJvbGxlciBEVCBk ZXZpY2UgcHJvY2Vzc2luZyBpcyBjaGFpbmVkIGJlZm9yZSBJT01NVQ0KPj4+Pj4+Pj4+PiArICAg ICAgICAgKiBwcm9jZXNzaW5nIHByZXNlcnZpbmcgcmV0dXJuIGNvZGUgYW5kIGV4cGVjdGVkIHRv IGJlIGV4ZWN1dGVkIGZvcg0KPj4+Pj4+Pj4+PiArICAgICAgICAgKiBhbnkgRFQgZGV2aWNlIHJl Z2FyZGxlc3MgaWYgRFQgZGV2aWNlIGlzIHByb3RlY3RlZCBieSBJT01NVSBvcg0KPj4+Pj4+Pj4+ PiArICAgICAgICAgKiBub3QgKG9yIElPTU1VIGlzIGRpc2FibGVkKS4NCj4+Pj4+Pj4+Pj4gKyAg ICAgICAgICovDQo+Pj4+Pj4+Pj4+ICsgICAgICAgIHJldDEgPSBzY2lfZG9fZG9tY3RsKG9wLCBk LCB1X2RvbWN0bCk7DQo+Pj4+Pj4+Pj4gV2h5IHdvdWxkIHRoaXMgbm90IGJlIHRoZSBpbml0aWFs aXplciBvZiB0aGUgbmV3IHZhcmlhYmxlPyAoSSBhbHNvIGRvbid0IHRoaW5rDQo+Pj4+Pj4+Pj4g dGhhdCB3ZSd2ZSBkZWNpZGVkIHRvIHBlcm1pdCB2YXJpYWJsZSBkZWNsYXJhdGlvbnMgYXQgb3Ro ZXIgdGhhbiB0aGUgdG9wIG9mDQo+Pj4+Pj4+Pj4gc2NvcGVzIG9yIHdpdGhpbiBlLmcuIGEgZm9y KCkgbG9vcCBjb250cm9sIGNvbnN0cnVjdC4pDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ICsNCj4+Pj4+ Pj4+Pj4gICAgICAgICAgICAgICByZXQgPSBpb21tdV9kb19kb21jdGwob3AsIGQsIHVfZG9tY3Rs KTsNCj4+Pj4+Pj4+Pj4gKyAgICAgICAgaWYgKCByZXQgPCAwICkNCj4+Pj4+Pj4+Pj4gKyAgICAg ICAgICAgIHJldHVybiByZXQ7DQo+Pj4+Pj4+Pj4gV2h5IHdvdWxkIHlvdSBpbnZva2UgYm90aCBp biBhbGwgY2FzZXM/IElmIHNjaV9kb19kb21jdGwoKSBoYW5kbGVkIHRoZSByZXF1ZXN0LA0KPj4+ Pj4+Pj4+IHRoZXJlIGlzbid0IGFueSBwb2ludCBpbiBhbHNvIGludm9raW5nIGlvbW11X2RvX2Rv bWN0bCgpLCBpcyB0aGVyZT8gT3IgZWxzZSBpcw0KPj4+Pj4+Pj4+IHRoZXJlIG1heWJlIHNvbWUg Y3J1Y2lhbCBhc3BlY3QgbWlzc2luZyBmcm9tIHRoZSBkZXNjcmlwdGlvbiAob3Igbm90IGV4cGxp Y2l0DQo+Pj4+Pj4+Pj4gZW5vdWdoIHRoZXJlIGZvciBhIG5vbi1TQ0kgcGVyc29uIGxpa2UgbWUp Pw0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gQWxzbyB0aGlzIGRvZXNuJ3QgbG9vayB0byBmaXQgdGhl IGRlc2NyaXB0aW9uIHNheWluZyAiVGhlIFNDSSBhY2Nlc3MtY29udHJvbGxlcg0KPj4+Pj4+Pj4+ IERUIGRldmljZSBwcm9jZXNzaW5nIGlzIGNoYWluZWQgYWZ0ZXIgSU9NTVUgcHJvY2Vzc2luZyAu Li4iDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+IFdlIGNhbGwgYm90aCBiZWNhdXNlIFNDSSBhbmQgSU9N TVUgY292ZXIgZGlmZmVyZW50IGNvbmNlcm5zIGFuZCBhIERUDQo+Pj4+Pj4+PiBkZXZpY2UgbWF5 IG5lZWQNCj4+Pj4+Pj4+IGJvdGg6IFNDSSBmb3IgRlctbWVkaWF0ZWQgYWNjZXNzIGNvbnRyb2wg KHBvd2VyL2Nsb2Nrcy9yZXNldCkgYW5kIElPTU1VDQo+Pj4+Pj4+PiBmb3IgRE1BIGlzb2xhdGlv bi4NCj4+Pj4+Pj4+IFNDSSByZXR1cm5pbmcgc3VjY2VzcyBkb2VzIG5vdCBtZWFuIHRoZSBJT01N VSB3b3JrIGlzIHJlZHVuZGFudC4NCj4+Pj4+Pj4gQ2FuIHRoZSBjb21tZW50IHRoZW4gcGxlYXNl IGJlIHVwZGF0ZWQgdG8gcHJvcGVybHkgY2FsbCBvdXQgdGhpcyBkdWFsDQo+Pj4+Pj4+IHJlcXVp cmVtZW50Pw0KPj4+Pj4+IFllcywgZm9yIHN1cmUuDQo+Pj4+Pj4+PiAtIHNjaV9kb19kb21jdGwo KSByZXR1cm5zIC1FTlhJTyB3aGVuIGl0IGhhcyBub3RoaW5nIHRvIGRvIChub24tRFQsIG5vDQo+ Pj4+Pj4+PiBtZWRpYXRvciwgbWVkaWF0b3IgbGFja3MgYXNzaWduIGhvb2spLg0KPj4+Pj4+Pj4g VGhhdCBpcyB0aGUg4oCcbm90IGhhbmRsZWQgYnkgU0NJ4oCdIHNlbnRpbmVsOyBpbiB0aGF0IGNh c2UgdGhlIGNvZGUNCj4+Pj4+Pj4+IHByb2NlZWRzIHRvIElPTU1VIG5vcm1hbGx5Lg0KPj4+Pj4+ Pj4gLcKgIFdoZW4gc2NpX2RvX2RvbWN0bCgpIHN1Y2NlZWRzICgwKSwgdGhlIGRldmljZSBtYXkg c3RpbGwgcmVxdWlyZSBJT01NVQ0KPj4+Pj4+Pj4gcHJvZ3JhbW1pbmcNCj4+Pj4+Pj4+IChlLmcu LCBEVCBkZXZpY2UgaGFzIGFuIGlvbW11cyBwcm9wZXJ0eSkuIFNraXBwaW5nIGlvbW11X2RvX2Rv bWN0bCgpDQo+Pj4+Pj4+PiB3b3VsZCBsZWF2ZSBETUEgaXNvbGF0aW9uIHVucHJvZ3JhbW1lZC4N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGUgZmluYWwgaWYgKHJldDEgIT0gLUVOWElPKSByZXQgPSBy ZXQxOyBlbnN1cmVzIHRoYXQgaWYgYm90aCBwYXRocyByYW4NCj4+Pj4+Pj4+IGFuZCBJT01NVSBz dWNjZWVkZWQsDQo+Pj4+Pj4+PiBhbiBTQ0kgZmFpbHVyZSBpcyBzdGlsbCByZXBvcnRlZCB0byB0 aGUgY2FsbGVyLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IERldmljZS10cmVlIGV4YW1wbGVzIHRvIGls bHVzdHJhdGUgdGhlIGR1YWwgcm9sZXM6DQo+Pj4+Pj4+PiAxLiBBY2Nlc3MtY29udHJvbGxlZCBE VCBkZXZpY2UgKG5vdCBuZWNlc3NhcmlseSBJT01NVS1wcm90ZWN0ZWQpOg0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+IGkyYzM6IGkyY0BlNjUwODAwMCB7DQo+Pj4+Pj4+PiAgICAgIMKgwqDCoCBjb21wYXRp YmxlID0gInJlbmVzYXMscmNhci1nZW4zLWkyYyI7DQo+Pj4+Pj4+PiAgICAgIMKgwqDCoCByZWcg PSA8MCAweGU2NTA4MDAwIDAgMHg0MD47DQo+Pj4+Pj4+PiAgICAgIMKgwqDCoCBwb3dlci1kb21h aW5zID0gPCZzY21pX3BkIDU+O8KgwqDCoMKgwqAgLy8gRlctbWFuYWdlZCBwb3dlciBkb21haW4N Cj4+Pj4+Pj4+ICAgICAgwqDCoMKgIGNsb2NrcyA9IDwmc2NtaV9jbGsgMTI+Ow0KPj4+Pj4+Pj4g ICAgICDCoMKgwqAgY2xvY2stbmFtZXMgPSAiZmNrIjsNCj4+Pj4+Pj4+ICAgICAgwqDCoMKgIGFj Y2Vzcy1jb250cm9sbGVycyA9IDwmc2NtaV94ZW4gMD47DQo+Pj4+Pj4+PiAgICAgIMKgwqDCoCAv LyBubyBpb21tdXMgcHJvcGVydHk6IFNDSSBtYXkgbmVlZCB0byBhdXRob3JpemUvcG93ZXIgdGhp cyBkZXZpY2U7DQo+Pj4+Pj4+PiBJT01NVSBoYXMgbm90aGluZyB0byBkbw0KPj4+Pj4+Pj4gfTsN Cj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAyLiBJT01NVS1wcm90ZWN0ZWQgRFQgZGV2aWNlIHRoYXQgc3Rp bGwgbWF5IG5lZWQgU0NJIG1lZGlhdGlvbjoNCj4+Pj4+Pj4+IHZwdTogdmlkZW9AZTZlZjAwMDAg ew0KPj4+Pj4+Pj4gICAgICDCoMKgwqAgY29tcGF0aWJsZSA9ICJyZW5lc2FzLHJjYXItdnB1IjsN Cj4+Pj4+Pj4+ICAgICAgwqDCoMKgIHJlZyA9IDwwIDB4ZTZlZjAwMDAgMCAweDEwMDAwPjsNCj4+ Pj4+Pj4+ICAgICAgwqDCoMKgIGlvbW11cyA9IDwmaXBtbXUgMCAwPjvCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgLy8gbmVlZHMgSU9NTVUgbWFwcGluZyBmb3IgRE1BDQo+Pj4+Pj4+PiBpc29sYXRp b24NCj4+Pj4+Pj4+ICAgICAgwqDCoMKgIHBvd2VyLWRvbWFpbnMgPSA8JnNjbWlfcGQgNz47wqDC oMKgwqDCoCAvLyBGVy1tYW5hZ2VkIHBvd2VyL2Nsb2NrL3Jlc2V0DQo+Pj4+Pj4+PiAgICAgIMKg wqDCoCBjbG9ja3MgPSA8JnNjbWlfY2xrIDM0PjsNCj4+Pj4+Pj4+ICAgICAgwqAgwqAgYWNjZXNz LWNvbnRyb2xsZXJzID0gPCZzY21pX3hlbiAwPjsNCj4+Pj4+Pj4+ICAgICAgwqDCoMKgIGNsb2Nr LW5hbWVzID0gInZwdSI7DQo+Pj4+Pj4+PiB9Ow0KPj4+Pj4+Pj4+PiAtLS0gYS94ZW4vZHJpdmVy cy9wYXNzdGhyb3VnaC9kZXZpY2VfdHJlZS5jDQo+Pj4+Pj4+Pj4+ICsrKyBiL3hlbi9kcml2ZXJz L3Bhc3N0aHJvdWdoL2RldmljZV90cmVlLmMNCj4+Pj4+Pj4+Pj4gQEAgLTM3OSw2ICszNzksMTIg QEAgaW50IGlvbW11X2RvX2R0X2RvbWN0bChzdHJ1Y3QgeGVuX2RvbWN0bCAqZG9tY3RsLCBzdHJ1 Y3QgZG9tYWluICpkLA0KPj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICBicmVhazsNCj4+Pj4+ Pj4+Pj4gICAgICAgICAgICAgICB9DQo+Pj4+Pj4+Pj4+ICAgICAgIA0KPj4+Pj4+Pj4+PiArICAg ICAgICBpZiAoICFkdF9kZXZpY2VfaXNfcHJvdGVjdGVkKGRldikgKQ0KPj4+Pj4+Pj4+PiArICAg ICAgICB7DQo+Pj4+Pj4+Pj4+ICsgICAgICAgICAgICByZXQgPSAwOw0KPj4+Pj4+Pj4+PiArICAg ICAgICAgICAgYnJlYWs7DQo+Pj4+Pj4+Pj4+ICsgICAgICAgIH0NCj4+Pj4+Pj4+Pj4gKw0KPj4+ Pj4+Pj4+PiAgICAgICAgICAgICAgIHJldCA9IGlvbW11X2Fzc2lnbl9kdF9kZXZpY2UoZCwgZGV2 KTsNCj4+Pj4+Pj4+Pj4gICAgICAgDQo+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgaWYgKCByZXQg KQ0KPj4+Pj4+Pj4+IEhvdyBhcmUgRFQgYW5kIFBDSSBkaWZmZXJlbnQgaW4gdGhpcyByZWdhcmQ/ DQo+Pj4+Pj4+PiBQbGVhc2UgZmluZCBleGFtcGxlcyBhYm92ZS4NCj4+Pj4+Pj4gU29ycnksIGJ1 dCBJIGNhbid0IHNwb3QgYW55dGhpbmcgUENJLWlzaCBpbiB0aGUgZXhhbXBsZXMgYWJvdmUuIFRo ZW4gYWdhaW4gSQ0KPj4+Pj4+PiBhbHNvIG5vIGxvbmdlciByZWNhbGwgd2h5IEkgY29tcGFyZWQg d2l0aCBQQ0kgaGVyZS4gT2gsIHBlcmhhcHMgYmVjYXVzZSB0aGUNCj4+Pj4+Pj4gUENJIHNpZGUg aXNuJ3QgYmVpbmcgbW9kaWZpZWQgYXQgYWxsLg0KPj4+Pj4+Pg0KPj4+Pj4+IENvcnJlY3QsIHBj aSBjb2RlIHdhc24ndCB0b3VjaGVkIGJ5IHRoZXNlIGNoYW5nZXMuDQo+Pj4+PiBZZXQgbXkgcXVl c3Rpb24gYm9pbHMgZG93biB0byAid2h5Iiwgbm90ICJ3aGV0aGVyIi4NCj4+Pj4+DQo+Pj4+IEkg aGF2ZSByZXZpZXdlZCB0aGUgcHJldmlvdXMgdmVyc2lvbnMgb2YgdGhlIHBhdGNoIHNlcmllIGFu ZCBjb3VsZCBub3QNCj4+Pj4gZmluZCBhbnkgcXVlc3Rpb25zIHJlbGF0ZWQgdG8gUENJIHByaW9y IHRvIHRoaXMgc2VyaWVzLiBUaGVyZWZvcmUsICJIb3cNCj4+Pj4gYXJlIERUIGFuZCBQQ0kgZGlm ZmVyZW50IGluIHRoaXMgcmVnYXJkPyIgYXBwZWFycyB0byBiZSB0aGUgZmlyc3QNCj4+Pj4gcXVl c3Rpb24gY29uY2VybmluZyBQQ0kuDQo+Pj4gUXVpdGUgcG9zc2libGUsIHlldCBkb2VzIHRoYXQg c29tZWhvdyBlbGltaW5hdGUgdGhlIG5lZWQgdG8gYWRkcmVzcyBpdD8gSSdtDQo+Pj4gdHJ5aW5n IHRvIHVuZGVyc3RhbmQgd2h5IHRoZSByZXNwZWN0aXZlIFBDSSBjb2RlIGlzbid0IGJlaW5nIHRv dWNoZWQuDQo+Pj4NCj4+IFhFTl9ET01DVExfYXNzaWduX2RldmljZSBkaXNwYXRjaDogd2Ugbm93 IGNoYWluIHNjaV9kb19kb21jdGwgZmlyc3QsDQo+PiB0aGVuIGlvbW11X2RvX2RvbWN0bC4NCj4+ IGlvbW11X2RvX2RvbWN0bCBmaXJzdCB0cmllcyBpb21tdV9kb19wY2lfZG9tY3RsICh3aGVuIENP TkZJR19IQVNfUENJKQ0KPj4gYW5kIGZhbGxzIGJhY2sgdG8gaW9tbXVfZG9fZHRfZG9tY3RsIG9u bHkgaWYgUENJIHJldHVybnMgLUVOT0RFVi4NCj4+IFRoZSBuZXcgZHRfZGV2aWNlX2lzX3Byb3Rl Y3RlZCgpIGJ5cGFzcyBpbiBpb21tdV9kb19kdF9kb21jdGwgb25seQ0KPj4gYXBwbGllcyB0byBE VC1kZXNjcmliZWQgZGV2aWNlczsgU0NJIHBhcmFtZXRlcnMgYXJlIGNhcnJpZWQgdmlhIERUIG5v ZGVzLg0KPj4gUENJIGRldmljZXMgaGFuZGxlZCBieSBpb21tdV9kb19wY2lfZG9tY3RsIGRvIG5v dCBjYXJyeSBEVC9TQ0kgbWV0YWRhdGENCj4+IGluIHRoaXMgcGF0aCwgc28gdGhlcmUgaXMgbm8g bm90aW9uIG9mIOKAnFNDSSBwYXJhbWV0ZXJzIG9uIGENCj4+IG5vbi1JT01NVS1wcm90ZWN0ZWQg UENJIGRldmljZeKAnSBmb3IgaXQgdG8gaW50ZXJwcmV0IG9yIHRvIHNraXAuIFRoZSBQQ0kNCj4+ IHBhdGggc2hvdWxkIGNvbnRpbnVlIHRvIHJlcG9ydCBlcnJvcnMgaWYgYXNzaWdubWVudCBjYW5u b3QgYmUgcGVyZm9ybWVkDQo+PiBieSB0aGUgSU9NTVUgbGF5ZXIuDQo+PiBTbyB3ZSBzaG91bGQg bGVhdmUgaW9tbXVfZG9fcGNpX2RvbWN0bCB1bmNoYW5nZWQ7IHRoZSBTQ0kvRFQtc3BlY2lmaWMN Cj4+IHJlbGF4YXRpb25zIGJlbG9uZyBvbmx5IGluIHRoZSBEVCBwYXRoLg0KPj4gQWxzb8KgIFND SSBoYW5kbGluZyBvbmx5IGV4aXN0cyB3aGVuIERUIGlzIHByZXNlbnQuDQo+IENhbiBhbiBhYnJp ZGdlZCB2YXJpYW50IG9mIHRoaXMgcGxlYXNlIGJlIGFkZGVkIHRvIHRoZSBkZXNjcmlwdGlvbj8N Cj4NCj4gSmFuDQpTdXJlLiBJIHdpbGwgYWRkIHRoaXMgdG8gY29tbWl0IGRlc2NyaXB0aW9uLg0K DQpPbGVrc2lpLg0K From xen-devel-bounces@lists.xenproject.org Tue Jan 13 16:12:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 16:12:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202025.1517627 (Exim 4.92) (envelope-from ) id 1vfh0S-0000dC-90; Tue, 13 Jan 2026 16:12:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202025.1517627; Tue, 13 Jan 2026 16:12:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfh0S-0000d5-5m; Tue, 13 Jan 2026 16:12:32 +0000 Received: by outflank-mailman (input) for mailman id 1202025; Tue, 13 Jan 2026 16:12: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 1vfh0Q-0000cx-4y for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 16:12:30 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a77c2d6c-f09a-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 17:12:28 +0100 (CET) Received: from MN0P221CA0012.NAMP221.PROD.OUTLOOK.COM (2603:10b6:208:52a::22) by IA0PPFF4B476A86.namprd12.prod.outlook.com (2603:10b6:20f:fc04::bea) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Tue, 13 Jan 2026 16:12:19 +0000 Received: from BL6PEPF00022571.namprd02.prod.outlook.com (2603:10b6:208:52a:cafe::f6) by MN0P221CA0012.outlook.office365.com (2603:10b6:208:52a::22) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Tue, 13 Jan 2026 16:12:06 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF00022571.mail.protection.outlook.com (10.167.249.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Tue, 13 Jan 2026 16:12:19 +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, 13 Jan 2026 10:12:18 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a77c2d6c-f09a-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=cD7LVDJwJgpy1pRR6rBHAdnUys3k0MpZXPP2UfzDdCw/kEkRQ0DYHUg/CnM/bKFzoWuXLZV6bMdnz8r2ed8SATD7kVvvF7yUA8j/VU2CUfLHkIiOOkM0hNy3CyfwuuddlUdyPsC3hdghZ92lRq/UqP9DEksl4IUq+ui1/91aB07+6WkfrfTf4moPlyt0y2K4uGziYwMHCYotPN1Wi2du32riq8xV9usmHovi669Dy+N9mLfWWVLnnyNXX1GEN3A7YS9qnvnF20ge4caQ6lDhi+Azc65gzc+dwHjVvdRO7dPRCTEy6V4y6ULs2ZviwAh5H5s1+sukh1QNktCZ3eAqgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XWNOwq1lrhQvLqw3PU5BGCqafDNlZIEQ6aIGHgr/KpE=; b=lyQpeBflycrJFCJmsPqh5RnGBf9tjd2lWo1S92VBFY9YhRfnUBXEAWSLgEJHhuYVTg8U8V2lNmrgGBBaJNpe2Uacf2tu3e2gQZiqDDZlAAmwMK9DjhMERiOz7wy8PfBYP1+BXcIOmBTcfZ3YXpQKGl4x0KDMcb2NzRrlcUMNe4U4dqc7jYyRBrYV4yCgHhjxbXKtjLg/I2CsHp8BmppX0QWEsPlNWi3PLg3nDANj6AZQtlaK1xehDuP0UGmiO9iIvo8oudCEqLM+6Lq39Au74IzG0sPBtk49akDBuM/TVWUYQUZdbkq5fZQ0xa13h36v2eZW/LrQ7iUjuRo5IK+NOA== 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=XWNOwq1lrhQvLqw3PU5BGCqafDNlZIEQ6aIGHgr/KpE=; b=JpSR11irIHdUNOlkk8bd82YzIPXqXK0OirCH5zQxTqhKbkA4Xd/XUv7s7Yop6PMHfOCk2FxXSuulkBDHf8oxh+jXzied2hPEqwSyNYayumVzO4AqR8j3Jm1HEnWAy+tFfbqAS4RhWA6ngIQR3uGI7dS9nQ1cxIjyedA4kkpr06c= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 13 Jan 2026 17:12:11 +0100 Message-ID: CC: Andrew Cooper , Anthony PERARD , Michal Orzel , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?= , Subject: Re: [PATCH v3 4/4] x86/ucode: Add Kconfig option to remove microcode loading From: Alejandro Vallejo To: Jan Beulich X-Mailer: aerc 0.20.1 References: <20260113122109.62399-1-alejandro.garciavallejo@amd.com> <20260113122109.62399-5-alejandro.garciavallejo@amd.com> <0706617f-fdb8-47c1-94f4-6aa92abd07ec@suse.com> In-Reply-To: <0706617f-fdb8-47c1-94f4-6aa92abd07ec@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: BL6PEPF00022571:EE_|IA0PPFF4B476A86:EE_ X-MS-Office365-Filtering-Correlation-Id: d6bb0dd5-a3c6-4932-3ea9-08de52be8720 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?VEVJbTJmb0RJNTd6RGRRWDIyMERlbzZuL2REN0lCVVhwenRJbFMxL0U4MUJL?= =?utf-8?B?QUxFWmJuMTB0T0RNbXNUWXlHNVBLbWR4UElyd1AvbS9oN1ROYzFVZWJCUTVa?= =?utf-8?B?MnRISFZJdkZMcTdickdxTjdSbGZlUEU0cWlmdkJCSk10ZzVHREk0TkQ5QktI?= =?utf-8?B?NHJIOHVJVEVBMTV6eGJOcEM3SUxiVXB5RVVheTN0bG0zOFYyYUxrWEVwQ2cx?= =?utf-8?B?RXBheWVkNWhDaHl6R0ZVeTc5N3cwc1c1MUVzRmc1eXliSEt4MzRwUGljckNl?= =?utf-8?B?SFpWZDJhTGhaN05Pb1R3cEwrS2poYjJrVFl5STV1QkVXQVJBVWVyRnhFMEJN?= =?utf-8?B?K0VaQWFnbnpxNXB2V3ZRMk53b1BXcFNBendWLzl3Q2ZLS1kwb2JzSk5JOHAz?= =?utf-8?B?WFhPLzBVZDVHTzlJaTdtUUpTQzIzUHF0alNhdWNvbzFENlZMWTdJK2s0aTM2?= =?utf-8?B?bWZUT2g0M0RnNnJPYjRXaURjckdMeFZaQXk4VVZiUnExY0FMb0NHZXFBOUZU?= =?utf-8?B?VWhZb2ZicW96ZWVaRmVqbWNvRnh5OFEwbWtiTzlocWluc3JiVGNoSnA5TXNN?= =?utf-8?B?VHJ6VmF3YXhmUDJUdjl1M2IxSHk3aWFlZTJjMXFzMjlXazlnOVRQYTBISklz?= =?utf-8?B?OTlVanpMQ0RnSVpEcG9ZSVltZWxvV3BYbG03Wm9JV2dCRG50UllRbXI2OVE3?= =?utf-8?B?VWw4czl0MytsS3FvTDlqWmxlNHlDZmIzdll5amhjeVhKRlErazVlZFJTckpJ?= =?utf-8?B?YXNIaS8xWEE2a0dUaUpFdU56UE1EVCszTGZVWEd2VERrbEMzdEI5QkFjME0y?= =?utf-8?B?YlpTazdqY0JsTzd3RmwzT2tXTEIyUjJ0NHlaSlY1K1l1b0t5Z1l4ME5XemUy?= =?utf-8?B?R1VxaWR0bm1OSGNqemZ2cUhUOG5BbS9sKzZKMlNJRlJHUzBHMEl1YVp4b2Nv?= =?utf-8?B?MWhSc1Jjbm1pOHFGZVB2TFZWUUJUMmpGWU01QStmYWxKYlJkVjJRNEhONmUr?= =?utf-8?B?dElvenhUMFViQXAwYk42TkFXYUZjaUdsWVBpZSs1U1RielhCak1mK0tpNktR?= =?utf-8?B?QjB0YStLQ1BYWXVnMWZBeU5YSHdqdVhPODRQeHczSys2VmRoRHgyQXdvejU5?= =?utf-8?B?aFBLTUZqcTBoRlc4Rm1xNjVHdVRFUm9Ba1hGWG1wY0wwYWVSY3d0WEVLVENi?= =?utf-8?B?YUZSY1RzZWdvRkNRcFBCbVJKNldkdE56NEtickx1anZVRW9KVkM5QUNkR2Fi?= =?utf-8?B?RnFZYmx2TkRVbFpoYXJoZWVndTkrcEUvd3doa2w3bW50QlF4UFd2OTEyRmNy?= =?utf-8?B?N3ZxTlcrVXgxaVM2NTFaV0tNRjJCNGkxTEhDaFFkMCtaaFdBc0plNWhmQVMw?= =?utf-8?B?TUJRdlNXT3NhR2N1TUFXUkhNL3JwQ3JVZ3lWNlNCcGZlMWpPYkNqaVBTaVI4?= =?utf-8?B?Qlp4elI1ZzEyUmxkU1dnd2YxVkw3OWZUMzhVT1Z5eWhOSTBmQzRUNmswOC9P?= =?utf-8?B?QVBjTE83ZVRTcVhVRGFnME8zditLbW0zRzRFM0hLVHA2WnBEeHRtTnBlR1Zm?= =?utf-8?B?SjBzQ1RvcnBqVVdhZ0c5cCtzTWlPU05xeTZ2SXRqLzdlNkFFRUxUdERMSmFh?= =?utf-8?B?TWJCUWQ2QTdhODdieWhHYzhOWGpGWXlld01uRzN1MWZFV1JKVk85TUtwdmJU?= =?utf-8?B?SkFEODg0RnpTREdMVUtHcXltZFU1VnBGQ3BkTHVJNGcwRFl0OGU0SXJ6Vit6?= =?utf-8?B?SGdoc2FROTFhc0Ywc1c2SXVaRDk1VnBFU0xKcFFwY0VNcXdqSGs0SVNoN04w?= =?utf-8?B?K1BuK3FTNjZiMk5FTTlwcHkrR2V6Ui9IS1h1TGlaekhwdVg2bzc2dTd6MER4?= =?utf-8?B?TWYyWlJKY2hUYWE4aEZFMllQa1BsYkJPbVUzRjBSbHZCUUNNcllHZ0tUdm1t?= =?utf-8?B?eVZveHBjUDVkd1M3L05yUlh1Z1pFZ0VlVHdCN0Nab3VHZE9HeHJsMW1EME9n?= =?utf-8?B?TU5JR1IwT04ydGVrd3R3OGFJeWRxVmR5TUFDNUJ0L2U3c1N4ODhhWHF6Nmd2?= =?utf-8?B?cEQ0bDBWbVU1QjhlMXI1UUZ2QjBheWZ2dEh0OElSWUZ4WDYvVnhkd25lZWQ1?= =?utf-8?Q?6Z/4=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 16:12:19.7053 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d6bb0dd5-a3c6-4932-3ea9-08de52be8720 X-MS-Exchange-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: BL6PEPF00022571.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PPFF4B476A86 On Tue Jan 13, 2026 at 4:27 PM CET, Jan Beulich wrote: > On 13.01.2026 13:21, Alejandro Vallejo wrote: >> @@ -469,7 +471,7 @@ struct ucode_buf { >> char buffer[]; >> }; >> =20 >> -static long cf_check ucode_update_hcall_cont(void *data) >> +static long cf_check __maybe_unused ucode_update_hcall_cont(void *data) >> { >> struct microcode_patch *patch =3D NULL; >> int ret, result; > > Why this change when ... > >> @@ -613,6 +615,7 @@ static long cf_check ucode_update_hcall_cont(void *d= ata) >> return ret; >> } >> =20 >> +#ifdef CONFIG_MICROCODE_LOADING > > ... this can simply be moved up accordingly? After all ... > >> int ucode_update_hcall(XEN_GUEST_HANDLE(const_void) buf, >> unsigned long len, unsigned int flags) >> { >> @@ -645,6 +648,7 @@ int ucode_update_hcall(XEN_GUEST_HANDLE(const_void) = buf, >> */ >> return continue_hypercall_on_cpu(0, ucode_update_hcall_cont, buffer= ); > > ... this is the only user of that other function. To minimise the scope of the ifdef. It's hard to know where things start/en= d when they cover several functions. This way it's (imo) clearer. I don't mind much though. > >> --- a/xen/arch/x86/cpu/microcode/intel.c >> +++ b/xen/arch/x86/cpu/microcode/intel.c >> @@ -408,17 +408,20 @@ static const char __initconst intel_cpio_path[] = =3D >> "kernel/x86/microcode/GenuineIntel.bin"; >> =20 >> static const struct microcode_ops __initconst_cf_clobber intel_ucode_op= s =3D { >> - .cpu_request_microcode =3D cpu_request_microcode, >> + .cpu_request_microcode =3D MICROCODE_OP(cpu_request_micr= ocode), >> .collect_cpu_info =3D collect_cpu_info, >> - .apply_microcode =3D apply_microcode, >> - .compare =3D intel_compare, >> - .cpio_path =3D intel_cpio_path, >> + .apply_microcode =3D MICROCODE_OP(apply_microcode)= , >> + .compare =3D MICROCODE_OP(intel_compare), >> + .cpio_path =3D MICROCODE_OP(intel_cpio_path)= , >> }; > > While I appreciate the intention with MICROCODE_OP(), I'm not really happ= y > with function pointer members left in place just for them to be NULL > everywhere. What if a call site remains unguarded? With PV guests that > would be a privilege escalation XSA. I see where you're coming from, but these are already NULL if microcode loading is not exposed by the underlying hypervisor (if any), or is blocked= by hardware in Intel, so arguably that worry is orthogonal to this. Also, only a privileged domain can perform late microcode loading, so the X= SM check would prevent any such XSA from coming to pass. dom0 crashing the sys= tem on a bad hypercall (while wrong) would just be unfortunate, not a security issue, as far as I can tell. I could indeed get rid of it all. But that'd cause a sea a ifdefs anywhere = the fields are accessed, which is contrary to the current intent of relying on = DCE for readability. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Tue Jan 13 16:16:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 16:16:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202044.1517637 (Exim 4.92) (envelope-from ) id 1vfh4O-0001G0-SR; Tue, 13 Jan 2026 16:16:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202044.1517637; Tue, 13 Jan 2026 16:16:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfh4O-0001Ft-Or; Tue, 13 Jan 2026 16:16:36 +0000 Received: by outflank-mailman (input) for mailman id 1202044; Tue, 13 Jan 2026 16:16:35 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfh4M-0001Fn-R1 for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 16:16:34 +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 38af3da9-f09b-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 17:16:32 +0100 (CET) Received: from MN0PR03CA0001.namprd03.prod.outlook.com (2603:10b6:208:52f::28) by DM6PR12MB4417.namprd12.prod.outlook.com (2603:10b6:5:2a4::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 16:16:23 +0000 Received: from BL6PEPF00022575.namprd02.prod.outlook.com (2603:10b6:208:52f:cafe::8c) by MN0PR03CA0001.outlook.office365.com (2603:10b6:208:52f::28) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.4 via Frontend Transport; Tue, 13 Jan 2026 16:16:22 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF00022575.mail.protection.outlook.com (10.167.249.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Tue, 13 Jan 2026 16:16:22 +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, 13 Jan 2026 10:16:21 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 38af3da9-f09b-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JEfID/2Ct/xo0YkaeApda1mtO2DnTU1a4BhU4fTbaNwWi8gnbYUkf+yd5Cdo7E8hTLnKvl09niNlgrmUpjBB1u2h//f3eIrVeHlmPeoBMdUWi+OPAKLXbfPvZ8R1HBuxes+x/d/+hmUlwFVmSl5B/GR9fEs6pQz3uSonB9VoX5VhXT2I4m1AzOgz95Ygda8ttcHN9hhvENuKfBFWhw5CCTZJKgEAru3Ej+hEL1V7DBYtVrfHAndRTjvXYmp8YCfneiEhWtLm9q7UMr0UWynInMV2N/XhJstC6hoUfWIyXak9IHngCmVJP3WgBCWZO7xy5A2D91ziAyrKVay/wEeO5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Rsr7nMo8BX3rxrcUabuZmfRBRJ//ey16ldT8y054K0w=; b=BvO7C0EmApmjELGsGHpn4q8D1Z2BCC5B03XOEqVOvzAAlS5yMBfQfvv8AdVDy8ypG4BLRbKjEB924UZQrYs5tZ4hqnLLyf3SeoFtsBqkhxNfpWO8yHpmKOp4K4GSPpapAJkAKuot+hcwcIR5axIKXwUC0yyUIEbSYXOql9DIrQHa5aao47R/fsxR2RbAaTY9E4uVnIYmZp/oQ2mEoLFgMFNBNJKTk7JW2ZbOK4X8frAJJ17F4tsEmf0Df05i/NlZSb6b7ObDPZgVhDCXsXe0PfcRfTbKIMTmtAmp5WxFjRkQfd4DLuhCbBCdIfhI+kZ29A0r554RgyNcUR7S6elqpw== 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=Rsr7nMo8BX3rxrcUabuZmfRBRJ//ey16ldT8y054K0w=; b=NX68Zql5YbbdaFyk9/Ply4d+8S1jFcx0RUmkCI/t0yPUGYzK8zkBnTH5EhAW6yy77MecV8/GCm1uDkMIIjG9sv81AHKn+jiRwoKvPdq8XS4JAPhBIp6WRUydt4ZcreKY837kMwksMKVXrNa9IdbHsHy3muYQEJNs4x0WTEmMBTc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 13 Jan 2026 17:16:20 +0100 Message-ID: From: Alejandro Vallejo To: Andrew Cooper , CC: Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Subject: Re: [PATCH v3 3/4] earlycpio: lib-ify earlycpio.c X-Mailer: aerc 0.20.1 References: <20260113122109.62399-1-alejandro.garciavallejo@amd.com> <20260113122109.62399-4-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: BL6PEPF00022575:EE_|DM6PR12MB4417:EE_ X-MS-Office365-Filtering-Correlation-Id: 51776997-ac56-4c72-059f-08de52bf1817 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?ZmpUVG1hcXppck9uOG5xVWJIK0dwK3Y1c0FWN0dLNjFJdUxLYm9MTnJzSXBv?= =?utf-8?B?d3YvUHFEcXUwRUg5eGlGVGwybmlVRW9QNllLUDQrZU9mNG9yV0pKSE5obHlz?= =?utf-8?B?anQzYmI4UDFid1ZRUzJFdmlMUWVvWnhmWm5PWCtiN0hhbndMMkJpRXE3MEJY?= =?utf-8?B?ZTdUL3VIbklJTVNYcGJRVTFheHNKZE5hRnlpb3BCYk42YmhYTDdZSUdxUU9m?= =?utf-8?B?ZTJ0Nk82eXZzeUZTM1kzZ2ZCUy9PdWN0eHlCdjhHMlBZdGFWckxmZGlSMGJ5?= =?utf-8?B?TjhGLzhNRnZRZk1WWThsK2dxcGFWdGR4Y2RQeGpmaUtmOWpSQUpmK3lpS0lp?= =?utf-8?B?NVFabEYxTzE4aFB2WkVHeHN2SWhkc1pyMHY2bXRhR25RYWdlQ3NoVmtNaDBD?= =?utf-8?B?dkdWakhKN1F5amdNV1RCQkFZSGMzT3A5ejNKV25Gd28wUUZaTndMRDFmVi92?= =?utf-8?B?a3NieEVoeWdQellKOU9qYUtUSWQ5aG0zNU5pOTd1YWJucnZiQ2ZqZCt6ekt0?= =?utf-8?B?UXJIZHRrR3gxc2FJY2lqa0JCcXArTGNiaFJkcjVJUGIwMGtIWVpEc2hqL3h6?= =?utf-8?B?YnB4K0UvNUs1Mk9MU203eTFZRFR5RmorbW9kU0Rpa3p2RnZKK2NYMFU4NU1O?= =?utf-8?B?ejBBTmdiaUhKd2JFaVBGWENzTC96N2NMSEFMbjNxYWYyem9sL2dQam9aYkE4?= =?utf-8?B?SVE2dEV1TEpWTWRGajB3eWZYa3FlWDVleWtnbTB4R2M5VzM5U1RUcDZLbWQ2?= =?utf-8?B?Qk9OcVR3OCtCK0pMNmJZYU9BMEdVNkdxdE5PK3ZzUlJGOUtIcnM4UWhOMy9X?= =?utf-8?B?ZllsTzE3NTFROXVFNkd3ZGZTOUFxZFQ4Q1REdTJmcmg3eFVzNFVWMTFBWmZX?= =?utf-8?B?TllsMlJmUXVrNEhJRUlrdkgvMFcvNDVJMlhuRGJXMyt3Zm82SlNYbjM4MGRT?= =?utf-8?B?RW1naE1Ybkp6Q2hJNnFNY0JrMVNqT0tMbDFqQmg2M3RvZnRSdlFyVzNuMjJB?= =?utf-8?B?MHdjODR5UmM1ZExWYkd1b1NYM2kwdllHSWM2KzNvUXJzYms1T2pwZkhZOVpL?= =?utf-8?B?ZlFoRm1ZMHNDYzJyVkNUdERYOEtOZWxhMEpZU0pNbTNSMHFweG5vUWVuS3do?= =?utf-8?B?R0V4Y0YwbVlWaDE4S1VXaGRvUi9UUVljRDZUeVp3VGJNWEVSbGJYdUkrVmZU?= =?utf-8?B?OElzemgrS3dIbFVlNGw0TEpwTDd2YnNFY2dnVnRjSC9KNUI4V2wwS2dMeTRk?= =?utf-8?B?c0dGS0R2TG9XK05GMXB5VGhNWXIvczNLZW5QRjZQYnd4UDBYRmc3eWowYXZL?= =?utf-8?B?QTdBckVUVTRidWVQeUVoQUNlZE9uaGxsdkRKNkdNUi8wa2VYcm9EMGRjUHJS?= =?utf-8?B?REJTSzZ2QUQwVnRDZmt2RXYyQmQzVFA0OHlsN003a3BuNE5yY3BIMVY5WGtn?= =?utf-8?B?RHZRUy92MzE1RTMySWIwcDg5ZkJvQ2dLTTArRlBlUmg5TE9RTjd0b25FV0hU?= =?utf-8?B?eWJlTXhiQVREUVdlZzROZDRuQ1YvN3JKZ1c4QlBXR0NKYUdyOHBVZ21hdzJj?= =?utf-8?B?R3U0eWxMdEJzNnpGblJUcFNaaWNGZWVmNm1UdEtrSDI3Zmt1bStxRDRKQ2tF?= =?utf-8?B?dFlDbVVwamdhVWxqS3hSeExBU3FkQ2FPMTF3a3loeDU3S0cxcHpuQnA1WTVH?= =?utf-8?B?WldoY1NORWFzRHBuUUsvNG5JeW1oQ1NBWUxYL1F3bHk1dHRJaEIwN0tzWHpJ?= =?utf-8?B?dmVnNFZQZ3FHZmZ4UzcyUHpwZWJsdGtlTWMwTlcvUEFGOUFkNlM1SElKMk9H?= =?utf-8?B?NWVjZE9RcXJ4YlNScTlkUVFCZGRJWXFsMzgrN0ZtVVpDQmorQWF4T1E2TjFo?= =?utf-8?B?eDV4clNaY3ErSFZVY0JWSEl2QmdKdEhpUkVNV1lvb09NTC9YbXBTQlF5clZ3?= =?utf-8?B?RVRvdmsxWjZMTkZ4THVmeGgzVHFQdG9HQ0Y5Ti9sZ0tIenRiK3lkcUZwdTFG?= =?utf-8?B?SlBmMG84UGdDZUtEZlFXYnRFNnd1NFJxbFNBNVZkV0xYY0tMcmZMT3g1MG5L?= =?utf-8?B?a0JDcHJmS01jVWNIMjlnaXoyNUVwL3FicEo4cE9venpzdjJ1NDhML2VxU2pq?= =?utf-8?Q?CZa8=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(36860700013)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 16:16:22.9125 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 51776997-ac56-4c72-059f-08de52bf1817 X-MS-Exchange-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: BL6PEPF00022575.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4417 On Tue Jan 13, 2026 at 4:19 PM CET, Andrew Cooper wrote: > On 13/01/2026 3:00 pm, Alejandro Vallejo wrote: >> On Tue Jan 13, 2026 at 3:24 PM CET, Andrew Cooper wrote: >>> On 13/01/2026 12:21 pm, Alejandro Vallejo wrote: >>>> It's only used for microcode loading on x86. By lib-ifying it we can m= ake >>>> it go away automatically when microcode loading becomes an optional >>>> feature in follow-up patches. >>>> >>>> Signed-off-by: Alejandro Vallejo >>>> --- >>>> v3: >>>> * New patch. Subsumes earlier conditionalisation of earlycpio.c on >>>> CONFIG_MICROCODE_LOADING. >>>> --- >>>> docs/misra/exclude-list.json | 8 ++++---- >>>> xen/common/Makefile | 2 +- >>>> xen/lib/Makefile | 1 + >>>> xen/{common =3D> lib}/earlycpio.c | 0 >>>> 4 files changed, 6 insertions(+), 5 deletions(-) >>>> rename xen/{common =3D> lib}/earlycpio.c (100%) >>>> >>>> diff --git a/docs/misra/exclude-list.json b/docs/misra/exclude-list.js= on >>>> index 388397dd3b..2b874dfd3b 100644 >>>> --- a/docs/misra/exclude-list.json >>>> +++ b/docs/misra/exclude-list.json >>>> @@ -121,10 +121,6 @@ >>>> "rel_path": "common/bunzip2.c", >>>> "comment": "Imported from Linux, ignore for now" >>>> }, >>>> - { >>>> - "rel_path": "common/earlycpio.c", >>>> - "comment": "Imported from Linux, ignore for now" >>>> - }, >>>> { >>>> "rel_path": "common/gzip/*", >>>> "comment": "Imported from Linux, ignore for now" >>>> @@ -225,6 +221,10 @@ >>>> "rel_path": "include/xen/decompress.h", >>>> "comment": "Imported from Linux, ignore for now" >>>> }, >>>> + { >>>> + "rel_path": "lib/earlycpio.c", >>>> + "comment": "Imported from Linux, ignore for now" >>>> + }, >>>> { >>>> "rel_path": "lib/find-next-bit.c", >>>> "comment": "Imported from Linux, ignore for now" >>> Honestly, I think this needs simply dropping.=C2=A0 "ignore for now" is= n't >>> going to cut it with any competent evaluators. >> That would depend on justifications and such. But regardless clearing th= e >> exclusion list is a different matter aside from removing microcode loadi= ng. >> >>> By libryfing it, it's no longer part of the AMD target build, but it >>> does want covering by *-allcode. >>> >>> Given that you noticed it for v2, I presume there's something in the >>> file that Eclair doesn't like? >> I didn't run Eclair on it. It's ignored as part of common, and the build >> fails in CI if the file in common is absent. That's how I noticed it. >> >> I'd rather not gate this particular change on earlycpio playing ball wit= h >> Eclair. > > I'm explicitly not gating it.=C2=A0 *-allcode is non-blocking, but I want > earlycpio being scanned. > > Simply omitting the second hunk should do this, and not explode the AMD > target build.=C2=A0 (Once this patch is reordered to the end of the serie= s.) > >> >>>> diff --git a/xen/common/Makefile b/xen/common/Makefile >>>> index 92c97d641e..4fc0c15088 100644 >>>> --- a/xen/common/Makefile >>>> +++ b/xen/common/Makefile >>>> @@ -65,7 +65,7 @@ obj-y +=3D wait.o >>>> obj-bin-y +=3D warning.init.o >>>> obj-y +=3D xmalloc_tlsf.o >>>> =20 >>>> -obj-bin-$(CONFIG_X86) +=3D $(foreach n,decompress bunzip2 unxz unlzma= lzo unlzo unlz4 unzstd earlycpio,$(n).init.o) >>>> +obj-bin-$(CONFIG_X86) +=3D $(foreach n,decompress bunzip2 unxz unlzma= lzo unlzo unlz4 unzstd,$(n).init.o) >>>> =20 >>>> obj-$(CONFIG_COMPAT) +=3D $(addprefix compat/,domain.o memory.o multi= call.o xlat.o) >>>> =20 >>>> diff --git a/xen/lib/Makefile b/xen/lib/Makefile >>>> index efca830d92..60cfda4dfc 100644 >>>> --- a/xen/lib/Makefile >>>> +++ b/xen/lib/Makefile >>>> @@ -3,6 +3,7 @@ obj-$(CONFIG_X86) +=3D x86/ >>>> lib-y +=3D bsearch.o >>>> lib-y +=3D ctors.o >>>> lib-y +=3D ctype.o >>>> +lib-y +=3D earlycpio.o >>>> lib-y +=3D find-next-bit.o >>>> lib-y +=3D generic-ffsl.o >>>> lib-y +=3D generic-flsl.o >>>> diff --git a/xen/common/earlycpio.c b/xen/lib/earlycpio.c >>>> similarity index 100% >>>> rename from xen/common/earlycpio.c >>>> rename to xen/lib/earlycpio.c >>> What's wrong with .init here?=C2=A0 There's only a single string which = will >>> end up unmerged so I'm not worried on this side of things, but we now >>> have series doing safety things getting tangled with .init and I want t= o >>> get it fixed. >> .init.o doesn't work with lib-y; only obj-y, obj-bin-y and extra-y. See = below: >> >> $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS-y +=3D -DI= NIT_SECTIONS_ONLY >> >> [snip] >> >> non-init-objects =3D $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(ex= tra-y)) >> >> [snip] >> >> $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): $(obj)/%.init.o: = $(obj)/%.o FORCE >> $(call if_changed,obj_init_o) >> >> That's just what I eyeballed. There might be more hidden elsewhere. >> >> It might want fixing, specially if something like libfdt is to turn into >> a library. But it's just not relevant for this particular change where t= he >> single contained function is already __init. > > *.init.o does two things: > > 1) For things we can tag, check everything is tagged > 2) For things we can't tag with __section(), such as string literals, > move them into .init > > > Fixing lib init properly should just be a case of sprinkling lib-y > through those places you mention.=C2=A0 If you want me to do the patch th= en > fine, but I want it fixed rather than keeping on going around in circles. I can do it, but I'll make a new series to deal with that independently of this if that's alright. Feel free to leave this patch uncommitted until = then.=20 I care far more about the next patch going in. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Tue Jan 13 16:23:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 16:23:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202066.1517683 (Exim 4.92) (envelope-from ) id 1vfhAy-0003Fb-S8; Tue, 13 Jan 2026 16:23:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202066.1517683; Tue, 13 Jan 2026 16:23: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 1vfhAy-0003FQ-OA; Tue, 13 Jan 2026 16:23:24 +0000 Received: by outflank-mailman (input) for mailman id 1202066; Tue, 13 Jan 2026 16:23: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 1vfhAy-0003EQ-2Y for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 16:23:24 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id 2d6a33af-f09c-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 17:23:22 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 797951595; Tue, 13 Jan 2026 08:23:14 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 302063F59E; Tue, 13 Jan 2026 08:23:20 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2d6a33af-f09c-11f0-b15e-2bf370ae4941 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Luca Fancellu , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v3 2/6] arm/mpu: Implement vmap functions for MPU Date: Tue, 13 Jan 2026 16:23:05 +0000 Message-ID: <20260113162309.6766-3-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260113162309.6766-1-harry.ramsey@arm.com> References: <20260113162309.6766-1-harry.ramsey@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Luca Fancellu HAS_VMAP is not enabled on MPU systems, but the vmap functions are used in places across common code. In order to keep the existing code and maintain correct functionality, implement the `vmap_contig` and `vunmap` functions for MPU systems. Introduce a helper function `destroy_xen_mapping_containing` to aid with unmapping an entire region when only the start address is known. Signed-off-by: Luca Fancellu Signed-off-by: Harry Ramsey --- v3: - Add additional comments for clarity regarding MPUMAP_REGION checks - Ensure `context_sync_mpu` occurs after `destroy_entire_xen_mapping` - Fix deadlock if `destroy_entire_xen_mapping` is called with an address that does not belong to a region v2: - Rename `destroy_entire_xen_mapping` to `destroy_xen_mapping_containing` - Improve code documentation - Refactor nested code - Fix ignored rc error code in `destroy_xen_mapping_containing` --- xen/arch/arm/include/asm/mpu/mm.h | 10 ++++ xen/arch/arm/mpu/mm.c | 82 ++++++++++++++++++++++++++----- xen/arch/arm/mpu/vmap.c | 14 ++++-- 3 files changed, 91 insertions(+), 15 deletions(-) diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h index e1ded6521d..1b5ffa5b64 100644 --- a/xen/arch/arm/include/asm/mpu/mm.h +++ b/xen/arch/arm/include/asm/mpu/mm.h @@ -111,6 +111,16 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags); int mpumap_contains_region(pr_t *table, uint8_t nr_regions, paddr_t base, paddr_t limit, uint8_t *index); + +/* + * Destroys and frees (if reference count is 0) an entire xen mapping on MPU + * systems where only the start address is known. + * + * @param s Start address of memory region to be destroyed. + * @return: 0 on success, negative on error. + */ +int destroy_xen_mapping_containing(paddr_t s); + #endif /* __ARM_MPU_MM_H__ */ /* diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c index 687dec3bc6..14a988ea0c 100644 --- a/xen/arch/arm/mpu/mm.c +++ b/xen/arch/arm/mpu/mm.c @@ -290,6 +290,43 @@ static void disable_mpu_region_from_index(uint8_t index) write_protection_region(&xen_mpumap[index], index); } +/* + * Free a xen_mpumap entry given the index. A mpu region is actually disabled + * when the refcount is 0 and the region type is MPUMAP_REGION_FOUND. + * + * @param idx Index of the mpumap entry. + * @param region_found_type MPUMAP_REGION_* value. + * @return 0 on success, otherwise negative on error. + */ +static int xen_mpumap_free_entry(uint8_t idx, int region_found_type) +{ + ASSERT(spin_is_locked(&xen_mpumap_lock)); + ASSERT(idx != INVALID_REGION_IDX); + ASSERT(MPUMAP_REGION_OVERLAP != region_found_type); + + if ( MPUMAP_REGION_NOTFOUND == region_found_type ) + { + printk(XENLOG_ERR "Cannot remove entry that does not exist\n"); + return -EINVAL; + } + + if ( xen_mpumap[idx].refcount ) + { + xen_mpumap[idx].refcount -= 1; + return 0; + } + + if ( MPUMAP_REGION_FOUND == region_found_type ) + disable_mpu_region_from_index(idx); + else + { + printk(XENLOG_ERR "Cannot remove a partial region\n"); + return -EINVAL; + } + + return 0; +} + /* * Update the entry in the MPU memory region mapping table (xen_mpumap) for the * given memory range and flags, creating one if none exists. @@ -357,18 +394,7 @@ static int xen_mpumap_update_entry(paddr_t base, paddr_t limit, return -EINVAL; } - if ( xen_mpumap[idx].refcount == 0 ) - { - if ( MPUMAP_REGION_FOUND == rc ) - disable_mpu_region_from_index(idx); - else - { - printk("Cannot remove a partial region\n"); - return -EINVAL; - } - } - else - xen_mpumap[idx].refcount -= 1; + return xen_mpumap_free_entry(idx, rc); } return 0; @@ -418,6 +444,38 @@ int destroy_xen_mappings(unsigned long s, unsigned long e) return xen_mpumap_update(s, e, 0); } +int destroy_xen_mapping_containing(paddr_t s) +{ + int rc; + uint8_t idx; + + ASSERT(IS_ALIGNED(s, PAGE_SIZE)); + + spin_lock(&xen_mpumap_lock); + + rc = mpumap_contains_region(xen_mpumap, max_mpu_regions, s, s + PAGE_SIZE, + &idx); + + /* + * Since only entire regions can be freed using `xen_mpumap_free_entry` we + * must first check the region exists. + */ + if ( MPUMAP_REGION_NOTFOUND == rc ) { + printk(XENLOG_ERR "Cannot remove entry that does not exist"); + rc = -EINVAL; + goto out; + } + + /* As we are unmapping entire region use MPUMAP_REGION_FOUND instead */ + rc = xen_mpumap_free_entry(idx, MPUMAP_REGION_FOUND); + if ( !rc ) + context_sync_mpu(); + out: + spin_unlock(&xen_mpumap_lock); + + return rc; +} + int map_pages_to_xen(unsigned long virt, mfn_t mfn, unsigned long nr_mfns, unsigned int flags) { diff --git a/xen/arch/arm/mpu/vmap.c b/xen/arch/arm/mpu/vmap.c index f977b79cd4..54d949e7ce 100644 --- a/xen/arch/arm/mpu/vmap.c +++ b/xen/arch/arm/mpu/vmap.c @@ -1,19 +1,27 @@ /* SPDX-License-Identifier: GPL-2.0-only */ #include +#include #include #include #include void *vmap_contig(mfn_t mfn, unsigned int nr) { - BUG_ON("unimplemented"); - return NULL; + paddr_t base = mfn_to_maddr(mfn); + + if ( map_pages_to_xen(base, mfn, nr, PAGE_HYPERVISOR ) ) + return NULL; + + return maddr_to_virt(base); } void vunmap(const void *va) { - BUG_ON("unimplemented"); + paddr_t base = virt_to_maddr(va); + + if ( destroy_xen_mapping_containing(base) ) + panic("Failed to vunmap region\n"); } /* -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 16:23:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 16:23:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202067.1517693 (Exim 4.92) (envelope-from ) id 1vfhB0-0003T1-1t; Tue, 13 Jan 2026 16:23:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202067.1517693; Tue, 13 Jan 2026 16:23:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfhAz-0003Su-Uo; Tue, 13 Jan 2026 16:23:25 +0000 Received: by outflank-mailman (input) for mailman id 1202067; Tue, 13 Jan 2026 16:23: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 1vfhAy-0003EQ-Nq for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 16:23:24 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id 2e6efb5b-f09c-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 17:23:23 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3A15A1596; Tue, 13 Jan 2026 08:23:16 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 73AD33F59E; Tue, 13 Jan 2026 08:23:21 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2e6efb5b-f09c-11f0-b15e-2bf370ae4941 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Penny Zheng , Wei Chen , Luca Fancellu , Hari Limaye Subject: [PATCH v3 3/6] arm/mpu: Implement free_init_memory for MPU systems Date: Tue, 13 Jan 2026 16:23:06 +0000 Message-ID: <20260113162309.6766-4-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260113162309.6766-1-harry.ramsey@arm.com> References: <20260113162309.6766-1-harry.ramsey@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Penny Zheng Implement the function `free_init_memory` for MPU systems. In order to support this, the function `modify_xen_mappings` is implemented. On MPU systems, we map the init text and init data sections using separate MPU memory regions. Therefore these are removed separately in `free_init_memory`. Additionally remove warning messages from `is_mm_attr_match` as some attributes can now be updated by `xen_mpumap_update_entry`. Signed-off-by: Penny Zheng Signed-off-by: Wei Chen Signed-off-by: Luca Fancellu Signed-off-by: Hari Limaye Signed-off-by: Harry Ramsey --- v3: - Refactor MPU_ATTR_* defines v2: - Refactor `is_mm_attr_match` to return logical values regarding the attribute mismatch. - Improve code documentation. --- xen/arch/arm/include/asm/setup.h | 2 + xen/arch/arm/mpu/mm.c | 119 +++++++++++++++++++++++-------- 2 files changed, 93 insertions(+), 28 deletions(-) diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h index 1eaf13bd66..005cf7be59 100644 --- a/xen/arch/arm/include/asm/setup.h +++ b/xen/arch/arm/include/asm/setup.h @@ -65,6 +65,8 @@ int map_irq_to_domain(struct domain *d, unsigned int irq, int map_range_to_domain(const struct dt_device_node *dev, uint64_t addr, uint64_t len, void *data); +extern const char __init_data_begin[], __bss_start[], __bss_end[]; + struct init_info { /* Pointer to the stack, used by head.S when entering in C */ diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c index 14a988ea0c..5633c1c4c5 100644 --- a/xen/arch/arm/mpu/mm.c +++ b/xen/arch/arm/mpu/mm.c @@ -15,6 +15,9 @@ #include #include +#define MPU_ATTR_XN_RO_MISMATCH -1 +#define MPU_ATTR_AI_MISMATCH -2 + struct page_info *frame_table; /* Maximum number of supported MPU memory regions by the EL2 MPU. */ @@ -171,33 +174,16 @@ int mpumap_contains_region(pr_t *table, uint8_t nr_regions, paddr_t base, return MPUMAP_REGION_NOTFOUND; } -static bool is_mm_attr_match(pr_t *region, unsigned int attributes) +static int is_mm_attr_match(pr_t *region, unsigned int attributes) { - if ( region->prbar.reg.ro != PAGE_RO_MASK(attributes) ) - { - printk(XENLOG_WARNING - "Mismatched Access Permission attributes (%#x instead of %#x)\n", - region->prbar.reg.ro, PAGE_RO_MASK(attributes)); - return false; - } - - if ( region->prbar.reg.xn != PAGE_XN_MASK(attributes) ) - { - printk(XENLOG_WARNING - "Mismatched Execute Never attributes (%#x instead of %#x)\n", - region->prbar.reg.xn, PAGE_XN_MASK(attributes)); - return false; - } + if ( (region->prbar.reg.xn != PAGE_XN_MASK(attributes)) || + (region->prbar.reg.ro != PAGE_RO_MASK(attributes)) ) + return MPU_ATTR_XN_RO_MISMATCH; if ( region->prlar.reg.ai != PAGE_AI_MASK(attributes) ) - { - printk(XENLOG_WARNING - "Mismatched Memory Attribute Index (%#x instead of %#x)\n", - region->prlar.reg.ai, PAGE_AI_MASK(attributes)); - return false; - } + return MPU_ATTR_AI_MISMATCH; - return true; + return 0; } /* Map a frame table to cover physical addresses ps through pe */ @@ -358,12 +344,44 @@ static int xen_mpumap_update_entry(paddr_t base, paddr_t limit, */ if ( flags_has_page_present && (rc >= MPUMAP_REGION_FOUND) ) { - if ( !is_mm_attr_match(&xen_mpumap[idx], flags) ) + int attr_match = is_mm_attr_match(&xen_mpumap[idx], flags); + + /* We do not support modifying AI attribute. */ + if ( MPU_ATTR_AI_MISMATCH == attr_match ) { - printk("Modifying an existing entry is not supported\n"); + printk(XENLOG_ERR + "Modifying memory attribute is not supported\n"); return -EINVAL; } + /* + * Attributes RO and XN can be changed only by the full region. + * Attributes that match can continue and just increment refcount. + */ + if ( MPU_ATTR_XN_RO_MISMATCH == attr_match ) + { + if ( rc == MPUMAP_REGION_INCLUSIVE ) + { + printk(XENLOG_ERR + "Cannot modify partial region attributes\n"); + return -EINVAL; + } + + if ( xen_mpumap[idx].refcount != 0 ) + { + printk(XENLOG_ERR + "Cannot modify memory attributes for a region mapped multiple times\n"); + return -EINVAL; + } + + /* Set new attributes */ + xen_mpumap[idx].prbar.reg.ro = PAGE_RO_MASK(flags); + xen_mpumap[idx].prbar.reg.xn = PAGE_XN_MASK(flags); + + write_protection_region(&xen_mpumap[idx], idx); + return 0; + } + /* Check for overflow of refcount before incrementing. */ if ( xen_mpumap[idx].refcount == 0xFF ) { @@ -514,8 +532,7 @@ void __init setup_mm_helper(void) int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf) { - BUG_ON("unimplemented"); - return -EINVAL; + return xen_mpumap_update(s, e, nf); } void dump_hyp_walk(vaddr_t addr) @@ -526,7 +543,53 @@ void dump_hyp_walk(vaddr_t addr) /* Release all __init and __initdata ranges to be reused */ void free_init_memory(void) { - BUG_ON("unimplemented"); + unsigned long inittext_end = (unsigned long)__init_data_begin; + unsigned long len = __init_end - __init_begin; + uint8_t idx; + int rc; + + /* Modify inittext region to be read/write instead of read/execute. */ + rc = modify_xen_mappings((unsigned long)__init_begin, inittext_end, + PAGE_HYPERVISOR_RW); + if ( rc ) + panic("Unable to map RW the init text section (rc = %d)\n", rc); + + /* + * From now on, init will not be used for execution anymore, + * so nuke the instruction cache to remove entries related to init. + */ + invalidate_icache_local(); + + /* + * The initdata region already has read/write attributes so it can just be + * zeroed out. + */ + memset(__init_begin, 0, len); + + rc = destroy_xen_mappings((unsigned long)__init_begin, inittext_end); + if ( rc ) + panic("Unable to remove init text section (rc = %d)\n", rc); + + /* + * The initdata and bss sections are mapped using a single MPU region, so + * modify the start of this region to remove the initdata section. + */ + spin_lock(&xen_mpumap_lock); + + rc = mpumap_contains_region(xen_mpumap, max_mpu_regions, + (unsigned long)__init_data_begin, + (unsigned long)__bss_end, + &idx); + if ( rc < MPUMAP_REGION_FOUND ) + panic("Unable to find bss data section (rc = %d)\n", rc); + + /* bss data section is shrunk and now starts from __bss_start */ + pr_set_base(&xen_mpumap[idx], (unsigned long)__bss_start); + + write_protection_region(&xen_mpumap[idx], idx); + context_sync_mpu(); + + spin_unlock(&xen_mpumap_lock); } void __iomem *ioremap_attr(paddr_t start, size_t len, unsigned int flags) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 16:23:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 16:23:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202068.1517703 (Exim 4.92) (envelope-from ) id 1vfhB1-0003hR-Dy; Tue, 13 Jan 2026 16:23:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202068.1517703; Tue, 13 Jan 2026 16: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 1vfhB1-0003hH-9K; Tue, 13 Jan 2026 16:23:27 +0000 Received: by outflank-mailman (input) for mailman id 1202068; Tue, 13 Jan 2026 16: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 1vfhAz-0003EQ-T1 for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 16:23:25 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id 2f457747-f09c-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 17:23:25 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8D92E15A1; Tue, 13 Jan 2026 08:23:17 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2A47B3F59E; Tue, 13 Jan 2026 08:23:23 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2f457747-f09c-11f0-b15e-2bf370ae4941 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Luca Fancellu , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Hari Limaye Subject: [PATCH v3 4/6] arm/mpu: Introduce modify_after_init_mappings Date: Tue, 13 Jan 2026 16:23:07 +0000 Message-ID: <20260113162309.6766-5-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260113162309.6766-1-harry.ramsey@arm.com> References: <20260113162309.6766-1-harry.ramsey@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Luca Fancellu During `init_done`, Xen sets the permissions of all symbols marked with __ro_after_init to be read-only. This does not work on MPU systems at present because part-region modification is not supported. Therefore introduce the function `modify_after_init_mappings` for MMU and MPU, to handle the divergent approaches to setting permissions of __ro_after_init symbols. For MPU systems `modify_xen_mappings` will shrink the RW mapping on one side and extend the RO mapping on the other. This approach prevents wasting an additional region between RW and RO mappings. As the new function is marked with __init, it needs to be called before `free_init_memory`. Signed-off-by: Luca Fancellu Signed-off-by: Hari Limaye Signed-off-by: Harry Ramsey Reviewed-by: Michal Orzel --- v3: - Add Michal R-by v2: - No changes --- xen/arch/arm/include/asm/setup.h | 3 +++ xen/arch/arm/mmu/setup.c | 15 ++++++++++++ xen/arch/arm/mpu/mm.c | 2 +- xen/arch/arm/mpu/setup.c | 40 ++++++++++++++++++++++++++++++++ xen/arch/arm/setup.c | 15 ++---------- 5 files changed, 61 insertions(+), 14 deletions(-) diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h index 005cf7be59..899e33925c 100644 --- a/xen/arch/arm/include/asm/setup.h +++ b/xen/arch/arm/include/asm/setup.h @@ -78,6 +78,9 @@ struct init_info paddr_t consider_modules(paddr_t s, paddr_t e, uint32_t size, paddr_t align, int first_mod); +/* Modify some mappings after the init is done */ +void modify_after_init_mappings(void); + #endif /* * Local variables: diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c index 9b874f8ab2..d042f73597 100644 --- a/xen/arch/arm/mmu/setup.c +++ b/xen/arch/arm/mmu/setup.c @@ -213,6 +213,21 @@ void __init remove_early_mappings(void) BUG_ON(rc); } +void __init modify_after_init_mappings(void) +{ + /* + * We have finished booting. Mark the section .data.ro_after_init + * read-only. + */ + int rc = modify_xen_mappings((unsigned long)&__ro_after_init_start, + (unsigned long)&__ro_after_init_end, + PAGE_HYPERVISOR_RO); + + if ( rc ) + panic("Unable to mark the .data.ro_after_init section read-only (rc = %d)\n", + rc); +} + /* * After boot, Xen page-tables should not contain mapping that are both * Writable and eXecutables. diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c index 5633c1c4c5..eb00acb9a9 100644 --- a/xen/arch/arm/mpu/mm.c +++ b/xen/arch/arm/mpu/mm.c @@ -35,7 +35,7 @@ DECLARE_BITMAP(xen_mpumap_mask, MAX_MPU_REGION_NR) \ /* EL2 Xen MPU memory region mapping table. */ pr_t __cacheline_aligned __section(".data") xen_mpumap[MAX_MPU_REGION_NR]; -static DEFINE_SPINLOCK(xen_mpumap_lock); +DEFINE_SPINLOCK(xen_mpumap_lock); static void __init __maybe_unused build_assertions(void) { diff --git a/xen/arch/arm/mpu/setup.c b/xen/arch/arm/mpu/setup.c index ec264f54f2..55317ee318 100644 --- a/xen/arch/arm/mpu/setup.c +++ b/xen/arch/arm/mpu/setup.c @@ -8,11 +8,14 @@ #include #include #include +#include #include static paddr_t __initdata mapped_fdt_base = INVALID_PADDR; static paddr_t __initdata mapped_fdt_limit = INVALID_PADDR; +extern spinlock_t xen_mpumap_lock; + void __init setup_pagetables(void) {} void * __init early_fdt_map(paddr_t fdt_paddr) @@ -106,6 +109,43 @@ void __init copy_from_paddr(void *dst, paddr_t paddr, unsigned long len) panic("Unable to unmap range for copy_from_paddr\n"); } +void __init modify_after_init_mappings(void) +{ + int rc; + uint8_t idx_rodata; + uint8_t idx_rwdata; + + spin_lock(&xen_mpumap_lock); + + rc = mpumap_contains_region(xen_mpumap, max_mpu_regions, + (unsigned long)_srodata, + (unsigned long)_erodata, + &idx_rodata); + + if ( rc < MPUMAP_REGION_FOUND ) + panic("Unable to find rodata section (rc = %d)\n", rc); + + rc = mpumap_contains_region(xen_mpumap, max_mpu_regions, + (unsigned long)__ro_after_init_start, + (unsigned long)__init_begin, + &idx_rwdata); + + if ( rc < MPUMAP_REGION_FOUND ) + panic("Unable to find rwdata section (rc = %d)\n", rc); + + /* Shrink rwdata section to begin at __ro_after_init_end */ + pr_set_base(&xen_mpumap[idx_rwdata], (unsigned long)__ro_after_init_end); + + /* Extend rodata section to end at __ro_after_init_end */ + pr_set_limit(&xen_mpumap[idx_rodata], (unsigned long)__ro_after_init_end); + + write_protection_region(&xen_mpumap[idx_rwdata], idx_rwdata); + write_protection_region(&xen_mpumap[idx_rodata], idx_rodata); + context_sync_mpu(); + + spin_unlock(&xen_mpumap_lock); +} + void __init remove_early_mappings(void) { int rc = destroy_xen_mappings(round_pgdown(mapped_fdt_base), diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 7ad870e382..6310a47d68 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -66,23 +66,12 @@ domid_t __read_mostly max_init_domid; static __used void noreturn init_done(void) { - int rc; - /* Must be done past setting system_state. */ unregister_init_virtual_region(); - free_init_memory(); + modify_after_init_mappings(); - /* - * We have finished booting. Mark the section .data.ro_after_init - * read-only. - */ - rc = modify_xen_mappings((unsigned long)&__ro_after_init_start, - (unsigned long)&__ro_after_init_end, - PAGE_HYPERVISOR_RO); - if ( rc ) - panic("Unable to mark the .data.ro_after_init section read-only (rc = %d)\n", - rc); + free_init_memory(); startup_cpu_idle_loop(); } -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 16:23:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 16:23:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202069.1517712 (Exim 4.92) (envelope-from ) id 1vfhB2-0003wC-K9; Tue, 13 Jan 2026 16:23:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202069.1517712; Tue, 13 Jan 2026 16: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 1vfhB2-0003w5-Gy; Tue, 13 Jan 2026 16:23:28 +0000 Received: by outflank-mailman (input) for mailman id 1202069; Tue, 13 Jan 2026 16: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 1vfhB1-0003EQ-21 for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 16:23:27 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id 3032fa90-f09c-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 17:23:26 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4D5B81650; Tue, 13 Jan 2026 08:23:19 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 878793F59E; Tue, 13 Jan 2026 08:23:24 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3032fa90-f09c-11f0-b15e-2bf370ae4941 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Penny Zheng , Wei Chen , Luca Fancellu , Ayan Kumar Halder Subject: [PATCH v3 5/6] arm: Use secure hypervisor timer in MPU system Date: Tue, 13 Jan 2026 16:23:08 +0000 Message-ID: <20260113162309.6766-6-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260113162309.6766-1-harry.ramsey@arm.com> References: <20260113162309.6766-1-harry.ramsey@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Penny Zheng As MPU systems only have one secure state, we have to use secure EL2 hypervisor timer for Xen in secure EL2. Signed-off-by: Penny Zheng Signed-off-by: Wei Chen Signed-off-by: Luca Fancellu Signed-off-by: Harry Ramsey Reviewed-by: Ayan Kumar Halder Acked-by: Michal Orzel --- v3: - Add Ayan R-by - Add Michal A-by v2: - Remove unncessary kconfig attribute. - Remove unncessary hypervisor timer macro. --- xen/arch/arm/include/asm/arm64/sysregs.h | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/include/asm/arm64/sysregs.h index 7dfd20414d..19d409d3eb 100644 --- a/xen/arch/arm/include/asm/arm64/sysregs.h +++ b/xen/arch/arm/include/asm/arm64/sysregs.h @@ -462,6 +462,17 @@ #define ZCR_ELx_LEN_SIZE 9 #define ZCR_ELx_LEN_MASK 0x1ff +#ifdef CONFIG_MPU +/* + * The Armv8-R AArch64 architecture always executes code in Secure + * state with EL2 as the highest exception level. + * + * Hypervisor timer registers for Secure EL2. + */ +#define CNTHP_CTL_EL2 CNTHPS_CTL_EL2 +#define CNTHP_CVAL_EL2 CNTHPS_CVAL_EL2 +#endif + #define REGION_TEXT_PRBAR 0x38 /* SH=11 AP=10 XN=00 */ #define REGION_RO_PRBAR 0x3A /* SH=11 AP=10 XN=10 */ #define REGION_DATA_PRBAR 0x32 /* SH=11 AP=00 XN=10 */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 16:23:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 16:23:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202070.1517723 (Exim 4.92) (envelope-from ) id 1vfhB3-0004BI-Tl; Tue, 13 Jan 2026 16:23:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202070.1517723; Tue, 13 Jan 2026 16:23: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 1vfhB3-0004AF-Oz; Tue, 13 Jan 2026 16:23:29 +0000 Received: by outflank-mailman (input) for mailman id 1202070; Tue, 13 Jan 2026 16:23: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 1vfhB3-0003EQ-5j for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 16:23:29 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id 312d5f62-f09c-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 17:23:28 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EC0CC1655; Tue, 13 Jan 2026 08:23:20 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 45B953F59E; Tue, 13 Jan 2026 08:23:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 312d5f62-f09c-11f0-b15e-2bf370ae4941 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Penny Zheng , Wei Chen , Luca Fancellu Subject: [PATCH v3 6/6] arm/mpu: Map domain page in AArch64 MPU systems Date: Tue, 13 Jan 2026 16:23:09 +0000 Message-ID: <20260113162309.6766-7-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260113162309.6766-1-harry.ramsey@arm.com> References: <20260113162309.6766-1-harry.ramsey@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Penny Zheng In MPU systems, we implement map_domain_page()/unmap_domain_page() through mapping the domain page with a MPU region on demand. Signed-off-by: Penny Zheng Signed-off-by: Wei Chen Signed-off-by: Luca Fancellu Signed-off-by: Harry Ramsey --- v3: - No changes v2: - No changes --- xen/arch/arm/Kconfig | 1 + xen/arch/arm/mpu/Makefile | 1 + xen/arch/arm/mpu/domain-page.c | 53 ++++++++++++++++++++++++++++++++++ 3 files changed, 55 insertions(+) create mode 100644 xen/arch/arm/mpu/domain-page.c diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index cf6af68299..baa6c4cf15 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -91,6 +91,7 @@ config MMU config MPU bool "MPU" if UNSUPPORTED + select ARCH_MAP_DOMAIN_PAGE if ARM_64 select STATIC_MEMORY help Memory Protection Unit (MPU). Select if you plan to run Xen on ARMv8-R diff --git a/xen/arch/arm/mpu/Makefile b/xen/arch/arm/mpu/Makefile index 4963c8b550..940297af3f 100644 --- a/xen/arch/arm/mpu/Makefile +++ b/xen/arch/arm/mpu/Makefile @@ -1,5 +1,6 @@ obj-$(CONFIG_ARM_32) += arm32/ obj-$(CONFIG_ARM_64) += arm64/ +obj-$(CONFIG_ARM_64) += domain-page.o obj-y += mm.o obj-y += p2m.o obj-y += setup.init.o diff --git a/xen/arch/arm/mpu/domain-page.c b/xen/arch/arm/mpu/domain-page.c new file mode 100644 index 0000000000..1b43bf82a6 --- /dev/null +++ b/xen/arch/arm/mpu/domain-page.c @@ -0,0 +1,53 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include +#include +#include +#include +#include + +void *map_domain_page_global(mfn_t mfn) +{ + BUG_ON("unimplemented"); + return NULL; +} + +/* Map a page of domheap memory */ +void *map_domain_page(mfn_t mfn) +{ + paddr_t pa = mfn_to_maddr(mfn); + + if ( map_pages_to_xen((unsigned long)pa, mfn, 1, PAGE_HYPERVISOR_RW) ) + return NULL; + + return maddr_to_virt(pa); +} + +/* Release a mapping taken with map_domain_page() */ +void unmap_domain_page(const void *ptr) +{ + paddr_t base = virt_to_maddr(ptr); + + if ( destroy_xen_mapping_containing(base) ) + panic("Failed to unmap domain page\n"); +} + +mfn_t domain_page_map_to_mfn(const void *ptr) +{ + BUG_ON("unimplemented"); + return INVALID_MFN; +} + +void unmap_domain_page_global(const void *va) +{ + BUG_ON("unimplemented"); +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 16:23:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 16:23:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202071.1517733 (Exim 4.92) (envelope-from ) id 1vfhB6-0004UT-5x; Tue, 13 Jan 2026 16:23:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202071.1517733; Tue, 13 Jan 2026 16:23: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 1vfhB6-0004UH-1h; Tue, 13 Jan 2026 16:23:32 +0000 Received: by outflank-mailman (input) for mailman id 1202071; Tue, 13 Jan 2026 16:23: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 1vfhB5-0004Qo-Bf for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 16:23:31 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id 2be01ab2-f09c-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 17:23:19 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D0F241516; Tue, 13 Jan 2026 08:23:11 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9CD2B3F59E; Tue, 13 Jan 2026 08:23:17 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2be01ab2-f09c-11f0-9ccf-f158ae23cfc8 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v3 0/6] Fourth MPU series Date: Tue, 13 Jan 2026 16:23:03 +0000 Message-ID: <20260113162309.6766-1-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This series aims to further the ongoing work to introduce support for MPU systems in xen. The patches in this series implement various memory functions and enable the hypervisor timer. Luca Fancellu (3): arm/mpu: Implement copy_from_paddr for MPU systems arm/mpu: Implement vmap functions for MPU arm/mpu: Introduce modify_after_init_mappings Penny Zheng (3): arm/mpu: Implement free_init_memory for MPU systems arm: Use secure hypervisor timer in MPU system arm/mpu: Map domain page in AArch64 MPU systems xen/arch/arm/Kconfig | 1 + xen/arch/arm/include/asm/arm64/sysregs.h | 11 ++ xen/arch/arm/include/asm/mpu/mm.h | 10 ++ xen/arch/arm/include/asm/setup.h | 5 + xen/arch/arm/mmu/setup.c | 15 ++ xen/arch/arm/mpu/Makefile | 1 + xen/arch/arm/mpu/domain-page.c | 53 ++++++ xen/arch/arm/mpu/mm.c | 203 ++++++++++++++++++----- xen/arch/arm/mpu/setup.c | 54 +++++- xen/arch/arm/mpu/vmap.c | 14 +- xen/arch/arm/setup.c | 15 +- 11 files changed, 324 insertions(+), 58 deletions(-) create mode 100644 xen/arch/arm/mpu/domain-page.c -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 16:23:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 16:23:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202072.1517743 (Exim 4.92) (envelope-from ) id 1vfhB7-0004kq-Fg; Tue, 13 Jan 2026 16:23:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202072.1517743; Tue, 13 Jan 2026 16:23:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfhB7-0004k0-Ae; Tue, 13 Jan 2026 16:23:33 +0000 Received: by outflank-mailman (input) for mailman id 1202072; Tue, 13 Jan 2026 16:23:32 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfhB6-0004Qo-0H for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 16:23:32 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id 2ca868df-f09c-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 17:23:20 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 364BC497; Tue, 13 Jan 2026 08:23:13 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C74453F59E; Tue, 13 Jan 2026 08:23:18 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2ca868df-f09c-11f0-9ccf-f158ae23cfc8 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Luca Fancellu , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Hari Limaye Subject: [PATCH v3 1/6] arm/mpu: Implement copy_from_paddr for MPU systems Date: Tue, 13 Jan 2026 16:23:04 +0000 Message-ID: <20260113162309.6766-2-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260113162309.6766-1-harry.ramsey@arm.com> References: <20260113162309.6766-1-harry.ramsey@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Luca Fancellu Implement the function copy_from_paddr variant for MPU systems, using the map_pages_to_xen/destroy_xen_mappings to temporarily map the memory range to be copied. Signed-off-by: Luca Fancellu Signed-off-by: Hari Limaye Signed-off-by: Harry Ramsey Reviewed-by: Michal Orzel --- v3: - No changes v2: - add Michal R-by --- xen/arch/arm/mpu/setup.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/mpu/setup.c b/xen/arch/arm/mpu/setup.c index 163573b932..ec264f54f2 100644 --- a/xen/arch/arm/mpu/setup.c +++ b/xen/arch/arm/mpu/setup.c @@ -91,7 +91,19 @@ void * __init early_fdt_map(paddr_t fdt_paddr) */ void __init copy_from_paddr(void *dst, paddr_t paddr, unsigned long len) { - BUG_ON("unimplemented"); + paddr_t start_pg = round_pgdown(paddr); + paddr_t end_pg = round_pgup(paddr + len); + unsigned long nr_mfns = (end_pg - start_pg) >> PAGE_SHIFT; + mfn_t mfn = maddr_to_mfn(start_pg); + + if ( map_pages_to_xen(start_pg, mfn, nr_mfns, PAGE_HYPERVISOR_WC) ) + panic("Unable to map range for copy_from_paddr\n"); + + memcpy(dst, maddr_to_virt(paddr), len); + clean_dcache_va_range(dst, len); + + if ( destroy_xen_mappings(start_pg, end_pg) ) + panic("Unable to unmap range for copy_from_paddr\n"); } void __init remove_early_mappings(void) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 13 16:33:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 16:33:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202151.1517789 (Exim 4.92) (envelope-from ) id 1vfhL0-0008Nk-PX; Tue, 13 Jan 2026 16:33:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202151.1517789; Tue, 13 Jan 2026 16:33:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfhL0-0008Nd-Le; Tue, 13 Jan 2026 16:33:46 +0000 Received: by outflank-mailman (input) for mailman id 1202151; Tue, 13 Jan 2026 16:33:45 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfhKz-0008NX-IL for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 16:33:45 +0000 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [2a00:1450:4864:20::631]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a0aa63d9-f09d-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 17:33:44 +0100 (CET) Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-b874c00a39fso96876066b.0 for ; Tue, 13 Jan 2026 08:33:44 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b871b5e60dasm630149866b.63.2026.01.13.08.33.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 08:33:43 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a0aa63d9-f09d-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768322024; x=1768926824; 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=UUlhDfD+5kJ3y3bTAFKu0Qryexyh4VkeiASI0Y9BHnc=; b=kPGESVAcApXehNze1qV6AsXHGrZq6BlSjJ6fzSx3UEJYiFGIrCVRmBs768tdHvIYp0 Mf3ToDWKkkY/wo7munPSPma1/TV5YEq4g+wUSp4Ui9RAiLpxLG9VMGR+Kl+4qA/YCszZ ksSvk0W7WwE092/H4QrRawua4qkp8Rche48/oT6mL7IVjlKSUe0/T4Gl7BSg044cGmdK V8eAIawl+dT+DLtaFwrrOcAGDreGo2jqujnCdOdHdyFUziP1AbMYb5Lmowcu1iEI8S7c 9T8HEopdnvFBOCVO2InvExU+67VKE/fJ4QJV/AxaxprbC3NrOVbLB4pmBDmiLBTez2Ql 2NPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768322024; x=1768926824; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=UUlhDfD+5kJ3y3bTAFKu0Qryexyh4VkeiASI0Y9BHnc=; b=D22ATOUSjpPPdZtM6PV/WMJqkSRwmzU1MOOWj7EQYBp4f8OfXnUeZOajRtjgRw97r7 MCtj+LpJ/pU6MgSofb6K2O2fzshjfgeFphhFnzaMkFhk/A3BCY3m3MeJMOxMXDFEPCw4 9MDV4Env+EZORS1QdJVPFG8pNrsb3L2Fjo9sTN88fiISlZeYCSeksUPyiPYIwEnc7sFt mDrbnQvkMP88f0xHz89vzeKlO2srL7jyPh0gBjmGs7MPQRF4tJ5Lo6TOmk9AZK5OciTM XYBPVcJGVu83ZB0VyTJU/w7ie2A4gbL+m7/Tzj29pX6W3wB4uXIFfXyKDPe0ji2z17pk PiRg== X-Forwarded-Encrypted: i=1; AJvYcCVbQogxYWujj5iocr40J0bdkWPYiwOQM/oeySGwh9eB8D0SHBfu40HT5rh2uVQd8QwSEKJdCKWFKks=@lists.xenproject.org X-Gm-Message-State: AOJu0YzK+5UHioIlfmY9o1rKytDhDjDE/qtqP/qPQao4UCU6eP5dQREn o8Td2grUm/eggWEjpx8PYL5H0qHosW4BqSoUWoSM7eq/sUFJK2XMvZZx X-Gm-Gg: AY/fxX4EqcB2u49Qi1fvg8mxLNPorJHxVJZeWRy27jGHBcnpS0gVL12ff2bXofUgWog 1ig1MXJiLBq8WAnCKcR7eoplXZMMdIPBW1ddfJPBS98Y6cb0akbnhad3jZULabFc9iDg2Mj1FMw 2OQFvmxUy1KqB3hSFNmGji0RiIve5PLFr2uoV8BzPzutc8x8r0xIy8tJENgQ1fpdvHY4kv04I5s Jo2nnhyxxbNDk1OxJk59kbSXWK0yKup3dWqPt/LkdaYaLv1lNdLe8iTwQdFB/i+g/UJBVyXsxwG P3OzTFS2q5osqeB//BDZ+kqsnUr56csNiaosbjpneF3HhnfMd4rOyA2gor8m8z2abEVu0GojwHJ Kt9ueVumu4LQzvsz7G4Nc9KWjRvsob1Q8gZt3ZFkTBrcqKTmfDhJ2DbHcifdanFYd94MlBRgxZ9 RAJBXx8KY3LD7Q5DR1MpvVTtZ6QdanJtna6B6ksM/nWo0e6dm5rMfGPrRivJZcGtc= X-Google-Smtp-Source: AGHT+IH/G0244y9OuKNun+CMAHAvQ1guMab8G9IMZZ5hsqp4Fvwl3y/XTCXI4nXTJwKMa5VRO86Szw== X-Received: by 2002:a17:907:2887:b0:b87:59a8:4c8 with SMTP id a640c23a62f3a-b8759a805b3mr41562966b.5.1768322023537; Tue, 13 Jan 2026 08:33:43 -0800 (PST) Message-ID: <5f658f5b-1c22-4bd7-9f25-f89576d5003e@gmail.com> Date: Tue, 13 Jan 2026 17:33:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 12/15] xen/riscv: introduce sbi_set_timer() 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: <84cf8fb2331614c6d0cc6e9030571f42bfc6d928.1766595589.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/12/26 4:12 PM, Jan Beulich wrote: > On 24.12.2025 18:03, Oleksii Kurochko wrote: >> Introduce pointer to function which points to a specific sbi_set_timer() >> implementation. It is done in this way as different OpenSBI version can >> have different Extenion ID and/or funcion ID for TIME extension. >> >> sbi_set_time() programs the clock for next event after stime_value >> time. This function also clears the pending timer interrupt bit. >> >> Introduce extension ID and SBI function ID for TIME extension. >> >> Implement only sbi_set_timer_v02() as there is not to much sense >> to support earlier version and, at the moment, Xen supports only v02. > Besides this somewhat contradicting the use of a function pointer: What > about the legacy extension's equivalent? I think this is not really needed, and the same implementation can be used for both the Legacy and TIME extensions, since the API is identical and the only difference is that|sbi_set_timer()| was moved into a separate extension. Since Xen reports to the guest that it supports SBI v0.2, it is up to the guest implementation to decide why it is still using|sbi_set_timer()| from the Legacy extension instead of the TIME extension. I think that I can add Legacy extension equivalent but considering that we are using OpenSBI v0.2 for which Time extension is available it seems for me it is enough to define sbi_set_timer to sbi_set_timer_v02() for now. > >> --- a/xen/arch/riscv/include/asm/sbi.h >> +++ b/xen/arch/riscv/include/asm/sbi.h >> @@ -33,6 +33,7 @@ >> >> #define SBI_EXT_BASE 0x10 >> #define SBI_EXT_RFENCE 0x52464E43 >> +#define SBI_EXT_TIME 0x54494D45 >> >> /* SBI function IDs for BASE extension */ >> #define SBI_EXT_BASE_GET_SPEC_VERSION 0x0 >> @@ -65,6 +66,9 @@ >> >> #define SBI_SPEC_VERSION_DEFAULT 0x1 >> >> +/* SBI function IDs for TIME extension */ >> +#define SBI_EXT_TIME_SET_TIMER 0x0 > Move up besides the other SBI_EXT_* and use the same amount of padding? Sure, I will do that. > >> @@ -138,6 +142,19 @@ int sbi_remote_hfence_gvma(const cpumask_t *cpu_mask, vaddr_t start, >> int sbi_remote_hfence_gvma_vmid(const cpumask_t *cpu_mask, vaddr_t start, >> size_t size, unsigned long vmid); >> >> +/* >> + * Programs the clock for next event after stime_value time. This function also >> + * clears the pending timer interrupt bit. >> + * If the supervisor wishes to clear the timer interrupt without scheduling the >> + * next timer event, it can either request a timer interrupt infinitely far >> + * into the future (i.e., (uint64_t)-1), or it can instead mask the timer >> + * interrupt by clearing sie.STIE CSR bit. >> + * >> + * This SBI call returns 0 upon success or an implementation specific negative >> + * error code. >> + */ >> +extern int (*sbi_set_timer)(uint64_t stime_value); > Despite the pretty extensive comment, the granularity of the value to be passed > isn't mentioned. I update the comment with the following then: The stime_value parameter represents absolute time measured in ticks. > >> --- a/xen/arch/riscv/sbi.c >> +++ b/xen/arch/riscv/sbi.c >> @@ -249,6 +249,26 @@ static int (* __ro_after_init sbi_rfence)(unsigned long fid, >> unsigned long arg4, >> unsigned long arg5); >> >> +static int cf_check sbi_set_timer_v02(uint64_t stime_value) >> +{ >> + struct sbiret ret; >> + >> +#ifdef CONFIG_RISCV_64 >> + ret = sbi_ecall(SBI_EXT_TIME, SBI_EXT_TIME_SET_TIMER, stime_value, 0, >> + 0, 0, 0, 0); >> +#else >> + ret = sbi_ecall(SBI_EXT_TIME, SBI_EXT_TIME_SET_TIMER, stime_value, >> + stime_value >> 32, 0, 0, 0, 0); >> +#endif > How about > > ret = sbi_ecall(SBI_EXT_TIME, SBI_EXT_TIME_SET_TIMER, stime_value, > #ifdef CONFIG_RISCV_64 > 0, > #else > stime_value >> 32, > #endif > 0, 0, 0, 0); > > ? Granted some may say this looks a little m ore clumsy, but it's surely > less redundancy. > > Also I'd suggest to use CONFIG_RISCV_32 with the #ifdef, as then the "else" > covers both RV64 and RV128. Makes sense, I will update the function in mentioned way. > >> + if ( ret.error ) >> + return sbi_err_map_xen_errno(ret.error); >> + else >> + return 0; >> +} > While I understand this is being debated, I continue to think that this > kind of use of if/else isn't very helpful. Function's main return > statements imo benefit from being unconditional. Considering what returns sbi_err_map_xen_errno() we can just drop if/else and have only: return sbi_err_map_xen_errno(ret.error); as if ret.error == SBI_SUCCESS(0) then sbi_err_map_xen_errno() will return 0. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Jan 13 16:47:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 16:47:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202176.1517798 (Exim 4.92) (envelope-from ) id 1vfhXy-0001qN-Vx; Tue, 13 Jan 2026 16:47:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202176.1517798; Tue, 13 Jan 2026 16:47:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfhXy-0001qG-TJ; Tue, 13 Jan 2026 16:47:10 +0000 Received: by outflank-mailman (input) for mailman id 1202176; Tue, 13 Jan 2026 16:47: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 1vfhXx-0001qA-AV for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 16:47:09 +0000 Received: from CH4PR04CU002.outbound.protection.outlook.com (mail-northcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c105::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7f0dba36-f09f-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 17:47:08 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS1PR03MB7967.namprd03.prod.outlook.com (2603:10b6:8:21a::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 16:47:04 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.005; Tue, 13 Jan 2026 16: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" X-Inumbo-ID: 7f0dba36-f09f-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FtFKjAXp9GQ2kgfrjc+EvbcwqMWEtQNVcL9mnHlvswQmNiwUcmmOEIFFXWF5DXUG6Jr16BTQiwk1ywY2wq5ufQn0wzlKOquqWtz3WhnZhjPwGL7wmRxdsO8GgIgBp6GLhti1SXzj8Qh0vzypPYAK12dZ5B34WFB9u5Ic+ouNj//ZUX7TYV65ysgM2utG+pp/GNM+UHifoYl+65w2I6Tw7CdJFxwAZTXYf4K9zUPR53sf7GykwkHX6p8N2Cobo0LisNCetPzOUth1fQjc6vsSBKJaassbLmWfEQAm2eM4JOWt9H+M1JR9coywm1ZlfLhuRPBlvlciu/FgWuJOulNLcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kIG4mSMbZSnCptsDEr0hozuhM7aJ3MO1bArNE8P9lVM=; b=FqghGb+ryAxHiamrQIny8xzFXwF4g/L3e3LzPE1UQ2vcj09s8tAGT4EGqXDLqupu6DpYnfHX+Xyw6pDZgyVhGb1Ud7I8BDLYAS8APgKcBP/cTT2jdsXKMWJdxxD8LjhO6Q3IrToM30gILjgKmdklCGSdHPbFESWcWpokldFVE/y5MrCq1Ukkb3rNxkkH/Q125zYyfd6DPVHD+iLV9QknOL1mAQ814rvJW1aQQIL0kFqy4whmlbdDDLzm1ebk60hfDn+Fip3OTKwVo815UUmGehaof/+NJ6c0iqFUWIp+NtjUPypysMnT+5AnFvbBoZdILSl+Yv1x5dcxF1sUbYREXw== 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=kIG4mSMbZSnCptsDEr0hozuhM7aJ3MO1bArNE8P9lVM=; b=krM/FYC9UytDdEF5K2BfGhPLB2tbt7pwPg3y6YYEpsK7OdFaf8Y+S6KdGW84SjtGwL6QiURVBHsmDg/AzZmZeoy/KgYH4Ll8hx9RCN9AkWDzYNzeyvt48KA4C4bs0dzMaI1IbY1CRVP1CO7hJYfLrV4cmx8WdvOChtNKroP5NbI= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <1dab1120-d947-4e5e-bf9d-0dfa5ec35bb0@citrix.com> Date: Tue, 13 Jan 2026 16:47:00 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , xen-devel@lists.xenproject.org Subject: Re: [PATCH v3 4/4] x86/ucode: Add Kconfig option to remove microcode loading To: Alejandro Vallejo , Jan Beulich References: <20260113122109.62399-1-alejandro.garciavallejo@amd.com> <20260113122109.62399-5-alejandro.garciavallejo@amd.com> <0706617f-fdb8-47c1-94f4-6aa92abd07ec@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO3P123CA0024.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:388::7) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS1PR03MB7967:EE_ X-MS-Office365-Filtering-Correlation-Id: 5f5bd29f-a654-48f7-411d-08de52c361a8 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?eHhKdGFjNUU3YmFJVzJuK1JsNHFTK0VzRThpZDBMbWpISlA5a0Q0MWdiWW5R?= =?utf-8?B?VzVaa2x6NkJpb200anJWYmEvWW56YnpDT0xzN3B2NHhDZEtMKzZnQVR1bEx0?= =?utf-8?B?bXljQ1pKMU1CN004eitOQ0JuTTUwdUJSSG5zWmhJR21SOXFLMnc2WmFwenVk?= =?utf-8?B?eWJId2RrNkxqeVQxbUJFVFExVnp5T1FPd2lZdkFZSDdDbVgyd0JiLzJ5MW9l?= =?utf-8?B?OTNuS3hsdHp6UHVRWkNpS1dSUnNpbUk1VzYycnpGMUh2d0tGMS85eHZ4Y1g0?= =?utf-8?B?Z2Z2TEFCcGFSVFBaa0FJRlBnV2thYUwvTVVXcjhiTmhsSkQwWVNDNldaT0Nv?= =?utf-8?B?MDlkbzV5Y0hwajJ3L1BDdjNtdEFTZnZPY21DOHFWU0xCZ2tYYmpmUnNMVTdW?= =?utf-8?B?czNlcitWSGlpLzB4T3Z3SlpuWDBoWVBENjN4UmFtRGNKVHhYWHhxZnR4eFhH?= =?utf-8?B?NEJFNUFsTTFzQXFmSWhxa1FRcTE4UG5mMWhyakxoRHJ1Z1Z1SmZMKzVPNGNr?= =?utf-8?B?V0J3ZVVLUFlLNFZ5bG5mcHdQRk1uNVB3MW5ibHZHYmVrYkIyUm95M2FVWXJk?= =?utf-8?B?RHpDNmtCRzFrd1FMdWFhK2JraWhaK0dTdkVIWHhXanFlVTZGK2Q1QS9OWWFl?= =?utf-8?B?Qk04eDdYVDdjekMwYnNlL2dIMUZnR2w0ZnFUdHNkakExZmJJWGNOakhPSDZM?= =?utf-8?B?Qkw0SVp1Tm1hN3duTzI3NW5KNW1nVndUUUZqSUF5TGdHQlF0UThnWk1wNGdO?= =?utf-8?B?K2xQYTFvQnllWFZDbi9kc2lTVyt6dEo5dFRRTGFrTGg3NXcxQ1piMW9LYjc5?= =?utf-8?B?Rm16WUEwY3JSRksyOStjU1Y5T0s1Wit4MWhBeXlOZEljZktuNnBPS0F4Nyt0?= =?utf-8?B?YXIwRDNrck5YaHhrc1lZMjFOZDNvVjJxTnVnSU5CaVpmSXdpa25vLzNyU25o?= =?utf-8?B?bW14eHlhMjZNYkhZUXBnUTErMjF6cDZJOXhlU3Q3Y2E1YjgxRXdaOG1ib3Ux?= =?utf-8?B?QnVLZUtFYUpYODRnUjBKeTB0dk9aeHdKRFMyNGlNTlZEa3EwcFRuODcxaFpn?= =?utf-8?B?YWV6bXFURk1INE9uSWErOG9PSU5sQXFON1FVNXV0OXAyMkFDNHRPQ2xFbmhz?= =?utf-8?B?YjRSeWY3aDRKMkNaOE1Yam5zME9WN1BrMmd6dktUMzVNcnJwdkM4TU0wbDJl?= =?utf-8?B?Z2w2NHN5RGhGbjZiMHByMm1EZHdzR2dtZUxVZGc2REE5clpOU2VLbk1BaTFU?= =?utf-8?B?eXV6UkUvdHRHbnJPWENGMUlnV29tZEREZS9rdVpIUUszelhKSTB1MjBGTjQ3?= =?utf-8?B?ekZzdGo2ZE1IdUd6alEwMlBQV2wrWllOWGJHWlNic0YrTEg4TU1GTjh1Q1ZM?= =?utf-8?B?WWs0cXZVN0ZKZUtwSWF5NjR6WDFsVDVDanpSc2xrZnJmaWZuMUVGaVQxM3g1?= =?utf-8?B?SitKRlJnNkUzVlVCaXFUNTFmbFpaUjFlaGZsT0Z1WEJkQ3I1SE5xb1lpeDIv?= =?utf-8?B?VHpNMlUyMUpFZ3MzWktzdEovaVdYL3pEVTFNSmFaWGFqMitYRE5jbXl6RW9a?= =?utf-8?B?LzkzdTJXdkd6aExkMVZyNkh6K1V5RkNGL2NtQ3hZSHZ4VU9yQnNtTWJsVVcy?= =?utf-8?B?T1RYMEZBNkFic09PKzdkaFVqS3MySGY1TXVFNXF5MGVCcWFpTzhkcE9JZlBn?= =?utf-8?B?U0dlQWpOZURhb0tjVHNPZThHbXpkVkE4dVRHaFppVktGU01ZQnl4SDl2Y3Y4?= =?utf-8?B?ZEY2d2ZtaUxFdi8zY05vSGJLeW5Na0FKL0YyWllIREZ4NXF2RFVHcXUzRVZy?= =?utf-8?B?S3JXaVUzMCtJZlFFdk8zeUU1ZHBSckVTSlpybmcwYUFPdU4vaGoyZUFJbTB3?= =?utf-8?B?NGdVR2Z2WVZBSVpsUDBzakwyeGNyenZoVWl5QjJ0SXpPczJDN2liZUVGb09G?= =?utf-8?Q?Q6OVLv3C2y7IE74TQGFUjpeBsdnHoxri?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Z0ZrQ1RoZjZwVTBOMEo0bUxaUGVjYzBKWmZ2YnZ3M2ovdWF3UmJzVUNmUkhQ?= =?utf-8?B?NlR5Q0RucU5MM3ZSbmNUMWFEV3dldnVseHU1VTE3b08wdmt4ZGtjcUtLTWxt?= =?utf-8?B?NUFGZU82VjBjZGNXeExtNHRrWjdoLzJGSHkzTHp2SXBOQ1BTVUc5amlqT1hn?= =?utf-8?B?elJzODg3WnFDY1plVzJPalIwN2pwWlhGU2R0TmJlZkZMdUlzZ3BYY3J5OWx6?= =?utf-8?B?cHpiOTdKR0VXVGNlVmdVOEFXdzB5dEwzSklzRjNlMDM0T1FpSU5CQ3k0QnB4?= =?utf-8?B?T1hyTjhodXFCRHpVZitYdHM1OUFMdi9naG0xZHVtdk1YLy9mc1VBS2lSd3NX?= =?utf-8?B?SFhlVVQyN0FSaTY0MFREMXpKdWJDYSt0eFhoV1pWdWFIY1NiUE55SXA5cmZr?= =?utf-8?B?S2Uvc094Z2k3NFVCRzBmU3drb1FKRmdHbjJUQWxtSGxLUVBTaEFWQnN3a25h?= =?utf-8?B?ZWNySFZnZDZPTnJUdTNNSklqSFZuSVppL3IyTERHSVYrajRaREY1dWhCN0p0?= =?utf-8?B?eVd5TEZGMkhEZHlEdTlOYS9iM2xpZDBidzQ2TWhOZUhib3BLWGVRT1BWOVMv?= =?utf-8?B?a2E2K3d0MXd5REQ5SVRzdEhzTHIzMnVYd1FydllLTWxyMmliRjVDbG5Edy9w?= =?utf-8?B?Nm5kWk92SnBBM2djYXUwRkluYWR5M2VWZDB3S283M203RnhFT0FXRTV4ZG52?= =?utf-8?B?NG5Jbkp6TE1uWU92eHRCYTR5R09XYmxoV2xRZWUwQ2VZVWRiOW5CdzBVK1ds?= =?utf-8?B?L3hXQVlDK25LNE1VaTVHNjJNMVZtbmdHRFNEUVVhUEFoV29lOTg1bktxQmFC?= =?utf-8?B?RnJGUVl0Q2JLc2c0LzZUMHIvVlNCRm4vcjFUQkJtK1I4ajBDQzlWKytxUTUr?= =?utf-8?B?RksraXRNTjBNVlF1bUZlK0VLbXlWSmprV1RwSFcydU9PWEFITjlKV1BBQ2RH?= =?utf-8?B?NzdFSklwU21aMmJEU3dobGlINGRyTTNJQ3F4alV0ZWhXV2wyS1hFM2NBVnVE?= =?utf-8?B?T3FuWTYwc0VTbU83Rm1HRzh6MEVoOG9FQXR1WW9NM2tkUGFxYUlQQWpXMjhX?= =?utf-8?B?ZldDNlpacS9DVktab21wbTZwSXJiSmcybnRuU0RteXkxclZFVkU3S3d2c1gy?= =?utf-8?B?c1pkR1hpQXh3ZmVGcWFxbG41R28yVFZKcjVEWm9QcnV1MTJCejVEdWpDVFR5?= =?utf-8?B?dVZuak4zZS9WNDE4YkN4NWoxRy9weCszM2x2UDJKRjRreHgzS0lJUHgyZnpF?= =?utf-8?B?YjdoZUcyWUVRVnJhWmxvb3krWi8veFE2L0xHSHJoZ3BMNEs5b2MzVXFVQis1?= =?utf-8?B?dUhCN3NLVHlLc0s0NVUvZklBUUNsWWExRStVc2xMNlczeGxOUGlJc3NVUnYr?= =?utf-8?B?VkhFRzdXZFpsZ0RTT0Z4dW5qa0VCU0RPZnNnVVc1TkwvZXdPQ2tCWGNHUjRh?= =?utf-8?B?Z0dpaFZvVk9oMGpjSHM1MnIxWEZVanFod1orTVh1dVQzY1IvU29EeGlPTHNw?= =?utf-8?B?bk9mT0pKNjRjU3RIcXhCYlpwM2doOVBNU0tBb3hsRWhqb21JQ0s1dS9vUVNs?= =?utf-8?B?M3dlQmhtMmpJT3VIbm9FczlxVk5WUC9oRkZoOW02RnNzNmpvWkt0dlRPdVlW?= =?utf-8?B?V2ZWN0srTlozMnBHUmtaMllJbFlQbytsYlNxWWhYdUcvRUd1QW1NNUUva2Vz?= =?utf-8?B?OUZQd0Vrelo4eEdvWE9zWkZ6ZUh2WG5NdWVrVGNUWEpkY2I2eFhMY0JHczdj?= =?utf-8?B?V1NlbU10NGE3NWJUL1hvK1E2aVVnT3d0djRQKzRDZkN5aWJPbjdrWURRWGxC?= =?utf-8?B?enMrdmQra3FOUEZPc3dNVkE2anJaRUpHbml2bzdhWmhmTCtrZHo2V3RhdmdX?= =?utf-8?B?eTFPVjZuYmxsUXNVOHVXa3Rkbm9HRk9vRTFubm41czFjeXdKY20wa1hJbXVX?= =?utf-8?B?Y0pqaG5HaFp4aUZEUUFVbkxWQmpnYnRETk44RTFwTlRBSnpoSkFtakZIaW1q?= =?utf-8?B?K2I2UVdHUUl1VjdFdnlkLzZLNWw4bWtIZldpZWVuVDJUNlgvb0JadTZHa2Ny?= =?utf-8?B?UEVOSVpTVGNsbkI1MXRBSE53UG5UTmU4eXZ5OVM2bEJCb1lJT2dwbHBTSHRB?= =?utf-8?B?bmVVa0hXSVVVQ3hEbHU0ZXNnYkEyYTFlWjhFTVVFUi9Jcm9IV0x4U0lsV0ZC?= =?utf-8?B?L0Y2Z3VKMlJZbTNKVmNPZUYrSXVrK1FnSVZyTGFjMTI0YkZ1UG5hUVlwQjMr?= =?utf-8?B?NDlNbEJrTm1IeVp2VFRPUGVpb2J6QnhIeW83MXlxZmgxdTgzV0x5K1JLS1Fv?= =?utf-8?B?dlJxaThqZWFjU3ZJTVdvVUpFTmp6SUkrYVFSYWEzWGZrYTBpRFd2RTFpbGVT?= =?utf-8?Q?R7SmVOfWMP42oKZA=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5f5bd29f-a654-48f7-411d-08de52c361a8 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 16:47:04.5680 (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: dV6v4He9BSa4rVKqBhJ9peWp8sG8QuhYUdXTQjQZs4F5WZcV0wbA02gICXQKcbXCj/FH2dIzbbdjKBnLkwgG5QSq9aMjHXoZXn+lrrWFV1Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS1PR03MB7967 On 13/01/2026 4:12 pm, Alejandro Vallejo wrote: >>> --- a/xen/arch/x86/cpu/microcode/intel.c >>> +++ b/xen/arch/x86/cpu/microcode/intel.c >>> @@ -408,17 +408,20 @@ static const char __initconst intel_cpio_path[] = >>> "kernel/x86/microcode/GenuineIntel.bin"; >>> >>> static const struct microcode_ops __initconst_cf_clobber intel_ucode_ops = { >>> - .cpu_request_microcode = cpu_request_microcode, >>> + .cpu_request_microcode = MICROCODE_OP(cpu_request_microcode), >>> .collect_cpu_info = collect_cpu_info, >>> - .apply_microcode = apply_microcode, >>> - .compare = intel_compare, >>> - .cpio_path = intel_cpio_path, >>> + .apply_microcode = MICROCODE_OP(apply_microcode), >>> + .compare = MICROCODE_OP(intel_compare), >>> + .cpio_path = MICROCODE_OP(intel_cpio_path), >>> }; >> While I appreciate the intention with MICROCODE_OP(), I'm not really happy >> with function pointer members left in place just for them to be NULL >> everywhere. What if a call site remains unguarded? With PV guests that >> would be a privilege escalation XSA. > I see where you're coming from, but these are already NULL if microcode > loading is not exposed by the underlying hypervisor (if any), or is blocked by > hardware in Intel, so arguably that worry is orthogonal to this. Also because they're cf_clobber, the calls are turned into UDs.  We won't follow a function pointer to 0. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 13 16:50:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 16:50:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202188.1517809 (Exim 4.92) (envelope-from ) id 1vfhbd-0003X7-Eu; Tue, 13 Jan 2026 16:50:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202188.1517809; Tue, 13 Jan 2026 16:50:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfhbd-0003X0-C8; Tue, 13 Jan 2026 16:50:57 +0000 Received: by outflank-mailman (input) for mailman id 1202188; Tue, 13 Jan 2026 16:50: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 1vfhbc-0003Wu-6r for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 16:50:56 +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 0622f84b-f0a0-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 17:50:53 +0100 (CET) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-64c893f3a94so13583a12.0 for ; Tue, 13 Jan 2026 08:50:53 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8701e1d467sm892936566b.70.2026.01.13.08.50.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 08:50:52 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0622f84b-f0a0-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768323053; x=1768927853; 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=weAGDGv5+VXSGDykJWyb+EGUtDTcouQ244mvV/7VgWM=; b=fNRR4Yy8cbWApkJKoUas171I1nhIKeXsmjpctN9PlYusWMTPHZQjlRPB2Rjb7fwoMg rCno3Dka0qb8o9PdsLwE6/EdGSJGGvqeYrvvzmOuYJgqVU1/w3NiX19cdJN/Q+L0Oj5L HAEuaGQB9Ti9sQnJ23DVbk2iqOej8dhQWIqHd7Rg2oQbh0oKVH9S3BZN0tP6JXMO4y5W EIiyRUAzH8lUMJYtJQgt1cwzu/baktS4UnguushVw4G07EtCdS4ky56mk4LzR0ZARQFN l7TAOAlUGVW2A1oN1zD9Iaf53anij9c3iqxHN3oA93+j71a59aaFWs06wYilhVlbtTIz +N9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768323053; x=1768927853; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=weAGDGv5+VXSGDykJWyb+EGUtDTcouQ244mvV/7VgWM=; b=h4KisTweLg9CwgjDmsDN9vL3Gw7YF4BYaNDoFXNFoS8nF4KOg9WPVIcp/Pms+HHbFg 3BlmFomSQxcuvDI9lTInlESFkTOwdY7j9CLRkPvvEBtT4b0zGHmbIlpM17Xn8ktTB4b3 sbc0ku8Yudd3VqFeWMOZQWSqbjHwD7X868cc0Monns5ew3oFUfIOvNTBsF9DmT0FF8KS IT9B5kpXAlGgH8nOJcSx4NIB8ZyJH79ZDAEBEaf1m1m9sLvY9wJxjrV3kx/WMTUKcDzo /Z3WN7dGDo7Ubs1fn9YgpyL863ZWYlMOfh3XPqrRtmDMaeZGK806jLFX3PxzuXrJPwwP AwaQ== X-Forwarded-Encrypted: i=1; AJvYcCX5acElqS6S1bb7rmTPsyk4gvcQVZdbs+Yz9AqxjLesA0YMPwREAHGD3DYOP4BLzO/Oyrj6DNX8Hf4=@lists.xenproject.org X-Gm-Message-State: AOJu0Yyj4pFFdEi24aEwyvJwA9g3BwFmjGpAavm8f/Vf9NcmwSxUA8Gx VR+tDMYlNQvrnm2Whq/NzJ4cV0pRuCvZMVN5lEZu5WHgqtJ8/GawsDKK X-Gm-Gg: AY/fxX5X1nGUkGYuOtEFsjn5QLtZxOopd1M5yyI0jpm//OzmYXlwVzzwrBG0UNF1m6C vuWaFMGs/r1PWvZPSBZy2VS1Tuat6WP4G+H2KfyVpUQHF54xoXm+3deW9v386Ot8xsqbU91sXvo oqjgnFVzMU0tWxFgUaP0RoGoh9AIThZjn2qKiEJbWk4YCuEn7aB8afn60yEaOVbgGIyfu3CBPTC +uVxO6QUS5AwT4YFI121A/SgoBwRbd8aFqHhfFGoTiXGNCaI227GuUcrIvw6sIY8UH7a8NZVBhu U0tdb+BCj7eP1rvoH5/V25+G1Z4j76k1bC40sNHFbC1KEr9BM0hW2oKM1THy9+rn+R/aaTMYWDh oC7vPicWs22ub22ksGwKDYovGPs8ZY4Mq8jRuVMMoInvBzA3aYzxr6FkBfFP+gfJwW9mYgyThH0 ZophHLBpCRmRrlmXdZ8bQ9fwJjWDE/kNXghETD1b3mbISOwkPHtF83+f06wFAODOY= X-Google-Smtp-Source: AGHT+IFbwkgx3lCWSWgMDEd5BdC/lpD0EA5nwVaggRQs/Vprry7RjOtdoFiWhbFNHAj+dXnQ0qbmkg== X-Received: by 2002:a17:907:3f24:b0:b87:191f:4fab with SMTP id a640c23a62f3a-b873598d8d2mr324205766b.26.1768323052965; Tue, 13 Jan 2026 08:50:52 -0800 (PST) Message-ID: <90e7fc60-09cc-4b61-ab0a-80037f8ecaf8@gmail.com> Date: Tue, 13 Jan 2026 17:50:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 13/15] xen/riscv: implement reprogram_timer() using SBI 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: <43249171def325c49541ebdac141fe99d159b60f.1766595589.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/12/26 4:24 PM, Jan Beulich wrote: > On 24.12.2025 18:03, Oleksii Kurochko wrote: >> @@ -39,6 +43,33 @@ static void __init preinit_dt_xen_time(void) >> cpu_khz = rate / 1000; >> } >> >> +int reprogram_timer(s_time_t timeout) >> +{ >> + uint64_t deadline, now; >> + int rc; >> + >> + if ( timeout == 0 ) >> + { >> + /* Disable timers */ >> + csr_clear(CSR_SIE, BIT(IRQ_S_TIMER, UL)); >> + >> + return 1; >> + } >> + >> + deadline = ns_to_ticks(timeout) + boot_clock_cycles; >> + now = get_cycles(); >> + if ( deadline <= now ) >> + return 0; >> + >> + /* Enable timer */ >> + csr_set(CSR_SIE, BIT(IRQ_S_TIMER, UL)); > Still learning RISC-V, so question for my understanding: Even if the timeout > is short enough to expire before the one SIE bit will be set, the interrupt > will still occur (effectively immediately)? (Else the bit may need setting > first.) The interrupt will become pending first (when mtime >= mtimecmp or mtime >= CSR_STIMECMP in case of SSTC) and then fire immediately once |SIE.STIE |(and global|SIE|) are enabled. > >> + if ( (rc = sbi_set_timer(deadline)) ) >> + panic("%s: timer wasn't set because: %d\n", __func__, rc); > Hmm, if this function ends up being used from any guest accessible path (e.g. > a hypercall), such panic()-ing better shouldn't be there. I don't have such use cases now and I don't expect that guest should use this function. > >> + return 1; >> +} > Finally, before we get yet another instance of this de-fact boolean function: > Wouldn't we better globally switch it to be properly "bool" first? We could do that, I will prepare a separate patch in the next version of this patch series. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Jan 13 16:53:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 16:53:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202198.1517819 (Exim 4.92) (envelope-from ) id 1vfhdv-00043e-QC; Tue, 13 Jan 2026 16:53:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202198.1517819; Tue, 13 Jan 2026 16:53: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 1vfhdv-00043X-NE; Tue, 13 Jan 2026 16:53:19 +0000 Received: by outflank-mailman (input) for mailman id 1202198; Tue, 13 Jan 2026 16:53: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 1vfhdt-00043K-Td for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 16:53:17 +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 55db249f-f0a0-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 17:53:07 +0100 (CET) Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-64baaa754c6so11309366a12.3 for ; Tue, 13 Jan 2026 08:53:07 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b871e383217sm562886366b.71.2026.01.13.08.53.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 08:53:06 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 55db249f-f0a0-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768323187; x=1768927987; 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=quR6N57RKz+5wdEK9dYC/7627WTrMtYCBE5SL1cVH24=; b=m9Br7jjYadDQ3hM20Pt7xjdC9nLmuIH4d5sHF+L7aPHtPGqZvx0XGrZ1EAV9tWGfZ6 7KNqFf/dnTCYswsBFeu59ewsN5ulQ3AQYmzSCSa7h9wxFwGfPYX3n4QFhDMh6LxMUdhu PXCC82GuVHjHqNJ7CaJHHsWMwoCYDYW5zbBFqsPS8qG2QnXTG1Ag6bqrKmqv6Q+ymYSE Kamgl2QcC/LnyyjBGOFvw12wzsGsOHJyO80dVHPV8t3S21IZBSXHSf9A2oBSJO5LHk8c zXPJ2WO2zVoVIZJFNUV90CrlnA2kZjREIs9S7YXsPLKpc8jDPvYnIn/6eSY6JmqphjGI 3hrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768323187; x=1768927987; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=quR6N57RKz+5wdEK9dYC/7627WTrMtYCBE5SL1cVH24=; b=wPcexVVHDMDg3tHOso7yvT7GEZXehoQ/OpUqJT+k3p9O80UGzWQeO95upv1hhsNq2P B7DmQbRwJ5nIFqeTPbHjxnrLtvOjW7OpFKOrVtgD+PG+xHWIj+8Ok8ecdrXho1D4dCTX EAEBjmTwIgPABP2s91pwI4bQCXxfm6XkyIc2dR890QGEAt9Jj3cBmc7BsQpjO3tJHalj GUiIVe9XIYYhEhYyniMuU863Zexmun/9b2v49TVI9zSM4Rxr3mqJ1GR0IuRYTjltFd8P l+pjO3VDA1XzOLzoWW2MOU7l0++LLfz0fiywZGDT3QqFF6uh/S7OYdxn8CgX6+EPD/Ea hE6w== X-Forwarded-Encrypted: i=1; AJvYcCWfl8GKzixw/wTKLOT0DMzsKTJlxWgMdYva5RA95zP9t57C7XeWi4MEoIdM1Y5Z3LhmQeyZrKyOToY=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx3thzaaWeKd6EtHdF405pXcfy2lVLetGFHc+UvJP9C2Nb2Q36N H0t66NPvmb9ftq0WxWmyQAsj/arxnMBZH5/eKYSxDvBzw7JYWu8ce2aU X-Gm-Gg: AY/fxX4FusKnpd3WviXkWpRYwuNWQzuVEdWoaP4iKXIqv7p7Ji7DeD+QGPHsZMWlII9 VYL8c9NyB4VXWic7iCJrNH6ks8ZpHxf9oX7aMWfkoELMJ+oPqCSzJKOZ5oWZCycydDw/afsaQy7 1khfIAFmeec5B83OP9q5JJZ5q6KMrMrbNMjYoePYRw4FZJPqnimQHnD8uY1SAN71bLTWJAPqq1P +RyuDbFmCt6ss5KMcBZgtXfeB6HddQnjYJ4A2oABKuvpjETwTVHhHFJvHo2/lUoAgdLJdbipP1X Jn6sKnWA+kupM+ReXXN7TfsyJRlEToYOS/a/wK4c8/bCnwsERfQIRlExqpE98rkKKCT3BvnCNce UqakiGDg9Pce9Ylnh+DKy/W1xYhP6SHL61kOFMGYjczCyfbmt0mpNOGSGPkxzKMPgKUQCpfV2ZY QPN2/BqaNMxRFFAtqaT7Bk63TQJYw5k7bpgpvJNyhdXLRXS0ZGRyGHhWWpTeZGh7e8iHsBk6spi A== X-Google-Smtp-Source: AGHT+IHuWjVoL7E1svo16dpvYexcmqlADS/kdgWQsDmPmGyT52fboynC+8J2+zVwxSmqZ5Ga2XwSRg== X-Received: by 2002:a17:907:780b:b0:b87:1fe8:9534 with SMTP id a640c23a62f3a-b871fe8af72mr429814766b.48.1768323186762; Tue, 13 Jan 2026 08:53:06 -0800 (PST) Message-ID: Date: Tue, 13 Jan 2026 17:53:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 14/15] xen/riscv: handle hypervisor timer interrupts To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/12/26 5:15 PM, Jan Beulich wrote: > On 24.12.2025 18:03, Oleksii Kurochko wrote: >> @@ -108,6 +109,15 @@ static void do_unexpected_trap(const struct cpu_user_regs *regs) >> die(); >> } >> >> +static void timer_interrupt(unsigned long cause) >> +{ >> + /* Disable the timer to avoid more interrupts */ >> + csr_clear(CSR_SIE, BIT(IRQ_S_TIMER, UL)); >> + >> + /* Signal the generic timer code to do its work */ >> + raise_softirq(TIMER_SOFTIRQ); >> +} > Why is "cause" being passed when it's not used? Good point. No any sense in it. Even more I think the cause is pretty known in such handler, it should be definitely = IRQ_S_TIMER. I will drop an argument for timer_interrupt(). Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Jan 13 17:00:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 17:00:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202212.1517829 (Exim 4.92) (envelope-from ) id 1vfhkS-0005WO-FA; Tue, 13 Jan 2026 17:00:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202212.1517829; Tue, 13 Jan 2026 17:00:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfhkS-0005Vw-B5; Tue, 13 Jan 2026 17:00:04 +0000 Received: by outflank-mailman (input) for mailman id 1202212; Tue, 13 Jan 2026 17:00: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 1vfhkQ-000519-Da for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 17:00: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 4c338afc-f0a1-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 18:00:00 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-477ba2c1ca2so85473955e9.2 for ; Tue, 13 Jan 2026 09:00:00 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5df8besm43390698f8f.26.2026.01.13.08.59.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 09:00:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4c338afc-f0a1-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768323600; x=1768928400; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=2RqQ7cKiStLcs+aeLKCBkbXvKCLE+Bjd/KLqxO6j+OU=; b=dgqFxfmYjqEBhhX3FCIwX+xW4ASKtyXI+6vSGa4EMKqjaspHI7iK8xt9rymzXBqO0X fzmH7JxHkvoBpKLfpwSLLz6mMmecOXXegD0a41w560YDpMxwuLLGUnxmenDdNAi1GgLY PuZoZapxcEHqcpuix3+Be872pdl5ATKt0rxgM74jGcsK/ldBWdH6C+8JliaLcl+zUJce tx/ckZqgRvLY3yggLGLaW1a7vtga6yIoXf//Hg3Xvn9hZzHGGmy+oiVchmCtOC2SJYRT FD9trYe03hG47dNjPfc7Aco30ZAPU42zy/0+HEsAEwS3YNCx9B6VuQlI3qYoztEfDIZ4 bD4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768323600; x=1768928400; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2RqQ7cKiStLcs+aeLKCBkbXvKCLE+Bjd/KLqxO6j+OU=; b=At+WqGll6xY6W4PMxikb1OHdrLd6iEi4u2VB7I+5B/7qzYnT7iRz9OwJNHQt2+ydbK h3muZfE+OFazIm+kfzxwukjT97jnfeO2yxfsIwGyJnjjnHx0mVw89q0Vs2EmLDmqcgR7 puGHij6wpDOhbXnprCAvAwe8mnzcSFl+3lFP78r2grnzdowy0XP4qLSDphCyKynRi4pK 7tWluolEx87bzP7s9IxuWuie42NIyFtY3ndTgy5EIadYu30ayE2XIFES0rzQLxjuGytz AfW2RLLGFUAGUhsjRidICCg5Pg1kH7FKb+JB76ALCgB9UPDFxg6PZenOlsjcUemN2ZpV 8s7w== X-Forwarded-Encrypted: i=1; AJvYcCX4dXe2sGqQSOXbF6UhnJARt9enAld9kWgtmdEkELYWAzSydGnenbODbxA7un9W+BznCyjmYn9f0Yo=@lists.xenproject.org X-Gm-Message-State: AOJu0YzMUsTSLL5ExBqo/UV2BA7hHmMiyYsKuSkTC0jn1tF5BihX6wew lVOD+FbPSU2Tee1E48nMARDZRkFgo7H4sFbHn8EIx2F6Tx/javvLPF0zfYGG7B5YlQ== X-Gm-Gg: AY/fxX7/d5ec8dJo+fLkPj0BOsFJk99fW3e6GdC+Lo+gJ0KFrjO2n4/ueYuUk5M8CSw DkZchC0zHA2W8+pulzaYMLcprIhbWGUBF+Gi75Z+uhEy3WxFLiz/AAwhjt/FbcRBvmY0jBWLAKN kyx06/VtZ4Wzx223+RM8Wo1dXk1zhDTI/pcTzvxoG0Jk30n/qFRA+hVMfM5KEgHRNypAXBy4v7Z 7Jmzqf+q34wrI/NuxpYVHVdsfWhWFssUkhrAQfal12BXucu5b8EymrTLnRA2gUN4tmlvB2tjWr8 4bcwPJ47/OO1qvVfcHOd2DXiJbiKeNH3v9i9oltCR8kGVTiFQwMQGRQ3KrWO9wLCjX+Mv7AvJ4G m0pOaB9lygjMQdUGylQQfGT1T1wJCp4pbE756tWrYzb0QsK7OMw8JMRr4de2YWT352LkRGeo/pW WJqizmK4IPxlAe/16aVsDdpYamL22k5ETnZb+C92KV+rLdvNJKg1A+hp4eFOvGKso0AV461M2Ba 7A= X-Google-Smtp-Source: AGHT+IGcH3+fYccOertXuX65iRdqrZJYxUV0OqOSY8DKdCV3jL0ELApYOyi4dMJ92HcsDMQLRO9UQQ== X-Received: by 2002:a05:600c:4e8a:b0:479:1b0f:dfff with SMTP id 5b1f17b1804b1-47d84b170famr294544805e9.10.1768323600285; Tue, 13 Jan 2026 09:00:00 -0800 (PST) Message-ID: <7083266d-6bac-4a8f-96e0-f695c17b1cd7@suse.com> Date: Tue, 13 Jan 2026 18:00:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 4/4] x86/ucode: Add Kconfig option to remove microcode loading To: Andrew Cooper , Alejandro Vallejo Cc: Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , xen-devel@lists.xenproject.org References: <20260113122109.62399-1-alejandro.garciavallejo@amd.com> <20260113122109.62399-5-alejandro.garciavallejo@amd.com> <0706617f-fdb8-47c1-94f4-6aa92abd07ec@suse.com> <1dab1120-d947-4e5e-bf9d-0dfa5ec35bb0@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: <1dab1120-d947-4e5e-bf9d-0dfa5ec35bb0@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 13.01.2026 17:47, Andrew Cooper wrote: > On 13/01/2026 4:12 pm, Alejandro Vallejo wrote: >>>> --- a/xen/arch/x86/cpu/microcode/intel.c >>>> +++ b/xen/arch/x86/cpu/microcode/intel.c >>>> @@ -408,17 +408,20 @@ static const char __initconst intel_cpio_path[] = >>>> "kernel/x86/microcode/GenuineIntel.bin"; >>>> >>>> static const struct microcode_ops __initconst_cf_clobber intel_ucode_ops = { >>>> - .cpu_request_microcode = cpu_request_microcode, >>>> + .cpu_request_microcode = MICROCODE_OP(cpu_request_microcode), >>>> .collect_cpu_info = collect_cpu_info, >>>> - .apply_microcode = apply_microcode, >>>> - .compare = intel_compare, >>>> - .cpio_path = intel_cpio_path, >>>> + .apply_microcode = MICROCODE_OP(apply_microcode), >>>> + .compare = MICROCODE_OP(intel_compare), >>>> + .cpio_path = MICROCODE_OP(intel_cpio_path), >>>> }; >>> While I appreciate the intention with MICROCODE_OP(), I'm not really happy >>> with function pointer members left in place just for them to be NULL >>> everywhere. What if a call site remains unguarded? With PV guests that >>> would be a privilege escalation XSA. >> I see where you're coming from, but these are already NULL if microcode >> loading is not exposed by the underlying hypervisor (if any), or is blocked by >> hardware in Intel, so arguably that worry is orthogonal to this. > > Also because they're cf_clobber, the calls are turned into UDs.  We > won't follow a function pointer to 0. Hmm, yes, the alternative patching will guarantee that. That hasn't got anything to do with cf_clobber though, I don't think. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 13 17:03:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 17:03:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202228.1517838 (Exim 4.92) (envelope-from ) id 1vfhoC-0006SB-0i; Tue, 13 Jan 2026 17:03:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202228.1517838; Tue, 13 Jan 2026 17: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 1vfhoB-0006S4-Tj; Tue, 13 Jan 2026 17:03:55 +0000 Received: by outflank-mailman (input) for mailman id 1202228; Tue, 13 Jan 2026 17:03:55 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfhoB-0006Ry-EF for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 17:03:55 +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 d6bddc12-f0a1-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 18:03:53 +0100 (CET) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-64c893f3a94so39438a12.0 for ; Tue, 13 Jan 2026 09:03:53 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a4cfe76sm2244644666b.40.2026.01.13.09.03.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 09:03:52 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d6bddc12-f0a1-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768323833; x=1768928633; 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=KebyABBjQbUhJvo+2ln2Z51K2TrX4MToP3GOAoNDiqg=; b=DACkUcR0EFAgLlH0oXKTG4MwD57ej6e/4tSxW8/sDw4wcZSIu2sg8EQvvAbsfwo8lj HlKGv48BOmsMgcf/SteMyar3Ym8eEEUAWrv5hZsMxwbYlWozt0kKUfj4l40gohSOT0nR l0bq/viOQUBNzIyBA6BW4OBiiC19a5eQ+Q6ZTT5TYjhDQYVCpJXx4XoQA+SdKm5HdTzO NOQ1HFC8vcLqHpBL74xYEKGswWl+tE1tcEb5zy87vwci/wkj/y4zCjSBpjHBTE1cwmvX GmG7rFd+edmXry01fG4FKcbbYddh7OwMecf8MfAo7vYRSz0pWdwjj9lc17dsEpbvTphk Ibkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768323833; x=1768928633; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KebyABBjQbUhJvo+2ln2Z51K2TrX4MToP3GOAoNDiqg=; b=kLFPdI3PvebTWxKbSE/xw2fU3dhf9NPTZIcbkKLDIoAcAvPoWHeW86jwx4rdcfkLyt Xl83Nkhwj5zbLpFKs0cf8vkHLOfZHyNAJX+7b/AKG/qjKr2IsIyvDfXfQAwOcdD4BHRQ PlBi4KZOw8gCe/IcNYtKCZD3lAm1Y+rZOMoR8rSuWpLORnrQ1WGc50CVixrDN3XQKmtD XzzvPV1+ecrP2IBCXRVqhu7rkpGeHQ+G3Na3CH0WCCXA2nsEcNvs4fyEtezxmMdp7raB LK6NCtwHHNcz8ZbvB+NVBDM+r4URPAs/ZHaXg/FFXquffnf5BK8PD+VAUt0tVlfWobih 4lPA== X-Forwarded-Encrypted: i=1; AJvYcCVzLfFp1lfZXPmmVIX8Npbu7z/7ZVweyA0cZtz42qh7+KLGAaXfqMyXIUSkgGJfGn1mV5OsfyI9etY=@lists.xenproject.org X-Gm-Message-State: AOJu0YzqtMgZ/vZgaN+VuNqdzHghwLXe/cQ97Fr3HXXqeCGVnKWkfpql BIT0GFGryOLgXs8XjFTfKrLW8kOgquZWw2AIV0uGJ9paRcS8bwgdf0qM X-Gm-Gg: AY/fxX5RDJFuqc/G0rM0YXce9wGk1ZbWRKiQQdJPH4dFYI6F2bdfcjM/9LG5jKS+YJX 8eBLfUBnnnoBP6xBb0SQKSJIn/5Vz05CasQ3lUE/0UdSU7BLZ583wkkPLGvPA/IUfpaVczW7g2E lXSqxT+tL5Of5emARPuNgyElvwAYN88Bm1JCdX0QMqBFjbWc36qCc1styH6qnRo0OypUsQiiZPG 0rlAKy6hTjuDrygB/549UdbYtXtxBSGSqVtmLlOIhVJG83IzDExc4Oh3HDxBsKDYb6sCLW3S0t8 BogKnza7CJPKG/hlalTkuZlI6p38gMmnXiHH/OPJvjR912gm0CuvNGL9ElKSRiLA2xAndZGkiVR VtnpRMAm/tcSxysGIBBJvH0wemA9L0hMBthNe/duz9B3W42Ys6iUOfRMAALpr4G9OzkVBz2Drp8 p9bvxMMHDm+PIWTRPj0sRomNXVrBvo+KhdMY/KLHbHhwEm7oeAyMxoLbwNqK8rPLg= X-Received: by 2002:a17:907:3f20:b0:b7f:fa5d:53d with SMTP id a640c23a62f3a-b8735ad63aamr306076666b.30.1768323832426; Tue, 13 Jan 2026 09:03:52 -0800 (PST) Message-ID: <7511b588-8699-49a9-99d0-0cb94f0fac76@gmail.com> Date: Tue, 13 Jan 2026 18:03:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 15/15] xen/riscv: init tasklet subsystem 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: <7fd154cda45466ca4bd425bc05d191caccc7d96d.1766595589.git.oleksii.kurochko@gmail.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 1/12/26 5:20 PM, Jan Beulich wrote: > On 24.12.2025 18:03, Oleksii Kurochko wrote: >> As the tasklet subsystem is now initialized, it is necessary to implement >> sync_local_execstate(), since it is invoked when something calls >> tasklet_softirq_action(), which is registered in tasklet_subsys_init(). >> >> After introducing sync_local_execstate(), the following linker issue occurs: >> riscv64-linux-gnu-ld: prelink.o: in function `bitmap_and': >> /build/xen/./include/xen/bitmap.h:147: undefined reference to >> `sync_vcpu_execstate' >> riscv64-linux-gnu-ld: ./.xen-syms.0: hidden symbol >> `sync_vcpu_execstate' isn't defined >> riscv64-linux-gnu-ld: final link failed: bad value > How that when ... > >> --- a/xen/arch/riscv/stubs.c >> +++ b/xen/arch/riscv/stubs.c >> @@ -91,16 +91,6 @@ void continue_running(struct vcpu *same) >> BUG_ON("unimplemented"); >> } >> >> -void sync_local_execstate(void) >> -{ >> - BUG_ON("unimplemented"); >> -} >> - >> -void sync_vcpu_execstate(struct vcpu *v) >> -{ >> - BUG_ON("unimplemented"); >> -} > ... there was a (stub) implementation? (The code changes look okay, it's just > that I can't make sense of that part of the description.) I haven’t investigated this further. I wanted to look into it now, but I can’t reproduce the issue anymore. I reverted|sync_vcpu_execstate()| to a stub and no longer see the problem. I will move the introduction of|sync_vcpu_execstate()|. It doesn’t seem to be really needed at the moment, but since it is already introduced and there are no specific comments against it, I think it can be added as a separate patch in this series. Thanks. ~ Olesii From xen-devel-bounces@lists.xenproject.org Tue Jan 13 17:04:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 17:04:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202229.1517849 (Exim 4.92) (envelope-from ) id 1vfhoH-0006h3-7k; Tue, 13 Jan 2026 17:04:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202229.1517849; Tue, 13 Jan 2026 17:04: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 1vfhoH-0006gu-3g; Tue, 13 Jan 2026 17:04:01 +0000 Received: by outflank-mailman (input) for mailman id 1202229; Tue, 13 Jan 2026 17:03: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 1vfhoF-0006QQ-Pa for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 17:03:59 +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 da03c57b-f0a1-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 18:03:58 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-47ed9b04365so6872945e9.0 for ; Tue, 13 Jan 2026 09:03:58 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f68f69dsm411421175e9.1.2026.01.13.09.03.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 09:03:57 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: da03c57b-f0a1-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768323838; x=1768928638; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=zLM1ROU9knuDPN1FMDY7x1s6BCM3gJz8FviC93uuB6Q=; b=ONinaUCZWCcv0cjF8uzlldIkY2RXGo9DkAyS0E2GC1XZ74hEUVaftozZ8f5IFZuENU zzX9+GOt1zG4hElf4F0qPyjMjiUPXUk7ulvyDF8i/1pp0+gtBtHbckZK/GhccZymFJvM u9KTDBrA5id2+kGvGrE9I6X/g0aPV19RUHCtOunOEnaaNSgYvpblfYZ2EsdHVXxwmJye WMLDKLX4ngdTuH4NxXvpk/EC6J2egH5HG6uHxQ/rCDvmzVzR6rUxVs6bHRPrAiJSY1++ Venz06XYzD78qvfsG+KAoWgvE5XTXs7jqjSsOZ08bGgpGAuooTzCK2cAH4+xg+wE+G1d xkIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768323838; x=1768928638; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=zLM1ROU9knuDPN1FMDY7x1s6BCM3gJz8FviC93uuB6Q=; b=D4KcKgR7LW/tNnQC1Ugg/0ujDHNwLIibWve1524UlR9xPNkyJVRl+IpjSJ+1XHBJTK OYoqtwk6AeAl70HjqHGmxzTl4J1TqqfU0WNE1YvtbwZ2lGd+5APKRA7SC27BUXzlm4g6 sNv8J7MDob3pS6YqktymCY1OgAKGZkh5jJEoRCyER7w3mfsqRwEQrawCNDuIw9y+IXEj jYf0WcLWnmWbpcLfGYfys6qCcg8M5AUAOV4OvD0l3VH9frWY/9iuaXogGzuOi5ckkOyd jbSicpZtwq6+2xpk023E9m+k0fMjXIQ6hLkesmaWZe3XPd04RaHQQFTG75DPoLP2wCvW sTvg== X-Forwarded-Encrypted: i=1; AJvYcCX0Qwcywbf3PQsqfmRMltkO0DuWM3p/KEL0PS/trx4UTS0pfnXHoCuAQ+42sPOu7ByPWhmFKzOlTDw=@lists.xenproject.org X-Gm-Message-State: AOJu0YyS4zVzlU4cIhkCIjlpYUS0SnCm+d67i3oghvkh7n/trSMF1zKl FAJVpIO/dkgwVNW5XYPqm9l3xKz03GB75UjjsGjmQkZZft3oukEhrNBjw7gdED2Nwg== X-Gm-Gg: AY/fxX6MhNlcbLIDAZ4I7MnUM6/KiaA0fJ8NbwlAu7qBjn6xMrPqOZsL8pwjjVxO4LQ MVAnFZ9sdYOAJb/W4eSfpE93vuq7vlN9BEiHny2dCI7PzrXNCcqaWwD6CSmCGeMDNnY3oOd+S8j WuUWWwlmgTeO+yZ4UQP3+txcJr5gMmh2tNeOgiJBgm30RLZ8+4DiV4ZbLcm3E19xCzfXB2+b8KO 2p5TxSSgjSAtjqSPnYaVT+13QQPpa+ovrug9Z+/pBTIA0E9S7e+3+k9I7Coq3uYacGimKC6ZSNI ES1+ecZPUdqNRnYhm05zNdvyOWIhHYR5stNwzSRop4FTn1pY9q8VJqt3+osZFas9Nl8yUqrXARO L3qLfuc+t91mrugVgrdrcUh6w3ZMGVlhupRu5EANEpnJCfrjJFmXUImdeMr9AvENw2l0k/nPfgq nfRTsyE3JnBkzI2lRODAB7TenVFrXvjqtu7Uj9JF6woshY/GrMAW8Qh5VUVVuJC/aXun9PwRSq6 QY= X-Google-Smtp-Source: AGHT+IFknbWApso6ojWx/OEso85mLW78fbPqadbrL/xymn7ASp9M+y6EE5vjXn+piZsBzojlcSk6BQ== X-Received: by 2002:a05:600c:3b27:b0:477:429b:3b93 with SMTP id 5b1f17b1804b1-47d8fc55375mr169262275e9.18.1768323838106; Tue, 13 Jan 2026 09:03:58 -0800 (PST) Message-ID: <8b67ed04-28c0-4c0a-97cc-f2ad56cfdf9d@suse.com> Date: Tue, 13 Jan 2026 18:03:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 4/4] x86/ucode: Add Kconfig option to remove microcode loading To: Alejandro Vallejo Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , xen-devel@lists.xenproject.org References: <20260113122109.62399-1-alejandro.garciavallejo@amd.com> <20260113122109.62399-5-alejandro.garciavallejo@amd.com> <0706617f-fdb8-47c1-94f4-6aa92abd07ec@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 13.01.2026 17:12, Alejandro Vallejo wrote: > On Tue Jan 13, 2026 at 4:27 PM CET, Jan Beulich wrote: >> On 13.01.2026 13:21, Alejandro Vallejo wrote: >>> @@ -469,7 +471,7 @@ struct ucode_buf { >>> char buffer[]; >>> }; >>> >>> -static long cf_check ucode_update_hcall_cont(void *data) >>> +static long cf_check __maybe_unused ucode_update_hcall_cont(void *data) >>> { >>> struct microcode_patch *patch = NULL; >>> int ret, result; >> >> Why this change when ... >> >>> @@ -613,6 +615,7 @@ static long cf_check ucode_update_hcall_cont(void *data) >>> return ret; >>> } >>> >>> +#ifdef CONFIG_MICROCODE_LOADING >> >> ... this can simply be moved up accordingly? After all ... >> >>> int ucode_update_hcall(XEN_GUEST_HANDLE(const_void) buf, >>> unsigned long len, unsigned int flags) >>> { >>> @@ -645,6 +648,7 @@ int ucode_update_hcall(XEN_GUEST_HANDLE(const_void) buf, >>> */ >>> return continue_hypercall_on_cpu(0, ucode_update_hcall_cont, buffer); >> >> ... this is the only user of that other function. > > To minimise the scope of the ifdef. It's hard to know where things start/end > when they cover several functions. This way it's (imo) clearer. > > I don't mind much though. > >> >>> --- a/xen/arch/x86/cpu/microcode/intel.c >>> +++ b/xen/arch/x86/cpu/microcode/intel.c >>> @@ -408,17 +408,20 @@ static const char __initconst intel_cpio_path[] = >>> "kernel/x86/microcode/GenuineIntel.bin"; >>> >>> static const struct microcode_ops __initconst_cf_clobber intel_ucode_ops = { >>> - .cpu_request_microcode = cpu_request_microcode, >>> + .cpu_request_microcode = MICROCODE_OP(cpu_request_microcode), >>> .collect_cpu_info = collect_cpu_info, >>> - .apply_microcode = apply_microcode, >>> - .compare = intel_compare, >>> - .cpio_path = intel_cpio_path, >>> + .apply_microcode = MICROCODE_OP(apply_microcode), >>> + .compare = MICROCODE_OP(intel_compare), >>> + .cpio_path = MICROCODE_OP(intel_cpio_path), >>> }; >> >> While I appreciate the intention with MICROCODE_OP(), I'm not really happy >> with function pointer members left in place just for them to be NULL >> everywhere. What if a call site remains unguarded? With PV guests that >> would be a privilege escalation XSA. > > I see where you're coming from, but these are already NULL if microcode > loading is not exposed by the underlying hypervisor (if any), or is blocked by > hardware in Intel, so arguably that worry is orthogonal to this. Yes and no. Paths taken differ between what we have now and what we will have when your work has gone in. > Also, only a privileged domain can perform late microcode loading, so the XSM > check would prevent any such XSA from coming to pass. dom0 crashing the system > on a bad hypercall (while wrong) would just be unfortunate, not a security > issue, as far as I can tell. Okay, together with Andrew's response it wouldn't be calls through NULL, so perhaps indeed not an XSA. The hypercall being Dom0-only I am, however, less convinced would necessarily matter here. We interact with remote CPUs, after all, and hence having one which happens to run a PV DomU call through NULL would still be in need of an XSA. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 13 18:41:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 18:41:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202296.1517906 (Exim 4.92) (envelope-from ) id 1vfjKA-0002wU-CT; Tue, 13 Jan 2026 18:41:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202296.1517906; Tue, 13 Jan 2026 18: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 1vfjKA-0002wN-9X; Tue, 13 Jan 2026 18:41:02 +0000 Received: by outflank-mailman (input) for mailman id 1202296; Tue, 13 Jan 2026 18: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 1vfjK9-0002wH-7O for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 18:41:01 +0000 Received: from DM1PR04CU001.outbound.protection.outlook.com (mail-centralusazlp170100005.outbound.protection.outlook.com [2a01:111:f403:c111::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 672e0b3a-f0af-11f0-b15e-2bf370ae4941; Tue, 13 Jan 2026 19:40:59 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by CH4PR03MB7649.namprd03.prod.outlook.com (2603:10b6:610:23f::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Tue, 13 Jan 2026 18:40:56 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9499.005; Tue, 13 Jan 2026 18:40: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: 672e0b3a-f0af-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rkz7pMsmkDSEal90D29QnCK0znwB3hOUXzPdx8Dxr5hPlPkptrt3KPUvWHQEKX12GKAIMAfY1ylw2VuNiUQA7JtRqU3qnIw2/OXvC5yd6YpsSPrNRL5+AwfhQDn6MA5GPonBzbKGpq1fLVwXNJH+sYLggMEKcoF/K5A27mOmMGFguUuQFugdvJZCcoNu1LdB+CpvDlgzEL1irOK5AufPtCE3j0dgtOn3Losri5+mZ9ty+/7jRnFjQlgH49TvaAPsZzvRiqT6N03zbQcFwE8GW+V0dSArN71UHEEoBP5ZI72lK698x4XA0JcyUSRyT/Ei48oyrGnALXjoMJHKbf7diA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bvmvAcuzt7ZHT14NUqgLWQpOs0IhFoOyX6G+ZVUh7T8=; b=fJYIFM8sMxeXGZ5o866oJz20p4Aq5cPGGu5fufXAHuJZ59gykprAhwG2KmDIZY9ePk16ShNMfRjJdsxYtl5iklruN5UAeUN6iGCIoVgrg8ttrSpaInSGU9+XT3dT/EWByuRt4taJv8s2EGzRPbJDgmLzGEfRlsxtnl1HrzGhzXgeo58+cNVcErYy3T79+XAkmslprDO4nIJQ/aTJj//cVEtEm/4gcyNf6OZRPswWu+rCU12vL4kKw+4R/KZ7f7fG9ROy1xuKXW57Wlp2umxq3fv3o6BRheCaG9SIs5BwSppGpW65L5SaYtHs9EtG/N84iHzmnhm2tZ2cq8ZQwLnrUw== 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=bvmvAcuzt7ZHT14NUqgLWQpOs0IhFoOyX6G+ZVUh7T8=; b=z8M2mkUflwgvcUEWzh/OgtfbgzbrOopWpspLvM7lDw2DKHfPy8X5EU9iM5nkRXbAtDUkjtFWeU4xabw2VHbTkeqKjfNQq/IEZXLTwqhWlAZG8+FEr0aKpbrK0/ztWJa7+4V78EWpU7h4zMu4B2xwrR5PvmjrGB7FZq3rCRQtD8E= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Tue, 13 Jan 2026 19:40:52 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH 2/5] x86/time: scale_delta() can be static Message-ID: References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: PR1P264CA0163.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:347::13) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|CH4PR03MB7649:EE_ X-MS-Office365-Filtering-Correlation-Id: 84faf625-efc1-4e4f-1bbb-08de52d349bc 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?bGUyR0hhcVcwMERlZ0pLOUNGbi92RGpYQnlabGpZVUlhNEVOS09yL3JUdXNC?= =?utf-8?B?Wk1ER0Z4cWxBcGdKQmsvN3FmbmRsbG56bFMwVkwwT3RhS3NPSDJNRWJFb0VI?= =?utf-8?B?Wk44WTZMc3NRR0FwbGNSYm1wdXJJQlZtRnpaYTFHM1V3MEZLelJQQ3RBdnI3?= =?utf-8?B?QXlQUnhoTis0eTlTMVBpS3BDTWE2TURMT2lvY2Yva2dscVd0VDZGblgxYXp5?= =?utf-8?B?SG1nMmoxaGMvOUVXSTVuVDlNZVl4QU5QQUNadUYvTzZvV3lpdkFvWnB4bDkr?= =?utf-8?B?RU92WWpBdS82bk1LR2ZGOFFKWU5hMUZKd2FHZWxHTG16amZoRmRhc3EvNEVs?= =?utf-8?B?SVVVblVmTzAwWlJ6RERpUFpqejk1SDdDazZtWEZrOFdCZG5VR09XL25sUXlU?= =?utf-8?B?dmxYaTlhRWZENXh4ODBkcEFxcFdkZnRGZURGU3FnVituenZtNjhzVzd6WnFw?= =?utf-8?B?Z2FYbTY2UGdKdCtlbXlYZDRHYXpoM2doUjNZMzAvTElDYmozSGgvQ3N3bnIy?= =?utf-8?B?TlgrTlVYaTFqR25ZUUpjY25EalVvcFhLLzJadkVpL3NPSmpkelFrSkYzb1Qr?= =?utf-8?B?U2dybm1GRG1zM0NKKzMzZ2tGdjkrOTA4T2N4c1BDcElmUmw4bFNoQTNMUENh?= =?utf-8?B?ZjB0Q3Yza1Z0Q1pmaXpITnlRMVpqZVh1MU8wTUw5T1UrSzd5dFpMWWFXVWRP?= =?utf-8?B?SkF2TEpUaVlXeFpzN3JucTNkQTRlRjgvcTM2eGVrQ0h5aGkyblVmZlEzRUlo?= =?utf-8?B?SkZaQzRVOGJFQmZobE1UZVVCVjBSQTArUWhvR25yd2JkNXdBZlhzZVI4QWdl?= =?utf-8?B?Qmg3cjBMZ21sWm1JUUNieWtKa1ZQOUsvMEk1aGpwRWhBaTkyNG53MzgvVEcv?= =?utf-8?B?bzFya0h5NTdKMkwxTWNKQ1d1UlNicVFIRGxReTJDTDRVVDFxM3lhR0Voc2pX?= =?utf-8?B?LzRzc1AxTXE5aGdKWVhPN3U5SG5kRnpkdzJsTnB5OC9PcEJQTGZXbWJmNXpq?= =?utf-8?B?VVJSMHQ5bWhTQ2Vac2RJbUJqSW9KL0djTEhTYXJpelBZbU1ITHZpSjZYZThR?= =?utf-8?B?TktQbU1FbjQwOUxrbzM0d0JUaU1iMkNsdXNuUCtyZC8vMVdlbUcydk4ydDhU?= =?utf-8?B?ZlZPQW1zcGg2T3RXa1VUcUt3bzB5b3Fya3Bra2w0RUlkM2hhVUJVZnVadlEr?= =?utf-8?B?TUkzVTNsK21DRjF2a1NrOGZ3OXVQQ0xzWWQ3ZzkrNGJoenV4NWhFQWJoaTk1?= =?utf-8?B?S0VCb0NCZ3pTVTVBR3JWRmJsM3lTb1BDc3g1elE5dTVlUmsvMXlMVUd2M2hU?= =?utf-8?B?eUsyckpKZk9nb3Y5ZzZNS1pKWVlxSCtrTHdaYlNlaEpJaERaUGFkcEQwak9t?= =?utf-8?B?REJYaXkrOGU2eVMyY0xEVUw3aE5JSnFzSkRFM3FDeVpMNUs2WUkxc3RWenJO?= =?utf-8?B?empEeGtPeGRVUFFNWWNHTThZV2JLbTlFRG5MMzlHb3h2azVCdGZEb0Zrc3Mv?= =?utf-8?B?bmRFUFp2aWtYUUJGOG9MbGxaekNoQmRld0xVQktKb3dsMXVqNFEzcGxVb1JK?= =?utf-8?B?bW5QSFRWdUd2NTdvS2REVUE4Rll1RVdLbW9OcFVLclh4RWRaMHAwVVg4RDl0?= =?utf-8?B?NUUwU3BkUUpuNkFKeU9oZzVBZXV4clJFV1dQOTFGWk5sd1RsUGlNUGVGKzdZ?= =?utf-8?B?UG1sS21pdTBnbEE2NTFNMEVIYlJyeXdKWnhVcWw4SDNWTVN6ZXlyR0VLYXNY?= =?utf-8?B?NkFuV0JyRHRsRy9oVXErWWV0NjhwbCtxOEhiZDNTN1FYdHZDbGloQTZrZEFi?= =?utf-8?B?aW1McEcwdnJicUlJN2JWN2VZZ0dGZStOclprbnpnUHd0UG4yV2N0SDkzM0FS?= =?utf-8?B?ZjRyYW1nNlV1WlA2REl2N1kvbmFna1gwVm8wQTByM1p2b1ZmN3V4YTJ4QlA4?= =?utf-8?Q?7GFUvH98GpE5CoJTqkfqwp0m4AgyUXCd?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RThWV2toNm0waGNVR3NFa2NzU3gvL015dFY3dFZhQWxxNTFlem9pcVJUYVp0?= =?utf-8?B?TFVhTTlpZlNtNk5tc2d1Y3RzYlIzWlFyc3pjYnZkdGQxT0MvMnhna1ludjMy?= =?utf-8?B?SHM3TzRLVXcrYUdsaEZKZ01aTS8vTnBXSDJzNmgyRzJ4MUlsYXhDRngxbTU3?= =?utf-8?B?OFZyTG92Slk0YWhKclFtOWkyTGJVTWtlbGEreDRnY1YxRkRIeEdXYU81VVBh?= =?utf-8?B?NlVFelZaN2gwbjgwZDFFbE0za0R4WnpDVU9WenJkU2xaOGFYK2thMXkwMXBs?= =?utf-8?B?ZFJnYTVTNHpkSE12WjVKNHAyRGZwYWE3NnB0UXBkWmFiL1Y3Y2hKaExoeW5B?= =?utf-8?B?TzdNR3hvZmpSZFViT3pDU2pSMXkwdWh1UTM0RjVYNnFkNFR5ZDFYaFRKVGty?= =?utf-8?B?WHVVZkErSUp3UXR5Umt3aXBPU2VkdVV4VXl4aW1Yb2NtUkFFanQ0cWtyZGhu?= =?utf-8?B?WUs3RXFUeVhsTThJWXhBMjZpeXpSR05RVlVaOG5rVThmamRZWjBjczRXV1JE?= =?utf-8?B?YUFZZ3BrYXhpcGJVanRCTHh2UzRLUllERXNQOFNtSEI3bS9SMlZSeGtNWE5W?= =?utf-8?B?ajg0SkEvTHZZYnRzRllCYkdtZ0dyYzkyTDNMVUMxakt4Uy9qaFRaaGxPRHdV?= =?utf-8?B?dkE5clpVa0Y3OGwxWC82Q3RidUoyV1FXbXJuMWxHSlJsUEdDNlY1MDJvYmFn?= =?utf-8?B?cWc1MjQ5eVpLV28wRHVZT0pqb25KQ2xxODZudVdnYTF2VVhPNGtkeXhTTVd1?= =?utf-8?B?cE9rd240TzZUbFlTSGRQWmNIUm9rQWJDVWtMcllENG1wL1dHRlN4TllrcSt4?= =?utf-8?B?cmhoTEx4cmhYVmljRUFUaVZCMFI3dmQrUTI0RU1QNzFsRHErZFNXQ3lxbVRI?= =?utf-8?B?UHlnZnh1RTBFemRXZUxTOEVBaEdINklLdndXNm1NbFhYVG1NV1lidkNMS1N3?= =?utf-8?B?em5NcFVwRnA3UW5Na0xkS1d4S0ZBbHBGa0lVNHkxOXN3YWE2VEQ5ME5pMDZH?= =?utf-8?B?bFNXRTlOaUZ0NmtLT01pUTdmRFVad1czQ0xkSHZVOTNIOGRhUUNuUDM5cllw?= =?utf-8?B?bng3a3NvemVEYkVEeGpob0o0L1RYS21CeDFsWVZ6bFlmTlNNNEU0Ui96b01p?= =?utf-8?B?Vmw3aW5UNW1RWG1JWHF3a1ZiRlljUXBOMFdJdnVjRFZYZWdOMzBYbiswdXRw?= =?utf-8?B?MWVXU3V0by9LUXowNytDdnZRZ0FMZEJOQVpZQTZiNVh0WjJLK0JPdUZYakIz?= =?utf-8?B?bmN2UE5WbkNCNFJTaHUxRUxCcHQwMEtkaTZ3NlNFZUxBMGJ4SU5RV2psYVZ3?= =?utf-8?B?TTBoSUFqb05OaGFuTUpOWE1pMEpIMDJVZll3OEg3RCtvUVI4dE1qRE9CaVh3?= =?utf-8?B?cVlmWURNLysrNzVBMHhJZEYveFNMMlAyU3hxWHQwMFJVanZJQkJhcDAxRUNq?= =?utf-8?B?dmI1ZmZMZzZ0Q0xRZW5yL3pmbG91cUUrN3pvM2NkL0JIWXdrbk1rT3J3K24r?= =?utf-8?B?OFR5NFhXMXArNlpSekZjVGNDRWpiakkvWHMwZWtJRzNYNDRPejV6eXZmVnJ3?= =?utf-8?B?RHJrVjlFUCsvbGU3R3Z5WENMZ0xyUHpzMTVLRWpXcEQ2b29wTFc0RXJ4eUZY?= =?utf-8?B?T3pEcHM2NGNMcDNGVjk5dlpjZ0kyLzlGSmt2dndHYVZSTDd1Y1N0OGcvUmdq?= =?utf-8?B?N09nZHVESmw1dFpmYTIyVWl1OE52RktHUzB6WkFGWHZtUENlWmdYWi9NZWNs?= =?utf-8?B?c0duSjJUaHFWRFBEaUFpdjFpQXBDalY4VHl3MVhMaEZ3MTlvNVFtc1FmaTUw?= =?utf-8?B?OUhiblNFUzFHQ0NMaHVNcUtjeG83WnBVZ25mcFdwdDUwcWE3ZURvN0VZbEcy?= =?utf-8?B?Ty9pcmNTTkw1bWZjV2htUmp2ckhwTm85QTJHYmVSNHZPWklRcHJQVTVPSXEy?= =?utf-8?B?Sm9jTDhBY0hhdGw4SjNYazV3WlAzNjg5SktNWkFuVTVzUFNBT08ranhBZVg5?= =?utf-8?B?MEp0VUl3N2JId0EvWnYyRWhWa240KzZNU0pFb3RGSzVpWmFHT0RmU3hqQU1R?= =?utf-8?B?ekNQOWNQVDFOM3hJQWxpVm0vQVV0ZmkrRHR3WUIyU0tqUEJZUFRnMVYrQlZW?= =?utf-8?B?L0pDMXdCVERnNnUxNWRneXQ2dzRSUXR6bUorQVovL2dGdXk0ZzJlWWpxZzlD?= =?utf-8?B?MjBpdXI5NkhBaDdIaW9mVVhGUUdweFkzdnZhZEpvSEZhWXgyTkZzdFljWEE5?= =?utf-8?B?dkZVbVhvMGdoSXdISVJ4NTdBV0xJUGs0eEVXcVMrRkZiYXpzVmtFTGRTUGZy?= =?utf-8?B?eUc2cXZINWlPcHZkNGJPdjRpaWVaRDB6dGh0OXUvSDlqbExpM0F1QT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 84faf625-efc1-4e4f-1bbb-08de52d349bc X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2026 18:40:56.3411 (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: FTOLa/DSc+p3+/kuPs9J/9UmDoXj3sbTwB9loqPZC1e1FbVOlitAM4W7Zpj5QukpJ8TpG6DTsrhvxTY2sbBCrw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH4PR03MB7649 On Tue, Jan 06, 2026 at 02:58:29PM +0100, Jan Beulich wrote: > It's used in time.c alone. Modernize types while there. > > Amends: 5a82d598d2d ("viridian: unify time sources") > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jan 13 22:48:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 22:48:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202349.1517936 (Exim 4.92) (envelope-from ) id 1vfnB8-0005qK-3l; Tue, 13 Jan 2026 22:47:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202349.1517936; Tue, 13 Jan 2026 22:47:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfnB8-0005qD-1E; Tue, 13 Jan 2026 22:47:58 +0000 Received: by outflank-mailman (input) for mailman id 1202349; Tue, 13 Jan 2026 22:47: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 1vfnB6-0005q7-4z for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 22:47:56 +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 e4b3f6f5-f0d1-11f0-9ccf-f158ae23cfc8; Tue, 13 Jan 2026 23:47:53 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 9D09F60018; Tue, 13 Jan 2026 22:47:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6A85FC116C6; Tue, 13 Jan 2026 22:47: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: e4b3f6f5-f0d1-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768344471; bh=tTt6Ten7zQu3KDjN/5ZOWgqcgitbPTpKXEV4joDC6IY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=uNq2i/acM/fxNvpqAePr7NIYrGgV0j1ylhp+KVkdvx0wE3U1GQuCRuJZtkJOE6DnT WUNM5wQ2FYRexSTmsX2KV35qUmdB3BqOTg+k2UXKs9umFdxesGGC8aiWTRpIS3h8Be CU8aevbzDkHnjrSJXJKuB5EHiR3BeY/j+gfXiYj00KGv9PNvFpRS9NFQKHeWYzTs74 gVTOUoFnTRozpsGdtyJBLlr49xiTfeHSzPWMdYfDY/kDvkfErE0L/n9k9SdQPXPrzd FonvDw6A86S7U+Ayf+y+zPUL4q9HEaZ2d9shseb+YPzLZDxetFe0UUVYzIaGKapUcc kr2rXtw91yvWg== Date: Tue, 13 Jan 2026 14:47:48 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Mykola Kvach cc: Xen-devel , andrea.bastoni@minervasys.tech, marco.solieri@minervasys.tech, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk , Carlo Nonato Subject: Re: [BUG] LLC coloring: parse_color_config shorthand/UINT_MAX/partial configs + missing newline In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1412054276-1768344472=:992863" 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-1412054276-1768344472=:992863 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Hi Mykola, Replies inline below On Tue, 13 Jan 2026, Mykola Kvach wrote: > Hi all, > > While investigating the Arm cache coloring, I noticed a few issues in > parse_color_config() and one minor logging issue in the DT-related changes. > > 1) parse_color_config() appears to accept "shorthand" forms not described > by the documented grammar > > The function documents: > COLOR_CONFIGURATION ::= COLOR | RANGE,...,COLOR | RANGE > RANGE ::= COLOR-COLOR > > However, as implemented, inputs starting with a delimiter may be > accepted and interpreted as if a leading 0 was present. For example: > > ",2-6" -> interpreted as "0,2-6" > "-10,2-6" -> interpreted as "0-10,2-6" > > The reason is that the parser calls simple_strtoul(s, &s, 0) and then > directly checks for '-'/',' at *s. If no digits were consumed, start > becomes 0 and s can remain at the delimiter, which then gets treated as > a range or separator. > > Questions/proposed direction: > - Is accepting these shorthand forms intentional? If yes, I think we > should document them explicitly (both in the comment above > parse_color_config() and in user-visible docs). > - If not intentional, we likely want to reject by verifying that at > least one digit was consumed for each number before accepting '-' > or ','. Yes, I think it was intentional. I would be happy with adding the shorthands to the documentation. > 2) Potential infinite loop/hang for ranges ending at UINT_MAX > > The range expansion loop uses: > for (color = start; color <= end; color++) > > If end == UINT_MAX, incrementing color wraps back to 0, and > (color <= end) remains true, resulting in an infinite loop inside early > parsing. The current bounds checks do not prevent > (start=UINT_MAX-some_small_number, end=UINT_MAX) > from passing. While that is true, no cache in existence can have even close to UINT_MAX colors, and the number of colors are either passed by the user (and assumed correct) or detected from the hardware. While I wouldn't mind hardening the code against bad configurations and I welcome a patch for it, we are talking about a patch that would turn a crash into an explicit panic or similar. Also see below. > 3) Partial global state on parse error can leak into later init/config use > parse_color_config() writes into the provided array and increments > *num_colors as it goes. On a parse error it returns -EINVAL, but the > partially updated outputs remain. > > his is particularly problematic for the cmdline parameters, because the > utputs are global and can later be consumed by llc_coloring_init() or > dom0_set_llc_colors(). > > A concrete example is "1,w,3-5": > - "1" is parsed and committed > - at "w", simple_strtoul() returns 0 and does not advance 's' > - the code then treats this as a single color 0, commits it, and breaks > out with *s != '\0' > - the function returns -EINVAL, but num_colors and the array already > contain a partial configuration > > In other words, a rejected configuration can still leave xen_num_colors > or dom0_num_colors non-zero and the corresponding colors[] partially > populated, which risks the feature being initialized/applied with an > unintended set of colors. > > I think the parser should be fail-closed here. Minimally: reset > *num_colors to 0 on any error path (including the final "*s ? -EINVAL" > case). Ideally: parse transactionally into a temporary buffer and only > commit outputs on full success. I think we should panic on parsing errors: cache coloring is not a feature for beginners that a distro like Debian is going to enable to improve the out of the box experience with new users. Cache coloring is a sophisticated feature that takes time to learn how to use it effectively. If an experience embedded developer is providing an erroneous configuration the best we can do it panic so that it becomes immediately obvious what they did wrong and they can fix it. > 4) Cosmetic: missing newline in printk in domain_set_llc_colors_from_str() > > printk(XENLOG_ERR "Error parsing LLC color configuration"); > without a trailing '\n'. > > I wanted to flag these issues in case you’d like to address them in the > next revision/follow-up. Sure please fix --8323329-1412054276-1768344472=:992863-- From xen-devel-bounces@lists.xenproject.org Tue Jan 13 23:06:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 23:06:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202370.1517946 (Exim 4.92) (envelope-from ) id 1vfnSY-0000Hl-KN; Tue, 13 Jan 2026 23:05:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202370.1517946; Tue, 13 Jan 2026 23:05:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfnSY-0000He-He; Tue, 13 Jan 2026 23:05:58 +0000 Received: by outflank-mailman (input) for mailman id 1202370; Tue, 13 Jan 2026 23:05:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfnSY-0000HS-1c for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 23:05:58 +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 6a691f48-f0d4-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 00:05:56 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 18D2D60018; Tue, 13 Jan 2026 23:05:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 10B37C116C6; Tue, 13 Jan 2026 23:05: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: 6a691f48-f0d4-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768345554; bh=9CN2VHBk5fq1iH+7VGkDZiOjbskB+UkAhrBK78R6cFE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Zx1jwhsdrAlSNJZZAjSyrGjBeoR3INCiL8sLzjv0JitkBn77Ffx0S2yj7CPi7R0Yk Pr61HiobP0F+VfE3/nObCaWl59fOS4+KZTK9cCLTP01EAyt0jGI0tlhpXmoIczuJn5 yZWMmEfKTaTS3P4hR4j4rWuTEsWaKg1ob/e9e2Bx3QzHkkjtd0OmS1+FRPOcSNRFGB fEntCK8WDkXCzbsRuLpr07/4JPPHBaKAxb5PgAcutd6xV8NkS+ZhJBzeYgkaTT+hRW L3COjFBw6M6GoA8GQu7iIxZkOYe2yfMpNb99hHDRT6ZwVCNBcMmOThYRBC6hP3dY+z 5sKWctYe1FJOg== Date: Tue, 13 Jan 2026 15:05:52 -0800 (PST) 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 v6 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver In-Reply-To: <0e805633-4e68-43b5-8201-81dc5135010a@epam.com> Message-ID: References: <0e805633-4e68-43b5-8201-81dc5135010a@epam.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Tue, 13 Jan 2026, Oleksii Moisieiev wrote: > >> chosen { > >> ranges; > >> xen,config { > > Q: [Stefano] The node name could be xen-config, but it doesn't matter > > because we > > should check for the compatible string instead (no check on node name). > > > > We need to add a compatible string here, I would use "xen,scmi": > > > > compatible = "xen,scmi"; > > > > > > A: [OM] this is a great finding. After looking into hyperlauch code I > > see the following implementation: > > > > > > config { > > compatible = "xen,config"; > > ... > > }; > > > > I was thinking about changing current approach to have the following > > format: > > > > config { > > compatible = "xen,config"; > > ... > > scmi_config { > > compatible = "xen,sci"; <-- more generic compatible string > > than "xen,scmi" > > scmi-secondary-agents = < > > 0x82000003 &scmi_shm_0 0 > > 0x82000004 &scmi_shm_2 2 > > ...>; > > #scmi-secondary-agents-cells = <3>; <--- optional, > > default 3 > > scmi_shm_0 : sram@47ff0000 { > > compatible = "arm,scmi-shmem"; > > reg = <0x0 0x47ff0000 0x0 0x1000>; > > }; > > > > scmi_shm_2: sram@47ff2000 { > > compatible = "arm,scmi-shmem"; > > reg = <0x0 0x47ff2000 0x0 0x1000>; > > }; > > scmi_xen: scmi { > > compatible = "arm,scmi-smc"; > > arm,smc-id = <0x82000002>; <--- Xen manegement agent > > smc-id > > #address-cells = < 1>; > > #size-cells = < 0>; > > #access-controller-cells = < 1>; > > shmem = <&scmi_shm_1>; <--- Xen manegement agent shmem > > }; > > }; > > ... > > }; > > > > and update scmi-multiagent driver to match "xen,sci" compatible and > > process all subnodes during probe. > > What do you think about this approach? Yes I think that's better. To be precise this would be the DT nodes hierarchy: chosen { xen { compatible = "xen,hypervisor"; // I would rather use an even more generic compatible string bootargs = ""; // since we are introducing this node we can use it for Xen bootargs scmi { compatible = "xen,sci"; } }; domU0@address { }; domU1@address { }; }; I would start by adding a patch for docs/misc/arm/device-tree/booting.txt to add the new nodes. From xen-devel-bounces@lists.xenproject.org Tue Jan 13 23:22:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 23:22:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202382.1517957 (Exim 4.92) (envelope-from ) id 1vfniu-00034F-Rf; Tue, 13 Jan 2026 23:22:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202382.1517957; Tue, 13 Jan 2026 23:22:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfniu-000348-OG; Tue, 13 Jan 2026 23:22:52 +0000 Received: by outflank-mailman (input) for mailman id 1202382; Tue, 13 Jan 2026 23:22:51 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfnit-000342-Pd for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 23:22:51 +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 c64df37c-f0d6-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 00:22:49 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 196676000A; Tue, 13 Jan 2026 23:22:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 330B2C116C6; Tue, 13 Jan 2026 23:22: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: c64df37c-f0d6-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768346567; bh=mL/FoDrtK0bhpnitojwJK2Qv3wuQ7upQnsTKciUEp6s=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=InjL+/eX0OT/SjG5rDpFGlAnJ/BggceavHGzLj8KImqEBwEvG3t8g/HbGjZMou2eQ 6aWAc13KpZeSME49YrIJBqfUMpa35BGEynLm6eLndiDa7/XAMA3Xcb+kvu0VPy8GQr uEOG1t84aGPc6XMS2OTRqAjbBGM9IYCAMVk7aqmRFP4Jps9cutoZJ0lalqlCP5089s QHQQI8wBERwQ2WZeGdYXPT1B7ToVc/iBLnq8z5Y17kuFsDU5Md/gJILfaRjZuUJewQ IsEZbLfNR14PeXf7jsh8h00MsjhBKngTKJ1g/ETzwPoARdI0YR3H/DlZ28dys76v+s 5K/fmgspnCrUQ== Date: Tue, 13 Jan 2026 15:22:46 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Juergen Gross cc: Stefano Stabellini , oleksandr_tyshchenko@epam.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH v2] xen: introduce xen_console_io option In-Reply-To: <4f22683f-8fd4-4db6-ac74-83c6f6460924@suse.com> Message-ID: References: <4f22683f-8fd4-4db6-ac74-83c6f6460924@suse.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1269708819-1768346568=:992863" 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-1269708819-1768346568=:992863 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Tue, 13 Jan 2026, Juergen Gross wrote: > On 13.01.26 08:57, Jürgen Groß wrote: > > On 13.01.26 01:24, Stefano Stabellini wrote: > > > Xen can support console_io hypercalls for any domains, not just dom0, > > > depending on DEBUG and XSM policies. These hypercalls can be very useful > > > for development and debugging. > > > > > > Introduce a kernel command line option xen_console_io to enable the > > > usage of console_io hypercalls for any domain upon request. When > > > xen_console_io is not specified, the current behavior is retained. > > > > > > Signed-off-by: Stefano Stabellini > > > > Reviewed-by: Juergen Gross > > Sorry, I need to revoke my R-b. > > I get: > > WARNING: modpost: vmlinux: section mismatch in reference: xen_cons_init+0x0 > (section: .text) -> opt_console_io (section: .init.data) > > I think xen_cons_init() should be __init, too. Yes you are right, good catch. I am cross-compiling x86 on ARM and my environment is not warning me about it. I made the change. --8323329-1269708819-1768346568=:992863-- From xen-devel-bounces@lists.xenproject.org Tue Jan 13 23:24:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 13 Jan 2026 23:24:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202391.1517966 (Exim 4.92) (envelope-from ) id 1vfnkP-0003ad-4B; Tue, 13 Jan 2026 23:24:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202391.1517966; Tue, 13 Jan 2026 23: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 1vfnkP-0003aW-1b; Tue, 13 Jan 2026 23:24:25 +0000 Received: by outflank-mailman (input) for mailman id 1202391; Tue, 13 Jan 2026 23: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 1vfnkO-0003ZP-7x for xen-devel@lists.xenproject.org; Tue, 13 Jan 2026 23:24:24 +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 fded9486-f0d6-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 00:24:23 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 0598F60018; Tue, 13 Jan 2026 23:24:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E72AC116C6; Tue, 13 Jan 2026 23:24: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: fded9486-f0d6-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768346661; bh=KgQbc3VLgN7FcqOfwIdsTARgz+mso4XfSHtrhZFGh5g=; h=Date:From:To:cc:Subject:From; b=qsQcVicRbRyhAVtmSTEmkbGAw7ETuJxTQjDLCGiCRTU1YVjEGoTy1NikL39zKLjIZ Gap/pOnYQtOXYvPNrZodODmmH9tgwF2S8VlTlBQjslcq1kMz2s48k2xQWXeRPMMnjQ 9bdbzmKpdf4ji4de40sI3ZmRSPVcPHqaFSAH96kvlOaU1CoEAmy8DpZ4ChIpJ7QDlH h8tRNOVHnDojPIvCWw0YuQi9L8p9vOcs1/meo8fGcvWhsWDOwl0C+Fh8ObwziSAiGH 61onOkoiWbeHPoRY/elmeOQQUZQyhUxNbfn1QvPqln9OHLsUWNr/Fb3clDPVJdV91B kcGE4nlSS/yWA== Date: Tue, 13 Jan 2026 15:24:20 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: xen-devel@lists.xenproject.org cc: sstabellini@kernel.org, jgross@suse.com, oleksandr_tyshchenko@epam.com Subject: [PATCH v3] xen: introduce xen_console_io option Message-ID: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Xen can support console_io hypercalls for any domains, not just dom0, depending on DEBUG and XSM policies. These hypercalls can be very useful for development and debugging. Introduce a kernel command line option xen_console_io to enable the usage of console_io hypercalls for any domain upon request. When xen_console_io is not specified, the current behavior is retained. Signed-off-by: Stefano Stabellini --- Changes in v3: - mark xen_cons_init as __init Changes in v2: - use kstrtobool --- .../admin-guide/kernel-parameters.txt | 5 ++++ drivers/tty/hvc/hvc_xen.c | 29 +++++++++++++++---- 2 files changed, 29 insertions(+), 5 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index a8d0afde7f85a..68ab6fa72b685 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -8414,6 +8414,11 @@ Kernel parameters save/restore/migration must be enabled to handle larger domains. + xen_console_io [XEN,EARLY] + Boolean option to enable/disable the usage of the Xen + console_io hypercalls to read and write to the console. + Mostly useful for debugging and development. + xen_emul_unplug= [HW,X86,XEN,EARLY] Unplug Xen emulated devices Format: [unplug0,][unplug1] diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c index 388a71afd6efe..95ec01b1aacf0 100644 --- a/drivers/tty/hvc/hvc_xen.c +++ b/drivers/tty/hvc/hvc_xen.c @@ -51,6 +51,22 @@ static DEFINE_SPINLOCK(xencons_lock); /* ------------------------------------------------------------------ */ +static bool xen_console_io = false; +static int __initdata opt_console_io = -1; + +static int __init parse_xen_console_io(char *arg) +{ + bool val; + int ret; + + ret = kstrtobool(arg, &val); + if (ret == 0) + opt_console_io = (int)val; + + return ret; +} +early_param("xen_console_io", parse_xen_console_io); + static struct xencons_info *vtermno_to_xencons(int vtermno) { struct xencons_info *entry, *ret = NULL; @@ -331,7 +347,7 @@ static int xen_initial_domain_console_init(void) struct xencons_info *info; unsigned long flags; - if (!xen_initial_domain()) + if (!xen_console_io) return -ENODEV; info = vtermno_to_xencons(HVC_COOKIE); @@ -369,7 +385,7 @@ void xen_console_resume(void) { struct xencons_info *info = vtermno_to_xencons(HVC_COOKIE); if (info != NULL && info->irq) { - if (!xen_initial_domain()) + if (!xen_console_io) xen_console_update_evtchn(info); rebind_evtchn_irq(info->evtchn, info->irq); } @@ -601,7 +617,7 @@ static int __init xen_hvc_init(void) if (!xen_domain()) return -ENODEV; - if (xen_initial_domain()) { + if (xen_console_io) { ops = &dom0_hvc_ops; r = xen_initial_domain_console_init(); if (r < 0) @@ -647,14 +663,17 @@ static int __init xen_hvc_init(void) } device_initcall(xen_hvc_init); -static int xen_cons_init(void) +static int __init xen_cons_init(void) { const struct hv_ops *ops; + xen_console_io = opt_console_io >= 0 ? opt_console_io : + xen_initial_domain(); + if (!xen_domain()) return 0; - if (xen_initial_domain()) + if (xen_console_io) ops = &dom0_hvc_ops; else { int r; -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Wed Jan 14 00:34:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 00:34:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202406.1517976 (Exim 4.92) (envelope-from ) id 1vfops-0004Pl-Us; Wed, 14 Jan 2026 00:34:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202406.1517976; Wed, 14 Jan 2026 00:34: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 1vfops-0004Pe-Rv; Wed, 14 Jan 2026 00:34:08 +0000 Received: by outflank-mailman (input) for mailman id 1202406; Wed, 14 Jan 2026 00:34: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 1vfopr-0004PY-LW for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 00:34: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 bae5f279-f0e0-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 01:34:05 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 2E6476000A; Wed, 14 Jan 2026 00:34:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5AA62C116C6; Wed, 14 Jan 2026 00:34: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: bae5f279-f0e0-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768350843; bh=9e2QbnMmZj2XxBe7h1WdUyrJFkXicHq5AIV9TxdkiXA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=HBniICX8QRAddh0CA0OyoxHHh/3BsZD+DHOsN3cg9ycJpMVEcWQQFBpqWVygl4TpF xaxrt9JXzaeN7xYFjLsZOzDUUJKvUmWW2lhe0Z3bB/vp2m3ZlBtHeBgF/HjcZeEdlZ bj6BacTAIsq7XX9EFDf5u6J0kIvjVLKoZ0Mdwxtr9H8hm/XvL/vUnWqW+GRN4RNusJ 3hLSOp5uFmyPu6/ZVKXJB3RP8WxBIYaCfCQcb27JXAvpeIg4wgd5E2qM+IJ8PUcHmQ 814Xa3cOM0qwObfKFPZ52AFtwshr/jAUgZy26W+/17p0pLgoA2hf1LpyAyuHNtPot4 l9iNnpJhxvt/w== Date: Tue, 13 Jan 2026 16:33:58 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Jan Beulich cc: Stefano Stabellini , grygorii_strashko@epam.com, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Victor Lira , andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH v2] xen/console: handle multiple domains using console_io hypercalls In-Reply-To: <3376e95d-8da5-4bc8-893f-4f9c84404a32@suse.com> Message-ID: References: <3376e95d-8da5-4bc8-893f-4f9c84404a32@suse.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Tue, 13 Jan 2026, Jan Beulich wrote: > On 13.01.2026 02:30, Stefano Stabellini wrote: > > Allow multiple dom0less domains to use the console_io hypercalls to > > print to the console. Handle them in a similar way to vpl011: only the > > domain which has focus can read from the console. All domains can write > > to the console but the ones without focus have a prefix. In this case > > the prefix is applied by using guest_printk instead of printk or > > console_puts which is what the original code was already doing. > > > > Signed-off-by: Stefano Stabellini > > --- > > Changes in v2: > > - fix code style > > - pbuf_idx/idx after ada53067083e > > - don't add extra \0 > > - clear input on console switch > > --- > > xen/drivers/char/console.c | 25 ++++++++++++++++++++++++- > > 1 file changed, 24 insertions(+), 1 deletion(-) > > > > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c > > index 2bdb4d5fb4..6c7a6592c5 100644 > > --- a/xen/drivers/char/console.c > > +++ b/xen/drivers/char/console.c > > @@ -576,6 +576,8 @@ static void console_switch_input(void) > > rcu_unlock_domain(d); > > > > console_rx = next_rx; > > + /* don't let the next dom read the previous dom's unread data */ > > Nit: Comment style. > > > + serial_rx_cons = serial_rx_prod; > > printk("*** Serial input to DOM%u", domid); > > Imo the flushing of input needs to come after the printk(), as it's only > then that the user gets confirmation of the change. > > As to flushing (rather than storing) leftover input: That's strictly an > improvement over v1, but imo unhelpful. I may not be willing to ack this > (still need to think about it some more), but at the very least this > somewhat odd behavior needs calling out (and perhaps also justifying) in > the description. Input is typically read quickly; if there is unread data is because the domain is slow or stuck. In this situation, the user is both providing the unread input and also typing Ctrl-AAA to switch domain. The user must be aware of the unread input. In my direct experience using this feature, it is natural that the unread data is lost and wouldn't expect otherwise. You are right that the explanation is missing from the commit message. I'll add it. > Further, did you think through the interaction with a racing > CONSOLEIO_read? Right now that's the only place where serial_rx_cons is > updated, and hence there was no issue with there being multiple reads > of the variable (perhaps unless a domain issued racing CONSOLEIO_read). > That changes now. I can't convince myself (yet) that's entirely safe, > and hence if it is that also wants discussing in the description. Looking carefully I also cannot convince myself it is OK. I wonder if we should use nrspin_lock_irq and nrspin_unlock_irq here and in CONSOLEIO_read. I'll send a patch update doing that. I tested it and works. > > @@ -730,6 +732,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, > > unsigned int flags = opt_console_to_ring > > ? CONSOLE_ALL : CONSOLE_DEFAULT; > > struct domain *cd = current->domain; > > + struct domain *input; > > > > while ( count > 0 ) > > { > > @@ -742,18 +745,28 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, > > if ( copy_from_guest(kbuf, buffer, kcount) ) > > return -EFAULT; > > > > - if ( is_hardware_domain(cd) ) > > + input = console_get_domain(); > > + if ( input && cd == input ) > > { > > + struct domain_console *cons = cd->console; > > + > > + if ( cons->idx ) > > + { > > + console_send(cons->buf, cons->idx, flags); > > + cons->idx = 0; > > + } > > I probably should have said so on v1 already: What is this about? There's > no comment and nothing in the description that I could associate with this > code. Something else to add to the commit message. The domain output is buffered when not in focus. When need to clear it out as the domain enters focus. > And then - is this safe without holding cons->lock? I'll move the console_lock taking earlier > > @@ -815,6 +829,13 @@ long do_console_io( > > if ( count > INT_MAX ) > > break; > > > > + d = console_get_domain(); > > + if ( d != current->domain ) > > + { > > + console_put_domain(d); > > + return 0; > > + } > > As of here d == current domain. Why are you holding onto ... > > > rc = 0; > > while ( (serial_rx_cons != serial_rx_prod) && (rc < count) ) > > { > > @@ -826,12 +847,14 @@ long do_console_io( > > len = count - rc; > > if ( copy_to_guest_offset(buffer, rc, &serial_rx_ring[idx], len) ) > > { > > + console_put_domain(d); > > rc = -EFAULT; > > break; > > } > > rc += len; > > serial_rx_cons += len; > > } > > + console_put_domain(d); > > break; > > ... the domain for this long (requiring multiple console_put_domain() > invocations)? The current domain can't go away under your feet. Hence imo > a single (early) call will do. Yes, good point From xen-devel-bounces@lists.xenproject.org Wed Jan 14 00:40:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 00:40:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202417.1517987 (Exim 4.92) (envelope-from ) id 1vfovd-0005vx-JG; Wed, 14 Jan 2026 00:40:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202417.1517987; Wed, 14 Jan 2026 00:40:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfovd-0005vp-EV; Wed, 14 Jan 2026 00:40:05 +0000 Received: by outflank-mailman (input) for mailman id 1202417; Wed, 14 Jan 2026 00:40: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 1vfovc-0005bB-4s for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 00:40:04 +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 8f7bb6a5-f0e1-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 01:40:02 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 9547540765; Wed, 14 Jan 2026 00:40:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA606C116C6; Wed, 14 Jan 2026 00:39: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: 8f7bb6a5-f0e1-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768351200; bh=btgGbUV4PFGAKSPjJqxJj29N51HHpBgWuBJBYCxGcd4=; h=Date:From:To:cc:Subject:From; b=uUf2rLvXuQ4EeK4M3x9d8DFpBY8tiB1S5ZHaSUoDX7hhHpe35qj2pM9yfpJRLIpGH JcUXKCpEPlw1hGVf5bnuM3RzyfPM9k39dZ/scLdsvEIUCXhNhfjiUsYIbz7fZv0JBy GzTDna79TRCIgVndAM4/vn2ZQzi8exGIOpuTOP025Dv8ND0KjaWEGKMMDTg5gCOLy+ RjztMKkJjyAaHrAUm4njW85UlpePWiRC1qXcmmFsbqAaLoCGkDqfY41bY2ZfInpIJH 8DLAdawnRDUH8xx2YNSZ7eQE9dF45k9DdBbD9TZIksBjv9YFhaq8g8NRJ8bxzSPNds 9jEJbiGrgMYMw== Date: Tue, 13 Jan 2026 16:39:57 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: xen-devel@lists.xenproject.org cc: jbeulich@suse.com, Stefano Stabellini , grygorii_strashko@epam.com, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Victor Lira , andrew.cooper3@citrix.com Subject: [PATCH v3] xen/console: handle multiple domains using console_io hypercalls Message-ID: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Allow multiple dom0less domains to use the console_io hypercalls to print to the console. Handle them in a similar way to vpl011: only the domain which has focus can read from the console. All domains can write to the console but the ones without focus have a prefix. In this case the prefix is applied by using guest_printk instead of printk or console_puts which is what the original code was already doing. When switching focus using Ctrl-AAA, discard any unread data in the input buffer. Input is read quickly and the user would be aware of it being slow or stuck as they use Ctrl-AAA to switch focus domain. In that situation, it is to be expected that the unread input is lost. The domain writes are buffered when the domain is not in focus. Push out the buffer when the domain enters focus. Add the console_lock around serial_rx_cons modifications to protect it against concurrent writes to it. Signed-off-by: Stefano Stabellini --- Changes in v3: - move serial_rx_cons before printk - call console_put_domain earlier on CONSOLEIO_read - take console_lock earlier - add console_lock around serial_rx_cons modifications Changes in v2: - fix code style - pbuf_idx/idx after ada53067083e - don't add extra \0 - clear input on console switch --- xen/drivers/char/console.c | 30 +++++++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 2bdb4d5fb4..58c32f22ef 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -577,6 +577,10 @@ static void console_switch_input(void) console_rx = next_rx; printk("*** Serial input to DOM%u", domid); + /* Don't let the next dom read the previous dom's unread data. */ + nrspin_lock_irq(&console_lock); + serial_rx_cons = serial_rx_prod; + nrspin_unlock_irq(&console_lock); break; } } @@ -730,6 +734,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, unsigned int flags = opt_console_to_ring ? CONSOLE_ALL : CONSOLE_DEFAULT; struct domain *cd = current->domain; + struct domain *input; while ( count > 0 ) { @@ -742,18 +747,28 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, if ( copy_from_guest(kbuf, buffer, kcount) ) return -EFAULT; - if ( is_hardware_domain(cd) ) + input = console_get_domain(); + if ( input && cd == input ) { - /* Use direct console output as it could be interactive */ + struct domain_console *cons = cd->console; + nrspin_lock_irq(&console_lock); + if ( cons->idx ) + { + console_send(cons->buf, cons->idx, flags); + cons->idx = 0; + } + /* Use direct console output as it could be interactive */ console_send(kbuf, kcount, flags); nrspin_unlock_irq(&console_lock); + console_put_domain(input); } else { char *kin = kbuf, *kout = kbuf, c; struct domain_console *cons = cd->console; + console_put_domain(input); /* Strip non-printable characters */ do { @@ -795,6 +810,7 @@ long do_console_io( { long rc; unsigned int idx, len; + struct domain *d; rc = xsm_console_io(XSM_OTHER, current->domain, cmd); if ( rc ) @@ -815,6 +831,11 @@ long do_console_io( if ( count > INT_MAX ) break; + d = console_get_domain(); + console_put_domain(d); + if ( d != current->domain ) + return 0; + rc = 0; while ( (serial_rx_cons != serial_rx_prod) && (rc < count) ) { @@ -830,7 +851,10 @@ long do_console_io( break; } rc += len; - serial_rx_cons += len; + nrspin_lock_irq(&console_lock); + if ( serial_rx_cons != serial_rx_prod ) + serial_rx_cons += len; + nrspin_unlock_irq(&console_lock); } break; default: -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Wed Jan 14 06:01:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 06:01:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202452.1517997 (Exim 4.92) (envelope-from ) id 1vftw5-0000Xn-22; Wed, 14 Jan 2026 06:00:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202452.1517997; Wed, 14 Jan 2026 06:00:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vftw4-0000Xf-TV; Wed, 14 Jan 2026 06:00:52 +0000 Received: by outflank-mailman (input) for mailman id 1202452; Wed, 14 Jan 2026 06:00:52 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vftw4-0000XZ-Fh for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 06:00:52 +0000 Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [2a00:1450:4864:20::22d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 61237020-f10e-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 07:00:51 +0100 (CET) Received: by mail-lj1-x22d.google.com with SMTP id 38308e7fff4ca-38310ee9d40so43118341fa.1 for ; Tue, 13 Jan 2026 22:00:51 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 61237020-f10e-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768370450; x=1768975250; 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=DCy1gkdAFYhKRkFLQUVCrclHbUxztvT7IZ0HJ77bow8=; b=IiWGq1+9eO0i5CFt1zLed5UmlspwDwJZ5feZnf/2nvCPJTzQs2XLpm3PE89lQ2wb8X q6d0ayrcdJlDB2BxTKhTuMPZnLFbuLPKRU8blKcvuZzIkEEe1Mv5DWWLJMuFqIwPNq1l PtgB+7GnXy7LJZZ2fq2tmCdM6woVmxPYo6s7mQXIv0Xo9rllusf3G9U8qlVh+uFddof6 fyzDFlm7wngFK7DQr5Y5eBXna1O2fRAElObp0a6Gf+z1S46lecGVIv+o8qfUBzHIaYhf FTl1+rXAp1aSN+nNilhNv9FuPoQwkuCuuWLCxgfE+fuOVfnvDigrIG/HoXuQ/6anhmNH n4LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768370450; x=1768975250; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=DCy1gkdAFYhKRkFLQUVCrclHbUxztvT7IZ0HJ77bow8=; b=JlQNHoheUYMtn089XXgigJKuLAafsJZ6cjxFoFboomQFXPzeGqgmJrjLZlN0oAGmFY oPg5ec4Wckvi2eIkX3sF5PrLm+/BV+eMxZ68PcBF0llbLvet/LRfJwpoGTgeudGmx4Rv pRroDmoUUmZ7ZpNNg/0yoAOUBrpgCU526eczv+OV4IjcO4iq2KLsjdwYQdrVrEYwm/tP JujE9mPF6+2YNAGeng1MIKOubGxNuU562a9YJOA9IgUWchNKTxmpksUD/OZxgFvINLL4 B+/A3NF9vv/gelnvk/4+atJqMUAymagfpmmQ+MNSJX+Agw45Ta7jJN9XVmxre4/TTbGy e0gw== X-Forwarded-Encrypted: i=1; AJvYcCUbfKxOYHtZjd1qrl5A0stb30DZTlQn+60Hq7o8cjMCKVBB3Jb/7drclJi8UGGJBivXXJVXPuNDsbg=@lists.xenproject.org X-Gm-Message-State: AOJu0YzqmbkRTQI016uSjRAFq0y0yZzKAsW+6Xjl9LcLGbA+oVlIOljP aeb4wMUtj1qB9zGLP4q5KozrdjTDvEJBKsud/bwU9ulb5gfK2YX0LzVMcPcHm1gcr/X9GuVfE8n Kk9koIT3MIrIEC9lDp2MzFnDHm9GssxM= X-Gm-Gg: AY/fxX6I0j2GBPFJ4QDmHceF7vqSaqD+E2/qavaNEjcQtJlQcvf8xTlWZ2zaYowaVX6 C9cYHHkWQtAg6KgONc439BIcHPC0BgKV+IBFQaTOgQiBgfs/rgY0KMBzS8buETks8hQ8aYrndo1 PBG5UD4sTm7kXrRG+tGp6ZbDw+Gcg6dL5AzxTsVsAOR6VaOJMByxkIFcz8YkIw6OjklY3I235tf DT8R3mzopH+YwhQK4a+jVdivd4K/DJ3Ute/5d48jT2gnHbb5XXLxDUuUHDqNBuL9RRHf7CitDvi MfTp X-Received: by 2002:a05:651c:30ca:b0:37c:d689:7e1c with SMTP id 38308e7fff4ca-38360756ffbmr4362431fa.23.1768370450167; Tue, 13 Jan 2026 22:00:50 -0800 (PST) MIME-Version: 1.0 References: <0d0f4689-97e2-408f-91e4-dd59f47bdb95@xen.org> <8133A491-4245-4376-A00C-D6D98C10A2AC@arm.com> In-Reply-To: <8133A491-4245-4376-A00C-D6D98C10A2AC@arm.com> From: Mykola Kvach Date: Wed, 14 Jan 2026 08:00:00 +0200 X-Gm-Features: AZwV_QgMO-YJDFYvMOYeKKTllHHPtYbw_6--Gdgi7t7DpmUxiAGuJgEhorjN-3I Message-ID: Subject: Re: [PATCH] xen/arm: irq: Use appropriate priority for SGIs in setup_irq() To: Bertrand Marquis Cc: Julien Grall , "xen-devel@lists.xenproject.org" , Mykola Kvach , Stefano Stabellini , Michal Orzel , Volodymyr Babchuk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bertrand, Julien, First of all, please accept my apologies for the delayed response. On Wed, Dec 3, 2025 at 10:10=E2=80=AFAM Bertrand Marquis wrote: > > Hi Julien/Mykola, > > > On 2 Dec 2025, at 19:26, Julien Grall wrote: > > > > Hi, > > > > Sorry for the late answer. > > > > On 16/09/2025 11:19, Mykola Kvach wrote: > >> On Sat, Sep 13, 2025 at 1:01=E2=80=AFAM Julien Grall = wrote: > >>>> 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 ir= qflags, struct irqaction *new) > >>> AFAIK, we are not using setup_irq() to handle SGIs because they are a= ll > >>> static and always enabled. Are you planning to handle dynamic SGIs? I= f > >>> 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 Xen. For > >> example, see ffa_notif.c in the functions ffa_notif_init_interrupt > >> and ffa_notif_init, which handle initialization of such SGIs. > > > > Bertrand can you comment on this? In particular, do we want the FFA SGI= s to have the priority of the internal ones? > > The following is only an advice, definitely not a requirement. I would > be ok to ack the current way to do things as right now FF-A is unsupporte= d and > is the only case of usage of dynamic SGI. > I would though require to have a log message to warn the user that SGI xx > has the same priority as xen internal interrupts during request_irq. > > Here is what I think: > > FFA SGIs can only be generated by the secure world and in practice they w= ill > be generated mostly when coming coming back from the secure world (either > after a preemption or on a return to an smc call) but one could also be > generated from the secure world from another core, preempting whatever ru= ns > (but same would occur when an interrupt is directly handled in the secure= world). > > Linux kernel implementation is not lowering the FF-A SGI interrupt as far= as I know. > > In my view having the FFA SGI having the same priority as ffa internal SG= I would mean > we have some trust that the secure world will not overload us. > > But in reality it would make sense to have a priority ordering like: > - Xen internal SGIs > - FF-A SGI (or any other dynamic SGI) > - any other kind of interrupt > > So that Xen internal SGIs have the highest priority, but having other SGI= s still having > a better priority than other interrupts. > > In any case, whatever we do, we should keep it possible to have one speci= fic dynamic > SGI at the maximum level or even at an higher level (ie lower down xen in= ternal SGIs) > for specific use cases (handling hardware errors comes to mind) but this = is ok to make > this possible only by changing xen code or when creating such a specific = driver. Thank you for the detailed feedback regarding the priority handling for dynamic SGIs. Based on Bertrand's suggestions, I would like to propose a more structured approach to interrupt priorities. To avoid having dynamic SGIs share the exact same priority as Xen's internal IPIs, while still ensuring they can preempt normal interrupts, I propose the following hierarchy: #define GIC_PRI_LOWEST 0xf0U #define GIC_PRI_IRQ 0xb0U #define GIC_PRI_DYNAMIC_SGI 0xa0U #define GIC_PRI_IPI 0x90U /* IPIs must preempt normal interrupts */ #define GIC_PRI_HIGHEST 0x80U /* Higher priorities belong to Secure-World *= / Key changes: 1. Shift GIC_PRI_IRQ to 0xb0U: This moves standard interrupts one level down. 2. Introduce GIC_PRI_DYNAMIC_SGI at 0xa0U: This creates a dedicated priority level for dynamic SGIs (like FF-A). This structure ensures that: - Internal Xen IPIs (0x90) remain the highest priority for the hypervisor. - Dynamic SGIs (0xa0) can preempt normal interrupts but cannot interfere with internal Xen signaling. - We stay within the safe range for Xen (starting from 0x80). Does this approach look acceptable to you? In particular, do you see any concerns with shifting the default GIC_PRI_IRQ from 0xa0 to 0xb0 on ARM? If this looks good to you, I will send a v2 with these changes. Best regards, Mykola > > Cheers > Bertrand > From xen-devel-bounces@lists.xenproject.org Wed Jan 14 06:01:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 06:01:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202455.1518008 (Exim 4.92) (envelope-from ) id 1vftwO-0000qG-98; Wed, 14 Jan 2026 06:01:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202455.1518008; Wed, 14 Jan 2026 06:01:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vftwO-0000q9-4D; Wed, 14 Jan 2026 06:01:12 +0000 Received: by outflank-mailman (input) for mailman id 1202455; Wed, 14 Jan 2026 06:01:11 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vftwN-0000pt-GG for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 06:01:11 +0000 Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [2a00:1450:4864:20::22b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6bf2d570-f10e-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 07:01:09 +0100 (CET) Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-382f4aa8dd1so65564061fa.3 for ; Tue, 13 Jan 2026 22:01:09 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6bf2d570-f10e-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768370469; x=1768975269; 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=cCN+j6pdToO7nMul7/ADuNhkHe61P/LGas+RLxrhGzY=; b=JCney5fLnIYbqjPQLJ5bHihEpK+OpHDwof5LOQlkzHoYgwV4LCCQPzfOVLpyrdvcRG MUjSDcbeMcQqjdwF931ZPu/MovABiLtmmzevXnUSv/8uF8ekfGKUcYNmfEfUmpO9nsT9 optQTAiWFy1/MYAIx1wZDh29/rd1aKzZMLYrS6Ehzv7VKJe/gzeHW+6ebOCqTifDO+Uk 8GqzovOPzLeo9kGIz0Nyg2w4827GbdZPC2WNQj5ifHCir3sQZVslvbcc4vmSgjAtVyLc gwym1hCEoxxyQA4OZTz1O5uZLeCpr0pWzDwGG7x5SmByFy51P89swd08yaPLzDUxbZ5G bEug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768370469; x=1768975269; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=cCN+j6pdToO7nMul7/ADuNhkHe61P/LGas+RLxrhGzY=; b=C8m1mcd4NSz+s5mkTVQiQon/AEstR+dEPJhIJPUNYU9w93cR3koCGpAs9FLAwsNtUZ DVnPEEYdaeoywfjC7sNiQW2kDqooON6Ao3vpCIs0St2dG2k6Q0ChtZcOJDYqA5QPz9Bk CKiwAvPE2XmaTXZvTqxtzkMIELwAf0bm7jKVLiXBeAEBK8q5DVH1F3kusGxlfHhY3U28 IHRXP7zvx2ocSBLPjaFGNJYroztNV3v4QJnIDNzoo5xuml/8UohPDa3SL7d2TwGXr69B DMbJIZ2M1+mkgT6pBOBUM+ZV8g59nXPwYrolXvrpzQVYoNReuSiGdHf3mm2ahRmIgYFU 1Vpw== X-Gm-Message-State: AOJu0Yz5JPc4qe0BSLfv6mhHACEibWrZWlzDiL+oocOMI4M5BcTEy/NO ZthLh4/ndfHpPXTlNagiB9iBtCxTF2hdj3/MwUNLPUL6rAVWcKP33oQdDLKpzBedIFRYIaLkdCm cEZ9ng8JeDv1qvt7ryjIuXwFz9tAPsX4OUp5/ X-Gm-Gg: AY/fxX4YKReGMgteyCpTN1Ay6UjegnLC5tk73UTKBGZ/BalFr4nkA0xU73o/W6GKf9B NLLXCExcfnXF6BDk4f7fohSVfNEPB0eKVWi6IayBK7QtCzs8qNbj9Kf6RpajGDWpZNS+1iLV1rq T7SvV+1x/OLm7D+EeD7Hh/z3O/036J5DMfPCnqQP29UzZaSkuY7GH6vVMYmUNBub77t2icggHXH wLiTTdU04c0svhGjiYArraPM709Ac1Eu1R9NfX2cgmALRSIsvAvHxQ837OaMqA+Ql7jGQ== X-Received: by 2002:a2e:9b82:0:b0:382:56ff:5207 with SMTP id 38308e7fff4ca-38360844aefmr3119301fa.36.1768370468523; Tue, 13 Jan 2026 22:01:08 -0800 (PST) MIME-Version: 1.0 References: <10aaed6d-6cb1-4bed-aa8c-5f9761f04fde@suse.com> <35819233-07ba-4e00-8939-74b2f4454250@suse.com> In-Reply-To: <35819233-07ba-4e00-8939-74b2f4454250@suse.com> From: Mykola Kvach Date: Wed, 14 Jan 2026 08:00:00 +0200 X-Gm-Features: AZwV_QhZCemHOV_JLr5xl1H5SbaODGdbkZwpZ5NEJRZUpgEp0-rza_Xm8VQgGx4 Message-ID: Subject: Re: Strange symbols_lookup() behaviour in test-symbols on arm64 CI To: Jan Beulich Cc: Xen-devel , Volodymyr Babchuk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jan, Apologies for the delay in responding. On Mon, Dec 15, 2025 at 1:27=E2=80=AFPM Jan Beulich wro= te: > > On 15.12.2025 12:00, Mykola Kvach wrote: > > On Thu, Dec 11, 2025 at 6:40=E2=80=AFPM Jan Beulich = wrote: > >> > >> On 11.12.2025 17:30, Mykola Kvach wrote: > >>> I have now attached the corresponding build log. > >> > >> Okay, so indeed not a table size change issue here. Then I fear some i= nstrumenting > >> will be needed to at least know what exactly is going wrong. Alternati= vely you could > >> arrange for the intermediate binaries to not be deleted, and make them= available > >> somehow / somewhere for me to see whether by inspection I can gain som= e clue. > > > > I prepared a small patch to keep the intermediate artifacts instead of > > deleting them. > > > > It removes two cleanup commands: > > xen/arch/arm/Makefile: drops rm -f $(@D)/.$(@F).[0-9]* (keeps > > .xen-syms.* intermediates) > > This alone should be sufficient. Understood. I have rerun the build with the cleanup line removed so the intermediate .xen-syms.* files are kept. The build artifacts are available here: https://gitlab.com/xen-project/people/mykola_kvach/xen/-/jobs/12707528457/a= rtifacts/browse/xen/ Best regards, Mykola > > > xen/scripts/Kbuild.include: drops rm -f $(@D)/.cst.$$$$ (keeps > > .cst. used by compare-symbol-tables) > > These can be easily re-created from the ones retained above. (They might = be > of immediate interest - and hence worth keeping - if the comparisons fail= ed, > but you said the build works fine for you even with these comparisons add= ed.) > > Jan > > > Should I gather any other files/logs that would be useful? > > > > > > > > Mykola > > > >> > >> Jan > From xen-devel-bounces@lists.xenproject.org Wed Jan 14 06:02:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 06:02:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202467.1518017 (Exim 4.92) (envelope-from ) id 1vftxC-0001Sm-Hm; Wed, 14 Jan 2026 06:02:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202467.1518017; Wed, 14 Jan 2026 06:02:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vftxC-0001Sf-DX; Wed, 14 Jan 2026 06:02:02 +0000 Received: by outflank-mailman (input) for mailman id 1202467; Wed, 14 Jan 2026 06:02: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 1vftxB-0000XZ-LD for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 06:02:01 +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 8a628944-f10e-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 07:02:00 +0100 (CET) Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-59b77f2e43aso614717e87.1 for ; Tue, 13 Jan 2026 22:02:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8a628944-f10e-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768370519; x=1768975319; 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=kmfIwy+3Yd/UL9Fy1LT6pRmo0zFkYk0GjxD/YNxnqOc=; b=m82MA7Szy+PGeppQfvIdcpE2gx4tWoWWIPcSPZfOJtfUEtCDDfTDmODeChwpVCr1RV TXOwqtB7ieZGUX1QTFnuzP1YL+nbUk9P20HVzbMyM6jWSoAMG70VSHXwosr0tW1d4rPR upSkX3syB9eVYOTUGXHTb6SvSHCY27La1pDceo/Rj/0EV4YyIY5LeCy6CxH73Em55g8O zy6NWpN4BFeD1BGmBxQYm9csTB2HxOhwvz/2MR7bUPoQQ1kh5VEq142uDG3mAOQh+5zE k9b1f7RpokWkSRDxvnGaGfiVWIv3EAH16Ad3icyI3Lqk9KbvpFJ4pPjBDRmQnTNXCyOf i46w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768370519; x=1768975319; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=kmfIwy+3Yd/UL9Fy1LT6pRmo0zFkYk0GjxD/YNxnqOc=; b=uyFnOr1tF2lVewaAGMjAr4GZot56puRfId30FDSKnPG0PqF58o2xktNo+Fae3tNgBB x+4c6L0w6/CRnPchveqkEdwiuZzE27n2zoHE5rEQu7xNjcBibc4RWCHMjJCpT4dNbIwQ G6R2p3fjNzYEkPIGrx1IhWWvmR/5ZfuTBeP+eeIyPn8+4Yxkv52OAyU02v56ommy7J6N c36XW819NeZ/lJEZNA0rjth9hfz6ebpliCNPVEGzFAUZ9/2moAryf5MkspYKXde7qxnX TGJmzRcMI00s2gqgbAm+ZElSZATdVBC8JI/cpJiwbF1vuq7K97MReHQXgVLFGHBwQ/lJ 91vA== X-Gm-Message-State: AOJu0YwK+KeaSvgyLeP/Gzs2iKRJLta1x7TbDIPiVSXen5RIbGlntPM4 zL543XBbAtUgHvnBjmYqehxgZlQ+LFBv5Yrp5kVq/M5NhCXqL2XhcsvhiMqlOIQnA1wCDl5Goc+ QVRxGIf87SsMQ0kiCYcRiwLGfgRdHqWJ5qZdn X-Gm-Gg: AY/fxX47X8b9br3XiuJJo6ya/hphcLgCuV5CUr7YH10XKCFbpZHU5lE7HO0CUPy/TAs ughfX3mz1MCnKFmJCIBcdZY+nkTvfZy2v3KOw2pI6YBULET1RrtsJ2SZKpeLmEMpWIstDp68WdY +QMVrsop9/cWM7h+UlOCHkICtQaee5ekS45sSnvpMzqzgnU9g5DaIzkEYttv9pS0bHPohqVps6J 9TXavIXeuwG536yWyo8uGmqkGVSUL0D1zwrmST7Mnsj8U+26YyQryAahA+Ztosx50jg5w== X-Received: by 2002:a05:6512:4025:b0:59b:572e:83e8 with SMTP id 2adb3069b0e04-59b9943311cmr1691686e87.24.1768370519047; Tue, 13 Jan 2026 22:01:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Mykola Kvach Date: Wed, 14 Jan 2026 08:00:00 +0200 X-Gm-Features: AZwV_QiqmgCRS9eSbDsv3i2VFjiFo9sY8wMm3z9CLCRIVCbUB9maiyfAIMhzYog Message-ID: Subject: Ping: [PATCH v16 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests To: Xen-devel Cc: Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, Friendly ping on this series. I believe all previously received comments have been addressed in this revision, and I=E2=80=99m not aware of any remaining open issues. Could you please take another look when you have a moment? If it looks good= , an Acked-by or Reviewed-by would be very appreciated; otherwise, I=E2=80=99= m happy to iterate on any further feedback. Best regards, Mykola On Fri, Dec 12, 2025 at 3:22=E2=80=AFPM Mykola Kvach wrote: > > 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. arch_domain_resume() stays int to propaga= te > errno-style detail into common logging; preserving the integer keeps the > reason visible and leaves room for future arch-specific failures or riche= r > handling. > > 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 > --- > Changes in V16: > - Refactor error handling in domain_resume: move logging to generic code, > use explicit return code checking. > - Make context clearing conditional on success in arch_domain_resume. > - The 'int' return type is retained for arch_domain_resume for consistenc= y > with other arch hooks and to allow for specific negative error codes. > --- > xen/arch/arm/domain.c | 39 +++++++++ > xen/arch/arm/include/asm/domain.h | 2 + > xen/arch/arm/include/asm/perfc_defn.h | 1 + > xen/arch/arm/include/asm/psci.h | 2 + > xen/arch/arm/include/asm/suspend.h | 27 ++++++ > xen/arch/arm/include/asm/vpsci.h | 5 +- > xen/arch/arm/vpsci.c | 116 +++++++++++++++++++++----- > xen/common/domain.c | 10 +++ > xen/include/xen/suspend.h | 25 ++++++ > 9 files changed, 205 insertions(+), 22 deletions(-) > create mode 100644 xen/arch/arm/include/asm/suspend.h > create mode 100644 xen/include/xen/suspend.h > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > index 47973f99d9..f903e7d4f0 100644 > --- a/xen/arch/arm/domain.c > +++ b/xen/arch/arm/domain.c > @@ -12,6 +12,8 @@ > #include > #include > > +#include > + > #include > #include > #include > @@ -24,10 +26,12 @@ > #include > #include > #include > +#include > #include > #include > #include > #include > +#include > #include > > #include "vpci.h" > @@ -851,6 +855,41 @@ void arch_domain_creation_finished(struct domain *d) > p2m_domain_creation_finished(d); > } > > +int arch_domain_resume(struct domain *d) > +{ > + int rc; > + struct resume_info *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%u, shutdown_code=3D%u\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 notify about= the > + * situation and return without error, allowing the existing logic t= o > + * proceed as expected. > + */ > + if ( !ctx->wake_cpu ) > + { > + dprintk(XENLOG_INFO, "%pd: Wake CPU pointer context was not prov= ided\n", > + d); > + return 0; > + } > + > + rc =3D vpsci_vcpu_up_prepare(ctx->wake_cpu , ctx->ep, ctx->cid); > + if ( !rc ) > + 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 758ad807e4..66b1246892 100644 > --- a/xen/arch/arm/include/asm/domain.h > +++ b/xen/arch/arm/include/asm/domain.h > @@ -5,6 +5,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -126,6 +127,7 @@ struct arch_domain > void *sci_data; > #endif > > + struct resume_info 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_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") > > PERFCOUNTER(vcpu_kick, "vcpu: notify other vcpu") > > 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) > > #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/as= m/suspend.h > new file mode 100644 > index 0000000000..313d03ea59 > --- /dev/null > +++ b/xen/arch/arm/include/asm/suspend.h > @@ -0,0 +1,27 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > + > +#ifndef ARM_SUSPEND_H > +#define ARM_SUSPEND_H > + > +struct domain; > +struct vcpu; > + > +struct resume_info { > + register_t ep; > + register_t cid; > + struct vcpu *wake_cpu; > +}; > + > +int arch_domain_resume(struct domain *d); > + > +#endif /* 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..c4d616ec68 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_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; > > if ( (ctxt =3D alloc_vcpu_guest_context()) =3D=3D NULL ) > - return PSCI_DENIED; > - > - vgic_clear_pending_irqs(v); > + return -ENOMEM; > > 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); > > 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; > > + 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 =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=3D%#"PRIregister", cid=3D%= #"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; > } > > + 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/common/domain.c b/xen/common/domain.c > index 93c71bc766..09ad0a26ee 100644 > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -26,6 +26,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -1374,6 +1375,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 un= der > @@ -1383,6 +1385,13 @@ void domain_resume(struct domain *d) > > spin_lock(&d->shutdown_lock); > > + 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; > > @@ -1393,6 +1402,7 @@ void domain_resume(struct domain *d) > v->paused_for_shutdown =3D 0; > } > > + fail: > spin_unlock(&d->shutdown_lock); > > domain_unpause(d); > diff --git a/xen/include/xen/suspend.h b/xen/include/xen/suspend.h > new file mode 100644 > index 0000000000..528879c2a9 > --- /dev/null > +++ b/xen/include/xen/suspend.h > @@ -0,0 +1,25 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > + > +#ifndef XEN_SUSPEND_H > +#define XEN_SUSPEND_H > + > +#if __has_include() > +#include > +#else > +static inline int arch_domain_resume(struct domain *d) > +{ > + return 0; > +} > +#endif > + > +#endif /* XEN_SUSPEND_H */ > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * tab-width: 4 > + * indent-tabs-mode: nil > + * End: > + */ > -- > 2.43.0 > From xen-devel-bounces@lists.xenproject.org Wed Jan 14 06:23:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 06:23:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202488.1518026 (Exim 4.92) (envelope-from ) id 1vfuHa-0004cJ-8F; Wed, 14 Jan 2026 06:23:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202488.1518026; Wed, 14 Jan 2026 06:23: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 1vfuHa-0004cC-5N; Wed, 14 Jan 2026 06:23:06 +0000 Received: by outflank-mailman (input) for mailman id 1202488; Wed, 14 Jan 2026 06:23:04 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfuHY-0004c6-Nb for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 06:23:04 +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 79e2705a-f111-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 07:23:02 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-b872f1c31f1so330347766b.0 for ; Tue, 13 Jan 2026 22:23:01 -0800 (PST) Received: from ?IPV6:2a00:12d0:af5b:2f01:96c4:9745:9e8c:b1e8? (2a00-12d0-af5b-2f01-96c4-9745-9e8c-b1e8.ip.tng.de. [2a00:12d0:af5b:2f01:96c4:9745:9e8c:b1e8]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b876e9ac655sm11050666b.6.2026.01.13.22.22.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 22:22:59 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 79e2705a-f111-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768371780; x=1768976580; 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=zgKiXIITRssYELTSQGgiSfajJrINKY+aywKjeRICw+M=; b=bY3+n4cHIygVZXvyQUHWBgh75gEJkkEMSn0B3GsbXH8riNUpmtR3S0/gQnWXhWQBJZ pHEcslFv4Ny+EFDaRY6rjiihziQDGDvkByeNTJA9VeuVclVu/HXuemZ6JfaSOnY+EFKP XgkOlxsIsGEX1GfopHs+kRL4wRP5yRM+BKtwQG/7eEBlilKjYpFcIDCZ4RrsyIMwtJao 6D0LIcFgMsHTv+FI2Lk/zaVHo0g4/HdtXOciFrwT3tji9gfO90CNTk4UzAVfcqQPqz8M euBljnoX4uzRWTH7LAC07sf1lepb9AHpf9QvB0aAIfe73r8ZKY/b+/sY2oRfNBu9vJDB vz+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768371780; x=1768976580; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=zgKiXIITRssYELTSQGgiSfajJrINKY+aywKjeRICw+M=; b=dRQJzufa8Bk1TsH6XeLrt0Fr9tFUydoqQIZRpDKzIqNparqNf27xEpIlBgQXxC+sBw rtLiYmMSQAyrznl/8qITYuorJ/4YFIICbScV7Pc8ntD1lLsvSBbAM2P4daXp5fNMzh7E F3jlozh6x3vO5dRAyX1vIIVMZUF3+v2Iv3CZjMbH5bjvV9hy9xTJWLuXT6jEwnOg1Yk7 yV6cjvUTL9jm20EvXoMAcxishFHVEglWnUqdLDhztISavlkqsr2T7jMD9IvwakVDbLgD rnGQsl8Xbfx1CYaZW6XUohOrOQHLVauCzjvz6s/VNY1muhq7VDkXKFEcc6qM1fnRw8YE Rb0A== X-Forwarded-Encrypted: i=1; AJvYcCW6uU0rinu0wd2JUm7lvUu2fntsoyNQR8g9zNyRpcxCZrOqKabCyAuKcZqE3f4iNMCPLhoIYeH4lFM=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy5mCpEdg00HP8C3DInr8jVjWQQ+/b9Mko/6+pRVDJP4UhilG+I uRLDM3WicN/XxXd8Yf0y5MikRoWfEwaMSjRhk11+AuJyeQVXfLXEul4r8LPpIyS5xug= X-Gm-Gg: AY/fxX6oLJhbfSt1taCnjD8b7smWKsuhcVUWo6EfNduhb5zXZNsyIScgRq5AzBLQwvx JglbNAWyxor8kfeb/1HamYwdEksDmDodP6YxSTWSf8HI7GNtum9CpgH9mj5TZqJICXTJp6JbBhx JeUPRsrg0JPgBTpVoUen4p/TNliHUIp74EdBHQ581fMhw43g0qnKk9ylJdx9o0KHeBsJ0uZH4tC ogPRfKBk8OTPsxpv1IrF3s+7bS93uPSscdMP7yfRsuOo6yn+/E/gocd2Ev1PB7WAm7Cwj538nQy 6hKQfBNm2aEVhRWBhzNwJguyRcG6xz25S/SMENNjDj7efdAMiWw8ZF5jyPmfugvJOvtOa/cvKbL uVTID0MFCmxeY55vNdkQGhBpxRO4PAFyeRLelhOvn083GwVbAoXKea+YNq/9b8G77UGzhK4j6fb WPmAecQTae0DTxIzQ3NF4QUWzCoghEgtwSeFpX0gF+kJpDBxq+EeCDXd+0spg2uka8pVqXvklJu +2s5ZRE9VrdxYCZ8zd+02Oj37/owajXFcfrfR4= X-Received: by 2002:a17:906:d54f:b0:b86:ecb2:f4da with SMTP id a640c23a62f3a-b8760fe2186mr133209566b.21.1768371780423; Tue, 13 Jan 2026 22:23:00 -0800 (PST) Message-ID: <9c9a8c75-57c3-48a6-b781-0aef368453a2@suse.com> Date: Wed, 14 Jan 2026 07:22:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] xen: introduce xen_console_io option To: Stefano Stabellini , xen-devel@lists.xenproject.org Cc: oleksandr_tyshchenko@epam.com 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="------------BxzB6l1rEtd0e0hY5JiqLh0R" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------BxzB6l1rEtd0e0hY5JiqLh0R Content-Type: multipart/mixed; boundary="------------X9iQhCeMHKAVpO0nvmfbZsjS"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Stefano Stabellini , xen-devel@lists.xenproject.org Cc: oleksandr_tyshchenko@epam.com Message-ID: <9c9a8c75-57c3-48a6-b781-0aef368453a2@suse.com> Subject: Re: [PATCH v3] xen: introduce xen_console_io option References: In-Reply-To: --------------X9iQhCeMHKAVpO0nvmfbZsjS Content-Type: multipart/mixed; boundary="------------tS2qcCSBNLROX0WXnD5RQhvm" --------------tS2qcCSBNLROX0WXnD5RQhvm Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTQuMDEuMjYgMDA6MjQsIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4gWGVuIGNh biBzdXBwb3J0IGNvbnNvbGVfaW8gaHlwZXJjYWxscyBmb3IgYW55IGRvbWFpbnMsIG5vdCBq dXN0IGRvbTAsDQo+IGRlcGVuZGluZyBvbiBERUJVRyBhbmQgWFNNIHBvbGljaWVzLiBUaGVz ZSBoeXBlcmNhbGxzIGNhbiBiZSB2ZXJ5IHVzZWZ1bA0KPiBmb3IgZGV2ZWxvcG1lbnQgYW5k IGRlYnVnZ2luZy4NCj4gDQo+IEludHJvZHVjZSBhIGtlcm5lbCBjb21tYW5kIGxpbmUgb3B0 aW9uIHhlbl9jb25zb2xlX2lvIHRvIGVuYWJsZSB0aGUNCj4gdXNhZ2Ugb2YgY29uc29sZV9p byBoeXBlcmNhbGxzIGZvciBhbnkgZG9tYWluIHVwb24gcmVxdWVzdC4gV2hlbg0KPiB4ZW5f Y29uc29sZV9pbyBpcyBub3Qgc3BlY2lmaWVkLCB0aGUgY3VycmVudCBiZWhhdmlvciBpcyBy ZXRhaW5lZC4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IFN0ZWZhbm8gU3RhYmVsbGluaSA8c3Rl ZmFuby5zdGFiZWxsaW5pQGFtZC5jb20+DQoNClJldmlld2VkLWJ5OiBKdWVyZ2VuIEdyb3Nz IDxqZ3Jvc3NAc3VzZS5jb20+DQoNCg0KSnVlcmdlbg0K --------------tS2qcCSBNLROX0WXnD5RQhvm 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----- --------------tS2qcCSBNLROX0WXnD5RQhvm-- --------------X9iQhCeMHKAVpO0nvmfbZsjS-- --------------BxzB6l1rEtd0e0hY5JiqLh0R 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/Ey8FAmlnNkMFAwAAAAAACgkQsN6d1ii/Ey8k hggAnLRObFgpjg+ppDbbjs69CoCSQhp+mLcRF7ropjxnDRLmFD2QTrMFyJQJzPKUUyzfof7PqTSf F1++Uwx7tvX+de68mW25YGe2IaZqYTCCAiZY5dSplSI7VI46xqxNk4uYNqCqxiuP8ZiMYQeYRyiX Q03nX3PV+Qf2l2ZdfHVmQjk6rC36GhEfbU+EeWrIHvgBZI3Oi9OvusGoIcfvxD0wvqpInnDulzG6 3CLp4sQuyIrC988jdoud2CubPHLy4R0V++zVX2aVtl8cCK3lAUz7czHM5Nqa4XwdIBgADZlOoc6C bA6+c1O93AgARn1r8d6OQ7wt0+qj7OYpz1yNKAvWDw== =tuxk -----END PGP SIGNATURE----- --------------BxzB6l1rEtd0e0hY5JiqLh0R-- From xen-devel-bounces@lists.xenproject.org Wed Jan 14 07:19:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 07:19:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202506.1518037 (Exim 4.92) (envelope-from ) id 1vfvA9-0002vR-5J; Wed, 14 Jan 2026 07:19:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202506.1518037; Wed, 14 Jan 2026 07: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 1vfvA9-0002vK-2U; Wed, 14 Jan 2026 07:19:29 +0000 Received: by outflank-mailman (input) for mailman id 1202506; Wed, 14 Jan 2026 07: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 1vfvA6-0002vE-OJ for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 07:19:27 +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 5661d759-f119-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 08:19:17 +0100 (CET) Received: from AS9PR04CA0037.eurprd04.prod.outlook.com (2603:10a6:20b:46a::28) by MRWPR08MB11808.eurprd08.prod.outlook.com (2603:10a6:501:9a::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Wed, 14 Jan 2026 07:19:13 +0000 Received: from AMS1EPF00000048.eurprd04.prod.outlook.com (2603:10a6:20b:46a:cafe::e7) by AS9PR04CA0037.outlook.office365.com (2603:10a6:20b:46a::28) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Wed, 14 Jan 2026 07:18:49 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by AMS1EPF00000048.mail.protection.outlook.com (10.167.16.132) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Wed, 14 Jan 2026 07:19:13 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by AM7PR08MB5301.eurprd08.prod.outlook.com (2603:10a6:20b:dd::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Wed, 14 Jan 2026 07:18:08 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%4]) with mapi id 15.20.9499.005; Wed, 14 Jan 2026 07:18: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: 5661d759-f119-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=Ct3dXnM4L90laIjQrP6wQ2mmOtS5T6Kiokdu8dMHBhIP9qodiGXpKJd9k8nBTBZTzJrK9Q4dCTUezZURqKBHoz40JfUW47ggwZkufW13Ksv68cTXojg9EOr9T2XdgnD5C7fcgdzioS2oZ+bBZtOHumOmgl5ebL1scF8Hq6399o8NCyljiZ2f22QWmugDWfxGQDwP8EAs3oJ9zBUnsBGaRHciJxA9xLI5eKCgLgsXesm4qwGHkLWrj9+IA57GzPz4p+Y5L0KEZMkt/lTpwe3G906fY9pG5/M0mpInH1tINIr6Z2Tij/IVC3fEBf/KrMhKOwCzlW+8uaor+nUZNC0Tmg== 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=yOlTYnTSnWsZXgfHDSS1qm5mjToMpwCQTjJRsK5HXwY=; b=uz+YQX7CtFK0fOG3PwFDznXAcmIHf5izagkUXp+r3kl23/K12yp5iBe8dcymUtzln/+lQi8ZUCSWKKPuQdA6OyPJ265QDLFvYakiUh8Yk5ogYHXmhEQZN9iCv9Wuo0MyS+rk2idPMxltJxRPUxku/QvGlc8udBCkTmFglPOCc/ubAbwFYt0tjCWh8MEeNFwiVsDV5xgrfeCk4JNJBgcLO5aRwQVIPAe/92UC5LNUS880QTeFMmVy5y6Wo1KENIntnJE0yxQVcci9IYceyk8VLH9eg4zdsZdLpFjZpye2krjgU7PQ7b+tr/wr7/pO9b4PtVXh3TSqWNlp/WjKMgMi3Q== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=gmail.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yOlTYnTSnWsZXgfHDSS1qm5mjToMpwCQTjJRsK5HXwY=; b=ifXoWA5R5OuQYo3TM8ir4JfH8CQ7hRb+bf7PKNDQnrl1Lz3ff6ornApLqB5aA06t9W1Fp072y58gCTbPxCGlMHkFNdKYS/fxXkjvgn+fxN1Iw4xQFEZyTd9/yEXv2epY8nQqTyQsaSLlBYnYPRUhXRHK7aAyLdDbguL53Ymp6MA= 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=fiaXin1SAy+hIdEehbuUTnRSDp6KV+rieP6tatKIayRQ4jWXy+ZlvVkYxgvgkXMTPTMYoAiZ7bJPaaHFOEokqDsv5xWhU8S7a73mbSLuPh+7o7XIb86KbHxp8ycG2pKBvkJIS4FtwAAh763n/pOY/e24gGZsTAQnyCp6ngow/NyxtpvnWuIk59sEYV247RVM0+x2zPfGISK7nrS/y2lKSiQCyiP2TVvt8a3FT0OXYJ1NaXIeltznTQWrnOrzAe9fdyaWLjlBB94iUuyou+1sgQeXHKj2r/bcUfvDUMRkUqfNFNAgMKBkxu+i6ITUfQWZXVrjsBkcGIokgeTnSHR3Ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yOlTYnTSnWsZXgfHDSS1qm5mjToMpwCQTjJRsK5HXwY=; b=XUWV5es3n4t2IPRwKXROnaf3NxXzITZgsmsj41Y4R7x1n4qC149RZfIr+ZbJntLC1wmIUjQYB7luPYyeJXKm0EiE6z1WuoEy5WIaR41wwBh+YLnBh2HpUvaendS9UO0pRo7i5tC+pqfafbwas07IHp7iigr4hsS4Kj8uDjzG0pnXOTSU5FC9d8bhQZidtSnl8Di6IzX+ENTsMwei9jtSBIuwfxCiuhlWsasrG96uVB6f7Pw3utyB5HFu1QVtpVmVoR4/MukKrD8wKmZ6FVhGsCxe6Pr6lgAucAuXOA6v36t6N7u12gplpvPu1u2mWvckIIO7Ygbq+lW3qxcJjXF6CA== 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=yOlTYnTSnWsZXgfHDSS1qm5mjToMpwCQTjJRsK5HXwY=; b=ifXoWA5R5OuQYo3TM8ir4JfH8CQ7hRb+bf7PKNDQnrl1Lz3ff6ornApLqB5aA06t9W1Fp072y58gCTbPxCGlMHkFNdKYS/fxXkjvgn+fxN1Iw4xQFEZyTd9/yEXv2epY8nQqTyQsaSLlBYnYPRUhXRHK7aAyLdDbguL53Ymp6MA= From: Bertrand Marquis To: Mykola Kvach CC: Julien Grall , "xen-devel@lists.xenproject.org" , Mykola Kvach , Stefano Stabellini , Michal Orzel , Volodymyr Babchuk , Bertrand Marquis Subject: Re: [PATCH] xen/arm: irq: Use appropriate priority for SGIs in setup_irq() Thread-Topic: [PATCH] xen/arm: irq: Use appropriate priority for SGIs in setup_irq() Thread-Index: AQHcHH4xsTo+MqBrSUGlzawFWy7VyrSQKKUAgAWFLACAeYuAgIAA5fEAgEHdygCAABXJAA== Date: Wed, 14 Jan 2026 07:18:08 +0000 Message-ID: <838CA022-64B3-4E4A-9995-E51A620A643A@arm.com> References: <0d0f4689-97e2-408f-91e4-dd59f47bdb95@xen.org> <8133A491-4245-4376-A00C-D6D98C10A2AC@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.300.41.1.7) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|AM7PR08MB5301:EE_|AMS1EPF00000048:EE_|MRWPR08MB11808:EE_ X-MS-Office365-Filtering-Correlation-Id: 87c01a99-3de3-46c5-2215-08de533d3837 x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|376014|366016|10070799003|1800799024|38070700021; X-Microsoft-Antispam-Message-Info-Original: =?utf-8?B?dUtTZXdkRWZyYVhIM1B0LzJuMTNmdk1acFRYdURLY1daOS9DREZkS1ZGelJh?= =?utf-8?B?SFZNSmxMWis0RWZJTG03U1dEa0lLZENqK3BVSFdJck1MRklya2NLd2ZqTXdH?= =?utf-8?B?dGpSVjhpSWNNNnRHRTg1d0NROUg4bEU0ZndmWEdzMUNCVHV0UGE3ZWxMYTVB?= =?utf-8?B?dFgyZjRtRFdFc0RvVHd5WEx4Z1RxRTdxc3BXVzd2OUNMZUdDTExRcUdvVmsx?= =?utf-8?B?MER3d2JXWmUzN2NTQjVTamxhQXdXOGtETUZIU3FQVnJPRi9CZEpmNGpWazZB?= =?utf-8?B?aGRQRG9jM1EvNU9URkhFWWtFMWNBSHllZ1kxZkdQT05tMWpKRHRiVkJVV1Iv?= =?utf-8?B?UkROaGhPVEwzaVQ2aEQwa2RnQkk0aFJBYkJEVmlJQXphM21TeVd0cmNDRjN2?= =?utf-8?B?SVZiMnNHeXl4eVlkSVY5Yk00ckFuMk1JOGpRUi95MVk3aWhkeGtEQnVibVBl?= =?utf-8?B?M3QzTFhhOGpPcDAzZ3VPVWRuT2VaTktXWUkwYXVCdUtLU2RkTzZEVlRuTFpB?= =?utf-8?B?NDZORHl2ckNpRDJlTkUvT1RmMTcwQjIvYUk1OVQwOVRDMCtGQlpFenp5ZVlm?= =?utf-8?B?MUd6ZVd0TnMzNWpKMTVOVHdJWVVnQzE5Y0xQRGl1NkZpRCs3RWxPTFN6eVRY?= =?utf-8?B?amVOSjZyUmhZSGVjQ1J5Q3VtckJ6bFZiZ3p3SHBBcHUvSEhadTFRaUQrYjQ1?= =?utf-8?B?SCtWNmlNUkFwdXZUMGR2Q0VvbEUwOStiaXpqck1MQXdqN2tJTkVLOTFmZDlZ?= =?utf-8?B?dFlyc09tcytkL2lEd09vb2s0MVB4LzR4cU5aUzM1eElrMjdMd0FYb29NT1JE?= =?utf-8?B?b3BoYjZ0WlQ2a1MwVFlseVhMSG9LeXFOdGVTT1YxWUUzaE1FcDNYTVQ0Ujl4?= =?utf-8?B?enY0bC9ucXdNbWcyMzlEcUlHL0JEVGNYREVham11bTJlaEZCWFU0MmQ5aWR1?= =?utf-8?B?ZGRTalNlSVlmUzlVc3Y2UzJlaGxnLzI3b3RTVHJOWkdYQWo0eURoODl0NXVI?= =?utf-8?B?cWNGWVRNTlovaWQ0ZHhKT250dHI0Y2tlVU1OWlI4VUdvREhFUWtEUTFCbFFk?= =?utf-8?B?WU16QnpRaExqM3FTSHF2L0s3bWJDMTc0bExnR2YwNzJSZytsb2Z5M3VTSVVB?= =?utf-8?B?Vkl0VWdZRjJSQ0pYZEJXQmhFMTYzci9wSXg3N01yRXdMVFcyZ2pPaXloQXNa?= =?utf-8?B?TVArbjdCWCtWM080NlU2bjdSYi9rNk9EYVc3bjhUcDVCbm8vOWFoSy9VSGRn?= =?utf-8?B?aUdwQ2RubFFuVzY5NDdlMjJCYm93NkxNakg1bmNLait2VnRFWHZRTDRaVGJX?= =?utf-8?B?cTEvZ1oxRmFyWnVNb0NjbUEzaE81b3VEcnBFbGRpU2pGL3VDbHh6R3JpZUdi?= =?utf-8?B?cXloUWtFRVdaZ3V6dkJEYjZrMFlremQwTjVNQlk2YnFsbUZzQUZlcDFtTC9l?= =?utf-8?B?cVFjcGVJRVdsc1VZNk41UTg5SzA5bjdVU3ZrODRUTzdFWlYxZHEvcWZReWJ6?= =?utf-8?B?QXJidUNzV096SkdVeHJPLzFRSWdWMWVxdENWaEpiMmgxMWtWcWp1djFtVHAy?= =?utf-8?B?elE5Q2QxYnBQNUtpMEVLeVZ0RW0rUThYdnIvaHFUUEQ4Vjd3c24zeXJkN3E2?= =?utf-8?B?N2EyRDM1Sk5HVWJwcFlRaUpSanNCdVZlUEt2YnN0clVDMGJTczZEWmtWSXVr?= =?utf-8?B?M2J2a0dwTnBWVEM3T1pFZUZOeDd0NUs4WmJyVDUwMzRPN1Q5WUdsc3NqdFkv?= =?utf-8?B?Yk1vdk1FQlArSkh2VXRGODUxR2VHUWlhcUpnRDFiR3pyRC8vSnFWWUl0Qmhv?= =?utf-8?B?czRKczAwazFTL0NvTFJBd1kwVWZUNnJHQVRYcTdwOXFUeWpBd1hlbCtLMWx5?= =?utf-8?B?MndDWkIzY2ZwMjNURU9yT0VacDBBUnBUVHpFbXBXWnJUNHk0ZzNMOS85bGJY?= =?utf-8?B?cG5jaWt6cTJtaW5pSUdxZ3ZYRmV5RHhaK09IUXpCS0F3MHRIdVhpVUZTSVUw?= =?utf-8?B?ZW0yaFpvdTgvT016aHZHVEtjTzRldEhYSnJlcVNDWUZPUDJxM0ZURXl1b3hz?= =?utf-8?Q?uN9Hsl?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(10070799003)(1800799024)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="utf-8" Content-ID: <0FBC35ECE1A96342BF527BB262B1F11B@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR08MB5301 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AMS1EPF00000048.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 91a7e3a5-2036-4f2f-56af-08de533d1194 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|35042699022|14060799003|36860700013|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?aU5nNmtEZE5FN01PbEI5VVBHaG5ENjN3dWVxTUREcGQwVDlkWDlSc3plclVJ?= =?utf-8?B?N2RCejN0M2Z0KzErcXFMdEtnOWRLMkZINzdCZ2RPTjFFOGZpM25ZQWVNcWJL?= =?utf-8?B?SXFkK1cyRVl1d0x6TEF6ZVhzanlhdmlGRllFRk1DVTR2d2xhWGY0N09OVmRp?= =?utf-8?B?TWFQZWtqQzlUODJLZUdXNTZBMjlzS3BmSUtYWENZWHJuc2V3ZWZKWnQzY29o?= =?utf-8?B?VVkrdlRVTGo3Z0NoOGpsUUp5RmlQbEJDQURlRUFNSFZDSzhQbzF0VWVzNVdy?= =?utf-8?B?b1RSUFRSdS83YXAydXpCSStsQ3VtakQrUHlLU1pSc1dvcXFjSm1LSmRDdjcr?= =?utf-8?B?RC9ZSlQxNTZSMXNEUFNnU1pRRXNOSjhWTTFXaysreTN4UWNYWHpVY0tWc3JC?= =?utf-8?B?RTJyTHdXSmN3QVZJRDdSRkdaZGFMZ3h6NDFERS9zTFpEQ1g0R3pOWWJ0T1pW?= =?utf-8?B?R0pNc0tmNzlBQ0JjZlo4MU1pU3V2V1FIT0NaRDhwT3EzMEVrMTZLd0NSNlhH?= =?utf-8?B?YWVqU3Q4YjJaemFOT1R0eURiYlRITStsS09DeWRLTzlsTlBLZHU0RU9NMzVV?= =?utf-8?B?VVU1YVMwZHNsb2tBRTdscm1EdFF2bEJMR2UvT1B4VEk2cVlQTFpOQk5hZkl1?= =?utf-8?B?WkMwRlBybk1RVE04TzQrYlVmcXRvak9sOWRaSmZqYjVjWi8zOVV2NnQrbU5E?= =?utf-8?B?bUZwTTZxbGM4ell1emFkcGNrenNWRjI4Yk8yT2tlQzYzYUdmOEJQendzeDIw?= =?utf-8?B?MXV3WE9aYmhGWWxlN3JpYXJyTmtkS2p3K3VFY3VsR0FrS0Y1YjBhNzhrbUx6?= =?utf-8?B?YXpoSlVFQjZMQi9mdXpSVFZFTVRHaUR2a0JWZUtObGhLazlCaFlXMlB4UTBr?= =?utf-8?B?TFliUFZuT2lvOTl6Nko2blQ1ZktuVlROdG9IM24zTHIzSzhycnM1c0dBaE1q?= =?utf-8?B?eVRKS0JHVXd4cDlGdi9ybHlDVkJXc3BMNUc0SFVnaWg5ZXJ2WkxVUTk4ZjNy?= =?utf-8?B?N1dyVGE5RTNEcU9NSDBHSHBRWmlGRk9MU1AvdUM1ODFWSzRqbW5Dc1IzcUhp?= =?utf-8?B?bmZtRkg2SEpTTVlYNU14eG5ZbVhBck0yNFJwSWMzMjZwaG1qRmlGbDBMRFBU?= =?utf-8?B?bkVNWmpFU3VnMXdlMjQxQ3I2bG5FSVNucm1FQ1NEbCsvWndobVR2andMSnR0?= =?utf-8?B?UE53RDAxVmtGYVlEYWFabUNhQURlYlV3UnViblQ4MXZSa2VGU1NHREF1V1lM?= =?utf-8?B?U3ZlT0ZRbDFoS2ZkdStZTkRWYXp4QkgxVHBIRUlXZUtrOFA0b2hEbFJuVDFt?= =?utf-8?B?K2t5RXUzczEzZDFaZXB2aDczWWtIeXhDK2Q0WWR3dTE3WUxEKzd2Rk85bFZS?= =?utf-8?B?TFBkcVI1aGxJbCtaVnI5YjErRWkranZuc1hIaURMK2l6OU0zeUpQdkZxbFBV?= =?utf-8?B?d1Fsc29wNFZVZzRQeGR5VEwzd1JWL3EwcnlVZkE0Nm1xUjVnczFIZzUyN0tZ?= =?utf-8?B?V2VUM1BsbXpWcDVCcnlHK3pYazI2SDhuMmJzYjdCS0lqOTdaZTdraVk4R2RB?= =?utf-8?B?WnVXVGJoUVBlQTNzbEg1bjBPd2M1NWNYSzZIekRCcWsvdXo3Tmg0NGZ4UnBO?= =?utf-8?B?VWMwdWg0aXBzRXg2N3A0bGR5ZjFPUjJCOW5tZlBvUGNzNVovSTFqaGxMUVlZ?= =?utf-8?B?eHdFRFF4cjkvZnc1WDFCRGZZSlNrWmZPc1pkZS9FUUdWNy9abzlxQlErQzAv?= =?utf-8?B?aFZYVm1DNmZTbUJ4Q0VXVmZuUEhZYW9ZbzNpRDdObmVmR0dwRERZRXVmZko3?= =?utf-8?B?bHh2Wmc3MmJHSThZaHg0MVJ2QnU1ZmdoeUtQcnZ1QWU0alBmbzUrMGhVQUo4?= =?utf-8?B?cDhkWGJwQmtHQVE2TTdnMW9NYzZxV1g1dVhzM0FoYWZqRlpVMm1xQ3BLdTRj?= =?utf-8?B?WHhSdEh0bjRjMURZN0lFRzNoQzhlLzZRSzdnMVh2YnJUU0VTaG50bTVrN2g2?= =?utf-8?B?RDhlWGxKcHlEd0JsSHV6QjlHb2FLRlNLWUxScDd4SFFIYyt3ZmNHMWVmZ09G?= =?utf-8?B?bkYycmExTVhBWlkySXFPTHdseTdqWXlRdlcrdlVxNkRRQXVJRGh4NDBlenFj?= =?utf-8?Q?yO4g=3D?= X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(35042699022)(14060799003)(36860700013)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2026 07:19:13.3543 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 87c01a99-3de3-46c5-2215-08de533d3837 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: AMS1EPF00000048.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MRWPR08MB11808 SGkgTXlrb2xhLA0KDQo+IE9uIDE0IEphbiAyMDI2LCBhdCAwNzowMCwgTXlrb2xhIEt2YWNoIDx4 YWtlcC5hbWF0b3BAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IEhpIEJlcnRyYW5kLCBKdWxpZW4s DQo+IA0KPiBGaXJzdCBvZiBhbGwsIHBsZWFzZSBhY2NlcHQgbXkgYXBvbG9naWVzIGZvciB0aGUg ZGVsYXllZCByZXNwb25zZS4NCj4gDQo+IE9uIFdlZCwgRGVjIDMsIDIwMjUgYXQgMTA6MTDigK9B TSBCZXJ0cmFuZCBNYXJxdWlzDQo+IDxCZXJ0cmFuZC5NYXJxdWlzQGFybS5jb20+IHdyb3RlOg0K Pj4gDQo+PiBIaSBKdWxpZW4vTXlrb2xhLA0KPj4gDQo+Pj4gT24gMiBEZWMgMjAyNSwgYXQgMTk6 MjYsIEp1bGllbiBHcmFsbCA8anVsaWVuQHhlbi5vcmc+IHdyb3RlOg0KPj4+IA0KPj4+IEhpLA0K Pj4+IA0KPj4+IFNvcnJ5IGZvciB0aGUgbGF0ZSBhbnN3ZXIuDQo+Pj4gDQo+Pj4gT24gMTYvMDkv MjAyNSAxMToxOSwgTXlrb2xhIEt2YWNoIHdyb3RlOg0KPj4+PiBPbiBTYXQsIFNlcCAxMywgMjAy NSBhdCAxOjAx4oCvQU0gSnVsaWVuIEdyYWxsIDxqdWxpZW5AeGVuLm9yZz4gd3JvdGU6DQo+Pj4+ Pj4gU2lnbmVkLW9mZi1ieTogTXlrb2xhIEt2YWNoIDxteWtvbGFfa3ZhY2hAZXBhbS5jb20+DQo+ Pj4+Pj4gLS0tDQo+Pj4+Pj4gIHhlbi9hcmNoL2FybS9pcnEuYyB8IDggKysrKysrKy0NCj4+Pj4+ PiAgMSBmaWxlIGNoYW5nZWQsIDcgaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQ0KPj4+Pj4+ IA0KPj4+Pj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vaXJxLmMgYi94ZW4vYXJjaC9hcm0v aXJxLmMNCj4+Pj4+PiBpbmRleCAwMmNhODJjMDg5Li4xN2M3YWM5MmI1IDEwMDY0NA0KPj4+Pj4+ IC0tLSBhL3hlbi9hcmNoL2FybS9pcnEuYw0KPj4+Pj4+ICsrKyBiL3hlbi9hcmNoL2FybS9pcnEu Yw0KPj4+Pj4+IEBAIC0zOTcsNyArMzk3LDEzIEBAIGludCBzZXR1cF9pcnEodW5zaWduZWQgaW50 IGlycSwgdW5zaWduZWQgaW50IGlycWZsYWdzLCBzdHJ1Y3QgaXJxYWN0aW9uICpuZXcpDQo+Pj4+ PiBBRkFJSywgd2UgYXJlIG5vdCB1c2luZyBzZXR1cF9pcnEoKSB0byBoYW5kbGUgU0dJcyBiZWNh dXNlIHRoZXkgYXJlIGFsbA0KPj4+Pj4gc3RhdGljIGFuZCBhbHdheXMgZW5hYmxlZC4gQXJlIHlv dSBwbGFubmluZyB0byBoYW5kbGUgZHluYW1pYyBTR0lzPyBJZg0KPj4+Pj4geWVzLCB0aGVuIGNh biB5b3UgcHJvdmlkZSBtb3JlIGRldGFpbHM/QXMgZmFyIGFzIEkga25vdywgdGhlcmUgY2FuIGJl IGF0IGxlYXN0IG9uZSDigJxkeW5hbWlj4oCdIFNHSSBpbiBYZW4uDQo+Pj4+IEFzIGZhciBhcyBJ IGtub3csIHRoZXJlIGlzIGF0IGxlYXN0IG9uZSDigJxkeW5hbWlj4oCdIFNHSSBpbiBYZW4uIEZv cg0KPj4+PiBleGFtcGxlLCBzZWUgZmZhX25vdGlmLmMgaW4gdGhlIGZ1bmN0aW9ucyBmZmFfbm90 aWZfaW5pdF9pbnRlcnJ1cHQNCj4+Pj4gYW5kIGZmYV9ub3RpZl9pbml0LCB3aGljaCBoYW5kbGUg aW5pdGlhbGl6YXRpb24gb2Ygc3VjaCBTR0lzLg0KPj4+IA0KPj4+IEJlcnRyYW5kIGNhbiB5b3Ug Y29tbWVudCBvbiB0aGlzPyBJbiBwYXJ0aWN1bGFyLCBkbyB3ZSB3YW50IHRoZSBGRkEgU0dJcyB0 byBoYXZlIHRoZSBwcmlvcml0eSBvZiB0aGUgaW50ZXJuYWwgb25lcz8NCj4+IA0KPj4gVGhlIGZv bGxvd2luZyBpcyBvbmx5IGFuIGFkdmljZSwgZGVmaW5pdGVseSBub3QgYSByZXF1aXJlbWVudC4g SSB3b3VsZA0KPj4gYmUgb2sgdG8gYWNrIHRoZSBjdXJyZW50IHdheSB0byBkbyB0aGluZ3MgYXMg cmlnaHQgbm93IEZGLUEgaXMgdW5zdXBwb3J0ZWQgYW5kDQo+PiBpcyB0aGUgb25seSBjYXNlIG9m IHVzYWdlIG9mIGR5bmFtaWMgU0dJLg0KPj4gSSB3b3VsZCB0aG91Z2ggcmVxdWlyZSB0byBoYXZl IGEgbG9nIG1lc3NhZ2UgdG8gd2FybiB0aGUgdXNlciB0aGF0IFNHSSB4eA0KPj4gaGFzIHRoZSBz YW1lIHByaW9yaXR5IGFzIHhlbiBpbnRlcm5hbCBpbnRlcnJ1cHRzIGR1cmluZyByZXF1ZXN0X2ly cS4NCj4+IA0KPj4gSGVyZSBpcyB3aGF0IEkgdGhpbms6DQo+PiANCj4+IEZGQSBTR0lzIGNhbiBv bmx5IGJlIGdlbmVyYXRlZCBieSB0aGUgc2VjdXJlIHdvcmxkIGFuZCBpbiBwcmFjdGljZSB0aGV5 IHdpbGwNCj4+IGJlIGdlbmVyYXRlZCBtb3N0bHkgd2hlbiBjb21pbmcgY29taW5nIGJhY2sgZnJv bSB0aGUgc2VjdXJlIHdvcmxkIChlaXRoZXINCj4+IGFmdGVyIGEgcHJlZW1wdGlvbiBvciBvbiBh IHJldHVybiB0byBhbiBzbWMgY2FsbCkgYnV0IG9uZSBjb3VsZCBhbHNvIGJlDQo+PiBnZW5lcmF0 ZWQgZnJvbSB0aGUgc2VjdXJlIHdvcmxkIGZyb20gYW5vdGhlciBjb3JlLCBwcmVlbXB0aW5nIHdo YXRldmVyIHJ1bnMNCj4+IChidXQgc2FtZSB3b3VsZCBvY2N1ciB3aGVuIGFuIGludGVycnVwdCBp cyBkaXJlY3RseSBoYW5kbGVkIGluIHRoZSBzZWN1cmUgd29ybGQpLg0KPj4gDQo+PiBMaW51eCBr ZXJuZWwgaW1wbGVtZW50YXRpb24gaXMgbm90IGxvd2VyaW5nIHRoZSBGRi1BIFNHSSBpbnRlcnJ1 cHQgYXMgZmFyIGFzIEkga25vdy4NCj4+IA0KPj4gSW4gbXkgdmlldyBoYXZpbmcgdGhlIEZGQSBT R0kgaGF2aW5nIHRoZSBzYW1lIHByaW9yaXR5IGFzIGZmYSBpbnRlcm5hbCBTR0kgd291bGQgbWVh bg0KPj4gd2UgaGF2ZSBzb21lIHRydXN0IHRoYXQgdGhlIHNlY3VyZSB3b3JsZCB3aWxsIG5vdCBv dmVybG9hZCB1cy4NCj4+IA0KPj4gQnV0IGluIHJlYWxpdHkgaXQgd291bGQgbWFrZSBzZW5zZSB0 byBoYXZlIGEgcHJpb3JpdHkgb3JkZXJpbmcgbGlrZToNCj4+IC0gWGVuIGludGVybmFsIFNHSXMN Cj4+IC0gRkYtQSBTR0kgKG9yIGFueSBvdGhlciBkeW5hbWljIFNHSSkNCj4+IC0gYW55IG90aGVy IGtpbmQgb2YgaW50ZXJydXB0DQo+PiANCj4+IFNvIHRoYXQgWGVuIGludGVybmFsIFNHSXMgaGF2 ZSB0aGUgaGlnaGVzdCBwcmlvcml0eSwgYnV0IGhhdmluZyBvdGhlciBTR0lzIHN0aWxsIGhhdmlu Zw0KPj4gYSBiZXR0ZXIgcHJpb3JpdHkgdGhhbiBvdGhlciBpbnRlcnJ1cHRzLg0KPj4gDQo+PiBJ biBhbnkgY2FzZSwgd2hhdGV2ZXIgd2UgZG8sIHdlIHNob3VsZCBrZWVwIGl0IHBvc3NpYmxlIHRv IGhhdmUgb25lIHNwZWNpZmljIGR5bmFtaWMNCj4+IFNHSSBhdCB0aGUgbWF4aW11bSBsZXZlbCBv ciBldmVuIGF0IGFuIGhpZ2hlciBsZXZlbCAoaWUgbG93ZXIgZG93biB4ZW4gaW50ZXJuYWwgU0dJ cykNCj4+IGZvciBzcGVjaWZpYyB1c2UgY2FzZXMgKGhhbmRsaW5nIGhhcmR3YXJlIGVycm9ycyBj b21lcyB0byBtaW5kKSBidXQgdGhpcyBpcyBvayB0byBtYWtlDQo+PiB0aGlzIHBvc3NpYmxlIG9u bHkgYnkgY2hhbmdpbmcgeGVuIGNvZGUgb3Igd2hlbiBjcmVhdGluZyBzdWNoIGEgc3BlY2lmaWMg ZHJpdmVyLg0KPiANCj4gVGhhbmsgeW91IGZvciB0aGUgZGV0YWlsZWQgZmVlZGJhY2sgcmVnYXJk aW5nIHRoZSBwcmlvcml0eSBoYW5kbGluZyBmb3INCj4gZHluYW1pYyBTR0lzLiBCYXNlZCBvbiBC ZXJ0cmFuZCdzIHN1Z2dlc3Rpb25zLCBJIHdvdWxkIGxpa2UgdG8gcHJvcG9zZQ0KPiBhIG1vcmUg c3RydWN0dXJlZCBhcHByb2FjaCB0byBpbnRlcnJ1cHQgcHJpb3JpdGllcy4NCj4gDQo+IFRvIGF2 b2lkIGhhdmluZyBkeW5hbWljIFNHSXMgc2hhcmUgdGhlIGV4YWN0IHNhbWUgcHJpb3JpdHkgYXMg WGVuJ3MNCj4gaW50ZXJuYWwgSVBJcywgd2hpbGUgc3RpbGwgZW5zdXJpbmcgdGhleSBjYW4gcHJl ZW1wdCBub3JtYWwgaW50ZXJydXB0cywNCj4gSSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgaGllcmFy Y2h5Og0KPiANCj4gI2RlZmluZSBHSUNfUFJJX0xPV0VTVCAweGYwVQ0KPiAjZGVmaW5lIEdJQ19Q UklfSVJRIDB4YjBVDQo+ICNkZWZpbmUgR0lDX1BSSV9EWU5BTUlDX1NHSSAweGEwVQ0KPiAjZGVm aW5lIEdJQ19QUklfSVBJIDB4OTBVIC8qIElQSXMgbXVzdCBwcmVlbXB0IG5vcm1hbCBpbnRlcnJ1 cHRzICovDQo+ICNkZWZpbmUgR0lDX1BSSV9ISUdIRVNUIDB4ODBVIC8qIEhpZ2hlciBwcmlvcml0 aWVzIGJlbG9uZyB0byBTZWN1cmUtV29ybGQgKi8NCj4gDQo+IA0KPiBLZXkgY2hhbmdlczoNCj4g MS4gU2hpZnQgR0lDX1BSSV9JUlEgdG8gMHhiMFU6IFRoaXMgbW92ZXMgc3RhbmRhcmQgaW50ZXJy dXB0cyBvbmUgbGV2ZWwNCj4gZG93bi4NCj4gMi4gSW50cm9kdWNlIEdJQ19QUklfRFlOQU1JQ19T R0kgYXQgMHhhMFU6IFRoaXMgY3JlYXRlcyBhIGRlZGljYXRlZA0KPiBwcmlvcml0eSBsZXZlbCBm b3IgZHluYW1pYyBTR0lzIChsaWtlIEZGLUEpLg0KPiANCj4gVGhpcyBzdHJ1Y3R1cmUgZW5zdXJl cyB0aGF0Og0KPiAtIEludGVybmFsIFhlbiBJUElzICgweDkwKSByZW1haW4gdGhlIGhpZ2hlc3Qg cHJpb3JpdHkgZm9yIHRoZQ0KPiBoeXBlcnZpc29yLg0KPiAtIER5bmFtaWMgU0dJcyAoMHhhMCkg Y2FuIHByZWVtcHQgbm9ybWFsIGludGVycnVwdHMgYnV0IGNhbm5vdA0KPiBpbnRlcmZlcmUgd2l0 aCBpbnRlcm5hbCBYZW4gc2lnbmFsaW5nLg0KPiAtIFdlIHN0YXkgd2l0aGluIHRoZSBzYWZlIHJh bmdlIGZvciBYZW4gKHN0YXJ0aW5nIGZyb20gMHg4MCkuDQo+IA0KPiBEb2VzIHRoaXMgYXBwcm9h Y2ggbG9vayBhY2NlcHRhYmxlIHRvIHlvdT8gSW4gcGFydGljdWxhciwgZG8geW91IHNlZSBhbnkN Cj4gY29uY2VybnMgd2l0aCBzaGlmdGluZyB0aGUgZGVmYXVsdCBHSUNfUFJJX0lSUSBmcm9tIDB4 YTAgdG8gMHhiMCBvbiBBUk0/DQoNClRoaXMgc291bmRzIHJlYXNvbmFibGUgYnV0IHdvdWxkIGRl ZmluaXRlbHkgbmVlZCBzb21lIGV4dGVuc2l2ZSB0ZXN0aW5nIHRvIHZhbGlkYXRlDQp0aGF0IHdl IGRvIG5vdCBicmVhayBleGlzdGluZyBzeXN0ZW1zIGJhc2VkIG9uIHRoZSBjdXJyZW50IHNjaGVt ZS4NCg0KTWF5YmUgd2Ugc2hvdWxkIGhhdmUgY29tbWFuZCBsaW5lIHBhcmFtZXRlcnMgc28gdGhh dCBhIHN5c3RlbSBzb21laG93IGRlcGVuZGVudA0Kb24gdGhlIG9sZCBwcmlvcml0eSBzY2hlbWUg Y291bGQgaGF2ZSBhIHdheSB0byBjb25maWd1cmUgdGhlIHByaW9yaXRpZXMgd2l0aG91dCBtb2Rp ZnlpbmcNCnhlbiBjb2RlIChnaWNfcHJpX2lycT0sIGdpY19wcmlfc2dpPSwgZ2ljX3ByaV9pcGk9 IHdpdGggdmFsdWVzIDAgdG8gOCB0byBtYWtlIHRoaW5ncyBlYXNpZXIpLA0KdGhpcyB3b3VsZCBn aXZlIGEgd2F5IHRvIGJlIGJhY2t3YXJkIGNvbXBhdGlibGUgZWFzaWx5Lg0KDQpSZWdhcmRpbmcg RkYtQSBpbnRlcnJ1cCBwcmlvcml0aWVzLCBJIGFtIG5vdCBjb21wbGV0ZWx5IHN1cmUgaWYgdGhh dCBzaG91bGQgb3Igbm90IGhhdmUgaGlnaGVyDQpwcmlvcml0eSB0aGFuIG5vcm1hbCBJUlFzIGJ1 dCB0aGF0IGkgY291bGQgbWFrZSBjb25maWd1cmFibGUgdGhyb3VnaCBhIGNvbW1hbmQgbGluZSBw YXJhbWV0ZXIuDQoNCj4gDQo+IElmIHRoaXMgbG9va3MgZ29vZCB0byB5b3UsIEkgd2lsbCBzZW5k IGEgdjIgd2l0aCB0aGVzZSBjaGFuZ2VzLg0KDQpXb3JrcyBmb3IgbWUNCg0KQ2hlZXJzDQpCZXJ0 cmFuZA0KDQoNCg0K From xen-devel-bounces@lists.xenproject.org Wed Jan 14 07:20:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 07:20:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202517.1518048 (Exim 4.92) (envelope-from ) id 1vfvAs-0004NR-Jq; Wed, 14 Jan 2026 07:20:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202517.1518048; Wed, 14 Jan 2026 07:20:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfvAs-0004NK-Eb; Wed, 14 Jan 2026 07:20:14 +0000 Received: by outflank-mailman (input) for mailman id 1202517; Wed, 14 Jan 2026 07:20: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 1vfvAr-0004F6-I8 for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 07:20:13 +0000 Received: from smtp-out3.simply.com (smtp-out3.simply.com [94.231.106.210]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 769c2a52-f119-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 08:20:11 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by smtp.simply.com (Simply.com) with ESMTP id 4drcvb0mT6z1DR2b; Wed, 14 Jan 2026 08:20:11 +0100 (CET) Received: from [192.168.0.25] (h-98-128-223-123.NA.cust.bahnhof.se [98.128.223.123]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.simply.com (Simply.com) with ESMTPSA id 4drcvY6Y97z1DDXQ; Wed, 14 Jan 2026 08:20:09 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 769c2a52-f119-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gaisler.com; s=simplycom2; t=1768375210; bh=+bsSYT5Z1t0Ue69EheEHF7hxKttSFoeDbi3ynLX/3AM=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=W0aE3JG9goSHRurW/f80QzESeYLCdz+1cCdlJriVIGX/Ex1LcwRgyEotsO+y02khS FhemM5xiIXD5RYq2dB6AZqI2t8TT/4xXbpur4a/f7pRBb3H2S+LkwN0GSy2rANeE1D Pgsg4O//8AASht2KWtGRQK2AaPGI5F2sOEAbuLOqCRbtqk7ar1sH1X9impRapmfR68 JsDB2vJ2shh93AI3xLEc371Bwxp3owy1ZLilXgIqaDVXYrndrwpqo9JHNNqgET7dzy tcIDzuCYYnQoxRAZrybVgK7ezKJw0EEplTcQoXefOAkjkbsbESP4Cja7daHOaHwUWK nlNb1c20WwN1w== Message-ID: <6c0a9851-9ec9-4a49-9d77-171f36a78448@gaisler.com> Date: Wed, 14 Jan 2026 08:20:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 04/14] sparc/mm: implement arch_flush_lazy_mmu_mode() To: Kevin Brodsky , linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, Alexander Gordeev , Andrew Morton , Anshuman Khandual , Boris Ostrovsky , Borislav Petkov , Catalin Marinas , Christophe Leroy , Dave Hansen , David Hildenbrand , "David S. Miller" , David Woodhouse , "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 , "Ritesh Harjani (IBM)" , Ryan Roberts , Suren Baghdasaryan , Thomas Gleixner , Venkat Rao Bagalkote , 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, x86@kernel.org References: <20251215150323.2218608-1-kevin.brodsky@arm.com> <20251215150323.2218608-5-kevin.brodsky@arm.com> Content-Language: en-US From: Andreas Larsson In-Reply-To: <20251215150323.2218608-5-kevin.brodsky@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2025-12-15 16:03, Kevin Brodsky wrote: > Upcoming changes to the lazy_mmu API will cause > arch_flush_lazy_mmu_mode() to be called when leaving a nested > lazy_mmu section. > > Move the relevant logic from arch_leave_lazy_mmu_mode() to > arch_flush_lazy_mmu_mode() and have the former call the latter. > > Note: the additional this_cpu_ptr() call on the > arch_leave_lazy_mmu_mode() path will be removed in a subsequent > patch. > > Acked-by: David Hildenbrand > Signed-off-by: Kevin Brodsky > --- > arch/sparc/include/asm/tlbflush_64.h | 2 +- > arch/sparc/mm/tlb.c | 9 ++++++++- > 2 files changed, 9 insertions(+), 2 deletions(-) > > diff --git a/arch/sparc/include/asm/tlbflush_64.h b/arch/sparc/include/asm/tlbflush_64.h > index 8b8cdaa69272..925bb5d7a4e1 100644 > --- a/arch/sparc/include/asm/tlbflush_64.h > +++ b/arch/sparc/include/asm/tlbflush_64.h > @@ -43,8 +43,8 @@ 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_flush_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/sparc/mm/tlb.c b/arch/sparc/mm/tlb.c > index a35ddcca5e76..7b5dfcdb1243 100644 > --- a/arch/sparc/mm/tlb.c > +++ b/arch/sparc/mm/tlb.c > @@ -59,12 +59,19 @@ void arch_enter_lazy_mmu_mode(void) > tb->active = 1; > } > > -void arch_leave_lazy_mmu_mode(void) > +void arch_flush_lazy_mmu_mode(void) > { > struct tlb_batch *tb = this_cpu_ptr(&tlb_batch); > > if (tb->tlb_nr) > flush_tlb_pending(); > +} > + > +void arch_leave_lazy_mmu_mode(void) > +{ > + struct tlb_batch *tb = this_cpu_ptr(&tlb_batch); > + > + arch_flush_lazy_mmu_mode(); > tb->active = 0; > preempt_enable(); > } Acked-by: Andreas Larsson Cheers, Andreas From xen-devel-bounces@lists.xenproject.org Wed Jan 14 07:21:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 07:21:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202527.1518056 (Exim 4.92) (envelope-from ) id 1vfvBt-0004u0-QQ; Wed, 14 Jan 2026 07:21:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202527.1518056; Wed, 14 Jan 2026 07:21:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfvBt-0004tt-Nq; Wed, 14 Jan 2026 07:21:17 +0000 Received: by outflank-mailman (input) for mailman id 1202527; Wed, 14 Jan 2026 07:21:17 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfvBs-0004tk-Vb for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 07:21:16 +0000 Received: from smtp-out3.simply.com (smtp-out3.simply.com [94.231.106.210]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9c2c0307-f119-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 08:21:14 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by smtp.simply.com (Simply.com) with ESMTP id 4drcwp38sWz1DR2b; Wed, 14 Jan 2026 08:21:14 +0100 (CET) Received: from [192.168.0.25] (h-98-128-223-123.NA.cust.bahnhof.se [98.128.223.123]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.simply.com (Simply.com) with ESMTPSA id 4drcwm54NNz1DDXY; Wed, 14 Jan 2026 08:21:12 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9c2c0307-f119-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gaisler.com; s=simplycom2; t=1768375274; bh=USGtV3+n93v8pp6pT/3Zgm6YGfywpo0PJVEBtkCCeSQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=GLYRdRw6BcVYpXpDzS8ZqYhxtT7bZEqyt6FuYL8Og+uuX6KmBzkodf4AAzTgQK8Vj 6QbBYuy/EUx3fCM7vga1p7zdd9seT9SSuJ28fck7TvCAs/Gwc0UpWogq+FDfeMLhxP Q9tIWi9KAy3JY7vvXnVldebdrOSI6/xQmw6aZqkHZJU9FXjDY0poTHU/LzOD1ekgYF 2nFh0u8d2uWVggyereuQ0MAq07iXxOjlDmJmNDlViRxcJ4I2srsAz+uaxP1y7echmT rgWILKmtxf/xBcRfC4IBmOKjPaCa/8zHfl4NRJCZIC9TqeetLFcYzLPvsXlK9du/pk oxIYdU3UlZQgw== Message-ID: <544172e4-cdf7-4789-8cad-4dc3c498e497@gaisler.com> Date: Wed, 14 Jan 2026 08:21:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 12/14] sparc/mm: replace batch->active with is_lazy_mmu_mode_active() To: Kevin Brodsky , linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, Alexander Gordeev , Andrew Morton , Anshuman Khandual , Boris Ostrovsky , Borislav Petkov , Catalin Marinas , Christophe Leroy , Dave Hansen , David Hildenbrand , "David S. Miller" , David Woodhouse , "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 , "Ritesh Harjani (IBM)" , Ryan Roberts , Suren Baghdasaryan , Thomas Gleixner , Venkat Rao Bagalkote , 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, x86@kernel.org, "David Hildenbrand (Red Hat)" References: <20251215150323.2218608-1-kevin.brodsky@arm.com> <20251215150323.2218608-13-kevin.brodsky@arm.com> Content-Language: en-US From: Andreas Larsson In-Reply-To: <20251215150323.2218608-13-kevin.brodsky@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2025-12-15 16:03, Kevin Brodsky wrote: > A per-CPU batch struct is activated when entering lazy MMU mode; its > lifetime is the same as the lazy MMU section (it is deactivated when > leaving the mode). Preemption is disabled in that interval to ensure > that the per-CPU reference remains valid. > > The generic lazy_mmu layer now tracks whether a task is in lazy MMU > mode. We can therefore use the generic helper > is_lazy_mmu_mode_active() to tell whether a batch struct is active > instead of tracking it explicitly. > > Acked-by: David Hildenbrand (Red Hat) > Signed-off-by: Kevin Brodsky > --- > arch/sparc/include/asm/tlbflush_64.h | 1 - > arch/sparc/mm/tlb.c | 9 +-------- > 2 files changed, 1 insertion(+), 9 deletions(-) > > diff --git a/arch/sparc/include/asm/tlbflush_64.h b/arch/sparc/include/asm/tlbflush_64.h > index 4e1036728e2f..6133306ba59a 100644 > --- a/arch/sparc/include/asm/tlbflush_64.h > +++ b/arch/sparc/include/asm/tlbflush_64.h > @@ -12,7 +12,6 @@ struct tlb_batch { > unsigned int hugepage_shift; > struct mm_struct *mm; > unsigned long tlb_nr; > - unsigned long active; > unsigned long vaddrs[TLB_BATCH_NR]; > }; > > diff --git a/arch/sparc/mm/tlb.c b/arch/sparc/mm/tlb.c > index 7b5dfcdb1243..3a852071d260 100644 > --- a/arch/sparc/mm/tlb.c > +++ b/arch/sparc/mm/tlb.c > @@ -52,11 +52,7 @@ void flush_tlb_pending(void) > > void arch_enter_lazy_mmu_mode(void) > { > - struct tlb_batch *tb; > - > preempt_disable(); > - tb = this_cpu_ptr(&tlb_batch); > - tb->active = 1; > } > > void arch_flush_lazy_mmu_mode(void) > @@ -69,10 +65,7 @@ void arch_flush_lazy_mmu_mode(void) > > void arch_leave_lazy_mmu_mode(void) > { > - struct tlb_batch *tb = this_cpu_ptr(&tlb_batch); > - > arch_flush_lazy_mmu_mode(); > - tb->active = 0; > preempt_enable(); > } > > @@ -93,7 +86,7 @@ static void tlb_batch_add_one(struct mm_struct *mm, unsigned long vaddr, > nr = 0; > } > > - if (!tb->active) { > + if (!is_lazy_mmu_mode_active()) { > flush_tsb_user_page(mm, vaddr, hugepage_shift); > global_flush_tlb_page(mm, vaddr); > goto out; Acked-by: Andreas Larsson Cheers, Andreas From xen-devel-bounces@lists.xenproject.org Wed Jan 14 07:26:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 07:26:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202543.1518067 (Exim 4.92) (envelope-from ) id 1vfvH9-0005We-Cp; Wed, 14 Jan 2026 07:26:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202543.1518067; Wed, 14 Jan 2026 07:26:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfvH9-0005WX-9T; Wed, 14 Jan 2026 07:26:43 +0000 Received: by outflank-mailman (input) for mailman id 1202543; Wed, 14 Jan 2026 07:26: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 1vfvH8-0005Vk-7u for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 07:26:42 +0000 Received: from srv1.deutnet.info (srv1.deutnet.info [2a01:4f8:c2c:6846::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5d783c63-f11a-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 08:26:39 +0100 (CET) Received: from [2a01:e0a:186:d20::ebe] by srv1.deutnet.info with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vfvH3-000000043nP-1nS2; Wed, 14 Jan 2026 08:26:37 +0100 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5d783c63-f11a-11f0-9ccf-f158ae23cfc8 Message-ID: <3e937fc7-62bb-404c-9b1b-c4172404bf35@deutnet.info> Date: Wed, 14 Jan 2026 08:26:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH XEN] tools: Update files examples PV&PVH with pygrub. To: Juergen Gross , xen-devel@lists.xenproject.org Cc: Anthony PERARD References: Content-Language: en-US From: Alexandre GRIVEAUX In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 13/01/2026 à 07:15, Juergen Gross a écrit : > On 12.01.26 23:44, Alexandre GRIVEAUX wrote: >> Update files exemples PV&PVH for non direct kernel boot with pygrub. >> >> Signed-off-by: Alexandre GRIVEAUX >> --- >>   tools/examples/xlexample.pvhlinux | 3 +++ >>   tools/examples/xlexample.pvlinux  | 3 +++ >>   2 files changed, 6 insertions(+) >> >> diff --git a/tools/examples/xlexample.pvhlinux >> b/tools/examples/xlexample.pvhlinux >> index 18305b80af..2bdd43c2c5 100644 >> --- a/tools/examples/xlexample.pvhlinux >> +++ b/tools/examples/xlexample.pvhlinux >> @@ -25,6 +25,9 @@ kernel = "/boot/vmlinuz" >>   # Kernel command line options >>   extra = "root=/dev/xvda1" >>   +# Enable to use a grub2 emulation inside guest instead of direct >> kernel boot. > > I don't think this is correct. > > pygrub is running in dom0, not in the guest. > > > Juergen Hello, I doesn't understand your reply, yes pygrub is running on the Dom0, and this goal is to behave like there is a grub2 on the DomU. My wording seem too confuse for you ? You would like this: Enable to use a "grub2 emulation inside guest" instead of direct kernel boot. Or Enable to use a emulation of grub2 inside guest instead of direct kernel boot. Or Enable to use a emulation of grub2 for guest instead of direct kernel boot. For me, using wiktionary: emulate (computing ) of a program or device: to imitate another program or device And according to man page of xl.cfg: > *bootloader="PROGRAM"* > > Run "PROGRAM" to find the kernel image and ramdisk to use. > Normally "PROGRAM" would be "pygrub", which is an emulation of > grub/grub2/syslinux. Either *kernel* or *bootloader* must be > specified for PV guests. And when using it like with a lx start -c .cfg, one of the screen will welcome an user with pygrub. Thanks. From xen-devel-bounces@lists.xenproject.org Wed Jan 14 07:27:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 07:27:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202570.1518077 (Exim 4.92) (envelope-from ) id 1vfvIH-00066l-MJ; Wed, 14 Jan 2026 07:27:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202570.1518077; Wed, 14 Jan 2026 07:27:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfvIH-00066e-JK; Wed, 14 Jan 2026 07:27:53 +0000 Received: by outflank-mailman (input) for mailman id 1202570; Wed, 14 Jan 2026 07:27: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 1vfvIF-00066R-Nz for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 07:27:51 +0000 Received: from smtp-out3.simply.com (smtp-out3.simply.com [94.231.106.210]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 878a97b9-f11a-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 08:27:49 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by smtp.simply.com (Simply.com) with ESMTP id 4drd4P0pSdz1DR2x; Wed, 14 Jan 2026 08:27:49 +0100 (CET) Received: from [192.168.0.25] (h-98-128-223-123.NA.cust.bahnhof.se [98.128.223.123]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.simply.com (Simply.com) with ESMTPSA id 4drd4M6G39z1DDdR; Wed, 14 Jan 2026 08:27:47 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 878a97b9-f11a-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gaisler.com; s=simplycom2; t=1768375668; bh=JoLWp43HOYjwRJyNJsc67cs6D8z3kCKzn/0ykuDh8HA=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=U/MxLTb8zVdLMDfDaOBJbtayShpVqfmLzNsYBnvb64wtspGFMsgZTsrPC3wOoIaLu kywwgDewFftKwA6/dELQHSxQdr6U4eCgbU5b2Xv1hnprAYzD6M28R5fasXD6TsgefO KmidDVQEATQE2TP78neAQZVbaqPpTu5dP9dDpFmN85FmL+ftYaO/Rrjcs0ASbXQD2y W24XwIYxbWV0LDjwKC7UzmRqMIEpZwEprXedMxQaZGak44dCLvtMH16KyfU1yvIpsR AKhv2uLMHt2sI3Gcd+z9fbTl4EjeW/ZFS3inFDmkwr/j1qOMllDjqxmUZAxnM2akcS wSePWEQv/mSSw== Message-ID: <45e4a43d-8996-4296-9df9-d5f2a8efcefd@gaisler.com> Date: Wed, 14 Jan 2026 08:27:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 06/14] mm: introduce CONFIG_ARCH_HAS_LAZY_MMU_MODE To: Kevin Brodsky , linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, Alexander Gordeev , Andrew Morton , Anshuman Khandual , Boris Ostrovsky , Borislav Petkov , Catalin Marinas , Christophe Leroy , Dave Hansen , David Hildenbrand , "David S. Miller" , David Woodhouse , "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 , "Ritesh Harjani (IBM)" , Ryan Roberts , Suren Baghdasaryan , Thomas Gleixner , Venkat Rao Bagalkote , 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, x86@kernel.org References: <20251215150323.2218608-1-kevin.brodsky@arm.com> <20251215150323.2218608-7-kevin.brodsky@arm.com> Content-Language: en-US From: Andreas Larsson In-Reply-To: <20251215150323.2218608-7-kevin.brodsky@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2025-12-15 16:03, Kevin Brodsky wrote: > Architectures currently opt in for implementing lazy_mmu helpers by > defining __HAVE_ARCH_ENTER_LAZY_MMU_MODE. > > In preparation for introducing a generic lazy_mmu layer that will > require storage in task_struct, let's switch to a cleaner approach: > instead of defining a macro, select a CONFIG option. > > This patch introduces CONFIG_ARCH_HAS_LAZY_MMU_MODE and has each > arch select it when it implements lazy_mmu helpers. > __HAVE_ARCH_ENTER_LAZY_MMU_MODE is removed and > relies on the new CONFIG instead. > > On x86, lazy_mmu helpers are only implemented if PARAVIRT_XXL is > selected. This creates some complications in arch/x86/boot/, because > a few files manually undefine PARAVIRT* options. As a result > does not define the lazy_mmu helpers, but this > breaks the build as only defines them if > !CONFIG_ARCH_HAS_LAZY_MMU_MODE. There does not seem to be a clean > way out of this - let's just undefine that new CONFIG too. > > Acked-by: David Hildenbrand > Reviewed-by: Ritesh Harjani (IBM) > Reviewed-by: Ryan Roberts > Signed-off-by: Kevin Brodsky > --- > arch/arm64/Kconfig | 1 + > arch/arm64/include/asm/pgtable.h | 1 - > arch/powerpc/include/asm/book3s/64/tlbflush-hash.h | 2 -- > arch/powerpc/platforms/Kconfig.cputype | 1 + > arch/sparc/Kconfig | 1 + > arch/sparc/include/asm/tlbflush_64.h | 2 -- > arch/x86/Kconfig | 1 + > arch/x86/boot/compressed/misc.h | 1 + > arch/x86/boot/startup/sme.c | 1 + > arch/x86/include/asm/paravirt.h | 1 - > include/linux/pgtable.h | 2 +- > mm/Kconfig | 7 +++++++ > 12 files changed, 14 insertions(+), 7 deletions(-) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 93173f0a09c7..3fb4603c0e16 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -35,6 +35,7 @@ config ARM64 > select ARCH_HAS_KCOV > select ARCH_HAS_KERNEL_FPU_SUPPORT if KERNEL_MODE_NEON > select ARCH_HAS_KEEPINITRD > + select ARCH_HAS_LAZY_MMU_MODE > select ARCH_HAS_MEMBARRIER_SYNC_CORE > select ARCH_HAS_MEM_ENCRYPT > select ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h > index 64d5f1d9cce9..f7d66c261347 100644 > --- a/arch/arm64/include/asm/pgtable.h > +++ b/arch/arm64/include/asm/pgtable.h > @@ -80,7 +80,6 @@ static inline void queue_pte_barriers(void) > } > } > > -#define __HAVE_ARCH_ENTER_LAZY_MMU_MODE > static inline void arch_enter_lazy_mmu_mode(void) > { > /* > diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h > index 2d45f57df169..565c1b7c3eae 100644 > --- a/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h > +++ b/arch/powerpc/include/asm/book3s/64/tlbflush-hash.h > @@ -24,8 +24,6 @@ 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 > - > static inline void arch_enter_lazy_mmu_mode(void) > { > struct ppc64_tlb_batch *batch; > diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype > index 4c321a8ea896..f399917c17bd 100644 > --- a/arch/powerpc/platforms/Kconfig.cputype > +++ b/arch/powerpc/platforms/Kconfig.cputype > @@ -93,6 +93,7 @@ config PPC_BOOK3S_64 > select IRQ_WORK > select PPC_64S_HASH_MMU if !PPC_RADIX_MMU > select KASAN_VMALLOC if KASAN > + select ARCH_HAS_LAZY_MMU_MODE > > config PPC_BOOK3E_64 > bool "Embedded processors" > diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig > index a630d373e645..2bad14744ca4 100644 > --- a/arch/sparc/Kconfig > +++ b/arch/sparc/Kconfig > @@ -112,6 +112,7 @@ config SPARC64 > select NEED_PER_CPU_PAGE_FIRST_CHUNK > select ARCH_SUPPORTS_SCHED_SMT if SMP > select ARCH_SUPPORTS_SCHED_MC if SMP > + select ARCH_HAS_LAZY_MMU_MODE > > config ARCH_PROC_KCORE_TEXT > def_bool y > diff --git a/arch/sparc/include/asm/tlbflush_64.h b/arch/sparc/include/asm/tlbflush_64.h > index 925bb5d7a4e1..4e1036728e2f 100644 > --- a/arch/sparc/include/asm/tlbflush_64.h > +++ b/arch/sparc/include/asm/tlbflush_64.h > @@ -39,8 +39,6 @@ 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 > - > void flush_tlb_pending(void); > void arch_enter_lazy_mmu_mode(void); > void arch_flush_lazy_mmu_mode(void); > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 80527299f859..2427a66cb0fe 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -808,6 +808,7 @@ config PARAVIRT > config PARAVIRT_XXL > bool > depends on X86_64 > + select ARCH_HAS_LAZY_MMU_MODE > > config PARAVIRT_DEBUG > bool "paravirt-ops debugging" > diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h > index fd855e32c9b9..4f86c5903e03 100644 > --- a/arch/x86/boot/compressed/misc.h > +++ b/arch/x86/boot/compressed/misc.h > @@ -11,6 +11,7 @@ > #undef CONFIG_PARAVIRT > #undef CONFIG_PARAVIRT_XXL > #undef CONFIG_PARAVIRT_SPINLOCKS > +#undef CONFIG_ARCH_HAS_LAZY_MMU_MODE > #undef CONFIG_KASAN > #undef CONFIG_KASAN_GENERIC > > diff --git a/arch/x86/boot/startup/sme.c b/arch/x86/boot/startup/sme.c > index e7ea65f3f1d6..b76a7c95dfe1 100644 > --- a/arch/x86/boot/startup/sme.c > +++ b/arch/x86/boot/startup/sme.c > @@ -24,6 +24,7 @@ > #undef CONFIG_PARAVIRT > #undef CONFIG_PARAVIRT_XXL > #undef CONFIG_PARAVIRT_SPINLOCKS > +#undef CONFIG_ARCH_HAS_LAZY_MMU_MODE > > /* > * This code runs before CPU feature bits are set. By default, the > diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h > index b5e59a7ba0d0..13f9cd31c8f8 100644 > --- a/arch/x86/include/asm/paravirt.h > +++ b/arch/x86/include/asm/paravirt.h > @@ -526,7 +526,6 @@ static inline void arch_end_context_switch(struct task_struct *next) > PVOP_VCALL1(cpu.end_context_switch, next); > } > > -#define __HAVE_ARCH_ENTER_LAZY_MMU_MODE > static inline void arch_enter_lazy_mmu_mode(void) > { > PVOP_VCALL0(mmu.lazy_mode.enter); > diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h > index 1abc4a1c3d72..d46d86959bd6 100644 > --- a/include/linux/pgtable.h > +++ b/include/linux/pgtable.h > @@ -235,7 +235,7 @@ static inline int pmd_dirty(pmd_t pmd) > * > * Nesting is not permitted and the mode cannot be used in interrupt context. > */ > -#ifndef __HAVE_ARCH_ENTER_LAZY_MMU_MODE > +#ifndef CONFIG_ARCH_HAS_LAZY_MMU_MODE > static inline void arch_enter_lazy_mmu_mode(void) {} > static inline void arch_leave_lazy_mmu_mode(void) {} > static inline void arch_flush_lazy_mmu_mode(void) {} > diff --git a/mm/Kconfig b/mm/Kconfig > index bd0ea5454af8..62073bd61544 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -1464,6 +1464,13 @@ config PT_RECLAIM > config FIND_NORMAL_PAGE > def_bool n > > +config ARCH_HAS_LAZY_MMU_MODE > + bool > + help > + The architecture uses the lazy MMU mode. This allows changes to > + MMU-related architectural state to be deferred until the mode is > + exited. See for details. > + > source "mm/damon/Kconfig" > > endmenu Acked-by: Andreas Larsson # sparc Cheers, Andreas From xen-devel-bounces@lists.xenproject.org Wed Jan 14 07:44:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 07:44:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202589.1518086 (Exim 4.92) (envelope-from ) id 1vfvXu-0000QM-Up; Wed, 14 Jan 2026 07:44:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202589.1518086; Wed, 14 Jan 2026 07:44:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfvXu-0000QF-SK; Wed, 14 Jan 2026 07:44:02 +0000 Received: by outflank-mailman (input) for mailman id 1202589; Wed, 14 Jan 2026 07:44: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 1vfvXs-0000Q9-MV for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 07:44:00 +0000 Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [2a00:1450:4864:20::541]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c8d900d5-f11c-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 08:43:58 +0100 (CET) Received: by mail-ed1-x541.google.com with SMTP id 4fb4d7f45d1cf-652fdd043f9so3247667a12.1 for ; Tue, 13 Jan 2026 23:43:58 -0800 (PST) Received: from ?IPV6:2a00:12d0:af5b:2f01:96c4:9745:9e8c:b1e8? (2a00-12d0-af5b-2f01-96c4-9745-9e8c-b1e8.ip.tng.de. [2a00:12d0:af5b:2f01:96c4:9745:9e8c:b1e8]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6507b8c4454sm22377242a12.3.2026.01.13.23.43.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 23:43:57 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c8d900d5-f11c-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768376637; x=1768981437; 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=nZBcekoOmtM0omaCckBMLaoIquuqBm2yb/TA/kpHHdw=; b=Dhoxr6BWv6/RKH4J/oGe8osD4nhaadfQjsxR0rHJsHydc1q4hjgE9teO/e2wGRo6yK EFI0tfjfvIr9Vwl34zhdx/X6DU2uCR09Fy4mC9PUMj+I9r9SqwBNaXXmguSNg/1BCcNv DGWaXNXNQYPLp9H3CyBDbj1SRDyfhIIJnH0CcIsK1tvwRcrDJh3SHrEIqqW9adDeOScW vbRH9IlyUJUx1VezQpQmR0gfj9z8KQspkzYJbTOD9RvP6j81kbPtV+PzgJchkFkFaUYT jp2UUU6IzS/DEEuaHncEeipCNpkBgqR3yRAwq7LrWe5wSmpJX/6A98DXUuZI1/ZuF9Kn OePg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768376637; x=1768981437; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nZBcekoOmtM0omaCckBMLaoIquuqBm2yb/TA/kpHHdw=; b=l17LbABMvoXEwBWRCWXvGkwqGGkVSbEC/vu93FPbmGZUaoszya3cjEUYLuhPUgBC4n AJWqabkgPyRMjB5Oq96ZYZlgEAONtZcP+sdMkVuCHujXrch4nrE8sQZdjra/FAehHHDS hppKB/YuIgausHj61BIApC7qlPVeFpZQmTZcUsszRVjVkFTVoUKyZaE38GQnCb0VYC+4 0h17acCe78yrH7EbWKJL9Ji50YlwgyoTMjxvaLrbGnw3JqIJ3EQwcZYw86A724jcyBsk fmNKp9vB3KbSukXhetm/+NZeUUGQqNgpTZEnozqP5+xZvOQWswLixY0V+uqs2GAvHwHv 0Thw== X-Forwarded-Encrypted: i=1; AJvYcCW61RGoRorAtFZ1jIHdSykgIAUxTWNLKYgdHaIOXBCufuVTsSek4TZYGtnxkMvLh+X44cKt166m4mU=@lists.xenproject.org X-Gm-Message-State: AOJu0YzNpIQfBsLkqZ6T51hIfkyKJZVYtnxOvOymV2h1AKhqMnc4q5Bi hzEvez7W9u9PJ/h6eFLlgdjSbK2CPdI/gtwdSK6DK1E7uh3obd3/Ko0gvTODlstCQKI1N1bBGmX ACPzP8+vBwQ== X-Gm-Gg: AY/fxX62GZXqaFhYezdyS9rXIHCzim9WdeLs4+9/hkf01Ng4EpsascD95P2x7Lgj/IM myyEn4sf/QnEX2WbT2JLBW9imRr9HNHO9Psbpl5a2cWgtulWYiNAefx4W8uY3EXg/qeM8ga6D7b WItgHAklRA1Xm2g97JcQx0ePT8y0eo9fXT13XLHuA2EFDh/RdCrKvWhW+CY464u1Q2hfsFLU4QN xGEEXFChZYU/SEGoFKyUUnfNL6HkgseCheTHQHbojlR9AXa4BoQuNLKRXjtqqn4iVS56RTKCfGh ogQw4AXSHzqYaku1RvZs14nott7vxAa1f3XE1QTLyGd5XO+p4yJEBZiACWAjgVLpdAJ3JbDAuhp ywyT+yhUdKxt3xFG84ursKGvcnl3xYPScnIwl8wcpPpxW5zIrL2YG2JOkxCHA0M31kFagy0PXQc XVqsxJDxvJ89QhgNf2RxRYbRWrOrZ8QZCdj5TnQUfbcOTTSNHg1nsxfgCfbWkZkybx3Jm74Ha0N fgcNEmxxjcNW8K7W3iRiH1SPlxsM9oNB+xQgTY= X-Received: by 2002:a05:6402:278e:b0:64b:3f56:55c9 with SMTP id 4fb4d7f45d1cf-653ee1b06f9mr906340a12.26.1768376637459; Tue, 13 Jan 2026 23:43:57 -0800 (PST) Message-ID: <4a572d26-a58c-4119-b8b2-006e4e1eea89@suse.com> Date: Wed, 14 Jan 2026 08:43:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH XEN] tools: Update files examples PV&PVH with pygrub. To: Alexandre GRIVEAUX , xen-devel@lists.xenproject.org Cc: Anthony PERARD References: <3e937fc7-62bb-404c-9b1b-c4172404bf35@deutnet.info> 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: <3e937fc7-62bb-404c-9b1b-c4172404bf35@deutnet.info> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------A0DlLc8TqXrk8i0VLuch07h4" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------A0DlLc8TqXrk8i0VLuch07h4 Content-Type: multipart/mixed; boundary="------------yMmA46rM5fOCVXy6dq1hREsv"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Alexandre GRIVEAUX , xen-devel@lists.xenproject.org Cc: Anthony PERARD Message-ID: <4a572d26-a58c-4119-b8b2-006e4e1eea89@suse.com> Subject: Re: [PATCH XEN] tools: Update files examples PV&PVH with pygrub. References: <3e937fc7-62bb-404c-9b1b-c4172404bf35@deutnet.info> In-Reply-To: <3e937fc7-62bb-404c-9b1b-c4172404bf35@deutnet.info> --------------yMmA46rM5fOCVXy6dq1hREsv Content-Type: multipart/mixed; boundary="------------qc1mysV7e0pTh740olARuGJa" --------------qc1mysV7e0pTh740olARuGJa Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTQuMDEuMjYgMDg6MjYsIEFsZXhhbmRyZSBHUklWRUFVWCB3cm90ZToNCj4gTGUgMTMv MDEvMjAyNiDDoCAwNzoxNSwgSnVlcmdlbiBHcm9zcyBhIMOpY3JpdMKgOg0KPj4gT24gMTIu MDEuMjYgMjM6NDQsIEFsZXhhbmRyZSBHUklWRUFVWCB3cm90ZToNCj4+PiBVcGRhdGUgZmls ZXMgZXhlbXBsZXMgUFYmUFZIIGZvciBub24gZGlyZWN0IGtlcm5lbCBib290IHdpdGggcHln cnViLg0KPj4+DQo+Pj4gU2lnbmVkLW9mZi1ieTogQWxleGFuZHJlIEdSSVZFQVVYIDxhZ3Jp dmVhdXhAZGV1dG5ldC5pbmZvPg0KPj4+IC0tLQ0KPj4+IMKgIHRvb2xzL2V4YW1wbGVzL3hs ZXhhbXBsZS5wdmhsaW51eCB8IDMgKysrDQo+Pj4gwqAgdG9vbHMvZXhhbXBsZXMveGxleGFt cGxlLnB2bGludXjCoCB8IDMgKysrDQo+Pj4gwqAgMiBmaWxlcyBjaGFuZ2VkLCA2IGluc2Vy dGlvbnMoKykNCj4+Pg0KPj4+IGRpZmYgLS1naXQgYS90b29scy9leGFtcGxlcy94bGV4YW1w bGUucHZobGludXggYi90b29scy9leGFtcGxlcy8gDQo+Pj4geGxleGFtcGxlLnB2aGxpbnV4 DQo+Pj4gaW5kZXggMTgzMDViODBhZi4uMmJkZDQzYzJjNSAxMDA2NDQNCj4+PiAtLS0gYS90 b29scy9leGFtcGxlcy94bGV4YW1wbGUucHZobGludXgNCj4+PiArKysgYi90b29scy9leGFt cGxlcy94bGV4YW1wbGUucHZobGludXgNCj4+PiBAQCAtMjUsNiArMjUsOSBAQCBrZXJuZWwg PSAiL2Jvb3Qvdm1saW51eiINCj4+PiDCoCAjIEtlcm5lbCBjb21tYW5kIGxpbmUgb3B0aW9u cw0KPj4+IMKgIGV4dHJhID0gInJvb3Q9L2Rldi94dmRhMSINCj4+PiDCoCArIyBFbmFibGUg dG8gdXNlIGEgZ3J1YjIgZW11bGF0aW9uIGluc2lkZSBndWVzdCBpbnN0ZWFkIG9mIGRpcmVj dCBrZXJuZWwgYm9vdC4NCj4+DQo+PiBJIGRvbid0IHRoaW5rIHRoaXMgaXMgY29ycmVjdC4N Cj4+DQo+PiBweWdydWIgaXMgcnVubmluZyBpbiBkb20wLCBub3QgaW4gdGhlIGd1ZXN0Lg0K Pj4NCj4+DQo+PiBKdWVyZ2VuDQo+IA0KPiBIZWxsbywNCj4gDQo+IA0KPiBJIGRvZXNuJ3Qg dW5kZXJzdGFuZCB5b3VyIHJlcGx5LCB5ZXMgcHlncnViIGlzIHJ1bm5pbmcgb24gdGhlIERv bTAsIGFuZCB0aGlzIA0KPiBnb2FsIGlzIHRvIGJlaGF2ZSBsaWtlIHRoZXJlIGlzIGEgZ3J1 YjIgb24gdGhlIERvbVUuDQoNClllcy4gVGhpcyBpcyB3aHkgSSBkb24ndCBsaWtlIHRoZSB3 b3JkaW5nICJpbnNpZGUgZ3Vlc3QiLCB3aGljaCBpcyBqdXN0IG5vdA0KdHJ1ZS4NCg0KUGxl YXNlIGJlIGF3YXJlIHRoYXQgd2UgYXJlIHRyeWluZyB0byBwaGFzZSBvdXQgcHlncnViLCBh cyBpdCB3aWRlbnMgdGhlDQphdHRhY2sgc3VyZmFjZSBvZiBkb20wIGZyb20gYSBndWVzdC4g cHlncnViIG5lZWRzIHRvIGxvb2sgaW50byBndWVzdA0KY29udHJvbGxlZCBmaWxlIHN5c3Rl bXMsIHNvIGFueSBidWcgaW4gdGhlIHJlbGF0ZWQgY29kZSAoZS5nLiBmYWlsdXJlIHRvDQpo YW5kbGUgYSBjb3JydXB0ZWQgb3IgbWFsaWNpb3VzbHkgbW9kaWZpZWQgZmlsZSBzeXN0ZW0p IG1pZ2h0IHJlc3VsdCBpbg0Kc2VjdXJpdHkgaXNzdWVzIGxpa2UgY29kZSBpbmplY3Rpb24u DQoNClNvIEknbSBvbiB0aGUgZWRnZSB3aGV0aGVyIHdlIHJlYWxseSBzaG91bGQgbWFrZSBp dCBlYXNpZXIgdG8gdXNlIHB5Z3J1Yi4NCg0KDQpKdWVyZ2VuDQo= --------------qc1mysV7e0pTh740olARuGJa 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----- --------------qc1mysV7e0pTh740olARuGJa-- --------------yMmA46rM5fOCVXy6dq1hREsv-- --------------A0DlLc8TqXrk8i0VLuch07h4 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/Ey8FAmlnSTwFAwAAAAAACgkQsN6d1ii/Ey9N 1AgAnrRcwgQrvWr2yn21BhZe+XA+55AJR+ANVCiK0ixnREg01Vc1VLblNpM1MsqSLH1iHIBVp+XJ twVRoLKrd8qSsjnNfnxLlK85YtTrBRrysbzjAQNYAlnazfAUFVvzcHjOzYHiAkgJQDCMZsyyydSD Kp/uGLaS8cz5ZW4dlR0Yt2Cz0PLvi5gVD6jjuh7MFZRHnkoC8C6qg69BLx4kJNWwVk06AZXxa3Lv LDFY4U27ODc/xekNF+y9DBigdhJwvdEIpfiGLpJZeeNuRhQsJ4SLEthMqgMB4vOEqgXOoCn3arTw 2u1yM7qo8zURj8w2QAIrbH6KHWdgvv7V18Itv9KoJA== =EI1V -----END PGP SIGNATURE----- --------------A0DlLc8TqXrk8i0VLuch07h4-- From xen-devel-bounces@lists.xenproject.org Wed Jan 14 07:52:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 07:52:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202604.1518097 (Exim 4.92) (envelope-from ) id 1vfvfX-00026s-SG; Wed, 14 Jan 2026 07:51:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202604.1518097; Wed, 14 Jan 2026 07:51:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfvfX-00026l-Ot; Wed, 14 Jan 2026 07:51:55 +0000 Received: by outflank-mailman (input) for mailman id 1202604; Wed, 14 Jan 2026 07:51: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 1vfvfW-00026f-4x for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 07:51:54 +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 e3bf3099-f11d-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 08:51:52 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id DD66D33688; Wed, 14 Jan 2026 07:51:50 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id BE8AE3EA63; Wed, 14 Jan 2026 07:51: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 InzOLBZLZ2lDLwAAD6G6ig (envelope-from ); Wed, 14 Jan 2026 07:51:50 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e3bf3099-f11d-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1768377111; 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=5QzQ3pX9jcY8TtdldB9SckMYIraUVSsrfoex7nqahqA=; b=crNqdH/MY8ECyROJ7FGlH1Vto7hxXWxrOhZN6mj0MyrprWJZmXZuOI+5fHbhsLs6R81zmp c2d2NVxAHpRs2MwOEsgTPm7APl8O4McEWECiQaujvEOa2HDNzhCnckDU9w+ahjET08fKKr SI9lo+vVqYqNGF4ZAFauwhwlAJndaqw= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1768377110; 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=5QzQ3pX9jcY8TtdldB9SckMYIraUVSsrfoex7nqahqA=; b=Oq83Pk99pXNvDYF1Jrw6UWZ+9wX0+rabzlld81uirZRXx6aMzDDtnwfSeEzuQm3+D1ztqO g9D74pUjQKimaoXu6PkjmrKBO7hpt5by5qwEjKB1MqKGxy/PNwmde4q6J47hj/NBUdAdHn XVo05GaS920klhlD7ILgSO3AbdkkjB4= Message-ID: <2d70de1d-e3bb-48e5-9edc-283121806d83@suse.com> Date: Wed, 14 Jan 2026 08:51:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH XEN] tools: Update files examples PV&PVH with pygrub. From: Juergen Gross To: Alexandre GRIVEAUX , xen-devel@lists.xenproject.org Cc: Anthony PERARD References: <3e937fc7-62bb-404c-9b1b-c4172404bf35@deutnet.info> <4a572d26-a58c-4119-b8b2-006e4e1eea89@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: <4a572d26-a58c-4119-b8b2-006e4e1eea89@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------T5Rf0k9rgl4S9UiZr2OshQgT" X-Spam-Score: -6.20 X-Spamd-Result: default: False [-6.20 / 50.00]; BAYES_HAM(-3.00)[100.00%]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; NEURAL_HAM_SHORT(-0.20)[-1.000]; 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)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,imap1.dmz-prg2.suse.org:helo]; HAS_ATTACHMENT(0.00)[] X-Spam-Level: X-Spam-Flag: NO This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------T5Rf0k9rgl4S9UiZr2OshQgT Content-Type: multipart/mixed; boundary="------------G1PTU2JlEUR00ME7itsfJBII"; protected-headers="v1" From: Juergen Gross To: Alexandre GRIVEAUX , xen-devel@lists.xenproject.org Cc: Anthony PERARD Message-ID: <2d70de1d-e3bb-48e5-9edc-283121806d83@suse.com> Subject: Re: [PATCH XEN] tools: Update files examples PV&PVH with pygrub. References: <3e937fc7-62bb-404c-9b1b-c4172404bf35@deutnet.info> <4a572d26-a58c-4119-b8b2-006e4e1eea89@suse.com> In-Reply-To: <4a572d26-a58c-4119-b8b2-006e4e1eea89@suse.com> --------------G1PTU2JlEUR00ME7itsfJBII Content-Type: multipart/mixed; boundary="------------Vl3TjEfXs3EWwY9xbK5FItef" --------------Vl3TjEfXs3EWwY9xbK5FItef Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTQuMDEuMjYgMDg6NDMsIErDvHJnZW4gR3Jvw58gd3JvdGU6DQo+IE9uIDE0LjAxLjI2 IDA4OjI2LCBBbGV4YW5kcmUgR1JJVkVBVVggd3JvdGU6DQo+PiBMZSAxMy8wMS8yMDI2IMOg IDA3OjE1LCBKdWVyZ2VuIEdyb3NzIGEgw6ljcml0wqA6DQo+Pj4gT24gMTIuMDEuMjYgMjM6 NDQsIEFsZXhhbmRyZSBHUklWRUFVWCB3cm90ZToNCj4+Pj4gVXBkYXRlIGZpbGVzIGV4ZW1w bGVzIFBWJlBWSCBmb3Igbm9uIGRpcmVjdCBrZXJuZWwgYm9vdCB3aXRoIHB5Z3J1Yi4NCj4+ Pj4NCj4+Pj4gU2lnbmVkLW9mZi1ieTogQWxleGFuZHJlIEdSSVZFQVVYIDxhZ3JpdmVhdXhA ZGV1dG5ldC5pbmZvPg0KPj4+PiAtLS0NCj4+Pj4gwqAgdG9vbHMvZXhhbXBsZXMveGxleGFt cGxlLnB2aGxpbnV4IHwgMyArKysNCj4+Pj4gwqAgdG9vbHMvZXhhbXBsZXMveGxleGFtcGxl LnB2bGludXjCoCB8IDMgKysrDQo+Pj4+IMKgIDIgZmlsZXMgY2hhbmdlZCwgNiBpbnNlcnRp b25zKCspDQo+Pj4+DQo+Pj4+IGRpZmYgLS1naXQgYS90b29scy9leGFtcGxlcy94bGV4YW1w bGUucHZobGludXggYi90b29scy9leGFtcGxlcy8gDQo+Pj4+IHhsZXhhbXBsZS5wdmhsaW51 eA0KPj4+PiBpbmRleCAxODMwNWI4MGFmLi4yYmRkNDNjMmM1IDEwMDY0NA0KPj4+PiAtLS0g YS90b29scy9leGFtcGxlcy94bGV4YW1wbGUucHZobGludXgNCj4+Pj4gKysrIGIvdG9vbHMv ZXhhbXBsZXMveGxleGFtcGxlLnB2aGxpbnV4DQo+Pj4+IEBAIC0yNSw2ICsyNSw5IEBAIGtl cm5lbCA9ICIvYm9vdC92bWxpbnV6Ig0KPj4+PiDCoCAjIEtlcm5lbCBjb21tYW5kIGxpbmUg b3B0aW9ucw0KPj4+PiDCoCBleHRyYSA9ICJyb290PS9kZXYveHZkYTEiDQo+Pj4+IMKgICsj IEVuYWJsZSB0byB1c2UgYSBncnViMiBlbXVsYXRpb24gaW5zaWRlIGd1ZXN0IGluc3RlYWQg b2YgZGlyZWN0IGtlcm5lbCANCj4+Pj4gYm9vdC4NCj4+Pg0KPj4+IEkgZG9uJ3QgdGhpbmsg dGhpcyBpcyBjb3JyZWN0Lg0KPj4+DQo+Pj4gcHlncnViIGlzIHJ1bm5pbmcgaW4gZG9tMCwg bm90IGluIHRoZSBndWVzdC4NCj4+Pg0KPj4+DQo+Pj4gSnVlcmdlbg0KPj4NCj4+IEhlbGxv LA0KPj4NCj4+DQo+PiBJIGRvZXNuJ3QgdW5kZXJzdGFuZCB5b3VyIHJlcGx5LCB5ZXMgcHln cnViIGlzIHJ1bm5pbmcgb24gdGhlIERvbTAsIGFuZCB0aGlzIA0KPj4gZ29hbCBpcyB0byBi ZWhhdmUgbGlrZSB0aGVyZSBpcyBhIGdydWIyIG9uIHRoZSBEb21VLg0KPiANCj4gWWVzLiBU aGlzIGlzIHdoeSBJIGRvbid0IGxpa2UgdGhlIHdvcmRpbmcgImluc2lkZSBndWVzdCIsIHdo aWNoIGlzIGp1c3Qgbm90DQo+IHRydWUuDQo+IA0KPiBQbGVhc2UgYmUgYXdhcmUgdGhhdCB3 ZSBhcmUgdHJ5aW5nIHRvIHBoYXNlIG91dCBweWdydWIsIGFzIGl0IHdpZGVucyB0aGUNCj4g YXR0YWNrIHN1cmZhY2Ugb2YgZG9tMCBmcm9tIGEgZ3Vlc3QuIHB5Z3J1YiBuZWVkcyB0byBs b29rIGludG8gZ3Vlc3QNCj4gY29udHJvbGxlZCBmaWxlIHN5c3RlbXMsIHNvIGFueSBidWcg aW4gdGhlIHJlbGF0ZWQgY29kZSAoZS5nLiBmYWlsdXJlIHRvDQo+IGhhbmRsZSBhIGNvcnJ1 cHRlZCBvciBtYWxpY2lvdXNseSBtb2RpZmllZCBmaWxlIHN5c3RlbSkgbWlnaHQgcmVzdWx0 IGluDQo+IHNlY3VyaXR5IGlzc3VlcyBsaWtlIGNvZGUgaW5qZWN0aW9uLg0KPiANCj4gU28g SSdtIG9uIHRoZSBlZGdlIHdoZXRoZXIgd2UgcmVhbGx5IHNob3VsZCBtYWtlIGl0IGVhc2ll ciB0byB1c2UgcHlncnViLg0KDQpPbmUgZnVydGhlciBub3RlOg0KDQpUaGUgb25seSByZWFs IGFkdmFudGFnZSBvZiBweWdydWIgaXMgaXRzIGFiaWxpdHkgdG8gZGV0ZXJtaW5lIHdoZXRo ZXIgdG8NCmNyZWF0ZSBhIDMyLSBvciA2NC1iaXQgUFYgZ3Vlc3QgZGVwZW5kaW5nIG9uIHRo ZSBrZXJuZWwgc2VsZWN0ZWQuDQoNCkFzIDMyLWJpdCBQViBtb2RlIGlzbid0IHN1cHBvcnRl ZCBieSB0aGUgTGludXgga2VybmVsIHNpbmNlIHNldmVyYWwgeWVhcnMgbm93LA0KdGhpcyBm ZWF0dXJlIG9mIHB5Z3J1YiBpcyBtb3N0bHkgaW50ZXJlc3RpbmcgZm9yIHZlcnkgZmV3IGxl Z2FjeSBndWVzdHMgd2hpY2gNCmNhbiBiZSB1c2VkIHdpdGggMzItIE9SIDY0LWJpdCBQViBr ZXJuZWxzLg0KDQpGb3IgbW9zdCB1c2UgY2FzZXMgaXQgaXMgbXVjaCBiZXR0ZXIgdG8gdXNl IHRoZSBQViBvciBQVkggdmFyaWFudCBvZiBncnViMiwNCndoaWNoIHdpbGwgcmVhbGx5IHJ1 biBpbnNpZGUgdGhlIGd1ZXN0Lg0KDQoNCkp1ZXJnZW4NCg== --------------Vl3TjEfXs3EWwY9xbK5FItef 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----- --------------Vl3TjEfXs3EWwY9xbK5FItef-- --------------G1PTU2JlEUR00ME7itsfJBII-- --------------T5Rf0k9rgl4S9UiZr2OshQgT 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/Ey8FAmlnSxYFAwAAAAAACgkQsN6d1ii/Ey96 zAgAhUylUnRgJ5TOP4zc0iMXBo0NkIdw9BOjsWfeO3l1rF0jcAkZjN/EoAZYXsDPDSrylKjM0i6H ByoPH7Dm4LIWQv3vWfizokfLWBvbPF35qUUzpa2Zx6XCcvCGRgkRMUVtDPU4ddD3EqA/GzJ7Rq/4 PDAaa2/eXT4zj1uTQRw4RJ9Z3Qqmt4xq0QcNQb97eAkUou+Y9TWGg7SbmkkvwiSSRZb1mXrru+vq rQnFJ89ezvhzsJUqKi/eQLRhfxGdsQhwAzvzU973M6vsIp43yKqHFeATwvGplrNZxph/3T1ECV0U QWGZoOrfOvkEgEaYUvYbQJFqapS/aJI19eQRTwX0NQ== =hGwQ -----END PGP SIGNATURE----- --------------T5Rf0k9rgl4S9UiZr2OshQgT-- From xen-devel-bounces@lists.xenproject.org Wed Jan 14 08:20:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 08:20:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202627.1518107 (Exim 4.92) (envelope-from ) id 1vfw7J-0006gr-AR; Wed, 14 Jan 2026 08:20:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202627.1518107; Wed, 14 Jan 2026 08:20:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfw7J-0006gk-7Q; Wed, 14 Jan 2026 08:20:37 +0000 Received: by outflank-mailman (input) for mailman id 1202627; Wed, 14 Jan 2026 08:20: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 1vfw7H-0006ge-Um for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 08:20:35 +0000 Received: from srv1.deutnet.info (srv1.deutnet.info [2a01:4f8:c2c:6846::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e59f911c-f121-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 09:20:34 +0100 (CET) Received: from [2a01:e0a:186:d20::ebe] by srv1.deutnet.info with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vfw7E-0000000441y-1uz6; Wed, 14 Jan 2026 09:20:32 +0100 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e59f911c-f121-11f0-b15e-2bf370ae4941 Content-Type: multipart/alternative; boundary="------------KHFGdDkTUPn9EHSBx1BsbyfN" Message-ID: Date: Wed, 14 Jan 2026 09:20:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH XEN] tools: Update files examples PV&PVH with pygrub. To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , xen-devel@lists.xenproject.org Cc: Anthony PERARD References: <3e937fc7-62bb-404c-9b1b-c4172404bf35@deutnet.info> <4a572d26-a58c-4119-b8b2-006e4e1eea89@suse.com> Content-Language: en-US From: Alexandre GRIVEAUX In-Reply-To: <4a572d26-a58c-4119-b8b2-006e4e1eea89@suse.com> This is a multi-part message in MIME format. --------------KHFGdDkTUPn9EHSBx1BsbyfN Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 14/01/2026 à 08:43, Jürgen Groß a écrit : > Yes. This is why I don't like the wording "inside guest", which is > just not > true. Before wasting more time for that side, there is chroot with bind-mount of DomU FS. Rephrasing like this should be more than enough: # Enable to use a grub2 emulation boot instead of direct kernel boot. > > Please be aware that we are trying to phase out pygrub, as it widens the > attack surface of dom0 from a guest. pygrub needs to look into guest > controlled file systems, so any bug in the related code (e.g. failure to > handle a corrupted or maliciously modified file system) might result in > security issues like code injection. Effectively, if pygrub is on verge of being phased out, there is not need for this patch... But could you point me to the discussion of alternatives ? As pygrub allow a more easy management... Should this be noted to the wiki ? > > So I'm on the edge whether we really should make it easier to use pygrub. Legit, Should patch subject need to be [RFC PATCH] ? > > > Juergen Thanks. --------------KHFGdDkTUPn9EHSBx1BsbyfN Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Le 14/01/2026 à 08:43, Jürgen Groß a écrit :
Yes. This is why I don't like the wording "inside guest", which is just not
true. 

Before wasting more time for that side, there is chroot with bind-mount of DomU FS.

Rephrasing like this should be more than enough:

# Enable to use a grub2 emulation boot instead of direct kernel boot. 


Please be aware that we are trying to phase out pygrub, as it widens the
attack surface of dom0 from a guest. pygrub needs to look into guest
controlled file systems, so any bug in the related code (e.g. failure to
handle a corrupted or maliciously modified file system) might result in
security issues like code injection. 

Effectively, if pygrub is on verge of being phased out, there is not need for this patch...

But could you point me to the discussion of alternatives ? As pygrub allow a more easy management...

Should this be noted to the wiki ?



So I'm on the edge whether we really should make it easier to use pygrub. 
Legit, Should patch subject need to be [RFC PATCH] ?


Juergen

Thanks.

--------------KHFGdDkTUPn9EHSBx1BsbyfN-- From xen-devel-bounces@lists.xenproject.org Wed Jan 14 08:41:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 08:41:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202658.1518120 (Exim 4.92) (envelope-from ) id 1vfwRj-0001AH-EI; Wed, 14 Jan 2026 08:41:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202658.1518120; Wed, 14 Jan 2026 08: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 1vfwRj-0001AA-BB; Wed, 14 Jan 2026 08:41:43 +0000 Received: by outflank-mailman (input) for mailman id 1202658; Wed, 14 Jan 2026 08:41:42 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfwRi-0001A1-M8 for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 08:41:42 +0000 Received: from mail-ej1-x641.google.com (mail-ej1-x641.google.com [2a00:1450:4864:20::641]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d923ac98-f124-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 09:41:41 +0100 (CET) Received: by mail-ej1-x641.google.com with SMTP id a640c23a62f3a-b8710c9cddbso478908766b.2 for ; Wed, 14 Jan 2026 00:41:41 -0800 (PST) Received: from ?IPV6:2a00:12d0:af5b:2f01:96c4:9745:9e8c:b1e8? (2a00-12d0-af5b-2f01-96c4-9745-9e8c-b1e8.ip.tng.de. [2a00:12d0:af5b:2f01:96c4:9745:9e8c:b1e8]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a4d1c6csm2375170066b.39.2026.01.14.00.41.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 00:41:40 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d923ac98-f124-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768380101; x=1768984901; 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=W5sYEAQcytupTs7Jv1BpsPPTMRJDcWNCQ1gZ3pmgRN0=; b=f771ML+InmeIS3OOZKkdCpjRzhoPzVxdZrf+a92FX28fhlxuYctJaEzWU8OLVoWkPO CPNTXLNr0LsbOBKvLvYKsEgRaSkcDC2fPBL6uxdpcCZrUy5bbnIfmB44ftoCKimv9Npf /RCdK1chjKEkHqx8X+heUUN7psdwa5I84btz/kJFClIEYKoCV+iZIijCb+OvT5tcp0uB lvl2uFWGfch5aeX5mBIMhLIdvTbFcdpI19u5r9NH2/EOdCK2qe49hwyoHfmrwydhFZIq DKpHxwvXvY9XLph67F8Yco/2zX7cUaCJ2olvNx62h9o7zd+fDZKQG6bCSZbFqXzBXgzr KUQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768380101; x=1768984901; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=W5sYEAQcytupTs7Jv1BpsPPTMRJDcWNCQ1gZ3pmgRN0=; b=XJNDOnfMokJeCZiSPLJ+6t6F7WFirzjyweVu0Qcz5Y3tjacXptTVASL77y2ZNBNRsL aJ60zWkerdPeAUjICI0GImstRY/xcKJaSPuuOYva7F2yZVmTpuYG9n/YSa67+bOXoAsH j56Z+Rj24lNm34lhiMgUsSdA6+eAEiSZN0jOCda4fAfCrrotfsFdAVNF0snnxSUxuJME 1LhL7O0cMAFTroV1qholMvnKezx4HkohfOCAMWHmE0qWAsDlhi9DkJk1Ii4SJgw5AeZ0 NiVJ/tuAzzG645o9y2H3qWBeSLXwRrzRbgiCGGwiydwWQNxEm5mVvjoW6IBCv2dnlNTf DOfw== X-Forwarded-Encrypted: i=1; AJvYcCVmj3GNRrru9xjCXySXLSdZ8d7NPQv+fwz4y1iW5tX4spWx8WYRuYAqenlLGQmHWA2YdG+p681uc9Q=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz90FV05//IPOOK6jxQMxW/0xm4DT6a/74S5V/T+vk9uzAhcDyv 9Xy895B7K3Dogpf/wdMbeTdnB8gLWZGU1xIgBKfffwQOwoIq408Xuoiq+aEdr7gAQi4= X-Gm-Gg: AY/fxX6IBcnhPNiMZMq+rV8PSC/QP0V5R0Si1ilXQ+GUi2e9B6W+PBDzX/M+I/1hVHl FKQLBHoJsTDlT/U81OvPcIL7qVZh9xgb8VLiY5zxuwM8rf0phT9JnmlyAwrpHZ+5+XOnsxCxnkV lLUYSNL85YTtX0O3dh8l+IgSM/X7vjSJpTYpumie27a5pGQgYh0v6f9c8PzS+o+4mWeVKnbyYpY NAtNxvN+8skbWE2B5QVzrjHHFVplZO+PzHpsxAHF20hj3vSnVelnAzqlzlLg5ju8LhdTv39ibZC kaXoveCE+++UTIWs1DFuINRKaEYnx6WOherPsUlH6j+z704cuF6OrEs5/vljc562XPMj8Dv5Kec /r7eR9kr8zBYtw2O7hr5hQUVhqZW7EqKbMWATY8QbmZ6/AgUOZ0A3AfLNRt9YB7sPXAgFUTQfkB jWjwRlWEZ5exxGvNcR7C4yUyYcF03Yt7ZMvVyays9Mo4QdV1jwRWVJZe2jtlk5uCDWnv2dAVOKR mfnfSfBxrn6C1JPOKH7K+CaFlE2/q7AHgdEjRc= X-Received: by 2002:a17:907:747:b0:b87:2bd6:6bc3 with SMTP id a640c23a62f3a-b87613e0446mr166418666b.61.1768380100731; Wed, 14 Jan 2026 00:41:40 -0800 (PST) Message-ID: <1d06919f-841f-44e4-b53f-af575e9dd2b1@suse.com> Date: Wed, 14 Jan 2026 09:41:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH XEN] tools: Update files examples PV&PVH with pygrub. To: Alexandre GRIVEAUX , xen-devel@lists.xenproject.org Cc: Anthony PERARD References: <3e937fc7-62bb-404c-9b1b-c4172404bf35@deutnet.info> <4a572d26-a58c-4119-b8b2-006e4e1eea89@suse.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------e4uLFezTWl5w89CAkdBazpRt" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------e4uLFezTWl5w89CAkdBazpRt Content-Type: multipart/mixed; boundary="------------CotXC5dkT0jy2ULllYVqsI1P"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Alexandre GRIVEAUX , xen-devel@lists.xenproject.org Cc: Anthony PERARD Message-ID: <1d06919f-841f-44e4-b53f-af575e9dd2b1@suse.com> Subject: Re: [PATCH XEN] tools: Update files examples PV&PVH with pygrub. References: <3e937fc7-62bb-404c-9b1b-c4172404bf35@deutnet.info> <4a572d26-a58c-4119-b8b2-006e4e1eea89@suse.com> In-Reply-To: --------------CotXC5dkT0jy2ULllYVqsI1P Content-Type: multipart/mixed; boundary="------------jo0OnpC40im3zESi56uw3K29" --------------jo0OnpC40im3zESi56uw3K29 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTQuMDEuMjYgMDk6MjAsIEFsZXhhbmRyZSBHUklWRUFVWCB3cm90ZToNCj4gTGUgMTQv MDEvMjAyNiDDoCAwODo0MywgSsO8cmdlbiBHcm/DnyBhIMOpY3JpdMKgOg0KPj4gWWVzLiBU aGlzIGlzIHdoeSBJIGRvbid0IGxpa2UgdGhlIHdvcmRpbmcgImluc2lkZSBndWVzdCIsIHdo aWNoIGlzIGp1c3Qgbm90DQo+PiB0cnVlLg0KPiANCj4gQmVmb3JlIHdhc3RpbmcgbW9yZSB0 aW1lIGZvciB0aGF0IHNpZGUsIHRoZXJlIGlzIGNocm9vdCB3aXRoIGJpbmQtbW91bnQgb2Yg RG9tVSBGUy4NCj4gDQo+IFJlcGhyYXNpbmcgbGlrZSB0aGlzIHNob3VsZCBiZSBtb3JlIHRo YW4gZW5vdWdoOg0KPiANCj4gIyBFbmFibGUgdG8gdXNlIGEgZ3J1YjIgZW11bGF0aW9uIGJv b3QgaW5zdGVhZCBvZiBkaXJlY3Qga2VybmVsIGJvb3QuDQo+IA0KPj4NCj4+IFBsZWFzZSBi ZSBhd2FyZSB0aGF0IHdlIGFyZSB0cnlpbmcgdG8gcGhhc2Ugb3V0IHB5Z3J1YiwgYXMgaXQg d2lkZW5zIHRoZQ0KPj4gYXR0YWNrIHN1cmZhY2Ugb2YgZG9tMCBmcm9tIGEgZ3Vlc3QuIHB5 Z3J1YiBuZWVkcyB0byBsb29rIGludG8gZ3Vlc3QNCj4+IGNvbnRyb2xsZWQgZmlsZSBzeXN0 ZW1zLCBzbyBhbnkgYnVnIGluIHRoZSByZWxhdGVkIGNvZGUgKGUuZy4gZmFpbHVyZSB0bw0K Pj4gaGFuZGxlIGEgY29ycnVwdGVkIG9yIG1hbGljaW91c2x5IG1vZGlmaWVkIGZpbGUgc3lz dGVtKSBtaWdodCByZXN1bHQgaW4NCj4+IHNlY3VyaXR5IGlzc3VlcyBsaWtlIGNvZGUgaW5q ZWN0aW9uLg0KPiANCj4gRWZmZWN0aXZlbHksIGlmIHB5Z3J1YiBpcyBvbiB2ZXJnZSBvZiBi ZWluZyBwaGFzZWQgb3V0LCB0aGVyZSBpcyBub3QgbmVlZCBmb3IgDQo+IHRoaXMgcGF0Y2gu Li4NCg0KOi0pDQoNCj4gQnV0IGNvdWxkIHlvdSBwb2ludCBtZSB0byB0aGUgZGlzY3Vzc2lv biBvZiBhbHRlcm5hdGl2ZXMgPyBBcyBweWdydWIgYWxsb3cgYSANCj4gbW9yZSBlYXN5IG1h bmFnZW1lbnQuLi4NCg0KT2gsIHRoZSBmdW4gb2Ygc2VsZWN0aW5nIHRoZSBncnViIHZhcmlh bnQuIDotKQ0KDQpUaGVyZSBhcmU6DQoNCi0gcHlncnViIGFzIGRpc2N1c3NlZCBhbHJlYWR5 DQoNCi0gZ3J1Yi1wdiAoMzItIGFuZCA2NC1iaXQpIGFuZCBncnViLXB2aDogb2ZmaWNpYWwg Zmxhdm9ycyBvZiBncnViMiBmb3IgUFYgYW5kDQogICBQVkggZ3Vlc3RzLCBzZWxlY3RlZCBi eSBzcGVjaWZ5aW5nIHRoZW0gYXMgdGhlIGtlcm5lbCB0byBib290LCBydW5uaW5nIGluDQog ICBkb21VIGNvbnRleHQNCg0KLSBwdmdydWIgKDMyLSBhbmQgNjQtYml0KTogbGVnYWN5IGdy dWIgMC45NyB2YXJpYW50cyBiYXNlZCBvbiBNaW5pLU9TIGZvciBQVg0KICAgZ3Vlc3RzLCBz ZWxlY3RlZCBieSBzcGVjaWZ5aW5nIHRoZW0gYXMgdGhlIGtlcm5lbCB0byBib290LCBydW5u aW5nIGluIGRvbVUNCiAgIGNvbnRleHQNCg0KPiANCj4gU2hvdWxkIHRoaXMgYmUgbm90ZWQg dG8gdGhlIHdpa2kgPw0KDQpZZXMuIERvY3VtZW50YXRpb24gc2hvdWxkIHJlYWxseSBiZSBl bmhhbmNlZC4NCg0KPj4gU28gSSdtIG9uIHRoZSBlZGdlIHdoZXRoZXIgd2UgcmVhbGx5IHNo b3VsZCBtYWtlIGl0IGVhc2llciB0byB1c2UgcHlncnViLg0KPiBMZWdpdCwgU2hvdWxkIHBh dGNoIHN1YmplY3QgbmVlZCB0byBiZSBbUkZDIFBBVENIXSA/DQoNCk5vLCBJIGRvbid0IHRo aW5rIHNvLiBPdGhlcnMgbWlnaHQgaGF2ZSBvdGhlciBvcGluaW9ucyB0aGFuIG1lIHJlZ2Fy ZGluZyBweWdydWIuDQoNCkp1ZXJnZW4NCg== --------------jo0OnpC40im3zESi56uw3K29 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----- --------------jo0OnpC40im3zESi56uw3K29-- --------------CotXC5dkT0jy2ULllYVqsI1P-- --------------e4uLFezTWl5w89CAkdBazpRt 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/Ey8FAmlnVsQFAwAAAAAACgkQsN6d1ii/Ey/u Zgf9GfXsouSO1LhzX86dNGpTCSGik3bmgjPxHsB/ojPHx8N08WP+Pg7ZOlkTyp3h7Y0bVTvzMgiC VjSukXu0gbuULkPlr9yXD5H2sWC+ZfiqIVb/OxNgA/Mt+OW60SAZbHG0vyw6dK/kcH+vYpQ3w1+f j+T71RJ8z9xqrSuuN9QoUEvzLuzthBbWylRbIJ5TlNQE+k8g3J4UCb54D2yfRIUyx2xqNksqQMG7 6mFQoyecJhnaymRiP9RvQAPLGjRka2VYmyy7zoUJmiQ9nCewDcEGaY1buPVCb9kQFFEHI8PACLLf as0XEXKG6OZP2sed0HmJa4vaxM64rVhe5/RCCDqppQ== =3T+m -----END PGP SIGNATURE----- --------------e4uLFezTWl5w89CAkdBazpRt-- From xen-devel-bounces@lists.xenproject.org Wed Jan 14 08:49:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 08:49:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202679.1518131 (Exim 4.92) (envelope-from ) id 1vfwYo-0001tG-9S; Wed, 14 Jan 2026 08:49:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202679.1518131; Wed, 14 Jan 2026 08: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 1vfwYo-0001t8-5I; Wed, 14 Jan 2026 08:49:02 +0000 Received: by outflank-mailman (input) for mailman id 1202679; Wed, 14 Jan 2026 08:49: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 1vfwYn-0001qy-AX for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 08:49:01 +0000 Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [2a00:1450:4864:20::32b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id deb7c1b7-f125-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 09:49:00 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-477a219dbcaso66606335e9.3 for ; Wed, 14 Jan 2026 00:49:00 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee54b90d5sm17229895e9.2.2026.01.14.00.48.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 00:48:59 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: deb7c1b7-f125-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768380540; x=1768985340; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=xiGVfVIHdprF755XGvSlBfxNYTkiMWZtddiwyb5XCgA=; b=NeG/+/TX33LwlFgHGRBgAg3IJdN8W7jsvMrMwLvcIUiVasF7jqJTFa+2pkp4vuv/vZ gmh6zXI/ymht8zUr2BJgfgcOdCQ+XZOjc7UjiDGc8UM9XPKfvsRhIyG66Uj/EKkpxZP0 ItXlMbrv0jFucaBXGvlr9CGfIfxcqJZcDp+qIpqfUxrHr9vNiuRGzgGFJuBT8PfACG3l en91lqBvv4MIWkiNTjVBHLEdmbY0mndWg8dnu2UDrKQTfvGDYUUnTwzymYiuTa6yhIJL 7eWMQx4h/aX3QlixxP6lyxQuxTGGPfXoyULygCZLvTRKLQyLoQqk1OLVYHheWqNQVd58 UJtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768380540; x=1768985340; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xiGVfVIHdprF755XGvSlBfxNYTkiMWZtddiwyb5XCgA=; b=YUHErZPVdUiWr/mGgosqeJ/U6mkEwloAamjm7gjP5sZdUhjfSCmgO+cu5y6pGQh1yC f5GlbVzxefEH5jYIttlPUtjEbGTffSvniQTXVGcJ+pjgSrsEhVfHQR3hyAVBVHHys65f FUQJTHmrjuhKyFAh5FovP6PmmpkRdFxR1N1k+zWfF5V/8tXQOcfvpSXctuPrrdJl+P/u RWG5M/NKritdj3i4LHAD+Q3T+jF7O9mjT+IY91uJxnnQ8mG45jHAuxc6LENueSc1juU9 PWZXh82SD6f/2PpomPkKBZ0eDjFSGfHz4W+QdU9JZnf8YCE9rN2BbPB81/EzedVIFMJI Ylug== X-Forwarded-Encrypted: i=1; AJvYcCVaHUw9hjGk/Dl5kr+mwsY2SYLornx5fYs4oZ9YgCswANmXdPiVTHYo4wkpiAQ0b66G4+3dqCensG0=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzcr0HEVInBTP+YBJ5bhjBHr7B7AvZgYnG06uVAmxp6+5IOnN5D WLvDKCeZ5Dcqd9UmJ+NBgADHkGHcQqZpCwsAGkO7urlvjBn7dEC3ElyxWqksuC+r1Q== X-Gm-Gg: AY/fxX6+hr4fBlvoBq3rKRvQ0bh1SUlAEmOEbLIn+e0ghRXH8YPOF1/c0dM9Yxs/AvJ 9Z4e6M6HsvKSBZ3GREv6MOEgzcBfXOTUsFpGlhr5kIp94i1NA7t7khjmcVaLvSWnabnzI3hTo61 8fSx4gTHDJwjQQW635jQdlIEz4qeXKCSNYAwnCUshGu4JpSXXNieO1Szs4pGFvyp0WP1mDmxIOD UyZ5+/6O1nPbQh7r0q0/0nkdeBSvUREaExdnx5kIRmtUd5Yjd2KrPePubnP6krkGv4IpwMo2iqn b99bszhSFrJQkX8WvhuruvyFqozpk59umsAD+ijPfKMu1Azu9obgpTAk1MG6JlPuQMdwdpXhDGI /+/EfD+lFBSC1ZcKXP+wLeRsSszv1blTu7MCYwg9MZCKTuQYPKh+mMTid8gDrt7bGz2xMdA5yr1 RfoOfhscLqLvkVbv6g7s+P9n2N3jT7sxZR/JN6WZMGXMhTlfdzWQo+DMVdpmgMkSU43zVqmQUsM +c= X-Received: by 2002:a05:600c:4751:b0:47e:e20e:bbbe with SMTP id 5b1f17b1804b1-47ee4827277mr11826695e9.25.1768380539565; Wed, 14 Jan 2026 00:48:59 -0800 (PST) Message-ID: Date: Wed, 14 Jan 2026 09:48:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] xen/mm: limit non-scrubbed allocations to a specific order To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260108175536.82153-1-roger.pau@citrix.com> <20260108175536.82153-3-roger.pau@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 13.01.2026 15:01, Roger Pau Monné wrote: > On Fri, Jan 09, 2026 at 12:19:26PM +0100, Jan Beulich wrote: >> On 08.01.2026 18:55, Roger Pau Monne wrote: >>> The current model of falling back to allocate unscrubbed pages and scrub >>> them in place at allocation time risks triggering the watchdog: >>> >>> Watchdog timer detects that CPU55 is stuck! >>> ----[ Xen-4.17.5-21 x86_64 debug=n Not tainted ]---- >>> CPU: 55 >>> RIP: e008:[] clear_page_sse2+0x1a/0x30 >>> RFLAGS: 0000000000000202 CONTEXT: hypervisor (d0v12) >>> [...] >>> Xen call trace: >>> [] R clear_page_sse2+0x1a/0x30 >>> [] S clear_domain_page+0x11/0x20 >>> [] S common/page_alloc.c#alloc_heap_pages+0x400/0x5a0 >>> [] S alloc_domheap_pages+0x67/0x180 >>> [] S common/memory.c#populate_physmap+0x22f/0x3b0 >>> [] S do_memory_op+0x728/0x1970 >>> >>> The maximum allocation order on x86 is limited to 18, that means allocating >>> and scrubbing possibly 1G worth of memory in 4K chunks. >>> >>> Start by limiting dirty allocations to CONFIG_DOMU_MAX_ORDER, which is >>> currently set to 2M chunks. However such limitation might cause >>> fragmentation in HVM p2m population during domain creation. To prevent >>> that introduce some extra logic in populate_physmap() that fallback to >>> preemptive page-scrubbing if the requested allocation cannot be fulfilled >>> and there's scrubbing work to do. This approach is less fair than the >>> current one, but allows preemptive page scrubbing in the context of >>> populate_physmap() to attempt to ensure unnecessary page-shattering. >>> >>> Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed") >>> Signed-off-by: Roger Pau Monné >>> --- >>> I'm not particularly happy with this approach, as it doesn't guarantee >>> progress for the callers. IOW: a caller might do a lot of scrubbing, just >>> to get it's pages stolen by a different concurrent thread doing >>> allocations. However I'm not sure there's a better solution than resorting >>> to 2M allocations if there's not enough free memory that is scrubbed. >>> >>> I'm having trouble seeing where we could temporary store page(s) allocated >>> that need to be scrubbed before being assigned to the domain, in a way that >>> can be used by continuations, and that would allow Xen to keep track of >>> them in case the operation is never finished. IOW: we would need to >>> account for cleanup of such temporary stash of pages in case the domain >>> never completes the hypercall, or is destroyed midway. >> >> How about stealing a bit from the range above MEMOP_EXTENT_SHIFT to >> indicate that state, with the actual page (and order plus scrub progress) >> recorded in the target struct domain? Actually, maybe such an indicator >> isn't needed at all: If the next invocation (continuation or not) finds >> an in-progress allocation, it could simply use that rather than doing a >> real allocation. (What to do if this isn't a continuation is less clear: >> We could fail such requests [likely not an option unless we can reliably >> tell original requests from continuations], or split the allocation if >> the request is smaller, or free the allocation to then take the normal >> path.) All of which of course only for "foreign" requests. >> >> If the hypercall is never continued, we could refuse to unpause the >> domain (with the allocation then freed normally when the domain gets >> destroyed). > > I have done something along this lines, introduced a couple of > stashing variables in the domain struct and stored the progress of > scrubbing in there. > >> As another alternative, how about returning unscrubbed pages altogether >> when it's during domain creation, requiring the tool stack to do the >> scrubbing (potentially allowing it to skip some of it when pages are >> fully initialized anyway, much like we do for Dom0 iirc)? > > It's going to be difficult for the toolstack to figure out which pages > need to be scrubbed, we would need a way to tell it the unscrubbed > regions in a domain physmap? My thinking here was that the toolstack would have to assume everything is unscrubbed, and it could avoid scrubbing only those pages which it knows it fully fills with some data. >>> --- a/xen/common/memory.c >>> +++ b/xen/common/memory.c >>> @@ -279,6 +279,18 @@ static void populate_physmap(struct memop_args *a) >>> >>> if ( unlikely(!page) ) >>> { >>> + nodeid_t node = MEMF_get_node(a->memflags); >>> + >>> + if ( memory_scrub_pending(node) || >>> + (node != NUMA_NO_NODE && >>> + !(a->memflags & MEMF_exact_node) && >>> + memory_scrub_pending(node = NUMA_NO_NODE)) ) >>> + { >>> + scrub_free_pages(node); >>> + a->preempted = 1; >>> + goto out; >>> + } >> >> At least for order 0 requests there's no point in trying this. With the >> current logic, actually for orders up to MAX_DIRTY_ORDER. > > Yes, otherwise we might force the CPU to do some scrubbing work when > it won't satisfy it's allocation request anyway. > >> Further, from a general interface perspective, wouldn't we need to do the >> same for at least XENMEM_increase_reservation? > > Possibly yes. TBH I would also be fine with strictly limiting > XENMEM_increase_reservation to 2M order extents, even for the control > domain. The physmap population is the only that actually requires > bigger extents. Hmm, that's an option, yes, but an ABI-changing one. Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 14 09:00:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 09:00:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202691.1518139 (Exim 4.92) (envelope-from ) id 1vfwk8-0004Vu-3Y; Wed, 14 Jan 2026 09:00:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202691.1518139; Wed, 14 Jan 2026 09: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 1vfwk8-0004Vn-0e; Wed, 14 Jan 2026 09:00:44 +0000 Received: by outflank-mailman (input) for mailman id 1202691; Wed, 14 Jan 2026 09: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 1vfwk7-0004Vf-5E for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 09:00:43 +0000 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [2a00:1450:4864:20::330]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 80498447-f127-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 10:00:40 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-47ee807a4c5so577485e9.2 for ; Wed, 14 Jan 2026 01:00:40 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee119aa2asm17561945e9.4.2026.01.14.01.00.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 01:00:39 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 80498447-f127-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768381240; x=1768986040; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Nsj4f9BO02MSbzEoDwR8oHG/4h/Z1+gxsOv7EcLp5PQ=; b=DQXnbYP45nK5qYTTjajk+FYgnE1G2I/IOxcYh4lPwcYmfWCbu1RfGJYPdouGPhhyqN O/5OBPZT/nV/eRnsB3TXqdofpAUmkGPiuRMGBnGa1VW5ag/1m3nvml9kgWDqBtrjuRAG OpeFwhegzA2clnMdK/q9JrDNfwT0NwpUrXE0hVexUVZbng9vRxPeyHPa55bpDl9gtIWd ICr4q7/XeLgbvqsGcAQmiVJzfk7DsCWMFvz6mEK1szxv5WFwYrR24yR7TpPcGysvfL7y MqkZEByS9J/FHbhZi5o2UzTGeGIWQSDLLWPfaUAnQQ3NxR4TXqatvdq8h1bQcGufdTQk HdaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768381240; x=1768986040; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Nsj4f9BO02MSbzEoDwR8oHG/4h/Z1+gxsOv7EcLp5PQ=; b=oimxr+KFj0vprEn0Fjjz47jzG2IB1Fx8wlwQ8rUv4jrtotZn5e5zyPrJ1skH+n2DT2 iLsKhvvgdEjPD+3PbK2Eu+Pa6uR9D5++WiLqex7shDLM9m7B2Qq4HGZFXKA/CAjWGiwR LI2JIit61AUU610VmgxJ6wiA5/D9WZLg6ZHVcuD6wS2mTYZXjqCO9vtfpAYpYbIqiCoA eFxq47NlBM34+gxyD/Q1AUjDmIA6rrQ9v/6V9aDfl6vVlmayMBV0C+QgOh2GjYpmcAXW 2zt32Cdxyh2ujHgVCaQvazzCqpbYtVS63f9MnTAtj/qLf5FLpoz+NuRJdX0W33FD81Kf mKfA== X-Forwarded-Encrypted: i=1; AJvYcCVJtySwDiporrUbaSEZknbHvfaJrDjMIzJ81XFDZvtzzanyuooavt560jjVpf7Z1/IDW+GMS9DsNcU=@lists.xenproject.org X-Gm-Message-State: AOJu0YwSrtjAqaKIjzyMLPi7DjJS2KRGgSvvarXyH+LSMjQ3J/9bS9zn E2anmVHT1SlH42LhPqe5K4sXjXrphpYtIKDsWC9awuwdXPD+LH83Zz43DWd6/Pv01w== X-Gm-Gg: AY/fxX4joMOdjr8+rs+696Lv2k+tQXePMRb+m3dxFB/F3ibLtsLSft8QPh9+uVLsh8c RjC07zq5BTnztzRxzBV2CBKC3K2ccXpEEa+d5vftDnUQIvazs1RlIXgTdrdEKVs+82G24dBgsXC CYZBUZLbHD4NzLOjesvuHX0nMvgKK/E9rj8N8YUL6mgfdt63mA1Q/Q/za5lPyyvQluC7JOxpVBl 5cTZCY/zHBMhKAAOeqRSFswoPJ9k5/1urNP68mdpRRioUC9XEWOAg4rje3QyGFSkAdCR4MzvW9Z 76rn+9p0b+WLt2fLVyS9iUtN9mW56Uajd8/6CP3Mi8D/MxmvVD6YBvb8GNjNfzdvNcu64nd8gpk 4z6PNzKfvspYIIY/gNeF0WeUOF0lUKNAtgwvIHwENNEobi/hN8iCBxPXEfbbuzC9EofUP/9s0Vm hhY+D1nZaf9JMHHyUF9DKHC4D1/ehu4/2zz862fweal79rB6NC6cDXd4tA72V4GkNCg4nZq48vF 5Q= X-Received: by 2002:a05:600c:34cd:b0:479:2a3c:f31a with SMTP id 5b1f17b1804b1-47ee32e94acmr23193615e9.1.1768381240170; Wed, 14 Jan 2026 01:00:40 -0800 (PST) Message-ID: Date: Wed, 14 Jan 2026 10:00:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 09/15] xen/riscv: add vtimer_{save,restore}() 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: <9d02934b-d448-4ec0-af0d-b4ee9a918e03@suse.com> <1acea58d-79f5-4fca-bd6a-1eaca72093f3@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: <1acea58d-79f5-4fca-bd6a-1eaca72093f3@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 13.01.2026 16:32, Oleksii Kurochko wrote: > On 1/8/26 11:43 AM, Jan Beulich wrote: >> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>> vtimer uses internal Xen timer: initialize it on the pcpu the vcpu is >>> running on, rather than the processor that it's creating the vcpu. >> This doesn't look to describe anything this patch does. > > Hm, and why not? Because this patch doesn't initialize any timer. The only timer-related call I see is one to migrate_timer(). > In vcpu_vtimer_init() we're initializing timer (it was incorrect to use > "internal Xen timer" though) on CPU is stored in vcpu->processor by calling > init_timier(). > > I will update this part then to: > Initialize the timer contained in|struct vtimer| by calling|init_timer()|. But you don't call that function. (Nor is this, btw, a useful sentence to have in a patch description. May I suggest that you read a fair number of in particular Andrew's or Roger's patch descriptions, to get a feel for what wants saying and what doesn't need to be said? In the case above: How else could you plausibly initialize that timer? Hence the latter part of the sentence is largely meaningless. Plus - is leaving the field uninitialized a plausible option? IOW you're merely stating the obvious anyway. Sadly, and I'm sorry to have to say that, this carries through many of your patch descriptions: You mechanically state what is being done, when really the thinking behind what you're doing and, often, further plans would be relevant to call out.) Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 14 09:07:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 09:07:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202704.1518149 (Exim 4.92) (envelope-from ) id 1vfwqr-0005Bq-OJ; Wed, 14 Jan 2026 09:07:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202704.1518149; Wed, 14 Jan 2026 09: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 1vfwqr-0005Bj-Lg; Wed, 14 Jan 2026 09:07:41 +0000 Received: by outflank-mailman (input) for mailman id 1202704; Wed, 14 Jan 2026 09:07: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 1vfwqp-0005Bd-VB for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 09:07:39 +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 762af735-f128-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 10:07:33 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-47ee807a4c5so640365e9.2 for ; Wed, 14 Jan 2026 01:07:33 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee563ce3csm17095275e9.14.2026.01.14.01.07.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 01:07:32 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 762af735-f128-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768381653; x=1768986453; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=SoSh1mihD7JKrbP5TTbUqHPy+briKFo4CJwVUJOJJSs=; b=ESWZ2Q2i5wiw7d1uLbJzJxSF2sukZX1cacTUI3IbGj24/E3yAozOa7lwPmlJzYlZeQ Fw7WvbowOJFZEYVs9NjwIM3AOISytiL6K8fVVKlYZlpzaAYc9hsCc+xyUpYbdbkedTaI OcR7zeUa0WTs0CuJfmbPiWT42ukDhEQEJ9mA46BLEo67iBA0YIyOaTCX9W4sg1k2kLjM f6mugrpJonZnpf5wpq09/+hT9B0QpgWn+neujE8ga/NgzMqvVuDVOPgKu4lnC1rsBf1e zbgIA+Vn4JKhiKeX6jyGey/3GUp2bI70yRj60Lavd/F3hjHEpHZBhjnrYSyLYucmV4C3 PClQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768381653; x=1768986453; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=SoSh1mihD7JKrbP5TTbUqHPy+briKFo4CJwVUJOJJSs=; b=j5PMdx2qy1dk3jtDnMnWKdQHAGXh83LSQmh+kLeJXwLfup0zSMKDUwyq/t8/6WAMOD Bs4nQGV2tVM64HXd02rMt7JYONjFALxgNSWRWK5WIrk85CMIsT/hdilTsjB76+P2h8jt /lRaARPWHD44R1qsFUAfnmptSckCcUJIiSJd7fzWypmf+VhUrFmK4xoQDtZevBuyelP1 7sCK6R7l7c04NsPE1bPY8D5jbUnODI6NBkvirfbMudMExuSJ59x9GfwIG19EJ1rXxQYF 3vz9dh4bF9idMSK8FUMjcpzMz9/FTD10gpYDbg5oQ21bkOcUVZX8sYl2IywmfuQ7wYJK 78AQ== X-Forwarded-Encrypted: i=1; AJvYcCUlUo8gkI8/VRkv2JhAPtEBrj6vBTivM0SaVMz611hOfw454SvTIOrOKeRATaMt+wcSyy/w0jRS1Go=@lists.xenproject.org X-Gm-Message-State: AOJu0YzZfEaInnr9YLpWDr9g4dcYlFKIuVxtDJ2QFdYnKRaWjLchntKj mqE/p+ujXbQ91yKbzVt8PCXfW8fi3aXXt3FS/5kuowP2pXuXLniUpS3pn99xgdGeIA== X-Gm-Gg: AY/fxX5gvj7pNEkjRTemXmwKtBOVL43+ERMmyM3bpZW3MeZweP/mVPGIbDB+XgjkbWC Z0PRGMtEzEUQl7NS4jiuLqNm2TKf7E4cy9Vsn0aD5HYmUQqvyNjADV4AC/TCJxBKx2py+MH+cll zaKEh7PMn9G1oLKAi8lf06xzu+ULC1XxGxrjjaCS5K2IaKBTzYrbd5bcpOum7Ub9nduZLEk0yqi r9Pu45stKryBJZAEKB9/KBgn2lkt7huBcRDcMVjE10f2yqeYvepfWTBdQy6MxyNzKyfMM1xd811 AMqGR8bFMzu8q4TZXKVX4zKxnn/KeDygWAL5sqsLT6PskuyWFXsBY5MRKIMRFmuWbqyjuaElKrH l73Lvr6iEGEUcuv5vW+SYP+KHF4nDkDSmFNEgs2PlXhVxc0hbPeiIIlZiC0+vU4N/ybXN8dqeSi 55PbDDd3eJuD+RrJEZSgEGfmS3xE9kpiNnwizS+suS/BJQ/nfcNPsosEtj3q99M7hrEGexsEJu7 a4= X-Received: by 2002:a05:600c:a46:b0:47a:975b:e3e6 with SMTP id 5b1f17b1804b1-47ee3371a0amr22137465e9.18.1768381652752; Wed, 14 Jan 2026 01:07:32 -0800 (PST) Message-ID: Date: Wed, 14 Jan 2026 10:07:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 12/15] xen/riscv: introduce sbi_set_timer() 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: <84cf8fb2331614c6d0cc6e9030571f42bfc6d928.1766595589.git.oleksii.kurochko@gmail.com> <5f658f5b-1c22-4bd7-9f25-f89576d5003e@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: <5f658f5b-1c22-4bd7-9f25-f89576d5003e@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 13.01.2026 17:33, Oleksii Kurochko wrote: > On 1/12/26 4:12 PM, Jan Beulich wrote: >> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>> Introduce pointer to function which points to a specific sbi_set_timer() >>> implementation. It is done in this way as different OpenSBI version can >>> have different Extenion ID and/or funcion ID for TIME extension. >>> >>> sbi_set_time() programs the clock for next event after stime_value >>> time. This function also clears the pending timer interrupt bit. >>> >>> Introduce extension ID and SBI function ID for TIME extension. >>> >>> Implement only sbi_set_timer_v02() as there is not to much sense >>> to support earlier version and, at the moment, Xen supports only v02. >> Besides this somewhat contradicting the use of a function pointer: What >> about the legacy extension's equivalent? > > I think this is not really needed, and the same implementation can be used for > both the Legacy and TIME extensions, since the API is identical and the only > difference is that|sbi_set_timer()| was moved into a separate extension. > > Since Xen reports to the guest that it supports SBI v0.2, it is up to the guest > implementation to decide why it is still using|sbi_set_timer()| from the > Legacy extension instead of the TIME extension. > > I think that I can add Legacy extension equivalent but considering that we are > using OpenSBI v0.2 for which Time extension is available it seems for me it is > enough to define sbi_set_timer to sbi_set_timer_v02() for now. Feels like here you're negating what just before you wrote in reply to 10/15. IOW - I'm now sufficiently confused. (Just consider if you ran Xen itself as a guest of the very same Xen. From what you said for 10/15, it would end up not seeing the TIME extension as available, hence would need a fallback to the Legacy one.) Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 14 09:13:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 09:13:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202713.1518160 (Exim 4.92) (envelope-from ) id 1vfwwK-0006iJ-7o; Wed, 14 Jan 2026 09:13:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202713.1518160; Wed, 14 Jan 2026 09:13:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfwwK-0006iC-4q; Wed, 14 Jan 2026 09:13:20 +0000 Received: by outflank-mailman (input) for mailman id 1202713; Wed, 14 Jan 2026 09:13: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 1vfwwI-0006i6-75 for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 09:13:18 +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 42de27dd-f129-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 10:13:16 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-42fbc305914so5932470f8f.0 for ; Wed, 14 Jan 2026 01:13:16 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ede7esm50138989f8f.32.2026.01.14.01.13.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 01:13:15 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 42de27dd-f129-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768381996; x=1768986796; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=B3EQylQ1WYMGuc6F6IY2qJmyNzD/0oNfuOw6DywxSJQ=; b=SlE/ykxI9bviA7ktFHp5WsGOrf0d94ekijlUz0oMXQ0Khyet0MtlhpsziNvXXBBNwa bdCBka8wcPlZatjjFxY4ZjjsM+HUM6tGmDLATT5ceHJwBhQU9mWpmNTVgE5SRALaYzlU j8ARs/bP1YX/8fYNJeDdXuCEdy9cADtb8JIpaiZ2QrRFzn99I8lOdgslpvzErBzFWk4l qgUnP1RedocG8kMV8wpdnNDWA9Zgm0T8EyhTUwNRuaWyKUGLsTwWCpNvMhLIk4qx5Xts fjCvNKpEqaWh0leiSbV1gmHFie1SFzZalmhsQAZpeeuGt/YOC9i0ybMyKVTsMuJ/w7oq 1p+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768381996; x=1768986796; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=B3EQylQ1WYMGuc6F6IY2qJmyNzD/0oNfuOw6DywxSJQ=; b=QqWQz5XyiFstkDObGWGoyyYJu0+yP3f4/YFr5Zn76pF9+LqE+3h4UbQnvCIz/hpRlB iFdDFTB31KI//RAZ+VXmyZLi/7Mp0VkcWg/R1bWWQIdTFoQdubLyhy/eux//cnOwfSXT sDXdAn2wrY961hUbCIStDp6dBl+eTujuCjuAPMVp2UijHQOMFCeuF0OfVLf8Wzh9QyUZ q9SeZX3xZhn/w5Har1h/cnRte+gQwgQ1epzz5wwiXkicuqIV4PLVnIpoTX2QQjKyopcZ Ww4ojqpTlixOu0Z0jC5dBIjFlzcNWEI8AK/GxyZDhGe73FssBAQkfRPwFyVq4PEMORSc jSEQ== X-Forwarded-Encrypted: i=1; AJvYcCXU/KWUJpWUpM61tdSyPMTUdRlR7MidrLBWwqFGdZoJAfh0BinnyqjE6p53dcbvI8rvLdTE+1IJmak=@lists.xenproject.org X-Gm-Message-State: AOJu0YwyS2KZaSfI8slrrqMH7n9yve1Q1bfbsp/mOMDH11KTJcMeNHtt Xt5L3ienWIbqlpL9tgoX/QhZlUYTITz0argDlPSLWJlgIyZ3iuKYJAkxVAHxV8C41A== X-Gm-Gg: AY/fxX42WiznpZzUHq4jiCQd601EcYeErG61iCoEsDTKk3tlu94N38/NrcpeUWMrq46 nLie2VHC84JYCHzJeV3ixAgC6q6St69G6awFAWCOEkqZMxOO5pnxOc9aVBGcYTNra8aKGK6gh4x BZ0wb1qBYufbp11dBJ6tqK7c0SNEKcr8c1o+gAPYkL8GtHJU0cp2TjWykOW7mO7StQYwhGnr248 Cata3aaSgIOL1Zqu+kmnz8D9Do8ACZpGH2V3veCM1EcmMz63FsWzsp10kgbxhG8QHo8B/3m/7EP PBlBjEschp8F8w/RT5Nlls58LjWS9M6XbaIXU2YlUMwzkpM8e2Y2YE6wnzr+gWSRzlcgJCh9ru5 D0Wi+bRByDM4bnsZwaba5j4t2Srhe37Fdp91Q16xL/VJk4BK4V6McfQVCAdCLpKR1/JJvJrB3rY 7Ziav6fmjyH3X+WPI48LfJS35IetWLu2Qqu3RmyVVJV3a1nkgu6Q2vrxm8uO+HGqrLuD5Uw2c1K jFyxIg/70e7LA== X-Received: by 2002:a05:6000:2013:b0:430:f5ed:83fc with SMTP id ffacd0b85a97d-4342c4f4d5fmr2077263f8f.11.1768381996178; Wed, 14 Jan 2026 01:13:16 -0800 (PST) Message-ID: Date: Wed, 14 Jan 2026 10:13:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 13/15] xen/riscv: implement reprogram_timer() using SBI 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: <43249171def325c49541ebdac141fe99d159b60f.1766595589.git.oleksii.kurochko@gmail.com> <90e7fc60-09cc-4b61-ab0a-80037f8ecaf8@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: <90e7fc60-09cc-4b61-ab0a-80037f8ecaf8@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 13.01.2026 17:50, Oleksii Kurochko wrote: > On 1/12/26 4:24 PM, Jan Beulich wrote: >> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>> @@ -39,6 +43,33 @@ static void __init preinit_dt_xen_time(void) >>> cpu_khz = rate / 1000; >>> } >>> >>> +int reprogram_timer(s_time_t timeout) >>> +{ >>> + uint64_t deadline, now; >>> + int rc; >>> + >>> + if ( timeout == 0 ) >>> + { >>> + /* Disable timers */ >>> + csr_clear(CSR_SIE, BIT(IRQ_S_TIMER, UL)); >>> + >>> + return 1; >>> + } >>> + >>> + deadline = ns_to_ticks(timeout) + boot_clock_cycles; >>> + now = get_cycles(); >>> + if ( deadline <= now ) >>> + return 0; >>> + >>> + /* Enable timer */ >>> + csr_set(CSR_SIE, BIT(IRQ_S_TIMER, UL)); >> Still learning RISC-V, so question for my understanding: Even if the timeout >> is short enough to expire before the one SIE bit will be set, the interrupt >> will still occur (effectively immediately)? (Else the bit may need setting >> first.) > > The interrupt will become pending first (when mtime >= mtimecmp or > mtime >= CSR_STIMECMP in case of SSTC) and then fire immediately once > |SIE.STIE |(and global|SIE|) are enabled. > >> >>> + if ( (rc = sbi_set_timer(deadline)) ) >>> + panic("%s: timer wasn't set because: %d\n", __func__, rc); >> Hmm, if this function ends up being used from any guest accessible path (e.g. >> a hypercall), such panic()-ing better shouldn't be there. > > I don't have such use cases now and I don't expect that guest should use > this function. How do you envision supporting e.g. VCPUOP_set_singleshot_timer without involving this function? Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 14 09:15:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 09:15:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202727.1518170 (Exim 4.92) (envelope-from ) id 1vfwy1-0007J8-L7; Wed, 14 Jan 2026 09:15:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202727.1518170; Wed, 14 Jan 2026 09:15:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfwy1-0007J1-Ht; Wed, 14 Jan 2026 09:15:05 +0000 Received: by outflank-mailman (input) for mailman id 1202727; Wed, 14 Jan 2026 09:15: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 1vfwy0-0007Hh-8Q for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 09:15:04 +0000 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [2a00:1450:4864:20::42b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8253e589-f129-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 10:15:03 +0100 (CET) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-430f57cd471so4270661f8f.0 for ; Wed, 14 Jan 2026 01:15:03 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ff0b2sm48837377f8f.42.2026.01.14.01.15.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 01:15:02 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8253e589-f129-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768382103; x=1768986903; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=XJCW3cD4Xjf4eA6qkgzI7CBKKgWBwQbe4IxF6FsR/d4=; b=MjJ+HrtWdZrBGgderOq3QOUQx+pzlzNz226IsEWLyRwXYpAs8oZ6YR2AdazKMTuF7T 8uwya0GNal08fLPHrCodZYeTI1XhFbGqmfrG7vrvBOwTMSyicF6QUbXsCQW0aC8xQ/6p 7NKGVW8lZPnbPJxJdeiI1Cxax5N2bD0EhUVk1asbRMlGVDbrWVyC9OEGB3CTmF1sBAgj XUvDpTz061m+B8r/ORKvMHb2B8ZZids1rxR1zXNlGnzmxfp80z8n2XxZAlpn5JuKnImj iRFNk/yO+n5iki8maiBKXK2k06GfxOilGx3bDYGWZujXqvi7znCfYInY5Wun8bHCpS0Q QIWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768382103; x=1768986903; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=XJCW3cD4Xjf4eA6qkgzI7CBKKgWBwQbe4IxF6FsR/d4=; b=BCDpc9hXQUPfRQxxYCNrBkGJSymG8SA1t8EV/WSMLlxlEK3ecsuUjY+eWAWZ3vTJ0K 7rsBouBz5LIfKs2y4T7Mv49XcwE8KSKa7LFCgbZXFFsf43sLuPpVgxe1MZwvBHIUT2ee zVzPsGxNh5V2hgDlC0MIAdRzV6tvl0BzDTzq+MPbWjNF6ew7SustXrNpmzHv7yBOEmfN Ua4OuwavOk53NfpDn5hoMfdLq9vjup6yOCBTetSFaqjhgTyU6ihlICGgyKYhXyqL2zOy JvjQl4+kzRXsxEhbgbd5cubtOm+BlBSXRDmRwY06CqlF60yi5dk8JXXhv61mulBaye9B IZ7g== X-Forwarded-Encrypted: i=1; AJvYcCWDbasm49Q7s8GpjKRXXj3B0JMVXk71F738rqQGENFMlcpxEAT7p+6UTPkPe3273K67KNTeVLVjHkQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YxfEz0WhfK4yBkF/cD/E0fdHA1rejnP4z7LvyWzYJru9WHtTwQP nr7oAQCWKVVGR7oem5yi+30f+uaRJKOueSq3tnGahNGdkldvd3xz3bYrzoKELFToSA== X-Gm-Gg: AY/fxX5TmgSiObJvAprcbM+YKrKC2EJf3NHN7nzl5Eww/wlESD2Ig8iAjOmOGlHgJQK tzRYdxvKrXUR/vNjMTT7phRe0uzUIust837STPh6ovqZBYYh5j5v2qsaqY4EmKKQRr7iZmNIe3f RpVSRl99c/mODC1NYeedckymdPIQs3aGSQ0CjaApI/flQIhvOSTiWBgcH1S6f13MgUZMgB/MuGJ 3nD4toz3knlq0XfZUxv9PP/tWJQWd1CrZeP5/mj0bQVKSJECnBv+43d527siL5mUEx+nRFE/5S7 989RPQk6D0kLXLBwMimGaSvdhb3OeF9EsmPjAexC9+YJflaYeOmpucG3WayUQatfF+Xns2WO5Ij Pc2qjnJ0gzwBNV8fJA50SCkUcKj5hecEk1hdOjJRLBVpM9cPw6X31zvCbndFewKTh0xVcF4Gz5Y DWeMHIUWMVfYeEO9TJWfxkTlrz2uwH9w6Cn8k+qDetfvdCgwOh+RLZfs6rbTnm7Iz1AJ1qGGn2W 61umiiXuTNd9w== X-Received: by 2002:a05:6000:604:b0:430:f1ae:c7a9 with SMTP id ffacd0b85a97d-4342c4fee33mr1795475f8f.22.1768382102658; Wed, 14 Jan 2026 01:15:02 -0800 (PST) Message-ID: <81b78b76-39e8-4a12-b392-ee62d426fcc5@suse.com> Date: Wed, 14 Jan 2026 10:15:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 15/15] xen/riscv: init tasklet subsystem 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: <7fd154cda45466ca4bd425bc05d191caccc7d96d.1766595589.git.oleksii.kurochko@gmail.com> <7511b588-8699-49a9-99d0-0cb94f0fac76@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: <7511b588-8699-49a9-99d0-0cb94f0fac76@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 13.01.2026 18:03, Oleksii Kurochko wrote: > > On 1/12/26 5:20 PM, Jan Beulich wrote: >> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>> As the tasklet subsystem is now initialized, it is necessary to implement >>> sync_local_execstate(), since it is invoked when something calls >>> tasklet_softirq_action(), which is registered in tasklet_subsys_init(). >>> >>> After introducing sync_local_execstate(), the following linker issue occurs: >>> riscv64-linux-gnu-ld: prelink.o: in function `bitmap_and': >>> /build/xen/./include/xen/bitmap.h:147: undefined reference to >>> `sync_vcpu_execstate' >>> riscv64-linux-gnu-ld: ./.xen-syms.0: hidden symbol >>> `sync_vcpu_execstate' isn't defined >>> riscv64-linux-gnu-ld: final link failed: bad value >> How that when ... >> >>> --- a/xen/arch/riscv/stubs.c >>> +++ b/xen/arch/riscv/stubs.c >>> @@ -91,16 +91,6 @@ void continue_running(struct vcpu *same) >>> BUG_ON("unimplemented"); >>> } >>> >>> -void sync_local_execstate(void) >>> -{ >>> - BUG_ON("unimplemented"); >>> -} >>> - >>> -void sync_vcpu_execstate(struct vcpu *v) >>> -{ >>> - BUG_ON("unimplemented"); >>> -} >> ... there was a (stub) implementation? (The code changes look okay, it's just >> that I can't make sense of that part of the description.) > > I haven’t investigated this further. I wanted to look into it now, but I can’t > reproduce the issue anymore. I reverted|sync_vcpu_execstate()| to a stub and no > longer see the problem. > > I will move the introduction of|sync_vcpu_execstate()|. It doesn’t seem to be > really needed at the moment, but since it is already introduced and there are no > specific comments against it, I think it can be added as a separate patch in this > series. Just to mention: Moving it right here looks to make sense to me. It's just that the description of the change was irritating. Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 14 09:25:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 09:25:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202741.1518179 (Exim 4.92) (envelope-from ) id 1vfx7N-0000eB-Gq; Wed, 14 Jan 2026 09:24:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202741.1518179; Wed, 14 Jan 2026 09: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 1vfx7N-0000e4-DQ; Wed, 14 Jan 2026 09:24:45 +0000 Received: by outflank-mailman (input) for mailman id 1202741; Wed, 14 Jan 2026 09: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 1vfx7M-0000dy-3p for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 09:24:44 +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 dae42532-f12a-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 10:24:41 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-43277900fb4so265271f8f.1 for ; Wed, 14 Jan 2026 01:24:41 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ff1e9sm50986089f8f.41.2026.01.14.01.24.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 01:24:40 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dae42532-f12a-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768382681; x=1768987481; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=EZahWFUg6rXWmaezAq8NXtXsslHE1pS9uJhUP7H5wzI=; b=BT1xDh4dE6hkmRF7i+diP2ON1kuO1kkdCAjUOJWHOPKPjvP4PJCYrMkH15bRChK3L3 /egoexFdJ3hjQcOZYAcESep7mNi/WPycnExrYhyWkhxooX7SjA6Uo7Vp61o9v6OB5Cji ZvGsNIfl7OIpkBYBSKHLGXUq7FKB2yWSeszeMk9cXjR3PfFGZhMyaP1lsyafmpE+Bwhh 1OgwuQJ7tZfQUDrd/NdTW3ERQ4XqW8i45d9PSyu8+qrs3dMWUzfuYf8aswXi9iJSBB2H hNj0g084WANgwNlA1SyZHI2tDR4UpgYE4mzaeOX0POphR+SJk8qnfZd2GDdSihieTKN2 o2LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768382681; x=1768987481; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=EZahWFUg6rXWmaezAq8NXtXsslHE1pS9uJhUP7H5wzI=; b=IfJcTY8Be8O3ghjI1cpRUUnpkoC5EAyDQZqDch0AUaWhmnzbdwgbdVNTTvgtiETpgl 5SIKjZirzm2YKe788p8V18k0D/zJT9MBAh6eUMJbpUi1UwSV2Cr/ffIhtL77KHW62x6o +KDnZonL0XI0+nIK5zONhVwIAOIbu2j72cAURI7ZzCCGA8i6WYrF8PJcHIPAw+rx61ba slEHGxpUGK9FFHl0XoSacQqBuVk89FZkD0Tnn7Nsf8eNi+VqUspjMcsWu0g+FhnYQneg ouzkPtruDSCzpuOlsTljpX6235YvKUyPyQfqwh6BDrJIuT84ta6cbdt1EhenuotYKaGD s2EA== X-Forwarded-Encrypted: i=1; AJvYcCVsQE77NgOQfJYKXCsYt2EPH3jG9AMCR/kwh28hEdBltgu6p35ezRyHEJtI1stXFH2Y7KVRBF5Akdc=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywd9l2ylF9EV9yEL54VfSvOYs0kQKJAv/07J1905EvFeWDFQRLd gvNWg/7X07scctLF+8bvnYj7/ARB6imiHOMCuRC9r8VAHhOuDdYmgXA247/fHuJGpg== X-Gm-Gg: AY/fxX5RIMVA+qjiGLka/JeywnRd34UTHyBWN3cPBcxxLocadH0Gn5zdjup7wIa3RSC 5EkjI0RFH/nW22LBMzoWHIYePT7ZATtQxy11mA3AZfU2F6/5NVnaovsERnmPs5XMdWERO8Gi/9G a2hHOPdyz5PRdDB4gG6YFKv46aytMF0Y0trmkD3bOm+UGdiL/23i9p0QJWK7YirKQ8lqOSbW/br OpOco/IpTk1NrG1IpyoB3r5LBTX53u27pS40dJpuBfjlOo3gQkq6srGjgwxh/0VJ0zfl3Eox5TB FPSiJXjyaNqDXhrfGzPVqV0S7Muyo3t5YnIU9Ui9sQI0ulUwLqQ3iMdqeecC6BXx9+nhnXf2Gwk dOorWMa0s/sc2qarTKIdgNf89gm71lEq+F1yDHNmm1RYh/lxasDO1/HjkSX05kyKZbshyEdhu40 7R3CN+59/KrHhx3/XjYiHeOAsMJ9qzGHMXpXV5LiuBNdpRVFjVkZ98dh2ewn9xfuJ7jrQoZ7XFp uzVrYH392BKpw== X-Received: by 2002:a05:6000:40cc:b0:431:c06:bc82 with SMTP id ffacd0b85a97d-43423e7cf42mr8203734f8f.12.1768382680749; Wed, 14 Jan 2026 01:24:40 -0800 (PST) Message-ID: <664b6639-732d-4e43-8323-47333b0d8e4c@suse.com> Date: Wed, 14 Jan 2026 10:24:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 2/2] xenpm: Add get-intel-temp subcommand To: Teddy Astie Cc: Oleksii Kurochko , Community Manager , Anthony PERARD , xen-devel@lists.xenproject.org References: <7dfa012b734f3c769da88f0f1c989d07b724bdaa.1768235932.git.teddy.astie@vates.tech> <7ae6ca6f93e81cb0b5a71db90913dc3f67e6b763.1768235932.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: <7ae6ca6f93e81cb0b5a71db90913dc3f67e6b763.1768235932.git.teddy.astie@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12.01.2026 17:47, Teddy Astie wrote: > @@ -1354,6 +1358,115 @@ void enable_turbo_mode(int argc, char *argv[]) > errno, strerror(errno)); > } > > +static int fetch_dts_temp(xc_interface *xch, uint32_t cpu, bool package, int *temp) > +{ > + xc_resource_entry_t entries[] = { > + { .idx = package ? MSR_PACKAGE_THERM_STATUS : MSR_IA32_THERM_STATUS }, > + { .idx = MSR_TEMPERATURE_TARGET }, > + }; > + struct xc_resource_op ops = { > + .cpu = cpu, > + .entries = entries, > + .nr_entries = ARRAY_SIZE(entries), > + }; > + int tjmax; > + > + int ret = xc_resource_op(xch, 1, &ops); > + > + switch ( ret ) > + { > + case -1: > + /* xc_resource_op returns -1 in out of memory scenarios */ > + return -ENOMEM; Assuming xc_resource_op() is well-behaved in this regard, why not return errno here? Or yet better stick to -1, leaving it to the caller to consume errno? And then ... > + case 0: > + /* This CPU isn't online or can't query this MSR */ > + return -ENODATA; ... set errno here and return -1? With this normalized here, ... > + case 1: > + { > + /* > + * The CPU doesn't support MSR_TEMPERATURE_TARGET, we assume it's 100 > + * which is correct aside a few selected Atom CPUs. Check Linux > + * kernel's coretemp.c for more information. > + */ > + static bool has_reported_once = false; > + > + if ( !has_reported_once ) > + { > + fprintf(stderr, "MSR_TEMPERATURE_TARGET is not supported, assume " > + "tjmax = 100, readings may be incorrect.\n"); > + has_reported_once = true; > + } > + > + tjmax = 100; > + break; > + } > + > + case 2: > + tjmax = (entries[1].val >> 16) & 0xff; > + break; > + > + default: > + if ( ret > 0 ) > + { > + fprintf(stderr, "Got unexpected xc_resource_op return value: %d", > + ret); > + return -EINVAL; > + } > + return ret; > + } > + > + *temp = tjmax - ((entries[0].val >> 16) & 0xff); > + return 0; > +} > + > +static void get_intel_temp(int argc, char *argv[]) > +{ > + int temp = -1, cpu = -1; > + unsigned int socket; > + bool has_data = false; > + > + if ( argc > 0 ) > + parse_cpuid(argv[0], &cpu); > + > + if ( cpu != -1 ) > + { > + if ( !fetch_dts_temp(xc_handle, cpu, false, &temp) ) > + printf("CPU%d: %d°C\n", cpu, temp); > + else > + printf("No data\n"); ... you can then use perror() here (and perhaps elsewhere). Right now the distinct non-zero return values of fetch_dts_temp() are of no interest to any of the callers. Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 14 09:29:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 09:29:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202751.1518191 (Exim 4.92) (envelope-from ) id 1vfxBp-0001ON-2I; Wed, 14 Jan 2026 09:29:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202751.1518191; Wed, 14 Jan 2026 09:29: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 1vfxBo-0001OG-Un; Wed, 14 Jan 2026 09:29:20 +0000 Received: by outflank-mailman (input) for mailman id 1202751; Wed, 14 Jan 2026 09:29: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 1vfxBn-0001OA-4b for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 09:29:19 +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 7e002d17-f12b-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 10:29:15 +0100 (CET) Received: from MN0P223CA0014.NAMP223.PROD.OUTLOOK.COM (2603:10b6:208:52b::26) by MW4PR12MB7013.namprd12.prod.outlook.com (2603:10b6:303:218::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Wed, 14 Jan 2026 09:29:10 +0000 Received: from BL02EPF0001A0FE.namprd03.prod.outlook.com (2603:10b6:208:52b:cafe::63) by MN0P223CA0014.outlook.office365.com (2603:10b6:208:52b::26) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Wed, 14 Jan 2026 09:28:54 +0000 Received: from satlexmb08.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.9520.1 via Frontend Transport; Wed, 14 Jan 2026 09:29:09 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 14 Jan 2026 03:29:09 -0600 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; Wed, 14 Jan 2026 01:29:08 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7e002d17-f12b-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=RPoRQ/ukFhwWAQLeR7E4Vy2EkTt3nXuhhMiQpXCLcM9+PWtX11JSm8R4v0ZveoGmOoaicbQawmmt1UaIUr37r4ea1OYc0SaGEXhEtNTbE2akafB97K8wtTzVUXIfLkeWb/AXQCn9N9iffAMafuKd7PKqMesVuG4KubU/OQHzS8EBucoL4sU05ZDJlPkvx0JHOWBNh+0L2W4stuPHjVD/bupzCsw4W9b8TvjXk9jDtSdAEyC1lxw2bo2VLnptFX9NfnweIqOsmOeh1xc7lfKZOafQSWqU1NsI/Snf93m6i+0DG4piXVci71KjA37BdKkp0B29fAEsS423H8k0s5DAiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0nOXHkvU6Jz/z5QykMx8MulO4e5olXB2Ki7KhX/hvwA=; b=rltQ/o/MlwXBS6zTrxB/MTE1k3/NGvnvexvK4l7hHwZzIU8RV6XYGNtzHtGn/94pjvC0jlVLyQYqrgph7KSZXBeSdWEdeWwU2YGCrI8Tmchnof9Ws8tE/XhqIaBZwZNUdV4gwYLvNnMfJ/UhYP9qlDECkPPn3sB/rzzmwcQQad0LzjKYwApcSrr0WqsLVwkrGaalg6FwZ8/0tuV4NmCIm+926XcYD7TwQv5T2qpN2RgnW+KjKi4lvMMrrvjvaIXLyeTs86IKosqOdab2gXj7/N4Zv5VH3hvPMXsAx2rHSAXmXjr//cAgUL/6B9PdvaRrgnDK8uiYY7f+MXjPRWb5Yg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0nOXHkvU6Jz/z5QykMx8MulO4e5olXB2Ki7KhX/hvwA=; b=cdDnSoxHtOW7up0zEQC6bfPbUzqpjmrPnrusdiMk+a9dgdZsO6PmmGOkGujb8zPidekNzcf22eqOFSHSYRKUwZ1z8YTKKur4iumn7XGJLwAsXQ/YfThoIlgwCDrtAdfk4zVcpyc3tokvBSPp1IDlWTFX9gxf2MWMRrI1hSYrI0Y= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <1cb6fc36-fd16-499b-a616-4d321ae83572@amd.com> Date: Wed, 14 Jan 2026 10:29:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/6] arm/mpu: Implement vmap functions for MPU To: Harry Ramsey , CC: , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk References: <20260113162309.6766-1-harry.ramsey@arm.com> <20260113162309.6766-3-harry.ramsey@arm.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20260113162309.6766-3-harry.ramsey@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF0001A0FE:EE_|MW4PR12MB7013:EE_ X-MS-Office365-Filtering-Correlation-Id: 8c3a3590-839e-410d-5ac7-08de534f5f42 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?b2pPOFdDNTYyQTJ6MDRza0NENGg2T1hBakVDRGgyOEdOOEhSL1VOZGZIY0NC?= =?utf-8?B?QkVrUXMwUlAwcC91THo1U0FlWmhiUEhXZWcyd1RxMnhZekNOdXNybWRQeUZi?= =?utf-8?B?a2pqUWljUkdlMGk2Nmk1cmpJNGZNVzh4L1FyMFU2UTdqMHR6VkVVd003dlBa?= =?utf-8?B?YXc1U1FJNW0xQzRwYlhYT25JY0hUR05YQlg0d0lRRUNjZ3VuU2x2UnNxaDlk?= =?utf-8?B?M1NnTXVEK1VxQXNQQ1pqYUU3K0U5dnNsTSt0QXg0azc3YjNnWFZLNXFqbGtP?= =?utf-8?B?RFNNbUY2a3k3ak1PQXRNSEJBdXhUU2FTMVB5MFJ1L05QdGN1cU9UcS9nTDVQ?= =?utf-8?B?MmNZUGJtMm5jRkxHeHdvUnJXdVE2SzJROEx6VjB1SkVlTlBaeWdBajJsU2pL?= =?utf-8?B?ajB4WTZLTHRrSHJXSkdTc0ZaeVFOZHM3ZjdUTDA3UGFjSnNuaWxxM0JRQ3ZR?= =?utf-8?B?Rzd5aXUvVkc2dEZ3Q1l2ODZtbmp5cXM5QkhTMjdNYXR1SytaK2ZZQ3pydUtI?= =?utf-8?B?WDJVY0JmMmRsdnBiYlJkRmE5aHhqbnllaGV6RTdwa1J3UERKL3VnR2tWOU8y?= =?utf-8?B?SlMweTA3YVhsSmRQT1VYeU12SGZ6aURGUE1rS2wxUVYrVXdBQzZxRmpWRXdP?= =?utf-8?B?S2hnaSszQ2tNVzR6aDBhR0hUcFg0Y1hUSWVYbXdrSXdTNVNlNDRueW16TDkx?= =?utf-8?B?WmpaVjBkNTZRY3R0a3cyYjJseWVyMERhMmVoaXRlaFFDYkI3UVMzamhzUTRB?= =?utf-8?B?RVJ5SHFkSWorN2NwQzBVRHRwdkhYSXArZnZMQjM0d204TkNOaVAxaFd1SU0v?= =?utf-8?B?d3JsN1lDM0JhdUMrSmZ6Mmp0ekpDVHY5RVRRa0xxREJLSzU0dTZ1eFZ5aXRV?= =?utf-8?B?Um95S3F6OGpDZ0VJS21ieVVYdnc4QzBnTFRNaWlXRFhkQzUralZkZ3J0Y1Rn?= =?utf-8?B?cXJ5cHorZGpsNk9OeWkzelVZUXYxbDAwN2owaG9kUlNKSlVtUFBCYTNsL29Z?= =?utf-8?B?aEJIeWtBYjdMRVZBK1BKQWJSR09iMkNDYUJweTRVQjIzSjRyRDhiVVpsUENQ?= =?utf-8?B?eit0SGh3Yi9zQ2pYVkRZcUpxN1BqZG5jZlBIcEk0RjNSdGFIZjJLT0x6YTA4?= =?utf-8?B?dnJhUFlDT1J1dVo4SnBQVUdMVzM1amZORk5CSTVsK3RBZHl3eHVBOFM1TExH?= =?utf-8?B?c3ZqeHA5MmFkUXhRT21CMFQ4TW5NV0pCZkdjQWQxYU9SK1Z2Ykh0cUh1VmpQ?= =?utf-8?B?cWhBMXhzUENuTG41WFR1SzdoTWZPdFRIRDRhYmY3MFBmbEtXRmphNDVTaEdu?= =?utf-8?B?aGUyeGFLV1JaTElVTldNZngzZG1LaTlveWd3UlVGUEpoL0hjVHRzV3JOR3ZV?= =?utf-8?B?ZzNzNjYxNithZWJmRVlna1V6SENFWSsxZ1J6c2p2MUdaMk9RWFJOc0RkR01w?= =?utf-8?B?VWt4WDZjVWg1cGdRWXM5VmJKRzRDSDlrOEJmcUdMNUpLRlFKa2h4NHEzYjJE?= =?utf-8?B?SXk4bFBaM2puVGFMdDFQWmpTTW5EV2lYQ3JoYzVHY2E5ZnRwTlkremNZM3FS?= =?utf-8?B?NlBqNElEbDl6bytBT0dOdDJ6UVdFclg5MU5udHcvU2g4enZ2N1R3WXNjN0x4?= =?utf-8?B?WlIvaE9scHp0d1pLdXlWeGJVVTN6N01lZ01rSzZNTGY3K2U2Z3VubWhrOW1W?= =?utf-8?B?SW5WWUQyVzVwL3V3UHBNN3hJN29pQVRHTW5GSDZKVXU0V0x3Y0RobXc1bFRi?= =?utf-8?B?QVg5K3ZyMnlFUHNoOE9ON011c0J1SDFwR2MxTWtRa3lnWnRQV25yS3JUTzM5?= =?utf-8?B?Slc2Y3VxdHpZSFBjVjhiK0JqeU1aSUdxSW9FQ1NLOWZZdVVzWm90RWtVbm9z?= =?utf-8?B?bEh4UzM1Ni9icnFUUlBmd3pOcE5ZdzdMSkRWY3QxZVprL2RCaVRkR2o1dmRl?= =?utf-8?B?N3o2L0tvNzQyNWphbVRXa3F2V0gySWxybjRJRkZveGpCNVZ1M2x4ZE1pNTF0?= =?utf-8?B?eUlqLzlXbElVbzBZZUNIQS90SGsweU1XNktXRXFIajF5Y2RXOUc5aERIRWlD?= =?utf-8?B?aS91dUV3TVBlOEptSVF0a0ZTVzJJZ3E5Q1g3c3ZtcU9ueWRNZEdaRmQ2OGJk?= =?utf-8?Q?lI2M=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2026 09:29:09.8445 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8c3a3590-839e-410d-5ac7-08de534f5f42 X-MS-Exchange-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: BL02EPF0001A0FE.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7013 On 13/01/2026 17:23, Harry Ramsey wrote: > From: Luca Fancellu > > HAS_VMAP is not enabled on MPU systems, but the vmap functions are used > in places across common code. In order to keep the existing code and > maintain correct functionality, implement the `vmap_contig` and `vunmap` > functions for MPU systems. > > Introduce a helper function `destroy_xen_mapping_containing` to aid with > unmapping an entire region when only the start address is known. > > Signed-off-by: Luca Fancellu > Signed-off-by: Harry Ramsey > --- > v3: > - Add additional comments for clarity regarding MPUMAP_REGION checks > - Ensure `context_sync_mpu` occurs after `destroy_entire_xen_mapping` > - Fix deadlock if `destroy_entire_xen_mapping` is called with an address > that does not belong to a region > v2: > - Rename `destroy_entire_xen_mapping` to `destroy_xen_mapping_containing` > - Improve code documentation > - Refactor nested code > - Fix ignored rc error code in `destroy_xen_mapping_containing` > --- > xen/arch/arm/include/asm/mpu/mm.h | 10 ++++ > xen/arch/arm/mpu/mm.c | 82 ++++++++++++++++++++++++++----- > xen/arch/arm/mpu/vmap.c | 14 ++++-- > 3 files changed, 91 insertions(+), 15 deletions(-) > > diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h > index e1ded6521d..1b5ffa5b64 100644 > --- a/xen/arch/arm/include/asm/mpu/mm.h > +++ b/xen/arch/arm/include/asm/mpu/mm.h > @@ -111,6 +111,16 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags); > int mpumap_contains_region(pr_t *table, uint8_t nr_regions, paddr_t base, > paddr_t limit, uint8_t *index); > > + > +/* > + * Destroys and frees (if reference count is 0) an entire xen mapping on MPU > + * systems where only the start address is known. > + * > + * @param s Start address of memory region to be destroyed. > + * @return: 0 on success, negative on error. > + */ > +int destroy_xen_mapping_containing(paddr_t s); > + > #endif /* __ARM_MPU_MM_H__ */ > > /* > diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c > index 687dec3bc6..14a988ea0c 100644 > --- a/xen/arch/arm/mpu/mm.c > +++ b/xen/arch/arm/mpu/mm.c > @@ -290,6 +290,43 @@ static void disable_mpu_region_from_index(uint8_t index) > write_protection_region(&xen_mpumap[index], index); > } > > +/* > + * Free a xen_mpumap entry given the index. A mpu region is actually disabled > + * when the refcount is 0 and the region type is MPUMAP_REGION_FOUND. > + * > + * @param idx Index of the mpumap entry. > + * @param region_found_type MPUMAP_REGION_* value. > + * @return 0 on success, otherwise negative on error. > + */ > +static int xen_mpumap_free_entry(uint8_t idx, int region_found_type) > +{ > + ASSERT(spin_is_locked(&xen_mpumap_lock)); > + ASSERT(idx != INVALID_REGION_IDX); > + ASSERT(MPUMAP_REGION_OVERLAP != region_found_type); > + > + if ( MPUMAP_REGION_NOTFOUND == region_found_type ) > + { > + printk(XENLOG_ERR "Cannot remove entry that does not exist\n"); > + return -EINVAL; > + } > + > + if ( xen_mpumap[idx].refcount ) > + { > + xen_mpumap[idx].refcount -= 1; > + return 0; > + } > + > + if ( MPUMAP_REGION_FOUND == region_found_type ) > + disable_mpu_region_from_index(idx); > + else > + { > + printk(XENLOG_ERR "Cannot remove a partial region\n"); > + return -EINVAL; > + } NIT: Try to limit the number of if/else blocks to make the code read better. Here you could do the following to remove one else: if ( MPUMAP_REGION_FOUND != region_found_type ) { printk(XENLOG_ERR "Cannot remove a partial region\n"); return -EINVAL; } disable_mpu_region_from_index(idx); return 0; > + > + return 0; > +} > + > /* > * Update the entry in the MPU memory region mapping table (xen_mpumap) for the > * given memory range and flags, creating one if none exists. > @@ -357,18 +394,7 @@ static int xen_mpumap_update_entry(paddr_t base, paddr_t limit, > return -EINVAL; > } > > - if ( xen_mpumap[idx].refcount == 0 ) > - { > - if ( MPUMAP_REGION_FOUND == rc ) > - disable_mpu_region_from_index(idx); > - else > - { > - printk("Cannot remove a partial region\n"); > - return -EINVAL; > - } > - } > - else > - xen_mpumap[idx].refcount -= 1; > + return xen_mpumap_free_entry(idx, rc); > } > > return 0; > @@ -418,6 +444,38 @@ int destroy_xen_mappings(unsigned long s, unsigned long e) > return xen_mpumap_update(s, e, 0); > } > > +int destroy_xen_mapping_containing(paddr_t s) > +{ > + int rc; > + uint8_t idx; > + > + ASSERT(IS_ALIGNED(s, PAGE_SIZE)); > + > + spin_lock(&xen_mpumap_lock); > + > + rc = mpumap_contains_region(xen_mpumap, max_mpu_regions, s, s + PAGE_SIZE, > + &idx); > + > + /* > + * Since only entire regions can be freed using `xen_mpumap_free_entry` we > + * must first check the region exists. > + */ > + if ( MPUMAP_REGION_NOTFOUND == rc ) { Bracket should be placed on its own line. > + printk(XENLOG_ERR "Cannot remove entry that does not exist"); > + rc = -EINVAL; > + goto out; > + } > + > + /* As we are unmapping entire region use MPUMAP_REGION_FOUND instead */ > + rc = xen_mpumap_free_entry(idx, MPUMAP_REGION_FOUND); > + if ( !rc ) > + context_sync_mpu(); > + out: > + spin_unlock(&xen_mpumap_lock); > + > + return rc; > +} > + > int map_pages_to_xen(unsigned long virt, mfn_t mfn, unsigned long nr_mfns, > unsigned int flags) > { > diff --git a/xen/arch/arm/mpu/vmap.c b/xen/arch/arm/mpu/vmap.c > index f977b79cd4..54d949e7ce 100644 > --- a/xen/arch/arm/mpu/vmap.c > +++ b/xen/arch/arm/mpu/vmap.c > @@ -1,19 +1,27 @@ > /* SPDX-License-Identifier: GPL-2.0-only */ > > #include > +#include > #include > #include > #include > > void *vmap_contig(mfn_t mfn, unsigned int nr) > { > - BUG_ON("unimplemented"); > - return NULL; > + paddr_t base = mfn_to_maddr(mfn); > + > + if ( map_pages_to_xen(base, mfn, nr, PAGE_HYPERVISOR ) ) > + return NULL; > + > + return maddr_to_virt(base); > } > > void vunmap(const void *va) > { > - BUG_ON("unimplemented"); > + paddr_t base = virt_to_maddr(va); > + > + if ( destroy_xen_mapping_containing(base) ) > + panic("Failed to vunmap region\n"); > } Looking at this series as a whole, at the end we will end up with vmap_contig/vunmap to contain the same implementation as map_domain_page and alike from the last patch. Shouldn't we define ones using the others? ~Michal From xen-devel-bounces@lists.xenproject.org Wed Jan 14 09:40:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 09:40:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202767.1518200 (Exim 4.92) (envelope-from ) id 1vfxMX-0004F4-5m; Wed, 14 Jan 2026 09:40:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202767.1518200; Wed, 14 Jan 2026 09: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 1vfxMX-0004Ex-1z; Wed, 14 Jan 2026 09:40:25 +0000 Received: by outflank-mailman (input) for mailman id 1202767; Wed, 14 Jan 2026 09:40:23 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfxMV-0004Er-9Y for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 09:40:23 +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 0afa870a-f12d-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 10:40:22 +0100 (CET) Received: from BY1PR03MB7875.namprd03.prod.outlook.com (2603:10b6:a03:5b1::10) by CH4PR03MB7553.namprd03.prod.outlook.com (2603:10b6:610:23e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Wed, 14 Jan 2026 09:40:18 +0000 Received: from BY1PR03MB7875.namprd03.prod.outlook.com ([fe80::2e3c:781a:5f98:7f19]) by BY1PR03MB7875.namprd03.prod.outlook.com ([fe80::2e3c:781a:5f98:7f19%7]) with mapi id 15.20.9520.003; Wed, 14 Jan 2026 09:40: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: 0afa870a-f12d-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HcnSbFcZAT+i8b4PuTsv2y7qfmmEA+qmmQM3LTy6hZuFirpFY/0tVjOd9rbFeywymubOlzvNTeXL9+yhGXmn43j1qitL6CCT7yo0Mliq96/4oQ1n02w/2bZ2Bi7xM1g6rLbe8Cgg6QbJ+j/SkkhHxeX8Fc9q8CzeDu9SUHaPaE/lNXAtVB1Asvf5b9uzryTUKfph17xTXWBO7pV+0Cgh2pbjiHZ9zMukiZ15evieCvmb7cuvnLRqaNJ+N3W1RzmI7any/4t49219HgRZdPNsdYfSwjd2ddtmijnHRa0NGS9Yrr2ird5hgZnBP9TMpV0Basw4wucGW/HMoVk3DdtJMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=s5Mf0X4KCin0qKB4UwdyPfmCEa8E3uKgTWUnpr2obR4=; b=Anru0lMRxMEPJuXNoQiP97dEX54rvvUcGHq1AHSzclGeIons072Qe+fvm/rGewaqls4MTc3lh0CxI1eSo6qMDtR6CX9tHcA8c2ZCT2VML5FMSJWvH1DatZzsfg1CWuweVb7r9M62GjZ88/7wi0lV9650fGLjG0qUancXLPLb1JCLJvVSEuMFzd662toKYkY6VfKXSMku4jE7OS+82XWeJ15YdvJKyLAecQvjf+mp3UuLqI1+HNFrYqQPDPcG2/hTuGccCj6KDwHwxNLbwWNp5J4H9aG/lTHuklqS/i+zEAFc+ZHPc0sQffTO96Ha0RuwU4Wyc6sTxY5PGfVEwNtyCA== 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=s5Mf0X4KCin0qKB4UwdyPfmCEa8E3uKgTWUnpr2obR4=; b=BLM9/gL0pEyQj89VfE8TRKzy+GWHJabUzjLsjyRBHWshI0vSaqNrPobtYCcyKrJ3h67mp+jB94mQgmqr4R6+55+nWmfg4yFmsj9b5W0wZchJzwUcd/XlDJgiQf6I2zC0Ym7rDyrOMU85yRdqC8Mmd119r3qpAidclhvH75Iz21Q= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 14 Jan 2026 10:40:13 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH 3/5] x86/HVM: drop at_tsc parameter from ->set_tsc_offset() hook Message-ID: References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <366597a9-c506-4183-bdee-8ef3d1045669@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <366597a9-c506-4183-bdee-8ef3d1045669@suse.com> X-ClientProxiedBy: PR3P191CA0024.EURP191.PROD.OUTLOOK.COM (2603:10a6:102:54::29) To BY1PR03MB7875.namprd03.prod.outlook.com (2603:10b6:a03:5b1::10) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7875:EE_|CH4PR03MB7553:EE_ X-MS-Office365-Filtering-Correlation-Id: db7372f8-1094-4c90-7483-08de5350ed35 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?dUg2bWg0cm1aY2dVUmdZMFdhUzM1SWRNa2FGNnFEVytNSTF1RVZmVkt6U3hl?= =?utf-8?B?cm5tMWxyR1cyZXpHS1NjVEhObmZQdVBOQUFBNFYwMGxvTnRGQVBRNy9sY1Q1?= =?utf-8?B?TTYvS1pVdWtiYmlXN1FqdDNVL2xSdklJTXA3Qzc1ZnI3NHFFZ1pHYWdLaWo4?= =?utf-8?B?MlVsVGppNS9obHN5YkUyWWVuQ1NsU1JKZHFHMG4rZzNZMmRQaEQxMDZMQWpJ?= =?utf-8?B?VmorZXlUNTBMS0R3QUlndTZ3TTVLdFp1dVdCemFKQWRCeVJHSEhqWG1BcXA1?= =?utf-8?B?VjZSZm5ORnNQVnExaGVsUDhIdERRZDNPelRGV2pCTHZZWGYxSVMxdjRTcWdP?= =?utf-8?B?akNDNGhCeENUV1BEZHRmVFRwQUs0V211WVpyYTFtdk82NGFHZjFIOHlKUWFP?= =?utf-8?B?Z1krWm4rU1ExaitkT051OWtXU1dDY1oxQ05WTldiWEtPN082SkJlZjB3WlJV?= =?utf-8?B?VFJXSTR3UGxWM3VreGJzN1hnYXVseUYzaEkwVmNSbHBzK3JuY0dUTXZDNDJs?= =?utf-8?B?T3FhNWVZQTBjYjdka0JkSnlSZWo2N3hDeHJIWmdON3J2NnBiSjZRUWRQaGE4?= =?utf-8?B?dFNrNzZSaUlQK3pIY05LNGFMNGZyNzBtOVkrR3NHOVdqUTk3NXFwd01zQzBM?= =?utf-8?B?cnpUL25iaC9USjhhWFZMOHhSemZ2RCs5NGFvOXc2ejQ1VGlRR3RWVmloU25E?= =?utf-8?B?WTZsRUQzZ0hGSFNzY1VWVEwrcERjNlBSdGtGcmpUdWQrWHpGejRoNUlFLy9W?= =?utf-8?B?OC9rQnhXNlZXMEhMOW5aYlpJdkFWanZzV1F1QzFab3BpOTdMR1NmSjFoN1k1?= =?utf-8?B?WnRZNmxHVEtXYlRnMWxldDlQcnpFZEVBWVM2WUxMbGpnN01FUkJuRHVLRXJF?= =?utf-8?B?K08rRTV3NEZySWxvZlBhR2FrbzdPQnpFRzNOaFFLL0NJdGJGclEwRzU3eWdo?= =?utf-8?B?QVVobmF2VmxHZ0c5NFhCbjlPMlhaREhDckExRlpiMW9mM1lmaEVPaDFTbjJG?= =?utf-8?B?TzNxL2pJbEg5YTMvS2EyamRHazZsTGRLdDJTUHVwdWlpYnk1R1RicW5ZQ2Fn?= =?utf-8?B?TGoyTzhLYjV2bEtEbUt4NGlmdE9aTkRySjZMRE1PeXdWeWVlZlhMRHhEU1Z5?= =?utf-8?B?eGErZis4U2dpK2N4TTdpSFJYZmlCOU1BTWkzTjhLNGJTNDFVNXU1a2NTa1ZH?= =?utf-8?B?cUZkZnl6cCtRTW9iWWlZeUdiVHh2dWRFV3drRlZ2S043QTFxSFk2NzlzcmZR?= =?utf-8?B?T3RsMkg3YURlVkJ1aWx2eDVaVG12YzJsWXAyOSsxbWYxa0VvVUZqN1I1dXQx?= =?utf-8?B?U0I1d00wQ2RjRnRXVkd2VmJIRU9oMFcyQlFxZk5TcUZKVklKT0UzUGpJRXl2?= =?utf-8?B?aVhvYVhDNU5SZGtxUTJudFlIcndZMlpJZWRMZUt4d0RFcU4yS0ZZVWVyS2Fu?= =?utf-8?B?NkxOZ3A2UmdjVmxTL05MbEZaaEkyZmFkN2gzeTdQZmlWQkwxcGgvTDRsaHFq?= =?utf-8?B?MkszMjFROWNZc1RXM3EvQW9EdysyKzNIUEx3SWRIRkFjOG9QTE1pYWJXcExr?= =?utf-8?B?UzBxbkMxOUJoTExLRFR0S3c4aitnbjFCTDVXVU1aN3ptU0xBSVBvQk1VYi9v?= =?utf-8?B?V2hsMkpvT2lKTXQ2U1J2OFhVY3k1MUs0cWlLK0tNNWpIYkpINlRYRmU3cDB0?= =?utf-8?B?aGNRbnEwKzUzNlZzNVlGNHlrZ1JOcC9Dc1lFbG5kYWZjZ0NwaUxVbDlFSHZw?= =?utf-8?B?eGFPd3o3a0gxMkVBTTZmU2FZY09EQVlkSUkvdUxzS1pGOWtPNUJCYWZsTzFP?= =?utf-8?B?WlU5YjVpVGdxeWg4QlZTclo4Ky82cm15MG5wVjNsdUhFdmkrWWgzbTBkb05l?= =?utf-8?B?TlRWekhhNEZkK0FnL3pNVEhxQjdISHNtdktaWDd4VWZ6RGFwNGZUYnR5Z2R3?= =?utf-8?Q?pAWlt29pZG31CKMUWOlBRGLOeChl4kcL?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7875.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?V09DWlhjQUJVaVdLZ0lLODBnemJzdW93VDhVdnFwck9zZmUvNk5pazcvK0FE?= =?utf-8?B?VmxCeU5qa2x6M3JIOUpmNjVYdG9EQkNHbXJ5UmZoUzNoeUJBTGFZNWZVSnBq?= =?utf-8?B?QVJ1THpaT0o2NVBvcFhCRzI2RGZXYndOWFFIT2MzTHJqblVQZm9heEF6OFJ0?= =?utf-8?B?aWdHRElMcmxVK0E5M2g2NUdnZzl5UDlSZGgvdWZGbXBuQitiZWVoNS8vUjEz?= =?utf-8?B?aXB0dDN2dUdPYlhKYkVSZHR3UTNHbVhpRHZoR0liM1NzZkZFWFNIakMyZXBG?= =?utf-8?B?cnMrZ0FJdC9saXh2Zlc2ajlEZzZIVEJLbDZLa2xKZDQ0ckpuazN5WS92WHNT?= =?utf-8?B?alJkQ1ZEVGlOMXhvUmtCQ1EyNFlzYkxsTklvdDVVb2pEMlJzVVh3ZDFwd2V5?= =?utf-8?B?QU5BTkNOSXB1QWJaZVhLK1JZSWovOFR4WWJwbUhlZE55SkgrY1d2bW1keTgr?= =?utf-8?B?Mk5nbStZeFgvQ3BuR0lTbXMzeHBRMXMrV2tPQVhVdFFBU3lFRlJyQlNQbERG?= =?utf-8?B?TGJvTko0TG5CWUJualRKdlYxOUp5Q25scG9PdWcvaEZxVFJQakRha1F6OVVn?= =?utf-8?B?Y2tUdWJTTnBYM1FHeTExUkhkb3J2NzRnYWRqRnFwVW94VS96NW9OaWhIdlpL?= =?utf-8?B?T0tuRUsrQjFUY1oxT1FvTUNRbjAxWnhpVllRWWhHcnFNOElBVHlnOW9lbVpD?= =?utf-8?B?TWRXM0R5M1FKa08yV0ZQN0M4eGY1UUZQQVhJSVNqYW9rLzVoNWhGK3c3c3Jw?= =?utf-8?B?aXdLYUk5Mm81d2RWL3hIeFFQSnFEYzRpR2IzWHFyT3B6eU5vcW9EWVRyZlF3?= =?utf-8?B?WG9KNndCSGdRNHREOTBnUTBwUnZ6RE1VajRhMGM2cjgyMHUvY3NlZmQ0akkv?= =?utf-8?B?TEZBQTczS2VzaVFMRjhCZVFiYXM1aG5CM0U0QnQ0SERQWGlJNmxzMXc0MDZa?= =?utf-8?B?SSt3MVF3cFNGUFVKdVl1OEtGYkdIdFJDaEc0UzFaMkZZak9FNnhueFBYM2Vo?= =?utf-8?B?eFh5K1p4YzdFMEdmNnVtZDQ5Y01Ma0ozY2hRcU1PYjNJQVh0N1duY2hPdERS?= =?utf-8?B?THNKdmN4dUxocGYvYWw0Zy9oUFFmOTVkNkFZcUIyRTU3eEg3QnpYWHY4SkNv?= =?utf-8?B?MWh2WTloS20vcndKUU1pcTZkNUx6RnE3Q3BJUGs5V3djdGhkTnRQbmFGNWsw?= =?utf-8?B?VitoYzczbUZDZEVNWUR2Q2ZPaTNCajZiaTRyVW1JYk9yUWU4RkZtQTJ2RWFV?= =?utf-8?B?UmtZcGE4UHJpa2Q1UjVUMTc3VjRRR3YyTytWS3FvUjZuS0xPNWJ4RDl4UjBT?= =?utf-8?B?T1B1dlduUkZ0Q3RKM090alhTZnd4VGYrblVLWm1neWdxRVFYM2xlVy9WZW9z?= =?utf-8?B?aUxOL2lGTFdSQlRwTnBvS0x1em8wNittekFybzNIem1jYW9rL0NlQTVXOWJG?= =?utf-8?B?UnVNdzZ1czdjMytFLzBseUllalIxZGtCRzMwVjUvcGJ0eklnWWk0RUJqQ3Yr?= =?utf-8?B?QnkwWjdrd2w1LytUZ2JIZUg0akJjN0ZieURWcFRadk9HNlE0UWFpNUhTU0xj?= =?utf-8?B?a2ZUMWhoejBxUVZaNFhhcmVFMlhLTzNWRkROaGlSQkNRSE5BSnN2cks1VmZM?= =?utf-8?B?M01lU1hQeUo2WWhEVU5CQWpSenluR3NYWHdwMCtjVC80U2hyYjlJa1Q4dXZH?= =?utf-8?B?R2ZXQlFLZXlJaHhROUc3QTcxVys0My9mc3V3a3RmU0VOSytkaHNCVFJvSXVm?= =?utf-8?B?Slo2RE9UR1FlSzVxZFZJQ1hZQU5CL3N4dDZEUG9wUTFMQmt6VExqcVJwazJr?= =?utf-8?B?L2JCTnJnZUxjd3pMOHZwK3JxVXJ1amJXY3U2V2dQNmFXbWNzb01VMEtzdHRJ?= =?utf-8?B?L09jNjQvend3TnRrSVdBWDZXYUp4cmVwaDJmY2RWSFVVaEM4aFNLWDBhZzkz?= =?utf-8?B?M1g4L0FIYlVxb3VMQ01ZT2d0OCt4WFdwV29Cc1dCTTdyWStSc2phUUpwaTQ3?= =?utf-8?B?TWZUUmZZdXZ1Wm91cngwV0FjTVZQc1Byb3lEb3d2eVUzQWZ2MlhDTWgrZG1p?= =?utf-8?B?OU9KZ2dCS1JwU2dKR1orZHQzd1J3UXRGV1phb243K1ZaUFhxZGl2VWVqSVBz?= =?utf-8?B?Z2pWZVFIVUI4azVIbkhmZUF6R0RXankyOEhiSVdvSlB3M0lBelF3RGFtblZC?= =?utf-8?B?U0JhU1hpVHl3WGI2Qi9GMVVTQmJmcWJSODBhejMxclNraFdZemtuNXcySmFy?= =?utf-8?B?cGlSdGhPU3Z6ZHBSU0pIbDd1em5Lc1NIdjNjZldoZ0lwZlFUMjM2dHE0RThr?= =?utf-8?B?OFg4THJySDZnSHJpaDMzcVk0WW94QU8yazZjOXBWTElXY2ROaGIzUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: db7372f8-1094-4c90-7483-08de5350ed35 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7875.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2026 09:40:17.8559 (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: r5IfrpLD0HPhnVmvaTkFcSpmru1o3SJr8jxGyGFQAVn1L9+AJgkoaBcIZnJE8GUJ093ujlVCb3C68R/409//wQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH4PR03MB7553 On Tue, Jan 06, 2026 at 02:58:54PM +0100, Jan Beulich wrote: > While the VMX hook never used the parameter, the SVM one lost its sole use > some time ago (while the original use of the parameter had gone away even > earlier). > > Again modernize types while there. > > Amends: 0cd50753eb40 ("nestedsvm: Disable TscRateMSR") > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 14 09:41:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 09:41:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202775.1518210 (Exim 4.92) (envelope-from ) id 1vfxNN-0004ht-D1; Wed, 14 Jan 2026 09:41:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202775.1518210; Wed, 14 Jan 2026 09:41:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfxNN-0004hm-A1; Wed, 14 Jan 2026 09:41:17 +0000 Received: by outflank-mailman (input) for mailman id 1202775; Wed, 14 Jan 2026 09: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 1vfxNL-0004UK-AF for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 09:41:15 +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 2a42770d-f12d-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 10:41:13 +0100 (CET) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-64b9b0b4d5dso17937136a12.1 for ; Wed, 14 Jan 2026 01:41:13 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8715952fc3sm885283566b.50.2026.01.14.01.41.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 01:41:12 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2a42770d-f12d-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768383673; x=1768988473; 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=d+KKqqMW8nxBukXV88HW+z2l/Nszr88m9Uq2V6byg8M=; b=huOcXBSjwrp+kaN/bMi9A/qlfMj05LuRIbUCK7PG/kKyGZILXK7tLGFrvyy3APS2GZ 08URedH4rkbwqiGQ5KOMmAjRqxUzXiO6t3A7cPuvvSCZ4a5HQjzKb6lffNbVAnjQVNLA SZEgIrqY+4GLW3//NeNNtKuHlgIAhijWm1jb0qMgbugRfOzPVoaqnoYaf4hZsY6xYjBC GWecUn/4T91+kIBES9OUv8Opd743JWESlAS0UKGPvcEBUfwFLDOydYQ6/cMCXpytmhJg SuAhEF7je7DesmXrhGBlrd+26jBlGVT+dM2zFBsQ96pkMKJKxD5m5fiYj3LtpOwYI/uL yf4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768383673; x=1768988473; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=d+KKqqMW8nxBukXV88HW+z2l/Nszr88m9Uq2V6byg8M=; b=sdDY85Y3Rs9sGnEXwFz9LuERtn/n6xOU+w3Qs+3BT9vQRRQBiZFvFAl/zDC1zrcWvH Vj9CnJ5oUOhVRZXZDbm5bTWdDdvndDSJ1lJ0jD98hr7dqtsyLyK3vsGtJeo3PNjxO77R 2R5+kKvtIg+hXDbriYAWVPuw/J3MJ0hdHEAmhrTIlEftfsBTVWs7AfqDwqO3XGJCy7WR E1EokPrxJy4GLGcuCGiFoTVYjd3QAWwOGTQtXP664WrOVLrYdkE3SbHfeMT4DdpO9BAd kPQDawVmTVTyH7/u4Bb9OeJlcBNt14rQ4JgKZANdpETF7ajr9YoFw+VHafCwR+PW4vCK ivww== X-Forwarded-Encrypted: i=1; AJvYcCVs6bCtVkmBZybxy1fTLsdUFUQbT29b9IRIHjeDCCgWz/j+B2GiBnhDEI5emj7orKHfnpShLPHENbM=@lists.xenproject.org X-Gm-Message-State: AOJu0YwTe8a2rHRT5e0Fb2p2u9CPJLvIn2gw7B3clFxsCPbDGBWZYXV7 vkv/kGTYMAaR4UFPLDxliQwInd8j5THFwx9e9jTEic/R6Ybtt5FT0SFn X-Gm-Gg: AY/fxX5sEG4+kBPuREiXtKZpQP4vqcXFM4h1+y5sLodngK+OAEv/Yf7NsgNxT1oEALu xewmO9yGv+Gvc7oME6sugw+e1AhYhaYLWj5G5iFY5hvanzhW3HDhXMYJqRvDAnPx9VuvGboW5Dz lbEtGK04JXxDF6TN5PITf5dez3vTyah6Ed4HjnM2QhKy7YHRaY5cgJT6be4Qt12usgt+GTIoXVm k4niDfJbJNFsiYFwo/iHKXAJMmPKsQXpzdfP7Ben3rkG1xBbjrftDhG+JuWBrrhhlPdN9J7Bdvw RASH6m7O9dth+tULER8KWpeV8L59OJht34MqqbGUwWn8SGMBE1XlysGjlvADVjfEaHEs/9Weik8 4nn76cGyfNnqnEXxN8OIioa4eZo3h2ej2jj9Jo7NwXo0fhdbeKeBpjqNV24wdGBT+a3+/tderlX GuNMyuEWk9fPwfvaDr1JthWVlFl88FKjhmGbj4HMOFh3qWXS/OKokAbspOiR+soO0= X-Received: by 2002:a17:907:72cb:b0:b87:d44:83a with SMTP id a640c23a62f3a-b8761135cdbmr175505766b.30.1768383672635; Wed, 14 Jan 2026 01:41:12 -0800 (PST) Message-ID: Date: Wed, 14 Jan 2026 10:41:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 13/15] xen/riscv: implement reprogram_timer() using SBI 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: <43249171def325c49541ebdac141fe99d159b60f.1766595589.git.oleksii.kurochko@gmail.com> <90e7fc60-09cc-4b61-ab0a-80037f8ecaf8@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/14/26 10:13 AM, Jan Beulich wrote: > On 13.01.2026 17:50, Oleksii Kurochko wrote: >> On 1/12/26 4:24 PM, Jan Beulich wrote: >>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>> @@ -39,6 +43,33 @@ static void __init preinit_dt_xen_time(void) >>>> cpu_khz = rate / 1000; >>>> } >>>> >>>> +int reprogram_timer(s_time_t timeout) >>>> +{ >>>> + uint64_t deadline, now; >>>> + int rc; >>>> + >>>> + if ( timeout == 0 ) >>>> + { >>>> + /* Disable timers */ >>>> + csr_clear(CSR_SIE, BIT(IRQ_S_TIMER, UL)); >>>> + >>>> + return 1; >>>> + } >>>> + >>>> + deadline = ns_to_ticks(timeout) + boot_clock_cycles; >>>> + now = get_cycles(); >>>> + if ( deadline <= now ) >>>> + return 0; >>>> + >>>> + /* Enable timer */ >>>> + csr_set(CSR_SIE, BIT(IRQ_S_TIMER, UL)); >>> Still learning RISC-V, so question for my understanding: Even if the timeout >>> is short enough to expire before the one SIE bit will be set, the interrupt >>> will still occur (effectively immediately)? (Else the bit may need setting >>> first.) >> The interrupt will become pending first (when mtime >= mtimecmp or >> mtime >= CSR_STIMECMP in case of SSTC) and then fire immediately once >> |SIE.STIE |(and global|SIE|) are enabled. >> >>>> + if ( (rc = sbi_set_timer(deadline)) ) >>>> + panic("%s: timer wasn't set because: %d\n", __func__, rc); >>> Hmm, if this function ends up being used from any guest accessible path (e.g. >>> a hypercall), such panic()-ing better shouldn't be there. >> I don't have such use cases now and I don't expect that guest should use >> this function. > How do you envision supporting e.g. VCPUOP_set_singleshot_timer without > involving this function? Looking at what is in common code for VCPUOP_set_singleshot_timer, it doesn't use reprogram_timer(), it is just activate/deactivate timer. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Jan 14 09:44:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 09:44:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202785.1518220 (Exim 4.92) (envelope-from ) id 1vfxQ1-0005JF-Pi; Wed, 14 Jan 2026 09:44:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202785.1518220; Wed, 14 Jan 2026 09: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 1vfxQ1-0005J8-Ms; Wed, 14 Jan 2026 09:44:01 +0000 Received: by outflank-mailman (input) for mailman id 1202785; Wed, 14 Jan 2026 09:44: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 1vfxQ0-0005J2-V6 for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 09:44:00 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8c4bdd65-f12d-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 10:43:58 +0100 (CET) Received: from BY1PR03MB7875.namprd03.prod.outlook.com (2603:10b6:a03:5b1::10) by CH4PR03MB7553.namprd03.prod.outlook.com (2603:10b6:610:23e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Wed, 14 Jan 2026 09:43:43 +0000 Received: from BY1PR03MB7875.namprd03.prod.outlook.com ([fe80::2e3c:781a:5f98:7f19]) by BY1PR03MB7875.namprd03.prod.outlook.com ([fe80::2e3c:781a:5f98:7f19%7]) with mapi id 15.20.9520.003; Wed, 14 Jan 2026 09:43: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: 8c4bdd65-f12d-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=KC0qqZVe7zViXaAbaAxP2mhJIlp0AVyAmiC0nBUXNYrWmKndLaajeqWpX0rTYiVXmwVHSV729R82QWwEaSDG5PoUgguXymC3Z9znVCDjxCo5g4jgkohg3Xzkxk7ns6q1Fc7anG8zrnBttezU9E4w5zV0dS70a2GrZ9LvfSnEgf+oGrblxToNdfXHTgbZYGJbA9HrezX3uBfVpmxDLSi38VOZsfObMTgfncjxOJ++a4RK0jRmCaNBJQN5ZJvjTKM0M0nSdwLDNlKtGrsTl4gD5RzIm5FNE2KtDszH/4Ruvn9mJq5fJAobb86+atXQi1BSnlPyBv0qsJpxyGg66rX+2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yiWWT5Lh5nvaMONFcR3IhJHMprnxl+EuIn9KkumOadA=; b=BDOp8eRsfeYhYADnWR7vRpLNIjgT7jyBRtQhS4i1Z1QDkxEbcLXwnQKA6AkOwhUrcgICv9wxTYq/Z9ZKBrsy+USFKKTuz9S/mnDZ25ea/cO2qjQw8TYCRBhh+NzpnKk7C/FaY47pLYdDEhxzZwQrc/3O3/RvwlFRHCnhtKhDgkIASh4RmzWAGuYk8HTZ9zqXf06rEr+cekk5p0vAgBCHv7gbnFBXFH6KUXJsIMplCY7dB8LkAMxltMG/qw8LKW/ubsiUtjlNE8zZlJvyq7+b28EDr84sc9tVldlar3neubRAqkaAQ6zzYraiVAcD8kg1SmVl21iTuYE9bLmjQ+fHZg== 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=yiWWT5Lh5nvaMONFcR3IhJHMprnxl+EuIn9KkumOadA=; b=kKgfTdYLMC2gV9gB1peeUfajo2oW72/1SFtmANGKi5mp0kzTcWv/EEfsmHzx0mtEAhibTC58AwmA8hF4Tb6k9TEn8ZM34sq1eRpVNenPJMkOZVe8MDxL9EcOK2bYDY9IHEXFti9xQrdOaVvwVY6JEfH3YfT1mDo4z/jTtHBtm2w= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 14 Jan 2026 10:43:38 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH 4/5] x86/time: gtsc_to_gtime() is HVM-only Message-ID: References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <79c32e1e-15d6-4b9a-9645-1429a21e63ec@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <79c32e1e-15d6-4b9a-9645-1429a21e63ec@suse.com> X-ClientProxiedBy: MA2P292CA0023.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250::18) To BY1PR03MB7875.namprd03.prod.outlook.com (2603:10b6:a03:5b1::10) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7875:EE_|CH4PR03MB7553:EE_ X-MS-Office365-Filtering-Correlation-Id: ff44b11f-2a61-4623-ad31-08de535167a3 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?MmxLbzBnQndoOHZPd29iLzczRFgrRldZTngyWTQ2eVlhVTRQeWd4MXBHZEc4?= =?utf-8?B?UXFjejJldWVRUXlMZlhoUWw1MjkyMVZORWh2b0xub2ZTMllKV2NSdk91WEtU?= =?utf-8?B?NzNLNmJaTDlmbjVkSjlUTEtKK1lqT3AvTHdzQldONFNJdlRBUnlMNlRQZ0E2?= =?utf-8?B?ZFAyVUhQRk5wSTh0VkxWNGFCNGJic0lBVWlTYTl5SlRFNTRlL1dxMGYrTTFS?= =?utf-8?B?OHlwVERvajI5Y3ZtSU9WdDJ2ZjFaS0ZXOTRqT20wc3NHalVEQzQ5RkNOSXZ6?= =?utf-8?B?eHd0dmV3M2N4SUREenVNcHovZmxtdVV2dWI2VmVnSVhwTFZVZEthM1ZUbnA2?= =?utf-8?B?eXdvS3dQVTRNSkFxajJXUHRZSHZEN2tyL3ljK20yS05wV1hIZUs3MnB4YUF2?= =?utf-8?B?b0E4QnYxS0JDY3Z2Q3ZZTFpCWllLMllMK3RTTmxWUDB5elJ5RHRFaklKeU1r?= =?utf-8?B?d2dSeVRjWHhaQ3Z2bVhhdmx1UHNPMUJ4bHlJOHQ2THdIeis0dklkeUE5QWNP?= =?utf-8?B?azZwTmdST1FYU0RGRUgxV1YxODVMZzZxQkdnSDkzUWRQVjdUcXlub2h3ZDdr?= =?utf-8?B?OXIwTmhrQ3IwTThOOWw3WUdpR3Y3Mkt2dy9JeTE3N3FlUHJLd0U3bVhGdWI0?= =?utf-8?B?TXVkSVhxTzg1U1UxMko3QkVaaExxcjhpZU9UUVFySXpOZEsyTDlGdFNndlNF?= =?utf-8?B?SUl0dmdWMXI2RnBSSnpzTVdlRWZQWFlsaWRvQ0lxejlJUWt6NWg4aVR6ck1Q?= =?utf-8?B?SlNIK0ZONXI2cVBUbG51eG1QdDNNeUI5SW1wYXpYRzhWLytoWjdXZjF6eGky?= =?utf-8?B?Tjd0M0lDR1hiV2c2Z3lMRWFFMFhRMlYwZVlNUXphSlZWcjRQWVN6b2Yza2xI?= =?utf-8?B?QkYrOU1CYUpSVTdFOERlakdIK0I5STM4eWNmaTN5REZ0QmFyNTk4TjZVNkhU?= =?utf-8?B?TWtscGlLYWZiZWZ5aHczUUFKU2prR09XOC95Ty9YanZ3SHB1bmZSZVprT3hL?= =?utf-8?B?SkFIZkNyTlhBZGd3ZmxWSDRXVGl1cGt3c0NzaGVUU1RhOEFFWEU0RkxwWFB1?= =?utf-8?B?MjhQay90L2hOWkN3RjRxMEJWMlpXb3B6aFlvbURHazFIS3pLZi9reWdHbjhr?= =?utf-8?B?RUQzRFlLM01BNm9tVUxSQzVadUE3U2J5YkM3L1lPQ204ZFdaNitmaERrRExX?= =?utf-8?B?MmljV204dWpnd1d1SW9nY1g3bVFvZWxXL0ZsQ3FHeFc3Z2pPY2dEd1VZSThN?= =?utf-8?B?M3hxWk9ZQmFtaE9oaXVBMTB3UlVyNHA4Z0hESXJicnJyZ25NbWpqNjJnVUpO?= =?utf-8?B?ZlBhNmhZamV4VjBwQUdSVmJSa3dMd29ob2RzZnJPQUx6S1F6MHdLN0VyZHRJ?= =?utf-8?B?cEdvQnZwdTdiZGxnWlozMDJaZnRyK09ScVJVRGNHT29SY3lsdDBid1doOFpT?= =?utf-8?B?N3FQUEs3SUlsNFpRbmo0U0xnbDI4Rk0vU2VoL2NxcER1Y2plSFo4NnplTlFQ?= =?utf-8?B?QkZvQ3lrWE1vQzVuMUdlZXdMY0lKTTY0QkIvMGhoVktlQ3pmY2xBQ0hVVFVF?= =?utf-8?B?V0xTL3R2NGc1NXRMOW1taW5NS3BsditUZHI5Z0ozZEVia05JUis0R0wzNDRE?= =?utf-8?B?cVdRaFJZNFhhVE40NGJJWTVLSU55aXhlWjN0bkIvWE9LSW5XM3RBSEJVRnlQ?= =?utf-8?B?eEtHd2IyOEdlbnU1ZTVNVHNvSStSdHFoaFB6akJMR2E2aExDVFBzR21lSktB?= =?utf-8?B?TE9vcTdaWXE0cnRja0tzaWRpelZIT0RXNXZOdnNyTGRUS2JuaUtMSzlQR1My?= =?utf-8?B?cW5MNVVXQmhWb1lKR0VUdjBaZ3dsUHcvalIxMUhkU2ordWxFcjBHY2FTWWRi?= =?utf-8?B?N3VqaHVNL29YQ3k1MDBrK2JmOElXN3hoaE1jakZ3VHFZb0pTQnhJTFlpdUJY?= =?utf-8?Q?VEyzOkLvLmr938iKWemxPKwirK1a5v7l?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7875.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?N3pZL2hzYlpzNk9Gb1YxaUluTERTYSszKzMySE1YeDdqU0poTEUzUkRncnZx?= =?utf-8?B?dW5aK1BXbkxqQVJaVng4QUh0QzVzVHNiVWdid0p4RmZqWmdoNWxYTG1EN01G?= =?utf-8?B?Q2F2UzZMcXJoeUtEOTd2UHFyWjRaaUFwSHh4WlpvTUNrdDJqTVdpTDdvRURQ?= =?utf-8?B?V01pSDNyK1BRQjl2bFRYbVdzZmtUTlBLbkJOcEQvNGtmNm1tRzJiU2Nqc3di?= =?utf-8?B?cldzZUFSdS8raUloOWJMbmcyajN0TCtwVDE0YXpSWmxOSVZXSzYySUJqc2c4?= =?utf-8?B?VDhiMHBHSEpsNHljRXQ0eXEzWXNDZ2NnQTNzRFRybGRUa2MzV2pGWjVVSE5m?= =?utf-8?B?ZkVJK1FkbVFkWDk4R2MwdkJ3aCtqUmZnMXg5WStOQ3hlSUpLU0V0ekhYTmM4?= =?utf-8?B?NWh6aTVHaXl6NnhlTHp5MjJaNmdIVmRVUE9pZjZxWjhOSTNlMSt3ZTkvd3Z5?= =?utf-8?B?UGFFOGpmamZNd1JRSWlFUHcvYkVrekVreDV1L0srMUdLSElBLzVtVHgvOTVK?= =?utf-8?B?MmlsRjF5Syt4d3hxbHNYT2VBUEhTajlYRUZ1SVg2aHBFaFB5QlZKVVJ5ZlJG?= =?utf-8?B?ZHVWN2ZCTnFWTTkwUXdpNjJ2MFM4V2l0dUNObmM2Y0hIQWtGczVsck50YldT?= =?utf-8?B?MGdteDBYeEExYTFqZnpsR2U0NGRMUGt4WmNZaXRveDJrdGtkbzh5SVJHNFhK?= =?utf-8?B?K3h6U0dxd1ZhNlhUL2tzQk43UWFGSFhmZzdaZ3UvR2NNb01xcU8vZVVEMDhX?= =?utf-8?B?VWVmNUFtQ3Y1T08xaTk3V09KNHYyVmJFMFVOR2NmZjRldjVBaG0wRDMrNEtv?= =?utf-8?B?YWJXZzJoUGdJd0h0RU9NTmFqYTlFREZEMmNpUkdtd0FEbEc0UkZWNVpkS1JO?= =?utf-8?B?cU9Yeko2a0N4dVlyeWtXMkFJaHIzSHlNRTBneDFYU203SS9vbFFYR1JoNnlt?= =?utf-8?B?cDQ0dzlDdlVsb05xa0pKVDdUeXp4d3ZGRTdsRURHUDhzalZlVG1NZVVVc2tS?= =?utf-8?B?MVpiUXUwVFVsck5wTWJSZ0lXbVFZUGU0NDhwbWgrd05IcW1GZmZsU0VUdk9p?= =?utf-8?B?ZHhKRHFEZnZhZ3llMFBubm9xazltemNIUHI2UEhWZXIwM1N0ek1hODNMTUZp?= =?utf-8?B?dEJwYVpGSENNeEg3TFhKL0FJQkF2OUNTaVV6MTMybGEyWTlQK2lqMUFzT0V5?= =?utf-8?B?RExIRDRsSjNYaEhGYi9VcDJ0ZzgrSmx0THd0bHlyMXc0M3czb2FKQXVmSjVx?= =?utf-8?B?M25Vb3hpMTNnVEFZQmIvQTVpQVZ1d0htV3l6NDVXQ0VWZGtsaE4wYkNTTVJI?= =?utf-8?B?VmphZUZ4eURqWEQ4ZDdNSkpVTjNockM2b2FETTRtNmhIOFYrK1RnbUVBS2ZM?= =?utf-8?B?ZldTaDhKbHI5SmZGeit1T3RpMTRDRFBTMFFBVGM1eGVRd3gxQU10Q01Lem9F?= =?utf-8?B?V0NwOU8xTWtSMG52NXZoSVM2b1FhKzZ6cW1IRlFhczJQeXp6bTh6TmpnWnVF?= =?utf-8?B?Vk9vR3JIbVRLeWlhbVpEV1U5ZmtXa3Y0aWZQTkl6bFFNeFExd3A3c2VwZkhm?= =?utf-8?B?Qm9mUUpFSnE5Umlub2UvSzh2TEtBbnJaV04wblYvbnBHNlNOMTdGY0RWeFVj?= =?utf-8?B?dkdXZkZBT0JIdVpZcy92MzRxU2ZycWFyNUN4TEY2WkJsN1J3OGpzWUYzamVi?= =?utf-8?B?S0kxOU1XRFFJY0doV0wzZEJvL1BlT09TMnlDZlllMWpYTEZKVHcxNzF6ZEJ5?= =?utf-8?B?Q3hBT25xUWU2ZXpZMmdTQTFaVER6dlhRanlhUmNlYzhuOTMvalFvT0wvOFR6?= =?utf-8?B?M1lzcWpHNm5QcWJtZnpTb0l3Vng1VlhjUzVraVhjckJ3YjV3aEt0TzJuZjNy?= =?utf-8?B?TjFKWFI1OHVjZVcwK0g4VU5GakpKcVJvOHRoUktQYWw3d25OaW1MOEtWUlNC?= =?utf-8?B?Z2l0UmtkbVlTbzY3dllPbW12UjNncTJqKzlGa1NhSjJCVUNrUmdtQkptOWk0?= =?utf-8?B?L05IKzhHekFxOEpjY2x0SWhncUMvejRQUEdqTDYyeEFTamRZaXpxSUdSTGU2?= =?utf-8?B?Q2RYMXNSd201R3JHcGtGTHFVVjYxd2d4aExLZUM4OU9zaDV1c1oxbDBxOE9Z?= =?utf-8?B?eFZHN3RiVDlQRjFyVEwyVlRmTzlRTUdnenM2MDVkNTY2aTd0L0xZTXRtcjF0?= =?utf-8?B?TmlwYlhjOUp5RVJKNXRsaGNXZkpPcVA0VVFLK1cxMUF0Ynlpb2tVNXJ3R0Vy?= =?utf-8?B?YldUK2NtVGtPcVJJc2xSMDFwaDdZblM4SERRaDg5YkliT2NuUFdZL0lVdlFq?= =?utf-8?B?NHBKa3lLTWYxZlNjRjhUTjhMNFpPQ05ha29Yc2pLK3NxOFhybTV4QT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ff44b11f-2a61-4623-ad31-08de535167a3 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7875.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2026 09:43:43.2491 (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: x8OvsU9lBwcOxn3f74yRbA2UYxL5w5QPfDfkqG7RvGLuf8Gpt58YPm7TSFoDcKjTTrOvmlXRl1bdlz+7+cqmfg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH4PR03MB7553 On Tue, Jan 06, 2026 at 02:59:43PM +0100, Jan Beulich wrote: > Omit the function when HVM=n. With that the !HVM logic can also go away; > leave an assertion. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/time.c > +++ b/xen/arch/x86/time.c > @@ -2840,14 +2840,13 @@ uint64_t gtime_to_gtsc(const struct doma > return scale_delta(time, &d->arch.ns_to_vtsc); > } > > +#ifdef CONFIG_HVM > uint64_t gtsc_to_gtime(const struct domain *d, uint64_t tsc) > { > - u64 time = scale_delta(tsc, &d->arch.vtsc_to_ns); > - > - if ( !is_hvm_domain(d) ) > - time += d->arch.vtsc_offset; > - return time; > + ASSERT(is_hvm_domain(d)); > + return scale_delta(tsc, &d->arch.vtsc_to_ns); > } > +#endif /* CONFIG_HVM */ Seeing this is solely used by the vlapic code, did you consider keeping scale_delta() non-static, and then moving gtsc_to_gtime() into vlapic.c? It would result in less ifdefery overall. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 14 09:46:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 09:46:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202802.1518230 (Exim 4.92) (envelope-from ) id 1vfxSY-0005tW-A1; Wed, 14 Jan 2026 09:46:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202802.1518230; Wed, 14 Jan 2026 09: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 1vfxSY-0005tO-7P; Wed, 14 Jan 2026 09:46:38 +0000 Received: by outflank-mailman (input) for mailman id 1202802; Wed, 14 Jan 2026 09:46: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 1vfxSW-0005tI-Tx for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 09:46:36 +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 e8dbfdaa-f12d-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 10:46:34 +0100 (CET) Received: from BY1PR03MB7875.namprd03.prod.outlook.com (2603:10b6:a03:5b1::10) by DS7PR03MB5653.namprd03.prod.outlook.com (2603:10b6:5:2c9::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Wed, 14 Jan 2026 09:46:30 +0000 Received: from BY1PR03MB7875.namprd03.prod.outlook.com ([fe80::2e3c:781a:5f98:7f19]) by BY1PR03MB7875.namprd03.prod.outlook.com ([fe80::2e3c:781a:5f98:7f19%7]) with mapi id 15.20.9520.003; Wed, 14 Jan 2026 09:46: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: e8dbfdaa-f12d-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=dypwA0ggMIL9lOSa7HRQW2aXNLWq8m0abVbmpwR07CL3EpwZ8toBtkRl+nHv+TxqZN6XMeFI7bXk3TAYNjsc89vHi+BaXutTlHz8vcbJwW0VhNpZgwA9AWl4e2d5H4Ti2nhp2YLjSU5miHbRxD/uInQHeLzlmTnxxKiOPOTgyYGPaDxoEs52DTmUDM2l9Ou3Q0S1cRUQXDtXuIQA6inIKUBEdSb8HIQ8DtgVacr5g71Nen+cp9qYQt2p2A/sKqd69yoyUk4dB+ykJs8QKFEjzq745OhjRn4ky5z6KB6raKR+opAsLNzPYwQ5JYOCm9gzQyaRGMQVJpe9Tbajby3Y8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=A2IM302llfb4oEErpfodosiaxgX7R77kHT2yj6APyKM=; b=iTeAkN8wCRix4HJDp00CqXEUoVkhaxMNmZhPA3uL0nPVrS1GImcuYdsaxgPCKSN0JwzgFa/eKl3INGkT5P3EF93fH0V4TcLSDHWjPNQQSJGaXZJAlSZpufH1TiotyNgTwFlKgGRs0dyqENVQDX3FWXnKSoT6A5Ju2KvWaV6qJ1ZNtFtcUmJRIiE8wKyZd5NArO3cWJC1VYghuyrSqO4bV7iv4FwpyU4nH2Kt1/GUr8n3D/Uzg0jg5MIAB32BbE13rRoJcbf4AdWiBy3aKAbrnS3yA6FquJburth5YLP/+Jm+M+WuxvHxhYAo7GpoPkFvxcy3FhHlpsbCKZLjR/peyg== 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=A2IM302llfb4oEErpfodosiaxgX7R77kHT2yj6APyKM=; b=y3z/2NK4g1zpME7cj5GFHrGY5W4AEQfDuyQMkz2Xd2n5Z1ViPedAMhLOS6H4Mo6wOPlFkdPZtG1NhtxshKmvkOcklyaiickUDa9L1RcqSEamGLCY0N09tZttvXKgrjFgB56D/M4wPrVmgNbPcH3rZqtZV/wkwf+BEexO1Yl3jeA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 14 Jan 2026 10:46:26 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH 5/5] x86/time: pv_soft_rdtsc() is PV-only Message-ID: References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <5467f5c4-e752-4d44-bbb7-05e6fa1a672c@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5467f5c4-e752-4d44-bbb7-05e6fa1a672c@suse.com> X-ClientProxiedBy: MA2P292CA0016.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250::14) To BY1PR03MB7875.namprd03.prod.outlook.com (2603:10b6:a03:5b1::10) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7875:EE_|DS7PR03MB5653:EE_ X-MS-Office365-Filtering-Correlation-Id: 10fc46b5-099a-43b1-d761-08de5351cb6e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?akV2Z2JGb3FweEF2VG83dmgreGtIc1ZSTHJ2a1p4M3VYSmdBR0IvM1ZEQkt1?= =?utf-8?B?NlcwMmROUzV3ZHZoTS8vY0ZaZVRhVTJjZmw3SStweWxJT1YvNEcyQ0pGMzFr?= =?utf-8?B?ZGc3aTZJYnpYMUptS25vSVdYUTZBbTIyTjJWeDhxMytUbi9KWVpoYnBvcDIr?= =?utf-8?B?YmxxTGZtZWpsNzdlek0yV2NXL1hzR1NIMWRLLzhqZmQ4OUhqNU5wTzNsallJ?= =?utf-8?B?aVNrRGJmbitkMzIwRGl5c0NiaFo1Rk1rWHpkbkJVdkMvU3hrZ0ZZbUVtVUNS?= =?utf-8?B?N0xzeWNXTCt5SVpZdStZbnlJbW1wZU85a2JlM2NJSWluc29Ya0RZNDMxbklu?= =?utf-8?B?UFJUQ0VpMVQ0M2dPWHRTRTVicm1Gb1ROaTdWTW0vTEZaeDR1cWdvdFNWRDVp?= =?utf-8?B?a2lYbm5LU21VOFF4L2hCM1lwc2RxRnlvU2hTR29CdlN1Y1Y4TENJb1VqWnZw?= =?utf-8?B?NjJLWXA0SjE0a2h1TEtYVDROUDJxMUlURlZabmlLeVBIZm8zUy8zNmMyZzBm?= =?utf-8?B?QXVmb1FUemJPNExQWWUwenRJSG5hdUlIZ2NiNUhrcnBhYmhoZ1ZITURRN29U?= =?utf-8?B?dFNBZmdiZHF2OGRrTkd3eU1vMUwzdWhUSDc3QmsrYkRtYmtnWVFzTEtYM1I5?= =?utf-8?B?RnNicktmdTJxT1dkOWlJV215QVoySmhzUlVvRm1keWpmRGR1bTNmWTd0QVlX?= =?utf-8?B?NjhHRWRMUnV0Mko5UXk2MGx5QXRrU2oyS01VMGZ5eHhQaHVaQkd0TWErMWkv?= =?utf-8?B?ZEgwY1pnUlZDMDJzUlVkK3V1RHYxaUl3TkpycnNBUEJMUnhuaXJPK2ZLd0xa?= =?utf-8?B?M3hpV0IxUCtma2tuY2lqeVFURlVCTVpHQUJiTWVZbUd4RzdPcWxQakZsTk5a?= =?utf-8?B?VjJKMFkrR21kbzNoVHd2bTBRSWpXMW4yaTFYYkpJeXp4cUxEU0hGRlBjMkZv?= =?utf-8?B?dFNYMjBhMExPa3V0cHNlaUY1NXdMOWpvcjYxaTdPbDRrY29DNGFzaDlkV1Bo?= =?utf-8?B?WElXOHU2VjJTYmdZZnBoUVQyaUpOQ1J2cjZOdlJhTDM3ZVc0RnpxRmhmV3gz?= =?utf-8?B?RFEvOW5sckpHTjBRNW1zeHFwenE0U0xOeDdhSUM5QUZWZWdHR1dnSzhHREcy?= =?utf-8?B?ZW5OQmJjVU1qTmY0RXRYditwRUlzUmFKbUZmaDg4SUM2VjhNSVQ4QmJzS2dX?= =?utf-8?B?UjVhdUwyTU81NHdHVmh5NmhhUThyakNCYlBtQ2NReXlvWnFUYWJ0M2lpejZQ?= =?utf-8?B?bEZxSHRSekVQRW90RFJ4WWs5c2VRVDZOZHAvUG9oU2dwU2Iycm03c3U1cHVr?= =?utf-8?B?V1ZyVCs1enRXSmttVlRWSG5PWHlxSVkvWmpnaUU5MUFMTFlFcWk1SmxtYmpE?= =?utf-8?B?OC9Hejd4L3Y3Z3lhSW84T0RqZHIzMVJweGM4V0VmejdObUxBZWtKN1BqZGtj?= =?utf-8?B?aWNCQTZZRjNoTVFZRHJGMmpiWVJiVmNONXMva2U4V2xZcXhDM1VkcWx3dHAx?= =?utf-8?B?ek9QbVNadkgySE43ZHd5cmx5NGR5eUZqSGlQQ0VqbEtuTTRTK3hiWW1zVEhK?= =?utf-8?B?ZzI0aXpyT1JrNVZ2RDI5bFRsSUpnR1M0QUtTZ2NKTDQyUXVnbUV0alZqRGdD?= =?utf-8?B?TFVPMGVvYTVsM3RQakhSNnZDQi9CcWZIQ2tiUkdjNFlzUzNrYTFKcklrTDJm?= =?utf-8?B?N1pseFJYTmZYNSsycmJXNHhKeGZFeWV5SFhnWmI5My9ZZzcxWVVha2E5Tkww?= =?utf-8?B?blUrbzdZbGFiWHlLYzlvRGpOQmFhVTRqVkdMNDlqVEhMQW5UVUJYcFBmQk42?= =?utf-8?B?Q0x1N0VuV0hTRjk0aGhPK2dVL2MyemNnNnZ0L25FYkNxSk9oRGVDaERPUHY3?= =?utf-8?B?OGppM3MvK0xyaXBWdmVQU0VFRG9jSTIwanREeW0xeGNTNXJsai9Qby8wYUQx?= =?utf-8?Q?egNZP7e5nHrqssdleKNv+eWNrNnsHnwY?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7875.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?L00wYlU0NnoxMTQ5dk9FMFU2WkFqZE11Nmc4djYwMGErL3d6WlRjcUZZUmYr?= =?utf-8?B?YzhycllNT0FDTUFBaURIOTJXZjY3bjJYaGx1N3NXendyZnFXeUpRcnF4QmtJ?= =?utf-8?B?clg5QVQwN1RWSW13RUpmL3Blbjd1RW00dkthcS9JWk05MHJXZGQzcFJGdzV3?= =?utf-8?B?S0F0N0ovMm40MURuV1VITGhicGUwMlNkck1YRWo3STNSbzlsV21DZytQV3pT?= =?utf-8?B?OEorUVBDRGFuSkNQNjMrNk1LK0NuK2YydGc1Zmd3RE1YckhLZUJmay90WVk3?= =?utf-8?B?dVJVaHcvc2ZMdzNtekVNOGNVVGtWYW1pWnR6WElDV1NQbXdlUjMyVERKV1lX?= =?utf-8?B?M1VyKzhFQnhHVjQxbE9tbmY3bkFyeit5YldHdkt0aE9JOWQrK0NidFA0QzZN?= =?utf-8?B?dVZHTzA5cEJoSmEvYmVKUXNnbFdpd2t3YU5QMDRCZ3Y3YVYrNDI0TFcxcUlk?= =?utf-8?B?ZFVHZW55VkRZdlVXWFU0MXplOVcvTCtJL0VTRkRQTUJZUEtSNFBSVnQySWpP?= =?utf-8?B?cmZzc0dxdElLY2p3TzF0cjBiWFc2RXZvckxRMUdQbERhLzkrQ1FRYm5xNVhn?= =?utf-8?B?cXBpTEl4MWEwZ2w1MTNIL2F0MXFIdjRESmcveUlBbS9QdG5rVVRkd0NEVnA3?= =?utf-8?B?M3FPdU5VYUlKb2J0d3YyZmpOMndNTENvNzhxdllkQjRwMDFKOXdDTWpVZ3k1?= =?utf-8?B?OG5aTnlyRmtoRGZKUlNNVTk3UnB2dlBvb2M2eWZFTDI2VkFVTEo3aFB6OWxC?= =?utf-8?B?YlZuUEMyL2VTZ2IxZ2hibE9wcWZCakI1UERnZlFqNlkyKzdFNmVua0hySHVt?= =?utf-8?B?NHJOWDAxWHNFTUZ5VzNrVVpMd3JwbER5L0VBTm1idy96Z1c2Uy9tNEkwN2tm?= =?utf-8?B?aVNpK3J2RkRpVDM5Mm1rQ0JibnVDUm91cytObmpBVWs2azMxQXlMWkJSaGMx?= =?utf-8?B?OHhJaXBLWE1CWWw4TksvaUNhVHBiOHVwaWpTUmpTWGkxVHVLNjFUbkpIK0pr?= =?utf-8?B?NTF2N2taaXRTNkV0ZlA0ajUzRFNHb1BhV3RtYWFsTVRwcVRFN0hacHAzdkt5?= =?utf-8?B?L1RGaHFBYzIxWCtmQUlYSmttKzBTdHp2Y3BheENjM3N5cjZxQ1l1V05UZWJC?= =?utf-8?B?MU5BeHZDTEVxY1o0LytBbzJRcnJFUVlwNk1DamZFSkR5SlJPbWFwKytxUDlT?= =?utf-8?B?bU1IOUFna3JwUWlBNnIzYSs1RHZ2UXUva0g3dkJCbTRjeUc3bmNTNjR0Unlv?= =?utf-8?B?UjYyaTArUzM4RUhiWTI3aisxRHJKTFdjdWc2eTBlRlBkWEtic2I5ZXdVR2dP?= =?utf-8?B?OHZKSGhpVTE0Y0JwZllTWGdDYUhDRWhKUVRHc3AxeXF6MTdXeTBCNDhVQlFT?= =?utf-8?B?RkNsTE9ZaFE3M0I0U0hmUDlzVVNnM1R1eDB1akVoYVJUZ1lLNHE1ZXQrL0Er?= =?utf-8?B?VXB0OXlUVW9IUndKU2tGai9LcGJvbURhb2N4VDhrSG1oQVlYQ0pLYlVmT3Fp?= =?utf-8?B?VWVBbUxtN0UvNGF2QkxKZzZySVFhWXVvTzhpbjZUcFlmZldrSTNhdEU2R05W?= =?utf-8?B?UFFQWFRoNkZXU1FjVDY2d3M5V2xpeEdkbFJTNzJZQXptQmJnbVp1d3F4azA1?= =?utf-8?B?YzBzMGwwZ2JSb25SS2hUYTVoWWhRZis4dXFRZHh2eWhTN2pMT0FHdm9yc2pu?= =?utf-8?B?RGtVaWNaTXZnUFkwTVRRWHJXelpaTm9Yb2VqSnpycHo4UkVoaVZqaWRwQzhh?= =?utf-8?B?a0dEWFcxOFlOdHZOd1ZKdDlZRUJTWWdxbXY0ZTh3ZVFDTkh4WkRvbUVwZERa?= =?utf-8?B?UElZWFNyVXM1V0xUK2hQRjdZK2VrUE9RYXRISUhGS0dHblZDaVpQOXVmYlpU?= =?utf-8?B?ZVAzSC90MUdKTzVTUjltTS9LcVgvVFY0T01wSHNNN1NJeUgyWVg1cGtZam80?= =?utf-8?B?bVBMTE9ORktFWGR4L3M2U2tWRXZYS2FhZFVkdm1KS1piWFJuK1dSR1JiZzVu?= =?utf-8?B?dm1EUnkvWTlKdCtiVWM3eitrbEUyWlNUYUg2c3pWOWNtcStWbytJbkd2RlZ6?= =?utf-8?B?MlJ4WjhXVXZsazVFTmVuN0JiYUhOTThBM2w4YzhyK3FXamRTc29odi9VaitR?= =?utf-8?B?R0FJTXF5RE1uUEVGRDNEcjJMZW1rdGkxaXpmMG9XYVlBMDdBdmgxVC9VT1BF?= =?utf-8?B?SVFVVFRRK1lkdUxyaUNMNG83b1A2a3lMN1Q0ZkI2dnE4a1QwdWtXUUZndTFZ?= =?utf-8?B?ZTlEbU1mNWxzK0xGbXlPbEh5OTUxVzlKR1k5WEFKdjhwakZVMkRpR2xCREFM?= =?utf-8?B?Um5yUzNyUDdNMk16Rms5MTJ3UWU0elRLR05nUWJQNFlVMXBNWUZkQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 10fc46b5-099a-43b1-d761-08de5351cb6e X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7875.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2026 09:46:30.4396 (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: qFxpVjfgvovvDC2tbLgMUuXXTuFZiV+/x+ii4AcsHjx/fO8XtzRj+Bdt7yITmJHPjyYoYHQQKJ3logiXrGnxnA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5653 On Tue, Jan 06, 2026 at 03:00:21PM +0100, Jan Beulich wrote: > Omit the function when PV=n, by moving it to the sole file using it, thus > allowing it to become static as well. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 14 09:49:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 09:49:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202811.1518240 (Exim 4.92) (envelope-from ) id 1vfxVg-0006ld-Oq; Wed, 14 Jan 2026 09:49:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202811.1518240; Wed, 14 Jan 2026 09:49:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfxVg-0006lW-L4; Wed, 14 Jan 2026 09:49:52 +0000 Received: by outflank-mailman (input) for mailman id 1202811; Wed, 14 Jan 2026 09:49:51 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfxVf-0006lA-2I for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 09:49:51 +0000 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [2a00:1450:4864:20::342]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5d57784e-f12e-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 10:49:48 +0100 (CET) Received: by mail-wm1-x342.google.com with SMTP id 5b1f17b1804b1-477ba2c1ca2so92838045e9.2 for ; Wed, 14 Jan 2026 01:49:48 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee573e2eesm19724455e9.15.2026.01.14.01.49.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 01:49:47 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5d57784e-f12e-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768384188; x=1768988988; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=YGfNd9JdEJdDxUNYzU7Z7H8QJOFbSS2CcL2abYsJoos=; b=C2GPJRtA73w9P1QSVUJiY2nv6UD0dvQg9dPrfAsTZnCSuJwA+m/DTPLM94u9vCi5LF Tzy6o/jfjTOAF1KHaZxE/QgsYYRR+WZzsoUnlL3XIuOV/zrQFy7jdraVvQbOFo1da0Iq mGL1Gsch628vwQ7VRA4S3ORijmMiU4ELqFkEowKzgn2LPdncQcYjM6vZJ+OEyAn04yCr VhQPb/9DMK6MKYDlaHNWh1+5tnun13bHpAVzC9AhdKoSfbcPkSbFgqJyViJmjVRCdEjB UAyhSt2KAwzUScygrXNWg/PEs0ZzjJBxnf2SE90wL5/XPCnphWVVBRCBmaZ24dXoS5oD eRkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768384188; x=1768988988; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=YGfNd9JdEJdDxUNYzU7Z7H8QJOFbSS2CcL2abYsJoos=; b=Cl3FH/fGlZnjrzhz+AGMp5JYlAN3q4049k5AJJiYvaGFDBCKkvwCVPDTCQP0NRUvxK TnozT4qB2hpC5/BfCzYmkTrW1HXNLzaUwoxT65lJbVYQbq9XY8qFvK5ObGVxbM7/qY5W YjgxakqBvVlLbFZgoauPncVuSP7s9mIyFLWymI+PEs5E85/+T5IKSXe/+3V+uGYZNLhb iDH4u3fKdVkNS/W7mwNi72MTWZnGf6W1MQxMqK2f54i3XCxjEcLvXAqg3O0IXeKZVFDU Kw24cqsKm5c+rAaeD3FCP6tS3sA38u/uF1RNZ6gvKK5u+8VhT3AiU4O6xSSbQFwQaU67 lpLw== X-Forwarded-Encrypted: i=1; AJvYcCUEWPLNrx+X2YLopc+yGS0aV4v7v9ejyujaGBzrlJstqziwkGtWM6n63QfFpHObzzHgHXXONBL1ZWI=@lists.xenproject.org X-Gm-Message-State: AOJu0YzuYTuAPYidA8OWdWenTvknWPNmkDo6OqyRywWn76xgZxXmQzeO aG3HCHauRWpT+RcALmG7LvneSvdsn3eVsBDAvbcFECqyRr9kOLdymKVzcasGLG5h0w== X-Gm-Gg: AY/fxX7mnndDjXem9tpq1e8/uR9R7Frd5lJTv4ETKz71vQuNzTQoP2niuS4jb5lgrP6 ZXLlxiiJ8f6v47LYt0z41X8PvFdKKwozVyNco0f7PJis6uF1owYIzq/BSlJMFM/fAGhUzVmkTXO 2LXudvns14uJ3AJH35PQTjf2C97Wt8STklU3vCwZMUn+6jwDxAxLmezXgnCH0PX2LN2YXv//MUP /ecsdZqEXHBFoK1JsD33+m+IQ8Hk5HTHGJbLtooHn+6zhfrnT47ZHKwPJt5X6FNXcNA2qqHCtS5 Ogd2E98ktMuZD5bXBVCU6T8m6gn+86UYSVy135ISxUUsII46NDWVfGo8kFy4ATiqYOEXsFhjrCm AdwEAI/IpA+SIzH2DDab6aZiQ69LtKBCyBt1t3mdAbCRmz8VFXdxn0t07BcVsWeKRhnSqW3nyiy n6zq43UER9DRrq2QiKimzwUXDlRPSZivnOFEXaCHsSENO/kZB9uMFxH7z1noSTIT6a5RzDuu42m vU= X-Received: by 2002:a05:600c:8217:b0:477:9eb8:97d2 with SMTP id 5b1f17b1804b1-47ee32e074dmr23625955e9.8.1768384188042; Wed, 14 Jan 2026 01:49:48 -0800 (PST) Message-ID: <00e17b41-f31e-4121-80c8-d4ea2bb02f34@suse.com> Date: Wed, 14 Jan 2026 10:49:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 3/5] arm/sysctl: Implement cpu hotplug ops To: Mykyta Poturai Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Timothy Pearson , Alistair Francis , Connor Davis , Oleksii Kurochko , "Daniel P. Smith" , "xen-devel@lists.xenproject.org" References: <54a015e0e47ea311471bad7f13fbf21e14389ef3.1768293759.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: <54a015e0e47ea311471bad7f13fbf21e14389ef3.1768293759.git.mykyta_poturai@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 13.01.2026 09:45, Mykyta Poturai wrote: > Move XEN_SYSCTL_CPU_HOTPLUG_{ONLINE,OFFLINE} handlers to common code to > allow for enabling/disabling CPU cores in runtime on Arm64. > > SMT-disable enforcement check is moved into a separate > architecture-specific function. > > For now this operations only support Arm64. For proper Arm32 support, > there needs to be a mechanism to free per-cpu page tables, allocated in > init_domheap_mappings. Also, hotplug is not supported if ITS, FFA, or > TEE is enabled, as they use non-static IRQ actions. For all of these "not supported" cases, what if a user nevertheless tries? Wouldn't the request better be outright denied, rather leaving the system in a questionable state? Hmm, I see you ... > --- a/xen/arch/arm/Kconfig > +++ b/xen/arch/arm/Kconfig > @@ -7,6 +7,7 @@ config ARM_64 > def_bool y > depends on !ARM_32 > select 64BIT > + select CPU_HOTPLUG if !TEE && !FFA && !HAS_ITS ... make the select conditional. But do TEE, FFA, and HAS_ITS each mean the feature is actually in use when the hypervisor runs? > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -176,6 +176,9 @@ config LIBFDT > config MEM_ACCESS_ALWAYS_ON > bool > > +config CPU_HOTPLUG > + bool Nit: Indentation by a single tab please. See adjacent entries. > @@ -104,6 +105,39 @@ void smp_call_function_interrupt(void) > irq_exit(); > } > > +#ifdef CONFIG_CPU_HOTPLUG > +long cf_check cpu_up_helper(void *data) > +{ > + unsigned int cpu = (unsigned long)data; Note this for the first comment below on cpu_down_helper(). > + int ret = cpu_up(cpu); > + > + /* Have one more go on EBUSY. */ > + if ( ret == -EBUSY ) > + ret = cpu_up(cpu); > + > + if ( !ret && arch_smt_cpu_disable(cpu) ) As you validly note in a comment in do_sysctl(), SMT is an arch-specific concept and perhaps even an arch-specific term. Hence using it in the name of an arch hook feels inappropriate. Plus - the hook could be used for other purposes. What the arch needs to indicate is whether the CPU that was brought up may actually stay online. That more generic purpose is what imo the name wants to cover. > + { > + ret = cpu_down_helper(data); > + if ( ret ) > + printk("Could not re-offline CPU%u (%d)\n", cpu, ret); > + else > + ret = -EPERM; > + } > + > + return ret; > +} > + > +long cf_check cpu_down_helper(void *data) > +{ > + int cpu = (unsigned long)data; Why is this left as plain int? Yes, it was like this in the original code, but wrongly so. > + int ret = cpu_down(cpu); > + /* Have one more go on EBUSY. */ Also please add the missing blank line after the declarations. > --- a/xen/common/sysctl.c > +++ b/xen/common/sysctl.c > @@ -483,6 +483,51 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) > copyback = 1; > break; > > +#ifdef CONFIG_CPU_HOTPLUG > + case XEN_SYSCTL_cpu_hotplug: Please see the pretty recent https://lists.xen.org/archives/html/xen-devel/2026-01/msg00329.html (scroll down to the xen/arch/x86/platform_hypercall.c change). > + { > + unsigned int cpu = op->u.cpu_hotplug.cpu; > + unsigned int hp_op = op->u.cpu_hotplug.op; > + bool plug; > + long (*fn)(void *data); > + void *hcpu; > + > + switch ( hp_op ) > + { > + case XEN_SYSCTL_CPU_HOTPLUG_ONLINE: > + plug = true; > + fn = cpu_up_helper; > + hcpu = _p(cpu); > + break; > + > + case XEN_SYSCTL_CPU_HOTPLUG_OFFLINE: > + plug = false; > + fn = cpu_down_helper; > + hcpu = _p(cpu); > + break; > + > + case XEN_SYSCTL_CPU_HOTPLUG_SMT_ENABLE: > + case XEN_SYSCTL_CPU_HOTPLUG_SMT_DISABLE: > + /* Use arch specific handlers as SMT is very arch-dependent */ > + ret = arch_do_sysctl(op, u_sysctl); > + copyback = 0; > + goto out; I wonder if it wouldn't be neater for this and actually also ... > + default: > + ret = -EOPNOTSUPP; > + break; ... this to fall through to ... > + } > + > + if ( !ret ) > + ret = plug ? xsm_resource_plug_core(XSM_HOOK) > + : xsm_resource_unplug_core(XSM_HOOK); > + > + if ( !ret ) > + ret = continue_hypercall_on_cpu(0, fn, hcpu); > + break; > + } > +#endif > + > default: > ret = arch_do_sysctl(op, u_sysctl); ... here. (Minimally the earlier default case wants uniformly forwarding to the arch handler, or else arch-specific additions would always require adjustment here.) Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 14 09:53:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 09:53:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202821.1518251 (Exim 4.92) (envelope-from ) id 1vfxYk-0008FV-6r; Wed, 14 Jan 2026 09:53:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202821.1518251; Wed, 14 Jan 2026 09:53:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfxYk-0008FO-2d; Wed, 14 Jan 2026 09:53:02 +0000 Received: by outflank-mailman (input) for mailman id 1202821; Wed, 14 Jan 2026 09:53:01 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfxYj-0008FI-51 for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 09:53:01 +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 cf0cd5c8-f12e-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 10:53:00 +0100 (CET) Received: from BY1PR03MB7875.namprd03.prod.outlook.com (2603:10b6:a03:5b1::10) by DS7PR03MB5653.namprd03.prod.outlook.com (2603:10b6:5:2c9::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Wed, 14 Jan 2026 09:52:56 +0000 Received: from BY1PR03MB7875.namprd03.prod.outlook.com ([fe80::2e3c:781a:5f98:7f19]) by BY1PR03MB7875.namprd03.prod.outlook.com ([fe80::2e3c:781a:5f98:7f19%7]) with mapi id 15.20.9520.003; Wed, 14 Jan 2026 09:52: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: cf0cd5c8-f12e-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=eL8sfaoc7JCFAXcdY5LJMmL3uG8oQv7YjrdPR9PvRHJDKTfL7EyO4qimgsm1Tcn+VnLJJ6NUrM8MviD12dWhxYlUBTot2W1U5uA5yMYHkK15n/ZtpOmjN8oKOtN3gyq5itkWJKSnp6M47f6U5l5Jl4AJL3xEL1Dt2F4qroSiwKu7p3uEsnpz6AQWojTjPUCo5RgrDRc9wfS6Shntp57cRQ0k5oU7f0eZRwH0GX5t/s9lfWAt+fWsY2bphOnzNr7wMLZlIfCbvffIQnpbAo27CIII0KXl2MiDbTWsXTJmT8JqQia/V6h6eb/Lnk3wRAhWiIHS3/tRwDmw3DfAR9/9zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LQXsGox0J2nDQ7zGjOnmuQKu+/3lCfMKMolkWae8U/M=; b=G8svYoVxvAnJcl8ODA7MK3e1q1FL+LQ5Zc2SEQlZULGdHC7uIRqsxE8KCr0CFJ/gAAUH4vW/9gPmdiI3yZq9isr0tCCaIgpy92DaPxNJLo7juX5/mVgjSgMPdSGSZYjSYrNQpVUoHb+5ei6IrAWgG2MH2XqmxyOKd9QQKkZloJn94Ow0vXER5mj7Vxt0QP29qVxXCMxjfLx6/CHHaZPInICFKRKE4wyxmO88SohwPmkA8E7BZcrF+dyQ9QsAUCiFG+/e2ilvl2Rezp6qt8O06XZubQOvI8YSJrGnCZ9EKGRAIO3Z5gVzi0i/SA2ECoxjtBIC2/fbEOEkW9JUufpI9A== 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=LQXsGox0J2nDQ7zGjOnmuQKu+/3lCfMKMolkWae8U/M=; b=0YZmyHPwHL5I3RSmdgu6/nWfxCTREtonx1IH+y5W3u8iuy9uFE5KjbQ/IxrwwzHMOTrz3EQvrjA3odq4nu0g3Mq4a+63tok7eMSPPNzgOJypt3sjwuJUX4hkLFcqOByCK3Wt5MGY2VUjy7U4bjxidlauKfSUND2rVuIFJfwpVTk= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 14 Jan 2026 10:52:07 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH 4/5] x86/time: gtsc_to_gtime() is HVM-only Message-ID: References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <79c32e1e-15d6-4b9a-9645-1429a21e63ec@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: MA4P292CA0011.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:2d::17) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7875:EE_|DS7PR03MB5653:EE_ X-MS-Office365-Filtering-Correlation-Id: 98beacda-1cde-4812-b8e5-08de5352a343 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?QURnR2NVN1Y3bFpYZ3V5RmdqdUFBQmhSN0oyZWJuN0k5aGVOdzhSWUlZZ09z?= =?utf-8?B?Rks3ZHdWMURCQ0JrV0ZneVdCa1RIN0R0Nk5MSGMreUZXcG1tM09HZDQ0S201?= =?utf-8?B?andlZEFxNzJwaWV0K3NLN3hzemlhMkhOWEtIdjRHL2JZSWVJdEMxNHNCVEox?= =?utf-8?B?bkVwaDZ5N3hEMk5VVHZ3eEVtQ01YWDd0QnVJcTVSTjJQSWVFTjF5cmVDKy92?= =?utf-8?B?UTlmV1VVZUlvaS9DeERLbTRyT3RwbDI0YzFPYllldWp4Nzc3T2tJQklmUnpl?= =?utf-8?B?Rkp5N0ZQNEpkNzdhbjJqY2FIbUUzQXo5N2FqZDA3VmtiakZVVXh4S0RTdFJF?= =?utf-8?B?WE1WaldHY09yRTN1MW4rTFZFYVYxTE5sczM5VWFBcCtBcG5vSEFjSyt4RUJZ?= =?utf-8?B?eHZoOUMxYkpxdGlKRUpwVXdwek1JTU1Fb0JmQ2lHcUQ0NG51T0RsNDBabXhQ?= =?utf-8?B?ZE9rMEY5Y2xDenkxei9PSCtqVnpkSzFzWGNoeEtUZ0RYL1p5U0lveENGaXhn?= =?utf-8?B?NUZ3UVY1cGw3WkZwczM4NGRoRzRMTXlueGVjVUtYQlpseTBDSXpHWVpJd2RD?= =?utf-8?B?TnNLVk1GaHJTd3dRM093TVYyWDNGUkpRcnpnNkN6eERHQ3FpRFlyTU91NVlz?= =?utf-8?B?eW90TnBXUWFIYTk0MU5la2dITE9hRC95VXoxNGhSNFA0Ynh3SlJvczJEQUE2?= =?utf-8?B?SmUxdEJCeEh6TmgrbmRSVzVpRHppZHNNSlh4LytnNTAzaGRJRm1Ccm9jaE9G?= =?utf-8?B?WjdodXBsaGR1NHFJUW9FdSs3QmtTbW5Td1JkajZEN2hLenFyV09mMk9CYlBy?= =?utf-8?B?QzQ0Nmd6WUo2Z3dVdkVBclVNcTBFMjBwY0g1UHpKRkx3WkVSMHhDOWtlUHd6?= =?utf-8?B?Vkd2endyWW1HcjVzaDFGK2l0d0Z2OEtOQnlhQXNyQ2x1L29aYkRuYXoyZFo0?= =?utf-8?B?RXhUcUxsLytYZVdlWnB1dFd1OWovMEF6a3pEQ0RNYUxMY0psUlBoamZrN1Qz?= =?utf-8?B?YnpvdmxTdXc4SmtFdXA3NVFLRXIyeUduZkF3OFFtV1dHdm5TRDJJUW9xd2Ni?= =?utf-8?B?TlI4ZUZ2emdMWTE4emVEUFdzV0Y2alVkWDJIcUN6anE5MDVWRDF2ckg3QWJM?= =?utf-8?B?SkQ1Zzl6WWk1L2I1Vk5TU0x6eHIvZU5sNzNFUDlNdlpFakJQUFhDc0R2SERK?= =?utf-8?B?SnphTklhZEFUZTVHcEYzbHMvR3gzbmRUNEN6RWJ1TGZ1SkVVd1pUT2hwSGZE?= =?utf-8?B?WkI1ZU9KWTNGS3dtUGl3TzhpMHVNelFJTzU5cElQalJOMEx0ZERJZ04ycHJ4?= =?utf-8?B?OW8zUVhHdU5DUjdvK29jYVZXTVJ6UzQ5WWlFNkhuVnUxQk5UQXhlTUpOUVJZ?= =?utf-8?B?akVJY2NDNFBjZnRMUER1Rjg1dVdDVDUwR2NYZmVjL212MHdLSThuSXFYZWgx?= =?utf-8?B?bFZUM3E0RXlaaTRQVWw1S0pGNDJ4VnZBemJtMGlnc1puSDJjckQ4RnMzMVdv?= =?utf-8?B?OE0zR01DY2t6MENHcVNMZnh1dFVUWEkrNEFpYVVCbHdORHZIWjBuRlN1UjZl?= =?utf-8?B?d0F4UDRybTVOWFpMbWU3Qng5cnZLNmxCcWdKcXBNaVlzYnRsejFZUDEyN0VK?= =?utf-8?B?d2tuT0xVT3JXTW9TaTErbUJySHJYZE5aMyt2eklEbEFvbktUNlVKRi9Rc2t5?= =?utf-8?B?eXM5dDIycEVLdVUrYlhkanZpZ2g1Q2Fzdmg4MkhMWVR1QkUwSy82dUJydk1P?= =?utf-8?B?MElDZlNBaWp3NlprYUgvcWtnRU4wSWpXRVhVcWJXNVpOWU9zUkRuMDR5b1VM?= =?utf-8?B?RHpZRFdnS3Q3b1U3Mm1zd1NqTWpNU25kSjloUktQaVJ3aVpVQnhBVEVYcW9a?= =?utf-8?B?L2dUdThWTDRvMGhuYUNEK0t4K2lHSTZ6aHhYTVJJdC9wU0lQV25tb1NWeHdx?= =?utf-8?Q?JA5ZjdG/FT3ddm8/V4Iv/tI6Og+XrLxM?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7875.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QUZOU0NOMUwxN0lhM0lYVWZpL1IvaitZZmR0bW0xQmVYM295YjV6UXVMWFp5?= =?utf-8?B?Y0tJeW5KZTc3Qk1abll5MU1QMGRQdk9kTEJXZ09McFY1ZmhFVzJ1dGlTTXFJ?= =?utf-8?B?N0lBR25iSXh6WHRnSExnamtiSm9zRmYxbjQzcjkyc1JjZVZpSzRTUTBSb0ly?= =?utf-8?B?UENmU01LRnZGRVFpNDNLRjZ1N2tZV091SHp0RzhqZGpUNWxlUzJqbkpyV2NG?= =?utf-8?B?SWFUQTk5TFEzc2kvNW9paitweWl2Ui9HV3ZDUFVFaTFHdWhGcFNtWURHdDM0?= =?utf-8?B?UU5pWS9HUDIyYVZraFpGNHRNMFNocjFTWnY4c0lmcDlLYjdaNzNWd0d0aWZk?= =?utf-8?B?ZWRRRXJTQzBMdE0ySW1YNDRHRnNiS3NaaHowRER2bWJHbVB6MmRSS1pZcHU0?= =?utf-8?B?TjlZY1lGa3pCbHhxazNSU3Q4cVI0TWJ2Z0V6SnZwTkpXR3dYY0RaTkRhWEJi?= =?utf-8?B?OCtsQm1BWXYyK0o4Y2NGc2t1eEFWRVRJajduNk4rdERCMW1NOGZtamgxd0Ro?= =?utf-8?B?T2JRRXozK3BZMHhFR042RzZ5MlRVdmg2QzBRM1JacnBGWUZGQ0R1NHJrWDBj?= =?utf-8?B?VVh1anFlMkV4NVl5Q0tNZEtzSTNGazh3ZzdzSlQ1UVhxek1vbVk0NVZ4eDdB?= =?utf-8?B?MjlwYUxEQ1hCT1VPdXUzZC9ZdVNWSWVvemtIRVkzQ2N2Q3QrbWdybTBGc1JO?= =?utf-8?B?SGtFRGRlTmRjMmlCc0g3MlBsSlZxRW50NFFiZnhNWVVvem1mdUV4YkhMczB0?= =?utf-8?B?ZkVZRGMyMVQ5d1JPWDN0dGwrSUd1TVdzcW1qTm9WY1crb0lYcE52S1Z2Tzg0?= =?utf-8?B?SVJOSlJrU3NlTkZJRFg5QU0yc2NOZ3VNS2hleWJkZk1NSW5KSUFLeE8vR1FY?= =?utf-8?B?T2RBdTBQRVBPWTdGczdNS1orZ0QyYkpQYkRaT25zMUhRUFFmYm5CVFhaRnJ5?= =?utf-8?B?TnY2czYyNmJlQ2UzV2t3NWZKbEZ6NTB6SC9PZ253ZzJjWkIyamEzdjZ3K0NE?= =?utf-8?B?VGEvOGhaWWlwODdBd1d3b3BqajBHbkR2UFJuVXo4d202bVVBa2FUSExDSklx?= =?utf-8?B?VktwUjhZa21jMStQZHRtMDJBSUdPWHhrTFdZQldHc3dFSmJQcWdOUXhjbFZV?= =?utf-8?B?Rld6cmdsMGFadFU1akxHd2drT0FMZmpsSUhKT1FTR0xnQWpzSzF5ZENQSHlx?= =?utf-8?B?SkdFY2I0akhSWlE2Y1JYMklaUjZsN1c2eThnOEN0Wnk2c3gySk5wbml4L2RB?= =?utf-8?B?bmtNKzBBNjFkSDJlcVIvQXh5M0NxNDQxTHRRWXUxNzVQQytGZTBRYkdWd2p4?= =?utf-8?B?VUU0NGkyZ3ArdWJVSE1aQVMxaTI4VGQ1UVhWditYNWtjMVQ0NTZkdDFVR0d4?= =?utf-8?B?YjNEdHZDU2x5U1hTbmwvVHVXZ3BKaUdPSlBvMm5FNm9RNEtRK21nRmwzVy80?= =?utf-8?B?OGowbyt3NWNyQTZuZkVPOXBpcnkrYVdMbEJ4enZqVDVXQ1pPVG53WDJubEJF?= =?utf-8?B?NzlteTNTUCs0R2NqZi9RcGJTbzRmMW9Ca0RpUTdITnZTVmVseDBpTG53QWVn?= =?utf-8?B?NHNYWDlhUFFQT25HN0RwSEpCOFBCdzZITUFGSE9ycHd1S0FyTk9lR2dkVmNQ?= =?utf-8?B?ODdnSHRRNGRJTkY5MEJMSTJ3VVR6OTBmNkJyRVptajQ0V0F6SjJlTFlQa3Fk?= =?utf-8?B?dmJXeVY5RzBTcGxPclcrOUNuaWgzaTBmTVZOZ0lDVllWdys0OUgxQndlQUdZ?= =?utf-8?B?dkJKWFl1VVpURHVBdlQxUWdYekZqRE1SOE5hRUt3dWx6MnlobGhVcUZSUm1N?= =?utf-8?B?Y2lYU3JNbHhCQjFMQWZaNDE1ZWlKNmsxVklPMXhIUXFGS3B5N1drdk9qdGpk?= =?utf-8?B?b2xLRFN3bExtTk5LSzBqMFNEUDc1ZW1YZFF1YTdtTlgyZjR6MGlDQm1JQVFI?= =?utf-8?B?cDhHbkg1cHcyenhhOHpERzBNZHZSVGZQbDhJcDBDVE1vR3YwTlJ5bkpFalF6?= =?utf-8?B?NGJ4QkdlTGhsMkkwa1VCQ3RKTEVuS1YvdXQ2ZmpXQi9SQjI0NldvVUwzcjFV?= =?utf-8?B?aGZqRC95ZVpqZk8xNzhVNzFwdTZwM1p1UFd1clFNamlyc2JlcGZFWXJKaUNU?= =?utf-8?B?VGJraVY1R05HbFVLcEpidDNCZnpHNGRhNDA0R0xwZTJpTDQvTGU2czduNUlh?= =?utf-8?B?Umo0YkUwUEtKbEo2TndmT3d1RXFLUGNqVnBIU0d2N1FiQnJDT2VUK3VmVjcy?= =?utf-8?B?NmY2VXQvQjlNcnEwa1RoMTB1am1HSmtDWjJ0amlwTnhqdnFzTjVQZWk0NkVS?= =?utf-8?B?T2o3S3hYcndoanBRc3VZRzIzQ0F4VUhJaHd5QlA0U2JVSWNtazJuUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 98beacda-1cde-4812-b8e5-08de5352a343 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2026 09:52:56.1284 (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: TJORWIOF0KvyEOTFjXaA5F7tkRgSpfQxFTY2xCCa+aOiulGf+X3g/fRMpIgz9f1T53EvlQ7EdhVG/xY0iBCLKg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5653 On Wed, Jan 14, 2026 at 10:43:38AM +0100, Roger Pau Monné wrote: > On Tue, Jan 06, 2026 at 02:59:43PM +0100, Jan Beulich wrote: > > Omit the function when HVM=n. With that the !HVM logic can also go away; > > leave an assertion. > > > > Signed-off-by: Jan Beulich > > > > --- a/xen/arch/x86/time.c > > +++ b/xen/arch/x86/time.c > > @@ -2840,14 +2840,13 @@ uint64_t gtime_to_gtsc(const struct doma > > return scale_delta(time, &d->arch.ns_to_vtsc); > > } > > > > +#ifdef CONFIG_HVM > > uint64_t gtsc_to_gtime(const struct domain *d, uint64_t tsc) > > { > > - u64 time = scale_delta(tsc, &d->arch.vtsc_to_ns); > > - > > - if ( !is_hvm_domain(d) ) > > - time += d->arch.vtsc_offset; > > - return time; > > + ASSERT(is_hvm_domain(d)); > > + return scale_delta(tsc, &d->arch.vtsc_to_ns); > > } > > +#endif /* CONFIG_HVM */ > > Seeing this is solely used by the vlapic code, did you consider > keeping scale_delta() non-static, and then moving gtsc_to_gtime() into > vlapic.c? > > It would result in less ifdefery overall. I see now this might not be appropriate, gtsc_to_gtime() is the pair to gtime_to_gtsc(), which is used in other places. It looks like gtsc_to_gtime() could also gain users in order parts of the code, and hence making static to vlapic might not be the best approach. I'm not overly happy with adding more ifdefary to time.c, and the asymmetry this creates with PV guest not having a gtsc_to_gtime(), but it's otherwise dead code, so: Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 14 09:53:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 09:53:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202822.1518261 (Exim 4.92) (envelope-from ) id 1vfxYt-0008WV-If; Wed, 14 Jan 2026 09:53:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202822.1518261; Wed, 14 Jan 2026 09: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 1vfxYt-0008WJ-D0; Wed, 14 Jan 2026 09:53:11 +0000 Received: by outflank-mailman (input) for mailman id 1202822; Wed, 14 Jan 2026 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 1vfxYr-0008VT-BD for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 09:53:09 +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 d37c3c2c-f12e-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 10:53:06 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-47775fb6cb4so46747965e9.0 for ; Wed, 14 Jan 2026 01:53:06 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee544387fsm19498685e9.0.2026.01.14.01.53.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 01:53:06 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d37c3c2c-f12e-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768384386; x=1768989186; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=bhY8qbSgd8DG8MqPWifeFMg6ub2ZmYQ2IL9+5P7hsO0=; b=RF1uCHh/ZqA0FTtBE5FL1Hr7mAeM1MuWA8tScoAcrfgvna3M34cIfgLp+hBsUkFKaU DZaWNPwz0hpDzi5NtuFkvmMI6l6HudSaAU4SGzoe+yE8GNNUzERxcZGObGbSz9Bc0M6/ GQ5mTQG65lKrvOn3GkZrkHswqdIJFHB0oja06A1ZmnrkQQm/dG54QPTYilLABdHijAh6 8hQlpg0dxU3CQQyrUVThT3JTb7iu8tCHZXlIbjq/U4oqwlXdx5uuJ7lW0uHQwGW70Ft1 aM4co5nSJDqn8ncqzzQSOWGG0Sb6JwrPtgo83oqO7q8z32b82idRSdGczyQPE5K2qIiG rRqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768384386; x=1768989186; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bhY8qbSgd8DG8MqPWifeFMg6ub2ZmYQ2IL9+5P7hsO0=; b=qE+0DUsw5jz/w0gWqTk5+XffeZb8/Tkob6g87Y3Z1D68KGEJMRDkfxCEDudMMonT5f Pkaxf13IimaSOcBjIxNFzj5wB1uwREkWgj5X+Jj51bAhPAaltz5fgS8MqRUMjp+sUPjg u0Y0VuxoqNfcFx8a997POwpvGCci3eMgHczltDlJCopgC+WTfEMjGcn2qFc3d+0Kw1Tz aI9G9C2KuSPl1JN8D6gHlI0TbDLWynG9AO8+2llXvlBhAuw7OVEZnx9exKV/EkUXuwhy GIKlGq1+4G7TM8bAEVUxuQ5m2R+Pq5Pww+8fn3FswAq8eKxvNtCR6hzy9FVNm0bx7Ohp BMgQ== X-Forwarded-Encrypted: i=1; AJvYcCUK5K9O56mXGfIm6eQ27JgSedSLRzLe1MBPHbtv29vNkP7o6ljGqoDlmwdrIzhvrfsZz1RX35ED/4s=@lists.xenproject.org X-Gm-Message-State: AOJu0YxlOOOX6gxgFVjA5dGhbu3w4uyJw/BcbG0yZfFNubdUO3rvgBXa cIuM4kgj19+Vw98i8KrXJ1D2J8CQIKj6M8fC6D2+C8+DHXPUYcRlujShdLIHPv6+tA== X-Gm-Gg: AY/fxX47LivFgh+rRcQ2Mms/F7HnclH4sgyeWdXt7Udt5ixhe5v/pIlEoKekE8Cv8ky l+vtduDkSQN2w3boZUvO2xn68Wm8cEOEObddaySg3j4DKbeK5A8aN3WCbxW7TaV+MyeFmQiOWZM UHnerp8YQSaL93WWDlJeSyZKKJrEe5ZA4gV+Lx/MVaELNE2G77KAMMH3IxwVqTeBOaMGh/MvJSI LlAOWNl2Ib/8hvG+mutgjklsrJo84RmvfqFc+VJyZPslcw74LqYY9pMtW3/BSjOYfswcLxzKtWC catvWlb/2JJ5V0u4KAKe4xvsjfuGXFW+9+iM0fSks6zgHKaL4B7KHX6FW/R0qyQbGEbT2P9EPw/ 5PRrIDluTRz8bumPZGlnY2C2xUxt2yJeAKTZ9fGqiYw+yexNWe7dWHzhvN0U7NKL1r3CWXGOHHm rM5FCz+/tUDUq0pPOzyJ/iO5qhdLrOezBK4miRkqXa3DqOaqJSf+p9peFO/cyje/9yBAG/eMDkv xU= X-Received: by 2002:a05:600c:3e8d:b0:476:d494:41d2 with SMTP id 5b1f17b1804b1-47ee33a1907mr21822815e9.29.1768384386303; Wed, 14 Jan 2026 01:53:06 -0800 (PST) Message-ID: Date: Wed, 14 Jan 2026 10:53:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 13/15] xen/riscv: implement reprogram_timer() using SBI 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: <43249171def325c49541ebdac141fe99d159b60f.1766595589.git.oleksii.kurochko@gmail.com> <90e7fc60-09cc-4b61-ab0a-80037f8ecaf8@gmail.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 14.01.2026 10:41, Oleksii Kurochko wrote: > > On 1/14/26 10:13 AM, Jan Beulich wrote: >> On 13.01.2026 17:50, Oleksii Kurochko wrote: >>> On 1/12/26 4:24 PM, Jan Beulich wrote: >>>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>>> @@ -39,6 +43,33 @@ static void __init preinit_dt_xen_time(void) >>>>> cpu_khz = rate / 1000; >>>>> } >>>>> >>>>> +int reprogram_timer(s_time_t timeout) >>>>> +{ >>>>> + uint64_t deadline, now; >>>>> + int rc; >>>>> + >>>>> + if ( timeout == 0 ) >>>>> + { >>>>> + /* Disable timers */ >>>>> + csr_clear(CSR_SIE, BIT(IRQ_S_TIMER, UL)); >>>>> + >>>>> + return 1; >>>>> + } >>>>> + >>>>> + deadline = ns_to_ticks(timeout) + boot_clock_cycles; >>>>> + now = get_cycles(); >>>>> + if ( deadline <= now ) >>>>> + return 0; >>>>> + >>>>> + /* Enable timer */ >>>>> + csr_set(CSR_SIE, BIT(IRQ_S_TIMER, UL)); >>>> Still learning RISC-V, so question for my understanding: Even if the timeout >>>> is short enough to expire before the one SIE bit will be set, the interrupt >>>> will still occur (effectively immediately)? (Else the bit may need setting >>>> first.) >>> The interrupt will become pending first (when mtime >= mtimecmp or >>> mtime >= CSR_STIMECMP in case of SSTC) and then fire immediately once >>> |SIE.STIE |(and global|SIE|) are enabled. >>> >>>>> + if ( (rc = sbi_set_timer(deadline)) ) >>>>> + panic("%s: timer wasn't set because: %d\n", __func__, rc); >>>> Hmm, if this function ends up being used from any guest accessible path (e.g. >>>> a hypercall), such panic()-ing better shouldn't be there. >>> I don't have such use cases now and I don't expect that guest should use >>> this function. >> How do you envision supporting e.g. VCPUOP_set_singleshot_timer without >> involving this function? > > Looking at what is in common code for VCPUOP_set_singleshot_timer, it doesn't > use reprogram_timer(), it is just activate/deactivate timer. And how would that work without, eventually, using reprogram_timer()? While not directly on a hypercall path, the use can still be guest-induced. Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 14 09:59:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 09:59:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202847.1518269 (Exim 4.92) (envelope-from ) id 1vfxey-0001LT-3f; Wed, 14 Jan 2026 09:59:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202847.1518269; Wed, 14 Jan 2026 09: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 1vfxey-0001LM-16; Wed, 14 Jan 2026 09:59:28 +0000 Received: by outflank-mailman (input) for mailman id 1202847; Wed, 14 Jan 2026 09: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 1vfxex-0001LG-6a for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 09:59:27 +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 b4e39e3b-f12f-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 10:59:25 +0100 (CET) Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-6536e4d25e1so2264001a12.1 for ; Wed, 14 Jan 2026 01:59:25 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6507b9d44bfsm22530193a12.8.2026.01.14.01.59.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 01:59:24 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b4e39e3b-f12f-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768384764; x=1768989564; 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=PYicekyITAX4irHFHrfOAg5BwT5oh5/ixpFZktRVUOg=; b=QKSrPU5UuhnV94zxn4oT0puzRU9dmpG5pmdkI5h7MeJbS0VNmwqGXLptWkBjrhRpI2 faCFdZNNnPos7xzf3tMBMkWz1HlRVt88XddgwjGuDMJUcUNXJxPQ9krVL+iFgXRJeuWL jov8hw9eebopUXbjle67iTGME9NhJ+j7XD5lxFPGV0b/9nWkaOBxGumRGmeRO/e5Sv6D Q9vt0E8ro/91vWZtsgYfHyd8r02cFs6YB5v3ZNeipk8jHukEFcXIbrweLoLv+MiEwlz9 tRbtKwi+BkcKHVIvSLnB0WvQ2cq3SgWpNKRSGcqCYadvmWm8stJiPPfZbDfEewETKsgE kURA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768384764; x=1768989564; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PYicekyITAX4irHFHrfOAg5BwT5oh5/ixpFZktRVUOg=; b=vDELpO8OWWVn3lc9xET8s8eQB90UJNaiVWwhGkQHcCsxGBBITMiRVl4k26R+l/tPVO 7V4Jpk4gcgw8XT9ejpruB6luU/m5oZA24QBm5/qQMXkJLdiuv6rbEPAyu7hdmz/8AEE7 W1MSfiOAZhVNeNwQbm67/UpGrydKHx8CiR9/8MgV8OsrltCBfgT64pezd3HfIvhxegs9 4BnxoPVL+fUfmQUJzH5tLP4UfZhgjxX/vbmmkecXgKhlSku+OudtBRi77neEjec4NXgJ TWNZi3tPxJ5/m5HHjvDyx+JzXJ+pZ+hcm9zwUDoaXTB1Rc3SOdcir+eOt6Fsz7pHoZ94 xuFA== X-Forwarded-Encrypted: i=1; AJvYcCVFjSOqKs9MV+5DaFZ6AMfrV9Xufy1tKoKQvQVbsTZo9WgAETlQJgRAEAFgNJSrnoaCAJ6n1pJu2es=@lists.xenproject.org X-Gm-Message-State: AOJu0YwvGaIa5+bDcsq0rxGTWaOBS5aRYdhfwytf8tO1JCxIeBqKeXTe v299oIrJIaaNBxkUyPE+fvQn/iZJzlOIX6H3D/71GxweUfiT9RSSRAc5Gjlz+g== X-Gm-Gg: AY/fxX6bIkVgdoDXphNBq7sIra1ADueOCUO/yn1DgCQjYQ63axW03yqoXL4lJU1P03u YWmBo9Dvn5q8MrGLTJNSdJ8rU/w9Mkxdibsm2wWxToHFdmkEPs4aCx+tVxg18ktU05NmTcTC0E3 uJGiEXbuYyhCzOLgvbyZOWCmo8u4lTsZ569m9sGOQ23lBDxNxofXPnOwZ79LmTQjM7Xrf0AInv2 KY3a6dExfoO4AoWSWMMufWHiWdFg508cV228ZcTOddneHSqX6aUKlx2ylHnpqxLg5jGibBHRaKt nGwe/p0pNnqZTQicD9UfZiIykLgnVtCQktY6vov/WLUnzln7ZbHlhn6a7v3vgB4a/4+At2z4NOT hGEuEGmsKLFdXl3S1XGbDml+tdTviGMBWAeohU6xRCRoanvYsu4UfKfSCbfo60qAX7UK1e2W9wK MB18Pqv6/3rcdPpTspGKWD1f4x9aJNv/B20TvCwUytSNbjxXd8YNzgbNkgehql5E4= X-Received: by 2002:aa7:d68c:0:b0:64b:458d:83 with SMTP id 4fb4d7f45d1cf-653ec11a4b7mr1117529a12.9.1768384764238; Wed, 14 Jan 2026 01:59:24 -0800 (PST) Message-ID: <6795ad9f-d755-4898-aaf7-c88bc6f9f754@gmail.com> Date: Wed, 14 Jan 2026 10:59:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 12/15] xen/riscv: introduce sbi_set_timer() 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: <84cf8fb2331614c6d0cc6e9030571f42bfc6d928.1766595589.git.oleksii.kurochko@gmail.com> <5f658f5b-1c22-4bd7-9f25-f89576d5003e@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/14/26 10:07 AM, Jan Beulich wrote: > On 13.01.2026 17:33, Oleksii Kurochko wrote: >> On 1/12/26 4:12 PM, Jan Beulich wrote: >>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>> Introduce pointer to function which points to a specific sbi_set_timer() >>>> implementation. It is done in this way as different OpenSBI version can >>>> have different Extenion ID and/or funcion ID for TIME extension. >>>> >>>> sbi_set_time() programs the clock for next event after stime_value >>>> time. This function also clears the pending timer interrupt bit. >>>> >>>> Introduce extension ID and SBI function ID for TIME extension. >>>> >>>> Implement only sbi_set_timer_v02() as there is not to much sense >>>> to support earlier version and, at the moment, Xen supports only v02. >>> Besides this somewhat contradicting the use of a function pointer: What >>> about the legacy extension's equivalent? >> I think this is not really needed, and the same implementation can be used for >> both the Legacy and TIME extensions, since the API is identical and the only >> difference is that|sbi_set_timer()| was moved into a separate extension. >> >> Since Xen reports to the guest that it supports SBI v0.2, it is up to the guest >> implementation to decide why it is still using|sbi_set_timer()| from the >> Legacy extension instead of the TIME extension. >> >> I think that I can add Legacy extension equivalent but considering that we are >> using OpenSBI v0.2 for which Time extension is available it seems for me it is >> enough to define sbi_set_timer to sbi_set_timer_v02() for now. > Feels like here you're negating what just before you wrote in reply to 10/15. > IOW - I'm now sufficiently confused. (Just consider if you ran Xen itself as > a guest of the very same Xen. From what you said for 10/15, it would end up > not seeing the TIME extension as available, hence would need a fallback to > the Legacy one. You are right, a fallback to the Legacy one should be provided for such cases. Actually, it is why Linux could be ran now as it has its fallback too. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Jan 14 10:33:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 10:33:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202870.1518279 (Exim 4.92) (envelope-from ) id 1vfyBt-0006tp-If; Wed, 14 Jan 2026 10:33:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202870.1518279; Wed, 14 Jan 2026 10:33:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfyBt-0006ti-Fm; Wed, 14 Jan 2026 10:33:29 +0000 Received: by outflank-mailman (input) for mailman id 1202870; Wed, 14 Jan 2026 10:33:28 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfyBs-0006tc-36 for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 10:33:28 +0000 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [2a00:1450:4864:20::62f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 75199773-f134-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 11:33:25 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-b870cbd1e52so510024366b.3 for ; Wed, 14 Jan 2026 02:33:25 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b870889ac26sm1040581266b.28.2026.01.14.02.33.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 02:33:24 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 75199773-f134-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768386805; x=1768991605; 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=rgAfa1yLWbGs9M2xhWgwMQab8J7/IoMLZh/Ypl2FAwA=; b=M/ZNzT/6mzE8n1bD9TTC2bC2FAZND7Pt5jaKuiPm6sMlbbRXRwMAmwaSCWiddEutTD z4DWZqfa4DdTNL+6e/2LhhgeYW8KO8ZF8A91Oznp+6E8hismVvgTyUJLkjhUCyOnNV/H npAum9S5vGUNnbz5B6omS4wjXeNADPFYlWY88uNFdW8baQluDopFadtOjc7gueem4ISR Utgv24fUzDeiGwvvC5E/R08Je4ch9aXQcF4ayC91vTsGAxNcYogoj7H061VFDATb256e OpP7VGXIyDGOidfhEhbyxR2WfP+JSw5BFlcbxsyyT5Kzq8UprnRU8wBrc2pBdjexGZfK aWHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768386805; x=1768991605; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rgAfa1yLWbGs9M2xhWgwMQab8J7/IoMLZh/Ypl2FAwA=; b=xNPltCfmqYuOsQ5E5mLWjp6paVRgM72Ty8smQpM6HswdASfZ0UfUhZ9CTNDSXzwd6K kCB1VlOjPF3vAJtUcWbk//zN1Z1Ms5BqyMBtPf1Rssfe+lyg+GzPu9awGY63bRR8wblp SsPhHrUmizptvlngCbT2MARvapRB5AHyxoxc2haX5GXkQ3uGbvMTEqGRl9uq6siqPgJ4 ZYettZQTK093OfR6scsr8SZm4Y97kH70peo9CrXUn/Ta5zFnXA4rBSjv5qhDwz5BsoX1 h1nUvZl+N8V77iAOl1T9PnYrE6NoiTxwscNI+73VKhBb0X8ed+DBKmCzw0pzNLgq8TZb ZVfg== X-Forwarded-Encrypted: i=1; AJvYcCVtBNP8vSkWek3ynroLB5OPm4RjdEwfL2Ftuaa6LLL28dLBYrO9NGxoAKL8A+oUDXTgwysAICqbIOU=@lists.xenproject.org X-Gm-Message-State: AOJu0YynakzYXcj34AKsXJBRRiVR7ir9JBBk1M/72t9/dGKZkCnbY7ta uf7YtdJZSSMSDaxUBEjPApe3eOKjRAKkXXU62iRcVSiOdDCkqfEXudkk X-Gm-Gg: AY/fxX7bXHko0ZPOJWHUS/pH9BjncCcwp0gMvIVq/wj5rtytLEqgBBQ0q8L6v2HB71M z1+gGCqRmsHNLKAJc5cH8VIYYaqdDqnw1wSvfqBj9Keko2Rdj0DsvKyK/6LF4UskonIzBPnZF5p 7worR4CHzTZeF2I2uYxcWcev3koBgRgqIGfOfJ37XZCQp3E1ryM/E8K/iXu8IVrKQBMlIBYF72G +pZZ4QEtcDUWnYxbg3y4/On1jnP3cgfflTyaeGVspISreor+pLHv/K1kG0F2Ka7Yv9JdHlFcJ7H v9Fz8Bhq1vmHDvT3zAKCD/bq5RVxSwxDKni57VmfvHVyYUz7hyGs6dtUorBH8AdqiJKjz0AdCET bNB4Lx/hdxK3WNrBNzozxOpXRmH886oT/zbNb8TYeEZ9IoUJgWQPwNC1b2CrbH9keshjKgSka96 wWQigoxX9LD83sJgONEJbJLKonyx2fZOeiaML6K3zRtbqQZcU8E3ewSfVPgKO3ELg= X-Received: by 2002:a17:906:f049:b0:b84:42e5:2b8a with SMTP id a640c23a62f3a-b87612dbed6mr193184266b.58.1768386804491; Wed, 14 Jan 2026 02:33:24 -0800 (PST) Message-ID: <4141bb71-7aef-4287-aefd-92009977294f@gmail.com> Date: Wed, 14 Jan 2026 11:33:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 13/15] xen/riscv: implement reprogram_timer() using SBI 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: <43249171def325c49541ebdac141fe99d159b60f.1766595589.git.oleksii.kurochko@gmail.com> <90e7fc60-09cc-4b61-ab0a-80037f8ecaf8@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/14/26 10:53 AM, Jan Beulich wrote: > On 14.01.2026 10:41, Oleksii Kurochko wrote: >> On 1/14/26 10:13 AM, Jan Beulich wrote: >>> On 13.01.2026 17:50, Oleksii Kurochko wrote: >>>> On 1/12/26 4:24 PM, Jan Beulich wrote: >>>>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>>>> @@ -39,6 +43,33 @@ static void __init preinit_dt_xen_time(void) >>>>>> cpu_khz = rate / 1000; >>>>>> } >>>>>> >>>>>> +int reprogram_timer(s_time_t timeout) >>>>>> +{ >>>>>> + uint64_t deadline, now; >>>>>> + int rc; >>>>>> + >>>>>> + if ( timeout == 0 ) >>>>>> + { >>>>>> + /* Disable timers */ >>>>>> + csr_clear(CSR_SIE, BIT(IRQ_S_TIMER, UL)); >>>>>> + >>>>>> + return 1; >>>>>> + } >>>>>> + >>>>>> + deadline = ns_to_ticks(timeout) + boot_clock_cycles; >>>>>> + now = get_cycles(); >>>>>> + if ( deadline <= now ) >>>>>> + return 0; >>>>>> + >>>>>> + /* Enable timer */ >>>>>> + csr_set(CSR_SIE, BIT(IRQ_S_TIMER, UL)); >>>>> Still learning RISC-V, so question for my understanding: Even if the timeout >>>>> is short enough to expire before the one SIE bit will be set, the interrupt >>>>> will still occur (effectively immediately)? (Else the bit may need setting >>>>> first.) >>>> The interrupt will become pending first (when mtime >= mtimecmp or >>>> mtime >= CSR_STIMECMP in case of SSTC) and then fire immediately once >>>> |SIE.STIE |(and global|SIE|) are enabled. >>>> >>>>>> + if ( (rc = sbi_set_timer(deadline)) ) >>>>>> + panic("%s: timer wasn't set because: %d\n", __func__, rc); >>>>> Hmm, if this function ends up being used from any guest accessible path (e.g. >>>>> a hypercall), such panic()-ing better shouldn't be there. >>>> I don't have such use cases now and I don't expect that guest should use >>>> this function. >>> How do you envision supporting e.g. VCPUOP_set_singleshot_timer without >>> involving this function? >> Looking at what is in common code for VCPUOP_set_singleshot_timer, it doesn't >> use reprogram_timer(), it is just activate/deactivate timer. > And how would that work without, eventually, using reprogram_timer()? While not > directly on a hypercall path, the use can still be guest-induced. Of course, eventually|reprogram_timer()| will be used. I incorrectly thought that we were talking about its direct use on the hypercall path. I am not really sure what we should do in the case when rc != 0. Looking at the OpenSBI call, it always returns 0, except when sbi_set_timer() is not supported, in which case it returns -SBI_ENOTSUPP. With such a return value, I think it would be acceptable to call domain_crash(current->domain). On the other hand, if some other negative error code is returned, it might be better to return 0 and simply allow the timer programming to be retried later. However, if we look at the comments for other architectures, the meaning of a return value of 0 from this function is: Returns 1 on success; 0 if the timeout is too soon or is in the past. In that case, it becomes difficult to distinguish whether 0 was returned due to an error or because the timeout was too soon or already in the past. It seems like at the moment it is better to call domain_crash() and change it if it will be necessity in the future as I expect that the only negative code which will be returned by sbi_set_timer() will -SBI_ENOTSUPP and if this SBI call isn't supported then we anyway need a different way to set a timer. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Jan 14 10:58:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 10:58:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202888.1518290 (Exim 4.92) (envelope-from ) id 1vfyaC-0001Zb-El; Wed, 14 Jan 2026 10:58:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202888.1518290; Wed, 14 Jan 2026 10:58:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfyaC-0001ZU-C8; Wed, 14 Jan 2026 10:58:36 +0000 Received: by outflank-mailman (input) for mailman id 1202888; Wed, 14 Jan 2026 10:58:35 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfyaA-0001ZN-55 for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 10:58:35 +0000 Received: from mail-43167.protonmail.ch (mail-43167.protonmail.ch [185.70.43.167]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f66a3f00-f137-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 11:58:31 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f66a3f00-f137-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1768388310; x=1768647510; bh=NVfvmKzgrJAEn5XrxiS+E6nAdepF2NP33nCezVWZu8Q=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=g+1mJd7QPSPdvvJ7JC+RbB0ZMOQKIJs5Gj5LuEqkfDRh/SYdEtNWZ4Z11Sa+WTu7J lOnRbev+xPTMiagF3lwU/pbET01kH8j2RkPkuXhDYHXTukxuRhgXwekW7LQVooI1fV Q4ISxtxgbAlL93y1Doj13pTLV4VVDmO+D2A9g16qRMUL/MDmAEydFPe6nx0Wdi3O6l e8NZ+NK4V8MNSm5613fOk+hOZEcWE4tjbvvNDuu9UOwUdmR/xIX8TNJnSdSElBucfw TuWe78JHQG+KfmSIEgsupRZ+maplSI/P5rea8HLa/8BV1RxWnhT7+4T4w9q2tE9UU8 w49O4etCbW0Og== Date: Wed, 14 Jan 2026 10:58:25 +0000 To: Jan Beulich From: Milky Cc: "xen-devel@lists.xenproject.org" , Jason Andryuk Subject: Re: Cpufreq drivers not working on T480S Message-ID: In-Reply-To: References: <7dbd26d1-0d9a-454f-90d8-5a7f3d8e12da@suse.com> <8a2125c7-c5ec-4be1-a7a5-61b2936cc90f@suse.com> Feedback-ID: 171106842:user:proton X-Pm-Message-ID: 30c71730f5c6aa056b2207ebd2dd618288ca6ad4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Just wanted to update this thread to say that now another T480 user (the T4= 80 is a very similar model to my T480S) using the release builds of librebo= ot (as of 26.01 RC1) also has the entries missing from the ACPI tables. Tha= t discussion was here https://codeberg.org/libreboot/lbmk/issues/394. So th= is confirms that I'm running a standard libreboot, rather than a bad build. Do you think there is any way to avoid the underclocking issue with Xen on = such devices/firmware? From xen-devel-bounces@lists.xenproject.org Wed Jan 14 11:08:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 11:08:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202903.1518300 (Exim 4.92) (envelope-from ) id 1vfyk5-0003QN-C9; Wed, 14 Jan 2026 11:08:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202903.1518300; Wed, 14 Jan 2026 11:08: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 1vfyk5-0003QG-95; Wed, 14 Jan 2026 11:08:49 +0000 Received: by outflank-mailman (input) for mailman id 1202903; Wed, 14 Jan 2026 11:08: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 1vfyk3-0003OU-8q for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 11:08:47 +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 62535220-f139-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 12:08:41 +0100 (CET) Received: from DUZPR01CA0058.eurprd01.prod.exchangelabs.com (2603:10a6:10:469::12) by PA6PR08MB10739.eurprd08.prod.outlook.com (2603:10a6:102:3d8::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Wed, 14 Jan 2026 11:08:37 +0000 Received: from DB5PEPF00014B9B.eurprd02.prod.outlook.com (2603:10a6:10:469:cafe::bf) by DUZPR01CA0058.outlook.office365.com (2603:10a6:10:469::12) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.5 via Frontend Transport; Wed, 14 Jan 2026 11:08:53 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by DB5PEPF00014B9B.mail.protection.outlook.com (10.167.8.168) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Wed, 14 Jan 2026 11:08:36 +0000 Received: from DU2PR08MB7272.eurprd08.prod.outlook.com (2603:10a6:10:2d7::16) by DB9PR08MB6731.eurprd08.prod.outlook.com (2603:10a6:10:2a4::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Wed, 14 Jan 2026 11:07:31 +0000 Received: from DU2PR08MB7272.eurprd08.prod.outlook.com ([fe80::5d34:206f:373:a323]) by DU2PR08MB7272.eurprd08.prod.outlook.com ([fe80::5d34:206f:373:a323%6]) with mapi id 15.20.9499.005; Wed, 14 Jan 2026 11:07: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: 62535220-f139-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=w0lBKP1oH7ijk0CZl0g7AwLMAcuzlWUDwDCPJeniFJUD1LDsV0PjtMnJUWMGXlw2pdPr3BaaZZ06lfIdUrfGVtLjGwQgVd49X8ZCrZxBogxiVtKkkvIlt8lb+qJQA0EC7mlXSDocMXJZUY5Hn5cYxXyWO06ove/bEzgtsTiN7k4KBSkyN1kkj6Iw8LyZcJLyhdvYdbLiuOjli8Nsm9hoZpDlGhXBuSkffRKHY9h0qV4XKW6pWVhn3c5Enmqa3jt1UdsuDDJPaiEKmMK8BvWvl6/7gOP3UeBo+wpl/NnQqDG9hmjzRvbjjXLb8WlC/i/Ivw5Q0+Y6ffciYVwtjF8LkQ== 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=uaSyDhtGvTHeVrT4IN3p8vE5r39tyrkkpkQ7ahmkb8k=; b=WP/NL+7G/NnSAWXZe/nlcuum2m/no1PwGGLA3BkdtPhJtl9BlvBXR0+OLI0SmO424i//T0Gz1mKZvLMr56b+b09W3jn4eO8LXPuq5dQPD6M4otlr9aQe4KD/XlC9B1HoOraA5Ya6WgKarvrcWmSGFqVywMWxlu+FWUK65cbivV62OXsgQtnsRZpmfG/hqoBs0PucgZwHFvBRohgnBoxRVJ95PGSR+VWb2gN0PlkdIIKCkBLDO6kL3oZA/uyzJoqb/HI6nXCmCyYbccQc4/vqGtrcdgx6crK38XGykAXu8SWFd7yuEHA+BiUqW8J4lPeQ4FBSBFG9AsgMOU7A4Z88bQ== 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=uaSyDhtGvTHeVrT4IN3p8vE5r39tyrkkpkQ7ahmkb8k=; b=GCqzWLN23Ss+PwKAhGG/m546C1Px3VtQHuF6JfDmwPkWtvQ1PskAIWTODyohASEbZP0aYglmdr+lVITknEPHGWPFj6hGD66HsMKzVtcUByE31ykVPX+M+W7QD/V7IUvV8dE4plPBWckxhiJq0IrGbcMzPYxn4ljmqWZ0XK0wp1M= 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=vA2qBdJYENzP9GXQoF02GNcm1HzGp7ADlOcKLQn8UymPshoZVv+wRqZw8qERoNYzLUB4pG/r3445CTUwy/T8kibUwkd3l0X2RVnXed8+zXcndTkelvQNy04OsZN6C8OLU38jjyPp7fOjXSSHsP0Pu7ooaXV+gFmvft4f62TS7dPeId9bYlKTKkczMv4K0FaLPwhjcg5kh62zgoa08at7Jah7ASHOyNhBShEn/ZmeA2SPPP2c/2iROhxN3yal3MhVV+1ykWHfQTJAIc6ocJju20XwDQEIqtCLFnXWNXPi9yKrdRqKfi4TobdifC5iPHZImZYLK5OkKAWSgEv+YFEy5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uaSyDhtGvTHeVrT4IN3p8vE5r39tyrkkpkQ7ahmkb8k=; b=UnftzqI9MjGmILGEu1BW2otC1l8e3uWSRTBYtDLRXwxwGQ1gyivS3Z1BmnoJdxE848XTljmWBUc8/0zGbRmoALwx2vBv/VAujAT19xhRKJDvcJWiMFQghTkWheJJP0ijIALv3GPBoxcmUFJMZFQL5zG8EDsP6f8/E1fBNxiaELhlLOtNclM24c3R8ygD+eQbP9yZem5eL3wfQq48U4xxosENSMxd7jM2DT00BOHc49Lg/0PcXhtnDRLzYX71QYFxZFQt5GU17NGiVN4aJTO2JJlFtSN0Us3Uv/9B/83TxplsUe36amcW9lunO3drftl1bUFP6m9ySCfvI79ReahN7A== 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=uaSyDhtGvTHeVrT4IN3p8vE5r39tyrkkpkQ7ahmkb8k=; b=GCqzWLN23Ss+PwKAhGG/m546C1Px3VtQHuF6JfDmwPkWtvQ1PskAIWTODyohASEbZP0aYglmdr+lVITknEPHGWPFj6hGD66HsMKzVtcUByE31ykVPX+M+W7QD/V7IUvV8dE4plPBWckxhiJq0IrGbcMzPYxn4ljmqWZ0XK0wp1M= From: Luca Fancellu To: "Orzel, Michal" CC: Harry Ramsey , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Subject: Re: [PATCH v3 2/6] arm/mpu: Implement vmap functions for MPU Thread-Topic: [PATCH v3 2/6] arm/mpu: Implement vmap functions for MPU Thread-Index: AQHchThCncyVuPEinUCTQtinTDX+lLVRgV4A Date: Wed, 14 Jan 2026 11:07:31 +0000 Message-ID: References: <20260113162309.6766-1-harry.ramsey@arm.com> <20260113162309.6766-3-harry.ramsey@arm.com> <1cb6fc36-fd16-499b-a616-4d321ae83572@amd.com> In-Reply-To: <1cb6fc36-fd16-499b-a616-4d321ae83572@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: DU2PR08MB7272:EE_|DB9PR08MB6731:EE_|DB5PEPF00014B9B:EE_|PA6PR08MB10739:EE_ X-MS-Office365-Filtering-Correlation-Id: 3878e3a5-7c2d-411b-c264-08de535d43b6 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: =?utf-8?B?WERmRjhVRXhOL3dYV0JESlozaVRsT0Y2dXM0MG5sdHpxdVZOOFpzWFRVdTRV?= =?utf-8?B?SEpiMjZhSVhHcHhsVlhUckwvZkZ4T2RneXhoajBqQVM3QkFYaEZraVgxT2h3?= =?utf-8?B?cUpKN0hqZXhFUUdHOUJZVFF4ZGQ5U1N5aWFoU05XTjJGR1pqaUtrSlU3YXRM?= =?utf-8?B?dXg1ZGNRRG1TZE5wczVmdWF5VU4veXB5NjdjOFpXUG50NTBCOU9Xazh2emRB?= =?utf-8?B?RElCWTc1cklzMDNvVHdoQ1llREI1NHFLWUpqb25KYjNGM1UyLzArbnlSZFR6?= =?utf-8?B?U3ZldzRiQlZtYXhvd0RDS2dvVnc0Q1BnNmlUWU1oYjNrZ2VUcTVGYm50Rnpz?= =?utf-8?B?T1BPbElUM05yQXAxcmp2bHF4R0NSMWxIb1pFVEk1Y3d6NGpmNFFIcWx0bTVR?= =?utf-8?B?bTRVU3pieWpuQ1VyMDQ2VGZzRnA5VGdrSTMzMldORURsWW54eStFZmFlRW9G?= =?utf-8?B?Z2ZPTDJJLytHemoyUkxoeFBBbnQ3Njlqc1V2cHh5YXBLNkRZNnlTUG56WDlH?= =?utf-8?B?cDFpZmRlOFhBVjlWMkVZRHNrM1pXSEw0TXM5VmtBSkIwU3hoaEdtUTVYdW9s?= =?utf-8?B?b1U1cGhuWlg4ZTgvTmlhdHVXRHZwODlMZGhWRnVlMGxoL2djMThnNG95M1BX?= =?utf-8?B?SER1S2tlbVlmSFhGbU85TmNpQUt0Qi9MMXRYTjZRc01vU3k1SFI4aEtoYll3?= =?utf-8?B?T3lkN3FXUS9CUi9jTnl4TEw1Y2toQS8xZUYzYkI1ZzF1a3dBV1dNSWJYUjNr?= =?utf-8?B?MVlCcE9CYjA1TnRjM0xkQkhBb29UVm43ZHBwZmxPbzRIQk5GNnR5dVp5R0ZU?= =?utf-8?B?bDdmQjBtaFZDNjB4b0d2RjFFd052S2FwRDlzem9Jd0h3RGRSMDRNWnpjZk5Y?= =?utf-8?B?NCtzam5xNEF0N2NMcVJKSHM4cEwyNmFNZE1kSzVrTFVNTzVFSGc5bnZmZDF2?= =?utf-8?B?dUhxc0JYNnRQUDY1K25ZeWpSOHJ2aXMrZ1FnekxsZkxFWSswSVFyOHUwUEor?= =?utf-8?B?ekhoWXNLaXNHbSthK003cmJPcVo1QW9yOXRSSGFKQ3NpUnhnRmQ0MGFTQUty?= =?utf-8?B?bzQvV003aWFLdFNWMVVVV3huOEIvL1FJQWNqQUxpazFxQzJlWjF1MmFSbTBI?= =?utf-8?B?K25xb24zd1lYZlhDZk5zbFF6T2pwU2RZVzZUUlJyd2hlUUZrRTI3YVVVZmwx?= =?utf-8?B?OVE0UlI0eCtXYTZVWDF4TlNWTWJURWFuRVZ6b01SV3VHb3lJWWM5RGpuSUg4?= =?utf-8?B?eGdQSFBsWFU3UFVYcUlzNXdxY3ZvTVNRNW9FMGdlQ2JBVzhOYlN0Y3lxMXJM?= =?utf-8?B?RHRyMGxZdjJpaDdvczkzY0RZV29IbHBhSlVsdTBtVkN5ZjlzRitxblZIWUdp?= =?utf-8?B?eWU4aE8vSVNKbDFIb2xnWGwreWhwQXdKclFVbFNHSnV6dEJxTkkvZzVmSDVO?= =?utf-8?B?VkNhckgxcWNsbXJNTTk1UmNCUWs1eFcxZStXS3hJOHlKbWVJTGF0SENtYVd2?= =?utf-8?B?Z2kyQWNPL2pBVjI5QXZkWkFHWXgxdi9FTVBSdjFmRFFFdDBMVy9aYXJ4K2xt?= =?utf-8?B?YW1QZ015c0FpbFFidTY4SlQxRXhibGpJTzVqeDBQbk50ZzNxRW0wM3dzeDdY?= =?utf-8?B?MDZOOUhXdHZJMmZvdnVYWHg5ZW5raURkdlkzMzBIQzZGU0U0eGQvYkk0citK?= =?utf-8?B?cERUVDdmSFFxQ0NuQnYxZmo0Y3Q1eTl1eU9wWjVKQjVYTEtJY3JZWjVHZW9W?= =?utf-8?B?RVg4OUZqZ1kvTkhYTVNPN2pXckg3ZzNNVnNmWHFOS21BaDhvRFdrTzNnSG1V?= =?utf-8?B?R1dHN3F4b0t6KzcweVM0ajd4WDFlTjZBSUYyZ1F4KzMxbjNERWR6cXNxR2Rl?= =?utf-8?B?M2Q5M0swV2I4MENLc1c0U0EydTE3elR4S3FtOUFLblQyTmJ4SUtQQWpUeVcx?= =?utf-8?B?YUEzT3d0OEc2YThCWWpnZnQwNE5wK1VqaXFNOUU0Wm83U0hINGdKK1R0amlX?= =?utf-8?B?SjQwT3B2Rzg2ZDIxRk9hZXhWd0tRZW9aSmFTVnZFcjB5TjRESGxTQTRzNGMz?= =?utf-8?B?K1NKNHI2eEtLQlgxL25EejhNQm44Z3JwdHVMWmZOUHYvMzYvNlVBellPbzhX?= =?utf-8?B?YU9GVVlUTnA0WVpOMytEbGUzSlBueDgrcEN1ZHhPRE5TNm9sL2pla1VxcWU1?= =?utf-8?Q?EHaRsovSdVGzMTRw8A3Ui2U=3D?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU2PR08MB7272.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="utf-8" Content-ID: <197A0A4407FA344281EDDA37E96D53B3@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB6731 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5PEPF00014B9B.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 96488539-c4f9-4f50-e731-08de535d1caf X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|82310400026|376014|35042699022|14060799003; X-Microsoft-Antispam-Message-Info: =?utf-8?B?NGhYUE9ucE1qck51MVZlT1N5Rk9udmZ0Zi9ta2dpRHFRaUJlSldIdVhxalZa?= =?utf-8?B?VzJRczRsRlBFUFRGdmNsZHlMVzVOaG80L0RZR3ljR0NnaDZBdE84MVlJenl4?= =?utf-8?B?UXREbVViOERVbG9JQklYTkRHbHZRVm1kVmlzU1NDQ0VkL3FBY2laR2t5dUZu?= =?utf-8?B?NmJXUVZodXJFNldjelRCbWNqU1VpdVhOdEgxV0lXcjVoZ0RYbVRrOGw0Wlhh?= =?utf-8?B?WnJzc2VWbEVueFgyY3hGMmNGa0pncXhYMW9kRml4bjFidzVzWms3Qm45QVR0?= =?utf-8?B?SUI1WFVjaDFDRitlV2lYc3BSbFhvSHFramVjMHhWQTdLd3o0bzFONzhNSjc0?= =?utf-8?B?WHo0MnBxbnp3UkpVeDMyQm42TUdXa21FanllOUIyR0dnRm1DVGxlU3VRUjlr?= =?utf-8?B?S241L1dZaFBkaFJZei9TejdXVEdSNDc0ZUY5bUpGVytDak5nb2RvdnprYUVp?= =?utf-8?B?VXgzb3JDRml1cXl2Uy9Uc1gvR0I4cnNhQzJTVVRIeTJvNW9Kd0ZaV2Njdkdm?= =?utf-8?B?dm44N2JiQ2hEbmovYWZ3dmFiV3lVY2t6ekN0K3cybVVwZTJGVGllbVlXQWpn?= =?utf-8?B?NThKbUFrUEp5ZWkxRkxYb1J3OG9QWjgrMDJvWlcxTHVIU3oybTkrRmcxWGNB?= =?utf-8?B?WGw0dVY4MWtyV01TQTQ4Y0JjcVRDSmo0Z29DdGFBWUJkMzdWUklwMVY2cEZP?= =?utf-8?B?K2orS25JKytaNEp2UWlnMUYrYm42RCtTTXBFbWpGdG1aenlCeWFuQ3hPaG1z?= =?utf-8?B?bzZwVmFjaU1mRjBqdlFKUnhuKzhFYUsyVm5ZL3dON21UUkU3eVlaWXBabG9C?= =?utf-8?B?N1dheGZHcndHOFc2TTIrRkpwdWhqUVVZSzhpdmJmeFVYUVVQd1NNVTlJVDBP?= =?utf-8?B?bzM2VUMxU2ptWnV5bTUwcVdCV1lnRjBGRzFNQ2N1cFhzV2pTSmI5ZUtFcjdp?= =?utf-8?B?VHNlTnVLMUhWc1Z3dFlhTGcwU0JucjZjNWNVbHJ5WXhPekk5azc3OGtwRE03?= =?utf-8?B?OVFkdDRZWnRJWEJ4ODdBdmpPd2ZRZjcxd29rVC9SQmY5cDVzbFpOYmFCSlJU?= =?utf-8?B?emNTSDJXU1hmaFduUWIvQTFRQit1VVU1RWRFVFB4MW1ML3VTbk1JSHV6c01W?= =?utf-8?B?eUU0OE5HL2oweFNpeHNneVF6b2F2N0hrTU5IZ0NBaEFTU2VFM2s5dkxmcG1S?= =?utf-8?B?dmtZZG9jTWtBUXhmVkpGSmREMEZEOHZjQi9MdFhkS1Q4UExyb3J2KzJTSTIv?= =?utf-8?B?WEorWUdpQ3M3Q2JzR2NkRzM5aVdnbmx2am5nUUNLNGNmdE1EZTFmbmVMYXc2?= =?utf-8?B?RFFmbkhBZUdnMTV5Z2NiRmVpMExSNmE4bjh4UnBzaUtjSURlclMvZXRKWUF5?= =?utf-8?B?VEo4cndPZ2dndTVtN0hYdWQwN0NNTUpkUmkxRnAxdkMwY1lLdS9YQm85eVVI?= =?utf-8?B?Y3IrREw4dVRadVV3U1RzVytuR0dkZVpXdGxGTEc1aEtqRWhFWUV3eVB0b08z?= =?utf-8?B?VVdlVTluT085YVB0cS9KNXdwSGEwRml1ZzAwZ0UyN3pBZVJSU21LUk5mSXUz?= =?utf-8?B?L3NUN0ovNWtteHlnd1p6OGpXZjBKN0NXbXZrTmpjQlZML25seitpTE9zNUo0?= =?utf-8?B?SE1jZ1U4YXhaMDM2THR0YXZwYlYrbmwvMEd5N2lid2NiVTJLOE5uU0dVUlcz?= =?utf-8?B?V2hCR091V2tJNTcyUU5GREkvSkxYN29ZUnZDekpSeUYzdVVxSEdjTHdJQ2tw?= =?utf-8?B?RHJXd0lLTVdRSVpyazVmdEEyblZaY1ZiTytFMmxPN0d4L2tZZ2tITE82SDVz?= =?utf-8?B?K2JYMlJScnBUYWE1Y3YyVFFTSFB0WjVRbTNPWXBVc0tTa3VaNzRpbXJsbXRa?= =?utf-8?B?NDdJN1hUc213Ri9qYjlUWmlFTmZENXdkVlFORWJsS1BMbEJQaTdhejFCYkth?= =?utf-8?B?ZUJIL05ldUdPZnJxSzN2MVp1Zm5KT1RVUGE2ejFoQllkWVYwZ2RQU0dER1No?= =?utf-8?B?b3JmTlVTd3NOT3VmVG1CbWZMNmlNby8wSytQeUxIQzJOR0ZTRTNXbVpLOFR2?= =?utf-8?B?TW04Q3BERkNGUEF2TTVoak9uVldlNG8xVnZiWDlwOTROT2YybTl6UVovZU9B?= =?utf-8?B?NGs3UmsvVG4wSEkrUGo1Tm5zL05jQ1BmMnc4NXlmbVFmN2xmRDRVOTlHY29q?= =?utf-8?B?dDJDL0dqREd2aC93dmlWc1JwVHVzU2oydTFXY2lrUmxXWUZFUmRFLzJGSW9T?= =?utf-8?B?R3I4ZGRUcVZLNWVFVUZZdUlmNmp3PT0=?= 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)(82310400026)(376014)(35042699022)(14060799003);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2026 11:08:36.4799 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3878e3a5-7c2d-411b-c264-08de535d43b6 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: DB5PEPF00014B9B.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA6PR08MB10739 SGkgTWljaGFsLA0KDQo+PiANCj4+ICsvKg0KPj4gKyAqIEZyZWUgYSB4ZW5fbXB1bWFwIGVudHJ5 IGdpdmVuIHRoZSBpbmRleC4gQSBtcHUgcmVnaW9uIGlzIGFjdHVhbGx5IGRpc2FibGVkDQo+PiAr ICogd2hlbiB0aGUgcmVmY291bnQgaXMgMCBhbmQgdGhlIHJlZ2lvbiB0eXBlIGlzIE1QVU1BUF9S RUdJT05fRk9VTkQuDQo+PiArICoNCj4+ICsgKiBAcGFyYW0gaWR4ICAgICAgICAgICAgICAgICAg IEluZGV4IG9mIHRoZSBtcHVtYXAgZW50cnkuDQo+PiArICogQHBhcmFtIHJlZ2lvbl9mb3VuZF90 eXBlICAgICBNUFVNQVBfUkVHSU9OXyogdmFsdWUuDQo+PiArICogQHJldHVybiAgICAgICAgICAg ICAgICAgICAgICAwIG9uIHN1Y2Nlc3MsIG90aGVyd2lzZSBuZWdhdGl2ZSBvbiBlcnJvci4NCj4+ ICsgKi8NCj4+ICtzdGF0aWMgaW50IHhlbl9tcHVtYXBfZnJlZV9lbnRyeSh1aW50OF90IGlkeCwg aW50IHJlZ2lvbl9mb3VuZF90eXBlKQ0KPj4gK3sNCj4+ICsgICAgQVNTRVJUKHNwaW5faXNfbG9j a2VkKCZ4ZW5fbXB1bWFwX2xvY2spKTsNCj4+ICsgICAgQVNTRVJUKGlkeCAhPSBJTlZBTElEX1JF R0lPTl9JRFgpOw0KPj4gKyAgICBBU1NFUlQoTVBVTUFQX1JFR0lPTl9PVkVSTEFQICE9IHJlZ2lv bl9mb3VuZF90eXBlKTsNCj4+ICsNCj4+ICsgICAgaWYgKCBNUFVNQVBfUkVHSU9OX05PVEZPVU5E ID09IHJlZ2lvbl9mb3VuZF90eXBlICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJpbnRrKFhF TkxPR19FUlIgIkNhbm5vdCByZW1vdmUgZW50cnkgdGhhdCBkb2VzIG5vdCBleGlzdFxuIik7DQo+ PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBpZiAo IHhlbl9tcHVtYXBbaWR4XS5yZWZjb3VudCApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHhlbl9t cHVtYXBbaWR4XS5yZWZjb3VudCAtPSAxOw0KPj4gKyAgICAgICAgcmV0dXJuIDA7DQo+PiArICAg IH0NCj4+ICsNCj4+ICsgICAgaWYgKCBNUFVNQVBfUkVHSU9OX0ZPVU5EID09IHJlZ2lvbl9mb3Vu ZF90eXBlICkNCj4+ICsgICAgICAgIGRpc2FibGVfbXB1X3JlZ2lvbl9mcm9tX2luZGV4KGlkeCk7 DQo+PiArICAgIGVsc2UNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIg IkNhbm5vdCByZW1vdmUgYSBwYXJ0aWFsIHJlZ2lvblxuIik7DQo+PiArICAgICAgICByZXR1cm4g LUVJTlZBTDsNCj4+ICsgICAgfQ0KPiBOSVQ6IFRyeSB0byBsaW1pdCB0aGUgbnVtYmVyIG9mIGlm L2Vsc2UgYmxvY2tzIHRvIG1ha2UgdGhlIGNvZGUgcmVhZCBiZXR0ZXIuDQo+IEhlcmUgeW91IGNv dWxkIGRvIHRoZSBmb2xsb3dpbmcgdG8gcmVtb3ZlIG9uZSBlbHNlOg0KPiAgICBpZiAoIE1QVU1B UF9SRUdJT05fRk9VTkQgIT0gcmVnaW9uX2ZvdW5kX3R5cGUgKQ0KPiAgICB7DQo+ICAgICAgICBw cmludGsoWEVOTE9HX0VSUiAiQ2Fubm90IHJlbW92ZSBhIHBhcnRpYWwgcmVnaW9uXG4iKTsNCj4g ICAgICAgIHJldHVybiAtRUlOVkFMOw0KPiAgICB9DQo+IA0KPiAgICBkaXNhYmxlX21wdV9yZWdp b25fZnJvbV9pbmRleChpZHgpOw0KPiANCj4gICAgcmV0dXJuIDA7DQoNCk1ha2VzIHNlbnNlLCB3 aGlsZSB3ZSBhcmUgdGhlcmUsIHNoYWxsIHdlIGhhdmUgYWxzbyBhIGNvbW1lbnQgYWJvdmUgdGhh dCBjaGVjaywgc29tZXRoaW5nIGxpa2UgdGhpczoNCg0KLyoNCiAqIElmIHdlIHJlYWNoZWQgdGhp cyBwb2ludCwgdGhlIHJlZ2lvbiBpcyBkdWUgdG8gYmUgZGVzdHJveWVkLCBhcyBhIHNhZmV0eQ0K ICogY2hlY2sgd2UgbmVlZCB0byBlbnN1cmUgdGhlIEFQSSBpcyBjYWxsZWQgd2l0aCB0aGUgZXhh Y3QgcmVnaW9uLCB0byBwcmV2ZW50DQogKiBkZXN0cm95aW5nIGEgcmVnaW9uIHVzaW5nIGEgcGFy dGlhbCBtZW1vcnkgcmFuZ2UuDQogKi8NCg0KV2hhdCBkbyB5b3UgdGhpbms/IE90aGVyd2lzZSBz b21lb25lIGluIHRoZSBmdXR1cmUgbWlnaHQgdGhpbmsgaXTigJlzIG9rIHRvIG1vdmUgdGhpcyBj aGVjaw0KdG9nZXRoZXIgd2l0aCB0aGUgb3RoZXIgb24gdG9wLg0KDQo+PiANCj4+IA0KPj4gdm9p ZCB2dW5tYXAoY29uc3Qgdm9pZCAqdmEpDQo+PiB7DQo+PiAtICAgIEJVR19PTigidW5pbXBsZW1l bnRlZCIpOw0KPj4gKyAgICBwYWRkcl90IGJhc2UgPSB2aXJ0X3RvX21hZGRyKHZhKTsNCj4+ICsN Cj4+ICsgICAgaWYgKCBkZXN0cm95X3hlbl9tYXBwaW5nX2NvbnRhaW5pbmcoYmFzZSkgKQ0KPj4g KyAgICAgICAgcGFuaWMoIkZhaWxlZCB0byB2dW5tYXAgcmVnaW9uXG4iKTsNCj4+IH0NCj4gTG9v a2luZyBhdCB0aGlzIHNlcmllcyBhcyBhIHdob2xlLCBhdCB0aGUgZW5kIHdlIHdpbGwgZW5kIHVw IHdpdGgNCj4gdm1hcF9jb250aWcvdnVubWFwIHRvIGNvbnRhaW4gdGhlIHNhbWUgaW1wbGVtZW50 YXRpb24gYXMgbWFwX2RvbWFpbl9wYWdlIGFuZA0KPiBhbGlrZSBmcm9tIHRoZSBsYXN0IHBhdGNo LiBTaG91bGRuJ3Qgd2UgZGVmaW5lIG9uZXMgdXNpbmcgdGhlIG90aGVycz8NCg0KV2UgY2FuIGRv IGl0LCB0aGUgb25seSB0aGluZyBpcyB0aGF0IGlmIHZ1bm1hcCBmYWlscywgd2Ugd2lsbCBnZXQg YSBsZXNzIHNwZWNpZmljIGVycm9yIG1lc3NhZ2UsDQppZiB5b3UgYXJlIG9rIHdpdGggdGhhdCB3 ZSB3aWxsIGRvIHRoZSBjaGFuZ2UuDQoNCkNoZWVycywNCkx1Y2ENCg0K From xen-devel-bounces@lists.xenproject.org Wed Jan 14 11:12:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 11:12:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202918.1518309 (Exim 4.92) (envelope-from ) id 1vfynK-0004yT-SF; Wed, 14 Jan 2026 11:12:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202918.1518309; Wed, 14 Jan 2026 11: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 1vfynK-0004yM-PI; Wed, 14 Jan 2026 11:12:10 +0000 Received: by outflank-mailman (input) for mailman id 1202918; Wed, 14 Jan 2026 11:12: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 1vfynI-0004yG-Kb for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 11:12:08 +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 dd10f9a6-f139-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 12:12:07 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-47ee301a06aso7038095e9.0 for ; Wed, 14 Jan 2026 03:12:07 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee563ce3csm21910015e9.14.2026.01.14.03.12.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 03:12:06 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dd10f9a6-f139-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768389127; x=1768993927; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=5DFX7CL5pzKbU8OxAPLYXRLBI4mQ8zHTwMB07f98xSI=; b=L1Lk3OAmRT6J4wMnYR+pBJCZ/oLmp/nPuw8UJqRCh6fsaKEtDrWrKaCi/jM0ltlTjR q8oJq0HEEXKU/EgldJKMM+MxlTRf9QvWTB59p1mrx8MJfDYmSMoeSFmMktqZfvkB45kK 4GO+OdxbbWbO9FH2DKzHq5NuzC26WAChBN1lpXn19m2SkhMeqNwmGwQA2jAUqwQBDXtM oSUnUdmon2XH7oYS2cwxReA7+tftXYT97FANsob5lq4eAOUpRfKqLrsRSS8+Ose767Ru u2FPD3wiJqMlwwk3T0a/GDvP9HHyVfHHzSPaB4EXGkrI0LUfwO9uZBg5I7PYFvkXrugQ FR+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768389127; x=1768993927; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5DFX7CL5pzKbU8OxAPLYXRLBI4mQ8zHTwMB07f98xSI=; b=pvEp8puZTTAEAO2v4Sr5a0VP7I6b2nmyiBsAhD/U72rC5fwKIv3kilW2CB9hATqPmk rAGBfuOgK4sEepnqSlgn2/47I+pWwzPg7R64jmJnzglDpN/JZVm3zYAdLAzUSaXZ7y+F hJHgKK/Qs3YfBaqz6FtTmf4OUz0h7aEi5wiFfFhZ4YTT7eU6JTazaux6OKvmdNy+aOOl DicfFrpMhCRQyt31/ub/Xwh5UI13NVx50FUxIV/vx39V41pqdIbqP9A2O9qLJWaW62Iq LxjABbOBCTbeyDSTtMUODTi8BNTSRC1p1HU8XHYmfRN7j+q9V8iMjP2sccw1unRdj+f6 vxKA== X-Gm-Message-State: AOJu0YxU+eMlHxpjoQECV68H0lxxehODLMdP9IZux7eO0KazxpiGGib8 Pt7Hk5zx8VWxgwaqrAq4NyDjUv30xW6A5HoO7KiYUscDqlzJYDWUqPWdlH1GgAeolg== X-Gm-Gg: AY/fxX5q89jIsGGxjQz6MTB9nOgbet96zjullEqK+W6nsdL3uFY0aQG59rMSh6xqa1Z r3pUsFbPE5b6SplFb1L7orYL/zeyTiJQPwJkItaXhtfRMY62DsaSKeT6a29N4LiBbhG+2kO2DZX j0PS/Y546OVljNEI4dr2sB7x7ydmDCd8kS/RBAFOrFPD8zIUCE7qdooRmBf6YM64RK97vyySrdb wcQCwW3eADUVpBoCveGcSl1Tmh+0Rb9g8U8WM8K2fZea5MQHinKdJHNP4/JiJgcdAlve17lDe75 25DwXHO6o0XxsLytloANuej+J8qzLoWrMzSJ/7hAz3EAk/LbbpZ3ehabiYN29YoZhUXTyHRTFis VhKs5lmq27bg1puH7WiW8tvFWYB9AJvgaPCNovW2nMhve2oCFy9LR/JKiV1dYyjtSfh8gP2WBDR c2oP9I1CjT4PtNAlfzaNp4GNQE63iXBE6ZrnQFkq0t5wCHJsls90dPXkYCM+tFMyklLuqaBC7aQ 2s= X-Received: by 2002:a05:600c:548c:b0:47d:264e:b35a with SMTP id 5b1f17b1804b1-47ee331fea0mr22119775e9.13.1768389126817; Wed, 14 Jan 2026 03:12:06 -0800 (PST) Message-ID: Date: Wed, 14 Jan 2026 12:12:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Cpufreq drivers not working on T480S To: Milky Cc: "xen-devel@lists.xenproject.org" , Jason Andryuk References: <7dbd26d1-0d9a-454f-90d8-5a7f3d8e12da@suse.com> <8a2125c7-c5ec-4be1-a7a5-61b2936cc90f@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 14.01.2026 11:58, Milky wrote: > Just wanted to update this thread to say that now another T480 user (the T480 is a very similar model to my T480S) using the release builds of libreboot (as of 26.01 RC1) also has the entries missing from the ACPI tables. That discussion was here https://codeberg.org/libreboot/lbmk/issues/394. So this confirms that I'm running a standard libreboot, rather than a bad build. > > Do you think there is any way to avoid the underclocking issue with Xen on such devices/firmware? In principle there is, but in the absence of ACPI data that means holding model- specific data in Xen. Which iirc is what the intel-pstate driver in Linux does (using ACPI info nowadays only as "auxiliary" data). But I may be wrong there, as it has been a long time since I last looked at that driver. Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 14 11:17:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 11:17:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202932.1518319 (Exim 4.92) (envelope-from ) id 1vfysk-0005jP-FN; Wed, 14 Jan 2026 11:17:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202932.1518319; Wed, 14 Jan 2026 11:17:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfysk-0005jI-CY; Wed, 14 Jan 2026 11:17:46 +0000 Received: by outflank-mailman (input) for mailman id 1202932; Wed, 14 Jan 2026 11:17: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 1vfysj-0005dl-BU for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 11:17:45 +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 a070a907-f13a-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 12:17:35 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-4775895d69cso42931905e9.0 for ; Wed, 14 Jan 2026 03:17:35 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee57b0749sm24700425e9.7.2026.01.14.03.17.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 03:17:34 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a070a907-f13a-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768389454; x=1768994254; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=WoYU+vXXGEPlDg0hNe/wDoms5L+2v5rMPyCY4NMStuI=; b=FC8v7h5zFLL3kIXkY3mtp6o0Gs9kzuiVQj5vDbmznjViZR6EFH4IKMLX5fGolhlFnr yx626rRxLsNN0sZ0zdZ9wTHxlCdDCvqAnzahidLZDH2VhtllN0kChXDccVkGNmetbmR/ ds9QZoHclc3k1IooJ8SmU+ASmJZNkkyBkaFIKza++OW46J5FrBy1o0TwTGEOLRowXOMS D4zY0oMaVZLE7j6ep2MjIXAmx/JngneKrV9ybRzMT+0sdPc1XD9uR54mZPKZrqSnwZWW tDOPaWV8gkvF3Nbzw5sZQ/z2Fn3kxTQS+WD8IFgaoKIKRfDkB1WyPFc/2Q+PgBwdMuMI NmPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768389454; x=1768994254; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=WoYU+vXXGEPlDg0hNe/wDoms5L+2v5rMPyCY4NMStuI=; b=w2OLHo8HRHqsDqWzESnonl1CcLKIC+G4SYBKnwTPv7UNuYLG7O3D4L3af3AfCxheFp cEh8CWnZF8qk6bJneu75pwLvyDMZz3eXWXWRJil9kPhmvgf8rM2lmj5an6HLK91kO1tN zVyjYqbodpC+cwN5SW89YeFFivpCqEt75jDmR79HhfWMAoVXH7/cSFqazI5mXDvotS+g R1AlZZz4f9msHZ1ouhEkmdWAivaQq+17o5ThKbyW5x53puSc7fuKHwCvGDUo1iqEMOc6 LaQiZfm35wdFbDzjO1cNZlSbBWQkdpIrwW2rT0d+7dNYW/UBm/qT9PpS0LbcXRmv5cXf YnGQ== X-Forwarded-Encrypted: i=1; AJvYcCXfGow8XwW0YHR8LAZVoXdJ5aNmllyiVMpJRwOHER5ykEq8Q74CuC8Otkx80AAY4jn4mU1wRSzsKjA=@lists.xenproject.org X-Gm-Message-State: AOJu0Yye/1ljTXyhLwoVFP3ZT3eXGCSGmaRgDfvsOB+b4BFxZu3ODX9c /D/S5U1KJvgPC7T5Eq+C51gEiweLQwSRcOUy4/DW29fHH8U1UOOvB4N+aVHCieRujw== X-Gm-Gg: AY/fxX7WMrPJIpI4AoA+xjA+Gahxymf9o9XelZp1c3miS2teDK4XFQ/Bg1ebT7CEmJ8 X+Se6KSK0sDCDYYCKLT4lJUDYnr7azNPQv7yp6g7Nbhvmch8MI0MFWL3rT4Sicp2Axgay/GzJNU jAl2R3a91yDcBugBGGZUAf016DtyJf4vi4GYD7eUPdFl/+ob+s3v8yJMWhCwsZ+Z7jpg4pMvLaA CivwRkW+Y5KmGTeJzkMFvwtDqjZ/hCOZq8d5iVh106tg4M2+MjGX15R7wCFkjDB/PJZ7UZVjdbp F1LCeRGQNrmxhobNpmSuxo88IWkblVIxnJGzoskuXIy3c22ts0n/x6mBbxb0TIP3yBN1D7nB9HK Pzwrdx/OCOPEBJyPrMCcO/Y5RH2IxYwPXfaTmAJ1K0E0SqDdLivNigK+JzUnPH5imgHZHXlQ7LI LdA+FQ6Iu7qJZqxWUtMtmMcQ9QxqPX/8e0gQNia+NnmPXqPTz51wo1oubqUpuUD1sGYHnFPU3l+ OI= X-Received: by 2002:a05:600c:8b52:b0:47e:e20e:bbbf with SMTP id 5b1f17b1804b1-47ee335646fmr26668175e9.24.1768389454633; Wed, 14 Jan 2026 03:17:34 -0800 (PST) Message-ID: Date: Wed, 14 Jan 2026 12:17:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 13/15] xen/riscv: implement reprogram_timer() using SBI 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: <43249171def325c49541ebdac141fe99d159b60f.1766595589.git.oleksii.kurochko@gmail.com> <90e7fc60-09cc-4b61-ab0a-80037f8ecaf8@gmail.com> <4141bb71-7aef-4287-aefd-92009977294f@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: <4141bb71-7aef-4287-aefd-92009977294f@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 14.01.2026 11:33, Oleksii Kurochko wrote: > > On 1/14/26 10:53 AM, Jan Beulich wrote: >> On 14.01.2026 10:41, Oleksii Kurochko wrote: >>> On 1/14/26 10:13 AM, Jan Beulich wrote: >>>> On 13.01.2026 17:50, Oleksii Kurochko wrote: >>>>> On 1/12/26 4:24 PM, Jan Beulich wrote: >>>>>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>>>>> @@ -39,6 +43,33 @@ static void __init preinit_dt_xen_time(void) >>>>>>> cpu_khz = rate / 1000; >>>>>>> } >>>>>>> >>>>>>> +int reprogram_timer(s_time_t timeout) >>>>>>> +{ >>>>>>> + uint64_t deadline, now; >>>>>>> + int rc; >>>>>>> + >>>>>>> + if ( timeout == 0 ) >>>>>>> + { >>>>>>> + /* Disable timers */ >>>>>>> + csr_clear(CSR_SIE, BIT(IRQ_S_TIMER, UL)); >>>>>>> + >>>>>>> + return 1; >>>>>>> + } >>>>>>> + >>>>>>> + deadline = ns_to_ticks(timeout) + boot_clock_cycles; >>>>>>> + now = get_cycles(); >>>>>>> + if ( deadline <= now ) >>>>>>> + return 0; >>>>>>> + >>>>>>> + /* Enable timer */ >>>>>>> + csr_set(CSR_SIE, BIT(IRQ_S_TIMER, UL)); >>>>>> Still learning RISC-V, so question for my understanding: Even if the timeout >>>>>> is short enough to expire before the one SIE bit will be set, the interrupt >>>>>> will still occur (effectively immediately)? (Else the bit may need setting >>>>>> first.) >>>>> The interrupt will become pending first (when mtime >= mtimecmp or >>>>> mtime >= CSR_STIMECMP in case of SSTC) and then fire immediately once >>>>> |SIE.STIE |(and global|SIE|) are enabled. >>>>> >>>>>>> + if ( (rc = sbi_set_timer(deadline)) ) >>>>>>> + panic("%s: timer wasn't set because: %d\n", __func__, rc); >>>>>> Hmm, if this function ends up being used from any guest accessible path (e.g. >>>>>> a hypercall), such panic()-ing better shouldn't be there. >>>>> I don't have such use cases now and I don't expect that guest should use >>>>> this function. >>>> How do you envision supporting e.g. VCPUOP_set_singleshot_timer without >>>> involving this function? >>> Looking at what is in common code for VCPUOP_set_singleshot_timer, it doesn't >>> use reprogram_timer(), it is just activate/deactivate timer. >> And how would that work without, eventually, using reprogram_timer()? While not >> directly on a hypercall path, the use can still be guest-induced. > > Of course, eventually|reprogram_timer()| will be used. I incorrectly thought > that we were talking about its direct use on the hypercall path. > > I am not really sure what we should do in the case when rc != 0. Looking at the > OpenSBI call, it always returns 0, except when sbi_set_timer() is not supported, > in which case it returns -SBI_ENOTSUPP. With such a return value, I think it would > be acceptable to call domain_crash(current->domain). How is current->domain related to a failure in reprogram_timer()? > On the other hand, if some > other negative error code is returned, it might be better to return 0 and simply > allow the timer programming to be retried later. > However, if we look at the comments for other architectures, the meaning of a > return value of 0 from this function is: > Returns 1 on success; 0 if the timeout is too soon or is in the past. > In that case, it becomes difficult to distinguish whether 0 was returned due to > an error or because the timeout was too soon or already in the past. Well, your problem is that neither Arm nor x86 can actually fail. Hence calling code isn't presently prepared for that. With panic() (and hence also BUG()) and domain_crash() ruled out, maybe generic infrastructure needs touching first (in a different way than making the function's return type "bool")? Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 14 11:26:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 11:26:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202945.1518329 (Exim 4.92) (envelope-from ) id 1vfz0j-0007MB-7r; Wed, 14 Jan 2026 11:26:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202945.1518329; Wed, 14 Jan 2026 11:26: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 1vfz0j-0007M4-5A; Wed, 14 Jan 2026 11:26:01 +0000 Received: by outflank-mailman (input) for mailman id 1202945; Wed, 14 Jan 2026 11:25:59 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfz0h-0007Ly-G6 for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 11:25:59 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id cb54256c-f13b-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 12:25:57 +0100 (CET) Received: from MN2PR04CA0028.namprd04.prod.outlook.com (2603:10b6:208:d4::41) by CH3PR12MB8726.namprd12.prod.outlook.com (2603:10b6:610:17b::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Wed, 14 Jan 2026 11:25:53 +0000 Received: from BL6PEPF0001AB50.namprd04.prod.outlook.com (2603:10b6:208:d4:cafe::d6) by MN2PR04CA0028.outlook.office365.com (2603:10b6:208:d4::41) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.5 via Frontend Transport; Wed, 14 Jan 2026 11:25:53 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BL6PEPF0001AB50.mail.protection.outlook.com (10.167.242.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Wed, 14 Jan 2026 11:25:52 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 14 Jan 2026 05:25:52 -0600 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; Wed, 14 Jan 2026 03:25:51 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cb54256c-f13b-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Tqfp4aZ6f80qZlRPyRTidwLiioDSDVYWaWcF5jYZ7UzlGhEBAc351XwXMmWVM9IWu1yPC0QCCBCStwwuLCHwedu7IKf/LkFFe7XVMmA2HCXi0mtdLvuEwzzcWd3mSSxTY+gIanO+zPE34JO3/fle13UH+Lc59ioGiDlEB71DsJjdCob/Z5ACgxPHORkP6HXG7mZAxk6ugqCNZ5feNIak2UkCxtLcPsisU4yvyFl331FlEqX8/ADIoQqPrHyu1k76t03X83D2LaUWrCmgpZvnBIiHyQkvQqCBivk+3c7hoO/zqyJtZ3N3zJFy1D73uXF3wGMFbRbhMTRnMwiV75x/Jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=P/I1xLNmBu1i03Tz1A4fr50Wly53NzflHq4T1dLHXAs=; b=p3lv0ASrxYubIND7bNk/aoK6MkV3S8DqQS8gS2VIEWh2xCsuF6VTfB1MCFo3aI4I36eQZ0sxCB0q1i6yfKICxW+xSlqrb1eXlw5qGaU5E56n7PRiD5GYASh1XMsRnsSdH0bjnceJsw/uKBX5h8AS3Je+ToZvgLvqTGYRmUk+LDCGPN1Og7fjEFqq9W/B5sOYQEvzJ3uV7zldgDMeO5TnUb7ke3wT/Jxv9gUwOA5xxvux5dxjdUnFq5RHZFEWLUPy+UFaaKH77VTFtbzKgoBIcAJoYVGNV4ChA2iclFM5l1fxrfENpUo0orR1KxcgTPE3mHoH7ojjdSyBDI07i62+Kg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P/I1xLNmBu1i03Tz1A4fr50Wly53NzflHq4T1dLHXAs=; b=xYA3GaTFqgRXXf09yVHEVmlP/X7+oiD/4YxyYyrZH0l2pi4sNXKcJrTB/jwLwH94fPudBqzevMiYDOwUtDD1yH9M0eFNjnh3FYlJHSsfj2btZ3+0546kiUbxIglEObPWjROE32V9fIYU9I2gKiyFsPODrfHuyanxcQ9NU4tNHys= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 14 Jan 2026 12:25:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/6] arm/mpu: Implement vmap functions for MPU To: Luca Fancellu CC: Harry Ramsey , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk References: <20260113162309.6766-1-harry.ramsey@arm.com> <20260113162309.6766-3-harry.ramsey@arm.com> <1cb6fc36-fd16-499b-a616-4d321ae83572@amd.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB50:EE_|CH3PR12MB8726:EE_ X-MS-Office365-Filtering-Correlation-Id: 146ad908-1bff-4b1d-928e-08de535fad5a 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?UTNaR3FsNDY0YTRkMmtXeEw0aVFRTXNHaVhFQTllK3luU2JCVTJhUENES1R0?= =?utf-8?B?VFNXUnd2d0FnZ2YxdWF6R2NaQm5MTUJrR0p4MzVJSCtIRUFXQjFiTmJ6eDdG?= =?utf-8?B?NEF6ZlpDNHNrdmN6ZVZYUTlkMVVKR1E1SmwwY2YvdWQ3QmNyMEtpYzh1STZW?= =?utf-8?B?Y1dDM0FhVjgrd1ZMdTdhKzZtbUlCMTZ5MDl6aUdZZTB5YW5OOHdPWFc2UHJU?= =?utf-8?B?VXU5ZGcvNE9uYmwyOGNJaG4wM2IrSjkzL2hreDBmOVVqbnZRZDdBQmNzUGN0?= =?utf-8?B?ZHhqdnBNUXM2UkRZNXhTYW8rdEJwOUhObDlubFFZdEEzbG8ySGJ4QmEya1gx?= =?utf-8?B?T2JzZDdPdzFjM1N0L3RhSjIzN0M3emJ4OVo1cklqTTF2SXBwbVI0aVFZOVBE?= =?utf-8?B?Mko5MXMwdUhuMEtHQ3h4d2lWM1E0bi9rZHJYY01mbHJ1aVJzZFNqaVdSNitI?= =?utf-8?B?ODhFRUpwU2hYSUJmWXU4cEN5ZzJSUFlRZVJhazNwZ3VHRlIyTW5PVjN6c3p5?= =?utf-8?B?Z0IzZVdKa3pPek1oMkVwU3JSRVFSLzNnZGhRZXg2VmRmZlhndmxkY05leU9Y?= =?utf-8?B?ZnZYNnNJczVwM1ZhdEpyVU9UVHhnWThleXMwTkptN3lBSU9uSUVwWksxT2pX?= =?utf-8?B?VXZxZEVXRUdBSTVjWGxSejluelZnN1oxYklCa3BFTkc5QTFRczhVUEhkN0JS?= =?utf-8?B?T3hTM2F5NEpYQkJxOTYzTmdzNExMT3hjQ0IzV2NCejBLd3VJalZnMEMyS0ta?= =?utf-8?B?TFU4Q1pBT3MvbHp5RjNLVXBkcHo4ekc2ZWFwcy8yRzJheXhNTG92dmVkVHdv?= =?utf-8?B?aXZkb3FVa1VxeTRBRlNLQWFsOEhwM1BqOUQ2Ni9qczlIMzJzamRMUVBVcVhZ?= =?utf-8?B?MExTZ0dZN01aOGVQWnZtZnVXMG5QNkNhQjQvcVdxaVhaVWxPR2tXRDJlMDZX?= =?utf-8?B?NzdDajRoR0t0aXg0OWtwNmxIdjhmVXJHR0h4SEpMdDRJRG4xVTFxN0lKRGdo?= =?utf-8?B?Ti9nYzljYkZ3Y2FqMFEvdnp1ZlN1WFpNWFptL2N5NE1MQWtNZ3ZhMTFyZFlr?= =?utf-8?B?MjhTc1RvSkowdW5pVlRpdVcwZHhrZmNtL3dzOWpJVXZoTDVCVFliWld2T0pl?= =?utf-8?B?VU96Zkl4dU8zYTI5Sm9obkljZHN5RkRyOHUvZHd4L1RJdkFFeEkzRnpXZ1M5?= =?utf-8?B?dTF3RjhLQWJrbHRaT1M5aGRDOTc3aVd1RWpqWVYzZTdzYktBM29jRVNmWXRp?= =?utf-8?B?M3pJY3l5Q2JjUGdBNDRHZkdVcUlLSCs3U3Ftak9GMm9hQVlhR0VWZDN5WmZG?= =?utf-8?B?N0VZWVlxSXRwQzMweElXcXdwamIyeFBoV2k1Y055bDJHL3VpNGEyYVFFMTVR?= =?utf-8?B?cURNeHJtWERUVnhzbkcwSGdvWGN4MU90VHlzK2NXempyS0FibjdobEJUS242?= =?utf-8?B?ODQrRDZ0bzNmQzRnTTd3VGZ2bnlkd2N0emdFazRNNlhERC9nSEVCTkx4amxK?= =?utf-8?B?ZktXVENvYkYxdlRJVXh3NGRlZHJ0bVNKNkdFRmRCVHM3Zng0SlBpcnNHdFNM?= =?utf-8?B?VGwwanhGeG41VnhRVFpoTjNPVVUya1Q0ZjJ3ZURHNmhZdVpMSExtZVpmMnUz?= =?utf-8?B?QjlDQjQ3a3hQWVI2RlZVSlU4UEtoVHlVSnRhdDBSUnFDUzRmNGwvcnNmK2N6?= =?utf-8?B?YlJTbDYzblJlMDJrU2E4RWF1RmUycUl4OHdUbmxSTW05K0lzREZOVHlXK0tX?= =?utf-8?B?VXZ6NjQ0OEc3VDAxMGlOc1BVNHEyTVhmdnNKSEQ3TUVNS2d1bXFRc1doMGF0?= =?utf-8?B?Y251Rll0a3M5RGNsN0tVb3ZDVlFMY0Nsd24rZFk2YXFVbXlOQ3EvRkNXKzJr?= =?utf-8?B?OHlMaUhjOVdrM3lGWnJ1RENxUWI1anNtTE5VMzFBWkZDcFBHTnhxWllwaHZl?= =?utf-8?B?MTk0R3lESmVjVExwRlduZXNrRmE1ZFcxRlM4RFpFVCtuVldmU2xzRzVhaGVm?= =?utf-8?B?OUxUUEFRbzVUYmJ5WVEyQXdEV3NJcWxkYThKMGJiL2V6bVJrcGhlWW5sTEYr?= =?utf-8?B?YU9lUy9Ra0h1dXg2K2RKVmFvRTlkOUtHSklRcmNla25wWW5DdTc3c255YU9W?= =?utf-8?B?S1pDQyswK0x3OHNHdDNrV0lQUStNbGJrZlpseWxIM3AyTHRZU0N1T1J5S3hS?= =?utf-8?B?dFE5aUxxQkZGeVJTckVCaW1uMk14UWptaExpdnp4VldSaVJQUkhIeFprNDlv?= =?utf-8?B?TDdROVljbkVnZXpoaUdOVWFJcjd3PT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2026 11:25:52.8150 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 146ad908-1bff-4b1d-928e-08de535fad5a X-MS-Exchange-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: BL6PEPF0001AB50.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8726 On 14/01/2026 12:07, Luca Fancellu wrote: > Hi Michal, > >>> >>> +/* >>> + * Free a xen_mpumap entry given the index. A mpu region is actually disabled >>> + * when the refcount is 0 and the region type is MPUMAP_REGION_FOUND. >>> + * >>> + * @param idx Index of the mpumap entry. >>> + * @param region_found_type MPUMAP_REGION_* value. >>> + * @return 0 on success, otherwise negative on error. >>> + */ >>> +static int xen_mpumap_free_entry(uint8_t idx, int region_found_type) >>> +{ >>> + ASSERT(spin_is_locked(&xen_mpumap_lock)); >>> + ASSERT(idx != INVALID_REGION_IDX); >>> + ASSERT(MPUMAP_REGION_OVERLAP != region_found_type); >>> + >>> + if ( MPUMAP_REGION_NOTFOUND == region_found_type ) >>> + { >>> + printk(XENLOG_ERR "Cannot remove entry that does not exist\n"); >>> + return -EINVAL; >>> + } >>> + >>> + if ( xen_mpumap[idx].refcount ) >>> + { >>> + xen_mpumap[idx].refcount -= 1; >>> + return 0; >>> + } >>> + >>> + if ( MPUMAP_REGION_FOUND == region_found_type ) >>> + disable_mpu_region_from_index(idx); >>> + else >>> + { >>> + printk(XENLOG_ERR "Cannot remove a partial region\n"); >>> + return -EINVAL; >>> + } >> NIT: Try to limit the number of if/else blocks to make the code read better. >> Here you could do the following to remove one else: >> if ( MPUMAP_REGION_FOUND != region_found_type ) >> { >> printk(XENLOG_ERR "Cannot remove a partial region\n"); >> return -EINVAL; >> } >> >> disable_mpu_region_from_index(idx); >> >> return 0; > > Makes sense, while we are there, shall we have also a comment above that check, something like this: > > /* > * If we reached this point, the region is due to be destroyed, as a safety > * check we need to ensure the API is called with the exact region, to prevent > * destroying a region using a partial memory range. > */ > > What do you think? Otherwise someone in the future might think it’s ok to move this check > together with the other on top. I'm not sure. I can read this from code but if you think it will be beneficial, I have no objections. > >>> >>> >>> void vunmap(const void *va) >>> { >>> - BUG_ON("unimplemented"); >>> + paddr_t base = virt_to_maddr(va); >>> + >>> + if ( destroy_xen_mapping_containing(base) ) >>> + panic("Failed to vunmap region\n"); >>> } >> Looking at this series as a whole, at the end we will end up with >> vmap_contig/vunmap to contain the same implementation as map_domain_page and >> alike from the last patch. Shouldn't we define ones using the others? > > We can do it, the only thing is that if vunmap fails, we will get a less specific error message, > if you are ok with that we will do the change. In the MMU case you won't get any info, so I think it's ok. ~Michal From xen-devel-bounces@lists.xenproject.org Wed Jan 14 11:33:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 11:33:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1202966.1518340 (Exim 4.92) (envelope-from ) id 1vfz7n-0000hw-1D; Wed, 14 Jan 2026 11:33:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1202966.1518340; Wed, 14 Jan 2026 11:33:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfz7m-0000hp-Ug; Wed, 14 Jan 2026 11:33:18 +0000 Received: by outflank-mailman (input) for mailman id 1202966; Wed, 14 Jan 2026 11:33:17 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfz7l-0000hU-78 for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 11:33:17 +0000 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [2a00:1450:4864:20::336]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d1533ed6-f13c-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 12:33:16 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-4779aa4f928so86354375e9.1 for ; Wed, 14 Jan 2026 03:33:16 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0e16d2sm51118032f8f.13.2026.01.14.03.33.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 03:33:15 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d1533ed6-f13c-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768390396; x=1768995196; 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=BajQDAKIgQ5gDjKtFsgRWf/pFzpGJIzi2y6k/uBcInE=; b=Kp04JN81c40zLsCtZfeSiPAKPdciNDt9v9VeO4ZU4qKd1n1KBpRAN7AirVmhg72jfM ummQATZ4+D83xJa4Wf1mLt1M7WINLdvtCW5pWLbFtEYe3iBC7SX02lRInwY01Gk0T8se j6kF/iYGTTO4EJhpUD5CRSFAOS0dXBTu874H1U36A6XzrxTrpgNnUV6eqLrmvmhm4TLk GsKqJP3qtyL6dLQf1dvguweHnv6J/MZ0J/mI/1KvlMhG1bY1s2XqfDgFaGAE5SSkYCYt B8hjzJo7+hzmqrE+iZ5zXIMHoknzFVq0YS9bAwWQD9PGsIbHWEzYtmbuRkfORmMkB1hn z3hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768390396; x=1768995196; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BajQDAKIgQ5gDjKtFsgRWf/pFzpGJIzi2y6k/uBcInE=; b=wscLVuRakr6pjzFkz+qB9Mwv+6rTnPAzR2PprCU7C5mp6NF7ljRdM6nbztbEl+L6pm CZXWS352/GyqhsGVhc1M5PS6cSwuN+5+P75FyEW8IB9ZaVwj9PHLsr8Pzr64fQrwtbrQ 3+mXuMieTMYJvdGhndTXG13fYMlweyoHBGSRBf7wM+1bb1uvNJx2tkj83hunWihNFOan xuriF/71lb1b5Ms6mFgYPN+xEwRpMHtLLiQrZAcgLjCm1mm570YjnxSTokC2TtlNsvl+ zbvotFfXCcLiQEUbJygczW9uDgKg7xb6Eehrdf27RfkOOH1fhOTiWCCJrCIde1i9+ANF rQjg== X-Gm-Message-State: AOJu0YzT5PgLK/KNuiJE60qI7IS26sh2tudCvJ4OyXWKCK9e7Ow9vkV7 TbVVj3NNBdW8jrOuX8c79xPs5aYxDNJBRspZAIg+K5dc45GZ//iO2gACGNvyUj8IIoRMMdRi4G4 wd5Q= X-Gm-Gg: AY/fxX6u82y2HjTOZH5QzBAN+yVuYCCtbJ5LI5AJHaHIEydO/dGUYPwZlSOujcWl+8P z2TXRD0nyOeI46kd0XdzoVMuHxH0imolZ611rLviFSnQ+G98RY1RE47kn+GdmI42WgWe/AEos8X foGiUZxQv12eqwsgbCaj+8SoBGUSajMjw3vZVTM9L7vmc8SuN5IBCBO99REwDaSzOa8ZQoY+NMP Ux3VOhgp+QzWhz4FMkvLs5lxhsJVipmlvEDZX4j/SRhdDz4ENENEVi7mPA9IwNemn0gmXE+/QB2 fpoKBDt8+7XXIG2idbYo5LhA7nZf5NoX9ezqySvhOIEBCH26V3yMt/W5ywmyAM71gwTBTMXaJBZ xEOuLv93tqh/2t1PdHvOhcngTSjfycZ8hui5d6Ioj/uCrH/Y+rd7lyPLxCvurjp8PUKFcvNCqAB RuXZ90hi+jJPN37eYa92Po/PZPQKVoX/CJ2oeCU0ELRyViyFqNfKgaUCyU2LT1wsW5q0V3skDqJ 4I= X-Received: by 2002:a05:6000:200d:b0:432:5b81:483 with SMTP id ffacd0b85a97d-4342c501318mr2508314f8f.24.1768390395541; Wed, 14 Jan 2026 03:33:15 -0800 (PST) Message-ID: <1caed635-3d9b-47ed-b8fb-d6c391293059@suse.com> Date: Wed, 14 Jan 2026 12:33:14 +0100 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?= , Oleksii Kurochko From: Jan Beulich Subject: [PATCH] kconfig: adjust NR_CPUS defaults Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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 Discussion of a RISC-V change revealed that for PPC and RISC-V we don't really set any default, but rather rely on internals of kconfig picking the lowest of the permitted values in such a case. Let's make this explicit, requiring architectures that mean to permit SMP by default to explicitly record some sensible value here. Leverage the adjustment to the "1" case to simplify all subsequent ones. Signed-off-by: Jan Beulich --- For not-yet-SMP-capable ports we might go even further and use range 1 1 if !X86 && (!ARM || MPU) at the top. Thoughts? (I've not done this right away as it is liable to get unwieldy when we have a larger number of SMP-capable ports.) --- a/xen/arch/Kconfig +++ b/xen/arch/Kconfig @@ -9,11 +9,11 @@ config NR_CPUS range 1 1 if ARM && MPU range 1 16383 default "256" if X86 - default "1" if ARM && MPU - default "8" if ARM && RCAR3 - default "4" if ARM && QEMU - default "4" if ARM && MPSOC - default "128" if ARM + default "1" if !ARM || MPU + default "8" if RCAR3 + default "4" if QEMU + default "4" if MPSOC + default "128" help Controls the build-time size of various arrays and bitmaps associated with multiple-cpu management. It is the upper bound of From xen-devel-bounces@lists.xenproject.org Wed Jan 14 12:27:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 12:27:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203007.1518349 (Exim 4.92) (envelope-from ) id 1vfzxv-0007Xq-0c; Wed, 14 Jan 2026 12:27:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203007.1518349; Wed, 14 Jan 2026 12:27:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfzxu-0007Xj-UO; Wed, 14 Jan 2026 12:27:10 +0000 Received: by outflank-mailman (input) for mailman id 1203007; Wed, 14 Jan 2026 12:27:10 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vfzxu-0007Xd-8i for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 12:27:10 +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 57a54bf2-f144-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 13:27:08 +0100 (CET) Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-64c893f3a94so1480710a12.0 for ; Wed, 14 Jan 2026 04:27:08 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8731f071e4sm574887566b.66.2026.01.14.04.27.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 04:27:06 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 57a54bf2-f144-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768393627; x=1768998427; 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=nmE0bkPqwySALuVSQ+L8vFyWzA69TauhQLdW5hVuKEw=; b=nnFBNgs5GaH1kM7AAwBXMxauFVz3FkbElnY15IRwQcMUFs1vHyO7PGbtGxGkZ0vJM+ SWpcw2Pz9V3e/HQbboAkmvRMOciYGqr1mIqiFU6lBln2k/GYpv4XGdeAh4ovAAotfkmx wVCW+difNeM5n2LaFC+1FaiWyBgnfDhQnPKBz3Z8ngPT4t/u37VdC6+YstMR4/WnUdxk JpOTG0lQ3tOsFOhn74fOd4UkQ/PrJSv9UB/N83CieWqHiMDptkGKrdKSOdeNYeAAS376 1EdKmcfwiXImIAraJ/ksQkPDKRO+yGEQtCQ6OupvDubz64WEjpb5MXhfeoqtoNOq3Rfe Fj1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768393627; x=1768998427; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nmE0bkPqwySALuVSQ+L8vFyWzA69TauhQLdW5hVuKEw=; b=dPiGnVJzw9gF95PbIm/mQho2UKUzqWc1xeh5UGWBB9l0gfRvG8lVlP4uTcgfzC6Xou yYgwxsygMLrFrc3wXgX+FailuEzz2rOoSFfD92hjdWG0osEKEz9XbqVsDciEsnYk17ks qFNA2uijNHJ1ZYh/CfBqkhBKUXYtKb7n4q0cpO+xxVwIH975xQ4KlSAU/k4S81cUiskL pDp/z+7NFAaBQ/kQgzjUuvrP+aA2/grZheIWoK3Qgs61taQ6pJ6gat9tbju+V4LfPQXv LBVDEmbRALSah641+SQG5m2vi3SYYDcEgwDY3ThHz1+apLfVbbWvxcP7E31p7BQgPZ+6 FUSA== X-Forwarded-Encrypted: i=1; AJvYcCUorxXrtddM8wDIkbLe87WleIxBwTLhHcKT3WmVZKhlBA7Su8sKSzDtJOH5DeI6WrSNYEwukb+fYaY=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw6wiTLKD/kR7tpkpL3atFoZyDEZG0deQ8XfLNNQiLC7jexi/LC B8lZ1K+4qKXNmC4TOtj6aGNAHxRJmi2TunQUOPr1+foMaFwlgDICIjqb X-Gm-Gg: AY/fxX7awoNBu+QEzuEaNZLc6WyyHQUlaigfh8ApDQSuypZvG8G6GCOM8PQ2hRf8kFT QcsCSCBuM4BMN4kysbwPoKJNIhhUx3066ARY4CEfVa/NZKK7oCm/OdcGHt6bFZSu/SA0rrWufDp 35xpUhbemIuTCFoiQ8VvpgW4kYO7CoCCsw946b/oBXdSGa/aHUTQP7/aeJJhM2FirzdLOEFgzX/ 7UDw/fsWPhmsE5QFrWZ+fukJaDRbzARFnnJzCHiG38gQyCtbc5rZmUFReRjMpckto4w8/0AM7/Q H/ld6VrKRR6vXwQEAeON0vpLzLwExUKjND5lgPECvBZcYrWNSJcDWbLhui8TVOfCxcbL5CDCCxA 8X+fhmTh5MiYOokUJ7Xsho/CShSVw/SvRqsWVPM+Pa9D3VY4NlnkYpQBL8cn06jx+WHO6CMGGgN sl1KwsXJLtqJGjwMy8Cfm1I6ah6wgW3wPCfFW7Cy00mzHYMQvx8Qq7Z9wDn7FgrlI= X-Received: by 2002:a17:906:f597:b0:b87:703c:139d with SMTP id a640c23a62f3a-b87703c1e8fmr72565866b.3.1768393627045; Wed, 14 Jan 2026 04:27:07 -0800 (PST) Message-ID: Date: Wed, 14 Jan 2026 13:27:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 08/15] xen/riscv: introduce vtimer_set_timer() and vtimer_expired() 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: <8cd3efa488b3da2a6751c92d20bbfeb87b3ba39a.1766595589.git.oleksii.kurochko@gmail.com> <4e18e4fc-de62-44fc-8ea0-517f6c7ef47f@gmail.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 1/13/26 4:12 PM, Jan Beulich wrote: > On 13.01.2026 15:44, Oleksii Kurochko wrote: >> On 1/8/26 11:28 AM, Jan Beulich wrote: >>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>> + vcpu_unset_interrupt(t->v, IRQ_VS_TIMER); >>>> + >>>> + /* >>>> + * According to the RISC-V sbi spec: >>>> + * If the supervisor wishes to clear the timer interrupt without >>>> + * scheduling the next timer event, it can either request a timer >>>> + * interrupt infinitely far into the future (i.e., (uint64_t)-1), >>>> + * or it can instead mask the timer interrupt by clearing sie.STIE CSR >>>> + * bit. >>>> + */ >>> And SBI is the only way to set the expiry value? No CSR access? (Question >>> also concerns the unconditional vcpu_unset_interrupt() above.) >> If we don't have SSTC extension support then I suppose yes, as CSR_MI{E,P} could >> be accessed only from M-mode: > How do M-mode CSRs come into play here? My question was rather towards ... Without SSTC (Supervisor Timer Extension) the current Privileged arch specification only defines a hardware mechanism for generating machine-mode timer interrupts (based on the mtime and mtimecmp registers). With the resultant requirement that timer services for S-mode/HS-mode (and for VS-mode) have to all be provided by M-mode - via SBI calls from S/HS-mode up to M-mode (or VS-mode calls to HS-mode and then to M-mode). > >> (code from OpenSBI) >> void sbi_timer_event_start(u64 next_event) >> { >> sbi_pmu_ctr_incr_fw(SBI_PMU_FW_SET_TIMER); >> >> /** >> * Update the stimecmp directly if available. This allows >> * the older software to leverage sstc extension on newer hardware. >> */ >> if (sbi_hart_has_extension(sbi_scratch_thishart_ptr(), SBI_HART_EXT_SSTC)) { >> #if __riscv_xlen == 32 >> csr_write(CSR_STIMECMP, next_event & 0xFFFFFFFF); >> csr_write(CSR_STIMECMPH, next_event >> 32); >> #else >> csr_write(CSR_STIMECMP, next_event); >> #endif > ... what if a guest did these CSR writes directly. Besides intercepting > access to them, These registers are available only when the SSTC extension is present. When SSTC is available and a guest accesses CSR_STIMECMP{H}, it actually accesses the corresponding VS aliases, VSTIMECMP{H}. The hardware continuously compares the value in VSTIMECMP against the guest’s view of time (time + htimedelta). When the condition is met, the hardware asserts the virtual supervisor timer interrupt pending bit (VSTIP) in the hypervisor’s HIP register and guest automatically receives timer interrupt. Therefore, there is no real need to intercept accesses to these registers. It is possible that VS-mode software may continue to use the SBI timer call instead of directly accessing the SSTC CSRs. In that case, VSTIMECMP would need to be updated manually by the hypervisor when such an SBI call occurs. However, this is not the case at the moment, as the SSTC extension is not currently supported. Technically, the hypervisor could also clear henvcfg.STCE when SSTC is vailable. In that case, the hypervisor would receive an illegal instruction trap in HS-mode when the guest attempts to access SSTC-related registers. However, I do not see a reason to prevent delegation of SSTC register access to the guest, since SSTC provides VS-* aliases for these registers, so I don't consider that as a real case. > you'd also need to synchronize both paths, I suppose. I didn't get you what is needed to be synchronized. Could you please explain? > >>>> + { >>>> + stop_timer(&t->timer); >>>> + >>>> + return; >>>> + } >>>> + >>>> + set_timer(&t->timer, expires); >>> See the handling of VCPUOP_set_singleshot_timer for what you may want to >>> do if the expiry asked for is (perhaps just very slightly) into the past. >> I got an idea why we want to check if "expires" already expired, but ... >> >>> There you'll also find a use of migrate_timer(), which you will want to >>> at least consider using here as well. >> ... I don't get why we want to migrate timer before set_timer() here. >> Could you please explain that? > Didn't I see you use migrate_timer() in other patches (making me assume > you understand)? Having the timer tied to the pCPU where the vCPU runs > means the signalling to that vCPU will (commonly) be cheaper. I thought that migrate_timer() is needed only when a vCPU changes the pCPU it is running on to ensure that it is running on correct pCPU after migrations, hotplug events, or scheduling changes. That is why I placed it in vtimer_restore(), as there is no guarantee that the vCPU will run on the same pCPU it was running on previously. So that is why ... > Whether > that actually matters depends on what vtimer_expired() will eventually > contain. Hence why I said "consider using". ... I didn't get why I might need vtimer_expired() in vtimer_set_timer() before set_timer(). vtimer_expired() will only notify the vCPU that a timer interrupt has occurred by setting bit in irqs_pending bitmap which then will be synced with vcpu->hvip, but I still do not understand whether migrate_timer() is needed before calling set_timer() here. Considering that vtimer_set_timer() is called from the vCPU while it is running on the current pCPU, and assuming no pCPU rescheduling has occurred for this vCPU, we are already on the correct pCPU. If pCPU rescheduling for the vCPU did occur, then migrate_timer() would have been called in context_switch(), and at the point where vtimer_set_timer() is invoked, we would already be running on the correct pCPU. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Jan 14 12:41:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 12:41:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203022.1518360 (Exim 4.92) (envelope-from ) id 1vg0BS-0001pL-6B; Wed, 14 Jan 2026 12:41:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203022.1518360; Wed, 14 Jan 2026 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 1vg0BS-0001pD-2P; Wed, 14 Jan 2026 12:41:10 +0000 Received: by outflank-mailman (input) for mailman id 1203022; Wed, 14 Jan 2026 12:41: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 1vg0BQ-0001p7-TJ for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 12:41:08 +0000 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [2a00:1450:4864:20::632]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4b6897d3-f146-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 13:41:06 +0100 (CET) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-b86f69bbe60so501586766b.1 for ; Wed, 14 Jan 2026 04:41:06 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8724197145sm760383566b.11.2026.01.14.04.41.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 04:41:05 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4b6897d3-f146-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768394466; x=1768999266; 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=ueYzrlq5f6o6Qg9JN81RVR2RMsGpdW8chZWBb2RnORY=; b=g0zxI1gHsKlg0vOoRBvMbNuzS5uxZ7ryR4bdESWo8eMbY0MIzEBuwho5MXTr6vknj3 7dBZbvbv8HupBd86e6dyFb3FEkkHszp1XpmEB8MTNK56jiRzJLQXQ/yNZfEYVPQkQoXh XdGHJm6dvRAmYpdEiWdDF+fot0v95xfsXTh9XxWh09AbD85cm4JgUcdl78mQVmCawbw6 X73WnSkug/QGZzjBnty+ZMwKPWyteihwjJ11dlqhZ6+insw4QPUWqguxjNRwmCRCDowl uNO7vlHF1gfLO16IcRamIsl5N2J0DecSdbzUUEX+1cxXnzcA3CRo3seLcg54dWIeDzTc +Rsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768394466; x=1768999266; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ueYzrlq5f6o6Qg9JN81RVR2RMsGpdW8chZWBb2RnORY=; b=sF+C7q0b50pgSzhwIKqRLIV3FuRCTsy7qS9vIXXWglF5CEtOGnMashjINFqmbQkY7w rP9Zi2l5aVv18r07a8JCPBfB83AHyMz/Ya48q9KsJQPHK3o8FAfLRQx54fgWmsCMQ58E 4AD+kvywhitx/x9Yo/Shpminc3jP6yUhE1VPDpZpk/OiX7RAPMEXZTFYoAAyFhxEkXBC Ga9wxEBJA5ndboeJmTiIEjmhEJOAYtDtaQcY8uQTOe79GkKok0TQ7Fe6dFA/5Lo8cYAO Tnfb08c9C8jp8IvaHYhokkdnMcuWzRQmhEtQOJB4vkWyNbo/N++qjZImcMUi8wBivTcO GJCQ== X-Forwarded-Encrypted: i=1; AJvYcCUwvSdeYFLb7UwZlmMT0cy3VG95viJP7Xn1hVEiYpYCrfE4eACLKxxvKxExNDgqQrGeT5vCNuouYEA=@lists.xenproject.org X-Gm-Message-State: AOJu0YyWZQscIYWiUNyi20K2SQ/Goy3ikf7gw38IyJKInjEM/PtC31Gr /ofp51iX4bcX2QxilY++aZf7nyaLU+oNCSkL2Vcd6xI8XOHlMFnZpMt9 X-Gm-Gg: AY/fxX7qb4fvs5TlRDNYndL301W06qD+mXq8Ye+bba2Y2PT9uTewWXVq6RSfe4zm0Ke WNnqU2CzjhBCuxGy6U3dJYl5Scsomc+NwfZEtr17+TMLTLkNzd0RxUjft8ixcgauyOjaGzmfWg1 cHxLKyrP0kUe8QBdgACM/JMchRD4/jH0wizwAJ9gjXiYZanUQ79AM8ytRsQ/di62m2Wo4dobDpC FnTHLfdTofV3076N9kvi9ugQ+oBzW/qGTIRKQGAEhqORmLMBftqgdUTZf8onpVQo6hsfjVE9T6N 5oOykTL2fufkQlSx0P80+stSQdFvm/A2dhRiJOCzJ8p4nfR5b3+DkMgoM/7jqVLQMkxs41q1vev 8nwMlgY+KzcfkNqEImq0g9ugDrgE05G+W4ksgc0V34vEf+WvwvS8zCITcgDw8eTE52K1FxO4phB 8YZwmvHWUpulMxVSPJg4U/W55bmXoHf9ERd+Z7BZmWqj50IhxW1nD39JWQdT2yUtk= X-Received: by 2002:a17:907:2da8:b0:b87:2b61:b03e with SMTP id a640c23a62f3a-b8761021a6amr212998966b.14.1768394465673; Wed, 14 Jan 2026 04:41:05 -0800 (PST) Message-ID: Date: Wed, 14 Jan 2026 13:41:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 13/15] xen/riscv: implement reprogram_timer() using SBI 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: <43249171def325c49541ebdac141fe99d159b60f.1766595589.git.oleksii.kurochko@gmail.com> <90e7fc60-09cc-4b61-ab0a-80037f8ecaf8@gmail.com> <4141bb71-7aef-4287-aefd-92009977294f@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/14/26 12:17 PM, Jan Beulich wrote: > On 14.01.2026 11:33, Oleksii Kurochko wrote: >> On 1/14/26 10:53 AM, Jan Beulich wrote: >>> On 14.01.2026 10:41, Oleksii Kurochko wrote: >>>> On 1/14/26 10:13 AM, Jan Beulich wrote: >>>>> On 13.01.2026 17:50, Oleksii Kurochko wrote: >>>>>> On 1/12/26 4:24 PM, Jan Beulich wrote: >>>>>>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>>>>>> @@ -39,6 +43,33 @@ static void __init preinit_dt_xen_time(void) >>>>>>>> cpu_khz = rate / 1000; >>>>>>>> } >>>>>>>> >>>>>>>> +int reprogram_timer(s_time_t timeout) >>>>>>>> +{ >>>>>>>> + uint64_t deadline, now; >>>>>>>> + int rc; >>>>>>>> + >>>>>>>> + if ( timeout == 0 ) >>>>>>>> + { >>>>>>>> + /* Disable timers */ >>>>>>>> + csr_clear(CSR_SIE, BIT(IRQ_S_TIMER, UL)); >>>>>>>> + >>>>>>>> + return 1; >>>>>>>> + } >>>>>>>> + >>>>>>>> + deadline = ns_to_ticks(timeout) + boot_clock_cycles; >>>>>>>> + now = get_cycles(); >>>>>>>> + if ( deadline <= now ) >>>>>>>> + return 0; >>>>>>>> + >>>>>>>> + /* Enable timer */ >>>>>>>> + csr_set(CSR_SIE, BIT(IRQ_S_TIMER, UL)); >>>>>>> Still learning RISC-V, so question for my understanding: Even if the timeout >>>>>>> is short enough to expire before the one SIE bit will be set, the interrupt >>>>>>> will still occur (effectively immediately)? (Else the bit may need setting >>>>>>> first.) >>>>>> The interrupt will become pending first (when mtime >= mtimecmp or >>>>>> mtime >= CSR_STIMECMP in case of SSTC) and then fire immediately once >>>>>> |SIE.STIE |(and global|SIE|) are enabled. >>>>>> >>>>>>>> + if ( (rc = sbi_set_timer(deadline)) ) >>>>>>>> + panic("%s: timer wasn't set because: %d\n", __func__, rc); >>>>>>> Hmm, if this function ends up being used from any guest accessible path (e.g. >>>>>>> a hypercall), such panic()-ing better shouldn't be there. >>>>>> I don't have such use cases now and I don't expect that guest should use >>>>>> this function. >>>>> How do you envision supporting e.g. VCPUOP_set_singleshot_timer without >>>>> involving this function? >>>> Looking at what is in common code for VCPUOP_set_singleshot_timer, it doesn't >>>> use reprogram_timer(), it is just activate/deactivate timer. >>> And how would that work without, eventually, using reprogram_timer()? While not >>> directly on a hypercall path, the use can still be guest-induced. >> Of course, eventually|reprogram_timer()| will be used. I incorrectly thought >> that we were talking about its direct use on the hypercall path. >> >> I am not really sure what we should do in the case when rc != 0. Looking at the >> OpenSBI call, it always returns 0, except when sbi_set_timer() is not supported, >> in which case it returns -SBI_ENOTSUPP. With such a return value, I think it would >> be acceptable to call domain_crash(current->domain). > How is current->domain related to a failure in reprogram_timer()? Agree, it isn't, a failure could happen during a ran of any domain. > >> On the other hand, if some >> other negative error code is returned, it might be better to return 0 and simply >> allow the timer programming to be retried later. >> However, if we look at the comments for other architectures, the meaning of a >> return value of 0 from this function is: >> Returns 1 on success; 0 if the timeout is too soon or is in the past. >> In that case, it becomes difficult to distinguish whether 0 was returned due to >> an error or because the timeout was too soon or already in the past. > Well, your problem is that neither Arm nor x86 can actually fail. Hence > calling code isn't presently prepared for that. With panic() (and hence > also BUG()) and domain_crash() ruled out, maybe generic infrastructure > needs touching first (in a different way than making the function's return > type "bool")? I think making the function's return still is fine and it is only question to arch-specific reprogram_timer() what to do when an error happens. Still doesn't clear to me what should be a reaction on failure of reprogram_timer(). Considering that SBI spec doesn't specify a list of possible errors and now the only possible error is -ENOSUPP it seems to me it is fine to have panic() as we don't have any other mechanism to set a timer except SBI call (except the case SSTC is supported then we can use just supervisor timer register directly without SBI call). ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Jan 14 12:50:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 12:50:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203036.1518370 (Exim 4.92) (envelope-from ) id 1vg0KJ-0003TZ-0U; Wed, 14 Jan 2026 12:50:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203036.1518370; Wed, 14 Jan 2026 12: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 1vg0KI-0003TS-TT; Wed, 14 Jan 2026 12:50:18 +0000 Received: by outflank-mailman (input) for mailman id 1203036; Wed, 14 Jan 2026 12:50:18 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg0KH-0003TM-Ro for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 12:50:18 +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 8cb00419-f147-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 13:50:06 +0100 (CET) Received: from BN9PR03CA0582.namprd03.prod.outlook.com (2603:10b6:408:10d::17) by DS0PR12MB8245.namprd12.prod.outlook.com (2603:10b6:8:f2::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Wed, 14 Jan 2026 12:50:02 +0000 Received: from BN3PEPF0000B373.namprd21.prod.outlook.com (2603:10b6:408:10d:cafe::da) by BN9PR03CA0582.outlook.office365.com (2603:10b6:408:10d::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Wed, 14 Jan 2026 12:49:46 +0000 Received: from satlexmb07.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_256_GCM_SHA384) id 15.20.9542.0 via Frontend Transport; Wed, 14 Jan 2026 12:50:02 +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; Wed, 14 Jan 2026 06:50:02 -0600 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 14 Jan 2026 06:50:01 -0600 Received: from [10.252.147.171] (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, 14 Jan 2026 06:49:59 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8cb00419-f147-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=RGH4hCyb8Z7XDZog/aQ2ULMDpi08Gif9SepZR56lY3H31jDAxFyUGm1OJUrefNvlCjQZU0hCMcwATDTB7ZcuKs/hALjZQRdh0Rd8uriR+VnfIkx5VH+E7AVi1b2apcg/+foxLxJhDktJpbbqgQAc21oPjmBEjCJGvVswNubm1AiVguqpd72tcmqBQlphHUtZ12j4pbILtYKHVwAgj3RdX7ZDs9ZNaYJLIAMzr/jEN/X/+vWOuw9bYQMpizjQXhuJkF11kQoLAzknlwjODm9y7aDQRY1C67q1ubbVkh89KVqCkveno9lkX1ycwQzLxUBAdDFPPCnnfFauvG5fO8DpEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0zZ9bo2AxtsZsclXePPyt8sA012nTA58g7aY6KPLgbc=; b=IiP/T8a3DBEK7holLn0IVKZNKMODt3FiyT8vm2WOWUkCFaU6NaAhK49r1R3nkkkE/BYUOur6rrVBO2lHIJSWGs7x2P7qAh7hz4DRMROfwoO7hQJc9UOSkW9sy7kWDz/4bh8h/ZCvHeTh3QrgG9viUQIIt0v5Vf6zmYW2ujjfNaNuuE+hCefMftRaSncvfgwxOBJyz3jvT3wykd5b1hdhYfg0yXUkpX2gqOeUV6Cv5ECFANer+V4w2MfN1x+Q132mEy7NSN3nUGjb/zcYNVBRST7fYYvKgcqmryglJ4SFzkKrYLegW7OQZPVmyJEDjP6WjANltrwve1Ep1YjdBrEtmw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0zZ9bo2AxtsZsclXePPyt8sA012nTA58g7aY6KPLgbc=; b=UvlAKitZ+p40Miygwv8v1p6diHjcUFC6+GbHSX4e+pRB0QF0B8WH0RmBggDlT/Mcafe1LBKB3+qCmZJfVZ8SiEjuqX9z3jyoPSyPPplO2IVwXjaUoa1T84xFwPVNe34f1xiN4rOOKs8aLYNJ7vHM1HHIp6LORJ3Rf9VzmyFSscw= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <9051c577-503f-487c-b180-36a4197e9bea@amd.com> Date: Wed, 14 Jan 2026 13:49:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/6] arm/mpu: Implement free_init_memory for MPU systems To: Harry Ramsey , CC: , Penny Zheng , "Stefano Stabellini" , Julien Grall , "Bertrand Marquis" , Volodymyr Babchuk , Wei Chen , Hari Limaye References: <20260113162309.6766-1-harry.ramsey@arm.com> <20260113162309.6766-4-harry.ramsey@arm.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20260113162309.6766-4-harry.ramsey@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF0000B373:EE_|DS0PR12MB8245:EE_ X-MS-Office365-Filtering-Correlation-Id: 044a32a6-f7a5-4527-4e69-08de536b6f06 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|82310400026|376014|36860700013|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?aUtPNFVkMThtQTk1SUNMekJrMHloWUlnc3VlTzVxRHRNYWI2eUl4MmJQSjRr?= =?utf-8?B?L0hKdGFXSVdoWFJzR2lsVXNVY2s5OGZiTk5VM05JSldwTnFkKzV3TFRCeDA3?= =?utf-8?B?Y3Q4ZVVQaTI3ZlRLVWVXejVzS3RjcVFkNzBWL0ZUcVRJODVSQmZKVGFnSUp4?= =?utf-8?B?YWprMnBzQi8rczVVKzBKRmNDdytQbnNpYVhwWnRHdWJVVXNEZEpWTWhNNjNo?= =?utf-8?B?aFYveDBVcE1GQWtuZFUwU2tMUlBkbjFMTXhzU3RpSWV5Q1pVd3JiLzJpYkpC?= =?utf-8?B?WXNJZG1TNTJBd2hTcDhGKytVQkl0ZU9KcGFrcmRiY2hScHdpYWpaMUZDbHlj?= =?utf-8?B?aEp5NVkwcE5KU1YyNEF6ck5NMjNpYjZ2UjhHbU1QSXhxL1BjeDJxb0NmT3Nr?= =?utf-8?B?OVlWT1kwVy9DYWdIMEhqT0paWXo4SldOTGg1dC9OMlR6bHU2LzJJbFkrMmpX?= =?utf-8?B?L1kvQU1ZNlA1YUJlTjRka3JzVEdqN0JOVnVkUSt1blRhelRFZnUzUXdHQXlO?= =?utf-8?B?dDQwb21nRWhHZDlmeGhZNFRna1FUSGlYVGMyc1IrQm15NG9nZ0RUMk0wUWwx?= =?utf-8?B?L3gvd2tjeTJzNHdqeDI4TXR6cUpDMUl3NGdYeGZjekwrUmdEVmh3bzhCaG1G?= =?utf-8?B?eGxwcUdNS1I1dnU4VlZXQ3lWYUpGYm0wYlg4dTJpYjBtZzlmYml5VkY0NE5O?= =?utf-8?B?Vmhoemx5VUxubEhOOVBuaEtvcit6MlRVUi9PSWZYbjJVMlo3cUZBaUJZbWIx?= =?utf-8?B?THVDeWhFRkxSV012dWtISFNSUU1HS2p0N1RCRXp5cHhnbDJZMEpMSUpiRk5x?= =?utf-8?B?MlRPS1pQcWdsUGVERVkvWDZseDMwdkFrTi9HQjBNRDJQclBCRlpjdWJHV3pL?= =?utf-8?B?T2VkUWd5VXJHaE50azRwcnl0aEdtYTB0SUFMQURHOFlhb0lreUtGbzlrK0lP?= =?utf-8?B?czFVeFREVXJtdlhWemx4ZW5xV0tsaVlHc1Q2KzhXTUVsSUtwUHBCSzlEUlhl?= =?utf-8?B?N0lJMURDbmlyTFRnczA0ajhjbjFwWGt2QXIvSlR2bWxrdElpTEFPWW5jV3p6?= =?utf-8?B?Z2FlT2w0Qy9sek51Q2JobXhWY2FweHZNS3lzSXRDWXEzZXFmYjAzRGtzV1Fn?= =?utf-8?B?aWNGaHNVWGR6R0hGOXQ0MW9HYVd3WHVjSHg2d0t6ZHBiVy95NCtQdnhmZ0gy?= =?utf-8?B?YjZjZTQ5R3FMWGdkNTE2UGxRY2pUTVFjN3ZrUVRwWElKT2Y5WTNJUVQ0V2NJ?= =?utf-8?B?QWE2RkVZazJJTjN4TUxIY1pvWllkUkVJaEdQWVE2Y1JjZ3lKa25iNDhVY0k0?= =?utf-8?B?TUxuUWFtNDNPcFQvV3h0V3kwd3lxdExnYUxzRU4rcFdOS0ZhbmZzbEF2UWRW?= =?utf-8?B?ZTBjbFFEVE9WWnNCT2I2Y2hPbHROYkd2aUF5bjc2V2ZaL2kzcXo4anQ2WFZw?= =?utf-8?B?aU9acXBlYi91YWlpSmZaSkZqSVNCK0JKMG1nY2ZxMXV5REtzaDVwQ0d4b2dw?= =?utf-8?B?WXhCK21IREY1dzZKbGFobDErYnA4NUNWNUNvNWkxaWRITDJpUnJId2g0Z1VT?= =?utf-8?B?VkVFM0VFNXMzMFVtejFlOHBpaUFpYnEwbFNsdW5BeDRZU1hob0F6VXJWR203?= =?utf-8?B?eHR4Y1hmQkVJVzYvanVSUEQ2dFdlNTVGZEttclYxdTk4TGFtQ2hIN1NUbFgw?= =?utf-8?B?dS9QbnhSVC81aitVbnlCa3lKTmNPOHVWQUI4anAxdSsxNnVSRjUzSXdsSEF4?= =?utf-8?B?UkplT0wxZWJyWHNLOVJCa0RFb2hIT001WmcyZ0UvUW1aOHRkcW9SQXlQWGtK?= =?utf-8?B?SXl1Rmd4a1hzTXIrNXVtUkVLMGN6UnAyNXlwdm5nUE5DWEZoa3ppTGN2aHR4?= =?utf-8?B?SHIrOHRRb3J5a29sOFBqSkNJZlhud3l5OGFsQTNDTTcvTU5OZElMYkowdi9q?= =?utf-8?B?ZkZaOUU5SFJZZENHTlhXUE5nMnAwOE13Q1JhaWNnZ2lTOU1QRkhGK0FrZG03?= =?utf-8?B?eUlBWHQ3ZFJIcGJzUTBvQjVQNDhkZURBY1FPVG5aWmhqc0VLWDVsQmtFSks2?= =?utf-8?B?ajJ2ODMzeDhMMEVvdFdhYU41UFFHMHIweTJOTm5uOGVHUFpJeFNuc1JyQjhu?= =?utf-8?B?QXFvNW1jT3J2MlRSTWZjbkR0b0VaWUFVNmxJRjNsc0FQa1RVUkx5VTFSMkth?= =?utf-8?B?WUxjRC9pWXJhd3U4TlFOcEEzS2FzVjkxUk1HWFlPUG9zMDNIQ2pmQUJpMnNh?= =?utf-8?B?SDQ4TDNyNTlpdlU0VHI2QjJnVXBnPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(82310400026)(376014)(36860700013)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2026 12:50:02.2095 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 044a32a6-f7a5-4527-4e69-08de536b6f06 X-MS-Exchange-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: BN3PEPF0000B373.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8245 On 13/01/2026 17:23, Harry Ramsey wrote: > From: Penny Zheng > > Implement the function `free_init_memory` for MPU systems. In order to > support this, the function `modify_xen_mappings` is implemented. > > On MPU systems, we map the init text and init data sections using > separate MPU memory regions. Therefore these are removed separately in > `free_init_memory`. > > Additionally remove warning messages from `is_mm_attr_match` as some > attributes can now be updated by `xen_mpumap_update_entry`. > > Signed-off-by: Penny Zheng > Signed-off-by: Wei Chen > Signed-off-by: Luca Fancellu > Signed-off-by: Hari Limaye > Signed-off-by: Harry Ramsey > --- > v3: > - Refactor MPU_ATTR_* defines > v2: > - Refactor `is_mm_attr_match` to return logical values regarding the > attribute mismatch. > - Improve code documentation. > --- > xen/arch/arm/include/asm/setup.h | 2 + > xen/arch/arm/mpu/mm.c | 119 +++++++++++++++++++++++-------- > 2 files changed, 93 insertions(+), 28 deletions(-) > > diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h > index 1eaf13bd66..005cf7be59 100644 > --- a/xen/arch/arm/include/asm/setup.h > +++ b/xen/arch/arm/include/asm/setup.h > @@ -65,6 +65,8 @@ int map_irq_to_domain(struct domain *d, unsigned int irq, > int map_range_to_domain(const struct dt_device_node *dev, > uint64_t addr, uint64_t len, void *data); > > +extern const char __init_data_begin[], __bss_start[], __bss_end[]; > + > struct init_info > { > /* Pointer to the stack, used by head.S when entering in C */ > diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c > index 14a988ea0c..5633c1c4c5 100644 > --- a/xen/arch/arm/mpu/mm.c > +++ b/xen/arch/arm/mpu/mm.c > @@ -15,6 +15,9 @@ > #include > #include > > +#define MPU_ATTR_XN_RO_MISMATCH -1 > +#define MPU_ATTR_AI_MISMATCH -2 > + > struct page_info *frame_table; > > /* Maximum number of supported MPU memory regions by the EL2 MPU. */ > @@ -171,33 +174,16 @@ int mpumap_contains_region(pr_t *table, uint8_t nr_regions, paddr_t base, > return MPUMAP_REGION_NOTFOUND; > } > > -static bool is_mm_attr_match(pr_t *region, unsigned int attributes) > +static int is_mm_attr_match(pr_t *region, unsigned int attributes) > { > - if ( region->prbar.reg.ro != PAGE_RO_MASK(attributes) ) > - { > - printk(XENLOG_WARNING > - "Mismatched Access Permission attributes (%#x instead of %#x)\n", > - region->prbar.reg.ro, PAGE_RO_MASK(attributes)); > - return false; > - } > - > - if ( region->prbar.reg.xn != PAGE_XN_MASK(attributes) ) > - { > - printk(XENLOG_WARNING > - "Mismatched Execute Never attributes (%#x instead of %#x)\n", > - region->prbar.reg.xn, PAGE_XN_MASK(attributes)); > - return false; > - } > + if ( (region->prbar.reg.xn != PAGE_XN_MASK(attributes)) || > + (region->prbar.reg.ro != PAGE_RO_MASK(attributes)) ) > + return MPU_ATTR_XN_RO_MISMATCH; > > if ( region->prlar.reg.ai != PAGE_AI_MASK(attributes) ) > - { > - printk(XENLOG_WARNING > - "Mismatched Memory Attribute Index (%#x instead of %#x)\n", > - region->prlar.reg.ai, PAGE_AI_MASK(attributes)); > - return false; > - } > + return MPU_ATTR_AI_MISMATCH; > > - return true; > + return 0; > } > > /* Map a frame table to cover physical addresses ps through pe */ > @@ -358,12 +344,44 @@ static int xen_mpumap_update_entry(paddr_t base, paddr_t limit, > */ > if ( flags_has_page_present && (rc >= MPUMAP_REGION_FOUND) ) > { > - if ( !is_mm_attr_match(&xen_mpumap[idx], flags) ) > + int attr_match = is_mm_attr_match(&xen_mpumap[idx], flags); > + > + /* We do not support modifying AI attribute. */ > + if ( MPU_ATTR_AI_MISMATCH == attr_match ) > { > - printk("Modifying an existing entry is not supported\n"); > + printk(XENLOG_ERR > + "Modifying memory attribute is not supported\n"); Because this message is the same as the one a bit lower I would suggest to do s/memory/AI/ here... > return -EINVAL; > } > > + /* > + * Attributes RO and XN can be changed only by the full region. > + * Attributes that match can continue and just increment refcount. > + */ > + if ( MPU_ATTR_XN_RO_MISMATCH == attr_match ) > + { > + if ( rc == MPUMAP_REGION_INCLUSIVE ) > + { > + printk(XENLOG_ERR > + "Cannot modify partial region attributes\n"); > + return -EINVAL; > + } > + > + if ( xen_mpumap[idx].refcount != 0 ) > + { > + printk(XENLOG_ERR > + "Cannot modify memory attributes for a region mapped multiple times\n"); and s/memory/RO,XN/ here. > + return -EINVAL; > + } > + > + /* Set new attributes */ > + xen_mpumap[idx].prbar.reg.ro = PAGE_RO_MASK(flags); > + xen_mpumap[idx].prbar.reg.xn = PAGE_XN_MASK(flags); > + > + write_protection_region(&xen_mpumap[idx], idx); > + return 0; > + } > + > /* Check for overflow of refcount before incrementing. */ > if ( xen_mpumap[idx].refcount == 0xFF ) > { > @@ -514,8 +532,7 @@ void __init setup_mm_helper(void) > > int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf) > { > - BUG_ON("unimplemented"); > - return -EINVAL; > + return xen_mpumap_update(s, e, nf); > } > > void dump_hyp_walk(vaddr_t addr) > @@ -526,7 +543,53 @@ void dump_hyp_walk(vaddr_t addr) > /* Release all __init and __initdata ranges to be reused */ > void free_init_memory(void) > { > - BUG_ON("unimplemented"); > + unsigned long inittext_end = (unsigned long)__init_data_begin; > + unsigned long len = __init_end - __init_begin; > + uint8_t idx; > + int rc; > + > + /* Modify inittext region to be read/write instead of read/execute. */ > + rc = modify_xen_mappings((unsigned long)__init_begin, inittext_end, > + PAGE_HYPERVISOR_RW); > + if ( rc ) > + panic("Unable to map RW the init text section (rc = %d)\n", rc); > + > + /* > + * From now on, init will not be used for execution anymore, > + * so nuke the instruction cache to remove entries related to init. > + */ > + invalidate_icache_local(); > + > + /* > + * The initdata region already has read/write attributes so it can just be > + * zeroed out. > + */ > + memset(__init_begin, 0, len); > + > + rc = destroy_xen_mappings((unsigned long)__init_begin, inittext_end); > + if ( rc ) > + panic("Unable to remove init text section (rc = %d)\n", rc); > + > + /* > + * The initdata and bss sections are mapped using a single MPU region, so > + * modify the start of this region to remove the initdata section. > + */ > + spin_lock(&xen_mpumap_lock); > + > + rc = mpumap_contains_region(xen_mpumap, max_mpu_regions, > + (unsigned long)__init_data_begin, > + (unsigned long)__bss_end, NIT: I'm thinking if it would not make sense to add some sanity checks in the future to make sure the layout is as expected. For example, what if a new section appeared between __init_end and __bss_start in the future? For this patch with the printk adjustments: Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Wed Jan 14 13:42:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 13:42:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203091.1518379 (Exim 4.92) (envelope-from ) id 1vg18l-0001TO-R1; Wed, 14 Jan 2026 13:42:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203091.1518379; Wed, 14 Jan 2026 13:42:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg18l-0001TH-O8; Wed, 14 Jan 2026 13:42:27 +0000 Received: by outflank-mailman (input) for mailman id 1203091; Wed, 14 Jan 2026 13:42:25 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg18j-0001TB-SV for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 13:42:25 +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 db574848-f14e-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 14:42:24 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-47775fb6cb4so48148505e9.0 for ; Wed, 14 Jan 2026 05:42:24 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee27cf06bsm21671155e9.4.2026.01.14.05.42.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 05:42:23 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: db574848-f14e-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768398144; x=1769002944; 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=nUWllKMPpy9udsf1yQ3TeWLTtx1XYb7DE5BROOZsni8=; b=dF984FPDY3pfvvIdl73+fWrRH6532CDoTxA3i8NTG+oPa8Ey8dcVA/pO3CXunREGcF nMIRa/0D/PPHRbj5n9FJq03Bxo+AamQvnNPr0AxKDuSp0HhzImJuZiDO/YFPCOUv1xZj bicaZLFw5runPqstTLGinPxZK7ms2gxCLAGC5Lujj1As7rSqInrUuKwTTKbz66BK9/L1 v1HkMXI8bRrW5NOb4T5+8iJtJHKOEvuxC+5QQhFAGbhGib4/BK7BufGL7gLs6FtJB3Cj zkXtk+MSJC9Rr6aV9tFYkYnwMePTyAd8ti2A7O1JCjLAb54so1WX+gO49BW3Yjl/k7/K e+Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768398144; x=1769002944; h=content-transfer-encoding:autocrypt:content-language:cc:to:subject :from:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nUWllKMPpy9udsf1yQ3TeWLTtx1XYb7DE5BROOZsni8=; b=i9svyeyng/1QzJft8tNPId9I9e9Bp04CasGx/9ZLfkPqsDPlulc32OBGV84Z9V0oVT oQdP2rvhKMpkA7PIOESatqmx3mVcOiyrUqaw6lUU7UFtIWmb50jD17NQDmASnEymlt8x 76Wp6r0yXqDVNoUQ6rcOR1hZfkdw+8YXfurZg+luQyeceK+rpyhmVB6MTwVdVb45z4Ae s9S6r6HfJBGhA2yB/BOwQZ+r6DHNMJ8hKk/av1YiBjuw4Z2eSpD0GvGVqNCsX9/ppWxe ZLHo6k8x/+186TcbDZ/126m9IR3L+0aTD5PxGK2ISHDN3mqaovb80v2ZMKOPpgklrLIu LlBw== X-Gm-Message-State: AOJu0Yw7GswVKRXb/o5CHoHOONu/Qa61ZoKSt7wMF4CbcSIR9fNl4fE/ /4lm8DOhw+Oj3SHW/YXhElhsAFXVwKDs811XOlfucR2XSTxCr9SkL5ncBa82X1EpTjiS/tXHLd5 ZIMU= X-Gm-Gg: AY/fxX6cDxOAEOCBfL4n0bBBU37kKQDvZ69OsbKmJScoLA7IhPM/SPUKFF+i/AUA66L tkvoum5t91YIgJPrcKEbYGtjR7FnIHtq2GgjrEg8bmUo5Hbi0JkdiYY1CfBiwo4OlJs27AjOBPZ G7vETHVN4arxxHyJLtV1hOuvuLWdU9ZyDuINvJxsKmpm9i+NGuY0pZYRvysD2NohYthqcbQP/Yd eQSbwF2BN8XiAjcXD/DDkLPYzbw6+jAWgc5aoQE7LWQxJkQMTzI79SpXQNDcI/uwJozPjKwrsBS gkfujSPGNy1V93eX2dfmFDOL4Hl5sEEy24gRgmf3GPuW4Hh3sizJcPw/uUyHINzWIbyPEoESW2t at4UIOKFj7K7ScnRe2Vmba5GP8MYH9ze2kSjaSOHT3XVDGno5oy/yRwqPiLQxIxnhpTi5359hj5 o4p9m0mJZooLqq/vcTBG9at11wWmrk4X6wDlG/Bj1/3mpK1ZhAd8Hl78cNzFqBGpUMto1h4Y6cp cY= X-Received: by 2002:a05:600c:4ed0:b0:47a:8cce:2940 with SMTP id 5b1f17b1804b1-47ee33454b6mr33160745e9.14.1768398143676; Wed, 14 Jan 2026 05:42:23 -0800 (PST) Message-ID: <4d3a3576-2d3c-42ec-8551-18f1f0982e17@suse.com> Date: Wed, 14 Jan 2026 14:42:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jan Beulich Subject: [PATCH v3 0/6] x86: CPUID leaf 6 consolidation 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 Integrate this leaf with CPU policy handling, to leverage the host policy when feature bits need evaluating. 1: cpu-policy: define bits of leaf 6 2: replace APERRMPERF synthetic feature bit 3: rename ARAT feature flag 4: Intel: use host CPU policy for ARAT checking 5: cpufreq: use host CPU policy for Turbo checking 6: cpufreq: use host CPU policy in HWP driver Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 14 13:43:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 13:43:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203099.1518390 (Exim 4.92) (envelope-from ) id 1vg19p-0001w7-3o; Wed, 14 Jan 2026 13:43:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203099.1518390; Wed, 14 Jan 2026 13:43: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 1vg19p-0001w0-0k; Wed, 14 Jan 2026 13:43:33 +0000 Received: by outflank-mailman (input) for mailman id 1203099; Wed, 14 Jan 2026 13:43: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 1vg19o-0001vr-0C for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 13:43:32 +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 03153e08-f14f-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 14:43:30 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-47ee807a4c5so2789935e9.2 for ; Wed, 14 Jan 2026 05:43:30 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee117e607sm23269505e9.3.2026.01.14.05.43.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 05:43:30 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 03153e08-f14f-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768398210; x=1769003010; 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=jUEWqlGQFbFZZkXGuB5GSbnLbTvfhpgjhZFwTESoBRI=; b=bJMQHrZXMo/qTUu3fkeOwajH7CGznh9rPvgT+6MQ2fevO4EKkv/eMzVw+2AuRrVgA0 fUfHhXoCnBq1BBEgbNTBls5Mqvx2pynu1qcx9hVVfmRC8R35PloZ5aSFP6QEjvmnJsMr Mi1wlcS5xoKtXfAObzH4J755hcqpvJL28txkukxp7MbaNc7ptzvjYqlmhkZMdQzaFwC6 xEZH0Ts2Gyx1nIuy56/+HpPO7kIKLAHxfNsn+gpk/RQOOZFJ21Nx4PksxGucSbl0LFWe SD4tDjmc6pDXNzgrPIDP+o93KRewV5V9M11n86JLn163tXonQcWe7lwSScGeD+CSkbC6 a0YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768398210; x=1769003010; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=jUEWqlGQFbFZZkXGuB5GSbnLbTvfhpgjhZFwTESoBRI=; b=KycN0IE5WfGWHucpt9syrl6U+3gKMTlahy8UsivchgXx3/tGQBTdI0l399XRqtvVLs kgXr25vi7oaQxsl/Lb7irjvcHBscVPxoDmmhIuBrCQCkuIKaj1jc1jl8nl81ILbUC1gH eH2oCtXnOIW3hIqUnrMftRAcYee0A9+k5GQjq+5ZJKFXvDwFT+K6Xv3c77DeONCieaOZ yqvLayxWAEpNpVTAUr+L0eaA7xIqBrDy5OI5ukvrp3Z0oy/XI5d3CkLn50l2HzTY0FgQ IhjqzWXOfTfoQHHpTHosL3OQnA4vZmSjRsD8n8eMzCypxzfQYv7U44HTeVPJHbDeWLnZ EyLA== X-Gm-Message-State: AOJu0Yzj8mrOZ0RVbN1Yg/0oWyVejQxkDSg8TDXBVvJxxKQbH8CTItfV MTWo4fQkSXlN3SIFnxsbYaPLlBoaSj/Kbl3utzCrwcwKrbzV2U+3rEhHJL+yIjRG8+c10o/Houe 2Y0Y= X-Gm-Gg: AY/fxX6a4/oyS5in0SWDKKBmzPpNpjxWs3TScMhKMnC1mV4fsuHJJbLoQ7bOBaeu6nr 25t0EcGpTs8PqUffZ+A4/ywwD1DJncPA7dvw+Yp7Uih05xw5b0KX2NRR96nBGagvh4tHKVvJh26 Pa7FsDiFUxv9hNlYgM16eRwNTJeAe1XlqRzzkuSv8JTIcVk65tPnO2gNxyjxzpENmYfYIFBojGq hHK58cRUq1/eUb0yX9D/BDkoh5nd900Jzk5it/kPBM3Ihxhhdue33VArXrXZxffDgJbvzW/vPWN n4TjBdpM2NnN+fcl8MRCNNYkOUiq7Px+4XiUOLFvL3NbK8mSjT5A+gqMojo1D7oLIQ72Xiim8EJ +wIIC7bpAxDo6lWOx97FBeXbB1H0HsdB1PHBqf5dsY1PRK90TwcIFvyUsWTFHXphn0AT9et9+gX LQQaibMoORVoZgUrIrVmyk5Z3NpqxWHjgIA4wWLxEjCAGWDboUxR5XkCDcGYHyXFyN5qhvPAyjX J4= X-Received: by 2002:a05:600c:1549:b0:47e:e946:3a72 with SMTP id 5b1f17b1804b1-47ee9816cafmr1874905e9.27.1768398210367; Wed, 14 Jan 2026 05:43:30 -0800 (PST) Message-ID: Date: Wed, 14 Jan 2026 14:43:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v3 1/6] x86/cpu-policy: define bits of leaf 6 From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie References: <4d3a3576-2d3c-42ec-8551-18f1f0982e17@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: <4d3a3576-2d3c-42ec-8551-18f1f0982e17@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ... as far as we presently use them in the codebase. Signed-off-by: Jan Beulich --- Or should we make both parts proper featureset elements? At least APERFMPERF could likely be made visible to guests (in principle). --- v3: Use SDM-conforming names. (Sorry Jason, had to drop you R-b once again.) v2: Use bool and unions. --- a/xen/include/xen/lib/x86/cpu-policy.h +++ b/xen/include/xen/lib/x86/cpu-policy.h @@ -121,7 +121,46 @@ struct cpu_policy uint64_t :64, :64; /* Leaf 0x3 - PSN. */ uint64_t :64, :64; /* Leaf 0x4 - Structured Cache. */ uint64_t :64, :64; /* Leaf 0x5 - MONITOR. */ - uint64_t :64, :64; /* Leaf 0x6 - Therm/Perf. */ + + /* Leaf 0x6 - Therm/Perf. */ + union { + uint32_t _6a; + struct { + bool :1, + turbo_boost:1, + arat:1, + :1, + :1, + :1, + :1, + hwp:1, + hwp_interrupt:1, + hwp_activity_window:1, + hwp_epp:1, + hwp_request_pkg:1, + :1, + hdc:1, + :1, + :1, + hwp_peci_override:1, + :1, + :1, + hw_feedback:1; + }; + }; + union { + uint32_t _6b; + }; + union { + uint32_t _6c; + struct { + bool hw_feedback_cap:1; + }; + }; + union { + uint32_t _6d; + }; + uint64_t :64, :64; /* Leaf 0x7 - Structured Features. */ uint64_t :64, :64; /* Leaf 0x8 - rsvd */ uint64_t :64, :64; /* Leaf 0x9 - DCA */ From xen-devel-bounces@lists.xenproject.org Wed Jan 14 13:43:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 13:43:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203103.1518400 (Exim 4.92) (envelope-from ) id 1vg1A9-0002KZ-BE; Wed, 14 Jan 2026 13:43:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203103.1518400; Wed, 14 Jan 2026 13: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 1vg1A9-0002KS-7r; Wed, 14 Jan 2026 13:43:53 +0000 Received: by outflank-mailman (input) for mailman id 1203103; Wed, 14 Jan 2026 13:43: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 1vg1A8-0002Ig-9G for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 13:43:52 +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 0ea617b9-f14f-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 14:43:50 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-47775fb6c56so83045085e9.1 for ; Wed, 14 Jan 2026 05:43:50 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee562df81sm27997295e9.10.2026.01.14.05.43.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 05:43:49 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0ea617b9-f14f-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768398229; x=1769003029; 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=KQ36zvjxXpDCUHe0Pi5BKTF7mvA6vIQwzP/JbYlUIEI=; b=Ro7hU4DXl919NDp45CQPplGNokxbzFUWKRswashXYdd0tfsvGcuGV9+N6zezxzGcSm jEUH3VqYWPXvuhsqHHmSt4x6vgjorod9agDUf0X3e+dFPw0skcIpVCtDcSwj7xqTu2fs BqriMXw8GXmyQui6/3+0xc0UxBo5p5lS6ZINBMh+P7HngEhV65wXfzws6dS+Qag1equl L96SFn3CzLs79Gkwvd0vHZks8JhjrahgfaJxnH480Hmn+OTK5d268wTRCY6VvoJXyH1E T8XRh8XG1OQd+D1zR8Zd+ykS8jBd+QCocWCtmo7AS1HCyiuJRIdgBLfc+7y9jAfYqUGp 8zbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768398229; x=1769003029; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=KQ36zvjxXpDCUHe0Pi5BKTF7mvA6vIQwzP/JbYlUIEI=; b=gAi6KZkVTsA+WnIv4alBEXrX7GKroRCHH6UExUamG2HasRGIL44Dw6SkhTDoIqiqcg pOB6fqHCEzwkgIXX7PrQSzUaIwlCOrjK13rU/0Su+cBOE1ghupo1UGtofE7hEFbOMcCC J1ozOBE46FYWPY7GS/i48Y9h27vFJzAyrQ8DLffvhXZSgjX3nqVq4X3VTnw5gMZucavk Tij+0JGwygXMHrkM9pRgjMuhYTsFJC8KmoZPU82ipG3oQPYpCXEzY14VwSLAIIZEHE2A 4rhYXmNb6xnAOUAanHgT0F93AHJI6k2c4BcZhqRBWJl9uUQtAGqfR/u7ZlEMe/Kr1D+O P0Rw== X-Gm-Message-State: AOJu0YwdU732uRs+vhbhb1ISFHV1rH4uVNp4+fQgYESfX1KUk/1MnYxf /ArZIA9WCxWEIRcsa1Z6lagu4qv9yIV/3q2Hj+gyY7PEhr/XTCBF1+Ef43mHRKFI8H6TKGveIL2 atYo= X-Gm-Gg: AY/fxX7P8/0407zQxTwMDlcRioiPK2dgJZ16kYZqP9D7gDRGRoohSbBIDNm6+IVTVux OgJDiMtk8tpqgJ94epaRZTwdfgTYwRxVsnplW0bkUEe6D6RPic86EI/t5lhtCyqChUt2sOEQUND nUlx7GTh+NZ6DS8+lMo7OPNmrmJ/41Yz9J4tBmSHLoIuhEeEukhWMQ3+Uxvk53uKpjTM6Wou4iU Qe7+lJK7RAnlEKDqYgALB2mS0QnWt7nMmjgoYThnoKSv6drnGZTBm5Dpt9J/lALcXXc3HklalER w/CkNGnNH3qDB2KqIUu6tumrpVTp3xgPYe3EucbtFAGxLBS+YLteYypYUkqnSEywEDFm4rZ4Lt6 23L4avGNHoafJ5e+4maETBmYD4eI5gD7mu/DgHWpncjW+fsVFxLhE4mR/qtApvNdCH9ICkJZLAN h9ZweDkNF4BH9g3JsJx40sdqGz4fB0ir06Ubu/Mzd4WKOhRSQT7tyE+Lyw0afXdcoZRRSXVChd3 gg= X-Received: by 2002:a05:600c:698c:b0:47e:dddc:3369 with SMTP id 5b1f17b1804b1-47ee339984cmr32093635e9.35.1768398229408; Wed, 14 Jan 2026 05:43:49 -0800 (PST) Message-ID: <29eb0997-bf74-4cde-ba7b-6977223c3829@suse.com> Date: Wed, 14 Jan 2026 14:43:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v3 2/6] x86: replace APERFMPERF synthetic feature bit From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <4d3a3576-2d3c-42ec-8551-18f1f0982e17@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: <4d3a3576-2d3c-42ec-8551-18f1f0982e17@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Use the respective host CPU policy bit instead. This has the (tolerable, as we generally assume symmetry anyway) effect of using the BSP's (unleveled) setting, rather than the result of leveling (as is done by identify_cpu() on boot_cpu_data, rendering the variable name somewhat misleading). Signed-off-by: Jan Beulich Reviewed-by: Jason Andryuk --- The leveling of boot_cpu_data is problematic anyway, as that way features can in principle disappear post-boot (as CPUs are being brought online; just that we don't think anymore that we really support physical CPU hotplug). --- v3: Re-base over naming changes. v2: Extend description. --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c @@ -80,7 +80,7 @@ unsigned int get_measured_perf(unsigned return 0; policy = per_cpu(cpufreq_cpu_policy, cpu); - if ( !policy || !cpu_has_aperfmperf ) + if ( !policy || !cpu_has_hw_feedback_cap ) return 0; switch (flag) --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -523,10 +523,6 @@ static void generic_identify(struct cpui if ( cpu_has(c, X86_FEATURE_CLFLUSH) ) c->x86_clflush_size = ((ebx >> 8) & 0xff) * 8; - if ( (c->cpuid_level >= CPUID_PM_LEAF) && - (cpuid_ecx(CPUID_PM_LEAF) & CPUID6_ECX_APERFMPERF_CAPABILITY) ) - __set_bit(X86_FEATURE_APERFMPERF, c->x86_capability); - /* AMD-defined flags: level 0x80000001 */ if (c->extended_cpuid_level >= 0x80000001) cpuid(0x80000001, &tmp, &tmp, --- a/xen/arch/x86/include/asm/cpufeature.h +++ b/xen/arch/x86/include/asm/cpufeature.h @@ -11,7 +11,9 @@ #include #ifndef __ASSEMBLER__ +#include #include +#include #else #include #endif @@ -121,7 +123,6 @@ static inline bool boot_cpu_has(unsigned #define CPUID6_EAX_HDC BIT(13, U) #define CPUID6_EAX_HWP_PECI BIT(16, U) #define CPUID6_EAX_HW_FEEDBACK BIT(19, U) -#define CPUID6_ECX_APERFMPERF_CAPABILITY BIT(0, U) /* CPUID level 0x00000001.edx */ #define cpu_has_fpu 1 @@ -175,6 +176,9 @@ static inline bool boot_cpu_has(unsigned #define cpu_has_fma4 boot_cpu_has(X86_FEATURE_FMA4) #define cpu_has_tbm boot_cpu_has(X86_FEATURE_TBM) +/* CPUID level 0x00000006.ecx */ +#define cpu_has_hw_feedback_cap host_cpu_policy.basic.hw_feedback_cap + /* CPUID level 0x0000000D:1.eax */ #define cpu_has_xsaveopt boot_cpu_has(X86_FEATURE_XSAVEOPT) #define cpu_has_xsavec boot_cpu_has(X86_FEATURE_XSAVEC) @@ -292,7 +296,6 @@ static inline bool boot_cpu_has(unsigned /* Synthesized. */ #define cpu_has_arch_perfmon boot_cpu_has(X86_FEATURE_ARCH_PERFMON) #define cpu_has_cpuid_faulting boot_cpu_has(X86_FEATURE_CPUID_FAULTING) -#define cpu_has_aperfmperf boot_cpu_has(X86_FEATURE_APERFMPERF) #define cpu_has_xen_lbr boot_cpu_has(X86_FEATURE_XEN_LBR) #define cpu_has_xen_shstk (IS_ENABLED(CONFIG_XEN_SHSTK) && \ boot_cpu_has(X86_FEATURE_XEN_SHSTK)) --- a/xen/arch/x86/include/asm/cpufeatures.h +++ b/xen/arch/x86/include/asm/cpufeatures.h @@ -19,7 +19,7 @@ XEN_CPUFEATURE(TSC_RELIABLE, X86_SY XEN_CPUFEATURE(XTOPOLOGY, X86_SYNTH( 5)) /* cpu topology enum extensions */ XEN_CPUFEATURE(CPUID_FAULTING, X86_SYNTH( 6)) /* cpuid faulting */ XEN_CPUFEATURE(XEN_FRED, X86_SYNTH( 7)) /* Xen uses FRED */ -XEN_CPUFEATURE(APERFMPERF, X86_SYNTH( 8)) /* APERFMPERF */ +/* Bit 8 unused */ XEN_CPUFEATURE(MFENCE_RDTSC, X86_SYNTH( 9)) /* MFENCE synchronizes RDTSC */ XEN_CPUFEATURE(XEN_SMEP, X86_SYNTH(10)) /* SMEP gets used by Xen itself */ XEN_CPUFEATURE(XEN_SMAP, X86_SYNTH(11)) /* SMAP gets used by Xen itself */ From xen-devel-bounces@lists.xenproject.org Wed Jan 14 13:44:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 13:44:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203114.1518409 (Exim 4.92) (envelope-from ) id 1vg1Al-0002vZ-Jb; Wed, 14 Jan 2026 13:44:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203114.1518409; Wed, 14 Jan 2026 13:44:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg1Al-0002vS-H7; Wed, 14 Jan 2026 13:44:31 +0000 Received: by outflank-mailman (input) for mailman id 1203114; Wed, 14 Jan 2026 13:44: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 1vg1Ak-0001vr-5Z for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 13:44:30 +0000 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [2a00:1450:4864:20::335]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 25ed765f-f14f-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 14:44:29 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-47775fb6cb4so48164515e9.0 for ; Wed, 14 Jan 2026 05:44:29 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee2840b7csm19538585e9.14.2026.01.14.05.44.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 05:44:28 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 25ed765f-f14f-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768398269; x=1769003069; 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=OMhFYAP0uDgitdjy3newUKs3PAfrZxLBZ1KDOJga+EI=; b=U/UtIQeH6aAFX4hC3pA0zQZyIGoyag/vbmKRG2IwPWLwQ/0pJvte7QU2twxt9Es2GS lLnSlmj165HiaT+FFFsvYfUz+Kp35pAuvSuMKOBSdlz28ctftygXz2PZMxlIJZE6QAY7 Nru6OW6DpSeq5m59HthDIHk61JstIwuqrx1plxQ62v6MMdB5vcKeaUf14zs0ZbFXGzh5 hQnNOyxcoPtOA2mnBts6wtfvtFRfBrK8+NWRb1ihKE2M8q6q92ljrj7+HxGiMBTuzk7m IhSLXixQqv4fjfOXaeYx2TuLqgU2LO+oUmq0/zdQIZ194yLp7PHfYLbVW+HZUqBillvY pDJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768398269; x=1769003069; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=OMhFYAP0uDgitdjy3newUKs3PAfrZxLBZ1KDOJga+EI=; b=FwCUfIIxegCveutiEwvI/S8YAwTryohKpoVbCbpBj+jCW9RrhGOex1hJXdOJniLIBX ny8th1yRchLxGmAUrBdR19b86eYTgU97/+aj1z0bHn5wR14ChFbocb/FAn3BnhXnuNPo nS/Kga43m9E6vRDVfovV1h7mmH7SInMGUwGx4BFcqoGLL/gioNJ1s0NyS88iGvBo93Cu aLhrS/DANkBx9tys0qKmKbed5Oy3px4YKKYn/KKIddpn1E7L0a/di3wm8Mpt68mDgrUR htEYtkvF7NL5UX66/3XDbU+w8IJW5U3azMiH8ZZ/Szq9jFMSovGKczU3rQSxFRDJ5t6f yAAg== X-Gm-Message-State: AOJu0YwIMDADAmFQrfH0HB/KKUBX59c20wGXSaSFHsoiq4CGN8vAean7 qm/6Y+ICx39+FSUrE0QOcht1oH8+9MzNERTlD+K3npQlgIIq8t9BwIXJ5L8e3sWIi38XlSf8rkN qMQQ= X-Gm-Gg: AY/fxX7wA4M36/ZZ26CFb9UTYa+UZTMeornYW1+LJhSIRrxx/Ap2X8sGVqkrmm8QIpR wp1v1nokodNZpiDMP/+/+GX9r3zpw1wjeWq68gteyKTNGo09xpdEcM4/Mso9rFiT/DaFOLn7IP0 Z1jLI28HiqPNa0hZUEOwJTAWHJcILEQ86UXY7cc2oo4dEeI4YhxFsmZMG9jy8IDmqvwBNMU6osh xwT70/P56YDwX4wrjJH+xBhpbmXRBMQeJ/yv2f7jnRsSMYwxPNH2rBsxSSjfJiKyZNV9mRvVtBI aKXZo1nTlez7hmvwAt2bqOzDGIHpFdLaTms89VaPCiviFmEos64+Dw6LVJoTrjaHrJoMH2oQpLJ +q4HmySAdeQDBaq7DHpzTvGuXTmXdx1txIEx2ftQ2+TRQau6g7sOtdsGSFBRxQbE954Fjwd9+9Y lZjtcaePU28WlGc8w1S3NQVrpS/7oefRPEyALsziIODRSKH590vjTZIM9oczIgnpyw+HOcnKx0y 30= X-Received: by 2002:a05:600c:8289:b0:47e:de23:dd6f with SMTP id 5b1f17b1804b1-47ee33441c9mr28442215e9.12.1768398268726; Wed, 14 Jan 2026 05:44:28 -0800 (PST) Message-ID: <9d7de9e6-11ef-4cd5-94e1-4c1829ea94a3@suse.com> Date: Wed, 14 Jan 2026 14:44:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v3 3/6] x86: rename ARAT feature flag From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <4d3a3576-2d3c-42ec-8551-18f1f0982e17@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: <4d3a3576-2d3c-42ec-8551-18f1f0982e17@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Add a XEN infix, to properly distinguish it from the CPUID feature flag (leaf 6 EAX bit 2). Signed-off-by: Jan Beulich Reviewed-by: Jason Andryuk --- Question is whether we still need opt_arat (and the command line option), or whether we could go directly from the CPUID bit (overriding it to 1 for older AMD [and Hygon?] CPUs). Or whether to have opt_arat affect the (host) CPU policy directly. --- a/xen/arch/x86/acpi/cpu_idle.c +++ b/xen/arch/x86/acpi/cpu_idle.c @@ -109,7 +109,7 @@ void (*__read_mostly lapic_timer_on)(voi bool lapic_timer_init(void) { - if ( boot_cpu_has(X86_FEATURE_ARAT) ) + if ( boot_cpu_has(X86_FEATURE_XEN_ARAT) ) { lapic_timer_off = lapic_timer_nop; lapic_timer_on = lapic_timer_nop; @@ -1463,7 +1463,7 @@ static void amd_cpuidle_init(struct acpi if ( !vendor_override ) { - if ( !boot_cpu_has(X86_FEATURE_ARAT) ) + if ( !boot_cpu_has(X86_FEATURE_XEN_ARAT) ) hpet_broadcast_init(); if ( !lapic_timer_init() ) --- a/xen/arch/x86/cpu/amd.c +++ b/xen/arch/x86/cpu/amd.c @@ -1239,7 +1239,7 @@ static void cf_check init_amd(struct cpu * running in deep C states. */ if ( opt_arat && c->x86 > 0x11 ) - __set_bit(X86_FEATURE_ARAT, c->x86_capability); + __set_bit(X86_FEATURE_XEN_ARAT, c->x86_capability); /* * Prior to Family 0x14, perf counters are not reset during warm reboot. --- a/xen/arch/x86/cpu/hygon.c +++ b/xen/arch/x86/cpu/hygon.c @@ -81,7 +81,7 @@ static void cf_check init_hygon(struct c /* Hygon processors have APIC timer running in deep C states. */ if (opt_arat) - __set_bit(X86_FEATURE_ARAT, c->x86_capability); + __set_bit(X86_FEATURE_XEN_ARAT, c->x86_capability); if (cpu_has(c, X86_FEATURE_EFRO)) { rdmsrl(MSR_K8_HWCR, value); --- a/xen/arch/x86/cpu/intel.c +++ b/xen/arch/x86/cpu/intel.c @@ -668,7 +668,7 @@ static void cf_check init_intel(struct c if ( opt_arat && ( c->cpuid_level >= 0x00000006 ) && ( cpuid_eax(0x00000006) & (1u<<2) ) ) - __set_bit(X86_FEATURE_ARAT, c->x86_capability); + __set_bit(X86_FEATURE_XEN_ARAT, c->x86_capability); if ((opt_cpu_info && !(c->apicid & (c->x86_num_siblings - 1))) || c == &boot_cpu_data ) --- a/xen/arch/x86/cpu/mwait-idle.c +++ b/xen/arch/x86/cpu/mwait-idle.c @@ -1633,7 +1633,7 @@ static int __init mwait_idle_probe(void) icpu = id->driver_data; cpuidle_state_table = icpu->state_table; - if (boot_cpu_has(X86_FEATURE_ARAT)) + if (boot_cpu_has(X86_FEATURE_XEN_ARAT)) lapic_timer_reliable_states = LAPIC_TIMER_ALWAYS_RELIABLE; pr_debug(PREFIX "v" MWAIT_IDLE_VERSION " model %#x\n", @@ -1792,7 +1792,7 @@ int __init mwait_idle_init(struct notifi return -ENODEV; err = mwait_idle_probe(); - if (!err && !boot_cpu_has(X86_FEATURE_ARAT)) { + if (!err && !boot_cpu_has(X86_FEATURE_XEN_ARAT)) { hpet_broadcast_init(); if (xen_cpuidle < 0 && !hpet_broadcast_is_available()) err = -ENODEV; --- a/xen/arch/x86/include/asm/cpufeatures.h +++ b/xen/arch/x86/include/asm/cpufeatures.h @@ -13,7 +13,7 @@ /* Synthetic features */ XEN_CPUFEATURE(CONSTANT_TSC, X86_SYNTH( 0)) /* TSC ticks at a constant rate */ XEN_CPUFEATURE(NONSTOP_TSC, X86_SYNTH( 1)) /* TSC does not stop in C states */ -XEN_CPUFEATURE(ARAT, X86_SYNTH( 2)) /* Always running APIC timer */ +XEN_CPUFEATURE(XEN_ARAT, X86_SYNTH( 2)) /* Xen may utilize always running APIC timer */ XEN_CPUFEATURE(ARCH_PERFMON, X86_SYNTH( 3)) /* Intel Architectural PerfMon */ XEN_CPUFEATURE(TSC_RELIABLE, X86_SYNTH( 4)) /* TSC is known to be reliable */ XEN_CPUFEATURE(XTOPOLOGY, X86_SYNTH( 5)) /* cpu topology enum extensions */ --- a/xen/arch/x86/time.c +++ b/xen/arch/x86/time.c @@ -2644,7 +2644,7 @@ static int _disable_pit_irq(bool init) * XXX dom0 may rely on RTC interrupt delivery, so only enable * hpet_broadcast if FSB mode available or if force_hpet_broadcast. */ - if ( cpuidle_using_deep_cstate() && !boot_cpu_has(X86_FEATURE_ARAT) ) + if ( cpuidle_using_deep_cstate() && !boot_cpu_has(X86_FEATURE_XEN_ARAT) ) { init ? hpet_broadcast_init() : hpet_broadcast_resume(); if ( !hpet_broadcast_is_available() ) From xen-devel-bounces@lists.xenproject.org Wed Jan 14 13:45:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 13:45:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203126.1518419 (Exim 4.92) (envelope-from ) id 1vg1Bp-0003YL-1L; Wed, 14 Jan 2026 13:45:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203126.1518419; Wed, 14 Jan 2026 13:45:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg1Bo-0003YE-Um; Wed, 14 Jan 2026 13:45:36 +0000 Received: by outflank-mailman (input) for mailman id 1203126; Wed, 14 Jan 2026 13:45:35 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg1Bn-0003Y4-TB for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 13:45:35 +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 4c6afde3-f14f-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 14:45:33 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-47ee4539adfso7440755e9.3 for ; Wed, 14 Jan 2026 05:45:33 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee2814548sm20222905e9.9.2026.01.14.05.45.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 05:45:32 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4c6afde3-f14f-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768398333; x=1769003133; 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=yMOMn2HwlqhXC4/C9EIMmJoujrYjFnjM4Ioz872BrNM=; b=FehmLS4bUEtjgH9gNEodwVnD+ZwOuik0nbgU3RVWgNwpRgerkEW0YOwdSfA6iiv8+1 aqkjB8HO+yjB5v6t/gA0CbmCmkgHGZ9ssxIvoHm6UlT8lVKwI4MdUSjg/rQ9ZASGznHv C+iLRM+CdhJzEx98YFtU+VFRExSnUSmeO0lOkagBTGzuEFaJXubqsMgrtuVhI5zhZC/T Kbo8GP6bvNummto1+Eu+5q9kpyfZvhVe6NJJYMqUP/iaeBBpxBY1URnRcejHNB+bwwP3 S94aTwj17Pzb6Yw+0eNbI0VjPyQmvhdM5CZohEuugrWzocZkQb2U95GqzqpyP78GIEw1 LEzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768398333; x=1769003133; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yMOMn2HwlqhXC4/C9EIMmJoujrYjFnjM4Ioz872BrNM=; b=gsMewopM9RjPpZdCwgg7R/rFc+jFlETyejkA6ixQ3MBgoxS7uD/EGfuaq7HOjt9W3Y B7R5YMQf7lrIf/WAq9bUbGw+0l76zATIxbnnjyO4a/4xS2NT99RYpYbihevctgeobAOx jyKIsoXP22LbLga+V4/7HIwjfW7DJS5jOuzykLOccW4VUfjnOXnwYUwnliypGpruYyJp gYbVsfU5hvSF8hMC8f7zHgccElqBemPXbSCgnO5Hu4tsuKLxpi77ljJ0mtSerl5NVo3A T6YcGFSGMWZFENVcpL38JPsp1k+4jkafyGcXKpSJlGUtqJAvLynhQLPbR/7l6x/RgwPy e/mw== X-Gm-Message-State: AOJu0YxNKEI3c9uXJxoCKkUras1r7YodqfASyH+UIujMJBEm/htXhhJt nzLcVYjBrrBHLul2X8hyrqFWn2Np0Mofwdmx1XJMEDk2MEPS40UDxPT2ubIkEu9uWROgUnHNbOP Pgug= X-Gm-Gg: AY/fxX4HeQxukKLnbSwZs4CW3PKQpvGCr5kmnqzW/ZrK7QxGE7rsRxd7iA9ZDf0o8/1 IxoH5FIM4hzi3aseNfAywhmgCF2aDuFpKipHmB6EM3TCg1EeufMz6kBaIWMtYFTNShSIcS0u4Ca HFrKr7cNHoO8rMcz3ElD6rcTwhr2Hmwaz757hrydjt3ikGpY/zYGlucXUiVzC+prxuC4YK0xug1 ob6WQsKpl9nrz57gYwZ2Hym8JGE3Dp5Hv5VakMmArqJhAdBpD23Z+eWzXcYLDbEP12Dx8gNKsZ9 blcC7L/0bQ4o17X9m4aMGvWjfsVGro4/gOGqYCr2VQPkN0I/LGIg5VorkP3cuLg47e7ZCvwFY+o 0J7knpH2Y5hCuo5C3WFoyGie0oE5ucUNsl9L+uqahpJ5FRVvedWj6kBMquiZ+bW4CVTP25VgfQ0 z4JkkB7AxFXqj6+Iwlz+JDe1bSY7YdMWpdDVd6DQzpxdlXn4iJ2Bu6IK3N8AykWzbF6qYB6twli j8/AR2ZtUJHaw== X-Received: by 2002:a05:600c:a51:b0:477:7bca:8b34 with SMTP id 5b1f17b1804b1-47ee32e5cd3mr34451775e9.6.1768398333076; Wed, 14 Jan 2026 05:45:33 -0800 (PST) Message-ID: Date: Wed, 14 Jan 2026 14:45:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v3 5/6] x86/cpufreq: use host CPU policy for Turbo checking From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <4d3a3576-2d3c-42ec-8551-18f1f0982e17@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: <4d3a3576-2d3c-42ec-8551-18f1f0982e17@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit There's no need to invoke CPUID yet another time - we assume symmetry anyway. With symmetry assumed, logging per-CPU also isn't very useful. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper Reviewed-by: Jason Andryuk --- v3: Re-base over naming changes. --- a/xen/arch/x86/acpi/cpufreq/acpi.c +++ b/xen/arch/x86/acpi/cpufreq/acpi.c @@ -220,14 +220,11 @@ static unsigned int cf_check get_cur_fre void intel_feature_detect(struct cpufreq_policy *policy) { - unsigned int eax; - - eax = cpuid_eax(6); - if (eax & 0x2) { + if ( cpu_has_turbo_boost ) + { policy->turbo = CPUFREQ_TURBO_ENABLED; - if (cpufreq_verbose) - printk(XENLOG_INFO "CPU%u: Turbo Mode detected and enabled\n", - smp_processor_id()); + if ( cpufreq_verbose ) + printk_once(XENLOG_INFO "Turbo Mode detected and enabled\n"); } } --- a/xen/arch/x86/include/asm/cpufeature.h +++ b/xen/arch/x86/include/asm/cpufeature.h @@ -177,6 +177,7 @@ static inline bool boot_cpu_has(unsigned #define cpu_has_tbm boot_cpu_has(X86_FEATURE_TBM) /* CPUID level 0x00000006.eax */ +#define cpu_has_turbo_boost host_cpu_policy.basic.turbo_boost #define cpu_has_arat host_cpu_policy.basic.arat /* CPUID level 0x00000006.ecx */ From xen-devel-bounces@lists.xenproject.org Wed Jan 14 13:45:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 13:45:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203130.1518430 (Exim 4.92) (envelope-from ) id 1vg1C7-0003vB-87; Wed, 14 Jan 2026 13:45:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203130.1518430; Wed, 14 Jan 2026 13:45: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 1vg1C7-0003v4-5J; Wed, 14 Jan 2026 13:45:55 +0000 Received: by outflank-mailman (input) for mailman id 1203130; Wed, 14 Jan 2026 13: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 1vg1C5-0003Y4-H7 for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 13:45:53 +0000 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [2a00:1450:4864:20::330]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 573dba35-f14f-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 14:45:51 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-47d5e021a53so65472905e9.3 for ; Wed, 14 Jan 2026 05:45:51 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee578d12fsm29552315e9.3.2026.01.14.05.45.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 05:45:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 573dba35-f14f-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768398351; x=1769003151; 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=of3ZVzYQS2KutMf+Jt2/4ruObRoSOuVu1pCONx6TmkE=; b=Slw/0h70M85bzja7GTIVRNiN6bIjcYjrlJsCJJk/n7Kdf64HSYH2VOVeAzuRo1D9ev xc+YVI1NlTNGnYe4euRRG417IKoG0Y/zcJe4lPUvkbhcFB27Q1/rLaKbs6MtIXAkJv+k Pgh1wr9K1dSppKrTy2ECsompahoniLMmPrj95Y3f/T9RXpYUucs3AgH9bdw9m63rnwha zT/3V2tgIXxK6U0fZ0+7CkkBzZT8ZU8btmP04kYJmUvEnk/c7BMFoD5oYuKcmUbUKflI CKkn2I5+R3wkfs/IaOB3KdqSkxvyhxmDiXysncbQ+0OMAy5h/M92hS3lnROqZBvPI1/7 c3Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768398351; x=1769003151; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=of3ZVzYQS2KutMf+Jt2/4ruObRoSOuVu1pCONx6TmkE=; b=l0ndaU+k/YM+E8tm5dwGsM/I3RjJdliCkpnGwXAi/CQzZOOsRfsQ2HhoHbBYWBbJlO 0QnCuOlUYZc1tirqUCJpWC1y3GavSOrHILuqF2mVApwShFJJmKsnb5xzbFo/O8sgJaqk jtbilnEFzBBhd8AmnMACj0/yGN2fYdMLUfGd+GNZltVX5Lx01TGsN8PkQadazrJl1oOR mAG6UkjYexBF6Q6MaLf+s++r0z8z9rMHgGy9xjPbk4vm6z3WygK+oI/8aIUm4xwkpX8u +MhfsT8S+RIYEKAMOu8Zfmufnwz7oMh0SlLH2KzVV01zLisSdfau1CwOY0OlIZKIfi3Y wSxQ== X-Gm-Message-State: AOJu0Yzk0tGqMuj8oFacrIh62jS/2cFqK5hpYwpjeSM6fKwgaqjDAjij K3a2A0PZxmElbYv6Yf9QJLkLafDJaHaD6oRUzs7UxOKsLK80N9ixwUrGRdX9g6aS19nbtxEFT/m PrLw= X-Gm-Gg: AY/fxX6Uz7W7/KvuE6iUI+qpr+pwfQF0/6DYiSF2iul7B80OGXyDkb4QBSTNVI8xur9 2UkAQfX23cmtyRnAUvO3B21Y/g9CxHMM9/RQ49NI5bX1RG4UZ4ydwpOce9fZWxb5eFms5M15HZX sSxwSLIblcxW9z95HaOf5JdVHzmPS8CA7xUOE1iZrORHUVPuZ8bu+W7kgzG4NL/EXdJFO7XiNn+ Bf4RHNPhpf5CJsM87MbtutGOKAk/wKTdDwB0gU8FY9y5HD4JelS+tMDxWZB5GPBuF1Ta/4ahs2Z 58ndIpbe1VqXZrTyzQue+6c+a389dbdMPooP4Vux6gLlgbLTaOZJD1lNUQkslSnnE3pC+TdvIzb Gj1G0Kcmj6xhps6ONED//IwJZAkN6F2JdG44jXiLSm2LS4NUglm4IDz2AgicNjLqBZtBwqXFZsn 6xX0sKYGMu5dNlxHS101wWb5mrVxEQTTwj1EdIpwDkEcbxdDPcxaM4PUwGRvgH/jlrlD9cyNDV5 CDl8bZD2UMMdg== X-Received: by 2002:a05:600c:4f0b:b0:477:9392:8557 with SMTP id 5b1f17b1804b1-47ee4819824mr24243505e9.18.1768398351202; Wed, 14 Jan 2026 05:45:51 -0800 (PST) Message-ID: <7d52c0cf-c097-4c32-9af6-5044727c3ef8@suse.com> Date: Wed, 14 Jan 2026 14:45:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v3 6/6] x86/cpufreq: use host CPU policy in HWP driver From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <4d3a3576-2d3c-42ec-8551-18f1f0982e17@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: <4d3a3576-2d3c-42ec-8551-18f1f0982e17@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit There's no need to invoke CPUID yet another time. This way two of the static booleans can also go away. Signed-off-by: Jan Beulich --- v3: Undo some line wrapping. Correct padding in asm/cpufeature.h. Re-base over naming changes. v2: Introduce cpu_has_*. --- a/xen/arch/x86/acpi/cpufreq/hwp.c +++ b/xen/arch/x86/acpi/cpufreq/hwp.c @@ -18,9 +18,6 @@ static bool __ro_after_init hwp_in_use; -static bool __ro_after_init feature_hwp_notification; -static bool __ro_after_init feature_hwp_activity_window; - static bool __read_mostly feature_hdc; static bool __ro_after_init opt_cpufreq_hdc = true; @@ -165,8 +162,6 @@ bool hwp_active(void) static bool __init hwp_available(void) { - unsigned int eax; - if ( boot_cpu_data.cpuid_level < CPUID_PM_LEAF ) { hwp_verbose("cpuid_level (%#x) lacks HWP support\n", @@ -183,29 +178,22 @@ static bool __init hwp_available(void) return false; } - eax = cpuid_eax(CPUID_PM_LEAF); - hwp_verbose("%d notify: %d act-window: %d energy-perf: %d pkg-level: %d peci: %d\n", - !!(eax & CPUID6_EAX_HWP), - !!(eax & CPUID6_EAX_HWP_NOTIFICATION), - !!(eax & CPUID6_EAX_HWP_ACTIVITY_WINDOW), - !!(eax & CPUID6_EAX_HWP_ENERGY_PERFORMANCE_PREFERENCE), - !!(eax & CPUID6_EAX_HWP_PACKAGE_LEVEL_REQUEST), - !!(eax & CPUID6_EAX_HWP_PECI)); + cpu_has_hwp, cpu_has_hwp_interrupt, + cpu_has_hwp_activity_window, cpu_has_hwp_epp, + cpu_has_hwp_request_pkg, cpu_has_hwp_peci_override); - if ( !(eax & CPUID6_EAX_HWP) ) + if ( !cpu_has_hwp ) return false; - if ( !(eax & CPUID6_EAX_HWP_ENERGY_PERFORMANCE_PREFERENCE) ) + if ( !cpu_has_hwp_epp ) { hwp_verbose("disabled: No energy/performance preference available"); return false; } - feature_hwp_notification = eax & CPUID6_EAX_HWP_NOTIFICATION; - feature_hwp_activity_window = eax & CPUID6_EAX_HWP_ACTIVITY_WINDOW; - feature_hdc = eax & CPUID6_EAX_HDC; + feature_hdc = cpu_has_hdc; hwp_verbose("Hardware Duty Cycling (HDC) %ssupported%s\n", feature_hdc ? "" : "not ", @@ -213,7 +201,7 @@ static bool __init hwp_available(void) : ""); hwp_verbose("HW_FEEDBACK %ssupported\n", - (eax & CPUID6_EAX_HW_FEEDBACK) ? "" : "not "); + cpu_has_hw_feedback ? "" : "not "); hwp_in_use = true; @@ -226,7 +214,7 @@ static int cf_check hwp_cpufreq_verify(s { struct hwp_drv_data *data = per_cpu(hwp_drv_data, policy->cpu); - if ( !feature_hwp_activity_window && data->activity_window ) + if ( !cpu_has_hwp_activity_window && data->activity_window ) { hwp_verbose("HWP activity window not supported\n"); @@ -268,7 +256,7 @@ static int cf_check hwp_cpufreq_target(s hwp_req.max_perf = data->maximum; hwp_req.desired = data->desired; hwp_req.energy_perf = data->energy_perf; - if ( feature_hwp_activity_window ) + if ( cpu_has_hwp_activity_window ) hwp_req.activity_window = data->activity_window; if ( hwp_req.raw == data->curr_req.raw ) @@ -365,7 +353,7 @@ static void cf_check hwp_init_msrs(void } /* Ensure we don't generate interrupts */ - if ( feature_hwp_notification ) + if ( cpu_has_hwp_interrupt ) wrmsr_safe(MSR_HWP_INTERRUPT, 0); if ( !(val & PM_ENABLE_HWP_ENABLE) ) @@ -537,7 +525,7 @@ int get_hwp_para(unsigned int cpu, return -ENODATA; cppc_para->features = - (feature_hwp_activity_window ? XEN_SYSCTL_CPPC_FEAT_ACT_WINDOW : 0); + (cpu_has_hwp_activity_window ? XEN_SYSCTL_CPPC_FEAT_ACT_WINDOW : 0); cppc_para->lowest = data->hw.lowest; cppc_para->lowest_nonlinear = data->hw.most_efficient; cppc_para->nominal = data->hw.guaranteed; @@ -585,7 +573,7 @@ int set_hwp_para(struct cpufreq_policy * /* Clear out activity window if lacking HW supported. */ if ( (set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ACT_WINDOW) && - !feature_hwp_activity_window ) + !cpu_has_hwp_activity_window ) { set_cppc->set_params &= ~XEN_SYSCTL_CPPC_SET_ACT_WINDOW; cleared_act_window = true; --- a/xen/arch/x86/include/asm/cpufeature.h +++ b/xen/arch/x86/include/asm/cpufeature.h @@ -115,14 +115,6 @@ static inline bool boot_cpu_has(unsigned } #define CPUID_PM_LEAF 6 -#define CPUID6_EAX_HWP BIT(7, U) -#define CPUID6_EAX_HWP_NOTIFICATION BIT(8, U) -#define CPUID6_EAX_HWP_ACTIVITY_WINDOW BIT(9, U) -#define CPUID6_EAX_HWP_ENERGY_PERFORMANCE_PREFERENCE BIT(10, U) -#define CPUID6_EAX_HWP_PACKAGE_LEVEL_REQUEST BIT(11, U) -#define CPUID6_EAX_HDC BIT(13, U) -#define CPUID6_EAX_HWP_PECI BIT(16, U) -#define CPUID6_EAX_HW_FEEDBACK BIT(19, U) /* CPUID level 0x00000001.edx */ #define cpu_has_fpu 1 @@ -179,6 +171,14 @@ static inline bool boot_cpu_has(unsigned /* CPUID level 0x00000006.eax */ #define cpu_has_turbo_boost host_cpu_policy.basic.turbo_boost #define cpu_has_arat host_cpu_policy.basic.arat +#define cpu_has_hwp host_cpu_policy.basic.hwp +#define cpu_has_hwp_interrupt host_cpu_policy.basic.hwp_interrupt +#define cpu_has_hwp_activity_window host_cpu_policy.basic.hwp_activity_window +#define cpu_has_hwp_epp host_cpu_policy.basic.hwp_epp +#define cpu_has_hwp_request_pkg host_cpu_policy.basic.hwp_request_pkg +#define cpu_has_hdc host_cpu_policy.basic.hdc +#define cpu_has_hwp_peci_override host_cpu_policy.basic.hwp_peci_override +#define cpu_has_hw_feedback host_cpu_policy.basic.hw_feedback /* CPUID level 0x00000006.ecx */ #define cpu_has_hw_feedback_cap host_cpu_policy.basic.hw_feedback_cap From xen-devel-bounces@lists.xenproject.org Wed Jan 14 13:47:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 13:47:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203141.1518440 (Exim 4.92) (envelope-from ) id 1vg1DV-0004fB-J9; Wed, 14 Jan 2026 13:47:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203141.1518440; Wed, 14 Jan 2026 13:47:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg1DV-0004f1-FL; Wed, 14 Jan 2026 13:47:21 +0000 Received: by outflank-mailman (input) for mailman id 1203141; Wed, 14 Jan 2026 13:47: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 1vg1BV-0001vr-Qe for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 13:45:17 +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 42529160-f14f-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 14:45:16 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-47ee301a06aso8479145e9.0 for ; Wed, 14 Jan 2026 05:45:17 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee119aa2asm22125615e9.4.2026.01.14.05.45.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 05:45:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 42529160-f14f-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768398316; x=1769003116; 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=ShrMN6y1f3Pp4MjOmW8owsNUITc4IfDLUGq6mur2Md0=; b=WRUsMAEQ24+uZq5stpEjAJLj4Zy4PImKVyFloe2w+43veGxlyNenK/iSAylovGiztr bQfQMF1FQ1ESONm+7Hn0vFkgHZG6iD6v03p2ZDY52rKd1ytrBi0D/5Upb89Bvtd71dLF FrfFNjjgBjymGWwRB9gktmEmsz3oeTr++t1m2+hn1BuxMsR5Xv2R8B2Su4YV/fmw2YGv TBoLPddK1++nTiNN1k6iUkDbNaLcW3d+t9r5ySSD1P+301P+I98AkudIe0HrZlE4dYVw EPuD6ZIPLoFG776DmWwkgKI3zvt1TraES2dgtSA+CtuJO/6aocSZEkMKLbDj3TetCC7M i38g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768398316; x=1769003116; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ShrMN6y1f3Pp4MjOmW8owsNUITc4IfDLUGq6mur2Md0=; b=cuF5XHnd7accBGArKNilQg7yLKfVywetaaIaTuKkLTsTHSPY6GW81b7HcZG2mHML5G CQSLBPko4FYLxdmF6Wrz87gXWolNe526Tt0FkLK/2IjflRIu2G9XEcbjb96y07BM1EBj xxRA2o5QuVWh7cWIh9+wSIb25CbR93W3acw5MK/4wFvDPKW4Ap/QgpSzCPbl+TO4fvmM EvMdVfDV5Dp4eTQtTNpvnrmw/Hl/4oHB1Q2WGANAIKz97kzKxOPn0T3m8mWVD49qEbnQ rqEPWG7bpxX/bZz/aN/F7xN7vGpAPpl/fpqR1ss1atIx+QPa2TXaDnpqFinJnI3mVhM4 g9jw== X-Gm-Message-State: AOJu0Ywq1TtT7bOYMtZWnG59qLrRCuA45VC8FX8LNXu31PYJxnqB+LhB aJrt9Qm4qknZZvrNACNRpokVUi4bYMvhFVN2R1HOL2XSMJbQ3ISYvX/xmaT1qkXGo5TFOB0ZBlZ dA6Q= X-Gm-Gg: AY/fxX69gz/xiLn/G8uenB/Nn2jIsSNEn+pZUFpqCAv2EhlrVssrS3aEL1GIDunzhzs V3XE+nuNPFVmkx0TlhtrGlGPN07QIFfHVGUIjcWZ1PFxqgUDXypNblpz1b3is58/QLzf+rkEG0G ZHk8cvlnjF16SL1tLhclY6tb2oJn2N7ljAW6BNEoWb/MOOtWAPz8n5moRsSaUAfpelzshLJCHHP IcfgZQZputUBma98ldtQF+oGT2xhZgKrFAqI1BYBsd5Vs18XIIrGr87gArDKB4ATDwTFDcIYkbz MCnSuOIkqHDLogoYyUi3Df43C4t+dLIbi2apLO2Xe6HrQRmW2VlRxAVjtamH4agqR+9FeobZ1d6 89dVf1OZcSbswEGsjmNHwkhSIw72R0+LMSHKdgmX1l2ev+i7pcuIAAsZcELzTAkbaFT7E4qeChL u/NLpRUo6OyX47QtB1cbd98p9kowWKsiuzRUhbWQdZvojzamf2v3wlRjxAKGKxdOye/b0Ek5yJp xdpE9PIwVjxng== X-Received: by 2002:a05:600c:c8d:b0:46e:59bd:f7d3 with SMTP id 5b1f17b1804b1-47ee33768c9mr30700245e9.20.1768398316425; Wed, 14 Jan 2026 05:45:16 -0800 (PST) Message-ID: Date: Wed, 14 Jan 2026 14:45:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v3 4/6] x86/Intel: use host CPU policy for ARAT checking From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <4d3a3576-2d3c-42ec-8551-18f1f0982e17@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: <4d3a3576-2d3c-42ec-8551-18f1f0982e17@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit There's no need to invoke CPUID yet another time. However, as the host CPU policy is set up only shortly after init_intel() ran on the BSP, defer the logic to a pre-SMP initcall. This can't be (a new) one in cpu/intel.c though, as that's linked after acpi/cpu_idle.c (which is where we already need the feature set). Since opt_arat is local to the cpu/ subtree, introduce a new Intel-specific helper to hold the code needed. Further, as we assume symmetry anyway, use setup_force_cpu_cap() and hence limit the checking to the boot CPU. Signed-off-by: Jan Beulich Reviewed-by: Jason Andryuk --- The need to move where cpu_has_arat is checked would go away if we did away with opt_arat (as mentioned in the previous patch), and hence could use cpu_has_arat directly where right now XEN_ARAT is checked. --- v3: Re-base over naming changes. --- a/xen/arch/x86/acpi/cpu_idle.c +++ b/xen/arch/x86/acpi/cpu_idle.c @@ -1666,6 +1666,9 @@ static int __init cf_check cpuidle_presm { void *cpu = (void *)(long)smp_processor_id(); + if ( boot_cpu_data.vendor == X86_VENDOR_INTEL ) + intel_init_arat(); + if ( !xen_cpuidle ) return 0; --- a/xen/arch/x86/cpu/intel.c +++ b/xen/arch/x86/cpu/intel.c @@ -665,10 +665,6 @@ static void cf_check init_intel(struct c __set_bit(X86_FEATURE_NONSTOP_TSC, c->x86_capability); __set_bit(X86_FEATURE_TSC_RELIABLE, c->x86_capability); } - if ( opt_arat && - ( c->cpuid_level >= 0x00000006 ) && - ( cpuid_eax(0x00000006) & (1u<<2) ) ) - __set_bit(X86_FEATURE_XEN_ARAT, c->x86_capability); if ((opt_cpu_info && !(c->apicid & (c->x86_num_siblings - 1))) || c == &boot_cpu_data ) @@ -693,3 +689,9 @@ const struct cpu_dev __initconst_cf_clob .c_early_init = early_init_intel, .c_init = init_intel, }; + +void __init intel_init_arat(void) +{ + if ( opt_arat && cpu_has_arat ) + setup_force_cpu_cap(X86_FEATURE_XEN_ARAT); +} --- a/xen/arch/x86/include/asm/cpufeature.h +++ b/xen/arch/x86/include/asm/cpufeature.h @@ -176,6 +176,9 @@ static inline bool boot_cpu_has(unsigned #define cpu_has_fma4 boot_cpu_has(X86_FEATURE_FMA4) #define cpu_has_tbm boot_cpu_has(X86_FEATURE_TBM) +/* CPUID level 0x00000006.eax */ +#define cpu_has_arat host_cpu_policy.basic.arat + /* CPUID level 0x00000006.ecx */ #define cpu_has_hw_feedback_cap host_cpu_policy.basic.hw_feedback_cap --- a/xen/arch/x86/include/asm/processor.h +++ b/xen/arch/x86/include/asm/processor.h @@ -102,6 +102,7 @@ extern void setup_force_cpu_cap(unsigned extern bool is_forced_cpu_cap(unsigned int cap); extern void print_cpu_info(unsigned int cpu); extern void init_intel_cacheinfo(struct cpuinfo_x86 *c); +extern void intel_init_arat(void); #define cpu_to_core(_cpu) (cpu_data[_cpu].cpu_core_id) #define cpu_to_socket(_cpu) (cpu_data[_cpu].phys_proc_id) From xen-devel-bounces@lists.xenproject.org Wed Jan 14 14:03:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 14:03:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203176.1518450 (Exim 4.92) (envelope-from ) id 1vg1T8-0007qh-SK; Wed, 14 Jan 2026 14:03:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203176.1518450; Wed, 14 Jan 2026 14: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 1vg1T8-0007qa-PO; Wed, 14 Jan 2026 14:03:30 +0000 Received: by outflank-mailman (input) for mailman id 1203176; Wed, 14 Jan 2026 14:03: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 1vg1T7-0007qU-D1 for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 14:03:29 +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 cb789862-f151-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 15:03:26 +0100 (CET) Received: by mail-wr1-x442.google.com with SMTP id ffacd0b85a97d-42fbc3056afso5110931f8f.2 for ; Wed, 14 Jan 2026 06:03:26 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0dacc5sm50125688f8f.5.2026.01.14.06.03.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 06:03:24 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cb789862-f151-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768399405; x=1769004205; 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=uDgFbJTg+T7n3yCT1y6vxNtm9qhtDEu+7IPLP3E06qI=; b=Uy6896eBhIhaDOMoYhLytsXXiA39LkZPWyyiNXOKwGf0EpfY3uUw046M2J1YLJHmzI DlUZcbASQpxv9jDybRbU5FEiK2tIbKUY+IM1bRzZtxT3DstVMOUsKVS/QajXTH3aAGSu BVVBM+nSE3G7fE+DQ6k8wr5T6OYA9aLKMYHZ9X2TGW8s8CT/KqB8tH+HzwodRCfp6Vyv WsMQxQQ/AFPeLth3yZ7hnc2xVP6ycA6U3ayXsk9IbOIQW1eqVbdahrML3pOxZM9Lphz1 W2YsrfcpYRhThEq8zlVFd8g1l3F2P0GgGYjZK8WnGc7KeSHi5qU+H0TxqMz4Csr8JpfK shJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768399405; x=1769004205; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uDgFbJTg+T7n3yCT1y6vxNtm9qhtDEu+7IPLP3E06qI=; b=H+DXu0h3hqIMXS9Du8CInumdQIkrO2pItiQ86vS0bT+3Y2/nEAFldfR8clvrcUK3b9 kKAanei9FSD2eKJzTvdcEX5DU1Ni767gRHwmRjm+Mr4AU4s+SbOM6s4AiZN6y9qXvnEm QuaMIj0sjaTEeXpqMW6hVTCxCugCk76QUWEq8RuoITNdOT9LNUS34+pDrokhHz7HIXxG kw5TTn3AnwEtWOt1fmtOIde70dlSeSDPmKoO+e8WaZ/7NweMcwlMJCMHN3RrLNZURr3T xhvBoGatdBPA2eZN7bIPDPnl4y+EUns54knmKLmk1MLgnlNFpQPVBz99zz0P8JZk8UUw ChgQ== X-Gm-Message-State: AOJu0YzRRg5rnFJh6BULF4T6UHJhJKkPPpa3VxqTBqeKOahkp6mqln4g k4tuF6wr6vF/74XJD/+8n35wpCKpKnHTlYl8TEAJPRuYAWOm06UwJ/3hM/nxxodrGlVgm4zir8o 1YIA= X-Gm-Gg: AY/fxX7EO17KXx2+z7JVHvfU+7C4EAWoCSAAXz5m4+9eP4BokQFV4KVDCwBOtaNZ873 HuTZV3L0GQK8R5S42NawkTg68zNE3S4Q2pGE4YAPk0PErhnE1Vc7PQPLM+VYSk8Igs5RKcMrD1p +NoiNzMdC7enq1mmyoBNmqe+w4JoP3nhcms44S36JngMmWsyWfEwTQEROegzE7KyWMZ9eTFzMFI kv9TLutQ+1XQ0cnHK1sDtJHP5gygyKe+fM7x/bzGcdjrq+cvdknDqbMd3CWKRJEexNmuS0uEq6A sSUr5h9uz7dCAj8dpndGIrDJWCczF+u0aycmPM9MOr0ToWSJOIB6c8KGR7ShJt1fLTDWS4Xd0hm G40ITHyY27PUR1EGvNGbwEM3/qcDWeBVizGZIWfCJAEn6/dDdLJnL1EDarHXfxoX36aPGZ1I2Do mv2BBNMh92G+LjS0Q/xk/oAsbVtrdjan7Gn+lPHh460Oa6I3WaPvBzGCEVW4E3V/BuflEIDbdaE b4= X-Received: by 2002:a5d:584e:0:b0:432:4c01:db00 with SMTP id ffacd0b85a97d-4342c504ff2mr3629568f8f.27.1768399405467; Wed, 14 Jan 2026 06:03:25 -0800 (PST) Message-ID: Date: Wed, 14 Jan 2026 15:03:24 +0100 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?= , Juergen Gross From: Jan Beulich Subject: [PATCH] build: avoid Paths.mk in hypervisor build Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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 Its inclusion placed where it is, it affects the hypervisor build as well. The hypervisor build, in its _install rule, uses $(DEBUG_DIR), first in [ -d "$(D)$(DEBUG_DIR)" ] || $(INSTALL_DIR) $(D)$(DEBUG_DIR) $(D) is an absolute directory (shorthand for $(DESTDIR)). $(DEBUG_DIR) as set by Paths.mk is, too. Both point into the build tree. The two simply shouldn't be glued together. Note that the earlier [ -d $(D)$(BOOT_DIR) ] || $(INSTALL_DIR) $(D)$(BOOT_DIR) continues to be working fine, as BOOT_DIR continues to be controlled by config/StdGNU.mk. Its DEBUG_DIR isn't taking effect anymore, when for the hypervisor build it should. And of course behavior now differs between building xen/ in a tree where tools/ was built before vs in an otherwise clean tree. Fixes: 82b9cc04a7c7 ("build: add make macro for making file from file.in") Signed-off-by: Jan Beulich --- This is clumsy, but I can't think of anything better. Suggestions anyone? --- a/Config.mk +++ b/Config.mk @@ -162,7 +162,9 @@ endef PATH_FILES := Paths.mk INC_FILES = $(foreach f, $(PATH_FILES), $(XEN_ROOT)/config/$(f)) +ifndef XEN_FULLVERSION -include $(INC_FILES) +endif BUILD_MAKE_VARS = $(foreach f, $(PATH_FILES), $(shell awk '$$2 == ":=" { print $$1; }' $(XEN_ROOT)/config/$(f).in)) From xen-devel-bounces@lists.xenproject.org Wed Jan 14 14:27:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 14:27:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203210.1518482 (Exim 4.92) (envelope-from ) id 1vg1ql-00038N-NB; Wed, 14 Jan 2026 14:27:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203210.1518482; Wed, 14 Jan 2026 14: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 1vg1ql-000366-E1; Wed, 14 Jan 2026 14:27:55 +0000 Received: by outflank-mailman (input) for mailman id 1203210; Wed, 14 Jan 2026 14:27: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 1vg1qk-0002lw-Ti for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 14:27:54 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id 367ef5da-f155-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 15:27:54 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AA7131516; Wed, 14 Jan 2026 06:27:46 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EB1F13F632; Wed, 14 Jan 2026 06:27:51 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 367ef5da-f155-11f0-b15e-2bf370ae4941 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Penny Zheng , Wei Chen , Luca Fancellu , Hari Limaye Subject: [PATCH v4 3/6] arm/mpu: Implement free_init_memory for MPU systems Date: Wed, 14 Jan 2026 14:27:31 +0000 Message-ID: <20260114142734.239197-4-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260114142734.239197-1-harry.ramsey@arm.com> References: <20260114142734.239197-1-harry.ramsey@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Penny Zheng Implement the function `free_init_memory` for MPU systems. In order to support this, the function `modify_xen_mappings` is implemented. On MPU systems, we map the init text and init data sections using separate MPU memory regions. Therefore these are removed separately in `free_init_memory`. Additionally remove warning messages from `is_mm_attr_match` as some attributes can now be updated by `xen_mpumap_update_entry`. Signed-off-by: Penny Zheng Signed-off-by: Wei Chen Signed-off-by: Luca Fancellu Signed-off-by: Hari Limaye Signed-off-by: Harry Ramsey Reviewed-by: Michal Orzel --- v4: - Refactor printk regarding memory modifications - Add Michal R-By v3: - Refactor MPU_ATTR_* defines v2: - Refactor `is_mm_attr_match` to return logical values regarding the attribute mismatch. - Improve code documentation. --- xen/arch/arm/include/asm/setup.h | 2 + xen/arch/arm/mpu/mm.c | 119 +++++++++++++++++++++++-------- 2 files changed, 93 insertions(+), 28 deletions(-) diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h index 1eaf13bd66..005cf7be59 100644 --- a/xen/arch/arm/include/asm/setup.h +++ b/xen/arch/arm/include/asm/setup.h @@ -65,6 +65,8 @@ int map_irq_to_domain(struct domain *d, unsigned int irq, int map_range_to_domain(const struct dt_device_node *dev, uint64_t addr, uint64_t len, void *data); +extern const char __init_data_begin[], __bss_start[], __bss_end[]; + struct init_info { /* Pointer to the stack, used by head.S when entering in C */ diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c index 5e19ffde4c..cfd75abdb0 100644 --- a/xen/arch/arm/mpu/mm.c +++ b/xen/arch/arm/mpu/mm.c @@ -15,6 +15,9 @@ #include #include +#define MPU_ATTR_XN_RO_MISMATCH -1 +#define MPU_ATTR_AI_MISMATCH -2 + struct page_info *frame_table; /* Maximum number of supported MPU memory regions by the EL2 MPU. */ @@ -171,33 +174,16 @@ int mpumap_contains_region(pr_t *table, uint8_t nr_regions, paddr_t base, return MPUMAP_REGION_NOTFOUND; } -static bool is_mm_attr_match(pr_t *region, unsigned int attributes) +static int is_mm_attr_match(pr_t *region, unsigned int attributes) { - if ( region->prbar.reg.ro != PAGE_RO_MASK(attributes) ) - { - printk(XENLOG_WARNING - "Mismatched Access Permission attributes (%#x instead of %#x)\n", - region->prbar.reg.ro, PAGE_RO_MASK(attributes)); - return false; - } - - if ( region->prbar.reg.xn != PAGE_XN_MASK(attributes) ) - { - printk(XENLOG_WARNING - "Mismatched Execute Never attributes (%#x instead of %#x)\n", - region->prbar.reg.xn, PAGE_XN_MASK(attributes)); - return false; - } + if ( (region->prbar.reg.xn != PAGE_XN_MASK(attributes)) || + (region->prbar.reg.ro != PAGE_RO_MASK(attributes)) ) + return MPU_ATTR_XN_RO_MISMATCH; if ( region->prlar.reg.ai != PAGE_AI_MASK(attributes) ) - { - printk(XENLOG_WARNING - "Mismatched Memory Attribute Index (%#x instead of %#x)\n", - region->prlar.reg.ai, PAGE_AI_MASK(attributes)); - return false; - } + return MPU_ATTR_AI_MISMATCH; - return true; + return 0; } /* Map a frame table to cover physical addresses ps through pe */ @@ -358,12 +344,44 @@ static int xen_mpumap_update_entry(paddr_t base, paddr_t limit, */ if ( flags_has_page_present && (rc >= MPUMAP_REGION_FOUND) ) { - if ( !is_mm_attr_match(&xen_mpumap[idx], flags) ) + int attr_match = is_mm_attr_match(&xen_mpumap[idx], flags); + + /* We do not support modifying AI attribute. */ + if ( MPU_ATTR_AI_MISMATCH == attr_match ) { - printk("Modifying an existing entry is not supported\n"); + printk(XENLOG_ERR + "Modifying AI attribute is not supported\n"); return -EINVAL; } + /* + * Attributes RO and XN can be changed only by the full region. + * Attributes that match can continue and just increment refcount. + */ + if ( MPU_ATTR_XN_RO_MISMATCH == attr_match ) + { + if ( rc == MPUMAP_REGION_INCLUSIVE ) + { + printk(XENLOG_ERR + "Cannot modify partial region attributes\n"); + return -EINVAL; + } + + if ( xen_mpumap[idx].refcount != 0 ) + { + printk(XENLOG_ERR + "Cannot modify RO,XN attributes for a region mapped multiple times\n"); + return -EINVAL; + } + + /* Set new attributes */ + xen_mpumap[idx].prbar.reg.ro = PAGE_RO_MASK(flags); + xen_mpumap[idx].prbar.reg.xn = PAGE_XN_MASK(flags); + + write_protection_region(&xen_mpumap[idx], idx); + return 0; + } + /* Check for overflow of refcount before incrementing. */ if ( xen_mpumap[idx].refcount == 0xFF ) { @@ -515,8 +533,7 @@ void __init setup_mm_helper(void) int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf) { - BUG_ON("unimplemented"); - return -EINVAL; + return xen_mpumap_update(s, e, nf); } void dump_hyp_walk(vaddr_t addr) @@ -527,7 +544,53 @@ void dump_hyp_walk(vaddr_t addr) /* Release all __init and __initdata ranges to be reused */ void free_init_memory(void) { - BUG_ON("unimplemented"); + unsigned long inittext_end = (unsigned long)__init_data_begin; + unsigned long len = __init_end - __init_begin; + uint8_t idx; + int rc; + + /* Modify inittext region to be read/write instead of read/execute. */ + rc = modify_xen_mappings((unsigned long)__init_begin, inittext_end, + PAGE_HYPERVISOR_RW); + if ( rc ) + panic("Unable to map RW the init text section (rc = %d)\n", rc); + + /* + * From now on, init will not be used for execution anymore, + * so nuke the instruction cache to remove entries related to init. + */ + invalidate_icache_local(); + + /* + * The initdata region already has read/write permissions so it can just be + * zeroed out. + */ + memset(__init_begin, 0, len); + + rc = destroy_xen_mappings((unsigned long)__init_begin, inittext_end); + if ( rc ) + panic("Unable to remove init text section (rc = %d)\n", rc); + + /* + * The initdata and bss sections are mapped using a single MPU region, so + * modify the start of this region to remove the initdata section. + */ + spin_lock(&xen_mpumap_lock); + + rc = mpumap_contains_region(xen_mpumap, max_mpu_regions, + (unsigned long)__init_data_begin, + (unsigned long)__bss_end, + &idx); + if ( rc < MPUMAP_REGION_FOUND ) + panic("Unable to find bss data section (rc = %d)\n", rc); + + /* bss data section is shrunk and now starts from __bss_start */ + pr_set_base(&xen_mpumap[idx], (unsigned long)__bss_start); + + write_protection_region(&xen_mpumap[idx], idx); + context_sync_mpu(); + + spin_unlock(&xen_mpumap_lock); } void __iomem *ioremap_attr(paddr_t start, size_t len, unsigned int flags) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 14 14:27:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 14:27:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203207.1518459 (Exim 4.92) (envelope-from ) id 1vg1qj-0002mA-RL; Wed, 14 Jan 2026 14:27:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203207.1518459; Wed, 14 Jan 2026 14:27:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg1qj-0002m3-Oj; Wed, 14 Jan 2026 14:27:53 +0000 Received: by outflank-mailman (input) for mailman id 1203207; Wed, 14 Jan 2026 14:27: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 1vg1qi-0002lZ-1N for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 14:27:52 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id 33f0b4af-f155-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 15:27:49 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5B9211515; Wed, 14 Jan 2026 06:27:42 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 208813F632; Wed, 14 Jan 2026 06:27:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 33f0b4af-f155-11f0-9ccf-f158ae23cfc8 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v4 0/6] Fourth MPU Series Date: Wed, 14 Jan 2026 14:27:28 +0000 Message-ID: <20260114142734.239197-1-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This series aims to further the ongoing work to introduce support for MPU systems in xen. The patches in this series implement various memory functions and enable the hypervisor timer. Luca Fancellu (3): arm/mpu: Implement copy_from_paddr for MPU systems arm/mpu: Implement vmap functions for MPU arm/mpu: Introduce modify_after_init_mappings Penny Zheng (3): arm/mpu: Implement free_init_memory for MPU systems arm: Use secure hypervisor timer in MPU system arm/mpu: Map domain page in AArch64 MPU systems xen/arch/arm/Kconfig | 1 + xen/arch/arm/include/asm/arm64/sysregs.h | 11 ++ xen/arch/arm/include/asm/mpu/mm.h | 10 ++ xen/arch/arm/include/asm/setup.h | 5 + xen/arch/arm/mmu/setup.c | 15 ++ xen/arch/arm/mpu/Makefile | 1 + xen/arch/arm/mpu/domain-page.c | 46 +++++ xen/arch/arm/mpu/mm.c | 204 ++++++++++++++++++----- xen/arch/arm/mpu/setup.c | 54 +++++- xen/arch/arm/mpu/vmap.c | 14 +- xen/arch/arm/setup.c | 15 +- 11 files changed, 318 insertions(+), 58 deletions(-) create mode 100644 xen/arch/arm/mpu/domain-page.c -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 14 14:27:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 14:27:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203209.1518475 (Exim 4.92) (envelope-from ) id 1vg1ql-00031P-A4; Wed, 14 Jan 2026 14:27:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203209.1518475; Wed, 14 Jan 2026 14: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 1vg1ql-00030o-4y; Wed, 14 Jan 2026 14:27:55 +0000 Received: by outflank-mailman (input) for mailman id 1203209; Wed, 14 Jan 2026 14:27:53 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg1qj-0002lw-IF for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 14:27:53 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id 357b10ea-f155-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 15:27:52 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F29AA1650; Wed, 14 Jan 2026 06:27:44 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A77763F632; Wed, 14 Jan 2026 06:27:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 357b10ea-f155-11f0-b15e-2bf370ae4941 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Luca Fancellu , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v4 2/6] arm/mpu: Implement vmap functions for MPU Date: Wed, 14 Jan 2026 14:27:30 +0000 Message-ID: <20260114142734.239197-3-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260114142734.239197-1-harry.ramsey@arm.com> References: <20260114142734.239197-1-harry.ramsey@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Luca Fancellu HAS_VMAP is not enabled on MPU systems, but the vmap functions are used in places across common code. In order to keep the existing code and maintain correct functionality, implement the `vmap_contig` and `vunmap` functions for MPU systems. Introduce a helper function `destroy_xen_mapping_containing` to aid with unmapping an entire region when only the start address is known. Signed-off-by: Luca Fancellu Signed-off-by: Harry Ramsey --- v4: - Code style fixes v3: - Add additional comments for clarity regarding MPUMAP_REGION checks - Ensure `context_sync_mpu` occurs after `destroy_entire_xen_mapping` - Fix deadlock if `destroy_entire_xen_mapping` is called with an address that does not belong to a region v2: - Rename `destroy_entire_xen_mapping` to `destroy_xen_mapping_containing` - Improve code documentation - Refactor nested code - Fix ignored rc error code in `destroy_xen_mapping_containing` --- xen/arch/arm/include/asm/mpu/mm.h | 10 ++++ xen/arch/arm/mpu/mm.c | 83 ++++++++++++++++++++++++++----- xen/arch/arm/mpu/vmap.c | 14 ++++-- 3 files changed, 92 insertions(+), 15 deletions(-) diff --git a/xen/arch/arm/include/asm/mpu/mm.h b/xen/arch/arm/include/asm/mpu/mm.h index e1ded6521d..1b5ffa5b64 100644 --- a/xen/arch/arm/include/asm/mpu/mm.h +++ b/xen/arch/arm/include/asm/mpu/mm.h @@ -111,6 +111,16 @@ pr_t pr_of_addr(paddr_t base, paddr_t limit, unsigned int flags); int mpumap_contains_region(pr_t *table, uint8_t nr_regions, paddr_t base, paddr_t limit, uint8_t *index); + +/* + * Destroys and frees (if reference count is 0) an entire xen mapping on MPU + * systems where only the start address is known. + * + * @param s Start address of memory region to be destroyed. + * @return: 0 on success, negative on error. + */ +int destroy_xen_mapping_containing(paddr_t s); + #endif /* __ARM_MPU_MM_H__ */ /* diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c index 687dec3bc6..5e19ffde4c 100644 --- a/xen/arch/arm/mpu/mm.c +++ b/xen/arch/arm/mpu/mm.c @@ -290,6 +290,43 @@ static void disable_mpu_region_from_index(uint8_t index) write_protection_region(&xen_mpumap[index], index); } +/* + * Free a xen_mpumap entry given the index. A mpu region is actually disabled + * when the refcount is 0 and the region type is MPUMAP_REGION_FOUND. + * + * @param idx Index of the mpumap entry. + * @param region_found_type MPUMAP_REGION_* value. + * @return 0 on success, otherwise negative on error. + */ +static int xen_mpumap_free_entry(uint8_t idx, int region_found_type) +{ + ASSERT(spin_is_locked(&xen_mpumap_lock)); + ASSERT(idx != INVALID_REGION_IDX); + ASSERT(MPUMAP_REGION_OVERLAP != region_found_type); + + if ( MPUMAP_REGION_NOTFOUND == region_found_type ) + { + printk(XENLOG_ERR "Cannot remove entry that does not exist\n"); + return -EINVAL; + } + + if ( xen_mpumap[idx].refcount ) + { + xen_mpumap[idx].refcount -= 1; + return 0; + } + + if ( MPUMAP_REGION_FOUND != region_found_type ) + { + printk(XENLOG_ERR "Cannot remove a partial region\n"); + return -EINVAL; + } + + disable_mpu_region_from_index(idx); + + return 0; +} + /* * Update the entry in the MPU memory region mapping table (xen_mpumap) for the * given memory range and flags, creating one if none exists. @@ -357,18 +394,7 @@ static int xen_mpumap_update_entry(paddr_t base, paddr_t limit, return -EINVAL; } - if ( xen_mpumap[idx].refcount == 0 ) - { - if ( MPUMAP_REGION_FOUND == rc ) - disable_mpu_region_from_index(idx); - else - { - printk("Cannot remove a partial region\n"); - return -EINVAL; - } - } - else - xen_mpumap[idx].refcount -= 1; + return xen_mpumap_free_entry(idx, rc); } return 0; @@ -418,6 +444,39 @@ int destroy_xen_mappings(unsigned long s, unsigned long e) return xen_mpumap_update(s, e, 0); } +int destroy_xen_mapping_containing(paddr_t s) +{ + int rc; + uint8_t idx; + + ASSERT(IS_ALIGNED(s, PAGE_SIZE)); + + spin_lock(&xen_mpumap_lock); + + rc = mpumap_contains_region(xen_mpumap, max_mpu_regions, s, s + PAGE_SIZE, + &idx); + + /* + * Since only entire regions can be freed using `xen_mpumap_free_entry` we + * must first check the region exists. + */ + if ( MPUMAP_REGION_NOTFOUND == rc ) + { + printk(XENLOG_ERR "Cannot remove entry that does not exist"); + rc = -EINVAL; + goto out; + } + + /* As we are unmapping entire region use MPUMAP_REGION_FOUND instead */ + rc = xen_mpumap_free_entry(idx, MPUMAP_REGION_FOUND); + if ( !rc ) + context_sync_mpu(); + out: + spin_unlock(&xen_mpumap_lock); + + return rc; +} + int map_pages_to_xen(unsigned long virt, mfn_t mfn, unsigned long nr_mfns, unsigned int flags) { diff --git a/xen/arch/arm/mpu/vmap.c b/xen/arch/arm/mpu/vmap.c index f977b79cd4..54d949e7ce 100644 --- a/xen/arch/arm/mpu/vmap.c +++ b/xen/arch/arm/mpu/vmap.c @@ -1,19 +1,27 @@ /* SPDX-License-Identifier: GPL-2.0-only */ #include +#include #include #include #include void *vmap_contig(mfn_t mfn, unsigned int nr) { - BUG_ON("unimplemented"); - return NULL; + paddr_t base = mfn_to_maddr(mfn); + + if ( map_pages_to_xen(base, mfn, nr, PAGE_HYPERVISOR ) ) + return NULL; + + return maddr_to_virt(base); } void vunmap(const void *va) { - BUG_ON("unimplemented"); + paddr_t base = virt_to_maddr(va); + + if ( destroy_xen_mapping_containing(base) ) + panic("Failed to vunmap region\n"); } /* -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 14 14:27:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 14:27:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203208.1518469 (Exim 4.92) (envelope-from ) id 1vg1ql-0002zi-1m; Wed, 14 Jan 2026 14:27:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203208.1518469; Wed, 14 Jan 2026 14: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 1vg1qk-0002zb-Uq; Wed, 14 Jan 2026 14:27:54 +0000 Received: by outflank-mailman (input) for mailman id 1203208; Wed, 14 Jan 2026 14: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 1vg1qj-0002lZ-1c for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 14:27:53 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id 34c4a6bc-f155-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 15:27:51 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B19631516; Wed, 14 Jan 2026 06:27:43 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4A6B83F632; Wed, 14 Jan 2026 06:27:49 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 34c4a6bc-f155-11f0-9ccf-f158ae23cfc8 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Luca Fancellu , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Hari Limaye Subject: [PATCH v4 1/6] arm/mpu: Implement copy_from_paddr for MPU systems Date: Wed, 14 Jan 2026 14:27:29 +0000 Message-ID: <20260114142734.239197-2-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260114142734.239197-1-harry.ramsey@arm.com> References: <20260114142734.239197-1-harry.ramsey@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Luca Fancellu Implement the function copy_from_paddr variant for MPU systems, using the map_pages_to_xen/destroy_xen_mappings to temporarily map the memory range to be copied. Signed-off-by: Luca Fancellu Signed-off-by: Hari Limaye Signed-off-by: Harry Ramsey Reviewed-by: Michal Orzel --- v4: - No changes v3: - No changes v2: - add Michal R-by --- xen/arch/arm/mpu/setup.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/mpu/setup.c b/xen/arch/arm/mpu/setup.c index 163573b932..ec264f54f2 100644 --- a/xen/arch/arm/mpu/setup.c +++ b/xen/arch/arm/mpu/setup.c @@ -91,7 +91,19 @@ void * __init early_fdt_map(paddr_t fdt_paddr) */ void __init copy_from_paddr(void *dst, paddr_t paddr, unsigned long len) { - BUG_ON("unimplemented"); + paddr_t start_pg = round_pgdown(paddr); + paddr_t end_pg = round_pgup(paddr + len); + unsigned long nr_mfns = (end_pg - start_pg) >> PAGE_SHIFT; + mfn_t mfn = maddr_to_mfn(start_pg); + + if ( map_pages_to_xen(start_pg, mfn, nr_mfns, PAGE_HYPERVISOR_WC) ) + panic("Unable to map range for copy_from_paddr\n"); + + memcpy(dst, maddr_to_virt(paddr), len); + clean_dcache_va_range(dst, len); + + if ( destroy_xen_mappings(start_pg, end_pg) ) + panic("Unable to unmap range for copy_from_paddr\n"); } void __init remove_early_mappings(void) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 14 14:27:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 14:27:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203211.1518500 (Exim 4.92) (envelope-from ) id 1vg1qo-0003hZ-Rr; Wed, 14 Jan 2026 14:27:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203211.1518500; Wed, 14 Jan 2026 14:27:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg1qo-0003hQ-Nx; Wed, 14 Jan 2026 14:27:58 +0000 Received: by outflank-mailman (input) for mailman id 1203211; Wed, 14 Jan 2026 14: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 1vg1qn-0002lZ-Kc for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 14:27:57 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id 37607e8c-f155-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 15:27:55 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 15B1F1650; Wed, 14 Jan 2026 06:27:48 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A20313F632; Wed, 14 Jan 2026 06:27:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 37607e8c-f155-11f0-9ccf-f158ae23cfc8 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Luca Fancellu , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Hari Limaye Subject: [PATCH v4 4/6] arm/mpu: Introduce modify_after_init_mappings Date: Wed, 14 Jan 2026 14:27:32 +0000 Message-ID: <20260114142734.239197-5-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260114142734.239197-1-harry.ramsey@arm.com> References: <20260114142734.239197-1-harry.ramsey@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Luca Fancellu During `init_done`, Xen sets the permissions of all symbols marked with __ro_after_init to be read-only. This does not work on MPU systems at present because part-region modification is not supported. Therefore introduce the function `modify_after_init_mappings` for MMU and MPU, to handle the divergent approaches to setting permissions of __ro_after_init symbols. For MPU systems `modify_xen_mappings` will shrink the RW mapping on one side and extend the RO mapping on the other. This approach prevents wasting an additional region between RW and RO mappings. As the new function is marked with __init, it needs to be called before `free_init_memory`. Signed-off-by: Luca Fancellu Signed-off-by: Hari Limaye Signed-off-by: Harry Ramsey Reviewed-by: Michal Orzel --- v4: - No changes v3: - Add Michal R-by v2: - No changes --- xen/arch/arm/include/asm/setup.h | 3 +++ xen/arch/arm/mmu/setup.c | 15 ++++++++++++ xen/arch/arm/mpu/mm.c | 2 +- xen/arch/arm/mpu/setup.c | 40 ++++++++++++++++++++++++++++++++ xen/arch/arm/setup.c | 15 ++---------- 5 files changed, 61 insertions(+), 14 deletions(-) diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h index 005cf7be59..899e33925c 100644 --- a/xen/arch/arm/include/asm/setup.h +++ b/xen/arch/arm/include/asm/setup.h @@ -78,6 +78,9 @@ struct init_info paddr_t consider_modules(paddr_t s, paddr_t e, uint32_t size, paddr_t align, int first_mod); +/* Modify some mappings after the init is done */ +void modify_after_init_mappings(void); + #endif /* * Local variables: diff --git a/xen/arch/arm/mmu/setup.c b/xen/arch/arm/mmu/setup.c index 9b874f8ab2..d042f73597 100644 --- a/xen/arch/arm/mmu/setup.c +++ b/xen/arch/arm/mmu/setup.c @@ -213,6 +213,21 @@ void __init remove_early_mappings(void) BUG_ON(rc); } +void __init modify_after_init_mappings(void) +{ + /* + * We have finished booting. Mark the section .data.ro_after_init + * read-only. + */ + int rc = modify_xen_mappings((unsigned long)&__ro_after_init_start, + (unsigned long)&__ro_after_init_end, + PAGE_HYPERVISOR_RO); + + if ( rc ) + panic("Unable to mark the .data.ro_after_init section read-only (rc = %d)\n", + rc); +} + /* * After boot, Xen page-tables should not contain mapping that are both * Writable and eXecutables. diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c index cfd75abdb0..6b3b0b06e9 100644 --- a/xen/arch/arm/mpu/mm.c +++ b/xen/arch/arm/mpu/mm.c @@ -35,7 +35,7 @@ DECLARE_BITMAP(xen_mpumap_mask, MAX_MPU_REGION_NR) \ /* EL2 Xen MPU memory region mapping table. */ pr_t __cacheline_aligned __section(".data") xen_mpumap[MAX_MPU_REGION_NR]; -static DEFINE_SPINLOCK(xen_mpumap_lock); +DEFINE_SPINLOCK(xen_mpumap_lock); static void __init __maybe_unused build_assertions(void) { diff --git a/xen/arch/arm/mpu/setup.c b/xen/arch/arm/mpu/setup.c index ec264f54f2..55317ee318 100644 --- a/xen/arch/arm/mpu/setup.c +++ b/xen/arch/arm/mpu/setup.c @@ -8,11 +8,14 @@ #include #include #include +#include #include static paddr_t __initdata mapped_fdt_base = INVALID_PADDR; static paddr_t __initdata mapped_fdt_limit = INVALID_PADDR; +extern spinlock_t xen_mpumap_lock; + void __init setup_pagetables(void) {} void * __init early_fdt_map(paddr_t fdt_paddr) @@ -106,6 +109,43 @@ void __init copy_from_paddr(void *dst, paddr_t paddr, unsigned long len) panic("Unable to unmap range for copy_from_paddr\n"); } +void __init modify_after_init_mappings(void) +{ + int rc; + uint8_t idx_rodata; + uint8_t idx_rwdata; + + spin_lock(&xen_mpumap_lock); + + rc = mpumap_contains_region(xen_mpumap, max_mpu_regions, + (unsigned long)_srodata, + (unsigned long)_erodata, + &idx_rodata); + + if ( rc < MPUMAP_REGION_FOUND ) + panic("Unable to find rodata section (rc = %d)\n", rc); + + rc = mpumap_contains_region(xen_mpumap, max_mpu_regions, + (unsigned long)__ro_after_init_start, + (unsigned long)__init_begin, + &idx_rwdata); + + if ( rc < MPUMAP_REGION_FOUND ) + panic("Unable to find rwdata section (rc = %d)\n", rc); + + /* Shrink rwdata section to begin at __ro_after_init_end */ + pr_set_base(&xen_mpumap[idx_rwdata], (unsigned long)__ro_after_init_end); + + /* Extend rodata section to end at __ro_after_init_end */ + pr_set_limit(&xen_mpumap[idx_rodata], (unsigned long)__ro_after_init_end); + + write_protection_region(&xen_mpumap[idx_rwdata], idx_rwdata); + write_protection_region(&xen_mpumap[idx_rodata], idx_rodata); + context_sync_mpu(); + + spin_unlock(&xen_mpumap_lock); +} + void __init remove_early_mappings(void) { int rc = destroy_xen_mappings(round_pgdown(mapped_fdt_base), diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 7ad870e382..6310a47d68 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -66,23 +66,12 @@ domid_t __read_mostly max_init_domid; static __used void noreturn init_done(void) { - int rc; - /* Must be done past setting system_state. */ unregister_init_virtual_region(); - free_init_memory(); + modify_after_init_mappings(); - /* - * We have finished booting. Mark the section .data.ro_after_init - * read-only. - */ - rc = modify_xen_mappings((unsigned long)&__ro_after_init_start, - (unsigned long)&__ro_after_init_end, - PAGE_HYPERVISOR_RO); - if ( rc ) - panic("Unable to mark the .data.ro_after_init section read-only (rc = %d)\n", - rc); + free_init_memory(); startup_cpu_idle_loop(); } -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 14 14:27:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 14:27:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203212.1518506 (Exim 4.92) (envelope-from ) id 1vg1qp-0003lx-94; Wed, 14 Jan 2026 14:27:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203212.1518506; Wed, 14 Jan 2026 14: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 1vg1qp-0003lO-3D; Wed, 14 Jan 2026 14:27:59 +0000 Received: by outflank-mailman (input) for mailman id 1203212; Wed, 14 Jan 2026 14:27:57 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg1qn-0002lw-NE for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 14:27:57 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id 38598b2a-f155-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 15:27:57 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BD49D1655; Wed, 14 Jan 2026 06:27:49 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0AF2E3F632; Wed, 14 Jan 2026 06:27:54 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 38598b2a-f155-11f0-b15e-2bf370ae4941 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Penny Zheng , Wei Chen , Luca Fancellu , Ayan Kumar Halder Subject: [PATCH v4 5/6] arm: Use secure hypervisor timer in MPU system Date: Wed, 14 Jan 2026 14:27:33 +0000 Message-ID: <20260114142734.239197-6-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260114142734.239197-1-harry.ramsey@arm.com> References: <20260114142734.239197-1-harry.ramsey@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Penny Zheng As MPU systems only have one secure state, we have to use secure EL2 hypervisor timer for Xen in secure EL2. Signed-off-by: Penny Zheng Signed-off-by: Wei Chen Signed-off-by: Luca Fancellu Signed-off-by: Harry Ramsey Reviewed-by: Ayan Kumar Halder Acked-by: Michal Orzel --- v4: - No changes v3: - Add Ayan R-by - Add Michal A-by v2: - Remove unncessary kconfig attribute. - Remove unncessary hypervisor timer macro. --- xen/arch/arm/include/asm/arm64/sysregs.h | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/include/asm/arm64/sysregs.h index 7dfd20414d..19d409d3eb 100644 --- a/xen/arch/arm/include/asm/arm64/sysregs.h +++ b/xen/arch/arm/include/asm/arm64/sysregs.h @@ -462,6 +462,17 @@ #define ZCR_ELx_LEN_SIZE 9 #define ZCR_ELx_LEN_MASK 0x1ff +#ifdef CONFIG_MPU +/* + * The Armv8-R AArch64 architecture always executes code in Secure + * state with EL2 as the highest exception level. + * + * Hypervisor timer registers for Secure EL2. + */ +#define CNTHP_CTL_EL2 CNTHPS_CTL_EL2 +#define CNTHP_CVAL_EL2 CNTHPS_CVAL_EL2 +#endif + #define REGION_TEXT_PRBAR 0x38 /* SH=11 AP=10 XN=00 */ #define REGION_RO_PRBAR 0x3A /* SH=11 AP=10 XN=10 */ #define REGION_DATA_PRBAR 0x32 /* SH=11 AP=00 XN=10 */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 14 14:28:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 14:28:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203214.1518520 (Exim 4.92) (envelope-from ) id 1vg1qr-0004FX-T0; Wed, 14 Jan 2026 14:28:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203214.1518520; Wed, 14 Jan 2026 14:28:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg1qr-0004FO-PS; Wed, 14 Jan 2026 14:28:01 +0000 Received: by outflank-mailman (input) for mailman id 1203214; Wed, 14 Jan 2026 14:28:00 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg1qq-0002lZ-Jr for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 14:28:00 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id 3958e2c4-f155-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 15:27:58 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 599D01516; Wed, 14 Jan 2026 06:27:51 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B54823F632; Wed, 14 Jan 2026 06:27:56 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3958e2c4-f155-11f0-9ccf-f158ae23cfc8 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Penny Zheng , Wei Chen , Luca Fancellu Subject: [PATCH v4 6/6] arm/mpu: Map domain page in AArch64 MPU systems Date: Wed, 14 Jan 2026 14:27:34 +0000 Message-ID: <20260114142734.239197-7-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260114142734.239197-1-harry.ramsey@arm.com> References: <20260114142734.239197-1-harry.ramsey@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Penny Zheng In MPU systems, we implement map_domain_page()/unmap_domain_page() through mapping the domain page with a MPU region on demand. Signed-off-by: Penny Zheng Signed-off-by: Wei Chen Signed-off-by: Luca Fancellu Signed-off-by: Harry Ramsey --- v4: - Remove duplicate code by having `map_domain_page` and `unmap_domain_page` use `vmap_contig` and `vunmap` v3: - No changes v2: - No changes --- xen/arch/arm/Kconfig | 1 + xen/arch/arm/mpu/Makefile | 1 + xen/arch/arm/mpu/domain-page.c | 46 ++++++++++++++++++++++++++++++++++ 3 files changed, 48 insertions(+) create mode 100644 xen/arch/arm/mpu/domain-page.c diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index cf6af68299..baa6c4cf15 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -91,6 +91,7 @@ config MMU config MPU bool "MPU" if UNSUPPORTED + select ARCH_MAP_DOMAIN_PAGE if ARM_64 select STATIC_MEMORY help Memory Protection Unit (MPU). Select if you plan to run Xen on ARMv8-R diff --git a/xen/arch/arm/mpu/Makefile b/xen/arch/arm/mpu/Makefile index 4963c8b550..940297af3f 100644 --- a/xen/arch/arm/mpu/Makefile +++ b/xen/arch/arm/mpu/Makefile @@ -1,5 +1,6 @@ obj-$(CONFIG_ARM_32) += arm32/ obj-$(CONFIG_ARM_64) += arm64/ +obj-$(CONFIG_ARM_64) += domain-page.o obj-y += mm.o obj-y += p2m.o obj-y += setup.init.o diff --git a/xen/arch/arm/mpu/domain-page.c b/xen/arch/arm/mpu/domain-page.c new file mode 100644 index 0000000000..b79afc493b --- /dev/null +++ b/xen/arch/arm/mpu/domain-page.c @@ -0,0 +1,46 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include +#include +#include +#include +#include +#include + +void *map_domain_page_global(mfn_t mfn) +{ + BUG_ON("unimplemented"); + return NULL; +} + +/* Map a page of domheap memory */ +void *map_domain_page(mfn_t mfn) +{ + return vmap_contig(mfn, 1); +} + +/* Release a mapping taken with map_domain_page() */ +void unmap_domain_page(const void *ptr) +{ + vunmap(ptr); +} + +mfn_t domain_page_map_to_mfn(const void *ptr) +{ + BUG_ON("unimplemented"); + return INVALID_MFN; +} + +void unmap_domain_page_global(const void *va) +{ + BUG_ON("unimplemented"); +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 14 14:46:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 14:46:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203286.1518530 (Exim 4.92) (envelope-from ) id 1vg28R-00006t-BM; Wed, 14 Jan 2026 14:46:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203286.1518530; Wed, 14 Jan 2026 14: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 1vg28R-00006m-8T; Wed, 14 Jan 2026 14:46:11 +0000 Received: by outflank-mailman (input) for mailman id 1203286; Wed, 14 Jan 2026 14: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 1vg28Q-00006g-BR for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 14:46:10 +0000 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [2a00:1450:4864:20::342]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id beffb65c-f157-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 15:46:02 +0100 (CET) Received: by mail-wm1-x342.google.com with SMTP id 5b1f17b1804b1-47edd6111b4so15469425e9.1 for ; Wed, 14 Jan 2026 06:46:01 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee591933bsm31084985e9.15.2026.01.14.06.46.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 06:46:01 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: beffb65c-f157-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768401961; x=1769006761; 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=LxSSAigpshvFRIR4HcF21VTPx1MqPmFL7Iw4jjvRg0A=; b=YmpsGUCtoabBxGE3eCvUUIO7fc8r3dKNatzVXOqEFr7jKOnemzP/7Q4ZHnxQxE58KO HjsCJAyl35HhjxxQs20vVvshWa+LWHXauByQrVqjhUDYK4Cvh79OgDKbsF2TVctXbjPi YYH1v8xh/205RxnCRvygsXHxtfJ2pS3Co5Rky38o2kod5tbX5ID13UxZC+LphOWC7x2V doYn9Df5D0JzotvsvBFmA9A1I2LqmXdZqdQxZg9cdX0kW17e5sjFcaA+Czv7VYYCQ4aD GwXgw02fsgUquh+FPunQcwwVwTiEEjnFMlIfdPhe9gwL8ayiRQqLV+8nZKGyCmW+fTZs mssw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768401961; x=1769006761; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=LxSSAigpshvFRIR4HcF21VTPx1MqPmFL7Iw4jjvRg0A=; b=iYK3oujeg1wAxAJs12vf2YgB1FhlK6n6/8N3/MrXBGzrDISUn8pS3hBFbP3HHY1ItO kUbjtvdoNJn4XGhTWtbAjYXvLMSwa+ABNx4jmxcfCASHtjnSHOVoNvnuprAFzNOG2FOC 42+gF/r2UP5JIPssO5x25GOd1AgnjVWJ2XzIUiAENDU9kZc9Ih14cVoNOHrzroJYBK+/ qSiFY8d2VTfvtLgq659Evdw+076Un9Ceij8nCJkXXT/nCO7DtpKogX9teaaPW4noYTm5 keekyJwl+/pXZww88Vr0pw+bOjMdHZtgghFvq6XGJ7M57f/MNPaUkEIcJEq24FdPCb4o gYVw== X-Forwarded-Encrypted: i=1; AJvYcCWO+jHPPQePWYKyM7un1VDUbSP6DEAf7rUmkHFyzgy4fhBYLZ9O+pFlJK9Gf4DBBwfwTLe2HC6qbKc=@lists.xenproject.org X-Gm-Message-State: AOJu0YzRxnU6rV4lwkFVolj/viAXtxlJf0klaRQE7hR4IEu/3E5FUlIL O7rvVZMpQFJhTXDwRhKfmSf6l1fA14UEzeZZsoqvaSqPpYrpIomso1/fmKl0hs+Duw== X-Gm-Gg: AY/fxX7NAgTkp6ywd0aaMpN5daSXKoUMHAloEhl6qw94rphJ2LyY3uaaIzAXgJl2lG6 0wkQ73HkHlp5CSAdMAaj3Y0C7U2snoWjoldrcllfi0CLekHYmx1iD/amAhKZSkne78zjkfFu4BF n6mAmYq6ThoKh1NIzyesjN40N6Ap/VAVQTKp5+G2QTZL1ITh/WzXqlKoSA5voXW6o3zDOx4FVPE JpYJbeylMaAiQSnIdzEvCNf9L/j0Ilc0LKEAm/wJKAk26oyDQhbGxQGWbDjVxcRE2X7BMADMhZ0 cYlfm8J4K6bq+YWjQ2zpziAhO3XwVbnEky+zwGnkIvuE5rpPsbhox5wCKDQIbbcDlHWAltixKVd KaWhJT5Lo9UHEN0zD8WDiFREK8uld5m/di3SJXu6jQDNsvuCAx0N1VDlytT7We29MaRg9aLO4HA 5eDvzry/Juti/gZWMkMsrVVDkh68zCpx9AsI8P7t3U9PedAioWCoteN51+bS4FT5TmFaNp9mqid xc= X-Received: by 2002:a05:600c:3e86:b0:479:1ac2:f9b8 with SMTP id 5b1f17b1804b1-47ee481c269mr30777665e9.21.1768401961327; Wed, 14 Jan 2026 06:46:01 -0800 (PST) Message-ID: <79798faa-52eb-4ff9-b308-f7233d2fe2f7@suse.com> Date: Wed, 14 Jan 2026 15:46:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/6] PCI: determine whether a device has extended config space From: Jan Beulich To: Stewart Hildebrand 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: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@suse.com> <52eb1293-b5d4-4f7a-b53b-285e4dd274a5@suse.com> Content-Language: en-US Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 13.01.2026 11:46, Jan Beulich wrote: > On 12.01.2026 22:07, Stewart Hildebrand wrote: >> On 1/6/26 08:47, Jan Beulich wrote: >>> @@ -420,6 +467,19 @@ static struct pci_dev *alloc_pdev(struct >>> break; >>> } >>> >>> + if ( pdev->ext_cfg && >>> + /* >>> + * Regular PCI devices have 256 bytes, but PCI-X 2 and PCI Express >>> + * devices have 4096 bytes. Even if the device is capable, that >>> + * doesn't mean we can access it. Maybe we don't have a way to >>> + * generate extended config space accesses, or the device is behind a >>> + * reverse Express bridge. So we try reading the dword at >>> + * PCI_CFG_SPACE_SIZE which must either be 0 or a valid extended >>> + * capability header. >>> + */ >>> + pci_conf_read32(pdev->sbdf, PCI_CFG_SPACE_SIZE) == 0xffffffffU ) >>> + pdev->ext_cfg = false; >> >> I'm using a machine where >> xen/arch/x86/x86_64/mmconfig-shared.c:is_mmconf_reserved() will initially return >> false during Xen boot: >> >> (XEN) PCI: MCFG configuration 0: base f0000000 segment 0000 buses 00 - 3f >> (XEN) PCI: Not using MCFG for segment 0000 bus 00-3f >> >> Then, during dom0 boot, dom0 will call PHYSDEVOP_pci_mmcfg_reserved, after which >> MCFG becomes enabled in Xen: >> >> (XEN) PCI: Using MCFG for segment 0000 bus 00-3f >> >> On such machines where mmcfg/ECAM is initially disabled, this will effectively >> set ->ext_cfg to false for all devices discovered at Xen boot. >> >> I'm not really sure if I have any good suggestions, but perhaps we could add a >> macro or small function that returns something like >> ( pdev->ext_cfg && pci_conf_read32(pdev->sbdf, PCI_CFG_SPACE_SIZE) != 0xffffffffU ) >> to allow this checking to happen dynamically (but this still wouldn't handle the >> aliasing quirk). Maybe re-run the ext_cfg detection logic at the end of >> PHYSDEVOP_pci_mmcfg_reserved? >> >> Regardless, I'd be happy to provide my R-b without this addressed, but I am >> curious if others think this as an issue? > > Hmm, no, I forgot to consider that case (which in principle I'm well aware of). > Will need to fix in v2. That'll be a little interesting, since per Dom0's request we may also lose MCFG access to a range of busses. Looks like we indeed need to fully re- evaluate ->ext_cfg. Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 14 14:57:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 14:57:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203305.1518540 (Exim 4.92) (envelope-from ) id 1vg2J0-0001pZ-9g; Wed, 14 Jan 2026 14:57:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203305.1518540; Wed, 14 Jan 2026 14:57:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg2J0-0001pS-6Q; Wed, 14 Jan 2026 14:57:06 +0000 Received: by outflank-mailman (input) for mailman id 1203305; Wed, 14 Jan 2026 14:57:04 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg2Iy-0001ot-LC for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 14:57:04 +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 492eb651-f159-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 15:57:03 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-47ee937ecf2so2339455e9.0 for ; Wed, 14 Jan 2026 06:57:03 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5df9afsm53541486f8f.24.2026.01.14.06.57.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 06:57:02 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 492eb651-f159-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768402623; x=1769007423; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=b+DD+G3OdKM2V2MVTBspeY6HuZPJY/nZDtUKjPKR3uI=; b=PtUZncYP0CY9lYaKBQDS1LKM8DrPduwpbCu2UZrbIJZiEtjjpFPkuDTn4/dM3TGACw 9M8AmFzl9/z/v+/2pd/uditXjGtK3MCKxXgR6AX1Ps5OBrzzeFT/4cYWkn2xeB/d2rf4 dk759rQkQ+2fY+jc6vyMiyyp0YTlU88JMyN8I5pPnc+/iMdpilve9pJmsBYnVkUuCnI9 Cal7irPkcpkOFD2u7IE6WSnXvgsiimJBELAl5Mfwo9R7DrnHxqp45mmR4wGG0LvBfggg uQtDVTQIN5lL/ZuRZ7wcsuWGRWMORsj1PK3u45XwsjmqRzFPrjEH1jsjS0IZB9ztG40d tZiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768402623; x=1769007423; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=b+DD+G3OdKM2V2MVTBspeY6HuZPJY/nZDtUKjPKR3uI=; b=uzV5QR62NQqBWzinmdkgTr+n7QCzwN8NZlkmXCvmCSUhGNFOUri2rt8j+s3VaMD2nI s7ripkMQCQeCbUDtG62xIoKC90okBoa8ZowhA/YRHQrF0b5Yzmyr/uQmB9e3NwqwhMok DmiQVyt/BusmriKN1FLAAnST3onocFxa616AhGgUhMu4RhVW/Kniea9BCM1z2GfDmnBe 6Qh///yujXB6i6Hg2xDKeMYsm4MkLJMnx+xB6Ey8ctOqZ77V+sZqqjrLaAFhPnZdKCW/ BHf2otPyOGjsKWVzY++pZUVIuWlK7Q7VPKOdLGNT+qf6tGkB0uXIzwdyuLqmewDefWJw 1Cgg== X-Forwarded-Encrypted: i=1; AJvYcCWakFWixZk1VCbax9yiXCIFnvzkPsq3PexWSRDD+VuTUTa61TSgK84NLhuq90m5D+CiZPWlR/F8n+A=@lists.xenproject.org X-Gm-Message-State: AOJu0YwPbKuJ4GBa3TD4g20DgotCCP2oGL/kzLlRAU0tURdzJ9bq+TkT EABf++9cZuMU8Jc4OreW8uU/OHJw35zQNzf+v3pNWJiNQTw3Ue0szFfNHBg2CR7uWQ== X-Gm-Gg: AY/fxX7HC2QwitxdmwWVXzzoTsKnUQ40ikuzbHouhJwp7pc7DOUCX/NfWS5cAPw+3E6 JvYlZPHffpKh+kjzG7Pzy5/jy98gwrvSCQQ4YZ7ucGk93sisnJ+yw/qCIXPH/XyJPS6iqdZ/zLA rW0y0FnyGWtakowjv+ULaPhBnZsE+KkWdsUUOc9Z+9wN8hgpv5YKJ5jlEeV/c8/vspOJ8ZvVVSy pCCNJOkpYkL7nGL5Z9q5I74HBP67qdOlvFI/Z4KAHidwvKsGaPyVbg+bzjgDMBei+yuc8wzaBO6 Jvgpb8l9wFb4QnavsiA7VTE8a+/WWGfdavLNL7S1980El+BvWc47boAbvelgfZkq8CCGAGSC8wQ siyXcO+Cit3PTLnl5FjD677c9gktk+H6ZUkcy7F2pZlOHnbB6WOVFP19OAKe6yRRn6MgAmNFfpL 8y4rlCg2GmZVahY/OQmseddTbGeTj5e0GGagoJaj7zBX0XrUkTiiMMhdYvHqpk2uMIrYQvdlYSM CPvyhdbqheusA== X-Received: by 2002:a05:600c:5701:b0:47a:8383:f2b2 with SMTP id 5b1f17b1804b1-47ed7c4ebe3mr64087655e9.17.1768402622658; Wed, 14 Jan 2026 06:57:02 -0800 (PST) Message-ID: <62c22b34-cbad-40f2-a367-ba5fd8d11b51@suse.com> Date: Wed, 14 Jan 2026 15:57:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 08/15] xen/riscv: introduce vtimer_set_timer() and vtimer_expired() 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: <8cd3efa488b3da2a6751c92d20bbfeb87b3ba39a.1766595589.git.oleksii.kurochko@gmail.com> <4e18e4fc-de62-44fc-8ea0-517f6c7ef47f@gmail.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 14.01.2026 13:27, Oleksii Kurochko wrote: > On 1/13/26 4:12 PM, Jan Beulich wrote: >> On 13.01.2026 15:44, Oleksii Kurochko wrote: >>> On 1/8/26 11:28 AM, Jan Beulich wrote: >>>> On 24.12.2025 18:03, Oleksii Kurochko wrote: > Therefore, there is no real need to intercept accesses to these registers. With this ... >> you'd also need to synchronize both paths, I suppose. > > I didn't get you what is needed to be synchronized. Could you please explain? ... there's nothing to synchronize. >>>>> + { >>>>> + stop_timer(&t->timer); >>>>> + >>>>> + return; >>>>> + } >>>>> + >>>>> + set_timer(&t->timer, expires); >>>> See the handling of VCPUOP_set_singleshot_timer for what you may want to >>>> do if the expiry asked for is (perhaps just very slightly) into the past. >>> I got an idea why we want to check if "expires" already expired, but ... >>> >>>> There you'll also find a use of migrate_timer(), which you will want to >>>> at least consider using here as well. >>> ... I don't get why we want to migrate timer before set_timer() here. >>> Could you please explain that? >> Didn't I see you use migrate_timer() in other patches (making me assume >> you understand)? Having the timer tied to the pCPU where the vCPU runs >> means the signalling to that vCPU will (commonly) be cheaper. > > I thought that migrate_timer() is needed only when a vCPU changes the pCPU > it is running on to ensure that it is running on correct pCPU after migrations, > hotplug events, or scheduling changes. That is why I placed it in > vtimer_restore(), as there is no guarantee that the vCPU will run on the > same pCPU it was running on previously. > > So that is why ... > >> Whether >> that actually matters depends on what vtimer_expired() will eventually >> contain. Hence why I said "consider using". > > ... I didn't get why I might need vtimer_expired() in vtimer_set_timer() > before set_timer(). > > vtimer_expired() will only notify the vCPU that a timer interrupt has > occurred by setting bit in irqs_pending bitmap which then will be synced > with vcpu->hvip, but I still do not understand whether migrate_timer() > is needed before calling set_timer() here. Just to repeat - it's not needed. It may be wanted. > Considering that vtimer_set_timer() is called from the vCPU while it is > running on the current pCPU, and assuming no pCPU rescheduling has > occurred for this vCPU, we are already on the correct pCPU. > If pCPU rescheduling for the vCPU did occur, then migrate_timer() would > have been called in context_switch(), Even if the timer wasn't active? Jan > and at the point where > vtimer_set_timer() is invoked, we would already be running on the > correct pCPU. > > ~ Oleksii > From xen-devel-bounces@lists.xenproject.org Wed Jan 14 15:04:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 15:04:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203321.1518549 (Exim 4.92) (envelope-from ) id 1vg2QD-0003VO-Vw; Wed, 14 Jan 2026 15:04:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203321.1518549; Wed, 14 Jan 2026 15: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 1vg2QD-0003VH-TB; Wed, 14 Jan 2026 15:04:33 +0000 Received: by outflank-mailman (input) for mailman id 1203321; Wed, 14 Jan 2026 15:04: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 1vg2QC-0003VB-58 for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 15:04:32 +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 535838c3-f15a-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 16:04:29 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-47ee301a06aso9366935e9.0 for ; Wed, 14 Jan 2026 07:04:29 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee55d42f0sm33962085e9.7.2026.01.14.07.04.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 07:04:28 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 535838c3-f15a-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768403069; x=1769007869; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Uw1mdVhhOFU9PBjxjNps+Ylka8ITQP/5h7t9ihrOMrY=; b=MFknnajAP/i9UiKUvYaWqcQcQ84vl4/BNkjSfTxTdn6SxV8qwM85H4OtgdpVe6D32i ee7J3eulIUzL7YwQS6OsB2mOJ+dUATPk0OhxyMG2u/lgDvaIvCxYgrhs0IOvkvGqPekG W8RlTgFVq6NxllVlXFuNLxQoZ7IQ2F1o2daaf6gVZ07IGIYK65LOWRrFNiua1VywsFe+ Mm85jOPsRm/0FkwmErdLr86jkEdTo6YNgoOwYuIQmjSC2oOvn9l/V4R+Xkf7cIbdHD5M GFkLQRMYbI8IZc23NkQyx0Y89wFE/ZgVY9CEIUJvuNKVwzHMYim3CTRYkQW3jFE3MVSa gPyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768403069; x=1769007869; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Uw1mdVhhOFU9PBjxjNps+Ylka8ITQP/5h7t9ihrOMrY=; b=rBleo4uoKhOlJ2uv9mbM//vEJsyXDwTEz1tAHJqOiPmrP0cczhHNo5z26nC7cNQQB+ 03J4WOETnKIvBLI/4ZwKdWqOui8dr5/6kLruKMYeiJUfhYyApOfCwZAy8eR4VRnmvR3u 4UhD5zKICvLI/c7pFsHJN+Ql3PtrHr/5GpkniSXyPkxTgwn3t3dmlw4FHAVH7F8ap/Ce IV0CRD+RR3h/15wV2FrTtCMr7DlHeEeilajHkt9VHw41G7nyhV/MGdcgNdrBR/U7r1zl fnzV6WM2VKt/8ic/hwIMgD/vUS2LzUFSUPW83Nx2cqkqg3gvffzn6Lr6n13ebW/qjcdG AS5w== X-Forwarded-Encrypted: i=1; AJvYcCU5lD3ZWg2f9Kwm0/3+Dr+1d+9eYLLNjIT+mE+6ShAYUq6mSgjHmlR8iPM0mLqJvvHSO7y6ZkFbUnA=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy1kDC0ilimIeyfM1IDBDxAEKog4FazNvDXtY9CM0nYKLYVkKCQ gdaP3PTpmkp/mzNE5tFHI6CiUPf6j1pgYYtqCvp/4swlSjW4CTzETEtxT0jDP6kdwA== X-Gm-Gg: AY/fxX49yid7kuy3nfyjPGq0H3wL8iQKJNiVqmZzocGpbexINa3TcQtpW520yzz77xi bAiSrMwQxTC+YYA75pMpCWzqri3we253zBvgYt0Al8m+A+A1XqOAbOFzGdtD9DJiCcHvsVYAuWX /z6igliKB/xKX3s8pEZfxqgHjH4WWXZJ2xPLIxq/W8B1Hgb9wqIbs33K/YnqihK/H0KT7uwPqHf YYPvLLyAqVl80Ou6T5La3GAOTpSkrxzYxxGWzpUOKKaTV7dVETQRFNDyH/3aKyav5gR3E5uPj5d D/zy2VXSv0k4RXBrD5gxfd+4Jye9IlFpbargbLfkapV+Zsy2rmq1axRaf6n/ieVZ6xLqxHvg6u8 9tgw/kBPUiSBPMA0irdkCno3CpodA9aVLPsM8DwSFnO1ypMafxaopxr6PabT+UJB9Ud5rpJ6rEO 43f5PLujk0YLjX5fhkqeDhHBUYmWGJgWAvev3I3RmNxMEIRPWFpAHF3TxkXdUZbiJDEcd5File6 WU= X-Received: by 2002:a05:600c:6992:b0:479:3a86:dc1a with SMTP id 5b1f17b1804b1-47ee33aa21amr33171555e9.36.1768403069176; Wed, 14 Jan 2026 07:04:29 -0800 (PST) Message-ID: <922c5809-8070-4ff4-9caf-d953c4ac0c2b@suse.com> Date: Wed, 14 Jan 2026 16:04:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 13/15] xen/riscv: implement reprogram_timer() using SBI 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: <43249171def325c49541ebdac141fe99d159b60f.1766595589.git.oleksii.kurochko@gmail.com> <90e7fc60-09cc-4b61-ab0a-80037f8ecaf8@gmail.com> <4141bb71-7aef-4287-aefd-92009977294f@gmail.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 14.01.2026 13:41, Oleksii Kurochko wrote: > On 1/14/26 12:17 PM, Jan Beulich wrote: >> On 14.01.2026 11:33, Oleksii Kurochko wrote: >>> On the other hand, if some >>> other negative error code is returned, it might be better to return 0 and simply >>> allow the timer programming to be retried later. >>> However, if we look at the comments for other architectures, the meaning of a >>> return value of 0 from this function is: >>> Returns 1 on success; 0 if the timeout is too soon or is in the past. >>> In that case, it becomes difficult to distinguish whether 0 was returned due to >>> an error or because the timeout was too soon or already in the past. >> Well, your problem is that neither Arm nor x86 can actually fail. Hence >> calling code isn't presently prepared for that. With panic() (and hence >> also BUG()) and domain_crash() ruled out, maybe generic infrastructure >> needs touching first (in a different way than making the function's return >> type "bool")? > > I think making the function's return still is fine and it is only question to > arch-specific reprogram_timer() what to do when an error happens. > > Still doesn't clear to me what should be a reaction on failure of > reprogram_timer(). > Considering that SBI spec doesn't specify a list of possible errors and now > the only possible error is -ENOSUPP it seems to me it is fine > to have panic() as we don't have any other mechanism to set a timer > except SBI call panic() (or BUG_ON()) is pretty drastic a measure when possibly the system could be kept alive. If is pretty certain that future SBI timer calls also aren't going to work, then I'd agree that panic()ing might be appropriate. If otoh a subsequent call might work, a less heavyweight action would seem preferable. (Welcome to the funs of relying on lower-level software.) > (except the case SSTC is supported then we can use just > supervisor timer register directly without SBI call). So maybe a good first step would be to use that extension if available? Might even think about requiring it for the time being ... Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 14 15:40:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 15:40:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203354.1518580 (Exim 4.92) (envelope-from ) id 1vg2ya-0000Ms-R3; Wed, 14 Jan 2026 15:40:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203354.1518580; Wed, 14 Jan 2026 15: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 1vg2ya-0000MO-OJ; Wed, 14 Jan 2026 15:40:04 +0000 Received: by outflank-mailman (input) for mailman id 1203354; Wed, 14 Jan 2026 15:40: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 1vg2yZ-0008RW-Gb for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 15:40:03 +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 499af745-f15f-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 16:40:00 +0100 (CET) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-b8719aeebc8so564174566b.3 for ; Wed, 14 Jan 2026 07:40:00 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a56c552sm2549735266b.68.2026.01.14.07.39.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 07:39:59 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 499af745-f15f-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768405200; x=1769010000; 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=juOoVOK9r6SjPvJOndnWvwaTG3b5iooY6F0TbDYVZ1o=; b=F2RglWTCbK4NG2EdRdpJ8QZ5UMa38LruHKIbR53+gk1F8VNPbJXLbLi0CC+rC10514 PHLOouwQpJGqaxZ7tw/rdLlNAYxRXqCmXT2XOFXOAxqCIAIbGqslnYVdvh8u3XekdTW9 fHAYi1tfGOmPGB5t184kVyNSqR4tOiWNctXXss/hVvilJbwIAWhFQyWeJ4oTgyr8AZ7+ /QUCuH42HesAc+rDP4coLUPe5jo8mmOkcW4vrr15SyqYDJmtxnoRqWWTAKB+MYQcda6l 4ay7FJk0Uur3mlE7ozFfOR8FEjsTD3Qfl7e+hIutOCG1LIM5wrW97B4fkRCtK9f2FIiT jZ8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768405200; x=1769010000; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=juOoVOK9r6SjPvJOndnWvwaTG3b5iooY6F0TbDYVZ1o=; b=dtgkUkXjgwfw964HjwSJq87k5OFLuAhdy2176qOE25Ychya5PSE4Hqj0CjOujCxOh/ QWiSlbVgT08WyhstSMR7g8ii1VKO9jkDdA+S+eEWQsZjS3DINDKcYf76JWI1pKjACQG6 TP6FO/l8tG8oFbBuq6t2cSPEtagGA8+bKDEKtk6va0doc0yGNS1H3e75R65MnRpXsUC2 F101FhrFfteH7XwguF8uxX8Irb2AtgbXUxZ3FQc9eOs8VVlBeFiS5MIN+wyNHBOCLErB O8rAlrOsmFchaozZ3daQfj1IFLnBgxjvLjQTmDE41dv4x8VsxcCdAzFZW757VKpjNObX 4Uww== X-Forwarded-Encrypted: i=1; AJvYcCUoEIm0zQOga5bkFfWl0DXwPtu9HX2RYwA/fv7DhRcaOfizv1C2EvGtfdExuMDWPn4sT5HAi/CuoOc=@lists.xenproject.org X-Gm-Message-State: AOJu0YxbgoO8r8s05NUkOOVz3wVsHF5Dn+c//kt8S7rIdJ6dVZRhE13a EtARJZC5nKSgf/bfLkYVrJN1C3+pi1Ewb1CqzDPUercu5WgeOMcxI5j+ X-Gm-Gg: AY/fxX55XFIu9kYoQ7UiLUdjVqY+jM7+leevi+SF0rRpT0WKnonP7EG1qxaGkqY2LiV G3/b1XeVgKrt7dHw41zU7VejcNkHmFZgXDGFrMwr5/uBoWjJ88i5h1m3su5C8hYUj33mFip1fJV Smx2uJMPwU3ANPlGW4Nh4I3PTwj91vuor10nDNs4oVZv98gLx71n1D0TV/LP7oudy+FFbh415PO +IPkZEvG4v22abKRlsmDjgxMfHha1i8vmInFpfCWLjXouw8rukCGDsx+8mP+QxbjOzgXFIUAzSz G3eWaw6RQWGVFFcSLr6t4dOWaJ6YlUPnU4an6vZDXZ1uHWVfgjPdFglYHEmJQkTH3OGLYfdd4jj 1l2do+8c7DAiyJPI8E79VLCsZ7tlfJXXsgpRLVT2XOMQebp9qMhimLy4yKczUaVviP4Al4rLAGu oJrDCh3LbeOLl+J7qSK3h3lgTsE4EoUOT03ABt3rRtJPvej9zp+n/4zeQsRihUPP4= X-Received: by 2002:a17:907:6e86:b0:b87:3280:6003 with SMTP id a640c23a62f3a-b87677e21c5mr178755266b.49.1768405199940; Wed, 14 Jan 2026 07:39:59 -0800 (PST) Message-ID: <7a90cc1b-b053-4b9f-91f1-d32064b1ec29@gmail.com> Date: Wed, 14 Jan 2026 16:39:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 07/15] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/13/26 2:54 PM, Jan Beulich wrote: > On 13.01.2026 13:51, Oleksii Kurochko wrote: >> On 1/7/26 5:28 PM, Jan Beulich wrote: >>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>> --- a/xen/arch/riscv/include/asm/domain.h >>>> +++ b/xen/arch/riscv/include/asm/domain.h >>>> @@ -85,6 +85,22 @@ struct arch_vcpu >>>> register_t vstval; >>>> register_t vsatp; >>>> register_t vsepc; >>>> + >>>> + /* >>>> + * VCPU interrupts >>>> + * >>>> + * We have a lockless approach for tracking pending VCPU interrupts >>>> + * implemented using atomic bitops. The irqs_pending bitmap represent >>>> + * pending interrupts whereas irqs_pending_mask represent bits changed >>>> + * in irqs_pending. >>> And hence a set immediately followed by an unset is then indistinguishable >>> from just an unset (or the other way around). >> I think it is distinguishable with the combination of irqs_pending_mask. > No. The set mask bit tells you that there was a change. But irqs_pending[] > records only the most recent set / clear. > >>> This may not be a problem, but >>> if it isn't, I think this needs explaining. Much like it is unclear why the >>> "changed" state needs tracking in the first place. >> It is needed to track which bits are changed, irqs_pending only represents >> the current state of pending interrupts.CPU might want to react to changes >> rather than the absolute state. >> >> Example: >> - If CPU 0 sets an interrupt, CPU 1 needs to notice “something changed” >> to inject it into the VCPU. >> - If CPU 0 sets and then clears the bit before CPU 1 reads it, >> irqs_pending alone shows 0, the transition is lost. > The fact there was any number of transitions is recorded in _mask[], yes, > but "the transition" was still lost if we consider the "set" in your > example in isolation. And it's not quite clear to me what's interesting > about a 0 -> 0 transition. (On x86, such a lost 0 -> 1 transition, i.e. > one followed directly by a 1 -> 0 one, would result in a "spurious > interrupt": There would be an indication that there was a lost interrupt > without there being a way to know which one it was.) IIUC, in this reply you are talking about when the contents written to the irq_pending and irqs_pending_mask bitmaps are flushed to the hardware registers. Originally, I understood your question to be about the case where vcpu_set_interrupt() is called and then vcpu_unset_interrupt() is called. I am trying to understand whether such a scenario is possible. Let’s take the vtimer as an example. vcpu_set_interrupt(t->v, IRQ_VS_TIMER) is not called again until vcpu_unset_interrupt(t->v, IRQ_VS_TIMER) and set_timer() are called in vtimer_set_timer(). The opposite situation is not possible: it cannot happen that vcpu_set_interrupt(t->v, IRQ_VS_TIMER) is called and then immediately vcpu_unset_interrupt(t->v, IRQ_VS_TIMER) is called, because vcpu_unset_interrupt() and set_timer() are only invoked when the guest has handled the timer interrupt and requested a new one. So if no interrupt flush is happening, the vcpu_set_interrupt() → vcpu_unset_interrupt() sequence will only update the irq_pending and irqs_pending_mask bitmaps, without touching the hardware registers, so no spurious interrupt will occur. And if an interrupt flush does happen, it is not possible to have a 1 -> 0 transition due to the call sequence I mentioned in the last two paragraphs above. > >> By maintaining irqs_pending_mask, you can detect “this bit changed >> recently,” even if the final state is 0. >> >> Also, having irqs_pending_mask allows to flush interrupts without lock: >> if ( ACCESS_ONCE(v->arch.irqs_pending_mask[0]) ) >> { >> mask = xchg(&v->arch.irqs_pending_mask[0], 0UL); >> val = ACCESS_ONCE(v->arch.irqs_pending[0]) & mask; >> >> *hvip &= ~mask; >> *hvip |= val; >> } >> Without it I assume that we should have spinlcok around access to irqs_pending. > Ah yes, this would indeed be a benefit. Just that it's not quite clear to > me: > > *hvip |= xchg(&v->arch.irqs_pending[0], 0UL); > > wouldn't require a lock either Because vCPU's hvip (which is stored on the stack) can't be changed concurrently and it's almost the one place in the code where vCPU->hvip is changed. Another place it is save_csrs() during context switch but it can't be called in parallel with the vcpu_sync_interrupts() (look below). > . What may be confusing me is that you put > things as if it was normal to see 1 -> 0 transitions from (virtual) > hardware, when I (with my x86 background) would expect 1 -> 0 transitions > to only occur due to software actions (End Of Interrupt), unless - see > above - something malfunctioned and an interrupt was lost. That (the 1 -> > 0 transitions) could be (guest) writes to SVIP, for example. > > Talking of which - do you really mean HVIP in the code you provided, not > VSVIP? So far I my understanding was that HVIP would be recording the > interrupts the hypervisor itself has pending (and needs to service). HVIP is correct to use here, HVIP is used to indicate virtual interrupts intended for VS-mode. And I think you confused HVIP with the HIP register which supplements the standard supervisor-level SIP register to indicate pending virtual supervisor (VS-level) interrupts and hypervisor-specific interrupts. If a guest will do "That (the 1 -> 0 transitions) could be (guest) writes to SVIP, for example." then the correspondent HVIP (and HIP as usually they are aliasis of HVIP) bits will be updated. And that is why we need vcpu_sync_interrupts() I've mentioned in one of replies and sync VSSIP: +void vcpu_sync_interrupts(struct vcpu *v) +{ + unsigned long hvip; + + /* Read current HVIP and VSIE CSRs */ + v->arch.vsie = csr_read(CSR_VSIE); + + /* Sync-up HVIP.VSSIP bit changes does by Guest */ + hvip = csr_read(CSR_HVIP); + if ( (v->arch.hvip ^ hvip) & BIT(IRQ_VS_SOFT, UL) ) + { + if ( hvip & BIT(IRQ_VS_SOFT, UL) ) + { + if ( !test_and_set_bit(IRQ_VS_SOFT, + &v->arch.irqs_pending_mask) ) + set_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); + } + else + { + if ( !test_and_set_bit(IRQ_VS_SOFT, + &v->arch.irqs_pending_mask) ) + clear_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); + } + } + + /* Sync-up AIA high interrupts */ + vcpu_aia_sync_interrupts(v); + + /* Sync-up timer CSRs */ + vtimer_sync(v); +} > >>>> Our approach is modeled around multiple producer >>>> + * and single consumer problem where the consumer is the VCPU itself. >>>> + * >>>> + * DECLARE_BITMAP() is needed here to support 64 vCPU local interrupts >>>> + * on RV32 host. >>>> + */ >>>> +#define RISCV_VCPU_NR_IRQS 64 >>>> + DECLARE_BITMAP(irqs_pending, RISCV_VCPU_NR_IRQS); >>>> + DECLARE_BITMAP(irqs_pending_mask, RISCV_VCPU_NR_IRQS); >>>> } __cacheline_aligned; >>>> >>>> struct paging_domain { >>>> @@ -123,6 +139,9 @@ static inline void update_guest_memory_policy(struct vcpu *v, >>>> >>>> static inline void arch_vcpu_block(struct vcpu *v) {} >>>> >>>> +int vcpu_set_interrupt(struct vcpu *v, const unsigned int irq); >>>> +int vcpu_unset_interrupt(struct vcpu *v, const unsigned int irq); >>> Why the const-s? >> As irq number isn't going to be changed inside these functions. > You realize though that we don't normally use const like this? This > use of qualifiers is meaningless to callers, and of limited meaning to > the function definition itself. There can be exceptions of course, when > it is important to clarify that a parameter must not change throughout > the function. > >>>> --- a/xen/arch/riscv/include/asm/riscv_encoding.h >>>> +++ b/xen/arch/riscv/include/asm/riscv_encoding.h >>>> @@ -91,6 +91,7 @@ >>>> #define IRQ_M_EXT 11 >>>> #define IRQ_S_GEXT 12 >>>> #define IRQ_PMU_OVF 13 >>>> +#define IRQ_LOCAL_MAX (IRQ_PMU_OVF + 1) >>> MAX together with "+ 1" looks wrong. What is 14 (which, when MAX is 14, >>> must be a valid interrupt)? Or if 14 isn't a valid interrupt, please use >>> NR or NUM. >> I didn’t fully understand your idea. Are you suggesting having|IRQ_LOCAL_NR|? >> That sounds unclear, as it’s not obvious what it would represent. >> Using|MAX_HART| seems better, since it represents the maximum number allowed >> for a local interrupt. Any IRQ below that value is considered local, while >> values above it are implementation-specific interrupts. > Not quite. If you say "max", anything below _or equal_ that value is > valid / covered. When you say "num", anything below that value is > valid / covered. That is, "max" is inclusive for the upper bound of > the range, while "num" is exclusive. Hence my question whether 14 is > a valid local interrupt. 14 is architecturally classified as a local interrupt, but its specific function is currently reserved. Intention was to cover standard portion (bits 15:0) of sip for which bits 15 and 14 are 0 as they are reserved, so it seems like NUM could be used here. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Jan 14 15:53:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 15:53:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203379.1518590 (Exim 4.92) (envelope-from ) id 1vg3BY-0002LT-Va; Wed, 14 Jan 2026 15:53:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203379.1518590; Wed, 14 Jan 2026 15:53:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg3BY-0002LM-Sj; Wed, 14 Jan 2026 15:53:28 +0000 Received: by outflank-mailman (input) for mailman id 1203379; Wed, 14 Jan 2026 15:53:27 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg3BX-0002Ky-Pv for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 15:53:27 +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 29a2e914-f161-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 16:53:26 +0100 (CET) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-b87124c6295so552126366b.3 for ; Wed, 14 Jan 2026 07:53:26 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a5641casm2669242666b.64.2026.01.14.07.53.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 07:53:25 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 29a2e914-f161-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768406006; x=1769010806; 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=/elI78rHTIFfPYXOwGaxs777CQdiDc2ax5tIcwgj7aA=; b=nVQWXQhNfO1zm/duhmFm2gIwJHMf1QKjvIaRFw7Re1ScFqsdp/zmQ51z1NWO1NAJvl yzQTFFyzXNUxPVZZAFW/PizikPiHfU8vep7GEPb64tYldwJMMMtXa783oHZNHN5/pyY0 NVVZvXrGAyNYH3d43tnRVY3+y5tJRl2Y8nWOR2z4z+h/QJwvVsOLoKWM3oCrWfAFZ09v HlrS1tdwH7PSOm1lLV2FcudmAlcdWvKKp/S9ipCCYI6xgPfc6+za7ikZeelYG3XtbUpc Ad7NwHYGx99SCi+4RWUHys36KZmPKxCl7NqQ87Uqw2LqACqFx3pV+s66MY8cfKd1yR4d JoNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768406006; x=1769010806; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/elI78rHTIFfPYXOwGaxs777CQdiDc2ax5tIcwgj7aA=; b=Rxe2o9ILJ2ZU6QCcAwawRiSDgFXWDWqJiSexu/XVnBAgbhT1xgNNNIR7YBopDjF7l6 F5/qhHe8NdKpUhDeRkqHHmMebEsxJ56WyD77Rpwo9nJR5pnA4DRgOrCF17M5U3EFhEUk 5O2Mq14ieM0RJZ7mt7Jj9U8qnzC4Fav1rgK+c1UKmHT4x8bpjI+k8LV9cpiMRpYtWVhc tFB/HorSNTW+4pd1oxMnqO/EzBVwsgvDpyBHOXvmGEyFc39g53LUNN3xL2pw75vRpp6C dCELLgJCA1cTNx73AdaaAaAM5PfUoeqi2Lfg5osJLag56uLGTkGw7aKCPE/baOaJ7ERZ 0Nbg== X-Forwarded-Encrypted: i=1; AJvYcCUYHx2baTOlpwoFcXH4Fe/d9HB+y6m//LIW3hCdzTeulozTKdOuU1BTeEoXqYdwiDE+nrq9sjCM2V4=@lists.xenproject.org X-Gm-Message-State: AOJu0YxKogO+Guo590z6UOYBLVtMcoEVUkC/zxTYsNpGN8GURYaUOS5S /td2KbygFMLrTUvnc9zd0LL6T5R7rmCNtIPZZFsgp8jB7pVb8Gt08A6e X-Gm-Gg: AY/fxX6DZhQKAO4CePNcYgJFT9o6yw99Eg+qBKFPWomEAcBWfBV/dlQ7Rvpg61SRdgk Ihw5A5+leMl7d5N9MUp79GaawJif4iZpOY7T2724SLzgWzETTCzZWtAu24mH3Qu4LloLeW5i4D8 eEcJ2lBw46bzQ8Q0XA9PgM9ANlKjeQnyKQHqp8DUzv8KFu6bFIFdFZz+turLcaPBRuvaeKdSVOs SGn1Frwfc14xV9Z73Djx0qoH9pbpD6iWnDnYH1f1pD2mOGuLPxyEFX+f/UExxBsLMv8mOWDQ/BG rsI1Q1y0Z3fbZGF79cI0ejGLFwXFBd1aB+79rgm1Icu4g2IeEGRt3/P/7rPqh9dTi8OUuuozM+8 H2MeCFH5xwi2+KvkXy73B3NJ2GKDVWfhg5qmVAhUHaYMwoenBbrz6Nw9DJDmG8YCvbG+yWgtJM3 noWuQUiI7UXqKkxXfjUgW/EXhGHexvaGsBLArD659xQc3JxMBHPQFlq9B44rzr2i7zehlO8vBLF 5YypQ== X-Received: by 2002:a17:907:97c6:b0:b80:3447:e0c0 with SMTP id a640c23a62f3a-b876141f2b0mr286287666b.62.1768406005456; Wed, 14 Jan 2026 07:53:25 -0800 (PST) Message-ID: <948f83bd-60aa-4ed2-b9e7-fd0e410fa1b9@gmail.com> Date: Wed, 14 Jan 2026 16:53:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 13/15] xen/riscv: implement reprogram_timer() using SBI 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: <43249171def325c49541ebdac141fe99d159b60f.1766595589.git.oleksii.kurochko@gmail.com> <90e7fc60-09cc-4b61-ab0a-80037f8ecaf8@gmail.com> <4141bb71-7aef-4287-aefd-92009977294f@gmail.com> <922c5809-8070-4ff4-9caf-d953c4ac0c2b@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <922c5809-8070-4ff4-9caf-d953c4ac0c2b@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/14/26 4:04 PM, Jan Beulich wrote: > On 14.01.2026 13:41, Oleksii Kurochko wrote: >> On 1/14/26 12:17 PM, Jan Beulich wrote: >>> On 14.01.2026 11:33, Oleksii Kurochko wrote: >>>> On the other hand, if some >>>> other negative error code is returned, it might be better to return 0 and simply >>>> allow the timer programming to be retried later. >>>> However, if we look at the comments for other architectures, the meaning of a >>>> return value of 0 from this function is: >>>> Returns 1 on success; 0 if the timeout is too soon or is in the past. >>>> In that case, it becomes difficult to distinguish whether 0 was returned due to >>>> an error or because the timeout was too soon or already in the past. >>> Well, your problem is that neither Arm nor x86 can actually fail. Hence >>> calling code isn't presently prepared for that. With panic() (and hence >>> also BUG()) and domain_crash() ruled out, maybe generic infrastructure >>> needs touching first (in a different way than making the function's return >>> type "bool")? >> I think making the function's return still is fine and it is only question to >> arch-specific reprogram_timer() what to do when an error happens. >> >> Still doesn't clear to me what should be a reaction on failure of >> reprogram_timer(). >> Considering that SBI spec doesn't specify a list of possible errors and now >> the only possible error is -ENOSUPP it seems to me it is fine >> to have panic() as we don't have any other mechanism to set a timer >> except SBI call > panic() (or BUG_ON()) is pretty drastic a measure when possibly the system > could be kept alive. If is pretty certain that future SBI timer calls also > aren't going to work, then I'd agree that panic()ing might be appropriate. > If otoh a subsequent call might work, a less heavyweight action would seem > preferable. (Welcome to the funs of relying on lower-level software.) I don’t know how OpenSBI will be updated in the future, but looking at the current situation, since SBI timer calls have existed from very early OpenSBI versions up to the latest ones, repeatedly issuing the SBI timer call will always return the same negative error code indicating that the timer call is not supported. I can add a comment above panic(), or include an explanation in the commit message. > >> (except the case SSTC is supported then we can use just >> supervisor timer register directly without SBI call). > So maybe a good first step would be to use that extension if available? > Might even think about requiring it for the time being ... I initially started working on SSTC support, but then stopped because an almost production-ready board to which I do have indirect access does not support this extension. As a result, I decided to proceed with SBI approach as it covers both cases when SSTC is available and when no. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Jan 14 15:55:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 15:55:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203387.1518600 (Exim 4.92) (envelope-from ) id 1vg3Dv-0002ss-Af; Wed, 14 Jan 2026 15:55:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203387.1518600; Wed, 14 Jan 2026 15:55: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 1vg3Dv-0002sl-7e; Wed, 14 Jan 2026 15:55:55 +0000 Received: by outflank-mailman (input) for mailman id 1203387; Wed, 14 Jan 2026 15:55: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 1vg3Dt-0002sf-4p for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 15:55:53 +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 79a613a8-f161-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 16:55:42 +0100 (CET) Received: from PH8PR07CA0001.namprd07.prod.outlook.com (2603:10b6:510:2cd::26) by IA1PR12MB9030.namprd12.prod.outlook.com (2603:10b6:208:3f2::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Wed, 14 Jan 2026 15:55:30 +0000 Received: from SJ1PEPF000023D3.namprd21.prod.outlook.com (2603:10b6:510:2cd:cafe::4) by PH8PR07CA0001.outlook.office365.com (2603:10b6:510:2cd::26) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.4 via Frontend Transport; Wed, 14 Jan 2026 15:55:29 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ1PEPF000023D3.mail.protection.outlook.com (10.167.244.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.0 via Frontend Transport; Wed, 14 Jan 2026 15:55:29 +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; Wed, 14 Jan 2026 09:55:29 -0600 Received: from [10.71.192.102] (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, 14 Jan 2026 09:55:27 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 79a613a8-f161-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=WkDp0Ulu0YElK+9fRp4ujMWFvtvgeuI9cC6bsJU/6C4sWmtMBK2BgdH71i2ewm+VdV88mrrY6yQHzwNp9oySRtXeZhVO2jQsoDzhkubP/bamd3fZ2OrNSw9z1Y90kbCpIcq0EIZw9PnJ3XMa9vOX2MJqxwexh+AAvHOIpyWGxCVmPzvrNZHhd5uwr5blPMKW1Wr+nttJMDZb6ayBf764EVxxGo871QffvLpkVeOyk37wHrXRfOO8/TaWrloiquflXDz0sEoemEpz8VR5mUQi03MnJU+0+q1hRgBnQ2HErUw9Ss/nmwglcAWJ7WuLJOmULYVu6MlMAuB5s9xbbZ4N1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1CnlhtRyB3A1U7H1J3lVb0lcSHBAMx5OHvUHpMWtq3I=; b=Ynttu8Utd9DiLbm235LNyPfJLSqMpbVAwRdjny1PePc2HtpmwLHHz8fpmnBMZP9bv2iB2rm7zDW9ymJ5HEVW/2fKNJS3ThNpQDYVJIVpD/NuCMUzSJk3MMobPr0Eieg9TWpNtuw4N0kMyeYOm2c1Ir0LBQNYe8ilo0mI7ED14vHTtNU1R1SkNk7S86WnK8thVmgusslpTl2RlijsoUcIRXPEadYQPOThPe3l9pyhSjBnxMjQmDg49hEjpKRM7YN7BhOSxYmi2LCrPNnIKzZpK9zYxTOe7roZCbACTIgkw81HAD951j2xMrqLDSxdvTP4jXplBLjl6tfBkfFjd4d7xQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1CnlhtRyB3A1U7H1J3lVb0lcSHBAMx5OHvUHpMWtq3I=; b=3sV6ChJzji+CCnvQk9MIxVhGAd2Jh8vL8YJqE7kR+kVRNxszhMpBXjmo2DqEgIQ8ZHL5Mniuso35ClJagrAhHmRgEcNrLsqYTAgBya+CX4dlZU1H4YByWEy8tBIHbAkGAC8GLitEgVnBDc6CbRKWIONj0pWSo82p3Rv7szccR8U= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: Date: Wed, 14 Jan 2026 15:55:27 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 6/6] arm/mpu: Map domain page in AArch64 MPU systems To: Harry Ramsey , CC: , Penny Zheng , "Stefano Stabellini" , Julien Grall , "Bertrand Marquis" , Michal Orzel , Volodymyr Babchuk , Wei Chen References: <20260114142734.239197-1-harry.ramsey@arm.com> <20260114142734.239197-7-harry.ramsey@arm.com> Content-Language: en-US From: "Halder, Ayan Kumar" In-Reply-To: <20260114142734.239197-7-harry.ramsey@arm.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF000023D3:EE_|IA1PR12MB9030:EE_ X-MS-Office365-Filtering-Correlation-Id: c2fcc6b3-94aa-41be-d547-08de538557b6 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?dlBMMlpRTVVmWGIxZmdrU1BOTWhkV0REbGJHZWdyTXdYVEw5ZmNYSXJpWUFK?= =?utf-8?B?aTJUbDViNkVVQ3J2N0hQanR1WkJQQ3o0aUhzdDlIKy9HWE9LSEJvWlMrRXNk?= =?utf-8?B?cFQ2cnJSYjZIVm1peFl0ZUNrdmxhckpOVnBvdG8reFFwaVhMejhBWVE0a0M1?= =?utf-8?B?dGF0b1FFNG5sdkN6cEQvVENvYXpuVTYvOGVaZEl4enltT05DSm5aM0lzODNk?= =?utf-8?B?TlRWS3I5N3NJSkNFUTgwWmxPdG8yV3dVY0pBYkE4RklZYVNWZkIwblYydTEr?= =?utf-8?B?YXVkSmJZTlRaWWw0RkplTTdtd1U2WTlyRXRNUHJ6aVRFMlhuZlFiUkV6UzF0?= =?utf-8?B?bjl6Z0FOejE2SmJrWUxISzNreExoTnBvaUNUYS8wWGVKUENqcVdyRm5iLzYz?= =?utf-8?B?UXdnRDVSeTB3bk50eFZZbzhMOVduZkV0R2JlN29ZY240cDZPWW9KUkV5RnNF?= =?utf-8?B?aUw0dFVxL2U0a2ZMU1Vrd05EcUV5L2NwOFZ4MUNSN3A4dHVtdzVYWTJLNGp5?= =?utf-8?B?My82cGFBd2Y3aE41cXU5ejdHNXVROHhDMXZQeHVkamMvY0c1NjU5cCsvMitZ?= =?utf-8?B?TDRoblVTcmFVcDFQMHd4NUJnT3RMNVlKSTRvdEliUmZyQ2FNcllIUXJwZG9x?= =?utf-8?B?K3F5YzhyeFc5V3JvcTNxTmlGMnEyNEdiWmpqekhFdkxnVXRMaFAwRTlkM1lq?= =?utf-8?B?R2hxYkpDbFdmcnc2QkZJQXFyeTlUUjlzK3RwaVl4Z09LbkZXK1Y4YVpWaUVD?= =?utf-8?B?ZUlzLzlsa0daWWRNVHNSaUFiUUR2QmVDRVU2WDZiOXpHY0d4QUwvQnhjV2F2?= =?utf-8?B?VXBvN0hTL2JLdkpXOXhxNXpEeUtqUzNiaU1kTElMWDRORFd1R2RzV2JvNVRN?= =?utf-8?B?bzBCelRBdXFVWWVuRXJxSHM5YXJ5ODVnM1BYWEs0NEY1SzFOdGVZQVRPNzRz?= =?utf-8?B?QngxT2pOUTBHaTFLSmo5ZnY2dk9zbFdGMkxWWEFKNG9IcUdJZWx1YXRCc3BT?= =?utf-8?B?MUJpaUM0aFBHZkl6eUFGa0M2U3RCVDhNSjBiR0E5K0NhVzUrR3E2d1BNbm9s?= =?utf-8?B?ZW5Qclp4ZkVtNHJGNU4yVGNrMlByWHU1allqaGtaeGllTDhmMFNOd3dxVnd1?= =?utf-8?B?ZzZRR2YyTFhkU2tkODF3eEkyM0RKb0MyVHVJVWNVTkFIYjlJeEs2VFMvUmRZ?= =?utf-8?B?V3UxMXFHMWQ3ejBQdzNOdjVQeW1GUitmWHhoeXdnYXdNNFhPb2xJWGhPeHBH?= =?utf-8?B?NGN3dlRDVzJjbzFiUnBPd0tJTEN3OEhDZ1U2WktZa3JOQ1FGaUltK2s3SXEr?= =?utf-8?B?ZU0wYm9xNXZwYzJoWkV1R1ppVjFTdkNQaHNacFNlZ1BNQUhrdU1uRnNBeWRJ?= =?utf-8?B?ck56UVlEWFBvbjc3YS9RK2IxYUpjSUpkV0FzaWJDdkJaeWphdlN4WXRpUUFH?= =?utf-8?B?YXhJb3hJRlA5UG9hRXlvU0lmSEgzYVF6WWJlWGsxL0E2WVoyR0hKbUJSUnEx?= =?utf-8?B?OWo4SkJQaWpVaDlsbUhQK0ZXMmRwdWJtazVUN2ZHdEFpRHM1OTJMZW82dWNZ?= =?utf-8?B?OHNBbGRTVnY2VmpsU1BhRS92V2RBTzFISHcxelU5SmRNR01qN1lUV0RvM1Nm?= =?utf-8?B?NW8wdW11ZExiNk1sL1NPdUF2K3ZJMmh6NDZUM2NvT1FJVEs5L1IxcUdhN25S?= =?utf-8?B?NjFJYzdMdXdDaUpzcmNkRkFETlk2MEhjODdabXkxc2dLTzJSZUdIQ21lK1ky?= =?utf-8?B?LzZhMHNtM3JZUkd0VzZVMHpYbitiajVMbEJ1T3pKWDJqY0MxMlBWL0lnTldI?= =?utf-8?B?RUdYU3Rja2VKL0RzSXRoYUZwdndKekluUnVjaDBMZmE0S2NOMGFHRUx6S3Rj?= =?utf-8?B?Mng3NlNHZmtaK2txV3JSQU12VGVkcDhRMnpWMU9qQXNVUll3cmE3c0NzY29x?= =?utf-8?B?d3VMaDNuejgrUnEzOW9JaElVdzJONTg4d1grUG55d3RoZVRoc2lvUFA3c3J4?= =?utf-8?B?UU5IK1E0T3Z0WitZdjFOR1dIcXQ3Mm1rNU9CczluQUlJRjJPSS94azJlRVpy?= =?utf-8?B?SjZVb2FvS1lHSWNkMWI5TnoyODlKcysvaUdhRzR4bW5sWkRDNHplcVk0ekpo?= =?utf-8?B?SkFneHFxaDh5K3Q2cW93T2o4OVI5WkhYMHNSSmozSWs5OXdiVWtmbFExd2pz?= =?utf-8?B?dWpyM2VTU2o5dEVoYkJCR0g4K3l0cTBIUnRMTFRvanphSm1VRkFxOXljb01Z?= =?utf-8?B?RFF4Ym96TEdLb2lKbWx5d3hoZk9nPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(376014)(36860700013)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2026 15:55:29.9194 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c2fcc6b3-94aa-41be-d547-08de538557b6 X-MS-Exchange-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: SJ1PEPF000023D3.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB9030 Hi Harry, Can we expand this to cover Arm32 as well ? I did some test and both Arm32 and Arm64 get to the same point. On 14/01/2026 14:27, Harry Ramsey wrote: > From: Penny Zheng > > In MPU systems, we implement map_domain_page()/unmap_domain_page() > through mapping the domain page with a MPU region on demand. > > Signed-off-by: Penny Zheng > Signed-off-by: Wei Chen > Signed-off-by: Luca Fancellu > Signed-off-by: Harry Ramsey > --- > v4: > - Remove duplicate code by having `map_domain_page` and > `unmap_domain_page` use `vmap_contig` and `vunmap` > v3: > - No changes > v2: > - No changes > --- > xen/arch/arm/Kconfig | 1 + > xen/arch/arm/mpu/Makefile | 1 + > xen/arch/arm/mpu/domain-page.c | 46 ++++++++++++++++++++++++++++++++++ > 3 files changed, 48 insertions(+) > create mode 100644 xen/arch/arm/mpu/domain-page.c > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig > index cf6af68299..baa6c4cf15 100644 > --- a/xen/arch/arm/Kconfig > +++ b/xen/arch/arm/Kconfig > @@ -91,6 +91,7 @@ config MMU > > config MPU > bool "MPU" if UNSUPPORTED > + select ARCH_MAP_DOMAIN_PAGE if ARM_64 Remove ARM_64 > select STATIC_MEMORY > help > Memory Protection Unit (MPU). Select if you plan to run Xen on ARMv8-R > diff --git a/xen/arch/arm/mpu/Makefile b/xen/arch/arm/mpu/Makefile > index 4963c8b550..940297af3f 100644 > --- a/xen/arch/arm/mpu/Makefile > +++ b/xen/arch/arm/mpu/Makefile > @@ -1,5 +1,6 @@ > obj-$(CONFIG_ARM_32) += arm32/ > obj-$(CONFIG_ARM_64) += arm64/ > +obj-$(CONFIG_ARM_64) += domain-page.o obj-y += domain-page.o > obj-y += mm.o > obj-y += p2m.o > obj-y += setup.init.o > diff --git a/xen/arch/arm/mpu/domain-page.c b/xen/arch/arm/mpu/domain-page.c > new file mode 100644 > index 0000000000..b79afc493b > --- /dev/null > +++ b/xen/arch/arm/mpu/domain-page.c > @@ -0,0 +1,46 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +void *map_domain_page_global(mfn_t mfn) > +{ > + BUG_ON("unimplemented"); > + return NULL; > +} > + > +/* Map a page of domheap memory */ > +void *map_domain_page(mfn_t mfn) > +{ > + return vmap_contig(mfn, 1); > +} > + > +/* Release a mapping taken with map_domain_page() */ > +void unmap_domain_page(const void *ptr) > +{ > + vunmap(ptr); > +} > + > +mfn_t domain_page_map_to_mfn(const void *ptr) > +{ > + BUG_ON("unimplemented"); > + return INVALID_MFN; > +} > + > +void unmap_domain_page_global(const void *va) > +{ > + BUG_ON("unimplemented"); > +} > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * indent-tabs-mode: nil > + * End: > + */ The rest LGTM. With this, one can see R52 booting to the same level as R82. (XEN) load tracking window length 1073741824 ns (XEN) Allocated console ring of 16 KiB. (XEN) VFP implementer 0x41 architecture 3 part 0x40 variant 0x2 rev 0x3 (XEN) CPU0: Guest atomics will try 1 times before pausing the domain (XEN) Brought up 1 CPUs (XEN) Xen BUG at arch/arm/arm32/mpu/p2m.c:9 - Ayan From xen-devel-bounces@lists.xenproject.org Wed Jan 14 15:56:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 15:56:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203388.1518609 (Exim 4.92) (envelope-from ) id 1vg3E7-0003BR-MN; Wed, 14 Jan 2026 15:56:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203388.1518609; Wed, 14 Jan 2026 15: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 1vg3E7-0003BK-JD; Wed, 14 Jan 2026 15:56:07 +0000 Received: by outflank-mailman (input) for mailman id 1203388; Wed, 14 Jan 2026 15: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 1vg3E6-0002sf-KY for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 15:56: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 87e24e71-f161-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 16:56:04 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-477a2ab455fso81965915e9.3 for ; Wed, 14 Jan 2026 07:56:04 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee117e607sm25736935e9.3.2026.01.14.07.56.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 07:56:03 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 87e24e71-f161-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768406164; x=1769010964; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Sq0HkgowQW0ezh21tXvT7v+YFZV0uMQYL63s9WUWcq4=; b=VvRQzvaYOmJMupQoD4yXFHvf+q0E9QF5NP2U3XSx0cB4b130pQ+Mq851MzfM7rqTfa phqbPdi+KSsmRqDkiUfW2Vxfo+ZlUWJOZuqRZaRRKIskdiJ/G59v6jmXb1lmOWejuB3J fbADNzGKkVh5t/h+AorqWosTl06y3OrwSRwxbWp61E2XHpOygcBGhIoVPXyufMl4j3Vn JDuSd9d/j0boEtjKYYph19madxX8BeTPBwA01Nw1jNPorI2ZDJma4JhpRJ8QtdFPkz/p Otj8zyAWYRnL7xcY2boIrfKXzR1MYj7NukooGVfHNcOytFToJJ1sDnROYq0c8fGqGQ24 WsLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768406164; x=1769010964; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Sq0HkgowQW0ezh21tXvT7v+YFZV0uMQYL63s9WUWcq4=; b=dL8jEOwlP2FnJ11jR0BqledK5DgVW9Sk9i0+g3HM/rkrvgTtwNVIogH/qie6wQL/5z mXv7Tp2LIEil13mnIh8/jQWI9ZcQp9pXEXkvw2Aak298XE1XPSRM8gseNMYMC9PP86Ah n7sMmueCBMlDFxQU8T4qpETzY2nJh/4dYV/4vNI3KxWtgYqX+xZ+M24P+e8Z9pHQo7qT 5z4v6YKg7mBb1Wupd7itr8uKEd0ZNLZv2xaUXk3tuwSkxJgFbkcT5ouSqhQGUMx8BicF tw8bpI/xr2l/ZCACEKXmODRoVYmlP9nUU7m5hTkruF63NtHnrqgyHODrtN9u73kfONPv Tssg== X-Forwarded-Encrypted: i=1; AJvYcCUJp7DeeRK6XhofktTpIPls7603YuOi/3P6El+n7g81aqqFIPEhtphF9AkLH29JEj/sKyuSLtSgaX8=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz1H+5l6qAQandE03Z2yxl3ISHgc9dFDL5pWCSWkXJyx+3QqO23 WGa9macnPz/xWvFxSsmPCkKW685jX6UteGSmhCCEYRfBdbOU+T/C2WQ/REyErZdFHg== X-Gm-Gg: AY/fxX4j1EbzJSLNnW+p2YIuErmQqCPcIq72uTbv4/7oqwR8iV6yAQ0fPL2ydoJAaK8 uMIhrED5osnhZ65riI5srMc6MQzydLUMZQhukCz0jaY0Y+jkxtnc4bIMRTx77shlBi0Uv1C/iqe 9s0esRSCqGwKtV5gQKhL3g/9U5Hut2DZVoqQXGQE2raJaFmSIMDv9w9KgH+E4Q+TtH4mfwlceF9 dmtF19wXHm2tmuJC7VHbBip1G45/mJNfe6gixv5yzmhKfHRlz3QxRxxUXyA+EhPtgv/S2KV86Uh FHn0xjCsWCMnj013DVpAOP9pSf7tN7lXIoi3I7KYttA4pZgL/AlnpWWDoWC4htOol/LUHOPHhka eo5XeKDF00jPygXyr92TWCl62DJJ1TCRdKxDPLZboWVUBZQb7IL+D/+TjfxXgVi5X4wLafkNFol wJaKV/wAFijxg3fD9vaAoi/s+MfMYKFKEeIBm7ueXF94tYcRBC/0JshXsw3HyPNCvQtQaz8Dc2O n0= X-Received: by 2002:a05:600c:1549:b0:47e:e946:3a72 with SMTP id 5b1f17b1804b1-47ee9816cafmr9058165e9.27.1768406163563; Wed, 14 Jan 2026 07:56:03 -0800 (PST) Message-ID: Date: Wed, 14 Jan 2026 16:56:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 07/15] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <7a90cc1b-b053-4b9f-91f1-d32064b1ec29@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: <7a90cc1b-b053-4b9f-91f1-d32064b1ec29@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 14.01.2026 16:39, Oleksii Kurochko wrote: > On 1/13/26 2:54 PM, Jan Beulich wrote: >> On 13.01.2026 13:51, Oleksii Kurochko wrote: >>> On 1/7/26 5:28 PM, Jan Beulich wrote: >>>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>>> --- a/xen/arch/riscv/include/asm/domain.h >>>>> +++ b/xen/arch/riscv/include/asm/domain.h >>>>> @@ -85,6 +85,22 @@ struct arch_vcpu >>>>> register_t vstval; >>>>> register_t vsatp; >>>>> register_t vsepc; >>>>> + >>>>> + /* >>>>> + * VCPU interrupts >>>>> + * >>>>> + * We have a lockless approach for tracking pending VCPU interrupts >>>>> + * implemented using atomic bitops. The irqs_pending bitmap represent >>>>> + * pending interrupts whereas irqs_pending_mask represent bits changed >>>>> + * in irqs_pending. >>>> And hence a set immediately followed by an unset is then indistinguishable >>>> from just an unset (or the other way around). >>> I think it is distinguishable with the combination of irqs_pending_mask. >> No. The set mask bit tells you that there was a change. But irqs_pending[] >> records only the most recent set / clear. >> >>>> This may not be a problem, but >>>> if it isn't, I think this needs explaining. Much like it is unclear why the >>>> "changed" state needs tracking in the first place. >>> It is needed to track which bits are changed, irqs_pending only represents >>> the current state of pending interrupts.CPU might want to react to changes >>> rather than the absolute state. >>> >>> Example: >>> - If CPU 0 sets an interrupt, CPU 1 needs to notice “something changed” >>> to inject it into the VCPU. >>> - If CPU 0 sets and then clears the bit before CPU 1 reads it, >>> irqs_pending alone shows 0, the transition is lost. >> The fact there was any number of transitions is recorded in _mask[], yes, >> but "the transition" was still lost if we consider the "set" in your >> example in isolation. And it's not quite clear to me what's interesting >> about a 0 -> 0 transition. (On x86, such a lost 0 -> 1 transition, i.e. >> one followed directly by a 1 -> 0 one, would result in a "spurious >> interrupt": There would be an indication that there was a lost interrupt >> without there being a way to know which one it was.) > > IIUC, in this reply you are talking about when the contents written to the > irq_pending and irqs_pending_mask bitmaps are flushed to the hardware > registers. > > Originally, I understood your question to be about the case where > vcpu_set_interrupt() is called and then vcpu_unset_interrupt() is called. I was actually asking in more abstract terms. And I was assuming there would be pretty direct ways for the guest to have vcpu_{,un}set_interrupt() invoked. Looks like ... > I am trying to understand whether such a scenario is possible. > > Let’s take the vtimer as an example. vcpu_set_interrupt(t->v, IRQ_VS_TIMER) > is not called again until vcpu_unset_interrupt(t->v, IRQ_VS_TIMER) and > set_timer() are called in vtimer_set_timer(). > > The opposite situation is not possible: it cannot happen that > vcpu_set_interrupt(t->v, IRQ_VS_TIMER) is called and then immediately > vcpu_unset_interrupt(t->v, IRQ_VS_TIMER) is called, because > vcpu_unset_interrupt() and set_timer() are only invoked when the guest > has handled the timer interrupt and requested a new one. > > So if no interrupt flush is happening, the vcpu_set_interrupt() → > vcpu_unset_interrupt() sequence will only update the irq_pending and > irqs_pending_mask bitmaps, without touching the hardware registers, > so no spurious interrupt will occur. And if an interrupt flush does > happen, it is not possible to have a 1 -> 0 transition due to the call > sequence I mentioned in the last two paragraphs above. ... that wasn't a correct assumption. (Partly attributed to the patch series leaving out a number of relevant things, which makes it hard to guess what else is left out.) >>> By maintaining irqs_pending_mask, you can detect “this bit changed >>> recently,” even if the final state is 0. >>> >>> Also, having irqs_pending_mask allows to flush interrupts without lock: >>> if ( ACCESS_ONCE(v->arch.irqs_pending_mask[0]) ) >>> { >>> mask = xchg(&v->arch.irqs_pending_mask[0], 0UL); >>> val = ACCESS_ONCE(v->arch.irqs_pending[0]) & mask; >>> >>> *hvip &= ~mask; >>> *hvip |= val; >>> } >>> Without it I assume that we should have spinlcok around access to irqs_pending. >> Ah yes, this would indeed be a benefit. Just that it's not quite clear to >> me: >> >> *hvip |= xchg(&v->arch.irqs_pending[0], 0UL); >> >> wouldn't require a lock either > > Because vCPU's hvip (which is stored on the stack) can't be changed concurrently > and it's almost the one place in the code where vCPU->hvip is changed. Another > place it is save_csrs() during context switch but it can't be called in parallel > with the vcpu_sync_interrupts() (look below). > >> . What may be confusing me is that you put >> things as if it was normal to see 1 -> 0 transitions from (virtual) >> hardware, when I (with my x86 background) would expect 1 -> 0 transitions >> to only occur due to software actions (End Of Interrupt), unless - see >> above - something malfunctioned and an interrupt was lost. That (the 1 -> >> 0 transitions) could be (guest) writes to SVIP, for example. >> >> Talking of which - do you really mean HVIP in the code you provided, not >> VSVIP? So far I my understanding was that HVIP would be recording the >> interrupts the hypervisor itself has pending (and needs to service). > > HVIP is correct to use here, HVIP is used to indicate virtual interrupts > intended for VS-mode. And I think you confused HVIP with the HIP register > which supplements the standard supervisor-level SIP register to indicate > pending virtual supervisor (VS-level) interrupts and hypervisor-specific > interrupts. > > If a guest will do "That (the 1 -> 0 transitions) could be (guest) writes > to SVIP, for example." then the correspondent HVIP (and HIP as usually > they are aliasis of HVIP) bits will be updated. And that is why we need > vcpu_sync_interrupts() I've mentioned in one of replies and sync VSSIP: > +void vcpu_sync_interrupts(struct vcpu *v) > +{ > + unsigned long hvip; > + > + /* Read current HVIP and VSIE CSRs */ > + v->arch.vsie = csr_read(CSR_VSIE); > + > + /* Sync-up HVIP.VSSIP bit changes does by Guest */ > + hvip = csr_read(CSR_HVIP); > + if ( (v->arch.hvip ^ hvip) & BIT(IRQ_VS_SOFT, UL) ) > + { > + if ( hvip & BIT(IRQ_VS_SOFT, UL) ) > + { > + if ( !test_and_set_bit(IRQ_VS_SOFT, > + &v->arch.irqs_pending_mask) ) > + set_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); > + } > + else > + { > + if ( !test_and_set_bit(IRQ_VS_SOFT, > + &v->arch.irqs_pending_mask) ) > + clear_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); > + } > + } I fear I don't understand this at all. Why would the guest having set a pending bit not result in the IRQ to be marked pending? You can't know whether that guest write happened before or after you last touched .irqs_pending{,mask}[]? Yet that pair of bit arrays is supposed to be tracking the most recent update (according to how I understood earlier explanations of yours). As an aside - the !test_and_set_bit() can be pulled out, to the outermost if(). Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 14 15:59:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 15:59:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203413.1518619 (Exim 4.92) (envelope-from ) id 1vg3HA-00049c-2y; Wed, 14 Jan 2026 15:59:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203413.1518619; Wed, 14 Jan 2026 15: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 1vg3HA-00049V-0S; Wed, 14 Jan 2026 15:59:16 +0000 Received: by outflank-mailman (input) for mailman id 1203413; Wed, 14 Jan 2026 15:59: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 1vg3H9-00049P-9W for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 15:59:15 +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 f8e9e92c-f161-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 16:59:14 +0100 (CET) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-64b9230f564so12180845a12.1 for ; Wed, 14 Jan 2026 07:59:14 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a4d1c61sm2469987666b.35.2026.01.14.07.59.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 07:59:12 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f8e9e92c-f161-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768406353; x=1769011153; 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=qKbThPh0tf72AZBKPTHvdSbHsKetHCjfioS2zydJe/k=; b=a7IDoZ6kD95ehFMLUTlKaQSlsu447n8T4uuN8CkHWAacm+xZId6Xt0ytymZK1Ob80t ZssPiGIEftNKL0bbyr3mscpvw4eJxOjAs0pZGlBk3cx/cACIA13eoxv6N2AjnFfDozj1 SqC4uKB/iUqAzPzV1TQzpZh3/vB7mI3UwLROQOAGEokrA5xnJ3bRSZFcd2/KAscvWygK NhxvL3K0N5EwEiX9K7GaxLf2JqpEwaalk39m2Ush50uRIx3C0eUKoloVLJtF9PDFuESX XjVFsiVmO7C0qwV1sYwvz0cqsqxvjSt6bPZf2PkH5ilL4N06u6N+EEzKsKb0L279PrnJ mvdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768406353; x=1769011153; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qKbThPh0tf72AZBKPTHvdSbHsKetHCjfioS2zydJe/k=; b=Y87rdoFiFd2Lj+eS3WpAQX17et5i41l00FlLcdoWFGsNk3UF1ueaMau6mTDYHuoOoM Of4jBwkxsrw0OnXQUbklj/gUC0vSYDpif70V7x6Gid/PSQFqaGQCvE5agioOVU1+dbRS 9XXrEw+nwzlKGg6PWHmLnmQFH0XftxtLwZcdAQN931Wq3eULlIwuLV53Lk9EVH+A1qsU fF0epIPn1Ny7+ldgWbL46dgWzKXGiQRMShRRt+d2rR8MTjGWgUrhVWmjDpGalIAIfcAP JdRKzNEIo79JHuJd43II363EGIooYfTlvVWRN1Dt4aR26Zt52ZnSNk3VlCeysVac/AVs e6Nw== X-Forwarded-Encrypted: i=1; AJvYcCWqbZf63Grnjq6Mls7Kk8n8lsZu7WENWCdXOVT2VegAxAweUWfbwXH01bksIIveQDlHhmyKD8bK0WA=@lists.xenproject.org X-Gm-Message-State: AOJu0YzUcd1fc7dYddonTLdzhrSPRbnXMrw5oP7KM5vkzF5QW1VLP2q9 MAcp+uH7ML9TMk2pNQTuas54a/yklo629vsE8ZhsgJbsa94MQHs2cNsN X-Gm-Gg: AY/fxX4xeiSECI+Cu2YrZW3ApwD9ig66AzsiPR4mzl9/P5eer3PqSLmz6Mm+WgdCmGy 6XXpvrRvWy4uHVaGXGZ7Ap0yyObkr1QrPJwphjQD8uYWao1i515Prs/UOQp9PZMk3CzJqoRIVTb TKbxVcYQ5YNl9+hm7vWkWvKS0eAfZx0LL5aVfxX+2jGm7GGwJFUJ2BeQXjB4HXgkTEEQRDX7LE7 P4vX3/cGrlFgppkUwgMYNAt6pfhrHgUqHWl4MR3t8lT4hh/IHlTuJqq6RmQMqttgbTrziEeny4p LDK1ktPsj7DJKMtfbSL2c8TbS5phogvAPfPEwFwC9TeRN76sAiiuWxbZVutmRdQ+dISOh96B5Cc gQK6qkinBUc+R5SHUeQ0wjKX7ZEINmA8WhM9zs6FU9S5EkJAH3+sERonIm4Va+GtTg5e96vl0Ky Ji3HQyEjO8VG79cwaSEWFpiQJMMqrR+LjvcPgH3zRdC9vzUmj9JPPpQ8UkBAxdrXU= X-Received: by 2002:a17:907:6e8c:b0:b70:ac7a:2a93 with SMTP id a640c23a62f3a-b87612dbe47mr269653566b.43.1768406353205; Wed, 14 Jan 2026 07:59:13 -0800 (PST) Message-ID: <5c6eff93-0db7-4382-8365-6b32b17f5f4d@gmail.com> Date: Wed, 14 Jan 2026 16:59:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 08/15] xen/riscv: introduce vtimer_set_timer() and vtimer_expired() 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: <8cd3efa488b3da2a6751c92d20bbfeb87b3ba39a.1766595589.git.oleksii.kurochko@gmail.com> <4e18e4fc-de62-44fc-8ea0-517f6c7ef47f@gmail.com> <62c22b34-cbad-40f2-a367-ba5fd8d11b51@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <62c22b34-cbad-40f2-a367-ba5fd8d11b51@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/14/26 3:57 PM, Jan Beulich wrote: > On 14.01.2026 13:27, Oleksii Kurochko wrote: >> On 1/13/26 4:12 PM, Jan Beulich wrote: >>> On 13.01.2026 15:44, Oleksii Kurochko wrote: >>>> On 1/8/26 11:28 AM, Jan Beulich wrote: >>>>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>>>> + { >>>>>> + stop_timer(&t->timer); >>>>>> + >>>>>> + return; >>>>>> + } >>>>>> + >>>>>> + set_timer(&t->timer, expires); >>>>> See the handling of VCPUOP_set_singleshot_timer for what you may want to >>>>> do if the expiry asked for is (perhaps just very slightly) into the past. >>>> I got an idea why we want to check if "expires" already expired, but ... >>>> >>>>> There you'll also find a use of migrate_timer(), which you will want to >>>>> at least consider using here as well. >>>> ... I don't get why we want to migrate timer before set_timer() here. >>>> Could you please explain that? >>> Didn't I see you use migrate_timer() in other patches (making me assume >>> you understand)? Having the timer tied to the pCPU where the vCPU runs >>> means the signalling to that vCPU will (commonly) be cheaper. >> I thought that migrate_timer() is needed only when a vCPU changes the pCPU >> it is running on to ensure that it is running on correct pCPU after migrations, >> hotplug events, or scheduling changes. That is why I placed it in >> vtimer_restore(), as there is no guarantee that the vCPU will run on the >> same pCPU it was running on previously. >> >> So that is why ... >> >>> Whether >>> that actually matters depends on what vtimer_expired() will eventually >>> contain. Hence why I said "consider using". >> ... I didn't get why I might need vtimer_expired() in vtimer_set_timer() >> before set_timer(). >> >> vtimer_expired() will only notify the vCPU that a timer interrupt has >> occurred by setting bit in irqs_pending bitmap which then will be synced >> with vcpu->hvip, but I still do not understand whether migrate_timer() >> is needed before calling set_timer() here. > Just to repeat - it's not needed. It may be wanted. > >> Considering that vtimer_set_timer() is called from the vCPU while it is >> running on the current pCPU, and assuming no pCPU rescheduling has >> occurred for this vCPU, we are already on the correct pCPU. >> If pCPU rescheduling for the vCPU did occur, then migrate_timer() would >> have been called in context_switch(), > Even if the timer wasn't active? Yes, migrate_timer() is called unconditionally in vtimer_restore() called from context_switch(). migrate_timer() will activate the timer. ~ Oleksii >> and at the point where >> vtimer_set_timer() is invoked, we would already be running on the >> correct pCPU. >> >> ~ Oleksii >> From xen-devel-bounces@lists.xenproject.org Wed Jan 14 16:00:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 16:00:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203421.1518629 (Exim 4.92) (envelope-from ) id 1vg3Ig-00068p-Cl; Wed, 14 Jan 2026 16:00:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203421.1518629; Wed, 14 Jan 2026 16:00:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg3Ig-00068i-A6; Wed, 14 Jan 2026 16:00:50 +0000 Received: by outflank-mailman (input) for mailman id 1203421; Wed, 14 Jan 2026 16:00: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 1vg3If-00068c-7O for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 16:00:49 +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 30092e83-f162-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 17:00:46 +0100 (CET) Received: from DU2PR04CA0224.eurprd04.prod.outlook.com (2603:10a6:10:2b1::19) by DB8PR08MB5305.eurprd08.prod.outlook.com (2603:10a6:10:112::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Wed, 14 Jan 2026 16:00:39 +0000 Received: from DB3PEPF00008860.eurprd02.prod.outlook.com (2603:10a6:10:2b1:cafe::9d) by DU2PR04CA0224.outlook.office365.com (2603:10a6:10:2b1::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.5 via Frontend Transport; Wed, 14 Jan 2026 16:00:37 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by DB3PEPF00008860.mail.protection.outlook.com (10.167.242.11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Wed, 14 Jan 2026 16:00:38 +0000 Received: from DU2PR08MB7272.eurprd08.prod.outlook.com (2603:10a6:10:2d7::16) by GVXPR08MB11762.eurprd08.prod.outlook.com (2603:10a6:150:317::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Wed, 14 Jan 2026 15:59:36 +0000 Received: from DU2PR08MB7272.eurprd08.prod.outlook.com ([fe80::5d34:206f:373:a323]) by DU2PR08MB7272.eurprd08.prod.outlook.com ([fe80::5d34:206f:373:a323%6]) with mapi id 15.20.9499.005; Wed, 14 Jan 2026 15:59: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: 30092e83-f162-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=mA4e6RTVr7LiyhkLAnL+fMYmQ1+i2znW3QHzScZYXEKPpeWMBi2g9WmklqxZlNnBS1++S1nKEAL+hfHRm8p6iFB1Hp/hp2Zczo7lgJMz5qFobDNNSnRerxcqx5TjLkyXD/659YFbGacU6WiJeP8njCqeWkCsfEW00cB230TlXzndDFlrT9cydvdj1NtP94VyogX1uNBTIKd62E+21hy6A/lqKg9f3i4rU+U78dHjTdkeeUhhnxirDqoibncJcDfpSrq+4TGsGK6g/qimdcpwTfYQMuekAerQQUBMP9fvrPCVrkdmI2Wihm70QwEIPJsv1WbTchbPLNinAaBcSsk1Zg== 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=Z8mjaOvVX1HbYVVLsDJ6Dg5Yz1px4buq7pt8oH4hTdg=; b=tgHtD4gReS0e8gHq/2U3J5GfTKBpgK4CK/zIW6VX3YSm5YZXR+IAXTDx5sbIB78r8E4O1gjh7U3VBO7xKfTH/RWfY6JcDTzjMuM5EH1I+GQRk3OdUjuJOsO3IcJj2RcwbYWF9dye0rVc84qBTTpgXXC3FbYcB/XyZ8UI4Y1CpB39R+Vqd1TsYyiz0AuAfoaTC6knt6Vb77K58tGEr7e/dVzhyLIWYAC0AQ4dvki8PpRRt3idgZf6QoVvWuUgtuAw5IwY4RjVNlAOXBoviAx/DnsY+/SbzVXkWz1pNByX/MZkYv5tNuJU3JU/TvLH2TgozGDygmQfhEnRl3gz+bQeCg== 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=Z8mjaOvVX1HbYVVLsDJ6Dg5Yz1px4buq7pt8oH4hTdg=; b=aYe3Srv3Hu3kjfS+AUaCxX8MPyVtcmhDMjERltDurMACt5YdwYPDZV7hUXbiJ8CXEIRiCiE4p2/htGS/G852MprjnDAIXSMP228R//MVaD18vwDLc3yyxSP+bJTtRUkU7dr57lLwOZYcrG+PRn/HKPhLUMnjQa3mbXUGbyX/l8E= 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=l0QY9Fw8Ko8hLE1rt85+h9Vblq1A7nV7pRoM8Mu6h7gQr+jwYUVRP+bQEx+K6B5L6p9layl/NDQ3rOgW1VER+uJDOuku13vkoZ84O2xh1L2HfAZtwAqkO1FIhrOt1ATNOcX6y+6gnvRJUV+9kb6GQ9iUNCCGcPRCzOxOEcfz9EXW579FMS+Lg4tDPslgmRpSy/j94sdHRPzFlobAtFNciYfsBoKsGTEvq7LQfnRRv2VWIbaFWKRih7ZaLnXsEgdE4Z4VF4n4II/uYi0zeSKa0JRghVMaRtTdn7T9p6GKRWwnTVan/T0PSarS7gzY/uiczULXYvEawFJY5ha3Z8at8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Z8mjaOvVX1HbYVVLsDJ6Dg5Yz1px4buq7pt8oH4hTdg=; b=QpJalPn1WaDOVUWDnF5l8DJB9HQ/VG3VL7HydaBIPsE88FeIgm8RXkvEoKyaR1EQj4a2ZGti4GtvIesbkLqfhfLozI3KO1ygKZzF+JpIs+ZBLxIaBZhiBfbgfKi5J0X3XuMFF93JdMOevj4Xc/waH/ibOgkWJpiMBdr11SDEh/cSg3E050gpvKdVuzFm7AnLE/j3VLXXHl8RplzIZYvXoQV65ok7RoLk2uExTN+xWgDgVDypLtX8OPQjz3T0EiGpyUjqdDQh2LobTeCPuqTv3ZD94PDIfGlFBEL3y3YJPiQxWAFct4kFKKsPjNbGKB5Q3+NN0zlUDaBb+SutBBZWbw== 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=Z8mjaOvVX1HbYVVLsDJ6Dg5Yz1px4buq7pt8oH4hTdg=; b=aYe3Srv3Hu3kjfS+AUaCxX8MPyVtcmhDMjERltDurMACt5YdwYPDZV7hUXbiJ8CXEIRiCiE4p2/htGS/G852MprjnDAIXSMP228R//MVaD18vwDLc3yyxSP+bJTtRUkU7dr57lLwOZYcrG+PRn/HKPhLUMnjQa3mbXUGbyX/l8E= From: Luca Fancellu To: "Halder, Ayan Kumar" CC: Harry Ramsey , "xen-devel@lists.xenproject.org" , Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Wei Chen Subject: Re: [PATCH v4 6/6] arm/mpu: Map domain page in AArch64 MPU systems Thread-Topic: [PATCH v4 6/6] arm/mpu: Map domain page in AArch64 MPU systems Thread-Index: AQHchW4/x/lNNLz1O02Z0+T7tL7LY7VR0o6A Date: Wed, 14 Jan 2026 15:59:35 +0000 Message-ID: <4EEAE5C4-59C7-4FA2-9B90-764C754420E1@arm.com> References: <20260114142734.239197-1-harry.ramsey@arm.com> <20260114142734.239197-7-harry.ramsey@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3826.700.81) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DU2PR08MB7272:EE_|GVXPR08MB11762:EE_|DB3PEPF00008860:EE_|DB8PR08MB5305:EE_ X-MS-Office365-Filtering-Correlation-Id: c78b5a71-6539-4c97-14a0-08de53860fce x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|376014|366016|1800799024|38070700021; X-Microsoft-Antispam-Message-Info-Original: =?utf-8?B?S2tjK1d5ek9MSFZ1ZnRWTXJkVFRaaTduVHNBVWw5d2ZTellKWVR5Zk9mbGVK?= =?utf-8?B?ams4Mmtlb3dRYmQ2VzZQRE1wQit1R0hKNEUwblpZRk8rbE83VHBTOHRDVUVO?= =?utf-8?B?bVpJUXZnYUtVU04xaml1YWlMOHFZTUVla2pDV2d0MmVFaW5qenR5VWx5K3JV?= =?utf-8?B?K0YwbGd4eXEzTE5kaEFTempmbXR4U0JKYzloaUlPdHBxd0VXVFVNVWJQVDQw?= =?utf-8?B?OHA2MXV1NE1VYkczMXBJNjNKenNBT1lwcW9GMFE0UDNGWUs1Z1JjTFd3dnZv?= =?utf-8?B?SDVjdGNxQUhuUlU5R1lWQkhtTzBKMktGbDdkL01VZlZZR3BQaXlLS3pyMWZr?= =?utf-8?B?VGRtMlptWjlpa29pdkJOMGNPU0FFZjFXdUNuNUtFTWlvc3Zid2hrVjd0ZEdL?= =?utf-8?B?RFhnK0hwMjlyN2MrQU1RR2JNSTQvMkg5akJFZnBDZ1JsVFJ2NFNEQjd3Ri95?= =?utf-8?B?VnZSbkJ1YU13dVNKYVM4R3NOTFM2OXh6SGpTamlWbEthR1RpZWlmYjB6WkxR?= =?utf-8?B?TGs5bWNZOS9YdGNrMGF0SCswaUNDVjBEZFJpYlBYZXJOSDNCOXRqTXdnd2tR?= =?utf-8?B?WlNxU1ZCSWNFd2had3J3b3ZYM05walI3UG5oMzlWZ043QjBGY0ROYnBpVVJp?= =?utf-8?B?MXR5aHFNZDg4QmtNMmQwQkxHS0VySXNRU2xxNjMrZTVXSEkwOHQ1aW14QU0z?= =?utf-8?B?NkpUYjViTkVvb1p2ZHBvMjJxd2NuLzRHTTlPT0J6d3diQ2V5SXB5MDZGTXFk?= =?utf-8?B?RS9HbEVSOXo2RFRsTGsrajRHUXFpNHZ1L2hIS0VtUGhubjNVSEJQSjQrNld1?= =?utf-8?B?WXZ6UFRic3huc0M4bVJRSEtCTjJKUWlXQlVVZDhDaGxBb1prSmJ4d0haVG81?= =?utf-8?B?TldpS3ZuODd3MmFZYnFiYWV3QWRZN1VJL0x5azNjdzc4WGU3QS8xMzBjalZF?= =?utf-8?B?cTg5RklEZGczejhNWm5GTG5LWEQzM3kwd0NZRFVLUk0vYlpnUGFoM2VCZVVU?= =?utf-8?B?cHJKakZpTUJlamtNaW1ZTzhESloweGR1NFcwR0QrMVRzalRnUkEvWWd0Mk0r?= =?utf-8?B?bDBOQzlTTHVVRDdSNzc3QkRIRlF3OVhyYWh3MGU3YWcvMFpVVlNBVzBwRFg3?= =?utf-8?B?eVZyQmxiRHQ2MnF5Q1JXM2NVaXV2SkQxUVNycGxudVdZTk0yMHJJVC9mZFVX?= =?utf-8?B?Rm5xWFRlRXlpdVdGdXBUeSswY3lDQjhCU3RQbW1MazJyT3lJNmhQc1hwME1G?= =?utf-8?B?SDBvU3ozNUJhZkduMmRsRTl2VGFBcmtVem0xZEdJL1dGTW1lR2RndytWSzk2?= =?utf-8?B?VDh5MkJBMmJETUF4UnFXQ3dEb2tVRE5zU2oybHNBMHRKbEN0Y1dUSFNqTXAr?= =?utf-8?B?Y0s0TDRQcVQ2MmY1cWkxcHpUR21lRGs4dUpWRUJFSUJ1eUozT2RFbmt5aW5M?= =?utf-8?B?enBNSkU4Tk9CaEQ0YWMxUW45REsvaXdVdVlJS2lleHVqZVpHNGRJek1XV2Zu?= =?utf-8?B?RStzOG9JZnUrcHU2Q1RPV3Y2eEM0MFdNSnhWdDhLTzNaSS9MdHJaNldxcm9q?= =?utf-8?B?aUQxR1lyWE1ZOGJ0L2xEQ2pzTXRYTGh4ai9iYWlMcDNFejB2RFBabGdEdnNk?= =?utf-8?B?eXR1TGpvZVgzTzFHdUdhY1NRRnRuc21sd3ZXQ1JXYjRDY3FON2M4OTRKYjBk?= =?utf-8?B?cGVBT1I5czhkWFVEaTNlVFVKS1o5YXNDamNLNzdsT2pHV3NDbmxzNHVMMURy?= =?utf-8?B?NjQyVGhyeTVHTld5cWFXQklpSm1mdG5sNkZ1eEkyYklVbGtST28rME5JZ0ZI?= =?utf-8?B?SGtkOURoK3puUEZjZUtXSUhJWUtnZ0Y4NHhqcFdBOFk4ZEEyNmFWOWw1YTND?= =?utf-8?B?Zkt1SHhnbENHOVJYTXlEc0YzcDRtZEZwZVkyTmV0UWp6S0xBQjB3QnZxcFp4?= =?utf-8?B?Qlg3RGdmVDczUFFsYjRCejFUQmNxVFVueVRxZktiZlFibUV1OVdpYTdXMkJx?= =?utf-8?B?WGxwWi81cjBiZ1M5VzZCMnJLeG1GQVZTa1lCYXM1UHJsTmZqR2dsNlhpdzc5?= =?utf-8?B?MlY1WVhMWVEyc0J1SDg5ZkZSZGlWRkRybER2OWozYnB4Y2JvTFpKNU51bUhT?= =?utf-8?B?TEtrQWYzUVA2bExIZXpENW9IMENwS05hSmM3QjVMbTJBNVoyZ0JKRGVBRlM4?= =?utf-8?Q?zrNdY0QnblJQAmGDS/WpFGo=3D?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU2PR08MB7272.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR08MB11762 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB3PEPF00008860.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 21889377-57dc-40dc-f907-08de5385ea4f X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|14060799003|376014|1800799024|35042699022|36860700013|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?dXl4TURCbXVKM0Zwc00vU2Q4ay9XekZCNkg4S2RjWW94RzBocmFjNFh6Y2JB?= =?utf-8?B?WHlua01ndFVOcUJ5bVAybEh4NWhIUWtYVzU4Zm9lTG1xVDE2VEdtcWFoVE9z?= =?utf-8?B?MytIb1lSTi9aMTdYRk1UdkgvcnNmT3lTZ1E1dE9hSFpKbk52Z05Kbk1lTEJz?= =?utf-8?B?WEJGK1lhdlpySzhtTXo4TzN5TEdBMFV1NFI5ZUFWK0VieWpxUHlmQ1NIV0Nu?= =?utf-8?B?TW9YNkk5K09lOTgyNXZ5eHhveE9zOEZkMXhWMm11VG1vQS9wTFZtcGd3SFdT?= =?utf-8?B?RFk0S3pOUHBxSmNCRzBaNVkxY1FHQjNzN21oSktYQWRZVUtjbmhFYW5rUnpU?= =?utf-8?B?UWFEVmx5YWdqd1R2a1FmRlJDL1I5NXI4K2ZTOW9aNVN5dVdCUzJsZXJzQ0pl?= =?utf-8?B?VFN5UE5hMHU5Wm51ZHZTeHpzaWljVC93VDZpbllyOW01clppNy9GOVA0MGZ3?= =?utf-8?B?OTdTcWR6Q2JqdVJ1WmozczBXaVVtVXErUDhVVm1lbDBoQnVlVU9RRFFqUlNT?= =?utf-8?B?amlTcndNcndoSXoxekZvc2ZPeE1nOVd5cVJlcUpGalZEVXRsbHQ1MG8yZ2ZU?= =?utf-8?B?YjhaV3pjVklub1M3WEgyUzRQZDhMamh3VXhsTzkxOERhNmNkdDBYUEZBQ1F6?= =?utf-8?B?MFhBVTJnLzl3NitrbHp3UTRHTXYzZnVhTFFJMC9tVS95SWxucnk1U1ZFVmFY?= =?utf-8?B?ajIxT3U1eEJXT2NlN3BhdndNdEF1WGpPVElJcDhJU0dENXlrUHBqREcvcGpC?= =?utf-8?B?ZEQyTmRxVG8vMms5SHlGSXorajdabWdFS0c0bnkyWkZpdS8rNThOU1RPWU9H?= =?utf-8?B?YTRwTXFDb3NnTDY2c1FWRlJXazNHc2pRaTNwS0JmVFNEV1ppcnpYa244SEVh?= =?utf-8?B?b0tyaUxRN21aeVQyb1RWcTlpbTdaaGtDTEhLYmsyTm5tT0tNSjlmbTlzMjZD?= =?utf-8?B?Vng4VWVYcHovNlNNZnV0KzVmQVhMZU1kUTZEeGgrRXl0YzJ2bmFYL0l2YllR?= =?utf-8?B?M2ZiWVhMNVhFdzFqcldubkFUVVRidUNDV0RmWjlRNDJ6cTNkcXc0TW03aEc3?= =?utf-8?B?dHRhblE4cEE5cFdzSmxMRld4UVcwVzl0MnpRQkhnYkJnVVJlS2JzKzVDckVX?= =?utf-8?B?d1lES3NQS1ZaSDljakJoaFBTR3UvVS83TTFpQjlidno5SFpoT3VSeXduZEhn?= =?utf-8?B?cWl4SFN2SVBGUFExM2VXWEpBQnBTYXhVbElER1lBeHRxWjhFenVzOCtqOXRh?= =?utf-8?B?Ync2MmgwZm4wOUxPRGlMemJBcWdnVldwTzdYOWY3TWUvdkljK25VMXpBVDRI?= =?utf-8?B?ZWtpdmtubFV2bHVOY0hxS0xZZjRKWHUvUEdwUVVRaGN6N1FPWUNpQW1OV1h2?= =?utf-8?B?Z2N6R0xZUkZRanA3Q3VsOUtNSVpxSXVTREZ3YW9iYXBkTDJtYVo0S2pqSmh6?= =?utf-8?B?NGd0dXY5KzhYdnJnLytCaXg5bGZpVGsxd0E2ODI5eDB5ajA4R0xLTjlOOHJl?= =?utf-8?B?RWsyNy9oa3B0TUIzNlpRNWRVT1A0SDVKcDgxeVI4WjR3YzhYMzAyQjVEaW5Y?= =?utf-8?B?cjZGcHh2dkZ2VnJNTkwyUmVZRDgrS3oyKzkwaVVUM0ZtTTZwdGg4UWhKdDJV?= =?utf-8?B?ZmNEeU5BTXV3eGN6eDVpak9hU0xyNlV2c2FKWktsbWFleGlrK1hqK1NxNTUw?= =?utf-8?B?cHpIQkZ6RjNZZFV6c20rMXJlZGhWMHNEak80b1NPZFZzYVBYa253RzNmQm1H?= =?utf-8?B?aE1BZ2E1dVlwWEtuK01aOEszeVJoMHc1RWJESE5raElBQ0lPcitGU1VUSVZE?= =?utf-8?B?TktWWXNGd0RXVWFzT2xDV2ZCSE1wYmxKeDJHdU0wdUJmUENEaEpWMjV2b1RZ?= =?utf-8?B?YUNCdjNKcXR1bldkYm8zcXlKdklnOEt0RFBWeGVxVEg4K1NiRWV2YnE5c3F0?= =?utf-8?B?OVE0RDZhNXFyTnl4ampTRmt6bG9vU1FsVDQxSElJcnY4aThKRnlxR2oxbjdR?= =?utf-8?B?elZHN3IvMTNuT3lFemNlaG52WWg0dmJ4aTN1QkxHdnFCenlZSDlFendvYWty?= =?utf-8?B?TjNyS2p0dDY5NjJHZkxiYmdCLzVSejJobi9uYmpVZk9hYlJRZ2Z2OEMrZGM4?= =?utf-8?B?ZExtNFZPWVhwU0loRXJOZ3VJY29NMWd5WXNMRXlhbi9UbllieWtUdlVoaDFE?= =?utf-8?B?dDM0M2MyeWxhMXphQ2N2aFZwZTBWYnE0blJvNDZKN1JONzN3Y2N6MFVlTGdO?= =?utf-8?B?RzN0VFh1bEs2eHI3K0p6anZZNWx3PT0=?= X-Forefront-Antispam-Report: CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(14060799003)(376014)(1800799024)(35042699022)(36860700013)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2026 16:00:38.8099 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c78b5a71-6539-4c97-14a0-08de53860fce 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: DB3PEPF00008860.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5305 DQoNCj4gT24gMTQgSmFuIDIwMjYsIGF0IDE1OjU1LCBIYWxkZXIsIEF5YW4gS3VtYXIgPGF5YW5r dW1hQGFtZC5jb20+IHdyb3RlOg0KPiANCj4gSGkgSGFycnksDQo+IA0KPiBDYW4gd2UgZXhwYW5k IHRoaXMgdG8gY292ZXIgQXJtMzIgYXMgd2VsbCA/IEkgZGlkIHNvbWUgdGVzdCBhbmQgYm90aCBB cm0zMiBhbmQgQXJtNjQgZ2V0IHRvIHRoZSBzYW1lIHBvaW50Lg0KDQpUaGUgb25seSBwcm9ibGVt IGlzIHRoYXQgd2UgZG9u4oCZdCBoYXZlIGFuIEFybTMyIHNldHVwIHRvIHRlc3QgdGhlc2UsIGlm IHRoZSBtYWludGFpbmVyIGFyZSBvayB3ZSBjYW4gZG8gaXQsDQpidXQgdGhlbiBpdCBzaG91bGQg YmUgeW91IHRvIHRlc3Qgb24gYXJtMzIuDQoNCkFsc28sIGluIGNhc2UsIGNvdWxkIGl0IGJlIGRv bmUgd2hpbGUgY29tbWl0dGluZz8gKHByb3ZpZGVkIHRoYXQgdGhlIG1haW50YWluZXIgZ2l2ZSB0 aGVpciBhY2spDQoNCkNoZWVycywNCkx1Y2ENCg0KDQo= From xen-devel-bounces@lists.xenproject.org Wed Jan 14 16:24:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 16:24:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203466.1518660 (Exim 4.92) (envelope-from ) id 1vg3fA-0001Ct-Iy; Wed, 14 Jan 2026 16:24:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203466.1518660; Wed, 14 Jan 2026 16:24:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg3fA-0001Cm-GM; Wed, 14 Jan 2026 16:24:04 +0000 Received: by outflank-mailman (input) for mailman id 1203466; Wed, 14 Jan 2026 16:24: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 1vg3f9-0001Am-Sc for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 16:24:03 +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 6f91d723-f165-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 17:24:02 +0100 (CET) Received: from CH2PR12CA0022.namprd12.prod.outlook.com (2603:10b6:610:57::32) by CH2PR12MB9541.namprd12.prod.outlook.com (2603:10b6:610:27e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Wed, 14 Jan 2026 16:23:54 +0000 Received: from DS2PEPF00003448.namprd04.prod.outlook.com (2603:10b6:610:57:cafe::4a) by CH2PR12CA0022.outlook.office365.com (2603:10b6:610:57::32) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Wed, 14 Jan 2026 16:23:54 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by DS2PEPF00003448.mail.protection.outlook.com (10.167.17.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Wed, 14 Jan 2026 16:23:54 +0000 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 14 Jan 2026 10:23:54 -0600 Received: from [10.71.192.102] (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, 14 Jan 2026 10:23:52 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6f91d723-f165-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=cOsQL8OyR77TMhIlHuNAwo4j3V67gXZ/I3EOnIJdQGBMa5AfUUWkT0aZmpEluZBmbilPCiG49wfA3vgt7OSrnwWx33EgrSdZ12C+R3xkkNF9FtZBP8nwhyxpo6SPCuLaEMRt9g3RwKritsq0FG95XzQqXm5I7TccfRQxG5vP/pmdy60GPLpE5HuJWLa4Nig+oM/XREBiul3RyJcNpLHvdBFM1kRwXR58WXfiEE82IQuNJtcezNqfx9speWmQPgtbIBuNHk1aXDXnoaSMwihvqZHkkICjWjVIVsZfS0xQLCsvYYQbfuP0VcnkA8CbFyYWkpvXdz0EDWjZixKTvgXuCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=O/i3OzvWdzADTxDJBn2pd8jIOa8e2UTJOLnq/8gtzmc=; b=iQcYyp//cF8C4IX5wjDDWT+J+Jc8PuImMxNpV+jYSayR04coldio+8L5P8MQRBUFB+BjcCcATzTeLxC1b766zQcqhbgNFySxpf5FgBaJ+aa7/6inNzovVOcjgyhEoLe94u/Us245d/obMHGIhOhDd4faUX565Kz4uSuiyhcl6OHFIbfKCPMy8y9e9eC0x5aDYVKBLF7mexwCdF9o5FDbgMoyNDGIWF5W5nIpm3kXwImu0jXoPckC039NAU8EVyE6p+Mz9lmSjeKp1Q4LZmNz1igB62nMf9Ulttd1du5xsh3RPsrHb/UeQfzCzoSUhGq/thBb5AqPR8A416gisZ+vRw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O/i3OzvWdzADTxDJBn2pd8jIOa8e2UTJOLnq/8gtzmc=; b=TohAPiJExcVyf71yz9a/HUkNPlF2yGdD8xlmVaHW9rxh2fD+QFu0pCQ6K1MDqfySuCjCbuXdWIGz3Ague88JXaMkNdMPiKMYnh4hUs1rXp07IYDTbxr9eTDiQV5lj6PoxaCOAoiXzq2SsvMCH370l/FZpW8sMY/vQ+NCaoPUKUg= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <4aaa5eda-36b5-4a4a-85f3-b53fa33cbf3e@amd.com> Date: Wed, 14 Jan 2026 16:23:52 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 6/6] arm/mpu: Map domain page in AArch64 MPU systems To: Luca Fancellu CC: Harry Ramsey , "xen-devel@lists.xenproject.org" , Penny Zheng , "Stefano Stabellini" , Julien Grall , "Bertrand Marquis" , Michal Orzel , Volodymyr Babchuk , Wei Chen References: <20260114142734.239197-1-harry.ramsey@arm.com> <20260114142734.239197-7-harry.ramsey@arm.com> <4EEAE5C4-59C7-4FA2-9B90-764C754420E1@arm.com> Content-Language: en-US From: "Halder, Ayan Kumar" In-Reply-To: <4EEAE5C4-59C7-4FA2-9B90-764C754420E1@arm.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS2PEPF00003448:EE_|CH2PR12MB9541:EE_ X-MS-Office365-Filtering-Correlation-Id: d17905e4-8d4c-4b33-730b-08de53894fac 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?dzlWa20wb014YUZ4cTJBTUF5Z3UvelhmMlBMbDZhRXFxZnNyL2JBVmVnbGF6?= =?utf-8?B?MWg1Y0YxdE5IMVN0c3ROMXlUcUhQZjBERkdtZFFDZkMyUVdnVW4xK1BCWEhT?= =?utf-8?B?b3Z6cVUxcEJKVVgzLzEzM1l2OEw0L28zdTI2d1NlZnQrVjFRMFh3dGxmZFJy?= =?utf-8?B?VUxTZ2U3a2d1NkRKT3JuT1V3WjAvb0NvM0t4VC82Z2NMMlU2MlIwSmF2R1gx?= =?utf-8?B?dGEvWHE4QkNzNzcya1A0MDFwL21qeXF0NWhFSURxeHBvSFQxRzFMMlRIdHh4?= =?utf-8?B?MGNDSXd2UnRzMVI3bnJKYXcrcldRRFRpbWhKQWMvaHF3dGNMZWtTY0Jtbnd4?= =?utf-8?B?bVExQlVVdFRiVWFVNnkyZHBUY1JWVk5mbDRDNU1GRiszcnBPdzd2S3kzakR4?= =?utf-8?B?Vy9FVm52ZGpvSjJxZ0RhTWV3TzczalNVUHN2SWsvZEdzTFNwdzhZN2NoYUQz?= =?utf-8?B?c3pyckgrQmQ0K0c1ZzhUZmVIUWRTemp1NTQxMXZON1h6QTlVbHZ2MTZXSDFj?= =?utf-8?B?K0NVMDZSY0k2TjM5ajNuazJUNGNGTVU0M1FNWkw2ZmxKRHYwbGE2dUV2Nk5Y?= =?utf-8?B?b1JjTlRaN3FsMFA0Y0ZuYVdjZHVIbjJCb1hFMXlDZHYvbkpLV3Y5dzhJRHJV?= =?utf-8?B?MG5wVWZsZVQ0aGJQaWZEbWYwTC8zMDd0MnRvMURUZ1NINGM2WVI4S1JMbk1r?= =?utf-8?B?eG9ORG5xVjJ0aUxYZ1JidEtQdEVORlZ2QTVoaitQZkZFRUhpalc0U25Zc3NH?= =?utf-8?B?V3E0SzBWZDdSOCtWZ1Y3ZkNSWC91YVQzaGo2bUJTZkhTeUdPQzRLaXhSeG9h?= =?utf-8?B?U0tYaGd3YWkxS0lZVlhTRDMxY2NYdlVXR0FtcmIzRlg0UG02OHkrOVpWRjI0?= =?utf-8?B?MXRQelJpbnJ5angvbXZlakhCOXR4NnRrM2ZpWlp3WXRmOXdTN0w5NFlBYzZB?= =?utf-8?B?UitCR3ZkMElkZXVSU0NJU0lEQWhuNHdzNE94RFZLV3FmOFlodytaUjBUUXF2?= =?utf-8?B?ZGt4UzJQbVJDWU52NkxYbVo5Vm00UFcxdzhpelh0bEVXcG1rTG1zRHkyaEZo?= =?utf-8?B?UzdJSkJubTl0enJhVUxSbW9mSXRRcXROeXF1RFZsWVFrWmlLWlFpdWtTWjJY?= =?utf-8?B?Qno4UjdMVGp6RVpqZWFsS1VEaFdEWFZwc3Rka1J1SStNM2R6ZFNvcm9xQm9u?= =?utf-8?B?dXNmemJyS2M2MWhSVnFTMWZ4OTZhcGNyaWJjQlpzQWQ4ZzFRaTRxcjhnT1Qy?= =?utf-8?B?T0ZpSmEra2Z0ZVd6cUhabFcvL25haDJkb2RPdUhrdzduemR1NE1mK2dZekpv?= =?utf-8?B?V1VyZFNJWExYdHIzRU1sS09uOFJGcjJtZEpiSU81cUlJdCt3ZmZYTFM1ZU54?= =?utf-8?B?d0lLQXRQM1RqREFRTHlpcmlzMlowKzNYTFNNbml1eFJxRU1mR1hzRlFuMUJp?= =?utf-8?B?cjl6NmdsWnVVNHVIcWdTSlNRdGZXOTFLN2N1S2RpdGs1bGt1OCswWmNUeGRE?= =?utf-8?B?anZSZU00N1hISmp3S1FyZ0NIMWQ4d2xXc05kRlhILzhjejRSTmZCNmN0UjEy?= =?utf-8?B?Vkk5SUZwK2VQb2xTWVhnNnlVVDl4b3dsUmJzMVYzUmo2MzhkdXhOaTQ2NXpr?= =?utf-8?B?R2xJYTM3ZzU1WXRmL3BrL2U3Tmxyd3U1M25NMksxVnJFWjBQYjltTVVtVmpY?= =?utf-8?B?eHczVGwrSU82TUJsZ3gzcUNjS2tLc0Mvdi8xNjdUMXhNM3NldE1LeWV0QytM?= =?utf-8?B?SVZWM0dqMzBIcDJGVW44WFpDWGxqZy9NNWdtUXFOZlJWSzR3dVhIVDlGS3l3?= =?utf-8?B?Z3M1c2FLTndsQ1pLS09Oc01Rc2NVV1VqN3VlSjRPVTZkRThhbUNnYVFXaXov?= =?utf-8?B?ME1ES3RhM1JJWDdadlRYaFBHckpJZGlQcU5nYklkZ01OejZkS1NRU0syOVd0?= =?utf-8?B?b2FYdmZZbi9pUW5wZU1xOGc1OWswSldydlVYTGZnL0tWWmdQVDIycFRHdmJq?= =?utf-8?B?L0hqYWZjeHVZQXBKd0RjZEdhVGEzS0hVZEJjSHN3TjJLZkVmL2crN3BzMTdG?= =?utf-8?B?Y3VGRzYvY0M2U2xIaXJ3NzVJdm9rM3hsTUVkeEd6UzlyWjJWa1BZdG5rNXRT?= =?utf-8?B?amlnd1dBcmExYk95V0xmaEdrR2F5bWdwcTNhd0pOOHNDMm9MWUxiOWJ1MG53?= =?utf-8?B?S3krdUxPNmppTHZoekFJZHJvNDFlNHhZT2VIZEw4NlRDaWdFTm0yNVhpWEFy?= =?utf-8?B?Q0JsU09Qd05lY0doT0ZiUCtoU0NBPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2026 16:23:54.4707 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d17905e4-8d4c-4b33-730b-08de53894fac X-MS-Exchange-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: DS2PEPF00003448.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB9541 Hi Luca, > >> On 14 Jan 2026, at 15:55, Halder, Ayan Kumar wrote: >> >> Hi Harry, >> >> Can we expand this to cover Arm32 as well ? I did some test and both Arm32 and Arm64 get to the same point. > The only problem is that we don’t have an Arm32 setup to test these, if the maintainer are ok we can do it, > but then it should be you to test on arm32. yes, I have the setup and can test the changes for arm32-v8r. You can test if it compiles or not. It saves some time and effort to send another patch for removing Kconfig. :-) - Ayan From xen-devel-bounces@lists.xenproject.org Wed Jan 14 16:50:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 16:50:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203488.1518669 (Exim 4.92) (envelope-from ) id 1vg44D-0004Pp-I4; Wed, 14 Jan 2026 16:49:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203488.1518669; Wed, 14 Jan 2026 16:49: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 1vg44D-0004Pi-FT; Wed, 14 Jan 2026 16:49:57 +0000 Received: by outflank-mailman (input) for mailman id 1203488; Wed, 14 Jan 2026 16:49:56 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg44C-0004PM-39 for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 16:49:56 +0000 Received: from srv1.deutnet.info (srv1.deutnet.info [2a01:4f8:c2c:6846::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0c07bd9b-f169-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 17:49:53 +0100 (CET) Received: from [2a01:e0a:186:d20::ebe] by srv1.deutnet.info with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vg446-0000000468Y-2rnX; Wed, 14 Jan 2026 17:49:50 +0100 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0c07bd9b-f169-11f0-9ccf-f158ae23cfc8 Message-ID: Date: Wed, 14 Jan 2026 17:49:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH XEN] tools: Update files examples PV&PVH with pygrub. To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , xen-devel@lists.xenproject.org Cc: Anthony PERARD References: <3e937fc7-62bb-404c-9b1b-c4172404bf35@deutnet.info> <4a572d26-a58c-4119-b8b2-006e4e1eea89@suse.com> <1d06919f-841f-44e4-b53f-af575e9dd2b1@suse.com> Content-Language: en-US From: Alexandre GRIVEAUX In-Reply-To: <1d06919f-841f-44e4-b53f-af575e9dd2b1@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 14/01/2026 à 09:41, Jürgen Groß a écrit : > On 14.01.26 09:20, Alexandre GRIVEAUX wrote: >> Le 14/01/2026 à 08:43, Jürgen Groß a écrit : >>> Yes. This is why I don't like the wording "inside guest", which is >>> just not >>> true. >> >> Before wasting more time for that side, there is chroot with >> bind-mount of DomU FS. >> >> Rephrasing like this should be more than enough: >> >> # Enable to use a grub2 emulation boot instead of direct kernel boot. >> >>> >>> Please be aware that we are trying to phase out pygrub, as it widens >>> the >>> attack surface of dom0 from a guest. pygrub needs to look into guest >>> controlled file systems, so any bug in the related code (e.g. >>> failure to >>> handle a corrupted or maliciously modified file system) might result in >>> security issues like code injection. >> >> Effectively, if pygrub is on verge of being phased out, there is not >> need for this patch... > > :-) > >> But could you point me to the discussion of alternatives ? As pygrub >> allow a more easy management... > > Oh, the fun of selecting the grub variant. :-) > > There are: > > - pygrub as discussed already > > - grub-pv (32- and 64-bit) and grub-pvh: official flavors of grub2 for > PV and >   PVH guests, selected by specifying them as the kernel to boot, > running in >   domU context > > - pvgrub (32- and 64-bit): legacy grub 0.97 variants based on Mini-OS > for PV >   guests, selected by specifying them as the kernel to boot, running > in domU >   context > >> >> Should this be noted to the wiki ? > > Yes. Documentation should really be enhanced. No problem to that, I have commit access to the wiki but beside updating, I need to test it, and check if Debian have packaged grub-pv... For me the pvgrub should also be noted as being phased out in favor of grub-pv. As for me the documentation should be usable by user without advanced knowledge to read code. > >>> So I'm on the edge whether we really should make it easier to use >>> pygrub. >> Legit, Should patch subject need to be [RFC PATCH] ? > > No, I don't think so. Others might have other opinions than me > regarding pygrub. > > Juergen Ok. Thanks. From xen-devel-bounces@lists.xenproject.org Wed Jan 14 16:56:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 16:56:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203518.1518681 (Exim 4.92) (envelope-from ) id 1vg49z-00063p-6O; Wed, 14 Jan 2026 16:55:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203518.1518681; Wed, 14 Jan 2026 16:55: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 1vg49z-00063i-2d; Wed, 14 Jan 2026 16:55:55 +0000 Received: by outflank-mailman (input) for mailman id 1203518; Wed, 14 Jan 2026 16:55: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 1vg49x-00063X-GO for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 16:55:53 +0000 Received: from mail8.us4.mandrillapp.com (mail8.us4.mandrillapp.com [205.201.136.8]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e1320245-f169-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 17:55:50 +0100 (CET) Received: from pmta15.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail8.us4.mandrillapp.com (Mailchimp) with ESMTP id 4drsgn1xfWz2K1t5s for ; Wed, 14 Jan 2026 16:55:49 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 02bd80d5a333410e889d0141c49c3aa1; Wed, 14 Jan 2026 16:55: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: e1320245-f169-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1768409749; x=1768679749; bh=AtllGZ6Y5k1iiyLVhr3ycRE0CdV4k59zMR6/1UbZufw=; 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=avDyeIzZBGanAw0ZMGdIsnRFGvPczryJXwcjaqFmOjRrl4jdv2a/3eIyJk6eCzCrY 9sKmkTjn5P/eh6VFNvPjzLJF2LEFISW/qCye33ENrZ4UxsTMy/7bfvumv7Y+HbAeck rFV+p7ahIGKBsAXfEI8il5lh+Tll+rUrxrcKXM3v0MyytTpYgvHb3TnqHg5poEEJaG adip1HABYOyjlMM9WeNXjO6mDuIOboPjnpbKvkbTirLUSXLHeMhW/3yXghFqSxy7Er lCuW3ZS44H+JIjmDtTb61aVPzBNQfa5JtTfrJEfIpf1vdlOvVQc9A8crGgWp7A6TDY fmRnBiW3/JgzQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1768409749; x=1768670249; i=teddy.astie@vates.tech; bh=AtllGZ6Y5k1iiyLVhr3ycRE0CdV4k59zMR6/1UbZufw=; 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=W0JoNf1P8J/Yo8tOCmgzY49aJ67VbMDX/fRU95NolSCcxo91BEUZN+x0EcEejKfvM JSPbZit2kp0RH0NY4yPAPrOFmAKi+c72PLk5D15Io3Fq8gbRcGuKYaqwg6E30Fyn7Z sJ687OxWE9c5nvjx20YahJ/YQL4ae6ep/yLABLVKlJHRJBEhXVBaI+364LMoxXXZ/Q B+ZypJiQ0Ep7WLmpn9wFIYuSCVSwA/elTVWdoW+Aag+0EoV4Wr8J3HrpNgF54YqYqD rV+WwSXQhthWFbBEyQNhlWnxP6i0eZnLqQFKZwJcSAnaW2zuxnqIIKL8I85IRBgGR9 rPRaLksQjrjmw== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=20v3=201/6]=20x86/cpu-policy:=20define=20bits=20of=20leaf=206?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1768409748287 Message-Id: <28910a0e-c6f3-41dd-9a0b-8289218562a0@vates.tech> To: "Jan Beulich" , xen-devel@lists.xenproject.org Cc: "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" References: <4d3a3576-2d3c-42ec-8551-18f1f0982e17@suse.com> In-Reply-To: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.02bd80d5a333410e889d0141c49c3aa1?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260114:md Date: Wed, 14 Jan 2026 16:55:49 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 14/01/2026 =C3=A0 14:45, Jan Beulich a =C3=A9crit=C2=A0: > ... as far as we presently use them in the codebase. > > Signed-off-by: Jan Beulich > --- > Or should we make both parts proper featureset elements? At least > APERFMPERF could likely be made visible to guests (in principle). > --- > v3: Use SDM-conforming names. (Sorry Jason, had to drop you R-b once > again.) > v2: Use bool and unions. > > --- a/xen/include/xen/lib/x86/cpu-policy.h > +++ b/xen/include/xen/lib/x86/cpu-policy.h > @@ -121,7 +121,46 @@ struct cpu_policy > uint64_t :64, :64; /* Leaf 0x3 - PSN. */ > uint64_t :64, :64; /* Leaf 0x4 - Structured Cache. */ > uint64_t :64, :64; /* Leaf 0x5 - MONITOR. */ > - uint64_t :64, :64; /* Leaf 0x6 - Therm/Perf. */ > + > + /* Leaf 0x6 - Therm/Perf. */ > + union { > + uint32_t _6a; > + struct { > + bool :1, > + turbo_boost:1, > + arat:1, > + :1, > + :1, > + :1, > + :1, > + hwp:1, > + hwp_interrupt:1, > + hwp_activity_window:1, > + hwp_epp:1, > + hwp_request_pkg:1, > + :1, > + hdc:1, > + :1, > + :1, > + hwp_peci_override:1, > + :1, > + :1, > + hw_feedback:1; > + }; > + }; > + union { > + uint32_t _6b; > + }; > + union { > + uint32_t _6c; > + struct { > + bool hw_feedback_cap:1; > + }; > + }; > + union { > + uint32_t _6d; > + }; > + While I'm ok for the a and c unions, I'm not convinced by the b and d ones (union with just a single uint32_t in it) as it's quite verbose and inconsistent with the rest of the cpu_policy structure. > uint64_t :64, :64; /* Leaf 0x7 - Structured Features. */ > uint64_t :64, :64; /* Leaf 0x8 - rsvd */ > uint64_t :64, :64; /* Leaf 0x9 - DCA */ > > -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Wed Jan 14 17:10:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 17:10:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203539.1518691 (Exim 4.92) (envelope-from ) id 1vg4Nh-0000lb-CZ; Wed, 14 Jan 2026 17:10:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203539.1518691; Wed, 14 Jan 2026 17:10:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg4Nh-0000lN-7Z; Wed, 14 Jan 2026 17:10:05 +0000 Received: by outflank-mailman (input) for mailman id 1203539; Wed, 14 Jan 2026 17:10:04 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg4Nf-0000Oo-Qm for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 17:10:03 +0000 Received: from mail137-3.atl71.mandrillapp.com (mail137-3.atl71.mandrillapp.com [198.2.137.3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id dbecfe61-f16b-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 18:10:01 +0100 (CET) Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail137-3.atl71.mandrillapp.com (Mailchimp) with ESMTP id 4drt072T2NzBsTrDT for ; Wed, 14 Jan 2026 17:09:59 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 22e83d2fdafe47ea8a73999fd20286d2; Wed, 14 Jan 2026 17:09: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: dbecfe61-f16b-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1768410599; x=1768680599; bh=OlWfxkxEDTn9r7Dg1MqxsBD1qeD0E59fmqNxesqwYdQ=; 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=mrVDFdGQWNRH4LbfB9uM3RGylbtpH72+whpT1QxkuLKqB8hO4h7k5oxYpG7+owHas +U5JpVfdqN924sD9CQ93FnbPxD3j4qbYSIwgy29T4ICzXoLzscgxvxRcUZe+X41v3y te2ZLcbyJ3ePXHA/80kSB/S+yj4IJXfxhEbtC0OjymrMOXYFVrD+lhe+iXxzCP0PN/ eeNov6az7tU/JqrnwSF27POpy5KHH0MYmh1Jssv5cxY3wWX59NvgJmS+kTWOYbCHz2 wu688ohQ4XSgtVhCfnx4ODrDlRSvYvghH7eW46PdlJ8eaH3U7cc2y0M3vkqptkaY4x s2F37Y4SrPrRw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1768410599; x=1768671099; i=teddy.astie@vates.tech; bh=OlWfxkxEDTn9r7Dg1MqxsBD1qeD0E59fmqNxesqwYdQ=; 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=U3uqaLS4Fleosyb01l4TXH4NeELlFIIxezfzgcxLO8jrSfdZGuGqKkntuH03FOuqV 5GBUftl3N/Fr9hsqnE4DXigNUvSrFLbXa3gaC6HWzwbExCHEVbtwyMlz4WJmBpc3xR Z6+KRsW+8gApNR7hqxlajZHCyAsZ3t5dgabTnILxJigR1dPZJoyZYw4tbRf21yQOti u/RK4tNdMqDJEuutxNWwW4feO0zgnqjePzxhQncrE/cIs3kYR703gkYIHMMXSuDxxu iitY3ChT3q6AabBRPQa7c4mHJW/123MOP3jASBU1wupabDralPDSK8kqwsCRWXTity IL++Bls9WyZvQ== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=20v3=202/6]=20x86:=20replace=20APERFMPERF=20synthetic=20feature=20bit?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1768410598136 Message-Id: <5607a1c2-a3ab-48d9-a9c4-10d6b1ceaffe@vates.tech> To: "Jan Beulich" , xen-devel@lists.xenproject.org Cc: "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" References: <4d3a3576-2d3c-42ec-8551-18f1f0982e17@suse.com> <29eb0997-bf74-4cde-ba7b-6977223c3829@suse.com> In-Reply-To: <29eb0997-bf74-4cde-ba7b-6977223c3829@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.22e83d2fdafe47ea8a73999fd20286d2?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260114:md Date: Wed, 14 Jan 2026 17:09:59 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 14/01/2026 =C3=A0 14:45, Jan Beulich a =C3=A9crit=C2=A0: > Use the respective host CPU policy bit instead. This has the (tolerable, > as we generally assume symmetry anyway) effect of using the BSP's > (unleveled) setting, rather than the result of leveling (as is done by > identify_cpu() on boot_cpu_data, rendering the variable name somewhat > misleading). > > Signed-off-by: Jan Beulich > Reviewed-by: Jason Andryuk > --- > The leveling of boot_cpu_data is problematic anyway, as that way features > can in principle disappear post-boot (as CPUs are being brought online; > just that we don't think anymore that we really support physical CPU > hotplug). I think in the vast majority of cases, hotplugged CPUs are of same model or very similar; so shouldn't diverge too much in term of features. Otherwise, it's pretty much impossible to guarantee anything unless we have per-socket cpu datas. > --- > v3: Re-base over naming changes. > v2: Extend description. > > --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c > +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c > @@ -80,7 +80,7 @@ unsigned int get_measured_perf(unsigned > return 0; > > policy =3D per_cpu(cpufreq_cpu_policy, cpu); > - if ( !policy || !cpu_has_aperfmperf ) > + if ( !policy || !cpu_has_hw_feedback_cap ) > return 0; > > switch (flag) > --- a/xen/arch/x86/cpu/common.c > +++ b/xen/arch/x86/cpu/common.c > @@ -523,10 +523,6 @@ static void generic_identify(struct cpui > =09if ( cpu_has(c, X86_FEATURE_CLFLUSH) ) > =09=09c->x86_clflush_size =3D ((ebx >> 8) & 0xff) * 8; > > -=09if ( (c->cpuid_level >=3D CPUID_PM_LEAF) && > -=09 (cpuid_ecx(CPUID_PM_LEAF) & CPUID6_ECX_APERFMPERF_CAPABILITY) ) > -=09=09__set_bit(X86_FEATURE_APERFMPERF, c->x86_capability); > - > =09/* AMD-defined flags: level 0x80000001 */ > =09if (c->extended_cpuid_level >=3D 0x80000001) > =09=09cpuid(0x80000001, &tmp, &tmp, > --- a/xen/arch/x86/include/asm/cpufeature.h > +++ b/xen/arch/x86/include/asm/cpufeature.h > @@ -11,7 +11,9 @@ > #include > > #ifndef __ASSEMBLER__ > +#include > #include > +#include > #else > #include > #endif > @@ -121,7 +123,6 @@ static inline bool boot_cpu_has(unsigned > #define CPUID6_EAX_HDC BIT(13, U) > #define CPUID6_EAX_HWP_PECI BIT(16, U) > #define CPUID6_EAX_HW_FEEDBACK BIT(19, U) > -#define CPUID6_ECX_APERFMPERF_CAPABILITY BIT(0, U) > > /* CPUID level 0x00000001.edx */ > #define cpu_has_fpu 1 > @@ -175,6 +176,9 @@ static inline bool boot_cpu_has(unsigned > #define cpu_has_fma4 boot_cpu_has(X86_FEATURE_FMA4) > #define cpu_has_tbm boot_cpu_has(X86_FEATURE_TBM) > > +/* CPUID level 0x00000006.ecx */ > +#define cpu_has_hw_feedback_cap host_cpu_policy.basic.hw_feedback_cap > + > /* CPUID level 0x0000000D:1.eax */ > #define cpu_has_xsaveopt boot_cpu_has(X86_FEATURE_XSAVEOPT) > #define cpu_has_xsavec boot_cpu_has(X86_FEATURE_XSAVEC) > @@ -292,7 +296,6 @@ static inline bool boot_cpu_has(unsigned > /* Synthesized. */ > #define cpu_has_arch_perfmon boot_cpu_has(X86_FEATURE_ARCH_PERFMON) > #define cpu_has_cpuid_faulting boot_cpu_has(X86_FEATURE_CPUID_FAULTING= ) > -#define cpu_has_aperfmperf boot_cpu_has(X86_FEATURE_APERFMPERF) > #define cpu_has_xen_lbr boot_cpu_has(X86_FEATURE_XEN_LBR) > #define cpu_has_xen_shstk (IS_ENABLED(CONFIG_XEN_SHSTK) && \ > boot_cpu_has(X86_FEATURE_XEN_SHSTK)) > --- a/xen/arch/x86/include/asm/cpufeatures.h > +++ b/xen/arch/x86/include/asm/cpufeatures.h > @@ -19,7 +19,7 @@ XEN_CPUFEATURE(TSC_RELIABLE, X86_SY > XEN_CPUFEATURE(XTOPOLOGY, X86_SYNTH( 5)) /* cpu topology enum e= xtensions */ > XEN_CPUFEATURE(CPUID_FAULTING, X86_SYNTH( 6)) /* cpuid faulting */ > XEN_CPUFEATURE(XEN_FRED, X86_SYNTH( 7)) /* Xen uses FRED */ > -XEN_CPUFEATURE(APERFMPERF, X86_SYNTH( 8)) /* APERFMPERF */ > +/* Bit 8 unused */ > XEN_CPUFEATURE(MFENCE_RDTSC, X86_SYNTH( 9)) /* MFENCE synchronizes= RDTSC */ > XEN_CPUFEATURE(XEN_SMEP, X86_SYNTH(10)) /* SMEP gets used by X= en itself */ > XEN_CPUFEATURE(XEN_SMAP, X86_SYNTH(11)) /* SMAP gets used by X= en itself */ > > -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Wed Jan 14 17:17:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 17:17:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203559.1518699 (Exim 4.92) (envelope-from ) id 1vg4UU-0001pR-4m; Wed, 14 Jan 2026 17:17:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203559.1518699; Wed, 14 Jan 2026 17: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 1vg4UU-0001pK-2B; Wed, 14 Jan 2026 17:17:06 +0000 Received: by outflank-mailman (input) for mailman id 1203559; Wed, 14 Jan 2026 17:17: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 1vg4US-0001pB-I6 for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 17:17:04 +0000 Received: from mail8.us4.mandrillapp.com (mail8.us4.mandrillapp.com [205.201.136.8]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d6ca92e3-f16c-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 18:17:01 +0100 (CET) Received: from pmta15.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail8.us4.mandrillapp.com (Mailchimp) with ESMTP id 4drt8D3MFRz2K1tTg for ; Wed, 14 Jan 2026 17:17:00 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 6bc1d91f2ac44b928af0eb62b499c31e; Wed, 14 Jan 2026 17:17: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: d6ca92e3-f16c-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1768411020; x=1768681020; bh=ssK4S1O4CZOfa9aiSQFG1racQJohBaF98Mq2e+oFXfI=; 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=ow46H8VQFboFwyVDqjUGUhL2Fcz7FN2+uurDiKx9WeNyTqWzebFoncgAKgAr5GFSf Cai31WxECA5MAdd9INIfOmNw3parYgFSvEhqk54SpQa27U0dZu1L1T0/4C3+l9D4Rt o9+l90ax/tfjERaxMkrHmvOwzfSUNvz1BsLx70GRtP2l/JnCmOI+PMTSa3eST+7FkZ GgahVcFIpDtxSBlY7DQZmODvetW5z3fVmILsuGM5pjLMMzbuk50kCU2yUl2V0Y8Ajn K5dhp5hcfFJUSvrHTxvPbX/wfYz4wlByY7mhZDMLLH35Qh0nEW7iz1ThXCVvw9UJlY wahtCdK2vwY7A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1768411020; x=1768671520; i=teddy.astie@vates.tech; bh=ssK4S1O4CZOfa9aiSQFG1racQJohBaF98Mq2e+oFXfI=; 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=F1uxkTg16V5LY753wTvBQI6nua3ZB04oQuAgMsrwCnJRB9f1ZTu5grejozCOVt8DN QZ3f4+ctLxI/4FsGHyyEnWJkjT7iDrWZ239soVHPZhDAJTTJ24VNaA3KSlpwFVOrdb hQaBPt3sWV3GKQPl/RnGR7l8adIJNpAztnwtcUbFYlTAjkA7uJ6Q/bVmUL0gvOZA0A cHidg0ZMsCUHHSMJwY0+GMIsN4Vu2MvMDz7OGYdVeU8oFXcqh4EPIKK9SnKyX0ywm3 mVfInEOFIUlREywJ0lL346k83JPlpV9uOEN5NDMH1QAhbs2fVTgpSu1wVsrUg/8NoL NLSpIMuGrICRw== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=20v3=206/6]=20x86/cpufreq:=20use=20host=20CPU=20policy=20in=20HWP=20driver?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1768411017689 Message-Id: To: "Jan Beulich" , xen-devel@lists.xenproject.org Cc: "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" References: <4d3a3576-2d3c-42ec-8551-18f1f0982e17@suse.com> <7d52c0cf-c097-4c32-9af6-5044727c3ef8@suse.com> In-Reply-To: <7d52c0cf-c097-4c32-9af6-5044727c3ef8@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.6bc1d91f2ac44b928af0eb62b499c31e?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260114:md Date: Wed, 14 Jan 2026 17:17:00 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 14/01/2026 =C3=A0 14:47, Jan Beulich a =C3=A9crit=C2=A0: > There's no need to invoke CPUID yet another time. This way two of the > static booleans can also go away. > > Signed-off-by: Jan Beulich > --- > v3: Undo some line wrapping. Correct padding in asm/cpufeature.h. Re-base > over naming changes. > v2: Introduce cpu_has_*. > > --- a/xen/arch/x86/acpi/cpufreq/hwp.c > +++ b/xen/arch/x86/acpi/cpufreq/hwp.c > @@ -18,9 +18,6 @@ > > static bool __ro_after_init hwp_in_use; > > -static bool __ro_after_init feature_hwp_notification; > -static bool __ro_after_init feature_hwp_activity_window; > - > static bool __read_mostly feature_hdc; > > static bool __ro_after_init opt_cpufreq_hdc =3D true; > @@ -165,8 +162,6 @@ bool hwp_active(void) > > static bool __init hwp_available(void) > { > - unsigned int eax; > - > if ( boot_cpu_data.cpuid_level < CPUID_PM_LEAF ) > { > hwp_verbose("cpuid_level (%#x) lacks HWP support\n", > @@ -183,29 +178,22 @@ static bool __init hwp_available(void) > return false; > } > > - eax =3D cpuid_eax(CPUID_PM_LEAF); > - > hwp_verbose("%d notify: %d act-window: %d energy-perf: %d pkg-level= : %d peci: %d\n", > - !!(eax & CPUID6_EAX_HWP), > - !!(eax & CPUID6_EAX_HWP_NOTIFICATION), > - !!(eax & CPUID6_EAX_HWP_ACTIVITY_WINDOW), > - !!(eax & CPUID6_EAX_HWP_ENERGY_PERFORMANCE_PREFERENCE), > - !!(eax & CPUID6_EAX_HWP_PACKAGE_LEVEL_REQUEST), > - !!(eax & CPUID6_EAX_HWP_PECI)); > + cpu_has_hwp, cpu_has_hwp_interrupt, > + cpu_has_hwp_activity_window, cpu_has_hwp_epp, > + cpu_has_hwp_request_pkg, cpu_has_hwp_peci_override); > > - if ( !(eax & CPUID6_EAX_HWP) ) > + if ( !cpu_has_hwp ) > return false; > > - if ( !(eax & CPUID6_EAX_HWP_ENERGY_PERFORMANCE_PREFERENCE) ) > + if ( !cpu_has_hwp_epp ) > { > hwp_verbose("disabled: No energy/performance preference availab= le"); > > return false; > } > > - feature_hwp_notification =3D eax & CPUID6_EAX_HWP_NOTIFICATION; > - feature_hwp_activity_window =3D eax & CPUID6_EAX_HWP_ACTIVITY_WINDOW= ; > - feature_hdc =3D eax & CPUID6_EAX_HDC; > + feature_hdc =3D cpu_has_hdc; > > hwp_verbose("Hardware Duty Cycling (HDC) %ssupported%s\n", > feature_hdc ? "" : "not ", > @@ -213,7 +201,7 @@ static bool __init hwp_available(void) > : ""); > > hwp_verbose("HW_FEEDBACK %ssupported\n", > - (eax & CPUID6_EAX_HW_FEEDBACK) ? "" : "not "); > + cpu_has_hw_feedback ? "" : "not "); > > hwp_in_use =3D true; > > @@ -226,7 +214,7 @@ static int cf_check hwp_cpufreq_verify(s > { > struct hwp_drv_data *data =3D per_cpu(hwp_drv_data, policy->cpu); > > - if ( !feature_hwp_activity_window && data->activity_window ) > + if ( !cpu_has_hwp_activity_window && data->activity_window ) > { > hwp_verbose("HWP activity window not supported\n"); > > @@ -268,7 +256,7 @@ static int cf_check hwp_cpufreq_target(s > hwp_req.max_perf =3D data->maximum; > hwp_req.desired =3D data->desired; > hwp_req.energy_perf =3D data->energy_perf; > - if ( feature_hwp_activity_window ) > + if ( cpu_has_hwp_activity_window ) > hwp_req.activity_window =3D data->activity_window; > > if ( hwp_req.raw =3D=3D data->curr_req.raw ) > @@ -365,7 +353,7 @@ static void cf_check hwp_init_msrs(void > } > > /* Ensure we don't generate interrupts */ > - if ( feature_hwp_notification ) > + if ( cpu_has_hwp_interrupt ) > wrmsr_safe(MSR_HWP_INTERRUPT, 0); > > if ( !(val & PM_ENABLE_HWP_ENABLE) ) > @@ -537,7 +525,7 @@ int get_hwp_para(unsigned int cpu, > return -ENODATA; > > cppc_para->features =3D > - (feature_hwp_activity_window ? XEN_SYSCTL_CPPC_FEAT_ACT_WINDOW := 0); > + (cpu_has_hwp_activity_window ? XEN_SYSCTL_CPPC_FEAT_ACT_WINDOW := 0); > cppc_para->lowest =3D data->hw.lowest; > cppc_para->lowest_nonlinear =3D data->hw.most_efficient; > cppc_para->nominal =3D data->hw.guaranteed; > @@ -585,7 +573,7 @@ int set_hwp_para(struct cpufreq_policy * > > /* Clear out activity window if lacking HW supported. */ > if ( (set_cppc->set_params & XEN_SYSCTL_CPPC_SET_ACT_WINDOW) && > - !feature_hwp_activity_window ) > + !cpu_has_hwp_activity_window ) > { > set_cppc->set_params &=3D ~XEN_SYSCTL_CPPC_SET_ACT_WINDOW; > cleared_act_window =3D true; > --- a/xen/arch/x86/include/asm/cpufeature.h > +++ b/xen/arch/x86/include/asm/cpufeature.h > @@ -115,14 +115,6 @@ static inline bool boot_cpu_has(unsigned > } > > #define CPUID_PM_LEAF 6 > -#define CPUID6_EAX_HWP BIT(7, U) > -#define CPUID6_EAX_HWP_NOTIFICATION BIT(8, U) > -#define CPUID6_EAX_HWP_ACTIVITY_WINDOW BIT(9, U) > -#define CPUID6_EAX_HWP_ENERGY_PERFORMANCE_PREFERENCE BIT(10, U) > -#define CPUID6_EAX_HWP_PACKAGE_LEVEL_REQUEST BIT(11, U) > -#define CPUID6_EAX_HDC BIT(13, U) > -#define CPUID6_EAX_HWP_PECI BIT(16, U) > -#define CPUID6_EAX_HW_FEEDBACK BIT(19, U) > > /* CPUID level 0x00000001.edx */ > #define cpu_has_fpu 1 > @@ -179,6 +171,14 @@ static inline bool boot_cpu_has(unsigned > /* CPUID level 0x00000006.eax */ > #define cpu_has_turbo_boost host_cpu_policy.basic.turbo_boost > #define cpu_has_arat host_cpu_policy.basic.arat > +#define cpu_has_hwp host_cpu_policy.basic.hwp > +#define cpu_has_hwp_interrupt host_cpu_policy.basic.hwp_interrupt > +#define cpu_has_hwp_activity_window host_cpu_policy.basic.hwp_activity_w= indow > +#define cpu_has_hwp_epp host_cpu_policy.basic.hwp_epp > +#define cpu_has_hwp_request_pkg host_cpu_policy.basic.hwp_request_pkg > +#define cpu_has_hdc host_cpu_policy.basic.hdc > +#define cpu_has_hwp_peci_override host_cpu_policy.basic.hwp_peci_overrid= e > +#define cpu_has_hw_feedback host_cpu_policy.basic.hw_feedback > > /* CPUID level 0x00000006.ecx */ > #define cpu_has_hw_feedback_cap host_cpu_policy.basic.hw_feedback_cap > > Reviewed-by: Teddy Astie -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Wed Jan 14 17:49:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 17:49:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203595.1518709 (Exim 4.92) (envelope-from ) id 1vg4zx-0007ED-HZ; Wed, 14 Jan 2026 17:49:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203595.1518709; Wed, 14 Jan 2026 17: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 1vg4zx-0007E6-Ek; Wed, 14 Jan 2026 17:49:37 +0000 Received: by outflank-mailman (input) for mailman id 1203595; Wed, 14 Jan 2026 17:49:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg4zx-0007Dy-1D for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 17:49:37 +0000 Received: from DM1PR04CU001.outbound.protection.outlook.com (mail-centralusazlp170100005.outbound.protection.outlook.com [2a01:111:f403:c111::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 632e7e3b-f171-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 18:49:35 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DS0PR03MB7774.namprd03.prod.outlook.com (2603:10b6:8:1f9::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Wed, 14 Jan 2026 17:49:30 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Wed, 14 Jan 2026 17:49: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: 632e7e3b-f171-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TDmHelmiWweNUJbqt36DUNe5GpZjq0zUNCkF2R/zSWeOXS60zWn+EI+rsRbgi14Q90fVsLSx4pKoEo3yqA/7eKsX3P/2qM/GAd3YAdkABw+CEOLg6D1QRTsM2ljQ8Tn66Jjh91PVugfgxaOuoii/V9eUnxha8eEzSlcdOj1N+bPXd8qt2V+6Oyz9hfG+BCavohbwzcQZF+COK/k155zDeq460XNRoY0xy1omkhz/mMPVefAiGKcnGa/oxP1BRRo9gllK69/6QRG5IV5Kw1LU841rZwzgrYN8vHoU8NUSHgWvUMDMZNpauvWJefPKFKzp+t3IRLLvph41eppgdGasOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aFzcPAKGUAvK2cxgErxT80xhhcqjeqxpEU7KH9F/ZmY=; b=V5aDr2kqWnfj5NvmnbZxybS2SN84hedoQ/gpUEIoHFs+FJb/sFhOSUgSR7Hb2Bt1EeeBFwoVKf93F7TbNJF/33gcRtzQrzzRjkZCSCLGY5asiPlXR3Nj+/VzT2nfsyScMYtjMaYkC04ZHLcJNGyvzLl/ECCQAorP0Pm+UEl1I1YsHut1cZ94KY1SvTYfsaNFZAwUKfgdmmGySMfmqcOkppw1EMGnDCdY7ZpjmjD50WdklCVC8RthrgVAaBzuiI8xftYLQYdKKNwyEl62BO69eOQaqoFLSYgIBTpMpKD2u3X/WWQumi+EiyEn1PQiQeSLLVOf5ty67JrS494By/gtBw== 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=aFzcPAKGUAvK2cxgErxT80xhhcqjeqxpEU7KH9F/ZmY=; b=N3Z5Izb3hSKStLbgB0cB1khxL24ndIic/OkrRc4ZUPsWbJ5uyUrAyH/+foKkf0/Qw7GxGHG4Eh9IlNrznEN0+qPdod34wAXb+lDL94yVZPUsfYOrXxjLu+NRl+iP0WNw6G5er0hY/dswieDlQI/dhbd5V77Qx5BRAxiNPft2+w8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 14 Jan 2026 18:49:26 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , =?utf-8?B?0JDQvdGC0L7QvSDQnNCw0YDQutC+0LI=?= Subject: Re: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() Message-ID: References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> X-ClientProxiedBy: PA7P264CA0228.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:372::10) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DS0PR03MB7774:EE_ X-MS-Office365-Filtering-Correlation-Id: c772f90e-eb85-4e49-cd79-08de539544cc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?VHVDWWJKNnB5ZlBoS1UrT3grOUE4WWVHN244aWN3Nk1LMTNFSmVQWWVoWTRS?= =?utf-8?B?YU5USWlYZVpWL1lQZkdKV2FOMUpyc25DMnVhUVJ4L1A5aHBhSUV5WTYwWXpn?= =?utf-8?B?UndKakZlRWdGVUZUcU5JODZuZ3VKc2YxVnJQVUlPdXNKNU1RRXFNYkYzMlVs?= =?utf-8?B?dzBWZWRGN2ljaXVUcGRabzNwUE4rcEVCaEVLdDdoaGFENmlTcWNSb3orZWwx?= =?utf-8?B?USsxZGVlNS9LU0htTWltUFBRWjNWZmNoa3pNNnphZTh5UXpVYTA3a0xuUzVR?= =?utf-8?B?T0dtdThBZzZzYU9JL1FhbC9INmxPZlhVSDhVSkpqY0ExZ2UyTE1rWkFDNkg5?= =?utf-8?B?SllEVzBTNERGN3VUN29majJHK0k3VFQySmU1NG5oK0VWZURaTm5keUlseEkx?= =?utf-8?B?bU5zQ1NNRjhtQTZVRFA5OURTeXZGUDgvaldCbmdGcFlpeXdxc3Q5ZGxrQkFZ?= =?utf-8?B?b1FNeENiU1BMMzZJN21CWkRDR2pLOTJBNEN6M3phZUpKbVVYMjN0TUR0UWNz?= =?utf-8?B?VVpjREJvaTM2azVjdGRkc3dHZ0dVQ1JQWWVoQzcxa0hGakdEWG9RMEZiN0pL?= =?utf-8?B?V1VvZkxqVGJ3YXMza2hrSG9xRGVsQXFPUlVFbzFpa1Fnd1gzSmU3bE5Dc25v?= =?utf-8?B?MERYN3FWcXZqTkZPRThUTkZFMDNEVS9EVmc1dDE2QmZWUlp0Z1FTS2xEbXl4?= =?utf-8?B?TmtJY1AzcHJ6TVlMaFQ1SHBHcVN0QmlGY0FLanptL1pwWEJ4T0oxMCtlVCtD?= =?utf-8?B?cjhLcEY3Z3MwRTRGK2JUR2lLdU5mbTYydVUxd3U4RlVyMk9vck90QlVoTjRt?= =?utf-8?B?RWxaR2sveHRsTmJrTTJCeGVHcjREbHhOMEZCanZxNHQrQ1N3b25pS3QybVZC?= =?utf-8?B?eUZBRHlrTmp6emZ5REo3UW5MdUt2MEdMZHNOYUozZlorRnM5ek4vUkFUT2Vr?= =?utf-8?B?OFl4NG1pdjBadjZPMUR2Mkx5dGY5QjFtN2lodUdNMWNML1hSQUs3bDYrRk43?= =?utf-8?B?empQT1RnN0pacEc1eXc0OXR3eUtKWlNoWEU5WnY4K2d0a2hwV1FnL2dxMFRH?= =?utf-8?B?WTdkZEMvdFdZeTUwU3ovUFFvZXdpcXR5WDNzdWVYeDM0WEdxUDF3M3E4SXBm?= =?utf-8?B?ZEJIWVMrVUk5ZUdDaHMyREk0ekNBRG91M1NXZi9yR05CVE5kU05NdktiR3dW?= =?utf-8?B?NFpIZmpnMW42OWtucmhkUXlSVDgzQ3crNVNJcVZ5QmRuN3NJcnFDb3VJU0M4?= =?utf-8?B?dmxaRHd6Yk1OMFVGdmdMOWJadURqRUovcXc5UTVaSDd6L0VlZDE4aXYxbFJv?= =?utf-8?B?MjBZSjBmeHFQWUs1RngvenI4UGIxQXRTcEV2RzJBWFAvMFYyUjVPa0EwdlFQ?= =?utf-8?B?eGZVcU1WWWZzN013aDcxYjhSVFlSVjRsUDFKeERwN2NmcklqMmJDU1hnZERk?= =?utf-8?B?SE1BWHlTZTFJK3k2UmxGcmJ5VFRvajYzRkhoSGo1aSsyclE0aFhLY0JlbkJM?= =?utf-8?B?Ni83TWMzODFYaEo4aEV0RHNNMFlvK1FHVTZtK0RCbWMrSWNjNXh3MnlVdlg1?= =?utf-8?B?bG5LMkJJMEZqR1hyZ3pnWDVNSW9TMDF0UjFRcGdhZlgrS0poRlFnaE9IV0Jn?= =?utf-8?B?R3NzM2xVSHBxa09tVTlPY2RPZlAwZU5Nby9PdXM5UFdDU1orZStWQmJ3Y3lw?= =?utf-8?B?NHkyQTRhQUdoZlVQdkMyMVlGWkdINDBudHV5RGMrMldwQlh0a2Q4d2pDaXdL?= =?utf-8?B?N2VqaEJBUmdoTXhnOXRpbE9BZ3dkazFCRitCOHZicGRocEVXVTc1a3loM29R?= =?utf-8?B?bThKYW5kOG9wOHl5dTh4OW9zZ3BEa09MNlptZDZteVZJaUt5Tks4Vlh1Tyti?= =?utf-8?B?Q0N5ZXVycTNSa3lRTStLUU9VMThIZ3BvVUxHbmY5aFN2bVFuNVFrMGp4Vnh3?= =?utf-8?B?ZWFXWFhRYkxwM0xZL09xb0lJNmxUNnkyb2VaNmxIanNwNW55cVprUjd0eWFt?= =?utf-8?B?NDViNHl3QU9iK2hoUDRsZ29Vc0FSOUd6cjRPeU5lcnU3dnZua0VhV3NsUzhE?= =?utf-8?B?NWtoWENTWDlFQlVUc2lxa2xBcGJNVVZkVngyeEpzTC9oSHZQZzhqZTV4bENl?= =?utf-8?Q?2M+Y=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SFNHUmQ2dGZYeDBxT3R4QnNTWTZQVTVlSU4wdGJpMWZ4dUZLSkJNR2sxQUxq?= =?utf-8?B?L2I0N29aRitqVDdvWXp6RWZPZWZEUi85TUVSUkgyQ3BOb05yTXZPTWxQS013?= =?utf-8?B?WXFGYUYzR1VSVU9KM1pYOHp2S0IxYzFrRy9FUWxnOXhRck5EYTd6ZmlpK09P?= =?utf-8?B?Q253NnpUd3YxZER3RGFFZ2pkbCtFZkYzbDJHOHpuWWFwUE02ZHhUbm93THhC?= =?utf-8?B?Y1llTThyanhmRkpNMDJKODFzT2daTUphWXl3ak93TmRrcllBWWpoR24xUGQ4?= =?utf-8?B?eFJqU2FvcWk5c0JHTEdmamJuUUdSNkNtbTlnTmE2K1lzQ1ZRamdVVW54dUNa?= =?utf-8?B?U05qZEk3cWc0VlVIelFTOEQ1SDdVYVZXMjJVeDRqeVhCWnFmRjlwTWUvWE5K?= =?utf-8?B?bjdHN05QMC9rbUwySTd2Smgzb3lQaHBUZEUzUG9MK2lEaTBrQi9wa2tMUGo2?= =?utf-8?B?dW9Xb3RNY3pteC8rNEZwUU4wTGlNWHB1cE5TUVJFSXdqbUhFeFE1U0dPQlpx?= =?utf-8?B?TDJkRVE3QVR3d2dVREZQN3dOSjJRWGNGcTl6Qjc3WUdlM2VQTktpRkl3ODFW?= =?utf-8?B?ckRpa3p3RkZIMitKQmZSOTYyODdMNXFvd25VV0MxMEZWTzVheXBCVXJxZ21m?= =?utf-8?B?MjVSWEpQaUxNNDdSOE5OTTZnenZjYjRGaFFrcmpXRDdDbjBTR3pkcE14UGEr?= =?utf-8?B?V25jNHhWejJScm9oOWFSeEdYeTFieHlNNzVQeDhUcEQ4ZWZ6SGFRNXFxMUVZ?= =?utf-8?B?UzluS1dJMDhScFhkT1RyZWt3RllkclptVHlma282dDd3RFNlVmJiVEhEMmlx?= =?utf-8?B?QzZJaHhrc2VoYVNZM0ZpSjduOXF6V2s2ekYvRi9WNEFSSGRPUDhUejZva1Ez?= =?utf-8?B?NDJnN2gzRTF3cnAxSVFlcEp1VXh6OEk2eWhsSmcvbGkzcngwb0llZVBCOHg5?= =?utf-8?B?UzlMYjRFKytwS2RDdXFob1pTK1BZb0tHeGp4WmdsUUhSd2p3UWxHNWorS3hF?= =?utf-8?B?M1FvTUllUzJ6RWs0SGFzdUtqN2lzcndzc25oRmwwM2MyTnhOb1V2d29xdUtS?= =?utf-8?B?allvZzFlMUFXZWVPU3RTYlB3NThjMFp0bVhrNkxxTUNZL0ViUndVanlYOGdQ?= =?utf-8?B?NzBjY2xzMWpkWE5hN3NWYkJLbE5NZ1YrbHRPNWtYWlIycW9TOXRaMUd0TUQ4?= =?utf-8?B?MTUrVFJLa05oNDd4VmVaSWxLbHRsOGlEeGRKU1dJYjBTVTBVL3FSMllLQ3dw?= =?utf-8?B?aHJVSDV4VHhRbTd6bnVuUGJReG9HMkI5Z0hYUkdXWGlJb05SQ0hxSGhGT1dY?= =?utf-8?B?d1JGYVpKQ3ozeHJ4dzZFWUtWMkZxZlphY09DN0ZONi9Vd21TditqZlVVSHlk?= =?utf-8?B?blIwdjdoR1kvMEJJVmcvbVBmakh3ZGlaUmovZDgzOUpjQW4rWUtWK3RUZy82?= =?utf-8?B?WXBXak94YWk2ejJBbVQyaDd0bld6ME0wWXVJbWFlL3Z4WXdBbFdPem4rZWJk?= =?utf-8?B?UEhPWVNpVGZYejJDb3VWRFFCb0NreW56VTg3dHdrRlhRR0R5c3QzK2J4UXRC?= =?utf-8?B?eHgrdDNDMVYyQ3IrL0RIZEJ5WDQ1VjY1OGtSVXJDWTRCakhxZHE4MC9lWUE3?= =?utf-8?B?aVFaSmQrblV4d2haMS9DMjJCVjFOL0l0SEV4aDdMd0ZKNFBPbmNWbXVtUmZU?= =?utf-8?B?c1hxOUVNeFREa1RJcHpubjRPQUJxd01XNTNheUNWZCtLTStyc0hxeVY1R0dP?= =?utf-8?B?TzMzcS9wd0lraXhJM2JuOXhvV1NSWTN2NVJ2YVBGYnJhSlR0VWJ1T3V3MGtV?= =?utf-8?B?cWxGb2s0NFdkOVdZVHFYK1kyNlJoZWJnNTRsNEhKbGp1NFhZYkkzR3J0Rjh3?= =?utf-8?B?R2hiSmFRMWxqTHFxaUdtMVg2UW5oT295Qm9iRk1GeTZUVCttc2c0dTV6cEo4?= =?utf-8?B?Sk9ZNnBJazV3dWVySytOaG42dmdid0Z2U2dGNVE2MGc0cHB4VitLYjVwLzNm?= =?utf-8?B?QTVBaEdXclU3Y2htcVhTZ0VuOExDV214NmF6TnlnMTQyRS9ITWduRU96NC9N?= =?utf-8?B?M1dxYklWdFFLbG1TWHI3bXdDSWNxNUU3cEY5VVYzTElPaFJDWWV0VEMyUkph?= =?utf-8?B?NGZVSVFHTE13UC9rOStOMVdxQlJGN3hQY3ZlQXNPYS9WNnJQMUxubVZmV0N2?= =?utf-8?B?OTdkNmNXcEx3aVZWaU0yaXY4bWJjRFNJZFhxSzhDWEZMVWx6Si9OSGMvLzRl?= =?utf-8?B?SEpkSnF1MXI0ay80YVo2Z1hOVlBmK2g4d1gyRlpEYVRtSmVPdUZSYURCNEJ6?= =?utf-8?B?K1lvN2VQb1FMeTBPM1hMdGdySEVVZmJ3VHVrMklQL1ZNTUo0a1UyQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: c772f90e-eb85-4e49-cd79-08de539544cc X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2026 17:49:30.4683 (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: ZhNBJ4cjUpikblgJn0kHYFdjOXZ7AZDPBV31UQ1EZ1kH6gyooRrHVkB70WI99eU6XhFyXEazEQIaHRtbZ7mSGA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB7774 On Tue, Jan 06, 2026 at 02:58:11PM +0100, Jan Beulich wrote: > Callers may pass in TSC values from before the local TSC stamp was last > updated (this would in particular be the case when the TSC was latched, a > time rendezvous occurs, and the latched value is used only afterwards). > scale_delta(), otoh, deals with unsigned values, and hence would treat > negative incoming deltas as huge positive values, yielding entirely bogus > return values. > > Fixes: 88e64cb785c1 ("x86/HVM: use fixed TSC value when saving or restoring domain") > Reported-by: Антон Марков > Signed-off-by: Jan Beulich > --- > An alternative might be to have scale_delta() deal with signed deltas, yet > that seemed more risky to me. I won't go that route, the caller can figure out the signedness of the result as needed. > There could likely be more Fixes: tags; the one used is the oldest > applicable one, from what I can tell. > > A similar issue looks to exist in read_xen_timer() and its read_cycle() > helper, if we're scheduled out (and beck in) between reading of the TSC > and calculation of the delta (involving ->tsc_timestamp). Am I > overlooking anything there? If we are scheduled out in the middle, and the ->tsc_timestamp is updated, ->version would also be bumped, and hence the loop will be restarted. I don't think there's an issue there. > stime2tsc() guards against negative deltas by using 0 instead; I'm not > quite sure that's correct either. Hm, we should likely do the same for stime2tsc() that you do for get_s_time_fixed(). Given the current callers I think we might be safe, but it's a risk. > amd_check_erratum_1474() (next to its call to tsc_ticks2ns()) has a > comment towards the TSC being "sane", but is that correct? Due to > TSC_ADJUST, rdtsc() may well return a huge value (and the TSC would then > wrap through 0 at some point). Shouldn't we subtract boot_tsc_stamp before > calling tsc_ticks2ns()? amd_check_erratum_1474() runs after early_time_init(), which would have cleared any TSC_ADJUST offset AFAICT. There's a note in the initcall to that regard: /* * Must be executed after early_time_init() for tsc_ticks2ns() to have been * calibrated. That prevents us doing the check in init_amd(). */ presmp_initcall(amd_check_erratum_1474); > A similar issue looks to exist in tsc_get_info(), again when rdtsc() > possibly returns a huge value due to TSC_ADJUST. Once again I wonder > whether we shouldn't subtract boot_tsc_stamp. I would expect tsc_get_info() to also get called exclusively after early_time_init()? > --- a/xen/arch/x86/time.c > +++ b/xen/arch/x86/time.c > @@ -1649,8 +1649,13 @@ s_time_t get_s_time_fixed(u64 at_tsc) > tsc = at_tsc; > else > tsc = rdtsc_ordered(); > - delta = tsc - t->stamp.local_tsc; > - return t->stamp.local_stime + scale_delta(delta, &t->tsc_scale); > + > + if ( tsc >= t->stamp.local_tsc ) Should we hint the compiler this is the likely path? > + delta = scale_delta(tsc - t->stamp.local_tsc, &t->tsc_scale); > + else > + delta = -scale_delta(t->stamp.local_tsc - tsc, &t->tsc_scale); > + > + return t->stamp.local_stime + delta; LGTM: Reviewed-by: Roger Pau Monné However I see Anton still has concerns that this patch doesn't fully fix the issue he reported, and I'm afraid I don't really understand what's going on. I will have to take a more detailed look at the thread, or possibly attempt to reproduce myself. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 14 18:27:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 18:27:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203659.1518729 (Exim 4.92) (envelope-from ) id 1vg5aK-0005I8-C1; Wed, 14 Jan 2026 18:27:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203659.1518729; Wed, 14 Jan 2026 18:27: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 1vg5aK-0005I1-9I; Wed, 14 Jan 2026 18:27:12 +0000 Received: by outflank-mailman (input) for mailman id 1203659; Wed, 14 Jan 2026 18: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 1vg5aJ-0005Gf-Oq for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 18:27:11 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a36e449f-f176-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 19:27:10 +0100 (CET) Received: from nico.tail79467d.ts.net (93-44-185-98.ip98.fastwebnet.it [93.44.185.98]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPSA id 4BB994EE3C1D; Wed, 14 Jan 2026 19:27:07 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a36e449f-f176-11f0-b15e-2bf370ae4941 Authentication-Results: bugseng.com; arc=none smtp.remote-ip=93.44.185.98 ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1768415228; b=lowYskxunXHL8atTnbMNCtL2jJGYGnZxwH3co/5qseUL/t6HXb/msLdxJ3CBpLcBgwTn GXqqy7oykGt9tpVKER4Jw5x91anZHnsNbhDBLl+zqSNu74w1Hef380IT+Rf5q5EHOU9u4 pCIL7SUO6yqkiOrWkuoNUMKeUEkQFizyUejbB3hjYjDOacmvP78fNxMaRpieIUY52rz2L LBPbrrF1H6dGIzH/2Cz3wJguIBeBcNJsrfhozEWSJ7y7KbHhY9kct35O3fyctdnEvlILB XOwXyDzVartbmVuz7vKoIWyqYeFAL5g55To0moEMlplQ3inlZrriFNUNBZyaZgtBShtql EZEJQn1lbFjiK4tZIcsER9bNqMOtUuBxe4faImv+Qr9/5JKD70LBCNV4mxzxv4kgtl8Dv 2Cfiff8dw285AvTCLsQX0cbmfqU/PidJtTXI/MqgY2VbGm+rpShgPErjYzm5G9rnzLYK0 3k1Ep5u6WiJeyIOt0e0QSUQr0xJEZvr0U2IcKNir4dpVv84AKz65+UMA5wxZG6IP9L+iS hxI0BnTtRfhlqne9sCAH1fYmSo7JNK5bOkCJj7XrhYpA1T58FJG8K3MMlcCG4tT5A49SD bIQP0V/P79P42wf0eVqtGGRHBJO7uzZ5syaZzJyC0Mh2N+XnWgKXdd/uix6CbMI= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1768415228; h=From:To:Cc:Subject:Date:Message-ID:X-Mailer:MIME-Version: Content-Transfer-Encoding; bh=DDvUkwhNpt4+B5Le4owhqbqzLz2eZLjRMbuVMhMsg1s=; b=j8+T4ZVC8v65TGQTO8IJwhi3kTo3DNY7cfAD76aRs57ps1OzzrhlzUtUZRFFReUDD74v gzxP9yss6HrC9vRKgKrt2B0xNS2KBeNrQeKx0WzoxnJVVeUfKAjeUYtSRxHQ2E9nL9PQQ teYSIuekDsQiQMVB2APqkVS1oYuPbiBJC90A/NBI9UI4gpT7zXddTtFdqNXOYSsQzsXSe R3n/VwTG/Uj69Wm2IFfOvvcJ1SGj8fl7XvMDGLnO1re4bobZPvzMG0EAOH/6fTpOUhzGg LyA6oFFr75FH0RPzfJDS6EkJcJKmaeueK/waRTjSEzDPTzVHJFFP8YFEM8HxwnChe/Ekj d/Tu10SzqJmfqm30hBP/h+eblvXmACzq9XSs1oMG6/8XV53ENltxmMNdwDKZ8eL2S9E6D ztnEUiF21Xk6/0igFgtQFExMrClJdc0mqYwcc+/DP+JFsvQmA5VHtO80HIUT/pjSBcI5e G0SzSDlEwwjrYgItzEVHMwXctYpi/vkWUvHVu0zSApGnlLBViOLniOPg9X70JUFUm8t33 WVf+Myy7GChFpT+pXz3hwLUuLK7waanORLZoQhBwy1QFWXYWLBJEV0GGEqEruEa6lrbjG AG/Fvc1uEa22Qf4hhTTtRRSEa2Frxov16+UVeJMfI01jdBZZZCfPJ5JzYwj3KH8= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=93.44.185.98 From: Nicola Vetrini To: xen-devel@lists.xenproject.org Cc: Nicola Vetrini , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [XEN PATCH] x86/mce: use offsetof to determine section offset Date: Wed, 14 Jan 2026 19:27:03 +0100 Message-ID: <350bd19ec4b0b190911d748df6ec92c626e7151a.1768415160.git.nicola.vetrini@bugseng.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit There is no reason to use pointer difference. A violation of MISRA C Rule 18.2 ("Subtraction between pointers shall only be applied to pointers that address elements of the same array") is also resolved because the object to the subtraction is applied is not an array. Signed-off-by: Nicola Vetrini --- Found while randomly browsing violations of the rule on the allcode-x86_64 scan. --- xen/arch/x86/cpu/mcheck/mce-apei.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/cpu/mcheck/mce-apei.c b/xen/arch/x86/cpu/mcheck/mce-apei.c index b89502088243..21aabe2027d0 100644 --- a/xen/arch/x86/cpu/mcheck/mce-apei.c +++ b/xen/arch/x86/cpu/mcheck/mce-apei.c @@ -74,7 +74,8 @@ int apei_write_mce(struct mce *m) rcd.hdr.record_id = cper_next_record_id(); rcd.hdr.flags = CPER_HW_ERROR_FLAGS_PREVERR; - rcd.sec_hdr.section_offset = (void *)&rcd.mce - (void *)&rcd; + rcd.sec_hdr.section_offset = offsetof(struct cper_mce_record, mce) - + offsetof(struct cper_mce_record, hdr); rcd.sec_hdr.section_length = sizeof(rcd.mce); rcd.sec_hdr.revision = CPER_SEC_REV; /* fru_id and fru_text is invalid */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 14 18:29:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 18:29:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203674.1518743 (Exim 4.92) (envelope-from ) id 1vg5cx-00061s-4F; Wed, 14 Jan 2026 18:29:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203674.1518743; Wed, 14 Jan 2026 18: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 1vg5cx-00061f-1X; Wed, 14 Jan 2026 18:29:55 +0000 Received: by outflank-mailman (input) for mailman id 1203674; Wed, 14 Jan 2026 18:29:54 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg5cv-0005zq-Qk for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 18:29: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 048173c3-f177-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 19:29:52 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by AS2PR03MB9465.eurprd03.prod.outlook.com (2603:10a6:20b:59e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Wed, 14 Jan 2026 18:29:47 +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.9520.005; Wed, 14 Jan 2026 18:29: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: 048173c3-f177-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DXOdQ4I1yc4A32P5d79x9Rl+W1yJa3GVSoz8LOQGn2vCu3MROPa6NOvof/F+KkV7MK1/XlSYl2hahy9Mup7Kendb43+D3Ug+YYUARgv2eL0B256XQhxFW4UbTyQYIy8AtdHuqEOkeMes9sCO5iYJcIq4SfnZqGXO4FniHG7rlEpDdUmIXlnQZzypDyKMpmgAh+reSx1CrnkLRErct4bu7QS9zGTt3Om3TYXIWNgrx1UGMLgIUnNHx239qy4/bsmlytpmMtis1ZU62dU+3VpWcX9YvlEo6LZj+hFXe/+sNd99h4GRWHm6rD2hW9b4c+dl/MzoYadCimPdcpXApkMoJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Dy0RGQQWd4FKgS65hnH7id3SYWXr8C6/1gGYmu7c3bc=; b=dTDu11A4FhyFQ1ZpNeBkpchFlMg/0Pztg+rpuESNhx+dMh9bl3kfSVjk6sSH/I6MhyM2/9pm84daZx3sUhUXj5nT1sTHyN4Qm/vpPfyZ9KW9f0KdbMBysade77tLHWXQ/OI3MRPnA9oYkvg62asrrh7FLx/bRZC6hB2oqhEPl1jdMO/m6LUnv8LM2M57+y0Qvx+sHnQIVRNWM28TFrQKdrVu27WC6F2t65SIo2GmmRkdcJehd9KVnkMdZvPP534lZUYw36oqz6ybmV4skzID1Xl6zhwChcFNLStG6PZwJ+T9v8c/qBuZQgy0zBuwKLBk93ohZ41aAXEe5oy26j9dqg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Dy0RGQQWd4FKgS65hnH7id3SYWXr8C6/1gGYmu7c3bc=; b=cq6VxZhOCR1q3Xd1M5aDYEslNxTJJ9NnSctuwjDk/+/moah+tFtIF5vOqohQTEL1BLZNpk3r7nPSl8HLLU63+Eh0+R8LuxJB84xCsMm3Iv5EALXFTNmV5zncmcQe6MAXpmm+FFxK3YItgTxf3cRLL9C1t2xcwbVV71tUurX4wJWXZ9WeBgDN+sVLOR1UuW1IObuQuBb/50bdJi+UDZPKy/2+1LWQtpMuY8MxQtoCB2bjH1a40wOI0W2EMXPNqwOfILDewhByQtpOxJmoTdi1rctl++8s9d0h/TeHtJpw8P3dDRfBiogb34FW1Ix6ADQxzQU20+gx0JTolouGUWG3kw== 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 , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v7 0/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent support Thread-Topic: [PATCH v7 0/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent support Thread-Index: AQHchYPDNaJFusNM7EOqlUnzJsl6Hw== Date: Wed, 14 Jan 2026 18:29:47 +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_|AS2PR03MB9465:EE_ x-ms-office365-filtering-correlation-id: 8e65a991-ae29-4b1f-4237-08de539ae5bc x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|7416014|376014|38070700021; x-microsoft-antispam-message-info: =?utf-8?B?ZGJUa0x5cnBEbFRncUdsZ2Y3WUlURlcyRnprRk1EdDQwY1lQOSsrNkpUM04w?= =?utf-8?B?RDhBU1FZaGZ0RWMvZmhIL0hiaU1yVHNpNUF3OWRORFE1aUt0WkIxWUtsQ3I4?= =?utf-8?B?NkZKTjJwUG9BVUIrWWZWR01QMFVHTkJIN1ZnU3kxK3pJMkJtemtTOWNlTjdU?= =?utf-8?B?cnZXdERKVTNZRjRYTE9UQUZoSlNtY0ZMNVZlMHhMTndLVzNQOUZBY0dTaTZN?= =?utf-8?B?VzI4TGI3bUwyVTJDZXNRd1pTQ2VvdjhxbXRIdWprRHZJdmdQRE05ekVTUFRV?= =?utf-8?B?WVc5RHpLTVpjU1QreGVaQWZtYTVYQW1mRHFMQmFQN3FiS2RxemVGMG1sdG8y?= =?utf-8?B?ZThqd1JxRkU2ZEVKZVprTUpHVklQejgrZTRsRzFQa2JrQXB1ZUd1K1BuTHM5?= =?utf-8?B?bVdweXpUR29Pa0pQVDd5dHZqbjE5b1lDUFRXbjRkWXlKcUFQRWRNcnhXa3RG?= =?utf-8?B?T3c0Q2RKY1BROHUvbmIzQXBPakxxc2tScW43aStLd1phUGlKS0xtTFo2aXMz?= =?utf-8?B?MnFSdlV6UnBLZForM2MzSDc4RS9KSktWeCtXeG5EVjdsSVBjSWlyY2I1cENw?= =?utf-8?B?dzliOFZDbVNEUEZ4UUlLbmVaTXBCYVlRNk1LNjFDQ2ptektCd1BKdGxlQzZw?= =?utf-8?B?QVNueVphajhyWHlsVXVQUk9EQ3huVGVNTm0vYXMwWmhCMDEyMmt6c3phaHdB?= =?utf-8?B?bklSREhraFBBTXhGeVl3TGpGbVlLaVBqeFFuaURtSTRrOE9ncXBqeGM4RWNt?= =?utf-8?B?a3FWWkhkWTZJWWtadUlQRDV0dW5oWkZMRkFCVDVMU2hKZTRudUhuR0k3eXVm?= =?utf-8?B?SGFiazliNjJhV0dvY3c0N2JHN1ZlbW8zWGlXeENqeFY2VFVyYWdXNGQyWW9w?= =?utf-8?B?TVhGbHVvMjlNT3lNWlg1RU11Z3F0V3dCRG5RRjVGRFlXUzNHQi80cGw5NHh2?= =?utf-8?B?MWdMaTJFZWc0MHMwYTU1OFRnVXBoSDc5RTJOdTFHZnBmYm5NSE9nRG1FelN1?= =?utf-8?B?aHA3bEhNN1dDZksydnViRGdlUlpJQkdCalpBTzc4M0hKak13NExodisvOXVH?= =?utf-8?B?U05vWTl5b08xTmVUQ3YvOVdIZ09HMHNjOSs3VmdoMDg3Zlpmem9xVkplTW0y?= =?utf-8?B?ckpZa3FraDc0dlBDemhlQkorZERUNUZQWmRhU25DZklWS2d2Ti9aUWJxT3Yx?= =?utf-8?B?bDhkMllQbzduakZuSkx3TW1RK2tLR3pheXBnaW1VcGZhYzVRWTJNNE1vR3Iz?= =?utf-8?B?ZDdsOFA2blZRUzBGM2VmMEJXZGRSSWl0aVpNaDUxbzl1YWcyUkpVNlFhRHU2?= =?utf-8?B?dnZ6S21BdFF4QVJVbU1SK0lOb1BCMEhvbDZQSlBScWZManA2bkJuWmx4TWZB?= =?utf-8?B?bDNVUllwNGdzS0hEaC9wR3lFc0VLZi93WmNBcEQyaHY3ZTlYVDZ2L0lFWStZ?= =?utf-8?B?S2JRcTRTUDR3MDBpenkwTGw2cnpXT0Q1NXA2czdwaU90dTdVZTAxbnBRTEJC?= =?utf-8?B?NDVaYlUxT1VqbzE3RGY0VVZmWlU1cXMwOVFhc0dHdVIwUWJEa2ZHMkl5eWta?= =?utf-8?B?VU1kb0RZU1N1aXRYZ0twdHVLMUxHc1ExY0xpZno1SXJvL3pKWkFjVkZzVWdz?= =?utf-8?B?Y1hFcWNTZjF5UHR2dk03aFdaeFpac1VuUjcrbnNNSFFWNURKRmZBN0xBNlg3?= =?utf-8?B?elNmemFIRGVpOWFJV2IzaFFXN2QwaCtwUnB1VmZVZUgxMC81UDdsUFRQd1Fy?= =?utf-8?B?bHZQRWRHUUROdlczV0lIUGFkSFRpUUM3Rlh3VlhQZVJINHdTdkFudHM5cis5?= =?utf-8?B?NGJBQlljNnNyVmNyM0hTaFpNSmZ5ZzJGdXFBa1c0UlhOdGFmemhZak1yem9j?= =?utf-8?B?WkU1aU4zd0pKbzNDc3lVNFZiRDVYTEpXNHN3UjJtdytuTTM4clhNRGUzbkFI?= =?utf-8?B?ZlNNeFNDbEVwSnVMMEo4K04rWXNlVW5DK0grdUFGN1Fmd3Q2ZXNVNk1QUEhs?= =?utf-8?B?V0hxSHZxMXF6REtYcFJiUHhWcS8vY2R5aWxsS0JaUUF3aHVkUmJsVlpZa2kx?= =?utf-8?B?U0FmdXpscFlzekREekJucGRXck9XYmJNbnJiQnZ5Y2xCWHVLV2hrdHFSTS9p?= =?utf-8?B?R3B3dGNaZlRvUnc1SXdMR3l3SU1hakNjeExQUFFHdTBKRjUzdFg0QW1nSE5Z?= =?utf-8?Q?VJvpipn8e7g6YPPNh319gUo=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)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dExiR3ZYS3h3aEh1U3diZTZsQXh2SHhoNzB3OTVVbXl0UFQxMXJsMThOcm55?= =?utf-8?B?L3djMWJTMnRHVWxPQTY3TGxmNlhnOFAyR0ZpQjZCWUJkK0ZQWmVNeWRuMmpp?= =?utf-8?B?SmREWXIzSFh2WjNJclBta3ZuVHlqL2RSNXR6RC9uamthM1BmQVdLc3FzdEtu?= =?utf-8?B?bmprTUJ2bmNhczhtN05QVFJEcUFteHhqVzR4QlExdmtER2RlZmhGclZLR2dL?= =?utf-8?B?bU9DbTFVbG9LNS91dHZqZnY2Uk15R2N3U0RlU3pLUnBtVUlPaCsrU3Fic250?= =?utf-8?B?eE01Q3BYeGd4Uk1BQStRQzZDaHA1SmhEQ3c1YytHcGV1aTRCZzEwSHdrZWdE?= =?utf-8?B?TFNWWFo1dzd0RmlrSk1MNlp2UENKZlp1cFFjVGMxMjlmeTBNd1ZzUkxwdGNK?= =?utf-8?B?MU1SQkJObzZ3OUw2cVd0UTc2ZTdISHl0NFNUdGpoQ3dYOTVydUJUcWFCbFd6?= =?utf-8?B?Z2c3b1pZRDA5eFBSVVFCMXRTbjhzbGRYYVk1R1RkOGkyRC94WDRUeGxha1ZP?= =?utf-8?B?SVFzbXVFMkVYbEdNbkR5WW5SaitTZUJkSFZqZ2g2MTZsai9TQ1BDWjZ5YWJy?= =?utf-8?B?Y0h1WDBtdUlFWnNPdjJpb2pPTjFjUllZbll0YSt1ZmFjNm9HZGRSRyt0NzdQ?= =?utf-8?B?ODlpUUxqcFlEQ1BUaWVLSXFrREI0d3A2NU82cDZZNmpwY3F2d1NrVGRRWnIx?= =?utf-8?B?RHRsYzM0MERkWW1FcHdEcW9kZHJTN2Jvd1J3ZFViNUtTVkNsc2Q2d1ZYM2Uv?= =?utf-8?B?NFMxaGt3eDdXREYvY2FUMlVaTGZUak5yZ3Z4RFpsdHVZTEc1MkZvYkMrTmxR?= =?utf-8?B?cytWRjBQREx6TUs4U3N0S3dzOWdYcUJWbEZPRjBMZ0YrTXFRdU5aMTJFRkNj?= =?utf-8?B?c1UvS3FTckpQVk9WaG1tRU0yejUwK01ZNlFMLzVURG1wTHJaVi9tbE5DbTZz?= =?utf-8?B?TTAzaTdzUUMzbHBqcStQV1pGVU1Zdmt0Tzdqc2IyZS9PRFJ5UVkvQ0tURUUv?= =?utf-8?B?QzA4T1lPNmw5c3dyblpwOVNpNXkwNzNhV2ZZaFhLVXFMdUZPWFNPaStZOHBl?= =?utf-8?B?SVJaeVA0cnJNeklvZS8vU21DNklPU2F0blBVa2hOWmFPVllxN0FkdFI2R0ZR?= =?utf-8?B?WWtmUVFTZkJQSlE3S1VaZkpldUd4dEZpRy9uRVE2ZkFtS2M3SENVc1VmMlpT?= =?utf-8?B?ZnFjUVpQVGVoNGllMndSUHZMYktBNzkvWmVaZVRqSnEvUEM5eWdNaVZzdTdY?= =?utf-8?B?a2JGaDY2d0VLaUdUMVdYeTNFY3ZOekZRK1NLM20zdDY2Q0N6dVp0bDhQUlpa?= =?utf-8?B?Vm9tY1V6bTlwYklNdE9PUytOOUZZWEZEcWJXNERROTh5Q3VOcTQ3NW8ydXZS?= =?utf-8?B?MHhjUm5KSDVFZlVvQnYvMC9td3FPb1pTVFBKVFg2WldWNVA4dzc0NXg5RzMx?= =?utf-8?B?VVhpU0NOckZOaGgxdnZTSndaVG04U3FxL0MrZHdiNXBxYUtOZnlnSWNRa0s1?= =?utf-8?B?Z0NyY2JGVnJpRHJHSlpRUytGM284Rnk1WHVXRmp2RmZMSnE0Y2g4MThLWDhv?= =?utf-8?B?YnJvcEQxaWxvNE5CRUx0aUhtOEUxTG55V1hsa2E0eFBBUGZSR2M1a2NuTFd1?= =?utf-8?B?SEFqSXFZdXhqY3FSLzg0VGU5MXdMR0dMWnM5K280VHZ5bWx0YkdKQWcxanZH?= =?utf-8?B?NVdka3YzOGtZVno2Tk5YK3VxeGxudFVNMUpvb0t5TlVvaHhEbmdKV2RYM2U1?= =?utf-8?B?WkllTWhJazBQeXB2K252bnQvN04zbHpvRnFETmN5MXpzdU9aZk5VdFg2cnkw?= =?utf-8?B?RDN3NW9aZ09jbjRVdW5lSUhQaWRxSnozMjg5QWl3bjByWElkb3BFZUNQQ0dB?= =?utf-8?B?MHVxelo2NlFtY1Q2bXRLMXFnak9xWnY3dEhQUHp6WUN5R00zSkxseXhsck1z?= =?utf-8?B?dnMzVWFCaERvV3ZVYlNUaTVUcHBPanRWQWlRbVJrWUV5TzY3RTBxd3hEV01w?= =?utf-8?B?aE5sejRKR20xNWs4ckFvb2dlaHRSOWM5bkt3UFpnNm4zVFAwNmRVdldyeklh?= =?utf-8?B?d2ZvbDhuZHhNdEtyUmdCMnVzRHZSMGptTzhZZFpNYjZiMzRwdkErd0g5eVlq?= =?utf-8?B?ZklJWExQd2xtUjhja2FjUnJneVFtYnlidUV4L0RvRFRSaktsdllweGdoMCsv?= =?utf-8?B?N2JiOVBxVmxVOHVvdWcrd2xiOXZFSlprengvTGJjN1lxOTZFTFNYa3ZLRHhS?= =?utf-8?B?UnpsM0tQQnV4QzQ5OW1PSjU5R0g4ZHNYcGVpUk9oc3FBa1gwNXp2QjdXQitq?= =?utf-8?B?S0pkUk5nTXk5QWlMZ0V6enFtWEJwb0Q1R0hRbVdYRWpKaGFPTzg0VVdJRWY4?= =?utf-8?Q?2n+29LNpEp14E6+M=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: PAVPR03MB8946.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8e65a991-ae29-4b1f-4237-08de539ae5bc X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2026 18:29:47.7448 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: g52xM7euuoobRvk74oUQMZMs3rU4hxWOv9627T1Cl2SNYzJA4Ct7YOx+Fkbtt7uLTZ3vfplGbMgheSUXSYR3keT414M+2znp4lgS90R8FT4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9465 SW5yb2R1Y2luZyBwYXRjaCBzZXJpZXMgd2hpY2ggaW5jbHVkZXMgaW1wbGVtZW50YXRpb24gb2Yg dGhlIFNDSSBTQ01JDQpTTUMgbXVsdGktYWdlbnQgc3VwcG9ydC4NClRoaXMgcGF0Y2ggc2VyaWVz IGZvbGxvd3MgUkZDIHY1IFszXSBzZXJpZXMgd2hpY2ggd2FzIGludHJvZHVjaW5nIGJvdGgNClND TUkgc2luZ2xlLWFnZW50IGFuZCBtdWx0aS1hZ2VudCBzdXBwb3J0LiBBZnRlciB0aGUgZGlzY3Vz c2lvbiBpdCB3YXMNCmRlY2lkZWQgdG8gc3BsaXQgZmVhdHVyZXMgYW5kIHVwc3RyZWFtIHNpbmdl LWFnZW50IHN1cHBvcnQgZmlyc3QuIFRoaXMNCmZlYXR1cmUgaXMgbWVyZ2VkIGZvciBub3cgdG8g djQuMjEtcmMyLg0KSSdtIHN0YXJ0aW5nIHRoaXMgcGF0Y2ggc2VyaWVzIGZyb20gdjYgdG8gc2F2 ZSB0aGUgZGlzY3Vzc2lvbiBoaXN0b3J5DQphbmQgZG9uJ3QgYnJlYWsgY2hhbmdlcyBsb2cuDQoN ClBhdGNoIC0geGVuL2RvbWN0bDogZXh0ZW5kIFhFTl9ET01DVExfYXNzaWduX2RldmljZSB0byBo YW5kbGUgbm90DQpvbmx5IGlvbW11DQotIGFkZCBjaGFpbmdlZCBoYW5kbGluZyBvZiBhc3NpZ25l ZCBEVCBkZXZpY2VzIHRvIHN1cHBvcnQNCmFjY2Vzcy1jb250cm9sbGVyIGZ1bmN0aW9uYWxpdHkg dGhyb3VnaCBTQ0kgZnJhbWV3b3JrLg0KQ2hhbmdlIHdhcyBkb25lIGluIHR3byBwYXJ0czoNCiAt IGNhbGwgdG8gc2NpX2RvX2RvbWN0bCgpIHRvIGRvX2RvbWN0bCgpDQogLSB1cGRhdGUgaW9tbXVf ZG9fZHRfZG9tY3RsKCkgdG8gY2hlY2sgZm9yIGR0X2RldmljZV9pc19wcm90ZWN0ZWQoKQ0KIGFu ZCBub3QgZmFpbCBpZiBEVCBkZXZpY2UgaXMgbm90IHByb3RlY3RlZCBieSBJT01NVQ0KDQpQYXRj aCAtIHhlbi9hcm06IHNjbWk6IGludHJvZHVjZSBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJp dmVyDQotIGFkZCBYZW4tc3BlY2lmaWMgU0NNSSBjb250YWluZXIgY29tcGF0aWJsZSBgeGVuLHNj aWANCiAgdW5kZXIgYC9jaG9zZW4veGVuYDsgWGVuIGJpbmRzIG9ubHkgdG8gdGhlIGBhcm0sc2Nt aS1zbWNgIGluc2lkZSBpdCBhbmQNCiAgaWdub3JlcyBvdGhlciBTQ01JIG5vZGVzIChlLmcuIHVu ZGVyIGAvZmlybXdhcmVgKS4NCi0gYWRkIGBzY21pLXNlY29uZGFyeS1hZ2VudHNgIGFuZCBgI3Nj bWktc2Vjb25kYXJ5LWFnZW50cy1jZWxsc2AgdG8gZGVzY3JpYmUNCiAgZnVuY19pZC9zaG1lbS8o b3B0aW9uYWwgYWdlbnRfaWQpIHR1cGxlcyBmb3Igc2Vjb25kYXJ5IGFnZW50cy4NCi0gZWFjaCBn dWVzdCB1c2luZyBTQ01JIHN1cHBsaWVzIGl0cyBhZ2VudF9pZCAoZG9tMCB2aWEgYGRvbTA9c2Np LWFnZW50LWlkPWAsDQogIHRvb2xzdGFjayB2aWEgYGFybV9zY2kgPSAidHlwZT1zY21pX3NtY19t dWx0aWFnZW50LGFnZW50X2lkPS4uLiJgLCBkb20wbGVzcw0KICB2aWEgYHhlbixzY2lfdHlwZWAg KyBgeGVuLHNjaS1hZ2VudC1pZGAgaW4gYHhlbixkb21haW5gKS4NCi0gZmFjdG9yIG91dCBTQ01J IGdlbmVyaWMgZGVmaW5pdGlvbnMgYW5kIHNobWVtIGNvZGUuDQotIHBhc3N0aHJvdWdoIGNvbmZp Z3VyYXRpb24gZm9yIFNDTUkgZ3Vlc3RzIG1pcnJvcnMgb3RoZXIgSFcgcGFzc3Rocm91Z2guDQoN ClBhdGNoIC0gZG9jczogYXJtOiBhZGQgU0NJIFNDTUkgU01DIG11bHRpLWFnZW50IGRyaXZlciBk b2NzDQotIGRvY3VtZW50IHRoZSBYZW4gU0NNSSBjb250YWluZXIgdW5kZXIgYC9jaG9zZW4veGVu L3hlbl9zY21pX2NvbmZpZ2AgYW5kIHRoZQ0KICBtZWRpYXRvcuKAmXMgYmluZGluZyBydWxlczsg dXBkYXRlIGV4YW1wbGVzIGFjY29yZGluZ2x5Lg0KDQpBbGwgWGVuLXNwZWNpZmljIFNDTUkgY29u ZmlndXJhdGlvbiBub3cgbGl2ZXMgdW5kZXIgYC9jaG9zZW4vZ2ANCnRvIGtlZXAgaG9zdCBEVCBj aGFuZ2VzIGlzb2xhdGVkIHdoaWxlIGxlYXZpbmcgdGhlIGhvc3QgYC9maXJtd2FyZS9zY21pYA0K dW50b3VjaGVkIGZvciBEb20wIGNvbnN1bXB0aW9uLg0KDQpDb2RlIGNhbiBiZSBmb3VuZCBhdDoN Cmh0dHBzOi8vZ2l0aHViLmNvbS9vbGVrc2lpbW9pc2llaWV2L3hlbi90cmVlL3NjbWlfbWFfdXBz dHJ2Ng0KDQpbMV0gUkZDIHYyOg0KaHR0cDovL3BhdGNod29yay5rZXJuZWwub3JnL3Byb2plY3Qv eGVuLWRldmVsL2NvdmVyL2NvdmVyLjE2NDQzNDE2MzUuZ2l0Lm9sZWtzaWlfbW9pc2llaWV2QGVw YW0uY29tLw0KWzJdIFJGQyB2MzoNCmh0dHBzOi8vcGF0Y2h3b3JrLmtlcm5lbC5vcmcvcHJvamVj dC94ZW4tZGV2ZWwvcGF0Y2gvMjAyNTAzMTExMTE2MTguMTg1MDkyNy0xLWdyeWdvcmlpX3N0cmFz aGtvQGVwYW0uY29tDQpbM10gUkZDIHY1Og0KaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRl dmVsL2NvdmVyLjE3NTMxODQ0ODcuZ2l0Lm9sZWtzaWlfbW9pc2llaWV2QGVwYW0uY29tLw0KWzRd IFNDTUkgc2luZ2xlLWFnZW50Og0KaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsL2Nv dmVyLjE3NTY5OTU1OTUuZ2l0Lm9sZWtzaWlfbW9pc2llaWV2QGVwYW0uY29tLw0KU0NNSSBzcGVj Og0KaHR0cHM6Ly9kZXZlbG9wZXIuYXJtLmNvbS9kb2N1bWVudGF0aW9uL2RlbjAwNTYvZS8/bGFu Zz1lbg0KDQpTQ01JIGJpbmRpbmdzOg0KaHR0cHM6Ly93ZWIuZ2l0Lmtlcm5lbC5vcmcvcHViL3Nj bS9saW51eC9rZXJuZWwvZ2l0L3RvcnZhbGRzL2xpbnV4LmdpdC90cmVlL0RvY3VtZW50YXRpb24v ZGV2aWNldHJlZS9iaW5kaW5ncy9maXJtd2FyZS9hcm0sc2NtaS55YW1sDQpodHRwczovL3dlYi5n aXQua2VybmVsLm9yZy9wdWIvc2NtL2xpbnV4L2tlcm5lbC9naXQvdG9ydmFsZHMvbGludXguZ2l0 L3RyZWUvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2FjY2Vzcy1jb250cm9sbGVy cy9hY2Nlc3MtY29udHJvbGxlcnMueWFtbA0KDQpSZWZlcmVuY2UgRUwzIEZXOg0KUlBJNTogaHR0 cHM6Ly9naXRodWIuY29tL3hlbi10cm9vcHMvYXJtLXRydXN0ZWQtZmlybXdhcmUvY29tbWl0cy9y cGk1X2Rldi8NClJlbmVzYXMgdjRoOg0KaHR0cHM6Ly9naXRodWIuY29tL0dyeWdpcmlpUy9hcm0t dHJ1c3RlZC1maXJtd2FyZS9jb21taXRzL3JjYXJfZ2VuNF92Mi43X3Y0eC1zY21pX3VwZC8NCg0K YmFzZS1jb21taXQ6IGRiZTYwZjI0NGMgKFVwZGF0ZSBYZW4gdG8gNC4yMSwgMjAyNS0wMi0yMSkN Cg0KQ2hhbmdlcyBpbiB2NzoNCi0gdXBkYXRlIGRvbWN0bCB0byBidWlsZCBvbiBib3RoIEFybSBh bmQgeDg2IHBsYXRmb3Jtcw0KLSBtb3ZlIHJldDEgZGVjbGFyYXRpb24gdG8gdGhlIHRvcCBvZiB0 aGUgZnVuY3Rpb24gYXMgcmVxdWlyZWQgYnkgY29kZQ0Kc3R5bGUNCi0geDg2IGd1aWRhbmNlOiBy ZW1vdmVkIHRoZSBzcGVjdWxhdGl2ZSBub3RlOyBoZWFkZXIgbm93IGp1c3Qgc2F5cw0KICBlYWNo IGFyY2ggc3VwcGxpZXMgaXRzIG93biBpbXBsZW1lbnRhdGlvbiBvciBtYWNyby4NCi0gbmFtZSBz cGFjaW5nOiBkcm9wcGVkIHRoZSBkb3VibGUtdW5kZXJzY29yZTsgdGhlIGhlbHBlcnMgYXJlIG5v dw0KICBtZW1jcHlfZnJvbWlvIC8gbWVtY3B5X3RvaW8uIFRoZSBoZWFkZXIgYWxzbyBleHBsaWNp dGx5IGFsbG93cyBhbg0KICBhcmNoIHRvIGRlZmluZSB0aGVzZSBhcyBtYWNyb3MgYmVmb3JlIGlu Y2x1ZGluZyBpdC4NCi0gdXBkYXRlZCBpby5jIHRvIGtlZXAgMzItYml0IHRyYW5zZmVycyBzYWZl IG9uIGFybTMyDQotIG1vdmVkIHRvIF9fcmF3X3JlYWQqL19fcmF3X3dyaXRlKiBhY2Nlc3NvcnMg dG8gYXZvaWQgZW5kaWFubmVzcyBjb252ZXJzaW9uLg0KLSBzcGxpdCB0aGUgaGVscGVycyBpbnRv IHNlcGFyYXRlIGNvbXBpbGF0aW9uIHVuaXRzDQotIHJld29yayBzY21pIG5vZGVzIGZvciB4ZW4g dG8gbWF0Y2ggb24gY29tcGF0aWJsZSBzdHJpbmcgaW5zdGVhZCBvZg0KdGhlIGRpcmVjdCBwYXRo DQotIHVwZGF0ZSBkb2N1bWVudGF0aW9uIGluIHNlY3Rpb24gb2YgdGhlIHhlbl9zY21pIGNvbmZp Z3VyYXRpb24gd2hpY2gNCmlzIG1hdGNoZWQgYnkgInhlbixzY2kiIGNvbXBhdGlibGUgaW5zdGVh ZCBvZiB0aGUgZGlyZWN0IHBhdGguDQoNCkNoYW5nZXMgaW4gdjY6DQotIGNoYW5nZSBpb21tdV9k b19kb21jdGwgYW5kIHNjaV9kb19kb21jdGwgY29tbWFuZCBvcmRlciBhbmQNCmNhbGwgc2NpX2Rv X2RvbWN0bCBmaXJzdCB3aGljaCB3aWxsIHByb2R1Y2UgY2xlYW5lciBjb2RlIHBhdGguDQpBbHNv IGRyb3BwZWQgY2hhbmdpbmcgcmV0dXJuIGNvZGUgd2hlbiBpb21tdSB3YXMgZGlzYWJsZWQgaW4N CmlvbW11X2RvX2RvbWN0bC4NCi0gc29ydGVkIG9ianMgaW4gTWFrZWZpbGUgYWxoYWJldGljYWxs eQ0KLSBhZGRlZCBuZXdsaW5lIGF0IHRoZSBlbmQgb2YgTWFrZWZpbGUNCi0gdXNlZCB1aW50e059 X3QgaW50ZWFkIG9mIHV7Tn0NCi0gYWRkIGNvbW1lbnQgYWJvdXQgd2h5IDMyIGJpdCBJTyBvcGVy YXRpb25zIHdlcmUgdXNlZA0KLSB1cGRhdGVkIGNhc3Qgb3BlcnRhaW9ucyB0byBhdm9pZCBkcm9w cGluZyBjb25zdG5lc3Mgd2hpY2ggaXMgd3JvbmcNCi0gbW92ZSBmdW5jdGlvbiBkZWZpbml0aW9u cyB0byBnZW5lcmljIHBsYWNlIHNvIHRoZSBjb3VsZCBiZSByZXVzZWQgYnkNCm90aGVyIGFyY2gN Ci0gYWRkIFNQRFggdGFnIHRvIGlvLmMNCi0gdXBkYXRlZCBzY21pLXNobWVtIHRvIHVzZSBpby5o IGZyb20gZ2VuZXJpYyBsb2NhdGlvbg0KLSB1cGRhdGUgc2NtaV9hZ2VudF9pZCBwYXJhbWV0ZXIg dG8gYmUgcHJvdmlkZWQgaW5zaWRlIGRvbTA9IHBhcmFtZXRlcg0KbGlzdCBhbmQgaGF2ZSB0aGUg Zm9sbG93aW5nIGZvcm1hdCAiZG9tMD1zY2ktYWdlbnQtaWQ9MCINClRoaXMgY2hhbmdlIHdhcyBk b25lIGFzIGEgcmVzcG9uc2UgZm9yIFN0ZWZhbm8gY29tbWVudCBhbmQNCnJlcXVpcmVzIGEgbG90 IG9mIGNvZGUgY2hhbmdlcywgYnV0IHByb2R1Y2VzIG11Y2ggY2xlYW5lciBzb2x1dGlvbg0KdGhh dCdzIHdoeSBJJ3ZlIGFkZGVkIGl0IHRvIHRoZSBjb2RlLg0KLSBmaXggZmlsZSBjb21tZW50cyBh bmQgcmV0dXJuIGNvZGVzDQotIGZpeCBsZW5naHQgY2hlY2tzIGluIHNobWVtX3tnZXQscHV0fV9t ZXNzYWdlIHRvIHVzZSBvZmZzZXRvZg0KLSByZW1vdmUgbGVuIG1lbWJlciBmcm9tIHNjbWlfY2hh bm5lbCBzdHJ1Y3R1cmUgYXMgaXQgaXMgbm90IHVzZWQNCi0gc2V0IHNjbWktc2Vjb25kYXJ5LWFn ZW50cyBwcm9wZXJ0eSB0byBiZSBtYW5kYXRvcnkgc2luY2UgaWYgbm8NCnNlY29uZGFyeSBhZ2Vu dHMgd2VyZSBwcm92aWRlZCB0aGVuIHRoZXJlIGlzIG5vIHNlbmNlIHRvIGVuYWJsZSBzY21pDQp3 aGVuIG5vIHNlY29uZGFyeSBhZ2VudHMgYXJlIHBvcHVsYXRlZCB0byB0aGUgRG9tYWlucw0KLSB1 cGRhdGUgZG9jdW1lbnRhdGlvbiBpbiBib290aW5nLnR4dCwgYWRkZWQgeGVuX3NjbWkgbm9kZSB0 byB0aGUNCmV4YW1wbGUNCi0gYWRqdXN0IGQtPmFyY2guc2NpX2VuYWJsZWQgdmFsdWUgaW4gc2Nt aV9kb21haW5fZGVzdHJveQ0KLSBmaXggbG9jayBtYW5hZ2VtZW50IGluIHNtY19jcmVhdGVfY2hh bm5lbCBjYWxsDQotIGF2b2lkIGV4dHJhIG1hcF9jaGFubmVsX21lbW9yeSBjb21tYW5kIGZvciBY ZW4gbWFuYWdlbWVudCBjaGFubmVsDQpiZWNhdXNlIGNvbGxlY3RfYWdlbnRfaWQgY2FsbCB1bm1h cHMgbWVtb3J5IGlmIERPTUlEX1hFTiBpcyBub3QNCnNldC4gU28gZm9yIFhlbiBtYW5hZ2VtZW50 IGNoYW5uZWwgd2UgY2FuIGluaXQgZG9tYWluX2lkIGFkIERPTUlEX1hFTg0KYmVmb3JlIGNhbGxp bmcgY29sbGVjdF9hZ2VudF9pZCBzbyBtZW1vcnkgc2hvdWxkbid0IGJlIHVubWFwcGVkLg0KLSBy ZW1vdmUgYWxsIEhWQyBtZW50aW9ucyBmcm9tIHRoZSBtdWx0aS1hZ2VudCBkb2MNCi0gdXBkYXRl IHNjaS1hZ2VudC1pZCBwYXJhbWV0ZXIgZGVzY3JpcHRpb24gaW4gdGhlIGRvY3VtZW50YXRpb24N Ci0gYWRkIG1pc3NpbmcgU2lnbi1vZg0KLSBtaW5vciBmaXhlcyBhY3Jvc3MgdGhlIGRvY3VtZW50 DQoNCkNoYW5nZXMgaW4gdjU6DQotIHJldHVybiAtRUlOVkFMIGlmIG1lZGlhdG9yIHdpdGhvdXQg YXNzaWduX2R0X2RldmljZSB3YXMgcHJvdmlkZWQNCi0gaW52ZXJ0IHJldHVybiBjb2RlIGNoZWNr IGZvciBpb21tdV9kb19kb21jdGwgaW4NClhFTl9ET01DVExfYXNzaWduX2RldmljZSBkb21jdGwg cHJvY2Vzc2luZyB0byBtYWtlIGNsZWFuZXIgY29kZQ0KLSBjaGFuZ2UgLUVOT1RTVVBQIGVycm9y IGNvZGUgdG8gLUVOWElPIGluIHNjaV9kb19kb21jdGwNCi0gaGFuZGxlIC1FTlhJTyByZXR1cm4g Y29tZGUgb2YgaW9tbXVfZG9fZG9tY3RsDQotIGxlYXZlICFkdF9kZXZpY2VfaXNfcHJvdGVjdGVk IGNoZWNrIGluIGlvbW11X2RvX2R0X2RvbWN0bCB0byBtYWtlDQpjb2RlIHdvcmsgdGhlIHNhbWUg d2F5IGl0J3MgZG9uZSBpbiAiaGFuZGxlX2RldmljZSIgY2FsbCB3aGlsZQ0KY3JlYXRpbmcgaHdk b20oZG9tMCkgYW5kICJoYW5kbGVfcGFzc3Rocm91Z2hfcHJvcCIgY2FsbCBmb3IgZG9tMGxlc3MN CmNyZWF0aW9uDQotIGRyb3AgcmV0dXJuIGNoZWNrIGZyb20gc2NpX2Fzc2lnbl9kdF9kZXZpY2Ug Y2FsbCBhcyBub3QgbmVlZGVkDQotIGRvIG5vdCByZXR1cm4gRUlOVkFMIHdoZW4gYWRkaWduX2R0 X2RldmljZSBpcyBub3Qgc2V0LiBUaGF0IGlzDQpiZWNhdXNlIHRoaXMgY2FsbGJhY2sgaXMgb3B0 aW9uYWwgYW5kIG5vdCBpbXBsZW1lbnRlZCBpbiBzaW5nbGUtYWdlbnQgZHJpdmVyDQotIG1vdmUg bWVtY3B5X3RvaW8vZnJvbWlvIHRvIHRoZSBnZW5lcmljIHBsYWNlDQotIGZpeCBkZXZpY2UtdHJl ZSBleGFtcGxlIGZvcm1hdCBpbiBib290aW5nLnR4dCwgYWRkZWQgIjsiIGFmdGVyICJ9Ii4NCi0g dXBkYXRlIGRlZmluZSBpbiBzY21pLXByb3RvLmgNCi0gdXBkYXRlIGRlZmluZSBpbiBzY21pLXNo bWVtLmggZmlsZQ0KLSBzY21pX2Fzc2lnbl9kZXZpY2UgLSBkbyBub3QgaWdub3JlIC1FT1BOT1RT VVBQIHJldHVybg0KY29kZSBvZiB0aGUgZG9fc21jX3hmZXINCi0gcmVtb3ZlIG92ZXJ3cml0aW5n IGFnZW50X2NoYW5uZWwtPmFnZW50X2lkIGFmdGVyDQpTQ01JX0JBU0VfRElTQ09WRVJfQUdFTlQg Y2FsbA0KLSBhZGQgbXVsdGktYWdlbnQgZmlsZXMgdG8gdGhlIE1BSU5UQUlORVJTDQotIGFkZCBT Q01JIG11bHRpLWFnZW50IGRlc2NyaXB0aW9uIHRvIHRoZSBTVVBQT1JULm1kDQotIGhhbmRsZSBB Uk1fU01DQ0NfSU5WQUxJRF9QQVJBTUVURVIgcmV0dXJuIGNvZGUgYW5kIHJldHVybiAtRUlOVkFM DQpmb3Igc21jIGNhbGwNCi0gdXBkYXRlZCBjb2xsZWN0X2FnZW50cyBmdW5jdGlvbi4gU2V0IGFn ZW50X2lkIHBhcmFtZXRlciBhcyBvcHRpb25hbA0KaW4gc2NtaS1zZWNvbmRhcnktYWdlbnRzIGRl dmljZS10cmVlIHByb3BlcnR5DQotIGludHJvZHVjZSAiI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1j ZWxscyIgcGFyYW1ldGVyIHRvIHNldCBpZg0KYWdlbnRfaWQgd2FzIHByb3ZpZGVkDQotIHJlYW5t ZSB4ZW4sc2NtaS1zZWNvbmRhcnktYWdlbnRzIHByb3BlcnR5IHRvIHNjbWktc2Vjb25kYXJ5LWFn ZW50cw0KLSBtb3ZlIG1lbWNwdV90b2lvL2Zyb21pbyBmb3IgdGhlIGdlbmVyaWMgcGxhY2UNCi0g dXBkYXRlIFhlbiB0byBnZXQgbWFuYWdlbWVudCBjaGFubmVsIGZyb20gL2Nob3Nlbi94ZW4sY29u ZmlnIG5vZGUNCi0gZ2V0IGh5cGVydmlzb3IgY2hhbm5uZWwgZnJvbSBub2RlIGluc3RlYWQgb2Yg dXNpbmcgaGFyZGNvZGVkDQotIHVwZGF0ZSBoYW5kbGluZyBzY21pIGFuZCBzaG1lbSBub2RlcyBm b3IgdGhlIGRvbWFpbg0KLSBTZXQgbXVsdGktYWdlbnQgZHJpdmVyIHRvIHN1cHBvcnQgb25seSBB cm02NA0KLSByZXdvcmsgbXVsdGktYWdlbnQgZHJpdmVyIHRvIGxlYXZlIEhvc3QgRGV2aWNlLXRy ZWUgdW5tb2RpZmllZA0KDQpDaGFuZ2VzIGluIHY0Og0KLSB0b29sc3RhY2sgY29tbWVudHMgZnJv bSBBbnRob255IFBFUkFSRA0KLSBhZGRlZCBkb20wbGVzcyBzdXBwb3J0DQotIGFkZGVkIGRvYyBm b3IgInhlbixzY21pLXNlY29uZGFyeS1hZ2VudHMiDQoNCkdyeWdvcmlpIFN0cmFzaGtvICgyKToN CiAgeGVuL2RvbWN0bDogZXh0ZW5kIFhFTl9ET01DVExfYXNzaWduX2RldmljZSB0byBoYW5kbGUg bm90IG9ubHkgaW9tbXUNCiAgZG9jczogYXJtOiBhZGQgU0NJIFNDTUkgU01DIG11bHRpLWFnZW50 IGRyaXZlciBkb2NzDQoNCk9sZWtzaWkgTW9pc2llaWV2ICgzKToNCiAgeGVuOiBhcm06IHNtY2Nj OiBhZGQgSU5WQUxJRF9QQVJBTUVURVIgZXJyb3IgY29kZQ0KICBsaWIvYXJtOiBBZGQgSS9PIG1l bW9yeSBjb3B5IGhlbHBlcnMNCiAgeGVuL2FybTogc2NtaTogaW50cm9kdWNlIFNDSSBTQ01JIFNN QyBtdWx0aS1hZ2VudCBkcml2ZXINCg0KIE1BSU5UQUlORVJTICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgNCArDQogU1VQUE9SVC5tZCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgIDExICsNCiAuLi4vYXJtL2Zpcm13YXJlL2FybS1zY21pLnJzdCAgICAg ICAgICAgICAgICAgfCAzNDEgKysrKysrKysNCiBkb2NzL21hbi94bC5jZmcuNS5wb2QuaW4gICAg ICAgICAgICAgICAgICAgICAgfCAgMTMgKw0KIGRvY3MvbWlzYy9hcm0vZGV2aWNlLXRyZWUvYm9v dGluZy50eHQgICAgICAgICB8IDEyMiArKysNCiBkb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5w YW5kb2MgICAgICAgICAgICAgfCAgMTkgKy0NCiB0b29scy9saWJzL2xpZ2h0L2xpYnhsX2FybS5j ICAgICAgICAgICAgICAgICAgfCAgIDQgKw0KIHRvb2xzL2xpYnMvbGlnaHQvbGlieGxfdHlwZXMu aWRsICAgICAgICAgICAgICB8ICAgNCArLQ0KIHRvb2xzL3hsL3hsX3BhcnNlLmMgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAxMiArDQogeGVuL2FyY2gvYXJtL2RvbTBsZXNzLWJ1aWxkLmMg ICAgICAgICAgICAgICAgIHwgIDExICsNCiB4ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMgICAg ICAgICAgICAgICAgICAgfCAgMjYgKy0NCiB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvS2NvbmZpZyAg ICAgICAgICAgICAgICAgfCAgMTIgKw0KIHhlbi9hcmNoL2FybS9maXJtd2FyZS9NYWtlZmlsZSAg ICAgICAgICAgICAgICB8ICAgMSArDQogeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjaS5jICAgICAg ICAgICAgICAgICAgIHwgIDM1ICsNCiB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1wcm90by5o ICAgICAgICAgICAgfCAxNjQgKysrKw0KIHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVt LmMgICAgICAgICAgICB8IDExNSArKysNCiB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zaG1l bS5oICAgICAgICAgICAgfCAgNDUgKw0KIHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNtYy1t dWx0aWFnZW50LmMgICB8IDgxNSArKysrKysrKysrKysrKysrKysNCiB4ZW4vYXJjaC9hcm0vaW5j bHVkZS9hc20vZmlybXdhcmUvc2NpLmggICAgICAgfCAgMTQgKw0KIHhlbi9hcmNoL2FybS9pbmNs dWRlL2FzbS9zbWNjYy5oICAgICAgICAgICAgICB8ICAgMSArDQogeGVuL2NvbW1vbi9kb21jdGwu YyAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDM1ICstDQogeGVuL2RyaXZlcnMvcGFzc3Ro cm91Z2gvZGV2aWNlX3RyZWUuYyAgICAgICAgIHwgICA2ICsNCiB4ZW4vaW5jbHVkZS9wdWJsaWMv YXJjaC1hcm0uaCAgICAgICAgICAgICAgICAgfCAgIDMgKw0KIHhlbi9pbmNsdWRlL3hlbi9saWIv aW8uaCAgICAgICAgICAgICAgICAgICAgICB8ICA2NSArKw0KIHhlbi9saWIvTWFrZWZpbGUgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgMSArDQogeGVuL2xpYi9hcm0vTWFrZWZpbGUg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAxICsNCiB4ZW4vbGliL2FybS9tZW1jcHlfZnJv bWlvLmMgICAgICAgICAgICAgICAgICAgfCAgNDggKysNCiB4ZW4vbGliL2FybS9tZW1jcHlfdG9p by5jICAgICAgICAgICAgICAgICAgICAgfCAgNDggKysNCiAyOCBmaWxlcyBjaGFuZ2VkLCAxOTcy IGluc2VydGlvbnMoKyksIDQgZGVsZXRpb25zKC0pDQogY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9h cmNoL2FybS9maXJtd2FyZS9zY21pLXByb3RvLmgNCiBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2Fy Y2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uYw0KIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vYXJj aC9hcm0vZmlybXdhcmUvc2NtaS1zaG1lbS5oDQogY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9hcmNo L2FybS9maXJtd2FyZS9zY21pLXNtYy1tdWx0aWFnZW50LmMNCiBjcmVhdGUgbW9kZSAxMDA2NDQg eGVuL2luY2x1ZGUveGVuL2xpYi9pby5oDQogY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9saWIvYXJt L01ha2VmaWxlDQogY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9saWIvYXJtL21lbWNweV9mcm9taW8u Yw0KIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vbGliL2FybS9tZW1jcHlfdG9pby5jDQoNCi0tIA0K Mi4zNC4xDQo= From xen-devel-bounces@lists.xenproject.org Wed Jan 14 18:29:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 18:29:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203675.1518751 (Exim 4.92) (envelope-from ) id 1vg5cx-0006As-Jh; Wed, 14 Jan 2026 18:29:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203675.1518751; Wed, 14 Jan 2026 18: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 1vg5cx-000681-DH; Wed, 14 Jan 2026 18:29:55 +0000 Received: by outflank-mailman (input) for mailman id 1203675; Wed, 14 Jan 2026 18:29:54 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg5cw-0005zq-Qr for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 18:29:54 +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 04ebd2ab-f177-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 19:29:53 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by AS2PR03MB9465.eurprd03.prod.outlook.com (2603:10a6:20b:59e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Wed, 14 Jan 2026 18:29: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%5]) with mapi id 15.20.9520.005; Wed, 14 Jan 2026 18:29: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: 04ebd2ab-f177-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Pa+7XcSUBIsYEt3gqbuG0PlTFH+fNYyH9TXCMphW3D2Xv+kaWQwms5UhT9lygqjoYeWyPwzBamGzhFbxb/O0U/bQUc7UDtY3xBWFvq3eGvBTQYPRKNxl6DxpmW/24N36wDOfPCM5RWZ7C+kNNTpCbzDsNntKdBaZmfb1JKd5aCEKfYHBM/8OrGDdEg/P4SgMB6NAJ+cP/nrl4sqmOi/e4fTcO9sV3dKEq7fAHjYr9kkBNNVw/VPKvmJ1FJGSH6tH2Hf5b+9KBIBcofez3bJYS92o+AjStxLEcO5AGO+6SGCvSYcGpfBE9JedvEzdw00QbXU88oQQOnWzaGDymaZ8Pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dUvvV+20T1UDiyfQPM2cyTTSiGchXAevlCVyA+kQh4I=; b=ikkSiEP4cdbIt+59H79vliqJD7BViH5Pd5FzGmRdqMdZiP7QXAUInte5guL+BAl+SbpZ51mWL62egjqCoGbx0tsg1wbrG11j8AwDV/zwQPbaueQgZ+/e7L12u57R2D3YcmlE/ngW7ffLhJzvGIOjP2w4lAFGsA+6yygeG0aqoYdnV/l17fWLeDlmvDJlfXVt7xaJlFay9Yga2PRTWEgryflfCfjegvtR4X80YJhurJWg23l82xlChy+m57djxHsgwLGXIghjn2gZN/SJRFZ9PEHYQCyP3MkpM5Jh6Vbj6r5UCV59sDqY3W9n8KTHhzJt0ceW6GFZhmy14lNxXtHO+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=dUvvV+20T1UDiyfQPM2cyTTSiGchXAevlCVyA+kQh4I=; b=GhPso1d5o7ttLzQDpZdvTYQo6QT/N1zfFoBLKyPeGEi279YG3dAoiN9Pk7q3OhO2EEAwlqDnoiwF65UdJXawOZMNigIHk0rey4gb2SBNxhzClZdm5YftasaPWYnNXqQDToI9+lVMHiGvGze7LsWXAgNmPTMsRY007G7WzMYcTgVVd5dQouAyEwYBpq4oodyQ/u2GSqnx0rPSNQ2csLrwwB79uMKdmZbAIT2Httwu6S69GdgLxL7Qs9zGOaitzHeRo6+qZNdx1b+BYcGm4+zWF7LAjCOcx8/bSn3mhHo5fp2jY0iinFc1gAnTde3awLOgCYJuYdP60gOSSiDnRAcZZw== 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/5] xen: arm: smccc: add INVALID_PARAMETER error code Thread-Topic: [PATCH v7 2/5] xen: arm: smccc: add INVALID_PARAMETER error code Thread-Index: AQHchYPDOaISZ8hXnEiYuxB1nnqaDQ== Date: Wed, 14 Jan 2026 18:29:48 +0000 Message-ID: <3ab46b8b5ceae264f26ad70ac2266a2ae56d02bc.1768415200.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_|AS2PR03MB9465:EE_ x-ms-office365-filtering-correlation-id: 834be4e1-2f7a-4407-ff45-08de539ae640 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|7416014|376014|38070700021; x-microsoft-antispam-message-info: =?iso-8859-1?Q?SLwU5IsgcrEywgCdlOthsp2pzzxCqXFBjltlHwrGXi4ORgsb+VRugh90MB?= =?iso-8859-1?Q?FAEDdOmB0FmSoAdYOV2ESk0hsFoUCa3vOauC3oEL3eE6bKlfCwMS6pS9Ol?= =?iso-8859-1?Q?b/Gr/Cpb537JbpRNndiYY/nHdM3Bb0uf1MMkE6hUdfYABRj1vih8nM//rt?= =?iso-8859-1?Q?VUdA0p38ToJgE3mUFXSq6+sharuN6COAs8+LdfQqRRXpSCqF9dQ+cF43Zo?= =?iso-8859-1?Q?FjlpcIkY+YjtcgZQ8vxLT/IwNjJCmbWnAlse3cz5WZAeBYlALdbs+OczoR?= =?iso-8859-1?Q?AGRb4jEWprqXiBERhYiK/bXKx9ZrNr0QJudf2MIJ1vLgNQ4SF1y9UjKQzv?= =?iso-8859-1?Q?KBWQnyE06G/TIynGK8/H8d5XtzH+s4NRSQjos+bUHTukdDW0UqXSneYpMB?= =?iso-8859-1?Q?5Rrg1LpADV/u5F33Uuaf16uE2kL1G0KXdWuFYMnl3E48vTixPGYJ4G3mAG?= =?iso-8859-1?Q?bb/GXqL6w2cb15gaRxM8+KUWnxFniSkDqwCKSQr/SLsntYpSHeUyF5PFhb?= =?iso-8859-1?Q?in92hJH1SWoHWrFeC6SpbhVU1LJthJzA8E1I1FkdBJ1+miW0+MFe0VPdQs?= =?iso-8859-1?Q?bNtQXl1R8kyQ5BfJ59mVxwf0e7SZgJLeEJzeDU4xUJzY1r3cLgCixcwLii?= =?iso-8859-1?Q?q3dgnpfSENsvriPQWxdpKU0hgRcnhIKn2fhehX54V6CwvUqqkPMsAN4ldo?= =?iso-8859-1?Q?Js1760+ZyPNJgnnLbCASp6fOql1opzd/kpZajE4EIAXnrc7t6187o0DaZD?= =?iso-8859-1?Q?Hk/QNR04YXkyAT11q6FOSrttOuVMeCt48VO5AZXMK2tVgsIehbTNqsKDif?= =?iso-8859-1?Q?4wwG/bFRTM+2DcIJOrrEQDu2c8tfXb7jO68K+/pU2MNhTLiD5712fjINLq?= =?iso-8859-1?Q?/Nmrm2MEVe+J5k/lefzNAgFNBviMEhRol6qWC2QM2q7N1CeRxq0In3zEYl?= =?iso-8859-1?Q?Ehtkyhd+X9pmDSrj6egMoOX+uOIY1yr+Q+7nbgSc6Gw03Wf61Hv3GjzWEu?= =?iso-8859-1?Q?2qpJZUUstNSXToda6LiFnq+t5Dl55xuMWwbxe+tpqS5JWVuyFffYdYC37m?= =?iso-8859-1?Q?Cu7tcV81inc9Ws53c9XD+/2MkT25ChGpGO0qB9laPszQQbtP4iKS6Pz/uh?= =?iso-8859-1?Q?m30rpAcgacBXKmaGBiOvzfvLIpgqSj8lg/TRVOyXq/jkbR6+zlyK+Dv1S9?= =?iso-8859-1?Q?2O6P+balmbkydQ3no5Ry29mU8BHmUG8YEZL3heO9Kib1i/RlLeoH4xVahu?= =?iso-8859-1?Q?p+GTeBXoIcgK7RzTIAKZJ4paxfZ8YXKQAfxTxnhEk/JXukgHGQnmxXe51g?= =?iso-8859-1?Q?++nvVurEP2xbkUwylzd+v9Fsu8wAAK9XOyxtbfOFlqavFcJD55qKf6jATB?= =?iso-8859-1?Q?iIqjadDh74ZLFaMPvOSuENrhZD7ZOl9JxOcX+hwyoNWiVt5THTeXZQuZ0T?= =?iso-8859-1?Q?74+tboPho92+IOsbRxSA4Zi3LYW0baylW+mzmCI8xPWhZTpy9tRVHh9yHC?= =?iso-8859-1?Q?OmK/L363ALyjQK/DwYy9IaV/Qp12l4lrwl8VTd3fjJEBxdXE4bKNqZ5A/Y?= =?iso-8859-1?Q?Tgfe2Gg04Q7z01eXyQZ6AHl1dWxiHYxSUUnLl8AJHEz4MOJYnl900RvzQn?= =?iso-8859-1?Q?utdX/EzCkbHISJbRQXZJLfKLXguOKSrBnaQU1x9DRIK23/tNcV3Rd5Nk5u?= =?iso-8859-1?Q?Izin3WMwBmoCMDamxlA=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)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?kR4a49bGbu4koxZPKhrBccGogo+H3b88dZLB096EhXv91SuiIrrA/kwpug?= =?iso-8859-1?Q?0QGto0JFP9eyrLakM6s0J8o+yB3l+JORtR52yP94KDeb46G4rEpjMPgHpY?= =?iso-8859-1?Q?TeziX3ieFWbu/5sVj29qqwUAAjOMl6SE2pMoj2pykuqhTwmjHf3r5Mo+wy?= =?iso-8859-1?Q?UIApk6E0LarZzOfUEpAVndC6EmwqaxV+s7nCntB04/HrcBH+EO98LGtpSk?= =?iso-8859-1?Q?ClGmPgG84oufnohTwllQL3B1XD3To3hP4CizGd9Qy9CBLsmdWzuHyJ0kKA?= =?iso-8859-1?Q?+VDiZkKgeRUbSbayYr0fH+dwqOyZmdEHDxCgztOszG6dorAflulGtgSfrj?= =?iso-8859-1?Q?P14OpF69edNiVLVxoxPKdI7C3jrIbQDep7Q+K4KxF5bzM17UrGSabMPJ3Z?= =?iso-8859-1?Q?TzVv1YAff93cIK5c0rkaHMWqSB8a9e5+X1ejgT0ljHVjbVW2hBkpluZXGb?= =?iso-8859-1?Q?7ivAi8sOPYpKm95iEl6R6R/QlTU5HPFb4Y6/4BNPHYP6WjHr6LlCG0AQh4?= =?iso-8859-1?Q?JEXphLrsIZ4E0555yHZnZgmxFAi9dtXNRXCAiehZhSrqnGK3ugvNrG9KZI?= =?iso-8859-1?Q?YagfWIq6z3t9PCoM5sbLc914TC/2eY/+b5oVs7laXbKvlgJQMzg8wth2aG?= =?iso-8859-1?Q?VrXN5X2YvxigePdaMY2AF4skpN/EWybf9vU/omZHhXgirdVeupGPNYLw+7?= =?iso-8859-1?Q?tOw5Wad1UDRoSJt8TKjpVf8RhHYSnvuwOghqiyL0y7WNqaXXg0VI1pyQS+?= =?iso-8859-1?Q?utYgtlBgFkl9axgnD/pb8CTA+XxrvdD5fe0pRDGkHRUjqjKcnzVFKqGHyx?= =?iso-8859-1?Q?S7BBzmtbf8a7ikDzIHpaIZmlpmQZ5REAiWR2jHrIdD8EfVb4HosAc08C0G?= =?iso-8859-1?Q?ZetO0OyFmiWxxIG6Mr0NA3yNNP8L6kmnDgdVbDaIhtwtH5y3JkhZ+Am/yx?= =?iso-8859-1?Q?iKyGsyYdBiMpl8pcm/GCxWvDBIHDNhwIEwhXU6KvR0go+bqRF/Vw2PtpGy?= =?iso-8859-1?Q?3X/IyjXqeRb93XG5qTn3chDwj+6fQF+iGGHMaRix0gplSu+bsbCV5LrY+A?= =?iso-8859-1?Q?Pn5Aicq/h+dXxY1ZKJL22dy0gbLvW3UsT5Fzbv5u6W7cBWwmPDQqj6CxG+?= =?iso-8859-1?Q?PYq4+PN/Dr6PpfqRdNNJRm4dprZnQEh/Lone1mkBOkwntEecbxi0mu38ma?= =?iso-8859-1?Q?p2trjtdogGlr/IO6vNp33LeZ55XkOHAjKpWQWjevMQL+aqq32QMQbVBQlt?= =?iso-8859-1?Q?xlBb3lwlRe8adAAr9eKfmOnCkTq0pn6b8wi1JSSm9XbmKTZvoZQRhe/idq?= =?iso-8859-1?Q?ATLOilWLAklFsxX7/mbOG7CEvewgJFTbdBIMrvlp3qoIg985pwkmHUCAo+?= =?iso-8859-1?Q?kV0m+x53+3iaFzV00K08ULkMW46TU5SJAPOT6WnxMi5bPWmxwtUFOwkgqL?= =?iso-8859-1?Q?Quh+tr5o9e/gvIYU9vpYP2XDIFvObeO7ePxGRNGEXs+nMfFEB4BSxgzwFs?= =?iso-8859-1?Q?G+Jsp6ouE3ahuiVUVt1syclxcuXWi/k00AsgnNcQnDGwPpZWhVYVpq5v9s?= =?iso-8859-1?Q?vQWHKpxdLEsXPEGaYx5I9un6AOE9cMuEvrr7jxcLQLflSnFCIAFdmeG0hD?= =?iso-8859-1?Q?oY7rfraIv5JV/P8kpf9AVzMRuc3rwLZzH/Tmm16eg/vOi17kF0ina31ih6?= =?iso-8859-1?Q?HbVCrdlz/3BB6a13BZJj81I7DnzR7e4mQA5HzCJsU5cF3zH1uYy3TynCQ6?= =?iso-8859-1?Q?fsQ3H40Iw5DW5eX2jRmoHE6/Xb50xt1daP6qFBmcA5g05HpxpsK9TxBaq1?= =?iso-8859-1?Q?4LF7EXuipHkhE3Taf7mfBgHCy130kM0=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: 834be4e1-2f7a-4407-ff45-08de539ae640 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2026 18:29:48.4518 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2k8d3grFZ4n8FRASEN+OaLh7DrhGRpbXGcInfs+/tz3PZgLckG0xFUg2qLP0aHzIs2duHkzvX/bPbLP4ugw99IqmCI31rXOZqBEPACiEp7o= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9465 According to the "7.1 Return Codes" section of DEN0028 [1] INVALID_PARAMETER code (-3) is returned when one of the call parameters has a non-supported value. Adding this error code to the common smccc header file. [1]: https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6 Signed-off-by: Oleksii Moisieiev --- xen/arch/arm/include/asm/smccc.h | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/sm= ccc.h index a289c48b7f..dc6af94db1 100644 --- a/xen/arch/arm/include/asm/smccc.h +++ b/xen/arch/arm/include/asm/smccc.h @@ -381,6 +381,7 @@ void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs = *args, 0x3FFF) =20 /* SMCCC error codes */ +#define ARM_SMCCC_INVALID_PARAMETER (-3) #define ARM_SMCCC_NOT_REQUIRED (-2) #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION (-1) #define ARM_SMCCC_NOT_SUPPORTED (-1) --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Jan 14 18:29:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 18:29:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203673.1518739 (Exim 4.92) (envelope-from ) id 1vg5cw-00060H-Un; Wed, 14 Jan 2026 18:29:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203673.1518739; Wed, 14 Jan 2026 18: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 1vg5cw-000606-RV; Wed, 14 Jan 2026 18:29:54 +0000 Received: by outflank-mailman (input) for mailman id 1203673; Wed, 14 Jan 2026 18:29:53 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg5cv-0005zq-5o for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 18:29: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 039bf376-f177-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 19:29:51 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by AS2PR03MB9465.eurprd03.prod.outlook.com (2603:10a6:20b:59e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Wed, 14 Jan 2026 18:29: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%5]) with mapi id 15.20.9520.005; Wed, 14 Jan 2026 18:29: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: 039bf376-f177-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=L8fXhzxNP0d2MzduSM+KJPPnnJo6PyWv0onJd8yvQpRog2WJe76T9qKVmoCiKc95tsLzYwARUn7E+O5WOQn2l/6tZ8ffi8zUSgn7bhctMs8Nec6svTEJcg3bqrpaMMH99QEaw4aR0H0joTue+p2sJEot7+Io3GivAdTmnKcP0GOhGoeFLbWpOkPVELA1WmAI1dNiJD9xnop29rlkGlHvspkZP7e5wucxuRt9yCuXkqCIhr9cKeVAwNNuWBBMV7NklvhY0+zPmeK35J9zX4l0SaOM2Eb5CuPCVarUn7q2jVqLp7nGZ8CPMHpBNtbQXyPft1kTracL3Kew1ibhVs27dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0ZOur9hcnIrC49t2nKFG1sBkxLPTcU8vBfzNYSma4Nw=; b=v5hXRKmJTu7ls9U7cuVc8rp1UjonOz4dIc3fBpbGn4gPUh/ooBabSgQztW+NWWGCIsX+DgdgcNojRz0jmnJqCzeC+Y+gdZeojvpU0HHSNULRkNqeS76BGxOrzmTndtci1O6LpF28Yd0QCuLLpsh3V8fBpDlx/hOVQpicttoscaiv2g5X8eaiXA8B08N+goJlM7pB4IKdASK1oalbKjQXC7jcbAyK3orcSuESu82wYawy1A6MsGQQBLfxSVEfhZm76UhkBtd7OZ+hup7pd0liVQT2Pn7N2qKrLqEud8+m8eP+gTvmNY2Hg+IuXX/BL47xpooteB74m0Jxj4Irt3dO9w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0ZOur9hcnIrC49t2nKFG1sBkxLPTcU8vBfzNYSma4Nw=; b=lD566+Y7msbsvWYlUL5iVU81NWKn29EBC7BoJkeo+OoR84MFtmIrTJxTJ4bRqHpkih2m1Cg2r+Zi9UO1CCiqDgGI87+vIb7oD4EprOj0HIoRApuLynkH9OjnCzRTNDb2X8LNKa+j+FLj5afTZmB4VoueuPLYfYvjG3m9yt8vNeMPZIV6Q1FQysJhkzTGM4/3XTb5DbJJNw0fAvi21EzhE3Y1WzUHkfW8gMqTDMueAE1oddtRG/HsNcSAOq8LW6tjn5vmGr5lfrG0pugNYR6pqQ6058u9yNtlzVnfa6mQwqtkOdIrtNaGIglgpG9lrv9R9/tVj63lrREceV+E22721g== 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 , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v7 1/5] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu Thread-Topic: [PATCH v7 1/5] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu Thread-Index: AQHchYPDuN/1Zdz2qUyC6pz/50rn/A== Date: Wed, 14 Jan 2026 18:29:48 +0000 Message-ID: <837eab835a75e7f668c5a49074991b2fcba56156.1768415200.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_|AS2PR03MB9465:EE_ x-ms-office365-filtering-correlation-id: 39588112-3f45-42f5-203b-08de539ae615 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|7416014|376014|38070700021; x-microsoft-antispam-message-info: =?utf-8?B?RHdnNm93OXIzNlF4eFZBWVRwQnFtMGRFUEcxTDV4MUVkVXVEOVJFbWZBYWE2?= =?utf-8?B?Qkt4N2JlSkZNc0JPRkEwalMrZlEzcDV1OWx1OGVzbU9TWllyR1d1RGwwb1Q0?= =?utf-8?B?OVd2bjIrcEFRZnZ5SW9vV0RMREMxamhETTh5V3dXVnowbGNoSVBDT00wVkQz?= =?utf-8?B?cXM3SEtuNTNISnhrZUhYbENkUUVTMFc4T2dQVnc5MzBzMk96eFp0VTJnK2ZF?= =?utf-8?B?d1YzQ1lNZHlTQ1pUSVNlU1dqSEtmTkQvaVRpUGdNWUtKVjVPS3BaR2Q1Z082?= =?utf-8?B?cXNhSXM0M2JGU1N0M3NpRHJtM2swa3ZYY1MxSy9abm1LN2pOMThXUWU0NjNi?= =?utf-8?B?U2d5ck94QXkxcjRxM05COUpMN3AyeWIrcDBsYXNjTGJZQkdsV0wvaktFTVhX?= =?utf-8?B?YnN0c2dsS2M2QmxJL0JHYnlaK1kraU1rOG1ucHVvSXZXcldOalFGLzBMOEFG?= =?utf-8?B?VzErTDZQbnFtRHR2d3dLU0xiTWFnckZXdG93OGpVSkJXa2dWMGpUeDhCUFU4?= =?utf-8?B?UE9Ua2pMTUlQOXhSbTdrUGtXdE1vNkJYWCsxUXBTNDZmYW1GREdRSXkzR0xa?= =?utf-8?B?dzRITU5PaFIrM05hZ0I3RFVUdkNCYjUrRVJ0d3VtOUNpQWg4b056QTI0cXl1?= =?utf-8?B?MjI5MlBqQkdhTFJFUGlPdGVzWEpNRmhjWEVmTkYvaDJlRVdPZ2FYcUkwWXZ1?= =?utf-8?B?Q1JzUWlKTldBdkEyYWg0UFFMRWYzTENneC9QQysvRjZyRnJudXFOYjJUNXVF?= =?utf-8?B?L1lMRjNMK1UwVVplUm4rcFEyRnN4alRlVlA1N1RZUjQrK2RsZEc1eUFHeEQ4?= =?utf-8?B?bXd2OCtla3VvVEJNN0pibnlubHBjcndJeGRvdHRsNXFmOHJ5bzRUTjNIaGQ5?= =?utf-8?B?MmQzS1JndytVREJmckVCVHh4Qi95TFI1L3hDZ09TYmZlWXBxVEh2dnVNQ2ZL?= =?utf-8?B?K25sUnp0OFJTOFBVSzVGYnQxdUhuQXU2eWFjeXhyaVh2WUFDRFJtcUp2Snhm?= =?utf-8?B?elVCbktTcCtObVRqb0JuNTl3UXJLM0NQUmJ5bEZKcEREQkxYd3hCb0RySjVU?= =?utf-8?B?bGFGS3l4aXpKd0l1YUZ3Z05uRXhVWVBWdlZLVDM3QVQ0L2hEMkVSclFBeUZp?= =?utf-8?B?TDN0S2k0Q3RUVytTTld0NGY2a0JpNFhjZS91YzJ1YXNVNmdaMWFlM0dOakRa?= =?utf-8?B?dE9zak9jY3NtMEJYRGVscktTUWNtWVk5MVg2U2pZZGFxaTNOTkRSL0E3cE52?= =?utf-8?B?N1E2dUhkdzlFMW80RHZDbWNNcm9XSG5yNDJWWVNSMFd4VkZGci9XUERTVVBv?= =?utf-8?B?clNDNm5YV3lGdnRZbFI2NUN0bGliNi9HZG1VNzIrbkRmQkVYWUV3NjFpVWU1?= =?utf-8?B?NWcyb0RzaFB1M0xoNWp3NmsyakVPeE1qUWk4czdvVmxHZmJYQTgyL2FwcmRm?= =?utf-8?B?dUJhZ00yd2I4MjVjYTZTQVNVMG5OYWpsMUtuTjlaTVNhVGtaL240T3cxY2hr?= =?utf-8?B?ZjF3TVZscFZhaUIyUHZRc1UxNno3dVpobnRqdE41bmYzT00yUlZ2TUNVcEpJ?= =?utf-8?B?Y1JHMlZhS2NkcXV3Wk11dHlFeXY3SU5QaXVGY1Jhay9sdWdrTERuZStQOW8v?= =?utf-8?B?QjE1ejlRbVM2TGhJMytlUi9uT2NSWEdlVmtRanlMMmRCbm11V0ZMZklTNXY5?= =?utf-8?B?S1RmZjVQYUxjRHhwZXZkS3Y5U2RXVE5SNkxCc2ZON2lEcjZyTDZ0OCtwUnJ5?= =?utf-8?B?S1ZXaitOay9tYS9lak9vckx4NExHNHc2VFFxM1owR3lmak9VSENWSGI3a1FE?= =?utf-8?B?S01mZW5KQktvVHgxVnhpMmhyTVRJNEF6YStEaFpuWTNjdmYvZVdHMHFBTnI4?= =?utf-8?B?WEIwZnVSNVRjSWlzS0RIUGNKZDBoaEh2LzROdTUyTFRZNVFnREltdklpUjBP?= =?utf-8?B?NHRXK09zL2kyN2hVd1hCMkxjWUh1OWNBSC9RSG94VEFsUU1QZXFOc0JTSnhY?= =?utf-8?B?VjE0cENBY3dWSUYxQ1hrOWVMbjdyODEzelBzL2NCcEUrUjFCWnBVTWIvRUtW?= =?utf-8?B?Z0lhd0JsM2g3YlRiOHF1SlBOYmk0MUdFRnpSbktkdDZnbk5hQmdqYk5lYmlY?= =?utf-8?B?eUY3cUVvS3pqNHl3allmekRFa2xHcndMdVNGMzdEdytuUkFhZVcrUjdtazRu?= =?utf-8?Q?FJDx7d5Y5jBwzkYUJfYohF8=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)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NStRQ3FYSUJvVUpHQWtudWpLQjZJcXowRmRJVDkxT1NnNG1kMkRQMW9BekZa?= =?utf-8?B?d0pYS3BWdERRVUZuWHNPYTFXUnV6Tm5SMHdBbGZHbWdYYmdUQjhGM3hBV29v?= =?utf-8?B?NDl5bkRXY1I0U3dKQnFPalllaEI5VnIxSHlQMnp5WXJJOU5vbnA3eFlBbEE4?= =?utf-8?B?M0ZtL2RsT1RrMzZvZ29SRXBocjZVNnlEWXZHV0NRdjdMaU5KMEhXZVYwdlUr?= =?utf-8?B?MTdXeWk0K1BScitTRzhmelVUQ0VFMVNIeXJjaXhPYTRaTHIzem1sVjJzSjY1?= =?utf-8?B?Sm04UlE1anJaTTN0UU5VcXIvejhCK3NzUk9uOHlKVlYrZ2dDL0g4SXBQeW5w?= =?utf-8?B?VjVjNjBLbklvcW0wb3lRTzg4dk84aHAyQUV1WnVvMDY1Z1ExU2xkVU4xMzUy?= =?utf-8?B?Um9jNE9IQjVMZ0Z4cDN6TEtYbGwzVWhhUU0rZHZJOG92UDV3Q1o2ZWJXY2No?= =?utf-8?B?N2pSZ2xtT0JVYytIaEw4Vk5SUnRnUlNRVTJKVTVkdUlpaFhTYUxuQTZZakZk?= =?utf-8?B?U1lTR0g2YUJxaGFES2xjMUhLVlY0Zk45K041YTNlSzdoY3ZJM0FpdVA4NjRM?= =?utf-8?B?c1drVXlmWFN0eHB2czlWVExadG5hV1ZDUkdHcVBKRUFMdVU2MnlJWXBGc05C?= =?utf-8?B?WENLK0RYL0xzdXVjZU1nNVFrcVJJdzZXSnUyQ3pnbDFDbFZMZmVzQlNHYkIx?= =?utf-8?B?UEpoaTFEMDVGQXdpU3JRUzZkcGhWR2FvOHpJNi94WDZ0a09BME92YUZ5ZDRE?= =?utf-8?B?dkhDQjVDRkNzR3lXMXNCZ0w4cUVJNDBqcStreHZVdzZTQU8xaVRtOVU1bXRG?= =?utf-8?B?MGVHNzQ4eG40UTc5OTUzUjR1anBHdk9RSnNBOThlOUpTOVZGcndMTkQwUjdu?= =?utf-8?B?L2w3MnpHbzkxbDRER3c2eDBpVmUzNmhTNEY3andCcmFUQk8wRDBtQ0RLdDJv?= =?utf-8?B?TlE4TS9kd3JRMXBJUjBMSzhMV3JuL0x3SVROWHZ0UWROdW1RcVoxS1ZoZnY4?= =?utf-8?B?YzF4MTZhMDZpSTZWNFZGR1RUZTBlYkk4KzB6bXVEUm92QUoxa2FKaE53aSta?= =?utf-8?B?OVZ3QklESFcyS1ZUVlBqVS91ckpqS3lwME43eDZ4QnpaWFFLZEp2a2ljOWw5?= =?utf-8?B?a3pWbVRONS9ZTlFkcUlsc3RyUkhDYlNtWGJsYjQ1Yk1JUkU1NTNzcXl0VTdT?= =?utf-8?B?K3B6dEs3ZVRhKzk5YW1UTldEM294dm02U1ZTOUdtaHRON2R6dUxxS0dpZkF0?= =?utf-8?B?Yk55V2FYNG9wTS9VeU5laHNPMktrQ2tsNU05bW4xOFhpSmpLajNnUFlrQmhu?= =?utf-8?B?alpHNC9TUHFkVlB1SHN2WmRtS2hvVTdoWlNlQ28xaVpkS0JsTEIvMEN3cEpI?= =?utf-8?B?ek5kVlFCR2J0ZVBlN2t3RFpzaG95RzZIOTJQWHE5d1lCODFYTlkzVnQwU21l?= =?utf-8?B?UmdweGtSWHg3TlpmTGJJS3pDK2dIS3Q4N21xMnFtaWNmT1BXOFlyZHkwSW5V?= =?utf-8?B?UWdPZ2xZZnNXVERRbW9VQit0VVRDZ2l2Z044elJnVk5IeEhPdmkvMEIyOGpY?= =?utf-8?B?YjNNcC9DMkRtVUxzN3JwNEg5NHgzQlkvZWdZQTcxdW1mTERKdXdpV1k0NmhK?= =?utf-8?B?c1ZRc1pvbDhKRlR4cGE3RlFtV1ora2QzUHR1c3gxbVBXbUZJYXJCRmdYS2hM?= =?utf-8?B?UGtCWUQxa25SN0l6YmxPOHFRRGE1U3ZMclZNVDFNZ04rQzFCTXBLWmFHbHdz?= =?utf-8?B?MjMvcElyV2lCby9uZml3NDJoWE4weHBWdWxZbHVlb21TejZIQUVXUHZydU0x?= =?utf-8?B?M0oyOTRQc0tPcUE1QVdXUEQ3c3BxR0NyRFBKZjJ3TCtGbGJwV00zUjZZdzhP?= =?utf-8?B?MXBvVlhTTzVkTDJSeUJzYVkwdHJ1WmlvdWNxOURaWUJ0VUFKWEtYZ005TEo1?= =?utf-8?B?Y0RhUXZSdjRBMWhpOHlqV003ajFUVnp3Rmlma2VVM2VHMDVWTkhkSEdUVHpK?= =?utf-8?B?aWVWTS9yYUdnTDE4YjdJUTlTRi9jeTd1clQ2RG5Cb2FVdFFMaXJBTUtMQTZq?= =?utf-8?B?a3BEbllCVWozZTIrYndUdnkwMFVhUWhJZmYxNHZ2bDZYY29TV3hIcm9PeGhU?= =?utf-8?B?eFRNM1RHbnNTYXdZT3NlYVdUNWNVN3J4VXNqMFZ0S1c2ZHY4bUh5N2MrZU92?= =?utf-8?B?aHNTMitNc0tOSGVoOStNVDM3R0VvTFhYZ1ArMENUN1NPRWtVcDRKU2M4UFBX?= =?utf-8?B?dzdpYU1vQ2JsOElPdFQyRGhvdUxyMGtEQzJ2dUhMRExtTnBzQkpMZFJjaVpV?= =?utf-8?B?MzdaQ1piTkhYdXpzVHJtaWtTRGVqSnU3N29BL3RFOHl4cVZZZExsOGNXRnFS?= =?utf-8?Q?sS0lz7Rtidal8Oa8=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: PAVPR03MB8946.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 39588112-3f45-42f5-203b-08de539ae615 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2026 18:29:48.1610 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZxGB9NnfNXFmWw665V2+3GCQxdgHmrPaok1/Iuqy/rNIFJvCSmEP5AKEsSEF1PyPZPy2Aix5Yb3+fyrw/wnvuy311dC7SfF+BDt7sGQ1jVw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9465 RnJvbTogR3J5Z29yaWkgU3RyYXNoa28gPGdyeWdvcmlpX3N0cmFzaGtvQGVwYW0uY29tPg0KDQpB ZGQgY2hhaW5lZCBoYW5kbGluZyBvZiBhc3NpZ25lZCBEVCBkZXZpY2VzIHRvIHN1cHBvcnQgYWNj ZXNzLWNvbnRyb2xsZXINCmZ1bmN0aW9uYWxpdHkgdGhyb3VnaCBTQ0kgZnJhbWV3b3JrLCBzbyBh IERUIGRldmljZSBhc3NpZ24gcmVxdWVzdCBjYW4gYmUNCnBhc3NlZCB0byBmaXJtd2FyZSBmb3Ig cHJvY2Vzc2luZyBhbmQgZW5hYmxpbmcgVk0gYWNjZXNzIHRvIHRoZSByZXF1ZXN0ZWQNCmRldmlj ZSAoZm9yIGV4YW1wbGUsIGRldmljZSBwb3dlciBtYW5hZ2VtZW50IHRocm91Z2ggU0NNSSkuDQoN ClRoZSBTQ0kgYWNjZXNzLWNvbnRyb2xsZXIgRFQgZGV2aWNlIHByb2Nlc3NpbmcgaXMgY2FsbGVk IGJlZm9yZSB0aGUgSU9NTVUNCnBhdGguIEl0IHJ1bnMgZm9yIGFueSBEVC1kZXNjcmliZWQgZGV2 aWNlIChwcm90ZWN0ZWQgb3Igbm90LCBhbmQgZXZlbiB3aGVuDQp0aGUgSU9NTVUgaXMgZGlzYWJs ZWQpLiBUaGUgSU9NTVUgcGF0aCByZW1haW5zIHVuY2hhbmdlZCBmb3IgUENJIGRldmljZXM7DQpv bmx5IHRoZSBEVCBwYXRoIGlzIHJlbGF4ZWQgdG8gcGVybWl0IG5vbi1JT01NVSBkZXZpY2VzLg0K DQpUaGlzIGxldHMgeGwuY2ZnOiJkdGRldiIgbGlzdCBib3RoIElPTU1VLXByb3RlY3RlZCBhbmQg bm9uLXByb3RlY3RlZCBEVA0KZGV2aWNlczoNCg0KZHRkZXYgPSBbDQogICAgIi9zb2MvdmlkZW9A ZTZlZjAwMDAiLCA8LSBJT01NVSBwcm90ZWN0ZWQgZGV2aWNlDQogICAgIi9zb2MvaTJjQGU2NTA4 MDAwIiwgPC0gbm90IElPTU1VIHByb3RlY3RlZCBkZXZpY2UNCl0NCg0KVGhlIGNoYW5nZSBpcyBk b25lIGluIHR3byBwYXJ0czoNCjEpIGNhbGwgc2NpX2RvX2RvbWN0bCgpIGluIGRvX2RvbWN0bCgp IGJlZm9yZSBJT01NVSBwcm9jZXNzaW5nIGFuZCBwcm9wYWdhdGUNCml0cyBlcnJvciBpZiBpdCBm YWlscyB3aGlsZSB0aGUgSU9NTVUgcGF0aCBzdWNjZWVkcyAodW5oYW5kbGVkIGNhc2VzIHJldHVy bg0KLUVOWElPIGFuZCBhcmUgaWdub3JlZCk7DQoyKSB1cGRhdGUgaW9tbXVfZG9fZHRfZG9tY3Rs KCkgdG8gY2hlY2sgZm9yIGR0X2RldmljZV9pc19wcm90ZWN0ZWQoKSBhbmQNCm5vdCBmYWlsIGlm IERUIGRldmljZSBpcyBub3QgcHJvdGVjdGVkIGJ5IElPTU1VLiBpb21tdV9kb19wY2lfZG9tY3Rs DQpkb2Vzbid0IG5lZWQgdG8gYmUgdXBkYXRlZCBiZWNhdXNlIGlvbW11X2RvX2RvbWN0bCBmaXJz dCB0cmllcw0KaW9tbXVfZG9fcGNpX2RvbWN0bCAod2hlbiBDT05GSUdfSEFTX1BDSSkgYW5kIGZh bGxzIGJhY2sgdG8NCmlvbW11X2RvX2R0X2RvbWN0bCBvbmx5IGlmIFBDSSByZXR1cm5zIC1FTk9E RVYuDQpUaGUgbmV3IGR0X2RldmljZV9pc19wcm90ZWN0ZWQoKSBieXBhc3MgaW4gaW9tbXVfZG9f ZHRfZG9tY3RsIG9ubHkNCmFwcGxpZXMgdG8gRFQtZGVzY3JpYmVkIGRldmljZXM7IFNDSSBwYXJh bWV0ZXJzIGFyZSBjYXJyaWVkIHZpYSBEVCBub2Rlcy4NClBDSSBkZXZpY2VzIGhhbmRsZWQgYnkg aW9tbXVfZG9fcGNpX2RvbWN0bCBkbyBub3QgY2FycnkgRFQvU0NJDQptZXRhZGF0YSBpbiB0aGlz IHBhdGgsIHNvIHRoZXJlIGlzIG5vIG5vdGlvbiBvZiDigJxTQ0kgcGFyYW1ldGVycyBvbiBhDQpu b24tSU9NTVUtcHJvdGVjdGVkIFBDSSBkZXZpY2XigJ0gZm9yIGl0IHRvIGludGVycHJldCBvciB0 byBza2lwLiBUaGUNClBDSSBwYXRoIHNob3VsZCBjb250aW51ZSB0byByZXBvcnQgZXJyb3JzIGlm IGFzc2lnbm1lbnQgY2Fubm90IGJlDQpwZXJmb3JtZWQgYnkgdGhlIElPTU1VIGxheWVyLg0KU28g d2Ugc2hvdWxkIGxlYXZlIGlvbW11X2RvX3BjaV9kb21jdGwgdW5jaGFuZ2VkOyB0aGUgU0NJL0RU LXNwZWNpZmljDQpyZWxheGF0aW9ucyBiZWxvbmcgb25seSBpbiB0aGUgRFQgcGF0aC4NCkFsc28g U0NJIGhhbmRsaW5nIG9ubHkgZXhpc3RzIHdoZW4gRFQgaXMgcHJlc2VudC4NCg0KU2lnbmVkLW9m Zi1ieTogR3J5Z29yaWkgU3RyYXNoa28gPGdyeWdvcmlpX3N0cmFzaGtvQGVwYW0uY29tPg0KU2ln bmVkLW9mZi1ieTogT2xla3NpaSBNb2lzaWVpZXYgPG9sZWtzaWlfbW9pc2llaWV2QGVwYW0uY29t Pg0KLS0tDQoNCkNoYW5nZXMgaW4gdjc6DQotIHVwZGF0ZSBkb21jdGwgdG8gYnVpbGQgb24gYm90 aCBBcm0gYW5kIHg4NiBwbGF0Zm9ybXMNCi0gbW92ZSByZXQxIGRlY2xhcmF0aW9uIHRvIHRoZSB0 b3Agb2YgdGhlIGZ1bmN0aW9uIGFzIHJlcXVpcmVkIGJ5IGNvZGUNCnN0eWxlDQoNCkNoYW5nZXMg aW4gdjY6DQotIGNoYW5nZSBpb21tdV9kb19kb21jdGwgYW5kIHNjaV9kb19kb21jdGwgY29tbWFu ZCBvcmRlciBhbmQNCmNhbGwgc2NpX2RvX2RvbWN0bCBmaXJzdCB3aGljaCB3aWxsIHByb2R1Y2Ug Y2xlYW5lciBjb2RlIHBhdGguDQpBbHNvIGRyb3BwZWQgY2hhbmdpbmcgcmV0dXJuIGNvZGUgd2hl biBpb21tdSB3YXMgZGlzYWJsZWQgaW4NCmlvbW11X2RvX2RvbWN0bC4NCg0KQ2hhbmdlcyBpbiB2 NToNCi0gcmV0dXJuIC1FSU5WQUwgaWYgbWVkaWF0b3Igd2l0aG91dCBhc3NpZ25fZHRfZGV2aWNl IHdhcyBwcm92aWRlZA0KLSBpbnZlcnQgcmV0dXJuIGNvZGUgY2hlY2sgZm9yIGlvbW11X2RvX2Rv bWN0bCBpbg0KWEVOX0RPTUNUTF9hc3NpZ25fZGV2aWNlIGRvbWN0bCBwcm9jZXNzaW5nIHRvIG1h a2UgY2xlYW5lciBjb2RlDQotIGNoYW5nZSAtRU5PVFNVUFAgZXJyb3IgY29kZSB0byAtRU5YSU8g aW4gc2NpX2RvX2RvbWN0bA0KLSBoYW5kbGUgLUVOWElPIHJldHVybiBjb21kZSBvZiBpb21tdV9k b19kb21jdGwNCi0gbGVhdmUgIWR0X2RldmljZV9pc19wcm90ZWN0ZWQgY2hlY2sgaW4gaW9tbXVf ZG9fZHRfZG9tY3RsIHRvIG1ha2UNCmNvZGUgd29yayB0aGUgc2FtZSB3YXkgaXQncyBkb25lIGlu ICJoYW5kbGVfZGV2aWNlIiBjYWxsIHdoaWxlDQpjcmVhdGluZyBod2RvbShkb20wKSBhbmQgImhh bmRsZV9wYXNzdGhyb3VnaF9wcm9wIiBjYWxsIGZvciBkb20wbGVzcw0KY3JlYXRpb24NCi0gZHJv cCByZXR1cm4gY2hlY2sgZnJvbSBzY2lfYXNzaWduX2R0X2RldmljZSBjYWxsIGFzIG5vdCBuZWVk ZWQNCi0gZG8gbm90IHJldHVybiBFSU5WQUwgd2hlbiBhZGRpZ25fZHRfZGV2aWNlIGlzIG5vdCBz ZXQuIFRoYXQgaXMNCmJlY2F1c2UgdGhpcyBjYWxsYmFjayBpcyBvcHRpb25hbCBhbmQgbm90IGlt cGxlbWVudGVkIGluIHNpbmdsZS1hZ2VudCBkcml2ZXINCg0KIHhlbi9hcmNoL2FybS9maXJtd2Fy ZS9zY2kuYyAgICAgICAgICAgICB8IDM1ICsrKysrKysrKysrKysrKysrKysrKysrKysNCiB4ZW4v YXJjaC9hcm0vaW5jbHVkZS9hc20vZmlybXdhcmUvc2NpLmggfCAxNCArKysrKysrKysrDQogeGVu L2NvbW1vbi9kb21jdGwuYyAgICAgICAgICAgICAgICAgICAgIHwgMzUgKysrKysrKysrKysrKysr KysrKysrKysrLQ0KIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2RldmljZV90cmVlLmMgICB8ICA2 ICsrKysrDQogNCBmaWxlcyBjaGFuZ2VkLCA4OSBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9uKC0p DQoNCmRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NpLmMgYi94ZW4vYXJjaC9h cm0vZmlybXdhcmUvc2NpLmMNCmluZGV4IGFhOTNjZGE3ZjAuLjMxYTdlNWMyOGIgMTAwNjQ0DQot LS0gYS94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NpLmMNCisrKyBiL3hlbi9hcmNoL2FybS9maXJt d2FyZS9zY2kuYw0KQEAgLTEyNiw2ICsxMjYsNDEgQEAgaW50IHNjaV9hc3NpZ25fZHRfZGV2aWNl KHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqZGV2KQ0KICAgICByZXR1 cm4gMDsNCiB9DQogDQoraW50IHNjaV9kb19kb21jdGwoc3RydWN0IHhlbl9kb21jdGwgKmRvbWN0 bCwgc3RydWN0IGRvbWFpbiAqZCwNCisgICAgICAgICAgICAgICAgICBYRU5fR1VFU1RfSEFORExF X1BBUkFNKHhlbl9kb21jdGxfdCkgdV9kb21jdGwpDQorew0KKyAgICBzdHJ1Y3QgZHRfZGV2aWNl X25vZGUgKmRldjsNCisgICAgaW50IHJldCA9IDA7DQorDQorICAgIHN3aXRjaCAoIGRvbWN0bC0+ Y21kICkNCisgICAgew0KKyAgICBjYXNlIFhFTl9ET01DVExfYXNzaWduX2RldmljZToNCisgICAg ICAgIHJldCA9IC1FTlhJTzsNCisgICAgICAgIGlmICggZG9tY3RsLT51LmFzc2lnbl9kZXZpY2Uu ZGV2ICE9IFhFTl9ET01DVExfREVWX0RUICkNCisgICAgICAgICAgICBicmVhazsNCisNCisgICAg ICAgIGlmICggIWN1cl9tZWRpYXRvciApDQorICAgICAgICAgICAgYnJlYWs7DQorDQorICAgICAg ICBpZiAoICFjdXJfbWVkaWF0b3ItPmFzc2lnbl9kdF9kZXZpY2UgKQ0KKyAgICAgICAgICAgIGJy ZWFrOw0KKw0KKyAgICAgICAgcmV0ID0gZHRfZmluZF9ub2RlX2J5X2dwYXRoKGRvbWN0bC0+dS5h c3NpZ25fZGV2aWNlLnUuZHQucGF0aCwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBkb21jdGwtPnUuYXNzaWduX2RldmljZS51LmR0LnNpemUsICZkZXYpOw0KKyAgICAgICAg aWYgKCByZXQgKQ0KKyAgICAgICAgICAgIHJldHVybiByZXQ7DQorDQorICAgICAgICByZXQgPSBz Y2lfYXNzaWduX2R0X2RldmljZShkLCBkZXYpOw0KKw0KKyAgICAgICAgYnJlYWs7DQorICAgIGRl ZmF1bHQ6DQorICAgICAgICAvKiBkbyBub3QgZmFpbCBoZXJlIGFzIGNhbGwgaXMgY2hhaW5lZCB3 aXRoIGlvbW11IGhhbmRsaW5nICovDQorICAgICAgICBicmVhazsNCisgICAgfQ0KKw0KKyAgICBy ZXR1cm4gcmV0Ow0KK30NCisNCiBzdGF0aWMgaW50IF9faW5pdCBzY2lfaW5pdCh2b2lkKQ0KIHsN CiAgICAgc3RydWN0IGR0X2RldmljZV9ub2RlICpucDsNCmRpZmYgLS1naXQgYS94ZW4vYXJjaC9h cm0vaW5jbHVkZS9hc20vZmlybXdhcmUvc2NpLmggYi94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20v ZmlybXdhcmUvc2NpLmgNCmluZGV4IDM1MDAyMTZiYzIuLmEyZDMxNGU2MjcgMTAwNjQ0DQotLS0g YS94ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZmlybXdhcmUvc2NpLmgNCisrKyBiL3hlbi9hcmNo L2FybS9pbmNsdWRlL2FzbS9maXJtd2FyZS9zY2kuaA0KQEAgLTE0Niw2ICsxNDYsMTQgQEAgaW50 IHNjaV9kdF9maW5hbGl6ZShzdHJ1Y3QgZG9tYWluICpkLCB2b2lkICpmZHQpOw0KICAqIGNvbnRy b2wiIGZ1bmN0aW9uYWxpdHkuDQogICovDQogaW50IHNjaV9hc3NpZ25fZHRfZGV2aWNlKHN0cnVj dCBkb21haW4gKmQsIHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqZGV2KTsNCisNCisvKg0KKyAqIFND SSBkb21jdGwgaGFuZGxlcg0KKyAqDQorICogT25seSBYRU5fRE9NQ1RMX2Fzc2lnbl9kZXZpY2Ug aXMgaGFuZGxlZCBmb3Igbm93Lg0KKyAqLw0KK2ludCBzY2lfZG9fZG9tY3RsKHN0cnVjdCB4ZW5f ZG9tY3RsICpkb21jdGwsIHN0cnVjdCBkb21haW4gKmQsDQorICAgICAgICAgICAgICAgICAgWEVO X0dVRVNUX0hBTkRMRV9QQVJBTSh4ZW5fZG9tY3RsX3QpIHVfZG9tY3RsKTsNCiAjZWxzZQ0KIA0K IHN0YXRpYyBpbmxpbmUgYm9vbCBzY2lfZG9tYWluX2lzX2VuYWJsZWQoc3RydWN0IGRvbWFpbiAq ZCkNCkBAIC0xOTUsNiArMjAzLDEyIEBAIHN0YXRpYyBpbmxpbmUgaW50IHNjaV9hc3NpZ25fZHRf ZGV2aWNlKHN0cnVjdCBkb21haW4gKmQsDQogICAgIHJldHVybiAwOw0KIH0NCiANCitzdGF0aWMg aW5saW5lIGludCBzY2lfZG9fZG9tY3RsKHN0cnVjdCB4ZW5fZG9tY3RsICpkb21jdGwsIHN0cnVj dCBkb21haW4gKmQsDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBYRU5fR1VFU1Rf SEFORExFX1BBUkFNKHhlbl9kb21jdGxfdCkgdV9kb21jdGwpDQorew0KKyAgICByZXR1cm4gMDsN Cit9DQorDQogI2VuZGlmIC8qIENPTkZJR19BUk1fU0NJICovDQogDQogI2VuZGlmIC8qIF9fQVNN X0FSTV9TQ0lfSCAqLw0KZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vZG9tY3RsLmMgYi94ZW4vY29t bW9uL2RvbWN0bC5jDQppbmRleCA5NTRkNzkwMjI2Li41YTMxY2NjZGQ3IDEwMDY0NA0KLS0tIGEv eGVuL2NvbW1vbi9kb21jdGwuYw0KKysrIGIveGVuL2NvbW1vbi9kb21jdGwuYw0KQEAgLTI5LDYg KzI5LDkgQEANCiAjaW5jbHVkZSA8eGVuL3h2bWFsbG9jLmg+DQogDQogI2luY2x1ZGUgPGFzbS9j dXJyZW50Lmg+DQorI2lmIElTX0VOQUJMRUQoQ09ORklHX0FSTSkNCisjaW5jbHVkZSA8YXNtL2Zp cm13YXJlL3NjaS5oPg0KKyNlbmRpZg0KICNpbmNsdWRlIDxhc20vaXJxLmg+DQogI2luY2x1ZGUg PGFzbS9wYWdlLmg+DQogI2luY2x1ZGUgPGFzbS9wMm0uaD4NCkBAIC0yNzQsNyArMjc3LDcgQEAg c3RhdGljIGJvb2wgaXNfc3RhYmxlX2RvbWN0bCh1aW50MzJfdCBjbWQpDQogDQogbG9uZyBkb19k b21jdGwoWEVOX0dVRVNUX0hBTkRMRV9QQVJBTSh4ZW5fZG9tY3RsX3QpIHVfZG9tY3RsKQ0KIHsN Ci0gICAgbG9uZyByZXQgPSAwOw0KKyAgICBsb25nIHJldCA9IDAsIHJldDEgPSAwOw0KICAgICBi b29sIGNvcHliYWNrID0gZmFsc2U7DQogICAgIHN0cnVjdCB4ZW5fZG9tY3RsIGN1cm9wLCAqb3Ag PSAmY3Vyb3A7DQogICAgIHN0cnVjdCBkb21haW4gKmQ7DQpAQCAtODI3LDcgKzgzMCwzNyBAQCBs b25nIGRvX2RvbWN0bChYRU5fR1VFU1RfSEFORExFX1BBUkFNKHhlbl9kb21jdGxfdCkgdV9kb21j dGwpDQogICAgIGNhc2UgWEVOX0RPTUNUTF90ZXN0X2Fzc2lnbl9kZXZpY2U6DQogICAgIGNhc2Ug WEVOX0RPTUNUTF9kZWFzc2lnbl9kZXZpY2U6DQogICAgIGNhc2UgWEVOX0RPTUNUTF9nZXRfZGV2 aWNlX2dyb3VwOg0KKyAgICAgICAgaWYgKCBJU19FTkFCTEVEKENPTkZJR19BUk0pICkNCisgICAg ICAgIHsNCisgICAgICAgICAgICAvKg0KKyAgICAgICAgICAgICAqIEFkZCBjaGFpbmVkIGhhbmRs aW5nIG9mIGFzc2lnbmVkIERUIGRldmljZXMgdG8gc3VwcG9ydA0KKyAgICAgICAgICAgICAqIGFj Y2Vzcy1jb250cm9sbGVyIGZ1bmN0aW9uYWxpdHkgdGhyb3VnaCBTQ0kgZnJhbWV3b3JrLCBzbw0K KyAgICAgICAgICAgICAqIERUIGRldmljZSBhc3NpZ24gcmVxdWVzdCBjYW4gYmUgcGFzc2VkIHRv IEZXIGZvciBwcm9jZXNzaW5nIGFuZA0KKyAgICAgICAgICAgICAqIGVuYWJsaW5nIFZNIGFjY2Vz cyB0byByZXF1ZXN0ZWQgZGV2aWNlLg0KKyAgICAgICAgICAgICAqIFRoZSBhY2Nlc3MtY29udHJv bGxlciBEVCBkZXZpY2UgcHJvY2Vzc2luZyBpcyBjYWxsZWQgYmVmb3JlIElPTU1VDQorICAgICAg ICAgICAgICogcHJvY2Vzc2luZyBwcmVzZXJ2aW5nIHJldHVybiBjb2RlIGFuZCBleHBlY3RlZCB0 byBiZSBleGVjdXRlZCBmb3INCisgICAgICAgICAgICAgKiBhbnkgRFQgZGV2aWNlIHJlZ2FyZGxl c3MgaWYgRFQgZGV2aWNlIGlzIHByb3RlY3RlZCBieSBJT01NVSBvcg0KKyAgICAgICAgICAgICAq IG5vdCAob3IgSU9NTVUgaXMgZGlzYWJsZWQpLg0KKyAgICAgICAgICAgICAqLw0KKyAgICAgICAg ICAgIHJldDEgPSBzY2lfZG9fZG9tY3RsKG9wLCBkLCB1X2RvbWN0bCk7DQorICAgICAgICAgICAg aWYgKCByZXQxIDwgMCApDQorICAgICAgICAgICAgICAgIHJldHVybiByZXQxOw0KKyAgICAgICAg fQ0KKyAgICAgICAgZWxzZQ0KKyAgICAgICAgICAgIHJldDEgPSAtRU5YSU87DQorDQogICAgICAg ICByZXQgPSBpb21tdV9kb19kb21jdGwob3AsIGQsIHVfZG9tY3RsKTsNCisgICAgICAgIGlmICgg cmV0IDwgMCApDQorICAgICAgICAgICAgcmV0dXJuIHJldDsNCisNCisgICAgICAgIC8qDQorICAg ICAgICAgKiBJZiBJT01NVSBwcm9jZXNzaW5nIHdhcyBzdWNjZXNzZnVsLCBjaGVjayBmb3IgU0NJ IHByb2Nlc3NpbmcgcmV0dXJuDQorICAgICAgICAgKiBjb2RlIGFuZCBpZiBpdCB3YXMgZmFpbGVk IHRoZW4gb3ZlcndyaXRlIHRoZSByZXR1cm4gY29kZSB0byBwcm9wYWdhdGUNCisgICAgICAgICAq IFNDSSBmYWlsdXJlIGJhY2sgdG8gY2FsbGVyLg0KKyAgICAgICAgICovDQorICAgICAgICBpZiAo IHJldDEgIT0gLUVOWElPICkNCisgICAgICAgICAgICByZXQgPSByZXQxOw0KKw0KICAgICAgICAg YnJlYWs7DQogDQogICAgIGNhc2UgWEVOX0RPTUNUTF9nZXRfcGFnaW5nX21lbXBvb2xfc2l6ZToN CmRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9kZXZpY2VfdHJlZS5jIGIveGVu L2RyaXZlcnMvcGFzc3Rocm91Z2gvZGV2aWNlX3RyZWUuYw0KaW5kZXggZjU4NTBhMjYwNy4uMjlh NDRkYzc3MyAxMDA2NDQNCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2RldmljZV90cmVl LmMNCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2RldmljZV90cmVlLmMNCkBAIC0zNzks NiArMzc5LDEyIEBAIGludCBpb21tdV9kb19kdF9kb21jdGwoc3RydWN0IHhlbl9kb21jdGwgKmRv bWN0bCwgc3RydWN0IGRvbWFpbiAqZCwNCiAgICAgICAgICAgICBicmVhazsNCiAgICAgICAgIH0N CiANCisgICAgICAgIGlmICggIWR0X2RldmljZV9pc19wcm90ZWN0ZWQoZGV2KSApDQorICAgICAg ICB7DQorICAgICAgICAgICAgcmV0ID0gMDsNCisgICAgICAgICAgICBicmVhazsNCisgICAgICAg IH0NCisNCiAgICAgICAgIHJldCA9IGlvbW11X2Fzc2lnbl9kdF9kZXZpY2UoZCwgZGV2KTsNCiAN CiAgICAgICAgIGlmICggcmV0ICkNCi0tIA0KMi4zNC4xDQo= From xen-devel-bounces@lists.xenproject.org Wed Jan 14 18:29:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 18:29:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203676.1518768 (Exim 4.92) (envelope-from ) id 1vg5cy-0006cl-Rx; Wed, 14 Jan 2026 18:29:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203676.1518768; Wed, 14 Jan 2026 18: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 1vg5cy-0006c5-Mq; Wed, 14 Jan 2026 18:29:56 +0000 Received: by outflank-mailman (input) for mailman id 1203676; Wed, 14 Jan 2026 18:29: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 1vg5cx-0005zq-R9 for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 18:29:55 +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 0531865b-f177-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 19:29:54 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by AS2PR03MB9465.eurprd03.prod.outlook.com (2603:10a6:20b:59e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Wed, 14 Jan 2026 18:29:49 +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.9520.005; Wed, 14 Jan 2026 18:29:49 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0531865b-f177-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mCIC6pJOhQZjdJ3Q9pk4DPPXVVu/7u73GWHaoTl3K8JOhkKs6JNUcC/dH1rJ3entwQAbEmS1EV3meEfJawko3VFyU4ZustXGYx+Jkd6YfMyPG7in2tgh7rpGcB6mS/A9ZtLTlJi+ZIv9V61kLhtQFK/gLQ6zjEUDRvbz5RxPnLbxD9AFWLSn4p/PSlHTKk/R7VIgKXE2uG0OoDuFaCJKi06JgCLsYccA6DlS+TURKTkeF9ESnRJHJKyaoNGl9eTTZwTw0yxdv9uChDwJTJBRBlyMa1DlfHwFFs+MRsYLlgCrhXZUYGryg309psvGP2aXBFiEJe6aiIYecnHt7N37dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YBJ28+wEFMkWxPquD6NRuZ/oMYSkhs3ZtZEPQWhlYnU=; b=FMH1bLksSnd6M60ABwuk1wxpYkkfbA1aSvp3DMcBV/9nyMfy3rIpMtMBZdwQB5e2OAixl17yhiLgSAbrV7CsUUM41GcdTOAxsZti2JIBj2NHjrKJdlc0QyaeDEU3+qyVDgLR77NsP78ML9LcTeXy+x5pwmv3GkIXDSfT1Inu/dsCyi2RFpTLSOo9IF+ZdOrcuLUyq3blymCsoqojN8B1grlhsQrzikDdObAfn1YeI/0OseU4DSmZ6RLCBdLYAa5oac9cs80CS4f750SDzha24afGJDf5+9pO/pa7g9aQnjbzzuxIy3W2Agw4k0FTPpKLQscdM+PIf+BzFHy6eDehHA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YBJ28+wEFMkWxPquD6NRuZ/oMYSkhs3ZtZEPQWhlYnU=; b=EywkCCfHbVmSP6bmF/8KJUU6ruWqX0BnFQ5dYbNK02tw5qlQxmghOKOxHl2DxPSsckX3Vr65uF2G76tngm8a1rBvC0mxXgCokNQcF3Zw4GJUkDcdCRkZrQ+arwnZkYwqQc6Fm92mFjg78UM5PfRafJ4gIo3EZ2iQKM7WfR358UlnOIo4BB8oJEwYopQ4IvHoVYBoMJ7DKY4hYaMHpCYKHI16cZBtpuV+pFSgPoTCfaik++EnAFRo9bCw6DHXnQAuBehR82RYfqNy6fSBl1HHbtkrBp8GQ7m9XocB/sAwt2acqoNgq3AvUb3a6SMF/5CsiTfdbRq+Gx3L5/eLPFBZng== 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/5] lib/arm: Add I/O memory copy helpers Thread-Topic: [PATCH v7 3/5] lib/arm: Add I/O memory copy helpers Thread-Index: AQHchYPD+fwQGyuKXEKqeHI8xFGbqA== Date: Wed, 14 Jan 2026 18:29:48 +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_|AS2PR03MB9465:EE_ x-ms-office365-filtering-correlation-id: c39b417c-e9a6-4348-42d0-08de539ae6c1 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|7416014|376014|38070700021; x-microsoft-antispam-message-info: =?iso-8859-1?Q?5AKzwDTcQJ/AkSr3keE+L4GK4PdHHVllc4DXfH+cFgoTe7+s9jlXTafF/s?= =?iso-8859-1?Q?sOstg7jGk/AJpH6/iS6oYrNC2wtvDENcQ1NLkU+6b8DwZgZ9xpWq9mtY42?= =?iso-8859-1?Q?523qsDtrRsm3um6KjmXaWYdrblK0Z2sVHO4aJgVksO4NGVrWrg+/sA414g?= =?iso-8859-1?Q?d1i1Mrm0NmFn0eO/7s1JAPvJoDuneL/74aSLAq51fr2vx42Dt7blPuk4ya?= =?iso-8859-1?Q?UMFHn+lFr/O8Ufd2ISJNOKQhCavhmlO140tB1qdb6NTyb/Bom6mvtBpxyQ?= =?iso-8859-1?Q?nMdcizXM4aJZ+1gtVkWBitP/yUcH8um4qSP7CBPbk5F1BznwF0kDGvArwb?= =?iso-8859-1?Q?28FJ+pSP740k6eTVFt+Gd9UqVwgoNs2EpuB/qCJE0WbDIM2qrQ3PuIQeMW?= =?iso-8859-1?Q?FOWUdJoqtgYeNCih1Mq/y/Ap+VnKuBy7OesGZpHqMPPGxbLGb9BNdYok9Y?= =?iso-8859-1?Q?LC/izhDiAcsp3bs0k2CRftoE2LSxKDMsjiZpG062zTPSyNPfwc+M0UTypH?= =?iso-8859-1?Q?D9prOAByOLBwOlSd2at2VEm5uyhOCazGOMyc8GutCOlUTr60Ug2QcwzDqb?= =?iso-8859-1?Q?SYwnhuUHPFUOtmPOKwR0FasGQQPOm0rvDQ+kzlAGPvS0n4qGcuJ2wo+yTV?= =?iso-8859-1?Q?QG8TRcKuCr2gvjGDxuqSL/3mXe4V3C/5wpOrJCGOA/UITGAoWnh/+4jGg2?= =?iso-8859-1?Q?ibiqh9taFwFXwVbqnuagvnDNGjrpD39eVrMN91OY/HcUcRRRkPxqBLRLyg?= =?iso-8859-1?Q?ebOyovjh4wDLszvMOOCNsNZjp/+m52IXiF27WKCfPXPVM2o8ratHI8QcKh?= =?iso-8859-1?Q?o4HjSZu+a6D2is31w0pct8hfL6kAjb5jLOUpH9oUbXTmmLkjnkK74u7z62?= =?iso-8859-1?Q?s/VvOHdUftzL0AJ74XyIkRLc0SjspzcyPTna8VaFa4S0sTNKaSh3W9JSwl?= =?iso-8859-1?Q?KaI399LGA+fqHkH12/qFWG0i/vtQMio8CxCj+scjzt7h8X7Lqpj9pxBeDf?= =?iso-8859-1?Q?VSVWQKvN/NEhB+l0f7jbrYAd7mAlvrVvabwjFhQkxOCDth2n83dS9bfLjD?= =?iso-8859-1?Q?DKPKuA6rmKBi37n7FoJ2vxTBqfuxc/EetmWKGyBvt9hdH03JrNSdYw2kei?= =?iso-8859-1?Q?U8QvrCubRnXL4wazwa9w81RE2iXpm5LjI5hqpXRHnux5MxzcJMnX8nrrLN?= =?iso-8859-1?Q?Hsw/oTyjeJ8+JgloDK1LZydmjXF4rdyMwDpC4uOnKf//wylDDWe8jDNb91?= =?iso-8859-1?Q?L52Jxz7lYPRUS+iysms1pGNSgG6gAHOYQ44AfMyFl4pcd7oCXGT8UBpHgV?= =?iso-8859-1?Q?imL1FCfs8gX1OGiKtotcAp7HHk4iduMF0VksU9JE7/g92T8mk0/7snD554?= =?iso-8859-1?Q?f0gKf9np//c4ABiZyYIPa2d1Uo1IbtQqwrq4ShcNqD6rUVoj+Ktpfd10OI?= =?iso-8859-1?Q?dPEKVbv1b1M1sZnZ9PIeRxO8paobOL19+nMOuPEYbQUchdMc9fZo2/vQqv?= =?iso-8859-1?Q?gWL6Z8xT+XagGQAx9Up4bmoxeZmtAM7a/flJLw7vaFqJxQcgTS1XDWobcD?= =?iso-8859-1?Q?3uTS0dHp94JszE+OOVOnNwvel8a3mdYwL2bho/Gjpp/Vrs3SQOBFOJihdV?= =?iso-8859-1?Q?4+oy1Mkz/m7enb4UdHTj1/NjNsJwllMkAEmcs6XHAtvgkOamjzZSsJKojk?= =?iso-8859-1?Q?07Qhn2K3AjAjMdInBww=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)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?EPOOcGaW6UgXikcbSa+MaGZyuyg75DrkWLwoyeDGomVr7GTBqZOfIRtNRG?= =?iso-8859-1?Q?EcFUOvm3lGCXhESYNq0FFgvgx+3TUoT06IrcL4nxneyp+gtHgecTbED97/?= =?iso-8859-1?Q?rhPkhl3x4A4bx5KlMSI2GJLjMJJY/PgvCBHaDXiuUomhGFVw0c4wUEzBiQ?= =?iso-8859-1?Q?5PyF07yReNr4A3tj6to7OgqV/ylixqxkEWI5xkwemOnJdAjanBU2+lX/wo?= =?iso-8859-1?Q?XJYXFuR20v+38neLxCjInC2dhwOavd1UODZ+3JTc56nlBRndFcezKx6Bat?= =?iso-8859-1?Q?JWN9Dp82Otc0SReCtM3KZCtbeJzmx/Jy2yceMhb/mPHHlnPLICqgpMxlPr?= =?iso-8859-1?Q?oFax0A4KD+LYEWbtobSB9ilIN+tcK8Yz88Jmz5mHhGtRvIOZPUQF7ubIJt?= =?iso-8859-1?Q?lpoca02sVNvLewaGwwPzYLZHZJLTGBK2GMJUEEZf7IL8AkxxetqFKNd67s?= =?iso-8859-1?Q?CRROz5fdhnh6OYBMOczhhhMO1XchyhfELyFf8jB6sGsbL1yXHvSdrKTsf9?= =?iso-8859-1?Q?URwy1ivyvD08f/h24La7LNuK2NYar7QoLplpMBn4xTVYVSBiHqbmFP3SkW?= =?iso-8859-1?Q?wPEwzNYkIhStAqZ3tgL9FiRSXTcfG1XGhQVFTgw438f1bQDOITyIUdAHRx?= =?iso-8859-1?Q?Ht/Pw+B+Txfdm/9IxhBBZGxam3AjsTDeSyBvmuT/CIlnzc0pvRQBPgQXEm?= =?iso-8859-1?Q?ljMRhkw3GvLKrPE9bqSTLeuzHMTMCRg0cUX1UF7RXulZmN4hJNEjDtfAFi?= =?iso-8859-1?Q?YfjZSxX6S9V1d4rO8e+P6mktOkzgj9uurRfi9DbPU4OPSNpIHbKV0+K48m?= =?iso-8859-1?Q?pBj/vJh7+ce+/mv6v6nreavLprC1eGvW/n84CSHK/caaZ+7qfmIP5OoEwV?= =?iso-8859-1?Q?fc/AI9kSHKFoeL7mQVvNP4GFJtzMoeZdpCfFAuCTJsDUZrUXL4Tgbk9n6y?= =?iso-8859-1?Q?xFIwrLnFVlbo5jn0x2Fo21KNL5w5cLmrv6I4RB1XOyU7xq125MeKwdSWXC?= =?iso-8859-1?Q?/BSHJETnnCWvgNSll493Y93mDZJkxgQEEanKPQMOqH5mg8gjkTL0TWlZyL?= =?iso-8859-1?Q?94eogkEkls6doFPiVPQigUyhXlDqWy3R0CHvLypGQzWjcmdL7TyjZHvoIF?= =?iso-8859-1?Q?N32OATdjRZ4zfpzHfFLGOqpI/2SAKQGAp5/FHWVD2T7de9mv0vPycL/QcC?= =?iso-8859-1?Q?sOdNZhLpc0evj4zelvx4Uubmniu0NElwF9zhDAZtqtQPzqwnPmb824qeQz?= =?iso-8859-1?Q?0pfiVlzpGRBfcDXUF0yOH2LkRnIjVOlLvWR5cSiP25rbWs1TMr73FMpVnh?= =?iso-8859-1?Q?N0wT6rZPbAvN6Xz+fSHxyGNzXUCmdKgzXVZQM/TV6/bCjYLrKZlYY6fCiK?= =?iso-8859-1?Q?Ew231ivTBiUA1zThwXH6jsssUF+a85nSdHUTLxL+91/f7rUjFtP/ABkKct?= =?iso-8859-1?Q?9jZhDl46OlfqrwPpiNHkNwkdFIDX654424026z4QBTAjDSohyhdL9cad2f?= =?iso-8859-1?Q?c+U+mu06grkK8LS25P3AmgY4TKJgjhvfIDlmxA9wk3JYbeflrdfs4yGtiH?= =?iso-8859-1?Q?zmcgBYu3I26QL1Qgm88DLof++iEk4ww9OOyJWghw1+pHAn6bBJpmvUPJhS?= =?iso-8859-1?Q?LBOTVK+rWb5rg7gh4CgriDCFKQXPS1K6gqMxPwG67eQpXxbRD6TWKgSiAH?= =?iso-8859-1?Q?4lCEfVTqoAX+rjps+7HGfCLQ48DlgVWdj/yjDkewD9FY6m6p9v/qt3slfi?= =?iso-8859-1?Q?9nNZQlsrux5ncd+8oQAkgXrys4aZwrSB4US2XNLGch1ab7BglZiw2FK2Qv?= =?iso-8859-1?Q?nwYoIuPO1IWWbJRmHhyjKWlN8UXPGhM=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: c39b417c-e9a6-4348-42d0-08de539ae6c1 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2026 18:29:48.7771 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OTLPb0LVgZAkIEkj+GCN51nB+8KC4NrXbim3IeJ6FPtPuFgaNGeSRyXP6HA7uWBz0p+3+4RzhVibe0i8RRvmiTV/TRE9idjSh5l6kct3w5E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9465 This commit introduces two helper functions, `memcpy_fromio` and `memcpy_toio`, to provide a robust mechanism for copying data between standard memory and memory-mapped I/O (MMIO) space for the ARM architecture. These helpers handle alignment safely by using byte accesses for any leading/trailing unaligned bytes and 32-bit raw accesses for the aligned bulk transfer. Using `__raw_readb/__raw_readl` and `__raw_writeb/__raw_writel` avoids unintended endianness conversion while remaining safe across ARM32/ARM64 devices that only support 32-bit accesses. The interface lives in the generic header so other architectures can provide their own implementations (as macros or functions). The ARM implementation is split into separate compilation units and added to the architecture-specific lib Makefile. Signed-off-by: Oleksii Moisieiev --- Changes in v7: - x86 guidance: removed the speculative note; header now just says each arch supplies its own implementation or macro. - name spacing: dropped the double-underscore; the helpers are now memcpy_fromio / memcpy_toio. The header also explicitly allows an arch to define these as macros before including it. - updated io.c to keep 32-bit transfers safe on arm32 - moved to __raw_read*/__raw_write* accessors to avoid endianness conversio= n. - split the helpers into separate compilation units Changes in v6: - sorted objs in Makefile alhabetically - added newline at the end of Makefile - used uint{N}_t intead of u{N} - add comment about why 32 bit IO operations were used - updated cast opertaions to avoid dropping constness which is wrong - move function definitions to generic place so the could be reused by other arch - add SPDX tag to io.c Changes in v5: - move memcpy_toio/fromio to the generic place xen/include/xen/lib/io.h | 65 +++++++++++++++++++++++++++++++++++++ xen/lib/Makefile | 1 + xen/lib/arm/Makefile | 1 + xen/lib/arm/memcpy_fromio.c | 48 +++++++++++++++++++++++++++ xen/lib/arm/memcpy_toio.c | 48 +++++++++++++++++++++++++++ 5 files changed, 163 insertions(+) create mode 100644 xen/include/xen/lib/io.h create mode 100644 xen/lib/arm/Makefile create mode 100644 xen/lib/arm/memcpy_fromio.c create mode 100644 xen/lib/arm/memcpy_toio.c diff --git a/xen/include/xen/lib/io.h b/xen/include/xen/lib/io.h new file mode 100644 index 0000000000..cd2b6680d5 --- /dev/null +++ b/xen/include/xen/lib/io.h @@ -0,0 +1,65 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Generic I/O memory copy function prototypes. + * + * These functions provide low-level implementation for copying data betwe= en + * regular memory and I/O memory regions. Each architecture must provide i= ts + * own implementation based on the specific requirements of the architectu= re's + * memory model and I/O access patterns. An architecture may supply these = as + * functions or as macros in its own headers before including this file. + * + * Architecture-specific implementations: + * =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 + * Each architecture should implement these functions in xen/lib//io= .c + * (or define them as macros) based on their hardware requirements. See + * xen/lib/arm/io.c for an example using explicit I/O accessors. + */ + +#ifndef _XEN_LIB_IO_H +#define _XEN_LIB_IO_H + +#include + +/* + * memcpy_fromio - Copy data from I/O memory space to regular memory + * @to: Destination buffer in regular memory + * @from: Source address in I/O memory space (must be marked __iomem) + * @count: Number of bytes to copy + * + * This function handles copying from memory-mapped I/O regions using + * architecture-appropriate I/O accessor functions. It ensures proper: + * - Memory ordering and barriers + * - Alignment requirements + * - Hardware-specific access semantics + * + * Each architecture provides its own implementation that may: + * - Use special I/O accessor functions (ARM: readl_relaxed, readb_relaxed= ) + * - Implement alignment handling for devices requiring specific access si= zes + * - Add memory barriers to ensure ordering with other I/O operations + * - Or simply map to memcpy() if the architecture allows direct I/O acces= s + */ +extern void memcpy_fromio(void *to, const volatile void __iomem *from, + size_t count); + +/* + * memcpy_toio - Copy data from regular memory to I/O memory space + * @to: Destination address in I/O memory space (must be marked __iomem) + * @from: Source buffer in regular memory + * @count: Number of bytes to copy + * + * This function handles copying to memory-mapped I/O regions using + * architecture-appropriate I/O accessor functions. It ensures proper: + * - Memory ordering and barriers + * - Alignment requirements + * - Hardware-specific access semantics + * + * Each architecture provides its own implementation that may: + * - Use special I/O accessor functions (ARM: writel_relaxed, writeb_relax= ed) + * - Implement alignment handling for devices requiring specific access si= zes + * - Add memory barriers to ensure ordering with other I/O operations + * - Or simply map to memcpy() if the architecture allows direct I/O acces= s + */ +extern void memcpy_toio(volatile void __iomem *to, const void *from, + size_t count); + +#endif /* _XEN_LIB_IO_H */ diff --git a/xen/lib/Makefile b/xen/lib/Makefile index 5ccb1e5241..6bb0491d89 100644 --- a/xen/lib/Makefile +++ b/xen/lib/Makefile @@ -1,3 +1,4 @@ +obj-$(CONFIG_ARM) +=3D arm/ obj-$(CONFIG_X86) +=3D x86/ =20 lib-y +=3D bsearch.o diff --git a/xen/lib/arm/Makefile b/xen/lib/arm/Makefile new file mode 100644 index 0000000000..0bb1a825ce --- /dev/null +++ b/xen/lib/arm/Makefile @@ -0,0 +1 @@ +obj-y +=3D memcpy_fromio.o memcpy_toio.o diff --git a/xen/lib/arm/memcpy_fromio.c b/xen/lib/arm/memcpy_fromio.c new file mode 100644 index 0000000000..342a28cb49 --- /dev/null +++ b/xen/lib/arm/memcpy_fromio.c @@ -0,0 +1,48 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#include +#include + +/* + * Use 32-bit raw IO operations for portability across ARM32/ARM64 where + * 64-bit accessors may not be atomic and some devices only support 32-bit + * aligned accesses. + */ + +void memcpy_fromio(void *to, const volatile void __iomem *from, + size_t count) +{ + while ( count && (!IS_ALIGNED((unsigned long)from, 4) || + !IS_ALIGNED((unsigned long)to, 4)) ) + { + *(uint8_t *)to =3D __raw_readb(from); + from++; + to++; + count--; + } + + while ( count >=3D 4 ) + { + *(uint32_t *)to =3D __raw_readl(from); + from +=3D 4; + to +=3D 4; + count -=3D 4; + } + + while ( count ) + { + *(uint8_t *)to =3D __raw_readb(from); + from++; + to++; + count--; + } +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 8 + * tab-width: 8 + * indent-tabs-mode: t + * End: + */ diff --git a/xen/lib/arm/memcpy_toio.c b/xen/lib/arm/memcpy_toio.c new file mode 100644 index 0000000000..e543c49124 --- /dev/null +++ b/xen/lib/arm/memcpy_toio.c @@ -0,0 +1,48 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#include +#include + +/* + * Use 32-bit raw IO operations for portability across ARM32/ARM64 where + * 64-bit accessors may not be atomic and some devices only support 32-bit + * aligned accesses. + */ + +void memcpy_toio(volatile void __iomem *to, const void *from, + size_t count) +{ + while ( count && (!IS_ALIGNED((unsigned long)to, 4) || + !IS_ALIGNED((unsigned long)from, 4)) ) + { + __raw_writeb(*(const uint8_t *)from, to); + from++; + to++; + count--; + } + + while ( count >=3D 4 ) + { + __raw_writel(*(const uint32_t *)from, to); + from +=3D 4; + to +=3D 4; + count -=3D 4; + } + + while ( count ) + { + __raw_writeb(*(const uint8_t *)from, to); + from++; + to++; + count--; + } +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 8 + * tab-width: 8 + * indent-tabs-mode: t + * End: + */ --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Jan 14 18:29:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 18:29:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203677.1518779 (Exim 4.92) (envelope-from ) id 1vg5d0-0006wD-Ay; Wed, 14 Jan 2026 18:29:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203677.1518779; Wed, 14 Jan 2026 18: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 1vg5d0-0006w2-6c; Wed, 14 Jan 2026 18:29:58 +0000 Received: by outflank-mailman (input) for mailman id 1203677; Wed, 14 Jan 2026 18:29: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 1vg5cy-0005zq-RT for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 18:29:57 +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 046c77a8-f177-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 19:29:52 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by AS8PR03MB6997.eurprd03.prod.outlook.com (2603:10a6:20b:295::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Wed, 14 Jan 2026 18:29:50 +0000 Received: from PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc%5]) with mapi id 15.20.9520.005; Wed, 14 Jan 2026 18:29: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: 046c77a8-f177-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Fq/DkHsKbtYk05WCdwmqbi82IFNpfF+uMoTs/YLIaBAhYJ1HiwiWFXOQ/bxjXS4t4/qRf3BHuM7ytrOW4dO3BPDPiyezS/E4r7lv5UriyD9zmX1TsXipFzRbcGonpEvnW98FDiJfd5NbtTa3qEbPLPl07obQiRVzPoi63qmn1c1bjJ+RmAOzYfK2oD1HlVvDfVNoYdvsBReTFkeXz5ji7e1i2+fRh2ToSnSUagWAyHjl5o0hmggirDh4cM14cNU+EjVPqq8BXpJYks+RdLiQN0P37bm59ktDyIXpg1UIRaI8UjUtw7m/JCuQz3J4Z1tNRJOUrM1VaWHHfFWqMLVh7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+kBo1WmJzCSNAieCBdtQa4OARvGIpi4ImzEncbh9XY4=; b=cLqR5yUC1EdV8TQLrljTR7MhiRpZiC4Lp2IU3DzJSFbBDywu53OcGij05MU2KcX5btRJWk42w9oZLEw5xfjJL8+nNe0/GFI4EoBe6fYHAqCDfMG1hmK7QYscKwiooJeXdx0R0i7i5UtXVPhGF3FJvBsH2EPHPr9pXAPUtwgHNFiu2UV+KHgAOAdlBSBk/Hz82xuPMeEDiiqCmMEwB5ZrHTeqEYELQfvXlEVujhPKgcZZSYbL6fq9mIXLTa9HWbeD8aPWhwkK4WwX8KhvIC6U3Tzu+tfcWifgS8MdCFsiPzpI23ogB0S8oH18D8uPLGu5Lk6kq0B1qghV3hA5MSA0ew== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+kBo1WmJzCSNAieCBdtQa4OARvGIpi4ImzEncbh9XY4=; b=JRq0dak5KeDgzte96bprVHBHU4BwykK6xIA+4TrguXNgqyWaYhZbkIFKiO23IYzgTwYA2kCJnR7+/KkGn0upT1dvLYdMxGtc8HXeBP4Uz39Z0vy6aT89ncyM+b2mcUIEdCoxHZ4qBwEYKmL16JvX1WWz7TkrTkc2SiXq2AcoNslhMjSZsLAW2EHr6iTpF1Tv6tkuaz6KVoowmKUKg8/DHeieUU/L3c68UtXd+1GCZB9ZWv4hMg7x4YUd1g0pcAQ608dEqA2ssgn2Cf4EapzSNL++H8Qb7VIhA8bSZeW5pwbjghoZnbb/pRAj6Yvlf2OaO2jgMBs/fnPUr89p/LzNbQ== 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/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [PATCH v7 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHchYPEY703sAu32kaCSJHhjFUjhg== Date: Wed, 14 Jan 2026 18:29:49 +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_|AS8PR03MB6997:EE_ x-ms-office365-filtering-correlation-id: c0574745-f103-4990-4be8-08de539ae70b x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|366016|38070700021; x-microsoft-antispam-message-info: =?iso-8859-1?Q?yJtR+ANxi8F+01MAmIzYEBclGk/qV25K+Wpc6uLQWKPl/nE5Xs1MgJ1YHm?= =?iso-8859-1?Q?9Are/DxLb2l5VweTv2hBa00qXTMKVSLAVxBppZTWbIMKIaPEm41az7g2aS?= =?iso-8859-1?Q?8kAdzDXtP29nnAyWdhQb9M7z4TB6nWQM8DJv0xD7hqkcvHMYjv7wvOjd1W?= =?iso-8859-1?Q?Sxq8bB3Z4XOjPeSEGcR/Q9Tz7mwJvlUdvYKY7e+RtH+1YqIHX9mtmtfwcT?= =?iso-8859-1?Q?fyHnELOPBV81vDtM0I3Tj0zD2rfB27DVqAbSyJ+80hxiVR3XpxrMo/ZKBk?= =?iso-8859-1?Q?5xXW+V6RNbZHLwycgRrVBpQXlMYYViIDEsW/iKlF0NgV9LK8R8QHDXUeYf?= =?iso-8859-1?Q?MpSjW6Y8HRsfLqxRAiEhTf0kP794bG94wAtY1Q2jnm6F9dyZZRJ3C+kojz?= =?iso-8859-1?Q?XBsZqeFiYOaXPWaQmRMl58mkMcLU9gg7NsGpS+fsXQTCFnnowy32jo2PIx?= =?iso-8859-1?Q?ZDsPCD3kvme9WZd1AmNF2nltAnp8rt1DeyN9tAf7TOvt27/3qeZ+AyN/pq?= =?iso-8859-1?Q?hNnLZ6Z83A2edfFZR0SFhDsF+o6UQ361D9STOYA2JtuUhHFXmzoAb7CipN?= =?iso-8859-1?Q?AVcb06+boSd+efLkY6Bl9ekF5/ogyzMRKiF0PkOC2uRxWgXKs93ZUO1CVe?= =?iso-8859-1?Q?TlYU9gvm+/8wtdgsMizlNx/GI2255PAuldQyNI5ze89da8thoE1fWEGQTw?= =?iso-8859-1?Q?OQIoWI1Pi3fc2TIVqKe8m+uM+nrVsquvxNG/bBxEo40k/ayZX3wMdTnEqq?= =?iso-8859-1?Q?6CosZGvMWILuYFIksbrWmlLgzQQf0ftVpArrUKz5L3UvY7i3jtIB4Df5qe?= =?iso-8859-1?Q?kvXgSmSvZXL9PGP/o/8d5rbYAWgkS0r48JVvNlsXYeVDiM/MMT6K5YOX/+?= =?iso-8859-1?Q?IZm4XCDhKPz7yr8XdV35zwHKdzXhE+76EFFujLFMvP0Sdhj+qRmw9p5Ab+?= =?iso-8859-1?Q?lgNW+Y1slt/tIrhgtq4CmDYe2CdZfQ3Yv9ipvKv8ZNxwMoqTCkV/Lqvy+E?= =?iso-8859-1?Q?8Pw0HMt083f7zh/PN/5QxTx2spShC2HBhg+0Rx79974EZQnfSAUlbC7SDd?= =?iso-8859-1?Q?ab6TVkX0amvKPJS7X//efF912R3N/NdHXzP+b66DYQMeqWjCSw6eTgc0Qq?= =?iso-8859-1?Q?OD6tH4dL9epDcebt1VH99EekHkq3NeNXhxuAL43akkkXNbU1DuZJM7SS4K?= =?iso-8859-1?Q?b5Wwvds9ImshxQz7bicd5YRvh568WgGGQT5bKlEVqtShflKrDGLHh6bdNI?= =?iso-8859-1?Q?syf8ijrxrWvZSe70hOjGCfg2FRsQvJ3SQkXzg56MngcpHA3v/5ymUWD/k8?= =?iso-8859-1?Q?wmzgEN7/+9jBW+EmU/vcCZS6j0GSCd9qlSW1oVF2r9mvtASNvOtBAMKqQ9?= =?iso-8859-1?Q?2jioRIpY8OFT0Cl2+/PUzc/P9LEDpqNPLHnj0FO/6WNdhBbXZm7lLdrL48?= =?iso-8859-1?Q?RdxcRGz+YMzqzlAZ/i6ntl1KVW7dvNvs5zRMeMQai0O3SJD+FnBO4i8pZ6?= =?iso-8859-1?Q?nSjZFOFzD/u3R5ze2dQCahToZRcGh6VbUrafE6OWGvE0gQIpy7/4BSFDAY?= =?iso-8859-1?Q?A29tTKD7Yr8/S9A7iXrA6FJBBklmTwpmdLVv0WO1FXPYDDWC90Wm2ckBnn?= =?iso-8859-1?Q?Vt4EqAWaX5SQ1HsAPeCQ6yw82dzMm+rjkJbp9jcewsXMD7ePUG/o6FvRCp?= =?iso-8859-1?Q?SO22YhiI09h6ULo+L2I=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?jA3IugYSc8durIFIKRPxqH50FsrQ4ohErNr3X/eXjrKeHXDITHSHu7Q8D4?= =?iso-8859-1?Q?0JxGT+sN+cL0eXoB7wX2CS0xjLqdJz6wB6IX6mDaClOebVDknmQ9WfpDVA?= =?iso-8859-1?Q?tBMcr5lYWOtlpzCVBnRbDH7mWvJ1+i8Sw61YlonKWwlKcZyhJg9G50w3UC?= =?iso-8859-1?Q?bsbKen56KGU7GaKM0QT7Db8eBn3ZHlRgHDZFLMi0TMMxsUqwg5nxmngxd1?= =?iso-8859-1?Q?xo+OCvbHZT28X3SE89AT6UcgYlmVOd+DHYybh0W0ptr5VI7AMHFTylHMMF?= =?iso-8859-1?Q?tCcdsVvmP/DP0ya7pIcikxWCBQzubgASCPf3xN+raqIzgyHCTKTU4MQgXp?= =?iso-8859-1?Q?U1XixwHkj9CVGux0/QFfu7uKe8OTwKnM8LT9bgsLFdviScW0lZB5xH8lES?= =?iso-8859-1?Q?4SeW2iBoX4UcECCvHliF9gkyFjYDq6z+g8/k0s6QvaqnM+8eRbu+ThYV0a?= =?iso-8859-1?Q?+D7e+I/622FyBY4xDOjnnntHlh6FBt+drl4k70S7Pob6I1lCfS42AJiqS5?= =?iso-8859-1?Q?KgnPNuSGRPeaAkHGtpONFpfJp9WMmx9RCwy1zRxwQGhyJczwp6k96WV2ys?= =?iso-8859-1?Q?bIlrlG5wko27TgvxvDFcye3pAK6a922u7Sc/g4MZKQkoZJC6ECIZBDlXUB?= =?iso-8859-1?Q?h1+cColQ1C0AFyWoSgPfsPfwWje1YZQKS6FAZM8ZkJZLSxXS5sM3BjHRVm?= =?iso-8859-1?Q?E9174SHWOHA5YyEb+OYiXNwb9CxEnvGGG301iYuLAo1burX+oQJV1C2DZ/?= =?iso-8859-1?Q?1VrJMzYGlBkSR9epdeaS9SzKn3dQuO1C1vZw0Zuge8oP7/R4qTHUsZ+dND?= =?iso-8859-1?Q?tVkwddxwzxjVOmiZOwRGKxY6GKff55RzegrB1zJ0IZAQwf31+BdnwyBCTQ?= =?iso-8859-1?Q?uUtbKtYGmeau9kkbyuI0nSAFIapdNJVuyUbUW6fjamJaKvdX3CTkboAwP8?= =?iso-8859-1?Q?dQpkCbl+Krj/riCUIkQnbctR4fkF4PVrX7eI/Tq7YbHEv6x9bB8ggLhM+L?= =?iso-8859-1?Q?mvTaaS6o2jtbgoVWIj+CiMRwhDeA9kKHOuxg5cbsKlZir0x+W2TL7LoVMp?= =?iso-8859-1?Q?rqley4aqkcSF9Zt9D0rhi/1PRUFcnr2cYroVf3CfxF0EHRQYqbhIeRX5z/?= =?iso-8859-1?Q?JUxSDDa+8O8fZIZmcNCLdLvni/O9MwxOZsiUxzYpUA37n+o8m5FIk9M4vN?= =?iso-8859-1?Q?6xzeiQThbu7Hi0ZZcyfJtlN0A62q6zuB/w7wHw1ib5IFXMZX9VdCwYeJ/r?= =?iso-8859-1?Q?S1S/sdW6/czldF5mqmPIKFOhxUHyn8qMzJ6FWWAH6L4Pmh0zttkGKFeWqo?= =?iso-8859-1?Q?xIcdbSFiT/IIEw1lLj+THHP+5n97Y+CvOoj7Qpx6buR4foOfqn8J+sv8zb?= =?iso-8859-1?Q?jqHIk08PuAWHVlID9ttU0T49aFmTawR/WthcrRdw3haZxL5L5uDkyWTMnp?= =?iso-8859-1?Q?C2Z5B3Q6kqJFO6ou5A70MsVZBpQmy6he9NzHbGseY8GcdeFMh7HfUVjLsK?= =?iso-8859-1?Q?1fKZpuWa2fLwg1Esujk8aOcwd0gPToRpl3LsDgsa3CWrZCHSo67+9/ErSK?= =?iso-8859-1?Q?j1aAa/G/9b3cf0To7kJAe+MQq5Yo0r3Krd9pIQmkIwQS95XgLF7+upKJgp?= =?iso-8859-1?Q?XoR94EYuY/tPnrNSZh60ZYNLWJkQkBaIXuDWVaOMxZBDkIyk0aXffnKlVv?= =?iso-8859-1?Q?Cq9+darTiSo6Qdk8RdHj0P/cmX4PEacSIkuKgSTGWcuc7PS6tEZRgcak78?= =?iso-8859-1?Q?mMrFY/chGqWgIRq6DEUkvMg9761IIRC//UYxD7PAT2+Eatp2Fn/1EzpW4r?= =?iso-8859-1?Q?NUGWvEKkaCEzd3Di8oVAzECFYHRs+7U=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: c0574745-f103-4990-4be8-08de539ae70b X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2026 18:29:49.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: CxFKbQ3g3aScmm307B2Xt8fPHdXzQu3fWOKjHOxHvfCKYXd4t6Uzhqxamp6SZ7iEBFFnauOC5tyHft056moHnFWC16T/w1zyjOsoGuRH7V0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB6997 This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-A (TF-A) which provides SCMI interface with multi-agent support, as shown below. +-----------------------------------------+ | | | EL3 TF-A SCMI | +-------+--+-------+--+-------+--+-------++ |shmem1 | |shmem0 | |shmem2 | |shmemX | +-----+-+ +---+---+ +--+----+ +---+---+ smc-id1 | | | | agent1 | | | | +-----v--------+---------+-----------+----+ | | | | | | | | | | +--------------+---------+-----------+----+ smc-id0 | smc-id2| smc-idX| agent0 | agent2 | agentX | | | | +----v---+ +--v-----+ +--v-----+ | | | | | | | Dom0 | | Dom1 | | DomX | | | | | | | | | | | | | +--------+ +--------+ +--------+ The EL3 SCMI multi-agent firmware is expected to provide SCMI SMC shared memory transport for every Agent in the system. The SCMI Agent transport channel defined by pair: - smc-id: SMC id used for Doorbell - shmem: shared memory for messages transfer, Xen page aligned. Shared memort is mapped with the following flags: MT_DEVICE_nGnRE. The follwoing SCMI Agents are expected to be defined by SCMI FW to enable S= CMI multi-agent functionality under Xen: - Xen management agent: trusted agents that accesses to the Base Protocol commands to configure agent specific permissions - OSPM VM agents: non-trusted agent, one for each Guest domain which is allowed direct HW access. At least one OSPM VM agent has to be provided by FW if HW is handled only by Dom0 or Driver Domain. The EL3 SCMI FW is expected to implement following Base protocol messages: - BASE_DISCOVER_AGENT (optional if agent_id was provided) - BASE_RESET_AGENT_CONFIGURATION (optional) - BASE_SET_DEVICE_PERMISSIONS (optional) The SCI SCMI SMC multi-agent driver implements following functionality: - The driver is initialized from the Xen SCMI container ``xen_scmi_config`` (compatible ``xen,sci``) placed under ``/chosen/xen``. Only the ``arm,scmi-smc`` node that is a child of this container will bind to Xen; other SCMI nodes (for example under ``/firmware``) are ignored to avoid stealing the host OSPM instance. scmi_shm_1: sram@47ff1000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff1000 0x0 0x1000>; }; scmi_xen: scmi { compatible =3D "arm,scmi-smc"; arm,smc-id =3D <0x82000003>; <--- Xen management agent smc-id #address-cells =3D < 1>; #size-cells =3D < 0>; #access-controller-cells =3D < 1>; shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem }; - The driver obtains Xen specific SCMI Agent's configuration from the Host DT, probes Agents and builds SCMI Agents list. The Agents configuration is taken from "scmi-secondary-agents" property where first item is "arm,smc-id", second - "arm,scmi-shmem" phandle and third is optional "agent_id": / { chosen { xen { ranges; xen_scmi_config { compatible =3D "xen,sci"; #address-cells =3D <2>; #size-cells =3D <2>; ranges; scmi_shm_0: sram@47ff0000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff0000 0x0 0x1000>; }; /* Xen SCMI management channel */ scmi_shm_1: sram@47ff1000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff1000 0x0 0x1000>; }; scmi_shm_2: sram@47ff2000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff2000 0x0 0x1000>; }; scmi_shm_3: sram@47ff3000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff3000 0x0 0x1000>; }; scmi-secondary-agents =3D < 0x82000002 &scmi_shm_0 0 0x82000004 &scmi_shm_2 2 0x82000005 &scmi_shm_3 3>; <--- func_id, shmem, agent_id #scmi-secondary-agents-cells =3D <3>; scmi_xen: scmi { compatible =3D "arm,scmi-smc"; arm,smc-id =3D <0x82000002>; <--- Xen management agent func_id #address-cells =3D <1>; #size-cells =3D <0>; #access-controller-cells =3D <1>; shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem }; }; }; }; }; / { /* * Host SCMI OSPM channel - provided to the Dom0 as is if SCMI * enabled for it, ignored by Xen multi-agent mediator */ scmi_shm: sram@47ff0000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff0000 0x0 0x1000>; }; firmware { scmi: scmi { compatible =3D "arm,scmi-smc"; arm,smc-id =3D <0x82000002>; <--- Host OSPM agent smc-id #address-cells =3D < 1>; #size-cells =3D < 0>; shmem =3D <&scmi_shm>; <--- Host OSPM agent shmem protocol@X{ }; }; }; }; This approach allows defining multiple SCMI Agents by adding Xen-specific properties under the ``/chosen`` node to the Host Device Tree, leaving the main part unchanged. The Host DT SCMI channel will be passed to Dom0. The Xen management agent is described as a ``scmi_xen`` node under the ``xen,sci`` comaptible node, which is used by Xen to control other SCMI Agents in the system. All secondary agents' configurations are provided in the ``scmi-secondary-agents`` property with an optional ``agent_id`` field. The ``agent_id`` from the ``scmi-secondary-agents`` property is used to identify the agent in the system and can be omitted by setting ``#scmi-secondary-agents-cells =3D <2>``, so the Secondary Agents configuration will look like this: / { chosen { xen { xen_scmi_config { compatible =3D "xen,sci"; #address-cells =3D <2>; #size-cells =3D <2>; ranges; /* Shared memory nodes as defined earlier */ scmi-secondary-agents =3D < 0x82000003 &scmi_shm_0 0x82000004 &scmi_shm_2 0x82000005 &scmi_shm_3 0x82000006 &scmi_shm_4>; #scmi-secondary-agents-cells =3D <2>; }; }; }; } In this case, Xen will use the ``SCMI_BASE_DISCOVER_AGENT`` call to discover the ``agent_id`` for each secondary agent. Providing the ``agent_id`` in the ``scmi-secondary-agents`` property allows skipping the discovery call, which is useful when the secondary agent's shared memory is not accessible by Xen or when boot time is important because it allows skipping the agent discovery procedure. Note that Xen is the only one entry in the system which need to know about SCMI multi-agent support. - It implements the SCI subsystem interface required for configuring and enabling SCMI functionality for Dom0/hwdom and Guest domains. To enable SCMI functionality for domain it has to be configured with unique supported SCMI Agent_id and use corresponding SCMI SMC shared memory transport [smc-id, shmem] defined for this SCMI Agent_id. - Once Xen domain is configured it can communicate with EL3 SCMI FW: -- zero-copy, the guest domain puts SCMI message in shmem; -- the guest triggers SMC exception with smc-id (doorbell); -- the Xen driver catches exception, do checks and synchronously forwards it to EL3 FW. - the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen management agent channel on domain destroy event. This allows to reset resources used by domain and so implement use-case like domain reboot. Dom0 Enable SCMI SMC: - pass dom0_scmi_agent_id=3D in Xen command line. if not provide= d SCMI will be disabled for Dom0 and all SCMI nodes removed from Dom0 DT. The driver updates Dom0 DT SCMI node "arm,smc-id" value and fix up shmem node according to assigned agent_id. Guest domains enable SCMI SMC: - xl.cfg: add configuration option as below arm_sci =3D "type=3Dscmi_smc_multiagent,agent_id=3D2" - xl.cfg: enable access to the "arm,scmi-shmem" which should correspond assigned agent_id for the domain, for example: iomem =3D [ "47ff2,1@22001", ] - DT: add SCMI nodes to the Driver domain partial device tree as in the below example. The "arm,smc-id" should correspond assigned agent_id for the domain: passthrough { scmi_shm_0: sram@22001000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x22001000 0x0 0x1000>; }; firmware { compatible =3D "simple-bus"; scmi: scmi { compatible =3D "arm,scmi-smc"; arm,smc-id =3D <0x82000004>; shmem =3D <&scmi_shm_0>; ... } } } SCMI "4.2.1.1 Device specific access control" The XEN SCI SCMI SMC multi-agent driver performs "access-controller" provider function in case EL3 SCMI FW implements SCMI "4.2.1.1 Device specific access control" and provides the BASE_SET_DEVICE_PERMISSIONS command to configure the devices that an agents have access to. The DT SCMI node should "#access-controller-cells=3D<1>" property and DT devices should be bound to the Xen SCMI. &i2c1 { access-controllers =3D <&scmi 0>; }; The Dom0 and dom0less domains DT devices will be processed automatically through sci_assign_dt_device() call, but to assign SCMI devices from toolstack the xl.cfg:"dtdev" property shall be used: dtdev =3D [ "/soc/i2c@e6508000", ] xl.cfg:dtdev will contain all nodes which are under SCMI management (not only those which are behind IOMMU). [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/= tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml [2] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/= tree/Documentation/devicetree/bindings/access-controllers/access-controller= s.yaml Signed-off-by: Grygorii Strashko Signed-off-by: Oleksii Moisieiev --- Changes in v7: - rework scmi nodes for xen to match on compatible string instead of the direct path Changes in v6: - updated scmi-shmem to use io.h from generic location - update scmi_agent_id parameter to be provided inside dom0=3D parameter list and have the following format "dom0=3Dsci-agent-id=3D0" This change was done as a response for Stefano comment and requires a lot of code changes, but produces much cleaner solution that's why I've added it to the code. - fix file comments and return codes - fix lenght checks in shmem_{get,put}_message to use offsetof - remove len member from scmi_channel structure as it is not used - set scmi-secondary-agents property to be mandatory since if no secondary agents were provided then there is no sence to enable scmi when no secondary agents are populated to the Domains - update documentation in booting.txt, added xen_scmi node to the example - adjust d->arch.sci_enabled value in scmi_domain_destroy - fix lock management in smc_create_channel call - avoid extra map_channel_memory command for Xen management channel because collect_agent_id call unmaps memory if DOMID_XEN is not set. So for Xen management channel we can init domain_id ad DOMID_XEN before calling collect_agent_id so memory shouldn't be unmapped. Changes in v5: - fix device-tree example format in booting.txt, added ";" after "}". - update define in scmi-proto.h - update define in scmi-shmem.h file - scmi_assign_device - do not ignore -EOPNOTSUPP return code of the do_smc_xfer - remove overwriting agent_channel->agent_id after SCMI_BASE_DISCOVER_AGENT call - add multi-agent files to the MAINTAINERS - add SCMI multi-agent description to the SUPPORT.md - handle ARM_SMCCC_INVALID_PARAMETER return code and return -EINVAL for smc call - updated collect_agents function. Set agent_id parameter as optional in scmi-secondary-agents device-tree property - introduce "#scmi-secondary-agents-cells" parameter to set if agent_id was provided - reanme xen,scmi-secondary-agents property to scmi-secondary-agents - move memcpu_toio/fromio for the generic place - update Xen to get management channel from /chosen/xen,config node - get hypervisor channnel from node instead of using hardcoded - update handling scmi and shmem nodes for the domain - Set multi-agent driver to support only Arm64 Changes in v4: - toolstack comments from Anthony PERARD - added dom0less support - added doc for "xen,scmi-secondary-agents" MAINTAINERS | 4 + SUPPORT.md | 11 + docs/man/xl.cfg.5.pod.in | 13 + docs/misc/arm/device-tree/booting.txt | 103 +++ docs/misc/xen-command-line.pandoc | 19 +- tools/libs/light/libxl_arm.c | 4 + tools/libs/light/libxl_types.idl | 4 +- tools/xl/xl_parse.c | 12 + xen/arch/arm/dom0less-build.c | 11 + xen/arch/arm/domain_build.c | 26 +- xen/arch/arm/firmware/Kconfig | 12 + xen/arch/arm/firmware/Makefile | 1 + xen/arch/arm/firmware/scmi-proto.h | 164 ++++ xen/arch/arm/firmware/scmi-shmem.c | 115 +++ xen/arch/arm/firmware/scmi-shmem.h | 45 ++ xen/arch/arm/firmware/scmi-smc-multiagent.c | 815 ++++++++++++++++++++ xen/include/public/arch-arm.h | 3 + 17 files changed, 1359 insertions(+), 3 deletions(-) create mode 100644 xen/arch/arm/firmware/scmi-proto.h create mode 100644 xen/arch/arm/firmware/scmi-shmem.c create mode 100644 xen/arch/arm/firmware/scmi-shmem.h create mode 100644 xen/arch/arm/firmware/scmi-smc-multiagent.c diff --git a/MAINTAINERS b/MAINTAINERS index ecd3f40df8..4ad1d818a6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -532,6 +532,10 @@ R: Oleksii Moisieiev S: Supported F: xen/arch/arm/firmware/sci.c F: xen/arch/arm/include/asm/firmware/sci.h +F: xen/arch/arm/firmware/scmi-smc-multiagent.c +F: xen/arch/arm/firmware/scmi-shmem.c +F: xen/arch/arm/firmware/scmi-shmem.h +F: xen/arch/arm/firmware/scmi-proto.h =20 SEABIOS UPSTREAM M: Wei Liu diff --git a/SUPPORT.md b/SUPPORT.md index 491f9ecd1b..7c8951d67b 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -956,6 +956,17 @@ by hwdom. Some platforms use SCMI for access to system= -level resources. =20 Status: Supported =20 +### Arm: SCMI SMC multi-agent support + +Enable support for the multi-agent configuration of the EL3 Firmware, whic= h +allows Xen to provide an SCMI interface to the Domains. +Xen manages access permissions to the HW resources and provides an SCMI in= terface +to the Domains. Each Domain is represented as a separate Agent, which can +communicate with EL3 Firmware using a dedicated shared memory region, and +notifications are passed through by Xen. + + Status, ARM64: Tech Preview + ### ARM: Guest PSCI support =20 Emulated PSCI interface exposed to guests. We support all mandatory diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in index ad1553c5e9..4fc3e12939 100644 --- a/docs/man/xl.cfg.5.pod.in +++ b/docs/man/xl.cfg.5.pod.in @@ -3156,8 +3156,21 @@ single SCMI OSPM agent support. Should be used together with B Xen command line option. =20 +=3Ditem B + +Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI ov= er +SMC calls forwarding from domain to the EL3 firmware (like Trusted Firmwar= e-A) +with a multi SCMI OSPM agent support. The SCMI B should be +specified for the guest. + =3Dback =20 +=3Ditem B + +Specifies a non-zero ARM SCI agent id for the guest. This option is mandat= ory +if the SCMI SMC support is enabled for the guest. The agent ids of domains +existing on a single host must be unique and in the range [1..255]. + =3Dback =20 =3Dback diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-t= ree/booting.txt index 977b428608..6fd7e4a16b 100644 --- a/docs/misc/arm/device-tree/booting.txt +++ b/docs/misc/arm/device-tree/booting.txt @@ -322,6 +322,20 @@ with the following properties: Should be used together with scmi-smc-passthrough Xen command line option. =20 + - "scmi_smc_multiagent" + + Enables ARM SCMI SMC multi-agent support for the guest by enabling SCM= I over + SMC calls forwarding from domain to the EL3 firmware (like ARM + Trusted Firmware-A) with a multi SCMI OSPM agent support. + The SCMI agent_id should be specified for the guest with "xen,sci-agen= t-id" + property. + +- "xen,sci-agent-id" + + Specifies ARM SCMI agent id for the guest. This option is mandatory if= the + SCMI SMC "scmi_smc_multiagent" support is enabled for the guest. The a= gent ids + of guest must be unique and in the range [0..255]. + Under the "xen,domain" compatible node, one or more sub-nodes are present for the DomU kernel and ramdisk. =20 @@ -824,3 +838,92 @@ The automatically allocated static shared memory will = get mapped at 0x80000000 in DomU1 guest physical address space, and at 0x90000000 in Dom= U2 guest physical address space. DomU1 is explicitly defined as the owner dom= ain, and DomU2 is the borrower domain. + +SCMI SMC multi-agent support +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D + +For enabling the ARM SCMI SMC multi-agent support (enabled by CONFIG_SCMI_= SMC_MA) +the Xen specific SCMI Agent's configuration shall be provided in the Host = DT +according to the SCMI compliant EL3 Firmware specification with +ARM SMC/HVC transport using property "scmi-secondary-agents" placed in "xe= n,config" +node under "chosen" node: + +- scmi-secondary-agents + + Defines a set of SCMI agents configuration supported by SCMI EL3 FW an= d + available for Xen. Each Agent defined as triple consisting of: + SMC/HVC function_id assigned for the agent transport ("arm,smc-id"), + phandle to SCMI SHM assigned for the agent transport ("arm,scmi-shmem"= ), + SCMI agent_id (optional) if not set - Xen will determine Agent ID for + each provided channel using BASE_DISCOVER_AGENT message. + +As an example: + +/{ +chosen { + xen,config { + scmi_shm_0 : sram@47ff0000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff0000 0x0 0x1000>; + }; + // Xen SCMI management channel + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + scmi_shm_2: sram@47ff2000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff2000 0x0 0x1000>; + }; + scmi_shm_3: sram@47ff3000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff3000 0x0 0x1000>; + }; + scmi_shm_3: sram@47ff4000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff4000 0x0 0x1000>; + }; + scmi-secondary-agents =3D < + 0x82000002 &scmi_shm_0 0 + 0x82000004 &scmi_shm_2 2 + 0x82000005 &scmi_shm_3 3 + 0x82000006 &scmi_shm_4 4>; + #scmi-secondary-agents-cells =3D <3>; + }; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000002>; <--- Xen management agent smc-id + #address-cells =3D < 1>; + #size-cells =3D < 0>; + #access-controller-cells =3D < 1>; + shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem + }; + + }; +}; + +- #scmi-secondary-agents-cells + + Defines whether Agent_id is set in the "scmi-secondary-agents" propert= y. + Possible values are: 2, 3. + When set to 3 (the default), expect agent_id to be present in the seco= ndary + agents list. + When set to 2, agent_id will be discovered for each channel using + BASE_DISCOVER_AGENT message. + + +Example: + +/{ +chosen { + xen,config { + scmi-secondary-agents =3D < + 0x82000003 &scmi_shm_1 + 0x82000004 &scmi_shm_2 + 0x82000005 &scmi_shm_3 + 0x82000006 &scmi_shm_4>; + #scmi-secondary-agents-cells =3D <2>; + }; + }; +}; diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line= .pandoc index 34004ce282..5541c4a4ed 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -835,7 +835,7 @@ Specify the bit width of the DMA heap. cpuid-faulting=3D, msr-relaxed=3D, pf-fixup=3D ] (x86) =20 - =3D List of [ sve=3D ] (Arm64) + =3D List of [ sve=3D, sci-agent-id=3D ] (Arm) =20 Controls for how dom0 is constructed on x86 systems. =20 @@ -923,6 +923,14 @@ Enables features on dom0 on Arm systems. option is provided with a positive non zero value, but the platform do= esn't support SVE. =20 +* The `sci-agent-id` integer parameter enables ARM SCMI (System Control = and + Management Interface) functionality for Dom0 when `CONFIG_SCMI_SMC_MA`= is + compiled in. This parameter specifies the SCMI agent ID for Dom0. + A value equal to 0xFF (or omitted) disables SCMI for Dom0, which is us= eful + for thin Dom0 or dom0less use-cases. Values from 0 to 254 specify the = SCMI + agent ID. The agent IDs of domains existing on a single host must be u= nique. + Example: `dom0=3Dsci-agent-id=3D0` to enable SCMI with agent ID 0 for = Dom0. + ### dom0-cpuid =3D List of comma separated booleans =20 @@ -1107,6 +1115,15 @@ affinities to prefer but be not limited to the speci= fied node(s). =20 Pin dom0 vcpus to their respective pcpus =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). + ### dtuart (ARM) > `=3D path [:options]` =20 diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c index e4407d6e3f..be0e6263ae 100644 --- a/tools/libs/light/libxl_arm.c +++ b/tools/libs/light/libxl_arm.c @@ -240,6 +240,10 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc, case LIBXL_ARM_SCI_TYPE_SCMI_SMC: config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; break; + case LIBXL_ARM_SCI_TYPE_SCMI_SMC_MULTIAGENT: + config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_M= A; + config->arch.arm_sci_agent_id =3D d_config->b_info.arch_arm.arm_sc= i.agent_id; + break; default: LOG(ERROR, "Unknown ARM_SCI type %d", d_config->b_info.arch_arm.arm_sci.type); diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_type= s.idl index 4a958f69f4..9bfbf09145 100644 --- a/tools/libs/light/libxl_types.idl +++ b/tools/libs/light/libxl_types.idl @@ -554,11 +554,13 @@ libxl_sve_type =3D Enumeration("sve_type", [ =20 libxl_arm_sci_type =3D Enumeration("arm_sci_type", [ (0, "none"), - (1, "scmi_smc") + (1, "scmi_smc"), + (2, "scmi_smc_multiagent") ], init_val =3D "LIBXL_ARM_SCI_TYPE_NONE") =20 libxl_arm_sci =3D Struct("arm_sci", [ ("type", libxl_arm_sci_type), + ("agent_id", uint8) ]) =20 libxl_rdm_reserve =3D Struct("rdm_reserve", [ diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c index 1cc41f1bff..0c389d25f9 100644 --- a/tools/xl/xl_parse.c +++ b/tools/xl/xl_parse.c @@ -1306,6 +1306,18 @@ static int parse_arm_sci_config(XLU_Config *cfg, lib= xl_arm_sci *arm_sci, } } =20 + if (MATCH_OPTION("agent_id", ptr, oparg)) { + unsigned long val =3D parse_ulong(oparg); + + if (!val || val > 255) { + fprintf(stderr, "An invalid ARM_SCI agent_id specified (%l= u). Valid range [1..255]\n", + val); + ret =3D ERROR_INVAL; + goto out; + } + arm_sci->agent_id =3D val; + } + ptr =3D strtok(NULL, ","); } =20 diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index 4181c10538..ddadc89148 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -299,6 +299,17 @@ static int __init domu_dt_sci_parse(struct dt_device_n= ode *node, d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE; else if ( !strcmp(sci_type, "scmi_smc") ) d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; + else if ( !strcmp(sci_type, "scmi_smc_multiagent") ) + { + uint32_t agent_id =3D 0; + + if ( !dt_property_read_u32(node, "xen,sci-agent-id", &agent_id) || + agent_id > UINT8_MAX ) + return -EINVAL; + + d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA= ; + d_cfg->arch.arm_sci_agent_id =3D agent_id; + } else { printk(XENLOG_ERR "xen,sci_type in not valid (%s) for domain %s\n"= , diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index fb8fbb1650..794ea1aa42 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -55,6 +55,10 @@ boolean_param("ext_regions", opt_ext_regions); static u64 __initdata dom0_mem; static bool __initdata dom0_mem_set; =20 +/* SCMI agent ID for dom0, parsed from dom0=3Dsci-agent-id=3D */ +#define SCMI_AGENT_ID_INVALID 0xFF +static uint8_t __initdata opt_dom0_scmi_agent_id =3D SCMI_AGENT_ID_INVALID= ; + static int __init parse_dom0_mem(const char *s) { dom0_mem_set =3D true; @@ -83,6 +87,16 @@ int __init parse_arch_dom0_param(const char *s, const ch= ar *e) #endif } =20 + if ( !parse_signed_integer("sci-agent-id", s, e, &val) ) + { + if ( (val >=3D 0) && (val <=3D UINT8_MAX) ) + opt_dom0_scmi_agent_id =3D val; + else + printk(XENLOG_INFO "'sci-agent-id=3D%lld' value out of range!\= n", val); + + return 0; + } + return -EINVAL; } =20 @@ -509,7 +523,8 @@ static int __init write_properties(struct domain *d, st= ruct kernel_info *kinfo, dt_property_name_is_equal(prop, "linux,uefi-mmap-start") = || dt_property_name_is_equal(prop, "linux,uefi-mmap-size") |= | dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-siz= e") || - dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-ver= ")) + dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-ver= ") || + dt_property_name_is_equal(prop, "xen,config") ) continue; =20 if ( dt_property_name_is_equal(prop, "xen,dom0-bootargs") ) @@ -2067,6 +2082,15 @@ void __init create_dom0(void) dom0_cfg.arch.tee_type =3D tee_get_type(); dom0_cfg.max_vcpus =3D dom0_max_vcpus(); =20 + /* Set up SCMI agent ID if specified in dom0=3D command line */ + if ( opt_dom0_scmi_agent_id !=3D SCMI_AGENT_ID_INVALID ) + { + dom0_cfg.arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_= MA; + dom0_cfg.arch.arm_sci_agent_id =3D opt_dom0_scmi_agent_id; + } + else + dom0_cfg.arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE; + if ( iommu_enabled ) dom0_cfg.flags |=3D XEN_DOMCTL_CDF_iommu; =20 diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig index 5c5f0880c4..972cd9b173 100644 --- a/xen/arch/arm/firmware/Kconfig +++ b/xen/arch/arm/firmware/Kconfig @@ -29,6 +29,18 @@ config SCMI_SMC driver domain. Use with EL3 firmware which supports only single SCMI OSPM agent. =20 +config SCMI_SMC_MA + bool "Enable ARM SCMI SMC multi-agent driver" + depends on ARM_64 + select ARM_SCI + help + Enables SCMI SMC/HVC multi-agent in XEN to pass SCMI requests from Doma= ins + to EL3 firmware (TF-A) which supports multi-agent feature. + This feature allows to enable SCMI per Domain using unique SCMI agent_i= d, + so Domain is identified by EL3 firmware as an SCMI Agent and can access + allowed platform resources through dedicated SMC/HVC Shared memory base= d + transport. + endchoice =20 endmenu diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefil= e index 71bdefc24a..37927e690e 100644 --- a/xen/arch/arm/firmware/Makefile +++ b/xen/arch/arm/firmware/Makefile @@ -1,2 +1,3 @@ obj-$(CONFIG_ARM_SCI) +=3D sci.o obj-$(CONFIG_SCMI_SMC) +=3D scmi-smc.o +obj-$(CONFIG_SCMI_SMC_MA) +=3D scmi-shmem.o scmi-smc-multiagent.o diff --git a/xen/arch/arm/firmware/scmi-proto.h b/xen/arch/arm/firmware/scm= i-proto.h new file mode 100644 index 0000000000..49f63cfc0a --- /dev/null +++ b/xen/arch/arm/firmware/scmi-proto.h @@ -0,0 +1,164 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Arm System Control and Management Interface definitions + * Version 3.0 (DEN0056C) + * + * Copyright (c) 2025 EPAM Systems + */ + +#ifndef ARM_FIRMWARE_SCMI_PROTO_H_ +#define ARM_FIRMWARE_SCMI_PROTO_H_ + +#include + +#define SCMI_SHORT_NAME_MAX_SIZE 16 + +/* SCMI status codes. See section 4.1.4 */ +#define SCMI_SUCCESS 0 +#define SCMI_NOT_SUPPORTED (-1) +#define SCMI_INVALID_PARAMETERS (-2) +#define SCMI_DENIED (-3) +#define SCMI_NOT_FOUND (-4) +#define SCMI_OUT_OF_RANGE (-5) +#define SCMI_BUSY (-6) +#define SCMI_COMMS_ERROR (-7) +#define SCMI_GENERIC_ERROR (-8) +#define SCMI_HARDWARE_ERROR (-9) +#define SCMI_PROTOCOL_ERROR (-10) + +/* Protocol IDs */ +#define SCMI_BASE_PROTOCOL 0x10 + +/* Base protocol message IDs */ +#define SCMI_BASE_PROTOCOL_VERSION 0x0 +#define SCMI_BASE_PROTOCOL_ATTIBUTES 0x1 +#define SCMI_BASE_PROTOCOL_MESSAGE_ATTRIBUTES 0x2 +#define SCMI_BASE_DISCOVER_AGENT 0x7 +#define SCMI_BASE_SET_DEVICE_PERMISSIONS 0x9 +#define SCMI_BASE_RESET_AGENT_CONFIGURATION 0xB + +typedef struct scmi_msg_header { + uint8_t id; + uint8_t type; + uint8_t protocol; + uint32_t status; +} scmi_msg_header_t; + +/* Table 2 Message header format */ +#define SCMI_HDR_ID GENMASK(7, 0) +#define SCMI_HDR_TYPE GENMASK(9, 8) +#define SCMI_HDR_PROTO GENMASK(17, 10) + +#define SCMI_FIELD_GET(_mask, _reg) = \ + ((typeof(_mask))(((_reg) & (_mask)) >> (ffs64(_mask) - 1))) +#define SCMI_FIELD_PREP(_mask, _val) = \ + (((typeof(_mask))(_val) << (ffs64(_mask) - 1)) & (_mask)) + +static inline uint32_t pack_scmi_header(scmi_msg_header_t *hdr) +{ + return SCMI_FIELD_PREP(SCMI_HDR_ID, hdr->id) | + SCMI_FIELD_PREP(SCMI_HDR_TYPE, hdr->type) | + SCMI_FIELD_PREP(SCMI_HDR_PROTO, hdr->protocol); +} + +static inline void unpack_scmi_header(uint32_t msg_hdr, scmi_msg_header_t = *hdr) +{ + hdr->id =3D SCMI_FIELD_GET(SCMI_HDR_ID, msg_hdr); + hdr->type =3D SCMI_FIELD_GET(SCMI_HDR_TYPE, msg_hdr); + hdr->protocol =3D SCMI_FIELD_GET(SCMI_HDR_PROTO, msg_hdr); +} + +static inline int scmi_to_xen_errno(int scmi_status) +{ + if ( scmi_status =3D=3D SCMI_SUCCESS ) + return 0; + + switch ( scmi_status ) + { + case SCMI_NOT_SUPPORTED: + return -EOPNOTSUPP; + case SCMI_INVALID_PARAMETERS: + return -EINVAL; + case SCMI_DENIED: + return -EACCES; + case SCMI_NOT_FOUND: + return -ENOENT; + case SCMI_OUT_OF_RANGE: + return -ERANGE; + case SCMI_BUSY: + return -EBUSY; + case SCMI_COMMS_ERROR: + return -ENOTCONN; + case SCMI_GENERIC_ERROR: + return -EIO; + case SCMI_HARDWARE_ERROR: + return -ENXIO; + case SCMI_PROTOCOL_ERROR: + return -EBADMSG; + default: + return -EINVAL; + } +} + +/* PROTOCOL_VERSION */ +#define SCMI_VERSION_MINOR GENMASK(15, 0) +#define SCMI_VERSION_MAJOR GENMASK(31, 16) + +struct scmi_msg_prot_version_p2a { + uint32_t version; +} __packed; + +/* BASE PROTOCOL_ATTRIBUTES */ +#define SCMI_BASE_ATTR_NUM_PROTO GENMASK(7, 0) +#define SCMI_BASE_ATTR_NUM_AGENT GENMASK(15, 8) + +struct scmi_msg_base_attributes_p2a { + uint32_t attributes; +} __packed; + +/* + * BASE_DISCOVER_AGENT + */ +#define SCMI_BASE_AGENT_ID_OWN 0xFFFFFFFF + +struct scmi_msg_base_discover_agent_a2p { + uint32_t agent_id; +} __packed; + +struct scmi_msg_base_discover_agent_p2a { + uint32_t agent_id; + char name[SCMI_SHORT_NAME_MAX_SIZE]; +} __packed; + +/* + * BASE_SET_DEVICE_PERMISSIONS + */ +#define SCMI_BASE_DEVICE_ACCESS_ALLOW BIT(0, UL) + +struct scmi_msg_base_set_device_permissions_a2p { + uint32_t agent_id; + uint32_t device_id; + uint32_t flags; +} __packed; + +/* + * BASE_RESET_AGENT_CONFIGURATION + */ +#define SCMI_BASE_AGENT_PERMISSIONS_RESET BIT(0, UL) + +struct scmi_msg_base_reset_agent_cfg_a2p { + uint32_t agent_id; + uint32_t flags; +} __packed; + +#endif /* ARM_FIRMWARE_SCMI_PROTO_H_ */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/firmware/scmi-shmem.c b/xen/arch/arm/firmware/scm= i-shmem.c new file mode 100644 index 0000000000..112507ba2a --- /dev/null +++ b/xen/arch/arm/firmware/scmi-shmem.c @@ -0,0 +1,115 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * SMC/HVC shmem transport implementation used by + * SCI SCMI multi-agent driver. + * + * Oleksii Moisieiev + * Copyright (c) 2025 EPAM Systems + */ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include +#include +#include + +#include "scmi-proto.h" +#include "scmi-shmem.h" + +static inline int +shmem_channel_is_free(const volatile struct scmi_shared_mem __iomem *shmem= ) +{ + return (readl(&shmem->channel_status) & + SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE) ? 0 : -EBUSY; +} + +int shmem_put_message(volatile struct scmi_shared_mem __iomem *shmem, + scmi_msg_header_t *hdr, void *data, int len) +{ + int ret; + + if ( (len + offsetof(struct scmi_shared_mem, msg_payload)) > + SCMI_SHMEM_MAPPED_SIZE ) + { + printk(XENLOG_ERR "scmi: Wrong size of smc message. Data is invali= d\n"); + return -EINVAL; + } + + ret =3D shmem_channel_is_free(shmem); + if ( ret ) + return ret; + + writel_relaxed(0x0, &shmem->channel_status); + /* Writing 0x0 right now, but "shmem"_FLAG_INTR_ENABLED can be set */ + writel_relaxed(0x0, &shmem->flags); + writel_relaxed(sizeof(shmem->msg_header) + len, &shmem->length); + writel(pack_scmi_header(hdr), &shmem->msg_header); + + if ( len > 0 && data ) + memcpy_toio(shmem->msg_payload, data, len); + + return 0; +} + +int shmem_get_response(const volatile struct scmi_shared_mem __iomem *shme= m, + scmi_msg_header_t *hdr, void *data, int len) +{ + int recv_len; + int ret; + int pad =3D sizeof(hdr->status); + + if ( len >=3D SCMI_SHMEM_MAPPED_SIZE - + offsetof(struct scmi_shared_mem, msg_payload) ) + { + printk(XENLOG_ERR + "scmi: Wrong size of input smc message. Data may be invalid= \n"); + return -EINVAL; + } + + ret =3D shmem_channel_is_free(shmem); + if ( ret ) + return ret; + + recv_len =3D readl(&shmem->length) - sizeof(shmem->msg_header); + + if ( recv_len < 0 ) + { + printk(XENLOG_ERR + "scmi: Wrong size of smc message. Data may be invalid\n"); + return -EINVAL; + } + + unpack_scmi_header(readl(&shmem->msg_header), hdr); + + hdr->status =3D readl(&shmem->msg_payload); + recv_len =3D recv_len > pad ? recv_len - pad : 0; + + ret =3D scmi_to_xen_errno(hdr->status); + if ( ret ) + { + printk(XENLOG_DEBUG "scmi: Error received: %d\n", ret); + return ret; + } + + if ( recv_len > len ) + { + printk(XENLOG_ERR + "scmi: Not enough buffer for message %d, expecting %d\n", + recv_len, len); + return -EINVAL; + } + + if ( recv_len > 0 ) + memcpy_fromio(data, shmem->msg_payload + pad, recv_len); + + return 0; +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/firmware/scmi-shmem.h b/xen/arch/arm/firmware/scm= i-shmem.h new file mode 100644 index 0000000000..7313cb6b26 --- /dev/null +++ b/xen/arch/arm/firmware/scmi-shmem.h @@ -0,0 +1,45 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Arm System Control and Management Interface definitions + * Version 3.0 (DEN0056C) + * Shared Memory based Transport + * + * Copyright (c) 2024 EPAM Systems + */ + +#ifndef ARM_FIRMWARE_SCMI_SHMEM_H_ +#define ARM_FIRMWARE_SCMI_SHMEM_H_ + +#include + +#define SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE BIT(0, UL) +#define SCMI_SHMEM_CHAN_STAT_CHANNEL_ERROR BIT(1, UL) + +struct scmi_shared_mem { + uint32_t reserved; + uint32_t channel_status; + uint32_t reserved1[2]; + uint32_t flags; + uint32_t length; + uint32_t msg_header; + uint8_t msg_payload[]; +}; + +#define SCMI_SHMEM_MAPPED_SIZE PAGE_SIZE + +int shmem_put_message(volatile struct scmi_shared_mem __iomem *shmem, + scmi_msg_header_t *hdr, void *data, int len); + +int shmem_get_response(const volatile struct scmi_shared_mem __iomem *shme= m, + scmi_msg_header_t *hdr, void *data, int len); +#endif /* ARM_FIRMWARE_SCMI_SHMEM_H_ */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/firmware/scmi-smc-multiagent.c b/xen/arch/arm/fir= mware/scmi-smc-multiagent.c new file mode 100644 index 0000000000..b79041daba --- /dev/null +++ b/xen/arch/arm/firmware/scmi-smc-multiagent.c @@ -0,0 +1,815 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * SCI SCMI multi-agent driver, using SMC/HVC shmem as transport. + * + * Oleksii Moisieiev + * Copyright (c) 2025 EPAM Systems + */ + +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include "scmi-proto.h" +#include "scmi-shmem.h" + +#define SCMI_AGENT_ID_INVALID 0xFF + +#define SCMI_SECONDARY_AGENTS "scmi-secondary-agents" + +struct scmi_channel { + uint32_t agent_id; + uint32_t func_id; + domid_t domain_id; + uint64_t paddr; + struct scmi_shared_mem __iomem *shmem; + spinlock_t lock; + struct list_head list; +}; + +struct scmi_data { + struct list_head channel_list; + spinlock_t channel_list_lock; + uint32_t func_id; + bool initialized; + uint32_t shmem_phandle; + uint32_t hyp_channel_agent_id; + struct dt_device_node *dt_dev; +}; + +static struct scmi_data scmi_data; + +static bool scmi_is_under_xen_sci(const struct dt_device_node *node) +{ + const struct dt_device_node *p; + + for ( p =3D node->parent; p; p =3D p->parent ) + if ( dt_device_is_compatible(p, "xen,sci") ) + return true; + + return false; +} + +static int send_smc_message(struct scmi_channel *chan_info, + scmi_msg_header_t *hdr, void *data, int len) +{ + struct arm_smccc_res resp; + int ret; + + ret =3D shmem_put_message(chan_info->shmem, hdr, data, len); + if ( ret ) + return ret; + + arm_smccc_1_1_smc(chan_info->func_id, 0, 0, 0, 0, 0, 0, 0, &resp); + + if ( resp.a0 =3D=3D ARM_SMCCC_INVALID_PARAMETER ) + return -EINVAL; + + if ( resp.a0 ) + return -EOPNOTSUPP; + + return 0; +} + +static int do_smc_xfer(struct scmi_channel *chan_info, scmi_msg_header_t *= hdr, + void *tx_data, int tx_size, void *rx_data, int rx_s= ize) +{ + int ret =3D 0; + + ASSERT(chan_info && chan_info->shmem); + + if ( !hdr ) + return -EINVAL; + + spin_lock(&chan_info->lock); + + printk(XENLOG_DEBUG + "scmi: agent_id =3D %d msg_id =3D %x type =3D %d, proto =3D %x\= n", + chan_info->agent_id, hdr->id, hdr->type, hdr->protocol); + + ret =3D send_smc_message(chan_info, hdr, tx_data, tx_size); + if ( ret ) + goto clean; + + ret =3D shmem_get_response(chan_info->shmem, hdr, rx_data, rx_size); + +clean: + printk(XENLOG_DEBUG + "scmi: get smc response agent_id =3D %d msg_id =3D %x proto =3D= %x res=3D%d\n", + chan_info->agent_id, hdr->id, hdr->protocol, ret); + + spin_unlock(&chan_info->lock); + + return ret; +} + +static struct scmi_channel *get_channel_by_id(uint32_t agent_id) +{ + struct scmi_channel *curr; + bool found =3D false; + + spin_lock(&scmi_data.channel_list_lock); + list_for_each_entry(curr, &scmi_data.channel_list, list) + { + if ( curr->agent_id =3D=3D agent_id ) + { + found =3D true; + break; + } + } + + spin_unlock(&scmi_data.channel_list_lock); + if ( found ) + return curr; + + return NULL; +} + +static struct scmi_channel *acquire_scmi_channel(struct domain *d, + uint32_t agent_id) +{ + struct scmi_channel *curr; + struct scmi_channel *ret =3D ERR_PTR(-ENOENT); + + spin_lock(&scmi_data.channel_list_lock); + list_for_each_entry(curr, &scmi_data.channel_list, list) + { + if ( curr->agent_id =3D=3D agent_id ) + { + if ( curr->domain_id !=3D DOMID_INVALID ) + { + ret =3D ERR_PTR(-EEXIST); + break; + } + + curr->domain_id =3D d->domain_id; + ret =3D curr; + break; + } + } + + spin_unlock(&scmi_data.channel_list_lock); + + return ret; +} + +static void relinquish_scmi_channel(struct scmi_channel *channel) +{ + ASSERT(channel !=3D NULL); + + spin_lock(&scmi_data.channel_list_lock); + channel->domain_id =3D DOMID_INVALID; + spin_unlock(&scmi_data.channel_list_lock); +} + +static int map_channel_memory(struct scmi_channel *channel) +{ + ASSERT(channel && channel->paddr); + channel->shmem =3D ioremap_nocache(channel->paddr, SCMI_SHMEM_MAPPED_S= IZE); + if ( !channel->shmem ) + return -ENOMEM; + + channel->shmem->channel_status =3D SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE; + printk(XENLOG_DEBUG "scmi: Got shmem %lx after vmap %p\n", channel->pa= ddr, + channel->shmem); + + return 0; +} + +static void unmap_channel_memory(struct scmi_channel *channel) +{ + ASSERT(channel && channel->shmem); + iounmap(channel->shmem); + channel->shmem =3D NULL; +} + +static struct scmi_channel *smc_create_channel(uint32_t agent_id, + uint32_t func_id, uint64_t = addr) +{ + struct scmi_channel *channel, *curr; + + spin_lock(&scmi_data.channel_list_lock); + + /* Check if channel already exists while holding the lock */ + list_for_each_entry(curr, &scmi_data.channel_list, list) + { + if ( curr->agent_id =3D=3D agent_id ) + { + spin_unlock(&scmi_data.channel_list_lock); + return ERR_PTR(-EEXIST); + } + } + + channel =3D xmalloc(struct scmi_channel); + if ( !channel ) + { + spin_unlock(&scmi_data.channel_list_lock); + return ERR_PTR(-ENOMEM); + } + + spin_lock_init(&channel->lock); + channel->agent_id =3D agent_id; + channel->func_id =3D func_id; + channel->domain_id =3D DOMID_INVALID; + channel->shmem =3D NULL; + channel->paddr =3D addr; + list_add_tail(&channel->list, &scmi_data.channel_list); + + spin_unlock(&scmi_data.channel_list_lock); + return channel; +} + +static void free_channel_list(void) +{ + struct scmi_channel *curr, *_curr; + + list_for_each_entry_safe(curr, _curr, &scmi_data.channel_list, list) + { + list_del(&curr->list); + xfree(curr); + } +} + +static int __init +scmi_dt_read_hyp_channel_addr(struct dt_device_node *scmi_node, u64 *addr, + u64 *size) +{ + struct dt_device_node *shmem_node; + const __be32 *prop; + + prop =3D dt_get_property(scmi_node, "shmem", NULL); + if ( !prop ) + return -EINVAL; + + shmem_node =3D dt_find_node_by_phandle(be32_to_cpu(*prop)); + if ( IS_ERR_OR_NULL(shmem_node) ) + { + printk(XENLOG_ERR + "scmi: Device tree error, can't parse reserved memory %ld\n= ", + PTR_ERR(shmem_node)); + return PTR_ERR(shmem_node); + } + + return dt_device_get_address(shmem_node, 0, addr, size); +} + +/* + * Handle Dom0 SCMI specific DT nodes + * + * Make a decision on copying SCMI specific nodes into Dom0 device tree. + * For SCMI multi-agent case: + * - shmem nodes will not be copied and generated instead if SCMI + * is enabled for Dom0 + * - scmi node will be copied if SCMI is enabled for Dom0 + */ +static bool scmi_dt_handle_node(struct domain *d, struct dt_device_node *n= ode) +{ + 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 */ }, + }; + + if ( !scmi_data.initialized ) + return false; + + /* 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; + } + + /* drop scmi if not enabled */ + if ( dt_match_node(scmi_matches, node) && !sci_domain_is_enabled(d) ) + { + dt_dprintk(" Skip scmi node\n"); + return true; + } + + return false; +} + +static int scmi_assign_device(uint32_t agent_id, uint32_t device_id, + uint32_t flags) +{ + struct scmi_msg_base_set_device_permissions_a2p tx; + struct scmi_channel *channel; + scmi_msg_header_t hdr; + + channel =3D get_channel_by_id(scmi_data.hyp_channel_agent_id); + if ( !channel ) + return -EINVAL; + + hdr.id =3D SCMI_BASE_SET_DEVICE_PERMISSIONS; + hdr.type =3D 0; + hdr.protocol =3D SCMI_BASE_PROTOCOL; + + tx.agent_id =3D agent_id; + tx.device_id =3D device_id; + tx.flags =3D flags; + + return do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0); +} + +static int scmi_dt_assign_device(struct domain *d, + struct dt_phandle_args *ac_spec) +{ + struct scmi_channel *agent_channel; + uint32_t scmi_device_id =3D ac_spec->args[0]; + int ret; + + if ( !d->arch.sci_data ) + return 0; + + /* The access-controllers is specified for DT dev, but it's not a SCMI= */ + if ( ac_spec->np !=3D scmi_data.dt_dev ) + return 0; + + agent_channel =3D d->arch.sci_data; + + spin_lock(&agent_channel->lock); + + ret =3D scmi_assign_device(agent_channel->agent_id, scmi_device_id, + SCMI_BASE_DEVICE_ACCESS_ALLOW); + if ( ret ) + { + printk(XENLOG_ERR + "scmi: could not assign dev for %pd agent:%d dev_id:%u (%d)= ", + d, agent_channel->agent_id, scmi_device_id, ret); + } + + spin_unlock(&agent_channel->lock); + return ret; +} + +static int collect_agent_id(struct scmi_channel *agent_channel) +{ + int ret; + scmi_msg_header_t hdr; + struct scmi_msg_base_discover_agent_p2a da_rx; + struct scmi_msg_base_discover_agent_a2p da_tx; + + ret =3D map_channel_memory(agent_channel); + if ( ret ) + return ret; + + hdr.id =3D SCMI_BASE_DISCOVER_AGENT; + hdr.type =3D 0; + hdr.protocol =3D SCMI_BASE_PROTOCOL; + + da_tx.agent_id =3D agent_channel->agent_id; + + ret =3D do_smc_xfer(agent_channel, &hdr, &da_tx, sizeof(da_tx), &da_rx= , + sizeof(da_rx)); + if ( agent_channel->domain_id !=3D DOMID_XEN ) + unmap_channel_memory(agent_channel); + if ( ret ) + return ret; + + printk(XENLOG_DEBUG "id=3D0x%x name=3D%s\n", da_rx.agent_id, da_rx.nam= e); + agent_channel->agent_id =3D da_rx.agent_id; + return 0; +} + +static __init int collect_agents(struct dt_device_node *scmi_node) +{ + const struct dt_device_node *config_node; + const __be32 *prop; + uint32_t len; + const __be32 *end; + uint32_t cells_per_entry =3D 3; /* Default to 3 cells if property is a= bsent. */ + + config_node =3D dt_find_compatible_node(NULL, NULL, "xen,sci"); + if ( !config_node ) + { + printk(XENLOG_WARNING "scmi: xen,sci node not found, no agents to = collect.\n"); + return -ENOENT; + } + + /* Check for the optional '#scmi-secondary-agents-cells' property. */ + if ( dt_property_read_u32(config_node, "#scmi-secondary-agents-cells", + &cells_per_entry) ) + { + if ( cells_per_entry !=3D 2 && cells_per_entry !=3D 3 ) + { + printk(XENLOG_ERR "scmi: Invalid #scmi-secondary-agents-cells = value: %u\n", + cells_per_entry); + return -EINVAL; + } + } + + prop =3D dt_get_property(config_node, SCMI_SECONDARY_AGENTS, &len); + if ( !prop ) + { + printk(XENLOG_ERR "scmi: No %s property found, no agents to collec= t.\n", + SCMI_SECONDARY_AGENTS); + return -EINVAL; + } + + /* Validate that the property length is a multiple of the cell size. *= / + if ( len =3D=3D 0 || len % (cells_per_entry * sizeof(uint32_t)) !=3D 0= ) + { + printk(XENLOG_ERR "scmi: Invalid length of %s property: %u for %u = cells per entry\n", + SCMI_SECONDARY_AGENTS, len, cells_per_entry); + return -EINVAL; + } + + end =3D (const __be32 *)((const u8 *)prop + len); + + for ( ; prop < end; ) + { + uint32_t agent_id; + uint32_t smc_id; + uint32_t shmem_phandle; + struct dt_device_node *node; + u64 addr, size; + int ret; + struct scmi_channel *agent_channel; + + smc_id =3D be32_to_cpu(*prop++); + shmem_phandle =3D be32_to_cpu(*prop++); + + if ( cells_per_entry =3D=3D 3 ) + agent_id =3D be32_to_cpu(*prop++); + else + agent_id =3D SCMI_BASE_AGENT_ID_OWN; + + node =3D dt_find_node_by_phandle(shmem_phandle); + if ( !node ) + { + printk(XENLOG_ERR "scmi: Could not find shmem node for agent %= u\n", + agent_id); + return -EINVAL; + } + + ret =3D dt_device_get_address(node, 0, &addr, &size); + if ( ret ) + { + printk(XENLOG_ERR + "scmi: Could not read shmem address for agent %u: %d\n"= , + agent_id, ret); + return ret; + } + + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) ) + { + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); + return -EINVAL; + } + + agent_channel =3D smc_create_channel(agent_id, smc_id, addr); + if ( IS_ERR(agent_channel) ) + { + printk(XENLOG_ERR "scmi: Could not create channel for agent %u= : %ld\n", + agent_id, PTR_ERR(agent_channel)); + return PTR_ERR(agent_channel); + } + + if ( cells_per_entry =3D=3D 2 ) + { + ret =3D collect_agent_id(agent_channel); + if ( ret ) + return ret; + } + + printk(XENLOG_DEBUG "scmi: Agent %u SMC %X addr %lx\n", agent_chan= nel->agent_id, + smc_id, (unsigned long)addr); + } + + return 0; +} + +static int scmi_domain_init(struct domain *d, + struct xen_domctl_createdomain *config) +{ + struct scmi_channel *channel; + int ret; + + if ( !scmi_data.initialized ) + return 0; + + /* + * SCMI support is configured via: + * - For dom0: dom0=3Dsci-agent-id=3D in Xen command line + * - For dom0less: xen,sci-agent-id in device tree + * The config->arch.arm_sci_type and config->arch.arm_sci_agent_id + * are already set by domain_build.c or dom0less-build.c + */ + + if ( config->arch.arm_sci_type =3D=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE ) + return 0; + + channel =3D acquire_scmi_channel(d, config->arch.arm_sci_agent_id); + if ( IS_ERR(channel) ) + { + printk(XENLOG_ERR + "scmi: Failed to acquire SCMI channel for agent_id %u: %ld\= n", + config->arch.arm_sci_agent_id, PTR_ERR(channel)); + return PTR_ERR(channel); + } + + printk(XENLOG_INFO + "scmi: Acquire channel id =3D 0x%x, domain_id =3D %d paddr =3D = 0x%lx\n", + channel->agent_id, channel->domain_id, channel->paddr); + + /* + * Dom0 (if present) needs to have an access to the guest memory range + * to satisfy iomem_access_permitted() check in XEN_DOMCTL_iomem_permi= ssion + * domctl. + */ + if ( hardware_domain && !is_hardware_domain(d) ) + { + ret =3D iomem_permit_access(hardware_domain, paddr_to_pfn(channel-= >paddr), + paddr_to_pfn(channel->paddr + PAGE_SIZE = - 1)); + if ( ret ) + goto error; + } + + d->arch.sci_data =3D channel; + d->arch.sci_enabled =3D true; + + return 0; + +error: + relinquish_scmi_channel(channel); + return ret; +} + +int scmi_domain_sanitise_config(struct xen_domctl_createdomain *config) +{ + if ( config->arch.arm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE && + config->arch.arm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC= _MA ) + { + dprintk(XENLOG_INFO, "scmi: Unsupported ARM_SCI type\n"); + return -EINVAL; + } + + return 0; +} + +static int scmi_relinquish_resources(struct domain *d) +{ + int ret; + struct scmi_channel *channel, *agent_channel; + scmi_msg_header_t hdr; + struct scmi_msg_base_reset_agent_cfg_a2p tx; + + if ( !d->arch.sci_data ) + return 0; + + agent_channel =3D d->arch.sci_data; + + spin_lock(&agent_channel->lock); + tx.agent_id =3D agent_channel->agent_id; + spin_unlock(&agent_channel->lock); + + channel =3D get_channel_by_id(scmi_data.hyp_channel_agent_id); + if ( !channel ) + { + printk(XENLOG_ERR + "scmi: Unable to get Hypervisor scmi channel for domain %d\= n", + d->domain_id); + return -EINVAL; + } + + hdr.id =3D SCMI_BASE_RESET_AGENT_CONFIGURATION; + hdr.type =3D 0; + hdr.protocol =3D SCMI_BASE_PROTOCOL; + + tx.flags =3D 0; + + ret =3D do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0); + if ( ret =3D=3D -EOPNOTSUPP ) + return 0; + + return ret; +} + +static void scmi_domain_destroy(struct domain *d) +{ + struct scmi_channel *channel; + + if ( !d->arch.sci_data ) + return; + + channel =3D d->arch.sci_data; + spin_lock(&channel->lock); + + relinquish_scmi_channel(channel); + printk(XENLOG_DEBUG "scmi: Free domain %d\n", d->domain_id); + + d->arch.sci_data =3D NULL; + d->arch.sci_enabled =3D false; + + spin_unlock(&channel->lock); +} + +static bool scmi_handle_call(struct cpu_user_regs *regs) +{ + uint32_t fid =3D (uint32_t)get_user_reg(regs, 0); + struct scmi_channel *agent_channel; + struct domain *d =3D current->domain; + struct arm_smccc_res resp; + bool res =3D false; + + if ( !sci_domain_is_enabled(d) ) + return false; + + agent_channel =3D d->arch.sci_data; + spin_lock(&agent_channel->lock); + + if ( agent_channel->func_id !=3D fid ) + { + res =3D false; + goto unlock; + } + + arm_smccc_1_1_smc(fid, + get_user_reg(regs, 1), + get_user_reg(regs, 2), + get_user_reg(regs, 3), + get_user_reg(regs, 4), + get_user_reg(regs, 5), + get_user_reg(regs, 6), + get_user_reg(regs, 7), + &resp); + + set_user_reg(regs, 0, resp.a0); + set_user_reg(regs, 1, resp.a1); + set_user_reg(regs, 2, resp.a2); + set_user_reg(regs, 3, resp.a3); + res =3D true; +unlock: + spin_unlock(&agent_channel->lock); + + return res; +} + +static const struct sci_mediator_ops scmi_ops =3D { + .domain_init =3D scmi_domain_init, + .domain_destroy =3D scmi_domain_destroy, + .relinquish_resources =3D scmi_relinquish_resources, + .handle_call =3D scmi_handle_call, + .dom0_dt_handle_node =3D scmi_dt_handle_node, + .domain_sanitise_config =3D scmi_domain_sanitise_config, + .assign_dt_device =3D scmi_dt_assign_device, +}; + +static int __init scmi_check_smccc_ver(void) +{ + if ( smccc_ver < ARM_SMCCC_VERSION_1_1 ) + { + printk(XENLOG_WARNING + "scmi: No SMCCC 1.1 support, SCMI calls forwarding disabled= \n"); + return -ENOSYS; + } + + return 0; +} + +static int __init scmi_dt_hyp_channel_read(struct dt_device_node *scmi_nod= e, + struct scmi_data *scmi_data, + u64 *addr) +{ + int ret; + u64 size; + + if ( !dt_property_read_u32(scmi_node, "arm,smc-id", &scmi_data->func_i= d) ) + { + printk(XENLOG_ERR "scmi: unable to read smc-id from DT\n"); + return -ENOENT; + } + + ret =3D scmi_dt_read_hyp_channel_addr(scmi_node, addr, &size); + if ( IS_ERR_VALUE(ret) ) + return -ENOENT; + + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) ) + { + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); + return -EINVAL; + } + + return 0; +} + +static __init int scmi_probe(struct dt_device_node *scmi_node, const void = *data) +{ + u64 addr; + int ret; + struct scmi_channel *channel; + unsigned int n_agents; + scmi_msg_header_t hdr; + struct scmi_msg_base_attributes_p2a rx; + + ASSERT(scmi_node !=3D NULL); + + /* + * Only bind to the SCMI node provided by Xen under the xen,sci contai= ner + * (e.g. /chosen/xen/xen_scmi_config/scmi). This avoids binding to fir= mware + * SCMI nodes that belong to the host OSPM and keeps the mediator scop= ed to + * Xen-provided configuration only. + */ + if ( !scmi_is_under_xen_sci(scmi_node) ) + return -ENODEV; + + INIT_LIST_HEAD(&scmi_data.channel_list); + spin_lock_init(&scmi_data.channel_list_lock); + + if ( !acpi_disabled ) + { + printk(XENLOG_WARNING "scmi: is not supported when using ACPI\n"); + return -EINVAL; + } + + ret =3D scmi_check_smccc_ver(); + if ( ret ) + return ret; + + ret =3D scmi_dt_hyp_channel_read(scmi_node, &scmi_data, &addr); + if ( ret ) + return ret; + + scmi_data.dt_dev =3D scmi_node; + + channel =3D smc_create_channel(SCMI_BASE_AGENT_ID_OWN, scmi_data.func_= id, addr); + if ( IS_ERR(channel) ) + goto out; + + /* Mark as Xen management channel before collecting agent ID */ + channel->domain_id =3D DOMID_XEN; + + /* Request agent id for Xen management channel */ + ret =3D collect_agent_id(channel); + if ( ret ) + goto error; + + /* Save the agent id for Xen management channel */ + scmi_data.hyp_channel_agent_id =3D channel->agent_id; + + hdr.id =3D SCMI_BASE_PROTOCOL_ATTIBUTES; + hdr.type =3D 0; + hdr.protocol =3D SCMI_BASE_PROTOCOL; + + ret =3D do_smc_xfer(channel, &hdr, NULL, 0, &rx, sizeof(rx)); + if ( ret ) + goto error; + + n_agents =3D SCMI_FIELD_GET(SCMI_BASE_ATTR_NUM_AGENT, rx.attributes); + printk(XENLOG_DEBUG "scmi: Got agent count %d\n", n_agents); + ret =3D collect_agents(scmi_node); + if ( ret ) + goto error; + + ret =3D sci_register(&scmi_ops); + if ( ret ) + { + printk(XENLOG_ERR "SCMI: mediator already registered (ret =3D %d)\= n", + ret); + return ret; + } + + scmi_data.initialized =3D true; + goto out; + +error: + unmap_channel_memory(channel); + free_channel_list(); +out: + return ret; +} + +static const struct dt_device_match scmi_smc_match[] __initconst =3D { + DT_MATCH_COMPATIBLE("arm,scmi-smc"), + { /* sentinel */ }, +}; + +DT_DEVICE_START(scmi_smc_ma, "SCMI SMC MEDIATOR", DEVICE_FIRMWARE) + .dt_match =3D scmi_smc_match, + .init =3D scmi_probe, +DT_DEVICE_END + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index 095b1a23e3..30e46de6d7 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -329,6 +329,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); =20 #define XEN_DOMCTL_CONFIG_ARM_SCI_NONE 0 #define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC 1 +#define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA 2 =20 struct xen_arch_domainconfig { /* IN/OUT */ @@ -355,6 +356,8 @@ struct xen_arch_domainconfig { uint32_t clock_frequency; /* IN */ uint8_t arm_sci_type; + /* IN */ + uint8_t arm_sci_agent_id; }; #endif /* __XEN__ || __XEN_TOOLS__ */ =20 --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Jan 14 18:29:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 18:29:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203678.1518789 (Exim 4.92) (envelope-from ) id 1vg5d1-0007DA-Nq; Wed, 14 Jan 2026 18:29:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203678.1518789; Wed, 14 Jan 2026 18:29:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg5d1-0007Cm-KW; Wed, 14 Jan 2026 18:29:59 +0000 Received: by outflank-mailman (input) for mailman id 1203678; Wed, 14 Jan 2026 18: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 1vg5cz-0005zq-Rl for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 18:29:57 +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 05e73332-f177-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 19:29:55 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by AS8PR03MB6997.eurprd03.prod.outlook.com (2603:10a6:20b:295::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Wed, 14 Jan 2026 18:29:50 +0000 Received: from PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc%5]) with mapi id 15.20.9520.005; Wed, 14 Jan 2026 18:29: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: 05e73332-f177-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=aarwzvupmXeB5EUFvrj4Qnnu32uXHXhKzs2+llj/sUQ88V2Pj+fzHSzg6tL0YEDkJXuBz+Mij/6fHSpSd7nYoSdiHh3JyWn2VHqzACfPsUAYClMMEinP1ZrxO1FoCYmwkJ6sMZ8fcovLh8CWrBdLzEqrGyKYJnJPRruGH1wiy8Jufe9tV0B3kaIR0fLMulFVD0+R2/1OjheESoslm2f9hKJXIxzR7TQbjfSdG1NRxOgCeO5NLh/ChmZ6/ktHeutYqFHpAxcPpbp4z+lTmsS6Gjkj2oGbKpwTNcbq8PiwB+Um9eKQ8iP+08gZUmE5YW+tUPS+xohyowh5Fb32xeOlkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KUbfJ09ajEh6RKCW3zuVvy+KnBTsoSV1Fb+FIC+7Rhk=; b=dcgzkQUgD5rGx2292NY0FxRWgMSYeH5eaZ/8g7qrl8Li4JynSO4kysZmeB8tFUBkrneb3Vq8EFVSDAd8GYOac1e/QFZiFik4WL59QFWcdftw9/ftoDop1gcB+hy2KOcliI6gqH5K8bcZDVNa80UadCxE2prdc7/sWbo9hQOGPOcnmgtuEkQiesQ3dRokl9c6HdoAg9c4yXru41j4enSldlqEgfLMj9Ce0AZKgRf/zurEfBgeIOg7uEucJI5dhMCgQNZwlzh/PtgvMAdT7/s316JQdHqVYiPtvkeiYziTo0gglhWXikTRqRJZd8ULP5NiERxPfLeaVtIh0eqYiqN5mA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KUbfJ09ajEh6RKCW3zuVvy+KnBTsoSV1Fb+FIC+7Rhk=; b=nzvuebu0pO14f0e7xRl8hrRVzYJsey1ZH29pNkMhVijjomE9owkkRCTYd8vcB924D970W4VnNwMMVWMSKA4d4sE7kb2dZj3+sWP6ekmkpL6v/8H6WFkFkpRnqdOXtScUkhR3+bw2tLYdAeKmybwZcp8z6OsnCMcS94unjHBl0jOGz7ahDT8rZEJCuK5fuXvLs5dHVqe3004Qx1YqY2APCxNsE3my3cxwahyf/EXfHmptXllzul6xYLrfkPKmKYsctkOe7R9MsI/TeO+r+nfbEzb3aGN/wXjrCm7bsK7X9RfT+RXQCdTuCuk4BKsvhuaQhelNyEYsbxNUSk5j24ng7w== 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 5/5] docs: arm: add SCI SCMI SMC multi-agent driver docs Thread-Topic: [PATCH v7 5/5] docs: arm: add SCI SCMI SMC multi-agent driver docs Thread-Index: AQHchYPEwdMU0byXVUqET+ZDFFsuOA== Date: Wed, 14 Jan 2026 18:29:49 +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_|AS8PR03MB6997:EE_ x-ms-office365-filtering-correlation-id: 595a4d2d-2275-4b53-4eaf-08de539ae74b x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|366016|38070700021; x-microsoft-antispam-message-info: =?iso-8859-1?Q?vawYf8/qwe3T21BUwNxD731Td0ca7HPXkSR3OWGkPss+t/jvrJJNgTFRhO?= =?iso-8859-1?Q?90vRtXtEWrC5NfULQayQ34a+7+0iQwcJCF01vhAN4F2TDm7aTopjNh4qX+?= =?iso-8859-1?Q?xRmcHi3frUNXSOEtKPaWDjH3JVzmSWKcw7h72uG/EmTyLmuUftNEREVdqr?= =?iso-8859-1?Q?2mldiqGYRTkIgLA7FNY/85nLxa6KptVYkhGB3SSeEDhMFkpuoKZoazCWSd?= =?iso-8859-1?Q?sYxFlKi5P4KvqxPrwwOvAYuPYEaH3r90bFnlnxNe/uaizy14I2hm/Dvjvy?= =?iso-8859-1?Q?idHsc7C9Khqna3K7XL9m/x/dYY0fR/DaPO9fcwpqPn03t1AqTFypljrDHR?= =?iso-8859-1?Q?BcKazdh7CKRFMbKe6QptZszcESZE2BK6ZZCq/rsI/IEp+Ds7eXRlULrkUo?= =?iso-8859-1?Q?XBdololFrJA8ri8LM/NOvBHl34MwzbVlOWfP4FRrD2l6381hTODhGVsM/e?= =?iso-8859-1?Q?/UWAIpwqRzVjYqeWoS4gAfpCGiLyY10Llnzxqhg7AEGvvQR/Jf1yEWV49e?= =?iso-8859-1?Q?dY6/YbBtMfj8kktANF2A/oKR4gcC2WILZidw5orcuqOeLY3gzGxX4Hca2M?= =?iso-8859-1?Q?1i+aSvsohCnNizJllJirCTPIxqLB66SNGKS2HFVQVuIj+YWk5IXoi7Vm8u?= =?iso-8859-1?Q?IGey/GBkR+TwcMeK7zZwtQ05udLyF7iBAOIbtp4oxs1O3S8FMmIett1nIo?= =?iso-8859-1?Q?aZ34W6M9c+3xd7vE3TZzfFMe4FO1tVAkdE6VmZKAa7pS95jkCuw4s66cDU?= =?iso-8859-1?Q?ZklvDsz/2hOJoiAmPuKm9e+nythjCbv80ORymMXiFGqMrPqt+MZUzXFzm1?= =?iso-8859-1?Q?XeCKdPqjsM715C19hTCFYMEiFdSZ3QR+sLrGBQElFjxBS2wvA27s/9GgSL?= =?iso-8859-1?Q?FU14iCk+aRnJUYzFb5UdIoTK4t1SZJlDAlMFPoZSSaX+wfjMjJ/XlBMoHu?= =?iso-8859-1?Q?eEwIE4KQ/oJk/19VqquLff7Eaj2CCMJ8jhzb+iLpIRDVA2zbGLwkWfTfWe?= =?iso-8859-1?Q?r1OH8oueofFFuAqcZeLlPKfZWtunu+X0H606FDLqUEAFaXWr72jynrh+qL?= =?iso-8859-1?Q?4nAFfta9v+sXsrNj6fzN4mpBCn0tMUgweRMG3iq5Y1rVekw0lCArl1Jb7J?= =?iso-8859-1?Q?j6UhdNtI0LFLP6s/TMXNynCD0FlxxULtXvUvyuPiL0Fvm3Bz4wCZ23o+0S?= =?iso-8859-1?Q?AY4vNQWlhDs7DgiNY+7c7PeTx3TriZUdj+Yj/QLci2yj9sbNstEXZqXrXC?= =?iso-8859-1?Q?qNX9xCvWp4XorsF3jfKvEpvdCVOSYemNXdHWEVSM/+FEyzn3x/ssRzawR0?= =?iso-8859-1?Q?hSND1Igv0+uj7ihRDi5yydU2XwEAiyeboLgmphmhkCCFUdHYCSSQVfNstw?= =?iso-8859-1?Q?wAyvfn+H6OoUrULTEKc0ZtqmyLt1ejY0dnEA39P3n+/VzLsFnlcm9JEMjh?= =?iso-8859-1?Q?biOym6MjWuIdF15AEK7GHvRjUMUBnoqWdUUQcppK+5NTse8FEmmBWjU8SA?= =?iso-8859-1?Q?549T1CqOMnR0qGwYgobC4wabxRWRfOqaezGCALqVX078BahK7CfBAAehmn?= =?iso-8859-1?Q?Ivl/B35sD58rinNvi7xb8/N1IPqm/wiGe2PVIVLuYk6Ze+ugKH6NEqTcqL?= =?iso-8859-1?Q?SVja23hXZ8MDCYan+RcmTAXKXXmMwf5/4pxT3A90vXPqBC7cJNxQPo37ws?= =?iso-8859-1?Q?1MTdns2fzXm6fsozWiI=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?3jXObwkRLBqYP/nJz2i/moQGU3AMeXZmsdbBFZ+XEMk1RF6x5EnySuanJc?= =?iso-8859-1?Q?bZfM6kLy87JFbDfl7Hp2I2e2LgyUw6SP9rvpELEHuChWvS3O3KXtztReMd?= =?iso-8859-1?Q?JxYyVY0rzkt4OlJnVP3jgmUCjzdQnIzy8OAqD/DNc60264TgecahYMyY6P?= =?iso-8859-1?Q?zDAshbu21LPVyvgkzHVICW84fLAeUol5yOA10R1V9aKuQUUH4HxmU/vml6?= =?iso-8859-1?Q?Y1pdMft0ev8vL/6b/QgM8rqj1U0xUdYkESs0UDnLOyeaHiyO6qI4OHcfN0?= =?iso-8859-1?Q?x9CheNh8F6JD6GEW9asHkLnlp8qrOIYFEttPSsrjNDhPWGoLKlsYwRgiiD?= =?iso-8859-1?Q?waODZEWz67oHALP3RM+uXAXoUKjuUzasP2BlPccpCmN8FtuVcL+Pzgjszw?= =?iso-8859-1?Q?i/5tclLEvcNPHYvbrbHLeiJpxlqFAL0PLEtIHvzNmZqTfuTBvioeFlRJWN?= =?iso-8859-1?Q?revuOdaOl6+NcxJuw1BGr2INPmIOoAcSpso4Kd1OGN+zYGmx6V3R4lpT1d?= =?iso-8859-1?Q?UTcEAmsGXaAd2EyeLwK+/4oKLzFbdgR8VNTA4cj+jBbIlVNUrTsKoA4/Uk?= =?iso-8859-1?Q?QAPUVwJdun224qa6bYmd1Dtc9WfTS1P0WrI44ModgSOVV6+ToPgEVaIl1F?= =?iso-8859-1?Q?fZqBkcelrQIqM9SN8Rz2hNIeyhD2p9VfY0qncFGsVG+6sUgc9nmkiLWOv3?= =?iso-8859-1?Q?nmr8N2JVzOLj/RCqr4WBDYphYJBGVGBJyln5vqaHV0Csh4thRniHBNVqaJ?= =?iso-8859-1?Q?2sT0WkRbmBrS8WFvg8Pp6NGERH/eHI9WWuLspLFrom2jgGcex1dq4zFYQT?= =?iso-8859-1?Q?xTdl2a+YlSdYey2E/YQpdqzg8qXkwmZxA2LyCMwToz7l+du0aFBPlzZcvx?= =?iso-8859-1?Q?OXuMNGo0UoUvo2y2K9MiqCe+lajpXCWQNRekQLAtXya2FLkpAWJ4JT23+x?= =?iso-8859-1?Q?N1LEY13W9vQuefg4oBZsCvxbN8J+wzKPuD6eMZS/+9iWfcLNi2o1ZWwgYZ?= =?iso-8859-1?Q?t9PZ3CTneBrC1swUyhs1f068VhDm8w13y6YASBnfxFs7tx7p98IjGcfqOU?= =?iso-8859-1?Q?k/9SqEd+Qks/2jXHZnjpymeoF81Y5zEiYQxmtMtJNVGHES/yZZWLUiAzIE?= =?iso-8859-1?Q?VoC/c8ElY9XGEf2+lcDvLJRC7jXxkBBbkWdqB5C30+SR65VsJ8CBXw6EWT?= =?iso-8859-1?Q?y2MA5DmkYclgCJYq5fMin9jGe+6g2gC0gXcpJP7SHAkuHLG4TcMyG6xVju?= =?iso-8859-1?Q?XUf6/dSX8OWn/tfXOUCASjzarvarC5Gsx6l8eaGT6CtsaCkzGy4h3/NVAs?= =?iso-8859-1?Q?RwsQ+ZokxhEs4VITTdaNCKeWTeFoj7JXezVQGEZ33nlvu99IyZLKx6y8w8?= =?iso-8859-1?Q?FPrY+/mjn0/kmhKCqiIsDsavzKw8HklV13yD1Er9kIXjFdDUPXwStInFuz?= =?iso-8859-1?Q?eN4Vx7XQLhhMyePfI20YZfqu3ShV/TtqirNPnv1f/R2rqXEHGwaYi39D4T?= =?iso-8859-1?Q?NDZlomsHiWvcC08VHzXMEoLUROlHWcVmrnq0NKCsUXchGJcHO6iMuBBReN?= =?iso-8859-1?Q?jOhma9GtGHvAh4ziFeax3DKuR+FnQ0r0YJaCd1GHgtGscdP3a3QH9n8rq0?= =?iso-8859-1?Q?qsUqZax4m5RnELYo4wcpZ141ghhh1zP9nBwJwKEt99hd3aQe6cCvGZttZB?= =?iso-8859-1?Q?yS8bmvCUgZJDFnBnwCfrQogR2cezObjLmh9+pej61RGaBsJelB9NHT0yQF?= =?iso-8859-1?Q?qiXgw+XrBm4JV7dWCEqXKusfQuBhRPWyKc1Z3GFTQ33yjVXLSDkA9/2lz7?= =?iso-8859-1?Q?czZvkqYDtCEty7oEqQ9Lh+c6GSaGoXI=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: 595a4d2d-2275-4b53-4eaf-08de539ae74b X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2026 18:29:49.6758 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: HBMFYxess5eKQQr9H6O9E60Qppv4BkNPZMpDWtAxWWt4JXrCEBZUtUuID++zIkgKRS86XY42ooI3mmRC2PkGCiIVXPzS9lQEfy/Lvi0egDs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB6997 From: Grygorii Strashko Add SCI SCMI SMC multi-agent driver documentation. It includes a detailed description of the SCMI multi-agent driver. This document explains the driver's functionality, configuration, and the compilation process. The Xen SCMI multi-agent driver is designed to provide SCMI access to system resources from different domains. Signed-off-by: Grygorii Strashko Signed-off-by: Oleksii Moisieiev --- Changes in v7: - update documentation in section of the xen_scmi configuration which is matched by "xen,sci" compatible instead of the direct path. Changes in v6: - remove all HVC mentions from the multi-agent doc - update sci-agent-id parameter description in the documentation - add missing Sign-of - minor fixes across the document Changes in v5: - rework multi-agent driver to leave Host Device-tree unmodified .../arm/firmware/arm-scmi.rst | 341 ++++++++++++++++++ docs/misc/arm/device-tree/booting.txt | 123 ++++--- 2 files changed, 412 insertions(+), 52 deletions(-) diff --git a/docs/hypervisor-guide/arm/firmware/arm-scmi.rst b/docs/hypervi= sor-guide/arm/firmware/arm-scmi.rst index d9698f4e4b..630965fef3 100644 --- a/docs/hypervisor-guide/arm/firmware/arm-scmi.rst +++ b/docs/hypervisor-guide/arm/firmware/arm-scmi.rst @@ -36,6 +36,8 @@ The below sections describe SCMI support options availabl= e for Xen. =20 | [1] `Arm SCMI `= _ | [2] `System Control and Management Interface (SCMI) bindings `_ +| [3] `Generic Domain Access Controllers bindings `_ + =20 Simple SCMI over SMC calls forwarding driver (EL3) ------------------------------------------------------ @@ -189,3 +191,342 @@ except explicitly enabling SCMI with "arm_sci" xl.cfg= option. -> xen,reg =3D <0x0 0x47ff0000 0x0 0x1000 0x0 0x22001000>; -> xen,force-assign-without-iommu; }; + +SCMI SMC multi-agent driver (EL3) +------------------------------------- + +The SCMI SMC multi-agent driver enables support for ARM EL3 Trusted Firmwa= re-A (TF-A) which +provides SCMI interface with multi-agent support, as shown below. + +:: + + +-----------------------------------------+ + | | + | EL3 TF-A SCMI | + +-------+--+-------+--+-------+--+-------++ + |shmem1 | |shmem0 | |shmem2 | |shmemX | + +-----+-+ +---+---+ +--+----+ +---+---+ + smc-id1 | | | | + agent1 | | | | + +-----v--------+---------+-----------+----+ + | | | | | + | | | | | + +--------------+---------+-----------+----+ + smc-id0 | smc-id2| smc-idX| + agent0 | agent2 | agentX | + | | | + +----v---+ +--v-----+ +--v-----+ + | | | | | | + | Dom0 | | Dom1 | | DomX | + | | | | | | + | | | | | | + +--------+ +--------+ +--------+ + +The EL3 SCMI multi-agent firmware is expected to provide SCMI SMC shared-m= emory transport +for every Agent in the system. The SCMI Agent transport channel defined by= pair: + +- smc-id: SMC function id used for Doorbell +- shmem: shared memory for messages transfer, **Xen page aligned**. + Shared memory is mapped with the following flags: MT_DEVICE_nGnRE and _P= AGE_DEVICE, indicating that this + memory is mapped as device memory. + +The following SCMI Agents are expected to be defined by SCMI FW to enable = SCMI multi-agent functionality +under Xen: + +- Xen management agent: trusted agents that accesses to the Base Protocol = commands to configure + agent specific permissions +- OSPM VM agents: non-trusted agent, one for each Guest domain which is a= llowed direct HW access. + At least one OSPM VM agent has to be provided by FW if HW is handled onl= y by Dom0 or Driver Domain. + +The EL3 SCMI FW is expected to implement following Base protocol messages: + +- BASE_DISCOVER_AGENT (optional if agent_id was provided) +- BASE_RESET_AGENT_CONFIGURATION (optional) +- BASE_SET_DEVICE_PERMISSIONS (optional) + +The number of supported SCMI agents and their transport specifications are= SCMI FW implementation +specific. + +Compiling with multi-agent support +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To build with the SCMI SMC multi-agent driver support, enable Kconfig opti= on: + +:: + + CONFIG_SCMI_SMC_MA + + +Driver functionality +^^^^^^^^^^^^^^^^^^^^ + +The SCI SCMI SMC multi-agent driver implements following functionality: + +- The driver is initialized based on the ``xen,config`` node under ``chose= n`` + (only one SCMI interface is supported), which describes the Xen manageme= nt + agent SCMI interface. + +.. code-block:: dts + + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000002>; <--- Xen management agent smc-id + #address-cells =3D < 1>; + #size-cells =3D < 0>; + #access-controller-cells =3D < 1>; + shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem + }; + +- The driver obtains Xen specific SCMI Agent's configuration from the Host= DT, probes Agents and + builds SCMI Agents list. The Agents configuration is taken from "scmi-se= condary-agents" + property where first item is "arm,smc-id", second - "arm,scmi-shmem" pha= ndle and third is + optional "agent_id": + +.. code-block:: dts + + chosen { + ranges; <--- set default ranges so address can be translated when pa= rsing scmi_shm node + xen,config { + ranges; <--- set default ranges so address can be translated when = parsing scmi_shm node + scmi-secondary-agents =3D < + 0x82000003 &scmi_shm_0 0 + 0x82000004 &scmi_shm_2 2 + 0x82000005 &scmi_shm_3 3 + 0x82000006 &scmi_shm_4 4>; + #scmi-secondary-agents-cells =3D <3>; <--- optional, default 3 + + scmi_shm_0 : sram@47ff0000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff0000 0x0 0x1000>; + }; + + scmi_shm_2: sram@47ff2000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff2000 0x0 0x1000>; + }; + scmi_shm_3: sram@47ff3000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff3000 0x0 0x1000>; + }; + scmi_shm_4: sram@47ff4000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff4000 0x0 0x1000>; + }; + + // Xen SCMI management channel + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000002>; <--- Xen management agent smc-id + #address-cells =3D < 1>; + #size-cells =3D < 0>; + #access-controller-cells =3D < 1>; + shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem + }; + }; + }; + + /{ + // Host SCMI OSPM channel - provided to the Dom0 as is if SCMI ena= bled for it + scmi_shm: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + + firmware { + scmi: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; <--- Host OSPM agent smc-id + #address-cells =3D < 1>; + #size-cells =3D < 0>; + shmem =3D <&scmi_shm>; <--- Host OSPM agent shmem + + protocol@X{ + }; + }; + }; + }; + + This approach allows defining multiple SCMI Agents by adding Xen-specifi= c properties under + the ``/chosen`` node to the Host Device Tree, leaving the main part unch= anged. The Host DT + SCMI channel will be passed to Dom0. + + The Xen management agent is described as a ``scmi_xen`` node under the `= `/chosen`` node, which + is used by Xen to control other SCMI Agents in the system. + + All secondary agents' configurations are provided in the ``scmi-secondar= y-agents`` property with + an optional ``agent_id`` field. + + The ``agent_id`` from the ``scmi-secondary-agents`` property is used to = identify the agent in the + system and can be omitted by setting ``#scmi-secondary-agents-cells =3D = <2>``, so the Secondary + Agents configuration will look like this: + +... code-block:: dts + + chosen { + xen,config { + scmi-secondary-agents =3D < + 0x82000003 &scmi_shm_0 + 0x82000004 &scmi_shm_2 + 0x82000005 &scmi_shm_3 + 0x82000006 &scmi_shm_4>; + #scmi-secondary-agents-cells =3D <2>; + }; + } + + In this case, Xen will use the ``SCMI_BASE_DISCOVER_AGENT`` call to disc= over the ``agent_id`` + for each secondary agent. Providing the ``agent_id`` in the ``scmi-secon= dary-agents`` property + allows skipping the discovery call, which is useful when the secondary a= gent's shared memory is + not accessible by Xen or when boot time is important because it allows s= kipping the agent + discovery procedure. + +.. note:: + + Note that Xen is the only one entry in the system which need to know a= bout SCMI multi-agent support. + +- The driver implements the SCI subsystem interface required for configuri= ng and enabling SCMI + functionality for Dom0/hwdom and Guest domains. To enable SCMI functiona= lity for guest domain + it has to be configured with unique supported SCMI Agent_id and use corr= esponding SCMI SMC + shared-memory transport ``[smc-id, shmem]`` defined for this SCMI Agent_= id. + +- Once Xen domain is configured it can communicate with EL3 SCMI FW: + + - zero-copy, the guest domain puts/gets SCMI message in/from shmem; + - the guest triggers SMC exception with agent "smc-id" (doorbell); + - the Xen driver catches exception, do checks and synchronously forwards= it to EL3 FW. + +- the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen manag= ement agent channel on + domain destroy event. This allows to reset resources used by domain and = so implement use-case + like domain reboot. + + +Configure SCMI for Dom0 +^^^^^^^^^^^^^^^^^^^^^^^ +The **"dom0=3Dsci-agent-id=3D"** parameter in the Xen comma= nd line is used to enable +SCMI functionality for Dom0. If not provided, SCMI will be disabled for Do= m0 and all SCMI nodes +removed from Dom0 DT. + +Example: **dom0=3Dsci-agent-id=3D0** to enable SCMI with agent ID 0 for Do= m0. + +Xen utilizes Host DT SCMI node to configure Dom0 SCMI Agent so the device-= tree remains unchanged +except for the Xen specific properties under ``/chosen`` node. If Xen devi= ce-tree doesn't include +``/firmware/scmi`` node or it's disabled, the Dom0 SCMI Agent will not be = configured. + +.. note:: + + The **sci-agent-id** value should match the ``func_id`` and ``shmem`` = in the ``/firmware/scmi`` node + to set the correct Dom0 SCMI Agent. + +Configure SCMI for for guest domain with toolstack +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* In domain's xl.cfg file add **"arm_sci"** option as below + +:: + + arm_sci =3D "type=3Dscmi_smc_multiagent,agent_id=3D2" + +* In domain's xl.cfg file enable access to the "arm,scmi-shmem" which shou= ld correspond + assigned "agent_id" for the domain, for example: + +:: + + iomem =3D [ + "47ff2,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. + The "arm,smc-id" should correspond assigned agent_id for the domain: + +.. 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"; + arm,smc-id =3D <0x82000004>; + shmem =3D <&scmi_shm_0>; + ... + } + } + } + +**Device specific access control** + +The XEN SCMI SMC multi-agent driver performs "access-controller" provider = function in case +EL3 SCMI FW implements SCMI "4.2.1.1 Device specific access control" and p= rovides the +BASE_SET_DEVICE_PERMISSIONS command to configure the devices that an agent= s have access to. +The Host DT SCMI node should have "#access-controller-cells=3D<1>" propert= y and DT devices should +be bound to the SCMI node using Access Controllers bindings [3]. + +For example: + +.. code-block:: dts + + &i2c1 { + access-controllers =3D <&scmi 0>; + }; + +Use domain's xl.cfg file **"dtdev"** property to assign SCMI devices from = toolstack to the guest: + +:: + + dtdev =3D [ + "/soc/i2c@e6508000", + ] + +.. note:: + + xl.cfg:"dtdev" need contain all nodes which are under SCMI management = (not only those which are + behind IOMMU) and passed-through to the guest domain. + +Configure SCMI for predefined domains (dom0less) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* add "xen,sci_type" and "xen,sci-agent-id" properties for required DomU (= "xen,domain") node + +:: + + xen,sci_type=3D"scmi_smc_multiagent" + xen,sci-agent-id=3D2 + +* add scmi nodes to the Driver domain partial device tree the same way as = above (toolstack case) and + enable access to the "arm,scmi-shmem" according to the dom0less document= ation. For example: + +.. code-block:: dts + + 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; + }; + +* For SCMI device access control configure pass-through devices in the gue= st partial DT according to + the dom0less documentation and ensure that devices SCMI management has "= xen,path" property set: + +.. code-block:: dts + + i2c@e6508000 { + ... + reg =3D <0x00 0xe6508000 0x00 0x1000>; + -> xen,path =3D "/soc/i2c@e6508000" + -> xen,reg =3D <0x0 0xe6508000 0x0 0x1000 0x0 0xe6508000>; + -> xen,force-assign-without-iommu; + }; diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-t= ree/booting.txt index 6fd7e4a16b..76eda1b756 100644 --- a/docs/misc/arm/device-tree/booting.txt +++ b/docs/misc/arm/device-tree/booting.txt @@ -844,9 +844,12 @@ SCMI SMC multi-agent support =20 For enabling the ARM SCMI SMC multi-agent support (enabled by CONFIG_SCMI_= SMC_MA) the Xen specific SCMI Agent's configuration shall be provided in the Host = DT -according to the SCMI compliant EL3 Firmware specification with -ARM SMC/HVC transport using property "scmi-secondary-agents" placed in "xe= n,config" -node under "chosen" node: +according to the SCMI compliant EL3 Firmware specification with ARM SMC/HV= C +transport. The SCMI configuration must live under the Xen SCMI container +"xen,sci" beneath "/chosen" (for example "/chosen/xen/xen_scmi_config/scmi= "). The +Xen SCMI mediator will bind only to the "arm,scmi-smc" node that is a chil= d of +this "xen,sci" container; any other "arm,scmi-smc" nodes (for example unde= r +"/firmware") are ignored to avoid stealing the host's SCMI OSPM instance. =20 - scmi-secondary-agents =20 @@ -859,47 +862,53 @@ node under "chosen" node: =20 As an example: =20 -/{ -chosen { - xen,config { - scmi_shm_0 : sram@47ff0000 { - compatible =3D "arm,scmi-shmem"; - reg =3D <0x0 0x47ff0000 0x0 0x1000>; - }; - // Xen SCMI management channel - scmi_shm_1: sram@47ff1000 { - compatible =3D "arm,scmi-shmem"; - reg =3D <0x0 0x47ff1000 0x0 0x1000>; - }; - scmi_shm_2: sram@47ff2000 { - compatible =3D "arm,scmi-shmem"; - reg =3D <0x0 0x47ff2000 0x0 0x1000>; - }; - scmi_shm_3: sram@47ff3000 { - compatible =3D "arm,scmi-shmem"; - reg =3D <0x0 0x47ff3000 0x0 0x1000>; - }; - scmi_shm_3: sram@47ff4000 { - compatible =3D "arm,scmi-shmem"; - reg =3D <0x0 0x47ff4000 0x0 0x1000>; - }; - scmi-secondary-agents =3D < - 0x82000002 &scmi_shm_0 0 - 0x82000004 &scmi_shm_2 2 - 0x82000005 &scmi_shm_3 3 - 0x82000006 &scmi_shm_4 4>; - #scmi-secondary-agents-cells =3D <3>; - }; - - scmi_xen: scmi { - compatible =3D "arm,scmi-smc"; - arm,smc-id =3D <0x82000002>; <--- Xen management agent smc-id - #address-cells =3D < 1>; - #size-cells =3D < 0>; - #access-controller-cells =3D < 1>; - shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem +/ { + chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + + scmi_shm_0: sram@47ff0000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff0000 0x0 0x1000>; + }; + + /* Xen SCMI management channel */ + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + + scmi_shm_2: sram@47ff2000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff2000 0x0 0x1000>; + }; + + scmi_shm_3: sram@47ff3000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff3000 0x0 0x1000>; + }; + + scmi-secondary-agents =3D < + 0x82000002 &scmi_shm_0 0 + 0x82000004 &scmi_shm_2 2 + 0x82000005 &scmi_shm_3 3>; <--- func_id, shmem, agent_= id + #scmi-secondary-agents-cells =3D <3>; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000002>; <--- Xen management agent= func_id + #address-cells =3D <1>; + #size-cells =3D <0>; + #access-controller-cells =3D <1>; + shmem =3D <&scmi_shm_1>; <--- Xen management agent shm= em + }; + }; }; - }; }; =20 @@ -915,15 +924,25 @@ chosen { =20 Example: =20 -/{ -chosen { - xen,config { - scmi-secondary-agents =3D < - 0x82000003 &scmi_shm_1 - 0x82000004 &scmi_shm_2 - 0x82000005 &scmi_shm_3 - 0x82000006 &scmi_shm_4>; - #scmi-secondary-agents-cells =3D <2>; +/ { + chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + + /* Shared memory nodes as in the previous example */ + + scmi-secondary-agents =3D < + 0x82000003 &scmi_shm_1 + 0x82000004 &scmi_shm_2 + 0x82000005 &scmi_shm_3 + 0x82000006 &scmi_shm_4>; + #scmi-secondary-agents-cells =3D <2>; + }; }; }; }; --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Jan 14 18:49:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 18:49:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203755.1518799 (Exim 4.92) (envelope-from ) id 1vg5w9-0003gE-IR; Wed, 14 Jan 2026 18:49:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203755.1518799; Wed, 14 Jan 2026 18:49: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 1vg5w9-0003g7-FZ; Wed, 14 Jan 2026 18:49:45 +0000 Received: by outflank-mailman (input) for mailman id 1203755; Wed, 14 Jan 2026 18:49: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 1vg5w7-0003g1-Mc for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 18:49:43 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c7be48ef-f179-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 19:49:40 +0100 (CET) Received: from BN9PR03CA0788.namprd03.prod.outlook.com (2603:10b6:408:13f::13) 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.9520.4; Wed, 14 Jan 2026 18:49:34 +0000 Received: from BN2PEPF000044A1.namprd02.prod.outlook.com (2603:10b6:408:13f:cafe::49) by BN9PR03CA0788.outlook.office365.com (2603:10b6:408:13f::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.5 via Frontend Transport; Wed, 14 Jan 2026 18:49:33 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN2PEPF000044A1.mail.protection.outlook.com (10.167.243.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Wed, 14 Jan 2026 18:49:33 +0000 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 14 Jan 2026 12:49:32 -0600 Received: from [172.28.136.14] (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, 14 Jan 2026 12:49:31 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c7be48ef-f179-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QsHPCVNKPJUv8EgEs140Q5sty5bIgUnGTe5T7O6NIiV2Kwe254H/sJETPko92Gpk3raODD61Jfj+a23eWE9i8Zt1aUwSDKxVr7DH4RrTd8yk3ARuVkTMazJqz4zRt58u+WHuVZiHVoMTs4fnaEcjsetZTN4R6VW8NqQ5k9J9xBcFL3me8if+7Qu9aQLN9cYOyMnbPeYDtuTOVKbS8mxpQvI0fefzHNJWw03D8xP9zG5La+UouHdIGyjTKt6G6kC+lJ0qmj0ormms754OAxOk/srfcWTe4Wep5Kpy1ffHxoyxkfW8JTU2hu/iCVSQW4SK9AVbX/zw0A5oaMr2JuYe7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=a2rXE0xpYpVD/5RkoyymIGKvNPcJ6yv8N6AT813fJ6Y=; b=rjqxapGGu/roOQv9b33xbMFwS82UT1f/1QuZQn74XTsiN1a+Bg2XOEd3hsbtka/dKCv56HxZcJTzkAW/Yv9W+3IWYJpvQJ2z6PEomNnIeuaeHz9szRu24+djJQtV4g98WFVikmJquF88DpIDAy2c86eRret647FAERZ7Sy6QWj3TWALmXDvXbdAgFsrgD5WRKxapN97Tib8dJ+OEjXPNE9WgKfXTI6DXHxqrFCwfyHDB6okCKKIYlGucP1kshI7sQ1zJwPhpq/mWmtN/h3cut3mocH897XIoLGEUdfDxinxIc+ZVA7wEspAUjyaWAAM+h+pjbbhlCgtIEXpgbE08og== 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=a2rXE0xpYpVD/5RkoyymIGKvNPcJ6yv8N6AT813fJ6Y=; b=arGo6bVaNM1b3OcDvHQLc823kI6mfpuYbs+kON/nkIiwzDp84/ovK2MKo32RuNhelhL+d5+WXiuBUEqzXIw2PQ6MVy8avOlOMfLxA6KWrSm/dhWRKPbqSMwqjOYr9CKcrSRMdyawH0DA0qzOSSg1CeKa3Yn3jlYsj5S5NBzhl1w= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <4091e373-fb1e-4544-9d73-47cfa650f904@amd.com> Date: Wed, 14 Jan 2026 13:49:30 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/6] x86/cpu-policy: define bits of leaf 6 To: Jan Beulich , "xen-devel@lists.xenproject.org" CC: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie References: <4d3a3576-2d3c-42ec-8551-18f1f0982e17@suse.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN2PEPF000044A1:EE_|DS2PR12MB9589:EE_ X-MS-Office365-Filtering-Correlation-Id: 80f95197-2c8b-4fda-a9cd-08de539da8c8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|376014|82310400026|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?N3R5RnM4eXBJWGU4cHBqL2ZiN241VGFaT1pMaEhYMm1hb0VKRko0Z1ByMU4v?= =?utf-8?B?eWdTaFlkWTN5NWplTzhNK1piOUtJL3NLMko4Rldkd2xaSEdJSTNwUGJiQUFZ?= =?utf-8?B?a3lMODF1VWw3ZUwvRU1NSmFFblVRNHNaUVRSQjd5Y2xoQWZXMFNFZ1lQcExF?= =?utf-8?B?SFJWdlpPZ09xVWpwOUdXb3JpcnZ1SS9ad1VtWlo2Tk5MdFJpRHNEYmk1aGg3?= =?utf-8?B?azhqL2NpZ1pnbmMzOFlrVy81dngwWVgvQVp4bm5GRGJ3a3puOWR5eHNHNFdz?= =?utf-8?B?TUx0NVhuelQ5aCs0akdzZSt2NGNLSDllQjN2WDMzOVAyY1l0ZVZQTkt0Rk44?= =?utf-8?B?L0ozcUNGMlJGM01GMklNZW1oR2dzTkZLc3FFa0lCREVFNnNZbmdpWGhtNWE0?= =?utf-8?B?d1J2cUFabmtTWjhqa3Y3REMydmxkVUdKbkhnUHkvNWJmak5vdFFkZ3F1N1NS?= =?utf-8?B?TERmcGh6WGJheHZ4S1NVY3FmUVE4Um8xc1VTVnFqWU5GNFZKaWVGVERyU0lo?= =?utf-8?B?ZUMvSStuRE4zNG5ScXdiU21YRFdaRHQ2UU5WKzExOEpxR0VhNmFMOFNwL3ha?= =?utf-8?B?SjFZalcyV3l1RkJaS2l5b0c5R2piYldGTmtGbG0vMGU5YitVbUcwV0srZldL?= =?utf-8?B?elUrY2ZrZ0hkY2Jaa0E1NFZUdnZRVkhHN042bDNaWFdaVWdLWTJDZjM2Z080?= =?utf-8?B?NGU5NCtrRW9NOTZ0bmthd2ZhTkpFR2Z4Z2huLzFoWkVSK2grRGd6TkxtcWcv?= =?utf-8?B?YUJneWY4bDhrTEVFZ0RnUVZwaG1qUjNRZFllcjVucDMzeHc4U1F6STBlLzAv?= =?utf-8?B?SUd6WU40cEFTVmpIekpkR3B3ZlY1RzIzN2ErZVIvdmdEai81TkdvK3FxSURZ?= =?utf-8?B?bm85TlR5MFNxNGFvYWJFTTloQkxhbWtTVFduRWJ3OWJPV3BmR3ZIWHpuOTV2?= =?utf-8?B?eGFuditGVVZyV05VZUtWa1NGZzFNK054eU8xclJIOVIwOWNzYjl2bEFFMzJM?= =?utf-8?B?QnowU1IyRW5WQ3g0OEFqZE1PL2FwSHAxVnBBbmlac2tMM2VvYkxLTlNIdU5F?= =?utf-8?B?RkhCTG1INGZHMzYxOWJyMCtxVFpuNVpLMkpib0tDL1ZGQVhuQXMzUjM4RGgy?= =?utf-8?B?RnYxd0RISDlwSGdhY1FLTXA5TUpjdGVEQXNKeldQaXlMVDlpM1hGbkxNdG1v?= =?utf-8?B?K2ZrY1k5S282a2FiZlh3cEZoTGRpdTZ4RkN0NWpybEFobXMvNVdyZVRSc2RB?= =?utf-8?B?N09ubzRyVVJsaisweEVoNUhDTFozZjZ5OWlLRVZxbUppVlU4WndXQkNIWUxS?= =?utf-8?B?WDVCVzBlVEFDZThSWm1MTENtTkhMbUw1d2VPdHFZYnhOdHJFOUliSjBQOWI2?= =?utf-8?B?QVE0OWJOUWV0bERZbzJoY0ZuRjl1dmlMdkh1anN6RDBCTXczWXdzTGlwSEhM?= =?utf-8?B?Z0JiMEJmZWhhK25wMllzTjl1c2JLSko5YnFhUGlLYUlFaHpKc3oxdm5mVVpN?= =?utf-8?B?RFgvQS9QQVU1ckhNYW5YSDkvMnZ4MTFiTjVEcVl4QTN3L3VaV0VqbURMNGVN?= =?utf-8?B?WEFpL2NhMi9pdm9ZVWZSQTl4YzMrWVNJRnhCVGNPZWNWaWVabTA5dlExR3No?= =?utf-8?B?RnkyakJNL2RXeFdYSXVDOUhGdmU4UmowclFpRXY2K3lQU0VYQVRaMVFIRU5k?= =?utf-8?B?MFN0b0ZKWEExTDZPQUw1cGJJZ0FxNVVVL2lpUTA4ZXJNRFZoSjQxcCtXbDNB?= =?utf-8?B?bWNRVVRPaTBHam1ERnB6aHdteThobVVReVArQlozS0VML2tMNWQ2ekhhMkNP?= =?utf-8?B?VHJITzFxVnVKY0J3K3dIUkpuZU4zalZSb212Z3IxSkFQcEN3WURmTmFLa3Jx?= =?utf-8?B?QzRyS2E5ZHJFL2M0ZUplY1ZGVnhhTGluc1pibTJ5ckx2NUZKdGxicGd5bmNP?= =?utf-8?B?dHF6MXZhdHQxK0VoQVFKUmdYMlhoTXJwSCtxZFAreENYaHNlelpwbnZkWi9H?= =?utf-8?B?VnVzQTlLeExRV1U1MjlncHZaRitpVTAvVDRQYXFhanFYYVZzRFBaV0ZZTXpz?= =?utf-8?B?RzR5bjgxaUVMejRpeUY5THpQZ1lWRVJVbWpwRW1MUWYrVXpyTUQzeXdXbFRi?= =?utf-8?B?ZXhoOUt5SG5yWTlXbFljcHh0T2cySmRyZzlHY0w0aTFDRjJZVTd5MllVNG1u?= =?utf-8?B?TDhFeFR3SC9VZDZZRTUrOUE0L0s3TWViU282V3Z3U0JvYVRSKzNKTHlCbWhI?= =?utf-8?B?ZUY3L0NLdGpnU09mWnNMS3k5WEtRPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2026 18:49:33.9455 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 80f95197-2c8b-4fda-a9cd-08de539da8c8 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN2PEPF000044A1.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS2PR12MB9589 On 2026-01-14 08:43, Jan Beulich wrote: > ... as far as we presently use them in the codebase. > > Signed-off-by: Jan Beulich > + /* Leaf 0x6 - Therm/Perf. */ > + union { > + uint32_t _6a; > + struct { > + bool :1, > + hw_feedback:1; > + }; > + union { > + uint32_t _6c; > + struct { > + bool hw_feedback_cap:1; Maybe with an comment of "/* aperf/mperf */" since that is probably how it is better know? I was confused with hw_feedback above which is different. Actually, looking at patch 2, I'd prefer leaving this named aperfmperf. While not the SDM name, I think it's a more common name for the feature. Either way (but preferably with aperfmperf): Reviewed-by: Jason Andryuk Regards, Jason From xen-devel-bounces@lists.xenproject.org Wed Jan 14 18:50:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 18:50:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203761.1518808 (Exim 4.92) (envelope-from ) id 1vg5wZ-00051P-Pj; Wed, 14 Jan 2026 18:50:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203761.1518808; Wed, 14 Jan 2026 18:50:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg5wZ-00051I-NE; Wed, 14 Jan 2026 18:50:11 +0000 Received: by outflank-mailman (input) for mailman id 1203761; Wed, 14 Jan 2026 18:50: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 1vg5wY-0004G4-KA for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 18:50:10 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d8890b2a-f179-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 19:50:08 +0100 (CET) Received: from BN0PR03CA0032.namprd03.prod.outlook.com (2603:10b6:408:e7::7) by DM6PR12MB4156.namprd12.prod.outlook.com (2603:10b6:5:218::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Wed, 14 Jan 2026 18:50:00 +0000 Received: from BN2PEPF0000449F.namprd02.prod.outlook.com (2603:10b6:408:e7:cafe::64) by BN0PR03CA0032.outlook.office365.com (2603:10b6:408:e7::7) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Wed, 14 Jan 2026 18:49:57 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN2PEPF0000449F.mail.protection.outlook.com (10.167.243.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Wed, 14 Jan 2026 18:50:00 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 14 Jan 2026 12:50:00 -0600 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 14 Jan 2026 10:49:59 -0800 Received: from [172.28.136.14] (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, 14 Jan 2026 12:49:59 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d8890b2a-f179-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MNp2DK4j07vqhfohb5AgB2NBX+ZbM/GlApFe8KyvrlC4hObUYSdKSstZeqNTe4uS4KdVXL7we/KLbjkzimfkG3pIQW6Bt6eM/kbhnWLT5OqLDkv4InuEKuHJPx0jKDmAHQCNqDFJM1EBggmk5M/YMiNa+hbJMc/hS78HUgckbGqRVvGdZE+zaspvQV8svf4GGH2vKiG+s3SDSn7uMnkQYHcFzMuPxrxxyjSzZWtU/yR2UdcZEUDbB+TzM2Fo9lChzxQM+893qAIDUo8fgslJrdLGoYXNFK8xd8XJ5Q6e7i3v7le95G8ndF9nRlTjGj4ID4a0V0plFICZV50fRj63QA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WgDTmPXvcD2+YrtQy7k5rE7ZgRJqltpcxKpIxIYbBBA=; b=V00kr6XErA4C/4TzxahjMjYMp88HDKmEW7x8zGM+moq2O8wyBV3Lye8dfDuATSUjIMiNYTN8bNHnzU+b7puHKMgT+oAX5KrovWoCCHgl4u46hqDpOEwc0x04lzvnEgOgM+0d+ZC93klr4oW1dLb46TMApIJIhHapErDYkToulDKGJvXVeS4zFTiDyczr/4smY7StOLngNQSrhaK7oBD+8hRh85A96igY8PcxPfbdbekTCD5+P610S2xWBRa+yWqfCa+Xz8gVuDyG4TRHWj1JIjO/spSUDt2xLqfZOc8KkRb+5w/ezmDGDiiPhryGbJBAamfraFgNZDSnfefSohoutQ== 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=WgDTmPXvcD2+YrtQy7k5rE7ZgRJqltpcxKpIxIYbBBA=; b=tadRTbYD0JcwjysVcDhMtPKKhJBP9w9717KdT0lOe5/s2dEd45warLEbaAMEs50m1ATzQZ9WKJRoP0de9nC7GPXiFHpYFKjo0c93drjtI1pj0nrr2XJeKwIv4Rrb1ZF6r3erJMazellJzC4lqGLSSt8BmKse1Ir8JuIVV17jnSQ= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 14 Jan 2026 13:49:54 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 6/6] x86/cpufreq: use host CPU policy in HWP driver To: Jan Beulich , "xen-devel@lists.xenproject.org" CC: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <4d3a3576-2d3c-42ec-8551-18f1f0982e17@suse.com> <7d52c0cf-c097-4c32-9af6-5044727c3ef8@suse.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <7d52c0cf-c097-4c32-9af6-5044727c3ef8@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: BN2PEPF0000449F:EE_|DM6PR12MB4156:EE_ X-MS-Office365-Filtering-Correlation-Id: cf5cd258-70e1-4f5f-c326-08de539db88a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700013|376014|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?cGhyc0duMms0QXJ0VEpxcGVqUjh0RFNaazVaZGxGcEViZ0xPcHZlTE9FUzVm?= =?utf-8?B?MWN6NHpTNzBCQW14czBJZ1NiaUswN2RBb3JSUTVvbkl1bFhoK3V3UFpsS3p1?= =?utf-8?B?UUhacmxZVndPK1N6RjZjaTlGVGg1SzhJWXV2allZTEpnNWpYSks2aUpQUndv?= =?utf-8?B?VzlIb3NRN1I0ZUZvYTdJalplSEg1UkppS3hvczJFdGlQajdjS2pjcUNESXNz?= =?utf-8?B?cG12VlhZSjQ5ZGs4dk1oY3lOd2hjNHc3VXhwbTYwbC9JS0pEN0JHMWNFWU1s?= =?utf-8?B?YS9oMFZNRjlsaktaL3lvVlpSSFI3eDkrVGhqZnJRQ3NiZEtYalVnL1hGT3Bh?= =?utf-8?B?MWdreC9hNFlWVEg2ZytydVRiSHNVRm94TDVhdVFnZE9mSWp0Uno2L0dXRENh?= =?utf-8?B?ZnFUelh5U1VqaXFabjltNnFLQ1hScm95NXhVUWRSOXRvc3VqRjhWYkZyN0Zy?= =?utf-8?B?VmhpMTMyejZqV2k2WjNNRXRJdnR5dVZINzZvejBEZ09od09yTkdCeUQ2OGZp?= =?utf-8?B?U1loVS9vK3dWT2p5NTlhM1lpRUhDaEpIekRpSkEzUW5ieFFYbTFRV1VOKy91?= =?utf-8?B?ZG8yZXJBQmZnVUZvSnZxdXdmUW1MR2JYVzlLRk84UnhoaUNnSk5JYTRGdlV0?= =?utf-8?B?ZHFQRURWZUdTd0dMK0VEM2wxTE5tNkJ0ZHdNUlVhNFRBWWQ1Tjg0c0d6Wlp0?= =?utf-8?B?aTFubzhPYUMraEh6bllZb1ErV3dzNlMzQ2FmNGJ0VDdKU2JSNEJyeUhLOXQ2?= =?utf-8?B?WWZZT1h6cUYyTG9DQ05kMUs4cUxyV0tGZmdKR3A0RVpwcnk0YlU0U2ZmVldD?= =?utf-8?B?clFqNE9vQjg2SEdJeE1PUklOUUVwSFFjUkJ3ZDRvTWh1eXlLdGcxdHdwdkRy?= =?utf-8?B?ZndQQUlaTXpiNzdnUEVtZHZOeTJZY0pQQUdyTHNGcE4zSWljamtNZ3Z0T2JY?= =?utf-8?B?K0pjR3NkQUZ0Z3VDRVRiVTZxN1RzdkFOOEh3S3NjUS9ocVlhUFZnZE8xVWRM?= =?utf-8?B?anhhckJsa3FLbFQyZ2hBczhRZmdmS082VldQblJZYU9mOXlPb1ExZlZiQzR2?= =?utf-8?B?bXBiK3VWYzZNNjdaL284SXZKL1g3d3NYMU5oL1UzS3FPSU1mR3hwUFZ6Y2pU?= =?utf-8?B?OWYraHZkaVUremFValpVbnF1aHllMk56Zy91Zk9JclZvMndkS0xZUExDYi9G?= =?utf-8?B?VmI0d2pTWXJLTlkzMjN0Z05Oc05LNW5BSnozTWlFdEJ3ek9zS2ozSzlBdzRp?= =?utf-8?B?OTRWUWt3SEhIb3krbHpwYnQxVFkrWUVPb016K0hkcWRTZi9vVC9hZ2xVbEdB?= =?utf-8?B?YXo3V0ZOQmpRS3doTVY4ZERVTkJ4T3lRcHkzY0FhY3RnNzh4ZDJVVE9JWGkx?= =?utf-8?B?K3R4R1JkWWNHTUt0UnV1OG5CcVoxdTFIa2xHa1p0YmtLOHRrSFcwN1NOTnBR?= =?utf-8?B?U0lvald3SjJiaWcweDZmYXo0SzJpL24yUWE3V0hEWi9HZisrZTd6MWNwY2VB?= =?utf-8?B?UmJoSTF6SjVRbXpra0pNL1gvSkthalBDaUw5aHJnNE14ZkhNenEzWmRlM1hH?= =?utf-8?B?a2tuZUxlcU1RNVUrSDROQmRZbmpaZlhlTGhkVDljMHM0UGNjbGcvWmlWOThs?= =?utf-8?B?TlYveDAxUit3dzhwYlowVldvMERWbkZQaEdPK0RwdDEvRUkxVmtxeHZGakRF?= =?utf-8?B?YzVMUFJlbXgrNnRsU1N4MEtPaTdBWnpBLzd2V3d1b0tOL3RRNDFGekNpNnFH?= =?utf-8?B?azRnSVdCRXhrVU54WW5zRzhkUHcwVTdFbklWV2kzYkdUOWFrT2pTRTZSMWJj?= =?utf-8?B?aENFR2daNjQwMXJudm9IL3d6V01IRWNBbFU0NXpzKytWZ0szNkhjVFRUNFJk?= =?utf-8?B?aXhwM1Q4RCthNTVubDliSnZXZGFSWnZFWjhKLzRuTkRyTmVMM1k2dURjekto?= =?utf-8?B?WGxKNnVRMCthZFZaUDhtcGs3a0xHeXBBVTY2NEVtZHdNYzcxNThSSXBpRHFW?= =?utf-8?B?c3pETGx5OGlKZTRCa2FISnlWbndDWlpBNDYwZTcxMGhycXI2WVU3d09VZnFk?= =?utf-8?B?S0U4N0ZNMEJuWDBsME1LY3I1NUFqcysvT2EwQmE1dHc3QkFaYmlFSGZBMXRX?= =?utf-8?B?RFFsNFExcjBUdmFKMWF1TjNVREZCMldmK0RMSzlwejlnd0ZwZllYSjl4QStL?= =?utf-8?B?dElUem1VaWZ4bmoxZ1p3UFlPZ0c0UXZQVHNyelRVNGtEOTVJTkR4MXpLMVBs?= =?utf-8?B?ZENjOE5OaUkvQlRsZWI5UmlLOHhBPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2026 18:50:00.3822 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cf5cd258-70e1-4f5f-c326-08de539db88a X-MS-Exchange-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: BN2PEPF0000449F.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4156 On 2026-01-14 08:45, Jan Beulich wrote: > There's no need to invoke CPUID yet another time. This way two of the > static booleans can also go away. > > Signed-off-by: Jan Beulich Reviewed-by: Jason Andryuk From xen-devel-bounces@lists.xenproject.org Wed Jan 14 20:41:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 20:41:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203827.1518819 (Exim 4.92) (envelope-from ) id 1vg7ff-000266-EA; Wed, 14 Jan 2026 20:40:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203827.1518819; Wed, 14 Jan 2026 20: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 1vg7ff-00025y-Ao; Wed, 14 Jan 2026 20:40:51 +0000 Received: by outflank-mailman (input) for mailman id 1203827; Wed, 14 Jan 2026 20:40:49 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg7fd-00025s-MV for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 20:40: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 4e60c841-f189-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 21:40:47 +0100 (CET) Received: from MN2PR04CA0004.namprd04.prod.outlook.com (2603:10b6:208:d4::17) by DS0PR12MB7725.namprd12.prod.outlook.com (2603:10b6:8:136::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Wed, 14 Jan 2026 20:40:39 +0000 Received: from MN1PEPF0000ECD7.namprd02.prod.outlook.com (2603:10b6:208:d4:cafe::80) by MN2PR04CA0004.outlook.office365.com (2603:10b6:208:d4::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.4 via Frontend Transport; Wed, 14 Jan 2026 20:40:39 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by MN1PEPF0000ECD7.mail.protection.outlook.com (10.167.242.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Wed, 14 Jan 2026 20:40:38 +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; Wed, 14 Jan 2026 14:40:38 -0600 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; Wed, 14 Jan 2026 14:40:38 -0600 Received: from [172.28.136.14] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Wed, 14 Jan 2026 12:40:37 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4e60c841-f189-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=h4hS3Z+2an1laxi9cJ8LtLX0VsFk4HwBS4WPkL+igLefiipexMwUY5kr/t6HsWZCHAhYVubdPLJfaZo5SQ4Wi+IgWIT2c9LmPmK8GXKMwSEqIEhC6DaNFF7qDXuJlagt3EN+iRViMQ4UDYYwVLe/SABw8Ebkt9T6JJjip9QTXtzEYHnqVRJkTki+QGQl75T/9TVDCMjMEczrK4djACvDdnGoCY892ZHvrVB5HKu0Lacqp9wv1bpBPg/ekL1KxkK6maqSUqZFqPK0kFj4zAsTv+Dhwi3aT4WBjebcuVP9gQ4OcImjWi3Op437qXWBASxzozahBjxouqJVfKAxprALwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=enNkDqd3q5BKhxWeYe0DgnTS2QiQY3lBAcyP4VvJLj8=; b=BFd+FH6zwWaPu+dlevU3bM5dCpYx17XA5ocELfEFRjHYCpMIghOqRJq0gc7w6PH8+GN2qgW67OlH2Kte0EfowM/Yj8FUbtXA5AGmw6TTPxQ2ts2AwL/z8mFIYbbbJyJDkI7CDnikEWx8yEJniafrmxckPYHPPfj2ekEaywdXJWd00htTUzlhgxyp2PdwJtSKzB56xt1XdZjOSQX8CULJrTCo+BLG/fv7DwADxiye/GvovT71S7hy4lAAtFFRdazSYgRNeO203crQb+G+LqcxErpv7npWcL3dycqPvLGIJ7yg1Zsel7KnvZhu8+HcA2mUvdjii5Rs54uKphGwCk2QNQ== 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=enNkDqd3q5BKhxWeYe0DgnTS2QiQY3lBAcyP4VvJLj8=; b=Z1HAkeDpktxfw86QCgeY7jGDPNyOJnp+yFXZnzyu5nBzv5Phsy1QjLtfhFXK6DXoTcEisi2NP6jMc4A2jkFQQQXhtyN563rgpEErZLqwZDR/3pzSWEcyaDUo3Fo8Y9apCKTCSiCiNEzW0DGewBQF17Ne5nHGJcwUMZuIYG68NaI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <87de17df-0aed-4ce1-b556-f93a381b66d3@amd.com> Date: Wed, 14 Jan 2026 15:40:37 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] x86/mce: use offsetof to determine section offset To: Nicola Vetrini , CC: Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <350bd19ec4b0b190911d748df6ec92c626e7151a.1768415160.git.nicola.vetrini@bugseng.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <350bd19ec4b0b190911d748df6ec92c626e7151a.1768415160.git.nicola.vetrini@bugseng.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: MN1PEPF0000ECD7:EE_|DS0PR12MB7725:EE_ X-MS-Office365-Filtering-Correlation-Id: e3d396a8-9c6e-4517-872f-08de53ad2d6e 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?bElXZ1RRYkwxWlp2QzZhdjRVTmN5dnVlaXpMalRhWmh1MjBWN0RES1p3OHNy?= =?utf-8?B?c3cyR3FZN2hZclpiU1VkamYrZ1plVklSQndDSXFSQmE1b2d3OFhiejhab3I0?= =?utf-8?B?N2J4ek1pamh0bzFhT09oSFJIcVJYSFo4eTFrWGRjOCszSmVMRUhqRW5yZG4z?= =?utf-8?B?UnFDVUVLVU9yUDlBU0hEdWxLck5oT2VTSnFlemNaU0wyTTJ0aFlqVUswUGV4?= =?utf-8?B?Wm5OMDVVRG5yU3pvQ3BuRzZZSENBc2NtZ0FPY0ZweTdwQmRUWk9QT0M1TEh3?= =?utf-8?B?QnVSTTBvSDZXNUdXWmxkOExTMEpUWER6MlR0VmVla2hKL21LQUcwdE9BTGtq?= =?utf-8?B?anA0Y0VQTW1pVUVKU2w1cTNSL0oyRFI4Rk5TbzY3NGpTNlpwSzgzSzBpRG9i?= =?utf-8?B?UmhWQXpINjRDUWdnZkxPMFlYUmpvOTdHWHNpcklXOS9Dd3ZGZFp3SUdhRS92?= =?utf-8?B?UkNwZVZSalJ4K1RzYTBoeDlVQ1hYbFV2SFcweXlUNlRuQ0g1K2YybHhJOEl4?= =?utf-8?B?KytVaVNrSGlJdFk3WTdZTWlBbDZTWlNkQVN2eno5NFdONGQxM09xQm9RQjlJ?= =?utf-8?B?YzZLWGxjSDJRVXJNMmd4NzJTVnNhSHVzV3BpYjdUdHhIY2dVSnpHMzJjWkU4?= =?utf-8?B?bm4xSldRM0ZtSGtvcDluZGJJUmpBMVNjdmpYeWJqdkJVQUw1ZnJqaTMwMDlI?= =?utf-8?B?TS9RQzJHd3ZZT1lLem5rVzNzUW0zMzlpTDZOaVBVaTZtU3hFTkt1WnY0N1Bt?= =?utf-8?B?QlVsait2L0NPREV4a29uTkE4MDlERTcra1pNUlNGTEFTa1ZlNFJCbm43RFVG?= =?utf-8?B?Kzg3WlRaRGptdXplMlNDK1l0dStFM1ltSUhjd0drQkIvcFIxZk96YW9oNEpp?= =?utf-8?B?VHA3QVp0SzBTZ1NxOXBxN2ZXQzJ0MGtzY0NxYWZ2d3hSTUgvbkZ0SzN3UU8v?= =?utf-8?B?TlBTTHRNRVhsSkpocDF4WG9JL2N6cHZBRTdESVBPbHN4K3JLVTFBSlZOclVw?= =?utf-8?B?cU5pTnE4RlMrejh1RHM4UkNJZitEOS9PMUVxNlQ1YVBhMUdwa0wyMFJpZEdM?= =?utf-8?B?OHoxV1R0QWE3U2Rxa29xNDI4VW9xbVR5MjUwNTVrTTBBVEwxTGxsbXJsMEtn?= =?utf-8?B?eVBCNENHQUk5eVh4cFpOWGtaaDlqbWVTeTJHMTRxczM5MU1HUlo3R2lyVFds?= =?utf-8?B?clNxbXZCZHV4WHRhMWl1QnRPM2FIOE1QV0hqNXpaVXR4eWtoTkpmL3l1TUFJ?= =?utf-8?B?ZG9icWkxQ1lvU0ZnYW5KUUk5QVQ2WmpCU0lJN082OWxrVnd0dDUzeWM5dU1B?= =?utf-8?B?SE9CdzN5RjN6YktXdnJLWEdZL3krbW14UVMvSktIcnBRdmRSS2VnajUrczk0?= =?utf-8?B?ZnRZY3o5R2VOMGoySXQ1SndpM011TGY0K2JuRUlTTlpmVnJZMmtsdGdkOHhI?= =?utf-8?B?MXdrdCtSeHUrVjZxUCt3dkZWZ0xFWkV3YXYvZXdmTllxRWRDY2RYMjArcEwr?= =?utf-8?B?S1BVM1NFaXdtYUxpNEN5bDdzWE4yZFNMNkNQUjhDVEc4OWN4ZldsL04ySEtP?= =?utf-8?B?SlZGcDd1NmVhOXdERVN0cFBSV1NsMHNlMUFMbFhhdTVINEZmZjRkWTNJc29Y?= =?utf-8?B?M0tQOWEvOFNNdXFzZU1QcVlHZzZXNG1jOTVSNjMveXhwZXRrR3o0MzJOeFlv?= =?utf-8?B?S3g3R2grclZPbndCSDB3eVJpclZEWnQwa2dZaFdtcUtURlpRRzlNb2pyMkVt?= =?utf-8?B?KzNDU01yMlhIUWVuZFRFRUhiNzVha0JCMkZLMjJlVEJCZU83ZW9paWNoaGNK?= =?utf-8?B?WCtiNVdnUXIrbFUzR2hPVVlCSWJyNE1JdHZGSXZoWUxZY1B6Q0sxUUZJNTVT?= =?utf-8?B?N2Zzc09OZTRnNkdIQXNHYjQwNDdMNTFHRFJOR0llR2d3a3V5cVhodlVPcUs5?= =?utf-8?B?ZXF2ODNwSSs2cXgyZW1rYnRCdFpmRmFXS3c4M0RsamF1RHFWVnlGc3hEZ0Rj?= =?utf-8?B?b2RjY3ArZ3BvU3ZsU2FkMjA4RVFhcnp3YVZQVXMwRVE5MXNLa1p6ZTdEWHM0?= =?utf-8?B?UVo4MHRnZjMyRDBwODJVV0luS3drV3JleHBoTlB5aFcyaGpTV1VNalRtOXFV?= =?utf-8?B?ZHFUdzZoNVdPNzJUekJFQmNSZ2NIalZNb0x4L2hlempmU3h2WjhQUGt1aE0y?= =?utf-8?B?N1FmVFBPRnRreVlUbU9nblVrczF0VXRpSklRYmI4aHpiZHpWaGg4U29iVXpV?= =?utf-8?B?cmxBYkgxcXRuNEd0aDlYYmN4TFRRPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(82310400026)(36860700013)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2026 20:40:38.9421 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e3d396a8-9c6e-4517-872f-08de53ad2d6e X-MS-Exchange-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: MN1PEPF0000ECD7.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7725 On 2026-01-14 13:27, Nicola Vetrini wrote: > There is no reason to use pointer difference. > A violation of MISRA C Rule 18.2 ("Subtraction between pointers > shall only be applied to pointers that address elements of the > same array") is also resolved because the object to the subtraction > is applied is not an array. > > Signed-off-by: Nicola Vetrini > --- > Found while randomly browsing violations of the rule on the allcode-x86_64 scan. > --- > xen/arch/x86/cpu/mcheck/mce-apei.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/x86/cpu/mcheck/mce-apei.c b/xen/arch/x86/cpu/mcheck/mce-apei.c > index b89502088243..21aabe2027d0 100644 > --- a/xen/arch/x86/cpu/mcheck/mce-apei.c > +++ b/xen/arch/x86/cpu/mcheck/mce-apei.c > @@ -74,7 +74,8 @@ int apei_write_mce(struct mce *m) > rcd.hdr.record_id = cper_next_record_id(); > rcd.hdr.flags = CPER_HW_ERROR_FLAGS_PREVERR; > > - rcd.sec_hdr.section_offset = (void *)&rcd.mce - (void *)&rcd; > + rcd.sec_hdr.section_offset = offsetof(struct cper_mce_record, mce) - > + offsetof(struct cper_mce_record, hdr); "= offsetof(struct cper_mce_record, mce);" should be sufficient since the offset of hdr is 0? Regards, Jason > rcd.sec_hdr.section_length = sizeof(rcd.mce); > rcd.sec_hdr.revision = CPER_SEC_REV; > /* fru_id and fru_text is invalid */ From xen-devel-bounces@lists.xenproject.org Wed Jan 14 20:56:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 20:56:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203846.1518830 (Exim 4.92) (envelope-from ) id 1vg7ul-0003vE-SI; Wed, 14 Jan 2026 20:56:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203846.1518830; Wed, 14 Jan 2026 20:56:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg7ul-0003v7-Nk; Wed, 14 Jan 2026 20:56:27 +0000 Received: by outflank-mailman (input) for mailman id 1203846; Wed, 14 Jan 2026 20:56:27 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg7ul-0003v1-1A for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 20:56:27 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7cbbc244-f18b-11f0-b15e-2bf370ae4941; Wed, 14 Jan 2026 21:56:24 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 42CCB4EE3C1D; Wed, 14 Jan 2026 21:56:23 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7cbbc244-f18b-11f0-b15e-2bf370ae4941 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=1768424183; b=TUN+L978NZJ09OBLpYrsWLLLXf9lpcLlLrkwiKdVK1BGgCAjTmQ27GlCuyqJ3t3oBEI8 IeHhviwhm6C2E40BrzDw1z72fF+fEMfZu9Y4AueQZvye2Z0CvEk6Os1CTJ08GEyLre2l4 xBSOBSiS7P/RsFpOHFPtISMUztAaq303ACBjE8oC9j/XPmhH1u4bkWgPX3qMiaYB5J9a6 NZ/lk2vUJu7Tzxr4NjV9UcGZS7+05gzdxCrrwf0pGf3OYcitYKfvfC3UCuLIpMKnRgvaT MvrCRbssSgcrJeSbDhBHq+sRO/wD4OxxV+0bpfXEzF5Xg7hi/w8U2TRAI4V8YvFI/Fq5G nqXXaL1VP/o9vxqEAdlHSBhRHQulyjh1IG7J9TfquXDDA+noqfKl32vNtuXVD7Xo4nt77 ubC/rHOdPFw2VRrrZEhUGXNrsAZApIOCSKnJDU8FE1DpGLrhMy5MPcHRlKSeTG69baVsd 5RpLzJb71m/3TSUCg/Ld0xUYjfhUUXmTT8hizjFk+bnKE/BVk3EuIZDJOX65QeKEtRAtK RidqsUV4A/tX12h4GfAhE9dA1Bf2y8waRsdhRtQNyiEqNiJ3pfaz3YhocVYPf6+7GAg/d O4iJdT5rmOJbvfHn/hdwuS0Acjqts5Vda//xC8km8nfi3k/PrsvcdkX+aDU4koU= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1768424183; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=ntQkDCkn5ceckBt3E0faKoXB378Nkvml9jXdJFgGqf0=; b=o9oDRVk11tM0XLhGUtVnE6iSjV7dCdCzpiQRIx23aJS3g3wK3n+le+zNYjEA4ntWew7I 1v+OODyRFDhl1IrsqCqY7tL7Pd9H0yV0QVwpnoa75GpYPLCGc/u0dv1k+9f1S3PRD4mbh jfUAEWWa3ivDx1pA3r+eEDivKnzAO5zIJFBupF4mZS/QemFAcATHCQoAcXswp4LvkIETt f4+MDb6S1Q14IL5f11LsrA+i5VQvQq3m5gY1djB54PJ/5EsiujuGZoVvWw1kjM3TQ8sTj zOf6w38MZeJuAOKFBouT3rRIwj5Jj3hK+6bV71WXM4LjsbCe0DmR69Wij4wCBkSAgeo+6 2g+D0wEMzZW+aRHba+97yH6Bxr3wb+PVZU2MVBfr4fcQlflqNNvIm4DbcTkIjw6MVYkqC iyaIFRRGIx6nZCFgZIgV96wt+JLlI7iUa0d6fVlP63ujoYSWJ/jCVseyQGFVdWmXPsux8 A1GKHPjzNYURzTFSAIrH3a/9CHc/3wjMiNkz4sMeQ+SI9NEMDkBsVejSwcYtVf8RLnbq6 qUCAR/A2sHRbsZ1zD2IzuP4CFfACBCvZlKOiTSegw1e0dTUlpE+3bAGQCLiLqVc49kzTb SzL9Ysd3Fqh211aNhyroWkNU5A2Ad5QJuu8vyK1mAsj8La+n3Ua2xUlOQuucDAc= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Wed, 14 Jan 2026 21:56:23 +0100 From: Nicola Vetrini To: Jason Andryuk Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [XEN PATCH] x86/mce: use offsetof to determine section offset In-Reply-To: <87de17df-0aed-4ce1-b556-f93a381b66d3@amd.com> References: <350bd19ec4b0b190911d748df6ec92c626e7151a.1768415160.git.nicola.vetrini@bugseng.com> <87de17df-0aed-4ce1-b556-f93a381b66d3@amd.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 2026-01-14 21:40, Jason Andryuk wrote: > On 2026-01-14 13:27, Nicola Vetrini wrote: >> There is no reason to use pointer difference. >> A violation of MISRA C Rule 18.2 ("Subtraction between pointers >> shall only be applied to pointers that address elements of the >> same array") is also resolved because the object to the subtraction >> is applied is not an array. >> >> Signed-off-by: Nicola Vetrini >> --- >> Found while randomly browsing violations of the rule on the >> allcode-x86_64 scan. >> --- >> xen/arch/x86/cpu/mcheck/mce-apei.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/xen/arch/x86/cpu/mcheck/mce-apei.c >> b/xen/arch/x86/cpu/mcheck/mce-apei.c >> index b89502088243..21aabe2027d0 100644 >> --- a/xen/arch/x86/cpu/mcheck/mce-apei.c >> +++ b/xen/arch/x86/cpu/mcheck/mce-apei.c >> @@ -74,7 +74,8 @@ int apei_write_mce(struct mce *m) >> rcd.hdr.record_id = cper_next_record_id(); >> rcd.hdr.flags = CPER_HW_ERROR_FLAGS_PREVERR; >> - rcd.sec_hdr.section_offset = (void *)&rcd.mce - (void *)&rcd; >> + rcd.sec_hdr.section_offset = offsetof(struct cper_mce_record, mce) - >> + offsetof(struct cper_mce_record, hdr); > > "= offsetof(struct cper_mce_record, mce);" should be sufficient since > the offset of hdr is 0? Yeah, makes sense. Given that the struct layout is coming from the UEFI spec it's not likely to change either. > > Regards, > Jason > >> rcd.sec_hdr.section_length = sizeof(rcd.mce); >> rcd.sec_hdr.revision = CPER_SEC_REV; >> /* fru_id and fru_text is invalid */ -- 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 Jan 14 23:42:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 14 Jan 2026 23:42:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203923.1518839 (Exim 4.92) (envelope-from ) id 1vgAVK-0006sA-15; Wed, 14 Jan 2026 23:42:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203923.1518839; Wed, 14 Jan 2026 23:42:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgAVJ-0006s3-Ug; Wed, 14 Jan 2026 23:42:21 +0000 Received: by outflank-mailman (input) for mailman id 1203923; Wed, 14 Jan 2026 23:42: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 1vgAVH-0006rx-C3 for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 23:42:20 +0000 Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a84ee0bc-f1a2-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 00:42:16 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a84ee0bc-f1a2-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1768434134; x=1768693334; bh=cLPq9bZJS+JUThg6WIQjstfs+bSetaFzbcl08dElefg=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=IW5D+PCxYLVdiP86Pz7uUv46fIUYUsVUqddvsNRjkTePcd3QiDeEE1MHxJ4RdiTCZ XG93lj/bi1o4lTX+v90qUGcZD7aC1KLHaRylMUIFVBKwMCsV95NVK0LlqyMiptI9dF zpOkCDie1Xk3LYQxL0qoNiXu7et1nDXXajDeYDW5unF9KS+6lIBYDpanPIKIjRavrz BC/YlAFLzs8x0yTMn2ZLgZ4DaxTyqRNHhbse7aijcRxM+j65twWq0efdJcGEEL0nin rYiX94NM3l0Ftg9oVpEdJWmhkuU+vmnC8h2Hr4G6NCMXsytLIc8+S92Pf4Xb7Oo5+T ul1Lix59UDGHA== Date: Wed, 14 Jan 2026 23:42:12 +0000 To: Jan Beulich From: Milky Cc: "xen-devel@lists.xenproject.org" , Jason Andryuk Subject: Re: Cpufreq drivers not working on T480S Message-ID: In-Reply-To: References: <7dbd26d1-0d9a-454f-90d8-5a7f3d8e12da@suse.com> <8a2125c7-c5ec-4be1-a7a5-61b2936cc90f@suse.com> Feedback-ID: 171106842:user:proton X-Pm-Message-ID: a87867e7ad09838aebac1fcafbc67dc4b8ff44a9 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wednesday, January 14th, 2026 at 11:12 AM, Jan Beulich wrote: > > > On 14.01.2026 11:58, Milky wrote: > > > Just wanted to update this thread to say that now another T480 user (th= e T480 is a very similar model to my T480S) using the release builds of lib= reboot (as of 26.01 RC1) also has the entries missing from the ACPI tables.= That discussion was here https://codeberg.org/libreboot/lbmk/issues/394. S= o this confirms that I'm running a standard libreboot, rather than a bad bu= ild. > > > > Do you think there is any way to avoid the underclocking issue with Xen= on such devices/firmware? > > > In principle there is, but in the absence of ACPI data that means holding= model- > specific data in Xen. Which iirc is what the intel-pstate driver in Linux= does > (using ACPI info nowadays only as "auxiliary" data). But I may be wrong t= here, > as it has been a long time since I last looked at that driver. > > Jan In that case, would you say this is settled now? Would it make sense to rep= ort back to the QubesOS community that librebooted T480/S will run underclo= cked, due to the missing data in ACPI tables and lack of native support in = Xen? This information is important, as the device is only barely usable. From xen-devel-bounces@lists.xenproject.org Thu Jan 15 00:15:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 00:15:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203934.1518850 (Exim 4.92) (envelope-from ) id 1vgB1Y-0002z1-9V; Thu, 15 Jan 2026 00:15:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203934.1518850; Thu, 15 Jan 2026 00: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 1vgB1Y-0002yu-4y; Thu, 15 Jan 2026 00:15:40 +0000 Received: by outflank-mailman (input) for mailman id 1203934; Thu, 15 Jan 2026 00: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 1vgB1W-0002yo-6I for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 00:15:38 +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 4b38d987-f1a7-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 01:15:28 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 84F3740600; Thu, 15 Jan 2026 00:15:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5611C4CEF7; Thu, 15 Jan 2026 00:15: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: 4b38d987-f1a7-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768436126; bh=l9alCJCT/vpCtrOLevRubwd+Mx/jfZHgoIsNZfh0rks=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=aVzmSnPuw39iNNTgUZNRfKYIBbjeBe/5r/yvvpeT6OUHY0gBko5p9yIBSFMOypcTW slaVMS3UBgHu83iFYViWTL3YBWHg3MWcDrnK1Ke7aCQT+KBRSB1QKZdIIfyHDe7Riu Hr+ZtwabU6h2eQO1pFzEB0h0ozjupfx+aC+oQELAixcelx/t75eR+SSNcCgtSTV/fe YqHzI1PyGclIkBO/XeBDW0eavyJzH+rnlza3zLdR66RtHhSPBXJLn3zn4elNhYzBzh KlvP4EQP/xUsOMBmgvpmfDEd9AM2ZXLK5FtYEgq8RsaM8PhphWy1IrCbPW3Ljs4Ybj BMt+o4yNADk2Q== Date: Wed, 14 Jan 2026 16:15:20 -0800 (PST) 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 1/5] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu In-Reply-To: <837eab835a75e7f668c5a49074991b2fcba56156.1768415200.git.oleksii_moisieiev@epam.com> Message-ID: References: <837eab835a75e7f668c5a49074991b2fcba56156.1768415200.git.oleksii_moisieiev@epam.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-814617685-1768436088=:8589" Content-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-814617685-1768436088=:8589 Content-Type: text/plain; CHARSET=UTF-8 Content-Transfer-Encoding: 8BIT Content-ID: On Wed, 14 Jan 2026, Oleksii Moisieiev wrote: > From: Grygorii Strashko > > Add chained handling of assigned DT devices to support access-controller > functionality through SCI framework, so a DT device assign request can be > passed to firmware for processing and enabling VM access to the requested > device (for example, device power management through SCMI). > > The SCI access-controller DT device processing is called before the IOMMU > path. It runs for any DT-described device (protected or not, and even when > the IOMMU is disabled). The IOMMU path remains unchanged for PCI devices; > only the DT path is relaxed to permit non-IOMMU devices. > > This lets xl.cfg:"dtdev" list both IOMMU-protected and non-protected DT > devices: > > dtdev = [ > "/soc/video@e6ef0000", <- IOMMU protected device > "/soc/i2c@e6508000", <- not IOMMU protected device > ] > > The change is done in two parts: > 1) call sci_do_domctl() in do_domctl() before IOMMU processing and propagate > its error if it fails while the IOMMU path succeeds (unhandled cases return > -ENXIO and are ignored); > 2) update iommu_do_dt_domctl() to check for dt_device_is_protected() and > not fail if DT device is not protected by IOMMU. iommu_do_pci_domctl > doesn't need to be updated because iommu_do_domctl first tries > iommu_do_pci_domctl (when CONFIG_HAS_PCI) and falls back to > iommu_do_dt_domctl only if PCI returns -ENODEV. > The new dt_device_is_protected() bypass in iommu_do_dt_domctl only > applies to DT-described devices; SCI parameters are carried via DT nodes. > PCI devices handled by iommu_do_pci_domctl do not carry DT/SCI > metadata in this path, so there is no notion of “SCI parameters on a > non-IOMMU-protected PCI device” for it to interpret or to skip. The > PCI path should continue to report errors if assignment cannot be > performed by the IOMMU layer. > So we should leave iommu_do_pci_domctl unchanged; the SCI/DT-specific > relaxations belong only in the DT path. > Also SCI handling only exists when DT is present. > > Signed-off-by: Grygorii Strashko > Signed-off-by: Oleksii Moisieiev > --- > > Changes in v7: > - update domctl to build on both Arm and x86 platforms > - move ret1 declaration to the top of the function as required by code > style > > Changes in v6: > - change iommu_do_domctl and sci_do_domctl command order and > call sci_do_domctl first which will produce cleaner code path. > Also dropped changing return code when iommu was disabled in > iommu_do_domctl. > > Changes in v5: > - return -EINVAL if mediator without assign_dt_device was provided > - invert return code check for iommu_do_domctl in > XEN_DOMCTL_assign_device domctl processing to make cleaner code > - change -ENOTSUPP error code to -ENXIO in sci_do_domctl > - handle -ENXIO return comde of iommu_do_domctl > - leave !dt_device_is_protected check in iommu_do_dt_domctl to make > code work the same way it's done in "handle_device" call while > creating hwdom(dom0) and "handle_passthrough_prop" call for dom0less > creation > - drop return check from sci_assign_dt_device call as not needed > - do not return EINVAL when addign_dt_device is not set. That is > because this callback is optional and not implemented in single-agent driver > > xen/arch/arm/firmware/sci.c | 35 +++++++++++++++++++++++++ > xen/arch/arm/include/asm/firmware/sci.h | 14 ++++++++++ > xen/common/domctl.c | 35 ++++++++++++++++++++++++- > xen/drivers/passthrough/device_tree.c | 6 +++++ > 4 files changed, 89 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/arm/firmware/sci.c b/xen/arch/arm/firmware/sci.c > index aa93cda7f0..31a7e5c28b 100644 > --- a/xen/arch/arm/firmware/sci.c > +++ b/xen/arch/arm/firmware/sci.c > @@ -126,6 +126,41 @@ int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev) > return 0; > } > > +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d, > + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) > +{ > + struct dt_device_node *dev; > + int ret = 0; > + > + switch ( domctl->cmd ) > + { > + case XEN_DOMCTL_assign_device: > + ret = -ENXIO; > + if ( domctl->u.assign_device.dev != XEN_DOMCTL_DEV_DT ) > + break; > + > + if ( !cur_mediator ) > + break; > + > + if ( !cur_mediator->assign_dt_device ) > + break; > + > + ret = dt_find_node_by_gpath(domctl->u.assign_device.u.dt.path, > + domctl->u.assign_device.u.dt.size, &dev); > + if ( ret ) > + return ret; > + > + ret = sci_assign_dt_device(d, dev); > + > + break; > + default: > + /* do not fail here as call is chained with iommu handling */ > + break; > + } > + > + return ret; > +} > + > static int __init sci_init(void) > { > struct dt_device_node *np; > diff --git a/xen/arch/arm/include/asm/firmware/sci.h b/xen/arch/arm/include/asm/firmware/sci.h > index 3500216bc2..a2d314e627 100644 > --- a/xen/arch/arm/include/asm/firmware/sci.h > +++ b/xen/arch/arm/include/asm/firmware/sci.h > @@ -146,6 +146,14 @@ int sci_dt_finalize(struct domain *d, void *fdt); > * control" functionality. > */ > int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev); > + > +/* > + * SCI domctl handler > + * > + * Only XEN_DOMCTL_assign_device is handled for now. > + */ > +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d, > + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl); > #else > > static inline bool sci_domain_is_enabled(struct domain *d) > @@ -195,6 +203,12 @@ static inline int sci_assign_dt_device(struct domain *d, > return 0; > } > > +static inline int sci_do_domctl(struct xen_domctl *domctl, struct domain *d, > + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) > +{ > + return 0; > +} > + > #endif /* CONFIG_ARM_SCI */ > > #endif /* __ASM_ARM_SCI_H */ > diff --git a/xen/common/domctl.c b/xen/common/domctl.c > index 954d790226..5a31cccdd7 100644 > --- a/xen/common/domctl.c > +++ b/xen/common/domctl.c > @@ -29,6 +29,9 @@ > #include > > #include > +#if IS_ENABLED(CONFIG_ARM) > +#include > +#endif > #include > #include > #include > @@ -274,7 +277,7 @@ static bool is_stable_domctl(uint32_t cmd) > > long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) > { > - long ret = 0; > + long ret = 0, ret1 = 0; > bool copyback = false; > struct xen_domctl curop, *op = &curop; > struct domain *d; > @@ -827,7 +830,37 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) > case XEN_DOMCTL_test_assign_device: > case XEN_DOMCTL_deassign_device: > case XEN_DOMCTL_get_device_group: > + if ( IS_ENABLED(CONFIG_ARM) ) I skipped the last round of review so if this is addressing a comment from Jan I am OK with this as is. However, I would check directly on CONFIG_ARM_SCI. > + { > + /* > + * Add chained handling of assigned DT devices to support > + * access-controller functionality through SCI framework, so > + * DT device assign request can be passed to FW for processing and > + * enabling VM access to requested device. > + * The access-controller DT device processing is called before IOMMU > + * processing preserving return code and expected to be executed for > + * any DT device regardless if DT device is protected by IOMMU or > + * not (or IOMMU is disabled). > + */ > + ret1 = sci_do_domctl(op, d, u_domctl); > + if ( ret1 < 0 ) > + return ret1; > + } > + else > + ret1 = -ENXIO; > + > ret = iommu_do_domctl(op, d, u_domctl); > + if ( ret < 0 ) > + return ret; > + > + /* > + * If IOMMU processing was successful, check for SCI processing return > + * code and if it was failed then overwrite the return code to propagate > + * SCI failure back to caller. > + */ > + if ( ret1 != -ENXIO ) > + ret = ret1; > + > break; > > case XEN_DOMCTL_get_paging_mempool_size: > diff --git a/xen/drivers/passthrough/device_tree.c b/xen/drivers/passthrough/device_tree.c > index f5850a2607..29a44dc773 100644 > --- a/xen/drivers/passthrough/device_tree.c > +++ b/xen/drivers/passthrough/device_tree.c > @@ -379,6 +379,12 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d, > break; > } > > + if ( !dt_device_is_protected(dev) ) > + { > + ret = 0; > + break; > + } > + > ret = iommu_assign_dt_device(d, dev); > > if ( ret ) > -- > 2.34.1 > --8323329-814617685-1768436088=:8589-- From xen-devel-bounces@lists.xenproject.org Thu Jan 15 00:19:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 00:19:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203948.1518859 (Exim 4.92) (envelope-from ) id 1vgB56-0003ZD-MY; Thu, 15 Jan 2026 00:19:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203948.1518859; Thu, 15 Jan 2026 00: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 1vgB56-0003Z6-JW; Thu, 15 Jan 2026 00:19:20 +0000 Received: by outflank-mailman (input) for mailman id 1203948; Thu, 15 Jan 2026 00: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 1vgB55-0003Z0-Ph for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 00:19: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 d45eb11e-f1a7-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 01:19:18 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 1898E42B6E; Thu, 15 Jan 2026 00:19:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4F57AC19423; Thu, 15 Jan 2026 00:19: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: d45eb11e-f1a7-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768436357; bh=tUwHMTTcJ8XZ+mPakudFp8PQXy21Q5UU3OtMuyoPqzk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=d674r4+FKqSNdzaO/vJTbenVTVFDGeweaoHw6BRUVGEZraGO9KfArYZjsRxDWoHvV apswTrDG7j5NDz/B3BvA0+X9bkFiV3BS0knRIKE9gMEiEJzK1VQzCiCW5FO/ybHFam Yv2GEQWcEIAOGD0PnY/lCSV13/NzWm497rjgnHcnJLOuZH/4ZbSlzDXxe/Cb0TrXo4 uQJwdhK963TopVaimlom05trNSeJh1BzoPWxiYerXzskK6ZHJcNokIKb9r0Q5ckS9K MlPn9jEesHS3/c8jaqDpKWhyzein2pldaKkAGBOhVO3M45R/g9k9JLdecJV3Hbc9PQ diYkKVeTMvP5Q== Date: Wed, 14 Jan 2026 16:19:12 -0800 (PST) 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 2/5] xen: arm: smccc: add INVALID_PARAMETER error code In-Reply-To: <3ab46b8b5ceae264f26ad70ac2266a2ae56d02bc.1768415200.git.oleksii_moisieiev@epam.com> Message-ID: References: <3ab46b8b5ceae264f26ad70ac2266a2ae56d02bc.1768415200.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 Wed, 14 Jan 2026, Oleksii Moisieiev wrote: > According to the "7.1 Return Codes" section of DEN0028 [1] > INVALID_PARAMETER code (-3) is returned when one of the call > parameters has a non-supported value. > Adding this error code to the common smccc header file. > > [1]: https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6 > > Signed-off-by: Oleksii Moisieiev Acked-by: Stefano Stabellini > --- > > > > xen/arch/arm/include/asm/smccc.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/smccc.h > index a289c48b7f..dc6af94db1 100644 > --- a/xen/arch/arm/include/asm/smccc.h > +++ b/xen/arch/arm/include/asm/smccc.h > @@ -381,6 +381,7 @@ void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs *args, > 0x3FFF) > > /* SMCCC error codes */ > +#define ARM_SMCCC_INVALID_PARAMETER (-3) > #define ARM_SMCCC_NOT_REQUIRED (-2) > #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION (-1) > #define ARM_SMCCC_NOT_SUPPORTED (-1) > -- > 2.34.1 > From xen-devel-bounces@lists.xenproject.org Thu Jan 15 00:27:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 00:27:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203961.1518879 (Exim 4.92) (envelope-from ) id 1vgBD5-0005RR-PE; Thu, 15 Jan 2026 00:27:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203961.1518879; Thu, 15 Jan 2026 00:27:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgBD5-0005RK-ML; Thu, 15 Jan 2026 00:27:35 +0000 Received: by outflank-mailman (input) for mailman id 1203961; Thu, 15 Jan 2026 00:27: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 1vgBD4-0005DR-74 for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 00:27:34 +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 f8a5d706-f1a8-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 01:27:29 +0100 (CET) Received: from SJ0PR05CA0038.namprd05.prod.outlook.com (2603:10b6:a03:33f::13) by MN0PR12MB5881.namprd12.prod.outlook.com (2603:10b6:208:379::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Thu, 15 Jan 2026 00:27:23 +0000 Received: from SJ1PEPF000023CE.namprd02.prod.outlook.com (2603:10b6:a03:33f:cafe::73) by SJ0PR05CA0038.outlook.office365.com (2603:10b6:a03:33f::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.4 via Frontend Transport; Thu, 15 Jan 2026 00:27:16 +0000 Received: from satlexmb07.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.9520.1 via Frontend Transport; Thu, 15 Jan 2026 00:27:23 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 14 Jan 2026 18:27:22 -0600 Received: from xsjvictlira01-ubuntu-0.tail79467d.ts.net (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, 14 Jan 2026 16:27:21 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f8a5d706-f1a8-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=I19nhdgREnO2j9Qc+KepZVpS118i84PkTFlSRTPdZ5toWULvloABEGJtBeyXtqw9XFRtTY4Wq8J9llO8ifeMVNgcqZiZmysQKz/E8CweUK3tTE7KnQCYRrUgGpV6HoCwATEqW0jcG2XEVm92ffXFZ8ZDbKiypgLscTEQuZrc0yONSj420M3+LnsykjvxAtkDk9iATxzMiEJ1LqFTnsIxdwYApxHJAVMMU5Z4gcGHIh63VYTtC34nRFzSL/Lb4wko/JA+eNrpS7NrEj5Cqlm9h7eM8KIPGsYmDtehvzG8cL65Ot0CKCf6aBDTIxHG2RjayTm93U54hUt1pmt0yattQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PH3djnAJYdyXCisb5N7pK2eva89Bdz1+TR97+9/YAiU=; b=m2mNdh44pro1s9V+cWIh+Dncpg51Izhf8moQ22vSHEsxcK5+JNS09XGCyI81AXEH7x0VFgP+T5h9m+haK+mrApZV9Kqn1IKCa7KVgYl5prvq/Gu4/AjySULdMpNh7Z8fZQYaiCmnCNcocpyip4L8vhu0ZnPNawaqIvpp3UFazcAIOrqzIbUdeqy1+mHzdPB2ayPSAqwPwm52xtLpC9eENLyqR8TFZP6koQPzu4owcZ02VzI6f+OoLG/CG2Yu1hLAyfwfOvVs8DwbNvrapL58EMX8rM0++yson3exgHbr0Nh2LxzH7BeZHubg5JdxQWdCPlYePNw78IIqfOtPHhTiMA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PH3djnAJYdyXCisb5N7pK2eva89Bdz1+TR97+9/YAiU=; b=zMiQE6JH6f13YKwX8bqblbZwCQSrzMNd4jV2ekHneKp03btuopC62dBFu3223JeQX6KlshbcMoK2ktNftLSylvDrVVDXbu+kQ3vcOjfIFCDz6b7C8mLxck7FACBFDb1uQ862rKeaal/UvV6xnX4RtGi4pTewp+K+sf+NWF0XbF0= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: Victor Lira To: CC: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Alejandro Vallejo Subject: [XEN PATCH v1 1/1] x86/vlapic: match broadcasts for logical destination mode Date: Wed, 14 Jan 2026 23:55:48 +0000 Message-ID: <20260114235548.626696-2-victorm.lira@amd.com> X-Mailer: git-send-email 2.51.GIT In-Reply-To: <20260114235548.626696-1-victorm.lira@amd.com> References: <20260114235548.626696-1-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: SJ1PEPF000023CE:EE_|MN0PR12MB5881:EE_ X-MS-Office365-Filtering-Correlation-Id: 8b67fb97-edea-4528-c019-08de53ccda61 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?DdgFKJCx6DFCOpNFgRasww/a5jSmsvi05g2A44Tl+t0b4Q4NclpVBdIMSRum?= =?us-ascii?Q?86YwZazR1tFLemAjSGyEDQXYv4hK2JkX+YHnHJv7JyrFN+92Qb6PosfyNYEJ?= =?us-ascii?Q?hi3VgsdtfGVKv6oK8PD3e4KXrNig0D0c8U3pcvhY0kYJkwYK/a4k8DzWZo+z?= =?us-ascii?Q?LQqZRTCY3W+PmwJSoWvX/7nnwJyLTFWsRG0Yg+qjj9+oCb2J0yOv5qDgOGcd?= =?us-ascii?Q?ARSCpDPPDr9CqLoz5PL53ZLdvUcqsuO50AFyceiSok65G12KFKtYZn2Zso6C?= =?us-ascii?Q?EQAoY+TdggU1Q4Q5AVgHr6zacn4IR/kkk4XGzxsHZTGWH8aOK8eyAqiRfwGr?= =?us-ascii?Q?tFG3VXKVeOOua4lWbDMbL2XQxCKmD+5LqH/yeYJnerPokF23aJyQVb/twQws?= =?us-ascii?Q?MyopvmlWDDeYotJ4WImAfE5cCJddwy5BHJaSSa4vB5WGA2sMKzrHcEh1fnUY?= =?us-ascii?Q?G479tp6taVtdphsNgvKSO7TgSt5+lOZrOjVoq+YVC72fUUQJR3E7gRBWoFj4?= =?us-ascii?Q?rzH1eryUUgm3EjZ52fg25hh4Kf6dKcwmQfTqYx/C39dCB6fKvwGd4OoSsLTu?= =?us-ascii?Q?eGFeX+2FVSJf57fOGGIlRmWG92HpQW3ItJ7gFodOc3n0/bBMnvdsNzJT6dVc?= =?us-ascii?Q?OljWYC1EDnzK372ZwQp24PbyYiiGc9fK+uUbtZ6//mHBA64lK56zYacGOyp5?= =?us-ascii?Q?kFkbM8NvjbD5xanBwaAnwMOdi2xTRxNANbW461Vz3dCuql9Wuj28JpextlTh?= =?us-ascii?Q?vrqrC4kPXi9zz1aR/O7eTiJWA+7eWrjfsoSQKm3hd+FCLUXmrVw/5Lp6KRtJ?= =?us-ascii?Q?wDDVfL/tOlzCNzlqsJo/MCf8BAdPyHKVq/KqsAQ+7nRNiU/OYGnjTn18HbXi?= =?us-ascii?Q?m4szjRnyJlAXDq5bT0i5v5YOHpmOKOL8xQ4hgpQ6QLg7xlIHsUeyBqTlfnOW?= =?us-ascii?Q?Lz3FJvGZVCwJDBhDaNB9/xuaEBPHs92nZX1kXrx4UgRHop75CuBnghRKGJgW?= =?us-ascii?Q?7g+un7Wddfe/2GoCEApaG8LYwlAJkmflwmgYJXNVDf19vOSfgkJmE02aRe9a?= =?us-ascii?Q?TxBSjIc4ljvyWYq2z1Rk+KFpsTL6h2b7fLSYumkXjNFChVMCxCkZMUs1Bx1/?= =?us-ascii?Q?VT/bgJO2GukOZGGTo/p7YAoPFngCy+RlQlDijlmuwU1WjXFQjq2PJnwDRYDA?= =?us-ascii?Q?T4IhavYAyXgUDUc9VnnFHL3S1b7v7O8Qj5u/IesFgB0I1x6CCH4UwrSmfHe9?= =?us-ascii?Q?4/cqAgg6yJBpSndp0gQTnRbJsYBScnsQVaO51bhyLNEzZUOgYzr3kS9rQ0hA?= =?us-ascii?Q?DFzCh8ZbBJMxnu7+hNo1WkCF08tBL7bJcBPbBzPadD9LaO1hocIeg/KybXw9?= =?us-ascii?Q?abYurGtb6qab/1y7a1RdFf6CA6v17xvN1WN1xGZmVcsICqMi1/uD5bmQePea?= =?us-ascii?Q?9jw2JkS3W9SN2E6q0wArCw2R71YqkKFxXfCzQZkMLkXET6dTGw8h5YHmMIYO?= =?us-ascii?Q?biTCMVt1WcIqvf3PN7PBBq/fII1owwR2NnEExjW/pGZ89Bh+GSMsMouIXLpy?= =?us-ascii?Q?mG5XshLubY2WTfZMghbKKWcKhGgiiwnk0Z+TsfSXib0lcZpR7j3RBOMa5YYt?= =?us-ascii?Q?if7g72mMXwPt40+o5yy3K1BVLFtydIteMaluNZQDDt4P41gwDM/b0EW37dHl?= =?us-ascii?Q?+osRjg=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 00:27:23.4046 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8b67fb97-edea-4528-c019-08de53ccda61 X-MS-Exchange-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: SJ1PEPF000023CE.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5881 amd64 vol 3 16.6.1: "In both the flat model and the cluster model, if the destination field = FFh, the interrupt is accepted by all local APICs." 16.14: "A DEST value of FFFF_FFFFh in the ICR is used to broadcast IPIs to all local APICs." intel 64 vol 3 12.6.2.2: "Broadcast to all local APICs is achieved by setting all destination bits to one." 12.12.9: "A destination ID value of FFFF_FFFFH is used for broadcast of interrupts in both logical destination and physical destination modes." The specs say 0xFFFFFFFF/0xFF should be a broadcast to all APICs in logical destination mode but it is matched only for cluster 0xFFFF/0xFF (or as flat mode in xAPIC). Add a check in vlapic_match_dest similar to what is done for physical destination mode. Signed-off-by: Victor Lira --- xen/arch/x86/hvm/vlapic.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c index 79697487ba..1208cd21f0 100644 --- a/xen/arch/x86/hvm/vlapic.c +++ b/xen/arch/x86/hvm/vlapic.c @@ -248,7 +248,8 @@ bool vlapic_match_dest( { case APIC_DEST_NOSHORT: if ( dest_mode ) - return vlapic_match_logical_addr(target, dest); + return (dest == _VLAPIC_ID(target, 0xffffffffU)) || + vlapic_match_logical_addr(target, dest); return (dest == _VLAPIC_ID(target, 0xffffffffU)) || (dest == VLAPIC_ID(target)); -- 2.51.GIT From xen-devel-bounces@lists.xenproject.org Thu Jan 15 00:27:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 00:27:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203960.1518868 (Exim 4.92) (envelope-from ) id 1vgBD3-0005De-FR; Thu, 15 Jan 2026 00:27:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203960.1518868; Thu, 15 Jan 2026 00:27:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgBD3-0005DX-Ci; Thu, 15 Jan 2026 00:27:33 +0000 Received: by outflank-mailman (input) for mailman id 1203960; Thu, 15 Jan 2026 00:27:31 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgBD1-0005DR-QO for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 00:27:31 +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 f87d75d2-f1a8-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 01:27:28 +0100 (CET) Received: from SJ0PR05CA0048.namprd05.prod.outlook.com (2603:10b6:a03:33f::23) by SN7PR12MB6910.namprd12.prod.outlook.com (2603:10b6:806:262::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Thu, 15 Jan 2026 00:27:23 +0000 Received: from SJ1PEPF000023CE.namprd02.prod.outlook.com (2603:10b6:a03:33f:cafe::65) by SJ0PR05CA0048.outlook.office365.com (2603:10b6:a03:33f::23) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.2 via Frontend Transport; Thu, 15 Jan 2026 00:26:57 +0000 Received: from satlexmb07.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.9520.1 via Frontend Transport; Thu, 15 Jan 2026 00:27:21 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 14 Jan 2026 18:27:21 -0600 Received: from xsjvictlira01-ubuntu-0.tail79467d.ts.net (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, 14 Jan 2026 16:27:21 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f87d75d2-f1a8-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jdGanimCwDJYNPrc/WRiKLXwosKB/b3JH2PGkBKXpOt6YCCYD59RawV85Zc3RyWEkUwU7EYE+z02jPk9h7zkLyNhC8Q8oEnGZ9blM09u1AyVKdW+Sm971Mejv71IP0vJNu5+mFSRtf25eVehgZ4xAbNT/mkjA7PEjOvdU/QmC9p5b4uI3X7UUpvts2+ix9I6cKULOj0yvYogp5i9WcMvXnFTtBaegGK2sKXJwcJ6v2Zg+Whw2zCEw21zND8UAVNwd2vo6zYbD6V1+G/6iCrFb9QRM4KzXm6zZo3avKLBtmVAnxLpYVKTpH4/akIsutTeDCjT/pIKYoZzQFBl0m09Lg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jZ5n/e7VN4IhVHwvH03BwDAA+krGDXIA0x/6VQiU8ZU=; b=KxcqPyiicKooUL0K8C/bZ65C6o+Has7EsXFsHaRTiyTUTgJk2fzDasSejrBo7YbMhllC64a0I0/PRvHrsoY8VyXPspQbCLmGIfHeOjziWWWrAE+k6DzvimW9mUzsBXwQR61PxE7GbMJiXdLBMmnvMujw8AoklmbsB9UdRwIKNoN/PneGAP8Iu897DcSCdLHNJ1UimP0whukp1+fxeag+5mEwOuw6Kw3R9OnlqNGd30GgZf/3hQ0CmxPgKOsxLjvI8z1xxgQdLsvtYt1Fhn+n6y595JZSzquGUD9uGb9bQ1rpb9AYNhJiWj44EFXhyvQb3rVl67w3YQt0nAD+HqRiLw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jZ5n/e7VN4IhVHwvH03BwDAA+krGDXIA0x/6VQiU8ZU=; b=zSf67CZAe+RxVkidBt4QNwE7BpRnt3sg5VCO7R2j3907mBdjFQED+mgUWdPdsoKrN6UmQvd/W4hAoxDan4VYxORv1snY6bzHPNwHwqgWq/eXkw7tRHGKO3rlAFB3sF3RtR5jxmLhw1UyH3MLxNRTMh8pZPvvui78QX+rIRPFWs0= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: Victor Lira To: CC: Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Alejandro Vallejo Subject: [XEN PATCH v1 0/1] x86/vlapic: match broadcasts for logical destination mode Date: Wed, 14 Jan 2026 23:55:47 +0000 Message-ID: <20260114235548.626696-1-victorm.lira@amd.com> X-Mailer: git-send-email 2.51.GIT MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF000023CE:EE_|SN7PR12MB6910:EE_ X-MS-Office365-Filtering-Correlation-Id: d048247d-8d86-4b50-836b-08de53ccd978 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700013|376014|1800799024; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?5JozR4eUCoPkhcfMpWLoWgfnKVyiCD8kvaKqxPC4sGfsJTgwFGJG8H21lh27?= =?us-ascii?Q?xFkuk1B0KMXV3uLGreYjd8UFnYShx2Pnxeknk8n1U1UphBAOnvXjjVT6k53M?= =?us-ascii?Q?lC6qxbcwVG2v3vQZaL2DnbBVEjpQooGO2hpCyuA2C8rN9JtBWdO68mb19b9/?= =?us-ascii?Q?QTo7YWIfSayA2eqI6mlk7ktHqXp9Uja5nmKWIjpiz7UFYIjQkNRRel3IZofN?= =?us-ascii?Q?AbJH4+yenw9E+amoVIZ175WSbkZNn5a5JnkAFxFGIn1KMw6ZP/POmW7OTBAI?= =?us-ascii?Q?vUL/ePdOVL3D9UTi8Ka8V/I6UN0EfVJVG7idtQ7drYvrNH5xMh6H4v7rWGz8?= =?us-ascii?Q?zxoMAW3mzdZGhUMfre0WAalCZZicd7D7izY8BX3F1F6u8cvJSMUQjrke/WHM?= =?us-ascii?Q?WFGLGS8N7gaZyn7pkyA+qVJ/D4Zt/TWliapcbaFMDWcfvoT9xk+bDzhTgtE5?= =?us-ascii?Q?LPiziUh2pnT5M1/ekFZXN4y3aY0st2hhqlItON52RswvMgOldVvJY04BeAy/?= =?us-ascii?Q?SSpW3eEGoLNcZ8a1l7STUX5dZazUML0aiLpLCwvE5VJREdkcIM1BPZKBnHH1?= =?us-ascii?Q?j4aKIbfag130z2WaIZohBCNKPRdTdle1/aNyfNRi0/FbNiqxDeF54m2KGymn?= =?us-ascii?Q?DRRaRXsQ9wK5MQCcXyhn+JbOUBEzaCcmkcIQkMOSRL57AUxQwdD+neRQLHfQ?= =?us-ascii?Q?9BinsCDeOyupIxA0gJJJDKc2U5VvSHx965y86ns3LHm5Gac8I3fIV/cNZx9D?= =?us-ascii?Q?6s0uM70oJs95HejYv/HUy5TzDMCPJgj/eMzKKw90EgmRLLw+7cSa5rzYs6k0?= =?us-ascii?Q?ivt2D14qWguoQt8pmCdTI0jtMxU3ADndlXIzrtyvL8sWEL0RRJHhsI5mDAim?= =?us-ascii?Q?kIxL6VFMIq0p4ubzqXTBA/X+nFW0DzEAOfQBCi6x2MYh6P22a4VcJWS/lTXv?= =?us-ascii?Q?X6aP9JN5dDmq6t6r1CipuPmdUgTLjxikU1SUurAzsL/clb3cl0lySYwLFNpk?= =?us-ascii?Q?0lsVjBkU57WBfODHOIquJ2kebtxcL4if6fGTNgXOex30Qya5ASxwU5ZnAGHH?= =?us-ascii?Q?PIpZzW3FOVuk/9/l4xd1TBpOc4TEp/zgkNnJrnybkkdu+R+Bv0mVR4mBXDn+?= =?us-ascii?Q?tSCPDqJGjbi9oLKT1yEFOX8Gce+FhWQOUxjL1605b0Nj/+cdmOeqFdd1TrEN?= =?us-ascii?Q?meV0lzSHwol22QfZkGAVJgUKWY9aFojyphOKfUX9yh3U2rC/FG/yiv7LCM1u?= =?us-ascii?Q?YITNX6lXMyHf2DmXhlS9fdkiWMlW0QaH7VHv73c0ZA1K3bbBMi4UmwNw9h3a?= =?us-ascii?Q?dmr9VJ53p9XT8JDtS2WTFaaBlpMsOsPRw+3YUNiYXBO4R+hPDJpRajU0mpzk?= =?us-ascii?Q?9S0e/30kdLXjiXb+rPGNmywAsk2vg6Qs0jOrR+MgEl2/FJ/OT4I9Ke96XaRf?= =?us-ascii?Q?EY3o1D9EFga+yZ9QL9vg5IXEpzdQKEqLAXidim31RvOh5PPL0NjdZZOqByHy?= =?us-ascii?Q?J8Rzn3HiyaC6XQf0DmPXNiwmNx4EobkcYPv4kjT+DPeKJFH2dW7hVlByovJV?= =?us-ascii?Q?1H5xVHA1WcsjqJYlZFOz+SEbzpUwKlVIsIf8MrB21Ay7H6nnC2vSe3i+s4hO?= =?us-ascii?Q?lrycTHdCxjxkYNh1WFyLKMIeUI0+nEqOxsEhwzNEqraJyFuaywvZk9u8NQ9E?= =?us-ascii?Q?Vf4WOg=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(376014)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 00:27:21.8810 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d048247d-8d86-4b50-836b-08de53ccd978 X-MS-Exchange-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: SJ1PEPF000023CE.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB6910 Hello, I came across something that is out of spec behavior in the domain APIC. Sent IPI's with broadcast destination are broadcast for physical mode but not for logical mode. Please give it a check because in 7429bfd50dd7 it seems that it was intentional to crash the domain if the command was lowest priority + logical + broadcast dest but it got removed. relevant commits: e03ad58f0b8c 8a02f12b7751 7429bfd50dd7 Victor Lira (1): x86/vlapic: match broadcasts for logical destination mode xen/arch/x86/hvm/vlapic.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 2.51.GIT From xen-devel-bounces@lists.xenproject.org Thu Jan 15 00:29:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 00:29:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203983.1518889 (Exim 4.92) (envelope-from ) id 1vgBEe-0006Io-4x; Thu, 15 Jan 2026 00:29:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203983.1518889; Thu, 15 Jan 2026 00:29:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgBEe-0006Ih-19; Thu, 15 Jan 2026 00:29:12 +0000 Received: by outflank-mailman (input) for mailman id 1203983; Thu, 15 Jan 2026 00:29: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 1vgBEc-0006IZ-Kw for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 00:29:10 +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 34592784-f1a9-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 01:29:08 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 2E6C343258; Thu, 15 Jan 2026 00:29:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 499BDC4CEF7; Thu, 15 Jan 2026 00:29: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: 34592784-f1a9-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768436947; bh=4aKe4OAPA0op+l26oHzSgj0yVQfWdRKuWfz5OopJ588=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Dfuwk3RQshcp0qDEw8rKI9v16E8Jof9oMOarA7qvm8VWKY8UV31ID5FaoUE+7GHjj H5rxdPvNbFjjamATT8wXc2FyIwHvHvkU5aspFi/m0jTrbePTLm8aw9WSM5P1DuX0XW fodX8K/HrUEUlYMhVBowxdlEnPsljRgK055WuU30opg/U54NXfKmJ7D9bDBSUf9xJU 5Dw2ySjLyZNuygrV9YADZiK75DsRhLpk7DAZebkFs0YiMuZewaa7k/g/HKtPj0apOB gkSpVYxUHO0soLMSxmnsn2c6c1rK9VdZKX7FQ3nvJ7oMQYITB35sNC8ZvPjw1o9jpm 93B+XOrhudefA== Date: Wed, 14 Jan 2026 16:28:58 -0800 (PST) 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/5] lib/arm: Add I/O memory copy helpers In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Wed, 14 Jan 2026, Oleksii Moisieiev wrote: > This commit introduces two helper functions, `memcpy_fromio` and > `memcpy_toio`, to provide a robust mechanism for copying data between > standard memory and memory-mapped I/O (MMIO) space for the ARM > architecture. > > These helpers handle alignment safely by using byte accesses for any > leading/trailing unaligned bytes and 32-bit raw accesses for the aligned > bulk transfer. Using `__raw_readb/__raw_readl` and > `__raw_writeb/__raw_writel` avoids unintended endianness conversion while > remaining safe across ARM32/ARM64 devices that only support 32-bit > accesses. > > The interface lives in the generic header so other architectures can > provide their own implementations (as macros or functions). The ARM > implementation is split into separate compilation units and added to the > architecture-specific lib Makefile. > > Signed-off-by: Oleksii Moisieiev >From an ARM point of view: Reviewed-by: Stefano Stabellini Thanks Jan for the good feedback on the previous version which has now been addressed > --- > > Changes in v7: > - x86 guidance: removed the speculative note; header now just says > each arch supplies its own implementation or macro. > - name spacing: dropped the double-underscore; the helpers are now > memcpy_fromio / memcpy_toio. The header also explicitly allows an > arch to define these as macros before including it. > - updated io.c to keep 32-bit transfers safe on arm32 > - moved to __raw_read*/__raw_write* accessors to avoid endianness conversion. > - split the helpers into separate compilation units > > Changes in v6: > - sorted objs in Makefile alhabetically > - added newline at the end of Makefile > - used uint{N}_t intead of u{N} > - add comment about why 32 bit IO operations were used > - updated cast opertaions to avoid dropping constness which is wrong > - move function definitions to generic place so the could be reused by > other arch > - add SPDX tag to io.c > > Changes in v5: > - move memcpy_toio/fromio to the generic place > > xen/include/xen/lib/io.h | 65 +++++++++++++++++++++++++++++++++++++ > xen/lib/Makefile | 1 + > xen/lib/arm/Makefile | 1 + > xen/lib/arm/memcpy_fromio.c | 48 +++++++++++++++++++++++++++ > xen/lib/arm/memcpy_toio.c | 48 +++++++++++++++++++++++++++ > 5 files changed, 163 insertions(+) > create mode 100644 xen/include/xen/lib/io.h > create mode 100644 xen/lib/arm/Makefile > create mode 100644 xen/lib/arm/memcpy_fromio.c > create mode 100644 xen/lib/arm/memcpy_toio.c > > diff --git a/xen/include/xen/lib/io.h b/xen/include/xen/lib/io.h > new file mode 100644 > index 0000000000..cd2b6680d5 > --- /dev/null > +++ b/xen/include/xen/lib/io.h > @@ -0,0 +1,65 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Generic I/O memory copy function prototypes. > + * > + * These functions provide low-level implementation for copying data between > + * regular memory and I/O memory regions. Each architecture must provide its > + * own implementation based on the specific requirements of the architecture's > + * memory model and I/O access patterns. An architecture may supply these as > + * functions or as macros in its own headers before including this file. > + * > + * Architecture-specific implementations: > + * ===================================== > + * Each architecture should implement these functions in xen/lib//io.c > + * (or define them as macros) based on their hardware requirements. See > + * xen/lib/arm/io.c for an example using explicit I/O accessors. > + */ > + > +#ifndef _XEN_LIB_IO_H > +#define _XEN_LIB_IO_H > + > +#include > + > +/* > + * memcpy_fromio - Copy data from I/O memory space to regular memory > + * @to: Destination buffer in regular memory > + * @from: Source address in I/O memory space (must be marked __iomem) > + * @count: Number of bytes to copy > + * > + * This function handles copying from memory-mapped I/O regions using > + * architecture-appropriate I/O accessor functions. It ensures proper: > + * - Memory ordering and barriers > + * - Alignment requirements > + * - Hardware-specific access semantics > + * > + * Each architecture provides its own implementation that may: > + * - Use special I/O accessor functions (ARM: readl_relaxed, readb_relaxed) > + * - Implement alignment handling for devices requiring specific access sizes > + * - Add memory barriers to ensure ordering with other I/O operations > + * - Or simply map to memcpy() if the architecture allows direct I/O access > + */ > +extern void memcpy_fromio(void *to, const volatile void __iomem *from, > + size_t count); > + > +/* > + * memcpy_toio - Copy data from regular memory to I/O memory space > + * @to: Destination address in I/O memory space (must be marked __iomem) > + * @from: Source buffer in regular memory > + * @count: Number of bytes to copy > + * > + * This function handles copying to memory-mapped I/O regions using > + * architecture-appropriate I/O accessor functions. It ensures proper: > + * - Memory ordering and barriers > + * - Alignment requirements > + * - Hardware-specific access semantics > + * > + * Each architecture provides its own implementation that may: > + * - Use special I/O accessor functions (ARM: writel_relaxed, writeb_relaxed) > + * - Implement alignment handling for devices requiring specific access sizes > + * - Add memory barriers to ensure ordering with other I/O operations > + * - Or simply map to memcpy() if the architecture allows direct I/O access > + */ > +extern void memcpy_toio(volatile void __iomem *to, const void *from, > + size_t count); > + > +#endif /* _XEN_LIB_IO_H */ > diff --git a/xen/lib/Makefile b/xen/lib/Makefile > index 5ccb1e5241..6bb0491d89 100644 > --- a/xen/lib/Makefile > +++ b/xen/lib/Makefile > @@ -1,3 +1,4 @@ > +obj-$(CONFIG_ARM) += arm/ > obj-$(CONFIG_X86) += x86/ > > lib-y += bsearch.o > diff --git a/xen/lib/arm/Makefile b/xen/lib/arm/Makefile > new file mode 100644 > index 0000000000..0bb1a825ce > --- /dev/null > +++ b/xen/lib/arm/Makefile > @@ -0,0 +1 @@ > +obj-y += memcpy_fromio.o memcpy_toio.o > diff --git a/xen/lib/arm/memcpy_fromio.c b/xen/lib/arm/memcpy_fromio.c > new file mode 100644 > index 0000000000..342a28cb49 > --- /dev/null > +++ b/xen/lib/arm/memcpy_fromio.c > @@ -0,0 +1,48 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#include > +#include > + > +/* > + * Use 32-bit raw IO operations for portability across ARM32/ARM64 where > + * 64-bit accessors may not be atomic and some devices only support 32-bit > + * aligned accesses. > + */ > + > +void memcpy_fromio(void *to, const volatile void __iomem *from, > + size_t count) > +{ > + while ( count && (!IS_ALIGNED((unsigned long)from, 4) || > + !IS_ALIGNED((unsigned long)to, 4)) ) > + { > + *(uint8_t *)to = __raw_readb(from); > + from++; > + to++; > + count--; > + } > + > + while ( count >= 4 ) > + { > + *(uint32_t *)to = __raw_readl(from); > + from += 4; > + to += 4; > + count -= 4; > + } > + > + while ( count ) > + { > + *(uint8_t *)to = __raw_readb(from); > + from++; > + to++; > + count--; > + } > +} > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 8 > + * tab-width: 8 > + * indent-tabs-mode: t > + * End: > + */ > diff --git a/xen/lib/arm/memcpy_toio.c b/xen/lib/arm/memcpy_toio.c > new file mode 100644 > index 0000000000..e543c49124 > --- /dev/null > +++ b/xen/lib/arm/memcpy_toio.c > @@ -0,0 +1,48 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#include > +#include > + > +/* > + * Use 32-bit raw IO operations for portability across ARM32/ARM64 where > + * 64-bit accessors may not be atomic and some devices only support 32-bit > + * aligned accesses. > + */ > + > +void memcpy_toio(volatile void __iomem *to, const void *from, > + size_t count) > +{ > + while ( count && (!IS_ALIGNED((unsigned long)to, 4) || > + !IS_ALIGNED((unsigned long)from, 4)) ) > + { > + __raw_writeb(*(const uint8_t *)from, to); > + from++; > + to++; > + count--; > + } > + > + while ( count >= 4 ) > + { > + __raw_writel(*(const uint32_t *)from, to); > + from += 4; > + to += 4; > + count -= 4; > + } > + > + while ( count ) > + { > + __raw_writeb(*(const uint8_t *)from, to); > + from++; > + to++; > + count--; > + } > +} > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 8 > + * tab-width: 8 > + * indent-tabs-mode: t > + * End: > + */ > -- > 2.34.1 > From xen-devel-bounces@lists.xenproject.org Thu Jan 15 01:14:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 01:14:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204027.1518898 (Exim 4.92) (envelope-from ) id 1vgBwM-0003yQ-BM; Thu, 15 Jan 2026 01:14:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204027.1518898; Thu, 15 Jan 2026 01:14:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgBwM-0003yJ-8U; Thu, 15 Jan 2026 01:14:22 +0000 Received: by outflank-mailman (input) for mailman id 1204027; Thu, 15 Jan 2026 01: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 1vgBwK-0003yD-8Z for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 01:14: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 81c5a527-f1af-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 02:14:15 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id E30AF441B2; Thu, 15 Jan 2026 01:14:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 023F8C4CEF7; Thu, 15 Jan 2026 01:14: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: 81c5a527-f1af-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768439653; bh=onKZNgRuGf74rDHkeWlBipqYdiPGLWVqOvxB59gLKlE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Th6i2TYTZ2pm/nKRS6xy6NPcYSzMEb1gNwIUSNXTBuEoX6Yo0f3Ga5AC522pe14MT 2l+QtyepwvytZKsfR/prGOwA/JiEMlGV8OOpjAKF1KVog5T+YOvTWlr0kDHApF3LNf QTTp5CcWKL4oAyoXdRDAermiAU67VNs3geTbeTzADNLIR5NRrQM5z8vg4tjot4W/aW 6tqX9bVr5tDFO2V9knICZz2QuNCTJmq8IGz+62leszvMbtdT3A1gM1w6AFxlAXnb0a QEWFXFTk8TzaxTywjUsBY2yHS2Ru4h6os+xorhKcMbB6NrCRjUXr7ZlPjMgQlLTtA0 KUK6E19K5x3vQ== Date: Wed, 14 Jan 2026 17:14:10 -0800 (PST) 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 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver 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, I am fine with the goals and the strategy to achieve the goals but there are some finer details that don't make sense to me. I apologize if I am asking the same questions you have already answered as some time as passed from the last interaction. On Wed, 14 Jan 2026, Oleksii Moisieiev wrote: > This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-A > (TF-A) which provides SCMI interface with multi-agent support, as shown > below. > > +-----------------------------------------+ > | | > | EL3 TF-A SCMI | > +-------+--+-------+--+-------+--+-------++ > |shmem1 | |shmem0 | |shmem2 | |shmemX | > +-----+-+ +---+---+ +--+----+ +---+---+ > smc-id1 | | | | > agent1 | | | | > +-----v--------+---------+-----------+----+ > | | | | | > | | | | | > +--------------+---------+-----------+----+ > smc-id0 | smc-id2| smc-idX| > agent0 | agent2 | agentX | > | | | > +----v---+ +--v-----+ +--v-----+ > | | | | | | > | Dom0 | | Dom1 | | DomX | > | | | | | | > | | | | | | > +--------+ +--------+ +--------+ > > The EL3 SCMI multi-agent firmware is expected to provide SCMI SMC shared > memory transport for every Agent in the system. > > The SCMI Agent transport channel defined by pair: > - smc-id: SMC id used for Doorbell > - shmem: shared memory for messages transfer, Xen page > aligned. Shared memort is mapped with the following flags: > MT_DEVICE_nGnRE. > > The follwoing SCMI Agents are expected to be defined by SCMI FW to enable SCMI > multi-agent functionality under Xen: > - Xen management agent: trusted agents that accesses to the Base Protocol > commands to configure agent specific permissions > - OSPM VM agents: non-trusted agent, one for each Guest domain which is > allowed direct HW access. At least one OSPM VM agent has to be provided > by FW if HW is handled only by Dom0 or Driver Domain. > > The EL3 SCMI FW is expected to implement following Base protocol messages: > - BASE_DISCOVER_AGENT (optional if agent_id was provided) > - BASE_RESET_AGENT_CONFIGURATION (optional) > - BASE_SET_DEVICE_PERMISSIONS (optional) > > The SCI SCMI SMC multi-agent driver implements following > functionality: > - The driver is initialized from the Xen SCMI container ``xen_scmi_config`` > (compatible ``xen,sci``) placed under ``/chosen/xen``. Only the > ``arm,scmi-smc`` node that is a child of this container will bind to Xen; > other SCMI nodes (for example under ``/firmware``) are ignored to avoid > stealing the host OSPM instance. > > scmi_shm_1: sram@47ff1000 { > compatible = "arm,scmi-shmem"; > reg = <0x0 0x47ff1000 0x0 0x1000>; > }; > scmi_xen: scmi { > compatible = "arm,scmi-smc"; > arm,smc-id = <0x82000003>; <--- Xen management agent smc-id > #address-cells = < 1>; > #size-cells = < 0>; > #access-controller-cells = < 1>; > shmem = <&scmi_shm_1>; <--- Xen management agent shmem > }; > > - The driver obtains Xen specific SCMI Agent's configuration from the > Host DT, probes Agents and builds SCMI Agents list. The Agents > configuration is taken from "scmi-secondary-agents" property where > first item is "arm,smc-id", second - "arm,scmi-shmem" phandle and > third is optional "agent_id": > > / { > chosen { > xen { > ranges; > xen_scmi_config { > compatible = "xen,sci"; > #address-cells = <2>; > #size-cells = <2>; > ranges; > > scmi_shm_0: sram@47ff0000 { > compatible = "arm,scmi-shmem"; > reg = <0x0 0x47ff0000 0x0 0x1000>; > }; > > /* Xen SCMI management channel */ > scmi_shm_1: sram@47ff1000 { > compatible = "arm,scmi-shmem"; > reg = <0x0 0x47ff1000 0x0 0x1000>; > }; > > scmi_shm_2: sram@47ff2000 { > compatible = "arm,scmi-shmem"; > reg = <0x0 0x47ff2000 0x0 0x1000>; > }; > > scmi_shm_3: sram@47ff3000 { > compatible = "arm,scmi-shmem"; > reg = <0x0 0x47ff3000 0x0 0x1000>; > }; > > scmi-secondary-agents = < > 0x82000002 &scmi_shm_0 0 0x82000002 is the same func_id as... > 0x82000004 &scmi_shm_2 2 > 0x82000005 &scmi_shm_3 3>; <--- func_id, shmem, agent_id > #scmi-secondary-agents-cells = <3>; > > scmi_xen: scmi { > compatible = "arm,scmi-smc"; > arm,smc-id = <0x82000002>; <--- Xen management agent func_id as the one used for Xen. This cannot be right? > #address-cells = <1>; > #size-cells = <0>; > #access-controller-cells = <1>; > shmem = <&scmi_shm_1>; <--- Xen management agent shmem > }; > }; > }; > }; > }; > > / { > /* > * Host SCMI OSPM channel - provided to the Dom0 as is if SCMI > * enabled for it, ignored by Xen multi-agent mediator > */ > scmi_shm: sram@47ff0000 { > compatible = "arm,scmi-shmem"; > reg = <0x0 0x47ff0000 0x0 0x1000>; > }; this is the same as &scmi_shm_0 which I guess is intended? > firmware { > scmi: scmi { > compatible = "arm,scmi-smc"; > arm,smc-id = <0x82000002>; <--- Host OSPM agent smc-id but this again is the same smc-id meant to be used by Xen. If 0x82000002 is the privileged interface, then it is OK for Xen and also baremetal Linux to use it, but Linux Dom0 should not be using it? Or is the smc-id interchangeable and not necessarily tied to the agent-id? I think either way this detail should be clarified in the docs. Speaking of docs, the next patch introducing the doc is not up-to-date with this patch. > #address-cells = < 1>; > #size-cells = < 0>; > shmem = <&scmi_shm>; <--- Host OSPM agent shmem > > protocol@X{ > }; > }; > }; > }; > > This approach allows defining multiple SCMI Agents by adding > Xen-specific properties under the ``/chosen`` node to the Host Device > Tree, leaving the main part unchanged. The Host DT SCMI channel will > be passed to Dom0. > > The Xen management agent is described as a ``scmi_xen`` node under the > ``xen,sci`` comaptible node, which is used by Xen to control other > SCMI Agents in the system. > > All secondary agents' configurations are provided in the > ``scmi-secondary-agents`` property with an optional ``agent_id`` field. > > The ``agent_id`` from the ``scmi-secondary-agents`` property is used > to identify the agent in the system and can be omitted by setting > ``#scmi-secondary-agents-cells = <2>``, so the Secondary Agents > configuration will look like this: > > / { > chosen { > xen { > xen_scmi_config { > compatible = "xen,sci"; > #address-cells = <2>; > #size-cells = <2>; > ranges; > > /* Shared memory nodes as defined earlier */ > > scmi-secondary-agents = < > 0x82000003 &scmi_shm_0 > 0x82000004 &scmi_shm_2 > 0x82000005 &scmi_shm_3 > 0x82000006 &scmi_shm_4>; > #scmi-secondary-agents-cells = <2>; > }; > }; > }; > } > > In this case, Xen will use the ``SCMI_BASE_DISCOVER_AGENT`` call to > discover the ``agent_id`` for each secondary agent. Providing the > ``agent_id`` in the ``scmi-secondary-agents`` property allows skipping > the discovery call, which is useful when the secondary agent's shared > memory is not accessible by Xen or when boot time is important because > it allows skipping the agent discovery procedure. > > Note that Xen is the only one entry in the system which need to know > about SCMI multi-agent support. > > - It implements the SCI subsystem interface required for configuring and > enabling SCMI functionality for Dom0/hwdom and Guest domains. To enable > SCMI functionality for domain it has to be configured with unique supported > SCMI Agent_id and use corresponding SCMI SMC shared memory transport > [smc-id, shmem] defined for this SCMI Agent_id. > - Once Xen domain is configured it can communicate with EL3 SCMI FW: > -- zero-copy, the guest domain puts SCMI message in shmem; > -- the guest triggers SMC exception with smc-id (doorbell); > -- the Xen driver catches exception, do checks and synchronously forwards > it to EL3 FW. > - the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen > management agent channel on domain destroy event. This allows to reset > resources used by domain and so implement use-case like domain reboot. > > Dom0 Enable SCMI SMC: > - pass dom0_scmi_agent_id= in Xen command line. if not provided > SCMI will be disabled for Dom0 and all SCMI nodes removed from Dom0 DT. > The driver updates Dom0 DT SCMI node "arm,smc-id" value and fix up shmem > node according to assigned agent_id. Given that everything else, the entire configuration, is based on device tree, I think it makes sense to also configure this via device tree instead of a command line. This could be another parameter under xen_scmi_config. What do you think? > Guest domains enable SCMI SMC: > - xl.cfg: add configuration option as below > > arm_sci = "type=scmi_smc_multiagent,agent_id=2" > > - xl.cfg: enable access to the "arm,scmi-shmem" which should > correspond assigned agent_id for the domain, for example: > > iomem = [ > "47ff2,1@22001", > ] > > - DT: add SCMI nodes to the Driver domain partial device tree as in the > below example. The "arm,smc-id" should correspond assigned agent_id > for the domain: > > passthrough { > scmi_shm_0: sram@22001000 { > compatible = "arm,scmi-shmem"; > reg = <0x0 0x22001000 0x0 0x1000>; > }; > > firmware { > compatible = "simple-bus"; > scmi: scmi { > compatible = "arm,scmi-smc"; > arm,smc-id = <0x82000004>; > shmem = <&scmi_shm_0>; > ... > } > } > } > > SCMI "4.2.1.1 Device specific access control" > > The XEN SCI SCMI SMC multi-agent driver performs "access-controller" > provider function in case EL3 SCMI FW implements SCMI "4.2.1.1 Device > specific access control" and provides the BASE_SET_DEVICE_PERMISSIONS > command to configure the devices that an agents have access to. > The DT SCMI node should "#access-controller-cells=<1>" property and DT > devices should be bound to the Xen SCMI. > > &i2c1 { > access-controllers = <&scmi 0>; > }; > > The Dom0 and dom0less domains DT devices will be processed > automatically through sci_assign_dt_device() call, but to assign SCMI > devices from toolstack the xl.cfg:"dtdev" property > shall be used: > > dtdev = [ > "/soc/i2c@e6508000", > ] > > xl.cfg:dtdev will contain all nodes which are under SCMI > management (not only those which are behind IOMMU). > > [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > [2] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml > > Signed-off-by: Grygorii Strashko > Signed-off-by: Oleksii Moisieiev > --- > > Changes in v7: > - rework scmi nodes for xen to match on compatible string instead of > the direct path > > Changes in v6: > - updated scmi-shmem to use io.h from generic location > - update scmi_agent_id parameter to be provided inside dom0= parameter > list and have the following format "dom0=sci-agent-id=0" > This change was done as a response for Stefano comment and > requires a lot of code changes, but produces much cleaner solution > that's why I've added it to the code. > - fix file comments and return codes > - fix lenght checks in shmem_{get,put}_message to use offsetof > - remove len member from scmi_channel structure as it is not used > - set scmi-secondary-agents property to be mandatory since if no > secondary agents were provided then there is no sence to enable scmi > when no secondary agents are populated to the Domains > - update documentation in booting.txt, added xen_scmi node to the > example > - adjust d->arch.sci_enabled value in scmi_domain_destroy > - fix lock management in smc_create_channel call > - avoid extra map_channel_memory command for Xen management channel > because collect_agent_id call unmaps memory if DOMID_XEN is not > set. So for Xen management channel we can init domain_id ad DOMID_XEN > before calling collect_agent_id so memory shouldn't be unmapped. > > Changes in v5: > - fix device-tree example format in booting.txt, added ";" after "}". > - update define in scmi-proto.h > - update define in scmi-shmem.h file > - scmi_assign_device - do not ignore -EOPNOTSUPP return > code of the do_smc_xfer > - remove overwriting agent_channel->agent_id after > SCMI_BASE_DISCOVER_AGENT call > - add multi-agent files to the MAINTAINERS > - add SCMI multi-agent description to the SUPPORT.md > - handle ARM_SMCCC_INVALID_PARAMETER return code and return -EINVAL > for smc call > - updated collect_agents function. Set agent_id parameter as optional > in scmi-secondary-agents device-tree property > - introduce "#scmi-secondary-agents-cells" parameter to set if > agent_id was provided > - reanme xen,scmi-secondary-agents property to scmi-secondary-agents > - move memcpu_toio/fromio for the generic place > - update Xen to get management channel from /chosen/xen,config node > - get hypervisor channnel from node instead of using hardcoded > - update handling scmi and shmem nodes for the domain > - Set multi-agent driver to support only Arm64 > > Changes in v4: > - toolstack comments from Anthony PERARD > - added dom0less support > - added doc for "xen,scmi-secondary-agents" > > MAINTAINERS | 4 + > SUPPORT.md | 11 + > docs/man/xl.cfg.5.pod.in | 13 + > docs/misc/arm/device-tree/booting.txt | 103 +++ > docs/misc/xen-command-line.pandoc | 19 +- > tools/libs/light/libxl_arm.c | 4 + > tools/libs/light/libxl_types.idl | 4 +- > tools/xl/xl_parse.c | 12 + > xen/arch/arm/dom0less-build.c | 11 + > xen/arch/arm/domain_build.c | 26 +- > xen/arch/arm/firmware/Kconfig | 12 + > xen/arch/arm/firmware/Makefile | 1 + > xen/arch/arm/firmware/scmi-proto.h | 164 ++++ > xen/arch/arm/firmware/scmi-shmem.c | 115 +++ > xen/arch/arm/firmware/scmi-shmem.h | 45 ++ > xen/arch/arm/firmware/scmi-smc-multiagent.c | 815 ++++++++++++++++++++ > xen/include/public/arch-arm.h | 3 + > 17 files changed, 1359 insertions(+), 3 deletions(-) > create mode 100644 xen/arch/arm/firmware/scmi-proto.h > create mode 100644 xen/arch/arm/firmware/scmi-shmem.c > create mode 100644 xen/arch/arm/firmware/scmi-shmem.h > create mode 100644 xen/arch/arm/firmware/scmi-smc-multiagent.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index ecd3f40df8..4ad1d818a6 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -532,6 +532,10 @@ R: Oleksii Moisieiev > S: Supported > F: xen/arch/arm/firmware/sci.c > F: xen/arch/arm/include/asm/firmware/sci.h > +F: xen/arch/arm/firmware/scmi-smc-multiagent.c > +F: xen/arch/arm/firmware/scmi-shmem.c > +F: xen/arch/arm/firmware/scmi-shmem.h > +F: xen/arch/arm/firmware/scmi-proto.h > > SEABIOS UPSTREAM > M: Wei Liu > diff --git a/SUPPORT.md b/SUPPORT.md > index 491f9ecd1b..7c8951d67b 100644 > --- a/SUPPORT.md > +++ b/SUPPORT.md > @@ -956,6 +956,17 @@ by hwdom. Some platforms use SCMI for access to system-level resources. > > Status: Supported > > +### Arm: SCMI SMC multi-agent support > + > +Enable support for the multi-agent configuration of the EL3 Firmware, which > +allows Xen to provide an SCMI interface to the Domains. > +Xen manages access permissions to the HW resources and provides an SCMI interface > +to the Domains. Each Domain is represented as a separate Agent, which can > +communicate with EL3 Firmware using a dedicated shared memory region, and > +notifications are passed through by Xen. > + > + Status, ARM64: Tech Preview > + > ### ARM: Guest PSCI support > > Emulated PSCI interface exposed to guests. We support all mandatory > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in > index ad1553c5e9..4fc3e12939 100644 > --- a/docs/man/xl.cfg.5.pod.in > +++ b/docs/man/xl.cfg.5.pod.in > @@ -3156,8 +3156,21 @@ single SCMI OSPM agent support. > Should be used together with B Xen command line > option. > > +=item B > + > +Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI over > +SMC calls forwarding from domain to the EL3 firmware (like Trusted Firmware-A) > +with a multi SCMI OSPM agent support. The SCMI B should be > +specified for the guest. > + > =back > > +=item B > + > +Specifies a non-zero ARM SCI agent id for the guest. This option is mandatory > +if the SCMI SMC support is enabled for the guest. The agent ids of domains > +existing on a single host must be unique and in the range [1..255]. > + > =back > > =back > diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt > index 977b428608..6fd7e4a16b 100644 > --- a/docs/misc/arm/device-tree/booting.txt > +++ b/docs/misc/arm/device-tree/booting.txt > @@ -322,6 +322,20 @@ with the following properties: > Should be used together with scmi-smc-passthrough Xen command line > option. > > + - "scmi_smc_multiagent" > + > + Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI over > + SMC calls forwarding from domain to the EL3 firmware (like ARM > + Trusted Firmware-A) with a multi SCMI OSPM agent support. > + The SCMI agent_id should be specified for the guest with "xen,sci-agent-id" > + property. > + > +- "xen,sci-agent-id" > + > + Specifies ARM SCMI agent id for the guest. This option is mandatory if the > + SCMI SMC "scmi_smc_multiagent" support is enabled for the guest. The agent ids > + of guest must be unique and in the range [0..255]. these two don't seem to be in the commit message examples > Under the "xen,domain" compatible node, one or more sub-nodes are present > for the DomU kernel and ramdisk. > > @@ -824,3 +838,92 @@ The automatically allocated static shared memory will get mapped at > 0x80000000 in DomU1 guest physical address space, and at 0x90000000 in DomU2 > guest physical address space. DomU1 is explicitly defined as the owner domain, > and DomU2 is the borrower domain. > + > +SCMI SMC multi-agent support > +============================ > + > +For enabling the ARM SCMI SMC multi-agent support (enabled by CONFIG_SCMI_SMC_MA) > +the Xen specific SCMI Agent's configuration shall be provided in the Host DT > +according to the SCMI compliant EL3 Firmware specification with > +ARM SMC/HVC transport using property "scmi-secondary-agents" placed in "xen,config" > +node under "chosen" node: > + > +- scmi-secondary-agents > + > + Defines a set of SCMI agents configuration supported by SCMI EL3 FW and > + available for Xen. Each Agent defined as triple consisting of: > + SMC/HVC function_id assigned for the agent transport ("arm,smc-id"), > + phandle to SCMI SHM assigned for the agent transport ("arm,scmi-shmem"), > + SCMI agent_id (optional) if not set - Xen will determine Agent ID for > + each provided channel using BASE_DISCOVER_AGENT message. > + > +As an example: > + > +/{ > +chosen { > + xen,config { should be updated > + scmi_shm_0 : sram@47ff0000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x47ff0000 0x0 0x1000>; > + }; > + // Xen SCMI management channel > + scmi_shm_1: sram@47ff1000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x47ff1000 0x0 0x1000>; > + }; > + scmi_shm_2: sram@47ff2000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x47ff2000 0x0 0x1000>; > + }; > + scmi_shm_3: sram@47ff3000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x47ff3000 0x0 0x1000>; > + }; > + scmi_shm_3: sram@47ff4000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x47ff4000 0x0 0x1000>; > + }; > + scmi-secondary-agents = < > + 0x82000002 &scmi_shm_0 0 > + 0x82000004 &scmi_shm_2 2 > + 0x82000005 &scmi_shm_3 3 > + 0x82000006 &scmi_shm_4 4>; > + #scmi-secondary-agents-cells = <3>; > + }; > + > + scmi_xen: scmi { > + compatible = "arm,scmi-smc"; > + arm,smc-id = <0x82000002>; <--- Xen management agent smc-id same question about 0x82000002 being already in use for &scmi_shm_0 > + #address-cells = < 1>; > + #size-cells = < 0>; > + #access-controller-cells = < 1>; > + shmem = <&scmi_shm_1>; <--- Xen management agent shmem > + }; > + > + }; > +}; > + > +- #scmi-secondary-agents-cells > + > + Defines whether Agent_id is set in the "scmi-secondary-agents" property. > + Possible values are: 2, 3. > + When set to 3 (the default), expect agent_id to be present in the secondary > + agents list. > + When set to 2, agent_id will be discovered for each channel using > + BASE_DISCOVER_AGENT message. > + > + > +Example: > + > +/{ > +chosen { > + xen,config { > + scmi-secondary-agents = < > + 0x82000003 &scmi_shm_1 > + 0x82000004 &scmi_shm_2 > + 0x82000005 &scmi_shm_3 > + 0x82000006 &scmi_shm_4>; > + #scmi-secondary-agents-cells = <2>; > + }; > + }; > +}; > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc > index 34004ce282..5541c4a4ed 100644 > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -835,7 +835,7 @@ Specify the bit width of the DMA heap. > cpuid-faulting=, msr-relaxed=, > pf-fixup= ] (x86) > > - = List of [ sve= ] (Arm64) > + = List of [ sve=, sci-agent-id= ] (Arm) > > Controls for how dom0 is constructed on x86 systems. > > @@ -923,6 +923,14 @@ Enables features on dom0 on Arm systems. > option is provided with a positive non zero value, but the platform doesn't > support SVE. > > +* The `sci-agent-id` integer parameter enables ARM SCMI (System Control and > + Management Interface) functionality for Dom0 when `CONFIG_SCMI_SMC_MA` is > + compiled in. This parameter specifies the SCMI agent ID for Dom0. > + A value equal to 0xFF (or omitted) disables SCMI for Dom0, which is useful > + for thin Dom0 or dom0less use-cases. Values from 0 to 254 specify the SCMI > + agent ID. The agent IDs of domains existing on a single host must be unique. > + Example: `dom0=sci-agent-id=0` to enable SCMI with agent ID 0 for Dom0. > + > ### dom0-cpuid > = List of comma separated booleans > > @@ -1107,6 +1115,15 @@ affinities to prefer but be not limited to the specified node(s). > > Pin dom0 vcpus to their respective pcpus > > +### scmi-smc-passthrough (ARM) > +> `= ` > + > +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 and > +SCMI nodes removed from Dom0/hwdom device tree. > +(for example, thin Dom0 with Driver domain use-case). > + > ### dtuart (ARM) > > `= path [:options]` > > diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c > index e4407d6e3f..be0e6263ae 100644 > --- a/tools/libs/light/libxl_arm.c > +++ b/tools/libs/light/libxl_arm.c > @@ -240,6 +240,10 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc, > case LIBXL_ARM_SCI_TYPE_SCMI_SMC: > config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; > break; > + case LIBXL_ARM_SCI_TYPE_SCMI_SMC_MULTIAGENT: > + config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA; > + config->arch.arm_sci_agent_id = d_config->b_info.arch_arm.arm_sci.agent_id; > + break; > default: > LOG(ERROR, "Unknown ARM_SCI type %d", > d_config->b_info.arch_arm.arm_sci.type); > diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl > index 4a958f69f4..9bfbf09145 100644 > --- a/tools/libs/light/libxl_types.idl > +++ b/tools/libs/light/libxl_types.idl > @@ -554,11 +554,13 @@ libxl_sve_type = Enumeration("sve_type", [ > > libxl_arm_sci_type = Enumeration("arm_sci_type", [ > (0, "none"), > - (1, "scmi_smc") > + (1, "scmi_smc"), > + (2, "scmi_smc_multiagent") > ], init_val = "LIBXL_ARM_SCI_TYPE_NONE") > > libxl_arm_sci = Struct("arm_sci", [ > ("type", libxl_arm_sci_type), > + ("agent_id", uint8) > ]) > > libxl_rdm_reserve = Struct("rdm_reserve", [ > diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c > index 1cc41f1bff..0c389d25f9 100644 > --- a/tools/xl/xl_parse.c > +++ b/tools/xl/xl_parse.c > @@ -1306,6 +1306,18 @@ static int parse_arm_sci_config(XLU_Config *cfg, libxl_arm_sci *arm_sci, > } > } > > + if (MATCH_OPTION("agent_id", ptr, oparg)) { > + unsigned long val = parse_ulong(oparg); > + > + if (!val || val > 255) { > + fprintf(stderr, "An invalid ARM_SCI agent_id specified (%lu). Valid range [1..255]\n", > + val); > + ret = ERROR_INVAL; > + goto out; > + } > + arm_sci->agent_id = val; > + } > + > ptr = strtok(NULL, ","); > } > > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c > index 4181c10538..ddadc89148 100644 > --- a/xen/arch/arm/dom0less-build.c > +++ b/xen/arch/arm/dom0less-build.c > @@ -299,6 +299,17 @@ static int __init domu_dt_sci_parse(struct dt_device_node *node, > d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_NONE; > else if ( !strcmp(sci_type, "scmi_smc") ) > d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; > + else if ( !strcmp(sci_type, "scmi_smc_multiagent") ) > + { > + uint32_t agent_id = 0; > + > + if ( !dt_property_read_u32(node, "xen,sci-agent-id", &agent_id) || > + agent_id > UINT8_MAX ) > + return -EINVAL; > + > + d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA; > + d_cfg->arch.arm_sci_agent_id = agent_id; > + } > else > { > printk(XENLOG_ERR "xen,sci_type in not valid (%s) for domain %s\n", > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > index fb8fbb1650..794ea1aa42 100644 > --- a/xen/arch/arm/domain_build.c > +++ b/xen/arch/arm/domain_build.c > @@ -55,6 +55,10 @@ boolean_param("ext_regions", opt_ext_regions); > static u64 __initdata dom0_mem; > static bool __initdata dom0_mem_set; > > +/* SCMI agent ID for dom0, parsed from dom0=sci-agent-id= */ > +#define SCMI_AGENT_ID_INVALID 0xFF > +static uint8_t __initdata opt_dom0_scmi_agent_id = SCMI_AGENT_ID_INVALID; > + > static int __init parse_dom0_mem(const char *s) > { > dom0_mem_set = true; > @@ -83,6 +87,16 @@ int __init parse_arch_dom0_param(const char *s, const char *e) > #endif > } > > + if ( !parse_signed_integer("sci-agent-id", s, e, &val) ) > + { > + if ( (val >= 0) && (val <= UINT8_MAX) ) > + opt_dom0_scmi_agent_id = val; we should prevent SCMI_AGENT_ID_INVALID from being assigned > + else > + printk(XENLOG_INFO "'sci-agent-id=%lld' value out of range!\n", val); > + > + return 0; > + } > + > return -EINVAL; > } > > @@ -509,7 +523,8 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo, > dt_property_name_is_equal(prop, "linux,uefi-mmap-start") || > dt_property_name_is_equal(prop, "linux,uefi-mmap-size") || > dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-size") || > - dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-ver")) > + dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-ver") || > + dt_property_name_is_equal(prop, "xen,config") ) should be updated > continue; > > if ( dt_property_name_is_equal(prop, "xen,dom0-bootargs") ) > @@ -2067,6 +2082,15 @@ void __init create_dom0(void) > dom0_cfg.arch.tee_type = tee_get_type(); > dom0_cfg.max_vcpus = dom0_max_vcpus(); > > + /* Set up SCMI agent ID if specified in dom0= command line */ > + if ( opt_dom0_scmi_agent_id != SCMI_AGENT_ID_INVALID ) > + { > + dom0_cfg.arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA; > + dom0_cfg.arch.arm_sci_agent_id = opt_dom0_scmi_agent_id; > + } > + else > + dom0_cfg.arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_NONE; > + > if ( iommu_enabled ) > dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu; > > diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig > index 5c5f0880c4..972cd9b173 100644 > --- a/xen/arch/arm/firmware/Kconfig > +++ b/xen/arch/arm/firmware/Kconfig > @@ -29,6 +29,18 @@ config SCMI_SMC > driver domain. > Use with EL3 firmware which supports only single SCMI OSPM agent. > > +config SCMI_SMC_MA > + bool "Enable ARM SCMI SMC multi-agent driver" > + depends on ARM_64 > + select ARM_SCI > + help > + Enables SCMI SMC/HVC multi-agent in XEN to pass SCMI requests from Domains > + to EL3 firmware (TF-A) which supports multi-agent feature. > + This feature allows to enable SCMI per Domain using unique SCMI agent_id, > + so Domain is identified by EL3 firmware as an SCMI Agent and can access > + allowed platform resources through dedicated SMC/HVC Shared memory based > + transport. > + > endchoice > > endmenu > diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefile > index 71bdefc24a..37927e690e 100644 > --- a/xen/arch/arm/firmware/Makefile > +++ b/xen/arch/arm/firmware/Makefile > @@ -1,2 +1,3 @@ > obj-$(CONFIG_ARM_SCI) += sci.o > obj-$(CONFIG_SCMI_SMC) += scmi-smc.o > +obj-$(CONFIG_SCMI_SMC_MA) += scmi-shmem.o scmi-smc-multiagent.o > diff --git a/xen/arch/arm/firmware/scmi-proto.h b/xen/arch/arm/firmware/scmi-proto.h > new file mode 100644 > index 0000000000..49f63cfc0a > --- /dev/null > +++ b/xen/arch/arm/firmware/scmi-proto.h > @@ -0,0 +1,164 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Arm System Control and Management Interface definitions > + * Version 3.0 (DEN0056C) > + * > + * Copyright (c) 2025 EPAM Systems > + */ > + > +#ifndef ARM_FIRMWARE_SCMI_PROTO_H_ > +#define ARM_FIRMWARE_SCMI_PROTO_H_ > + > +#include > + > +#define SCMI_SHORT_NAME_MAX_SIZE 16 > + > +/* SCMI status codes. See section 4.1.4 */ > +#define SCMI_SUCCESS 0 > +#define SCMI_NOT_SUPPORTED (-1) > +#define SCMI_INVALID_PARAMETERS (-2) > +#define SCMI_DENIED (-3) > +#define SCMI_NOT_FOUND (-4) > +#define SCMI_OUT_OF_RANGE (-5) > +#define SCMI_BUSY (-6) > +#define SCMI_COMMS_ERROR (-7) > +#define SCMI_GENERIC_ERROR (-8) > +#define SCMI_HARDWARE_ERROR (-9) > +#define SCMI_PROTOCOL_ERROR (-10) > + > +/* Protocol IDs */ > +#define SCMI_BASE_PROTOCOL 0x10 > + > +/* Base protocol message IDs */ > +#define SCMI_BASE_PROTOCOL_VERSION 0x0 > +#define SCMI_BASE_PROTOCOL_ATTIBUTES 0x1 > +#define SCMI_BASE_PROTOCOL_MESSAGE_ATTRIBUTES 0x2 > +#define SCMI_BASE_DISCOVER_AGENT 0x7 > +#define SCMI_BASE_SET_DEVICE_PERMISSIONS 0x9 > +#define SCMI_BASE_RESET_AGENT_CONFIGURATION 0xB > + > +typedef struct scmi_msg_header { > + uint8_t id; > + uint8_t type; > + uint8_t protocol; > + uint32_t status; > +} scmi_msg_header_t; > + > +/* Table 2 Message header format */ > +#define SCMI_HDR_ID GENMASK(7, 0) > +#define SCMI_HDR_TYPE GENMASK(9, 8) > +#define SCMI_HDR_PROTO GENMASK(17, 10) > + > +#define SCMI_FIELD_GET(_mask, _reg) \ > + ((typeof(_mask))(((_reg) & (_mask)) >> (ffs64(_mask) - 1))) > +#define SCMI_FIELD_PREP(_mask, _val) \ > + (((typeof(_mask))(_val) << (ffs64(_mask) - 1)) & (_mask)) > + > +static inline uint32_t pack_scmi_header(scmi_msg_header_t *hdr) > +{ > + return SCMI_FIELD_PREP(SCMI_HDR_ID, hdr->id) | > + SCMI_FIELD_PREP(SCMI_HDR_TYPE, hdr->type) | > + SCMI_FIELD_PREP(SCMI_HDR_PROTO, hdr->protocol); > +} > + > +static inline void unpack_scmi_header(uint32_t msg_hdr, scmi_msg_header_t *hdr) > +{ > + hdr->id = SCMI_FIELD_GET(SCMI_HDR_ID, msg_hdr); > + hdr->type = SCMI_FIELD_GET(SCMI_HDR_TYPE, msg_hdr); > + hdr->protocol = SCMI_FIELD_GET(SCMI_HDR_PROTO, msg_hdr); > +} > + > +static inline int scmi_to_xen_errno(int scmi_status) > +{ > + if ( scmi_status == SCMI_SUCCESS ) > + return 0; > + > + switch ( scmi_status ) > + { > + case SCMI_NOT_SUPPORTED: > + return -EOPNOTSUPP; > + case SCMI_INVALID_PARAMETERS: > + return -EINVAL; > + case SCMI_DENIED: > + return -EACCES; > + case SCMI_NOT_FOUND: > + return -ENOENT; > + case SCMI_OUT_OF_RANGE: > + return -ERANGE; > + case SCMI_BUSY: > + return -EBUSY; > + case SCMI_COMMS_ERROR: > + return -ENOTCONN; > + case SCMI_GENERIC_ERROR: > + return -EIO; > + case SCMI_HARDWARE_ERROR: > + return -ENXIO; > + case SCMI_PROTOCOL_ERROR: > + return -EBADMSG; > + default: > + return -EINVAL; > + } > +} > + > +/* PROTOCOL_VERSION */ > +#define SCMI_VERSION_MINOR GENMASK(15, 0) > +#define SCMI_VERSION_MAJOR GENMASK(31, 16) > + > +struct scmi_msg_prot_version_p2a { > + uint32_t version; > +} __packed; > + > +/* BASE PROTOCOL_ATTRIBUTES */ > +#define SCMI_BASE_ATTR_NUM_PROTO GENMASK(7, 0) > +#define SCMI_BASE_ATTR_NUM_AGENT GENMASK(15, 8) > + > +struct scmi_msg_base_attributes_p2a { > + uint32_t attributes; > +} __packed; > + > +/* > + * BASE_DISCOVER_AGENT > + */ > +#define SCMI_BASE_AGENT_ID_OWN 0xFFFFFFFF > + > +struct scmi_msg_base_discover_agent_a2p { > + uint32_t agent_id; > +} __packed; > + > +struct scmi_msg_base_discover_agent_p2a { > + uint32_t agent_id; > + char name[SCMI_SHORT_NAME_MAX_SIZE]; > +} __packed; > + > +/* > + * BASE_SET_DEVICE_PERMISSIONS > + */ > +#define SCMI_BASE_DEVICE_ACCESS_ALLOW BIT(0, UL) > + > +struct scmi_msg_base_set_device_permissions_a2p { > + uint32_t agent_id; > + uint32_t device_id; > + uint32_t flags; > +} __packed; > + > +/* > + * BASE_RESET_AGENT_CONFIGURATION > + */ > +#define SCMI_BASE_AGENT_PERMISSIONS_RESET BIT(0, UL) > + > +struct scmi_msg_base_reset_agent_cfg_a2p { > + uint32_t agent_id; > + uint32_t flags; > +} __packed; > + > +#endif /* ARM_FIRMWARE_SCMI_PROTO_H_ */ > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * tab-width: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/arch/arm/firmware/scmi-shmem.c b/xen/arch/arm/firmware/scmi-shmem.c > new file mode 100644 > index 0000000000..112507ba2a > --- /dev/null > +++ b/xen/arch/arm/firmware/scmi-shmem.c > @@ -0,0 +1,115 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * SMC/HVC shmem transport implementation used by > + * SCI SCMI multi-agent driver. > + * > + * Oleksii Moisieiev > + * Copyright (c) 2025 EPAM Systems > + */ > +/* SPDX-License-Identifier: GPL-2.0-only */ > + > +#include > +#include > +#include > + > +#include "scmi-proto.h" > +#include "scmi-shmem.h" > + > +static inline int > +shmem_channel_is_free(const volatile struct scmi_shared_mem __iomem *shmem) > +{ > + return (readl(&shmem->channel_status) & > + SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE) ? 0 : -EBUSY; > +} > + > +int shmem_put_message(volatile struct scmi_shared_mem __iomem *shmem, > + scmi_msg_header_t *hdr, void *data, int len) > +{ > + int ret; > + > + if ( (len + offsetof(struct scmi_shared_mem, msg_payload)) > > + SCMI_SHMEM_MAPPED_SIZE ) > + { > + printk(XENLOG_ERR "scmi: Wrong size of smc message. Data is invalid\n"); > + return -EINVAL; > + } > + > + ret = shmem_channel_is_free(shmem); > + if ( ret ) > + return ret; > + > + writel_relaxed(0x0, &shmem->channel_status); > + /* Writing 0x0 right now, but "shmem"_FLAG_INTR_ENABLED can be set */ > + writel_relaxed(0x0, &shmem->flags); > + writel_relaxed(sizeof(shmem->msg_header) + len, &shmem->length); > + writel(pack_scmi_header(hdr), &shmem->msg_header); > + > + if ( len > 0 && data ) > + memcpy_toio(shmem->msg_payload, data, len); > + > + return 0; > +} > + > +int shmem_get_response(const volatile struct scmi_shared_mem __iomem *shmem, > + scmi_msg_header_t *hdr, void *data, int len) > +{ > + int recv_len; > + int ret; > + int pad = sizeof(hdr->status); > + > + if ( len >= SCMI_SHMEM_MAPPED_SIZE - > + offsetof(struct scmi_shared_mem, msg_payload) ) > + { > + printk(XENLOG_ERR > + "scmi: Wrong size of input smc message. Data may be invalid\n"); > + return -EINVAL; > + } > + > + ret = shmem_channel_is_free(shmem); > + if ( ret ) > + return ret; > + > + recv_len = readl(&shmem->length) - sizeof(shmem->msg_header); > + > + if ( recv_len < 0 ) > + { > + printk(XENLOG_ERR > + "scmi: Wrong size of smc message. Data may be invalid\n"); > + return -EINVAL; > + } > + > + unpack_scmi_header(readl(&shmem->msg_header), hdr); > + > + hdr->status = readl(&shmem->msg_payload); > + recv_len = recv_len > pad ? recv_len - pad : 0; > + > + ret = scmi_to_xen_errno(hdr->status); > + if ( ret ) > + { > + printk(XENLOG_DEBUG "scmi: Error received: %d\n", ret); > + return ret; > + } > + > + if ( recv_len > len ) > + { > + printk(XENLOG_ERR > + "scmi: Not enough buffer for message %d, expecting %d\n", > + recv_len, len); > + return -EINVAL; > + } > + > + if ( recv_len > 0 ) > + memcpy_fromio(data, shmem->msg_payload + pad, recv_len); > + > + return 0; > +} > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * tab-width: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/arch/arm/firmware/scmi-shmem.h b/xen/arch/arm/firmware/scmi-shmem.h > new file mode 100644 > index 0000000000..7313cb6b26 > --- /dev/null > +++ b/xen/arch/arm/firmware/scmi-shmem.h > @@ -0,0 +1,45 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Arm System Control and Management Interface definitions > + * Version 3.0 (DEN0056C) > + * Shared Memory based Transport > + * > + * Copyright (c) 2024 EPAM Systems > + */ > + > +#ifndef ARM_FIRMWARE_SCMI_SHMEM_H_ > +#define ARM_FIRMWARE_SCMI_SHMEM_H_ > + > +#include > + > +#define SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE BIT(0, UL) > +#define SCMI_SHMEM_CHAN_STAT_CHANNEL_ERROR BIT(1, UL) > + > +struct scmi_shared_mem { > + uint32_t reserved; > + uint32_t channel_status; > + uint32_t reserved1[2]; > + uint32_t flags; > + uint32_t length; > + uint32_t msg_header; > + uint8_t msg_payload[]; > +}; > + > +#define SCMI_SHMEM_MAPPED_SIZE PAGE_SIZE > + > +int shmem_put_message(volatile struct scmi_shared_mem __iomem *shmem, > + scmi_msg_header_t *hdr, void *data, int len); > + > +int shmem_get_response(const volatile struct scmi_shared_mem __iomem *shmem, > + scmi_msg_header_t *hdr, void *data, int len); > +#endif /* ARM_FIRMWARE_SCMI_SHMEM_H_ */ > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * tab-width: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/arch/arm/firmware/scmi-smc-multiagent.c b/xen/arch/arm/firmware/scmi-smc-multiagent.c > new file mode 100644 > index 0000000000..b79041daba > --- /dev/null > +++ b/xen/arch/arm/firmware/scmi-smc-multiagent.c > @@ -0,0 +1,815 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * SCI SCMI multi-agent driver, using SMC/HVC shmem as transport. > + * > + * Oleksii Moisieiev > + * Copyright (c) 2025 EPAM Systems > + */ > + > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > + > +#include "scmi-proto.h" > +#include "scmi-shmem.h" > + > +#define SCMI_AGENT_ID_INVALID 0xFF > + > +#define SCMI_SECONDARY_AGENTS "scmi-secondary-agents" > + > +struct scmi_channel { > + uint32_t agent_id; > + uint32_t func_id; > + domid_t domain_id; > + uint64_t paddr; > + struct scmi_shared_mem __iomem *shmem; > + spinlock_t lock; > + struct list_head list; > +}; > + > +struct scmi_data { > + struct list_head channel_list; > + spinlock_t channel_list_lock; > + uint32_t func_id; > + bool initialized; > + uint32_t shmem_phandle; > + uint32_t hyp_channel_agent_id; > + struct dt_device_node *dt_dev; > +}; > + > +static struct scmi_data scmi_data; > + > +static bool scmi_is_under_xen_sci(const struct dt_device_node *node) > +{ > + const struct dt_device_node *p; > + > + for ( p = node->parent; p; p = p->parent ) > + if ( dt_device_is_compatible(p, "xen,sci") ) > + return true; > + > + return false; > +} > + > +static int send_smc_message(struct scmi_channel *chan_info, > + scmi_msg_header_t *hdr, void *data, int len) > +{ > + struct arm_smccc_res resp; > + int ret; > + > + ret = shmem_put_message(chan_info->shmem, hdr, data, len); > + if ( ret ) > + return ret; > + > + arm_smccc_1_1_smc(chan_info->func_id, 0, 0, 0, 0, 0, 0, 0, &resp); > + > + if ( resp.a0 == ARM_SMCCC_INVALID_PARAMETER ) > + return -EINVAL; > + > + if ( resp.a0 ) > + return -EOPNOTSUPP; > + > + return 0; > +} > + > +static int do_smc_xfer(struct scmi_channel *chan_info, scmi_msg_header_t *hdr, > + void *tx_data, int tx_size, void *rx_data, int rx_size) > +{ > + int ret = 0; > + > + ASSERT(chan_info && chan_info->shmem); > + > + if ( !hdr ) > + return -EINVAL; > + > + spin_lock(&chan_info->lock); > + > + printk(XENLOG_DEBUG > + "scmi: agent_id = %d msg_id = %x type = %d, proto = %x\n", > + chan_info->agent_id, hdr->id, hdr->type, hdr->protocol); > + > + ret = send_smc_message(chan_info, hdr, tx_data, tx_size); > + if ( ret ) > + goto clean; > + > + ret = shmem_get_response(chan_info->shmem, hdr, rx_data, rx_size); > + > +clean: > + printk(XENLOG_DEBUG > + "scmi: get smc response agent_id = %d msg_id = %x proto = %x res=%d\n", > + chan_info->agent_id, hdr->id, hdr->protocol, ret); > + > + spin_unlock(&chan_info->lock); > + > + return ret; > +} > + > +static struct scmi_channel *get_channel_by_id(uint32_t agent_id) > +{ > + struct scmi_channel *curr; > + bool found = false; > + > + spin_lock(&scmi_data.channel_list_lock); > + list_for_each_entry(curr, &scmi_data.channel_list, list) > + { > + if ( curr->agent_id == agent_id ) > + { > + found = true; > + break; > + } > + } > + > + spin_unlock(&scmi_data.channel_list_lock); > + if ( found ) > + return curr; > + > + return NULL; > +} > + > +static struct scmi_channel *acquire_scmi_channel(struct domain *d, > + uint32_t agent_id) > +{ > + struct scmi_channel *curr; > + struct scmi_channel *ret = ERR_PTR(-ENOENT); > + > + spin_lock(&scmi_data.channel_list_lock); > + list_for_each_entry(curr, &scmi_data.channel_list, list) > + { > + if ( curr->agent_id == agent_id ) > + { > + if ( curr->domain_id != DOMID_INVALID ) > + { > + ret = ERR_PTR(-EEXIST); > + break; > + } > + > + curr->domain_id = d->domain_id; > + ret = curr; > + break; > + } > + } > + > + spin_unlock(&scmi_data.channel_list_lock); > + > + return ret; > +} > + > +static void relinquish_scmi_channel(struct scmi_channel *channel) > +{ > + ASSERT(channel != NULL); > + > + spin_lock(&scmi_data.channel_list_lock); > + channel->domain_id = DOMID_INVALID; > + spin_unlock(&scmi_data.channel_list_lock); > +} > + > +static int map_channel_memory(struct scmi_channel *channel) > +{ > + ASSERT(channel && channel->paddr); > + channel->shmem = ioremap_nocache(channel->paddr, SCMI_SHMEM_MAPPED_SIZE); > + if ( !channel->shmem ) > + return -ENOMEM; > + > + channel->shmem->channel_status = SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE; > + printk(XENLOG_DEBUG "scmi: Got shmem %lx after vmap %p\n", channel->paddr, > + channel->shmem); > + > + return 0; > +} > + > +static void unmap_channel_memory(struct scmi_channel *channel) > +{ > + ASSERT(channel && channel->shmem); > + iounmap(channel->shmem); > + channel->shmem = NULL; > +} > + > +static struct scmi_channel *smc_create_channel(uint32_t agent_id, > + uint32_t func_id, uint64_t addr) > +{ > + struct scmi_channel *channel, *curr; > + > + spin_lock(&scmi_data.channel_list_lock); > + > + /* Check if channel already exists while holding the lock */ > + list_for_each_entry(curr, &scmi_data.channel_list, list) > + { > + if ( curr->agent_id == agent_id ) > + { > + spin_unlock(&scmi_data.channel_list_lock); > + return ERR_PTR(-EEXIST); > + } > + } > + > + channel = xmalloc(struct scmi_channel); > + if ( !channel ) > + { > + spin_unlock(&scmi_data.channel_list_lock); > + return ERR_PTR(-ENOMEM); > + } > + > + spin_lock_init(&channel->lock); > + channel->agent_id = agent_id; > + channel->func_id = func_id; > + channel->domain_id = DOMID_INVALID; > + channel->shmem = NULL; > + channel->paddr = addr; > + list_add_tail(&channel->list, &scmi_data.channel_list); > + > + spin_unlock(&scmi_data.channel_list_lock); > + return channel; > +} > + > +static void free_channel_list(void) > +{ > + struct scmi_channel *curr, *_curr; > + > + list_for_each_entry_safe(curr, _curr, &scmi_data.channel_list, list) > + { > + list_del(&curr->list); > + xfree(curr); > + } > +} > + > +static int __init > +scmi_dt_read_hyp_channel_addr(struct dt_device_node *scmi_node, u64 *addr, > + u64 *size) > +{ > + struct dt_device_node *shmem_node; > + const __be32 *prop; > + > + prop = dt_get_property(scmi_node, "shmem", NULL); > + if ( !prop ) > + return -EINVAL; > + > + shmem_node = dt_find_node_by_phandle(be32_to_cpu(*prop)); > + if ( IS_ERR_OR_NULL(shmem_node) ) > + { > + printk(XENLOG_ERR > + "scmi: Device tree error, can't parse reserved memory %ld\n", > + PTR_ERR(shmem_node)); > + return PTR_ERR(shmem_node); > + } > + > + return dt_device_get_address(shmem_node, 0, addr, size); > +} > + > +/* > + * Handle Dom0 SCMI specific DT nodes > + * > + * Make a decision on copying SCMI specific nodes into Dom0 device tree. > + * For SCMI multi-agent case: > + * - shmem nodes will not be copied and generated instead if SCMI > + * is enabled for Dom0 > + * - scmi node will be copied if SCMI is enabled for Dom0 > + */ > +static bool scmi_dt_handle_node(struct domain *d, struct dt_device_node *node) > +{ > + static const struct dt_device_match shmem_matches[] __initconst = { > + DT_MATCH_COMPATIBLE("arm,scmi-shmem"), > + { /* sentinel */ }, > + }; > + static const struct dt_device_match scmi_matches[] __initconst = { > + DT_MATCH_PATH("/firmware/scmi"), > + { /* sentinel */ }, > + }; > + > + if ( !scmi_data.initialized ) > + return false; > + > + /* 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; > + } > + > + /* drop scmi if not enabled */ > + if ( dt_match_node(scmi_matches, node) && !sci_domain_is_enabled(d) ) > + { > + dt_dprintk(" Skip scmi node\n"); > + return true; > + } > + > + return false; > +} > + > +static int scmi_assign_device(uint32_t agent_id, uint32_t device_id, > + uint32_t flags) > +{ > + struct scmi_msg_base_set_device_permissions_a2p tx; > + struct scmi_channel *channel; > + scmi_msg_header_t hdr; > + > + channel = get_channel_by_id(scmi_data.hyp_channel_agent_id); > + if ( !channel ) > + return -EINVAL; > + > + hdr.id = SCMI_BASE_SET_DEVICE_PERMISSIONS; > + hdr.type = 0; > + hdr.protocol = SCMI_BASE_PROTOCOL; > + > + tx.agent_id = agent_id; > + tx.device_id = device_id; > + tx.flags = flags; > + > + return do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0); > +} > + > +static int scmi_dt_assign_device(struct domain *d, > + struct dt_phandle_args *ac_spec) > +{ > + struct scmi_channel *agent_channel; > + uint32_t scmi_device_id = ac_spec->args[0]; > + int ret; > + > + if ( !d->arch.sci_data ) > + return 0; > + > + /* The access-controllers is specified for DT dev, but it's not a SCMI */ > + if ( ac_spec->np != scmi_data.dt_dev ) > + return 0; > + > + agent_channel = d->arch.sci_data; > + > + spin_lock(&agent_channel->lock); > + > + ret = scmi_assign_device(agent_channel->agent_id, scmi_device_id, > + SCMI_BASE_DEVICE_ACCESS_ALLOW); > + if ( ret ) > + { > + printk(XENLOG_ERR > + "scmi: could not assign dev for %pd agent:%d dev_id:%u (%d)", > + d, agent_channel->agent_id, scmi_device_id, ret); > + } > + > + spin_unlock(&agent_channel->lock); > + return ret; > +} > + > +static int collect_agent_id(struct scmi_channel *agent_channel) > +{ > + int ret; > + scmi_msg_header_t hdr; > + struct scmi_msg_base_discover_agent_p2a da_rx; > + struct scmi_msg_base_discover_agent_a2p da_tx; > + > + ret = map_channel_memory(agent_channel); > + if ( ret ) > + return ret; > + > + hdr.id = SCMI_BASE_DISCOVER_AGENT; > + hdr.type = 0; > + hdr.protocol = SCMI_BASE_PROTOCOL; > + > + da_tx.agent_id = agent_channel->agent_id; > + > + ret = do_smc_xfer(agent_channel, &hdr, &da_tx, sizeof(da_tx), &da_rx, > + sizeof(da_rx)); > + if ( agent_channel->domain_id != DOMID_XEN ) > + unmap_channel_memory(agent_channel); > + if ( ret ) > + return ret; > + > + printk(XENLOG_DEBUG "id=0x%x name=%s\n", da_rx.agent_id, da_rx.name); > + agent_channel->agent_id = da_rx.agent_id; > + return 0; > +} > + > +static __init int collect_agents(struct dt_device_node *scmi_node) > +{ > + const struct dt_device_node *config_node; > + const __be32 *prop; > + uint32_t len; > + const __be32 *end; > + uint32_t cells_per_entry = 3; /* Default to 3 cells if property is absent. */ > + > + config_node = dt_find_compatible_node(NULL, NULL, "xen,sci"); > + if ( !config_node ) > + { > + printk(XENLOG_WARNING "scmi: xen,sci node not found, no agents to collect.\n"); > + return -ENOENT; > + } > + > + /* Check for the optional '#scmi-secondary-agents-cells' property. */ > + if ( dt_property_read_u32(config_node, "#scmi-secondary-agents-cells", > + &cells_per_entry) ) > + { > + if ( cells_per_entry != 2 && cells_per_entry != 3 ) > + { > + printk(XENLOG_ERR "scmi: Invalid #scmi-secondary-agents-cells value: %u\n", > + cells_per_entry); > + return -EINVAL; > + } > + } > + > + prop = dt_get_property(config_node, SCMI_SECONDARY_AGENTS, &len); > + if ( !prop ) > + { > + printk(XENLOG_ERR "scmi: No %s property found, no agents to collect.\n", > + SCMI_SECONDARY_AGENTS); > + return -EINVAL; > + } > + > + /* Validate that the property length is a multiple of the cell size. */ > + if ( len == 0 || len % (cells_per_entry * sizeof(uint32_t)) != 0 ) > + { > + printk(XENLOG_ERR "scmi: Invalid length of %s property: %u for %u cells per entry\n", > + SCMI_SECONDARY_AGENTS, len, cells_per_entry); > + return -EINVAL; > + } > + > + end = (const __be32 *)((const u8 *)prop + len); > + > + for ( ; prop < end; ) > + { > + uint32_t agent_id; > + uint32_t smc_id; > + uint32_t shmem_phandle; > + struct dt_device_node *node; > + u64 addr, size; > + int ret; > + struct scmi_channel *agent_channel; > + > + smc_id = be32_to_cpu(*prop++); > + shmem_phandle = be32_to_cpu(*prop++); > + > + if ( cells_per_entry == 3 ) > + agent_id = be32_to_cpu(*prop++); > + else > + agent_id = SCMI_BASE_AGENT_ID_OWN; > + > + node = dt_find_node_by_phandle(shmem_phandle); > + if ( !node ) > + { > + printk(XENLOG_ERR "scmi: Could not find shmem node for agent %u\n", > + agent_id); > + return -EINVAL; > + } > + > + ret = dt_device_get_address(node, 0, &addr, &size); > + if ( ret ) > + { > + printk(XENLOG_ERR > + "scmi: Could not read shmem address for agent %u: %d\n", > + agent_id, ret); > + return ret; > + } > + > + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) ) > + { > + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); > + return -EINVAL; > + } > + > + agent_channel = smc_create_channel(agent_id, smc_id, addr); > + if ( IS_ERR(agent_channel) ) > + { > + printk(XENLOG_ERR "scmi: Could not create channel for agent %u: %ld\n", > + agent_id, PTR_ERR(agent_channel)); > + return PTR_ERR(agent_channel); > + } > + > + if ( cells_per_entry == 2 ) > + { > + ret = collect_agent_id(agent_channel); > + if ( ret ) > + return ret; > + } aren't we missing a call to map_channel_memory in the other case? > + > + printk(XENLOG_DEBUG "scmi: Agent %u SMC %X addr %lx\n", agent_channel->agent_id, > + smc_id, (unsigned long)addr); > + } > + > + return 0; > +} > + > +static int scmi_domain_init(struct domain *d, > + struct xen_domctl_createdomain *config) > +{ > + struct scmi_channel *channel; > + int ret; > + > + if ( !scmi_data.initialized ) > + return 0; > + > + /* > + * SCMI support is configured via: > + * - For dom0: dom0=sci-agent-id= in Xen command line > + * - For dom0less: xen,sci-agent-id in device tree > + * The config->arch.arm_sci_type and config->arch.arm_sci_agent_id > + * are already set by domain_build.c or dom0less-build.c > + */ > + > + if ( config->arch.arm_sci_type == XEN_DOMCTL_CONFIG_ARM_SCI_NONE ) > + return 0; > + > + channel = acquire_scmi_channel(d, config->arch.arm_sci_agent_id); > + if ( IS_ERR(channel) ) > + { > + printk(XENLOG_ERR > + "scmi: Failed to acquire SCMI channel for agent_id %u: %ld\n", > + config->arch.arm_sci_agent_id, PTR_ERR(channel)); > + return PTR_ERR(channel); > + } > + > + printk(XENLOG_INFO > + "scmi: Acquire channel id = 0x%x, domain_id = %d paddr = 0x%lx\n", > + channel->agent_id, channel->domain_id, channel->paddr); > + > + /* > + * Dom0 (if present) needs to have an access to the guest memory range > + * to satisfy iomem_access_permitted() check in XEN_DOMCTL_iomem_permission > + * domctl. > + */ > + if ( hardware_domain && !is_hardware_domain(d) ) > + { > + ret = iomem_permit_access(hardware_domain, paddr_to_pfn(channel->paddr), > + paddr_to_pfn(channel->paddr + PAGE_SIZE - 1)); > + if ( ret ) > + goto error; > + } > + > + d->arch.sci_data = channel; > + d->arch.sci_enabled = true; > + > + return 0; > + > +error: > + relinquish_scmi_channel(channel); > + return ret; > +} > + > +int scmi_domain_sanitise_config(struct xen_domctl_createdomain *config) > +{ > + if ( config->arch.arm_sci_type != XEN_DOMCTL_CONFIG_ARM_SCI_NONE && > + config->arch.arm_sci_type != XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA ) > + { > + dprintk(XENLOG_INFO, "scmi: Unsupported ARM_SCI type\n"); > + return -EINVAL; > + } > + > + return 0; > +} > + > +static int scmi_relinquish_resources(struct domain *d) > +{ > + int ret; > + struct scmi_channel *channel, *agent_channel; > + scmi_msg_header_t hdr; > + struct scmi_msg_base_reset_agent_cfg_a2p tx; > + > + if ( !d->arch.sci_data ) > + return 0; > + > + agent_channel = d->arch.sci_data; > + > + spin_lock(&agent_channel->lock); > + tx.agent_id = agent_channel->agent_id; > + spin_unlock(&agent_channel->lock); > + > + channel = get_channel_by_id(scmi_data.hyp_channel_agent_id); > + if ( !channel ) > + { > + printk(XENLOG_ERR > + "scmi: Unable to get Hypervisor scmi channel for domain %d\n", > + d->domain_id); > + return -EINVAL; > + } > + > + hdr.id = SCMI_BASE_RESET_AGENT_CONFIGURATION; > + hdr.type = 0; > + hdr.protocol = SCMI_BASE_PROTOCOL; > + > + tx.flags = 0; > + > + ret = do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0); > + if ( ret == -EOPNOTSUPP ) > + return 0; > + > + return ret; > +} > + > +static void scmi_domain_destroy(struct domain *d) > +{ > + struct scmi_channel *channel; > + > + if ( !d->arch.sci_data ) > + return; > + > + channel = d->arch.sci_data; > + spin_lock(&channel->lock); > + > + relinquish_scmi_channel(channel); > + printk(XENLOG_DEBUG "scmi: Free domain %d\n", d->domain_id); > + > + d->arch.sci_data = NULL; > + d->arch.sci_enabled = false; > + > + spin_unlock(&channel->lock); > +} > + > +static bool scmi_handle_call(struct cpu_user_regs *regs) > +{ > + uint32_t fid = (uint32_t)get_user_reg(regs, 0); > + struct scmi_channel *agent_channel; > + struct domain *d = current->domain; > + struct arm_smccc_res resp; > + bool res = false; > + > + if ( !sci_domain_is_enabled(d) ) > + return false; > + > + agent_channel = d->arch.sci_data; > + spin_lock(&agent_channel->lock); > + > + if ( agent_channel->func_id != fid ) > + { > + res = false; > + goto unlock; > + } > + > + arm_smccc_1_1_smc(fid, > + get_user_reg(regs, 1), > + get_user_reg(regs, 2), > + get_user_reg(regs, 3), > + get_user_reg(regs, 4), > + get_user_reg(regs, 5), > + get_user_reg(regs, 6), > + get_user_reg(regs, 7), > + &resp); > + > + set_user_reg(regs, 0, resp.a0); > + set_user_reg(regs, 1, resp.a1); > + set_user_reg(regs, 2, resp.a2); > + set_user_reg(regs, 3, resp.a3); > + res = true; > +unlock: > + spin_unlock(&agent_channel->lock); > + > + return res; > +} > + > +static const struct sci_mediator_ops scmi_ops = { > + .domain_init = scmi_domain_init, > + .domain_destroy = scmi_domain_destroy, > + .relinquish_resources = scmi_relinquish_resources, > + .handle_call = scmi_handle_call, > + .dom0_dt_handle_node = scmi_dt_handle_node, > + .domain_sanitise_config = scmi_domain_sanitise_config, > + .assign_dt_device = scmi_dt_assign_device, > +}; > + > +static int __init scmi_check_smccc_ver(void) > +{ > + if ( smccc_ver < ARM_SMCCC_VERSION_1_1 ) > + { > + printk(XENLOG_WARNING > + "scmi: No SMCCC 1.1 support, SCMI calls forwarding disabled\n"); > + return -ENOSYS; > + } > + > + return 0; > +} > + > +static int __init scmi_dt_hyp_channel_read(struct dt_device_node *scmi_node, > + struct scmi_data *scmi_data, > + u64 *addr) > +{ > + int ret; > + u64 size; > + > + if ( !dt_property_read_u32(scmi_node, "arm,smc-id", &scmi_data->func_id) ) > + { > + printk(XENLOG_ERR "scmi: unable to read smc-id from DT\n"); > + return -ENOENT; > + } > + > + ret = scmi_dt_read_hyp_channel_addr(scmi_node, addr, &size); > + if ( IS_ERR_VALUE(ret) ) > + return -ENOENT; > + > + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) ) > + { > + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); > + return -EINVAL; > + } > + > + return 0; > +} > + > +static __init int scmi_probe(struct dt_device_node *scmi_node, const void *data) > +{ > + u64 addr; > + int ret; > + struct scmi_channel *channel; > + unsigned int n_agents; > + scmi_msg_header_t hdr; > + struct scmi_msg_base_attributes_p2a rx; > + > + ASSERT(scmi_node != NULL); > + > + /* > + * Only bind to the SCMI node provided by Xen under the xen,sci container > + * (e.g. /chosen/xen/xen_scmi_config/scmi). This avoids binding to firmware > + * SCMI nodes that belong to the host OSPM and keeps the mediator scoped to > + * Xen-provided configuration only. > + */ > + if ( !scmi_is_under_xen_sci(scmi_node) ) > + return -ENODEV; > + > + INIT_LIST_HEAD(&scmi_data.channel_list); > + spin_lock_init(&scmi_data.channel_list_lock); > + > + if ( !acpi_disabled ) > + { > + printk(XENLOG_WARNING "scmi: is not supported when using ACPI\n"); > + return -EINVAL; > + } > + > + ret = scmi_check_smccc_ver(); > + if ( ret ) > + return ret; > + > + ret = scmi_dt_hyp_channel_read(scmi_node, &scmi_data, &addr); > + if ( ret ) > + return ret; > + > + scmi_data.dt_dev = scmi_node; > + > + channel = smc_create_channel(SCMI_BASE_AGENT_ID_OWN, scmi_data.func_id, addr); > + if ( IS_ERR(channel) ) > + goto out; > + > + /* Mark as Xen management channel before collecting agent ID */ > + channel->domain_id = DOMID_XEN; > + > + /* Request agent id for Xen management channel */ > + ret = collect_agent_id(channel); > + if ( ret ) > + goto error; > + > + /* Save the agent id for Xen management channel */ > + scmi_data.hyp_channel_agent_id = channel->agent_id; > + > + hdr.id = SCMI_BASE_PROTOCOL_ATTIBUTES; > + hdr.type = 0; > + hdr.protocol = SCMI_BASE_PROTOCOL; > + > + ret = do_smc_xfer(channel, &hdr, NULL, 0, &rx, sizeof(rx)); > + if ( ret ) > + goto error; > + > + n_agents = SCMI_FIELD_GET(SCMI_BASE_ATTR_NUM_AGENT, rx.attributes); > + printk(XENLOG_DEBUG "scmi: Got agent count %d\n", n_agents); > + ret = collect_agents(scmi_node); > + if ( ret ) > + goto error; > + > + ret = sci_register(&scmi_ops); > + if ( ret ) > + { > + printk(XENLOG_ERR "SCMI: mediator already registered (ret = %d)\n", > + ret); > + return ret; > + } > + > + scmi_data.initialized = true; > + goto out; > + > +error: > + unmap_channel_memory(channel); > + free_channel_list(); > +out: > + return ret; > +} > + > +static const struct dt_device_match scmi_smc_match[] __initconst = { > + DT_MATCH_COMPATIBLE("arm,scmi-smc"), > + { /* sentinel */ }, > +}; > + > +DT_DEVICE_START(scmi_smc_ma, "SCMI SMC MEDIATOR", DEVICE_FIRMWARE) > + .dt_match = scmi_smc_match, > + .init = scmi_probe, > +DT_DEVICE_END > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * tab-width: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h > index 095b1a23e3..30e46de6d7 100644 > --- a/xen/include/public/arch-arm.h > +++ b/xen/include/public/arch-arm.h > @@ -329,6 +329,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); > > #define XEN_DOMCTL_CONFIG_ARM_SCI_NONE 0 > #define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC 1 > +#define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA 2 > > struct xen_arch_domainconfig { > /* IN/OUT */ > @@ -355,6 +356,8 @@ struct xen_arch_domainconfig { > uint32_t clock_frequency; > /* IN */ > uint8_t arm_sci_type; > + /* IN */ > + uint8_t arm_sci_agent_id; > }; > #endif /* __XEN__ || __XEN_TOOLS__ */ > > -- > 2.34.1 > From xen-devel-bounces@lists.xenproject.org Thu Jan 15 02:01:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 02:01:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204054.1518909 (Exim 4.92) (envelope-from ) id 1vgCfq-0002IC-Qi; Thu, 15 Jan 2026 02:01:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204054.1518909; Thu, 15 Jan 2026 02: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 1vgCfq-0002I5-Mu; Thu, 15 Jan 2026 02:01:22 +0000 Received: by outflank-mailman (input) for mailman id 1204054; Thu, 15 Jan 2026 02: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 1vgCfp-0002Hr-Az for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 02:01:21 +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 14705527-f1b6-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 03:01:19 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by LV3PR03MB7585.namprd03.prod.outlook.com (2603:10b6:408:28c::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.6; Thu, 15 Jan 2026 02:01:15 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.005; Thu, 15 Jan 2026 02:01: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: 14705527-f1b6-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UKJFU2ziGrVjaEkA8pRqoHZE4UMiwwprb0RDUqWoQSPqCghkEvKb6829VasSJuvWRXVdpj1Mqclr6ylyF/u4S6zuYo0e0OkiR76udhlHXeIvrGcNzkbGOk8cWbIfh5QUL5qVvAETT/sdM/R5jHcr7o2KA/0j5I8T184UnwLWFMNutmeQWgostnrjqaq0sD8BlpdyFctSbqzoajleGiftbPeF3xvTwIoR/GiZREPP54BTKgmqrVDQe3zxv2GG5qdBomDlyXgZ3lPs3BANedXelzegJTX5KvVzk7ZNaCp8DAJdd2InrDHi9kdlFkt7/WmhswQcsMNx+5AIGl5smbHqww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=AP3ozEoHItsDE7xlRQ632Iews+ktvhqzJRFlIiG1kfo=; b=pG6MlVLRaYa5kqLAYMT6xLdGkRUnDvU95ITR2znz2WsuR2emn/RQnWBgMQ/ZVRYwUZGh9QtEfk3aYqu8U9OEy+gujENnnTZ8HSNMPu2HDjoFBiDiUvhhvkio4Np8ABOJK1D325s9Jiq6A60mOWHd9ZI4V9rGn8khtmOR6UjbPnKt/fU5bL2WiIqO+MxXtd0CzaFjE5EqJHtJysu7onw4Dv/8YZXD6vcnNlImCMx5C795aPHseHuOIc9tggao9fgYlFec+HuQN1MOncX38ybcSJFfULnxmR2LBtKrnetg/x3b7bBWeTVxD8pfXoY7FLjawsLGESdKnix1fqXztjG/0Q== 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=AP3ozEoHItsDE7xlRQ632Iews+ktvhqzJRFlIiG1kfo=; b=LDEZqmq4GSBX8D4oyPz6lWir+IFykkxwK1iLSuyXPRkpmMNG0lCh07g3u59DXRgD4DUcQDfD7o1pppeB7nLENztqdtcO1kYnPRPHX/f6Nsnr125+x9TqGTQ99lgezWHjG9Z9USZdQuP2ZcvDiNBSnlJrKLto2bj/bckwyaRNm0w= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <95e0e0fb-2978-4c87-b723-fb7c30f36883@citrix.com> Date: Thu, 15 Jan 2026 02:01:12 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo Subject: Re: [XEN PATCH v1 1/1] x86/vlapic: match broadcasts for logical destination mode To: Victor Lira , xen-devel@lists.xenproject.org References: <20260114235548.626696-1-victorm.lira@amd.com> <20260114235548.626696-2-victorm.lira@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260114235548.626696-2-victorm.lira@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0614.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:314::15) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|LV3PR03MB7585:EE_ X-MS-Office365-Filtering-Correlation-Id: daf1c36f-afed-4779-81fe-08de53d9f75e 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?bVdycXd4L1o1aXplRVR6RUNFWGdENU0yc3R2aGJ2U2JJY2UzNkhGeUlZU295?= =?utf-8?B?d2hqNnV0LzBqN0dBeUZTKzZtbEN5d0NxZFlQM3RRdFA3QTZqaVJqQ3RSa01T?= =?utf-8?B?ZWhhQ2JmbUhGblNyM3N3NVhoWElQS2RYaVlDRHJ0ek4yZ2JmMWlIblp0T2Ji?= =?utf-8?B?dmZobmhJTnRGTFZTdVlvUVU1NkhNMW0rZ2g0b3o3a2xEaWJLRTh1SjdFWEl4?= =?utf-8?B?V0UvQXFnenRoejlHWlZ3Mk5sVXhoUFhxOVp6ejQwRE41RmpheUt0NFRZVE9Q?= =?utf-8?B?QXE0aDlLUWRLVzJTOXVRUFdZWlROS0oyaE5XdWpGRmx3RGhXZ2ZUOGF0RDh6?= =?utf-8?B?MWRERUtmd1lnaHJuTnRySlltRkxrVTB5NjdRZWo0eHpuUjgyVnMvcCtZMWVJ?= =?utf-8?B?b1hIZFJ3VnUreVJ2aTA0aksweE12ZS9WQWxvZU1qQTk1eHBPUlQzbHZHWVpG?= =?utf-8?B?cGdrOVh6NkRxVXMvdWNpdjRKZ3Jvbzd3OFdKY3ErVmtOTXYwY2c3TFVNb1d4?= =?utf-8?B?cEdFYjY1eEMvR0d4NlVWQ1Z0YkpoQXZRd1pvbytLZldtTWdmb1dGd1g0eGdN?= =?utf-8?B?K0l5bmJqTkRRMzk4b29HU0I4VmFtaGJJdjR2MU5YVEZWTzQyWUgxdXY5YjNk?= =?utf-8?B?azh3NmFOK0tiMGtaaXg4aVlodkVCdUJBOFliQ0trRmxKT3kwTnh6cTBuRDU4?= =?utf-8?B?ZkRKd0hhS0t0V28vcGN0dkI3T2kzODJqOG1LWUhhY3p6SmQwQktJZnlvWkJx?= =?utf-8?B?TlIyQmw0RGRHUWdtM3M1Yk14aE0wdXo3a0pGTkt4aFdDdVZoYmRxODBjV1Js?= =?utf-8?B?di83eExFeDVCVHovUG9obWhVK05hZlFVQzFJZzFHaDZIN25UZ3hWb3A4TkhW?= =?utf-8?B?cjhxWnM3SGk3am43RWRXcFgwY1F2UUpPV2lwM3VmS05CRFU5QnRDOC9qaVhR?= =?utf-8?B?YmRFZEVBRlBWZHVrNU5UNktEU3UvNlZ6ZHNVYkpvUnJDUGlOaDk5d0xTTEEx?= =?utf-8?B?YlJTV3h2eGJQV2hLOWk4L0xpSkV0TS9iTG9TV3A5cnprb0dSZkNlT2F0V1E4?= =?utf-8?B?Y0pwMFRpQXJwM0RxdEJHVStHNmgwVzlnZTZuTWFRT2dyazlMTVZCbFF5Mllr?= =?utf-8?B?Q2dVODR1UmhkQUxRVnk0V2dVSjBQdGp0Nk9nRVo3aXdmaWF5ZUovcFNMTi93?= =?utf-8?B?Zzg1VldJZk9oaERJTVVUcTRHZHY3ZktDUzVGWHVPZVdPZUtuOEFyTlpxVEtj?= =?utf-8?B?NzgrWldwUDVTZ1RDSzNKSUtGUXhxMmREMUJXUnlpdXM1QzgvcDJjUGxneVZI?= =?utf-8?B?UVlUU3lMQXFjZWZnV0huZndOQ3BCbm5GczBjc1FURUJBWi9TaFNYRDEwb0FI?= =?utf-8?B?N2YxUDJOY2VoR3JpNDhGV3NnUWFMTUpEa253RlpjbDdoNTdxOE9DYjJUaWV0?= =?utf-8?B?NEVPVnAwdE42NHcra1VkTFpvWmdzUzZtTVd5L005bCtFZWhlV2xHaTVyak01?= =?utf-8?B?MDdWZ1NOREREOGloR09mVmNHcTRjMUVOa0xlM25oMFZ2dnUyZkNQR1FzK2wx?= =?utf-8?B?SzNVMnBrQXd1cFE2ZWZ6bXN3emJzbS9VcU5kcEd6UzhxWHpMMHZ2QjIrWk9n?= =?utf-8?B?TXVlNnBqeHFreWRYR3V5bTI2R3NzL1BONmhIbzdoMjdhSVhIcmJwY0UvcHpz?= =?utf-8?B?R29aWFVHejUzcURQbkR2US8rR1BKV05NbTFXSFV1Ti9OVXlqWW5MRnBidGlH?= =?utf-8?B?MVNFeHozY2xUQnpxM3VFb3FXbHl2UStIUytjaW4wMVlCVXhkY0t2dEE1RmtV?= =?utf-8?B?MzRiQWlCTytnUVFDWjRkTTNUVTZhNnljOTR3VmRZUHZhajBvaktoZkVGVXJl?= =?utf-8?B?UlpzVm1HNit6T2ZnKzhEUGpXV215NWpVb3g5OEJiazZiYzV6NkZkaVhhSHow?= =?utf-8?B?VGpSckkranZMOWhwek02MDFGVnJaVmVSVWR3c3VHd0tNTmxNVTV0dUtURERN?= =?utf-8?B?V0VuMWZEOGFXcGZDaUM5UGQwY0IyVmlBQkszaFFORkNqazhUNS9sSTFhcER3?= =?utf-8?B?MXpQVUJWSDhDSmNUbmRqNTI2bm5VV0hvYlJYcTNIcEwzSkp6YVRyRUdqTjdK?= =?utf-8?Q?yJQQ=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VTFvVXVUVktrMTM0QXRHbGNzYjgyOGRUVXdwaUdQQUtGQTNaMVpmc1paK3dn?= =?utf-8?B?YkZqclhMQzRITTFQNmtQWDFjZllIb0pPSmVWamE2Y2ZpelZFR1MwM01RWEJj?= =?utf-8?B?RnhvZDFtckxxSWJKYVBwSGZsUkt2N2YrMHhZeU9Hb0p3MHNvTFpJWmpLemVl?= =?utf-8?B?b2hsb28xZmtrbWhBck1WVWRIbzhVc01ucTlndzFKMXZtTTRqdCtxMW9sa3Va?= =?utf-8?B?ZmVnUlk2ck5OOVFQK1llRURxRnErMm8rUVhHTkhjdy9MTUVKZ1gvNHcyaHFq?= =?utf-8?B?eDhhK3BRT1IrcDRndDJmL0RCMEg3WlJGZlhPWjRUQVRBRzYzTFZCQWhWK21O?= =?utf-8?B?aGR2R3hvT0VCS3UwempBN0NPeUUvTEp2R3FieSt3SzdNZCtqZE5TVnhVRW1M?= =?utf-8?B?U3NIZlB0d1NrMndmRElXaSt2QTFCZk1DV3ZCc296bTdtM0R2S21lUVdoUkp2?= =?utf-8?B?YkgxbXZxRUhjejRBWVovb29vUTlFd3dlNSt4THhoYVlDS1FlSGp5S1NhVE10?= =?utf-8?B?VDNUZ1cvZ3NGUDZ4WGhwLzRWZXYzK0ZQeXR0YXVmTDhLREgyZ2dPbmdIM1lv?= =?utf-8?B?M1lYSGpNZjRUNFAzUkMrdEoxb3hyQ2V1dDNWN0lwbDVVR1ozcUZFRUpyNU84?= =?utf-8?B?Smd0dzB6Ylg3aWRxaDdrTmJ1L2JUS1N0YjUwVk84MWZtMEF6MmdpKy9FRGFp?= =?utf-8?B?YnA2VENTS0FBQ0JaWHlyWGtNS1gzY3NNVS9IV0p3OThnRkRvbzdnZ090VVVQ?= =?utf-8?B?MThOUFM2bllGSlNqek9CR1hiSGtVaUgwV1Blby9ya2lWQnNweXZCanRXYUtT?= =?utf-8?B?dmRmay8rUWZUdGdFU2RXaExqeDBTRjRqbUNYSTRXZ3luRTRCTUJmaVV1N1hN?= =?utf-8?B?R3k3LzgrWFM1UktzNmNHQzVKYWdqM3hxZDBmK05Tb1pPUTZmT1FtNUJhUG1F?= =?utf-8?B?TnJYNmQwMDhrZXFLNGNRdHhsQlRQSmRVL2pDWUdRSnRZU0gyYytwQWF1T3lG?= =?utf-8?B?WVMzV3doVmJIS3VyU28vc09yNjlQbEMwQTVYaUhuaDNJSFFJMmx0YU9QcEpa?= =?utf-8?B?d3dpK2VZSkdJT2kxdE1TNHltajQ2dnFBL21VajFkcWhRTzZGTVVtV0xVVHFu?= =?utf-8?B?cGQ5d1hEN1c5d0V3c21kZzV3L1RpSTIwVTk2S08zNklpMkRISlJHWm5MQ095?= =?utf-8?B?UFFqUngwYjdLNVM1bnZia29RK2o2am1hZUtlTFIydXVxSHNwU3hZU0pyYmcv?= =?utf-8?B?UFlwQnJFSk04TkxnVDdWOGhMZlE1TElJNGdSQ09McHB0M0IyMWd1MEQrNkhF?= =?utf-8?B?QmV3RHpjSWRuUW42V1UybEhYRUU4UUpnVmUxazBPNkJiMS9ZeXVZemg0R1Zn?= =?utf-8?B?MXVybDB2UzZxYWNtemc3b3I1dTB5Rnd5cjFZRFBUYktPUDJFejFEeGVvZmtY?= =?utf-8?B?N2dxUlFyK3pla0diNmxjenBzS0hKdXJiWDJJc0lxZEIrQTVUbVoyVU1wbUpw?= =?utf-8?B?MWFzd0QzRzcwa0I1NkhadklrUEtkVUo5RlFselVEK3RIenprNHZqaTk0OWdx?= =?utf-8?B?WXpOTTVPVEh3MTYrSTVyRWpqd3RnMDdSU2pmTi8xWWxjYjE3WFR6aElsK2wv?= =?utf-8?B?V2VZcE1WYUw3Y1V4QVBROUUzZzBPMkNaUTNzOHBMa3FnbG9UZEFLYjAzeEFu?= =?utf-8?B?eVM4SjhJa1BWZEpOWnRHdlhqRG96R3VqYVJ4bUlWNUtsM2d6N0NLWUZkRi9k?= =?utf-8?B?WTVzQmhFUGVlU2dleS9OUGVRVURONGR5THc3UitFT3EvS005dTk5NXY5RVVj?= =?utf-8?B?MDZ0cXBBLzFINE9WVUE4cDcvejZqUDljd2orS2s2ajRwRGxWK0dQelpmWHZZ?= =?utf-8?B?WnFneWZBRWhDWW5FQzB5RWxqang1eWN6YWNFRGwyMFFFNU9pTWNqME02NmlJ?= =?utf-8?B?OXFHUGNnQ1dIV0I1ZVROV1gyL0NnRUtTMjRtSFJoQlZWK1EyRVZKcEVZQmZF?= =?utf-8?B?LzZ4WUZWQnJiTElodnA3ZlNJREVaOHJWZVpvV0tuK0s1TDcvTXhsS1VBV1dD?= =?utf-8?B?TnY0RU56ZHdNTjQwL0V3S0FLTlhTSWN6d2dqRW9NVmxhbTdnU2V2eVVjd0lR?= =?utf-8?B?TU92cmRUdDRhSWp4UThnWG1RNW5kMGpycVBHWjhKb1o0UndHUVU4bGdBT2xU?= =?utf-8?B?bWhsS09DUUhYSW9FQ3RqaDlKWVI2RFBuTkxmbEZGSWRQaFhrSlZ3di8zSWxP?= =?utf-8?B?SnBsV2h6OXpLdnpmWlZ5d2NlOEtCRk5YaEU0RTk3K1RDb0pNZ3hrT09sdTY3?= =?utf-8?B?WmpWSFdxSW5QR0czaXd4YWRGYW1NZjdXellzL0w3QnFsb3lxeVBIQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: daf1c36f-afed-4779-81fe-08de53d9f75e X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 02:01:15.7264 (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: G7bVYO1C112iiQAQHBuNdziblycoSraKYwyOLF+RiEie8QvFq4QobWkJZcpI7pK9uF20sPabP3ocTvofUUuxmUXxpw24QULOANiF0Q5mOu8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7585 On 14/01/2026 11:55 pm, Victor Lira wrote: > amd64 vol 3 > 16.6.1: "In both the flat model and the cluster model, if the > destination field = FFh, the interrupt is accepted by all local APICs." > 16.14: "A DEST value of FFFF_FFFFh in the ICR is used to broadcast > IPIs to all local APICs." > > intel 64 vol 3 > 12.6.2.2: "Broadcast to all local APICs is achieved by setting all > destination bits to one." > 12.12.9: "A destination ID value of FFFF_FFFFH is used > for broadcast of interrupts in both logical destination and physical > destination modes." The formatting here really needs some work. > > The specs say 0xFFFFFFFF/0xFF should be a broadcast to all APICs in > logical destination mode but it is matched only for cluster 0xFFFF/0xFF > (or as flat mode in xAPIC). > > Add a check in vlapic_match_dest similar to what is done for physical > destination mode. > > Signed-off-by: Victor Lira > --- > xen/arch/x86/hvm/vlapic.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c > index 79697487ba..1208cd21f0 100644 > --- a/xen/arch/x86/hvm/vlapic.c > +++ b/xen/arch/x86/hvm/vlapic.c > @@ -248,7 +248,8 @@ bool vlapic_match_dest( > { > case APIC_DEST_NOSHORT: > if ( dest_mode ) > - return vlapic_match_logical_addr(target, dest); > + return (dest == _VLAPIC_ID(target, 0xffffffffU)) || > + vlapic_match_logical_addr(target, dest); > return (dest == _VLAPIC_ID(target, 0xffffffffU)) || > (dest == VLAPIC_ID(target)); The SDM/APM quotes are clear, but I think this logic has more bugs than just this. First, you've got a common expression that the compiler cannot optimise because of the function calls hidden in VLAPIC_ID().  The appropriate rearrangement would be:     case APIC_DEST_NOSHORT:         return (dest == _VLAPIC_ID(target, 0xffffffffU) ||                 dest_mode ? vlapic_match_logical_addr(target, dest)                           : dest == VLAPIC_ID(target)); However, the first clause looking for the broadcast ID is surely wrong. Surely it needs checking against the source LAPIC, not the target.  Whether 0xff or 0xffffffff is the broadcast address depends on the xAPIC vs x2APIC mode of the sending LAPIC only, and it's surely buggy to fail to match targets just because they're in the opposite mode.  So, I think the correct code is:     case APIC_DEST_NOSHORT:         return (dest == _VLAPIC_ID(source, 0xffffffffU) ||                 dest_mode ? vlapic_match_logical_addr(target, dest)                           : dest == VLAPIC_ID(target)); Thoughts? Given this bug, I expect the OSes which use fully broadcast interrupts tend to do using shorthands, not the broadcast destination. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Jan 15 06:24:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 06:24:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1203823.1518919 (Exim 4.92) (envelope-from ) id 1vgGm3-00083j-AR; Thu, 15 Jan 2026 06:24:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1203823.1518919; Thu, 15 Jan 2026 06: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 1vgGm3-00083c-7U; Thu, 15 Jan 2026 06:24:03 +0000 Received: by outflank-mailman (input) for mailman id 1203823; Wed, 14 Jan 2026 20:31:22 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vg7WU-0000yJ-C2 for xen-devel@lists.xenproject.org; Wed, 14 Jan 2026 20:31:22 +0000 Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [2607:f8b0:4864:20::72d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id fa8fbc09-f187-11f0-9ccf-f158ae23cfc8; Wed, 14 Jan 2026 21:31:18 +0100 (CET) Received: by mail-qk1-x72d.google.com with SMTP id af79cd13be357-8c530866cf0so19845985a.1 for ; Wed, 14 Jan 2026 12:31:18 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fa8fbc09-f187-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oasis-open-org.20230601.gappssmtp.com; s=20230601; t=1768422677; x=1769027477; darn=lists.xenproject.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=2fYIETUaxvUJwN836Uu55NyXtFf/1P28/mpSnbMK4bA=; b=iMaUW4Oi7JbHLzbQtRYFJT5lPeAzfernodteg7jeetrFd4UQ8b8baRoklKtvurqQ0I Dr1+Z6X/eQsy1gVZqi6OfV/kDqCi4D/MnMWH9BVegSd6U13BAt+VyZ0Vj1UdqwusHFXB pbyK9HGMu6mol6UwHEbyiaApI79SyIaEtZtuzewdqSxjus+VuplNljOYEe28IWO5KWvn yGU/UwVUb6nE1wGtutQfxhaSR8J/xadRN9qR2UByQnTLq9SRQbjGGYvupN0tOiI80RIP EIFXi5Sdu+Tm1L6U9TI/PZzC3eaZLU6eFNVQoxkmkQOL0Tb6qPgTuwdFlPZ5hrcq/kio mWLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768422677; x=1769027477; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2fYIETUaxvUJwN836Uu55NyXtFf/1P28/mpSnbMK4bA=; b=RwBTQ9P7PryT9hBJ4pRg0RyD0oOHL3ex4DRxloi9E/mXtDMS82tWBpc3+HOsFKhpw+ xvHKS0ZExuyi5gyDCUmwVaMOaObCGv1ikhXgjowARfWHxMIzwGESqBTOPrF9iMxYef2s yhOHQW/QsFkjqaOk4JDwHBC9SCSobHZktjh8A23fRFRP2TTdhQrtTQj+SsNotVvbuvhg XM0cJYYNEfBtvs+orx9ob9wynJP1lw6pxV5k2aaH6JzzLHdI/dUVxA4hrcdmhcrirZoC /r76+M1qZtt2xGsUOCG+p+kmkbDMyD5mXSf7IDsA6uD73C9pnW1n5fRt+1dvRJu18Vwz /uag== X-Forwarded-Encrypted: i=1; AJvYcCUAIsJn6037FGu5zqPsUSTWP0x8yQ2GLoeBMwsEY3xhqE4OyPvousNfZ+kdn9FNP2ypi7BgfFB5Dgs=@lists.xenproject.org X-Gm-Message-State: AOJu0Yye3Xc60ucJnyBM87jvg+Vp0tCaSnHOzRN5vIN4luaSvglAA9OL p2iMkCQ4usx8ChjedWadnfsqiiqfOEtKGQ08mCddWx5cuFhOTMF7YEL2UF3COzGLMwi54m4N9dP KEKO9pihqawBJs/xRz9hinl3JPUNDHv3NLKHdtrB7YuOkrMFSGCEl X-Gm-Gg: AY/fxX5Y6W9CfOa0mLeurVpiFBJgT5+cVokcWAx03Yj5jmhQ/BtY8HpPpINYEvHff+b 8GsrQ43Jh6D8z6XCuEBEn4uWMCTP4VwnbLD4RHBB65OCNpVbFyq2VypsSjlFq/dCX5iajq3tmDi vvHSc00vyw6nCvujkXEO2s/bwJPjFrXtBom7jbTNQq+wL4zldYWi90PsYThyNi+kF3/kvr5mXvA 9DcKVeHzBxaz9jOmDqA2wvBAw1kPdC9j7znhlxscOheBVNg3W2ZO5BfF4r6oH/Zum10ba+HGVOa 5bBPUBrpLf1xfhTmqqC0HGGHBzOAY4lmCRuo8fWaNqfNIad57bPSzoh1B+TZRRRyfOkZr9U= X-Received: by 2002:a05:620a:29ce:b0:8bb:9f02:489e with SMTP id af79cd13be357-8c52fbcf15dmr558224785a.74.1768422676863; Wed, 14 Jan 2026 12:31:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Kelly Cullinane Date: Wed, 14 Jan 2026 15:30:39 -0500 X-Gm-Features: AZwV_QiCqCxANNz1udCuWC7xOZO9m8PtoTX-mt0_iIp4ME__ZtZZBHdr7BoO8PI Message-ID: Subject: Fwd: Invitation to comment on VIRTIO v1.4 CSD01 To: undisclosed-recipients:; Content-Type: multipart/alternative; boundary="00000000000077ac2606485efdac" Bcc: xen-devel@lists.xenproject.org --00000000000077ac2606485efdac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ---------- Forwarded message --------- From: Kelly Cullinane Date: Wed, Jan 14, 2026 at 3:28=E2=80=AFPM Subject: Invitation to comment on VIRTIO v1.4 CSD01 To: , , < virtio-comment@lists.linux.dev> OASIS members and other interested parties, OASIS and the VIRTIO TC are pleased to announce that VIRTIO v1.4 CSD01 is now available for public review and comment. VIRTIO TC aims to enhance the performance of virtual devices by standardizing key features of the VIRTIO (Virtual I/O) Device Specification= . Virtual I/O Device (VIRTIO) Version 1.4 Committee Specification Draft 01 / Public Review Draft 01 09 December 2025 TEX: https://docs.oasis-open.org/virtio/virtio/v1.4/csprd01/virtio-v1.4-csprd01.= html (Authoritative) HTML: https://docs.oasis-open.org/virtio/virtio/v1.4/csprd01/virtio-v1.4-csprd01.= html PDF: https://docs.oasis-open.org/virtio/virtio/v1.4/csprd01/virtio-v1.4-csprd01.= pdf The ZIP containing the complete files of this release is found in the directory: https://docs.oasis-open.org/virtio/virtio/v1.4/csprd01/virtio-v1.4-csprd01.= zip How to Provide Feedback OASIS and the VIRTIO TC value your feedback. We solicit input from developers, users and others, whether OASIS members or not, for the sake of improving the interoperability and quality of its technical work. The public review is now open and ends Friday, February 13 2026 at 23:59 UTC. Comments may be submitted to the project=E2=80=99s comment mailing list at virtio-comment@lists.linux.dev. You can subscribe to the list by sending an email to virtio-comment+subscribe@lists.linux.dev. All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. In connection with this public review, we call your attention to the OASIS IPR Policy applicable especially to the work of this technical committee. All members of the TC should be familiar with this document, which may create obligations regarding the disclosure and availability of a member's patent, copyright, trademark and license rights that read on an approved OASIS specification. OASIS invites any persons who know of any such claims to disclose these if they may be essential to the implementation of the above specification, so that notice of them may be posted to the notice page for this TC's work. Additional information about the specification and the VIRTIO TC can be found at the TC=E2=80=99s public home page located here. --00000000000077ac2606485efdac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


<= div dir=3D"ltr" class=3D"gmail_attr">---------- Forwarded message ---------=
From: Kelly Cullinane <kelly.cullinane@oasis-open.org>
Date: Wed, Jan 14, 2= 026 at 3:28=E2=80=AFPM
Subject: Invitation to comment on VIRTIO v1.4 CSD= 01
To: <virtio-dev@lis= ts.linux.dev>, <OASIS-virtio@connectedcommunity.org>, <virtio-comment@lists.linux.dev>
<= /div>

OASIS members and other = interested parties,=C2=A0


OASIS and the VIRTIO TC are pleased to announce that VI= RTIO v1.4 CSD01 is now available for public review and comment.=C2=A0


VIRTIO TC aims to = enhance the performance of virtual devices by standardizing key feature= s of the VIRTIO (Virtual I/O) Device Specification.


Virtual I/O Device (VIRTIO) Version= 1.4

Committee Specification Draft 01 / Public Review Dr= aft 01

09 December 2025


TEX: https://docs.oasis-open.org/virtio/virtio/v1.4/= csprd01/virtio-v1.4-csprd01.html (Authoritative)

HTM= L: https://docs.oasis-open.org/virtio/virtio/v1.4/csprd01/virtio-v1= .4-csprd01.html

PDF: https://docs.oasis-open.org/virt= io/virtio/v1.4/csprd01/virtio-v1.4-csprd01.pdf


The ZIP contai= ning the complete files of this release is found in the directory:

https://docs.oasis-open.org/virtio/virtio/v1.4/csprd01/virtio-v1.4-csprd0= 1.zip


How to Pro= vide Feedback


OASIS= and the VIRTIO TC value your feedback. We solicit input from developers, u= sers and=C2=A0

others, whether OASIS members or not, for the sak= e of improving the interoperability and quality of its technical work.


The public review is now= open and ends Friday, February 13 2026 at 23:59 UT= C.


Comments may be s= ubmitted to the project=E2=80=99s comment mailing list at virtio-comment@lists.linux.dev.= You can subscribe to the list by sending an email to

<= a href=3D"mailto:virtio-comment%2Bsubscribe@lists.linux.dev" target=3D"_bla= nk">virtio-comment+subscribe@lists.linux.dev.


All commen= ts submitted to OASIS are subject to the OASIS Feedback License, which ensu= res that the feedback you provide carries the same obligations at least as = the obligations of the TC members. In connection with this public review, w= e call your attention to the <= span style=3D"font-size:11pt;font-family:Arial,sans-serif;color:rgb(17,85,2= 04);background-color:transparent;font-weight:400;font-style:normal;font-var= iant:normal;text-decoration:underline;vertical-align:baseline;white-space:p= re-wrap">OASIS IPR Policy applicable especially to the work of = this technical committee. All members of the TC should be familiar with thi= s document, which may create obligations regarding the disclosure and avail= ability of a member's patent, copyright, trademark and license rights t= hat read on an approved OASIS specification.=C2=A0


OASIS inv= ites any persons who know of any such claims to disclose these if they may = be essential to the implementation of the above specification, so that noti= ce of them may be posted to the notice page for this TC's work.<= /p>


Additional information about the specification and the VIRTIO TC ca= n be found at the TC=E2=80=99s pub= lic home page located here.



--00000000000077ac2606485efdac-- From xen-devel-bounces@lists.xenproject.org Thu Jan 15 07:39:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 07:39:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204188.1518928 (Exim 4.92) (envelope-from ) id 1vgHwV-0008Hk-GE; Thu, 15 Jan 2026 07:38:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204188.1518928; Thu, 15 Jan 2026 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 1vgHwV-0008Hd-Dh; Thu, 15 Jan 2026 07:38:55 +0000 Received: by outflank-mailman (input) for mailman id 1204188; Thu, 15 Jan 2026 07:38: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 1vgHwU-0008HX-FU for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 07:38:54 +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 3a4c567d-f1e5-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 08:38:48 +0100 (CET) Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-42fbc544b09so447860f8f.1 for ; Wed, 14 Jan 2026 23:38:47 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af6fc8fbsm4006807f8f.39.2026.01.14.23.38.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 23:38:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3a4c567d-f1e5-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768462727; x=1769067527; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=hw9nExakTAdhSF2n0j1ihoVsEt+bIL6JKWS08PbtWYw=; b=cmdrJcZlUCQyGBFFND06/aTjlXZOC7SOG0G+VBzbbi2GKncreJWeQtK6Sr/fLLhTzk ozZTW34oQaHblDmdfg7g8JbUt4MT1mIxfs3b0kQSsYrH+tW5811EEtNfzySmjLhiRXax IPhJg37SSby2GSDt93LYw9gCGs59/YthTbwJnfJWfr912XKF3MII8Mr8ReeRgIX/q9zs g5j5sZvCbJlU+s8nS7Ru6DcFBUPjvhqOrjc4FUx0hifROLn+54MengVQQdjqC8gUg/JR sIpxfbTv2kOymtVjY5T79UpBKd6T8/cow3M0iEN+Oq4huFv7yfEgODWuLkRUrsb2atrO 68dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768462727; x=1769067527; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hw9nExakTAdhSF2n0j1ihoVsEt+bIL6JKWS08PbtWYw=; b=onyFq6F2RqiIil9OoCCTLGXppwdyxdhoxbhM6N6g3smeeVbHM9SHH9uWE0BEIH6Dqq 6KPDWWgEu6Nu51xaStme3uRmQa3twOW/+fuMCh7f/cIbqzCmnpq29GQk3KoW4X/Sl92G HL+G+Tp3FUzPT+w8Kd0YEITNn//xTGH47P8SUZ37LCVTJntT/9zkmeXLdF6GlnsGUBIu XO9B/r9vI556rhWt6vAi2mJqq+97kxetAn8y+qs3R80OJWYPXzaYuRrg3Ss/KFf7+mUB lhvi94L5sfQAQNszCm9iQq4F9f7PjgYz5W+CNS6X8lLteEjsQd9m2slgr+18DQIPBW0+ MslQ== X-Forwarded-Encrypted: i=1; AJvYcCXMRN/nKacaTwf5Sr6+rJH677QLW80AW0pY+Fsyxpb4+3iXf8fq8CRl41Q5+HaDkYzVP6HDiHAkg+o=@lists.xenproject.org X-Gm-Message-State: AOJu0YyKyr7KzpkT1dh1XRf3zNx+VMbLOwoleElhSI/3DC7el8rbRhtu h9UnAi89htONnCyz6ntxw/v0z6iKViBqWYv/lbgNI8P+zyKnvyrmdL/+643tXHNOpA== X-Gm-Gg: AY/fxX6BTf0AIFUe3mJ62a6Z4VlNLVEYyHbbfQrrnD13oTXGQlpsEf5yuMDBfVR+xbG Riw2tfxFlZmT1ujkGZeZoWNOg0srmwRP0ZTEUaFN0Qj21Rixz0O68UXuMqMlEbejRheaxjBYrY0 HTP26mZ7JukmTF+6nhtGusoYVo0p6+gq0w/g5WiHJwLtEDCn++qv/fCDHhHzXr442qHTbGMH94a 1M4aEfUudf+rz2RHhSX0GCNeZDuCNdDSmBqdwg/4MH+9Da4fUsGIkntfSHWv/sepjLAjGhjEihi Y3mcYGUcN2op9gWQbAGV2+n9G8vwH+1Mlc7up0867zWRwZmB9Y5A9el8ZfA2mcj/AVKx2UwwDWN +4ddQeGDEAoglLW2mTzaoBKqV+9/2qATR8Nx8sTOtSvA9NTNHK7f0UhVXJrEPrJg0gizVhIB119 GgeJw2ptIAlH0FGYTZL1aW/RuK1EiQuDTrFeMHydSONvBwCyeu/SCzujAicQP2+A7Ib79VuvIzC mg= X-Received: by 2002:a05:6000:2010:b0:431:344:5a2d with SMTP id ffacd0b85a97d-4342c543b74mr5852965f8f.41.1768462727052; Wed, 14 Jan 2026 23:38:47 -0800 (PST) Message-ID: Date: Thu, 15 Jan 2026 08:38:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/6] x86/cpu-policy: define bits of leaf 6 To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <4d3a3576-2d3c-42ec-8551-18f1f0982e17@suse.com> <28910a0e-c6f3-41dd-9a0b-8289218562a0@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: <28910a0e-c6f3-41dd-9a0b-8289218562a0@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 14.01.2026 17:55, Teddy Astie wrote: > Le 14/01/2026 à 14:45, Jan Beulich a écrit : >> ... as far as we presently use them in the codebase. >> >> Signed-off-by: Jan Beulich >> --- >> Or should we make both parts proper featureset elements? At least >> APERFMPERF could likely be made visible to guests (in principle). >> --- >> v3: Use SDM-conforming names. (Sorry Jason, had to drop you R-b once >> again.) >> v2: Use bool and unions. >> >> --- a/xen/include/xen/lib/x86/cpu-policy.h >> +++ b/xen/include/xen/lib/x86/cpu-policy.h >> @@ -121,7 +121,46 @@ struct cpu_policy >> uint64_t :64, :64; /* Leaf 0x3 - PSN. */ >> uint64_t :64, :64; /* Leaf 0x4 - Structured Cache. */ >> uint64_t :64, :64; /* Leaf 0x5 - MONITOR. */ >> - uint64_t :64, :64; /* Leaf 0x6 - Therm/Perf. */ >> + >> + /* Leaf 0x6 - Therm/Perf. */ >> + union { >> + uint32_t _6a; >> + struct { >> + bool :1, >> + turbo_boost:1, >> + arat:1, >> + :1, >> + :1, >> + :1, >> + :1, >> + hwp:1, >> + hwp_interrupt:1, >> + hwp_activity_window:1, >> + hwp_epp:1, >> + hwp_request_pkg:1, >> + :1, >> + hdc:1, >> + :1, >> + :1, >> + hwp_peci_override:1, >> + :1, >> + :1, >> + hw_feedback:1; >> + }; >> + }; >> + union { >> + uint32_t _6b; >> + }; >> + union { >> + uint32_t _6c; >> + struct { >> + bool hw_feedback_cap:1; >> + }; >> + }; >> + union { >> + uint32_t _6d; >> + }; >> + > > While I'm ok for the a and c unions, I'm not convinced by the b and d > ones (union with just a single uint32_t in it) as it's quite verbose and > inconsistent with the rest of the cpu_policy structure. Indeed for them I wasn't quite certain. I could drop the union wrapping for now (until individual fields appear), yet then I'd again be on the edge: Use uint32_t _6b; or uint32_t :32; ? Both have their pros and cons. Hence why I went with consistent layout for all 4 fields. If there was a clear majority preference for either of the above, I'd be fine to switch. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 07:51:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 07:51:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204204.1518939 (Exim 4.92) (envelope-from ) id 1vgI8m-0002Uw-M3; Thu, 15 Jan 2026 07:51:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204204.1518939; Thu, 15 Jan 2026 07:51:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgI8m-0002Up-Ip; Thu, 15 Jan 2026 07:51:36 +0000 Received: by outflank-mailman (input) for mailman id 1204204; Thu, 15 Jan 2026 07:51: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 1vgI8k-0002Uj-SU for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 07:51:34 +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 01ea0311-f1e7-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 08:51:32 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-47edffe5540so6006195e9.0 for ; Wed, 14 Jan 2026 23:51:32 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af64a778sm4159493f8f.3.2026.01.14.23.51.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 23:51:31 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 01ea0311-f1e7-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768463491; x=1769068291; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=FYN3QVD9ORfEN4a1Uwdps8CyfvMKZ8/di2f6UPpXfL4=; b=YgZ3fl9XGWxU3RAeifYKo7KMZfy7e/7H5C1DTtqyF7E8RlLO7zj3CRYpkcaQcQiKSb sex1jfMm9b92ROWD/i5hEh2RNzVwGFEoi7RpTUtlsb9IS72gJXYAFmrGffjUUn39G6nQ CjwHwI91ydyXjzHVeBtBMVlGfVBKH3Op7YCd9kmKc5BvD6QNOw7OpVGp9io8ou71gDe5 +AG5QerPtSrFDaQiUSmL3TnAFX8AOdwgw+QQCddwyRRSNh3F1Ma6hzElYUTJXyIcMcIU sk1hFlEDkH9fYND4j2nzjlHyOANlqQKgaykIoIX1L0XpriPFI6G3Xiea+yEmj9spSojD XBOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768463491; x=1769068291; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=FYN3QVD9ORfEN4a1Uwdps8CyfvMKZ8/di2f6UPpXfL4=; b=BvijmB4FQZxz2vXo2U4X9fFJER/7RgiWmzkoZnUOwXNimYVA9jyuNB0IlMvkgjJFvo UYn2KMO8s8JOwS6cSemUVI9xpGY8PvpL64614iGqn4PC/QlNCZwJm2yPdM4G55kHxS/o ezF8eKyrlKNE7dXwo2bav4ZWZ8h29krq0f8N+sEbGnZU779AIQBOELupH+Yqxa5KXPdy SZ9xvW9eHrlmrfhNDn93Jokx66RGIs0zr/MdAAbRVU9xyqLZzOgeEowz9i7hee+FQkeZ xCoW/bUKlU0Gec5yRihsykHPWM7Qd8ILbqEvbf9/24duzdCpjjMaLHMYgCo9Ea/0LBbH l45g== X-Gm-Message-State: AOJu0YzoLAJnPTTBUI7OvrYudctxrjXJG6+/cC0VRw+5N6fVencScYUk rwshWLNlIvHdCsZ17bFzjLt/UDDkCZnZqWIMtbwqOaY6goSyX9m5YyxeEKmnvyIeqw== X-Gm-Gg: AY/fxX7n5ID5tbh4iK2o0B2mFFGQEAXR+X32FmCSOlWfzLQbU/LsbakkeE0gKpxnEGl Xs3RbMLzGgIWQpBh5LliXKnC2jCRgLYww28ouoO2ZAi2lPnDqL/XxV2cfG7LsH6tID0LelbxDDR 8EopToUW8SBuEvMpHZbfkTqITMpdNQ8xUc+buasZ+/3ynllXwTnSnvLQDwyrGgIaJm02etFzzSj TRdSYWnGKGXRR1rLAmsx3VhHYQ5wk/qrLDYqFfMQ/4V8t3T+sW4P/YDF1A0To2GO3vN3fyyBvJA 6aC4qkqFP5JhwRzzkD9oDIJ6+b70y3k0UEI5V/l8tLIff2EILTRFaGubtdcV9kPM5fcgeCfGGlO Idj/Uyy2p8G4Zqoc1Ae4Od2bK61M3vHJnmbq29qAYV4UW6SO1UiLjJMgP/v4m7PuLHTFcd6a4Dc fSNHaYRhI+TNtcmubgMyDhH9HeDjLfOCMHW+2Nq3KZMrZi0fHWAfL/wtSc9Tej5GA73n9EcfAtQ +Y= X-Received: by 2002:a05:600c:818c:b0:47e:e2ec:9960 with SMTP id 5b1f17b1804b1-47ee339ba32mr55279325e9.35.1768463491575; Wed, 14 Jan 2026 23:51:31 -0800 (PST) Message-ID: <98b1ba19-40d3-4f36-9723-2773580df3e3@suse.com> Date: Thu, 15 Jan 2026 08:51:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Cpufreq drivers not working on T480S To: Milky Cc: "xen-devel@lists.xenproject.org" , Jason Andryuk References: <7dbd26d1-0d9a-454f-90d8-5a7f3d8e12da@suse.com> <8a2125c7-c5ec-4be1-a7a5-61b2936cc90f@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 15.01.2026 00:42, Milky wrote: > On Wednesday, January 14th, 2026 at 11:12 AM, Jan Beulich wrote: >> On 14.01.2026 11:58, Milky wrote: >> >>> Just wanted to update this thread to say that now another T480 user (the T480 is a very similar model to my T480S) using the release builds of libreboot (as of 26.01 RC1) also has the entries missing from the ACPI tables. That discussion was here https://codeberg.org/libreboot/lbmk/issues/394. So this confirms that I'm running a standard libreboot, rather than a bad build. >>> >>> Do you think there is any way to avoid the underclocking issue with Xen on such devices/firmware? >> >> >> In principle there is, but in the absence of ACPI data that means holding model- >> specific data in Xen. Which iirc is what the intel-pstate driver in Linux does >> (using ACPI info nowadays only as "auxiliary" data). But I may be wrong there, >> as it has been a long time since I last looked at that driver. > > In that case, would you say this is settled now? Would it make sense to report back to the QubesOS community that librebooted T480/S will run underclocked, due to the missing data in ACPI tables and lack of native support in Xen? This information is important, as the device is only barely usable. What to suggest to the Qubes community needs to be discussed there, I think. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 07:52:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 07:52:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204212.1518948 (Exim 4.92) (envelope-from ) id 1vgI9M-0002vH-Sm; Thu, 15 Jan 2026 07:52:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204212.1518948; Thu, 15 Jan 2026 07:52:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgI9M-0002vA-QJ; Thu, 15 Jan 2026 07:52:12 +0000 Received: by outflank-mailman (input) for mailman id 1204212; Thu, 15 Jan 2026 07:52: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 1vgI9L-0002l1-Ad for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 07:52:11 +0000 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [2a00:1450:4864:20::42e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 18a8f5c3-f1e7-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 08:52:10 +0100 (CET) Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-432d2c7dd52so463058f8f.2 for ; Wed, 14 Jan 2026 23:52:10 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af6b29cfsm4233532f8f.27.2026.01.14.23.52.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jan 2026 23:52:09 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 18a8f5c3-f1e7-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768463530; x=1769068330; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=G04VNH9mM5QJYcfrwDmtk2vbND5eL1Ze1p1mnEyfR7g=; b=DVH0HbHJ/uwSgWAxwbxD81cIkyzLMbUvysMiQVdHJ5BC0Dp+5xifZ2kun/kJ9D/krJ C2Dsqcb/JAy4F5cssteN5HzTNNqlVsaosdaB/AmVXv0wVBTP2+fhN4ioXYK+Yp7Y+qO6 dEmhWfBEDWTs5rsg3ga+yGC1/2B5Kz1sYZQeDe9vMShGfQXYFCLo5QFFozRHa7yA+TrF 2zT5ha8XB0fWM/EfM3Af7QjVKiBkZTn9Pq48wS2hYrT4hBNqzJijtvabE01n91mYzApV d4PQc8qPnJheWNQqjHYTTZancOVgiRhuaeGEtz7Un57Z6IVJh6SLKIUt+NQoP/xwLzMc ZFYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768463530; x=1769068330; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=G04VNH9mM5QJYcfrwDmtk2vbND5eL1Ze1p1mnEyfR7g=; b=ZWyBw6zYg9MPBRlIYtDpd4dRORSmpc3/0u0ij/fdwvtsnaekG6DSiSAXjF0ydX36zK +AJDytNFDJVDldrAs6opw4HlnQ62QgOcoeETr0r1apL8eYDmBRB3Kty3aTp7u4cwriVG sNgdft1aorltvTjuV+OL0s6MxobeWQiNAK4gzBKNtNWK6VmJgyyvIxZ3eVqponTohvR3 LXSrUPcbu6Mo6cWs0mzhjv2TUcXJVGJ+rhdsBZnzUlgZ7WiERqap30kd+YdC9/fYrsHF 0Osfi/tO+8pTZIIj2lbc71C0EELBpfbfNEsw5JZxVTRptvtnGPoMcQ3LtAs5rdLSU+sO oYNw== X-Forwarded-Encrypted: i=1; AJvYcCXy0UUtJIWNT66KvDczrjwFAiL9AAq036Phuf5gTpvuCuHC1ftolJqb2nEUSpNdJCrd7ti/xvJ5boE=@lists.xenproject.org X-Gm-Message-State: AOJu0YxPR+7/1mnhxcGmlOZf1D+ucm4HXtNUFWV5zy7TjgyKmpp+XTE0 ut+3Cnn2We1nb0X1iWdv5O8hUNqFlO7JhRF2kC/FduLkTI4uJtjyw8dYwLjA/aH9Zg== X-Gm-Gg: AY/fxX5ekP9ojbZQhwNV/XWMIwgJASYFxdHezalNocOWzzGUUUzsUt2vCAA29HYN4Ug UkgqLP1+Vb58OhqxZe4AKkLD9xsU+dX2alZ69je3eE0nRTUBHSffWUJxrLIlucnA47ByWq5Momf E6RT+0XWpJeRZBDGyG0dpWOl+idVGPKIQlPul943v3Pqrlcl1uYda6wz1FxSEa3eArnpOXrbiO7 R61sR7p8hpx5wauzMxygMJS+vbuJerMb4CZEGBEliyH34aj1pi5iWg6PxMlTwIjqORGPoFDwpQf +vUk5ljFAb+vqs29zuAEpALdMtILtGyVzZ/kmPZR77EDcjKQIPebUA8eLNO5S2jWwbs7eEJmMFI vG/SkfAzu1aGFn/3fig+0PRpF6h03fRFc8+a5ulS7gYxxHpM4Di9JeLiS2Ic5sbxHnPanQpoWqv uT1qYeoFtRntBSH0f+R5kkXqATW1Wji7jDwsqGSb/bWtkpbAd7f//IfpEjVIiRm0eH7PwdyyLAD x8= X-Received: by 2002:a5d:5d83:0:b0:432:5bf9:cf22 with SMTP id ffacd0b85a97d-4342c4f4c89mr5829537f8f.3.1768463529727; Wed, 14 Jan 2026 23:52:09 -0800 (PST) Message-ID: <8fa84e68-72b6-4578-9c3b-70d85d268c53@suse.com> Date: Thu, 15 Jan 2026 08:52:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 08/15] xen/riscv: introduce vtimer_set_timer() and vtimer_expired() 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: <8cd3efa488b3da2a6751c92d20bbfeb87b3ba39a.1766595589.git.oleksii.kurochko@gmail.com> <4e18e4fc-de62-44fc-8ea0-517f6c7ef47f@gmail.com> <62c22b34-cbad-40f2-a367-ba5fd8d11b51@suse.com> <5c6eff93-0db7-4382-8365-6b32b17f5f4d@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: <5c6eff93-0db7-4382-8365-6b32b17f5f4d@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 14.01.2026 16:59, Oleksii Kurochko wrote: > > On 1/14/26 3:57 PM, Jan Beulich wrote: >> On 14.01.2026 13:27, Oleksii Kurochko wrote: >>> On 1/13/26 4:12 PM, Jan Beulich wrote: >>>> On 13.01.2026 15:44, Oleksii Kurochko wrote: >>>>> On 1/8/26 11:28 AM, Jan Beulich wrote: >>>>>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>>>>> + { >>>>>>> + stop_timer(&t->timer); >>>>>>> + >>>>>>> + return; >>>>>>> + } >>>>>>> + >>>>>>> + set_timer(&t->timer, expires); >>>>>> See the handling of VCPUOP_set_singleshot_timer for what you may want to >>>>>> do if the expiry asked for is (perhaps just very slightly) into the past. >>>>> I got an idea why we want to check if "expires" already expired, but ... >>>>> >>>>>> There you'll also find a use of migrate_timer(), which you will want to >>>>>> at least consider using here as well. >>>>> ... I don't get why we want to migrate timer before set_timer() here. >>>>> Could you please explain that? >>>> Didn't I see you use migrate_timer() in other patches (making me assume >>>> you understand)? Having the timer tied to the pCPU where the vCPU runs >>>> means the signalling to that vCPU will (commonly) be cheaper. >>> I thought that migrate_timer() is needed only when a vCPU changes the pCPU >>> it is running on to ensure that it is running on correct pCPU after migrations, >>> hotplug events, or scheduling changes. That is why I placed it in >>> vtimer_restore(), as there is no guarantee that the vCPU will run on the >>> same pCPU it was running on previously. >>> >>> So that is why ... >>> >>>> Whether >>>> that actually matters depends on what vtimer_expired() will eventually >>>> contain. Hence why I said "consider using". >>> ... I didn't get why I might need vtimer_expired() in vtimer_set_timer() >>> before set_timer(). >>> >>> vtimer_expired() will only notify the vCPU that a timer interrupt has >>> occurred by setting bit in irqs_pending bitmap which then will be synced >>> with vcpu->hvip, but I still do not understand whether migrate_timer() >>> is needed before calling set_timer() here. >> Just to repeat - it's not needed. It may be wanted. >> >>> Considering that vtimer_set_timer() is called from the vCPU while it is >>> running on the current pCPU, and assuming no pCPU rescheduling has >>> occurred for this vCPU, we are already on the correct pCPU. >>> If pCPU rescheduling for the vCPU did occur, then migrate_timer() would >>> have been called in context_switch(), >> Even if the timer wasn't active? > > Yes, migrate_timer() is called unconditionally in vtimer_restore() called > from context_switch(). migrate_timer() will activate the timer. Which is wrong? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 08:00:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 08:00:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204236.1518959 (Exim 4.92) (envelope-from ) id 1vgIH8-0005A6-38; Thu, 15 Jan 2026 08:00:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204236.1518959; Thu, 15 Jan 2026 08:00:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgIH8-00059z-0D; Thu, 15 Jan 2026 08:00:14 +0000 Received: by outflank-mailman (input) for mailman id 1204236; Thu, 15 Jan 2026 08:00: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 1vgIH6-00059s-BB for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 08:00:12 +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 36a8f0f2-f1e8-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 09:00:10 +0100 (CET) Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-43277900fb4so735553f8f.1 for ; Thu, 15 Jan 2026 00:00:10 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af6b296asm4202111f8f.24.2026.01.15.00.00.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 00:00:08 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 36a8f0f2-f1e8-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768464009; x=1769068809; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=TiR68iTUJJECnVuKxLPU5y1gLJwzsBQYkPUS2tRwLPo=; b=RWrVLUB1qHS9S/HW+QmPKbz84sfIDyKSw9kxIHJ8Y33MGelpt1jW0yY698wiNrLs6+ +goU5M9Z5YuHvl7aZ0JSxSZX7Y2qx7weLpF9FVb2WB/CTI1rbKw6dAORZ2IaulkOR7gB w369YPEpsxjq8Wy29v3sZtGveUQcuzy7N6U7oJTGBFTsgY/yCv6pDTD9uceD6MPgIxU2 /0mjkmP8vTS/PJo2im8/3ydOUChB9RgUOy5MitfyBn0vJjozA/W5v0Ozh3+IfXD4xr/m I8pkifQgjHRuURbxDuRpc+NmLXOVBXKF7YIrSzXRZGhpPkMeB2p9cpS7RtacJkXFj+ic iX5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768464009; x=1769068809; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=TiR68iTUJJECnVuKxLPU5y1gLJwzsBQYkPUS2tRwLPo=; b=qpLaW32GHsknaC01gKdWoGngLcn84vBDh51GZyuF7ItpwAMHxVd1u5p4O8TQOecByE 5mzvoJvGUXJ8u6JNDB/Q89+e50Ok86SXptEK2r+SER2wnkbIVHzXeufROwiGfnB8rEQA X6jSiKB2KAm1xx+7H80ABp/t6eFzw5qUILVHHPBrVS4AuTAnLDGJADiUa0X5jq7DjD/A 6Xw4LuHvzicxtXtkMJWaI/2SSRmjUMqMXBBqaVqkPW5/JjVOBUaMiJ/WNLR1tu/JDdb+ AiLD3jW8OQn+VCJdEpjhJq59HSxP/pMPuzrzPNXL1MFuTXtNKzpE8l9Itr1xwOMhgnQv anEg== X-Gm-Message-State: AOJu0YwwSL+773ET0G+s7keSw/+tuDnHPKk1h5af/u4+BBET2wjcl3aB hd+q9uzh3I5Vc/ACTWLxF5sVJIHcA4noPpFArQV/kwIyUrzXX7dfRGQ3RbV05KdMaA== X-Gm-Gg: AY/fxX7NCexnuiFxXjPjJaE2nt+B5a9XM3Bw7t8QamfyT3SjRUzsEXMoDgA/lgbrMpT YJT7kNBRc/EMFIhLMNoN7h2GaSTxe46JedoA+cdFajlbL48jSuEvQqlIy435nUfTXHMRyj8GxbR IHBS0omVPuG14O6B86xiZYkipcqrojxeed542cqpWCKmyBajhwZn3bTdLQbGQo1ln+gxO+RI6lD fAZGPB4d1oJIiPIHc0UtN4LPMB3e5GfTyWHiR9THihokOmQrJ9yDm0CehgeALmeAnu6uTdRq2Jk JihC86P0qTtFDqbfzkCoJ2ShEBhBTW5s6DAYbDnPAsq/Vw5n+6B89OE42PzSdk6lmGvfrLPY/+z U3bOA6/sWjh8lIUcUeE41Tmk2YrJ7teVLJm99DXEtXntznxThF3gzG5TK6LXNXkfewMtA6l6qsA h8q1+B3IZ1amjzyTryUleD3c+9MMLGE9oPnol65hwY5SI/uZe5HlDnYd7FnyNblTdBXufktWQf1 b4= X-Received: by 2002:a05:6000:1869:b0:431:397:4c2b with SMTP id ffacd0b85a97d-434d75629d7mr2804968f8f.11.1768464009252; Thu, 15 Jan 2026 00:00:09 -0800 (PST) Message-ID: Date: Thu, 15 Jan 2026 09:00:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , =?UTF-8?B?0JDQvdGC0L7QvSDQnNCw0YDQutC+0LI=?= References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <1f539879-3083-41d5-a2c5-c63c9161f0bf@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 14.01.2026 18:49, Roger Pau Monné wrote: > On Tue, Jan 06, 2026 at 02:58:11PM +0100, Jan Beulich wrote: >> A similar issue looks to exist in read_xen_timer() and its read_cycle() >> helper, if we're scheduled out (and beck in) between reading of the TSC >> and calculation of the delta (involving ->tsc_timestamp). Am I >> overlooking anything there? > > If we are scheduled out in the middle, and the ->tsc_timestamp is > updated, ->version would also be bumped, and hence the loop will be > restarted. I don't think there's an issue there. Oh, indeed - I was too focused on the read_cycle() alone. That may go wrong, but as you say the result then simply won't be used. >> stime2tsc() guards against negative deltas by using 0 instead; I'm not >> quite sure that's correct either. > > Hm, we should likely do the same for stime2tsc() that you do for > get_s_time_fixed(). Given the current callers I think we might be > safe, but it's a risk. Will do then. >> amd_check_erratum_1474() (next to its call to tsc_ticks2ns()) has a >> comment towards the TSC being "sane", but is that correct? Due to >> TSC_ADJUST, rdtsc() may well return a huge value (and the TSC would then >> wrap through 0 at some point). Shouldn't we subtract boot_tsc_stamp before >> calling tsc_ticks2ns()? > > amd_check_erratum_1474() runs after early_time_init(), which would > have cleared any TSC_ADJUST offset AFAICT. There's a note in the > initcall to that regard: > > /* > * Must be executed after early_time_init() for tsc_ticks2ns() to have been > * calibrated. That prevents us doing the check in init_amd(). > */ > presmp_initcall(amd_check_erratum_1474); Hmm, I should have written "Due to e.g. TSC_ADJUST". Firmware may also have played other games with MSR_TSC. >> A similar issue looks to exist in tsc_get_info(), again when rdtsc() >> possibly returns a huge value due to TSC_ADJUST. Once again I wonder >> whether we shouldn't subtract boot_tsc_stamp. > > I would expect tsc_get_info() to also get called exclusively after > early_time_init()? Same here then (obviously). >> --- a/xen/arch/x86/time.c >> +++ b/xen/arch/x86/time.c >> @@ -1649,8 +1649,13 @@ s_time_t get_s_time_fixed(u64 at_tsc) >> tsc = at_tsc; >> else >> tsc = rdtsc_ordered(); >> - delta = tsc - t->stamp.local_tsc; >> - return t->stamp.local_stime + scale_delta(delta, &t->tsc_scale); >> + >> + if ( tsc >= t->stamp.local_tsc ) > > Should we hint the compiler this is the likely path? I was wondering too, but was erring on the side of "no" primarily because of Andrew's general preference towards no likely(). I'd be happy to add it here. >> + delta = scale_delta(tsc - t->stamp.local_tsc, &t->tsc_scale); >> + else >> + delta = -scale_delta(t->stamp.local_tsc - tsc, &t->tsc_scale); >> + >> + return t->stamp.local_stime + delta; > > LGTM: > > Reviewed-by: Roger Pau Monné Thanks. > However I see Anton still has concerns that this patch doesn't fully > fix the issue he reported, and I'm afraid I don't really understand > what's going on. I will have to take a more detailed look at the > thread, or possibly attempt to reproduce myself. Largely the same here. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 08:24:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 08:24:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204263.1518969 (Exim 4.92) (envelope-from ) id 1vgIed-0008KB-3l; Thu, 15 Jan 2026 08:24:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204263.1518969; Thu, 15 Jan 2026 08:24:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgIed-0008K4-0Y; Thu, 15 Jan 2026 08:24:31 +0000 Received: by outflank-mailman (input) for mailman id 1204263; Thu, 15 Jan 2026 08:24: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 1vgIeb-0008Jy-HC for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 08:24:29 +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 9918c11c-f1eb-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 09:24:24 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by LV3PR03MB7405.namprd03.prod.outlook.com (2603:10b6:408:19c::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Thu, 15 Jan 2026 08:24:20 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Thu, 15 Jan 2026 08:24: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: 9918c11c-f1eb-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Ksi2qvca1KBMEyxWCTWnEc7VBF9mbIVV+jXSA0ZO6CGoVcaXE11ASOnvDFm478K+3x+ZTOs6mrjWjH3rfR5oSCISJhsHhSUJwFhogsoukraBIdxQMonGQLBZZku9645Z9dfUs19/IK1mM325KQEX0FL3onFiCq5mf8QlK0wtQuowOz6dBz5+m1+tozoKSn4N/4NdgGspPn/T8kbe3qZrLhTDHqEz2UhdFzgyRXznoi+gLZC2NVe4WbJKF9OqzPC9sFN3lOMNbBthFxLMnAvdcyCIwsWArqds0aVuz/WL9Ppno0T6dUf/Q7bvvk/uqZj89ZyH8OUSud56w6xHk4QXZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QWbM/gihrIFqE2bja28+nto3VqlAb8waADxRcQuJ7t0=; b=dZVAPSlM/94DiAQuCAoeFNdyH0lwFAGO4Shr4s2n3sRAUHhBRGTAmxaI8xH4laC/o3ZsVrR4iJ7yDAxxfyoDFP52oZVgCdtCSF3Z6eREa/lIQDNfmGCPKbRLyuiXi4kbcKNRJf+MhwUVfg6G/KnV148n02AHuSfb2wXC+fGWH/jz1inoVA5bJLQo28jubpM55SFVXAKn+1NFtRJpnRSn1iRRWWoI64j1ho0xLI8ivLMXHZV2k9zbVkopI2Vo3MSMzwo+k2IprMcwp0LdUQ5FcVn0/ugsxr+gyb39bPMQi/6qryAz+jISPui83e3pbGuOC/1D5KA4lZMVkdhnF5IW0g== 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=QWbM/gihrIFqE2bja28+nto3VqlAb8waADxRcQuJ7t0=; b=D56A4AUofk5l8KtDa3BfcLoXV3RuRoBf9uzOlY+bwAbumhquQb7n/P7gccYDTny4bCGGmrK6kajgM0BoZ2KCGHwmBjI+m8VL+0VL4YrZPxjSTjZvopVxf6LMh18e8keAyLjO5FMQ6wD841j+zcSl3ST17R06sHHAFZIon4wue14= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 15 Jan 2026 09:24:16 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , =?utf-8?B?0JDQvdGC0L7QvSDQnNCw0YDQutC+0LI=?= Subject: Re: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() Message-ID: References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: PR3P193CA0023.EURP193.PROD.OUTLOOK.COM (2603:10a6:102:50::28) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|LV3PR03MB7405:EE_ X-MS-Office365-Filtering-Correlation-Id: 057c4207-be0c-4d4f-7f21-08de540f7b44 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?WithektTL0tnakx3SHk0Tm83ZmFacDZOcGZJbHZyaHQ3SnBOenBvcWdMc1Mv?= =?utf-8?B?cnZldjZGQXIzdTMvMzhLandJSUpBSEwyT3haTEEvQS9vRVB2c2ZQZ0JrSG44?= =?utf-8?B?RjNqSUJFaGNxODZxaFZTR1BleXVBMGNQOFMzYzUvRUM5YUVUd3Q2ZmpKV0Z4?= =?utf-8?B?ZGM2U2FNa3FFSk9ROVZMeEV0WDhPTnQvamVUV0lkTU1JMWhaRWZBczkwQWdE?= =?utf-8?B?bWlNSkVFWGxEK0U1dDdud2swRGJuYkRsKzllV2xJdk1oWEZNOFdhRFlDYjQy?= =?utf-8?B?R21UREY2NDlROWdWblNaZkVPQkF3TFJaTVQ0R2xhNUZvNUJjb3RkOEdycm50?= =?utf-8?B?WEZzWGo5cVhHSkJ6VFRTTTM3QmJzdnpaWE80RXFJcWFaN0R2ei95QWVGSlJY?= =?utf-8?B?eElua1BGOG5SbkdHbWpUcklSWHNSQkJxeGlCbGFlMThYNndneDlzMjRqczJ5?= =?utf-8?B?NnNTbTVzazU5MjBBVjVTWXZvRTZWcGhlK1VFRk1mSFlUc1RwSWVGUEJZdmsy?= =?utf-8?B?aTlVZFNMdTVZcDloU2xNVERoSi96emR3SUhuK0dvWWNsK2dBOUdXM1lELzdw?= =?utf-8?B?cGQwTzlyK2orSUhCNTVsZ3ZDUXMwb3liQ25DWVZvTVErUWhtbStTZjNwc1J5?= =?utf-8?B?ZmE3L3BwbFNjYzkxZFpKWWRJd0VSMWtMVFA0RkdjM3JUNlBNdi95aVRWL2cw?= =?utf-8?B?b20xZEJZbnhLQTRPd2FVdlVQSUpxT0wzUENMaksrdkNIaFdVbkRwNlNDN1Rw?= =?utf-8?B?SUZGTDkxYkJkQzdjdmw1L0c1ZVp2VjhtVDR2enJGTXdsR0s2WkNHWk01UXNV?= =?utf-8?B?S21ockpCSWNCV1F0ZllZTzd0ZFQ0ZUZuMXI2bG5YM3B2NWJwbGlBUGtlMWZK?= =?utf-8?B?bGVNSldEcDV1VEh3Y3dONmhHM0lTTXd1aU55c3dsQzEvNXpnYnhBdnVwQVVa?= =?utf-8?B?LzJSaGZqaFdUZFpxQmk3bnBsNEp3Y1V6K21pUUx2a1NXTS9jOWFCV0REZUNT?= =?utf-8?B?WjBtSlBoWlNZVnVZMmRrNEh5cmZTcWt2bElESGt4MDloaFdSekxLQzRWMk5T?= =?utf-8?B?eUJGVVZFSkpZZFVIaVVSOFJCS3FSeTl0cWJvRm5Fa2hpakNBMGNIb0FsL2J0?= =?utf-8?B?WEVnZ0QrOFlrSlVZb0dSQVRTbDZJQmllQ1laN21UYk9NYU13RFlmaFAxOHBL?= =?utf-8?B?bGVaYUNOelFxcld1OGVhRzkxM3VoSmhMV014VGVZaDRmTDN5NnNRSUpPcTBV?= =?utf-8?B?SDFIL2dLa2ZaRjFnekd0WEg2cFY3QkhsMjRZR1RscXBZOEloTUdWYXgzNkdP?= =?utf-8?B?R1pZWWU1YnI5NmRMUlYyb3VPMk5UUlpNL3JFM1NmOGRPOERxRjNOR29vTnkw?= =?utf-8?B?K0kxZGRkOFZ5cXZxa3VEWFpxbjBmMm9CZUhTTEd6U1dMN3VsK0EvSkZtSmJs?= =?utf-8?B?bUF4ZTFDTGJ4QXp6TXJMSHQzTW1YcFF0ajJwenpkQWs0TWgwM2Ftd2pHY0ps?= =?utf-8?B?dUVlZXJXYm1sTGZoODB3RjJiY204R0Y0dkMvRkl5czUyVlJ1b0YxdjZEZzZl?= =?utf-8?B?aTAzTGFWQUh5OE10ZnlJZER6Q0VSNjNrbVRaa3U3Qnh1cTdvY1JQYjkvWVBz?= =?utf-8?B?empJZVJqRXljd2ppeTQ1eC9wcDd1UjhRN2daSGNic3dKNFBwdW16Yi9ZZjVV?= =?utf-8?B?VnB2dENmME9lYlRjZ0tMRW1CVFZucmZVaEVFYWE2bDh2eE5uSi85NkU3MTBZ?= =?utf-8?B?T1V0OGlmQ21heG5IOXYybDR5WXE2eHFWVU83VDRJOGxxN0c3czd5THBMV0Iw?= =?utf-8?B?d0JlaHhTMnNNSm5qMDJ2S1ZzVllqY1ovSlBMUVl2bmlZWTVEV2o4NXM2T3hu?= =?utf-8?B?L3hXRU9VZGVNYUNlZHIyTW85cExwUmQzZWEzcE9XT291TG1ISllkbnJsTncz?= =?utf-8?B?aUR1eEtCQk1NR0ZQY3NUakNJNzQ2KzBjZ3BTTWlaZEFmdURsVVY2WU9lL2pr?= =?utf-8?B?ZEhNME9zQnV5THFGU29CYzBtWWNkSmRSdG1FWUdkKzVLNUZLVUhCaGo4cHFG?= =?utf-8?B?T0R5aVBqUVdBTU5MUHZ5SnQ1ZEpnZzhoOW1LckZjelpKaFFlZGJjdWV4REl1?= =?utf-8?Q?YYJ8=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RTdHQXYybzBzUGdHWDdFQys2UFNqT2RjR1ZsdURsQStUZWJuczlqZ2VyNE9i?= =?utf-8?B?cW1Xc2lhdDZxTmRJSTJ2aUlubGtrdEdLK2pyUm1Qbk15OXdRQUtMNmZUTEgy?= =?utf-8?B?WExqbjY1QUZMaVBlemJsak16d3JuUmZmWm5Pa1h2SXNKeFBFUnloOURxWHpR?= =?utf-8?B?WDB4b1lQOG43dzVkY3Z1cXNobzgybXoybmUram5pR1BTQjdRbDJPRVZqbG4x?= =?utf-8?B?QTB5TjMzRnJpVkFaaXI4b2VyUTRqb2xueWQwTjFaWE1GS3N1S0dkemw5T3NY?= =?utf-8?B?RUpWSXJyZDJ2VjFuaGdwdWZtK1I0Vm14T0VDWDcrZ0dWN0RueUE0SHZmOU93?= =?utf-8?B?VGEyVmpOWEM1VlI2VVBxSkZlb2drK0VtSEdBOGJLM0JYdEZZT2owOG5UbEJo?= =?utf-8?B?cGZPaWZtVmsxQ3JMSmpnVTJKTDBBZWJOc1huQkk5dlp2WWJYcFArcGw5OUdL?= =?utf-8?B?VmJxMmkzQjU5V25QWEtHM0JqbGlPSlA1UjE4Z1RuY2tGSmRjK0JKT3E4cGh1?= =?utf-8?B?Vm5kNlY5cDBVVGg5TTBaMzcxSVF0cVNJanhFbTZqbU1QUVNpdEo1MlRyZC9m?= =?utf-8?B?OEVnK2U0OFE5d3Q1blRQM0R1SFRjTFNwdk1Hc2pyK0FNZ1RYaHNVcEdGU0Fs?= =?utf-8?B?cTFrckZKMkRjcE8wd29RZGx4djh5TkJ2b2Q2aTg2dzRYR2RSY2ZPVCtYNTM3?= =?utf-8?B?b2kxaEhkbUo4WkxjNjA2aG1aSHhxSGZOYmx2OVU5Ym8rMFZyMFI3VHNoNXJt?= =?utf-8?B?VDNTYVhRQzExQ3VZSmlDYzFqVkt5ZXlWbmphcFpEQWhuM2FOWlB6VWU5TDlZ?= =?utf-8?B?aTMxcWJ0U0tqVi9OYjFwV3VmdG96cWVmN3VlRXdSUWd2bmJzQ3MyNTdOazBH?= =?utf-8?B?cm9oQVZPRWhTczh3UnJwd2p4aUs0c0RubDVvOGtEbW1GenU3T0NPSVNBQkNO?= =?utf-8?B?Ry90Tmx3NkFzekFIUEM0SnZoTStWeW84WkJ1dG1oRVdEeGNMb2VuNm5Qb1FK?= =?utf-8?B?MWlGYzhqME5pVHE2YjJFMTFhUFA5RGsyL1dhMDRhRkhDTnZwbzVhRW9RaHFp?= =?utf-8?B?QnBtbnp4WGl4VENYaXZtbTBQb2JhN1JwbEtLMG5tRG1KRW0vSytmL0tLZE9J?= =?utf-8?B?OUpyVUZXRnNyajMrYlNJeHhtRTFLaU1mNjdYVm00ZFRzRE9MTitOY0pERUF0?= =?utf-8?B?NEJ0anZpSGJUdGVjalpWZldXTkpwU1ByUGhXVVJiTDRuR2JpaUUwNDBsQlg2?= =?utf-8?B?bU15QzAvNDlJdC9TZ2RESVFZaWNIYXh2NFNBZW9xdkgrK0NCZmNraGYwS3JD?= =?utf-8?B?M0ZOS1dYSHYyQlBPME9FOUhwYno5UXpIMmU0QWZDYTI5NWRjOTIzK0IrQVhR?= =?utf-8?B?M0FhR1dzZEhPVjBGc3pJMXdJVzVFeURrYnhoMWRqUFVHNUVEUTJEdnMrUDFq?= =?utf-8?B?dFliemN5RG5OQkFCSTYvTDJjY1FTYXFrTnZEdmJBMUFpZm1oWEVZYnJ1RHp6?= =?utf-8?B?QXVGc010ZkpKMzFSTnZoSXhuakdWVExNdkNQUFJPb0c4Qkhia3NSaUpPY3py?= =?utf-8?B?UTQyUnVOaldZSEJybDk5RlNWOWpVRHhLWDBIQ3Nnd1IxUStjenhhZlUrenc0?= =?utf-8?B?WFlydE9kYTRBZlJiQ3NabDBnNUxnYnJ4b0Nva3VNVFllVnNFVURRZ09UVCs1?= =?utf-8?B?TFlwak9mMXBXTkJIUGIrUlFqemV6ZjVyOG8yd1dWK01LQjZvYjR3RloxdVI1?= =?utf-8?B?VkdNQmtldTRxRDB6WS9ycmZCYWI0VlNOUVRtM3lOYkFCNlB3YVNhbGFNNVZJ?= =?utf-8?B?UUR1WjVGWlltMGVGZE9kYndYL0FEL24rRHVFMFNWclNEV04zR0duNEtSYVVu?= =?utf-8?B?SllKSDJSZ01OSzJiZHpaNXp3YzN5NzlaSXo2OXdwMEZvaElKcGg5cTJjcUNI?= =?utf-8?B?ME14MWFqZjN5emVHeW02VHdBYjMvNGdZQTlaRUlvU3JxMzlsbVBlNzFDc0VS?= =?utf-8?B?cUhzMDZrbkYwL2xLYUNuV2ZZVlpDSmVGL1h1R05tSGE4YkJGemR5NlptQUdQ?= =?utf-8?B?VVRoN3hWZEx3MUNPTnVZNnlkKzhEa3hTaWRMUVFKa2Z1VUNEcHVTZk5VczRS?= =?utf-8?B?RnhiaWZ6aXdDdUhKdzBGSkJYWVd4ZjBWSERNVUhYMklROWd3Qml2T09MS3Rj?= =?utf-8?B?aC91cEJmQTFHSUVSTVlDT3pXQUwrcElkZ001QlFWS2RZQXB2ZzM3N2RoNjZi?= =?utf-8?B?YkhkLzFEVWJDNjhTVjZuTC9ZaG5sWEhwenEva0xHdmpBMk9QYmRHY1JZRURR?= =?utf-8?B?aGNNOU1LOUNoUmsyM0d0M3J0TkdHZnVRRmxwb0JnZmhGcWwzeGR0dz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 057c4207-be0c-4d4f-7f21-08de540f7b44 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 08:24:20.4051 (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: hzzaRO4tipSKHHI9/ve82rXxlU7q7J9xOh8peUspLUw7iNzLuaLzGt2+9ESBv0dvem5ol7s+cYuSS09NsHXmfA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7405 On Thu, Jan 15, 2026 at 09:00:07AM +0100, Jan Beulich wrote: > On 14.01.2026 18:49, Roger Pau Monné wrote: > > On Tue, Jan 06, 2026 at 02:58:11PM +0100, Jan Beulich wrote: > >> A similar issue looks to exist in read_xen_timer() and its read_cycle() > >> helper, if we're scheduled out (and beck in) between reading of the TSC > >> and calculation of the delta (involving ->tsc_timestamp). Am I > >> overlooking anything there? > > > > If we are scheduled out in the middle, and the ->tsc_timestamp is > > updated, ->version would also be bumped, and hence the loop will be > > restarted. I don't think there's an issue there. > > Oh, indeed - I was too focused on the read_cycle() alone. That may go > wrong, but as you say the result then simply won't be used. > > >> stime2tsc() guards against negative deltas by using 0 instead; I'm not > >> quite sure that's correct either. > > > > Hm, we should likely do the same for stime2tsc() that you do for > > get_s_time_fixed(). Given the current callers I think we might be > > safe, but it's a risk. > > Will do then. > > >> amd_check_erratum_1474() (next to its call to tsc_ticks2ns()) has a > >> comment towards the TSC being "sane", but is that correct? Due to > >> TSC_ADJUST, rdtsc() may well return a huge value (and the TSC would then > >> wrap through 0 at some point). Shouldn't we subtract boot_tsc_stamp before > >> calling tsc_ticks2ns()? > > > > amd_check_erratum_1474() runs after early_time_init(), which would > > have cleared any TSC_ADJUST offset AFAICT. There's a note in the > > initcall to that regard: > > > > /* > > * Must be executed after early_time_init() for tsc_ticks2ns() to have been > > * calibrated. That prevents us doing the check in init_amd(). > > */ > > presmp_initcall(amd_check_erratum_1474); > > Hmm, I should have written "Due to e.g. TSC_ADJUST". Firmware may also > have played other games with MSR_TSC. For amd_check_erratum_1474() we don't want to subtract boot_tsc_stamp, otherwise when kexec'ed we won't be accounting properly for the time since host startup, as subtracting boot_tsc_stamp would remove any time consumed by a previously run OS. > >> A similar issue looks to exist in tsc_get_info(), again when rdtsc() > >> possibly returns a huge value due to TSC_ADJUST. Once again I wonder > >> whether we shouldn't subtract boot_tsc_stamp. > > > > I would expect tsc_get_info() to also get called exclusively after > > early_time_init()? > > Same here then (obviously). For tsc_get_info() I think you are worried that the TSC might overflow, and hence the calculation in scale_delta() would then be skewed. We must have other instances of this pattern however, what about get_s_time_fixed(), I think it would also be affected? Or maybe I'm not understanding the concern. Given the proposed scale_delta() logic, it won't be possible to distinguish rdtsc overflowing from a value in the past. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 15 08:40:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 08:40:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204277.1518978 (Exim 4.92) (envelope-from ) id 1vgIuD-0002hR-CN; Thu, 15 Jan 2026 08:40:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204277.1518978; Thu, 15 Jan 2026 08:40:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgIuD-0002hK-9m; Thu, 15 Jan 2026 08:40:37 +0000 Received: by outflank-mailman (input) for mailman id 1204277; Thu, 15 Jan 2026 08:40:36 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgIuB-0002hD-4j for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 08:40:36 +0000 Received: from mail-24424.protonmail.ch (mail-24424.protonmail.ch [109.224.244.24]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id da7cac8d-f1ed-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 09:40:32 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: da7cac8d-f1ed-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=i3ue7g36xvelpdcfqqedl5amie.protonmail; t=1768466431; x=1768725631; bh=P0ydKPtJaYsx+LZsWuE/jP+cCQ+slQ4dQXQwtrZWcLU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=S7v8JtIbHpCRYkaIC9h5NfHQDs+Ee8RcjWiCzzRyHlUCyWx5Dh0c5fL0ZcCTp6qmt eWFJoAv9+4PVmTHiusxCTShakmh+8n5N54xKdZsN47U/6fzSGM0ohYU78VCRYw/lnZ VnBAuTN+NykKh61v04Bxu7GuvThIMwAtrkMnVOtVNNFyg1wqIFAjFCZr8SS6MDdHDC rUseYbxwZGEO/0QIBaR8i6aVdB4dp9QzrvsC9B7nr6mPEPLdvrQ10P7Ymy+Om9pbi2 fTejWaKghTG02fm24UUPXDzegfjLB+4mtKHnKjmQnugmoyXcfKkQOCcRqN7mwVBHD5 DP8VTZiOu326A== Date: Thu, 15 Jan 2026 08:40:27 +0000 To: Jan Beulich From: Milky Cc: "xen-devel@lists.xenproject.org" , Jason Andryuk Subject: Re: Cpufreq drivers not working on T480S Message-ID: In-Reply-To: <98b1ba19-40d3-4f36-9723-2773580df3e3@suse.com> References: <7dbd26d1-0d9a-454f-90d8-5a7f3d8e12da@suse.com> <8a2125c7-c5ec-4be1-a7a5-61b2936cc90f@suse.com> <98b1ba19-40d3-4f36-9723-2773580df3e3@suse.com> Feedback-ID: 171106842:user:proton X-Pm-Message-ID: 4bdbe48abd5975c7a2fe586f2384d992a2312307 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thursday, January 15th, 2026 at 10:51 AM, Jan Beulich wrote: >=20 >=20 > On 15.01.2026 00:42, Milky wrote: >=20 > > On Wednesday, January 14th, 2026 at 11:12 AM, Jan Beulich jbeulich@suse= .com wrote: > >=20 > > > On 14.01.2026 11:58, Milky wrote: > > >=20 > > > > Just wanted to update this thread to say that now another T480 user= (the T480 is a very similar model to my T480S) using the release builds of= libreboot (as of 26.01 RC1) also has the entries missing from the ACPI tab= les. That discussion was here https://codeberg.org/libreboot/lbmk/issues/39= 4. So this confirms that I'm running a standard libreboot, rather than a ba= d build. > > > >=20 > > > > Do you think there is any way to avoid the underclocking issue with= Xen on such devices/firmware? > > >=20 > > > In principle there is, but in the absence of ACPI data that means hol= ding model- > > > specific data in Xen. Which iirc is what the intel-pstate driver in L= inux does > > > (using ACPI info nowadays only as "auxiliary" data). But I may be wro= ng there, > > > as it has been a long time since I last looked at that driver. > >=20 > > In that case, would you say this is settled now? Would it make sense to= report back to the QubesOS community that librebooted T480/S will run unde= rclocked, due to the missing data in ACPI tables and lack of native support= in Xen? This information is important, as the device is only barely usable= . >=20 >=20 > What to suggest to the Qubes community needs to be discussed there, I thi= nk. >=20 > Jan I was just hoping to confirm with you that my understanding is correct, in = order not to pass the wrong information. In fact I intend to report this to= the libreboot/coreboot community too, in case there is a way to include th= e missing data in ACPI tables. But first I wanted to make sure that from th= e Xen perspective, we got to the bottom of it.=20 Thanks for your time. From xen-devel-bounces@lists.xenproject.org Thu Jan 15 08:44:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 08:44:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204290.1518988 (Exim 4.92) (envelope-from ) id 1vgIyO-0003LI-SC; Thu, 15 Jan 2026 08:44:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204290.1518988; Thu, 15 Jan 2026 08:44:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgIyO-0003LB-Pc; Thu, 15 Jan 2026 08:44:56 +0000 Received: by outflank-mailman (input) for mailman id 1204290; Thu, 15 Jan 2026 08:44: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 1vgIyN-0003L5-KL for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 08:44:55 +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 7689456a-f1ee-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 09:44:54 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-4801c2fae63so1027475e9.2 for ; Thu, 15 Jan 2026 00:44:54 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af653787sm4457147f8f.18.2026.01.15.00.44.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 00:44:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7689456a-f1ee-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768466694; x=1769071494; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=wjTKonMGUTxf8DA/ZyV7NizLlRvw2nj8sm+ZM78Gks8=; b=AzKnlMmidex2CUlrw7Crdrsf+gJGtHkdvSAszC7OvCLvqrDxYwPImA7UuDc2/c249M nzTy8CVbk8dLZJIOPKoE2osT0iQ1GWBntAbc7hsDyzMY+37v1NJyXr9JAP7K67RYG17p 5neABm+yByPidXAHOY0tqu5LWQIFC/W8saFLf16+lwcU97V5wjn0grtkPy03lBM6ls34 Qr0fHqGIb+xeBPZ6oR97ugCZOxdHxrLhL8uc06TIC+2xejwR2WRVWTV88SlAJD1mAPPR QZKqpZWwOZa4w8b2G+LIcoZ09SEMtDa/2ymaKZDTaFDZPfL/MjpNvGhhIAm46uPFreGI cQow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768466694; x=1769071494; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=wjTKonMGUTxf8DA/ZyV7NizLlRvw2nj8sm+ZM78Gks8=; b=NVPvc1UeSZpWMvj6y8N2jQosk6v/PM2dSGeNpcLj5UWwQlA/mfTdHwnGhaCzQaJYs6 Qm9aSsBa6QMnGoMdaoeK/8TIDk3h0kWz+5YMVnGX15AuLYBoiDd7o2f/E/UlSmIQaPwC oceJb9Zlaacx0zMzpMNvX+8encDspZ2cmWKu0ysGcUPMa3fQWZUyZhYS0OR2yJKX+MDD ncwY458I65V/JbpRZEto4IFP3s7zpl1PqgD7qf6SVld0FvVu0bOnNLBhQ7Z0zy78H4Ca gwr5GrD+5ur1n+4ysg6RzYd7H4Eo6R156usS8rinifj13k5y08TuMMVRvuLRvXxhdPx3 bu4Q== X-Gm-Message-State: AOJu0YyK040hd+FM6/lMRC5nVuiWYjRyhQwRHKjmltDnRiNhfQHBvfD6 baJVHzBWNNfXeglueuSBSbayvgBVmAT/ttvnxH+uKgvvLbQNyMYZpuLFZ6T1ave+OA== X-Gm-Gg: AY/fxX49VxyD8HD+LDv2OovSihpXaC2bysh1+U+AyWpS+EHo7Z9aN0IKcSvJm+Iqw/c x5oNfs2lofPBvP188jNY8tlrGhKJ+OiqCjBc7iW7BOgHdHMQ/fFnpDfZrSgAq6sC6zFIfwd4Tp9 rcRt1SZ+6YSE63zXz15oXvP5EE7jZnWXvjOV702VwYNnvjrh0Ba20FRjD3W2AQ+UtJ73lbCIaAP Qgyu4qdSzFS6RlPbUga4KEE9MNaJqRhMTX8ELBJLS1TPz3koPitJDo8PUwgAonBdh1SfYg7hLtc g8CiOO99zVsX75JqSZt2XuaKXc6Kz1WzPrhMq3IUdoG6tLdsDuN+G0kJ7sXj5fbEBZBzgKel+AK GL4f3nT7gtxe2DCAlDpJ98+PXDTsXoy+nObNIMgLU/w3to+j/WwYoFLNpjjHxAZ+/GrNk65n9S+ xcplZBnr+jZzxYMm+Gd+JRSiaieCHsWTIeqBEkCD5SARK921Z8orplP0qDQsfSXLWPuJxN+mmrz fc= X-Received: by 2002:a5d:5f83:0:b0:432:dc5c:25cf with SMTP id ffacd0b85a97d-4342d5b27e0mr5796979f8f.18.1768466693679; Thu, 15 Jan 2026 00:44:53 -0800 (PST) Message-ID: <11e81503-615b-48a1-8136-14386c57c4a5@suse.com> Date: Thu, 15 Jan 2026 09:44:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Cpufreq drivers not working on T480S To: Milky Cc: "xen-devel@lists.xenproject.org" , Jason Andryuk References: <7dbd26d1-0d9a-454f-90d8-5a7f3d8e12da@suse.com> <8a2125c7-c5ec-4be1-a7a5-61b2936cc90f@suse.com> <98b1ba19-40d3-4f36-9723-2773580df3e3@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 15.01.2026 09:40, Milky wrote: > On Thursday, January 15th, 2026 at 10:51 AM, Jan Beulich wrote: >> On 15.01.2026 00:42, Milky wrote: >>> In that case, would you say this is settled now? Would it make sense to report back to the QubesOS community that librebooted T480/S will run underclocked, due to the missing data in ACPI tables and lack of native support in Xen? This information is important, as the device is only barely usable. >> >> What to suggest to the Qubes community needs to be discussed there, I think. > > I was just hoping to confirm with you that my understanding is correct, in order not to pass the wrong information. In fact I intend to report this to the libreboot/coreboot community too, in case there is a way to include the missing data in ACPI tables. But first I wanted to make sure that from the Xen perspective, we got to the bottom of it. Well, "got to the bottom" builds upon the needed ACPI data indeed being absent. Which I can't confirm, only you can. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 08:49:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 08:49:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204299.1518998 (Exim 4.92) (envelope-from ) id 1vgJ2H-00040G-Ai; Thu, 15 Jan 2026 08:48:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204299.1518998; Thu, 15 Jan 2026 08:48: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 1vgJ2H-000409-8C; Thu, 15 Jan 2026 08:48:57 +0000 Received: by outflank-mailman (input) for mailman id 1204299; Thu, 15 Jan 2026 08:48: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 1vgJ2G-000403-0A for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 08:48:56 +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 05c42980-f1ef-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 09:48:54 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 012EB5BCEB; Thu, 15 Jan 2026 08:48: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 B147A3EA63; Thu, 15 Jan 2026 08:48:52 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id PESNKPSpaGnEIAAAD6G6ig (envelope-from ); Thu, 15 Jan 2026 08:48:52 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 05c42980-f1ef-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1768466934; 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=T4gQhUuagqLQmvTbN6c66jJbuGTJE17NFmXSnIA/TI8=; b=oY/oDF+NuXX3VQAMqj48JB2uJpwCE02l/tyX1XP8NP8s8NDMfNclL60SpFFymmyPD8xbKm 3zQFJ7U6Dsz2aQ7TBXM+KT0K5gugtITLCIqJaODaSpR2C3X3UjJBR5+hk/YzNFViJrRj7q gg7DeJg2TV0yKBcuSezRh2RRr5lGf+4= Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b="oY/oDF+N" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1768466934; 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=T4gQhUuagqLQmvTbN6c66jJbuGTJE17NFmXSnIA/TI8=; b=oY/oDF+NuXX3VQAMqj48JB2uJpwCE02l/tyX1XP8NP8s8NDMfNclL60SpFFymmyPD8xbKm 3zQFJ7U6Dsz2aQ7TBXM+KT0K5gugtITLCIqJaODaSpR2C3X3UjJBR5+hk/YzNFViJrRj7q gg7DeJg2TV0yKBcuSezRh2RRr5lGf+4= From: Juergen Gross To: linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux.dev, kvm@vger.kernel.org, linux-block@vger.kernel.org Cc: Juergen Gross , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Paolo Bonzini , Vitaly Kuznetsov , Boris Ostrovsky , xen-devel@lists.xenproject.org, Denis Efremov , Jens Axboe Subject: [PATCH v3 0/5] x86: Cleanups around slow_down_io() Date: Thu, 15 Jan 2026 09:48:44 +0100 Message-ID: <20260115084849.31502-1-jgross@suse.com> X-Mailer: git-send-email 2.51.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: -3.01 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)[]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; FUZZY_RATELIMITED(0.00)[rspamd.com]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; MIME_TRACE(0.00)[0:+]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; RCPT_COUNT_TWELVE(0.00)[20]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; DNSWL_BLOCKED(0.00)[2a07:de40:b281:106:10:150:64:167:received,2a07:de40:b281:104:10:150:64:97:from]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[suse.com:+]; TO_DN_SOME(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-Level: X-Rspamd-Action: no action X-Rspamd-Queue-Id: 012EB5BCEB X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Spam-Flag: NO While looking at paravirt cleanups I stumbled over slow_down_io() and the related REALLY_SLOW_IO define. Do several cleanups, resulting in a deletion of REALLY_SLOW_IO and the io_delay() paravirt function hook. Patch 4 is removing the config options for selecting the default delay mechanism and sets the default to "no delay". This is in preparation of removing the io_delay() functionality completely, as suggested by Ingo Molnar. Patch 5 is adding an additional config option allowing to avoid building io_delay.c (default is still to build it). Changes in V2: - patches 2 and 3 of V1 have been applied - new patches 4 and 5 Changes in V3: - rebase to tip/master kernel branch Juergen Gross (5): x86/paravirt: Replace io_delay() hook with a bool block/floppy: Don't use REALLY_SLOW_IO for delays x86/io: Remove REALLY_SLOW_IO handling x86/io_delay: Switch io_delay() default mechanism to "none" x86/io_delay: Add config option for controlling build of io_delay. arch/x86/Kconfig | 8 +++ arch/x86/Kconfig.debug | 30 ---------- arch/x86/include/asm/floppy.h | 31 ++++++++-- arch/x86/include/asm/io.h | 19 ++++--- arch/x86/include/asm/paravirt-base.h | 6 ++ arch/x86/include/asm/paravirt.h | 11 ---- arch/x86/include/asm/paravirt_types.h | 2 - arch/x86/kernel/Makefile | 3 +- arch/x86/kernel/cpu/vmware.c | 2 +- arch/x86/kernel/io_delay.c | 81 +-------------------------- arch/x86/kernel/kvm.c | 8 +-- arch/x86/kernel/paravirt.c | 3 +- arch/x86/kernel/setup.c | 4 +- arch/x86/xen/enlighten_pv.c | 6 +- drivers/block/floppy.c | 2 - 15 files changed, 60 insertions(+), 156 deletions(-) -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 15 08:49:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 08:49:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204300.1519009 (Exim 4.92) (envelope-from ) id 1vgJ2P-0004Gz-KT; Thu, 15 Jan 2026 08:49:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204300.1519009; Thu, 15 Jan 2026 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 1vgJ2P-0004Gq-Hp; Thu, 15 Jan 2026 08:49:05 +0000 Received: by outflank-mailman (input) for mailman id 1204300; Thu, 15 Jan 2026 08:49:04 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgJ2N-0004G1-VE for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 08:49: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 09cd28ca-f1ef-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 09:49:01 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 024B05BD50; Thu, 15 Jan 2026 08:49: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 D85283EA63; Thu, 15 Jan 2026 08:48: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 UJZeMPupaGnWIAAAD6G6ig (envelope-from ); Thu, 15 Jan 2026 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: 09cd28ca-f1ef-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1768466941; 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=IcAVv+KWnCRg/40DoITyiU2vnkn2NT3Rm2oPIYRObDo=; b=OqSKW0h/vTBTF5rxkK8jBk2q9SlrT+BMlkvp1CJtp/WTXpRALfw8fxy8tsdL3j99VTBm2E axEXjWeGzRk5Lpu4U283tMfbvwFKoQqBJq/HSFbufiaspchMqczltzIdIPomOzeSD3DNtb Yul6DYgFjlZDw5neu8XX3s+gzdIPYec= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1768466941; 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=IcAVv+KWnCRg/40DoITyiU2vnkn2NT3Rm2oPIYRObDo=; b=OqSKW0h/vTBTF5rxkK8jBk2q9SlrT+BMlkvp1CJtp/WTXpRALfw8fxy8tsdL3j99VTBm2E axEXjWeGzRk5Lpu4U283tMfbvwFKoQqBJq/HSFbufiaspchMqczltzIdIPomOzeSD3DNtb Yul6DYgFjlZDw5neu8XX3s+gzdIPYec= From: Juergen Gross To: linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux.dev, kvm@vger.kernel.org Cc: Juergen Gross , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Paolo Bonzini , Vitaly Kuznetsov , Boris Ostrovsky , xen-devel@lists.xenproject.org Subject: [PATCH v3 1/5] x86/paravirt: Replace io_delay() hook with a bool Date: Thu, 15 Jan 2026 09:48:45 +0100 Message-ID: <20260115084849.31502-2-jgross@suse.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260115084849.31502-1-jgross@suse.com> References: <20260115084849.31502-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-2.80 / 50.00]; BAYES_HAM(-3.00)[100.00%]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.20)[-0.999]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_TWELVE(0.00)[17]; FUZZY_RATELIMITED(0.00)[rspamd.com]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; TO_DN_SOME(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:helo] X-Spam-Flag: NO X-Spam-Score: -2.80 X-Spam-Level: The io_delay() paravirt hook is in no way performance critical and all users setting it to a different function than native_io_delay() are using an empty function as replacement. This enables to replace the hook with a bool indicating whether native_io_delay() should be called. Signed-off-by: Juergen Gross --- V3: - rebase to tip/master kernel branch --- arch/x86/include/asm/io.h | 9 ++++++--- arch/x86/include/asm/paravirt-base.h | 6 ++++++ arch/x86/include/asm/paravirt.h | 11 ----------- arch/x86/include/asm/paravirt_types.h | 2 -- arch/x86/kernel/cpu/vmware.c | 2 +- arch/x86/kernel/kvm.c | 8 +------- arch/x86/kernel/paravirt.c | 3 +-- arch/x86/xen/enlighten_pv.c | 6 +----- 8 files changed, 16 insertions(+), 31 deletions(-) diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index ca309a3227c7..8a9292ce7d2d 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -243,11 +243,16 @@ extern int io_delay_type; extern void io_delay_init(void); #if defined(CONFIG_PARAVIRT) -#include +#include #else +#define call_io_delay() true +#endif static inline void slow_down_io(void) { + if (!call_io_delay()) + return; + native_io_delay(); #ifdef REALLY_SLOW_IO native_io_delay(); @@ -256,8 +261,6 @@ static inline void slow_down_io(void) #endif } -#endif - #define BUILDIO(bwl, type) \ static inline void out##bwl##_p(type value, u16 port) \ { \ diff --git a/arch/x86/include/asm/paravirt-base.h b/arch/x86/include/asm/paravirt-base.h index 982a0b93bc76..3b9e7772d196 100644 --- a/arch/x86/include/asm/paravirt-base.h +++ b/arch/x86/include/asm/paravirt-base.h @@ -15,6 +15,8 @@ struct pv_info { #ifdef CONFIG_PARAVIRT_XXL u16 extra_user_64bit_cs; /* __USER_CS if none */ #endif + bool io_delay; + const char *name; }; @@ -26,6 +28,10 @@ u64 _paravirt_ident_64(u64); #endif #define paravirt_nop ((void *)nop_func) +#ifdef CONFIG_PARAVIRT +#define call_io_delay() pv_info.io_delay +#endif + #ifdef CONFIG_PARAVIRT_SPINLOCKS void paravirt_set_cap(void); #else diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index b21072af731d..f4885bd98a18 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -19,17 +19,6 @@ #include #include -/* The paravirtualized I/O functions */ -static inline void slow_down_io(void) -{ - PVOP_VCALL0(pv_ops, cpu.io_delay); -#ifdef REALLY_SLOW_IO - PVOP_VCALL0(pv_ops, cpu.io_delay); - PVOP_VCALL0(pv_ops, cpu.io_delay); - PVOP_VCALL0(pv_ops, cpu.io_delay); -#endif -} - void native_flush_tlb_local(void); void native_flush_tlb_global(void); void native_flush_tlb_one_user(unsigned long addr); diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 7ccd41628d36..3946d0f69921 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -30,8 +30,6 @@ struct pv_lazy_ops { struct pv_cpu_ops { /* hooks for various privileged instructions */ - void (*io_delay)(void); - #ifdef CONFIG_PARAVIRT_XXL unsigned long (*get_debugreg)(int regno); void (*set_debugreg)(int regno, unsigned long value); diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c index a3e6936839b1..eee0d1a48802 100644 --- a/arch/x86/kernel/cpu/vmware.c +++ b/arch/x86/kernel/cpu/vmware.c @@ -339,7 +339,7 @@ arch_initcall(activate_jump_labels); static void __init vmware_paravirt_ops_setup(void) { pv_info.name = "VMware hypervisor"; - pv_ops.cpu.io_delay = paravirt_nop; + pv_info.io_delay = false; if (vmware_tsc_khz == 0) return; diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c index de550b12d9ab..8c3221048d9f 100644 --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -75,12 +75,6 @@ DEFINE_PER_CPU_DECRYPTED(struct kvm_steal_time, steal_time) __aligned(64) __visi static int has_steal_clock = 0; static int has_guest_poll = 0; -/* - * No need for any "IO delay" on KVM - */ -static void kvm_io_delay(void) -{ -} #define KVM_TASK_SLEEP_HASHBITS 8 #define KVM_TASK_SLEEP_HASHSIZE (1< Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 08:49:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204304.1519019 (Exim 4.92) (envelope-from ) id 1vgJ2X-0004dl-TT; Thu, 15 Jan 2026 08:49:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204304.1519019; Thu, 15 Jan 2026 08: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 1vgJ2X-0004de-PG; Thu, 15 Jan 2026 08:49:13 +0000 Received: by outflank-mailman (input) for mailman id 1204304; Thu, 15 Jan 2026 08: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 1vgJ2W-0004G1-DA for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 08:49:12 +0000 Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [2a00:1450:4864:20::343]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0ef3f435-f1ef-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 09:49:10 +0100 (CET) Received: by mail-wm1-x343.google.com with SMTP id 5b1f17b1804b1-47ee4539adfso5809895e9.3 for ; Thu, 15 Jan 2026 00:49:10 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee11ab892sm39952805e9.6.2026.01.15.00.49.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 00:49:09 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0ef3f435-f1ef-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768466949; x=1769071749; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=gvsmLp7JhLuQWhLHWus5ECv1L4CKpHytFNpIKghAoJQ=; b=Gg6u9vzIwWk1SBsvvuojSlOBULmXZYBGHzanxJDHAcOhCnfv8pV7d6nwEWpjUsf6ru 7HfiPDg+rFOB9bPvfNH6+Y+n3vnd3g4cclH0VEMh2bk9+ZqqgXQeOfdItXlfupGK1Ym2 jpGLxYUdq9edqhI1EzSAnzAhu+wJ5Dcqn1qUUGcLWKj0ACAHSOm7BsjbKtHziUwz1fiG vK/PFGTf4SqVVZKrrBgkepW534iMp7SYkzEo47p/YnlaKZxXt8NcTcG1/2sjO7cDdGEu iINS18P6T8XqzZ82MIT74lGCO6YFilx4eg9DKy7i8IbZcoVm8gW1xfE8Ia2nDqyr/TXL 28RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768466949; x=1769071749; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gvsmLp7JhLuQWhLHWus5ECv1L4CKpHytFNpIKghAoJQ=; b=DRsRMNV7A/vuVxmjNmrR4d17pURmlRYNJh+fh8tSfM2p76rmD1845U8KnE8abAEDZ6 SlulfeboAtCGkEiXmZU5WPnn8wSliExDL+B9hwOHbX802iZ9UMYZ7fGwKvG3SPIAuRAh jfAh+eU39fUzKJ0tIt5aWdrC+eyq/6uFIlDkjXiCnMdWuZ/Tv3iy+LGrWMtrFr3sDD2H vId7yb6iB7MPjEl+GvulnTK9bh97Trb+DnZGi6SbDO+kDd76FHsFEINE+JTd+2AHOra/ ZnJvv/qruRF/ducY37TeOF6rTN5g0Plz3dw91KItH7mfSjvugigq8bOkjK29iMJkyHzS IQIQ== X-Forwarded-Encrypted: i=1; AJvYcCWVQ1LT+2roKCyBSyVAgyvseKbX7Pr7PDuMcEGglMELcFh1iT3cUjSajoVK9tjTdfk6zH3/NRpXxFk=@lists.xenproject.org X-Gm-Message-State: AOJu0YwWvd96xbAOg/86IeXQGr0AvGNpIavi26AWDLeXMsIZj3et5ba5 yiN+lj/swFE0bYxXuCk+fxNphM5FmQHXjn0i+xr6iIg7MXAAX49mlOj+/6Pb+l9OaA== X-Gm-Gg: AY/fxX6yaxr43TxHwi0FZF9nSLX+iDPBHY5Nt7IFSWVrCsB4vNaFuO35n3mfE7gboU/ B9YShBqtCqclhdTPBJjy8ETdkP1f1IlGr9VBOF6qGLpu/2U7X5AaiZSw1pygUyUgvwSJXgWCvGy BX3aPVmR9gg/jG+19JcU0DUnwI17RS/wAGy812u55S2njlbwrpFI0gSnLd5OD9mN/pML3F2zOdB CZN/IrFii1cQOXS0IZwf4P+FocIVysG7NIFZGqMtqMjT67QW7jOH1juIdyqb5Z11j5ompLdzpTq EG0fF/LUv6Nxj9hij/ugK+K4bA0vLtqGDbo0oTb7aJp4tFFsqvKu1DFMgy+BXXo7z0AYDKq5INT aPO8h2vkTGlLYI4TSF0v0jleFFDEzLakFDQDd7VJhaEPX4v/Sl1lnFQ9ekU6eVL77MlQc5MOOvt lZfNYeEY3kdD7wTSlpSscgqTNhqUP0OphMrR+r0CzXEp49vs1URlSepkfmeyCCsYGjrAJhnparf 7k= X-Received: by 2002:a05:600c:3555:b0:477:7c7d:d9b2 with SMTP id 5b1f17b1804b1-47ee338f01bmr70091245e9.32.1768466949385; Thu, 15 Jan 2026 00:49:09 -0800 (PST) Message-ID: <8621d9c5-15d3-4d6b-8119-006327efb5c4@suse.com> Date: Thu, 15 Jan 2026 09:49:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 0/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent support To: Oleksii Moisieiev Cc: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "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 14.01.2026 19:29, Oleksii Moisieiev wrote: > Inroducing patch series which includes implementation of the SCI SCMI > SMC multi-agent support. > This patch series follows RFC v5 [3] series which was introducing both > SCMI single-agent and multi-agent support. After the discussion it was > decided to split features and upstream singe-agent support first. This > feature is merged for now to v4.21-rc2. > I'm starting this patch series from v6 to save the discussion history > and don't break changes log. > > Patch - xen/domctl: extend XEN_DOMCTL_assign_device to handle not > only iommu > - add chainged handling of assigned DT devices to support > access-controller functionality through SCI framework. > Change was done in two parts: > - call to sci_do_domctl() to do_domctl() > - update iommu_do_dt_domctl() to check for dt_device_is_protected() > and not fail if DT device is not protected by IOMMU > > Patch - xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver > - add Xen-specific SCMI container compatible `xen,sci` > under `/chosen/xen`; Xen binds only to the `arm,scmi-smc` inside it and > ignores other SCMI nodes (e.g. under `/firmware`). > - add `scmi-secondary-agents` and `#scmi-secondary-agents-cells` to describe > func_id/shmem/(optional agent_id) tuples for secondary agents. > - each guest using SCMI supplies its agent_id (dom0 via `dom0=sci-agent-id=`, > toolstack via `arm_sci = "type=scmi_smc_multiagent,agent_id=..."`, dom0less > via `xen,sci_type` + `xen,sci-agent-id` in `xen,domain`). > - factor out SCMI generic definitions and shmem code. > - passthrough configuration for SCMI guests mirrors other HW passthrough. > > Patch - docs: arm: add SCI SCMI SMC multi-agent driver docs > - document the Xen SCMI container under `/chosen/xen/xen_scmi_config` and the > mediator’s binding rules; update examples accordingly. > > All Xen-specific SCMI configuration now lives under `/chosen/g` > to keep host DT changes isolated while leaving the host `/firmware/scmi` > untouched for Dom0 consumption. > > Code can be found at: > https://github.com/oleksiimoisieiev/xen/tree/scmi_ma_upstrv6 > > [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 > [3] RFC v5: > https://lore.kernel.org/xen-devel/cover.1753184487.git.oleksii_moisieiev@epam.com/ > [4] SCMI single-agent: > https://lore.kernel.org/xen-devel/cover.1756995595.git.oleksii_moisieiev@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 v7: > - update domctl to build on both Arm and x86 platforms > - move ret1 declaration to the top of the function as required by code > style > - x86 guidance: removed the speculative note; header now just says > each arch supplies its own implementation or macro. > - name spacing: dropped the double-underscore; the helpers are now > memcpy_fromio / memcpy_toio. The header also explicitly allows an > arch to define these as macros before including it. > - updated io.c to keep 32-bit transfers safe on arm32 > - moved to __raw_read*/__raw_write* accessors to avoid endianness conversion. > - split the helpers into separate compilation units > - rework scmi nodes for xen to match on compatible string instead of > the direct path > - update documentation in section of the xen_scmi configuration which > is matched by "xen,sci" compatible instead of the direct path. > > Changes in v6: > - change iommu_do_domctl and sci_do_domctl command order and > call sci_do_domctl first which will produce cleaner code path. > Also dropped changing return code when iommu was disabled in > iommu_do_domctl. > - sorted objs in Makefile alhabetically > - added newline at the end of Makefile > - used uint{N}_t intead of u{N} > - add comment about why 32 bit IO operations were used > - updated cast opertaions to avoid dropping constness which is wrong > - move function definitions to generic place so the could be reused by > other arch > - add SPDX tag to io.c > - updated scmi-shmem to use io.h from generic location > - update scmi_agent_id parameter to be provided inside dom0= parameter > list and have the following format "dom0=sci-agent-id=0" > This change was done as a response for Stefano comment and > requires a lot of code changes, but produces much cleaner solution > that's why I've added it to the code. > - fix file comments and return codes > - fix lenght checks in shmem_{get,put}_message to use offsetof > - remove len member from scmi_channel structure as it is not used > - set scmi-secondary-agents property to be mandatory since if no > secondary agents were provided then there is no sence to enable scmi > when no secondary agents are populated to the Domains > - update documentation in booting.txt, added xen_scmi node to the > example > - adjust d->arch.sci_enabled value in scmi_domain_destroy > - fix lock management in smc_create_channel call > - avoid extra map_channel_memory command for Xen management channel > because collect_agent_id call unmaps memory if DOMID_XEN is not > set. So for Xen management channel we can init domain_id ad DOMID_XEN > before calling collect_agent_id so memory shouldn't be unmapped. > - remove all HVC mentions from the multi-agent doc > - update sci-agent-id parameter description in the documentation > - add missing Sign-of > - minor fixes across the document > > Changes in v5: > - return -EINVAL if mediator without assign_dt_device was provided > - invert return code check for iommu_do_domctl in > XEN_DOMCTL_assign_device domctl processing to make cleaner code > - change -ENOTSUPP error code to -ENXIO in sci_do_domctl > - handle -ENXIO return comde of iommu_do_domctl > - leave !dt_device_is_protected check in iommu_do_dt_domctl to make > code work the same way it's done in "handle_device" call while > creating hwdom(dom0) and "handle_passthrough_prop" call for dom0less > creation > - drop return check from sci_assign_dt_device call as not needed > - do not return EINVAL when addign_dt_device is not set. That is > because this callback is optional and not implemented in single-agent driver > - move memcpy_toio/fromio to the generic place > - fix device-tree example format in booting.txt, added ";" after "}". > - update define in scmi-proto.h > - update define in scmi-shmem.h file > - scmi_assign_device - do not ignore -EOPNOTSUPP return > code of the do_smc_xfer > - remove overwriting agent_channel->agent_id after > SCMI_BASE_DISCOVER_AGENT call > - add multi-agent files to the MAINTAINERS > - add SCMI multi-agent description to the SUPPORT.md > - handle ARM_SMCCC_INVALID_PARAMETER return code and return -EINVAL > for smc call > - updated collect_agents function. Set agent_id parameter as optional > in scmi-secondary-agents device-tree property > - introduce "#scmi-secondary-agents-cells" parameter to set if > agent_id was provided > - reanme xen,scmi-secondary-agents property to scmi-secondary-agents > - move memcpu_toio/fromio for the generic place > - update Xen to get management channel from /chosen/xen,config node > - get hypervisor channnel from node instead of using hardcoded > - update handling scmi and shmem nodes for the domain > - Set multi-agent driver to support only Arm64 > - rework multi-agent driver to leave Host Device-tree unmodified > > Changes in v4: > - toolstack comments from Anthony PERARD > - added dom0less support > - added doc for "xen,scmi-secondary-agents" > > Grygorii Strashko (2): > xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu > docs: arm: add SCI SCMI SMC multi-agent driver docs > > Oleksii Moisieiev (3): > xen: arm: smccc: add INVALID_PARAMETER error code > lib/arm: Add I/O memory copy helpers > xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver > > MAINTAINERS | 4 + > SUPPORT.md | 11 + > .../arm/firmware/arm-scmi.rst | 341 ++++++++ > docs/man/xl.cfg.5.pod.in | 13 + > docs/misc/arm/device-tree/booting.txt | 122 +++ > docs/misc/xen-command-line.pandoc | 19 +- > tools/libs/light/libxl_arm.c | 4 + > tools/libs/light/libxl_types.idl | 4 +- > tools/xl/xl_parse.c | 12 + > xen/arch/arm/dom0less-build.c | 11 + > xen/arch/arm/domain_build.c | 26 +- > xen/arch/arm/firmware/Kconfig | 12 + > xen/arch/arm/firmware/Makefile | 1 + > xen/arch/arm/firmware/sci.c | 35 + > xen/arch/arm/firmware/scmi-proto.h | 164 ++++ > xen/arch/arm/firmware/scmi-shmem.c | 115 +++ > xen/arch/arm/firmware/scmi-shmem.h | 45 + > xen/arch/arm/firmware/scmi-smc-multiagent.c | 815 ++++++++++++++++++ > xen/arch/arm/include/asm/firmware/sci.h | 14 + > xen/arch/arm/include/asm/smccc.h | 1 + > xen/common/domctl.c | 35 +- > xen/drivers/passthrough/device_tree.c | 6 + > xen/include/public/arch-arm.h | 3 + > xen/include/xen/lib/io.h | 65 ++ > xen/lib/Makefile | 1 + > xen/lib/arm/Makefile | 1 + > xen/lib/arm/memcpy_fromio.c | 48 ++ > xen/lib/arm/memcpy_toio.c | 48 ++ > 28 files changed, 1972 insertions(+), 4 deletions(-) > create mode 100644 xen/arch/arm/firmware/scmi-proto.h > create mode 100644 xen/arch/arm/firmware/scmi-shmem.c > create mode 100644 xen/arch/arm/firmware/scmi-shmem.h > create mode 100644 xen/arch/arm/firmware/scmi-smc-multiagent.c Just like done here, can ... > create mode 100644 xen/include/xen/lib/io.h > create mode 100644 xen/lib/arm/Makefile > create mode 100644 xen/lib/arm/memcpy_fromio.c > create mode 100644 xen/lib/arm/memcpy_toio.c ... new files please use dashes in favor of underscores? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 08:49:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 08:49:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204325.1519028 (Exim 4.92) (envelope-from ) id 1vgJ2y-0005Ql-3m; Thu, 15 Jan 2026 08:49:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204325.1519028; Thu, 15 Jan 2026 08: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 1vgJ2y-0005Qe-1K; Thu, 15 Jan 2026 08:49:40 +0000 Received: by outflank-mailman (input) for mailman id 1204325; Thu, 15 Jan 2026 08:49: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 1vgJ2w-0004G1-Io for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 08:49:38 +0000 Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [2607:f8b0:4864:20::62d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1e7bee51-f1ef-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 09:49:36 +0100 (CET) Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-2a09757004cso5245935ad.3 for ; Thu, 15 Jan 2026 00:49:36 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1e7bee51-f1ef-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768466975; x=1769071775; 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=wmenWw37itcVsqTSbXJxL8Gqvg4SzPFeokBdkrMeGSY=; b=Xqnd1AxJQttwr7LymhEm0D9FRQ8C4fKzqhmz3i7tCe2LpEbKSxIP7/uWlX50E92HsA QFEBa+06cabOvCLTZrpyGPjaMQi2cnA80TRi7qtNyiiB9nPn9HNmrionFNlyznL76WLp sir/gPyLLM9dIpwkbUQNlGh3RJWikmxbUuAPAZi9FbfMJqXdGOaBZurUIdFL920nRBuc W1mJ1qPqgb5/Rul791AM3IO9wpkh4gEkjt2FdkMclS31kVh7nCDUd8CyJQiQnk0kNVFo NwPTC2zgwHRxE2Fm1Sw4NSANMtslVuWI9//alpwAO+LRmRFJrmt9kcGq8OdKhAnJ1uf3 AWVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768466975; x=1769071775; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=wmenWw37itcVsqTSbXJxL8Gqvg4SzPFeokBdkrMeGSY=; b=jPF++RCRHe2dXXShxtlAxdbs3Ao7oXbtYqp6l+5MvSAEqNcJG0JFCEcms9tRgWH2jn NrRyaGlIkpj6f53rOPs4EYAp1n9jw0txYfRr5oaWjY64yM/HfhuLAQwESZJUy3bnAGKr ziMAEAApzDzoDG71wuU9nzRQPjrWPwZltk4PIwwNkfx9f50hMQpENh5D1ktRm+hWM0qb C8QMKFch4pGxhPffophh3Ly3svq1MAsQr+/Rna7fKxCeYdJYDVj2TyYU1ZWsy/Ta7VB0 ppf+fpaNzcayMyyCH2p4oAo/mkVENQ0inhW0kAt8mm6qDzRGUVXO5XQNkOi5Yql7oYFB 9u/A== X-Forwarded-Encrypted: i=1; AJvYcCUQerVJz3trpUIhGPjB3EBX65h+r5efPsWhL4PEbtgkPz9iZv9jPojwYT5VXuHyGR9KPo6F3o36qV0=@lists.xenproject.org X-Gm-Message-State: AOJu0YxsAkBn73lRNw9p0ejWj4czsqBAtIfABB7qnC7OpIDmCtouimEu vdFZGcP+jF98IakjIwMjn+0Ky0TIKwAocFXTdx0EqsZMiDFCOiifQdc9M/r6vmT86n1uSLYGxIv Jep+AMT/Jlu8mqOSKvmCiLFdtBbpP4llMNQJ/hXN5uBVt X-Gm-Gg: AY/fxX4n/o+YT1CDv45N7H39iJMyUN/Fh6jd8wyxaEqsGF1LMRxurda/BS7nlfWK9U8 01prKVKQvJmn8OsDRS4u/t+ZyKj+R71xSPqGe1gHn6Lht6d/NwTrDZvR0TSJgHA55aWIPdk3alE WTwi/uM3bqj711v0VcayNb3kmNG/Dy5kDqfcdOP3yHdNLa6UwgsBYvJkMmiXI5vdPfzqaoT6QzX OMaxylUZtAz3B3b8Gqpo7TriBmT1tu+9FR5Qe9/quqPzOA3tn/DH6I96WNsQEx30oBsLukgjI3V v9fryyo= X-Received: by 2002:a17:902:f688:b0:295:745a:8016 with SMTP id d9443c01a7336-2a59bb1803bmr51851575ad.11.1768466975176; Thu, 15 Jan 2026 00:49:35 -0800 (PST) MIME-Version: 1.0 References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> In-Reply-To: From: Anton Markov Date: Thu, 15 Jan 2026 11:49:23 +0300 X-Gm-Features: AZwV_QinbTdDHIwfGNQEJEjm8UqxJn4sKYAYXEFF6g_3XF-xDisXK_ej4TsIzZU Message-ID: Subject: Re: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Jan Beulich , "xen-devel@lists.xenproject.org" , Andrew Cooper Content-Type: multipart/alternative; boundary="000000000000da3af10648694d8f" --000000000000da3af10648694d8f Content-Type: text/plain; charset="UTF-8" Sorry. I mixed several threads into one. It wasn't immediately clear that the second bug isn't related to handling negative values in scale_delta. It's related to gradual time desynchronization between cores, so they should probably be addressed separately. Thanks. --000000000000da3af10648694d8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= span class=3D"gmail-jCAhz gmail-ChMk0b">Sorry.= I m= ixed several threads into one. It wasn't immediately clear tha= t the second bug isn't related to handling negative values in scale_del= ta. It's related to gradual time desynchronization between cor= es, so they should probably be addressed separately.

<= /span>
Thanks.
--000000000000da3af10648694d8f-- From xen-devel-bounces@lists.xenproject.org Thu Jan 15 08:57:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 08:57:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204347.1519039 (Exim 4.92) (envelope-from ) id 1vgJAk-0007Ji-0m; Thu, 15 Jan 2026 08:57:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204347.1519039; Thu, 15 Jan 2026 08:57:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgJAj-0007Jb-T8; Thu, 15 Jan 2026 08:57:41 +0000 Received: by outflank-mailman (input) for mailman id 1204347; Thu, 15 Jan 2026 08:57: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 1vgJ3c-000403-15 for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 08:50:20 +0000 Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [2a00:1450:4864:20::441]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 37a27cb4-f1ef-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 09:50:18 +0100 (CET) Received: by mail-wr1-x441.google.com with SMTP id ffacd0b85a97d-42fb4eeb482so356336f8f.0 for ; Thu, 15 Jan 2026 00:50:18 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af65363dsm4629743f8f.13.2026.01.15.00.50.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 00:50:17 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 37a27cb4-f1ef-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768467018; x=1769071818; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=BA1cwIy+rA5vpcOl7abVGxW1SXxqAKXIBu7i3jjTacg=; b=ab5MibXRyCACmbgRfToYHtGKxrjFhgjhGByNG3KWoLZ2WO8zh1qIBtUzmJMdw0izpX T7YbX9kLziJZvHKVCrLAplOgvNp9GyIYBvdRGoL1eIBdsXCSKVA4bxlDpy0MK03YqC7v kMmdK7g6zXNFCnVhJH7a5NAeFMNx4EELIwqNQHIJSpgazUbrxSMyntG89Nq+EWMlmIRj +7bzQd10oV+RCpHDB5+67vgB8g+c4c2QIFCnnONNAzNjV7ZvpIRMdftHEnMbFKXRzr+W DOYTEm3kKDAnxxlfrr01g9qccc2k2fTab5lw9mTe3EMSP+EVsmESuYECoEG2q2UmyiXp j1sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768467018; x=1769071818; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=BA1cwIy+rA5vpcOl7abVGxW1SXxqAKXIBu7i3jjTacg=; b=QlFCINDdnwHlVub2j+NDyF/yx3LouL0P8U7WMqaDm++lKZx654YnvHZl2QsjDHYkfY u62D6DbqivYRRTp8ccrCtKip9wegpA6uTEf7jS23i3N4odZy0gxvc0b8+eHii6XrMkGx huKrNud/OL7Jvej2UgfWyQnzuVbyEIIRs5On7xe9ymbM/PdbLCDgZilHkQNBLvGMU8uH zcfjjaPsDrGiV67SjxmzQGafYT9nWs92jpD8XQjktFgJtZfilrIa784EohjnrXitBFmN iXuNFCC9oJJ/aZLGQt8SRzvlI1pslRbh7uMx/LtFIKi2VPvd39WPju8/ltJx3G23gmrj 5/bA== X-Gm-Message-State: AOJu0YyxiozV2W7aBvhqvS6YFdGhXFtg0EYOH8J+XkZGWPTbz/IOKP8B c1c+6dKdD+NGR/GLXAkvCFEzfS0awRDroBqnHexcA9EwigrC3AmN6JhT1T/Uh4JwaQ== X-Gm-Gg: AY/fxX5OMj0elobTl/VnmJT3g3SyaoEP+c7YZLiIm/pBdesqChGYs1Jf1LZbkcFjHhL 4++a16Ut75p4zmPzo5Yx0srBrXDlFDIzrR5nUvlCYTp1qjn7Z9kKP6dpQidg067OljlnvpRNFn7 9Oos2aSnyoZlEQto0Xm0Xx43y3Ta8vazYiSWAkLc7S7PAdnrgCHdYy5LS6vBnkxvid9fChSNxET RkCqU9NpaMBXcMDht4qfu0EQAX8Rk8gj1UVOyUwJ3wjM1ydaK0DsvFI2JHeHaK0oQ5N1K+tMq81 883yDak5OjEh/8RfqedqOGFnMlA8JMm8hYLWqtPC02VQ/2Y9vmytHD2MlHt6ZDyAHaEqbgkvQRo ZuYGmciYLJ5KAI1LepCccXIQapCIZHqVxdZzp2c9Ut+SYzAiiTbIiNYDor7slCJVKY5m+kHMeZz T7cgDK6nuwCbRtzWY4UjgdR6yxhwdt+BoLC/oCd44hcQ7deI4xHQ+6U2Qfud8e3emrhbByr3Xzx lIkSPjJauappQ== X-Received: by 2002:a05:6000:238a:b0:430:ff81:2965 with SMTP id ffacd0b85a97d-4342c55e401mr6465371f8f.49.1768467017703; Thu, 15 Jan 2026 00:50:17 -0800 (PST) Message-ID: <99412152-015a-4056-8f85-c2c74cf1076c@suse.com> Date: Thu, 15 Jan 2026 09:50:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 1/5] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu To: Stefano Stabellini , Oleksii Moisieiev Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Volodymyr Babchuk , Grygorii Strashko References: <837eab835a75e7f668c5a49074991b2fcba56156.1768415200.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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 15.01.2026 01:15, Stefano Stabellini wrote: > On Wed, 14 Jan 2026, Oleksii Moisieiev wrote: >> @@ -827,7 +830,37 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) >> case XEN_DOMCTL_test_assign_device: >> case XEN_DOMCTL_deassign_device: >> case XEN_DOMCTL_get_device_group: >> + if ( IS_ENABLED(CONFIG_ARM) ) > > I skipped the last round of review so if this is addressing a comment > from Jan I am OK with this as is. > > However, I would check directly on CONFIG_ARM_SCI. +1 Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 09:02:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 09:02:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204361.1519049 (Exim 4.92) (envelope-from ) id 1vgJEv-0000Yk-Fo; Thu, 15 Jan 2026 09:02:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204361.1519049; Thu, 15 Jan 2026 09:02: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 1vgJEv-0000Yd-Cq; Thu, 15 Jan 2026 09:02:01 +0000 Received: by outflank-mailman (input) for mailman id 1204361; Thu, 15 Jan 2026 09:02:00 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgJEu-0000YX-8Q for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 09:02:00 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vgJEm-004jDg-0a; Thu, 15 Jan 2026 09:01: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 1vgJEl-004KR1-1L; Thu, 15 Jan 2026 09: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" 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=GGMrPRFB+xHLzHgb8fqcJuD0KTFzCPZv4Y+fcJ5KC+A=; b= GlkDmHWZ7m+QsQbWjbF7AUUXt0YYgSGtJVpQd4l4MOw+1vy+h1WJmmKLpA0l/AZXa3E9jtxwWPoQ9 rbPsK4mmfgiDRZrLw4tBHDVQRJScY3Q0H8K7f02nz9ENeWbEON4P3zpEshOLgudSTsquZSU+sK/eP q1cICu1dHGzaf+WK8=; From: dmukhin@xen.org Date: Thu, 15 Jan 2026 01:01:50 -0800 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 1/4] tests: fixup domid make fragment Message-ID: References: <20260111041145.553673-1-dmukhin@ford.com> <20260111041145.553673-2-dmukhin@ford.com> <2badbc33-f78c-47d9-acef-9383a5aa3387@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2badbc33-f78c-47d9-acef-9383a5aa3387@suse.com> On Mon, Jan 12, 2026 at 12:16:46PM +0100, Jan Beulich wrote: > On 11.01.2026 05:11, dmukhin@xen.org wrote: > > From: Denis Mukhin > > > > There can be multiple test harnesses per one test target (e.g. harness.h > > and harness2.h). Account for that by further parametrizing existing > > emit-harness-nested-rule(). > > Multiple harnesses within a single dir imo likely would share headers, but > use different .c files. Also, why would dependencies on headers need > recording at all? The Makefile includes $(DEPS_INCLUDE), so all dependency > concerns should be covered (or else the generic machinery would need > fixing). Imo all of this wants simplifying (dropping?) rather than further > complicating. Whoops, I forgot to drop that multi-harness stuff. Thanks! > > Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 09:04:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 09:04:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204371.1519058 (Exim 4.92) (envelope-from ) id 1vgJGx-00016O-Ql; Thu, 15 Jan 2026 09:04:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204371.1519058; Thu, 15 Jan 2026 09: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 1vgJGx-00016H-Nh; Thu, 15 Jan 2026 09:04:07 +0000 Received: by outflank-mailman (input) for mailman id 1204371; Thu, 15 Jan 2026 09:04: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 1vgJGw-00015s-C1 for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 09:04:06 +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 212f1c92-f1f1-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 10:04:00 +0100 (CET) Received: from SJ0PR03CA0178.namprd03.prod.outlook.com (2603:10b6:a03:338::33) by MW4PR12MB7440.namprd12.prod.outlook.com (2603:10b6:303:223::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Thu, 15 Jan 2026 09:03:55 +0000 Received: from SJ5PEPF000001D5.namprd05.prod.outlook.com (2603:10b6:a03:338:cafe::8) by SJ0PR03CA0178.outlook.office365.com (2603:10b6:a03:338::33) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.4 via Frontend Transport; Thu, 15 Jan 2026 09:03:48 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ5PEPF000001D5.mail.protection.outlook.com (10.167.242.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Thu, 15 Jan 2026 09:03:55 +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; Thu, 15 Jan 2026 03:03:54 -0600 Received: from satlexmb08.amd.com (10.181.42.217) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 15 Jan 2026 03:03:53 -0600 Received: from [10.252.147.171] (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, 15 Jan 2026 03:03:51 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 212f1c92-f1f1-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Pxgr3UzMIsDlNFnPopSxSLlGFSzdagTL0p0kx9TwEyzF16YO5pmA/jrZyXqeZluGoUzE/1r/DXZb8IVNbhVMOjXEDd58EJXxG8+VhLtOx+1XHW/YVdzUYj/w11Kw9iOUSH/2fcfG6eiaqvTYDngo1/aauyi/vPOwGFv7Hc2GVeZ0U7LdHEu8HPYyEjK1dRg7XRBcsgjODBLn0KurisZmQ+BNrDJlHNi+RScQz58IXgTQjQONhWgubk01psMioEp6Gi7mhUCMjAckb5NzeHCF5fjAq7u/G+aphPGkm/V3o2grog4+5+JWEAgJ5YdA3i71gikdusb9ubWcMcYEEUOw3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GfW0N6H2ly5YeUdCPE3Iat57aZinNMZDcEEsXST2ynQ=; b=AQPM/mtlin7nY8ovXL8rRbmfU4tqBavUyJxK1/fWc6GYCjPn2Z/BA742VFrUPok7uEvflvJEB/E8soEyeYDDmpMD1V5XUWBdwCs/oLzNVOD8T2shnqcr5AAgSy1Gdx/bMnSAGvjDMCZps/R2KjcwbLSUoNBOE9yaG6ZbzV8UHyYeGxB+D5r5N0/VNLWR/u7fONYaFO/W320pwDPA9ce/3nfldcu++Ua3gtC+R8QDx1pVcd+72aTtyTLeVxWgcJYt2wu7bjvZSApaw1/0QIHvE3s6k+qX1hZe1zmalK7mOUVBPkhzr7V9Mtq8Ec7Kl4DLyfVvd4oGn2XGwaSNFkYw2A== 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=GfW0N6H2ly5YeUdCPE3Iat57aZinNMZDcEEsXST2ynQ=; b=civOcESdx/MjIVZcfDrmiwvRor0FbiM1ugnU6VtevsZXiH9poHkcfydj2Cf8LRRUoTOG1BKMISsmvrmTQfKxyRGkKYttkxR9TGmLOMPEcwuRBMiz90S+iGCpqgkqUgPawlzyQhVIMQphc6bvAluvtx7926Bb/TTRA6/vE5jGUNM= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <806731b5-6c56-4274-98f1-120530cfe398@amd.com> Date: Thu, 15 Jan 2026 10:03:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v16 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests To: Mykola Kvach , CC: Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: From: "Orzel, Michal" Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001D5:EE_|MW4PR12MB7440:EE_ X-MS-Office365-Filtering-Correlation-Id: c2a74f9e-082f-4525-6b3d-08de541502d9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|7416014|376014|36860700013; X-Microsoft-Antispam-Message-Info: =?utf-8?B?ejJDcHA2bmQrMVZVQ0ptSXBWaTRNNzVzUEx0eEYrSUt6eXp0UmcrbEtwT3o1?= =?utf-8?B?UHVEa1RMUURGUjh5by9jMDBodmZWTHhySy9tbTZpMmRNeStjb1NHNVBjVlEz?= =?utf-8?B?b2lrZElIYnpzOWN2cGk0YU5BNE9oaVFXTWNCUFd1ODlFQXB6OFRtZ1R3TCtv?= =?utf-8?B?ekVvUnRHY2xZbythVnNNUkVZdXAxRHRMNWgzS2dhTmdyeXlhSWFGT0h3UWZq?= =?utf-8?B?SWJjYVJhSmZsWlIvbGtvUDhrN0wzS1dobnlOOWhMdDZlSTVmbXl5cDl2dVpS?= =?utf-8?B?NTE5cGR4VmpwUDJsOFh2alE0YTNnTFJrNElwN1FVR0t2bjljM0h2TGY0OGdP?= =?utf-8?B?YjNtQXFoNkRLL0I5cC8rQ0lYU0JxOEVQVFRhNVhkVmtsM1F6Rm8zdm80d3px?= =?utf-8?B?N3hUSm1WM2Q3UGM2WGpLNjlDdVVsbFNRV1JVSm1LZG1CVjk3cHd4dDFUWEpK?= =?utf-8?B?QVBwa2w5Zk1UMkdlNXdzSDQxSGQ0M3pIUXpnWDJtcC9sN3lGUHNIR2FQdHZG?= =?utf-8?B?QlV1enFqa0w3TEJ4Mm5jWFFOUFdHbzd6eUtSbUE4dVRacUVLRG5IVWpOZDQ4?= =?utf-8?B?NGxlQ0pxcmVhTENsNGhQS3FDeVM0NnFUVktiVlRmeWRCWERya2dvZ1QzSWNy?= =?utf-8?B?TGdZbURZdkxOK3hhM0Q0VTZFeS9yTEU4RDJyQmNpSlhxMGdIYmQrVkdBcEZR?= =?utf-8?B?UEtDcFNKV0xLT1pHQ0VRa1ppa2tlY2FlZ2dOV3R1TE9wNjduMURlNm5qQlJm?= =?utf-8?B?Y1cxdTVBNTJFRWtrSTFlRmdaMGZncUh4eXZCcHVSb2ZKM1NwM1BVVkVZZ2U0?= =?utf-8?B?WXNDRTdteWpXODhZYndEdlBCcEllNFVFZlM3Wi93dEc1NHZEUzN0YzNDNlAz?= =?utf-8?B?VCthd3JCRjdnOGk3MnJKY01OSGdIYnJrRU1XSVZ5bGRMWVFZMUtVdGtHMnl0?= =?utf-8?B?TkIya1pkQWlPY0txU1FsWHVYMEZCbkZDNjQwaktxdC9IWlpLRFVhdTNpazlQ?= =?utf-8?B?OXNzVDBqcFBPcU02T3BzMWkyeWEyc3lHclUySjZ1K1FFVnlwbS9tWHRHb2dF?= =?utf-8?B?bW5tSkdnd0lNem1tbnIyNVlyNnBMY1lOeEtUak9Lb2c4Y2Q5NE5FaGNJMWtK?= =?utf-8?B?cVd3KzIvbytCZ1JvWDZxUWhyRzFvRXZDWks2VmJOdzVaVERpZExBWDZUZSt6?= =?utf-8?B?NjZWdzZVK0VQU1NiRVF0VlIxOUV2L3NUdTVpNGxxQ1g4Nmx1VFJxci85LzVs?= =?utf-8?B?bUZ6OGZEbFRYekIxTWRzb3dxUXErZWwvN01Keno2dHpCOHVXM1pVTUFiVEtF?= =?utf-8?B?VTlCYVFkSERtQmM0UU1oTFg5V3FLOHZnYk4zcTVENEV3dWN0MHNENHBuTzQz?= =?utf-8?B?Z3VHcWpHc2JLb1JMQ3BzWTUyTjBQMWJXWWdPSnBoS3U4TVZEdUdpZFNtemM2?= =?utf-8?B?NUE3NUtXbi80a2JJVkt0Y2drdzYvTmJNMHYxczQyUFF4b3hZV2gvS0R2YmZz?= =?utf-8?B?c3RWenErRkJYUXUwN05Ibm5ydTdQVTI1S1BaVWd6SUlON0s1cmFnc3F6aE8y?= =?utf-8?B?Qi92ZWYwQkZZaWdvOXMweDJUZy8vQy9zbHNodlhYWENSdlNTK0tubDhTM3E4?= =?utf-8?B?LzdlZXVVUk4vc0kvd05INUU4eCs4cVdWWlNrcmdEamZoT0hudCtoTE8xbGln?= =?utf-8?B?aEpibmtKcXNqYlUzVm1MVVU3MERyTEpBeWxEQjhPYi81SGxsUVRuN2dtR3Qy?= =?utf-8?B?TUNYbGJGenFCUHgzOWRyMXVhRkhNU0piNHRIZHdENnArRVF2YzhEb3lWZWZz?= =?utf-8?B?RU1BVU9wK2p5VVJ3dkd3WXZMcWwyMHJwblNHbTd4MExxT3hNRkErNXMyQTZR?= =?utf-8?B?NXZOQjgxdkRNdmdvSVBRRG5kWTBIQWcrZ1FKK05TcFNUVlk3bnVMZ3RwMWVa?= =?utf-8?B?T3dBYk9XNzlaeGNjay8yTUNVS1M2Y2NLa3hnajRBUHlvYXdKb203Mi9aRTI3?= =?utf-8?B?eGo0M0xiMVhZUGZIbVVYZzNrMDlaQ2JHYTcvWEY0V0xtTGcybUVrME5mNG9U?= =?utf-8?B?UHVUYkF6dXNKbU43Z2N4cW5iL3djZ0hWS3J5Qy9JT0lpbFJCZFhvTWNhYWRw?= =?utf-8?B?djFKcXNiOXNqMFd0aGVQVkxObnZDdjlTYkNiKzhnMFZmcExYanE5R1RqZXdi?= =?utf-8?B?RDdJdTRkQUgzTXlkY2U0RllINWdxYndCS2NRU0Vha3NBUG1FR09ocWxCMHhU?= =?utf-8?B?d3NhQk9RQk4xbDBDcUlkckdLSUtBPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(7416014)(376014)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 09:03:55.0685 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c2a74f9e-082f-4525-6b3d-08de541502d9 X-MS-Exchange-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: SJ5PEPF000001D5.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7440 On 12/12/2025 14:18, Mykola Kvach wrote: > 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. arch_domain_resume() stays int to propagate > errno-style detail into common logging; preserving the integer keeps the > reason visible and leaves room for future arch-specific failures or richer > handling. > > 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 > --- > Changes in V16: > - Refactor error handling in domain_resume: move logging to generic code, > use explicit return code checking. > - Make context clearing conditional on success in arch_domain_resume. > - The 'int' return type is retained for arch_domain_resume for consistency > with other arch hooks and to allow for specific negative error codes. > --- > xen/arch/arm/domain.c | 39 +++++++++ > xen/arch/arm/include/asm/domain.h | 2 + > xen/arch/arm/include/asm/perfc_defn.h | 1 + > xen/arch/arm/include/asm/psci.h | 2 + > xen/arch/arm/include/asm/suspend.h | 27 ++++++ > xen/arch/arm/include/asm/vpsci.h | 5 +- > xen/arch/arm/vpsci.c | 116 +++++++++++++++++++++----- > xen/common/domain.c | 10 +++ > xen/include/xen/suspend.h | 25 ++++++ > 9 files changed, 205 insertions(+), 22 deletions(-) > create mode 100644 xen/arch/arm/include/asm/suspend.h > create mode 100644 xen/include/xen/suspend.h > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > index 47973f99d9..f903e7d4f0 100644 > --- a/xen/arch/arm/domain.c > +++ b/xen/arch/arm/domain.c > @@ -12,6 +12,8 @@ > #include > #include > > +#include > + > #include > #include > #include > @@ -24,10 +26,12 @@ > #include > #include > #include > +#include > #include > #include > #include > #include > +#include > #include > > #include "vpci.h" > @@ -851,6 +855,41 @@ void arch_domain_creation_finished(struct domain *d) > p2m_domain_creation_finished(d); > } > > +int arch_domain_resume(struct domain *d) > +{ > + int rc; > + struct resume_info *ctx = &d->arch.resume_ctx; > + > + if ( !d->is_shutting_down || d->shutdown_code != SHUTDOWN_suspend ) How does this check and returning -EINVAL correspond to... > + { > + dprintk(XENLOG_WARNING, > + "%pd: Invalid domain state for resume: is_shutting_down=%u, shutdown_code=%u\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 comment? This patch assumes that we can now resume successfully (i.e. this function returns 0 and common domain_resume can continue) only if the shutdown was with SCHEDOP_shutdown. Anything else will infinitely keep the vCPUS paused. Other than that, the patch looks good. ~Michal From xen-devel-bounces@lists.xenproject.org Thu Jan 15 09:10:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 09:10:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204394.1519068 (Exim 4.92) (envelope-from ) id 1vgJMy-0002tS-EJ; Thu, 15 Jan 2026 09:10:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204394.1519068; Thu, 15 Jan 2026 09: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 1vgJMy-0002tL-BM; Thu, 15 Jan 2026 09:10:20 +0000 Received: by outflank-mailman (input) for mailman id 1204394; Thu, 15 Jan 2026 09:10: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 1vgJMw-0002tF-Gv for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 09:10:18 +0000 Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [2a00:1450:4864:20::443]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 023c4947-f1f2-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 10:10:17 +0100 (CET) Received: by mail-wr1-x443.google.com with SMTP id ffacd0b85a97d-432dc56951eso435706f8f.0 for ; Thu, 15 Jan 2026 01:10:17 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af64a778sm4621712f8f.3.2026.01.15.01.10.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 01:10:14 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 023c4947-f1f2-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768468216; x=1769073016; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=XNiFNKSA8ewzq3AITTPzSNiSva1DLVUpQFCVeULNOW8=; b=egpEiVyq9LqMlY755hMogonncjd0RFHRaTg1LRDXpVxAPV7irH/vuqGp6XeIKduMck fQi1w9n3Ro5zb1CCNU8sxAmcuoKKF6hVpDJhP7iBEZWMkSCXqI5rpK+u/KZf/S2DGPRC 7HAKYnWFnOgo7OF0HKkFujJY3Qrrr154ervYyDdhEqMax4dCVbxpazmAtqePOD1ESxxp Tp9l3B5+gL45TbJrnH1a+P531Ndzxh+CXmxALzNyEgeySKahEr8BfuZ99Tank+vIRW17 fAHccPJVncqUvwd/oxAewWH5c7RUvlkTWbSLQ8I43aQzkB79PQHFefap8PuCoA3pTet3 ratw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768468216; x=1769073016; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=XNiFNKSA8ewzq3AITTPzSNiSva1DLVUpQFCVeULNOW8=; b=LABgNAfVpE/5yLxBnc+ZcFc+9lxqVbxmPw8/cuFNk+NkBxgBGO9Jxg07Id389tr0w2 RoIYZILuHrmgpSoPLWuynUY7zR0ZPhAT+CEHW5MfkiVikUc5aQWrx/WGbE8fF4vHH9VL xEbeKA8ho4q+Vu+Wmu4V4ok+XvtwelJlPo888xGIXTz5/yBY1ukdsWStfcMUPN7uwjQ1 SdVqWdA//X6Up27f2uKxL0I4Pxy18EMZ+gw/8VOdCSpIvSL36/l8i+0Glxg73sRVKC87 vxuOlhuilnxyXhwvjtb5Hp0i+3tvmF3+H8d1qeQiSvV49Mj0+qo8Ue4Z1BGfDNF0uVk/ 1HLg== X-Forwarded-Encrypted: i=1; AJvYcCVkVipWa/cgfxQBJtLxhY4Vf+9t43b+nDFjS09ez2Dsd9b8ItAcGal+F8JRYQ0sUgiV0QfZnIbadQ4=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzy+wnUe8St2ZxJ6UdNVERq2htl9xDHRrPYeoMjkeuyexr3sUCC aLkaIlFuFfm14E85TCJZsLlb82zxypsGuLTtteZtNAE69aJx1axP6HX5CdtCqW33pw== X-Gm-Gg: AY/fxX4TxzwkUbta1huHBefGAYwyElio3HU408EI6XK6zoZt4XODaT54lhLucYGAtr+ XzVfwfsDtfJohvNbc8cee3XI0f6csDmT43WIeVLhWEF1L+Ui4Oaje30ZlokY/s0GohoeV9abg6c BwIkC+H+5HIoelyTz6UJ8Swfvn4uqLG1qhQnqQw4JpZDGrv8/uCMutOREz4jC59eaR8sRB6Z0hs S7Q8nH3ofDyzIYFV83AlDinmsE8D1Ds31PIjkCjmZmBYyC6V8HH7UvJ27+UMxBqEewawxvIuRXl DHQB7jo2Kp9iz+u1aHFVWVyrVJLsy35WLxztbVa6TF2rxSdNLVcv97PRNkdbA9YUBjl51KE2zwT 2a8ayfyHwkQvX7LBlsd/Tz9X8Nzu/e3FJibY1qJ6Cs/CaBhcbB4HfU83893QkOHK70uied9q+dg lGXudWj3GPpdOmK7VKbSZ2Md3Fb8ij8bLPVLN+3HAAcl/EaqGuRPtkRpQdUlnpMqSLz4Ypp66CZ lA= X-Received: by 2002:a05:6000:200d:b0:432:c0e6:cfda with SMTP id ffacd0b85a97d-4342c4ee790mr6053937f8f.7.1768468215033; Thu, 15 Jan 2026 01:10:15 -0800 (PST) Message-ID: <86fe1ba2-2775-441f-9ea2-47de5f0375aa@suse.com> Date: Thu, 15 Jan 2026 10:10:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 1/5] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu To: Oleksii Moisieiev Cc: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" References: <837eab835a75e7f668c5a49074991b2fcba56156.1768415200.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: <837eab835a75e7f668c5a49074991b2fcba56156.1768415200.git.oleksii_moisieiev@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 14.01.2026 19:29, Oleksii Moisieiev wrote: > From: Grygorii Strashko Nit on the patch title: "not only iommu" can mean pretty much anything. Imo SCI should somehow appear in the title. > Add chained handling of assigned DT devices to support access-controller > functionality through SCI framework, so a DT device assign request can be > passed to firmware for processing and enabling VM access to the requested > device (for example, device power management through SCMI). > > The SCI access-controller DT device processing is called before the IOMMU > path. It runs for any DT-described device (protected or not, and even when > the IOMMU is disabled). The IOMMU path remains unchanged for PCI devices; > only the DT path is relaxed to permit non-IOMMU devices. > > This lets xl.cfg:"dtdev" list both IOMMU-protected and non-protected DT > devices: > > dtdev = [ > "/soc/video@e6ef0000", <- IOMMU protected device > "/soc/i2c@e6508000", <- not IOMMU protected device > ] > > The change is done in two parts: > 1) call sci_do_domctl() in do_domctl() before IOMMU processing and propagate > its error if it fails while the IOMMU path succeeds (unhandled cases return > -ENXIO and are ignored); > 2) update iommu_do_dt_domctl() to check for dt_device_is_protected() and > not fail if DT device is not protected by IOMMU. iommu_do_pci_domctl > doesn't need to be updated because iommu_do_domctl first tries > iommu_do_pci_domctl (when CONFIG_HAS_PCI) and falls back to > iommu_do_dt_domctl only if PCI returns -ENODEV. Given how the line above ends early, you likely want to have a paragraph (empty line) past here, to aid the reader? > The new dt_device_is_protected() bypass in iommu_do_dt_domctl only > applies to DT-described devices; SCI parameters are carried via DT nodes. > PCI devices handled by iommu_do_pci_domctl do not carry DT/SCI > metadata in this path, so there is no notion of “SCI parameters on a > non-IOMMU-protected PCI device” for it to interpret or to skip. The > PCI path should continue to report errors if assignment cannot be > performed by the IOMMU layer. It's less clear here, as ... > So we should leave iommu_do_pci_domctl unchanged; the SCI/DT-specific > relaxations belong only in the DT path. ... this still looks to pertain to the earlier paragraph. Perhaps that sentence should start on the earlier line? A more general nit: Please try to be consistent with line wrapping. Don't go past 75 chars, but at the same time use available line length instead of wrapping a sentence early. Also please be consistent with adding () after function names. > @@ -827,7 +830,37 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) > case XEN_DOMCTL_test_assign_device: > case XEN_DOMCTL_deassign_device: > case XEN_DOMCTL_get_device_group: > + if ( IS_ENABLED(CONFIG_ARM) ) > + { > + /* > + * Add chained handling of assigned DT devices to support Why "Add"? The comment should be describing what the code does, not what is being changed by this patch. > + * access-controller functionality through SCI framework, so > + * DT device assign request can be passed to FW for processing and > + * enabling VM access to requested device. > + * The access-controller DT device processing is called before IOMMU > + * processing preserving return code and expected to be executed for > + * any DT device regardless if DT device is protected by IOMMU or > + * not (or IOMMU is disabled). > + */ Is there perhaps one (or more) comma(s) missing here? One after "processing", and maybe another one after "code". Assuming of course I infer correctly what is intended to be said. > + ret1 = sci_do_domctl(op, d, u_domctl); > + if ( ret1 < 0 ) > + return ret1; This leaves ret1 >= 0 for the code further down. Then ... > + } > + else > + ret1 = -ENXIO; > + > ret = iommu_do_domctl(op, d, u_domctl); > + if ( ret < 0 ) > + return ret; > + > + /* > + * If IOMMU processing was successful, check for SCI processing return > + * code and if it was failed then overwrite the return code to propagate > + * SCI failure back to caller. > + */ > + if ( ret1 != -ENXIO ) > + ret = ret1; ..., with ret being 0 when we make it here, what use is this? I don't think we can or should be returning positive values? Nit for the comment: Drop the latter "was". Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 09:14:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 09:14:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204410.1519079 (Exim 4.92) (envelope-from ) id 1vgJQi-0003WK-3K; Thu, 15 Jan 2026 09:14:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204410.1519079; Thu, 15 Jan 2026 09: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 1vgJQh-0003WD-Vi; Thu, 15 Jan 2026 09:14:11 +0000 Received: by outflank-mailman (input) for mailman id 1204410; Thu, 15 Jan 2026 09:14:10 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgJQg-0003W7-KM for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 09:14:10 +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 8a0d1079-f1f2-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 10:14:05 +0100 (CET) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-b8718187eb6so98817966b.2 for ; Thu, 15 Jan 2026 01:14:05 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b86ebfd007fsm1539531366b.31.2026.01.15.01.14.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 01:14:03 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8a0d1079-f1f2-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768468444; x=1769073244; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=ZqUg99QjD548h0aCZ23XVdeCBRhKMsL9njyo8YPDMSw=; b=i4zQKjlxyDgq2aRsY5AoCJf/XnZt/T+n/nbC8v8dZgnwWtk+v6UVdZY31zX/h2K2+s OH2jWzXcGt58thB1vlkwlM2WK6s2BElxfsuomKehDLmTY+b1aIHM9o46Te9AU1CMkT1b +DwCw0gV+KCgboiEu5eSBBVtnFemhiPNiNTsYuItVCuLrZ81ITEyeCf1lGbnGrsgfVBe DOcs01CeG7lza76vHJlUJPLWYEnhkU47DR38IU50vNTUCmSryo4yZcEyKTQkheur93df jFNtZOAR22+aPi+TV8xjSm6hm5SZF9sIpXVefBg0f0g7OUAE7qfO3Qd3b1nWl2CmdHbU 8mAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768468444; x=1769073244; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZqUg99QjD548h0aCZ23XVdeCBRhKMsL9njyo8YPDMSw=; b=reKyLXDE+KVoiOijYqTNHxw3dtqzP6GodsLLn87oBjoz59CYNukxAgJfXLok0zlc7O AGkCpag1EW0gpz0mTy8nEOxWIIcn04gEa+pCKnqI2RQ5XZTffoV5tBLA6pFkDOmOanRG JbNPAZHRgsEUiDmoKeDrJR1ThgsnH/cPj2Qs4cbxDHRkMI44gdF5E1LDuSJLlyJcNFyG 6LDz+0+uqKF1WxkWH97wKSBAE9O8x/rofTcXzIN1+ZLq/8g3J2y0laD7s2i4WHHVkAYk g72ONzu9P35bxOvWjTGBVBkSGoCJXI4qMVUZ+MvGibSb/wxvWKLiGJ18A7hM0Kz/UeZX aj+w== X-Forwarded-Encrypted: i=1; AJvYcCVLY4uHiB7qFkOylURNVqCfqoyH88qdaHoIPA9ZFiIvMY1BaWuUbHR/9UjMe6DGZt7Ot5g5xU/pkE4=@lists.xenproject.org X-Gm-Message-State: AOJu0YzbVb/FdmUb7TfJGRIU0AoyvoXv9AgEOoOl3xrhb9RYu8TQtbed 6aDDhgXQK7WJm2bMXWw0drLNWsc69/fheuhyt8WrAiwm2p+//+1Fjvrd X-Gm-Gg: AY/fxX4FXgrRGIH5xih/El2RKdU5UZ8FSHgZqIKZ+1IsYY1voS9YNxwoofso/NpUAcM A2AE8wRyGfhjU/89pTyDlo/ZCPGQg54sn3LjPI3HoWOxOzHcmyqqvro8m9td5sb95HvataRYy13 r1SCViFwu7vr4dmEcOcOslxRkbTYiSW5p/PAgR3Ff/pXQOQvveoRf9M2U2E6hj9jkJJjQsYVLPG uf+WjGHOZr4vSm9FrQ9lFxCSt8V0of27dyy16Yp+f4rtDUmPx3WdUZVK6Xut/URRBz05EifXQrS 8vVkIxMsu/PzoiK1p0fj/RXGiQwWQeb47af/pwYsynxQIIkuksoiCBVfitjIPr9MuXURNZEuejy IMg3w8iRilFADpLosBLEforBayNaAPXLkh8kXoZWw4X4qi3StEybfI0SlbkzeKpKOtJlC1YYg6W mQnn56YaQJP4TMWUFICAZXvTlBSTiJd7XCeG9DHRWuBxm5I5shOFxOUi7f4fL3bxk= X-Received: by 2002:a17:907:3e26:b0:b87:20eb:a66d with SMTP id a640c23a62f3a-b8761431e0amr382469466b.65.1768468443975; Thu, 15 Jan 2026 01:14:03 -0800 (PST) Message-ID: Date: Thu, 15 Jan 2026 10:14:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Oleksii Kurochko Subject: Re: [PATCH v1 07/15] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <7a90cc1b-b053-4b9f-91f1-d32064b1ec29@gmail.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/14/26 4:56 PM, Jan Beulich wrote: > On 14.01.2026 16:39, Oleksii Kurochko wrote: >> On 1/13/26 2:54 PM, Jan Beulich wrote: >>> On 13.01.2026 13:51, Oleksii Kurochko wrote: >>>> On 1/7/26 5:28 PM, Jan Beulich wrote: >>>>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>>>> --- a/xen/arch/riscv/include/asm/domain.h >>>>>> +++ b/xen/arch/riscv/include/asm/domain.h >>>>>> @@ -85,6 +85,22 @@ struct arch_vcpu >>>>>> register_t vstval; >>>>>> register_t vsatp; >>>>>> register_t vsepc; >>>>>> + >>>>>> + /* >>>>>> + * VCPU interrupts >>>>>> + * >>>>>> + * We have a lockless approach for tracking pending VCPU interrupts >>>>>> + * implemented using atomic bitops. The irqs_pending bitmap represent >>>>>> + * pending interrupts whereas irqs_pending_mask represent bits changed >>>>>> + * in irqs_pending. >>>>> And hence a set immediately followed by an unset is then indistinguishable >>>>> from just an unset (or the other way around). >>>> I think it is distinguishable with the combination of irqs_pending_mask. >>> No. The set mask bit tells you that there was a change. But irqs_pending[] >>> records only the most recent set / clear. >>> >>>>> This may not be a problem, but >>>>> if it isn't, I think this needs explaining. Much like it is unclear why the >>>>> "changed" state needs tracking in the first place. >>>> It is needed to track which bits are changed, irqs_pending only represents >>>> the current state of pending interrupts.CPU might want to react to changes >>>> rather than the absolute state. >>>> >>>> Example: >>>> - If CPU 0 sets an interrupt, CPU 1 needs to notice “something changed” >>>> to inject it into the VCPU. >>>> - If CPU 0 sets and then clears the bit before CPU 1 reads it, >>>> irqs_pending alone shows 0, the transition is lost. >>> The fact there was any number of transitions is recorded in _mask[], yes, >>> but "the transition" was still lost if we consider the "set" in your >>> example in isolation. And it's not quite clear to me what's interesting >>> about a 0 -> 0 transition. (On x86, such a lost 0 -> 1 transition, i.e. >>> one followed directly by a 1 -> 0 one, would result in a "spurious >>> interrupt": There would be an indication that there was a lost interrupt >>> without there being a way to know which one it was.) >> IIUC, in this reply you are talking about when the contents written to the >> irq_pending and irqs_pending_mask bitmaps are flushed to the hardware >> registers. >> >> Originally, I understood your question to be about the case where >> vcpu_set_interrupt() is called and then vcpu_unset_interrupt() is called. > I was actually asking in more abstract terms. And I was assuming there > would be pretty direct ways for the guest to have vcpu_{,un}set_interrupt() > invoked. Looks like ... > >> I am trying to understand whether such a scenario is possible. >> >> Let’s take the vtimer as an example. vcpu_set_interrupt(t->v, IRQ_VS_TIMER) >> is not called again until vcpu_unset_interrupt(t->v, IRQ_VS_TIMER) and >> set_timer() are called in vtimer_set_timer(). >> >> The opposite situation is not possible: it cannot happen that >> vcpu_set_interrupt(t->v, IRQ_VS_TIMER) is called and then immediately >> vcpu_unset_interrupt(t->v, IRQ_VS_TIMER) is called, because >> vcpu_unset_interrupt() and set_timer() are only invoked when the guest >> has handled the timer interrupt and requested a new one. >> >> So if no interrupt flush is happening, the vcpu_set_interrupt() → >> vcpu_unset_interrupt() sequence will only update the irq_pending and >> irqs_pending_mask bitmaps, without touching the hardware registers, >> so no spurious interrupt will occur. And if an interrupt flush does >> happen, it is not possible to have a 1 -> 0 transition due to the call >> sequence I mentioned in the last two paragraphs above. > ... that wasn't a correct assumption. (Partly attributed to the patch > series leaving out a number of relevant things, which makes it hard to > guess what else is left out.) Then it makes sense to introduce second part of pending interrupts tracking as part of this patch series in the next version. Or for now not introduce tracking of pending vCPU interrupts and implement vtimer expired handler as: csr_set(CSR_HVIP, IRQ_VS_TIMER); vcpu->hvip = csr_read(CSR_HVIP); >>>> By maintaining irqs_pending_mask, you can detect “this bit changed >>>> recently,” even if the final state is 0. >>>> >>>> Also, having irqs_pending_mask allows to flush interrupts without lock: >>>> if ( ACCESS_ONCE(v->arch.irqs_pending_mask[0]) ) >>>> { >>>> mask = xchg(&v->arch.irqs_pending_mask[0], 0UL); >>>> val = ACCESS_ONCE(v->arch.irqs_pending[0]) & mask; >>>> >>>> *hvip &= ~mask; >>>> *hvip |= val; >>>> } >>>> Without it I assume that we should have spinlcok around access to irqs_pending. >>> Ah yes, this would indeed be a benefit. Just that it's not quite clear to >>> me: >>> >>> *hvip |= xchg(&v->arch.irqs_pending[0], 0UL); >>> >>> wouldn't require a lock either >> Because vCPU's hvip (which is stored on the stack) can't be changed concurrently >> and it's almost the one place in the code where vCPU->hvip is changed. Another >> place it is save_csrs() during context switch but it can't be called in parallel >> with the vcpu_sync_interrupts() (look below). >> >>> . What may be confusing me is that you put >>> things as if it was normal to see 1 -> 0 transitions from (virtual) >>> hardware, when I (with my x86 background) would expect 1 -> 0 transitions >>> to only occur due to software actions (End Of Interrupt), unless - see >>> above - something malfunctioned and an interrupt was lost. That (the 1 -> >>> 0 transitions) could be (guest) writes to SVIP, for example. >>> >>> Talking of which - do you really mean HVIP in the code you provided, not >>> VSVIP? So far I my understanding was that HVIP would be recording the >>> interrupts the hypervisor itself has pending (and needs to service). >> HVIP is correct to use here, HVIP is used to indicate virtual interrupts >> intended for VS-mode. And I think you confused HVIP with the HIP register >> which supplements the standard supervisor-level SIP register to indicate >> pending virtual supervisor (VS-level) interrupts and hypervisor-specific >> interrupts. >> >> If a guest will do "That (the 1 -> 0 transitions) could be (guest) writes >> to SVIP, for example." then the correspondent HVIP (and HIP as usually >> they are aliasis of HVIP) bits will be updated. And that is why we need >> vcpu_sync_interrupts() I've mentioned in one of replies and sync VSSIP: >> +void vcpu_sync_interrupts(struct vcpu *v) >> +{ >> + unsigned long hvip; >> + >> + /* Read current HVIP and VSIE CSRs */ >> + v->arch.vsie = csr_read(CSR_VSIE); >> + >> + /* Sync-up HVIP.VSSIP bit changes does by Guest */ >> + hvip = csr_read(CSR_HVIP); >> + if ( (v->arch.hvip ^ hvip) & BIT(IRQ_VS_SOFT, UL) ) >> + { >> + if ( hvip & BIT(IRQ_VS_SOFT, UL) ) >> + { >> + if ( !test_and_set_bit(IRQ_VS_SOFT, >> + &v->arch.irqs_pending_mask) ) >> + set_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); >> + } >> + else >> + { >> + if ( !test_and_set_bit(IRQ_VS_SOFT, >> + &v->arch.irqs_pending_mask) ) >> + clear_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); >> + } >> + } > I fear I don't understand this at all. Why would the guest having set a > pending bit not result in the IRQ to be marked pending? Maybe it is wrong assumption but based on the spec: Bits sip.SSIP and sie.SSIE are the interrupt-pending and interrupt-enable bits for supervisor-level software interrupts. If implemented, SSIP is writable in sip and may also be set to 1 by a platform-specific interrupt controller. and: Interprocessor interrupts are sent to other harts by implementation-specific means, which will ultimately cause the SSIP bit to be set in the recipient hart’s sip register. Meaning that sending an IPI to self by writing 1 to sip.SSIP is well-defined. The same should be true of vsip.SSIP while in VS mode. And so in this case if SSIP handling was delegated by hypervisor to guest by setting hedeleg[2] = 1 we won't have an interrupt in hypervsor, and so nothing will set a pending bit in bitmap or update hvip register from hypervisor. ( All bits except SSIP in the sip register are read-only. ) > You can't know > whether that guest write happened before or after you last touched > .irqs_pending{,mask}[]? Yes, I think you are right. On the other hand, if we are in hypervisor when vcpu_sync_interrupts() is called it means that pCPU on which vCPU is ran and for which vcpu_sync_interrupts() is called now executes some hypervisor things, so guest won't able to update VSIP.SSIP for this pCPU. So nothing else will change VSIP.SSIP and so h/w HVIP won't be changed by something and it is okay to sync .irqs_pending{,mask} with what h/w in its HVIP. ~ Oleksii > Yet that pair of bit arrays is supposed to be > tracking the most recent update (according to how I understood earlier > explanations of yours). > > As an aside - the !test_and_set_bit() can be pulled out, to the outermost > if(). From xen-devel-bounces@lists.xenproject.org Thu Jan 15 09:19:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 09:19:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204424.1519088 (Exim 4.92) (envelope-from ) id 1vgJVo-0004LJ-JR; Thu, 15 Jan 2026 09:19:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204424.1519088; Thu, 15 Jan 2026 09: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 1vgJVo-0004LC-Gn; Thu, 15 Jan 2026 09:19:28 +0000 Received: by outflank-mailman (input) for mailman id 1204424; Thu, 15 Jan 2026 09: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 1vgJVn-0004L6-1o for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 09:19:27 +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 47eb45ea-f1f3-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 10:19:24 +0100 (CET) Received: from SA9PR13CA0171.namprd13.prod.outlook.com (2603:10b6:806:28::26) by SJ2PR12MB7799.namprd12.prod.outlook.com (2603:10b6:a03:4d3::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.6; Thu, 15 Jan 2026 09:19:20 +0000 Received: from SA2PEPF00003AE7.namprd02.prod.outlook.com (2603:10b6:806:28:cafe::e2) by SA9PR13CA0171.outlook.office365.com (2603:10b6:806:28::26) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.3 via Frontend Transport; Thu, 15 Jan 2026 09:19:18 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by SA2PEPF00003AE7.mail.protection.outlook.com (10.167.248.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Thu, 15 Jan 2026 09:19:19 +0000 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.2562.17; Thu, 15 Jan 2026 03:19:18 -0600 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; Thu, 15 Jan 2026 03:19:18 -0600 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; Thu, 15 Jan 2026 01:19:17 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 47eb45ea-f1f3-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TSJQGkIQsP+0Y9LCeT1w7e0M1rrTXt8YWip6b0WIDIAoUa5sAF+s7HUlfVpCHLPgLbmkf5RBHMTuAonPnV1A8w3WNRYNVM8wDlaSI+5gRdQ+CRdIW0tusFHw/wXjHWTxfjt2g93PEkr6ORK6FanLr5og49PpIGFu3P+zUiR45KeiEpuWqZxc3UvcSpo0lwhquFnpa4ShyA+bWSyc+61ngR7Zd1ApF0jCjOMwi0S6v9k7eIOG4uya0jYM+QMAEJMPcl97BGb8p1KUqcz00to8x57T8KVd/usoIYfINvJqVQz3Cf7X7pSWbOCZLVxMPJS9ED5dnr7PMLF3nt3tJe7K0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iH1wPPQQd26x/9jv9dNBM+QsAcaIMKkHjiCJ5AWGuPk=; b=G6N6UZdREwy4bc9N9KDwR8UfB2a45ZK80FfJNdAZuili4FdgfylJ/tH3glXknBudr+998VeyxRO0vSjPUATZl/1aKX3HbYZDWZou7L6eY18V9TJQhcltr2vUkAvzL2XNg+1lO4+nYYFMdY2k8BASvjqZNAsJVGLAOkPXm+e7hfeUn8Oh/uHfZMeuGo+JjzVgDOEQMQC2XiJQh7i18Z/6w6PRAZqzOMvQNe9ljAefpt/tBFtuLOVJ//w+pMSaKULIJAvSnPj17dEMcFbNFbCJ6rLxvh6E3v33/4k0vO0KjKGitf9pw3vJiMPHkvWXchyEd/OoLx7UhunCwHTLBiMVpA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iH1wPPQQd26x/9jv9dNBM+QsAcaIMKkHjiCJ5AWGuPk=; b=C1f7WFoDKHcSCfs8b0mvWoeKES6fr3YlrugDmH3k/yVY+szUZ/33X3M3B48ePFk4wPXGsh+WFCX2gpVjp1ssrqarm4IHPnoHv0zEJDOgQAfUooB776+rvCfdx05lPhn0L+PnnO8p54B9oWCSeROLUc/AVt+C6kvP/aCZJt2r4UE= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <9e811c32-0786-49fa-b54b-18c33104632d@amd.com> Date: Thu, 15 Jan 2026 10:19:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/6] arm/mpu: Implement vmap functions for MPU To: Harry Ramsey , CC: , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk References: <20260114142734.239197-1-harry.ramsey@arm.com> <20260114142734.239197-3-harry.ramsey@arm.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20260114142734.239197-3-harry.ramsey@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB04.amd.com: michal.orzel@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA2PEPF00003AE7:EE_|SJ2PR12MB7799:EE_ X-MS-Office365-Filtering-Correlation-Id: c9183a1b-3d19-4711-9aa4-08de541729ef X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700013|376014|82310400026|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?Q3BsN3g5RzY0Nm1BYWxib212aExOdWVpdmtwbmhXWFBGbTMycTAvODBJQ2Fh?= =?utf-8?B?ck4rZ2N0cFRMcXV4dnhQYnR1UTIwTEVBa3krcmNRQXFVMmhDdmIzV2ZxcUdz?= =?utf-8?B?ZnZaLzBXTGdjaW96ZlpIRlcxVHFvb2Vla2xDOTNvN0MyZEpCYjZLKzVJZnF3?= =?utf-8?B?emZPUHFuSVFlM0oxUUxiV2dralF2ZGVpQ201cUdyWUxzSXFnUGx1ak9TNk05?= =?utf-8?B?Qi9rWlBudGE2RTVoVzdVcGVoM2phS0JmQWVWS1ROT2FtcXhTbkNqak90TXZs?= =?utf-8?B?ZXRiOXVQVmxLWGlNeG9nQWpUdmQ3a3cvNDFET0JtYVFGa1REYmdqWVJIVzJ0?= =?utf-8?B?R1ZQWFNCL1FZNXRZL2lSZmJLRVNQbENWS2JueGZOWWt3ZEk2dnN2QVEyOEMx?= =?utf-8?B?eTh1bzUyYkQ2WDJuTGczank1RC95amRyeU53K3lYSlNXN0lDRllsNzkxelJy?= =?utf-8?B?WXB5a2tRQXozSG1DMjF1enFaMTVvS01aZUM5K29tOGNYNWxJR1ZPYkRjWVNh?= =?utf-8?B?aSs2TzZtZG0wb3cvQnRodTZhNjZlYnVvUVJOVnU2ZzlaR0RpYUJFRHVaYXE3?= =?utf-8?B?bU9oV2FoR2VjN1dqTzJPcW41YUxhQjBNb25NYU5rQU9mZFB5RC9ROStTdFQv?= =?utf-8?B?d3liZ3hCeWFSTjBpaVM0OXgzb0I4dERUeTRMNFV1VnVaaFVPb0FKaFU4Z2Nn?= =?utf-8?B?Y2Y4NG1VL29rbmo2d0IrQ2dIMno0clN5N0lzUmpmTEQ3QXFWeWVESG1mU2NK?= =?utf-8?B?c1E5YnFqWjdXVEM4KzI5ZnJDWUlsbEdlTjBZMXZNRjd4WUhleXBadFlmV0p5?= =?utf-8?B?UkNHb2NiSVBKVFRqZ3EwSlVTTGo3ZDFGYTBUWHJlblZKdjRsNmdFWDRMRmxj?= =?utf-8?B?WWVHNHhXRHQ2UWRVQ3JhZUY2RFpHc09RWUphdGpIVmN0UXFFS1BvVWY3L2JG?= =?utf-8?B?R0R6MjgzMkY2ZlJ5cE5ESlhOYW5hQ2FIUURoRnVxeWk4cXQvYU9mWTJ2VnJn?= =?utf-8?B?L1pZZ2w3ZFBTNUJrZmV5KzErY2NVNVpncnpHR2ZENmViVmpacXF6cDYzTUJF?= =?utf-8?B?d1RxZ1JSaFVrMVpreDJZbytPRG5ZZ0g1d05pMFlwQTB3VGJ4RlNwYzQrYzFx?= =?utf-8?B?d3ozQlhlUkh3OWJMZHN4ZTE2eDVrb25teUdJaWFOcWk2OWtqTVVCOWVnQlR5?= =?utf-8?B?Smc3dVRLRVg0Mmc4T09YOEZSMllXZnhqSDh2RWtpa2RhMURkMXBkK0JuL3RX?= =?utf-8?B?MzFsUUxDMGtoelc3V21jRHBZRmZjZGpsbVJHYytDRnR1elhrSzBhcGhGQlNQ?= =?utf-8?B?RUhhRCtibURvNVlsSmJ3SHNrclZqTGZTcWRuUDVhczBMZ1BEYzVYZXNjdFlp?= =?utf-8?B?Q0p5ZCtPTlJjZW9ETFhwMUNxeXNPcHl5QXoyVGt4L3kxVmc0bDNmS0hITytH?= =?utf-8?B?dzRpazh0TytqcS9zSFE3VnVZeEdRMzdtMFJwV2syUlo2Sit2K0REYmh2MUt3?= =?utf-8?B?RWZiMVhtczdkRmRlT2NWNWVvVGNrY0FEUGxNbXQwMDZTWDRqVU9aTmFvRkE3?= =?utf-8?B?WjlJOHNzWUtUMCtRSU9iUTdib3FnMG8yck9Zci9vQWdzY0ZOZUI5WmxuU2gz?= =?utf-8?B?TERnU3p3bHZpY095WTlseDlNK09BNUxnaCtxTVhnTmY0Z1M5YlFNWXFvVFpJ?= =?utf-8?B?OU5jK3kwbFdvbDlNMU53NEpzSysxUWgva0lvbldxRXRtRFlYd2tuV28yOHFI?= =?utf-8?B?MXQrSW9nckpoUXErSGxnSk9mOXR4SlhvcDQ2alA4UjBBZUVZR2YvUC9rOEYv?= =?utf-8?B?Q2ordlNwNFY1c2YxVXRPYzR5MDVEUElHc0dHNzRzQi9vMXd3dy8yWnp5S3Jh?= =?utf-8?B?c3JYNFh0ampZbXZTZnpPT04xbEI1eldqcXpjQVk2ZEdlMWgwdVVIR0Z2b290?= =?utf-8?B?VEFuRTB5RC9maUwvMGN1eUJla2F4Yk94V0xOUStvYjlDcXJ3QXVpcU5DeWR6?= =?utf-8?B?cVQ0M2h0Q1VHcC9GWVpBSlF1ckh4d3dQV1d1K1JaSUgyZkVIQkRXL1VyNVYx?= =?utf-8?B?aTVWY09DTFNscnE4aTNKUDl3a2JpakVZVXE3MTNhU0M5UHl6eTJldGhzMVo4?= =?utf-8?B?azVKenRaWklCT3FIaHhleXFCSGRVSS9mODJ1OFRRVTljcVVFdmw1NDI0cmdy?= =?utf-8?B?SHlwRE0xZUxCUUkza1VBakVBNS8xSzAzVGVvMEJkbEo4Ly9sZTQzUzFFWDF2?= =?utf-8?B?U2tUTEYwYVNURFdVYkx3cnVWTVlnPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 09:19:19.7085 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c9183a1b-3d19-4711-9aa4-08de541729ef X-MS-Exchange-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: SA2PEPF00003AE7.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB7799 On 14/01/2026 15:27, Harry Ramsey wrote: > From: Luca Fancellu > > HAS_VMAP is not enabled on MPU systems, but the vmap functions are used > in places across common code. In order to keep the existing code and > maintain correct functionality, implement the `vmap_contig` and `vunmap` > functions for MPU systems. > > Introduce a helper function `destroy_xen_mapping_containing` to aid with > unmapping an entire region when only the start address is known. > > Signed-off-by: Luca Fancellu > Signed-off-by: Harry Ramsey Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Thu Jan 15 09:21:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 09:21:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204445.1519098 (Exim 4.92) (envelope-from ) id 1vgJXY-0005oR-Ua; Thu, 15 Jan 2026 09:21:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204445.1519098; Thu, 15 Jan 2026 09:21: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 1vgJXY-0005oK-RQ; Thu, 15 Jan 2026 09:21:16 +0000 Received: by outflank-mailman (input) for mailman id 1204445; Thu, 15 Jan 2026 09:21:15 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgJXX-0005n3-As for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 09:21:15 +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 883e2efb-f1f3-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 10:21:12 +0100 (CET) Received: from BY3PR05CA0054.namprd05.prod.outlook.com (2603:10b6:a03:39b::29) by SA1PR12MB8966.namprd12.prod.outlook.com (2603:10b6:806:385::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Thu, 15 Jan 2026 09:21:06 +0000 Received: from SJ5PEPF000001D5.namprd05.prod.outlook.com (2603:10b6:a03:39b:cafe::9e) by BY3PR05CA0054.outlook.office365.com (2603:10b6:a03:39b::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.2 via Frontend Transport; Thu, 15 Jan 2026 09:21:06 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ5PEPF000001D5.mail.protection.outlook.com (10.167.242.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Thu, 15 Jan 2026 09:21:05 +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; Thu, 15 Jan 2026 03:21:05 -0600 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 15 Jan 2026 01:21:05 -0800 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; Thu, 15 Jan 2026 01:21:03 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 883e2efb-f1f3-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=amq7dK9pBvq/KUPbFzURMfwG04OEuxCQJHgqZxkQxCGW9a7WakwHJcTFOIg2R6sOtSRN9h6M0R4BohJR8l0MXhuElm5Um8eBmgtrUpFuRlhs/YPXvHpYASb3k6pWolexd+XmMAglGDgz5T4W3WNcUTxh0uVMXhxfQ8fmdnGhabNiJ5LE66hpB6kXtj55OZfdjUlPhf+o/0Geu7QKCi76U3eYOqrE04TFRGTL/QtcM5JxrpQGZRF+HXp+bFAilTQ2EnBbqsJK+uHomCtACrzxs3OD+puKv0A51Dycsn51kFx6rlU2KpLZq4yonmCP7OUC9gs9G+X5YuKEAngcJhnung== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VKkNSgMzWHcJZYy4NMjFwvu9jND2h6b0owm5FGSZ6cw=; b=hx0munzyp9rigZLnW8g0qC3N07Oh5DEtSTiNtZfcOohYOwMwLCKiNyK9743zlpFVDbhqJPgV9oyYRSACmXAdizEJ2UeI/PlI5bTvnb7FZtb8aWLpkZy1bDtW/Mu5+4jJURlLw0qnLyAKiS+UrkAmrcL9ZgkkdDaQQXh8pCX7hi1kp+JUPHli/H6wWLy31f45w6CLT2VTgwlaIDlfX1ULGkYwNRXrrWUSbc+3Cq8goFOGheoAjFPqJqYBn6bRXh3/lVI2i2dKeZbG/0wuQCiuTAR/WNs8WLQV4UyruyHxYaToa9SCya73sL5wT5j40XufFZK033n8AXv0SLk+6e6e8g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VKkNSgMzWHcJZYy4NMjFwvu9jND2h6b0owm5FGSZ6cw=; b=vs4/TgjhZPSwpGJR3+Ep54WfyUwBo3lauEFPbmEfFqW8G4qcl7AaKezIfe+aQTB/d0KnOKzfXRn2/FDNzld7UkrMYZiUGxBcPJNzfx1wUX/GzbAIRt3K+rR3EcpQEV7RpA69zgMmu6Wmn2ECf3qV/vteZFn1YsxYSquYxdJ9rE8= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <26fe13ea-c613-4d39-8f77-a363805e8872@amd.com> Date: Thu, 15 Jan 2026 10:21:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 6/6] arm/mpu: Map domain page in AArch64 MPU systems To: Luca Fancellu , "Halder, Ayan Kumar" CC: Harry Ramsey , "xen-devel@lists.xenproject.org" , Penny Zheng , "Stefano Stabellini" , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Wei Chen References: <20260114142734.239197-1-harry.ramsey@arm.com> <20260114142734.239197-7-harry.ramsey@arm.com> <4EEAE5C4-59C7-4FA2-9B90-764C754420E1@arm.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <4EEAE5C4-59C7-4FA2-9B90-764C754420E1@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001D5:EE_|SA1PR12MB8966:EE_ X-MS-Office365-Filtering-Correlation-Id: 5a1a1c0b-b59e-48ce-75b7-08de54176953 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?allXUytpZVNtK3lrcUttYkVKMS8waG1vbE5RY3A2b2dHV1A2Rk1icUhSeVp4?= =?utf-8?B?YUMzT0JnK1ZaU3RiYklDQUtKb0thelBIeUtld0gwSmdlM3IyYnVRczIxR2NX?= =?utf-8?B?UGc2UXVxaVg5NytodmZaelU5RkIzdG9nUVppWDVValNtWWZvaEpjakxOUFdn?= =?utf-8?B?UjROOEQxSWxwRkFaeGxhOERyTjZMREJEaUw4L2NhTFhYbmsxaVI3dXppZ0xY?= =?utf-8?B?ejlobi9HOXBrWG9PTDN5S3BlY2lHMWRBM0hlQjBUalN4ZzlYaS9iMHpRaU10?= =?utf-8?B?RjJEOUZTZGNhbUJMK1ByOEN3c2ZHNXAycmhEMVZvTDFSSVpoVnp2QmxRS255?= =?utf-8?B?N3hJclBuWXFhcU9CWWRNNXVuUFJOVVJtZUdwZHZQYk02MjBZY05saXZhWWNo?= =?utf-8?B?SUExblBDOTdHaGxiR0FKSnVLVzVoT0h0NkpzUkhETzdQNFdobDZERG93UG1z?= =?utf-8?B?UVJNUHhGNlRiN1ZtWlIxcnFYUGZsSCtHS0ZBNkxVaHAyN1pDTFBjcmNjZG81?= =?utf-8?B?eStmWmlpajNzTmxkRUpwU3p2MGoyU3NtWEJmbEkvS3kzVGR0b0czU0Ziamtu?= =?utf-8?B?OUwzV3FmQU0rOFVRb2ttaDVab1JVa25jS1k4aXZNVG1rNmpxRk14NWFvNUJh?= =?utf-8?B?UWdqY1F4Y1lTSEdvRC81M2VCcU9razFVSFBoVGd4QmMzV1ZmNyt5TGd1YWZZ?= =?utf-8?B?eVFuU2p6djR0ZFhPdmF4Smg5MWcydjVvRUZoUXJKRlpTT0dGMVhwVFNtVktF?= =?utf-8?B?T2Vja2JrMlNuekNldFFVb2xqQ01IU0dyT1F3WEtvT3FVaDdKTnU5Rm1GdEJo?= =?utf-8?B?azFHYUhCdEViazVYNDY2ZnBhVEViN3dmRTVsT1lLZDJQM3RGejh4NmYyRmpC?= =?utf-8?B?YjJ4VDNweGVaWkVPalZ1VVVORmxJT09NcGx4ZDhHZDBhWHZlMi85MWFEQ1A1?= =?utf-8?B?R2wyTWE0NCs3ZG43MzJabHZrNFFDdVJuM1Z2RTlCSjlxWURPN0ZCa3JENTlC?= =?utf-8?B?UUJnOEhiek4ySmxBUjlxUkVtVkRScWp4SjVRTE4yNUROUVUwTHBESnliMWp5?= =?utf-8?B?MUNqTVlFeUVKdGpnRmxuYjE1Q2hwMmdrSXdwQ0cwT2lhcXhGNzdIcU5RQWtL?= =?utf-8?B?d0I2bEErZUl1MEdxQjdvSG1qUkF0Mzgza3hqSDVRVXF5Z3NwRXdPOUlObDVs?= =?utf-8?B?alBOcS9KMEt0SkI1enBFQWdIK2RYam1kazhSZUVlZys5MHlNdmtVNXhNVFRT?= =?utf-8?B?bWptSW9TOXBRdlEvUGpUZWVPZWtVVk44UStnK2RDWXVWd2x1WWVzMzl5K2Ri?= =?utf-8?B?KzY0S1krQ2dQZFFOYWNpN2xta2tNNnVRYTNTNjMyN2dzY0xHWlAwQnM1Qkl1?= =?utf-8?B?dTJvbTVBa3lrRjZ4SjhvM0dmZ25paEY1bTVTQ0tNb0lxeWxsY3pTQlkyZUVt?= =?utf-8?B?aEppYVorcm9WZzRRaUs4aytvUW1ucjZtK2RoMngwbGFjcTBkVUtkaDBLdWRE?= =?utf-8?B?cWUxMUxsRCtLNHA4ZWVPMDZRV2M3ajVGT0lvSFlQZ0U5LzdNVTQ0ZkFXZTZo?= =?utf-8?B?SGxtSTZXTkhHTUJwNytyRUoxcG9QTmtScEV5NnE0TGVqZC8yZDB5bm41Z1ht?= =?utf-8?B?L3U2Wlk2cGFLdTBFUDhYNkJqaWg0Nnlic2trMHV2RlYvazd2cTZKazAxelBU?= =?utf-8?B?dkRoWlM0ZjVIUnhaNkNhTmw0ZE5qbnk2MkozZW5zaUhQdzA5dXhUZWxURkly?= =?utf-8?B?cEtrRnNXMTJOUmM0QTFuUVJFY3lkZXc2K1hiY3gwUSt4M2dXS0FqRmxyRytp?= =?utf-8?B?aklTYjNCQVRLQ3hKQ0VsWERGSG5KSHJNOUxMRmNxcDBZOTU5THJLVzdPTnpn?= =?utf-8?B?dDJPSnVWSlVJa0c2S3hNcnFHK3ljNmx1V213OThtcGpWeXpFeDF5WERDQUNp?= =?utf-8?B?MkpNL3dZQzJrb2NOQXIxYnZiL2dEYUVMdE9tL0ZNMkVQVkZXN3NGYVhPQzZU?= =?utf-8?B?akUrUEp5cVAxMHVJbDZURktxbXUyNm1jSzNacUpCVHdTc0l4aE1OTHpLSklW?= =?utf-8?B?eVpKQ0pTVUcySXZRN0E3SURiUFkra2k1Qk5lbndiMzkwaXlxZ3pMUytxb3Bq?= =?utf-8?B?Nkg4TVE4SW1Qd3NIdlpOWlQ0bTZ2bFgvUGdBUkxyNlkya2VhRDM0akNVTXhZ?= =?utf-8?B?cTh4ZVlhVjh0eFZjS20yTGlXM1ZTRUVoZ0Vwb3ROcjdvRzhOSERFalBQRHlW?= =?utf-8?B?LzVzUUtvTUkvRGVOSGRCdmJDNzNRPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(36860700013)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 09:21:05.9911 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5a1a1c0b-b59e-48ce-75b7-08de54176953 X-MS-Exchange-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: SJ5PEPF000001D5.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8966 On 14/01/2026 16:59, Luca Fancellu wrote: > > >> On 14 Jan 2026, at 15:55, Halder, Ayan Kumar wrote: >> >> Hi Harry, >> >> Can we expand this to cover Arm32 as well ? I did some test and both Arm32 and Arm64 get to the same point. > > The only problem is that we don’t have an Arm32 setup to test these, if the maintainer are ok we can do it, > but then it should be you to test on arm32. > > Also, in case, could it be done while committing? (provided that the maintainer give their ack) I can do that later on when committing. Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Thu Jan 15 09:26:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 09:26:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204461.1519109 (Exim 4.92) (envelope-from ) id 1vgJcN-0006Rf-IC; Thu, 15 Jan 2026 09:26:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204461.1519109; Thu, 15 Jan 2026 09:26: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 1vgJcN-0006RY-Ff; Thu, 15 Jan 2026 09:26:15 +0000 Received: by outflank-mailman (input) for mailman id 1204461; Thu, 15 Jan 2026 09:26: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 1vgJcL-0006RS-SM for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 09:26:13 +0000 Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [2a00:1450:4864:20::442]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3aee1811-f1f4-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 10:26:11 +0100 (CET) Received: by mail-wr1-x442.google.com with SMTP id ffacd0b85a97d-42fb0fc5aa4so523436f8f.1 for ; Thu, 15 Jan 2026 01:26:11 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af653576sm4880524f8f.17.2026.01.15.01.26.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 01:26:10 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3aee1811-f1f4-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768469171; x=1769073971; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=cVX8I+QMYPBxGP8lOvP8ShcblrEkJtFKFsIG5peRypo=; b=Zod8JCgoIsfJhahsWkVNPOaSLcZBN1JrjTwiHkCNC0L4CyvF2grK0fSiTGdp1A+fOe BZOB1ah8mPhpEe68yrdnc0ID/ml39X3+4RbfW7+HbzZ61Lx5I/HNv80kJUhd9rUIqMtY /N2FdvISamXnW3be+XpvL9U//hkacKyNq1pTpEQGm5IjxF35beNNwQlrRecc09CU0WqA ZrPfvO2yBb6/7ZwxI/afDP9K+yjpZAjrAFOrX/w8PlUj/RZIHqOYB52uSuotpZEcRxxZ 1iD7OGXz3Wb59Iyq4nO+lrvbXwMPJuIjXV5O4RSOnc+d90cdQyLL9lpCdhyn37WYbaDZ fVqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768469171; x=1769073971; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=cVX8I+QMYPBxGP8lOvP8ShcblrEkJtFKFsIG5peRypo=; b=UX1vQf9qrSjIhoPViYWtwd10hhv39gdVFGyfnMif/gjxlV1od1TlcVOABBdn7LgFoM FKaATX+ge9go7hxhuAks29Jv7y9YPeiIkWRJGpH1WjKwUo48IwV7h0DqBHhAnMkChLMi kydewV3QHyv93KGdeIE70gZ5WutrzklVSXbpZ7yceWcSU+9j6JwHrIKzwRYNFoY2XdvY GFr3/ULoBdJef7fSKFnz857nQdETQjWV8x8W8BRIMYAZEOPOfnvxn3bZRQ4HIouxNtCL /aYNokszWftuAWWNhPx2jIMQLxgEwoX4D9xMYPcJbn10GtU8lp8MoT9CMWyQiZiU8EMf cPyQ== X-Forwarded-Encrypted: i=1; AJvYcCVxb122wJhUM1FYaAbmVJlT5I82WqDf/nYdvQTnxULzE7hlcLIY/tbAfivvcUSXViU9gHWroGlooO8=@lists.xenproject.org X-Gm-Message-State: AOJu0YzNELoIHE22etMUl82pykudXlUIyMnNYM/psAA9Bi2yM7KDBihX lWt+ZV8L+ycenyvksu1l5g5ZHuGdiSdB0W8qn2d5JjEtvD1lCpdu1FHs1k1VU13jPg== X-Gm-Gg: AY/fxX45wvKZTwpfbxSuZNeroW6dmE+2K4jTLiuS9aA3msrxhjmW0QE3NfucJEHtcj4 dOuwSZpWezBAFL6A8rO6sHIQj/kxqIf1gbDtrHlABGrwm5mpJ33G4HrNYE2X/fx0fylIPMaigr3 oX3MQbBZBb5t60Mt9P8PQXrK9IkxnBgdJklg3ieCEXAUh5E/NuSAYgGE+wJ7VWBxxbkUwj9beOT sokzJOY7RXVKjcJSl75xo60OviklRA0AgQBQrSprfUzOUtpGRKf+Rb9ua0rWcb6/wHarLK51J0J Wzd+pZaFDxpbJmv8QsE0Ay66gWpIwlUZ8eOGVBWYLHHfWiEPdt6I3K0OqOiRBE48JEmHI+LlgCA U4f4XgnnUmmMKoMSmHQuZiA9uncNMHFD8gm09Jba5lWf1I3mRqOEXRcv7q02sW4PC4tjsMuEYyL nCMkbVmJQY+7fOGt20CPXAOWeFpQK4W84Ea/gDMGz9anGkVsDaQ2CB7PXmp2cduAxtmg6W+x4Gr K8= X-Received: by 2002:a5d:5f44:0:b0:432:84f9:9803 with SMTP id ffacd0b85a97d-4342c3f1586mr6476803f8f.3.1768469170681; Thu, 15 Jan 2026 01:26:10 -0800 (PST) Message-ID: Date: Thu, 15 Jan 2026 10:26:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 3/5] lib/arm: Add I/O memory copy helpers To: Oleksii Moisieiev Cc: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "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 14.01.2026 19:29, Oleksii Moisieiev wrote: > --- /dev/null > +++ b/xen/lib/arm/Makefile > @@ -0,0 +1 @@ > +obj-y += memcpy_fromio.o memcpy_toio.o lib-y please (requiring a change in Arm's arch.mk as well), and each file on its own line. Plus if this is to be Arm-only (see below), it really means to live in xen/arch/arm/lib/ - see how xen/lib/x86/ is about to go away: https://lists.xen.org/archives/html/xen-devel/2026-01/msg00138.html. > --- /dev/null > +++ b/xen/lib/arm/memcpy_fromio.c > @@ -0,0 +1,48 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#include > +#include > + > +/* > + * Use 32-bit raw IO operations for portability across ARM32/ARM64 where > + * 64-bit accessors may not be atomic and some devices only support 32-bit > + * aligned accesses. > + */ > + > +void memcpy_fromio(void *to, const volatile void __iomem *from, > + size_t count) > +{ > + while ( count && (!IS_ALIGNED((unsigned long)from, 4) || > + !IS_ALIGNED((unsigned long)to, 4)) ) Nit: Xen style indentation (no hard tabs) please throughout. > + { > + *(uint8_t *)to = __raw_readb(from); > + from++; > + to++; > + count--; > + } > + > + while ( count >= 4 ) > + { > + *(uint32_t *)to = __raw_readl(from); > + from += 4; > + to += 4; > + count -= 4; > + } > + > + while ( count ) > + { > + *(uint8_t *)to = __raw_readb(from); > + from++; > + to++; > + count--; > + } > +} Barrier requirements on Arm aren't quite clear to me here: Is it really correct to use __raw_read{b,w,l}() here, rather than read{b,w,l}()? If it was, wouldn't a barrier then be needed at the end of the function? And then, if it was read{b,w,l}() that is to be used here, what about all of this would then still be Arm-specific? Hmm, I guess the IS_ALIGNED() on "to" is, but that's Arm32-specific, with Arm64 not needing it? Plus then it's again not exactly Arm-specific, but specific to all architectures where misaligned accesses may fault. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 09:29:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 09:29:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204474.1519124 (Exim 4.92) (envelope-from ) id 1vgJfE-0007Mz-9Y; Thu, 15 Jan 2026 09:29:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204474.1519124; Thu, 15 Jan 2026 09:29:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgJfE-0007MH-3D; Thu, 15 Jan 2026 09:29:12 +0000 Received: by outflank-mailman (input) for mailman id 1204474; Thu, 15 Jan 2026 09:29: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 1vgJfD-0007JZ-0t for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 09:29:11 +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 a573d807-f1f4-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 10:29:10 +0100 (CET) Received: from DM6PR02CA0129.namprd02.prod.outlook.com (2603:10b6:5:1b4::31) by MN0PR12MB5713.namprd12.prod.outlook.com (2603:10b6:208:370::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Thu, 15 Jan 2026 09:29:05 +0000 Received: from DS3PEPF000099DC.namprd04.prod.outlook.com (2603:10b6:5:1b4:cafe::d6) by DM6PR02CA0129.outlook.office365.com (2603:10b6:5:1b4::31) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.6 via Frontend Transport; Thu, 15 Jan 2026 09:29:02 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by DS3PEPF000099DC.mail.protection.outlook.com (10.167.17.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Thu, 15 Jan 2026 09:29:04 +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, 15 Jan 2026 03:29:02 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a573d807-f1f4-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=A/VYPWQQqXTj+MQs9iE5XVgq5sStcxOgYO7AyB864rnceOZeICLWOxCfZYlx8yMtzIgW9jyjgTfepqUxjok+7WKWF/QFaiCDhWTLxHKDY5kVWqxJ0A5+248KbvwnZbxq+ao00Pu0dxcb8IMg7t3bDij65/+OXxrX7pnVZoCJYbCh3ehJFjSGQzFvXH5Gy2B8QJueMJywYW3FOqo73k4bPT1tAydyPqrZyyp1jUJxiwjO/gAxnddb6ICsiXXyzA+PW5LRAJO7s98S5nnbkzl4KTrwkSGiE3qBQ3z4aCh2Pgf/2S1jYgOJzj3URU9GEGzHTCsgQU/IUhOAPVzUAwbyaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vrxm4Ssb4DNyh7hnIccW9NVrE+CVSNJj7c6CdihhrWg=; b=BLEuXsOrG2XRuUe9UcJlkUCFRD9OI4KSeG8y4SJ0modUXtZreF/AChWodFUnyi2VVrQ6KSG1daH8W/TObFvKg6+cjaAO5Dmz2BJa2DWfxXOX8HDRKPy2yvkthPjVnQsIxqAdTTsO07eFSbi3PvZ/7xNDL+XRnmvN6U0C+8cEC7dTnIXW1wzBZ+fWAyzkH9Jl4otbDn9vzwnxiiMBMqDXw+ejeKVdb2DmgBk75QlSF7zgeOzldmPFowWGg6giB6AuzShS2ewUFnm5R5ASRaE+8DFlisD5Ndc1k0+C+EJYfzFi1i3SrlHK+TkKgNlkYW31qRtl95RD0jVzBJH/etPOsA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vrxm4Ssb4DNyh7hnIccW9NVrE+CVSNJj7c6CdihhrWg=; b=4XlQnKyGI5cL+Sretnc21lqAdnOKoPd7rgu6ISUCD8bJNbFSAYQC0NZw0k2jvZejuNipd697RFC89luEWg9Xrg2fMQIsaUx42lLI91jI0evp9kXBBecJPLwKi9XEdqbtWiCTENn8T8B+NZu2IrScRYKjqZtXUUgfjb8HFJoExys= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 v4 1/6] xen/x86: move declaration from mem_access.h to altp2m.h Date: Thu, 15 Jan 2026 17:28:36 +0800 Message-ID: <20260115092841.2651224-2-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260115092841.2651224-1-Penny.Zheng@amd.com> References: <20260115092841.2651224-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: 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: DS3PEPF000099DC:EE_|MN0PR12MB5713:EE_ X-MS-Office365-Filtering-Correlation-Id: 17b824c0-9c38-4f12-948f-08de5418869f 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?NoVPenieFXp3FJykhzA9UtvkCoOkczR70Y4EtyYslrrN7GzgNnm//fp0N1CT?= =?us-ascii?Q?2ixttBYgKDDLVuA1xS7EqmiIoopeBsnr1zP7JHL1KxtOpMvEqWCcRJ/ulELB?= =?us-ascii?Q?Wk2t73U/LoNrpC6E0iIiEaHxaUDcFCtCAkYIi4rj/jticoxv8LYTu1drtzh1?= =?us-ascii?Q?49zevOoD3DvNmvomt7w9MbMWd3C2GJ52TPWGvLWhhznAD2u+2u5CdE7FvGl+?= =?us-ascii?Q?2nN9Wk7BPIubl5zPIWh43ckE+oWaYmD1Jy0ubUgcE+wqglImcZH5gf8GOgaO?= =?us-ascii?Q?JH6Kp5IzLcm7vEc9MOpE89nUS/y/aumMe9YZPAyF4ckqIyLOs6sBgP7yGpFn?= =?us-ascii?Q?+MAqNGnaNMH0k6t6erx0jg034PLGUZTIdIwHMb3yhfLZzlyetLSRV8O7/Av9?= =?us-ascii?Q?AZU06zbmgiKWoR9NZRDbTnHbOGeh6dULOR300aAHiHsPm8Bym6/eaqJVekDR?= =?us-ascii?Q?mH7uFzJ8epUdbDyoVP9fGFTIzCcB9b1x3WQ3NO+X02SZNvsn0cFt78xiUdwQ?= =?us-ascii?Q?Z+R71LlfhlFSrXeYoZ0eyoJCJtbLz1RtwAn+il4Ye32HOZsKs+fcirjRW3Dw?= =?us-ascii?Q?grWVxHfpULGuFNADre3JjCd3LEZcZ+ZcCyZrXlWhpwUMM6lk4rfyQhSZO55a?= =?us-ascii?Q?Kq1f3QrU61JNGLwGpj9EKweijM7YP/MGv92LENNAQUN3QZSJ3mV/lMmg82z6?= =?us-ascii?Q?ZRCxQxCtPw47ESFn75XWjW86mDRnvLjNNg5HdNBIt5uKqaaEWdsEYvTVb9ON?= =?us-ascii?Q?19TekgMvRiGwKMoeidgoVWGW4OlGCZ4U0AIPZ2M9g16MUhMvrrTKa5LqmgDF?= =?us-ascii?Q?wJqMjcbi5fwtz4PP4DwtS1F+ma77Vze29iHvYrHElOob/f6QGG4FXknFEoPf?= =?us-ascii?Q?MNgro65kp8LH7GoN6ls06gAKGPxkSTpa5XZJJv1QCqltXlAC9tG6wuhhN5dq?= =?us-ascii?Q?Ub+9TybjvkOY2GO09Dasdg4wK4gNq1NOwmXpM37sr5txLK4uQJk5JcJaDz5r?= =?us-ascii?Q?fo+oEYcKvDowQOqoaDOEB3Zt1zb6M+jUiJa+8JQsNRX0irHYEngqV+tMmaVl?= =?us-ascii?Q?SjkndqXwD1pSx95Deo3V73A3IwrQc/lKvUOXG2aO7n9FgeYqdAqw3QL5sgwr?= =?us-ascii?Q?uuqutOR20nV9DzVV/DzwluzgtU9tph34HZ3FCMZYQNt7tBkZ7qRQfTT9sv3c?= =?us-ascii?Q?ZaV48oUY3sg+L2SfGIn67JxKSc6wqWSuaAd5TXI48p8TX7baxrlcSxnu95/P?= =?us-ascii?Q?uvTizE8AJw+RW9tNNuD/D4Vm2k7+V7Xme/wAt4T6gKS9/kKPUs5Uw11S8Ghf?= =?us-ascii?Q?G3CPZgsv6TrerjsO4X/HCKuB3PpKdLFirZGwNKwenR+gy4HJphbjuWttAZb/?= =?us-ascii?Q?n6Er7fGjwsfVSppCh4TaRZZwcqLKaskZOppwGSXrzHyccav95noYnR8FFagA?= =?us-ascii?Q?Ud96BjQ6CLuEk96Y5BXWvjyJGD4YMxGBZ8hnvzotgWAlfWNqbTdLlltv3NI9?= =?us-ascii?Q?303NvQiOdVyP/wuKVHzJuHEw5CkRW6S3v23PZAD5ucLSuk/1rgMqRVvkyNDg?= =?us-ascii?Q?RD0kBb2djlIJlnxc3RmAMcjLeZFvmzXrmP4Yun9Tdw/rKedl4Rx1OHRxM9yF?= =?us-ascii?Q?Hs4VZx70WmgSwKUKvVjflo+wuRYcpJM8bxvugTLcmIDprxyWrguVbilv229J?= =?us-ascii?Q?lTR3iQ=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 09:29:04.7311 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 17b824c0-9c38-4f12-948f-08de5418869f X-MS-Exchange-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: DS3PEPF000099DC.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5713 Memory access and ALTP2M are two seperate features, and each could be controlled via VM_EVENT or ALTP2M. In order to avoid implicit declaration when ALTP2M=y and VM_EVENT=n on compiling hvm.o/altp2m.o, we move declaration of the following functions from to : - p2m_set_suppress_ve - p2m_set_suppress_ve_multi - p2m_get_suppress_ve Potential error on altp2m.c also breaks Misra Rule 8.4. Signed-off-by: Penny Zheng Reviewed-by: Jan Beulich Reviewed-by: Jason Andryuk --- xen/arch/x86/include/asm/altp2m.h | 10 ++++++++++ xen/arch/x86/include/asm/mem_access.h | 10 ---------- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/xen/arch/x86/include/asm/altp2m.h b/xen/arch/x86/include/asm/altp2m.h index 8ecd74f363..9c1ac3cc26 100644 --- a/xen/arch/x86/include/asm/altp2m.h +++ b/xen/arch/x86/include/asm/altp2m.h @@ -46,6 +46,16 @@ void altp2m_vcpu_destroy(struct vcpu *v); int altp2m_vcpu_enable_ve(struct vcpu *v, gfn_t gfn); void altp2m_vcpu_disable_ve(struct vcpu *v); +int p2m_set_suppress_ve(struct domain *d, gfn_t gfn, bool suppress_ve, + unsigned int altp2m_idx); + +struct xen_hvm_altp2m_suppress_ve_multi; +int p2m_set_suppress_ve_multi(struct domain *d, + struct xen_hvm_altp2m_suppress_ve_multi *sve); + +int p2m_get_suppress_ve(struct domain *d, gfn_t gfn, bool *suppress_ve, + unsigned int altp2m_idx); + #else static inline bool altp2m_is_eptp_valid(const struct domain *d, diff --git a/xen/arch/x86/include/asm/mem_access.h b/xen/arch/x86/include/asm/mem_access.h index 1a52a10322..257ed33de1 100644 --- a/xen/arch/x86/include/asm/mem_access.h +++ b/xen/arch/x86/include/asm/mem_access.h @@ -34,16 +34,6 @@ bool p2m_mem_access_emulate_check(struct vcpu *v, /* Sanity check for mem_access hardware support */ bool p2m_mem_access_sanity_check(const struct domain *d); -int p2m_set_suppress_ve(struct domain *d, gfn_t gfn, bool suppress_ve, - unsigned int altp2m_idx); - -struct xen_hvm_altp2m_suppress_ve_multi; -int p2m_set_suppress_ve_multi(struct domain *d, - struct xen_hvm_altp2m_suppress_ve_multi *sve); - -int p2m_get_suppress_ve(struct domain *d, gfn_t gfn, bool *suppress_ve, - unsigned int altp2m_idx); - #endif /*__ASM_X86_MEM_ACCESS_H__ */ /* -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Jan 15 09:29:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 09:29:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204473.1519120 (Exim 4.92) (envelope-from ) id 1vgJfE-0007Jr-0O; Thu, 15 Jan 2026 09:29:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204473.1519120; Thu, 15 Jan 2026 09:29: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 1vgJfD-0007Jk-SW; Thu, 15 Jan 2026 09:29:11 +0000 Received: by outflank-mailman (input) for mailman id 1204473; Thu, 15 Jan 2026 09:29:09 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgJfB-0007JZ-Pg for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 09:29:09 +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 a47e4754-f1f4-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 10:29:08 +0100 (CET) Received: from DS7PR05CA0051.namprd05.prod.outlook.com (2603:10b6:8:2f::12) by DS0PR12MB8200.namprd12.prod.outlook.com (2603:10b6:8:f5::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Thu, 15 Jan 2026 09:29:02 +0000 Received: from DS3PEPF000099DF.namprd04.prod.outlook.com (2603:10b6:8:2f:cafe::e) by DS7PR05CA0051.outlook.office365.com (2603:10b6:8:2f::12) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.4 via Frontend Transport; Thu, 15 Jan 2026 09:29:02 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by DS3PEPF000099DF.mail.protection.outlook.com (10.167.17.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Thu, 15 Jan 2026 09:29:02 +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, 15 Jan 2026 03:28:58 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a47e4754-f1f4-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=I2mGPHk/PGIbaEQG1hW9W0oXW9kXn8/pAM50se01+KJkCeZxMngF/5K5Q5I3Q9TNc4wFrprHPuelrIiHpzNNsuTBZl7iP9Y5C0XP4zTaUX/HjQ6FcMcdccVylldVjq3BDasZusZeqRZxxBMAYbhK475bZU+/ANsH9EB24OGRqTuZuhM5CmviLCyUU1wG89qDHjuyfvTVg2OEUscY5V6jKkk155ZRwJR+2UDPwy9t4RFF1i9Rv/Wv+kFMFp/rvKew3iQOSLQrb/n0gSSKhuGJXVFlEvWpKoSnwMfZTT71m4VaN727gtFUALHEnQ6muzeWOml1qLaixXg2LQ9/VH6HXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1QWX3MEiUvQV4E1tz+nSas99Rto/scgJscwAKJ9D2l4=; b=y6JhlWZdBImBFrTcQF5xXd9KrEniO+0Lh+1u89kJVxajtvCw96+LPclRlkM+K6HD9kKHT1oYaOpE63vvvpMTqbZm6Qlyn1DfzJY3dgRNuDRx933jH+v9aOo0NFFrIeYK2kxFiBFdb0c6NR8WUzxL+inAoBNbwqj97zO0x0Gr9qWmMWSWyzgEUJmES9+onGrdB4jQBr/VffH5RhS5PrgGkcwOXYSZYH3YdWYqoP1fmsQ3h8myoaL7BQrKC4W1MvRqEFJgzuGG8lZ4x6a2zZ693QWb53H4wXbzf3ma3bHLVqLErcHrX2+vHOycbKkOi4LMiO85hs9wuhcsvz+59bvbAg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1QWX3MEiUvQV4E1tz+nSas99Rto/scgJscwAKJ9D2l4=; b=qmPnF5up2Y3fiInij/cu3E3gBxMu+ye9IHOtarDH2UmB3iGGhT9soS0/YBIFvjxA58sp0L1b9bqC5RHvneKIwccI9HBWTd1YTaTuCO0s0KtXXb4RnGj1Tdbvj3RNjnmvnRdnLPi4z6bxvLsA7T+sD6+pkJUc5+6nDU5obBp13tU= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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" , Anthony PERARD , Michal Orzel , "Julien Grall" , Stefano Stabellini Subject: [PATCH v4 0/6] consolidate vm event subsystem Date: Thu, 15 Jan 2026 17:28:35 +0800 Message-ID: <20260115092841.2651224-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: 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: DS3PEPF000099DF:EE_|DS0PR12MB8200:EE_ X-MS-Office365-Filtering-Correlation-Id: c32aee2c-39cb-4d7d-0a01-08de54188530 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|376014|7416014|36860700013|7053199007|13003099007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?IRWRk2+txkiRha3ycrkqriYRhj/5j8NNmQrsxD9rEZxP2s6aDtZn4tlG7o68?= =?us-ascii?Q?TfL5wixxqABGzpfDbJE3vAJb+Og/zZTUD/9ccUszA5LGR+Y8qpwl4cVEPQ74?= =?us-ascii?Q?44mIGz6ADWk5vMDrUy1TFSZslAF06xdVLpO46ZRHKtYNi/oJrSbbTz2umJEL?= =?us-ascii?Q?C+eSjY9Z9JcwfESb8A6HSTwMioBO5vZStT7CAV3v04kDWJz0Du/a+DOciBGg?= =?us-ascii?Q?Q+BTp3z9Tzsi46b3xBOIw90q7WsYsFQN9Hu2q0Lzo94VX7tXt0JO2jXslN35?= =?us-ascii?Q?qEWmL9B2DKcqCVn4cKmHFkcyWLnsRoq96aEMmimvbCUwTPSlinkRHCuopcar?= =?us-ascii?Q?QODUP6FOdRSo6KUA67yjbwYGd8npunHEcGkQFvbaTzSawH5GY+HzmAi5GDEM?= =?us-ascii?Q?h94t1wBaS9NmmLHZaVXElaGd9u7P8Zg3XucYZEq3YdPE/jemGtkEQ2L2lKjY?= =?us-ascii?Q?IoXl9LAtig2XXEJ50r5SYWSPW04Gl9qQiavTEUrq688mOdPZ7EYFivk5ubb/?= =?us-ascii?Q?VuvX4odCvZgUCkgS5ZVngg0+GJ8FP2m+CmKGuCm5FcMIR+KCtY48szKmi5Sa?= =?us-ascii?Q?Uw+6aLO1usGFcJZGi8iubujL8iZ2xevl30PT2DJx7Jd2FEsTWF4kVAxqfyw/?= =?us-ascii?Q?l5JQECZP1icc3893rd9XF1akRF+hzrsWh8Vv/JK4ZCFBNhvRRc3t6Cq3JNbC?= =?us-ascii?Q?41k8YJ5z2KTC1FUO/Bvuhox/3cudVXv/9hqSRbRBGkAdYi27zV8mgdQ9QM39?= =?us-ascii?Q?sRy48S3paJLp8aHCJfLMqLCaV9WbughNklW1gfJA8QF5sES92uWNAKfh84P7?= =?us-ascii?Q?oMDgyn9X1D5PDyPPqqCxA+VHsJXycViRjRNYQoE6GTbrpyiGQAx5oOUKKCsp?= =?us-ascii?Q?0tMAvefkhIgKZUuX7ollpgnJTxGylPugHNLtnKxD42t+nOOBALhAdx2TxH6T?= =?us-ascii?Q?uWcMZmKBpVJzLyswX3SxxDGr3PIk9nUPaORyKmUmwaXrq6jbFQhz/GTepdnr?= =?us-ascii?Q?VsETov9fhJCmFEpIsBQZzbIZaxCXuhyzjlUzW5L7RBwJkIqwolG0FQRh978M?= =?us-ascii?Q?qsHMJFgmGTzueY/e49lS2T7qWAFtDPYVHiIuZxecgbWAnrYjs5PgF2pA/IOU?= =?us-ascii?Q?jDxrTYT6yCBXMTGLLz3oO8C+8XNh+qb8ZI+89qYs/2BBHgVMqW6ltsgnJ1Vt?= =?us-ascii?Q?VH3pHzqMbhDpthu7O0YYG5A+o5WDzvLQmJLMGJ+r9ayGf3gz4YX8hp/Ketbu?= =?us-ascii?Q?C5DyOUe9ADBtlv0goaCkpv3tfaaWFpITATc9te9F38ArS6hoXqs83v0bfTsU?= =?us-ascii?Q?NvxZj8s9TQqjiHZYizo07deEhYjSEgD4Vc6AUj9GCTwiWSy8eScRTjCl77GJ?= =?us-ascii?Q?OSY0tYgjvmEiFoZLT5kzDmCv2QZIn+6Eq8rrycdUnBzZWr4dURycAje7OMmy?= =?us-ascii?Q?GwgaxHk+m7hk11CTgdrq92Xg2Yuk2qOPsorbNje46qvDcZ5Auy0Q74RJ63C6?= =?us-ascii?Q?76MbD8es0XFkUvYiQPp5oYWlRBNvU+bx9T7bdARkL5T8qKho3pkt+ziCh0iw?= =?us-ascii?Q?g4453Z1CXUVnLaiGtnvmZjjFnzXm12CTF4fbI/w4tg75erDQiv/WO3r7kOW+?= =?us-ascii?Q?Lg=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(376014)(7416014)(36860700013)(7053199007)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 09:29:02.2850 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c32aee2c-39cb-4d7d-0a01-08de54188530 X-MS-Exchange-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: DS3PEPF000099DF.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8200 This patch serie originates from "Disable domctl-op via CONFIG_MGMT_HYPERCALLS" [1], and focuses on consolidating vm event subsystem (i.e. VM_EVENT), and its derived features, like memory paging, etc. [1] https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg200843.html --- Happy 2026! Sorry for the late response to this patch serie and the domctl one. v4 is just doing a rebase on the latest staging, and one comment fix. I still need 2 acks for commit "xen/p2m: move xenmem_access_to_p2m_access() to common p2m.c" and "xen/mem_access: wrap memory access when VM_EVENT=n". --- Penny Zheng (6): xen/x86: move declaration from mem_access.h to altp2m.h x86/vm_event: introduce vm_event_is_enabled() x86/monitor: wrap monitor_op under CONFIG_VM_EVENT xen/p2m: move xenmem_access_to_p2m_access() to common p2m.c xen/mem_access: wrap memory access when VM_EVENT=n xen/vm_event: consolidate CONFIG_VM_EVENT xen/arch/x86/Makefile | 2 +- xen/arch/x86/hvm/Kconfig | 1 - xen/arch/x86/hvm/Makefile | 4 +- xen/arch/x86/hvm/emulate.c | 67 ++++++++++++------------ xen/arch/x86/hvm/hvm.c | 51 ++++++++++++++++--- xen/arch/x86/hvm/svm/intr.c | 2 +- xen/arch/x86/hvm/svm/svm.c | 54 ++++++++++++-------- xen/arch/x86/hvm/vmx/intr.c | 2 +- xen/arch/x86/hvm/vmx/vmx.c | 73 ++++++++++++++++++--------- xen/arch/x86/include/asm/altp2m.h | 10 ++++ xen/arch/x86/include/asm/hvm/hvm.h | 18 ++++--- xen/arch/x86/include/asm/mem_access.h | 20 ++++---- xen/arch/x86/include/asm/monitor.h | 9 ++++ xen/arch/x86/include/asm/vm_event.h | 5 ++ xen/arch/x86/mm/mem_access.c | 36 ------------- xen/arch/x86/mm/mem_sharing.c | 3 ++ xen/arch/x86/mm/p2m.c | 40 +++++++++++++++ xen/common/Kconfig | 7 +-- xen/include/xen/mem_access.h | 5 -- xen/include/xen/p2m-common.h | 3 ++ xen/include/xen/vm_event.h | 7 +++ 21 files changed, 266 insertions(+), 153 deletions(-) -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Jan 15 09:29:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 09:29:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204481.1519138 (Exim 4.92) (envelope-from ) id 1vgJfV-00083f-IC; Thu, 15 Jan 2026 09:29:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204481.1519138; Thu, 15 Jan 2026 09:29:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgJfV-00083Y-FT; Thu, 15 Jan 2026 09:29:29 +0000 Received: by outflank-mailman (input) for mailman id 1204481; Thu, 15 Jan 2026 09:29: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 1vgJfU-0007pe-IK for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 09:29:28 +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 af149d0a-f1f4-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 10:29:26 +0100 (CET) Received: from CH0PR03CA0354.namprd03.prod.outlook.com (2603:10b6:610:11a::17) by CH3PR12MB8460.namprd12.prod.outlook.com (2603:10b6:610:156::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Thu, 15 Jan 2026 09:29:20 +0000 Received: from DS3PEPF000099DD.namprd04.prod.outlook.com (2603:10b6:610:11a:cafe::16) by CH0PR03CA0354.outlook.office365.com (2603:10b6:610:11a::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.4 via Frontend Transport; Thu, 15 Jan 2026 09:29:17 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by DS3PEPF000099DD.mail.protection.outlook.com (10.167.17.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Thu, 15 Jan 2026 09:29:19 +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, 15 Jan 2026 03:29:07 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: af149d0a-f1f4-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=cgghZTfn2kD2B0gnvsGiWUGRboHEeFf0klMb3gp8MPVnXpuW7YU9wq7sniw83YyrVxF/vHHNogguCzTFqUBIzgVm/YhJCO8TERXE1eA7kfeCRcAV+I6GU64KCIWrB/6cFmG2opQ4UwzMR4IF3iMc+jWXM6gVjWhT2L5u716cHwLss9hEWT2jTBU9h3neGjjH3Sdy68Xd9Guidp49D0KN17SavPC7kIB8/765vlcN+9uVnoTbc2v8sUHK0mZ1LSv0ouDoqR6OZgiUziNA6wGppqkvEkFAkMplBASeHrdxhFnmnp8e4xGh7ZB7bbwHtYzgluBf4fxc5X4YEQCtpOrTUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EWULiMlAUpeVte6nMxTzyciI1mUUV5lwW8iQ0Q8ICbk=; b=M8sON7Fb/urS+oMgrpQ68X8B1Mf6TQKyS4aJSE5rSxZBlHC75uRWrmS0jS6PiAbS36cS+n1RYHznfLZcNanuoShSdVVZqn3QHPDCIt7qQPRTzHvXxeKIixu2i5z8M3FJsSBfV6T7VJyxn3vrK9meepuPdDG89uE0oI7HW0P7bUid1YK5GgMHjNMm2UgYqao4+un4ljjWvCk3JtI8kX2ddHinNVXLBS7kxLwzOOwA5go8UcNxYP/s8tOXGEUwrIs+OUwW6X69dR4hrOPA9sIJkezteAzP4NCIhj13IcnEBvsF5rlwbQzqH6qaMqIl3/xclYls+QzVF8GJS8xtNvfrBg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EWULiMlAUpeVte6nMxTzyciI1mUUV5lwW8iQ0Q8ICbk=; b=R1Mb+MJ/jeMJipVvvKqo2M2l7jqA4UGjFyDxFBxRUCLr9txYg2lgYG9pVKArAg7i4xQQsHkyIwG9odZxVQHU29chDqoqqB/IpnzPYeywp0HKCjLYIY/XMadmynpL029wMruz62I21MBiSqr/s+TdvYsBFr0VatNQz4ouYVQrFhE= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 v4 3/6] x86/monitor: wrap monitor_op under CONFIG_VM_EVENT Date: Thu, 15 Jan 2026 17:28:38 +0800 Message-ID: <20260115092841.2651224-4-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260115092841.2651224-1-Penny.Zheng@amd.com> References: <20260115092841.2651224-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: 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: DS3PEPF000099DD:EE_|CH3PR12MB8460:EE_ X-MS-Office365-Filtering-Correlation-Id: 858f4fb0-aef3-4470-f9ee-08de54188fba X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?4Yjt2mWj2Nx5cQnAV55ZFLIMJfAnoYl5TRo7BZz9sCVQlgbeoe0hAHXGetS6?= =?us-ascii?Q?GuqIu10/1KGoSr1773EYieQfrybFRzrAZ5gJ6p9WGFOiMW9Xqj5rCZ1veVcM?= =?us-ascii?Q?+rcq2KCNaIgkFDf6vYjeHz/4VfZx5cmQjk1zo3UloLoyn39hkvc1/d8L1zsP?= =?us-ascii?Q?P6g9bgtNi5mZ3GHe8XdDzxC6xx9NFyubcttvrumSxKgyD9LqfgcFOZXbTV48?= =?us-ascii?Q?VUfnMWft2F6LH+60UX5zwtDoB5vz/gGw83Jxch1pi6mdG3qW/E6ZU4U4WEXv?= =?us-ascii?Q?jIUqnD9uJwkMHEGdQYPK7BAHAPZxnR0BIdrNc4niOlsMJqFMySLtSI3GzRZb?= =?us-ascii?Q?N+hhwSqWAfiHzXs9FbzwoSARQhKmTi8p242Ndc5gNHalc3NR0h2TOS0Bzh29?= =?us-ascii?Q?9xeg1QCLVOw88g7bbnhqeqXBj/VeaYsvlTFA/BkCyNifWSTmnVFv8PDnVSXH?= =?us-ascii?Q?mn5GR56m/2o0AuziS+vya9HHeTDAkszPu+LOs8yjuLWxmQlP11uXP8tDADKP?= =?us-ascii?Q?ZSGBzss8QTHxM0w3BK4vwgK2osyRTPUHLYbz4aGsvZxYrQds/0JPNgjgLRZM?= =?us-ascii?Q?F22PaFDZkqxZGCEO4ZkJkQmtoGvB2uO0+RNqcl7weuaJrc//VpWup36otNaK?= =?us-ascii?Q?hufzqrNXW6AMOWnCw2joUvoT3muus9Z9QRXqnzWyS/qymSvOiE9m7OCnpvH2?= =?us-ascii?Q?D9gahTmMfgtryO7OfqQ+ngZ2V91rCCDC/GcSRrVUCLcbBnIG2UmuxfcYZMBc?= =?us-ascii?Q?dtA4sliSxFMUoFgeRQSfKGJrwvRjNCjH7QRjBfcjqAyYomSMETdx7T9Gbjf6?= =?us-ascii?Q?YsUaZYB2EOY04CCUDhfM2dxT1rPXSizvgxfGDG1eYBtrj2YDchJfIic2DPjA?= =?us-ascii?Q?KnAEKsliocAURoKp+W6y1+fyPLveF/fGvWpL1e/iY6jdWRrV9ukmRn5pnFRG?= =?us-ascii?Q?wifMTVW5mav/LjwLUV/86R9pHQq9KpTIpQ7ZTl38wne1FOAcK3fywE3MZrAg?= =?us-ascii?Q?dh1B7ZLyA2IAbcote09iM9uYyFIyrxsbK9H1M9drPqsgbRM73De8rFsaJv+P?= =?us-ascii?Q?+D0aNsWP40EvTNZM3RBYKr8S5QcaJacRlWXMDvIFY9KkPuLMRVnLmrAHYDdT?= =?us-ascii?Q?92Wgv53FDfcfUwC9Yyu67AGBEIWtozTcY78DUG7DIUhwZXIGl6YSozbqoFEL?= =?us-ascii?Q?ZE/I+01q2uQxX1pH8soPfUQ+P2AJKh5HqzvdWLYbTVakeOurGIlRMh9+I0Hc?= =?us-ascii?Q?hHt/RIQQU93INsxkAAlbw+d26eJi1MxyMmQIYI55vfsx0Qy4HugO/yczpJRE?= =?us-ascii?Q?z5LOlnhvFIjmb+pmsXFuQOG9bIcRHUaZfT2lwQbdG08nRTGpTxVHfSGeohmI?= =?us-ascii?Q?ce3+PO+Ds9pFg/tByRFxyrSgOmjQCVHimq2SikEIbxoNRJ+mWjbZ7V7fQSWx?= =?us-ascii?Q?xEO2jlYfCJPkEqrGLYRxvdyd1qIXI/5qrANmSSNPZCTEkzbE8SkDFOFvJoAe?= =?us-ascii?Q?f3/X4MVxICSqJeVDMf9+b4N8SHujmbBPMH1VdR9orRsTGH86vO97ImyL8jFl?= =?us-ascii?Q?Y0reSPUKBqapuMumRY6CqiAisOwoDWrmmEVUP/CBdsimzu3rWdFlao0CAdFC?= =?us-ascii?Q?fhk01+XdtwEybNBLUkCLj2SoUIxmHhj5bAD0EwqteogA1b68phRHaKoQYr08?= =?us-ascii?Q?3dQOhA=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 09:29:19.9728 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 858f4fb0-aef3-4470-f9ee-08de54188fba X-MS-Exchange-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: DS3PEPF000099DD.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8460 Feature monitor_op is based on vm event subsystem, so monitor.o shall be wrapped under CONFIG_VM_EVENT. The following functions are only invoked by monitor-op, so they all shall be wrapped with CONFIG_VM_EVENT (otherwise they will become unreachable and violate Misra rule 2.1 when VM_EVENT=n): - hvm_enable_msr_interception - hvm_function_table.enable_msr_interception - hvm_has_set_descriptor_access_existing - hvm_function_table.set_descriptor_access_existi - arch_monitor_get_capabilities Function monitored_msr() still needs a stub to pass compilation when VM_EVENT=n. Signed-off-by: Penny Zheng Acked-by: Jan Beulich Reviewed-by: Jason Andryuk --- xen/arch/x86/hvm/Makefile | 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 | 18 +++++++++++------- xen/arch/x86/include/asm/monitor.h | 9 +++++++++ 5 files changed, 38 insertions(+), 9 deletions(-) diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile index 1b97bdc624..ee4b45a4ee 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 diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 21f355a657..5d23603fc1 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -297,6 +297,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; @@ -304,6 +305,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) { @@ -824,6 +826,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) { @@ -841,6 +844,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) { @@ -2454,9 +2458,11 @@ 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, - .set_rdtsc_exiting = svm_set_rdtsc_exiting, .set_descriptor_access_exiting = svm_set_descriptor_access_exiting, +#endif + .set_rdtsc_exiting = svm_set_rdtsc_exiting, .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 89f9d9c7f6..40e4c71244 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -1581,6 +1581,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) { @@ -1595,6 +1596,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) { @@ -2474,6 +2476,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; @@ -2481,6 +2484,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 @@ -2932,7 +2936,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, @@ -3141,9 +3147,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 @@ -3214,8 +3222,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 666fa402a8..af042ae858 100644 --- a/xen/arch/x86/include/asm/hvm/hvm.h +++ b/xen/arch/x86/include/asm/hvm/hvm.h @@ -192,7 +192,11 @@ 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); + void (*enable_msr_interception)(struct domain *d, uint32_t msr); +#endif /* Nested HVM */ int (*nhvm_vcpu_initialise)(struct vcpu *v); @@ -224,8 +228,6 @@ struct hvm_function_table { paddr_t *L1_gpa, unsigned int *page_order, uint8_t *p2m_acc, struct npfec npfec); - void (*enable_msr_interception)(struct domain *d, uint32_t msr); - #ifdef CONFIG_ALTP2M /* Alternate p2m */ void (*altp2m_vcpu_update_p2m)(struct vcpu *v); @@ -435,11 +437,18 @@ static inline bool using_svm(void) #define hvm_long_mode_active(v) (!!((v)->arch.hvm.guest_efer & EFER_LMA)) +#ifdef CONFIG_VM_EVENT static inline bool hvm_has_set_descriptor_access_exiting(void) { return hvm_funcs.set_descriptor_access_exiting; } +static inline void hvm_enable_msr_interception(struct domain *d, uint32_t msr) +{ + alternative_vcall(hvm_funcs.enable_msr_interception, d, msr); +} +#endif /* CONFIG_VM_EVENT */ + static inline void hvm_domain_creation_finished(struct domain *d) { if ( hvm_funcs.domain_creation_finished ) @@ -681,11 +690,6 @@ static inline int nhvm_hap_walk_L1_p2m( v, L2_gpa, L1_gpa, page_order, p2m_acc, npfec); } -static inline void hvm_enable_msr_interception(struct domain *d, uint32_t msr) -{ - alternative_vcall(hvm_funcs.enable_msr_interception, d, msr); -} - static inline bool hvm_is_singlestep_supported(void) { return hvm_funcs.caps.singlestep; diff --git a/xen/arch/x86/include/asm/monitor.h b/xen/arch/x86/include/asm/monitor.h index 3c64d8258f..9249324fd0 100644 --- a/xen/arch/x86/include/asm/monitor.h +++ b/xen/arch/x86/include/asm/monitor.h @@ -71,6 +71,7 @@ int arch_monitor_domctl_op(struct domain *d, struct xen_domctl_monitor_op *mop) return rc; } +#ifdef CONFIG_VM_EVENT static inline uint32_t arch_monitor_get_capabilities(struct domain *d) { uint32_t capabilities = 0; @@ -102,6 +103,7 @@ static inline uint32_t arch_monitor_get_capabilities(struct domain *d) return capabilities; } +#endif /* CONFIG_VM_EVENT */ int arch_monitor_domctl_event(struct domain *d, struct xen_domctl_monitor_op *mop); @@ -123,7 +125,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__ */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Jan 15 09:29:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 09:29:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204482.1519146 (Exim 4.92) (envelope-from ) id 1vgJfV-00087m-W2; Thu, 15 Jan 2026 09:29:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204482.1519146; Thu, 15 Jan 2026 09:29:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgJfV-00085s-OY; Thu, 15 Jan 2026 09:29:29 +0000 Received: by outflank-mailman (input) for mailman id 1204482; Thu, 15 Jan 2026 09:29:28 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgJfU-0007JZ-KT for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 09:29:28 +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 af4e2ab2-f1f4-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 10:29:27 +0100 (CET) Received: from CH0PR03CA0337.namprd03.prod.outlook.com (2603:10b6:610:11a::27) by SJ0PR12MB8090.namprd12.prod.outlook.com (2603:10b6:a03:4ea::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Thu, 15 Jan 2026 09:29:21 +0000 Received: from DS3PEPF000099DD.namprd04.prod.outlook.com (2603:10b6:610:11a:cafe::8b) 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.9520.6 via Frontend Transport; Thu, 15 Jan 2026 09:29:17 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by DS3PEPF000099DD.mail.protection.outlook.com (10.167.17.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Thu, 15 Jan 2026 09:29:21 +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, 15 Jan 2026 03:29:16 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: af4e2ab2-f1f4-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bD7/C+UBRoYpllMLVGEYP3cN/RCtfTf38x/Gd+hXq4AQPwye0i0oBbV2mexw6eKyPK98wXllh9sqKnZZ9ttaI44W6JJRCBmKsljvI746y1c6bgkcUetuvdZwOMsXjiu5BXsexPupogv9pBLAepjuePkFLRjJ/82yUgfP3wOfLGPsX4ZEhipYNz47KxQ8haGX2CJ86eVfJSEIyASpJOcsftriFfjCBL6ADa83wdp+GZwzYcmvvXMRJrUeghZ0Z1L37+1zwU/3MUpe+6DD5t5KeHDgCyCO+8GV2iqOv1v3uJmYG4zg9vr+5DqDZo/1VQUnBSBp4beQffgVIvhXlC5vGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LALbY4dL3KCQh/g6RMK77IghwWdSjrOw31tRRJG4UsA=; b=JrKnDxU0KSX/ZmFk0PSJanrxpmB90dJduuYL08wG+Ayljp6ejAzAezUIa4yBpjaoc5A9XemV00/e7ZTyt/bmXXTz7RGhQiCQol5p5L6i4FIB0exbMXuVvy8PkiRLGMtilxCPM20L57472vzt1mTGT2MgKHP2ZM53B3O9Z7LE37aI+kApwMLGrtFMQ7Uk4jqQ5H3I4Uqe2QSi/vjqbMsrZHVoqeUNPlUBiKL4AaqKCJ16ascRcQQdkjirndz2vbdIzKW1K2xGaZM8nP5Bh6KLPfwCaiF3OKDPfj3k+x1Qjfw+OnsGlMzIyqvJxQBVQHseG8t1tAhRhRCWbJm5x0AG8g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LALbY4dL3KCQh/g6RMK77IghwWdSjrOw31tRRJG4UsA=; b=itEnpKbS0s1G7TwHmUsYc95sVBTI4Hm3KnfIOiaIIOx3CrNq5tUEnhVoR5ITKGMFIPxzRJr4L/+Qvsz0UvV3x5w2g/3w+FwWwF0X/OSmrEDFmkQTExYYyY5tgv0GqOO6B66osLxJ897yADcJStKJUvCIHBfZW1ICHmf+XRIVe2E= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 , "Tamas K Lengyel" , Alexandru Isaila , Petre Pircalabu Subject: [PATCH v4 6/6] xen/vm_event: consolidate CONFIG_VM_EVENT Date: Thu, 15 Jan 2026 17:28:41 +0800 Message-ID: <20260115092841.2651224-7-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260115092841.2651224-1-Penny.Zheng@amd.com> References: <20260115092841.2651224-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: 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: DS3PEPF000099DD:EE_|SJ0PR12MB8090:EE_ X-MS-Office365-Filtering-Correlation-Id: 3b50ec80-4176-4da8-01d5-08de541890a0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|36860700013|82310400026|1800799024; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?ob25nXPVEoUAi0i8tngJ1EyXRq60XBiVsPwnSlD0PRnGDtJZMbsBAeakiWRt?= =?us-ascii?Q?PtDCtluhX7C5Ugj1k1m56FFZNPNiriZPXNZYBCIazHT0LppBquppFbjKLlv9?= =?us-ascii?Q?zuVsjrNT2LjX5aP9ks7d47DAj8LFJomANJDvb4hDxJ1kJ2fC+kOxbMYz/X2/?= =?us-ascii?Q?vRt3UK6kYVtGzM5diXLBxlrSq2DfMZhlbCIRTCNoAM/69+bpkBdUuYBt5KxU?= =?us-ascii?Q?tTpQMxtj0nBkF6w86JU//IYbGbsGLqnka2qBTwjPpz9XWbb0jpJ/lhj/Dr5A?= =?us-ascii?Q?GY9ULrpW0YqZJXqysAVEhwyC4sKUojNPGQ9XF2izHie6K3ThnCBg8ZpKT4KT?= =?us-ascii?Q?LiAfpwH/tBW4rKKRAmVpeI/DnvtQWztwDVMiN0jHaVPVYiqIh+rauhotctF7?= =?us-ascii?Q?wTvOy+/fsVWrGUZj+uytwQifBXHxhpEtnyalULT80qN2q5CcbpMIU25dSED4?= =?us-ascii?Q?AYkjPQbm7XBKCmN9Szp6rnXpqjF+bAlUAIhI4RVxYFz6d1AZDJ4dRl6UM9mm?= =?us-ascii?Q?KBEZn88EIMmGKCbw/dmxeVyrzIWpav/LPbyrl6xIq5nU0CssiiNVMgBt9O78?= =?us-ascii?Q?xLD/weGSwNp4H2r7LwHjQGn+C2MdSEabSiW6FSsT2xSSiu3GCTX6aTUnipfu?= =?us-ascii?Q?YmyROKRz7mv20ol3zrHnaN/QvYsJTG90ep1a5WzLYos+Uy3df2ad06VCVUTN?= =?us-ascii?Q?oszSlaj00VNmtPSJmwB76nc9KJrTbWOSj8VTt8RqlQad1kM/Of2lLgmfcT9v?= =?us-ascii?Q?7pkJxLLuvvZUCOanDe+28xHNccF/7lJ7fKh5bIDWMf+7qKAM+yZJZl8qgcpO?= =?us-ascii?Q?FlE6mLYC/h2WQnBLLjtIzkZBgGMmwcm9F2AyGmfadQxCLapbyF4M2dTq07sw?= =?us-ascii?Q?UpgGggSpJ4s0qwWtxkTu2NwqkSMUsiF7KUWx9QYbOanzMk35rtAa/5tVhkjB?= =?us-ascii?Q?bv71eOs9pxCFYkdpGPWAmpoMV2LU6/3lTJH0gLB8JCcE4tW/jir8bOGaMIEs?= =?us-ascii?Q?sOyvC6RLHZ2O+wd7UTX3Lz+TvfdZ715XlY3xITkvwBjmsyiH24fjcIHcZIFU?= =?us-ascii?Q?kG5+lbwx5bBZIQSV1zeCEctZGcnYGzEzi5q7yHLyHo82bRahM0bjIYHvuEqY?= =?us-ascii?Q?pybpSnsnjC6mUCib+i7gpei81ScQ9J29PJp1PgY5UnjEeYUUHRBC0lrngfEA?= =?us-ascii?Q?StyHDeEQf1OojA4YmvBAKaBEl8VOC7FDHXrdEmB5QnQkGCHqT1IDJlUMedEI?= =?us-ascii?Q?VANMs+AwL8Mh/yABR8p6R4Q4g8I6yaT2n273mWaUpj43j4pYD0VXv/qHxAP8?= =?us-ascii?Q?mZZfI3HUHaYRDb6Vd+c4UaZSjzfrxqKEaJewDJBml+SirvDmdHrXw2TDdjVQ?= =?us-ascii?Q?OapVUToHpqJBbK3gVcxIzOsIbhXCSl/bGObQXQB/kL1979MEM8196noaXcNU?= =?us-ascii?Q?eLR3UOk6IxIJsKfV65Y1ON4dFezo4Kz2PJPQCnAZsmEQp8FqPogcFAuERBfZ?= =?us-ascii?Q?kyV87DLRcqrLNbJzv+XHePempMbOqZ1wn2DFzzW8CPJKYKz6NWFZ/dzskqyX?= =?us-ascii?Q?9ZWDG4+q4AZUF2BBnKxMrmHItzJUQlM5rE48i4ItILME+rHZiV7wYoApzDiK?= =?us-ascii?Q?fZHAkOuv+7VOCI8zVQ8yBcQi3PBHvcSuvg5+oFplJBqWTBvtdVTG+UhBn8kl?= =?us-ascii?Q?UP8BIg=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(7416014)(376014)(36860700013)(82310400026)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 09:29:21.5091 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3b50ec80-4176-4da8-01d5-08de541890a0 X-MS-Exchange-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: DS3PEPF000099DD.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB8090 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. Although CONFIG_VM_EVENT is right now forcibly enabled on x86 via MEM_ACCESS_ALWAYS_ON, we could disable it through disabling CONFIG_MGMT_HYPERCALLS later. So we remove MEM_ACCESS_ALWAYS_ON and make VM_EVENT=y on default only on x86 to retain the same. The following functions are developed on the basis of vm event framework, or only invoked by vm_event.c, so they all shall be wrapped with CONFIG_VM_EVENT (otherwise they will become unreachable and violate Misra rule 2.1 when VM_EVENT=n): - hvm_toggle_singlestep - hvm_fast_singlestep - hvm_emulate_one_vm_event - hvmemul_write{,cmpxchg,rep_ins,rep_outs,rep_movs,rep_stos,read_io,write_io}_discard And Function vm_event_check_ring() needs stub to pass compilation when VM_EVENT=n. Signed-off-by: Penny Zheng Acked-by: Jan Beulich Reviewed-by: Jason Andryuk --- As the last commit, plz be commited either in the last, or shall be commited together with prereq commit 8d708e98ad, 8b4147009f, dbfccb5918, ae931f63a0, 37ec0e2b75. --- xen/arch/x86/Makefile | 2 +- xen/arch/x86/hvm/Kconfig | 1 - xen/arch/x86/hvm/Makefile | 2 +- xen/arch/x86/hvm/emulate.c | 58 ++++++++++++++++++++------------------ xen/arch/x86/hvm/hvm.c | 2 ++ xen/common/Kconfig | 7 ++--- xen/include/xen/vm_event.h | 7 +++++ 7 files changed, 44 insertions(+), 35 deletions(-) diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile index d8b41cec16..5bf3578983 100644 --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -69,7 +69,7 @@ obj-$(CONFIG_INTEL) += tsx.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/Kconfig b/xen/arch/x86/hvm/Kconfig index c1a131d185..25eb3e374f 100644 --- a/xen/arch/x86/hvm/Kconfig +++ b/xen/arch/x86/hvm/Kconfig @@ -4,7 +4,6 @@ menuconfig HVM default !PV_SHIM select COMPAT select IOREQ_SERVER - select MEM_ACCESS_ALWAYS_ON help Interfaces to support HVM domains. HVM domains require hardware virtualisation extensions (e.g. Intel VT-x, AMD SVM), but can boot diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile index ee4b45a4ee..f34fb03934 100644 --- a/xen/arch/x86/hvm/Makefile +++ b/xen/arch/x86/hvm/Makefile @@ -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/emulate.c b/xen/arch/x86/hvm/emulate.c index fe75b0516d..d56ef02baf 100644 --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -1615,6 +1615,7 @@ static int cf_check hvmemul_blk( return rc; } +#ifdef CONFIG_VM_EVENT static int cf_check hvmemul_write_discard( enum x86_segment seg, unsigned long offset, @@ -1717,6 +1718,7 @@ static int cf_check hvmemul_cache_op_discard( { return X86EMUL_OKAY; } +#endif /* CONFIG_VM_EVENT */ static int cf_check hvmemul_cmpxchg( enum x86_segment seg, @@ -2750,33 +2752,6 @@ static const struct x86_emulate_ops hvm_emulate_ops = { .vmfunc = hvmemul_vmfunc, }; -static const struct x86_emulate_ops hvm_emulate_ops_no_write = { - .read = hvmemul_read, - .insn_fetch = hvmemul_insn_fetch, - .write = hvmemul_write_discard, - .cmpxchg = hvmemul_cmpxchg_discard, - .rep_ins = hvmemul_rep_ins_discard, - .rep_outs = hvmemul_rep_outs_discard, - .rep_movs = hvmemul_rep_movs_discard, - .rep_stos = hvmemul_rep_stos_discard, - .read_segment = hvmemul_read_segment, - .write_segment = hvmemul_write_segment, - .read_io = hvmemul_read_io_discard, - .write_io = hvmemul_write_io_discard, - .read_cr = hvmemul_read_cr, - .write_cr = hvmemul_write_cr, - .read_xcr = hvmemul_read_xcr, - .write_xcr = hvmemul_write_xcr, - .read_msr = hvmemul_read_msr, - .write_msr = hvmemul_write_msr_discard, - .cache_op = hvmemul_cache_op_discard, - .tlb_op = hvmemul_tlb_op, - .cpuid = x86emul_cpuid, - .get_fpu = hvmemul_get_fpu, - .put_fpu = hvmemul_put_fpu, - .vmfunc = hvmemul_vmfunc, -}; - /* * Note that passing VIO_no_completion into this function serves as kind * of (but not fully) an "auto select completion" indicator. When there's @@ -2887,6 +2862,34 @@ int hvm_emulate_one( return _hvm_emulate_one(hvmemul_ctxt, &hvm_emulate_ops, completion); } +#ifdef CONFIG_VM_EVENT +static const struct x86_emulate_ops hvm_emulate_ops_no_write = { + .read = hvmemul_read, + .insn_fetch = hvmemul_insn_fetch, + .write = hvmemul_write_discard, + .cmpxchg = hvmemul_cmpxchg_discard, + .rep_ins = hvmemul_rep_ins_discard, + .rep_outs = hvmemul_rep_outs_discard, + .rep_movs = hvmemul_rep_movs_discard, + .rep_stos = hvmemul_rep_stos_discard, + .read_segment = hvmemul_read_segment, + .write_segment = hvmemul_write_segment, + .read_io = hvmemul_read_io_discard, + .write_io = hvmemul_write_io_discard, + .read_cr = hvmemul_read_cr, + .write_cr = hvmemul_write_cr, + .read_xcr = hvmemul_read_xcr, + .write_xcr = hvmemul_write_xcr, + .read_msr = hvmemul_read_msr, + .write_msr = hvmemul_write_msr_discard, + .cache_op = hvmemul_cache_op_discard, + .tlb_op = hvmemul_tlb_op, + .cpuid = x86emul_cpuid, + .get_fpu = hvmemul_get_fpu, + .put_fpu = hvmemul_put_fpu, + .vmfunc = hvmemul_vmfunc, +}; + void hvm_emulate_one_vm_event(enum emul_kind kind, unsigned int trapnr, unsigned int errcode) { @@ -2949,6 +2952,7 @@ void hvm_emulate_one_vm_event(enum emul_kind kind, unsigned int trapnr, hvm_emulate_writeback(&ctx); } +#endif /* CONFIG_VM_EVENT */ void hvm_emulate_init_once( struct hvm_emulate_ctxt *hvmemul_ctxt, diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index b34cd29629..4d37a93c57 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -5250,6 +5250,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)); @@ -5276,6 +5277,7 @@ void hvm_fast_singlestep(struct vcpu *v, uint16_t p2midx) v->arch.hvm.fast_single_step.p2midx = p2midx; } #endif +#endif /* CONFIG_VM_EVENT */ /* * Segment caches in VMCB/VMCS are inconsistent about which bits are checked, diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 38320b248a..d7e79e752a 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -173,13 +173,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 diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h index 27d0c74216..1b76ce632e 100644 --- a/xen/include/xen/vm_event.h +++ b/xen/include/xen/vm_event.h @@ -51,7 +51,14 @@ struct vm_event_domain }; /* Returns whether a ring has been set up */ +#ifdef CONFIG_VM_EVENT bool vm_event_check_ring(struct vm_event_domain *ved); +#else +static inline bool vm_event_check_ring(struct vm_event_domain *ved) +{ + return false; +} +#endif /* CONFIG_VM_EVENT */ /* Returns 0 on success, -ENOSYS if there is no ring, -EBUSY if there is no * available space and the caller is a foreign domain. If the guest itself -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Jan 15 09:29:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 09:29:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204485.1519159 (Exim 4.92) (envelope-from ) id 1vgJfY-00008l-BN; Thu, 15 Jan 2026 09:29:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204485.1519159; Thu, 15 Jan 2026 09: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 1vgJfY-00008Z-7d; Thu, 15 Jan 2026 09:29:32 +0000 Received: by outflank-mailman (input) for mailman id 1204485; Thu, 15 Jan 2026 09:29: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 1vgJfW-0007JZ-7L for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 09:29:30 +0000 Received: from DM1PR04CU001.outbound.protection.outlook.com (mail-centralusazlp170100005.outbound.protection.outlook.com [2a01:111:f403:c111::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id af19d6ed-f1f4-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 10:29:29 +0100 (CET) Received: from CH0PR03CA0335.namprd03.prod.outlook.com (2603:10b6:610:11a::31) by DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Thu, 15 Jan 2026 09:29:21 +0000 Received: from DS3PEPF000099DD.namprd04.prod.outlook.com (2603:10b6:610:11a:cafe::fe) by CH0PR03CA0335.outlook.office365.com (2603:10b6:610:11a::31) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.6 via Frontend Transport; Thu, 15 Jan 2026 09:29:21 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by DS3PEPF000099DD.mail.protection.outlook.com (10.167.17.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Thu, 15 Jan 2026 09:29: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; Thu, 15 Jan 2026 03:29:13 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: af19d6ed-f1f4-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=a+UAL0uVslowv5+vAD0BPjNFTlDjM7h4CkgDKkVG3RgnWQHmgSeOY+dNgtk0UQ5YWzYvFPGBbcVYIm2tMP7DjYQ0OZDqCdNOTgUYZXyJDakg/RnZZUi4cxP/4tnr5qY4bNcSjjccLDcrMvFubHQOLvv9W8sQEdyyK+1WPJ8gpQdCzNI+NCElG9InLovNQbRkFj+1TmVfcdutUM4JFY2HEahjl9pSFssKo3aEuqJSrOygvzIUDEoAq1VXyLEkpOcdlNP6vb/q+xcDi/XacAKoUNil8+gTeTUd22HOf8y1jx+B3j72K6QYLQPA6Noj2+lp+VMt02vso1jSHnaTUG1Shg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+GoBJx+OHAGG6+O4+7S1BHBC7d9Er+VdkwujlD93WbE=; b=anDHgLtGRTTI0CS1rdVmpXjxZafwWl22vYkd+AV7L29fBSlowps88/HlaojRWLeiSl5r+c6oZ58YAwvUczxRe3tjh1QVdgTriTJNQEcHERhyHeNFktjugWzrKjNIfWh6r/PVXGzC0sJcCitGSJxAJmwcEL/yI1cHptiw3vHc6qldaa1F90OwdYh/6kxGtua9l96hs1F9ZZYo4dn29lvmlKSZNOhqJnJj3L0VnsM44JX5Pjal74j4LMXvysCc9ZajRYIU9/+inOony5fkjZludXMRBFGAPvEvdq6Ew0dIkmrb0ryycfEYX4jyG5BseGa3JPxkc4W+bhuoMYC3bKdmCg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+GoBJx+OHAGG6+O4+7S1BHBC7d9Er+VdkwujlD93WbE=; b=tfd1DvreAqxHjZ0dZw5N2Mi0Je/BF+XPnd7yCYA9+rs4BQoet7fS0x34D5/2cNXHr7FBHBsa/pOCllOiQwN2276MfqcYWKwHqDaORSL4dsWebtuL2xqKoBuf8PTXed0G0ZVs1aJBkmcYv7FKDQGZlkOWCTk+YmdPJ+od9saMqXk= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 v4 5/6] xen/mem_access: wrap memory access when VM_EVENT=n Date: Thu, 15 Jan 2026 17:28:40 +0800 Message-ID: <20260115092841.2651224-6-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260115092841.2651224-1-Penny.Zheng@amd.com> References: <20260115092841.2651224-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: 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: DS3PEPF000099DD:EE_|DM4PR12MB8451:EE_ X-MS-Office365-Filtering-Correlation-Id: 34a7d81f-6e8d-4a61-caa9-08de54189046 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?LF/0nq/hSNpVruUt9s+tjnfAFMCCPYw+QO9ugSNG2pXuiVLrdl/fO/DvWYDS?= =?us-ascii?Q?h5R2sEM3zgfzmheQJFfugXhOs8UxOLnFf92pVm4XI+FBMeJp4SBdjQ70E+gK?= =?us-ascii?Q?bgtNHA6MyysIn4qo0BalMbcalPyh+jzX3bY4iVQdTnCQxgYNFM60Eps0rLm5?= =?us-ascii?Q?EQoXKdMCILpRyt1/QDXHllhrmsuObTXm+ANqvPev/EeKR9W/pA9Nn6MC+BdT?= =?us-ascii?Q?lmJUFllgal5dp8YinkHSPNV7DME+mm/9h5CuL+X/rKnzHpnvl1J9+OJEflsT?= =?us-ascii?Q?1FPJlOquZRu+RdnaoZ1ZQ/Qpr0W6KevoyfL2yh8/EZrAV2SoDiKL0oi30cYJ?= =?us-ascii?Q?EBr3ttstpu0LKIgaKtEstZQuQ5GvvYdKmnOS8gzAYowgaBmoZ8yGaCzZc/sw?= =?us-ascii?Q?ob8PVgKgyrnrvUglI3D0CvGZuPY/BTe82jH06x/wr/sD6PL3Py7mU2ALxMt8?= =?us-ascii?Q?tAF7MTK0RydJ9dw9VXxeVVWplwLNyOpOtdf05zl2GBDU8Dg9ATl52pH5g4kS?= =?us-ascii?Q?pa43MPKuYk7TFxPklI1I5KslY2Mon07F2xtGgeNwxZ9bFpnFOpq24CjGh7Qs?= =?us-ascii?Q?d9QStDiQkTwqSDJTgkoGcm6uFTkgk0sv8r3KhSWfTEoUPsQKNRqy4rzUrYLX?= =?us-ascii?Q?S8732ApKt2ZCKrhViFhYabF8umTe0toVDvwUr/DRTioQn5SiJ3GSDeGHn28D?= =?us-ascii?Q?xp0lIb3O/3PNrH3gfJ5paeypapC/7rdVCRo1+6ksFwY3PDiB3AzzyVWCUBi5?= =?us-ascii?Q?LEhYA3yw6jSohrTQX2xFztNA3DgHV4j6Xydgtlbrep+F4IG7JmclEK3uWG9M?= =?us-ascii?Q?EIBD+vI//TTAfnvP7hqCKz7MCrXith1okxZJpLAS3LCTzWIyIFh8TGwm8IeY?= =?us-ascii?Q?2VwcOiMr2oAFeLaOJTnIUKmiod7d8w+sftEEnnYy6QK2Ggb5L6LBjS5Sk/jA?= =?us-ascii?Q?VocOgEBcV+wOJBKZIsvpxVhyFDUrvgrsSCRFFEY6PUE42/MCa7saGTQA6g0t?= =?us-ascii?Q?LkCaIsz0bBg5606NWHgIFYwF0cjTISZtF75dLgCbppajSP/gvAAC1/ILFKTd?= =?us-ascii?Q?Lc2bGyDEn4XALTJ3v3leBAcKZi7HsgL1qJ5Pg2LhIYpG69T7SMPEBK2eKZei?= =?us-ascii?Q?p/Fu+HJQxGEE6xKAyIo6B25n5gl7Si/x69MMLTVdCbogSK5tAv8YYTqRbFqT?= =?us-ascii?Q?njWeawqo6+0HcT33yr/SaBp1h+Um0S1pFZ7wLr4mLJ1tQXILGXV1wlgJFSvy?= =?us-ascii?Q?xONOELzXIEkeSSBLVYrsK+usRqeMNIUw3wH0WJNCdCQZU1e9vnehcO1/f9un?= =?us-ascii?Q?yI+7G2nYvK+2UPKUvANkRDvQzjXn1cbUJkxvlNIgg1fnRAlenVqRvKGqu0L0?= =?us-ascii?Q?6MudathUJfeqMjpy0JoFaM1Z+sS6yEt1Jz9Vn5J5sI50yjGU75yX+m9nInp0?= =?us-ascii?Q?cZZJHSNRVAthpbTMkDnS1GDavCL2MOGjxepu3D+StZSLiqpowAYFf2yVnO3r?= =?us-ascii?Q?KagcTTwurJ1TTBnbHrfxTTeg0JKYho+q0/TVOy2YQpCTBgq1+lA5vNFK/Yzp?= =?us-ascii?Q?TNWnlZN/fT+TLnSdSrBNt+/ulkyNgNz+IfMWsOimNXnh+EzdL0ALijeN+e50?= =?us-ascii?Q?mKgNivENlJqk9zvSBAZ4N1nOi2WFkE1Xw2b1INY7JBcTgtLoLIMPCDIMTUcT?= =?us-ascii?Q?imgTJg=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 09:29:20.8881 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 34a7d81f-6e8d-4a61-caa9-08de54189046 X-MS-Exchange-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: DS3PEPF000099DD.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB8451 Feature memory access is based on vm event subsystem, and it could be disabled in the future. So a few switch-blocks in do_altp2m_op() need vm_event_is_enabled() condition check to pass compilation when ALTP2M=y and VM_EVENT=n(, hence MEM_ACCESS=n), like HVMOP_altp2m_set_mem_access, etc. Function p2m_mem_access_check() still needs stub when VM_EVENT=n to pass compilation. Although local variable "req_ptr" still remains NULL throughout its lifetime, with the change of NULL assignment, we will face runtime undefined error only when CONFIG_USBAN is on. So we strengthen the condition check via adding vm_event_is_enabled() for the special case. Signed-off-by: Penny Zheng Acked-by: Jan Beulich --- v1 -> v3: - a comment next to the excessive condition - use vm_event_is_enabled() instead - avoid heavy churn by using the inverted condition plus break --- v3 - v4: - refine comment --- xen/arch/x86/hvm/hvm.c | 26 +++++++++++++++++++++++++- xen/arch/x86/include/asm/mem_access.h | 10 ++++++++++ 2 files changed, 35 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 07e54890d9..b34cd29629 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -52,6 +52,7 @@ #include #include #include +#include #include #include #include @@ -2082,7 +2083,12 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla, #endif } - if ( req_ptr ) + /* + * req_ptr being constant NULL when !CONFIG_VM_EVENT, CONFIG_UBSAN=y + * builds have been observed to still hit undefined-ness at runtime. + * Hence do a seemingly redundant vm_event_is_enabled() check here. + */ + if ( req_ptr && vm_event_is_enabled(curr) ) { if ( monitor_traps(curr, sync, req_ptr) < 0 ) rc = 0; @@ -4804,6 +4810,12 @@ static int do_altp2m_op( break; case HVMOP_altp2m_set_mem_access: + if ( !vm_event_is_enabled(current) ) + { + rc = -EOPNOTSUPP; + break; + } + if ( a.u.mem_access.pad ) rc = -EINVAL; else @@ -4813,6 +4825,12 @@ static int do_altp2m_op( break; case HVMOP_altp2m_set_mem_access_multi: + if ( !vm_event_is_enabled(current) ) + { + rc = -EOPNOTSUPP; + break; + } + if ( a.u.set_mem_access_multi.pad || a.u.set_mem_access_multi.opaque > a.u.set_mem_access_multi.nr ) { @@ -4844,6 +4862,12 @@ static int do_altp2m_op( break; case HVMOP_altp2m_get_mem_access: + if ( !vm_event_is_enabled(current) ) + { + rc = -EOPNOTSUPP; + break; + } + if ( a.u.mem_access.pad ) rc = -EINVAL; else diff --git a/xen/arch/x86/include/asm/mem_access.h b/xen/arch/x86/include/asm/mem_access.h index 257ed33de1..790bed81e8 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,15 @@ 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) +{ + *req_ptr = NULL; + return false; +} +#endif /* CONFIG_VM_EVENT */ /* Check for emulation and mark vcpu for skipping one instruction * upon rescheduling if required. */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Jan 15 09:29:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 09:29:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204488.1519169 (Exim 4.92) (envelope-from ) id 1vgJfa-0000S4-Jd; Thu, 15 Jan 2026 09:29:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204488.1519169; Thu, 15 Jan 2026 09:29:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgJfa-0000Rr-GC; Thu, 15 Jan 2026 09:29:34 +0000 Received: by outflank-mailman (input) for mailman id 1204488; Thu, 15 Jan 2026 09:29:33 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgJfZ-0007JZ-9H for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 09:29:33 +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 af1afdc4-f1f4-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 10:29:26 +0100 (CET) Received: from CH0PR03CA0356.namprd03.prod.outlook.com (2603:10b6:610:11a::34) by CH1PPF84B7B0C96.namprd12.prod.outlook.com (2603:10b6:61f:fc00::618) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Thu, 15 Jan 2026 09:29:20 +0000 Received: from DS3PEPF000099DD.namprd04.prod.outlook.com (2603:10b6:610:11a:cafe::c6) by CH0PR03CA0356.outlook.office365.com (2603:10b6:610:11a::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.6 via Frontend Transport; Thu, 15 Jan 2026 09:29:19 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by DS3PEPF000099DD.mail.protection.outlook.com (10.167.17.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Thu, 15 Jan 2026 09:29: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; Thu, 15 Jan 2026 03:29:10 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: af1afdc4-f1f4-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TUwyQG/MzpCq57QuIse3ioF5fEqCNYy6NziViD1vEKLEj55X/36Ejz9igbZMhWY9DMKt+f+7va9DdCMC2baotU/3/a1/H8AQ7gPkmzVRRYIpGdXW90fKYsgxv/EHqnaYGCLpJqyH4hZ838hZH5SDo/bnS9uQRNBlpsKwz2Z8QVhg7XT3tH3CoN6bVNlwTgw2WlTPba63xMBVjY3UFl80BqJXL8DVcnBmVnR4zO/xJAkdWNVEU1+TVuCcVazUFACQO4nZjjYce2ex6k9lkSgcwvWyYg47lgZBiAVJHORwVc1vbERgQ7CVw7nW+4P7exrkG0DjEnrZJwdzPjp8q0vD5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ABCXVSHV2eH9kGiJIwIF6xx3zPKKoyzY2uDyJj9ALZk=; b=k9Nx07YjyUDc3fJHsoaOn71T1173iRzLQ0vZ/BttaVdf38pbxAkvdJEu0iGZiAwxagDZDrLMvzqJCpa79oO7n6DeOZU+3gWRvavlIaUQlz3f8FgxwBjvGtgyP/JDI7h+fQcqM1onjAIbgcPxcIUptp33VV+vQTitvboEL90VNgJMWbIHIHsx74Znz11qs/4uV64E9rgodI5EhIqtqPLxsln3FwcLE6w0pJA51psgOFGSbSwhYO5VktfedFRC+7Jj54ekyD7TnDGo6MD/+m/thQVoJcEYlh0/vCK6oNo5gtgXdyJZfyJyyd2sQyyWQJqW8DEG8waTXyDd3fG6I+q4pQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ABCXVSHV2eH9kGiJIwIF6xx3zPKKoyzY2uDyJj9ALZk=; b=TmQkQ33u+dWTd9tRWmD/MeIS3jOf/r3CxL9lauYgQieAO3TAiks6rJbZWuWhlnAyP0SoUoz7gFE365NE2yOsiOTRQVFayMsMhkjBLCJ/3c/M19F+k38MwL+6wQxKcLtLUjgvr1fTxWNcIBWG6pLyUqimiD022QE1gk3Loe9Dpvs= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 , Tamas K Lengyel , Alexandru Isaila , "Petre Pircalabu" , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD , Michal Orzel , "Julien Grall" , Stefano Stabellini Subject: [PATCH v4 4/6] xen/p2m: move xenmem_access_to_p2m_access() to common p2m.c Date: Thu, 15 Jan 2026 17:28:39 +0800 Message-ID: <20260115092841.2651224-5-Penny.Zheng@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260115092841.2651224-1-Penny.Zheng@amd.com> References: <20260115092841.2651224-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: 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: DS3PEPF000099DD:EE_|CH1PPF84B7B0C96:EE_ X-MS-Office365-Filtering-Correlation-Id: 38dd6108-a5fe-4e78-d322-08de54188fff X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026|7416014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?A/7NW45hdC/CbRpFxgQ14gZtUnzX27oQLgJJ9tlCEI7rnc0VnM15Z2TTgXhX?= =?us-ascii?Q?lyRcE36oLy6AV53ZXPAp7G84q9wtBKCHQU+Ex7xsmcxWYJCMep9SRMVk48mX?= =?us-ascii?Q?7YL2CEcs5vAwlq0FrrKfCh2hb02cH+HuHQezthiCY2B+DTKn+vl5n8ZytC8x?= =?us-ascii?Q?XdZFSfVMVrF2QZu0ULGk7K7a+wcsR+wz2iKkzt38CBeYwDVjyJlIieMVLQXp?= =?us-ascii?Q?Hq6HOM8/sRVef3nEVdl/qCCI+C3kR4iIYnSZL0WGwQGmKEHJjbflL2OmI/1w?= =?us-ascii?Q?VpLkjZJJusdPDzGMpNE8eym9s3ZJbRX6pevw60jhinsxb7ZxtYBUsjOzbFfB?= =?us-ascii?Q?M/eDGz33qXvbtsAvSYQynuHiAyGCdy1XaeZFPKY+0Z0tWWNo311IPBbAQwBt?= =?us-ascii?Q?S/7grTOtJAvs/BBEgO4sjApYTu7Kb5HrFyS1tPa5vRQa5gLNscZl4VmRkZyp?= =?us-ascii?Q?UaOoVojM62SdZSlwhnWoFq8D/W4mU3idF9CPkFKXBmXtjlNyrcuSpwjKRfQ4?= =?us-ascii?Q?NTsHZ1HjP7uH2CkdBUhz5h+a7O+E8eETLDjfZViYb//9qKOGMxt1DcJG5Inu?= =?us-ascii?Q?W9Lv0boGQ7wn7/79SEEx+UBehUcq5yLit7WgEOrszcRc057HwXZBoiq35RMS?= =?us-ascii?Q?W8StyyySY+45PAA1SSDfOb+9QpOPfogH7AfrhAsEIz6tfczjjA3PsJEo+tN3?= =?us-ascii?Q?u27LNHlTqC0zoIFkDYKZKayKUd8hQGtA9YmvYzd30Byrc9VeGeHNHMROYlqq?= =?us-ascii?Q?nPFDJptAfa9zMhtTIBhMXA2Oih1m2UqRWXfiCMWqcvNfMe0/bu75BNrjNwoU?= =?us-ascii?Q?iZ+vggRj96Y0yBWIZp8Sq3UdTXWGlfplLbk5pxskYQh0ZyKzKldQXVW1J4B9?= =?us-ascii?Q?/vYZTo3uEZmA2wNM4GtVGe0aZfGCoOlikny1PLSzzVpdVx02ro4rPKrqGC7l?= =?us-ascii?Q?5iOhIU1F65YifYSh5VWa3eIaK8ZalDzCyrNgACeUkNTsbaLjb39P1znx63Z/?= =?us-ascii?Q?EoAvlW12F4rMuX4ljcBdFOtrYFa+8MqWSlLaNkoRRb1gpMVU3g1qJIZ07vrQ?= =?us-ascii?Q?oKyoDvF/mA/b/BXMPm8odn9kBb+AZQE86K8AGJFH70uVn8dUzCcZf/n9e4VJ?= =?us-ascii?Q?aOgCZ59G7pu0R6NYA0WnsiwB92nW4aHKSaPMBBqZtA9WyjqAjlO3Oqr84HAp?= =?us-ascii?Q?/kl8DaARTD0o6A1uSUQ9z258VQBtPTfPIyDixt0+zTTzGnhIqiox3xnOsG/K?= =?us-ascii?Q?ZochSCts0zeDhzzaByt12zF2x+DyG5XLFJlanZwJ6EqAIgz962TTTXhyXN1a?= =?us-ascii?Q?tGLShNZGQeTHPOKdb6chqviEv+9OPgUSKfgFo1pEWz0oPfTxBBUwx5rj26H2?= =?us-ascii?Q?LeM9hbnOtUneTez728ytsnwcTyHeLcur/cmHDmqLEukMhc2PQt5JaDmouhHt?= =?us-ascii?Q?Zt6AOWuzAf2iiTEu7+t+KZEylfWpz/pzjBIr4VqR1B7YW2uXybdvN96fhoAf?= =?us-ascii?Q?VNvB3osEKMpATx+Ev6fgQ4aqQdbRHZynPXPb2vV8GzkPWjmq0UYrcEvMYFl+?= =?us-ascii?Q?eu57ABAQQKyYvHrhEsWHo4c2EqZYdtv/CGnqiac4olHdTffhvZFGyGhhxNER?= =?us-ascii?Q?KLfJPbknEl5Z9R5Stnm9vLadDiJCNxMM6kPxYhluSzVJJgyFHhdoO3RGissr?= =?us-ascii?Q?itwR1A=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026)(7416014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 09:29:20.4242 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 38dd6108-a5fe-4e78-d322-08de54188fff X-MS-Exchange-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: DS3PEPF000099DD.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PPF84B7B0C96 Memory access and ALTP2M are two seperate features, while both depending on helper xenmem_access_to_p2m_access(). So it betters lives in common p2m.c, other than mem_access.c which will be compiled out when VM_EVENT=n && ALTP2M=y. Guard xenmem_access_to_p2m_access() with VM_EVENT || ALTP2M, otherwise it will become unreachable when both VM_EVENT=n and ALTP2M=n, and hence violating Misra rule 2.1 We also need to move declaration from mem_access.h to p2m-common.h An extra blank line is inserted after each case-block to correct coding style at the same time. Signed-off-by: Penny Zheng Acked-by: Jan Beulich --- v1 -> v3: - Guard xenmem_access_to_p2m_access() with VM_EVENT || ALTP2M - Move declaration from mem_access.h to p2m-common.h - refine commit message --- xen/arch/x86/mm/mem_access.c | 36 -------------------------------- xen/arch/x86/mm/p2m.c | 40 ++++++++++++++++++++++++++++++++++++ xen/include/xen/mem_access.h | 5 ----- xen/include/xen/p2m-common.h | 3 +++ 4 files changed, 43 insertions(+), 41 deletions(-) diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c index e6b609064c..e55e53f44c 100644 --- a/xen/arch/x86/mm/mem_access.c +++ b/xen/arch/x86/mm/mem_access.c @@ -298,42 +298,6 @@ static int set_mem_access(struct domain *d, struct p2m_domain *p2m, return rc; } -bool xenmem_access_to_p2m_access(const struct p2m_domain *p2m, - xenmem_access_t xaccess, - p2m_access_t *paccess) -{ - static const p2m_access_t memaccess[] = { -#define ACCESS(ac) [XENMEM_access_##ac] = p2m_access_##ac - ACCESS(n), - ACCESS(r), - ACCESS(w), - ACCESS(rw), - ACCESS(x), - ACCESS(rx), - ACCESS(wx), - ACCESS(rwx), - ACCESS(rx2rw), - ACCESS(n2rwx), - ACCESS(r_pw), -#undef ACCESS - }; - - switch ( xaccess ) - { - case 0 ... ARRAY_SIZE(memaccess) - 1: - xaccess = array_index_nospec(xaccess, ARRAY_SIZE(memaccess)); - *paccess = memaccess[xaccess]; - break; - case XENMEM_access_default: - *paccess = p2m->default_access; - break; - default: - return false; - } - - return true; -} - /* * Set access type for a region of gfns. * If gfn == INVALID_GFN, sets the default access type. diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index 759f3273d3..8d34357bcb 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -2203,6 +2203,46 @@ void p2m_log_dirty_range(struct domain *d, unsigned long begin_pfn, guest_flush_tlb_mask(d, d->dirty_cpumask); } +#if defined(CONFIG_VM_EVENT) || defined(CONFIG_ALTP2M) +bool xenmem_access_to_p2m_access(const struct p2m_domain *p2m, + xenmem_access_t xaccess, + p2m_access_t *paccess) +{ + static const p2m_access_t memaccess[] = { +#define ACCESS(ac) [XENMEM_access_##ac] = p2m_access_##ac + ACCESS(n), + ACCESS(r), + ACCESS(w), + ACCESS(rw), + ACCESS(x), + ACCESS(rx), + ACCESS(wx), + ACCESS(rwx), + ACCESS(rx2rw), + ACCESS(n2rwx), + ACCESS(r_pw), +#undef ACCESS + }; + + switch ( xaccess ) + { + case 0 ... ARRAY_SIZE(memaccess) - 1: + xaccess = array_index_nospec(xaccess, ARRAY_SIZE(memaccess)); + *paccess = memaccess[xaccess]; + break; + + case XENMEM_access_default: + *paccess = p2m->default_access; + break; + + default: + return false; + } + + return true; +} +#endif /* VM_EVENT || ALTP2M */ + /* * Local variables: * mode: C diff --git a/xen/include/xen/mem_access.h b/xen/include/xen/mem_access.h index 4de651038d..8e7d9ea2e3 100644 --- a/xen/include/xen/mem_access.h +++ b/xen/include/xen/mem_access.h @@ -73,11 +73,6 @@ typedef enum { /* NOTE: Assumed to be only 4 bits right now on x86. */ } p2m_access_t; -struct p2m_domain; -bool xenmem_access_to_p2m_access(const struct p2m_domain *p2m, - xenmem_access_t xaccess, - p2m_access_t *paccess); - /* * Set access type for a region of gfns. * If gfn == INVALID_GFN, sets the default access type. diff --git a/xen/include/xen/p2m-common.h b/xen/include/xen/p2m-common.h index f0bd9a6b98..bd4169caee 100644 --- a/xen/include/xen/p2m-common.h +++ b/xen/include/xen/p2m-common.h @@ -43,5 +43,8 @@ int __must_check check_get_page_from_gfn(struct domain *d, gfn_t gfn, bool readonly, p2m_type_t *p2mt_p, struct page_info **page_p); +bool xenmem_access_to_p2m_access(const struct p2m_domain *p2m, + xenmem_access_t xaccess, + p2m_access_t *paccess); #endif /* _XEN_P2M_COMMON_H */ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Jan 15 09:33:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 09:33:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204526.1519179 (Exim 4.92) (envelope-from ) id 1vgJja-0002yK-2k; Thu, 15 Jan 2026 09:33:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204526.1519179; Thu, 15 Jan 2026 09:33: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 1vgJjZ-0002yD-WA; Thu, 15 Jan 2026 09:33:41 +0000 Received: by outflank-mailman (input) for mailman id 1204526; Thu, 15 Jan 2026 09:33:40 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgJjY-0002y7-UC for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 09:33:40 +0000 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [2a00:1450:4864:20::32d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 459a920f-f1f5-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 10:33:38 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-4801c314c84so1417895e9.0 for ; Thu, 15 Jan 2026 01:33:38 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af6fca57sm4532916f8f.42.2026.01.15.01.33.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 01:33:37 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 459a920f-f1f5-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768469618; x=1769074418; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=/99ddwQSI5EW2LBegFhid5W2imJC03ePbUzWYJ3u+OI=; b=UzrEXd6CtkKZ0unA+60rrEsP0xg6K5nojVePl4vqIsM9QDe46k5nv/XWrlDyv2EA3B +Pdz2Hq8ZnXVM1EPs0YM0T9q1jegYi7OF3ZEBG3PpLODv1cBysqEtSRnksF8Pw4ctBEm szsQ23oDmEkgluZrTZ31pAZvjgVXg6SD0239kF4h6t1cYplEI4M0RPQES/GNVUBSzooO VZxNBALQ01L+sWBbbtOWXP1lFoDUz8AkGqpehg9DiNsqA0UeaAEICcwhxjQZt0lEIPyb gjzI65d8+WyoxHyi7Ipyy5Bw8Gz2uy6a4dADhcja+phBEj+kLgn0jodyd/ZE+eUPF1vT W4wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768469618; x=1769074418; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/99ddwQSI5EW2LBegFhid5W2imJC03ePbUzWYJ3u+OI=; b=Rn/xWB5bMthTJf1NudzkfBRDOXykBppT7eNQQ1WaK97ywdPkVgER1CJriu9ldd729g Y8QceKJ8Oe6pufCGKjyjNpnxi+iejBt50rEtG+sxinulsWL0HBd8UEjD8hyiBmPHy1Oo hDuszCLJ5IoK3e+fvn82qQ5j6qnelWkC/XW++G+eY1nOC/ILxMkIyl/araupvjHL5Q4W GkMqyAj0jKdVM9Opf/NW56GXwCKZeYjHLy0iATqcC4zKOeLgsT88FEEu0co5p7BUJ55v AMDE2u8iJeUyJ5N+D5ACTae3BvWeEkkaR7rJbCZir2gtCKXHKaCb0Yn+NeA3K8FTURoR peVQ== X-Forwarded-Encrypted: i=1; AJvYcCUaaMTq7CSfgkfby/ABBC/cqTA2jss608jMwZgziCsoinF7OLd3Uz7C3EPJUdQo5wpGOL6zanoG0Gs=@lists.xenproject.org X-Gm-Message-State: AOJu0YwHE0GSPFBkYH0M8pgLNWdRkQt0bJ8DdnL4ke0hg5+d4+bzGSuv jiSghi3jnQOQiav2dqVhO2ymglWYWGFYLPIW+G3T/MKac54iUIHakH1VO4BqJJgBXg== X-Gm-Gg: AY/fxX7K/eBgd7jZ6I0sZVk6VYqel84mRw00DEXdeLKIMMaR4qhX7fLUOSlk4+LHSyO YyVXqtNqsqoWWRfNxQr2+3lqZP9SaZgb/iV8LlRjeYaxXmsi4XQl76ZlLj+3AODPS5jUjFPpzJn XDOJiRxGsn80yE487mJxQqZx8LYNHSqZGZG2qHJfYG4JX2pb1RHBj+1TD4VG5zIPogGTBzU9N/D D++dbcwfbk7paliGJ1DfZswUH3xhQ97GMhlYiN72CbGJOtNpn+yFBda1R1sMz0YOVNObe0kX9L7 XeKOXQ7hCyDWHIT2HW9nOGx7YPzHlXOuea6uTeygdJZKlMt1iyqbPD0/ruK4rNWsZwU84EX8VLC aTwUfaV7znipWlAbbSmuUOc7ryFp05G3ZA0sdSlqwF0HLDLvtXzUz6xF0cnfYqxXtZCZE3eWYXL jAG7LMeHjX0Rs5I/JMWiuT1S9aJqafvSg2+NOSeigToMkZzHFfIQhZ2940mlhab+PQKd7ZBTHRB H8= X-Received: by 2002:a05:600c:8217:b0:477:7bd2:693f with SMTP id 5b1f17b1804b1-47ee3317131mr61238015e9.6.1768469618114; Thu, 15 Jan 2026 01:33:38 -0800 (PST) Message-ID: <29c2d1dc-23fb-403e-bb03-d8c2f32424e6@suse.com> Date: Thu, 15 Jan 2026 10:33:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver To: Oleksii Moisieiev Cc: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "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 14.01.2026 19:29, Oleksii Moisieiev wrote: > @@ -1107,6 +1115,15 @@ affinities to prefer but be not limited to the specified node(s). > > Pin dom0 vcpus to their respective pcpus > > +### scmi-smc-passthrough (ARM) > +> `= ` > + > +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 and > +SCMI nodes removed from Dom0/hwdom device tree. > +(for example, thin Dom0 with Driver domain use-case). > + > ### dtuart (ARM) > > `= path [:options]` I appreciate missing doc for a pre-existing cmdline option to be introduced, but: Why here (in two ways)? First, why in this patch, without it even being mentioned in the description? And why in the middle of options starting with 'd', when the entire file means to be sorted? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 09:37:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 09:37:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204541.1519189 (Exim 4.92) (envelope-from ) id 1vgJn9-0003cO-KD; Thu, 15 Jan 2026 09:37:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204541.1519189; Thu, 15 Jan 2026 09:37: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 1vgJn9-0003cH-HF; Thu, 15 Jan 2026 09:37:23 +0000 Received: by outflank-mailman (input) for mailman id 1204541; Thu, 15 Jan 2026 09:37: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 1vgJn8-0003as-A7 for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 09:37:22 +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 c971b441-f1f5-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 10:37:20 +0100 (CET) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-430f3ef2d37so530494f8f.3 for ; Thu, 15 Jan 2026 01:37:20 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af6b2c76sm4739552f8f.26.2026.01.15.01.37.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 01:37:18 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c971b441-f1f5-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768469839; x=1769074639; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=/+tVhBx5vAnKgWDp6CS4Wex3Nh93uNmjlZLHEUL/zTY=; b=C1SgRQ3NAQnNgFgs2IbSNwtnUqZiYEylMBHuFbbFp5hc0pmPrJnvNjCr8f3JF/n7Di lHaQQh50RvZrzZp9C4X7OYydHf6bX2TbAh6OiVFpbyBW4oGSjy1RdO2r4/JEXIUsOgZY uYqCrdWdn9NB8ftavlyu9K56uEn35066WDmpZ0PpS6yz0MVXTez3Z9p6Ffy0kpMrrDjB BUWyI/1fIbJ6awMz8dm+tNrKJNGPK1zMK9d6i2KyiWk0jQUFXjYjK22dLAx0jejEh9Hq aezEu4p3j3AFAxhbiYgeGJ/lupYeuidPH9zySa3Hy3SQlZ1J9puGu8jhgrblKKWX3akC mmzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768469839; x=1769074639; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/+tVhBx5vAnKgWDp6CS4Wex3Nh93uNmjlZLHEUL/zTY=; b=juoS11t/Z7bpEnwzMC3zxLaV8N824oXcYGbM+DrpmNxIygeTnQ0m0mJVy32FCMFSSv RRIMBgmzw8M0Q6b9ZFwcqC2wbnJZU7njUSv/jtWEErw7eSM7ySN7t8lFO7KWeJNPPEH0 iPD6YntV4LtAShQd3O+5hlcriy+kpjXRSL4alKQnR387vaKE+OJwt0dDp+KBME0rsIyA Xfy44Y6O32OdhRF0rE6tJvPRM/eR/0MOAtnhVJV/e5WSkfiidFcY2uhLA/WvxemYvhhh 0Wj3bmVp6EaCiQgdU1S7LqJwAoQ3JVIlhQEFB9kHoD2tAaPA6Kxrv8rq12PcDq5emZdc p4Vg== X-Forwarded-Encrypted: i=1; AJvYcCXCIZrsfoRjyfHvycTfcMxU9ZKCPYHEOX5nYBldFt8SRH4kaPzXEo+ek/ZeHbAUhfyD3rO/Wj6jd/M=@lists.xenproject.org X-Gm-Message-State: AOJu0YzMvzZh0AyCOcGD4AG9WREu52DXGgdnArZZz4o5lY99ZRCDVrg2 RKJl0Iv0zFYXImT48rh3NxB5+4FxBVsQVDhUZ/VW0kqgvFeMYRZ2fFfbFjdGY5ebYA== X-Gm-Gg: AY/fxX5biyA57hyHCZ/damO/WEd0c7y/HgdYB/hhbUBUTdeP2yyg+XR1INLy+uRfZ4o bfN4uE6E3jRnUwbiz0RC5bIa9mpP6R7ceML4z7JgcJJumW+a3XtuSEt6gqJZaP0aFjqdF5xo38/ 1V4uIFuKivTvOqn912FnOqYP0gpUgymlbU8vBLBSQeuvx9sQU5uo6vbQ4+YZBYIcFgmfz0FfrHb veYbbHL2xugMBZmDf6Zt/J2RNojPKBNI4Xh54BywvkB3dWJii+ii2ZkokDLAo1Rk3Gpag1W+iFL wDr5dl2gfiiY2fh8j2w2Gn30WqbBZsVHpenGkmVWd7jms4gdkV7O9XZC+JJ6RlkmKqvsYfjUwCt 90fpqj4DpLNyRyPzhqwP9nNSGYFnZDzejoaNLTKGhnWLJ8ioI4HGWfjfKeSBvsZjxFeA3xFx/Fi VQN1gHFre1+cDsLQH6zBvPjtzXiTvWTyBk12yykwot70oEmQ/9E8PpiePYGDAeINYxjOWpyXjDm oMkZ9w7au6fyA== X-Received: by 2002:a05:6000:40dd:b0:42b:2dfd:5350 with SMTP id ffacd0b85a97d-4342c570dffmr7850209f8f.56.1768469839292; Thu, 15 Jan 2026 01:37:19 -0800 (PST) Message-ID: <7d67f3a8-eec3-4942-ba4d-88e7ca35e201@suse.com> Date: Thu, 15 Jan 2026 10:37:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/6] xen/x86: move declaration from mem_access.h to altp2m.h 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, jason.andryuk@amd.com References: <20260115092841.2651224-1-Penny.Zheng@amd.com> <20260115092841.2651224-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: <20260115092841.2651224-2-Penny.Zheng@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 15.01.2026 10:28, Penny Zheng wrote: > Memory access and ALTP2M are two seperate features, and each could be > controlled via VM_EVENT or ALTP2M. In order to avoid implicit declaration > when ALTP2M=y and VM_EVENT=n on compiling hvm.o/altp2m.o, we move declaration > of the following functions from to : > - p2m_set_suppress_ve > - p2m_set_suppress_ve_multi > - p2m_get_suppress_ve > Potential error on altp2m.c also breaks Misra Rule 8.4. > > Signed-off-by: Penny Zheng > Reviewed-by: Jan Beulich > Reviewed-by: Jason Andryuk > --- > xen/arch/x86/include/asm/altp2m.h | 10 ++++++++++ > xen/arch/x86/include/asm/mem_access.h | 10 ---------- > 2 files changed, 10 insertions(+), 10 deletions(-) Tamas - can we please get an ack here? I guess I'll time out on waiting for one in a day or two. Penny - may I remind you that it is on you to chase missing acks? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 09:37:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 09:37:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204543.1519199 (Exim 4.92) (envelope-from ) id 1vgJnE-0003vw-Qd; Thu, 15 Jan 2026 09:37:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204543.1519199; Thu, 15 Jan 2026 09: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 1vgJnE-0003vp-NI; Thu, 15 Jan 2026 09:37:28 +0000 Received: by outflank-mailman (input) for mailman id 1204543; Thu, 15 Jan 2026 09:37: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 1vgJgT-0007JZ-VF for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 09:30:29 +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 d49c5a28-f1f4-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 10:30:29 +0100 (CET) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-6505cac9879so1079101a12.1 for ; Thu, 15 Jan 2026 01:30:29 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b876b6865desm369905966b.12.2026.01.15.01.30.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 01:30:27 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d49c5a28-f1f4-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768469428; x=1769074228; 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=T7lH+Zu9fWG8FmlF6j1ldxjuSpIosPg1695HWnwC8qg=; b=NaaTHTgiRKgY6EA9HxbTDNfAgIR6hHtWLmLyv0lRz6tRJJypHausRf+jq50fVZ7gHA P9xWXpLlEHfrc/G5Sinzp6GrqukiSpPvuJzjtt1cxDRYn5094/Xhc/Dd8hE5pTBHfATC /E0ueVWpcINxs4erHSpAjz1jv007He1+UwbRZsQVA5y1TEnG47YhSkQ4iUIsZcr5MEpu 4+ghVdVeLYj6FKoEE4hvvegr3G/maNGNui++b0RHtl4MHJ7yw3BrUtjUD1wsJ94Ozk5h Sd9MJcrXUWxjSjkWgLrAoAvczgU7ok4QJNSfxEyfK5my3nybWHD7hBO1cg2DRVwVlfkv XQtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768469428; x=1769074228; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=T7lH+Zu9fWG8FmlF6j1ldxjuSpIosPg1695HWnwC8qg=; b=f2WuwoaR3PStnc+PPGL0Ki5T2yMvP5O1SiBXJ3Dh4sf5lDipasxjW21Adr3TKppJAY +FwwfMvKHd6vg5mLZZn+vk4DnA4mL+TQm7yPQfjnkNtqcH9vNBTzZfzLUFme5mCjIzzi yViQ7rakaCmgz7kaQm+YBunMlBeASRsbevM+l0tbPiLAaJ+vT9wSW79Hu/zwFfHUEA8N v2whenZtNOsWFGYsDeTxvYPlNt3B+BiRTcKlc/1zseH/7O3HPNTwMG+QEhJlsgosODcT vpSTQ20DMAT7ylrgadwtoidCNsK6i/ZZSRnQkJNNvLEy3YZhvuMhLoQ0gcqzXAl60F66 3b6Q== X-Forwarded-Encrypted: i=1; AJvYcCUabwvkavFN50YKOtACGaMagH6GFswf1pWPfaRYPr6a4UdMuZjFbW313wH66Q+6pASa6RI+98Iz8AI=@lists.xenproject.org X-Gm-Message-State: AOJu0YxoJefSnwbrzn1ydTDFMVXwGaT0BlMRSQ7o3JMKEyPzNaqhtRJ3 MyjrgoybMfiZYdvLN3UaEBENgdlUU291n7/dcBQ6EX4CN3RGZoCduIbL X-Gm-Gg: AY/fxX4tLDtpzuzvGd7RS6sToJrJHKASotxwp+M1OydxjvtlmiZU3B9OFvdso7/+H7X O4ih+u+wQQjGJlGqmPAZ4mQV+aM7Uak+WyDiXhXJmR/FFkDgY5QqFNwI5dIiwWxPPv/lH7TlV+M 6/97W98hjW4b3BeDDRBWZu6SfDVy64cH5HZX1E80NdxN66Bzeovfi9svYWqTN/lzk1tBUeyflRq 3lRKoDCqcP4L8+XxC3YrNEdyaGu1WrBq78Q17TZwfSy3BU7/zXGdbSHNEphcHvIdN45aMDlIqat Dr2m0uIybokDw711z0Ikd77fXP/HMn2FI3OxLIz8EXWaC0Pg0efg5ApJO68IwXPSG92Nu5smdaj iVxeLMdL4+hXcuvN0erS1AjYROpTA8fEp1PHPrCO8nIazcPjmY6vyMO5z1RVEB/7Pg5bYc5ZdCP 49Op+EY6DXnluT5MpdzLmEYEB44Qt5I9yagtLhuPE98P/TqCQortxSqEPbZY/lyCM= X-Received: by 2002:a17:907:6d27:b0:b83:3716:cd52 with SMTP id a640c23a62f3a-b87676a6a4bmr421703266b.24.1768469428162; Thu, 15 Jan 2026 01:30:28 -0800 (PST) Message-ID: <477dfa23-7b64-4e2b-9896-9af389e33ceb@gmail.com> Date: Thu, 15 Jan 2026 10:30:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 08/15] xen/riscv: introduce vtimer_set_timer() and vtimer_expired() 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: <8cd3efa488b3da2a6751c92d20bbfeb87b3ba39a.1766595589.git.oleksii.kurochko@gmail.com> <4e18e4fc-de62-44fc-8ea0-517f6c7ef47f@gmail.com> <62c22b34-cbad-40f2-a367-ba5fd8d11b51@suse.com> <5c6eff93-0db7-4382-8365-6b32b17f5f4d@gmail.com> <8fa84e68-72b6-4578-9c3b-70d85d268c53@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <8fa84e68-72b6-4578-9c3b-70d85d268c53@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/15/26 8:52 AM, Jan Beulich wrote: > On 14.01.2026 16:59, Oleksii Kurochko wrote: >> On 1/14/26 3:57 PM, Jan Beulich wrote: >>> On 14.01.2026 13:27, Oleksii Kurochko wrote: >>>> On 1/13/26 4:12 PM, Jan Beulich wrote: >>>>> On 13.01.2026 15:44, Oleksii Kurochko wrote: >>>>>> On 1/8/26 11:28 AM, Jan Beulich wrote: >>>>>>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>>>>>> + { >>>>>>>> + stop_timer(&t->timer); >>>>>>>> + >>>>>>>> + return; >>>>>>>> + } >>>>>>>> + >>>>>>>> + set_timer(&t->timer, expires); >>>>>>> See the handling of VCPUOP_set_singleshot_timer for what you may want to >>>>>>> do if the expiry asked for is (perhaps just very slightly) into the past. >>>>>> I got an idea why we want to check if "expires" already expired, but ... >>>>>> >>>>>>> There you'll also find a use of migrate_timer(), which you will want to >>>>>>> at least consider using here as well. >>>>>> ... I don't get why we want to migrate timer before set_timer() here. >>>>>> Could you please explain that? >>>>> Didn't I see you use migrate_timer() in other patches (making me assume >>>>> you understand)? Having the timer tied to the pCPU where the vCPU runs >>>>> means the signalling to that vCPU will (commonly) be cheaper. >>>> I thought that migrate_timer() is needed only when a vCPU changes the pCPU >>>> it is running on to ensure that it is running on correct pCPU after migrations, >>>> hotplug events, or scheduling changes. That is why I placed it in >>>> vtimer_restore(), as there is no guarantee that the vCPU will run on the >>>> same pCPU it was running on previously. >>>> >>>> So that is why ... >>>> >>>>> Whether >>>>> that actually matters depends on what vtimer_expired() will eventually >>>>> contain. Hence why I said "consider using". >>>> ... I didn't get why I might need vtimer_expired() in vtimer_set_timer() >>>> before set_timer(). >>>> >>>> vtimer_expired() will only notify the vCPU that a timer interrupt has >>>> occurred by setting bit in irqs_pending bitmap which then will be synced >>>> with vcpu->hvip, but I still do not understand whether migrate_timer() >>>> is needed before calling set_timer() here. >>> Just to repeat - it's not needed. It may be wanted. >>> >>>> Considering that vtimer_set_timer() is called from the vCPU while it is >>>> running on the current pCPU, and assuming no pCPU rescheduling has >>>> occurred for this vCPU, we are already on the correct pCPU. >>>> If pCPU rescheduling for the vCPU did occur, then migrate_timer() would >>>> have been called in context_switch(), >>> Even if the timer wasn't active? >> Yes, migrate_timer() is called unconditionally in vtimer_restore() called >> from context_switch(). migrate_timer() will activate the timer. > Which is wrong? I don't know, based on the comment above migrate_timer(): /* Migrate a timer to a different CPU. The timer may be currently active. */ it doesn't mention that it shouldn't be called if the timer wasn't active. All around other cases where migrate_timer() is used I don't see also that anyone checks if a timer is active or not. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Jan 15 09:44:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 09:44:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204579.1519209 (Exim 4.92) (envelope-from ) id 1vgJtZ-00067d-Dy; Thu, 15 Jan 2026 09:44:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204579.1519209; Thu, 15 Jan 2026 09: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 1vgJtZ-00067W-Ar; Thu, 15 Jan 2026 09:44:01 +0000 Received: by outflank-mailman (input) for mailman id 1204579; Thu, 15 Jan 2026 09:44: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 1vgJtX-00067Q-Vv for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 09:43:59 +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 b218b89b-f1f6-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 10:43:50 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-42fbc305552so600082f8f.0 for ; Thu, 15 Jan 2026 01:43:50 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af6fc8dcsm4810165f8f.40.2026.01.15.01.43.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 01:43:49 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b218b89b-f1f6-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768470229; x=1769075029; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=ym6iT70Yab7br6NcL95LFB2EK7PsN+GafLw66limSd0=; b=WeulC2/yOGP1S7c5z1TsxzfwaPmYrV0DADFR//m5ZKq6efPTKkJsgW8R8UTm2D3ZvI JfCwdcUddpWhUHl+sn2jvoeTIjXj0RbI376wKzwK5K7fCXkitoa4CT6dsVDPvdp/NEYC hH5l+nD/jW2MdoaXTUeZ8c7heT0AmgLa9MlXtdrrM7+28meZwd0nymZHX5U7ct3EOo/K tr/vcgCr/dMw7Yb7V2SxhkOyPPyhgiX8g3aEmtaxD9+uFmoIW/Xy9NL70vYBt5Nb9ynu Ycxi10b6+KUtD2ZXEzhFlnqZu+Bz3MHgj4ga/KEMFW+eqIVPM6RkKoR14FMkJUFlanBy U5Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768470230; x=1769075030; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ym6iT70Yab7br6NcL95LFB2EK7PsN+GafLw66limSd0=; b=ke6a3QphFyvnGNNLI059S6hzCD9QV54Nr64dyABNzvqQ2AJfERrJ+QAovmLRGAExjA Ml+dNG9lXAo920WetBJh1lMBnJvDEbzz7iKeRYHIqQ9k9HA7zJonpb4GNpFIlnDAgSTG x4UGLv6iM+Mzr0e/XhA9yLbs3/QnfsZLxPKqxpOnh3MUehFahIlJ2kzImWe/nNik3qU2 fgJtbunxAVkEtMKf/1kxGnFn/55B5NxvLxHhgjcYjxu0BTk4NdyXSw7F7pki/CO+/K3v HYzNGeRAd6Ub/QE2nrXVn83K4tLXBPlZTua3stiZdfXGTPNcqO+Fd19i3oL/CtFmD0bf YXog== X-Forwarded-Encrypted: i=1; AJvYcCVSaABLQ7Evk6gpwGrpMPp/64HU8/JIeJwVGhxuv1fmDr6lFGxwpBE3ZtuEar50Bg67596Dfv0VDY4=@lists.xenproject.org X-Gm-Message-State: AOJu0YxpltcDfY+bnIzuNVUg27cjwBtJ5T9hU47wq4ts9n+eVlfGoGC1 4kT5T201O1i4GR8JBTMPdRAuTQ+AKlKhnVtFcQTaLtZ07AdyCDGddT43C98X9J+ZOA== X-Gm-Gg: AY/fxX6nBPjTjSjpIsuIdXFipbyH+iNEMMOGaNWRVw+K2OfyvE+99phMZ5mpPVEb8IV nEgFkH5sN+2pK8r4t6vugPF18zslK7WHkiNpcOjs1DtBjrhIOXLxIg9sRwvid1b0SzMNm+b8QtK 5zbYAXz+yhUy1+fn3DFYXpzRXcip4FcUkBswmwMKSBrumHJS1PI3yZzfWG3xBJJWEO2jsvagWmN BqnpXnXGBgLnt9iueL7YlDo4TEfiNtUy8IAzYR90lUUnKXATKZf9dWWtuzqW8XtbRHJ7utX5zVq PdhrtN3I0IZO4lpVCNE/13DMrEu+BMAzxA5cSLNYh79hNb/GjgoXhrsAcy69orYoyKqHwNIQBRv w0O9TwBYzF8UbiSYFigoDwnUt9CzLuYxy9D4HNRzAeekaJ6JdYm2CF8n7G3ewlKSwls+i4RKExV mkTJX5QWKi7pvM+yo3+sNFublBjbu2hm0Y/5rlZc92ACpM8HXIF3jRYmOdlVh6BYG7GvvOKGV25 GTl7y7PMozOYA== X-Received: by 2002:a05:6000:4301:b0:431:6ba:38ac with SMTP id ffacd0b85a97d-4342c3f0fcemr6936879f8f.4.1768470229637; Thu, 15 Jan 2026 01:43:49 -0800 (PST) Message-ID: Date: Thu, 15 Jan 2026 10:43:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 6/6] xen/vm_event: consolidate CONFIG_VM_EVENT 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 , Tamas K Lengyel , Alexandru Isaila , Petre Pircalabu , xen-devel@lists.xenproject.org, jason.andryuk@amd.com References: <20260115092841.2651224-1-Penny.Zheng@amd.com> <20260115092841.2651224-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: <20260115092841.2651224-7-Penny.Zheng@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 15.01.2026 10:28, Penny Zheng wrote: > 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. > > Although CONFIG_VM_EVENT is right now forcibly enabled on x86 via > MEM_ACCESS_ALWAYS_ON, we could disable it through disabling > CONFIG_MGMT_HYPERCALLS later. So we remove MEM_ACCESS_ALWAYS_ON and > make VM_EVENT=y on default only on x86 to retain the same. > > The following functions are developed on the basis of vm event framework, or > only invoked by vm_event.c, so they all shall be wrapped with CONFIG_VM_EVENT > (otherwise they will become unreachable and > violate Misra rule 2.1 when VM_EVENT=n): > - hvm_toggle_singlestep > - hvm_fast_singlestep > - hvm_emulate_one_vm_event > - hvmemul_write{,cmpxchg,rep_ins,rep_outs,rep_movs,rep_stos,read_io,write_io}_discard > And Function vm_event_check_ring() needs stub to pass compilation when > VM_EVENT=n. > > Signed-off-by: Penny Zheng > Acked-by: Jan Beulich > Reviewed-by: Jason Andryuk > --- > As the last commit, plz be commited either in the last, or shall be commited > together with prereq commit 8d708e98ad, 8b4147009f, dbfccb5918, ae931f63a0, > 37ec0e2b75. What do these hashes refer to? Also (assuming these might be the hashes of the commits in your private tree), as I'm pretty sure I said before, committing a series in-order is the default thing to happen. It's patches that are independent of earlier ones which may want to call out that fact, for them to possibly go in early. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 09:45:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 09:45:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204589.1519219 (Exim 4.92) (envelope-from ) id 1vgJvE-0006cP-Pm; Thu, 15 Jan 2026 09:45:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204589.1519219; Thu, 15 Jan 2026 09: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 1vgJvE-0006cI-MT; Thu, 15 Jan 2026 09:45:44 +0000 Received: by outflank-mailman (input) for mailman id 1204589; Thu, 15 Jan 2026 09:45:44 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgJvE-0006bP-6j for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 09:45:44 +0000 Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [2a00:1450:4864:20::344]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f59c244a-f1f6-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 10:45:43 +0100 (CET) Received: by mail-wm1-x344.google.com with SMTP id 5b1f17b1804b1-47ee974e230so6051465e9.2 for ; Thu, 15 Jan 2026 01:45:43 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af64a671sm4799221f8f.9.2026.01.15.01.45.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 01:45:42 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f59c244a-f1f6-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768470343; x=1769075143; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=ZjyOOHkIsXSvDmYZrojhSZYTaRaQBRh49A/U5Mb4dGU=; b=d6JVzC5L2bnp2VyR49T7UEvpIKa3/Zj1LJRxw+0DbLDLikFYIUe6JAQ/jscqmsEsqb ySzbiBeWXOShilqTHBPZJd+6gG/2xp0XJKvKD8iH/IgSV5WNlI44oSPj/H/hPESQD6K2 /7zBIjS3nwbE80f3avqSZts3GpLMFoUdg7gtLIiC5A5H0xS5lcwGL0lH/TD9sZP/IjgH zpER+wOXTU9caF1yf6J/3PPPcUz9et/cxbhTH/nEFUiipEECEZcDwGavckCYy42mtoSo hYr6QjyRUPWRzS3YhjnqJPx5wrFSHeH2Y+UjX0d165tVRfkNknY4v40J5tFAd+yRlYYe 8N+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768470343; x=1769075143; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ZjyOOHkIsXSvDmYZrojhSZYTaRaQBRh49A/U5Mb4dGU=; b=PBI/sanSS5w1vlQSKlpSAUDopSs+dfp0oPSE+qnAXQ79ZHprPUX8dcOPsn9BXIvqUj PnAtI66wpjk+jdNm3gNkjNAgx+NvrzcgC+v+ugV/H4bR0ALiMmzUICVfDbXGY23sq1FZ z1hFC6iCe5sCtC58SoFe8n6flIQYPfhXweRFaS0NEU/CaNw9aKzrd3ElIG80fHT2yZOo iQ71N1/UFU5F85Kg1iUXfozDbLfbUE8eTpcvssqhEFfjPxJHrM+Bic8DIRCWARoIH5cp aZ/DyjMqkMkWUlbXZwXaLiJlcdX0bVvSrf+4hHamCMN3i/EYW6uR3i/77sRfclzMLPTG wAbg== X-Forwarded-Encrypted: i=1; AJvYcCXU/yTGb9CwKHcIg8D3z2oP3FyHrr2TpQtXlrXMiZWK6QPbJ7aFjzB6VVY+7LWLMrVBGdJXeAn3RrA=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy0IqXcl/efi3IqQiX/iuLP2145G6JHb/p2Ez1EcL3e21CzOGq+ TnMl3VgAtNU3zCj2RZGeiC95BFuBxpsMQ/NfIjndILWGtJxDypFKPGXV2Xr2IP3bZQ== X-Gm-Gg: AY/fxX7DZKuN8PE9PkgzWkR2wseJalPQqzD+GM7YmmxbZ6evPFTHFThLj3oSuR/Mk3H iVO3EWdADy96vtcydcWmBHRdRdK15gBfxqoAf/HaE5CrvJaoHZvRvYBfTGcoDfRWV45YHtLsF2I 8a3uu2xz2wT61O8XQAptVCNPMjG1R3/xMcEVHCDVHNozq4UUcny5I64LYlQ7/Iwwo00UKdW6PUO kv6fRS9OGOSG3D3s1Ebez2PWajf7LoG7ZlTKMkTV68yNDigl7FGvLmR3qz1tyzH7kogqn12Jycg JLxweCy7jIH+KEsYyZzhMNwv3IHuEyWNEjIxZTIyKoipc4Yb6HFRMHTOSAzTQ/9jT9WNXOZW8qC OvzfDg7Ca7oIf+da+HuRysjyYIXtjCgi4c+xTRsURf+fz4jkUAOOnhjmq4so5XBWnXStaV2EdoU qcfYiTjOAwMIuGT8zqkWwnbjNSWheHbOGPnwKfbFYqfUnhs/6U5d9KPljdH8W3gLGY05xSi0Ope 9A= X-Received: by 2002:a05:600c:458e:b0:47a:7fdd:2906 with SMTP id 5b1f17b1804b1-47ee32fd0aemr52993405e9.12.1768470342813; Thu, 15 Jan 2026 01:45:42 -0800 (PST) Message-ID: <3b9c018a-aceb-4015-963c-e8854dd50efa@suse.com> Date: Thu, 15 Jan 2026 10:45:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 0/6] consolidate vm event subsystem To: Penny Zheng Cc: ray.huang@amd.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Tamas K Lengyel , Alexandru Isaila , Petre Pircalabu , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org, jason.andryuk@amd.com References: <20260115092841.2651224-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: <20260115092841.2651224-1-Penny.Zheng@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 15.01.2026 10:28, Penny Zheng wrote: > This patch serie originates from "Disable domctl-op via CONFIG_MGMT_HYPERCALLS" > [1], and focuses on consolidating vm event subsystem (i.e. VM_EVENT), and its > derived features, like memory paging, etc. > > [1] https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg200843.html > --- > Happy 2026! > Sorry for the late response to this patch serie and the domctl one. > v4 is just doing a rebase on the latest staging, and one comment fix. > I still need 2 acks for commit "xen/p2m: move xenmem_access_to_p2m_access() to > common p2m.c" and "xen/mem_access: wrap memory access when VM_EVENT=n". Is this true? I'm under the impression that strictly speaking every one of the patches needs Tamas'es ack. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 09:51:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 09:51:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204605.1519229 (Exim 4.92) (envelope-from ) id 1vgK0P-0000HN-G6; Thu, 15 Jan 2026 09:51:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204605.1519229; Thu, 15 Jan 2026 09:51:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgK0P-0000HG-CZ; Thu, 15 Jan 2026 09:51:05 +0000 Received: by outflank-mailman (input) for mailman id 1204605; Thu, 15 Jan 2026 09:51: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 1vgK0N-0000H8-OA for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 09:51:03 +0000 Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [2a00:1450:4864:20::429]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b3c898c2-f1f7-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 10:51:02 +0100 (CET) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-4327555464cso367518f8f.1 for ; Thu, 15 Jan 2026 01:51:02 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af64a650sm4874422f8f.4.2026.01.15.01.51.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Jan 2026 01:51:01 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b3c898c2-f1f7-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1768470662; x=1769075462; 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=UJRL9dWZYYSFhfbfgxjey3dNtDOXM5WXHk14eiGhqrU=; b=ZwrFxAwn8DelPCuJfDrdaeiWA5Y8E2Cb4WVRcJNgPpg+iZmPGG4iPFjMmS4TdAY70u mzk4PDh4I3Z7plsY4qjUZmiU/kSu4Lx+cLicQEGNPvhXaXRiaCaCkKcYsl64asWCh6+q lbcfY0gPsvs0S8UJd8VwmCO53YDAQjy+vsZBs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768470662; x=1769075462; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=UJRL9dWZYYSFhfbfgxjey3dNtDOXM5WXHk14eiGhqrU=; b=J5qq8tSCOzAHu/o3qoIN2qwm3XLuwp6aS8f4RJ9f1DdHNNuZMP00pFjWGcXeQpX8Pm fR2wQlhcF4pCjO4Ysaw/pH12JkEz4g24BRxCrgqvBM3jKJl9kjmNPdWrJ5hxEjmVzQJX JIaNJEh/7uuyn5H8nzQBtE4iC32edqhvxerjHf9ianeBAPuNBW0BoBOcnpZwJUsEYQaS jQQu8ZEV0yMMZG2BZK3LvAgYHgADsijPErnzwiglJ+B4zRbGWRDO7rgEZDiUV/FN2ylr nw11fHjbTnAUJdlBWfD7Zm76a74rg083YFUt4oIAfwI6Ig6KQTf2wJBv/2vADdwdvDf2 bxgg== X-Gm-Message-State: AOJu0YxdlyQamLMyfCHCDzv7jPeL8KslCHE6cm1aIahUx2QvQ+o83N80 s/TuwSlZwAuoon5/+danIWMScQgtKQc5hrsgXHKD2kE3R7RRFYvzcP5EsAnbQkBJN8B5LiCVT1I GTHsL X-Gm-Gg: AY/fxX5wXLBtNwT/eSTGmfG4x2PIoLPv9Gwge+Rugfqj1dMmrnHBrqORY79AbuDEDq9 1aFzjbqBulANs7fhHmtGaWIac/fzYRLvZFz4y5rL0MaFutGaKx5f0pLAiIr1y95aiquJWYBA/PA CaP3q3poK6ZIgHslS7jNNbYkbsqVraKwwwFy2gw/Rc8es2itOIIIyEmesPPZ0RSS+Y5XyhsySWy U/jPrBTr59QrokcpG414e1zhzzqV8ozUEuO7mQ1rNcKFM26PW25NXqXSiDgNZDA+YrfH47q0lqi RFvP097MKRB1Tvwk+5jy33guJX4jptITTuEoKEXmZDNODRSTCSzE2IMjZMaBy9hrY+5Qi8t52LG 7nC9uZfTXcqJXhEOxvXjetINxfU6Ho5Srr8FFF3QyyPUpoX7HZgJ23G8JKflwosLBEKcu59JPdG 9FUJMzhbmwVzyv9m5dXH6dSp4bg8p9DbQmc1WD0T094BdxE94ZC5d5VCtMB3fDXg== X-Received: by 2002:a05:6000:1865:b0:431:8f8:7f1e with SMTP id ffacd0b85a97d-4342c548320mr7052654f8f.48.1768470661630; Thu, 15 Jan 2026 01:51:01 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH] x86/time: Drop unused parameter from soft_rdtsc() Date: Thu, 15 Jan 2026 09:50:47 +0000 Message-Id: <20260115095047.1201825-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 Fixes: a6ed4543222a ("x86/time: pv_soft_rdtsc() is PV-only") Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné --- xen/arch/x86/pv/emul-priv-op.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c index c970e16152f4..bf3c92d9ee29 100644 --- a/xen/arch/x86/pv/emul-priv-op.c +++ b/xen/arch/x86/pv/emul-priv-op.c @@ -874,8 +874,7 @@ static uint64_t guest_efer(const struct domain *d) return val; } -static uint64_t soft_rdtsc( - const struct vcpu *v, const struct cpu_user_regs *regs) +static uint64_t soft_rdtsc(const struct vcpu *v) { s_time_t old, new, now = get_s_time(); struct domain *d = v->domain; @@ -934,7 +933,7 @@ static int cf_check read_msr( return X86EMUL_OKAY; case MSR_IA32_TSC: - *val = currd->arch.vtsc ? soft_rdtsc(curr, ctxt->regs) : rdtsc(); + *val = currd->arch.vtsc ? soft_rdtsc(curr) : rdtsc(); return X86EMUL_OKAY; case MSR_EFER: -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Thu Jan 15 09:52:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 09:52:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204616.1519239 (Exim 4.92) (envelope-from ) id 1vgK2C-0000nT-Q6; Thu, 15 Jan 2026 09:52:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204616.1519239; Thu, 15 Jan 2026 09:52:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgK2C-0000nM-N7; Thu, 15 Jan 2026 09:52:56 +0000 Received: by outflank-mailman (input) for mailman id 1204616; Thu, 15 Jan 2026 09:52: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 1vgK2B-0000nE-Df for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 09:52:55 +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 f5828dc6-f1f7-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 10:52:52 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-47d63594f7eso4478485e9.0 for ; Thu, 15 Jan 2026 01:52:52 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee27fd33dsm41426805e9.8.2026.01.15.01.52.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 01:52:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f5828dc6-f1f7-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768470772; x=1769075572; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=APisuLnU2lPssXgJmZvw0WC+h035gdi5wEOk6crb6E0=; b=fZoUURjplUn0Yu6vaqxAqGMnCQCfK0uRr/wapVVUvROeEf+Zi//45uQTpHP0SpBttT RtBBmtTVcHyYE4xmYZQrV1srNaF34DgdKLgagFia5qVyJ2+wBRe/hFRugwjKCdZXjdB2 0EVrUOXLEwoGllRpADhZ4Bk67CLvi59mQdwI1TN4izVbtNLQhjv6pymljR4FdJRgREq6 ODhz8bKpcEmQ84rVy3HU1O+44PQ9NejUz5HeSHKJAkmW0mw1b6U2oeOqTU3BLjczMM1r uksdjztcTilB3rsJJUyXV9PLnsLhytdOazlTgnFRR6lOJNXsIVzQnM0zhAqXfxtEeP7E 7swA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768470772; x=1769075572; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=APisuLnU2lPssXgJmZvw0WC+h035gdi5wEOk6crb6E0=; b=OiunRPd7Cu5occT357+NzS7YhJnpdYyMGlagNNu5HEwASqR3QIJ6KzFmWctRxv/hSU xmQff1by2cPX5zqpIKU7IuM74x4PBdkWv4vvLs8sNIE006jNfVTrTKsfYzx5leLumOSo d2ELutJ9GnFGcqJ47jPzPLa3V3dTUONhPKPl/pS2uCpJIAUw7do1XDFYYwfmFdIPArjf fS7+6Vw5tGAWXVJoVpl4hLXJBahNZQSQdIjidW+m/FF+zDRCvDFeErYlpzc1OY9KaJcR /FkiDlM0Pnal9KiwavgP7pTr4bxFpYHH8bAQLSwaJDo7e9tTYSATIpyGqJ1WpEx/FGkh 8QNA== X-Forwarded-Encrypted: i=1; AJvYcCVUEdmF8MTos4SeSnqYC0fkp10d5HEcV0GcMrHRiVWcyo+VdCaOEzITXLoQt97v4YQYlN+LrDxTY/s=@lists.xenproject.org X-Gm-Message-State: AOJu0YzzxpyrzTFVqwt8lWyfsR0S+qwO3t9jAsQEsnZ6reraBG8fNIOM esxcR5philUedi1r/m9qJ0vtkn8ueY3HOaT8ETR8YGpZNmTLCQ1MxUC9AG2quo/QxQ== X-Gm-Gg: AY/fxX6EfIjJJSh7eOZQEMbH28m+NJprnk4/gBgy+hJ9A7XlPy5bWJtNg2dKsCf+xFU B5QZzdaLJrSHw3MxttkhqbdjzIUrw2FFnKKDMm8bpyrawXNPkqAm8IMbV7JudZBHVrh/JBKQmz8 Um5C7dA3Hh4KUx/JT8O1u3z3Z8vAPJ5wzPtqpMM1W4kGh5tuSedxk8Ta93eeRO0MeOw8wbxvsv+ sIkq3DN8ahuFpxZoTzWj/v+6n+Oo9tjRMm47GJox8OeMiRwO6tiapIYz35mvtI4d7bnuSh6zrq3 AtPpIxPfwAqWoPBzrkG2wVW/SQT23Uh1f7uVqHRZI38SBJ+rpfzVpkGlm+W/gumvWeCk/OeNfCj ZhCrBAJAR9/ifLrTXGY+7dumyoClp8poUPQLY8tP6UuXgDRGxK0nmYQzaOkRgk+uJ18R0Ivwp7B VspAgRda/+/nl14T+6PNnVgKC2NcW1/c4ZaIDN3SNPXllscGMhdNlKJ+Y1AeapiOMwn2ZFF9sL0 e8= X-Received: by 2002:a05:600c:4e92:b0:47b:d914:98a7 with SMTP id 5b1f17b1804b1-47ee48325b1mr57930565e9.29.1768470772198; Thu, 15 Jan 2026 01:52:52 -0800 (PST) Message-ID: Date: Thu, 15 Jan 2026 10:52:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 07/15] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <7a90cc1b-b053-4b9f-91f1-d32064b1ec29@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 15.01.2026 10:14, Oleksii Kurochko wrote: > On 1/14/26 4:56 PM, Jan Beulich wrote: >> On 14.01.2026 16:39, Oleksii Kurochko wrote: >>> On 1/13/26 2:54 PM, Jan Beulich wrote: >>>> On 13.01.2026 13:51, Oleksii Kurochko wrote: >>>>> On 1/7/26 5:28 PM, Jan Beulich wrote: >>>>>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>>> By maintaining irqs_pending_mask, you can detect “this bit changed >>>>> recently,” even if the final state is 0. >>>>> >>>>> Also, having irqs_pending_mask allows to flush interrupts without lock: >>>>> if ( ACCESS_ONCE(v->arch.irqs_pending_mask[0]) ) >>>>> { >>>>> mask = xchg(&v->arch.irqs_pending_mask[0], 0UL); >>>>> val = ACCESS_ONCE(v->arch.irqs_pending[0]) & mask; >>>>> >>>>> *hvip &= ~mask; >>>>> *hvip |= val; >>>>> } >>>>> Without it I assume that we should have spinlcok around access to irqs_pending. >>>> Ah yes, this would indeed be a benefit. Just that it's not quite clear to >>>> me: >>>> >>>> *hvip |= xchg(&v->arch.irqs_pending[0], 0UL); >>>> >>>> wouldn't require a lock either >>> Because vCPU's hvip (which is stored on the stack) can't be changed concurrently >>> and it's almost the one place in the code where vCPU->hvip is changed. Another >>> place it is save_csrs() during context switch but it can't be called in parallel >>> with the vcpu_sync_interrupts() (look below). >>> >>>> . What may be confusing me is that you put >>>> things as if it was normal to see 1 -> 0 transitions from (virtual) >>>> hardware, when I (with my x86 background) would expect 1 -> 0 transitions >>>> to only occur due to software actions (End Of Interrupt), unless - see >>>> above - something malfunctioned and an interrupt was lost. That (the 1 -> >>>> 0 transitions) could be (guest) writes to SVIP, for example. >>>> >>>> Talking of which - do you really mean HVIP in the code you provided, not >>>> VSVIP? So far I my understanding was that HVIP would be recording the >>>> interrupts the hypervisor itself has pending (and needs to service). >>> HVIP is correct to use here, HVIP is used to indicate virtual interrupts >>> intended for VS-mode. And I think you confused HVIP with the HIP register >>> which supplements the standard supervisor-level SIP register to indicate >>> pending virtual supervisor (VS-level) interrupts and hypervisor-specific >>> interrupts. >>> >>> If a guest will do "That (the 1 -> 0 transitions) could be (guest) writes >>> to SVIP, for example." then the correspondent HVIP (and HIP as usually >>> they are aliasis of HVIP) bits will be updated. And that is why we need >>> vcpu_sync_interrupts() I've mentioned in one of replies and sync VSSIP: >>> +void vcpu_sync_interrupts(struct vcpu *v) >>> +{ >>> + unsigned long hvip; >>> + >>> + /* Read current HVIP and VSIE CSRs */ >>> + v->arch.vsie = csr_read(CSR_VSIE); >>> + >>> + /* Sync-up HVIP.VSSIP bit changes does by Guest */ >>> + hvip = csr_read(CSR_HVIP); >>> + if ( (v->arch.hvip ^ hvip) & BIT(IRQ_VS_SOFT, UL) ) >>> + { >>> + if ( hvip & BIT(IRQ_VS_SOFT, UL) ) >>> + { >>> + if ( !test_and_set_bit(IRQ_VS_SOFT, >>> + &v->arch.irqs_pending_mask) ) >>> + set_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); >>> + } >>> + else >>> + { >>> + if ( !test_and_set_bit(IRQ_VS_SOFT, >>> + &v->arch.irqs_pending_mask) ) >>> + clear_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); >>> + } >>> + } >> I fear I don't understand this at all. Why would the guest having set a >> pending bit not result in the IRQ to be marked pending? > > Maybe it is wrong assumption but based on the spec: > Bits sip.SSIP and sie.SSIE are the interrupt-pending and interrupt-enable > bits for supervisor-level software interrupts. If implemented, SSIP is > writable in sip and may also be set to 1 by a platform-specific interrupt > controller. > and: > Interprocessor interrupts are sent to other harts by implementation-specific > means, which will ultimately cause the SSIP bit to be set in the recipient > hart’s sip register. > > Meaning that sending an IPI to self by writing 1 to sip.SSIP is > well-defined. The same should be true of vsip.SSIP while in VS mode. I can't read that out of the text above. To the contrary, "will ultimately cause the SSIP bit to be set" suggests to me that the bit is not to be set by writing the CSR. Things still may work like this for self-IPI, but that wouldn't follow from the quotation above. >> You can't know >> whether that guest write happened before or after you last touched >> .irqs_pending{,mask}[]? > > Yes, I think you are right. > > On the other hand, if we are in hypervisor when vcpu_sync_interrupts() is > called it means that pCPU on which vCPU is ran and for which > vcpu_sync_interrupts() is called now executes some hypervisor things, so > guest won't able to update VSIP.SSIP for this pCPU. So nothing else will > change VSIP.SSIP and so h/w HVIP won't be changed by something and it is > okay to sync .irqs_pending{,mask} with what h/w in its HVIP. That is, vcpu_sync_interrupts() is called on every entry to the hypervisor? Not just during context switch? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 09:55:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 09:55:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204627.1519249 (Exim 4.92) (envelope-from ) id 1vgK4v-0001Lk-5T; Thu, 15 Jan 2026 09:55:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204627.1519249; Thu, 15 Jan 2026 09:55: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 1vgK4v-0001Ld-1l; Thu, 15 Jan 2026 09:55:45 +0000 Received: by outflank-mailman (input) for mailman id 1204627; Thu, 15 Jan 2026 09:55:43 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgK4t-0001LX-9V for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 09:55:43 +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 5a5f115e-f1f8-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 10:55:42 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-4801c731d0aso906915e9.1 for ; Thu, 15 Jan 2026 01:55:42 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee2814548sm40028775e9.9.2026.01.15.01.55.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 01:55:41 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5a5f115e-f1f8-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768470941; x=1769075741; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=1h9d9ylM04iXq4Fpgj69MFkgdTGtCbP4kNfP42K0UI4=; b=cQGjo5V5EHsbYXvTmpBGQC90JyAtNwpiigj1RSyHGmPhdixIoEtLOVf1ZgQxCHFegS ASj0pFQPeyPK/okialm5CuknrVDyG7P6M8v+/F6nykhuWf5xtk1U9HWCNdvAS9uYRpB/ McTVWnWN2ccNvUlWkdUh9eUENByjftusQqVjjkmWZmH6kHQ2Rktc9s1oT3gI+Ad1UVw0 6QJYLO/wg439KDx+5mHAh7IZdG0s05d9psV0BUVD6Sm8dYAAKWA+Skdc50IVz/HUrO65 AtjqFc0uBW2f73DNa1cDACPdS0GsD930L5zETI4Rtes6L4xxbJPDhN+q5AjEEc7KarD7 eWvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768470941; x=1769075741; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=1h9d9ylM04iXq4Fpgj69MFkgdTGtCbP4kNfP42K0UI4=; b=NKbykk6E5to7gKjMXTHEUM/6HMO1xHcVHxrlqgaRuDe5VmGE+tKRjkffkVF5HQG4Aa RkZ/IpW03WPoziXgmxizzdIDOH9wxaDk5McMWBvq9YataggjDyGDqJEDKsLlOPI5da5i NNOD9g9BHOcAKo3byyHoHqI1jvxz1eqGBla4yR2PbyPWgFt+E+1qX3xeqbQC8DBkIFGX u1gj0tpJ9a4pYeta98stFF4OVxnYJkxmN2BZZ61UBv0OFdHLQ4S+26dCRtw2AYYw/g6m YpvL1O8H17yDjOwNYbb2Ps2637B2rggM6X9OSd2DeUMJtY5RQagW0evnqSwMfbaOAB5Y T/sA== X-Forwarded-Encrypted: i=1; AJvYcCVe30jrRCZkQ5L29g5wd5WgNsXf37lulrF/qYPUVw1RuKDW/XfHUfSrrUB5vvTWl93odbFMmXvcytY=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx5SDvjKgkg10sXgMxFkUNjiLfoJFJeGbXs3uaSJ7pD+VgBNtGT C/Fom+I9x//dR1XBH7lDs1Bp86HubCqOZegBr3565NAOIAdVm4l/haMBBUzABNeYCw== X-Gm-Gg: AY/fxX6teU1y+FfJycmmB+qAAWSOqPYoS4lpwwr/WIpVwTWXrPEgwX294C9Tq5X/vp0 O8wPTfBqGzAFs2ABTf/mQK7DSFazZipUsDPnqjjdFnFEvJJrJ0ZQ3jLU/tcKTWwm89a2Pz7EnfX qca/hfr/0auKMA2RlvzOQOnidCIo3i7uDfH3xj80Y1uJNFiIDGCoKRpsTQPOOJJKSXgsu4MBBOP 5nlhtn7oHaCjsR8y8uoKzdaqDmCg9G+t81LAK8mrBuzGZvOBkIURZn93fxs9gudgYOLNnty1M4T 6sFanYRgtWzO5ARFptMIPdg4r0KxR/wWbq9FGZ0HwvNvHzQwCwdEOi1yeF7csxzz2/E8RJ6VK1E npLDX2TPFKAEWBVBP6/cpaTvFxXk5VrJF5gbuSNDKokWHFHbcdFtn053HYGpFpHq5dDA4qoT4/n Iimn4w41pwdjVBFmEB2sJ/GRvjgqpFnMTmkEJgwzvrs5P71laocXFRggQR2RJTv2UK5Xq6XqMl/ io= X-Received: by 2002:a05:600c:6287:b0:477:79f8:daa8 with SMTP id 5b1f17b1804b1-47ee3391744mr76626815e9.17.1768470941457; Thu, 15 Jan 2026 01:55:41 -0800 (PST) Message-ID: Date: Thu, 15 Jan 2026 10:55:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 08/15] xen/riscv: introduce vtimer_set_timer() and vtimer_expired() 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: <8cd3efa488b3da2a6751c92d20bbfeb87b3ba39a.1766595589.git.oleksii.kurochko@gmail.com> <4e18e4fc-de62-44fc-8ea0-517f6c7ef47f@gmail.com> <62c22b34-cbad-40f2-a367-ba5fd8d11b51@suse.com> <5c6eff93-0db7-4382-8365-6b32b17f5f4d@gmail.com> <8fa84e68-72b6-4578-9c3b-70d85d268c53@suse.com> <477dfa23-7b64-4e2b-9896-9af389e33ceb@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: <477dfa23-7b64-4e2b-9896-9af389e33ceb@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 15.01.2026 10:30, Oleksii Kurochko wrote: > > On 1/15/26 8:52 AM, Jan Beulich wrote: >> On 14.01.2026 16:59, Oleksii Kurochko wrote: >>> On 1/14/26 3:57 PM, Jan Beulich wrote: >>>> On 14.01.2026 13:27, Oleksii Kurochko wrote: >>>>> On 1/13/26 4:12 PM, Jan Beulich wrote: >>>>>> On 13.01.2026 15:44, Oleksii Kurochko wrote: >>>>>>> On 1/8/26 11:28 AM, Jan Beulich wrote: >>>>>>>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>>>>>>> + { >>>>>>>>> + stop_timer(&t->timer); >>>>>>>>> + >>>>>>>>> + return; >>>>>>>>> + } >>>>>>>>> + >>>>>>>>> + set_timer(&t->timer, expires); >>>>>>>> See the handling of VCPUOP_set_singleshot_timer for what you may want to >>>>>>>> do if the expiry asked for is (perhaps just very slightly) into the past. >>>>>>> I got an idea why we want to check if "expires" already expired, but ... >>>>>>> >>>>>>>> There you'll also find a use of migrate_timer(), which you will want to >>>>>>>> at least consider using here as well. >>>>>>> ... I don't get why we want to migrate timer before set_timer() here. >>>>>>> Could you please explain that? >>>>>> Didn't I see you use migrate_timer() in other patches (making me assume >>>>>> you understand)? Having the timer tied to the pCPU where the vCPU runs >>>>>> means the signalling to that vCPU will (commonly) be cheaper. >>>>> I thought that migrate_timer() is needed only when a vCPU changes the pCPU >>>>> it is running on to ensure that it is running on correct pCPU after migrations, >>>>> hotplug events, or scheduling changes. That is why I placed it in >>>>> vtimer_restore(), as there is no guarantee that the vCPU will run on the >>>>> same pCPU it was running on previously. >>>>> >>>>> So that is why ... >>>>> >>>>>> Whether >>>>>> that actually matters depends on what vtimer_expired() will eventually >>>>>> contain. Hence why I said "consider using". >>>>> ... I didn't get why I might need vtimer_expired() in vtimer_set_timer() >>>>> before set_timer(). >>>>> >>>>> vtimer_expired() will only notify the vCPU that a timer interrupt has >>>>> occurred by setting bit in irqs_pending bitmap which then will be synced >>>>> with vcpu->hvip, but I still do not understand whether migrate_timer() >>>>> is needed before calling set_timer() here. >>>> Just to repeat - it's not needed. It may be wanted. >>>> >>>>> Considering that vtimer_set_timer() is called from the vCPU while it is >>>>> running on the current pCPU, and assuming no pCPU rescheduling has >>>>> occurred for this vCPU, we are already on the correct pCPU. >>>>> If pCPU rescheduling for the vCPU did occur, then migrate_timer() would >>>>> have been called in context_switch(), >>>> Even if the timer wasn't active? >>> Yes, migrate_timer() is called unconditionally in vtimer_restore() called >>> from context_switch(). migrate_timer() will activate the timer. >> Which is wrong? > > I don't know, based on the comment above migrate_timer(): > /* Migrate a timer to a different CPU. The timer may be currently active. */ > > it doesn't mention that it shouldn't be called if the timer wasn't active. > All around other cases where migrate_timer() is used I don't see also that > anyone checks if a timer is active or not. Hmm, I'm sorry, I was mis-remembering. Migrating is indeed fine for inactive timers. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 10:00:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 10:00:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204637.1519258 (Exim 4.92) (envelope-from ) id 1vgK9H-0003PH-L2; Thu, 15 Jan 2026 10:00:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204637.1519258; Thu, 15 Jan 2026 10:00: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 1vgK9H-0003PA-IC; Thu, 15 Jan 2026 10:00:15 +0000 Received: by outflank-mailman (input) for mailman id 1204637; Thu, 15 Jan 2026 10:00: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 1vgK9F-0003P4-OG for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 10:00:13 +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 fba62c1c-f1f8-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 11:00:12 +0100 (CET) Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-59b6a987346so681728e87.3 for ; Thu, 15 Jan 2026 02:00:12 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fba62c1c-f1f8-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768471212; x=1769076012; 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=hiE3X3RbLbN/YrjFYwPkJWRyZnCD12aqK2eKPDZSpvo=; b=kkPlVRPjAO5DRco6X/nA7+HO7bUGCSg0t7vCh/LD83hlB7YtLlc+RsvrsCYqxDy5lA k6PtzP2HkgMyIbpvaRPCIYuk0/MOmifn0BtTnXe0pcETzr3CDBpOYodInu0SMsRgdxQ2 IYc7d0RxCvgEE50sWFbilOasqb9jvBriamrt/RrKVSQYEbkZRxohNFswatY6qgUXDUv5 1nvxR9bGBAc89nD1P1vwLQBDLdFGXw27yN5bOtapJX6jI1n0U1ZqY6kywzKW1mpwfoO1 W5sVsRSi65IL6fv2jhzcYxkrCdqy1SICGJHWGA6993OnbMvpqDQew5vjvEl9b21RLb+Z 6OsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768471212; x=1769076012; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=hiE3X3RbLbN/YrjFYwPkJWRyZnCD12aqK2eKPDZSpvo=; b=NG7zjceJyYaBM/XNG0tsnshYsF9G1+7qDE8EhbyHSYbWhmLLyV843PwUCj3W6+KtY5 /AWp41AORdsvuyiCaXBso295ekAKuhJZcJbPyHO1IRod+vxi7hUZOWt6SINTQbnNWElw BhROyCfjEqVnqURBpEYO9xamOyxMxrNDYr+Ff8BZbX424fk9g1AE3PqAIsFzMTRBqEue sy1JNlPGdQl+1oTbWMT26ZW/lgo23W9EubYVOCuv5jXf3KptEhhNGO5SzNZ9fyriJ7BL gt/kM/H5QEGix/7Qht9QZFUOuuJcpRLUdeUDO5h1HgJXqRijyMJjvtHsVS+TrMHTZWee x2DA== X-Gm-Message-State: AOJu0Yw0oqOCqiM3xe6eaOuyxwgoiZ1Bx2cmWEHwjvZqtkc8XTo6M8N2 del+tiDfWXDGCbR/H0vldymN2bBzQJirjEt5Ypm4nui+3viF3Xdi/y8yt+rZHKE5+ABUI/FWFKA 0Y7nK1phc2p07w7oSF1gAZTTQDyTU1FM= X-Gm-Gg: AY/fxX5/tTsLBqZ1gvkuQN+skNZA0PH3ht5CSYla1GACWCYysS7U85kXJf+IYpKSaCk pmWscvukfi0rX6mt+ezolzGCyJqdZIVOAZQsnQwWiaHGVIrjDizPPCpI9PYYHZk4S6DUbmSFd2i fgZ4tFGO5pkmcWkpVk31q4tnAinjZuaaeGt2gcvQuzGixrN6EXcL069DMq8jkljYAm56VnGNrZO 5cQE7PH/DIV7Dca4joAL+nHbpM2iWMdH7T92B12lHcMNURNjGw/h57FbFOJmuQapQiTxYC/xQYT NkJsucm90iuzH88+JDudgYzR X-Received: by 2002:a05:6512:138d:b0:59b:9ae0:d94f with SMTP id 2adb3069b0e04-59ba0f626a8mr2013102e87.14.1768471211604; Thu, 15 Jan 2026 02:00:11 -0800 (PST) MIME-Version: 1.0 References: <75823cb4-c14c-4a4a-b523-e131c820a4d3@xen.org> In-Reply-To: <75823cb4-c14c-4a4a-b523-e131c820a4d3@xen.org> From: Mykola Kvach Date: Thu, 15 Jan 2026 12:00:00 +0200 X-Gm-Features: AZwV_QhsvrHWdgLHGqpfHSYTlC0Pumq3lobF2mT1E0OMzT10MFZ59gIyE9-WhTk Message-ID: Subject: Re: [PATCH v7 02/12] xen/arm: gic-v2: Implement GIC suspend/resume functions To: Julien Grall Cc: xen-devel@lists.xenproject.org, Mykola Kvach , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Saeed Nowshadi , Mykyta Poturai Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Julien, Thanks for the review. On Fri, Dec 26, 2025 at 2:29=E2=80=AFPM Julien Grall wrote= : > > Hi Mykola, > > On 11/12/2025 18:43, Mykola Kvach wrote: > > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c > > index b23e72a3d0..0b2f7b3862 100644 > > --- a/xen/arch/arm/gic-v2.c > > +++ b/xen/arch/arm/gic-v2.c > > @@ -1098,6 +1098,123 @@ static int gicv2_iomem_deny_access(struct domai= n *d) > > return iomem_deny_access(d, mfn, mfn + nr); > > } > > > > +#ifdef CONFIG_SYSTEM_SUSPEND > > + > > +/* This struct represent block of 32 IRQs */ > > +struct irq_block { > > + uint32_t icfgr[2]; /* 2 registers of 16 IRQs each */ > > + uint32_t ipriorityr[8]; > > + uint32_t isenabler; > > + uint32_t isactiver; > > + uint32_t itargetsr[8]; > > +}; > > + > > +/* GICv2 registers to be saved/restored on system suspend/resume */ > > +struct gicv2_context { > > + /* GICC context */ > > + struct cpu_ctx {> + uint32_t ctlr; > > + uint32_t pmr; > > + uint32_t bpr; > > + } cpu; > > + > > + /* GICD context */ > > + struct dist_ctx { > > + uint32_t ctlr; > > + struct irq_block *irqs; > > To confirm my understanding, this will also include the PPIs, SGIs for > the boot CPU, am I correct? If so, I would suggest to add a comment. Yes, correct. I=E2=80=99ll add a comment to make it explicit that this incl= udes SGIs/PPIs for the boot CPU. > > > + } dist; > > +}; > > + > > +static struct gicv2_context gic_ctx; > > + > > +static int gicv2_suspend(void) > > +{ > > + unsigned int i, blocks =3D DIV_ROUND_UP(gicv2_info.nr_lines, 32); > > + > > + /* Save GICC configuration */ > > + gic_ctx.cpu.ctlr =3D readl_gicc(GICC_CTLR); > > + gic_ctx.cpu.pmr =3D readl_gicc(GICC_PMR); > > + gic_ctx.cpu.bpr =3D readl_gicc(GICC_BPR); > > + > > + /* Save GICD configuration */ > > + gic_ctx.dist.ctlr =3D readl_gicd(GICD_CTLR); > > Do we want to disable the GIC distributor and CPU interface on suspend? I think we should quiesce the CPU interface after saving state, but not disable the distributor globally. I still prefer not to disable GICD globally for safety on platforms where the wake request is routed from the GIC to the PMU/SCP (e.g. via nIRQOUT/nFIQOUT). So I=E2=80=99d quiesce GICC, keep GICD enabled. Are you OK with this approach? > > > + > > + for ( i =3D 0; i < blocks; i++ ) > > + { > > + struct irq_block *irqs =3D gic_ctx.dist.irqs + i; > > + size_t j, off =3D i * sizeof(irqs->isenabler); > > + > > + irqs->isenabler =3D readl_gicd(GICD_ISENABLER + off); > > + irqs->isactiver =3D readl_gicd(GICD_ISACTIVER + off); > > + > > + off =3D i * sizeof(irqs->ipriorityr); > > + for ( j =3D 0; j < ARRAY_SIZE(irqs->ipriorityr); j++ ) > > + { > > + irqs->ipriorityr[j] =3D readl_gicd(GICD_IPRIORITYR + off += j * 4); > > + irqs->itargetsr[j] =3D readl_gicd(GICD_ITARGETSR + off + j= * 4); > > + } > > + > > + off =3D i * sizeof(irqs->icfgr); > > + for ( j =3D 0; j < ARRAY_SIZE(irqs->icfgr); j++ ) > > + irqs->icfgr[j] =3D readl_gicd(GICD_ICFGR + off + j * 4); > > + } > > + > > + return 0; > > +} > > + > > +static void gicv2_resume(void) > > +{ > > + unsigned int i, blocks =3D DIV_ROUND_UP(gicv2_info.nr_lines, 32); > > + > > + gicv2_cpu_disable(); > > + /* Disable distributor */> + writel_gicd(0, GICD_CTLR); > > +> + for ( i =3D 0; i < blocks; i++ ) > > + { > > + struct irq_block *irqs =3D gic_ctx.dist.irqs + i; > > + size_t j, off =3D i * sizeof(irqs->isenabler); > > + > > + writel_gicd(0xffffffffU, GICD_ICENABLER + off); > > NIT: Can we use GENMASK? This will make easier to confirm we have the > correct number of bits. Sure, I'll change it to GENMASK Best regards, Mykola > > [...] > > Cheers, > > -- > Julien Grall > From xen-devel-bounces@lists.xenproject.org Thu Jan 15 10:01:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 10:01:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204652.1519269 (Exim 4.92) (envelope-from ) id 1vgKAS-0003xe-2Q; Thu, 15 Jan 2026 10:01:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204652.1519269; Thu, 15 Jan 2026 10:01:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgKAR-0003xV-VC; Thu, 15 Jan 2026 10:01:27 +0000 Received: by outflank-mailman (input) for mailman id 1204652; Thu, 15 Jan 2026 10:01:27 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgKAR-0003P4-9i for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 10:01:27 +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 27c6e6fc-f1f9-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 11:01:26 +0100 (CET) Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-37fd6e91990so6606301fa.3 for ; Thu, 15 Jan 2026 02:01:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 27c6e6fc-f1f9-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768471286; x=1769076086; 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=/NUq6ZuohHWwa1bqjnFzQy2W23gyUBmH+kKcLMdDFmA=; b=ITxaynnU1T4dTGqIzAr9EwK7f28wPO1+gNqk81v+rqmbKQKhGD4KZ9g1MHoxrjwoG5 KtJuuq1JsZI6vOnvVR6fFQ6KN59h5ADiL3ZzbUZOqRHNvO8md2tKHrAxOect5u8bRjNa uHJE3tlZdVANG3FYjsZU3zl6Dh9mK5ASxNAYy0yBUQsB8S2giJBgZUD1775EX7MF6a1z g0Dqx8yzNSXmvnH1w2Q1yH4/X/QA0BBL+MloM047t7Vj4ggOu1mxqVSqaFrSy7PYQynh YwAmUpWj78KvnvaX1o7aX9h4zFIyV/L66iMpsrvE7pbECUsAlWcb/HoutqnCN+r/Ac5G 2CKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768471286; x=1769076086; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=/NUq6ZuohHWwa1bqjnFzQy2W23gyUBmH+kKcLMdDFmA=; b=ja2JgHgyyVDLr7SvperoUUxXpPjVDX4RQg8WZwoRTsEjAeCh3a+0T6tWX9zRoxQhuK Dje8qXDZBEtIZGFKDQtX4K7BOj10dxY6D+e5ki3J9Mdt2XRKzBmtlwyn171J842M757Y nEnwv7DZxL5Hlphs8/1ZiOqOwi4eQuuzpYAsytNsypxOQSzH6DUAVQmkRPngn7Zz8QLO DXWH8TKnBG1gZt72RxZYrTvUO9Ceorpf8kwF/ihC+jlGmYTfNOD841S4H4tvJ90dFxI5 lZJYBowL7fRok2L4QoLofvDn3C/oaPEtkmfyhdd0Hv4jKFW4pDtHoWe9J+SywYs96eT8 qH9w== X-Forwarded-Encrypted: i=1; AJvYcCVvxwBdPm7vUDbvg6bn+d0V8b/uYiRZ5aEHvlTcX5zL0dLCSKSl/uOItxwZ9oKkclyZ466geJGrSqw=@lists.xenproject.org X-Gm-Message-State: AOJu0Yyz3POxJeHQx2+RwV0cakunsd59EJ4w7zD8MFZG+VixJc5+u4Z4 Sx4fnPDimjOEkY7KLSz8bNaA6ecs/cBx27Zejd5QOHLh5F2Im0k0m9Xf6tGW62LdR/hgeTEoY19 GFDrbOMpAOu0yh28S0+PBQ+K5BlrzpwM= X-Gm-Gg: AY/fxX5TOMd8+0LLpwk9TS8wxuTZTeyFQd7I6GpX0hufWLSgGFj7tfDJsvIczlHsdNU 6x8Vdx9fJLd3umHjVzeOfWyMMdAKI9mi0MCMA/shYurjKLTIvEBgooyuKAdnnNy7memFpRZ/B7g RzKu5ivgkABpCXK3tAYv99DhhYoAaPwHZDEZOr1QXIbbP7UgDVUGMTFxQBZaajVOxZXmRWi+NW5 jBxqdela6B6DIxVoAo4YYug5jy3enPiAUizACJYjV+gcDOOKyFQ0cTanpG3aHeB2JFKXmblWqxU 7HB2JQcevX/ctkFDjTuRZatS X-Received: by 2002:a2e:be28:0:b0:372:8e26:a4d4 with SMTP id 38308e7fff4ca-383608260dfmr17319671fa.42.1768471285606; Thu, 15 Jan 2026 02:01:25 -0800 (PST) MIME-Version: 1.0 References: <2fade2b96128053fbe3ed59f1d5e3444b32b96c3.1765472890.git.mykola_kvach@epam.com> <59fc7f4c-b3f9-4a5e-b438-7989c4cd7c02@suse.com> In-Reply-To: <59fc7f4c-b3f9-4a5e-b438-7989c4cd7c02@suse.com> From: Mykola Kvach Date: Thu, 15 Jan 2026 12:00:00 +0200 X-Gm-Features: AZwV_Qjkeref5iCREf7ie5Selhq0tqavbcVGGwCNSuylaxNVrC_iBERfc4grQN8 Message-ID: Subject: Re: [PATCH v7 04/12] xen/arm: gic-v3: add ITS suspend/resume support 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 Hi Jan, Thank you for the review. On Mon, Dec 15, 2025 at 1:39=E2=80=AFPM Jan Beulich wro= te: > > On 11.12.2025 19:43, Mykola Kvach wrote: > > --- a/xen/include/xen/list.h > > +++ b/xen/include/xen/list.h > > @@ -535,6 +535,20 @@ static inline void list_splice_init(struct list_he= ad *list, > > &(pos)->member !=3D (head); = \ > > (pos) =3D list_entry((pos)->member.next, typeof(*(pos)), memb= er)) > > > > +/** > > + * list_for_each_entry_continue_reverse - iterate backwards from the g= iven point > > + * @pos: the type * to use as a loop cursor. > > + * @head: the head for your list. > > + * @member: the name of the list_head within the struct. > > + * > > + * Start to iterate over list of given type backwards, continuing afte= r > > + * the current position. > > + */ > > +#define list_for_each_entry_continue_reverse(pos, head, member) = \ > > + for ((pos) =3D list_entry((pos)->member.prev, typeof(*(pos)), memb= er); \ > > + &(pos)->member !=3D (head); = \ > > + (pos) =3D list_entry((pos)->member.prev, typeof(*(pos)), memb= er)) > > + > > /** > > * list_for_each_entry_from - iterate over list of given type from the > > * current point > > While not said so anywhere, I understand this is taken from Linux. Maybe = we > should indeed take it verbatim (as far as possible, i.e. without the use = of > list_entry_is_head() which we don't have yet), but I'd like to point out > that in the comment "continuing after the current position" is ambiguous. > In list order, what is meant is "before the current position"; "after" is > correct only when considering iteration direction. Personally I would muc= h > prefer if this was disambiguated. Got it. I=E2=80=99ll disambiguate the wording while keeping it close to the Linux text, e.g.: =E2=80=9CStart to iterate over list of given type backwards, continuing wit= h the entry preceding the current position (i.e. starting from pos->member.prev).= =E2=80=9D Best regards, Mykola > > Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 10:04:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 10:04:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204663.1519280 (Exim 4.92) (envelope-from ) id 1vgKDU-0004X0-Ih; Thu, 15 Jan 2026 10:04:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204663.1519280; Thu, 15 Jan 2026 10:04:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgKDU-0004Ws-DH; Thu, 15 Jan 2026 10:04:36 +0000 Received: by outflank-mailman (input) for mailman id 1204663; Thu, 15 Jan 2026 10:04: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 1vgKDT-0004Wm-Cs for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 10:04: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 978aa261-f1f9-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 11:04:34 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-477a219dbcaso5775625e9.3 for ; Thu, 15 Jan 2026 02:04:34 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47fb73762cfsm14685615e9.4.2026.01.15.02.04.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 02:04:33 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 978aa261-f1f9-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768471473; x=1769076273; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=fErsITdv1QreScvG162N8masb9sIgtLt4SqV0gAJwg4=; b=bUDSBzAnKAdKKogAdoyFFy4p8XqY1mmo+IpgCU3QQC2s5D2dulkjCpoKY/Hpq47AP+ QN1Tra1fG+Uvv1cBb3AynwrdfBepSYgqz/FnEsjgeaDEL+XWix/obi/Oe0bJmoHkJVma UMvELJoXVFf7l4nWX/9SSSdzfUppJ/R0z/sEKcSDPrG7EYslZOjOEOQK23Wj7MfF0ntd G3UcvooJe2GFRy48Y587kOscChkV6BjyOQHZ0d/3D88kx+HE+qZZsceIM3BMVrIvfVHx MffbzxORo+jQvx0O4/XwlGEMMoNfZ2/Xz5ekXvJqyrztoys5ngqHSRNqvVakga2NjiQp Q1Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768471473; x=1769076273; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=fErsITdv1QreScvG162N8masb9sIgtLt4SqV0gAJwg4=; b=CWkJx5gFCGErN1wquSCFAyEOAuQMpqeQKRT+E3OyceWDUlHrEGAPt8dCKzf1Bh/6pQ B1XyndFtWqCRaM9DcddOyUrGren5fvGDu0ajj1Pi9H8o1hNu+rXe+vwOf5DZKxsnhftz LnKxW1RUdmPDGEQwjwhDdFS15d8upR55GYY/Y1Syb3ovx8hLPy0wiTNytSy0oSrUjbp9 pHoHrM3BtsiounTPVVzlqUFFeYTbkApNACzTs40An5ti7SjYHAfFIw0YTnYbHji7wd5q rZpDZtWKu83CprOOzbQC/lXgIE04khG+SYshcQxQf8njduwL0mk8WKEvEXryqGwZfME8 i6QQ== X-Forwarded-Encrypted: i=1; AJvYcCVOAUjlAcks6wMbLEqGp/apPwNgr+K8rzGnhoc6gh1DS3053ZuTXKG3Llvfh7+6I0IOdLSehPkUnwg=@lists.xenproject.org X-Gm-Message-State: AOJu0YxMEoN7amJXcnKXVhAxqZ58dfNTPZZQZOpCx3G8ajkDf82PmABJ cRUEJbpmL3lH/1SMymu+sMStRkQGOMkeChD1zsgAD7prZ6Qxk9YZtIQc8Wl23biDpg== X-Gm-Gg: AY/fxX5GOsV9N4KeYlU5ovOIpBdazTgfenHFxydH9IGvtWk664RDdSSETSPQ+B8xWp7 2wVX/kk964RTLsJ9UxjfBY6RIXOkEcPnF1P1N9iku6QrWmGeSRXFDNHXDuUiL53cpYnxFJWIG2I ERKmkiOvv/MXBEMzL7IXFjNSByDSpVrQqbVJDEate3OPFigxXGoyofq6O89O4JZh6Hyco6oncsU NfGuSMr7P9AyZdGNukiPPSN+k0TqEztEyHKT3gQprML+gfWXcq90vyXdET/yBiHVhrejO7KTylk 6v8LZh8pNbNzXGwoYq618xrY+pZG/5PpEkoiWkLg/c322eYNcWJ+NTI9OOeZwUswcUu/JVyZ+ol S/Ys7wzzTSPLUVswrtyLjsbVaQgiL8OA+Ay78aB6aOxy5iU9tLjgqgZJ4wDlTzEpmYVtnxtCYpl lF8rpx3YIeqFW/erJp54/VW0tRSsFwm4yDfB34m/z+HUJNHDUgy6XlNJ+73AtNNeZuug8jlDCZQ Is= X-Received: by 2002:a05:600c:674a:b0:477:b734:8c52 with SMTP id 5b1f17b1804b1-47ee47ca2d4mr56006605e9.14.1768471473507; Thu, 15 Jan 2026 02:04:33 -0800 (PST) Message-ID: <128f0e07-05cc-49c3-80f2-303f6a0c75c3@suse.com> Date: Thu, 15 Jan 2026 11:04:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/time: Drop unused parameter from soft_rdtsc() To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260115095047.1201825-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: <20260115095047.1201825-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 15.01.2026 10:50, Andrew Cooper wrote: > Fixes: a6ed4543222a ("x86/time: pv_soft_rdtsc() is PV-only") > Signed-off-by: Andrew Cooper Why Fixes: without you calling out what bug it is that is being fixed (and that was introduced by said commit)? That's really where I think Amends: is to be used, but yes, I know you dislike that new tag. The Misra rule 2.2 (dead code) violation was pre-existing to the named commit. Plus that rule isn't among the accepted ones, i.e. while we should strive to not have violations, having ones isn't quite a "bug" (yet). But yes - I probably could / should have noticed this and done the change right while moving the function. Without the tag, or with it changed to Amends: Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 10:17:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 10:17:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204690.1519288 (Exim 4.92) (envelope-from ) id 1vgKQI-0006s7-Iy; Thu, 15 Jan 2026 10:17:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204690.1519288; Thu, 15 Jan 2026 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 1vgKQI-0006s0-GH; Thu, 15 Jan 2026 10:17:50 +0000 Received: by outflank-mailman (input) for mailman id 1204690; Thu, 15 Jan 2026 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 1vgKQH-0006ru-8S for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 10:17:49 +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 70157981-f1fb-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 11:17:47 +0100 (CET) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-42fbc305914so437123f8f.0 for ; Thu, 15 Jan 2026 02:17:47 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af6fca57sm4753210f8f.42.2026.01.15.02.17.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 02:17:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 70157981-f1fb-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768472266; x=1769077066; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=VSpE9caEEZbUY5/RPFYcJU6rRkRT43oaDHagzRcqq/Q=; b=LP4L7N4cglmw40zPqoehEFqQMDmS6+Bn/m+0csvKcrLS9arK6DjUO6wMWgcEs4U9r3 IHex3r9VTNy1+yOLleSBLjt572VvY892I+js/RGy4B3mQPUdVeNXsyUsjR7ny2+L05Ec 20fNl5mLyfkx9+fZq8tGvypwOzTajxwEFk3mfDp5NzHNlH2WZJ/RyBrSbXRlsxPLXUn5 Kae2KDpVpfBvfYxunyYUUMA7YtqfUB/k6awJznIlWLKfs1ZGZ1M0kigEeRbMw9NTP9gf jmLc7oo5P7pO8cch9DLypLduS2k89b0c0sK0DsZrj5jd0xjXUVjar0Vg/jcA2yKm/cnS yLIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768472266; x=1769077066; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=VSpE9caEEZbUY5/RPFYcJU6rRkRT43oaDHagzRcqq/Q=; b=O2oYsQs1hbRW5oiB2hp2v53ewViV7cbqY4lmVlMEd/gOhKY0/TCwQDksnXYsGVSAvZ zvmH16rxj6xvaKTicL9+uqFHdnN984Pq78j6b/lI5Qlc7KusRhiEvrvho8wwm6rEG5Ck S8xzJ/bB9PjZSSRSRXQHhKSULv5LhgfEo7NOqNZrTKexwrkx+mJdi4PDOwhpKbjA2wA+ HxPjMEdxicEIMSarUSD1Py0L9qjw7HvLENU5N/wSf2AbWLSu2fHRIO3YtGhtbkHidSJK xQjhmyK549cSNWNMKjU4RMazQ+sU08zcSRsgKUqT0qxmu/Lhu036Fq3A0q+MP/f5utY5 XVCw== X-Gm-Message-State: AOJu0Yytbv7HWS4MYNJ6QvqHtS9u5hy1ZwElKEpX/OmjNO/cdI1Xo01s d41QSUHwSnrm+GPXNW8odN/pwEO2R3Jl/b8tn/l8a1shl2KqEeyB8bE1mIg9cCrnE37EvtmuRSV EJmI= X-Gm-Gg: AY/fxX57AZDtKAZvpq17tsgtcKAWGrykz+fh+9OM10eg2lOwXGAJy7Tfa8MTEz+GONB YUV6HufAkC/f9eCfuSEWNfnrf9xErQgw9M0I6YDfduIxbopwbPTWqkSh2vOcP7Hz4KkUKKGNHxi Hm83WnI9JbtBLD5B60HOZ+UOhPI1W5+DIvrrp1J1JRLQ7CsLkMZpTUDjkIhb1ABv+rsI5faDSdV BLx1ylK95S4bcmmTS97Hxqi7tUpl8ITpjeRB37GUelGjALv6aAihbMLg1ITVC6uTnVUmIG7J6qt KvGfDOjhTvFj+AZWptaXgoWSjRi0VSxIK5ulL+X1/A/JWzjfsLOhitpzDjDEM9QAJAxy80Odf8v d+OFg43D1bzlubJJfxUZQ5b5BnKiLBsuolBFtRBlL18Y7sQ9WD9quVvucrOYApYqSeGzpWDmEXI cpA6RdzJP6yQolqtlSHf14UCe3+GvIYPSu6X/GjFwvaB3ZAUgbNaHHxDhMhjwq6nypPw5w/uBMW Zw= X-Received: by 2002:a05:6000:2511:b0:430:f1d3:f96 with SMTP id ffacd0b85a97d-4342c4f4cb4mr6329137f8f.6.1768472266364; Thu, 15 Jan 2026 02:17:46 -0800 (PST) Message-ID: <2012453e-d09f-4da0-bdfc-8487cef278ef@suse.com> Date: Thu, 15 Jan 2026 11:17:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [XEN PATCH] x86/mce: use offsetof to determine section offset To: Nicola Vetrini Cc: xen-devel@lists.xenproject.org, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk References: <350bd19ec4b0b190911d748df6ec92c626e7151a.1768415160.git.nicola.vetrini@bugseng.com> <87de17df-0aed-4ce1-b556-f93a381b66d3@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 14.01.2026 21:56, Nicola Vetrini wrote: > On 2026-01-14 21:40, Jason Andryuk wrote: >> On 2026-01-14 13:27, Nicola Vetrini wrote: >>> --- a/xen/arch/x86/cpu/mcheck/mce-apei.c >>> +++ b/xen/arch/x86/cpu/mcheck/mce-apei.c >>> @@ -74,7 +74,8 @@ int apei_write_mce(struct mce *m) >>> rcd.hdr.record_id = cper_next_record_id(); >>> rcd.hdr.flags = CPER_HW_ERROR_FLAGS_PREVERR; >>> - rcd.sec_hdr.section_offset = (void *)&rcd.mce - (void *)&rcd; >>> + rcd.sec_hdr.section_offset = offsetof(struct cper_mce_record, mce) - >>> + offsetof(struct cper_mce_record, hdr); >> >> "= offsetof(struct cper_mce_record, mce);" should be sufficient since >> the offset of hdr is 0? > > Yeah, makes sense. Given that the struct layout is coming from the UEFI > spec it's not likely to change either. It's okay either way, but I'm happy to adjust to the simpler form while committing (I'd slightly prefer that, precisely for being simpler, and it being close to what was there originally): Acked-by: Jan Beulich (ftaod: either way). Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 10:19:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 10:19:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204699.1519299 (Exim 4.92) (envelope-from ) id 1vgKS8-0007bG-UL; Thu, 15 Jan 2026 10:19:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204699.1519299; Thu, 15 Jan 2026 10:19:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgKS8-0007b9-RZ; Thu, 15 Jan 2026 10:19:44 +0000 Received: by outflank-mailman (input) for mailman id 1204699; Thu, 15 Jan 2026 10:19: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 1vgKS7-0007b3-IH for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 10:19:43 +0000 Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [2a00:1450:4864:20::231]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b5084e64-f1fb-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 11:19:42 +0100 (CET) Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-382fd45a1feso6573351fa.0 for ; Thu, 15 Jan 2026 02:19:42 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b5084e64-f1fb-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768472382; x=1769077182; 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=bZVmO8N0UZYu/o2t/bIFeKiY6ewosWiZISEU6KWNQIw=; b=WVK1BXr68fCteuJrRVTcC8X28KRBa/uRznKVp4A7D8BveUpC+Z55Vgn5rSlBzD216T /4C4ZGxyeBecBLzWs3KFt1/AWRGBC6fjfzfZAHye0pouURoR7EYlb8RSBzfH72BmaO3X cvLStHtuc2tsjrwJGrL0HCcW3+9o5FZyzH+C/b45MwO11id05chgoWy+3opQtO82EmGO KmaO7Cq/FnUhjpXzD1bfBEpJXqBI6ELVtEDxK7ffO93AHNad7bCRORMxBYaXJlnPrOKP OC1y0eG2xfXykeAcmb4oFiFcgZeNcUz9kGOKLswlqdWdJuxdBtXF1xCX4XALibCE7eMg E3FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768472382; x=1769077182; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=bZVmO8N0UZYu/o2t/bIFeKiY6ewosWiZISEU6KWNQIw=; b=vwPB2iAr2ggXcR87wQv42KVjlUWJPbB23ugX2NXvOCBddqmPOFz5/bdCpu733N1Gp4 87f/146TM6I68BAkKu9pD9mpAJgzMy+Gf43nyVWOLc+cUdg25OTgZOySMbb/VnPbk9Ry 6kcbpcf66JO6OxZEJvtY2peoFzm/Y2BTLxw1aSpL8astUklsOAcfqLkC6i12gUmOUUzv DZAhHRIgGYwYVPwG6x5lFpR8nAg3XVBQANkVuywdfrSBiRkTlcN3M0vph1/AH3cBPaE5 XZON18H08m4RzAToBe0Hl2X/xOjxASVxf3KMGdr0Ym1tBhi5f0caEbcrEzJYT7jIWXlP +3CA== X-Forwarded-Encrypted: i=1; AJvYcCWY/d6kw9Aiv8Aesr49EJAzTqV/1rQPnkSGhuZkxX7PKdmpxt4lCQvW4BIBxZ8XbXFQmhZDX/DS2pM=@lists.xenproject.org X-Gm-Message-State: AOJu0YzfC3qzLFwNlIt6LmqKKTEmPmh41ISeXLBQYPAlxEfLlcU9VF7o RMJ1GyE6tT71ZriLVxElCxREfJ9dVon0MMi/LvzYTMkZMUSvaoTYq+Pzqx1QFHBRf8mj7oVJ8wG zuuOTeqiJZAsdF5DztT/cUtRg+HLw53M= X-Gm-Gg: AY/fxX61mN16hMZj4DqGOShjPOsNbGxfBDOfELY25RO43A1FRM2HhDXDD60/jBOfzHf LXq/JBmvwJaeQylyHpY2VIdrpAOwii4GwQk9sjk1RdKt7W2Gz9qA8P9KsGmrxJNGion3C3R260G JhgTYscsOyjyGfFL/rCFjnkeAJsItfwYhineUHt2IfScNExibEUo8XV96c2/89RTUejZZwvDcNN nnZP+T6KpTA0qOr64NQ/plc/fYic/TuNl8Bt22cTcppZmHTDRMrFqPkxr89AivH7wcNmcp7hOrh DawEqZjsniaOuDsUkDE6FdT1 X-Received: by 2002:a2e:b88d:0:b0:382:f9c6:ba68 with SMTP id 38308e7fff4ca-3836ee0044cmr7611511fa.0.1768472381818; Thu, 15 Jan 2026 02:19:41 -0800 (PST) MIME-Version: 1.0 References: <66fffded45f39599c62a1e4dad83c34f9de51d7d.1765472890.git.mykola_kvach@epam.com> <5bfbdbc6-c1ea-4aa6-acf0-1516b226f3c2@suse.com> In-Reply-To: <5bfbdbc6-c1ea-4aa6-acf0-1516b226f3c2@suse.com> From: Mykola Kvach Date: Thu, 15 Jan 2026 12:19:30 +0200 X-Gm-Features: AZwV_Qgt-1wOFbpC4qdZWzyD2qoK2Irfj7GqqXCWRcz4FktmgBTycqaQL1kkwck Message-ID: Subject: Re: [PATCH v7 12/12] xen/arm: Add support for system suspend triggered by control domain 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?= , Rahul Singh , Saeed Nowshadi , Mykyta Poturai , xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jan, On Mon, Dec 15, 2025 at 1:49=E2=80=AFPM Jan Beulich wro= te: > > On 11.12.2025 19:43, Mykola Kvach wrote: > > --- a/xen/common/Kconfig > > +++ b/xen/common/Kconfig > > @@ -137,6 +137,11 @@ config HAS_EX_TABLE > > config HAS_FAST_MULTIPLY > > bool > > > > +config HAS_HWDOM_SHUTDOWN_ON_SUSPEND > > + bool > > + default y > > + depends on !ARM_64 || !SYSTEM_SUSPEND > > As written, this would want to be "def_bool y". However, I think I indica= ted OK, I=E2=80=99ll switch this to def_bool. > previously that imo it would be nice if we could stop adding more "depend= s on" > referencing particular architectures. Instead "select" or "imply" from > xen/arch//Kconfig appears more desirable to use in such cases. That= way > each arch can control what it wants without needing to touch common code. > > As an aside, in the context of PV_SHIM_EXCLUSIVE it was also said several > times that negative dependencies aren't very nice to have. Here we have n= o > prompt, so the "allyesconfig" concern doesn't apply, but I still thought = I'd > mention this. I used the common-level dependency only to avoid adding selects in every other arch Kconfig, as the only exception I need is ARM_64 && SYSTEM_SUSPEND. If you still prefer keeping all arch-specific handling under xen/arch//Kconfig, I can rework it accordingly. > > > --- a/xen/common/domain.c > > +++ b/xen/common/domain.c > > @@ -1324,6 +1324,11 @@ void __domain_crash(struct domain *d) > > domain_shutdown(d, SHUTDOWN_crash); > > } > > > > +static inline bool need_hwdom_shutdown(uint8_t reason) > > Personally I think "want" would better express things, but I don't really > mind "need". I'll change it to "want". > > > +{ > > + return IS_ENABLED(CONFIG_HAS_HWDOM_SHUTDOWN_ON_SUSPEND) || > > + reason !=3D SHUTDOWN_suspend; > > +} > > Seeing this in use, I wonder if HAS_ is really suitable here. What name would you consider more suitable here? Best regards, Mykola > > Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 10:20:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 10:20:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204707.1519308 (Exim 4.92) (envelope-from ) id 1vgKSl-0000ax-5x; Thu, 15 Jan 2026 10:20:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204707.1519308; Thu, 15 Jan 2026 10:20:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgKSl-0000aq-39; Thu, 15 Jan 2026 10:20:23 +0000 Received: by outflank-mailman (input) for mailman id 1204707; Thu, 15 Jan 2026 10:20: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 1vgKSj-0007b3-Fn for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 10:20:21 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id cb5764ca-f1fb-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 11:20:20 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 0437E4EE75B7; Thu, 15 Jan 2026 11:20:19 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cb5764ca-f1fb-11f0-b15e-2bf370ae4941 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=1768472419; b=0mGEsviCTbWlTn4WtRtz6ZUjfkjA+M06fgi2UMLfSsRyoAZbKmwRQdCdV1SMtPx8X9Ak XRS0fUjdimDjPcKnJx5nymP/Tuu9DopmzSlXeP25JdmlELYysLqInz36KC+ArK0f0abzw 0+vJEw4rtaudrEoHtsmyYt8UzIYQedg0jp7Zrqhx3vGUshCrD7CFfIi6wTs7uSspQSZh0 BVcCz1hKLS5tbUJo/K9wYy8B6RaQJpgZeeODEwfD62SJIN4w9ZH1eTeLWj0+Z8HA8ljLc gf6V7qVzlZEbMluko2mmIjcXPuBHHLgovTzTl5s91d3HQ9O1wjO7xUZim1arSvhGjt+hp yK4ko9NC74SXEZOBIpHT5o1OP/hSaf7w3+NmUK1+M5GA4qxl9+XjrlRl/vHqOtdBiDoLw 8QT/8rRF7Z5EWTYpsUXPoV+pN6QKlxsj6B9GWslFbWhZNCG8qGB+TMH3JJL6JyXQNyr/t FGLpQ3i7SVRsaFiCsrjIdAqnsF60Ylp3xH6ugnS4XZ0ux/wLJWZUTdaOTopC67kgdb+HH 4RO1ConPDKL8WGDcYulNccst/tzrd6FKl405R6eX49/uiXi7WIpbgY1iV1rFND2cWDtQl wFxiqSYSi5hOBQ77xc9FYVdtm9eIJ3pUXhCSYD/NZREb59L3SincOzpk0Nbv9TQ= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1768472419; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=KnZWE/vN7WeQU73j9OaHH+BojkCuakSF/uLVTudYhn0=; b=3bgOhu7Ph01dRdQxpdMgUNqORM0609FxToNqmyN5ixQuhBUartQXy5g3isPf1ghxyXwE OFlURCEBalwvtIIhQS2z9doa5BvvtEB0ZYAsK97GZ3LU3xWsda+6G3zsBdN7Z8vL4aA04 qy1AxAs67xow5c10QDPZKP77pwIwF8Aw6i0dpylSk22G/Py75skVHUmjAHwgM1FDsnsXG 2ke2mClh2wYowB8FJCoQnXDMMKVqf4Iv8H3A+8DUMAE/TgZzIDkoW4Gf68dCmZx6g/J6/ aOzV69T1E4UTw28vLAd42FoGP5mfotw3WwXJrHAeJQNLpkqdepAtOZpnkKC+atFMYy2K6 H8Qln3ZUU3GadKjgyadb2+j3T2eNPyDiyZRysZLyxOorISn0VJOy3ManomgOJhDferR57 MVYyJDqqEB4Hho1CXjhHCc3A4Xes7TSnvxtxy7QVzLTEK71FA8yS1yJuArv3gU/R8GQV4 1qPl0l5YzhYvbXhI4EDFUX5vhRKnVpIdnNPk/GrFOCWJhngmmnsq1sEDP2SyoY60N7Oq7 VCBLskBNQKa46sKANTp6ytUJiLbxAYR54ap6p19bXA1Dy+un8Vl1pWwipXtrHPQHyUTt+ Xt3KC6+KLSW5XC3s/KgUNKe/81nR/2TcAFy4vSlBSinwwqlhnm/bVGxT8p70wNg= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Thu, 15 Jan 2026 11:20:19 +0100 From: Nicola Vetrini To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk Subject: Re: [XEN PATCH] x86/mce: use offsetof to determine section offset In-Reply-To: <2012453e-d09f-4da0-bdfc-8487cef278ef@suse.com> References: <350bd19ec4b0b190911d748df6ec92c626e7151a.1768415160.git.nicola.vetrini@bugseng.com> <87de17df-0aed-4ce1-b556-f93a381b66d3@amd.com> <2012453e-d09f-4da0-bdfc-8487cef278ef@suse.com> Message-ID: <1d15798d2e416764aa81d6120bbaf7a0@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 2026-01-15 11:17, Jan Beulich wrote: > On 14.01.2026 21:56, Nicola Vetrini wrote: >> On 2026-01-14 21:40, Jason Andryuk wrote: >>> On 2026-01-14 13:27, Nicola Vetrini wrote: >>>> --- a/xen/arch/x86/cpu/mcheck/mce-apei.c >>>> +++ b/xen/arch/x86/cpu/mcheck/mce-apei.c >>>> @@ -74,7 +74,8 @@ int apei_write_mce(struct mce *m) >>>> rcd.hdr.record_id = cper_next_record_id(); >>>> rcd.hdr.flags = CPER_HW_ERROR_FLAGS_PREVERR; >>>> - rcd.sec_hdr.section_offset = (void *)&rcd.mce - (void *)&rcd; >>>> + rcd.sec_hdr.section_offset = offsetof(struct cper_mce_record, mce) >>>> - >>>> + offsetof(struct cper_mce_record, hdr); >>> >>> "= offsetof(struct cper_mce_record, mce);" should be sufficient since >>> the offset of hdr is 0? >> >> Yeah, makes sense. Given that the struct layout is coming from the >> UEFI >> spec it's not likely to change either. > > It's okay either way, but I'm happy to adjust to the simpler form while > committing (I'd slightly prefer that, precisely for being simpler, and > it > being close to what was there originally): > Acked-by: Jan Beulich > (ftaod: either way). > > Jan Thanks -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Thu Jan 15 10:33:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 10:33:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204738.1519319 (Exim 4.92) (envelope-from ) id 1vgKfg-0002e6-C4; Thu, 15 Jan 2026 10:33:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204738.1519319; Thu, 15 Jan 2026 10:33:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgKfg-0002dz-9F; Thu, 15 Jan 2026 10:33:44 +0000 Received: by outflank-mailman (input) for mailman id 1204738; Thu, 15 Jan 2026 10:33: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 1vgKff-0002df-LX for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 10:33:43 +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 a8c7ccd7-f1fd-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 11:33:41 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-47fedb7c68dso3928495e9.2 for ; Thu, 15 Jan 2026 02:33:41 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af6e1698sm5298158f8f.37.2026.01.15.02.33.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 02:33:39 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a8c7ccd7-f1fd-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768473220; x=1769078020; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=h3U14mP0O4cySah4Cpl1bg8vD/ITlMdvA+VdD6zfWxg=; b=gyzrUUQzfOCDKOHNeH5Fez93swY9xO7msn8qwyqlAHp6MKdzFO6wDE5nnuVhB6yA1B 55NPmNjgcGwoCI+k5HVlqPPplS1o8+RgEaKUCeaLOxqaKR72wACNdVmXvyBX2cuaJs63 e4BhFVPYG5PfgXKknLMA9yTmWg7kpzPItmDr7GHXmsKPT56KcboNlDFlssh5EfNCCRvX 2NTKaT+lJzOdBuScvQYoWCW5qrADb9X4xEvNnCjnYNvdIUsWbYwBcgx4vK/9foaOwmbX AIH7jiOcSLYzMf6Df6YKCkEFXrZC1fkC0i56wKqSNegnzSYOtsW3GobYyOd5PgJkttw4 m1ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768473220; x=1769078020; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=h3U14mP0O4cySah4Cpl1bg8vD/ITlMdvA+VdD6zfWxg=; b=XaE4uOJdNKtMU9gHuXUdY7yJQv45cxaZZQggWFEx11PuqVDpcLGLUzJ4Y+nziUq4gK 16Tk+5Cm/Jp9tk2q2itr7scmO+rvqgRhiQCWqkDpqHKZry7AqFY7AhO7tlHhvOlpipqq gUOjhYAQKRIHClSAIS8CpJu4q/0sov3WoRyZw7v11zDgQ6a8oDaOT4BpqS/RMIvyZKk6 CHO2XeyqcJSD2pWW/5sbYbs9xKhhZzq4uaOfHEFcxV9L4Z6ZmT57fwT1lapUFmZRInwd VUA0PrFEDIa9uzZrh75tladPn/SojkVn2nHgowZkYwX0JohIgDzez7b8MyErRr8OBnr7 umNw== X-Forwarded-Encrypted: i=1; AJvYcCU+BX2qFwQ9sW81Eye40n5/eiO828Czx4Sfi29C4rnvJc1vFFKpoo9TgtNFoZwHzH1NKVdbuBw0R1M=@lists.xenproject.org X-Gm-Message-State: AOJu0YzAkinCfV2xmUfmYHffJN8uyKHqHDuWjXpRpBP0bE1u6lj+SHlx pJUxuHyqALOaAQWMzWoJk2VURG+Ybi+ob3+Pw5gEkkPJZR/3iWPsSmS2zpW2ILFPnw== X-Gm-Gg: AY/fxX4SkI/tCAvtNllWviDt5ZtbsC2QhMXzcMp5gSgOKqfZZGhnqsQMjkI2vBZLMNl tfs9iclCyPQDLR3LAVHELRbw0jy6TdelGHzkGpSMLDBUB2Lo5jSe7bPP854hR0G3dPMFARd31Vc CQebdnmuBd175o1PrEYlRh9PhtSB3vMY5NZMS1CbSubmQi1IcFLY4IYaybRfoRo9T5mwvHqOeYZ qljko9c5Z9Ng26F7L81JdO1XR073XlKfHHsp8vPpRt9PjqpSv49L6KhyK/wa8xmyPNK0sRP2to5 HAuKHJTZ71Utb7p4b4EOpJUO/3Y/anl4XoIXftekAKZzuUjCamwwLxSyCHac85XUSibI3gbEVOK LD61hKoZkaZf28k2ml+n+i0OhnZbSZ0un67dEggNZSHLKe7woMmdGzMQT5YAa3A5x68JfFa/VdB IgEOeFZm3KBwi/SAqg83/EtEQiNvsvMnAYW6hP50zZWQk9mCSlV+9to7atD5/T7fFFQUc2bsQE5 /4= X-Received: by 2002:a05:6000:3110:b0:430:fc3a:fbce with SMTP id ffacd0b85a97d-4342c4fef6dmr7592012f8f.15.1768473220380; Thu, 15 Jan 2026 02:33:40 -0800 (PST) Message-ID: <2a0571c2-5c1c-4b03-9f31-1aa283f24e42@suse.com> Date: Thu, 15 Jan 2026 11:33:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 12/12] xen/arm: Add support for system suspend triggered by control domain 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?= , Rahul Singh , Saeed Nowshadi , Mykyta Poturai , xen-devel@lists.xenproject.org References: <66fffded45f39599c62a1e4dad83c34f9de51d7d.1765472890.git.mykola_kvach@epam.com> <5bfbdbc6-c1ea-4aa6-acf0-1516b226f3c2@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 15.01.2026 11:19, Mykola Kvach wrote: > On Mon, Dec 15, 2025 at 1:49 PM Jan Beulich wrote: >> On 11.12.2025 19:43, Mykola Kvach wrote: >>> --- a/xen/common/Kconfig >>> +++ b/xen/common/Kconfig >>> @@ -137,6 +137,11 @@ config HAS_EX_TABLE >>> config HAS_FAST_MULTIPLY >>> bool >>> >>> +config HAS_HWDOM_SHUTDOWN_ON_SUSPEND >>> + bool >>> + default y >>> + depends on !ARM_64 || !SYSTEM_SUSPEND >> >> As written, this would want to be "def_bool y". However, I think I indicated > > OK, I’ll switch this to def_bool. > >> previously that imo it would be nice if we could stop adding more "depends on" >> referencing particular architectures. Instead "select" or "imply" from >> xen/arch//Kconfig appears more desirable to use in such cases. That way >> each arch can control what it wants without needing to touch common code. >> >> As an aside, in the context of PV_SHIM_EXCLUSIVE it was also said several >> times that negative dependencies aren't very nice to have. Here we have no >> prompt, so the "allyesconfig" concern doesn't apply, but I still thought I'd >> mention this. > > I used the common-level dependency only to avoid adding selects in every > other arch Kconfig, as the only exception I need is > ARM_64 && SYSTEM_SUSPEND. > > If you still prefer keeping all arch-specific handling under > xen/arch//Kconfig, I can rework it accordingly. Imo there are two options: Do as you suggest, but with an option not starting HAS_*. Or use HAS_ with per-arch selects (which I think I'd prefer). To limit the number of selects needed, perhaps the sense of the option may want inverting? Otoh I don't think we know yet what RISC-V and PPC are going to want? >>> --- a/xen/common/domain.c >>> +++ b/xen/common/domain.c >>> @@ -1324,6 +1324,11 @@ void __domain_crash(struct domain *d) >>> domain_shutdown(d, SHUTDOWN_crash); >>> } >>> >>> +static inline bool need_hwdom_shutdown(uint8_t reason) >> >> Personally I think "want" would better express things, but I don't really >> mind "need". > > I'll change it to "want". > >> >>> +{ >>> + return IS_ENABLED(CONFIG_HAS_HWDOM_SHUTDOWN_ON_SUSPEND) || >>> + reason != SHUTDOWN_suspend; >>> +} >> >> Seeing this in use, I wonder if HAS_ is really suitable here. > > What name would you consider more suitable here? As per above, HAS_ dropped would be an option. Yet that goes against my preference above. Maybe HAS_ really is okay-ish here, despite what I said earlier. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 10:38:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 10:38:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204749.1519329 (Exim 4.92) (envelope-from ) id 1vgKk2-0003W0-Sq; Thu, 15 Jan 2026 10:38:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204749.1519329; Thu, 15 Jan 2026 10:38: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 1vgKk2-0003Vt-Pf; Thu, 15 Jan 2026 10:38:14 +0000 Received: by outflank-mailman (input) for mailman id 1204749; Thu, 15 Jan 2026 10:38:13 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgKk1-0003Vn-SI for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 10:38:13 +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 4a8626a4-f1fe-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 11:38:12 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-477619f8ae5so5238945e9.3 for ; Thu, 15 Jan 2026 02:38:12 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47f4b26764fsm39979865e9.12.2026.01.15.02.38.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 02:38:11 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4a8626a4-f1fe-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768473492; x=1769078292; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=+aCDT4mV4mNDqWKbUUKkjVLJcR2an8L/53Ch3xJ+6o4=; b=X0Xr8+NuW3kTsZuC6hd01EEnU6u2LR1kPa8z7Hhm8JYWF921tekCxUFTOAteny5ihg vD9HxYz81lkef+qxfOszMJ2N1Kc/Z54Kh8hrf0dRMefWCit0Sa/zmXHcL2vgls3T6VMk ZN0gk3BI/JsUEP9wjagWlh8ABGlwqC2iYnqpIxFz9Pf7A06lm7mgBDT4Vhs/yf17gGyq YjzqtptdPfcqLaxfhtrECvQN+PmdxEmh5oXhRqykuOGe6w5hBeH+B7BpHBQDr9NP9/eQ JRRchOg7oCbNJt/GgMXuLSt0ARI+IfNmkmkM7lDZCamJy2xqkxuKJ9f/UOtHIH5NOVNJ 7dWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768473492; x=1769078292; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+aCDT4mV4mNDqWKbUUKkjVLJcR2an8L/53Ch3xJ+6o4=; b=bFdvFdl0uYaG2sDD/q+EUvL4BDqlj/vumcnfTJkyBkQ6+fWgsI9vM/vljC5vWAB3Aq xDdEHEC+0GmRtWCJ2UtIcDlalqw8meOuvW/w6mfhCr8TIOxjrw/SpvxMdgaCU+3mJWA+ AlBUZ0cTxAQBZxbqPNTCKCdyq58ACVdgZCM4CAkaw4r+oNM4D9p/BlgelFSwOcBExks7 fLw3MEVTipeJPqEKF9iNCHGeF3qEkvmWk8zvazUIbqJn4W/XhmK7BZ9KefvxgtqpYLuY qYSrr+wyMLiknlpDyq5xuFhhELC8XOPZVPJI0ddWHJv8uQemJ33NV6XSBl6w5HE9WUaB 08WQ== X-Gm-Message-State: AOJu0Yyr7tXSSqGMwArbZF7ejap6VE72ZZw6wnNRWIXV/CzZBtu4DhbI NeUpaveU5NN3NtTxdnPoqZTedXsUwHGfJMtOMPjhngWi3qG2fJvvI8kesgFm3x8iVhqom2/l/rY tZYI= X-Gm-Gg: AY/fxX4Kmv3MW5ZtnwFuu9b9BWpoLGh97+5Q9SnQ69KzdbVN6lV6K7dSISCakM7fV6R q6wB1YOKu2Xor429iOHjQARhnNXRKb/5G3T49nvbaigh+OlYp7bOSS4WCigiIaf060aWUjg2aP+ MU6zJcHVkDA04t5ApFRdLaa4+X2joPfAIhBT6GVwGvYaq9VJJG1jJ5AuxGh1b689xxy60SS2qm1 FJwn4MkJbQnt/aETN3EQh3Dn3MH1ZTRXxcdCKg5b9/1kdI+IC0dYbT1yA8AXfiyhnzL6FU0nfIQ run4N2fYradAK+IyDOJmTMgYx0lRBo/62F6LQ9GpysDrpKy87F65HoLVCtyTVT29ud+3oNNegOi Ry4uL7FJPJiUZCjma+HVLnu8uLA2GsfJ33qiIuFEPeCTQlPbJ7SZSXuMw3eIRhbQyjQDlcjZFc7 GFbpvpTPxRcARTlN5V+C7CcZDXHRG/nIMaC/t4NdVQwyotGfnabJN3AQ0ogeNTIZR2PWVzqjsgB vc= X-Received: by 2002:a05:600c:46d5:b0:479:3a89:121d with SMTP id 5b1f17b1804b1-47ee33b2f95mr67097845e9.36.1768473491850; Thu, 15 Jan 2026 02:38:11 -0800 (PST) Message-ID: <49507100-faa9-4480-a534-e4bab6cecc5b@suse.com> Date: Thu, 15 Jan 2026 11:38:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , =?UTF-8?B?0JDQvdGC0L7QvSDQnNCw0YDQutC+0LI=?= References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <1f539879-3083-41d5-a2c5-c63c9161f0bf@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 15.01.2026 09:24, Roger Pau Monné wrote: > On Thu, Jan 15, 2026 at 09:00:07AM +0100, Jan Beulich wrote: >> On 14.01.2026 18:49, Roger Pau Monné wrote: >>> On Tue, Jan 06, 2026 at 02:58:11PM +0100, Jan Beulich wrote: >>>> amd_check_erratum_1474() (next to its call to tsc_ticks2ns()) has a >>>> comment towards the TSC being "sane", but is that correct? Due to >>>> TSC_ADJUST, rdtsc() may well return a huge value (and the TSC would then >>>> wrap through 0 at some point). Shouldn't we subtract boot_tsc_stamp before >>>> calling tsc_ticks2ns()? >>> >>> amd_check_erratum_1474() runs after early_time_init(), which would >>> have cleared any TSC_ADJUST offset AFAICT. There's a note in the >>> initcall to that regard: >>> >>> /* >>> * Must be executed after early_time_init() for tsc_ticks2ns() to have been >>> * calibrated. That prevents us doing the check in init_amd(). >>> */ >>> presmp_initcall(amd_check_erratum_1474); >> >> Hmm, I should have written "Due to e.g. TSC_ADJUST". Firmware may also >> have played other games with MSR_TSC. > > For amd_check_erratum_1474() we don't want to subtract boot_tsc_stamp, > otherwise when kexec'ed we won't be accounting properly for the time > since host startup, as subtracting boot_tsc_stamp would remove any > time consumed by a previously run OS. For both this and ... >>>> A similar issue looks to exist in tsc_get_info(), again when rdtsc() >>>> possibly returns a huge value due to TSC_ADJUST. Once again I wonder >>>> whether we shouldn't subtract boot_tsc_stamp. >>> >>> I would expect tsc_get_info() to also get called exclusively after >>> early_time_init()? >> >> Same here then (obviously). > > For tsc_get_info() I think you are worried that the TSC might > overflow, and hence the calculation in scale_delta() would then be > skewed. We must have other instances of this pattern however, what > about get_s_time_fixed(), I think it would also be affected? > > Or maybe I'm not understanding the concern. Given the proposed > scale_delta() logic, it won't be possible to distinguish rdtsc > overflowing from a value in the past. ... this, my main point really is that scale_delta() (as its name says), and hence also tsc_ticks2ns(), shouldn't be used on absolute counts, but only deltas. (Yes, an absolute count can be viewed as delta from 0, but that's correct only if we know the TSC started counting from 0 and was never adjusted by some bias.) Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 10:43:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 10:43:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204760.1519338 (Exim 4.92) (envelope-from ) id 1vgKpA-00051m-Ee; Thu, 15 Jan 2026 10:43:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204760.1519338; Thu, 15 Jan 2026 10:43:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgKpA-00051f-BU; Thu, 15 Jan 2026 10:43:32 +0000 Received: by outflank-mailman (input) for mailman id 1204760; Thu, 15 Jan 2026 10:43:31 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgKp9-00051Z-23 for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 10:43:31 +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 07965b41-f1ff-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 11:43:29 +0100 (CET) Received: by mail-wm1-x343.google.com with SMTP id 5b1f17b1804b1-47ee301a06aso7111215e9.0 for ; Thu, 15 Jan 2026 02:43:29 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee27cf06bsm43696195e9.4.2026.01.15.02.43.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 02:43:28 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 07965b41-f1ff-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768473809; x=1769078609; 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=y+JDD4/9/4R79/PBe0tl0vMxBf7RNoPd/Wz2k8GBJck=; b=HPB+ESbfC0a8gqBZAw4BMw1Wq53O25KRFuIKbGtbFXA5q3gWiVKTSiCxToZAIM36hP lvKCxQ8enUovlSkUQdEwDiYWrcPx9qoSierfHHQexkfuWOFmlBgc1DSKg1xBHZNbQOG1 VVhM0U1aALNnM38JvTU7QD5w9myLY6JDqwXdRwiXGwjXI1mfkd/Kx8oTFygpOt7yq377 jmKwx+LldPgkFVqPt3Y3SczhPwJyQf16WoxmN1lcPirL9VOtnl5VfjfhvXzGS9HGJ6DO JMVvyA1/8NowNTaWsb7rr2QZORuwf+jumMf0y/joROSeeZ6VZI3uGQyd8AOAmFDwdkMd P2qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768473809; x=1769078609; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=y+JDD4/9/4R79/PBe0tl0vMxBf7RNoPd/Wz2k8GBJck=; b=kT93sM0UTZ10APNIstDd7/VGwdKkb3tErD4YadVbcntJRYJDm3xPHCp9lA9RJQ34OE DGf8LbSDS4fH9GPpFbpxt/9HX6jb0VvJDFZyMjTx+Pi/TwqegGSi//qEM//Wnl2kzDuK LTTGZbLmXiAfZrl6nNyz30U0iDcWOALdTR6dosBMmwnrJhwzzZLpzkUNUnNKR4b1GWvQ rFUA2eydkEL9abSuVlHHG8x7Sn3KB61h06iv9qhRKNRgpTYWXcHRO9OhuZZBKL+IjLjv gOTPJli46d3QDC6FX0Bp786OrQmfpp75mK1+avLMn6w2bB9GOm9P5nF+waFgnNmWKlSK dyNQ== X-Forwarded-Encrypted: i=1; AJvYcCVZZxOGqyxaKamV2AsVhfTTpuafLDoIR1i3n/AU3c8i6c2lkFiXNHRslwzsjAkzRLQgrp74AwdHTzc=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy9t5ymD5f/aI96e+Ax+hc9MupKGNvsWAB+fjiZbDV5OoY97ZnB xk4RhN3Q6rUse9JTK0em+MbEsBYlnQpjXHQGpG4opdOpFp7rHIlU9xaSLuxl6EmZ3g== X-Gm-Gg: AY/fxX718ByNaIUTjt72OUYK6Fkll8DcvNnjGlaaTo6JcL6LNwMpA2fMqZTtifFEHlP wr/CnkLUfxCiHtfVR878ccX8eIw3QtvAaX4aMelIEu86p/X72bLDFYmCBs/1CyhH6wkqTKexG8P Wx5E5T42VRyoBSlWQTCMK0CZMLPSex/OruuHwG6WXIizxBiRFrxvDxrdfusHeafLA8UvpeTePx2 gYsrQhnql+ZdOO9d5H11It7HZuQyajCeH6sOURVq4YCAOT1t6sovl/jm5TByln67pOSHoluAXWc Yywp9p/H1rrLN/qnfH83YmOyUGc7IT7f8pF0a0MUZh5XgPGWl8pyWWm90nfWw9DzoE90Nrl10e3 Ur5Dsir6R3Kowb6Il7Nt35wV1oGSMf2XInBZWx849u8+J5gwZMZnmkot2EGMGUFE1H47C71ztB7 AUY97rg78MR7jBruvtKVNhh9ZcRgXbqJGW1iVQGbD/kD2LE0MWXI9X5mSedAc8SwjN9qNMsIayF NA= X-Received: by 2002:a05:600c:34c3:b0:480:1a3a:5ce6 with SMTP id 5b1f17b1804b1-4801a3a5f92mr15979515e9.14.1768473808970; Thu, 15 Jan 2026 02:43:28 -0800 (PST) Message-ID: <5d4aec52-03af-4de6-9625-b972ffb5e5b7@suse.com> Date: Thu, 15 Jan 2026 11:43:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/6] PCI: determine whether a device has extended config space From: Jan Beulich To: Stewart Hildebrand 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: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@suse.com> <52eb1293-b5d4-4f7a-b53b-285e4dd274a5@suse.com> Content-Language: en-US Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 13.01.2026 11:46, Jan Beulich wrote: > On 12.01.2026 22:07, Stewart Hildebrand wrote: >> On 1/6/26 08:47, Jan Beulich wrote: >>> @@ -420,6 +467,19 @@ static struct pci_dev *alloc_pdev(struct >>> break; >>> } >>> >>> + if ( pdev->ext_cfg && >>> + /* >>> + * Regular PCI devices have 256 bytes, but PCI-X 2 and PCI Express >>> + * devices have 4096 bytes. Even if the device is capable, that >>> + * doesn't mean we can access it. Maybe we don't have a way to >>> + * generate extended config space accesses, or the device is behind a >>> + * reverse Express bridge. So we try reading the dword at >>> + * PCI_CFG_SPACE_SIZE which must either be 0 or a valid extended >>> + * capability header. >>> + */ >>> + pci_conf_read32(pdev->sbdf, PCI_CFG_SPACE_SIZE) == 0xffffffffU ) >>> + pdev->ext_cfg = false; >> >> I'm using a machine where >> xen/arch/x86/x86_64/mmconfig-shared.c:is_mmconf_reserved() will initially return >> false during Xen boot: >> >> (XEN) PCI: MCFG configuration 0: base f0000000 segment 0000 buses 00 - 3f >> (XEN) PCI: Not using MCFG for segment 0000 bus 00-3f >> >> Then, during dom0 boot, dom0 will call PHYSDEVOP_pci_mmcfg_reserved, after which >> MCFG becomes enabled in Xen: >> >> (XEN) PCI: Using MCFG for segment 0000 bus 00-3f >> >> On such machines where mmcfg/ECAM is initially disabled, this will effectively >> set ->ext_cfg to false for all devices discovered at Xen boot. >> >> I'm not really sure if I have any good suggestions, but perhaps we could add a >> macro or small function that returns something like >> ( pdev->ext_cfg && pci_conf_read32(pdev->sbdf, PCI_CFG_SPACE_SIZE) != 0xffffffffU ) >> to allow this checking to happen dynamically (but this still wouldn't handle the >> aliasing quirk). Maybe re-run the ext_cfg detection logic at the end of >> PHYSDEVOP_pci_mmcfg_reserved? >> >> Regardless, I'd be happy to provide my R-b without this addressed, but I am >> curious if others think this as an issue? > > Hmm, no, I forgot to consider that case (which in principle I'm well aware of). > Will need to fix in v2. My reply yesterday was actually not quite sufficient. On a system like yours, isn't it the case that PVH Dom0 then also doesn't work quite right (yet), due to parts of vPCI depending on extended config space accesses now? All of what we presently do during boot, and which requires extended config space access, would need re-doing once extended config space access becomes available (or goes away) for a (sub)set of devices. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 10:49:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 10:49:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204777.1519348 (Exim 4.92) (envelope-from ) id 1vgKuS-0005pw-0a; Thu, 15 Jan 2026 10:49:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204777.1519348; Thu, 15 Jan 2026 10:48:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgKuR-0005pp-UA; Thu, 15 Jan 2026 10:48:59 +0000 Received: by outflank-mailman (input) for mailman id 1204777; Thu, 15 Jan 2026 10:48:58 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgKuQ-0005pj-Oe for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 10:48:58 +0000 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170100009.outbound.protection.outlook.com [2a01:111:f403:c107::9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c9c5e020-f1ff-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 11:48:55 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SA3PR03MB8253.namprd03.prod.outlook.com (2603:10b6:806:460::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.6; Thu, 15 Jan 2026 10:48:52 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Thu, 15 Jan 2026 10:48: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: c9c5e020-f1ff-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=cNHTZ6YSwe3K6lsme5ecCkrmm60mbukPGJjx0Mhc2Lr+Bat+60Nmty5Oe8UXoNIRN+tyQE9LjVIX6wusho4Prtup5ofxNL2zbkpFZE23329hi06JlmvjVhBTfgJsPGD3Rnk6X0dQ+1YYljiBCCzGBjKx9QCFdUdojZnQRQiBl5Bjaf8kxHcICiI5CHacwqSNucBEWLXU6U1GbiDl0D0Z7QNXqIpNXCwVVdB/kJlpUxtw+fDVGjAZdvMZr6tvP89BitBlLQuJF6mIhV9lIY16EaLe1Ayg0rKCBYucGp4RcqghXzc1LB0h9xzp+gHRREkh6HWwNZSxJNTaFxz2OrF5HA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LlVpFKCHmOhYc/17Woga3RbyZhaYj8zZbHJcIq5OwbM=; b=pzWMbracWm78c1WwN5dY2pUwyGz4eTCTL7NF//M/LDNSlYJBDBAeSbljGBHjAxRBVYrdS9sXudpLW5JscYUbrxlKi053wgJX7mvQh4LIzKSm6qnvUXATUlB4beqI9HHbeDVyABoZnNqAUhq3cpCl2eOqVcogyKc9JK6iXBSzUqgCcK5OEdSwqtezlaKFbiUsI132jv4syN/yoJXPQ3arjL/Pp4JSjVxH0P8AC1H93qBy+fxde0QB5ydSpsheg5rqaMagVyO5opJ9ox/YJ94+6FoyhmXdoS106xwHBBQnFZwNbJMsc+j9p8l6Spu8/v/cETjY4uvF7+Ay1PRVsYmC9w== 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=LlVpFKCHmOhYc/17Woga3RbyZhaYj8zZbHJcIq5OwbM=; b=c9hNJbl0yH0+5ASIlOzUXXZsd+2OdiVIUWxcZhNwT1oIxH5SVCHJi4usAQid5UkeHjrOB9ceU6FkmJMq3N+kzeOLAXWyO0EjUshFn38cqCzYOaEGscAoSPmc4b1MMQZxs2UQdWoGTj50j5nn1CYCq2/Wz+dhdJwAU4VVhAyzwrA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 15 Jan 2026 11:48:47 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH 2/2] xen/mm: limit non-scrubbed allocations to a specific order Message-ID: References: <20260108175536.82153-1-roger.pau@citrix.com> <20260108175536.82153-3-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: PAZP264CA0208.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:237::21) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SA3PR03MB8253:EE_ X-MS-Office365-Filtering-Correlation-Id: 01f6bdd9-a4ff-4295-d83b-08de5423abc6 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?YUdBaFVGUS84S3dBL3RhZnF3M1FSL3hta2U4Q09Qd2VMVTlTSFhRTDBFeWk0?= =?utf-8?B?a2ZnMm5LMmRBbWpZOE1Zc1dHZ1RBS2pESVBVdXpsbm9FelB2UngrdTNSSW53?= =?utf-8?B?c054RmNEcXVKN0pIdXRvYklaTDFsZFJua0xRU2l2RHRGMjRzUTBtRHV5bUti?= =?utf-8?B?OWs1TzNmTnNQT3loa0szWllYUlFEbnQ3emV1WUVUb0ZZNkN1dVBESmVLTFNY?= =?utf-8?B?WS9vRVJjckJERVNWTFBJRStJVVJKYk9yUGIyYjdGVElWaTRWcmdHVGxBc0M5?= =?utf-8?B?b1V1eWFNMFU1czI5ZjNZclcrTE1CcmpGd1E0dGFIdm92aGx4V1IzaTF2N29x?= =?utf-8?B?QnAvOUxUSHlpdEdpSjhuTEJ2UmpqeTNKV0dLWGtsejZEM2NraXIzSnNWWkJF?= =?utf-8?B?cDhiRzhYTXBEM1M5cDFFWjAwbzd3ZjV5VCsxcGRiOXRlVXZOaW5ucjhodXVU?= =?utf-8?B?UkpmL0o0cTVxTmZxMk9kK0U4SExWSEhaUlYrdFllKzY3RlJoWkNzTTN0dHl0?= =?utf-8?B?bTBwVUlpa2g0TjBSZ2xqZVcwZklORzZOK29lMEVTcGFrUm5NT0FhcXR3MU11?= =?utf-8?B?QmJnSnpSSmZuVW5DT053WTAvVVB4a05FVExvOFpiQVdWL0lDOFJ1Y3MvYWFD?= =?utf-8?B?OHBnN01qQTEvd2g3NkUvWElxaTU1M252a1o2djBBZkNYL2ZrSjFVSmpqZ1px?= =?utf-8?B?SkxCQ21RZ1FjYlBLWVhnZ2xJczliSisrQVlLNnEwOEdJUFA5eUVuL2d0czRP?= =?utf-8?B?Y3VVR3p0YlFxUFlVbFBUR0U1Mmk1SFcvaDk4NkMxeFhRVit5VXg1WGhTMWhI?= =?utf-8?B?MW5Wd2g3cXRhK1dnaWsvMnNrakZNbU5CWHovdFNmN05DOHRndmFnOENzRHVF?= =?utf-8?B?bkNFcFB1VVZiRnBicEYvOUs5cHhQYmNjL09CcFlkR250aHdPZ211UjR2Y2tP?= =?utf-8?B?eVRZMTNQY3pSbk0vU21rY0pTWUhXSTBFTE5pbm16TkpqSVdyNm9mTkFPNTQ0?= =?utf-8?B?YlphWUoxRVFiclFXMnhNd0VlUEd0VDhEL01CcnhIcjRpd3IvYkgzZGtTRDFn?= =?utf-8?B?VXBSa2REZE85ZFRNb0ttaWZlQ2ZlSG9XM1J1aW1YdlNTcldOMzZsRXAyMFQ5?= =?utf-8?B?L1lmdHA0RS9MaW1kZk8yWHgvLzVsZ251d1FBbHJtbHY0cU5qUFY0MUhiQm02?= =?utf-8?B?bXhNemR6dEVBY2MyRG94QUVZMGN3Wm43akVEUGszdTJTK2NmQTNnYTRVNnBl?= =?utf-8?B?NFJvY3NGcHl6QlhVM0ZHSUQxSnhXQVZtMmt0SmZ5cjkxNXNxUk1SWFR6aWtN?= =?utf-8?B?a0I2VXRHOHV6aXNGV3gwL2V2VFFXbC8rd1hWOHdmbDU0b2UyVWV5SGF6cENq?= =?utf-8?B?MDhWanRUSFRYNU4vMTBXSmlyZ3hFSXB1cVhPUlJ2c3NLYXptMHJydDg4dTJp?= =?utf-8?B?SkJFOUVQN0JOWWhaSlhrUHUzWmxNQmRtQmljNThwTzdKUkgxQ1VwdlljNU5u?= =?utf-8?B?NnpqVnFnNmxNQ2NDWm5DWlhpQ29FT2RtSHV6MzVWQUtvMGxFOWZLYkI3VjU4?= =?utf-8?B?ZXhjQ05xLzZjNmdQYk5YYm9ISVVYK3RlSGFRTWFBbUV2Q0dLSVVIV0RETFA4?= =?utf-8?B?MGRINW9CN0d5VU9MZ2ZPaCtHdG9IRzhTUU1DUFQ5d3BvTTEyV1VtOW5VRVdF?= =?utf-8?B?VU9UZTdmVkdmRmtnbW1zaUo1d1BiTDRWeDFOSjRDS3pPcENXQVY0NEtiWEcv?= =?utf-8?B?Y3Q3WUtTc1E3a1F0OUtLSm5vVkNzejZmU2hNUTdqQlo4YnBRM1JCU1AydE9Z?= =?utf-8?B?Z1djY1FYbUlnR1QrWlluNnptc0hpeUkvUDdqcTNjYXA1RWxVZWV3K2RKZ29T?= =?utf-8?B?TVh5MTRXeU5Td0RLcm02UW9SSkM5Ui9CRFgxanJCZ3JkZDJSNEtKbU4xeTJW?= =?utf-8?B?WjF6QWhtcDF3QncxZk9iSUxYdy9HQTRDRGNjTWg1NEVDb0hhZGhVWWttUkdy?= =?utf-8?B?Z2xIT3JnMldNS0RwckhtSk9sbWFZenYvbU9HS2NiWERsdVlVQUd2S3pVMXM1?= =?utf-8?B?U3ZMaFFqN09INnFtSjhSbE1IYitpZlhuUEVpL050dFlwSXh1YzRjclZNNlFB?= =?utf-8?Q?zIqc=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?a1FSZUxaK253bFc5eUVNSlBJYVduMHg3cmNYTm9PNXpHZk5IbXNZajdjL3RL?= =?utf-8?B?TkY0cFJuMnkxTlNyZ0JtRTZiT0QxOFlCeTdEeVllMGtrUDhYRmVNOGdtZ3pq?= =?utf-8?B?aDdiZWNWVTJyU29oa2VzS2VpYkZaSGJjaUlNaTUxenpWaVlyWFl4aGpMb3B0?= =?utf-8?B?Y3luRG9pcThNdklpM3dFdWUyQWxGcStjUTJ5bXhxSFhpVEM5aVkwMlpPUGJy?= =?utf-8?B?TnVnbzFsOStTWTdoQnRmaTEvTGEvdzg3dVMrdG1EUjlYQWYxbHVlTTVrNjBr?= =?utf-8?B?NWk0L01nOEI2c2RaYjBxNEFqQVdkTDQ1TDVYVUdnQ1lhQ1N5a1Q1cHpsUmpm?= =?utf-8?B?ZSt3MXZqdlU3SkR3Mmt1VUlZcm9heWUxYWNaSExuZUtuOWpXVnZxOURnTmVh?= =?utf-8?B?Z2xJdkJyY2ZaNit5TTVaR3hGcTN1VnJCVmFSamgwRktUMHZDZUFrWHJNaWpm?= =?utf-8?B?dFRiRnVDcW14WVU3a0FvbDdVZFVPdEhwVWU4U1l2TlVmc29FdEFpOFJGbmw4?= =?utf-8?B?eWNlY2dnZFBxLzAzd2ZYREpnV3padi9lWW90Sk9qNVMvdm80aE9zbEQrYXBm?= =?utf-8?B?TE02eSt5N2Y4Wk1WTnI2KzRuOHFFakYyWFExTHIvMXR3VUl2NE9BN0N2VGhW?= =?utf-8?B?bU1rSVFGaUZna0FCRmRPVlpyS2YxOVV5MmFOM0ZTb0EvR0xSL2pwZlU5a0l0?= =?utf-8?B?NlBKamZ1Ylp2allyMk9YWXVndElPRkEvR0ZJaEo2a2lRNFVpODNVMEM2REhK?= =?utf-8?B?MzdUYjhmN3BPbHp0VW9HUmdMNFkwdmRiUTNRc3FyRVpSRXlhZHk1cWNuWDQr?= =?utf-8?B?NE02TG9yS3BETHhzODhYTVpsU0JwbGZQanB3R0NIdWE1Qks1SVJic2Nsc0ZU?= =?utf-8?B?Wng3RmgzV0UrTmRVK2trbExScXJoeTRseHYzazVYRUNCekhhR2x1by9yVGpw?= =?utf-8?B?SXRPQjNXK0M0anFvQkxPSklLR0Z3ZDg0cXlsV01PTmdtYTBodHBYc2F5OGJu?= =?utf-8?B?L3liNG1WcnhaMC9SN0x3K0V4SHREWkV5NWt0Y0RVNmo1bVRTREZQeWc3RHZq?= =?utf-8?B?MkVRckpseTIxMFF0Y0pwWVVTN0plUnJmREZ2UjJLOWFEMmFtUXN0UGtMcnVG?= =?utf-8?B?MEdVOW14SEIvSHQ0RTBUWk5udWtmcWJvd29VUFU0OXJmMTVqbGJPQzFpamlj?= =?utf-8?B?VWo3R2RkaFRsWjJYdnVOdE5KN1ZFMldSYXRyd2ZUd20vcHBNbVM4bUhIWDU2?= =?utf-8?B?ZGhqNkdUR1dyWkw5Z0ZnaXlJWktJdUQyeXNTcU1SMkZYajFPNVRZVU1VcmxD?= =?utf-8?B?WmlkVGdVZ0VHKytNUGJpZU1qMlE1UUVyRE4zMytvU0lpbXZxMHJmYU8xbTJP?= =?utf-8?B?dHpYNWVpL2ljV3dEWG10M2oyVkN3ZFBFUFVrYSs3YnBkU3ZiMlVISFIyT08v?= =?utf-8?B?UW80enZpdzcvTWl6d09vQXlNSS8rcGdHK0JLYzFpRnZBbVgzKzYrMmFPNFpp?= =?utf-8?B?TWQvTU9Bbkl1eWZ3cEJpZ1A5VFZZVjMwRG02Z0RVdW05UUdabU9NMmV0c0I5?= =?utf-8?B?K3IyS1huaTlYVHBJWE94Mml6NTZHV3QxTkZUcW9rSlBmVHB6cUVhRHpDOFRO?= =?utf-8?B?akZtbGJib3lHYktrV2Mva1doK2s3cnllbGFNVUJkTkc4cThtMmROOHJISDlp?= =?utf-8?B?L2diSW9KWUFQejE4L0Y4cGc0Y3hxNXdWMHhyOGlQdXI2dkxLTmx4UkswOE0v?= =?utf-8?B?bGMrdEdXcDhRVU52bDVwVGx6MWhsVHQ1ajhpRGllc0RDL1BxT0JsWkVhclpF?= =?utf-8?B?c3R0Y0F1QnVZY0F1TkVYQktWejZzbkpNLzM2MnNaRHpSdTBCRlF5aEQvTitz?= =?utf-8?B?N2ZXdjdHZnVMMDhWVTI4Q1RodVZFVStDZjJ6a3RxTzVETUFWK2pXdVBYdGpx?= =?utf-8?B?YnNkMndsS2RIYzhWYmg2QnN1K1RaUDkrUTUxbC9zRHhJY3lSVVB3NGY2aFhO?= =?utf-8?B?MFdrR3lLN2RVTVV1NmJvZDM0SExqekdoVXN1MHVQUGprb054Ulc5VC95OUs0?= =?utf-8?B?S25tUk5mQ1lyUDRsaFE3ZEJyQ0QyY1R3dDUvemxQTnlhbEFVTUNKbnRlU0Fm?= =?utf-8?B?VW9hWmdBUzg0cFlBV0dERG5HSkFCL0JwL2Frdkhyc0J6U3BURGV5N3hGOWtv?= =?utf-8?B?ZXBlUlFjVzdLUSs1eHpFcFdLYUpsY04rb1ByelRzcTZxTDR6RVM0VmU3U0ZM?= =?utf-8?B?V2l3bjh6UWptTjJ6OUh2ODFLd3VIM3VQci9jNXZCUzdvMDdXUHdVM0JqSVVY?= =?utf-8?B?UHhNb2ZrbTdWdE5XQXR2MEVha0pXbTVtbWlKRnF6RndINTA0ckNZUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 01f6bdd9-a4ff-4295-d83b-08de5423abc6 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 10:48:51.8134 (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: ltOJKC9VGljHuhWv97sqFe1LFSSoVDEyVZMq/Yu3bbw6h3SUoDc8upFJ5Zuw7Y4f79DqtU1vvl6Bwukkol7NQA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR03MB8253 On Wed, Jan 14, 2026 at 09:48:59AM +0100, Jan Beulich wrote: > On 13.01.2026 15:01, Roger Pau Monné wrote: > > On Fri, Jan 09, 2026 at 12:19:26PM +0100, Jan Beulich wrote: > >> On 08.01.2026 18:55, Roger Pau Monne wrote: > >>> --- a/xen/common/memory.c > >>> +++ b/xen/common/memory.c > >>> @@ -279,6 +279,18 @@ static void populate_physmap(struct memop_args *a) > >>> > >>> if ( unlikely(!page) ) > >>> { > >>> + nodeid_t node = MEMF_get_node(a->memflags); > >>> + > >>> + if ( memory_scrub_pending(node) || > >>> + (node != NUMA_NO_NODE && > >>> + !(a->memflags & MEMF_exact_node) && > >>> + memory_scrub_pending(node = NUMA_NO_NODE)) ) > >>> + { > >>> + scrub_free_pages(node); > >>> + a->preempted = 1; > >>> + goto out; > >>> + } > >> > >> At least for order 0 requests there's no point in trying this. With the > >> current logic, actually for orders up to MAX_DIRTY_ORDER. > > > > Yes, otherwise we might force the CPU to do some scrubbing work when > > it won't satisfy it's allocation request anyway. > > > >> Further, from a general interface perspective, wouldn't we need to do the > >> same for at least XENMEM_increase_reservation? > > > > Possibly yes. TBH I would also be fine with strictly limiting > > XENMEM_increase_reservation to 2M order extents, even for the control > > domain. The physmap population is the only that actually requires > > bigger extents. > > Hmm, that's an option, yes, but an ABI-changing one. I don't think it changes the ABI: Xen has always reserved the right to block high order allocations. See for example how max_order() has different limits depending on the domain permissions, and I would not consider those limits part of the ABI, they can be changed from the command line. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 15 10:55:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 10:55:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204797.1519359 (Exim 4.92) (envelope-from ) id 1vgL0r-0007R5-QP; Thu, 15 Jan 2026 10:55:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204797.1519359; Thu, 15 Jan 2026 10: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 1vgL0r-0007Qx-Mg; Thu, 15 Jan 2026 10:55:37 +0000 Received: by outflank-mailman (input) for mailman id 1204797; Thu, 15 Jan 2026 10:55:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgL0r-0007Qr-0c for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 10:55:37 +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 b76ddba5-f200-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 11:55:35 +0100 (CET) Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-65089cebdb4so1170495a12.0 for ; Thu, 15 Jan 2026 02:55:34 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-654120840dfsm2230564a12.27.2026.01.15.02.55.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 02:55:33 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b76ddba5-f200-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768474533; x=1769079333; 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=C12moZQp1Jlz4eDJh1Ln6w399/SbVfOuWsYDoQk6hyY=; b=QzB0SOu7v+NHkBmbLht6NcNwggRDG28OZ1J7WfAuRetDpi0zEv5xxNAAVp8LXoMNsX Pw4bz/Mq7ORknKzYdhrSdCMOw0uS7HYW5jtrZtgXZgS47zU8//NKHRi+4FV7DBVyB1De TXLh98+zYVlv8Kyn+XwVWco1OzSD6exNro+NEWwX08IrNdmieDg/R1hnavhL7yvNECXO BCu2EJYfWLkFnJIBGVJPi1Dqm5HOgpetqagJoADWGcYzVuFwHFEzHdM1sFFJG1jqkHwG oy5bZqma0H83ZEiekfBTXDv5V5CbSijwVALzojzDHoyrzHJ2hCzbONiwFkTx+UTFgzIJ YolA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768474533; x=1769079333; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=C12moZQp1Jlz4eDJh1Ln6w399/SbVfOuWsYDoQk6hyY=; b=XgqIfgHlmmhmZsNpIY/2l6pAkHbRHa8jUK5fw0JAgpOFquVaqLNWNZgAET1ofdt0yn aUjsEzycowaR+tfBeGdRUhYI2fvO1ABXA5n1stu9aP31k8eTKLoVxWeDRskTWAjfByjB jZxUoxFzlkaR1LinwTayzLFTDeLmj3Qb7pylvedoH6HP/aSko9tRZbAJGDwPTamM11UA zfT4Qp1GBKoW3/FkFxrPzoQOpoEho4/S8dhgs5CCqqXHYp25dgEmbLkwPK2Vv3v3TB0i B/pJa6R5FACvD4Uvfl1uc9n28CwSAvKbEeSlFEFAVznE7m4btIyyz3JZ995GX288/16F Auyw== X-Forwarded-Encrypted: i=1; AJvYcCVxd9WgTkKb2x6KKNxf515pS/IKWfLOyc1Bm85A6+zfDzzSZrrn7KMdOaGMeulcBKvtOLYthQrZiEA=@lists.xenproject.org X-Gm-Message-State: AOJu0YxYUdnBLBE30C1WWR2mobG3jteXftTHjcBt6kd+jCnq4lLrGoOZ wvw/M4Y0wuXia5ZSg/jDD1DTocmaG/pqBq8TrR/caoQBLTiqyx1+Z8hC X-Gm-Gg: AY/fxX6hAw35dPauAemdmj0h9MtWxmK8pRbGRUlR911x+64vRR30HNM7IE2VUevxiwr HPR8i6MEA/2pkblbS3P4EoO+PKWi1muA9wHydc9QuGX+uCy31+vmnPa+HzOM8FxR9aTYiYJ3eL1 niTUlFRwORn4n6rELZ95f00+EJIPeF3fq5Z0upc1T+amDjjJ9Xb6pdhx6h+JfxhHEM/Xk1UAqkh naB66oKniVjotccfLO/22u3fvBQPCksmCOitz2T/h3crUXL/lpRvIJs8QAFMokyBenj1BnHq5sq 5+uOKA6iWUq1339IybtbrNxmTxaEl0nq9sJRejV2srfds9UBQ8cPsk26jx0NYS5bF/7S5TYgy3B HAfYMFjzEHNEQiAkMok8q/rvQGBMWJ18lpKw8xpNw5MQBd/hfMsaBkWEthlY5yfM6YN3dLQ8lMe mHDrAnNSFVcAmm7C2JjMs6Y53DSTYneoNom44Ne1ZEvx6jnT1jo/vpohJ/1sWACKJggmNosiCsc w== X-Received: by 2002:aa7:c50e:0:b0:650:8a2c:43de with SMTP id 4fb4d7f45d1cf-653ec4744f0mr3393130a12.29.1768474533311; Thu, 15 Jan 2026 02:55:33 -0800 (PST) Message-ID: Date: Thu, 15 Jan 2026 11:55:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 07/15] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <7a90cc1b-b053-4b9f-91f1-d32064b1ec29@gmail.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 1/15/26 10:52 AM, Jan Beulich wrote: > On 15.01.2026 10:14, Oleksii Kurochko wrote: >> On 1/14/26 4:56 PM, Jan Beulich wrote: >>> On 14.01.2026 16:39, Oleksii Kurochko wrote: >>>> On 1/13/26 2:54 PM, Jan Beulich wrote: >>>>> On 13.01.2026 13:51, Oleksii Kurochko wrote: >>>>>> On 1/7/26 5:28 PM, Jan Beulich wrote: >>>>>>> On 24.12.2025 18:03, Oleksii Kurochko wrote: >>>>>> By maintaining irqs_pending_mask, you can detect “this bit changed >>>>>> recently,” even if the final state is 0. >>>>>> >>>>>> Also, having irqs_pending_mask allows to flush interrupts without lock: >>>>>> if ( ACCESS_ONCE(v->arch.irqs_pending_mask[0]) ) >>>>>> { >>>>>> mask = xchg(&v->arch.irqs_pending_mask[0], 0UL); >>>>>> val = ACCESS_ONCE(v->arch.irqs_pending[0]) & mask; >>>>>> >>>>>> *hvip &= ~mask; >>>>>> *hvip |= val; >>>>>> } >>>>>> Without it I assume that we should have spinlcok around access to irqs_pending. >>>>> Ah yes, this would indeed be a benefit. Just that it's not quite clear to >>>>> me: >>>>> >>>>> *hvip |= xchg(&v->arch.irqs_pending[0], 0UL); >>>>> >>>>> wouldn't require a lock either >>>> Because vCPU's hvip (which is stored on the stack) can't be changed concurrently >>>> and it's almost the one place in the code where vCPU->hvip is changed. Another >>>> place it is save_csrs() during context switch but it can't be called in parallel >>>> with the vcpu_sync_interrupts() (look below). >>>> >>>>> . What may be confusing me is that you put >>>>> things as if it was normal to see 1 -> 0 transitions from (virtual) >>>>> hardware, when I (with my x86 background) would expect 1 -> 0 transitions >>>>> to only occur due to software actions (End Of Interrupt), unless - see >>>>> above - something malfunctioned and an interrupt was lost. That (the 1 -> >>>>> 0 transitions) could be (guest) writes to SVIP, for example. >>>>> >>>>> Talking of which - do you really mean HVIP in the code you provided, not >>>>> VSVIP? So far I my understanding was that HVIP would be recording the >>>>> interrupts the hypervisor itself has pending (and needs to service). >>>> HVIP is correct to use here, HVIP is used to indicate virtual interrupts >>>> intended for VS-mode. And I think you confused HVIP with the HIP register >>>> which supplements the standard supervisor-level SIP register to indicate >>>> pending virtual supervisor (VS-level) interrupts and hypervisor-specific >>>> interrupts. >>>> >>>> If a guest will do "That (the 1 -> 0 transitions) could be (guest) writes >>>> to SVIP, for example." then the correspondent HVIP (and HIP as usually >>>> they are aliasis of HVIP) bits will be updated. And that is why we need >>>> vcpu_sync_interrupts() I've mentioned in one of replies and sync VSSIP: >>>> +void vcpu_sync_interrupts(struct vcpu *v) >>>> +{ >>>> + unsigned long hvip; >>>> + >>>> + /* Read current HVIP and VSIE CSRs */ >>>> + v->arch.vsie = csr_read(CSR_VSIE); >>>> + >>>> + /* Sync-up HVIP.VSSIP bit changes does by Guest */ >>>> + hvip = csr_read(CSR_HVIP); >>>> + if ( (v->arch.hvip ^ hvip) & BIT(IRQ_VS_SOFT, UL) ) >>>> + { >>>> + if ( hvip & BIT(IRQ_VS_SOFT, UL) ) >>>> + { >>>> + if ( !test_and_set_bit(IRQ_VS_SOFT, >>>> + &v->arch.irqs_pending_mask) ) >>>> + set_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); >>>> + } >>>> + else >>>> + { >>>> + if ( !test_and_set_bit(IRQ_VS_SOFT, >>>> + &v->arch.irqs_pending_mask) ) >>>> + clear_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); >>>> + } >>>> + } >>> I fear I don't understand this at all. Why would the guest having set a >>> pending bit not result in the IRQ to be marked pending? >> Maybe it is wrong assumption but based on the spec: >> Bits sip.SSIP and sie.SSIE are the interrupt-pending and interrupt-enable >> bits for supervisor-level software interrupts. If implemented, SSIP is >> writable in sip and may also be set to 1 by a platform-specific interrupt >> controller. >> and: >> Interprocessor interrupts are sent to other harts by implementation-specific >> means, which will ultimately cause the SSIP bit to be set in the recipient >> hart’s sip register. >> >> Meaning that sending an IPI to self by writing 1 to sip.SSIP is >> well-defined. The same should be true of vsip.SSIP while in VS mode. > I can't read that out of the text above. To the contrary, "will ultimately cause > the SSIP bit to be set" suggests to me that the bit is not to be set by writing > the CSR. Things still may work like this for self-IPI, but that wouldn't follow > from the quotation above. Why not that wouldn't follow from the quotation above? The first quotation tells that we can do self-IPI so VSSIP.SSIP will set to 1 what we could miss SSIP bit if won't explicitly try to read h/w HVIP (or VSSIP, or whatever other alias of the SSIP bit) and sync with what we have cached in hypervisor. The second quotation tells that if another CPU send IPI to CPUx then CPUx.SIP will have SSIP bit set to 1 and again hypervisor won't know that without explicit reading of HVIP (or VSSIP, or whatever other alias of the SSIP bit). > >>> You can't know >>> whether that guest write happened before or after you last touched >>> .irqs_pending{,mask}[]? >> Yes, I think you are right. >> >> On the other hand, if we are in hypervisor when vcpu_sync_interrupts() is >> called it means that pCPU on which vCPU is ran and for which >> vcpu_sync_interrupts() is called now executes some hypervisor things, so >> guest won't able to update VSIP.SSIP for this pCPU. So nothing else will >> change VSIP.SSIP and so h/w HVIP won't be changed by something and it is >> okay to sync .irqs_pending{,mask} with what h/w in its HVIP. > That is, vcpu_sync_interrupts() is called on every entry to the hypervisor? > Not just during context switch? It is called each time before exit from the hypervisor to a guest. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Jan 15 10:56:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 10:56:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204805.1519368 (Exim 4.92) (envelope-from ) id 1vgL1Z-0007u1-1a; Thu, 15 Jan 2026 10:56:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204805.1519368; Thu, 15 Jan 2026 10:56:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgL1Y-0007tu-Um; Thu, 15 Jan 2026 10:56:20 +0000 Received: by outflank-mailman (input) for mailman id 1204805; Thu, 15 Jan 2026 10: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 1vgL1X-0007Qr-RE for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 10:56:19 +0000 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [2a00:1450:4864:20::331]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d1f0ee4d-f200-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 11:56:18 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-47ee807a4c5so5576765e9.2 for ; Thu, 15 Jan 2026 02:56:18 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee2a5e48asm39939555e9.20.2026.01.15.02.56.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 02:56:17 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d1f0ee4d-f200-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768474578; x=1769079378; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Za7Gq1jYLlWSX1PBmn/AuaZtv3+lx9trnFsAxr1SdSQ=; b=FvInh05UWvVVs80LXXUxKx4IbbIeOXRVKYItkLpnrki7s4mwAwetgnDmhMfSPFFOy0 yIjysvQUGo+NUFWgukj9Dl+lqBSuNS41q0rl7kNRiZAd84r1fAdFoBRscQ+3lLA2P1ci Bd8EqrfOCdnd4fU0Y5jSATVtXUB+5QM4aqe0OE+Tifg2EbOdcpZxGknxAd3rHQI6MCBk U8xtaGI9siKRvfmLoD5MWl4tO/1Wvozl4fXCNmipvP6x4QFymvgQJ55RbjX2dF/VLRj3 oQfYOdNNhr42K/L4JkP9RCj9EyJgXBP59OEnKKUaJrKVWLdIJXky16JFtSzZLZ8+Dm60 BqOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768474578; x=1769079378; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Za7Gq1jYLlWSX1PBmn/AuaZtv3+lx9trnFsAxr1SdSQ=; b=L09Y0qa1kf2CopJahePebMcrDp1dAKj8rS4uELDFb+cpuuZYkmwVM3aO+0R2B+IsNE MU/7wVXg/dNLiQTnigrW7asuyzucaVFfX0IMqFcR3jibAEyrYbOlsmdQTmCZJk7wfzFs 2dqsKorF4eIgEUXI+KNtTSf0a94mSaabZ0X91zjiJcvN7Uli6N3K/HfgHCpyt3hL5k8i fhdLkRsShxGD9yO1QTRTtZiL6v0bro/xxLYOv/CoJ+pceo5Hc+hHvDEvguvYbCpZAEVT uwVN5gWuE13clIWc1aawiA4QGODVM8zNFaa21Z5ZrGv7UXbcRc23rw9nQCq85yDu3IE9 0klw== X-Forwarded-Encrypted: i=1; AJvYcCU+I7yG9GMpgoxX0bng8Wq4831k5XQPOANewOswGLBP2RHWRi657QzVKwnLJaeyJrmdXyFazl9h0iQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YxYV18zgRx4VjKdB/0D1I7yoAh5+ZYSl/Te/vW+8sgetJz062Qo 9PvopYtLrdqegI9UerQBkWEiclrPY2AWFLGk3w1iZ3Ji3C140LqAEU7mcdFhOJmvOw== X-Gm-Gg: AY/fxX5Xe/oGTjVqmLXGJjuZ/6WYzQzylYRMi2ACUirNg+7hF+A51jgE6fnBXsa4h19 iWTvscyW4xxoWAyanYv5SRkmGZJv3AUjSgtMY+/aAG1Bj8ncxjfFqzRDa8Q7+wXCpljCEKJv7Z5 sWDMsJQsTRCiq4tG/cIvV9E7oRQkAieGQHAPM/GlKd3hgzFv06zkzl8CPv1PJoGwxjOWnCQYxKO s3sHFuSpLFpSZDr4BASZeZRQx0wRAg8VUOMz90ZX2DOr0+PkWCkO7fevZkHmEnVoWQSt7oqJpSD 2lkXPZtDn5XVo+j2gzZZcUibVdo8msE8pydc7D8WuHZFZDyUMLBN9WPs53n9D7QJs0H2UJ9t7al y9UZPJDQ1ZOXNKZEnwyG+PlDYfUYKRZzzcVJUW0BwyfkRTFODEmTdLByRzMdquH8MVnpj8lNxYG g49AbfqfITrRlGAoIcghp6AcD4vNe9CsDCfvnq990Kjn/otxYKKw7medU0SsViNmSsqLeZlNakT xNiqrFaHPlHog== X-Received: by 2002:a05:600c:528b:b0:480:1d16:2538 with SMTP id 5b1f17b1804b1-4801d162823mr2914125e9.23.1768474577990; Thu, 15 Jan 2026 02:56:17 -0800 (PST) Message-ID: <14560e88-bbd5-48e1-848e-e53a3237d16b@suse.com> Date: Thu, 15 Jan 2026 11:56:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] xen/mm: limit non-scrubbed allocations to a specific order To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260108175536.82153-1-roger.pau@citrix.com> <20260108175536.82153-3-roger.pau@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 15.01.2026 11:48, Roger Pau Monné wrote: > On Wed, Jan 14, 2026 at 09:48:59AM +0100, Jan Beulich wrote: >> On 13.01.2026 15:01, Roger Pau Monné wrote: >>> On Fri, Jan 09, 2026 at 12:19:26PM +0100, Jan Beulich wrote: >>>> On 08.01.2026 18:55, Roger Pau Monne wrote: >>>>> --- a/xen/common/memory.c >>>>> +++ b/xen/common/memory.c >>>>> @@ -279,6 +279,18 @@ static void populate_physmap(struct memop_args *a) >>>>> >>>>> if ( unlikely(!page) ) >>>>> { >>>>> + nodeid_t node = MEMF_get_node(a->memflags); >>>>> + >>>>> + if ( memory_scrub_pending(node) || >>>>> + (node != NUMA_NO_NODE && >>>>> + !(a->memflags & MEMF_exact_node) && >>>>> + memory_scrub_pending(node = NUMA_NO_NODE)) ) >>>>> + { >>>>> + scrub_free_pages(node); >>>>> + a->preempted = 1; >>>>> + goto out; >>>>> + } >>>> >>>> At least for order 0 requests there's no point in trying this. With the >>>> current logic, actually for orders up to MAX_DIRTY_ORDER. >>> >>> Yes, otherwise we might force the CPU to do some scrubbing work when >>> it won't satisfy it's allocation request anyway. >>> >>>> Further, from a general interface perspective, wouldn't we need to do the >>>> same for at least XENMEM_increase_reservation? >>> >>> Possibly yes. TBH I would also be fine with strictly limiting >>> XENMEM_increase_reservation to 2M order extents, even for the control >>> domain. The physmap population is the only that actually requires >>> bigger extents. >> >> Hmm, that's an option, yes, but an ABI-changing one. > > I don't think it changes the ABI: Xen has always reserved the right to > block high order allocations. See for example how max_order() has > different limits depending on the domain permissions, and I would not > consider those limits part of the ABI, they can be changed from the > command line. When the limits were introduced, we were aware this is an ABI change, albeit a necessary one. You have a point however as to the command line control that there now is. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 10:59:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 10:59:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204817.1519379 (Exim 4.92) (envelope-from ) id 1vgL4R-0000Kp-F0; Thu, 15 Jan 2026 10:59:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204817.1519379; Thu, 15 Jan 2026 10:59:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgL4R-0000Ki-C6; Thu, 15 Jan 2026 10:59:19 +0000 Received: by outflank-mailman (input) for mailman id 1204817; Thu, 15 Jan 2026 10:59: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 1vgL4Q-0000Kc-AQ for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 10:59:18 +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 3bc2fbd9-f201-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 11:59:16 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-47ee2715254so3513695e9.3 for ; Thu, 15 Jan 2026 02:59:16 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee11c64b6sm41955005e9.7.2026.01.15.02.59.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 02:59:14 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3bc2fbd9-f201-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768474755; x=1769079555; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=XPh9hjMlmCFPl4UvXb1fH+OTaYAZNhI8xMvO0cWzu38=; b=BIhANuTIHTAqRsVSutd2wLCJg0ECJoa+CB0IOGF5ALwNdCN6tHpD6fkBmO4Ancxi7k qsS62bp8XZauXAIAFijnvd3e9iF0wUC8gJB3w4wi+yUSrBCaeSpx5RMp5wpPD9UCy671 bVjeY8wvvWUCWIwxSA06KWd4KgkjCR04vOOMKSFUpUyAMG812wnA/UvfWMMeQLcXjRFR aaFY9CFwfV9r5RvOfoDzxC4eNOEKrEWdtkd5E93/JF8vEcI1jB3V7nOraNEcbllpvbEw q7xVEA4w6n94Ketdk9E8efTf0EEFyLx8W4FmDueFvdIp5E1/X6PA1C2f2AeeNb5Q9tMr 8S8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768474755; x=1769079555; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=XPh9hjMlmCFPl4UvXb1fH+OTaYAZNhI8xMvO0cWzu38=; b=PCDPaXaBwpz3FCiXoUoqEAQyIuB5zSKzGlXu0fOkmKjAposRIXkkUL1XWG+tfD4ZDC VDCO5HYQPJ3rNbOeWa0vy4UDH6/0OGgPNybqFt/UID1q04hg1Hs734G9vpdnNULj9j4Y KWml6jeqlCra1KPxRzTl4fM4TsiWy1Lionh88XbujjZ+03crhA2Fn28ubzaNgDp2lT3S hO1X4jRpeajeLsUZsOhW9eoob66s2Hln770rk909kHpUiZJX3RZCmpUivylZ44qRgoBX y0cYFQTzshvxeHAJVE6KwYoPIyOLTTmGP78i/s6Dei2uE6EN1c/q2xnUzi9vm58uX9M5 bDbw== X-Forwarded-Encrypted: i=1; AJvYcCWYpVvaTXiZDej/4+WHx/vgu4zcfnD8WV4AfSkgKcK7IEVheVFuulGJIlC7jsXgqF+w+ORiUgHvt4I=@lists.xenproject.org X-Gm-Message-State: AOJu0YwtE2iGsYxjH4RkECBX1Nb4KIGth88jF5vcXpGCBt0ZSmS8SYHj O8lxtQxKdLLZJfQRRR5K4/gNnaBwCpU8wxOqS5Yh2LPjPtvmGRUKWtWt7pNHrNm5gA== X-Gm-Gg: AY/fxX5u+V/qELvE1aDfBHGKq5nfq1gmJD2Mts4spNpeYKMFCx+Knjfw1nCqCEbUqTa BV19kLIXk+0jNPjDBYTwP79XdMccKM62Lcgzmi4LqCtoAwkgzj13dtPGpsj7XPLu3dvIlZOd+8x 80k42mnavm+JRj84eQ1Vz2Dn0oSatCeT9ExYsO2q/xBoUgtVwu3153qwFqrQvKPkIzPtszcQHYv /KOg1XAgo/BeNatzRZoC2eqftHn1KixvppbiiGbiciVG0QYr/Lht5e0HTXDQcI78TpuNvAnj7sV VUpSAG7vfzsNcphS4cIIRwGBUUrvmTJ6Yjq9yl/lglGr3FIowhs3q8/zbP+eHapkHte4gKlb4Nq XRArVKvWWKWGYk1VBBOOCXjfCiA5HOg40QUoPTdSrGKSaoDuHL2hVs4x4JvH1cDWrn1LcfMh8pN pNIREE05/BE7qWpeU21UR1GirB6bpP0yMS0NtDZR/vbGNkdiusAO6I7agy7xYd0GeRTbRY+m/zV rR7Oiw/rHackA== X-Received: by 2002:a05:600c:6489:b0:479:3a87:2093 with SMTP id 5b1f17b1804b1-47ee339fc98mr52178045e9.37.1768474755528; Thu, 15 Jan 2026 02:59:15 -0800 (PST) Message-ID: Date: Thu, 15 Jan 2026 11:59:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 07/15] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <7a90cc1b-b053-4b9f-91f1-d32064b1ec29@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 15.01.2026 11:55, Oleksii Kurochko wrote: > On 1/15/26 10:52 AM, Jan Beulich wrote: >> On 15.01.2026 10:14, Oleksii Kurochko wrote: >>> On 1/14/26 4:56 PM, Jan Beulich wrote: >>>> On 14.01.2026 16:39, Oleksii Kurochko wrote: >>>>> If a guest will do "That (the 1 -> 0 transitions) could be (guest) writes >>>>> to SVIP, for example." then the correspondent HVIP (and HIP as usually >>>>> they are aliasis of HVIP) bits will be updated. And that is why we need >>>>> vcpu_sync_interrupts() I've mentioned in one of replies and sync VSSIP: >>>>> +void vcpu_sync_interrupts(struct vcpu *v) >>>>> +{ >>>>> + unsigned long hvip; >>>>> + >>>>> + /* Read current HVIP and VSIE CSRs */ >>>>> + v->arch.vsie = csr_read(CSR_VSIE); >>>>> + >>>>> + /* Sync-up HVIP.VSSIP bit changes does by Guest */ >>>>> + hvip = csr_read(CSR_HVIP); >>>>> + if ( (v->arch.hvip ^ hvip) & BIT(IRQ_VS_SOFT, UL) ) >>>>> + { >>>>> + if ( hvip & BIT(IRQ_VS_SOFT, UL) ) >>>>> + { >>>>> + if ( !test_and_set_bit(IRQ_VS_SOFT, >>>>> + &v->arch.irqs_pending_mask) ) >>>>> + set_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); >>>>> + } >>>>> + else >>>>> + { >>>>> + if ( !test_and_set_bit(IRQ_VS_SOFT, >>>>> + &v->arch.irqs_pending_mask) ) >>>>> + clear_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); >>>>> + } >>>>> + } >>>> I fear I don't understand this at all. Why would the guest having set a >>>> pending bit not result in the IRQ to be marked pending? >>> Maybe it is wrong assumption but based on the spec: >>> Bits sip.SSIP and sie.SSIE are the interrupt-pending and interrupt-enable >>> bits for supervisor-level software interrupts. If implemented, SSIP is >>> writable in sip and may also be set to 1 by a platform-specific interrupt >>> controller. >>> and: >>> Interprocessor interrupts are sent to other harts by implementation-specific >>> means, which will ultimately cause the SSIP bit to be set in the recipient >>> hart’s sip register. >>> >>> Meaning that sending an IPI to self by writing 1 to sip.SSIP is >>> well-defined. The same should be true of vsip.SSIP while in VS mode. >> I can't read that out of the text above. To the contrary, "will ultimately cause >> the SSIP bit to be set" suggests to me that the bit is not to be set by writing >> the CSR. Things still may work like this for self-IPI, but that wouldn't follow >> from the quotation above. > > Why not that wouldn't follow from the quotation above? > > The first quotation tells that we can do self-IPI so VSSIP.SSIP will set to 1 > what we could miss SSIP bit if won't explicitly try to read h/w HVIP (or VSSIP, > or whatever other alias of the SSIP bit) and sync with what we have cached > in hypervisor. The bit being writable doesn't imply that it being written with 1 would also trigger an interruption. If that's indeed the behavior, it surely is being said elsewhere. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 11:19:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 11:19:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204854.1519395 (Exim 4.92) (envelope-from ) id 1vgLNk-0003et-D4; Thu, 15 Jan 2026 11:19:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204854.1519395; Thu, 15 Jan 2026 11:19: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 1vgLNk-0003eO-7k; Thu, 15 Jan 2026 11:19:16 +0000 Received: by outflank-mailman (input) for mailman id 1204854; Thu, 15 Jan 2026 11:19: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 1vgLNj-0003bC-5V for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 11:19:15 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 05e868fa-f204-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 12:19:14 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by LV3PR03MB7431.namprd03.prod.outlook.com (2603:10b6:408:194::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Thu, 15 Jan 2026 11:19:11 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Thu, 15 Jan 2026 11:19: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: 05e868fa-f204-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HOUt15YJB2aXEzpXq0D3dExLXpxTS0dWGWptTiLjTOzULkpBRXQYJ3nD5hdv4mg9vZtUDAEIszkcEwV3Ck8c3wcchArhow1Kv8LYAoE7zyM+mntVJswv1JRs9F6hvW9Nz9icnM1hvTRCztVb32MaAR+HzIhBvV9z62nzj3QEPBRgnEb/r+aBZVEtruPulHNWX4aIFXHLF/IAt3oSw6WPLoXsXhfMscFvWVZve+Ey2PVkh4pVeC04oKHqlsMnmJ/UyCgIoWzjdZ83hUF8b5AzyYhU5eOhZMqsw65FOXFbzc6LBdEBTNYCH2OrA6TSXg/sb4H4+mAgjLZqKW3mYFi1kw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DGFKVF0i2wWigbiwR7BNTdhzq53D/kNouGUmcPEvNic=; b=JdiHKVg/Q04yRKCBDGAg34F6fzWLdPryQoeNztm9IsEqstxHWHzxiKQAUJBzycHu59aOsxsB8Y55S+w3YoXZMKXz278f3RQDjRGp/DRg42kmGMn2tVng8cQ8YMn4DsF4J4cojPTKfvBVHlQilluLTSP7Elihwc9KZbWRlb7uFvdWDILmbfDFl35YoML/w+oRqduyTB7R3gJh3mmRKfUgOniDZHg6GHeoQrGG7Lbao1W1zdkLmw146kwfJ4kkxqvOYdfctMpQKY8I64wPcOn6IsL/PYg3y95ATCa9AR+8hoC+9CYCH9+wdWSgaT1sdNOjRF65oUnLG7r8fjfMmDuLPg== 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=DGFKVF0i2wWigbiwR7BNTdhzq53D/kNouGUmcPEvNic=; b=cMn0fGOpUhbnml+IyMxP++T1XQmhV8/pklD2FXIr7Wkzft78VDu2gHlFql0yckWmFEbkwJUHTgREl9zo92FXaB+NflWkauWwrdj/s54L+Pzs5IfNoWshrrGMwwH4U1cEWQyDMWnnJM3xubg5slrUwEU7/XbizFO5TX7o2BBYnOA= 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 , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v2 1/3] xen/mm: enforce SCRUB_DEBUG checks for MEMF_no_scrub allocations Date: Thu, 15 Jan 2026 12:18:02 +0100 Message-ID: <20260115111804.40199-2-roger.pau@citrix.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260115111804.40199-1-roger.pau@citrix.com> References: <20260115111804.40199-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MN2PR06CA0012.namprd06.prod.outlook.com (2603:10b6:208:23d::17) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|LV3PR03MB7431:EE_ X-MS-Office365-Filtering-Correlation-Id: 711dc458-f203-4445-de7b-08de5427e88c 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?Um5WeTI3MnNzbjMxRFJJR2RiWDlDVUNUeUt1aUN4YU0ycTRzTGswSnhmZUNv?= =?utf-8?B?UHc4blZVTUc4ZlI5U0hPRTVtOFlnUStXU3BmVXdqY2RlckN0WldybTVaSFBw?= =?utf-8?B?QnZJdkJGZW9OcVovaHJNemFDQlg0dUdXWWNlWXlvSTdqaDMxYU5UQXBLMGxQ?= =?utf-8?B?UWZtN3h6RkhjNkVrVllHaFF4cFdKa3A0WGtoWWV5VEMvdkdUVXF1TmpzWllB?= =?utf-8?B?V0RNL3JwUytXVmF1QktSVkRZRmRmSUlyMzJySWJRMzBrZWpRZzhPT1MxM3FO?= =?utf-8?B?THU5MUNjaEhYMVNSbW8xeGcxVmZ2YStiUWlUUVVpVjBhS29zVGFhdnJuMjhC?= =?utf-8?B?cVVqYXAvQVA2eGQ3R09jS29EUFlqTCs0TUtKS3dpMFZPb0NEcHVMSWFGZEty?= =?utf-8?B?Rlg3enpBNDhDT2QvQ0JlaE9yRnVzV2dlR25xU3JqbVVyMjBabGNMeGJ4YlQz?= =?utf-8?B?eWhidWF2ZlRmL3BoZnQyVVVtWXpVTjUraFRqWE5IVFJkSlJGeCt6K0xzazZ6?= =?utf-8?B?TFBmMlFxaVhxc214d24rcFRySVVsTXB5VFNISVV4SUpXM0tKdjNnZWthdk5G?= =?utf-8?B?NGFmMGNoVzZodFc5djJtL25reTZ4ZEYrRTlLdUNoMHR2elJnZDYxaDZBb1RO?= =?utf-8?B?RGJicEdyZTJGOGRtK0Q3bHllT1lyUXhmdGxJOFgrbU1xekRYaVFlK1F6LzI1?= =?utf-8?B?YzdvcGlsR3o3YnFnNFo2QnFuL0R0T2Z2WjN6Z09QbUltQTduUG1xeFRtZE14?= =?utf-8?B?RTFoOFN0TlpHNWt2RkFUZXV6SEdTSit4Q2ZwclZJSStZZUhvTHRQK01tcFhz?= =?utf-8?B?bHdKKzJnWTVyb0p3TVFJN09tSythYzZWYjRrcVVTL3MyK1oxUFc0U3hxbzJm?= =?utf-8?B?OVY2M1dSVDNSanpha3lMMllIenZSUlZrV2Z4OHhCTUhiaWIvWUtFRk9KbnNW?= =?utf-8?B?djJ6NXBuRzRsL2hWYkdxb1kyZk9TanFDMEpmUS90SVJza1BhUnZmSkl2L3JG?= =?utf-8?B?RjB5VnB1ekpxRWpEQi81S1h0c3FVbnVJejkyUDE5T202VFo3U2JIUGNzVlh4?= =?utf-8?B?ck54OGJicGZOcS85ckdLQjFOTERITVBnUHEySnVSRDZUVlliNW4yZ0RtYmI1?= =?utf-8?B?U3BrN0dCcThDaFhGTGdUZmFMWktiYkNHZG9wKzJPMng0ZzUvZUllSTlacjVG?= =?utf-8?B?WGpGZ1ZwRkdqTFpieFhOSEJVZEordnFnK1Vxb1FxTXdVYzVHTi9yVjB5eStL?= =?utf-8?B?NGQ0SkJveEJmRm9CclJidkxHUWRrRkRYUHRiQ1lOejRiazhCcjlSYVk1dFYx?= =?utf-8?B?N3I4SlhHd0hZZ284c1MyU2JxZ05yMTVJcEdaUTdyaytoOTlGNGJmWDllTWFr?= =?utf-8?B?L2ZHTDUvRzV1QjdOOVFVaDByb3p1VkM0Y1l3dGpIUG9kVnB2WnUzL01tU1Zu?= =?utf-8?B?SFQ1N0FwUFhQSUY3UjdrcUk1SmRtTU9TMHV3ckswOW4vN2o5SDMxd2pES1hT?= =?utf-8?B?RTlIcXN6LytTbUVNRWpjeXNtaGRBT2dIZHNDcUFFOU11QkJNMFc1VUQrOEdq?= =?utf-8?B?cXoxbit5aVRIVWRlNmxGSW1vL0c2aXpBL0tmMDE4QVlEeENGZjkwL0hDZTVV?= =?utf-8?B?Mk9RVUNOeGZwODNENjRnM01YdEZMd20wU3ZhRHQxN3gwcHNPYXJ6aTVVNUhu?= =?utf-8?B?WGdkR2xvdGhLYnRiTFAvSG5rczhQWDVUWnpSTXJ0dzBuaTIxTElzUHhvUVdo?= =?utf-8?B?ZWpqK2VWTlIxY1pFT01qd3RLcWRYSmwvUy95Q3dLRlowZG4xcFJMQUtOL1da?= =?utf-8?B?cTM4UXZoekRYZFBFNW5BdmlSOERLa240cXIrRUx3WDZSNjZ3cVFEMkZiQzNL?= =?utf-8?B?aGw4ZjhDQURQQ0xFN0tJVTB2VzdxOFQvOEdRZUhxcTdDdUVZYkp5T0cwZ2Nq?= =?utf-8?B?ZG9YZkQ3VlljR2tXUUcyT0g1TGt0VlFLZ2FEbkJ3c05lbFRmVXpUOGZWMTBF?= =?utf-8?B?T3RlUTJpUzU3alZoK0tmbCtKRkIrc0tDOFduYXNHNFJhKzY2eHBMTXlVamNU?= =?utf-8?B?NmYrZ28yNUdldHRlMXZRT1VZMjJOTUR4MDZtYlZsdXptelIzRjc1V3krU2NW?= =?utf-8?Q?5TlQ=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?U2laTHU2Ukd4RWhtTjZKUkNBMmVQbDkzZUEyQlM2RklHVExLOFdvK2d6NldI?= =?utf-8?B?VEt5ckZmelEwcjBoUUN4ckdwR21IbE9JQS9YaVhLNXcyZUNITHRzdGtFMkhD?= =?utf-8?B?ZHpUZUFoM2czK1c3VXo0WEFjNnNVYXBBUUljTGlERFpEZitxMUcvc2liVTJr?= =?utf-8?B?RkxOUVc0ZnU5TVBpQVRqUS9aa3k3akk2N0xmWXY5RTVLZHlDd2phRGNJSWdX?= =?utf-8?B?cHZXYzgrYlpvdHVqTmpHV3BvZzNGVUNLTU0yZXhNTFBTeFNIUytjemR0YWRI?= =?utf-8?B?Z2NTMG1LWmliZ2x4Vnpva2VqdmpjeG1ZcUhVYUU0Q3pXQ3JpLzdjb29uOW1z?= =?utf-8?B?d2YvRjRoOGhsaUo1SGdJMStVbnlXQkE3UjV6aUxnalBqTE92OVQwWUVGbDRj?= =?utf-8?B?UUxwVUtNNUhJMktyUi9OR2xieTBQOUtlaElvZEtUVytFK1J4dWtmS1Z1Mk1M?= =?utf-8?B?Y0FOamNUTUxEeDZhSFV5TDNFRC9lc0h2MkdLZmk1ZGdrTjE2blloclJRUU5h?= =?utf-8?B?QndHWHVZMk1ERS92UjNNbjFidkZSUTFDTGNESThlL2svYmwwd0hmUkZYV1d4?= =?utf-8?B?a1pNQkI0b2x2OFhqS3FON0tJSEcwc29LZUlWeVMxUzU5TldiUjlZL2VBTW1H?= =?utf-8?B?akg0NHBpcGxndHo4T0xEV0w2ODNHcllVSGM4ZFBQRzVqbmY2M1pXbEJXZlpB?= =?utf-8?B?bDM2TE5BQlJYV0hYOWlXcDRtWXkxdWpSQTJGVWdFOWtZUStnVEhVT2xVWnZs?= =?utf-8?B?M2lJUm9VTVVRZ2p6Q2NSZVhwSHhMVmxWM3BRL0lFUEYwTkVFcDZzcXEwME5t?= =?utf-8?B?aTcvbE84azFoWXVTOGhZZ1dTNVF4b3Yvb3U1NzBxbVNkK1pESW1zbGRFenRV?= =?utf-8?B?eVkyVEgxWExxZGRYVTVNRytReDZrODgyWUxDSzVXUjdGOVk3dTRNSk40d0dU?= =?utf-8?B?QjFQNzFKcERqWjcvUTBDN2ZkNms5MUpQbFdPV3AzQmN3SFIvM1Zvd2RFcDJ3?= =?utf-8?B?RmEzMUpTSmxub3dRV01OTnozZXMzMUMrYVVNdDFlN3Y4dncvTjZDUjR3SVQ2?= =?utf-8?B?b204bjc0ZitqbU9ESVFmb0JYWTdhOStXQ0RKTkZXK1UzVjQzNHJJOE81SDFi?= =?utf-8?B?d3RTb0pydFFOZmZpdWZVUlg1a3JHYXVuUGZYNkVMcmRnMTI1TmNTU1FBZ0s5?= =?utf-8?B?OStvMDJMTGhLSTdDUXdzckYxelVQQ3orY1Z6NEhlWENJZ1VVdHVUZExMZGxO?= =?utf-8?B?LytDaHVkblMyQjBlNWZ2elUveXFvd2E1TTgrOEdGQlkxTlAxWWpQT2hvUStB?= =?utf-8?B?V1YrOWEvdjd1THBVU3RFcVhjYVlTRGh6dnVSczdWTjNZMDlVOFRzeHg2ZExk?= =?utf-8?B?RnFYYjRlSVVvOFREYkdqTXF6V3EyaUd2eEtZK0NaUlZlbjlMUEcrZDNCN3l5?= =?utf-8?B?dGVSTGwrTFBhL2UyenlNbmV0MUgySy9PbDN3a0lscEhXYjhOQU1kblJRZ1Zt?= =?utf-8?B?L2tSOFdjRkY3RjAzM2VoQmtmRjRhL0plNWlHYm1lOTd1L1AxTHY5WlJkR1gy?= =?utf-8?B?d0hJeWxQR2trbWw0bTdlUGl6K2ExYWpPaDlRbFRLWUU2b2tqR2RDS0JURkdq?= =?utf-8?B?QkpUTkc1NU5LOFA1S053ZUp6d3pTeHEvQ3h3elpjdlBBYndCZWFWR3Nmb2Vv?= =?utf-8?B?dVd0eGZzZ1JwVVg0NmE1WWJ5MmxyNXA5VDQrbDZyVk8xdVkyMTFhcGFlODd1?= =?utf-8?B?cjNqSjZ5OEozeU9iQ2E2c2lYWDZ5cFB1c0Q1M3VVUlJKaTQxa0pKMXJMQjVT?= =?utf-8?B?b3V3VHIzYytxZllWT2pkLy8rbW1tTTVvU2NJNkJwb1EyeHBiWnBaQVpweUR4?= =?utf-8?B?REdYM3M4NTBmM0RPczdrWDRBQmlhdWJra1N0bVVNLytLc0xLU2JNQkZCeGE3?= =?utf-8?B?WE0vL0tsL2pTdXByRVA1S3F4VnI2ait1QjNTelJXdUVPYU10ZzNaYURTMEg5?= =?utf-8?B?UktvcnlMblNLVFNqbkVEa01Jd2lBa0cwQ2lLaGdZWFBqeDZuOVA2ODg4TUEz?= =?utf-8?B?M0R4NGZwdTZwZ2lVUXAyOFZ3ME44aWY1TWpHWStLZGhod1FONWszaTd6aGhp?= =?utf-8?B?MUZXSHl3dCtwa1hXR2x0R2srYTV4YkhGSHJjd3d2OHc2N2dkdEhaOVhsSEJh?= =?utf-8?B?VUdPV3c0U2M4WndETUV3MUlFZkhrS0pCQmNvTytOang5ajJCOXRwNlgzdDFo?= =?utf-8?B?d0N1OGpnVGdHa0JJRnVNZTNIMWZlQTk5OFV5cTBEL0h1L01FcURFRmxjbWhG?= =?utf-8?B?d1RLN1BJQW1hdXNmVnoxdDJJZDJBQ2tPK1l3Q2lNZEJPbFJqdURXZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 711dc458-f203-4445-de7b-08de5427e88c X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 11:19:11.6964 (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: QY2DH6neAatWyF0VweI5fMVs6nggu1MLMKibZOVtTP8SqYG7mlay09Doz0z14Ff+jwSoIVxj0FOP2I0Z7MwT2A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7431 The logic in alloc_heap_pages() only checks for scrubbing pattern correctness when the caller doesn't pass MEMF_no_scrub in memflags. However already scrubbed pages can be checked for correctness, regardless of the caller having requested MEMF_no_scrub. Relax the checking around the check_one_page() call, to allow for calls with MEMF_no_scrub to also check the correctness of pages marked as already scrubbed when allocated. This widens the checking of scrubbing correctness, so it would also check the scrubbing correctness of MEMF_no_scrub allocations. Signed-off-by: Roger Pau Monné --- After discussing with Jan I've deliberately omitted the tag: Fixes: 0c5f2f9cefac ("mm: Make sure pages are scrubbed") The intended approach might have been to ensure the caller of alloc_heap_pages() gets properly scrubbed pages, rather than asserting the internal state of free pages is as expected. --- xen/common/page_alloc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 2efc11ce095f..de1480316f05 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -1105,8 +1105,7 @@ static struct page_info *alloc_heap_pages( spin_unlock(&heap_lock); - if ( first_dirty != INVALID_DIRTY_IDX || - (scrub_debug && !(memflags & MEMF_no_scrub)) ) + if ( first_dirty != INVALID_DIRTY_IDX || scrub_debug ) { bool cold = d && d != current->domain; @@ -1119,7 +1118,7 @@ static struct page_info *alloc_heap_pages( dirty_cnt++; } - else if ( !(memflags & MEMF_no_scrub) ) + else check_one_page(&pg[i]); } -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 15 11:19:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 11:19:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204853.1519389 (Exim 4.92) (envelope-from ) id 1vgLNk-0003bU-3J; Thu, 15 Jan 2026 11:19:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204853.1519389; Thu, 15 Jan 2026 11:19: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 1vgLNk-0003bN-0Z; Thu, 15 Jan 2026 11:19:16 +0000 Received: by outflank-mailman (input) for mailman id 1204853; Thu, 15 Jan 2026 11:19: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 1vgLNi-0003bC-Gv for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 11:19:14 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 05013c79-f204-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 12:19:13 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by LV3PR03MB7431.namprd03.prod.outlook.com (2603:10b6:408:194::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Thu, 15 Jan 2026 11:19:10 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Thu, 15 Jan 2026 11:19: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: 05013c79-f204-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=yVc4aqOFZhHr5uOYPjB2PKpn4p2NFivFsXZy4h2BdorNh/EoH3UPbr9tvHcDI/jY1HGeF6jDaYap1oI1YcFuXi8ZtbxpaQLsvE9WXs8MJ5ktxBqahTugl6RdQDzHt9AIIw8M2ewi3744E2+iKD0qrUAfWqo+4XU+5JLD44VLNjPLiavYdOBi/36uPDCPE7vJnn4dV8f6eJVQJbS/vBz9wVsoIYpqsZ6bK3m9EDnQH8OZFuK4StGwC0WD9+Bb8ElN2obSynw5K7v6uGKQ7gD59NDrkrluR0Qks3cnmPiINMbp4YLh7+SdWjXBY03Nb3trB6zcj1mDvBCq/Qw9h8uxlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=B9Cibf6lORNw9LbneDyZBJ7456XS35mADhwrOLDAMMw=; b=AqavF1uVKJXO0iCONMio9gCd5W7AheTQ/fAC7ntRzDLWEBClwxe60eJbS7oO5i93VZBnbnXFDwajj4vWbjicAdMCxXLSppg7ADM5qmZudcBwyVaEYd7WIk/z2hnprPJzPAS58vE0iTor/Fe5rBhM+IboNStkaeyXo7M8hNYu0+I8Rr9CgSvDAYmZ6VCnq2KL5P1GEjWhQOobibGGLPjYghcCxkguwKrLm6L4oeelRcTJqudH+eZpDcNGrSSFAJSZPqgNSeo88QA33m3VFsU9b90H08FkCcXikoU0mMtItUn4uPxSn1vTQxC/7ZDaJ4meA+pbtKEF+mZt/Louly3vXQ== 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=B9Cibf6lORNw9LbneDyZBJ7456XS35mADhwrOLDAMMw=; b=s0XpGH38Mi5Nytksx4/DmiWp0w6dRtWET7tvVq/b5ZrdzTWfkSryRnyaqxbm4y7iSER31dzqQtT+jpMB5rWDZgfZRgDuxbX8CxIUAwaIHRXNJ75N2uRFeubrL/MZ0jvFqY2M1idEZ7o5lHWTIXKaw8VyrR2cxNzR7rApZhu9gYA= 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 , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v2 0/3] xen/mm: limit in-place scrubbing Date: Thu, 15 Jan 2026 12:18:01 +0100 Message-ID: <20260115111804.40199-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: BL1PR13CA0275.namprd13.prod.outlook.com (2603:10b6:208:2bc::10) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|LV3PR03MB7431:EE_ X-MS-Office365-Filtering-Correlation-Id: 0f6704ae-ce37-4d0a-8058-08de5427e6e2 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?dEdCQVh5Y2xRSHpGSlR2ZDZybHYrOUVGTUcyWmtBK2NZSnlHQUM4OTlzbHhR?= =?utf-8?B?ZWFnbGNGb0xvZWROeC9ISWhlRzU0Y3FWS0lpcG5saFIrWXNRZkROZXRUZi8r?= =?utf-8?B?MDdtcEY0ZFF5SzNJNHA5Zk5wVW9vbGlnampTd1g3RHpGa2d0QXphRXVlbGdS?= =?utf-8?B?OFV0VGVOa1MvcVJqd3piOGZ6YlNpU1drekE0S1BCZEpIRTdIYzJDM3dhYjVW?= =?utf-8?B?RnhGL0ZjQmpXSWxMTFhCcjQ4ZFk3STFnL2ZlNktnYUFBN2dweG1ETnB0WU5r?= =?utf-8?B?bVNrUXlveXhxb2VHQUU5a0RSV1RlVkNwYnhYWm1qRmI2cldxbUphZHMxZEtt?= =?utf-8?B?REtLaFYxaUVHeG9mY3pYdGltTXlmWDkyNWl1cmEwdCt3Z1p6WFgyYWNRTEY0?= =?utf-8?B?a0p2RU1ZVXFJblR0QTl1ei93Sld4QS9XUE01RHBhclFkZkE1aUV1WVM2Kzdo?= =?utf-8?B?ODNndjJTaVlSN1FMWXlzT2QxMDRrZTRWUW5qVE5ERU4wczhJQ2oxQTc0OFJp?= =?utf-8?B?VktIanhiUmIva1FRcVdnSU4wOUNSU0VsaGNKV0FUc3VIbFJUaWw3cDlQNXNN?= =?utf-8?B?alV0ekNUZHNZN1hTU0NIRm91VWtxVGFsQllSN1AvYjBrYXJma0RMMUhsZVM3?= =?utf-8?B?WlhjRWhwMUlKRjRDcnRldWJUaXROQW9jeFlBS0dsdXhIL0RrSGF4QkVWVllm?= =?utf-8?B?ZEZEdkZ0ZmNGdnhmVUtRQzVRV2VXQVNYcUNUMkRvdVQ4M3cyaVdYRktrdEph?= =?utf-8?B?TUt3emtjbjB6RXNaV0hBWjlmT2QxVVlFLzE0cVFyMEFFb01GQ0xXNDdsUGlr?= =?utf-8?B?Zi9qNiswSUVRYzJicHlaSFJHckhzcGMra2FtdkZPak5LWTltUlRnam1MbFBm?= =?utf-8?B?NHJvZFpEVXRVdUZDalc2ZEVhQ2tURmd2Mk9YOFBzSVhLY3Q0U2s2dlZ6TzFz?= =?utf-8?B?SVh2T0Z4Zmh0TU9xeDRwVEdFMlB0V0RnL2lpTnVWL0t1UUVnUDJEc3B1Vk9R?= =?utf-8?B?TTEwUzNsZU9rSUk2czdxdFhyaDdUcGF2bWdaQjd1Zy9kZzJhVE9MbStCRXVS?= =?utf-8?B?TzFCcHdPT0JEdU5UWTJxKzVRbnV2bVQ4S0hqc1BDeGxZM2trRHBPcHFyZ0hT?= =?utf-8?B?T3lZcDBKanpQRHZlWnA5THhpRG5wc3pZN3h3U2FEODExQk5nUTQzaVdtWFEv?= =?utf-8?B?STRxUkNlYkNETklEUk9qLzE2U3RwVnVNZXZQaU1MWnpYbzk5OGxzamFydDFH?= =?utf-8?B?djJGajR4UnRxWlFBK1F3MlRBUkVKV20ybTJxeUVCMTV4azFKWUFJZk5EVmlC?= =?utf-8?B?OEZhbUF1a2RnUFpORHdWYU5yVXpJVTJaRFpsWkdNWkhRSzVCbVl0OW9PL255?= =?utf-8?B?c2lPck1sU2dGUENqT0o4L2FUN082OG1mdlpzclpuSHZ4KzNQaGNTbm42MXVv?= =?utf-8?B?elZ4Q2FnMVBXVzR5YzdOQjQyb2cyeXV2MzBwVDV4ZmFNYmdkSVRHSGN4UjMz?= =?utf-8?B?dGY2TGd5bnNVTXR6QzEzMFloN0NwcnZUQUZZQWNEZEtrSk5BdGJsbW9xQzVS?= =?utf-8?B?cFpFVTF4bHFJK3R3S0dqWlBRdEVvQ21RRE40RWEyNnl3STQ4QTdlaUtCdG9Y?= =?utf-8?B?T3JVVHZzSHhxNW1FeE5PZmxMMXhjcERiL25qeVBleVZXZnVBYVlNOW1XbXVX?= =?utf-8?B?YVV5VHl6VkFSaUZtQ1NsalZPRDI5YW8rYUI1VWhXaFFBUDZPZW5mVHp6aEls?= =?utf-8?B?amRrZUsya3NMYi9hUDd4QTB3WnJIUTFveTI4bXdKRWl1Vmd0M1VwdTA1WW1p?= =?utf-8?B?SHNyUDZ4WFNEdEZsS1FzSUduOUM2YUh5TlU3NzBQdlNiWENyN2FrVEFBVzRh?= =?utf-8?B?UjMxMGdvdGFlVkJaUTZRN1U2YmsreFNJd0tvTmVOVlUvUit4Mmo2S1dlT1RY?= =?utf-8?B?MmwzQ0wvOGlHVWNpZWRNTUIzVEdWTEhRYmZQc25VNlJuNUtpNmg3N1VjSjNi?= =?utf-8?B?VDF3bFBGQ2xGR3VyaXRPd3ZZZi9Za01kd1E4ZUJJS0YvQW8rMmQrR1R1Nk5W?= =?utf-8?B?Nmw2S3hwMkpzZXVOaUdsYjB6bU5aTU51WTdtL0h3anNWR3dVOEIzS0dGZjZa?= =?utf-8?Q?RHgo=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SWRvN1NYRmJKR2dhKzJ6S0I5TlIxNWV2em5lTEZ2cjFwTTEvT3VPcTFrSGlO?= =?utf-8?B?Y1RYN3VBYW9VYTEvMCtCV2FrQjhES3FaNmtDenl0eHpXWVNGa2NhYmx3K2tF?= =?utf-8?B?dVhEdkVNSloveXVEWGxPV1JZaFdCSDZRWE13eTRaZlVvSHdOQlFqU2NzRlI5?= =?utf-8?B?eTRYYVB3eW1UZGJLNnQvbk5VNmFnYmxVanY0VFRYQjlHQm82eHdYYUhLQkVY?= =?utf-8?B?dk5KZU81enBlNVIxc3pvVElSVnZjWVAyOSs1TVpQNG1mZGdDZ2RJUXFSRDRY?= =?utf-8?B?dHkrUkhFZVUvTXFuRkhQUnZVNGtJajVneHdiWWw3TCswamVvTm1CMElEY2ZI?= =?utf-8?B?YVRqUktXS2dMNlBnR2tXSyttcEVpeFJseHYxK3UvSm5abFByMnNhZ3hTNzdK?= =?utf-8?B?ZWdMVit5M3ZFOHcxdStQdkViZ0ppQ0t5bzIzTWlUY2U3OUpwV1pmWk1uL1k4?= =?utf-8?B?Wm9tTUpOcCtrZGRXMTNWa2JnS2REdEdsSzBwNlkxVTJnYnFIWEF5WjVzQngv?= =?utf-8?B?TUNtU1gzVXFzaElBSDdpMzh2V1EzOC9IVEFJcXBZSXNobVBvNi91RUEwOTIy?= =?utf-8?B?clRjQnp6Zm1nL29HdXdGZ2QzV3R6Y3hQMS8vWnZZVDBXNk9WL1JGNHQxWEww?= =?utf-8?B?VDBsaW9mckhBUWV2MXRnM29hb3V3c0hsUE1QcGNvUm81c2c5bjdLcUx4cmh0?= =?utf-8?B?d2VBMytPMVltZU9saWlEREQ1bUFQdlZFTDFlUXJpQS96dGtNc1kvMFVvRlRD?= =?utf-8?B?MS9sc2xuMHBNcm90V0t6ZnB2cGhyVWgzQ0dxa3FsalArNlNrWnVMcVB2N2xC?= =?utf-8?B?RWVEak13c2xyUFV5TnhqSVNoOUk3eDNWMGtSQ3NRUk9QUWlCeHRRak9VaEZy?= =?utf-8?B?bTZzV0hZVHhKTm93cy91cXRmMDdWYXN2T3dHaFFJZTUyZTN3QkFIQ29BSFZu?= =?utf-8?B?OGRVZy91RDZod3FlVVpLM0ZYV2tjaWZ4bjZFdWpiVmZ2QldzMzlJWnpEMUc1?= =?utf-8?B?WnYxYloySENsbW9qSjZoVnJxVVhCQU9GMzhMZnJkRmF2NXFiUnFnWU5jejhr?= =?utf-8?B?WnU1K1VMVkszWlJvTW80MVdWM0xwRDNQaXJDcTBZTlpacHBiNThRODZiUFZY?= =?utf-8?B?Vk14M2ZoMk5RSFdITXJjRlBNd2V4UjBEKzFrU1p0RC9PU3ZqVXk3SDBsRmp3?= =?utf-8?B?UWZGc1RaTnV0TGhhSHl2dlRhbWNWcGdXYktPc09Ob2Q3cDJjZ3c2NlZMYzVj?= =?utf-8?B?VHNuUnUreC8ydjUzTktuRTZoNElKbXZiVzVzY0hFQkNITk5qbk53TU9LaS9m?= =?utf-8?B?cDFyTGxNd1JtbzMvalVVaVB5am9lOUhDekxLSjRJekowN0pyT3JzeFoxSnNX?= =?utf-8?B?b1N1ZWdqZUxCRGVvbitNZ0lTbVJCQTV3YmF4TG85NG9BTHgvUy9TQWJYSEEz?= =?utf-8?B?ZVZJbnFpKzl2cmJ0Y000ZUFEWnhsVldZRitRb01JeDFHWW1rLzFpZUt3NG40?= =?utf-8?B?cHZnV2JBRG9xeVBuU1JBNTFIWllKREpOTXRJcS9hRk1XQ2pUWGpQb0xrWDRh?= =?utf-8?B?dy9DUHkrWkdicXpYUnlqa1ZkWGN5bFFyc3FWMFhJdm1KbGpLbTFHcnNYN2gr?= =?utf-8?B?cXdjRmxGL2w0QXpCYTJTUTFQeDNKajdBOVVBazVmb2tHRGJUM2tZMDRqUTB2?= =?utf-8?B?aHJlVU12bkVxQ3RxaUFGQnIzeW4rVmxwczg2SmFzMGVyTTR4UldVUUFqQlpo?= =?utf-8?B?WENKdkNORmFDa3g1eDNnUmZacFl6Tk4vZFArd3pHSGx4M0h4L3NQbHBQMWRM?= =?utf-8?B?STFpK3Y5WERkb01uOUVMeWszZlFuRTV2ZXY2WTFGaE1pa3dNcmJ0VnBQdUFF?= =?utf-8?B?a216U3Q5YzlHaWdBZ1ZQN216SnZqaS82aTNUYmd6elRXU0wycnM1QU1IWUFQ?= =?utf-8?B?cEUwckdvRktEcGxaMENRcmhodGthYnBZNWJtRUpRUyswak9zNjNNamtYS2Zo?= =?utf-8?B?dDViOC9zVzlDS1Z2VXI3Rmdoc3prNk1yejZkaUtmWkkxbFppQ2xnTGg4ZXc2?= =?utf-8?B?RkljS3F6eTVmTWlTTlBRQ2kxT3lTTDhQV3pkRWlTUkNwSUdCc2prWlpQUS90?= =?utf-8?B?ei9KUnpPdE40MTYrOE9QRnlxaFpWSERRUE16K2QxbXRlamxtbm8vNGRPY3gr?= =?utf-8?B?dVFxa3lVZmlBSTJ4Sjg1a255b3lUdnZrR0Qwb3NQNFRNSlk4eXdjUWVDSVI2?= =?utf-8?B?akxId0NvNVduVkhsWFdNaXF3ZU1uV2dJTXF1S1hDVldOcy9IbURyaldwWktt?= =?utf-8?B?d1RLWXFMcDBEclcvQkZaMDhkbWRyVXJ4ZVpyMnpNZ0lSazRTelhKQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0f6704ae-ce37-4d0a-8058-08de5427e6e2 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 11:19:08.9028 (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: 9MVo+18YS+lan9GGjgJjY6G20Fcs2jaZtyae8rRoSjripVXCa9fxNqzs2zM39qf1tI874WzmcJ7nkkQEvt8vVQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7431 Hello, In XenServer we have seen the watchdog occasionally triggering during domain creation if 1GB pages are scrubbed in-place during physmap population. The following series attempt to mitigate this by adding preemption to page scrubbing in populate_physmap(). Also a new limit and command line option to signal the maximum allocation order when doing in-place scrubbing. This is set by default to CONFIG_DOMU_MAX_ORDER. Thanks, Roger. Roger Pau Monne (3): xen/mm: enforce SCRUB_DEBUG checks for MEMF_no_scrub allocations xen/mm: allow deferred scrub of physmap populate allocated pages xen/mm: limit non-scrubbed allocations to a specific order docs/misc/xen-command-line.pandoc | 9 +++ xen/common/domain.c | 17 +++++ xen/common/memory.c | 105 +++++++++++++++++++++++++++++- xen/common/page_alloc.c | 30 +++++++-- xen/include/xen/mm.h | 1 + xen/include/xen/sched.h | 5 ++ 6 files changed, 161 insertions(+), 6 deletions(-) -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 15 11:19:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 11:19:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204858.1519409 (Exim 4.92) (envelope-from ) id 1vgLNz-0004DI-JD; Thu, 15 Jan 2026 11:19:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204858.1519409; Thu, 15 Jan 2026 11:19:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgLNz-0004D9-FG; Thu, 15 Jan 2026 11:19:31 +0000 Received: by outflank-mailman (input) for mailman id 1204858; Thu, 15 Jan 2026 11:19: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 1vgLNy-0003bC-4l for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 11:19:30 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0e6a5028-f204-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 12:19:29 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by LV3PR03MB7431.namprd03.prod.outlook.com (2603:10b6:408:194::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Thu, 15 Jan 2026 11:19:14 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Thu, 15 Jan 2026 11:19: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: 0e6a5028-f204-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XsDoWne7cHuZsKJqc/j0QsxbXsuykPAwP9pI4tQer56FSk8/ldC6SRonV63PzHt4KEGZWLKy44GBsgmbq+be/A+Ge0djmbE6r17x8eQ/4GnY64tfO//cYbRHqkgv2u1DWCkVrnZeZrvemdCL3Wxsay2bdeEGKdy+ucA7jBefPvSzw/61xdifuMkh6TA/J0CvXdEsH7qpBjaKAQb2081Xn7LwZ6sEXCXbJxEKmHg17PyJxV3SFZlK4D0qibYbscv6VtSrIfMwu/ShohxEhncKBt9j4mqX5mwhYu4omGzIL2lq0qADRD4O8bkfGq5quFVRupKEjUAOY00k+jCf0bVytA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=q8bzH/L1hTXEPNB93H2sFsVys9laAXqSrcgU3fr2F+Y=; b=UkZY9fWiYYoTEk/2npoVwn+rex5Uak+0qJW25hi361rbTSuRcT3gI3oF5HahF4hoNO0/eCMWhjlxOF/H+frzaGNdpbmRPknFZfArgwq7yhxQFHWDATIKnF3i/w5JpKbdbfRF5Ny9NaCaCjKs+xmpxyLbnP/yJ2a5v3Yu8J26vgRIkQSu0YWzlzYS0tTKnLq7TFPjnlxyKmMVbnQH6eAoLbIKmqFYZW4guEGd2ZA3Q6pV7Mg+M4El439NqXwEcHuQGWjjt5X4F0pUkKg4m3BqrvMX+/3TgbioG3bsTcX/jUZagmR5+PJEttCFUQFysp+I4eCURd1G52PDsnN7oymKdg== 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=q8bzH/L1hTXEPNB93H2sFsVys9laAXqSrcgU3fr2F+Y=; b=WO0pLLVyNWx57TYuN0Xyi/sHxj50w87SbEN2zrs9PpspAP6+GdPuC97+6d3zFXDau9d/kXkmsf6PZUgvGRd0GidLNHwd9cAChOgRASnsF0Ub+w32OL70hVfYbifeVWkzwrKvvNkpNCO78Brcn7N9D6z6F22iaijMiiu1W7SjnFQ= 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 , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v2 2/3] xen/mm: allow deferred scrub of physmap populate allocated pages Date: Thu, 15 Jan 2026 12:18:03 +0100 Message-ID: <20260115111804.40199-3-roger.pau@citrix.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260115111804.40199-1-roger.pau@citrix.com> References: <20260115111804.40199-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MN0P221CA0008.NAMP221.PROD.OUTLOOK.COM (2603:10b6:208:52a::30) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|LV3PR03MB7431:EE_ X-MS-Office365-Filtering-Correlation-Id: 7568f4fb-280b-4145-1564-08de5427ea52 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?eFFXZWFwVmpqVkR1RXZRY0lVV0F6Y2M2SkIzUFp4UEdXelZ3RkxhOVpjVnVT?= =?utf-8?B?RHowNVhFbUZsODR1ODRMNzMrY1YwMm5sd3IvQTBLMlovbm9wcCtJWEYxSHU5?= =?utf-8?B?THAyWGphUjRsQ2RaQkVSaUhGbDlza0JKcDRibzdIVTdCdzF3SENXdDJJTFNS?= =?utf-8?B?NjF5UDRaQStuL1M5bWtqMThvNXZic1dZbDdUd2haZUN6eXZpM0NwTEF5OXNI?= =?utf-8?B?T2dnd2t0ZC9jMHVhNGkrMnhNU0VBYTVWYjRTYktqUktFVTFvRS9JcEE2djBn?= =?utf-8?B?MHlZeDNRbFJKY3NzcXdFbTcwL2U1K3ZZdnU3Y2xlVXltd0tRV3FETGlFdkRS?= =?utf-8?B?bysyRVovazh5TTVsenErUW80T0VaalovYklUL2hrM0NmQklkQlBucElmSElB?= =?utf-8?B?RUJucHFMTHpEblhlNzJJMjNLdXlDV2ZWbWJrNTFrQ3RtMXROK0RYNURYN3Rm?= =?utf-8?B?bVcrRUV2WkNkRXN0N1AxV0ZFeGliRUFWbUQ4U3dvSEZRN2pRb1RPTFFaUU1o?= =?utf-8?B?akhqWUFGcmlSZXV5QjRLZ1QwekZwanB4Tnc5RUlkUFlKR1JGNmMvTEF1MC8y?= =?utf-8?B?cGh4dzZKOGJmTGR4WjR6Ti9SV0xnRTUzUWs0TVIyODkzQ0oyRWhLZElyMG84?= =?utf-8?B?S3VyUG9Da1hTQ3JtYkFYbGJ5RXAxdDVOdEJoWGJmQnVjVXRLWmVtWXBmVWFk?= =?utf-8?B?TU5NdzhzTVAxY2hCS1JQcWJKNVFwZmVZVFczK3ZGNGxmb1dRdnBJNTJjZlNu?= =?utf-8?B?TGNGakV1T3ZvenRlV0x5TUdBSHBNZ0Q5a0VMN3BDY00zS3ZvejRXaHFrcmwz?= =?utf-8?B?NVNWRGN6SDI1MUFTWEFmUUZPc1pRa3h6a2hySTlPcm5kemR6QWtuZkJOQ1l4?= =?utf-8?B?cVg3eVRXb0tBNFVrUkpVc1Rma2I3QUtQNHlqY2UvMEVoYmJ4L1ZwTWMvOGRt?= =?utf-8?B?dnpxS1RIVDR0alRHejhzQUhReXBkUnBLR1lSRnM2VE5QMHd4U3FYbTE4VkxY?= =?utf-8?B?WTZvRm53T2U0OTZCeEx6QjBHZ2NBZXVsYm94VmMzb242UUFkczc0ZU5NcTNM?= =?utf-8?B?RDFRSS9FU2F4bXpnUlJ2bWV1aFpEUXk1QnR5SmpscHZieTR1c0twQVdQdUQw?= =?utf-8?B?c1FhSUJ5YjZobEdmSzk5eGZ0Y1dQT1JScTErLzAvVFo0UFdla0pNcUtEZDVN?= =?utf-8?B?Vmhsb25xWjRXRytVM2FRRHIxNWhjM3ozYUNUN25qMndwdWRReTQwdHJLaExq?= =?utf-8?B?OEZsNjlkY3RkYjFnZXhQYjdVNmVoQTRXazdraHdvNXlqZDVLOXNVMmRYdUY4?= =?utf-8?B?Ukd2NVBndXhCUy81Y0dVb1ZoM3MzamJ3M0VEWVZSVVhGd3RjRVNVMWNGODN1?= =?utf-8?B?T3kxMVpwWjZScmFha0hXYitzcVN4a0Q1eXM4cDlnZkd4V3JINmtjMmIrMFhG?= =?utf-8?B?cFNvQllERG5uSFhoRDBXbmlhSE9XS0crcTl2Y2RDNDB5UDhiMVBlWVlaL1lG?= =?utf-8?B?Ukg3ejVpWnBQSGN5WHcvTGNWQkpZVHdWd2tqeWkyd2pmTkFYZWhEdWdUWGpn?= =?utf-8?B?dmNuY3A0c3l5RE9DK3dCRXM2N0FobHV1RFlBNGpnUmF6ODYzRDVwWUJqb2Fp?= =?utf-8?B?MFVIaXJ1YWV5TVlwZ3ppakEzNzBlc0trTHRsKzlPTlRsekRYclk0RW10VnRM?= =?utf-8?B?M0I2aDlBSFBoN2hDajZCYVpVMVNQNXBCd3VOdnArWlNteFFIb2o1UTlIMys1?= =?utf-8?B?NU8ybmtaaXpzWUh1SGRuUzlBYm9oMGRQVHdYS2FhTTRUOXBBRWtkckcwU3Zs?= =?utf-8?B?ZnBPczlTelpLYktGRDVvUVpReEpkTCtwZkdwVGlJQVg5MS9ML0E0dkhhNG9u?= =?utf-8?B?bWF2TXZIeHFmR1ZlVTRQRHcvTTNOYmEwRmJEM3ZMWUhPVEtKUUFkQTg3VDMw?= =?utf-8?B?UmtRRjJXaVJnNDNMRlFUT0YxcWR2SzlWdnpzYU94aG80d3lEbnFiUVZ4Ymor?= =?utf-8?B?RFp3NGtGK2xNUWxvbC9XanBOdHZWVXBjRWQ4UC84Uk9zN3Vzbzl4YkdVc2VV?= =?utf-8?B?NndSemVCcUx4ZE90Y0tNcm1YcDQvUGhxMko3bjdGOWxhMmtMRU5Udi8yakZu?= =?utf-8?Q?aZxs=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VVFaa055MnlqTmg1WWxnL29GOWJSYWNKZlVCbDQwdVBuK3hxbVNRTG5tQU9F?= =?utf-8?B?b0JyUzNBUm9mR01TaVdOMkFzWERvNHNXZjBzTEtVeUtFL3YyOHI3WEdGMXhD?= =?utf-8?B?NEg0QlhCT2d2Y2V1N1I1VDJxQTNOQ09Fd0FEN0toOTdFalJXNWFWcVdibEV3?= =?utf-8?B?Y2VGb0hPQVhLM2VmU01HZmwyVUh2dGZiZEIrMGQ0czRrcDRyc3dMMStWV1p6?= =?utf-8?B?TkpBOXp2RTVnOUR4R2M3aEJxK0JFUkllb09hVzVtZlBGTm1SbzNVKzFOcWpF?= =?utf-8?B?Z2Jrb2tyUTI0Q0poM2dlQmxRYkp6dng3enFvNzZvY1dkTnlhdTVNVThIVzBR?= =?utf-8?B?TjNKODQvRUJaSG4rSEg1dDNPSS84VVd6M2szbCt5T2V5TW1KNDZUNHZNU09v?= =?utf-8?B?YWs4Z3hvWktPN1hQK2xXcCsyUTYrRG5TOTlDZkVlU2xQQzQ5QUd2VjFnOFY0?= =?utf-8?B?TkRYb0hKYUVIbUVWSWl3eVFvaGNaZkFtREFwT0lDaTZIbk9VNk51NkpiVDE1?= =?utf-8?B?RXFuU2N5Nk91OXFjTEJnTklKS3lLUmVmVE1PQW9iMGhGVlU2TFhpOVN1cjI4?= =?utf-8?B?YWxDUS9JWVh6UU1nRUlZTGZvcWZ0VFJ2YmxybUV1UFpEcU9sQUswRitGeEtN?= =?utf-8?B?czkxOEJDMncwWDhQaDdGK3JYV3VERWdKeVQzMmdnckJJRjZ3eForQ1pGeEls?= =?utf-8?B?TXVUWDlvYXRxNVZzWmhiajBrQ29pNWVrQlVkbEhpb1Q5QlpTLzZMeDV3UkFy?= =?utf-8?B?dmZwaXFzdWo0UUVtdkk4dHRLQXljVEZQNno2SHpHV3FleXpuVG1qaVJLUnAx?= =?utf-8?B?ck4va0tGZFp6NTI2b09YaVozcnBlMWM4b3pJVzdIbUdGUFJjY2xOK2Y4OFAx?= =?utf-8?B?UVAyVVlWUGE0NUtyRmVrQjRsQm1OMkFyUDZLN0xmWnpjNVBIYmVkTmZrS0VY?= =?utf-8?B?ZGJHV2FETnlvYW82TVhEdGhlZVNmWHlSM01EWjh1ZFJLLzFROVo1dkNOblkv?= =?utf-8?B?dnNvWFNaaXlNeTRjRERxemdOTFRiVENvbVJBMm4rbGg5ZWdPWEJwQ0MzMjc0?= =?utf-8?B?YStBRFJsNzdyT1ZkL2tNMkJELzZjbno1bEN3RXBpdzVramdXY1RKd0hGcnNy?= =?utf-8?B?SnlLeW50akg3SVRZOHNyUXRPS1Y2ZjNtTHFnOUN3bXA1d0pZZnQrLzdMZVpo?= =?utf-8?B?b2FqVXNLYWs0ekQzYm83V1dmS3IxUW1XMnhxQUg2MkVJRlNFcjMxazA0cFow?= =?utf-8?B?MVVoK0JUTXdwSmIyaUdUUk81ZVc5UlVzU0xTdnNMMXpuNWo5Qk1ObXczT09Q?= =?utf-8?B?SXIvN3lzWnRSQUJBRmNMTnlOOGVBcmFXdU10TXJlSXN1VTlJN1FPaHI1TkpE?= =?utf-8?B?ak5kSDd1ZUYwajZOOThzNkpzRWxYaHdiK3lDNDlVVHk3clQvWkRYWjY2cjd3?= =?utf-8?B?YWtSRVhJbkllSWZ3T0xpUlhUN2xOVTBaN0h2VnB5a2djS0dseVgyNkgrQVoy?= =?utf-8?B?OHpXMk1zbVRRclh0ZHZsLzFFLytoMDJ6dzhmN2RxRXhORjFsN3BTK25ETExu?= =?utf-8?B?R2s3VFRVRUx6a3BUTUVicVI1STIvTWZTbzg1MjdPR1RnUlZXWkdreDhRZ3NM?= =?utf-8?B?eEhNdDdRRURKYlFVN1ZWbjRuM21PTlpTMGt5Zy82c0w4eGYzQ201UlpGYjBy?= =?utf-8?B?cGkyNWxURWhucmtHa0xZd0h6VU91UnM1a3U0NjVRa0JaemVVUnNmUlhNSjBj?= =?utf-8?B?aEF3WkhQUmp3VVlrcHFqSGQ3bk9Eekpzektrd0o5ZWRnYldmQS9uZTBqSzNa?= =?utf-8?B?Z3R0Nm1BQ0d4UjROWEt5TVFXMmdQaEIvUEw3UFVUNHVuRDJTTEhuYWhIVWRq?= =?utf-8?B?bGFaQWlWcXYyWDdVVWNqZklBN05YQUdJUERmekZGdjk0U1JlSjBidWVsN0Vy?= =?utf-8?B?a281WmppenNjUTBiNE93Y3RjbDRFaTNIbFI4R1h4blNScThkeHkwYXhXYTR2?= =?utf-8?B?Y0lxTkk4dC9SZEt4dG5rTFRWRE1zRi9ES1NNa0RuYitrNlZVWnBxakU2SDNy?= =?utf-8?B?NzUvU3JobTBLSEJ3YjdHeERuSzR1T0ZKWGNtVXdEaWxNUFZPa0lhWEd4TFVm?= =?utf-8?B?MlFxMzZjSU4xUUNZT0dNY1VtditJWU5XMEZXUUlJbE55enBBZzdEZkQyWVV0?= =?utf-8?B?T1dlZkFIcHhzSGxTRE1uTEx2R1lHR2I1N2tZUEtTeHBKejVSRlY0VU1yN0N0?= =?utf-8?B?L3hSN0dwanJncjlldDRHN3pvcmJEeURwT3pLTzJ5a0JZSkpid1BFUkswS0t2?= =?utf-8?B?bXZXM3FLMVBCVkEzS0oxMHpqWjVDbzdFMENkR0RnZE5lKzg5RGNyUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7568f4fb-280b-4145-1564-08de5427ea52 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 11:19:14.6685 (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: uHf3YnkPw9gZt7tmrUoCIeyGkOiqLa3e6BfBdr+GEeNvW95r1Yh4Ks1TivRPOxf0KKuvP91Ghgd+LADiHD5iTA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7431 Physmap population has the need to use pages as big as possible to reduce p2m shattering. However that triggers issues when big enough pages are not yet scrubbed, and so scrubbing must be done at allocation time. On some scenarios with added contention the watchdog can trigger: Watchdog timer detects that CPU55 is stuck! ----[ Xen-4.17.5-21 x86_64 debug=n Not tainted ]---- CPU: 55 RIP: e008:[] clear_page_sse2+0x1a/0x30 RFLAGS: 0000000000000202 CONTEXT: hypervisor (d0v12) [...] Xen call trace: [] R clear_page_sse2+0x1a/0x30 [] S clear_domain_page+0x11/0x20 [] S common/page_alloc.c#alloc_heap_pages+0x400/0x5a0 [] S alloc_domheap_pages+0x67/0x180 [] S common/memory.c#populate_physmap+0x22f/0x3b0 [] S do_memory_op+0x728/0x1970 Introduce a mechanism to preempt page scrubbing in populate_physmap(). It relies on stashing the dirty page in the domain struct temporarily to preempt to guest context, so the scrubbing can resume when the domain re-enters the hypercall. The added deferral mechanism will only be used for domain construction, and is designed to be used with a single threaded domain builder. If the toolstack makes concurrent calls to XENMEM_populate_physmap for the same target domain it will trash stashed pages, resulting in slow domain physmap population. Note a similar issue is present in increase reservation. However that hypercall is likely to only be used once the domain is already running and the known implementations use 4K pages. It will be deal with in a separate patch using a different approach, that will also take care of the allocation in populate_physmap() once the domain is running. Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed") Signed-off-by: Roger Pau Monné --- Changes since v1: - New in this version, different approach than v1. --- xen/common/domain.c | 17 +++++++ xen/common/memory.c | 105 +++++++++++++++++++++++++++++++++++++++- xen/common/page_alloc.c | 2 +- xen/include/xen/mm.h | 1 + xen/include/xen/sched.h | 5 ++ 5 files changed, 128 insertions(+), 2 deletions(-) diff --git a/xen/common/domain.c b/xen/common/domain.c index 376351b528c9..5bbbc7e1aada 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -722,6 +722,15 @@ static void _domain_destroy(struct domain *d) XVFREE(d->console); + if ( d->pending_scrub ) + { + BUG_ON(d->creation_finished); + free_domheap_pages(d->pending_scrub, d->pending_scrub_order); + d->pending_scrub = NULL; + d->pending_scrub_order = 0; + d->pending_scrub_index = 0; + } + argo_destroy(d); rangeset_domain_destroy(d); @@ -1678,6 +1687,14 @@ int domain_unpause_by_systemcontroller(struct domain *d) */ if ( new == 0 && !d->creation_finished ) { + if ( d->pending_scrub ) + { + printk(XENLOG_ERR + "%pd: cannot be started with pending dirty pages, destroying\n", + d); + domain_crash(d); + return -EBUSY; + } d->creation_finished = true; arch_domain_creation_finished(d); } diff --git a/xen/common/memory.c b/xen/common/memory.c index 10becf7c1f4c..4ad2cc6428d5 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -159,6 +159,74 @@ static void increase_reservation(struct memop_args *a) a->nr_done = i; } +/* + * Temporary storage for a domain assigned page that's not been fully scrubbed. + * Stored pages must be domheap ones. + * + * The stashed page can be freed at any time by Xen, the caller must pass the + * order and NUMA node requirement to the fetch function to ensure the + * currently stashed page matches it's requirements. + */ +static void stash_allocation(struct domain *d, struct page_info *page, + unsigned int order, unsigned int scrub_index) +{ + BUG_ON(d->creation_finished); + + rspin_lock(&d->page_alloc_lock); + + /* + * Drop any stashed allocation to accommodated the current one. This + * interface is designed to be used for single-threaded domain creation. + */ + if ( d->pending_scrub ) + free_domheap_pages(d->pending_scrub, d->pending_scrub_order); + + d->pending_scrub_index = scrub_index; + d->pending_scrub_order = order; + d->pending_scrub = page; + + rspin_unlock(&d->page_alloc_lock); +} + +static struct page_info *get_stashed_allocation(struct domain *d, + unsigned int order, + nodeid_t node, + unsigned int *scrub_index) +{ + struct page_info *page = NULL; + + BUG_ON(d->creation_finished && d->pending_scrub); + + rspin_lock(&d->page_alloc_lock); + + /* + * If there's a pending page to scrub check it satisfies the current + * request. If it doesn't keep it stashed and return NULL. + */ + if ( !d->pending_scrub || d->pending_scrub_order != order || + (node != NUMA_NO_NODE && node != page_to_nid(d->pending_scrub)) ) + goto done; + else + { + page = d->pending_scrub; + *scrub_index = d->pending_scrub_index; + } + + /* + * The caller now owns the page, clear stashed information. Prevent + * concurrent usages of get_stashed_allocation() from returning the same + * page to different contexts. + */ + d->pending_scrub_index = 0; + d->pending_scrub_order = 0; + d->pending_scrub = NULL; + + done: + rspin_unlock(&d->page_alloc_lock); + + return page; +} + static void populate_physmap(struct memop_args *a) { struct page_info *page; @@ -275,7 +343,18 @@ static void populate_physmap(struct memop_args *a) } else { - page = alloc_domheap_pages(d, a->extent_order, a->memflags); + unsigned int scrub_start = 0; + nodeid_t node = + (a->memflags & MEMF_exact_node) ? MEMF_get_node(a->memflags) + : NUMA_NO_NODE; + + page = get_stashed_allocation(d, a->extent_order, node, + &scrub_start); + + if ( !page ) + page = alloc_domheap_pages(d, a->extent_order, + a->memflags | (d->creation_finished ? 0 + : MEMF_no_scrub)); if ( unlikely(!page) ) { @@ -286,6 +365,30 @@ static void populate_physmap(struct memop_args *a) goto out; } + if ( !d->creation_finished ) + { + unsigned int dirty_cnt = 0, j; + + /* Check if there's anything to scrub. */ + for ( j = scrub_start; j < (1U << a->extent_order); j++ ) + { + if ( !test_and_clear_bit(_PGC_need_scrub, + &page[j].count_info) ) + continue; + + scrub_one_page(&page[j], true); + + if ( (j + 1) != (1U << a->extent_order) && + !(++dirty_cnt & 0xff) && + hypercall_preempt_check() ) + { + a->preempted = 1; + stash_allocation(d, page, a->extent_order, ++j); + goto out; + } + } + } + if ( unlikely(a->memflags & MEMF_no_tlbflush) ) { for ( j = 0; j < (1U << a->extent_order); j++ ) diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index de1480316f05..c9e82fd7ab62 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -792,7 +792,7 @@ static void page_list_add_scrub(struct page_info *pg, unsigned int node, # define scrub_page_cold clear_page_cold #endif -static void scrub_one_page(const struct page_info *pg, bool cold) +void scrub_one_page(const struct page_info *pg, bool cold) { void *ptr; diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index 426362adb2f4..f249c52cb7d8 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -144,6 +144,7 @@ unsigned long avail_domheap_pages_region( unsigned long avail_node_heap_pages(unsigned int nodeid); #define alloc_domheap_page(d,f) (alloc_domheap_pages(d,0,f)) #define free_domheap_page(p) (free_domheap_pages(p,0)) +void scrub_one_page(const struct page_info *pg, bool cold); int online_page(mfn_t mfn, uint32_t *status); int offline_page(mfn_t mfn, int broken, uint32_t *status); diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index 91d6a49daf16..735d5b76b411 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -661,6 +661,11 @@ struct domain /* Pointer to console settings; NULL for system domains. */ struct domain_console *console; + + /* Pointer to allocated domheap page that possibly needs scrubbing. */ + struct page_info *pending_scrub; + unsigned int pending_scrub_order; + unsigned int pending_scrub_index; } __aligned(PAGE_SIZE); static inline struct page_list_head *page_to_list( -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 15 11:19:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 11:19:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204859.1519413 (Exim 4.92) (envelope-from ) id 1vgLNz-0004FX-Rf; Thu, 15 Jan 2026 11:19:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204859.1519413; Thu, 15 Jan 2026 11:19:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgLNz-0004ER-NU; Thu, 15 Jan 2026 11:19:31 +0000 Received: by outflank-mailman (input) for mailman id 1204859; Thu, 15 Jan 2026 11:19:31 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgLNz-0003bC-54 for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 11:19:31 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0f2361ce-f204-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 12:19:29 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by LV3PR03MB7431.namprd03.prod.outlook.com (2603:10b6:408:194::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Thu, 15 Jan 2026 11:19:17 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Thu, 15 Jan 2026 11:19: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: 0f2361ce-f204-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=RpLNlcoW4ZS/4PZdX86LFV4SElXBvYn6qZyvpbWap/HT0iG/p4VXsDO5JqcxRInLmZximCMpxDuB9JW8O6Hzks3boKV83inZMmJwI2xhcJCE2H81xOLZCxJf9iWs0RRPCPByy11seBucIPDz/2MIptMHp/WNNLWNCzQ04DbGrXt2X9yVodimHSKxOrA/M4OfxhjmnmObXISDzbFzr/dZKmKBcwJ/0JISn+FhX9hXhZgvHT/saZFiZrqyiMohebuCd2KrNXHa57ZZc9i89V2RHrigzPVByU0FK4N0wefTJdihMAxKy7II4+0491CmikWPdYW04vO8bKUVMY9OS6SxYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qYRYoLFH/OVP5b6Hea05RAtPOi9OmM1ZzKogWwOxcy8=; b=sraHMv1h8XjJ0TMXDeyzLdU0YFF2FGreysT32lKNpbJ7cO2wux/HrLt3pAXu3ii2CzqoXaaUymLCFIxrnd0Dvnd+r1bRqGOIGxQ6YVEFDTUaLl/7aNfv57sa12YXf1H7LW+ITqXPsaNTWPD0MKu3MZpRC7EfwaDN6e911/BzKreLh8QCM6ezTXyhaHhvIpgvI35zU1stm4UGr/VyhzzqHngKob0b4t3mZOeWTCrfBIWKPp+fgDygWVmJuQHwi0yNiLcyGMfd3UvGewPzUQ/6Ob7OeWzZRBhcTGzjLuNCGYmWx2YIV7hRs+UTxERwrAd6wpowRi4IuHOdtvD+N0Cw6Q== 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=qYRYoLFH/OVP5b6Hea05RAtPOi9OmM1ZzKogWwOxcy8=; b=arjkhKQS4bbdHaQYk9pWVhf+tZcdB5E+v1doX47iWoT1jNeuAVAVlMCZWF0kEDEE1lKKireneNb7ROI50Ung1z+9UdEPlIVDeLw46aOLrrh6Fgqft/M2RJLjNyLqotbN3kdvHX2jtlb/v8zQnPfGyoqhLoXsblNDWO4w1AZBatI= 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 , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v2 3/3] xen/mm: limit non-scrubbed allocations to a specific order Date: Thu, 15 Jan 2026 12:18:04 +0100 Message-ID: <20260115111804.40199-4-roger.pau@citrix.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260115111804.40199-1-roger.pau@citrix.com> References: <20260115111804.40199-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: BLAPR03CA0160.namprd03.prod.outlook.com (2603:10b6:208:32f::25) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|LV3PR03MB7431:EE_ X-MS-Office365-Filtering-Correlation-Id: 3c766822-244e-43d2-0faa-08de5427ebff 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?WkxabVFJQXRJeG1WTmtaUHltcE9aa2ZnaklYU3cwK3crU1Z3TjJUd2I0Z3l1?= =?utf-8?B?WVNqQjJuVVp4WmNjWnZhVDBiakE1emJpdXNhTnUxb1F4dkNuSHhsY21KN3p3?= =?utf-8?B?eGpHK2p2TWxhbitqNzdNa2FGZUk4WDE4L1pQNTZNTXhHTGp3cGp4MGlmZGdj?= =?utf-8?B?Z29BZ1pIK2FobmlnOWN3dm92WlZ1TjNkdnZSSW13cGE0L2o0VlBwcUk3Yk05?= =?utf-8?B?Z093aTN4WHA3dkJUNnNwNFk3cnlpWDZqZ05BbTFwUlZOajBjdmlWOUU1NGV0?= =?utf-8?B?Y0ZCaXVnVC9nTTErUUx5em5JTEdnaE5YRWpYRGYxQXJuNnA2QlIyUG4vZVg2?= =?utf-8?B?TEpwbkE4a2g4R1RSbkMzRkUvVU1LNGRGdmxJWFdLNExVc2tSMUw5UytSY1hO?= =?utf-8?B?NUhNY2tHUWNucW9pY0VHN3NvRzRVc21LMzg0K29SYzB4WGNkaHo1alFGMjJN?= =?utf-8?B?d1ZJSEgraXNGUTdFM3VUdDFsNHE3akFZbGYySXd3UkQ1ZUlURGpHM0RLUE1s?= =?utf-8?B?R0k1M29sMzE0eHB4T3lCc1VhUG1uRHZIbzJWUDh6ZmE5WFQ3VEQ0ZmpGNHpi?= =?utf-8?B?M3RMcUNzQ083WFhoNXZRQ2V6TXFibFBwRDRZVlFZZldVTWp3aU9WdStQTkF1?= =?utf-8?B?RmlyQzhDWXhOZXZFaFNoaFM0R09Dekx3WnhJaVhBTWZIZStrMXNGdkMrbmpI?= =?utf-8?B?eE12dGM5cnhWQkJuQnZFOUVvcFAzdHlOeE9IcGtpTW9sRjd1dDBiUUowZmpv?= =?utf-8?B?eE5tQ0hoR1dROTNoanJ5RFQrTkd4L05ac2dDVDk0R1p0NEozSDgxcU51TUhq?= =?utf-8?B?STd2UmVyMlQzdkJySVBKNVdINS9wU3lVcDZLVk9nT1l5SWtXRjduc2dYVDE4?= =?utf-8?B?dzVVbDdlZ0RQRWowN2RiZHM3WTNUYUdudTlTcXdTV1lFYVdtd25BMnp4aDZu?= =?utf-8?B?RTZ2RnNtQlJVQ0xUVjZxMUl3bllITEZzcGR3cDNWaFFTeVRVRVZPZWhzUzc2?= =?utf-8?B?ak5Fa2FKWXJVZ1hIOEZkNmdvVTdMMkI2eEZkeGN2WFFGQWxQclVSZ1ZTcTg0?= =?utf-8?B?dWgzeWxkQ0hkSzZxOEx6Uzh2ZVhISUhmZGVNMHpOek1ZZzloR3ZUVzV6am1u?= =?utf-8?B?YklXalRGSTQvZEIyTExNSVlLRDM3ZmoyZDVDZ1JKc3FrSDIyNHNaTlhCbVQw?= =?utf-8?B?RUpQVkREaG9TTm1vaHNnUVM3STNHd0pmYjFvSGxyYlJpaDhmZjlrZkh0bTht?= =?utf-8?B?NElPTy9PQ3ZvLzlaMUdpYmlrTHVvUm83VVdQTGduS05oa052RXlWZFZMY3ZE?= =?utf-8?B?SzlPUXFUQUg1UXBsVnZNcDE0alRlMWRJTnRZN1F0bVZVM2w5TUZSMUdWdTVH?= =?utf-8?B?d0xYdGJCdGRzSlgzVmFIYmlkODBiL2cwQVpoVEtQY2c2MEVXUzJBQ25sWkV5?= =?utf-8?B?OFA0SG9iUHJoTFF5V2hOTmh0bWl6cmpzckJFM0pnQ0JEYU9SYTZtWVBnYkx6?= =?utf-8?B?dS8vOWVRZElGUWYwa2NKTDhoY1BWblVUZlBId0N3S0lSQ0puYnFhcDFISjJs?= =?utf-8?B?ZzNpRDR0dWo2TEs4cUM0VVdMWGtOUjdBNklQRmJ4RkhxT1BueW5XOGFCMVQ4?= =?utf-8?B?c0hEc3plOEszUk1Vamk3b2cwYmhFWWE5SGIrTHNmSzVHcExQbVIyUC8zUWxX?= =?utf-8?B?c1ExZXVlMXZJM0hxbkR5VWJCV1d0L3JPWTJUMjhlL1dOZGxOTlIrVFBUekx4?= =?utf-8?B?WnNKOTJZa0JSdWg4U1dVZ2JPamhRdzkyVjhXTTlNWVVWcVhEMDJqRzdKamNQ?= =?utf-8?B?bmZyeDhKSFhlL3hrU01vMzBwWHp6WWRyTmdYUm9qbTZoOWp2TllnT1lNKzBp?= =?utf-8?B?dFVvb2VIcGVnZGsyLzZzdXc0Wmcxb0dxNytTUVdlaE1EVCtKeUIzaEJ0TURO?= =?utf-8?B?L2xya1V2ZHRkcFN5VitWejBScjRhOHBjNGYzTForelJ4dnhnZk84QnJqTzhR?= =?utf-8?B?WnBVQXJ5MXBEZzh0U3g5N2hqZi9uYXU0UUo1ZzFZMlRYeGdsLzd1SzF6N1lm?= =?utf-8?B?bi9Wcll3QlZSL3VLYUN3SitocXlCNk9OdXVmcVJlaldmRG5YV3BxYW5heHNs?= =?utf-8?Q?tveM=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cU80ZzRKdzIwRTlrdlF4VEdJQkdkM0s0Q0t6bFNsYVlwS3F3cngwRVhIbUh4?= =?utf-8?B?cXE3cjZKaXcvY1Y4dmxpVXdFcHlXT2xYM2dLeVVJUG94ckJFT0dUajFhcU5x?= =?utf-8?B?RU5HbUJid28rYy9DdnRtVjFiNy9KSk5xNjUzZGlQbk8xN2VwbENkWlQxNTdP?= =?utf-8?B?REhhVUE0c0FaOXhTdDZSbDVOUlVqSG83MWdpeER2ZmJWUVB6ZTNXZndBVkh2?= =?utf-8?B?RkJFS2JRRE5mR1dIMWhtSTVRUXVWMEo3cmhUaGNuSVZXLzJzYjlLblFzUjRU?= =?utf-8?B?S0dMcUhXQjBoVGI5bVZtUzlYQU05Zm9QN1J5VEVkcTcxNXZPaEpPTjlZVFBN?= =?utf-8?B?L25TZGoxekRyOC9XYlRQZUUzVEJ2OEd6cEVMQjdJWDU3OTQ1a3Q4bTR3aE5O?= =?utf-8?B?TVF5cnpPNTFmMG5Id0xLNGNLOCtvY00yQ1BvTVcyV0NPWkdGeW1sSUUraklH?= =?utf-8?B?ZGlURTM2b09yVElEekZpQ1Bna2VQRGt1SW84RXV6V29ucWdNYWwwYmRRaVRU?= =?utf-8?B?dGJhRWxXM3Z0djFTbzdXellCT1BXdGJPSEtBWDgxaDBydWpmdFM0QWxLNktl?= =?utf-8?B?QkNJTDdlZXpVZUZqdmdvUFdaMEdic1NiS1B6cFpJRVpaajdzQ1lOZHVFKzNn?= =?utf-8?B?T1VVYXZnaG5MWitwU3RVLzdCNVhQTHp5eFZwMTBqRlVWYVltVFlEOVh4dDI2?= =?utf-8?B?N0FrY0FSYXhLVlYrM21jaUkrcDliSVErNVBpQWRxSU1ZRTdlak9TMHh6a3dP?= =?utf-8?B?d2FJUG05RDNmeXJ4L1RJdFFPQytOVDB5SUlaOWgxWWpjd2tQVjA2d3drZ29j?= =?utf-8?B?ek5oUjVheU1sN2ZYSEZ3SWZ0SGwwMEtqWlpPOFpKNzNFUXArMFRMSHNxNjJi?= =?utf-8?B?Tlp2NDZsSGtlS0R4QS9adHJoNklxR0RRN0t6cWlSY3VVRzM2ZXFqRXBDbHk4?= =?utf-8?B?Y0FydHpaWklTbUtvWC9SYVZETVkrVDZvMXRhN0hKM2lydC8vQWJGdFJVNWxX?= =?utf-8?B?Tmx1VDB5WHZmS0RLYVE0OTJzRURWOWlVMHBNZHQ4UjBraGJNN2R3K0JtVFBq?= =?utf-8?B?SndwTWFwcy8vSWs2UmF4T2MwSlovUm9HelVIUnI3VjdlOXhQbzcyV0cySnJQ?= =?utf-8?B?NGhYYUVRNzRqSjM4OWQ4ZHF4R1FYTmJtajJrekpnQk5PZTA1clFFc2NIc0JV?= =?utf-8?B?NUZjR3czUXF1RSttbUFRcURRNmNRank1UkpFMm5sMStXZmJwa0VRQ1pad0Uy?= =?utf-8?B?Q2pUN2JyVDlhS0c5V29hQ3JsVEVtamxsNmlzcEZHcTZHSFFKQlFGQjhzSWhT?= =?utf-8?B?bENOVGNrT0VGcStuZk9kMC9zQ3F1UXVSbWdLdGRsYllNZmtqZHhPTzhIUzli?= =?utf-8?B?VWhTUCtnTnBnaXJkMEVNRXp4SVhObGh0RG1RL3ljejJhWVp3aHEvMzJreDcy?= =?utf-8?B?VnlpTDBXYzRkdk03bjNOR1padkM0UWRkaTBkWnBndExWNE1YMGkrVHdBZC9J?= =?utf-8?B?UTBEZm5pSmVxNWxpdDRGZ3BCS0lLNktiRkF6dTRlMjd2UUxzazhMdVRydlAy?= =?utf-8?B?VDl5TkpaNnppaC9VRndNekdVbUQySkdhdGV2YnFHTXU1ZXU3dXA1dS9lZFB6?= =?utf-8?B?QUxDSDVmL3FjdXplSFMyanpidUZhcVRWOWZQRDBYTU5LVFVKSUlIdDhIMVJ3?= =?utf-8?B?RHBBcGFoQ0RNVkJqMmpUdGpEby9xeTAybzhIRU5xcHJkenplemM2ZGVCMjk2?= =?utf-8?B?NGJkcFdwS2hDd0lRY0pBVEhqemUvZmVqaHZWU0hCempDb2gvOWUzc3JqV0JG?= =?utf-8?B?bDk1TFJlTzNEd1B2ZWdyMC9PNHcxUFZsaU9VMlR5Y081UVk2MkNHVWgwMjZP?= =?utf-8?B?TktUTHVtdnFiNG03V0kxck1EeGl2L2l2MDZKVUFYc0lCNFZ6NTlhdnh1NHps?= =?utf-8?B?VmxzOGRGY0VmWFZEWk9uN2dsQ0JUQWR5ckN1MDQ2QzN5bFFvRS9QVlZJTStU?= =?utf-8?B?TFZvOHZWc0t2cjczdXhtb3NZK0RyMGhmeU02TzJObEt1eStBeitLNHRkRy9j?= =?utf-8?B?ckY0LzFSL2FjVzIwc0JoMHY5RFZtZGVrSmkyUWFTMVdwSGl1ZjJ4aFdycmdW?= =?utf-8?B?ZGVaekN1Mk5JQmxFckVDVStHR3hGWUd3OXhGT3c2Qnd1dzVqaUI0Ym9NcktI?= =?utf-8?B?UXQvSDcyekE0NnZDdjVVdGtMNDVKUWRyVDRrMVRaS2cvVld1YXJEb3RPbG1B?= =?utf-8?B?YmhuSGpuc0NuVlA0d0VhZFhuNFJ1djhxZ2U1WWpueFE1MTcxWnc3TjZjNU9z?= =?utf-8?B?aWMvSWRqdnVIdCtFVlpuUUdJalc5NU9rYTFuSGdieGVnUUJxTkExUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3c766822-244e-43d2-0faa-08de5427ebff X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 11:19:17.4639 (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: J7bUeytQMKGfayYO+GtGefv2lU2m8PotS+zopPiep/Qq/CaqL3/icEpJplAark2nUvx5RmaClqxVzeefUMCu7A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7431 The current logic allows for up to 1G pages to be scrubbed in place, which can cause the watchdog to trigger in practice. Reduce the limit for in-place scrubbed allocations to a newly introduced define: CONFIG_DIRTY_MAX_ORDER. This currently defaults to CONFIG_DOMU_MAX_ORDER on all architectures. Also introduce a command line option to set the value. Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed") Signed-off-by: Roger Pau Monné --- Changes since v1: - Split from previous patch. - Introduce a command line option to set the limit. --- docs/misc/xen-command-line.pandoc | 9 +++++++++ xen/common/page_alloc.c | 23 ++++++++++++++++++++++- 2 files changed, 31 insertions(+), 1 deletion(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 50d7edb2488e..65b4dfc826b5 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -1822,6 +1822,15 @@ Specify the deepest C-state CPUs are permitted to be placed in, and optionally the maximum sub C-state to be used used. The latter only applies to the highest permitted C-state. +### max-order-dirty +> `= ` + +Specify the maximum allocation order allowed when scrubbing allocated pages +in-place. The allocation is non-preemptive, and hence the value must be keep +low enough to avoid hogging the CPU for too long. + +Defaults to `CONFIG_DIRTY_MAX_ORDER` or if unset to `CONFIG_DOMU_MAX_ORDER`. + ### max_gsi_irqs (x86) > `= ` diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index c9e82fd7ab62..728b4d6c9861 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -267,6 +267,13 @@ static PAGE_LIST_HEAD(page_offlined_list); /* Broken page list, protected by heap_lock. */ static PAGE_LIST_HEAD(page_broken_list); +/* Maximum order allowed for allocations with MEMF_no_scrub. */ +#ifndef CONFIG_DIRTY_MAX_ORDER +# define CONFIG_DIRTY_MAX_ORDER CONFIG_DOMU_MAX_ORDER +#endif +static unsigned int __ro_after_init dirty_max_order = CONFIG_DIRTY_MAX_ORDER; +integer_param("max-order-dirty", dirty_max_order); + /************************* * BOOT-TIME ALLOCATOR */ @@ -1008,7 +1015,13 @@ static struct page_info *alloc_heap_pages( pg = get_free_buddy(zone_lo, zone_hi, order, memflags, d); /* Try getting a dirty buddy if we couldn't get a clean one. */ - if ( !pg && !(memflags & MEMF_no_scrub) ) + if ( !pg && !(memflags & MEMF_no_scrub) && + /* + * Allow any order unscrubbed allocations during boot time, we + * compensate by processing softirqs in the scrubbing loop below once + * irqs are enabled. + */ + (order <= dirty_max_order || system_state < SYS_STATE_active) ) pg = get_free_buddy(zone_lo, zone_hi, order, memflags | MEMF_no_scrub, d); if ( !pg ) @@ -1117,6 +1130,14 @@ static struct page_info *alloc_heap_pages( scrub_one_page(&pg[i], cold); dirty_cnt++; + + /* + * Use SYS_STATE_smp_boot explicitly; ahead of that state + * interrupts are disabled. + */ + if ( system_state == SYS_STATE_smp_boot && + !(dirty_cnt & 0xff) ) + process_pending_softirqs(); } else check_one_page(&pg[i]); -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 15 11:46:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 11:46:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204921.1519428 (Exim 4.92) (envelope-from ) id 1vgLni-0000uK-30; Thu, 15 Jan 2026 11:46:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204921.1519428; Thu, 15 Jan 2026 11: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 1vgLni-0000uD-08; Thu, 15 Jan 2026 11:46:06 +0000 Received: by outflank-mailman (input) for mailman id 1204921; Thu, 15 Jan 2026 11: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 1vgLng-0000u7-Lb for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 11:46:04 +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 c4e2aac8-f207-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 12:46:03 +0100 (CET) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-b8712507269so124652966b.3 for ; Thu, 15 Jan 2026 03:46:03 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b86ebfd08b2sm1611040666b.25.2026.01.15.03.46.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 03:46:01 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c4e2aac8-f207-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768477562; x=1769082362; 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=cBDntRF5odkNRAOPBPSdTMmWZ0IZJrCgtKbD4q2DrxI=; b=kM5QvSLlSF0ggntnkvxiB0u9Or4WD0O2p5BLO8dY47Z5bvC76xqATlk/OfjlvTRpLg NOefgnEq/RIswXj9yGW7kT4R6vZOMj0I7ID4FyDUEvf7SGSH8Ck/LzFPP9zLdnLvbdlJ E2eU2bCjDC9Vj1S1VlH4QPVx/zbHTuh8d8DZWMLh5YWH0li27ntBO2HZCsYeR0JMxF4Y XOC5WkmEZ21Sq+LUPqHy8u67zIZyRQyHxpGMjWZhIIbd/ok+3aPjug3FYxO7dOyLjTdI HZyw2f6gqc2L8Hy2CNMy18rbAG0aOzmksyPUnAnjvmjvCaaEJpuEYBEO+0yFamPjOxbv 5jIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768477562; x=1769082362; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cBDntRF5odkNRAOPBPSdTMmWZ0IZJrCgtKbD4q2DrxI=; b=oXEYVvkYK9eIMRKPe2DG2bJy9hueG1Im7o6y+WqPBVRJnTn9oMgpzdiZutOK7sWP+k 66aAJGYSvhHuAi1NS/qKx/qkSHxfPBaZ7Aa/nwp/lrAa9Ep45sEwOrLOx3BqxKJz12N1 dMNZYaV+Qg3VyPay1VZh7xYnOHx1qu1rcmutgAT2/pKPHNtit0UAG9jlwWzxzg1DJT3y 7oPyTp4QFzNSQ4APfjGTVmaenwrviq89t/Xuop2gqLT0PfJPNc4pZw8aiYgJHK+G0X4D YG21qZcJ/VZrQb0MBJMrGf03NsfWbeUjsQW2siw77TZIWx3WCxymGhP1S9aRVFCFdyOB GP5w== X-Forwarded-Encrypted: i=1; AJvYcCU0+JmpOO5tytjTDIn8Y0jVLx1mRft9Gx2wmhsh2qHKxwhZM+9f0SuqeDSeLZ9/wA8cp3iYNPKJL3k=@lists.xenproject.org X-Gm-Message-State: AOJu0YwmPg24rJqsrEniV2dKZb1kIjyV+YMlaw9ntNHRhsoa1MiNHNJ3 cOdp1EaRa+yiXU7xQhgoChJY/m3YIjtAyPHAU7x6y2Rx2cr9aePjsIiz X-Gm-Gg: AY/fxX76d6uR9edZVHlGdr3nEZJd/DSueddUWECE6oKRnfWFHZjwTLuyR7LCamtdOJ7 Sq7N+K5bGuqqBVF+0bstdasA8z/p5755k0U2qmii1Z/Ued095dI7L/XVipdqVBfBNDQHO/aC1Xu UbJrE6DOLP/0Zh3LUv+E5QLxUOcVyk11kN4Maa1TLAOst/RuDHdZxIHap9Bl8HqdQP4s2JtL1cX 7ARCLLuY5MfjtPimhaHxehbGd8j9kzDrMGcaMFR8dnO4NDUDc5718s4pc/0QuoTRcSZCAG8M1Yb KyiBOLn2hMU1U4IV6GBt7rhG8M8KRTYnorvaucJn3RzpNBVeybJIXib1XLzRfdFOO3x6j+EtaiE JtELE7n/vnDQ/lZRjy2sKJOXtl7q81n7sXNGAVIX5w5BqG1aBkChHRW4RwVH26Vvr8mHj+YUvgb jT6ek9Ia17XRREjXNXsaVpo0yUHIJuUxrmy3ODj3e3h32RLRq/dGESRlpEFVC1E0A= X-Received: by 2002:a17:907:80b:b0:b86:f3d2:efae with SMTP id a640c23a62f3a-b87612a489bmr535889666b.35.1768477562273; Thu, 15 Jan 2026 03:46:02 -0800 (PST) Message-ID: Date: Thu, 15 Jan 2026 12:46:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 07/15] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <7a90cc1b-b053-4b9f-91f1-d32064b1ec29@gmail.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 1/15/26 11:59 AM, Jan Beulich wrote: > On 15.01.2026 11:55, Oleksii Kurochko wrote: >> On 1/15/26 10:52 AM, Jan Beulich wrote: >>> On 15.01.2026 10:14, Oleksii Kurochko wrote: >>>> On 1/14/26 4:56 PM, Jan Beulich wrote: >>>>> On 14.01.2026 16:39, Oleksii Kurochko wrote: >>>>>> If a guest will do "That (the 1 -> 0 transitions) could be (guest) writes >>>>>> to SVIP, for example." then the correspondent HVIP (and HIP as usually >>>>>> they are aliasis of HVIP) bits will be updated. And that is why we need >>>>>> vcpu_sync_interrupts() I've mentioned in one of replies and sync VSSIP: >>>>>> +void vcpu_sync_interrupts(struct vcpu *v) >>>>>> +{ >>>>>> + unsigned long hvip; >>>>>> + >>>>>> + /* Read current HVIP and VSIE CSRs */ >>>>>> + v->arch.vsie = csr_read(CSR_VSIE); >>>>>> + >>>>>> + /* Sync-up HVIP.VSSIP bit changes does by Guest */ >>>>>> + hvip = csr_read(CSR_HVIP); >>>>>> + if ( (v->arch.hvip ^ hvip) & BIT(IRQ_VS_SOFT, UL) ) >>>>>> + { >>>>>> + if ( hvip & BIT(IRQ_VS_SOFT, UL) ) >>>>>> + { >>>>>> + if ( !test_and_set_bit(IRQ_VS_SOFT, >>>>>> + &v->arch.irqs_pending_mask) ) >>>>>> + set_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); >>>>>> + } >>>>>> + else >>>>>> + { >>>>>> + if ( !test_and_set_bit(IRQ_VS_SOFT, >>>>>> + &v->arch.irqs_pending_mask) ) >>>>>> + clear_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); >>>>>> + } >>>>>> + } >>>>> I fear I don't understand this at all. Why would the guest having set a >>>>> pending bit not result in the IRQ to be marked pending? >>>> Maybe it is wrong assumption but based on the spec: >>>> Bits sip.SSIP and sie.SSIE are the interrupt-pending and interrupt-enable >>>> bits for supervisor-level software interrupts. If implemented, SSIP is >>>> writable in sip and may also be set to 1 by a platform-specific interrupt >>>> controller. >>>> and: >>>> Interprocessor interrupts are sent to other harts by implementation-specific >>>> means, which will ultimately cause the SSIP bit to be set in the recipient >>>> hart’s sip register. >>>> >>>> Meaning that sending an IPI to self by writing 1 to sip.SSIP is >>>> well-defined. The same should be true of vsip.SSIP while in VS mode. >>> I can't read that out of the text above. To the contrary, "will ultimately cause >>> the SSIP bit to be set" suggests to me that the bit is not to be set by writing >>> the CSR. Things still may work like this for self-IPI, but that wouldn't follow >>> from the quotation above. >> Why not that wouldn't follow from the quotation above? >> >> The first quotation tells that we can do self-IPI so VSSIP.SSIP will set to 1 >> what we could miss SSIP bit if won't explicitly try to read h/w HVIP (or VSSIP, >> or whatever other alias of the SSIP bit) and sync with what we have cached >> in hypervisor. > The bit being writable doesn't imply that it being written with 1 would also > trigger an interruption. If that's indeed the behavior, it surely is being > said elsewhere. According to the spec it will trap to S-mode (VS-mode in our context) if both of the following are true: (a) either the current privilege mode is S and the SIE bit in the sstatus register is set, or the current privilege mode has less privilege than S-mode; and (b) bit i is set in both sip and sie. Even without a triggering an interrupt I think it we can still lose set bit in VSSIP register (if Im not mistaken something). If we won't do a sync of cached hvip and h/w hvip then it could lead to the issue we lost a real SSIP bit value. For example, guest before entering hypervisor set VSSIP.SSIP to 1 what means what means that hip.VSSIP will be also set to 1 as: When bit 2 of hideleg is zero, vsip.SSIP and vsie.SSIE are read-only zeros. Else, vsip.SSIP and vsie.SSIE are aliases of hip.VSSIP and hie.VSSIE. And so hvip.SSIP will be set to 1 as: Bits hip.VSSIP and hie.VSSIE are the interrupt-pending and interrupt-enable bits for VS-level software interrupts. VSSIP in hip is an alias (writable) of the same bit in hvip. And then if we don't sync cached hvip with h/w hvip, it could lead to then when we will put cached hvip (which has .VSSIP set to 0) overwrite h/w hvip.VSSIP which was set to 1. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Jan 15 11:48:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 11:48:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204929.1519439 (Exim 4.92) (envelope-from ) id 1vgLqK-0001bG-Ft; Thu, 15 Jan 2026 11:48:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204929.1519439; Thu, 15 Jan 2026 11:48:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgLqK-0001b5-Cd; Thu, 15 Jan 2026 11:48:48 +0000 Received: by outflank-mailman (input) for mailman id 1204929; Thu, 15 Jan 2026 11:48: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 1vgLqI-0001Zq-Hq for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 11:48:46 +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 231a826b-f208-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 12:48:41 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by CH1PR03MB8168.namprd03.prod.outlook.com (2603:10b6:610:2b0::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Thu, 15 Jan 2026 11:48:37 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Thu, 15 Jan 2026 11:48: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: 231a826b-f208-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=uZmpNaWM8FunqOPJd2IJANwFx2dhWgpHmcZJ2/TJCyImMX8c8p+B/4YgYX59gsYTfu26Dnt85fck/4tBKqjjtzahI4iTIaVZwGqKjTpoFFdd8fFovMuRQx3+LlOjt0UxZhgOw7iq15iSlOAwbVZBfXSRje/JiFBMNpOtex80nMAlabAdXA4FZCp8wXtqDHFBZ+TfC2+QaN+e+6yZfw3DJLkaDKn6+Sx4tOVACAYlmAzuiU6b4G549tl5ks9gxeG8G5WfojfISN5NMjYCpM4T2tGpt6dgi0WZNvjgf8/r3Cd/RX4mdQgh0Vuvv7makunL/4Wr1rePRfFVzHeMvJ7fUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zw2SFA/9uekFeQTeIzgEzl8vbJdzSOciNg4Yk3D9LL4=; b=bGSMQJ5DCme9Q3pdOG3DVhQbI6VYpTxvs8ZORmHqKQtRo68Ci+Irppyf53oe0HE5CAjn6q1t+lhXimU5HhQ+qq2ugPjd7I0Nbm+k3otOu1m6/YPdRV2nGQfBWkelVVHvCbcdgShzBNq6goYdVWT29Lra3ZWnju+t6uLkD12MXeq1ECoqwilhqIFV7GNTKKixu/MZM2R2jukPX88djx3F4wSAgdey6L8QOIZ2V68RkCbng7bISn0dd7HR+oGzYFexl7oQK8SDzTK7snRA4G9VLeS9LlUXzjWC0aRpHwgsCNRZcoSAaoNaIQ7mrrx0RozmSnZqY9mErN6bjW502AxkRw== 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=zw2SFA/9uekFeQTeIzgEzl8vbJdzSOciNg4Yk3D9LL4=; b=LXYERUA1HEaHDQQd3N+3G5rFWgbkhTFy9XQ5krXWfed/XtY3IDFapq90viyG3hl7lwfMWwKIwK4k5CeiWSbdUUc7z4KznzBQidOpxwCE9EYVerPqzvIdq0qq3Jiry6wGH+e837lSSZvepovlZhs0cUv+pvqQrYoKIPXe72LaZzI= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 15 Jan 2026 12:48:34 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , =?utf-8?B?0JDQvdGC0L7QvSDQnNCw0YDQutC+0LI=?= Subject: Re: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() Message-ID: References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> <49507100-faa9-4480-a534-e4bab6cecc5b@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <49507100-faa9-4480-a534-e4bab6cecc5b@suse.com> X-ClientProxiedBy: MA2P292CA0002.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:1::18) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|CH1PR03MB8168:EE_ X-MS-Office365-Filtering-Correlation-Id: 0541d5f1-bfb7-4fde-29a2-08de542c050f 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?MnFSeVh5aVNobFZpTlJGN3ZDLzZUUEtvNjBUcXk3YWovVElUT3NPTVlpRnpV?= =?utf-8?B?RUkzckdaaW5ya01CN1dZNjhBSDMvUlFjakE4MS93MnU0ZWRCdzVFQUlCWEV5?= =?utf-8?B?Uk1UQ2w1VVJqQWNiVFBEOEU5WkkwbDNVOWNOK3ZFenJwZ3oySTA5VWVqMTFn?= =?utf-8?B?MTJrSHVSQy9tRVBEaE9vcmloQjh1cHppeWI4RGs1akM2U0laRUY3K2tYNzVk?= =?utf-8?B?ekhWTGdPZlY0SUdUU2JOdlNacW12TE1TV3crSEVCNGs3RmxOQWFuNHdhSlZ2?= =?utf-8?B?ZDhBM2NqUzh0cFNuRTl0Qi8rcjc3TG1aQjA4TWhFSURjd2ZTc2dRYjJoOVlQ?= =?utf-8?B?RDJqQUFYOFZtWXl3clFPYTdkQm9TcjlvUzlOaGhyVTRYTGp3cTIyZUxMZThj?= =?utf-8?B?eG84SEY4QnQ0SlBUVVJ0WHFLTnRrYy9OdVlTOGMxbU1saU8ybXAzNW5nM2lH?= =?utf-8?B?MTdJNk1CWUVnb0pRQ0E0djh4bFlCd0MyVnd6OUhLVk8xMjgvRlllVFgycy9F?= =?utf-8?B?TDFGT1dlZ0RYME1reE5oNS9RYWhrTk9kblVZZ2h6NThLU2U3WVp1ZzZyUUpw?= =?utf-8?B?VWp1N1RKcDlHUXBSWXRQTEZqMWgvZ1VkOVdZVjlNaEk3TEFwZUppUFRuaTdq?= =?utf-8?B?YUxxMW41ZG5XZjhrYi93SHV1ZTlaME9hWE5KL2JyeTNuTnZING4vamNiZ1JP?= =?utf-8?B?Qithb1RxWUxGRnJuOGlBTk5nQUxVY3dCK2oyUVBZRlpjTVhlUE5MSUdCUENz?= =?utf-8?B?bHkzblFwY0ViM1FrcEhFTTlrSytLRS9NOHdpaGFremdtTmtwb1NvL21uOGhC?= =?utf-8?B?OTFDUmxJeVpYazArS3dmRDdVOTR5TDRHSXZlNkVuOXBQQnVlNkRGaE1sYVZw?= =?utf-8?B?OUx5end4QWliZjJWdHZQeGpCVXAvVFBJT2RrUDQ3N1duZFA4YURHTFlXd21m?= =?utf-8?B?WkcrWnVzQk9hN0RlblJTQXhSbkJhMEc4SzdXSGRkbUQ0RGJCSjhEVnpjSVEw?= =?utf-8?B?RkVCUjlpS3lBdjZ4RjAxekZwdGh3eGVXLzdpaTZCMGlCOHFvUVYycmRrUEVH?= =?utf-8?B?bzVEZUNYTG9NRnJBN051bE5OczBZejRycGZIb203dkJkNWJSYVU5aWNIOHZU?= =?utf-8?B?R2Jmbkt6SmZMUHZYdk90bzVBTy9ycW9iMzhlSWhvb3VlUk9MeWd2UnljM2R3?= =?utf-8?B?NWdjS3hDMnVucXJETlR1cnY2enJaMTlGZmtTc0F2TSs4M1dYNEp6aE5RUVYr?= =?utf-8?B?QWthNml3S0hBeWJvb25sdXpFNEVBa2cwTzlzQXRpcWpLbmlkVGJwUDJ4ZEJj?= =?utf-8?B?eGx0WFVsQXdJNk5VNVpZZDROTHNNU2tqcDNUS3dJSEdsNFdndzROaU9SaUhV?= =?utf-8?B?QW4zeGhTeXUyTklqZUZSMnZFQXhGRmRuZG5tVGdmK1Q3TXN3RFZDTU9jZmZ5?= =?utf-8?B?N0l3TmovWlFRZEEyM09YNWRXamR0d0orN1V0dmc5NjhWdGhlaW1iZEVsTXFR?= =?utf-8?B?SVUvcWtCeWFzT0dqaHhnNFRwU1R0cEJqUll0ZTZKaDN5MW9pc2d5bm5vdXBF?= =?utf-8?B?ZzVrcWxaWlZka0dHR1pXRTMydk5nUmh0QTNwdFpFWlBhVDlvRlQ4QXRENXpB?= =?utf-8?B?a0RiVXMrQjJKZlplUTlVT0syMWVva0lVemVGZWVvOFZ1QTBNZzZpbzdtcWlT?= =?utf-8?B?aW1Fczd4aDNFd3drc3FqSjNVaExwRnFsOE1hQThxWHRmNnpEeWpCU2dSVy9l?= =?utf-8?B?UWRyZ28rT3pjcGNLa0ZkTlU3Y0RtSUc0SzJUTnB4SUltdjdFeVdTcjhGOGU2?= =?utf-8?B?N3ZOS3AwZ3EzZE9RM0lnampKUXFGTWF5QXBQWTA0Q2FsTUVSSnNnK3ZkTG0x?= =?utf-8?B?UG84dEphamxjNU1XaWZMdDV3TUFqUHRvTU8rcnlHYzJxaHBSUnFlQ2ZGOW9O?= =?utf-8?B?Y0RzYks0SHNuQThCS2w5MFA2RGxRclRKZHNGTjFieUk1dWhBUlhVZE00VjBZ?= =?utf-8?B?dnZmVFhsQmVpTTRVbVpvYzgyRFF6NEluZ3UxWC9zWlMzZ1Z0bjYxQzdYSmp5?= =?utf-8?B?Q0ZsTzZUUVNpbENxcWhHbVBzN3IzZFpBazRWZWxjTno5ZFM2RHIwVTNMVjZG?= =?utf-8?Q?vyGQ=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bVorcGs3ZGZFV3dRRGQ0TGxKdE9HUzIrOW8xUTZUWUJacTFicnhEWmt1UXg2?= =?utf-8?B?OFNpMjJlL2RkRjc0d3VuQnFrZmx1TTErYzlQVm9vcWd2a0gvTUMvUlIwYWhI?= =?utf-8?B?bVZzWm5UVGIxSzVUNUU4Z1REc3daaU9Gak82TGNZVm1ORXVobFJJNldqdEdH?= =?utf-8?B?Yzd6WmRDVTE4NWVTQzdJaEc3d0FaTVVxeFVMQ1JaWmRnZGsvMzQ0VFVQMUFl?= =?utf-8?B?TlgvYmM4ZWhDS05YdVdtejlDeTF2Q2ZSOUFVQkJCaG5taGJTMlpVbkFOc0JP?= =?utf-8?B?L09LbTdXZTVLd1hQeGh4aXdrRmM3ekxCSVJQSzhEVnpvUEdRanJKQmtGaXF2?= =?utf-8?B?aWlmb1BPYVNzSVBiVUlnOW1RK2lyK3F3UkExaUlRZzA0Sy96anU3VWtqbkVH?= =?utf-8?B?S2RNVHBkQzhRY3M3WUdSL3Mzb2VmZGNBNWtBMVNwVjhCbHNqYjVLeGl0QmRK?= =?utf-8?B?QWduWnozQjlNTWwxSzY0QjFDc0g0NDVZN2lYT2o4QmlzK1oyUk1nV0V3TXY5?= =?utf-8?B?bnR3V2VDZ05COUNNRW5qcHJBK1NqRE81VWdOQWdxYld4NjZRUEMrTVdmRktM?= =?utf-8?B?eUVzRStIdmJncmF2cEZpc01wV09ib0pzQkZpSHFtaEVFaVd5ang4ZFZYK2hT?= =?utf-8?B?WUVmaGRpZm8zam5xUGY5Rmc4a0dNZlVQQmxXUTdSRGcwTmUybERTdTEyQW0z?= =?utf-8?B?VXNMWEg5Y0s1S1g4b05sT0t1VElGYk43UldrbWtRUSt5Y20yNEVhWkRvdlBZ?= =?utf-8?B?b0hrT2gyMGE1NjgxWGpTTndEUEtPNzd6OXZIRXJhZExsVUdGZTk4dUMrYW8r?= =?utf-8?B?SndhbE5sYjJ5MWhTVG5hclJraCtOZE1IdWpOVFNaQkgvR2k1a3VndkoyOWtM?= =?utf-8?B?TGp4L2RPQmJvOW5KeVZ4M2RNMkNtakZod2dSZkxaK2VtNWphM1poRnBPeXNM?= =?utf-8?B?YXpOUi9hdzZiZFArWko4MFFjR2dJVDdJUGJ4S3Z4LzBKanNkVnM3MENhanUx?= =?utf-8?B?YVNza0RvblhEdjNZTlVVMm94YTlGYm4vSTdmMVBBQkxidEJGUmpSTHlkd2Yy?= =?utf-8?B?bndEem9qY0tMNHdwYzZ4T2FQYkFZUjVyLzFQNkN5UEY1QkJFOTljWEdXbEZq?= =?utf-8?B?WCt1ZFR3STcwb0NlQXQvNmVLWXo1Qmg1RXAzOHlhSEdTT09mWUJ5bDBTb2x6?= =?utf-8?B?WWdlSVFxOHZpYnI1VmtoQlhTcnhmL0UzSWpOOVdzNWhRb3gzdzVsN3lsVW1C?= =?utf-8?B?V2thNnlHVHZvTzl5eXJWUnIyYjh4ZlVoODRhbVExdzUvVGRtZkRNNGdEVFBH?= =?utf-8?B?dVZyejArWnNYOUlOV2d1KzhIWmwxcjR1a3lIY1Z6TUozWGZUaGtMNEJEUTFX?= =?utf-8?B?SFljZlZaYTFaWlJZMEJwYnl2dWkxdVFad1Ivcmdaanh2Uy9oOHZ5WWdzWDB1?= =?utf-8?B?YmZmeHlHTmtrWjN4ZCtXTElFdU9XeVZjN2R3MjVldVZ4aU1IbDF5cTdnSWhn?= =?utf-8?B?cXM4MWVacmNFOStQLzd0UFJ0SE1rWmkzdkdENlpXNit1bEpCU1hqaElqZHZL?= =?utf-8?B?cUdmdTUyYXh0RHdSY1RmMC9IdWoxYmJ2eUhqL0p1akZnc255UW5TVFNzWDFU?= =?utf-8?B?MDFXQk5tWmUrYWwrUmNudC84VUdKZklDOFplaW1RYys5cTdNSll4Q2tmeU9L?= =?utf-8?B?LzJlT0hHSFk2TzRmNE1POGNaMElZVi96SXEyZ2NkaVhsMlduQlJwNVBjL1RR?= =?utf-8?B?c0k2U0RTMlV5T1YzNDhqdGJuZVdzTlpmZHg0aVNYTVkvcHNsbUY2V2VEa01R?= =?utf-8?B?ZG1xd2lBckVPV2tYdlFFRkw0WEdnOEVYODdGbGsySEx2SmJCUm9XemtIeWxG?= =?utf-8?B?ZTZxTitFK3oycHNGWUNzUHBGTU5nZHZEdDBmZ2wvbGJTM203bnRPeDZDNnov?= =?utf-8?B?R1c3N3Y3KzJnRm1oL3QwUElCUTk3Q3ErTmtFSHU1U0pXVWd5MUxyd2JBQzFa?= =?utf-8?B?MmxEQkVLR3FzRkZySVlVaUxERThQc3A0Q2RLb3VSQXhaN3dIWGNBWTI2ekM1?= =?utf-8?B?dkFXZ2V3T3VLRWVWNE9kRlFPaFRPeG4wOUYvbFZTcHpXeSszSTFrMTh3YUkr?= =?utf-8?B?TmdUM0MvNEZ0MEh5ZEppRzhmQVVwcnZRTDV3Mm5IdFFnRlpoNEp2cFVhczRz?= =?utf-8?B?Wm1LL2pRU2Y0a2Via09MNWhKMmdzV3ZhcjIyNUdQVWFNNXE4RUtOZ3VWc3Qr?= =?utf-8?B?UU90K25ITmRSTmlVcmFOL1piMERmaTc4TVNRM2RVbFJ4WlJrMW5DaTRtQWxH?= =?utf-8?B?NlFROXBtZGxISmU2QTdCemdoSUZBMUduSXVxS3lBRTlIdCtvLzBiQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0541d5f1-bfb7-4fde-29a2-08de542c050f X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 11:48:37.5521 (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: 4thryce/7U2I/1WtiEIXw89FdIjOTm+a3lp7Hm1PbFuCX+zjnpTy0/TSRmUjEpc8mx9Q91YAfBODcwNwV00zGQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PR03MB8168 On Thu, Jan 15, 2026 at 11:38:10AM +0100, Jan Beulich wrote: > On 15.01.2026 09:24, Roger Pau Monné wrote: > > On Thu, Jan 15, 2026 at 09:00:07AM +0100, Jan Beulich wrote: > >> On 14.01.2026 18:49, Roger Pau Monné wrote: > >>> On Tue, Jan 06, 2026 at 02:58:11PM +0100, Jan Beulich wrote: > >>>> amd_check_erratum_1474() (next to its call to tsc_ticks2ns()) has a > >>>> comment towards the TSC being "sane", but is that correct? Due to > >>>> TSC_ADJUST, rdtsc() may well return a huge value (and the TSC would then > >>>> wrap through 0 at some point). Shouldn't we subtract boot_tsc_stamp before > >>>> calling tsc_ticks2ns()? > >>> > >>> amd_check_erratum_1474() runs after early_time_init(), which would > >>> have cleared any TSC_ADJUST offset AFAICT. There's a note in the > >>> initcall to that regard: > >>> > >>> /* > >>> * Must be executed after early_time_init() for tsc_ticks2ns() to have been > >>> * calibrated. That prevents us doing the check in init_amd(). > >>> */ > >>> presmp_initcall(amd_check_erratum_1474); > >> > >> Hmm, I should have written "Due to e.g. TSC_ADJUST". Firmware may also > >> have played other games with MSR_TSC. > > > > For amd_check_erratum_1474() we don't want to subtract boot_tsc_stamp, > > otherwise when kexec'ed we won't be accounting properly for the time > > since host startup, as subtracting boot_tsc_stamp would remove any > > time consumed by a previously run OS. > > For both this and ... > > >>>> A similar issue looks to exist in tsc_get_info(), again when rdtsc() > >>>> possibly returns a huge value due to TSC_ADJUST. Once again I wonder > >>>> whether we shouldn't subtract boot_tsc_stamp. > >>> > >>> I would expect tsc_get_info() to also get called exclusively after > >>> early_time_init()? > >> > >> Same here then (obviously). > > > > For tsc_get_info() I think you are worried that the TSC might > > overflow, and hence the calculation in scale_delta() would then be > > skewed. We must have other instances of this pattern however, what > > about get_s_time_fixed(), I think it would also be affected? > > > > Or maybe I'm not understanding the concern. Given the proposed > > scale_delta() logic, it won't be possible to distinguish rdtsc > > overflowing from a value in the past. > > ... this, my main point really is that scale_delta() (as its name says), > and hence also tsc_ticks2ns(), shouldn't be used on absolute counts, but > only deltas. (Yes, an absolute count can be viewed as delta from 0, but > that's correct only if we know the TSC started counting from 0 and was > never adjusted by some bias.) Well amd_check_erratum_1474() does want the delta from 0 to the current TSC, because that's the best? way to see when C6 needs to be disabled. Otherwise we just straight disable C6 on boot on affected systems. IMO the problem is not about using tsc_ticks2ns() or scale_delta() with absolute or delta values, the issue if how the "delta" passed to those functions is calculated. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 15 12:00:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 12:00:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204950.1519448 (Exim 4.92) (envelope-from ) id 1vgM15-0003Rs-JE; Thu, 15 Jan 2026 11:59:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204950.1519448; Thu, 15 Jan 2026 11: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 1vgM15-0003Rl-Ge; Thu, 15 Jan 2026 11:59:55 +0000 Received: by outflank-mailman (input) for mailman id 1204950; Thu, 15 Jan 2026 11:59:54 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgM14-0003Rf-4H for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 11:59:54 +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 b32d0744-f209-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 12:59:52 +0100 (CET) Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-432d256c2a9so815123f8f.3 for ; Thu, 15 Jan 2026 03:59:52 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af6535ddsm5494514f8f.15.2026.01.15.03.59.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 03:59:51 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b32d0744-f209-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768478392; x=1769083192; 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=mURageZvhTtiW+61SxASMO6hw1Ff0KysHUSzTfh1Ww4=; b=Nlxn6Ewj7nYi+AiHUaHWYTKwpb8o5qXEsCj7GoDwG1rKfzZLbkHkjQFkqW6QTl8+kw 2kO5BnxHutVwAL+rJWmX0YA2KnGdnUnQASxQYZtU5gCTlsNq8Xqkc5cbJ4gFMmI29guf RxiH8kF3vJynFJ8FUEokLqYnwZbkjVXZl068LbPy89oekxpgQGC9BY71ftmAORQBbgMk iVCiDs+SQcI3wq7eCn4KtHGvCVaD6rsxt3JzHdjrlwDWvKi+fmsuYnjhJO6tgQ7Ga1XN Dp54gNQHI/PhM2lv1FFw2BUFWdT8g/rjaRau3ajeeIa275nujYmckaRsyHBhm8BgQUi/ h9/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768478392; x=1769083192; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mURageZvhTtiW+61SxASMO6hw1Ff0KysHUSzTfh1Ww4=; b=cY4+mf5VL0Rcr4bW/i2ZW3bN4Vapsb2Vzj08HCe9JXndmJ4s38NRBqzmuk73sHriYi Ym6qaQGVmSiAaTCqlZuGDIt21+jDBtXaG1kEQuvHkadFX/EiRP3vRqKWIzQ9pvVZsDn2 dMDcOmJoCrm+cfp31tBtjCkfBP01BcrrUZS1+a7mvi1cCcDxyTbrGqgacC6gckVI9QzQ tYwy+o+RfHCARQgqbnq0Eorki7ToDOREwMJBAhwJ4mSAarKB8hJEN8sw+lUvEpNUZjok S8mbckkk5dx6KVVbCG2rmLgtZ3dvieEv4CvrPzfPZeGls1bPr8ExD+c89XJLX0oI0+K8 zpIA== X-Forwarded-Encrypted: i=1; AJvYcCULnBS/n5NEb/Fbz6Agm4BP+ykIEZC7OXtxbAAC5nfPNMnXomyP/5JMspSV6cI88NRzAUDAYnZph48=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy4C++BfVPI+bKA9lbwetj3F/b571KXTnXuk/P1m06TJ3cZiRG2 5d6Xh57nrOgebA/TI39QFaFdPw7Lbo97Af/XH4kp3MZfaZfsgZXitJFYXMIlxDAX1A== X-Gm-Gg: AY/fxX6Ja5RWJwf6F1nOP4fUEipLn7hYR+rj2hO49FkZ+tsNGqhGLRSqz9FZbiDzPIj N6dD+uks3q1boq3hTTQD3DQTLhXMvUkNBj34Q3cVbBavl4Z3JLyLAymPMWIkujeRDzG4KqMYdSR 4H5Yc60xzlL9xMdZhii+NK6JuLd00SziHR2zMGapsErx+ig3hWnHZ1NxM8MZrvINjWf/PUiYLjS WXY57pq/G9qZ1AWhUEQ2ogHWpvlXB8WaPoE6are9TRGKR/2w5o/Xt38zBw2HS/9w1lHRUc1ZyEX vdqqQg5BfdL8BjfzixIrsgon4E8pcxONJ3BzusZIE0rZ0uQ/OVjdvmC4Hie/iyxr+BlGsC7Sh7F PzZcaBd3zR9Ng0AxEWsqLwYUWuQiB9Tsn3SYuYfqcSB4PvW/+f5j9WmBhl8uk/K+5qodSS9f3Kh bdTIyVmPdnqxyCJ71sQh+NGO0kAhdGrjfn8u7u41JkVjkYpJ586DUf728JwsAzKe7q1leZx0Mal H4BFKyLBvz5Ag== X-Received: by 2002:a05:6000:4027:b0:432:86e1:bd38 with SMTP id ffacd0b85a97d-4342c5483b1mr7136421f8f.39.1768478391764; Thu, 15 Jan 2026 03:59:51 -0800 (PST) Message-ID: <8539bed5-280f-4dcc-a63d-4c0ee3b7cff7@suse.com> Date: Thu, 15 Jan 2026 12:59:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 3/5] lib/arm: Add I/O memory copy helpers From: Jan Beulich To: Oleksii Moisieiev Cc: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" References: Content-Language: en-US Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 15.01.2026 10:26, Jan Beulich wrote: > On 14.01.2026 19:29, Oleksii Moisieiev wrote: >> --- /dev/null >> +++ b/xen/lib/arm/memcpy_fromio.c >> @@ -0,0 +1,48 @@ >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> +#include >> +#include >> + >> +/* >> + * Use 32-bit raw IO operations for portability across ARM32/ARM64 where >> + * 64-bit accessors may not be atomic and some devices only support 32-bit >> + * aligned accesses. >> + */ >> + >> +void memcpy_fromio(void *to, const volatile void __iomem *from, >> + size_t count) >> +{ >> + while ( count && (!IS_ALIGNED((unsigned long)from, 4) || >> + !IS_ALIGNED((unsigned long)to, 4)) ) > > Nit: Xen style indentation (no hard tabs) please throughout. > >> + { >> + *(uint8_t *)to = __raw_readb(from); >> + from++; >> + to++; >> + count--; >> + } >> + >> + while ( count >= 4 ) >> + { >> + *(uint32_t *)to = __raw_readl(from); >> + from += 4; >> + to += 4; >> + count -= 4; >> + } >> + >> + while ( count ) >> + { >> + *(uint8_t *)to = __raw_readb(from); >> + from++; >> + to++; >> + count--; >> + } >> +} > > Barrier requirements on Arm aren't quite clear to me here: Is it really correct > to use __raw_read{b,w,l}() here, rather than read{b,w,l}()? If it was, wouldn't > a barrier then be needed at the end of the function? Thinking about it, as the order of MMIO accesses needs to be guaranteed (unless you have extra information about the area's properties, like it being a video frame buffer), I'm pretty sure now that read{b,w,l}() needs using here. In fact the comment in the header says that it would handle "Memory ordering and barriers" when it doesn't look as if it did. Note how Linux looks to have grown multiple flavors: Besides memcpy_fromio() I can also spot at least fb_memcpy_fromio() and sdio_memcpy_fromio(). > And then, if it was read{b,w,l}() that is to be used here, what about all of > this would then still be Arm-specific? Hmm, I guess the IS_ALIGNED() on "to" is, > but that's Arm32-specific, with Arm64 not needing it? Plus then it's again not > exactly Arm-specific, but specific to all architectures where misaligned > accesses may fault. There's a bigger issue here, with access granularity (despite the header claiming "Implement alignment handling for devices requiring specific access sizes"). MMIO can behave in interesting ways. The header comment says nothing as to restrictions, i.e. when these functions may not be used. Yet consider a device registers of which must be accessed in 32-bit chunks. As long as the other pointer is suitably aligned, all would be fine. But you handle the case where it isn't, and hence that case then also needs to function correctly. At the same time accesses to a devices requiring 16- or 64bit granularity wouldn't work at all, which for required 8-bit granularity it would again only work partly. How much of the above requires code adjustments and how much should be dealt with by updating commentary I don't know, as I know nothing about your particular use case, nor about possible future ones. Also note that the header comment still references the ..._relaxed() functions, when then implementation doesn't use those anymore. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 12:04:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 12:04:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204965.1519459 (Exim 4.92) (envelope-from ) id 1vgM5P-00053p-8I; Thu, 15 Jan 2026 12:04:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204965.1519459; Thu, 15 Jan 2026 12: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 1vgM5P-00053i-5I; Thu, 15 Jan 2026 12:04:23 +0000 Received: by outflank-mailman (input) for mailman id 1204965; Thu, 15 Jan 2026 12:04: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 1vgM5N-00053c-VN for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 12:04:21 +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 52548c3d-f20a-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 13:04:19 +0100 (CET) Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-430fbb6012bso568318f8f.1 for ; Thu, 15 Jan 2026 04:04:19 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af64a65bsm5589978f8f.7.2026.01.15.04.04.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 04:04:18 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 52548c3d-f20a-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768478659; x=1769083459; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=es4pAXIiZJcaSHieisvPWWIhTRVmg+2omFF/nirmX0A=; b=EkNJqd+J8wUvWn859GfWndPkkTLS7goYYy6Up0CkVA3nSCzBsrrSfNqSkG7z6cYymA Ppufgp2bHI12DXZf0gPLydBJsUvlnea/cGV4c5YOec1ZdlLAMV8QDkBshe4ScFB7SXRN pGt5H5HMdi4xAU0xxeKKB9wvjK/Wj7ltrZeXyUZBLyKhBgStMxvpe3N0T6odR9kDH9zk uBq9bA+G4QMJ5wiUDJUWO234Rh8kKfvInw30Orm2cUB8jVhg4wy6nFd3rUCS9L+mfSZP IKmOLWYhNjfi1R+ZeXfu2pJUIjbnTQtQ7yiCxjmkLemjGs+g1cxW3LRlYU8kEZSVcHE3 Xwsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768478659; x=1769083459; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=es4pAXIiZJcaSHieisvPWWIhTRVmg+2omFF/nirmX0A=; b=uT3CCzq5malZ03+bwHkEn33AVf0aJRiTGBu7TbLHKQYdtrnduHerZr8wPvL6uDZvMD PwC2dxw7nCQ/3V1y0DNgAHmy4Xt3gIBidRZNDL/5A0lz3EUP0iC9ZdeB+0FWpSuB1bcO ryFlW8bTN72ZpsOYstMyKhcOBerGPuXr2kOrMAqcOMs3xmoupHckMinkr0afNS85l9+q Ql00PBsqm4ykU7vk8Tqqq7IpFqphS6vjY0BEZ+LqYO3k1IWN5ro2BRlWeNiVT9XDE8U7 5g/bzFpEMb6p39eWZ7xc7rQb0cSR4+i612+goSY+oq+R9pvwbeewjIadeEPBkwe20gvg exDA== X-Gm-Message-State: AOJu0YwzRRHm9sUsxPjN3SlTATpSwLQoyT/IHTX1Y75jQHIwNjvTjsbA WfjHgcHXYiw8M/QsAfKtX4rG+EvVxciMSQxXh9F3npXD48ZKe6XorcpmoJ1dgExYcw== X-Gm-Gg: AY/fxX5rU/avnlsWZE0ishTLp3ZvaiTzZZMtkC9cn94JBN4nW2WtTWaXaM5NmIgcZbs EiQ3IpcPLeSWgSLHizHzDUMU2KCfF6w3uzN/lVRAf+UnC0g67PNdSFCPyw+i+OeB+YDk/zUUdD8 uTGkrOtzZy9EsphveulaTIJy0jHoHwF7OPCQSD5d48dC6aHieCFLftSfOhMiCJ3+EQGjoFpBTwQ S5xN5xfaQTPlLm7GKI/wMLvlV/JZnBWY2VW1rYol6yRM+z+cElJ78Wq2wlGuWp+t6zXEJrE2puD q/TkDuyNoH1Mg6/sfJ7AQNfmDW2AB+pYPFbH6bQMIhSP3bQpBbWBacHDEtJCRKbJO04QBx8UoQO lQrbC/hVqhDXCeEcOEBnZgjWI75DOpG6vfP+J1gAFLm2vCEVCkAPqtdadlMPU9ENgj+Wu0T9MSr sZ+0wBWoU0o/8r0RFKhn7p0A3J7wVocObc1Zbs49dGi1pFgolkGiZqdhfl1J7kCWKxg6ejlKgnc dU= X-Received: by 2002:a05:6000:1867:b0:430:f449:5f17 with SMTP id ffacd0b85a97d-4342c569a14mr7689406f8f.42.1768478658864; Thu, 15 Jan 2026 04:04:18 -0800 (PST) Message-ID: Date: Thu, 15 Jan 2026 13:04:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , =?UTF-8?B?0JDQvdGC0L7QvSDQnNCw0YDQutC+0LI=?= References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> <49507100-faa9-4480-a534-e4bab6cecc5b@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 15.01.2026 12:48, Roger Pau Monné wrote: > On Thu, Jan 15, 2026 at 11:38:10AM +0100, Jan Beulich wrote: >> On 15.01.2026 09:24, Roger Pau Monné wrote: >>> On Thu, Jan 15, 2026 at 09:00:07AM +0100, Jan Beulich wrote: >>>> On 14.01.2026 18:49, Roger Pau Monné wrote: >>>>> On Tue, Jan 06, 2026 at 02:58:11PM +0100, Jan Beulich wrote: >>>>>> amd_check_erratum_1474() (next to its call to tsc_ticks2ns()) has a >>>>>> comment towards the TSC being "sane", but is that correct? Due to >>>>>> TSC_ADJUST, rdtsc() may well return a huge value (and the TSC would then >>>>>> wrap through 0 at some point). Shouldn't we subtract boot_tsc_stamp before >>>>>> calling tsc_ticks2ns()? >>>>> >>>>> amd_check_erratum_1474() runs after early_time_init(), which would >>>>> have cleared any TSC_ADJUST offset AFAICT. There's a note in the >>>>> initcall to that regard: >>>>> >>>>> /* >>>>> * Must be executed after early_time_init() for tsc_ticks2ns() to have been >>>>> * calibrated. That prevents us doing the check in init_amd(). >>>>> */ >>>>> presmp_initcall(amd_check_erratum_1474); >>>> >>>> Hmm, I should have written "Due to e.g. TSC_ADJUST". Firmware may also >>>> have played other games with MSR_TSC. >>> >>> For amd_check_erratum_1474() we don't want to subtract boot_tsc_stamp, >>> otherwise when kexec'ed we won't be accounting properly for the time >>> since host startup, as subtracting boot_tsc_stamp would remove any >>> time consumed by a previously run OS. >> >> For both this and ... >> >>>>>> A similar issue looks to exist in tsc_get_info(), again when rdtsc() >>>>>> possibly returns a huge value due to TSC_ADJUST. Once again I wonder >>>>>> whether we shouldn't subtract boot_tsc_stamp. >>>>> >>>>> I would expect tsc_get_info() to also get called exclusively after >>>>> early_time_init()? >>>> >>>> Same here then (obviously). >>> >>> For tsc_get_info() I think you are worried that the TSC might >>> overflow, and hence the calculation in scale_delta() would then be >>> skewed. We must have other instances of this pattern however, what >>> about get_s_time_fixed(), I think it would also be affected? >>> >>> Or maybe I'm not understanding the concern. Given the proposed >>> scale_delta() logic, it won't be possible to distinguish rdtsc >>> overflowing from a value in the past. >> >> ... this, my main point really is that scale_delta() (as its name says), >> and hence also tsc_ticks2ns(), shouldn't be used on absolute counts, but >> only deltas. (Yes, an absolute count can be viewed as delta from 0, but >> that's correct only if we know the TSC started counting from 0 and was >> never adjusted by some bias.) > > Well amd_check_erratum_1474() does want the delta from 0 to the > current TSC, because that's the best? way to see when C6 needs to be > disabled. Otherwise we just straight disable C6 on boot on affected > systems. I think that may be necessary when we don't know what was done to the TSC before we took control of the system. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 12:09:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 12:09:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1204977.1519469 (Exim 4.92) (envelope-from ) id 1vgMAk-0005qm-S7; Thu, 15 Jan 2026 12:09:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1204977.1519469; Thu, 15 Jan 2026 12:09:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgMAk-0005qf-OB; Thu, 15 Jan 2026 12:09:54 +0000 Received: by outflank-mailman (input) for mailman id 1204977; Thu, 15 Jan 2026 12:09: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 1vgMAj-0005qZ-E1 for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 12:09:53 +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 17857f66-f20b-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 13:09:50 +0100 (CET) Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-432d2c7dd52so691789f8f.2 for ; Thu, 15 Jan 2026 04:09:50 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af6fca57sm5340612f8f.42.2026.01.15.04.09.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 04:09:49 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 17857f66-f20b-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768478990; x=1769083790; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=fVNLL7Ed0X6HGAu6P4eo0tISqnJrZlBVXmfFsuNGwik=; b=U+q4wKE4BL+XJ5gWyBwwAWPTruV2cnIbQxvLFNPfOcvBie19H3xW+rkjCJgzeiNT8p Te0Z2vJlK62/Nr8eE93qyZZlqdY7qFOt0PdhIo7zHWLX6HQDoDIKDYrz81jbAri8b2AD K31uKFlhYmNkHEzOBrgo6Xt4f1/RhJxly7T/JFUCvSZos/7XCMPo6gQO3MfeIMlLqdRK xuomeLEEhjRtvjt44xJL6Qmcz7RlvcAvQGT3dRuGbMuMP80WfXKQp8rup0psmmRWBBSU nBIYFwdbxAvRRxDgk0z9nHc8RHtDSq0feg6+VuqCBp5vfF5gibVHFARkX0dKQfsPaocy Mx9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768478990; x=1769083790; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=fVNLL7Ed0X6HGAu6P4eo0tISqnJrZlBVXmfFsuNGwik=; b=WlWfwvJU2azF1gTDgy4OAKncKJ9BrK3x1SKpzWB2q1JDVu3NeS6dhyZ+TUth1XfGPC fHYbhWnkxJ2wMrbCIBUVg63UG71EprlM0UbHLWc6OAytAIwOHpmSBhkEgnkX556hlCmb eUQj0fiyq11DNAo2GpT0P4LRGVG/ol3Pc0DW/rpI7THhxcTj/GzTowaP9WFCiHwq5vjs mxaE/Uu5DzvMBr3oO3sCmku0/l/OijeMQOERkibpowg4vh5ZTHoSdwC3msm/ukKU2yKu XPoqDEURvTEIdHZWb/CQRChR3DYz7TTg6WrvO8LpvA50i4It4wKbWtl/udLV7Js8M5Zd nb4g== X-Forwarded-Encrypted: i=1; AJvYcCXqSUh8kOWSvqMgfV44WLsD+j8x8kixBuIZ8hYR0fX+mLPzOObd2hUbE+lu8uK0JFn/kHNOT9sRJkg=@lists.xenproject.org X-Gm-Message-State: AOJu0Yximp+MVSXJhhvFWlM/HZjqoiKCf+grqDbggN3dUGnOg58VmCtY nuTGzof0Dx5WHJ/cUw9MSkPdBXRQzj9crhU8ACV9WP8uICqx/3xuWFrhQRxyaaF+9w== X-Gm-Gg: AY/fxX6YG/mP+2mWJkfVZoQqPHetMQjcYnsKJlkmXazBkzhulq7LQKqVK2azOxx2GR9 Eyo5Axn+OtsiSeW5IQUWfqeSudRBu0OhXtj5UnphWMEun6MJxfR9w6C7yPA9CwfLaJzEBoS1rje nPFPlsAlqN7a+oSxTqK5443yF9bDR2QIYyZkfA3zN1Rx10CCujSpjvTnpR5rQrmjZ3L49jvHS+a Lih+oRzLuDT+6QoFuP9HrE5qUVXonbB2dNzS3zTLk9fcrz7OujgC129NkQezE8j1+Ps/FJuDitj P35eBllU6L3M3qiqcDQ3eRCaCKPuSouScRqhbUNSd9d+wMYq93UAD1ltbWryqbtN+907f3TgNSK CAPcW/qfj8DoFPuvSa5oZC8XY7PJLqlGjI1/GS3jfAgTPyzw7B8UjboKzlmDLtt4Sbq9spSikkf igYDVg3mZT+nERzjF3sz28IuX3S6o0bDRd5ikhSTxoVBl/uWz9BdpdWgnfrf0U4uJtQrJQud2GZ nM= X-Received: by 2002:a05:6000:2403:b0:42c:b8fd:21b3 with SMTP id ffacd0b85a97d-4342c574ca2mr7777111f8f.57.1768478989667; Thu, 15 Jan 2026 04:09:49 -0800 (PST) Message-ID: Date: Thu, 15 Jan 2026 13:09:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 07/15] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <7a90cc1b-b053-4b9f-91f1-d32064b1ec29@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 15.01.2026 12:46, Oleksii Kurochko wrote: > > On 1/15/26 11:59 AM, Jan Beulich wrote: >> On 15.01.2026 11:55, Oleksii Kurochko wrote: >>> On 1/15/26 10:52 AM, Jan Beulich wrote: >>>> On 15.01.2026 10:14, Oleksii Kurochko wrote: >>>>> On 1/14/26 4:56 PM, Jan Beulich wrote: >>>>>> On 14.01.2026 16:39, Oleksii Kurochko wrote: >>>>>>> If a guest will do "That (the 1 -> 0 transitions) could be (guest) writes >>>>>>> to SVIP, for example." then the correspondent HVIP (and HIP as usually >>>>>>> they are aliasis of HVIP) bits will be updated. And that is why we need >>>>>>> vcpu_sync_interrupts() I've mentioned in one of replies and sync VSSIP: >>>>>>> +void vcpu_sync_interrupts(struct vcpu *v) >>>>>>> +{ >>>>>>> + unsigned long hvip; >>>>>>> + >>>>>>> + /* Read current HVIP and VSIE CSRs */ >>>>>>> + v->arch.vsie = csr_read(CSR_VSIE); >>>>>>> + >>>>>>> + /* Sync-up HVIP.VSSIP bit changes does by Guest */ >>>>>>> + hvip = csr_read(CSR_HVIP); >>>>>>> + if ( (v->arch.hvip ^ hvip) & BIT(IRQ_VS_SOFT, UL) ) >>>>>>> + { >>>>>>> + if ( hvip & BIT(IRQ_VS_SOFT, UL) ) >>>>>>> + { >>>>>>> + if ( !test_and_set_bit(IRQ_VS_SOFT, >>>>>>> + &v->arch.irqs_pending_mask) ) >>>>>>> + set_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); >>>>>>> + } >>>>>>> + else >>>>>>> + { >>>>>>> + if ( !test_and_set_bit(IRQ_VS_SOFT, >>>>>>> + &v->arch.irqs_pending_mask) ) >>>>>>> + clear_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); >>>>>>> + } >>>>>>> + } >>>>>> I fear I don't understand this at all. Why would the guest having set a >>>>>> pending bit not result in the IRQ to be marked pending? >>>>> Maybe it is wrong assumption but based on the spec: >>>>> Bits sip.SSIP and sie.SSIE are the interrupt-pending and interrupt-enable >>>>> bits for supervisor-level software interrupts. If implemented, SSIP is >>>>> writable in sip and may also be set to 1 by a platform-specific interrupt >>>>> controller. >>>>> and: >>>>> Interprocessor interrupts are sent to other harts by implementation-specific >>>>> means, which will ultimately cause the SSIP bit to be set in the recipient >>>>> hart’s sip register. >>>>> >>>>> Meaning that sending an IPI to self by writing 1 to sip.SSIP is >>>>> well-defined. The same should be true of vsip.SSIP while in VS mode. >>>> I can't read that out of the text above. To the contrary, "will ultimately cause >>>> the SSIP bit to be set" suggests to me that the bit is not to be set by writing >>>> the CSR. Things still may work like this for self-IPI, but that wouldn't follow >>>> from the quotation above. >>> Why not that wouldn't follow from the quotation above? >>> >>> The first quotation tells that we can do self-IPI so VSSIP.SSIP will set to 1 >>> what we could miss SSIP bit if won't explicitly try to read h/w HVIP (or VSSIP, >>> or whatever other alias of the SSIP bit) and sync with what we have cached >>> in hypervisor. >> The bit being writable doesn't imply that it being written with 1 would also >> trigger an interruption. If that's indeed the behavior, it surely is being >> said elsewhere. > > According to the spec it will trap to S-mode (VS-mode in our context) if both of > the following are true: (a) either the current privilege mode is S and the SIE > bit in the sstatus register is set, or the current privilege mode has less > privilege than S-mode; and (b) bit i is set in both sip and sie. That's still not it. Here is the relevant quote: "These conditions for an interrupt trap to occur must be evaluated in a bounded amount of time from when an interrupt becomes, or ceases to be, pending in sip, and must also be evaluated immediately following the execution of an SRET instruction or an explicit write to a CSR on which these interrupt trap conditions expressly depend (including sip, sie and sstatus)." Note in particular the "explicit write to a CSR". (Sorry, I did read that before, but I didn't memorize it. Else I wouldn't have asked the original question.) Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 12:25:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 12:25:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205010.1519494 (Exim 4.92) (envelope-from ) id 1vgMPc-0000RU-9Q; Thu, 15 Jan 2026 12:25:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205010.1519494; Thu, 15 Jan 2026 12:25: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 1vgMPc-0000RN-6l; Thu, 15 Jan 2026 12:25:16 +0000 Received: by outflank-mailman (input) for mailman id 1205010; Thu, 15 Jan 2026 12:25: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 1vgMPb-0000RH-BK for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 12:25:15 +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 38b19afe-f20d-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 13:25:04 +0100 (CET) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-65378ba2ff7so1474398a12.2 for ; Thu, 15 Jan 2026 04:25:04 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6541209ce83sm2331670a12.32.2026.01.15.04.25.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 04:25:03 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 38b19afe-f20d-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768479904; x=1769084704; 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=eOmpfRbO7PuUQLpFyvG5O9PMahXJ89Q3CjedLYzFIzg=; b=HxIgBjPrVS9rJVqCVLgO6G+6pR493SXg35lawQHAAK1qmOPiKvGKnabEjxG0nF1Jxg vgajCi4yi3UUx2h42IGTkEDmLKM1p9I3tBmmubrTq0ogzwOvziaHuvPVvAEoukFMX2fm 8pDZtDpgTBaFAOOZd1ddZACIOI4UQxwrxONpbRB5QZuMwMGh4iQT6xPJF0dyG8et1HgI fITjnO3jc6wXfZCCBIyXrStEXu8zeg70RhVhHrGtzxT/+ldi+FAybbkEPt3UUDUKB/Q/ VmmhtRlg0TqUlZExC9JKJiFINNSE/3YLv5gMA/QRQZD48qBaqGLni9ZphI12PlLySdd6 PTeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768479904; x=1769084704; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=eOmpfRbO7PuUQLpFyvG5O9PMahXJ89Q3CjedLYzFIzg=; b=rwhuN65pbdesJ4M00oxSGAJH6BB/9jM4j1Z7HmtwB4LMH8XgUzyn0BGez5eZiOql/q FD+BFyVIi22lKrNczMypstJvZsCbMfn+LETH40W3EiOn6XWyxVTZvJfrkeE6rbeiMkjy nv2HVqbLM7N6Q2qDlMmBlzXQnawhsevH7qB1TowSNOl/hDFTVPGHL71w9x3UYDgiosqs 3BdXtKUiDoHwuUC3cZz+IPK07y9Me/yUygMS4LkCK5XaJAligbJ9Fp+MK5iRXbs1GhQe IsP2aj5j+sIduRPd5bjjrkgTC51YxaejbX6iRj9H3q9NZx369rb5toGn6crJBCE1NrtE rtDQ== X-Forwarded-Encrypted: i=1; AJvYcCXJqCjgn6AtvRSeWgHKWYhJS+0TiGHXA5H8gxGpg263ieoOl7WK5X9pj7DJKiJteF1/PUmfi82w2q8=@lists.xenproject.org X-Gm-Message-State: AOJu0YyybRy1YQBdI4ALkcGkOXGU4XbihdssKz0yRYs/MSrC2/e6Yt7E UiUWhM95FX1L7Zai2lLoVFuJNU6+9UkrZBtxxhG2/dqGUNcu4FuSZQmY X-Gm-Gg: AY/fxX4fAYiU5wLuIQlOr785yES/RVpvg0yPGq21cGaOzIrRCCzOUKdovWfdXsJp94Z hdYwqXUkXEWi8VHjCTRKWYwKYSmv8H0TGQqmRNqs5RtYM3znz5BaPMiKBCG4WELNKAuRRdi/LkF 3OI1P5lkRtKaoYO62NbWOiyv/M2HwL4EqRkMXcSGaKiMMjaiLFb/gnFtMw/IcQfZySqjhvhoLAA IU1W+fZXCkJRC5QAB50sGb/3BHqZ2AFY63k1F7Vs71viHkwSeC/ZYizkwe42N25KWLXFmMzFxDU u2PZyZ2mzTh5jgCT66ZnlrRcUi/PCYXtW6cKmfwW+3jKvSfy72RyHuKg/1MgkPlf3Jo50WL5Vek VA75tumHmlig4M7V0JtTaFFJqMBlgYdHci4k6Dyjnf+6yVHBdVF20LKBgDW2LZYylt71ZxCibV1 IS32KnRMFZrz8pY5YgZYY30wXOxr4W6s6qHujNkqD02ao0ZrIbH/5JsQtcA3S+x1JAdv7dJ9Vxl g== X-Received: by 2002:a05:6402:2804:b0:650:891f:1c06 with SMTP id 4fb4d7f45d1cf-653ec115969mr5063648a12.12.1768479904161; Thu, 15 Jan 2026 04:25:04 -0800 (PST) Message-ID: <9c0fd87d-a953-4728-ad31-93e50fa47bea@gmail.com> Date: Thu, 15 Jan 2026 13:25:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 07/15] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <7a90cc1b-b053-4b9f-91f1-d32064b1ec29@gmail.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 1/15/26 1:09 PM, Jan Beulich wrote: > On 15.01.2026 12:46, Oleksii Kurochko wrote: >> On 1/15/26 11:59 AM, Jan Beulich wrote: >>> On 15.01.2026 11:55, Oleksii Kurochko wrote: >>>> On 1/15/26 10:52 AM, Jan Beulich wrote: >>>>> On 15.01.2026 10:14, Oleksii Kurochko wrote: >>>>>> On 1/14/26 4:56 PM, Jan Beulich wrote: >>>>>>> On 14.01.2026 16:39, Oleksii Kurochko wrote: >>>>>>>> If a guest will do "That (the 1 -> 0 transitions) could be (guest) writes >>>>>>>> to SVIP, for example." then the correspondent HVIP (and HIP as usually >>>>>>>> they are aliasis of HVIP) bits will be updated. And that is why we need >>>>>>>> vcpu_sync_interrupts() I've mentioned in one of replies and sync VSSIP: >>>>>>>> +void vcpu_sync_interrupts(struct vcpu *v) >>>>>>>> +{ >>>>>>>> + unsigned long hvip; >>>>>>>> + >>>>>>>> + /* Read current HVIP and VSIE CSRs */ >>>>>>>> + v->arch.vsie = csr_read(CSR_VSIE); >>>>>>>> + >>>>>>>> + /* Sync-up HVIP.VSSIP bit changes does by Guest */ >>>>>>>> + hvip = csr_read(CSR_HVIP); >>>>>>>> + if ( (v->arch.hvip ^ hvip) & BIT(IRQ_VS_SOFT, UL) ) >>>>>>>> + { >>>>>>>> + if ( hvip & BIT(IRQ_VS_SOFT, UL) ) >>>>>>>> + { >>>>>>>> + if ( !test_and_set_bit(IRQ_VS_SOFT, >>>>>>>> + &v->arch.irqs_pending_mask) ) >>>>>>>> + set_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); >>>>>>>> + } >>>>>>>> + else >>>>>>>> + { >>>>>>>> + if ( !test_and_set_bit(IRQ_VS_SOFT, >>>>>>>> + &v->arch.irqs_pending_mask) ) >>>>>>>> + clear_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); >>>>>>>> + } >>>>>>>> + } >>>>>>> I fear I don't understand this at all. Why would the guest having set a >>>>>>> pending bit not result in the IRQ to be marked pending? >>>>>> Maybe it is wrong assumption but based on the spec: >>>>>> Bits sip.SSIP and sie.SSIE are the interrupt-pending and interrupt-enable >>>>>> bits for supervisor-level software interrupts. If implemented, SSIP is >>>>>> writable in sip and may also be set to 1 by a platform-specific interrupt >>>>>> controller. >>>>>> and: >>>>>> Interprocessor interrupts are sent to other harts by implementation-specific >>>>>> means, which will ultimately cause the SSIP bit to be set in the recipient >>>>>> hart’s sip register. >>>>>> >>>>>> Meaning that sending an IPI to self by writing 1 to sip.SSIP is >>>>>> well-defined. The same should be true of vsip.SSIP while in VS mode. >>>>> I can't read that out of the text above. To the contrary, "will ultimately cause >>>>> the SSIP bit to be set" suggests to me that the bit is not to be set by writing >>>>> the CSR. Things still may work like this for self-IPI, but that wouldn't follow >>>>> from the quotation above. >>>> Why not that wouldn't follow from the quotation above? >>>> >>>> The first quotation tells that we can do self-IPI so VSSIP.SSIP will set to 1 >>>> what we could miss SSIP bit if won't explicitly try to read h/w HVIP (or VSSIP, >>>> or whatever other alias of the SSIP bit) and sync with what we have cached >>>> in hypervisor. >>> The bit being writable doesn't imply that it being written with 1 would also >>> trigger an interruption. If that's indeed the behavior, it surely is being >>> said elsewhere. >> According to the spec it will trap to S-mode (VS-mode in our context) if both of >> the following are true: (a) either the current privilege mode is S and the SIE >> bit in the sstatus register is set, or the current privilege mode has less >> privilege than S-mode; and (b) bit i is set in both sip and sie. > That's still not it. Here is the relevant quote: > > "These conditions for an interrupt trap to occur must be evaluated in a bounded > amount of time from when an interrupt becomes, or ceases to be, pending in sip, > and must also be evaluated immediately following the execution of an SRET > instruction or an explicit write to a CSR on which these interrupt trap > conditions expressly depend (including sip, sie and sstatus)." > > Note in particular the "explicit write to a CSR". (Sorry, I did read that before, > but I didn't memorize it. Else I wouldn't have asked the original question.) Guest can do: csr_write(CSR_SIP, SSIP); what is an explicit write to a CSR. Or it the quote it means a different CSR? ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Jan 15 12:30:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 12:30:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205026.1519504 (Exim 4.92) (envelope-from ) id 1vgMV4-0002F1-0Q; Thu, 15 Jan 2026 12:30:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205026.1519504; Thu, 15 Jan 2026 12:30: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 1vgMV3-0002Eu-TW; Thu, 15 Jan 2026 12:30:53 +0000 Received: by outflank-mailman (input) for mailman id 1205026; Thu, 15 Jan 2026 12:30: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 1vgMV2-0002Eh-SX for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 12:30:52 +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 06e09e9f-f20e-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 13:30:50 +0100 (CET) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-430fbb6012bso593611f8f.1 for ; Thu, 15 Jan 2026 04:30:50 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af6e09acsm5549394f8f.35.2026.01.15.04.30.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 04:30:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 06e09e9f-f20e-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768480250; x=1769085050; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=d52WIRb/PGf9RMMyoJVmGkXAyk/ZJwVAfu2iEAPGvAQ=; b=ao2iqsjfF5yX6OkqwFt1mbE8HAnclTu01G5a0in4YMVXkcXjhOYMNEJwDyeLPotKoo kWyMOBu3x5iY5h2eE+yiYHLVbuGWfUVFFA+QFjb5LiE4DpBL119Vu9PXVnoZbUyTd8cp fi6ZkNWfC0SCXP6+JiQvQmr+F04goyl3YXqSuw2XkiGM107EPv37YNU8eHqBsn3f3MQs enM3Dan/mK9tFtO/gJxYH6sargTxgerNlzrlXV43VgXT2lq/t61yVZvZXB4wM7FoA9As ixsPfvs7hl3xose+igOY7y4StCo/ibJYpYr2oa+hAP/DqReUPJEyRD/ypPc09dPiosQb KgLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768480250; x=1769085050; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=d52WIRb/PGf9RMMyoJVmGkXAyk/ZJwVAfu2iEAPGvAQ=; b=RINaBMChWS/lzgmFcaYaAuE9n8++FBeBSapfiuB0k6by1enL628o5f+GAQu5C1jaZA 92DETX2Cs12lYge5f3JnFQxS2GYkVRI3mwYs7diIOeERyh+MHZPwPrMh4ZBD6VsOAQrQ m1WryOR+Si3q9Vph0sL96KB6ONVJM9pM8QwzOYan3tbTG9MvOql7d1Vu36rShqJyaeOp 1EqpYkvOff3OPaOYJ+fIsuFz3pdnCAojiPTXgvsJEw46U2wOCBdQTVjffLMk2SWcplCX d0GzGLeixW0N9FDWiN2agHS9xIx09qg+wBasriudn/XViwjpdtmXGE41bR+4/7oKoOTX 1yfA== X-Forwarded-Encrypted: i=1; AJvYcCVLcHfC8EYUzEHApq1UiqQu5Q3LRDiVMUW6rMzv56AAfjvOa/R1iACZjBL3i9xdfucEnmEmxARkYLc=@lists.xenproject.org X-Gm-Message-State: AOJu0YwOB26XHm0j2Qol7IZfJXZ2P/Pr5HJnsVX2Z4ApkVFHP4nViVyQ uQET2LpW2JNycQzfh1E9vES3h75bp0Ii4z9TrMv6+i2q6aEz/p0MsvNrNeXoL1ZihA== X-Gm-Gg: AY/fxX6+4XVfWuyNp7jREkY4by51+x0RvFCmRjttRujouuLQWQ2Q+kmvYsmNsU3f5fj OoguqPZ2WP/6cS9m30bxV1QaR7PdZaG6iS+wiAmGBEvPS9luh3xfeaI7tz0saBz1Hc7o0J+7CLe cIZxLBKAP/rNoBupKRQYPhhYiH7fw3va/PVIiNRku1f2+ES5f6TqGKO2fg4y43EMnw0fSMZ9NH7 JYz9g+ElHNgVC5qeyLLx5z2rX7FA9kmpl1yFbrxROiA8UNQveQF2zHzA70m8oHWKq8tns/6Efn5 qh2pDwoJxLNvAo1Oq9K980U8s8zOZSzt7HOHAr8peHNzRr4v+sq4oKD2QHVKQUYYI252uxHcVkz OYIoQwxOLgRGS/nO+WeRaDaZ6DPz7a/nTv/nOb1cnwW6Yp4T3bIokdgklDDjofQ2umqJETlj05O MsUREAOlfIhU2pq9GXfAdsDJKR3mEQrLMNNdS0sQR6deLAj4Pc6dlZ7ln+GhwmHPavmfxi6cNlF to= X-Received: by 2002:a05:6000:40e1:b0:431:54c:6f0 with SMTP id ffacd0b85a97d-4342c4f4d19mr6730417f8f.4.1768480250265; Thu, 15 Jan 2026 04:30:50 -0800 (PST) Message-ID: Date: Thu, 15 Jan 2026 13:30:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 07/15] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <7a90cc1b-b053-4b9f-91f1-d32064b1ec29@gmail.com> <9c0fd87d-a953-4728-ad31-93e50fa47bea@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: <9c0fd87d-a953-4728-ad31-93e50fa47bea@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 15.01.2026 13:25, Oleksii Kurochko wrote: > > On 1/15/26 1:09 PM, Jan Beulich wrote: >> On 15.01.2026 12:46, Oleksii Kurochko wrote: >>> On 1/15/26 11:59 AM, Jan Beulich wrote: >>>> On 15.01.2026 11:55, Oleksii Kurochko wrote: >>>>> On 1/15/26 10:52 AM, Jan Beulich wrote: >>>>>> On 15.01.2026 10:14, Oleksii Kurochko wrote: >>>>>>> On 1/14/26 4:56 PM, Jan Beulich wrote: >>>>>>>> On 14.01.2026 16:39, Oleksii Kurochko wrote: >>>>>>>>> If a guest will do "That (the 1 -> 0 transitions) could be (guest) writes >>>>>>>>> to SVIP, for example." then the correspondent HVIP (and HIP as usually >>>>>>>>> they are aliasis of HVIP) bits will be updated. And that is why we need >>>>>>>>> vcpu_sync_interrupts() I've mentioned in one of replies and sync VSSIP: >>>>>>>>> +void vcpu_sync_interrupts(struct vcpu *v) >>>>>>>>> +{ >>>>>>>>> + unsigned long hvip; >>>>>>>>> + >>>>>>>>> + /* Read current HVIP and VSIE CSRs */ >>>>>>>>> + v->arch.vsie = csr_read(CSR_VSIE); >>>>>>>>> + >>>>>>>>> + /* Sync-up HVIP.VSSIP bit changes does by Guest */ >>>>>>>>> + hvip = csr_read(CSR_HVIP); >>>>>>>>> + if ( (v->arch.hvip ^ hvip) & BIT(IRQ_VS_SOFT, UL) ) >>>>>>>>> + { >>>>>>>>> + if ( hvip & BIT(IRQ_VS_SOFT, UL) ) >>>>>>>>> + { >>>>>>>>> + if ( !test_and_set_bit(IRQ_VS_SOFT, >>>>>>>>> + &v->arch.irqs_pending_mask) ) >>>>>>>>> + set_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); >>>>>>>>> + } >>>>>>>>> + else >>>>>>>>> + { >>>>>>>>> + if ( !test_and_set_bit(IRQ_VS_SOFT, >>>>>>>>> + &v->arch.irqs_pending_mask) ) >>>>>>>>> + clear_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); >>>>>>>>> + } >>>>>>>>> + } >>>>>>>> I fear I don't understand this at all. Why would the guest having set a >>>>>>>> pending bit not result in the IRQ to be marked pending? >>>>>>> Maybe it is wrong assumption but based on the spec: >>>>>>> Bits sip.SSIP and sie.SSIE are the interrupt-pending and interrupt-enable >>>>>>> bits for supervisor-level software interrupts. If implemented, SSIP is >>>>>>> writable in sip and may also be set to 1 by a platform-specific interrupt >>>>>>> controller. >>>>>>> and: >>>>>>> Interprocessor interrupts are sent to other harts by implementation-specific >>>>>>> means, which will ultimately cause the SSIP bit to be set in the recipient >>>>>>> hart’s sip register. >>>>>>> >>>>>>> Meaning that sending an IPI to self by writing 1 to sip.SSIP is >>>>>>> well-defined. The same should be true of vsip.SSIP while in VS mode. >>>>>> I can't read that out of the text above. To the contrary, "will ultimately cause >>>>>> the SSIP bit to be set" suggests to me that the bit is not to be set by writing >>>>>> the CSR. Things still may work like this for self-IPI, but that wouldn't follow >>>>>> from the quotation above. >>>>> Why not that wouldn't follow from the quotation above? >>>>> >>>>> The first quotation tells that we can do self-IPI so VSSIP.SSIP will set to 1 >>>>> what we could miss SSIP bit if won't explicitly try to read h/w HVIP (or VSSIP, >>>>> or whatever other alias of the SSIP bit) and sync with what we have cached >>>>> in hypervisor. >>>> The bit being writable doesn't imply that it being written with 1 would also >>>> trigger an interruption. If that's indeed the behavior, it surely is being >>>> said elsewhere. >>> According to the spec it will trap to S-mode (VS-mode in our context) if both of >>> the following are true: (a) either the current privilege mode is S and the SIE >>> bit in the sstatus register is set, or the current privilege mode has less >>> privilege than S-mode; and (b) bit i is set in both sip and sie. >> That's still not it. Here is the relevant quote: >> >> "These conditions for an interrupt trap to occur must be evaluated in a bounded >> amount of time from when an interrupt becomes, or ceases to be, pending in sip, >> and must also be evaluated immediately following the execution of an SRET >> instruction or an explicit write to a CSR on which these interrupt trap >> conditions expressly depend (including sip, sie and sstatus)." >> >> Note in particular the "explicit write to a CSR". (Sorry, I did read that before, >> but I didn't memorize it. Else I wouldn't have asked the original question.) > > Guest can do: > csr_write(CSR_SIP, SSIP); > what is an explicit write to a CSR. Or it the quote it means a different CSR? That's what is meant, aiui. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 12:56:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 12:56:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205061.1519514 (Exim 4.92) (envelope-from ) id 1vgMta-0005R4-Pt; Thu, 15 Jan 2026 12:56:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205061.1519514; Thu, 15 Jan 2026 12: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 1vgMta-0005Qx-NF; Thu, 15 Jan 2026 12:56:14 +0000 Received: by outflank-mailman (input) for mailman id 1205061; Thu, 15 Jan 2026 12:56: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 1vgMtZ-0005QC-Ml for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 12:56:13 +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 9173e225-f211-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 13:56:11 +0100 (CET) Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-65089cebdb4so1365090a12.0 for ; Thu, 15 Jan 2026 04:56:11 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b871f50cdc4sm1073599266b.20.2026.01.15.04.56.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Jan 2026 04:56:10 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9173e225-f211-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768481771; x=1769086571; 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=Pfh8ymSKNRwssTu9w7Ic4LfSMxpFQTrPMsHWSNICpiM=; b=iv3dF3ioqCSEDBOG7/1RWTQ1iCYEqdwuuloSz+bHKWY4smVuf5YR3heBY+fuHMErE+ 5t5aZqN9F0Z15kcqiLJuTC03JGjMAkrEOr7TROolBFOk+JyHT1G+4+N10WG7sHpBa0rw 7/xmOXDXAGWDngYWqCA3FBVry7bBbPJ1vdOWvfBht/eLiwVZDAzROmexg8xAhrOH86Ze JKIl9t9fH9ij3M5GBzMeCnjmOtRzdN77asJCku4/ozJgEyyxRJHe1ysSuVixTOUrjG7M k53jwg6rvOy+BhAqB0M1m35Tc03v2UHf+JzA2V+5xXlEPfl+06yRMlzdQwoA7phrkemZ m66Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768481771; x=1769086571; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Pfh8ymSKNRwssTu9w7Ic4LfSMxpFQTrPMsHWSNICpiM=; b=AS+5zBPw7/d4JiBQaizTAO4jyC1wRFb+wesk/pShVMdUYoC1i10vDsrcj95EARPbcU KQpSlbHgEIlEkuDvSophlh5G/0nBbSkqkSgBrdGNXERgv/6bNiHAz/t5hHxA3mgTFnx3 K8NjSaGW3FmdsD5r/0/A+Di9je9Rx8U0nH/igSBJ3hGlrN/C9AMCNcbRRUWP1A5uTpL8 n+WGzDfDKzjX0VEJ3vbTkb2QLZSv9GOQxWhTnCV8jyjRXouxigfvQz3dn630tc6TeEdg jrevEpoSFSMtxZWKzm28dUbtlucSB/A28tSr/uaXHeEqH8gJWKceDPAVB2CCF7izV0oE L0hw== X-Gm-Message-State: AOJu0Yyc0MZJ3joMhmIKi6nnHRORlBZRVizK2kSb9QCBsbx9sWGXB1sk SYI0Q6UuP5v52YODiVgxKvtrutkbc0bFG9bMHyspvdXROIqqyghYb8NhiKRLGw== X-Gm-Gg: AY/fxX4GeOLxlACw1FkGyJT8wFJxlAoD4CYUscHfUupzA/IalopqFbyeGDtbiq73JX6 z7D4NkGE+/bdJLXCzBHhYRx0xxmBNGDht+2dGcI0Z429z4vjlBJFOK5ceVnTiypsQEm8lUoC+pE O7eah4zl3HiSm5spdIcGutDNiMGH/oo7v0sEYehwETTuTvN/AVsYB16YJ4CiDPZWPDsUfsJs0Ld e//9RubLnvsmiiB1bxPTiB6mnuZlEkmiAIWcQnfUNoH0nlWUO9hOroFPccH3+wZGEA0xAHKTatY OAXP4t3qHBB1/6Eyk+5giSxo/hxLR0D+7n/M4G9bcDjfsqFZbHMKmzunVDtFEWbXaBlhooJVmN+ afiuZVrZXtjU6nUWkQFwBK+PGnfFWpTYiw3U0jzlQImJjPTS5xdCgtcfBMcIIp7FD9janqDb7v5 TXdfi5SO76mdvPPekZIil2zNfJgAwIeWvGoKBpXivYZUY85c3VOoy/YA== X-Received: by 2002:a17:907:9629:b0:b74:9833:306c with SMTP id a640c23a62f3a-b876127f271mr494457366b.47.1768481770863; Thu, 15 Jan 2026 04:56:10 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH] xen/riscv: dump CSRs on unexpected traps Date: Thu, 15 Jan 2026 13:56:01 +0100 Message-ID: <20260115125601.70834-1-oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Provide more context on the exception state when an unexpected exception occurs by dumping various Supervisor, Virtual Supervisor and Hypervisor CSRs. Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/traps.c | 55 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c index e9c967786312..d6c92588ea47 100644 --- a/xen/arch/riscv/traps.c +++ b/xen/arch/riscv/traps.c @@ -17,6 +17,10 @@ #include #include +#define print_csr(csr) do { \ + printk("\t" #csr ": %#02lx\n", csr_read(csr)); \ +} while ( 0 ) + /* * Initialize the trap handling. * @@ -99,12 +103,63 @@ static const char *decode_cause(unsigned long cause) return decode_trap_cause(cause); } +static void dump_csrs(unsigned long cause) +{ + unsigned long hstatus; + bool gva; + + printk("\nDumping CSRs...\n"); + + printk("Supervisor CSRs\n"); + print_csr(CSR_STVEC); + print_csr(CSR_SATP); + print_csr(CSR_SEPC); + + hstatus = csr_read(CSR_HSTATUS); + gva = !!(hstatus & HSTATUS_GVA); + + printk("\tCSR_STVAL: %#02lx%s\n", csr_read(CSR_STVAL), + gva ? ", (guest virtual address)" : ""); + + printk("\tCSR_SCAUSE: %#02lx\n", cause); + printk("\t\tDescription: %s\n", decode_cause(cause)); + print_csr(CSR_SSTATUS); + + printk("\nVirtual Supervisor CSRs\n"); + print_csr(CSR_VSTVEC); + print_csr(CSR_VSATP); + print_csr(CSR_VSEPC); + print_csr(CSR_VSTVAL); + cause = csr_read(CSR_VSCAUSE); + printk("\tCSR_VSCAUSE: %#02lx\n", cause); + printk("\t\tDescription: %s\n", decode_cause(cause)); + print_csr(CSR_VSSTATUS); + + printk("\nHypervisor CSRs\n"); + + print_csr(CSR_HSTATUS); + printk("\t\thstatus.VTSR=%d\n", !!(hstatus & HSTATUS_VTSR)); + printk("\t\thstatus.VTVM=%d\n", !!(hstatus & HSTATUS_VTVM)); + printk("\t\thstatus.HU=%d\n", !!(hstatus & HSTATUS_HU)); + printk("\t\thstatus.SPVP=%d\n", !!(hstatus & HSTATUS_SPVP)); + printk("\t\thstatus.SPV=%d\n", !!(hstatus & HSTATUS_SPV)); + printk("\t\thstatus.GVA=%d\n", !!(hstatus & HSTATUS_GVA)); + print_csr(CSR_HGATP); + print_csr(CSR_HTVAL); + print_csr(CSR_HTINST); + print_csr(CSR_HEDELEG); + print_csr(CSR_HIDELEG); + print_csr(CSR_HSTATEEN0); +} + static void do_unexpected_trap(const struct cpu_user_regs *regs) { unsigned long cause = csr_read(CSR_SCAUSE); printk("Unhandled exception: %s\n", decode_cause(cause)); + dump_csrs(cause); + die(); } -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 15 13:06:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 13:06:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205081.1519525 (Exim 4.92) (envelope-from ) id 1vgN2u-0007Ct-Ka; Thu, 15 Jan 2026 13:05:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205081.1519525; Thu, 15 Jan 2026 13:05: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 1vgN2u-0007Cm-Gn; Thu, 15 Jan 2026 13:05:52 +0000 Received: by outflank-mailman (input) for mailman id 1205081; Thu, 15 Jan 2026 13:05: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 1vgN2t-0007Cg-39 for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 13:05:51 +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 e975e7bd-f212-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 14:05:50 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by LV3PR03MB7777.namprd03.prod.outlook.com (2603:10b6:408:28c::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.6; Thu, 15 Jan 2026 13:05:46 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Thu, 15 Jan 2026 13:05:46 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e975e7bd-f212-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=eO7NRBuk9Qevn/5dSw+Dnxw6pzaOdUvuTtgtKDff7xxZm2tgNu7+WrXXdnmAKZb9NnQxzXkTw2MyKd2NmJB3cgnwtH5WNMy0rcuN1+i8oTfLh3devEOo4SsR3TX7U3T+6zWZTIX2yJZc2+tgz/U7sv4AgrgrpZ8L5nbUXzyTTDCh2rJBOwNQVWgKyQnXgcSjL2wMZKMaO4HiNRRPUNjnR0JeRRYRtaT0O/6TFU0Qw+5uuG18IV9z5OqSQ359ODh46QV7rUVKdqMvgjtgp01r3UtaWh6YTs0yrkoOgvnJSixHYJAW5gSAH+rJ1aFStzywDTqmmqM58/D6M87Gq1nrxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lpV821/MNKcxrhFf1YrO3uDU67SP6H8I+lFrszztmZY=; b=KhiJzMuU48OPIpQCcvfOnWi85e8mf4oDlcsMQynkihu9+bIG6R304K9Qb1NaY4yzMDb9xkQAlOiSMmLcA7I8LYSSLvuyA2AhTfZMAdkjBCpkTQ7v7t6kexJEoC5EI+GHC2NNnclBm1B0+YHv7dHwxPMj1ShGP948WOrWXUjcTlLi9Q18FfX5/ZS0tEoO0pofXmpNj+6Fs+aAZfi07Ulk+qoXwu3O2+BfzV7HaGyToIE8w73h59crfTajYTByDPp0Si8PZObR0Xz2LakoQ90MlwHrYkTBlbAd+oWT3STWmnVGd5iIi86p+eLC2z+xi7tttaQazZc4+nChPNS1Nhp3Vw== 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=lpV821/MNKcxrhFf1YrO3uDU67SP6H8I+lFrszztmZY=; b=MjDLN+VlPqccfwkPkTTU0kMdB9V2Dt5595H59YbXzMLTPAmE67vgdGLXl6LKm03lMvjl0+iNZklqNR9TfKbI3ptTIJ5MwcahnoCtw3qXUdVnjgtH75zU7bEnbS/nFv60FHYahyl4Wgfd3hCIeO8rFjlO9DNvssItD1YB/iCeJUI= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 15 Jan 2026 14:05:42 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH 2/2] xen/mm: limit non-scrubbed allocations to a specific order Message-ID: References: <20260108175536.82153-1-roger.pau@citrix.com> <20260108175536.82153-3-roger.pau@citrix.com> <14560e88-bbd5-48e1-848e-e53a3237d16b@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <14560e88-bbd5-48e1-848e-e53a3237d16b@suse.com> X-ClientProxiedBy: PAZP264CA0080.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:1fa::11) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|LV3PR03MB7777:EE_ X-MS-Office365-Filtering-Correlation-Id: 7619dd5c-834e-48bf-8d83-08de5436cbf9 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?RjdMcDllZWh1MDltdFphQzhTdzRTRVFuajR3U2hOcGlUMlk3ek5rbXJRQXZI?= =?utf-8?B?Ykg5Y0loWWZrN0FLOUE5SFF4UmtKUTZibE95c3JZOHo5c3JmdVBxSUM4S3ZC?= =?utf-8?B?U2FnVmpiT2NPMjNFMVBWSkdiL0xsQ2lVVXVNMmVtQUVLdHYxSC80eit3MGUv?= =?utf-8?B?b0xvS2FpVGNQOWJxRDZkcnk0R0pGQUVFbVA1K0VvWm52Z1JzcitBdDh0aFZI?= =?utf-8?B?RVNyRnl3VjRTRVZRcXFnckRyVDNoSlZFQVhWd0pLT0VjdDY4ZXZHak5aZEIz?= =?utf-8?B?bFJDN3NoWERUZWlCZDlGWE9LSEUvdmxrSW9aSmxZVnphYUZDQXNlb29MYUtI?= =?utf-8?B?aWxRaFRFZGZDYi9zQzFnT3hGdDBxZUcrTFU4ZTF1ZlJIdGlJa0VhWXg5emQx?= =?utf-8?B?MkRYZWxiWFIvZE9YMTFzQlhUZDJzaGtUVTNUM3VaanBDWnpQY1dIeVU0Rytp?= =?utf-8?B?cjNIaWtjckM0QUdzbXl6TG5Yc1JPalRCVmFzMmFTQTJTcTRLeWpYL2xYSkVF?= =?utf-8?B?NSsxVGNscnordVNRa2FyN0RFRTVkSTJGbkMxTTQzQzVEK2lXY011cEhPM296?= =?utf-8?B?R2ZENTZxeWZpR1hNR2Z1ZlBWMTB3d0Z1RHZhQXRCbEIwOW1lSllNblI5ZW4w?= =?utf-8?B?MHNJVVZqT2hScEtNSXUrNXZCcDcyckZTK0M3R3hNWkJWYzI1Q1E2WU5YUEhm?= =?utf-8?B?SUI3QUk0RlZoZExtZXNhVXBqUUlTNWNWZG5KdjdwcWNtQjEvUGNiN2o1ZVVT?= =?utf-8?B?Qm9ieHVtTHlaemJPUGhwL3BMcUJyaXM1UTlUUkpQS09WNDFxSGdwQWdhM294?= =?utf-8?B?NVhYVUVRM2NrSGxqR3B3eVIyT3Z4aDNWSHJwM3R3WDR5Mm1tZEwxenVvMVM1?= =?utf-8?B?cXgrT1BzT3lIN2FnQzdRUGl2YjRVWURxMjRSL2hHNkdFR0hST1ozYXQ1OFp3?= =?utf-8?B?OVM5OXc3WlA5MUhPNUxrOWhUajJFTys5ZFByU0hTMlFxM3VNN3NXdGQ2Smdn?= =?utf-8?B?bi9raVhNVWFnZEtlN25pV3J0MzdYbVkvZWR6S1oyVThPaFhVUmlVc3dDM3V5?= =?utf-8?B?NVN2Wjl0ZC9nWEU5T0pNdTAyTWxOdy95dXlsRmZqNnpvekhpdzRHU3lzZ0hw?= =?utf-8?B?NlBvU3RFWTBDZWhLQWR6WjNkVmYwTEI4U21na3RZRjJrN0hlSWlWaWVDVkhk?= =?utf-8?B?Um1TSFBYK245bjJ1elJWU0crODlEWFRKQUZZKzY3S2VQOGhTeFd2cDJ0a0sr?= =?utf-8?B?RUxGYlIvUTY1Sk1IeHVnN3A0ajFmZGV6NmFxQ3VHYVhYQ3hGT0JDYXdSSnBp?= =?utf-8?B?bkJRay9BTEFpeGxELzFweUVQK3hVeGEvb0M3Ty9XK3lxRGJ0NktkTlJBeDJw?= =?utf-8?B?aFNzUDFjSURHU3BjSEtTL3I2R1VCcGc5N1ExTWxaQjY3SWNnb0w5bEIzdVQ4?= =?utf-8?B?bmtwdzZvVEhVcjBnZzZHZktERU45OEVDLzg1TVlsN1V5d0phTkw5L3ZVSUE5?= =?utf-8?B?bHdlZjdJOVFXOGtqeW1pZ0Zvajk2WjVvVlJlU1g5R0Z4V3IrWGdRdVNISWRI?= =?utf-8?B?d1VoM2dCbU4vOGRTUFc1T1ZPRk1vYkorZDBOb3luNi9NQmoyLzF6YkxYWmlP?= =?utf-8?B?eU0rVzRJL25peEdVRUYveHZlNlU1cWQySUxyNDNTQ1BkRm0yVzZZVGYvMnVo?= =?utf-8?B?aWlwenNnTjlidGljVjhkT1FsZXF3dWk0ZnZDUTIrR1lOb3RUVGhqNHFXNVoz?= =?utf-8?B?RlVqQVJIdTJlMkhxaVA2Z2IwQTFZYzFOYmk0R1ducWVuM0hlUE41LzFIOC8w?= =?utf-8?B?Z3NTbHM3a0J2OWQvRVR2Q3NPbVp2REN2TGFKZnFVeWRIMzBrdklma3U1dUpt?= =?utf-8?B?cmFTZ2hDRWZYdk1OK1VWZVpMRHB5c2ZyNHAvdHhraXZGc0VZV09LVWV6MHFw?= =?utf-8?B?T0hyU3R3d2h4ZnIraFNtOWNQN3hWQ0JRbk5qcDByL2pZTEh2S0dYd2hNbFhw?= =?utf-8?B?MmtwcFRieHZHQnZWVVhjL3VpanpNWjhNWTRHVjlycDVFeVdhUXlwbExQaWpC?= =?utf-8?B?Wisyb1hLNVBEOEVXbldJNUZtWU54WlNhaTVUNmVzQTJnNWRUYVppdHJjOGU4?= =?utf-8?Q?AwNM=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?STdRdTB1djJUOFhIV3g3NTNhdUJWVVNHRHhJdldGdWZlUzlrRlF5TGdGWmpX?= =?utf-8?B?UEMxUWlHTHo3T2xya2w0cW1LNzZYYmdwRUZXRUowa2hJNEs4U2RUaVlscnU1?= =?utf-8?B?am5xOHZPWnhlbkVhOHovcDRQdVhhK1VFZG4zT0tRYTNJQ3FNdmtIcUQ3TXIw?= =?utf-8?B?TE41QjE3Wm5XTi9Zd2E3TU9xeTZtaWFpS0Y2QWZiWUhMT3F1VXBjUXBrOTc0?= =?utf-8?B?a2FoVEt4MkJITGQ2aHlTREtrNm93azFDYWo2MlB1ZHFuQzU5RXIvYllwT0l2?= =?utf-8?B?a21YZjhZMU04QURtUHZjc0ZIOHgyOE93RVZDMzBScGxidHpScFVzQ2lIdUdz?= =?utf-8?B?WGtNK1RickxMV2UxZUZZZWp1aEZyYlVJSmJPaDVpZVFYSFJ2bGV6VitsNHlO?= =?utf-8?B?M3BiUzVhRjBFRys5bkZVS0tGSVNyT0pUS3VHcG5MUDlKNnJJbHYrbllTRFhF?= =?utf-8?B?YUlzWW9ZcTY1cWRaZFlpeEdUcFJzR3o1MTNoWnhGOEwyaGw1NkJ0V25sazc5?= =?utf-8?B?THZ0dElCUlVEWlNyaHN1d3RaNHVDUDl4UjIrUFYvNUlvMXNmRjRSNkpBVGEw?= =?utf-8?B?b3hGRXB4T0E1Y3RTM3F1RzZkaFBjTUlxa0h1L3liRWlJOWRzb3U4YmgvYWFn?= =?utf-8?B?OUcwM3RoU1crTE51bGszVm01NEtyWTR5cUI5L3BMNklSL0h1dkdGYk8vY2Uz?= =?utf-8?B?YnBCMVVSd0NhUzlIWTFpWmNVK1VqN1VuRXZjb2Y5UUpMOGRGQmxYNmQ5T1pj?= =?utf-8?B?WnNzUUVJb01TRm5ERyt0QzB0bXBNejdXMTlZUlYzUkVvYWFOZ1c3QzRtSXhX?= =?utf-8?B?KzNuVWpIMnVKaHF1RGsxQ0tqNjl5RWpWY3hpa0dxWjZpenQzRkk2VFhQTGxP?= =?utf-8?B?VFppcmxZVHRIMHdwaXlYbzlUQ21mUWhLKzU0cEVaN3pUVG9kcStJbjhKWi90?= =?utf-8?B?M3VwbGlFRGFXZ1ExQ3A0dWNkdUMycUpuU0pCZnUvV1orQnhjM21ueWJFR1ZX?= =?utf-8?B?bG5TWnRVRE1sd1BJL1hUYjA0SkpyTzVDdjJPK0RFZHlkUlNQbDFtZGg0akpH?= =?utf-8?B?b3h0VnhBY1lSYTBMUWJDZjM0L1czYXhXMTNIaDlZQ0lkbzJqcDc1Tm4xNyt0?= =?utf-8?B?VnluNy9kaFdTMFRCTE83b1lDbmpFWUkxejhidEQ2c0NCRWI2eXViRVZwUk1N?= =?utf-8?B?RzUrcHJrcTJuek1xTGlKK1c5QkhKeC8vbE1TV2g4ZlJsV1IzOC9iMU1WU2JD?= =?utf-8?B?dXJYNmUrYXd5M3BOQUFtdTVITE9GcHVvNlJpbTMrYjUrTUFFSkNkWWRkYTJu?= =?utf-8?B?MVVtR2VFeE82ci9NaFFQZlkrZUFNWUhkMnhVYWJPYk5BZVdNNDY2VGwraUUw?= =?utf-8?B?QW5Jako3NUJ5bklCNkxiNW92cDlXaTFEaVBoVWJ0em9Ob3B4aHJmeTlIeU1p?= =?utf-8?B?bjZJQ2hhZ2pyUnNTb1phQlM0RHNHTU1ldkE5WFpFMHlIRm5wclRkcGNvWU5z?= =?utf-8?B?WFpVSjhZT00xdWVmYjJ3VWNOVXdPS29LeWdjdk93aE5NSkF4cy9YWEtUSTcw?= =?utf-8?B?NnBXcUJUWnBDZFh6b3JMNDc1dzJYM1JTY3pibk9yTWpqL1FtcVM3bmkrT1Jr?= =?utf-8?B?VE9XYjM2NEkydUpFc2J5OEl2KzRlVmQ5alN5bmUwelF1RDNwWjg2ZFM2SjJW?= =?utf-8?B?OGJYdVd2aTBReG5ESEx2YSs1MlJyWVpjN25nSjFTS2M2VzFuVHhMejJXK1VS?= =?utf-8?B?SWpmUFhqL244YmdnalErQmNrWkNoZk42SGFkS2MySmZSSWRJRkRDWS8yYnhn?= =?utf-8?B?NUsvNjB3YmlGR1IvWHhBUzNsMTdoWHZiSUhvV0xZOVRGYmF5c1A0ZUg3YXNO?= =?utf-8?B?U0VxUmVBYWtoc3BCNTBubUpjN2RLMmMwSkVkTGRSNktkS2NLZ2FLRjBRM2FB?= =?utf-8?B?dk5PUGh3Z2h0TDZBeVFualpqVGhxQlB5VHJOYTVmWm1CMW44R0pMM2s1a2xT?= =?utf-8?B?Q0dCV2IzaS9XSkNKeE5leVhXMnl2c2NRSFNJUWQrbXIxckY3dlZEN0VLY0FN?= =?utf-8?B?UllDOFErdm5PaTlUNmJ4NTZ0OEZkcytnM21UdWZYVGZaWFlLSURVUnlLOTJQ?= =?utf-8?B?TWxZcU5RditVTzdRMURBL1Vyc1pKTkUxdkVBY1VSWGZsZVdaNlF1OUQvNjh3?= =?utf-8?B?Q1JSRVNhUHF6VCtFWmdPMk1WRGhST3pUUjVMVGdraGdiS2p3R29Tb3Q4N3JO?= =?utf-8?B?YytpRFkxamZrQ25ka2FqQzhyYjdXSm44aG4xazQ0VnhqeFZIQU41bDl3NFZZ?= =?utf-8?B?ZldlN1dubEE2WitLemkyTVZEYzVVYmZxb3R3MzE4Y2w5SGZhZUV6Zz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7619dd5c-834e-48bf-8d83-08de5436cbf9 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 13:05:46.2869 (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: 7Cwpg4j1qxtuvC3lZN6XskPuhKZSP3d82xlFojfxYz26QlwC5KH8IpeATsBTz8q3SE3eudO01yFU0a/Y+pf7lQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7777 On Thu, Jan 15, 2026 at 11:56:16AM +0100, Jan Beulich wrote: > On 15.01.2026 11:48, Roger Pau Monné wrote: > > On Wed, Jan 14, 2026 at 09:48:59AM +0100, Jan Beulich wrote: > >> On 13.01.2026 15:01, Roger Pau Monné wrote: > >>> On Fri, Jan 09, 2026 at 12:19:26PM +0100, Jan Beulich wrote: > >>>> On 08.01.2026 18:55, Roger Pau Monne wrote: > >>>>> --- a/xen/common/memory.c > >>>>> +++ b/xen/common/memory.c > >>>>> @@ -279,6 +279,18 @@ static void populate_physmap(struct memop_args *a) > >>>>> > >>>>> if ( unlikely(!page) ) > >>>>> { > >>>>> + nodeid_t node = MEMF_get_node(a->memflags); > >>>>> + > >>>>> + if ( memory_scrub_pending(node) || > >>>>> + (node != NUMA_NO_NODE && > >>>>> + !(a->memflags & MEMF_exact_node) && > >>>>> + memory_scrub_pending(node = NUMA_NO_NODE)) ) > >>>>> + { > >>>>> + scrub_free_pages(node); > >>>>> + a->preempted = 1; > >>>>> + goto out; > >>>>> + } > >>>> > >>>> At least for order 0 requests there's no point in trying this. With the > >>>> current logic, actually for orders up to MAX_DIRTY_ORDER. > >>> > >>> Yes, otherwise we might force the CPU to do some scrubbing work when > >>> it won't satisfy it's allocation request anyway. > >>> > >>>> Further, from a general interface perspective, wouldn't we need to do the > >>>> same for at least XENMEM_increase_reservation? > >>> > >>> Possibly yes. TBH I would also be fine with strictly limiting > >>> XENMEM_increase_reservation to 2M order extents, even for the control > >>> domain. The physmap population is the only that actually requires > >>> bigger extents. > >> > >> Hmm, that's an option, yes, but an ABI-changing one. > > > > I don't think it changes the ABI: Xen has always reserved the right to > > block high order allocations. See for example how max_order() has > > different limits depending on the domain permissions, and I would not > > consider those limits part of the ABI, they can be changed from the > > command line. > > When the limits were introduced, we were aware this is an ABI change, albeit > a necessary one. You have a point however as to the command line control that > there now is. In addition to what I've said above: the limit that I've introduced in v2 only affects dirty allocations that require scrubbing. If the requested order is available and scrubbed the limit won't be enforced. So the ABI is not changed in that regard, only unscrubbed pages past a certain order are considered as not free. It's possibly best to move the conversation to the v2 proposal and discuss the limit there. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 15 13:12:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 13:12:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205100.1519552 (Exim 4.92) (envelope-from ) id 1vgN9C-0000eG-J5; Thu, 15 Jan 2026 13:12:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205100.1519552; Thu, 15 Jan 2026 13:12:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgN9C-0000e9-FA; Thu, 15 Jan 2026 13:12:22 +0000 Received: by outflank-mailman (input) for mailman id 1205100; Thu, 15 Jan 2026 13:12: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 1vgN9B-0000e3-Gm for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 13:12:21 +0000 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [2a00:1450:4864:20::42f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d13f7710-f213-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 14:12:17 +0100 (CET) Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-430f5ecaa08so461571f8f.3 for ; Thu, 15 Jan 2026 05:12:17 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af6d909fsm5979825f8f.31.2026.01.15.05.12.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 05:12:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d13f7710-f213-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768482737; x=1769087537; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=LFm/I4196HgVQNwV0YmL4WM1x1A8fO4rt2IHhLxqcjs=; b=LuJ877eQHKGAmPR6+lNXH697xYSUMmSAM6gprkotfYAq+bKA245KAPoN/O+RpHko0w TO4OtRVozJIcAJ3FJoRmujS0Ymhpp9XnsbT89pDzYUlbm6Rpmd8j/3N/+AGtTpy+gRK1 fbNUPJmQpw8k9/5NaFR8dcU8skGapx+N2TOcefdH3X8RVgC/MFKaQj5zUsU03EFysM+h /jfenxVGfivdA0sucur7RVnTHXg3iJrAy4/+GPrkVOULHfBMNSBIu1pxX25qmt6JdGWA wv/+1HU2MdH8Ukzx712dU39lrFD7Va8yfqQ5NOKzFetkJscWNVeLGTSpgpPmqluwZSb3 W97w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768482737; x=1769087537; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=LFm/I4196HgVQNwV0YmL4WM1x1A8fO4rt2IHhLxqcjs=; b=oXIukQnVWj+Uyagzewsr7J8jA44GEjGk2/uQTeOWj9kPpTY63j2bRr/m2LCweLjIZQ tE1m2cS4db52PsXBG6rVkjPxxQczvTaZif78NRp9HaGt5yUdQXio3o/J8taUtJpWPbsR PcLwQRuazsxsdFD+ORYGtC6YZFRovm523S4VMKGjYxBEnEDmP26nNBTsby7jjb1j3TmM H77tKc4Mvnz3jnFUA5T+9xR8t+TbqyUFJ4iAXM/5LGFPL1hMwQo9DTd/AW7p0MWIOe0S k6qdrCZk9RxKYXcdUpIpqB/rEg7wAsxDgbLZemM6Y0t5c/jLJz6pzHlJuOWu+c4TttPr 8BDQ== X-Forwarded-Encrypted: i=1; AJvYcCU22nWZntnkQkRwnCfczQ1Rt4dqs30r6uVH//04giKjeyQ6ZTkVJjc7nk5tbuB3eSJVGZ2ma5XtNIw=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxc6z0xDYE9i4lbjfcCUTJp5mwrKl1MEbngyBRfyvSg0Phq6Uak 9/FYqBcnKGsT64S759pK0egeh8qEwvwffBJHSB9QkXRpxIy9sf54wfpDYllEQhsHyQ== X-Gm-Gg: AY/fxX6uXV0MEEXdnmjJg2vVfOvir+oYmXvB1SMeXRqC8a+wSB5VWEv/uMqhclzsPiN YSfMYXelvGz3lEIAH88KU62XoiuFTwDN7z3JwkBEuoqoVTbNeC8xRyqeYBfYKGboFFJ0Y422H9U G7ydqHf4aogvsm63tRUbPMGCdV115VgeoXW6pa+4ZM1lVkr6FGszZW06CoF3QUzxTh/Ty6LkrXz 3mW2TyY35SAKdD9/eDTMwkWt0RV0CVuzeq034THLEjOeB6t2APyHFyiM9QBbLAJWyK8safkVqj0 p2Z98e01nNUMhsEVMXZBcn9O3adp7QT/bxp4/ZWk9UbonmSYm9nW1UUNj8d2tJzP2hnGPsbIL9V lC7mo9Tdisvd1bJJP5XaOtECPhRFuoC4i8IBRsFi0LzkRXqPFqtSUyly4LfSXj3rxyyWgcS5+mi C00nNEiGYo81WJPWAKD2lDKYpPZsT276FWnVcw8NyIC0SO7/kzvob9aAojgj/Q1PRIbAKS07jq0 co= X-Received: by 2002:a5d:6d46:0:b0:430:fced:902 with SMTP id ffacd0b85a97d-4342c5039d8mr6429935f8f.26.1768482737282; Thu, 15 Jan 2026 05:12:17 -0800 (PST) Message-ID: <8377bdc2-d92d-4c3f-893b-19c842cad3a7@suse.com> Date: Thu, 15 Jan 2026 14:12:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/riscv: dump CSRs on unexpected traps To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260115125601.70834-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: <20260115125601.70834-1-oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 15.01.2026 13:56, Oleksii Kurochko wrote: > --- a/xen/arch/riscv/traps.c > +++ b/xen/arch/riscv/traps.c > @@ -17,6 +17,10 @@ > #include > #include > > +#define print_csr(csr) do { \ > + printk("\t" #csr ": %#02lx\n", csr_read(csr)); \ Why the 02 in the format? If you wanted to align things, you'd use %016lx. (I also don't think the 0x prefixes are overly useful in such dumping, but others may disagree.) As an aside, the width of 2 would be fully consumed by your use of #, except for zero which would (oddly) be printed as 00 afaict. > +} while ( 0 ) Why the do/while wrapping, btw? > @@ -99,12 +103,63 @@ static const char *decode_cause(unsigned long cause) > return decode_trap_cause(cause); > } > > +static void dump_csrs(unsigned long cause) > +{ > + unsigned long hstatus; > + bool gva; > + > + printk("\nDumping CSRs...\n"); > + > + printk("Supervisor CSRs\n"); > + print_csr(CSR_STVEC); > + print_csr(CSR_SATP); > + print_csr(CSR_SEPC); > + > + hstatus = csr_read(CSR_HSTATUS); > + gva = !!(hstatus & HSTATUS_GVA); No need for !! when the lhs type is bool. Question is whether gva is useful to have as a local in the first place, when ... > + printk("\tCSR_STVAL: %#02lx%s\n", csr_read(CSR_STVAL), > + gva ? ", (guest virtual address)" : ""); ... this it's sole use (you don't use where you could further down). > + printk("\tCSR_SCAUSE: %#02lx\n", cause); > + printk("\t\tDescription: %s\n", decode_cause(cause)); > + print_csr(CSR_SSTATUS); > + > + printk("\nVirtual Supervisor CSRs\n"); > + print_csr(CSR_VSTVEC); > + print_csr(CSR_VSATP); > + print_csr(CSR_VSEPC); > + print_csr(CSR_VSTVAL); > + cause = csr_read(CSR_VSCAUSE); > + printk("\tCSR_VSCAUSE: %#02lx\n", cause); > + printk("\t\tDescription: %s\n", decode_cause(cause)); > + print_csr(CSR_VSSTATUS); Everything below I understand wants dumping, but for much of the above that's less clear to me. Why would guest's values be relevant when we have a hypervisor problem? > + printk("\nHypervisor CSRs\n"); > + > + print_csr(CSR_HSTATUS); Above you special-case VSCAUSE, but here you re-read HSTATUS. > + printk("\t\thstatus.VTSR=%d\n", !!(hstatus & HSTATUS_VTSR)); > + printk("\t\thstatus.VTVM=%d\n", !!(hstatus & HSTATUS_VTVM)); > + printk("\t\thstatus.HU=%d\n", !!(hstatus & HSTATUS_HU)); > + printk("\t\thstatus.SPVP=%d\n", !!(hstatus & HSTATUS_SPVP)); > + printk("\t\thstatus.SPV=%d\n", !!(hstatus & HSTATUS_SPV)); > + printk("\t\thstatus.GVA=%d\n", !!(hstatus & HSTATUS_GVA)); Might these better be put on a single line, e.g. in the form [VTSR SPVP SPV] i.e. enumerating the (interesting) set bits textually? > + print_csr(CSR_HGATP); > + print_csr(CSR_HTVAL); > + print_csr(CSR_HTINST); > + print_csr(CSR_HEDELEG); > + print_csr(CSR_HIDELEG); > + print_csr(CSR_HSTATEEN0); > +} > + > static void do_unexpected_trap(const struct cpu_user_regs *regs) > { > unsigned long cause = csr_read(CSR_SCAUSE); > > printk("Unhandled exception: %s\n", decode_cause(cause)); > > + dump_csrs(cause); > + > die(); > } Apart from CSRs, how about also dumping GPRs? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 14:04:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 14:04:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205161.1519562 (Exim 4.92) (envelope-from ) id 1vgNxn-00070F-71; Thu, 15 Jan 2026 14:04:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205161.1519562; Thu, 15 Jan 2026 14:04:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgNxn-000708-3F; Thu, 15 Jan 2026 14:04:39 +0000 Received: by outflank-mailman (input) for mailman id 1205161; Thu, 15 Jan 2026 14:04:38 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgNxm-000702-1g for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 14:04:38 +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 1ff49d6d-f21b-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 15:04:36 +0100 (CET) Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by AM4PR03MB11129.eurprd03.prod.outlook.com (2603:10a6:20b:6cd::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.5; Thu, 15 Jan 2026 14:04: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.9499.005; Thu, 15 Jan 2026 14:04:31 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1ff49d6d-f21b-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=V6KPTtrJoENOBo9Rr8ryteYYvtvjPYCi1wkTcGrpBTi5Nn5kFJgd1SnrlNviAESJDAWdrMtDrsva888Joc4a2oK8NXQIl3mlIZyzVN8r9WQitLG0DwyxW+ZDameL/NzPbBMK1JPVH8vS9QMB0lYkBO5vUWx0Gxh7UU3fx5GZdRJpP/kqykrReOnBGT961Zdi6ASLV5g1qN4sqF8nvAjL9V3X9hA0dRnROWw36iSzmMPlodCpHDmw0poHp/ChqOdFI3R7On5gpdm9MGde6tCpCPSowIzBjShdMI38sVH71AKlnSnSmoWno9Kd6xObsynuR+pgSWSpAPCkpK6MhN6uMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LUryxahDtJTk/fDntRR+sditQ0dn1x83U5LY3cQKckQ=; b=e+Zp8kRIAhjfnA9mK/EgCJ2LQgVhN3NkKlqL1dr6JLRw9jJZkJTNv/VE/xsTk/gJUzy9Jyid924WJBiSdAT8Mrghj13rz+IVc/5/vRB5weYm3eGUNR3IA5651P2a7f7zSgGWdoDyJsn1ZpHVlgAq8qlhIMw3HJ3af72QIWbT753+RTReCLlrbsT7cQ0k275hHxd7853YxCqMx5pIYNg93OPgMCtMY91+ib3p357M/ZDRKA6gDMNSGFt+CP88hpa5sznuoWcmtBarRzbVMiFMQoIdohEuwJCh/1Iv4qrBJyOJ1xu/hvSukh7ZjsY3c/alOixcK1E5ywWRu9GLIj96GA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LUryxahDtJTk/fDntRR+sditQ0dn1x83U5LY3cQKckQ=; b=ldBBDhmmdXONcrBdgD/nm03Acaalyjsq1sphay2KZcNVm/wi63/VNQyxniYADijNly1JZ/3b6lpKgOcNud/JSQN4KYlzPrhKKKaqhfz74WKw3il6qRyIoBCF8QFvyXar34VYm+Z6m9AB3xV+0o14fGLq/8Fv1pvLLd+or3q+YV/GwvO5z6DbUZbJqMCfCQwwJ7ZNyYGAoKtdOT1XCFCYMD5xI/k0qpRmpZJqRAySL2TWrVxLSPpuj9BMLW2INYwX3QfYQhbIHFUIDnBprHblZD49Cmcgo0HxtoFQkaeU2uw1kJkHWjd4MfI6aFPSyh4KMy6KIelZXjOY4mBGp/sb0Q== From: Mykyta Poturai To: "penny.zheng@arm.com" , "luca.fancellu@arm.com" CC: "xen-devel@lists.xenproject.org" Subject: GICv4.1 support patches Thread-Topic: GICv4.1 support patches Thread-Index: AQHchifeIJuTyIWpjU+OJLTHHxG0NQ== Date: Thu, 15 Jan 2026 14:04:31 +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_|AM4PR03MB11129:EE_ x-ms-office365-filtering-correlation-id: f2e50d1a-d924-4785-b3ca-08de543f0187 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?ZERIMWNveUVxbXhGM0FYbUJpbjliZ0Q0VDd3QUkyZmk5ZndvYnk2TlljR2U5?= =?utf-8?B?amJ1cUJQVCtOK0ZjTVh2b0Y5V2pINHp2OTljc3VvWjVBbWc2THdYVGhvbndj?= =?utf-8?B?YXFhTUh0Ym0rMmVrdlR1dWpxZkJWeXFwRWNUOWZXRVVlWVdETkZCN3daQ1VY?= =?utf-8?B?WGkxVHAyOVJ5S1lOTG1oK2lTTE5JNU1KbWdWNjlMaWI5b0RmekR6aE5KMVVU?= =?utf-8?B?M2JiSzJrSWNrTFBDenVLTWIzbnlLTWZCNDhqeGdWTjF2YkdrazRhaWgrNVhx?= =?utf-8?B?MmRnNEdXSVZwL2RaQ1JWV0t4RVhYb2h4cVR6SHRvUHdkallvOEdKNzgyU2FQ?= =?utf-8?B?bVFoOFZDVStEWVBnSXBJTnUzdDNMcnh5Q0xkVFhrTGdJZTVoNWxQc3lqL3Rz?= =?utf-8?B?ZlczWUMzSWt0Ulc1VnJkcUVtMytoWUJKK0djMlpuRGJ2NEd6bnMrQ09VODFo?= =?utf-8?B?MkRVcWZIS3k4RDl3UlhmTnF1ODZXeVJKandoaHk1TTJzTVNhaitzcTFOOXRq?= =?utf-8?B?Q1VFSDJOMjVCMnFUTG9CWE8yMzZ1YUFyU2p4eXBvejJDRU9WVmc5UTRLOXZn?= =?utf-8?B?amRCNzhPVEZnaDRQazZhS0FnWTlBRFp4RFJMSWRVYzJ2YmtlUFBod3VsRVJ6?= =?utf-8?B?ajc0YktsQTBvTDVmWS9sdXBQN2lVN2Q0bUhBNkdib1EwVFM1cXBRQTVQaUxC?= =?utf-8?B?UmJLT1ZkUnFnakt6SitWWVZDZHV6dG9KVXpPSnp5aENYbEl6Tk50WU0xTjY5?= =?utf-8?B?MmR5ZVU3Mllnbm5HL29mTHIzSitYa2UzRkd1WHZiRlZSSXdOaDY1bUgyRkxX?= =?utf-8?B?dXpUQVFLOTlWcXdFbmRTbkJMT1g0bXBUVHpTbVVFL0dOTUFRNk5RMHM0L0FN?= =?utf-8?B?UTZySXR6alhpcXVEc3FaQnVsMlJPRFRaUFdoWi9nSzhYa2JhaitPeEJIUDkr?= =?utf-8?B?NEJYcTh1akY2bEIwbXhWeTVtN1E5VEJLNGl0YnhvQ0h1UzNtN1lGb0hXTnln?= =?utf-8?B?cWhRdW5tbUo2UXJPbnA3c056L1p1dWIvbzlyRVpuWjV1SldNbmVFUk9BV3lK?= =?utf-8?B?ZU9xVVI4UFo4UEc4MmpvSjFiQlhyTS9HeDlpMEw4YWYwc25Kb1ZmNXlXNlNp?= =?utf-8?B?TStzNlUrTThZRk1Ed3lFS2tyZkhyRnptTE54RVdCWXhOM3J6dHBMdHl1Mnd3?= =?utf-8?B?dEhiNHFhTjgyWW9DUjMrMXAyWWQ5Q29DZjNVQ2tzcFVvd0NFLy9EcyszaEtV?= =?utf-8?B?c1JLLzJlcjdsV1JtZUhkajErcDN6VFpRcERBbUtmRDl6VHFSeFNFQmMvRWJZ?= =?utf-8?B?RVFUSUVJREhodXdJUmhITExVY0h4OVcwN2dCb1ZDUklKSjNjbVRLb1c3MGNL?= =?utf-8?B?TFdlYmFsczZKY2xaeUpDeWNLTWk1c1pDUDNiL2dQdTh5bDRBbmRXWFdRTVNr?= =?utf-8?B?TGltMG1wS0VnYWMxOElIZjR5UVVCemRwWEowU2hZd0c2YmxybEplenpUdkRL?= =?utf-8?B?bFMxWmVHZTJWUVh5RTFMWC9Cd2xpVUViZlY5SEg1blpyYS9sWm5yb1J6Nmlj?= =?utf-8?B?akQ1ODRIbW9abzE4OXVMa1dDOWM4RVJRNDdTekJoOGpGeFAzSENsL3dZWGto?= =?utf-8?B?aDlhbHlqVitqZlpTbnI5bDNTVWZnSlNrdVJIWWJvUmU2RUFvTllZZlMzc0wx?= =?utf-8?B?bE5ua1F0UkJ3V1p1Sm1STGpTV0g4anpxczUyOWlqbHdXYURVNTRTQ29NaXBV?= =?utf-8?B?eW9QMWZqb1prUHF1dXhteW5Sa0JnNm90UXc3ZkNlTGlSZEZWMDdkMTVoMkZQ?= =?utf-8?B?SVZNcnV4Wm1JRkdBQS9lUVN6Q0R0Wkgvb3J6NC9CZlQvYVUyZ2xqa0JCeFRk?= =?utf-8?B?RWRxMjhKYkFRVU9EWC9ZYUFkUHBRUGZ0NUJLTkcwRnhaMUdrR1lEUUVIekhC?= =?utf-8?B?UFlybU9mbjRRNU1DTUE0d05XUTN2ZFZWenZHQ1FuVWRmaXJoZnN1UlRQZklV?= =?utf-8?B?WnJsNHpETy9NT2V3b2Z0ODc4bnZZTU5Vc3EzSjdJN21SUDUzazZ4a3Z5Zk0v?= =?utf-8?B?ZkI5VUw0djg4cXZyUXRoTy9JNHpKdTNzblVIeC9mY2FVdWduR0NZb2dhTDJY?= =?utf-8?B?RW5nS1RWOVRocURLTUR5L0ZrK21uM3VGdUw0cTZ5ODM1MUpwdEpUWVg0ODVp?= =?utf-8?Q?BNmGoqRaR+PoVNk9V4kKiK8=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?TVpZSlVkRU0xSjltNGd3UU1OWGdDbWtmR0s2VWJtWHFPOXlZRklIemM4VDBz?= =?utf-8?B?RllWSkxUWk5ZOCsrMkZ6akxrV0o4UE5EVVp1OXIyRDExMmNITWFsWVNKZEdr?= =?utf-8?B?MW9oaU03TUozaEJ5K1haMEh1YVlFN3pGZW9UT0M4cWZUUVVLVGNoN1hTbFpI?= =?utf-8?B?MHV0TWhNMGp4S2tXV2FibEJHVk1KK1FDMHdNNkd2S1VZWWNIQXpObjd6YUxQ?= =?utf-8?B?WXhjV0N1ak8rQ0ZaQVVpbGNjSElEU3NQM3JteUcwUVNab3plMlVXbDRQcDBh?= =?utf-8?B?c1RXNVhJRTcwb20wbkhBQjNIRm9zWm1wcjNUMUU0NTltRWVKenZuZkc5VEhL?= =?utf-8?B?MkRjZUd6UlZ2cVdnOXNNWEttTWlUZnMxUUl2VTl1L2xvQkpZVFNydkRXVmd6?= =?utf-8?B?bEhVMDhQeW9oZ2VuMlptcVRCcytwdWw0ajBFbk5NZ1lZT0I3MS9heDhvWC9H?= =?utf-8?B?SlFTNCt5UDk2OWtCVUUybjRUb096YTdYcGZwZ2pqVXZzOHl5MlBXVGNzTU9Z?= =?utf-8?B?eTBpSE81ZG5GSUd0V1Zpb08zczlNMzl5enc3NHNkempwMXJNWmtTMXAxdkZI?= =?utf-8?B?ZGxsYnlWTzVRU3V1WDJmK01wcGt0TkJLRGlmMUYxYTRhSS9mZDhBdlpMNWZW?= =?utf-8?B?aG9vZVhhaWhLeEJQV2N4cU05US9uTW9YRzJiWnJRZUNXKzVTdmlnMWQxNDNB?= =?utf-8?B?VEs1MXpaWDhOQ3l3VzR0RDl3S3AxOG5mcnNFNU9CNTQ2eStSeUpUL2ZjVm5h?= =?utf-8?B?OUU2emdVRmV3ejJEUXpEL1JpMHhQbmhaSjl5V0xZVEZSd2xVM3V0L3FVcXEz?= =?utf-8?B?V21tY0dCRTB2YnVhMlkvNUJKd0lSMXQ4KzdicFFmampBeldUR2xwZ0Z3cWMr?= =?utf-8?B?WXVxVnNGWjBuWkEzckVCR01tR0toN0Vhb1FyTXp4U0FGSkkzNk5tTURpUGZE?= =?utf-8?B?R2dVQ2dZSzJDTmhnM2xDY1NoY0NuOUlsbFhYdjJNeVZFVXJYd1pDemo4c01K?= =?utf-8?B?MHFBSlNNZXlyUTArSVhjbEcxMjk1RDlJWTVUMG53ME13UDRFajBPMStLZjh4?= =?utf-8?B?UmVKRjJsOXlLN3R5NHcvVlNTRDdKUEdFaGZ1ZGFrVUw4ZFNSbDk5SXhlaWFL?= =?utf-8?B?SWFZc2R1M2ZGMG1rYnZHWDJFME5iOXNucEh1cG5zTHJoZ0N2ZklKNVF2dGVH?= =?utf-8?B?dnZNaGFKOVdYUDNkZUROZ0lpTWF1NWNzZklwNzlTRG9xSk5GK2Z3aS9rQ3ZT?= =?utf-8?B?RDhKQVdOcGRTUW0vL0QvRFU0YlFUT1J2aDVaYmxRN3ZFOGt4N2xSbktjOGxF?= =?utf-8?B?Q0tMWE51bVJIaG9qMzg3NytWYVBJQWFadkora01YWlhaMmVNU21hTzViL2JL?= =?utf-8?B?aGQ1bmpIeUhNNTIwdGs2OU4yQkVIbUlXVThUbXlGRFYvcXpPVExHS1dMMmRL?= =?utf-8?B?dHFOdEk5T290NWpid1U3UHlTNE81c0hja0NWTHlvTUhHTkcxUXFFN3FIN0xG?= =?utf-8?B?Q2V6M2h4QUVaVFVSVlZ5REJEQW8rcnFrNGIxT0ZFMXJHYlhSN0E0MVBsM202?= =?utf-8?B?a2lIbXYyMWlxSEJEcXc2ckExUjJxUFhYM2kzQjlWODVBTEE2SHRzVXBMTWQz?= =?utf-8?B?Z09hc2RNVlE4d2I3UnhIV3B1dVQxVHFOVHB0TkdNeDRESGorNEFyVXhvYnlC?= =?utf-8?B?SjZrY2haR2g4M21VNDF6NThmQVBiZDZZSGZkUFJWSVpxUUVKc0JGdzhjRVV0?= =?utf-8?B?L0w1M3BKZ3lTWmVQcHV3UkpObENjZWNERytpWlJZRWd4Zkh3Z0J2ZERQaEgx?= =?utf-8?B?Q3BqeXhGTFdEYXlhTWZyL2FTSzNlTzFhUlFkOFZEcGg0c1QzQ0ovTklkUFFj?= =?utf-8?B?N2N0OVh3LytWTHJkUnFSRkNVOTJBUGZLVWhNTnR2TG9jRGhJOW5ZM1hvMk5E?= =?utf-8?B?RExkakVjMzRKaUVzUzIvRU94Sm1sc3dOdEJvcWFIdHA5REdxUk1aZGVHVEgz?= =?utf-8?B?Q0xnREVtWGtON2djTHJVdVRwT0V1VFErL1RmWEJpL1ZTQjdUT201NWFEVWI1?= =?utf-8?B?bitXV3ZYRmdMb2F3R1orbjcwVHRUQlI4T3U5U2tBZTZvYkZlM21UbEtQZDVx?= =?utf-8?B?R2RvSVBTaFM3dmJtcmVzUFliSTdhekZOY2pod2lDMEt1NHlkTmVQNG54YlM2?= =?utf-8?B?cUN0dGNZb3NEd200WHoxcURHNmk0MUhNZDBTZ2tTQ2ZUNTczM3ZTeVBHR2Zx?= =?utf-8?B?TjFCcHJkbmlERVM4UExaOFY3WVpKVlZCaVdLL3dXVDAyNmI5bHo2VzYyZmVK?= =?utf-8?B?eUlkNHhBQmJuMDFBNFh2T0ZtaUxpZjBLcFhCb3RkMjYreTFleldtdlpPM1Vk?= =?utf-8?Q?Xx6H5GjYJR5J71xA=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <745F3C9C631B764A8F4BD212D4A5B1AF@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: f2e50d1a-d924-4785-b3ca-08de543f0187 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2026 14:04:31.7933 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hXiQwOrFaPu67Usb7qAMQVSHLiWTGEXQjSDbv/POeCYrMRXqgTjql9XfyEjOd3Hhh0DbEm9f0tVcPjcWWFF9tQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB11129 SGkgUGVubnksIEx1Y2ENCg0KSSB3YW50IHRvIGJyaW5nIEdJQ3Y0LjEgc3VwcG9ydCB0byB1cHN0 cmVhbSBYZW4gYW5kIEkgaGF2ZSBmb3VuZCB5b3VyIA0Kd29yayBmcm9tIGhlcmVbMV0uIEnigJl2 ZSBub3RpY2VkIHRoZSAiVXBzdHJlYW0tU3RhdHVzOiBJbmFwcHJvcHJpYXRlIiANCnRhZyBpbiB0 aGUgcGF0Y2guIENvdWxkIHlvdSBwbGVhc2UgY2xhcmlmeSBpZiB0aGlzIHN0YXR1cyBpcyBkdWUg dG8ganVzdCANCnRoZSBwYXRjaCBiZWluZyB0b28gYmlnIGFuZCBub3QgcHJlcGFyZWQgaW50byBh IHNlcmllcywgb3IgYXJlIHRoZXJlIA0Kc29tZSBvdGhlciwgbW9yZSBmdW5kYW1lbnRhbCBjb25j ZXJucz8NCg0KQWxzbywgaWYgSSBlbmQgdXAgc3BsaXR0aW5nIHRoaXMgY29kZSBpbnRvIGEgcHJv cGVyIHBhdGNoIHNlcmllcywgY291bGQgDQp5b3UgcGxlYXNlIHNwZWNpZnkgaG93IHlvdSB3YW50 IHRvIGJlIGNyZWRpdGVkIGluIHRoZSByZXN1bHRpbmcgcGF0Y2hlcz8NCg0KDQoNClsxXTogDQpo dHRwczovL2dpdGxhYi5hcm0uY29tL2F1dG9tb3RpdmUtYW5kLWluZHVzdHJpYWwvYXJtLWF1dG8t c29sdXRpb25zL3N3LXJlZi1zdGFjay8tL2Jsb2IvNGZjNDIwMWIyMWQ4YTBjZjY4Mzk1ZWRiZmFi NGRjYTFjNjAwNDk1NS95b2N0by9tZXRhLWFybS1hdXRvLXNvbHV0aW9ucy9yZWNpcGVzLWV4dGVu ZGVkL3hlbi9maWxlcy8wMDQyLXhlbi1hcm0taW50cm9kdWNlLUdJQ3Y0LjEtb24tQVJNLXBsYXRm b3JtLnBhdGNoDQoNCg0KQmVzdCByZWdhcmRzLA0KTXlreXRh From xen-devel-bounces@lists.xenproject.org Thu Jan 15 14:34:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 14:34:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205195.1519571 (Exim 4.92) (envelope-from ) id 1vgOQg-0002Ut-F1; Thu, 15 Jan 2026 14:34:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205195.1519571; Thu, 15 Jan 2026 14:34:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgOQg-0002Um-Bk; Thu, 15 Jan 2026 14:34:30 +0000 Received: by outflank-mailman (input) for mailman id 1205195; Thu, 15 Jan 2026 14:34: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 1vgOQe-0002Ug-Ta for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 14:34:29 +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 483f6d3f-f21f-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 15:34:23 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by CO1PR03MB5684.namprd03.prod.outlook.com (2603:10b6:303:95::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Thu, 15 Jan 2026 14:34:18 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Thu, 15 Jan 2026 14:34: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: 483f6d3f-f21f-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=WmyOFijCw253KWOe91WaGAJye5leSYS3NoE3VAvJ/1tJVo54w1BB0rPtVrqoLWGwfJJPqtk5jbZUpCnvBNFX51Qh/JHRR9gk6hyFfKDl0QPgzJOJy2DGIQnK32wgEonvGWKR441kaefER/EzW4q+Y1iq95K6u/HzHGPMPEQPCWp8kNZwA1yujD9xCGlI+4E0MWU0tm2RNsdZSQDgdnrHhYZcW5xiJDYXTIVN+QES6a3ChuB9knQCmHFI+d76T2hdjN1u7QNewt1iQEaqi7TMtt5VL3MJREunEhcwVdWmZchYQp/ClJmmlPAHh8/lROvJMIH0bg1nDyd+RII+34Jh1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sPzH/zU1VTKlM+wBOU58Q2pAmfy/+9lepNcKezU2nlU=; b=Dh1sejNf3D8h8vfJDU+vgNPDAUNolgzbnCvAa9nr1B/EKxEz0AHEaaa1wCLg4r4/iBriWGYmwt8bFP3v0piuwqsFLgiRRfD56fYlfLp4uMyP77UkBA1aYlWa1JSG/OSGOT+/0ZprLng3W9J7r15p3PAbhJrM9XeTYn0+DzzYsiQ+CJStFSqeqNIvpxADtciV6gFQlX2TlNnWzoJFaoFPLI6CEIVduap8HkaNzA4rlCpCS/KTK8HAGb/j/cWVz5UKDEF6nKpVhrVTR/nMjQqD3EN/knEPaKhPBWk7h2jNZ4aOoQokuUL7xJlKe/LZbH8E4aDty8qd4R6lfsdpwHgryQ== 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=sPzH/zU1VTKlM+wBOU58Q2pAmfy/+9lepNcKezU2nlU=; b=JwBAql3KDj1fdnMEYPegxN5pOX7c4Gy1H1jXSoUDMRm3n5ztL8BqYGw2E0gu0qk9yEcdeC6e1HE5CuZFqeN6AMfVw/3seqIwoIH/RYSgk+Xf4BmlCB7/Yor2x6/C1DdzuUNB1hp7m6W2tBKyu++TYhjHCKsD/AfiiqHi/VhLzAY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 15 Jan 2026 15:34:12 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: Victor Lira , xen-devel@lists.xenproject.org, Jan Beulich , Alejandro Vallejo Subject: Re: [XEN PATCH v1 1/1] x86/vlapic: match broadcasts for logical destination mode Message-ID: References: <20260114235548.626696-1-victorm.lira@amd.com> <20260114235548.626696-2-victorm.lira@amd.com> <95e0e0fb-2978-4c87-b723-fb7c30f36883@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <95e0e0fb-2978-4c87-b723-fb7c30f36883@citrix.com> X-ClientProxiedBy: ZR0P278CA0198.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:44::12) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|CO1PR03MB5684:EE_ X-MS-Office365-Filtering-Correlation-Id: 2a61347a-7ee2-4d81-ea26-08de5443291a 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?ZU9NamZjcXRtNzJwSHpFSjNoNGM4SENQWFV2ZDBNT3A0ZFJ1L0NiUlFyYkFC?= =?utf-8?B?V25WRm1PTW9LRkdwMzh1U2F3U1RPTFZQdVpqUVQyNlp6ekRmV2xPZXNJUE9v?= =?utf-8?B?N3B1ZE9RWVBSbzV3NGRhYjNzcFkxS0pYcE5BZjAzRkZ1bUlkMHZva3ZYRTI0?= =?utf-8?B?czBBclBRVXdDdHIxbHA1aDlkckdoVnp6TjVldE5kT280NDY4UFJrcFZwaXZI?= =?utf-8?B?NGJ3UlFxc0NzbTVNanFWVWw3cnVKT1VaTVEvaHF6YWNGSEZLcElNeEs0bmZw?= =?utf-8?B?aHY3MEFOVzdKN3NUaHR4WkNoRmtJQmtSSHMzSWdUcHNiamlDNmk1SkJaSzhR?= =?utf-8?B?TFowcWdiSGhwL1NQVWwzL2EzaXhTQk5GTW5oYS9Xc2Focmx1SUhxbXhMN21x?= =?utf-8?B?MU12THYwOTBScGNaVkdIY0JCNnkycnJUSGtNank4V004OWhZOUsxck9qdkVL?= =?utf-8?B?RTdmdW10enhJbGIvWTdqRWk3NnNVazdpaVg0N09MRTNCcXA3WFlaVHRjZVBP?= =?utf-8?B?S1gva28yanBqQWR2YmllZE43NUpEV3lCTzJRRWh0NCtKa3h4M2RvT3Ryd2Rw?= =?utf-8?B?dlc3V2RXSHQzT0xnampaU0RzdHZUYTdEc3ZwS1RIYWJBc2J4eXlDZzdPSFR3?= =?utf-8?B?RTlMQjdQaXdOU053M2s0Wit1N29RejVxaDZEUnRCQ25CRWg0UkxNbWRZek5Q?= =?utf-8?B?NWVuNkIvUTloMDUwTE15cmo1T0t4VU1GcVJ3RUV4RWYvUFZuR2lNVW56VDMr?= =?utf-8?B?ZE55di9FY0VuRTlNSWhDaW9lY3hoOHJjNWFsRlZqMWQ1enFUS0NwM201OG9Z?= =?utf-8?B?R1BIRlNuWksvNy82Y1h1NUFMdnBXYlRiT3dOSlNvUnhxMGVXREhOTm5mcFM0?= =?utf-8?B?VnhoM2J0OTFZSk01SEJEWWFQMERWb2swQUo4RHR6MHlQaWU4SWJEeFN5a3lH?= =?utf-8?B?SW42VjExLzlsbm9oMkk4T05PQXlOWS9BWjBielZPNVNWSFlrR05MYi9sMFNY?= =?utf-8?B?VTBpS25oV2wzYXNBS1hPUHlDaUozWUlrM3JYS3Z5SE50Q1ZhMEdNTHM3WEZV?= =?utf-8?B?OHJMQ1E1TkVtdzJLcmk0OVZIcjNpZGZwWFhqVlNNOFgvMndpTVFwR3kwVUky?= =?utf-8?B?cmZGMnh5M1Rvbk1FbHRDNmVXZmVoWkhQZmtqR3JEVm8rVlQ4RWdWVlpuclYr?= =?utf-8?B?V2M1dzQyT2FySXdUeFdobGRPYmswRlQ0VFZqSE8yaHAwOFlwNkUySWVGZzVw?= =?utf-8?B?NStWS3RINHp1djJleEZZTlVMZDJaeXJVL3NCcndPWDJqVlpBUDJ2UFNjOENu?= =?utf-8?B?MDRCbXZpcFRxNm1KQmluQ3BjN0k4SjlMQU85RWVtMFlxM1F0Ulkzd3N3Tzk1?= =?utf-8?B?MFRPWkI1WlN1SktIV2NCN04rY0txUkdMdHBYOTJkUHQrYkpDaE95NTU2bVp5?= =?utf-8?B?OWdFbUQrWDRlbDUvSmdSVFlwQXc4RVoyT0NsMmZ5RkNRQWU3RkswZlRjMTQz?= =?utf-8?B?czh0N3VWYTJYblZGUlVQMUFkVFNNS254TUhpYUQ4Nmg5Q1pOOFBqR0d0U1ZF?= =?utf-8?B?L2hKZVJIYUtraCtIVjBLdHJ3ZlN2eFBQNm1kc0VWenhzTld5Ulg5d0pmekow?= =?utf-8?B?aWNVdlVTV0hJeWpnZjRUMk5rRzZ4cXpHR1pPNS96WmVOM0pJZFdzczBJYUtq?= =?utf-8?B?cm52KzFqMGlUSXlyZUdHV3lLeVhCeVQ2V2ZvZER5L1lUM2E3VkxyNThuNVE3?= =?utf-8?B?TGNwYm1hWUp0QWd3Wno4RmIvQjJXb2RmUmJNYlR1d3VyMVpaN21CRzlqSlQz?= =?utf-8?B?ZU5uTDlWNzVmTUxTdEliRTBpSmxoR0N1eXM1WUJNZUw2WWg5RGFEaG1mYkhF?= =?utf-8?B?VXhLSmxtcEYwdTE1b0pzc0dJVi9BK2twWUpQQWMxSDBXOHNyNGxub1ZkcURq?= =?utf-8?B?aUs4dmJ3TFZpSGRObnVMamRURVFHbk1lYjYwTjNwVzFrZkp0R1I4R1JFL3dx?= =?utf-8?B?d2EybUd4WFV0YUFEMndxNExscVJEZXZQTVI3WFpxckFTSUp4ZGRKWEhzakkz?= =?utf-8?B?aWZwaklDMXhORUQzNVFMWVdvL2R5Zk9aN1ZOQmtOZ05NU0ZueFZJSEFZMitk?= =?utf-8?Q?tTp4=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?T05hMHc2dmt4enVtcDltR3JReEdZQzRVeEU1TVVIQzhpcTRGdHZ0dGtUZ0Y2?= =?utf-8?B?VUIyQWRCQ0Y5VnQrNGZLZXpUQ0JKbm52V3QvVnYxWWlBV2RUb3JHTXVUY3JY?= =?utf-8?B?blRReS8rVG5JK0ttakdiVm1FZTRRUDNIaStUcy9WM2FZTEhxVGlVWXBKNjNq?= =?utf-8?B?WURXbEg2TzZFMUhsSWp0ZHlzbXo0MkcxUUd2NjZBSUNld0o4K1pDV0o2aE03?= =?utf-8?B?MlUzVFMzSFhFQ2NLUmZkaUhVcE9PcEQ0NWRZMHRFMjdpMXF6cGR0RTBmK21m?= =?utf-8?B?cEdEa3pZK1Q5V3dkNWtsd0g4Yjh6ckhKTkhqbHZtSVgvMk5wSzZieEwrK1lr?= =?utf-8?B?WEVBWU0ybFhCUFlTa296UDJIczFvMWd4V0hyNTlEYzd1ZklSejVGUUc4cWYz?= =?utf-8?B?b2tTb29zS1VoWElGWG1jZGlxRFg5YmVEcXU0QmJ2UU1SNWJPQkR5K3NGYTZq?= =?utf-8?B?aDJoSlp5T25UVEp3THcyeVJPc2pBRStic2UySDgwbElaSm1LOXVwRGV6SzY5?= =?utf-8?B?TWVQNnQ2dkl6Z1YxeFBBa0RERnd3QmQ2UnZDQXRNK3FybDYycFJld1NUODlK?= =?utf-8?B?dTVsd0lCRmpidHNzMnEwR2pvK0wyY2VrOThrUTd5WmJzNXlWRUF5Z3JNR1Bm?= =?utf-8?B?RGJNMXRNcVVvU1poUjlPbFRkeVljYmVFQzMvQ2xBT0E1V0daaHk0UFozU3Zu?= =?utf-8?B?Zm9YNzd2ZlpXL0Rsb2VFSzdyRnpSN0M0S2p6dWdZREdHeEtNRjY5U1k0QVYz?= =?utf-8?B?Kzd1VWc4dmgvMFhLWk1UY2cxWWo0TU1LS01qWitsLy9yU0w5cnBlam96SFZN?= =?utf-8?B?d3BWWkZvcXFHblViWWFXWkhHV1dDM0ZmMC9nTzV4UWdCWHgya042NGh5cnBh?= =?utf-8?B?a2N5b0VmaWlTdElURG4rZHFjU05lejJYaVFtVDdPV0FVUjR4TXlRR2Q1Mnh5?= =?utf-8?B?UGw4VkQ5M09sZHpBWTVCMERNUVpsWXVZRGpDN24vRFJaM2QrbzVWTzlsV2JQ?= =?utf-8?B?SHB2dVBpSUtYMjVjVXFrbVZNUGI0NFRhVTN1b1RQUEFBSFNCTjVMOUdpbnVF?= =?utf-8?B?QmtrTWdWSUZtemY1cUVHN2V5KzFPU1NBQmxCRGd6ZHZRZnZZK0JVdS9LSWpq?= =?utf-8?B?aDhoVk5BUXhOK3J1TlVGemFVTUxGNDVnelZLcWdVWjd4cFBVWkVOek4wMkgx?= =?utf-8?B?NDlYUUJpaTdKYU40M0VsZzBtS3ZKd0NTYUJnSDlTMmtPaUtHZmZ2ZnhYLzlX?= =?utf-8?B?RWdzdmJRVW5ZN3RoUXFpMXFuZWY0ZDlYb3NGT1NGMU9SS3RJbDdnWDlyd1FR?= =?utf-8?B?OEFpVlQyZlE0UjJWN3czL1NqY0theitGVUhtNXljcnNxUGtyM0x5LzN2dk9R?= =?utf-8?B?RHlEa3hjRjJVay9FYUtnMFlMRFZPZXBmVmlCS0U3N3pRV2M1UDJlV2o4eXlK?= =?utf-8?B?VEJpT1llZzhLQXBxQi9vU29LRENyT0F5QzM0SHZLNllWeHJOR28wd1dwUDFI?= =?utf-8?B?WnNtVEhPdkpqaDFvQXM2Zml6WUdyVUlUUzRISTUxSUxFQ1QzVUV1SnJDV1lJ?= =?utf-8?B?d3M0Y3h6NHd1bTVPZVBUd2NZclFEYjU3TlFCcG5uYlpKTm50NVNsQUcxbGNW?= =?utf-8?B?RGVsK2FISTlMNklIdVZGMmE5Z0VwMHR6WDdqRXFURlRRdXhQUEd5NVdUeWpZ?= =?utf-8?B?QXhUTzlGcmROaU50Tmp0bnVWb05aNDFuNVVqR1VTVlM4TFU5Q1FjNHRXYTEz?= =?utf-8?B?TGNhZkhXQTF3UUs4WmRUeExHMzFUMHV4d3RNZXVvNXBuRGF1STk2dzRwTCtm?= =?utf-8?B?aFJMb0RKenM0QUh6L3JCc0hNWTNneVRCQzg1UDVCUUhIdlRhdWtUVWs1N3RG?= =?utf-8?B?dFM1MmJQcUdyY3pSUVNsTXRjNUF6K2FVek90UkVVRFZWZysxTDNaSnNORkFD?= =?utf-8?B?Vnl1NzdocUdNTHJ3SUF1R3ZnaGs0ZzBNRWhmZ0h3aGxsVkkvL3hsVFhkc2tR?= =?utf-8?B?M1IxU3VubHNaMDBEYVFnaE5lYlN2MXF6ZDdHblo1eUpDcFk4RjdnY2IzWUEv?= =?utf-8?B?WEdEcytJU2M0U3c0YlZlei9MMkJ3ZmxkYnZQR2MveFhmS1VnaEtUZVVPWWhS?= =?utf-8?B?Q01NcmxZSjhXVzlaT2lyL0R5YnB0NmdEd1VLSE0yYnZ6cGFLNVdQNGg5d2xD?= =?utf-8?B?RHRUcWV4TGFCOFBHTG5SL2xXTnhwSEFkVHhOOHR2RVdYVk5PTEhSS2kzOHB1?= =?utf-8?B?N1BZYWhRWGVJRWNwZFhxbVRUZjVWSWpLdVNXS2VFWURwdVArN0pjZ1d6NzJK?= =?utf-8?B?TUszWVVoRStJZEM3UGFkejBqWkdZNzc5b2xWWU0xM2NEMnp1MWNnQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2a61347a-7ee2-4d81-ea26-08de5443291a X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 14:34:16.4669 (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: VkCs9lGqJS3krFWyza8+HA5Cu8I9A0pj5tVXbUvW81o20gz+Z0rETXllPUQuvLHf+Ad4hXpOV8sBBLyjr8/Nuw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB5684 On Thu, Jan 15, 2026 at 02:01:12AM +0000, Andrew Cooper wrote: > On 14/01/2026 11:55 pm, Victor Lira wrote: > > amd64 vol 3 > > 16.6.1: "In both the flat model and the cluster model, if the > > destination field = FFh, the interrupt is accepted by all local APICs." > > 16.14: "A DEST value of FFFF_FFFFh in the ICR is used to broadcast > > IPIs to all local APICs." > > > > intel 64 vol 3 > > 12.6.2.2: "Broadcast to all local APICs is achieved by setting all > > destination bits to one." > > 12.12.9: "A destination ID value of FFFF_FFFFH is used > > for broadcast of interrupts in both logical destination and physical > > destination modes." > > The formatting here really needs some work. > > > > > The specs say 0xFFFFFFFF/0xFF should be a broadcast to all APICs in > > logical destination mode but it is matched only for cluster 0xFFFF/0xFF > > (or as flat mode in xAPIC). > > > > Add a check in vlapic_match_dest similar to what is done for physical > > destination mode. > > This possibly needs a "Fixes:" tag, I think: Fixes: 7429bfd50dd7 ("This patch provide local APIC support for vmx guest.") It's been broken since it was introduced. > > Signed-off-by: Victor Lira > > --- > > xen/arch/x86/hvm/vlapic.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c > > index 79697487ba..1208cd21f0 100644 > > --- a/xen/arch/x86/hvm/vlapic.c > > +++ b/xen/arch/x86/hvm/vlapic.c > > @@ -248,7 +248,8 @@ bool vlapic_match_dest( > > { > > case APIC_DEST_NOSHORT: > > if ( dest_mode ) > > - return vlapic_match_logical_addr(target, dest); > > + return (dest == _VLAPIC_ID(target, 0xffffffffU)) || > > + vlapic_match_logical_addr(target, dest); > > return (dest == _VLAPIC_ID(target, 0xffffffffU)) || > > (dest == VLAPIC_ID(target)); > > The SDM/APM quotes are clear, but I think this logic has more bugs than > just this. > > First, you've got a common expression that the compiler cannot optimise > because of the function calls hidden in VLAPIC_ID().  The appropriate > rearrangement would be: > >     case APIC_DEST_NOSHORT: >         return (dest == _VLAPIC_ID(target, 0xffffffffU) || >                 dest_mode ? vlapic_match_logical_addr(target, dest) >                           : dest == VLAPIC_ID(target)); > > > However, the first clause looking for the broadcast ID is surely wrong. > > Surely it needs checking against the source LAPIC, not the target.  That would be: Fixes: f9e0cccf7b35 ("x86/HVM: fix ID handling of x2APIC emulation") > Whether 0xff or 0xffffffff is the broadcast address depends on the xAPIC > vs x2APIC mode of the sending LAPIC only, and it's surely buggy to fail > to match targets just because they're in the opposite mode.  So, I think > the correct code is: > >     case APIC_DEST_NOSHORT: >         return (dest == _VLAPIC_ID(source, 0xffffffffU) || >                 dest_mode ? vlapic_match_logical_addr(target, dest) >                           : dest == VLAPIC_ID(target)); > > > Thoughts? LGTM. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 15 14:44:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 14:44:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205218.1519581 (Exim 4.92) (envelope-from ) id 1vgOaF-0004Er-Gd; Thu, 15 Jan 2026 14:44:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205218.1519581; Thu, 15 Jan 2026 14:44: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 1vgOaF-0004Ek-D2; Thu, 15 Jan 2026 14:44:23 +0000 Received: by outflank-mailman (input) for mailman id 1205218; Thu, 15 Jan 2026 14:44:22 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgOaE-0004Ee-9y for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 14:44:22 +0000 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a947ee84-f220-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 15:44:16 +0100 (CET) Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jan 2026 06:44:13 -0800 Received: from lkp-server01.sh.intel.com (HELO 765f4a05e27f) ([10.239.97.150]) by fmviesa001.fm.intel.com with ESMTP; 15 Jan 2026 06:44:09 -0800 Received: from kbuild by 765f4a05e27f with local (Exim 4.98.2) (envelope-from ) id 1vgOZy-00000000I54-3wGb; Thu, 15 Jan 2026 14:44: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: a947ee84-f220-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1768488256; x=1800024256; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=W8bSj3Tt1fNR22DvPlznzXtp4tTD+xt+MEIzrxtDuUM=; b=AqcVCN8nfy0Sd5yX51uL8zOKmETXVsw8iHMGOQw+VfZudWaQl9qVg8qc 1eSQ9GpxYVmQ70VxHutb/PHHsuSHmIPyOEYTr/Gij8XxaJDl+y8HZdhlE 39hN8S2Waac5sotshvEntV+fiqP8vKD+A7U/YSrAfFPd79RZxNN9Tv3yd cJxSmPpJTqVFKMe2XtdJIIu5gA3LbjxVy4UN16C9qpeajZhNuHLud/EZj j6BHV3cisul9czCSi1tvv/GJNLwPWk/fMbOOU55v7Lu26IjiT0lLxA92T CKsrGhVcTsJbR5qdnmpH0u6tMwZ7iSHp3GNzKLH267lRjINuKzODNjSG6 g==; X-CSE-ConnectionGUID: 5C4OF2AySB+qxJD1oSx8rA== X-CSE-MsgGUID: QYGoQ/hlTZSRLxTOFPS8dw== X-IronPort-AV: E=McAfee;i="6800,10657,11672"; a="69773532" X-IronPort-AV: E=Sophos;i="6.21,228,1763452800"; d="scan'208";a="69773532" X-CSE-ConnectionGUID: 1CV0d29lS5m316xjAn+w0w== X-CSE-MsgGUID: 5+bzz2H0T3OvpIwVh4UbOQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,228,1763452800"; d="scan'208";a="236223880" Date: Thu, 15 Jan 2026 22:43:59 +0800 From: kernel test robot To: Juergen Gross , linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux.dev, kvm@vger.kernel.org Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev, Juergen Gross , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Paolo Bonzini , Vitaly Kuznetsov , Boris Ostrovsky , xen-devel@lists.xenproject.org Subject: Re: [PATCH v3 1/5] x86/paravirt: Replace io_delay() hook with a bool Message-ID: <202601152203.plJOoOEF-lkp@intel.com> References: <20260115084849.31502-2-jgross@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260115084849.31502-2-jgross@suse.com> Hi Juergen, kernel test robot noticed the following build errors: [auto build test ERROR on tip/master] [also build test ERROR on next-20260115] [cannot apply to kvm/queue kvm/next tip/x86/core kvm/linux-next tip/auto-latest linus/master v6.19-rc5] [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-Replace-io_delay-hook-with-a-bool/20260115-165320 base: tip/master patch link: https://lore.kernel.org/r/20260115084849.31502-2-jgross%40suse.com patch subject: [PATCH v3 1/5] x86/paravirt: Replace io_delay() hook with a bool config: i386-randconfig-011-20260115 (https://download.01.org/0day-ci/archive/20260115/202601152203.plJOoOEF-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/20260115/202601152203.plJOoOEF-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/202601152203.plJOoOEF-lkp@intel.com/ All errors (new ones prefixed by >>): >> drivers/cpufreq/longhaul.c:145:2: error: call to undeclared function 'arch_safe_halt'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 145 | safe_halt(); | ^ include/linux/irqflags.h:231:3: note: expanded from macro 'safe_halt' 231 | raw_safe_halt(); \ | ^ include/linux/irqflags.h:192:27: note: expanded from macro 'raw_safe_halt' 192 | #define raw_safe_halt() arch_safe_halt() | ^ >> drivers/cpufreq/longhaul.c:150:2: error: call to undeclared function 'halt'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 150 | halt(); | ^ drivers/cpufreq/longhaul.c:179:2: error: call to undeclared function 'arch_safe_halt'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 179 | safe_halt(); | ^ include/linux/irqflags.h:231:3: note: expanded from macro 'safe_halt' 231 | raw_safe_halt(); \ | ^ include/linux/irqflags.h:192:27: note: expanded from macro 'raw_safe_halt' 192 | #define raw_safe_halt() arch_safe_halt() | ^ drivers/cpufreq/longhaul.c:187:4: error: call to undeclared function 'halt'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 187 | halt(); | ^ drivers/cpufreq/longhaul.c:205:3: error: call to undeclared function 'halt'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 205 | halt(); | ^ drivers/cpufreq/longhaul.c:224:4: error: call to undeclared function 'halt'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 224 | halt(); | ^ drivers/cpufreq/longhaul.c:165:6: warning: variable 't' set but not used [-Wunused-but-set-variable] 165 | u32 t; | ^ 1 warning and 6 errors generated. vim +/arch_safe_halt +145 drivers/cpufreq/longhaul.c ^1da177e4c3f41 arch/i386/kernel/cpu/cpufreq/longhaul.c Linus Torvalds 2005-04-16 134 ac617bd0f7b959 arch/x86/kernel/cpu/cpufreq/longhaul.c Dave Jones 2009-01-17 135 static void do_longhaul1(unsigned int mults_index) ^1da177e4c3f41 arch/i386/kernel/cpu/cpufreq/longhaul.c Linus Torvalds 2005-04-16 136 { dadb49d8746bc4 arch/i386/kernel/cpu/cpufreq/longhaul.c Rafa Bilski 2006-07-03 137 union msr_bcr2 bcr2; ^1da177e4c3f41 arch/i386/kernel/cpu/cpufreq/longhaul.c Linus Torvalds 2005-04-16 138 c435e608cf59ff drivers/cpufreq/longhaul.c Ingo Molnar 2025-04-09 139 rdmsrq(MSR_VIA_BCR2, bcr2.val); dadb49d8746bc4 arch/i386/kernel/cpu/cpufreq/longhaul.c Rafa Bilski 2006-07-03 140 /* Enable software clock multiplier */ dadb49d8746bc4 arch/i386/kernel/cpu/cpufreq/longhaul.c Rafa Bilski 2006-07-03 141 bcr2.bits.ESOFTBF = 1; ac617bd0f7b959 arch/x86/kernel/cpu/cpufreq/longhaul.c Dave Jones 2009-01-17 142 bcr2.bits.CLOCKMUL = mults_index & 0xff; dadb49d8746bc4 arch/i386/kernel/cpu/cpufreq/longhaul.c Rafa Bilski 2006-07-03 143 dadb49d8746bc4 arch/i386/kernel/cpu/cpufreq/longhaul.c Rafa Bilski 2006-07-03 144 /* Sync to timer tick */ dadb49d8746bc4 arch/i386/kernel/cpu/cpufreq/longhaul.c Rafa Bilski 2006-07-03 @145 safe_halt(); dadb49d8746bc4 arch/i386/kernel/cpu/cpufreq/longhaul.c Rafa Bilski 2006-07-03 146 /* Change frequency on next halt or sleep */ 78255eb2397332 drivers/cpufreq/longhaul.c Ingo Molnar 2025-04-09 147 wrmsrq(MSR_VIA_BCR2, bcr2.val); 179da8e6e8903a arch/i386/kernel/cpu/cpufreq/longhaul.c Rafa Bilski 2006-08-08 148 /* Invoke transition */ 179da8e6e8903a arch/i386/kernel/cpu/cpufreq/longhaul.c Rafa Bilski 2006-08-08 149 ACPI_FLUSH_CPU_CACHE(); 179da8e6e8903a arch/i386/kernel/cpu/cpufreq/longhaul.c Rafa Bilski 2006-08-08 @150 halt(); dadb49d8746bc4 arch/i386/kernel/cpu/cpufreq/longhaul.c Rafa Bilski 2006-07-03 151 dadb49d8746bc4 arch/i386/kernel/cpu/cpufreq/longhaul.c Rafa Bilski 2006-07-03 152 /* Disable software clock multiplier */ dadb49d8746bc4 arch/i386/kernel/cpu/cpufreq/longhaul.c Rafa Bilski 2006-07-03 153 local_irq_disable(); c435e608cf59ff drivers/cpufreq/longhaul.c Ingo Molnar 2025-04-09 154 rdmsrq(MSR_VIA_BCR2, bcr2.val); dadb49d8746bc4 arch/i386/kernel/cpu/cpufreq/longhaul.c Rafa Bilski 2006-07-03 155 bcr2.bits.ESOFTBF = 0; 78255eb2397332 drivers/cpufreq/longhaul.c Ingo Molnar 2025-04-09 156 wrmsrq(MSR_VIA_BCR2, bcr2.val); ^1da177e4c3f41 arch/i386/kernel/cpu/cpufreq/longhaul.c Linus Torvalds 2005-04-16 157 } ^1da177e4c3f41 arch/i386/kernel/cpu/cpufreq/longhaul.c Linus Torvalds 2005-04-16 158 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki From xen-devel-bounces@lists.xenproject.org Thu Jan 15 14:46:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 14:46:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205234.1519591 (Exim 4.92) (envelope-from ) id 1vgOcG-0004lm-Sn; Thu, 15 Jan 2026 14:46:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205234.1519591; Thu, 15 Jan 2026 14: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 1vgOcG-0004lf-Pd; Thu, 15 Jan 2026 14:46:28 +0000 Received: by outflank-mailman (input) for mailman id 1205234; Thu, 15 Jan 2026 14:46:27 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgOcE-0004lZ-CV for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 14:46:27 +0000 Received: from forwardcorp1d.mail.yandex.net (forwardcorp1d.mail.yandex.net [178.154.239.200]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f4751a25-f220-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 15:46:20 +0100 (CET) Received: from mail-nwsmtp-smtp-corp-main-66.iva.yp-c.yandex.net (mail-nwsmtp-smtp-corp-main-66.iva.yp-c.yandex.net [IPv6:2a02:6b8:c0c:bca6:0:640:3d05:0]) by forwardcorp1d.mail.yandex.net (Yandex) with ESMTPS id BF22180868; Thu, 15 Jan 2026 17:46:19 +0300 (MSK) Received: from vsementsov-lin (unknown [2a02:6bf:8080:b8d::1:8]) by mail-nwsmtp-smtp-corp-main-66.iva.yp-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id 8kWwj30BHuQ0-HTKyN28y; Thu, 15 Jan 2026 17:46:19 +0300 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f4751a25-f220-11f0-9ccf-f158ae23cfc8 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1768488379; bh=Sog4NysrTRQOFCDxSu8OumRUjUeggtRZWWoGKeJhXK8=; h=Cc:Message-ID:References:Date:In-Reply-To:Subject:To:From; b=Zo+ReVQSp0H9DsSsqmLA+kMJOcr4AtKNgy8qGN6uamZ5F60AS1SURE/HMjegdE7G4 DB2Toh+3/Sb3jvZfPaDpL7JoYQK7j+MdBtSnPNoL8MLi9NDS63hPW8aFwJrGS0P5c6 svuGmV/obDwfYA8kobs7ivPGRb9Ky/dYNlaHLiGg= Authentication-Results: mail-nwsmtp-smtp-corp-main-66.iva.yp-c.yandex.net; dkim=pass header.i=@yandex-team.ru From: Vladimir Sementsov-Ogievskiy To: marcandre.lureau@redhat.com Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, vsementsov@yandex-team.ru, Stefano Stabellini , Anthony PERARD , Paul Durrant , "Edgar E. Iglesias" , xen-devel@lists.xenproject.org (open list:X86 Xen CPUs) Subject: [PATCH v3 08/10] chardev: introduce .chr_get_pty_name() handler Date: Thu, 15 Jan 2026 17:46:02 +0300 Message-ID: <20260115144606.233252-9-vsementsov@yandex-team.ru> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260115144606.233252-1-vsementsov@yandex-team.ru> References: <20260115144606.233252-1-vsementsov@yandex-team.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently we do two wrong things: 1. Abuse s->filename to get pty_name from it 2. Violate layering with help of CHARDEV_IS_PTY() Let's get rid of both, and introduce correct way to get pty name in generic code, if available. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Marc-André Lureau --- chardev/char-pty.c | 7 +++++++ chardev/char.c | 19 +++++++++++++------ hw/char/xen_console.c | 7 ++++--- include/chardev/char.h | 7 +++++-- 4 files changed, 29 insertions(+), 11 deletions(-) diff --git a/chardev/char-pty.c b/chardev/char-pty.c index a582aa7bc7..047aade09e 100644 --- a/chardev/char-pty.c +++ b/chardev/char-pty.c @@ -387,6 +387,12 @@ static void pty_chr_parse(QemuOpts *opts, ChardevBackend *backend, Error **errp) pty->path = g_strdup(path); } +static char *pty_chr_get_pty_name(Chardev *chr) +{ + PtyChardev *s = PTY_CHARDEV(chr); + return g_strdup(s->pty_name); +} + static void char_pty_class_init(ObjectClass *oc, const void *data) { ChardevClass *cc = CHARDEV_CLASS(oc); @@ -396,6 +402,7 @@ static void char_pty_class_init(ObjectClass *oc, const void *data) cc->chr_write = pty_chr_write; cc->chr_update_read_handler = pty_chr_update_read_handler; cc->chr_add_watch = pty_chr_add_watch; + cc->chr_get_pty_name = pty_chr_get_pty_name; } static const TypeInfo char_pty_type_info = { diff --git a/chardev/char.c b/chardev/char.c index 44bfed3627..0dc792b88f 100644 --- a/chardev/char.c +++ b/chardev/char.c @@ -1090,9 +1090,7 @@ ChardevReturn *qmp_chardev_add(const char *id, ChardevBackend *backend, } ret = g_new0(ChardevReturn, 1); - if (CHARDEV_IS_PTY(chr)) { - ret->pty = g_strdup(chr->filename + 4); - } + ret->pty = qemu_chr_get_pty_name(chr); return ret; @@ -1101,6 +1099,17 @@ err: return NULL; } +char *qemu_chr_get_pty_name(Chardev *chr) +{ + ChardevClass *cc = CHARDEV_GET_CLASS(chr); + + if (cc->chr_get_pty_name) { + return cc->chr_get_pty_name(chr); + } + + return NULL; +} + ChardevReturn *qmp_chardev_change(const char *id, ChardevBackend *backend, Error **errp) { @@ -1192,9 +1201,7 @@ ChardevReturn *qmp_chardev_change(const char *id, ChardevBackend *backend, object_unref(OBJECT(chr_new)); ret = g_new0(ChardevReturn, 1); - if (CHARDEV_IS_PTY(chr_new)) { - ret->pty = g_strdup(chr_new->filename + 4); - } + ret->pty = qemu_chr_get_pty_name(chr_new); return ret; } diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c index 8ee098d9ad..bdeb76dc87 100644 --- a/hw/char/xen_console.c +++ b/hw/char/xen_console.c @@ -418,6 +418,7 @@ static void xen_console_realize(XenDevice *xendev, Error **errp) XenConsole *con = XEN_CONSOLE_DEVICE(xendev); Chardev *cs = qemu_chr_fe_get_driver(&con->chr); unsigned int u; + g_autofree char *pty_name = NULL; if (!cs) { error_setg(errp, "no backing character device"); @@ -450,9 +451,9 @@ static void xen_console_realize(XenDevice *xendev, Error **errp) trace_xen_console_realize(con->dev, object_get_typename(OBJECT(cs))); - if (CHARDEV_IS_PTY(cs)) { - /* Strip the leading 'pty:' */ - xen_device_frontend_printf(xendev, "tty", "%s", cs->filename + 4); + pty_name = qemu_chr_get_pty_name(cs); + if (pty_name) { + xen_device_frontend_printf(xendev, "tty", "%s", pty_name); } /* No normal PV driver initialization for the primary console under Xen */ diff --git a/include/chardev/char.h b/include/chardev/char.h index e1bf97222b..ada5529fa6 100644 --- a/include/chardev/char.h +++ b/include/chardev/char.h @@ -247,8 +247,6 @@ OBJECT_DECLARE_TYPE(Chardev, ChardevClass, CHARDEV) #define CHARDEV_IS_RINGBUF(chr) \ object_dynamic_cast(OBJECT(chr), TYPE_CHARDEV_RINGBUF) -#define CHARDEV_IS_PTY(chr) \ - object_dynamic_cast(OBJECT(chr), TYPE_CHARDEV_PTY) struct ChardevClass { ObjectClass parent_class; @@ -308,6 +306,9 @@ struct ChardevClass { void (*chr_be_event)(Chardev *s, QEMUChrEvent event); void (*chr_listener_cleanup)(Chardev *chr); + + /* return PTY name if available */ + char *(*chr_get_pty_name)(Chardev *s); }; Chardev *qemu_chardev_new(const char *id, const char *typename, @@ -322,4 +323,6 @@ GSource *qemu_chr_timeout_add_ms(Chardev *chr, guint ms, void suspend_mux_open(void); void resume_mux_open(void); +char *qemu_chr_get_pty_name(Chardev *chr); + #endif -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 15 14:50:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 14:50:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205249.1519601 (Exim 4.92) (envelope-from ) id 1vgOgG-0006LK-CH; Thu, 15 Jan 2026 14:50:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205249.1519601; Thu, 15 Jan 2026 14:50: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 1vgOgG-0006LD-9p; Thu, 15 Jan 2026 14:50:36 +0000 Received: by outflank-mailman (input) for mailman id 1205249; Thu, 15 Jan 2026 14:50: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 1vgOgF-0006L7-Rz for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 14:50:35 +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 8be149a4-f221-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 15:50:34 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-b86ed375d37so134970566b.3 for ; Thu, 15 Jan 2026 06:50:34 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a27cc6bsm2814906366b.23.2026.01.15.06.50.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 06:50:32 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8be149a4-f221-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768488634; x=1769093434; 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=16eX45xSUfz4pCxpxfVOREW80XWq4NETUSWgOvDD4hY=; b=WpnWo/QuD5ul7ZoTeH3Uup5k6wC8u+Jeu4Mi6inAI9ayOWH1Bg2Xjrbd6Z9y2CjN/5 4Jhk+oc0PjpYviDlwG3vhMnb5NsrNdiYLfyr8uQmyH9cbUKddjOARUJGwEKvnNfu1IeP zYmfJW9+BLrccqRMrStbI9qbelor8hwIiANYGhqmZq+IiAOFDDRV8ikRehANK8PvPdOg vm3GYunHHirfJAvxzziBLOI5N/X4HUMIojmseQs0o/tzuNX6mkiVjKeIyZK181mNRsNQ SQ4i6oEiRNuhD3C+D1CYi3B7nvhmuW6WW7Oyr/mjGk0t0mwbYaFEPUUukiEdTLw9P0F1 H3gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768488634; x=1769093434; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=16eX45xSUfz4pCxpxfVOREW80XWq4NETUSWgOvDD4hY=; b=VDELMopaOp5eQC1cYrg/sMZUAwpV4eIZ/g5t5Q25FLTN8LaqMXePPSSEY9//cRF7vZ OKxypg1MMhnX5mvEE11TyJBmvmqAuzPjQ9cCWwT7HK3x2sGp/UNCDXeNCjFNPFh0wjxD ovefhndQOonUuZlHK2jCyUz2eJMhyau+Q3Q8jhjTblDZBAhpCGS9N58/H+C4oDRjOMWP mmClDEdTQXj9nHNO2fukw2dOxOdI5V1EEGeYc+kh4wLIUxASlrOMqdDFVIhGK6NWRhuN vsEM/meNKCUf9BuT3iTzfS5AV0f7ka0bqCS/6I6t4TyEHpFGu2caTUucDTVklV8GjTKg Wa/g== X-Forwarded-Encrypted: i=1; AJvYcCVvV1y21ubHoLHth96GoAcaHlQnhEnByMmSQmTAQy/Ak0/nZYsc50+HWO1pbWMIp84SNT+H1LclhY8=@lists.xenproject.org X-Gm-Message-State: AOJu0YxWTReXhV2MrgMBKj96au00zYKEDij3fWjQhxWwbsaQ16/x4Utx iY/mEjTjxv5alhcboQJ7JfEMo6o3L/HiiYUJ4QlzbRtm86mLIKi618G0 X-Gm-Gg: AY/fxX5F6heCTvqqxIp3QrbM+NSVl3WKmRZPe72MS2OehANKCjceIbzDbgtIVDyxoHK 7D0PlQ1NqUJfi1aGAUeKoq2jFihZpqbpMFsebAp+E4YoXuV5HV7KuObH04k7zbOe7FDquay2jnL SDQ5FCVh3UdaIERumGs6l3Yo3fKlgK1oBgaur3HdVKhjuqJdB+/1/pimPd0e+DUYKJjS4lb91P4 pOVxJtVRd+XKxmWllGFX6P/SgPHPqE6bQnqYh2UnWB9u3BaUxJS0L5T8AdCLZv5ylAFNpv92G2X lTWhEM26LbqFRDWn9c3ts+QIFXewI+xsHHDxIWCqp0aNzQDSGfMh7bJZmE33aXCm8DRaBrrMeg8 J4LcxaG0kA7l75tPQexlo9OOniEfahiA2p9mb8JSn0448I0b9kj9rxGaYNinX7Z/EH5ManYPtnf rXEWZKOYLodRCHtNEJhDosUI/VNoSAF1MbB+ycG+2q+kbpDqvgQSMAZQavY4JDSTc= X-Received: by 2002:a17:907:75c7:b0:b87:6f58:a848 with SMTP id a640c23a62f3a-b876f58b96cmr300906766b.51.1768488633420; Thu, 15 Jan 2026 06:50:33 -0800 (PST) Message-ID: <4e94f7f5-2cf2-4695-873b-5d269f10ddac@gmail.com> Date: Thu, 15 Jan 2026 15:50:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/riscv: dump CSRs on unexpected traps To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260115125601.70834-1-oleksii.kurochko@gmail.com> <8377bdc2-d92d-4c3f-893b-19c842cad3a7@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <8377bdc2-d92d-4c3f-893b-19c842cad3a7@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/15/26 2:12 PM, Jan Beulich wrote: > On 15.01.2026 13:56, Oleksii Kurochko wrote: >> --- a/xen/arch/riscv/traps.c >> +++ b/xen/arch/riscv/traps.c >> @@ -17,6 +17,10 @@ >> #include >> #include >> >> +#define print_csr(csr) do { \ >> + printk("\t" #csr ": %#02lx\n", csr_read(csr)); \ > Why the 02 in the format? If you wanted to align things, you'd use %016lx. (I > also don't think the 0x prefixes are overly useful in such dumping, but others > may disagree.) As an aside, the width of 2 would be fully consumed by your use > of #, except for zero which would (oddly) be printed as 00 afaict. I used before 0x%02lx and after switch to %# don't think that 02 would fully consumed by #. I am okay to use just %lx. > >> +} while ( 0 ) > Why the do/while wrapping, btw? Added it automatically, there is no really to have it here. I'll drop. > >> @@ -99,12 +103,63 @@ static const char *decode_cause(unsigned long cause) >> return decode_trap_cause(cause); >> } >> >> +static void dump_csrs(unsigned long cause) >> +{ >> + unsigned long hstatus; >> + bool gva; >> + >> + printk("\nDumping CSRs...\n"); >> + >> + printk("Supervisor CSRs\n"); >> + print_csr(CSR_STVEC); >> + print_csr(CSR_SATP); >> + print_csr(CSR_SEPC); >> + >> + hstatus = csr_read(CSR_HSTATUS); >> + gva = !!(hstatus & HSTATUS_GVA); > No need for !! when the lhs type is bool. Question is whether gva is useful > to have as a local in the first place, when ... > >> + printk("\tCSR_STVAL: %#02lx%s\n", csr_read(CSR_STVAL), >> + gva ? ", (guest virtual address)" : ""); > ... this it's sole use (you don't use where you could further down). Agree, with such usage there is no really necessity for it. > >> + printk("\tCSR_SCAUSE: %#02lx\n", cause); >> + printk("\t\tDescription: %s\n", decode_cause(cause)); >> + print_csr(CSR_SSTATUS); >> + >> + printk("\nVirtual Supervisor CSRs\n"); >> + print_csr(CSR_VSTVEC); >> + print_csr(CSR_VSATP); >> + print_csr(CSR_VSEPC); >> + print_csr(CSR_VSTVAL); >> + cause = csr_read(CSR_VSCAUSE); >> + printk("\tCSR_VSCAUSE: %#02lx\n", cause); >> + printk("\t\tDescription: %s\n", decode_cause(cause)); >> + print_csr(CSR_VSSTATUS); > Everything below I understand wants dumping, but for much of the above > that's less clear to me. Why would guest's values be relevant when we > have a hypervisor problem? It could be useful when we jump to guest, something wasn't configured correctly and so lets say an illegal instruction in guest happen and so it would be useful to at least understand what is this instruction based on VSEPC or VSTVAL. All others probaly there is no need to have printed, I don't remember that I used them during debug. > >> + printk("\nHypervisor CSRs\n"); >> + >> + print_csr(CSR_HSTATUS); > Above you special-case VSCAUSE, but here you re-read HSTATUS. Because above I re-used 'cause' then for decode_cause(). > >> + printk("\t\thstatus.VTSR=%d\n", !!(hstatus & HSTATUS_VTSR)); >> + printk("\t\thstatus.VTVM=%d\n", !!(hstatus & HSTATUS_VTVM)); >> + printk("\t\thstatus.HU=%d\n", !!(hstatus & HSTATUS_HU)); >> + printk("\t\thstatus.SPVP=%d\n", !!(hstatus & HSTATUS_SPVP)); >> + printk("\t\thstatus.SPV=%d\n", !!(hstatus & HSTATUS_SPV)); >> + printk("\t\thstatus.GVA=%d\n", !!(hstatus & HSTATUS_GVA)); > Might these better be put on a single line, e.g. in the form > > [VTSR SPVP SPV] > > i.e. enumerating the (interesting) set bits textually? Agree, visually it would be better. > >> + print_csr(CSR_HGATP); >> + print_csr(CSR_HTVAL); >> + print_csr(CSR_HTINST); >> + print_csr(CSR_HEDELEG); >> + print_csr(CSR_HIDELEG); >> + print_csr(CSR_HSTATEEN0); >> +} >> + >> static void do_unexpected_trap(const struct cpu_user_regs *regs) >> { >> unsigned long cause = csr_read(CSR_SCAUSE); >> >> printk("Unhandled exception: %s\n", decode_cause(cause)); >> >> + dump_csrs(cause); >> + >> die(); >> } > Apart from CSRs, how about also dumping GPRs? Maybe, it is a good idea and it would be nice to add them. I just almost never needed them for debugging so I am not printing them. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Jan 15 15:17:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 15:17:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205291.1519611 (Exim 4.92) (envelope-from ) id 1vgP62-00019s-DT; Thu, 15 Jan 2026 15:17:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205291.1519611; Thu, 15 Jan 2026 15:17:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgP62-00019l-AR; Thu, 15 Jan 2026 15:17:14 +0000 Received: by outflank-mailman (input) for mailman id 1205291; Thu, 15 Jan 2026 15:17:13 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgP61-00019f-9H for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 15:17:13 +0000 Received: from mail14.wdc04.mandrillapp.com (mail14.wdc04.mandrillapp.com [205.201.139.14]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 40a15334-f225-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 16:17:06 +0100 (CET) Received: from pmta16.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail14.wdc04.mandrillapp.com (Mailchimp) with ESMTP id 4dsRRP2W5Zz8XRwLR for ; Thu, 15 Jan 2026 15:17:05 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id cc88d528486c4ba3b4af9c7aaf14be2a; Thu, 15 Jan 2026 15:17: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: 40a15334-f225-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1768490225; x=1768760225; bh=E4u2qur7qFOqEXURQqrbQx6Ra8vsG2nE9Sz9kh4hOSQ=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=kxbSX9UIvzX0Nbna5a+R+b6UE1bLk1Ffez+ROzGGxkLnO2yzWNoawy+Um6PgC4Q/H ZTVT+n9UAeFWumA5fbphYi0oleWhk6DzdKm+Fp4g/wMjzv13Ls2sR3QV88eE8a5HH2 cV8fSULVjdFFNkB9F52qVjiUd0COj4JGIdSCj16atss00AhP0T7599RoX8BF01H0O+ UE8AUbqIzQLSqpdhzDmOxWjnHpjYb8hYf/SG3SW2BMeEjMPj9FWCtYI2ealZOGl41J lO30T7cf0e9BKIrZrlp2PbokROv2SyZ47Jnh4oj5rYqCgDYuM38CywiUctFmF+MGtU Nnva2MJdtgGTA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1768490225; x=1768750725; i=julian.vetter@vates.tech; bh=E4u2qur7qFOqEXURQqrbQx6Ra8vsG2nE9Sz9kh4hOSQ=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=HbS7nfScM3qXoSz7E1wNpMx2rgzPnlNKNSibgG6QN2uSVUtuNkNKvMaQo53dSHnXu kHJXsTyp/Oz263SUQKmFiwJuG15xe3Q78VUV9PQZieeEJZea2i9Zb9n/1g+/4Rz3sI dVcoXVAIEWtP2RCUGgoM4FoTmNXZNNL/+z8dWOc74Ph4ndnx5d0PuQV1TGUfS/6uyZ 5gM6GwYlFUvCuelkWEaoOkNMULVeJd22E3JT7xDGEU1Lit13kMQW9XGyWj07NVQwRa k4mDKCpsjWwM6fT6q/lefTP2zGu4w0VVaT/BXiOXNLKsBuCZc1cRa+FPsnm3l1QjdL vvGW8+U6ekVBw== From: "Julian Vetter" Subject: =?utf-8?Q?[PATCH]=20xen:=20Move=20NX=20handling=20to=20a=20dedicated=20place?= 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: 1768490223908 To: xen-devel@lists.xenproject.org Cc: "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Daniel P . Smith" , "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" , "Julian Vetter" Message-Id: <20260115151658.3725784-1-julian.vetter@vates.tech> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.cc88d528486c4ba3b4af9c7aaf14be2a?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260115:md Date: Thu, 15 Jan 2026 15:17:05 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Currently the CONFIG_REQUIRE_NX prevents booting XEN, if NX is disabled in the BIOS. AMD doesn't have a software-accessible MSR to re-enable it, so there is nothing we can do. The system is going to die anyway. But on Intel NX might just be hidden via IA32_MISC_ENABLE.XD_DISABLE. But the function to re-enable it is called after the check + panic in efi_arch_cpu. So, this patch removes the early check and moves the entire NX handling into a dedicated place. Signed-off-by: Julian Vetter --- xen/arch/x86/boot/head.S | 56 -------------------------------- xen/arch/x86/boot/trampoline.S | 5 ++- xen/arch/x86/cpu/intel.c | 4 --- xen/arch/x86/efi/efi-boot.h | 12 ------- xen/arch/x86/include/asm/setup.h | 2 ++ xen/arch/x86/setup.c | 46 ++++++++++++++++++++++++++ 6 files changed, 50 insertions(+), 75 deletions(-) diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S index 77bb7a9e21..7fb7fb1351 100644 --- a/xen/arch/x86/boot/head.S +++ b/xen/arch/x86/boot/head.S @@ -133,7 +133,6 @@ multiboot2_header: .Lbad_ldr_nbs: .asciz "ERR: Bootloader shutdown EFI x64 boot services!" .Lbad_efi_msg: .asciz "ERR: EFI IA-32 platforms are not supported!" .Lbag_alg_msg: .asciz "ERR: Xen must be loaded at a 2Mb boundary!" -.Lno_nx_msg: .asciz "ERR: Not an NX-capable CPU!" .section .init.data, "aw", @progbits .subsection 1 /* Put data here after the page tables (in x86_64.S). */ @@ -165,11 +164,6 @@ early_error: /* Here to improve the disassembly. */ .Lnot_aligned: mov $sym_offs(.Lbag_alg_msg), %ecx jmp .Lget_vtb -#ifdef CONFIG_REQUIRE_NX -.Lno_nx: - mov $sym_offs(.Lno_nx_msg), %ecx - jmp .Lget_vtb -#endif .Lmb2_no_bs: /* * Ditto. Additionally, here there is a chance that Xen was started @@ -547,56 +541,6 @@ trampoline_setup: bt $cpufeat_bit(X86_FEATURE_LM),%edx jnc .Lbad_cpu - /* - * Check for NX - * - If Xen was compiled requiring it simply assert it's - * supported. The trampoline already has the right constant. - * - Otherwise, update the trampoline EFER mask accordingly. - */ - bt $cpufeat_bit(X86_FEATURE_NX), %edx - jc .Lgot_nx - - /* - * NX appears to be unsupported, but it might be hidden. - * - * The feature is part of the AMD64 spec, but the very first Intel - * 64bit CPUs lacked the feature, and thereafter there was a - * firmware knob to disable the feature. Undo the disable if - * possible. - * - * All 64bit Intel CPUs support this MSR. If virtualised, expect - * the hypervisor to either emulate the MSR or give us NX. - */ - xor %eax, %eax - cpuid - cmp $X86_VENDOR_INTEL_EBX, %ebx - jnz .Lno_nx - cmp $X86_VENDOR_INTEL_EDX, %edx - jnz .Lno_nx - cmp $X86_VENDOR_INTEL_ECX, %ecx - jnz .Lno_nx - - /* Clear the XD_DISABLE bit */ - mov $MSR_IA32_MISC_ENABLE, %ecx - rdmsr - btr $2, %edx - jnc .Lno_nx - wrmsr - orb $MSR_IA32_MISC_ENABLE_XD_DISABLE >> 32, 4 + sym_esi(trampoline_misc_enable_off) - - /* Check again for NX */ - mov $0x80000001, %eax - cpuid - bt $cpufeat_bit(X86_FEATURE_NX), %edx - jnc .Lno_nx - -.Lgot_nx: -#ifndef CONFIG_REQUIRE_NX - /* Adjust EFER given that NX is present */ - orb $EFER_NXE >> 8, 1 + sym_esi(trampoline_efer) -.Lno_nx: -#endif - /* Stash TSC to calculate a good approximation of time-since-boot */ rdtsc mov %eax, sym_esi(boot_tsc_stamp) diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S index a92e399fbe..8e8d50cbdf 100644 --- a/xen/arch/x86/boot/trampoline.S +++ b/xen/arch/x86/boot/trampoline.S @@ -144,10 +144,9 @@ gdt_48: GLOBAL(trampoline_misc_enable_off) .quad 0 -/* EFER OR-mask for boot paths. SCE conditional on PV support, NX added when available. */ +/* EFER OR-mask for boot paths. SCE conditional on PV support. */ GLOBAL(trampoline_efer) - .long EFER_LME | (EFER_SCE * IS_ENABLED(CONFIG_PV)) | \ - (EFER_NXE * IS_ENABLED(CONFIG_REQUIRE_NX)) + .long EFER_LME | (EFER_SCE * IS_ENABLED(CONFIG_PV)) GLOBAL(trampoline_xen_phys_start) .long 0 diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c index b76797cb9a..e8cf51e853 100644 --- a/xen/arch/x86/cpu/intel.c +++ b/xen/arch/x86/cpu/intel.c @@ -351,10 +351,6 @@ static void cf_check early_init_intel(struct cpuinfo_x86 *c) if (c->x86 == 15 && c->x86_cache_alignment == 64) c->x86_cache_alignment = 128; - if (c == &boot_cpu_data && - bootsym(trampoline_misc_enable_off) & MSR_IA32_MISC_ENABLE_XD_DISABLE) - printk(KERN_INFO "re-enabled NX (Execute Disable) protection\n"); - intel_unlock_cpuid_leaves(c); /* CPUID workaround for Intel 0F33/0F34 CPU */ diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h index 0194720003..8dfd549f12 100644 --- a/xen/arch/x86/efi/efi-boot.h +++ b/xen/arch/x86/efi/efi-boot.h @@ -748,18 +748,6 @@ static void __init efi_arch_cpu(void) if ( (eax >> 16) == 0x8000 && eax > 0x80000000U ) { caps[FEATURESET_e1d] = cpuid_edx(0x80000001U); - - /* - * This check purposefully doesn't use cpu_has_nx because - * cpu_has_nx bypasses the boot_cpu_data read if Xen was compiled - * with CONFIG_REQUIRE_NX - */ - if ( IS_ENABLED(CONFIG_REQUIRE_NX) && - !boot_cpu_has(X86_FEATURE_NX) ) - blexit(L"This build of Xen requires NX support"); - - if ( cpu_has_nx ) - trampoline_efer |= EFER_NXE; } } diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h index b01e83a8ed..16f53725ca 100644 --- a/xen/arch/x86/include/asm/setup.h +++ b/xen/arch/x86/include/asm/setup.h @@ -70,4 +70,6 @@ extern bool opt_dom0_msr_relaxed; #define max_init_domid (0) +void nx_init(void); + #endif diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index 27c63d1d97..608720b717 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1119,6 +1119,50 @@ static struct domain *__init create_dom0(struct boot_info *bi) return d; } +void __init nx_init(void) +{ + uint64_t misc_enable; + uint32_t eax, ebx, ecx, edx; + + if ( !boot_cpu_has(X86_FEATURE_NX) ) + { + /* Intel: try to unhide NX by clearing XD_DISABLE */ + cpuid(0, &eax, &ebx, &ecx, &edx); + if ( ebx == X86_VENDOR_INTEL_EBX && + ecx == X86_VENDOR_INTEL_ECX && + edx == X86_VENDOR_INTEL_EDX ) + { + rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable); + if ( misc_enable & MSR_IA32_MISC_ENABLE_XD_DISABLE ) + { + misc_enable &= ~MSR_IA32_MISC_ENABLE_XD_DISABLE; + wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable); + + /* Re-read CPUID after having cleared XD_DISABLE */ + boot_cpu_data.x86_capability[FEATURESET_e1d] = cpuid_edx(0x80000001U); + + /* Adjust misc_enable_off for secondary startup and wakeup code */ + bootsym(trampoline_misc_enable_off) |= MSR_IA32_MISC_ENABLE_XD_DISABLE; + printk(KERN_INFO "re-enabled NX (Execute Disable) protection\n"); + } + } + /* AMD: nothing we can do - NX must be enabled in BIOS */ + } + + /* Enable EFER.NXE only if NX is available */ + if ( boot_cpu_has(X86_FEATURE_NX) ) + { + if ( !(read_efer() & EFER_NXE) ) + write_efer(read_efer() | EFER_NXE); + + /* Adjust trampoline_efer for secondary startup and wakeup code */ + bootsym(trampoline_efer) |= EFER_NXE; + } + + if ( IS_ENABLED(CONFIG_REQUIRE_NX) && !boot_cpu_has(X86_FEATURE_NX) ) + panic("This build of Xen requires NX support\n"); +} + /* How much of the directmap is prebuilt at compile time. */ #define PREBUILT_MAP_LIMIT (1 << L2_PAGETABLE_SHIFT) @@ -1159,6 +1203,8 @@ void asmlinkage __init noreturn __start_xen(void) rdmsrl(MSR_EFER, this_cpu(efer)); asm volatile ( "mov %%cr4,%0" : "=r" (info->cr4) ); + nx_init(); + /* Enable NMIs. Our loader (e.g. Tboot) may have left them disabled. */ enable_nmis(); -- 2.51.0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Thu Jan 15 15:21:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 15:21:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205323.1519621 (Exim 4.92) (envelope-from ) id 1vgP9i-0002r5-V4; Thu, 15 Jan 2026 15:21:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205323.1519621; Thu, 15 Jan 2026 15: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 1vgP9i-0002qy-SP; Thu, 15 Jan 2026 15:21:02 +0000 Received: by outflank-mailman (input) for mailman id 1205323; Thu, 15 Jan 2026 15:21: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 1vgP9h-0002qd-6A for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 15:21:01 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c9c36978-f225-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 16:20:56 +0100 (CET) Received: from BL0PR05CA0017.namprd05.prod.outlook.com (2603:10b6:208:91::27) by DS7PR12MB9525.namprd12.prod.outlook.com (2603:10b6:8:251::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Thu, 15 Jan 2026 15:20:52 +0000 Received: from BL6PEPF0001AB75.namprd02.prod.outlook.com (2603:10b6:208:91:cafe::17) by BL0PR05CA0017.outlook.office365.com (2603:10b6:208:91::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.2 via Frontend Transport; Thu, 15 Jan 2026 15:20:47 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BL6PEPF0001AB75.mail.protection.outlook.com (10.167.242.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Thu, 15 Jan 2026 15:20:49 +0000 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.2562.17; Thu, 15 Jan 2026 09:20:49 -0600 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; Thu, 15 Jan 2026 09:20:48 -0600 Received: from [172.28.136.14] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Thu, 15 Jan 2026 07:20:47 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c9c36978-f225-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=p3/aiv0CjILA943Oe+m+0rNs994WoeGGaaNTid+VM8aIBfXGVknLop+NqX64UFDIrEAzF3tf7LU7L8MHkyHOE1E1AMTbyKYfrYP4zb1pyhotQrgDoMfKBDKA5d+oL06Sxj0nL1tIyGffvj8PzSIL1oJ5zzapKjPnG9E5BASdU2yWM3iDdlgU6U4/Zoc/QZXm8AZgAA1WU6FsoBsI4djPlLUCFjUgnnIY58TZRWSvfW5l6H+U/F3a8Cc1LZb2A1wb1bEY9+AjGEYsmDBPozddBb4xGMcCnriDoDZxyRrvocwCwTC24dj4Va+topPblikGxACJa1rSmBbotgEtGzMyVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=AT0YncTFlrxicix8PIWQyUS6zwBdKYeczTKCyPIeycY=; b=hoFVyBm1FjIgvLf8HGFLtbAX2KgHlMakLrFNOO6zgZXV3Y8d08yJPWBGkLSblt+h3JAqZXAzcvjw0N84+lUwMo2SoSoiskV4vI8FdgOlPyENY+oLApexrVNVjYxdbVDc5fvq5GwR7XaKdAat/c9dB+JH0b5NuHVw9vXLR+x7iH7EMV51QjkK2L3+PE9Ha3Qt+ydRml1/kXo+fAQMwIzZfoB2157oBDNRZajKGtDthFyXB4u84jHrOhrCQvmg+bgN3eGESKYovKTVd/ESpwa4Fj3bEAT3eZhR0Ejm+obno6jc4xU1MWe/DY1yxt/zod2WQzoosrjROgqPvpHmVmBy+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=AT0YncTFlrxicix8PIWQyUS6zwBdKYeczTKCyPIeycY=; b=Who3EB/c0i2hsDukJzlNYArfcRQ3rbgpFQC9XVPRaCsX3pZ+gHP88EAsa3JE9PoA7ur8Og1OxCZX7qgU6MD54N44JEnGQs5CbdMyQGTFfAnWkwWQxrLPm14NSv4zWm18mSGSHfnHMj5/JZnFNyvowSKIfIOXkUmsb7G6QNdg20Y= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: Thu, 15 Jan 2026 10:08:15 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 4/6] xen/p2m: move xenmem_access_to_p2m_access() to common p2m.c To: Penny Zheng , CC: , Tamas K Lengyel , "Alexandru Isaila" , Petre Pircalabu , Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , "Michal Orzel" , Julien Grall , "Stefano Stabellini" References: <20260115092841.2651224-1-Penny.Zheng@amd.com> <20260115092841.2651224-5-Penny.Zheng@amd.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <20260115092841.2651224-5-Penny.Zheng@amd.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: BL6PEPF0001AB75:EE_|DS7PR12MB9525:EE_ X-MS-Office365-Filtering-Correlation-Id: aed075ec-8b50-4dde-5986-08de5449aa0a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|36860700013|7416014|82310400026; X-Microsoft-Antispam-Message-Info: =?utf-8?B?M1A1V05sNVZqVDJVRVFUZ3BjQ3UzNnZJOTIvcC84Z2xFWHZqQUNWYy9pNEpk?= =?utf-8?B?bjRHaHZ2aEU4TXVRZWFRMnlVUWlYSjNadTQzWHBHVWhSeTZmT0hkUEVnVmhz?= =?utf-8?B?OEdJejIrUDM4UU95OUNPZ2ZWcmhUdURTajlBU3RVWDNjWWFHaCtLTGJVdXVM?= =?utf-8?B?MDdFVFh0TlZHdWRheHFCMmxYN1FHOTJCSFowUnE4bmxxTlRZLzdHSVdZNkQy?= =?utf-8?B?OWU2c3dLT2Rqd2hqZE9jWUpZQWlUa2U4ZWNpTElaZFNUTU9IZ0tvTUd6WmNr?= =?utf-8?B?VHRHTWV1MlR3OUJtdzJJMFdJZ0tFNEJBUU10NXlZM20yTlFaMlNWU1BBSXkx?= =?utf-8?B?R2NpRVowWHRaREN3elZTdE1nNXBIeFVMdTJYelpwUDlIRVUzcmxmUTZ0cEF3?= =?utf-8?B?RGUwWDBrMTIxUXUwcFVNVmlURVlBTHRKbVVCd2UzWFFVWjhUais2Z3dRNkg5?= =?utf-8?B?UDZnVUF1WUkydFBSVGptZGFYVmhwV1hsWmlBNTltUUNMUjJNV3hPTVA0cFFV?= =?utf-8?B?dFFyalp6Uk11Mi9BN2hPSm1HSlZ0bThxS1F0VHE2RHkwcTZ2LzNlQ2p5N1hL?= =?utf-8?B?bVNnRmdVb1p6TmQ5dGpaU0FiSXM2VjFmcDdXMldQOEwzaXc3T3lSYllINzNN?= =?utf-8?B?M1VXNmVuck1yeUdKODNEeDVlbUFIUnJMOThpR1FZQVI4SlNkUWJRbzRLMFhI?= =?utf-8?B?b1dPa0k5bGN0NUU3akhoSDByb2U4dm95U0czbVNmTEJHa05EQWtnVUl3bWx4?= =?utf-8?B?SDh4LzNnb2J6OUtva0ptWk1aWW1JNm1leE9xSmViSG9kZFFxbjBiczVZRXor?= =?utf-8?B?RFJWaXRrZS96bG1vTCt6WUNTZDVnK1g0cXo3eC9SbEJYdmhvV3g5Rzd1R3hl?= =?utf-8?B?RkZaZjFtNWd4R1VES2wvdWJCVklXSHdpVlU5UndzMUZkMWNOZ2JFaHpwQjY2?= =?utf-8?B?UFJDb0xtK2FZcE9mOFRNWDdqSi85cVVtdFR1WG5DZmZPVFl2RDNMVGpLTUk3?= =?utf-8?B?RWhTUy9JMWRXSit5OXEzQ2NKOXpFOXF2QUZKOHhtdVI3WW9CQjlGb0xoTjRo?= =?utf-8?B?RzA5ZTI1VWY5UWt5R2xQNENjZGtueXRuSk9hbnYrTUlNNWFzaHhQelFaOE42?= =?utf-8?B?VUtrQWNkSE5iSHNkQ1hwK1BqK1BXY2xHWEtUU2dSdERXV2xwSmZnSXN4NFVE?= =?utf-8?B?Zk4rbDcwOUFRelU2U0U3SEk0bWsrSGF1SEVVUGZ4SGNJcTY4WmJ3THVmTC9x?= =?utf-8?B?bE8wT2JVb0RrTTZmT2hrQWlVOFQrMVlyUnNHL3Q0d3hZbFR3ZGtCSVIyVlR6?= =?utf-8?B?cGp6dGVNMDh5TXlyanptV2dTNzVZYnVqS1hqc2Y3d0VRNGhzRTlLdFYzUVFI?= =?utf-8?B?ZnNXS09KcGJNc0htdGZFb1VYUFRLZkpBYkV3OEJLcHNlYjhMTnFiS09MS2Ro?= =?utf-8?B?VFNnOU00UlRFN3h6SkNpbHZaNUk1K3Q4RFJMdGdTOHpLcXVxWU53YUJwWUpl?= =?utf-8?B?VTZDd2xCQ3F5MXNqMEZlRlZEckRUVWdnc2NHRUVLbmZWV0VJZjB5bjAwaWdy?= =?utf-8?B?SjJrMURrVDI3RGtQZFM3bDlObHZ3elRBUEdUUVNnY0U5TjhUcWNJY1NwU3I5?= =?utf-8?B?SDBiUzVYV3ZUSTVnQ0dpZnRqUUIzekRqbVg3QXZ5RVpLZXFSY3NYNms0ZjVV?= =?utf-8?B?YjVqaURPQU9PckV1NC9nN3o4cWRnemhQUHdZaDIxU0Q4aVRHMG9hS255S01Y?= =?utf-8?B?ZVVzcklhMWhiaStYYmNUaXRjcm0xNUc4Z280M0VkOHJzV0dOdU9ORDdaVzB1?= =?utf-8?B?TWZSMkVQOVhsSlk2eHdQNG02cUZ0UnNBSUxXYXBtUnFHalFEY3kwQWUxYzlP?= =?utf-8?B?eldIRHdSV1l1VVBnSGF3bGdKZmI1WFc5M1BNM3RKVk80NXRuVmJqSWxvVXRm?= =?utf-8?B?OTNRaXBZTjdpNHYwTW1sVmpyeHpZVmpmcm80ZTRYcEdUOEpiN0RwSEtibGxI?= =?utf-8?B?aWhDdW1rUEpZSUI3VlhuS2YySWM0M1lXR1ZCaVZEcU5WQzhGK29uQXEzb2dQ?= =?utf-8?B?d3cyeVorTlNkWTVkYS9EMnVQMW9mMnJUcC9HTlBZbUIvbkVaeFN6WlRnZTY1?= =?utf-8?B?aGhBVm5XaTRYb1BiSFlaQVRieUlNTGdJYUdWeXZvWTB5QmREeFlnMlFrSFky?= =?utf-8?B?ZFV5cnprTUFZMFBlNUZkaEx0TDNOMGoxZ3JTUlIwMmd6WTBlL2NMSnczMVV4?= =?utf-8?B?QXRGZmpNT2lXZGdyTlNHMDRsU3N3PT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(36860700013)(7416014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 15:20:49.4881 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: aed075ec-8b50-4dde-5986-08de5449aa0a X-MS-Exchange-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: BL6PEPF0001AB75.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB9525 On 2026-01-15 04:28, Penny Zheng wrote: > Memory access and ALTP2M are two seperate features, while both depending on > helper xenmem_access_to_p2m_access(). So it betters lives in common p2m.c, > other than mem_access.c which will be compiled out when VM_EVENT=n && ALTP2M=y. > Guard xenmem_access_to_p2m_access() with VM_EVENT || ALTP2M, otherwise it > will become unreachable when both VM_EVENT=n and ALTP2M=n, and hence > violating Misra rule 2.1 > We also need to move declaration from mem_access.h to p2m-common.h > An extra blank line is inserted after each case-block to correct coding > style at the same time. > > Signed-off-by: Penny Zheng > Acked-by: Jan Beulich Reviewed-by: Jason Andryuk From xen-devel-bounces@lists.xenproject.org Thu Jan 15 15:21:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 15:21:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205332.1519631 (Exim 4.92) (envelope-from ) id 1vgPAL-0003KT-7T; Thu, 15 Jan 2026 15:21:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205332.1519631; Thu, 15 Jan 2026 15: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 1vgPAL-0003KM-40; Thu, 15 Jan 2026 15:21:41 +0000 Received: by outflank-mailman (input) for mailman id 1205332; Thu, 15 Jan 2026 15: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 1vgPAJ-000379-NW for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 15:21:39 +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 e2dc7fe0-f225-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 16:21:38 +0100 (CET) Received: from BN9P223CA0004.NAMP223.PROD.OUTLOOK.COM (2603:10b6:408:10b::9) by LV9PR12MB9808.namprd12.prod.outlook.com (2603:10b6:408:2e7::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.6; Thu, 15 Jan 2026 15:21:34 +0000 Received: from BL6PEPF0001AB74.namprd02.prod.outlook.com (2603:10b6:408:10b:cafe::cf) by BN9P223CA0004.outlook.office365.com (2603:10b6:408:10b::9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.5 via Frontend Transport; Thu, 15 Jan 2026 15:21:20 +0000 Received: from satlexmb08.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.9520.1 via Frontend Transport; Thu, 15 Jan 2026 15:21:33 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 15 Jan 2026 09:21:33 -0600 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 15 Jan 2026 07:21:33 -0800 Received: from [172.28.136.14] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Thu, 15 Jan 2026 07:21:32 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e2dc7fe0-f225-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QzBZ8iQPP5BLvfZpeDGUQkjTpS6k3tyr6xQZTQSdmsANmRyHvLw7lJ5RDNO+j8v2hzf2rQEBTG0/wXTrHBAQzqmny4/0cWhoAMiFTdub8/uez9+RX0/oih0FkeR5l58wj0FuRg1ZZX2ArUcX6fHrNU8Zy/UyZWQamxo/P3HUBwDLKQkT/EOSklLSm88Oa9qe6rgi0TrRP/kPx54AVWxVNZzQ3AM8VOlK1tQ/Lt9HTHdWAAHKNtC8nARpnKPr4A+Q2BD+MVAooXENCsl9lDilyTpmrMJqV+WaUBWHBrwW0AM1VVzHLNH4Jyta52jyCghhX0tAU5rHkm+qNXKXpkEjSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eunTBxQUoCuFapaUeyOHSujr8tPvlHJRrRm31BHHiLU=; b=rk5RLGKna8I5jCMHYY78CmCBNG0BGZXqp2wLcfZMEZnjHXDRM9Ruy8qxJC+4BPkCfAVHzQ56Q6E5GEkuHj9YWhX0OILSRQKbevv9UC1Z5fA58DfjnzL79+HkZv2QKtH3UEfovaCh+L/Ow1V9+HImPXH7A/ZhJWq5nKO3DdOgZ+BK6IuFcuHUc8d55WEwwsElh6VRrHD2s2u5WK6XQJls5vSGxwK8RNeJYaU9JgBVY/J/RG6svQNFLswyuTT3yuo5dZsKH7Zy/iLatcW4pQIJVwz5WY7PkuJ+OKgdzhWCWm08GCZo39k90mv2x2xNjx8cq8z1K4xkB9QH07mQz8TtDQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eunTBxQUoCuFapaUeyOHSujr8tPvlHJRrRm31BHHiLU=; b=o+Aqj6bhxPWQQUVZew+RBymS0+MTwouO1IQJKwUl/gfBd9/yOONg1stFr6o+KJRlTl1ChkhtyP/P8x6nkQR7q5h/QTi7UEBY787j2TtMY1J8Q85J+TxDTViXPMPOkoUATgVlOUZ6Lr0nWAcGwqq26kszq1Ysl9skh/Gr0pVJHtE= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <84943630-0f68-4097-a5a4-4aba17c0fb86@amd.com> Date: Thu, 15 Jan 2026 10:09:00 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 5/6] xen/mem_access: wrap memory access when VM_EVENT=n To: Penny Zheng , CC: , Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Tamas K Lengyel , "Alexandru Isaila" , Petre Pircalabu References: <20260115092841.2651224-1-Penny.Zheng@amd.com> <20260115092841.2651224-6-Penny.Zheng@amd.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <20260115092841.2651224-6-Penny.Zheng@amd.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB74:EE_|LV9PR12MB9808:EE_ X-MS-Office365-Filtering-Correlation-Id: df4d648f-03c6-46d6-7c97-08de5449c48a 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?WHVJZ0RLa1RIdDN4VTZpN1N3ZitGUGNtN3M4ckg3UG4vaUdkUklxakRZNFhu?= =?utf-8?B?Rml2N1gzSXlVYXRHaEtnZWJHRGY3MG5xVEx5MVZIOFhsZWh0KzVsNHVzT2VO?= =?utf-8?B?ZmZHbXVhaEUweWtsVk93K2NVVkQvNkJQdkRGWklBbTI4aTkyV2N6U2ppYlBa?= =?utf-8?B?YWJtZUV6MFpDMkNta3lwNEF3WTkvdWFjZzNkRGhtVUpxUE9xYWc4Y3gvdWJq?= =?utf-8?B?QWRkOGxhS0lmSVF5MGZsdjd0VUdYWnJTNnhyZUNIQ21WNTl1aGgzV3IzSTV0?= =?utf-8?B?TDNIbVBMZ1F4M0JlZTFpYjRHYkllMG9Vc0tzNmFnSWs4a1JVVGRVb0RWdmll?= =?utf-8?B?VnplWUIvRS9SVHJtM3AvMXd1LysvbG5sZklYTXhrSm1IOWMzM2Y3V0s2endz?= =?utf-8?B?Y3V4UEMxV3pacFNBd0ZRYzU5cWh3YkNScmkzQzRKT2M0bkV3a0lxQjMwd3gv?= =?utf-8?B?N0lSZE95aTQ1b0VwSjFYd1RzQi91NXRYSGZlSWgrUEJDUmNPeTI0QjRHY3JG?= =?utf-8?B?ZFg1S0VUWkxGMzNEc2IyM2FicDBxK1FnbUo3UmlnejdWZkR1ditBQ2tzNGp3?= =?utf-8?B?THVxVjZJbXUyVnByMXRPUGtodGJPaVZ1cXJCNkIwVjdHYjZKaXdOWm1sTnJs?= =?utf-8?B?RW5FcjRLOFA3SEw3TEpGeXhWYy9jdS80aTBwdFlEN0lTYmc3ZlVjN1V6WWhS?= =?utf-8?B?S0psMFJMd1lrZzk5WnRjYjVSaGxQSGZqVnoxZ3RpaEpCYkEwVEdJc0lIQVAv?= =?utf-8?B?YzUvRC80bFpTeEVuU0Rma3plVlN1emFjQWpXR2NCdU9wWXcxSjdkQ3V2dEFE?= =?utf-8?B?amIwY2VQMnpHNldNREdTS0ExemNEVVNlaGd2Q0FwZm56U3l0QVBhQkJyNEM2?= =?utf-8?B?Tk0wSkpyUkdNNXJ2bFlTTTlPMC83U0plUlJHcUhlWVVTY2U0NGdRSVpkdTN2?= =?utf-8?B?a3lhRGlsNHEyNXlKNXIwd0FHODVDMXRZY1FuKzVkeHNHY28vendQQjJ0VWZx?= =?utf-8?B?bFdCRWJTZ2o1VDRicmxZZFZXL01zc2kzS0tEa3dPTlJHMFY2OTJ3SEh1TE9M?= =?utf-8?B?M1puQjRNUUloaHV1ZHZFeGp4czMwSjlydHhCZ0U2VGNYNUNiOFFPVDBZVHlG?= =?utf-8?B?RXpqVEcwbVM5UEpNUWNJQlAxVEZLaHZkOGQ4enhteVpXbk9IZXJWMkNxNVJ5?= =?utf-8?B?YmJhVjVnYnVqeVMrQlk1Q0RIZnpneFFqWVZVU1hBeVB0YmdrZ0lFMStrRlk5?= =?utf-8?B?UU9JNjJjZmMvL2RrT1Ezd1drN0FtVFdmV01iVldsb3FxMEszNTBiSENoZGsx?= =?utf-8?B?ZU9TMVhoVERGYWYwdEl6eDBOZElvZ3ppNVVZSm85SENRcnk2elo2cmVCeVcw?= =?utf-8?B?enNnZzdjbjArWUY5TWRmNnhBS3RiT1hKdGRTZCtEOFBjQ2xwbEJybnl5cVh0?= =?utf-8?B?d0l5MUZubVY5R1FBRXJTUHYxcUhxL3BuT2wrT1oxQXNhb3UyYS9mc0RscERP?= =?utf-8?B?eW8wamN3WXdyUjlSVDF0YmN5cjFuL1hVeG9jSGpBRUh1UnRac2RMc0lJemxG?= =?utf-8?B?Ui9xdmg2RDZRaEtIVm5ORytDb2h5aTU4NG16bjVCR0duSHVxcmx6YWFhZUR5?= =?utf-8?B?ejR5YUYrWDRXV1lUdVczbHpoQUROZXVsRW9FaGdzZWNaTjRYYWd3YzdZeHcw?= =?utf-8?B?azNkMWU1VDBXcG84aHRMSTB2cTFMLzRxdjdCOGc2eUd1QzF3ZG9VeUVKNUc3?= =?utf-8?B?VWRVSWhybGdINC81S1BsVjFvaUNDeHJtOGhZd2d6MENhd3FKcG5GSm9tcFFt?= =?utf-8?B?bkRFbjNSdTZmMFo3T2RJZUE4T1ZOcGFsdHF4YmV1Nm0zWFVhaGQrVGpHbU42?= =?utf-8?B?WnA5WkF0R29MWnBwcjd0NWgrZGlFUWlDVEVLRGJXakZING9wcFh1Q2I4TWxW?= =?utf-8?B?azllallnMVhjc2tvbzVTMUNURVhMem1nelJwMVV3TVlWeFVKVWowNDMxMVM1?= =?utf-8?B?VURvYlNIOHdRYVdlSkRnN0x3RE5sVTg2bUJLbWZwcFUvSTM4dlJXKytTWnJI?= =?utf-8?B?cSs0NVROcnRwdmZ2SUdON0kzc202dXpmMlBtdU10Q2Y2Q0ZIMDBUYVc4VVZ2?= =?utf-8?B?ZWJWeFNFOHlLVHNQbTk4S0t3eThwU21TV2ZrUzhjVHZYKzEwUVF6djIwZkd1?= =?utf-8?B?UFBqWU9kR0l3YjUzYjJucUVWeitrY1p4c3hkSkE3b1B0d21lS2ZEcWxoMVJG?= =?utf-8?B?SDZ3OGdybjdEd0VqRWRRVSt6WjBnPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 15:21:33.9505 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: df4d648f-03c6-46d6-7c97-08de5449c48a X-MS-Exchange-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: BL6PEPF0001AB74.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV9PR12MB9808 On 2026-01-15 04:28, Penny Zheng wrote: > Feature memory access is based on vm event subsystem, and it could be disabled > in the future. So a few switch-blocks in do_altp2m_op() need > vm_event_is_enabled() condition check to pass compilation when ALTP2M=y and > VM_EVENT=n(, hence MEM_ACCESS=n), like HVMOP_altp2m_set_mem_access, etc. > Function p2m_mem_access_check() still needs stub when VM_EVENT=n to > pass compilation. > Although local variable "req_ptr" still remains NULL throughout its lifetime, > with the change of NULL assignment, we will face runtime undefined error only > when CONFIG_USBAN is on. So we strengthen the condition check via adding > vm_event_is_enabled() for the special case. > > Signed-off-by: Penny Zheng > Acked-by: Jan Beulich Reviewed-by: Jason Andryuk From xen-devel-bounces@lists.xenproject.org Thu Jan 15 15:28:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 15:28:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205348.1519640 (Exim 4.92) (envelope-from ) id 1vgPH6-00048D-RQ; Thu, 15 Jan 2026 15:28:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205348.1519640; Thu, 15 Jan 2026 15:28: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 1vgPH6-000486-Oq; Thu, 15 Jan 2026 15:28:40 +0000 Received: by outflank-mailman (input) for mailman id 1205348; Thu, 15 Jan 2026 15:28:38 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgPH4-000480-SG for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 15:28:38 +0000 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [2a00:1450:4864:20::333]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id dbf67a32-f226-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 16:28:36 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-47eddddcdcfso5733585e9.1 for ; Thu, 15 Jan 2026 07:28:36 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47f428cebdcsm51838595e9.12.2026.01.15.07.28.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 07:28:35 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dbf67a32-f226-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768490916; x=1769095716; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=5oZtXamjWgQelXQM3KP8RjGd9ICs7N/ygiCiSmbuh6E=; b=Dq0CdOGEBjOeLEkgH5egDZFJyJaISebcDi18uT/wXGk6Z5O6dFP4HmOgXjky5u0Fi1 ef9ho0w3XZfcmTcC6kjC+gCY44cLIqSXC+hkFCxpewfZ/0ZMcIOo1MxgWB6LYfSlYLYK eUUxP7UaXW2KqALwI+arFK0C63yLVfuva9yDj2/rUPzrxij2wykN0GhBvHi8eCCl7smt JHK4UmEhQaMJTXlSScQ6EVnCPu439qGBIipu7MHpCMRmFsO3hpi9LsOVYb5yrAR5cPOk G3l0/Y/JI4DMPXhhQvKsVojpFG+Kn3QTubqecnp5GTFbeNEhsoex1IFEgFeUQ+VMyg5G h/Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768490916; x=1769095716; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5oZtXamjWgQelXQM3KP8RjGd9ICs7N/ygiCiSmbuh6E=; b=SFTafy2TtdeMEVgb79yvu0yoEtyKFiGlNm3UEJBTc2bov4aJDs/2YqcxQzQOsg0UjP PgEijQafqcln/LvsNX6UrbzE3lVFDgR3P60WMXctpuNktZpl5FZTMQl8F7DRa30lvlZL XyoZ7aD3Cr64eN4LEHwu/mrNwtpGOc3JmMgQSJo6VHep+0IaCv7rGpGzRO6V8Ml8cMlV h2CO7JUoGsOI/klHIx2/iFt0ca7/xGdrkEBRX0c24X2/U6a8lyY/kGtgD154y1yAnVMY ZWtEcpZGklU56d8t0zPCMf4hEsbV+RuS9rBqbz0nMdoGlbQH4FTOpxPWsi9DOaao+6HC 4alQ== X-Forwarded-Encrypted: i=1; AJvYcCVQ5c1DWnTCRyEwTPp0tDMVNkUB55iCpIVtrXjo6GgKRHj6dIQcAZRdYGnEZIyryWdiJTeTNjQ2vQA=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxbl6/fANESqCHVVZWwSvLfIz7gcpca4Sj+YqFDLP1BsyrTOEo4 s9oub5ebUko7EQi72pNp3UZXLQ9ZPk+BfA3cH3asOv6pZSGN3RxJAnsxyfiRifqsQg== X-Gm-Gg: AY/fxX41WnSe3JrgSnK4cbltDHwG3pScDZIVQPsVGEU7S2K0WgyQlXuW4yhZFUHrYkh SQGsVoUROp0xbNf2ukJ89W7WQhYEJyDBLoCe4vgEBW1HJw9/ENvelf0nVzSAvQtdT9J5fM4TGH1 kS+OZ484jmZJptxoJuecFxsXrEfjH6nlQvixW8QMqNRdxzaCbFrcBjlRVtVEbkcMywe+8XfJnIh BnsbMZvSIUdeKWbvQNM797J569SLX9x7u0OOIGSTgbzM0xDmmRf3x2+beyHaDtTqf+4M8Ms+M4v RA2/u0VEWf0d068wA3KUNr5nEenSCG/1dvX9CG98zD7LPZDqcHuujsoaA78If09jfa0lSsGlWZM eC/EqTPGC6M+BB17/2riLXlxM2OynhczWs13RH9by5waV3MNrl7y2nhjqs1Zs+MTNe2R+7l8afC y/6IQs79ceWJhTigZ6r8/fABZTCi3BnmYGcxMiGYw+ey1gleko488MLiO1oe0cV+SSXQlK1WuzZ yXh16+T+VDvrw== X-Received: by 2002:a05:600c:1d09:b0:47e:e970:cf28 with SMTP id 5b1f17b1804b1-4801e34cc24mr1509955e9.30.1768490915690; Thu, 15 Jan 2026 07:28:35 -0800 (PST) Message-ID: <291467bb-61f4-4ada-b165-33d8773cddd8@suse.com> Date: Thu, 15 Jan 2026 16:28:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen: Move NX handling to a dedicated place To: Julian Vetter Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P . Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , xen-devel@lists.xenproject.org References: <20260115151658.3725784-1-julian.vetter@vates.tech> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260115151658.3725784-1-julian.vetter@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 15.01.2026 16:17, Julian Vetter wrote: > Currently the CONFIG_REQUIRE_NX prevents booting XEN, if NX is disabled > in the BIOS. Which is what the config option's name says? IOW if this wants changing, more wants saying here. > AMD doesn't have a software-accessible MSR to re-enable it, > so there is nothing we can do. The system is going to die anyway. But on > Intel NX might just be hidden via IA32_MISC_ENABLE.XD_DISABLE. But the > function to re-enable it is called after the check + panic in > efi_arch_cpu. So, this patch removes the early check and moves the > entire NX handling into a dedicated place. > > Signed-off-by: Julian Vetter > --- > xen/arch/x86/boot/head.S | 56 -------------------------------- > xen/arch/x86/boot/trampoline.S | 5 ++- > xen/arch/x86/cpu/intel.c | 4 --- > xen/arch/x86/efi/efi-boot.h | 12 ------- > xen/arch/x86/include/asm/setup.h | 2 ++ > xen/arch/x86/setup.c | 46 ++++++++++++++++++++++++++ > 6 files changed, 50 insertions(+), 75 deletions(-) Wasn't there some earlier variant of this? I.e. is this a v2 (or higher), where it might help if changes made were briefly called out? Still need to look at the patch as a whole ... Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 15:34:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 15:34:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205361.1519661 (Exim 4.92) (envelope-from ) id 1vgPMP-0005uH-Ng; Thu, 15 Jan 2026 15:34:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205361.1519661; Thu, 15 Jan 2026 15:34:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgPMP-0005u8-Km; Thu, 15 Jan 2026 15:34:09 +0000 Received: by outflank-mailman (input) for mailman id 1205361; Thu, 15 Jan 2026 15:34: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 1vgPMO-0005fo-4E for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 15:34:08 +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 9eaef482-f227-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 16:34:03 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by AM7PR03MB6626.eurprd03.prod.outlook.com (2603:10a6:20b:1ba::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.6; Thu, 15 Jan 2026 15:34: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.9520.005; Thu, 15 Jan 2026 15:34:00 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9eaef482-f227-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UiqsnYr7LM7Wz7k+TGeOeQihUsYmZuwKacHFwp79425zc+sUc2bQl4DVFIBNRBieLKU0L0qA8blo/iixsYUZHQUXot7zG5UmLL61A4nsfyIdzibDNJLgJAgoK+0naeJAdF0cMu/ElHqvsVjDFYbp1nYrJbnrwfEw5wDU/sB1aIKfh5Ixv/6WNyGB7K7mV6IWRS3Sg5mwL+/oV5sW6nf2YdaeyCfBVfbYXDdc6rDOppL6UKT+CX1oLI8ysb4Uab3O+lYmxWW75wk1ib2EocAV+yUm2ZGYHD1Ldy1RG3OOx6zPrqoQeQTZ6hJp16+gdgP3pOfvHYKF/A+UOqAkbiTuhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hw5If/YVWfhpalv6uyl5toGeL9XCA6J9aLeMoMbQFqQ=; b=Uqc6HeEZzY5V/Q1vd0DNMA6Biv0a0YKmhwyeSDylMHPITHtKutN4BRjH7bxakZz5717pjkhLycpvKEMf6QDUEPxajbN1aZ+4E/x86hMgIhc7P0D3KTDv+4R7g986Txjygkn7bZdLfko/SF+rHUMPCgERmonRinmMLoOTlC/b0sw2YoaCtdKzGVHe4DVjjcJQS4lriSYhbRi+DyK9YIMaJKPPcIBdavEtQQIcfzCmmN4iBoBpClKdV4EKT/vyyQfoJHkijPjgIKgayZpijquePPW6SC9foX3bWIOhqmnW8pTf1zOTj7sI7R0/4ZdpGV5gMFKXAkvIqzDB2EO2L4g7SQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hw5If/YVWfhpalv6uyl5toGeL9XCA6J9aLeMoMbQFqQ=; b=QAo8d8p5ABKnjmBJQPLweB5WqPbLNu+iUS7o0c/JgqBYda3Qi2d/T0YUniODkcGUQ7ZrXPMwPRC+2fT1VOb2YwCq4EoEpGDavw4wnyf4vwDB9HX3RoQq40ztbfjS1I90yKvmOCB6J0CDKi4CE3WsizdXciDiZfTcR/aD8bgt6H/erm+FCPAJEZFvRYs5skaEG9E48eQIFUT/C1SQAt/rsFVLjpdevvxodYuxHiXrG5QOyXA2N1biaYCGNKtWOYxlA3RwrkAWJruouHrygWALEGEFBfoMd9Pnf0RBOqP40veDVNOANTt8WlKINGmGtKBZv1x7eSzjLCxq3Yu/LRat5A== From: Oleksii Moisieiev To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v7 3/5] lib/arm: Add I/O memory copy helpers Thread-Topic: [PATCH v7 3/5] lib/arm: Add I/O memory copy helpers Thread-Index: AQHchYPD+fwQGyuKXEKqeHI8xFGbqLVS9u+AgAAq8ACAADvNAA== Date: Thu, 15 Jan 2026 15:34:00 +0000 Message-ID: References: <8539bed5-280f-4dcc-a63d-4c0ee3b7cff7@suse.com> In-Reply-To: <8539bed5-280f-4dcc-a63d-4c0ee3b7cff7@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_|AM7PR03MB6626:EE_ x-ms-office365-filtering-correlation-id: 073f46ad-fd41-41f5-4e68-08de544b817f 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?VkJYOE9sYnJKU2htNU5VM0JPSHM0TVJRK0xBd0UzTmRnaTQzcWYwbnpidEFu?= =?utf-8?B?eTNuT3BKNnhsQ2IvMnhDU2V4cGI5K2JvQ2ExZFhnRTd6aDA3NWZPdy9vZGRI?= =?utf-8?B?c0FtRS83Y1NXT1MvK09ldEt2dnRlbGkvUEs0RnhGc2llNmwzWWNoZ2dlVzVa?= =?utf-8?B?V0xGTkdPUEY5OU9GcHRNQ2RlZGgzQXkrWW5JMC9vaklGOHRtaDFLMXRyRjZ4?= =?utf-8?B?SlErSlQ4Q3owa3dXVEZQQWltR3YzR2M4Q1NhKzltTzI0Rjc2T1U4R1llV0Q5?= =?utf-8?B?Tk5HZEV6N0syZnhZOU9selhMeW1IUUpmdVkrM29iblRPSXl0dmhlc3ZGMjEr?= =?utf-8?B?NTNFWlpGZ2RyTUI1SlhhcHhGRE1NRUI3cVBIR3h6R3hkZnhpTllmN3pPSWpl?= =?utf-8?B?ZHVadmlYZmN6OXY0MnZCYzdVL0RJejhnR3IwTUR5SUhFZjMzMUVUeGJYenBF?= =?utf-8?B?QWpLU3hoVDJhTnBja1BFa0RHbDFDbGM4emNSRXh5RXgwZjFZaXdkQVZ6Zngw?= =?utf-8?B?anJ4Zk5Kd2dHT0JtNGlETmZGb3AvdXVqR2Y0aVhUWVlRS1VieFR4a09DSmtU?= =?utf-8?B?cWx4WG9UaDRtRWJib2czVnJaeTZZdTF5WVBtSmh3Nk93TDRoTUk1d3JzdVl6?= =?utf-8?B?eFZTSVFVaDR1dnc5VTUzRktROWFVbHRlY1JpL3kyTUdFMng5czk0NmlqdkxB?= =?utf-8?B?V0pRcGRKVG1MZFdsckppODFiVUpkMW5HVDEwN3E1Nk1QNWRxVVUya3k3Sm4y?= =?utf-8?B?UTZ0cjZGSVQ2L1BLMFR5TU9ML25RaWhkc1VVdlVLVzdRN1A4c1U5R0prVTlG?= =?utf-8?B?RysveU9pTHhweFdDQUpjOG50ZWpCSHZmN3liZ2pNeUtHUkJZSEV2UDlFWVla?= =?utf-8?B?cmhhS3pqT21LMWYvR0xoRXNkUHdVb21QckZ5SjdiNFJIOGcyblNZSm50TEY3?= =?utf-8?B?emFnVndWL25Fc3V6NkxVNDRaazQ1VnZpRkpiS21jQ1B1R0Y3T0V1SndnODBC?= =?utf-8?B?YXNnSXo0b0txd2ROa0VLM2dwUlV0THBpNlY1YzBjNDBuZU1taFI5ck1xbElR?= =?utf-8?B?Nk5FNDVmQ3BHM0VTMXMvcWNGbmlTM2FqL3hXK0dpMHZsRFBGZXB1a2NXSG4r?= =?utf-8?B?N1UxQS90QXM1cy9JNjBNSlVNWWh1VXRVV1pteGtMSmhGSXc4OFVGTm02OFFS?= =?utf-8?B?OGZrN0djYnE4OEtELyt4YUNDVWxVSUlFS1J2SHhsalFMMUdBN3Y2MjBSSGQx?= =?utf-8?B?Rm9lN0E0ZHl0NDc4RGdNRmh2YW9yTzBQeTZBa1NTRE91VitZN25jZDlsWVlF?= =?utf-8?B?RmNrcjUyeHlUTHczRzlUdC9WYm9WbmpLSmc0ZzJIQ21GRm9SVTZQZ0o5eVQy?= =?utf-8?B?RU0wcCt4bnNCazhuNm1Hbk9NZTJxL0E4c2tKTnRIQnVsQmRMWTdkN3BRNWZB?= =?utf-8?B?eFo3MHZEdUV6elkzL0VJQ2M5WlRZZ2NYN1J4cWtiS1hFanVFVW4zOE5tZW91?= =?utf-8?B?dy9Xa1BVblYyUytIOC9adEhFUXVkT001WWJRZkhTUjVISitTMTVtVEtNbWJk?= =?utf-8?B?TGJpOXZRRGl5T1hnSkNHQ0ZQc0srWEJ6cWpzZ0JWK3lzdGRhRzZvdWx4NXlP?= =?utf-8?B?LzhvTTB2cFZ1UHpaT3VsU3FkaGQxRnFja3Y0cGVTei93K1BYWmZWZ2lkNmtX?= =?utf-8?B?WXdiTy8rOXNsY3IwWDFHRFQ3dHBGdmZMeExmeGFUaFFBcFR6Vy9vRmF4VFdH?= =?utf-8?B?MVJ0ZnpyaUF2WHlvOUVUdm9KbXA1RmRXSVpLU1FqNzVjeUE1T09UcEwrMGQy?= =?utf-8?B?OE5tdlk0MVpRT3pkc3FxdTZTRDF4bFQ1S1A0b1FWbzBqQUV1THdWN3RhUk9L?= =?utf-8?B?aGo5NzkranlUSmhVOXA0djB2TFY1aFZ0czEzelNoeEFxdWs2akFwcVlMSml5?= =?utf-8?B?TXI1WXJERmlLOEVCUkZ2OERzYWsxR1FwQ0s1UDl6Sy9BSmdKTWpJZm9QYkh6?= =?utf-8?B?eFhwbjJ6dUFraFVLU3IyY1ZQWXlCb21SaUp5alNmOTBkdWtvVDVZOWdYQS9u?= =?utf-8?B?SWYvK2hSRGtyang2MDhCc2ovWnIzZm1ESGJQQlhSOGZBRTJJb2JON2Z0Qm1v?= =?utf-8?B?WXJhSnpvL0NWeWQvQUhNK3I1Uk55ME9NbENzTk9EbTVvRmh6alJkdC9BQ3dk?= =?utf-8?Q?rLplIKVlM8JkGnP450XPMMc=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?Yy9naGh2ZUlYYmhFcDJ5OXRocVRaTVV1UFRDeFdrM0sxWmVieEp6T3dWNi85?= =?utf-8?B?QkRQb2dHNWRRdGw4V1dLK2hMZXp4a0QzOUNLTGYyZzdUSWh0OEV5S2k2U2tG?= =?utf-8?B?UmllMGNDUmdxbnlwYnVyZ2JPOXV1bkFsL3lIdkZGdSt5M1pEYlQ1eFBxektr?= =?utf-8?B?TmJvelFDSmV3VzBLdWhDUlJsNDl0NTBVdzRrM1FOMEFVUkNKQWYvTmx1M3VO?= =?utf-8?B?UUdBbDB6ekh3Vk9yUlJtQTNnSkRteUxXNGZrQXlTUkowT0JJTFF1T2FBdFRy?= =?utf-8?B?OFJTUXNZMUNCdXdUL2oyZldQQUhLNXFQTmNFM2xDdUh1endieUJFN2svYzRD?= =?utf-8?B?RkFsVkFzdWdiZHkyZk1HeG9Oek4rUVpoa2xldVpBelNsYVZmVVFoM2Q2djhj?= =?utf-8?B?Q0lJOW1JTFU5c3BjZUFvQzllM1BqNGx5MHU0cjZQS3BqTHpvQURFR2dSR3lv?= =?utf-8?B?V0dwaUZVc0Jkamkrc2hRSUNjaC9pM1pta0R1SVdnekdVZVNmNnZXaEJsajNu?= =?utf-8?B?UW9XSmdWZUhtdlBCRmtxdzh3bmhhTm1pbTV1T2RZY2FDMDNtVTZQanAzWFVY?= =?utf-8?B?T3Z6Nk5FTmVRcVZIUjlBSGVhM2hkd1JvQUxPUXV3OEpjdHcrdHVpT21JVk56?= =?utf-8?B?amZJTlRQVzFiY0RZam0vYjVpTU1SVEJHV3RVUGp5WGxoeGlOdFZFMjlVaGJX?= =?utf-8?B?SUhHY0JpRWY2ZWRzT3hSc2hUbTd1Zlk0dUVrV0s2cGE3aTQxSzQrUG5HUTV0?= =?utf-8?B?bGlOMmk1bk5HZXhIWTE1VWRMbS9NdXZZSEhBekEyR090RWlKd1JuZVFnMjBM?= =?utf-8?B?TWpSdW43WThOamo2TUMwY1BpZWxZRkRIWlFmMng1ZDlqODdvQnVaMjIwNzQ2?= =?utf-8?B?ZUk4MGtNRDUyUE9VK2lRN2tWLzRmenFjZzdSTG5BaWcrU0Q3WVgwWDV6Yjg3?= =?utf-8?B?Ynk1WVNiekkrODQ1T1ZrZmd6QnloK2hRN052UEpHNEl0K0dCZkQ0Rzc5dnR1?= =?utf-8?B?RVYva2U0bno3ekhHZWZybnRiY1BQZ0s3b1p3emRWRWRXVTlVellrWTdiSWZy?= =?utf-8?B?WFg4ci9ZT1BVMzNlMzFpUHpoVkkvVWZTdUF4bFlWZUdJTDZFRURsY0F2MVNu?= =?utf-8?B?SGNkcHhtNzdqb04zUHlXSVJwdHRBVHlTd2ZnblV3MzRVRFc5UnBpTjliV2VM?= =?utf-8?B?UXJpZG1CeEJXRW1OR3I1aU0rSEhMTmgxQ1hJVk1TYi9FYlk5K2dLQkxQaUxY?= =?utf-8?B?Q3YrNjltZldtMmh5S2ZzVk5PMW1iU05rdDRaeGsraURPYi8xeXVjMGt3S3Ji?= =?utf-8?B?Nk9iM3NPaDBVb25YTjFoWkhvQXcxNEE1Vmd2elE5M0hZQzRBZmNFUENHeEta?= =?utf-8?B?MW1hTjZNL1VKanRGT2VjTGM3OGN3M08wQlgvZndiM2xsUXBLT2pQTExmeTRX?= =?utf-8?B?eFRNbHdPeW9hK3ZGNzFpeE5YTmlVTVZwRUZyWlVPdHAybVZiNnhGQ3pCbmUw?= =?utf-8?B?SDlINlc4ZGxVQVdLLzdhb0djZENsQ3VxNkxib2RmNWNha2RnUXlaR3lOQUNO?= =?utf-8?B?ZnJXWUovbTNOak5FbWh2MEI2ZnNKdG14V1FnOXlpRjR2TEltRHZKejM4eTNV?= =?utf-8?B?bVJMTXZIZ0JJbFNHbmh4M1IvZTYzdHRWMlYrc01ybEhhYWZZMy9aSERuOEdq?= =?utf-8?B?ZkYrVDQvNDJ1LzNOQ3N4ZUplQTF3cVhOZUlLbDdqQTU5RGhoa2RSbllDQ1Jj?= =?utf-8?B?RTJpQnl6Lzl6RWxuMzZ0OTBJVlQ1Yzh3cVhBMDE3ZldDak1jMjZIMmt2bnli?= =?utf-8?B?bmlITlNCUXg2ZTkxU0tNeDZSU0wwYXU4MlkrTm95Z25CZmtUcHh0ejlEblJw?= =?utf-8?B?NkJFQ0wza3F6MHBWL05lb0JZRE40MUxCMEQzaEFYRmI5Ky9pWFJ5S1lSTFkv?= =?utf-8?B?U1F4b1ZmZFBnYU1aUWtRdkkzMmlMSnMzeXpwVXJDS1FOeUJIcTlEa3JsMEo5?= =?utf-8?B?YWJ6MTBTT08vcHdQVk9RMU9Wc2wxVktYTXU5ckhiQzRNeFpoQUdMQ2VaSldq?= =?utf-8?B?MHI4Q1dONTlWR0c3TUdTMmtYaU51b2N5NG01MExtTldKc3djQW1OclllWFBG?= =?utf-8?B?OHJPbHdPQWcxSTJXRE9nU2ZHM2twL3RlU0Nzc3JyR2l2QUVaRGhVS0pBMWdN?= =?utf-8?B?OUZVM3g2bUFwanhGY2MrdlM1dUNlZFE3Z2RGQ3JYVVpDTEhQQm10YmVVNXFZ?= =?utf-8?B?VFhwTkFUNWdBRDdOVFpsMFhpcTkvTHR4a2ZQT3dQc3g4M3ZBZlV0VnE0bTFt?= =?utf-8?B?LzZZZmdvdGhBR0p1QjVVWDBFK2ZLYXl0dlJkNDIrcGZCRVFNYm1KVmhEZnN4?= =?utf-8?Q?bpeHRbif/T+f/kq8=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <4CC4432D7DC99F4693E194887FED4349@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: 073f46ad-fd41-41f5-4e68-08de544b817f X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2026 15:34:00.4666 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sc2ei9+4A9TRHgMjdF4/mTlCXa1QSmJTjuw5mvNsiym41QXQv8eJd3FPQJ+Rf4c28i8d4aTIPhyXetnlF6A5YTLqltDp+ihVdxcLia2Snek= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR03MB6626 DQoNCk9uIDE1LzAxLzIwMjYgMTM6NTksIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxNS4wMS4y MDI2IDEwOjI2LCBKYW4gQmV1bGljaCB3cm90ZToNCj4+IE9uIDE0LjAxLjIwMjYgMTk6MjksIE9s ZWtzaWkgTW9pc2llaWV2IHdyb3RlOg0KPj4+IC0tLSAvZGV2L251bGwNCj4+PiArKysgYi94ZW4v bGliL2FybS9tZW1jcHlfZnJvbWlvLmMNCj4+PiBAQCAtMCwwICsxLDQ4IEBADQo+Pj4gKy8qIFNQ RFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4wLW9ubHkgKi8NCj4+PiArI2luY2x1ZGUgPGFz bS9pby5oPg0KPj4+ICsjaW5jbHVkZSA8eGVuL2xpYi9pby5oPg0KPj4+ICsNCj4+PiArLyoNCj4+ PiArICogVXNlIDMyLWJpdCByYXcgSU8gb3BlcmF0aW9ucyBmb3IgcG9ydGFiaWxpdHkgYWNyb3Nz IEFSTTMyL0FSTTY0IHdoZXJlDQo+Pj4gKyAqIDY0LWJpdCBhY2Nlc3NvcnMgbWF5IG5vdCBiZSBh dG9taWMgYW5kIHNvbWUgZGV2aWNlcyBvbmx5IHN1cHBvcnQgMzItYml0DQo+Pj4gKyAqIGFsaWdu ZWQgYWNjZXNzZXMuDQo+Pj4gKyAqLw0KPj4+ICsNCj4+PiArdm9pZCBtZW1jcHlfZnJvbWlvKHZv aWQgKnRvLCBjb25zdCB2b2xhdGlsZSB2b2lkIF9faW9tZW0gKmZyb20sDQo+Pj4gKwkJICAgc2l6 ZV90IGNvdW50KQ0KPj4+ICt7DQo+Pj4gKwl3aGlsZSAoIGNvdW50ICYmICghSVNfQUxJR05FRCgo dW5zaWduZWQgbG9uZylmcm9tLCA0KSB8fA0KPj4+ICsJCQkgICFJU19BTElHTkVEKCh1bnNpZ25l ZCBsb25nKXRvLCA0KSkgKQ0KPj4gTml0OiBYZW4gc3R5bGUgaW5kZW50YXRpb24gKG5vIGhhcmQg dGFicykgcGxlYXNlIHRocm91Z2hvdXQuDQo+Pg0KPj4+ICsJew0KPj4+ICsJCSoodWludDhfdCAq KXRvID0gX19yYXdfcmVhZGIoZnJvbSk7DQo+Pj4gKwkJZnJvbSsrOw0KPj4+ICsJCXRvKys7DQo+ Pj4gKwkJY291bnQtLTsNCj4+PiArCX0NCj4+PiArDQo+Pj4gKwl3aGlsZSAoIGNvdW50ID49IDQg KQ0KPj4+ICsJew0KPj4+ICsJCSoodWludDMyX3QgKil0byA9IF9fcmF3X3JlYWRsKGZyb20pOw0K Pj4+ICsJCWZyb20gKz0gNDsNCj4+PiArCQl0byArPSA0Ow0KPj4+ICsJCWNvdW50IC09IDQ7DQo+ Pj4gKwl9DQo+Pj4gKw0KPj4+ICsJd2hpbGUgKCBjb3VudCApDQo+Pj4gKwl7DQo+Pj4gKwkJKih1 aW50OF90ICopdG8gPSBfX3Jhd19yZWFkYihmcm9tKTsNCj4+PiArCQlmcm9tKys7DQo+Pj4gKwkJ dG8rKzsNCj4+PiArCQljb3VudC0tOw0KPj4+ICsJfQ0KPj4+ICt9DQo+PiBCYXJyaWVyIHJlcXVp cmVtZW50cyBvbiBBcm0gYXJlbid0IHF1aXRlIGNsZWFyIHRvIG1lIGhlcmU6IElzIGl0IHJlYWxs eSBjb3JyZWN0DQo+PiB0byB1c2UgX19yYXdfcmVhZHtiLHcsbH0oKSBoZXJlLCByYXRoZXIgdGhh biByZWFke2IsdyxsfSgpPyBJZiBpdCB3YXMsIHdvdWxkbid0DQo+PiBhIGJhcnJpZXIgdGhlbiBi ZSBuZWVkZWQgYXQgdGhlIGVuZCBvZiB0aGUgZnVuY3Rpb24/DQo+IFRoaW5raW5nIGFib3V0IGl0 LCBhcyB0aGUgb3JkZXIgb2YgTU1JTyBhY2Nlc3NlcyBuZWVkcyB0byBiZSBndWFyYW50ZWVkDQo+ ICh1bmxlc3MgeW91IGhhdmUgZXh0cmEgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGFyZWEncyBwcm9w ZXJ0aWVzLCBsaWtlIGl0DQo+IGJlaW5nIGEgdmlkZW8gZnJhbWUgYnVmZmVyKSwgSSdtIHByZXR0 eSBzdXJlIG5vdyB0aGF0IHJlYWR7Yix3LGx9KCkgbmVlZHMNCj4gdXNpbmcgaGVyZS4gSW4gZmFj dCB0aGUgY29tbWVudCBpbiB0aGUgaGVhZGVyIHNheXMgdGhhdCBpdCB3b3VsZCBoYW5kbGUNCj4g Ik1lbW9yeSBvcmRlcmluZyBhbmQgYmFycmllcnMiIHdoZW4gaXQgZG9lc24ndCBsb29rIGFzIGlm IGl0IGRpZC4NCj4NCj4gTm90ZSBob3cgTGludXggbG9va3MgdG8gaGF2ZSBncm93biBtdWx0aXBs ZSBmbGF2b3JzOiBCZXNpZGVzDQo+IG1lbWNweV9mcm9taW8oKSBJIGNhbiBhbHNvIHNwb3QgYXQg bGVhc3QgZmJfbWVtY3B5X2Zyb21pbygpIGFuZA0KPiBzZGlvX21lbWNweV9mcm9taW8oKS4NCj4N Cj4+IEFuZCB0aGVuLCBpZiBpdCB3YXMgcmVhZHtiLHcsbH0oKSB0aGF0IGlzIHRvIGJlIHVzZWQg aGVyZSwgd2hhdCBhYm91dCBhbGwgb2YNCj4+IHRoaXMgd291bGQgdGhlbiBzdGlsbCBiZSBBcm0t c3BlY2lmaWM/IEhtbSwgSSBndWVzcyB0aGUgSVNfQUxJR05FRCgpIG9uICJ0byIgaXMsDQo+PiBi dXQgdGhhdCdzIEFybTMyLXNwZWNpZmljLCB3aXRoIEFybTY0IG5vdCBuZWVkaW5nIGl0PyBQbHVz IHRoZW4gaXQncyBhZ2FpbiBub3QNCj4+IGV4YWN0bHkgQXJtLXNwZWNpZmljLCBidXQgc3BlY2lm aWMgdG8gYWxsIGFyY2hpdGVjdHVyZXMgd2hlcmUgbWlzYWxpZ25lZA0KPj4gYWNjZXNzZXMgbWF5 IGZhdWx0Lg0KPiBUaGVyZSdzIGEgYmlnZ2VyIGlzc3VlIGhlcmUsIHdpdGggYWNjZXNzIGdyYW51 bGFyaXR5IChkZXNwaXRlIHRoZSBoZWFkZXINCj4gY2xhaW1pbmcgIkltcGxlbWVudCBhbGlnbm1l bnQgaGFuZGxpbmcgZm9yIGRldmljZXMgcmVxdWlyaW5nIHNwZWNpZmljDQo+IGFjY2VzcyBzaXpl cyIpLiBNTUlPIGNhbiBiZWhhdmUgaW4gaW50ZXJlc3Rpbmcgd2F5cy4gVGhlIGhlYWRlciBjb21t ZW50DQo+IHNheXMgbm90aGluZyBhcyB0byByZXN0cmljdGlvbnMsIGkuZS4gd2hlbiB0aGVzZSBm dW5jdGlvbnMgbWF5IG5vdCBiZQ0KPiB1c2VkLiBZZXQgY29uc2lkZXIgYSBkZXZpY2UgcmVnaXN0 ZXJzIG9mIHdoaWNoIG11c3QgYmUgYWNjZXNzZWQgaW4gMzItYml0DQo+IGNodW5rcy4gQXMgbG9u ZyBhcyB0aGUgb3RoZXIgcG9pbnRlciBpcyBzdWl0YWJseSBhbGlnbmVkLCBhbGwgd291bGQgYmUN Cj4gZmluZS4gQnV0IHlvdSBoYW5kbGUgdGhlIGNhc2Ugd2hlcmUgaXQgaXNuJ3QsIGFuZCBoZW5j ZSB0aGF0IGNhc2UgdGhlbg0KPiBhbHNvIG5lZWRzIHRvIGZ1bmN0aW9uIGNvcnJlY3RseS4gQXQg dGhlIHNhbWUgdGltZSBhY2Nlc3NlcyB0byBhIGRldmljZXMNCj4gcmVxdWlyaW5nIDE2LSBvciA2 NGJpdCBncmFudWxhcml0eSB3b3VsZG4ndCB3b3JrIGF0IGFsbCwgd2hpY2ggZm9yDQo+IHJlcXVp cmVkIDgtYml0IGdyYW51bGFyaXR5IGl0IHdvdWxkIGFnYWluIG9ubHkgd29yayBwYXJ0bHkuDQo+ DQo+IEhvdyBtdWNoIG9mIHRoZSBhYm92ZSByZXF1aXJlcyBjb2RlIGFkanVzdG1lbnRzIGFuZCBo b3cgbXVjaCBzaG91bGQgYmUNCj4gZGVhbHQgd2l0aCBieSB1cGRhdGluZyBjb21tZW50YXJ5IEkg ZG9uJ3Qga25vdywgYXMgSSBrbm93IG5vdGhpbmcgYWJvdXQNCj4geW91ciBwYXJ0aWN1bGFyIHVz ZSBjYXNlLCBub3IgYWJvdXQgcG9zc2libGUgZnV0dXJlIG9uZXMuDQo+DQo+IEFsc28gbm90ZSB0 aGF0IHRoZSBoZWFkZXIgY29tbWVudCBzdGlsbCByZWZlcmVuY2VzIHRoZSAuLi5fcmVsYXhlZCgp DQo+IGZ1bmN0aW9ucywgd2hlbiB0aGVuIGltcGxlbWVudGF0aW9uIGRvZXNuJ3QgdXNlIHRob3Nl IGFueW1vcmUuDQo+DQo+IEphbg0KSGkgSmFuLA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5 b3VyIHZhbHVhYmxlIGlucHV0IGFuZCBpbnZvbHZlbWVudC4NCg0KQWZ0ZXIgZnVydGhlciByZXNl YXJjaCBhbmQgcmVjb25zaWRlcmluZyBhbGwgdGhlIHBvaW50cyB5b3UgcmFpc2VkLCBJIA0KaGF2 ZSBkZWNpZGVkDQp0byBzd2l0Y2ggdG8gdXNpbmcgdGhlIG9yZGVyZWQgTU1JTyBhY2Nlc3NvcnMg KHJlYWRiL3JlYWRsIGFuZCANCndyaXRlYi93cml0ZWwpLg0KDQpIZXJlIGlzIG15IHJlYXNvbmlu ZzoNCg0KVGhlIGNvbmNlcm4geW91IG1lbnRpb25lZCB3YXMgdmFsaWQ6IHRoZSB1c2Ugb2YgX19y YXdfcmVhZCovX19yYXdfd3JpdGUqIA0KaW4gdGhlDQpoZWxwZXJzIGRpZCBub3QgcHJvdmlkZSB0 aGUgb3JkZXJpbmcgZ3VhcmFudGVlcyBleHBlY3RlZCBmb3IgTU1JTyANCmNvcGllcywgYW5kIHRo ZQ0KaGVhZGVyIHN0aWxsIHJlZmVyZW5jZWQgKl9yZWxheGVkLCBldmVuIHRob3VnaCB0aGUgaW1w bGVtZW50YXRpb24gbm8gDQpsb25nZXIgdXNlZA0KdGhlbS4gVGhpcyBjb3VsZCBhbGxvdyByZW9y ZGVyaW5nIGFyb3VuZCB0aGUgY29weSBhbmQgbWlzcmVwcmVzZW50IHRoZSANCmludGVuZGVkDQpz ZW1hbnRpY3MuDQoNCkEgZmV3IGFkZGl0aW9uYWwgdGhvdWdodHMgcmVnYXJkaW5nIHlvdXIgb3Ro ZXIgcXVlc3Rpb25zOg0KDQpJcyBpdCBzdGlsbCBBcm0tc3BlY2lmaWM/DQpGdW5jdGlvbmFsbHks IHRoZSBsb2dpYyBjb3VsZCB3b3JrIG9uIGFueSBhcmNoaXRlY3R1cmUgdGhhdCBzdXBwb3J0cyAN CjgvMzItYml0IE1NSU8NCmFjY2Vzc2VzIGFuZCB1c2VzIHRoZSBzYW1lIGFjY2Vzc29yIHNlbWFu dGljcy4gSG93ZXZlciwgdGhpcyBpbXBsZW1lbnRhdGlvbg0KcmVsaWVzIG9uIEFybeKAmXMgcmVh ZCovd3JpdGUqIG9yZGVyaW5nIGd1YXJhbnRlZXMsIGFzIHdlbGwgYXMgdGhlIA0KQXJtLXNwZWNp ZmljDQpJU19BTElHTkVEIGNoZWNrIHRvIGF2b2lkIG1pc2FsaWduZWQgZmF1bHRzLiBUaGVyZWZv cmUsIGl0IHJlbWFpbnMgDQpBcm0tc3BlY2lmaWMNCmFzIHdyaXR0ZW47IG90aGVyIGFyY2hpdGVj dHVyZXMgd291bGQgbmVlZCB0aGVpciBvd24gaW1wbGVtZW50YXRpb25zIGlmIHRoZXkNCmhhdmUg ZGlmZmVyZW50IGFsaWdubWVudCBvciBncmFudWxhcml0eSByZXF1aXJlbWVudHMuDQoNCk9yZGVy ZWQgYWNjZXNzb3JzIHZzLiByYXcgYWNjZXNzb3JzICsgdHJhaWxpbmcgYmFycmllcjoNCkkgY2hv c2UgdG8gdXNlIG9yZGVyZWQgYWNjZXNzb3JzIGluc3RlYWQgb2YgcmF3IGFjY2Vzc29ycyB3aXRo IGEgDQp0cmFpbGluZyBiYXJyaWVyDQpiZWNhdXNlIHJlYWRiL3JlYWRsIGFuZCB3cml0ZWIvd3Jp dGVsIGFscmVhZHkgcHJvdmlkZSB0aGUgcmVxdWlyZWQgDQpkZXZpY2Ugb3JkZXJpbmcNCmFuZCBi YXJyaWVyIHNlbWFudGljcywgbWFraW5nIGFuIGFkZGl0aW9uYWwgYmFycmllciB1bm5lY2Vzc2Fy eSBhbmQgDQpzb2x2aW5nIHBvdGVudGlhbA0Kb3JkZXJpbmcgaXNzdWVzLg0KDQpVc2UgZm9yIHJl Z2lzdGVyIGFjY2VzczoNClRoZXNlIGhlbHBlcnMgYXJlIHN1aXRhYmxlIGZvciBNTUlPIGJ1ZmZl cnMsIHNoYXJlZCBtZW1vcnksIGFuZCANCnJlZ2lzdGVycyB0aGF0DQp0b2xlcmF0ZSA4LS8zMi1i aXQgYWNjZXNzZXMuIFRoZXkgYXJlIG5vdCBhcHByb3ByaWF0ZSBmb3IgcmVnaXN0ZXJzIHRoYXQN CnJlcXVpcmUgMTYtIG9yIDY0LWJpdCBhY2Nlc3Nlcywgb3Igd2hlcmUgc2lkZSBlZmZlY3RzIGRl cGVuZCBvbiB0aGUgZXhhY3QNCmFjY2VzcyB3aWR0aC4gSSdsbCB1cGRhdGUgdGhlIGhlYWRlciB0 byBkb2N1bWVudCB0aGlzIGxpbWl0YXRpb247IA0KZHJpdmVycyBuZWVkaW5nIHN0cmljdA0KcmVn aXN0ZXIgc2VtYW50aWNzIHNob3VsZCBjb250aW51ZSB0byB1c2UgcmVhZGwvd3JpdGVsDQoob3Ig cmVhZHcvd3JpdGV3L3JlYWRxL3dyaXRlcSkgZGlyZWN0bHksIHJhdGhlciB0aGFuIG1lbWNweV8q aW8oKS4NCg0KU3VtbWFyeToNCg0KSSBoYXZlIG1hZGUgdGhlIGZvbGxvd2luZyBjaGFuZ2VzIHRv IHRoZSBoZWxwZXIgZnVuY3Rpb25zOg0KDQotIHN3aXRjaGVkIHRvIG9yZGVyZWQgYWNjZXNzb3Jz IHRvIGFkZHJlc3MgdGhlIG9yZGVyaW5nIGFuZCBiYXJyaWVyIA0KY29uY2VybnMuDQotIHVwZGF0 ZWQgdGhlIGRvY3VtZW50YXRpb24gdG8gbWF0Y2ggdGhlIGltcGxlbWVudGF0aW9uIGFuZCBleHBs aWNpdGx5IHN0YXRlDQp0aGUgc3VwcG9ydGVkIGFjY2VzcyBzaXplcyBhbmQgZ3JhbnVsYXJpdHku DQoNCklmIHRoaXMgYXBwcm9hY2ggc291bmRzIGdvb2QgdG8geW91LCBJIHdpbGwgcHJvY2VlZCB3 aXRoIHRoZSBmaXggYW5kIA0Kc3VibWl0IGEgbmV3IHZlcnNpb24uDQoNCkJlc3QgcmVnYXJkcywN Ck9sZWtzaWkNCg0K From xen-devel-bounces@lists.xenproject.org Thu Jan 15 15:34:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 15:34:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205360.1519651 (Exim 4.92) (envelope-from ) id 1vgPMM-0005g1-E5; Thu, 15 Jan 2026 15:34:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205360.1519651; Thu, 15 Jan 2026 15:34:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgPMM-0005fu-Af; Thu, 15 Jan 2026 15:34:06 +0000 Received: by outflank-mailman (input) for mailman id 1205360; Thu, 15 Jan 2026 15:34:04 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgPMK-0005fo-CW for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 15:34:04 +0000 Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [2a00:1450:4864:20::341]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9e37c8b3-f227-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 16:34:02 +0100 (CET) Received: by mail-wm1-x341.google.com with SMTP id 5b1f17b1804b1-47f5c2283b6so6734265e9.1 for ; Thu, 15 Jan 2026 07:34:02 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47f428acd0csm52404385e9.6.2026.01.15.07.34.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 07:34:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9e37c8b3-f227-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768491241; x=1769096041; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=NbpdJ4oz/23kVurwARU+dvJPq+baPgP/RkY7VRdYnyw=; b=VxXN2THvrH8/Hpaw9EPbTsdWnlgUDa+sKxZkBpG1wBdABgnI0c+/KL2PxMv+ZMgzQK /5Kq7M84fk+pPVTjkb9/BEQw2hsbcaGq3s6pIJlfFxn2kV1tYbMfC1an3YSJrmz1JC9Z avuiH/SU/13Qj86st2nJvV1VFRkM8GJzSPqz84Jr0dE4G65RWM0eK3zioDhaPNFiwOOw sKz4RdJ4avSkvCM5Ls7i3H/2e7Kn9tCZUrwR09tNXJpEWBNGCbkIAdfVMZivuCQSnasH FSmtbFER6SosRhoRh2H6YKObV55IJBWuWtRuJT2vvNMma9LexbLdHgBgiZqwvaxMrdj2 2i7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768491241; x=1769096041; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=NbpdJ4oz/23kVurwARU+dvJPq+baPgP/RkY7VRdYnyw=; b=P/Mvd3WrdkBOYm8alJv1P8RdWNCUZYTtvZg/UrVPqZGGo2BQta1WzMlWNmK7bzCrm/ uMlop+ZGxvGMEpaR1YuOe83Pusy+18ycJy6/vmowQ1LwvebNUOqx3Z7taIAP53eTqKw7 IRe2yEGpKdVVwhMDbiiPol7CLpWJyjbyg2hpNlK5jPX79d6Re1BRlRh+/S2yFtZExN+Y tpwpdke5nwEms20P5cZDpm8jCxy+zSg/V1ZcAMSXzOZMDZDltm8Etnm2SY4UseNq6IQh UCU96MGo4F4aKWGmAiEQrOpi5boJJxK0fT78w9bsy44XJ7o4VCkSvCZaOrH/+oFVmNd4 m5CQ== X-Gm-Message-State: AOJu0YylI/t0axxK6Whj2iiLsS73BlWUzSbeSGOnV2084gzlIAMrURJO dmMXTBZj6w0O5btM2CGvF+jFVtKIaJrXmbB59Dr6CYtMWDciY+F9GXKgayJsYK1Hyg== X-Gm-Gg: AY/fxX650Xsl7NXvde1okftIcluezdAxek5eRQuR1zU5ldpNJqScPTtMMm5JLMfKo6V AX4004uf0OC/atBHOexKDFYbSbnDz+AKUec1uIpxZ/lhvlLT1f7WqUKGvuogQQFWf1rKTykD0W0 cFk+tyOfm6wJIUJKMhfHw0lPoAL2dOHs5y1s9O0gdsvMVLEemnmoXdfkPoZXwmUO/7SE0IlNyb9 iR6SFFTEH4cxjxir0yP7Fs3JxqA9cAhPa/37keXWn4k/qmFBfL5A35pcWYVyY+0Vc9Arc8hEKME jLzkV8T+HKiAHzWSKGVjPPQA9c7coODk1mdooroYUYer+oAm6BuFCSJejRitQXIhDl+0rD1EzLo AhUxyvem2UZnNIsVXFKXfWtWhJp8V3EJeS2hvF75rcowZHG/gQoFM+06Oc+JGxS4Ahaj/PYiVHt mQuhbzC39jhEmMwFElWTB7errW1PC15LqgL4aAsNFzU9fJJyq1sTtpLNV8EcAoB73mIUPja3W2V WE= X-Received: by 2002:a05:600c:3e14:b0:47a:9560:ec28 with SMTP id 5b1f17b1804b1-4801e30b8ffmr2183025e9.13.1768491241530; Thu, 15 Jan 2026 07:34:01 -0800 (PST) Message-ID: Date: Thu, 15 Jan 2026 16:33:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Strange symbols_lookup() behaviour in test-symbols on arm64 CI To: Mykola Kvach Cc: Xen-devel , Volodymyr Babchuk References: <10aaed6d-6cb1-4bed-aa8c-5f9761f04fde@suse.com> <35819233-07ba-4e00-8939-74b2f4454250@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 14.01.2026 07:00, Mykola Kvach wrote: > On Mon, Dec 15, 2025 at 1:27 PM Jan Beulich wrote: >> On 15.12.2025 12:00, Mykola Kvach wrote: >>> On Thu, Dec 11, 2025 at 6:40 PM Jan Beulich wrote: >>>> On 11.12.2025 17:30, Mykola Kvach wrote: >>>>> I have now attached the corresponding build log. >>>> >>>> Okay, so indeed not a table size change issue here. Then I fear some instrumenting >>>> will be needed to at least know what exactly is going wrong. Alternatively you could >>>> arrange for the intermediate binaries to not be deleted, and make them available >>>> somehow / somewhere for me to see whether by inspection I can gain some clue. >>> >>> I prepared a small patch to keep the intermediate artifacts instead of >>> deleting them. >>> >>> It removes two cleanup commands: >>> xen/arch/arm/Makefile: drops rm -f $(@D)/.$(@F).[0-9]* (keeps >>> .xen-syms.* intermediates) >> >> This alone should be sufficient. > > Understood. I have rerun the build with the cleanup line removed > so the intermediate .xen-syms.* files are kept. > > The build artifacts are available here: > https://gitlab.com/xen-project/people/mykola_kvach/xen/-/jobs/12707528457/artifacts/browse/xen/ Apart from the intermediate files there's a file named xen there, but xen-syms is missing. I'll see what I can do without that. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 15:39:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 15:39:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205387.1519670 (Exim 4.92) (envelope-from ) id 1vgPRN-000715-9f; Thu, 15 Jan 2026 15:39:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205387.1519670; Thu, 15 Jan 2026 15: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 1vgPRN-00070y-6m; Thu, 15 Jan 2026 15:39:17 +0000 Received: by outflank-mailman (input) for mailman id 1205387; Thu, 15 Jan 2026 15:39: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 1vgPRL-00070s-MK for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 15:39:15 +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 580f6593-f228-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 16:39:14 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4801bc32725so3899485e9.0 for ; Thu, 15 Jan 2026 07:39:14 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af6e1b7bsm6546085f8f.34.2026.01.15.07.39.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 07:39:13 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 580f6593-f228-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768491553; x=1769096353; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=JidgEfI3Auog5+NvBHtFBi7soVJjFhRg70GZ295ltJY=; b=VYRUgIokBSiG0pl2iJzeeb5pJRyVKZsITbkL1Diy7bpczlkG/gpesCAA7HLpIIirvb +9QQNF1NEj/5cfWZcL1XR9cujnegsOpIK8Jk9euT/H4AmvXlz+wFN4LTFNsd4wEinL2r qlg6OLSXSPFlWczWdqLXtbq3hwtXNYa4aOFedYooE4imMeFPPnc0oX6Md1XDiRjmFPUR pSbqZ4sSuwgM7MCbFxqYMgItwLMf8k8SGvCke3WdTOJFMSzLQjwmVRDFMMn0dJhfK/pn jSDP/U8Tp71RWuxUWYpHm6ue16lLyyfQ2fpqq2jnf++d6GGpNarFjVl+tIGoRjA1wvFk 7/yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768491553; x=1769096353; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=JidgEfI3Auog5+NvBHtFBi7soVJjFhRg70GZ295ltJY=; b=rawSHCwwnXm7vxi7qdvxtdhQXrM9dNcjWAb2ttJnT4J66+ub5IC0dKrb306LDfC+0I AYZev6mit5OSaV6pXRMJvvMb0bUd96gZvG6YBP3LGIcNeY90UeByJIB6oFel5Aw8I8Ac 7XvSJCfPO5ICUvgnigimM/MPBk9cCMD11WDzlX6rw5nKg3OsUHYpwaiB0DFbYW8OSF8z Yz9zj0SGTJiPd8sGEZ3/FpMtE6l/US5wkPaWEiic9bCRoW2u5BxrTAYbvZDOd8daJM6R Nv/kHn3rWFdoyF3/WoxI5t0XUVJCXY2QizoxzPP4D05n4FgsYx/CVR3O389oNFjdnE2j adxg== X-Forwarded-Encrypted: i=1; AJvYcCWeJHYws5mXRpu3C+BKz/DptVDujL6guK4BXPQ87xcJoao/5uNgZFpi8bTXOAAx+a9stULofJUhBfg=@lists.xenproject.org X-Gm-Message-State: AOJu0YxWLICrhCRaNPQuStcSlDhWJ+ssJVfZM5zlLMsBPrdaO4py1YpQ n4/PMQFP5baJeTNscDn3qea0q3bk/zWsPLctrT3au0YyU5vHcnqRjJhEyo/fFSS3cQ== X-Gm-Gg: AY/fxX5ibRTwSXEs2wKLMWjGMXNTRhSKi9vQVULU8BNbr7UWOv6Gj6nkjOj7BXHjsGi pkY/a8OMxo5oOeereGzY5wQCP/Y0ZvWzLhK1FuUzvOxaEDKboCJtR4eT7Pm6OApqeMpHzft48vy aTixaT3XR7Qelbt9s+LD/cJNe1ojakB6dL6jm0dmjBjOToW4TH9020qCqfxpyh1B0byIlxjYFoU McvqtzDWXLidJ8iF407rwTm3GctL3/Sgqj/YRSb8joiMUZ+yCDbuvsF8PoO/wxJaDASOockeH+W JotsvuG+smJqt9RtcvvskJn3n8LxtnZMuweDFDz9A2frwFXQOp8JtpA0F2cWwKFrxfEiq5EzKW8 RhP14b+Z/qsFwBA/fRnm0gANF5qVIIgGgQaNRkZi9D46bYadKuGcRWuBiNW4TZH9C7UUPqpoWRQ poPSJjVObEiuBYySTDPAcMqa/xz/bIdbOMP3hqc2PWSzEmT/6rRdtMQ+djjazWVjqIv039TruyH cvCGgCBIdOfJQ== X-Received: by 2002:a05:600c:8b8c:b0:480:1c10:5633 with SMTP id 5b1f17b1804b1-4801e341a87mr2178615e9.26.1768491553475; Thu, 15 Jan 2026 07:39:13 -0800 (PST) Message-ID: <2703684c-4ad5-44e2-a8fc-4d5b40de2d3d@suse.com> Date: Thu, 15 Jan 2026 16:39:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 3/5] lib/arm: Add I/O memory copy helpers To: Oleksii Moisieiev Cc: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" References: <8539bed5-280f-4dcc-a63d-4c0ee3b7cff7@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 15.01.2026 16:34, Oleksii Moisieiev wrote: > On 15/01/2026 13:59, Jan Beulich wrote: >> On 15.01.2026 10:26, Jan Beulich wrote: >>> On 14.01.2026 19:29, Oleksii Moisieiev wrote: >>>> --- /dev/null >>>> +++ b/xen/lib/arm/memcpy_fromio.c >>>> @@ -0,0 +1,48 @@ >>>> +/* SPDX-License-Identifier: GPL-2.0-only */ >>>> +#include >>>> +#include >>>> + >>>> +/* >>>> + * Use 32-bit raw IO operations for portability across ARM32/ARM64 where >>>> + * 64-bit accessors may not be atomic and some devices only support 32-bit >>>> + * aligned accesses. >>>> + */ >>>> + >>>> +void memcpy_fromio(void *to, const volatile void __iomem *from, >>>> + size_t count) >>>> +{ >>>> + while ( count && (!IS_ALIGNED((unsigned long)from, 4) || >>>> + !IS_ALIGNED((unsigned long)to, 4)) ) >>> Nit: Xen style indentation (no hard tabs) please throughout. >>> >>>> + { >>>> + *(uint8_t *)to = __raw_readb(from); >>>> + from++; >>>> + to++; >>>> + count--; >>>> + } >>>> + >>>> + while ( count >= 4 ) >>>> + { >>>> + *(uint32_t *)to = __raw_readl(from); >>>> + from += 4; >>>> + to += 4; >>>> + count -= 4; >>>> + } >>>> + >>>> + while ( count ) >>>> + { >>>> + *(uint8_t *)to = __raw_readb(from); >>>> + from++; >>>> + to++; >>>> + count--; >>>> + } >>>> +} >>> Barrier requirements on Arm aren't quite clear to me here: Is it really correct >>> to use __raw_read{b,w,l}() here, rather than read{b,w,l}()? If it was, wouldn't >>> a barrier then be needed at the end of the function? >> Thinking about it, as the order of MMIO accesses needs to be guaranteed >> (unless you have extra information about the area's properties, like it >> being a video frame buffer), I'm pretty sure now that read{b,w,l}() needs >> using here. In fact the comment in the header says that it would handle >> "Memory ordering and barriers" when it doesn't look as if it did. >> >> Note how Linux looks to have grown multiple flavors: Besides >> memcpy_fromio() I can also spot at least fb_memcpy_fromio() and >> sdio_memcpy_fromio(). >> >>> And then, if it was read{b,w,l}() that is to be used here, what about all of >>> this would then still be Arm-specific? Hmm, I guess the IS_ALIGNED() on "to" is, >>> but that's Arm32-specific, with Arm64 not needing it? Plus then it's again not >>> exactly Arm-specific, but specific to all architectures where misaligned >>> accesses may fault. >> There's a bigger issue here, with access granularity (despite the header >> claiming "Implement alignment handling for devices requiring specific >> access sizes"). MMIO can behave in interesting ways. The header comment >> says nothing as to restrictions, i.e. when these functions may not be >> used. Yet consider a device registers of which must be accessed in 32-bit >> chunks. As long as the other pointer is suitably aligned, all would be >> fine. But you handle the case where it isn't, and hence that case then >> also needs to function correctly. At the same time accesses to a devices >> requiring 16- or 64bit granularity wouldn't work at all, which for >> required 8-bit granularity it would again only work partly. >> >> How much of the above requires code adjustments and how much should be >> dealt with by updating commentary I don't know, as I know nothing about >> your particular use case, nor about possible future ones. >> >> Also note that the header comment still references the ..._relaxed() >> functions, when then implementation doesn't use those anymore. >> >> Jan > Hi Jan, > > Thank you very much for your valuable input and involvement. > > After further research and reconsidering all the points you raised, I > have decided > to switch to using the ordered MMIO accessors (readb/readl and > writeb/writel). > > Here is my reasoning: > > The concern you mentioned was valid: the use of __raw_read*/__raw_write* > in the > helpers did not provide the ordering guarantees expected for MMIO > copies, and the > header still referenced *_relaxed, even though the implementation no > longer used > them. This could allow reordering around the copy and misrepresent the > intended > semantics. > > A few additional thoughts regarding your other questions: > > Is it still Arm-specific? > Functionally, the logic could work on any architecture that supports > 8/32-bit MMIO > accesses and uses the same accessor semantics. However, this implementation > relies on Arm’s read*/write* ordering guarantees, as well as the > Arm-specific > IS_ALIGNED check to avoid misaligned faults. Therefore, it remains > Arm-specific > as written; other architectures would need their own implementations if they > have different alignment or granularity requirements. > > Ordered accessors vs. raw accessors + trailing barrier: > I chose to use ordered accessors instead of raw accessors with a > trailing barrier > because readb/readl and writeb/writel already provide the required > device ordering > and barrier semantics, making an additional barrier unnecessary and > solving potential > ordering issues. > > Use for register access: > These helpers are suitable for MMIO buffers, shared memory, and > registers that > tolerate 8-/32-bit accesses. They are not appropriate for registers that > require 16- or 64-bit accesses, or where side effects depend on the exact > access width. I'll update the header to document this limitation; > drivers needing strict > register semantics should continue to use readl/writel > (or readw/writew/readq/writeq) directly, rather than memcpy_*io(). > > Summary: > > I have made the following changes to the helper functions: > > - switched to ordered accessors to address the ordering and barrier > concerns. > - updated the documentation to match the implementation and explicitly state > the supported access sizes and granularity. > > If this approach sounds good to you, I will proceed with the fix and > submit a new version. At the first glance it looks okay, but please allow Arm folks to give their opinion. And of course my final take will be available only once I see the next version. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 15:41:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 15:41:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205404.1519681 (Exim 4.92) (envelope-from ) id 1vgPTW-00006i-Qs; Thu, 15 Jan 2026 15:41:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205404.1519681; Thu, 15 Jan 2026 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 1vgPTW-00006b-N4; Thu, 15 Jan 2026 15:41:30 +0000 Received: by outflank-mailman (input) for mailman id 1205404; Thu, 15 Jan 2026 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 1vgPTV-00006T-6j for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 15:41:29 +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 a7fc5b0b-f228-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 16:41:28 +0100 (CET) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-652fdd043f9so2027998a12.1 for ; Thu, 15 Jan 2026 07:41:28 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6541209b8e6sm2932867a12.30.2026.01.15.07.41.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 07:41:27 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a7fc5b0b-f228-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768491688; x=1769096488; 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=u2D6QFyAr8NuX1z9WO0hjuOnj49SR8081LQJ1dRh8uk=; b=ErI8EtHIF0iLnrv34b7k8niPXtw4C331tenXk1eCehk20U3le04WMxS9R54L0+wugJ /kkfQJg4A1S5cM6jHjyU78cl45R6arB18gSv77OB5HdwIOiJIzi3CV09oDzfKs0LvQUr +bKvZcATT9QkYUJhtq/RLusiQcO5jctw14C0NoDRR2IS8JnFaJHbkHdFETpsI43p/dHV ClYH/poevwOQWoRUrqfuQTLVQ7RNE5Za/1dE/vmUSk6uDIIWDz81Qc9r36nEkgff3JK3 heqUWZdOG5cG3U3DrGy/62s3+LYiBENZZPz2qpRYkoGS1TC3bxvSw0As0xiwSwzBWhpW RqUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768491688; x=1769096488; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=u2D6QFyAr8NuX1z9WO0hjuOnj49SR8081LQJ1dRh8uk=; b=t8Im8sMHT9LhQq6yHYq/JvNQZ9+Q4B5WsZbenmtH+vidcQfkfwmVsCFwd6uo8VWMBy hyJKmIRJa9T5CgFJfpxDTKaBwG/GrGXZZkx7w1CRwz0K2w/kdDENUuc98ARhmimyhfWp qsRfEno1jTE7lymIc7Euwv7rs0YCcYfhXsEl7+gQGtdRRtDAK72QQkD4RhE0cYHkJUga g9O6Udgi+1RaEhB45U6B7pAKHEww61EW1CqItVvCjW0LB+FiJiUCP3HA6EgPX4D3tvC2 vOVuwleZih7MZKdAVUY+bEFwozeJRVJ5fcQC3qom2P+1+79wX7ms/+7n9nlFQhQmnad9 BIrg== X-Forwarded-Encrypted: i=1; AJvYcCWOt2CUjNRovKcg0mTGskFwmOWgmlfpU5whtacLxLqvhLY4CCE4kGe6gigWVc7TRwiupm4TC2v5SBY=@lists.xenproject.org X-Gm-Message-State: AOJu0YzAstcudzWhYG5dKSs7une3rBLIi68MlUiPrTx0f11CGe1ElhNR bUOg5QEM8b/MnWodrjdrUVwawVVc9Hzs/4f+PxdGK72wKXuSGw2WogUx X-Gm-Gg: AY/fxX5P6hUuaiIsVcThnZ2wRj67G2xSl45G2LAFGgCdMr79O9LB26gjStW1EdgjLff ZGYBm26dkAjKxeNkkZ5X4YxNzAOhkACKCSI3RPWuIQ4XicLwQA9ecqrjUIuT4J4Vb0AoPN8IDTM a3AVhhDfKOtI67gX3qCQXSJ057sjqP/uArCvy+2pzo+mqrcoNs0QaqULAUoY9qXy277b3ve7Mfr QghJ8AuYPME94nKQMbPqeXHj2pxuTZ0TCO/ZPx1jouo1ukZOUQr6PyFNDeuc51HA2EBFozFDL+C sm7qVek3Ifg76zJQKk57JMJ5bwst6FS/EJ4IzfKlzxG75ZHrLETQHMsWb6i3aQBKWDWkhio4l7e iRxRGsw4tmD+DLyMnZRSp2TTLrmjnJDfqpivYBWruU64f3mK7DZhdmNV/S4FHq+748SRXFamiJ9 dZ0bof0LSmnKvkm5O42fLe97tPeUGMkHYUKkaaumFNBPTSzZ0mdrLKi2jSJF9Ojoc= X-Received: by 2002:a05:6402:1d53:b0:649:5bb4:59e5 with SMTP id 4fb4d7f45d1cf-653ee2acb50mr5194153a12.30.1768491687467; Thu, 15 Jan 2026 07:41:27 -0800 (PST) Message-ID: Date: Thu, 15 Jan 2026 16:41:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/riscv: dump CSRs on unexpected traps To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260115125601.70834-1-oleksii.kurochko@gmail.com> <8377bdc2-d92d-4c3f-893b-19c842cad3a7@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <8377bdc2-d92d-4c3f-893b-19c842cad3a7@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/15/26 2:12 PM, Jan Beulich wrote: >> static void do_unexpected_trap(const struct cpu_user_regs *regs) >> { >> unsigned long cause = csr_read(CSR_SCAUSE); >> >> printk("Unhandled exception: %s\n", decode_cause(cause)); >> >> + dump_csrs(cause); >> + >> die(); >> } > Apart from CSRs, how about also dumping GPRs? Just to double-check, do you mean GPRs which are stired in regs argument of do_unexpected_trap? ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Jan 15 15:42:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 15:42:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205412.1519691 (Exim 4.92) (envelope-from ) id 1vgPUZ-0000cY-2g; Thu, 15 Jan 2026 15:42:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205412.1519691; Thu, 15 Jan 2026 15:42:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgPUY-0000cR-W1; Thu, 15 Jan 2026 15:42:34 +0000 Received: by outflank-mailman (input) for mailman id 1205412; Thu, 15 Jan 2026 15:42: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 1vgPUW-0000cC-Uw for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 15:42:33 +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 cdae2ab4-f228-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 16:42:31 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by GV1PR03MB8094.eurprd03.prod.outlook.com (2603:10a6:150:1d::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.6; Thu, 15 Jan 2026 15:42: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.9520.005; Thu, 15 Jan 2026 15:42:25 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cdae2ab4-f228-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=PPjENYKW+cbYfY3HCgb6RHtxGx5dex45nPSaDr9hGO7xqUbaS7QwwiLUJ0e3VuEvH8dlkhEqAuNrnjBNHh+XqdX/RuxiI3DTNn95dtT1OIjpZx2nSEMDN+tYxd+8QHbHTvoPbAqw+CISDyL8P7zFB/DyV/qx5ivl89oFwSQtbGVrB+ZiNJMc7YJgN7ORh1stAXZFPAxXIwhmqFAOzUNpGOf2xMh4dhAuJy7m3fsFoEyTRv0ro4n/Y22MhOHUpJiWIjbGvKzm09cZCKkMqdqbkc9gRcf0IFWJkG12j+qOa84DBGrnriW3qtAaYxaA8hzeiOO4bzOPcAplDyk7U23r5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nBBnCnh2Fafd9vf3Iw4VPpFY5LszCz06xBd2Kkjfj5M=; b=dd/fle+8yY+gdUI13yJG1JUd0lmqUgjNal9HH5DLdbq3UZKXSLAoQXE4K5PRHdgOcAcVqDRPw/0lzzuhacrIlHpJ82i2hXAaMwnuEK3k7VGmhqudJdpd58ifHaL6VZBcpOzVphp0rKXmD8GycIG4VWHiHzK2VcwCW6Tewa53Y7+/e61u7WtMM/IpWQORhbTlpMw/WqJO7mwLYHs4Q40XRrTYElP255Qt2VuiN+Rkpx+z1+j21OEOWzk6/HaJvcfnyw+TLvF+VpjrCvjI41MKJxUvE1S9OxqRvBEtCgAGcQIawbvycqw2Ns+Kpo88Vqu9SCKSsU+3eKfUEvmYxssubA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nBBnCnh2Fafd9vf3Iw4VPpFY5LszCz06xBd2Kkjfj5M=; b=SNzMMLkURIkJ4dbY1LKmh2MHRUfY2b566+tqkuSAMrKklZKZM9Oi7GrHSqL0eG70CCyo8rHKY7M7WcKqxlog4AeDZR2BqkBK5i9V/H9VlPzEa0y4sb6iK/rYd2VIvudzuXy/mg+JI0Ne13FNFXh6Ft2IYvAdPY8XnlvZYhTq0WyH14Rl/wNpCypTwc2C/4AFnj70Jr0i+A7y6U+2jMOkrpacxC5QrJGQ7oMvkkiqEpmBOGd6RqSyFoujOKPYVsulmzGMB9+0GICeSf6Z+JZ2ZEiO4OGWoAzSX2EOvHrQIax1ld8CSa/lIg3++8YpPxop/R9D8PslxzRDY021ouSH+Q== From: Oleksii Moisieiev To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v7 3/5] lib/arm: Add I/O memory copy helpers Thread-Topic: [PATCH v7 3/5] lib/arm: Add I/O memory copy helpers Thread-Index: AQHchYPD+fwQGyuKXEKqeHI8xFGbqLVS9u+AgAAq8ACAADvNAIAAAX0AgAAA5QA= Date: Thu, 15 Jan 2026 15:42:25 +0000 Message-ID: <3ea6dda4-a9ab-42ff-9150-8cce7e7888b7@epam.com> References: <8539bed5-280f-4dcc-a63d-4c0ee3b7cff7@suse.com> <2703684c-4ad5-44e2-a8fc-4d5b40de2d3d@suse.com> In-Reply-To: <2703684c-4ad5-44e2-a8fc-4d5b40de2d3d@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_|GV1PR03MB8094:EE_ x-ms-office365-filtering-correlation-id: 885ded57-81c9-4643-37f8-08de544caea7 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|41320700013|1800799024|366016|7416014|38070700021; x-microsoft-antispam-message-info: =?utf-8?B?QmNjTC8yd0c1VXdqT2E2bkRyem1BUUptZ2dVWVZWTktXclE5NlEwRC9MOENM?= =?utf-8?B?WFBHL1loM3dSNWhqeGZuMWpCMjJEK0FYY2Q1U3JjYUgyR3pkOTlpellVeTB4?= =?utf-8?B?SVdIdXFOVHo5bDFBbWVhK1ZpTWd4N2Z5cGk3TkoySW4xdlllVi9odWo3bHpn?= =?utf-8?B?NFRyMWRGZU1oakozTG5pTzZYSlI2N0daUlpLcnhtNjkvMG9VODlHQmRGVmQz?= =?utf-8?B?ajY5WHpjaWN4c3dDWGpleU1qUTR0bjhwbmN5ZDVrYW1tNGtUYnhQaC9Lc3VK?= =?utf-8?B?eGo2WnhFNEhHeVRPQlY1SzJMZStXK05hYUVvdFVuM2tSM0FQVmFSUVNKY3VH?= =?utf-8?B?QzZmcUEyRHA3WnlqOTRhTGZDZU5vSjh6YStBdFhIcEJLL1BKdFFab1FCQ3BY?= =?utf-8?B?ZE81ZEl0VWZDYVRWWjhRZksweWYzcXd4b0pTbXFFaDYrNlFFWk80Z2UwMjRz?= =?utf-8?B?WkVLckFTOEtyZWtZcjZ4d1lPZElRZmQ2UzVseVdwd3p0dEZmOWRydkZFZXEw?= =?utf-8?B?TnNwRUZoUkdxSUdqbEcwalVwRDRvc0lOTG5MbG9zRVJrWUlhQlZodzVrWEtp?= =?utf-8?B?aXNsK0N0OFpNalkzLzcrb0lBYkVMNjdvY28vODAxKzJ0cmVBWmVvcE5JZGVO?= =?utf-8?B?VVgrL0xqUUQvUFppNUtuZElXT3V1amllay83aCtjUnpWbFNXL3VLOW5OSlJo?= =?utf-8?B?MmdjcG12eXBRZnJoWXdpOTdOVHg3REo0MkI2Wlpab2dXMFk3VW1ZNjJMdWVT?= =?utf-8?B?dDIzVlN2MG53SllBbTAzVm1FbWZUbDRHQjdmVjVXQmw4R0ZHZFdndnpKM2VG?= =?utf-8?B?RkN1T2NhSENYM1NIdGh6eVVEbzdIK3IwOEp0WGFVNUVsVVk5U2x4VHhEbTdY?= =?utf-8?B?am1rSkQxdFpmajBaV1RlbDRyNHFnZVIyVkViMkVvRW9Ub0JGRTVMRGtjYWZZ?= =?utf-8?B?cE1iRE0xOFlFWU9PK1ZMSk1hSUhJa1B3cXF5TFk3UzZaN2gvSzMxTmhhMkRP?= =?utf-8?B?SVVmZVlsN2F2WmtIQXA2ZHg2OUdrV0VMeHhHeURpc2E2Qm1CZCtjd0swdFdk?= =?utf-8?B?bitHVzRhREhseTJXNEdmWDZ5b0ozdTNMYWdZQm9UaVJxTnNpa3M1b1pHbGdq?= =?utf-8?B?S0hlQ0lHVUhwTDdGOTNNMEU5enE2N0dGanBWQ212K2l4Uytra1JUSGc0K0Jx?= =?utf-8?B?UktjWTdTS2JuamQwTzJmWlkrMjNYdGVweDhhbSs4RlZ1M05aM0VhbHpvdmoy?= =?utf-8?B?dExjczV2N21pVlYzTzFJZ0x3OUhFaWRZa25NUzc3ODd0YXloV1huNStjczg2?= =?utf-8?B?OEJTUTFwaGNrVzRIQ25nQU91MDJOdXlEWHZlUjQ5SWxvbnMxUis2cnMrWi9K?= =?utf-8?B?eFVibzhGakpBd0Q3UFFSS1pvck0wdWNaR3ZMdHcveVF1N1JJTTdMUDRPZkhz?= =?utf-8?B?MDFUSVEydGFuVXZXcWJJRkZXMGhaVEgySzFhd2M3Tzc4b1RZZVJFOVdtVmFG?= =?utf-8?B?UE5aYmNwN05tMEhvMWpQUEhJR3dnM1lhaURGNFIvbUptSTQ5ZHQ1cVUrY2xU?= =?utf-8?B?OE5yU0RwanhrcGFWSmtiTE1wd3ZMNHJrZCtDVXRWRUZnY0dTRWVtRytwZVZt?= =?utf-8?B?UFBCKzVJT3IyK3JIcTJZRWEwSU55aGdUYjNhUy9iUXF1ZDRHSnFzd0E2OVNq?= =?utf-8?B?Qm9yUlAyb1k2aGJFOTBlT2FSMytoRXdNeTlOcjJiWTFLcHN4VWdLWnJHcllp?= =?utf-8?B?ZnBoMnlvUXIwelBwR045dTFFK3Nzc0JjSEpBTEpnVmE5bmlpWElGWmthUStM?= =?utf-8?B?OGk4VGZUSmJaYjdUaTRtUmlOdXJmZVpOTEJsbm5VdEVocVBKUkphNDFkU0lw?= =?utf-8?B?aDZnd2NqT3l6eWRMdDIzNVc2dmNrQTFOaHg2N2UzN2JPTlhHaEY0WFQ4MVli?= =?utf-8?B?cEpVNm1aQ254aXQ1aTA2bCttbUJzdUlWV2FYWXdDVFR1ZVVqS3o0NTBDaGpm?= =?utf-8?B?WDVVMXJjdEtMbnliTWhId09SLzJYQnlyS29GVHBYT1V2S01DcFpPWVlzWHdJ?= =?utf-8?B?K0RPbVM2cFY2cnNQMFJNZkd2Z0RvSHZ2VG9pNmpTbGxzZmJyYTIzR3NRRjRj?= =?utf-8?B?SEJyQjNhMUdqZHFwWjdkMVRoTVlqZ2NBQjhhNG1GQlRFNm5lODhlTjltb0FV?= =?utf-8?Q?quQ5yWZobpUn8TBuOgmad70=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)(41320700013)(1800799024)(366016)(7416014)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?YVRoaU1uUFFYUXB6SWZNUFVZeFZxTnFid1c0MXB3ZzFyZk9pejN1aGJNMTNB?= =?utf-8?B?aGdQaFJuNC9HK21CS2NSNkc4QlBCS3JweGl5M0dUUm9yT1lrY3dVRytKUkZJ?= =?utf-8?B?NDFxV1QzVEFCUnhLdTRlRWZVbWx5Vng4azdFRmR4WERpZXAvVUxRRlBqYXpO?= =?utf-8?B?cExGTSs1NWNlQnBYeStjNG9mOGFTb3BTeVU4bXErZ3RFdFBNTDVxaGpTWUZG?= =?utf-8?B?YUhQekFwV1hIWWxIWWNpR1hvelNZZ0lrQVVGeW9jZlRZUWlKU2wrOGJqWTlR?= =?utf-8?B?aDFrRjRQNFRGVmtEQzZBWG9WNm9iZ0VTb3UzcHRmdEMzNjhmMURMUTB5QURn?= =?utf-8?B?aDRLV05sQVNpakt6QmZzZG5YRzRGUUU5TXNwRTRDYWVtTzFKNStXa2Y1VWxp?= =?utf-8?B?RS9XUk9neG84Q3dQVFdSYnl1NzhEdVJ2Yi9HK2dMeEVyTUlqQnB1Q2t0TldL?= =?utf-8?B?VEdiMHRDa21rMTVGRS9GckRVQ2FKVkdCeXFYd2xUQTYxOUpOclpEQkFFZnpw?= =?utf-8?B?UkVDSEZoTjNlWWtmOTBYRjJLeWh1Z2c0RHk2QWVnZHpCWHd6TUhNaHo1amta?= =?utf-8?B?WnBaVlltQU1QZXRlSWl3MFFueTBocnN2UlI5cndsN2F5TEJJL2traHh3c0o0?= =?utf-8?B?a0lZSFBHRWVyWldOcTRYanROaHFmK3JXQk5POENWRnY5VEJuMnFMYzQ1dEpS?= =?utf-8?B?aGRZbXFuN1kzRWpQamFMUWR0N3hjZ05jMUxzRHJPOVB0T2JkOFAxMnFkZUtJ?= =?utf-8?B?cXhpZ05UQTk5N1RHR09rK1RXWDkrRG1VaXg0bjFROXFhNzhVN2RoYmxpNDlJ?= =?utf-8?B?TlJrQllZTzZPQ25JOWkrNmJ2emdxbC9Cd2xUN0pqM1ZiZGN3cndNUkoxV1g0?= =?utf-8?B?QnRvQ000MVhQM2JHeHhLQnd1NGd1QTZhejlZb2dJL3VuWkJWa2RmUGd2ZXgz?= =?utf-8?B?TEJkTE12S3VMdUdydUhGWHdHVzBLQWNVOTJ0c2FoMlFMU3FpbXFKODM4WDk2?= =?utf-8?B?V0x1UkdFUVhMNWVIeE5Ld0p3MGJsZEI5d1gxeFlWYjF6RURwZ0l2ZU5abERY?= =?utf-8?B?bVJ2dk1IazdZeVROVHVGTlNtRjRmOHozb0tnbTRaTWtUc2NIYXhQSVNOZzZ6?= =?utf-8?B?YmdUU0FsZWN1QWNzMFlBY1JwMWEwL3FVTXdzMjBSK09iZWRWNDlQRDUrVUIr?= =?utf-8?B?eFJwMTRFZUlMZ2hCSFFQYUhkYm8zZzNBK25UNlhpWTBQRFJUZzNnUVVBa1BW?= =?utf-8?B?aUY4RXlaVHY5Q2ZlaWtmeVd2WFlTbURQWFp6cUxPamYvd1FJUHVsdVQrRmRU?= =?utf-8?B?SWtoYjNmaXhMa3ZuYklTcTZXK0N6dEd0MW1tN1dlOGFEK3BZQlhkWjd6MUZa?= =?utf-8?B?RHhyZGZLREJoQWZKbVVXM1k0VmdpdzBXMUU3TWJDNUhVUENXL0Y0NHhpejV6?= =?utf-8?B?QzVGeHIycjZvajNabWtrR0w4d09xc3RPY1Y5aHVFQzF6aHJGSE1Pem9HSFMx?= =?utf-8?B?dXhhMCtPKy91ejJkVmVRZEdUakhabER0L1FkMTd3QnBuNnFraFBZcUNmVm1j?= =?utf-8?B?OTNzZ05xandCWGwxTFFERldvOXp6MkxJamJiNHViUFB3NVRadkxUZ0J5NEdy?= =?utf-8?B?QmQxNCs3cWNQczFkOEF4VUk1bWdjTnJWWEhLMi9HYmcxN0lxQ0NtOXRmejYy?= =?utf-8?B?TTZsQlhpeVpWY3JNMG5lQ2h6MWowL01FUzBXaTliRGZmbjAxcFVSRHBxK0hC?= =?utf-8?B?R0p2bk9ja0J3dXc5RzFTdXJ3QWVKTndQQjZ6emVreE5sV2g5aDZHd1hHTy93?= =?utf-8?B?R3VoZUdzaWF4aVBIOEIvSG5GaUFxRHI2eDJLeUhOTlpwdDhJMXBTM0JTbzZ1?= =?utf-8?B?VGViSzRCaHdpZC9jaUEzMzRML2VsYnlESTFmZVRFUFNMZ3ozTE1MWjFESTlr?= =?utf-8?B?SXNIL2lxNXhaSWIrWXdvblQvTC9LNUUyL0taL1dUeDhhSnZWT3huLzlsSzVX?= =?utf-8?B?SUNSOVVTV0JDV1lrL0NjUVhFUWdGQVc4Y0FjcE9RdllDYlM5bExPY0NsWVlM?= =?utf-8?B?eUVaS05CVWdPeU9zTnFLZkVtZE9HQ0J1STBVbzNNcHlBZFdjNzNObVFuRkVE?= =?utf-8?B?cDEyMUlvallQZFNiY3NQT0NtNEQxOXpiTTBXbGoxNm83VGtTeHlFOHljQkpV?= =?utf-8?B?aXNRZDJPRmhkaDB0dnNUVHZWM0VuV250c0hXM2g4eHhKT0VoV2VIaC95Q1Vj?= =?utf-8?B?ZENwSk5zeU5zRGVYZ2xuR0d1aHB2VlVtY3pnWlA4ZENIbDRMYXdTNHF6dTVY?= =?utf-8?B?YlZicDVqSWNldGlHU2k0L2ZlUjJkM2QvNEFpc0IzNm9UNlcwbG83WTN4WjJM?= =?utf-8?Q?ajSmZ5q0IYxovMIA=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: PAVPR03MB8946.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 885ded57-81c9-4643-37f8-08de544caea7 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2026 15:42:25.7598 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9b1C4+YkeT3+gBr9xYf2R5EKJiAbCFaX4mTSER1DUXeR5DhT7lvjzSn029RwwnpjTU1lMUHP7tNqVUoa3V6pB1jF/9Uf6liX7Ka1kViRpBM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB8094 DQoNCk9uIDE1LzAxLzIwMjYgMTc6MzksIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxNS4wMS4y MDI2IDE2OjM0LCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToNCj4+IE9uIDE1LzAxLzIwMjYgMTM6 NTksIEphbiBCZXVsaWNoIHdyb3RlOg0KPj4+IE9uIDE1LjAxLjIwMjYgMTA6MjYsIEphbiBCZXVs aWNoIHdyb3RlOg0KPj4+PiBPbiAxNC4wMS4yMDI2IDE5OjI5LCBPbGVrc2lpIE1vaXNpZWlldiB3 cm90ZToNCj4+Pj4+IC0tLSAvZGV2L251bGwNCj4+Pj4+ICsrKyBiL3hlbi9saWIvYXJtL21lbWNw eV9mcm9taW8uYw0KPj4+Pj4gQEAgLTAsMCArMSw0OCBAQA0KPj4+Pj4gKy8qIFNQRFgtTGljZW5z ZS1JZGVudGlmaWVyOiBHUEwtMi4wLW9ubHkgKi8NCj4+Pj4+ICsjaW5jbHVkZSA8YXNtL2lvLmg+ DQo+Pj4+PiArI2luY2x1ZGUgPHhlbi9saWIvaW8uaD4NCj4+Pj4+ICsNCj4+Pj4+ICsvKg0KPj4+ Pj4gKyAqIFVzZSAzMi1iaXQgcmF3IElPIG9wZXJhdGlvbnMgZm9yIHBvcnRhYmlsaXR5IGFjcm9z cyBBUk0zMi9BUk02NCB3aGVyZQ0KPj4+Pj4gKyAqIDY0LWJpdCBhY2Nlc3NvcnMgbWF5IG5vdCBi ZSBhdG9taWMgYW5kIHNvbWUgZGV2aWNlcyBvbmx5IHN1cHBvcnQgMzItYml0DQo+Pj4+PiArICog YWxpZ25lZCBhY2Nlc3Nlcy4NCj4+Pj4+ICsgKi8NCj4+Pj4+ICsNCj4+Pj4+ICt2b2lkIG1lbWNw eV9mcm9taW8odm9pZCAqdG8sIGNvbnN0IHZvbGF0aWxlIHZvaWQgX19pb21lbSAqZnJvbSwNCj4+ Pj4+ICsJCSAgIHNpemVfdCBjb3VudCkNCj4+Pj4+ICt7DQo+Pj4+PiArCXdoaWxlICggY291bnQg JiYgKCFJU19BTElHTkVEKCh1bnNpZ25lZCBsb25nKWZyb20sIDQpIHx8DQo+Pj4+PiArCQkJICAh SVNfQUxJR05FRCgodW5zaWduZWQgbG9uZyl0bywgNCkpICkNCj4+Pj4gTml0OiBYZW4gc3R5bGUg aW5kZW50YXRpb24gKG5vIGhhcmQgdGFicykgcGxlYXNlIHRocm91Z2hvdXQuDQo+Pj4+DQo+Pj4+ PiArCXsNCj4+Pj4+ICsJCSoodWludDhfdCAqKXRvID0gX19yYXdfcmVhZGIoZnJvbSk7DQo+Pj4+ PiArCQlmcm9tKys7DQo+Pj4+PiArCQl0bysrOw0KPj4+Pj4gKwkJY291bnQtLTsNCj4+Pj4+ICsJ fQ0KPj4+Pj4gKw0KPj4+Pj4gKwl3aGlsZSAoIGNvdW50ID49IDQgKQ0KPj4+Pj4gKwl7DQo+Pj4+ PiArCQkqKHVpbnQzMl90ICopdG8gPSBfX3Jhd19yZWFkbChmcm9tKTsNCj4+Pj4+ICsJCWZyb20g Kz0gNDsNCj4+Pj4+ICsJCXRvICs9IDQ7DQo+Pj4+PiArCQljb3VudCAtPSA0Ow0KPj4+Pj4gKwl9 DQo+Pj4+PiArDQo+Pj4+PiArCXdoaWxlICggY291bnQgKQ0KPj4+Pj4gKwl7DQo+Pj4+PiArCQkq KHVpbnQ4X3QgKil0byA9IF9fcmF3X3JlYWRiKGZyb20pOw0KPj4+Pj4gKwkJZnJvbSsrOw0KPj4+ Pj4gKwkJdG8rKzsNCj4+Pj4+ICsJCWNvdW50LS07DQo+Pj4+PiArCX0NCj4+Pj4+ICt9DQo+Pj4+ IEJhcnJpZXIgcmVxdWlyZW1lbnRzIG9uIEFybSBhcmVuJ3QgcXVpdGUgY2xlYXIgdG8gbWUgaGVy ZTogSXMgaXQgcmVhbGx5IGNvcnJlY3QNCj4+Pj4gdG8gdXNlIF9fcmF3X3JlYWR7Yix3LGx9KCkg aGVyZSwgcmF0aGVyIHRoYW4gcmVhZHtiLHcsbH0oKT8gSWYgaXQgd2FzLCB3b3VsZG4ndA0KPj4+ PiBhIGJhcnJpZXIgdGhlbiBiZSBuZWVkZWQgYXQgdGhlIGVuZCBvZiB0aGUgZnVuY3Rpb24/DQo+ Pj4gVGhpbmtpbmcgYWJvdXQgaXQsIGFzIHRoZSBvcmRlciBvZiBNTUlPIGFjY2Vzc2VzIG5lZWRz IHRvIGJlIGd1YXJhbnRlZWQNCj4+PiAodW5sZXNzIHlvdSBoYXZlIGV4dHJhIGluZm9ybWF0aW9u IGFib3V0IHRoZSBhcmVhJ3MgcHJvcGVydGllcywgbGlrZSBpdA0KPj4+IGJlaW5nIGEgdmlkZW8g ZnJhbWUgYnVmZmVyKSwgSSdtIHByZXR0eSBzdXJlIG5vdyB0aGF0IHJlYWR7Yix3LGx9KCkgbmVl ZHMNCj4+PiB1c2luZyBoZXJlLiBJbiBmYWN0IHRoZSBjb21tZW50IGluIHRoZSBoZWFkZXIgc2F5 cyB0aGF0IGl0IHdvdWxkIGhhbmRsZQ0KPj4+ICJNZW1vcnkgb3JkZXJpbmcgYW5kIGJhcnJpZXJz IiB3aGVuIGl0IGRvZXNuJ3QgbG9vayBhcyBpZiBpdCBkaWQuDQo+Pj4NCj4+PiBOb3RlIGhvdyBM aW51eCBsb29rcyB0byBoYXZlIGdyb3duIG11bHRpcGxlIGZsYXZvcnM6IEJlc2lkZXMNCj4+PiBt ZW1jcHlfZnJvbWlvKCkgSSBjYW4gYWxzbyBzcG90IGF0IGxlYXN0IGZiX21lbWNweV9mcm9taW8o KSBhbmQNCj4+PiBzZGlvX21lbWNweV9mcm9taW8oKS4NCj4+Pg0KPj4+PiBBbmQgdGhlbiwgaWYg aXQgd2FzIHJlYWR7Yix3LGx9KCkgdGhhdCBpcyB0byBiZSB1c2VkIGhlcmUsIHdoYXQgYWJvdXQg YWxsIG9mDQo+Pj4+IHRoaXMgd291bGQgdGhlbiBzdGlsbCBiZSBBcm0tc3BlY2lmaWM/IEhtbSwg SSBndWVzcyB0aGUgSVNfQUxJR05FRCgpIG9uICJ0byIgaXMsDQo+Pj4+IGJ1dCB0aGF0J3MgQXJt MzItc3BlY2lmaWMsIHdpdGggQXJtNjQgbm90IG5lZWRpbmcgaXQ/IFBsdXMgdGhlbiBpdCdzIGFn YWluIG5vdA0KPj4+PiBleGFjdGx5IEFybS1zcGVjaWZpYywgYnV0IHNwZWNpZmljIHRvIGFsbCBh cmNoaXRlY3R1cmVzIHdoZXJlIG1pc2FsaWduZWQNCj4+Pj4gYWNjZXNzZXMgbWF5IGZhdWx0Lg0K Pj4+IFRoZXJlJ3MgYSBiaWdnZXIgaXNzdWUgaGVyZSwgd2l0aCBhY2Nlc3MgZ3JhbnVsYXJpdHkg KGRlc3BpdGUgdGhlIGhlYWRlcg0KPj4+IGNsYWltaW5nICJJbXBsZW1lbnQgYWxpZ25tZW50IGhh bmRsaW5nIGZvciBkZXZpY2VzIHJlcXVpcmluZyBzcGVjaWZpYw0KPj4+IGFjY2VzcyBzaXplcyIp LiBNTUlPIGNhbiBiZWhhdmUgaW4gaW50ZXJlc3Rpbmcgd2F5cy4gVGhlIGhlYWRlciBjb21tZW50 DQo+Pj4gc2F5cyBub3RoaW5nIGFzIHRvIHJlc3RyaWN0aW9ucywgaS5lLiB3aGVuIHRoZXNlIGZ1 bmN0aW9ucyBtYXkgbm90IGJlDQo+Pj4gdXNlZC4gWWV0IGNvbnNpZGVyIGEgZGV2aWNlIHJlZ2lz dGVycyBvZiB3aGljaCBtdXN0IGJlIGFjY2Vzc2VkIGluIDMyLWJpdA0KPj4+IGNodW5rcy4gQXMg bG9uZyBhcyB0aGUgb3RoZXIgcG9pbnRlciBpcyBzdWl0YWJseSBhbGlnbmVkLCBhbGwgd291bGQg YmUNCj4+PiBmaW5lLiBCdXQgeW91IGhhbmRsZSB0aGUgY2FzZSB3aGVyZSBpdCBpc24ndCwgYW5k IGhlbmNlIHRoYXQgY2FzZSB0aGVuDQo+Pj4gYWxzbyBuZWVkcyB0byBmdW5jdGlvbiBjb3JyZWN0 bHkuIEF0IHRoZSBzYW1lIHRpbWUgYWNjZXNzZXMgdG8gYSBkZXZpY2VzDQo+Pj4gcmVxdWlyaW5n IDE2LSBvciA2NGJpdCBncmFudWxhcml0eSB3b3VsZG4ndCB3b3JrIGF0IGFsbCwgd2hpY2ggZm9y DQo+Pj4gcmVxdWlyZWQgOC1iaXQgZ3JhbnVsYXJpdHkgaXQgd291bGQgYWdhaW4gb25seSB3b3Jr IHBhcnRseS4NCj4+Pg0KPj4+IEhvdyBtdWNoIG9mIHRoZSBhYm92ZSByZXF1aXJlcyBjb2RlIGFk anVzdG1lbnRzIGFuZCBob3cgbXVjaCBzaG91bGQgYmUNCj4+PiBkZWFsdCB3aXRoIGJ5IHVwZGF0 aW5nIGNvbW1lbnRhcnkgSSBkb24ndCBrbm93LCBhcyBJIGtub3cgbm90aGluZyBhYm91dA0KPj4+ IHlvdXIgcGFydGljdWxhciB1c2UgY2FzZSwgbm9yIGFib3V0IHBvc3NpYmxlIGZ1dHVyZSBvbmVz Lg0KPj4+DQo+Pj4gQWxzbyBub3RlIHRoYXQgdGhlIGhlYWRlciBjb21tZW50IHN0aWxsIHJlZmVy ZW5jZXMgdGhlIC4uLl9yZWxheGVkKCkNCj4+PiBmdW5jdGlvbnMsIHdoZW4gdGhlbiBpbXBsZW1l bnRhdGlvbiBkb2Vzbid0IHVzZSB0aG9zZSBhbnltb3JlLg0KPj4+DQo+Pj4gSmFuDQo+PiBIaSBK YW4sDQo+Pg0KPj4gVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciB2YWx1YWJsZSBpbnB1dCBh bmQgaW52b2x2ZW1lbnQuDQo+Pg0KPj4gQWZ0ZXIgZnVydGhlciByZXNlYXJjaCBhbmQgcmVjb25z aWRlcmluZyBhbGwgdGhlIHBvaW50cyB5b3UgcmFpc2VkLCBJDQo+PiBoYXZlIGRlY2lkZWQNCj4+ IHRvIHN3aXRjaCB0byB1c2luZyB0aGUgb3JkZXJlZCBNTUlPIGFjY2Vzc29ycyAocmVhZGIvcmVh ZGwgYW5kDQo+PiB3cml0ZWIvd3JpdGVsKS4NCj4+DQo+PiBIZXJlIGlzIG15IHJlYXNvbmluZzoN Cj4+DQo+PiBUaGUgY29uY2VybiB5b3UgbWVudGlvbmVkIHdhcyB2YWxpZDogdGhlIHVzZSBvZiBf X3Jhd19yZWFkKi9fX3Jhd193cml0ZSoNCj4+IGluIHRoZQ0KPj4gaGVscGVycyBkaWQgbm90IHBy b3ZpZGUgdGhlIG9yZGVyaW5nIGd1YXJhbnRlZXMgZXhwZWN0ZWQgZm9yIE1NSU8NCj4+IGNvcGll cywgYW5kIHRoZQ0KPj4gaGVhZGVyIHN0aWxsIHJlZmVyZW5jZWQgKl9yZWxheGVkLCBldmVuIHRo b3VnaCB0aGUgaW1wbGVtZW50YXRpb24gbm8NCj4+IGxvbmdlciB1c2VkDQo+PiB0aGVtLiBUaGlz IGNvdWxkIGFsbG93IHJlb3JkZXJpbmcgYXJvdW5kIHRoZSBjb3B5IGFuZCBtaXNyZXByZXNlbnQg dGhlDQo+PiBpbnRlbmRlZA0KPj4gc2VtYW50aWNzLg0KPj4NCj4+IEEgZmV3IGFkZGl0aW9uYWwg dGhvdWdodHMgcmVnYXJkaW5nIHlvdXIgb3RoZXIgcXVlc3Rpb25zOg0KPj4NCj4+IElzIGl0IHN0 aWxsIEFybS1zcGVjaWZpYz8NCj4+IEZ1bmN0aW9uYWxseSwgdGhlIGxvZ2ljIGNvdWxkIHdvcmsg b24gYW55IGFyY2hpdGVjdHVyZSB0aGF0IHN1cHBvcnRzDQo+PiA4LzMyLWJpdCBNTUlPDQo+PiBh Y2Nlc3NlcyBhbmQgdXNlcyB0aGUgc2FtZSBhY2Nlc3NvciBzZW1hbnRpY3MuIEhvd2V2ZXIsIHRo aXMgaW1wbGVtZW50YXRpb24NCj4+IHJlbGllcyBvbiBBcm3igJlzIHJlYWQqL3dyaXRlKiBvcmRl cmluZyBndWFyYW50ZWVzLCBhcyB3ZWxsIGFzIHRoZQ0KPj4gQXJtLXNwZWNpZmljDQo+PiBJU19B TElHTkVEIGNoZWNrIHRvIGF2b2lkIG1pc2FsaWduZWQgZmF1bHRzLiBUaGVyZWZvcmUsIGl0IHJl bWFpbnMNCj4+IEFybS1zcGVjaWZpYw0KPj4gYXMgd3JpdHRlbjsgb3RoZXIgYXJjaGl0ZWN0dXJl cyB3b3VsZCBuZWVkIHRoZWlyIG93biBpbXBsZW1lbnRhdGlvbnMgaWYgdGhleQ0KPj4gaGF2ZSBk aWZmZXJlbnQgYWxpZ25tZW50IG9yIGdyYW51bGFyaXR5IHJlcXVpcmVtZW50cy4NCj4+DQo+PiBP cmRlcmVkIGFjY2Vzc29ycyB2cy4gcmF3IGFjY2Vzc29ycyArIHRyYWlsaW5nIGJhcnJpZXI6DQo+ PiBJIGNob3NlIHRvIHVzZSBvcmRlcmVkIGFjY2Vzc29ycyBpbnN0ZWFkIG9mIHJhdyBhY2Nlc3Nv cnMgd2l0aCBhDQo+PiB0cmFpbGluZyBiYXJyaWVyDQo+PiBiZWNhdXNlIHJlYWRiL3JlYWRsIGFu ZCB3cml0ZWIvd3JpdGVsIGFscmVhZHkgcHJvdmlkZSB0aGUgcmVxdWlyZWQNCj4+IGRldmljZSBv cmRlcmluZw0KPj4gYW5kIGJhcnJpZXIgc2VtYW50aWNzLCBtYWtpbmcgYW4gYWRkaXRpb25hbCBi YXJyaWVyIHVubmVjZXNzYXJ5IGFuZA0KPj4gc29sdmluZyBwb3RlbnRpYWwNCj4+IG9yZGVyaW5n IGlzc3Vlcy4NCj4+DQo+PiBVc2UgZm9yIHJlZ2lzdGVyIGFjY2VzczoNCj4+IFRoZXNlIGhlbHBl cnMgYXJlIHN1aXRhYmxlIGZvciBNTUlPIGJ1ZmZlcnMsIHNoYXJlZCBtZW1vcnksIGFuZA0KPj4g cmVnaXN0ZXJzIHRoYXQNCj4+IHRvbGVyYXRlIDgtLzMyLWJpdCBhY2Nlc3Nlcy4gVGhleSBhcmUg bm90IGFwcHJvcHJpYXRlIGZvciByZWdpc3RlcnMgdGhhdA0KPj4gcmVxdWlyZSAxNi0gb3IgNjQt Yml0IGFjY2Vzc2VzLCBvciB3aGVyZSBzaWRlIGVmZmVjdHMgZGVwZW5kIG9uIHRoZSBleGFjdA0K Pj4gYWNjZXNzIHdpZHRoLiBJJ2xsIHVwZGF0ZSB0aGUgaGVhZGVyIHRvIGRvY3VtZW50IHRoaXMg bGltaXRhdGlvbjsNCj4+IGRyaXZlcnMgbmVlZGluZyBzdHJpY3QNCj4+IHJlZ2lzdGVyIHNlbWFu dGljcyBzaG91bGQgY29udGludWUgdG8gdXNlIHJlYWRsL3dyaXRlbA0KPj4gKG9yIHJlYWR3L3dy aXRldy9yZWFkcS93cml0ZXEpIGRpcmVjdGx5LCByYXRoZXIgdGhhbiBtZW1jcHlfKmlvKCkuDQo+ Pg0KPj4gU3VtbWFyeToNCj4+DQo+PiBJIGhhdmUgbWFkZSB0aGUgZm9sbG93aW5nIGNoYW5nZXMg dG8gdGhlIGhlbHBlciBmdW5jdGlvbnM6DQo+Pg0KPj4gLSBzd2l0Y2hlZCB0byBvcmRlcmVkIGFj Y2Vzc29ycyB0byBhZGRyZXNzIHRoZSBvcmRlcmluZyBhbmQgYmFycmllcg0KPj4gY29uY2VybnMu DQo+PiAtIHVwZGF0ZWQgdGhlIGRvY3VtZW50YXRpb24gdG8gbWF0Y2ggdGhlIGltcGxlbWVudGF0 aW9uIGFuZCBleHBsaWNpdGx5IHN0YXRlDQo+PiB0aGUgc3VwcG9ydGVkIGFjY2VzcyBzaXplcyBh bmQgZ3JhbnVsYXJpdHkuDQo+Pg0KPj4gSWYgdGhpcyBhcHByb2FjaCBzb3VuZHMgZ29vZCB0byB5 b3UsIEkgd2lsbCBwcm9jZWVkIHdpdGggdGhlIGZpeCBhbmQNCj4+IHN1Ym1pdCBhIG5ldyB2ZXJz aW9uLg0KPiBBdCB0aGUgZmlyc3QgZ2xhbmNlIGl0IGxvb2tzIG9rYXksIGJ1dCBwbGVhc2UgYWxs b3cgQXJtIGZvbGtzIHRvIGdpdmUgdGhlaXINCj4gb3Bpbmlvbi4gQW5kIG9mIGNvdXJzZSBteSBm aW5hbCB0YWtlIHdpbGwgYmUgYXZhaWxhYmxlIG9ubHkgb25jZSBJIHNlZSB0aGUNCj4gbmV4dCB2 ZXJzaW9uLg0KPg0KPiBKYW4NClN1cmUuIEkgd2lsbCBwb3N0IHRoZSBuZXcgdmVyc2lvbiBvbmNl IEkgc29ydCBvdXQgYWxsIGRvY3VtZW50YXRpb24gDQpxdWVzdGlvbi4NClRoYW5rIHlvdSBhZ2Fp biBmb3IgZGVlcCByZXZpZXchDQoNCk9sZWtzaWku From xen-devel-bounces@lists.xenproject.org Thu Jan 15 15:48:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 15:48:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205427.1519700 (Exim 4.92) (envelope-from ) id 1vgPZu-0001OI-Le; Thu, 15 Jan 2026 15:48:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205427.1519700; Thu, 15 Jan 2026 15:48:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgPZu-0001OB-Ig; Thu, 15 Jan 2026 15:48:06 +0000 Received: by outflank-mailman (input) for mailman id 1205427; Thu, 15 Jan 2026 15:48:05 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgPZt-0001O5-4W for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 15:48:05 +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 909b5cda-f229-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 16:47:59 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BN9PR03MB6042.namprd03.prod.outlook.com (2603:10b6:408:137::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Thu, 15 Jan 2026 15:47:56 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.005; Thu, 15 Jan 2026 15:47:56 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 909b5cda-f229-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AStzdjVhvaYJZpcF072LnMeq6tsUPtW/vpTVsvMr13lKpZpWFEEUVoQOM7c7ia3/yzOnWusaQFUeZGTbJc03ROFdnpP9acKkV3k6D3Ea6usKJSkfWbBhZ4/jpzcFscPNEByRyef8uQLJty4z8AeHDZbgy5G4KbyeaxZvZjwgtTFUkSsKaK4rykH1oeqBf26Hj8ZL3XKZwUCH4OMhASp9dRd4C+unwug2BjQzdeTNPejiddARaWgTyuRKY0rwbuY6L6ImHuCAFCG3YnKS0+iRLBxSvS/WaQxTOxbT0Rpy98Q/EoR0/LssuW8va+QNmSvDtvHVLSkoBNExxFjSPt9jRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3TOq1LgknB8r94vHCHUTJ8lcwAaUsfulbrztKnI2+Ys=; b=WSzC7um6q5M6l7ClsQKtzUK8mtT09IO0GWMamoI3R+6CPgrOBAi+9eUh9LpFrszhAjQSisNe3ZYFUoJNmmNUhYOlsfzUW3J5AFR+KkmHYTc8oe7QWacqONwGdFYyHNnS8W/1gdKHkd8KOMpaSLp/hZlpbAlH2eOn+9b0N/0307Q806VBDPv1JNctNajm/9JTI6Kf5F9ceF1HKQyiWRtqOYqCrmE1A/ZIh4Jnm3Ci3sPG8QsXjZCpEYi9id/i1vLTTf8sYCC4Qcipr2QfKcaQI+7azWmeN3cfYEq9hp5IH1qES/N7f/kA/z241eho6d4XcCaDxfcWakGiGLoQOEf9hg== 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=3TOq1LgknB8r94vHCHUTJ8lcwAaUsfulbrztKnI2+Ys=; b=axeLSSfpSf5vWl8uqvkQUdJMv/cgHIOL7G667Uwe/9lVSlADnFZeldzVq4qgE1Q9qVRkMC3cwD95NMDfiaFDzUV227M+Lv1ealL+jIt54qVBEGc77lJSkK0lCI5gmlvY6HsDogFgjNGtxmnQIGpOVnSNfcdLnLOmitKOonuP78g= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <69b511db-654d-46b3-aca3-3f37f30d3473@citrix.com> Date: Thu, 15 Jan 2026 15:47:52 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P . Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= Subject: Re: [PATCH] xen: Move NX handling to a dedicated place To: Julian Vetter , xen-devel@lists.xenproject.org References: <20260115151658.3725784-1-julian.vetter@vates.tech> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260115151658.3725784-1-julian.vetter@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0189.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a4::14) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BN9PR03MB6042:EE_ X-MS-Office365-Filtering-Correlation-Id: 0a605ab9-70c2-4f7e-bc31-08de544d7368 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?aTV2UzIzK2FNZmtuWlNnTkUvbC9PUFpOWVZ2bHZqL2Y5Vm8xU09ERnBBTFZV?= =?utf-8?B?UmhYM1A3bnNPM2M3bGdnQnk3UUdzQ0V5UE5RaWl1T3UxMHVHN0MrY3J2bnBn?= =?utf-8?B?M0E2UTd1WnZnd3pCKzVnb1lJeEN4MENqUXYrNHduRkhHcmRMUWZUZHl2bGZY?= =?utf-8?B?QU1uS2dmRHphTWFrbGhIaXBoZjhGa1N4UUMzUFVubHZUSUFWZEZXUHJBQUdQ?= =?utf-8?B?eFpVRWZTNWhncDRWc3BCZnJ0Skg5bUJiMXFiYmxDLzFld08wV3o4S3I3eHd0?= =?utf-8?B?bytFNXRYRjh3M0kzb2Yvd2xjZVFCdUY0Z2xEY3V4TjZGalZIazUxdlcreXdJ?= =?utf-8?B?V3FLUERSeVlZMG5ncG1ubUVESHVqMVJzSSttNWU4RmU1U0MxbWRNb3hvZzhN?= =?utf-8?B?a3U1ZHpqbDdSQzZXOUhaekc1YW04bk9QNGJCYW43RVNaN1NwOXBVTzcyQkJU?= =?utf-8?B?LzA0T1Z2NjNIdHZPZzFXbXpsVnRYcjROb3ViZW9weXpIR0NuZkpRZHdjdnJ4?= =?utf-8?B?TWRnRzBlbnkySlFqWng3eUpkQlJHRU4wVmlMZ3hHUUVuS2hVSWU0R1A3ZlJ5?= =?utf-8?B?UXdaNjJsVnNYeWtzT0hqUUk4OFVPK1VMK2RQb3dRMmRpOGlldjZQSmxPNFBX?= =?utf-8?B?eUZ1TGZCQ1phdVBvNThESnBaa2h2SjlNT25IQ0Q5UHR4ZXJOVDFIakZlWC96?= =?utf-8?B?RXArTVcrSHoybWNjc0l5cUtFVEJCTy81Ykp6aG9uOXlQdzJwNkpVS0d4RGVo?= =?utf-8?B?Y085YU14aFE4Z2x2TnhVdVl1QTJGN281VkUxMUdoRDljNU9CUkg1WnpSRUVx?= =?utf-8?B?RHRCem5PZncwa2dER3A0aUtuREpmbHZoWWtvZGJRclE3ZWgxUkYyRUxUR2M5?= =?utf-8?B?WW4xOWRWOVhjT245dlcxL1VBWUx4RVhVM04zQ0hza0I4RHFlZnBUNEwwSWpF?= =?utf-8?B?bHlvdTlSL0MxVFlFNnVCZlU2ZjdRWWZuc0Z3cC9TVklsVjlDSXMyMnVOOThV?= =?utf-8?B?bmw5UElZN3cxMnFET0wrQUdKM2E3UjY3MndRRDh1U3RWY3VTYU5vdkNMVW1Q?= =?utf-8?B?YUhsN2xBVzBUV3l0anl6QnBaVUdFa2Q1a3Myd2JNNHU2RW1FSWhuTmExMEN6?= =?utf-8?B?WEhpaktoeFhyc3puUzJySjVCVlpjazMvQU9XTmtCWUE5OU94ZFIvbnY0azg0?= =?utf-8?B?RkdqYzNWZGtqNFlzREdwbUZyZ0lIUnJoYllIN0FkNWlaMzZ4bmdRcXJlWTZ5?= =?utf-8?B?RStUS3FZSWhPMXBkNWN4STVzQWc2bW9EM2YrbkpEQ0w3NXhxblEwdkc0UmdC?= =?utf-8?B?NmJHUHFpbnVaZDUzVzZLbWZ0Rm1lLzZIaVlEREdGWmNOS1NxRy81SHFqam9w?= =?utf-8?B?UWdsckw5dnhiTVhYSGpOZ2VHVFcvdndZWEROWDZ6cUhnVEdOSFZOeERJQUJW?= =?utf-8?B?UXFJTWoybTBodnpRNnpBenZENmkzbTJPazc3emJ6ajVnQWp4Tkk5d3FHTm8v?= =?utf-8?B?MTdEUmFUMVk5SEgzZGpxVzd2bVhic0xXdzVXUktPSlFBRjB4bnVRWGYxK1dn?= =?utf-8?B?VU5FY05DRUJ4MnBLM0xaZlh3MEtuR0t3dWFLT09leGMzK3dCVTlyQ2VhRU45?= =?utf-8?B?MUNhS2lWNUszTndnMVVZVkJHdVVVOE80Tm9IbTZFdDlqVU9seGdXNEQ1aUFX?= =?utf-8?B?ekk5V25ZclZtNFQ4eTZVNFI3SGRLQnFMcFlhVXllaWIrcVFON3BzcHRqcVp1?= =?utf-8?B?VUh6ZDh1SnhTbVlKS25XL0x1bFFkNERLaWEzMzhRYVdCbnhPR2JISTVCM3R5?= =?utf-8?B?aXUvSFQvRjJ1dTBUTnRLV2VhWmRFNnNVOTZyYTV2RXVlS1V6N2ZXMzFLc0x1?= =?utf-8?B?VHZXMG5Ud1FzZ21jQUpvZXAvV1cwSUJYM25ZSmN4aG1UOTg0bHJnbGNsQnZU?= =?utf-8?B?R3h4UFdLZzEydjNnMTNBQmtnQ0V5dkdtYUludzdlTTRuNWZkT016UEpsNml0?= =?utf-8?B?aC9oa2ppdlJpRms1NW01Q0RJelJLaDZqTzBUSUpGTGExVDJvVFR4QlN4UDN1?= =?utf-8?B?OGZqUDIxWk5uM0IzTU4zbTJGQTJRcy9kazR4WTQ4SmJ5NHZqT1cwYnpSN1V2?= =?utf-8?Q?Vzcg=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?T1plck9wZGlwYkNUWld5c3ljd3d5bFc2disrS1RiYjF1Q1VDZDNEdTlnYzVX?= =?utf-8?B?ZTBOaFdmeHhCVTQxeFRUZFVOeTV4QVV4Sm1pdXg4UjBjd0psOGxkREIxN0M2?= =?utf-8?B?T3hpMG1CemlpSHg0MTc5WElPNm12aDlHdDE0UEp2bkJGZHZJN2V0OVZ2NUJQ?= =?utf-8?B?VEwwdjg3NFRqU3diekpCYXhJaEpiNUNzbDRwalkrais4V2pXWFZsNmlNM05w?= =?utf-8?B?dnlZSmZScTBYQVFPMXBRWmtzOThYVXQ2Z0txMWtDRnV0NEpzSzIwVVoyZURZ?= =?utf-8?B?ZTZwb1NWNGR3d01Vb2t4eVgzVkhLSGRzbEM5UVgzZXJ3ZE9FRFV2U2E2MTIz?= =?utf-8?B?WlV0Rm80YjViSlo3TmJkTTNuY1RzQTJyMVRUanlQQXhyTVIrTXFKOXBmakF1?= =?utf-8?B?WDM3dmxXOFRWR0MyQkVEL3pYdWc5KzBRaVFncFNRVmdwVjA4MFB1bUxkcytQ?= =?utf-8?B?dEtHdTNwZE55bUY0Sm1zckNLbzZMV1FwRTBxK29wNEdQNlhGbndrQ0ZjQUZa?= =?utf-8?B?bEozeC84a1VaSXdyODdVMnMrQWF5NHRLamFEQW5ZTEZKWHEvcUhEQytVNFJU?= =?utf-8?B?c2NDVTlYc0E3S3lBN3JsUW9zYjA0bDRNNU1keGxLMDNBNTRKTTZNRmxxOXg2?= =?utf-8?B?cEtWbCtvRU9PUXJJb2czbzU3N0tLa1paM1pvRjlXeWkrTk1SbzM3NkZ0TmZz?= =?utf-8?B?K3ZVK21wMjFFSi9rMm1IZnliaWFuV1VBVVdGOE9Fb0hGZDh2MkFRMjZ0MThV?= =?utf-8?B?V3ladmc2bkJLczJueDNQREJCaCszVzlqYlh0NlpDTVRVaEVvbTI4b0N0MVhP?= =?utf-8?B?ZW8wSnB1Q1h4QkJ1THh0bnJGUFcwSTEzVUN3anNTOWVYRW5PbEtOajFTbkJH?= =?utf-8?B?MHg5anJTT1U4czhLY093Q2UrVllkOW5LSWM5S3RMVVJVNWFDb1FkQjhqaXlw?= =?utf-8?B?VWp0TFRhaTRIRkRMWEdwb0hhZ0xCRnR2SHFsbUcrR1dwVFBlYXhTZUFEd2Jq?= =?utf-8?B?bldQeEVXbzBkR3V2MDhMcmRmMjhvUTdjbDFFOWQrNEJteW5wUk1RZm5pbXVu?= =?utf-8?B?VEg0NnB3WCtqYU9KV0ZxVFNiQkNHMlpzZDBoa0lrUUpKUDZ5UC8zUGVYZmll?= =?utf-8?B?OG9IcGNmN0pJRXc0T09vVFhVWWY0b0I5Q3hEdXFGZXo3Q3o1UllGKzVMREFn?= =?utf-8?B?VFRKK3VZeURObEExVy9qQ3R6eWtWM0l5VHlkZEhoYU8xSTZYRTAvSkN1dG9t?= =?utf-8?B?Ni9LajJjUkVGREhkYjZDVVB2cW5ST21DbHJ1bndZdmNBL3dVM2greEtIbm41?= =?utf-8?B?aEl2L3FyeStTT3pMZVdPTW55TkZjRzVjbHlFaWFXT1VmSDQzazl2YWZkc1VV?= =?utf-8?B?K01Tb1JCeHZJV1JGajY5aGNyL1IxWTJzNHJJQkZXV0trUXVOR1o2THNXY2c1?= =?utf-8?B?K3dFR1NCSmlpR0VEVEU2ajNFY00rbW0xVy9oTUd0RHFkT0FzZVlJWVduNnN5?= =?utf-8?B?OC9hSldnQkk5aG9sZlRPWWsyM3FLd0VTZm1oVmgwSUZPM0xPcVpwV1p4QkRW?= =?utf-8?B?VG9LK05BRUdDUmpOZ0pQVVo3VXcyQ0RyVklkSGRUS3h5NVJENFB4TDNPQ2Jw?= =?utf-8?B?K2RXclVISVZqWndsZ2FNOEFHSVRPRHFQS2dIVUhTcm5EZy9FZXRDRDBzRktw?= =?utf-8?B?R3g2TmoyWTNBRzlXeUFLSVFrMGVDR2phZnRTaG1qeEhHM2tULzR3MGphUWxT?= =?utf-8?B?S3Z3dUcyaU1MNWFCWlBDZXNraGEwWG5KZTFwcjM0bXIzeURLQ3JCbG9YM2I2?= =?utf-8?B?MC9uaDY3UkR2Nm4wZElSS09pdDVZSXVMLzZaYi82eXh6NiswZWlkZG0vQk1M?= =?utf-8?B?L2RkbVBSUVFZbjhlNmhQTlJLRStaSXJ2czYvMHQyZkp6WVZ5Q1hrRGJaOEIv?= =?utf-8?B?UkF2WFgvenVZOFE5SnU5V2ZBWHBiWUxjK1BkNG42RHlUT1dvNWFYM2tvRFJl?= =?utf-8?B?VlEzeU1WSGdGaGpDNzFQWHhHeEVraFUxckhRTllEUFFWTllBS2tXUlpCNWdN?= =?utf-8?B?aXphRksrTzRsbENiWVFDdHRUamErcG9GWmtjM0NJdWFpOW9hSERKTm92aG5h?= =?utf-8?B?KzA3bGpOVGhuQlo5M1g2Mm9JNmRNbkpIVG9BLzFMVUhBNjRqczk3MWpPTlFL?= =?utf-8?B?Sm8yQ1lXRlFqMlhBUkhMZFB1NW5tMDR1ZmlBWGdNM0trTjU2WUFxRVp1Z0hw?= =?utf-8?B?bm1qZ3EzZHhpMG1IQ29DVnprd3JNUmVaSkFnb2UvRXZFT2w3NThsY242dEUv?= =?utf-8?B?WlBHem1SSTZMK21oY2ZOOXpLVlhCcllTY0xFNFJvWGdCOUtwQVN6QT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0a605ab9-70c2-4f7e-bc31-08de544d7368 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 15:47:56.0404 (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: 47fsRJ6q2AY7hPpSbtKzuM4ofN/5EYso/JpcUV0P15EGhPggT/LBftO8lrbZ7pacGeve//H+nIfgvQxXkYNZA33wa9EJSF7e6UtETWzuChQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR03MB6042 On 15/01/2026 3:17 pm, Julian Vetter wrote: > Currently the CONFIG_REQUIRE_NX prevents booting XEN, if NX is disabled > in the BIOS. AMD doesn't have a software-accessible MSR to re-enable it, > so there is nothing we can do. The system is going to die anyway. But on > Intel NX might just be hidden via IA32_MISC_ENABLE.XD_DISABLE. But the > function to re-enable it is called after the check + panic in > efi_arch_cpu. So, this patch removes the early check and moves the > entire NX handling into a dedicated place. > > Signed-off-by: Julian Vetter Sorry I didn't get around to doing the prep work I promised. This is going along the right lines, but there are a few complexities still. Also you'll want to split the patch into a series.  More on that when we've sorted out a few other details. > diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S > index a92e399fbe..8e8d50cbdf 100644 > --- a/xen/arch/x86/boot/trampoline.S > +++ b/xen/arch/x86/boot/trampoline.S > @@ -144,10 +144,9 @@ gdt_48: > GLOBAL(trampoline_misc_enable_off) > .quad 0 > > -/* EFER OR-mask for boot paths. SCE conditional on PV support, NX added when available. */ > +/* EFER OR-mask for boot paths. SCE conditional on PV support. */ The comment wants to stay as-was.  NX does get added when available. > GLOBAL(trampoline_efer) > - .long EFER_LME | (EFER_SCE * IS_ENABLED(CONFIG_PV)) | \ > - (EFER_NXE * IS_ENABLED(CONFIG_REQUIRE_NX)) > + .long EFER_LME | (EFER_SCE * IS_ENABLED(CONFIG_PV)) > > GLOBAL(trampoline_xen_phys_start) > .long 0 > diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/setup.h > index b01e83a8ed..16f53725ca 100644 > --- a/xen/arch/x86/include/asm/setup.h > +++ b/xen/arch/x86/include/asm/setup.h > @@ -70,4 +70,6 @@ extern bool opt_dom0_msr_relaxed; > > #define max_init_domid (0) > > +void nx_init(void); > + > #endif > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c > index 27c63d1d97..608720b717 100644 > --- a/xen/arch/x86/setup.c > +++ b/xen/arch/x86/setup.c > @@ -1119,6 +1119,50 @@ static struct domain *__init create_dom0(struct boot_info *bi) > return d; > } > > +void __init nx_init(void) This should be static if it's only used in a single file.  However, see later for doing it a bit differently. > +{ > + uint64_t misc_enable; > + uint32_t eax, ebx, ecx, edx; > + > + if ( !boot_cpu_has(X86_FEATURE_NX) ) > + { > + /* Intel: try to unhide NX by clearing XD_DISABLE */ > + cpuid(0, &eax, &ebx, &ecx, &edx); > + if ( ebx == X86_VENDOR_INTEL_EBX && > + ecx == X86_VENDOR_INTEL_ECX && > + edx == X86_VENDOR_INTEL_EDX ) > + { > + rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable); > + if ( misc_enable & MSR_IA32_MISC_ENABLE_XD_DISABLE ) > + { > + misc_enable &= ~MSR_IA32_MISC_ENABLE_XD_DISABLE; > + wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable); > + > + /* Re-read CPUID after having cleared XD_DISABLE */ > + boot_cpu_data.x86_capability[FEATURESET_e1d] = cpuid_edx(0x80000001U); > + > + /* Adjust misc_enable_off for secondary startup and wakeup code */ > + bootsym(trampoline_misc_enable_off) |= MSR_IA32_MISC_ENABLE_XD_DISABLE; > + printk(KERN_INFO "re-enabled NX (Execute Disable) protection\n"); > + } > + } > + /* AMD: nothing we can do - NX must be enabled in BIOS */ The BIOS is only hiding the CPUID bit.  It's not blocking the use of NX. You want to do a wrmsr_safe() trying to set EFER.NXE, and if it succeeds, set the NX bit in MSR_K8_EXT_FEATURE_MASK to "unhide" it in regular CPUID.  This is a little more tricky to arrange because it needs doing on each CPU, not just the BSP. > + } > + > + /* Enable EFER.NXE only if NX is available */ > + if ( boot_cpu_has(X86_FEATURE_NX) ) > + { > + if ( !(read_efer() & EFER_NXE) ) > + write_efer(read_efer() | EFER_NXE); > + > + /* Adjust trampoline_efer for secondary startup and wakeup code */ > + bootsym(trampoline_efer) |= EFER_NXE; > + } > + > + if ( IS_ENABLED(CONFIG_REQUIRE_NX) && !boot_cpu_has(X86_FEATURE_NX) ) > + panic("This build of Xen requires NX support\n"); > +} > + > /* How much of the directmap is prebuilt at compile time. */ > #define PREBUILT_MAP_LIMIT (1 << L2_PAGETABLE_SHIFT) > > @@ -1159,6 +1203,8 @@ void asmlinkage __init noreturn __start_xen(void) > rdmsrl(MSR_EFER, this_cpu(efer)); > asm volatile ( "mov %%cr4,%0" : "=r" (info->cr4) ); > > + nx_init(); > + > /* Enable NMIs. Our loader (e.g. Tboot) may have left them disabled. */ > enable_nmis(); > This is too early, as can be seen by the need to make a cpuid() call rather than using boot_cpu_data. The cleanup I wanted to do was to create/rework early_cpu_init() to get things in a better order, so the panic() could go at the end here.  The current split we've got of early/regular CPU init was inherited from Linux and can be collapsed substantially. The intel "unlocking" wants to move back into early_init_intel(), along with intel_unlock_cpuid_leaves().  (This is where it used to live before REQUIRE_NX was added). The AMD side probe wants to live in early_amd_init()  (not that there is one right now), but the re-enabling of the NX bit in CPUID needs to also be in amd_init() so it gets applied to APs too. Does this make sense? ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Jan 15 16:03:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 16:03:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205471.1519714 (Exim 4.92) (envelope-from ) id 1vgPoV-0004tn-2k; Thu, 15 Jan 2026 16:03:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205471.1519714; Thu, 15 Jan 2026 16:03: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 1vgPoU-0004tg-VA; Thu, 15 Jan 2026 16:03:10 +0000 Received: by outflank-mailman (input) for mailman id 1205471; Thu, 15 Jan 2026 16: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 1vgPoT-0004tX-NE for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 16:03:09 +0000 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [2a00:1450:4864:20::331]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id aa243f87-f22b-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 17:03:00 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-47ee937ecf2so8813515e9.0 for ; Thu, 15 Jan 2026 08:03:00 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee11c64b6sm47155645e9.7.2026.01.15.08.02.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 08:02:59 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: aa243f87-f22b-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768492980; x=1769097780; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=aNMDB5rheHSEk4abqk8B8eFHAGbHqb4XKzIlVPSXS6Q=; b=S8lEEiVF9vH5JIBWsRlaTXgnfnTwmnUNkgKZJ0FUqn6DP4iVh+tjGPjssfr7FLyV8h WsyV5iVf1hFcxYBH7YYBPye1O7AOd4XjsJ0VuOWhivCHC9lG2iNvjRp+giuhu6qNt8nZ 2Bbb1Ki8MEbv126lH8DGYzjlvMdThpPQ5gYX7vzw1l/Q6T0/83SdScAsYgZE9t8HkeLW g/U4qlHzr3BvNckDDL5WLr1GDDn+xe5DxU6pqq4591ZKK5krM6HgFZIPgSZyEd9PMfdp 5y5eFP4XE9q27oCKjbTFH/8qVg7x2+wF1bApUR/lnQbSclUGyUEG6A1+P6+RoxyIzZkb q5LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768492980; x=1769097780; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=aNMDB5rheHSEk4abqk8B8eFHAGbHqb4XKzIlVPSXS6Q=; b=m0oyvTC8mg8t9kiZX8lFpN5QTJ33QN/F2chcG9ZoJxA1R1ia69HQSi/OeIN3lUlryK EpzVjzUQe4kC2mbhpf7IGPmgTQzHxYaSCJR8c7mIklkB4QA0wyBvZSPXimBYGfk34EQs QreI8M/mnixwmC0VhW6PRsNdydF1cGxYPgo5Rx9z+CnZHbAhXlixofng74RaZFHe+uVr 9YKV8nZ+nJ2/3jgx4uXsP5yD5VHbr9LtZogp2jim+TcKJ3Q/lx41rEXTrVSPUnIF4FP4 VTuscuci8PXkDfO3l2bQIybeGn8d5bciMEhDwvRydacG6IB2nVrZv+qKqftHZz+14LBh v3Rg== X-Forwarded-Encrypted: i=1; AJvYcCWYijDMQZwqqi7cOEjR1vuMaUbsSEe6h5/wqCQavDFLXJ7mSjDbYJ5GSeoskUzEMKk/Xik0KrCfbMs=@lists.xenproject.org X-Gm-Message-State: AOJu0YwtmQnUeckoykUXQt2OPAxli2PIonAk641asFufO6Rkr6Mm4Cr4 SPqJh2R8OllIf0qEUjar9yi+XUifXZ4wfTVEJCwP7Soq9HbqlLt4eyzhsuFyuf9uoA== X-Gm-Gg: AY/fxX4NZoFh/htqbQZ84HPTQwEIRkZ/ob4Zke4STIW6fj0xGrNfMADJTEWlyBILv8d pnfelPentKdzP3vTFuQaBKxHr+B803N/8wvor2l844CfoRnjU2ZZoWPmPeytOIijkv+uxVONbZs 4cANbvJq24Y1Fgi8kiHR21dsWZf+4Sx8LQpj7BN8UpTJk2XeI3hIjVVYGtUA63d+QC6ziIGdQ/T ViajOSOr5guc8XkQdC43UJ1dUYHrtK4ByPmwwj9LcTEIKGSUrxhUniigG7nkoSk++glCL9RQYql gpTEFWSM6eWWhxh6/vcdZX1OQnParjJEdaf/+lYeiZZRIYvdpE+CS/4sPQwbqllBZlcZfAKsztn w83JvhQX1nYsTHgn0KkO57NMhZU8QFhd90BOCGLnf5ZbWzKlrJEAE5/28YSYniarblYsxwC8sFn eQDjB+SaVxsJK2OnA/G3GSjeU+OhmXuP59GHY3+sb7Rk5qu2AeeEagNAUNcKjqtygkqoccqdNrb 90= X-Received: by 2002:a05:600c:3e08:b0:480:1c1c:47d6 with SMTP id 5b1f17b1804b1-4801e53c069mr122115e9.6.1768492979583; Thu, 15 Jan 2026 08:02:59 -0800 (PST) Message-ID: Date: Thu, 15 Jan 2026 17:02:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/riscv: dump CSRs on unexpected traps To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260115125601.70834-1-oleksii.kurochko@gmail.com> <8377bdc2-d92d-4c3f-893b-19c842cad3a7@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 15.01.2026 16:41, Oleksii Kurochko wrote: > On 1/15/26 2:12 PM, Jan Beulich wrote: >>> static void do_unexpected_trap(const struct cpu_user_regs *regs) >>> { >>> unsigned long cause = csr_read(CSR_SCAUSE); >>> >>> printk("Unhandled exception: %s\n", decode_cause(cause)); >>> >>> + dump_csrs(cause); >>> + >>> die(); >>> } >> Apart from CSRs, how about also dumping GPRs? > > Just to double-check, do you mean GPRs which are stired in > regs argument of do_unexpected_trap? Sure, those are the ones pertaining to the trap. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 16:04:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 16:04:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205484.1519723 (Exim 4.92) (envelope-from ) id 1vgPpt-0005QJ-CN; Thu, 15 Jan 2026 16:04:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205484.1519723; Thu, 15 Jan 2026 16:04:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgPpt-0005QC-9d; Thu, 15 Jan 2026 16:04:37 +0000 Received: by outflank-mailman (input) for mailman id 1205484; Thu, 15 Jan 2026 16:04: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 1vgPpr-0005OL-K8 for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 16:04:35 +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 dfe5377e-f22b-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 17:04:31 +0100 (CET) Received: from BN9PR03CA0220.namprd03.prod.outlook.com (2603:10b6:408:f8::15) by SA1PR12MB9548.namprd12.prod.outlook.com (2603:10b6:806:458::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Thu, 15 Jan 2026 16:04:26 +0000 Received: from BN2PEPF000044A4.namprd02.prod.outlook.com (2603:10b6:408:f8:cafe::c8) by BN9PR03CA0220.outlook.office365.com (2603:10b6:408:f8::15) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.6 via Frontend Transport; Thu, 15 Jan 2026 16:04:23 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN2PEPF000044A4.mail.protection.outlook.com (10.167.243.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Thu, 15 Jan 2026 16:04:24 +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; Thu, 15 Jan 2026 10:04:24 -0600 Received: from satlexmb08.amd.com (10.181.42.217) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 15 Jan 2026 10:04:23 -0600 Received: from [172.19.137.210] (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, 15 Jan 2026 10:04:22 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dfe5377e-f22b-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gIHOGM8ffH2h/+VWKJpC0kKVtbK6PPVUYntm8xZRRzSqNLVHzbIUIYG18TYXIWJecgFVtJA4vrOcFarG6NBxTS2XSnyRVkxjhVLoLNiXmWQP+6mSAetQYMyOhikqDCtShS+2fmPKAXx18ssRAQ4B94ZiRbhXMF9xkf5MpD3OoBosPfalvwQp3XDsNiROeZG+WRwTgnZVcNZMdkBKclP0SVTUQ9cXT+8EFwzcNaTg/B6ObWBJzDwI64hQyFnkObx9e9sK22y70pZfgpfcRShevm5KbhDbgbrRh8rxZ9U/3NBAlDNLkh5IptPw1R6kdqd0JcE4an0XuXkywXUnA1/tQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=T46NP2Enpxn6nDBpKzEtQfdn+lkTPsqFLGevnirD5fI=; b=EY3vNhIEE8HjxekLSpnjhHOMSeNiuyIIXpQ/l1dRxJjPRF6VK5ZsbYE6rKbWI566D5YuYyaxrkeUIjYN1py3gPhAPbD39l8X8OEd/wnb8bqQf6klIL2ygFfXwLFYg5n1F6BRj2hp6Dbv5xKfMBzTWXAWVVlweLZNWiDeREY1u1InEy0NDTlh1PzhF91hDWdgdOPB9GB3Cx3L1dhHwjScctOJ96xQpxEBbDsE0Brp9KwfC1vS0LdadlIse9wgSx2cTj5TGUBMoWA6rYRpOUZ4/03mn0PaKx4rkDtAidHcRhLQDWvII1CHsECVF/t5bcZ/plws0bEBVAkFrudZECNmBA== 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=T46NP2Enpxn6nDBpKzEtQfdn+lkTPsqFLGevnirD5fI=; b=jRv1RwT/I/kVTOxWqKWkLFf0lq3V3a+42/2pZbC4E+FsHnB1ebSQFnnsQzPWVyeSMuRzKmUMQqVfnNMhKVp+Lpqb2AD938kZpObJibx1RNK+pK5vAT4dVbp/f+LPx7JvyGNQKqhNM9/o+rVMg8tfhvBQ7bA6XqlD8WCvtldHCNw= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <74199039-494c-4120-93f9-bcdbab52818a@amd.com> Date: Thu, 15 Jan 2026 11:04:21 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/6] PCI: determine whether a device has extended config space To: Jan Beulich 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: <05bc9acd-3054-4c5a-be87-cfd8d7bfa0f8@suse.com> <52eb1293-b5d4-4f7a-b53b-285e4dd274a5@suse.com> <5d4aec52-03af-4de6-9625-b972ffb5e5b7@suse.com> Content-Language: en-US From: Stewart Hildebrand In-Reply-To: <5d4aec52-03af-4de6-9625-b972ffb5e5b7@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB04.amd.com: stewart.hildebrand@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN2PEPF000044A4:EE_|SA1PR12MB9548:EE_ X-MS-Office365-Filtering-Correlation-Id: 6459bae2-d9ec-4e88-0c03-08de544fc0ef 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?Tkh6ODlUc0JxV3hyN1QwUEtkYXNFMzg3S3FXczEwUVRER0hUUlRYTG9LSUNs?= =?utf-8?B?WGh5MnZCajRtNUtWR090UldIcGgxaHQ4WmFGdktIdFpDaUdOWmZTT2wxczR4?= =?utf-8?B?NjBGUkdxUjlNenVESUhRa1hqVE9oaVZlYVJhNTV4NEx0Qi9pWWtwL1hrMXBX?= =?utf-8?B?ZVUva3g0MkU1cXZPb2dySzJacmg2dzNreGRLTndrNERSSitjaE1JS3ZVYjVK?= =?utf-8?B?TVNiTGFZQi9jazdnZHNibzM0WWt1RGJ1TGl5REZ1N2JweHZYbnp4YjBLdjZW?= =?utf-8?B?MTltSkkzcHZhZFUyNDJTSFY0VlFGNEpuOThFb1o1Ukpmb05EMkMzQkRoVVU4?= =?utf-8?B?Uy9GRUpRcUVaek1tY1lmbEVrKzVhaExEZnhVRlJJZTRQWEZMYnVmZmNJTksr?= =?utf-8?B?TTl3ZkNNdG5lWnVQZUNDYXFMZjRzTlh0RGZQSmc1eU9IdnpaSnNkQVhLMFF1?= =?utf-8?B?OW1kNXVIMmlWVHJrUktIdml6NnQ5Y3cwcVJVSk5EZ3U4MlNaNUJ6VTJZYXRS?= =?utf-8?B?U3lXMk9yOVZSdG5CeldTNUhHVjJKR1lxQmlwdElGSE9iMGJRMVJIME0rNzdN?= =?utf-8?B?aXR2azdSWHJxNWtVd1B1S3Z6NkREUjJqMWZLSnJVTFdIN0VxajNHMHFJMDM5?= =?utf-8?B?ZWJhZXhHdncwRHBqWXRlSXNES1RTbzdWSXptME5WdE82U25tRXVSMy9sSFhQ?= =?utf-8?B?WTl2c3ZXeWtZQWpPcnExL2NJQVY2VGs0SStUVk5YSGhrRU5teC81Y0lTNVd1?= =?utf-8?B?ZkR2dnZUVVZvZjFmL1drZmNqanJpR0s2c2E2L29ERVpzSEpTY0JvSXNORnRD?= =?utf-8?B?Z0NLRURtVXFsSU5BN3hwTzMyRW05ZEFhWVJKcGpHcTBoUWtROVBscnJhWFVV?= =?utf-8?B?NkJrTXdPckkrN2t6cXplZ0hPVXVLTWhtdHdsS0dNaUFvSS9RQy9TS2paUThL?= =?utf-8?B?cG1JWUZUOTQvMDA2Y241NWxxZWpqR0NBV2ZZQVJXMmEwNWhzMGRTWjBLRXdr?= =?utf-8?B?ZHJBR0pHS3RRTjNRaUhwV1RqNVRXcmhkcWlhNTZEL1NuNkdDL3ZtY3Q3emQ1?= =?utf-8?B?Nmh3ejNJNVV3NVlrN1JiS0VGbjllQkI2NXdMTFBsVEp6NGVlUGRNSkl3MHU5?= =?utf-8?B?TUl2R2JlaC9hc0FaY3FFd1RYYWp0WEdDdG1VOXRwVlZZdW1NMVQ4aFQvbGxq?= =?utf-8?B?MEdtUkxsUHJaZWkxNXgyYXJmY1lqRGpRQm15Q0M4TFVHT01vOFU5aW9kNkFL?= =?utf-8?B?NFRpSjNVS3dpYnIrN3Z4WERnSnQ3eWVUSDhQc2Z2VDRwVTJHRy9yc3FPNDFF?= =?utf-8?B?bTlIaFh0djhHU2kwZ0JNMHFWTmdWM1YzY1k4dVBnVThpeWlKbzFsUklpZ3RK?= =?utf-8?B?dVVKTDZJSWFMMks5QWhNSlVLdEc1OTVlU1l5M1hNWmZvVzM5SXJ5QzJ2Yi9Q?= =?utf-8?B?VFNFZ2pkNnlWY3k0dWZqUlhFZHBsV0JrMEg3NHhoNzZBWDdyTkJkN2loQ0ZI?= =?utf-8?B?ZFRzRGdEY3g5TzZuQ0lrNEdSNlFIVHBlalZpWWxBNDI1MnE5UHVLVzBTUjYx?= =?utf-8?B?T2Y1Szh2M0lQaGliOWJRVTB3RFpXdEpuN3I1OVZFMWF1L2VIQ2g3azFKTmxB?= =?utf-8?B?RXMwak1XelFoRnROZlV0UHZQMjN0c1hFUG1ST3E3Qmd2TGxzU3RzMldvK2k0?= =?utf-8?B?SEEyVXVIeEpwcDJkR2p5cUl4N1AyaEJmbmFucGpSY0trckl1ZlI2NEZ1aDlp?= =?utf-8?B?RGtkNU9HdXYzcXRSdUUxNzFpUzM2S0JncWhyaHpGcHlXMFZjZlN3eHVweDJx?= =?utf-8?B?Ty9ua3l0RDFSREtCeDVGQStMR1JxYmx3S0NvNTdkZUx5RHdHUzJVUTlhanR2?= =?utf-8?B?NHFhL1pac2dxVmg3Z0xuWFlwVElqT2lLNWx5emxrbk5Qd2NyT2dZYnRXeFV6?= =?utf-8?B?MFZJOEVvRE9EZDQ5MGFwSU5FRUtkMmlaaVBOVTBMZExJem9hbU9VYUwycGJC?= =?utf-8?B?QW1wcDBVRTJ6R0cyNFI2SERsS3h5aEdwSkhmcEhNeWROMnBQMURJTVpmMDQr?= =?utf-8?B?Y0RkT2FuVkVSLzBmQ3ZYTmJlb2Nra3pTY2wvQjFiMGl0cVVpVnJwaWpLZmM3?= =?utf-8?B?VnFBSElMVW9oR2ZRY2tKaFFvZ0l5dEhKTjNoWWlBTndZVGpiVVk0MWhlV0lW?= =?utf-8?B?WDhsRDFmTVE3TGdzbWs1bTNWSFdLeUo3YVd0b0FuN3hob2pwK01hS0Y4QWFW?= =?utf-8?B?MkF0ZEFJZWp1SHRnL0x6K2MrZ0R3PT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(376014)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 16:04:24.8794 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6459bae2-d9ec-4e88-0c03-08de544fc0ef X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN2PEPF000044A4.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB9548 On 1/15/26 05:43, Jan Beulich wrote: > On 13.01.2026 11:46, Jan Beulich wrote: >> On 12.01.2026 22:07, Stewart Hildebrand wrote: >>> On 1/6/26 08:47, Jan Beulich wrote: >>>> @@ -420,6 +467,19 @@ static struct pci_dev *alloc_pdev(struct >>>> break; >>>> } >>>> >>>> + if ( pdev->ext_cfg && >>>> + /* >>>> + * Regular PCI devices have 256 bytes, but PCI-X 2 and PCI Express >>>> + * devices have 4096 bytes. Even if the device is capable, that >>>> + * doesn't mean we can access it. Maybe we don't have a way to >>>> + * generate extended config space accesses, or the device is behind a >>>> + * reverse Express bridge. So we try reading the dword at >>>> + * PCI_CFG_SPACE_SIZE which must either be 0 or a valid extended >>>> + * capability header. >>>> + */ >>>> + pci_conf_read32(pdev->sbdf, PCI_CFG_SPACE_SIZE) == 0xffffffffU ) >>>> + pdev->ext_cfg = false; >>> >>> I'm using a machine where >>> xen/arch/x86/x86_64/mmconfig-shared.c:is_mmconf_reserved() will initially return >>> false during Xen boot: >>> >>> (XEN) PCI: MCFG configuration 0: base f0000000 segment 0000 buses 00 - 3f >>> (XEN) PCI: Not using MCFG for segment 0000 bus 00-3f >>> >>> Then, during dom0 boot, dom0 will call PHYSDEVOP_pci_mmcfg_reserved, after which >>> MCFG becomes enabled in Xen: >>> >>> (XEN) PCI: Using MCFG for segment 0000 bus 00-3f >>> >>> On such machines where mmcfg/ECAM is initially disabled, this will effectively >>> set ->ext_cfg to false for all devices discovered at Xen boot. >>> >>> I'm not really sure if I have any good suggestions, but perhaps we could add a >>> macro or small function that returns something like >>> ( pdev->ext_cfg && pci_conf_read32(pdev->sbdf, PCI_CFG_SPACE_SIZE) != 0xffffffffU ) >>> to allow this checking to happen dynamically (but this still wouldn't handle the >>> aliasing quirk). Maybe re-run the ext_cfg detection logic at the end of >>> PHYSDEVOP_pci_mmcfg_reserved? >>> >>> Regardless, I'd be happy to provide my R-b without this addressed, but I am >>> curious if others think this as an issue? >> >> Hmm, no, I forgot to consider that case (which in principle I'm well aware of). >> Will need to fix in v2. > > My reply yesterday was actually not quite sufficient. On a system like yours, > isn't it the case that PVH Dom0 then also doesn't work quite right (yet), due > to parts of vPCI depending on extended config space accesses now? All of what > we presently do during boot, and which requires extended config space access, > would need re-doing once extended config space access becomes available (or > goes away) for a (sub)set of devices. Right, e.g. rebar will fail to initialize. One possible approach might be to do some variation of this at the end of PHYSDEVOP_pci_mmcfg_reserved (untested): for_each_pdev ( hardware_domain, pdev ) vpci_reset_device(pdev); This would be better than nothing IMO, however, as you point out, it may only be needed for a subset of devices. From xen-devel-bounces@lists.xenproject.org Thu Jan 15 16:11:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 16:11:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205500.1519733 (Exim 4.92) (envelope-from ) id 1vgPwY-0007FL-4k; Thu, 15 Jan 2026 16:11:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205500.1519733; Thu, 15 Jan 2026 16:11:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgPwY-0007FE-1x; Thu, 15 Jan 2026 16:11:30 +0000 Received: by outflank-mailman (input) for mailman id 1205500; Thu, 15 Jan 2026 16:11:28 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgPwW-0007F5-Aj for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 16:11:28 +0000 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d389db73-f22c-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 17:11:20 +0100 (CET) Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jan 2026 08:11:19 -0800 Received: from lkp-server01.sh.intel.com (HELO 765f4a05e27f) ([10.239.97.150]) by orviesa007.jf.intel.com with ESMTP; 15 Jan 2026 08:11:14 -0800 Received: from kbuild by 765f4a05e27f with local (Exim 4.98.2) (envelope-from ) id 1vgPwF-00000000IBQ-0m18; Thu, 15 Jan 2026 16: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: d389db73-f22c-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1768493481; x=1800029481; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=gFIoEC1f1qlzIUpk/6FrkLxr7vkPH7lbau/8uT3TPbk=; b=Ai//pSkzXrHAyhBvqUxZfQzZvPfO2GIxCTtGQuAOM4+y7v4ZW2VFmB64 GL59F1+3KBpv0hIEDiVt5xCHRjpzFTtavQ4Iurf5BpoBnQU7SdK4bfM+n 5Di7/zS+q4RJXY8KWG7Sjn6O3aHr/XPlF4LSzOdBvYTB4L8igQLwxBsJE PTE3BycLp55RxeQlcKyRjrDjNVI6suEYiohcD7CCxXzBVN4oqGPbFHD9h 5uKpgdhBc6oulQBAsOzE5USZe/BzJ2TWK4dwvJe4ahSJTnwVIjQ1iBYnd RYv9ElzfFxrGL75NGyaYfs4SDqS9JhTqqEKmRtpefHr7wZW+YZeh0LIDi Q==; X-CSE-ConnectionGUID: P2S7flEKRmesLbaS43dFCQ== X-CSE-MsgGUID: AETCUT9KQRupmjY6Z1DepA== X-IronPort-AV: E=McAfee;i="6800,10657,11672"; a="69701548" X-IronPort-AV: E=Sophos;i="6.21,228,1763452800"; d="scan'208";a="69701548" X-CSE-ConnectionGUID: T0RnRcTxRsGGrhE5Yp0D6g== X-CSE-MsgGUID: 0Lh0zAVbQ2yEnGpU34emxg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,228,1763452800"; d="scan'208";a="205020917" Date: Fri, 16 Jan 2026 00:10:12 +0800 From: kernel test robot To: Juergen Gross , linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux.dev, kvm@vger.kernel.org Cc: oe-kbuild-all@lists.linux.dev, Juergen Gross , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Paolo Bonzini , Vitaly Kuznetsov , Boris Ostrovsky , xen-devel@lists.xenproject.org Subject: Re: [PATCH v3 1/5] x86/paravirt: Replace io_delay() hook with a bool Message-ID: <202601152321.kJ6D4yKM-lkp@intel.com> References: <20260115084849.31502-2-jgross@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260115084849.31502-2-jgross@suse.com> Hi Juergen, kernel test robot noticed the following build errors: [auto build test ERROR on tip/master] [also build test ERROR on next-20260115] [cannot apply to kvm/queue kvm/next tip/x86/core kvm/linux-next tip/auto-latest linus/master v6.19-rc5] [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-Replace-io_delay-hook-with-a-bool/20260115-165320 base: tip/master patch link: https://lore.kernel.org/r/20260115084849.31502-2-jgross%40suse.com patch subject: [PATCH v3 1/5] x86/paravirt: Replace io_delay() hook with a bool config: x86_64-randconfig-006-20260115 (https://download.01.org/0day-ci/archive/20260115/202601152321.kJ6D4yKM-lkp@intel.com/config) compiler: gcc-12 (Debian 12.4.0-5) 12.4.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260115/202601152321.kJ6D4yKM-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/202601152321.kJ6D4yKM-lkp@intel.com/ All errors (new ones prefixed by >>): arch/x86/kernel/tboot.c: In function 'tboot_shutdown': >> arch/x86/kernel/tboot.c:255:17: error: implicit declaration of function 'halt' [-Werror=implicit-function-declaration] 255 | halt(); | ^~~~ cc1: some warnings being treated as errors vim +/halt +255 arch/x86/kernel/tboot.c 58c41d28259c24 H. Peter Anvin 2009-08-14 225 3162534069597e Joseph Cihula 2009-06-30 226 void tboot_shutdown(u32 shutdown_type) 3162534069597e Joseph Cihula 2009-06-30 227 { 3162534069597e Joseph Cihula 2009-06-30 228 void (*shutdown)(void); 3162534069597e Joseph Cihula 2009-06-30 229 3162534069597e Joseph Cihula 2009-06-30 230 if (!tboot_enabled()) 3162534069597e Joseph Cihula 2009-06-30 231 return; 3162534069597e Joseph Cihula 2009-06-30 232 11520e5e7c1855 Linus Torvalds 2012-12-15 233 /* 11520e5e7c1855 Linus Torvalds 2012-12-15 234 * if we're being called before the 1:1 mapping is set up then just 11520e5e7c1855 Linus Torvalds 2012-12-15 235 * return and let the normal shutdown happen; this should only be 11520e5e7c1855 Linus Torvalds 2012-12-15 236 * due to very early panic() 11520e5e7c1855 Linus Torvalds 2012-12-15 237 */ 11520e5e7c1855 Linus Torvalds 2012-12-15 238 if (!tboot_pg_dir) 11520e5e7c1855 Linus Torvalds 2012-12-15 239 return; 11520e5e7c1855 Linus Torvalds 2012-12-15 240 3162534069597e Joseph Cihula 2009-06-30 241 /* if this is S3 then set regions to MAC */ 3162534069597e Joseph Cihula 2009-06-30 242 if (shutdown_type == TB_SHUTDOWN_S3) 58c41d28259c24 H. Peter Anvin 2009-08-14 243 if (tboot_setup_sleep()) 58c41d28259c24 H. Peter Anvin 2009-08-14 244 return; 3162534069597e Joseph Cihula 2009-06-30 245 3162534069597e Joseph Cihula 2009-06-30 246 tboot->shutdown_type = shutdown_type; 3162534069597e Joseph Cihula 2009-06-30 247 3162534069597e Joseph Cihula 2009-06-30 248 switch_to_tboot_pt(); 3162534069597e Joseph Cihula 2009-06-30 249 3162534069597e Joseph Cihula 2009-06-30 250 shutdown = (void(*)(void))(unsigned long)tboot->shutdown_entry; 3162534069597e Joseph Cihula 2009-06-30 251 shutdown(); 3162534069597e Joseph Cihula 2009-06-30 252 3162534069597e Joseph Cihula 2009-06-30 253 /* should not reach here */ 3162534069597e Joseph Cihula 2009-06-30 254 while (1) 3162534069597e Joseph Cihula 2009-06-30 @255 halt(); 3162534069597e Joseph Cihula 2009-06-30 256 } 3162534069597e Joseph Cihula 2009-06-30 257 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki From xen-devel-bounces@lists.xenproject.org Thu Jan 15 16:32:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 16:32:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205536.1519746 (Exim 4.92) (envelope-from ) id 1vgQGx-000209-QQ; Thu, 15 Jan 2026 16:32:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205536.1519746; Thu, 15 Jan 2026 16: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 1vgQGx-000202-Nn; Thu, 15 Jan 2026 16:32:35 +0000 Received: by outflank-mailman (input) for mailman id 1205536; Thu, 15 Jan 2026 16:32:34 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgQGw-0001zw-H8 for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 16:32:34 +0000 Received: from mail187-33.suw11.mandrillapp.com (mail187-33.suw11.mandrillapp.com [198.2.187.33]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c7c1abec-f22f-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 17:32:28 +0100 (CET) Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail187-33.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4dsT6M09z8zBsTlVw for ; Thu, 15 Jan 2026 16:32:27 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 9f7b2055ceaf426ca865a44bdff1f793; Thu, 15 Jan 2026 16:32: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: c7c1abec-f22f-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1768494747; x=1768764747; bh=9twe24x1zX+FLh6t5OJMyT3WR+NCn2bdCavyVwLMpfw=; 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=sD+lXiiuSX1xmQ0NQ+9EKZNmfG7tDBfm7klxPHh1/ifTCHlq+RMTWUstmIYdJhCtE IP9uSfFcCRxgJ7JazzJB4X58Wi7cevH2E5Qyk6LGPw2hL+6wzdMiFqPjdT23QcQzPd tyZ3s+kdlKwvdWHJwSfdKABFPtu4tAniERS+xdl9MyQlnR1CZD3iC463uytWfD+F08 FYCmp62pjLndK4RRQFQDagD/fW0Bwq/wR/rF9ynW/smjDocaow1YdcIxfYGAWgnHVb 7ckBp3EJNrvqHmjXDJznnsiok8zCotLSPJRqPBjg2uacYYNc5pU7QwxABr2hAN4jen RRBfn453ZPaBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1768494747; x=1768755247; i=teddy.astie@vates.tech; bh=9twe24x1zX+FLh6t5OJMyT3WR+NCn2bdCavyVwLMpfw=; 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=XJtk69ronuHWiHSiehBsxk+F5b4hdC4QkmrQIA92WEGUckhhy/7J+v7JiRzjQi+pL wZ0pZdgcLPGvm7mZKEFp67uKpmfA8tAZ/yk0NYXnES0KA2KFTtv8Lnz3iswPySKaFJ opvguRTUDgw4ro6d6VLHf0DCU/lEh3XHqf/Xf4uDtxD/xH5IksH4hWxllvshhDeJKR 2Fi94FKrQ7FrG9NRsw77z0gGwSyd6VgFoaeQ3P7NNdqlK5NugKxAqLxiTME8zIWY79 VUa0CqhlcMmWHMlbgK8mD5IG1hL3K1QBzlHDtRF/9u98EETOPBF4M1ckpaV7te0UId 1P4lgKihVUeXA== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH]=20xen:=20Move=20NX=20handling=20to=20a=20dedicated=20place?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1768494745417 Message-Id: To: "Andrew Cooper" , "Julian Vetter" , xen-devel@lists.xenproject.org Cc: "Jan Beulich" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Daniel P . Smith" , "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" References: <20260115151658.3725784-1-julian.vetter@vates.tech> <69b511db-654d-46b3-aca3-3f37f30d3473@citrix.com> In-Reply-To: <69b511db-654d-46b3-aca3-3f37f30d3473@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.9f7b2055ceaf426ca865a44bdff1f793?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260115:md Date: Thu, 15 Jan 2026 16:32:26 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 15/01/2026 =C3=A0 16:50, Andrew Cooper a =C3=A9crit=C2=A0: > On 15/01/2026 3:17 pm, Julian Vetter wrote: >> Currently the CONFIG_REQUIRE_NX prevents booting XEN, if NX is disabled >> in the BIOS. AMD doesn't have a software-accessible MSR to re-enable it, >> so there is nothing we can do. The system is going to die anyway. But on >> Intel NX might just be hidden via IA32_MISC_ENABLE.XD_DISABLE. But the >> function to re-enable it is called after the check + panic in >> efi_arch_cpu. So, this patch removes the early check and moves the >> entire NX handling into a dedicated place. >> >> Signed-off-by: Julian Vetter > > Sorry I didn't get around to doing the prep work I promised. > > This is going along the right lines, but there are a few complexities sti= ll. > > Also you'll want to split the patch into a series.=C2=A0 More on that whe= n > we've sorted out a few other details. > >> diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoli= ne.S >> index a92e399fbe..8e8d50cbdf 100644 >> --- a/xen/arch/x86/boot/trampoline.S >> +++ b/xen/arch/x86/boot/trampoline.S >> @@ -144,10 +144,9 @@ gdt_48: >> GLOBAL(trampoline_misc_enable_off) >> .quad 0 >> >> -/* EFER OR-mask for boot paths. SCE conditional on PV support, NX adde= d when available. */ >> +/* EFER OR-mask for boot paths. SCE conditional on PV support. */ > > The comment wants to stay as-was.=C2=A0 NX does get added when available. > >> GLOBAL(trampoline_efer) >> - .long EFER_LME | (EFER_SCE * IS_ENABLED(CONFIG_PV)) | \ >> - (EFER_NXE * IS_ENABLED(CONFIG_REQUIRE_NX)) >> + .long EFER_LME | (EFER_SCE * IS_ENABLED(CONFIG_PV)) >> >> GLOBAL(trampoline_xen_phys_start) >> .long 0 >> diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm= /setup.h >> index b01e83a8ed..16f53725ca 100644 >> --- a/xen/arch/x86/include/asm/setup.h >> +++ b/xen/arch/x86/include/asm/setup.h >> @@ -70,4 +70,6 @@ extern bool opt_dom0_msr_relaxed; >> >> #define max_init_domid (0) >> >> +void nx_init(void); >> + >> #endif >> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c >> index 27c63d1d97..608720b717 100644 >> --- a/xen/arch/x86/setup.c >> +++ b/xen/arch/x86/setup.c >> @@ -1119,6 +1119,50 @@ static struct domain *__init create_dom0(struct b= oot_info *bi) >> return d; >> } >> >> +void __init nx_init(void) > > This should be static if it's only used in a single file.=C2=A0 However, = see > later for doing it a bit differently. > >> +{ >> + uint64_t misc_enable; >> + uint32_t eax, ebx, ecx, edx; >> + >> + if ( !boot_cpu_has(X86_FEATURE_NX) ) >> + { >> + /* Intel: try to unhide NX by clearing XD_DISABLE */ >> + cpuid(0, &eax, &ebx, &ecx, &edx); >> + if ( ebx =3D=3D X86_VENDOR_INTEL_EBX && >> + ecx =3D=3D X86_VENDOR_INTEL_ECX && >> + edx =3D=3D X86_VENDOR_INTEL_EDX ) >> + { >> + rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable); >> + if ( misc_enable & MSR_IA32_MISC_ENABLE_XD_DISABLE ) >> + { >> + misc_enable &=3D ~MSR_IA32_MISC_ENABLE_XD_DISABLE; >> + wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable); >> + >> + /* Re-read CPUID after having cleared XD_DISABLE */ >> + boot_cpu_data.x86_capability[FEATURESET_e1d] =3D cpuid_= edx(0x80000001U); >> + >> + /* Adjust misc_enable_off for secondary startup and wak= eup code */ >> + bootsym(trampoline_misc_enable_off) |=3D MSR_IA32_MISC_= ENABLE_XD_DISABLE; >> + printk(KERN_INFO "re-enabled NX (Execute Disable) prote= ction\n"); >> + } >> + } >> + /* AMD: nothing we can do - NX must be enabled in BIOS */ > > The BIOS is only hiding the CPUID bit.=C2=A0 It's not blocking the use of= NX. > > You want to do a wrmsr_safe() trying to set EFER.NXE, and if it > succeeds, set the NX bit in MSR_K8_EXT_FEATURE_MASK to "unhide" it in > regular CPUID.=C2=A0 This is a little more tricky to arrange because it n= eeds > doing on each CPU, not just the BSP. > I see this MSR in the BKDG (bit 20 is NX). Are these bits stable across the AMD CPU generations ? >> + } >> + >> + /* Enable EFER.NXE only if NX is available */ >> + if ( boot_cpu_has(X86_FEATURE_NX) ) >> + { >> + if ( !(read_efer() & EFER_NXE) ) >> + write_efer(read_efer() | EFER_NXE); >> + >> + /* Adjust trampoline_efer for secondary startup and wakeup code= */ >> + bootsym(trampoline_efer) |=3D EFER_NXE; >> + } >> + >> + if ( IS_ENABLED(CONFIG_REQUIRE_NX) && !boot_cpu_has(X86_FEATURE_NX)= ) >> + panic("This build of Xen requires NX support\n"); >> +} >> + >> /* How much of the directmap is prebuilt at compile time. */ >> #define PREBUILT_MAP_LIMIT (1 << L2_PAGETABLE_SHIFT) >> >> @@ -1159,6 +1203,8 @@ void asmlinkage __init noreturn __start_xen(void) >> rdmsrl(MSR_EFER, this_cpu(efer)); >> asm volatile ( "mov %%cr4,%0" : "=3Dr" (info->cr4) ); >> >> + nx_init(); >> + >> /* Enable NMIs. Our loader (e.g. Tboot) may have left them disabl= ed. */ >> enable_nmis(); >> > > This is too early, as can be seen by the need to make a cpuid() call > rather than using boot_cpu_data. > > The cleanup I wanted to do was to create/rework early_cpu_init() to get > things in a better order, so the panic() could go at the end here.=C2=A0 = The > current split we've got of early/regular CPU init was inherited from > Linux and can be collapsed substantially. > > The intel "unlocking" wants to move back into early_init_intel(), along > with intel_unlock_cpuid_leaves().=C2=A0 (This is where it used to live be= fore > REQUIRE_NX was added). > > The AMD side probe wants to live in early_amd_init()=C2=A0 (not that ther= e is > one right now), but the re-enabling of the NX bit in CPUID needs to also > be in amd_init() so it gets applied to APs too. > > Does this make sense? Sounds good to me, I suppose there is no use of NX before this ? > > ~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 Thu Jan 15 16:36:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 16:36:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205556.1519756 (Exim 4.92) (envelope-from ) id 1vgQKc-0002d1-CB; Thu, 15 Jan 2026 16:36:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205556.1519756; Thu, 15 Jan 2026 16: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 1vgQKc-0002cu-9H; Thu, 15 Jan 2026 16:36:22 +0000 Received: by outflank-mailman (input) for mailman id 1205556; Thu, 15 Jan 2026 16:36:21 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgQKb-0002cl-Ex for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 16:36:21 +0000 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [2a00:1450:4864:20::342]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 521132b9-f230-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 17:36:19 +0100 (CET) Received: by mail-wm1-x342.google.com with SMTP id 5b1f17b1804b1-47d63594f7eso7613495e9.0 for ; Thu, 15 Jan 2026 08:36:20 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-434af65363dsm7032369f8f.13.2026.01.15.08.36.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 08:36:18 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 521132b9-f230-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768494979; x=1769099779; 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=HWoVJSYtgIiM0jpqJ0ctVniWXXN4CsswtXafNoh3awE=; b=IG34ZbIn7OXuXsiE9Ujn3BuS8lKUcyGVyilqYLXwxXThmfXOuZpQMBmv0bDw3RbZBz t4KEY8WBRIXSmS5g5el/+jo4Zfp1ZZgT7yZS03z68bdubrZdbD3kjd+vo/joWB9TfJGx zwZ+lr8hTrWCZuQQ1G2XFvpbEdrI2bD6E1mjSNqzrca7VIbH2CJECgT1L8AOBrGYYMWk 92SMQDoQR89lcK2DJLVVB/OKG2Y98XXlM35Q6tNpSrghipDVQ87F+UpI3JpBrQFy5Y+w WrhwdIJPfQEjA/Nfb7y/n2hw8m1jPlLeOv8nhaSVmMx6lGpWN8U1R1y6fwbwG7E3LBCY zEQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768494979; x=1769099779; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=HWoVJSYtgIiM0jpqJ0ctVniWXXN4CsswtXafNoh3awE=; b=hmo9m+PKxzS7xGUpb6YsOlB9grexiORvX7I404PuQmJraWueP5yHY2ccPNhJxoe4vh WvXsaCRDMeUlQQnDBr9pM9ayn/8vatFM4xEbieYZ7uy38714kpMuroCgHO7jrXBYsrEw EMcBjSA2nfPvSRq8D8lMZizhsCPz0+GOVTgFLsAZtGBL1zNDMOMNUI4S71v90KBXYLcw Ufgs7mvEyiXqkdZT6riaewKGfnOmLLk0RPBMmeh6N3rGZQcBM8gH2iKTf1UZ1Ap8Jb12 VwrhAT2DwvzgNYAZs9tu/y35OMRBDfiQ40uqK9itAv9dyUUtUhp33khDl5pZWkIH1euQ SbjA== X-Gm-Message-State: AOJu0YwTPToLlVW1bEAjrOhehbeQdCAY/FqqYPyW3xoOxCwuCbQ6vYef ElCTe3Tw3FeBqNwUiyO1rlj/CTckEztCG6/DCXEvhNy8+bmmC4jTK6QXmXln8vSsqw== X-Gm-Gg: AY/fxX6H1c1f2i7teS7yin9fR0ZQJM3e5lyeglgT7m6nTcNQ6pco9FCrqEBzWKsbZVY 2Tovzba7EeUWA5SATiSbh3D27LLvPfhFfImn43SEjihwn4Lj5xJ9ALOCsCBT9VUoYG3Tf6w35Ux A2jUGyXP4BYcHvPhmvpkaE26ydST3SI6jIOSHXI0n43VP0IjbA/xwk+AFolHnc5ViFQKl3uGyZ+ 8maQ0BG0qSGp02FtlaWewl7FDT2mLAH+f9usKrDVB39dlguuMaYRxk/Hrlotoumn6CBFF6RpCoc qEHYEsO3dSuH5ENl0I4pxklhH3lHpg9oApevlQnR/BzqnvgpD7pY/4e68hDhIILmE7WiROe6sha aKOV2OIWoCKkWndJURZLgcta3YPlNK+UsjT2d9u77Owl/SK2uv3ZCI3yAVa03iUdPt9pQr2rn7R phblK1fuQ4Z2WnQEz+eq82ntx3LXwA+CglGzXnufhWj5QThA3b9zrPSoTs7EJ3/3oG5EGToNzZs 1s= X-Received: by 2002:a05:600c:1d07:b0:477:a21c:2066 with SMTP id 5b1f17b1804b1-4801e2fc194mr4183835e9.5.1768494979300; Thu, 15 Jan 2026 08:36:19 -0800 (PST) Message-ID: Date: Thu, 15 Jan 2026 17:36:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Strange symbols_lookup() behaviour in test-symbols on arm64 CI From: Jan Beulich To: Mykola Kvach Cc: Xen-devel , Volodymyr Babchuk References: <10aaed6d-6cb1-4bed-aa8c-5f9761f04fde@suse.com> <35819233-07ba-4e00-8939-74b2f4454250@suse.com> Content-Language: en-US Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 15.01.2026 16:33, Jan Beulich wrote: > On 14.01.2026 07:00, Mykola Kvach wrote: >> On Mon, Dec 15, 2025 at 1:27 PM Jan Beulich wrote: >>> On 15.12.2025 12:00, Mykola Kvach wrote: >>>> On Thu, Dec 11, 2025 at 6:40 PM Jan Beulich wrote: >>>>> On 11.12.2025 17:30, Mykola Kvach wrote: >>>>>> I have now attached the corresponding build log. >>>>> >>>>> Okay, so indeed not a table size change issue here. Then I fear some instrumenting >>>>> will be needed to at least know what exactly is going wrong. Alternatively you could >>>>> arrange for the intermediate binaries to not be deleted, and make them available >>>>> somehow / somewhere for me to see whether by inspection I can gain some clue. >>>> >>>> I prepared a small patch to keep the intermediate artifacts instead of >>>> deleting them. >>>> >>>> It removes two cleanup commands: >>>> xen/arch/arm/Makefile: drops rm -f $(@D)/.$(@F).[0-9]* (keeps >>>> .xen-syms.* intermediates) >>> >>> This alone should be sufficient. >> >> Understood. I have rerun the build with the cleanup line removed >> so the intermediate .xen-syms.* files are kept. >> >> The build artifacts are available here: >> https://gitlab.com/xen-project/people/mykola_kvach/xen/-/jobs/12707528457/artifacts/browse/xen/ > > Apart from the intermediate files there's a file named xen there, but xen-syms > is missing. I'll see what I can do without that. I will need that file along with the temporary ones, sorry. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 15 16:58:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 16:58:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205589.1519766 (Exim 4.92) (envelope-from ) id 1vgQfL-00060W-UJ; Thu, 15 Jan 2026 16:57:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205589.1519766; Thu, 15 Jan 2026 16:57:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgQfL-00060P-Rd; Thu, 15 Jan 2026 16:57:47 +0000 Received: by outflank-mailman (input) for mailman id 1205589; Thu, 15 Jan 2026 16:57: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 1vgQfL-0005xn-58 for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 16:57:47 +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 50b72891-f233-11f0-b15e-2bf370ae4941; Thu, 15 Jan 2026 17:57:46 +0100 (CET) Received: by mail-wm1-x343.google.com with SMTP id 5b1f17b1804b1-47ee4338e01so4655715e9.2 for ; Thu, 15 Jan 2026 08:57:46 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4801e886834sm517335e9.7.2026.01.15.08.57.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 08:57:45 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 50b72891-f233-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768496265; x=1769101065; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=x3yQYz+MAWJqOoD/uYGsKdGLFxX7a98Zg2P2/v9r7ic=; b=ZnO4xDjvpiP70ZPFCfezUE8SrpqE8R/X9eKMAxo6q2omzu79S/ybKhXhwK4lmVuEgr +bvqrbXzJtm/ljEICzkwXbqa/3998ZTYixn2K8iqBSZcQp/aufd+eSQSe9tVK80MGkKt nquSxB9KLc0b2laVG23PhLvrCWuc9k8McMbQnHpCsm8j45uhHqAfUQcg2DEy7FYF/kom BIc8pKG2SfhFIxPQ+h8p3sAyVO3ppD9U+/qevtxVO9h6GWZ3lhty+FU0VDJ4KLWeVUnp txdp8vwAmDnO7NMIo6mWYWRTDW2sE//0AEMCxukO8jd8L1PCTBu7ce9MkSUzzQmSFtyZ m6PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768496265; x=1769101065; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=x3yQYz+MAWJqOoD/uYGsKdGLFxX7a98Zg2P2/v9r7ic=; b=JSuPVkksYlPupdetnTdc4dWBCTkAy8Cpw8wmNiw2AD06DGXUpNOh/+sfLccFxr1ClX /cWCRas74gZPaPRnDQZh43g2KvWEDVlfGiuN8nTCKBgaGotx2QbxNuQVmbIPTamUzyLp EaD/UjLOOxzKLzO400cFtYKncw5FIM7THZKqqKLfLH03Zf9Kifc6eIOY6qlsO6M3Y9oN Rx9uv3oxCi3r9RpXtxq5CARkrE2qv4FEFqAkQ8eRVsPnge+SmXyOBXFZGCYmNZlh8GJv kiDnQZLBWA7/LJ5tKbCOaJh5GsYammmw0+YfMJSCHxTHi+MK8/7uHklmxD63hqyZD2YL JhxQ== X-Gm-Message-State: AOJu0YzFVygel91TYvuG53+gc8x8V7psJzYomGsXUqMSXYI85ilciFPC FUr3S8d8W83ZIp1N2B2t0Qy2bzaOCIjTRXek26HZHkYKfCSVwVt2E+P+xamXKZ9xGQ== X-Gm-Gg: AY/fxX5HDdpvsE3jgAsLjwyhjpRfKFxbyQGOgz9FqGullcz8WTJtbmUkc7i05Cb0+e6 51QQtt678+w0WPFbVjNnOB2I0j8NUSNtHTfD3PSR6iwvzopwTTXWugfUglNkGr260VhzOjG9vcw f+BmBnE8fW2rm48CsOPTbpF7zCB45pi296Q/d37HKm1c+lATDQc9D2yFSp53IgiD7HpOScuqWgW WbZa/+NZk+UUnAszTRM/u4Ux+e4clrNbkp1U5S4q6caTzbSrqcB82Od5UN2qYlq072QQct/UpsD VknBLlsTgSSZAom1EbqMYyeCIh8bEPckBi0pZ4/ivvC5AvW+8bTx+VB7Tmak6YMKecucOhceJld 4VA1wwHS8jSdN1BQiNjzHD+TDHOTCIO+KWpoVgt8cVFTFjEJPbDrfPdYbKYmGJLxJ+Jcag8WzET T+4S91g+Co0LIzLbctDahW1LwI3ng2UVCvpVW8/qYT6KSnRJS7FslnBd31KzxsiQXFafbKCJ7Em 6M= X-Received: by 2002:a05:600c:3b9f:b0:477:582e:7a81 with SMTP id 5b1f17b1804b1-4801e2f5357mr4871315e9.4.1768496265541; Thu, 15 Jan 2026 08:57:45 -0800 (PST) Message-ID: Date: Thu, 15 Jan 2026 17:57:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jan Beulich Subject: Re: Strange symbols_lookup() behaviour in test-symbols on arm64 CI To: Mykola Kvach Cc: Xen-devel , Volodymyr Babchuk References: <10aaed6d-6cb1-4bed-aa8c-5f9761f04fde@suse.com> <35819233-07ba-4e00-8939-74b2f4454250@suse.com> Content-Language: en-US Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 15.01.2026 16:33, Jan Beulich wrote: > On 14.01.2026 07:00, Mykola Kvach wrote: >> On Mon, Dec 15, 2025 at 1:27 PM Jan Beulich wrote: >>> On 15.12.2025 12:00, Mykola Kvach wrote: >>>> On Thu, Dec 11, 2025 at 6:40 PM Jan Beulich wrote: >>>>> On 11.12.2025 17:30, Mykola Kvach wrote: >>>>>> I have now attached the corresponding build log. >>>>> >>>>> Okay, so indeed not a table size change issue here. Then I fear some instrumenting >>>>> will be needed to at least know what exactly is going wrong. Alternatively you could >>>>> arrange for the intermediate binaries to not be deleted, and make them available >>>>> somehow / somewhere for me to see whether by inspection I can gain some clue. >>>> >>>> I prepared a small patch to keep the intermediate artifacts instead of >>>> deleting them. >>>> >>>> It removes two cleanup commands: >>>> xen/arch/arm/Makefile: drops rm -f $(@D)/.$(@F).[0-9]* (keeps >>>> .xen-syms.* intermediates) >>> >>> This alone should be sufficient. >> >> Understood. I have rerun the build with the cleanup line removed >> so the intermediate .xen-syms.* files are kept. >> >> The build artifacts are available here: >> https://gitlab.com/xen-project/people/mykola_kvach/xen/-/jobs/12707528457/artifacts/browse/xen/ > > Apart from the intermediate files there's a file named xen there, but xen-syms > is missing. I'll see what I can do without that. Actually, can you give the patch below a try? That would explain the 24-byte difference (albeit I'm struggling with some other aspects of a proper explanation). Jan --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -87,13 +87,13 @@ endif $(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds $(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S $(MAKE) $(build)=$(@D) $(dot-target).0.o - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< \ + $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ $(dot-target).0.o -o $(dot-target).0 $(NM) -pa --format=sysv $(dot-target).0 \ | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ > $(dot-target).1.S $(MAKE) $(build)=$(@D) $(dot-target).1.o - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< \ + $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ $(dot-target).1.o -o $(dot-target).1 $(NM) -pa --format=sysv $(dot-target).1 \ | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ From xen-devel-bounces@lists.xenproject.org Thu Jan 15 17:33:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 17:33:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205648.1519776 (Exim 4.92) (envelope-from ) id 1vgRDz-0002l1-Hk; Thu, 15 Jan 2026 17:33:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205648.1519776; Thu, 15 Jan 2026 17:33:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgRDz-0002ku-F8; Thu, 15 Jan 2026 17:33:35 +0000 Received: by outflank-mailman (input) for mailman id 1205648; Thu, 15 Jan 2026 17:33: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 1vgRDx-0002ko-Vo for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 17:33:34 +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 4ba3b0bf-f238-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 18:33:28 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS2PR03MB8158.namprd03.prod.outlook.com (2603:10b6:8:27b::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Thu, 15 Jan 2026 17:33:22 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.005; Thu, 15 Jan 2026 17:33: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: 4ba3b0bf-f238-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DU76gdvHuIPHw8RmlSiewDp1pR5W+36ltDLE2S4Kdi5QlW7v5cSRTQYPsuJoaV4D3XTrsHJnPZ3DtQW/r82r+5VRw4q4k23P3fcSluxWvxCBbKyHkoee7JrzVyglTZPAet6YxwfETed+jbSK4YRHRNuQUqzDn23HWCjl7Dbk2LjK95UGVToqjPlOpPz+l7Nn/nBwoJVo3QpYVeMBhvgvUrExxAurXrqiGqsGzATjEl0piFKThXq4NtemYLBJMLsEsvQofCCrL586bsEGmwEjZy5hd/8D7R3ySuZMm/1T2ve73qylGOFGz2dz9U01psCEzPIGo+BMXXzKHYtFCaNfrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EBwI/3ozVYTUN92TwQP6D4wLM33n82wTqfF7bmaMe2U=; b=TfPOWGgoc4dpNhWCXPCLFThSfHaVZyG5ITfjNa4IVvIqNlvtY5FvX37a0mfJDQ9qVEgzJrCqUBCXbEDwlBnQXtsn+EeOW0mffRA+h6nDuKKuuuHS0ax65yr3mwTpvz4xlNb5FRjrQnpY2oklD0OYsVQs4jS1deMrILsLNtmS+e9sdx9yJEqcZVFypnvUYgua5JfyOTDdp81HXiw4c3T8kMREDH48+mEk96UmpVa4My3rs+uJVEljD9N5IpvcpfZdbEN6P70KxO+0BGVelg1VLESVRfzpj/2N9St3s3NnRrLf/bKQb8fAzOk+FCUi1Lbhk9aTZNkh2NXGGffGne9o4w== 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=EBwI/3ozVYTUN92TwQP6D4wLM33n82wTqfF7bmaMe2U=; b=rrevciZDSk/05oLza/TYH5APTRUNcKICGr7OOZzIIMJMAMvmYLc6pIdLGic6Q0adXAlAkaoC9Q/KSvntvVAFxz1aoK/NYouZR6gjJnLrs1vFEqSbnTGo/LEpOwPxq0I7V2vjTGYOFq2Wp+TD8Xq6+4LvJK2ZF0EVjSiphuG387Y= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <57a89245-d493-41a8-9e1d-adfab2282771@citrix.com> Date: Thu, 15 Jan 2026 17:33:18 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P . Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= Subject: Re: [PATCH] xen: Move NX handling to a dedicated place To: Teddy Astie , Julian Vetter , xen-devel@lists.xenproject.org References: <20260115151658.3725784-1-julian.vetter@vates.tech> <69b511db-654d-46b3-aca3-3f37f30d3473@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0134.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2c4::6) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS2PR03MB8158:EE_ X-MS-Office365-Filtering-Correlation-Id: efec6832-70ca-40a2-c724-08de545c2ded 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?YjNQZ3dWZUJmRmxaMUFuRFM1THVoTzhPcHNKUHJHMGRLK3pHWWNKbmFPbXQ5?= =?utf-8?B?M253ZUI3bUJUT0VWS0RyV0JkUmYwQ1ZMWHJ4SHpNTnNRTmVqcWY2djA0TUhh?= =?utf-8?B?K3RWWkh2dGRkanFkZnQ3RURSQmE3ZnYyVWlkL2hyK1RHSkxtdSt5OTZQN29P?= =?utf-8?B?QS9KT0F3NkpYNnpIVms5bmtzVXNMWGdrQnhsOFkvc0ZoazlhaDIwOXN2Z2w0?= =?utf-8?B?bUhUK0s0T0dhVjc5Y05TbktJN203VVh1Z2dyME81MDlseWFOWTBUVkY2Zzk3?= =?utf-8?B?M1phKzJLSHh1UDF4OXduNC9vTk1yYnF1eVcrNXFnRFlEV09rQnlTbnFnd3dT?= =?utf-8?B?aHZMWHpTMUZTYXh4eWJackhKZHV5MW1ITmlvMFo5ZVowQkJacU9pYk9tZVlG?= =?utf-8?B?VWhPNk1IaExMNm1hSFB0MDh6L0JnY3Y5N1RHRnEwOWtHS0tnN0RFMDNOYmZW?= =?utf-8?B?L05EZURyRVBLLzVKT2EvMDA3aTFEMFhUNHB6VTJ5dWUvSnY0Wld3RkgzNkhy?= =?utf-8?B?WFJFMUZiQXhNVnd6UlNNUkd4Vk9nVForTkdGVFNnN1hDODdjT045dDk1aHll?= =?utf-8?B?VEh0a2JMOHgvVEg3L3lid25FSUs4SzdjL09kTFg5NWZNZVdhVWpUd3AyVlJk?= =?utf-8?B?Z2dIbUUwMWlYaTZ0S2VGckJzNU9HdTIzL01mdVdGRzJYanFhMHBoUW5DT08w?= =?utf-8?B?ZXduT2FKVjJ5RFRObWhxUTM3UEFrTWRMSmFQZjB1eXF2UW9reWtYak1IeHVx?= =?utf-8?B?TTMzcm5RM0JnZzZ2N1hzVjJvRFRkUmg3OUE2M2FpRERBSkxhUjkxcjQ5bHZW?= =?utf-8?B?THZPejZ0UWQyaXh6dGwxWDhGckRYS0FKWHd3V0lHZ1h4ZnoyempNYjZ0VXV3?= =?utf-8?B?N3R1UDdyUmNSUG5QZlE1Q2pVRUNHZmhadFBxdm9uejFWQXJiNEdUcmg2cWp1?= =?utf-8?B?ejJjUmc4NDdBcUhyZTl6TGJycHRYcGlSL09uUDhpTTBoUVdRaTZ0SHpsMXd3?= =?utf-8?B?MndnZ3FhdWRRdDBiUzBpNkg4Rk9ab2JwYVhvY08zSmNsaUE3M01yZVN1UDJa?= =?utf-8?B?dWFRd25ienJSK0wrSll0MXMvekc0dFJJbkJxdDNrRDBzVmxGc25YMml2azhK?= =?utf-8?B?MjlQdmFZc1R5QXlIRmM4c3poWUEveURvUnUya2grSGt5WmIvbnBCOGFCSGM1?= =?utf-8?B?eXZLaHA5YlJkdDRTS0tMekFzckxUaUhVWk9UdzMySkRDVmxtSktraGNDZHpv?= =?utf-8?B?M1VyQlY1UDc0WVVxUGlxbTR5YmcvWWNHRzJ0Z29ZUFZDQUVJeVExNU01dWNy?= =?utf-8?B?d0ZBb0JLQVUyek9iT2UyL1Vmd0dNSG96VE5vcFVkVWJTMjFXUWc1dVZwRWR6?= =?utf-8?B?cTZrdFZUQXYyRkthMzFqSlpBa2hybksvWVROMGM0dnE3N0greGNMVzVzRjRo?= =?utf-8?B?OFh0YWRzT0UrS0p6MFNqTFZsblJLN0Y1NHlYZjVjYVBESWNhS2V1YkJHYUQ4?= =?utf-8?B?Znp2bmRYY2tJYkIyYkhORWhFUDdHR3orVG4vaEc3U1YrMzlHM2QxekdnZ3Bs?= =?utf-8?B?Rnh6V0dOUnQxaDh4RXhKQ3c3cmllQjMwRVFKU1A3T2hUVVRSTEJKcjNPSy9G?= =?utf-8?B?K283UWVXL0Y2TGpQR2RMSmVmSmlmRFNUeDRFV1lINGtQdGEvc1EvNjFWenNS?= =?utf-8?B?QmtoNTMxdCszVjcrQVQ2Szd2UlpTeFJZaEMweTUvWmdBU3ZwUElld3RocElE?= =?utf-8?B?TnB4Rk1pRWY3aUdFdWtud2RzTytrcTJUMzN1YnpOcDF1Y0NsK2YyWWhEZEY3?= =?utf-8?B?TmJvbjh5Q2Y1N0dtZ1U4WEdwTGxlbmllY1VpWjRoNk15Tnh2VlFIRGJjcHMr?= =?utf-8?B?K25tUHI1OFZ0VFlNT05PdWQyWkNhRjFja3ZCRnZOSlFDVEYxdWdHYjNJa080?= =?utf-8?B?UmVSanhIMmFGUkxHUXcwZnZhSWZ4Yjk2QmdhSU9MUmxuRlk2UHB3VGMwNHpi?= =?utf-8?B?TElnaFY4dlE3aTNsS2ZhTDlSUStJZ0FSK1VMR3VHYzY2bEpHNmN5OE8zNVpq?= =?utf-8?B?Y1IrQWR5dVN3a09XZ0psdW81RmVIR01RVFFlOEZlSUNuaHRzOHRlaS9ITDFO?= =?utf-8?Q?4RD8=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eHNQbEowZEhYN0c3TWEzeURzajBIWGxkaklSY0dHM3k2akRvbzhlZkluaTBK?= =?utf-8?B?S0FBMUtNVzhwOVRERnNLbjRSR2pyeWwzL1pCZlV6c2FiWkVzTGZoNUJFSTdJ?= =?utf-8?B?d0ZTSmxlM1FkTjhxWGZnVUFwR1pmanpFSS9WNGN6RzV2MFdEaWtFWXZ0dkNY?= =?utf-8?B?ZW5ISGhyYmY5V2pnR2I2akhCYlBMSTloOUY2ZmJRdjVZakNKUk00R0Vacy9W?= =?utf-8?B?UTcxb1JZOW84VC85cXFKeG8zY2JnRm50TFJrYUZ4Nno4WGdUM0I1RFRXYkJW?= =?utf-8?B?UGFLcGR2ZEpUR1UrUGFZVVk3VXo5eWR0RU0zMVZGcytxUWxhZkFOMHVXdEpT?= =?utf-8?B?RElDcisxT3RPcXgzdGN3VFZ3Q2pFQWg0WENMa3pMZXAreFRHYTc3Nm0zb3Y5?= =?utf-8?B?NEF2R2NKMjRRYk1xTHRDVkhpN0drNS92VkNtT3lRVXdsaENRZ0xSZXU5Sll0?= =?utf-8?B?eHk5dExOOFlMMlgvZmVSTkVQYkl2SmI2dGZHM3BsQnlxcFY2UDNBbXdsd0lQ?= =?utf-8?B?TXFnNWk4NzgyM1hkTTdYaXo3U2lHUm1RWWxCVlBCRWpDenNtT1NPQzRjUzZw?= =?utf-8?B?cEZwNXFFRGwxYmdBTXpvRDNrZHRnY24zOTdLVVRpOFpJWW9POSt5WHpiaXcv?= =?utf-8?B?TW5iallYcHkvRXloRWx4WXdBaytEREo5K3g5K05hbC9ROGJER1Nwb2FLVzhE?= =?utf-8?B?Y21QRGJITVZjV1dJNDFxUVJ4c3pqVWNCWVg1eUVBQ3NWVU10WkUzRjRxMm1U?= =?utf-8?B?bDhNUU9zUlgwUHYzRk04VDJoSjQxNFFPY1F2TC8xM3kvTGZpZFAwWEc3YU01?= =?utf-8?B?RTVzZDhLQUFReHIxVEhGRnZEQ2xYOC8yOHNEcHZYdTNmVUhiNHV3L0RGUE1w?= =?utf-8?B?QStFb2ZLUnkyMk8wSlEwWkFvL1FBb2hLYzl6Z1ZHcGlJMlovcnZPWUFoUm14?= =?utf-8?B?VHZ6R0h4RXA0RzFZN0dJRjFhNGx6ZjUwM0pyWXllSUVraStmV3FpYktDeUow?= =?utf-8?B?S2hRT3FKakpveDdETWVaOTZtNkI1SWp2SVVHUmJGdm5xZDNmRS9ZME9mMWJj?= =?utf-8?B?Qnd3aTh6WkwrMDliUDZ6UkdkRXNrTTh3ZTJGUzlBTENoVnRxMlE0eHhsVWRM?= =?utf-8?B?VjNMQmh2YkhKaGsrVzQzWmxOWkVaTng5MWFsSnMreG8rbnF3dG1rd1daWW03?= =?utf-8?B?bjFYcUp5cWVFSWtaSm9yNElhR0MvbStDa254Y2RycmdvRjRkNzRzQUlhWGxP?= =?utf-8?B?SHd6UlNmaEFpQmVGRXY0dFFpY2hBQng4bXBVcmRsRC8rc3VBQXZaYXA2bjJ1?= =?utf-8?B?UGp0YnNhaFZKSGZndzBOZ2o5b2NFRmoxS0ZnekFQQkNaQ2haSGdNVno3TmtW?= =?utf-8?B?WHgrczhBQjYwVGlzaUUyS1BEaHcyeW0zRmhEOWRnZGRucWVZMzFJWGVCN1Jn?= =?utf-8?B?Y2dTaysxWkVOTE90TUI5MlFQNXlGOVJzcjZuUitwMzc3TVNGejB1SGN0Mi9F?= =?utf-8?B?QlJkUy9YNWdNY2xJU1BFU2wxTm45VXFxazlPVnl1M0wvZmlEdE9vS1ZoaUND?= =?utf-8?B?ZEFIZmwvait5UndLRHg3eTNJc1pkTW0xZ3FxcGFYVjlIQ3VEOUVDM1AyY1Ju?= =?utf-8?B?dmN6Rk5tcGh6M0h1N1g5SFowa1VaeExwSnpYQVVUNTVidW01WGtHZHRPWVF0?= =?utf-8?B?OTZCSjNlYzVic3JmaEdTb2x5Z0VVekQ4ZFQ4WkI0U2g1OXhqYXBxM3A5OWRr?= =?utf-8?B?QlNoeEMyMEVGWmxSa29CSlF2TlNDT3BnclpZekQ5b3FsYjJQRlhLNWZFRDBq?= =?utf-8?B?RlVFamMycmFzUE1XUDV5QThBNTFaaE5MK2NKSUdFVHBXb0lhZDkwcEcyZklH?= =?utf-8?B?bTJOMklPTnF3TE5hb2tObDEvQXphem1ZUVZkeDV3WXFjUUhwMTBHaHQ5ZGFB?= =?utf-8?B?N2NLSVM1TCtKU3pHaFNHUkZPUEh4ck8zK3V3MkZoK2R6OU8zT29LaHpwdElF?= =?utf-8?B?RGplYnlSMmJuWXYxeUt6ODlaUkZ0ajYxeCtsSEc5OU1OTU1BTjU0QmlDQkpp?= =?utf-8?B?cXFqcmpVMS9EZ1owQ3AzYWNmUW9USDVNKysyb2VKR01pWUt5Q1QvOTlkUFRS?= =?utf-8?B?U05HMnAwRUluaUgvaWpLMkZTTDZQTC9XMVpRcDh3Rm1DbGNFOTgxKzYxeVNs?= =?utf-8?B?MGNsTVdsYzhhenpOWTFGelcwVFlLd1FHOUVFemQ5TWpJN3BWVklIU1Bxa0dz?= =?utf-8?B?S0lYU0lpOXFCTFhGQkFLRm1CT0s2S2VxSFg1TXpidWRQaXp6NmpHZkdxNWxn?= =?utf-8?B?NzROb1A4a3J6dGhpdjJnQUVZcnhsZUtBaUNQMG9rckl4N1VqOFpmQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: efec6832-70ca-40a2-c724-08de545c2ded X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2026 17:33:21.8494 (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: vyNxIb5vYl4f9Tr1sN5tP2jlcV710fJTio1MKjkW1t8Ee2eTFDe0O0wg/sfLYaiGytwNhK4YUyRggMebNIJKyQ+E7XeMJg+QuFY64IorjoA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS2PR03MB8158 On 15/01/2026 4:32 pm, Teddy Astie wrote: > Le 15/01/2026 à 16:50, Andrew Cooper a écrit : >> On 15/01/2026 3:17 pm, Julian Vetter wrote: >>> +{ >>> + uint64_t misc_enable; >>> + uint32_t eax, ebx, ecx, edx; >>> + >>> + if ( !boot_cpu_has(X86_FEATURE_NX) ) >>> + { >>> + /* Intel: try to unhide NX by clearing XD_DISABLE */ >>> + cpuid(0, &eax, &ebx, &ecx, &edx); >>> + if ( ebx == X86_VENDOR_INTEL_EBX && >>> + ecx == X86_VENDOR_INTEL_ECX && >>> + edx == X86_VENDOR_INTEL_EDX ) >>> + { >>> + rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable); >>> + if ( misc_enable & MSR_IA32_MISC_ENABLE_XD_DISABLE ) >>> + { >>> + misc_enable &= ~MSR_IA32_MISC_ENABLE_XD_DISABLE; >>> + wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable); >>> + >>> + /* Re-read CPUID after having cleared XD_DISABLE */ >>> + boot_cpu_data.x86_capability[FEATURESET_e1d] = cpuid_edx(0x80000001U); >>> + >>> + /* Adjust misc_enable_off for secondary startup and wakeup code */ >>> + bootsym(trampoline_misc_enable_off) |= MSR_IA32_MISC_ENABLE_XD_DISABLE; >>> + printk(KERN_INFO "re-enabled NX (Execute Disable) protection\n"); >>> + } >>> + } >>> + /* AMD: nothing we can do - NX must be enabled in BIOS */ >> The BIOS is only hiding the CPUID bit.  It's not blocking the use of NX. >> >> You want to do a wrmsr_safe() trying to set EFER.NXE, and if it >> succeeds, set the NX bit in MSR_K8_EXT_FEATURE_MASK to "unhide" it in >> regular CPUID.  This is a little more tricky to arrange because it needs >> doing on each CPU, not just the BSP. >> > I see this MSR in the BKDG (bit 20 is NX). Are these bits stable across > the AMD CPU generations ? Urgh.  Almost, but not quite, and I've apparently lost a patch. " x86/amd: Fixes for levelling setup" The K8 RevD and earlier have their masking MSRs at different indices. Perhaps instead of editing the masking MSRs, just setup_force_cpu_cap(), which confines the logic to the BSP. >>> + } >>> + >>> + /* Enable EFER.NXE only if NX is available */ >>> + if ( boot_cpu_has(X86_FEATURE_NX) ) >>> + { >>> + if ( !(read_efer() & EFER_NXE) ) >>> + write_efer(read_efer() | EFER_NXE); >>> + >>> + /* Adjust trampoline_efer for secondary startup and wakeup code */ >>> + bootsym(trampoline_efer) |= EFER_NXE; >>> + } >>> + >>> + if ( IS_ENABLED(CONFIG_REQUIRE_NX) && !boot_cpu_has(X86_FEATURE_NX) ) >>> + panic("This build of Xen requires NX support\n"); >>> +} >>> + >>> /* How much of the directmap is prebuilt at compile time. */ >>> #define PREBUILT_MAP_LIMIT (1 << L2_PAGETABLE_SHIFT) >>> >>> @@ -1159,6 +1203,8 @@ void asmlinkage __init noreturn __start_xen(void) >>> rdmsrl(MSR_EFER, this_cpu(efer)); >>> asm volatile ( "mov %%cr4,%0" : "=r" (info->cr4) ); >>> >>> + nx_init(); >>> + >>> /* Enable NMIs. Our loader (e.g. Tboot) may have left them disabled. */ >>> enable_nmis(); >>> >> This is too early, as can be seen by the need to make a cpuid() call >> rather than using boot_cpu_data. >> >> The cleanup I wanted to do was to create/rework early_cpu_init() to get >> things in a better order, so the panic() could go at the end here.  The >> current split we've got of early/regular CPU init was inherited from >> Linux and can be collapsed substantially. >> >> The intel "unlocking" wants to move back into early_init_intel(), along >> with intel_unlock_cpuid_leaves().  (This is where it used to live before >> REQUIRE_NX was added). >> >> The AMD side probe wants to live in early_amd_init()  (not that there is >> one right now), but the re-enabling of the NX bit in CPUID needs to also >> be in amd_init() so it gets applied to APs too. >> >> Does this make sense? > Sounds good to me, I suppose there is no use of NX before this ? NX predates 64bit on AMD CPUs. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Jan 15 19:45:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 19:45:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205781.1519787 (Exim 4.92) (envelope-from ) id 1vgTHh-0001KJ-NQ; Thu, 15 Jan 2026 19:45:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205781.1519787; Thu, 15 Jan 2026 19:45: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 1vgTHh-0001KC-KX; Thu, 15 Jan 2026 19:45:33 +0000 Received: by outflank-mailman (input) for mailman id 1205781; Thu, 15 Jan 2026 19:45: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 1vgTHg-0001K6-9x for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 19:45:32 +0000 Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [2607:f8b0:4864:20::f33]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bcf1e426-f24a-11f0-9ccf-f158ae23cfc8; Thu, 15 Jan 2026 20:45:26 +0100 (CET) Received: by mail-qv1-xf33.google.com with SMTP id 6a1803df08f44-8907ec50855so17536656d6.3 for ; Thu, 15 Jan 2026 11:45:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bcf1e426-f24a-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oasis-open-org.20230601.gappssmtp.com; s=20230601; t=1768506325; x=1769111125; 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=BVuRcIp9C9aDs7YujmRCIsJWyiCOSqmqC7FZNs5wMUU=; b=zfsED9WeRCYkwrAr87Pz4EnCp0Z9CCj8hUABpGa0XNgAz1pK9sedpurFOn2ookGiSS D26++vyI7sqUoxUSSgPGZ35I+aGKK89dLRPnI6a4rCAajASRMM40wUEJZOdT9H1tiVDY 6vZqOId1TZsTQMZMu80OPzIXvftRIW2/m4Wk5KbT5FylyDqQeuUKrOPQjhk8uE4zOpwJ eCKGvis5KZA0Cyvv3s3CSUCJaHglR49qEVOhmPkt614CvMH3OLEFA9RKKNU99koeBXkr FaxmcbSuT4ZGep++MPhi44v3txy+B3DqH4E41YhLHcBMtDTNyHpwch21jqDp52QqQvma okWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768506325; x=1769111125; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=BVuRcIp9C9aDs7YujmRCIsJWyiCOSqmqC7FZNs5wMUU=; b=aQhquKNThdJpcQoiyvhKrZJIl/LhzTP5+8JvSpEo8JSTo7tnCZHMuPOEWizS2yxV5Y FW0CdrSp0l1IYyNN4mMVBikQjoUW5NinC2hxwUFKHPmuQLhLsXWOhg6bnk3NkSiFd9Hp 0KCzp10+cJQwVZusAY9Qjbg/1pjTC2VrX9/bF17diRQaqQJxQScTx2N7li/D7CXkgd+V DIxTtjHLXBGFgYhFk9bJ9xKEyla5TVTfnF5SHyOz9OvmTC5uBfhvvEGRM49ltcTfU2OG 9eKRE1vWYJSrKr/7pImNb1lW+CEVDbtOd80oEu06OIFYyU6U2pt2gWQNa0VB21XXz4eo anmg== X-Gm-Message-State: AOJu0Ywp80DcEQjloisKfeKM3G6jtfvz1YFCPbdD/2E8bLKmOTBGXZnB PxJzLY56iN85AflFRrrGwUXqBOYev+ju5uy+KsrjDMCYEV8CfFfzDmlp5lpgSWQiFtCZ621FUWq o2eVovjyjBpluga69mE+mGI8+yrRxfuci+rkEpIXNFUxvZLcdgfqSyzo= X-Gm-Gg: AY/fxX48aa5ccoYmA1lU64fqolQL03LrUPY0BTlHx3wEfJVBFLDVRPgPCqPSPCoacEA uww5Buvy9i3rrWXU125VV4tHo1njgFzjMzAUEFGCnBD/iiiL7jr/ADZXNhyTheiKj/Y6YI/QMUb nrxicoRh5DCxIoktUHhmQw7GYqOdy4HfGEf+cWKTXPHrWgfzrroLNA1gMC8ISV99h2XFE3AJ0o4 7Zz7aTtpuxIbAoeEt93+cngltl+Ej/yfeS1t8DjPINeW0lAZvN3EppyvMGEU53gdaaDXarmhrhZ Far0djH9kaJotNGjVGnlGaP8y2d9A6KPuatCdahIJ/NFtF8KejrS0P+iJgPq X-Received: by 2002:ad4:5cc1:0:b0:888:7f91:e276 with SMTP id 6a1803df08f44-8942e42cc8fmr7330426d6.30.1768506325306; Thu, 15 Jan 2026 11:45:25 -0800 (PST) MIME-Version: 1.0 From: Kelly Cullinane Date: Thu, 15 Jan 2026 14:44:49 -0500 X-Gm-Features: AZwV_Qhv46EC-3juuarlSq3uhNN5xVVUoigaoPryNNEIJSl3WMf_ROS7L5svrwM Message-ID: Subject: Invitation to comment on VIRTIO v1.4 CSD01 To: xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OASIS members and other interested parties, OASIS and the VIRTIO TC are pleased to announce that VIRTIO v1.4 CSD01 is now available for public review and comment. VIRTIO TC aims to enhance the performance of virtual devices by standardizing key features of the VIRTIO (Virtual I/O) Device Specification. Virtual I/O Device (VIRTIO) Version 1.4 Committee Specification Draft 01 / Public Review Draft 01 09 December 2025 TEX: https://docs.oasis-open.org/virtio/virtio/v1.4/csprd01/virtio-v1.4-csp= rd01.html (Authoritative) HTML: https://docs.oasis-open.org/virtio/virtio/v1.4/csprd01/virtio-v1.4-cs= prd01.html PDF: https://docs.oasis-open.org/virtio/virtio/v1.4/csprd01/virtio-v1.4-csp= rd01.pdf The ZIP containing the complete files of this release is found in the direc= tory: https://docs.oasis-open.org/virtio/virtio/v1.4/csprd01/virtio-v1.4-csprd01.= zip How to Provide Feedback OASIS and the VIRTIO TC value your feedback. We solicit input from developers, users and others, whether OASIS members or not, for the sake of improving the interoperability and quality of its technical work. The public review is now open and ends Friday, February 13 2026 at 23:59 UT= C. Comments may be submitted to the project=E2=80=99s comment mailing list at virtio-comment@lists.linux.dev. You can subscribe to the list by sending an email to virtio-comment+subscribe@lists.linux.dev. All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. In connection with this public review, we call your attention to the OASIS IPR Policy applicable especially to the work of this technical committee. All members of the TC should be familiar with this document, which may create obligations regarding the disclosure and availability of a member's patent, copyright, trademark and license rights that read on an approved OASIS specification. OASIS invites any persons who know of any such claims to disclose these if they may be essential to the implementation of the above specification, so that notice of them may be posted to the notice page for this TC's work. Additional information about the specification and the VIRTIO TC can be found at the TC=E2=80=99s public homepage. From xen-devel-bounces@lists.xenproject.org Thu Jan 15 23:09:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 23:09:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205932.1519798 (Exim 4.92) (envelope-from ) id 1vgWSk-0007du-Gq; Thu, 15 Jan 2026 23:09:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205932.1519798; Thu, 15 Jan 2026 23:09:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgWSk-0007dn-CF; Thu, 15 Jan 2026 23:09:10 +0000 Received: by outflank-mailman (input) for mailman id 1205932; Thu, 15 Jan 2026 23:09: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 1vgWSj-0007dh-Je for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 23:09:09 +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 2e68d2c6-f267-11f0-9ccf-f158ae23cfc8; Fri, 16 Jan 2026 00:09:03 +0100 (CET) Received: by mx.zohomail.com with SMTPS id 1768518536669160.44063775779557; Thu, 15 Jan 2026 15:08:56 -0800 (PST) Received: by mail-oi1-f177.google.com with SMTP id 5614622812f47-45c8e85deffso441581b6e.1 for ; Thu, 15 Jan 2026 15:08:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2e68d2c6-f267-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; t=1768518539; cv=none; d=zohomail.com; s=zohoarc; b=X3+Ukw+c+X0YgvNgW8qAkvfr9mJ8Ad+KmjOHC7NN7d+fo7JepIavUbrbxCFCiUHvZHpt648Gm/s5OLHvJtp/CWWz4AYVAhqqbSgptkwfOvSvi/JNgqxM6fFgnM7XDwI7WLMuK1ahT0EsuEorporRVfd7Ke0lAvc9+tst7bqoNEY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1768518539; 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=bDJVVA3E22bQ/IxWhkb2Y4579buw3WQ1C3StIr1NqAQ=; b=IoLEXfZEEXm5mWaxuQIW8NRG4OvyyYEsG9PSWskxV9yoDyuD6ku1s7oReLT0H3b79srRWCxfPg7J7PVF8RRomFFw0678YjsRThl1SNW8Hp+AtgVBvffcI6E8Dk3QWcaYMG5H4ucw8rGom4txrJBcYRGm7KWFjnLjFAkJ7AaWeV0= 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=1768518539; 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=bDJVVA3E22bQ/IxWhkb2Y4579buw3WQ1C3StIr1NqAQ=; b=eCqIje+3lvOAU81V8WPNMglp5HDt5JyzXuNJNngZ9uJ9xUjGzoSofws4xhGAVPAJ Qvmja/BR3BKvers1St0GePM2VjSNnlNBLwZ1uI+w5jUns9m/UFGNUbmpRuNpQyRj5cl BAQYBEWTxGhgYpnch3JpI3wzSf1qrRKzAtenNcXA= X-Gm-Message-State: AOJu0YyY2JJGLiBOEQn50KTkvGolEwlrvj3brAPe5BlJxNGP0crC1ldy vqyv3uGbLXBp+5J5neFh1pQsj4e1a5ffvcxjyEsduTGe8037CqtVYM7B6i+AGKr04NVRnBjsurv pR7W3qjRxUhddDYGjNdedLmg7q5PZFIs= X-Received: by 2002:a05:6808:344c:b0:450:c7b5:23d0 with SMTP id 5614622812f47-45c9d8a85f4mr406673b6e.49.1768518535318; Thu, 15 Jan 2026 15:08:55 -0800 (PST) MIME-Version: 1.0 References: <20260115092841.2651224-1-Penny.Zheng@amd.com> <20260115092841.2651224-2-Penny.Zheng@amd.com> In-Reply-To: <20260115092841.2651224-2-Penny.Zheng@amd.com> From: Tamas K Lengyel Date: Thu, 15 Jan 2026 18:07:00 -0500 X-Gmail-Original-Message-ID: X-Gm-Features: AZwV_QgAK-Tq1TmBE3lhHnVK_Fy5hdvXUja-jL0JwNzb4POF3gcp1Dgou6AgwUQ Message-ID: Subject: Re: [PATCH v4 1/6] xen/x86: move declaration from mem_access.h to altp2m.h To: Penny Zheng Cc: xen-devel@lists.xenproject.org, jason.andryuk@amd.com, ray.huang@amd.com, Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alexandru Isaila , Petre Pircalabu Content-Type: multipart/alternative; boundary="000000000000139fb30648754f3f" --000000000000139fb30648754f3f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 15, 2026 at 4:29=E2=80=AFAM Penny Zheng w= rote: > Memory access and ALTP2M are two seperate features, and each could be > controlled via VM_EVENT or ALTP2M. In order to avoid implicit declaration > when ALTP2M=3Dy and VM_EVENT=3Dn on compiling hvm.o/altp2m.o, we move > declaration > of the following functions from to : > - p2m_set_suppress_ve > - p2m_set_suppress_ve_multi > - p2m_get_suppress_ve > Potential error on altp2m.c also breaks Misra Rule 8.4. > > Signed-off-by: Penny Zheng > Reviewed-by: Jan Beulich > Reviewed-by: Jason Andryuk Acked-by: Tamas K Lengyel --000000000000139fb30648754f3f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 15,= 2026 at 4:29=E2=80=AFAM Penny Zheng <Penny.Zheng@amd.com> wrote:
Memory access and ALTP2M are two seperate features,= and each could be
controlled via VM_EVENT or ALTP2M. In order to avoid implicit declaration when ALTP2M=3Dy and VM_EVENT=3Dn on compiling hvm.o/altp2m.o, we move decla= ration
of the following functions from <asm/mem_access.h> to <asm/altp2m.= h>:
- p2m_set_suppress_ve
- p2m_set_suppress_ve_multi
- p2m_get_suppress_ve
Potential error on altp2m.c also breaks Misra Rule 8.4.

Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>

Acked-by: Tamas K Lengyel <tama= s@tklengyel.com>=C2=A0
--000000000000139fb30648754f3f-- From xen-devel-bounces@lists.xenproject.org Thu Jan 15 23:10:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 23:10:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205940.1519807 (Exim 4.92) (envelope-from ) id 1vgWTo-0000dL-OG; Thu, 15 Jan 2026 23:10:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205940.1519807; Thu, 15 Jan 2026 23: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 1vgWTo-0000dE-LG; Thu, 15 Jan 2026 23:10:16 +0000 Received: by outflank-mailman (input) for mailman id 1205940; Thu, 15 Jan 2026 23:10: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 1vgWTn-000844-HF for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 23:10:15 +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 58395493-f267-11f0-9ccf-f158ae23cfc8; Fri, 16 Jan 2026 00:10:13 +0100 (CET) Received: by mx.zohomail.com with SMTPS id 1768518609448327.96669906004786; Thu, 15 Jan 2026 15:10:09 -0800 (PST) Received: by mail-oo1-f50.google.com with SMTP id 006d021491bc7-66106a2f8d0so957647eaf.2 for ; Thu, 15 Jan 2026 15:10:08 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 58395493-f267-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; t=1768518611; cv=none; d=zohomail.com; s=zohoarc; b=n869em04m5spi5M/gM3TTvQJycSh60+EuBK/MvRkENyilLSTTQFtwO5IVb0Y3QYx4V+Dc3XmzyFpNALowau1F0oYTgPngt5SxSbQqlgbSMpFBvIoul47BGnITY67qoktEOeN1eqzOnfzetxTdFEuYrHlh/wC+Ctxono40eMFcSg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1768518611; 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=siaeCtKqcCym2YtgRvOP6EB2cSKk/5lXJOvehqUu0Qw=; b=eBuiZwtYYRI69M3hIBh3AKM6p0r67aEQFdvVvunDmPPXmqX6XUg5mznYjMJ52e36rlegEv80COPuo93+4LQINmC/f4ZVXv9j1JFJhBoy1Yp9jFDHE/mGbV2kY5cTGQOVKqwwFAm6eLSTAFQizZy1DVYOrpi5ClHQzG9rkST9MrY= 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=1768518611; 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=siaeCtKqcCym2YtgRvOP6EB2cSKk/5lXJOvehqUu0Qw=; b=Fd/Am4RfB03sudAniORexM2gK2SGMggMRnHtJ3kKAqhRaUJt4PWP5csU1D1nB4nY 1cEGSFu1d6p2XW8zub0mB4QCLnvh9eXFYdF4QZw/skBO3Tuod9sWRgGVEpUmfwOickb zeeSw4Nkwv2gSLG79O8q37FW/h8m3bV6pMIgck3A= X-Forwarded-Encrypted: i=1; AJvYcCWtyEqv7y+yvKdKnPh6DALSDbFIaXESwleZfw+faLnM/bMO1L1yFuDhHHGqduR6oAk0x5EPItIn56c=@lists.xenproject.org X-Gm-Message-State: AOJu0YyGaamVSEs8Sj4NLG3nNl9jQfOEZYQdPG76IktIRjmky1jy3dfP MPKOAt1hqfi3pNukCggz3UeiXKMWqflAN4aKQt17mL1Yl6Tujdd5P3ZHaaaN0Pe6f3DgsEQ2pnn h9dnyuzEzTzCSdcbUI45XXJ8JbwHYCSc= X-Received: by 2002:a05:6820:160f:b0:65f:6cc6:5ffd with SMTP id 006d021491bc7-66117990684mr618756eaf.33.1768518608084; Thu, 15 Jan 2026 15:10:08 -0800 (PST) MIME-Version: 1.0 References: <20260115092841.2651224-1-Penny.Zheng@amd.com> <20260115092841.2651224-5-Penny.Zheng@amd.com> In-Reply-To: From: Tamas K Lengyel Date: Thu, 15 Jan 2026 18:09:00 -0500 X-Gmail-Original-Message-ID: X-Gm-Features: AZwV_QhTc1KOPhSYAhbdzoWv41YMqEsmvQYVT2UNiYCPQWhrKvTog2dxIwuufvk Message-ID: Subject: Re: [PATCH v4 4/6] xen/p2m: move xenmem_access_to_p2m_access() to common p2m.c To: Jason Andryuk Cc: Penny Zheng , xen-devel@lists.xenproject.org, ray.huang@amd.com, Alexandru Isaila , Petre Pircalabu , Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Content-Type: multipart/alternative; boundary="00000000000069e85e06487553bd" --00000000000069e85e06487553bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 15, 2026 at 10:21=E2=80=AFAM Jason Andryuk wrote: > On 2026-01-15 04:28, Penny Zheng wrote: > > Memory access and ALTP2M are two seperate features, while both dependin= g > on > > helper xenmem_access_to_p2m_access(). So it betters lives in common > p2m.c, > > other than mem_access.c which will be compiled out when VM_EVENT=3Dn && > ALTP2M=3Dy. > > Guard xenmem_access_to_p2m_access() with VM_EVENT || ALTP2M, otherwise = it > > will become unreachable when both VM_EVENT=3Dn and ALTP2M=3Dn, and henc= e > > violating Misra rule 2.1 > > We also need to move declaration from mem_access.h to p2m-common.h > > An extra blank line is inserted after each case-block to correct coding > > style at the same time. > > > > Signed-off-by: Penny Zheng > > Acked-by: Jan Beulich > > Reviewed-by: Jason Andryuk > Acked-by: Tamas K Lengyel --00000000000069e85e06487553bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 15, 2026= at 10:21=E2=80=AFAM Jason Andryuk <jason.andryuk@amd.com> wrote:
On 2026-01-15 04:28, Penny Zhen= g wrote:
> Memory access and ALTP2M are two seperate features, while both dependi= ng on
> helper xenmem_access_to_p2m_access(). So it betters lives in common p2= m.c,
> other than mem_access.c which will be compiled out when VM_EVENT=3Dn &= amp;& ALTP2M=3Dy.
> Guard xenmem_access_to_p2m_access() with VM_EVENT || ALTP2M, otherwise= it
> will become unreachable when both VM_EVENT=3Dn and ALTP2M=3Dn, and hen= ce
> violating Misra rule 2.1
> We also need to move declaration from mem_access.h to p2m-common.h
> An extra blank line is inserted after each case-block to correct codin= g
> style at the same time.
>
> Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>

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

Acked-by: Tamas K Lengyel <tamas@tklengyel.com>=C2=A0
--00000000000069e85e06487553bd-- From xen-devel-bounces@lists.xenproject.org Thu Jan 15 23:13:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 15 Jan 2026 23:13:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1205950.1519816 (Exim 4.92) (envelope-from ) id 1vgWWU-00019p-4A; Thu, 15 Jan 2026 23:13:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1205950.1519816; Thu, 15 Jan 2026 23: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 1vgWWU-00019i-1b; Thu, 15 Jan 2026 23:13:02 +0000 Received: by outflank-mailman (input) for mailman id 1205950; Thu, 15 Jan 2026 23:13: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 1vgWWS-00019Y-VH for xen-devel@lists.xenproject.org; Thu, 15 Jan 2026 23:13: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 bb218ce3-f267-11f0-b15e-2bf370ae4941; Fri, 16 Jan 2026 00:12:59 +0100 (CET) Received: by mx.zohomail.com with SMTPS id 1768518776463307.9111597064151; Thu, 15 Jan 2026 15:12:56 -0800 (PST) Received: by mail-oo1-f41.google.com with SMTP id 006d021491bc7-65e943048afso551573eaf.0 for ; Thu, 15 Jan 2026 15:12:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bb218ce3-f267-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; t=1768518777; cv=none; d=zohomail.com; s=zohoarc; b=eKRZUhoOJCVNAT5+UKI5k+GS9VstnVhaxnitJpAI+El0e8T4IhozBBcgBa7qXlX6/eamQoTqgc0tXPgUZrF9iPBA5cOoS3EqWnflyhiS3aMrqgVHtPSZeCaqK4I1xOc1sosaryHvk2CYdy1EFsje2S9Cxylv5+dCXpVYq+5Ij94= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1768518777; 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=0l3q3A8gUey+LqCIoBCGD6oDpOqHDGxXljILJBuxYyg=; b=nKB0nVg1qcpHmXSrNaGTEX9X400FWCwCKCzzKhN8V76x/29ki/wInPKXb3qw57ngs5H8GXQM0Py+0314V+NZhJOKI5DQpNwe+cFmmRoReVVPLap3jxKCXDfxDbRmI8ItLSI9pVk+FBNTw+zZXLirN5ulgPLBTuvszyP3vOhXlMY= 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=1768518777; 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=0l3q3A8gUey+LqCIoBCGD6oDpOqHDGxXljILJBuxYyg=; b=dCiYKTUC0mjkw8FhZaj9o1RZMq/Pq2LJ/TnLjuA+K0XB14r7Dic3ntjhQWDO71da 2lHluVNthdlOvki1ikPoj2cixRdqOfTKReBC7NX+RDZuuCWyFYc+1nYyICQhnlwOpAm ZToxsddIluHB4Stc4fAUO+vYmrctlzW+5bNSojNY= X-Gm-Message-State: AOJu0YxJWCF/ayDI24oG8UkHxBFOKaeRpwY/8kSWZcGvLAvv/x4YncbT xb9Q+vXnL5LCG6WPdUoqWziqjsuFDhHG+Djf4woJKyOHNCZYVRu1GKcmw7T1Nek4MQ2nlCS1n0d rjS3DMgmSTv4Fnjobc+mqPR2z6A/iwa4= X-Received: by 2002:a05:6820:1896:b0:65f:2baf:4ad with SMTP id 006d021491bc7-661188fb236mr373189eaf.30.1768518775291; Thu, 15 Jan 2026 15:12:55 -0800 (PST) MIME-Version: 1.0 References: <20260115092841.2651224-1-Penny.Zheng@amd.com> <20260115092841.2651224-7-Penny.Zheng@amd.com> In-Reply-To: <20260115092841.2651224-7-Penny.Zheng@amd.com> From: Tamas K Lengyel Date: Thu, 15 Jan 2026 18:11:00 -0500 X-Gmail-Original-Message-ID: X-Gm-Features: AZwV_Qi5Y4yS1ot7FV7Z3AgAM0GHcw4zW3O9rm-SfsAkiEQRkjVGaBBKp2ChL2M Message-ID: Subject: Re: [PATCH v4 6/6] xen/vm_event: consolidate CONFIG_VM_EVENT To: Penny Zheng Cc: xen-devel@lists.xenproject.org, jason.andryuk@amd.com, ray.huang@amd.com, Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , Alexandru Isaila , Petre Pircalabu Content-Type: multipart/alternative; boundary="0000000000006143bf0648755df0" --0000000000006143bf0648755df0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 15, 2026 at 4:29=E2=80=AFAM Penny Zheng w= rote: > File hvm/vm_event.c and x86/vm_event.c are the extend to vm_event handlin= g > routines, and its compilation shall be guarded by CONFIG_VM_EVENT too. > > Although CONFIG_VM_EVENT is right now forcibly enabled on x86 via > MEM_ACCESS_ALWAYS_ON, we could disable it through disabling > CONFIG_MGMT_HYPERCALLS later. So we remove MEM_ACCESS_ALWAYS_ON and > make VM_EVENT=3Dy on default only on x86 to retain the same. > > The following functions are developed on the basis of vm event framework, > or > only invoked by vm_event.c, so they all shall be wrapped with > CONFIG_VM_EVENT > (otherwise they will become unreachable and > violate Misra rule 2.1 when VM_EVENT=3Dn): > - hvm_toggle_singlestep > - hvm_fast_singlestep > - hvm_emulate_one_vm_event > - > hvmemul_write{,cmpxchg,rep_ins,rep_outs,rep_movs,rep_stos,read_io,write_i= o}_discard > And Function vm_event_check_ring() needs stub to pass compilation when > VM_EVENT=3Dn. > > Signed-off-by: Penny Zheng > Acked-by: Jan Beulich > Reviewed-by: Jason Andryuk > Acked-by: Tamas K Lengyel --0000000000006143bf0648755df0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 15,= 2026 at 4:29=E2=80=AFAM Penny Zheng <Penny.Zheng@amd.com> wrote:
File hvm/vm_event.c and x86/vm_event.c are the exte= nd to vm_event handling
routines, and its compilation shall be guarded by CONFIG_VM_EVENT too.

Although CONFIG_VM_EVENT is right now forcibly enabled on x86 via
MEM_ACCESS_ALWAYS_ON, we could disable it through disabling
CONFIG_MGMT_HYPERCALLS later. So we remove MEM_ACCESS_ALWAYS_ON and
make VM_EVENT=3Dy on default only on x86 to retain the same.

The following functions are developed on the basis of vm event framework, o= r
only invoked by vm_event.c, so they all shall be wrapped with CONFIG_VM_EVE= NT
(otherwise they will become unreachable and
violate Misra rule 2.1 when VM_EVENT=3Dn):
- hvm_toggle_singlestep
- hvm_fast_singlestep
- hvm_emulate_one_vm_event
=C2=A0 =C2=A0 - hvmemul_write{,cmpxchg,rep_ins,rep_outs,rep_movs,rep_stos,r= ead_io,write_io}_discard
And Function vm_event_check_ring() needs stub to pass compilation when
VM_EVENT=3Dn.

Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>

Acked-by: Tamas K Lengyel <tamas= @tklengyel.com>
--0000000000006143bf0648755df0-- From xen-devel-bounces@lists.xenproject.org Fri Jan 16 03:09:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 03:09:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206069.1519826 (Exim 4.92) (envelope-from ) id 1vgaD3-00031V-Vo; Fri, 16 Jan 2026 03:09:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206069.1519826; Fri, 16 Jan 2026 03: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 1vgaD3-00031O-Sa; Fri, 16 Jan 2026 03:09:13 +0000 Received: by outflank-mailman (input) for mailman id 1206069; Fri, 16 Jan 2026 03:09:12 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgaD2-00031I-A8 for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 03:09:12 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vgaD0-006BCR-16; Fri, 16 Jan 2026 03:09:10 +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 1vgaCz-005Mm8-2F; Fri, 16 Jan 2026 03:09: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:Message-ID:Date: Subject:Cc:To:From; bh=SbEWkPeAnSslQvi8YgwfbD8xqGWKRn1zKia3IHWmxB0=; b=WbvKjR Cl7ShQp+RVf+wi4jj0fQzYtTPRZMeMWLUwd1+xDrbaB9D0I7Ua6kjFqQpKTBEF1FPBSsCiKHBA5Cw D60HNcFVZfMympJqxg/XCoI+TYBjTB8PkpY2/ySGTQVferByqK1XZDl1uSeZitQPuaoHqpwphUCYF gjnzKf3TtnU=; 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] INSTALL: remove unsupported XEN_CONFIG_EXPERT from documentation Date: Thu, 15 Jan 2026 19:08:43 -0800 Message-ID: <20260116030842.415583-2-dmukhin@ford.com> X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Denis Mukhin Amends: 37339ba9ef46 ("automation: Remove XEN_CONFIG_EXPERT leftovers") Signed-off-by: Denis Mukhin --- Changes since v1: - rephrased a note about EXPERT features - Link to v1: https://lore.kernel.org/xen-devel/20260108141641.506534-2-dmukhin@ford.com/ --- INSTALL | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/INSTALL b/INSTALL index c2e756bf4b2b..919e1c04891b 100644 --- a/INSTALL +++ b/INSTALL @@ -33,11 +33,11 @@ small subset of the options. Attempts to change other options will be silently overridden. The only way to find which configuration options are available is to run `make menuconfig' or the like. -You can counter-override this behaviour by setting XEN_CONFIG_EXPERT=y -in your environment. However, doing this is not supported and the -resulting configurations do not receive security support. If you set -this variable there is nothing stopping you setting dangerously -experimental combinations of features - not even any warnings. +This behavior can be overridden by enabling "Configure EXPERT features" +in Kconfig (CONFIG_EXPERT). However, resulting configurations do not +receive security support. In addition, CONFIG_EXPERT permits the +selection of experimental and potentially unsafe feature combinations +without generating configuration warnings. Options recognized by configure =============================== -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Jan 16 04:35:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 04:35:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206119.1519846 (Exim 4.92) (envelope-from ) id 1vgbYC-0005Rc-Ba; Fri, 16 Jan 2026 04:35:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206119.1519846; Fri, 16 Jan 2026 04:35:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgbYC-0005RV-8p; Fri, 16 Jan 2026 04:35:08 +0000 Received: by outflank-mailman (input) for mailman id 1206119; Fri, 16 Jan 2026 04:35:06 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgbYA-0005E6-Pc for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 04:35:06 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vgbYA-006Cye-1i; Fri, 16 Jan 2026 04:35: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 1vgbY9-005RC1-2y; Fri, 16 Jan 2026 04:35: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=kh21T0kKV5XodX2DHwO7OSuhQ97nSlNN542UIGS2Vhw=; b=Afvnp0XjZ2mG+CkbS9x0iACoZK PrjKPb+/yXNdGNStzyPTn2w4WngrnRlVenv07LA9PZnmeYOC1UHdWiHHO4xPuAPrY1oMX8AaXOm4K TPiU4fBJWOH/hm847E7n+bq+Sa70rAyccAXyYkF0KANFxIDaLckjrfPXoV4QhEkDd6Eo=; 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 v1 1/4] scripts/config: import Kconfig manipulation tool from Linux Date: Thu, 15 Jan 2026 20:34:55 -0800 Message-ID: <20260116043458.730728-2-dmukhin@ford.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260116043458.730728-1-dmukhin@ford.com> References: <20260116043458.730728-1-dmukhin@ford.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Denis Mukhin Manipulating Kconfig settings is often required when preparing a custom Xen build using an external build system (e.g., a Yocto-based workflow). Import the Kconfig manipulation tool from the Linux kernel (commit 0f61b1860cc3, Linux v6.19-rc5) to support this use case. Signed-off-by: Denis Mukhin --- xen/scripts/config | 236 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 236 insertions(+) create mode 100755 xen/scripts/config diff --git a/xen/scripts/config b/xen/scripts/config new file mode 100755 index 000000000000..ea475c07de28 --- /dev/null +++ b/xen/scripts/config @@ -0,0 +1,236 @@ +#!/usr/bin/env bash +# SPDX-License-Identifier: GPL-2.0 +# Manipulate options in a .config file from the command line + +myname=${0##*/} + +# If no prefix forced, use the default CONFIG_ +CONFIG_="${CONFIG_-CONFIG_}" + +# We use an uncommon delimiter for sed substitutions +SED_DELIM=$(echo -en "\001") + +usage() { + cat >&2 <"$tmpfile" + # replace original file with the edited one + mv "$tmpfile" "$infile" +} + +txt_subst() { + local before="$1" + local after="$2" + local infile="$3" + local tmpfile="$infile.swp" + + sed -e "s$SED_DELIM$before$SED_DELIM$after$SED_DELIM" "$infile" >"$tmpfile" + # replace original file with the edited one + mv "$tmpfile" "$infile" +} + +txt_delete() { + local text="$1" + local infile="$2" + local tmpfile="$infile.swp" + + sed -e "/$text/d" "$infile" >"$tmpfile" + # replace original file with the edited one + mv "$tmpfile" "$infile" +} + +set_var() { + local name=$1 new=$2 before=$3 + + name_re="^($name=|# $name is not set)" + before_re="^($before=|# $before is not set)" + if test -n "$before" && grep -Eq "$before_re" "$FN"; then + txt_append "^$before=" "$new" "$FN" + txt_append "^# $before is not set" "$new" "$FN" + elif grep -Eq "$name_re" "$FN"; then + txt_subst "^$name=.*" "$new" "$FN" + txt_subst "^# $name is not set" "$new" "$FN" + else + echo "$new" >>"$FN" + fi +} + +undef_var() { + local name=$1 + + txt_delete "^$name=" "$FN" + txt_delete "^# $name is not set" "$FN" +} + +FN=.config +CMDS=() +while [[ $# -gt 0 ]]; do + if [ "$1" = "--file" ]; then + if [ "$2" = "" ]; then + usage + fi + FN="$2" + shift 2 + else + CMDS+=("$1") + shift + fi +done + +set -- "${CMDS[@]}" +if [ "$1" = "" ] ; then + usage +fi + +MUNGE_CASE=yes +while [ "$1" != "" ] ; do + CMD="$1" + shift + case "$CMD" in + --keep-case|-k) + MUNGE_CASE=no + continue + ;; + --refresh) + ;; + --*-after|-E|-D|-M) + checkarg "$1" + A=$ARG + checkarg "$2" + B=$ARG + shift 2 + ;; + -*) + checkarg "$1" + shift + ;; + esac + case "$CMD" in + --enable|-e) + set_var "${CONFIG_}$ARG" "${CONFIG_}$ARG=y" + ;; + + --disable|-d) + set_var "${CONFIG_}$ARG" "# ${CONFIG_}$ARG is not set" + ;; + + --module|-m) + set_var "${CONFIG_}$ARG" "${CONFIG_}$ARG=m" + ;; + + --set-str) + # sed swallows one level of escaping, so we need double-escaping + set_var "${CONFIG_}$ARG" "${CONFIG_}$ARG=\"${1//\"/\\\\\"}\"" + shift + ;; + + --set-val) + set_var "${CONFIG_}$ARG" "${CONFIG_}$ARG=$1" + shift + ;; + --undefine|-u) + undef_var "${CONFIG_}$ARG" + ;; + + --state|-s) + if grep -q "# ${CONFIG_}$ARG is not set" $FN ; then + echo n + else + V="$(grep "^${CONFIG_}$ARG=" $FN)" + if [ $? != 0 ] ; then + echo undef + else + V="${V/#${CONFIG_}$ARG=/}" + V="${V/#\"/}" + V="${V/%\"/}" + V="${V//\\\"/\"}" + echo "${V}" + fi + fi + ;; + + --enable-after|-E) + set_var "${CONFIG_}$B" "${CONFIG_}$B=y" "${CONFIG_}$A" + ;; + + --disable-after|-D) + set_var "${CONFIG_}$B" "# ${CONFIG_}$B is not set" "${CONFIG_}$A" + ;; + + --module-after|-M) + set_var "${CONFIG_}$B" "${CONFIG_}$B=m" "${CONFIG_}$A" + ;; + + --refresh) + yes "" | make oldconfig KCONFIG_CONFIG=$FN + ;; + + *) + echo "bad command: $CMD" >&2 + usage + ;; + esac +done -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Jan 16 04:35:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 04:35:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206118.1519836 (Exim 4.92) (envelope-from ) id 1vgbYB-0005EJ-4G; Fri, 16 Jan 2026 04:35:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206118.1519836; Fri, 16 Jan 2026 04:35:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgbYB-0005EC-1W; Fri, 16 Jan 2026 04:35:07 +0000 Received: by outflank-mailman (input) for mailman id 1206118; Fri, 16 Jan 2026 04:35:05 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgbY9-0005E0-NW for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 04:35:05 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vgbY9-006CyY-1Z; Fri, 16 Jan 2026 04:35: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 1vgbY8-005RBx-2j; Fri, 16 Jan 2026 04:35: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:Message-ID:Date: Subject:Cc:To:From; bh=g09Ig48jUKT3edah76oufAL+kURNVPKdk9sZlJC36mU=; b=WKQ3ic ENbdioXeYd1Oh74oCPROMz67JIEfOI6aadXFgK9I0Gx4/H/fNOOxsFBcPlrBR/3QgTT+rGRl7wBzF WHtYn9rJJIRLIpG1BWmgSmfTIbym5NXlhVnL1wQyq7z1XJS84lNEOWcQkhbTpCoeuvDbPUSAw9md6 yIVcaaQ867c=; 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 v1 0/4] introduce xen/scripts/config Date: Thu, 15 Jan 2026 20:34:54 -0800 Message-ID: <20260116043458.730728-1-dmukhin@ford.com> X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit There is currently no in-tree tool to manipulate Kconfig settings in a non-interactive way similar to the Linux scripts/config utility [1]. Such tooling is useful when building Xen via external build systems (e.g., Yocto) and can also simplify custom CI configuration. This series imports the Linux scripts/config helper and integrates it into an existing Xen automation script. Example of usage: ./xen/scripts/config --file xen/.config -y FOO -n BAR -y BAZ Patch 1 imports scripts/config from Linux (based on v6.19-rc5) [1]. Patch 2 drops the -m option, since Xen does not support modules. Patch 3 adds convenience flags -y (set to yes) and -n (set to no). Patch 4 performs minimal integration into existing Xen build system. [1] https://github.com/torvalds/linux/blob/master/scripts/config [2] https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2266369021 Denis Mukhin (4): scripts/config: import Kconfig manipulation tool from Linux scripts/config: drop modules support scripts/config: add -y|-n flags scripts/config: hook to automation build script automation/scripts/build | 2 +- xen/scripts/config | 225 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 226 insertions(+), 1 deletion(-) create mode 100755 xen/scripts/config -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Jan 16 04:35:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 04:35:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206120.1519853 (Exim 4.92) (envelope-from ) id 1vgbYC-0005Ue-Lc; Fri, 16 Jan 2026 04:35:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206120.1519853; Fri, 16 Jan 2026 04:35:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgbYC-0005Tk-FI; Fri, 16 Jan 2026 04:35:08 +0000 Received: by outflank-mailman (input) for mailman id 1206120; Fri, 16 Jan 2026 04:35:07 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgbYB-0005MO-JA for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 04:35:07 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vgbYB-006Cyn-1p; Fri, 16 Jan 2026 04:35: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 1vgbYA-005RC5-3D; Fri, 16 Jan 2026 04:35: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=vQ+i0Se3Q6gtbukAXmyZwLdyrtEvtzopHHyFl1Djo1M=; b=CrTbsrOnyAz9/uMEjxsjNsTQMx HjJgrENTOYUKVFIS5klb19G8jo1F/ReyqC/PSdocVSGqUR3a0UlLF1DwDPVIkpOUJLzrdgGykQP3h oDrKZYuaYsdON0scIrWVxhT4lGcR8wyox+UNAb/Ento25iQzchV0zIk3H41W/L86FOqY=; 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 v1 2/4] scripts/config: drop modules support Date: Thu, 15 Jan 2026 20:34:56 -0800 Message-ID: <20260116043458.730728-3-dmukhin@ford.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260116043458.730728-1-dmukhin@ford.com> References: <20260116043458.730728-1-dmukhin@ford.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Denis Mukhin Drop the --module (-m) and --module-after (-M) options, as Xen does not support loadable modules, so options are not applicable. Signed-off-by: Denis Mukhin --- xen/scripts/config | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/xen/scripts/config b/xen/scripts/config index ea475c07de28..1050812aae8d 100755 --- a/xen/scripts/config +++ b/xen/scripts/config @@ -18,7 +18,6 @@ $myname options command ... commands: --enable|-e option Enable option --disable|-d option Disable option - --module|-m option Turn option into a module --set-str option string Set option to "string" --set-val option value @@ -30,8 +29,6 @@ commands: Enable option directly after other option --disable-after|-D beforeopt option Disable option directly after other option - --module-after|-M beforeopt option - Turn option into module directly after other option --refresh Refresh the config using old settings commands can be repeated multiple times @@ -177,10 +174,6 @@ while [ "$1" != "" ] ; do set_var "${CONFIG_}$ARG" "# ${CONFIG_}$ARG is not set" ;; - --module|-m) - set_var "${CONFIG_}$ARG" "${CONFIG_}$ARG=m" - ;; - --set-str) # sed swallows one level of escaping, so we need double-escaping set_var "${CONFIG_}$ARG" "${CONFIG_}$ARG=\"${1//\"/\\\\\"}\"" @@ -220,10 +213,6 @@ while [ "$1" != "" ] ; do set_var "${CONFIG_}$B" "# ${CONFIG_}$B is not set" "${CONFIG_}$A" ;; - --module-after|-M) - set_var "${CONFIG_}$B" "${CONFIG_}$B=m" "${CONFIG_}$A" - ;; - --refresh) yes "" | make oldconfig KCONFIG_CONFIG=$FN ;; -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Jan 16 04:35:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 04:35:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206121.1519867 (Exim 4.92) (envelope-from ) id 1vgbYE-0005tO-QG; Fri, 16 Jan 2026 04:35:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206121.1519867; Fri, 16 Jan 2026 04:35:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgbYE-0005t6-M3; Fri, 16 Jan 2026 04:35:10 +0000 Received: by outflank-mailman (input) for mailman id 1206121; Fri, 16 Jan 2026 04:35:08 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgbYC-0005fx-Su for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 04:35:08 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vgbYC-006Czk-26; Fri, 16 Jan 2026 04:35: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 1vgbYC-005RCB-0I; Fri, 16 Jan 2026 04:35: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=sstj4f6s3p4JgN2+Qmv2+rlNpy+6d5aRHrcXL1c5i4w=; b=gZkV7QGbSdUXvIrOgJn1marDGW E6xzxYxtMwlyS/7RIlLydtCmd19wXuI9ZsT80vwrTr+irZVLHjUiSHbysVZ70VOi3C4QN2/gxrjvr JspWSY7fknF6rbRkNB0gRhEAmb4/l63qWZSpIVOnPjGoCDwhIiSnQYZJeZSn4u1Mu62A=; 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 v1 3/4] scripts/config: add -y|-n flags Date: Thu, 15 Jan 2026 20:34:57 -0800 Message-ID: <20260116043458.730728-4-dmukhin@ford.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260116043458.730728-1-dmukhin@ford.com> References: <20260116043458.730728-1-dmukhin@ford.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Denis Mukhin Add alias -y ("yes") to --enable and -n ("no") to --disable a Kconfig option for better scripting experience. Signed-off-by: Denis Mukhin --- xen/scripts/config | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/xen/scripts/config b/xen/scripts/config index 1050812aae8d..1ede964320cf 100755 --- a/xen/scripts/config +++ b/xen/scripts/config @@ -16,8 +16,8 @@ Manipulate options in a .config file from the command line. Usage: $myname options command ... commands: - --enable|-e option Enable option - --disable|-d option Disable option + --enable|-e|-y|--yes option Enable option + --disable|-d|-n|--no option Disable option --set-str option string Set option to "string" --set-val option value @@ -166,11 +166,11 @@ while [ "$1" != "" ] ; do ;; esac case "$CMD" in - --enable|-e) + --enable|-e|-y|--yes) set_var "${CONFIG_}$ARG" "${CONFIG_}$ARG=y" ;; - --disable|-d) + --disable|-d|-n|--no) set_var "${CONFIG_}$ARG" "# ${CONFIG_}$ARG is not set" ;; -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Jan 16 04:35:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 04:35:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206122.1519877 (Exim 4.92) (envelope-from ) id 1vgbYG-000680-2N; Fri, 16 Jan 2026 04:35:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206122.1519877; Fri, 16 Jan 2026 04: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 1vgbYF-00067m-Ue; Fri, 16 Jan 2026 04:35:11 +0000 Received: by outflank-mailman (input) for mailman id 1206122; Fri, 16 Jan 2026 04:35:11 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgbYF-00065r-M6 for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 04:35:11 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vgbYD-006D19-2T; Fri, 16 Jan 2026 04:35: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 1vgbYD-005RCF-0d; Fri, 16 Jan 2026 04:35: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=cGX7QRPQV6chtt4Q4JiEAoLE9EjWPAngRkAOki5ArhA=; b=MTGsgyktOaUhTGAEmFmeY3oPtO v3DoCqpYE/umcFF5b65tq+71/Er3rsdyOQ8vOO8rO6JyU55vax5sq2ysCadb+fL7SQQ2xtuUd9lf+ tp2JatXcsb3ogvFK2j3ixrXHnKMgtZzq6yFGsS6xlP3zEVSlzyD2qNZQ5E3LM6gQQ1vw=; 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 v1 4/4] scripts/config: hook to automation build script Date: Thu, 15 Jan 2026 20:34:58 -0800 Message-ID: <20260116043458.730728-5-dmukhin@ford.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260116043458.730728-1-dmukhin@ford.com> References: <20260116043458.730728-1-dmukhin@ford.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Denis Mukhin Use the new .config manipulation tool to toggle CONFIG_DEBUG in the Xen automation build script. Signed-off-by: Denis Mukhin --- automation/scripts/build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/automation/scripts/build b/automation/scripts/build index 7a81d229decd..ee1127c53dc5 100755 --- a/automation/scripts/build +++ b/automation/scripts/build @@ -27,7 +27,7 @@ else # Start off with arch's defconfig make -C xen defconfig - echo "CONFIG_DEBUG=${debug}" >> xen/.config + xen/scripts/config --file xen/.config -${debug} DEBUG if [[ -n "${EXTRA_XEN_CONFIG}" ]]; then echo "${EXTRA_XEN_CONFIG}" >> xen/.config -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Jan 16 07:01:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 07:01:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206209.1519887 (Exim 4.92) (envelope-from ) id 1vgdpW-00009E-Tu; Fri, 16 Jan 2026 07:01:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206209.1519887; Fri, 16 Jan 2026 07: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 1vgdpW-000097-QJ; Fri, 16 Jan 2026 07:01:10 +0000 Received: by outflank-mailman (input) for mailman id 1206209; Fri, 16 Jan 2026 07:01: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 1vgdpV-000091-Pr for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 07:01:09 +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 21c83e05-f2a9-11f0-b15e-2bf370ae4941; Fri, 16 Jan 2026 08:01:08 +0100 (CET) Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-4308d81fdf6so962960f8f.2 for ; Thu, 15 Jan 2026 23:01:08 -0800 (PST) Received: from ?IPV6:2003:ca:b70c:6a3e:55b2:6ac3:5c03:be67? (p200300cab70c6a3e55b26ac35c03be67.dip0.t-ipconnect.de. [2003:ca:b70c:6a3e:55b2:6ac3:5c03:be67]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43569926648sm3454354f8f.10.2026.01.15.23.01.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 23:01:06 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 21c83e05-f2a9-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768546867; x=1769151667; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=ayJPgyHpxlsc7HAnLOHjxLMRPJOVx07qFlR3E0f2ywY=; b=HNnttfQfVk7PDkafR/yloaTstYw8dYR1eCt6U+8e7jwZfGHTXMvWN/9zHsUrjVsxVB l1O0KkeRScXY697ErvALif2/FVvZKHG6r4sSnQ4rqgrU6oMAingNgqGS6pWCucEkOu7H b0luEqpyZ0lDWyDZFfEQBcuvTFI8o2jlVPkACUvNDkoL78hXTosB9+lIyJSLShHCdZY8 2pt4BT+uXlLma2x5Mfum8eHdI3QXdurvIE5yyhKi8XUfWAxs2e5ICbNDqdcBSnQLb5z7 IffSIHTr0Nqucvhb/aBDx1Jlb4WluIUR+oIFhygySs5At18wHEVCmzXae2WH8ZY3gNRl 6T2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768546867; x=1769151667; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ayJPgyHpxlsc7HAnLOHjxLMRPJOVx07qFlR3E0f2ywY=; b=c4C2Jomf5elfj4abG/9WW67E/nV8slfMOaPyhH/9mQhWNKiF0qEngwLU7NAfVc5nIz I9qu1OXE7rnVHGcqPBl7hSBV1vmcGUGWymjDT5O8OrWmcHDfDlUl7MyFVUa23q2s3HvH tKg+AmzWT8uBV+QIJopOHrlKTaxkaR+ORcZHIJbBTwCoEPCmFtUV8Q3iMmRg+A+2RI7o lEtMfPe3EN2Rmxu5l3jondnTRJHvpDbwGRK1xx+A8dU3brDaphTIpNKAxucD0vL3gk26 7I2CcFHHtciwSXE1m5DsQ3XFRI0WDebL1/iLSPj12Oc7KCEWJG5F4l5MuKwNNYf9TRsO +flg== X-Gm-Message-State: AOJu0YwCWJnYhbDuB2/R7uVPKtIdlJVrqujCPcmuI0kHRqXKwDPaO1Az ToBadfWEdlcbghr+c2ln9W1WiszKom+zVjJHINjuuupNorwzme9gp8loph/SSCnV5A== X-Gm-Gg: AY/fxX5YQR70DJK3TfrRbr/Ub/s7nNpTlxMB2ipP7LlKTM+qm8y6/4JF0nqipD2ROHB LGU2moUFIPTxUylxh30rBSe9WUNFcv0rbf0cU4+ic+xsdmTPL/Ht6uJrjSuRw+T9R5MMv7BmzbI idqP0x/jwWLo/2WfuY+U6DgnqgyQqZQXiU7L4p5WekrHPEkKlGM8gQP+umr5Tuoad61WUq/SCr8 MIZWICQJO8gZYklzkZoqEAPTEUOKPoPkvwJJIJKX0OzCUuCfF42oCUqD/eAJ4Qn6qspoBakq7T2 h+uvMlk6Azq0DHHK69yGOu7G5p/cGfRkQbX4Wz2JGJGzjTRVIR9tsdil3ncfLO3P7qKomkjRJRG GDczb2DHQh4OCwbAbyvHt66G8XpQBkCS8kdE34qzPEsMrByBuLJnhMaNk77Z2auXZu9hx6uWCCV gz4RfBu7A2MXXa0fH+4cD+jrS1tahiGDkK5xaJ1pjRseKHahBCFHW8ksMB7aAUBNkKlCcPx/0PD n4T79LYHuQWcdgvycoDkuZIC1U4RtZ7RwALbx10Ncmou4/p X-Received: by 2002:a5d:5f53:0:b0:431:266:d13a with SMTP id ffacd0b85a97d-43569bcb7bbmr2065190f8f.48.1768546867285; Thu, 15 Jan 2026 23:01:07 -0800 (PST) Message-ID: Date: Fri, 16 Jan 2026 08:01:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/6] xen/x86: move declaration from mem_access.h to altp2m.h To: Tamas K Lengyel Cc: xen-devel@lists.xenproject.org, jason.andryuk@amd.com, ray.huang@amd.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alexandru Isaila , Petre Pircalabu , Penny Zheng References: <20260115092841.2651224-1-Penny.Zheng@amd.com> <20260115092841.2651224-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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 16.01.2026 00:07, Tamas K Lengyel wrote: > On Thu, Jan 15, 2026 at 4:29 AM Penny Zheng wrote: > >> Memory access and ALTP2M are two seperate features, and each could be >> controlled via VM_EVENT or ALTP2M. In order to avoid implicit declaration >> when ALTP2M=y and VM_EVENT=n on compiling hvm.o/altp2m.o, we move >> declaration >> of the following functions from to : >> - p2m_set_suppress_ve >> - p2m_set_suppress_ve_multi >> - p2m_get_suppress_ve >> Potential error on altp2m.c also breaks Misra Rule 8.4. >> >> Signed-off-by: Penny Zheng >> Reviewed-by: Jan Beulich >> Reviewed-by: Jason Andryuk > > Acked-by: Tamas K Lengyel Thanks for the ack here as well as the ones for 4 and 6. What about 2, 3, and 5 though? Jan From xen-devel-bounces@lists.xenproject.org Fri Jan 16 07:04:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 07:04:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206217.1519896 (Exim 4.92) (envelope-from ) id 1vgdsS-0000hR-Af; Fri, 16 Jan 2026 07:04:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206217.1519896; Fri, 16 Jan 2026 07:04:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgdsS-0000hK-7n; Fri, 16 Jan 2026 07:04:12 +0000 Received: by outflank-mailman (input) for mailman id 1206217; Fri, 16 Jan 2026 07:04: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 1vgdsR-0000hC-0u for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 07:04:11 +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 8d6327f6-f2a9-11f0-9ccf-f158ae23cfc8; Fri, 16 Jan 2026 08:04:08 +0100 (CET) Received: by mail-wm1-x344.google.com with SMTP id 5b1f17b1804b1-47fedb7c68dso11058775e9.2 for ; Thu, 15 Jan 2026 23:04:08 -0800 (PST) Received: from ?IPV6:2003:ca:b70c:6a3e:55b2:6ac3:5c03:be67? (p200300cab70c6a3e55b26ac35c03be67.dip0.t-ipconnect.de. [2003:ca:b70c:6a3e:55b2:6ac3:5c03:be67]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4356992681esm3366346f8f.11.2026.01.15.23.04.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jan 2026 23:04:07 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8d6327f6-f2a9-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768547048; x=1769151848; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=2/uxT1IsHyoq40vUl8mHMMfSOqv4Eb1xS5Yuvea9w5E=; b=E4+BofxQo1L1VFyVj5B/O2RQM3qFoDyfeAVMPJY9OBj9MBs2UcA55AOpvoY1EgHxEh ChH4e+cYhl89tLShFgF4KS8NNcKB9D5o6Zi9osHKS9aluwk6RrMGZQ8OwNQ8FkUDkr/A kUbhvqqXbxflrOJkerFrG/Da9l36yKkb9IL/OI1z+eN41O95Yb6AZBdQwt2eEoUiRlBf 8obI/eNwlvjeVsup4qci8ELntyDR+gqFwFMXhdtIA8DZVPWXXcWrEvdd5ip92LJRa76n GYVgm0+TaR4kL4lSZicIxvZ1BY72GfhCUulyTooho46K9tp2Uas0qXJmqE7VfIubgMxS rIIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768547048; x=1769151848; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2/uxT1IsHyoq40vUl8mHMMfSOqv4Eb1xS5Yuvea9w5E=; b=Sc6kC10j4xip6iOb1RjBlfFNlWtB4T1CEccNROvaz7TCvl/eIMfKUxxYQFLsqPV1VU sAMPaNzchZDVFt+sOdOuuC4kTHexfSji1/AIKIzQoji4yMEnEtuZBJoYjniUsjQ3Q580 /jl1+2+eO8JzSbib1YZOoxAK3/r2Xhh98QJqrxFm1eGrCQk0O9VppOjigys+qI0WqVKX DdD7+HMqbS9X+5Cbp5vEp5phez5Z7kuJtfgqHRYtkrFE/yjvMs0WNXi5eytF/k/+vu5E xJp8+0g1M5gLvss6xH0qevtrcxevCfbXazKbKMH6RyxsCpbhUpAH8EIDGeWbk/vA2Wui FaUg== X-Forwarded-Encrypted: i=1; AJvYcCW7Ry34IZy6bwsNIJO8P7mpBlsEnmuMrxopYnv1rUYeppH8wrvVI5/O7K5Ph6FTXgdNEecUbzfaT0k=@lists.xenproject.org X-Gm-Message-State: AOJu0YxeUv3TYTcR1cPYY3yb1ubGNyGjeT+5YK/KMJxO1YXv/vVLh4ok rx0iDSjVjm7AryubSVIP7PbVHpN8N1Ne5e5RQyXkrxiL4ErnnSlMkbb5BpvWjk0lLA== X-Gm-Gg: AY/fxX7r6tSitr9PColIGcM+82LW8tLHFFRGP4itK95N2pde9b4i71EB44OisojZ0I1 xK9BXpIYaq+iCTsHFr0D0OXaxKW5jssAi2k+TCUGgjbMU8/ZcgKrqsxuVD/NQr+s7KGJLbaMJf9 BLw2ltQ9FquBywQFCJoaEqV+7mXNALdcRalpoMKs12GF20fJlnbQZ6l1p93I0+0LaF+Jcf01sW1 xENl3XaepnlLqlCvJlTwOGFI0IVAiSuV5W0XluVGYuKrIW3G3A3tUDS6u59+0pwLQcXy0S19ywb Hb3GPko2vBERlAlRixaQzMW7kvTq/qjY5a3L4ptsbwo4SW9s8TNIr5B27WLUBpBYKcmG4xlm6hp Rn5uZlo8Iv+UO1L1zG7g1xVY0m34mGXuqXoGeC9Wqsrpvy5gO6sfJYG6WOYvxOib3ywSGUAfOQO y07tUAC47TNqHNEdCe4MvSm/tj621Kzo9hxRPN54a/P6rQkdiFYVTt8fd/2XWfublqlswDVcXr7 oq9bWaTXP9z5HHp6GD4mxyyDL2v9teF4Oaj7wC++HSQo/ig X-Received: by 2002:a5d:5f96:0:b0:431:a0:7de0 with SMTP id ffacd0b85a97d-43569bc1928mr1889259f8f.35.1768547047369; Thu, 15 Jan 2026 23:04:07 -0800 (PST) Message-ID: <09c0007b-3cac-469a-83a0-726c1be149da@suse.com> Date: Fri, 16 Jan 2026 08:04:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] INSTALL: remove unsupported XEN_CONFIG_EXPERT from documentation 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: <20260116030842.415583-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: <20260116030842.415583-2-dmukhin@ford.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 16.01.2026 04:08, dmukhin@xen.org wrote: > --- a/INSTALL > +++ b/INSTALL > @@ -33,11 +33,11 @@ small subset of the options. Attempts to change other options will be > silently overridden. The only way to find which configuration options > are available is to run `make menuconfig' or the like. I fear this earlier paragraph needs editing as well, which will then make more clear that ... > -You can counter-override this behaviour by setting XEN_CONFIG_EXPERT=y > -in your environment. However, doing this is not supported and the > -resulting configurations do not receive security support. If you set > -this variable there is nothing stopping you setting dangerously > -experimental combinations of features - not even any warnings. > +This behavior can be overridden by enabling "Configure EXPERT features" > +in Kconfig (CONFIG_EXPERT). ... this may not be quite adequate. Jan > However, resulting configurations do not > +receive security support. In addition, CONFIG_EXPERT permits the > +selection of experimental and potentially unsafe feature combinations > +without generating configuration warnings. From xen-devel-bounces@lists.xenproject.org Fri Jan 16 07:39:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 07:39:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206241.1519906 (Exim 4.92) (envelope-from ) id 1vgeQJ-0004sm-WF; Fri, 16 Jan 2026 07:39:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206241.1519906; Fri, 16 Jan 2026 07: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 1vgeQJ-0004sf-Sr; Fri, 16 Jan 2026 07:39:11 +0000 Received: by outflank-mailman (input) for mailman id 1206241; Fri, 16 Jan 2026 07: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 1vgeQI-0004sX-Be for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 07:39:10 +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 707aab27-f2ae-11f0-b15e-2bf370ae4941; Fri, 16 Jan 2026 08:39:08 +0100 (CET) Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by SN7PR12MB8792.namprd12.prod.outlook.com (2603:10b6:806:341::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.6; Fri, 16 Jan 2026 07:39:04 +0000 Received: from DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::6d8e:2499:8a0a:7eb2]) by DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::6d8e:2499:8a0a:7eb2%2]) with mapi id 15.20.9520.005; Fri, 16 Jan 2026 07:39: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: 707aab27-f2ae-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=i3i41AWBbuBycFApyXWQYU83XjB9cnR9j0ijo/zwKyyl8/9h9nIUMrYwIsUv4EdoR90PJo9RVrW4T7MdOLW+zHLnEsXgHv0BS91DbdKHAAUMnyruuCMuddr4D0uVFijMrvgzBqrYwt0IHz31iJn6j3UQcedkJf0HJO+6fg844zPHZ9eJzMZW0segHAlAF9pMG9U5VD7fXlncTNt8kxdFsczQQBRkB9lLKNUXmzd0H9+MR4Z84Y8NuEGQKU//cAM1H3ssS5UlkM+V/Amogyx9FGD7YyCgStA214X0JNbcHxPw5jLRppkHvmDNUCUITRC3eXCZ1KnAETKgJnZv+ZvukA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HGTSZ8piwgHaKl1GOzMZjZyoyyCvYA907ZSIxn3VuzY=; b=cS5dD8akyt3XahQYRGTVPd7UEohkTU8zaHCo1HHxCAZkC4gIzc436ZdTigOM6vamASn4yyxPVMHik6aAG4XU7+tKfFCpa2SMvTiwTu7Q2f58FBJFnq5bvwaWA6I+TI9vUq0kHp0YzPint26K7c8JEGNHLSUAZIJBN5Y4tTJ4USDXK8tja86olpkgSmyVgiq6rxdcaFfe4Nbgb5r0w907c8us594FlyUtqANvTnuK/Bux1fUXzRUmFDtsVP/a0aH02JLvvJhmzYBvfN3vgQll5WezREQAX/OkH/R2vGyEL8+bu+K06aCEcTcfsS1dZUgXsyxmxASLU15HEG4if38JKw== 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=HGTSZ8piwgHaKl1GOzMZjZyoyyCvYA907ZSIxn3VuzY=; b=SepOppEN6/7eSGIKmBBFqamMRrS5tUaKlBkEZLXRxroUmO+TZCzPh5vAqi1tKYjzy7WZCXiu6XeikC2vxi0T8Qy9PIdaATfdD/m1gRaOY43/u1f7ut/sAejPGXMgZZKNPHr+CfwieYQxdn7hSJsD7HNXkjjXblr7+QYT+QZcW/A= From: "Penny, Zheng" To: "xen-devel@lists.xenproject.org" , Tamas K Lengyel Subject: RE: [PATCH v4 3/6] x86/monitor: wrap monitor_op under CONFIG_VM_EVENT Thread-Topic: [PATCH v4 3/6] x86/monitor: wrap monitor_op under CONFIG_VM_EVENT Thread-Index: AQHchgFzx+i/rzGyyUiVB7q9IfPMErVUadBg Date: Fri, 16 Jan 2026 07:39:04 +0000 Message-ID: References: <20260115092841.2651224-1-Penny.Zheng@amd.com> <20260115092841.2651224-4-Penny.Zheng@amd.com> In-Reply-To: <20260115092841.2651224-4-Penny.Zheng@amd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2026-01-16T07:38: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_|SN7PR12MB8792:EE_ x-ms-office365-filtering-correlation-id: 1ff81181-3753-43e5-6802-08de54d25307 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700021|7053199007; x-microsoft-antispam-message-info: =?iso-8859-1?Q?PQczt1BOXKHc6B5BiPEe80Spz1heArct9D610W9LGFBw5eaoziXTAxLqeU?= =?iso-8859-1?Q?fzvDk9lAfgq0smcTzpXts6rxFJxLQZAldEOgJ0nhq7NYBPRn8Qp5lE988T?= =?iso-8859-1?Q?3PD3TZv8Kka5T9G8rgAssGgZN5k82oD5vs5lpVu6yS6Eq8BvXmWUO3q3iP?= =?iso-8859-1?Q?jvDpqBQo4u1FEis6LnwfhzRGOvVyq2LS/Trq1nM2BXGsy/aiBSnI/si6Pg?= =?iso-8859-1?Q?lUOz10VymgB7FDBzJOauxbTz2DcrXZ0gdoaH9xKytfcS+WXYWobTeKd3+F?= =?iso-8859-1?Q?cxHUiM9Lsqe1u8vPsfjorRjlZRa06HwnK/XhPom9JXm/QpcAMjSPg9H4JU?= =?iso-8859-1?Q?2P1aN3ie7wgYtIUykEevek4ORSyyatq9Heh0j9sxI5PKzme1xulBHcBCLq?= =?iso-8859-1?Q?HGc0s9Ex8qoSEG0eColJJMHSbt7hX6qAPsN+gJziW1hkq6eeTbPceKFTQX?= =?iso-8859-1?Q?EBRgKVJ7YoVxHiIE20vTt4FS2Ux4xE4PGd7N/Tuat9N9vGa6KZZzI6cnW4?= =?iso-8859-1?Q?4JxqkXb6qGMzY6dBPUI5OX0WzTRWY0zOV46eaaU8naUo31lSkRUpd5TO7/?= =?iso-8859-1?Q?vNvDsECe9HQNLJSkbaaEWQ/yNsGBMVTUtT+b2nBuR3DZfDcTtQ3fNFO6N9?= =?iso-8859-1?Q?t0XuWMhhjwODg80/6zgCztnfCx8rmkSCmQ+7ObcwrjK+K7+ceXj+hERWk3?= =?iso-8859-1?Q?kDyVdXxDe4QmitDoWX5rXUlFcXvLNI8hBUvgsNjnEfNhzVLB6ZMC+TnRJW?= =?iso-8859-1?Q?fogsbupf6hRX+H+5Inh8k/6CuskxKvJliSgKBjtKb2MXbwnYWy7obSIl8d?= =?iso-8859-1?Q?ru3QLhw64MfCMdImI+om02lRBb12loeGpM9C+fmeGP5+sgyk5pieQNnEI6?= =?iso-8859-1?Q?xGxzNxqIhXUNFC2o4+gkllF8ct5rwVsB7uQbboH2sHUADBGpEW58TaPDkJ?= =?iso-8859-1?Q?kH0yQeDf5YEbK6HeWtbTSm7oKtp1qmVxKAN158sXKN1vzS1Py0NtmkmWu2?= =?iso-8859-1?Q?P698rVEx3t3bW3yz47orkZfetCbzvP1Qj4a9j0mzWjppiVNGtRashMdYeZ?= =?iso-8859-1?Q?7RrViIqFC86UkO5ksFYct1PRSfwrwtc+TXFHV1pyS1jHGLhOY2RPzV5/4Z?= =?iso-8859-1?Q?IT9ClFnlTM7x461X5nEMFYHR2OYUC/lunBAByQKuOkWbYH0AIPZMcRuHu4?= =?iso-8859-1?Q?cMjFRv/pFxm1LnNcv/jTZOF617QJCs/hEHTEFdUPClEiSFV3uSnJoxP51G?= =?iso-8859-1?Q?/cwn2HXGk/0UyHtCir+JsDV2bW5Lgc4Z5ZxyaMyS+sTOinAtY6Ia39R1L2?= =?iso-8859-1?Q?5Kja7C25d5Xm1pBwCGLqsS+PdfwZBbwVAy0rFJ2CmyNswE5rVTt6l5tsy1?= =?iso-8859-1?Q?pj8WuxZDDUUpZna6v3Vmz/dLC9a3Az+2cbMfFILVbd2w7n5woS89aJ6P+z?= =?iso-8859-1?Q?/aH/lgs9sVq1X4ZNiU71nlQEVJaLLMsoQTNAmlRPkIaTDKgxaK7M7SMPRX?= =?iso-8859-1?Q?+HVmwckbKyYFzkGj6hfKvlN7pSmw9pP16y3J4OGsxPt6rxmcVdeNC8D2CO?= =?iso-8859-1?Q?t1X6p6hcGSpq+85y8zPbRtk8uQIDKscnSOu1K9CEOvSJmojADFhgWl32UB?= =?iso-8859-1?Q?7Bp09MzSnU4OpQvsn6TsEsZHrrOMSuVvQQ9lCfNmucHlgUD/mYfosA/U7/?= =?iso-8859-1?Q?TDiBuwTJytYo94hE6ss=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)(7053199007);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?ifYPthjVSAyMsjUYWLkT3HDGKSvSGvINFFsl1mH++fPT2Gn+4ws6KdUlOl?= =?iso-8859-1?Q?XUh/cNsmA5bfeqtc4X21iNiEi5p6+XKtG9WtJaJixaVWWd4uzEGKdiyXH4?= =?iso-8859-1?Q?OhVpVncj+A9M9DUIdYOTz20N2Pi5vyUtc/ATK4y5PnUxV+rTx/psu1koj9?= =?iso-8859-1?Q?s9P5GflqX6g/kllzFjDd5I5QcdAsRN6+W5SI4t9hXZoelcFkqGJPnHsprb?= =?iso-8859-1?Q?T5ABe6k3W6+cOIpoobj9Pl9hWixKbza33yOQuLwag2EhadO99mq0hq8t8k?= =?iso-8859-1?Q?OYDe3hhE7UX1SX6PB4o3rdbTpQFDCEEhjq96DjvIJgaHG2h3CVo/udMkyl?= =?iso-8859-1?Q?YNctA4/D3FGTVQs9EkXtE8LbXEhEhgoJFMis4RMR1n19C6vbrtnvgLm/l3?= =?iso-8859-1?Q?TU7bx/S6Tur6VVPxwCvsUGqv0OFdhbmJpfjZVks63bwf6wsoz4TWWM1Haj?= =?iso-8859-1?Q?mMF5wqwX1kBZvDaHMF2lYyJTEwrIorBPOlNHPcJ+7JhMbQPBM0raXZ8E2i?= =?iso-8859-1?Q?dKqZZAcjg8aT9jx2/b+mMH1HtWRyRKEvVlwBH5RQRiJJJRaoPk5XypeD2u?= =?iso-8859-1?Q?kSX7YcghYyJZOSkxEhDwhhLE2euFqoHuGCRzLRwoLo/Tp79opyOICxttgI?= =?iso-8859-1?Q?zu51cJGyogTsR5bGMVv8jocmZ37ZERTvtITKi7hErM0W8ZR92ViyKNhUpR?= =?iso-8859-1?Q?BYcgQhCcK2FvSOJZAG61U+3f4w2XtA85l+cwFkbXYslCaw6mNccyZWMsiI?= =?iso-8859-1?Q?z5a3djJGf0Cfvlybo8gSSVFCtk4O6Xu1CsYTMWKgowSg4QKPhxC8H/W4UV?= =?iso-8859-1?Q?vnGq+xbCnqv7Y5bjI8UeVfQ/iQEO8qkc5eUEOg5t0QuQR/A7S/ufBCgLIj?= =?iso-8859-1?Q?EDPa7Eu7FhOT4WEkuy/nEmCphOQEdwjdTJhud0aBMqEO/LEfPvkblWxh4H?= =?iso-8859-1?Q?56NQk5qtB3r8AyhsucTcVYWiI6Nir8bkK/PpAvFBsJf32Hy5+wxGrrkiB+?= =?iso-8859-1?Q?wW3tmRA3MtMuwqeuob/r9QJSt3+fWzyuV0aGj59EzKRk7j5uz9pWfUyZ1v?= =?iso-8859-1?Q?1SNSj5xxQ5AfrrrTItZj+X9vDndrnWQkYZA88NCSiCvktWJGrcIxuJ5bpQ?= =?iso-8859-1?Q?UVVgKoOfU31zcE7BgOVXV2mc3NnDPe6MidQNOiWfn9yPti8H+HrLczJb5o?= =?iso-8859-1?Q?/pNvI8ExXDhH4HcXBoPZPotYNsiQRMcoalrOfUPET4Tt04q69arMojT0bt?= =?iso-8859-1?Q?cZlaPPtT+nxXMCZ+7/BYQC+Enbq2ZQISdqDD/QUtBuNXZe2cCvJiqM2S/M?= =?iso-8859-1?Q?o97lMV5/tuoXE6K3PX1VTJ1Dz3cVt5JiTZZwr8XhMVZmEOAqYgrqLMcJIR?= =?iso-8859-1?Q?d7bPAh0byIostsAvjWoaI6bEHWimh4x5WJMYCHd4AZiHPdFet2EeZZXwPM?= =?iso-8859-1?Q?+NlZkuivteMFFzbW+YG1e1TxMk3vxGsIVAWTg8G4q0WxwoVwD+AjU3LorO?= =?iso-8859-1?Q?fe1HittYp5d3CL49ZhTcaFoAZ5xJv1RmnmQ+I4tD1zctWHti6W6O+T4mgq?= =?iso-8859-1?Q?0pmA1brsKhJrbCK6e4t8CAgp4EFzx838hGkHmQAsboABCOr9fpDedDl4FT?= =?iso-8859-1?Q?TnpfSQwtzM2oIrjRrd2pQgA6TuXWEqKVuuqRe7AjZqImeEZgzPHBuqCvhQ?= =?iso-8859-1?Q?+Kldmkw+Oqsil9xSdsPRlLrwie7IIoPks92heZrhTAh/MlifcdWa+U4lln?= =?iso-8859-1?Q?f1QF2mFcZjreBEHalX5Kt5M95bgSXmcezlZ+07CMEuEeEl?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1ff81181-3753-43e5-6802-08de54d25307 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2026 07:39:04.5934 (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: Ak5VvBmH/7sYhH2WosLQewdcOB4fP40LsMQnVLP+Zarrm1IDAfzXdKbl1UoL2h82K0LnKqxA3MPBm3rrfY72dQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8792 [Public] Hi, Tamas May I ask for a review on this commit? Many thanks Penny Zheng > -----Original Message----- > From: Penny, Zheng > Sent: Thursday, January 15, 2026 5:29 PM > To: xen-devel@lists.xenproject.org; Andryuk, Jason > Cc: Huang, Ray ; Penny, Zheng > ; Jan Beulich ; Andrew Cooper > ; Roger Pau Monn=E9 ; Ta= mas > K Lengyel ; Alexandru Isaila ; > Petre Pircalabu > Subject: [PATCH v4 3/6] x86/monitor: wrap monitor_op under CONFIG_VM_EVEN= T > > Feature monitor_op is based on vm event subsystem, so monitor.o shall be > wrapped under CONFIG_VM_EVENT. > The following functions are only invoked by monitor-op, so they all shall= be wrapped > with CONFIG_VM_EVENT (otherwise they will become unreachable and violate > Misra rule 2.1 when VM_EVENT=3Dn): > - hvm_enable_msr_interception > - hvm_function_table.enable_msr_interception > - hvm_has_set_descriptor_access_existing > - hvm_function_table.set_descriptor_access_existi > - arch_monitor_get_capabilities > Function monitored_msr() still needs a stub to pass compilation when > VM_EVENT=3Dn. > > Signed-off-by: Penny Zheng > Acked-by: Jan Beulich > Reviewed-by: Jason Andryuk > --- > xen/arch/x86/hvm/Makefile | 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 | 18 +++++++++++------- > xen/arch/x86/include/asm/monitor.h | 9 +++++++++ > 5 files changed, 38 insertions(+), 9 deletions(-) > > diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile index > 1b97bdc624..ee4b45a4ee 100644 > --- a/xen/arch/x86/hvm/Makefile > +++ b/xen/arch/x86/hvm/Makefile > @@ -16,7 +16,7 @@ obj-y +=3D io.o > obj-y +=3D ioreq.o > obj-y +=3D irq.o > obj-y +=3D mmio.o > -obj-y +=3D monitor.o > +obj-$(CONFIG_VM_EVENT) +=3D monitor.o > obj-y +=3D mtrr.o > obj-y +=3D nestedhvm.o > obj-y +=3D pmtimer.o > diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c inde= x > 21f355a657..5d23603fc1 100644 > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -297,6 +297,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, uint3= 2_t msr) > { > struct vcpu *v; > @@ -304,6 +305,7 @@ static void cf_check svm_enable_msr_interception(stru= ct > 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) { @@ -824,6 +826,7 @@ static vo= id > 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) > { > @@ -841,6 +844,7 @@ static void cf_check svm_set_descriptor_access_exitin= g( > > 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) > { @@ -2454,9 +2458,11 @@ static struct hvm_function_table __initdata_cf_c= lobber > svm_function_table =3D { > .fpu_dirty_intercept =3D svm_fpu_dirty_intercept, > .msr_read_intercept =3D svm_msr_read_intercept, > .msr_write_intercept =3D svm_msr_write_intercept, > +#ifdef CONFIG_VM_EVENT > .enable_msr_interception =3D svm_enable_msr_interception, > - .set_rdtsc_exiting =3D svm_set_rdtsc_exiting, > .set_descriptor_access_exiting =3D svm_set_descriptor_access_exiting= , > +#endif > + .set_rdtsc_exiting =3D svm_set_rdtsc_exiting, > .get_insn_bytes =3D svm_get_insn_bytes, > > .nhvm_vcpu_initialise =3D nsvm_vcpu_initialise, diff --git > a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index > 89f9d9c7f6..40e4c71244 100644 > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -1581,6 +1581,7 @@ static void cf_check vmx_set_rdtsc_exiting(struct v= cpu > *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) > { > @@ -1595,6 +1596,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) { @@ -2474,6 +247= 6,7 @@ > static void cf_check vmx_handle_eoi(uint8_t vector, int isr) > printk_once(XENLOG_WARNING "EOI for %02x but SVI=3D%02x\n", vect= or, > old_svi); } > > +#ifdef CONFIG_VM_EVENT > static void cf_check vmx_enable_msr_interception(struct domain *d, uint3= 2_t msr) > { > struct vcpu *v; > @@ -2481,6 +2484,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 > > @@ -2932,7 +2936,9 @@ static struct hvm_function_table __initdata_cf_clob= ber > vmx_function_table =3D { > .nhvm_domain_relinquish_resources =3D nvmx_domain_relinquish_resourc= es, > .update_vlapic_mode =3D vmx_vlapic_msr_changed, > .nhvm_hap_walk_L1_p2m =3D nvmx_hap_walk_L1_p2m, > +#ifdef CONFIG_VM_EVENT > .enable_msr_interception =3D vmx_enable_msr_interception, > +#endif > #ifdef CONFIG_ALTP2M > .altp2m_vcpu_update_p2m =3D vmx_vcpu_update_eptp, > .altp2m_vcpu_update_vmfunc_ve =3D vmx_vcpu_update_vmfunc_ve, @@ - > 3141,9 +3147,11 @@ const struct hvm_function_table * __init start_vmx(voi= d) > > vmx_function_table.caps.singlestep =3D cpu_has_monitor_trap_flag; > > +#ifdef CONFIG_VM_EVENT > if ( cpu_has_vmx_dt_exiting ) > vmx_function_table.set_descriptor_access_exiting =3D > vmx_set_descriptor_access_exiting; > +#endif > > /* > * Do not enable EPT when (!cpu_has_vmx_pat), to prevent security ho= le @@ - > 3214,8 +3222,10 @@ void __init vmx_fill_funcs(void) > if ( !cpu_has_xen_ibt ) > return; > > +#ifdef CONFIG_VM_EVENT > vmx_function_table.set_descriptor_access_exiting =3D > vmx_set_descriptor_access_exiting; > +#endif > > vmx_function_table.update_eoi_exit_bitmap =3D vmx_update_eoi_exit_bi= tmap; > vmx_function_table.process_isr =3D vmx_process_isr; > diff --git a/xen/arch/x86/include/asm/hvm/hvm.h > b/xen/arch/x86/include/asm/hvm/hvm.h > index 666fa402a8..af042ae858 100644 > --- a/xen/arch/x86/include/asm/hvm/hvm.h > +++ b/xen/arch/x86/include/asm/hvm/hvm.h > @@ -192,7 +192,11 @@ 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); > + void (*enable_msr_interception)(struct domain *d, uint32_t msr); > +#endif > > /* Nested HVM */ > int (*nhvm_vcpu_initialise)(struct vcpu *v); @@ -224,8 +228,6 @@ str= uct > hvm_function_table { > paddr_t *L1_gpa, unsigned int *page_orde= r, > uint8_t *p2m_acc, struct npfec npfec); > > - void (*enable_msr_interception)(struct domain *d, uint32_t msr); > - > #ifdef CONFIG_ALTP2M > /* Alternate p2m */ > void (*altp2m_vcpu_update_p2m)(struct vcpu *v); @@ -435,11 +437,18 @= @ > static inline bool using_svm(void) > > #define hvm_long_mode_active(v) (!!((v)->arch.hvm.guest_efer & EFER_LMA)= ) > > +#ifdef CONFIG_VM_EVENT > static inline bool hvm_has_set_descriptor_access_exiting(void) > { > return hvm_funcs.set_descriptor_access_exiting; > } > > +static inline void hvm_enable_msr_interception(struct domain *d, > +uint32_t msr) { > + alternative_vcall(hvm_funcs.enable_msr_interception, d, msr); } > +#endif /* CONFIG_VM_EVENT */ > + > static inline void hvm_domain_creation_finished(struct domain *d) { > if ( hvm_funcs.domain_creation_finished ) @@ -681,11 +690,6 @@ stati= c inline > int nhvm_hap_walk_L1_p2m( > v, L2_gpa, L1_gpa, page_order, p2m_acc, npfec); } > > -static inline void hvm_enable_msr_interception(struct domain *d, uint32_= t msr) -{ > - alternative_vcall(hvm_funcs.enable_msr_interception, d, msr); > -} > - > static inline bool hvm_is_singlestep_supported(void) { > return hvm_funcs.caps.singlestep; > diff --git a/xen/arch/x86/include/asm/monitor.h > b/xen/arch/x86/include/asm/monitor.h > index 3c64d8258f..9249324fd0 100644 > --- a/xen/arch/x86/include/asm/monitor.h > +++ b/xen/arch/x86/include/asm/monitor.h > @@ -71,6 +71,7 @@ int arch_monitor_domctl_op(struct domain *d, struct > xen_domctl_monitor_op *mop) > return rc; > } > > +#ifdef CONFIG_VM_EVENT > static inline uint32_t arch_monitor_get_capabilities(struct domain *d) = { > uint32_t capabilities =3D 0; > @@ -102,6 +103,7 @@ static inline uint32_t arch_monitor_get_capabilities(= struct > domain *d) > > return capabilities; > } > +#endif /* CONFIG_VM_EVENT */ > > int arch_monitor_domctl_event(struct domain *d, > struct xen_domctl_monitor_op *mop); @@ -12= 3,7 +125,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__ */ > -- > 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Jan 16 07:42:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 07:42:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206252.1519917 (Exim 4.92) (envelope-from ) id 1vgeTI-0006Lv-DA; Fri, 16 Jan 2026 07:42:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206252.1519917; Fri, 16 Jan 2026 07:42:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgeTI-0006Lo-9Q; Fri, 16 Jan 2026 07:42:16 +0000 Received: by outflank-mailman (input) for mailman id 1206252; Fri, 16 Jan 2026 07:42:14 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgeTG-0006Ld-KC for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 07:42:14 +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 de429829-f2ae-11f0-b15e-2bf370ae4941; Fri, 16 Jan 2026 08:42:12 +0100 (CET) Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by SN7PR12MB8792.namprd12.prod.outlook.com (2603:10b6:806:341::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.6; Fri, 16 Jan 2026 07:42:08 +0000 Received: from DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::6d8e:2499:8a0a:7eb2]) by DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::6d8e:2499:8a0a:7eb2%2]) with mapi id 15.20.9520.005; Fri, 16 Jan 2026 07:42: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: de429829-f2ae-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=RK0JkdYpqEZJAGfTO+TI18Up7XKX2DmTOaYtZ913XIGm2bwC7+gUFeTPbz/K//T9AWSkUjz7lumAr3OmJAPSWl4xkcX7X1NK6PH1RKN+CjbOpkAhd9NmL3qA85N37GGgvxE8M01l95rUzrwuyyqn+xD32TEWuQoh5xTM9aDFK22S/odGAYe8hcLCT60RP/LDyp/rGsrLWDHQ/zHUcejCknuWGgbbZ9zQ7dxAeHMxILmAi1nTlU5PHb4rfzCfMcBIwwCapmd19MRGRUAC6OhPeCIBx+OVBwNrTnHuLMYpWEOv5d9h8tNI7Dkq/Y7m2F9ggk66u+b5Y6M1SnZe05m5Ew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eJS348ba2ktTQRfLWuR45oJBcnYOw/S44GCld14Abts=; b=HYGUWCgg/NzwuZ1IUU+6QtfXrZz2tMvr8dNpUrB4CqyiBjfuHuJqrtG0Z5mrFTIw8pYS+AWGy8D+SNJL+smXFFGr98/TZAW+SX1HWF+FN5YH9bEN2fe8ytO+HwRhwdYnkvlhw7OtkpCmJPtjVE/0R6aeenKO1IJqbf0SeqPwmPqmpvWWnW686U3wxDDxNFcdNIjoh9hUs+/fZcjZsujGpJHNHTwMGgdWFwgRT0qCd3jdLSGvptdXw/N1uFQhKQ7CWc7ce7hkIpQVw+OFaM7xsG1k9vwsvG4rw3Pu8enhWZdnAY30V40heB7n3Xj6RFnHzOHAiIeFuo5KFVIYUzDRGg== 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=eJS348ba2ktTQRfLWuR45oJBcnYOw/S44GCld14Abts=; b=kVABG1kKyV4K0BnO861TmOMBBaqWVYY3gImFw1jK30RZ6O3spZ85pWdED72aelLPJKnWrnHm1XLFhAo9/WVoVLcNrvNVCGiAHSRuc2ZjDS8h4cIHhw6MfsV6i3EYqJuwExiSBnm87jjIOfza8dZ8uXxZuZvnlsCyFk3WJlje2q8= From: "Penny, Zheng" To: "xen-devel@lists.xenproject.org" , Tamas K Lengyel Subject: RE: [PATCH v4 6/6] xen/vm_event: consolidate CONFIG_VM_EVENT Thread-Topic: [PATCH v4 6/6] xen/vm_event: consolidate CONFIG_VM_EVENT Thread-Index: AQHchgF0sy5e5KAUF0uytoTLl3dvgbVUar7Q Date: Fri, 16 Jan 2026 07:42:08 +0000 Message-ID: References: <20260115092841.2651224-1-Penny.Zheng@amd.com> <20260115092841.2651224-7-Penny.Zheng@amd.com> In-Reply-To: <20260115092841.2651224-7-Penny.Zheng@amd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2026-01-16T07:41:52.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_|SN7PR12MB8792:EE_ x-ms-office365-filtering-correlation-id: ffcc1843-51a4-4695-301b-08de54d2c0ca x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700021|7053199007; x-microsoft-antispam-message-info: =?iso-8859-1?Q?Iq0VzKcz6sWaUA6FNxLa8dsuMaAn+z05NtN5croowjPHGnO9TN/6dhhd5M?= =?iso-8859-1?Q?dL/mE84fJ3sYPP7HST26aN3FN+BjA6TuqYYxixi3yZOxfIwjDh3qpEkPXo?= =?iso-8859-1?Q?UnDQsC+t/URkQE2GMuZhXh1ZhbpsCzI/mULqb2vE7mCzUGNlpnD/1UrITf?= =?iso-8859-1?Q?kmhGCoZ1BIgsgMBmNOxK9flDZwGImr8BhfQxaRmhkIrBnvuDrLrFXBXTTi?= =?iso-8859-1?Q?13qd+Knbj/ltBDzT5RlvdC01cPwW0AFFz/PLQWMeL2HYosiopJbW/QJYfL?= =?iso-8859-1?Q?4anKk5+mrovwy6Lc8R2L+TZk5D8uEYpoj5VTsWJk6NmHkp4yex6TMcWB/1?= =?iso-8859-1?Q?j0AXLmhFl8lLNbbL5TUoovBxf2KQ2CQyBAnaSa4r+hHy9t31vShSNjso82?= =?iso-8859-1?Q?Sp0pS6eopqWMbYj/6bV9bLU8BbCM15Q8K0nKO7TMtvIe9ckKo+7PHmu8HV?= =?iso-8859-1?Q?eZKZnm4/mDTDHeKTvDPPKWvXeEfCHBFkgEu2DP9YQPvRz+jTojEtBAZQTc?= =?iso-8859-1?Q?qhzyT080zHifwD75x/tEw2g1iWdT7d9FH+USMgWxLmdbt8dNlAbeiQX272?= =?iso-8859-1?Q?l+cHhAY+8m9uWv+8cgBwoD+vlYvOUNmQtVIwXDv4yCLnniFwW8WswFPdLd?= =?iso-8859-1?Q?OrvrCaWrLu2pg4sqN5wdT3E1bm7QIFRxvBIkLB4ZkwRZ9TYRmBp4cgnnbI?= =?iso-8859-1?Q?lsyGg9qWK9+sOB2/wnkpf5ujYOZ6eQZm6FV27WZJ7EDlFsq4UCDz9uXPcS?= =?iso-8859-1?Q?Ffisr2yBEwKXR7sreM1mr1xDaoS+hWtdt4cWKZVJlhehELB3spLS/ITQAw?= =?iso-8859-1?Q?eq8B2c/v51TOyVgz4x8+fctbTXcIpNVa+bwMf47eoNbvoqrh54lierNwWV?= =?iso-8859-1?Q?ISnJhBGPzjN3+MV7G8DwbZc1JFH3wv3PRTbQPz3jRMy1OJq5MaNNKlzTaI?= =?iso-8859-1?Q?e6/sF8a7j/m2Rop9hqro/YOpF37pwn+M72KKo8Wd3izkLs+vw1NDw9yGDK?= =?iso-8859-1?Q?1ORDuN/z9QQkfMQ6CGZ/TtSz6R5o703apGgZjkSvSTOoPrAZQTTg0o5T4N?= =?iso-8859-1?Q?OTvll59mAfoei4pEUNRm8RpmLSLYrJ8XHjdl8HVbQ/KzwPfHM+Te85/e4+?= =?iso-8859-1?Q?GqCotmgmUPbbzu8M6eTY1opCg+D1FRMuI4KXs3H9YULt3ybEZdWDpe1eiE?= =?iso-8859-1?Q?oj7txSeDIgemaRManob4/tQ25+f5ttz/ZSy4QcaGVwNjwVOTlHCCaxAPKT?= =?iso-8859-1?Q?GG6/4zIOlJOEFMbGFCLA57Xv6Zt/Z2E2Kl41D73rR387VX0Ech4IyhnBKH?= =?iso-8859-1?Q?0Tb4kvRW3CieNsa78hbJnhd83wTHsv0DCKPjuwkGH03bzokgG6tD3bxf+I?= =?iso-8859-1?Q?nThZEWTKdMDuko1t7eZWNyV5j6nxg9lJEpQuUukrd6EuvqVE7BqW7lPJ5y?= =?iso-8859-1?Q?HhfaPSgC2Y7EcLTvFO6ESp87UA7eKQvqOhCT6IRaXIxaCS1pFSsuRxSjsZ?= =?iso-8859-1?Q?vogYF6gkDgtXprqVGTbogvdoSfnQ16tP7HShnmTB6AsSjI+APm0Zvb9Kxl?= =?iso-8859-1?Q?YMhjQFhWsV7ewoxwi98hkyGOZS33Nme9lbEYgXwFUJpCv92k2Hf6y0AVv/?= =?iso-8859-1?Q?EAVcTgqSMk4+WfojNxk2vkYdlblHvoDQQo7bjjY75sMN8Su2l/U/7EW2fj?= =?iso-8859-1?Q?tDyarDmc72srp4ptrkU=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)(7053199007);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?a0pzoduSzCKUldN71csWkIOhxtavtRioOLyVzMtG8QTnshbOohnOvgtAMA?= =?iso-8859-1?Q?6v3KClIA3p6ZRArHQ2X6r+nHYR8+M1czqyGGdDp08E0UCeituG2xJ1PggX?= =?iso-8859-1?Q?f72UmWOvtvaiszULxoSu4oFiCW4MquJx8mPx5kB7gvq3k0Bk5nAN8vZEbt?= =?iso-8859-1?Q?lSo6FTcGUlP+NL4NaPV0g4IjmfhNte9aK59r2T4ceo/W7bBX8SDvxypOB1?= =?iso-8859-1?Q?ukCWDlTG/aqSneJtLHYGMnRDB0kfvlLvQj7OiOiXKZ6xZgdsxPyoCqOpzU?= =?iso-8859-1?Q?DmrS+3mZXxcB7qPr2h28x/ZbBFyaiyVgF2K/IRkzWyy2yoPULBUvDSIstJ?= =?iso-8859-1?Q?P4Hm2lMVDF4bTdL0cxbAln9/jsxKgNK9zEKvEsN3IWRsjY6Gr3R+DDssJr?= =?iso-8859-1?Q?EYrjgI+IYnUWPfQlqT2jwxfNtqOVzPjXL2MnYC6Gplu1F4oIGOuHluaQvv?= =?iso-8859-1?Q?yO2vExdY7cO3LU1g1M+2ruBz2eTcrLuNOt9C0CXVh1WSt3WrmZgpfEPszt?= =?iso-8859-1?Q?5DBORPmdeoOWduRx3Rq8BAxp84SwvuZHZjmXnPBzpFZZBnOWyJJsSc3ghy?= =?iso-8859-1?Q?ZIBoL6YKkfLw62K2hygQPPgvSc1kz0AgOHpDxtQ4ue3Cc+5Hn+em8qSHKR?= =?iso-8859-1?Q?ylZzpi6Ji5JrRoeU35gr94mPEpRxnnEz2n+a4iK+4qdXooNOR2NVlEnG5t?= =?iso-8859-1?Q?iOoRlMayaIiMstek9QO9gTDjAvQZCjgILmsj16ew3pSCn4FT7Kn87hKsj/?= =?iso-8859-1?Q?Gh7mbCbVTCbBwlknZXQDMPMNlQAzeoqVDK/d1RiQjdwBYcT321v+r4ULaa?= =?iso-8859-1?Q?RnRYUrXJEZqq992not2V67Z3Hm/tdlMI7F+XXzwQkBW6t6OjD3fdfiNtT0?= =?iso-8859-1?Q?9aU1oaWqXDZA5lg85I9NVfh6Zn6FXgwzaPOb5XP4hk3DbJj+F5Lr0DCfks?= =?iso-8859-1?Q?LRYaJrTDk7UbXKrKXA274RZB3Dq8xG6TxV+Sz1pmoB6m7PegSIHT71Q/fv?= =?iso-8859-1?Q?wkZI/XKtcN8tcNpGtJwppMHXv3mBIXcyUCk2re8Fk5R/HWVIVJ3+hqQ20l?= =?iso-8859-1?Q?Rkj81gdA7VTMkVw9sJe6d8YdrajqyT21G5eBxNZGe6rp2lTwMMXS52GKSU?= =?iso-8859-1?Q?i8Zt3DEKddo7YAdV0UjYAA/Aylkykix8rrqFunze0DEtVbHR5gMjxwYk4R?= =?iso-8859-1?Q?sysr8O5pi1RC+COP500So76C4ULxdbDpgoIQo3zVay2dEkuoXi/arSXL7C?= =?iso-8859-1?Q?YxmxyHMdtEHcy/LTtWTLA3eQCzF9ctXlwCCLv+wLUAEf9OKVGxfe2C8b8P?= =?iso-8859-1?Q?jNJ/EIRIm51DigHva/1s1KGZCHcoawk564AgRVajA3Xaqm95U1kADcvmCb?= =?iso-8859-1?Q?0qMpSJ9EOheGix2GT0fsVQnt6l7qGP06u8OTnDZN5ZSbP6S8NnMI1wfb+p?= =?iso-8859-1?Q?1GHtd/1Nd0wlFz6H1wqjQLXoHntoxe+Vr84+qOEA5kkoGa+d/ZrCdq4K5S?= =?iso-8859-1?Q?14onvDI/h5rnzgLFzd03YmsdU5Cp1RPvG7lteRwMqGTkU0bGyVROjeNZvW?= =?iso-8859-1?Q?XfYzRr2FEXZYHll6KM8VoxRv0Ww3Njbn3nkwcMCcq0BQh+o8qZ+WCrhuqi?= =?iso-8859-1?Q?Y9LCN3jJLHXLcjqssD5qB9N2SDFH9OaKMDJ4G0s9kB34tMii2DntPBZY1H?= =?iso-8859-1?Q?/lRYn3+FXJJgJQ1KNyeXnC52MeCeshm2OaL0zKrSEGuOp9/eo6IkQrj7ww?= =?iso-8859-1?Q?8bZmqUBb27YptewXmk7qs2QPGHmAQSS/GgQ8JYM2ZHPpMS?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ffcc1843-51a4-4695-301b-08de54d2c0ca X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2026 07:42:08.6967 (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: 0NvxEyi5zHBshaAOAXWXAbBQSCryLobHMOsdgUUfwoShfHReyt7zEFbCpunvxeOaaK/mieyedevBP9fZcMnzng== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8792 [Public] Hi, Tamas, May I ask a review on this commit? Many thanks Penny Zheng > -----Original Message----- > From: Penny, Zheng > Sent: Thursday, January 15, 2026 5:29 PM > To: xen-devel@lists.xenproject.org; Andryuk, Jason > Cc: Huang, Ray ; Penny, Zheng > ; Jan Beulich ; Andrew Cooper > ; Roger Pau Monn=E9 ; > Anthony PERARD ; Orzel, Michal > ; Julien Grall ; Stefano Stabellini > ; Tamas K Lengyel ; Alexandr= u > Isaila ; Petre Pircalabu > Subject: [PATCH v4 6/6] xen/vm_event: consolidate CONFIG_VM_EVENT > > File hvm/vm_event.c and x86/vm_event.c are the extend to vm_event handlin= g > routines, and its compilation shall be guarded by CONFIG_VM_EVENT too. > > Although CONFIG_VM_EVENT is right now forcibly enabled on x86 via > MEM_ACCESS_ALWAYS_ON, we could disable it through disabling > CONFIG_MGMT_HYPERCALLS later. So we remove > MEM_ACCESS_ALWAYS_ON and make VM_EVENT=3Dy on default only on x86 to > retain the same. > > The following functions are developed on the basis of vm event framework,= or only > invoked by vm_event.c, so they all shall be wrapped with CONFIG_VM_EVENT > (otherwise they will become unreachable and violate Misra rule 2.1 when > VM_EVENT=3Dn): > - hvm_toggle_singlestep > - hvm_fast_singlestep > - hvm_emulate_one_vm_event > - > hvmemul_write{,cmpxchg,rep_ins,rep_outs,rep_movs,rep_stos,read_io,write_i= o}_dis > card > And Function vm_event_check_ring() needs stub to pass compilation when > VM_EVENT=3Dn. > > Signed-off-by: Penny Zheng > Acked-by: Jan Beulich > Reviewed-by: Jason Andryuk > --- > As the last commit, plz be commited either in the last, or shall be commi= ted > together with prereq commit 8d708e98ad, 8b4147009f, dbfccb5918, ae931f63a= 0, > 37ec0e2b75. > --- > xen/arch/x86/Makefile | 2 +- > xen/arch/x86/hvm/Kconfig | 1 - > xen/arch/x86/hvm/Makefile | 2 +- > xen/arch/x86/hvm/emulate.c | 58 ++++++++++++++++++++------------------ > xen/arch/x86/hvm/hvm.c | 2 ++ > xen/common/Kconfig | 7 ++--- > xen/include/xen/vm_event.h | 7 +++++ > 7 files changed, 44 insertions(+), 35 deletions(-) > > diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile index > d8b41cec16..5bf3578983 100644 > --- a/xen/arch/x86/Makefile > +++ b/xen/arch/x86/Makefile > @@ -69,7 +69,7 @@ obj-$(CONFIG_INTEL) +=3D tsx.o obj-y +=3D x86_emulate.= o > obj-$(CONFIG_TBOOT) +=3D tboot.o > obj-y +=3D hpet.o > -obj-y +=3D vm_event.o > +obj-$(CONFIG_VM_EVENT) +=3D vm_event.o > obj-y +=3D xstate.o > > ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y) > diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig index > c1a131d185..25eb3e374f 100644 > --- a/xen/arch/x86/hvm/Kconfig > +++ b/xen/arch/x86/hvm/Kconfig > @@ -4,7 +4,6 @@ menuconfig HVM > default !PV_SHIM > select COMPAT > select IOREQ_SERVER > - select MEM_ACCESS_ALWAYS_ON > help > Interfaces to support HVM domains. HVM domains require hardware > virtualisation extensions (e.g. Intel VT-x, AMD SVM), but can boo= t diff --git > a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile index > ee4b45a4ee..f34fb03934 100644 > --- a/xen/arch/x86/hvm/Makefile > +++ b/xen/arch/x86/hvm/Makefile > @@ -26,7 +26,7 @@ obj-y +=3D save.o > obj-y +=3D stdvga.o > obj-y +=3D vioapic.o > obj-y +=3D vlapic.o > -obj-y +=3D vm_event.o > +obj-$(CONFIG_VM_EVENT) +=3D vm_event.o > obj-y +=3D vmsi.o > obj-y +=3D vpic.o > obj-y +=3D vpt.o > diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c inde= x > fe75b0516d..d56ef02baf 100644 > --- a/xen/arch/x86/hvm/emulate.c > +++ b/xen/arch/x86/hvm/emulate.c > @@ -1615,6 +1615,7 @@ static int cf_check hvmemul_blk( > return rc; > } > > +#ifdef CONFIG_VM_EVENT > static int cf_check hvmemul_write_discard( > enum x86_segment seg, > unsigned long offset, > @@ -1717,6 +1718,7 @@ static int cf_check hvmemul_cache_op_discard( { > return X86EMUL_OKAY; > } > +#endif /* CONFIG_VM_EVENT */ > > static int cf_check hvmemul_cmpxchg( > enum x86_segment seg, > @@ -2750,33 +2752,6 @@ static const struct x86_emulate_ops hvm_emulate_op= s > =3D { > .vmfunc =3D hvmemul_vmfunc, > }; > > -static const struct x86_emulate_ops hvm_emulate_ops_no_write =3D { > - .read =3D hvmemul_read, > - .insn_fetch =3D hvmemul_insn_fetch, > - .write =3D hvmemul_write_discard, > - .cmpxchg =3D hvmemul_cmpxchg_discard, > - .rep_ins =3D hvmemul_rep_ins_discard, > - .rep_outs =3D hvmemul_rep_outs_discard, > - .rep_movs =3D hvmemul_rep_movs_discard, > - .rep_stos =3D hvmemul_rep_stos_discard, > - .read_segment =3D hvmemul_read_segment, > - .write_segment =3D hvmemul_write_segment, > - .read_io =3D hvmemul_read_io_discard, > - .write_io =3D hvmemul_write_io_discard, > - .read_cr =3D hvmemul_read_cr, > - .write_cr =3D hvmemul_write_cr, > - .read_xcr =3D hvmemul_read_xcr, > - .write_xcr =3D hvmemul_write_xcr, > - .read_msr =3D hvmemul_read_msr, > - .write_msr =3D hvmemul_write_msr_discard, > - .cache_op =3D hvmemul_cache_op_discard, > - .tlb_op =3D hvmemul_tlb_op, > - .cpuid =3D x86emul_cpuid, > - .get_fpu =3D hvmemul_get_fpu, > - .put_fpu =3D hvmemul_put_fpu, > - .vmfunc =3D hvmemul_vmfunc, > -}; > - > /* > * Note that passing VIO_no_completion into this function serves as kind > * of (but not fully) an "auto select completion" indicator. When there= 's @@ - > 2887,6 +2862,34 @@ int hvm_emulate_one( > return _hvm_emulate_one(hvmemul_ctxt, &hvm_emulate_ops, completion);= } > > +#ifdef CONFIG_VM_EVENT > +static const struct x86_emulate_ops hvm_emulate_ops_no_write =3D { > + .read =3D hvmemul_read, > + .insn_fetch =3D hvmemul_insn_fetch, > + .write =3D hvmemul_write_discard, > + .cmpxchg =3D hvmemul_cmpxchg_discard, > + .rep_ins =3D hvmemul_rep_ins_discard, > + .rep_outs =3D hvmemul_rep_outs_discard, > + .rep_movs =3D hvmemul_rep_movs_discard, > + .rep_stos =3D hvmemul_rep_stos_discard, > + .read_segment =3D hvmemul_read_segment, > + .write_segment =3D hvmemul_write_segment, > + .read_io =3D hvmemul_read_io_discard, > + .write_io =3D hvmemul_write_io_discard, > + .read_cr =3D hvmemul_read_cr, > + .write_cr =3D hvmemul_write_cr, > + .read_xcr =3D hvmemul_read_xcr, > + .write_xcr =3D hvmemul_write_xcr, > + .read_msr =3D hvmemul_read_msr, > + .write_msr =3D hvmemul_write_msr_discard, > + .cache_op =3D hvmemul_cache_op_discard, > + .tlb_op =3D hvmemul_tlb_op, > + .cpuid =3D x86emul_cpuid, > + .get_fpu =3D hvmemul_get_fpu, > + .put_fpu =3D hvmemul_put_fpu, > + .vmfunc =3D hvmemul_vmfunc, > +}; > + > void hvm_emulate_one_vm_event(enum emul_kind kind, unsigned int trapnr, > unsigned int errcode) > { > @@ -2949,6 +2952,7 @@ void hvm_emulate_one_vm_event(enum emul_kind > kind, unsigned int trapnr, > > hvm_emulate_writeback(&ctx); > } > +#endif /* CONFIG_VM_EVENT */ > > void hvm_emulate_init_once( > struct hvm_emulate_ctxt *hvmemul_ctxt, diff --git a/xen/arch/x86/hvm= /hvm.c > b/xen/arch/x86/hvm/hvm.c index b34cd29629..4d37a93c57 100644 > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -5250,6 +5250,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)); > @@ -5276,6 +5277,7 @@ void hvm_fast_singlestep(struct vcpu *v, uint16_t > p2midx) > v->arch.hvm.fast_single_step.p2midx =3D p2midx; } #endif > +#endif /* CONFIG_VM_EVENT */ > > /* > * Segment caches in VMCB/VMCS are inconsistent about which bits are che= cked, > diff --git a/xen/common/Kconfig b/xen/common/Kconfig index > 38320b248a..d7e79e752a 100644 > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -173,13 +173,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= diff -- > git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h index > 27d0c74216..1b76ce632e 100644 > --- a/xen/include/xen/vm_event.h > +++ b/xen/include/xen/vm_event.h > @@ -51,7 +51,14 @@ struct vm_event_domain }; > > /* Returns whether a ring has been set up */ > +#ifdef CONFIG_VM_EVENT > bool vm_event_check_ring(struct vm_event_domain *ved); > +#else > +static inline bool vm_event_check_ring(struct vm_event_domain *ved) { > + return false; > +} > +#endif /* CONFIG_VM_EVENT */ > > /* Returns 0 on success, -ENOSYS if there is no ring, -EBUSY if there is= no > * available space and the caller is a foreign domain. If the guest itse= lf > -- > 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Jan 16 07:44:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 07:44:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206264.1519927 (Exim 4.92) (envelope-from ) id 1vgeVe-0006y4-SB; Fri, 16 Jan 2026 07:44:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206264.1519927; Fri, 16 Jan 2026 07: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 1vgeVe-0006xx-PT; Fri, 16 Jan 2026 07:44:42 +0000 Received: by outflank-mailman (input) for mailman id 1206264; Fri, 16 Jan 2026 07:44: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 1vgeVe-0006xr-4s for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 07:44:42 +0000 Received: from CH4PR04CU002.outbound.protection.outlook.com (mail-northcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c105::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 36ee59fc-f2af-11f0-b15e-2bf370ae4941; Fri, 16 Jan 2026 08:44:40 +0100 (CET) Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by SN7PR12MB8792.namprd12.prod.outlook.com (2603:10b6:806:341::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.6; Fri, 16 Jan 2026 07:44:37 +0000 Received: from DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::6d8e:2499:8a0a:7eb2]) by DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::6d8e:2499:8a0a:7eb2%2]) with mapi id 15.20.9520.005; Fri, 16 Jan 2026 07:44: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: 36ee59fc-f2af-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=f3QCkdot+IMRDqd5PQhJUq7IIOMDQ/Vd68CzeQoeXoWjibOuxnZMsyxL7yzYbrp6r8gi6bIv8OJK9PEQTKtGS3sd0b/BXDSzSqS+taYUznfi4LwNnbxQQRVAPuAgScnwcJAdjTTWGxweEF1RfRes3w9HcTsEwsFE0RGrzVbJy2ADkPxPvM7nsLGD9a4cEn1aNY90v4AKGJLIieHAeQJnfJ4oP8KTRrio/p3mye7R/uPKLS/owwzzC4OYU6ZUEWm66xYBALzkqBCc02jNfi5Dj8g9BeJKmEpuapXCduR1t+692Pm3O3TQgUye+Y3D5Sxud20UbDvodZBgOa2BqLbSvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=O0qMULjR5iUcnvMlfl+mMRmygHqA3d8qIBtZu1FHGgg=; b=xRYW1N0qBdLfnKgtxYMeS/iNF7Q+sAZk+qQ/4Obv886pMeZpvo5w8h2UwZqNvJ0qi6dtzXgHUUDFKnCq6NMXGCIiieuCTAtVDoORFDx3hRVInEKQvpFt1x4D9ui5n3bSAlnBotDG0/iQXB33H6mXIlloCS2zgvf12ocPAcbYeyTvVBgthJojhB0TixZWJd6DLTLq0WnVcmxbG3y1GtN6Lsgd1MOLyshZHHTqNe3MgxmWYtXI9PE9DW+6NJk0caWzI0bpapz3MLOgTxLVtgGXHaCifdZW5yZmmCXm30ed/Ys1F49W0J5Rz95KQ/6gn0B6nyt7MwFN4itdHasBUK1ySg== 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=O0qMULjR5iUcnvMlfl+mMRmygHqA3d8qIBtZu1FHGgg=; b=nb/cq53KBKW2C4zInejNn6iqokhkV8Xxnmg6SuMo6VPg7qXpWgPTpnpnxWI3ueKG7PpqFmArYIAuuDSnJ71SqDXDoy2Iquu3BgFIYFB2IRHMLUEHeJyIt4NIGOJ9mRP2qb1A5rtG32UOnMk7EITWbJb/y361IRDBYkqf/tSSDEI= From: "Penny, Zheng" To: "xen-devel@lists.xenproject.org" , Tamas K Lengyel Subject: RE: [PATCH v4 5/6] xen/mem_access: wrap memory access when VM_EVENT=n Thread-Topic: [PATCH v4 5/6] xen/mem_access: wrap memory access when VM_EVENT=n Thread-Index: AQHchgFz7GhZy9MFSkqKuUrhU5ZbzrVUa57Q Date: Fri, 16 Jan 2026 07:44:37 +0000 Message-ID: References: <20260115092841.2651224-1-Penny.Zheng@amd.com> <20260115092841.2651224-6-Penny.Zheng@amd.com> In-Reply-To: <20260115092841.2651224-6-Penny.Zheng@amd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2026-01-16T07:44: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: DM4PR12MB8451:EE_|SN7PR12MB8792:EE_ x-ms-office365-filtering-correlation-id: e454ba37-e391-41dd-a8c4-08de54d3194e x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700021|7053199007; x-microsoft-antispam-message-info: =?iso-8859-1?Q?WYF+35spRsgV/l7VWihpVWlkdKF28CHVX0Txq7fph0vaPn2dylUcGAbmqj?= =?iso-8859-1?Q?+U+z7jDEAqMhvPAxakU2LBO5bYPYn10BnTRlCWzTF0rl/dw7JfKvg5vtpB?= =?iso-8859-1?Q?ZSCGJiOhxd4qPBVpuDM1LBkz/tDCyIjjXfbCdQ4BkJfLVx2dNGbDoaVWcz?= =?iso-8859-1?Q?UvqBnXBf4gE3qBK/ZVEvy254/tZmsvhw7V4EfdJG/L04vgGLmCahsRpZ9z?= =?iso-8859-1?Q?Gb3suiR3IAloEyeWAkEjOlOjNhXsrfceLhD3wjW80jZNMhEvW3T4mKg3Ev?= =?iso-8859-1?Q?HhTjOhUpAotREd2Cld1jyrRxtbOl8Iz0h8ygqYTsD3pLZWt/L7k6Fj+5cs?= =?iso-8859-1?Q?+kYsg7Bc9Qd94Ay0exkVLa/XFuvbpNEW8wWGwse+Vs/8qGrDTYgwVtgzDj?= =?iso-8859-1?Q?9naeMqbMynDiRSLetdewUKz+Y00uBHRysW3hPB0E5JFyUOMagH2iWdBt4y?= =?iso-8859-1?Q?rasiWHF9jLyLS+RzYPvYlZNwpajJIkQou8IcHYYgEmauEt08aJYLGH312Y?= =?iso-8859-1?Q?KxD8QvHcE7HIrKgxcHF4NdU8f6BExKlv1dDNwmQmsR8NqGfeuvw4F+goBy?= =?iso-8859-1?Q?UBD8sUdqKkK8K9Q8sU8Jr3jds5L+UHHe6s7bgh+MO1ASnOR7y1E4DSVH51?= =?iso-8859-1?Q?rlo0xiknYWaugwDy8TxyC4hFU4s2YzMNvHrnYcqJDaAs3gJkzAxK+ihP3m?= =?iso-8859-1?Q?BKG3nL9fPJVqBr1eohyhl6rKDNqn3e7YU6OwyQmG+9jqtd1lsP/xMCSife?= =?iso-8859-1?Q?mPL8K7ju/9/kaflaIpqopPpvW9KXXL2IMsxhzgRQWB/wR0KwMVQB2NZg9G?= =?iso-8859-1?Q?mezjOmaP3A1ru0I8Paut9AI2OpZVkF47TubB6iguv+SwUQGBJEFOO09syV?= =?iso-8859-1?Q?0ZnXM470wMLjKRljAF7eAe3nXYg10DzKHRkU46E+sbMS8Hq1MwSo3hgaKd?= =?iso-8859-1?Q?+qxV2zWMoEXtmZ4z5LC+aJrQiIWuT/+wq2vBrgUGPEg86qkpME2QEwoH6Q?= =?iso-8859-1?Q?ie//fbphOo0s/OrFwncMBXelwTa6I5baP6cZivMpsHtwc95tJR/GAAg3CZ?= =?iso-8859-1?Q?Tf9MXXIfHIMORo08cEiIjlIyNFrd+KsM9wLjHokhnJN19C9NrTJAAHS68k?= =?iso-8859-1?Q?V1T47Gwazx/y5hyZJrjsl2EKcN9wNyOKoZjARD3CDRSjss2RbQClhPwve9?= =?iso-8859-1?Q?w777h9wmt1BrpDk0PcjS/FFvDaR68Xhh+Vci0RdOMne+IPZY+xDlP5ePlm?= =?iso-8859-1?Q?CVc11oGFNWl14n2HoKKSmvgwXvRnUlod0P7I/fiDoLadBZltifYgen2GUN?= =?iso-8859-1?Q?eE18Pi4Y1b3Z5Gvd31nOL6fXeKwbeqFWEwXKJ9dPbO0sUQhRRMQJs5IYye?= =?iso-8859-1?Q?MJ76Qejrf8Etganj/IVa4+svigJrmZk5opxUdEcYeqKpKw2//dYjsw7IgL?= =?iso-8859-1?Q?xcBs8rCD+8KQdGDamyQQ0NKZPVFioSrJT9k10BholN3JMmANcWGf50xTly?= =?iso-8859-1?Q?CahJJcsI8olXO5FdeT0+dVbnBEBYEPq9lBfDHiTMKp0ZylwERyxFSd1i+O?= =?iso-8859-1?Q?vXrSiu+NcLXH77CgfrDYn9xhKUXtqNcjCPNMdhR5sVDfcwaJuYhFssEw41?= =?iso-8859-1?Q?aKGf7XtsUnMOFiq3H1/oLOQfchMgy9D/TMdbWalnH/kGKbH6Tg+iSRN+87?= =?iso-8859-1?Q?lfryCLgHnn+25W/+sQU=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)(7053199007);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?2El+j3KA4f1InO1XGt9T1BaUOceDKbGFlUCAK7WmztQHddXtXYHRiYoUHo?= =?iso-8859-1?Q?K0DMdNp9DAGrg6rTq8ZCQb47X1UXUu3ZIFIOnBmMx56cC4wmmlYpleavHf?= =?iso-8859-1?Q?sDUz8NDMR+kufdNXJcW7awX9qAQ0qZo8gZCGNIzX05Nj6r08olEQwSozFc?= =?iso-8859-1?Q?zDOYzGia7e5VXkJ5gkNLLGL+J036xyxDGpMieEE7Z0k+2X9V2w7Xhnd6GO?= =?iso-8859-1?Q?C7yn0iH0eOnP6xkdxfAD0j16MJcD5OfPrsc7cH1GC+dqS+6TiFWJE5RJKB?= =?iso-8859-1?Q?Oy9i3wZEpxGYx68niwYGs0oe3bFuQsFlqHcMkyFT1b0ar8G3jsRFjNo/K2?= =?iso-8859-1?Q?pYKYLjn0G5pdFjOwCn2mTUBf7bV+pVGPcp8o9Kn+y3B4Fx7P2XoMXAlWDk?= =?iso-8859-1?Q?8tqfD/UMmuOFtvFSnVV8PUCQjlt/ini9qbTghdrBRU2Lm7TjLhPb7/zzSz?= =?iso-8859-1?Q?QET7Z2r8sTqHev09zzH8E3mAeJriKHV2CGHOFZV1SQBXlIuxEBtkVFGceT?= =?iso-8859-1?Q?Mx+7K/BN/RJt6o+ErcsoTONBXAgkDxRrQlYsBdpPUDSFpS08+rQsRC5VZv?= =?iso-8859-1?Q?0ON6cedgh89G6hzJGQVwxKL0QlJi2Hrqs2uw9RkFeOMTSYhJ8oRV0LvVmg?= =?iso-8859-1?Q?pcnikzLCWIS+fzEc/waYjaxlm1+JK9ioOD/b2yA4LvFeHvWyhrCJcrj/Zs?= =?iso-8859-1?Q?vAwOnH+B61GeUlXCpxN9cSCLQWynFWfCHicUXt57NphBm78vsvTOpri1yB?= =?iso-8859-1?Q?zFcw+tW9x4Ttn9NDBTLC8et5LlNE/HMwAGArELawm/lz05EcNyk8MX53Br?= =?iso-8859-1?Q?dK8XqPV7cEmDPohdQP1lc/ugbgeFtUWK8US9bpPDp52aDsr3UQWedJKAbY?= =?iso-8859-1?Q?XKaRbr6KP54GV3pYk0RT5gOYG+gN3EHmW/kHpH8/TgibI1QGDFF146OWfz?= =?iso-8859-1?Q?DpW7MtYVf6I/qs5lAyuKuY/lFVOm0V0vqYmv6fUfaCZ/8gkVSHeDpTZ5JL?= =?iso-8859-1?Q?PEZGa9iViM7jtKTBFKOmunyA6o25S94UD4amSp9Ge1+dqbLVpPE/NhQCeq?= =?iso-8859-1?Q?EhGTwtnCfurw8UgX6LOIJV0danPlz40Pa/f/ArOQ+swB5EOOU+lw+4egK9?= =?iso-8859-1?Q?n20OgMqmYj6dO6eNRtEdrg708LyWmtLITwwWXpqnO4KBw+8qa2npABuO1f?= =?iso-8859-1?Q?pf+6BLjV4cj4hYTdKXi/1WO3gkRsCYY0jdKxtNn9N7xyckebWAka2sx2ZX?= =?iso-8859-1?Q?7n9HC63X/hMxJYBbe+KRvrmDOcADBC1rhLx4skqR36gVzOWah3MQDXc3rE?= =?iso-8859-1?Q?WmV+UBHOa2Z93KFer3Yfy4IT0bV5x8A/XHlVoPmt/bSVyoDkrVBTkojDEN?= =?iso-8859-1?Q?z/lDZjl42880PfvwGrDuVWXc0dScDzzi4pBm/iEd+JO0rsyM9MHUj5Bl+i?= =?iso-8859-1?Q?lbnl9Q+rxb267qs/z8wfhRPtl2uvtayekx8YO2zhrMbJek205nzwKNyVKs?= =?iso-8859-1?Q?bkofkRBagQOse0wOa3AZHv6wmS1WWRjpH+bcWJjezqPFH2ULEvKJcKeCEv?= =?iso-8859-1?Q?AaRdRGF4/S+nJZNOl+QttITeEB6t4eqIz1kyyDb2A2+lMaBgQ7vpzcwRfN?= =?iso-8859-1?Q?TGgBseKOFLEvAjio2nHf//PXrSNMWmEzTDa0ytYWLDLiIf3OjXRAJ3VCEN?= =?iso-8859-1?Q?fgUCuckbTvQglFn7jEcXCVOR5pmAfCeiL1Pbj1gTjQshQrd9O44671IdA/?= =?iso-8859-1?Q?X+KhmcYCyyJlCVZOOLwj2iepknVMojmMzSAlVx1tMajAfU?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB8451.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e454ba37-e391-41dd-a8c4-08de54d3194e X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2026 07:44:37.2395 (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: vIa7ZPcrYP25LGsVzUvbR+iw/2t1Cj9RUZGXTza5Jn1UWYsUr6RrWLjZPbsMp5Kz4mkX7ubTt2LL9a2GsaDgig== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8792 [Public] Hi, Tamas May I ask a review on this commit? Many thanks, Penny Zheng > -----Original Message----- > From: Penny, Zheng > Sent: Thursday, January 15, 2026 5:29 PM > To: xen-devel@lists.xenproject.org; Andryuk, Jason > Cc: Huang, Ray ; Penny, Zheng > ; Jan Beulich ; Andrew Cooper > ; Roger Pau Monn=E9 ; Ta= mas > K Lengyel ; Alexandru Isaila ; > Petre Pircalabu > Subject: [PATCH v4 5/6] xen/mem_access: wrap memory access when > VM_EVENT=3Dn > > Feature memory access is based on vm event subsystem, and it could be dis= abled > in the future. So a few switch-blocks in do_altp2m_op() need > vm_event_is_enabled() condition check to pass compilation when ALTP2M=3Dy= and > VM_EVENT=3Dn(, hence MEM_ACCESS=3Dn), like > HVMOP_altp2m_set_mem_access, etc. > Function p2m_mem_access_check() still needs stub when VM_EVENT=3Dn to pas= s > compilation. > Although local variable "req_ptr" still remains NULL throughout its lifet= ime, with the > change of NULL assignment, we will face runtime undefined error only when > CONFIG_USBAN is on. So we strengthen the condition check via adding > vm_event_is_enabled() for the special case. > > Signed-off-by: Penny Zheng > Acked-by: Jan Beulich > --- > v1 -> v3: > - a comment next to the excessive condition > - use vm_event_is_enabled() instead > - avoid heavy churn by using the inverted condition plus break > --- > v3 - v4: > - refine comment > --- > xen/arch/x86/hvm/hvm.c | 26 +++++++++++++++++++++++++- > xen/arch/x86/include/asm/mem_access.h | 10 ++++++++++ > 2 files changed, 35 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index > 07e54890d9..b34cd29629 100644 > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -52,6 +52,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -2082,7 +2083,12 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigne= d > long gla, #endif > } > > - if ( req_ptr ) > + /* > + * req_ptr being constant NULL when !CONFIG_VM_EVENT, > CONFIG_UBSAN=3Dy > + * builds have been observed to still hit undefined-ness at runtime. > + * Hence do a seemingly redundant vm_event_is_enabled() check here. > + */ > + if ( req_ptr && vm_event_is_enabled(curr) ) > { > if ( monitor_traps(curr, sync, req_ptr) < 0 ) > rc =3D 0; > @@ -4804,6 +4810,12 @@ static int do_altp2m_op( > break; > > case HVMOP_altp2m_set_mem_access: > + if ( !vm_event_is_enabled(current) ) > + { > + rc =3D -EOPNOTSUPP; > + break; > + } > + > if ( a.u.mem_access.pad ) > rc =3D -EINVAL; > else > @@ -4813,6 +4825,12 @@ static int do_altp2m_op( > break; > > case HVMOP_altp2m_set_mem_access_multi: > + if ( !vm_event_is_enabled(current) ) > + { > + rc =3D -EOPNOTSUPP; > + break; > + } > + > if ( a.u.set_mem_access_multi.pad || > a.u.set_mem_access_multi.opaque > a.u.set_mem_access_multi.= nr ) > { > @@ -4844,6 +4862,12 @@ static int do_altp2m_op( > break; > > case HVMOP_altp2m_get_mem_access: > + if ( !vm_event_is_enabled(current) ) > + { > + rc =3D -EOPNOTSUPP; > + break; > + } > + > if ( a.u.mem_access.pad ) > rc =3D -EINVAL; > else > diff --git a/xen/arch/x86/include/asm/mem_access.h > b/xen/arch/x86/include/asm/mem_access.h > index 257ed33de1..790bed81e8 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 avail= able). > * Handles the rw2rx conversion. Boolean return value indicates if event= type @@ - > 25,6 +26,15 @@ 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) { > + *req_ptr =3D NULL; > + return false; > +} > +#endif /* CONFIG_VM_EVENT */ > > /* Check for emulation and mark vcpu for skipping one instruction > * upon rescheduling if required. */ > -- > 2.34.1 From xen-devel-bounces@lists.xenproject.org Fri Jan 16 10:32:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 10:32:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206391.1519992 (Exim 4.92) (envelope-from ) id 1vgh82-0002bc-1N; Fri, 16 Jan 2026 10:32:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206391.1519992; Fri, 16 Jan 2026 10:32:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgh81-0002bV-UQ; Fri, 16 Jan 2026 10:32:29 +0000 Received: by outflank-mailman (input) for mailman id 1206391; Fri, 16 Jan 2026 10:32:29 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgh80-0002bO-TB for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 10:32:29 +0000 Received: from mail187-33.suw11.mandrillapp.com (mail187-33.suw11.mandrillapp.com [198.2.187.33]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a6bfe935-f2c6-11f0-b15e-2bf370ae4941; Fri, 16 Jan 2026 11:32:27 +0100 (CET) Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail187-33.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4dsx4T5BMZzBsVCKp for ; Fri, 16 Jan 2026 10:32:25 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id dc61bcb81ca541428aef09e9b6c10ee6; Fri, 16 Jan 2026 10:32: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: a6bfe935-f2c6-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1768559545; x=1768829545; bh=sToY2ZIn3wQPkHhsh7FyPZGR9xNobzoQklK0nB2Hxnk=; 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=FC6a5MsNrQHcAo5r4r8zKtMC7riDdgLLuSgI3OjFoDBxNtDp7r90j3GaHsz5quHmw rtI5Oqkm1801OTJy3sbcKjqXTfLeyHu1EixsHQbQe16uC5ikO6mezC2ovRScmtGb9J NsGbd76tDe/8+kRMR8/OoOANNM6g+2baCDdqJEeWLEEe9KOL4/Z4ZmnMOTmCmTvlfE 4H/TFCND9uRvH1qsB582Ag4lvNmXso1Cchey2fvbAh5x1KLJWSTFHqM+cZE31gUBrl fXKwFxQuGQqYZQOlAj5vwha4+05l+VKW0MW4Kpwh4P/BUAvHAh/uAI5u7KQoy5qDCR iXVFE3OpVaPDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1768559545; x=1768820045; i=teddy.astie@vates.tech; bh=sToY2ZIn3wQPkHhsh7FyPZGR9xNobzoQklK0nB2Hxnk=; 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=zDiB1lKZfA8BSsIP9qZNYSLVmN8rJKqUAEAx43npyL1iUAYyRF3xFfBqLSUBw/KDi gyWhLt+TZhB6JFeN9lk8EBDIhvvvy4bLXt7jNx9ZrplcIPNgkuEVt3vTBwFUT//AnT BoU1UMxBYZWcyDk1HO2LmQY5QkHAMDbv3uhB9QZOKY7TaeD86dGBA9jcq0ZLox6Owu 2/SYOZbVaVHxMFhFr9CPpBpSevFvmNWrrVAQsY4f3laHlDLVDSMZmczfnkaFUG4xb9 SKUC2r551xD2O/CREIGJqPGW8qwdKj/cPs/gdV+wdRloIi8DMo/zPQ1Rxm9a/kO2Gy T5/Z+ZFlPCMkw== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=20v5=202/2]=20xenpm:=20Add=20get-intel-temp=20subcommand?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1768559544976 Message-Id: To: "Jan Beulich" Cc: "Oleksii Kurochko" , "Community Manager" , "Anthony PERARD" , xen-devel@lists.xenproject.org References: <7dfa012b734f3c769da88f0f1c989d07b724bdaa.1768235932.git.teddy.astie@vates.tech> <7ae6ca6f93e81cb0b5a71db90913dc3f67e6b763.1768235932.git.teddy.astie@vates.tech> <664b6639-732d-4e43-8323-47333b0d8e4c@suse.com> In-Reply-To: <664b6639-732d-4e43-8323-47333b0d8e4c@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.dc61bcb81ca541428aef09e9b6c10ee6?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260116:md Date: Fri, 16 Jan 2026 10:32:25 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 14/01/2026 =C3=A0 10:27, Jan Beulich a =C3=A9crit=C2=A0: > On 12.01.2026 17:47, Teddy Astie wrote: >> @@ -1354,6 +1358,115 @@ void enable_turbo_mode(int argc, char *argv[]) >> errno, strerror(errno)); >> } >> >> +static int fetch_dts_temp(xc_interface *xch, uint32_t cpu, bool package= , int *temp) >> +{ >> + xc_resource_entry_t entries[] =3D { >> + { .idx =3D package ? MSR_PACKAGE_THERM_STATUS : MSR_IA32_THERM_= STATUS }, >> + { .idx =3D MSR_TEMPERATURE_TARGET }, >> + }; >> + struct xc_resource_op ops =3D { >> + .cpu =3D cpu, >> + .entries =3D entries, >> + .nr_entries =3D ARRAY_SIZE(entries), >> + }; >> + int tjmax; >> + >> + int ret =3D xc_resource_op(xch, 1, &ops); >> + >> + switch ( ret ) >> + { >> + case -1: >> + /* xc_resource_op returns -1 in out of memory scenarios */ >> + return -ENOMEM; > > Assuming xc_resource_op() is well-behaved in this regard, why not return = errno > here? Or yet better stick to -1, leaving it to the caller to consume errn= o? And > then ... > >> + case 0: >> + /* This CPU isn't online or can't query this MSR */ >> + return -ENODATA; > > ... set errno here and return -1? With this normalized here, ... > >> + case 1: >> + { >> + /* >> + * The CPU doesn't support MSR_TEMPERATURE_TARGET, we assume it= 's 100 >> + * which is correct aside a few selected Atom CPUs. Check Linux >> + * kernel's coretemp.c for more information. >> + */ >> + static bool has_reported_once =3D false; >> + >> + if ( !has_reported_once ) >> + { >> + fprintf(stderr, "MSR_TEMPERATURE_TARGET is not supported, a= ssume " >> + "tjmax =3D 100, readings may be incorrect.\= n"); >> + has_reported_once =3D true; >> + } >> + >> + tjmax =3D 100; >> + break; >> + } >> + >> + case 2: >> + tjmax =3D (entries[1].val >> 16) & 0xff; >> + break; >> + >> + default: >> + if ( ret > 0 ) >> + { >> + fprintf(stderr, "Got unexpected xc_resource_op return value= : %d", >> + ret); >> + return -EINVAL; >> + } >> + return ret; >> + } >> + >> + *temp =3D tjmax - ((entries[0].val >> 16) & 0xff); >> + return 0; >> +} >> + >> +static void get_intel_temp(int argc, char *argv[]) >> +{ >> + int temp =3D -1, cpu =3D -1; >> + unsigned int socket; >> + bool has_data =3D false; >> + >> + if ( argc > 0 ) >> + parse_cpuid(argv[0], &cpu); >> + >> + if ( cpu !=3D -1 ) >> + { >> + if ( !fetch_dts_temp(xc_handle, cpu, false, &temp) ) >> + printf("CPU%d: %d=C2=B0C\n", cpu, temp); >> + else >> + printf("No data\n"); > > ... you can then use perror() here (and perhaps elsewhere). Right now the > distinct non-zero return values of fetch_dts_temp() are of no interest to > any of the callers. > > Jan > I did some changes in that regard, and unified the code style for the socket and core parts. diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c index d20a213c71..de490b6507 100644 --- a/tools/misc/xenpm.c +++ b/tools/misc/xenpm.c @@ -1377,11 +1377,13 @@ static int fetch_dts_temp(xc_interface *xch, uint32_t cpu, bool package, int *te { case -1: /* xc_resource_op returns -1 in out of memory scenarios */ - return -ENOMEM; + errno =3D -ENOMEM; + return -1; case 0: /* This CPU isn't online or can't query this MSR */ - return -ENODATA; + errno =3D -ENODATA; + return -1; case 1: { @@ -1410,11 +1412,12 @@ static int fetch_dts_temp(xc_interface *xch, uint32_t cpu, bool package, int *te default: if ( ret > 0 ) { - fprintf(stderr, "Got unexpected xc_resource_op return value: %d", - ret); - return -EINVAL; + fprintf(stderr, "Got unexpected xc_resource_op return value: %d", ret); + errno =3D -EINVAL; } - return ret; + else + errno =3D ret; + return -1; } *temp =3D tjmax - ((entries[0].val >> 16) & 0xff); @@ -1435,7 +1438,11 @@ static void get_intel_temp(int argc, char *argv[]) if ( !fetch_dts_temp(xc_handle, cpu, false, &temp) ) printf("CPU%d: %d=C2=B0C\n", cpu, temp); else + { + fprintf(stderr, "Unable to fetch temperature (%d - %s)\n", + errno, strerror(errno)); printf("No data\n"); + } return; } @@ -1443,11 +1450,16 @@ static void get_intel_temp(int argc, char *argv[]) for ( socket =3D 0, cpu =3D 0; cpu < max_cpu_nr; socket++, cpu +=3D physinfo.cores_per_socket * physinfo.threads_per_core ) { - if ( !fetch_dts_temp(xc_handle, cpu, true, &temp) ) + if ( fetch_dts_temp(xc_handle, cpu, true, &temp) ) { - has_data =3D true; - printf("Package%u: %d=C2=B0C\n", socket, temp); + fprintf(stderr, + "[Package%u] Unable to fetch temperature (%d - %s)\n", + cpu, errno, strerror(errno)); + continue; } + + has_data =3D true; + printf("Package%u: %d=C2=B0C\n", socket, temp); } if ( has_data ) @@ -1457,7 +1469,11 @@ static void get_intel_temp(int argc, char *argv[]) for ( cpu =3D 0; cpu < max_cpu_nr; cpu +=3D physinfo.threads_per_core= ) { if ( fetch_dts_temp(xc_handle, cpu, false, &temp) ) + { + fprintf(stderr, "[CPU%d] Unable to fetch temperature (%d - %s)\n", + cpu, errno, strerror(errno)); continue; + } has_data =3D true; printf("CPU%d: %d=C2=B0C\n", cpu, temp); It can be quite verbose on the stderr side, but at least report errors. -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Fri Jan 16 10:52:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 10:52:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206418.1520003 (Exim 4.92) (envelope-from ) id 1vghRi-0005N1-Lv; Fri, 16 Jan 2026 10:52:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206418.1520003; Fri, 16 Jan 2026 10:52:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vghRi-0005Mu-IX; Fri, 16 Jan 2026 10:52:50 +0000 Received: by outflank-mailman (input) for mailman id 1206418; Fri, 16 Jan 2026 10:52: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 1vghRh-0005Mn-Aw for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 10:52: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 7d1d6c1c-f2c9-11f0-9ccf-f158ae23cfc8; Fri, 16 Jan 2026 11:52:46 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-4801ea9bafdso2413325e9.3 for ; Fri, 16 Jan 2026 02:52:45 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435699271easm4454843f8f.14.2026.01.16.02.52.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Jan 2026 02:52:44 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7d1d6c1c-f2c9-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768560764; x=1769165564; 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=XA4sDXX2gIlKk6nQgwb2ZVwBL0/C4PuwImesDY0dvQE=; b=Nd+4jJ3elFUlPsZy78hgNEf8Mgm1ofXldP6J3dDTAaclo/VCgi/osfbe59rjtoz1CK hULGcKiyKxvl2rPqj0GgE49uJhcxMysfyOjWtI27IaY0IAKOFgbAfu6A9OSjKYWiYwS/ 1ptjtCq+vAuhImkk8H+k81FdWfOJgfFqMQUTMpBvviDgWQoelaglikUEKhFoPzqoGZZS Vz2xcEqI5M9tqxqGcytt6nqe/JxJUDDvt0cRknHV5iRjwHJINeTzhQWnACcjz8AdCg+K fSVW6W3EFnKVUAcYLCvmHN/Ewa7xPYrhKoApIbBMmT+oD2Cv8NfEL3f0bzIQg5wGl2Vc L40g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768560764; x=1769165564; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XA4sDXX2gIlKk6nQgwb2ZVwBL0/C4PuwImesDY0dvQE=; b=QiIjzpGaxfGDQiS9xXeE9P+Ind54yAwGLJ2H8AuLuRWpYXKRUnY8H9GFdg3MgTMKx5 JlJNXyrgbpD7v4NA6uDqv6marjyglrGgJBoqFpqfskeeG3WSLpGdlKpSghPcUEiTQM24 HpcDqXaohQX2sb6Oy7H2QT84wDH08jnSGQPEPHGZspQp79Jnh7dkxHgIyxomayMyUNM7 oKuwdqckFl1qdev9g1/anOALMAzcVO9EmgB28CUS+R4GnfdNlFp3reaNMUovL6Yz4VnU Ldu9jJKHULIsDq2T7rYsG86XPZAlS09xvSJVthAPcbM/MUYtWrmORbytpv5ECXNoFUn+ yvCQ== X-Gm-Message-State: AOJu0YxXPWiO7isDijLE4mjoo7XzveyQh+3Mk1O+qyXeMpmda5s+jk5s fH504yv2sFHCpGiQmi5Imww2ZwujwP37+st7m+SyiNu2DVOR/1cI2BNj08y6RGPhEpbFGHyAT+G KbC0= X-Gm-Gg: AY/fxX6M3mj9z2yT3KCNZ/exlXPJSyv3qKoHKxdZompsypKIdPO7dcbJj1jjtTnWurQ PLIcYDmjUCPnLvRz7eoPZWywgCO/1nBb8fsMGh0U0XKzD6D7B1slfnMRWI4Umkwtv+C19Hgs/1o xUW6aSw2OY7doy6z3GJBXOxOeC2zG4ID+KvzkOnyBW7+jY1Z2VjBFOjREuTdbtoxgDIJCRY43O4 29c3wg/05MwSR5FK7G+Ucliy10Y3xSAHTWEjYqV3xfhbjTK4C4lWFxhh72HMFJCFSG2OTt+2LZs L6wNny9Wja2LEKAb7/FNIGScpFx1XZ1zEvOcZfdLkPhbt9/N9aNBT5znZdSQwOIFwa3JHRjan07 jmbKidA5ehLY6JUcs0w/f+lj+L35tPmg9uah88F/urzechKb7F+artIK5313fnOtgd2ctqxVpeU QYNXUa16zT+zz4hKdCJW7xL2rzFYu0cgspE1yUbUCgFE0qNDF8y1lj4/nPTM6iFb6yp2xG4GNJg zg= X-Received: by 2002:a05:600c:4745:b0:479:2f95:5179 with SMTP id 5b1f17b1804b1-4801e30fae9mr33450515e9.15.1768560764294; Fri, 16 Jan 2026 02:52:44 -0800 (PST) Message-ID: Date: Fri, 16 Jan 2026 11:52:42 +0100 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?= , Bertrand Marquis , Volodymyr Babchuk , Oleksii Kurochko , Timothy Pearson , Mykola Kvach From: Jan Beulich Subject: [PATCH] build/non-x86: fix symbol lookup in presence of build-id Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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 clear why only x86 had $(build_id_linker) applied to all three linking passes. Not doing so will alter symbol offsets between the 2nd and 3rd passes for, potentially, all of the symbols at higher addresses (intermediate alignment padding may mask this effect, though, so it will look as if problems appeared randomly). Fixes: a353cab905af ("build_id: Provide ld-embedded build-ids") Reported-by: Mykola Kvach Signed-off-by: Jan Beulich --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -87,13 +87,13 @@ endif $(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds $(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S $(MAKE) $(build)=$(@D) $(dot-target).0.o - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< \ + $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ $(dot-target).0.o -o $(dot-target).0 $(NM) -pa --format=sysv $(dot-target).0 \ | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ > $(dot-target).1.S $(MAKE) $(build)=$(@D) $(dot-target).1.o - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< \ + $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ $(dot-target).1.o -o $(dot-target).1 $(NM) -pa --format=sysv $(dot-target).1 \ | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ --- a/xen/arch/ppc/Makefile +++ b/xen/arch/ppc/Makefile @@ -14,13 +14,13 @@ $(TARGET): $(TARGET)-syms $(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds $(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S $(MAKE) $(build)=$(@D) $(dot-target).0.o - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< \ + $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ $(dot-target).0.o -o $(dot-target).0 $(NM) -pa --format=sysv $(dot-target).0 \ | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ > $(dot-target).1.S $(MAKE) $(build)=$(@D) $(dot-target).1.o - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< \ + $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ $(dot-target).1.o -o $(dot-target).1 $(NM) -pa --format=sysv $(dot-target).1 \ | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ --- a/xen/arch/riscv/Makefile +++ b/xen/arch/riscv/Makefile @@ -28,13 +28,13 @@ $(TARGET): $(TARGET)-syms $(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds $(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S $(MAKE) $(build)=$(@D) $(dot-target).0.o - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< \ + $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ $(dot-target).0.o -o $(dot-target).0 $(NM) -pa --format=sysv $(dot-target).0 \ | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ > $(dot-target).1.S $(MAKE) $(build)=$(@D) $(dot-target).1.o - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< \ + $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ $(dot-target).1.o -o $(dot-target).1 $(NM) -pa --format=sysv $(dot-target).1 \ | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ From xen-devel-bounces@lists.xenproject.org Fri Jan 16 11:17:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 11:17:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206459.1520012 (Exim 4.92) (envelope-from ) id 1vghp4-0008Ow-IQ; Fri, 16 Jan 2026 11:16:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206459.1520012; Fri, 16 Jan 2026 11:16:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vghp4-0008Op-FS; Fri, 16 Jan 2026 11:16:58 +0000 Received: by outflank-mailman (input) for mailman id 1206459; Fri, 16 Jan 2026 11:16:57 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vghp3-0008Oc-67 for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 11:16:57 +0000 Received: from DM1PR04CU001.outbound.protection.outlook.com (mail-centralusazlp170100005.outbound.protection.outlook.com [2a01:111:f403:c111::5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id dcdd5312-f2cc-11f0-9ccf-f158ae23cfc8; Fri, 16 Jan 2026 12:16:55 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CO1PR03MB5841.namprd03.prod.outlook.com (2603:10b6:303:9f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.4; Fri, 16 Jan 2026 11:16:51 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9499.005; Fri, 16 Jan 2026 11:16:51 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dcdd5312-f2cc-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=WiBSgz7pRuSLF1cyxWYeSG6G8LRGU2xDjmnj2PWHBA8nE9w4ZKvTF1HUEZdtK6c96BqZGA1mMO1BPTcBHEcpU3zDF5yLFbzgCgZO/4dceDQFHbTYW+No7DH3nTmmL/uxvirHtdjKNu7LoKRStK5OdeADZdfBmf5PayUQK2npMnI6aR2YC6l7EGOd+yGpAcrfe0s4cFO1sAubm6qF0KfA5glK51lrDXhboD9WjigGmzplRsvIFKt6u/b59UxtYFMnreRPyprafSIxEo8H4OljWxMtLga9AR/n6mmlxAUPVGSwMixHf42jMgdVtoOmNjvvGjdA7hK58UW++Byr67BEUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+3jZvyi1+TRpa1wtyNUJlSDD43ttt2aBdW8nrRsEy7Y=; b=UZofZb8CBuw0KShjxrH1EWPcqtDUjrLhumzNBSRSRcT8jaDJHTiQTrpETsmDBdsv3aJiY62SguhF1KsgH4C73UW0yEfvQ0Q9fSzeTcxa9S9oYrwD9o4QWvJPiSLGP9pKWvndnlmc7vtj1Y41tUnhx1VBSQLJxK88VpkL4Rhbn9Yu+GwLZyTbTL5ru++8f48TIPWUkqpgVbdmofJm3wlIUBH3dUDjnDbGWbS3MIglUvygBTQPKxyjVaMMvN7A8hlsRyNC+pUccarQ1f3F6H5/CgPl9ydGIIph3nDao6Dt/W+M7D6QvrsGWm2uPRn1CsVIiaj4d2o6NPERmlGHTMOPhQ== 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=+3jZvyi1+TRpa1wtyNUJlSDD43ttt2aBdW8nrRsEy7Y=; b=cqy8GW+nW7d4e+h10hw0aylqGdOexs0XUspiUJgcXVQj2gF3AEE7rFlxl7rFG52B6//kW4ekdH06/9WzVw4sg4JzNp1nSHEoGCfjakOGT7KjGxL/aFhYUrMmc7SNYQmLZNxeb/QLC4qMtbUkAJVHWI0fVWyHNwaPC5DgexQrIAo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Fri, 16 Jan 2026 11:16:46 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Bertrand Marquis , Volodymyr Babchuk , Oleksii Kurochko , Timothy Pearson , Mykola Kvach Subject: Re: [PATCH] build/non-x86: fix symbol lookup in presence of build-id To: Jan Beulich , "xen-devel@lists.xenproject.org" References: Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0160.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:188::21) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CO1PR03MB5841:EE_ X-MS-Office365-Filtering-Correlation-Id: 676c3136-f273-42a3-e361-08de54f0bf64 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|7416014|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?akFKRU5sTE9uZjBkRC9aVmcwQXJNQU5xMGV3eHp0Q3pGdi9GOCs1OWN1SWFL?= =?utf-8?B?cnErZGFWU1dmU0JlanlaelgyL2VEZWxMQS82ZWNtdzhQc3RIZkJYS0dLcXdl?= =?utf-8?B?WmttYXRkUmEwbFAxUkJDZEFLZk5kM2xGSWdDNjA0NnRsNXBIMGZUaVFnVHU1?= =?utf-8?B?WlpPTzAvL2NLTmhCd1oxV28wUnpmOFh3TFUwMHlFLzhQT2d2R1hLNkQ2RjVj?= =?utf-8?B?aURwbXVJNVN2M0s0MGh2ZUhQYVJXL0FwbEM5bHdBNVg1TzdKRDVMbmNOenFC?= =?utf-8?B?N1JVSk4wb0NaSHhFUldGcFRHK2lzZVhkQm5UOWpEY29yK0Z4YnBPZlhOTGU2?= =?utf-8?B?akZDN052Sys3KzBHbjYyV013bXFnK2JSSVhON3NMZ0pSRVZUUlUyNU9Balls?= =?utf-8?B?bURSaVgzZ2RiaXk4dzlxNUZxbEhFNnF4Vng3T1VSaUpJa0tLVm5adFp5SHN3?= =?utf-8?B?UUdaM1BpWjJRZE5oY2ZZSXBpSkFSWTBYZXA0b0VTazhwUkhYbVBQTUhMbEkw?= =?utf-8?B?NC9ZYndRZm1aRHBiN2R1Q2N5MVA1Yy8xT2VZd2Q2VG9QeVZmQit4bjJJOEd5?= =?utf-8?B?aGNudzBDL0JHS1RET1FSSmY4TVFKMEpGQUNTNDN6SHNiM2pxVVNQcGRYQk1j?= =?utf-8?B?NHFSc0tmajVQTVJHWEdxQXQ0blJuUnVUMzdEUSszQ016OWFJREhtaHpVY0sr?= =?utf-8?B?ZHQzZ1V5TTl2V0t3R21JL29nSmQ5dDc5V1ZsYjlPellENElINEVHeENhMFIy?= =?utf-8?B?b0pzWk02SzNzbElCdkpzMDUvZWhLT0owT0N1VjJHeittNjRFZEpUVG1VeC85?= =?utf-8?B?Nll0WUhVYXp0Y2pabnVONEw1M1p2UThQTlBSbzNSTGd6QlZ1cktBWnVhbWZD?= =?utf-8?B?dTRvdGd2ekxBMkU4YklEbkhSWHBLUEZpcVozeFFtZkRFUzYwc3hDbG5JS1Yy?= =?utf-8?B?d1dVZnZFUDZ5WnpZbXZQU1pPUTZGY2l6cXZEN0VPaTV3ZG05dGF1NDI2LzN6?= =?utf-8?B?L0RYM0RxWHM5VWJsZlJQRGpXR044WWVmakpuL1BGRmpWelJLRjNPOFhualds?= =?utf-8?B?QU05QWZ1czJ5SkQ1TWNndFZHM1YyQitLRjJjekRwenVoT3hwV3JpSFI3UWlk?= =?utf-8?B?QXpiL0xwdlV5MFBWa0haNTNWRUhoTGtXYnFkWXlRUG55S2l4Ny90OCtMR0RP?= =?utf-8?B?aWVTT1JkVkczVzJSb1RvNkpQMDNTQWdUMUNrZXJkNmFlYVJ1QjVlTFZHMUkr?= =?utf-8?B?NkNEYWMxM2xDMEEvL2pRSXlKdWFjWEZ0UnA2bnZibUl5anZjczY4Q1R4N0RC?= =?utf-8?B?QXJoL2dpRThCTGVBYU1NdWw3RExLTHdPa2kxV1p6bGgxVlRna1NpSHV2ajBm?= =?utf-8?B?cFhOV2g2dDBZbmFXaUp3Q2NwSjIxQStEbjUxSEhVejhzL3VRcTlJYm5TdUlZ?= =?utf-8?B?VExpeTVDZlNoQlVwTTFTdXI4WStSNWlhN2xpYkZWcGV5enhPMWF3Q09sOHFs?= =?utf-8?B?a2FYbnFNZmNvUVRTMWJZSVN1RGc0RFgvOTVVdGYvdVdDQmZaQStLQ0p1N2FX?= =?utf-8?B?aUFoZHdZZnh0TWRmYmk2azhvNzFwb2F4NzdRTWtXVGpjNnNDdWZ4VDBXRnZo?= =?utf-8?B?ckJDVDMzRHJ2VkxqR1F4RHlWY1lWYTVGSVFyUWNzT0hZOHNiK2h2clR3UlBV?= =?utf-8?B?YlNqT0hWTFlveGp4eThZYnFZU21aamRsVmpqamc4ZXV5M0psZzQ0dGFjRzhH?= =?utf-8?B?Rm8wbnR0LzRrMTlyaUYyM1NPYmVGaTRucUtSakxwVkk1RkVpQUwyUDVzNzRt?= =?utf-8?B?WjJHMGxnZlFUb1pnLytNL3pEcEFTVGZLdzdPemFzWUdZMjdhSDBTT2tteU1Y?= =?utf-8?B?TTAveTNqTzVRbEFVU3pCWmFYZ2J3NnkwaVhkOUgyWjUyUmNwOFprUk1kcmRW?= =?utf-8?B?UStNL1lhajBtUnY1ODBYY1k5N2M4L3NhUFBNa281VHJjWDdKdkd6WW8zLy9Y?= =?utf-8?B?YUZUbHN2T3UzZURKLzlpRUVrb3hWVnJpN3p1QlRMYXdTSVF0UTNmaUxaczR1?= =?utf-8?B?aFpGMEszYkNCSE9KTm43QjkzY2lLY2NEL0Q4NTcrMzRlWDU3UlVJV1FoME5T?= =?utf-8?Q?rxc0=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(7416014)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Zmlia2tUTGsrODdTb0s3T2g5bVB4cmJjUVV5SVNsTEtMdEd0S1ZnTEJTOWtx?= =?utf-8?B?S0cwa3pyd2swUEFHOC93VW4vUnpMN3lpdFFPNkJTRzArNkxHS2U1OWpDVGtv?= =?utf-8?B?UW5RSEt4YVdhZUNzK0Q3WE0vMWV3VGMwZHRpaDNXWHpXK1VySnllMjJXMVJw?= =?utf-8?B?VUMzRU53MDhqVmFublBYaUM0MlZCTDM2QTlDZTVZK0tXQzlvZHJhQWM0Uzc5?= =?utf-8?B?VVB4VnhPeWtGMjVqMXpIUmNFRHZaK1U4bWQ2VG9xakNEeEh0T0lFcmJaQzB0?= =?utf-8?B?dVh6M0VDa1pjb0ZUdHhhTGNKa2F3RDBCYWRZekg1ejJINHpmSGl0d3RpdWxo?= =?utf-8?B?MFFoZzB3Mm1BempMZWFPTnFIMVlUeEFCUUIwNGowMEtJKzhLd04wTE4vZ25M?= =?utf-8?B?WmZERnVualh5U1Jub3FldnptbndwelgrdmJFditzd1NqUWtVYjhxcFArM0Nw?= =?utf-8?B?YUtLZCtDMFNzOUdzMW9qL2JaQmRTeFF4dURJTlk3Ri92bXZBZmhBcFdPRzcy?= =?utf-8?B?NU5rWnlRUXpYWnBJR1RyYis4S2RuaDVodHcrOVdPazZiV2tWOWFJQk0ya0xx?= =?utf-8?B?NGRVVnVBanBUcElKejhQRktvTVVBNHN1WDczYVQ5SUx6RTBCZUw1M0FycWRB?= =?utf-8?B?K3FEU1ZQbVhOV1hXV3BNMVNMMlRlR3ZFVklOV1ExaGVndmVnVVBEQTZLSkth?= =?utf-8?B?TkJIVVV3RGtLNjRnZ2dWRmczTTdyNkttVVNzZVR4QjZoQnFya0tnNUhhclVM?= =?utf-8?B?Y0RYdHNPK0VpVURlTmtTa0pXenJHa0luWktJeDBISSs4R2R0dTR6WWRLZ0py?= =?utf-8?B?Q3NZRTF4QnRJbXc5b0JNR1J0YUtsayt6am1uc3ZXazYyYk0vbnI0cHQxcXdW?= =?utf-8?B?OGpIUVVPNjQ2N2hHcUNQOEg3Zmpoajk4dUZ0aVE5TEQzWCtHL3JjNzQ1Q0tz?= =?utf-8?B?RXU3NnhMK0JPbWNVQWF3VG5Yd2I1Yi9jeHpLb1pQWmd5UGp4aDJJS2xGM25u?= =?utf-8?B?Nzh0TzNDajhobTVhbkJ6c243K1p5Qm40OHlIZFU2dkR6NjhIa1c0bEZUb0cx?= =?utf-8?B?cWMyZ0Z5UkJiUkxkRWFvY01nMjRDNDM1K2loTXdYOHhPYXc2Y2p3amRHc0Fj?= =?utf-8?B?VzhvR3A3aWFIWi9HSmxoYS9ZMWErd1UrT2syclF4YTJ0NHIxbThVQmFuZHIw?= =?utf-8?B?NVFLaXN3cGZDcm5VcUdRT2Rvd2ljNDJDR1BlRTVIc01DTVBJTitKLzQyWWxp?= =?utf-8?B?S2h2VVpmNjgwY0l3bjhIM1g0bkVHYXBLS0JGVC9BWmt0VnpqRmd1TldOdVB6?= =?utf-8?B?Nkd6SjcxMnpzTHhJQU9xb3lZQ0NzMTIxRUtSUEY4bzZWMlM2T0M2cFZaVy9W?= =?utf-8?B?OUNvbnlQQmpzVGozeWhwdVZrNm5JQ1Voc001R3hvb1A3SWtnWSttV1kzOG94?= =?utf-8?B?RDA1Q1hhUVV4Y0VwZndLYVdveEk3N2tuU3B5bExxVHdRRklMZWw2bUIzN3RL?= =?utf-8?B?cDNTWmZuZFU2aEJ1ano4a2pNd3RFR3k5VzRwejB2bXNHakJQUUVjZEVzak5E?= =?utf-8?B?cTlGUDdINkNKOFV0MDFLYXRFUWt1YlpGdjZORkhhRWdWWFJhbzM4R05JVEdq?= =?utf-8?B?UVFJVnRJTkNSbFRpMDZEcCs5bWt2WHk2TmpMU1Qwb2p6VzJpNCtneENwcWps?= =?utf-8?B?bnBJWklBYmFtWHJwZDE4Vkp0cXdKWUlWWXJ6cDlXaThmbkFMVlN6WmwzR2c2?= =?utf-8?B?VFgxczAyaGlNMkplRSt4U2tOVVdoVVdqejZoNG5OVHZYa0hyVzBwbTQxV2tI?= =?utf-8?B?SGN3WnNTajdCNTZGNlYrVnBiRXR0YlBwRkppUFY1dFFud2RsbStVUTRnNUtN?= =?utf-8?B?amxLV0o1SXJTTlYra2V3cG1jWVhWT2ZORGtvdzdiTHppVFRkRW1RaENyS0tU?= =?utf-8?B?MFFkVC9FZEM0Y08rUHJDQm5NOHNoZkgzbmF1ZWZ5OVU4UDNYZndJVGFLRzdJ?= =?utf-8?B?NnJqVDZsV204RGpYUjVMZjkyTlE0SFF4aGdvejlSVkhoSlBBcFk2cDQ2anEz?= =?utf-8?B?a2dnTUlrNXJ5S2svMWdKZjBEeFZ0c2VGZS9LU0E3UHBDcmR5NHIzT0FxSU1E?= =?utf-8?B?TnorUjRZVXExcG5kUnoyMmN3NytLV2dWVXV4Rk80R0tKL3lHVTlnYXdMM21o?= =?utf-8?B?RGdmVko4MzJqc1lDeStPYTNxdEduQXd5RDFTVEVUREc5bmVQN2FqWWFwa3Zq?= =?utf-8?B?aG9KalUyWmhqc0ZidGptREc0UVJJV1N5ckFBenBPSWc2Yms5NXE5bGpWbnh6?= =?utf-8?B?dXZOTHRVVE5POVc5d1VxaCtsL1BDak5kU1VGN2RtZitxQzh3R3ZWZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 676c3136-f273-42a3-e361-08de54f0bf64 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jan 2026 11:16:51.4830 (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: qDWfEGr5ctZab/7zPXWC1JM38bxYdsQpJoIg+4fEyVjwKR8Vv3lVqsVVAJJ3ili92oUIkfXQIUKsBWr/Nt4tVbvGCIAelqFZbqqIY8pN1mc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB5841 On 16/01/2026 10:52 am, Jan Beulich wrote: > It's not clear why only x86 had $(build_id_linker) applied to all three > linking passes. Not doing so will alter symbol offsets between the 2nd > and 3rd passes for, potentially, all of the symbols at higher addresses > (intermediate alignment padding may mask this effect, though, so it will > look as if problems appeared randomly). > > Fixes: a353cab905af ("build_id: Provide ld-embedded build-ids") > Reported-by: Mykola Kvach > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper We really need to make this step common between architectures.  It's entirely magic, but mostly common. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jan 16 12:48:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 12:48:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206565.1520023 (Exim 4.92) (envelope-from ) id 1vgjFW-0002Zt-S4; Fri, 16 Jan 2026 12:48:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206565.1520023; Fri, 16 Jan 2026 12:48:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgjFW-0002Zm-P2; Fri, 16 Jan 2026 12:48:22 +0000 Received: by outflank-mailman (input) for mailman id 1206565; Fri, 16 Jan 2026 12:48: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 1vgjFV-0002Zg-43 for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 12:48:21 +0000 Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [2a00:1450:4864:20::234]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a1d754dc-f2d9-11f0-9ccf-f158ae23cfc8; Fri, 16 Jan 2026 13:48:18 +0100 (CET) Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-382f087e6c9so11315691fa.0 for ; Fri, 16 Jan 2026 04:48:18 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a1d754dc-f2d9-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768567698; x=1769172498; 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=L41dPiH44XiWmV9X9+UuETkLEvEFX3CXZYd9hOxjhhk=; b=ib6oomKYWQhMyMKs36q4Z9quTPe58dHDDKP9hWho8ek5QZ/XWf9rDZmg0E/SHsU6F0 dBHwhv7cccj+wtMNTG935VYuI7q7gYT90s7eaOVvVmhQPZkeoET+YTNGUM2PFDIDtfFz D1FiZdCi8fqcoBzXPYbk7d7B0DAS8ZeZ8VupqipsNXIL0G+sX10Axay3GGPbSlRjMqji P0MrtwY+B7TE4o5Qi2uuRm3HfsSm/wCjMx2NmpiGHef5wQJPuIze1ySf6gM2Tw5Y9wHl 6SvkFN9FoRsRJKHDSUntLHRntSp0UNo/Cj4suzB+jlOMY1YCMzQi3LzTAYGtnb79QZJp 4tog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768567698; x=1769172498; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=L41dPiH44XiWmV9X9+UuETkLEvEFX3CXZYd9hOxjhhk=; b=jQl1L9wIbiVsSLReTu0Bm7zF6I0Ezt7dEVBvypY5kqnMK3tAeEyx9OUUKFofl/JQEY pLV5tO0DFK+iEY5PsPrfv3rfLZa1aeiTh9Vj5yLJB978zNd8LdU8z41uaomDgM/A8uVh nH+Ey4RMz5oCcp6O36dyw1b1o4Fpd2QDimFl2PLgY2dfvV7Zh/qSO9FlMiBuGzuldB/4 4E3/Be4iuc7MdWJNMWvkEI9P2R9Hp9HX1rD5/GIbvkH+q+fJ4lPJRyLjK76DKg44aK3F IhQaFSQXPRDXGNtsiO8UEZ4bf+n8FBwgyizCbZMeoYCeRsea6woBJCzk+CHuVY9E6u+3 6zCQ== X-Gm-Message-State: AOJu0YztM7q6YWLYN37ipxEI27xgv1YsJvFzQCGBUVq34+T6ap8yYQA2 HxLIQOnMfbcBCRVn014iqQxmWiF450OGS812b+DnxF+D1FybiHSFm7vo+5BjYJQSsOQ9a/g2nb5 Ham2dM5X6C4VDVhOrbk1to3ujna6iiNQ= X-Gm-Gg: AY/fxX42vmELyP3Sb+SaDTZlIwU7ZkdlcRIJ8zf22AlqvS2Lr8yihaQkh3XoUvH5i3H eGbVo6F8KwDjgcQhC+0dInH5v/89VSx0b7eUq7QQT8M7anL1Xx0G434ZfVO0cRluEEKWanaKHAc DvdH6HV2RQEVv4UQ8sxpU0x9cKZGH733Dr+kmAjZIfIbVgUHx8y5TEcrpXfny3wNB2KH3u7vTuD eJbyrljTVly4qCY30RDFa5SQHMZcMkQ7x3W9O3YQIytmwQM/bPr51ByOOehKNBG53bqMMRTJS61 akKGiQ== X-Received: by 2002:a05:6512:1050:b0:59b:72f8:238e with SMTP id 2adb3069b0e04-59baef0bdcdmr1067322e87.52.1768567697697; Fri, 16 Jan 2026 04:48:17 -0800 (PST) MIME-Version: 1.0 References: <10aaed6d-6cb1-4bed-aa8c-5f9761f04fde@suse.com> <35819233-07ba-4e00-8939-74b2f4454250@suse.com> In-Reply-To: From: Mykola Kvach Date: Fri, 16 Jan 2026 14:48:06 +0200 X-Gm-Features: AZwV_QgHuf3HNG8dQpQ5mNjqMNv5I22t4l9d4lWYcn3x9SaUiwDjaUaIvY33XXw Message-ID: Subject: Re: Strange symbols_lookup() behaviour in test-symbols on arm64 CI To: Jan Beulich Cc: Xen-devel , Volodymyr Babchuk Content-Type: text/plain; charset="UTF-8" Hi Jan, > Actually, can you give the patch below a try? That would explain the 24-byte > difference (albeit I'm struggling with some other aspects of a proper > explanation). > > Jan > > --- a/xen/arch/arm/Makefile > +++ b/xen/arch/arm/Makefile > @@ -87,13 +87,13 @@ endif > $(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds > $(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S > $(MAKE) $(build)=$(@D) $(dot-target).0.o > - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< \ > + $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ > $(dot-target).0.o -o $(dot-target).0 > $(NM) -pa --format=sysv $(dot-target).0 \ > | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ > > $(dot-target).1.S > $(MAKE) $(build)=$(@D) $(dot-target).1.o > - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< \ > + $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ > $(dot-target).1.o -o $(dot-target).1 > $(NM) -pa --format=sysv $(dot-target).1 \ > | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ Thank you for fixing this issue. I tried the Makefile change you suggested (adding $(build_id_linker) to the two $(LD) invocations. With this patch applied, I no longer see the issue. Artifacts (binaries): https://gitlab.com/xen-project/people/mykola_kvach/xen/-/jobs/12743067337/artifacts/browse/binaries/ Test job: https://gitlab.com/xen-project/people/mykola_kvach/xen/-/jobs/12743031743 Applied changes (last two commits): https://gitlab.com/xen-project/people/mykola_kvach/xen/-/commits/reg_dbg1 Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Fri Jan 16 13:50:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 13:50:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206626.1520033 (Exim 4.92) (envelope-from ) id 1vgkDE-00022B-5c; Fri, 16 Jan 2026 13:50:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206626.1520033; Fri, 16 Jan 2026 13:50: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 1vgkDE-00021P-1s; Fri, 16 Jan 2026 13:50:04 +0000 Received: by outflank-mailman (input) for mailman id 1206626; Fri, 16 Jan 2026 13:50: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 1vgkDC-0001YF-WA for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 13:50:02 +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 4092efc0-f2e2-11f0-9ccf-f158ae23cfc8; Fri, 16 Jan 2026 14:50:01 +0100 (CET) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-42fb5810d39so1632877f8f.2 for ; Fri, 16 Jan 2026 05:50:01 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43569921dedsm5415980f8f.9.2026.01.16.05.49.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Jan 2026 05:50:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4092efc0-f2e2-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768571400; x=1769176200; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=U+rQyQgzpiX9jFzahbz+s4ZW0ETE/t7YYZZKejJ9Hwo=; b=P0TRqGSsZX/HG/KcT4fs1HgPfakLdq7KxKUEsLwK/o+7VptmejJNIjj9aTfUalLR2K BZ1h42Q2LsNtnLwhYsa/wc0PNnZfMuRn23ShXdmVvDu+05IuHH+DaeTwoNZkauTdExnT NULTsmGaUUgRUDOjVeqEFHM37tGCrji9NT9lHBRZZxOqbUaU3oFlavf54BJnO9n6Q4PK X52gBl8y2bhZpAWLiBImCnBnu3l41NpNS4HRttVEVp0zCJILd7FaCvidV9N6w6QnGQ9A i0dXbEamWygL458Jb3AEDlFQq+gXbxlBvf41oVvNr8UrVmkDM45+maeFiCFjQ+GcPJQJ KGJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768571400; x=1769176200; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=U+rQyQgzpiX9jFzahbz+s4ZW0ETE/t7YYZZKejJ9Hwo=; b=k8YqdKt+xHxqT8JsjOkZge5k4EmnX5mAlrhlhgxkOz3e47L8GtDmUgKfsYxvg3g8KH 2preqk88Mw27gMysqdi6rVEY6eFF7gFzLU5AF+TAJ6jpjuSr7J6Ijkogkmd6xQrVk2hW q4YcXYontmBdoaPOzr1U9IOxEWMaO1JPF0dlOyOf+ud8pi2rIVx/NloeAfH/3LEFVOjM +Q89ZSuL5ikHEuauYywbKf4NoEaoOZIVzhcunmtg04utFBe0szl5iB4/92U/BqxSjGjW 7xYX/T8v8mLot8nJPJNQajRq5XHApBo6CSG95kw2LByIle5OoyFMA05XtYdAlNhs+uOi WBNg== X-Gm-Message-State: AOJu0Yxex5Ha7oGNkdPpbJhxmV8V70XKrZKkBs0mLZG3+YfMoncWTY1t oy8MchNImD2MxHbrBsGi2cvF62gwxhG5ePzjhbnnk6Mwv7tf9S/+mFFPpqexqaJdoQ== X-Gm-Gg: AY/fxX5bs0gE0gvvC69hc56kO+V3GtZDDYTF0W181vmr4ySZIkhtf6Z1bQU98ZS9DMD aigCLMe/plAfpClrywizBzbUxPzsI5nOinpvf/lmVkalmOwY2ong8XWE+uu8ZrrWAcOZhAHlhTs Zpoejj4y3ZxHb/RiGTwAN2223zbNgnkoucZASU5391S5F7RhKJeCC3DogAOgsadPBs6EvoyZ6Ri jS16I1eHN5ZctAIEZiM6iURFrcjlgXq4s98jPwHjbTS8R7aVLsONfSQdglUnlZBkAmcM7C4tNXC VAf73VUlTVNBV2YVAg/nBazHWXGx0tD6CSWupjwBxKxVY6gFgDaklKEUvz7yqB1KoFIP8qZpUOq k9ujWfo8U5Fck+ZnsZvZ1ziT6XH4V16D1F9V1ieCzvcCtgYKBJ6JHLK7C25QHBOphLgQ7XwRct0 llcWczus1R6Oa9DNXHth7v/VPM2uCh5oReC2MqtTjkskwpZVhBhy+/oasjKBwIVORRALOdNGLj3 /I= X-Received: by 2002:a05:6000:2382:b0:430:f742:fbc3 with SMTP id ffacd0b85a97d-4356a05c0f1mr3699473f8f.48.1768571400392; Fri, 16 Jan 2026 05:50:00 -0800 (PST) Message-ID: <728956d5-b404-4e9c-b618-06289acbc71f@suse.com> Date: Fri, 16 Jan 2026 14:49:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Strange symbols_lookup() behaviour in test-symbols on arm64 CI To: Mykola Kvach Cc: Xen-devel , Volodymyr Babchuk References: <10aaed6d-6cb1-4bed-aa8c-5f9761f04fde@suse.com> <35819233-07ba-4e00-8939-74b2f4454250@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 16.01.2026 13:48, Mykola Kvach wrote: >> Actually, can you give the patch below a try? That would explain the 24-byte >> difference (albeit I'm struggling with some other aspects of a proper >> explanation). >> >> --- a/xen/arch/arm/Makefile >> +++ b/xen/arch/arm/Makefile >> @@ -87,13 +87,13 @@ endif >> $(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds >> $(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S >> $(MAKE) $(build)=$(@D) $(dot-target).0.o >> - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< \ >> + $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ >> $(dot-target).0.o -o $(dot-target).0 >> $(NM) -pa --format=sysv $(dot-target).0 \ >> | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ >> > $(dot-target).1.S >> $(MAKE) $(build)=$(@D) $(dot-target).1.o >> - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< \ >> + $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ >> $(dot-target).1.o -o $(dot-target).1 >> $(NM) -pa --format=sysv $(dot-target).1 \ >> | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ > > Thank you for fixing this issue. > > I tried the Makefile change you suggested (adding $(build_id_linker) > to the two $(LD) invocations. > With this patch applied, I no longer see the issue. May I translate this to Tested-by: then (confined to Arm, as the full patch touches PPC and RISC-V as well)? Jan From xen-devel-bounces@lists.xenproject.org Fri Jan 16 14:03:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 14:03:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206645.1520042 (Exim 4.92) (envelope-from ) id 1vgkPm-0004Ev-6r; Fri, 16 Jan 2026 14:03:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206645.1520042; Fri, 16 Jan 2026 14:03:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgkPm-0004Eo-4L; Fri, 16 Jan 2026 14:03:02 +0000 Received: by outflank-mailman (input) for mailman id 1206645; Fri, 16 Jan 2026 14:03: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 1vgkPl-0004Ei-DO for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 14:03:01 +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 1124ed09-f2e4-11f0-b15e-2bf370ae4941; Fri, 16 Jan 2026 15:03:00 +0100 (CET) Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-59b7073f61dso2592354e87.2 for ; Fri, 16 Jan 2026 06:03:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1124ed09-f2e4-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768572180; x=1769176980; 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=lkRgaANMh8CQ8z4LC91LtnxcfXnjI7vhTwaYXv12uSM=; b=aeIpbcDr+Q3zCjwI8Mrz2LUAH6Oy6lfSYdai2ElZvZRitBML2BhixsNRMeWRyFxcP+ KdOekqQki0ctmaY4pdvmjSU8zKwTndCm7x6114m6kXu7W2dXIqwxYr6hHJB3MbIFPvuU naDN1Y+q2T7BYOeBaxe7HineJ6mNjAeFYGXbdarLZpDazGsX56wv4OmbhwTogM5oJu6/ IJsNdJX1OrhnyFkdqeMrt42WYFnCk7TkM42Z8ElbXqC27+BVfnm2oKww0tOV3AVHgbHZ mP2WP4dQeEa6WviCqKbrS7fHvci16Tayep4Li4Abave9WC9rmynMl+U1asAuX4PGjv9K TFsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768572180; x=1769176980; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=lkRgaANMh8CQ8z4LC91LtnxcfXnjI7vhTwaYXv12uSM=; b=ZAHq4AKzOHMuoacL1Go8Obo3E+KgW75h1sk4k9u0YCgDosZEA0m1SIwhle158ac7Ju kx9IOdsmZ0GNt2qqOcdDICAgWarUbqjPnRbss5P3Ua6oTnwt68xFuH2r2yCRoFJ7ZKw0 NFqVmGeLlwQ7TlI6xBGsnOFLXvg5/w/Z84GyEGruTUt3jg6girESWAy99S9+8eCJVkKG uKCfh61N6kaEZrINjbElRqJ3hwSIkW7npj22Y2NhZLUOLwN1iVv6t1yjupY+T8rIrApe /c1Jrs70gm4I69MRypTf84m/iz9ngW06NhazccUZQefetlLKdhxprvdUuvQzu0tb7QNr 0L2Q== X-Gm-Message-State: AOJu0YyVUvnxDpqk9Z9p534FvFzcN/oyrygiQ12YLKX84DDFRA4+8xRh +Un2DVTPewbEhiSd6hipL4NpARYsQ2BHoPS2hEDQQfKRXakbo2YEnQM4bpO+duWBTDvC0CjoS6I 7E0CZ1gy4Iczl45FbUddUQhPVHkwcCt4= X-Gm-Gg: AY/fxX7urD5cHm0xml6DtAF5/2upKThDv6tmnJ4XJ/Zc23oIF+qQdCVFBvrNTodiZzy sbzZEpr0+eVhQR/mfOw+kPlv6VuWf37qupvQXa1Yn59uHGikx2b/1aRxvsPxKhCzezNG0X0zI+W mJKwzqt3rNL0ktdonUOlxFWlGpTfZotms/CXYsChPtvY/Pi/uEgje+JVZUM3tZVQmK1Tonxv3dT zz7It2EHE1oKKpLKBRE7FjrWjnjyFukGAnwwjcPJZ0XpJ0htuT+hyXnNg+QMoQCHpQ5qCZp3Lq1 l8v5ng== X-Received: by 2002:a05:6512:4015:b0:59b:b0f9:53ed with SMTP id 2adb3069b0e04-59bb0f9545fmr789328e87.3.1768572179406; Fri, 16 Jan 2026 06:02:59 -0800 (PST) MIME-Version: 1.0 References: <10aaed6d-6cb1-4bed-aa8c-5f9761f04fde@suse.com> <35819233-07ba-4e00-8939-74b2f4454250@suse.com> <728956d5-b404-4e9c-b618-06289acbc71f@suse.com> In-Reply-To: <728956d5-b404-4e9c-b618-06289acbc71f@suse.com> From: Mykola Kvach Date: Fri, 16 Jan 2026 16:02:47 +0200 X-Gm-Features: AZwV_QjBazq5TyGK8Cvf0utBL1NRcjz5j9TCbn4s1rgB30UYd2IAFKYchlo0VVo Message-ID: Subject: Re: Strange symbols_lookup() behaviour in test-symbols on arm64 CI To: Jan Beulich Cc: Xen-devel , Volodymyr Babchuk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 16, 2026 at 3:50=E2=80=AFPM Jan Beulich wro= te: > > On 16.01.2026 13:48, Mykola Kvach wrote: > >> Actually, can you give the patch below a try? That would explain the 2= 4-byte > >> difference (albeit I'm struggling with some other aspects of a proper > >> explanation). > >> > >> --- a/xen/arch/arm/Makefile > >> +++ b/xen/arch/arm/Makefile > >> @@ -87,13 +87,13 @@ endif > >> $(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds > >> $(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target= ).0.S > >> $(MAKE) $(build)=3D$(@D) $(dot-target).0.o > >> - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< \ > >> + $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ > >> $(dot-target).0.o -o $(dot-target).0 > >> $(NM) -pa --format=3Dsysv $(dot-target).0 \ > >> | $(objtree)/tools/symbols $(all_symbols) --sysv --sor= t \ > >> > $(dot-target).1.S > >> $(MAKE) $(build)=3D$(@D) $(dot-target).1.o > >> - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< \ > >> + $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ > >> $(dot-target).1.o -o $(dot-target).1 > >> $(NM) -pa --format=3Dsysv $(dot-target).1 \ > >> | $(objtree)/tools/symbols $(all_symbols) --sysv --sor= t \ > > > > Thank you for fixing this issue. > > > > I tried the Makefile change you suggested (adding $(build_id_linker) > > to the two $(LD) invocations. > > With this patch applied, I no longer see the issue. > > May I translate this to Tested-by: then (confined to Arm, as the full pat= ch > touches PPC and RISC-V as well)? Yes, I agree -- please add the Tested-by tag. > > Jan From xen-devel-bounces@lists.xenproject.org Fri Jan 16 14:25:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 14:25:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206684.1520053 (Exim 4.92) (envelope-from ) id 1vgklB-0007Ao-Sc; Fri, 16 Jan 2026 14:25:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206684.1520053; Fri, 16 Jan 2026 14:25: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 1vgklB-0007Ah-Oc; Fri, 16 Jan 2026 14:25:09 +0000 Received: by outflank-mailman (input) for mailman id 1206684; Fri, 16 Jan 2026 14:25: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 1vgklA-0007Ab-3T for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 14:25:08 +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 272440c6-f2e7-11f0-9ccf-f158ae23cfc8; Fri, 16 Jan 2026 15:25:05 +0100 (CET) Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-64b9230f564so2804620a12.1 for ; Fri, 16 Jan 2026 06:25:05 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b879513e9f3sm259137066b.10.2026.01.16.06.25.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Jan 2026 06:25:04 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 272440c6-f2e7-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768573505; x=1769178305; 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=TfxQ1MkYSVozlt2Rs8/5hJDTJvj3zf64lUpUWQ+6jpg=; b=ndRj7MCthHTBGt69DKrsbMRHL+FncvtmQttq2tdotzPdyHDv9bv2Z3iuMQaNWcaOAM HykscA/y4BdWmhrnvcQgNk/TVH2y4J3sVq78cbXThhbl+jibh3xrzVEA9PceTlRXA+3B c0gUjDpWoxGZvMSnhdqZjYs6cvkdDO9bMTd3bXhKilBzkEBCLp3PjKR5Wbgq54CjvXSg S4BJClqJu0+nh2gCjOdQZxBFCfhLYaUnT2EB9p4zPubfgpCeciDV9OiIufenWqYD8v6S qSTcRLpE/7IVk8L9VZpjIkyL49QvR4dgwDAKEuwsGk7LzVcMUjVI3iiP1yLKxY1Yzhan UgCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768573505; x=1769178305; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TfxQ1MkYSVozlt2Rs8/5hJDTJvj3zf64lUpUWQ+6jpg=; b=X/ukVfNcwfFe/qvkWPMPPQAxwxDG45bqSnEdLJrD6/nDFyV6n6wp9beICsX45WITXO vSulkU95e0uheX1uHeTi/sB1y//nyBuZmMVChE3P2eUyjFE2iMPo8hcdlypW4rdXFMAe X95uUEBww61S+uxDfdfEwO3ca8YQf8ostGsK6lMB4I8uWw2/JaN0s6QA9Exprplmm0Gq RetI6Ao+z9Kru014IkGQRSjzSBtQAoAczelvhTAP1y6iJb3EokUg8bas9zUSAGgAxu9C 5biqhFXlZczdzwBcU+2bgyDs3+RCsEkuOOHmj82P24ZHwJZYcaDNowbzvASCO7b4z+oE UnBQ== X-Forwarded-Encrypted: i=1; AJvYcCUK96ER+Hsc3iNxJLg/iWiYlWVIUJpsuC51bariGCzdLNx4aj95QI3RcmIsMTImOzQCRk/YFJYbozU=@lists.xenproject.org X-Gm-Message-State: AOJu0YxAtmvOh+96gPxy3bQeDgXiqgwAUqdUbZhIRDoAP82K2WRMgZb+ S4VdqXCKCisZOkfLCogRKCkPZgbnckKRX4y9kBQw7Vtz0XKhJE9tw2nP X-Gm-Gg: AY/fxX4H2pO7DphrmyLH5jdtM/tqiwu5i+H5zm3aCQxcP5lRvOB7zwC7N+fPiVpiiQ3 zrtWw9dwSeVYT5WHGcJ8FemQoDHjuIfqO7bNMzaInkwwlJxWykiLoKBoAzdddhdZqQbnwJkxhpm VXeBBK7nQuOvs+wwQ8+nTqmU8S1pdUszDn1uKo1rX3upn/Mq27TIW/X3Ck1TwzeJ7yJVNEBcCTZ V3iDNx/7ldZBJgxhiZmLcbsXoRROAE8MGNvel/aFFnYgJ81BffGEP2tDwPk/bmIZtKRL9zdI1H1 YJ+9RRNgWqg4PXY2sHup+rQreeQsawWALvAjf9d82eNorui5K0R1lxjyHi5GI0wZIimdE5bjwA0 eFYy914skIXaxn75gEsBRDWSPOlYvCWIOSW8H3Sh1iSA48T+xe8u3XnEbfj+4N22aVkvP+bdVgV sd8z//citzqYGLyhvjtNkXhBgAacYH7vkQblj1JEUc5RQxZABLMof8uHIbMsoCYew= X-Received: by 2002:a17:907:94ce:b0:b87:1b2b:3312 with SMTP id a640c23a62f3a-b8792d65770mr268460266b.16.1768573505025; Fri, 16 Jan 2026 06:25:05 -0800 (PST) Message-ID: <9212924e-8f3a-4797-8c3b-149ff7c4b03e@gmail.com> Date: Fri, 16 Jan 2026 15:25:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 07/15] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/7/26 5:28 PM, Jan Beulich wrote: >> + >> + /* >> + * VCPU interrupts >> + * >> + * We have a lockless approach for tracking pending VCPU interrupts >> + * implemented using atomic bitops. The irqs_pending bitmap represent >> + * pending interrupts whereas irqs_pending_mask represent bits changed >> + * in irqs_pending. > And hence a set immediately followed by an unset is then indistinguishable > from just an unset (or the other way around). This may not be a problem, but > if it isn't, I think this needs explaining. I am still not sure that this is actually a problem, or what kind of explanation is needed. |unset| is called only when the guest makes such a request, and the guest will make that request only after it has received an interrupt that was previously set in the|irq_pending| bitmap and then flushed to the hardware HVIP. If an interrupt is simply set and then unset without ever being flushed to the hardware HVIP, it seems there would be no issue, since it would not affect the guest. However, the question of why this happened at all would still remain. Do I miss some corner cases which should be taken into account? Should I still have to add some extra explanation to the comment or commit message? ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Jan 16 14:28:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 14:28:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206693.1520063 (Exim 4.92) (envelope-from ) id 1vgkoL-0007m3-AC; Fri, 16 Jan 2026 14:28:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206693.1520063; Fri, 16 Jan 2026 14: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 1vgkoL-0007lw-6t; Fri, 16 Jan 2026 14:28:25 +0000 Received: by outflank-mailman (input) for mailman id 1206693; Fri, 16 Jan 2026 14:28: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 1vgkoJ-0007lq-Rx for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 14:28:23 +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 9c32e493-f2e7-11f0-b15e-2bf370ae4941; Fri, 16 Jan 2026 15:28:22 +0100 (CET) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-655ae329d6bso1271829a12.0 for ; Fri, 16 Jan 2026 06:28:22 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8795168b9bsm261858566b.16.2026.01.16.06.28.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Jan 2026 06:28:21 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9c32e493-f2e7-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768573701; x=1769178501; 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=0Oaj8qOuIakkOAc62hcs+ZprvirFF3N3/2V+KJMuKZA=; b=CFLPe7yTYTlhYX12q6wId3Mp1avOU7kTDgRWI4JLeHXcQcViQS7O2OVNEc8SGMFuBR XN6UrPMaJk+HcTz3HmtGzy/VQ++Mgb9Yy1macJwD3MPL3dE31QZpn80xg0txl5dyiYA1 35nAcHxqI4Hj0rMoj2rDCX9+6yW7Xekddhl3MCljmLAd48L3HR2K3DBzC7Rain5OECjD jJ3xHXnykEzDXP60rSTzhTCgdaRjLfd0f8Z8WuUkLComSYAxFS2ALkD2AnCIXuXR2Pw7 wISMj4bybUGeeyrJO4PVavb54mBd5cFFKg4q5ZT7AwdJpEu6XGnjdCQJLgdF9RmfSng5 PSdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768573701; x=1769178501; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0Oaj8qOuIakkOAc62hcs+ZprvirFF3N3/2V+KJMuKZA=; b=E7/83hvT8yCIPdTSI785UFP8G09TybqkBSqcqR/59uezCmToVs80oSBxhSFsslVI6j 0KogF8y3NXo2EzK/rIfc/t0bKNivNzyTMIEhsjto0bPL+LlU7ptF3lfMgAy8FNFADlBm I8ZPjsYf/Oye/uRVutRh1gVEKvjp47LEpkcZeVhzKfXNwUq3DPmWE0kS1lUeAWiJaeYz M8QrFqdrhRtrp/TWF7Cyov4FFdBWJrSHOTaPBmgVisJLWxMJ43WsM7djH3Hcz6TeIwQg fZPkoVf92+Ih9FV8ghkOQjvpA+CAb+k3GjOBGKBXDjX69JLTZGjqTBJPrJKoemtcvTz3 F5Tw== X-Forwarded-Encrypted: i=1; AJvYcCUzZQjOJ3tYCRsE8/onFEEYYiqthsCAKWAjEdCFqJkE7hNOA4sHABvN6B0mkCNgh4VDk4SFxZ2pKQc=@lists.xenproject.org X-Gm-Message-State: AOJu0YxkCzMgi053iO/MKRWZgbimVTt+ewqh/xTfO4ktk7308IPZ78vx uX3n7r8qD5iNSuYwhPNEh7BAG81KHLWTqxJX0PXU+lN0jM2n7OvFVEhE X-Gm-Gg: AY/fxX5q331nyPoNRUWm82pxKrMDToNR70Hugzvs9V79Pk//wLZK2cE8QeiYQGDRiJ/ 9K6Bfzg91FEa8bBunNP9+Am4g4AUNUqslUu+osfyKh+LdcsSFsA34JoZFj2cUQGpkMWdMYlx4ea 4g4qp+Xhb35fpVulPCrL/fA+RS7ySMYC8/OJwrhNML2SmN5ovpwVRkSqEipbWD+niO6aU0QcIag dhb+cKsw6kdHz/ybE7NfKCcGMCkBhU6Bv+yecz5TSx+QmdKfMUvHeFGu2h9TeNKXhhjreEtfQVn c9Mc1NSAsQvnHocQaPyPqPPud7mSM8tBgK2g/5NAFXQ4u+UEQ1qV0B+k0b8GV256tGx+09J7Pi9 71bghJn718LdfUWWNrdKiLw4kVsCO/hBXKBmzoLw6GMCBrqkI/Nls6UqLTKa5K9FGi4ZdWIB27u IO1GljYJgq1CLhY2kqIe7Nx6wZ/ADGyOZ6JqcgNvDDaPlCHHxn1X70aqHyMmumEE0= X-Received: by 2002:a17:906:f592:b0:b86:fca7:3dc2 with SMTP id a640c23a62f3a-b87968d4b0bmr216093366b.10.1768573701522; Fri, 16 Jan 2026 06:28:21 -0800 (PST) Message-ID: <5270a5d9-96c5-44b9-b61b-ce1dc35453e8@gmail.com> Date: Fri, 16 Jan 2026 15:28:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] build/non-x86: fix symbol lookup in presence of build-id To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Bertrand Marquis , Volodymyr Babchuk , Timothy Pearson , Mykola Kvach References: Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/16/26 11:52 AM, Jan Beulich wrote: > It's not clear why only x86 had $(build_id_linker) applied to all three > linking passes. Not doing so will alter symbol offsets between the 2nd > and 3rd passes for, potentially, all of the symbols at higher addresses > (intermediate alignment padding may mask this effect, though, so it will > look as if problems appeared randomly). > > Fixes: a353cab905af ("build_id: Provide ld-embedded build-ids") > Reported-by: Mykola Kvach > Signed-off-by: Jan Beulich ... > --- a/xen/arch/riscv/Makefile > +++ b/xen/arch/riscv/Makefile > @@ -28,13 +28,13 @@ $(TARGET): $(TARGET)-syms > $(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds > $(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S > $(MAKE) $(build)=$(@D) $(dot-target).0.o > - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< \ > + $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ > $(dot-target).0.o -o $(dot-target).0 > $(NM) -pa --format=sysv $(dot-target).0 \ > | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ > > $(dot-target).1.S > $(MAKE) $(build)=$(@D) $(dot-target).1.o > - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< \ > + $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ > $(dot-target).1.o -o $(dot-target).1 > $(NM) -pa --format=sysv $(dot-target).1 \ > | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ Reviewed-by: Oleksii Kurochko ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Jan 16 14:43:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 14:43:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206724.1520072 (Exim 4.92) (envelope-from ) id 1vgl2O-00029Y-KJ; Fri, 16 Jan 2026 14:42:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206724.1520072; Fri, 16 Jan 2026 14: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 1vgl2O-00029R-Hc; Fri, 16 Jan 2026 14:42:56 +0000 Received: by outflank-mailman (input) for mailman id 1206724; Fri, 16 Jan 2026 14:42: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 1vgl2N-00029L-Ic for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 14:42:55 +0000 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [2a00:1450:4864:20::42f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9f344dc0-f2e9-11f0-b15e-2bf370ae4941; Fri, 16 Jan 2026 15:42:46 +0100 (CET) Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-42fb6ce71c7so1933853f8f.1 for ; Fri, 16 Jan 2026 06:42:46 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43569927007sm5491907f8f.16.2026.01.16.06.42.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Jan 2026 06:42:45 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9f344dc0-f2e9-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768574566; x=1769179366; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=8Y4wHI16YUXLiieGFEpwUAV2tNBHO1pG5DY/2eh2MmY=; b=R/EMqpZ7qSLoEbpIs1UlsFliKDGrKReb74MNGDTiPxuK1sUPcy/HlO8Cv1fKzOmS58 ZKxk4N+NCKHNFvhCvFJF4zE2NUvJz8dkA8RtjCTw86/9hfXd1/qRwVXlPC0pyW3IuGuV NGHh1rq3m4AVN3Y2xyWuLQtYg93vt/U3KbFJ8JWL2kZxjvBO6TpL/qXfl33NLML3LHjX mjQm5ReWRZ9C1ZMkRbUhXs/DU/6NxH9Ty0kxqAQTpEwQYyGz0poEsewDi+H+oKoIAtkd YUQS8T9BZPedEiGz1dCxHilcH4K0+2bSfebmMlssjH2XKCc/DFlJ5nBKQwgwDXlHinSj xKWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768574566; x=1769179366; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8Y4wHI16YUXLiieGFEpwUAV2tNBHO1pG5DY/2eh2MmY=; b=ZcmyUcV7b3VAGqXl93gu7yK42+AfLPvZKbjJ0lCJxvSS1Zep2bW4s9McYVMSTkEWWt ZFyyGuSrjmNG+23D2HS7sYH/BkPR0rqFB56YAuYA74pbhQrw2G/5R4BUMi6vWwZAm2wA yAGtz9CHKuQNwwZ7I4HEhYdtk+x0e6u3R0kxyFWOXjhxm+eTTj+ptAa8dI+sUUEkiqWI LeCeQTeB+Z3QoNNjqyOaKboYz2spC4mTVutAqIPciJK0jnzdgPds/ZIMLTjE7bz2jor9 aEZ6d8ZfDhaUTNfJUYOIc9mOWIB9WVpTqSZyt0f51N5uH8y7k4IItWwsox3hgutabKcx UtEQ== X-Forwarded-Encrypted: i=1; AJvYcCX3V1MHJE/UTuupYbcTvS7vgMQJGI0dsb48tgHQFBN9PvOzg6oVo6WX7tdaFoHmIWTrJSfioYp1fsE=@lists.xenproject.org X-Gm-Message-State: AOJu0YzkEDk77er+iiU90UXFh0X4Z+CucNu4fbbhJIyGfUJ7fVsdTW5N LId8qTHsvMMxj+euItWtMJuM+AdsYjVirFTc9ZvW7dbri0Rx1Y+yswu25PF764GazQ== X-Gm-Gg: AY/fxX6CAXVha5T8HVE1bnQIqIv5kCjx5EqZiiXiLwEU4H+MATj3wp41JS4ZvNShwFS TrXD2Njb8XVzC1uv90inDzO8A10hZ5Zl1jHglO7tEROikndvQUo3dqJQvmEgFQvdWyD7XXQ7jX4 oPHh0xtFK1F1W3cUiVVFUwbaV40rCTjGnqWPV+npcabtRBxJdJY0bZGPbXAdDsloL1Uzs94xrwt 9CtZEfD2oLcqqQeK9ZueI+yqo/ETSTQdnxVuZrBuMERq5s59Z5KuWKlVrhF1vmqpEkOKQ8WNa3O YgVPmqLpXYCmKEXmCJeMJMzrTQpkidH0CMlP8o66HZSLxi2F8Q7VkMtwIwpwiPdJP9ipDA1jfoN IZRCKPJsFr7XlD9SihsPVWqsVzF7yvA+bwoVGWKtH4vVHu4VnD0QF5WyETVNuT3UeRo3X4/Dvhb IQtaYZetcqRwEzohq+leJrRPs1ct06thaeib7eZrTRRaM5hJ9ASluMueznwPrRVEP9yEKqvr/Ub 4E= X-Received: by 2002:a5d:5f95:0:b0:42f:b690:6788 with SMTP id ffacd0b85a97d-4356997f4afmr4229753f8f.10.1768574565610; Fri, 16 Jan 2026 06:42:45 -0800 (PST) Message-ID: Date: Fri, 16 Jan 2026 15:42:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 07/15] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <9212924e-8f3a-4797-8c3b-149ff7c4b03e@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: <9212924e-8f3a-4797-8c3b-149ff7c4b03e@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 16.01.2026 15:25, Oleksii Kurochko wrote: > > On 1/7/26 5:28 PM, Jan Beulich wrote: >>> + >>> + /* >>> + * VCPU interrupts >>> + * >>> + * We have a lockless approach for tracking pending VCPU interrupts >>> + * implemented using atomic bitops. The irqs_pending bitmap represent >>> + * pending interrupts whereas irqs_pending_mask represent bits changed >>> + * in irqs_pending. >> And hence a set immediately followed by an unset is then indistinguishable >> from just an unset (or the other way around). This may not be a problem, but >> if it isn't, I think this needs explaining. > > I am still not sure that this is actually a problem, or what kind of explanation > is needed. > |unset| is called only when the guest makes such a request, and the guest will > make that request only after it has received an interrupt that was previously > set in the|irq_pending| bitmap and then flushed to the hardware HVIP. > > If an interrupt is simply set and then unset without ever being flushed to the > hardware HVIP, it seems there would be no issue, since it would not affect the > guest. However, the question of why this happened at all would still remain. > > Do I miss some corner cases which should be taken into account? > Should I still have to add some extra explanation to the comment or commit > message? Perhaps the problem is that really I can't see the full picture yet, for the series not putting everything in place that is related. Jan From xen-devel-bounces@lists.xenproject.org Fri Jan 16 16:16:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 16:16:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206799.1520083 (Exim 4.92) (envelope-from ) id 1vgmV2-00058X-2H; Fri, 16 Jan 2026 16:16:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206799.1520083; Fri, 16 Jan 2026 16:16:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgmV1-00058Q-Uj; Fri, 16 Jan 2026 16:16:35 +0000 Received: by outflank-mailman (input) for mailman id 1206799; Fri, 16 Jan 2026 16:16:34 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgmV0-00058K-8u for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 16:16: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 b74104e4-f2f6-11f0-9ccf-f158ae23cfc8; Fri, 16 Jan 2026 17:16:30 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by AM7PR03MB6277.eurprd03.prod.outlook.com (2603:10a6:20b:13a::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.6; Fri, 16 Jan 2026 16:16:27 +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.9520.005; Fri, 16 Jan 2026 16:16: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: b74104e4-f2f6-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gtUbdQx23h0RUEKfnYFvwBJKCQbXp0fagQe3XR7cS+XfnLhpjtgNGNJgcJ7iWHSP9hGjKi27TvIu30CjP2utMy8jzXgjPj/fWhuzALGkiWvidLbISL3eJDJNhvLFLHLx8U/X7HR/c0II/UafkI1IRry9dLsZAsNgaplTUXM79K6EJnNePJscfjIqpM4f7OQU68VNgK7bE6Pf88PY3/Ltw6XblwkSeugmlls6xaVhjX9FjLY8cy3um5zM330vp+uXU+y/kt3vooKn2DkHIiC13LKcOAQMpv/aEcDEzrt2+gK6Nyapt6jMRTnDRfjUCTuyEfC9lwnFnFHsbAu57mLbGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oLKFSAlMeusNbERuOhCU51le1OIaZALEZvhqNbk1bKY=; b=toggv2RhhKwQltFo9zIfjSLy8/iStEmWAL0vgdtyxdrewbteZhCXilTa/rMokIhTcERxb1undApVep2Nff3DKyMYbUNKIO0Hz7+Z3FsYrXpR/FHuJ1euZoH1oypFLLn9emTy9TVw8c5mLeMCC/Vk/o5N/cJ89CIMyj2I42r0fcEyAfnk8+jCIHDKBJXdfqNIDMcKxDidfIuyliL0mKNrx6d/Tq8YEb8HeTL1uZQBLCUNnhZut19hL9cUXZUrV1MtN0ksAv8OhrWZy5kHr00lA115nhkAtjhmIt7dWKVruNm5ZZPSGC+zVPJr0r2cFJ+P+EifA5kSIW2HkXy8SAxs3g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oLKFSAlMeusNbERuOhCU51le1OIaZALEZvhqNbk1bKY=; b=ndCv0mGi29v1yxTqjEWmva0+FnUEK+TlXazZGnZCvsZwPtf6bVXa81yX1v+PDMW4pmtdeJwl4xXzSwhfgDuGu4BDUozFG6cDEk9pq06V6i3YBGRhrbuyEUl1c1II+qIoh9phwd0lAyHsXYKEYvgVoBIg484Ly0wV+Dco4DxWeXgrdhhU1jswyp0i/pV/7rwXGE8isuLnHG7g7BUyPhh9kzL6XZArrksT3kGtvitjWvqR9qhR/lbmdCVQFkAZKN2e5D7AogO/4m41lKp1oLKbRaSh7wr1BX20GDWya4EeTbF03mdPQDU8app7CfLJBhQNCEvbEYUFKR8HPNOPv+qYAw== 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 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [PATCH v7 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHchYPEY703sAu32kaCSJHhjFUjhrVSbXkAgAKOa4A= Date: Fri, 16 Jan 2026 16:16:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PAVPR03MB8946:EE_|AM7PR03MB6277:EE_ x-ms-office365-filtering-correlation-id: dd1a80f1-6bdf-42cb-d491-08de551a99b7 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?aWQwN1J3aWtMMXRDUWl0SW40eCtCQTJaSDNBUnVHZm16L3pGQjh5ZWRmSklJ?= =?utf-8?B?aWI2QXFUeGZGMmJxZ3JUQjcvbzNuWVU4QmZtK0t1UU1LSURlZHQvcitvWUdk?= =?utf-8?B?VEVFVTNQYlJPaTNvdTRPVWcwOERtUzRkVDBpMzE4T3RpMGNjN1NHa1VVREZ2?= =?utf-8?B?QlZpT1RIY01BOGFpTHdEN2tWd0ZadXJHWXEyQkVtTm51a0gxSE0zVnFyRjM2?= =?utf-8?B?ZlAySitBMmN3NkVJd29oZkhOSmpuaEYzTTAzTGlOZnc2d25GTWlHdmZvc1NY?= =?utf-8?B?bzB2YzdRVWx6SWNVRHdEeEJwazJMdlB1WjdmN3Vja2l5K244c2IybklBZ2hS?= =?utf-8?B?T3hVRy91TzFabHlSV2RmUWllMGtwbWVUZy9JZzV6b1h0MFkrYi91RGkrMFhS?= =?utf-8?B?MGorR2hYa1hvTExtQW9GMy9lYXJTYUxGT0lFYVhKUFBDbDJRYU1mNmlQWmk1?= =?utf-8?B?Mmx0a2ZKMEc1UGt4WnlzcUlEOFdnZWVTYlowRlJ0QVJGSlJaSlAyZklMV3By?= =?utf-8?B?RU1lcTdheWFJNHJjeDhjcUxLbDZSL0VzKzc4dDVxWVNYRFU5ZXlaRUprWUZ0?= =?utf-8?B?blFKZWovQW5sSzAxUmNZRDErTXRjMVJydFc0ZjZHMVM3bkFqa2xBV3AvZVFS?= =?utf-8?B?b1BBOUlOZENTZHB5Vis3TDdmNktpbEdPSWk5OXFidTBtV05PQVFtcHY4VEJP?= =?utf-8?B?Rm5nR2o3elh3L3JaSEcwaTNTOHNvanlTU1RtdUJUejJmazh2ak9DTUplVUpk?= =?utf-8?B?VnF5TzQ3MnhBV2lnMDVGQXl2cWUvREpCeUJkOGw0ZmVZM3YwM3dEb3NEdWU3?= =?utf-8?B?ZEYxUlRFSWFSbXBYd2RyWmtUTHQ5S01xdGlDT2FIVFZuVVBRT0JEMm9KYmNO?= =?utf-8?B?eEZBWU9YNlNWUGFUdEdLbDhRU3BxQ21VUTk0OXJvak5JeEdXMjV1ZUJLUnhk?= =?utf-8?B?eFltNWx1b1JMbHI0RXdOaHBzejJjQU5WR3dnUlVkNmRnVjF3MitBeEVnSDJy?= =?utf-8?B?anltbmV5WEM0L0cxOGZGSkk5ZXhQc0lvWWhMc3lOSkR1dUNnYUN2MDBYc2oy?= =?utf-8?B?WGZDM1Mzckx6VExIUkNGQitmajRXOUVyVXZCUldzTVI1UVkvN2N4d0hycEtU?= =?utf-8?B?ZFVwMmNQY3cvWnRrREpYcVZsMit2VXFVbmluNUw4ODA3TGlKUld2L2RrRkpy?= =?utf-8?B?TnBTWEoyUHVJSTErcTh5ZjV2MXYrM1c1TW5HTGZWakhqSTVNRE1lZEpnZDl6?= =?utf-8?B?OFpXQWxJRlhzcjBienlNSldCV0F5Z2xPTTRtc3lzbHhBcmFTSTlmbmxHU3ZT?= =?utf-8?B?eFAyMXJlM3BVUm0vOTJLa0Fja3pXUGc3L05oNHNEUUQrQTYzcWRHS1YySDdO?= =?utf-8?B?OW1FTGsxdS9xalhkT2xGRTZrd1NPWDFVU1ZCek1qQ3JZYlAwU1BNMTFweStK?= =?utf-8?B?TUpvSFhNSHJWMEZmRHhyU3dwRU5MQVJQL2hWNWx5UDR4VzZNVU1wRnNXZ2Qx?= =?utf-8?B?R09aZWJaaURkcHpXdnZWNnhmZkFHR0pvWFkreVpDN2YzNlpXYkxKcVN6L3Jz?= =?utf-8?B?WENya09mMEdCMTgwM0ppZmVhRmlaUXMyZktYZ0xGV1doTW00ZHdRRXNkOGNw?= =?utf-8?B?SmZyY3hsNkEwc1RQNWlBb2MyM0RXYkhwTGR3d2JMRVN6Yk1scmtCcUJKVTZ1?= =?utf-8?B?REZIa2YvdFN5bVBzZmhoZEczN2NMSXVUblY3aDh3NkJ4TlNWQUFIK1lvbkxk?= =?utf-8?B?czN3V1BFalMvSFFHb3k3eXpuOVdQeWtnWU9NVUFkcHBlVVRERmFvN0ZxVjND?= =?utf-8?B?cXNTOEpjN042c1JMdFU3SVB5b2s2TmJDQjZpQVlRZUNRS29qY0M0ZUxFSjdZ?= =?utf-8?B?dDJ2SDJDK0hkVFlnbzN5T25DZEVJNTNnZk5WVzBuUmFVVnk2QnYrK1BrajZ0?= =?utf-8?B?TkRoVUpUSU1MY2lDUFZyQ3R4Q2VnNndlcXhyRlVQeVMzaGxkNTR4UWVlY05W?= =?utf-8?B?NVhYby9rOTgweW9tRnRja084QUdFUTJtTFE2UXVBZU50K01La2ZhbUtaZy8w?= =?utf-8?B?eDltT0FTS2dWR2pLMGFKQVdQdWZFWE9PRzBSSndraTZNbG9KWGJMWEtNWm5J?= =?utf-8?B?dEExQ256cHJHRGlMazFHSTNZZG9reW45U3ZVcFo5aS9LSHpaUXNPUE0raFls?= =?utf-8?Q?j42mlEQpWNn9/FxJ7bPA7Eo=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?Um5vSWZBcW5zNThiaDJkckxjRE90ODhKWm9KKzdWcWpNUGtrSFpibG1rYUlL?= =?utf-8?B?RXFBdmhBdTFORVo5ajA2TFE5N3ZwZ2xLaVA2NFRVYmtNMzJpdDliNUp4SER3?= =?utf-8?B?RXJnQzE1RUFhdnBKb2NDN2hHbWx3S05BOEFJSTNjQ1F1alpoTGR1OVUxWity?= =?utf-8?B?bjJtejd6aURTWTJMRExkY2hWdngxSDN0UFNObkxzeDUxc3h6NUM0b1FHNXp4?= =?utf-8?B?OGxYOFFwN2xyNzZCcEFXb3VsUlFJWGtad3d5MHlwQzUyeXVnK1piR1hOb3gy?= =?utf-8?B?ZXVoQkpocE1zZ1FmRjlVSFVreU0vMlJLS1UwY1Z0RDAyaXJ5V25CeEtWRGtm?= =?utf-8?B?YVFsRjlmeERnbG9rTllNNnZlN3hmaXZzcHVkbFJmRzFjMUVnQjFWTW94Umxs?= =?utf-8?B?dmJ6cG53Qm1lMkZBMmNwb3BJUVlIRVJ5bGVUSFNSOStSYlFSRG9UZkd4aFBE?= =?utf-8?B?MzUxUi80ZW9QLy9zcCtTZUNKT09NM1lEVGdDNGh3bU9IRW01aTJnWHkrUWFa?= =?utf-8?B?SnNiSTZHZXNVUDdkaXp6a2VJYVVWU2w5ZG1sajBydERmTEQrWDZZVnRESnBr?= =?utf-8?B?eHh0aUxkUUZBT2VSYUNCdFVpSXNDUkVKQmJWejBPZVgwenZuSnI4aml2YUtX?= =?utf-8?B?bzMxNzlDU1NiSXgvUFBkUHpOSDBlUTVXaXMvRjJWWTFVS2N0cGtySkRyR3R3?= =?utf-8?B?WFNPWElqcXo0WUQ4UlVKd3ppOFZqcFVGUUZZM3pHZmt4clpOUi9MMUF1Wnht?= =?utf-8?B?cGsrTnB3K1hPdjJqQVgwVjNMRlBiZnlRZEFMeXN3M3oxTHM3WHp5VVF1QjlJ?= =?utf-8?B?dThtOGI3TmlTcUtRVGtObVBNNi9rb2dJSGNDc2xaWWtzbVB5b1ZKM2NzNWdI?= =?utf-8?B?aVYzR1dLaG10QkRQL09JcnNZZXkyMnJrSU9QRUdxZzJ5aHlIZERSdGtsaDZS?= =?utf-8?B?VUtxZ1YwM2pnbzFVU2lXQUQwaitnK1gxRTUzY3FhVmhwZWgvOHlDZ2VXZStk?= =?utf-8?B?RFVzU1c0WEhRZVVZeERuazExZCtCM3FQUEpwK3hOeHhyOVlua0hPRHpyYTJB?= =?utf-8?B?QlNobXFCaHVxYnI1TllEZUxGcm1USmFOeUFvdElvd0ZaWHFOUU1Nd0NIZlp0?= =?utf-8?B?ajhWbnA1MVRZLzJSZVZPRk5BOGpYWmREb2w1QlJvOHB3UDdsQ0locmRmQ050?= =?utf-8?B?cnpxd25jc0RTV2plVWtVQUlIL0VDaG9tL2NCYzhyUlRoK2czTVdpckRpdlJl?= =?utf-8?B?eTFoNG1QUEp0Mzh0bFhDMVNrRTZ0UEdHRlNyUEtZWnovK2NEU1VnSnE4VkU1?= =?utf-8?B?Mkc2TkJZd2JUUUFVait3aERZazN2L3FLZGhPS1BUMFI2M3lFKzBJaHExTEN5?= =?utf-8?B?NERmUlIzNWJ2VkxuSXMydm9ldXBlWGx5bE1hbzRzY2JXQVpVdzAwQ1hSeTcv?= =?utf-8?B?dko1QSszUU1yRGdhUElBdVFRN051UUJkejA2RGhXa3NmampPaDF6QUczV1hI?= =?utf-8?B?azlib016ZXA4azJSTmI3SWxOc3Q3QS8xZ2pLTyt6Z05aTUpsZERyRVhDUTU0?= =?utf-8?B?d2c5Z0gwaVJVOGkwNGNJNlFLNXBocEg2R3Z3dnNZQVZyemxrVmphZEt1RGpO?= =?utf-8?B?YWhNcXZObWxqZ3RyYk94NGhucjgxNk5FTm5GZDcvSThvWUpONFA4NTBJZXhz?= =?utf-8?B?bndmRG5TMkRjbUpuUXN6ZEVnL1UyY1FVVGVMcHlrL1hLN3dSc094ckRiWXVw?= =?utf-8?B?RnhuanltQW5NL3ZNWGp6VnJpQzRiMEp5Tko1OVJSVUZ6bUxkNWNIRGhocUhr?= =?utf-8?B?ai9Sd1J4RXBHU0VLYkF2N2hVbkFUL1VxaVQ5bWM5TlNuKzNOYjJ5YUpzZEtl?= =?utf-8?B?cHFQa2VXVmFWdnlwSCt0WmVFS1VHOS9OelRoOTlyY0Y3OHNVMU9uQU85eWVH?= =?utf-8?B?SjFLREt4NkRROWFDMVltUUFrUXJoUEZJOHdCMjdDYWlWVmp0SFRGaUdic0Rh?= =?utf-8?B?MFFsWSsrN0FZc0E2eEFMSTZVQTYwUU1wekZzTnU1bEtqbEp2RVJUcndaS0tn?= =?utf-8?B?YU14Y0ZFUmtuV1lCOHI3cVFuSk4xRU5XaTFTdTNSTnpzeTE5N2V0ZDk2dERx?= =?utf-8?B?c0VWbFR4WkJjL3hwVUYwS01rV2p6MTJYUVlGdmdaV0dCVWRtN1hKSzBINWtW?= =?utf-8?B?SUJWL2ZMV2NzQ1p3UmRFLzcwYXZza3NxUU5oMEtLV2hlWHY5akJQVnZFTGRO?= =?utf-8?B?Y05pVTBKL01Ia2dLV3RxT3V1ZWdWVFd0ZkF6dlptQjdLUXNzK2FyZVppY1BI?= =?utf-8?B?cGVHUUd4NTNnNitXc0g4cWYzbUJpUWlLSHA1V2pFVWZ5dlYxSkplQnNzQzdT?= =?utf-8?Q?t87a13zC947T3b/A=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: PAVPR03MB8946.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dd1a80f1-6bdf-42cb-d491-08de551a99b7 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2026 16:16:26.9297 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zfXzYKmuyxk79yexxAauawJUrpO/k0uFMI2XfbYTe5cLytYQY8kzEddNtK73gH49tTb/gVNmup2DWT9vJbczopLEJfVONXQCH/EamKUtjhg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR03MB6277 SGkgU3RlZmFubywNClBsZWFzZSBzZWUgYmVsb3cuDQoNCk9uIDE1LzAxLzIwMjYgMDM6MTQsIFN0 ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4gSGkgT2xla3NpaSwNCj4NCj4gSSBhbSBmaW5lIHdp dGggdGhlIGdvYWxzIGFuZCB0aGUgc3RyYXRlZ3kgdG8gYWNoaWV2ZSB0aGUgZ29hbHMgYnV0IHRo ZXJlDQo+IGFyZSBzb21lIGZpbmVyIGRldGFpbHMgdGhhdCBkb24ndCBtYWtlIHNlbnNlIHRvIG1l LiBJIGFwb2xvZ2l6ZSBpZiBJIGFtDQo+IGFza2luZyB0aGUgc2FtZSBxdWVzdGlvbnMgeW91IGhh dmUgYWxyZWFkeSBhbnN3ZXJlZCBhcyBzb21lIHRpbWUgYXMNCj4gcGFzc2VkIGZyb20gdGhlIGxh c3QgaW50ZXJhY3Rpb24uDQo+DQo+DQo+IE9uIFdlZCwgMTQgSmFuIDIwMjYsIE9sZWtzaWkgTW9p c2llaWV2IHdyb3RlOg0KPj4gVGhpcyBwYXRjaCBpbnRyb2R1Y2VzIFNDSSBkcml2ZXIgdG8gc3Vw cG9ydCBmb3IgQVJNIEVMMyBUcnVzdGVkIEZpcm13YXJlLUENCj4+IChURi1BKSB3aGljaCBwcm92 aWRlcyBTQ01JIGludGVyZmFjZSB3aXRoIG11bHRpLWFnZW50IHN1cHBvcnQsIGFzIHNob3duDQo+ PiBiZWxvdy4NCj4+DQo+PiAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rDQo+PiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 DQo+PiAgICB8IEVMMyBURi1BIFNDTUkgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+PiAg ICArLS0tLS0tLSstLSstLS0tLS0tKy0tKy0tLS0tLS0rLS0rLS0tLS0tLSsrDQo+PiAgICB8c2ht ZW0xIHwgIHxzaG1lbTAgfCAgfHNobWVtMiB8ICB8c2htZW1YIHwNCj4+ICAgICstLS0tLSstKyAg Ky0tLSstLS0rICArLS0rLS0tLSsgICstLS0rLS0tKw0KPj4gc21jLWlkMSB8ICAgICAgICB8ICAg ICAgICAgfCAgICAgICAgICAgfA0KPj4gYWdlbnQxICB8ICAgICAgICB8ICAgICAgICAgfCAgICAg ICAgICAgfA0KPj4gICAgKy0tLS0tdi0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0t Kw0KPj4gICAgfCAgICAgICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgIHwgICAgfA0KPj4g ICAgfCAgICAgICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgIHwgICAgfA0KPj4gICAgKy0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tKw0KPj4gICAgICAgICAgIHNt Yy1pZDAgfCAgc21jLWlkMnwgICAgc21jLWlkWHwNCj4+ICAgICAgICAgICBhZ2VudDAgIHwgIGFn ZW50MiB8ICAgIGFnZW50WCB8DQo+PiAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICAg ICAgICAgfA0KPj4gICAgICAgICAgICAgICstLS0tdi0tLSsgICstLXYtLS0tLSsgICstLXYtLS0t LSsNCj4+ICAgICAgICAgICAgICB8ICAgICAgICB8ICB8ICAgICAgICB8ICB8ICAgICAgICB8DQo+ PiAgICAgICAgICAgICAgfCBEb20wICAgfCAgfCBEb20xICAgfCAgfCBEb21YICAgfA0KPj4gICAg ICAgICAgICAgIHwgICAgICAgIHwgIHwgICAgICAgIHwgIHwgICAgICAgIHwNCj4+ICAgICAgICAg ICAgICB8ICAgICAgICB8ICB8ICAgICAgICB8ICB8ICAgICAgICB8DQo+PiAgICAgICAgICAgICAg Ky0tLS0tLS0tKyAgKy0tLS0tLS0tKyAgKy0tLS0tLS0tKw0KPj4NCj4+IFRoZSBFTDMgU0NNSSBt dWx0aS1hZ2VudCBmaXJtd2FyZSBpcyBleHBlY3RlZCB0byBwcm92aWRlIFNDTUkgU01DIHNoYXJl ZA0KPj4gbWVtb3J5IHRyYW5zcG9ydCBmb3IgZXZlcnkgQWdlbnQgaW4gdGhlIHN5c3RlbS4NCj4+ DQo+PiBUaGUgU0NNSSBBZ2VudCB0cmFuc3BvcnQgY2hhbm5lbCBkZWZpbmVkIGJ5IHBhaXI6DQo+ PiAgIC0gc21jLWlkOiBTTUMgaWQgdXNlZCBmb3IgRG9vcmJlbGwNCj4+ICAgLSBzaG1lbTogc2hh cmVkIG1lbW9yeSBmb3IgbWVzc2FnZXMgdHJhbnNmZXIsIFhlbiBwYWdlDQo+PiAgIGFsaWduZWQu IFNoYXJlZCBtZW1vcnQgaXMgbWFwcGVkIHdpdGggdGhlIGZvbGxvd2luZyBmbGFnczoNCj4+ICAg TVRfREVWSUNFX25HblJFLg0KPj4NCj4+IFRoZSBmb2xsd29pbmcgU0NNSSBBZ2VudHMgYXJlIGV4 cGVjdGVkIHRvIGJlIGRlZmluZWQgYnkgU0NNSSBGVyB0byBlbmFibGUgU0NNSQ0KPj4gbXVsdGkt YWdlbnQgZnVuY3Rpb25hbGl0eSB1bmRlciBYZW46DQo+PiAtIFhlbiBtYW5hZ2VtZW50IGFnZW50 OiB0cnVzdGVkIGFnZW50cyB0aGF0IGFjY2Vzc2VzIHRvIHRoZSBCYXNlIFByb3RvY29sDQo+PiBj b21tYW5kcyB0byBjb25maWd1cmUgYWdlbnQgc3BlY2lmaWMgcGVybWlzc2lvbnMNCj4+IC0gT1NQ TSBWTSBhZ2VudHM6IG5vbi10cnVzdGVkIGFnZW50LCBvbmUgZm9yIGVhY2ggR3Vlc3QgZG9tYWlu IHdoaWNoIGlzDQo+PiAgICBhbGxvd2VkIGRpcmVjdCBIVyBhY2Nlc3MuIEF0IGxlYXN0IG9uZSBP U1BNIFZNIGFnZW50IGhhcyB0byBiZSBwcm92aWRlZA0KPj4gICAgYnkgRlcgaWYgSFcgaXMgaGFu ZGxlZCBvbmx5IGJ5IERvbTAgb3IgRHJpdmVyIERvbWFpbi4NCj4+DQo+PiBUaGUgRUwzIFNDTUkg RlcgaXMgZXhwZWN0ZWQgdG8gaW1wbGVtZW50IGZvbGxvd2luZyBCYXNlIHByb3RvY29sIG1lc3Nh Z2VzOg0KPj4gLSBCQVNFX0RJU0NPVkVSX0FHRU5UIChvcHRpb25hbCBpZiBhZ2VudF9pZCB3YXMg cHJvdmlkZWQpDQo+PiAtIEJBU0VfUkVTRVRfQUdFTlRfQ09ORklHVVJBVElPTiAob3B0aW9uYWwp DQo+PiAtIEJBU0VfU0VUX0RFVklDRV9QRVJNSVNTSU9OUyAob3B0aW9uYWwpDQo+Pg0KPj4gVGhl IFNDSSBTQ01JIFNNQyBtdWx0aS1hZ2VudCBkcml2ZXIgaW1wbGVtZW50cyBmb2xsb3dpbmcNCj4+ IGZ1bmN0aW9uYWxpdHk6DQo+PiAtIFRoZSBkcml2ZXIgaXMgaW5pdGlhbGl6ZWQgZnJvbSB0aGUg WGVuIFNDTUkgY29udGFpbmVyIGBgeGVuX3NjbWlfY29uZmlnYGANCj4+ICAgIChjb21wYXRpYmxl IGBgeGVuLHNjaWBgKSBwbGFjZWQgdW5kZXIgYGAvY2hvc2VuL3hlbmBgLiBPbmx5IHRoZQ0KPj4g ICAgYGBhcm0sc2NtaS1zbWNgYCBub2RlIHRoYXQgaXMgYSBjaGlsZCBvZiB0aGlzIGNvbnRhaW5l ciB3aWxsIGJpbmQgdG8gWGVuOw0KPj4gICAgb3RoZXIgU0NNSSBub2RlcyAoZm9yIGV4YW1wbGUg dW5kZXIgYGAvZmlybXdhcmVgYCkgYXJlIGlnbm9yZWQgdG8gYXZvaWQNCj4+ICAgIHN0ZWFsaW5n IHRoZSBob3N0IE9TUE0gaW5zdGFuY2UuDQo+Pg0KPj4gc2NtaV9zaG1fMTogc3JhbUA0N2ZmMTAw MCB7DQo+PiAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4gICAg ICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjEwMDAgMHgwIDB4MTAwMD47DQo+PiB9Ow0KPj4gc2Nt aV94ZW46IHNjbWkgew0KPj4gICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zbWMiOw0K Pj4gICAgICAgICAgYXJtLHNtYy1pZCA9IDwweDgyMDAwMDAzPjsgPC0tLSBYZW4gbWFuYWdlbWVu dCBhZ2VudCBzbWMtaWQNCj4+ICAgICAgICAgICNhZGRyZXNzLWNlbGxzID0gPCAxPjsNCj4+ICAg ICAgICAgICNzaXplLWNlbGxzID0gPCAwPjsNCj4+ICAgICAgICAgICNhY2Nlc3MtY29udHJvbGxl ci1jZWxscyA9IDwgMT47DQo+PiAgICAgICAgICBzaG1lbSA9IDwmc2NtaV9zaG1fMT47IDwtLS0g WGVuIG1hbmFnZW1lbnQgYWdlbnQgc2htZW0NCj4+IH07DQo+Pg0KPj4gLSBUaGUgZHJpdmVyIG9i dGFpbnMgWGVuIHNwZWNpZmljIFNDTUkgQWdlbnQncyBjb25maWd1cmF0aW9uIGZyb20gdGhlDQo+ PiAgICBIb3N0IERULCBwcm9iZXMgQWdlbnRzIGFuZCBidWlsZHMgU0NNSSBBZ2VudHMgbGlzdC4g VGhlIEFnZW50cw0KPj4gICAgY29uZmlndXJhdGlvbiBpcyB0YWtlbiBmcm9tICJzY21pLXNlY29u ZGFyeS1hZ2VudHMiIHByb3BlcnR5IHdoZXJlDQo+PiAgICBmaXJzdCBpdGVtIGlzICJhcm0sc21j LWlkIiwgc2Vjb25kIC0gImFybSxzY21pLXNobWVtIiBwaGFuZGxlIGFuZA0KPj4gICAgdGhpcmQg aXMgb3B0aW9uYWwgImFnZW50X2lkIjoNCj4+DQo+PiAvIHsNCj4+ICAgIGNob3NlbiB7DQo+PiAg ICAgIHhlbiB7DQo+PiAgICAgICAgcmFuZ2VzOw0KPj4gICAgICAgIHhlbl9zY21pX2NvbmZpZyB7 DQo+PiAgICAgICAgICBjb21wYXRpYmxlID0gInhlbixzY2kiOw0KPj4gICAgICAgICAgI2FkZHJl c3MtY2VsbHMgPSA8Mj47DQo+PiAgICAgICAgICAjc2l6ZS1jZWxscyA9IDwyPjsNCj4+ICAgICAg ICAgIHJhbmdlczsNCj4+DQo+PiAgICAgICAgICBzY21pX3NobV8wOiBzcmFtQDQ3ZmYwMDAwIHsN Cj4+ICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+PiAgICAgICAg ICAgIHJlZyA9IDwweDAgMHg0N2ZmMDAwMCAweDAgMHgxMDAwPjsNCj4+ICAgICAgICAgIH07DQo+ Pg0KPj4gICAgICAgICAgLyogWGVuIFNDTUkgbWFuYWdlbWVudCBjaGFubmVsICovDQo+PiAgICAg ICAgICBzY21pX3NobV8xOiBzcmFtQDQ3ZmYxMDAwIHsNCj4+ICAgICAgICAgICAgY29tcGF0aWJs ZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+PiAgICAgICAgICAgIHJlZyA9IDwweDAgMHg0N2ZmMTAw MCAweDAgMHgxMDAwPjsNCj4+ICAgICAgICAgIH07DQo+Pg0KPj4gICAgICAgICAgc2NtaV9zaG1f Mjogc3JhbUA0N2ZmMjAwMCB7DQo+PiAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWkt c2htZW0iOw0KPj4gICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjIwMDAgMHgwIDB4MTAwMD47 DQo+PiAgICAgICAgICB9Ow0KPj4NCj4+ICAgICAgICAgIHNjbWlfc2htXzM6IHNyYW1ANDdmZjMw MDAgew0KPj4gICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxzY21pLXNobWVtIjsNCj4+ICAg ICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYzMDAwIDB4MCAweDEwMDA+Ow0KPj4gICAgICAgICAg fTsNCj4+DQo+PiAgICAgICAgICBzY21pLXNlY29uZGFyeS1hZ2VudHMgPSA8DQo+PiAgICAgICAg ICAgIDB4ODIwMDAwMDIgJnNjbWlfc2htXzAgMA0KPiAweDgyMDAwMDAyIGlzIHRoZSBzYW1lIGZ1 bmNfaWQgYXMuLi4NCj4NCj4NCj4+ICAgICAgICAgICAgMHg4MjAwMDAwNCAmc2NtaV9zaG1fMiAy DQo+PiAgICAgICAgICAgIDB4ODIwMDAwMDUgJnNjbWlfc2htXzMgMz47IDwtLS0gZnVuY19pZCwg c2htZW0sIGFnZW50X2lkDQo+PiAgICAgICAgICAjc2NtaS1zZWNvbmRhcnktYWdlbnRzLWNlbGxz ID0gPDM+Ow0KPj4NCj4+ICAgICAgICAgIHNjbWlfeGVuOiBzY21pIHsNCj4+ICAgICAgICAgICAg Y29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zbWMiOw0KPj4gICAgICAgICAgICBhcm0sc21jLWlkID0g PDB4ODIwMDAwMDI+OyA8LS0tIFhlbiBtYW5hZ2VtZW50IGFnZW50IGZ1bmNfaWQNCj4gYXMgdGhl IG9uZSB1c2VkIGZvciBYZW4uIFRoaXMgY2Fubm90IGJlIHJpZ2h0Pw0KPg0KVGhhdCdzIHJpZ2h0 LiBIZXJlIHNob3VsZCBiZSAweDgyMDAwMDAzLg0KPj4gICAgICAgICAgICAjYWRkcmVzcy1jZWxs cyA9IDwxPjsNCj4+ICAgICAgICAgICAgI3NpemUtY2VsbHMgPSA8MD47DQo+PiAgICAgICAgICAg ICNhY2Nlc3MtY29udHJvbGxlci1jZWxscyA9IDwxPjsNCj4+ICAgICAgICAgICAgc2htZW0gPSA8 JnNjbWlfc2htXzE+OyA8LS0tIFhlbiBtYW5hZ2VtZW50IGFnZW50IHNobWVtDQo+PiAgICAgICAg ICB9Ow0KPj4gICAgICAgIH07DQo+PiAgICAgIH07DQo+PiAgICB9Ow0KPj4gfTsNCj4+DQo+PiAv IHsNCj4+ICAgICAgLyoNCj4+ICAgICAgICogSG9zdCBTQ01JIE9TUE0gY2hhbm5lbCAtIHByb3Zp ZGVkIHRvIHRoZSBEb20wIGFzIGlzIGlmIFNDTUkNCj4+ICAgICAgICogZW5hYmxlZCBmb3IgaXQs IGlnbm9yZWQgYnkgWGVuIG11bHRpLWFnZW50IG1lZGlhdG9yDQo+PiAgICAgICAqLw0KPj4gICAg ICBzY21pX3NobTogc3JhbUA0N2ZmMDAwMCB7DQo+PiAgICAgICAgICAgICAgY29tcGF0aWJsZSA9 ICJhcm0sc2NtaS1zaG1lbSI7DQo+PiAgICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYwMDAw IDB4MCAweDEwMDA+Ow0KPj4gICAgICB9Ow0KPiB0aGlzIGlzIHRoZSBzYW1lIGFzICZzY21pX3No bV8wIHdoaWNoIEkgZ3Vlc3MgaXMgaW50ZW5kZWQ/DQo+DQppdCBpcy4gdG8gbWF0Y2ggSG9zdCBE VC4NCj4+ICAgICAgZmlybXdhcmUgew0KPj4gICAgICAgIHNjbWk6IHNjbWkgew0KPj4gICAgICAg ICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zbWMiOw0KPj4gICAgICAgICAgYXJtLHNtYy1pZCA9 IDwweDgyMDAwMDAyPjsgPC0tLSBIb3N0IE9TUE0gYWdlbnQgc21jLWlkDQo+IGJ1dCB0aGlzIGFn YWluIGlzIHRoZSBzYW1lIHNtYy1pZCBtZWFudCB0byBiZSB1c2VkIGJ5IFhlbi4NCj4NCj4gSWYg MHg4MjAwMDAwMiBpcyB0aGUgcHJpdmlsZWdlZCBpbnRlcmZhY2UsIHRoZW4gaXQgaXMgT0sgZm9y IFhlbiBhbmQNCj4gYWxzbyBiYXJlbWV0YWwgTGludXggdG8gdXNlIGl0LCBidXQgTGludXggRG9t MCBzaG91bGQgbm90IGJlIHVzaW5nIGl0Pw0KPiBPciBpcyB0aGUgc21jLWlkIGludGVyY2hhbmdl YWJsZSBhbmQgbm90IG5lY2Vzc2FyaWx5IHRpZWQgdG8gdGhlDQo+IGFnZW50LWlkPw0KPg0KPiBJ IHRoaW5rIGVpdGhlciB3YXkgdGhpcyBkZXRhaWwgc2hvdWxkIGJlIGNsYXJpZmllZCBpbiB0aGUg ZG9jcy4gU3BlYWtpbmcNCj4gb2YgZG9jcywgdGhlIG5leHQgcGF0Y2ggaW50cm9kdWNpbmcgdGhl IGRvYyBpcyBub3QgdXAtdG8tZGF0ZSB3aXRoIHRoaXMNCj4gcGF0Y2guDQo+DQpJbiBteSBjdXJy ZW50IGNvbmZpZ3VyYXRpb24sIEkgaGF2ZSB0aGUgZm9sbG93aW5nIHNldHVwOg0KDQpUaGUgWGVu IHByaXZpbGVnZWQgaW50ZXJmYWNlIG9wZXJhdGVzIHRocm91Z2ggZnVuY19pZCAweDgyMDAwMDAz Lg0KZnVuY19pZCAweDgyMDAwMDAyIGlzIHVzZWQgZm9yIERvbWFpbi0wLCBpbiBvcmRlciB0byBr ZWVwIHRoZSBEZXZpY2UNClRyZWUgKERUKSBjb25zaXN0ZW50IGJldHdlZW4gWGVuIGFuZCBiYXJl LW1ldGFsIGNvbmZpZ3VyYXRpb25zLg0KSSBhbSB1bnN1cmUgaG93IGJlc3QgdG8gZG9jdW1lbnQg dGhpcywgc2luY2UgdGhlIGltcGxlbWVudGF0aW9uIGRvZXMNCm5vdCBzdHJpY3RseSByZXF1aXJl IHRoaXMgc3BlY2lmaWMgY29uZmlndXJhdGlvbiBhbmQgYWxsb3dzIGZsZXhpYmlsaXR5DQpmb3Ig dGhlDQplbmQgdXNlci4gTXkgaW50ZW50aW9uIGlzIHRvIHByb3ZpZGUgYW4gZXhhbXBsZSBjb25m aWd1cmF0aW9uIGluIHRoZSBEVA0KZXhhbXBsZXMgdGhhdCBpcyBtb3N0IGxpa2VseSB0byBiZSB1 c2VkIGFzIGEgcmVmZXJlbmNlIGZvciByZWFsLXdvcmxkDQpzZXR1cHMuDQoNCkF0IHRoaXMgc3Rh Z2UsIEkgYmVsaWV2ZSB0aGUgbW9zdCBhcHByb3ByaWF0ZSBhcHByb2FjaCBpcyB0byBpbmNsdWRl IGEgbm90ZQ0KaW4gdGhlIGRvY3VtZW50YXRpb24gc3RhdGluZyB0aGF0IHRoZSBleGFtcGxlcyBp bGx1c3RyYXRlIGEgY29uZmlndXJhdGlvbg0KdGhhdCBhbGlnbnMgd2VsbCB3aXRoIHRoZSBYZW4g YXJjaGl0ZWN0dXJlLCBidXQgb3RoZXIgY29uZmlndXJhdGlvbnMgYXJlDQpwb3NzaWJsZSBkZXBl bmRpbmcgb24gdXNlciByZXF1aXJlbWVudHMuDQo+PiAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9 IDwgMT47DQo+PiAgICAgICAgICAjc2l6ZS1jZWxscyA9IDwgMD47DQo+PiAgICAgICAgICBzaG1l bSA9IDwmc2NtaV9zaG0+OyA8LS0tIEhvc3QgT1NQTSBhZ2VudCBzaG1lbQ0KPj4NCj4+ICAgICAg ICAgIHByb3RvY29sQFh7DQo+PiAgICAgICAgICB9Ow0KPj4gICAgICAgIH07DQo+PiAgICAgfTsN Cj4+IH07DQo+Pg0KPj4gVGhpcyBhcHByb2FjaCBhbGxvd3MgZGVmaW5pbmcgbXVsdGlwbGUgU0NN SSBBZ2VudHMgYnkgYWRkaW5nDQo+PiBYZW4tc3BlY2lmaWMgcHJvcGVydGllcyB1bmRlciB0aGUg YGAvY2hvc2VuYGAgbm9kZSB0byB0aGUgSG9zdCBEZXZpY2UNCj4+IFRyZWUsIGxlYXZpbmcgdGhl IG1haW4gcGFydCB1bmNoYW5nZWQuIFRoZSBIb3N0IERUIFNDTUkgY2hhbm5lbCB3aWxsDQo+PiBi ZSBwYXNzZWQgdG8gRG9tMC4NCj4+DQo+PiBUaGUgWGVuIG1hbmFnZW1lbnQgYWdlbnQgaXMgZGVz Y3JpYmVkIGFzIGEgYGBzY21pX3hlbmBgIG5vZGUgdW5kZXIgdGhlDQo+PiBgYHhlbixzY2lgYCBj b21hcHRpYmxlIG5vZGUsIHdoaWNoIGlzIHVzZWQgYnkgWGVuIHRvIGNvbnRyb2wgb3RoZXINCj4+ IFNDTUkgQWdlbnRzIGluIHRoZSBzeXN0ZW0uDQo+Pg0KPj4gQWxsIHNlY29uZGFyeSBhZ2VudHMn IGNvbmZpZ3VyYXRpb25zIGFyZSBwcm92aWRlZCBpbiB0aGUNCj4+IGBgc2NtaS1zZWNvbmRhcnkt YWdlbnRzYGAgcHJvcGVydHkgd2l0aCBhbiBvcHRpb25hbCBgYGFnZW50X2lkYGAgZmllbGQuDQo+ Pg0KPj4gVGhlIGBgYWdlbnRfaWRgYCBmcm9tIHRoZSBgYHNjbWktc2Vjb25kYXJ5LWFnZW50c2Bg IHByb3BlcnR5IGlzIHVzZWQNCj4+IHRvIGlkZW50aWZ5IHRoZSBhZ2VudCBpbiB0aGUgc3lzdGVt IGFuZCBjYW4gYmUgb21pdHRlZCBieSBzZXR0aW5nDQo+PiBgYCNzY21pLXNlY29uZGFyeS1hZ2Vu dHMtY2VsbHMgPSA8Mj5gYCwgc28gdGhlIFNlY29uZGFyeSBBZ2VudHMNCj4+IGNvbmZpZ3VyYXRp b24gd2lsbCBsb29rIGxpa2UgdGhpczoNCj4+DQo+PiAvIHsNCj4+ICAgIGNob3NlbiB7DQo+PiAg ICAgIHhlbiB7DQo+PiAgICAgICAgeGVuX3NjbWlfY29uZmlnIHsNCj4+ICAgICAgICAgIGNvbXBh dGlibGUgPSAieGVuLHNjaSI7DQo+PiAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9IDwyPjsNCj4+ ICAgICAgICAgICNzaXplLWNlbGxzID0gPDI+Ow0KPj4gICAgICAgICAgcmFuZ2VzOw0KPj4NCj4+ ICAgICAgICAgIC8qIFNoYXJlZCBtZW1vcnkgbm9kZXMgYXMgZGVmaW5lZCBlYXJsaWVyICovDQo+ Pg0KPj4gICAgICAgICAgc2NtaS1zZWNvbmRhcnktYWdlbnRzID0gPA0KPj4gICAgICAgICAgICAw eDgyMDAwMDAzICZzY21pX3NobV8wDQo+PiAgICAgICAgICAgIDB4ODIwMDAwMDQgJnNjbWlfc2ht XzINCj4+ICAgICAgICAgICAgMHg4MjAwMDAwNSAmc2NtaV9zaG1fMw0KPj4gICAgICAgICAgICAw eDgyMDAwMDA2ICZzY21pX3NobV80PjsNCj4+ICAgICAgICAgICNzY21pLXNlY29uZGFyeS1hZ2Vu dHMtY2VsbHMgPSA8Mj47DQo+PiAgICAgICAgfTsNCj4+ICAgICAgfTsNCj4+ICAgIH07DQo+PiB9 DQo+Pg0KPj4gSW4gdGhpcyBjYXNlLCBYZW4gd2lsbCB1c2UgdGhlIGBgU0NNSV9CQVNFX0RJU0NP VkVSX0FHRU5UYGAgY2FsbCB0bw0KPj4gZGlzY292ZXIgdGhlIGBgYWdlbnRfaWRgYCBmb3IgZWFj aCBzZWNvbmRhcnkgYWdlbnQuIFByb3ZpZGluZyB0aGUNCj4+IGBgYWdlbnRfaWRgYCBpbiB0aGUg YGBzY21pLXNlY29uZGFyeS1hZ2VudHNgYCBwcm9wZXJ0eSBhbGxvd3Mgc2tpcHBpbmcNCj4+IHRo ZSBkaXNjb3ZlcnkgY2FsbCwgd2hpY2ggaXMgdXNlZnVsIHdoZW4gdGhlIHNlY29uZGFyeSBhZ2Vu dCdzIHNoYXJlZA0KPj4gbWVtb3J5IGlzIG5vdCBhY2Nlc3NpYmxlIGJ5IFhlbiBvciB3aGVuIGJv b3QgdGltZSBpcyBpbXBvcnRhbnQgYmVjYXVzZQ0KPj4gaXQgYWxsb3dzIHNraXBwaW5nIHRoZSBh Z2VudCBkaXNjb3ZlcnkgcHJvY2VkdXJlLg0KPj4NCj4+ICAgIE5vdGUgdGhhdCBYZW4gaXMgdGhl IG9ubHkgb25lIGVudHJ5IGluIHRoZSBzeXN0ZW0gd2hpY2ggbmVlZCB0byBrbm93DQo+PiAgICBh Ym91dCBTQ01JIG11bHRpLWFnZW50IHN1cHBvcnQuDQo+Pg0KPj4gLSBJdCBpbXBsZW1lbnRzIHRo ZSBTQ0kgc3Vic3lzdGVtIGludGVyZmFjZSByZXF1aXJlZCBmb3IgY29uZmlndXJpbmcgYW5kDQo+ PiBlbmFibGluZyBTQ01JIGZ1bmN0aW9uYWxpdHkgZm9yIERvbTAvaHdkb20gYW5kIEd1ZXN0IGRv bWFpbnMuIFRvIGVuYWJsZQ0KPj4gU0NNSSBmdW5jdGlvbmFsaXR5IGZvciBkb21haW4gaXQgaGFz IHRvIGJlIGNvbmZpZ3VyZWQgd2l0aCB1bmlxdWUgc3VwcG9ydGVkDQo+PiBTQ01JIEFnZW50X2lk IGFuZCB1c2UgY29ycmVzcG9uZGluZyBTQ01JIFNNQyBzaGFyZWQgbWVtb3J5IHRyYW5zcG9ydA0K Pj4gW3NtYy1pZCwgc2htZW1dIGRlZmluZWQgZm9yIHRoaXMgU0NNSSBBZ2VudF9pZC4NCj4+IC0g T25jZSBYZW4gZG9tYWluIGlzIGNvbmZpZ3VyZWQgaXQgY2FuIGNvbW11bmljYXRlIHdpdGggRUwz IFNDTUkgRlc6DQo+PiAgICAtLSB6ZXJvLWNvcHksIHRoZSBndWVzdCBkb21haW4gcHV0cyBTQ01J IG1lc3NhZ2UgaW4gc2htZW07DQo+PiAgICAtLSB0aGUgZ3Vlc3QgdHJpZ2dlcnMgU01DIGV4Y2Vw dGlvbiB3aXRoIHNtYy1pZCAoZG9vcmJlbGwpOw0KPj4gICAgLS0gdGhlIFhlbiBkcml2ZXIgY2F0 Y2hlcyBleGNlcHRpb24sIGRvIGNoZWNrcyBhbmQgc3luY2hyb25vdXNseSBmb3J3YXJkcw0KPj4g ICAgaXQgdG8gRUwzIEZXLg0KPj4gLSB0aGUgWGVuIGRyaXZlciBzZW5kcyBCQVNFX1JFU0VUX0FH RU5UX0NPTkZJR1VSQVRJT04gbWVzc2FnZSB0byBYZW4NCj4+ICAgIG1hbmFnZW1lbnQgYWdlbnQg Y2hhbm5lbCBvbiBkb21haW4gZGVzdHJveSBldmVudC4gVGhpcyBhbGxvd3MgdG8gcmVzZXQNCj4+ ICAgIHJlc291cmNlcyB1c2VkIGJ5IGRvbWFpbiBhbmQgc28gaW1wbGVtZW50IHVzZS1jYXNlIGxp a2UgZG9tYWluIHJlYm9vdC4NCj4+DQo+PiBEb20wIEVuYWJsZSBTQ01JIFNNQzoNCj4+ICAgLSBw YXNzIGRvbTBfc2NtaV9hZ2VudF9pZD08YWdlbnRfaWQ+IGluIFhlbiBjb21tYW5kIGxpbmUuIGlm IG5vdCBwcm92aWRlZA0KPj4gICAgIFNDTUkgd2lsbCBiZSBkaXNhYmxlZCBmb3IgRG9tMCBhbmQg YWxsIFNDTUkgbm9kZXMgcmVtb3ZlZCBmcm9tIERvbTAgRFQuDQo+PiAgICAgVGhlIGRyaXZlciB1 cGRhdGVzIERvbTAgRFQgU0NNSSBub2RlICJhcm0sc21jLWlkIiB2YWx1ZSBhbmQgZml4IHVwIHNo bWVtDQo+PiAgICAgbm9kZSBhY2NvcmRpbmcgdG8gYXNzaWduZWQgYWdlbnRfaWQuDQo+IEdpdmVu IHRoYXQgZXZlcnl0aGluZyBlbHNlLCB0aGUgZW50aXJlIGNvbmZpZ3VyYXRpb24sIGlzIGJhc2Vk IG9uIGRldmljZQ0KPiB0cmVlLCBJIHRoaW5rIGl0IG1ha2VzIHNlbnNlIHRvIGFsc28gY29uZmln dXJlIHRoaXMgdmlhIGRldmljZSB0cmVlDQo+IGluc3RlYWQgb2YgYSBjb21tYW5kIGxpbmUuDQo+ DQo+IFRoaXMgY291bGQgYmUgYW5vdGhlciBwYXJhbWV0ZXIgdW5kZXIgeGVuX3NjbWlfY29uZmln LiBXaGF0IGRvIHlvdQ0KPiB0aGluaz8NCj4NCg0KVGhlIGBgZG9tMF9zY21pX2FnZW50X2lkYGAg cGFyYW1ldGVyIHdhcyBpbnRyb2R1Y2VkIHRvIGtlZXAgdGhlIERvbTANCmNvbmZpZ3VyYXRpb24g c2VwYXJhdGUgZnJvbSB0aGUgeGVuX3NjbWlfY29uZmlnIG5vZGUsIHdoaWNoIGlzIGludGVuZGVk DQpzcGVjaWZpY2FsbHkgZm9yIFhlbiBTQ01JIGNvbmZpZ3VyYXRpb24uIEluIG15IG9waW5pb24s IGFkZGluZyBEb20wLXNwZWNpZmljDQpjb25maWd1cmF0aW9uIHRvIHhlbl9zY21pX2NvbmZpZyB3 b3VsZCBtaXggdGhlIHB1cnBvc2VzIG9mIHRoZSBub2RlIGFuZA0KcmVkdWNlIGNsYXJpdHkuDQoN CkFkZGl0aW9uYWxseSwgdGhlIGBgZG9tMF9zY21pX2FnZW50X2lkYGAgcGFyYW1ldGVyIGlzIHNp bWlsYXIgdG8gdGhlDQpgYGFnZW50X2lkYGAgcGFyYW1ldGVyIHVzZWQgZm9yIGFybV9zY2kgaW4g eGwuY2ZnLiBUaGlzIGFwcHJvYWNoIGVuc3VyZXMNCnRoYXQNCnRoZSBEb20wIGNvbmZpZ3VyYXRp b24gaXMgYXMgY29uc2lzdGVudCBhcyBwb3NzaWJsZSB3aXRoIHRoZQ0KY29uZmlndXJhdGlvbiBm b3INCm90aGVyIGRvbWFpbnMuDQoNCk92ZXJhbGwsIEkgYmVsaWV2ZSB0aGlzIG1ha2VzIHRoZSBj b25maWd1cmF0aW9uIGxlc3MgY29uZnVzaW5nLCBhcyBpdCBhbGxvd3MNCnVzIHRvIHNldCBzaW1p bGFyIHBhcmFtZXRlcnMgZm9yIGJvdGggRG9tMCBhbmQgb3RoZXIgZG9tYWlucyBpbiBhIGNsZWFy DQphbmQgb3JnYW5pemVkIG1hbm5lci4NCg0KPj4gR3Vlc3QgZG9tYWlucyBlbmFibGUgU0NNSSBT TUM6DQo+PiAgIC0geGwuY2ZnOiBhZGQgY29uZmlndXJhdGlvbiBvcHRpb24gYXMgYmVsb3cNCj4+ DQo+PiAgICAgYXJtX3NjaSA9ICJ0eXBlPXNjbWlfc21jX211bHRpYWdlbnQsPTIiDQo+Pg0KPj4g ICAtIHhsLmNmZzogZW5hYmxlIGFjY2VzcyB0byB0aGUgImFybSxzY21pLXNobWVtIiB3aGljaCBz aG91bGQNCj4+ICAgY29ycmVzcG9uZCBhc3NpZ25lZCBhZ2VudF9pZCBmb3IgdGhlIGRvbWFpbiwg Zm9yIGV4YW1wbGU6DQo+Pg0KPj4gaW9tZW0gPSBbDQo+PiAgICAgICI0N2ZmMiwxQDIyMDAxIiwN Cj4+IF0NCj4+DQo+PiAgIC0gRFQ6IGFkZCBTQ01JIG5vZGVzIHRvIHRoZSBEcml2ZXIgZG9tYWlu IHBhcnRpYWwgZGV2aWNlIHRyZWUgYXMgaW4gdGhlDQo+PiAgIGJlbG93IGV4YW1wbGUuIFRoZSAi YXJtLHNtYy1pZCIgc2hvdWxkIGNvcnJlc3BvbmQgYXNzaWduZWQgYWdlbnRfaWQNCj4+ICAgZm9y IHRoZSBkb21haW46DQo+Pg0KPj4gcGFzc3Rocm91Z2ggew0KPj4gICAgIHNjbWlfc2htXzA6IHNy YW1AMjIwMDEwMDAgew0KPj4gICAgICAgICBjb21wYXRpYmxlID0gImFybSxzY21pLXNobWVtIjsN Cj4+ICAgICAgICAgcmVnID0gPDB4MCAweDIyMDAxMDAwIDB4MCAweDEwMDA+Ow0KPj4gICAgIH07 DQo+Pg0KPj4gICAgIGZpcm13YXJlIHsNCj4+ICAgICAgICAgIGNvbXBhdGlibGUgPSAic2ltcGxl LWJ1cyI7DQo+PiAgICAgICAgICAgICAgc2NtaTogc2NtaSB7DQo+PiAgICAgICAgICAgICAgICAg IGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc21jIjsNCj4+ICAgICAgICAgICAgICAgICAgYXJtLHNt Yy1pZCA9IDwweDgyMDAwMDA0PjsNCj4+ICAgICAgICAgICAgICAgICAgc2htZW0gPSA8JnNjbWlf c2htXzA+Ow0KPj4gICAgICAgICAgICAgICAgICAuLi4NCj4+ICAgICAgICAgICAgICB9DQo+PiAg ICAgIH0NCj4+IH0NCj4+DQo+PiBTQ01JICI0LjIuMS4xIERldmljZSBzcGVjaWZpYyBhY2Nlc3Mg Y29udHJvbCINCj4+DQo+PiBUaGUgWEVOIFNDSSBTQ01JIFNNQyBtdWx0aS1hZ2VudCBkcml2ZXIg cGVyZm9ybXMgImFjY2Vzcy1jb250cm9sbGVyIg0KPj4gcHJvdmlkZXIgZnVuY3Rpb24gaW4gY2Fz ZSBFTDMgU0NNSSBGVyBpbXBsZW1lbnRzIFNDTUkgIjQuMi4xLjEgRGV2aWNlDQo+PiBzcGVjaWZp YyBhY2Nlc3MgY29udHJvbCIgYW5kIHByb3ZpZGVzIHRoZSBCQVNFX1NFVF9ERVZJQ0VfUEVSTUlT U0lPTlMNCj4+IGNvbW1hbmQgdG8gY29uZmlndXJlIHRoZSBkZXZpY2VzIHRoYXQgYW4gYWdlbnRz IGhhdmUgYWNjZXNzIHRvLg0KPj4gVGhlIERUIFNDTUkgbm9kZSBzaG91bGQgIiNhY2Nlc3MtY29u dHJvbGxlci1jZWxscz08MT4iIHByb3BlcnR5IGFuZCBEVA0KPj4gZGV2aWNlcyBzaG91bGQgYmUg Ym91bmQgdG8gdGhlIFhlbiBTQ01JLg0KPj4NCj4+ICZpMmMxIHsNCj4+ICAgICAgYWNjZXNzLWNv bnRyb2xsZXJzID0gPCZzY21pIDA+Ow0KPj4gfTsNCj4+DQo+PiBUaGUgRG9tMCBhbmQgZG9tMGxl c3MgZG9tYWlucyBEVCBkZXZpY2VzIHdpbGwgYmUgcHJvY2Vzc2VkDQo+PiBhdXRvbWF0aWNhbGx5 IHRocm91Z2ggc2NpX2Fzc2lnbl9kdF9kZXZpY2UoKSBjYWxsLCBidXQgdG8gYXNzaWduIFNDTUkN Cj4+IGRldmljZXMgZnJvbSB0b29sc3RhY2sgdGhlIHhsLmNmZzoiZHRkZXYiIHByb3BlcnR5DQo+ PiBzaGFsbCBiZSB1c2VkOg0KPj4NCj4+IGR0ZGV2ID0gWw0KPj4gICAgICAiL3NvYy9pMmNAZTY1 MDgwMDAiLA0KPj4gXQ0KPj4NCj4+IHhsLmNmZzpkdGRldiB3aWxsIGNvbnRhaW4gYWxsIG5vZGVz IHdoaWNoIGFyZSB1bmRlciBTQ01JDQo+PiBtYW5hZ2VtZW50IChub3Qgb25seSB0aG9zZSB3aGlj aCBhcmUgYmVoaW5kIElPTU1VKS4NCj4+DQo+PiBbMV1odHRwczovL3dlYi5naXQua2VybmVsLm9y Zy9wdWIvc2NtL2xpbnV4L2tlcm5lbC9naXQvdG9ydmFsZHMvbGludXguZ2l0L3RyZWUvRG9jdW1l bnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2Zpcm13YXJlL2FybSxzY21pLnlhbWwNCj4+IFsy XWh0dHBzOi8vd2ViLmdpdC5rZXJuZWwub3JnL3B1Yi9zY20vbGludXgva2VybmVsL2dpdC90b3J2 YWxkcy9saW51eC5naXQvdHJlZS9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvYWNj ZXNzLWNvbnRyb2xsZXJzL2FjY2Vzcy1jb250cm9sbGVycy55YW1sDQo+Pg0KPj4gU2lnbmVkLW9m Zi1ieTogR3J5Z29yaWkgU3RyYXNoa288Z3J5Z29yaWlfc3RyYXNoa29AZXBhbS5jb20+DQo+PiBT aWduZWQtb2ZmLWJ5OiBPbGVrc2lpIE1vaXNpZWlldjxvbGVrc2lpX21vaXNpZWlldkBlcGFtLmNv bT4NCj4+IC0tLQ0KPj4NCj4+IENoYW5nZXMgaW4gdjc6DQo+PiAtIHJld29yayBzY21pIG5vZGVz IGZvciB4ZW4gdG8gbWF0Y2ggb24gY29tcGF0aWJsZSBzdHJpbmcgaW5zdGVhZCBvZg0KPj4gdGhl IGRpcmVjdCBwYXRoDQo+Pg0KPj4gQ2hhbmdlcyBpbiB2NjoNCj4+IC0gdXBkYXRlZCBzY21pLXNo bWVtIHRvIHVzZSBpby5oIGZyb20gZ2VuZXJpYyBsb2NhdGlvbg0KPj4gLSB1cGRhdGUgc2NtaV9h Z2VudF9pZCBwYXJhbWV0ZXIgdG8gYmUgcHJvdmlkZWQgaW5zaWRlIGRvbTA9IHBhcmFtZXRlcg0K Pj4gbGlzdCBhbmQgaGF2ZSB0aGUgZm9sbG93aW5nIGZvcm1hdCAiZG9tMD1zY2ktYWdlbnQtaWQ9 MCINCj4+IFRoaXMgY2hhbmdlIHdhcyBkb25lIGFzIGEgcmVzcG9uc2UgZm9yIFN0ZWZhbm8gY29t bWVudCBhbmQNCj4+IHJlcXVpcmVzIGEgbG90IG9mIGNvZGUgY2hhbmdlcywgYnV0IHByb2R1Y2Vz IG11Y2ggY2xlYW5lciBzb2x1dGlvbg0KPj4gdGhhdCdzIHdoeSBJJ3ZlIGFkZGVkIGl0IHRvIHRo ZSBjb2RlLg0KPj4gLSBmaXggZmlsZSBjb21tZW50cyBhbmQgcmV0dXJuIGNvZGVzDQo+PiAtIGZp eCBsZW5naHQgY2hlY2tzIGluIHNobWVtX3tnZXQscHV0fV9tZXNzYWdlIHRvIHVzZSBvZmZzZXRv Zg0KPj4gLSByZW1vdmUgbGVuIG1lbWJlciBmcm9tIHNjbWlfY2hhbm5lbCBzdHJ1Y3R1cmUgYXMg aXQgaXMgbm90IHVzZWQNCj4+IC0gc2V0IHNjbWktc2Vjb25kYXJ5LWFnZW50cyBwcm9wZXJ0eSB0 byBiZSBtYW5kYXRvcnkgc2luY2UgaWYgbm8NCj4+IHNlY29uZGFyeSBhZ2VudHMgd2VyZSBwcm92 aWRlZCB0aGVuIHRoZXJlIGlzIG5vIHNlbmNlIHRvIGVuYWJsZSBzY21pDQo+PiB3aGVuIG5vIHNl Y29uZGFyeSBhZ2VudHMgYXJlIHBvcHVsYXRlZCB0byB0aGUgRG9tYWlucw0KPj4gLSB1cGRhdGUg ZG9jdW1lbnRhdGlvbiBpbiBib290aW5nLnR4dCwgYWRkZWQgeGVuX3NjbWkgbm9kZSB0byB0aGUN Cj4+IGV4YW1wbGUNCj4+IC0gYWRqdXN0IGQtPmFyY2guc2NpX2VuYWJsZWQgdmFsdWUgaW4gc2Nt aV9kb21haW5fZGVzdHJveQ0KPj4gLSBmaXggbG9jayBtYW5hZ2VtZW50IGluIHNtY19jcmVhdGVf Y2hhbm5lbCBjYWxsDQo+PiAtIGF2b2lkIGV4dHJhIG1hcF9jaGFubmVsX21lbW9yeSBjb21tYW5k IGZvciBYZW4gbWFuYWdlbWVudCBjaGFubmVsDQo+PiBiZWNhdXNlIGNvbGxlY3RfYWdlbnRfaWQg Y2FsbCB1bm1hcHMgbWVtb3J5IGlmIERPTUlEX1hFTiBpcyBub3QNCj4+IHNldC4gU28gZm9yIFhl biBtYW5hZ2VtZW50IGNoYW5uZWwgd2UgY2FuIGluaXQgZG9tYWluX2lkIGFkIERPTUlEX1hFTg0K Pj4gYmVmb3JlIGNhbGxpbmcgY29sbGVjdF9hZ2VudF9pZCBzbyBtZW1vcnkgc2hvdWxkbid0IGJl IHVubWFwcGVkLg0KPj4NCj4+IENoYW5nZXMgaW4gdjU6DQo+PiAtIGZpeCBkZXZpY2UtdHJlZSBl eGFtcGxlIGZvcm1hdCBpbiBib290aW5nLnR4dCwgYWRkZWQgIjsiIGFmdGVyICJ9Ii4NCj4+IC0g dXBkYXRlIGRlZmluZSBpbiBzY21pLXByb3RvLmgNCj4+IC0gdXBkYXRlIGRlZmluZSBpbiBzY21p LXNobWVtLmggZmlsZQ0KPj4gLSBzY21pX2Fzc2lnbl9kZXZpY2UgLSBkbyBub3QgaWdub3JlIC1F T1BOT1RTVVBQIHJldHVybg0KPj4gY29kZSBvZiB0aGUgZG9fc21jX3hmZXINCj4+IC0gcmVtb3Zl IG92ZXJ3cml0aW5nIGFnZW50X2NoYW5uZWwtPmFnZW50X2lkIGFmdGVyDQo+PiBTQ01JX0JBU0Vf RElTQ09WRVJfQUdFTlQgY2FsbA0KPj4gLSBhZGQgbXVsdGktYWdlbnQgZmlsZXMgdG8gdGhlIE1B SU5UQUlORVJTDQo+PiAtIGFkZCBTQ01JIG11bHRpLWFnZW50IGRlc2NyaXB0aW9uIHRvIHRoZSBT VVBQT1JULm1kDQo+PiAtIGhhbmRsZSBBUk1fU01DQ0NfSU5WQUxJRF9QQVJBTUVURVIgcmV0dXJu IGNvZGUgYW5kIHJldHVybiAtRUlOVkFMDQo+PiBmb3Igc21jIGNhbGwNCj4+IC0gdXBkYXRlZCBj b2xsZWN0X2FnZW50cyBmdW5jdGlvbi4gU2V0IGFnZW50X2lkIHBhcmFtZXRlciBhcyBvcHRpb25h bA0KPj4gaW4gc2NtaS1zZWNvbmRhcnktYWdlbnRzIGRldmljZS10cmVlIHByb3BlcnR5DQo+PiAt IGludHJvZHVjZSAiI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxscyIgcGFyYW1ldGVyIHRvIHNl dCBpZg0KPj4gYWdlbnRfaWQgd2FzIHByb3ZpZGVkDQo+PiAtIHJlYW5tZSB4ZW4sc2NtaS1zZWNv bmRhcnktYWdlbnRzIHByb3BlcnR5IHRvIHNjbWktc2Vjb25kYXJ5LWFnZW50cw0KPj4gLSBtb3Zl IG1lbWNwdV90b2lvL2Zyb21pbyBmb3IgdGhlIGdlbmVyaWMgcGxhY2UNCj4+IC0gdXBkYXRlIFhl biB0byBnZXQgbWFuYWdlbWVudCBjaGFubmVsIGZyb20gL2Nob3Nlbi94ZW4sY29uZmlnIG5vZGUN Cj4+IC0gZ2V0IGh5cGVydmlzb3IgY2hhbm5uZWwgZnJvbSBub2RlIGluc3RlYWQgb2YgdXNpbmcg aGFyZGNvZGVkDQo+PiAtIHVwZGF0ZSBoYW5kbGluZyBzY21pIGFuZCBzaG1lbSBub2RlcyBmb3Ig dGhlIGRvbWFpbg0KPj4gLSBTZXQgbXVsdGktYWdlbnQgZHJpdmVyIHRvIHN1cHBvcnQgb25seSBB cm02NA0KPj4NCj4+IENoYW5nZXMgaW4gdjQ6DQo+PiAtIHRvb2xzdGFjayBjb21tZW50cyBmcm9t IEFudGhvbnkgUEVSQVJEDQo+PiAtIGFkZGVkIGRvbTBsZXNzIHN1cHBvcnQNCj4+IC0gYWRkZWQg ZG9jIGZvciAieGVuLHNjbWktc2Vjb25kYXJ5LWFnZW50cyINCj4+DQo+PiAgIE1BSU5UQUlORVJT ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDQgKw0KPj4gICBTVVBQT1JULm1k ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDExICsNCj4+ICAgZG9jcy9tYW4v eGwuY2ZnLjUucG9kLmluICAgICAgICAgICAgICAgICAgICB8ICAxMyArDQo+PiAgIGRvY3MvbWlz Yy9hcm0vZGV2aWNlLXRyZWUvYm9vdGluZy50eHQgICAgICAgfCAxMDMgKysrDQo+PiAgIGRvY3Mv bWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYyAgICAgICAgICAgfCAgMTkgKy0NCj4+ICAgdG9v bHMvbGlicy9saWdodC9saWJ4bF9hcm0uYyAgICAgICAgICAgICAgICB8ICAgNCArDQo+PiAgIHRv b2xzL2xpYnMvbGlnaHQvbGlieGxfdHlwZXMuaWRsICAgICAgICAgICAgfCAgIDQgKy0NCj4+ICAg dG9vbHMveGwveGxfcGFyc2UuYyAgICAgICAgICAgICAgICAgICAgICAgICB8ICAxMiArDQo+PiAg IHhlbi9hcmNoL2FybS9kb20wbGVzcy1idWlsZC5jICAgICAgICAgICAgICAgfCAgMTEgKw0KPj4g ICB4ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMgICAgICAgICAgICAgICAgIHwgIDI2ICstDQo+ PiAgIHhlbi9hcmNoL2FybS9maXJtd2FyZS9LY29uZmlnICAgICAgICAgICAgICAgfCAgMTIgKw0K Pj4gICB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvTWFrZWZpbGUgICAgICAgICAgICAgIHwgICAxICsN Cj4+ICAgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktcHJvdG8uaCAgICAgICAgICB8IDE2NCAr KysrDQo+PiAgIHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmMgICAgICAgICAgfCAx MTUgKysrDQo+PiAgIHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmggICAgICAgICAg fCAgNDUgKysNCj4+ICAgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc21jLW11bHRpYWdlbnQu YyB8IDgxNSArKysrKysrKysrKysrKysrKysrKw0KPj4gICB4ZW4vaW5jbHVkZS9wdWJsaWMvYXJj aC1hcm0uaCAgICAgICAgICAgICAgIHwgICAzICsNCj4+ICAgMTcgZmlsZXMgY2hhbmdlZCwgMTM1 OSBpbnNlcnRpb25zKCspLCAzIGRlbGV0aW9ucygtKQ0KPj4gICBjcmVhdGUgbW9kZSAxMDA2NDQg eGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktcHJvdG8uaA0KPj4gICBjcmVhdGUgbW9kZSAxMDA2 NDQgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uYw0KPj4gICBjcmVhdGUgbW9kZSAx MDA2NDQgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uaA0KPj4gICBjcmVhdGUgbW9k ZSAxMDA2NDQgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc21jLW11bHRpYWdlbnQuYw0KPj4N Cj4+IGRpZmYgLS1naXQgYS9NQUlOVEFJTkVSUyBiL01BSU5UQUlORVJTDQo+PiBpbmRleCBlY2Qz ZjQwZGY4Li40YWQxZDgxOGE2IDEwMDY0NA0KPj4gLS0tIGEvTUFJTlRBSU5FUlMNCj4+ICsrKyBi L01BSU5UQUlORVJTDQo+PiBAQCAtNTMyLDYgKzUzMiwxMCBAQCBSOiAgICAgIE9sZWtzaWkgTW9p c2llaWV2PG9sZWtzaWlfbW9pc2llaWV2QGVwYW0uY29tPg0KPj4gICBTOiBTdXBwb3J0ZWQNCj4+ ICAgRjogeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjaS5jDQo+PiAgIEY6IHhlbi9hcmNoL2FybS9p bmNsdWRlL2FzbS9maXJtd2FyZS9zY2kuaA0KPj4gK0Y6ICB4ZW4vYXJjaC9hcm0vZmlybXdhcmUv c2NtaS1zbWMtbXVsdGlhZ2VudC5jDQo+PiArRjogIHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21p LXNobWVtLmMNCj4+ICtGOiAgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uaA0KPj4g K0Y6ICB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1wcm90by5oDQo+Pg0KPj4gICBTRUFCSU9T IFVQU1RSRUFNDQo+PiAgIE06IFdlaSBMaXU8d2xAeGVuLm9yZz4NCj4+IGRpZmYgLS1naXQgYS9T VVBQT1JULm1kIGIvU1VQUE9SVC5tZA0KPj4gaW5kZXggNDkxZjllY2QxYi4uN2M4OTUxZDY3YiAx MDA2NDQNCj4+IC0tLSBhL1NVUFBPUlQubWQNCj4+ICsrKyBiL1NVUFBPUlQubWQNCj4+IEBAIC05 NTYsNiArOTU2LDE3IEBAIGJ5IGh3ZG9tLiBTb21lIHBsYXRmb3JtcyB1c2UgU0NNSSBmb3IgYWNj ZXNzIHRvIHN5c3RlbS1sZXZlbCByZXNvdXJjZXMuDQo+Pg0KPj4gICAgICAgU3RhdHVzOiBTdXBw b3J0ZWQNCj4+DQo+PiArIyMjIEFybTogU0NNSSBTTUMgbXVsdGktYWdlbnQgc3VwcG9ydA0KPj4g Kw0KPj4gK0VuYWJsZSBzdXBwb3J0IGZvciB0aGUgbXVsdGktYWdlbnQgY29uZmlndXJhdGlvbiBv ZiB0aGUgRUwzIEZpcm13YXJlLCB3aGljaA0KPj4gK2FsbG93cyBYZW4gdG8gcHJvdmlkZSBhbiBT Q01JIGludGVyZmFjZSB0byB0aGUgRG9tYWlucy4NCj4+ICtYZW4gbWFuYWdlcyBhY2Nlc3MgcGVy bWlzc2lvbnMgdG8gdGhlIEhXIHJlc291cmNlcyBhbmQgcHJvdmlkZXMgYW4gU0NNSSBpbnRlcmZh Y2UNCj4+ICt0byB0aGUgRG9tYWlucy4gRWFjaCBEb21haW4gaXMgcmVwcmVzZW50ZWQgYXMgYSBz ZXBhcmF0ZSBBZ2VudCwgd2hpY2ggY2FuDQo+PiArY29tbXVuaWNhdGUgd2l0aCBFTDMgRmlybXdh cmUgdXNpbmcgYSBkZWRpY2F0ZWQgc2hhcmVkIG1lbW9yeSByZWdpb24sIGFuZA0KPj4gK25vdGlm aWNhdGlvbnMgYXJlIHBhc3NlZCB0aHJvdWdoIGJ5IFhlbi4NCj4+ICsNCj4+ICsgICAgU3RhdHVz LCBBUk02NDogVGVjaCBQcmV2aWV3DQo+PiArDQo+PiAgICMjIyBBUk06IEd1ZXN0IFBTQ0kgc3Vw cG9ydA0KPj4NCj4+ICAgRW11bGF0ZWQgUFNDSSBpbnRlcmZhY2UgZXhwb3NlZCB0byBndWVzdHMu IFdlIHN1cHBvcnQgYWxsIG1hbmRhdG9yeQ0KPj4gZGlmZiAtLWdpdCBhL2RvY3MvbWFuL3hsLmNm Zy41LnBvZC5pbiBiL2RvY3MvbWFuL3hsLmNmZy41LnBvZC5pbg0KPj4gaW5kZXggYWQxNTUzYzVl OS4uNGZjM2UxMjkzOSAxMDA2NDQNCj4+IC0tLSBhL2RvY3MvbWFuL3hsLmNmZy41LnBvZC5pbg0K Pj4gKysrIGIvZG9jcy9tYW4veGwuY2ZnLjUucG9kLmluDQo+PiBAQCAtMzE1Niw4ICszMTU2LDIx IEBAIHNpbmdsZSBTQ01JIE9TUE0gYWdlbnQgc3VwcG9ydC4NCj4+ICAgU2hvdWxkIGJlIHVzZWQg dG9nZXRoZXIgd2l0aCBCPHNjbWktc21jLXBhc3N0aHJvdWdoPiBYZW4gY29tbWFuZCBsaW5lDQo+ PiAgIG9wdGlvbi4NCj4+DQo+PiArPWl0ZW0gQjxzY21pX3NtY19tdWx0aWFnZW50Pg0KPj4gKw0K Pj4gK0VuYWJsZXMgQVJNIFNDTUkgU01DIG11bHRpLWFnZW50IHN1cHBvcnQgZm9yIHRoZSBndWVz dCBieSBlbmFibGluZyBTQ01JIG92ZXINCj4+ICtTTUMgY2FsbHMgZm9yd2FyZGluZyBmcm9tIGRv bWFpbiB0byB0aGUgRUwzIGZpcm13YXJlIChsaWtlIFRydXN0ZWQgRmlybXdhcmUtQSkNCj4+ICt3 aXRoIGEgbXVsdGkgU0NNSSBPU1BNIGFnZW50IHN1cHBvcnQuIFRoZSBTQ01JIEI8YWdlbnRfaWQ+ IHNob3VsZCBiZQ0KPj4gK3NwZWNpZmllZCBmb3IgdGhlIGd1ZXN0Lg0KPj4gKw0KPj4gICA9YmFj aw0KPj4NCj4+ICs9aXRlbSBCPGFnZW50X2lkPU5VTUJFUj4NCj4+ICsNCj4+ICtTcGVjaWZpZXMg YSBub24temVybyBBUk0gU0NJIGFnZW50IGlkIGZvciB0aGUgZ3Vlc3QuIFRoaXMgb3B0aW9uIGlz IG1hbmRhdG9yeQ0KPj4gK2lmIHRoZSBTQ01JIFNNQyBzdXBwb3J0IGlzIGVuYWJsZWQgZm9yIHRo ZSBndWVzdC4gVGhlIGFnZW50IGlkcyBvZiBkb21haW5zDQo+PiArZXhpc3Rpbmcgb24gYSBzaW5n bGUgaG9zdCBtdXN0IGJlIHVuaXF1ZSBhbmQgaW4gdGhlIHJhbmdlIFsxLi4yNTVdLg0KPj4gKw0K Pj4gICA9YmFjaw0KPj4NCj4+ICAgPWJhY2sNCj4+IGRpZmYgLS1naXQgYS9kb2NzL21pc2MvYXJt L2RldmljZS10cmVlL2Jvb3RpbmcudHh0IGIvZG9jcy9taXNjL2FybS9kZXZpY2UtdHJlZS9ib290 aW5nLnR4dA0KPj4gaW5kZXggOTc3YjQyODYwOC4uNmZkN2U0YTE2YiAxMDA2NDQNCj4+IC0tLSBh L2RvY3MvbWlzYy9hcm0vZGV2aWNlLXRyZWUvYm9vdGluZy50eHQNCj4+ICsrKyBiL2RvY3MvbWlz Yy9hcm0vZGV2aWNlLXRyZWUvYm9vdGluZy50eHQNCj4+IEBAIC0zMjIsNiArMzIyLDIwIEBAIHdp dGggdGhlIGZvbGxvd2luZyBwcm9wZXJ0aWVzOg0KPj4gICAgICAgU2hvdWxkIGJlIHVzZWQgdG9n ZXRoZXIgd2l0aCBzY21pLXNtYy1wYXNzdGhyb3VnaCBYZW4gY29tbWFuZCBsaW5lDQo+PiAgICAg ICBvcHRpb24uDQo+Pg0KPj4gKyAgICAtICJzY21pX3NtY19tdWx0aWFnZW50Ig0KPj4gKw0KPj4g KyAgICBFbmFibGVzIEFSTSBTQ01JIFNNQyBtdWx0aS1hZ2VudCBzdXBwb3J0IGZvciB0aGUgZ3Vl c3QgYnkgZW5hYmxpbmcgU0NNSSBvdmVyDQo+PiArICAgIFNNQyBjYWxscyBmb3J3YXJkaW5nIGZy b20gZG9tYWluIHRvIHRoZSBFTDMgZmlybXdhcmUgKGxpa2UgQVJNDQo+PiArICAgIFRydXN0ZWQg RmlybXdhcmUtQSkgd2l0aCBhIG11bHRpIFNDTUkgT1NQTSBhZ2VudCBzdXBwb3J0Lg0KPj4gKyAg ICBUaGUgU0NNSSBhZ2VudF9pZCBzaG91bGQgYmUgc3BlY2lmaWVkIGZvciB0aGUgZ3Vlc3Qgd2l0 aCAieGVuLHNjaS1hZ2VudC1pZCINCj4+ICsgICAgcHJvcGVydHkuDQo+PiArDQo+PiArLSAieGVu LHNjaS1hZ2VudC1pZCINCj4+ICsNCj4+ICsgICAgU3BlY2lmaWVzIEFSTSBTQ01JIGFnZW50IGlk IGZvciB0aGUgZ3Vlc3QuIFRoaXMgb3B0aW9uIGlzIG1hbmRhdG9yeSBpZiB0aGUNCj4+ICsgICAg U0NNSSBTTUMgInNjbWlfc21jX211bHRpYWdlbnQiIHN1cHBvcnQgaXMgZW5hYmxlZCBmb3IgdGhl IGd1ZXN0LiBUaGUgYWdlbnQgaWRzDQo+PiArICAgIG9mIGd1ZXN0IG11c3QgYmUgdW5pcXVlIGFu ZCBpbiB0aGUgcmFuZ2UgWzAuLjI1NV0uDQo+IHRoZXNlIHR3byBkb24ndCBzZWVtIHRvIGJlIGlu IHRoZSBjb21taXQgbWVzc2FnZSBleGFtcGxlcw0KPg0KPg0KYGBzY21pX3NtY19tdWx0aWFnZW50 YGAgbWVudGlvbmVkIGluIHRoZSBjb21taXQgbWVzc2FnZSBhdCB0aGUgZm9sbG93aW5nDQpwYXJ0 Og0KDQogPiAtIHhsLmNmZzogYWRkIGNvbmZpZ3VyYXRpb24gb3B0aW9uIGFzIGJlbG93DQogPiBh cm1fc2NpID0gInR5cGU9c2NtaV9zbWNfbXVsdGlhZ2VudCxhZ2VudF9pZD0yIg0KDQpgYHhlbixz Y2ktYWdlbnQtaWRgYCBpcyB1c2VkIGZvciBkb20wbGVzcy4gSXQgZGVzY3JpYmVkIGluIGFybS1z Y21pLnJzdA0KZmlsZSB3aGljaCB3YXMgcHJlc2VudGVkIGluIHRoZSBuZXh0IGNvbW1pdC4NCg0K Pj4gICBVbmRlciB0aGUgInhlbixkb21haW4iIGNvbXBhdGlibGUgbm9kZSwgb25lIG9yIG1vcmUg c3ViLW5vZGVzIGFyZSBwcmVzZW50DQo+PiAgIGZvciB0aGUgRG9tVSBrZXJuZWwgYW5kIHJhbWRp c2suDQo+Pg0KPj4gQEAgLTgyNCwzICs4MzgsOTIgQEAgVGhlIGF1dG9tYXRpY2FsbHkgYWxsb2Nh dGVkIHN0YXRpYyBzaGFyZWQgbWVtb3J5IHdpbGwgZ2V0IG1hcHBlZCBhdA0KPj4gICAweDgwMDAw MDAwIGluIERvbVUxIGd1ZXN0IHBoeXNpY2FsIGFkZHJlc3Mgc3BhY2UsIGFuZCBhdCAweDkwMDAw MDAwIGluIERvbVUyDQo+PiAgIGd1ZXN0IHBoeXNpY2FsIGFkZHJlc3Mgc3BhY2UuIERvbVUxIGlz IGV4cGxpY2l0bHkgZGVmaW5lZCBhcyB0aGUgb3duZXIgZG9tYWluLA0KPj4gICBhbmQgRG9tVTIg aXMgdGhlIGJvcnJvd2VyIGRvbWFpbi4NCj4+ICsNCj4+ICtTQ01JIFNNQyBtdWx0aS1hZ2VudCBz dXBwb3J0DQo+PiArPT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPj4gKw0KPj4gK0ZvciBl bmFibGluZyB0aGUgQVJNIFNDTUkgU01DIG11bHRpLWFnZW50IHN1cHBvcnQgKGVuYWJsZWQgYnkg Q09ORklHX1NDTUlfU01DX01BKQ0KPj4gK3RoZSBYZW4gc3BlY2lmaWMgU0NNSSBBZ2VudCdzIGNv bmZpZ3VyYXRpb24gc2hhbGwgYmUgcHJvdmlkZWQgaW4gdGhlIEhvc3QgRFQNCj4+ICthY2NvcmRp bmcgdG8gdGhlIFNDTUkgY29tcGxpYW50IEVMMyBGaXJtd2FyZSBzcGVjaWZpY2F0aW9uIHdpdGgN Cj4+ICtBUk0gU01DL0hWQyB0cmFuc3BvcnQgdXNpbmcgcHJvcGVydHkgInNjbWktc2Vjb25kYXJ5 LWFnZW50cyIgcGxhY2VkIGluICJ4ZW4sY29uZmlnIg0KPj4gK25vZGUgdW5kZXIgImNob3NlbiIg bm9kZToNCj4+ICsNCj4+ICstIHNjbWktc2Vjb25kYXJ5LWFnZW50cw0KPj4gKw0KPj4gKyAgICBE ZWZpbmVzIGEgc2V0IG9mIFNDTUkgYWdlbnRzIGNvbmZpZ3VyYXRpb24gc3VwcG9ydGVkIGJ5IFND TUkgRUwzIEZXIGFuZA0KPj4gKyAgICBhdmFpbGFibGUgZm9yIFhlbi4gRWFjaCBBZ2VudCBkZWZp bmVkIGFzIHRyaXBsZSBjb25zaXN0aW5nIG9mOg0KPj4gKyAgICBTTUMvSFZDIGZ1bmN0aW9uX2lk IGFzc2lnbmVkIGZvciB0aGUgYWdlbnQgdHJhbnNwb3J0ICgiYXJtLHNtYy1pZCIpLA0KPj4gKyAg ICBwaGFuZGxlIHRvIFNDTUkgU0hNIGFzc2lnbmVkIGZvciB0aGUgYWdlbnQgdHJhbnNwb3J0ICgi YXJtLHNjbWktc2htZW0iKSwNCj4+ICsgICAgU0NNSSBhZ2VudF9pZCAob3B0aW9uYWwpIGlmIG5v dCBzZXQgLSBYZW4gd2lsbCBkZXRlcm1pbmUgQWdlbnQgSUQgZm9yDQo+PiArICAgIGVhY2ggcHJv dmlkZWQgY2hhbm5lbCB1c2luZyBCQVNFX0RJU0NPVkVSX0FHRU5UIG1lc3NhZ2UuDQo+PiArDQo+ PiArQXMgYW4gZXhhbXBsZToNCj4+ICsNCj4+ICsvew0KPj4gK2Nob3NlbiB7DQo+PiArICAgIHhl bixjb25maWcgew0KPiBzaG91bGQgYmUgdXBkYXRlZA0KQWdyZWUuLi4gYXJtLXNjbWkucnN0IGV4 YW1wbGVzIHNob3VsZCBiZSB1cGRhdGVkIGFzIHdlbGwuLi4gSSB0aGluayBJJ3ZlDQptZXNzZWQg dXAgdGhlIGRvY3VtZW50YXRpb24gY29tbWl0IG9uIHRoZSBsYXN0IHBhdGNoIHNlcmllcy4gV2ls bCBmaXguDQo+PiArICAgICAgICBzY21pX3NobV8wIDogc3JhbUA0N2ZmMDAwMCB7DQo+PiArICAg ICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+PiArICAgICAgICAgICAg cmVnID0gPDB4MCAweDQ3ZmYwMDAwIDB4MCAweDEwMDA+Ow0KPj4gKyAgICAgICAgfTsNCj4+ICsg ICAgICAgIC8vIFhlbiBTQ01JIG1hbmFnZW1lbnQgY2hhbm5lbA0KPj4gKyAgICAgICAgc2NtaV9z aG1fMTogc3JhbUA0N2ZmMTAwMCB7DQo+PiArICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAi YXJtLHNjbWktc2htZW0iOw0KPj4gKyAgICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjEw MDAgMHgwIDB4MTAwMD47DQo+PiArICAgICAgICB9Ow0KPj4gKyAgICAgICAgc2NtaV9zaG1fMjog c3JhbUA0N2ZmMjAwMCB7DQo+PiArICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNj bWktc2htZW0iOw0KPj4gKyAgICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjIwMDAgMHgw IDB4MTAwMD47DQo+PiArICAgICAgICB9Ow0KPj4gKyAgICAgICAgc2NtaV9zaG1fMzogc3JhbUA0 N2ZmMzAwMCB7DQo+PiArICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2ht ZW0iOw0KPj4gKyAgICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjMwMDAgMHgwIDB4MTAw MD47DQo+PiArICAgICAgICB9Ow0KPj4gKyAgICAgICAgc2NtaV9zaG1fMzogc3JhbUA0N2ZmNDAw MCB7DQo+PiArICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0K Pj4gKyAgICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjQwMDAgMHgwIDB4MTAwMD47DQo+ PiArICAgICAgICB9Ow0KPj4gKyAgICAgICAgc2NtaS1zZWNvbmRhcnktYWdlbnRzID0gPA0KPj4g KyAgICAgICAgICAgIDB4ODIwMDAwMDIgJnNjbWlfc2htXzAgMA0KPj4gKyAgICAgICAgICAgIDB4 ODIwMDAwMDQgJnNjbWlfc2htXzIgMg0KPj4gKyAgICAgICAgICAgIDB4ODIwMDAwMDUgJnNjbWlf c2htXzMgMw0KPj4gKyAgICAgICAgICAgIDB4ODIwMDAwMDYgJnNjbWlfc2htXzQgND47DQo+PiAr ICAgICAgICAgICAgI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxscyA9IDwzPjsNCj4+ICsgICAg ICAgIH07DQo+PiArDQo+PiArICAgICAgICBzY21pX3hlbjogc2NtaSB7DQo+PiArICAgICAgICAg ICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zbWMiOw0KPj4gKyAgICAgICAgICAgIGFybSxzbWMt aWQgPSA8MHg4MjAwMDAwMj47IDwtLS0gWGVuIG1hbmFnZW1lbnQgYWdlbnQgc21jLWlkDQo+IHNh bWUgcXVlc3Rpb24gYWJvdXQgMHg4MjAwMDAwMiBiZWluZyBhbHJlYWR5IGluIHVzZSBmb3IgJnNj bWlfc2htXzANCj4NCj4NCj4+ICsgICAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9IDwgMT47DQo+ PiArICAgICAgICAgICAgI3NpemUtY2VsbHMgPSA8IDA+Ow0KPj4gKyAgICAgICAgICAgICNhY2Nl c3MtY29udHJvbGxlci1jZWxscyA9IDwgMT47DQo+PiArICAgICAgICAgICAgc2htZW0gPSA8JnNj bWlfc2htXzE+OyA8LS0tIFhlbiBtYW5hZ2VtZW50IGFnZW50IHNobWVtDQo+PiArICAgICAgICB9 Ow0KPj4gKw0KPj4gKyAgICB9Ow0KPj4gK307DQo+PiArDQo+PiArLSAjc2NtaS1zZWNvbmRhcnkt YWdlbnRzLWNlbGxzDQo+PiArDQo+PiArICAgIERlZmluZXMgd2hldGhlciBBZ2VudF9pZCBpcyBz ZXQgaW4gdGhlICJzY21pLXNlY29uZGFyeS1hZ2VudHMiIHByb3BlcnR5Lg0KPj4gKyAgICBQb3Nz aWJsZSB2YWx1ZXMgYXJlOiAyLCAzLg0KPj4gKyAgICBXaGVuIHNldCB0byAzICh0aGUgZGVmYXVs dCksIGV4cGVjdCBhZ2VudF9pZCB0byBiZSBwcmVzZW50IGluIHRoZSBzZWNvbmRhcnkNCj4+ICsg ICAgYWdlbnRzIGxpc3QuDQo+PiArICAgIFdoZW4gc2V0IHRvIDIsIGFnZW50X2lkIHdpbGwgYmUg ZGlzY292ZXJlZCBmb3IgZWFjaCBjaGFubmVsIHVzaW5nDQo+PiArICAgIEJBU0VfRElTQ09WRVJf QUdFTlQgbWVzc2FnZS4NCj4+ICsNCj4+ICsNCj4+ICtFeGFtcGxlOg0KPj4gKw0KPj4gKy97DQo+ PiArY2hvc2VuIHsNCj4+ICsgICAgeGVuLGNvbmZpZyB7DQo+PiArICAgICAgICBzY21pLXNlY29u ZGFyeS1hZ2VudHMgPSA8DQo+PiArICAgICAgICAgICAgMHg4MjAwMDAwMyAmc2NtaV9zaG1fMQ0K Pj4gKyAgICAgICAgICAgIDB4ODIwMDAwMDQgJnNjbWlfc2htXzINCj4+ICsgICAgICAgICAgICAw eDgyMDAwMDA1ICZzY21pX3NobV8zDQo+PiArICAgICAgICAgICAgMHg4MjAwMDAwNiAmc2NtaV9z aG1fND47DQo+PiArICAgICAgICAgICAgI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxscyA9IDwy PjsNCj4+ICsgICAgICAgIH07DQo+PiArICAgIH07DQo+PiArfTsNCj4+IGRpZmYgLS1naXQgYS9k b2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MgYi9kb2NzL21pc2MveGVuLWNvbW1hbmQt bGluZS5wYW5kb2MNCj4+IGluZGV4IDM0MDA0Y2UyODIuLjU1NDFjNGE0ZWQgMTAwNjQ0DQo+PiAt LS0gYS9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MNCj4+ICsrKyBiL2RvY3MvbWlz Yy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYw0KPj4gQEAgLTgzNSw3ICs4MzUsNyBAQCBTcGVjaWZ5 IHRoZSBiaXQgd2lkdGggb2YgdGhlIERNQSBoZWFwLg0KPj4gICAgICAgICAgICAgICAgICAgY3B1 aWQtZmF1bHRpbmc9PGJvb2w+LCBtc3ItcmVsYXhlZD08Ym9vbD4sDQo+PiAgICAgICAgICAgICAg ICAgICBwZi1maXh1cD08Ym9vbD4gXSAoeDg2KQ0KPj4NCj4+IC0gICAgPSBMaXN0IG9mIFsgc3Zl PTxpbnRlZ2VyPiBdIChBcm02NCkNCj4+ICsgICAgPSBMaXN0IG9mIFsgc3ZlPTxpbnRlZ2VyPiwg c2NpLWFnZW50LWlkPTxpbnRlZ2VyPiBdIChBcm0pDQo+Pg0KPj4gICBDb250cm9scyBmb3IgaG93 IGRvbTAgaXMgY29uc3RydWN0ZWQgb24geDg2IHN5c3RlbXMuDQo+Pg0KPj4gQEAgLTkyMyw2ICs5 MjMsMTQgQEAgRW5hYmxlcyBmZWF0dXJlcyBvbiBkb20wIG9uIEFybSBzeXN0ZW1zLg0KPj4gICAg ICAgb3B0aW9uIGlzIHByb3ZpZGVkIHdpdGggYSBwb3NpdGl2ZSBub24gemVybyB2YWx1ZSwgYnV0 IHRoZSBwbGF0Zm9ybSBkb2Vzbid0DQo+PiAgICAgICBzdXBwb3J0IFNWRS4NCj4+DQo+PiArKiAg IFRoZSBgc2NpLWFnZW50LWlkYCBpbnRlZ2VyIHBhcmFtZXRlciBlbmFibGVzIEFSTSBTQ01JIChT eXN0ZW0gQ29udHJvbCBhbmQNCj4+ICsgICAgTWFuYWdlbWVudCBJbnRlcmZhY2UpIGZ1bmN0aW9u YWxpdHkgZm9yIERvbTAgd2hlbiBgQ09ORklHX1NDTUlfU01DX01BYCBpcw0KPj4gKyAgICBjb21w aWxlZCBpbi4gVGhpcyBwYXJhbWV0ZXIgc3BlY2lmaWVzIHRoZSBTQ01JIGFnZW50IElEIGZvciBE b20wLg0KPj4gKyAgICBBIHZhbHVlIGVxdWFsIHRvIDB4RkYgKG9yIG9taXR0ZWQpIGRpc2FibGVz IFNDTUkgZm9yIERvbTAsIHdoaWNoIGlzIHVzZWZ1bA0KPj4gKyAgICBmb3IgdGhpbiBEb20wIG9y IGRvbTBsZXNzIHVzZS1jYXNlcy4gVmFsdWVzIGZyb20gMCB0byAyNTQgc3BlY2lmeSB0aGUgU0NN SQ0KPj4gKyAgICBhZ2VudCBJRC4gVGhlIGFnZW50IElEcyBvZiBkb21haW5zIGV4aXN0aW5nIG9u IGEgc2luZ2xlIGhvc3QgbXVzdCBiZSB1bmlxdWUuDQo+PiArICAgIEV4YW1wbGU6IGBkb20wPXNj aS1hZ2VudC1pZD0wYCB0byBlbmFibGUgU0NNSSB3aXRoIGFnZW50IElEIDAgZm9yIERvbTAuDQo+ PiArDQo+PiAgICMjIyBkb20wLWNwdWlkDQo+PiAgICAgICA9IExpc3Qgb2YgY29tbWEgc2VwYXJh dGVkIGJvb2xlYW5zDQo+Pg0KPj4gQEAgLTExMDcsNiArMTExNSwxNSBAQCBhZmZpbml0aWVzIHRv IHByZWZlciBidXQgYmUgbm90IGxpbWl0ZWQgdG8gdGhlIHNwZWNpZmllZCBub2RlKHMpLg0KPj4N Cj4+ICAgUGluIGRvbTAgdmNwdXMgdG8gdGhlaXIgcmVzcGVjdGl2ZSBwY3B1cw0KPj4NCj4+ICsj IyMgc2NtaS1zbWMtcGFzc3Rocm91Z2ggKEFSTSkNCj4+ICs+IGA9IDxib29sZWFuPmANCj4+ICsN Cj4+ICtUaGUgb3B0aW9uIGlzIGF2YWlsYWJsZSB3aGVuIGBDT05GSUdfU0NNSV9TTUNgIGlzIGNv bXBpbGVkIGluLCBhbmQgYWxsb3dzIHRvDQo+PiArZW5hYmxlIFNDTUkgU01DIHNpbmdsZSBhZ2Vu dCBpbnRlcmZhY2UgZm9yIGFueSwgYnV0IG9ubHkgb25lIGd1ZXN0IGRvbWFpbiwNCj4+ICt3aGlj aCBzZXJ2ZXMgYXMgRHJpdmVyIGRvbWFpbi4gVGhlIFNDTUkgd2lsbCBiZSBkaXNhYmxlZCBmb3Ig RG9tMC9od2RvbSBhbmQNCj4+ICtTQ01JIG5vZGVzIHJlbW92ZWQgZnJvbSBEb20wL2h3ZG9tIGRl dmljZSB0cmVlLg0KPj4gKyhmb3IgZXhhbXBsZSwgdGhpbiBEb20wIHdpdGggRHJpdmVyIGRvbWFp biB1c2UtY2FzZSkuDQo+PiArDQo+PiAgICMjIyBkdHVhcnQgKEFSTSkNCj4+ICAgPiBgPSBwYXRo IFs6b3B0aW9uc11gDQo+Pg0KPj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxf YXJtLmMgYi90b29scy9saWJzL2xpZ2h0L2xpYnhsX2FybS5jDQo+PiBpbmRleCBlNDQwN2Q2ZTNm Li5iZTBlNjI2M2FlIDEwMDY0NA0KPj4gLS0tIGEvdG9vbHMvbGlicy9saWdodC9saWJ4bF9hcm0u Yw0KPj4gKysrIGIvdG9vbHMvbGlicy9saWdodC9saWJ4bF9hcm0uYw0KPj4gQEAgLTI0MCw2ICsy NDAsMTAgQEAgaW50IGxpYnhsX19hcmNoX2RvbWFpbl9wcmVwYXJlX2NvbmZpZyhsaWJ4bF9fZ2Mg KmdjLA0KPj4gICAgICAgY2FzZSBMSUJYTF9BUk1fU0NJX1RZUEVfU0NNSV9TTUM6DQo+PiAgICAg ICAgICAgY29uZmlnLT5hcmNoLmFybV9zY2lfdHlwZSA9IFhFTl9ET01DVExfQ09ORklHX0FSTV9T Q0lfU0NNSV9TTUM7DQo+PiAgICAgICAgICAgYnJlYWs7DQo+PiArICAgIGNhc2UgTElCWExfQVJN X1NDSV9UWVBFX1NDTUlfU01DX01VTFRJQUdFTlQ6DQo+PiArICAgICAgICBjb25maWctPmFyY2gu YXJtX3NjaV90eXBlID0gWEVOX0RPTUNUTF9DT05GSUdfQVJNX1NDSV9TQ01JX1NNQ19NQTsNCj4+ ICsgICAgICAgIGNvbmZpZy0+YXJjaC5hcm1fc2NpX2FnZW50X2lkID0gZF9jb25maWctPmJfaW5m by5hcmNoX2FybS5hcm1fc2NpLmFnZW50X2lkOw0KPj4gKyAgICAgICAgYnJlYWs7DQo+PiAgICAg ICBkZWZhdWx0Og0KPj4gICAgICAgICAgIExPRyhFUlJPUiwgIlVua25vd24gQVJNX1NDSSB0eXBl ICVkIiwNCj4+ICAgICAgICAgICAgICAgZF9jb25maWctPmJfaW5mby5hcmNoX2FybS5hcm1fc2Np LnR5cGUpOw0KPj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfdHlwZXMuaWRs IGIvdG9vbHMvbGlicy9saWdodC9saWJ4bF90eXBlcy5pZGwNCj4+IGluZGV4IDRhOTU4ZjY5ZjQu LjliZmJmMDkxNDUgMTAwNjQ0DQo+PiAtLS0gYS90b29scy9saWJzL2xpZ2h0L2xpYnhsX3R5cGVz LmlkbA0KPj4gKysrIGIvdG9vbHMvbGlicy9saWdodC9saWJ4bF90eXBlcy5pZGwNCj4+IEBAIC01 NTQsMTEgKzU1NCwxMyBAQCBsaWJ4bF9zdmVfdHlwZSA9IEVudW1lcmF0aW9uKCJzdmVfdHlwZSIs IFsNCj4+DQo+PiAgIGxpYnhsX2FybV9zY2lfdHlwZSA9IEVudW1lcmF0aW9uKCJhcm1fc2NpX3R5 cGUiLCBbDQo+PiAgICAgICAoMCwgIm5vbmUiKSwNCj4+IC0gICAgKDEsICJzY21pX3NtYyIpDQo+ PiArICAgICgxLCAic2NtaV9zbWMiKSwNCj4+ICsgICAgKDIsICJzY21pX3NtY19tdWx0aWFnZW50 IikNCj4+ICAgICAgIF0sIGluaXRfdmFsID0gIkxJQlhMX0FSTV9TQ0lfVFlQRV9OT05FIikNCj4+ DQo+PiAgIGxpYnhsX2FybV9zY2kgPSBTdHJ1Y3QoImFybV9zY2kiLCBbDQo+PiAgICAgICAoInR5 cGUiLCBsaWJ4bF9hcm1fc2NpX3R5cGUpLA0KPj4gKyAgICAoImFnZW50X2lkIiwgdWludDgpDQo+ PiAgICAgICBdKQ0KPj4NCj4+ICAgbGlieGxfcmRtX3Jlc2VydmUgPSBTdHJ1Y3QoInJkbV9yZXNl cnZlIiwgWw0KPj4gZGlmZiAtLWdpdCBhL3Rvb2xzL3hsL3hsX3BhcnNlLmMgYi90b29scy94bC94 bF9wYXJzZS5jDQo+PiBpbmRleCAxY2M0MWYxYmZmLi4wYzM4OWQyNWY5IDEwMDY0NA0KPj4gLS0t IGEvdG9vbHMveGwveGxfcGFyc2UuYw0KPj4gKysrIGIvdG9vbHMveGwveGxfcGFyc2UuYw0KPj4g QEAgLTEzMDYsNiArMTMwNiwxOCBAQCBzdGF0aWMgaW50IHBhcnNlX2FybV9zY2lfY29uZmlnKFhM VV9Db25maWcgKmNmZywgbGlieGxfYXJtX3NjaSAqYXJtX3NjaSwNCj4+ICAgICAgICAgICAgICAg fQ0KPj4gICAgICAgICAgIH0NCj4+DQo+PiArICAgICAgICBpZiAoTUFUQ0hfT1BUSU9OKCJhZ2Vu dF9pZCIsIHB0ciwgb3BhcmcpKSB7DQo+PiArICAgICAgICAgICAgdW5zaWduZWQgbG9uZyB2YWwg PSBwYXJzZV91bG9uZyhvcGFyZyk7DQo+PiArDQo+PiArICAgICAgICAgICAgaWYgKCF2YWwgfHwg dmFsID4gMjU1KSB7DQo+PiArICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiQW4gaW52 YWxpZCBBUk1fU0NJIGFnZW50X2lkIHNwZWNpZmllZCAoJWx1KS4gVmFsaWQgcmFuZ2UgWzEuLjI1 NV1cbiIsDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgdmFsKTsNCj4+ICsgICAgICAgICAg ICAgICAgcmV0ID0gRVJST1JfSU5WQUw7DQo+PiArICAgICAgICAgICAgICAgIGdvdG8gb3V0Ow0K Pj4gKyAgICAgICAgICAgIH0NCj4+ICsgICAgICAgICAgICBhcm1fc2NpLT5hZ2VudF9pZCA9IHZh bDsNCj4+ICsgICAgICAgIH0NCj4+ICsNCj4+ICAgICAgICAgICBwdHIgPSBzdHJ0b2soTlVMTCwg IiwiKTsNCj4+ICAgICAgIH0NCj4+DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL2RvbTBs ZXNzLWJ1aWxkLmMgYi94ZW4vYXJjaC9hcm0vZG9tMGxlc3MtYnVpbGQuYw0KPj4gaW5kZXggNDE4 MWMxMDUzOC4uZGRhZGM4OTE0OCAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS9kb20wbGVz cy1idWlsZC5jDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vZG9tMGxlc3MtYnVpbGQuYw0KPj4gQEAg LTI5OSw2ICsyOTksMTcgQEAgc3RhdGljIGludCBfX2luaXQgZG9tdV9kdF9zY2lfcGFyc2Uoc3Ry dWN0IGR0X2RldmljZV9ub2RlICpub2RlLA0KPj4gICAgICAgICAgIGRfY2ZnLT5hcmNoLmFybV9z Y2lfdHlwZSA9IFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfTk9ORTsNCj4+ICAgICAgIGVsc2Ug aWYgKCAhc3RyY21wKHNjaV90eXBlLCAic2NtaV9zbWMiKSApDQo+PiAgICAgICAgICAgZF9jZmct PmFyY2guYXJtX3NjaV90eXBlID0gWEVOX0RPTUNUTF9DT05GSUdfQVJNX1NDSV9TQ01JX1NNQzsN Cj4+ICsgICAgZWxzZSBpZiAoICFzdHJjbXAoc2NpX3R5cGUsICJzY21pX3NtY19tdWx0aWFnZW50 IikgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICB1aW50MzJfdCBhZ2VudF9pZCA9IDA7DQo+PiAr DQo+PiArICAgICAgICBpZiAoICFkdF9wcm9wZXJ0eV9yZWFkX3UzMihub2RlLCAieGVuLHNjaS1h Z2VudC1pZCIsICZhZ2VudF9pZCkgfHwNCj4+ICsgICAgICAgICAgICAgYWdlbnRfaWQgPiBVSU5U OF9NQVggKQ0KPj4gKyAgICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gKw0KPj4gKyAgICAg ICAgZF9jZmctPmFyY2guYXJtX3NjaV90eXBlID0gWEVOX0RPTUNUTF9DT05GSUdfQVJNX1NDSV9T Q01JX1NNQ19NQTsNCj4+ICsgICAgICAgIGRfY2ZnLT5hcmNoLmFybV9zY2lfYWdlbnRfaWQgPSBh Z2VudF9pZDsNCj4+ICsgICAgfQ0KPj4gICAgICAgZWxzZQ0KPj4gICAgICAgew0KPj4gICAgICAg ICAgIHByaW50ayhYRU5MT0dfRVJSICJ4ZW4sc2NpX3R5cGUgaW4gbm90IHZhbGlkICglcykgZm9y IGRvbWFpbiAlc1xuIiwNCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxk LmMgYi94ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMNCj4+IGluZGV4IGZiOGZiYjE2NTAuLjc5 NGVhMWFhNDIgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMNCj4+ ICsrKyBiL3hlbi9hcmNoL2FybS9kb21haW5fYnVpbGQuYw0KPj4gQEAgLTU1LDYgKzU1LDEwIEBA IGJvb2xlYW5fcGFyYW0oImV4dF9yZWdpb25zIiwgb3B0X2V4dF9yZWdpb25zKTsNCj4+ICAgc3Rh dGljIHU2NCBfX2luaXRkYXRhIGRvbTBfbWVtOw0KPj4gICBzdGF0aWMgYm9vbCBfX2luaXRkYXRh IGRvbTBfbWVtX3NldDsNCj4+DQo+PiArLyogU0NNSSBhZ2VudCBJRCBmb3IgZG9tMCwgcGFyc2Vk IGZyb20gZG9tMD1zY2ktYWdlbnQtaWQ9PHZhbHVlPiAqLw0KPj4gKyNkZWZpbmUgU0NNSV9BR0VO VF9JRF9JTlZBTElEIDB4RkYNCj4+ICtzdGF0aWMgdWludDhfdCBfX2luaXRkYXRhIG9wdF9kb20w X3NjbWlfYWdlbnRfaWQgPSBTQ01JX0FHRU5UX0lEX0lOVkFMSUQ7DQo+PiArDQo+PiAgIHN0YXRp YyBpbnQgX19pbml0IHBhcnNlX2RvbTBfbWVtKGNvbnN0IGNoYXIgKnMpDQo+PiAgIHsNCj4+ICAg ICAgIGRvbTBfbWVtX3NldCA9IHRydWU7DQo+PiBAQCAtODMsNiArODcsMTYgQEAgaW50IF9faW5p dCBwYXJzZV9hcmNoX2RvbTBfcGFyYW0oY29uc3QgY2hhciAqcywgY29uc3QgY2hhciAqZSkNCj4+ ICAgI2VuZGlmDQo+PiAgICAgICB9DQo+Pg0KPj4gKyAgICBpZiAoICFwYXJzZV9zaWduZWRfaW50 ZWdlcigic2NpLWFnZW50LWlkIiwgcywgZSwgJnZhbCkgKQ0KPj4gKyAgICB7DQo+PiArICAgICAg ICBpZiAoICh2YWwgPj0gMCkgJiYgKHZhbCA8PSBVSU5UOF9NQVgpICkNCj4+ICsgICAgICAgICAg ICBvcHRfZG9tMF9zY21pX2FnZW50X2lkID0gdmFsOw0KPiB3ZSBzaG91bGQgcHJldmVudCBTQ01J X0FHRU5UX0lEX0lOVkFMSUQgZnJvbSBiZWluZyBhc3NpZ25lZA0KPg0KPg0KPj4gKyAgICAgICAg ZWxzZQ0KPj4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfSU5GTyAiJ3NjaS1hZ2VudC1pZD0l bGxkJyB2YWx1ZSBvdXQgb2YgcmFuZ2UhXG4iLCB2YWwpOw0KPj4gKw0KPj4gKyAgICAgICAgcmV0 dXJuIDA7DQo+PiArICAgIH0NCj4+ICsNCj4+ICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gICB9 DQo+Pg0KPj4gQEAgLTUwOSw3ICs1MjMsOCBAQCBzdGF0aWMgaW50IF9faW5pdCB3cml0ZV9wcm9w ZXJ0aWVzKHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBrZXJuZWxfaW5mbyAqa2luZm8sDQo+PiAg ICAgICAgICAgICAgICAgICAgZHRfcHJvcGVydHlfbmFtZV9pc19lcXVhbChwcm9wLCAibGludXgs dWVmaS1tbWFwLXN0YXJ0IikgfHwNCj4+ICAgICAgICAgICAgICAgICAgICBkdF9wcm9wZXJ0eV9u YW1lX2lzX2VxdWFsKHByb3AsICJsaW51eCx1ZWZpLW1tYXAtc2l6ZSIpIHx8DQo+PiAgICAgICAg ICAgICAgICAgICAgZHRfcHJvcGVydHlfbmFtZV9pc19lcXVhbChwcm9wLCAibGludXgsdWVmaS1t bWFwLWRlc2Mtc2l6ZSIpIHx8DQo+PiAtICAgICAgICAgICAgICAgICBkdF9wcm9wZXJ0eV9uYW1l X2lzX2VxdWFsKHByb3AsICJsaW51eCx1ZWZpLW1tYXAtZGVzYy12ZXIiKSkNCj4+ICsgICAgICAg ICAgICAgICAgIGR0X3Byb3BlcnR5X25hbWVfaXNfZXF1YWwocHJvcCwgImxpbnV4LHVlZmktbW1h cC1kZXNjLXZlciIpIHx8DQo+PiArICAgICAgICAgICAgICAgICBkdF9wcm9wZXJ0eV9uYW1lX2lz X2VxdWFsKHByb3AsICJ4ZW4sY29uZmlnIikgKQ0KPiBzaG91bGQgYmUgdXBkYXRlZA0KPg0KKw0K Pj4gICAgICAgICAgICAgICAgICAgY29udGludWU7DQo+Pg0KPj4gICAgICAgICAgICAgICBpZiAo IGR0X3Byb3BlcnR5X25hbWVfaXNfZXF1YWwocHJvcCwgInhlbixkb20wLWJvb3RhcmdzIikgKQ0K Pj4gQEAgLTIwNjcsNiArMjA4MiwxNSBAQCB2b2lkIF9faW5pdCBjcmVhdGVfZG9tMCh2b2lkKQ0K Pj4gICAgICAgZG9tMF9jZmcuYXJjaC50ZWVfdHlwZSA9IHRlZV9nZXRfdHlwZSgpOw0KPj4gICAg ICAgZG9tMF9jZmcubWF4X3ZjcHVzID0gZG9tMF9tYXhfdmNwdXMoKTsNCj4+DQo+PiArICAgIC8q IFNldCB1cCBTQ01JIGFnZW50IElEIGlmIHNwZWNpZmllZCBpbiBkb20wPSBjb21tYW5kIGxpbmUg Ki8NCj4+ICsgICAgaWYgKCBvcHRfZG9tMF9zY21pX2FnZW50X2lkICE9IFNDTUlfQUdFTlRfSURf SU5WQUxJRCApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIGRvbTBfY2ZnLmFyY2guYXJtX3NjaV90 eXBlID0gWEVOX0RPTUNUTF9DT05GSUdfQVJNX1NDSV9TQ01JX1NNQ19NQTsNCj4+ICsgICAgICAg IGRvbTBfY2ZnLmFyY2guYXJtX3NjaV9hZ2VudF9pZCA9IG9wdF9kb20wX3NjbWlfYWdlbnRfaWQ7 DQo+PiArICAgIH0NCj4+ICsgICAgZWxzZQ0KPj4gKyAgICAgICAgZG9tMF9jZmcuYXJjaC5hcm1f c2NpX3R5cGUgPSBYRU5fRE9NQ1RMX0NPTkZJR19BUk1fU0NJX05PTkU7DQo+PiArDQo+PiAgICAg ICBpZiAoIGlvbW11X2VuYWJsZWQgKQ0KPj4gICAgICAgICAgIGRvbTBfY2ZnLmZsYWdzIHw9IFhF Tl9ET01DVExfQ0RGX2lvbW11Ow0KPj4NCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZmly bXdhcmUvS2NvbmZpZyBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9LY29uZmlnDQo+PiBpbmRleCA1 YzVmMDg4MGM0Li45NzJjZDliMTczIDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gvYXJtL2Zpcm13 YXJlL0tjb25maWcNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9LY29uZmlnDQo+PiBA QCAtMjksNiArMjksMTggQEAgY29uZmlnIFNDTUlfU01DDQo+PiAgICAgICAgZHJpdmVyIGRvbWFp bi4NCj4+ICAgICAgICBVc2Ugd2l0aCBFTDMgZmlybXdhcmUgd2hpY2ggc3VwcG9ydHMgb25seSBz aW5nbGUgU0NNSSBPU1BNIGFnZW50Lg0KPj4NCj4+ICtjb25maWcgU0NNSV9TTUNfTUENCj4+ICsg ICAgYm9vbCAiRW5hYmxlIEFSTSBTQ01JIFNNQyBtdWx0aS1hZ2VudCBkcml2ZXIiDQo+PiArICAg IGRlcGVuZHMgb24gQVJNXzY0DQo+PiArICAgIHNlbGVjdCBBUk1fU0NJDQo+PiArICAgIGhlbHAN Cj4+ICsgICAgICBFbmFibGVzIFNDTUkgU01DL0hWQyBtdWx0aS1hZ2VudCBpbiBYRU4gdG8gcGFz cyBTQ01JIHJlcXVlc3RzIGZyb20gRG9tYWlucw0KPj4gKyAgICAgIHRvIEVMMyBmaXJtd2FyZSAo VEYtQSkgd2hpY2ggc3VwcG9ydHMgbXVsdGktYWdlbnQgZmVhdHVyZS4NCj4+ICsgICAgICBUaGlz IGZlYXR1cmUgYWxsb3dzIHRvIGVuYWJsZSBTQ01JIHBlciBEb21haW4gdXNpbmcgdW5pcXVlIFND TUkgYWdlbnRfaWQsDQo+PiArICAgICAgc28gRG9tYWluIGlzIGlkZW50aWZpZWQgYnkgRUwzIGZp cm13YXJlIGFzIGFuIFNDTUkgQWdlbnQgYW5kIGNhbiBhY2Nlc3MNCj4+ICsgICAgICBhbGxvd2Vk IHBsYXRmb3JtIHJlc291cmNlcyB0aHJvdWdoIGRlZGljYXRlZCBTTUMvSFZDIFNoYXJlZCBtZW1v cnkgYmFzZWQNCj4+ICsgICAgICB0cmFuc3BvcnQuDQo+PiArDQo+PiAgIGVuZGNob2ljZQ0KPj4N Cj4+ICAgZW5kbWVudQ0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9NYWtl ZmlsZSBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9NYWtlZmlsZQ0KPj4gaW5kZXggNzFiZGVmYzI0 YS4uMzc5MjdlNjkwZSAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9NYWtl ZmlsZQ0KPj4gKysrIGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL01ha2VmaWxlDQo+PiBAQCAtMSwy ICsxLDMgQEANCj4+ICAgb2JqLSQoQ09ORklHX0FSTV9TQ0kpICs9IHNjaS5vDQo+PiAgIG9iai0k KENPTkZJR19TQ01JX1NNQykgKz0gc2NtaS1zbWMubw0KPj4gK29iai0kKENPTkZJR19TQ01JX1NN Q19NQSkgKz0gc2NtaS1zaG1lbS5vIHNjbWktc21jLW11bHRpYWdlbnQubw0KPj4gZGlmZiAtLWdp dCBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXByb3RvLmggYi94ZW4vYXJjaC9hcm0vZmly bXdhcmUvc2NtaS1wcm90by5oDQo+PiBuZXcgZmlsZSBtb2RlIDEwMDY0NA0KPj4gaW5kZXggMDAw MDAwMDAwMC4uNDlmNjNjZmMwYQ0KPj4gLS0tIC9kZXYvbnVsbA0KPj4gKysrIGIveGVuL2FyY2gv YXJtL2Zpcm13YXJlL3NjbWktcHJvdG8uaA0KPj4gQEAgLTAsMCArMSwxNjQgQEANCj4+ICsvKiBT UERYLUxpY2Vuc2UtSWRlbnRpZmllcjogR1BMLTIuMC1vbmx5ICovDQo+PiArLyoNCj4+ICsgKiBB cm0gU3lzdGVtIENvbnRyb2wgYW5kIE1hbmFnZW1lbnQgSW50ZXJmYWNlIGRlZmluaXRpb25zDQo+ PiArICogVmVyc2lvbiAzLjAgKERFTjAwNTZDKQ0KPj4gKyAqDQo+PiArICogQ29weXJpZ2h0IChj KSAyMDI1IEVQQU0gU3lzdGVtcw0KPj4gKyAqLw0KPj4gKw0KPj4gKyNpZm5kZWYgQVJNX0ZJUk1X QVJFX1NDTUlfUFJPVE9fSF8NCj4+ICsjZGVmaW5lIEFSTV9GSVJNV0FSRV9TQ01JX1BST1RPX0hf DQo+PiArDQo+PiArI2luY2x1ZGUgPHhlbi9zdGRpbnQuaD4NCj4+ICsNCj4+ICsjZGVmaW5lIFND TUlfU0hPUlRfTkFNRV9NQVhfU0laRSAxNg0KPj4gKw0KPj4gKy8qIFNDTUkgc3RhdHVzIGNvZGVz LiBTZWUgc2VjdGlvbiA0LjEuNCAqLw0KPj4gKyNkZWZpbmUgU0NNSV9TVUNDRVNTICAgICAgICAg ICAgICAwDQo+PiArI2RlZmluZSBTQ01JX05PVF9TVVBQT1JURUQgICAgICAoLTEpDQo+PiArI2Rl ZmluZSBTQ01JX0lOVkFMSURfUEFSQU1FVEVSUyAoLTIpDQo+PiArI2RlZmluZSBTQ01JX0RFTklF RCAgICAgICAgICAgICAoLTMpDQo+PiArI2RlZmluZSBTQ01JX05PVF9GT1VORCAgICAgICAgICAo LTQpDQo+PiArI2RlZmluZSBTQ01JX09VVF9PRl9SQU5HRSAgICAgICAoLTUpDQo+PiArI2RlZmlu ZSBTQ01JX0JVU1kgICAgICAgICAgICAgICAoLTYpDQo+PiArI2RlZmluZSBTQ01JX0NPTU1TX0VS Uk9SICAgICAgICAoLTcpDQo+PiArI2RlZmluZSBTQ01JX0dFTkVSSUNfRVJST1IgICAgICAoLTgp DQo+PiArI2RlZmluZSBTQ01JX0hBUkRXQVJFX0VSUk9SICAgICAoLTkpDQo+PiArI2RlZmluZSBT Q01JX1BST1RPQ09MX0VSUk9SICAgICAoLTEwKQ0KPj4gKw0KPj4gKy8qIFByb3RvY29sIElEcyAq Lw0KPj4gKyNkZWZpbmUgU0NNSV9CQVNFX1BST1RPQ09MIDB4MTANCj4+ICsNCj4+ICsvKiBCYXNl IHByb3RvY29sIG1lc3NhZ2UgSURzICovDQo+PiArI2RlZmluZSBTQ01JX0JBU0VfUFJPVE9DT0xf VkVSU0lPTiAgICAgICAgICAgIDB4MA0KPj4gKyNkZWZpbmUgU0NNSV9CQVNFX1BST1RPQ09MX0FU VElCVVRFUyAgICAgICAgICAweDENCj4+ICsjZGVmaW5lIFNDTUlfQkFTRV9QUk9UT0NPTF9NRVNT QUdFX0FUVFJJQlVURVMgMHgyDQo+PiArI2RlZmluZSBTQ01JX0JBU0VfRElTQ09WRVJfQUdFTlQg ICAgICAgICAgICAgIDB4Nw0KPj4gKyNkZWZpbmUgU0NNSV9CQVNFX1NFVF9ERVZJQ0VfUEVSTUlT U0lPTlMgICAgICAweDkNCj4+ICsjZGVmaW5lIFNDTUlfQkFTRV9SRVNFVF9BR0VOVF9DT05GSUdV UkFUSU9OICAgMHhCDQo+PiArDQo+PiArdHlwZWRlZiBzdHJ1Y3Qgc2NtaV9tc2dfaGVhZGVyIHsN Cj4+ICsgICAgdWludDhfdCBpZDsNCj4+ICsgICAgdWludDhfdCB0eXBlOw0KPj4gKyAgICB1aW50 OF90IHByb3RvY29sOw0KPj4gKyAgICB1aW50MzJfdCBzdGF0dXM7DQo+PiArfSBzY21pX21zZ19o ZWFkZXJfdDsNCj4+ICsNCj4+ICsvKiBUYWJsZSAyIE1lc3NhZ2UgaGVhZGVyIGZvcm1hdCAqLw0K Pj4gKyNkZWZpbmUgU0NNSV9IRFJfSUQgICAgR0VOTUFTSyg3LCAwKQ0KPj4gKyNkZWZpbmUgU0NN SV9IRFJfVFlQRSAgR0VOTUFTSyg5LCA4KQ0KPj4gKyNkZWZpbmUgU0NNSV9IRFJfUFJPVE8gR0VO TUFTSygxNywgMTApDQo+PiArDQo+PiArI2RlZmluZSBTQ01JX0ZJRUxEX0dFVChfbWFzaywgX3Jl ZykgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCj4+ICsgICAg KCh0eXBlb2YoX21hc2spKSgoKF9yZWcpICYgKF9tYXNrKSkgPj4gKGZmczY0KF9tYXNrKSAtIDEp KSkNCj4+ICsjZGVmaW5lIFNDTUlfRklFTERfUFJFUChfbWFzaywgX3ZhbCkgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXA0KPj4gKyAgICAoKCh0eXBlb2YoX21hc2sp KShfdmFsKSA8PCAoZmZzNjQoX21hc2spIC0gMSkpICYgKF9tYXNrKSkNCj4+ICsNCj4+ICtzdGF0 aWMgaW5saW5lIHVpbnQzMl90IHBhY2tfc2NtaV9oZWFkZXIoc2NtaV9tc2dfaGVhZGVyX3QgKmhk cikNCj4+ICt7DQo+PiArICAgIHJldHVybiBTQ01JX0ZJRUxEX1BSRVAoU0NNSV9IRFJfSUQsIGhk ci0+aWQpIHwNCj4+ICsgICAgICAgICAgIFNDTUlfRklFTERfUFJFUChTQ01JX0hEUl9UWVBFLCBo ZHItPnR5cGUpIHwNCj4+ICsgICAgICAgICAgIFNDTUlfRklFTERfUFJFUChTQ01JX0hEUl9QUk9U TywgaGRyLT5wcm90b2NvbCk7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBpbmxpbmUgdm9pZCB1 bnBhY2tfc2NtaV9oZWFkZXIodWludDMyX3QgbXNnX2hkciwgc2NtaV9tc2dfaGVhZGVyX3QgKmhk cikNCj4+ICt7DQo+PiArICAgIGhkci0+aWQgPSBTQ01JX0ZJRUxEX0dFVChTQ01JX0hEUl9JRCwg bXNnX2hkcik7DQo+PiArICAgIGhkci0+dHlwZSA9IFNDTUlfRklFTERfR0VUKFNDTUlfSERSX1RZ UEUsIG1zZ19oZHIpOw0KPj4gKyAgICBoZHItPnByb3RvY29sID0gU0NNSV9GSUVMRF9HRVQoU0NN SV9IRFJfUFJPVE8sIG1zZ19oZHIpOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgaW5saW5lIGlu dCBzY21pX3RvX3hlbl9lcnJubyhpbnQgc2NtaV9zdGF0dXMpDQo+PiArew0KPj4gKyAgICBpZiAo IHNjbWlfc3RhdHVzID09IFNDTUlfU1VDQ0VTUyApDQo+PiArICAgICAgICByZXR1cm4gMDsNCj4+ ICsNCj4+ICsgICAgc3dpdGNoICggc2NtaV9zdGF0dXMgKQ0KPj4gKyAgICB7DQo+PiArICAgIGNh c2UgU0NNSV9OT1RfU1VQUE9SVEVEOg0KPj4gKyAgICAgICAgcmV0dXJuIC1FT1BOT1RTVVBQOw0K Pj4gKyAgICBjYXNlIFNDTUlfSU5WQUxJRF9QQVJBTUVURVJTOg0KPj4gKyAgICAgICAgcmV0dXJu IC1FSU5WQUw7DQo+PiArICAgIGNhc2UgU0NNSV9ERU5JRUQ6DQo+PiArICAgICAgICByZXR1cm4g LUVBQ0NFUzsNCj4+ICsgICAgY2FzZSBTQ01JX05PVF9GT1VORDoNCj4+ICsgICAgICAgIHJldHVy biAtRU5PRU5UOw0KPj4gKyAgICBjYXNlIFNDTUlfT1VUX09GX1JBTkdFOg0KPj4gKyAgICAgICAg cmV0dXJuIC1FUkFOR0U7DQo+PiArICAgIGNhc2UgU0NNSV9CVVNZOg0KPj4gKyAgICAgICAgcmV0 dXJuIC1FQlVTWTsNCj4+ICsgICAgY2FzZSBTQ01JX0NPTU1TX0VSUk9SOg0KPj4gKyAgICAgICAg cmV0dXJuIC1FTk9UQ09OTjsNCj4+ICsgICAgY2FzZSBTQ01JX0dFTkVSSUNfRVJST1I6DQo+PiAr ICAgICAgICByZXR1cm4gLUVJTzsNCj4+ICsgICAgY2FzZSBTQ01JX0hBUkRXQVJFX0VSUk9SOg0K Pj4gKyAgICAgICAgcmV0dXJuIC1FTlhJTzsNCj4+ICsgICAgY2FzZSBTQ01JX1BST1RPQ09MX0VS Uk9SOg0KPj4gKyAgICAgICAgcmV0dXJuIC1FQkFETVNHOw0KPj4gKyAgICBkZWZhdWx0Og0KPj4g KyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArICAgIH0NCj4+ICt9DQo+PiArDQo+PiArLyog UFJPVE9DT0xfVkVSU0lPTiAqLw0KPj4gKyNkZWZpbmUgU0NNSV9WRVJTSU9OX01JTk9SIEdFTk1B U0soMTUsIDApDQo+PiArI2RlZmluZSBTQ01JX1ZFUlNJT05fTUFKT1IgR0VOTUFTSygzMSwgMTYp DQo+PiArDQo+PiArc3RydWN0IHNjbWlfbXNnX3Byb3RfdmVyc2lvbl9wMmEgew0KPj4gKyAgICB1 aW50MzJfdCB2ZXJzaW9uOw0KPj4gK30gX19wYWNrZWQ7DQo+PiArDQo+PiArLyogQkFTRSBQUk9U T0NPTF9BVFRSSUJVVEVTICovDQo+PiArI2RlZmluZSBTQ01JX0JBU0VfQVRUUl9OVU1fUFJPVE8g R0VOTUFTSyg3LCAwKQ0KPj4gKyNkZWZpbmUgU0NNSV9CQVNFX0FUVFJfTlVNX0FHRU5UIEdFTk1B U0soMTUsIDgpDQo+PiArDQo+PiArc3RydWN0IHNjbWlfbXNnX2Jhc2VfYXR0cmlidXRlc19wMmEg ew0KPj4gKyAgICB1aW50MzJfdCBhdHRyaWJ1dGVzOw0KPj4gK30gX19wYWNrZWQ7DQo+PiArDQo+ PiArLyoNCj4+ICsgKiBCQVNFX0RJU0NPVkVSX0FHRU5UDQo+PiArICovDQo+PiArI2RlZmluZSBT Q01JX0JBU0VfQUdFTlRfSURfT1dOIDB4RkZGRkZGRkYNCj4+ICsNCj4+ICtzdHJ1Y3Qgc2NtaV9t c2dfYmFzZV9kaXNjb3Zlcl9hZ2VudF9hMnAgew0KPj4gKyAgICB1aW50MzJfdCBhZ2VudF9pZDsN Cj4+ICt9IF9fcGFja2VkOw0KPj4gKw0KPj4gK3N0cnVjdCBzY21pX21zZ19iYXNlX2Rpc2NvdmVy X2FnZW50X3AyYSB7DQo+PiArICAgIHVpbnQzMl90IGFnZW50X2lkOw0KPj4gKyAgICBjaGFyIG5h bWVbU0NNSV9TSE9SVF9OQU1FX01BWF9TSVpFXTsNCj4+ICt9IF9fcGFja2VkOw0KPj4gKw0KPj4g Ky8qDQo+PiArICogQkFTRV9TRVRfREVWSUNFX1BFUk1JU1NJT05TDQo+PiArICovDQo+PiArI2Rl ZmluZSBTQ01JX0JBU0VfREVWSUNFX0FDQ0VTU19BTExPVyAgICAgICAgICAgQklUKDAsIFVMKQ0K Pj4gKw0KPj4gK3N0cnVjdCBzY21pX21zZ19iYXNlX3NldF9kZXZpY2VfcGVybWlzc2lvbnNfYTJw IHsNCj4+ICsgICAgdWludDMyX3QgYWdlbnRfaWQ7DQo+PiArICAgIHVpbnQzMl90IGRldmljZV9p ZDsNCj4+ICsgICAgdWludDMyX3QgZmxhZ3M7DQo+PiArfSBfX3BhY2tlZDsNCj4+ICsNCj4+ICsv Kg0KPj4gKyAqIEJBU0VfUkVTRVRfQUdFTlRfQ09ORklHVVJBVElPTg0KPj4gKyAqLw0KPj4gKyNk ZWZpbmUgU0NNSV9CQVNFX0FHRU5UX1BFUk1JU1NJT05TX1JFU0VUICAgICAgIEJJVCgwLCBVTCkN Cj4+ICsNCj4+ICtzdHJ1Y3Qgc2NtaV9tc2dfYmFzZV9yZXNldF9hZ2VudF9jZmdfYTJwIHsNCj4+ ICsgICAgdWludDMyX3QgYWdlbnRfaWQ7DQo+PiArICAgIHVpbnQzMl90IGZsYWdzOw0KPj4gK30g X19wYWNrZWQ7DQo+PiArDQo+PiArI2VuZGlmIC8qIEFSTV9GSVJNV0FSRV9TQ01JX1BST1RPX0hf ICovDQo+PiArDQo+PiArLyoNCj4+ICsgKiBMb2NhbCB2YXJpYWJsZXM6DQo+PiArICogbW9kZTog Qw0KPj4gKyAqIGMtZmlsZS1zdHlsZTogIkJTRCINCj4+ICsgKiBjLWJhc2ljLW9mZnNldDogNA0K Pj4gKyAqIHRhYi13aWR0aDogNA0KPj4gKyAqIGluZGVudC10YWJzLW1vZGU6IG5pbA0KPj4gKyAq IEVuZDoNCj4+ICsgKi8NCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2Nt aS1zaG1lbS5jIGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uYw0KPj4gbmV3IGZp bGUgbW9kZSAxMDA2NDQNCj4+IGluZGV4IDAwMDAwMDAwMDAuLjExMjUwN2JhMmENCj4+IC0tLSAv ZGV2L251bGwNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmMNCj4+ IEBAIC0wLDAgKzEsMTE1IEBADQo+PiArLyogU1BEWC1MaWNlbnNlLUlkZW50aWZpZXI6IEdQTC0y LjAtb25seSAqLw0KPj4gKy8qDQo+PiArICogU01DL0hWQyBzaG1lbSB0cmFuc3BvcnQgaW1wbGVt ZW50YXRpb24gdXNlZCBieQ0KPj4gKyAqIFNDSSBTQ01JIG11bHRpLWFnZW50IGRyaXZlci4NCj4+ ICsgKg0KPj4gKyAqIE9sZWtzaWkgTW9pc2llaWV2PG9sZWtzaWlfbW9pc2llaWV2QGVwYW0uY29t Pg0KPj4gKyAqIENvcHlyaWdodCAoYykgMjAyNSBFUEFNIFN5c3RlbXMNCj4+ICsgKi8NCj4+ICsv KiBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogR1BMLTIuMC1vbmx5ICovDQo+PiArDQo+PiArI2lu Y2x1ZGUgPHhlbi9lcnIuaD4NCj4+ICsjaW5jbHVkZSA8eGVuL2xpYi9pby5oPg0KPj4gKyNpbmNs dWRlIDxhc20vaW8uaD4NCj4+ICsNCj4+ICsjaW5jbHVkZSAic2NtaS1wcm90by5oIg0KPj4gKyNp bmNsdWRlICJzY21pLXNobWVtLmgiDQo+PiArDQo+PiArc3RhdGljIGlubGluZSBpbnQNCj4+ICtz aG1lbV9jaGFubmVsX2lzX2ZyZWUoY29uc3Qgdm9sYXRpbGUgc3RydWN0IHNjbWlfc2hhcmVkX21l bSBfX2lvbWVtICpzaG1lbSkNCj4+ICt7DQo+PiArICAgIHJldHVybiAocmVhZGwoJnNobWVtLT5j aGFubmVsX3N0YXR1cykgJg0KPj4gKyAgICAgICAgICAgIFNDTUlfU0hNRU1fQ0hBTl9TVEFUX0NI QU5ORUxfRlJFRSkgPyAwIDogLUVCVVNZOw0KPj4gK30NCj4+ICsNCj4+ICtpbnQgc2htZW1fcHV0 X21lc3NhZ2Uodm9sYXRpbGUgc3RydWN0IHNjbWlfc2hhcmVkX21lbSBfX2lvbWVtICpzaG1lbSwN Cj4+ICsgICAgICAgICAgICAgICAgICAgICAgc2NtaV9tc2dfaGVhZGVyX3QgKmhkciwgdm9pZCAq ZGF0YSwgaW50IGxlbikNCj4+ICt7DQo+PiArICAgIGludCByZXQ7DQo+PiArDQo+PiArICAgIGlm ICggKGxlbiArIG9mZnNldG9mKHN0cnVjdCBzY21pX3NoYXJlZF9tZW0sIG1zZ19wYXlsb2FkKSkg Pg0KPj4gKyAgICAgICAgIFNDTUlfU0hNRU1fTUFQUEVEX1NJWkUgKQ0KPj4gKyAgICB7DQo+PiAr ICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAic2NtaTogV3Jvbmcgc2l6ZSBvZiBzbWMgbWVzc2Fn ZS4gRGF0YSBpcyBpbnZhbGlkXG4iKTsNCj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4g KyAgICB9DQo+PiArDQo+PiArICAgIHJldCA9IHNobWVtX2NoYW5uZWxfaXNfZnJlZShzaG1lbSk7 DQo+PiArICAgIGlmICggcmV0ICkNCj4+ICsgICAgICAgIHJldHVybiByZXQ7DQo+PiArDQo+PiAr ICAgIHdyaXRlbF9yZWxheGVkKDB4MCwgJnNobWVtLT5jaGFubmVsX3N0YXR1cyk7DQo+PiArICAg IC8qIFdyaXRpbmcgMHgwIHJpZ2h0IG5vdywgYnV0ICJzaG1lbSJfRkxBR19JTlRSX0VOQUJMRUQg Y2FuIGJlIHNldCAqLw0KPj4gKyAgICB3cml0ZWxfcmVsYXhlZCgweDAsICZzaG1lbS0+ZmxhZ3Mp Ow0KPj4gKyAgICB3cml0ZWxfcmVsYXhlZChzaXplb2Yoc2htZW0tPm1zZ19oZWFkZXIpICsgbGVu LCAmc2htZW0tPmxlbmd0aCk7DQo+PiArICAgIHdyaXRlbChwYWNrX3NjbWlfaGVhZGVyKGhkciks ICZzaG1lbS0+bXNnX2hlYWRlcik7DQo+PiArDQo+PiArICAgIGlmICggbGVuID4gMCAmJiBkYXRh ICkNCj4+ICsgICAgICAgIG1lbWNweV90b2lvKHNobWVtLT5tc2dfcGF5bG9hZCwgZGF0YSwgbGVu KTsNCj4+ICsNCj4+ICsgICAgcmV0dXJuIDA7DQo+PiArfQ0KPj4gKw0KPj4gK2ludCBzaG1lbV9n ZXRfcmVzcG9uc2UoY29uc3Qgdm9sYXRpbGUgc3RydWN0IHNjbWlfc2hhcmVkX21lbSBfX2lvbWVt ICpzaG1lbSwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgIHNjbWlfbXNnX2hlYWRlcl90ICpo ZHIsIHZvaWQgKmRhdGEsIGludCBsZW4pDQo+PiArew0KPj4gKyAgICBpbnQgcmVjdl9sZW47DQo+ PiArICAgIGludCByZXQ7DQo+PiArICAgIGludCBwYWQgPSBzaXplb2YoaGRyLT5zdGF0dXMpOw0K Pj4gKw0KPj4gKyAgICBpZiAoIGxlbiA+PSBTQ01JX1NITUVNX01BUFBFRF9TSVpFIC0NCj4+ICsg ICAgICAgICBvZmZzZXRvZihzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtLCBtc2dfcGF5bG9hZCkgKQ0K Pj4gKyAgICB7DQo+PiArICAgICAgICBwcmludGsoWEVOTE9HX0VSUg0KPj4gKyAgICAgICAgICAg ICAgICJzY21pOiBXcm9uZyBzaXplIG9mIGlucHV0IHNtYyBtZXNzYWdlLiBEYXRhIG1heSBiZSBp bnZhbGlkXG4iKTsNCj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gKyAgICB9DQo+PiAr DQo+PiArICAgIHJldCA9IHNobWVtX2NoYW5uZWxfaXNfZnJlZShzaG1lbSk7DQo+PiArICAgIGlm ICggcmV0ICkNCj4+ICsgICAgICAgIHJldHVybiByZXQ7DQo+PiArDQo+PiArICAgIHJlY3ZfbGVu ID0gcmVhZGwoJnNobWVtLT5sZW5ndGgpIC0gc2l6ZW9mKHNobWVtLT5tc2dfaGVhZGVyKTsNCj4+ ICsNCj4+ICsgICAgaWYgKCByZWN2X2xlbiA8IDAgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBw cmludGsoWEVOTE9HX0VSUg0KPj4gKyAgICAgICAgICAgICAgICJzY21pOiBXcm9uZyBzaXplIG9m IHNtYyBtZXNzYWdlLiBEYXRhIG1heSBiZSBpbnZhbGlkXG4iKTsNCj4+ICsgICAgICAgIHJldHVy biAtRUlOVkFMOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIHVucGFja19zY21pX2hlYWRlcihy ZWFkbCgmc2htZW0tPm1zZ19oZWFkZXIpLCBoZHIpOw0KPj4gKw0KPj4gKyAgICBoZHItPnN0YXR1 cyA9IHJlYWRsKCZzaG1lbS0+bXNnX3BheWxvYWQpOw0KPj4gKyAgICByZWN2X2xlbiA9IHJlY3Zf bGVuID4gcGFkID8gcmVjdl9sZW4gLSBwYWQgOiAwOw0KPj4gKw0KPj4gKyAgICByZXQgPSBzY21p X3RvX3hlbl9lcnJubyhoZHItPnN0YXR1cyk7DQo+PiArICAgIGlmICggcmV0ICkNCj4+ICsgICAg ew0KPj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19ERUJVRyAic2NtaTogRXJyb3IgcmVjZWl2ZWQ6 ICVkXG4iLCByZXQpOw0KPj4gKyAgICAgICAgcmV0dXJuIHJldDsNCj4+ICsgICAgfQ0KPj4gKw0K Pj4gKyAgICBpZiAoIHJlY3ZfbGVuID4gbGVuICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJp bnRrKFhFTkxPR19FUlINCj4+ICsgICAgICAgICAgICAgICAic2NtaTogTm90IGVub3VnaCBidWZm ZXIgZm9yIG1lc3NhZ2UgJWQsIGV4cGVjdGluZyAlZFxuIiwNCj4+ICsgICAgICAgICAgICAgICBy ZWN2X2xlbiwgbGVuKTsNCj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gKyAgICB9DQo+ PiArDQo+PiArICAgIGlmICggcmVjdl9sZW4gPiAwICkNCj4+ICsgICAgICAgIG1lbWNweV9mcm9t aW8oZGF0YSwgc2htZW0tPm1zZ19wYXlsb2FkICsgcGFkLCByZWN2X2xlbik7DQo+PiArDQo+PiAr ICAgIHJldHVybiAwOw0KPj4gK30NCj4+ICsNCj4+ICsvKg0KPj4gKyAqIExvY2FsIHZhcmlhYmxl czoNCj4+ICsgKiBtb2RlOiBDDQo+PiArICogYy1maWxlLXN0eWxlOiAiQlNEIg0KPj4gKyAqIGMt YmFzaWMtb2Zmc2V0OiA0DQo+PiArICogdGFiLXdpZHRoOiA0DQo+PiArICogaW5kZW50LXRhYnMt bW9kZTogbmlsDQo+PiArICogRW5kOg0KPj4gKyAqLw0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNo L2FybS9maXJtd2FyZS9zY21pLXNobWVtLmggYi94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1z aG1lbS5oDQo+PiBuZXcgZmlsZSBtb2RlIDEwMDY0NA0KPj4gaW5kZXggMDAwMDAwMDAwMC4uNzMx M2NiNmIyNg0KPj4gLS0tIC9kZXYvbnVsbA0KPj4gKysrIGIveGVuL2FyY2gvYXJtL2Zpcm13YXJl L3NjbWktc2htZW0uaA0KPj4gQEAgLTAsMCArMSw0NSBAQA0KPj4gKy8qIFNQRFgtTGljZW5zZS1J ZGVudGlmaWVyOiBHUEwtMi4wLW9ubHkgKi8NCj4+ICsvKg0KPj4gKyAqIEFybSBTeXN0ZW0gQ29u dHJvbCBhbmQgTWFuYWdlbWVudCBJbnRlcmZhY2UgZGVmaW5pdGlvbnMNCj4+ICsgKiBWZXJzaW9u IDMuMCAoREVOMDA1NkMpDQo+PiArICogU2hhcmVkIE1lbW9yeSBiYXNlZCBUcmFuc3BvcnQNCj4+ ICsgKg0KPj4gKyAqIENvcHlyaWdodCAoYykgMjAyNCBFUEFNIFN5c3RlbXMNCj4+ICsgKi8NCj4+ ICsNCj4+ICsjaWZuZGVmIEFSTV9GSVJNV0FSRV9TQ01JX1NITUVNX0hfDQo+PiArI2RlZmluZSBB Uk1fRklSTVdBUkVfU0NNSV9TSE1FTV9IXw0KPj4gKw0KPj4gKyNpbmNsdWRlIDx4ZW4vc3RkaW50 Lmg+DQo+PiArDQo+PiArI2RlZmluZSBTQ01JX1NITUVNX0NIQU5fU1RBVF9DSEFOTkVMX0ZSRUUg IEJJVCgwLCBVTCkNCj4+ICsjZGVmaW5lIFNDTUlfU0hNRU1fQ0hBTl9TVEFUX0NIQU5ORUxfRVJS T1IgQklUKDEsIFVMKQ0KPj4gKw0KPj4gK3N0cnVjdCBzY21pX3NoYXJlZF9tZW0gew0KPj4gKyAg ICB1aW50MzJfdCByZXNlcnZlZDsNCj4+ICsgICAgdWludDMyX3QgY2hhbm5lbF9zdGF0dXM7DQo+ PiArICAgIHVpbnQzMl90IHJlc2VydmVkMVsyXTsNCj4+ICsgICAgdWludDMyX3QgZmxhZ3M7DQo+ PiArICAgIHVpbnQzMl90IGxlbmd0aDsNCj4+ICsgICAgdWludDMyX3QgbXNnX2hlYWRlcjsNCj4+ ICsgICAgdWludDhfdCBtc2dfcGF5bG9hZFtdOw0KPj4gK307DQo+PiArDQo+PiArI2RlZmluZSBT Q01JX1NITUVNX01BUFBFRF9TSVpFIFBBR0VfU0laRQ0KPj4gKw0KPj4gK2ludCBzaG1lbV9wdXRf bWVzc2FnZSh2b2xhdGlsZSBzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtIF9faW9tZW0gKnNobWVtLA0K Pj4gKyAgICAgICAgICAgICAgICAgICAgICBzY21pX21zZ19oZWFkZXJfdCAqaGRyLCB2b2lkICpk YXRhLCBpbnQgbGVuKTsNCj4+ICsNCj4+ICtpbnQgc2htZW1fZ2V0X3Jlc3BvbnNlKGNvbnN0IHZv bGF0aWxlIHN0cnVjdCBzY21pX3NoYXJlZF9tZW0gX19pb21lbSAqc2htZW0sDQo+PiArICAgICAg ICAgICAgICAgICAgICAgICBzY21pX21zZ19oZWFkZXJfdCAqaGRyLCB2b2lkICpkYXRhLCBpbnQg bGVuKTsNCj4+ICsjZW5kaWYgLyogQVJNX0ZJUk1XQVJFX1NDTUlfU0hNRU1fSF8gKi8NCj4+ICsN Cj4+ICsvKg0KPj4gKyAqIExvY2FsIHZhcmlhYmxlczoNCj4+ICsgKiBtb2RlOiBDDQo+PiArICog Yy1maWxlLXN0eWxlOiAiQlNEIg0KPj4gKyAqIGMtYmFzaWMtb2Zmc2V0OiA0DQo+PiArICogdGFi LXdpZHRoOiA0DQo+PiArICogaW5kZW50LXRhYnMtbW9kZTogbmlsDQo+PiArICogRW5kOg0KPj4g KyAqLw0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNtYy1tdWx0 aWFnZW50LmMgYi94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zbWMtbXVsdGlhZ2VudC5jDQo+ PiBuZXcgZmlsZSBtb2RlIDEwMDY0NA0KPj4gaW5kZXggMDAwMDAwMDAwMC4uYjc5MDQxZGFiYQ0K Pj4gLS0tIC9kZXYvbnVsbA0KPj4gKysrIGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc21j LW11bHRpYWdlbnQuYw0KPj4gQEAgLTAsMCArMSw4MTUgQEANCj4+ICsvKiBTUERYLUxpY2Vuc2Ut SWRlbnRpZmllcjogR1BMLTIuMC1vbmx5ICovDQo+PiArLyoNCj4+ICsgKiBTQ0kgU0NNSSBtdWx0 aS1hZ2VudCBkcml2ZXIsIHVzaW5nIFNNQy9IVkMgc2htZW0gYXMgdHJhbnNwb3J0Lg0KPj4gKyAq DQo+PiArICogT2xla3NpaSBNb2lzaWVpZXY8b2xla3NpaV9tb2lzaWVpZXZAZXBhbS5jb20+DQo+ PiArICogQ29weXJpZ2h0IChjKSAyMDI1IEVQQU0gU3lzdGVtcw0KPj4gKyAqLw0KPj4gKw0KPj4g KyNpbmNsdWRlIDx4ZW4vYWNwaS5oPg0KPj4gKw0KPj4gKyNpbmNsdWRlIDx4ZW4vZGV2aWNlX3Ry ZWUuaD4NCj4+ICsjaW5jbHVkZSA8eGVuL2luaXQuaD4NCj4+ICsjaW5jbHVkZSA8eGVuL2lvY2Fw Lmg+DQo+PiArI2luY2x1ZGUgPHhlbi9lcnIuaD4NCj4+ICsjaW5jbHVkZSA8eGVuL2xpYmZkdC9s aWJmZHQuaD4NCj4+ICsjaW5jbHVkZSA8eGVuL3N0cmluZy5oPg0KPj4gKyNpbmNsdWRlIDx4ZW4v cGFyYW0uaD4NCj4+ICsjaW5jbHVkZSA8eGVuL3NjaGVkLmg+DQo+PiArI2luY2x1ZGUgPHhlbi92 bWFwLmg+DQo+PiArDQo+PiArI2luY2x1ZGUgPGFzbS9maXJtd2FyZS9zY2kuaD4NCj4+ICsjaW5j bHVkZSA8YXNtL3NtY2NjLmg+DQo+PiArDQo+PiArI2luY2x1ZGUgInNjbWktcHJvdG8uaCINCj4+ ICsjaW5jbHVkZSAic2NtaS1zaG1lbS5oIg0KPj4gKw0KPj4gKyNkZWZpbmUgU0NNSV9BR0VOVF9J RF9JTlZBTElEIDB4RkYNCj4+ICsNCj4+ICsjZGVmaW5lIFNDTUlfU0VDT05EQVJZX0FHRU5UUyAi c2NtaS1zZWNvbmRhcnktYWdlbnRzIg0KPj4gKw0KPj4gK3N0cnVjdCBzY21pX2NoYW5uZWwgew0K Pj4gKyAgICB1aW50MzJfdCBhZ2VudF9pZDsNCj4+ICsgICAgdWludDMyX3QgZnVuY19pZDsNCj4+ ICsgICAgZG9taWRfdCBkb21haW5faWQ7DQo+PiArICAgIHVpbnQ2NF90IHBhZGRyOw0KPj4gKyAg ICBzdHJ1Y3Qgc2NtaV9zaGFyZWRfbWVtIF9faW9tZW0gKnNobWVtOw0KPj4gKyAgICBzcGlubG9j a190IGxvY2s7DQo+PiArICAgIHN0cnVjdCBsaXN0X2hlYWQgbGlzdDsNCj4+ICt9Ow0KPj4gKw0K Pj4gK3N0cnVjdCBzY21pX2RhdGEgew0KPj4gKyAgICBzdHJ1Y3QgbGlzdF9oZWFkIGNoYW5uZWxf bGlzdDsNCj4+ICsgICAgc3BpbmxvY2tfdCBjaGFubmVsX2xpc3RfbG9jazsNCj4+ICsgICAgdWlu dDMyX3QgZnVuY19pZDsNCj4+ICsgICAgYm9vbCBpbml0aWFsaXplZDsNCj4+ICsgICAgdWludDMy X3Qgc2htZW1fcGhhbmRsZTsNCj4+ICsgICAgdWludDMyX3QgaHlwX2NoYW5uZWxfYWdlbnRfaWQ7 DQo+PiArICAgIHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqZHRfZGV2Ow0KPj4gK307DQo+PiArDQo+ PiArc3RhdGljIHN0cnVjdCBzY21pX2RhdGEgc2NtaV9kYXRhOw0KPj4gKw0KPj4gK3N0YXRpYyBi b29sIHNjbWlfaXNfdW5kZXJfeGVuX3NjaShjb25zdCBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKm5v ZGUpDQo+PiArew0KPj4gKyAgICBjb25zdCBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKnA7DQo+PiAr DQo+PiArICAgIGZvciAoIHAgPSBub2RlLT5wYXJlbnQ7IHA7IHAgPSBwLT5wYXJlbnQgKQ0KPj4g KyAgICAgICAgaWYgKCBkdF9kZXZpY2VfaXNfY29tcGF0aWJsZShwLCAieGVuLHNjaSIpICkNCj4+ ICsgICAgICAgICAgICByZXR1cm4gdHJ1ZTsNCj4+ICsNCj4+ICsgICAgcmV0dXJuIGZhbHNlOw0K Pj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgaW50IHNlbmRfc21jX21lc3NhZ2Uoc3RydWN0IHNjbWlf Y2hhbm5lbCAqY2hhbl9pbmZvLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBzY21p X21zZ19oZWFkZXJfdCAqaGRyLCB2b2lkICpkYXRhLCBpbnQgbGVuKQ0KPj4gK3sNCj4+ICsgICAg c3RydWN0IGFybV9zbWNjY19yZXMgcmVzcDsNCj4+ICsgICAgaW50IHJldDsNCj4+ICsNCj4+ICsg ICAgcmV0ID0gc2htZW1fcHV0X21lc3NhZ2UoY2hhbl9pbmZvLT5zaG1lbSwgaGRyLCBkYXRhLCBs ZW4pOw0KPj4gKyAgICBpZiAoIHJldCApDQo+PiArICAgICAgICByZXR1cm4gcmV0Ow0KPj4gKw0K Pj4gKyAgICBhcm1fc21jY2NfMV8xX3NtYyhjaGFuX2luZm8tPmZ1bmNfaWQsIDAsIDAsIDAsIDAs IDAsIDAsIDAsICZyZXNwKTsNCj4+ICsNCj4+ICsgICAgaWYgKCByZXNwLmEwID09IEFSTV9TTUND Q19JTlZBTElEX1BBUkFNRVRFUiApDQo+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsN Cj4+ICsgICAgaWYgKCByZXNwLmEwICkNCj4+ICsgICAgICAgIHJldHVybiAtRU9QTk9UU1VQUDsN Cj4+ICsNCj4+ICsgICAgcmV0dXJuIDA7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBpbnQgZG9f c21jX3hmZXIoc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbl9pbmZvLCBzY21pX21zZ19oZWFkZXJf dCAqaGRyLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgdm9pZCAqdHhfZGF0YSwgaW50IHR4 X3NpemUsIHZvaWQgKnJ4X2RhdGEsIGludCByeF9zaXplKQ0KPj4gK3sNCj4+ICsgICAgaW50IHJl dCA9IDA7DQo+PiArDQo+PiArICAgIEFTU0VSVChjaGFuX2luZm8gJiYgY2hhbl9pbmZvLT5zaG1l bSk7DQo+PiArDQo+PiArICAgIGlmICggIWhkciApDQo+PiArICAgICAgICByZXR1cm4gLUVJTlZB TDsNCj4+ICsNCj4+ICsgICAgc3Bpbl9sb2NrKCZjaGFuX2luZm8tPmxvY2spOw0KPj4gKw0KPj4g KyAgICBwcmludGsoWEVOTE9HX0RFQlVHDQo+PiArICAgICAgICAgICAic2NtaTogYWdlbnRfaWQg PSAlZCBtc2dfaWQgPSAleCB0eXBlID0gJWQsIHByb3RvID0gJXhcbiIsDQo+PiArICAgICAgICAg ICBjaGFuX2luZm8tPmFnZW50X2lkLCBoZHItPmlkLCBoZHItPnR5cGUsIGhkci0+cHJvdG9jb2wp Ow0KPj4gKw0KPj4gKyAgICByZXQgPSBzZW5kX3NtY19tZXNzYWdlKGNoYW5faW5mbywgaGRyLCB0 eF9kYXRhLCB0eF9zaXplKTsNCj4+ICsgICAgaWYgKCByZXQgKQ0KPj4gKyAgICAgICAgZ290byBj bGVhbjsNCj4+ICsNCj4+ICsgICAgcmV0ID0gc2htZW1fZ2V0X3Jlc3BvbnNlKGNoYW5faW5mby0+ c2htZW0sIGhkciwgcnhfZGF0YSwgcnhfc2l6ZSk7DQo+PiArDQo+PiArY2xlYW46DQo+PiArICAg IHByaW50ayhYRU5MT0dfREVCVUcNCj4+ICsgICAgICAgICAgICJzY21pOiBnZXQgc21jIHJlc3Bv bnNlIGFnZW50X2lkID0gJWQgbXNnX2lkID0gJXggcHJvdG8gPSAleCByZXM9JWRcbiIsDQo+PiAr ICAgICAgICAgICBjaGFuX2luZm8tPmFnZW50X2lkLCBoZHItPmlkLCBoZHItPnByb3RvY29sLCBy ZXQpOw0KPj4gKw0KPj4gKyAgICBzcGluX3VubG9jaygmY2hhbl9pbmZvLT5sb2NrKTsNCj4+ICsN Cj4+ICsgICAgcmV0dXJuIHJldDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIHN0cnVjdCBzY21p X2NoYW5uZWwgKmdldF9jaGFubmVsX2J5X2lkKHVpbnQzMl90IGFnZW50X2lkKQ0KPj4gK3sNCj4+ ICsgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAqY3VycjsNCj4+ICsgICAgYm9vbCBmb3VuZCA9IGZh bHNlOw0KPj4gKw0KPj4gKyAgICBzcGluX2xvY2soJnNjbWlfZGF0YS5jaGFubmVsX2xpc3RfbG9j ayk7DQo+PiArICAgIGxpc3RfZm9yX2VhY2hfZW50cnkoY3VyciwgJnNjbWlfZGF0YS5jaGFubmVs X2xpc3QsIGxpc3QpDQo+PiArICAgIHsNCj4+ICsgICAgICAgIGlmICggY3Vyci0+YWdlbnRfaWQg PT0gYWdlbnRfaWQgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAgICAgIGZvdW5kID0gdHJ1 ZTsNCj4+ICsgICAgICAgICAgICBicmVhazsNCj4+ICsgICAgICAgIH0NCj4+ICsgICAgfQ0KPj4g Kw0KPj4gKyAgICBzcGluX3VubG9jaygmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdF9sb2NrKTsNCj4+ ICsgICAgaWYgKCBmb3VuZCApDQo+PiArICAgICAgICByZXR1cm4gY3VycjsNCj4+ICsNCj4+ICsg ICAgcmV0dXJuIE5VTEw7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBzdHJ1Y3Qgc2NtaV9jaGFu bmVsICphY3F1aXJlX3NjbWlfY2hhbm5lbChzdHJ1Y3QgZG9tYWluICpkLA0KPj4gKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBhZ2VudF9p ZCkNCj4+ICt7DQo+PiArICAgIHN0cnVjdCBzY21pX2NoYW5uZWwgKmN1cnI7DQo+PiArICAgIHN0 cnVjdCBzY21pX2NoYW5uZWwgKnJldCA9IEVSUl9QVFIoLUVOT0VOVCk7DQo+PiArDQo+PiArICAg IHNwaW5fbG9jaygmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdF9sb2NrKTsNCj4+ICsgICAgbGlzdF9m b3JfZWFjaF9lbnRyeShjdXJyLCAmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdCwgbGlzdCkNCj4+ICsg ICAgew0KPj4gKyAgICAgICAgaWYgKCBjdXJyLT5hZ2VudF9pZCA9PSBhZ2VudF9pZCApDQo+PiAr ICAgICAgICB7DQo+PiArICAgICAgICAgICAgaWYgKCBjdXJyLT5kb21haW5faWQgIT0gRE9NSURf SU5WQUxJRCApDQo+PiArICAgICAgICAgICAgew0KPj4gKyAgICAgICAgICAgICAgICByZXQgPSBF UlJfUFRSKC1FRVhJU1QpOw0KPj4gKyAgICAgICAgICAgICAgICBicmVhazsNCj4+ICsgICAgICAg ICAgICB9DQo+PiArDQo+PiArICAgICAgICAgICAgY3Vyci0+ZG9tYWluX2lkID0gZC0+ZG9tYWlu X2lkOw0KPj4gKyAgICAgICAgICAgIHJldCA9IGN1cnI7DQo+PiArICAgICAgICAgICAgYnJlYWs7 DQo+PiArICAgICAgICB9DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgc3Bpbl91bmxvY2soJnNj bWlfZGF0YS5jaGFubmVsX2xpc3RfbG9jayk7DQo+PiArDQo+PiArICAgIHJldHVybiByZXQ7DQo+ PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyB2b2lkIHJlbGlucXVpc2hfc2NtaV9jaGFubmVsKHN0cnVj dCBzY21pX2NoYW5uZWwgKmNoYW5uZWwpDQo+PiArew0KPj4gKyAgICBBU1NFUlQoY2hhbm5lbCAh PSBOVUxMKTsNCj4+ICsNCj4+ICsgICAgc3Bpbl9sb2NrKCZzY21pX2RhdGEuY2hhbm5lbF9saXN0 X2xvY2spOw0KPj4gKyAgICBjaGFubmVsLT5kb21haW5faWQgPSBET01JRF9JTlZBTElEOw0KPj4g KyAgICBzcGluX3VubG9jaygmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdF9sb2NrKTsNCj4+ICt9DQo+ PiArDQo+PiArc3RhdGljIGludCBtYXBfY2hhbm5lbF9tZW1vcnkoc3RydWN0IHNjbWlfY2hhbm5l bCAqY2hhbm5lbCkNCj4+ICt7DQo+PiArICAgIEFTU0VSVChjaGFubmVsICYmIGNoYW5uZWwtPnBh ZGRyKTsNCj4+ICsgICAgY2hhbm5lbC0+c2htZW0gPSBpb3JlbWFwX25vY2FjaGUoY2hhbm5lbC0+ cGFkZHIsIFNDTUlfU0hNRU1fTUFQUEVEX1NJWkUpOw0KPj4gKyAgICBpZiAoICFjaGFubmVsLT5z aG1lbSApDQo+PiArICAgICAgICByZXR1cm4gLUVOT01FTTsNCj4+ICsNCj4+ICsgICAgY2hhbm5l bC0+c2htZW0tPmNoYW5uZWxfc3RhdHVzID0gU0NNSV9TSE1FTV9DSEFOX1NUQVRfQ0hBTk5FTF9G UkVFOw0KPj4gKyAgICBwcmludGsoWEVOTE9HX0RFQlVHICJzY21pOiBHb3Qgc2htZW0gJWx4IGFm dGVyIHZtYXAgJXBcbiIsIGNoYW5uZWwtPnBhZGRyLA0KPj4gKyAgICAgICAgICAgY2hhbm5lbC0+ c2htZW0pOw0KPj4gKw0KPj4gKyAgICByZXR1cm4gMDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGlj IHZvaWQgdW5tYXBfY2hhbm5lbF9tZW1vcnkoc3RydWN0IHNjbWlfY2hhbm5lbCAqY2hhbm5lbCkN Cj4+ICt7DQo+PiArICAgIEFTU0VSVChjaGFubmVsICYmIGNoYW5uZWwtPnNobWVtKTsNCj4+ICsg ICAgaW91bm1hcChjaGFubmVsLT5zaG1lbSk7DQo+PiArICAgIGNoYW5uZWwtPnNobWVtID0gTlVM TDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIHN0cnVjdCBzY21pX2NoYW5uZWwgKnNtY19jcmVh dGVfY2hhbm5lbCh1aW50MzJfdCBhZ2VudF9pZCwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGZ1bmNfaWQsIHVpbnQ2NF90IGFkZHIp DQo+PiArew0KPj4gKyAgICBzdHJ1Y3Qgc2NtaV9jaGFubmVsICpjaGFubmVsLCAqY3VycjsNCj4+ ICsNCj4+ICsgICAgc3Bpbl9sb2NrKCZzY21pX2RhdGEuY2hhbm5lbF9saXN0X2xvY2spOw0KPj4g Kw0KPj4gKyAgICAvKiBDaGVjayBpZiBjaGFubmVsIGFscmVhZHkgZXhpc3RzIHdoaWxlIGhvbGRp bmcgdGhlIGxvY2sgKi8NCj4+ICsgICAgbGlzdF9mb3JfZWFjaF9lbnRyeShjdXJyLCAmc2NtaV9k YXRhLmNoYW5uZWxfbGlzdCwgbGlzdCkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgaWYgKCBjdXJy LT5hZ2VudF9pZCA9PSBhZ2VudF9pZCApDQo+PiArICAgICAgICB7DQo+PiArICAgICAgICAgICAg c3Bpbl91bmxvY2soJnNjbWlfZGF0YS5jaGFubmVsX2xpc3RfbG9jayk7DQo+PiArICAgICAgICAg ICAgcmV0dXJuIEVSUl9QVFIoLUVFWElTVCk7DQo+PiArICAgICAgICB9DQo+PiArICAgIH0NCj4+ ICsNCj4+ICsgICAgY2hhbm5lbCA9IHhtYWxsb2Moc3RydWN0IHNjbWlfY2hhbm5lbCk7DQo+PiAr ICAgIGlmICggIWNoYW5uZWwgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBzcGluX3VubG9jaygm c2NtaV9kYXRhLmNoYW5uZWxfbGlzdF9sb2NrKTsNCj4+ICsgICAgICAgIHJldHVybiBFUlJfUFRS KC1FTk9NRU0pOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIHNwaW5fbG9ja19pbml0KCZjaGFu bmVsLT5sb2NrKTsNCj4+ICsgICAgY2hhbm5lbC0+YWdlbnRfaWQgPSBhZ2VudF9pZDsNCj4+ICsg ICAgY2hhbm5lbC0+ZnVuY19pZCA9IGZ1bmNfaWQ7DQo+PiArICAgIGNoYW5uZWwtPmRvbWFpbl9p ZCA9IERPTUlEX0lOVkFMSUQ7DQo+PiArICAgIGNoYW5uZWwtPnNobWVtID0gTlVMTDsNCj4+ICsg ICAgY2hhbm5lbC0+cGFkZHIgPSBhZGRyOw0KPj4gKyAgICBsaXN0X2FkZF90YWlsKCZjaGFubmVs LT5saXN0LCAmc2NtaV9kYXRhLmNoYW5uZWxfbGlzdCk7DQo+PiArDQo+PiArICAgIHNwaW5fdW5s b2NrKCZzY21pX2RhdGEuY2hhbm5lbF9saXN0X2xvY2spOw0KPj4gKyAgICByZXR1cm4gY2hhbm5l bDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIHZvaWQgZnJlZV9jaGFubmVsX2xpc3Qodm9pZCkN Cj4+ICt7DQo+PiArICAgIHN0cnVjdCBzY21pX2NoYW5uZWwgKmN1cnIsICpfY3VycjsNCj4+ICsN Cj4+ICsgICAgbGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZlKGN1cnIsIF9jdXJyLCAmc2NtaV9kYXRh LmNoYW5uZWxfbGlzdCwgbGlzdCkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgbGlzdF9kZWwoJmN1 cnItPmxpc3QpOw0KPj4gKyAgICAgICAgeGZyZWUoY3Vycik7DQo+PiArICAgIH0NCj4+ICt9DQo+ PiArDQo+PiArc3RhdGljIGludCBfX2luaXQNCj4+ICtzY21pX2R0X3JlYWRfaHlwX2NoYW5uZWxf YWRkcihzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKnNjbWlfbm9kZSwgdTY0ICphZGRyLA0KPj4gKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHU2NCAqc2l6ZSkNCj4+ICt7DQo+PiArICAgIHN0 cnVjdCBkdF9kZXZpY2Vfbm9kZSAqc2htZW1fbm9kZTsNCj4+ICsgICAgY29uc3QgX19iZTMyICpw cm9wOw0KPj4gKw0KPj4gKyAgICBwcm9wID0gZHRfZ2V0X3Byb3BlcnR5KHNjbWlfbm9kZSwgInNo bWVtIiwgTlVMTCk7DQo+PiArICAgIGlmICggIXByb3AgKQ0KPj4gKyAgICAgICAgcmV0dXJuIC1F SU5WQUw7DQo+PiArDQo+PiArICAgIHNobWVtX25vZGUgPSBkdF9maW5kX25vZGVfYnlfcGhhbmRs ZShiZTMyX3RvX2NwdSgqcHJvcCkpOw0KPj4gKyAgICBpZiAoIElTX0VSUl9PUl9OVUxMKHNobWVt X25vZGUpICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlINCj4+ICsg ICAgICAgICAgICAgICAic2NtaTogRGV2aWNlIHRyZWUgZXJyb3IsIGNhbid0IHBhcnNlIHJlc2Vy dmVkIG1lbW9yeSAlbGRcbiIsDQo+PiArICAgICAgICAgICAgICAgUFRSX0VSUihzaG1lbV9ub2Rl KSk7DQo+PiArICAgICAgICByZXR1cm4gUFRSX0VSUihzaG1lbV9ub2RlKTsNCj4+ICsgICAgfQ0K Pj4gKw0KPj4gKyAgICByZXR1cm4gZHRfZGV2aWNlX2dldF9hZGRyZXNzKHNobWVtX25vZGUsIDAs IGFkZHIsIHNpemUpOw0KPj4gK30NCj4+ICsNCj4+ICsvKg0KPj4gKyAqIEhhbmRsZSBEb20wIFND TUkgc3BlY2lmaWMgRFQgbm9kZXMNCj4+ICsgKg0KPj4gKyAqIE1ha2UgYSBkZWNpc2lvbiBvbiBj b3B5aW5nIFNDTUkgc3BlY2lmaWMgbm9kZXMgaW50byBEb20wIGRldmljZSB0cmVlLg0KPj4gKyAq IEZvciBTQ01JIG11bHRpLWFnZW50IGNhc2U6DQo+PiArICogLSBzaG1lbSBub2RlcyB3aWxsIG5v dCBiZSBjb3BpZWQgYW5kIGdlbmVyYXRlZCBpbnN0ZWFkIGlmIFNDTUkNCj4+ICsgKiAgIGlzIGVu YWJsZWQgZm9yIERvbTANCj4+ICsgKiAtIHNjbWkgbm9kZSB3aWxsIGJlIGNvcGllZCBpZiBTQ01J IGlzIGVuYWJsZWQgZm9yIERvbTANCj4+ICsgKi8NCj4+ICtzdGF0aWMgYm9vbCBzY21pX2R0X2hh bmRsZV9ub2RlKHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqbm9kZSkN Cj4+ICt7DQo+PiArICAgIHN0YXRpYyBjb25zdCBzdHJ1Y3QgZHRfZGV2aWNlX21hdGNoIHNobWVt X21hdGNoZXNbXSBfX2luaXRjb25zdCA9IHsNCj4+ICsgICAgICAgIERUX01BVENIX0NPTVBBVElC TEUoImFybSxzY21pLXNobWVtIiksDQo+PiArICAgICAgICB7IC8qIHNlbnRpbmVsICovIH0sDQo+ PiArICAgIH07DQo+PiArICAgIHN0YXRpYyBjb25zdCBzdHJ1Y3QgZHRfZGV2aWNlX21hdGNoIHNj bWlfbWF0Y2hlc1tdIF9faW5pdGNvbnN0ID0gew0KPj4gKyAgICAgICAgRFRfTUFUQ0hfUEFUSCgi L2Zpcm13YXJlL3NjbWkiKSwNCj4+ICsgICAgICAgIHsgLyogc2VudGluZWwgKi8gfSwNCj4+ICsg ICAgfTsNCj4+ICsNCj4+ICsgICAgaWYgKCAhc2NtaV9kYXRhLmluaXRpYWxpemVkICkNCj4+ICsg ICAgICAgIHJldHVybiBmYWxzZTsNCj4+ICsNCj4+ICsgICAgLyogc2tpcCBzY21pIHNobWVtIG5v ZGUgZm9yIGRvbTAgaWYgc2NtaSBub3QgZW5hYmxlZCAqLw0KPj4gKyAgICBpZiAoIGR0X21hdGNo X25vZGUoc2htZW1fbWF0Y2hlcywgbm9kZSkgJiYgIXNjaV9kb21haW5faXNfZW5hYmxlZChkKSAp DQo+PiArICAgIHsNCj4+ICsgICAgICAgIGR0X2RwcmludGsoIiAgU2tpcCBzY21pIHNobWVtIG5v ZGVcbiIpOw0KPj4gKyAgICAgICAgcmV0dXJuIHRydWU7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsg ICAgLyogZHJvcCBzY21pIGlmIG5vdCBlbmFibGVkICovDQo+PiArICAgIGlmICggZHRfbWF0Y2hf bm9kZShzY21pX21hdGNoZXMsIG5vZGUpICYmICFzY2lfZG9tYWluX2lzX2VuYWJsZWQoZCkgKQ0K Pj4gKyAgICB7DQo+PiArICAgICAgICBkdF9kcHJpbnRrKCIgIFNraXAgc2NtaSBub2RlXG4iKTsN Cj4+ICsgICAgICAgIHJldHVybiB0cnVlOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIHJldHVy biBmYWxzZTsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIGludCBzY21pX2Fzc2lnbl9kZXZpY2Uo dWludDMyX3QgYWdlbnRfaWQsIHVpbnQzMl90IGRldmljZV9pZCwNCj4+ICsgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB1aW50MzJfdCBmbGFncykNCj4+ICt7DQo+PiArICAgIHN0cnVjdCBz Y21pX21zZ19iYXNlX3NldF9kZXZpY2VfcGVybWlzc2lvbnNfYTJwIHR4Ow0KPj4gKyAgICBzdHJ1 Y3Qgc2NtaV9jaGFubmVsICpjaGFubmVsOw0KPj4gKyAgICBzY21pX21zZ19oZWFkZXJfdCBoZHI7 DQo+PiArDQo+PiArICAgIGNoYW5uZWwgPSBnZXRfY2hhbm5lbF9ieV9pZChzY21pX2RhdGEuaHlw X2NoYW5uZWxfYWdlbnRfaWQpOw0KPj4gKyAgICBpZiAoICFjaGFubmVsICkNCj4+ICsgICAgICAg IHJldHVybiAtRUlOVkFMOw0KPj4gKw0KPj4gKyAgICBoZHIuaWQgPSBTQ01JX0JBU0VfU0VUX0RF VklDRV9QRVJNSVNTSU9OUzsNCj4+ICsgICAgaGRyLnR5cGUgPSAwOw0KPj4gKyAgICBoZHIucHJv dG9jb2wgPSBTQ01JX0JBU0VfUFJPVE9DT0w7DQo+PiArDQo+PiArICAgIHR4LmFnZW50X2lkID0g YWdlbnRfaWQ7DQo+PiArICAgIHR4LmRldmljZV9pZCA9IGRldmljZV9pZDsNCj4+ICsgICAgdHgu ZmxhZ3MgPSBmbGFnczsNCj4+ICsNCj4+ICsgICAgcmV0dXJuIGRvX3NtY194ZmVyKGNoYW5uZWws ICZoZHIsICZ0eCwgc2l6ZW9mKHR4KSwgTlVMTCwgMCk7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRp YyBpbnQgc2NtaV9kdF9hc3NpZ25fZGV2aWNlKHN0cnVjdCBkb21haW4gKmQsDQo+PiArICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGR0X3BoYW5kbGVfYXJncyAqYWNfc3Bl YykNCj4+ICt7DQo+PiArICAgIHN0cnVjdCBzY21pX2NoYW5uZWwgKmFnZW50X2NoYW5uZWw7DQo+ PiArICAgIHVpbnQzMl90IHNjbWlfZGV2aWNlX2lkID0gYWNfc3BlYy0+YXJnc1swXTsNCj4+ICsg ICAgaW50IHJldDsNCj4+ICsNCj4+ICsgICAgaWYgKCAhZC0+YXJjaC5zY2lfZGF0YSApDQo+PiAr ICAgICAgICByZXR1cm4gMDsNCj4+ICsNCj4+ICsgICAgLyogVGhlIGFjY2Vzcy1jb250cm9sbGVy cyBpcyBzcGVjaWZpZWQgZm9yIERUIGRldiwgYnV0IGl0J3Mgbm90IGEgU0NNSSAqLw0KPj4gKyAg ICBpZiAoIGFjX3NwZWMtPm5wICE9IHNjbWlfZGF0YS5kdF9kZXYgKQ0KPj4gKyAgICAgICAgcmV0 dXJuIDA7DQo+PiArDQo+PiArICAgIGFnZW50X2NoYW5uZWwgPSBkLT5hcmNoLnNjaV9kYXRhOw0K Pj4gKw0KPj4gKyAgICBzcGluX2xvY2soJmFnZW50X2NoYW5uZWwtPmxvY2spOw0KPj4gKw0KPj4g KyAgICByZXQgPSBzY21pX2Fzc2lnbl9kZXZpY2UoYWdlbnRfY2hhbm5lbC0+YWdlbnRfaWQsIHNj bWlfZGV2aWNlX2lkLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU0NNSV9CQVNF X0RFVklDRV9BQ0NFU1NfQUxMT1cpOw0KPj4gKyAgICBpZiAoIHJldCApDQo+PiArICAgIHsNCj4+ ICsgICAgICAgIHByaW50ayhYRU5MT0dfRVJSDQo+PiArICAgICAgICAgICAgICAgInNjbWk6IGNv dWxkIG5vdCBhc3NpZ24gZGV2IGZvciAlcGQgYWdlbnQ6JWQgZGV2X2lkOiV1ICglZCkiLA0KPj4g KyAgICAgICAgICAgICAgIGQsIGFnZW50X2NoYW5uZWwtPmFnZW50X2lkLCBzY21pX2RldmljZV9p ZCwgcmV0KTsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBzcGluX3VubG9jaygmYWdlbnRfY2hh bm5lbC0+bG9jayk7DQo+PiArICAgIHJldHVybiByZXQ7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRp YyBpbnQgY29sbGVjdF9hZ2VudF9pZChzdHJ1Y3Qgc2NtaV9jaGFubmVsICphZ2VudF9jaGFubmVs KQ0KPj4gK3sNCj4+ICsgICAgaW50IHJldDsNCj4+ICsgICAgc2NtaV9tc2dfaGVhZGVyX3QgaGRy Ow0KPj4gKyAgICBzdHJ1Y3Qgc2NtaV9tc2dfYmFzZV9kaXNjb3Zlcl9hZ2VudF9wMmEgZGFfcng7 DQo+PiArICAgIHN0cnVjdCBzY21pX21zZ19iYXNlX2Rpc2NvdmVyX2FnZW50X2EycCBkYV90eDsN Cj4+ICsNCj4+ICsgICAgcmV0ID0gbWFwX2NoYW5uZWxfbWVtb3J5KGFnZW50X2NoYW5uZWwpOw0K Pj4gKyAgICBpZiAoIHJldCApDQo+PiArICAgICAgICByZXR1cm4gcmV0Ow0KPj4gKw0KPj4gKyAg ICBoZHIuaWQgPSBTQ01JX0JBU0VfRElTQ09WRVJfQUdFTlQ7DQo+PiArICAgIGhkci50eXBlID0g MDsNCj4+ICsgICAgaGRyLnByb3RvY29sID0gU0NNSV9CQVNFX1BST1RPQ09MOw0KPj4gKw0KPj4g KyAgICBkYV90eC5hZ2VudF9pZCA9IGFnZW50X2NoYW5uZWwtPmFnZW50X2lkOw0KPj4gKw0KPj4g KyAgICByZXQgPSBkb19zbWNfeGZlcihhZ2VudF9jaGFubmVsLCAmaGRyLCAmZGFfdHgsIHNpemVv ZihkYV90eCksICZkYV9yeCwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICBzaXplb2YoZGFf cngpKTsNCj4+ICsgICAgaWYgKCBhZ2VudF9jaGFubmVsLT5kb21haW5faWQgIT0gRE9NSURfWEVO ICkNCj4+ICsgICAgICAgIHVubWFwX2NoYW5uZWxfbWVtb3J5KGFnZW50X2NoYW5uZWwpOw0KPj4g KyAgICBpZiAoIHJldCApDQo+PiArICAgICAgICByZXR1cm4gcmV0Ow0KPj4gKw0KPj4gKyAgICBw cmludGsoWEVOTE9HX0RFQlVHICJpZD0weCV4IG5hbWU9JXNcbiIsIGRhX3J4LmFnZW50X2lkLCBk YV9yeC5uYW1lKTsNCj4+ICsgICAgYWdlbnRfY2hhbm5lbC0+YWdlbnRfaWQgPSBkYV9yeC5hZ2Vu dF9pZDsNCj4+ICsgICAgcmV0dXJuIDA7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBfX2luaXQg aW50IGNvbGxlY3RfYWdlbnRzKHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqc2NtaV9ub2RlKQ0KPj4g K3sNCj4+ICsgICAgY29uc3Qgc3RydWN0IGR0X2RldmljZV9ub2RlICpjb25maWdfbm9kZTsNCj4+ ICsgICAgY29uc3QgX19iZTMyICpwcm9wOw0KPj4gKyAgICB1aW50MzJfdCBsZW47DQo+PiArICAg IGNvbnN0IF9fYmUzMiAqZW5kOw0KPj4gKyAgICB1aW50MzJfdCBjZWxsc19wZXJfZW50cnkgPSAz OyAvKiBEZWZhdWx0IHRvIDMgY2VsbHMgaWYgcHJvcGVydHkgaXMgYWJzZW50LiAqLw0KPj4gKw0K Pj4gKyAgICBjb25maWdfbm9kZSA9IGR0X2ZpbmRfY29tcGF0aWJsZV9ub2RlKE5VTEwsIE5VTEws ICJ4ZW4sc2NpIik7DQo+PiArICAgIGlmICggIWNvbmZpZ19ub2RlICkNCj4+ICsgICAgew0KPj4g KyAgICAgICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HICJzY21pOiB4ZW4sc2NpIG5vZGUgbm90IGZv dW5kLCBubyBhZ2VudHMgdG8gY29sbGVjdC5cbiIpOw0KPj4gKyAgICAgICAgcmV0dXJuIC1FTk9F TlQ7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgLyogQ2hlY2sgZm9yIHRoZSBvcHRpb25hbCAn I3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxscycgcHJvcGVydHkuICovDQo+PiArICAgIGlmICgg ZHRfcHJvcGVydHlfcmVhZF91MzIoY29uZmlnX25vZGUsICIjc2NtaS1zZWNvbmRhcnktYWdlbnRz LWNlbGxzIiwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmY2VsbHNfcGVyX2Vu dHJ5KSApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIGlmICggY2VsbHNfcGVyX2VudHJ5ICE9IDIg JiYgY2VsbHNfcGVyX2VudHJ5ICE9IDMgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAgICAg IHByaW50ayhYRU5MT0dfRVJSICJzY21pOiBJbnZhbGlkICNzY21pLXNlY29uZGFyeS1hZ2VudHMt Y2VsbHMgdmFsdWU6ICV1XG4iLA0KPj4gKyAgICAgICAgICAgICAgICAgICBjZWxsc19wZXJfZW50 cnkpOw0KPj4gKyAgICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gKyAgICAgICAgfQ0KPj4g KyAgICB9DQo+PiArDQo+PiArICAgIHByb3AgPSBkdF9nZXRfcHJvcGVydHkoY29uZmlnX25vZGUs IFNDTUlfU0VDT05EQVJZX0FHRU5UUywgJmxlbik7DQo+PiArICAgIGlmICggIXByb3AgKQ0KPj4g KyAgICB7DQo+PiArICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAic2NtaTogTm8gJXMgcHJvcGVy dHkgZm91bmQsIG5vIGFnZW50cyB0byBjb2xsZWN0LlxuIiwNCj4+ICsgICAgICAgICAgICAgICBT Q01JX1NFQ09OREFSWV9BR0VOVFMpOw0KPj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiAr ICAgIH0NCj4+ICsNCj4+ICsgICAgLyogVmFsaWRhdGUgdGhhdCB0aGUgcHJvcGVydHkgbGVuZ3Ro IGlzIGEgbXVsdGlwbGUgb2YgdGhlIGNlbGwgc2l6ZS4gKi8NCj4+ICsgICAgaWYgKCBsZW4gPT0g MCB8fCBsZW4gJSAoY2VsbHNfcGVyX2VudHJ5ICogc2l6ZW9mKHVpbnQzMl90KSkgIT0gMCApDQo+ PiArICAgIHsNCj4+ICsgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJzY21pOiBJbnZhbGlkIGxl bmd0aCBvZiAlcyBwcm9wZXJ0eTogJXUgZm9yICV1IGNlbGxzIHBlciBlbnRyeVxuIiwNCj4+ICsg ICAgICAgICAgICAgICBTQ01JX1NFQ09OREFSWV9BR0VOVFMsIGxlbiwgY2VsbHNfcGVyX2VudHJ5 KTsNCj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAg IGVuZCA9IChjb25zdCBfX2JlMzIgKikoKGNvbnN0IHU4ICopcHJvcCArIGxlbik7DQo+PiArDQo+ PiArICAgIGZvciAoIDsgcHJvcCA8IGVuZDsgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICB1aW50 MzJfdCBhZ2VudF9pZDsNCj4+ICsgICAgICAgIHVpbnQzMl90IHNtY19pZDsNCj4+ICsgICAgICAg IHVpbnQzMl90IHNobWVtX3BoYW5kbGU7DQo+PiArICAgICAgICBzdHJ1Y3QgZHRfZGV2aWNlX25v ZGUgKm5vZGU7DQo+PiArICAgICAgICB1NjQgYWRkciwgc2l6ZTsNCj4+ICsgICAgICAgIGludCBy ZXQ7DQo+PiArICAgICAgICBzdHJ1Y3Qgc2NtaV9jaGFubmVsICphZ2VudF9jaGFubmVsOw0KPj4g Kw0KPj4gKyAgICAgICAgc21jX2lkID0gYmUzMl90b19jcHUoKnByb3ArKyk7DQo+PiArICAgICAg ICBzaG1lbV9waGFuZGxlID0gYmUzMl90b19jcHUoKnByb3ArKyk7DQo+PiArDQo+PiArICAgICAg ICBpZiAoIGNlbGxzX3Blcl9lbnRyeSA9PSAzICkNCj4+ICsgICAgICAgICAgICBhZ2VudF9pZCA9 IGJlMzJfdG9fY3B1KCpwcm9wKyspOw0KPj4gKyAgICAgICAgZWxzZQ0KPj4gKyAgICAgICAgICAg IGFnZW50X2lkID0gU0NNSV9CQVNFX0FHRU5UX0lEX09XTjsNCj4+ICsNCj4+ICsgICAgICAgIG5v ZGUgPSBkdF9maW5kX25vZGVfYnlfcGhhbmRsZShzaG1lbV9waGFuZGxlKTsNCj4+ICsgICAgICAg IGlmICggIW5vZGUgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAgICAgIHByaW50ayhYRU5M T0dfRVJSICJzY21pOiBDb3VsZCBub3QgZmluZCBzaG1lbSBub2RlIGZvciBhZ2VudCAldVxuIiwN Cj4+ICsgICAgICAgICAgICAgICAgICAgYWdlbnRfaWQpOw0KPj4gKyAgICAgICAgICAgIHJldHVy biAtRUlOVkFMOw0KPj4gKyAgICAgICAgfQ0KPj4gKw0KPj4gKyAgICAgICAgcmV0ID0gZHRfZGV2 aWNlX2dldF9hZGRyZXNzKG5vZGUsIDAsICZhZGRyLCAmc2l6ZSk7DQo+PiArICAgICAgICBpZiAo IHJldCApDQo+PiArICAgICAgICB7DQo+PiArICAgICAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIN Cj4+ICsgICAgICAgICAgICAgICAgICAgInNjbWk6IENvdWxkIG5vdCByZWFkIHNobWVtIGFkZHJl c3MgZm9yIGFnZW50ICV1OiAlZFxuIiwNCj4+ICsgICAgICAgICAgICAgICAgICAgYWdlbnRfaWQs IHJldCk7DQo+PiArICAgICAgICAgICAgcmV0dXJuIHJldDsNCj4+ICsgICAgICAgIH0NCj4+ICsN Cj4+ICsgICAgICAgIGlmICggIUlTX0FMSUdORUQoc2l6ZSwgU0NNSV9TSE1FTV9NQVBQRURfU0la RSkgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJz Y21pOiBzaG1lbSBtZW1vcnkgaXMgbm90IGFsaWduZWRcbiIpOw0KPj4gKyAgICAgICAgICAgIHJl dHVybiAtRUlOVkFMOw0KPj4gKyAgICAgICAgfQ0KPj4gKw0KPj4gKyAgICAgICAgYWdlbnRfY2hh bm5lbCA9IHNtY19jcmVhdGVfY2hhbm5lbChhZ2VudF9pZCwgc21jX2lkLCBhZGRyKTsNCj4+ICsg ICAgICAgIGlmICggSVNfRVJSKGFnZW50X2NoYW5uZWwpICkNCj4+ICsgICAgICAgIHsNCj4+ICsg ICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAic2NtaTogQ291bGQgbm90IGNyZWF0ZSBjaGFu bmVsIGZvciBhZ2VudCAldTogJWxkXG4iLA0KPj4gKyAgICAgICAgICAgICAgICAgICBhZ2VudF9p ZCwgUFRSX0VSUihhZ2VudF9jaGFubmVsKSk7DQo+PiArICAgICAgICAgICAgcmV0dXJuIFBUUl9F UlIoYWdlbnRfY2hhbm5lbCk7DQo+PiArICAgICAgICB9DQo+PiArDQo+PiArICAgICAgICBpZiAo IGNlbGxzX3Blcl9lbnRyeSA9PSAyICkNCj4+ICsgICAgICAgIHsNCj4+ICsgICAgICAgICAgICBy ZXQgPSBjb2xsZWN0X2FnZW50X2lkKGFnZW50X2NoYW5uZWwpOw0KPj4gKyAgICAgICAgICAgIGlm ICggcmV0ICkNCj4+ICsgICAgICAgICAgICAgICAgcmV0dXJuIHJldDsNCj4+ICsgICAgICAgIH0N Cj4gYXJlbid0IHdlIG1pc3NpbmcgYSBjYWxsIHRvIG1hcF9jaGFubmVsX21lbW9yeSBpbiB0aGUg b3RoZXIgY2FzZT8NCg0KSSdtIG5vdCBzdXJlIGlmIEkgZnVsbHkgdW5kZXJzdG9vZCB5b3VyIHF1 ZXN0aW9uLCBidXQgaWYgeW91IGFyZSByZWZlcnJpbmcNCnRvIHRoZSBjYXNlIHdoZXJlIGNlbGxz X3Blcl9lbnRyeSA9IDMsIHdlIGFzc3VtZSB0aGF0IHRoZSBwcm92aWRlZCBjb25maWd1cmF0aW9u DQppcyBjb3JyZWN0IGFuZCB0aGVyZSBpcyBubyBuZWVkIHRvIHJlcXVlc3QgdGhlIGFnZW50X2lk LiBUaGlzIGFwcHJvYWNoIGlzIHBhcnRpY3VsYXJseQ0KdXNlZnVsIGluIHNjZW5hcmlvcyB3aGVy ZSBYZW4gY2Fubm90IGFjY2VzcyBvdGhlciBjaGFubmVscy4NCg0KPg0KPj4gKw0KPj4gKyAgICAg ICAgcHJpbnRrKFhFTkxPR19ERUJVRyAic2NtaTogQWdlbnQgJXUgU01DICVYIGFkZHIgJWx4XG4i LCBhZ2VudF9jaGFubmVsLT5hZ2VudF9pZCwNCj4+ICsgICAgICAgICAgICAgICBzbWNfaWQsICh1 bnNpZ25lZCBsb25nKWFkZHIpOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIHJldHVybiAwOw0K Pj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgaW50IHNjbWlfZG9tYWluX2luaXQoc3RydWN0IGRvbWFp biAqZCwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxf Y3JlYXRlZG9tYWluICpjb25maWcpDQo+PiArew0KPj4gKyAgICBzdHJ1Y3Qgc2NtaV9jaGFubmVs ICpjaGFubmVsOw0KPj4gKyAgICBpbnQgcmV0Ow0KPj4gKw0KPj4gKyAgICBpZiAoICFzY21pX2Rh dGEuaW5pdGlhbGl6ZWQgKQ0KPj4gKyAgICAgICAgcmV0dXJuIDA7DQo+PiArDQo+PiArICAgIC8q DQo+PiArICAgICAqIFNDTUkgc3VwcG9ydCBpcyBjb25maWd1cmVkIHZpYToNCj4+ICsgICAgICog LSBGb3IgZG9tMDogZG9tMD1zY2ktYWdlbnQtaWQ9PHZhbHVlPiBpbiBYZW4gY29tbWFuZCBsaW5l DQo+PiArICAgICAqIC0gRm9yIGRvbTBsZXNzOiB4ZW4sc2NpLWFnZW50LWlkIGluIGRldmljZSB0 cmVlDQo+PiArICAgICAqIFRoZSBjb25maWctPmFyY2guYXJtX3NjaV90eXBlIGFuZCBjb25maWct PmFyY2guYXJtX3NjaV9hZ2VudF9pZA0KPj4gKyAgICAgKiBhcmUgYWxyZWFkeSBzZXQgYnkgZG9t YWluX2J1aWxkLmMgb3IgZG9tMGxlc3MtYnVpbGQuYw0KPj4gKyAgICAgKi8NCj4+ICsNCj4+ICsg ICAgaWYgKCBjb25maWctPmFyY2guYXJtX3NjaV90eXBlID09IFhFTl9ET01DVExfQ09ORklHX0FS TV9TQ0lfTk9ORSApDQo+PiArICAgICAgICByZXR1cm4gMDsNCj4+ICsNCj4+ICsgICAgY2hhbm5l bCA9IGFjcXVpcmVfc2NtaV9jaGFubmVsKGQsIGNvbmZpZy0+YXJjaC5hcm1fc2NpX2FnZW50X2lk KTsNCj4+ICsgICAgaWYgKCBJU19FUlIoY2hhbm5lbCkgKQ0KPj4gKyAgICB7DQo+PiArICAgICAg ICBwcmludGsoWEVOTE9HX0VSUg0KPj4gKyAgICAgICAgICAgICAgICJzY21pOiBGYWlsZWQgdG8g YWNxdWlyZSBTQ01JIGNoYW5uZWwgZm9yIGFnZW50X2lkICV1OiAlbGRcbiIsDQo+PiArICAgICAg ICAgICAgICAgY29uZmlnLT5hcmNoLmFybV9zY2lfYWdlbnRfaWQsIFBUUl9FUlIoY2hhbm5lbCkp Ow0KPj4gKyAgICAgICAgcmV0dXJuIFBUUl9FUlIoY2hhbm5lbCk7DQo+PiArICAgIH0NCj4+ICsN Cj4+ICsgICAgcHJpbnRrKFhFTkxPR19JTkZPDQo+PiArICAgICAgICAgICAic2NtaTogQWNxdWly ZSBjaGFubmVsIGlkID0gMHgleCwgZG9tYWluX2lkID0gJWQgcGFkZHIgPSAweCVseFxuIiwNCj4+ ICsgICAgICAgICAgIGNoYW5uZWwtPmFnZW50X2lkLCBjaGFubmVsLT5kb21haW5faWQsIGNoYW5u ZWwtPnBhZGRyKTsNCj4+ICsNCj4+ICsgICAgLyoNCj4+ICsgICAgICogRG9tMCAoaWYgcHJlc2Vu dCkgbmVlZHMgdG8gaGF2ZSBhbiBhY2Nlc3MgdG8gdGhlIGd1ZXN0IG1lbW9yeSByYW5nZQ0KPj4g KyAgICAgKiB0byBzYXRpc2Z5IGlvbWVtX2FjY2Vzc19wZXJtaXR0ZWQoKSBjaGVjayBpbiBYRU5f RE9NQ1RMX2lvbWVtX3Blcm1pc3Npb24NCj4+ICsgICAgICogZG9tY3RsLg0KPj4gKyAgICAgKi8N Cj4+ICsgICAgaWYgKCBoYXJkd2FyZV9kb21haW4gJiYgIWlzX2hhcmR3YXJlX2RvbWFpbihkKSAp DQo+PiArICAgIHsNCj4+ICsgICAgICAgIHJldCA9IGlvbWVtX3Blcm1pdF9hY2Nlc3MoaGFyZHdh cmVfZG9tYWluLCBwYWRkcl90b19wZm4oY2hhbm5lbC0+cGFkZHIpLA0KPj4gKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBwYWRkcl90b19wZm4oY2hhbm5lbC0+cGFkZHIgKyBQQUdF X1NJWkUgLSAxKSk7DQo+PiArICAgICAgICBpZiAoIHJldCApDQo+PiArICAgICAgICAgICAgZ290 byBlcnJvcjsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBkLT5hcmNoLnNjaV9kYXRhID0gY2hh bm5lbDsNCj4+ICsgICAgZC0+YXJjaC5zY2lfZW5hYmxlZCA9IHRydWU7DQo+PiArDQo+PiArICAg IHJldHVybiAwOw0KPj4gKw0KPj4gK2Vycm9yOg0KPj4gKyAgICByZWxpbnF1aXNoX3NjbWlfY2hh bm5lbChjaGFubmVsKTsNCj4+ICsgICAgcmV0dXJuIHJldDsNCj4+ICt9DQo+PiArDQo+PiAraW50 IHNjbWlfZG9tYWluX3Nhbml0aXNlX2NvbmZpZyhzdHJ1Y3QgeGVuX2RvbWN0bF9jcmVhdGVkb21h aW4gKmNvbmZpZykNCj4+ICt7DQo+PiArICAgIGlmICggY29uZmlnLT5hcmNoLmFybV9zY2lfdHlw ZSAhPSBYRU5fRE9NQ1RMX0NPTkZJR19BUk1fU0NJX05PTkUgJiYNCj4+ICsgICAgICAgICBjb25m aWctPmFyY2guYXJtX3NjaV90eXBlICE9IFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfU0NNSV9T TUNfTUEgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBkcHJpbnRrKFhFTkxPR19JTkZPLCAic2Nt aTogVW5zdXBwb3J0ZWQgQVJNX1NDSSB0eXBlXG4iKTsNCj4+ICsgICAgICAgIHJldHVybiAtRUlO VkFMOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIHJldHVybiAwOw0KPj4gK30NCj4+ICsNCj4+ ICtzdGF0aWMgaW50IHNjbWlfcmVsaW5xdWlzaF9yZXNvdXJjZXMoc3RydWN0IGRvbWFpbiAqZCkN Cj4+ICt7DQo+PiArICAgIGludCByZXQ7DQo+PiArICAgIHN0cnVjdCBzY21pX2NoYW5uZWwgKmNo YW5uZWwsICphZ2VudF9jaGFubmVsOw0KPj4gKyAgICBzY21pX21zZ19oZWFkZXJfdCBoZHI7DQo+ PiArICAgIHN0cnVjdCBzY21pX21zZ19iYXNlX3Jlc2V0X2FnZW50X2NmZ19hMnAgdHg7DQo+PiAr DQo+PiArICAgIGlmICggIWQtPmFyY2guc2NpX2RhdGEgKQ0KPj4gKyAgICAgICAgcmV0dXJuIDA7 DQo+PiArDQo+PiArICAgIGFnZW50X2NoYW5uZWwgPSBkLT5hcmNoLnNjaV9kYXRhOw0KPj4gKw0K Pj4gKyAgICBzcGluX2xvY2soJmFnZW50X2NoYW5uZWwtPmxvY2spOw0KPj4gKyAgICB0eC5hZ2Vu dF9pZCA9IGFnZW50X2NoYW5uZWwtPmFnZW50X2lkOw0KPj4gKyAgICBzcGluX3VubG9jaygmYWdl bnRfY2hhbm5lbC0+bG9jayk7DQo+PiArDQo+PiArICAgIGNoYW5uZWwgPSBnZXRfY2hhbm5lbF9i eV9pZChzY21pX2RhdGEuaHlwX2NoYW5uZWxfYWdlbnRfaWQpOw0KPj4gKyAgICBpZiAoICFjaGFu bmVsICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlINCj4+ICsgICAg ICAgICAgICAgICAic2NtaTogVW5hYmxlIHRvIGdldCBIeXBlcnZpc29yIHNjbWkgY2hhbm5lbCBm b3IgZG9tYWluICVkXG4iLA0KPj4gKyAgICAgICAgICAgICAgIGQtPmRvbWFpbl9pZCk7DQo+PiAr ICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBoZHIuaWQg PSBTQ01JX0JBU0VfUkVTRVRfQUdFTlRfQ09ORklHVVJBVElPTjsNCj4+ICsgICAgaGRyLnR5cGUg PSAwOw0KPj4gKyAgICBoZHIucHJvdG9jb2wgPSBTQ01JX0JBU0VfUFJPVE9DT0w7DQo+PiArDQo+ PiArICAgIHR4LmZsYWdzID0gMDsNCj4+ICsNCj4+ICsgICAgcmV0ID0gZG9fc21jX3hmZXIoY2hh bm5lbCwgJmhkciwgJnR4LCBzaXplb2YodHgpLCBOVUxMLCAwKTsNCj4+ICsgICAgaWYgKCByZXQg PT0gLUVPUE5PVFNVUFAgKQ0KPj4gKyAgICAgICAgcmV0dXJuIDA7DQo+PiArDQo+PiArICAgIHJl dHVybiByZXQ7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyB2b2lkIHNjbWlfZG9tYWluX2Rlc3Ry b3koc3RydWN0IGRvbWFpbiAqZCkNCj4+ICt7DQo+PiArICAgIHN0cnVjdCBzY21pX2NoYW5uZWwg KmNoYW5uZWw7DQo+PiArDQo+PiArICAgIGlmICggIWQtPmFyY2guc2NpX2RhdGEgKQ0KPj4gKyAg ICAgICAgcmV0dXJuOw0KPj4gKw0KPj4gKyAgICBjaGFubmVsID0gZC0+YXJjaC5zY2lfZGF0YTsN Cj4+ICsgICAgc3Bpbl9sb2NrKCZjaGFubmVsLT5sb2NrKTsNCj4+ICsNCj4+ICsgICAgcmVsaW5x dWlzaF9zY21pX2NoYW5uZWwoY2hhbm5lbCk7DQo+PiArICAgIHByaW50ayhYRU5MT0dfREVCVUcg InNjbWk6IEZyZWUgZG9tYWluICVkXG4iLCBkLT5kb21haW5faWQpOw0KPj4gKw0KPj4gKyAgICBk LT5hcmNoLnNjaV9kYXRhID0gTlVMTDsNCj4+ICsgICAgZC0+YXJjaC5zY2lfZW5hYmxlZCA9IGZh bHNlOw0KPj4gKw0KPj4gKyAgICBzcGluX3VubG9jaygmY2hhbm5lbC0+bG9jayk7DQo+PiArfQ0K Pj4gKw0KPj4gK3N0YXRpYyBib29sIHNjbWlfaGFuZGxlX2NhbGwoc3RydWN0IGNwdV91c2VyX3Jl Z3MgKnJlZ3MpDQo+PiArew0KPj4gKyAgICB1aW50MzJfdCBmaWQgPSAodWludDMyX3QpZ2V0X3Vz ZXJfcmVnKHJlZ3MsIDApOw0KPj4gKyAgICBzdHJ1Y3Qgc2NtaV9jaGFubmVsICphZ2VudF9jaGFu bmVsOw0KPj4gKyAgICBzdHJ1Y3QgZG9tYWluICpkID0gY3VycmVudC0+ZG9tYWluOw0KPj4gKyAg ICBzdHJ1Y3QgYXJtX3NtY2NjX3JlcyByZXNwOw0KPj4gKyAgICBib29sIHJlcyA9IGZhbHNlOw0K Pj4gKw0KPj4gKyAgICBpZiAoICFzY2lfZG9tYWluX2lzX2VuYWJsZWQoZCkgKQ0KPj4gKyAgICAg ICAgcmV0dXJuIGZhbHNlOw0KPj4gKw0KPj4gKyAgICBhZ2VudF9jaGFubmVsID0gZC0+YXJjaC5z Y2lfZGF0YTsNCj4+ICsgICAgc3Bpbl9sb2NrKCZhZ2VudF9jaGFubmVsLT5sb2NrKTsNCj4+ICsN Cj4+ICsgICAgaWYgKCBhZ2VudF9jaGFubmVsLT5mdW5jX2lkICE9IGZpZCApDQo+PiArICAgIHsN Cj4+ICsgICAgICAgIHJlcyA9IGZhbHNlOw0KPj4gKyAgICAgICAgZ290byB1bmxvY2s7DQo+PiAr ICAgIH0NCj4+ICsNCj4+ICsgICAgYXJtX3NtY2NjXzFfMV9zbWMoZmlkLA0KPj4gKyAgICAgICAg ICAgICAgICAgICAgICBnZXRfdXNlcl9yZWcocmVncywgMSksDQo+PiArICAgICAgICAgICAgICAg ICAgICAgIGdldF91c2VyX3JlZyhyZWdzLCAyKSwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAg Z2V0X3VzZXJfcmVnKHJlZ3MsIDMpLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICBnZXRfdXNl cl9yZWcocmVncywgNCksDQo+PiArICAgICAgICAgICAgICAgICAgICAgIGdldF91c2VyX3JlZyhy ZWdzLCA1KSwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgZ2V0X3VzZXJfcmVnKHJlZ3MsIDYp LA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICBnZXRfdXNlcl9yZWcocmVncywgNyksDQo+PiAr ICAgICAgICAgICAgICAgICAgICAgICZyZXNwKTsNCj4+ICsNCj4+ICsgICAgc2V0X3VzZXJfcmVn KHJlZ3MsIDAsIHJlc3AuYTApOw0KPj4gKyAgICBzZXRfdXNlcl9yZWcocmVncywgMSwgcmVzcC5h MSk7DQo+PiArICAgIHNldF91c2VyX3JlZyhyZWdzLCAyLCByZXNwLmEyKTsNCj4+ICsgICAgc2V0 X3VzZXJfcmVnKHJlZ3MsIDMsIHJlc3AuYTMpOw0KPj4gKyAgICByZXMgPSB0cnVlOw0KPj4gK3Vu bG9jazoNCj4+ICsgICAgc3Bpbl91bmxvY2soJmFnZW50X2NoYW5uZWwtPmxvY2spOw0KPj4gKw0K Pj4gKyAgICByZXR1cm4gcmVzOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgY29uc3Qgc3RydWN0 IHNjaV9tZWRpYXRvcl9vcHMgc2NtaV9vcHMgPSB7DQo+PiArICAgIC5kb21haW5faW5pdCA9IHNj bWlfZG9tYWluX2luaXQsDQo+PiArICAgIC5kb21haW5fZGVzdHJveSA9IHNjbWlfZG9tYWluX2Rl c3Ryb3ksDQo+PiArICAgIC5yZWxpbnF1aXNoX3Jlc291cmNlcyA9IHNjbWlfcmVsaW5xdWlzaF9y ZXNvdXJjZXMsDQo+PiArICAgIC5oYW5kbGVfY2FsbCA9IHNjbWlfaGFuZGxlX2NhbGwsDQo+PiAr ICAgIC5kb20wX2R0X2hhbmRsZV9ub2RlID0gc2NtaV9kdF9oYW5kbGVfbm9kZSwNCj4+ICsgICAg LmRvbWFpbl9zYW5pdGlzZV9jb25maWcgPSBzY21pX2RvbWFpbl9zYW5pdGlzZV9jb25maWcsDQo+ PiArICAgIC5hc3NpZ25fZHRfZGV2aWNlID0gc2NtaV9kdF9hc3NpZ25fZGV2aWNlLA0KPj4gK307 DQo+PiArDQo+PiArc3RhdGljIGludCBfX2luaXQgc2NtaV9jaGVja19zbWNjY192ZXIodm9pZCkN Cj4+ICt7DQo+PiArICAgIGlmICggc21jY2NfdmVyIDwgQVJNX1NNQ0NDX1ZFUlNJT05fMV8xICkN Cj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HDQo+PiArICAgICAg ICAgICAgICAgInNjbWk6IE5vIFNNQ0NDIDEuMSBzdXBwb3J0LCBTQ01JIGNhbGxzIGZvcndhcmRp bmcgZGlzYWJsZWRcbiIpOw0KPj4gKyAgICAgICAgcmV0dXJuIC1FTk9TWVM7DQo+PiArICAgIH0N Cj4+ICsNCj4+ICsgICAgcmV0dXJuIDA7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBpbnQgX19p bml0IHNjbWlfZHRfaHlwX2NoYW5uZWxfcmVhZChzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKnNjbWlf bm9kZSwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3Ry dWN0IHNjbWlfZGF0YSAqc2NtaV9kYXRhLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB1NjQgKmFkZHIpDQo+PiArew0KPj4gKyAgICBpbnQgcmV0Ow0KPj4g KyAgICB1NjQgc2l6ZTsNCj4+ICsNCj4+ICsgICAgaWYgKCAhZHRfcHJvcGVydHlfcmVhZF91MzIo c2NtaV9ub2RlLCAiYXJtLHNtYy1pZCIsICZzY21pX2RhdGEtPmZ1bmNfaWQpICkNCj4+ICsgICAg ew0KPj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgInNjbWk6IHVuYWJsZSB0byByZWFkIHNt Yy1pZCBmcm9tIERUXG4iKTsNCj4+ICsgICAgICAgIHJldHVybiAtRU5PRU5UOw0KPj4gKyAgICB9 DQo+PiArDQo+PiArICAgIHJldCA9IHNjbWlfZHRfcmVhZF9oeXBfY2hhbm5lbF9hZGRyKHNjbWlf bm9kZSwgYWRkciwgJnNpemUpOw0KPj4gKyAgICBpZiAoIElTX0VSUl9WQUxVRShyZXQpICkNCj4+ ICsgICAgICAgIHJldHVybiAtRU5PRU5UOw0KPj4gKw0KPj4gKyAgICBpZiAoICFJU19BTElHTkVE KHNpemUsIFNDTUlfU0hNRU1fTUFQUEVEX1NJWkUpICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAg cHJpbnRrKFhFTkxPR19FUlIgInNjbWk6IHNobWVtIG1lbW9yeSBpcyBub3QgYWxpZ25lZFxuIik7 DQo+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBy ZXR1cm4gMDsNCj4+ICt9DQo+PiArDQo+PiArc3RhdGljIF9faW5pdCBpbnQgc2NtaV9wcm9iZShz dHJ1Y3QgZHRfZGV2aWNlX25vZGUgKnNjbWlfbm9kZSwgY29uc3Qgdm9pZCAqZGF0YSkNCj4+ICt7 DQo+PiArICAgIHU2NCBhZGRyOw0KPj4gKyAgICBpbnQgcmV0Ow0KPj4gKyAgICBzdHJ1Y3Qgc2Nt aV9jaGFubmVsICpjaGFubmVsOw0KPj4gKyAgICB1bnNpZ25lZCBpbnQgbl9hZ2VudHM7DQo+PiAr ICAgIHNjbWlfbXNnX2hlYWRlcl90IGhkcjsNCj4+ICsgICAgc3RydWN0IHNjbWlfbXNnX2Jhc2Vf YXR0cmlidXRlc19wMmEgcng7DQo+PiArDQo+PiArICAgIEFTU0VSVChzY21pX25vZGUgIT0gTlVM TCk7DQo+PiArDQo+PiArICAgIC8qDQo+PiArICAgICAqIE9ubHkgYmluZCB0byB0aGUgU0NNSSBu b2RlIHByb3ZpZGVkIGJ5IFhlbiB1bmRlciB0aGUgeGVuLHNjaSBjb250YWluZXINCj4+ICsgICAg ICogKGUuZy4gL2Nob3Nlbi94ZW4veGVuX3NjbWlfY29uZmlnL3NjbWkpLiBUaGlzIGF2b2lkcyBi aW5kaW5nIHRvIGZpcm13YXJlDQo+PiArICAgICAqIFNDTUkgbm9kZXMgdGhhdCBiZWxvbmcgdG8g dGhlIGhvc3QgT1NQTSBhbmQga2VlcHMgdGhlIG1lZGlhdG9yIHNjb3BlZCB0bw0KPj4gKyAgICAg KiBYZW4tcHJvdmlkZWQgY29uZmlndXJhdGlvbiBvbmx5Lg0KPj4gKyAgICAgKi8NCj4+ICsgICAg aWYgKCAhc2NtaV9pc191bmRlcl94ZW5fc2NpKHNjbWlfbm9kZSkgKQ0KPj4gKyAgICAgICAgcmV0 dXJuIC1FTk9ERVY7DQo+PiArDQo+PiArICAgIElOSVRfTElTVF9IRUFEKCZzY21pX2RhdGEuY2hh bm5lbF9saXN0KTsNCj4+ICsgICAgc3Bpbl9sb2NrX2luaXQoJnNjbWlfZGF0YS5jaGFubmVsX2xp c3RfbG9jayk7DQo+PiArDQo+PiArICAgIGlmICggIWFjcGlfZGlzYWJsZWQgKQ0KPj4gKyAgICB7 DQo+PiArICAgICAgICBwcmludGsoWEVOTE9HX1dBUk5JTkcgInNjbWk6IGlzIG5vdCBzdXBwb3J0 ZWQgd2hlbiB1c2luZyBBQ1BJXG4iKTsNCj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4g KyAgICB9DQo+PiArDQo+PiArICAgIHJldCA9IHNjbWlfY2hlY2tfc21jY2NfdmVyKCk7DQo+PiAr ICAgIGlmICggcmV0ICkNCj4+ICsgICAgICAgIHJldHVybiByZXQ7DQo+PiArDQo+PiArICAgIHJl dCA9IHNjbWlfZHRfaHlwX2NoYW5uZWxfcmVhZChzY21pX25vZGUsICZzY21pX2RhdGEsICZhZGRy KTsNCj4+ICsgICAgaWYgKCByZXQgKQ0KPj4gKyAgICAgICAgcmV0dXJuIHJldDsNCj4+ICsNCj4+ ICsgICAgc2NtaV9kYXRhLmR0X2RldiA9IHNjbWlfbm9kZTsNCj4+ICsNCj4+ICsgICAgY2hhbm5l bCA9IHNtY19jcmVhdGVfY2hhbm5lbChTQ01JX0JBU0VfQUdFTlRfSURfT1dOLCBzY21pX2RhdGEu ZnVuY19pZCwgYWRkcik7DQo+PiArICAgIGlmICggSVNfRVJSKGNoYW5uZWwpICkNCj4+ICsgICAg ICAgIGdvdG8gb3V0Ow0KPj4gKw0KPj4gKyAgICAvKiBNYXJrIGFzIFhlbiBtYW5hZ2VtZW50IGNo YW5uZWwgYmVmb3JlIGNvbGxlY3RpbmcgYWdlbnQgSUQgKi8NCj4+ICsgICAgY2hhbm5lbC0+ZG9t YWluX2lkID0gRE9NSURfWEVOOw0KPj4gKw0KPj4gKyAgICAvKiBSZXF1ZXN0IGFnZW50IGlkIGZv ciBYZW4gbWFuYWdlbWVudCBjaGFubmVsICAqLw0KPj4gKyAgICByZXQgPSBjb2xsZWN0X2FnZW50 X2lkKGNoYW5uZWwpOw0KPj4gKyAgICBpZiAoIHJldCApDQo+PiArICAgICAgICBnb3RvIGVycm9y Ow0KPj4gKw0KPj4gKyAgICAvKiBTYXZlIHRoZSBhZ2VudCBpZCBmb3IgWGVuIG1hbmFnZW1lbnQg Y2hhbm5lbCAqLw0KPj4gKyAgICBzY21pX2RhdGEuaHlwX2NoYW5uZWxfYWdlbnRfaWQgPSBjaGFu bmVsLT5hZ2VudF9pZDsNCj4+ICsNCj4+ICsgICAgaGRyLmlkID0gU0NNSV9CQVNFX1BST1RPQ09M X0FUVElCVVRFUzsNCj4+ICsgICAgaGRyLnR5cGUgPSAwOw0KPj4gKyAgICBoZHIucHJvdG9jb2wg PSBTQ01JX0JBU0VfUFJPVE9DT0w7DQo+PiArDQo+PiArICAgIHJldCA9IGRvX3NtY194ZmVyKGNo YW5uZWwsICZoZHIsIE5VTEwsIDAsICZyeCwgc2l6ZW9mKHJ4KSk7DQo+PiArICAgIGlmICggcmV0 ICkNCj4+ICsgICAgICAgIGdvdG8gZXJyb3I7DQo+PiArDQo+PiArICAgIG5fYWdlbnRzID0gU0NN SV9GSUVMRF9HRVQoU0NNSV9CQVNFX0FUVFJfTlVNX0FHRU5ULCByeC5hdHRyaWJ1dGVzKTsNCj4+ ICsgICAgcHJpbnRrKFhFTkxPR19ERUJVRyAic2NtaTogR290IGFnZW50IGNvdW50ICVkXG4iLCBu X2FnZW50cyk7DQo+PiArICAgIHJldCA9IGNvbGxlY3RfYWdlbnRzKHNjbWlfbm9kZSk7DQo+PiAr ICAgIGlmICggcmV0ICkNCj4+ICsgICAgICAgIGdvdG8gZXJyb3I7DQo+PiArDQo+PiArICAgIHJl dCA9IHNjaV9yZWdpc3Rlcigmc2NtaV9vcHMpOw0KPj4gKyAgICBpZiAoIHJldCApDQo+PiArICAg IHsNCj4+ICsgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJTQ01JOiBtZWRpYXRvciBhbHJlYWR5 IHJlZ2lzdGVyZWQgKHJldCA9ICVkKVxuIiwNCj4+ICsgICAgICAgICAgICAgICByZXQpOw0KPj4g KyAgICAgICAgcmV0dXJuIHJldDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBzY21pX2RhdGEu aW5pdGlhbGl6ZWQgPSB0cnVlOw0KPj4gKyAgICBnb3RvIG91dDsNCj4+ICsNCj4+ICtlcnJvcjoN Cj4+ICsgICAgdW5tYXBfY2hhbm5lbF9tZW1vcnkoY2hhbm5lbCk7DQo+PiArICAgIGZyZWVfY2hh bm5lbF9saXN0KCk7DQo+PiArb3V0Og0KPj4gKyAgICByZXR1cm4gcmV0Ow0KPj4gK30NCj4+ICsN Cj4+ICtzdGF0aWMgY29uc3Qgc3RydWN0IGR0X2RldmljZV9tYXRjaCBzY21pX3NtY19tYXRjaFtd IF9faW5pdGNvbnN0ID0gew0KPj4gKyAgICBEVF9NQVRDSF9DT01QQVRJQkxFKCJhcm0sc2NtaS1z bWMiKSwNCj4+ICsgICAgeyAvKiBzZW50aW5lbCAqLyB9LA0KPj4gK307DQo+PiArDQo+PiArRFRf REVWSUNFX1NUQVJUKHNjbWlfc21jX21hLCAiU0NNSSBTTUMgTUVESUFUT1IiLCBERVZJQ0VfRklS TVdBUkUpDQo+PiArICAgICAgICAuZHRfbWF0Y2ggPSBzY21pX3NtY19tYXRjaCwNCj4+ICsgICAg ICAgIC5pbml0ID0gc2NtaV9wcm9iZSwNCj4+ICtEVF9ERVZJQ0VfRU5EDQo+PiArDQo+PiArLyoN Cj4+ICsgKiBMb2NhbCB2YXJpYWJsZXM6DQo+PiArICogbW9kZTogQw0KPj4gKyAqIGMtZmlsZS1z dHlsZTogIkJTRCINCj4+ICsgKiBjLWJhc2ljLW9mZnNldDogNA0KPj4gKyAqIHRhYi13aWR0aDog NA0KPj4gKyAqIGluZGVudC10YWJzLW1vZGU6IG5pbA0KPj4gKyAqIEVuZDoNCj4+ICsgKi8NCj4+ IGRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC1hcm0uaCBiL3hlbi9pbmNsdWRl L3B1YmxpYy9hcmNoLWFybS5oDQo+PiBpbmRleCAwOTViMWEyM2UzLi4zMGU0NmRlNmQ3IDEwMDY0 NA0KPj4gLS0tIGEveGVuL2luY2x1ZGUvcHVibGljL2FyY2gtYXJtLmgNCj4+ICsrKyBiL3hlbi9p bmNsdWRlL3B1YmxpYy9hcmNoLWFybS5oDQo+PiBAQCAtMzI5LDYgKzMyOSw3IEBAIERFRklORV9Y RU5fR1VFU1RfSEFORExFKHZjcHVfZ3Vlc3RfY29udGV4dF90KTsNCj4+DQo+PiAgICNkZWZpbmUg WEVOX0RPTUNUTF9DT05GSUdfQVJNX1NDSV9OT05FICAgICAgMA0KPj4gICAjZGVmaW5lIFhFTl9E T01DVExfQ09ORklHX0FSTV9TQ0lfU0NNSV9TTUMgIDENCj4+ICsjZGVmaW5lIFhFTl9ET01DVExf Q09ORklHX0FSTV9TQ0lfU0NNSV9TTUNfTUEgIDINCj4+DQo+PiAgIHN0cnVjdCB4ZW5fYXJjaF9k b21haW5jb25maWcgew0KPj4gICAgICAgLyogSU4vT1VUICovDQo+PiBAQCAtMzU1LDYgKzM1Niw4 IEBAIHN0cnVjdCB4ZW5fYXJjaF9kb21haW5jb25maWcgew0KPj4gICAgICAgdWludDMyX3QgY2xv Y2tfZnJlcXVlbmN5Ow0KPj4gICAgICAgLyogSU4gKi8NCj4+ICAgICAgIHVpbnQ4X3QgYXJtX3Nj aV90eXBlOw0KPj4gKyAgICAvKiBJTiAqLw0KPj4gKyAgICB1aW50OF90IGFybV9zY2lfYWdlbnRf aWQ7DQo+PiAgIH07DQo+PiAgICNlbmRpZiAvKiBfX1hFTl9fIHx8IF9fWEVOX1RPT0xTX18gKi8N Cj4+DQo+PiAtLQ0KPj4gMi4zNC4xDQo+Pg0K From xen-devel-bounces@lists.xenproject.org Fri Jan 16 16:17:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 16:17:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206806.1520094 (Exim 4.92) (envelope-from ) id 1vgmVh-0005Wv-FT; Fri, 16 Jan 2026 16:17:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206806.1520094; Fri, 16 Jan 2026 16:17:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgmVh-0005Wn-BC; Fri, 16 Jan 2026 16:17:17 +0000 Received: by outflank-mailman (input) for mailman id 1206806; Fri, 16 Jan 2026 16:17: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 1vgmVg-0005Pw-00 for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 16:17:16 +0000 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [2a00:1450:4864:20::629]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d1edd7a5-f2f6-11f0-b15e-2bf370ae4941; Fri, 16 Jan 2026 17:17:14 +0100 (CET) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-b8714a52072so338587866b.3 for ; Fri, 16 Jan 2026 08:17:14 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b879ae74639sm228575566b.9.2026.01.16.08.17.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Jan 2026 08:17:13 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d1edd7a5-f2f6-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768580234; x=1769185034; 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=AoBnW7tBy1EuHOi2Jlnywq3gozT2W8TQV+cw8fxFPbM=; b=JBOYeLGAiPrVqLwBka3lfhAu/xAuNGdv2LXlRXH9AeB7+Y7p2VxgtlBlUgWnhHj3cf 9WErd4eAAX42lEcJM9j+AZCuc95kffF9z34FjvwFiiL+/p4gZytWId1wbR92vX59gkD/ v9zTwrxHwlC2eQJlzFiIzv61sIkrgLdK4MUgTxpGJhA7g51+dwhbfn6d24MH5rUsxZRS jiyW8BpMVOKCmIWgItjvM7Zyq8qC5yK921Plou74mv5M5Mgul3iyYcvrzIjXfQZC2Ufa lcVna2VRlOUg7ND7ljZqWaAGTEPK4lKhSofofb7nhMrdbn8xgXV25PNMOSNyCIYEz5BM lMSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768580234; x=1769185034; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=AoBnW7tBy1EuHOi2Jlnywq3gozT2W8TQV+cw8fxFPbM=; b=id3nEdNnD/AkVvWVQVQIqwg9cYBKlEVY/uIPJ26tS33omG8uzm2DWnUteU4FYFbnF0 c8nVKkLffOgkUY8Pr+GNVmOyXr1Vj7bD2pP/ktPkO0m60jf9lvVGlr1JBsUyCiK3hnWV uURogK9pQEaVIOCsIx1hSgYnoGAZhIfdIHmbSligzViKDm4AV91vYQcJ3150laW++Cuu 7umtajo22XGQJtcC5Q/JqQqwfBIbNEpBplSpJ3vbyqGODP0HGNLBxi0WLva2p6ZKZHgB pbpTxo5g1DSHwnOBmrIIVXx4YX/yj+n+m/Nfy+Omj57kqCjvP2RE3ZYcKIeTo/trdPk9 3+Yw== X-Gm-Message-State: AOJu0YwBCkil0XUbUTszuf8BE6Ne8qBC7+vV2rgIeQcSvFrMK5JK9hNr dTYBcsBFwLIZgNXyd0xLCW9it4Otv/3BDvH9RNojXbezrnow601i/KxchkxBjg== X-Gm-Gg: AY/fxX7seLe0vfrMLfAHpTG0PSCA4wnYhYtO6jRZ9nohRXq7aduIZsBvejUHvqzYhZQ 5Ufvpvr1Q+pS+EjUvASkn6NlEMvzahHosP8ARVVstr/j4V/+30K+1XPOSnI33L8tEunqnEqbUd0 1hLowaE6GF3U5yO5Ht8jWHEjKOqY592uIVeIA+7lajvTO8+/Qe1REuJCNmY3IYAxBxoD7Eqk1wc wM0hdYVc9lAStEwfjLaOi81h1bAbZIRQb+k3hYQHdIXQeMqFBFdp9LJgaMEDjGRgaXNxdhfYNLc 62aV/Uf5ROf5+Ixp+k6u2ZdLYm2Foj6wp7V3IJ65spRtBhnPsqzsshoZemOwtfUP2w1NuHxy7sx V649Pb4CV7x++dGvvqrUdd7sFPfyDDamdU/OPmB7PHBkfJK15haJP8vO6k4O/roWMKRRcSEJRJg oqB/4+N1g1pjF7jsE3LOTzrclrTv++YfMgl78I42AuqqkDZK/tUyFfuA== X-Received: by 2002:a17:907:7f91:b0:b87:12ad:d4d3 with SMTP id a640c23a62f3a-b8796bb1bc0mr245882666b.55.1768580233696; Fri, 16 Jan 2026 08:17:13 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Romain Caritey Subject: [PATCH v2] xen/riscv: dump GPRS and CSRs on unexpected traps Date: Fri, 16 Jan 2026 17:16:39 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Provide more context on the exception state when an unexpected exception occurs by dumping various Supervisor, Virtual Supervisor and Hypervisor CSRs, and GPRs pertaining to the trap. Signed-off-by: Oleksii Kurochko --- Changes in v2 - Address coments about print_csr() macros and dump_csrs(). - Add dumping of GPRs pertaining to the trap. --- xen/arch/riscv/traps.c | 82 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c index e9c967786312..4e0df698552f 100644 --- a/xen/arch/riscv/traps.c +++ b/xen/arch/riscv/traps.c @@ -17,6 +17,13 @@ #include #include +#define print_csr(csr) \ + printk("\t" #csr ": %016lx\n", csr_read(csr)); + +#define print_gprs(regs, reg1, reg2) \ + printk("\t%-7s: %016lx %-7s: %016lx\n", \ + #reg1, (regs)->reg1, #reg2, (regs)->reg2) + /* * Initialize the trap handling. * @@ -99,12 +106,87 @@ static const char *decode_cause(unsigned long cause) return decode_trap_cause(cause); } +static void dump_general_regs(const struct cpu_user_regs *regs) +{ + printk("\nDumping GPRs...\n"); + + print_gprs(regs, ra, sp); + print_gprs(regs, gp, tp); + print_gprs(regs, t0, t1); + print_gprs(regs, t2, s0); + print_gprs(regs, s1, a0); + print_gprs(regs, a1, a2); + print_gprs(regs, a3, a4); + print_gprs(regs, a5, a6); + print_gprs(regs, a7, s2); + print_gprs(regs, s3, s4); + print_gprs(regs, s5, s6); + print_gprs(regs, s7, s8); + print_gprs(regs, s9, s10); + print_gprs(regs, s11, t3); + print_gprs(regs, t4, t5); + print_gprs(regs, t6, sepc); + print_gprs(regs, sstatus, hstatus); +} + +static void dump_csrs(unsigned long cause) +{ + unsigned long hstatus; + + printk("\nDumping CSRs...\n"); + + printk("Supervisor CSRs\n"); + print_csr(CSR_STVEC); + print_csr(CSR_SATP); + print_csr(CSR_SEPC); + + hstatus = csr_read(CSR_HSTATUS); + + printk("\tCSR_STVAL: %016lx%s\n", csr_read(CSR_STVAL), + (hstatus & HSTATUS_GVA) ? ", (guest virtual address)" : ""); + + printk("\tCSR_SCAUSE: %016lx\n", cause); + printk("\t\tDescription: %s\n", decode_cause(cause)); + print_csr(CSR_SSTATUS); + + printk("\nVirtual Supervisor CSRs\n"); + print_csr(CSR_VSTVEC); + print_csr(CSR_VSATP); + print_csr(CSR_VSEPC); + print_csr(CSR_VSTVAL); + cause = csr_read(CSR_VSCAUSE); + printk("\tCSR_VSCAUSE: %016lx\n", cause); + printk("\t\tDescription: %s\n", decode_cause(cause)); + print_csr(CSR_VSSTATUS); + + printk("\nHypervisor CSRs\n"); + + printk("\tCSR_HSTATUS: %016lx [%s%s%s%s%s%s ]\n", + hstatus, + (hstatus & HSTATUS_VTSR) ? " VTSR" : "", + (hstatus & HSTATUS_VTVM) ? " VTVM" : "", + (hstatus & HSTATUS_HU) ? " HU" : "", + (hstatus & HSTATUS_SPVP) ? " SPVP" : "", + (hstatus & HSTATUS_SPV) ? " SPV" : "", + (hstatus & HSTATUS_GVA) ? " GVA" : ""); + + print_csr(CSR_HGATP); + print_csr(CSR_HTVAL); + print_csr(CSR_HTINST); + print_csr(CSR_HEDELEG); + print_csr(CSR_HIDELEG); + print_csr(CSR_HSTATEEN0); +} + static void do_unexpected_trap(const struct cpu_user_regs *regs) { unsigned long cause = csr_read(CSR_SCAUSE); printk("Unhandled exception: %s\n", decode_cause(cause)); + dump_csrs(cause); + dump_general_regs(regs); + die(); } -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Fri Jan 16 16:48:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 16:48:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1206852.1520102 (Exim 4.92) (envelope-from ) id 1vgmzu-0001Kq-JL; Fri, 16 Jan 2026 16:48:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1206852.1520102; Fri, 16 Jan 2026 16:48:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgmzu-0001Kj-GH; Fri, 16 Jan 2026 16:48:30 +0000 Received: by outflank-mailman (input) for mailman id 1206852; Fri, 16 Jan 2026 16:48: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 1vgmzs-0001Kd-Nt for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 16:48:28 +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 2d69ea1c-f2fb-11f0-9ccf-f158ae23cfc8; Fri, 16 Jan 2026 17:48:26 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by AS8PR03MB7908.eurprd03.prod.outlook.com (2603:10a6:20b:423::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.4; Fri, 16 Jan 2026 16:48: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.9520.005; Fri, 16 Jan 2026 16: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: 2d69ea1c-f2fb-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=usf+GHsGG3N0Tg+yeKkGrQzJPwQeloqAWw5GVyn5aeS0FBS9YUc7qx6tPieH8dBGstqelQHwYV1RXFni9zIRu8aXApE6YvNlho4tRvA8os6SqSbgFHNyvamjPqOZwoXQFeA70hQ7mSvdnNyKDI4qmMvB8TZepqca3b75aBiHsLUAeW0Ae0RHy4l1CPzAkmoluTxJ1Xca3XnwGYnht1F0N3RXdeeuUORSR9cVd1nm1ENa0in5Ye+/ttfwdfXFO03kipD+m2gQ+OpZmkp8xbZoaStpGYoXm/f9uxPwtjXW95JbzZUO27fwiDRfx7gOI8vN+oCvYyyBSwCzDO3kfLQ9xQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=It20i3rhZ/8FmuH9XLH2uRdbx5EC01CNmV2DeU3GCcg=; b=w7ia9SMTqG93SwBnVO96BOLKkUI5HSGthiNMWfyD/scyioQOP9ieWhD5QxUFODY81Q+I8ACf9MFww/Ex8kksv/t7S1f4obVooJPWxbZEjrpTngto7LQqk+tIoyOQt64BU9az/bXtfS7I9bcs/egd3sVzfY8EfhBCBxpcAP4q1/25bd49qf2VH3cDMdvTjrUmWC1U9GV5PODyfyL8SoVpFaE70GEvi1LJVKPLbmqfaVWND1hJJXRLwBAmOJc6ROYHvSnpPxzN51DZvXDiylz+WYLchFa7Eh0dZZ9fA4KqnPeAa84BQ2PCgx+j6dwY1QtpTG27SeHEGIoBRtulw+yw4w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=It20i3rhZ/8FmuH9XLH2uRdbx5EC01CNmV2DeU3GCcg=; b=IkWBZ/iWQ/ombq6oCRoCmh6+j3DrrK8IlwKpMpjZl7z1tpfnsbgdEmPSNzbMnKKUwRCEgy8aH29mEC8E0fvrlUumrQkfKZ7VCxrhyjNMYb+2b0iJaxVy7VPF2AuCeAVKOuxVDm8FvlHIGwgW7qyJ5Zlo2139yNLNdUILt4KROKF1gK1Bl3uDc11Ic/PQoFtv8bfDngKu9M5+AqNevKqfuBaKdzLqE4ak3qUAG3lyIlqZQD9S0GehI5HDc/3ELkbYElqNNA81eRUYbINE5HA+8KD+Leh6cARE3NDdou0xelZn2O9j/5SQozedkiPn+Zv2+fzoMVbmKDRye0/V5w+HFQ== From: Oleksii Moisieiev To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v7 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [PATCH v7 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHchYPEY703sAu32kaCSJHhjFUjhrVS+QWAgAILygA= Date: Fri, 16 Jan 2026 16:48:21 +0000 Message-ID: References: <29c2d1dc-23fb-403e-bb03-d8c2f32424e6@suse.com> In-Reply-To: <29c2d1dc-23fb-403e-bb03-d8c2f32424e6@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_|AS8PR03MB7908:EE_ x-ms-office365-filtering-correlation-id: 50f9d6d0-2092-4c4e-4949-08de551f0e9c x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|7416014|1800799024|38070700021; x-microsoft-antispam-message-info: =?utf-8?B?aFUyb2JjMEhXQXJyRFdqdHBOdWtZcXU1V1YzdDNGaGtlcGgvaWdLbXc4dy9k?= =?utf-8?B?VFNIa3AyNEt2UWNBeHMxVEVROWNvMGowUXFoeXRnR0grREtmL0o3QUJyNjZH?= =?utf-8?B?VGtEVWJDcmlHNmswQko4cUpML1RDT3E1cnp4TEplVzNqemY1bzlVbzBpbmxi?= =?utf-8?B?QkM3Smw4Tlg5aDhBN0FTcWs2alo1SFA2NFhiNmtSdzZUNHYvcEsxUkQ4alU5?= =?utf-8?B?RHdiNlpJeVFNV3lEd2lTeEpSc3RQVGl1UjZsMTBrUVJKQTNsQ2RlM0Y1V3U0?= =?utf-8?B?SjljOEwvNDhiZ0VzYjRidWYxM3JkSkNUbURDWEYrUmN5eEpWOUtBV0dwb0Rj?= =?utf-8?B?RWNnaVVOZXdkUUtDc0M5UDhuUHp1QzFCLzJmMUN3VmdnZzJabzVtS3BhY2k0?= =?utf-8?B?ZlBsNEFham13OGk3ZTNJZHlsaVlDUldiMVZBNnFuR1pELzRoTW1BbW1XSzNw?= =?utf-8?B?dlUxNUNjbHNMT1JFS2YyRVdZd1dNYXdwZTU0UHdYRVd1dWJoU1N3VjVialNp?= =?utf-8?B?YmV2Vjd2TGhialdxM21adm1XcDB2NU9qUm93VFg1U3FsL2EzRUg5RC8yK0JZ?= =?utf-8?B?T1hxOHR4aW1TZUx4SlJHQ3l6YS93UGIwRk1Nbm1ST0p2R2VqaGw5YTlrYVMv?= =?utf-8?B?eFlaZ1dSVlk5MlIyeWhSalMrbmxLMjZNdkNZRVFodENPQWxtUWwrajdlTGxo?= =?utf-8?B?eVNONUdqSzA4aVhjcDJsZHE3TGxqK2ZqSEdrRTNXQ1ZhRHV3WmxkV3hCUHZY?= =?utf-8?B?Uko0cE0reEl4dVBaZ2Z5T1VYMVNCTmgvL0NqMEtIRUhYeFFCWm1VMXErMkhN?= =?utf-8?B?YThCNjhwMTZZdUpLRjFNWDROWk0zS0pWaVZKdFdsTTZnL0ZvUnE2azJWeEFl?= =?utf-8?B?OUw3MnlkeW5jQmhzTzhqVERTUlhNd3YzZDdXZ09tRTg5dlhiWGxIT3VTcVFu?= =?utf-8?B?Sms4UEFNQjhtdzc2MjRwcEl1NTNneU9pbGtjQ2FGY2ZhZVVpNklhQ2Q4c1p0?= =?utf-8?B?NGZJZVQxWGVpRXcxZFJ4Nms5YkZEMWIyc3RRY3FDbmljTEFpeVNYRUVtbmRl?= =?utf-8?B?d1laRktxN2ljQVg0ZklabnpLN253Q2VDWFJZUy8vVFM3MDVIS01yOFpHZE9S?= =?utf-8?B?a3BUSlNtcEx3dGhnbFpvbGNqZnRNTVY2SzB3OHdVQkFXbTQyRmtKRVBXN1FH?= =?utf-8?B?M2tFU2orcDVMa3dJNEpQMFRSV2pqNTJBL1RXZE1sdEVqMm05R0hweHU0bjBn?= =?utf-8?B?SDRkNUhMbHRoNjBwQ25nR3ZXcTExaU4vTHkxUXBTemIyWFZIQ1VZblRDQUlT?= =?utf-8?B?MFJsSGsrNWpBMDVlczB1bjNNSitGY1VUbmtFK3lUdkY0b3dKNXNnWkUzbHhp?= =?utf-8?B?SWc5VVM4aHJtUEpRazhJcDlCLzc2YTE2b2U3ODlWVjVTTGxySGpCVHlXSlF3?= =?utf-8?B?WXdIelROK3dYZ2NMUGtRRlk0dHVUVW0rcHdNZlBINnR4YzBOMDFBdzhnUjZ0?= =?utf-8?B?VXUxcDF1d1U1WHRmZlR1VVFEODRoSHc2dEN3cDZYaDFFbGpVYm9UelZuQXNm?= =?utf-8?B?TUt4Rk94b2Jla0ZCMWlTOUFqMDBIMURVbFhCNGwvMmF0czRvUkVCai8yZ3k0?= =?utf-8?B?ZHdpQ1ZtZ3FGU1VyVGFLdjFseXh2MUZsS0ZJK0dHZFpNa3dya3luRWRFeDlp?= =?utf-8?B?MDQvOUp3VFhNcGFqcGNYTFA4L0pXMStlcG1EbmRuRWpFL3pjWEVMajNxZTFS?= =?utf-8?B?aVc5dUI2SDNncVhBTnRMRjAyZFR3ZHovSjg3dkhwRkNzaUs4ODBoR1NnN0NK?= =?utf-8?B?eVlER0FrRkM2d3c4djJ2djRFWmJ3dlc0dUoxZUtRWlIybkpEVFNwOHNKWURF?= =?utf-8?B?aWx2ZHkxay9kYWxsb3ZCMERrVmdHbklTRURUdUU2ZjNuekkrbU9SMjF0WEpB?= =?utf-8?B?aENnOTVSVkNRL0dCTU8xWFpaOHlkeFVmWXhRdExVcnMyaS9XQUZuSjNSL3B2?= =?utf-8?B?bVJQNHlEZkhIaFJybGhpUFNacEhoNDc4Vm5ZVDdMMXBYSEt5Q1V6OVl3Y0Ur?= =?utf-8?B?cjhsNU8zZ1ZPRnZlb3JjTklOR1RhbG9NWUkrdGw4eHhkVWtOU3JsTmNNUmg2?= =?utf-8?B?VHVFSXkxUEF6RGpiVTd3b0dBTmdnUTdsc2UvQ255Y2h5TDRiL1NsNEZzT2oy?= =?utf-8?Q?1uKadJXim6oFAEmx9G1tnyI=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)(7416014)(1800799024)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?TDV0Tm5NNXQxakJFVXcxcEp3Z3FDbnBjalZXRnVFSXpvblArNGhacEVRVXFN?= =?utf-8?B?Wm82RFh0K0VnUFUyWlN3a1I4QzU1bXlLcHpGcXEvZmRaajhENHhsdVNoTEd2?= =?utf-8?B?Zjd4SGNDUENhVzQrQ1UwbGl1TGh0ZG9xMG9BeFFRc25VMjVFSndkeFpsTGg2?= =?utf-8?B?RVdIVllkTnY2Y0RNN1RkeUxEOEpLeXhNVnRJN0lLNWhjaTNrR0JabllHU2Rx?= =?utf-8?B?VVBhQTM3ZmxCL2Nqb0pXYVRvMDZpL3NIcUxNWThxa01kTDErdENIQlpmNHgr?= =?utf-8?B?WUdlVmF1QU9OUmFMeDVGRjR0YVcyWmprZU5teXRMK1ZTL215ZWlNRHpzTGQ3?= =?utf-8?B?d1hQcWRuYUhheEdEK3VXUnlPNldHRmcvS1lJTkJHeVJZeUd5ZGpJZ29YdjlQ?= =?utf-8?B?cUpOK2xNdHBiVU1JWGFzU0s5ZEc1R211dlYyeW10cndhRHgxYjFUM1FCbXVI?= =?utf-8?B?Mm9LNjVrYlZBKy9KTEcvWFVnQWl6eG51QUxzTHFkR0hlQUd3MmhkaW42T3o3?= =?utf-8?B?eEdOMVk3U25TazF2UUpoM1BOQ2MvK1FGdWh2b04zYSswQlhWUEw4YnQrbk1a?= =?utf-8?B?WHhuL092ZG95am9TYys3VUFvaHhEdGlySzFuTndMQ2h5UlJvWnZqd2FhVHcv?= =?utf-8?B?MVhVbWhvSDdkZUI2VHF6TktrMWl3SWZKZis0bnJFcnBBT2lsemxmeVg2UThJ?= =?utf-8?B?VW01bWJGQUxFUWxtdHV3aVk1VHIyekVSWTg1U3F0SGNsQXc2c2R3ZXFJc2Ux?= =?utf-8?B?RERGeHJQaFExaGgyQzcwYktZNlh3QU5CTUZtYVpkUGxvOHJwSVhlWnQwYjFw?= =?utf-8?B?SW4yV1o3SU8ra0FQSWVOb3hTc0pxNWNTMXR0RHo2OW43ZGZkUEhMV0Rsb2RV?= =?utf-8?B?UkVCL0gzTW94RWdLNU14K1dsNnAvL25CU09odWdISmlseVJLeVpwN3FVczNx?= =?utf-8?B?VVp6WS9ZdXp2S3ZKYktMcTBJYXh2YlNTYWVzbGJ0b2JRejV6OTBKUnVjL2RU?= =?utf-8?B?UGpaSzNJVTZ1cXgvcldtZ1ZxY0tQQUVzcTc4M05TblJPOXY4MGQvZTBYQ212?= =?utf-8?B?WGZmR21jdXlzN2RVSkwyQUhFbW1Ea2tDR1I5OXdta3NGWVZDcnpQbE1jWkZY?= =?utf-8?B?eEM3WjFxcHB4UHFqVitleGtnQkYwdUYvbWo0c2hyeVNVaklzbG1MeTNvL3k5?= =?utf-8?B?V3BzSXZvazdhUTk5ZEYxTzJ1Uy9CUGZudzhaZEZpRnAyMmk0WExjWHk0UURi?= =?utf-8?B?ZnRDZ3F5YXZHZm1XNVVYTEZlVW1sMGRIZkdhSGVVYTlTd3BUT0diZEJVOGlF?= =?utf-8?B?RHVNUzMxRW5VbG5FbytUaU8ySSswNktnakx2eFc5ZENJSzZKTXlWMG9TZmZO?= =?utf-8?B?eG9oc2grd2czN1RFelpBMzErbUtmR09QZHFGWkRLaFAwMS9ZUk8rUitXSHJL?= =?utf-8?B?VXh0aDZmbzhsV1M1VmI2RU44alVxWTFJVjFiQTJldVhiTWFaQXVnblptL0sr?= =?utf-8?B?aXU5QThpNjAyODJRS3VzL21UbWN6M2NPQi8wVUcvZWorN2hmcmlrZXllSFZ2?= =?utf-8?B?QVRYWmg4UjlacGRuaGpSalNBM2JVVzlzWG1UUmx4N3Z0YjZDbTQ1V2w4TVA3?= =?utf-8?B?Y25BNXE3U2pGZEs1Y042WFI1TDJ2K08wSzl1M3J1STk0RFRDZWZYbFRrZGc4?= =?utf-8?B?d0JLNGdJTXMzZU5tYndiekNqcWQ0eXNocXh6RmhzUTZvV2FFWlpmNlRZZS92?= =?utf-8?B?TEljSXZuM2d1R3pKTzl5bE9ENTFWcTNpSWJCbWZxTFkyTVFldHdWazc3SGV2?= =?utf-8?B?eVF6WnphU1dTbTBJVjVNak1pL0duVVdhcXdRRGtCWGl0STNGNGNtUXh1cGpa?= =?utf-8?B?TU5UaGxXQWluR2o3ejFVRjFvemhtV2NwdjFsUjRrZHI1cG9CdHYvV3RKYm5m?= =?utf-8?B?K3dBWFhQTVk4Qnk3M3BJdVc1MzFUZGI2Z1RrVllZWlY5VDZRWm54YkRkL3Bz?= =?utf-8?B?RU1lOFVsQmp4RWxObUYzRHdSRkVxOVNMRjkxKysvd2Nxd1I3RUhBc0hWdDVY?= =?utf-8?B?eDVBcnB0RUxyRW53N1JiYkFNNDlRR3VXNGg2aXYzb2dONG9BKzlVR3l6NVQ0?= =?utf-8?B?RTBBamlrWUp0TnBIS3F0YUErNktFMEdQbG9Xd2pKYXZ6cy96akQyQVcrZXIz?= =?utf-8?B?ZjFXRzVZMXA1UjRENWJPNEJDNHN6ZXBneHhHMmxObC8yZ2FNdVQxK1NoMHVX?= =?utf-8?B?RnlHa0QxTCtPUEZmV3I2ejloMVFiMFFHUzZoOG1sWXV5QWNTQzM1T2psNC8w?= =?utf-8?B?N1l4RmN2aDI0WEVQUk9URnRCSWE2czJZWWl2N0VNd01ZV242ZWdNVi9FTzZB?= =?utf-8?Q?KqXF2GwdDgXtPGw4=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: PAVPR03MB8946.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 50f9d6d0-2092-4c4e-4949-08de551f0e9c X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2026 16:48:21.0198 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4UF+vPfYR6WG6JgQlTradLkF6DfiKH8PaNTVQ97fjTxJ6v+g21S6sxcD908YHoWsoasKBfcmIq24Wmf82zadopwcrVOvjW+OH7wGtjnqtHA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7908 DQoNCk9uIDE1LzAxLzIwMjYgMTE6MzMsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAxNC4wMS4y MDI2IDE5OjI5LCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToNCj4+IEBAIC0xMTA3LDYgKzExMTUs MTUgQEAgYWZmaW5pdGllcyB0byBwcmVmZXIgYnV0IGJlIG5vdCBsaW1pdGVkIHRvIHRoZSBzcGVj aWZpZWQgbm9kZShzKS4NCj4+ICAgDQo+PiAgIFBpbiBkb20wIHZjcHVzIHRvIHRoZWlyIHJlc3Bl Y3RpdmUgcGNwdXMNCj4+ICAgDQo+PiArIyMjIHNjbWktc21jLXBhc3N0aHJvdWdoIChBUk0pDQo+ PiArPiBgPSA8Ym9vbGVhbj5gDQo+PiArDQo+PiArVGhlIG9wdGlvbiBpcyBhdmFpbGFibGUgd2hl biBgQ09ORklHX1NDTUlfU01DYCBpcyBjb21waWxlZCBpbiwgYW5kIGFsbG93cyB0bw0KPj4gK2Vu YWJsZSBTQ01JIFNNQyBzaW5nbGUgYWdlbnQgaW50ZXJmYWNlIGZvciBhbnksIGJ1dCBvbmx5IG9u ZSBndWVzdCBkb21haW4sDQo+PiArd2hpY2ggc2VydmVzIGFzIERyaXZlciBkb21haW4uIFRoZSBT Q01JIHdpbGwgYmUgZGlzYWJsZWQgZm9yIERvbTAvaHdkb20gYW5kDQo+PiArU0NNSSBub2RlcyBy ZW1vdmVkIGZyb20gRG9tMC9od2RvbSBkZXZpY2UgdHJlZS4NCj4+ICsoZm9yIGV4YW1wbGUsIHRo aW4gRG9tMCB3aXRoIERyaXZlciBkb21haW4gdXNlLWNhc2UpLg0KPj4gKw0KPj4gICAjIyMgZHR1 YXJ0IChBUk0pDQo+PiAgID4gYD0gcGF0aCBbOm9wdGlvbnNdYA0KPiBJIGFwcHJlY2lhdGUgbWlz c2luZyBkb2MgZm9yIGEgcHJlLWV4aXN0aW5nIGNtZGxpbmUgb3B0aW9uIHRvIGJlIGludHJvZHVj ZWQsDQo+IGJ1dDogV2h5IGhlcmUgKGluIHR3byB3YXlzKT8gRmlyc3QsIHdoeSBpbiB0aGlzIHBh dGNoLCB3aXRob3V0IGl0IGV2ZW4gYmVpbmcNCj4gbWVudGlvbmVkIGluIHRoZSBkZXNjcmlwdGlv bj8gQW5kIHdoeSBpbiB0aGUgbWlkZGxlIG9mIG9wdGlvbnMgc3RhcnRpbmcgd2l0aA0KPiAnZCcs IHdoZW4gdGhlIGVudGlyZSBmaWxlIG1lYW5zIHRvIGJlIHNvcnRlZD8NCj4NCj4gSmFuDQpIaSBK YW4sDQoNClRoYW5rIHlvdSBmb3IgcG9pbnRpbmcgdGhhdCBvdXQuDQpJIHdpbGwgYWRkIHRoZSBm b2xsb3dpbmcgbm90ZSB0byB0aGUgY29tbWl0IGRlc2NyaXB0aW9uOg0KDQoiDQpBZGRpdGlvbmFs bHksIHRoaXMgcGF0Y2ggYWRkcyBkb2N1bWVudGF0aW9uIGZvciB0aGUgcHJlLWV4aXN0aW5nDQpz Y21pLXNtYy1wYXNzdGhyb3VnaCBjb21tYW5kIGxpbmUgb3B0aW9uLCB3aGljaCB3YXMgcHJldmlv dXNseQ0KdW5kb2N1bWVudGVkLg0KIg0KRG9lcyB0aGlzIGxvb2sgZ29vZCB0byB5b3U/DQoNCkJS LA0KT2xla3NpaQ== From xen-devel-bounces@lists.xenproject.org Fri Jan 16 20:48:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 20:48:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1207008.1520112 (Exim 4.92) (envelope-from ) id 1vgqjc-0003Xa-Qy; Fri, 16 Jan 2026 20:47:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1207008.1520112; Fri, 16 Jan 2026 20:47: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 1vgqjc-0003XT-O9; Fri, 16 Jan 2026 20:47:56 +0000 Received: by outflank-mailman (input) for mailman id 1207008; Fri, 16 Jan 2026 20:47: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 1vgqjb-0003XN-Pz for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 20:47: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 a0967834-f31c-11f0-b15e-2bf370ae4941; Fri, 16 Jan 2026 21:47:54 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 1D97F438B0; Fri, 16 Jan 2026 20:47:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B917BC116C6; Fri, 16 Jan 2026 20:47: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: a0967834-f31c-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768596472; bh=lhnp+KwTei7PSKtw7nsBqrFYfld0nH8kSgLJrDfqu3U=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=JP+DjfQ6b7KYHMzknP/Z9X8kAT+DCTFu1I2bNgQIwmT/KJT42CNPu+jObGJXneTMN pBdfJqU2W7MqQkJcUS6wd4Kzr3tq4lqxfbdBNh7clKI5UiFr41L7se/Ae8YH5epdZB XiuON7iYBB5eR6LC0GrN6Cx14TX9oAsdc5SQVRf+/ZSO5F/ehbQ+1Ght8+dyQpe7o7 mKuipkKpkidII58ihlWUGb/llk/IbE4pdKtzZxSwzWiriIWeHZ5KRz88lYbHt5xeLk csfLoyO9S/9RkgnF7lKdz820oqTEU5KKe+OF+n6ZWgw2u+6iTxuYajN6OSVA76z1VF eI4/Sc2IKBwCQ== Date: Fri, 16 Jan 2026 12:47:50 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop 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 Subject: Re: [PATCH v2] INSTALL: remove unsupported XEN_CONFIG_EXPERT from documentation In-Reply-To: <09c0007b-3cac-469a-83a0-726c1be149da@suse.com> Message-ID: References: <20260116030842.415583-2-dmukhin@ford.com> <09c0007b-3cac-469a-83a0-726c1be149da@suse.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 16 Jan 2026, Jan Beulich wrote: > On 16.01.2026 04:08, dmukhin@xen.org wrote: > > --- a/INSTALL > > +++ b/INSTALL > > @@ -33,11 +33,11 @@ small subset of the options. Attempts to change other options will be > > silently overridden. The only way to find which configuration options > > are available is to run `make menuconfig' or the like. > > I fear this earlier paragraph needs editing as well, which will then > make more clear that ... > > > -You can counter-override this behaviour by setting XEN_CONFIG_EXPERT=y > > -in your environment. However, doing this is not supported and the > > -resulting configurations do not receive security support. If you set > > -this variable there is nothing stopping you setting dangerously > > -experimental combinations of features - not even any warnings. > > +This behavior can be overridden by enabling "Configure EXPERT features" > > +in Kconfig (CONFIG_EXPERT). > > ... this may not be quite adequate. > I am not sure how you would like to change the earlier paragraph or this paragraph. I gave it a try and removed both paragraphs, replacing it with this: """ Only a subset of options is supported or security-supported by Xen Project. You can explore all available options, including unsupported ones and those recommended only for expert users, by using `make menuconfig` and enabling `CONFIG_UNSUPPORTED` and/or `CONFIG_EXPERT`. However, enabling these options is not supported, and configurations resulting from them do not receive security support. """ What do you think? > > However, resulting configurations do not > > +receive security support. In addition, CONFIG_EXPERT permits the > > +selection of experimental and potentially unsafe feature combinations > > +without generating configuration warnings. From xen-devel-bounces@lists.xenproject.org Fri Jan 16 21:07:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 21:07:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1207029.1520122 (Exim 4.92) (envelope-from ) id 1vgr2W-0006LB-9t; Fri, 16 Jan 2026 21:07:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1207029.1520122; Fri, 16 Jan 2026 21: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 1vgr2W-0006L4-6m; Fri, 16 Jan 2026 21:07:28 +0000 Received: by outflank-mailman (input) for mailman id 1207029; Fri, 16 Jan 2026 21:07:27 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgr2V-0006Kw-Ak for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 21:07: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 5ab42a6b-f31f-11f0-9ccf-f158ae23cfc8; Fri, 16 Jan 2026 22:07:24 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 466D160150; Fri, 16 Jan 2026 21:07:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A367FC116C6; Fri, 16 Jan 2026 21:07:21 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5ab42a6b-f31f-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768597643; bh=8ZbdpUbcwnOt6536QD+ehWeN26NaOgAeqEsyV7WEM2M=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=rg/UvFlXpjTHjwVFwn1EWAJif9rRyo2WcN8E2hMs9isxUzKUnP2j0+0ZQZ+qVcCWG CLz/Sdl3CRtSwSIbLqQ9QCaY98KHYphLYJn1MS/MQYmFJsVM/8jZ5AIkUWBA1ffHQ9 iIln+irtzy1MMCI3izrGD9bv8FiU8E3F3lCRRhJIgNMCci8bQ/Swt0Mr7hlbpOhyU0 CzeDhm/BiSUrfvgcV0VdsY3c5C2esd1X1EBhli2J+RpT9rNiyz1JyXTC8aH14pQEsO zKbE+xo2g8CmDy9ksCCmNLtwGFw9WhWcs0ZlK9u5ifvYwIDlsvVBLt+9xJGFZMTxzU Bp5bfhPdhkNOg== Date: Fri, 16 Jan 2026 13:07:20 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Stefano Stabellini cc: xen-devel@lists.xenproject.org, jbeulich@suse.com, grygorii_strashko@epam.com, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Victor Lira , andrew.cooper3@citrix.com Subject: Re: [PATCH v3] xen/console: handle multiple domains using console_io hypercalls In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Tue, 13 Jan 2026, Stefano Stabellini wrote: > Allow multiple dom0less domains to use the console_io hypercalls to > print to the console. Handle them in a similar way to vpl011: only the > domain which has focus can read from the console. All domains can write > to the console but the ones without focus have a prefix. In this case > the prefix is applied by using guest_printk instead of printk or > console_puts which is what the original code was already doing. > > When switching focus using Ctrl-AAA, discard any unread data in the > input buffer. Input is read quickly and the user would be aware of it > being slow or stuck as they use Ctrl-AAA to switch focus domain. > In that situation, it is to be expected that the unread input is lost. > > The domain writes are buffered when the domain is not in focus. Push out > the buffer when the domain enters focus. > > Add the console_lock around serial_rx_cons modifications to protect it > against concurrent writes to it. > > Signed-off-by: Stefano Stabellini Ping? > --- > Changes in v3: > - move serial_rx_cons before printk > - call console_put_domain earlier on CONSOLEIO_read > - take console_lock earlier > - add console_lock around serial_rx_cons modifications > > Changes in v2: > - fix code style > - pbuf_idx/idx after ada53067083e > - don't add extra \0 > - clear input on console switch > --- > xen/drivers/char/console.c | 30 +++++++++++++++++++++++++++--- > 1 file changed, 27 insertions(+), 3 deletions(-) > > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c > index 2bdb4d5fb4..58c32f22ef 100644 > --- a/xen/drivers/char/console.c > +++ b/xen/drivers/char/console.c > @@ -577,6 +577,10 @@ static void console_switch_input(void) > > console_rx = next_rx; > printk("*** Serial input to DOM%u", domid); > + /* Don't let the next dom read the previous dom's unread data. */ > + nrspin_lock_irq(&console_lock); > + serial_rx_cons = serial_rx_prod; > + nrspin_unlock_irq(&console_lock); > break; > } > } > @@ -730,6 +734,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, > unsigned int flags = opt_console_to_ring > ? CONSOLE_ALL : CONSOLE_DEFAULT; > struct domain *cd = current->domain; > + struct domain *input; > > while ( count > 0 ) > { > @@ -742,18 +747,28 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, > if ( copy_from_guest(kbuf, buffer, kcount) ) > return -EFAULT; > > - if ( is_hardware_domain(cd) ) > + input = console_get_domain(); > + if ( input && cd == input ) > { > - /* Use direct console output as it could be interactive */ > + struct domain_console *cons = cd->console; > + > nrspin_lock_irq(&console_lock); > + if ( cons->idx ) > + { > + console_send(cons->buf, cons->idx, flags); > + cons->idx = 0; > + } > + /* Use direct console output as it could be interactive */ > console_send(kbuf, kcount, flags); > nrspin_unlock_irq(&console_lock); > + console_put_domain(input); > } > else > { > char *kin = kbuf, *kout = kbuf, c; > struct domain_console *cons = cd->console; > > + console_put_domain(input); > /* Strip non-printable characters */ > do > { > @@ -795,6 +810,7 @@ long do_console_io( > { > long rc; > unsigned int idx, len; > + struct domain *d; > > rc = xsm_console_io(XSM_OTHER, current->domain, cmd); > if ( rc ) > @@ -815,6 +831,11 @@ long do_console_io( > if ( count > INT_MAX ) > break; > > + d = console_get_domain(); > + console_put_domain(d); > + if ( d != current->domain ) > + return 0; > + > rc = 0; > while ( (serial_rx_cons != serial_rx_prod) && (rc < count) ) > { > @@ -830,7 +851,10 @@ long do_console_io( > break; > } > rc += len; > - serial_rx_cons += len; > + nrspin_lock_irq(&console_lock); > + if ( serial_rx_cons != serial_rx_prod ) > + serial_rx_cons += len; > + nrspin_unlock_irq(&console_lock); > } > break; > default: > -- > 2.25.1 > From xen-devel-bounces@lists.xenproject.org Fri Jan 16 21:21:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 21:21:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1207045.1520132 (Exim 4.92) (envelope-from ) id 1vgrG5-0000dy-Jd; Fri, 16 Jan 2026 21:21:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1207045.1520132; Fri, 16 Jan 2026 21:21:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgrG5-0000dr-H7; Fri, 16 Jan 2026 21:21:29 +0000 Received: by outflank-mailman (input) for mailman id 1207045; Fri, 16 Jan 2026 21:21: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 1vgrG3-0000dl-M3 for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 21:21: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 4fa3fb3a-f321-11f0-b15e-2bf370ae4941; Fri, 16 Jan 2026 22:21:25 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id AE9E560160; Fri, 16 Jan 2026 21:21:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B0A34C116C6; Fri, 16 Jan 2026 21:21:21 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4fa3fb3a-f321-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768598483; bh=kVz63F/RyJ3otjUteBXhgWEC5QC8+f0Ju+jogj49Cy8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=dTWxDWPNJutlwHzW59KTQuBNdEPQtfQ2123bKumxK4Aq5BMsnNfiRGiks6DFzMzFS l9SMkx8CCg/nFv4jC7o6cGTbVH9XsJRMaCSU83yeQ9dQf3if6Pagk+J5GWGmfuIViK irFLQIzWt86vN7yNq7YtXIGL30/3rBcxyJ8Tzycp0ND18dk+SP0QpU27Cbi2crgXZX 9ixbQHYiY6rxLrNzeTo0rd80/qjnzbyLq8gz9atY3blagct9EMvKggAzm738Bmx5/Q yLxckxFq3ZFb//Ecqx4LRRHfbI4FQKMjTHeL88HAQSN84lj3VbVL+vh2PpxAq55He5 uafVGNWTKxkJQ== Date: Fri, 16 Jan 2026 13:21:17 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Oleksii Moisieiev cc: Stefano Stabellini , "xen-devel@lists.xenproject.org" , Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Volodymyr Babchuk , Grygorii Strashko Subject: Re: [PATCH v7 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 16 Jan 2026, Oleksii Moisieiev wrote: > Hi Stefano, > Please see below. > > On 15/01/2026 03:14, Stefano Stabellini wrote: > > Hi Oleksii, > > > > I am fine with the goals and the strategy to achieve the goals but there > > are some finer details that don't make sense to me. I apologize if I am > > asking the same questions you have already answered as some time as > > passed from the last interaction. > > > > > > On Wed, 14 Jan 2026, Oleksii Moisieiev wrote: > >> This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-A > >> (TF-A) which provides SCMI interface with multi-agent support, as shown > >> below. > >> > >> +-----------------------------------------+ > >> | | > >> | EL3 TF-A SCMI | > >> +-------+--+-------+--+-------+--+-------++ > >> |shmem1 | |shmem0 | |shmem2 | |shmemX | > >> +-----+-+ +---+---+ +--+----+ +---+---+ > >> smc-id1 | | | | > >> agent1 | | | | > >> +-----v--------+---------+-----------+----+ > >> | | | | | > >> | | | | | > >> +--------------+---------+-----------+----+ > >> smc-id0 | smc-id2| smc-idX| > >> agent0 | agent2 | agentX | > >> | | | > >> +----v---+ +--v-----+ +--v-----+ > >> | | | | | | > >> | Dom0 | | Dom1 | | DomX | > >> | | | | | | > >> | | | | | | > >> +--------+ +--------+ +--------+ > >> > >> The EL3 SCMI multi-agent firmware is expected to provide SCMI SMC shared > >> memory transport for every Agent in the system. > >> > >> The SCMI Agent transport channel defined by pair: > >> - smc-id: SMC id used for Doorbell > >> - shmem: shared memory for messages transfer, Xen page > >> aligned. Shared memort is mapped with the following flags: > >> MT_DEVICE_nGnRE. > >> > >> The follwoing SCMI Agents are expected to be defined by SCMI FW to enable SCMI > >> multi-agent functionality under Xen: > >> - Xen management agent: trusted agents that accesses to the Base Protocol > >> commands to configure agent specific permissions > >> - OSPM VM agents: non-trusted agent, one for each Guest domain which is > >> allowed direct HW access. At least one OSPM VM agent has to be provided > >> by FW if HW is handled only by Dom0 or Driver Domain. > >> > >> The EL3 SCMI FW is expected to implement following Base protocol messages: > >> - BASE_DISCOVER_AGENT (optional if agent_id was provided) > >> - BASE_RESET_AGENT_CONFIGURATION (optional) > >> - BASE_SET_DEVICE_PERMISSIONS (optional) > >> > >> The SCI SCMI SMC multi-agent driver implements following > >> functionality: > >> - The driver is initialized from the Xen SCMI container ``xen_scmi_config`` > >> (compatible ``xen,sci``) placed under ``/chosen/xen``. Only the > >> ``arm,scmi-smc`` node that is a child of this container will bind to Xen; > >> other SCMI nodes (for example under ``/firmware``) are ignored to avoid > >> stealing the host OSPM instance. > >> > >> scmi_shm_1: sram@47ff1000 { > >> compatible = "arm,scmi-shmem"; > >> reg = <0x0 0x47ff1000 0x0 0x1000>; > >> }; > >> scmi_xen: scmi { > >> compatible = "arm,scmi-smc"; > >> arm,smc-id = <0x82000003>; <--- Xen management agent smc-id > >> #address-cells = < 1>; > >> #size-cells = < 0>; > >> #access-controller-cells = < 1>; > >> shmem = <&scmi_shm_1>; <--- Xen management agent shmem > >> }; > >> > >> - The driver obtains Xen specific SCMI Agent's configuration from the > >> Host DT, probes Agents and builds SCMI Agents list. The Agents > >> configuration is taken from "scmi-secondary-agents" property where > >> first item is "arm,smc-id", second - "arm,scmi-shmem" phandle and > >> third is optional "agent_id": > >> > >> / { > >> chosen { > >> xen { > >> ranges; > >> xen_scmi_config { > >> compatible = "xen,sci"; > >> #address-cells = <2>; > >> #size-cells = <2>; > >> ranges; > >> > >> scmi_shm_0: sram@47ff0000 { > >> compatible = "arm,scmi-shmem"; > >> reg = <0x0 0x47ff0000 0x0 0x1000>; > >> }; > >> > >> /* Xen SCMI management channel */ > >> scmi_shm_1: sram@47ff1000 { > >> compatible = "arm,scmi-shmem"; > >> reg = <0x0 0x47ff1000 0x0 0x1000>; > >> }; > >> > >> scmi_shm_2: sram@47ff2000 { > >> compatible = "arm,scmi-shmem"; > >> reg = <0x0 0x47ff2000 0x0 0x1000>; > >> }; > >> > >> scmi_shm_3: sram@47ff3000 { > >> compatible = "arm,scmi-shmem"; > >> reg = <0x0 0x47ff3000 0x0 0x1000>; > >> }; > >> > >> scmi-secondary-agents = < > >> 0x82000002 &scmi_shm_0 0 > > 0x82000002 is the same func_id as... > > > > > >> 0x82000004 &scmi_shm_2 2 > >> 0x82000005 &scmi_shm_3 3>; <--- func_id, shmem, agent_id > >> #scmi-secondary-agents-cells = <3>; > >> > >> scmi_xen: scmi { > >> compatible = "arm,scmi-smc"; > >> arm,smc-id = <0x82000002>; <--- Xen management agent func_id > > as the one used for Xen. This cannot be right? > > > That's right. Here should be 0x82000003. > >> #address-cells = <1>; > >> #size-cells = <0>; > >> #access-controller-cells = <1>; > >> shmem = <&scmi_shm_1>; <--- Xen management agent shmem > >> }; > >> }; > >> }; > >> }; > >> }; > >> > >> / { > >> /* > >> * Host SCMI OSPM channel - provided to the Dom0 as is if SCMI > >> * enabled for it, ignored by Xen multi-agent mediator > >> */ > >> scmi_shm: sram@47ff0000 { > >> compatible = "arm,scmi-shmem"; > >> reg = <0x0 0x47ff0000 0x0 0x1000>; > >> }; > > this is the same as &scmi_shm_0 which I guess is intended? > > > it is. to match Host DT. > >> firmware { > >> scmi: scmi { > >> compatible = "arm,scmi-smc"; > >> arm,smc-id = <0x82000002>; <--- Host OSPM agent smc-id > > but this again is the same smc-id meant to be used by Xen. > > > > If 0x82000002 is the privileged interface, then it is OK for Xen and > > also baremetal Linux to use it, but Linux Dom0 should not be using it? > > Or is the smc-id interchangeable and not necessarily tied to the > > agent-id? > > > > I think either way this detail should be clarified in the docs. Speaking > > of docs, the next patch introducing the doc is not up-to-date with this > > patch. > > > In my current configuration, I have the following setup: > > The Xen privileged interface operates through func_id 0x82000003. > func_id 0x82000002 is used for Domain-0, in order to keep the Device > Tree (DT) consistent between Xen and bare-metal configurations. > I am unsure how best to document this, since the implementation does > not strictly require this specific configuration and allows flexibility > for the > end user. My intention is to provide an example configuration in the DT > examples that is most likely to be used as a reference for real-world > setups. Yes, I am aligned with that > At this stage, I believe the most appropriate approach is to include a note > in the documentation stating that the examples illustrate a configuration > that aligns well with the Xen architecture, but other configurations are > possible depending on user requirements. Yes. The important detail is to explain that the same configuration works for both Linux baremetal and Linux Dom0. In the Linux Dom0 case, the privileged SCMI connection differs from the one of Linux Dom0 and it is the one used by Xen. Baremetal Linux: func_id 0x82000002, scmi-shmem 0x47ff0000 Dom0 Linux: func_id 0x82000002, scmi-shmem 0x47ff0000 Xen: func_id 0x82000003, scmi-shmem 0x47ff1000 This works because, I am guessing, the privileged SCMI connection is not tied to func_id 0x82000002, scmi-shmem 0x47ff0000. The problem occurs when there can be only one privileged SCMI connection and it is tied to func_id 0x82000002, scmi-shmem 0x47ff0000 which is the one described in the Host DT. In which case, Linux Dom0 ends up with the privileged connection, not Xen. I think we should explain why this problem does not occur. > >> #address-cells = < 1>; > >> #size-cells = < 0>; > >> shmem = <&scmi_shm>; <--- Host OSPM agent shmem > >> > >> protocol@X{ > >> }; > >> }; > >> }; > >> }; > >> > >> This approach allows defining multiple SCMI Agents by adding > >> Xen-specific properties under the ``/chosen`` node to the Host Device > >> Tree, leaving the main part unchanged. The Host DT SCMI channel will > >> be passed to Dom0. > >> > >> The Xen management agent is described as a ``scmi_xen`` node under the > >> ``xen,sci`` comaptible node, which is used by Xen to control other > >> SCMI Agents in the system. > >> > >> All secondary agents' configurations are provided in the > >> ``scmi-secondary-agents`` property with an optional ``agent_id`` field. > >> > >> The ``agent_id`` from the ``scmi-secondary-agents`` property is used > >> to identify the agent in the system and can be omitted by setting > >> ``#scmi-secondary-agents-cells = <2>``, so the Secondary Agents > >> configuration will look like this: > >> > >> / { > >> chosen { > >> xen { > >> xen_scmi_config { > >> compatible = "xen,sci"; > >> #address-cells = <2>; > >> #size-cells = <2>; > >> ranges; > >> > >> /* Shared memory nodes as defined earlier */ > >> > >> scmi-secondary-agents = < > >> 0x82000003 &scmi_shm_0 > >> 0x82000004 &scmi_shm_2 > >> 0x82000005 &scmi_shm_3 > >> 0x82000006 &scmi_shm_4>; > >> #scmi-secondary-agents-cells = <2>; > >> }; > >> }; > >> }; > >> } > >> > >> In this case, Xen will use the ``SCMI_BASE_DISCOVER_AGENT`` call to > >> discover the ``agent_id`` for each secondary agent. Providing the > >> ``agent_id`` in the ``scmi-secondary-agents`` property allows skipping > >> the discovery call, which is useful when the secondary agent's shared > >> memory is not accessible by Xen or when boot time is important because > >> it allows skipping the agent discovery procedure. > >> > >> Note that Xen is the only one entry in the system which need to know > >> about SCMI multi-agent support. > >> > >> - It implements the SCI subsystem interface required for configuring and > >> enabling SCMI functionality for Dom0/hwdom and Guest domains. To enable > >> SCMI functionality for domain it has to be configured with unique supported > >> SCMI Agent_id and use corresponding SCMI SMC shared memory transport > >> [smc-id, shmem] defined for this SCMI Agent_id. > >> - Once Xen domain is configured it can communicate with EL3 SCMI FW: > >> -- zero-copy, the guest domain puts SCMI message in shmem; > >> -- the guest triggers SMC exception with smc-id (doorbell); > >> -- the Xen driver catches exception, do checks and synchronously forwards > >> it to EL3 FW. > >> - the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen > >> management agent channel on domain destroy event. This allows to reset > >> resources used by domain and so implement use-case like domain reboot. > >> > >> Dom0 Enable SCMI SMC: > >> - pass dom0_scmi_agent_id= in Xen command line. if not provided > >> SCMI will be disabled for Dom0 and all SCMI nodes removed from Dom0 DT. > >> The driver updates Dom0 DT SCMI node "arm,smc-id" value and fix up shmem > >> node according to assigned agent_id. > > Given that everything else, the entire configuration, is based on device > > tree, I think it makes sense to also configure this via device tree > > instead of a command line. > > > > This could be another parameter under xen_scmi_config. What do you > > think? > > > > The ``dom0_scmi_agent_id`` parameter was introduced to keep the Dom0 > configuration separate from the xen_scmi_config node, which is intended > specifically for Xen SCMI configuration. In my opinion, adding Dom0-specific > configuration to xen_scmi_config would mix the purposes of the node and > reduce clarity. > > Additionally, the ``dom0_scmi_agent_id`` parameter is similar to the > ``agent_id`` parameter used for arm_sci in xl.cfg. This approach ensures > that > the Dom0 configuration is as consistent as possible with the > configuration for > other domains. > > Overall, I believe this makes the configuration less confusing, as it allows > us to set similar parameters for both Dom0 and other domains in a clear > and organized manner. We are heading in a direction where Dom0 has its own separate domain node similarly to other Dom0less domains. Many of these changes have already been committed as part of Hardware Domain / Control Domain separation work by Jason. In a world where Dom0, like other DomUs, has its own configuration node and also Dom0 can be split between Hardware Domain and Control Domain, it doesn't make sense to use Dom0 command line options anymore. It is already possible to assign Dom0 "powers" to a dom0less domain for example. I can see it is worth discussing command line options for dom0 in situations where Device Tree might not be present (datacenter configuration on ACPI system) but in this case where Device Tree changes are required, I think it doesn't make sense to add Dom0 command line options as they are less flexible and a duplicate of other options we must have anyway. However, we can express them in better ways. For instance, we could reuse your exiting work to enable dom0less DomUs. See https://www.youtube.com/watch?v=J6q67jkG5DQ > >> Guest domains enable SCMI SMC: > >> - xl.cfg: add configuration option as below > >> > >> arm_sci = "type=scmi_smc_multiagent,=2" > >> > >> - xl.cfg: enable access to the "arm,scmi-shmem" which should > >> correspond assigned agent_id for the domain, for example: > >> > >> iomem = [ > >> "47ff2,1@22001", > >> ] > >> > >> - DT: add SCMI nodes to the Driver domain partial device tree as in the > >> below example. The "arm,smc-id" should correspond assigned agent_id > >> for the domain: > >> > >> passthrough { > >> scmi_shm_0: sram@22001000 { > >> compatible = "arm,scmi-shmem"; > >> reg = <0x0 0x22001000 0x0 0x1000>; > >> }; > >> > >> firmware { > >> compatible = "simple-bus"; > >> scmi: scmi { > >> compatible = "arm,scmi-smc"; > >> arm,smc-id = <0x82000004>; > >> shmem = <&scmi_shm_0>; > >> ... > >> } > >> } > >> } > >> > >> SCMI "4.2.1.1 Device specific access control" > >> > >> The XEN SCI SCMI SMC multi-agent driver performs "access-controller" > >> provider function in case EL3 SCMI FW implements SCMI "4.2.1.1 Device > >> specific access control" and provides the BASE_SET_DEVICE_PERMISSIONS > >> command to configure the devices that an agents have access to. > >> The DT SCMI node should "#access-controller-cells=<1>" property and DT > >> devices should be bound to the Xen SCMI. > >> > >> &i2c1 { > >> access-controllers = <&scmi 0>; > >> }; > >> > >> The Dom0 and dom0less domains DT devices will be processed > >> automatically through sci_assign_dt_device() call, but to assign SCMI > >> devices from toolstack the xl.cfg:"dtdev" property > >> shall be used: > >> > >> dtdev = [ > >> "/soc/i2c@e6508000", > >> ] > >> > >> xl.cfg:dtdev will contain all nodes which are under SCMI > >> management (not only those which are behind IOMMU). > >> > >> [1]https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > >> [2]https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml > >> > >> Signed-off-by: Grygorii Strashko > >> Signed-off-by: Oleksii Moisieiev > >> --- > >> > >> Changes in v7: > >> - rework scmi nodes for xen to match on compatible string instead of > >> the direct path > >> > >> Changes in v6: > >> - updated scmi-shmem to use io.h from generic location > >> - update scmi_agent_id parameter to be provided inside dom0= parameter > >> list and have the following format "dom0=sci-agent-id=0" > >> This change was done as a response for Stefano comment and > >> requires a lot of code changes, but produces much cleaner solution > >> that's why I've added it to the code. > >> - fix file comments and return codes > >> - fix lenght checks in shmem_{get,put}_message to use offsetof > >> - remove len member from scmi_channel structure as it is not used > >> - set scmi-secondary-agents property to be mandatory since if no > >> secondary agents were provided then there is no sence to enable scmi > >> when no secondary agents are populated to the Domains > >> - update documentation in booting.txt, added xen_scmi node to the > >> example > >> - adjust d->arch.sci_enabled value in scmi_domain_destroy > >> - fix lock management in smc_create_channel call > >> - avoid extra map_channel_memory command for Xen management channel > >> because collect_agent_id call unmaps memory if DOMID_XEN is not > >> set. So for Xen management channel we can init domain_id ad DOMID_XEN > >> before calling collect_agent_id so memory shouldn't be unmapped. > >> > >> Changes in v5: > >> - fix device-tree example format in booting.txt, added ";" after "}". > >> - update define in scmi-proto.h > >> - update define in scmi-shmem.h file > >> - scmi_assign_device - do not ignore -EOPNOTSUPP return > >> code of the do_smc_xfer > >> - remove overwriting agent_channel->agent_id after > >> SCMI_BASE_DISCOVER_AGENT call > >> - add multi-agent files to the MAINTAINERS > >> - add SCMI multi-agent description to the SUPPORT.md > >> - handle ARM_SMCCC_INVALID_PARAMETER return code and return -EINVAL > >> for smc call > >> - updated collect_agents function. Set agent_id parameter as optional > >> in scmi-secondary-agents device-tree property > >> - introduce "#scmi-secondary-agents-cells" parameter to set if > >> agent_id was provided > >> - reanme xen,scmi-secondary-agents property to scmi-secondary-agents > >> - move memcpu_toio/fromio for the generic place > >> - update Xen to get management channel from /chosen/xen,config node > >> - get hypervisor channnel from node instead of using hardcoded > >> - update handling scmi and shmem nodes for the domain > >> - Set multi-agent driver to support only Arm64 > >> > >> Changes in v4: > >> - toolstack comments from Anthony PERARD > >> - added dom0less support > >> - added doc for "xen,scmi-secondary-agents" > >> > >> MAINTAINERS | 4 + > >> SUPPORT.md | 11 + > >> docs/man/xl.cfg.5.pod.in | 13 + > >> docs/misc/arm/device-tree/booting.txt | 103 +++ > >> docs/misc/xen-command-line.pandoc | 19 +- > >> tools/libs/light/libxl_arm.c | 4 + > >> tools/libs/light/libxl_types.idl | 4 +- > >> tools/xl/xl_parse.c | 12 + > >> xen/arch/arm/dom0less-build.c | 11 + > >> xen/arch/arm/domain_build.c | 26 +- > >> xen/arch/arm/firmware/Kconfig | 12 + > >> xen/arch/arm/firmware/Makefile | 1 + > >> xen/arch/arm/firmware/scmi-proto.h | 164 ++++ > >> xen/arch/arm/firmware/scmi-shmem.c | 115 +++ > >> xen/arch/arm/firmware/scmi-shmem.h | 45 ++ > >> xen/arch/arm/firmware/scmi-smc-multiagent.c | 815 ++++++++++++++++++++ > >> xen/include/public/arch-arm.h | 3 + > >> 17 files changed, 1359 insertions(+), 3 deletions(-) > >> create mode 100644 xen/arch/arm/firmware/scmi-proto.h > >> create mode 100644 xen/arch/arm/firmware/scmi-shmem.c > >> create mode 100644 xen/arch/arm/firmware/scmi-shmem.h > >> create mode 100644 xen/arch/arm/firmware/scmi-smc-multiagent.c > >> > >> diff --git a/MAINTAINERS b/MAINTAINERS > >> index ecd3f40df8..4ad1d818a6 100644 > >> --- a/MAINTAINERS > >> +++ b/MAINTAINERS > >> @@ -532,6 +532,10 @@ R: Oleksii Moisieiev > >> S: Supported > >> F: xen/arch/arm/firmware/sci.c > >> F: xen/arch/arm/include/asm/firmware/sci.h > >> +F: xen/arch/arm/firmware/scmi-smc-multiagent.c > >> +F: xen/arch/arm/firmware/scmi-shmem.c > >> +F: xen/arch/arm/firmware/scmi-shmem.h > >> +F: xen/arch/arm/firmware/scmi-proto.h > >> > >> SEABIOS UPSTREAM > >> M: Wei Liu > >> diff --git a/SUPPORT.md b/SUPPORT.md > >> index 491f9ecd1b..7c8951d67b 100644 > >> --- a/SUPPORT.md > >> +++ b/SUPPORT.md > >> @@ -956,6 +956,17 @@ by hwdom. Some platforms use SCMI for access to system-level resources. > >> > >> Status: Supported > >> > >> +### Arm: SCMI SMC multi-agent support > >> + > >> +Enable support for the multi-agent configuration of the EL3 Firmware, which > >> +allows Xen to provide an SCMI interface to the Domains. > >> +Xen manages access permissions to the HW resources and provides an SCMI interface > >> +to the Domains. Each Domain is represented as a separate Agent, which can > >> +communicate with EL3 Firmware using a dedicated shared memory region, and > >> +notifications are passed through by Xen. > >> + > >> + Status, ARM64: Tech Preview > >> + > >> ### ARM: Guest PSCI support > >> > >> Emulated PSCI interface exposed to guests. We support all mandatory > >> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in > >> index ad1553c5e9..4fc3e12939 100644 > >> --- a/docs/man/xl.cfg.5.pod.in > >> +++ b/docs/man/xl.cfg.5.pod.in > >> @@ -3156,8 +3156,21 @@ single SCMI OSPM agent support. > >> Should be used together with B Xen command line > >> option. > >> > >> +=item B > >> + > >> +Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI over > >> +SMC calls forwarding from domain to the EL3 firmware (like Trusted Firmware-A) > >> +with a multi SCMI OSPM agent support. The SCMI B should be > >> +specified for the guest. > >> + > >> =back > >> > >> +=item B > >> + > >> +Specifies a non-zero ARM SCI agent id for the guest. This option is mandatory > >> +if the SCMI SMC support is enabled for the guest. The agent ids of domains > >> +existing on a single host must be unique and in the range [1..255]. > >> + > >> =back > >> > >> =back > >> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt > >> index 977b428608..6fd7e4a16b 100644 > >> --- a/docs/misc/arm/device-tree/booting.txt > >> +++ b/docs/misc/arm/device-tree/booting.txt > >> @@ -322,6 +322,20 @@ with the following properties: > >> Should be used together with scmi-smc-passthrough Xen command line > >> option. > >> > >> + - "scmi_smc_multiagent" > >> + > >> + Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI over > >> + SMC calls forwarding from domain to the EL3 firmware (like ARM > >> + Trusted Firmware-A) with a multi SCMI OSPM agent support. > >> + The SCMI agent_id should be specified for the guest with "xen,sci-agent-id" > >> + property. > >> + > >> +- "xen,sci-agent-id" > >> + > >> + Specifies ARM SCMI agent id for the guest. This option is mandatory if the > >> + SCMI SMC "scmi_smc_multiagent" support is enabled for the guest. The agent ids > >> + of guest must be unique and in the range [0..255]. > > these two don't seem to be in the commit message examples > > > > > ``scmi_smc_multiagent`` mentioned in the commit message at the following > part: > > > - xl.cfg: add configuration option as below > > arm_sci = "type=scmi_smc_multiagent,agent_id=2" > > ``xen,sci-agent-id`` is used for dom0less. It described in arm-scmi.rst > file which was presented in the next commit. All device tree options should be described docs/misc/arm/device-tree/booting.txt, even if they are similar to other options described elsewhere. This is similar to the way all Xen command line options should be described in docs/misc/xen-command-line.pandoc > >> Under the "xen,domain" compatible node, one or more sub-nodes are present > >> for the DomU kernel and ramdisk. > >> > >> @@ -824,3 +838,92 @@ The automatically allocated static shared memory will get mapped at > >> 0x80000000 in DomU1 guest physical address space, and at 0x90000000 in DomU2 > >> guest physical address space. DomU1 is explicitly defined as the owner domain, > >> and DomU2 is the borrower domain. From xen-devel-bounces@lists.xenproject.org Fri Jan 16 23:19:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 23:19:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1207103.1520143 (Exim 4.92) (envelope-from ) id 1vgt6Q-00058p-D7; Fri, 16 Jan 2026 23:19:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1207103.1520143; Fri, 16 Jan 2026 23: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 1vgt6Q-00058i-AU; Fri, 16 Jan 2026 23:19:38 +0000 Received: by outflank-mailman (input) for mailman id 1207103; Fri, 16 Jan 2026 23:19:37 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgt6P-00058c-PJ for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 23:19:37 +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 d0e8d651-f331-11f0-9ccf-f158ae23cfc8; Sat, 17 Jan 2026 00:19:34 +0100 (CET) Received: by mx.zohomail.com with SMTPS id 1768605568308525.6440969563023; Fri, 16 Jan 2026 15:19:28 -0800 (PST) Received: by mail-oi1-f177.google.com with SMTP id 5614622812f47-45c958d48a9so1143183b6e.1 for ; Fri, 16 Jan 2026 15:19:27 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d0e8d651-f331-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; t=1768605570; cv=none; d=zohomail.com; s=zohoarc; b=ecloVruetXAjpq9kp/31ODkpx1zLfPoOP2W89vWSJxQfoF+VkoA9q2/FghISWvQrgnuU0/RROJuWYlgvl/myfRryRpAw43lT5L+X15xJe2xaloVwY1j+w1/9oypgz/UbyFmqONWqMM3Qv0eD96hQeRUbkEHdk6AVkf5cw+X5Ph0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1768605570; 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=p2YteRo9HLg4hO9nC7EOOavXwgX3pSd+0fOVfpkd1Ic=; b=fOB+uvb8cJbaoh1UrBBvLc1L1dy4Ov0Xih/c9ww5bUBgBoff0KmQkRLVu0LE3LPzjQnEpFvwQ4Dv7aucDft9ATpeH2fHfMSypnARvrrKJzL2ymhBBDOZU6fobJUGbxbgJqo4YDCiGwJE42NAO901CpeGpcHd+Uso5n6m8wr0DOo= 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=1768605570; 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=p2YteRo9HLg4hO9nC7EOOavXwgX3pSd+0fOVfpkd1Ic=; b=UK4lipqErXkh3ExmTGve9kN7oHgqI6+sSL6xkGxvDLlU/IXaQf0aQ9W1wD+W0G64 ebtlDBwVrV5Pl6lnQLBkxi3+rph7tLed04UGQhkRKhMHTaCVQEMyUtEry82PYHF48FB 7OLZigJHDdZ4y5gKGgKxx4dlF0mYkyIm26ugFDa8= X-Gm-Message-State: AOJu0YwDFsSQyy6wn8jhlYIHIsMU6w0pZCR0+4DS1xmz4+ozrZgvVtZF JN3u5F8/tC7Mkk/Mtu4+MM2BUur7YAvt1jn/6bvDRbrPwh9sir42J7YBubZoXBN87hpqi+Kvhml zDA9j0SVrBEhujwhCe6kGYIUklgO31hk= X-Received: by 2002:a05:6808:1b1f:b0:450:bc64:d159 with SMTP id 5614622812f47-45c9c11971bmr1950662b6e.54.1768605567013; Fri, 16 Jan 2026 15:19:27 -0800 (PST) MIME-Version: 1.0 References: <20260115092841.2651224-1-Penny.Zheng@amd.com> <20260115092841.2651224-3-Penny.Zheng@amd.com> In-Reply-To: <20260115092841.2651224-3-Penny.Zheng@amd.com> From: Tamas K Lengyel Date: Fri, 16 Jan 2026 18:19:00 -0500 X-Gmail-Original-Message-ID: X-Gm-Features: AZwV_Qim6pJ-PlwFTlssJgpCQPKoBnb_eTYi5BnhK9_K95MPNzxIPWTB6KYiBrY Message-ID: Subject: Re: [PATCH v4 2/6] x86/vm_event: introduce vm_event_is_enabled() To: Penny Zheng Cc: xen-devel@lists.xenproject.org, jason.andryuk@amd.com, ray.huang@amd.com, Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alexandru Isaila , Petre Pircalabu Content-Type: multipart/alternative; boundary="00000000000091da7d064889920a" --00000000000091da7d064889920a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 15, 2026 at 4:29=E2=80=AFAM Penny Zheng w= rote: > 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 unreachable calls/codes, such as hvm_monitor_io(), etc, > when having VM_EVENT=3Dn. > > Signed-off-by: Penny Zheng > Acked-by: Jan Beulich > Reviewed-by: Jason Andryuk Acked-by: Tamas K Lengyel --00000000000091da7d064889920a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 15,= 2026 at 4:29=E2=80=AFAM Penny Zheng <Penny.Zheng@amd.com> wrote:
Function vm_event_is_enabled() is introduced to che= ck if vm event is enabled,
and also make the checking conditional upon CONFIG_VM_EVENT, which could he= lp
DCE a lot unreachable calls/codes, such as hvm_monitor_io(), etc,
when having VM_EVENT=3Dn.

Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>

Acked-by: Tamas K Lengyel <tama= s@tklengyel.com>=C2=A0
--00000000000091da7d064889920a-- From xen-devel-bounces@lists.xenproject.org Fri Jan 16 23:19:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 23:19:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1207107.1520152 (Exim 4.92) (envelope-from ) id 1vgt6l-0005Uo-Nx; Fri, 16 Jan 2026 23:19:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1207107.1520152; Fri, 16 Jan 2026 23:19:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgt6l-0005Uh-LF; Fri, 16 Jan 2026 23:19:59 +0000 Received: by outflank-mailman (input) for mailman id 1207107; Fri, 16 Jan 2026 23:19:58 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vgt6k-00058c-Jz for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 23:19:58 +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 de3e41b6-f331-11f0-9ccf-f158ae23cfc8; Sat, 17 Jan 2026 00:19:56 +0100 (CET) Received: by mx.zohomail.com with SMTPS id 1768605591708468.66365585678; Fri, 16 Jan 2026 15:19:51 -0800 (PST) Received: by mail-oi1-f175.google.com with SMTP id 5614622812f47-45ca0d06eddso754526b6e.2 for ; Fri, 16 Jan 2026 15:19:51 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: de3e41b6-f331-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; t=1768605593; cv=none; d=zohomail.com; s=zohoarc; b=hxpQY7oXVtnBV+MAdIdMnliHaxdqxFHzyaNqldLn1yTTL0ey1bcKuWPy8jxxZai9W5P8Hl9/zl2J8ibb2XP96MNccQD7N2eYL++oCjC+/FdIpBfgv0o++mwnF9HTbmEEzcahqPEXS131uVYxF3thFNkkOo8Q+mY1x+p5fMhsXHA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1768605593; 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=qr25avvDLnDOnm9RWcIZUh3dqPd+LfGVqV0F0VX+7Xs=; b=Jb3e7pbuxjsKvRxMQ91jDwXZ7FNtp/n2bf158pHe2rYUtHXVZhyHbTS0w5UBXhqIttIPfvJfRTVrV4ByA29Eb/vmCNnHOIP2iWS+Mo9j5T33mHUUhTXEeuarsm/WWcq1XRuFC8FpnilR+8CjnK/Gn39H6AO2zX/q3qfEFOwS3Xw= 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=1768605593; 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=qr25avvDLnDOnm9RWcIZUh3dqPd+LfGVqV0F0VX+7Xs=; b=KWhX1+EKH+He+VA+1fCxO6O5xPAiyNMqBqviWHYWEEAthHQw4YWs4i4+yFeogVNk XLNGtajew4sbbxNRDzlVTs4tCzy7N9S0hi1WAlvx906DdDg/LDcUaJs3xE0ipC3ZwVI FP1ZTnqhnOUJVzY8TE8/bQzzZDvDGRVZRPuvNZGk= X-Gm-Message-State: AOJu0YwYHOoPufUeEBQ5+R8yb270FkKSoSNrJdxGaQZZT2844FLTjfJ+ m0867pSEFqUZ9Fh2ubqjAsLhwWazoOPN1V+zEziUfZVucR0RUZqxK4LoZ8J07RLdKMOQJ7v9w3U xnPGAtiqjk2N6M8Kvll5c/S5dhorqAFs= X-Received: by 2002:a05:6808:c2d9:b0:459:98aa:672e with SMTP id 5614622812f47-45c9bf866a0mr1843899b6e.4.1768605585563; Fri, 16 Jan 2026 15:19:45 -0800 (PST) MIME-Version: 1.0 References: <20260115092841.2651224-1-Penny.Zheng@amd.com> <20260115092841.2651224-4-Penny.Zheng@amd.com> In-Reply-To: <20260115092841.2651224-4-Penny.Zheng@amd.com> From: Tamas K Lengyel Date: Fri, 16 Jan 2026 18:19:00 -0500 X-Gmail-Original-Message-ID: X-Gm-Features: AZwV_QhpBcX11oR94k7K1BbsOj961rwAavKNmzwxBVJv0aGo93lZWIYYBsIZkhs Message-ID: Subject: Re: [PATCH v4 3/6] x86/monitor: wrap monitor_op under CONFIG_VM_EVENT To: Penny Zheng Cc: xen-devel@lists.xenproject.org, jason.andryuk@amd.com, ray.huang@amd.com, Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alexandru Isaila , Petre Pircalabu Content-Type: multipart/alternative; boundary="000000000000ace4d40648899375" --000000000000ace4d40648899375 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 15, 2026 at 4:29=E2=80=AFAM Penny Zheng w= rote: > Feature monitor_op is based on vm event subsystem, so monitor.o shall be > wrapped under CONFIG_VM_EVENT. > The following functions are only invoked by monitor-op, so they all shall > be > wrapped with CONFIG_VM_EVENT (otherwise they will become unreachable and > violate Misra rule 2.1 when VM_EVENT=3Dn): > - hvm_enable_msr_interception > - hvm_function_table.enable_msr_interception > - hvm_has_set_descriptor_access_existing > - hvm_function_table.set_descriptor_access_existi > - arch_monitor_get_capabilities > Function monitored_msr() still needs a stub to pass compilation when > VM_EVENT=3Dn. > > Signed-off-by: Penny Zheng > Acked-by: Jan Beulich > Reviewed-by: Jason Andryuk Acked-by: Tamas K Lengyel --000000000000ace4d40648899375 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 15,= 2026 at 4:29=E2=80=AFAM Penny Zheng <Penny.Zheng@amd.com> wrote:
Feature monitor_op is based on vm event subsystem, = so monitor.o shall be
wrapped under CONFIG_VM_EVENT.
The following functions are only invoked by monitor-op, so they all shall b= e
wrapped with CONFIG_VM_EVENT (otherwise they will become unreachable and violate Misra rule 2.1 when VM_EVENT=3Dn):
- hvm_enable_msr_interception
=C2=A0 - hvm_function_table.enable_msr_interception
- hvm_has_set_descriptor_access_existing
=C2=A0 - hvm_function_table.set_descriptor_access_existi
- arch_monitor_get_capabilities
Function monitored_msr() still needs a stub to pass compilation when
VM_EVENT=3Dn.

Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>

Acked-by: Tamas K Lengyel <tama= s@tklengyel.com>=C2=A0
--000000000000ace4d40648899375-- From xen-devel-bounces@lists.xenproject.org Fri Jan 16 23:20:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 16 Jan 2026 23:20:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1207124.1520162 (Exim 4.92) (envelope-from ) id 1vgt7f-00075v-1h; Fri, 16 Jan 2026 23:20:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1207124.1520162; Fri, 16 Jan 2026 23: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 1vgt7e-00075o-Uv; Fri, 16 Jan 2026 23:20:54 +0000 Received: by outflank-mailman (input) for mailman id 1207124; Fri, 16 Jan 2026 23: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 1vgt7e-0005RK-1r for xen-devel@lists.xenproject.org; Fri, 16 Jan 2026 23:20:54 +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 ff744436-f331-11f0-b15e-2bf370ae4941; Sat, 17 Jan 2026 00:20:52 +0100 (CET) Received: by mx.zohomail.com with SMTPS id 1768605648057100.37824651156598; Fri, 16 Jan 2026 15:20:48 -0800 (PST) Received: by mail-oo1-f47.google.com with SMTP id 006d021491bc7-65f66d72b3fso1718726eaf.3 for ; Fri, 16 Jan 2026 15:20:47 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ff744436-f331-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; t=1768605649; cv=none; d=zohomail.com; s=zohoarc; b=Un8is00hNzVntpxcDK4/ddu+5be/GO5xL2T3YfGmhwK0J1hAHmUZn4exi5V516ocbBK66Q0K5ZJy34+sSGqBozD0vXm/IJUdL4/tzTnqtGsfAXmM/2kd0hzvToZU85uyCVouUWBs5+mC5RFVelRx4GiYttaZdd/c/YhE6k5Spog= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1768605649; 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=TKtiMH8oBdrfkRfa3Gcqh/WpBKYSshT5TbDes+EMBp0=; b=DxHsd30+UCmB5fQFmKOD0cyOe2kqXDkvsd3aNDuUzSVLm9KzrHQrLPfUpf0HnoV4I04Ra5C8d9Peu/edIvZuLKvhj6nidC3Y0gs3BYy+8xKKEdvNXRlh7X0w5/3TwWMHuJVzIDMX9j9uq0QRNKjgtP/IVumHjU+jWT35vmap0nk= 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=1768605649; 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=TKtiMH8oBdrfkRfa3Gcqh/WpBKYSshT5TbDes+EMBp0=; b=PE96VqBV9EdMdNAto5TGq+lpilsaUFi4pmmmF5OCrctHTa5LPIxlTc+H16cpu87p nUIE+HKFmQld+OSPqswfgyWUkPavVVGAgU95TAQdc5eFrNfYrwFzH8YZBDXVZBGuBDX OWFnIl4ThCmsDxmA0RlXu6F1AZOwEMHpwLvI0S5o= X-Forwarded-Encrypted: i=1; AJvYcCXKDVvd2r4IkxmMnEIIezmui9LSW2e51ZaNDxSrN02SKyrZx/zyJu9xZoq55P1mBD0XD+NitEYJ6oA=@lists.xenproject.org X-Gm-Message-State: AOJu0YyZx/+xtwgh8Aph6n9z5bp4xDaPy2/quvuiroSOwjBGVn2dUFPU dbHAhpPxftD1wph30SpGbYGTBSbtkzI1InIA3z01JYoZBmkkrXMyRW/2+g2m4FVQKePz9JQnipj RRpP6LTDAe31yTVVZesHi2MQe1KliKTM= X-Received: by 2002:a05:6820:1c97:b0:659:9a49:904d with SMTP id 006d021491bc7-6611795a29cmr1849712eaf.24.1768605647446; Fri, 16 Jan 2026 15:20:47 -0800 (PST) MIME-Version: 1.0 References: <20260115092841.2651224-1-Penny.Zheng@amd.com> <20260115092841.2651224-6-Penny.Zheng@amd.com> <84943630-0f68-4097-a5a4-4aba17c0fb86@amd.com> In-Reply-To: <84943630-0f68-4097-a5a4-4aba17c0fb86@amd.com> From: Tamas K Lengyel Date: Fri, 16 Jan 2026 18:19:00 -0500 X-Gmail-Original-Message-ID: X-Gm-Features: AZwV_QjIVHKJlvK2mzsmXj03m5Q7EZzX2_PGu0SBNmdrc9rM8GVfPhFFaWzy13Y Message-ID: Subject: Re: [PATCH v4 5/6] xen/mem_access: wrap memory access when VM_EVENT=n To: Jason Andryuk Cc: Penny Zheng , xen-devel@lists.xenproject.org, ray.huang@amd.com, Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alexandru Isaila , Petre Pircalabu Content-Type: multipart/alternative; boundary="0000000000005d2994064889977b" --0000000000005d2994064889977b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 15, 2026 at 10:21=E2=80=AFAM Jason Andryuk wrote: > On 2026-01-15 04:28, Penny Zheng wrote: > > Feature memory access is based on vm event subsystem, and it could be > disabled > > in the future. So a few switch-blocks in do_altp2m_op() need > > vm_event_is_enabled() condition check to pass compilation when ALTP2M= =3Dy > and > > VM_EVENT=3Dn(, hence MEM_ACCESS=3Dn), like HVMOP_altp2m_set_mem_access,= etc. > > Function p2m_mem_access_check() still needs stub when VM_EVENT=3Dn to > > pass compilation. > > Although local variable "req_ptr" still remains NULL throughout its > lifetime, > > with the change of NULL assignment, we will face runtime undefined erro= r > only > > when CONFIG_USBAN is on. So we strengthen the condition check via addin= g > > vm_event_is_enabled() for the special case. > > > > Signed-off-by: Penny Zheng > > Acked-by: Jan Beulich > > Reviewed-by: Jason Andryuk > Acked-by: Tamas K Lengyel --0000000000005d2994064889977b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 15,= 2026 at 10:21=E2=80=AFAM Jason Andryuk <jason.andryuk@amd.com> wrote:
On 2026-01-15 04:28, Penny Zheng wrote: > Feature memory access is based on vm event subsystem, and it could be = disabled
> in the future. So a few switch-blocks in do_altp2m_op() need
> vm_event_is_enabled() condition check to pass compilation when ALTP2M= =3Dy and
> VM_EVENT=3Dn(, hence MEM_ACCESS=3Dn), like HVMOP_altp2m_set_mem_access= , etc.
> Function p2m_mem_access_check() still needs stub when VM_EVENT=3Dn to<= br> > pass compilation.
> Although local variable "req_ptr" still remains NULL through= out its lifetime,
> with the change of NULL assignment, we will face runtime undefined err= or only
> when CONFIG_USBAN is on. So we strengthen the condition check via addi= ng
> vm_event_is_enabled() for the special case.
>
> Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>

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

Acked-by: Tamas K Lengyel <= tamas@tklengyel.com>=C2=A0
--0000000000005d2994064889977b-- From xen-devel-bounces@lists.xenproject.org Sun Jan 18 13:34:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 18 Jan 2026 13:34:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1207810.1520184 (Exim 4.92) (envelope-from ) id 1vhSum-000412-Qy; Sun, 18 Jan 2026 13:34:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1207810.1520184; Sun, 18 Jan 2026 13: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 1vhSum-00040c-Lc; Sun, 18 Jan 2026 13:34:00 +0000 Received: by outflank-mailman (input) for mailman id 1207810; Sun, 18 Jan 2026 13:33:59 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhSul-0003p9-9D for xen-devel@lists.xenproject.org; Sun, 18 Jan 2026 13:33:59 +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 56ee9b0d-f472-11f0-9ccf-f158ae23cfc8; Sun, 18 Jan 2026 14:33:57 +0100 (CET) Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-64b791b5584so6306435a12.0 for ; Sun, 18 Jan 2026 05:33:57 -0800 (PST) Received: from PKL-HASEEBA-LT.. ([39.37.230.99]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-65452cdab55sm7683163a12.10.2026.01.18.05.33.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 Jan 2026 05:33:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 56ee9b0d-f472-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768743236; x=1769348036; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=uPY8I9p89Z49IT6xTWbbfssEr8lHB6MKrNil8DAb3PU=; b=NDD1a9NB7ZddUhD27a/4ROju+s+t3/LUbmUYxSAr4uQYbF27d6gWCwGj9oOmLq1RZw L0dmhtmA17XXSOrMMR3DzAi3xHF4CH4gRy5G8ZC9z+KkQctKA/CiXFAfEWs3j9ieV8Mh lmOyAQEbuoVmY7/jR7Z6MCjueYA9nA1kJ0vWdNLmswjGHBbLCiHZ19jTJEDE6JSf05FD kXGFTieM4JI+ykVWQWLli79ImjD/arTuzk0+M02LGE4/mLJ6ZohVqnZiN47oPwcwn7p2 6gO5qxkIfA5wDspP4SYev+ofh5C4C8SfqOPigJVMvyDUkyAnwlDlM/xjXRYyMWgmZZ/R vh9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768743236; x=1769348036; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=uPY8I9p89Z49IT6xTWbbfssEr8lHB6MKrNil8DAb3PU=; b=cKaFBUseg/ztZYaYUVX5rhzaCjJL8Dz3Eagbjyt7ONRQqeU3QwQIMAVSxnfxifjmZq u+VWRySCqnRl50+yzsfa7kZemNLp3ibz3u1RjbAXhFzoAA5nWpJbFaEtUxwzyoYEwRyV 9D7lbz5xN3DPP/2XclU0uQ7miVccs3bZ/NtKoBaEeLmfnr4aoyrXMJVvIX0PihYAUS0y OnZ6Sql/lslAGy1rmEwRhNRTtWthQD85X5QFmbrgpXAygywgLBaUVsijXdCe9RxodmZb nWfkUX8rV0aADvg2MvlpaZXj9ifPG6bJznEyNoazHEeowx1mmJ3sDZwWhYgaPnrDkEly 79gg== X-Gm-Message-State: AOJu0YzwXSUOGYXcoLjdJzGg+XOz1HNhwn9eYHCzL1Ro5I/H91w4roa4 vDNp+cN5U/L8ifv9xt1Ve0UhUZHi0e9uYjyCeZDMrsh5bb/7M+2DMllrodGlgA== X-Gm-Gg: AY/fxX49T1Cr6IyLUzOtEavKvatDxqdDJsZYXgBN7D81hDQdkLLOvsyFU9d8NffKrXZ eEWm+FUJUZJNFwIgbNAl2UL/dQYbQZEzX04Gr1kUo2P1Ly5m66mBTUSi+4wCnWNQkIze9R/BWwp MeoU44K1e6Jnc9lkHHt0jjx0w/nceMg7LI3MkkbIX4u/meGqMyJkEb53z8c3gsqvvYOOBwcThLG 9mrsdt4whlBGRklk9xIUlDy5tIGnpUxS2UrEqTcFiJiZ2Xox1Xg82Ofg0OLBz89OuakJ3mpuBFJ a9yoL0vdhPLODlD4vay7PqEJiWu6Y/2JlE/mZcb3t8yjC7DwE2xfPobVz2Y4kbDe576zAXlVHbA vUn4jWWGlPsC1NeNmAXAw0OrcWUpIHQBHBIztgfYrSq5hbzZBvwTNw9GGrBDNFNW1FBSACyVP9q eAaLT4sEuhalnEnh984dMe6BJtbn+vMAi5kNMV1H6+cAwxfCn3nA== X-Received: by 2002:a05:6402:4302:b0:64d:498b:aee7 with SMTP id 4fb4d7f45d1cf-654b955d7ecmr6277959a12.9.1768743236042; Sun, 18 Jan 2026 05:33:56 -0800 (PST) From: Haseeb Ashraf To: xen-devel@lists.xenproject.org Cc: Haseeb Ashraf , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [XEN PATCH v3 1/3] xen/arm/p2m: perform IPA-based TLBI when IPA is known Date: Sun, 18 Jan 2026 18:33:27 +0500 Message-ID: X-Mailer: git-send-email 2.43.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Haseeb Ashraf This commit addresses a major issue for running Xen on KVM i.e. costly emulation of VMALLS12E1IS which becomes worse when this TLBI is invoked too many times. There are mainly two places where this is problematic: (a) When vCPUs switch on a pCPU or pCPUs (b) When domu mapped pages onto dom0, are to be unmapped, then each page being removed by XENMEM_remove_from_physmap has its TLBs invalidated by VMALLS12E1IS. The first one is addressed by relaxing VMALLS12E1 -> VMALLE1 as the stage-2 is common between all the vCPUs of a VM. Since each CPU has its own private TLBs, so flush between vCPU of the same domains is still required to avoid translations from vCPUx to "leak" to the vCPUy which can be achieved by using VMALLE1. The second one is addressed by using IPA-based TLBI (IPAS2E1) in combination with VMALLE1 whenever the IPA range is known instead of using VMALLS12E1. There is an upper cap placed on number of IPA-based TLBI. This factor for execution time of VMALLS12E1 vs IPAS2E1 is found to be 70K on Graviton4 in Xen on KVM virtualization. So, 64K * 4KB = 256MB is set as the threshold. For arm32, TLBIALL instruction can invalidate both stage-1 and stage-2 entries, so using IPA-based TLBI would be redundant as TLBIALL is required in any case to invalidate corresponding cached entries from stage-1. Suggested-by: Julien Grall Signed-off-by: Haseeb Ashraf Changes in v3: - Updated IPA-based TLBI sequence to apply ARM64 repeat TLBI workaround to only final TLBI and DSB of the sequence. - Removed TLB_HELPER_IPA and instead directly used the TLBI instruction where needed as that was the only instance where it is being used. - Removed flush_guest_tlb_range_ipa_local() as it was not being used. - Updated comments as per feedback in v2 about holding lock before p2m_load_vttbr. - Updated references of ARM ARM to use newer version DDI 0487L.b instead of older version DDI 0487A.e. Changes in v2: - This commit implements the basline implementation to address the problem at hand. Removed the FEAT_nTLBPA implementation from this commit which will be implemented in following commit using CPU capability. - Moved ARM32 and ARM64 specific implementations of TLBIs to architecture specific flushtlb.h. - Added references of ARM ARM in code comments. - Evaluated and added a threshold to select between IPA-based TLB invalidation vs fallback to full stage TLB invalidation above the threshold. --- xen/arch/arm/include/asm/arm32/flushtlb.h | 53 +++++++++++++ xen/arch/arm/include/asm/arm64/flushtlb.h | 46 ++++++++++++ xen/arch/arm/include/asm/mmu/p2m.h | 2 + xen/arch/arm/mmu/p2m.c | 92 +++++++++++++++++------ 4 files changed, 168 insertions(+), 25 deletions(-) diff --git a/xen/arch/arm/include/asm/arm32/flushtlb.h b/xen/arch/arm/include/asm/arm32/flushtlb.h index 61c25a3189..3c0c2123d4 100644 --- a/xen/arch/arm/include/asm/arm32/flushtlb.h +++ b/xen/arch/arm/include/asm/arm32/flushtlb.h @@ -45,6 +45,43 @@ TLB_HELPER(flush_xen_tlb_local, TLBIALLH, nsh) #undef TLB_HELPER +/* + * Flush TLB of local processor. Use when flush for only stage-1 is intended. + * + * The following function should be used where intention is to clear only + * stage-1 TLBs. This would be helpful in future in identifying which stage-1 + * TLB flushes can be skipped such as in present of FEAT_nTLBPA. + */ +static inline void flush_guest_tlb_s1_local(void) +{ + /* + * Same instruction can invalidate both stage-1 and stage-2 TLBs depending + * upon the execution context. + * + * See ARMv8 (DDI 0487L.b): G5-11698 Table G5-23. + */ + return flush_guest_tlb_local(); +} + +/* + * Flush TLB of inner-shareable processor domain. Use when flush for only + * stage-1 is intended. + * + * The following function should be used where intention is to clear only + * stage-1 TLBs. This would be helpful in future in identifying which stage-1 + * TLB flushes can be skipped such as in present of FEAT_nTLBPA. + */ +static inline void flush_guest_tlb_s1(void) +{ + /* + * Same instruction can invalidate both stage-1 and stage-2 TLBs depending + * upon the execution context. + * + * See ARMv8 (DDI 0487L.b): G5-11698 Table G5-23. + */ + return flush_guest_tlb(); +} + /* Flush TLB of local processor for address va. */ static inline void __flush_xen_tlb_one_local(vaddr_t va) { @@ -57,6 +94,22 @@ static inline void __flush_xen_tlb_one(vaddr_t va) asm volatile(STORE_CP32(0, TLBIMVAHIS) : : "r" (va) : "memory"); } +/* + * Flush a range of IPA's mappings from the TLB of all processors in the + * inner-shareable domain. + */ +static inline void flush_guest_tlb_range_ipa(paddr_t ipa, + unsigned long size) +{ + /* + * Following can invalidate both stage-1 and stage-2 TLBs depending upon + * the execution mode. + * + * See ARMv8 (DDI 0487L.b): G5-11698 Table G5-23. + */ + flush_guest_tlb(); +} + #endif /* __ASM_ARM_ARM32_FLUSHTLB_H__ */ /* * Local variables: diff --git a/xen/arch/arm/include/asm/arm64/flushtlb.h b/xen/arch/arm/include/asm/arm64/flushtlb.h index 3b99c11b50..67ae616993 100644 --- a/xen/arch/arm/include/asm/arm64/flushtlb.h +++ b/xen/arch/arm/include/asm/arm64/flushtlb.h @@ -1,6 +1,8 @@ #ifndef __ASM_ARM_ARM64_FLUSHTLB_H__ #define __ASM_ARM_ARM64_FLUSHTLB_H__ +#include /* For SZ_* macros. */ + /* * Every invalidation operation use the following patterns: * @@ -72,6 +74,12 @@ TLB_HELPER(flush_guest_tlb_local, vmalls12e1, nsh) /* Flush innershareable TLBs, current VMID only */ TLB_HELPER(flush_guest_tlb, vmalls12e1is, ish) +/* Flush local TLBs, current VMID, stage-1 only */ +TLB_HELPER(flush_guest_tlb_s1_local, vmalle1, nsh) + +/* Flush innershareable TLBs, current VMID, stage-1 only */ +TLB_HELPER(flush_guest_tlb_s1, vmalle1is, ish) + /* Flush local TLBs, all VMIDs, non-hypervisor mode */ TLB_HELPER(flush_all_guests_tlb_local, alle1, nsh) @@ -90,6 +98,44 @@ TLB_HELPER_VA(__flush_xen_tlb_one, vae2is) #undef TLB_HELPER #undef TLB_HELPER_VA +/* + * Flush a range of IPA's mappings from the TLB of all processors in the + * inner-shareable domain. + */ +static inline void flush_guest_tlb_range_ipa(paddr_t ipa, unsigned long size) +{ + paddr_t end; + + /* + * If IPA range is too big (empirically found to be 256M), then fallback to + * full TLB flush. + */ + if ( size > SZ_256M ) + return flush_guest_tlb(); + + end = ipa + size; + + /* + * See ARM ARM DDI 0487L.b D8.17.6.1 (Invalidating TLB entries from stage 2 + * translations) for details of TLBI sequence. + */ + dsb(ishst); /* Ensure prior page-tables updates have completed */ + while ( ipa < end ) + { + /* Flush stage-2 TLBs for ipa address */ + asm_inline volatile ( + "tlbi ipas2e1is, %0;" : : "r" (ipa >> PAGE_SHIFT) : "memory" ); + ipa += PAGE_SIZE; + } + /* + * As ARM64_WORKAROUND_REPEAT_TLBI is required to be applied to last TLBI + * of the sequence, it is only needed to be handled in the following + * invocation. Final dsb() and isb() are also applied in the following + * invocation. + */ + flush_guest_tlb_s1(); +} + #endif /* __ASM_ARM_ARM64_FLUSHTLB_H__ */ /* * Local variables: diff --git a/xen/arch/arm/include/asm/mmu/p2m.h b/xen/arch/arm/include/asm/mmu/p2m.h index 58496c0b09..8a16722b82 100644 --- a/xen/arch/arm/include/asm/mmu/p2m.h +++ b/xen/arch/arm/include/asm/mmu/p2m.h @@ -10,6 +10,8 @@ extern unsigned int p2m_root_level; struct p2m_domain; void p2m_force_tlb_flush_sync(struct p2m_domain *p2m); +void p2m_force_tlb_flush_range_sync(struct p2m_domain *p2m, uint64_t start_ipa, + uint64_t page_count); void p2m_tlb_flush_sync(struct p2m_domain *p2m); void p2m_clear_root_pages(struct p2m_domain *p2m); diff --git a/xen/arch/arm/mmu/p2m.c b/xen/arch/arm/mmu/p2m.c index 51abf3504f..eec59056fa 100644 --- a/xen/arch/arm/mmu/p2m.c +++ b/xen/arch/arm/mmu/p2m.c @@ -235,33 +235,28 @@ void p2m_restore_state(struct vcpu *n) * when running multiple vCPU of the same domain on a single pCPU. */ if ( *last_vcpu_ran != INVALID_VCPU_ID && *last_vcpu_ran != n->vcpu_id ) - flush_guest_tlb_local(); + flush_guest_tlb_s1_local(); *last_vcpu_ran = n->vcpu_id; } /* - * Force a synchronous P2M TLB flush. + * Loads VTTBR from given P2M. * * Must be called with the p2m lock held. + * + * This returns switched out VTTBR. */ -void p2m_force_tlb_flush_sync(struct p2m_domain *p2m) +static uint64_t p2m_load_vttbr(struct p2m_domain *p2m, unsigned long *flags) { - unsigned long flags = 0; uint64_t ovttbr; - ASSERT(p2m_is_write_locked(p2m)); - - /* - * ARM only provides an instruction to flush TLBs for the current - * VMID. So switch to the VTTBR of a given P2M if different. - */ ovttbr = READ_SYSREG64(VTTBR_EL2); if ( ovttbr != p2m->vttbr ) { uint64_t vttbr; - local_irq_save(flags); + local_irq_save(*flags); /* * ARM64_WORKAROUND_AT_SPECULATE: We need to stop AT to allocate @@ -280,8 +275,14 @@ void p2m_force_tlb_flush_sync(struct p2m_domain *p2m) isb(); } - flush_guest_tlb(); + return ovttbr; +} +/* + * Restores VTTBR which was switched out as a result of p2m_load_vttbr(). + */ +static void p2m_restore_vttbr(uint64_t ovttbr, unsigned long flags) +{ if ( ovttbr != READ_SYSREG64(VTTBR_EL2) ) { WRITE_SYSREG64(ovttbr, VTTBR_EL2); @@ -289,10 +290,58 @@ void p2m_force_tlb_flush_sync(struct p2m_domain *p2m) isb(); local_irq_restore(flags); } +} + +/* + * Force a synchronous P2M TLB flush. + * + * Must be called with the p2m lock held. + */ +void p2m_force_tlb_flush_sync(struct p2m_domain *p2m) +{ + unsigned long flags = 0; + uint64_t ovttbr; + + ASSERT(p2m_is_write_locked(p2m)); + + /* + * ARM only provides an instruction to flush TLBs for the current + * VMID. So switch to the VTTBR of a given P2M if different. + */ + ovttbr = p2m_load_vttbr(p2m, &flags); + + flush_guest_tlb(); + + p2m_restore_vttbr(ovttbr, flags); p2m->need_flush = false; } +/* + * Force a synchronous P2M TLB flush on a range of addresses. + * + * Must be called with the p2m lock held. + */ +void p2m_force_tlb_flush_range_sync(struct p2m_domain *p2m, uint64_t start_ipa, + uint64_t page_count) +{ + unsigned long flags = 0; + uint64_t ovttbr; + + ASSERT(p2m_is_write_locked(p2m)); + + /* + * ARM only provides an instruction to flush TLBs for the current + * VMID. So switch to the VTTBR of a given P2M if different. + */ + ovttbr = p2m_load_vttbr(p2m, &flags); + + /* Invalidate TLB entries by IPA range */ + flush_guest_tlb_range_ipa(start_ipa, PAGE_SIZE * page_count); + + p2m_restore_vttbr(ovttbr, flags); +} + void p2m_tlb_flush_sync(struct p2m_domain *p2m) { if ( p2m->need_flush ) @@ -1034,7 +1083,8 @@ static int __p2m_set_entry(struct p2m_domain *p2m, * For more details see (D4.7.1 in ARM DDI 0487A.j). */ p2m_remove_pte(entry, p2m->clean_pte); - p2m_force_tlb_flush_sync(p2m); + p2m_force_tlb_flush_range_sync(p2m, gfn_x(sgfn) << PAGE_SHIFT, + 1UL << page_order); p2m_write_pte(entry, split_pte, p2m->clean_pte); @@ -1090,8 +1140,8 @@ static int __p2m_set_entry(struct p2m_domain *p2m, p2m_remove_pte(entry, p2m->clean_pte); if ( removing_mapping ) - /* Flush can be deferred if the entry is removed */ - p2m->need_flush |= !!lpae_is_valid(orig_pte); + p2m_force_tlb_flush_range_sync(p2m, gfn_x(sgfn) << PAGE_SHIFT, + 1UL << page_order); else { lpae_t pte = mfn_to_p2m_entry(smfn, t, a); @@ -1102,18 +1152,10 @@ static int __p2m_set_entry(struct p2m_domain *p2m, /* * It is necessary to flush the TLB before writing the new entry * to keep coherency when the previous entry was valid. - * - * Although, it could be defered when only the permissions are - * changed (e.g in case of memaccess). */ if ( lpae_is_valid(orig_pte) ) - { - if ( likely(!p2m->mem_access_enabled) || - P2M_CLEAR_PERM(pte) != P2M_CLEAR_PERM(orig_pte) ) - p2m_force_tlb_flush_sync(p2m); - else - p2m->need_flush = true; - } + p2m_force_tlb_flush_range_sync(p2m, gfn_x(sgfn) << PAGE_SHIFT, + 1UL << page_order); else if ( !p2m_is_valid(orig_pte) ) /* new mapping */ p2m->stats.mappings[level]++; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Sun Jan 18 13:34:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 18 Jan 2026 13:34:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1207811.1520193 (Exim 4.92) (envelope-from ) id 1vhSut-0004Hq-0v; Sun, 18 Jan 2026 13:34:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1207811.1520193; Sun, 18 Jan 2026 13:34:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhSus-0004Hj-TV; Sun, 18 Jan 2026 13:34:06 +0000 Received: by outflank-mailman (input) for mailman id 1207811; Sun, 18 Jan 2026 13:34:05 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhSuq-0004Go-W8 for xen-devel@lists.xenproject.org; Sun, 18 Jan 2026 13:34:05 +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 5af29eb3-f472-11f0-b15e-2bf370ae4941; Sun, 18 Jan 2026 14:34:03 +0100 (CET) Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-64b9dfc146fso6061917a12.0 for ; Sun, 18 Jan 2026 05:34:03 -0800 (PST) Received: from PKL-HASEEBA-LT.. ([39.37.230.99]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-65452cdab55sm7683163a12.10.2026.01.18.05.33.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 Jan 2026 05:34:01 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5af29eb3-f472-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768743243; x=1769348043; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=89jrADcfTNLToqirJ07l6LVFLAbwHAWxMw55ZpCsj8k=; b=lprYvOXYC4muJ5dJqgLAPXEC52gi8ailH9mILb97MocHJ8JiWFErPUohLbNLiUV5ri R+7Kvy5HJp9iAD33QOIzfPC6hMz8ALKBlQujBKmreSZ7IgFNdDUJJqie2pS8EsjcjMox XhW4UHMITPeAjZDLC/3K1bQixiwF20/Yy8kMLMBMfwtWb3SmjqqRHdfZOk4glasAIEf9 a2uqyL/Z56o/73/s0XaeDx2okyZoxQkkukRXIeVABs96QRX1UwemgaBlPxniQaNvCBHt 6IFgABa8nJNRK1FSfD0pvrL/aaWe5FTDuC55Qz/HfUqFuhgNW5xrC/Xiy1F4CYOSlhBU odIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768743243; x=1769348043; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=89jrADcfTNLToqirJ07l6LVFLAbwHAWxMw55ZpCsj8k=; b=ihvtDU7X2FoW68yXoKe6iWn977E4ndgG0MMMsGT9zHKLHAk2LwMuIhtfylm42GcCY6 EgA+TSgLf2jdX8nMATWLSeruSfvlidT6U6RlLbb5Nn6TvcCFO0ZeTxJlPLJbORZIiK/g Z0DPJpOHYNRvBQrOhYJWjgFg33O+AAHxz7K0xTB6yQGUY2Ms8d+/UvT0muNsMrHcyM+M TT6E+j++BKzGVcQ4c3AS651jtWtdSkTgPG03HuzxPp9EzJi2R/wG4zOvYAS0HsVSoqrd VokS6Wr8sGh5jjlWB9iP06oOTmMhtpgUSe0g0zz5V2u+l4lMJeXGJSskzB6FW8DjYd/i SHPg== X-Gm-Message-State: AOJu0YwqGWLqXbI7rlVkz65BuahSGo/tUKI+0qLCO9kcwIZ9sUYBVFge BRY2NYTL0LHsrcQ6q+QY06P7dgGS76ClixcGQL8dJM+G7LQ7i9BrPUJJiq34gA== X-Gm-Gg: AY/fxX5NN5Dz5eeJGj0NSLZyUILmH1GYXfXar06NVNZWJ0tqVKQAJTNTT0XiT/sRiLH nLwo0gZsy19mnBIDh24mh/nKYvlqGLPXK6sU5BRWLPGzA4+XjdhDN/VeGsmA50cSr4p7X1CHx63 JRzkYgDNmki91DPY/jWEZbFQlR5+kNC0eKYZ1V8SpImTcDZjJHqAY1igkjPiyyTMWqno2iVl6fG tuPmKUaVxQ1Y6tDW4//viCVlCrdqJL+yvb+p8GndZzCnqx4TS6DYqr9eSQzdMuyDfF4iSX/gHkZ QersfpiRSCXlyeoQViTMSSkCE0ZPM9EOI8jedi+TZ+90ZhrzOypgeDVa7mU5UWvTkMnDMaiy21+ tjEivSIHz4bpDXrKQlmFwDv0WOOQNkfVc5p14yZKCQLAa6u9SJt4WwH2eEYTG7hstJEuRSJGb8/ Hf7J4GTOKKsOSV0k3DkbBnEDBBGJm18MAGEZlufFpM3BTqn20G8w== X-Received: by 2002:a05:6402:35c3:b0:64d:4149:4924 with SMTP id 4fb4d7f45d1cf-654529cf529mr7345067a12.4.1768743242629; Sun, 18 Jan 2026 05:34:02 -0800 (PST) From: Haseeb Ashraf To: xen-devel@lists.xenproject.org Cc: Haseeb Ashraf , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Mohamed Mediouni Subject: [XEN PATCH v3 2/3] xen/arm: optimize stage-1,2 combined TLBI in presence of FEAT_nTLBPA Date: Sun, 18 Jan 2026 18:33:28 +0500 Message-ID: <025aae317ebfbb234554be7621fd38fcad08a0c7.1765197209.git.haseeb.ashraf@siemens.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Haseeb Ashraf FEAT_nTLBPA (quoting definition) introduces a mechanism to identify if the intermediate caching of translation table walks does not include non-coherent caches of previous valid translation table entries since the last completed TLBI applicable to the PE. As there won't be any non-coherent caches since the last completed TLBI, stage-1 TLBI won't be required while performing stage-2 TLBI. This feature is optionally available in both arm32 and arm64. Suggested-by: Mohamed Mediouni Signed-off-by: Haseeb Ashraf Changes in v3: - This commit has no functional change in v3, only rebasing changes due to updates in commit-1. Changes in v2: - This commit is implemented in v2 and is splitted from commit-1 in v1. This is implemented by using CPU capability. --- xen/arch/arm/cpufeature.c | 19 ++++++ xen/arch/arm/include/asm/arm32/flushtlb.h | 14 +++-- xen/arch/arm/include/asm/arm64/flushtlb.h | 77 ++++++++++++++++------- xen/arch/arm/include/asm/cpufeature.h | 24 ++++++- xen/arch/arm/include/asm/processor.h | 7 +++ 5 files changed, 109 insertions(+), 32 deletions(-) diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c index 1a80738571..9fa1c45869 100644 --- a/xen/arch/arm/cpufeature.c +++ b/xen/arch/arm/cpufeature.c @@ -17,7 +17,19 @@ DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS); struct cpuinfo_arm __read_mostly domain_cpuinfo; +#ifdef CONFIG_ARM_32 +static bool has_ntlbpa(const struct arm_cpu_capabilities *entry) +{ + return system_cpuinfo.mm32.ntlbpa == MM32_NTLBPA_SUPPORT_IMP; +} +#endif + #ifdef CONFIG_ARM_64 +static bool has_ntlbpa(const struct arm_cpu_capabilities *entry) +{ + return system_cpuinfo.mm64.ntlbpa == MM64_NTLBPA_SUPPORT_IMP; +} + static bool has_sb_instruction(const struct arm_cpu_capabilities *entry) { return system_cpuinfo.isa64.sb; @@ -25,6 +37,13 @@ static bool has_sb_instruction(const struct arm_cpu_capabilities *entry) #endif static const struct arm_cpu_capabilities arm_features[] = { +#if defined(CONFIG_ARM_32) || defined(CONFIG_ARM_64) + { + .desc = "Intermediate caching of translation table walks (nTLBPA)", + .capability = ARM_HAS_NTLBPA, + .matches = has_ntlbpa, + }, +#endif #ifdef CONFIG_ARM_64 { .desc = "Speculation barrier instruction (SB)", diff --git a/xen/arch/arm/include/asm/arm32/flushtlb.h b/xen/arch/arm/include/asm/arm32/flushtlb.h index 3c0c2123d4..7cff042508 100644 --- a/xen/arch/arm/include/asm/arm32/flushtlb.h +++ b/xen/arch/arm/include/asm/arm32/flushtlb.h @@ -49,8 +49,8 @@ TLB_HELPER(flush_xen_tlb_local, TLBIALLH, nsh) * Flush TLB of local processor. Use when flush for only stage-1 is intended. * * The following function should be used where intention is to clear only - * stage-1 TLBs. This would be helpful in future in identifying which stage-1 - * TLB flushes can be skipped such as in present of FEAT_nTLBPA. + * stage-1 TLBs. This would be helpful in identifying which stage-1 TLB flushes + * can be skipped such as in present of FEAT_nTLBPA. */ static inline void flush_guest_tlb_s1_local(void) { @@ -60,7 +60,8 @@ static inline void flush_guest_tlb_s1_local(void) * * See ARMv8 (DDI 0487L.b): G5-11698 Table G5-23. */ - return flush_guest_tlb_local(); + if ( !cpus_have_const_cap(ARM_HAS_NTLBPA) ) + flush_guest_tlb_local(); } /* @@ -68,8 +69,8 @@ static inline void flush_guest_tlb_s1_local(void) * stage-1 is intended. * * The following function should be used where intention is to clear only - * stage-1 TLBs. This would be helpful in future in identifying which stage-1 - * TLB flushes can be skipped such as in present of FEAT_nTLBPA. + * stage-1 TLBs. This would be helpful in identifying which stage-1 TLB flushes + * can be skipped such as in present of FEAT_nTLBPA. */ static inline void flush_guest_tlb_s1(void) { @@ -79,7 +80,8 @@ static inline void flush_guest_tlb_s1(void) * * See ARMv8 (DDI 0487L.b): G5-11698 Table G5-23. */ - return flush_guest_tlb(); + if ( !cpus_have_const_cap(ARM_HAS_NTLBPA) ) + flush_guest_tlb(); } /* Flush TLB of local processor for address va. */ diff --git a/xen/arch/arm/include/asm/arm64/flushtlb.h b/xen/arch/arm/include/asm/arm64/flushtlb.h index 67ae616993..0f0d5050e5 100644 --- a/xen/arch/arm/include/asm/arm64/flushtlb.h +++ b/xen/arch/arm/include/asm/arm64/flushtlb.h @@ -47,6 +47,24 @@ static inline void name(void) \ : : : "memory"); \ } +#define TLB_HELPER_NTLBPA(name, tlbop, sh) \ +static inline void name(void) \ +{ \ + if ( !cpus_have_const_cap(ARM_HAS_NTLBPA) ) \ + asm_inline volatile ( \ + "dsb " # sh "st;" \ + "tlbi " # tlbop ";" \ + ALTERNATIVE( \ + "nop; nop;", \ + "dsb ish;" \ + "tlbi " # tlbop ";", \ + ARM64_WORKAROUND_REPEAT_TLBI, \ + CONFIG_ARM64_WORKAROUND_REPEAT_TLBI) \ + "dsb " # sh ";" \ + "isb;" \ + : : : "memory"); \ +} + /* * FLush TLB by VA. This will likely be used in a loop, so the caller * is responsible to use the appropriate memory barriers before/after @@ -75,10 +93,10 @@ TLB_HELPER(flush_guest_tlb_local, vmalls12e1, nsh) TLB_HELPER(flush_guest_tlb, vmalls12e1is, ish) /* Flush local TLBs, current VMID, stage-1 only */ -TLB_HELPER(flush_guest_tlb_s1_local, vmalle1, nsh) +TLB_HELPER_NTLBPA(flush_guest_tlb_s1_local, vmalle1, nsh) /* Flush innershareable TLBs, current VMID, stage-1 only */ -TLB_HELPER(flush_guest_tlb_s1, vmalle1is, ish) +TLB_HELPER_NTLBPA(flush_guest_tlb_s1, vmalle1is, ish) /* Flush local TLBs, all VMIDs, non-hypervisor mode */ TLB_HELPER(flush_all_guests_tlb_local, alle1, nsh) @@ -104,8 +122,6 @@ TLB_HELPER_VA(__flush_xen_tlb_one, vae2is) */ static inline void flush_guest_tlb_range_ipa(paddr_t ipa, unsigned long size) { - paddr_t end; - /* * If IPA range is too big (empirically found to be 256M), then fallback to * full TLB flush. @@ -113,27 +129,42 @@ static inline void flush_guest_tlb_range_ipa(paddr_t ipa, unsigned long size) if ( size > SZ_256M ) return flush_guest_tlb(); - end = ipa + size; - - /* - * See ARM ARM DDI 0487L.b D8.17.6.1 (Invalidating TLB entries from stage 2 - * translations) for details of TLBI sequence. - */ - dsb(ishst); /* Ensure prior page-tables updates have completed */ - while ( ipa < end ) + else if ( size > 0 ) { - /* Flush stage-2 TLBs for ipa address */ - asm_inline volatile ( - "tlbi ipas2e1is, %0;" : : "r" (ipa >> PAGE_SHIFT) : "memory" ); - ipa += PAGE_SIZE; + paddr_t end = ipa + size; + + /* + * See ARM ARM DDI 0487L.b D8.17.6.1 (Invalidating TLB entries from + * stage 2 translations) for details on TLBI sequence. + */ + dsb(ishst); /* Ensure prior page-tables updates have completed */ + while ( ipa < end ) + { + /* Flush stage-2 TLBs for ipa address */ + asm_inline volatile ( + "tlbi ipas2e1is, %0;" : : "r" (ipa >> PAGE_SHIFT) : "memory" ); + ipa += PAGE_SIZE; + } + if ( cpus_have_const_cap(ARM_HAS_NTLBPA) ) + asm_inline volatile ( + ALTERNATIVE( + "nop; nop;", + "dsb ish;" + "tlbi ipas2e1is, %0;", + ARM64_WORKAROUND_REPEAT_TLBI, + CONFIG_ARM64_WORKAROUND_REPEAT_TLBI) + "dsb ish;" + "isb;" + : : "r" ((ipa - PAGE_SIZE) >> PAGE_SHIFT) : "memory" ); + else + /* + * As ARM64_WORKAROUND_REPEAT_TLBI is required to be applied to + * last TLBI of the sequence, it is only needed to be handled in + * the following invocation. Final dsb() and isb() are also applied + * in the following invocation. + */ + flush_guest_tlb_s1(); } - /* - * As ARM64_WORKAROUND_REPEAT_TLBI is required to be applied to last TLBI - * of the sequence, it is only needed to be handled in the following - * invocation. Final dsb() and isb() are also applied in the following - * invocation. - */ - flush_guest_tlb_s1(); } #endif /* __ASM_ARM_ARM64_FLUSHTLB_H__ */ diff --git a/xen/arch/arm/include/asm/cpufeature.h b/xen/arch/arm/include/asm/cpufeature.h index 13353c8e1a..9f796ed4c1 100644 --- a/xen/arch/arm/include/asm/cpufeature.h +++ b/xen/arch/arm/include/asm/cpufeature.h @@ -76,8 +76,9 @@ #define ARM_WORKAROUND_BHB_SMCC_3 15 #define ARM_HAS_SB 16 #define ARM64_WORKAROUND_1508412 17 +#define ARM_HAS_NTLBPA 18 -#define ARM_NCAPS 18 +#define ARM_NCAPS 19 #ifndef __ASSEMBLER__ @@ -269,7 +270,8 @@ struct cpuinfo_arm { unsigned long ets:4; unsigned long __res1:4; unsigned long afp:4; - unsigned long __res2:12; + unsigned long ntlbpa:4; + unsigned long __res2:8; unsigned long ecbhb:4; /* MMFR2 */ @@ -430,8 +432,24 @@ struct cpuinfo_arm { register_t bits[1]; } aux32; - struct { + union { register_t bits[6]; + struct { + /* MMFR0 */ + unsigned long __res0:32; + /* MMFR1 */ + unsigned long __res1:32; + /* MMFR2 */ + unsigned long __res2:32; + /* MMFR3 */ + unsigned long __res3:32; + /* MMFR4 */ + unsigned long __res4:32; + /* MMFR5 */ + unsigned long __res5:4; + unsigned long ntlbpa:4; + unsigned long __res6:24; + }; } mm32; struct { diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h index 1a48c9ff3b..85f3b643a0 100644 --- a/xen/arch/arm/include/asm/processor.h +++ b/xen/arch/arm/include/asm/processor.h @@ -459,9 +459,16 @@ /* FSR long format */ #define FSRL_STATUS_DEBUG (_AC(0x22,UL)<<0) +#ifdef CONFIG_ARM_32 +#define MM32_NTLBPA_SUPPORT_NI 0x0 +#define MM32_NTLBPA_SUPPORT_IMP 0x1 +#endif + #ifdef CONFIG_ARM_64 #define MM64_VMID_8_BITS_SUPPORT 0x0 #define MM64_VMID_16_BITS_SUPPORT 0x2 +#define MM64_NTLBPA_SUPPORT_NI 0x0 +#define MM64_NTLBPA_SUPPORT_IMP 0x1 #endif #ifndef __ASSEMBLER__ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Sun Jan 18 13:34:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 18 Jan 2026 13:34:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1207813.1520203 (Exim 4.92) (envelope-from ) id 1vhSuw-0004YJ-Bl; Sun, 18 Jan 2026 13:34:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1207813.1520203; Sun, 18 Jan 2026 13:34:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhSuw-0004YC-8q; Sun, 18 Jan 2026 13:34:10 +0000 Received: by outflank-mailman (input) for mailman id 1207813; Sun, 18 Jan 2026 13: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 1vhSuv-0004Go-3D for xen-devel@lists.xenproject.org; Sun, 18 Jan 2026 13:34:09 +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 5d942f59-f472-11f0-b15e-2bf370ae4941; Sun, 18 Jan 2026 14:34:08 +0100 (CET) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-b87693c981fso603418766b.1 for ; Sun, 18 Jan 2026 05:34:08 -0800 (PST) Received: from PKL-HASEEBA-LT.. ([39.37.230.99]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-65452cdab55sm7683163a12.10.2026.01.18.05.34.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 Jan 2026 05:34:06 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5d942f59-f472-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768743247; x=1769348047; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=MPopwKkyNB/YxawSKEN75nDXwr6v2rb4f3Mwy9XTqs4=; b=TLLRLzwpZBMbs4Pi3ntS7kEG/W0q9sgqq2S5dlduZip5THOLP/WJSBbAgZaDtqNNH3 G3x9VDhFlsE7UlZ6aa0zupOJH51ZUfzS3PYb4uI6fpQW+e7KcnWP3J3DFrXIQ6Kj3UEz 6YFJtq6tt7O2QRMTgE3pniK0LALictVQRWGkMLWkxjAxtMhwPSZqQ4tnknDvP2AZRpJs siAW4yvrMNhXtd0APyyqD1Nb4bv103HT6fYCKIyXrTk8Kc+QxTwsWBayropGZaGCcW9B jWwTth9m7IpXdqFZJZAYVX7pcV86Aed0WpARBWq7yKXxU6OfaPVbHX+gfx2laXPFVl7Q Th7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768743247; x=1769348047; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=MPopwKkyNB/YxawSKEN75nDXwr6v2rb4f3Mwy9XTqs4=; b=fx81sk2IZKQ1bRImz2BhSgnksf0mt2pKpA73lHRjyG006/sMoSIA1LUrKxx/Lf+2Hj R9zxp5Np+cqjv3F9VzJvH2w6QcHDgav8bZbmYvmaffGl1omqqHuqbZ3ZoGb0JArFPJsS te3GqlLktLUKPLkWa3ynWZmXddQPU3ngV30a9a3ja+Ckxhztrdl/gYEATV0IoMfiMlGz +DShOnNlwevy+mM8Xw9EiXNvwHxGRzlNY+keotWVptZDOjFsakepJ9yE6LwoP3OMqRSK Db3Uh7w1TF5y/tAq/6230y+wkJ+trlAHBjJbw4i+JlpxtguMDhp806CnwVFX9+iywacP zPgQ== X-Gm-Message-State: AOJu0YxP0ttHPaWOHOpBvgLMefHG3Tp+MpWLXLlYgPIOYaYwLVKNKSta P/Sn6v3v2UKVugrPZQnfMWe8mUhsL5EswvoD1ixitpI96AHUiTOdlZ0uq+BKQQ== X-Gm-Gg: AY/fxX756sXDc2PLhL+w2DsWsqcpfhDnjC9IoxmrNvArK8sUZzA9ry3gvQCc0eLwh37 wQ71pkuyFSgf2Q9iG2dxVxVYWMzLxjuyc6IBk7pIqrgEaRR+C5tZpQVP8P8+0hzA7omRgeM1qph 4xaowlbcora4T7Ax1EhMTnSwf1SEHd17hJmhL0JFwoMUvpowGPeZaaZrLRnsNm63ZbQIGUXlnH2 l8MvrgQtnxtQXBuzenPFfjHs62mB+eyOrYwk8tz5B6RYY2W7poVyF1yFDq/YLMgA3NPR2gQeg7W CegV7okDHVVjJcQg8LquEKXJAxfEp+MNCYQHEut/JoO7WVhogrYOPnpnJ0I/DvPxbt+h9tKYVRp tTh2nQCH3hSkGleDQkMUl1gq/SaxS4WQGYJtXpr7N5Heak1WX7HOMvaGMSgQBN1hf3zgz2lMc+j 5hRhK/OFx5z/6mHYXrgVK5JkDeM0nDMj72VnJscJXTre2TNmnBCg== X-Received: by 2002:a17:907:3c96:b0:b75:7b39:88bc with SMTP id a640c23a62f3a-b8792fee117mr817891566b.58.1768743246925; Sun, 18 Jan 2026 05:34:06 -0800 (PST) From: Haseeb Ashraf To: xen-devel@lists.xenproject.org Cc: Haseeb Ashraf , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [XEN PATCH v3 3/3] xen/arm32: add CPU capability for IPA-based TLBI Date: Sun, 18 Jan 2026 18:33:29 +0500 Message-ID: <68ad0721305814f6d7081223df4039b71627ae1f.1765197209.git.haseeb.ashraf@siemens.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Haseeb Ashraf This feature is available since armv8 and can be used to perform IPA-based TLBI for arm32. XENMEM_remove_from_physmap performs this invalidation in each hypercall so this code path will be optimized, instead of performing a TLBIALL each time in presence of nTLBPA. Suggested-by: Julien Grall Signed-off-by: Haseeb Ashraf Changes in v3: - There are no functional changes in this version. There are minor code updates and comment updates as per the feedback on v2. - The cpregs are defined in order as per Coprocessor-> CRn-> Opcode 1 -> CRm-> Opcode 2. - Added comment to explain why IPA-based TLBI is added only in presence of FEAT_nTLBPA. - Replaced `goto default_tlbi` with if...else. - Removed extra definitions of MM32_UNITLB_* macros which were not being used. Changes in v2: - This commit is implemented in v2 as per the feedback to implement IPA-based TLBI for Arm32 in addition to Arm64. --- xen/arch/arm/cpufeature.c | 12 +++++++ xen/arch/arm/include/asm/arm32/flushtlb.h | 42 ++++++++++++++++++++--- xen/arch/arm/include/asm/cpregs.h | 4 +++ xen/arch/arm/include/asm/cpufeature.h | 15 ++++---- xen/arch/arm/include/asm/processor.h | 3 ++ 5 files changed, 65 insertions(+), 11 deletions(-) diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c index 9fa1c45869..d18c6449c6 100644 --- a/xen/arch/arm/cpufeature.c +++ b/xen/arch/arm/cpufeature.c @@ -18,6 +18,11 @@ DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS); struct cpuinfo_arm __read_mostly domain_cpuinfo; #ifdef CONFIG_ARM_32 +static bool has_tlb_ipa_instruction(const struct arm_cpu_capabilities *entry) +{ + return system_cpuinfo.mm32.unitlb == MM32_UNITLB_BY_IPA; +} + static bool has_ntlbpa(const struct arm_cpu_capabilities *entry) { return system_cpuinfo.mm32.ntlbpa == MM32_NTLBPA_SUPPORT_IMP; @@ -37,6 +42,13 @@ static bool has_sb_instruction(const struct arm_cpu_capabilities *entry) #endif static const struct arm_cpu_capabilities arm_features[] = { +#ifdef CONFIG_ARM_32 + { + .desc = "IPA-based TLB Invalidation", + .capability = ARM32_HAS_TLB_IPA, + .matches = has_tlb_ipa_instruction, + }, +#endif #if defined(CONFIG_ARM_32) || defined(CONFIG_ARM_64) { .desc = "Intermediate caching of translation table walks (nTLBPA)", diff --git a/xen/arch/arm/include/asm/arm32/flushtlb.h b/xen/arch/arm/include/asm/arm32/flushtlb.h index 7cff042508..3e6f86f6d2 100644 --- a/xen/arch/arm/include/asm/arm32/flushtlb.h +++ b/xen/arch/arm/include/asm/arm32/flushtlb.h @@ -1,6 +1,8 @@ #ifndef __ASM_ARM_ARM32_FLUSHTLB_H__ #define __ASM_ARM_ARM32_FLUSHTLB_H__ +#include /* For SZ_* macros. */ + /* * Every invalidation operation use the following patterns: * @@ -104,12 +106,42 @@ static inline void flush_guest_tlb_range_ipa(paddr_t ipa, unsigned long size) { /* - * Following can invalidate both stage-1 and stage-2 TLBs depending upon - * the execution mode. - * - * See ARMv8 (DDI 0487L.b): G5-11698 Table G5-23. + * IPA-based TLBI is used only in presence of nTLBPA, otherwise, stage-1 + * invalidation would still be required and there is no separate TLBI for + * stage-1 on Arm32. So in absence of nTLBPA, it is pointless to flush by + * IPA. */ - flush_guest_tlb(); + if ( cpus_have_const_cap(ARM_HAS_NTLBPA) && + cpus_have_const_cap(ARM32_HAS_TLB_IPA) ) + { + /* + * If IPA range is too big (empirically found to be 256M), then + * fallback to full TLB flush + */ + if ( size > SZ_256M ) + /* + * Following can invalidate both stage-1 and stage-2 TLBs depending + * upon the execution mode. + * + * See ARMv8 (DDI 0487L.b): G5-11698 Table G5-23. + */ + flush_guest_tlb(); + else + { + paddr_t end = ipa + size; + + dsb(ishst); /* Ensure prior page-tables updates have completed */ + while ( ipa < end ) + { + /* Flush stage-2 TLBs for ipa address. */ + asm volatile(STORE_CP32(0, TLBIIPAS2IS) + : : "r" (ipa >> PAGE_SHIFT) : "memory"); + ipa += PAGE_SIZE; + } + dsb(ish); + isb(); + } + } } #endif /* __ASM_ARM_ARM32_FLUSHTLB_H__ */ diff --git a/xen/arch/arm/include/asm/cpregs.h b/xen/arch/arm/include/asm/cpregs.h index a7503a190f..51f091dace 100644 --- a/xen/arch/arm/include/asm/cpregs.h +++ b/xen/arch/arm/include/asm/cpregs.h @@ -223,9 +223,13 @@ #define TLBIMVA p15,0,c8,c7,1 /* invalidate unified TLB entry by MVA */ #define TLBIASID p15,0,c8,c7,2 /* invalid unified TLB by ASID match */ #define TLBIMVAA p15,0,c8,c7,3 /* invalidate unified TLB entries by MVA all ASID */ +#define TLBIIPAS2IS p15,4,c8,c0,1 /* Invalidate unified TLB entry for stage 2 by IPA inner shareable */ +#define TLBIIPAS2LIS p15,4,c8,c0,5 /* Invalidate unified TLB entry for stage 2 last level by IPA inner shareable */ #define TLBIALLHIS p15,4,c8,c3,0 /* Invalidate Entire Hyp. Unified TLB inner shareable */ #define TLBIMVAHIS p15,4,c8,c3,1 /* Invalidate Unified Hyp. TLB by MVA inner shareable */ #define TLBIALLNSNHIS p15,4,c8,c3,4 /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB inner shareable */ +#define TLBIIPAS2 p15,4,c8,c4,1 /* Invalidate unified TLB entry for stage 2 by IPA */ +#define TLBIIPAS2L p15,4,c8,c4,5 /* Invalidate unified TLB entry for stage 2 last level by IPA */ #define TLBIALLH p15,4,c8,c7,0 /* Invalidate Entire Hyp. Unified TLB */ #define TLBIMVAH p15,4,c8,c7,1 /* Invalidate Unified Hyp. TLB by MVA */ #define TLBIALLNSNH p15,4,c8,c7,4 /* Invalidate Entire Non-Secure Non-Hyp. Unified TLB */ diff --git a/xen/arch/arm/include/asm/cpufeature.h b/xen/arch/arm/include/asm/cpufeature.h index 9f796ed4c1..07f1d770b3 100644 --- a/xen/arch/arm/include/asm/cpufeature.h +++ b/xen/arch/arm/include/asm/cpufeature.h @@ -77,8 +77,9 @@ #define ARM_HAS_SB 16 #define ARM64_WORKAROUND_1508412 17 #define ARM_HAS_NTLBPA 18 +#define ARM32_HAS_TLB_IPA 19 -#define ARM_NCAPS 19 +#define ARM_NCAPS 20 #ifndef __ASSEMBLER__ @@ -440,15 +441,17 @@ struct cpuinfo_arm { /* MMFR1 */ unsigned long __res1:32; /* MMFR2 */ - unsigned long __res2:32; + unsigned long __res2:16; + unsigned long unitlb:4; + unsigned long __res3:12; /* MMFR3 */ - unsigned long __res3:32; - /* MMFR4 */ unsigned long __res4:32; + /* MMFR4 */ + unsigned long __res5:32; /* MMFR5 */ - unsigned long __res5:4; + unsigned long __res6:4; unsigned long ntlbpa:4; - unsigned long __res6:24; + unsigned long __res7:24; }; } mm32; diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h index 85f3b643a0..eda39566e1 100644 --- a/xen/arch/arm/include/asm/processor.h +++ b/xen/arch/arm/include/asm/processor.h @@ -460,6 +460,9 @@ #define FSRL_STATUS_DEBUG (_AC(0x22,UL)<<0) #ifdef CONFIG_ARM_32 +#define MM32_UNITLB_NI 0x0 +#define MM32_UNITLB_BY_IPA 0x6 + #define MM32_NTLBPA_SUPPORT_NI 0x0 #define MM32_NTLBPA_SUPPORT_IMP 0x1 #endif -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Sun Jan 18 13:34:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 18 Jan 2026 13:34:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1207809.1520173 (Exim 4.92) (envelope-from ) id 1vhSul-0003pS-L1; Sun, 18 Jan 2026 13:33:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1207809.1520173; Sun, 18 Jan 2026 13: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 1vhSul-0003pJ-Ep; Sun, 18 Jan 2026 13:33:59 +0000 Received: by outflank-mailman (input) for mailman id 1207809; Sun, 18 Jan 2026 13: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 1vhSuk-0003p9-1c for xen-devel@lists.xenproject.org; Sun, 18 Jan 2026 13:33:58 +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 5417a52e-f472-11f0-9ccf-f158ae23cfc8; Sun, 18 Jan 2026 14:33:54 +0100 (CET) Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-64b921d9e67so5818392a12.3 for ; Sun, 18 Jan 2026 05:33:52 -0800 (PST) Received: from PKL-HASEEBA-LT.. ([39.37.230.99]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-65452cdab55sm7683163a12.10.2026.01.18.05.33.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 Jan 2026 05:33:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5417a52e-f472-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768743231; x=1769348031; 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=9yfRH+v8o1fMcD7nIgwoL2ojGo+xNx8nkGSixxBQ19g=; b=Ep5NgPaj1b74b9VAFCFvCQEDHgRo3jj3jdj/mGancLWRoqfNdsTIJ2iYYdRw8c5jtd TR0ovftcbmdoLf8X4raUrtUX9mn+8jnaWBy9ZrdbSvGqizvEZtWW4gbsd8TCR/HTWycX UMTasm/flLMCr2xLM5xWllqRnA3ca6Ty86NEgkj8RTCJJnQp/57+5xk59oSOtBHkYCZI OEhl/nZzFyce5OhILb9A7jI+hmiOGubAyUiYs33wxzM1k1pKfnr3rH55WPZngo/8LyRs MPGlp9Gki/eFz4WsOUlIu6mTgt2RmgMEPIpYH8oDB9W2Vb9CdV38wD1YGtf0WuNTG4+J 1cWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768743231; x=1769348031; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=9yfRH+v8o1fMcD7nIgwoL2ojGo+xNx8nkGSixxBQ19g=; b=iDXfFu9WLsBopzgHaOo3sYg6bvc8dfJ2aOODKFnkc88TYh0GyXDK1U1ptjsNZCGvvh lqIgArLbQ+O46vdnIs76O/Pyj3syWZC2OvnjmdjvlQRroKtchxmcVO4JzKpBpr8aiklj ZnkPsvaXRrvSFphbI5kpXP9gu7MNsae1Sujyuc4yYvtyPDi+pkN0JMXgZhIIAMvU5dcV jexSwHbzBzOnUhI5zWSyhSLY76RXo9cKqOT7XRKgVgL8ZClpBdO19wR9VCci8v2ne1+U pkWoUGSRy30ABu8NF5gN6kOoNTL7B26qcpeyIDRwKJ/LVdMXmPo4dXdHODgq3NK3GZc/ s9DA== X-Gm-Message-State: AOJu0Yz/RRE13w+FY5XiURIxwTCTZWgqUjob19DzSo0IR2WhoOfMHwof bGnUZmTfx/yBhzaDF3kPuEuEaivfkxDS1p/Mf+wjBLWb7bNJXKiR2Djk+HS8cw== X-Gm-Gg: AY/fxX5RxaKdmdTW2CqeRpGpsrkWZGCE8QAN94dkffUepUy+aSJcL5BlHMljvD11DjL eOLPq9mIg5fBcLiKahowC2jEn9Umo9fcv4P8YFPpGGlt1qmGbUWUPTsT1pnTQgymj4QDONzE72s 7ZE8ShCS7YVriCbVtHCgcTjF5OZdibL3qfVaghP2WRCV4SuIxeWxiMLQtkH1SzaD9tNtKstDmxE KsBwe1vIASFvLtXfvbQaw/SYKgV8ItpOmDvtvuEpDwLDc80XKh4POMY5ptcjwgRKzC4sEDJaZpA lzJdaM1H2C/9YsboSVXTWbjhlXG7niT2rR7qcMBIVQz+ADhXAmxK8jDyW6UI/iFsxSeI86jbtiw nLJ74sOfBgNLtZzREubbtrd7mj4ZFH9oCGtP/2soGLF4F9wAl/I37VvWv66HkC9gtCL1KDvYER5 KKE7hLxZoZ6fYLAKnQLBToPKnuwGsEcvwbLBenPCJeoxwM5qZ16g== X-Received: by 2002:a05:6402:1466:b0:640:aae4:b84e with SMTP id 4fb4d7f45d1cf-654b955d67bmr6344710a12.13.1768743231135; Sun, 18 Jan 2026 05:33:51 -0800 (PST) From: Haseeb Ashraf To: xen-devel@lists.xenproject.org Cc: Haseeb Ashraf , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [XEN PATCH v3 0/3] xen/arm{32,64}: perform IPA-based TLBI when IPA is known Date: Sun, 18 Jan 2026 18:33:26 +0500 Message-ID: X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Haseeb Ashraf This patch series addresses a major issue for running Xen on KVM i.e. costly emulation of VMALLS12E1IS which becomes worse when this TLBI is invoked too many times. There are mainly two places where this is problematic: (a) When vCPUs switch on a pCPU or pCPUs (b) When domu mapped pages onto dom0, are to be unmapped, then each page being removed by XENMEM_remove_from_physmap has its TLBs invalidated by the TLBI variant that flushes the whole range. This patch series prefers usage of IPA-based TLBIs wherever possible instead of complete flushing of TLBs every time. It consists of three patches where the first one address the issue being discussed for Arm64. Second patch further optimizes the combined stage-1,2 TLB flushes by leveraging FEAT_nTLBPA. Third patch introduces IPA-based TLBI for Arm32 in presence of FEAT_nTLBPA. Haseeb Ashraf (3): xen/arm/p2m: perform IPA-based TLBI when IPA is known xen/arm: optimize stage-1,2 combined TLBI in presence of FEAT_nTLBPA xen/arm32: add CPU capability for IPA-based TLBI Changes in v3: - Mainly the handling of repeat TLBI workaround with IPA-based TLBI, so that the extra TLBI and DSB are repeated only for the final TLBI and DSB of the whole sequence. - Updated code comments as per feedback. Further details are available in each commit's changelog. - Minor updates to code as per feedback. Further details are available in each commit's changelog. Changes in v2: - Split up the commit in 3 commits. First commit implements the baseline implementation without any addition of new CPU capabilities. Implemented new CPU caps in separate features to emphasize how each of it optimizes the TLB invalidation. - Moved ARM32 and ARM64 specific implementations of TLBIs to architecture specific flushtlb.h. - Added references of ARM ARM in code comments. - Evaluated and added a threshold to select between IPA-based TLB invalidation vs fallback to full stage TLB invalidation above the threshold. - Introduced ARM_HAS_NTLBPA CPU capability which leverages FEAT_nTLBPA for arm32 as well as arm64. - Introduced ARM_HAS_TLB_IPA CPU capability for IPA-based TLBI for arm32. Haseeb Ashraf (3): xen/arm/p2m: perform IPA-based TLBI when IPA is known xen/arm: optimize stage-1,2 combined TLBI in presence of FEAT_nTLBPA xen/arm32: add CPU capability for IPA-based TLBI xen/arch/arm/cpufeature.c | 31 ++++++++ xen/arch/arm/include/asm/arm32/flushtlb.h | 87 +++++++++++++++++++++ xen/arch/arm/include/asm/arm64/flushtlb.h | 77 +++++++++++++++++++ xen/arch/arm/include/asm/cpregs.h | 4 + xen/arch/arm/include/asm/cpufeature.h | 27 ++++++- xen/arch/arm/include/asm/mmu/p2m.h | 2 + xen/arch/arm/include/asm/processor.h | 10 +++ xen/arch/arm/mmu/p2m.c | 92 +++++++++++++++++------ 8 files changed, 302 insertions(+), 28 deletions(-) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Jan 19 07:30:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 07:30:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1207977.1520212 (Exim 4.92) (envelope-from ) id 1vhji6-00027z-0O; Mon, 19 Jan 2026 07:30:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1207977.1520212; Mon, 19 Jan 2026 07:30: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 1vhji5-00027s-Tl; Mon, 19 Jan 2026 07:30:01 +0000 Received: by outflank-mailman (input) for mailman id 1207977; Mon, 19 Jan 2026 07:30: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 1vhji4-00027m-SD for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 07:30:00 +0000 Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [2a00:1450:4864:20::341]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a856e7e4-f508-11f0-9ccf-f158ae23cfc8; Mon, 19 Jan 2026 08:29:58 +0100 (CET) Received: by mail-wm1-x341.google.com with SMTP id 5b1f17b1804b1-47f5c2283b6so25271065e9.1 for ; Sun, 18 Jan 2026 23:29:58 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4801e9ac373sm79472765e9.1.2026.01.18.23.29.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 18 Jan 2026 23:29:57 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a856e7e4-f508-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768807797; x=1769412597; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=vFYKlFrylLExJQVZ6G2P+N9Oy2TYCgyjtxuyeF5sSNY=; b=Pwfel6DWWjTQ2cSdsGNby/g2qJyQlFmgRl1OyVTc/Oc/aV5JVREI1wEKqcFcckKIc8 Z+7HvxfZQGVyJqLvm+6wO6YrGn4vE0rNunnFZa3v8duat+H5KyPDQv67FRno2CZBlbq9 FLfm813HZMv/vIizWGfGJx/+j0dRXzHHjVgZHMQBks4WsTHhXt265EBaRu9enapOfCph nocAZYGrBgc4Slp+eMz72pytD9RK4UKfwnZRSygCNxstg8hN/xd3+EqHO2Szt/F78rnC ZxomGBJ00YtfOegb7rOK7Yip9EeZ6OmmlCRVfAITB4pv/OgHnhUAPHYs892aIi51dYww RRuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768807797; x=1769412597; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vFYKlFrylLExJQVZ6G2P+N9Oy2TYCgyjtxuyeF5sSNY=; b=YfX4M8BvLSn8ywA6Jqzg228A2RCY7ejvv9ZBgdz+yRtTXBN1Gg2kFHkCyFi+wSEpOa cU2BmDKlWRXkJMxuK71Tp5sSXA4uNsOTtvSu7tVoK7j5U5xF0ra2x/6QJk10eRnfqWvg Dr+TcHlw+TvWEah16Kz8VKUCCDsqok2sP+IKrkYh9DFR3dAa1JlAGWo61uocjazHqnsa byrumMI732EIWc2jk0szenaafQpKm75phw5fqvIbRa7gbhBLqyucwbjhprwaUAyfkUGz L32nTyiY1a/XTZo6eCqG9II2O+BUipdRTemkjlusAW6MvgkEPxbb2v/TxM+IHQtECTZf iR7A== X-Forwarded-Encrypted: i=1; AJvYcCUEKwvY7xsn6+3BFCmAd/KefbKh3Rrnn0C9IJ3AlwBVT/P+B8f1jp/xXxCgMD8KLVFwDOxNKj183OQ=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzy0yEpJDzcFCCRyvMWsgxmmeWdBniUXvI/f7kQT80s8b1oGfhd b69uKT3Lm+dqIzbDalyBv8XD81LSFa0hyM9fRrxKbwJHb/oXfg6uQhlNYRM4ivnKjw== X-Gm-Gg: AY/fxX49mrZqlpYIdIWXAPi+Er/Nq7otPlOO25rg0Ny3XiotKScwTXZRfExaX3nwy+x 0DleLFTTnHE0FPpT0LNduZ/ruM+QPfStwAiunJHi0H9suoSlhnfAUOn0hNWeVfp1FmuZ4dYSjYo a16EaXAd1q0Jp7D5IGBvc4lLLooNQHrMgHoOHCwEAi4ZJmAj88OR/bTwJtfRVjf9qhScgLngAa+ XByx+B7WBYxnx/koTEe238uxJjdpmbBpAa1ZoTn20vycCsONKOwrWbxoghcA4e/M1IBLDu2+a0K ObBZt4eyrmuiyq8okKYvv+8ogUB4qcP5cEmrHNCxiTO1tvmza4tSb6Ylwx+Q2209D119IkQANZr eANzPsufuLl4oGtiVRTcjO9qCYoAahi2VYwmUsNMcVzmeiqI/57p3m1Q4BdNtHniwcG65AXqh3J h4nJSUJG5VsYLNSAfHjJ1gbygHQb24/v7Rj5kIrfAXY2e2QblWf4GX9X0EhiVNl3c52V/OVgY8A vM= X-Received: by 2002:a05:600c:4ed3:b0:47e:e91d:73c0 with SMTP id 5b1f17b1804b1-4801e3397d6mr120127135e9.19.1768807797510; Sun, 18 Jan 2026 23:29:57 -0800 (PST) Message-ID: <6f275030-a3c2-4710-952e-56c3226b5a8b@suse.com> Date: Mon, 19 Jan 2026 08:29:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] INSTALL: remove unsupported XEN_CONFIG_EXPERT from documentation To: Stefano Stabellini Cc: dmukhin@xen.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, dmukhin@ford.com, xen-devel@lists.xenproject.org References: <20260116030842.415583-2-dmukhin@ford.com> <09c0007b-3cac-469a-83a0-726c1be149da@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 16.01.2026 21:47, Stefano Stabellini wrote: > On Fri, 16 Jan 2026, Jan Beulich wrote: >> On 16.01.2026 04:08, dmukhin@xen.org wrote: >>> --- a/INSTALL >>> +++ b/INSTALL >>> @@ -33,11 +33,11 @@ small subset of the options. Attempts to change other options will be >>> silently overridden. The only way to find which configuration options >>> are available is to run `make menuconfig' or the like. >> >> I fear this earlier paragraph needs editing as well, which will then >> make more clear that ... >> >>> -You can counter-override this behaviour by setting XEN_CONFIG_EXPERT=y >>> -in your environment. However, doing this is not supported and the >>> -resulting configurations do not receive security support. If you set >>> -this variable there is nothing stopping you setting dangerously >>> -experimental combinations of features - not even any warnings. >>> +This behavior can be overridden by enabling "Configure EXPERT features" >>> +in Kconfig (CONFIG_EXPERT). >> >> ... this may not be quite adequate. >> > > I am not sure how you would like to change the earlier paragraph or this > paragraph. I gave it a try and removed both paragraphs, replacing it > with this: > > """ > Only a subset of options is supported or security-supported by Xen > Project. You can explore all available options, including unsupported > ones and those recommended only for expert users, by using `make > menuconfig` and enabling `CONFIG_UNSUPPORTED` and/or `CONFIG_EXPERT`. > However, enabling these options is not supported, and configurations > resulting from them do not receive security support. > """ > > What do you think? This would be fine with me. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 19 08:07:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 08:07:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1207994.1520222 (Exim 4.92) (envelope-from ) id 1vhkIX-0007n4-0Q; Mon, 19 Jan 2026 08:07:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1207994.1520222; Mon, 19 Jan 2026 08:07: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 1vhkIW-0007mx-U8; Mon, 19 Jan 2026 08:07:40 +0000 Received: by outflank-mailman (input) for mailman id 1207994; Mon, 19 Jan 2026 08:07: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 1vhkIV-0007mq-QI for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 08:07:39 +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 eac8a6a2-f50d-11f0-9ccf-f158ae23cfc8; Mon, 19 Jan 2026 09:07:37 +0100 (CET) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-430f57cd471so1983106f8f.0 for ; Mon, 19 Jan 2026 00:07:37 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43569921dedsm21454318f8f.9.2026.01.19.00.07.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jan 2026 00:07:36 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: eac8a6a2-f50d-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768810056; x=1769414856; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=biZYjY4em3mzByOcXAuDU9PPHceEnfFUhiLm0j561zQ=; b=Wvp7ef+CNMJTNDiKx/4NdLCAHjT5jpTD+OVynXWXBUVixdsgaH8SCs96wExV38Z/q3 cmBfmijtUoK3e6YfLei2csuhYX2WZn+4NOoB/56u4yj31pDtTg+C4LMP8ptg6byVvns+ 6sKwrSd19ndLJEoRdnCJkgh49549Z0tYRhpStL3O+EpT/uTRr35n/2GozPtRiSxvunk1 dZAQRjR0GIISkIuumt7968SkJ5j4rzb6+cqFjxnuNffaq9tgwJsFfQ4xB5ygjGAY7C9v 7j4W9X5XNVI1p0wrxAgbtX62VC+3oVrIAb5EM9KzeCQwwBg3rM0DRw18wR1OEw8aZRi1 QTgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768810056; x=1769414856; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=biZYjY4em3mzByOcXAuDU9PPHceEnfFUhiLm0j561zQ=; b=fXayZnLO46wdohjhqWemTjul/mWBFWMWcOUk3xlerSi90ayaLRLcDRO/aguLFsyuh9 Nj5yrpeX4IAYdVUoBD5kvkko5PRke/5ZcI7QDbigA9jk6uAS9a2GO6nTZ2HKq2dL+66q fYEQ0ACFVeN6HtmrShqX9VEMhVR7vtFqINWCPIG0HB49oxCUMjAkrHBU6T+dY336kHBu fLUqQ1gGUX4bVvzNBRY3rqK/px3POyPwcuNWYLJpvsw+Xie6j5oHvKIaLne5kRg4MyP/ kFQqhDK2KscFxpV6/ocz0Cr735UNMIYK/d36nH9HHBaYMVjwXz4W7ysTRL5SXPT0T63t T4rg== X-Forwarded-Encrypted: i=1; AJvYcCV3CzBc/A02O11jm9TvRWb9JNzUsL5GlwFkSFQfMSxreZZo9hD+IYi9f8TPeI/WICCiIPqT840o4fI=@lists.xenproject.org X-Gm-Message-State: AOJu0YymNXQXG/dM94CKMvX7l+7VHp0vt3GIF0OjWjCxGhzaJeUC0wyg jIgkLTrvcBwBQFv9OMgTnPkKLJSjAeuxdmQ0CcRd/4L3TtUZ1Qek8zv9wY6BGurhIA== X-Gm-Gg: AZuq6aKtOKKea9x+KLGGSYQJSlTX071HpDdruqDWHj8YFYQg/ibBx6bo/Ne3vrO5mES csx26ue1SBwheNNCWWo4pAYuaBRcgMTdppsqXh+DN0rViIttvO9GemRthzSHFVntgBfRVukMre4 Sodg7/xD/epDpeYl8ciLxvDz5K8Bci+dyIWzRuqVUpNJTrV9cn5S3aFJPuH+kw/V8DiPnFv3tFR 6Ar57rxUsEmWryrxnvCI++usBLj1iPgMAoWLnuREDQsFB9Dqe9TbBrPlTPITWgG4t+vYv4ioY2j Kz+h9C7MrpawPPKqmC168WqDyqvttQ5WEkMXdSvL2ZO5FlL81pwPcL/FwChWhYcwPnRQz93yoJO Nd+mckQJlUdc5gq7CN3BybWlzDzcDdYA9nD5ToeowgfxwGfUjabkkxetcOA5NLPTqyCoFRg22kh DfZtd2EOwrAnroUj+wzpzPwFaYKtch1+BMCm+CBXdTEr8ncqHBkSCLVMoR7NL9Xp8sPXqaMJJLz VA= X-Received: by 2002:a05:6000:40e0:b0:435:693b:cbdd with SMTP id ffacd0b85a97d-4356a03033bmr12946363f8f.28.1768810056335; Mon, 19 Jan 2026 00:07:36 -0800 (PST) Message-ID: <326ce1df-7e3a-4ba2-8530-98cd74994ee7@suse.com> Date: Mon, 19 Jan 2026 09:07:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver To: Oleksii Moisieiev Cc: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" References: <29c2d1dc-23fb-403e-bb03-d8c2f32424e6@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 16.01.2026 17:48, Oleksii Moisieiev wrote: > > > On 15/01/2026 11:33, Jan Beulich wrote: >> On 14.01.2026 19:29, Oleksii Moisieiev wrote: >>> @@ -1107,6 +1115,15 @@ affinities to prefer but be not limited to the specified node(s). >>> >>> Pin dom0 vcpus to their respective pcpus >>> >>> +### scmi-smc-passthrough (ARM) >>> +> `= ` >>> + >>> +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 and >>> +SCMI nodes removed from Dom0/hwdom device tree. >>> +(for example, thin Dom0 with Driver domain use-case). >>> + >>> ### dtuart (ARM) >>> > `= path [:options]` >> I appreciate missing doc for a pre-existing cmdline option to be introduced, >> but: Why here (in two ways)? First, why in this patch, without it even being >> mentioned in the description? And why in the middle of options starting with >> 'd', when the entire file means to be sorted? > > Thank you for pointing that out. > I will add the following note to the commit description: > > " > Additionally, this patch adds documentation for the pre-existing > scmi-smc-passthrough command line option, which was previously > undocumented. > " > Does this look good to you? Sure. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 19 08:10:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 08:10:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208004.1520233 (Exim 4.92) (envelope-from ) id 1vhkKo-0008Ux-CP; Mon, 19 Jan 2026 08:10:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208004.1520233; Mon, 19 Jan 2026 08:10:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhkKo-0008UO-90; Mon, 19 Jan 2026 08:10:02 +0000 Received: by outflank-mailman (input) for mailman id 1208004; Mon, 19 Jan 2026 08:10: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 1vhkKm-0008Mc-Dh for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 08:10:00 +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 3ef04f9c-f50e-11f0-b15e-2bf370ae4941; Mon, 19 Jan 2026 09:09:58 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-47fedb7c68dso26058075e9.2 for ; Mon, 19 Jan 2026 00:09:58 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4801e8d90b3sm183498265e9.15.2026.01.19.00.09.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jan 2026 00:09:57 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3ef04f9c-f50e-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768810198; x=1769414998; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=QoHB5wvizaAWl1D7bMe7q23T+DHS/1w+EkPraaCrKpw=; b=VZDrI9E/jmC3JapNybqwJch8oCOl0Kqi6d7E5EbuCxaSBuFMsOx9WESaEfJDO7Dvju PRKDxLcszNRFmmcYQ1ftAB6coa/sn2eFdPAb/BlmSuEDxYdtZF0qQdCbMZfymbyFSxpP PrlE3HpaP4qv+hACYOVq3cv2RTyRu0vBgdbveDysIZ9ITFRoblZMaw/xu2tBjlU2v5ZZ EMAel3Sx3lMR5K1RBlqpCyDvRJRz8QJmDI7UD5htXjEmv+MaB9a6w3NIDywl8TJskE07 7yooyyeJj54w3cY7smOV4reFdaZ0VcFyXgdQJdStbFlw8yeN9msgClBxwVbiaR06/pOl hnXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768810198; x=1769414998; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=QoHB5wvizaAWl1D7bMe7q23T+DHS/1w+EkPraaCrKpw=; b=tpJZ7hbq4zW9Xz79/ad9hWjICJ6Lp8TMULFMkpoysWA7L1FgAYRvdudozB2zwTBuTY QkLmvhwxbuIN2XZJjrNG1F+Jg9EK2gVyFwVvAPj1wKk1SvxyqamgpI8EkiJpko+LB/8H 5kcnWHHxsFOXpaYYF4dFFlK4BgDL+0Whiw6OD60nKJ43YNGvwTPv3kFMGwyx4W1Pen2Z Y4m5ixQvTdWIyO9YMdPsh8Ntq0IqQAMIEm+zkNAO2vkawud5EV4SmqVKMIs0VMEee87S NNJbOgGMW3jPXSuwq1QogxCt3Lf6BX0YSe+d107yi6lXiE8jQzIqlbv7fnytOaTIrapi fe3w== X-Gm-Message-State: AOJu0YwwLyNnOkdeXT/H8tULcJWMETY+rnprnnPe1urHDV3ezAEAZD8k 1BTJMcLXX0JjSP++xIDXts2Ap3mJfJCY6fgx+yfh3anBD5lq9jp3HVU2XKSQnxOvXw== X-Gm-Gg: AY/fxX63b4RxDqSAZVSOF4p9wQSJmeRoOmUbf8H2ne7gEv0aDUtDzNSzBl2oZo7Hwcp 0VKMszcGtn56orX7uIeIFrqD8eBnEj0nUHG6nQPxNoW0pNwtI5aZh+c1sY8V/R7tzzSLAjey8wk zlbAAPpaDh+EDydgWKFVstFxGZHVMyYzgActUdnG8KX68+TX9r/yVEivq05GfSL1KbzSzNcQulp dlzCyETegFMz0/ev9FAhGAaE6BiaVYjWxdPrFsUJQvm0uz4QlqBGVliHDQl1hW2ma9ebESMoQCm 8eccyHrywZTMLdAsKmQrKF6JSgQo9CzrN+gF1zjdvEVWTIDWK/IxC+Uqu9sb+By0jZbGQc/rfdw GuVgNasWqqr/Iy/bIoq/J9kwdUlFijMa2wEWAudx1fXjgTOLDCwk8ftcODtjtTZ0O4QhIjcXdoi 3+rD10LSCou9aOOekByu/RzJmCRy67T8v9Vy2/NyLt1SDMPJZEsYBvIPvaM4qyyFSj6inEW8vC8 Ts= X-Received: by 2002:a05:600c:4e43:b0:477:73e9:dbe7 with SMTP id 5b1f17b1804b1-4801e358875mr128177165e9.35.1768810197714; Mon, 19 Jan 2026 00:09:57 -0800 (PST) Message-ID: <1c6152e0-fbb5-4dd1-b8e8-6610251df9c1@suse.com> Date: Mon, 19 Jan 2026 09:09:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] xen/console: handle multiple domains using console_io hypercalls To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, grygorii_strashko@epam.com, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Victor Lira , andrew.cooper3@citrix.com References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 16.01.2026 22:07, Stefano Stabellini wrote: > On Tue, 13 Jan 2026, Stefano Stabellini wrote: >> Allow multiple dom0less domains to use the console_io hypercalls to >> print to the console. Handle them in a similar way to vpl011: only the >> domain which has focus can read from the console. All domains can write >> to the console but the ones without focus have a prefix. In this case >> the prefix is applied by using guest_printk instead of printk or >> console_puts which is what the original code was already doing. >> >> When switching focus using Ctrl-AAA, discard any unread data in the >> input buffer. Input is read quickly and the user would be aware of it >> being slow or stuck as they use Ctrl-AAA to switch focus domain. >> In that situation, it is to be expected that the unread input is lost. >> >> The domain writes are buffered when the domain is not in focus. Push out >> the buffer when the domain enters focus. >> >> Add the console_lock around serial_rx_cons modifications to protect it >> against concurrent writes to it. >> >> Signed-off-by: Stefano Stabellini > > Ping? I'm sorry to ask, but doesn't this come a little early? (I for one simply haven't found time yet to look at the v3 of this.) Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 19 08:34:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 08:34:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208020.1520243 (Exim 4.92) (envelope-from ) id 1vhkiA-00045e-B5; Mon, 19 Jan 2026 08:34:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208020.1520243; Mon, 19 Jan 2026 08:34:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhkiA-00045X-8E; Mon, 19 Jan 2026 08:34:10 +0000 Received: by outflank-mailman (input) for mailman id 1208020; Mon, 19 Jan 2026 08: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 1vhki9-00045R-LD for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 08:34:09 +0000 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [2a00:1450:4864:20::32c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9efcc39e-f511-11f0-b15e-2bf370ae4941; Mon, 19 Jan 2026 09:34:08 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-4801d98cf39so15812795e9.1 for ; Mon, 19 Jan 2026 00:34:07 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4801e9d8ba8sm78309355e9.3.2026.01.19.00.34.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jan 2026 00:34:06 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9efcc39e-f511-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768811647; x=1769416447; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=tkuiGBZS0YjW31rqeXS35kc3lMmLmi0YtGHC4cZOsJc=; b=YtsaEsBxWw2XygfYfg4uJkBCQM2JiLUT3YwDQtJcGa1HTeo1U7cJbF/SCkootIwrZK xEiD2NWg5LgTz7KeD/Gi1VNbp/tEbAjA8rEic/uPs/ispWBWTdiY2reVmFhlxRLuzdpK WbPHnfslm87uorI/0BWbCE5b9OEiVI4tsT2uk+axvIyXXPKa15in993f4ig97KV6LX4e nXq+X6DzWd+y0KpjnHMAnuBfqAbPHX2yaLiq4ZrvTRMVSNg4leUuKciSWp4l4kCEPD9f zjEdmtuQ1RT3n8ejWluCr4MgOMJv/20y4wDnc7V9sqpcbrWx3aKqyw0Vp6/yr0DGfVLy Jo3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768811647; x=1769416447; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=tkuiGBZS0YjW31rqeXS35kc3lMmLmi0YtGHC4cZOsJc=; b=md2/qoYXh6aCy4cjymfpiuFXIcEn3dhRpF84sL/uMSr1jwaWugQVfGmYse9ojG1I/f OidI02p9BuPYaJji4vw6U0uDKh+hl26vw0UPnRqMO4bLLjM8dPvyzi1Ax8ygMDFWLUxq j6KKsJp0O2KKu07BVDsvv1uGDWJhbeGufWDaHXtlzjHLEmWWveqC8UUiiq2kTMNtrN1h XL7JPHYo37CRu4//uVEAjnScogdrfQ4tVQlT/v9Wgu9O67+4XpsVZWWAkX+ILk697M36 ctPc1Xl7oNhN+qWr0DaqqGl9XSGMEekJqTzojs6XvtAqT6E42l/RCDs2cgUs/1Hdwl0N GCnQ== X-Forwarded-Encrypted: i=1; AJvYcCXsXEyhCYk7nQoOu/31vWy3WYBYpOw7WBDOMlcJKoMi0/lwOsSmnLUw/shwo8oNE6bYaGwstRkZ1vw=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy+TtrXh3Dtt8HjPzEcC/HXlb/A8OO6vn2naBtBf2yoe+c3s7d0 t9k5tDeI2PCSobtcn/uRw7m62DGFb61AVddWNM+6t7Hwez+/XfVmkSqDRkJMXqt99w== X-Gm-Gg: AY/fxX6hSVjJNlOf4dy0OWLiuM62uhw+Xaxxy9XFH+BwLWSILmdvdqv97egp970AUmJ 2HPWJHHgHyDcvog/Z/KU+9fnJMxk3yQ9ftuZBPOBB8X9Yyb/x3aQHTbhnjLyv5WDyqnQIygzmQ4 yEz0sLtaOdmTP9y2OkF8nUbUEGjn9lAxMYX3+zsKu4sOThhdbvoyVCdDQzkOY2vTHbXmyAbwAZe Nq0oyNmP8WHfXH97xsUg9Df/t+D7ka3KbniuANNHB4RO27R1F2NCeUqjwueZ0ENfOLyrAzrFyzw vAV1i8Re8eQWOWq5m8lTl5nfpcBDgYYRdnbAnNROtNejPUFR8P81xmaAawJhGIDWypymzFgvmxR 6TRBKxv5HuMA3dMsiybxW2brUIehcMZh/Oj3R6apnGRWHveVqMENgZvUf2xBjdJUcVs5FNnK+De B300/x9keC2UbUjb9Tm7WOEMpKngQjFC3vT4Ci4fFcQCK30g9oNbWX4DB+UkZLLxMs3F+kI2RZ2 cQ= X-Received: by 2002:a05:600c:4e92:b0:475:de14:db1e with SMTP id 5b1f17b1804b1-4801eb0426fmr127326205e9.24.1768811647317; Mon, 19 Jan 2026 00:34:07 -0800 (PST) Message-ID: <843ba134-099c-49a1-8561-5e364b630bc8@suse.com> Date: Mon, 19 Jan 2026 09:34:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/riscv: dump GPRS and CSRs on unexpected traps To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 16.01.2026 17:16, Oleksii Kurochko wrote: > Provide more context on the exception state when an unexpected > exception occurs by dumping various Supervisor, Virtual Supervisor > and Hypervisor CSRs, and GPRs pertaining to the trap. > > Signed-off-by: Oleksii Kurochko > --- > Changes in v2 > - Address coments about print_csr() macros and dump_csrs(). > - Add dumping of GPRs pertaining to the trap. > --- > xen/arch/riscv/traps.c | 82 ++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 82 insertions(+) > > diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c > index e9c967786312..4e0df698552f 100644 > --- a/xen/arch/riscv/traps.c > +++ b/xen/arch/riscv/traps.c > @@ -17,6 +17,13 @@ > #include > #include > > +#define print_csr(csr) \ > + printk("\t" #csr ": %016lx\n", csr_read(csr)); This prints the CSR_ prefix of the internally used constants. Is this useful (rather than extra clutter)? Unlike for the GPRs this also prints the register names in upper case. That may be fine, or may not be. The values printed also won't align, which may make reading more difficult. > +#define print_gprs(regs, reg1, reg2) \ > + printk("\t%-7s: %016lx %-7s: %016lx\n", \ > + #reg1, (regs)->reg1, #reg2, (regs)->reg2) Yes, two per line is certainly helpful. Why not also for some of the CSRs. > @@ -99,12 +106,87 @@ static const char *decode_cause(unsigned long cause) > return decode_trap_cause(cause); > } > > +static void dump_general_regs(const struct cpu_user_regs *regs) > +{ > + printk("\nDumping GPRs...\n"); Register names alone will be meaningful enough? Be mindful of serial line bandwidth as well as screen resolution. > + print_gprs(regs, ra, sp); > + print_gprs(regs, gp, tp); > + print_gprs(regs, t0, t1); > + print_gprs(regs, t2, s0); > + print_gprs(regs, s1, a0); > + print_gprs(regs, a1, a2); > + print_gprs(regs, a3, a4); > + print_gprs(regs, a5, a6); > + print_gprs(regs, a7, s2); > + print_gprs(regs, s3, s4); > + print_gprs(regs, s5, s6); > + print_gprs(regs, s7, s8); > + print_gprs(regs, s9, s10); > + print_gprs(regs, s11, t3); > + print_gprs(regs, t4, t5); > + print_gprs(regs, t6, sepc); > + print_gprs(regs, sstatus, hstatus); The last three aren't GPRs. Why would they be logged here? (All three also being logged in dump_csrs() would further require some disambiguation in the output, for people to not need to go look at the source code every time.) > +} > + > +static void dump_csrs(unsigned long cause) > +{ > + unsigned long hstatus; > + > + printk("\nDumping CSRs...\n"); > + > + printk("Supervisor CSRs\n"); > + print_csr(CSR_STVEC); > + print_csr(CSR_SATP); > + print_csr(CSR_SEPC); > + > + hstatus = csr_read(CSR_HSTATUS); > + > + printk("\tCSR_STVAL: %016lx%s\n", csr_read(CSR_STVAL), > + (hstatus & HSTATUS_GVA) ? ", (guest virtual address)" : ""); > + > + printk("\tCSR_SCAUSE: %016lx\n", cause); > + printk("\t\tDescription: %s\n", decode_cause(cause)); > + print_csr(CSR_SSTATUS); > + > + printk("\nVirtual Supervisor CSRs\n"); > + print_csr(CSR_VSTVEC); > + print_csr(CSR_VSATP); > + print_csr(CSR_VSEPC); > + print_csr(CSR_VSTVAL); > + cause = csr_read(CSR_VSCAUSE); > + printk("\tCSR_VSCAUSE: %016lx\n", cause); > + printk("\t\tDescription: %s\n", decode_cause(cause)); > + print_csr(CSR_VSSTATUS); As before, imo justification is wanted (in the description) for logging VS* values. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 19 08:51:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 08:51:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208031.1520252 (Exim 4.92) (envelope-from ) id 1vhkyR-00071L-LQ; Mon, 19 Jan 2026 08:50:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208031.1520252; Mon, 19 Jan 2026 08: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 1vhkyR-00071E-IY; Mon, 19 Jan 2026 08:50:59 +0000 Received: by outflank-mailman (input) for mailman id 1208031; Mon, 19 Jan 2026 08: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 1vhkyQ-000715-N0 for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 08:50:58 +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 f84dc2e1-f513-11f0-b15e-2bf370ae4941; Mon, 19 Jan 2026 09:50:57 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-47edffe5540so35598625e9.0 for ; Mon, 19 Jan 2026 00:50:57 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47f429071a2sm235389895e9.11.2026.01.19.00.50.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jan 2026 00:50:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f84dc2e1-f513-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768812656; x=1769417456; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=ptll9SHWVZupN3kNFevmi2rV+p8ZUoLcqAweBYKdp9E=; b=WZMiichWdEwUcWMW9QgAKN9tJqoGyLuynYUYUjqRoVX1ymU8U0az/M+fKnOFY3/RDa sFKU7K0HL6nfTIqAStpSwQMg+eeR+yfh/rX8lSDtoezfdiSDoW/n4YDhG6m0/6xW7O1Y c+ZgDAD9ZfaFQ1BVV2/6ug8t9Vccw1ft5+rN/hq/D5ywssMQFK1SKnWGhR5V/3u8LCsD 60+9hkXtY0estrfBC7MgOTwVjlVLt6rzmni59TZbem1UpyTKoPdT3IqSMc0h7JvA4KDz jl6R2Y4geBkdr9PCNvMMWqimMZvBbJcE0aB8aQpn6XQwLV5u5uYVo0oEUHDayr/JYTPE mJOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768812656; x=1769417456; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ptll9SHWVZupN3kNFevmi2rV+p8ZUoLcqAweBYKdp9E=; b=GAkbSnuwmnKF5ytKJNXrpk9qDAty6B8cOmYJ25dcm9s+j7bU0f4IdoaCPJBPhVYZV6 PXXVJ30/95F0rnEJsYsl1T2iwjoXPpDpgGle1zt6w+3S/X16WlxnfTRK5KrQ53Ccclqu ZCE/31wOB6viqZvXlpC4BhcJZjTDoEREnLuLepjZgaOOs1WgFpIJT95zzqQy/wxn1yPr WoDDGHPNdKVJBOS0E09e6Au66KUwDKBckhQfX8/i+odql7rY7hY/Vtd64VDlsUlTq/Ad 2IUPHKc7VnpB4+89xKppuKcnBiP+jfJhmCQSSPArZX1XUe3N6UQ3JFzEnPGLWbVIJvDp cmkQ== X-Forwarded-Encrypted: i=1; AJvYcCWI65cGt+CmRlrrZR/zFpslsTEfOVYL8nGQH5tO0vyeqVj14lErrVXlP8/LxFfN2fNG7SaF3CtpXXY=@lists.xenproject.org X-Gm-Message-State: AOJu0YysirlPvC+nV5TE/+dxKPHwfGweNezl8GOy5VdzT8GYJJFuMiXe zYder21ntUvNNXQad17EXD0XyWnKlZt1FETetbwglYaMSo+7vmGtUOlQHLRwxCrakA== X-Gm-Gg: AY/fxX62iiADT8bstw/MOOm+MBW7iV0Wf+FejvfcGJ0Taq1FJP4ar085HINCGsdZG+q eblBXNk5mDKD58zc1KCSwdGuKtU7Px90/sTLaiER5Nl5n7jxct24EPVHHRCLOmHiCEoNV+MRjLc 87fepOziP1g4dbr4t58NdSWO//hEwrsr1FZMcbvz+JdIcZhs0DupQtfksgASl2U0bL83OTuWhA1 fzilk/t5SAUu/+CeSFMVpggdBsj0Qx4YjklBjDcghvruoOdLwYynd3HT59YH57b+G6ahGFW2djP eh7et6Sqb9FYIAsgSdOvpJkNbYHrK5xYReYaFkooGJaqVv1G0pKaWubEKeJaGfTqtlYdz9Yz/fJ kkecZe2JzPkg8gVjF/PmqsH1BDa377fvKFMmO7ZyNy04nJ5V9+HWaN/jmJFgHvVBlouKaofjmW9 IbJHD7UAnjzcUL8AYQLLZpojZefF8Ij2CwehwVCZ7WnF5KvUvtZGIEPfcb5PFTmHRQU4GZqGcMr 14= X-Received: by 2002:a05:600c:138a:b0:477:1af2:f40a with SMTP id 5b1f17b1804b1-4801e33c066mr158758235e9.17.1768812656132; Mon, 19 Jan 2026 00:50:56 -0800 (PST) Message-ID: Date: Mon, 19 Jan 2026 09:50:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 4/6] xen/p2m: move xenmem_access_to_p2m_access() to common p2m.c To: Penny Zheng Cc: ray.huang@amd.com, Tamas K Lengyel , Alexandru Isaila , Petre Pircalabu , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org, jason.andryuk@amd.com References: <20260115092841.2651224-1-Penny.Zheng@amd.com> <20260115092841.2651224-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: <20260115092841.2651224-5-Penny.Zheng@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 15.01.2026 10:28, Penny Zheng wrote: > --- a/xen/arch/x86/mm/p2m.c > +++ b/xen/arch/x86/mm/p2m.c > @@ -2203,6 +2203,46 @@ void p2m_log_dirty_range(struct domain *d, unsigned long begin_pfn, > guest_flush_tlb_mask(d, d->dirty_cpumask); > } > > +#if defined(CONFIG_VM_EVENT) || defined(CONFIG_ALTP2M) > +bool xenmem_access_to_p2m_access(const struct p2m_domain *p2m, > + xenmem_access_t xaccess, > + p2m_access_t *paccess) > +{ > + static const p2m_access_t memaccess[] = { > +#define ACCESS(ac) [XENMEM_access_##ac] = p2m_access_##ac > + ACCESS(n), > + ACCESS(r), > + ACCESS(w), > + ACCESS(rw), > + ACCESS(x), > + ACCESS(rx), > + ACCESS(wx), > + ACCESS(rwx), > + ACCESS(rx2rw), > + ACCESS(n2rwx), > + ACCESS(r_pw), > +#undef ACCESS > + }; > + > + switch ( xaccess ) > + { > + case 0 ... ARRAY_SIZE(memaccess) - 1: > + xaccess = array_index_nospec(xaccess, ARRAY_SIZE(memaccess)); > + *paccess = memaccess[xaccess]; > + break; > + > + case XENMEM_access_default: > + *paccess = p2m->default_access; > + break; > + > + default: > + return false; > + } > + > + return true; > +} > +#endif /* VM_EVENT || ALTP2M */ > + > /* > * Local variables: > * mode: C > diff --git a/xen/include/xen/mem_access.h b/xen/include/xen/mem_access.h > index 4de651038d..8e7d9ea2e3 100644 > --- a/xen/include/xen/mem_access.h > +++ b/xen/include/xen/mem_access.h > @@ -73,11 +73,6 @@ typedef enum { > /* NOTE: Assumed to be only 4 bits right now on x86. */ > } p2m_access_t; > > -struct p2m_domain; > -bool xenmem_access_to_p2m_access(const struct p2m_domain *p2m, > - xenmem_access_t xaccess, > - p2m_access_t *paccess); > - > /* > * Set access type for a region of gfns. > * If gfn == INVALID_GFN, sets the default access type. > diff --git a/xen/include/xen/p2m-common.h b/xen/include/xen/p2m-common.h > index f0bd9a6b98..bd4169caee 100644 > --- a/xen/include/xen/p2m-common.h > +++ b/xen/include/xen/p2m-common.h > @@ -43,5 +43,8 @@ int __must_check check_get_page_from_gfn(struct domain *d, gfn_t gfn, > bool readonly, p2m_type_t *p2mt_p, > struct page_info **page_p); > > +bool xenmem_access_to_p2m_access(const struct p2m_domain *p2m, > + xenmem_access_t xaccess, > + p2m_access_t *paccess); CI says "no" on both PPC and RISC-V. I wouldn't be surprised of build issues on Arm or x86 either, seeing that p2m-common.h doesn't (and shouldn't) include xen/mem_access.h. It's arch//include/asm/p2m.h which is responsible for the inclusion ahead of including p2m-common.h. Question though is: If this is an x86-only function, why was its decl put in xen/mem_access.h rather than x86'es asm/mem_access.h. I'll try that before giving up and handing this back to you, but may I stress again that you please properly test your changes? It is not the responsibility of the committer to deal with such fallout. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 19 09:19:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 09:19:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208043.1520263 (Exim 4.92) (envelope-from ) id 1vhlQC-0001s9-Qy; Mon, 19 Jan 2026 09:19:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208043.1520263; Mon, 19 Jan 2026 09:19: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 1vhlQC-0001s2-O7; Mon, 19 Jan 2026 09:19:40 +0000 Received: by outflank-mailman (input) for mailman id 1208043; Mon, 19 Jan 2026 09:19:39 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhlQB-0001rt-Kk for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 09:19: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 df865e16-f517-11f0-b15e-2bf370ae4941; Mon, 19 Jan 2026 10:18:53 +0100 (CET) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-430f5ecaa08so1861784f8f.3 for ; Mon, 19 Jan 2026 01:18:53 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435696fbea8sm22044717f8f.0.2026.01.19.01.18.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jan 2026 01:18:52 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: df865e16-f517-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768814333; x=1769419133; 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=FzJUUhx0YFkyNyXnl48dPOe60KcyB1we55lVdUo7lsU=; b=GJb5PM7ubFxucxFYVHDOYa6KkdjBK52DJa1tm7N+9engG6MGlS8pZzZQEmfrD58+Rc H70uQZdGFg/Vcec3q5zleDPSo9vMqsfPCFogt9s4dOKSFpmIHnELp6KsUE0MX01KNoMa 5qil65oL167QsFhUEuKWl8cUbjq5VngwJ0CkQU4W6tvmYamQYFEpWSXPPsIspn2idqyv B1KYL6a/whc/k3824UwEed5Uk+WGDH6tBhmWo2BQbjmxw/w6KPb501iE940y27PUn5lB QwOKn7xi5y7T0r9ZbgEjwYQKaRqFf1isGRVbSJq9U4wdFR1otqYfjhOP+SGtVE7m7Uwi QD7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768814333; x=1769419133; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=FzJUUhx0YFkyNyXnl48dPOe60KcyB1we55lVdUo7lsU=; b=TQDunTzxc2F0DNQoFi76J3eLDJgOdILKt/WIVD9jn/o8UoC7bGIz9apI9WSx2fbE0V /iC9WLd39Och74jKqCFrshIw4RxLuDUsX2tgEG9Uno9Fql8zeXTgLlzs6VT2xqD+dAU+ JBVBaC7g9cKdK0Bzukx0px3TYd9g1G/skpFj+9yXtOimvgDdH7esG099XF9xckTwxPcK EhF860SUHiZlZbL//nbeEVMonCcnJDdpvL8gxwVxDqPBRIypW8h319GrfM5pX1UaIgFM 0v4/4/lcYOpF2vLfZFMdqul5T/lsbJgUsTptlRLUaZ4FmCJ1fxs3buw6efvRuWlcVX// MIZA== X-Forwarded-Encrypted: i=1; AJvYcCUw3Ed/X4gj6GwIWMcGP21eL9XrBetwJFCj4LLlrLXFggtnh7OrQHV7+fEla3zQ7+NJBXP3GM+1rFc=@lists.xenproject.org X-Gm-Message-State: AOJu0Yyd2/fhqe9PUqIU4dXPzdiyE+CeUuWoZbh6FYvm8wLDsvOYCI/+ OTDBbu4PJxbL1HDisxRXziaPI1amENYwFcXNiFsZgrMneQmmu4mKrijPy0HBkHmi0w== X-Gm-Gg: AZuq6aIBbNE25a9g0QjV4FSQYGxRGhtiqMVdlXbqRrKQ6xvwf3t1rW4k6Ux5LcX8L6c GOD+x5SeyKrrLCAaQZsK67hFjtzs5PCh8fL38hWK7iBJSu678VvNb8gOWtzl13bQdhx61OXz0+G 41coNe6dubujE77SITcRVox8tbrV3KT7A34BJjx7OHl7yPRiRV4eU/bZLCdWOaYeEGXXCsIOv4o xnwSqRPFMWM8DKLb6qx0TMdzutukgnxlRnOXSW6TwAtkrpwY2QFXRGxU3YEu44s1+qz2OwhTP8o jcF785MqpWq/Sfi+aLd7CUHUGgC9kezA5kY64dmNsmaLVRr2s9itgXx3/izkBe9mA1Q61HzTnJ2 d5QNaWG5NcM6wCl6SL1NxI6hbr1uKvKoq58ZwLgBs8Wh6naDhVVo8OCICc0e/C0HJe4WnGUJNSv 6wZzJrQN+PYo3imvzDk3cLMMraqmYktlrXzK4YcOiTJ9vAfspgLJ/CjS2Ev/24ufnuwCvrqsTxj L6Ma7YjADxgnw== X-Received: by 2002:a05:6000:25c7:b0:432:5bf9:cf15 with SMTP id ffacd0b85a97d-4356a024907mr15592645f8f.5.1768814332648; Mon, 19 Jan 2026 01:18:52 -0800 (PST) Message-ID: Date: Mon, 19 Jan 2026 10:18:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/altp2m: altp2m_get_effective_entry() should honor ap2m->default_access From: Jan Beulich To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org, Tamas K Lengyel , =?UTF-8?Q?Petr_Bene=C5=A1?= References: <1916d0a7-ff9a-49f1-8564-2767226fca9c@citrix.com> Content-Language: en-US Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12.01.2026 12:24, Jan Beulich wrote: > On 12.01.2026 12:18, Andrew Cooper wrote: >> On 12/01/2026 11:09 am, Jan Beulich wrote: >>> On 09.01.2026 19:28, Petr Beneš wrote: >>>> From: Petr Beneš >>>> >>>> Commit 7e5b662 fixed p2m_altp2m_get_or_propagate() to use the altp2m's >>>> default_access when propagating entries from the host p2m. However, the same >>>> fix was not applied to altp2m_get_effective_entry(), which has the same issue. >>>> >>>> When altp2m_get_effective_entry() prepopulates a superpage from the host >>>> p2m, it incorrectly uses the host p2m's access permissions instead of >>>> the altp2m's default_access. This causes problems when the superpage is >>>> later split (e.g., when setting mem_access on a specific 4K page): all >>>> 512 entries inherit the host p2m's access rights instead of the altp2m's >>>> default_access. >>>> >>>> This issue became apparent after commit 50baf2d, which causes the host p2m >>>> to use superpages more frequently. Before that commit, the host p2m >>>> typically had 4K entries after VM restore, so the prepopulate branch was >>>> rarely taken. >>>> >>>> Symptoms include memory-access events firing for unexpected pages when >>>> using VMI tools with altp2m, particularly after VM resume. >>>> The issue can be worked around by booting with "hap_1gb=0 hap_2mb=0". >>>> >>>> Fixes: 7e5b662 ("x86/altp2m: p2m_altp2m_get_or_propagate() should honor ap2m->default_access") >>> You didn't even Cc Tamas, who I think once again will need to ack this. >>> Already with the referenced change I didn't quite understand the >>> reasoning. >>> >>> However, two formal points: Please use 12-digit hashes, as demanded by >>> sending-patches.pandoc. Plus I don't think Fixes: is quite right here. >>> That earlier change of yours didn't mean to do more than it did, by its >>> title and description. We relatively recently introduced Amends:, which >>> may be a suitable fit here. >> >> I beg your pardon?  Fixes are and Amends are synonyms. > > This is news to me. To me a "fix" addresses a bug in the referenced commit. > Whereas making a related change which isn't strictly a bugfix to the > referenced earlier change is what Amends: was introduced for. If both were > synonyms, why would you not have objected to the introduction of Amends:? Having thought about this some more, would Complements: or Supplements: possibly better suit you? Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 19 10:34:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 10:34:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208063.1520297 (Exim 4.92) (envelope-from ) id 1vhmaO-00039W-6n; Mon, 19 Jan 2026 10:34:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208063.1520297; Mon, 19 Jan 2026 10:34:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhmaO-00039P-3v; Mon, 19 Jan 2026 10:34:16 +0000 Received: by outflank-mailman (input) for mailman id 1208063; Mon, 19 Jan 2026 10:34: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 1vhmaM-00039J-FI for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 10:34:14 +0000 Received: from mail187-33.suw11.mandrillapp.com (mail187-33.suw11.mandrillapp.com [198.2.187.33]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 64204b92-f522-11f0-9ccf-f158ae23cfc8; Mon, 19 Jan 2026 11:34:11 +0100 (CET) Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail187-33.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4dvmz56DZ6zBsTwYK for ; Mon, 19 Jan 2026 10:34:09 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 3d347223db944c539b4fc967bdb4378a; Mon, 19 Jan 2026 10:34:09 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 64204b92-f522-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1768818849; x=1769088849; bh=vn3Wli3BNWKqrV+U6eVpSMGef8+BZt16wPe0+g/asaM=; 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=JOH+0kfEomGOk5Gkh9mYJ14Gn/C8qyi6c8WBYubbYS6mjAIZjN3RQh6Z19FtjPvvj MmQYJlsavcjr6QCzfOu42eJDh1vfyh4QZEBSmkofagUAP5rwt25cb6iW72rLNave8l GYhm0o20Lai6bKiCY7QCiL7UWbgIP3I2IoIDXI94SaEmH/n6wMLwHoMshk0KtRA99y 0u1gWBXfwu0iGXixsSXyLzkDjEwYZU0pN2t5goVGoAHe6b7eEY9PMzpUTKaU/+3jD5 q9q/bzCqX/+OaxbA7K6KXhbQY6STKsXv6nO34X/931A47XpLlb7ysZk4vrC+DzsZuQ oQrHmXi6IHvEw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1768818849; x=1769079349; i=julian.vetter@vates.tech; bh=vn3Wli3BNWKqrV+U6eVpSMGef8+BZt16wPe0+g/asaM=; 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=fMJttFIOTcXnQY2CMosBzovW4JD1YzSu7nlbMO+WgcLgfhpgBr484IKRNriYkNYRc 0xOMlRzg0mzgu1CH1cTbYE7n8T3Qxg+m89ymo0rNhm5oiqttYrQG5lIYd4DeN5EL0P ItnqyPwNZ558qufY0WNhgdiMNd9UwKTtDk4LE6vsoTz7qwDKGYDmVGt3JsZqHnpjnw 7uHu+i9r/Snm+oT46pEniKoXjDoPDYGvsfqMbSCq8yGj2sTtVTLqUwO9mDymfiLhQk Vm90Ai5WuCkDSskeDC+2exYC7G1+LVaAMCX9PfiDpvsLrUfhPc/0f5fRAgMV/XTxby Td+9rIY29BLVg== From: "Julian Vetter" Subject: =?utf-8?Q?Re:=20[PATCH]=20xen:=20Move=20NX=20handling=20to=20a=20dedicated=20place?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1768818848319 Message-Id: To: "Andrew Cooper" , xen-devel@lists.xenproject.org Cc: "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Daniel P . Smith" , "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" , "Jan Beulich" References: <20260115151658.3725784-1-julian.vetter@vates.tech> <69b511db-654d-46b3-aca3-3f37f30d3473@citrix.com> In-Reply-To: <69b511db-654d-46b3-aca3-3f37f30d3473@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.3d347223db944c539b4fc967bdb4378a?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260119:md Date: Mon, 19 Jan 2026 10:34:09 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/15/26 4:50 PM, Andrew Cooper wrote: > On 15/01/2026 3:17 pm, Julian Vetter wrote: >> Currently the CONFIG_REQUIRE_NX prevents booting XEN, if NX is disabled >> in the BIOS. AMD doesn't have a software-accessible MSR to re-enable it, >> so there is nothing we can do. The system is going to die anyway. But on >> Intel NX might just be hidden via IA32_MISC_ENABLE.XD_DISABLE. But the >> function to re-enable it is called after the check + panic in >> efi_arch_cpu. So, this patch removes the early check and moves the >> entire NX handling into a dedicated place. >> >> Signed-off-by: Julian Vetter > > Sorry I didn't get around to doing the prep work I promised. No problem, I assumed you were quiet busy so I looked into it. > > This is going along the right lines, but there are a few complexities sti= ll. Thank you for the feedback. > > Also you'll want to split the patch into a series.=C2=A0 More on that whe= n > we've sorted out a few other details. Yes, I will do that once everything is sorted out. > >> diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoli= ne.S >> index a92e399fbe..8e8d50cbdf 100644 >> --- a/xen/arch/x86/boot/trampoline.S >> +++ b/xen/arch/x86/boot/trampoline.S >> @@ -144,10 +144,9 @@ gdt_48: >> GLOBAL(trampoline_misc_enable_off) >> .quad 0 >> >> -/* EFER OR-mask for boot paths. SCE conditional on PV support, NX adde= d when available. */ >> +/* EFER OR-mask for boot paths. SCE conditional on PV support. */ > > The comment wants to stay as-was.=C2=A0 NX does get added when available. > >> GLOBAL(trampoline_efer) >> - .long EFER_LME | (EFER_SCE * IS_ENABLED(CONFIG_PV)) | \ >> - (EFER_NXE * IS_ENABLED(CONFIG_REQUIRE_NX)) >> + .long EFER_LME | (EFER_SCE * IS_ENABLED(CONFIG_PV)) >> >> GLOBAL(trampoline_xen_phys_start) >> .long 0 >> diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm= /setup.h >> index b01e83a8ed..16f53725ca 100644 >> --- a/xen/arch/x86/include/asm/setup.h >> +++ b/xen/arch/x86/include/asm/setup.h >> @@ -70,4 +70,6 @@ extern bool opt_dom0_msr_relaxed; >> >> #define max_init_domid (0) >> >> +void nx_init(void); >> + >> #endif >> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c >> index 27c63d1d97..608720b717 100644 >> --- a/xen/arch/x86/setup.c >> +++ b/xen/arch/x86/setup.c >> @@ -1119,6 +1119,50 @@ static struct domain *__init create_dom0(struct b= oot_info *bi) >> return d; >> } >> >> +void __init nx_init(void) > > This should be static if it's only used in a single file.=C2=A0 However, = see > later for doing it a bit differently. > >> +{ >> + uint64_t misc_enable; >> + uint32_t eax, ebx, ecx, edx; >> + >> + if ( !boot_cpu_has(X86_FEATURE_NX) ) >> + { >> + /* Intel: try to unhide NX by clearing XD_DISABLE */ >> + cpuid(0, &eax, &ebx, &ecx, &edx); >> + if ( ebx =3D=3D X86_VENDOR_INTEL_EBX && >> + ecx =3D=3D X86_VENDOR_INTEL_ECX && >> + edx =3D=3D X86_VENDOR_INTEL_EDX ) >> + { >> + rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable); >> + if ( misc_enable & MSR_IA32_MISC_ENABLE_XD_DISABLE ) >> + { >> + misc_enable &=3D ~MSR_IA32_MISC_ENABLE_XD_DISABLE; >> + wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable); >> + >> + /* Re-read CPUID after having cleared XD_DISABLE */ >> + boot_cpu_data.x86_capability[FEATURESET_e1d] =3D cpuid_= edx(0x80000001U); >> + >> + /* Adjust misc_enable_off for secondary startup and wak= eup code */ >> + bootsym(trampoline_misc_enable_off) |=3D MSR_IA32_MISC_= ENABLE_XD_DISABLE; >> + printk(KERN_INFO "re-enabled NX (Execute Disable) prote= ction\n"); >> + } >> + } >> + /* AMD: nothing we can do - NX must be enabled in BIOS */ > > The BIOS is only hiding the CPUID bit.=C2=A0 It's not blocking the use of= NX. Yes, you're right. > > You want to do a wrmsr_safe() trying to set EFER.NXE, and if it > succeeds, set the NX bit in MSR_K8_EXT_FEATURE_MASK to "unhide" it in > regular CPUID.=C2=A0 This is a little more tricky to arrange because it n= eeds > doing on each CPU, not just the BSP. Ok, yes, I have modified the AMD side to use MSR_K8_EXT_FEATURE_MASK to "unhide" it. > >> + } >> + >> + /* Enable EFER.NXE only if NX is available */ >> + if ( boot_cpu_has(X86_FEATURE_NX) ) >> + { >> + if ( !(read_efer() & EFER_NXE) ) >> + write_efer(read_efer() | EFER_NXE); >> + >> + /* Adjust trampoline_efer for secondary startup and wakeup code= */ >> + bootsym(trampoline_efer) |=3D EFER_NXE; >> + } >> + >> + if ( IS_ENABLED(CONFIG_REQUIRE_NX) && !boot_cpu_has(X86_FEATURE_NX)= ) >> + panic("This build of Xen requires NX support\n"); >> +} >> + >> /* How much of the directmap is prebuilt at compile time. */ >> #define PREBUILT_MAP_LIMIT (1 << L2_PAGETABLE_SHIFT) >> >> @@ -1159,6 +1203,8 @@ void asmlinkage __init noreturn __start_xen(void) >> rdmsrl(MSR_EFER, this_cpu(efer)); >> asm volatile ( "mov %%cr4,%0" : "=3Dr" (info->cr4) ); >> >> + nx_init(); >> + >> /* Enable NMIs. Our loader (e.g. Tboot) may have left them disabl= ed. */ >> enable_nmis(); >> > > This is too early, as can be seen by the need to make a cpuid() call > rather than using boot_cpu_data. > > The cleanup I wanted to do was to create/rework early_cpu_init() to get > things in a better order, so the panic() could go at the end here.=C2=A0 = The > current split we've got of early/regular CPU init was inherited from > Linux and can be collapsed substantially. I have tried to add the logic into the early_init_{intel,amd}() functions. But it seems this is already too late in the boot chain. This is why I put into an extra function which is called earlier. Because it seems there are already pages with PAGE_NX being used on the way to early_init_{intel,amd}(). Because when I put my code into early_init_intel I get a fault and a reboot. What do you suggest? > > The intel "unlocking" wants to move back into early_init_intel(), along > with intel_unlock_cpuid_leaves().=C2=A0 (This is where it used to live be= fore > REQUIRE_NX was added). > > The AMD side probe wants to live in early_amd_init()=C2=A0 (not that ther= e is > one right now), but the re-enabling of the NX bit in CPUID needs to also > be in amd_init() so it gets applied to APs too. > > Does this make sense? > > ~Andrew > -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Mon Jan 19 10:50:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 10:50:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208079.1520307 (Exim 4.92) (envelope-from ) id 1vhmqD-0005yK-Ky; Mon, 19 Jan 2026 10:50:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208079.1520307; Mon, 19 Jan 2026 10:50:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhmqD-0005yD-Hp; Mon, 19 Jan 2026 10:50:37 +0000 Received: by outflank-mailman (input) for mailman id 1208079; Mon, 19 Jan 2026 10:50:36 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhmqC-0005y7-9Z for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 10:50:36 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id adef8295-f524-11f0-b15e-2bf370ae4941; Mon, 19 Jan 2026 11:50:33 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 396D91517; Mon, 19 Jan 2026 02:50:26 -0800 (PST) Received: from e134099.cambridge.arm.com (e134099.arm.com [10.1.198.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4E8603F632; Mon, 19 Jan 2026 02:50:31 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: adef8295-f524-11f0-b15e-2bf370ae4941 From: Harry Ramsey To: xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Penny Zheng , Wei Chen , Luca Fancellu , Hari Limaye Subject: [PATCH] arm/mpu: implement setup_virt_paging for MPU system Date: Mon, 19 Jan 2026 10:50:22 +0000 Message-ID: <20260119105022.3616126-1-harry.ramsey@arm.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Penny Zheng For MMU system, setup_virt_paging is used to configure stage 2 address translation regime, like IPA bits, VMID allocator set up, etc. Some could be inherited in MPU system, like VMID allocator set up, etc. For MPU system, we could have the following memory translation regime: - PMSAv8-64 at both EL1/EL0 and EL2 - VMSAv8-64 at EL1/EL0 and PMSAv8-64 at EL2 The default option will be the second, unless the platform could not support, which could be checked against MSA_frac bit in Memory Model Feature Register 0( ID_AA64MMFR0_EL1). Signed-off-by: Penny Zheng Signed-off-by: Wei Chen Signed-off-by: Luca Fancellu Signed-off-by: Hari Limaye Signed-off-by: Harry Ramsey --- xen/arch/arm/arm64/mpu/p2m.c | 90 +++++++++++++++++++++++- xen/arch/arm/include/asm/arm32/mpu.h | 2 + xen/arch/arm/include/asm/arm64/mpu.h | 2 + xen/arch/arm/include/asm/arm64/sysregs.h | 5 ++ xen/arch/arm/include/asm/cpufeature.h | 7 ++ xen/arch/arm/include/asm/mpu.h | 7 +- xen/arch/arm/include/asm/mpu/p2m.h | 12 ++++ xen/arch/arm/include/asm/p2m.h | 5 ++ xen/arch/arm/include/asm/processor.h | 13 ++++ xen/arch/arm/mpu/p2m.c | 71 ++++++++++++++++++- 10 files changed, 209 insertions(+), 5 deletions(-) diff --git a/xen/arch/arm/arm64/mpu/p2m.c b/xen/arch/arm/arm64/mpu/p2m.c index b6d8b2777b..13b633d9fe 100644 --- a/xen/arch/arm/arm64/mpu/p2m.c +++ b/xen/arch/arm/arm64/mpu/p2m.c @@ -2,11 +2,99 @@ #include #include +#include #include void __init setup_virt_paging(void) { - BUG_ON("unimplemented"); + uint64_t vtcr_el2 = 0, vstcr_el2 = 0; + bool p2m_vmsa = true; + + /* PA size */ + const unsigned int pa_range_info[] = { 32, 36, 40, 42, 44, 48, 52, 0, /* Invalid */ }; + + /* + * Restrict "p2m_ipa_bits" if needed. As P2M table is always configured + * with IPA bits == PA bits, compare against "pabits". + */ + if ( pa_range_info[system_cpuinfo.mm64.pa_range] < p2m_ipa_bits ) + p2m_ipa_bits = pa_range_info[system_cpuinfo.mm64.pa_range]; + + /* + * Clear VTCR_EL2.NSA bit to configure non-secure stage 2 translation output + * address space to access the Secure PA space. + */ + vtcr_el2 &= NSA_SEL2; + + /* + * The MSA and MSA_frac fields in the ID_AA64MMFR0_EL1 register identify the + * memory system configurations supported at EL1. In Armv8-R AArch64, the + * only permitted value for ID_AA64MMFR0_EL1.MSA is 0b1111. + */ + if ( system_cpuinfo.mm64.msa != MM64_MSA_PMSA_SUPPORT ) + goto fault; + + /* Permitted values for ID_AA64MMFR0_EL1.MSA_frac are 0b0001 and 0b0010. */ + if ( system_cpuinfo.mm64.msa_frac == MM64_MSA_FRAC_NONE_SUPPORT ) + goto fault; + + /* + * When ID_AA64MMFR0_EL1.MSA_frac is 0b0010 the stage 1 EL1&0 translation + * regime supports both PMSAv8-64 and VMSAv8-64. + */ + if ( system_cpuinfo.mm64.msa_frac != MM64_MSA_FRAC_VMSA_SUPPORT ) + { + p2m_vmsa = false; + warning_add("Be aware of that there is no support for VMSAv8-64 at EL1 on this platform\n"); + } + + /* + * If PE supports both PMSAv8-64 and VMSAv8-64 at EL1, then VTCR_EL2.MSA + * determines the memory system architecture enabled at stage 1 of the + * Secure EL1&0 translation regime. + * + * Normally, we set the initial VTCR_EL2.MSA value VMSAv8-64 support, + * unless this platform only supports PMSAv8-64. + */ + if ( !p2m_vmsa ) + vtcr_el2 &= VTCR_MSA_PMSA; + else + vtcr_el2 |= VTCR_MSA_VMSA; + + /* + * cpuinfo sanitization makes sure we support 16bits VMID only if all cores + * are supporting it. + */ + if ( system_cpuinfo.mm64.vmid_bits == MM64_VMID_16_BITS_SUPPORT ) + max_vmid = MAX_VMID_16_BIT; + + /* Set the VS bit only if 16 bit VMID is supported. */ + if ( MAX_VMID == MAX_VMID_16_BIT ) + vtcr_el2 |= VTCR_VS; + + p2m_vmid_allocator_init(); + + WRITE_SYSREG(vtcr_el2, VTCR_EL2); + + /* + * VSTCR_EL2.SA defines secure stage 2 translation output address space. + * To make sure that all stage 2 translations for the Secure PA space access + * the Secure PA space, we keep SA bit as 0. + * + * VSTCR_EL2.SC is NS check enable bit. To make sure that Stage 2 NS + * configuration is checked against stage 1 NS configuration in EL1&0 + * translation regime for the given address, and generates a fault if they + * are different, we set SC bit 1. + */ + vstcr_el2 = 1 << VSTCR_EL2_RES1_SHIFT; + vstcr_el2 &= VSTCR_EL2_SA; + vstcr_el2 |= VSTCR_EL2_SC; + WRITE_SYSREG(vstcr_el2, VSTCR_EL2); + + return; + + fault: + panic("Hardware with no PMSAv8-64 support in any translation regime\n"); } /* diff --git a/xen/arch/arm/include/asm/arm32/mpu.h b/xen/arch/arm/include/asm/arm32/mpu.h index 2cf0f8cbac..d565230f84 100644 --- a/xen/arch/arm/include/asm/arm32/mpu.h +++ b/xen/arch/arm/include/asm/arm32/mpu.h @@ -11,6 +11,8 @@ */ #define MPU_REGION_RES0 0x0 +#define VSCTLR_VMID_SHIFT 16 + /* Hypervisor Protection Region Base Address Register */ typedef union { struct { diff --git a/xen/arch/arm/include/asm/arm64/mpu.h b/xen/arch/arm/include/asm/arm64/mpu.h index 4f694190a8..8b86a03fee 100644 --- a/xen/arch/arm/include/asm/arm64/mpu.h +++ b/xen/arch/arm/include/asm/arm64/mpu.h @@ -7,6 +7,8 @@ #define MPU_REGION_RES0 (0xFFFFULL << 48) +#define VSCTLR_VMID_SHIFT 48 + /* Protection Region Base Address Register */ typedef union { struct __packed { diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/include/asm/arm64/sysregs.h index 19d409d3eb..4ed8ac0440 100644 --- a/xen/arch/arm/include/asm/arm64/sysregs.h +++ b/xen/arch/arm/include/asm/arm64/sysregs.h @@ -462,6 +462,11 @@ #define ZCR_ELx_LEN_SIZE 9 #define ZCR_ELx_LEN_MASK 0x1ff +/* Virtualization Secure Translation Control Register */ +#define VSTCR_EL2_RES1_SHIFT 31 +#define VSTCR_EL2_SA ~(_AC(0x1,UL)<<30) +#define VSTCR_EL2_SC (_AC(0x1,UL)<<20) + #ifdef CONFIG_MPU /* * The Armv8-R AArch64 architecture always executes code in Secure diff --git a/xen/arch/arm/include/asm/cpufeature.h b/xen/arch/arm/include/asm/cpufeature.h index 13353c8e1a..677cb2b96d 100644 --- a/xen/arch/arm/include/asm/cpufeature.h +++ b/xen/arch/arm/include/asm/cpufeature.h @@ -248,6 +248,12 @@ struct cpuinfo_arm { unsigned long tgranule_16K:4; unsigned long tgranule_64K:4; unsigned long tgranule_4K:4; +#if !defined(CONFIG_MMU) + unsigned long __res:16; + unsigned long msa:4; + unsigned long msa_frac:4; + unsigned long __res0:8; +#else unsigned long tgranule_16k_2:4; unsigned long tgranule_64k_2:4; unsigned long tgranule_4k_2:4; @@ -255,6 +261,7 @@ struct cpuinfo_arm { unsigned long __res0:8; unsigned long fgt:4; unsigned long ecv:4; +#endif /* MMFR1 */ unsigned long hafdbs:4; diff --git a/xen/arch/arm/include/asm/mpu.h b/xen/arch/arm/include/asm/mpu.h index 72fa5b00b8..55011e3d96 100644 --- a/xen/arch/arm/include/asm/mpu.h +++ b/xen/arch/arm/include/asm/mpu.h @@ -87,7 +87,12 @@ static inline bool region_is_valid(const pr_t *pr) return pr->prlar.reg.en; } -#endif /* __ASSEMBLER__ */ +static inline register_t generate_vsctlr(uint16_t vmid) +{ + return ((register_t)vmid << VSCTLR_VMID_SHIFT); +} + +#endif /* __ASSEMBLY__ */ #endif /* __ARM_MPU_H__ */ diff --git a/xen/arch/arm/include/asm/mpu/p2m.h b/xen/arch/arm/include/asm/mpu/p2m.h index e46d9e757a..d165585d4e 100644 --- a/xen/arch/arm/include/asm/mpu/p2m.h +++ b/xen/arch/arm/include/asm/mpu/p2m.h @@ -5,6 +5,18 @@ struct p2m_domain; +/* + * The architecture allows at most 255 EL2 MPU memory regions. The size of the + * MPU structure entry (pr_t) is 32 Bytes on AArch64 (requiring two 4KB pages) + * and 16 bytes on AArch32 (requiring one 4KB page). + */ +#ifdef CONFIG_ARM_64 +#define P2M_ROOT_ORDER 1 +#else +#define P2M_ROOT_ORDER 0 +#endif + +/* Not used on MPU system */ static inline void p2m_clear_root_pages(struct p2m_domain *p2m) {} static inline void p2m_tlb_flush_sync(struct p2m_domain *p2m) {} diff --git a/xen/arch/arm/include/asm/p2m.h b/xen/arch/arm/include/asm/p2m.h index 010ce8c9eb..3dd0a5887e 100644 --- a/xen/arch/arm/include/asm/p2m.h +++ b/xen/arch/arm/include/asm/p2m.h @@ -48,8 +48,13 @@ struct p2m_domain { /* Current VMID in use */ uint16_t vmid; +#if defined(CONFIG_MMU) /* Current Translation Table Base Register for the p2m */ uint64_t vttbr; +#else + /* Current Virtualization System Control Register for the p2m */ + register_t vsctlr; +#endif /* Highest guest frame that's ever been mapped in the p2m */ gfn_t max_mapped_gfn; diff --git a/xen/arch/arm/include/asm/processor.h b/xen/arch/arm/include/asm/processor.h index 1a48c9ff3b..0a47ca8294 100644 --- a/xen/arch/arm/include/asm/processor.h +++ b/xen/arch/arm/include/asm/processor.h @@ -403,6 +403,12 @@ #define VTCR_RES1 (_AC(1,UL)<<31) +#if !defined(CONFIG_MMU) && defined(CONFIG_ARM_64) +#define VTCR_MSA_VMSA (_AC(0x1,UL)<<31) +#define VTCR_MSA_PMSA ~(_AC(0x1,UL)<<31) +#define NSA_SEL2 ~(_AC(0x1,UL)<<30) +#endif + /* HCPTR Hyp. Coprocessor Trap Register */ #define HCPTR_TAM ((_AC(1,U)<<30)) #define HCPTR_TTA ((_AC(1,U)<<20)) /* Trap trace registers */ @@ -464,6 +470,13 @@ #define MM64_VMID_16_BITS_SUPPORT 0x2 #endif +#if !defined(CONFIG_MMU) && defined(CONFIG_ARM_64) +#define MM64_MSA_PMSA_SUPPORT 0xf +#define MM64_MSA_FRAC_NONE_SUPPORT 0x0 +#define MM64_MSA_FRAC_PMSA_SUPPORT 0x1 +#define MM64_MSA_FRAC_VMSA_SUPPORT 0x2 +#endif + #ifndef __ASSEMBLER__ extern register_t __cpu_logical_map[]; diff --git a/xen/arch/arm/mpu/p2m.c b/xen/arch/arm/mpu/p2m.c index f7fb58ab6a..1598f9ab64 100644 --- a/xen/arch/arm/mpu/p2m.c +++ b/xen/arch/arm/mpu/p2m.c @@ -28,10 +28,62 @@ void p2m_dump_info(struct domain *d) BUG_ON("unimplemented"); } +static int __init p2m_alloc_table(struct domain *d) +{ + struct p2m_domain *p2m = p2m_get_hostp2m(d); + pr_t* p2m_map; + + p2m_map = alloc_xenheap_pages(P2M_ROOT_ORDER, 0); + if ( !p2m_map ) + { + printk(XENLOG_G_ERR "DOM%pd: p2m: unable to allocate P2M MPU mapping table\n", d); + return -ENOMEM; + } + clear_page(p2m_map); + + p2m->root = virt_to_page((const void *)p2m_map); + + return 0; +} + int p2m_init(struct domain *d) { - BUG_ON("unimplemented"); - return -EINVAL; + struct p2m_domain *p2m = p2m_get_hostp2m(d); + int rc = 0; + unsigned int cpu; + + rwlock_init(&p2m->lock); + + p2m->vmid = INVALID_VMID; + p2m->max_mapped_gfn = _gfn(0); + p2m->lowest_mapped_gfn = _gfn(ULONG_MAX); + + p2m->default_access = p2m_access_rwx; + /* mem_access is NOT supported in MPU system. */ + p2m->mem_access_enabled = false; + + /* Ensure that the type chosen is large enough for MAX_VIRT_CPUS. */ + BUILD_BUG_ON((1 << (sizeof(p2m->last_vcpu_ran[0]) * 8)) < MAX_VIRT_CPUS); + + for_each_possible_cpu(cpu) + p2m->last_vcpu_ran[cpu] = INVALID_VCPU_ID; + + /* + * "Trivial" initialization is now complete. Set the backpointer so that + * p2m_teardown() and related functions know to do something. + */ + p2m->domain = d; + + rc = p2m_alloc_vmid(d); + if ( rc ) + return rc; + p2m->vsctlr = generate_vsctlr(p2m->vmid); + + rc = p2m_alloc_table(d); + if ( rc ) + return rc; + + return rc; } void p2m_save_state(struct vcpu *p) @@ -46,7 +98,20 @@ void p2m_restore_state(struct vcpu *n) void p2m_final_teardown(struct domain *d) { - BUG_ON("unimplemented"); + struct p2m_domain *p2m = p2m_get_hostp2m(d); + + /* p2m not actually initialized */ + if ( !p2m->domain ) + return; + + if ( p2m->root ) + free_xenheap_pages(p2m->root, P2M_ROOT_ORDER); + + p2m->root = NULL; + + p2m_free_vmid(d); + + p2m->domain = NULL; } bool p2m_resolve_translation_fault(struct domain *d, gfn_t gfn) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Jan 19 13:01:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 13:01:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208106.1520348 (Exim 4.92) (envelope-from ) id 1vhosH-0004bp-Tc; Mon, 19 Jan 2026 13:00:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208106.1520348; Mon, 19 Jan 2026 13:00:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhosH-0004bi-QM; Mon, 19 Jan 2026 13:00:53 +0000 Received: by outflank-mailman (input) for mailman id 1208106; Mon, 19 Jan 2026 13:00: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 1vhosG-0004bc-9P for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 13:00:52 +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 e0898b41-f536-11f0-9ccf-f158ae23cfc8; Mon, 19 Jan 2026 14:00:49 +0100 (CET) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-42fed090e5fso2347364f8f.1 for ; Mon, 19 Jan 2026 05:00:49 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43569998240sm22465267f8f.43.2026.01.19.05.00.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jan 2026 05:00:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e0898b41-f536-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768827649; x=1769432449; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=sbCaCYw061cnJ/iE1RROMXPKMgAIfNLHQNz/ou7YqPk=; b=A7dOfxyotD+VTQIV5Dn8/A8UMg1z/wV3YBoVxVP3r12JP7OIfn5EOzEsvTW+O1p7Tt ex+YDjS8MJfZX7C92uMfsTXJi13ytQutEJT7mjTMA4jxFFkuWeMR38KpIeuEROTqRIR2 Vz2w36C5jBjA/49YRpBSB1sr2Mh1lX4/h8iJeV3xLbdNqMk1ivE+bXPhv1WZLRYOMGE0 bAOwwnHXzYTmQU1VI7mJIYypHdBI+Rj7lxZg9C/MzhH+cELhMmz7cqSE1BklHhM/8rjm puld8ublBLTcbrhUmY4fZxU/snLgIN1v1Pkn3zjUOE5UXtQvUc5Zu5EkwMv1np5bnHZf 89hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768827649; x=1769432449; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=sbCaCYw061cnJ/iE1RROMXPKMgAIfNLHQNz/ou7YqPk=; b=uigzXlnZJ4oKOYhzG8/zcn/xC1hhpUStl53rsSn4N+N8EvkzlxUYrKIQouCuwFH8wb 8Ppmnaw655mQRPXXi+oqfN/YXquHcXBCtG4ttkfcqr/qln/cDfMOtLpHe/GptLnKELhS cvLDNmyS1oJ628Z+IZXi+Xy1XIy/oblGNODqAqMVJwdny2mkhsZ9BtuBTYwAGCKS5b2t yWSLoAnLddXInsojWW3GZKrAD0C0eAVVOYMDjldxKqbYB5meFDaKxUZqwVqpCXBChGYq ngqmQlQgd23Yu1J3635yR067YTpx9ratzRM5TLJMW6BD5mtMId+RnBlkD2Yol9vZzd1K nG6Q== X-Forwarded-Encrypted: i=1; AJvYcCWIuuZRKMgDOmVbU+HqB2fMZUyFYXn/JhIWkEjRLC8xfkaz+qycoRk2DyLTYfg2QcLCbwjKfAXwjAs=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzja6J6OE7IfmkXWmcSyoeb8W9QzeQTm49qpU96BP+j/WmHovXb TtH1NCPZvLKx/m0Ge4YhWMnS55NYVNXk+BpYhY7Z8da3w1204wlglMnhLrJ73Jw4ew== X-Gm-Gg: AZuq6aJ/FVxtxFN5UAxhZ+M8zSLUY8D8QHTSFGDrHzfv1+lZclv5A9n6o5sGcHEXCxx WebnV5FoYhgAixctG2Y6F41fE8TPUM6sNXV3GkL7L1QKwDl+r1tIjNeDcXzFnQ583fOAr2IEqNW nceYbCyysTV6QxTFJ13sciAazI/Jnm3ZclKSXT2YUYi7ZxN0D39ftQyVs5xXYfqIHBID6Lwa4rK pUlQEWldpVv8vDd0rCt/0Tu3YBnatzb6iaoRyAPk2zzNBqDVaENp4cKLEnyX9YpEeUD+QmrXgvW r8aW0GJQIce8mwFK4eLUdRqDDmSBRsZSRP7adyD74Rx7J/zBz4erskmJOa+bpeOYC4Cg8yd+DQx 95cyGvdhOwW9DMbPzrfB/U3fg2gW1wJA3vXCwd7W/UtO9bChsNGfDS7vQslw6UpAYzhZ9iaX5AZ uT8gZ9GlOJhCR+qqlIcFUmJbzC120zcQNtGw6ixfBXhXgGVzUi5WtUmPe0HDz/JGrSX8IrVaipQ 3g= X-Received: by 2002:a05:6000:1a8a:b0:430:f9c2:84ec with SMTP id ffacd0b85a97d-4356999d50fmr16255153f8f.26.1768827648433; Mon, 19 Jan 2026 05:00:48 -0800 (PST) Message-ID: <7387457f-104a-436d-96ae-b70c77745200@suse.com> Date: Mon, 19 Jan 2026 14:00:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/3] xen/mm: allow deferred scrub of physmap populate allocated pages To: Roger Pau Monne Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260115111804.40199-1-roger.pau@citrix.com> <20260115111804.40199-3-roger.pau@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260115111804.40199-3-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 15.01.2026 12:18, Roger Pau Monne wrote: > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -722,6 +722,15 @@ static void _domain_destroy(struct domain *d) > > XVFREE(d->console); > > + if ( d->pending_scrub ) > + { > + BUG_ON(d->creation_finished); > + free_domheap_pages(d->pending_scrub, d->pending_scrub_order); > + d->pending_scrub = NULL; > + d->pending_scrub_order = 0; > + d->pending_scrub_index = 0; > + } Because of the other zeroing wanted (it's not strictly needed, is it?), it may be a little awkward to use FREE_DOMHEAP_PAGES() here. Yet I would still have recommended to avoid its open-coding, if only we had such a wrapper already. Would this better be done earlier, in domain_kill(), to avoid needlessly holding back memory that isn't going to be used by this domain anymore? Would require the spinlock be acquired to guard against a racing stash_allocation(), I suppose. In fact freeing right in domain_unpause_by_systemcontroller() might be yet better (albeit without eliminating the need to do it here or in domain_kill()). > @@ -1678,6 +1687,14 @@ int domain_unpause_by_systemcontroller(struct domain *d) > */ > if ( new == 0 && !d->creation_finished ) > { > + if ( d->pending_scrub ) > + { > + printk(XENLOG_ERR > + "%pd: cannot be started with pending dirty pages, destroying\n", s/dirty/unscrubbed/ to avoid ambiguity with "dirty" as in "needing writeback"? > --- a/xen/common/memory.c > +++ b/xen/common/memory.c > @@ -159,6 +159,74 @@ static void increase_reservation(struct memop_args *a) > a->nr_done = i; > } > > +/* > + * Temporary storage for a domain assigned page that's not been fully scrubbed. > + * Stored pages must be domheap ones. > + * > + * The stashed page can be freed at any time by Xen, the caller must pass the > + * order and NUMA node requirement to the fetch function to ensure the > + * currently stashed page matches it's requirements. > + */ > +static void stash_allocation(struct domain *d, struct page_info *page, > + unsigned int order, unsigned int scrub_index) > +{ > + BUG_ON(d->creation_finished); Is this valid here and ... > + rspin_lock(&d->page_alloc_lock); > + > + /* > + * Drop any stashed allocation to accommodated the current one. This > + * interface is designed to be used for single-threaded domain creation. > + */ > + if ( d->pending_scrub ) > + free_domheap_pages(d->pending_scrub, d->pending_scrub_order); > + > + d->pending_scrub_index = scrub_index; > + d->pending_scrub_order = order; > + d->pending_scrub = page; > + > + rspin_unlock(&d->page_alloc_lock); > +} > + > +static struct page_info *get_stashed_allocation(struct domain *d, > + unsigned int order, > + nodeid_t node, > + unsigned int *scrub_index) > +{ > + struct page_info *page = NULL; > + > + BUG_ON(d->creation_finished && d->pending_scrub); ... here? A badly behaved toolstack could do a populate in parallel with the initial unpause, couldn't it? > + rspin_lock(&d->page_alloc_lock); > + > + /* > + * If there's a pending page to scrub check it satisfies the current > + * request. If it doesn't keep it stashed and return NULL. > + */ > + if ( !d->pending_scrub || d->pending_scrub_order != order || > + (node != NUMA_NO_NODE && node != page_to_nid(d->pending_scrub)) ) Ah, and MEMF_exact_node is handled in the caller. > + goto done; > + else > + { > + page = d->pending_scrub; > + *scrub_index = d->pending_scrub_index; > + } > + > + /* > + * The caller now owns the page, clear stashed information. Prevent > + * concurrent usages of get_stashed_allocation() from returning the same > + * page to different contexts. > + */ > + d->pending_scrub_index = 0; > + d->pending_scrub_order = 0; > + d->pending_scrub = NULL; > + > + done: > + rspin_unlock(&d->page_alloc_lock); > + > + return page; > +} Hmm, you free the earlier allocation only in stash_allocation(), i.e. that memory isn't available to fulfill the present request. (I do understand that the freeing there can't be dropped, to deal with possible races caused by the toolstack.) The use of "goto" here also looks a little odd, as it would be easy to get away without. Or else I'd like to ask that the "else" be dropped. > @@ -286,6 +365,30 @@ static void populate_physmap(struct memop_args *a) > goto out; > } > > + if ( !d->creation_finished ) > + { > + unsigned int dirty_cnt = 0, j; Declaring (another) j here is going to upset Eclair, I fear, as ... > + /* Check if there's anything to scrub. */ > + for ( j = scrub_start; j < (1U << a->extent_order); j++ ) > + { > + if ( !test_and_clear_bit(_PGC_need_scrub, > + &page[j].count_info) ) > + continue; > + > + scrub_one_page(&page[j], true); > + > + if ( (j + 1) != (1U << a->extent_order) && > + !(++dirty_cnt & 0xff) && > + hypercall_preempt_check() ) > + { > + a->preempted = 1; > + stash_allocation(d, page, a->extent_order, ++j); Better j + 1, as j's value isn't supposed to be used any further? > + goto out; > + } > + } > + } > + > if ( unlikely(a->memflags & MEMF_no_tlbflush) ) > { > for ( j = 0; j < (1U << a->extent_order); j++ ) ... for this to work there must already be one available from an outer scope. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 19 14:46:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 14:46:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208126.1520359 (Exim 4.92) (envelope-from ) id 1vhqVj-0008Gz-3K; Mon, 19 Jan 2026 14:45:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208126.1520359; Mon, 19 Jan 2026 14:45: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 1vhqVj-0008Gs-04; Mon, 19 Jan 2026 14:45:43 +0000 Received: by outflank-mailman (input) for mailman id 1208126; Mon, 19 Jan 2026 14:45: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 1vhqVi-0008Gm-D0 for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 14:45:42 +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 8623d1f0-f545-11f0-b15e-2bf370ae4941; Mon, 19 Jan 2026 15:45:40 +0100 (CET) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-432d2c7a8b9so3826016f8f.2 for ; Mon, 19 Jan 2026 06:45:40 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4356992201csm24093209f8f.2.2026.01.19.06.45.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jan 2026 06:45:39 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8623d1f0-f545-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768833939; x=1769438739; 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=loz6VaQwHDOaYVDwdyAXRHZWLIJTAzZg2oeK0GPCLSc=; b=SOgtBlCN/6K++OA1q6kNcYxToEYK3+bcrj2zMT4DT4t+Q2rXTqadyp5KQwuSzItPZB r6hxdvmCLnJgeRJNNMaz4FA/DOmi/cgsJwUgQ8zuASsTWV7ruhLoNkPwnlQ0c0Ap7oKF 4O6R/mMqeTpUyrVLIFZ4PsuFmViN5+j1vOTWWNcZLMQDLEuHEw5nAgABQfYW16vUrmh/ Q1KsPG/4kWTk97ThvX/lfEaZwYXiwmOzpPM9X919SGWFHy2EzqqXduvmLhi9lH2SjRm8 mqPFXalmhjf+g/aB/sWH/1tWNvGwQSy4z/cdmwobBVfuz8B2+MNPN/nX3rINETUaKTJi MCBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768833939; x=1769438739; h=content-transfer-encoding:autocrypt:content-language:cc:to:subject :from:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=loz6VaQwHDOaYVDwdyAXRHZWLIJTAzZg2oeK0GPCLSc=; b=gQBWODwP655rIit7MtvcY3ooOqQvNEJUzjVG7Z1kIR5DfdPu2q7tSWvbC001dlr3Pm x+YnrTaENKUd2vflw6zPgTNoSlNtqxBwXliMl3SS7atOX29aOImK6i90j9JIdm5Qv5Wb PwA259xVSdXnFnJhoC6DhdkbooW61CSWDhC0oWIRRwhv4lWkjfyX+ocD15JjAFXqMRVm WjBfAjis7Sfqk6eTUwaWkVnHR/8JN5JDDvs6SSmnjvrWmsZvny6MJBBDNIjC/Hqpbrz6 0jHfEMls7J+lvyM1fme4C5ldhj73v2s6xZ/T3yr9aZkhEf/P2u0RKYykb0Jph6AyHUc0 vlXQ== X-Gm-Message-State: AOJu0YwfK0uUP+KnAxPPP+LGXZ5c0cE54Tb1d8VCOeIkiXR5JJa5zBvG La04T1QYZhQi4luC/ZAPFmalpyzUFjdQmt0Mn8UeD5fwmMtPH3pmvKfHLu9G88vhgTW3CHtCW2F Yigw= X-Gm-Gg: AZuq6aJ39qOojSswQPpKYmjyS12iKhJjPtT9HpZDvup+fchBYUDRCqc3DDmYC6SPR3z v+rNtzQKeEI40AnbRsMmiM1fNHQjSH97RGgqvdOkn9JqWUvgRGdrkhK2nubD+zfuWDbzg+b2hs6 cXUd2VkrQAPj6xidXDaplgrqSuPD4ExYmvAtIVmm7IWOefkvfiS2O8Q6qquP0Plm/toZgrvcbDZ 3iY4ViwBZ2dUx0Vp6Q37y7+/2PGMh0ex6lTuBrQUeQ4bMlo9iKpsTG/5v00FyXFzN7G8bFso0t/ wo1bv4R/T3lk1IZxXOYffZib2qpwY5vWbjj3SeYbg9HxMTnEqot3Vkf3eOZBiuU6YVs4rJrzD03 iMVkoBb0qMGNzhM0U6Q0OC6q75C+Luq8yP/mHGNAqt71F/Gu0W9qDVAGoVRlJL9AFmJUhSskM0H Bu4a3ebItGHnwgdpW8FqrYJWVnMKXqyBfqevGjgAkPnn9ELdHGH7Of90fYaJs5jRaX8zrp8IPm7 Lk= X-Received: by 2002:a05:6000:428a:b0:430:f5ed:83ee with SMTP id ffacd0b85a97d-4356a03323fmr12832537f8f.7.1768833939576; Mon, 19 Jan 2026 06:45:39 -0800 (PST) Message-ID: <58091dc1-7bda-4536-8200-2d0a5679d4d1@suse.com> Date: Mon, 19 Jan 2026 15:45:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jan Beulich Subject: [PATCH v2 0/4] (v)PCI: extended capability handling 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?= , Stewart Hildebrand Content-Language: en-US Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This is a follow-on to 'vPCI: avoid bogus "overlap in extended cap list" warnings', addressing further issues noted there. v2: New first patch and significantly re-worked 2nd one. See there. 1: PCI: handle PCI->PCIe bridges as well in alloc_pdev() 2: PCI: determine whether a device has extended config space 3: PCI: don't look for ext-caps when there's no extended cfg space 4: vPCI/DomU: really no ext-caps without extended config space Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 19 14:46:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 14:46:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208131.1520368 (Exim 4.92) (envelope-from ) id 1vhqWX-0000F1-CH; Mon, 19 Jan 2026 14:46:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208131.1520368; Mon, 19 Jan 2026 14: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 1vhqWX-0000Eu-9F; Mon, 19 Jan 2026 14:46:33 +0000 Received: by outflank-mailman (input) for mailman id 1208131; Mon, 19 Jan 2026 14:46: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 1vhqWW-0000Ek-67 for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 14:46:32 +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 a46d932c-f545-11f0-b15e-2bf370ae4941; Mon, 19 Jan 2026 15:46:31 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-47ee4338e01so17856695e9.2 for ; Mon, 19 Jan 2026 06:46:31 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43569926ff1sm23285772f8f.13.2026.01.19.06.46.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jan 2026 06:46:30 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a46d932c-f545-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768833990; x=1769438790; 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=xnRmTKXNteKMqdZEfaFQJUrsWcgVdqBEXTb4msepQGA=; b=fzxAM5LHtstpodnYk6gZik5wMRfgUlFcrxYMH3MzZoR2CfhZvg59HfEQGkD1rk3sof MmFS7pNhaoXwlfbB26p3FCmRJ1jlL8ZDBCkSQA+m5Nl92HnFWlkc1d7yR3z0maZwOj7w HRpmOZ6rfhHqekWEWG7i/3ac+ZW/fEAI3OW+w03llZ0KfTDtYeqdbhJ6k73okMGSCDiW fvEI2w1gFp8yQiykmZeFGfe6zopiGK3wDm0YOqDgGndxRkl0UxUtybzUWkoQCAwDJXr9 NQ9C/PZz6lfjwLN0qQYTj2tXm08CYBQNSPBGHm2Og463k6UChDX21GWtI9IymLPuyeFK pLew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768833990; x=1769438790; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xnRmTKXNteKMqdZEfaFQJUrsWcgVdqBEXTb4msepQGA=; b=jo885fV91QoDYB1sfHpm2w29TqtiKu9oOtAwJFhFEF1IynmfB1Ib9nGe2j8/rLd5tV vrNELBjcsfjYIyd20PLnOeh/Mwv52x98GUU7tG0HSq250X8btnK5VaqwIeAKqi5g25XD oGJcTsWa8eaE/hlTGGY5jtaDViKaFdBQp4t5oxLkIQDhxgQIHi+eFVtPubZvdu8bbL5d zZCzEDCJHMc8B3wGfrRlD3rbpLhQavad0YVyW0srmteeoN1iC80fZ9pxCsbAQw6je/DD mjmMbFM4PQfMjGEvQlWXx3KoOBSggfai4y98JXm4BU2huSAx+9zB2LmqwMv/hON0GZg/ BYdw== X-Gm-Message-State: AOJu0YwQ0TpMvftWjRNwfhme0Hbc1aozmIajwRkSpEPR+qQc3/HCy489 7V32fOrCRdDk9pCqtTvAh7AWNKtflXhxsFgJMTuKzXp0fKdlMtz2A3Jn0xMGvUmMPOta/yAMy6G eEbA= X-Gm-Gg: AY/fxX4qJPOMv+wOJYsDBSWAfqAt0g6QBLh7an8TA8e0g4ZAUw66PQywAqFf0a+BMKM dMBDufznPo33PEwOIt3eH21kFxZRcqqx5O6G5SGxyniZdLKOagYrU0j9amRuBjn7zZGFdvZW2Kj g5vueQ/rwVfPJdiEjMGLhjViGcpPQ7+G4+pxz/rIx1YBg8VVVg6//AnCU/qk9Ei6UFIA5b7YivP vRrNAWOAWOpPI7askf3Q+KzNhja4VX02mIcqD/E4LKkbqaUY8jhc9WzgnAKvIId/PwBLnRwC7Dt u+H5OYNqYeA146vSJ5agTSM5pK0che3jrEZszZ4RVEGiPoru1851lIcJpu1FBpdR9RXBwryp5zX iIWVXmsnS46bfNx02sHeeXjIioeof2445Zwg+0Ny15ikr+NzU7xisFmZq66KjF4zAeUFMcjEMUh fWvadZGVmKCxKOUq6rw5ViSXe/Kim9fGfEI6ecmGhNg08RMIVFx4chN2NlVLe0KCcD7CdJhaaOb 4A= X-Received: by 2002:a05:600c:6489:b0:459:db7b:988e with SMTP id 5b1f17b1804b1-4801eac331bmr135763005e9.13.1768833990294; Mon, 19 Jan 2026 06:46:30 -0800 (PST) Message-ID: Date: Mon, 19 Jan 2026 15:46:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v2 1/4] PCI: handle PCI->PCIe bridges as well in alloc_pdev() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand References: <58091dc1-7bda-4536-8200-2d0a5679d4d1@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: <58091dc1-7bda-4536-8200-2d0a5679d4d1@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit It's not clear why the enumerator was omitted, as these clearly shouldn't take the "default" path (issuing a warning). Handle them the same as legacy and PCIe->PCI bridges. Fixes: e7e08d86ad2f ("IOMMU/PCI: consolidate pdev_type() and cache its result for a given device") Signed-off-by: Jan Beulich --- v2: New. --- a/xen/drivers/passthrough/pci.c +++ b/xen/drivers/passthrough/pci.c @@ -351,6 +351,7 @@ static struct pci_dev *alloc_pdev(struct unsigned long flags; case DEV_TYPE_PCIe2PCI_BRIDGE: + case DEV_TYPE_PCI2PCIe_BRIDGE: case DEV_TYPE_LEGACY_PCI_BRIDGE: sec_bus = pci_conf_read8(pdev->sbdf, PCI_SECONDARY_BUS); sub_bus = pci_conf_read8(pdev->sbdf, PCI_SUBORDINATE_BUS); From xen-devel-bounces@lists.xenproject.org Mon Jan 19 14:46:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 14:46:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208139.1520379 (Exim 4.92) (envelope-from ) id 1vhqWu-0000hN-JG; Mon, 19 Jan 2026 14:46:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208139.1520379; Mon, 19 Jan 2026 14:46:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhqWu-0000hE-GE; Mon, 19 Jan 2026 14:46:56 +0000 Received: by outflank-mailman (input) for mailman id 1208139; Mon, 19 Jan 2026 14:46:55 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhqWt-0000Ek-5y for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 14:46:55 +0000 Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [2a00:1450:4864:20::444]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b2770eaa-f545-11f0-b15e-2bf370ae4941; Mon, 19 Jan 2026 15:46:54 +0100 (CET) Received: by mail-wr1-x444.google.com with SMTP id ffacd0b85a97d-43284ed32a0so2439382f8f.3 for ; Mon, 19 Jan 2026 06:46:54 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4356996cf42sm23755497f8f.20.2026.01.19.06.46.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jan 2026 06:46:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b2770eaa-f545-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768834014; x=1769438814; 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=+dUkXgiK2DH2wyqqSUw4eWQiqTgrfXkQw7d9LrW88Ck=; b=OvivTaFxonCBinYv5MWrG0oEcMTfSuD8J4n6yNBHe2MjAyYkgn6sgPMUtpb1oNeC3P 8yxOF1hpt/NN5Ap5NlTbBCQhCKTxD3Oxn/Dj6UE/KdsxZsLqvt/DtkrP4Q5RHQIrOgvu 7zw/MrKITyD+Q8jljQM4YMSLvuSwTYkJdhp6qtMnBp+CnY6MIu/EsSG2ALDf2oLsGnKW l2YenEFdj6FyHQcH9GW6OB6HxyioJUPbxNo+G+spnvlyJy3YLJbLGePAGD0robpsj2fy GPS2ckPWmOF1ITJkX7OPuop8VvX9Cp4I9JF3w6ILE2dTYNzGSGHyASGNllPYuoWCFkxD JvvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768834014; x=1769438814; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+dUkXgiK2DH2wyqqSUw4eWQiqTgrfXkQw7d9LrW88Ck=; b=lB1+HJiTIF8X70yrGkbypIxMjL4TnCF/RNA1hnbqRPjfBN1iU6k3RGmvsgfW8sIXrG X8wy0av+WN3DIwKmJ5QBd345eCXY2ehNkpsZl2FiwmHzpo2NZxvzN3nLrn4yx6KW3NYZ 4WHJNfVTMbkwX0vIiFKxyGanCdtaxhPePVmlznSCNarakZttSA/SJNWGAjzV6JEHmyOE bphKNpSleoXwP4jdAZ+WAMBJFLxdPTLuh4/jtg6o3dBRFpughCAqLzdeb/fSUesJ6Utn DXg+SRabaHyeRbR1OMWGBU4UMv5r/Jw88HaIq0bFAwgxh9v3xnr5P8xczCM3NcRAhTyr S6VQ== X-Gm-Message-State: AOJu0Yxp2XPrrXRQkjChAuKIvuJlvvwVyfyzapqJQGv83/fhuVCZKRv2 P/jrpam86WCzTHXtEbwl10+FLg0Ew/4G6vO5ci2IEwYcITp+NCJy9IlFqkscTDNOl4u0518t0aK oqQ6CcQ== X-Gm-Gg: AZuq6aIHi8C7KkU4f5cLP7NMJdvgx47ix2fPF9u0/bCNqO/6pF+vy0GYHdbmucMwSpc y4Ritdeu5x1dY7PvlLsRalykeWAEi9puCnCReuKC0hEhPU30Tr8i+jn/lvCEgmbOhzeoSh6HjM4 QVQX/o7MtFn7M1nR4o5k5jB6GoOte14Z/jnVstkoiZe15Y+j5lutK4PGb5UPV6g7H/ieRie+Cj3 qePPFfx63tXj7z+HBVwbMambcfxLKlQpiIMvmT89nf+puRylWw6HXTfR5Rx1lJPQz9BUNPneU0g iY2/oxYgZwpW3Nbon2Toj8Y7HYEYjwRrR3SfjLR80qCjjEwv1auvu7NT2bxnp+KDddMGJA+Zj6p kHM/6Gp+QEs4HGZaGObDE+yJk9Yixs1A82EoiL9ls7gx3mb0+gC/pRNdlC4JlpXA/h2D2BcUIMC J/si3rXQ8sYVD3LZ8n+DVHWxKJofAN7W/i4nXz8YaoHokq41SYNoJRxs+bJUzn1adklhIcUvE1H +s= X-Received: by 2002:a5d:5f94:0:b0:431:1d4:3a8a with SMTP id ffacd0b85a97d-43569972d22mr13740605f8f.7.1768834013906; Mon, 19 Jan 2026 06:46:53 -0800 (PST) Message-ID: Date: Mon, 19 Jan 2026 15:46:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v2 2/4] PCI: determine whether a device has extended config space From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand References: <58091dc1-7bda-4536-8200-2d0a5679d4d1@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: <58091dc1-7bda-4536-8200-2d0a5679d4d1@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Legacy PCI devices don't have any extended config space. Reading any part thereof may return all ones or other arbitrary data, e.g. in some cases base config space contents repeatedly. Logic follows Linux 6.19-rc's pci_cfg_space_size(), albeit leveraging our determination of device type; in particular some comments are taken verbatim from there. Signed-off-by: Jan Beulich --- Should we skip re-evaluation when pci_mmcfg_arch_enable() takes its early exit path? The warning near the bottom of pci_check_extcfg() may be issued multiple times for a single device now. Should we try to avoid that? Note that no vPCI adjustments are done here, but they're going to be needed: Whatever requires extended capabilities will need re- evaluating / newly establishing / tearing down in case an invocation of PHYSDEVOP_pci_mmcfg_reserved alters global state. Linux also has CONFIG_PCI_QUIRKS, allowing to compile out the slightly risky code (as reads may in principle have side effects). Should we gain such, too? --- v2: Major re-work to also check upon PHYSDEVOP_pci_mmcfg_reserved invocation. --- a/xen/arch/x86/physdev.c +++ b/xen/arch/x86/physdev.c @@ -22,6 +22,8 @@ int physdev_map_pirq(struct domain *d, i struct msi_info *msi); int physdev_unmap_pirq(struct domain *d, int pirq); +int cf_check physdev_check_pci_extcfg(struct pci_dev *pdev, void *arg); + #include "x86_64/mmconfig.h" #ifndef COMPAT @@ -160,6 +162,17 @@ int physdev_unmap_pirq(struct domain *d, return ret; } + +int cf_check physdev_check_pci_extcfg(struct pci_dev *pdev, void *arg) +{ + const struct physdev_pci_mmcfg_reserved *info = arg; + + ASSERT(pdev->seg == info->segment); + if ( pdev->bus >= info->start_bus && pdev->bus <= info->end_bus ) + pci_check_extcfg(pdev); + + return 0; +} #endif /* COMPAT */ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) @@ -511,6 +524,11 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H ret = pci_mmcfg_reserved(info.address, info.segment, info.start_bus, info.end_bus, info.flags); + + if ( !ret ) + ret = pci_segment_iterate(info.segment, physdev_check_pci_extcfg, + &info); + if ( !ret && has_vpci(currd) && (info.flags & XEN_PCI_MMCFG_RESERVED) ) { /* --- a/xen/drivers/passthrough/pci.c +++ b/xen/drivers/passthrough/pci.c @@ -422,6 +422,9 @@ static struct pci_dev *alloc_pdev(struct } apply_quirks(pdev); + + pci_check_extcfg(pdev); + check_pdev(pdev); return pdev; @@ -718,6 +721,11 @@ int pci_add_device(u16 seg, u8 bus, u8 d list_add(&pdev->vf_list, &pf_pdev->vf_list); } + + if ( !pdev->ext_cfg ) + printk(XENLOG_WARNING + "%pp: VF without extended config space?\n", + &pdev->sbdf); } } @@ -1041,6 +1049,75 @@ enum pdev_type pdev_type(u16 seg, u8 bus return pos ? DEV_TYPE_PCIe_ENDPOINT : DEV_TYPE_PCI; } +void pci_check_extcfg(struct pci_dev *pdev) +{ + unsigned int pos, sig; + + pdev->ext_cfg = false; + + switch ( pdev->type ) + { + case DEV_TYPE_PCIe_ENDPOINT: + case DEV_TYPE_PCIe_BRIDGE: + case DEV_TYPE_PCI_HOST_BRIDGE: + case DEV_TYPE_PCIe2PCI_BRIDGE: + case DEV_TYPE_PCI2PCIe_BRIDGE: + break; + + case DEV_TYPE_LEGACY_PCI_BRIDGE: + case DEV_TYPE_PCI: + pos = pci_find_cap_offset(pdev->sbdf, PCI_CAP_ID_PCIX); + if ( !pos || + !(pci_conf_read32(pdev->sbdf, pos + PCI_X_STATUS) & + (PCI_X_STATUS_266MHZ | PCI_X_STATUS_533MHZ)) ) + return; + break; + + default: + return; + } + + /* + * Regular PCI devices have 256 bytes, but PCI-X 2 and PCI Express devices + * have 4096 bytes. Even if the device is capable, that doesn't mean we + * can access it. Maybe we don't have a way to generate extended config + * space accesses, or the device is behind a reverse Express bridge. So + * we try reading the dword at PCI_CFG_SPACE_SIZE which must either be 0 + * or a valid extended capability header. + */ + if ( pci_conf_read32(pdev->sbdf, PCI_CFG_SPACE_SIZE) == 0xffffffffU ) + return; + + /* + * PCI Express to PCI/PCI-X Bridge Specification, rev 1.0, 4.1.4 says that + * when forwarding a type1 configuration request the bridge must check + * that the extended register address field is zero. The bridge is not + * permitted to forward the transactions and must handle it as an + * Unsupported Request. Some bridges do not follow this rule and simply + * drop the extended register bits, resulting in the standard config space + * being aliased, every 256 bytes across the entire configuration space. + * Test for this condition by comparing the first dword of each potential + * alias to the vendor/device ID. + * Known offenders: + * ASM1083/1085 PCIe-to-PCI Reversible Bridge (1b21:1080, rev 01 & 03) + * AMD/ATI SBx00 PCI to PCI Bridge (1002:4384, rev 40) + */ + sig = pci_conf_read32(pdev->sbdf, PCI_VENDOR_ID); + for ( pos = PCI_CFG_SPACE_SIZE; + pos < PCI_CFG_SPACE_EXP_SIZE; pos += PCI_CFG_SPACE_SIZE ) + if ( pci_conf_read32(pdev->sbdf, pos) != sig ) + break; + + if ( pos >= PCI_CFG_SPACE_EXP_SIZE ) + { + printk(XENLOG_WARNING "%pp: extended config space aliases base one\n", + &pdev->sbdf); + return; + } + + pdev->ext_cfg = true; +} + /* * find the upstream PCIe-to-PCI/PCIX bridge or PCI legacy bridge * return 0: the device is integrated PCI device or PCIe @@ -1841,6 +1918,29 @@ int pci_iterate_devices(int (*handler)(s return pci_segments_iterate(iterate_all, &iter) ?: iter.rc; } +/* Iterate a single PCI segment, with locking but without preemption. */ +int pci_segment_iterate(unsigned int segment, + int (*handler)(struct pci_dev *pdev, void *arg), + void *arg) +{ + struct pci_seg *seg = get_pseg(segment); + struct segment_iter iter = { + .handler = handler, + .arg = arg, + }; + + if ( !seg ) + return -ENODEV; + + pcidevs_lock(); + + iter.rc = iterate_all(seg, &iter) ?: iter.rc; + + pcidevs_unlock(); + + return iter.rc; +} + /* * Local variables: * mode: C --- a/xen/include/xen/pci.h +++ b/xen/include/xen/pci.h @@ -126,6 +126,9 @@ struct pci_dev { nodeid_t node; /* NUMA node */ + /* Whether the device has (accessible) extended config space. */ + bool ext_cfg; + /* Device to be quarantined, don't automatically re-assign to dom0 */ bool quarantine; @@ -242,6 +245,11 @@ void pci_check_disable_device(u16 seg, u int pci_iterate_devices(int (*handler)(struct pci_dev *pdev, void *arg), void *arg); +/* Iterate a single PCI segment, with locking but without preemption. */ +int pci_segment_iterate(unsigned int segment, + int (*handler)(struct pci_dev *pdev, void *arg), + void *arg); + uint8_t pci_conf_read8(pci_sbdf_t sbdf, unsigned int reg); uint16_t pci_conf_read16(pci_sbdf_t sbdf, unsigned int reg); uint32_t pci_conf_read32(pci_sbdf_t sbdf, unsigned int reg); @@ -260,6 +268,7 @@ unsigned int pci_find_next_cap_ttl(pci_s unsigned int *ttl); unsigned int pci_find_next_cap(pci_sbdf_t sbdf, unsigned int pos, unsigned int cap); +void pci_check_extcfg(struct pci_dev *pdev); unsigned int pci_find_ext_capability(const struct pci_dev *pdev, unsigned int cap); unsigned int pci_find_next_ext_capability(const struct pci_dev *pdev, From xen-devel-bounces@lists.xenproject.org Mon Jan 19 14:47:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 14:47:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208149.1520390 (Exim 4.92) (envelope-from ) id 1vhqXV-0001MP-0g; Mon, 19 Jan 2026 14:47:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208149.1520390; Mon, 19 Jan 2026 14: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 1vhqXU-0001MG-St; Mon, 19 Jan 2026 14:47:32 +0000 Received: by outflank-mailman (input) for mailman id 1208149; Mon, 19 Jan 2026 14: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 1vhqXT-0001Lt-21 for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 14:47:31 +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 c69c21aa-f545-11f0-9ccf-f158ae23cfc8; Mon, 19 Jan 2026 15:47:29 +0100 (CET) Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-42fbc305882so2451681f8f.0 for ; Mon, 19 Jan 2026 06:47:28 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43569921da2sm23567771f8f.1.2026.01.19.06.47.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jan 2026 06:47:27 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c69c21aa-f545-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768834048; x=1769438848; 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=2cfIXKgHYTFCKsrX1bFpAF8sQFG6ytaJSHI//BPGSL8=; b=SBQKG6gNmS7B0g+ci15OQ5lXx425LxvWxv5ZGep241pwPi5PUk1vxVqZqFujrVbyXD X11qFOugvvdvpOC6KZ5wSTC0Wut58JaHzW2X+ocUTnQxUjJ+Q2D/W6EejR+3+bQZmJXc 6+rnYq3/6knc2t1DGTquuP+jDW2pWdfIrg5s97qZ32K6plRWOVsja3GsQL1GJi0P8SjW 9GxfStn3l7zcRhwrM63NSIC6EpEC1Zo6sdaNCYf7NJkb+tvTt5yGEF931dfpxwoUOZl8 /5sqTHhSP0zHjdOG6sYblFhCiHGvd6rBhKpqzPCPI8RgCHkxxzsDqim8iRHK/D4xY7fZ tTEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768834048; x=1769438848; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2cfIXKgHYTFCKsrX1bFpAF8sQFG6ytaJSHI//BPGSL8=; b=xH/XC4QK6q1aMqqOGGoL19+T7McWqnVfsRox7ysQUmxdOw7Qo3+LwZm5V+un8Rcltp xdZTyWKRol4c7XGn7k6nGtgDAqQYReu0ceyxeShhGVxseGkmNfAbRae5qcFINdEsIk3m q9SUC1WZX/ih16I3raWmiZ8Cjsl0AWcOm39fDXzD/P2kKCa/PqwZ/bXJWRP4CSmBppwo c5eNTVVd+OUju535MpSIEc0D0JbpNlAMVOAA+71z8K2mQsalac/+/CJrs9SzPdopxOKf HqA3oiku0lHdd8KDPesrSWKVaOSIdmxAsg+8V4mQXSSSa0GQQyxgvRC9CrIviAuy/8Ge BJEg== X-Gm-Message-State: AOJu0Yxg1gWXPdzPZP15ky0bPHRoyWtaxJITpEz0iXVMW5F3AbYNZavX 9SjETbfdfGKpYR85AQLkS0uKliklyNN1ECqe2voUU0YvgQ0Mil/CKcsIgwOPkYsP/RDfYpzKQUi PG7g= X-Gm-Gg: AZuq6aK4TSxuhOVcI7Ybv2CzsuPldkxH1nGtyDEO5vUdwICYBtxCmACpXkmVFEdp/9M YlCL63A7tTPAJTS3EgZ7XgjNTI/aGgLAziqJtFTP/Fh4kv2jAP3QHW0XyfhnvrtoCh9lF9PInLl HwdpVfrsjH5GifpBVWSRorjElP2nakHrShPUh0NQMkaQDbwYBx6WnLxMniNZ/vScxtUY3oT89C+ l35mzFIfW97FnGOS4MNOgbOhykG9068asbEusmF1UkBkCab4R08FhWxzlM4yZerfzCFm3szgU7l rTlqm2AfH/C0ula7uLCkpl7/TIzEqcQr2Pv8JTGnvi8Mf0np9PEMPTCvS6t/fI2CMxt1D4lPyiL nIf53kkk2F5fVDlAGozJKBMerxTUq1PuHsCZ2UiRPBsHtfHcnrEVxx/pZDujkcLlUf7qCjVULdp xAsR4quXl9yA9YQsDDpPWk/hXRwekJFD4VpQFxB7rJGC33fTOOe1wU67ngKRmRfPHoU2XGOaaXT Dg= X-Received: by 2002:a05:6000:2c13:b0:430:f742:fbc8 with SMTP id ffacd0b85a97d-43569972d7bmr13723591f8f.6.1768834047591; Mon, 19 Jan 2026 06:47:27 -0800 (PST) Message-ID: <133c1cb0-bdb6-4c9a-bea8-c50f42ce58d7@suse.com> Date: Mon, 19 Jan 2026 15:47:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v2 3/4] PCI: don't look for ext-caps when there's no extended cfg space From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand References: <58091dc1-7bda-4536-8200-2d0a5679d4d1@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: <58091dc1-7bda-4536-8200-2d0a5679d4d1@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Avoid interpreting as extended capabilities what may be about anything. In doing so, vPCI then also won't mis-interpret data from beyond base config space anymore. Fixes: 3b35911d709e ("Enable pci mmcfg and ATS for x86_64") Fixes: a845b50c12f3 ("vpci/header: Emulate extended capability list for dom0") Signed-off-by: Jan Beulich --- Because of the multiple prereq changes, despite the Fixes: tags I'm not quite sure whether to backport this. (I'm leaning towards "no".) --- a/xen/drivers/pci/pci.c +++ b/xen/drivers/pci/pci.c @@ -113,6 +113,12 @@ unsigned int pci_find_next_ext_capabilit int ttl = 480; /* 3840 bytes, minimum 8 bytes per capability */ unsigned int pos = max(start, PCI_CFG_SPACE_SIZE + 0U); + if ( !pdev->ext_cfg ) + { + ASSERT(!start); + return 0; + } + header = pci_conf_read32(pdev->sbdf, pos); /* From xen-devel-bounces@lists.xenproject.org Mon Jan 19 14:48:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 14:48:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208161.1520398 (Exim 4.92) (envelope-from ) id 1vhqXy-0001r4-7Y; Mon, 19 Jan 2026 14:48:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208161.1520398; Mon, 19 Jan 2026 14:48:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhqXy-0001qx-4j; Mon, 19 Jan 2026 14:48:02 +0000 Received: by outflank-mailman (input) for mailman id 1208161; Mon, 19 Jan 2026 14:48: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 1vhqXx-0000Ek-9C for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 14:48:01 +0000 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [2a00:1450:4864:20::336]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d9c8ef6d-f545-11f0-b15e-2bf370ae4941; Mon, 19 Jan 2026 15:48:00 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-47ee4338e01so17864775e9.2 for ; Mon, 19 Jan 2026 06:48:00 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4356996dad0sm23506468f8f.27.2026.01.19.06.47.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jan 2026 06:47:59 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d9c8ef6d-f545-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768834080; x=1769438880; 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=LxIHHnoWmRfEZQKRp7c/KawtwyGIc/YRyMoiBmbjtBI=; b=TxLaI9HOXth5fRHyIUzPjqNZQ/ALpBNqQAdYSVadlU7apUJdF09BgIAr25iW0Dx4vd DFjR/2czV2Yw1lf4/lHA6lzSWWisPIkVeqwlAQTZWkm1VeS71kBZlrlryFg3IhDTpUUw elTM7fXLAEjzS2CSHAHfYht9460x/3XZ5c+gMTv2qPADdQ2c3FniwTJpPBRo0g478ei8 Tgv/0TehDcKJV3aPNKPSzj8FsejjFYw1FtAh+7Id05fUjGLKw/umx62oUqZiQABb0VTp UwOCJaSOlD4DimMFxpVUAwHvT0vrhH/Y2cxsx6vUPM3kZH/yBmaKD1aIVmLX5HAWBW6v aShA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768834080; x=1769438880; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=LxIHHnoWmRfEZQKRp7c/KawtwyGIc/YRyMoiBmbjtBI=; b=jAY7K+3u/QGxsci/KC+WjuokVd8MrjtIbGe27pY+KzExfixf0PSLj9aQXrnT4Rt0Sy rWc1FAaSW2nAES7fb90q4qAZHieVjpYNaJTxrLLAIJ9u7keuvrM+p+T8tfeVbQaOn+k9 nALC4PGYPPa/0fsKiRe8fKjSoABv+qWcDSHdIMPGVbe/IIDAlP3tLMFuOap1gz4yPcA2 UEPijMY/SowRakrNSn74+YvA8YFjP0/5+qSClp3tFdG7Tekzgs21pzQAeHDVJbEKsn6m fyvJcF+xVfY/mY63rzUAbA3Z9lzAIY/AMOWcGDyg5iVWY2FIzkaP/OsY6hmt/d7e+GEZ OTOg== X-Gm-Message-State: AOJu0YyFGVglj6FjUY4QEVowa0QgV+f6cBbld5a4xxop/n9R06WA04K6 A0SgjEItb2q4O+TiM9yJGv4LgRHLm9a63VFbiTlLQxbBT0Zz9wRHty4s6VLW7kzok8GDl3SRcRd lBjg= X-Gm-Gg: AY/fxX4ltqcCjE2sDxeUotr4Ohvhi67PzdJXIUeTmDAZSWzgVmDvn3VSfPvFbcG4dJx nlo9f/mF9D8tmT1f57FaJEVeavb0a1/1aOgVSwb1qdvu0hIQYk3J69vAL7JqLU6vFUMRXX5xgQ/ yT+RhZaigJNzczvzxtejUmtnu3nzEMqlv+bw0n1xZZcjm0QjNlSpyZ62kThEymdht0YX28Ps2LW APBF7q7Y720Jj87+P0EPLZE4zO9X3Zm9meCQ+kGHNhePSX9v55jcGY9zDwhXbrwuY3jDkQ+LL8u kNilLvwFLDi7YghZCO9c4yCjJaGvLrcPSIYZO7Edb2WwmHh6pzCx9SorAThmZC5ltNnRQgGd972 aP3KvTx3Mq4WqQ903EQkesp899JSt75VDiTwCuC6RZFVOOoIY9LAR/MiE6oyjtzTB/LY9OslGWQ MWMyRggYpBh0egCevZjypN14zwN/crcISaz3jComFHtcKPXGK5tAz3kulsJtl2LLC1sSk+copYK qQ= X-Received: by 2002:a05:600c:4e15:b0:46e:37a7:48d1 with SMTP id 5b1f17b1804b1-4801eb181a8mr149210435e9.34.1768834079918; Mon, 19 Jan 2026 06:47:59 -0800 (PST) Message-ID: <96e90685-3321-4884-8fe7-f083c25ba7ab@suse.com> Date: Mon, 19 Jan 2026 15:48:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v2 4/4] vPCI/DomU: really no ext-caps without extended config space From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand References: <58091dc1-7bda-4536-8200-2d0a5679d4d1@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: <58091dc1-7bda-4536-8200-2d0a5679d4d1@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Whether to emulate accesses to the first 32 bits of extended config space as read-as-zero or read-as-all-ones depends on whether a device actually has extended config space. If it doesn't, read-as-zero isn't correct; not getting this right may confuse functions like Linux 6.19-rc's pci_ext_cfg_is_aliased(). Fixes: a845b50c12f3 ("vpci/header: Emulate extended capability list for dom0") Signed-off-by: Jan Beulich --- a/xen/drivers/vpci/header.c +++ b/xen/drivers/vpci/header.c @@ -830,9 +830,14 @@ static int vpci_init_ext_capability_list unsigned int pos = PCI_CFG_SPACE_SIZE; if ( !is_hardware_domain(pdev->domain) ) + { + if ( !pdev->ext_cfg ) + return 0; + /* Extended capabilities read as zero, write ignore for DomU */ return vpci_add_register(pdev->vpci, vpci_read_val, NULL, pos, 4, (void *)0); + } do { From xen-devel-bounces@lists.xenproject.org Mon Jan 19 14:50:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 14:50:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208173.1520409 (Exim 4.92) (envelope-from ) id 1vhqZv-00030s-J5; Mon, 19 Jan 2026 14:50:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208173.1520409; Mon, 19 Jan 2026 14: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 1vhqZv-00030J-FX; Mon, 19 Jan 2026 14:50:03 +0000 Received: by outflank-mailman (input) for mailman id 1208173; Mon, 19 Jan 2026 14:50:02 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhqZu-0002nZ-Tw for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 14:50:02 +0000 Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [2a00:1450:4864:20::444]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2223a6ec-f546-11f0-b15e-2bf370ae4941; Mon, 19 Jan 2026 15:50:01 +0100 (CET) Received: by mail-wr1-x444.google.com with SMTP id ffacd0b85a97d-42fed090e5fso2431348f8f.1 for ; Mon, 19 Jan 2026 06:50:01 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4356992211dsm23708041f8f.7.2026.01.19.06.50.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jan 2026 06:50:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2223a6ec-f546-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768834201; x=1769439001; 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=S/pRPN4mA6rQjbWVU7QO8eHswIF88XWsdDte4GY6FaQ=; b=F2lWB4eYlh54wbyX8ulIlTiAF3dedm8Zw37306c3dG4gC7MP54G36C3mcoaXjUhKgV vQUY8Y7wpMPuq9oJOG/FFWgn8BHv+juvG+5/AfGzRum1MVyA396OSNr72EwFmH78O2N0 CBKjJ1VAmR85i5aguMcA13ygR4vPoqpomTMQzaiDMEotD0F995VOOVLuoxiHbOY8ebFU lPhUBsCAO5mq6TF5s5Z359el+fu36it2Qr9j2pfkbowMc0r0E6PjZWH5ECcmrBYbz4Md EvTfsryOLbZc8JrGfuhuHyhcNA9wQOfun30Qu7bAVGZcF3FU3wHbDF20tEmdlZRaxgKL X03g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768834201; x=1769439001; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=S/pRPN4mA6rQjbWVU7QO8eHswIF88XWsdDte4GY6FaQ=; b=nYkeuuDbNQFydPIU5qMphguMWIDmomOILreixdzx00feSclQDPTdbpQjGfze92WC8C 0TCxUJ3URlBDGYVNoZoAyZC1UMgopxKAYA+7UjqxFT3E87O66D7BaSzviGLcyLEQN8NE PkKnNpafBrF1wDGpfIhB9fN/C7FBubhCPtfJmTVlbtAfqHfVG1T7C6lIKnGjx3rb7tyi bj7S4dNPQJclB8eZFjlW7IXrXXrbCKYD9YoBed4czowUmRtEbz5ZCAsa0osnaZtNWkWS 36t/TuguaQVMnqHPFEHZ4ZNtujI6VzMpvrQic3Jr21ly+NKvxM4m5Dr3etXsrqzMLhdw Wu1Q== X-Gm-Message-State: AOJu0YxsjPSjL0z44Mu/0N1//Kd+77tzqqFV6sI/qOLufhibg4NppMaM Hcro+Hlu7UtUT9vqz7WiWKWuGw82xx4yudDDDePVI7/NA5hj5khol3JxJqxaoSU0jCPuYtHHLRp IdOM= X-Gm-Gg: AZuq6aIfYjvIRS9ThCZLAZHpxa1U0iCEkqP51vUy+TCnuyt5Iul9CLqVJ2sOhERD/fo gJbi6OrJToNegZ11YSeuuzyQzXbhbj6m+7IUzMGOmbo3AmDFkjgBB1P5vttCgknX10S0GxTnjA+ 6k9OfbczL+ln6hO0svgJB23VBJoMk6cnoWkNTxEH4ztmxBBaT9EUEIoPHHprcXG48uYVQ3H6ob7 UnquFllRGx173UEozPkE11N1j1z2LDIid136ISVA/Pv6CPgl7iXXhFWaEpGN1HeIhZEC3EnV/I4 JTEKTSNw8qTeJ5+0O3oa8PdymNbDFerTaVPG6KuDXsnU/RShJXQbbkpZ/IpJ1PPsd4E/OLTqw+M 1h2eRAInBNbbzjZi/eeK0jg1bnAdaicH8YfDxtc0LQNGftgdQlsD6geUcxL1PKkjj5re58+wVCB UpTJpK/d+OryakQ3OU7HqK2+Ce9oTBQPLxo63kFSk70K7b6rluna9hAi/h2UyiKGXR7rjR9bnJX zM= X-Received: by 2002:a05:6000:26c7:b0:432:86dd:ef31 with SMTP id ffacd0b85a97d-43569bd46demr16527522f8f.56.1768834201282; Mon, 19 Jan 2026 06:50:01 -0800 (PST) Message-ID: <0e188989-9190-4f3b-9c45-f4e3d460daca@suse.com> Date: Mon, 19 Jan 2026 15:50:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Ping: [PATCH] flask: fix gcov build with gcc14+ From: Jan Beulich To: Daniel Smith Cc: "xen-devel@lists.xenproject.org" References: <875df90d-1d3a-416b-a958-3d3a31144f85@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: <875df90d-1d3a-416b-a958-3d3a31144f85@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Daniel, On 08.01.2026 10:18, Jan Beulich wrote: > Gcc's "threading" of conditionals can lead to undue warnings, as reported > in e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116519 (no matter > that the overall situation is different there). While my gcc15 complains > ("buf[2] may be used uninitialized in this function") about only two of > the three instances (not about the one in type_read()), adjust all three > to be on the safe side. > > Signed-off-by: Jan Beulich any chance of an ack (or otherwise)? Thanks, Jan > --- > While auditing uses of next_entry(), I noticed POLICYDB_VERSION_ROLETRANS > dependent ones in policydb_read(): How come the 4th slot isn't used at all > there (not even checked for being e.g. zero, i.e. holding no useful data)? > Then again other instances can be found where data is read but outright > ignored. > > --- a/xen/xsm/flask/ss/policydb.c > +++ b/xen/xsm/flask/ss/policydb.c > @@ -1271,7 +1271,10 @@ static int cf_check role_read(struct pol > if ( ver >= POLICYDB_VERSION_BOUNDARY ) > rc = next_entry(buf, fp, sizeof(buf[0]) * 3); > else > + { > rc = next_entry(buf, fp, sizeof(buf[0]) * 2); > + buf[2] = cpu_to_le32(0); /* gcc14 onwards */ > + } > > if ( rc < 0 ) > goto bad; > @@ -1342,7 +1345,10 @@ static int cf_check type_read(struct pol > if ( ver >= POLICYDB_VERSION_BOUNDARY ) > rc = next_entry(buf, fp, sizeof(buf[0]) * 4); > else > + { > rc = next_entry(buf, fp, sizeof(buf[0]) * 3); > + buf[3] = cpu_to_le32(0); /* gcc14 onwards */ > + } > > if ( rc < 0 ) > goto bad; > @@ -1436,7 +1442,10 @@ static int cf_check user_read(struct pol > if ( ver >= POLICYDB_VERSION_BOUNDARY ) > rc = next_entry(buf, fp, sizeof(buf[0]) * 3); > else > + { > rc = next_entry(buf, fp, sizeof(buf[0]) * 2); > + buf[2] = cpu_to_le32(0); /* gcc14 onwards */ > + } > > if ( rc < 0 ) > goto bad; From xen-devel-bounces@lists.xenproject.org Mon Jan 19 14:50:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 14:50:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208178.1520419 (Exim 4.92) (envelope-from ) id 1vhqaF-0003sp-Rg; Mon, 19 Jan 2026 14:50:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208178.1520419; Mon, 19 Jan 2026 14: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 1vhqaF-0003si-Nh; Mon, 19 Jan 2026 14:50:23 +0000 Received: by outflank-mailman (input) for mailman id 1208178; Mon, 19 Jan 2026 14: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 1vhqaE-0002nZ-2B for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 14:50:22 +0000 Received: from SA9PR02CU001.outbound.protection.outlook.com (mail-southcentralusazlp170130001.outbound.protection.outlook.com [2a01:111:f403:c10c::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2d208132-f546-11f0-b15e-2bf370ae4941; Mon, 19 Jan 2026 15:50:21 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by IA1PR03MB8090.namprd03.prod.outlook.com (2603:10b6:208:594::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Mon, 19 Jan 2026 14:50:18 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Mon, 19 Jan 2026 14:50: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: 2d208132-f546-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Iial/55kvX3iqcNy6X2B5haAeG/dSYTVUhO8z3MwXv8/2rxTmjKhV5qIjbyZ0ZGAUqocH4knG3uDgGhKZh5Sb6Hlbjy0xgiq3jKy4Rcsey9xuKRHGzJ0/Njp81zKl5qYUo/1hX7TIXqWVLp35JBddNrvRSPbV7nmY9UISI6x7pRVDhJxCg+J0ZiuQt0E6q5WwzNplTSCx0hEzLgnx969w85rj6meCAJOPOfQKYMAVrO4V8DnOUy5mf86ankbHbu2CS8OfnHeuVdqwRI6+tQphpLo0xaAXvoDPyGd2OXlNkw1AB2QYucLoSMbo8zQpVwYjtETe6iGi/8ogzQCUZzPhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3Fs/v6FMEFoHGhIoGW+MRaIfJSOLH2/2aN0qF1qYgRI=; b=t4Xy4Fz/tZFU/xmS4GMOp+SbJ3PTCbDbduZr4WUFskv935/NQSp8g3oFmULs+rM930PIb7yBdZW+ozVsqkAUuAYmhtdWPNq8tqoWAie1RYUdJaqkiFEyc3S3FYx4JRFWc/b9iYvcHA2nBotSvvVj96ef1soa+iqH3IK4bSdDlijE4UeQM/EP22texJ0ZQFK/2AgmWg2sN2HFd7iGr2LlnmnIN2xeniE3QJeQCo0SAbSsMnVHwlNmaRK5pAs9uQlISXHJFEh8UkPoe6Viro+B5BM4CFk7Dws7/ltB24jTL6b5NlO+Id1TUD1R7pVD7EbCjBENI819BErzZwz1OHWMcQ== 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=3Fs/v6FMEFoHGhIoGW+MRaIfJSOLH2/2aN0qF1qYgRI=; b=VtATmX4Ny9tdxZ0EDkqiwhsrTm8HjuTpc2yrEATZtOnHAETtKmz60BdLBWUWN6QPwXOgXU+C38aUTphQTZ4HADz6qMfVxALo9RRaE/W2xMUcXgwlPZONYX4MNj+RvpZff7EXlvRuMItD0cxUXH/bSVUGoSHvyFiAgIbsz/T1lfg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <791d4bfb-7203-4d7b-ad32-657b70b03150@citrix.com> Date: Mon, 19 Jan 2026 14:50:13 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Luca.Fancellu@arm.com, Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Wei Chen , Hari Limaye Subject: Re: [PATCH] arm/mpu: implement setup_virt_paging for MPU system To: Harry Ramsey , xen-devel@lists.xenproject.org References: <20260119105022.3616126-1-harry.ramsey@arm.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260119105022.3616126-1-harry.ramsey@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0274.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:37a::6) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|IA1PR03MB8090:EE_ X-MS-Office365-Filtering-Correlation-Id: 2f533e66-a603-419b-e93a-08de576a0fcd X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|366016; X-Microsoft-Antispam-Message-Info: =?utf-8?B?NzZpNmx4NXFTbW1EVVc3YjJaM2xTRjZUWXQwd0JCc2VzRDgwMno1aDlzMnVY?= =?utf-8?B?UDRreXRNTitYdHFkVjVQbVNaTjV0YXdKYmx2S0hXaS9lUzJUdzNUcTBvbTcx?= =?utf-8?B?VVFjZmtOYmp3cVlLK1JpVXdMSE00YzhGdDR5RnlBcTJCYm5aMnJMVkJGL0VU?= =?utf-8?B?d2dkNmhzcUV1UGczSXRXV1k0Nk9lZTJSeHBiYW1XR0FwbWNxcHlTeTNEdXRi?= =?utf-8?B?V3lpWGVheC9XQlJCMWZDcjE4ZHQyV250WVljS2RIUVJQOHBVMDEvSllRc3VR?= =?utf-8?B?YmdTUUFXSHMzTnozZ0JzWWhSUjVwa3hPQWk1UWdoaDNTSzJQdDl0ek40RU1E?= =?utf-8?B?bGdLQWxZTnpvSmN5VnBMWmFKcHJ5ZG5ZaFpNaitOZEE3UjhZOGIrd2JKalJt?= =?utf-8?B?ZkYwQmJNMzhSQjR5ZFo0a1dGMnQvY3VhaGR1N3lFbldXS0tTVTE2QW51ZHVs?= =?utf-8?B?Ni93RmwxNXhraFRkMUVNRkZ4QXpSWVNSVVlBdzByS3Z3b2dzTjlSZUJVWE1E?= =?utf-8?B?YUlPQm93UVJKY0Yxa0dFcmJBejZQdEFwRGVSNVMrOFZqeFJhT1JhVGxSc0hU?= =?utf-8?B?dklNazY4enZBQ29mcjlESEhYOC9KcXhCM3ArNTVhVmpnN1dVdGhtQTQwRktI?= =?utf-8?B?OW9XMVNLd3h5MnM3UkNtVmJHN1c0WHpLZ3RFclJZcjExVCt5TGZBQkhwcElL?= =?utf-8?B?a3lrbzQ4SEtHU01iV3BxYWdydlpZZFNvenRIU1RPTHVFZUJ2bzhOZFVOSHVk?= =?utf-8?B?RGY5OGZkTkNaS3JJQkxmVHNIazdxM0lpMDdjb3FzRTJrK0ZxYk44ckpxV25K?= =?utf-8?B?dTduZHF5MjZGYzExYzFPKzdDU0QrVXRzOTd3WWZqRFh6OGhvTms4QVlybG5U?= =?utf-8?B?OUF4RDNXN3REQlZpZG1sSjlJeVd3dGlKUmhyL1hwR1FMTVBtWUZZNFRDdWcy?= =?utf-8?B?OE1rK2huSUdjaGtKcFIxSnlSaFNBVEdTTTd0Qkh5Y21PdWV1ZnNsMWhjWGlp?= =?utf-8?B?QUNWS042d25HU3VxQ2VTYzEvM2RGWjZYQ0d6N3pWRHlmNTNjMFh0eW1YMTY0?= =?utf-8?B?YmZzV2RPcXhhVDUzTlhMR0tlV1l3dFZkVDRLMnpEL0hiT3dpaTcrNjN3ZHAw?= =?utf-8?B?b0F2ZkVJWDB3aTBLRjdXWVFScm9oVTQwQW9BNW9zUlFUQkJ1b1RXL052Tjcz?= =?utf-8?B?SUU5NG1aeFJVaFBFWHkxZXkzRzZlc1ZEdjY3eDRMM0hLcUs0Z3o0a3JXWndw?= =?utf-8?B?b0hCMkkzdDNMengzNkVaa21VaSt6MFJIUUNkdHZ1MGRGb0dEM2ZJb3lyZnd5?= =?utf-8?B?RjlydWxqQytJUksxMnRGTWNlcDBaWTFyYzF0NGhJV2RLYnN6WmFPdmNNRjhu?= =?utf-8?B?MzBlRk84SEZ4UlFrSUNod0pxYWRzb0NRZnQ1TkxOemltOGpMVkpCQmhMWkpx?= =?utf-8?B?L1pTd0hLYlp2aU12cnNqMmJKcEdRY3hMQVZEbi9leFZsREhBMGJPY0huU01j?= =?utf-8?B?bDN1cHgvbmY3cmk4bU1jUzB4Rmd4TkR2L3hGQnB1NFJkaDREMk84NVlMTVRX?= =?utf-8?B?TmE2UTVrWXJLRkFaSVdBZ1A1RFRyMk5VTm1UOUIwZGNmZGhxWDJmRlpTUmI2?= =?utf-8?B?dUwrT1RBQ2FzaVI0c1YxSkNFRVJLWit0Q3h1RFZHd01MYlA5TkwyOWgzNkpa?= =?utf-8?B?Nnkrb1NYWURpUXZrbTBRdkJEYm5JYWVENWNCTVpqa3cxT0JseDRmR3F3Wm9G?= =?utf-8?B?REllWG9IMDgwblR4bnp2aU1UL0hEZVdkdjFDb0UwaWZZMk5oWVd6VzlncXgx?= =?utf-8?B?NkhLSTBlTkU4bVFsSTNaOFFkVmovcktaWXRmOHkyRmJ6SXhqK2ZvNDM1VU9D?= =?utf-8?B?emlrVWlydjEwaHltOVlqUUE0cW9QUmovRnVFbDN1Ukh5dUc4czI2bzJLQ2Zz?= =?utf-8?B?eGJ1cXNiMnBmd0JnZmVUMlg3QWo4Q2g1ZzVDUm1UcVJsNTU4enkyNnA5dTJ6?= =?utf-8?B?VHZlb2U2NGtvLytEcmREU2p4NjUvR1BUbEhzQUp2YWFwS2hKNHhBRjBqZWM2?= =?utf-8?B?SFVTMjRnUWZKeGh6S2dYSzBWaFVBWjU0QXpBRnFYUVo4Zm9VUFlHU0JKTlpC?= =?utf-8?Q?icW8=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZFVWeWQ3djFuSGI3aVplMHZrTnJtb1dhYzZqRVUwZUJleVZ2M0c3ZnhNZkJM?= =?utf-8?B?OTloV1ZndEdoTCtZWll3S2tmeEhzN2VSQmJtVFhMc3pIc1N6R1VibXlyRHRQ?= =?utf-8?B?S2FsRGRnTjg1YlBTMFJLUktDT0wydGtEK09vai90UnhOcnh1K2hBdElZNlg3?= =?utf-8?B?S0l1dm1zQUtPYXhsVzU5Z0lNblZkYnhkK0dLa2hYVlRNdVA4b0hTZURhajZm?= =?utf-8?B?TU1ONGUxZTJOS0hXSG0zQ2NJSjFHaHI4Y3BTeFltZDZUVnBLeUJQbk5aS08w?= =?utf-8?B?b0lXVm5vT3hjZUszdG5lcU54enhONFhpdmZqTTNVeU5FMVZIWWlCSkVGSWRM?= =?utf-8?B?UUM2YVUyV1VaUXNvU0tQZTNNU1Bnc2FQMENOcmZpc1h4emdxbmtwQThHVlZr?= =?utf-8?B?ZDB5TlNxRDhTQXEzZXpsUWp1Q2pXZ1RHZ0pONlMzYlgrcC8vWTZjS2xnRGV2?= =?utf-8?B?NGZySEpVRzJVUndsU3gwRnJwTVBGQTJlcDRpVFlmTmxPREtpQ01YL1NoM05I?= =?utf-8?B?d1JkcllzVXRJK3VTVUhTcHVPeXl0SnVPZ3l3QWVMZElRTndxU3dGS3hiYTg5?= =?utf-8?B?WmRRazc3a3o2OVRqaWh2NU1QS1R0ZlRnSEdsSjI3QXFhMkhpbUVBVW1pRGF1?= =?utf-8?B?cVZvRklnTU04ZElIQTJ3QmpadldrR1NzbnFSS2N3NkhteTFOa2Z2K243dHlY?= =?utf-8?B?MWJwaTJPaUFNNnhTRDVhQ2JiUXJCbU5adHZncE1jSEtTdThKTTVzbWhabEJZ?= =?utf-8?B?SldLN09BNlNmQ3hrZDJrTW85djY4dzF3REthczQyaHFlVjJZRzBOdkR2KzIr?= =?utf-8?B?RWVmMXJIUW1MZWw5YjZNZWZPb25hMCtFNnBidTZxcFlCQU94bXVtSTJBaU01?= =?utf-8?B?L0R4RzRoMjlCdGhLdWdHbzR4bWR0QXJhcGcvaWRCSllhMXRHcUdPNC81ZW0r?= =?utf-8?B?Uk1hcUFuQ09BQkJlN040enE2aTRaNTFDTE84NThTWWpwUkFKRmpramV0U1dB?= =?utf-8?B?UWNNekJJWVl2dWp2Y2toSlh6YXdmaE1TajFhVUN2YXorV0ZiSVZUSmd3cFlB?= =?utf-8?B?MUhERC9KUDJQbElRU2dISjR5K0JVTmcwc2NjVGhJTFFDZzJjazNqeEFtamt0?= =?utf-8?B?U25PK0dBRFBYelRhbmQ4QmZ6VnRLOEZxdVNVcVgwL2ZLODB5eGtXWU8xVzdk?= =?utf-8?B?amNjOGwwL1Rsck5yajViaHVmemQ0VUhhYXliRkpNdUJueHFSV1ZCVzlORkdk?= =?utf-8?B?R20vRXlyWFlyV0hzeFNKZTlnUmt3enJOMCtGeGRoOXRobTNwUCtYS3hzZm5E?= =?utf-8?B?OXRmNE82Y1JmaGVhQklYS29LeWpYV3BJUDM0WGVOTy9leTJMbmNZM3V5YSt0?= =?utf-8?B?L3kzUk96R1ZQYlorZ3kwU09SOFBKWGFXRnRqeENqanFLeHU2NkRmUXVFRUNN?= =?utf-8?B?cWIrcEZJdklqRWl5VmZUY0pEOHpYZjZMaHJUb01qZW8wV0o4cVI0Z1JXdnRS?= =?utf-8?B?b0prbUpKdjNsbnNQVCtFS1dsdEtoVHRReTlvUzBoTmlTbEZDYUhxZnRzanNm?= =?utf-8?B?TWZ6dURuYU5NMm5USHNCV1hyNHNrTVVQdmNNbFE2OFVZWHViYit3VXl2RWZq?= =?utf-8?B?bjVaUXlrWUwzMFpvL2FjdjJjbVdZZDJWc05mcjg5Z2VWR2IzSGFiTXhPS0lE?= =?utf-8?B?NTZKK0p5Z2t5WlJadEQwb2thRjJZem5JWFJYZTVvbDdxNkpoVWVQQ1JLeGtY?= =?utf-8?B?RlF5eDBld2N6b21RUWd2NjJ1R0ZxaTFxYlF6OG1pSnYrbk9vcGNoRERZK0dP?= =?utf-8?B?TVpyNUZaM096RVRZS296UXJwd0FnK0FQNHZ3YWJCaUs2MlVSdjhINHFsZXl0?= =?utf-8?B?aVBPMFoxWFl1eldnWmR5K2NYMlRqRkhLeUFGZk5odjQvR2dzMEh1Tms0eFpE?= =?utf-8?B?VExpcjhsSDhUcGM4VTByWm9uQ2YxL05qY2ptL3EvMW9mN0twcWovL20zTDR3?= =?utf-8?B?L0p1RW5XN1o2S0M5eUtlNzNJU2Y3V2xrWDNjelZVWTYybWJvRFFRV0F3WEt4?= =?utf-8?B?bmJZQTJBMmNBb1p3U3VCd2JITnhybjFLb3FWa21PUHJuNGlFODZHb29td2Vn?= =?utf-8?B?MU5wR1F6Rzd3YXh1VG9KMmJFWFRFSVRaUGVudkxFQ0RtT2wzdUVOQ3FVOUwx?= =?utf-8?B?eDBJUE9ycm93dlpNRGthWFAvdWNLQTZHWWNrVDVIVkdGZmVuQ1RwdUF6YkIy?= =?utf-8?B?eWM4dENpakJxNk1sdTFLMVRWaTdmMWpScXJvS1llczBXLzR0R29SODcrbFo3?= =?utf-8?B?MnhRUzJBY0dpMjNQV0N2SEVlclBrL3dyWXZGRy91Vzk0ZFlFYTVtdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2f533e66-a603-419b-e93a-08de576a0fcd X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jan 2026 14:50:17.8064 (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: cOO5lAA6ldows1cBD0Yb0YNKrgQjx5QsLXqtje/r3zgWcAEFTAAjyxatJuH4GoGT4v6fJmu1Z0q2w3lTNXtN7N+v4a4at1NcQf49Srvtqc0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR03MB8090 On 19/01/2026 10:50 am, Harry Ramsey wrote: > diff --git a/xen/arch/arm/include/asm/mpu.h > b/xen/arch/arm/include/asm/mpu.h > index 72fa5b00b8..55011e3d96 100644 > --- a/xen/arch/arm/include/asm/mpu.h > +++ b/xen/arch/arm/include/asm/mpu.h > @@ -87,7 +87,12 @@ static inline bool region_is_valid(const pr_t *pr) > return pr->prlar.reg.en; > } > > -#endif /* __ASSEMBLER__ */ > +static inline register_t generate_vsctlr(uint16_t vmid) > +{ > + return ((register_t)vmid << VSCTLR_VMID_SHIFT); > +} > + > +#endif /* __ASSEMBLY__ */ > > #endif /* __ARM_MPU_H__ */ > You've got a rebasing error here.  __ASSEMBLY__ doesn't exist any more. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jan 19 15:30:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 15:30:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208210.1520429 (Exim 4.92) (envelope-from ) id 1vhrDH-0001XC-Qm; Mon, 19 Jan 2026 15:30:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208210.1520429; Mon, 19 Jan 2026 15:30:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhrDH-0001X5-NM; Mon, 19 Jan 2026 15:30:43 +0000 Received: by outflank-mailman (input) for mailman id 1208210; Mon, 19 Jan 2026 15:30:42 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhrDG-0001Wz-Ic for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 15:30: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 d023418d-f54b-11f0-b15e-2bf370ae4941; Mon, 19 Jan 2026 16:30:41 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-47ee3da7447so27758325e9.0 for ; Mon, 19 Jan 2026 07:30:41 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4801e8d90b3sm203362415e9.15.2026.01.19.07.30.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jan 2026 07:30:40 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d023418d-f54b-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768836641; x=1769441441; 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=5FG0MWqsc1Mq5LhFOHZaTMZeQ28n5VfcT6LtJkTUwtQ=; b=gitpqHDHjnd4YXwsOeDDEoCZPz3IslmYydQ27sk9JJ+A4iWy8lGAfdL2BYTYVQO1x0 mFU4KGqtHCJ/aVTNEE9msdfsZ1Av0pffn+FCRVwotejCtr+WZQh0dPtudfDueAWDJkNW rBhyaxGsBQCQJbUgGUQeF8fRpN1GBe3bwylfglAAO78peJtNQ94bAfjf/pYtpR6wlt3t puJ4elqNPsqB3J+EI0hhx8c0CpPuVDycckm0WCvIrN7ysspIh+COhi/cPgvs5mV66kVE AX0S6iYRqG3wnrPG7xp2Q2HBXuWtZDd37BFMCId0ZFGUUIqldM07OhftjktZSlIJnHSi Higg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768836641; x=1769441441; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5FG0MWqsc1Mq5LhFOHZaTMZeQ28n5VfcT6LtJkTUwtQ=; b=HyJuu+6FDiZQ0g+RTX5aaitVnYbu0pZ5VOs6jcvlwp1Jrigiqsij4rfbFupHdE8Xxp QUerpr19TtncUZR7N5HJvT69/OLFe0XS9+vwEg0aeoiQvUFkXKD3Es83MhokS7tdBy+w gCAWaLrCKUqS+jXQrNiQevFzi8qAbxRvJ80Xn6LW62yqm6iLeBEHW52D5Gtq5YmGszbV BiWvKHqt8Z1QiSP/yeev2r4fKKB0lG1ZoypEgDlLyKIN9ncIVyQuYi22R+DeOtYymmQ7 R/YeP7dgbHiNqQOjYbYH3I3OCnRbjsT/Y686X4hyxJWj+Q9KMP00WSZEaulcIkZO7nJr YPvg== X-Gm-Message-State: AOJu0YzyuqWTaOMPtPFpPLW50KkcP3v2PbImoFenU+oFDj4IMq4Qnn90 13q7G0HO03fyZSh+6mDHshtRk6fDFDq8Hhp5K2ciTAVIwYbCfsL/zDcxQROpb57JC7fGihETDvv s2x8= X-Gm-Gg: AY/fxX66X9C4fxISyuDygPbJrfy5Lm0mU7+NKj/p21cEUloAlfIjDOxbxzqWg7574RW HOyq0I9JF3+0NBpQuYEhPgVnFL6VtrD+s2/tn/fFnCZiZTTMpu5qaFVZMduJJtvnUeY0J5qgxGc UnuvSsYuNxrVhCj4qJbyXiPHvarQ0Ug3VZ/7Y52fn9AJBUCwXMC9Cz4biYKnwfZ/iFyUfcF+7mW 1H4YF77DcvWLprW83lfgJdJZz7WCuIaKjK7U3OPBUuNfagV+mxHf7++QJLsBQHCGNO0vrLGggE9 MEGttJIYSrDQH9XsedccqG5ECqivbP2VDETR0uWCMDlc5yyZMB8FyITHQ2bPM9wEoZspcoOvaGi /CbHpgr4IGILgtjSGTETT8TIUX0Y8VKL8+zEzyRFp780NZQu4IDH9C8wyZS9j8kY1IuePWm9JMH IM3rx0WHoXsS93AYhEn54+e+1Ku6+jmOzrnVLJBwNpvYdEQEJYh3U7qjgqUBTESjPbWYhB++/L4 qQ= X-Received: by 2002:a05:600c:35c6:b0:477:93f7:bbc5 with SMTP id 5b1f17b1804b1-4801e2fdf57mr160486475e9.10.1768836640616; Mon, 19 Jan 2026 07:30:40 -0800 (PST) Message-ID: <70fe3986-ad89-4b42-b158-7e7b2b24ec1e@suse.com> Date: Mon, 19 Jan 2026 16:30:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH] x86: calculate number of synthetic feature and bug enumerators Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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 Rather than spelling out their amounts (requiring updates when multiples of 32 are crossed), introduce a sentinel each and calculate the two numbers from those. No difference in generated code, albeit debug info size grows quite a bit. Signed-off-by: Jan Beulich --- This is an alternative to "x86: guard synthetic feature and bug enumerators", bulding upon the expectation that when adding to the end of either list people will notice the sentinel and not forget to update it. --- a/xen/arch/x86/include/asm/cpufeatures.h +++ b/xen/arch/x86/include/asm/cpufeatures.h @@ -7,7 +7,6 @@ #define FSCAPINTS FEATURESET_NR_ENTRIES /* Synthetic words follow the featureset words. */ -#define X86_NR_SYNTH 2 #define X86_SYNTH(x) (FSCAPINTS * 32 + (x)) /* Synthetic features */ @@ -44,9 +43,11 @@ XEN_CPUFEATURE(IBPB_ENTRY_HVM, X86_SY 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() */ +XEN_CPUFEATURE(nr, X86_SYNTH(33)) /* Number of synthetic features */ + +#define X86_NR_SYNTH DIV_ROUND_UP(X86_FEATURE_nr - FSCAPINTS * 32, 32) /* Bug words follow the synthetic words. */ -#define X86_NR_BUG 1 #define X86_BUG(x) ((FSCAPINTS + X86_NR_SYNTH) * 32 + (x)) #define X86_BUG_FPU_PTRS X86_BUG( 0) /* (F)X{SAVE,RSTOR} doesn't save/restore FOP/FIP/FDP. */ @@ -64,5 +65,10 @@ XEN_CPUFEATURE(XEN_REP_MOVSB, X86_SY #define X86_SPEC_BHB_LOOPS X86_BUG(20) /* Use clear_bhb_loops for BHI mitigation.*/ #define X86_SPEC_BHB_LOOPS_LONG X86_BUG(21) /* Upgrade clear_bhb_loops to the "long" sequence. */ +#define X86_BUG_nr X86_BUG(22) /* Number of bug identifiers */ + +#define X86_NR_BUG DIV_ROUND_UP(X86_BUG_nr - (FSCAPINTS + X86_NR_SYNTH) * 32, \ + 32) + /* Total number of capability words, inc synth and bug words. */ #define NCAPINTS (FSCAPINTS + X86_NR_SYNTH + X86_NR_BUG) /* N 32-bit words worth of info */ From xen-devel-bounces@lists.xenproject.org Mon Jan 19 16:13:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 16:13:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208222.1520439 (Exim 4.92) (envelope-from ) id 1vhrsh-0007B6-RF; Mon, 19 Jan 2026 16:13:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208222.1520439; Mon, 19 Jan 2026 16:13:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhrsh-0007Ay-NK; Mon, 19 Jan 2026 16:13:31 +0000 Received: by outflank-mailman (input) for mailman id 1208222; Mon, 19 Jan 2026 16:13:30 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhrsg-0007As-E8 for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 16:13:30 +0000 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [2a00:1450:4864:20::329]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c83ff6a7-f551-11f0-9ccf-f158ae23cfc8; Mon, 19 Jan 2026 17:13:25 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-4801ea9bafdso10396775e9.3 for ; Mon, 19 Jan 2026 08:13:25 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47f428bb0b5sm255812685e9.8.2026.01.19.08.13.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jan 2026 08:13:24 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c83ff6a7-f551-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768839204; x=1769444004; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=l+vUXsm6d9ywAGLhahwKO78cqkqQuhm3E6TBu40z0KA=; b=dhHXq9Ty4wsFgsxbwZZSXBhBGnPVRMKzp6Knsw+E7s/nQk2830ZqWe+qIGHVRcRI3d IjGfDkM7EGyWSPbu8Pm4tz0GjEpA4P8FCgZ0kcdDSbFg4z5BLdoNKybx3hIolScYzisN J0Fpnrkzp1aaL73sZPm7JGomXoua0vPIk1hl79VTjAXb0s3LTKkjHGekGyP7gb1Iymsb Wi56e0LKSFP57oc7/d9MW3e6d7UjLfHbEvmg3rqQ0XjEl+U+hEqJGJUdiWJMTiVRp3Ll EHjoxWxk1g9E0KW9fMq5fiTvYCqPRpX8/zLUuZzMB/wa77akAu2rXR96doJvXBVy+T2j SzSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768839204; x=1769444004; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=l+vUXsm6d9ywAGLhahwKO78cqkqQuhm3E6TBu40z0KA=; b=SNSdRDUYeqFuNcyonBsyA0oL0Cyz2LB8pLT3noBUVA0k319EXCeHZyZjplCJQ2qHzu H3t9r8lVtn20QQ1l+PTxSQLMNmtoY9ryMwb95BoEJMnBfE5/503WVNOnzGhYV37+fM6e Td8rlfvw/hiPJNQsDfIDKCTHa4iYC8dhIp6Vx3GK66aBX/tfhMgXKQg/ku30uIavF+3y g5fZGahK3IXHMX9aA7E1RocLsGK/6EKeM4bqSSCGc6xPWqn3yLYhkWFam6daDrC5fr2H 50nfTHrecAMA3Rn/1pxggyKLUCiwNZ3eULnKLNiIJy0oRkVFIsQICH1BkvpedyZbnx7e LQKg== X-Forwarded-Encrypted: i=1; AJvYcCV6JBJk7VqlLCttUTlIlugUgaGr1oYnLmUxsEa1kStndqW+7i1YkjCRMBvgKE3cwAhVqI303AijfMQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YxgPJbUtg4rQzzQgRxxLclhJ4SMfyNOzSMNpsiKwFT+bCa1Ggsj MxfIQH6po0FZI1zprv7tXlup4jFWEUoxmF717Hzto6Ux5fAOLdGGjGYOyivqbX20Uw== X-Gm-Gg: AY/fxX7z9K/+bnTaxM/tjRpKSRA0P2FKXiS+gSOYVuqjIBvZrwv4xu9E9cPvjXgg79F CqoeolKDai9esfzbb90F4IiNJcEl9RCtjzCQYnNlzC/uQ5bVdESGM1+rMzNMqwvFQ/jOywsG2On 3zQaNrxNLe64NNwI1ZE2g/r/A4Xf9QnElmSAtRsPBo2w0I4VEWA500ddTf6vN+xSI0HURvPaYyA FjmKyxVTZgIx87TOahh3lj3e7qFGRSAExgr1LXxm+oxCywQACq8jNa0kC/gn7gBTlIoVPF9kKUu fJ5gkdOK0xGNugLJnbNcp/MlxS5oQ+a1bb/G+gYg/1TOkP/Y9fe9Z9HxCbCh8K7vSjwFTLt3G4I B7c6Fg7SkYsbcByNT/BNT9scLV1e3FVBMuRipHwoJkchJPOdbiiV2e45gE6XPXMuBE8hXZEgeni V+FGbsCdo0rW0iNpogRXigx42aASH5OTWqhMZCByjQMbkiNjLUxOiwJNCjnYqCJKWKd7aa9iglZ Ss= X-Received: by 2002:a05:600d:6413:10b0:480:1e40:3d2 with SMTP id 5b1f17b1804b1-4801e400518mr116115895e9.29.1768839204388; Mon, 19 Jan 2026 08:13:24 -0800 (PST) Message-ID: <858d73b3-2feb-419f-bf3b-9a264e9f9af8@suse.com> Date: Mon, 19 Jan 2026 17:13:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/3] xen/mm: limit non-scrubbed allocations to a specific order To: Roger Pau Monne Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260115111804.40199-1-roger.pau@citrix.com> <20260115111804.40199-4-roger.pau@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260115111804.40199-4-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 15.01.2026 12:18, Roger Pau Monne wrote: > The current logic allows for up to 1G pages to be scrubbed in place, which > can cause the watchdog to trigger in practice. Reduce the limit for > in-place scrubbed allocations to a newly introduced define: > CONFIG_DIRTY_MAX_ORDER. This currently defaults to CONFIG_DOMU_MAX_ORDER > on all architectures. Also introduce a command line option to set the > value. > > Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed") > Signed-off-by: Roger Pau Monné > --- > Changes since v1: > - Split from previous patch. > - Introduce a command line option to set the limit. > --- > docs/misc/xen-command-line.pandoc | 9 +++++++++ > xen/common/page_alloc.c | 23 ++++++++++++++++++++++- > 2 files changed, 31 insertions(+), 1 deletion(-) If you confine the change to page_alloc.c, won't this mean that patch 2's passing of MEMF_no_scrub will then also be bounded (in which case the need for patch 2 would largely disappear)? > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -1822,6 +1822,15 @@ Specify the deepest C-state CPUs are permitted to be placed in, and > optionally the maximum sub C-state to be used used. The latter only applies > to the highest permitted C-state. > > +### max-order-dirty > +> `= ` > + > +Specify the maximum allocation order allowed when scrubbing allocated pages > +in-place. The allocation is non-preemptive, and hence the value must be keep > +low enough to avoid hogging the CPU for too long. > + > +Defaults to `CONFIG_DIRTY_MAX_ORDER` or if unset to `CONFIG_DOMU_MAX_ORDER`. This may end up misleading, as - despite their names - these aren't really Kconfig settings that people could easily control in their builds. > ### max_gsi_irqs (x86) > > `= ` I also wonder whether your addition wouldn't more naturally go a litter further down, by assuming / implying that the sorting used largely ignores separator characters (underscore vs dash here). Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 19 16:33:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 16:33:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208233.1520448 (Exim 4.92) (envelope-from ) id 1vhsBZ-0001a0-74; Mon, 19 Jan 2026 16:33:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208233.1520448; Mon, 19 Jan 2026 16:33:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhsBZ-0001Zt-4Y; Mon, 19 Jan 2026 16:33:01 +0000 Received: by outflank-mailman (input) for mailman id 1208233; Mon, 19 Jan 2026 16:33:00 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhsBY-0001Zn-7q for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 16:33:00 +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 7e4bf7e2-f554-11f0-9ccf-f158ae23cfc8; Mon, 19 Jan 2026 17:32:49 +0100 (CET) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-430f3ef2d37so3516526f8f.3 for ; Mon, 19 Jan 2026 08:32:49 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4356996cf33sm24840625f8f.25.2026.01.19.08.32.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jan 2026 08:32:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7e4bf7e2-f554-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768840369; x=1769445169; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=PWZtUaHgj9FkKrdCwqyUaCh/zsx6Y8epxrk+KkO6QAA=; b=OP3MeLkqhaYPaI6Zu/afY4oipm6RUn0wvItEUsFDkHynikdIIPGyOwd89V/Bn8jTdB lAh9B91XIyBPEsrT+ykBNd5y8cakLTHHOzSadKeLNx6HBp5Zbp9rpq3TUeOiuocoIuEf jUxkVDaS6VLfplOkLGrlPJ7uVSDzr64gJ7QLvtTgnvIn4etF32CW1LMFajAftR6JXrb7 ertgm9bvZ6XBoIJ+C8Sp96RdsDT+KlVqeXFR/jUtONqMuaEp1P9wzvFirUseNA0EiO2g ZXJsndyB2Df5dA3kklfHca0H9yUFlSug7i2fWo4k3G6SpG8Eyc+EsXHShXwJtZjWSoyT zm/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768840369; x=1769445169; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=PWZtUaHgj9FkKrdCwqyUaCh/zsx6Y8epxrk+KkO6QAA=; b=iroYZCMBuugoXXAFEUY80bFAbcOWZNNTaC44+GeGLFBeuphOLhpvDgDaoYcJ1mxcNG xG6QHbwkhpQWqy/q6pB1OAggR5eaHl2BOkpmla2duNxhxISG+ssOpO8RHpvWyP8e++v9 BMfFL2G231gliU0LnASYtSVvBGazhRsQWfmCRe2nXWFcJhbuTmA809aykFz0sIuwmzZK JOM4JhVtwQlwuFUhmYj5P1mpUaF9gjC1AaxHDVlUQ0Rw2+ZLme5lrswXf0+lLe4obvEW stY1+ExPL4JSrlvI3r8/ZI3w8+646wkOrhsJfvnI5KYeW/OyQfqJ6VzwfDB6mGL/Eo9W Zj+Q== X-Forwarded-Encrypted: i=1; AJvYcCXKsyc0lmWgtIsUw64lkwae+a7KdpTRZLFZx/h9/+6X13+OJNVXUamArKQ64mzXcsjL3ccLg8C1juk=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzn2PrmSXtJCjKyLIkJu/UsZ9QWxNizGlkgEzOqNfwmgcWmbI/F +UuTxl0Gn5tc6Pi9I+DXoDIguxaJMTmE2+rU1ik6llu4D9Ep2Pxd8uaJCDWTHO7FRQ== X-Gm-Gg: AZuq6aKYMM68IHZ4GW95D+tgxCcQ5c7cAqZOJ2N9x7FqqV9GIk0EQOzNGFqknFt5h8t 7WIgPhHy3uDG28JhrFZ2j1t23gASPhASWEh8lOW7JaXsaAu6/ZVQNK0ZKomiyZG+RpGoiAAOnPm RfWaDEc7L9iItrqSzOeqd18ZPwayKuXqUOKTjanNZQTITYlXqn1BsgvAoAadITriOwCb5ak83U/ NTwIxfv41dz7tJxs0QBV2g6klRcyPlavg08fRct12serkGxmMpMkOEDFpDTk7/G35sHhJ0kOK31 NYIJj4wCNLG69yGbibUC7Z3A9PdY7rR9cyMcpNFUoBzV4JMJAqkBQ1D14XnjfhxgvFShMIfvM/Q W8mx6SPasYrnphmanqvjw6cxt0hrBXFhXd/nAPYsmgeFOsIOYWg5JPIpqz2g70pabfbX3w0e3G4 FVblTWeC9hJFCX4qsHs9Uo1KNURK+0HclnKMNAubLnvIwMx5RJRMwMdYan+H0Y4xws2d6/N0eTb AY= X-Received: by 2002:a05:6000:144b:b0:430:f5dc:d34a with SMTP id ffacd0b85a97d-43569bbb0acmr17227187f8f.29.1768840368754; Mon, 19 Jan 2026 08:32:48 -0800 (PST) Message-ID: <63c35c5e-577b-4346-b600-03808306177f@suse.com> Date: Mon, 19 Jan 2026 17:32:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] xen/console: handle multiple domains using console_io hypercalls To: Stefano Stabellini Cc: grygorii_strashko@epam.com, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Victor Lira , andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 14.01.2026 01:39, Stefano Stabellini wrote: > @@ -815,6 +831,11 @@ long do_console_io( > if ( count > INT_MAX ) > break; > > + d = console_get_domain(); > + console_put_domain(d); > + if ( d != current->domain ) > + return 0; This isn't atomic (as in: in a suitably locked region) with ... > @@ -830,7 +851,10 @@ long do_console_io( > break; > } > rc += len; > - serial_rx_cons += len; > + nrspin_lock_irq(&console_lock); > + if ( serial_rx_cons != serial_rx_prod ) > + serial_rx_cons += len; > + nrspin_unlock_irq(&console_lock); > } > break; ... this. If the focus domain changes after the check in the earlier hunk, I think you need to also return with no input here. Or you need to acquire the lock earlier (and then similarly in console_switch_input()), albeit that would then mean holding it across a copy-to-guest. Which technically is perhaps not a problem, but it leaves an uneasy feeling. In no case may you continue the loop if the focus domain changed, or else you potentially hand the old one input targeted at the new one. For context: What caught my attention is the conditional inside the locked region. This, imo, shouldn't be necessary when everything else is properly structured. Actually, the lock strictly needs holding now across all accesses to serial_rx_{cons,prod}. That'll then naturally make the conditional unnecessary. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 19 18:26:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 18:26:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208250.1520458 (Exim 4.92) (envelope-from ) id 1vhtxZ-00069V-GJ; Mon, 19 Jan 2026 18:26:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208250.1520458; Mon, 19 Jan 2026 18:26:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhtxZ-00069O-DX; Mon, 19 Jan 2026 18:26:41 +0000 Received: by outflank-mailman (input) for mailman id 1208250; Mon, 19 Jan 2026 18:26: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 1vhtxX-00069I-EK for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 18:26:39 +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 6376c756-f564-11f0-b15e-2bf370ae4941; Mon, 19 Jan 2026 19:26:36 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id CDD235BCCE; Mon, 19 Jan 2026 18:26:35 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 266903EA63; Mon, 19 Jan 2026 18:26: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 1xrIB1t3bmmpaAAAD6G6ig (envelope-from ); Mon, 19 Jan 2026 18:26: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: 6376c756-f564-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1768847195; 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=es6/9iazupCDI6/7lXEp32/GJOPok2cUpRLmpWvKLkM=; b=adGq2lDw/ziTP/sy6wRsMUsI9ByF14hQ6d0dKFUjC3IKDHScmmeOQqchV3ghgQzs6QqArp 7Rq6Rh1gvW5LvZjxrzfFc2chPq5Ak1+BhW51vLfvoPWnTdC1j+0l05Ln6G2pjOcrIqPmr7 oNCARBaKZXFCT2zf+k1qE+41DTi8lMs= Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=adGq2lDw DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1768847195; 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=es6/9iazupCDI6/7lXEp32/GJOPok2cUpRLmpWvKLkM=; b=adGq2lDw/ziTP/sy6wRsMUsI9ByF14hQ6d0dKFUjC3IKDHScmmeOQqchV3ghgQzs6QqArp 7Rq6Rh1gvW5LvZjxrzfFc2chPq5Ak1+BhW51vLfvoPWnTdC1j+0l05Ln6G2pjOcrIqPmr7 oNCARBaKZXFCT2zf+k1qE+41DTi8lMs= From: Juergen Gross To: linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux.dev, kvm@vger.kernel.org, linux-block@vger.kernel.org Cc: Juergen Gross , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Paolo Bonzini , Vitaly Kuznetsov , Boris Ostrovsky , xen-devel@lists.xenproject.org, Denis Efremov , Jens Axboe Subject: [PATCH v4 0/6] x86: Cleanups around slow_down_io() Date: Mon, 19 Jan 2026 19:26:26 +0100 Message-ID: <20260119182632.596369-1-jgross@suse.com> X-Mailer: git-send-email 2.52.0 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)[]; URIBL_BLOCKED(0.00)[suse.com:dkim,suse.com:mid,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns]; FROM_HAS_DN(0.00)[]; FUZZY_RATELIMITED(0.00)[rspamd.com]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_TWELVE(0.00)[20]; MIME_TRACE(0.00)[0:+]; 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]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:dkim,suse.com:mid]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; DKIM_TRACE(0.00)[suse.com:+] X-Spam-Flag: NO X-Spam-Score: -3.01 X-Rspamd-Queue-Id: CDD235BCCE X-Rspamd-Action: no action X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Spam-Level: While looking at paravirt cleanups I stumbled over slow_down_io() and the related REALLY_SLOW_IO define. Do several cleanups, resulting in a deletion of REALLY_SLOW_IO and the io_delay() paravirt function hook. Patch 4 is removing the config options for selecting the default delay mechanism and sets the default to "no delay". This is in preparation of removing the io_delay() functionality completely, as suggested by Ingo Molnar. Patch 5 is adding an additional config option allowing to avoid building io_delay.c (default is still to build it). Changes in V2: - patches 2 and 3 of V1 have been applied - new patches 4 and 5 Changes in V3: - rebase to tip/master kernel branch Changes in V4: - add patch 1 as prereq patch to the series Juergen Gross (6): x86/irqflags: Fix build failure x86/paravirt: Replace io_delay() hook with a bool block/floppy: Don't use REALLY_SLOW_IO for delays x86/io: Remove REALLY_SLOW_IO handling x86/io_delay: Switch io_delay() default mechanism to "none" x86/io_delay: Add config option for controlling build of io_delay. arch/x86/Kconfig | 8 +++ arch/x86/Kconfig.debug | 30 ---------- arch/x86/include/asm/floppy.h | 31 ++++++++-- arch/x86/include/asm/io.h | 19 ++++--- arch/x86/include/asm/irqflags.h | 6 +- arch/x86/include/asm/paravirt-base.h | 6 ++ arch/x86/include/asm/paravirt.h | 11 ---- arch/x86/include/asm/paravirt_types.h | 2 - arch/x86/kernel/Makefile | 3 +- arch/x86/kernel/cpu/vmware.c | 2 +- arch/x86/kernel/io_delay.c | 81 +-------------------------- arch/x86/kernel/kvm.c | 8 +-- arch/x86/kernel/paravirt.c | 3 +- arch/x86/kernel/setup.c | 4 +- arch/x86/xen/enlighten_pv.c | 6 +- drivers/block/floppy.c | 2 - 16 files changed, 63 insertions(+), 159 deletions(-) -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Mon Jan 19 18:26:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 18:26:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208251.1520468 (Exim 4.92) (envelope-from ) id 1vhtxi-0006Os-Qm; Mon, 19 Jan 2026 18:26:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208251.1520468; Mon, 19 Jan 2026 18:26:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhtxi-0006Ol-OB; Mon, 19 Jan 2026 18:26:50 +0000 Received: by outflank-mailman (input) for mailman id 1208251; Mon, 19 Jan 2026 18:26: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 1vhtxh-00069I-44 for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 18:26:49 +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 6a4b5054-f564-11f0-b15e-2bf370ae4941; Mon, 19 Jan 2026 19:26:47 +0100 (CET) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 7F8025BCCF; Mon, 19 Jan 2026 18:26:47 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id F0E353EA63; Mon, 19 Jan 2026 18:26:46 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id bQUXOWZ3bmlDaQAAD6G6ig (envelope-from ); Mon, 19 Jan 2026 18: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: 6a4b5054-f564-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1768847207; 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=AptIhJVLc4BAPjc93uyYDO0mqV71EtV4n2ofFaZETBA=; b=MHdJ4bZvPaLDXUUOQ3i7gfZ7SaV5KwjmoaFwAn84TqAqysh6unnWea6ggMSDJ/PpHkvkjo I0bcsilVrid3zIhgY/mNdw68yalgrA6NjTLwct4FKvMxS8yXswniUi2Aw805dPA794XFJp PwpYIqSNVMu84lONkQNyMxjfHxIq6NE= Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.com header.s=susede1 header.b=MHdJ4bZv DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1768847207; 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=AptIhJVLc4BAPjc93uyYDO0mqV71EtV4n2ofFaZETBA=; b=MHdJ4bZvPaLDXUUOQ3i7gfZ7SaV5KwjmoaFwAn84TqAqysh6unnWea6ggMSDJ/PpHkvkjo I0bcsilVrid3zIhgY/mNdw68yalgrA6NjTLwct4FKvMxS8yXswniUi2Aw805dPA794XFJp PwpYIqSNVMu84lONkQNyMxjfHxIq6NE= From: Juergen Gross To: linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux.dev, kvm@vger.kernel.org Cc: Juergen Gross , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Paolo Bonzini , Vitaly Kuznetsov , Boris Ostrovsky , xen-devel@lists.xenproject.org Subject: [PATCH v4 2/6] x86/paravirt: Replace io_delay() hook with a bool Date: Mon, 19 Jan 2026 19:26:28 +0100 Message-ID: <20260119182632.596369-3-jgross@suse.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260119182632.596369-1-jgross@suse.com> References: <20260119182632.596369-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)[]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; FUZZY_RATELIMITED(0.00)[rspamd.com]; ARC_NA(0.00)[]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; MIME_TRACE(0.00)[0:+]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RCPT_COUNT_TWELVE(0.00)[17]; RCVD_COUNT_TWO(0.00)[2]; URIBL_BLOCKED(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.com:mid,suse.com:dkim,suse.com:email]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_RATELIMIT(0.00)[to_ip_from(RLkdkdrsxe9hqhhs5ask8616i6)]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[suse.com:+]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[]; TO_DN_SOME(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:dkim,suse.com:email] X-Spam-Flag: NO X-Spam-Score: -3.01 X-Rspamd-Queue-Id: 7F8025BCCF X-Rspamd-Action: no action X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Spam-Level: The io_delay() paravirt hook is in no way performance critical and all users setting it to a different function than native_io_delay() are using an empty function as replacement. This enables to replace the hook with a bool indicating whether native_io_delay() should be called. Signed-off-by: Juergen Gross --- V3: - rebase to tip/master kernel branch --- arch/x86/include/asm/io.h | 9 ++++++--- arch/x86/include/asm/paravirt-base.h | 6 ++++++ arch/x86/include/asm/paravirt.h | 11 ----------- arch/x86/include/asm/paravirt_types.h | 2 -- arch/x86/kernel/cpu/vmware.c | 2 +- arch/x86/kernel/kvm.c | 8 +------- arch/x86/kernel/paravirt.c | 3 +-- arch/x86/xen/enlighten_pv.c | 6 +----- 8 files changed, 16 insertions(+), 31 deletions(-) diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index ca309a3227c7..8a9292ce7d2d 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -243,11 +243,16 @@ extern int io_delay_type; extern void io_delay_init(void); #if defined(CONFIG_PARAVIRT) -#include +#include #else +#define call_io_delay() true +#endif static inline void slow_down_io(void) { + if (!call_io_delay()) + return; + native_io_delay(); #ifdef REALLY_SLOW_IO native_io_delay(); @@ -256,8 +261,6 @@ static inline void slow_down_io(void) #endif } -#endif - #define BUILDIO(bwl, type) \ static inline void out##bwl##_p(type value, u16 port) \ { \ diff --git a/arch/x86/include/asm/paravirt-base.h b/arch/x86/include/asm/paravirt-base.h index 982a0b93bc76..3b9e7772d196 100644 --- a/arch/x86/include/asm/paravirt-base.h +++ b/arch/x86/include/asm/paravirt-base.h @@ -15,6 +15,8 @@ struct pv_info { #ifdef CONFIG_PARAVIRT_XXL u16 extra_user_64bit_cs; /* __USER_CS if none */ #endif + bool io_delay; + const char *name; }; @@ -26,6 +28,10 @@ u64 _paravirt_ident_64(u64); #endif #define paravirt_nop ((void *)nop_func) +#ifdef CONFIG_PARAVIRT +#define call_io_delay() pv_info.io_delay +#endif + #ifdef CONFIG_PARAVIRT_SPINLOCKS void paravirt_set_cap(void); #else diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index b21072af731d..f4885bd98a18 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -19,17 +19,6 @@ #include #include -/* The paravirtualized I/O functions */ -static inline void slow_down_io(void) -{ - PVOP_VCALL0(pv_ops, cpu.io_delay); -#ifdef REALLY_SLOW_IO - PVOP_VCALL0(pv_ops, cpu.io_delay); - PVOP_VCALL0(pv_ops, cpu.io_delay); - PVOP_VCALL0(pv_ops, cpu.io_delay); -#endif -} - void native_flush_tlb_local(void); void native_flush_tlb_global(void); void native_flush_tlb_one_user(unsigned long addr); diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 7ccd41628d36..3946d0f69921 100644 --- a/arch/x86/include/asm/paravirt_types.h +++ b/arch/x86/include/asm/paravirt_types.h @@ -30,8 +30,6 @@ struct pv_lazy_ops { struct pv_cpu_ops { /* hooks for various privileged instructions */ - void (*io_delay)(void); - #ifdef CONFIG_PARAVIRT_XXL unsigned long (*get_debugreg)(int regno); void (*set_debugreg)(int regno, unsigned long value); diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c index a3e6936839b1..eee0d1a48802 100644 --- a/arch/x86/kernel/cpu/vmware.c +++ b/arch/x86/kernel/cpu/vmware.c @@ -339,7 +339,7 @@ arch_initcall(activate_jump_labels); static void __init vmware_paravirt_ops_setup(void) { pv_info.name = "VMware hypervisor"; - pv_ops.cpu.io_delay = paravirt_nop; + pv_info.io_delay = false; if (vmware_tsc_khz == 0) return; diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c index 26ab6f8e36df..911950c9110c 100644 --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -75,12 +75,6 @@ DEFINE_PER_CPU_DECRYPTED(struct kvm_steal_time, steal_time) __aligned(64) __visi static int has_steal_clock = 0; static int has_guest_poll = 0; -/* - * No need for any "IO delay" on KVM - */ -static void kvm_io_delay(void) -{ -} #define KVM_TASK_SLEEP_HASHBITS 8 #define KVM_TASK_SLEEP_HASHSIZE (1< Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 19:01:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208279.1520479 (Exim 4.92) (envelope-from ) id 1vhuVM-0003Q5-DT; Mon, 19 Jan 2026 19:01:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208279.1520479; Mon, 19 Jan 2026 19: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 1vhuVM-0003Py-9s; Mon, 19 Jan 2026 19:01:36 +0000 Received: by outflank-mailman (input) for mailman id 1208279; Mon, 19 Jan 2026 19:01:35 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhuVK-0003Ps-UV for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 19:01:35 +0000 Received: from SA9PR02CU001.outbound.protection.outlook.com (mail-southcentralusazlp170130001.outbound.protection.outlook.com [2a01:111:f403:c10c::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 447dfa29-f569-11f0-b15e-2bf370ae4941; Mon, 19 Jan 2026 20:01:33 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CO1PR03MB7913.namprd03.prod.outlook.com (2603:10b6:303:274::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.11; Mon, 19 Jan 2026 19:01:29 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Mon, 19 Jan 2026 19: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: 447dfa29-f569-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=wjvNUzh63bPr6qKCa1Zh2IEACo2095t0wxE7iiWRTJFTGez+kYaYyNjaY8Q9mKRgweTpuYkWZe0mDvKC8GvmZe6PEhhygBIC7MnWrzcn75nwfsP5abLaKjkgdxUrDcPTZH4tUXxdA0yk7f0S0y4TkqlNs3WiWU4zER9WutHNksJt7Hd71EIamL1ZpOvv5aLSncDBgyMjZdH4VWV2kpk0snWyUYWjAoOzYnAYyv7855D/8cezqSlRHtZenfdD47fcvzZ34sbICAUY6q/7gYq+zABhVkLUTBM5ZN8ZP0gsRWXnbvJeUiUF+hGt08WjA0U0IpXw+2TvtK5hOwn1hqLY4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=p6NSuYkMmYDfkae9kO2qKhlwOe6zic4bnQPFknOnPpg=; b=qng1AIywYYTRbViS+Vz0sZRqFZs+b/tlztvinTIPt6LlobSWkgNDYMrOJOd5EZIR93/GG9VpZ4VvspH+uQ7Bdd99pu0X3dZ7Vn1glZ1VLD6nGrwo/KfiXj5dV6Wafa3bZsTnSZwX/XT3+NUZMhPtrwUzuF1x8zbEAyY9frKxK4PHhQAud4TvDO4SIykcAToMyV83nI1SXmPgOlnboAT0uvQZjfahIKELXedLtil/zxl5XWeWQf/a5AUJt1cLTcKdJHQ1WpfZlsu+1nUK4Mdo2blEBtHNtGUSHD/0gJwMaDtGsCVm+pqfjHMB9eK/f2ZUrf1qIbQk/dnvRaTAynlVwQ== 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=p6NSuYkMmYDfkae9kO2qKhlwOe6zic4bnQPFknOnPpg=; b=GhqNlV0EFA+d2MQ2dm11OSiy1HxzBMWsBCxWDg9zJ2/O9m3EtfYc20gDwznxBZ/oHCwXJBdOaIcWYR7nfNvDPGKUbxQJG/OGH8PD78c1Rbg/S4kGeNsUMg/qzpZGL67PBKpOSK4CUbbKHAAVMxoH1p8JTGHStiSsuCP88pPOvXo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <335949fc-059e-477c-9b2b-ddcd2f144300@citrix.com> Date: Mon, 19 Jan 2026 19:01:25 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P . Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Jan Beulich Subject: Re: [PATCH] xen: Move NX handling to a dedicated place To: Julian Vetter , xen-devel@lists.xenproject.org References: <20260115151658.3725784-1-julian.vetter@vates.tech> <69b511db-654d-46b3-aca3-3f37f30d3473@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0679.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:351::12) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CO1PR03MB7913:EE_ X-MS-Office365-Filtering-Correlation-Id: fac5c2bd-a62b-4b88-5376-08de578d26bf 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?aUN3UFIyampHTzg0S0lYMGZ1Z2N3M3YzSDViK0hiZFVQMFVhRWNyZUthUzRS?= =?utf-8?B?enBMZlpDL2w3eWtsRlFQMUw4Mm91ZFl5QUdCMThZTVJ1SzhFeDBQWnFTTk1Z?= =?utf-8?B?RDJuWnVDRVJzeTloK0FVN2pYalY2OVJYZzVNSHlpZDhFbGV1ZjU5UXlYbkxk?= =?utf-8?B?K2xHSWluSGoyUlMzcEU5SGtPdlJoczR5ZEZGVEtMTVpsQTV0MTZFc0lCa3Vq?= =?utf-8?B?QW1MK1A4L2o2bHc5d0F1ODBDT0VERGJ1dTFCbDFNRHgxYWRmWSs2Z2xOU2RU?= =?utf-8?B?cjdyY0pUdXBxWXRFczZkQ3B1elMrQVpKczQ5MEkxRWNsRm5PbHdjcnBxU2N2?= =?utf-8?B?SVVXMnV1ZzBleDVKQTVqNjZWRkM2VEhoN1pPN1NHMmhXVTVCYXNib0haSXpy?= =?utf-8?B?MjFmOGFtREs1dFdvcy9kRlRQQlpGSE1CL2ZqTmgybkFiNE1vajJCRlc2d2xU?= =?utf-8?B?bEhMeFIzTUZ0aTBhc1dkS3pKbEpCcmFFSHVxT014S3I1aVFNVlZ3R002dnBm?= =?utf-8?B?OVREY0ZPRFlOQmdjSi9Pd255SGVJR0NWeDNIZDZFbklLcmM2Z21PN1BCeGlC?= =?utf-8?B?S1BIWE10WmlyWUtNbDF1bXZnVnNiZWtKakdXbVF6empHaE01UWJGcEVFM3Q1?= =?utf-8?B?TTJJeGIrRk9mSzl6RERPeW9JWVdIb1RuR3Z5blRGb0RxV1RPNGNQdGF4M09l?= =?utf-8?B?dkJjODN0bE43OCtXeDQydG1LMG5jak1zUWxQcDRvVk5ydC8xV0hmTFp3aVRO?= =?utf-8?B?MG1nMVV0RmhzNlMxMlNWeEh3Kzl1VFo0dkVTZzlzTkFLRG5hTURTV3FOd0c1?= =?utf-8?B?K1pybzhJVWc0WnQ1MEdUdWdHZEJaaFFUbXhEQ2VkU0F0UjJyZUd4VzZQZXU1?= =?utf-8?B?WjB4WVZYUjZzeUhjYjNscWtDRG1Td0FzdFlDblAyNjNxcXk4bmdiZWVrZ1Jr?= =?utf-8?B?UTBMMzFaRk9Ua1JsOGlkcHZ1MHJ6OHM5b01WUHJmclppNDUrRGF6Tk05U1lo?= =?utf-8?B?d0hqNXppSmR4WmN3dzNkSUkxWW93Rm8wR1hPeWFLL1V5dVJYclNybE5nbncz?= =?utf-8?B?cUVNUmE1NHQ1T1gvMnZNZkRjT0djT25zcWI2Q2daT1hmSmlQWVc2cUNDa054?= =?utf-8?B?K0VKT1h1eVNlazhwZUFmY3pSaWF1akJEL2s3TXBBY1Z0U2xWNTBSNzBQOGwz?= =?utf-8?B?SHRvV01obE4rdmxLNmhOYTdTcHIvOU04L2FPNk1GMndqZmY3bHRPSDNXTUVP?= =?utf-8?B?cjJ3Ry9sNjFYV2lmRHRJR3hKWFVQM05mbVVBeE9SNm5CeW5PdFZjaEsxRWlD?= =?utf-8?B?QnBpL2htWnJsMWJ4c200SWdFVHJwMXMwN3RUVnUxbVFmcU5yb1F1N2Q2RHdl?= =?utf-8?B?SERzd3dWQVNCaVMwWE5MdVdOTE5QTEk3UU1HajBQdGowYnFhbHJKb2lQeFhQ?= =?utf-8?B?TlNmTGxWLzd2UDhvQi9FTXVsSVpGelpmSzdoMUdjMnlTb2ZPL09naS9Pbks3?= =?utf-8?B?Sm5IVlltVWhtN2JQWGpiZ1dwams5VkdPMk94REQ2RGFQVHdTMWwxL3VGS2NK?= =?utf-8?B?T2xYNlh5ZW1tYmJpUkdBL0U0dms2c1grYWRKRjNFYlc2Z3dpQzhoNkwyeDRt?= =?utf-8?B?SE01ZHo2ZmZnWmhyT3NpY1hNM3IxKzJTVyswYy85WG1ydS9ZT3krZ1MwS1VH?= =?utf-8?B?Q2luNkNBNjM2dWk1WXd1cXJ5OHRpeEdOUDBoNU1BT0dXZnM0Sm1tY3pKS2Rm?= =?utf-8?B?dUZ0V1J3OStiQ3pUREFwNmN5aXA4TUR0endTSkljRVBFYmZydTlZQkNyNjVP?= =?utf-8?B?UzlIWlRwdTlUdzV1T2d4Z0JWRE9ncGdnczhKRWlZZHVPZE41ckNWREtIM21k?= =?utf-8?B?OVRPT0ZxeUtkSy9KdGtnVjFGZVpNbVRURElLTWlHM2d3SHFrN2hrNGE5UkJK?= =?utf-8?B?RVZHdGQvSk1zazBOSmw4a1N4ZkljVURmZ21DNzZMc3E2TVJkSlBsK3ZNMHd2?= =?utf-8?B?clRmWnZyMXNCTWlNWEExWWFaMldEYlFiVUlUV0RwMkVWSnpWdE5TS3dlTEh1?= =?utf-8?B?YThmcXBRSCtvOXMvaGJOSEJzTFo3amV3Q1QvV2VGbU81T09FbXgvTGc5NCtp?= =?utf-8?Q?xEgg=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?K1ZjY2xmZHZiaUZIbFhXSlBYZnVCTmErczhtcFBIWWdNN3E3am5USWtjZVFj?= =?utf-8?B?d0lObE1UM3g1cm9NWXU5NmVzMmdTMzZGY0w2U1U0WUNodlY3bEhRYWNTWktN?= =?utf-8?B?aGJsWVA3ZDZlT1hsdU9JUDdlQ1NDSHBNUDBUYkZwaFVoVlBCMndYdHhhNlF0?= =?utf-8?B?bDVTdzZQWVJDS2VkZmdHKzJOS1JSQ1Rmd0dNMGtSUVlqM2F0S2ZtcWVaV241?= =?utf-8?B?SDhLbDFJR2I4NkROMktRZ2ZIVzdyUEJZVTZpdDB0Nnp4Z3NaZGtDeWJkSEsw?= =?utf-8?B?VXRYOVpaMXBKUUZ0dUNrTTA2dlRJNTFUWEdpL21iRWRLMG1ldXZiNWRXUmNp?= =?utf-8?B?UEttdUVSS0J1U0ExMzVRb1F4MlFSdXhUaW5aNGVzOGd3dTFyTWlmbFdYSHBO?= =?utf-8?B?eklHS3d6dDhlTzZRdzhCWkhLaTRoUUlIOUxpNzlYd3k4K3hmTnFVejhJR2hv?= =?utf-8?B?aEtCLytnd2QwbXhPaHc2RkFnRVhVaTluSXhSZmlJRkNlWTNjU0wwSy9yYUtr?= =?utf-8?B?bERHd3U5R0JGU0JRdXF1TmRKcERwc25jNDQ4ckNxTWFHRGhwbDNjMVFYYnhC?= =?utf-8?B?MXA3cTdVUU94MGJkQmtLWkxCWlpkZUgveHVqY0RGRGxpckdwaDBCM25qQkZS?= =?utf-8?B?K1pLNTlFb2dpNWtCRnJLN2ZhSXZEZko0aGVPQlNUTUkrSERZdStMenJkR3d6?= =?utf-8?B?ZTdoMVR6UXdXQzBRUkFmRDFtNmhjMHozMEY3b2hWS3AyWHg4YVJTMjNIc1lO?= =?utf-8?B?Yy9nUmpJMUpvOEFCS2pJNnB3ZHhwWXFEM2FoWHhPempyRDdjaTA4blBaR1Uz?= =?utf-8?B?UnlOd2JMajNTZDUxZVltcjV5bGpLNnhrZHYwTXQ5ckZaQ3FVYThmYjNEZkNL?= =?utf-8?B?Y0lsSVVFZ29aOUZzbUdzdUZ5enBvWXJWSjVOa2x1RzBUZWZla3hwbjR2dFRn?= =?utf-8?B?Z1VjbS9BT3l1dDljZVFEck1TcFdFTEx5Wk1NN0F5Rkh2Z3VYNDYzNTRmV0lo?= =?utf-8?B?emduaWUrNWxiaEpyOVRkQUZYUFltUDVaYmEzcm9heGo0WVY3MTFFN01vRVIw?= =?utf-8?B?YWUvQ2tsZTNSUWlpS1RuRFhWS2F5RUE1azVJeC81UUFkZFVGYlo1SGZvWXJX?= =?utf-8?B?Z1dDeDQ4eG1uTUEwRDN4OXFpcjdxK2wzeHpmM2NBRUkrL0R6clFTcFBzMy9T?= =?utf-8?B?Z25LWXdESVJsd2Nla2ZuZnJjbnhjK0IwUkJpaUVaR2VSL0hOT256SUFyR05h?= =?utf-8?B?bURQbXEwdDRleStoZGw3VmZvUWRsUTZBZ1EwZktPL1lVSEhoRStadmNKTThs?= =?utf-8?B?TGJEOWhBeHhLTy9RaFUyREtsSHdQVHFyWndkR3A2cGlFaVVONytvdjNER0ZC?= =?utf-8?B?b3Q3bDdBM1lmaHhhSExEcWlJbzZrQ0s2cXgvcmE1VTA5Q25VK2l2UXVFWGVo?= =?utf-8?B?Uks0MTQ5UmJSNWFJUzZuQkpLSUNicmRLNjgwYm9tQzFSbkxXdDhmMUMwd25m?= =?utf-8?B?Q3VkejFvclJBK0Rqdk9sdGdRSm54eUdOaWg0K2VmS3NQRWR6SWtJdWpFb3hz?= =?utf-8?B?R21UNTVKbE8vVFRUVURzTjYwQU1NZ2NRUmgycUNXSm1wbzN3c2VNY0F6RThE?= =?utf-8?B?RXJwd1ZpV01ZYzJBZE5USTRITktGR3VEYjhrSkYvMzM1VjhxTEdVYkUrN2Ur?= =?utf-8?B?R1RwVHoxZy9VSGNwempRZkh6OG9sRVc1ajFITldFLzZlWW5TK0UwdmVkNmZB?= =?utf-8?B?QlBjTm0zVjFnWUJENjU5bTBNc0NmNDNwbHgzY2lLV1N1V3pJSm5URG1qTG5m?= =?utf-8?B?Nk1NaUZGZTZBaGZ1RE9VUDFhblRSdEc1dS9pR2RZdWdMSy93ZEoyZlVDcldo?= =?utf-8?B?SXlsOU9nV240M0ozeUFXZ0k2dUVDQnJBL1M3WW05eGxpenlhSTBvcWxiVmFG?= =?utf-8?B?K2V3bmx1b1kzNkYrQzRORFhGQmpXc0xiZFBpY1BzNWYxTy9ReWdKRXFvam42?= =?utf-8?B?WGZMYk5pOHpHVnUzajFqWFpQc1U1bGhJY2FKTzlDOXZUZFp5Tm55cjVCamRM?= =?utf-8?B?LzJxK1owU1phQWM0ZHNZOWZhSG45VXlQeW9MNG5wZzIwdmVrc3pKYjg1aWdw?= =?utf-8?B?cjcxMVhHSnNCaW9TTjFoL0kzT0xIMUdJNmhXMEplMHFReG40QkVsL2Z2MThk?= =?utf-8?B?ckcwUXNJQ0w2b2RBRWEydTJXTWRoL2NTSUtJN3FLWmhoUW4zTHplNzFKcXh1?= =?utf-8?B?Ui9iVkhYWHhkNnNXV0tJVE16L3AzZEVFZXc3LzVpSlVRMkNxZ1dqMkREWGp6?= =?utf-8?B?RXZIV2JHczV6ZkFoM2IzVjc2SDRPcTBiRURNcXJWcGw3L0pmNFRxZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: fac5c2bd-a62b-4b88-5376-08de578d26bf X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jan 2026 19:01:28.5931 (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: Ysi/vySjY/aZ5Xh3sOjD60NjptyK2Mg0Z4vkebsw4OkFem97QmC8OceZd2jJB+Pde4bBTXnNgN8Y1apIRCCPiPnwoEOK+GJBik/bRw0JlU0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7913 On 19/01/2026 10:34 am, Julian Vetter wrote: > On 1/15/26 4:50 PM, Andrew Cooper wrote: >> On 15/01/2026 3:17 pm, Julian Vetter wrote: >>> +{ >>> + uint64_t misc_enable; >>> + uint32_t eax, ebx, ecx, edx; >>> + >>> + if ( !boot_cpu_has(X86_FEATURE_NX) ) >>> + { >>> + /* Intel: try to unhide NX by clearing XD_DISABLE */ >>> + cpuid(0, &eax, &ebx, &ecx, &edx); >>> + if ( ebx == X86_VENDOR_INTEL_EBX && >>> + ecx == X86_VENDOR_INTEL_ECX && >>> + edx == X86_VENDOR_INTEL_EDX ) >>> + { >>> + rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable); >>> + if ( misc_enable & MSR_IA32_MISC_ENABLE_XD_DISABLE ) >>> + { >>> + misc_enable &= ~MSR_IA32_MISC_ENABLE_XD_DISABLE; >>> + wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable); >>> + >>> + /* Re-read CPUID after having cleared XD_DISABLE */ >>> + boot_cpu_data.x86_capability[FEATURESET_e1d] = cpuid_edx(0x80000001U); >>> + >>> + /* Adjust misc_enable_off for secondary startup and wakeup code */ >>> + bootsym(trampoline_misc_enable_off) |= MSR_IA32_MISC_ENABLE_XD_DISABLE; >>> + printk(KERN_INFO "re-enabled NX (Execute Disable) protection\n"); >>> + } >>> + } >>> + /* AMD: nothing we can do - NX must be enabled in BIOS */ >> The BIOS is only hiding the CPUID bit.  It's not blocking the use of NX. > Yes, you're right. >> You want to do a wrmsr_safe() trying to set EFER.NXE, and if it >> succeeds, set the NX bit in MSR_K8_EXT_FEATURE_MASK to "unhide" it in >> regular CPUID.  This is a little more tricky to arrange because it needs >> doing on each CPU, not just the BSP. > Ok, yes, I have modified the AMD side to use MSR_K8_EXT_FEATURE_MASK to > "unhide" it. Great.  And contrary to the other thread, this really must modify the mask MSRs rather than use setup_force_cpu_cap(), because we still need it to be visible to PV guest kernels which can't see Xen's choice of setup_force_cpu_cap(). > >>> + } >>> + >>> + /* Enable EFER.NXE only if NX is available */ >>> + if ( boot_cpu_has(X86_FEATURE_NX) ) >>> + { >>> + if ( !(read_efer() & EFER_NXE) ) >>> + write_efer(read_efer() | EFER_NXE); >>> + >>> + /* Adjust trampoline_efer for secondary startup and wakeup code */ >>> + bootsym(trampoline_efer) |= EFER_NXE; >>> + } >>> + >>> + if ( IS_ENABLED(CONFIG_REQUIRE_NX) && !boot_cpu_has(X86_FEATURE_NX) ) >>> + panic("This build of Xen requires NX support\n"); >>> +} >>> + >>> /* How much of the directmap is prebuilt at compile time. */ >>> #define PREBUILT_MAP_LIMIT (1 << L2_PAGETABLE_SHIFT) >>> >>> @@ -1159,6 +1203,8 @@ void asmlinkage __init noreturn __start_xen(void) >>> rdmsrl(MSR_EFER, this_cpu(efer)); >>> asm volatile ( "mov %%cr4,%0" : "=r" (info->cr4) ); >>> >>> + nx_init(); >>> + >>> /* Enable NMIs. Our loader (e.g. Tboot) may have left them disabled. */ >>> enable_nmis(); >>> >> This is too early, as can be seen by the need to make a cpuid() call >> rather than using boot_cpu_data. >> >> The cleanup I wanted to do was to create/rework early_cpu_init() to get >> things in a better order, so the panic() could go at the end here.  The >> current split we've got of early/regular CPU init was inherited from >> Linux and can be collapsed substantially. > I have tried to add the logic into the early_init_{intel,amd}() > functions. But it seems this is already too late in the boot chain. This > is why I put into an extra function which is called earlier. Because it > seems there are already pages with PAGE_NX being used on the way to > early_init_{intel,amd}(). Because when I put my code into > early_init_intel I get a fault and a reboot. What do you suggest? Have you got the backtrace available? It's probably easiest if I prototype the split I'd like to see, and you integrate with that. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jan 19 19:39:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 19:39:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208290.1520489 (Exim 4.92) (envelope-from ) id 1vhv5h-0007Kp-5r; Mon, 19 Jan 2026 19:39:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208290.1520489; Mon, 19 Jan 2026 19: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 1vhv5h-0007Ki-2t; Mon, 19 Jan 2026 19:39:09 +0000 Received: by outflank-mailman (input) for mailman id 1208290; Mon, 19 Jan 2026 19:39: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 1vhv5f-0007Kc-EW for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 19:39: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 83408502-f56e-11f0-9ccf-f158ae23cfc8; Mon, 19 Jan 2026 20:39:04 +0100 (CET) Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-432da746749so2389517f8f.0 for ; Mon, 19 Jan 2026 11:39:04 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43569922032sm26146475f8f.8.2026.01.19.11.39.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Jan 2026 11:39:02 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 83408502-f56e-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1768851544; x=1769456344; 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=1LuowZkM4E9Dk4HGNIH/SL9OY7qq6DsAGVlOw3BlToQ=; b=TIxt/hCbTz2KFP14YddU6D17dXpHD/vtYMaGmkv9WnDCeQ121r5OAyMI76QmnXeD8c Hu9gnftzSX0YlWJe5W0dfjuOQoukE/R14bhwDrTIDhU5VHkrFN6IB2quYF//PnUDRFn1 0z/qHu40goZalhW5Yrqso8tSswSJc3DSKliSc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768851544; x=1769456344; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=1LuowZkM4E9Dk4HGNIH/SL9OY7qq6DsAGVlOw3BlToQ=; b=l4mKDf6PR5PsNU8EhQo3UQZtZg3qhf31YXcIL46gxGy/44VOvWQqMUezQIdOk/f3On uMnQCiOwosJIsMamPkExGzbtaDZpVpEwtMF2wyIZK/9eKLdJwrggFYTBbeO3fu4rmzS0 Q8xTCsgtcmJ+EKvmRv3YV8F1kUIbf7NzgICwEYOSbSGDVyjPrNtokOxr1pLD5dpshRio f6H5V6HXooSZpYJ7gFSdpXVMzDI5i/5CVNdFwmrjiGE5mvZ+zblv42deVF6LQyGa2em2 1fHYxAYlpqnDg8w0qNm2Yl3z/uCUi/JmUht7aq3yiPteHMYmI9ZIbpNM0Ua3mUb1dRzx BGjA== X-Gm-Message-State: AOJu0YzJZZ1OgerzDKgTr8iXaDXql/lZIBMZ8cP9McM4mqeAni7xj0Zp RYydAr6ZOopGZDaezE4ye2AoNnRLGdz02EI5jj1miZMZ+yCvhzr0NQzKipfqB64a6R/9Al0W5s+ lffb4 X-Gm-Gg: AZuq6aJ5uaK2SDj2UU8GrlDzPivoeOMuZG9BXpeOrOH7SXGJ8SBQDzpC5+FtNO8Vt12 Z2gHauxg3pdgM+Cijv/X2+mOUDyUVYZM9T37+Ka7reyKInvYd3QgX5HPbePwS3gmMDL+2bVbHBZ v6lh3RZ5LTmFb5m3Ndqx63eXpcAH+Fnr0p7tLcTNNHMUrZ+6nDrwqEeOWKZCQEdb613/1rx091H brZQWyQskEBgc+HeUMV8qOlKeMHGCfUqKXrKPIznBFTXaTlStYuDRAV4FNfqoM6/f+qv23G0c6S JUJ+2gqBKjXv+ZlyTXyqsIBjK6s/Nfkohuk8kA8Hne6Qzwq39I2TbfpsdWD55bfsmb4zW+gzG2s m3fEeniow3Sm1By8P2H/keo98tqkclQDJXEBNZaQu47uqE0m/hqzYyoAGiVRUZC75b1thjwiNX4 f+56VK7B7sZNbKtCKHwiCL5UYyI8rlZMNH62iFq2txeG8YopvqigKzcXXQNwwF6Q== X-Received: by 2002:a05:6000:1789:b0:430:f7ae:af3c with SMTP id ffacd0b85a97d-43569bc1801mr16921908f8f.31.1768851543093; Mon, 19 Jan 2026 11:39:03 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH] x86/intel: Drop more cpuid_mask_* infrastructure Date: Mon, 19 Jan 2026 19:39:01 +0000 Message-Id: <20260119193901.1354905-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 Despite removing references from the documentation, the Intel parts of CPUID Masking were accidentally left behind and still active. Intel CPUID Masking is even more niche than AMD masking, as the MSRs only exist between Nehalem and SandyBridge, being fully replaced with CPUID Faulting from IvyBridge onwards. Fixes: 317051c2f032 ("x86/amd: Drop the cpuid_mask_* command line options") Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné --- xen/arch/x86/cpu/common.c | 13 ------------- xen/arch/x86/cpu/cpu.h | 3 --- xen/arch/x86/cpu/intel.c | 18 ++---------------- 3 files changed, 2 insertions(+), 32 deletions(-) diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c index 37820a3a08ab..79573384ea38 100644 --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -31,19 +31,6 @@ bool __read_mostly opt_dom0_cpuid_faulting = true; bool opt_arat = true; boolean_param("arat", opt_arat); -unsigned int opt_cpuid_mask_ecx = ~0u; -integer_param("cpuid_mask_ecx", opt_cpuid_mask_ecx); -unsigned int opt_cpuid_mask_edx = ~0u; -integer_param("cpuid_mask_edx", opt_cpuid_mask_edx); - -unsigned int opt_cpuid_mask_xsave_eax = ~0u; -integer_param("cpuid_mask_xsave_eax", opt_cpuid_mask_xsave_eax); - -unsigned int opt_cpuid_mask_ext_ecx = ~0u; -integer_param("cpuid_mask_ext_ecx", opt_cpuid_mask_ext_ecx); -unsigned int opt_cpuid_mask_ext_edx = ~0u; -integer_param("cpuid_mask_ext_edx", opt_cpuid_mask_ext_edx); - unsigned int __initdata expected_levelling_cap; unsigned int __read_mostly levelling_caps; diff --git a/xen/arch/x86/cpu/cpu.h b/xen/arch/x86/cpu/cpu.h index 8bed3f52490f..bbede57ab00d 100644 --- a/xen/arch/x86/cpu/cpu.h +++ b/xen/arch/x86/cpu/cpu.h @@ -12,9 +12,6 @@ extern const struct cpu_dev intel_cpu_dev, amd_cpu_dev, centaur_cpu_dev, shanghai_cpu_dev, hygon_cpu_dev; extern bool opt_arat; -extern unsigned int opt_cpuid_mask_ecx, opt_cpuid_mask_edx; -extern unsigned int opt_cpuid_mask_xsave_eax; -extern unsigned int opt_cpuid_mask_ext_ecx, opt_cpuid_mask_ext_edx; extern int get_model_name(struct cpuinfo_x86 *c); extern void display_cacheinfo(struct cpuinfo_x86 *c); diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c index b76797cb9a4a..284101e4ea4c 100644 --- a/xen/arch/x86/cpu/intel.c +++ b/xen/arch/x86/cpu/intel.c @@ -259,6 +259,8 @@ static const typeof(ctxt_switch_masking) __initconst_cf_clobber __used csm = */ static void __init noinline intel_init_levelling(void) { + uint32_t eax, ecx, edx, tmp; + /* * Intel Fam0f is old enough that probing for CPUID faulting support * introduces spurious #GP(0) when the appropriate MSRs are read, @@ -275,13 +277,8 @@ static void __init noinline intel_init_levelling(void) probe_masking_msrs(); if (msr_basic) { - uint32_t ecx, edx, tmp; - cpuid(0x00000001, &tmp, &tmp, &ecx, &edx); - ecx &= opt_cpuid_mask_ecx; - edx &= opt_cpuid_mask_edx; - /* Fast-forward bits - Must be set. */ if (ecx & cpufeat_mask(X86_FEATURE_XSAVE)) ecx |= cpufeat_mask(X86_FEATURE_OSXSAVE); @@ -291,23 +288,12 @@ static void __init noinline intel_init_levelling(void) } if (msr_ext) { - uint32_t ecx, edx, tmp; - cpuid(0x80000001, &tmp, &tmp, &ecx, &edx); - - ecx &= opt_cpuid_mask_ext_ecx; - edx &= opt_cpuid_mask_ext_edx; - cpuidmask_defaults.e1cd &= ((u64)edx << 32) | ecx; } if (msr_xsave) { - uint32_t eax, tmp; - cpuid_count(0x0000000d, 1, &eax, &tmp, &tmp, &tmp); - - eax &= opt_cpuid_mask_xsave_eax; - cpuidmask_defaults.Da1 &= (~0ULL << 32) | eax; } base-commit: e80f4da85b29f888c0644749b0a4ab29a9f2f6ca -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 19 19:53:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 19:53:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208306.1520499 (Exim 4.92) (envelope-from ) id 1vhvJo-0001Zk-Hc; Mon, 19 Jan 2026 19:53:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208306.1520499; Mon, 19 Jan 2026 19:53: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 1vhvJo-0001Zd-Dz; Mon, 19 Jan 2026 19:53:44 +0000 Received: by outflank-mailman (input) for mailman id 1208306; Mon, 19 Jan 2026 19:53:42 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhvJm-0001ZX-6G for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 19:53:42 +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 8cdf3292-f570-11f0-b15e-2bf370ae4941; Mon, 19 Jan 2026 20:53:39 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by AS8PR03MB7414.eurprd03.prod.outlook.com (2603:10a6:20b:2ed::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.11; Mon, 19 Jan 2026 19:53:37 +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.9520.011; Mon, 19 Jan 2026 19:53: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: 8cdf3292-f570-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bW1Pxpx81v9f5DlTrhuG+887r+S4tZqGO9jxNyAK9Amur1Jm4hRqRNTtiKh7RsfX2RnMiimuZ6wWLAA0gWmwCO9KSiFi6ktDcpwIhJs8CtZpq/amwIuBMnMmzBOycfKzBrQdqoImDFVF1+WEj1R4Eqi9vxSZx2GzIsNcoFkvzYCOscGBCQ0kX++eVPlru6bueXRXiifcQO5BIuJAtqJLVe7o+GR6akh0KzjLQ++edJ8u++KcvPWd3PJVXS8cm9yS+xaaqasn7ocY6iGvt/LVqkkyPlZt040SKN8dC751LRhqlcX/My4ufafPn5hydobjFlI+cXdM/OoDeu9uHPeptA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zPFQSF2/T3WPz7VkOswcRQlqtFvPtIlKUZE601xZbxs=; b=xHwD5IsSp3FPyl3o4VbNK2zcgABXtlBWM9KuTb1xh0KuecSsv71UrrWP8xmF39vA5RxcU+BUSV5X8+T9eWW4uMnVg6HHiur9O5ivpY9dEqhljH2IHl7ax47BvtSrIoxgVbNR7BLj9e66DCshzv3vmOjtsXm9jqOgdV9k+577OKeNEhX58ugbRa5imDWJxYRApxIllyTS/BcXWtqzzouN/UgGG3u4Pq2p4+8gzz8B/BxfVSBS9yk+YcWu9oPL/2I8hhkdEyBHQqJ1Nwf7hv/r1ZinZCXbCDgVOhULxaH2CkFe6umwPRP43KmYN9NznYc1OmABXsQYjJQJnEWqkN+3Zg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zPFQSF2/T3WPz7VkOswcRQlqtFvPtIlKUZE601xZbxs=; b=UeQLxk5pkOWs5BNjjybnYpqjVhcWBhs5RUiCBQX6QQ2zc+hfYx+re75RJWLdRCQJFd98vzlHCvyIxju6xWWvjjWlKMy8P9Z3dGRe9miZSThVaXag/HzNoGJZ9MQ58qaRXIm1kttDDC9nlPx7z5SvBzUX/M4vs/L/GXkp676OCkzVd2jMaTiFP3JU6dYaY6tOWaF2ABlO7TVHujrUkKAgz8nzSXpordjqgshFHMRVuMBXnQLdQzQutIaeo83PytoRPXdYPtcja6owvwSpyrF32v7OjxrtcAzy/dss+RwpZWhMGV8qjImJ0QLQiqgj/08opgHSmOvP2NITPyU8jCu6iQ== 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 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [PATCH v7 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHchYPEY703sAu32kaCSJHhjFUjhrVSbXkAgAKOa4CAAFUugIAEnmUA Date: Mon, 19 Jan 2026 19:53:37 +0000 Message-ID: <5177397f-d596-40b3-9207-f0de63a24ee6@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_|AS8PR03MB7414:EE_ x-ms-office365-filtering-correlation-id: 04f8f84d-c388-42c8-4311-08de57946fb2 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?R3I4Ulo4cEU0Wis3TnJQZ3NMVElHbFRSVmFabWVKdnFjbDZweDAxQk9wTnFW?= =?utf-8?B?VDJ6LzkxbnJZUjNuSkJkRnQrenJoSUZZK0VCdjRkckhQTFRXcndoK3ZxQkxC?= =?utf-8?B?anFvU3ExMzhnWFdjbGlvRFRZSkhheUJsYTJRVzRoVllyc3dkanlCL3B0V3RE?= =?utf-8?B?Q3FFUTlpYnowQkw5WE8zVWl5ZmxDeVJNVDVxbFU2dXFoWHhMSzJVaUlQaU54?= =?utf-8?B?WnRodDFJMG9JQWZxak01d0YraHRKS0lnUGhxTE1uQmRSam9GMnlKUVhpVlRj?= =?utf-8?B?NHJGcExIU2ZyZVVSR2JlOVZ4T0FHVzhwazVwbzcwL0xkWUxBd2tZTG1xbjY4?= =?utf-8?B?RnkrWkdaa1RFNjVXSnhVNWNaL1J3RmRadHpreHFMZFo5MVJKbWJHelUwQzBu?= =?utf-8?B?WGp2am1RbGNnVWlMOTZzZmRBVlVBbzNldzIzUHdpSWNzdmxXbmpJMnFIVndm?= =?utf-8?B?eEhYMmYrWkNUZmxoT1hPZmRvSko2ZHEwZE85SHRTcEt6bGlYWEFMRGJYY3U2?= =?utf-8?B?MG9PNGhjbFhhNWFaL1MrWkdaSWNGT2dDOWdYYk1hZ09ucHJXc05SRzQ2ZUlB?= =?utf-8?B?QlRzTlhGSlNlUElXYUlDWk5YZE03NmhvS0NZbm5VclJkbzdqRSs1RHNoUEdJ?= =?utf-8?B?VTlJSWFMYnZxYUM4b0lIOUpjcGh6Um45dEJJdlVWS09wL0tqL2R3UjhkZDdL?= =?utf-8?B?cWxNWVMvUGpVUUQvUUwzelRvVXp2UHpIeG4wVlc4aGZBQmcyTFhjSk9PcHp5?= =?utf-8?B?UHV5cmp6WWVWSmptc0hkeHBKRDV3TGN0WkRQUmMzUmw5QldzdDFva0JOV1pD?= =?utf-8?B?QVVTcmFLRm85VThxYUtJTXpSeXhrMGRjYXR0M3VuK3JLTDhPNVd1T3NadUlt?= =?utf-8?B?cmdvaldqOFgraDVOaVExTFdad3E2eXpDeG5Jd21lKzY5NUYzV1BsdUJEM2Ji?= =?utf-8?B?VkxpNlllY2FtWVg0azBaNTdaZWdldzF2TXhYVHNQMGJpZ0U2OEZDaUttSmxR?= =?utf-8?B?ejBHcUhMTFV6TkcvUk5xd3dEbi9HNUF0b2FudE0xVHBpdml0NEhLTlFxZlIy?= =?utf-8?B?WVJwaXowYUg4ZUVsbTkyMm5udG8yOFh3c2wvSk00MFBkbDlFS3lrU2ZVNVBV?= =?utf-8?B?RkhSWjd0T2c5SVMxRUEwcmZjV1hUSFo4OUNPVERzSDVTUFBDUTFYam5ZMlA0?= =?utf-8?B?c0RyUWptc3V1M1g0TnFrYVdpT3dvZ244dVE2TTdpOU1tbjlTamZ2NWpzNnht?= =?utf-8?B?aVhlclIrZDBtREVwdXJrOW8vVUlBSHg4YTdacGN1TjQ2bHNsem1HWGcxN2pv?= =?utf-8?B?MHhOMHlkbVhIWllGcWJDamc2bGFSUFZuT0xsbFF4RjZEdDlxakhlN1hwaVBh?= =?utf-8?B?Yy9ZWkJUM3NKcm1SMHppWUJDbWJaZjEyY20zVDhGQzhWbUxDUFl0TzJSQXNo?= =?utf-8?B?NTVwRSsxdFFVUUFsVENUd2hqVVp2NnJwZXRYZXpacVcyb2ZFVG9JMWpYd21v?= =?utf-8?B?QzVNY0tJaGEvdE9vdnVuWjA5aWpvL2FJdFZuUkhjMnVpdlAzd00ybHVnZkJI?= =?utf-8?B?T0VNbTQ0VFBsdUFOYURJZDJPWSttNDc3cVZaUGtqb1JaSGF3SE0vTUUwRDc5?= =?utf-8?B?Tk5ESTNKL3RTbDVKTm5IQVpBUThwL0Z0OW5Db3A3c0VOaHF5cXdZdHU3aDFX?= =?utf-8?B?dmMxTDlSNkhDWERrT3cwa3U1K0RLanpqZmtpalUrTzdrOFJKOWZQZEF4Umtu?= =?utf-8?B?M1BRZGtZaFc3czQ3WnVxZC8zZzBLTjZMSDNYUHNGYVZqM3BoMDUvV2JlbDNw?= =?utf-8?B?clVvQXhXWTNlTVNtYmlDMy90MmdRU1ZQYXk5KzFPNlJjbU1rbGQwaExFTjRR?= =?utf-8?B?MzczbW9YTllpckhwdTg1OUQwYnVXNGVsVTFRcm0yZDFXVDNDMmg4U0k4MDBF?= =?utf-8?B?RWcxaGd6bG1NN2dnWXpBNFFhN2JvNnA2S2R1cGlzc0FNOGVoQjF4UlVIcldZ?= =?utf-8?B?ZTBGcjNqSjkzQ1c3N0NnaGlveTN3VXQxclRId2toMHNFU2VpemxyNkZqSVVj?= =?utf-8?B?bVl5M0xEZkNlNVZXMEF0RzZpdDUwUDNNWHJyNTZqOTVwWFJwNmZsdkozYU4x?= =?utf-8?Q?Ni+RffzjQxLgQzwtekXcvEV5Y?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?R1RLTFpaakhlVE53YThVUGR3WXFKT0JiSDhTUkVZTm9JVVExeEVpcVllaGhO?= =?utf-8?B?ZjdzTXdJa2l1Qk1GUklYVFlqeGJUc2tUb3U4NFM4enMvYXhWc0E2cFQzWWlE?= =?utf-8?B?U2UrbUV0Tk1tcGJ1YjYvUktFdmtpVEZES0krdzZnL1dZWThCMWRiU2d4R1ox?= =?utf-8?B?NjhQWVNlWFR1NWRkM2MzZTkzYnlsMDNaR05DdXF6K0F0WHk0czVDcndnQ1cx?= =?utf-8?B?YzIrTER6RmJ0ejVlY1N5SXJlYXY5RTVROUJBL1A2MmEzVGxNRGl6V3gxNUFm?= =?utf-8?B?Z3ZodUpOQlN0dzlTaGpzRUdnbzhQSUFhV3EvQjFPRUEyQW5OS2dUZE53Zy9B?= =?utf-8?B?YmptZ3lvSW53S3Q0cEovUm91dHZKQXgxVmJKaDFpbGFuR3NYajRwNzBDaEVL?= =?utf-8?B?T1lCK2JBUjRCbldSd0JoaUlxVFFvYTNLSVJwcjMwSzBVcjVjTStJSkhJQ21V?= =?utf-8?B?YzlDV3QzSkVscXdmNnVCVDhPNGRyd21zcFBudncwVE1VVG9oRFM1MjdxZk8v?= =?utf-8?B?NnIrWEVvME9UMFlJMkJFcldnN1pSV1dzWGY4OTJYTHJ5aWtCOWNlMFN1elA4?= =?utf-8?B?RVFheEdmcGJ1MzFXVnhUZE9UMXpjWlZTVU8ycDVOMmlzbFljZ1BoNzczWkFZ?= =?utf-8?B?TE9FNlNNWUd5dExmclB4TG5PUzR1VGt6b3BUVUR3bFpPMXlnYzdjKzFiOEFp?= =?utf-8?B?NjYvcjVha3lKY0xVakUrQzM3TjZMYmVxWGxaVitpNGQzU3ZkVTE5Rzd5R2pR?= =?utf-8?B?SjJUWk8vRnZtY21NWXRFeXJuSDZGZEJYU3ZYUmZLUlF6TmcxN1VIR1ZuNWp1?= =?utf-8?B?STZDY20zVmFpcHB4a3AxSUNScDdiazI4akR1elR5TFR0K1FqVkx6VkFYYkg2?= =?utf-8?B?MWtjWkZ2K3ZnQWwzYytxdUpzNE5LK1FYdm5OZlBXajRnTkhiKzZLd0RaMjA1?= =?utf-8?B?bmpGWEFZQzYvbWlVVzhFZ3JqRzZtTHFMTzFjR3J5akQ4TW1oS2x6NmlRWVB1?= =?utf-8?B?VFg1WFc3RE4zMkF6Y0RUS3J0NHZXdDdVTWFCS0taVzlUaEN4S3ExWExMWi90?= =?utf-8?B?SWVBVThyNGVQNjdhb1Vqa1ZNSkZlaTl2VllFZzdqMTZKeHR5RVBVdUl6Q1M4?= =?utf-8?B?KzNuTEEwZ3VWbzlBYWNKWGxZSVlMTzFBU3AvSFR1aVR6MkhtQmhqdnMzVzVT?= =?utf-8?B?ZkZnckRPbTFkWVZqTXJFTnQycFBENWVJVy9JSzNFQVJCNXNMTEVRVjdHczZZ?= =?utf-8?B?TVRVYllYWjdkSlhldXB1L3Z5NUpNZmVXN1grYmM1RTZuN01XcWFZNTFGK1pU?= =?utf-8?B?aU5oSk9DWmFROGU2aXVYZHhpeVFSTlBKUFFieWt5U2orZEJ2WXcreE4vSmcz?= =?utf-8?B?YjhKLzdLWXV1Zk45eHFDWWZlWG03NU51aUhQS1BHb0RWS1o4dm9XOUZjOHYv?= =?utf-8?B?empxdzVVK1M0M1dKMUV5S1A1bTFWTjZRSHh1KzRSZlFaeUsreXg5TnQvS0RN?= =?utf-8?B?TysxVzkxOVFDYnJFbXlqSCtBZ0RXLzQ2S3NnRzcrdytMZEkzbkFnVEs5eDgy?= =?utf-8?B?WjhQc1lGbXNWYStBM0lvMnBTODdXU1hMOEk2QkJjbTRmbXZFcDMreXVvekRM?= =?utf-8?B?T0h1ZkgrQUNKbnVuTXlRN3QwODZWcnJyL2grSlo2TjNjSWNEVjI2WFJQMjlQ?= =?utf-8?B?ZnZOY29ZU1gwOGpLZy9DTEZtYmxFakZnb1FQY0s4SldKc3FMY2VKTTVNQnhw?= =?utf-8?B?UDdsN3l6SW1rZnFQOW9XNVdKVjQ1RE15bXIxWS9oQmFqQ2VyK0tUWk1wNHJz?= =?utf-8?B?MEVaNFVmdFpXOGxSTlo3VHg1eVRoK1krSzdVYmRNS3FkejFrdGlublo4K2Qy?= =?utf-8?B?eWpOYU9yOENuSjZ5MkRraWtzeGp5UElsZ0hCV3podmlTYzNFK25BbklNdFkz?= =?utf-8?B?WXNwTXpCOVE2THMwUk1mK2tSdnhMaUt0a29HaUoxV21hcGU1QklEc2kyWklB?= =?utf-8?B?a0pjMWYrUzk1QnBQSmd0dnFkQnZCRENXMU5nUHRLRk5xNXY3Vkx2Uml2d29m?= =?utf-8?B?Rndua05pWlNnOHRxbDI3V2wwY0pHME1Jd3M5TzJaY2F5Z1JpT25takZvVTBK?= =?utf-8?B?RHNITDVqc0xndmZlalpJeUVCUHRvNG1HQWRRNzVvSklQR1MzNVliL0dTR0ZG?= =?utf-8?B?bnAxbGpOa1BlNEgzQVNRZ1ZraWpRSE5sbTFBeERqV3pmWGZ6WFV2RjVheDg0?= =?utf-8?B?WXN4cWJRS1hQTU10enQ0WW9EcVQyMG1kNTU4ZEY1Sm0xL1MvU3JGMnlMVVRh?= =?utf-8?B?MWZsVlgvT2Y2cllUMGEwOW1XdURTeTVlV1ZyY0xyUGZXRGRnSlNqcDZLaUpa?= =?utf-8?Q?Fleuqpikjit16oss=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <9CE9C26151DB2748A347AFDBCF47AF28@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: 04f8f84d-c388-42c8-4311-08de57946fb2 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2026 19:53:37.3330 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BJxKGuStMXGQ0ZALuFnw+DxCULES+LiWzDA9Lzsd+dzgrGU2ZygbF9N8MoocnRs21oRNEu24/WjkbmAyiPvXBQsi/hjsjMjbjCaJuqUbnoI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7414 DQoNCk9uIDE2LzAxLzIwMjYgMjM6MjEsIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4gT24g RnJpLCAxNiBKYW4gMjAyNiwgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+PiBIaSBTdGVmYW5v LA0KPj4gUGxlYXNlIHNlZSBiZWxvdy4NCj4+DQo+PiBPbiAxNS8wMS8yMDI2IDAzOjE0LCBTdGVm YW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+Pj4gSGkgT2xla3NpaSwNCj4+Pg0KPj4+IEkgYW0gZmlu ZSB3aXRoIHRoZSBnb2FscyBhbmQgdGhlIHN0cmF0ZWd5IHRvIGFjaGlldmUgdGhlIGdvYWxzIGJ1 dCB0aGVyZQ0KPj4+IGFyZSBzb21lIGZpbmVyIGRldGFpbHMgdGhhdCBkb24ndCBtYWtlIHNlbnNl IHRvIG1lLiBJIGFwb2xvZ2l6ZSBpZiBJIGFtDQo+Pj4gYXNraW5nIHRoZSBzYW1lIHF1ZXN0aW9u cyB5b3UgaGF2ZSBhbHJlYWR5IGFuc3dlcmVkIGFzIHNvbWUgdGltZSBhcw0KPj4+IHBhc3NlZCBm cm9tIHRoZSBsYXN0IGludGVyYWN0aW9uLg0KPj4+DQo+Pj4NCj4+PiBPbiBXZWQsIDE0IEphbiAy MDI2LCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToNCj4+Pj4gVGhpcyBwYXRjaCBpbnRyb2R1Y2Vz IFNDSSBkcml2ZXIgdG8gc3VwcG9ydCBmb3IgQVJNIEVMMyBUcnVzdGVkIEZpcm13YXJlLUENCj4+ Pj4gKFRGLUEpIHdoaWNoIHByb3ZpZGVzIFNDTUkgaW50ZXJmYWNlIHdpdGggbXVsdGktYWdlbnQg c3VwcG9ydCwgYXMgc2hvd24NCj4+Pj4gYmVsb3cuDQo+Pj4+DQo+Pj4+ICAgICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+Pj4+ICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4+ICAgICB8IEVMMyBURi1BIFNDTUkg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4+ICAgICArLS0tLS0tLSstLSstLS0tLS0t Ky0tKy0tLS0tLS0rLS0rLS0tLS0tLSsrDQo+Pj4+ICAgICB8c2htZW0xIHwgIHxzaG1lbTAgfCAg fHNobWVtMiB8ICB8c2htZW1YIHwNCj4+Pj4gICAgICstLS0tLSstKyAgKy0tLSstLS0rICArLS0r LS0tLSsgICstLS0rLS0tKw0KPj4+PiBzbWMtaWQxIHwgICAgICAgIHwgICAgICAgICB8ICAgICAg ICAgICB8DQo+Pj4+IGFnZW50MSAgfCAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgIHwNCj4+ Pj4gICAgICstLS0tLXYtLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLSsNCj4+Pj4g ICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgICB8ICAgIHwNCj4+Pj4gICAg IHwgICAgICAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgICB8ICAgIHwNCj4+Pj4gICAgICst LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLSsNCj4+Pj4gICAgICAgICAg ICBzbWMtaWQwIHwgIHNtYy1pZDJ8ICAgIHNtYy1pZFh8DQo+Pj4+ICAgICAgICAgICAgYWdlbnQw ICB8ICBhZ2VudDIgfCAgICBhZ2VudFggfA0KPj4+PiAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgIHwgICAgICAgICAgIHwNCj4+Pj4gICAgICAgICAgICAgICArLS0tLXYtLS0rICArLS12LS0t LS0rICArLS12LS0tLS0rDQo+Pj4+ICAgICAgICAgICAgICAgfCAgICAgICAgfCAgfCAgICAgICAg fCAgfCAgICAgICAgfA0KPj4+PiAgICAgICAgICAgICAgIHwgRG9tMCAgIHwgIHwgRG9tMSAgIHwg IHwgRG9tWCAgIHwNCj4+Pj4gICAgICAgICAgICAgICB8ICAgICAgICB8ICB8ICAgICAgICB8ICB8 ICAgICAgICB8DQo+Pj4+ICAgICAgICAgICAgICAgfCAgICAgICAgfCAgfCAgICAgICAgfCAgfCAg ICAgICAgfA0KPj4+PiAgICAgICAgICAgICAgICstLS0tLS0tLSsgICstLS0tLS0tLSsgICstLS0t LS0tLSsNCj4+Pj4NCj4+Pj4gVGhlIEVMMyBTQ01JIG11bHRpLWFnZW50IGZpcm13YXJlIGlzIGV4 cGVjdGVkIHRvIHByb3ZpZGUgU0NNSSBTTUMgc2hhcmVkDQo+Pj4+IG1lbW9yeSB0cmFuc3BvcnQg Zm9yIGV2ZXJ5IEFnZW50IGluIHRoZSBzeXN0ZW0uDQo+Pj4+DQo+Pj4+IFRoZSBTQ01JIEFnZW50 IHRyYW5zcG9ydCBjaGFubmVsIGRlZmluZWQgYnkgcGFpcjoNCj4+Pj4gICAgLSBzbWMtaWQ6IFNN QyBpZCB1c2VkIGZvciBEb29yYmVsbA0KPj4+PiAgICAtIHNobWVtOiBzaGFyZWQgbWVtb3J5IGZv ciBtZXNzYWdlcyB0cmFuc2ZlciwgWGVuIHBhZ2UNCj4+Pj4gICAgYWxpZ25lZC4gU2hhcmVkIG1l bW9ydCBpcyBtYXBwZWQgd2l0aCB0aGUgZm9sbG93aW5nIGZsYWdzOg0KPj4+PiAgICBNVF9ERVZJ Q0VfbkduUkUuDQo+Pj4+DQo+Pj4+IFRoZSBmb2xsd29pbmcgU0NNSSBBZ2VudHMgYXJlIGV4cGVj dGVkIHRvIGJlIGRlZmluZWQgYnkgU0NNSSBGVyB0byBlbmFibGUgU0NNSQ0KPj4+PiBtdWx0aS1h Z2VudCBmdW5jdGlvbmFsaXR5IHVuZGVyIFhlbjoNCj4+Pj4gLSBYZW4gbWFuYWdlbWVudCBhZ2Vu dDogdHJ1c3RlZCBhZ2VudHMgdGhhdCBhY2Nlc3NlcyB0byB0aGUgQmFzZSBQcm90b2NvbA0KPj4+ PiBjb21tYW5kcyB0byBjb25maWd1cmUgYWdlbnQgc3BlY2lmaWMgcGVybWlzc2lvbnMNCj4+Pj4g LSBPU1BNIFZNIGFnZW50czogbm9uLXRydXN0ZWQgYWdlbnQsIG9uZSBmb3IgZWFjaCBHdWVzdCBk b21haW4gd2hpY2ggaXMNCj4+Pj4gICAgIGFsbG93ZWQgZGlyZWN0IEhXIGFjY2Vzcy4gQXQgbGVh c3Qgb25lIE9TUE0gVk0gYWdlbnQgaGFzIHRvIGJlIHByb3ZpZGVkDQo+Pj4+ICAgICBieSBGVyBp ZiBIVyBpcyBoYW5kbGVkIG9ubHkgYnkgRG9tMCBvciBEcml2ZXIgRG9tYWluLg0KPj4+Pg0KPj4+ PiBUaGUgRUwzIFNDTUkgRlcgaXMgZXhwZWN0ZWQgdG8gaW1wbGVtZW50IGZvbGxvd2luZyBCYXNl IHByb3RvY29sIG1lc3NhZ2VzOg0KPj4+PiAtIEJBU0VfRElTQ09WRVJfQUdFTlQgKG9wdGlvbmFs IGlmIGFnZW50X2lkIHdhcyBwcm92aWRlZCkNCj4+Pj4gLSBCQVNFX1JFU0VUX0FHRU5UX0NPTkZJ R1VSQVRJT04gKG9wdGlvbmFsKQ0KPj4+PiAtIEJBU0VfU0VUX0RFVklDRV9QRVJNSVNTSU9OUyAo b3B0aW9uYWwpDQo+Pj4+DQo+Pj4+IFRoZSBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJpdmVy IGltcGxlbWVudHMgZm9sbG93aW5nDQo+Pj4+IGZ1bmN0aW9uYWxpdHk6DQo+Pj4+IC0gVGhlIGRy aXZlciBpcyBpbml0aWFsaXplZCBmcm9tIHRoZSBYZW4gU0NNSSBjb250YWluZXIgYGB4ZW5fc2Nt aV9jb25maWdgYA0KPj4+PiAgICAgKGNvbXBhdGlibGUgYGB4ZW4sc2NpYGApIHBsYWNlZCB1bmRl ciBgYC9jaG9zZW4veGVuYGAuIE9ubHkgdGhlDQo+Pj4+ICAgICBgYGFybSxzY21pLXNtY2BgIG5v ZGUgdGhhdCBpcyBhIGNoaWxkIG9mIHRoaXMgY29udGFpbmVyIHdpbGwgYmluZCB0byBYZW47DQo+ Pj4+ICAgICBvdGhlciBTQ01JIG5vZGVzIChmb3IgZXhhbXBsZSB1bmRlciBgYC9maXJtd2FyZWBg KSBhcmUgaWdub3JlZCB0byBhdm9pZA0KPj4+PiAgICAgc3RlYWxpbmcgdGhlIGhvc3QgT1NQTSBp bnN0YW5jZS4NCj4+Pj4NCj4+Pj4gc2NtaV9zaG1fMTogc3JhbUA0N2ZmMTAwMCB7DQo+Pj4+ICAg ICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4+PiAgICAgICAgICAg ICByZWcgPSA8MHgwIDB4NDdmZjEwMDAgMHgwIDB4MTAwMD47DQo+Pj4+IH07DQo+Pj4+IHNjbWlf eGVuOiBzY21pIHsNCj4+Pj4gICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc21jIjsN Cj4+Pj4gICAgICAgICAgIGFybSxzbWMtaWQgPSA8MHg4MjAwMDAwMz47IDwtLS0gWGVuIG1hbmFn ZW1lbnQgYWdlbnQgc21jLWlkDQo+Pj4+ICAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9IDwgMT47 DQo+Pj4+ICAgICAgICAgICAjc2l6ZS1jZWxscyA9IDwgMD47DQo+Pj4+ICAgICAgICAgICAjYWNj ZXNzLWNvbnRyb2xsZXItY2VsbHMgPSA8IDE+Ow0KPj4+PiAgICAgICAgICAgc2htZW0gPSA8JnNj bWlfc2htXzE+OyA8LS0tIFhlbiBtYW5hZ2VtZW50IGFnZW50IHNobWVtDQo+Pj4+IH07DQo+Pj4+ DQo+Pj4+IC0gVGhlIGRyaXZlciBvYnRhaW5zIFhlbiBzcGVjaWZpYyBTQ01JIEFnZW50J3MgY29u ZmlndXJhdGlvbiBmcm9tIHRoZQ0KPj4+PiAgICAgSG9zdCBEVCwgcHJvYmVzIEFnZW50cyBhbmQg YnVpbGRzIFNDTUkgQWdlbnRzIGxpc3QuIFRoZSBBZ2VudHMNCj4+Pj4gICAgIGNvbmZpZ3VyYXRp b24gaXMgdGFrZW4gZnJvbSAic2NtaS1zZWNvbmRhcnktYWdlbnRzIiBwcm9wZXJ0eSB3aGVyZQ0K Pj4+PiAgICAgZmlyc3QgaXRlbSBpcyAiYXJtLHNtYy1pZCIsIHNlY29uZCAtICJhcm0sc2NtaS1z aG1lbSIgcGhhbmRsZSBhbmQNCj4+Pj4gICAgIHRoaXJkIGlzIG9wdGlvbmFsICJhZ2VudF9pZCI6 DQo+Pj4+DQo+Pj4+IC8gew0KPj4+PiAgICAgY2hvc2VuIHsNCj4+Pj4gICAgICAgeGVuIHsNCj4+ Pj4gICAgICAgICByYW5nZXM7DQo+Pj4+ICAgICAgICAgeGVuX3NjbWlfY29uZmlnIHsNCj4+Pj4g ICAgICAgICAgIGNvbXBhdGlibGUgPSAieGVuLHNjaSI7DQo+Pj4+ICAgICAgICAgICAjYWRkcmVz cy1jZWxscyA9IDwyPjsNCj4+Pj4gICAgICAgICAgICNzaXplLWNlbGxzID0gPDI+Ow0KPj4+PiAg ICAgICAgICAgcmFuZ2VzOw0KPj4+Pg0KPj4+PiAgICAgICAgICAgc2NtaV9zaG1fMDogc3JhbUA0 N2ZmMDAwMCB7DQo+Pj4+ICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc2htZW0i Ow0KPj4+PiAgICAgICAgICAgICByZWcgPSA8MHgwIDB4NDdmZjAwMDAgMHgwIDB4MTAwMD47DQo+ Pj4+ICAgICAgICAgICB9Ow0KPj4+Pg0KPj4+PiAgICAgICAgICAgLyogWGVuIFNDTUkgbWFuYWdl bWVudCBjaGFubmVsICovDQo+Pj4+ICAgICAgICAgICBzY21pX3NobV8xOiBzcmFtQDQ3ZmYxMDAw IHsNCj4+Pj4gICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+Pj4+ ICAgICAgICAgICAgIHJlZyA9IDwweDAgMHg0N2ZmMTAwMCAweDAgMHgxMDAwPjsNCj4+Pj4gICAg ICAgICAgIH07DQo+Pj4+DQo+Pj4+ICAgICAgICAgICBzY21pX3NobV8yOiBzcmFtQDQ3ZmYyMDAw IHsNCj4+Pj4gICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+Pj4+ ICAgICAgICAgICAgIHJlZyA9IDwweDAgMHg0N2ZmMjAwMCAweDAgMHgxMDAwPjsNCj4+Pj4gICAg ICAgICAgIH07DQo+Pj4+DQo+Pj4+ICAgICAgICAgICBzY21pX3NobV8zOiBzcmFtQDQ3ZmYzMDAw IHsNCj4+Pj4gICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+Pj4+ ICAgICAgICAgICAgIHJlZyA9IDwweDAgMHg0N2ZmMzAwMCAweDAgMHgxMDAwPjsNCj4+Pj4gICAg ICAgICAgIH07DQo+Pj4+DQo+Pj4+ICAgICAgICAgICBzY21pLXNlY29uZGFyeS1hZ2VudHMgPSA8 DQo+Pj4+ICAgICAgICAgICAgIDB4ODIwMDAwMDIgJnNjbWlfc2htXzAgMA0KPj4+IDB4ODIwMDAw MDIgaXMgdGhlIHNhbWUgZnVuY19pZCBhcy4uLg0KPj4+DQo+Pj4NCj4+Pj4gICAgICAgICAgICAg MHg4MjAwMDAwNCAmc2NtaV9zaG1fMiAyDQo+Pj4+ICAgICAgICAgICAgIDB4ODIwMDAwMDUgJnNj bWlfc2htXzMgMz47IDwtLS0gZnVuY19pZCwgc2htZW0sIGFnZW50X2lkDQo+Pj4+ICAgICAgICAg ICAjc2NtaS1zZWNvbmRhcnktYWdlbnRzLWNlbGxzID0gPDM+Ow0KPj4+Pg0KPj4+PiAgICAgICAg ICAgc2NtaV94ZW46IHNjbWkgew0KPj4+PiAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxz Y21pLXNtYyI7DQo+Pj4+ICAgICAgICAgICAgIGFybSxzbWMtaWQgPSA8MHg4MjAwMDAwMj47IDwt LS0gWGVuIG1hbmFnZW1lbnQgYWdlbnQgZnVuY19pZA0KPj4+IGFzIHRoZSBvbmUgdXNlZCBmb3Ig WGVuLiBUaGlzIGNhbm5vdCBiZSByaWdodD8NCj4+Pg0KPj4gVGhhdCdzIHJpZ2h0LiBIZXJlIHNo b3VsZCBiZSAweDgyMDAwMDAzLg0KPj4+PiAgICAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9IDwx PjsNCj4+Pj4gICAgICAgICAgICAgI3NpemUtY2VsbHMgPSA8MD47DQo+Pj4+ICAgICAgICAgICAg ICNhY2Nlc3MtY29udHJvbGxlci1jZWxscyA9IDwxPjsNCj4+Pj4gICAgICAgICAgICAgc2htZW0g PSA8JnNjbWlfc2htXzE+OyA8LS0tIFhlbiBtYW5hZ2VtZW50IGFnZW50IHNobWVtDQo+Pj4+ICAg ICAgICAgICB9Ow0KPj4+PiAgICAgICAgIH07DQo+Pj4+ICAgICAgIH07DQo+Pj4+ICAgICB9Ow0K Pj4+PiB9Ow0KPj4+Pg0KPj4+PiAvIHsNCj4+Pj4gICAgICAgLyoNCj4+Pj4gICAgICAgICogSG9z dCBTQ01JIE9TUE0gY2hhbm5lbCAtIHByb3ZpZGVkIHRvIHRoZSBEb20wIGFzIGlzIGlmIFNDTUkN Cj4+Pj4gICAgICAgICogZW5hYmxlZCBmb3IgaXQsIGlnbm9yZWQgYnkgWGVuIG11bHRpLWFnZW50 IG1lZGlhdG9yDQo+Pj4+ICAgICAgICAqLw0KPj4+PiAgICAgICBzY21pX3NobTogc3JhbUA0N2Zm MDAwMCB7DQo+Pj4+ICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7 DQo+Pj4+ICAgICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYwMDAwIDB4MCAweDEwMDA+Ow0K Pj4+PiAgICAgICB9Ow0KPj4+IHRoaXMgaXMgdGhlIHNhbWUgYXMgJnNjbWlfc2htXzAgd2hpY2gg SSBndWVzcyBpcyBpbnRlbmRlZD8NCj4+Pg0KPj4gaXQgaXMuIHRvIG1hdGNoIEhvc3QgRFQuDQo+ Pj4+ICAgICAgIGZpcm13YXJlIHsNCj4+Pj4gICAgICAgICBzY21pOiBzY21pIHsNCj4+Pj4gICAg ICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc21jIjsNCj4+Pj4gICAgICAgICAgIGFybSxz bWMtaWQgPSA8MHg4MjAwMDAwMj47IDwtLS0gSG9zdCBPU1BNIGFnZW50IHNtYy1pZA0KPj4+IGJ1 dCB0aGlzIGFnYWluIGlzIHRoZSBzYW1lIHNtYy1pZCBtZWFudCB0byBiZSB1c2VkIGJ5IFhlbi4N Cj4+Pg0KPj4+IElmIDB4ODIwMDAwMDIgaXMgdGhlIHByaXZpbGVnZWQgaW50ZXJmYWNlLCB0aGVu IGl0IGlzIE9LIGZvciBYZW4gYW5kDQo+Pj4gYWxzbyBiYXJlbWV0YWwgTGludXggdG8gdXNlIGl0 LCBidXQgTGludXggRG9tMCBzaG91bGQgbm90IGJlIHVzaW5nIGl0Pw0KPj4+IE9yIGlzIHRoZSBz bWMtaWQgaW50ZXJjaGFuZ2VhYmxlIGFuZCBub3QgbmVjZXNzYXJpbHkgdGllZCB0byB0aGUNCj4+ PiBhZ2VudC1pZD8NCj4+Pg0KPj4+IEkgdGhpbmsgZWl0aGVyIHdheSB0aGlzIGRldGFpbCBzaG91 bGQgYmUgY2xhcmlmaWVkIGluIHRoZSBkb2NzLiBTcGVha2luZw0KPj4+IG9mIGRvY3MsIHRoZSBu ZXh0IHBhdGNoIGludHJvZHVjaW5nIHRoZSBkb2MgaXMgbm90IHVwLXRvLWRhdGUgd2l0aCB0aGlz DQo+Pj4gcGF0Y2guDQo+Pj4NCj4+IEluIG15IGN1cnJlbnQgY29uZmlndXJhdGlvbiwgSSBoYXZl IHRoZSBmb2xsb3dpbmcgc2V0dXA6DQo+Pg0KPj4gVGhlIFhlbiBwcml2aWxlZ2VkIGludGVyZmFj ZSBvcGVyYXRlcyB0aHJvdWdoIGZ1bmNfaWQgMHg4MjAwMDAwMy4NCj4+IGZ1bmNfaWQgMHg4MjAw MDAwMiBpcyB1c2VkIGZvciBEb21haW4tMCwgaW4gb3JkZXIgdG8ga2VlcCB0aGUgRGV2aWNlDQo+ PiBUcmVlIChEVCkgY29uc2lzdGVudCBiZXR3ZWVuIFhlbiBhbmQgYmFyZS1tZXRhbCBjb25maWd1 cmF0aW9ucy4NCj4+IEkgYW0gdW5zdXJlIGhvdyBiZXN0IHRvIGRvY3VtZW50IHRoaXMsIHNpbmNl IHRoZSBpbXBsZW1lbnRhdGlvbiBkb2VzDQo+PiBub3Qgc3RyaWN0bHkgcmVxdWlyZSB0aGlzIHNw ZWNpZmljIGNvbmZpZ3VyYXRpb24gYW5kIGFsbG93cyBmbGV4aWJpbGl0eQ0KPj4gZm9yIHRoZQ0K Pj4gZW5kIHVzZXIuIE15IGludGVudGlvbiBpcyB0byBwcm92aWRlIGFuIGV4YW1wbGUgY29uZmln dXJhdGlvbiBpbiB0aGUgRFQNCj4+IGV4YW1wbGVzIHRoYXQgaXMgbW9zdCBsaWtlbHkgdG8gYmUg dXNlZCBhcyBhIHJlZmVyZW5jZSBmb3IgcmVhbC13b3JsZA0KPj4gc2V0dXBzLg0KPiBZZXMsIEkg YW0gYWxpZ25lZCB3aXRoIHRoYXQNCj4NCj4NCj4+IEF0IHRoaXMgc3RhZ2UsIEkgYmVsaWV2ZSB0 aGUgbW9zdCBhcHByb3ByaWF0ZSBhcHByb2FjaCBpcyB0byBpbmNsdWRlIGEgbm90ZQ0KPj4gaW4g dGhlIGRvY3VtZW50YXRpb24gc3RhdGluZyB0aGF0IHRoZSBleGFtcGxlcyBpbGx1c3RyYXRlIGEg Y29uZmlndXJhdGlvbg0KPj4gdGhhdCBhbGlnbnMgd2VsbCB3aXRoIHRoZSBYZW4gYXJjaGl0ZWN0 dXJlLCBidXQgb3RoZXIgY29uZmlndXJhdGlvbnMgYXJlDQo+PiBwb3NzaWJsZSBkZXBlbmRpbmcg b24gdXNlciByZXF1aXJlbWVudHMuDQo+IFllcy4gVGhlIGltcG9ydGFudCBkZXRhaWwgaXMgdG8g ZXhwbGFpbiB0aGF0IHRoZSBzYW1lIGNvbmZpZ3VyYXRpb24NCj4gd29ya3MgZm9yIGJvdGggTGlu dXggYmFyZW1ldGFsIGFuZCBMaW51eCBEb20wLiBJbiB0aGUgTGludXggRG9tMCBjYXNlLA0KPiB0 aGUgcHJpdmlsZWdlZCBTQ01JIGNvbm5lY3Rpb24gZGlmZmVycyBmcm9tIHRoZSBvbmUgb2YgTGlu dXggRG9tMCBhbmQgaXQNCj4gaXMgdGhlIG9uZSB1c2VkIGJ5IFhlbi4NCj4NCj4gQmFyZW1ldGFs IExpbnV4OiBmdW5jX2lkIDB4ODIwMDAwMDIsIHNjbWktc2htZW0gMHg0N2ZmMDAwMA0KPiBEb20w IExpbnV4OiBmdW5jX2lkIDB4ODIwMDAwMDIsIHNjbWktc2htZW0gMHg0N2ZmMDAwMA0KPiBYZW46 IGZ1bmNfaWQgMHg4MjAwMDAwMywgc2NtaS1zaG1lbSAweDQ3ZmYxMDAwDQo+DQo+IFRoaXMgd29y a3MgYmVjYXVzZSwgSSBhbSBndWVzc2luZywgdGhlIHByaXZpbGVnZWQgU0NNSSBjb25uZWN0aW9u IGlzIG5vdA0KPiB0aWVkIHRvIGZ1bmNfaWQgMHg4MjAwMDAwMiwgc2NtaS1zaG1lbSAweDQ3ZmYw MDAwLg0KPg0KPiBUaGUgcHJvYmxlbSBvY2N1cnMgd2hlbiB0aGVyZSBjYW4gYmUgb25seSBvbmUg cHJpdmlsZWdlZCBTQ01JIGNvbm5lY3Rpb24NCj4gYW5kIGl0IGlzIHRpZWQgdG8gZnVuY19pZCAw eDgyMDAwMDAyLCBzY21pLXNobWVtIDB4NDdmZjAwMDAgd2hpY2ggaXMgdGhlDQo+IG9uZSBkZXNj cmliZWQgaW4gdGhlIEhvc3QgRFQuIEluIHdoaWNoIGNhc2UsIExpbnV4IERvbTAgZW5kcyB1cCB3 aXRoIHRoZQ0KPiBwcml2aWxlZ2VkIGNvbm5lY3Rpb24sIG5vdCBYZW4uDQo+DQo+IEkgdGhpbmsg d2Ugc2hvdWxkIGV4cGxhaW4gd2h5IHRoaXMgcHJvYmxlbSBkb2VzIG5vdCBvY2N1ci4NCj4NCj4N Cj4+Pj4gICAgICAgICAgICNhZGRyZXNzLWNlbGxzID0gPCAxPjsNCj4+Pj4gICAgICAgICAgICNz aXplLWNlbGxzID0gPCAwPjsNCj4+Pj4gICAgICAgICAgIHNobWVtID0gPCZzY21pX3NobT47IDwt LS0gSG9zdCBPU1BNIGFnZW50IHNobWVtDQo+Pj4+DQo+Pj4+ICAgICAgICAgICBwcm90b2NvbEBY ew0KPj4+PiAgICAgICAgICAgfTsNCj4+Pj4gICAgICAgICB9Ow0KPj4+PiAgICAgIH07DQo+Pj4+ IH07DQo+Pj4+DQo+Pj4+IFRoaXMgYXBwcm9hY2ggYWxsb3dzIGRlZmluaW5nIG11bHRpcGxlIFND TUkgQWdlbnRzIGJ5IGFkZGluZw0KPj4+PiBYZW4tc3BlY2lmaWMgcHJvcGVydGllcyB1bmRlciB0 aGUgYGAvY2hvc2VuYGAgbm9kZSB0byB0aGUgSG9zdCBEZXZpY2UNCj4+Pj4gVHJlZSwgbGVhdmlu ZyB0aGUgbWFpbiBwYXJ0IHVuY2hhbmdlZC4gVGhlIEhvc3QgRFQgU0NNSSBjaGFubmVsIHdpbGwN Cj4+Pj4gYmUgcGFzc2VkIHRvIERvbTAuDQo+Pj4+DQo+Pj4+IFRoZSBYZW4gbWFuYWdlbWVudCBh Z2VudCBpcyBkZXNjcmliZWQgYXMgYSBgYHNjbWlfeGVuYGAgbm9kZSB1bmRlciB0aGUNCj4+Pj4g YGB4ZW4sc2NpYGAgY29tYXB0aWJsZSBub2RlLCB3aGljaCBpcyB1c2VkIGJ5IFhlbiB0byBjb250 cm9sIG90aGVyDQo+Pj4+IFNDTUkgQWdlbnRzIGluIHRoZSBzeXN0ZW0uDQo+Pj4+DQo+Pj4+IEFs bCBzZWNvbmRhcnkgYWdlbnRzJyBjb25maWd1cmF0aW9ucyBhcmUgcHJvdmlkZWQgaW4gdGhlDQo+ Pj4+IGBgc2NtaS1zZWNvbmRhcnktYWdlbnRzYGAgcHJvcGVydHkgd2l0aCBhbiBvcHRpb25hbCBg YGFnZW50X2lkYGAgZmllbGQuDQo+Pj4+DQo+Pj4+IFRoZSBgYGFnZW50X2lkYGAgZnJvbSB0aGUg YGBzY21pLXNlY29uZGFyeS1hZ2VudHNgYCBwcm9wZXJ0eSBpcyB1c2VkDQo+Pj4+IHRvIGlkZW50 aWZ5IHRoZSBhZ2VudCBpbiB0aGUgc3lzdGVtIGFuZCBjYW4gYmUgb21pdHRlZCBieSBzZXR0aW5n DQo+Pj4+IGBgI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxscyA9IDwyPmBgLCBzbyB0aGUgU2Vj b25kYXJ5IEFnZW50cw0KPj4+PiBjb25maWd1cmF0aW9uIHdpbGwgbG9vayBsaWtlIHRoaXM6DQo+ Pj4+DQo+Pj4+IC8gew0KPj4+PiAgICAgY2hvc2VuIHsNCj4+Pj4gICAgICAgeGVuIHsNCj4+Pj4g ICAgICAgICB4ZW5fc2NtaV9jb25maWcgew0KPj4+PiAgICAgICAgICAgY29tcGF0aWJsZSA9ICJ4 ZW4sc2NpIjsNCj4+Pj4gICAgICAgICAgICNhZGRyZXNzLWNlbGxzID0gPDI+Ow0KPj4+PiAgICAg ICAgICAgI3NpemUtY2VsbHMgPSA8Mj47DQo+Pj4+ICAgICAgICAgICByYW5nZXM7DQo+Pj4+DQo+ Pj4+ICAgICAgICAgICAvKiBTaGFyZWQgbWVtb3J5IG5vZGVzIGFzIGRlZmluZWQgZWFybGllciAq Lw0KPj4+Pg0KPj4+PiAgICAgICAgICAgc2NtaS1zZWNvbmRhcnktYWdlbnRzID0gPA0KPj4+PiAg ICAgICAgICAgICAweDgyMDAwMDAzICZzY21pX3NobV8wDQo+Pj4+ICAgICAgICAgICAgIDB4ODIw MDAwMDQgJnNjbWlfc2htXzINCj4+Pj4gICAgICAgICAgICAgMHg4MjAwMDAwNSAmc2NtaV9zaG1f Mw0KPj4+PiAgICAgICAgICAgICAweDgyMDAwMDA2ICZzY21pX3NobV80PjsNCj4+Pj4gICAgICAg ICAgICNzY21pLXNlY29uZGFyeS1hZ2VudHMtY2VsbHMgPSA8Mj47DQo+Pj4+ICAgICAgICAgfTsN Cj4+Pj4gICAgICAgfTsNCj4+Pj4gICAgIH07DQo+Pj4+IH0NCj4+Pj4NCj4+Pj4gSW4gdGhpcyBj YXNlLCBYZW4gd2lsbCB1c2UgdGhlIGBgU0NNSV9CQVNFX0RJU0NPVkVSX0FHRU5UYGAgY2FsbCB0 bw0KPj4+PiBkaXNjb3ZlciB0aGUgYGBhZ2VudF9pZGBgIGZvciBlYWNoIHNlY29uZGFyeSBhZ2Vu dC4gUHJvdmlkaW5nIHRoZQ0KPj4+PiBgYGFnZW50X2lkYGAgaW4gdGhlIGBgc2NtaS1zZWNvbmRh cnktYWdlbnRzYGAgcHJvcGVydHkgYWxsb3dzIHNraXBwaW5nDQo+Pj4+IHRoZSBkaXNjb3Zlcnkg Y2FsbCwgd2hpY2ggaXMgdXNlZnVsIHdoZW4gdGhlIHNlY29uZGFyeSBhZ2VudCdzIHNoYXJlZA0K Pj4+PiBtZW1vcnkgaXMgbm90IGFjY2Vzc2libGUgYnkgWGVuIG9yIHdoZW4gYm9vdCB0aW1lIGlz IGltcG9ydGFudCBiZWNhdXNlDQo+Pj4+IGl0IGFsbG93cyBza2lwcGluZyB0aGUgYWdlbnQgZGlz Y292ZXJ5IHByb2NlZHVyZS4NCj4+Pj4NCj4+Pj4gICAgIE5vdGUgdGhhdCBYZW4gaXMgdGhlIG9u bHkgb25lIGVudHJ5IGluIHRoZSBzeXN0ZW0gd2hpY2ggbmVlZCB0byBrbm93DQo+Pj4+ICAgICBh Ym91dCBTQ01JIG11bHRpLWFnZW50IHN1cHBvcnQuDQo+Pj4+DQo+Pj4+IC0gSXQgaW1wbGVtZW50 cyB0aGUgU0NJIHN1YnN5c3RlbSBpbnRlcmZhY2UgcmVxdWlyZWQgZm9yIGNvbmZpZ3VyaW5nIGFu ZA0KPj4+PiBlbmFibGluZyBTQ01JIGZ1bmN0aW9uYWxpdHkgZm9yIERvbTAvaHdkb20gYW5kIEd1 ZXN0IGRvbWFpbnMuIFRvIGVuYWJsZQ0KPj4+PiBTQ01JIGZ1bmN0aW9uYWxpdHkgZm9yIGRvbWFp biBpdCBoYXMgdG8gYmUgY29uZmlndXJlZCB3aXRoIHVuaXF1ZSBzdXBwb3J0ZWQNCj4+Pj4gU0NN SSBBZ2VudF9pZCBhbmQgdXNlIGNvcnJlc3BvbmRpbmcgU0NNSSBTTUMgc2hhcmVkIG1lbW9yeSB0 cmFuc3BvcnQNCj4+Pj4gW3NtYy1pZCwgc2htZW1dIGRlZmluZWQgZm9yIHRoaXMgU0NNSSBBZ2Vu dF9pZC4NCj4+Pj4gLSBPbmNlIFhlbiBkb21haW4gaXMgY29uZmlndXJlZCBpdCBjYW4gY29tbXVu aWNhdGUgd2l0aCBFTDMgU0NNSSBGVzoNCj4+Pj4gICAgIC0tIHplcm8tY29weSwgdGhlIGd1ZXN0 IGRvbWFpbiBwdXRzIFNDTUkgbWVzc2FnZSBpbiBzaG1lbTsNCj4+Pj4gICAgIC0tIHRoZSBndWVz dCB0cmlnZ2VycyBTTUMgZXhjZXB0aW9uIHdpdGggc21jLWlkIChkb29yYmVsbCk7DQo+Pj4+ICAg ICAtLSB0aGUgWGVuIGRyaXZlciBjYXRjaGVzIGV4Y2VwdGlvbiwgZG8gY2hlY2tzIGFuZCBzeW5j aHJvbm91c2x5IGZvcndhcmRzDQo+Pj4+ICAgICBpdCB0byBFTDMgRlcuDQo+Pj4+IC0gdGhlIFhl biBkcml2ZXIgc2VuZHMgQkFTRV9SRVNFVF9BR0VOVF9DT05GSUdVUkFUSU9OIG1lc3NhZ2UgdG8g WGVuDQo+Pj4+ICAgICBtYW5hZ2VtZW50IGFnZW50IGNoYW5uZWwgb24gZG9tYWluIGRlc3Ryb3kg ZXZlbnQuIFRoaXMgYWxsb3dzIHRvIHJlc2V0DQo+Pj4+ICAgICByZXNvdXJjZXMgdXNlZCBieSBk b21haW4gYW5kIHNvIGltcGxlbWVudCB1c2UtY2FzZSBsaWtlIGRvbWFpbiByZWJvb3QuDQo+Pj4+ DQo+Pj4+IERvbTAgRW5hYmxlIFNDTUkgU01DOg0KPj4+PiAgICAtIHBhc3MgZG9tMF9zY21pX2Fn ZW50X2lkPTxhZ2VudF9pZD4gaW4gWGVuIGNvbW1hbmQgbGluZS4gaWYgbm90IHByb3ZpZGVkDQo+ Pj4+ICAgICAgU0NNSSB3aWxsIGJlIGRpc2FibGVkIGZvciBEb20wIGFuZCBhbGwgU0NNSSBub2Rl cyByZW1vdmVkIGZyb20gRG9tMCBEVC4NCj4+Pj4gICAgICBUaGUgZHJpdmVyIHVwZGF0ZXMgRG9t MCBEVCBTQ01JIG5vZGUgImFybSxzbWMtaWQiIHZhbHVlIGFuZCBmaXggdXAgc2htZW0NCj4+Pj4g ICAgICBub2RlIGFjY29yZGluZyB0byBhc3NpZ25lZCBhZ2VudF9pZC4NCj4+PiBHaXZlbiB0aGF0 IGV2ZXJ5dGhpbmcgZWxzZSwgdGhlIGVudGlyZSBjb25maWd1cmF0aW9uLCBpcyBiYXNlZCBvbiBk ZXZpY2UNCj4+PiB0cmVlLCBJIHRoaW5rIGl0IG1ha2VzIHNlbnNlIHRvIGFsc28gY29uZmlndXJl IHRoaXMgdmlhIGRldmljZSB0cmVlDQo+Pj4gaW5zdGVhZCBvZiBhIGNvbW1hbmQgbGluZS4NCj4+ Pg0KPj4+IFRoaXMgY291bGQgYmUgYW5vdGhlciBwYXJhbWV0ZXIgdW5kZXIgeGVuX3NjbWlfY29u ZmlnLiBXaGF0IGRvIHlvdQ0KPj4+IHRoaW5rPw0KPj4+DQo+PiBUaGUgYGBkb20wX3NjbWlfYWdl bnRfaWRgYCBwYXJhbWV0ZXIgd2FzIGludHJvZHVjZWQgdG8ga2VlcCB0aGUgRG9tMA0KPj4gY29u ZmlndXJhdGlvbiBzZXBhcmF0ZSBmcm9tIHRoZSB4ZW5fc2NtaV9jb25maWcgbm9kZSwgd2hpY2gg aXMgaW50ZW5kZWQNCj4+IHNwZWNpZmljYWxseSBmb3IgWGVuIFNDTUkgY29uZmlndXJhdGlvbi4g SW4gbXkgb3BpbmlvbiwgYWRkaW5nIERvbTAtc3BlY2lmaWMNCj4+IGNvbmZpZ3VyYXRpb24gdG8g eGVuX3NjbWlfY29uZmlnIHdvdWxkIG1peCB0aGUgcHVycG9zZXMgb2YgdGhlIG5vZGUgYW5kDQo+ PiByZWR1Y2UgY2xhcml0eS4NCj4+DQo+PiBBZGRpdGlvbmFsbHksIHRoZSBgYGRvbTBfc2NtaV9h Z2VudF9pZGBgIHBhcmFtZXRlciBpcyBzaW1pbGFyIHRvIHRoZQ0KPj4gYGBhZ2VudF9pZGBgIHBh cmFtZXRlciB1c2VkIGZvciBhcm1fc2NpIGluIHhsLmNmZy4gVGhpcyBhcHByb2FjaCBlbnN1cmVz DQo+PiB0aGF0DQo+PiB0aGUgRG9tMCBjb25maWd1cmF0aW9uIGlzIGFzIGNvbnNpc3RlbnQgYXMg cG9zc2libGUgd2l0aCB0aGUNCj4+IGNvbmZpZ3VyYXRpb24gZm9yDQo+PiBvdGhlciBkb21haW5z Lg0KPj4NCj4+IE92ZXJhbGwsIEkgYmVsaWV2ZSB0aGlzIG1ha2VzIHRoZSBjb25maWd1cmF0aW9u IGxlc3MgY29uZnVzaW5nLCBhcyBpdCBhbGxvd3MNCj4+IHVzIHRvIHNldCBzaW1pbGFyIHBhcmFt ZXRlcnMgZm9yIGJvdGggRG9tMCBhbmQgb3RoZXIgZG9tYWlucyBpbiBhIGNsZWFyDQo+PiBhbmQg b3JnYW5pemVkIG1hbm5lci4NCj4gV2UgYXJlIGhlYWRpbmcgaW4gYSBkaXJlY3Rpb24gd2hlcmUg RG9tMCBoYXMgaXRzIG93biBzZXBhcmF0ZSBkb21haW4NCj4gbm9kZSBzaW1pbGFybHkgdG8gb3Ro ZXIgRG9tMGxlc3MgZG9tYWlucy4gTWFueSBvZiB0aGVzZSBjaGFuZ2VzIGhhdmUNCj4gYWxyZWFk eSBiZWVuIGNvbW1pdHRlZCBhcyBwYXJ0IG9mIEhhcmR3YXJlIERvbWFpbiAvIENvbnRyb2wgRG9t YWluDQo+IHNlcGFyYXRpb24gd29yayBieSBKYXNvbi4NCj4NCj4gSW4gYSB3b3JsZCB3aGVyZSBE b20wLCBsaWtlIG90aGVyIERvbVVzLCBoYXMgaXRzIG93biBjb25maWd1cmF0aW9uIG5vZGUNCj4g YW5kIGFsc28gRG9tMCBjYW4gYmUgc3BsaXQgYmV0d2VlbiBIYXJkd2FyZSBEb21haW4gYW5kIENv bnRyb2wgRG9tYWluLA0KPiBpdCBkb2Vzbid0IG1ha2Ugc2Vuc2UgdG8gdXNlIERvbTAgY29tbWFu ZCBsaW5lIG9wdGlvbnMgYW55bW9yZS4gSXQgaXMNCj4gYWxyZWFkeSBwb3NzaWJsZSB0byBhc3Np Z24gRG9tMCAicG93ZXJzIiB0byBhIGRvbTBsZXNzIGRvbWFpbiBmb3INCj4gZXhhbXBsZS4NCj4N Cj4gSSBjYW4gc2VlIGl0IGlzIHdvcnRoIGRpc2N1c3NpbmcgY29tbWFuZCBsaW5lIG9wdGlvbnMg Zm9yIGRvbTAgaW4NCj4gc2l0dWF0aW9ucyB3aGVyZSBEZXZpY2UgVHJlZSBtaWdodCBub3QgYmUg cHJlc2VudCAoZGF0YWNlbnRlcg0KPiBjb25maWd1cmF0aW9uIG9uIEFDUEkgc3lzdGVtKSBidXQg aW4gdGhpcyBjYXNlIHdoZXJlIERldmljZSBUcmVlIGNoYW5nZXMNCj4gYXJlIHJlcXVpcmVkLCBJ IHRoaW5rIGl0IGRvZXNuJ3QgbWFrZSBzZW5zZSB0byBhZGQgRG9tMCBjb21tYW5kIGxpbmUNCj4g b3B0aW9ucyBhcyB0aGV5IGFyZSBsZXNzIGZsZXhpYmxlIGFuZCBhIGR1cGxpY2F0ZSBvZiBvdGhl ciBvcHRpb25zIHdlDQo+IG11c3QgaGF2ZSBhbnl3YXkuDQpUaGF0IG1ha2VzIHNlbnNlIHRvIG1l LiBTaW5jZSB3ZSBhcmUgbW92aW5nIHRvIHRoZSBEb20wIERldmljZSBUcmVlDQpjb25maWd1cmF0 aW9uLA0KSSBjYW4gbW92ZSBgYGRvbTBfc2NtaV9hZ2VudF9pZGBgIGluc2lkZSB0aGUgYGB4ZW4s c2NpYGAgbm9kZSBhbmQgcmVuYW1lDQppdCBhcyB0aGUNCmBgYWdlbnRfaWRgYCBwcm9wZXJ0eS4N Cg0KV291bGQgeW91IHJlY29tbWVuZCBkcm9wcGluZyB0aGUgYGBkb20wX3NjbWlfYWdlbnRfaWRg YCBjb21tYW5kIGxpbmUNCnBhcmFtZXRlcg0KZW50aXJlbHksIG9yIHNob3VsZCBJIGtlZXAgaXQg YXMgYSBiYWNrdXAgb3B0aW9uPw0KPiBIb3dldmVyLCB3ZSBjYW4gZXhwcmVzcyB0aGVtIGluIGJl dHRlciB3YXlzLiBGb3IgaW5zdGFuY2UsIHdlIGNvdWxkDQo+IHJldXNlIHlvdXIgZXhpdGluZyB3 b3JrIHRvIGVuYWJsZSBkb20wbGVzcyBEb21Vcy4NCj4NCj4gU2VlIGh0dHBzOi8vd3d3LnlvdXR1 YmUuY29tL3dhdGNoP3Y9SjZxNjdqa0c1RFENCj4NCj4NCj4+Pj4gR3Vlc3QgZG9tYWlucyBlbmFi bGUgU0NNSSBTTUM6DQo+Pj4+ICAgIC0geGwuY2ZnOiBhZGQgY29uZmlndXJhdGlvbiBvcHRpb24g YXMgYmVsb3cNCj4+Pj4NCj4+Pj4gICAgICBhcm1fc2NpID0gInR5cGU9c2NtaV9zbWNfbXVsdGlh Z2VudCw9MiINCj4+Pj4NCj4+Pj4gICAgLSB4bC5jZmc6IGVuYWJsZSBhY2Nlc3MgdG8gdGhlICJh cm0sc2NtaS1zaG1lbSIgd2hpY2ggc2hvdWxkDQo+Pj4+ICAgIGNvcnJlc3BvbmQgYXNzaWduZWQg YWdlbnRfaWQgZm9yIHRoZSBkb21haW4sIGZvciBleGFtcGxlOg0KPj4+Pg0KPj4+PiBpb21lbSA9 IFsNCj4+Pj4gICAgICAgIjQ3ZmYyLDFAMjIwMDEiLA0KPj4+PiBdDQo+Pj4+DQo+Pj4+ICAgIC0g RFQ6IGFkZCBTQ01JIG5vZGVzIHRvIHRoZSBEcml2ZXIgZG9tYWluIHBhcnRpYWwgZGV2aWNlIHRy ZWUgYXMgaW4gdGhlDQo+Pj4+ICAgIGJlbG93IGV4YW1wbGUuIFRoZSAiYXJtLHNtYy1pZCIgc2hv dWxkIGNvcnJlc3BvbmQgYXNzaWduZWQgYWdlbnRfaWQNCj4+Pj4gICAgZm9yIHRoZSBkb21haW46 DQo+Pj4+DQo+Pj4+IHBhc3N0aHJvdWdoIHsNCj4+Pj4gICAgICBzY21pX3NobV8wOiBzcmFtQDIy MDAxMDAwIHsNCj4+Pj4gICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+ Pj4+ICAgICAgICAgIHJlZyA9IDwweDAgMHgyMjAwMTAwMCAweDAgMHgxMDAwPjsNCj4+Pj4gICAg ICB9Ow0KPj4+Pg0KPj4+PiAgICAgIGZpcm13YXJlIHsNCj4+Pj4gICAgICAgICAgIGNvbXBhdGli bGUgPSAic2ltcGxlLWJ1cyI7DQo+Pj4+ICAgICAgICAgICAgICAgc2NtaTogc2NtaSB7DQo+Pj4+ ICAgICAgICAgICAgICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc21jIjsNCj4+Pj4gICAg ICAgICAgICAgICAgICAgYXJtLHNtYy1pZCA9IDwweDgyMDAwMDA0PjsNCj4+Pj4gICAgICAgICAg ICAgICAgICAgc2htZW0gPSA8JnNjbWlfc2htXzA+Ow0KPj4+PiAgICAgICAgICAgICAgICAgICAu Li4NCj4+Pj4gICAgICAgICAgICAgICB9DQo+Pj4+ICAgICAgIH0NCj4+Pj4gfQ0KPj4+Pg0KPj4+ PiBTQ01JICI0LjIuMS4xIERldmljZSBzcGVjaWZpYyBhY2Nlc3MgY29udHJvbCINCj4+Pj4NCj4+ Pj4gVGhlIFhFTiBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJpdmVyIHBlcmZvcm1zICJhY2Nl c3MtY29udHJvbGxlciINCj4+Pj4gcHJvdmlkZXIgZnVuY3Rpb24gaW4gY2FzZSBFTDMgU0NNSSBG VyBpbXBsZW1lbnRzIFNDTUkgIjQuMi4xLjEgRGV2aWNlDQo+Pj4+IHNwZWNpZmljIGFjY2VzcyBj b250cm9sIiBhbmQgcHJvdmlkZXMgdGhlIEJBU0VfU0VUX0RFVklDRV9QRVJNSVNTSU9OUw0KPj4+ PiBjb21tYW5kIHRvIGNvbmZpZ3VyZSB0aGUgZGV2aWNlcyB0aGF0IGFuIGFnZW50cyBoYXZlIGFj Y2VzcyB0by4NCj4+Pj4gVGhlIERUIFNDTUkgbm9kZSBzaG91bGQgIiNhY2Nlc3MtY29udHJvbGxl ci1jZWxscz08MT4iIHByb3BlcnR5IGFuZCBEVA0KPj4+PiBkZXZpY2VzIHNob3VsZCBiZSBib3Vu ZCB0byB0aGUgWGVuIFNDTUkuDQo+Pj4+DQo+Pj4+ICZpMmMxIHsNCj4+Pj4gICAgICAgYWNjZXNz LWNvbnRyb2xsZXJzID0gPCZzY21pIDA+Ow0KPj4+PiB9Ow0KPj4+Pg0KPj4+PiBUaGUgRG9tMCBh bmQgZG9tMGxlc3MgZG9tYWlucyBEVCBkZXZpY2VzIHdpbGwgYmUgcHJvY2Vzc2VkDQo+Pj4+IGF1 dG9tYXRpY2FsbHkgdGhyb3VnaCBzY2lfYXNzaWduX2R0X2RldmljZSgpIGNhbGwsIGJ1dCB0byBh c3NpZ24gU0NNSQ0KPj4+PiBkZXZpY2VzIGZyb20gdG9vbHN0YWNrIHRoZSB4bC5jZmc6ImR0ZGV2 IiBwcm9wZXJ0eQ0KPj4+PiBzaGFsbCBiZSB1c2VkOg0KPj4+Pg0KPj4+PiBkdGRldiA9IFsNCj4+ Pj4gICAgICAgIi9zb2MvaTJjQGU2NTA4MDAwIiwNCj4+Pj4gXQ0KPj4+Pg0KPj4+PiB4bC5jZmc6 ZHRkZXYgd2lsbCBjb250YWluIGFsbCBub2RlcyB3aGljaCBhcmUgdW5kZXIgU0NNSQ0KPj4+PiBt YW5hZ2VtZW50IChub3Qgb25seSB0aG9zZSB3aGljaCBhcmUgYmVoaW5kIElPTU1VKS4NCj4+Pj4N Cj4+Pj4gWzFdaHR0cHM6Ly93ZWIuZ2l0Lmtlcm5lbC5vcmcvcHViL3NjbS9saW51eC9rZXJuZWwv Z2l0L3RvcnZhbGRzL2xpbnV4LmdpdC90cmVlL0RvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5k aW5ncy9maXJtd2FyZS9hcm0sc2NtaS55YW1sDQo+Pj4+IFsyXWh0dHBzOi8vd2ViLmdpdC5rZXJu ZWwub3JnL3B1Yi9zY20vbGludXgva2VybmVsL2dpdC90b3J2YWxkcy9saW51eC5naXQvdHJlZS9E b2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvYWNjZXNzLWNvbnRyb2xsZXJzL2FjY2Vz cy1jb250cm9sbGVycy55YW1sDQo+Pj4+DQo+Pj4+IFNpZ25lZC1vZmYtYnk6IEdyeWdvcmlpIFN0 cmFzaGtvPGdyeWdvcmlpX3N0cmFzaGtvQGVwYW0uY29tPg0KPj4+PiBTaWduZWQtb2ZmLWJ5OiBP bGVrc2lpIE1vaXNpZWlldjxvbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbT4NCj4+Pj4gLS0tDQo+ Pj4+DQo+Pj4+IENoYW5nZXMgaW4gdjc6DQo+Pj4+IC0gcmV3b3JrIHNjbWkgbm9kZXMgZm9yIHhl biB0byBtYXRjaCBvbiBjb21wYXRpYmxlIHN0cmluZyBpbnN0ZWFkIG9mDQo+Pj4+IHRoZSBkaXJl Y3QgcGF0aA0KPj4+Pg0KPj4+PiBDaGFuZ2VzIGluIHY2Og0KPj4+PiAtIHVwZGF0ZWQgc2NtaS1z aG1lbSB0byB1c2UgaW8uaCBmcm9tIGdlbmVyaWMgbG9jYXRpb24NCj4+Pj4gLSB1cGRhdGUgc2Nt aV9hZ2VudF9pZCBwYXJhbWV0ZXIgdG8gYmUgcHJvdmlkZWQgaW5zaWRlIGRvbTA9IHBhcmFtZXRl cg0KPj4+PiBsaXN0IGFuZCBoYXZlIHRoZSBmb2xsb3dpbmcgZm9ybWF0ICJkb20wPXNjaS1hZ2Vu dC1pZD0wIg0KPj4+PiBUaGlzIGNoYW5nZSB3YXMgZG9uZSBhcyBhIHJlc3BvbnNlIGZvciBTdGVm YW5vIGNvbW1lbnQgYW5kDQo+Pj4+IHJlcXVpcmVzIGEgbG90IG9mIGNvZGUgY2hhbmdlcywgYnV0 IHByb2R1Y2VzIG11Y2ggY2xlYW5lciBzb2x1dGlvbg0KPj4+PiB0aGF0J3Mgd2h5IEkndmUgYWRk ZWQgaXQgdG8gdGhlIGNvZGUuDQo+Pj4+IC0gZml4IGZpbGUgY29tbWVudHMgYW5kIHJldHVybiBj b2Rlcw0KPj4+PiAtIGZpeCBsZW5naHQgY2hlY2tzIGluIHNobWVtX3tnZXQscHV0fV9tZXNzYWdl IHRvIHVzZSBvZmZzZXRvZg0KPj4+PiAtIHJlbW92ZSBsZW4gbWVtYmVyIGZyb20gc2NtaV9jaGFu bmVsIHN0cnVjdHVyZSBhcyBpdCBpcyBub3QgdXNlZA0KPj4+PiAtIHNldCBzY21pLXNlY29uZGFy eS1hZ2VudHMgcHJvcGVydHkgdG8gYmUgbWFuZGF0b3J5IHNpbmNlIGlmIG5vDQo+Pj4+IHNlY29u ZGFyeSBhZ2VudHMgd2VyZSBwcm92aWRlZCB0aGVuIHRoZXJlIGlzIG5vIHNlbmNlIHRvIGVuYWJs ZSBzY21pDQo+Pj4+IHdoZW4gbm8gc2Vjb25kYXJ5IGFnZW50cyBhcmUgcG9wdWxhdGVkIHRvIHRo ZSBEb21haW5zDQo+Pj4+IC0gdXBkYXRlIGRvY3VtZW50YXRpb24gaW4gYm9vdGluZy50eHQsIGFk ZGVkIHhlbl9zY21pIG5vZGUgdG8gdGhlDQo+Pj4+IGV4YW1wbGUNCj4+Pj4gLSBhZGp1c3QgZC0+ YXJjaC5zY2lfZW5hYmxlZCB2YWx1ZSBpbiBzY21pX2RvbWFpbl9kZXN0cm95DQo+Pj4+IC0gZml4 IGxvY2sgbWFuYWdlbWVudCBpbiBzbWNfY3JlYXRlX2NoYW5uZWwgY2FsbA0KPj4+PiAtIGF2b2lk IGV4dHJhIG1hcF9jaGFubmVsX21lbW9yeSBjb21tYW5kIGZvciBYZW4gbWFuYWdlbWVudCBjaGFu bmVsDQo+Pj4+IGJlY2F1c2UgY29sbGVjdF9hZ2VudF9pZCBjYWxsIHVubWFwcyBtZW1vcnkgaWYg RE9NSURfWEVOIGlzIG5vdA0KPj4+PiBzZXQuIFNvIGZvciBYZW4gbWFuYWdlbWVudCBjaGFubmVs IHdlIGNhbiBpbml0IGRvbWFpbl9pZCBhZCBET01JRF9YRU4NCj4+Pj4gYmVmb3JlIGNhbGxpbmcg Y29sbGVjdF9hZ2VudF9pZCBzbyBtZW1vcnkgc2hvdWxkbid0IGJlIHVubWFwcGVkLg0KPj4+Pg0K Pj4+PiBDaGFuZ2VzIGluIHY1Og0KPj4+PiAtIGZpeCBkZXZpY2UtdHJlZSBleGFtcGxlIGZvcm1h dCBpbiBib290aW5nLnR4dCwgYWRkZWQgIjsiIGFmdGVyICJ9Ii4NCj4+Pj4gLSB1cGRhdGUgZGVm aW5lIGluIHNjbWktcHJvdG8uaA0KPj4+PiAtIHVwZGF0ZSBkZWZpbmUgaW4gc2NtaS1zaG1lbS5o IGZpbGUNCj4+Pj4gLSBzY21pX2Fzc2lnbl9kZXZpY2UgLSBkbyBub3QgaWdub3JlIC1FT1BOT1RT VVBQIHJldHVybg0KPj4+PiBjb2RlIG9mIHRoZSBkb19zbWNfeGZlcg0KPj4+PiAtIHJlbW92ZSBv dmVyd3JpdGluZyBhZ2VudF9jaGFubmVsLT5hZ2VudF9pZCBhZnRlcg0KPj4+PiBTQ01JX0JBU0Vf RElTQ09WRVJfQUdFTlQgY2FsbA0KPj4+PiAtIGFkZCBtdWx0aS1hZ2VudCBmaWxlcyB0byB0aGUg TUFJTlRBSU5FUlMNCj4+Pj4gLSBhZGQgU0NNSSBtdWx0aS1hZ2VudCBkZXNjcmlwdGlvbiB0byB0 aGUgU1VQUE9SVC5tZA0KPj4+PiAtIGhhbmRsZSBBUk1fU01DQ0NfSU5WQUxJRF9QQVJBTUVURVIg cmV0dXJuIGNvZGUgYW5kIHJldHVybiAtRUlOVkFMDQo+Pj4+IGZvciBzbWMgY2FsbA0KPj4+PiAt IHVwZGF0ZWQgY29sbGVjdF9hZ2VudHMgZnVuY3Rpb24uIFNldCBhZ2VudF9pZCBwYXJhbWV0ZXIg YXMgb3B0aW9uYWwNCj4+Pj4gaW4gc2NtaS1zZWNvbmRhcnktYWdlbnRzIGRldmljZS10cmVlIHBy b3BlcnR5DQo+Pj4+IC0gaW50cm9kdWNlICIjc2NtaS1zZWNvbmRhcnktYWdlbnRzLWNlbGxzIiBw YXJhbWV0ZXIgdG8gc2V0IGlmDQo+Pj4+IGFnZW50X2lkIHdhcyBwcm92aWRlZA0KPj4+PiAtIHJl YW5tZSB4ZW4sc2NtaS1zZWNvbmRhcnktYWdlbnRzIHByb3BlcnR5IHRvIHNjbWktc2Vjb25kYXJ5 LWFnZW50cw0KPj4+PiAtIG1vdmUgbWVtY3B1X3RvaW8vZnJvbWlvIGZvciB0aGUgZ2VuZXJpYyBw bGFjZQ0KPj4+PiAtIHVwZGF0ZSBYZW4gdG8gZ2V0IG1hbmFnZW1lbnQgY2hhbm5lbCBmcm9tIC9j aG9zZW4veGVuLGNvbmZpZyBub2RlDQo+Pj4+IC0gZ2V0IGh5cGVydmlzb3IgY2hhbm5uZWwgZnJv bSBub2RlIGluc3RlYWQgb2YgdXNpbmcgaGFyZGNvZGVkDQo+Pj4+IC0gdXBkYXRlIGhhbmRsaW5n IHNjbWkgYW5kIHNobWVtIG5vZGVzIGZvciB0aGUgZG9tYWluDQo+Pj4+IC0gU2V0IG11bHRpLWFn ZW50IGRyaXZlciB0byBzdXBwb3J0IG9ubHkgQXJtNjQNCj4+Pj4NCj4+Pj4gQ2hhbmdlcyBpbiB2 NDoNCj4+Pj4gLSB0b29sc3RhY2sgY29tbWVudHMgZnJvbSBBbnRob255IFBFUkFSRA0KPj4+PiAt IGFkZGVkIGRvbTBsZXNzIHN1cHBvcnQNCj4+Pj4gLSBhZGRlZCBkb2MgZm9yICJ4ZW4sc2NtaS1z ZWNvbmRhcnktYWdlbnRzIg0KPj4+Pg0KPj4+PiAgICBNQUlOVEFJTkVSUyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICA0ICsNCj4+Pj4gICAgU1VQUE9SVC5tZCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAxMSArDQo+Pj4+ICAgIGRvY3MvbWFuL3hsLmNmZy41 LnBvZC5pbiAgICAgICAgICAgICAgICAgICAgfCAgMTMgKw0KPj4+PiAgICBkb2NzL21pc2MvYXJt L2RldmljZS10cmVlL2Jvb3RpbmcudHh0ICAgICAgIHwgMTAzICsrKw0KPj4+PiAgICBkb2NzL21p c2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MgICAgICAgICAgIHwgIDE5ICstDQo+Pj4+ICAgIHRv b2xzL2xpYnMvbGlnaHQvbGlieGxfYXJtLmMgICAgICAgICAgICAgICAgfCAgIDQgKw0KPj4+PiAg ICB0b29scy9saWJzL2xpZ2h0L2xpYnhsX3R5cGVzLmlkbCAgICAgICAgICAgIHwgICA0ICstDQo+ Pj4+ICAgIHRvb2xzL3hsL3hsX3BhcnNlLmMgICAgICAgICAgICAgICAgICAgICAgICAgfCAgMTIg Kw0KPj4+PiAgICB4ZW4vYXJjaC9hcm0vZG9tMGxlc3MtYnVpbGQuYyAgICAgICAgICAgICAgIHwg IDExICsNCj4+Pj4gICAgeGVuL2FyY2gvYXJtL2RvbWFpbl9idWlsZC5jICAgICAgICAgICAgICAg ICB8ICAyNiArLQ0KPj4+PiAgICB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvS2NvbmZpZyAgICAgICAg ICAgICAgIHwgIDEyICsNCj4+Pj4gICAgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL01ha2VmaWxlICAg ICAgICAgICAgICB8ICAgMSArDQo+Pj4+ICAgIHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXBy b3RvLmggICAgICAgICAgfCAxNjQgKysrKw0KPj4+PiAgICB4ZW4vYXJjaC9hcm0vZmlybXdhcmUv c2NtaS1zaG1lbS5jICAgICAgICAgIHwgMTE1ICsrKw0KPj4+PiAgICB4ZW4vYXJjaC9hcm0vZmly bXdhcmUvc2NtaS1zaG1lbS5oICAgICAgICAgIHwgIDQ1ICsrDQo+Pj4+ICAgIHhlbi9hcmNoL2Fy bS9maXJtd2FyZS9zY21pLXNtYy1tdWx0aWFnZW50LmMgfCA4MTUgKysrKysrKysrKysrKysrKysr KysNCj4+Pj4gICAgeGVuL2luY2x1ZGUvcHVibGljL2FyY2gtYXJtLmggICAgICAgICAgICAgICB8 ICAgMyArDQo+Pj4+ICAgIDE3IGZpbGVzIGNoYW5nZWQsIDEzNTkgaW5zZXJ0aW9ucygrKSwgMyBk ZWxldGlvbnMoLSkNCj4+Pj4gICAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9hcmNoL2FybS9maXJt d2FyZS9zY21pLXByb3RvLmgNCj4+Pj4gICAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9hcmNoL2Fy bS9maXJtd2FyZS9zY21pLXNobWVtLmMNCj4+Pj4gICAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9h cmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmgNCj4+Pj4gICAgY3JlYXRlIG1vZGUgMTAwNjQ0 IHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNtYy1tdWx0aWFnZW50LmMNCj4+Pj4NCj4+Pj4g ZGlmZiAtLWdpdCBhL01BSU5UQUlORVJTIGIvTUFJTlRBSU5FUlMNCj4+Pj4gaW5kZXggZWNkM2Y0 MGRmOC4uNGFkMWQ4MThhNiAxMDA2NDQNCj4+Pj4gLS0tIGEvTUFJTlRBSU5FUlMNCj4+Pj4gKysr IGIvTUFJTlRBSU5FUlMNCj4+Pj4gQEAgLTUzMiw2ICs1MzIsMTAgQEAgUjogICAgICBPbGVrc2lp IE1vaXNpZWlldjxvbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbT4NCj4+Pj4gICAgUzogU3VwcG9y dGVkDQo+Pj4+ICAgIEY6IHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY2kuYw0KPj4+PiAgICBGOiB4 ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZmlybXdhcmUvc2NpLmgNCj4+Pj4gK0Y6ICB4ZW4vYXJj aC9hcm0vZmlybXdhcmUvc2NtaS1zbWMtbXVsdGlhZ2VudC5jDQo+Pj4+ICtGOiAgeGVuL2FyY2gv YXJtL2Zpcm13YXJlL3NjbWktc2htZW0uYw0KPj4+PiArRjogIHhlbi9hcmNoL2FybS9maXJtd2Fy ZS9zY21pLXNobWVtLmgNCj4+Pj4gK0Y6ICB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1wcm90 by5oDQo+Pj4+DQo+Pj4+ICAgIFNFQUJJT1MgVVBTVFJFQU0NCj4+Pj4gICAgTTogV2VpIExpdTx3 bEB4ZW4ub3JnPg0KPj4+PiBkaWZmIC0tZ2l0IGEvU1VQUE9SVC5tZCBiL1NVUFBPUlQubWQNCj4+ Pj4gaW5kZXggNDkxZjllY2QxYi4uN2M4OTUxZDY3YiAxMDA2NDQNCj4+Pj4gLS0tIGEvU1VQUE9S VC5tZA0KPj4+PiArKysgYi9TVVBQT1JULm1kDQo+Pj4+IEBAIC05NTYsNiArOTU2LDE3IEBAIGJ5 IGh3ZG9tLiBTb21lIHBsYXRmb3JtcyB1c2UgU0NNSSBmb3IgYWNjZXNzIHRvIHN5c3RlbS1sZXZl bCByZXNvdXJjZXMuDQo+Pj4+DQo+Pj4+ICAgICAgICBTdGF0dXM6IFN1cHBvcnRlZA0KPj4+Pg0K Pj4+PiArIyMjIEFybTogU0NNSSBTTUMgbXVsdGktYWdlbnQgc3VwcG9ydA0KPj4+PiArDQo+Pj4+ ICtFbmFibGUgc3VwcG9ydCBmb3IgdGhlIG11bHRpLWFnZW50IGNvbmZpZ3VyYXRpb24gb2YgdGhl IEVMMyBGaXJtd2FyZSwgd2hpY2gNCj4+Pj4gK2FsbG93cyBYZW4gdG8gcHJvdmlkZSBhbiBTQ01J IGludGVyZmFjZSB0byB0aGUgRG9tYWlucy4NCj4+Pj4gK1hlbiBtYW5hZ2VzIGFjY2VzcyBwZXJt aXNzaW9ucyB0byB0aGUgSFcgcmVzb3VyY2VzIGFuZCBwcm92aWRlcyBhbiBTQ01JIGludGVyZmFj ZQ0KPj4+PiArdG8gdGhlIERvbWFpbnMuIEVhY2ggRG9tYWluIGlzIHJlcHJlc2VudGVkIGFzIGEg c2VwYXJhdGUgQWdlbnQsIHdoaWNoIGNhbg0KPj4+PiArY29tbXVuaWNhdGUgd2l0aCBFTDMgRmly bXdhcmUgdXNpbmcgYSBkZWRpY2F0ZWQgc2hhcmVkIG1lbW9yeSByZWdpb24sIGFuZA0KPj4+PiAr bm90aWZpY2F0aW9ucyBhcmUgcGFzc2VkIHRocm91Z2ggYnkgWGVuLg0KPj4+PiArDQo+Pj4+ICsg ICAgU3RhdHVzLCBBUk02NDogVGVjaCBQcmV2aWV3DQo+Pj4+ICsNCj4+Pj4gICAgIyMjIEFSTTog R3Vlc3QgUFNDSSBzdXBwb3J0DQo+Pj4+DQo+Pj4+ICAgIEVtdWxhdGVkIFBTQ0kgaW50ZXJmYWNl IGV4cG9zZWQgdG8gZ3Vlc3RzLiBXZSBzdXBwb3J0IGFsbCBtYW5kYXRvcnkNCj4+Pj4gZGlmZiAt LWdpdCBhL2RvY3MvbWFuL3hsLmNmZy41LnBvZC5pbiBiL2RvY3MvbWFuL3hsLmNmZy41LnBvZC5p bg0KPj4+PiBpbmRleCBhZDE1NTNjNWU5Li40ZmMzZTEyOTM5IDEwMDY0NA0KPj4+PiAtLS0gYS9k b2NzL21hbi94bC5jZmcuNS5wb2QuaW4NCj4+Pj4gKysrIGIvZG9jcy9tYW4veGwuY2ZnLjUucG9k LmluDQo+Pj4+IEBAIC0zMTU2LDggKzMxNTYsMjEgQEAgc2luZ2xlIFNDTUkgT1NQTSBhZ2VudCBz dXBwb3J0Lg0KPj4+PiAgICBTaG91bGQgYmUgdXNlZCB0b2dldGhlciB3aXRoIEI8c2NtaS1zbWMt cGFzc3Rocm91Z2g+IFhlbiBjb21tYW5kIGxpbmUNCj4+Pj4gICAgb3B0aW9uLg0KPj4+Pg0KPj4+ PiArPWl0ZW0gQjxzY21pX3NtY19tdWx0aWFnZW50Pg0KPj4+PiArDQo+Pj4+ICtFbmFibGVzIEFS TSBTQ01JIFNNQyBtdWx0aS1hZ2VudCBzdXBwb3J0IGZvciB0aGUgZ3Vlc3QgYnkgZW5hYmxpbmcg U0NNSSBvdmVyDQo+Pj4+ICtTTUMgY2FsbHMgZm9yd2FyZGluZyBmcm9tIGRvbWFpbiB0byB0aGUg RUwzIGZpcm13YXJlIChsaWtlIFRydXN0ZWQgRmlybXdhcmUtQSkNCj4+Pj4gK3dpdGggYSBtdWx0 aSBTQ01JIE9TUE0gYWdlbnQgc3VwcG9ydC4gVGhlIFNDTUkgQjxhZ2VudF9pZD4gc2hvdWxkIGJl DQo+Pj4+ICtzcGVjaWZpZWQgZm9yIHRoZSBndWVzdC4NCj4+Pj4gKw0KPj4+PiAgICA9YmFjaw0K Pj4+Pg0KPj4+PiArPWl0ZW0gQjxhZ2VudF9pZD1OVU1CRVI+DQo+Pj4+ICsNCj4+Pj4gK1NwZWNp ZmllcyBhIG5vbi16ZXJvIEFSTSBTQ0kgYWdlbnQgaWQgZm9yIHRoZSBndWVzdC4gVGhpcyBvcHRp b24gaXMgbWFuZGF0b3J5DQo+Pj4+ICtpZiB0aGUgU0NNSSBTTUMgc3VwcG9ydCBpcyBlbmFibGVk IGZvciB0aGUgZ3Vlc3QuIFRoZSBhZ2VudCBpZHMgb2YgZG9tYWlucw0KPj4+PiArZXhpc3Rpbmcg b24gYSBzaW5nbGUgaG9zdCBtdXN0IGJlIHVuaXF1ZSBhbmQgaW4gdGhlIHJhbmdlIFsxLi4yNTVd Lg0KPj4+PiArDQo+Pj4+ICAgID1iYWNrDQo+Pj4+DQo+Pj4+ICAgID1iYWNrDQo+Pj4+IGRpZmYg LS1naXQgYS9kb2NzL21pc2MvYXJtL2RldmljZS10cmVlL2Jvb3RpbmcudHh0IGIvZG9jcy9taXNj L2FybS9kZXZpY2UtdHJlZS9ib290aW5nLnR4dA0KPj4+PiBpbmRleCA5NzdiNDI4NjA4Li42ZmQ3 ZTRhMTZiIDEwMDY0NA0KPj4+PiAtLS0gYS9kb2NzL21pc2MvYXJtL2RldmljZS10cmVlL2Jvb3Rp bmcudHh0DQo+Pj4+ICsrKyBiL2RvY3MvbWlzYy9hcm0vZGV2aWNlLXRyZWUvYm9vdGluZy50eHQN Cj4+Pj4gQEAgLTMyMiw2ICszMjIsMjAgQEAgd2l0aCB0aGUgZm9sbG93aW5nIHByb3BlcnRpZXM6 DQo+Pj4+ICAgICAgICBTaG91bGQgYmUgdXNlZCB0b2dldGhlciB3aXRoIHNjbWktc21jLXBhc3N0 aHJvdWdoIFhlbiBjb21tYW5kIGxpbmUNCj4+Pj4gICAgICAgIG9wdGlvbi4NCj4+Pj4NCj4+Pj4g KyAgICAtICJzY21pX3NtY19tdWx0aWFnZW50Ig0KPj4+PiArDQo+Pj4+ICsgICAgRW5hYmxlcyBB Uk0gU0NNSSBTTUMgbXVsdGktYWdlbnQgc3VwcG9ydCBmb3IgdGhlIGd1ZXN0IGJ5IGVuYWJsaW5n IFNDTUkgb3Zlcg0KPj4+PiArICAgIFNNQyBjYWxscyBmb3J3YXJkaW5nIGZyb20gZG9tYWluIHRv IHRoZSBFTDMgZmlybXdhcmUgKGxpa2UgQVJNDQo+Pj4+ICsgICAgVHJ1c3RlZCBGaXJtd2FyZS1B KSB3aXRoIGEgbXVsdGkgU0NNSSBPU1BNIGFnZW50IHN1cHBvcnQuDQo+Pj4+ICsgICAgVGhlIFND TUkgYWdlbnRfaWQgc2hvdWxkIGJlIHNwZWNpZmllZCBmb3IgdGhlIGd1ZXN0IHdpdGggInhlbixz Y2ktYWdlbnQtaWQiDQo+Pj4+ICsgICAgcHJvcGVydHkuDQo+Pj4+ICsNCj4+Pj4gKy0gInhlbixz Y2ktYWdlbnQtaWQiDQo+Pj4+ICsNCj4+Pj4gKyAgICBTcGVjaWZpZXMgQVJNIFNDTUkgYWdlbnQg aWQgZm9yIHRoZSBndWVzdC4gVGhpcyBvcHRpb24gaXMgbWFuZGF0b3J5IGlmIHRoZQ0KPj4+PiAr ICAgIFNDTUkgU01DICJzY21pX3NtY19tdWx0aWFnZW50IiBzdXBwb3J0IGlzIGVuYWJsZWQgZm9y IHRoZSBndWVzdC4gVGhlIGFnZW50IGlkcw0KPj4+PiArICAgIG9mIGd1ZXN0IG11c3QgYmUgdW5p cXVlIGFuZCBpbiB0aGUgcmFuZ2UgWzAuLjI1NV0uDQo+Pj4gdGhlc2UgdHdvIGRvbid0IHNlZW0g dG8gYmUgaW4gdGhlIGNvbW1pdCBtZXNzYWdlIGV4YW1wbGVzDQo+Pj4NCj4+Pg0KPj4gYGBzY21p X3NtY19tdWx0aWFnZW50YGAgbWVudGlvbmVkIGluIHRoZSBjb21taXQgbWVzc2FnZSBhdCB0aGUg Zm9sbG93aW5nDQo+PiBwYXJ0Og0KPj4NCj4+ICAgPiAtIHhsLmNmZzogYWRkIGNvbmZpZ3VyYXRp b24gb3B0aW9uIGFzIGJlbG93DQo+PiAgID4gYXJtX3NjaSA9ICJ0eXBlPXNjbWlfc21jX211bHRp YWdlbnQsYWdlbnRfaWQ9MiINCj4+DQo+PiBgYHhlbixzY2ktYWdlbnQtaWRgYCBpcyB1c2VkIGZv ciBkb20wbGVzcy4gSXQgZGVzY3JpYmVkIGluIGFybS1zY21pLnJzdA0KPj4gZmlsZSB3aGljaCB3 YXMgcHJlc2VudGVkIGluIHRoZSBuZXh0IGNvbW1pdC4NCj4gQWxsIGRldmljZSB0cmVlIG9wdGlv bnMgc2hvdWxkIGJlIGRlc2NyaWJlZA0KPiBkb2NzL21pc2MvYXJtL2RldmljZS10cmVlL2Jvb3Rp bmcudHh0LCBldmVuIGlmIHRoZXkgYXJlIHNpbWlsYXIgdG8gb3RoZXINCj4gb3B0aW9ucyBkZXNj cmliZWQgZWxzZXdoZXJlLiBUaGlzIGlzIHNpbWlsYXIgdG8gdGhlIHdheSBhbGwgWGVuIGNvbW1h bmQNCj4gbGluZSBvcHRpb25zIHNob3VsZCBiZSBkZXNjcmliZWQgaW4gZG9jcy9taXNjL3hlbi1j b21tYW5kLWxpbmUucGFuZG9jDQo+DQo+DQo+Pj4+ICAgIFVuZGVyIHRoZSAieGVuLGRvbWFpbiIg Y29tcGF0aWJsZSBub2RlLCBvbmUgb3IgbW9yZSBzdWItbm9kZXMgYXJlIHByZXNlbnQNCj4+Pj4g ICAgZm9yIHRoZSBEb21VIGtlcm5lbCBhbmQgcmFtZGlzay4NCj4+Pj4NCj4+Pj4gQEAgLTgyNCwz ICs4MzgsOTIgQEAgVGhlIGF1dG9tYXRpY2FsbHkgYWxsb2NhdGVkIHN0YXRpYyBzaGFyZWQgbWVt b3J5IHdpbGwgZ2V0IG1hcHBlZCBhdA0KPj4+PiAgICAweDgwMDAwMDAwIGluIERvbVUxIGd1ZXN0 IHBoeXNpY2FsIGFkZHJlc3Mgc3BhY2UsIGFuZCBhdCAweDkwMDAwMDAwIGluIERvbVUyDQo+Pj4+ ICAgIGd1ZXN0IHBoeXNpY2FsIGFkZHJlc3Mgc3BhY2UuIERvbVUxIGlzIGV4cGxpY2l0bHkgZGVm aW5lZCBhcyB0aGUgb3duZXIgZG9tYWluLA0KPj4+PiAgICBhbmQgRG9tVTIgaXMgdGhlIGJvcnJv d2VyIGRvbWFpbi4NCg== From xen-devel-bounces@lists.xenproject.org Mon Jan 19 21:12:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 21:12:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208323.1520509 (Exim 4.92) (envelope-from ) id 1vhwY3-0002jY-3i; Mon, 19 Jan 2026 21:12:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208323.1520509; Mon, 19 Jan 2026 21:12:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhwY3-0002jR-0x; Mon, 19 Jan 2026 21:12:31 +0000 Received: by outflank-mailman (input) for mailman id 1208323; Mon, 19 Jan 2026 21:12: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 1vhwY1-0002jK-IA for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 21:12:29 +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 8d80f75d-f57b-11f0-b15e-2bf370ae4941; Mon, 19 Jan 2026 22:12:27 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 74FFA40D9A; Mon, 19 Jan 2026 21:12:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1441C116C6; Mon, 19 Jan 2026 21:12:22 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8d80f75d-f57b-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768857144; bh=gIUQKTb4qgDQbXOcb9pJA2xwBrcDdOEamvxwJ41a2ec=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Nhzjk9mbbru6Xsqy1Zs/EAFgxxKt4A9Cy1fDKiwnjVq5+5N/gpBfcrh4DPuXP7Oze HLNxJ+MI9GhmwfcAELqI3a0X9xdzBBnfN14zU3ieB6ZPXE0mtn2xTIyqU38Ka5PikR BH8Y7sEMiBGFezcUshpP/lKeB1Ns2r87TBu1bRHdPM72TmlLgW6aejeWr/uY14hCcQ OIWLlEZjkly6a0XLnWOEkEaOjhRlUcV4f8+qMuTHpRw+M8TYg2MPUwTdYRGXYUCnuF W7HvkAZCdMXR0F5IXdtkfdKiJKLmHzFaSMo07p8fIDlzhw2e9ciuokXIs+9k70pH2E xW7yvBHbk9GVw== Date: Mon, 19 Jan 2026 13:12:21 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Oleksii Moisieiev cc: Stefano Stabellini , "xen-devel@lists.xenproject.org" , Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Volodymyr Babchuk , Grygorii Strashko Subject: Re: [PATCH v7 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver In-Reply-To: <5177397f-d596-40b3-9207-f0de63a24ee6@epam.com> Message-ID: References: <5177397f-d596-40b3-9207-f0de63a24ee6@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, 19 Jan 2026, Oleksii Moisieiev wrote: > On 16/01/2026 23:21, Stefano Stabellini wrote: > > On Fri, 16 Jan 2026, Oleksii Moisieiev wrote: > >> Hi Stefano, > >> Please see below. > >> > >> On 15/01/2026 03:14, Stefano Stabellini wrote: > >>> Hi Oleksii, > >>> > >>> I am fine with the goals and the strategy to achieve the goals but there > >>> are some finer details that don't make sense to me. I apologize if I am > >>> asking the same questions you have already answered as some time as > >>> passed from the last interaction. > >>> > >>> > >>> On Wed, 14 Jan 2026, Oleksii Moisieiev wrote: > >>>> This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-A > >>>> (TF-A) which provides SCMI interface with multi-agent support, as shown > >>>> below. > >>>> > >>>> +-----------------------------------------+ > >>>> | | > >>>> | EL3 TF-A SCMI | > >>>> +-------+--+-------+--+-------+--+-------++ > >>>> |shmem1 | |shmem0 | |shmem2 | |shmemX | > >>>> +-----+-+ +---+---+ +--+----+ +---+---+ > >>>> smc-id1 | | | | > >>>> agent1 | | | | > >>>> +-----v--------+---------+-----------+----+ > >>>> | | | | | > >>>> | | | | | > >>>> +--------------+---------+-----------+----+ > >>>> smc-id0 | smc-id2| smc-idX| > >>>> agent0 | agent2 | agentX | > >>>> | | | > >>>> +----v---+ +--v-----+ +--v-----+ > >>>> | | | | | | > >>>> | Dom0 | | Dom1 | | DomX | > >>>> | | | | | | > >>>> | | | | | | > >>>> +--------+ +--------+ +--------+ > >>>> > >>>> The EL3 SCMI multi-agent firmware is expected to provide SCMI SMC shared > >>>> memory transport for every Agent in the system. > >>>> > >>>> The SCMI Agent transport channel defined by pair: > >>>> - smc-id: SMC id used for Doorbell > >>>> - shmem: shared memory for messages transfer, Xen page > >>>> aligned. Shared memort is mapped with the following flags: > >>>> MT_DEVICE_nGnRE. > >>>> > >>>> The follwoing SCMI Agents are expected to be defined by SCMI FW to enable SCMI > >>>> multi-agent functionality under Xen: > >>>> - Xen management agent: trusted agents that accesses to the Base Protocol > >>>> commands to configure agent specific permissions > >>>> - OSPM VM agents: non-trusted agent, one for each Guest domain which is > >>>> allowed direct HW access. At least one OSPM VM agent has to be provided > >>>> by FW if HW is handled only by Dom0 or Driver Domain. > >>>> > >>>> The EL3 SCMI FW is expected to implement following Base protocol messages: > >>>> - BASE_DISCOVER_AGENT (optional if agent_id was provided) > >>>> - BASE_RESET_AGENT_CONFIGURATION (optional) > >>>> - BASE_SET_DEVICE_PERMISSIONS (optional) > >>>> > >>>> The SCI SCMI SMC multi-agent driver implements following > >>>> functionality: > >>>> - The driver is initialized from the Xen SCMI container ``xen_scmi_config`` > >>>> (compatible ``xen,sci``) placed under ``/chosen/xen``. Only the > >>>> ``arm,scmi-smc`` node that is a child of this container will bind to Xen; > >>>> other SCMI nodes (for example under ``/firmware``) are ignored to avoid > >>>> stealing the host OSPM instance. > >>>> > >>>> scmi_shm_1: sram@47ff1000 { > >>>> compatible = "arm,scmi-shmem"; > >>>> reg = <0x0 0x47ff1000 0x0 0x1000>; > >>>> }; > >>>> scmi_xen: scmi { > >>>> compatible = "arm,scmi-smc"; > >>>> arm,smc-id = <0x82000003>; <--- Xen management agent smc-id > >>>> #address-cells = < 1>; > >>>> #size-cells = < 0>; > >>>> #access-controller-cells = < 1>; > >>>> shmem = <&scmi_shm_1>; <--- Xen management agent shmem > >>>> }; > >>>> > >>>> - The driver obtains Xen specific SCMI Agent's configuration from the > >>>> Host DT, probes Agents and builds SCMI Agents list. The Agents > >>>> configuration is taken from "scmi-secondary-agents" property where > >>>> first item is "arm,smc-id", second - "arm,scmi-shmem" phandle and > >>>> third is optional "agent_id": > >>>> > >>>> / { > >>>> chosen { > >>>> xen { > >>>> ranges; > >>>> xen_scmi_config { > >>>> compatible = "xen,sci"; > >>>> #address-cells = <2>; > >>>> #size-cells = <2>; > >>>> ranges; > >>>> > >>>> scmi_shm_0: sram@47ff0000 { > >>>> compatible = "arm,scmi-shmem"; > >>>> reg = <0x0 0x47ff0000 0x0 0x1000>; > >>>> }; > >>>> > >>>> /* Xen SCMI management channel */ > >>>> scmi_shm_1: sram@47ff1000 { > >>>> compatible = "arm,scmi-shmem"; > >>>> reg = <0x0 0x47ff1000 0x0 0x1000>; > >>>> }; > >>>> > >>>> scmi_shm_2: sram@47ff2000 { > >>>> compatible = "arm,scmi-shmem"; > >>>> reg = <0x0 0x47ff2000 0x0 0x1000>; > >>>> }; > >>>> > >>>> scmi_shm_3: sram@47ff3000 { > >>>> compatible = "arm,scmi-shmem"; > >>>> reg = <0x0 0x47ff3000 0x0 0x1000>; > >>>> }; > >>>> > >>>> scmi-secondary-agents = < > >>>> 0x82000002 &scmi_shm_0 0 > >>> 0x82000002 is the same func_id as... > >>> > >>> > >>>> 0x82000004 &scmi_shm_2 2 > >>>> 0x82000005 &scmi_shm_3 3>; <--- func_id, shmem, agent_id > >>>> #scmi-secondary-agents-cells = <3>; > >>>> > >>>> scmi_xen: scmi { > >>>> compatible = "arm,scmi-smc"; > >>>> arm,smc-id = <0x82000002>; <--- Xen management agent func_id > >>> as the one used for Xen. This cannot be right? > >>> > >> That's right. Here should be 0x82000003. > >>>> #address-cells = <1>; > >>>> #size-cells = <0>; > >>>> #access-controller-cells = <1>; > >>>> shmem = <&scmi_shm_1>; <--- Xen management agent shmem > >>>> }; > >>>> }; > >>>> }; > >>>> }; > >>>> }; > >>>> > >>>> / { > >>>> /* > >>>> * Host SCMI OSPM channel - provided to the Dom0 as is if SCMI > >>>> * enabled for it, ignored by Xen multi-agent mediator > >>>> */ > >>>> scmi_shm: sram@47ff0000 { > >>>> compatible = "arm,scmi-shmem"; > >>>> reg = <0x0 0x47ff0000 0x0 0x1000>; > >>>> }; > >>> this is the same as &scmi_shm_0 which I guess is intended? > >>> > >> it is. to match Host DT. > >>>> firmware { > >>>> scmi: scmi { > >>>> compatible = "arm,scmi-smc"; > >>>> arm,smc-id = <0x82000002>; <--- Host OSPM agent smc-id > >>> but this again is the same smc-id meant to be used by Xen. > >>> > >>> If 0x82000002 is the privileged interface, then it is OK for Xen and > >>> also baremetal Linux to use it, but Linux Dom0 should not be using it? > >>> Or is the smc-id interchangeable and not necessarily tied to the > >>> agent-id? > >>> > >>> I think either way this detail should be clarified in the docs. Speaking > >>> of docs, the next patch introducing the doc is not up-to-date with this > >>> patch. > >>> > >> In my current configuration, I have the following setup: > >> > >> The Xen privileged interface operates through func_id 0x82000003. > >> func_id 0x82000002 is used for Domain-0, in order to keep the Device > >> Tree (DT) consistent between Xen and bare-metal configurations. > >> I am unsure how best to document this, since the implementation does > >> not strictly require this specific configuration and allows flexibility > >> for the > >> end user. My intention is to provide an example configuration in the DT > >> examples that is most likely to be used as a reference for real-world > >> setups. > > Yes, I am aligned with that > > > > > >> At this stage, I believe the most appropriate approach is to include a note > >> in the documentation stating that the examples illustrate a configuration > >> that aligns well with the Xen architecture, but other configurations are > >> possible depending on user requirements. > > Yes. The important detail is to explain that the same configuration > > works for both Linux baremetal and Linux Dom0. In the Linux Dom0 case, > > the privileged SCMI connection differs from the one of Linux Dom0 and it > > is the one used by Xen. > > > > Baremetal Linux: func_id 0x82000002, scmi-shmem 0x47ff0000 > > Dom0 Linux: func_id 0x82000002, scmi-shmem 0x47ff0000 > > Xen: func_id 0x82000003, scmi-shmem 0x47ff1000 > > > > This works because, I am guessing, the privileged SCMI connection is not > > tied to func_id 0x82000002, scmi-shmem 0x47ff0000. > > > > The problem occurs when there can be only one privileged SCMI connection > > and it is tied to func_id 0x82000002, scmi-shmem 0x47ff0000 which is the > > one described in the Host DT. In which case, Linux Dom0 ends up with the > > privileged connection, not Xen. > > > > I think we should explain why this problem does not occur. > > > > > >>>> #address-cells = < 1>; > >>>> #size-cells = < 0>; > >>>> shmem = <&scmi_shm>; <--- Host OSPM agent shmem > >>>> > >>>> protocol@X{ > >>>> }; > >>>> }; > >>>> }; > >>>> }; > >>>> > >>>> This approach allows defining multiple SCMI Agents by adding > >>>> Xen-specific properties under the ``/chosen`` node to the Host Device > >>>> Tree, leaving the main part unchanged. The Host DT SCMI channel will > >>>> be passed to Dom0. > >>>> > >>>> The Xen management agent is described as a ``scmi_xen`` node under the > >>>> ``xen,sci`` comaptible node, which is used by Xen to control other > >>>> SCMI Agents in the system. > >>>> > >>>> All secondary agents' configurations are provided in the > >>>> ``scmi-secondary-agents`` property with an optional ``agent_id`` field. > >>>> > >>>> The ``agent_id`` from the ``scmi-secondary-agents`` property is used > >>>> to identify the agent in the system and can be omitted by setting > >>>> ``#scmi-secondary-agents-cells = <2>``, so the Secondary Agents > >>>> configuration will look like this: > >>>> > >>>> / { > >>>> chosen { > >>>> xen { > >>>> xen_scmi_config { > >>>> compatible = "xen,sci"; > >>>> #address-cells = <2>; > >>>> #size-cells = <2>; > >>>> ranges; > >>>> > >>>> /* Shared memory nodes as defined earlier */ > >>>> > >>>> scmi-secondary-agents = < > >>>> 0x82000003 &scmi_shm_0 > >>>> 0x82000004 &scmi_shm_2 > >>>> 0x82000005 &scmi_shm_3 > >>>> 0x82000006 &scmi_shm_4>; > >>>> #scmi-secondary-agents-cells = <2>; > >>>> }; > >>>> }; > >>>> }; > >>>> } > >>>> > >>>> In this case, Xen will use the ``SCMI_BASE_DISCOVER_AGENT`` call to > >>>> discover the ``agent_id`` for each secondary agent. Providing the > >>>> ``agent_id`` in the ``scmi-secondary-agents`` property allows skipping > >>>> the discovery call, which is useful when the secondary agent's shared > >>>> memory is not accessible by Xen or when boot time is important because > >>>> it allows skipping the agent discovery procedure. > >>>> > >>>> Note that Xen is the only one entry in the system which need to know > >>>> about SCMI multi-agent support. > >>>> > >>>> - It implements the SCI subsystem interface required for configuring and > >>>> enabling SCMI functionality for Dom0/hwdom and Guest domains. To enable > >>>> SCMI functionality for domain it has to be configured with unique supported > >>>> SCMI Agent_id and use corresponding SCMI SMC shared memory transport > >>>> [smc-id, shmem] defined for this SCMI Agent_id. > >>>> - Once Xen domain is configured it can communicate with EL3 SCMI FW: > >>>> -- zero-copy, the guest domain puts SCMI message in shmem; > >>>> -- the guest triggers SMC exception with smc-id (doorbell); > >>>> -- the Xen driver catches exception, do checks and synchronously forwards > >>>> it to EL3 FW. > >>>> - the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen > >>>> management agent channel on domain destroy event. This allows to reset > >>>> resources used by domain and so implement use-case like domain reboot. > >>>> > >>>> Dom0 Enable SCMI SMC: > >>>> - pass dom0_scmi_agent_id= in Xen command line. if not provided > >>>> SCMI will be disabled for Dom0 and all SCMI nodes removed from Dom0 DT. > >>>> The driver updates Dom0 DT SCMI node "arm,smc-id" value and fix up shmem > >>>> node according to assigned agent_id. > >>> Given that everything else, the entire configuration, is based on device > >>> tree, I think it makes sense to also configure this via device tree > >>> instead of a command line. > >>> > >>> This could be another parameter under xen_scmi_config. What do you > >>> think? > >>> > >> The ``dom0_scmi_agent_id`` parameter was introduced to keep the Dom0 > >> configuration separate from the xen_scmi_config node, which is intended > >> specifically for Xen SCMI configuration. In my opinion, adding Dom0-specific > >> configuration to xen_scmi_config would mix the purposes of the node and > >> reduce clarity. > >> > >> Additionally, the ``dom0_scmi_agent_id`` parameter is similar to the > >> ``agent_id`` parameter used for arm_sci in xl.cfg. This approach ensures > >> that > >> the Dom0 configuration is as consistent as possible with the > >> configuration for > >> other domains. > >> > >> Overall, I believe this makes the configuration less confusing, as it allows > >> us to set similar parameters for both Dom0 and other domains in a clear > >> and organized manner. > > We are heading in a direction where Dom0 has its own separate domain > > node similarly to other Dom0less domains. Many of these changes have > > already been committed as part of Hardware Domain / Control Domain > > separation work by Jason. > > > > In a world where Dom0, like other DomUs, has its own configuration node > > and also Dom0 can be split between Hardware Domain and Control Domain, > > it doesn't make sense to use Dom0 command line options anymore. It is > > already possible to assign Dom0 "powers" to a dom0less domain for > > example. > > > > I can see it is worth discussing command line options for dom0 in > > situations where Device Tree might not be present (datacenter > > configuration on ACPI system) but in this case where Device Tree changes > > are required, I think it doesn't make sense to add Dom0 command line > > options as they are less flexible and a duplicate of other options we > > must have anyway. > That makes sense to me. Since we are moving to the Dom0 Device Tree > configuration, > I can move ``dom0_scmi_agent_id`` inside the ``xen,sci`` node and rename > it as the > ``agent_id`` property. > > Would you recommend dropping the ``dom0_scmi_agent_id`` command line > parameter > entirely, or should I keep it as a backup option? I would drop the command line parameter entirely From xen-devel-bounces@lists.xenproject.org Mon Jan 19 22:03:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 22:03:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208335.1520518 (Exim 4.92) (envelope-from ) id 1vhxL9-0000Sf-Lk; Mon, 19 Jan 2026 22:03:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208335.1520518; Mon, 19 Jan 2026 22: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 1vhxL9-0000SY-Ie; Mon, 19 Jan 2026 22:03:15 +0000 Received: by outflank-mailman (input) for mailman id 1208335; Mon, 19 Jan 2026 22: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 1vhxL8-0000SS-A2 for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 22:03:14 +0000 Received: from SA9PR02CU001.outbound.protection.outlook.com (mail-southcentralusazlp170130001.outbound.protection.outlook.com [2a01:111:f403:c10c::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a422390a-f582-11f0-b15e-2bf370ae4941; Mon, 19 Jan 2026 23:03:10 +0100 (CET) Received: from SJ0P220CA0017.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:41b::27) by DM6PR12MB4219.namprd12.prod.outlook.com (2603:10b6:5:217::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Mon, 19 Jan 2026 22:03:05 +0000 Received: from SJ5PEPF000001E9.namprd05.prod.outlook.com (2603:10b6:a03:41b:cafe::f9) 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.9520.11 via Frontend Transport; Mon, 19 Jan 2026 22:02:53 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ5PEPF000001E9.mail.protection.outlook.com (10.167.242.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Mon, 19 Jan 2026 22:03:04 +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; Mon, 19 Jan 2026 16:03:04 -0600 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 19 Jan 2026 16:03:04 -0600 Received: from [172.29.134.248] (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, 19 Jan 2026 14:03:02 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a422390a-f582-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Y67QIV6tFf/FymduX6Z5CeTCFS7fV5k26NfqV9DFegQyFbNb3x0rchAa5ahAod49QDZMj03hrn0uIX3JShAuLjoE/bPpC15beLo/+wcY3h6sVVKfJ5cctDlI99wRR2gven0AcdkCyfaL9dw5WI/MYJjv0RMiVQnQ4km8WIV62Q0dei2/28EWMEySXgU8DsSxlAOlSa1W79KVvO4Ae2inFAp2bCVxiPUqDXyVt//rd69UbNaO5HbnDbWcN1W0ZGP/f3CzZLPDUsac3yZ+JhLSqUHHN8ZI/5vigTqlx3+oR4uFwDQC4xkHud1G++5XtysD/Py6zqWEFjz+F0aj+nV21g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4TfQEhyGuQ3DbXSnJe7w1JkgRDIIZ3s+IHEZQm2/ERI=; b=PCRAaW/JuND1ZGIpDpQzymVCMfxSk/odkFvpnXLySXqSwF2XJWEmJiNP1dpSVe39zmcx7fHqkHdcK7znL62ZdWk7WvfjogE6yvVPNf4KqisrspIKvnTrUk7pZtQx0wKiobgjufRg0svvk9aVsGwg4u8yIaSnXXl7uFRBbuHkwqRIfDeVJsFiY/ioLIE8vIC7t7wOmbCHaYxhnL3s/1rQ/Y03jt1ySTG2SJCkI0Z1eFt2ZDQJD3cUZU5JHt4jJzuVX/UOBa0+aHz6meHyB9k2yGG1JtVDM73jcUIJbrSwn5Zfmi0e2lL1abpBwVG0piSXkkhvilM+5bJU9qLXDEXMoA== 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=4TfQEhyGuQ3DbXSnJe7w1JkgRDIIZ3s+IHEZQm2/ERI=; b=EpNlyW2iX2kPSxnAwalfaDNitzgcyEfkOGdo0vHrjjhvzetdXwCRtD7fiwJQev8IjEoZlSPI/Os5VLp6XklbMPj3pJD2Vn0qUC2Pif5YPtDinbrShkw7A/fhFaKglculLc2zKmrTqTqWbxl8n+0D52C+vfrY69ddgyAuMOAxc0I= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 19 Jan 2026 17:02:57 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/4] PCI: handle PCI->PCIe bridges as well in alloc_pdev() 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: <58091dc1-7bda-4536-8200-2d0a5679d4d1@suse.com> Content-Language: en-US From: Stewart Hildebrand In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001E9:EE_|DM6PR12MB4219:EE_ X-MS-Office365-Filtering-Correlation-Id: 40fbe1db-fccc-4c2f-cb22-08de57a68583 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?R2Y2am9vQkhPVGhqcTYxZlRyd0lDMDdQSEdEanp0N2kyVTF3ZTNiRlhudG4r?= =?utf-8?B?Q3VzMnlvZzVYcVVYTmFialhSSnFZSVF1b0RLazRMUCtzcU55aDRzdmIrS3BP?= =?utf-8?B?cmZvaGdhQ3k4dFo4RHlqZmYvenY4bW9WTy9FMTFmN3VGOE5rRGNoakFQNFBN?= =?utf-8?B?VzNqYTZCUzFpbVF5ZnlYa2lsVDV5NFdxbUN1QmRnclhWZSs3LzFST1FmbExX?= =?utf-8?B?U3B6QllHNEN6elliTHJCUVgrOHFTbnJkZERXalovak1iSFhyYVB4TXh5eDJV?= =?utf-8?B?Q0RXa1FLY3M1UlZWZWl2dmEvNTVqUU1PV2xWb1RObXh3UTY1RmRHSEVQSzEr?= =?utf-8?B?VnFzL09hNkNmTElOMS90eXlvZ3NXN2J2SVVrQWo5clBVcWNpYWl2NTRrMTJ6?= =?utf-8?B?L1dIMHBDbmh2OGZkdWRqZ29pZGc3WWZZWDhzM2RGREo2RE01aDJMQmtrd3NV?= =?utf-8?B?djkvY0ExZkNab0Z1dmtGOStqQUVwNXloZFlINkd3QUdLTWxGT05VTTdBcVRZ?= =?utf-8?B?TjRONjhQZUZJRC9wMXI0SElzT0Y4aEtqRVF1aFNKb0pEd1g2WFVZT1YvOFRk?= =?utf-8?B?LzYwek5oMkdnVFRVdUVUZ3AzVU9jUDh2akZ4RjNUazh2VU9KU2taaWlDd1d2?= =?utf-8?B?UWFKM0dQVzBsT055cHp5MngxdWxSU2JjZDk4cGpucHg1cWlvOHBqb2dKZlFC?= =?utf-8?B?T0NKdXl6ZXVhZjR2dHI2N0YwenU1cUcwV1hMTzlHMzEzQXFmbktZd1JLZnI0?= =?utf-8?B?bnJsTHF1MjV0RzFQaTRyUXNXeGpNWWw1dG1sQW9WeUREY21SNmRKSHBmS1Rl?= =?utf-8?B?U09idUYwdktQSXNoMGFWdTErWnk1VnRpYjhNcmtCdGJ5dnNVRHFjSG5nVUt5?= =?utf-8?B?VEhHemFmemJaem82NDNLTXdSZVFuSnFrN0R4VFlQWmhhQzdOTG9pVERmNXFm?= =?utf-8?B?Rzh3YU9VSHg5V2N1cC93QXYxNUFLZkVOOVpqN1NEQ3pBUWdXY0RoQ0pkOHBl?= =?utf-8?B?MGYzVjdvNm0wdXBJWlplRUZYOG15RWlUMWxxSXh4MHRHN0NZNWJnVkVXT0M5?= =?utf-8?B?dkJNa2l6VHkyY2xzaCtNMGJod2xXRnlSVTkzWXIzcmZ4UHVEemo5ZitmcVlM?= =?utf-8?B?MThLbEl2OWRzZXFyUjI4T0ZmOUJkQ1ZCTTNZeG1hS24wTUNrKzlxVEtrWUIw?= =?utf-8?B?aE5HVWhWd3ZmNktmZzhjeldHdFRIaCtoZmhMUStLVWd3WHFyUmJhQVprUSta?= =?utf-8?B?R1AxMnBJaTFkZHJYTVc3aEZzRkgrSjI4cXBXTmZsVkgvanVuR1RBOWlKYUlO?= =?utf-8?B?NTBFczNVQkoyaDZRS05xb0xrQXNsclBhMno1dUR1Vnpxa21EN21HSTk2V1Zq?= =?utf-8?B?cXNpMXNEUENLTnpJSWd3YXpsc1d3ekord29QSDk2KzdyWTVpL3FJVzlkbzlS?= =?utf-8?B?R1VrN0hYeHhqWURocGV0eFc1ZWpLOGI3T2pXRlY5QzJzSDhEL3MzVW5nNVVZ?= =?utf-8?B?M052QXVLL0NiR2Q4eGs4UGhxWnlyUnVSREQzdk5GS25PTzVKR05hdmlYSlVL?= =?utf-8?B?NkQ1aUZtNFZIZ0RDaG5qVitVWHc3Tnd0UXF4UzFHaDlObHJER0pCQVUxdUNB?= =?utf-8?B?bGFZLzFUZnJJQmJwVS9wM2RBVVlWelQ0cFBITTQ5WldGSklXL0lvcDZTR3hW?= =?utf-8?B?Wk9vQXFmYjVhZUhHU0FXTjFuSnl4RlNVK2cvSmhpODZNS3ZqWEdnWG9DNzNa?= =?utf-8?B?dEEwdHBURGs4MEx3c2xNMUg3V3NiY3lmdkF4b3AySkc1bEN4TVhxeEE3eU8w?= =?utf-8?B?RXg1TmZJMVFDSHNjM1htZnFxQkRmTzZIUTRlVmF6Nkp1STl4a0ZCemZVQXdD?= =?utf-8?B?V0c3ODlzbTJxU0MzYk54dVVRY1ZiL3hPZGprNmQyZTBtemxQMUFiQjEvd0ZE?= =?utf-8?B?NE1lUUNZSDVsYXBFT2R6OTRhOTZJL00vbjlkRi9XZEFWdFdiZFdQbTJ5ajA5?= =?utf-8?B?QnVPTmJaZlpodloxNFFEQk1VQ3N4UTZrTGdwVVFKNmVFOER0NURxc1M5eXhp?= =?utf-8?B?YThRVkxnaHlTVVU2YXhJOC9VS29KSyt2ajBzeDdHVUcxMXV4QkNmRG5GQ3Fi?= =?utf-8?B?RTdPTHNndnN2NmFHd0g5V2lzV0huN25RSTJjb2V5cDZTTmFCMjdvUWg3c0hl?= =?utf-8?B?R2dOaEhOVGFHdTlld0svQmhDOWJTa2J0K0N3N0NXUUdJUmd1aGRjQjhYT0w4?= =?utf-8?B?eExmZmxOUEdPWDdjdDBhMXdLcEhRPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jan 2026 22:03:04.8693 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 40fbe1db-fccc-4c2f-cb22-08de57a68583 X-MS-Exchange-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: SJ5PEPF000001E9.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4219 On 1/19/26 09:46, Jan Beulich wrote: > It's not clear why the enumerator was omitted, as these clearly shouldn't > take the "default" path (issuing a warning). Handle them the same as > legacy and PCIe->PCI bridges. > > Fixes: e7e08d86ad2f ("IOMMU/PCI: consolidate pdev_type() and cache its result for a given device") > Signed-off-by: Jan Beulich Reviewed-by: Stewart Hildebrand From xen-devel-bounces@lists.xenproject.org Mon Jan 19 23:24:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 23:24:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208347.1520529 (Exim 4.92) (envelope-from ) id 1vhyb4-0001VG-Ay; Mon, 19 Jan 2026 23:23:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208347.1520529; Mon, 19 Jan 2026 23:23:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vhyb4-0001V9-7u; Mon, 19 Jan 2026 23:23:46 +0000 Received: by outflank-mailman (input) for mailman id 1208347; Mon, 19 Jan 2026 23:23: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 1vhyb3-0001V3-7R for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 23:23:45 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e209b5b3-f58d-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 00:23:38 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 244CE600CB; Mon, 19 Jan 2026 23:23:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7953CC116C6; Mon, 19 Jan 2026 23:23: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: e209b5b3-f58d-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768865016; bh=h70xqgpSOHh35QgijNb0CKzSa9qCNWudRuvTsZ7KzFQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ttv69XRgbXMJ9OV9pCR5TV8bdG4l77DR5qKNlJK+6CoRWIYGVXqX0GZPgI+IxCxUu PUw4CN6nlZqw8RGEep+HGgyJUKOSEgkezlGTAeVXoHYBClmXkmWmrTLDUlgIxK2Cg8 qNR0bA2y7LFqBzqT1DqzefFkA47YSC3xh6Ng+RuFQdsKfEVSMXb03B5+tqMiGTDSWB 3nRcfBUUy1NsOKASdTzggz23X0oUv0D239GQD7VQDwZxPUUGlJo5lgH6spcGBvnLdm dkkLn8tOfZ/XGDcQTI/pxq4AKvtZX9bTkSMkBf3UqvFkb/3ok3p/HAqaPd+maSp467 fCVgclEEmHaKA== Date: Mon, 19 Jan 2026 15:23:34 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Jan Beulich cc: Stefano Stabellini , grygorii_strashko@epam.com, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Victor Lira , andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH v3] xen/console: handle multiple domains using console_io hypercalls In-Reply-To: <63c35c5e-577b-4346-b600-03808306177f@suse.com> Message-ID: References: <63c35c5e-577b-4346-b600-03808306177f@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, 19 Jan 2026, Jan Beulich wrote: > On 14.01.2026 01:39, Stefano Stabellini wrote: > > @@ -815,6 +831,11 @@ long do_console_io( > > if ( count > INT_MAX ) > > break; > > > > + d = console_get_domain(); > > + console_put_domain(d); > > + if ( d != current->domain ) > > + return 0; > > This isn't atomic (as in: in a suitably locked region) with ... > > > @@ -830,7 +851,10 @@ long do_console_io( > > break; > > } > > rc += len; > > - serial_rx_cons += len; > > + nrspin_lock_irq(&console_lock); > > + if ( serial_rx_cons != serial_rx_prod ) > > + serial_rx_cons += len; > > + nrspin_unlock_irq(&console_lock); > > } > > break; > > ... this. If the focus domain changes after the check in the earlier hunk, > I think you need to also return with no input here. Or you need to acquire > the lock earlier (and then similarly in console_switch_input()), albeit > that would then mean holding it across a copy-to-guest. Which technically > is perhaps not a problem, but it leaves an uneasy feeling. I thought about it when writing this patch and I had the same feeling as you. However, especially considering the other feedback, I don't see another viable solution. I'll extend the locking. > In no case may you continue the loop if the focus domain changed, or else > you potentially hand the old one input targeted at the new one. > > For context: What caught my attention is the conditional inside the locked > region. This, imo, shouldn't be necessary when everything else is properly > structured. > > Actually, the lock strictly needs holding now across all accesses to > serial_rx_{cons,prod}. That'll then naturally make the conditional > unnecessary. From xen-devel-bounces@lists.xenproject.org Mon Jan 19 23:30:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 19 Jan 2026 23:30:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208362.1520538 (Exim 4.92) (envelope-from ) id 1vhyhu-0003AI-3y; Mon, 19 Jan 2026 23:30:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208362.1520538; Mon, 19 Jan 2026 23: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 1vhyhu-0003AB-1R; Mon, 19 Jan 2026 23:30:50 +0000 Received: by outflank-mailman (input) for mailman id 1208362; Mon, 19 Jan 2026 23:30: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 1vhyhs-0003A5-3x for xen-devel@lists.xenproject.org; Mon, 19 Jan 2026 23:30:48 +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 e1316c65-f58e-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 00:30:46 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 5B036600CB; Mon, 19 Jan 2026 23:30:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AF3F8C116C6; Mon, 19 Jan 2026 23:30: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: e1316c65-f58e-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768865445; bh=EN7ctvv9pHTp8U7XaRXHF3QmJYU6S5dpEJGH8sbixiY=; h=Date:From:To:cc:Subject:From; b=Oc5yBzMvIRA/1cNbKV4ip+iJw6NUBgRkDixeH/HU329KcUmS6WquRZkwoPcNxw3sz TBdbvxfXyLbxbxfC7MPX0d0hcbfO2GyfwbJ6s5tcZsAUmSGE2xDes8m1ycevqSczoR txeRmAqOeOq/9AMUZmSRCC7oNfAE8X3PjERj6RAM2nObIcTdU8PXn+bcQmyJOAjATl GSfO2n2v+ON7p6O5FOiz8fjbFJosY4ufO5rKWIUMEbP1eg3+IfmeWQ+olblvvA4DPj 3ZrOhZ8UBuG6Yhqq4javndz9gQa8xlFyQQAPd9c0fSYR3UU7ubLpYc6Dj2yKrJqCF1 nBEq1QpdPqcSg== Date: Mon, 19 Jan 2026 15:30:42 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: xen-devel@lists.xenproject.org cc: grygorii_strashko@epam.com, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Victor Lira , andrew.cooper3@citrix.com, sstabellini@kernel.org, jbeulich@suse.com Subject: [PATCH v4] xen/console: handle multiple domains using console_io hypercalls Message-ID: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Allow multiple dom0less domains to use the console_io hypercalls to print to the console. Handle them in a similar way to vpl011: only the domain which has focus can read from the console. All domains can write to the console but the ones without focus have a prefix. In this case the prefix is applied by using guest_printk instead of printk or console_puts which is what the original code was already doing. When switching focus using Ctrl-AAA, discard any unread data in the input buffer. Input is read quickly and the user would be aware of it being slow or stuck as they use Ctrl-AAA to switch focus domain. In that situation, it is to be expected that the unread input is lost. The domain writes are buffered when the domain is not in focus. Push out the buffer when the domain enters focus. Add the console_lock around serial_rx_prod and serial_rx_cons modifications to protect it against concurrent writes to it. Also protect against changes of domain with focus while reading from the serial. Signed-off-by: Stefano Stabellini --- Changes in v4: - protect serial_rx_prod and serial_rx_cons with console_lock - protect CONSOLEIO_read against concurrent changes of the focus domain - if vpl011 is enabled, send characters to it (retains current behavior on ARM) --- xen/drivers/char/console.c | 52 ++++++++++++++++++++++++++++++++------ 1 file changed, 44 insertions(+), 8 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 7b176da71a..acfc49d558 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -574,8 +574,12 @@ static void console_switch_input(void) if ( !d->console.input_allowed ) continue; - console_rx = next_rx; printk("*** Serial input to DOM%u", domid); + nrspin_lock_irq(&console_lock); + console_rx = next_rx; + /* Don't let the next dom read the previous dom's unread data. */ + serial_rx_cons = serial_rx_prod; + nrspin_unlock_irq(&console_lock); break; } } @@ -594,10 +598,22 @@ static void __serial_rx(char c) if ( console_rx == 0 ) return handle_keypress(c, false); + nrspin_lock_irq(&console_lock); d = console_get_domain(); if ( !d ) + { + nrspin_unlock_irq(&console_lock); return; + } +#ifdef CONFIG_SBSA_VUART_CONSOLE + /* Prioritize vpl011 if enabled for this domain */ + if ( d->arch.vpl011.base_addr ) + { + /* Deliver input to the emulated UART. */ + rc = vpl011_rx_char_xen(d, c); + } else +#endif if ( is_hardware_domain(d) || IS_ENABLED(CONFIG_DOM0LESS_BOOT) ) { /* @@ -613,11 +629,6 @@ static void __serial_rx(char c) */ send_guest_domain_virq(d, VIRQ_CONSOLE); } -#ifdef CONFIG_SBSA_VUART_CONSOLE - else - /* Deliver input to the emulated UART. */ - rc = vpl011_rx_char_xen(d, c); -#endif if ( consoled_is_enabled() ) /* Deliver input to the PV shim console. */ @@ -629,6 +640,7 @@ static void __serial_rx(char c) rc); console_put_domain(d); + nrspin_unlock_irq(&console_lock); } static void cf_check serial_rx(char c) @@ -729,6 +741,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, unsigned int flags = opt_console_to_ring ? CONSOLE_ALL : CONSOLE_DEFAULT; struct domain *cd = current->domain; + struct domain *input; while ( count > 0 ) { @@ -741,17 +754,26 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, if ( copy_from_guest(kbuf, buffer, kcount) ) return -EFAULT; - if ( is_hardware_domain(cd) ) + nrspin_lock_irq(&console_lock); + input = console_get_domain(); + if ( input && cd == input ) { + if ( cd->pbuf_idx ) + { + console_send(cd->pbuf, cd->pbuf_idx, flags); + cd->pbuf_idx = 0; + } /* Use direct console output as it could be interactive */ - nrspin_lock_irq(&console_lock); console_send(kbuf, kcount, flags); + console_put_domain(input); nrspin_unlock_irq(&console_lock); } else { char *kin = kbuf, *kout = kbuf, c; + console_put_domain(input); + nrspin_unlock_irq(&console_lock); /* Strip non-printable characters */ do { @@ -793,6 +815,7 @@ long do_console_io( { long rc; unsigned int idx, len; + struct domain *d; rc = xsm_console_io(XSM_OTHER, current->domain, cmd); if ( rc ) @@ -813,6 +836,15 @@ long do_console_io( if ( count > INT_MAX ) break; + nrspin_lock_irq(&console_lock); + d = console_get_domain(); + if ( d != current->domain ) + { + console_put_domain(d); + nrspin_unlock_irq(&console_lock); + return 0; + } + rc = 0; while ( (serial_rx_cons != serial_rx_prod) && (rc < count) ) { @@ -825,11 +857,15 @@ long do_console_io( if ( copy_to_guest_offset(buffer, rc, &serial_rx_ring[idx], len) ) { rc = -EFAULT; + console_put_domain(d); + nrspin_unlock_irq(&console_lock); break; } rc += len; serial_rx_cons += len; } + console_put_domain(d); + nrspin_unlock_irq(&console_lock); break; default: rc = -ENOSYS; -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 07:11:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 07:11:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208388.1520548 (Exim 4.92) (envelope-from ) id 1vi5tE-000596-7K; Tue, 20 Jan 2026 07:11:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208388.1520548; Tue, 20 Jan 2026 07: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 1vi5tE-00058z-4U; Tue, 20 Jan 2026 07:11:00 +0000 Received: by outflank-mailman (input) for mailman id 1208388; Tue, 20 Jan 2026 07:10:59 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi5tD-00058s-1d for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 07:10:59 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vi5t7-00Cd0R-1m; Tue, 20 Jan 2026 07:10:53 +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 1vi5t6-00B8um-2v; Tue, 20 Jan 2026 07:10: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=In-Reply-To:Content-Type:MIME-Version:References:Message-ID :Subject:Cc:To:Date:From; bh=aPPFJbjUAKb601RHV/6PWokK7q363TBq5kpsScZJaaA=; b= y1B5JOJ6ldIx9/MLW9dep8E78pfOPB6/kWTJ5dVgQTtcrnkhWJI5+hs3EuwjKL2VfkpMi7cU+w+hK ESw8ptov8xCEbxvYPd7HW2KwiX69fgJCy5UMQEdExAC3k4D3f/r2pvfgPhQAvvzW3j9y0rlIQN4Qp yswRJCcHHOsmu2EzY=; From: dmukhin@xen.org Date: Mon, 19 Jan 2026 23:10:50 -0800 To: Jan Beulich Cc: Stefano Stabellini , andrew.cooper3@citrix.com, anthony.perard@vates.tech, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, dmukhin@ford.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH v2] INSTALL: remove unsupported XEN_CONFIG_EXPERT from documentation Message-ID: References: <20260116030842.415583-2-dmukhin@ford.com> <09c0007b-3cac-469a-83a0-726c1be149da@suse.com> <6f275030-a3c2-4710-952e-56c3226b5a8b@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6f275030-a3c2-4710-952e-56c3226b5a8b@suse.com> On Mon, Jan 19, 2026 at 08:29:58AM +0100, Jan Beulich wrote: > On 16.01.2026 21:47, Stefano Stabellini wrote: > > On Fri, 16 Jan 2026, Jan Beulich wrote: > >> On 16.01.2026 04:08, dmukhin@xen.org wrote: > >>> --- a/INSTALL > >>> +++ b/INSTALL > >>> @@ -33,11 +33,11 @@ small subset of the options. Attempts to change other options will be > >>> silently overridden. The only way to find which configuration options > >>> are available is to run `make menuconfig' or the like. > >> > >> I fear this earlier paragraph needs editing as well, which will then > >> make more clear that ... > >> > >>> -You can counter-override this behaviour by setting XEN_CONFIG_EXPERT=y > >>> -in your environment. However, doing this is not supported and the > >>> -resulting configurations do not receive security support. If you set > >>> -this variable there is nothing stopping you setting dangerously > >>> -experimental combinations of features - not even any warnings. > >>> +This behavior can be overridden by enabling "Configure EXPERT features" > >>> +in Kconfig (CONFIG_EXPERT). > >> > >> ... this may not be quite adequate. > >> > > > > I am not sure how you would like to change the earlier paragraph or this > > paragraph. I gave it a try and removed both paragraphs, replacing it > > with this: > > > > """ > > Only a subset of options is supported or security-supported by Xen > > Project. You can explore all available options, including unsupported > > ones and those recommended only for expert users, by using `make > > menuconfig` and enabling `CONFIG_UNSUPPORTED` and/or `CONFIG_EXPERT`. > > However, enabling these options is not supported, and configurations > > resulting from them do not receive security support. > > """ > > > > What do you think? > > This would be fine with me. Thanks Stefano and Jan. I will send an update shortly. -- Denis From xen-devel-bounces@lists.xenproject.org Tue Jan 20 07:17:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 07:17:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208398.1520559 (Exim 4.92) (envelope-from ) id 1vi5zk-0005ia-SP; Tue, 20 Jan 2026 07:17:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208398.1520559; Tue, 20 Jan 2026 07:17: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 1vi5zk-0005iT-Pe; Tue, 20 Jan 2026 07:17:44 +0000 Received: by outflank-mailman (input) for mailman id 1208398; Tue, 20 Jan 2026 07:17:43 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi5zj-0005iN-OW for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 07:17:43 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vi5zj-00Cd7n-1N; Tue, 20 Jan 2026 07:17:43 +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 1vi5zi-00B9Gz-2f; Tue, 20 Jan 2026 07:17: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:MIME-Version:Message-ID:Date: Subject:Cc:To:From; bh=pKv7ArlF2h8gshpBz8SQSzsZjNvWC9ePOUcC6f6+vYs=; b=fqCAX5 x5ojsDobFg+W5C3nbGSSGsmyDUjaOm0WBukIaUZRnOLFsA8V5lSby+/aamd5HMswdrlFlZfwrYvTH CMbjLAZPLr5uOKDIvnbj5V6onXxWjbI9zMiiE0zYquW6LsaQ1UeYE69xVrNW6soBZKk9K/Crh0g1V Dpzx9EEBArk=; 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] INSTALL: remove unsupported XEN_CONFIG_EXPERT from documentation Date: Mon, 19 Jan 2026 23:16:56 -0800 Message-ID: <20260120071654.640873-3-dmukhin@ford.com> X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Denis Mukhin Remove XEN_CONFIG_EXPERT explanation and also correct information in the entire "Xen Hypervisor" section. Amends: 37339ba9ef46 ("automation: Remove XEN_CONFIG_EXPERT leftovers") Suggested-by: Stefano Stabellini Signed-off-by: Denis Mukhin --- Changes since v2: - Applied suggested edits to the entire section suggested by Stefano - Link to v2: https://lore.kernel.org/xen-devel/20260116030842.415583-2-dmukhin@ford.com/ --- INSTALL | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/INSTALL b/INSTALL index c2e756bf4b2b..670cbc2fa3b8 100644 --- a/INSTALL +++ b/INSTALL @@ -25,19 +25,12 @@ Xen Hypervisor Xen itself is configured via a `kconfig' system borrowed from Linux. See https://www.kernel.org/doc/html/v5.4/kbuild/. -Note that unlike with Linux, and contrary to that document, you cannot -look at Kconfig files, or the default or generated config files etc., -to find available configuration options. This is because it is only -supported (and security supported) by the Xen Project, to change a -small subset of the options. Attempts to change other options will be -silently overridden. The only way to find which configuration options -are available is to run `make menuconfig' or the like. - -You can counter-override this behaviour by setting XEN_CONFIG_EXPERT=y -in your environment. However, doing this is not supported and the -resulting configurations do not receive security support. If you set -this variable there is nothing stopping you setting dangerously -experimental combinations of features - not even any warnings. +Only a subset of options is supported or security-supported by Xen +Project. You can explore all available options, including unsupported +ones and those recommended only for expert users, by using `make +menuconfig` and enabling `CONFIG_UNSUPPORTED` and/or `CONFIG_EXPERT`. +However, enabling these options is not supported, and configurations +resulting from them do not receive security support. Options recognized by configure =============================== -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 07:26:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 07:26:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208410.1520569 (Exim 4.92) (envelope-from ) id 1vi67i-0007H2-KU; Tue, 20 Jan 2026 07:25:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208410.1520569; Tue, 20 Jan 2026 07:25: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 1vi67i-0007Gu-H6; Tue, 20 Jan 2026 07:25:58 +0000 Received: by outflank-mailman (input) for mailman id 1208410; Tue, 20 Jan 2026 07:25: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 1vi67g-0007Gi-NZ for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 07:25:56 +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 3f99e113-f5d1-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 08:25:51 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-480142406b3so25707925e9.1 for ; Mon, 19 Jan 2026 23:25:51 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4358f12ee69sm2797507f8f.11.2026.01.19.23.25.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jan 2026 23:25:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3f99e113-f5d1-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768893951; x=1769498751; 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=n7DieNAjIepvpk0xvQnW1kQ+6VlXF95tzA1h3z+8h4k=; b=Q72J17f8CiAU2KMemFefGdKAcJhOFD+cpIIJbIlqZZdLjqvGJUyFUUkDxyFk89WmbJ aleNYmImnhteJ5SSz9JgtmBsSmzuTHLD/ZHDFKvUwMPXdgvKWL6CUZpawcI3vhfaTdKW vE4WX5adqgmRQ3iNJecwINiALR0kx1F9KnsD72KlsSEGsu+0yX80SduiiV6GZWz/FDMB anQviQWo4mm0sA5dZYMv8MWZ0FvZry7vXNEbOyhCprkv8sUme14Kw/1ACB+TMpaD3PXp SnwVar24V3eU/YA12db5eNzGgt9eD/FH1rbPcKn1WNuB0W23jMmR39yrOlnmQouDlx14 1Z/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768893951; x=1769498751; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=n7DieNAjIepvpk0xvQnW1kQ+6VlXF95tzA1h3z+8h4k=; b=Qrw+mcQHiYX1J9Smj+BVP4rKWQY9C+0KlA5o2LLo+pPynxPKWUHZaT91BUWQqUh/EI oOgYBm/8hOWFgM/mKz6GkgQ/p7AlamhesMyBUR4C2kMQtTA+KOM73MrM9tYqncyOJA5D axcXPCdna+7M5IRHAcBULaiN3ReIfO8grEV2rbL9dBL0iimKOuQDJacAuqLvqUS+1cVF K0u0fpqQgeViwBySXrpfgzgJb1RygxeO+fUOvBi3kTLqlT9g4WhXx5TjLBDe+G6ncnP6 OnD9SRNIw4tfNM941LBfw/pD7FJU4acntEz5kT/zBGdvQs+uTyY1RThrodt9Z8pKxApg yeNA== X-Forwarded-Encrypted: i=1; AJvYcCXTot3RIr0Vuf84PNcb6ZEZ9Dl37V10mdl5R1H7X4TihKW/7ujLhUvxt2Xe1t7/XxjT09NK8nBQbjA=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywt0CG2pD1JDaUvlQbdafFiVO9S47JwzHDUm4QMAd/UEEJJGcwJ uzX2hD1KV/Nqn/jtLytchSsXDegM3vamQQo+OVJn2fqv++zRRUh+By5Kiel9orakiw== X-Gm-Gg: AY/fxX41ddWmLkTaspAkRhG8Eysl4yMrinIjfJ+U/BlmKuLlNrkuPEh9pytvgHtswBD vk9zinFq31L/kO9wY0h/uqDDLQPMKr2cht2REPENuNA2Q/5Wd1EzdR9xKByRP4Nhf2FfWNKWD1K i7QtlF41N1HoCxJBdGrlXO9IS4KLbVOjdiuQpoxZPJg64nXY+HHXvLzX14ax80Jviv3tJvEv88L c0MP9CadHKB92pDMIXSfGAtteZ/iaDmDEkfL1bCFkAKqCSwj1LoWB7l//YbCqxt1Gzggdlh4KeW nEjjwWxXJgT8uMhFR3y1slBchKldFmXUga/xtCAbnT77rMrj6s32SPYm1Oaj4DMALLOw7E9iHxz msFUjrGVdgLmXEgG7sijty/Nn9fiBEtzKBnxKXgA7EwLIGf3jnQajUg6OmUQQt1gY9w6Nc8WCJK Dne60MLEh71p+/KPqPrNVCo084IUozQuzxIuR0lq34JBAkl9voRF2GsryVLEbJPymWvS7bJ/Awo Ck= X-Received: by 2002:a05:600c:3555:b0:47e:e20e:bb9c with SMTP id 5b1f17b1804b1-4801e2f8e63mr181696175e9.8.1768893950748; Mon, 19 Jan 2026 23:25:50 -0800 (PST) Message-ID: <97127b23-4e4c-4b06-a8bb-b1dad31bf0b0@suse.com> Date: Tue, 20 Jan 2026 08:25:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/3] xen/mm: limit non-scrubbed allocations to a specific order From: Jan Beulich To: Roger Pau Monne Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260115111804.40199-1-roger.pau@citrix.com> <20260115111804.40199-4-roger.pau@citrix.com> <858d73b3-2feb-419f-bf3b-9a264e9f9af8@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: <858d73b3-2feb-419f-bf3b-9a264e9f9af8@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 19.01.2026 17:13, Jan Beulich wrote: > On 15.01.2026 12:18, Roger Pau Monne wrote: >> The current logic allows for up to 1G pages to be scrubbed in place, which >> can cause the watchdog to trigger in practice. Reduce the limit for >> in-place scrubbed allocations to a newly introduced define: >> CONFIG_DIRTY_MAX_ORDER. This currently defaults to CONFIG_DOMU_MAX_ORDER >> on all architectures. Also introduce a command line option to set the >> value. >> >> Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed") >> Signed-off-by: Roger Pau Monné >> --- >> Changes since v1: >> - Split from previous patch. >> - Introduce a command line option to set the limit. >> --- >> docs/misc/xen-command-line.pandoc | 9 +++++++++ >> xen/common/page_alloc.c | 23 ++++++++++++++++++++++- >> 2 files changed, 31 insertions(+), 1 deletion(-) > > If you confine the change to page_alloc.c, won't this mean that patch 2's > passing of MEMF_no_scrub will then also be bounded (in which case the need > for patch 2 would largely disappear)? This was rubbish, sorry. Besides my being thick-headed I can only attribute this to the double negation in !(memflags & MEMF_no_scrub). I have another concern, though: You effectively undermine ptdom_max_order, which is even more of a problem as that would also affect Dom0's ability to obtain larger contiguous I/O buffers. Perhaps DIRTY_MAX_ORDER ought to default to PTDOM_MAX_ORDER (if HAS_PASSTHROUGH)? Yet then command line options may also need tying together, such that people using "memop-max-order=" to alter (increase) ptdom_max_order won't need to additionally use "max-order-dirty="? At which point maybe the new option shouldn't be a standalone one, but be added to "memop-max-order=" (despite it being effected in alloc_heap_pages())? Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 20 07:42:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 07:42:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208419.1520579 (Exim 4.92) (envelope-from ) id 1vi6NE-0001bz-Ts; Tue, 20 Jan 2026 07:42:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208419.1520579; Tue, 20 Jan 2026 07:42:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi6NE-0001bs-Qs; Tue, 20 Jan 2026 07:42:00 +0000 Received: by outflank-mailman (input) for mailman id 1208419; Tue, 20 Jan 2026 07: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 1vi6ND-0001bm-Df for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 07:41:59 +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 7d11f784-f5d3-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 08:41:53 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-47ee9817a35so27805625e9.1 for ; Mon, 19 Jan 2026 23:41:53 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43569998240sm27228205f8f.43.2026.01.19.23.41.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jan 2026 23:41:52 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7d11f784-f5d3-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768894913; x=1769499713; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=qpGZ4Zl02J19k/6EyNTEK+2X721BxWTLFU42awna7YE=; b=JH8F52JwqQsWgINXobJ78cPe+46Td/FVP3Shy2zCRc4rzrUQo9DDabCmQkR8GlI+/L QkzQpwFtup9keIE73k4ADhWlfWTm5GqFqrAJ52P9v/kX67KGS+c04DybLzYJUsRXsa6q jyJw+jMIXRZCCcLWrpWvKELKDie41I1fgnGxwqF0hIJ13JjuyGxmV6WB7NAyCWYWXaEO HT0+tFpqnP5VP90soIRxsTRItaZ2g7seXDs81dQfdNJS+yOkXMH12rvON5Tuj3/+yEyA 5w+wLH5bA0ZSqq+IPU4djOx3b4xRBaObicLJDKqYvISRCJq/KeZDB0xRCN0QL8wjw4iB bzKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768894913; x=1769499713; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=qpGZ4Zl02J19k/6EyNTEK+2X721BxWTLFU42awna7YE=; b=WAW8vukOcx2yvs/y+TRr5rdz+e39g4VJu5GmNJ2D+xhahVwxCako0BLfssr/4Ay3Ng 6mgHzF+7/uXGX9URYCztu8Oy/ncM18c3/dK0JnsxRv6KnBHELpZB0DFyvumQ+54Vw+55 JflHALM0SV5ExwVeBIOsXlSfQuLaAl8xNhbzbHSoQczHEUcAXWKVdU56fJ/VqMuTvXmY G8awRapcanmgFDFbvwCk2P2LSrT6Mgy6aPpAq5z0zhJjuQyzI9q1dauSa4u9T5ZnWRAH p6VUDsY9K9qsoXNWEXmncSP1uYNGWP9SfF+bQRfHT0zQ98m+QP+JNx7ptiU/ya0Ye8Ov cQ9w== X-Forwarded-Encrypted: i=1; AJvYcCWCuQo+5KvjTqonHVk/cIBY6zOCZpoka8qieoxMrfzCB9Nb0pMju+pUXo7vtFgPOYb0xUJMICzitn0=@lists.xenproject.org X-Gm-Message-State: AOJu0Yyn/fzlB6ba/2XwEjb8CBn5W15I2G9NLy2LZ9QETvDC4oMAhLXM nJtNwksCXemEChw918OqT4JDE0W4OckK2zPhPfI+Q0oCSUo5jqaCY6PNX3W3kWQDHA== X-Gm-Gg: AY/fxX64iRsZWEvVThnlkXZ88ylFLRoY+nQyWTyZ78/LL9q70hxqVueJs7RpWFipdDu bBTLNtCMY7tbLhJ0p/RPHXA6YqYd7W9rxGn/f6FKMiLaEoM7IgcguAz+tZrE1OPpa7KTHRW5bCz AJYjWGVz2IfpktQncLzNPJiuhN15TuMqstQj1yMOu6+FLXsXs52jhEwFXY5/PFE8jmnqgEMNgvI ivIXoymKqa/vLvs7YfagHiTpcWENmTA97Q6yDBS8vNkqKArQsIUiBON59eTcvCklJGG14ybz7x2 A5M1PLhqpbG5CS7QZdj2GHZsBgajbywJkabexVqP5U7aFzIJPvKQzV+LZpK+/Y8DGES4CSwMaIO sRmv9kkrVBuFeFYvvpP529RHLG8KYPC9SzwnwDbScQ0cMU3sqFOBHKJiZRSkZdIcq8Bw2PJ8hZK R9kxU8kZ8Id5NSW/ETVRS+r6+tuBMjjzhBFFK0TTa4YQhMBSV3S0WIvZY3uc9NSPIdpMr4bokkq UE= X-Received: by 2002:a05:600c:6388:b0:477:9a28:b0a4 with SMTP id 5b1f17b1804b1-4803e713cc2mr12693765e9.0.1768894912997; Mon, 19 Jan 2026 23:41:52 -0800 (PST) Message-ID: <32d0a9a2-89df-4e20-8f7a-0f069cbff11f@suse.com> Date: Tue, 20 Jan 2026 08:41:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] xen/console: handle multiple domains using console_io hypercalls To: Stefano Stabellini Cc: grygorii_strashko@epam.com, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Victor Lira , andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org References: <63c35c5e-577b-4346-b600-03808306177f@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 20.01.2026 00:23, Stefano Stabellini wrote: > On Mon, 19 Jan 2026, Jan Beulich wrote: >> On 14.01.2026 01:39, Stefano Stabellini wrote: >>> @@ -815,6 +831,11 @@ long do_console_io( >>> if ( count > INT_MAX ) >>> break; >>> >>> + d = console_get_domain(); >>> + console_put_domain(d); >>> + if ( d != current->domain ) >>> + return 0; >> >> This isn't atomic (as in: in a suitably locked region) with ... >> >>> @@ -830,7 +851,10 @@ long do_console_io( >>> break; >>> } >>> rc += len; >>> - serial_rx_cons += len; >>> + nrspin_lock_irq(&console_lock); >>> + if ( serial_rx_cons != serial_rx_prod ) >>> + serial_rx_cons += len; >>> + nrspin_unlock_irq(&console_lock); >>> } >>> break; >> >> ... this. If the focus domain changes after the check in the earlier hunk, >> I think you need to also return with no input here. Or you need to acquire >> the lock earlier (and then similarly in console_switch_input()), albeit >> that would then mean holding it across a copy-to-guest. Which technically >> is perhaps not a problem, but it leaves an uneasy feeling. > > I thought about it when writing this patch and I had the same feeling as > you. However, especially considering the other feedback, I don't see > another viable solution. Taking just the logic here, an option might be to re-check the focus domain once holding the lock, and discard the most recent chunk of input from what would go back to the caller if the focus changed. But that would come with its own new complexities. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 20 07:44:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 07:44:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208433.1520589 (Exim 4.92) (envelope-from ) id 1vi6Q3-0002EN-Er; Tue, 20 Jan 2026 07:44:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208433.1520589; Tue, 20 Jan 2026 07:44: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 1vi6Q3-0002EG-C0; Tue, 20 Jan 2026 07:44:55 +0000 Received: by outflank-mailman (input) for mailman id 1208433; Tue, 20 Jan 2026 07:44: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 1vi6Q2-0002EA-OG for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 07:44:54 +0000 Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [2a00:1450:4864:20::442]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e7b66342-f5d3-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 08:44:52 +0100 (CET) Received: by mail-wr1-x442.google.com with SMTP id ffacd0b85a97d-432d256c2e6so4264783f8f.3 for ; Mon, 19 Jan 2026 23:44:52 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43569922032sm29098015f8f.8.2026.01.19.23.44.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jan 2026 23:44:51 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e7b66342-f5d3-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768895092; x=1769499892; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=PzVQEOmqsd/5MICjHZcd3xDgzx/ha6IBOhbYlgwGARI=; b=RiGZCrp4cjlSkXsudwyHBOmICPfNA97w84ptsk+NmWDQQid2WSzPDGkI6/ywxXhc8c ZVfXw4Gw44PCeNmZWafERSIxjX04Mm1GyoFgonDY6h1vv2HguG5AjILo90B5afC/7jPw 9eCkqS5JsAIfQUbpwMMLPFayKBOfjzfmYATHpp6H8933/vcTviWHUWpCBzZcAVpm9YvH xoUCUFz9B88clOQZ7ms3roJzll9Immv/KF37StXrSTIC2mFJXToqKHyjTuLoI1yoYsMz RDhAs+6uuCNGIRlEASQP2An0m0PXa7cTT9A05+gd5CRXoCAxBMhdQ8dsMmly1C6kqite 7Rzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768895092; x=1769499892; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=PzVQEOmqsd/5MICjHZcd3xDgzx/ha6IBOhbYlgwGARI=; b=DZ9CC0NCfO6djM95j2I3MDUnB+/eJGox3e/O54OGOBrex3qcX2CpCHWr99outoEsm4 Z5cfWNIf9sWoaSjFPkV+wmiCZgBSua1ih2Z3NM3f8exL5MYHdT4SnYSEVyPNnGiiZALR u36xcjcrJt25esZJrWXd/zWnwTlltKFALYq1PTdliDMg/xisnufgyGHUzvo020zVEUuR 1QpiMl6afaZKyvrgDOUeyafhm9ffqPrX1hrq+J74vTEPD/tuR4o+6lRMYEL2NYeQkjcl P07JzQs9BAdquymBggaTk95uHMFVuuX48dNTQuYBSGJMCZrzviXVfzMICh5euUbGI50f 3A2Q== X-Forwarded-Encrypted: i=1; AJvYcCVQQoFPe/jPqK8sRgRpdh649wFPHMJqifMHAPfp9wCMdn0VpSIgwCixo8AwW16IikY6sJe9S9xL3DI=@lists.xenproject.org X-Gm-Message-State: AOJu0YxVSOMasx3nwe0kn6WhhP5L5oqAu7jkW+0x2z6OItgjWDsX85O7 FB3x1pW/Us9J298bbhv0PsJwvfpCdhDfEMd7Iqt9CPnK0QqypBJcrWEluO+i31Xq+A== X-Gm-Gg: AZuq6aIHsoMBUvguAS6f0uBUolHVb8gNfFqDJNin8DEj3C9P+bc3OfLyQHGQ8V/jNjh xmpanmF3IOVrp0VGPoAQjtHcegBfTSGPDOF1VhIsufDkM3+LR37S/OMe0mh0zcIrEDx5T2xocRw PaCBXSZxc5iw0QBRQKL17WqB6X1O9TnqZ2oUPfmRy14/6qggMdgoWME1epD85wkbIvsJ/XgfEMg yvBGpaEVDM1rxnXWTK43+KilJJPSYoOyo5FEprUI/xd4QZImJjHHSjMD/XB3jAqvS5LSYp/Gtgs dpymoG4BmO7+FLjcDO/Ve8FT20EorGWWEysdKs+0Eg1rAfPdAFbgpGBhOV4EAmHGVp0ghPdQqI8 u+SZLSaMF6qcCMTt87s4i6B5tN0qN4BWtXXuYuDwQplGnwQOQkVR0I2dsgRaCvNDBX2UUOkdn0D JMn76DpDipyaWdjq6bEdXwHlje4DSFqtuChIHEde3raSDosizcaJf1IrNgjC8Nqg2n9s5F4ntl3 nr9snrogMalBA== X-Received: by 2002:a05:6000:2303:b0:431:3a5:d9b8 with SMTP id ffacd0b85a97d-4358ff31af2mr1391230f8f.52.1768895091892; Mon, 19 Jan 2026 23:44:51 -0800 (PST) Message-ID: Date: Tue, 20 Jan 2026 08:44:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] INSTALL: remove unsupported XEN_CONFIG_EXPERT from documentation 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: <20260120071654.640873-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: <20260120071654.640873-3-dmukhin@ford.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 20.01.2026 08:16, dmukhin@xen.org wrote: > From: Denis Mukhin > > Remove XEN_CONFIG_EXPERT explanation and also correct information in > the entire "Xen Hypervisor" section. > > Amends: 37339ba9ef46 ("automation: Remove XEN_CONFIG_EXPERT leftovers") > Suggested-by: Stefano Stabellini > Signed-off-by: Denis Mukhin Acked-by: Jan Beulich preferably with ... > --- a/INSTALL > +++ b/INSTALL > @@ -25,19 +25,12 @@ Xen Hypervisor > Xen itself is configured via a `kconfig' system borrowed from Linux. > See https://www.kernel.org/doc/html/v5.4/kbuild/. > > -Note that unlike with Linux, and contrary to that document, you cannot > -look at Kconfig files, or the default or generated config files etc., > -to find available configuration options. This is because it is only > -supported (and security supported) by the Xen Project, to change a > -small subset of the options. Attempts to change other options will be > -silently overridden. The only way to find which configuration options > -are available is to run `make menuconfig' or the like. > - > -You can counter-override this behaviour by setting XEN_CONFIG_EXPERT=y > -in your environment. However, doing this is not supported and the > -resulting configurations do not receive security support. If you set > -this variable there is nothing stopping you setting dangerously > -experimental combinations of features - not even any warnings. > +Only a subset of options is supported or security-supported by Xen > +Project. You can explore all available options, including unsupported > +ones and those recommended only for expert users, by using `make "..., e.g. by using ..." > +menuconfig` and enabling `CONFIG_UNSUPPORTED` and/or `CONFIG_EXPERT`. > +However, enabling these options is not supported, and configurations > +resulting from them do not receive security support. > > Options recognized by configure > =============================== Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 20 07:50:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 07:50:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208446.1520599 (Exim 4.92) (envelope-from ) id 1vi6VD-0003up-0A; Tue, 20 Jan 2026 07:50:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208446.1520599; Tue, 20 Jan 2026 07: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 1vi6VC-0003ui-Tg; Tue, 20 Jan 2026 07:50:14 +0000 Received: by outflank-mailman (input) for mailman id 1208446; Tue, 20 Jan 2026 07:50: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 1vi6VC-0003uc-Et for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 07:50:14 +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 a6594d72-f5d4-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 08:50:12 +0100 (CET) Received: by mail-wm1-x344.google.com with SMTP id 5b1f17b1804b1-4801eb2c0a5so31409125e9.3 for ; Mon, 19 Jan 2026 23:50:12 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43569921da2sm27829302f8f.1.2026.01.19.23.50.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jan 2026 23:50:11 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a6594d72-f5d4-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768895412; x=1769500212; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Uo//KNX2NUE9m72eGstqyYNgDqAe3xJiyhPzdd7xWPw=; b=MwQOMMBEqeOz5r2778q9G/Gb9ve9EykhxCbNf4HsG5tSHQqCoQzeB0kj4l/XszUsvE tePXvFmzyPBtOKzBfp2rQ2RyhFq4jdI6T6STLGfQ9lHZSgwSZWK3gRhBUZs3iEJD7o7e VBmQ3w6xf3Z0DTtoNNWILzq91xVf3dCbWXSI8Cx3F4ZIUlk1fes7hnBSxB62h6jMfDa/ tVzrbk+nIzvtHj24aPuR+8jBsb3mBEQve92Z/DvJXMND5bDj14dCMOG1mm/T8IlY1fel WbD9oAmkCU1bYtaxxk2vCrj/blk4bhaZpGN9wNHcH6wd0QjYqHmInoZk7CNO6KQy84aN TRoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768895412; x=1769500212; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Uo//KNX2NUE9m72eGstqyYNgDqAe3xJiyhPzdd7xWPw=; b=JAAsAT1A65QEYaLCImDiExorGvghgHtQfEO40ypOCG0Ju3I2qXTrLNnFHSP6j+W38Y d8uF5guLVijlnA3CORuNTl6JjDZN5+fidsPAZvKy5IVvth7BAAynj9P/LnFMAoyKiepI J7sxSrDgwoSONOx86PAVHz6xMWe1EjcxVo+F63YKFgT+DAfbjKOkRJhy3FsqT9aDq38J O0E73WJgDLgegC7gWRdIyQuzn/PtdtDQPtmcEnkULagypdCF1A1lRTtHOflyNvkgYGwp QTDt4r/0yUePY8FCGIJ2K+hp7R794DePl4uddQ4RmkNnBmVLBpoaM7q3q7NXFgTYQgiM FmSA== X-Forwarded-Encrypted: i=1; AJvYcCVUopPmH6dmHg81g/k6qxcSfLKM3x3GDyCx1EmKcN5el4Oj4I3nWxpMkvgQQlsObkOhzpfKPoVslFs=@lists.xenproject.org X-Gm-Message-State: AOJu0YwXjpdrUkldTzWJzBKAqE7USQXt+8N+FrSOXseX3ViCpbCWrEMr 1XLUMGARMTYwzNH3cDpKtHABlNd/g3o/vxuhkEXmavKTcrYrMNeSVgBcFTfjoOOMXw== X-Gm-Gg: AY/fxX73TjJDPLy6aC+yBzQ15u0mwCkIvCIyrbiqn8PCwekNyCHA3FoUJ9a26ZeR7EY D/3zc7gMguNv1DB6eY+t/I6K0CgeRnbR/79LiAkBNA9MlwXtxTKt66KcSkU5qW5XyChfnFB+QPo OF4UxxUSPkPuFgzncjidezeZm2nIbLu0UFEQ511V5KW9/QImIk8QL3lvaDjguh8ptnLDjiM2Eh9 7+N/4J2j2jBD6L7Q1+1/Ffra65qg0Yc83rCVc8qpnk8XRXuSCgLtiwpAKhQqPfnUUvDu5CBu2Pv 9VQRmOPIua2GiAji8X0+PyXJTVE+4PYBWhvE29XIlU7Dpw6GzHCDkbN2hv9w39mpiLzVuhGW68f m4qGEiN7XxqgQq1yARl1GoY+LPDv0OAdKkgXGSMwHOig3W2Ciu++jHc5eTRm7TpbLHGYrjDL5VT bHMFtIJ2LuWVtDGr62r6x4+sCZXk8uJLO1MusUPpgToLdOUni3AbUMQcoBGcDUJUVAAwCoG9MaG jY= X-Received: by 2002:a05:600c:8b8c:b0:46f:c55a:5a8d with SMTP id 5b1f17b1804b1-4801e2efd61mr172869635e9.4.1768895411867; Mon, 19 Jan 2026 23:50:11 -0800 (PST) Message-ID: <14a32e1f-c5ca-4d1c-b54b-c565184bd6e7@suse.com> Date: Tue, 20 Jan 2026 08:50:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/intel: Drop more cpuid_mask_* infrastructure To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260119193901.1354905-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: <20260119193901.1354905-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 19.01.2026 20:39, Andrew Cooper wrote: > Despite removing references from the documentation, the Intel parts of CPUID > Masking were accidentally left behind and still active. > > Intel CPUID Masking is even more niche than AMD masking, as the MSRs only > exist between Nehalem and SandyBridge, being fully replaced with CPUID > Faulting from IvyBridge onwards. > > Fixes: 317051c2f032 ("x86/amd: Drop the cpuid_mask_* command line options") > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich Yet I think you also want to edit the CHANGELOG.md entry the other commit put in place, to not have that remain AMD-only? Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 20 08:51:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 08:51:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208466.1520608 (Exim 4.92) (envelope-from ) id 1vi7S0-0003Z6-KH; Tue, 20 Jan 2026 08:51:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208466.1520608; Tue, 20 Jan 2026 08: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 1vi7S0-0003Yz-Hc; Tue, 20 Jan 2026 08:51:00 +0000 Received: by outflank-mailman (input) for mailman id 1208466; Tue, 20 Jan 2026 08: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 1vi7Ry-0003Yl-P4 for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 08:50:58 +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 2269bb87-f5dd-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 09:50:56 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-47ee937ecf2so36450645e9.0 for ; Tue, 20 Jan 2026 00:50:56 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47f428b954esm291555515e9.7.2026.01.20.00.50.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jan 2026 00:50:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2269bb87-f5dd-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768899056; x=1769503856; 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=tvR8P1qhYUxOgFhUpo6UQFFziOLcP+abKFopPZ8Y4lA=; b=I+b7Uea8A3+d7PWrXw0NR4+per94K6se/+S+wCrHt7BnKMMlx0mbsVla4vL/wvqOlU ep6qFotVXTGh3x4cnTUIc67AUgLb+b/Ll+EbypYIxP2/bqlts4WPyhDLrt3M51arG1iZ 5PtZTvGjBbzp5vUMFI10PxUmGtAuOQG8X/iy1qQsvvWGijBoA0rL8K2S/rJ5lkKf6vsR Qkt7YYLSlaSxcahMRMki1kmJb7+Q/asag0u4s8xCfJqETviqaYJTXmOVrShkl636uhUt yKoji64C1rc1qRJmIFIrtOGntut8MJ9Zya1QKEoAn3WALr+/DNLlA+d5hPxppyRyLc+G XhYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768899056; x=1769503856; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=tvR8P1qhYUxOgFhUpo6UQFFziOLcP+abKFopPZ8Y4lA=; b=vvyW/D3wA6FDDubuS/oDTrAmMr0X3fGdEVgdx0rvrCmfsFueroVURA31rNRv78ab5E yYGvVOY7bmLJDlzkHUiprifmc09KzWmq1vWQ7Ftne0AXgrMDMzAUeUavSpiH0u7JBc3K 3W1V1WCKk91x7SB6TUNrZZj40eAcPIdkApvUEjm7pHkuXP9uxLdTCCbYUJKjQRcNpeyV AYlt3KNcU5S6hFCSsZcliZngjlPv3+ztuuY65KoUeX09GTJCqzDejtoc/0wng8fo4uc6 8A++rlde88A0ia8QGZ8LXBCi3ymUC4zdLhX6EvVv/iHoHgObSwxzBsJUGRb8Z3aJIypS INxg== X-Gm-Message-State: AOJu0YyM2I56TqoH8GcZpY/2I2+mWQ+VyPpRlYMIov7RjZ6/9JK5NJOQ DVb/Ymm6D4zsOf7wzP0rbn6TPSQSkeh8w504cWXSyYEdBbNJ27ExIj9F3wZH59I3CA== X-Gm-Gg: AY/fxX65kSWPrqvUi61lMzSTiZFV0k3Be2VgmBi5GmkH56cAefb/Kd6pj0kQMsxz3M/ BKFlRaTwD8leiTV3IIyNvX9cWIKIeUM9+fTjipPtSnjbchrRJ+TXfRcfhIP+2BBr8KB4VqVAoT4 mnQaZkL5e9bAk+me/zjXYdfbrwfu2P6jgGY1JKj940rp/jB7NIRRphQeDOj91Jv87sUjUw0/bWb XmBjJ0VBjWBIBCNe1g6u35BlzI9Wh/g0ODu/Y40Li2klx4p/Uks03bH4EvBq95QdxynFo5xEzPe XIWLs++QXRJuC6vElurOnKcY+3fS49TIojDA7XyiJnd6fe744VJ2eMcnoWRR54WJX1xBYxaYuRU ABQ0Zs1LCEG/oqRN0b9sCbDmFb3Zql1zzrEt0yX+kEcWwQ1gLa+7k7AvRvCkJhPWI09O1IZgEfD 82HuE0qJG4A4eKFCm1hiDf3xB1Ehp28dI0Mn7aakv+IXvVakh6tVOb5mKCqT3K1e1wD7kCPOpky VM= X-Received: by 2002:a05:600c:8184:b0:475:d9de:952e with SMTP id 5b1f17b1804b1-4801e530d08mr171832985e9.1.1768899055809; Tue, 20 Jan 2026 00:50:55 -0800 (PST) Message-ID: <380f4d96-4612-4369-8ade-8e9739929135@suse.com> Date: Tue, 20 Jan 2026 09:50:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() From: Jan Beulich To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , =?UTF-8?B?0JDQvdGC0L7QvSDQnNCw0YDQutC+0LI=?= References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> Content-Language: en-US Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 15.01.2026 09:00, Jan Beulich wrote: > On 14.01.2026 18:49, Roger Pau Monné wrote: >> On Tue, Jan 06, 2026 at 02:58:11PM +0100, Jan Beulich wrote: >>> stime2tsc() guards against negative deltas by using 0 instead; I'm not >>> quite sure that's correct either. >> >> Hm, we should likely do the same for stime2tsc() that you do for >> get_s_time_fixed(). Given the current callers I think we might be >> safe, but it's a risk. > > Will do then. While doing so, I came to wonder if there isn't a reason for this "capping". In local_time_calibration() we also have /* Local time warps forward if it lags behind master time. */ if ( curr.local_stime < curr.master_stime ) curr.local_stime = curr.master_stime; Which for the use of stime2tsc() in cstate_restore_tsc() might mean that indeed there is a worry of the delta being negative, and the desire to "warp forward" in that case. Whereas for the other use in reprogram_timer() capping at 0 isn't overly useful. By the time the value is used, it is likely in the past anyway. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 20 09:29:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 09:29:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208486.1520647 (Exim 4.92) (envelope-from ) id 1vi82n-0007rX-MX; Tue, 20 Jan 2026 09:29:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208486.1520647; Tue, 20 Jan 2026 09:29:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi82n-0007rO-JQ; Tue, 20 Jan 2026 09:29:01 +0000 Received: by outflank-mailman (input) for mailman id 1208486; Tue, 20 Jan 2026 09:29: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 1vi82m-0007rI-Uz for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 09:29:00 +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 728a3a81-f5e2-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 10:28:58 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-47ee3a63300so48348455e9.2 for ; Tue, 20 Jan 2026 01:28:58 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4358e24cef3sm3250356f8f.0.2026.01.20.01.28.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jan 2026 01:28:57 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 728a3a81-f5e2-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768901338; x=1769506138; 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=z8qtmLeEYJkg0E+FGU0YcIS6Kp7zsO5AEUqj66EA7/Y=; b=CIh83e62ta4p5xABIRLVLmiKEZkCiH4F5iSUxUhJZrlEtyKTCHZOMelRK+xqhw87Qi tjeb42PqrG8rs6lIYOqsyS9dhCJUqNcq43cNyIX5TkUcnvUhoGSMOie1SEymvcMGkouf 2vW2jldKl0aPsT7gWZcZZZnw6L+EV7PMdRDf8+8seNb6wrsFMkEnAKosVflLzKzN84KL yRUPYq4psGI7HYWfB7+2733YhtHyMhDOp5Gmfm97nhGulSc8+bcmMERC2Y2c47sVkMbx AytT082yEteFuBKr2uT0qLqNUx2mhTA4pvjaTHQJTJt4ls/Vtwh2qYBjS0qBwMKJF9rq xhdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768901338; x=1769506138; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=z8qtmLeEYJkg0E+FGU0YcIS6Kp7zsO5AEUqj66EA7/Y=; b=DPnaYSkXJV+HvDX0+i7Sv1UjSVclvOAHgGtsM4oboleizAyseJROzzrXYXlYIh1oGk XTlzGT803Uvm4vowNWIfSjgxGBITWx+73jmRSyIlasGz75zCbenVU1nmO4IhDICbBmyV cfeCjcg2G/2he3N5B7nq4bjc5m1kjBd6GNUb4qS/5vthMdHZenQ+eggBRxBHpeDpkB8E ZXcmtTdF/nqJJmJ1YDjs93rVTBb0mtLHb1LszUqT/ERPnlPcpHjchc+XvZDV6A3K6VW4 8p/bhokjltUQ2FtiGQD8/JgKhj5+JL2jvIsmqWLsoZnQo/Wrr3kFA+h9cvvajLs8ELKg L6RA== X-Gm-Message-State: AOJu0YwhKvgBZsEI7wiBOtOr+r4UIILZknMzjo/JwG3aFKA8xHyvT0Lr aOK4Fg/jU/JpQJcB+ku2k/KHLzzMlRd6NU69UmQ/QopnSr4yNCR56N/DdvBnx7jnHw== X-Gm-Gg: AZuq6aI6dU1+TAHwXJz/9edZ87IjFMY1nblVERfFGzjLP9pTNntXuL0DRqHXAWDQ/1Y bush6vEx2qEvHLwAW1Zl77+XiXwO6k9qaDfJT9aIMrPBiCsmVWT5T7OB41qv1FB57xtQsNzowrk 9USOl3Gude1NgRpANzfXfFpeTNqcCswelI7qyTExwLpiXpmlq0TgL4m3IBnDe/Neot5jqqMgpkh NvGTZlW7IOS5+hWhw6WNCTD1SdY/GJmGqju9XfTHxEDVGAuTAX167gR/8Z+i0aa6J1Z+pqvOzYI n4bban3Gam8UIFjCySracBhgesIeYgzc2YmHtKPUoiyFHWlkUBHcbU4um1oraFSJiTx+l9XqLWg RfDEHSPB6yrvNMl/nicyiTrnVrcyhoVQFyjKCSovue0GwQG0Jb+wuJ8C0calEVbjZYToC7yMJrt bMYRn3OzWlg3Dk2d0RoiaKqaQoB7Zi6RGLr+JgdbbhfUE+3R7AqqjlqBURPsO0cOU7LtVD4vYo2 HPuWI7cwwd0Eg== X-Received: by 2002:a05:6000:200b:b0:431:35a:4a7d with SMTP id ffacd0b85a97d-4358ff6f98bmr1831452f8f.58.1768901337694; Tue, 20 Jan 2026 01:28:57 -0800 (PST) Message-ID: <069c49f7-5150-47bc-885a-593970ffc113@suse.com> Date: Tue, 20 Jan 2026 10:28:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] x86/time: deal with negative deltas in get_s_time_fixed() From: Jan Beulich To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , =?UTF-8?B?0JDQvdGC0L7QvSDQnNCw0YDQutC+0LI=?= References: <66a53368-9c33-436c-858e-2b2d25ae84b7@suse.com> <1f539879-3083-41d5-a2c5-c63c9161f0bf@suse.com> <380f4d96-4612-4369-8ade-8e9739929135@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: <380f4d96-4612-4369-8ade-8e9739929135@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 20.01.2026 09:50, Jan Beulich wrote: > On 15.01.2026 09:00, Jan Beulich wrote: >> On 14.01.2026 18:49, Roger Pau Monné wrote: >>> On Tue, Jan 06, 2026 at 02:58:11PM +0100, Jan Beulich wrote: >>>> stime2tsc() guards against negative deltas by using 0 instead; I'm not >>>> quite sure that's correct either. >>> >>> Hm, we should likely do the same for stime2tsc() that you do for >>> get_s_time_fixed(). Given the current callers I think we might be >>> safe, but it's a risk. >> >> Will do then. > > While doing so, I came to wonder if there isn't a reason for this "capping". > In local_time_calibration() we also have > > /* Local time warps forward if it lags behind master time. */ > if ( curr.local_stime < curr.master_stime ) > curr.local_stime = curr.master_stime; > > Which for the use of stime2tsc() in cstate_restore_tsc() might mean that > indeed there is a worry of the delta being negative, and the desire to > "warp forward" in that case. Proposed new function implementation (easier to look at than the diff): uint64_t stime2tsc(s_time_t stime) { const struct cpu_time *t = &this_cpu(cpu_time); s_time_t stime_delta = stime - t->stamp.local_stime; int64_t delta = 0; /* * While for reprogram_timer() the capping at 0 isn't relevant (the returned * value is likely in the past anyway then, by the time it is used), for * cstate_restore_tsc() it is meaningful: We need to avoid moving the TSC * backwards (relative to when it may last have been read). */ if ( stime_delta > 0 ) { struct time_scale sys_to_tsc = scale_reciprocal(t->tsc_scale); delta = scale_delta(stime_delta, &sys_to_tsc); } return t->stamp.local_tsc + delta; } Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 20 09:39:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 09:39:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208501.1520667 (Exim 4.92) (envelope-from ) id 1vi8D9-0001NP-Va; Tue, 20 Jan 2026 09:39:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208501.1520667; Tue, 20 Jan 2026 09:39:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi8D9-0001NI-SK; Tue, 20 Jan 2026 09:39:43 +0000 Received: by outflank-mailman (input) for mailman id 1208501; Tue, 20 Jan 2026 09:39: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 1vi8D8-00018d-13 for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 09:39:42 +0000 Received: from DM1PR04CU001.outbound.protection.outlook.com (mail-centralusazlp170100005.outbound.protection.outlook.com [2a01:111:f403:c111::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f1a88de7-f5e3-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 10:39:41 +0100 (CET) Received: from SN6PR05CA0002.namprd05.prod.outlook.com (2603:10b6:805:de::15) by PH0PR12MB999113.namprd12.prod.outlook.com (2603:10b6:510:38f::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.13; Tue, 20 Jan 2026 09:39:37 +0000 Received: from SN1PEPF0002BA52.namprd03.prod.outlook.com (2603:10b6:805:de:cafe::d4) by SN6PR05CA0002.outlook.office365.com (2603:10b6:805:de::15) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.9 via Frontend Transport; Tue, 20 Jan 2026 09:39:38 +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.9542.4 via Frontend Transport; Tue, 20 Jan 2026 09:39:36 +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, 20 Jan 2026 03:39:33 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f1a88de7-f5e3-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HVMs8HfaZ99SakjTfkmAlts9+k93IpFM+h6bV07kMMGcqHoTK5p0T348/2Q4xjF+FzjtaCNm1z7oLUboua4lovxnONm+Vwsc/f/dZ1bJm4eQh2EjDwaEYW6PX1U1ifBWWQXXBxdEkqisxM6h0z//CIN2mGYluCS5NPyA+Od6cuuoGNYDrRZeNFa3DEhX9i8AAsDgXtpHJM6hnHLdIoUiRxzq79HgncrU7JD+p4pCZxd5N4XzD96sN3L4ZVgh/pUK2FfWqVRpxIKavlvQqUDsLyKmEPUbD/BNn5nD0mpGcnIbUZaeTubPqZ0Hn8ZKjmYSorxz6joqTqPCZzJtzDFaXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FrP7eMzlU98UJI3/6mC+q5/l7owwMFeEcveAnyG5A9g=; b=lZd/WlmmsF5pZff4PJ5BIqGqnTCKLth5S12og3oMn5H6w43W6OU86p7twMZDspkLayVLoKscIKIj4/V7AVJvsgatao34WfDLy0GCNkAzXqe0RbIaJthkB6hyMNy2Acf0YL1H8zrclEcirWw4oMGMRY08adGPM9H8LJ0sgQd0WdU175mYyWNHWkhriVlMXkNK81P0I23IP8Qwoyb15fNgll5HmMFzMxxDeSmWJfaozioLkpQ0fLnMiwz71KsClQLiIK22zhEGcmgcs80k4VeiK6Ugi4jIcmEi7Pc+lQZGrs3LjhJlwdvB7Im3LgCn9jSBudsN66PplbrJMqWVmICwyQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FrP7eMzlU98UJI3/6mC+q5/l7owwMFeEcveAnyG5A9g=; b=AC3aTi4863sG+p+8GmmJn3s4LFX/+s/sULqEmuksxzdHYw8dqo9A2W+WqgTHBszno71bw3uS1gt/05sZ5fDRkYQ+Jc7odnfWb64GJohZuiXMj3RlMjEtPprNiAQs7j6Aav8WNM+pWb8Pvh0i/KbUdY1WCvJNUGTBtE0GJk/Js+A= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v4 3/5] earlycpio: lib-ify earlycpio.c Date: Tue, 20 Jan 2026 10:38:48 +0100 Message-ID: <20260120093852.2380-4-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> References: <20260120093852.2380-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: SN1PEPF0002BA52:EE_|PH0PR12MB999113:EE_ X-MS-Office365-Filtering-Correlation-Id: 6e9521fa-ebb4-4401-2eb2-08de5807d32b 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?Yym73SRnm92MLJz9FTQra9nmDvySZ+dOtOMrm5fQsK++sUCpqLvHdg3QhKF+?= =?us-ascii?Q?oNy/W+VQsRlYbLB1mcGUTtAQCGUuvmJfqcQVLuKChOyd77dEq36Ux6Ui8QMY?= =?us-ascii?Q?X5KGWpI2mpmENdL4XeTOzUuQ+dH0DifboLVAyNTLl/iL209ePpyMljm1/0Lo?= =?us-ascii?Q?W+/o/WvqF1Rv3A2b4Mv6RuyarhbCxC3fH0hvCrKkSOBAdN8AE0ztzbkwGc8J?= =?us-ascii?Q?SnS+bGpOEvnCPp9pZ3wny47tpNgJR91YlfR/UZk5vKLGZUWww4CIeNElNbL8?= =?us-ascii?Q?TObix94ekKS7h73HVsfEYpqhRwTJP42Hnc4kNLC9s6/3JDRVk5IrRZzD65+j?= =?us-ascii?Q?iFEAS2uKvkV3V1JiNBjXavQ6QUV+8IbNJKmj0TIk2XpkRZt0gw9ZwR+3a9yx?= =?us-ascii?Q?HsGRXhvEgIXwQyUhhksjZVTGOvr+pvVQsixrDVeMkdQTZr/NjtHRv8WVj8wq?= =?us-ascii?Q?Rldjy+BRj7I3LBDvFVBSTLG9jbqfWgVlZv5RKJFAk5AQ9Vu6QLyl1qsypuJy?= =?us-ascii?Q?LvaqEVSsXIXJ8OitGFsV++xQvPDsWag8CJZzC9zovZ8+99gI13IX+JnDUjtv?= =?us-ascii?Q?HpNqKLoN3TJI/FVHLxIHOel/GzIyPAzOTucfvkJzZMr2yMwMyMxLBoV1Hl7T?= =?us-ascii?Q?lIpHBtNpGig+SugIXRxyHJSp4LLOedt7esbzLpsRO8qseHYwra0sXevRvCBh?= =?us-ascii?Q?S9W3I2lCIRyJCA/AnPd+pPIxpUB2G0+0I7B3QX4rX0RibfEdG20sZJvu7hpR?= =?us-ascii?Q?CslWczaCUzAJiANbN6pctmLPUMsm5muPcb8uGToGFL7xcSWKXFupgQ5rap1A?= =?us-ascii?Q?AfqFsogNLJoYOVokxI3Ugb6wEAxxz04UYD81AROKrihpPcH7LDwvXH2XZ32m?= =?us-ascii?Q?kuvDQfyqgGfQc7bsEMYm5lOOCtH1CkUWOB8CF4xRoh2Q8r26BmQwqo4VcDkP?= =?us-ascii?Q?u+PYHol+q+2p8IMi+6dPF6sGAjG5D51f1XRUp909qzilwwRVkBCZjGWCK6Kq?= =?us-ascii?Q?yi7eVZ8UTzSt57fsTkbOWabAGLTikuQzRoHqYCfXhLuEYduDSctZ1/7kJ1Nc?= =?us-ascii?Q?eREo20h2bAoUnSUfuwCMrNk5f2PjT0xGOlETm6+/N6mZNUu0TWGePjdCyq8K?= =?us-ascii?Q?/NX+rumOX6gIvWkc7x/fHhMw5sTJTxDYiggG8DM3vll/twN1b+Y3HyWXdHNX?= =?us-ascii?Q?Kwf7txEh/8LIHkKkbIS+jNR7MJ29ynMXrbGvFDGbYvYSZrT4nYoPswm2qqiE?= =?us-ascii?Q?6cO5P3t7FSeArg9NQ2JWRI6pgZqU6E0iBn23B6MGsf17XYi9GnuIG13PdWNW?= =?us-ascii?Q?7rZbjeiYyIpZ8ebhCYeafTdhEXq72nTkcXc/lElpz9yvnzx3rbPpeLmPqCwQ?= =?us-ascii?Q?NTY7YVm4MJdgvTbkWagb/nW0VW4c6vlojrT/PY6bhakYuPLJTZG8N8t1Y7/3?= =?us-ascii?Q?HcLAS+m4QdRd4xlHGyTu1VnLTgncI4KZ3p4j5j9c8GjezhrHMWwjUMxf/i/D?= =?us-ascii?Q?1AvI/fC4ewo1U/tRTK0jb3apUXE/U/B04reWMIzniygtaqvC/nLGFuXB/S72?= =?us-ascii?Q?ucEftGY1RTHmWtlRuUjd8iiz0pzNTN6mAqVYMqAUV1QtFkVJKjS2RgqW7o5q?= =?us-ascii?Q?g2scKDSsMbXHbdnc/QEzuOBnUTqfTOS+K/1Jtg5b+ljAImvcJnbD2IbyUCAw?= =?us-ascii?Q?p/GG+Q=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(1800799024)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 09:39:36.3395 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6e9521fa-ebb4-4401-2eb2-08de5807d32b X-MS-Exchange-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: PH0PR12MB999113 It's only used for microcode loading on x86. By lib-ifying it we can make it go away automatically when microcode loading becomes an optional feature in follow-up patches. Signed-off-by: Alejandro Vallejo --- v4: * Makes the lib-y target init-only --- xen/common/Makefile | 2 +- xen/lib/Makefile | 1 + xen/{common => lib}/earlycpio.c | 0 3 files changed, 2 insertions(+), 1 deletion(-) rename xen/{common => lib}/earlycpio.c (100%) diff --git a/xen/common/Makefile b/xen/common/Makefile index 92c97d641e..4fc0c15088 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -65,7 +65,7 @@ obj-y += wait.o obj-bin-y += warning.init.o obj-y += xmalloc_tlsf.o -obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo unlz4 unzstd earlycpio,$(n).init.o) +obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo unlz4 unzstd,$(n).init.o) obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o) diff --git a/xen/lib/Makefile b/xen/lib/Makefile index efca830d92..3b0137902c 100644 --- a/xen/lib/Makefile +++ b/xen/lib/Makefile @@ -3,6 +3,7 @@ obj-$(CONFIG_X86) += x86/ lib-y += bsearch.o lib-y += ctors.o lib-y += ctype.o +lib-y += earlycpio.init.o lib-y += find-next-bit.o lib-y += generic-ffsl.o lib-y += generic-flsl.o diff --git a/xen/common/earlycpio.c b/xen/lib/earlycpio.c similarity index 100% rename from xen/common/earlycpio.c rename to xen/lib/earlycpio.c -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 09:39:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 09:39:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208500.1520656 (Exim 4.92) (envelope-from ) id 1vi8D4-00018s-Nr; Tue, 20 Jan 2026 09:39:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208500.1520656; Tue, 20 Jan 2026 09:39:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi8D4-00018l-LI; Tue, 20 Jan 2026 09:39:38 +0000 Received: by outflank-mailman (input) for mailman id 1208500; Tue, 20 Jan 2026 09:39:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi8D3-00018d-K2 for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 09:39:37 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ee14f73b-f5e3-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 10:39:35 +0100 (CET) Received: from SA1PR04CA0024.namprd04.prod.outlook.com (2603:10b6:806:2ce::28) by DM4PR12MB5938.namprd12.prod.outlook.com (2603:10b6:8:69::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 09:39:30 +0000 Received: from SN1PEPF0002BA4D.namprd03.prod.outlook.com (2603:10b6:806:2ce:cafe::26) by SA1PR04CA0024.outlook.office365.com (2603:10b6:806:2ce::28) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.9 via Frontend Transport; Tue, 20 Jan 2026 09:39:30 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SN1PEPF0002BA4D.mail.protection.outlook.com (10.167.242.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Tue, 20 Jan 2026 09:39:29 +0000 Received: from xcbagarciav01.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 20 Jan 2026 03:39:26 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ee14f73b-f5e3-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=NY2A7IxOtkKgA3Hn1goGUiv468LLtofv+O0IGtneZ8Ut4PUtSCnE05EhiHrbR60QOpOSrEEiuEZmvdQVRh/sPUUwTN+uBni8Nwabr4pOQ2Q7r/65Zhtl/0tpieBNbNFKkDLzGCuIsLVFgliy3uU/OP+i8W+aI7AdBHPhdIwSqoV0qjwsl25QKKt2+ZnMxf+Uvsl6KXCvbFgQqGae03F/QRlnZnxgbemYCsRVPaMEjkvD++ixDj2grh7qJlQ9Q/tPSS8FxElTofSyEDPj8gU/beRC/lkYxzvJf7gYINFHhmMZVkvzcWvHIyKSu2l9LSYn6pyj4vDOwHRqaBK46I5VpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gTHEOSo1GinnsF6MJncYbd12zNvRUUcGZTNdnJimhAk=; b=DnJdIO+1tSFQvZ1sdJGwNSF2z3Q30peUNsNGyog9I/Ob6TSvy5xixiJEEySCCRROYJRaQ5AbFiPifv/SeBpy0jcNRVZNEVrU4NkjXG23ZxNSr8B4pjxwVlnLmOmLZY9iIzy2yIDrSFDPF9YysjzvQhpWAhFJENVIzf+Gh0NA521V/YphTEt1p0uzjoyG3KsdDheXGU1NupL7dOTvgSqnanLy3IR+VFuqBSkeGJc9WplYg4IVwyHlSMQhjeomnGEy1FoPgrid/i62/fDTJ+Sca6mNkB5YekizgfDQc7Xdwzh0+ZXzPzqpJclO9YbghaRpUyDp1MLSI+E7+r+//aomRw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gTHEOSo1GinnsF6MJncYbd12zNvRUUcGZTNdnJimhAk=; b=FPtPtRcfL7NQNgjfK1gy37kcN01zli9wEvN1V+9V3yM4iEZIsrDpnMkQ1EHVzC/vvC3xZdmHufU2kWXHNUutqzWZ7qv5SPyKynk0BxN7D3/WN8fh5cvn6Rb8siVXd5lefJ4n7K2K1fYOMR0xRhx4h7dRnMJhXFgFPTn6OCiv8yo= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Doug Goldstein Subject: [PATCH v4 0/4] Add Kconfig option to remove microcode loading support Date: Tue, 20 Jan 2026 10:38:45 +0100 Message-ID: <20260120093852.2380-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: SN1PEPF0002BA4D:EE_|DM4PR12MB5938:EE_ X-MS-Office365-Filtering-Correlation-Id: 536b3562-30a4-4616-693f-08de5807cf1d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|376014|7416014|1800799024|36860700013|13003099007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?u67qK3bVuUqqvIHaTJLlqrL5t6zdpZJ5nEpnO5sMkPwK5ne40KSJItvS+niE?= =?us-ascii?Q?ZGSnfjLXAHV7opQHU1MFDR9LWTxLBaPBulP7rbk0JH1rAMLAFzMKbyANwR/h?= =?us-ascii?Q?g71sB/y3p/84zEad+w3JYrhTZus33YRSpB7QetikquDKpeNiFSxRYR5bGo7a?= =?us-ascii?Q?uxEYTsQxZgabNBznjZyiZy78mz1IEh98bNZsk2Hgrfs1nC8RLpJ1vtvnfcsL?= =?us-ascii?Q?hBX7ikIEBckcKVur4BB7vubAU4NLUY8wFrKrxeDqNsW3v7BuZL1kzWsWhRyh?= =?us-ascii?Q?3+8kBi3YEahKDoXYJ4yZL/MI7tdV4nJhaMPR+nfsf6h2mKT73uBBwuLUPKEN?= =?us-ascii?Q?Fsr7nJ0ZAEbm2mtdS3TMMuv6bkmn5ik9h7APJHaW6C2SAEfTOBwVhL78jWm7?= =?us-ascii?Q?vvmVjAi4natWjHmvoR8O0DhuIbMejETLfuN9LUgR7Idt4NF4mi3ntafYS4eo?= =?us-ascii?Q?ogBkvSj5V4yyEdrxGIdI173eeGD67yQmMinroi5Fa9wo7LHYaxWsEAuQcxuK?= =?us-ascii?Q?VAlodH4eC81zFAofq6oq2UoKZnJ/+H4Hp1dxty39h52mK8PriwPmZ4nHEncy?= =?us-ascii?Q?+6GVDqcnJwHhKWciCXsSQSIlFjmf+1V1l6grZZlAj2InnDtbXaweFNrtxbSI?= =?us-ascii?Q?fayG2sPEtATXWiTMKuAI3o6sY3lgDjcaSNp3HhOJdVuqkW0a3VoMnDP4OhZ0?= =?us-ascii?Q?Wqzqqas85xtm+3LM/0/1a6KxQSvxm2GZ8jRceEPWvIWac2Wh3kcljqyz4lHT?= =?us-ascii?Q?uGqVmk0xDxZMqEemUckAq4j8/4XS0+F0LgfO0kav2rSGQ1qE05JA2g1CVri/?= =?us-ascii?Q?f6v569n4Dfzi/yXioy1bG9OEXxLz4KpZQ800oWuNW+eoNs4Q1LeLsYKh9uHN?= =?us-ascii?Q?zqpOW/pdKM/lsNIOi6QrjFLFXJS/KbrVAxuMRjr+5GaAcO6WV3+5OJdg18FM?= =?us-ascii?Q?TXocRWS69W29itjLBCw0A4RET/dUM5YcmUN+nEgtBl3jRSTp+aZPXL7hmcAq?= =?us-ascii?Q?N0IGURZRl6Jyau59XcBFSQ4/cad1y6uZYE+AdpfcRsZkow2OwOkcVJDHHI8X?= =?us-ascii?Q?g4S6zSIf/RiPnlmIBRLrO2ySiDODvVIHLjzZbsfDiIl1NlA7XyWDHEMoWoUg?= =?us-ascii?Q?wttRGJz9/B2xolTFhB1CF+M9dT0vrTTltVuNPZ5JKeECQfPO1mrYK8NoyQMz?= =?us-ascii?Q?U/QW1Fe5V90c71+RvzYs/BquCBtAUEPvI6V3txqP9IIl9D52vwBXYwwBqE4s?= =?us-ascii?Q?XemDrSEb66tCPtp8G/DPgYA4+lmz4ZXJwPdAEBRrE+UxPlXoraO6SdvO7TsZ?= =?us-ascii?Q?7Od7ewzXUBZ4Y+MKl/KYo9drFAcIM1YSyXfvdI+iMElqYNxrOl8T7HbBLHwc?= =?us-ascii?Q?uz+hcMPot5zf8Q92fZYWLuSSYMndrY9Qh1drtQouNPw7OseVegW4x/6hSYmd?= =?us-ascii?Q?XaeLVWRePdC5rWsOX7EAStai4rEIEIYdD4VviO0TQg2ICujJP9FfudgSDZRC?= =?us-ascii?Q?c2g9Ylux7t8YHwzBzV6RvbHI0dTEWPqiTyxOnWfFTIGMuPzBU31r2nFiFiS3?= =?us-ascii?Q?9r1GDSwuaXT+STtJqHSx4UGetH+X+eMUuqQ/KtbtXTRWwdr6kcpkhsFCZyX9?= =?us-ascii?Q?jBptBLinZH4m6IkYfpGY36jfFE6mYSMAP9dbxDRpz6kQxjdchuZ1T69lAAlW?= =?us-ascii?Q?ZdgTVg=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(7416014)(1800799024)(36860700013)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 09:39:29.5423 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 536b3562-30a4-4616-693f-08de5807cf1d X-MS-Exchange-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: SN1PEPF0002BA4D.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5938 Hi, v1: https://lore.kernel.org/xen-devel/20251112162219.226075-1-alejandro.garciavallejo@amd.com/ v2: https://lore.kernel.org/xen-devel/20260112150259.74535-1-alejandro.garciavallejo@amd.com/ v3: https://lore.kernel.org/xen-devel/20260113122109.62399-1-alejandro.garciavallejo@amd.com/ pipeline (red, but see below): https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/2272127547 Pipeline failures are on ARM builds, so clearly unrelated to this. Also has an eclair run on allcode that shows no new failures in earlycpio.c. The only dependency here is patch 2 going in before patch 3. Everything else can be freely rearranged. Cheers, Alejandro Alejandro Vallejo (5): x86/ucode: Add Kconfig option to remove microcode loading xen: Allow lib-y targets to also be .init.o earlycpio: lib-ify earlycpio.c docs/misra: Remove earlycpio.c from the Eclair exclusion list. automation: Disable ucode loading on AMD's analysis run automation/gitlab-ci/analyze.yaml | 1 + docs/admin-guide/microcode-loading.rst | 2 ++ docs/misc/efi.pandoc | 2 ++ docs/misc/xen-command-line.pandoc | 7 ++++--- docs/misra/exclude-list.json | 4 ---- xen/Rules.mk | 10 +++++----- xen/arch/x86/Kconfig | 14 ++++++++++++++ xen/arch/x86/cpu/microcode/amd.c | 16 +++++++++------- xen/arch/x86/cpu/microcode/core.c | 15 ++++++++++++--- xen/arch/x86/cpu/microcode/intel.c | 11 +++++++---- xen/arch/x86/cpu/microcode/private.h | 3 +++ xen/arch/x86/efi/efi-boot.h | 3 ++- xen/arch/x86/platform_hypercall.c | 10 ++++++++-- xen/common/Makefile | 2 +- xen/lib/Makefile | 1 + xen/{common => lib}/earlycpio.c | 0 16 files changed, 71 insertions(+), 30 deletions(-) rename xen/{common => lib}/earlycpio.c (100%) base-commit: 7b3e1b4e848d34c9a5b6634009959a7b9dd42104 -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 09:39:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 09:39:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208502.1520677 (Exim 4.92) (envelope-from ) id 1vi8DC-0001ce-7c; Tue, 20 Jan 2026 09:39:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208502.1520677; Tue, 20 Jan 2026 09:39:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi8DC-0001cT-2f; Tue, 20 Jan 2026 09:39:46 +0000 Received: by outflank-mailman (input) for mailman id 1208502; Tue, 20 Jan 2026 09:39:44 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi8DA-00018d-5y for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 09:39:44 +0000 Received: from CH1PR05CU001.outbound.protection.outlook.com (mail-northcentralusazlp170100001.outbound.protection.outlook.com [2a01:111:f403:c105::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f2aaf39e-f5e3-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 10:39:43 +0100 (CET) Received: from SA9PR11CA0008.namprd11.prod.outlook.com (2603:10b6:806:6e::13) by IA1PR12MB9468.namprd12.prod.outlook.com (2603:10b6:208:596::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 09:39:39 +0000 Received: from SN1PEPF0002BA4B.namprd03.prod.outlook.com (2603:10b6:806:6e:cafe::ab) by SA9PR11CA0008.outlook.office365.com (2603:10b6:806:6e::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.11 via Frontend Transport; Tue, 20 Jan 2026 09:39:17 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SN1PEPF0002BA4B.mail.protection.outlook.com (10.167.242.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Tue, 20 Jan 2026 09:39:39 +0000 Received: from xcbagarciav01.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 20 Jan 2026 03:39:38 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f2aaf39e-f5e3-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=htC+sJj6Cmsp4Hp2NUbcaGay/tkGty6VehoB7XwVge+ojzdZqYiGUuoLTC4r9jwRxbkH6Oug7PlCXWXy2SQ4BvjmbKPQrFKqm1FSqXBDzk/oYkE5/PT3DptfGpySgyS7D3cRAy50uPQ0KePZC1LCcyBam+HiZdBL1whNBgd6KRQvlPA5QsTe1UvDP+my+oEoCqITPpA/Fv0ZvUgM3IFeSQoHbg5hfemtqDFEyLcAna7bjk07PvE2EZ2HgZI2AaEtKNVeVJ6kceRS+fCP1srKjMyXSvUxDD4AQW98tJZJtkIPkl3FtjsUgpKLh/2730mOetYKZclOA/MyERyKajuPYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=cQefSA2WZMHjaT2qx78VZVCjljpc/SfUnwaK++kIFs8=; b=S8M0N4qTbkgwT4fhKBm6vsY9ztenbz7LUanotY+yophbb9Q33KUEW9tY13tXRetUQTAIaxv8zCTCUqc0j4ClXzx9g3Ea/OgPqeVqr3VetoFiiiOsQ3WD3yfggkqbKydBsGWJ4M8T4nR8meRyhc4YZBUrT58FckKRfRg+EqE5jQBvW0hci2+2saAbHkGT270qsIWYg5CTcmLmdzt4U6+OwzMoTU2OZTmfyoQK+eTiHNBYUMFzB/riIWE0Ak8MSehOR2pa/NkQJqzF51R28Ls7t9OFNBSNZv5Hn2qfaDkKIJNXYdRp9UgOjMOTcR24b4glsxyjdMbBCMpik7ooHsN1ug== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cQefSA2WZMHjaT2qx78VZVCjljpc/SfUnwaK++kIFs8=; b=KAzzK0SSEO9n1U3tw7CiTyODKTm6uGxN7/iAYclxNxuYjnvoftB4NTpy30QwOL91kcYTsHesljCNroMLsmsWYxreXOAWvM2B2JV8pUW0KDjAuvMHxWiWCUMdsWog7Vixq1uB9fsT3eWfmVpe3Bcz3sP/QEXMntRryQRm5K0zElM= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 , Doug Goldstein , Stefano Stabellini Subject: [PATCH v4 5/5] automation: Disable ucode loading on AMD's analysis run Date: Tue, 20 Jan 2026 10:38:50 +0100 Message-ID: <20260120093852.2380-6-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> References: <20260120093852.2380-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: SN1PEPF0002BA4B:EE_|IA1PR12MB9468:EE_ X-MS-Office365-Filtering-Correlation-Id: bc0f563f-4085-42c6-19e0-08de5807d528 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?dZx7MDoNscdnszO0NZn6VnIQgQ3aySeoNY7AkNQeHcAVWXWVcyYchUgNSaf8?= =?us-ascii?Q?MjNxX8pg064EV4zeY335E74rULsaywKFc6agpfhAQcN1QyTlYpclvmmfTh/y?= =?us-ascii?Q?kltlm2rqgRHVoNnnGigiX9SAHkIsdmg4VUdV2gC13LekqPovQ7ITAtOcaNf2?= =?us-ascii?Q?0Sr9W+V3yIxOeLQWxgqdeQYF0TCWbuMg4GJIGtt6QEJEF6VibfaZk3FcN+y2?= =?us-ascii?Q?yHeo3EXtDRuxd0Pwhdnm6MFh9r7qvEcpZhz10jZFLn04W96ssnhWziCXNSAD?= =?us-ascii?Q?FTa46NNKfaHuuEI6D1E7MUWW2/TdQkl+8ulc+FY4ZblBGLcDkDUuoDoDHEIe?= =?us-ascii?Q?rnsu9aRDEIonpg4r7WOdXT9XXSXa1Hteo/W8IjYZLXLzbpZhMVnnAuuVaKcV?= =?us-ascii?Q?l4vE8Vll3/pUHT1ktEa3aD9h6GBcZ5+5hcQo8bZNlN0tKj+GTQd12tfykbwx?= =?us-ascii?Q?Dl0h0GvtXRAw4Jga/g4Cg4UgwtLNgTEN8R9O94rjm3Pkmf/6VKt1JAiRFc1c?= =?us-ascii?Q?jgxvGPOtrqgXO+1jTTZ4FwV7GAkoFdAnhlKELt/uz0DFslQoK2UK+1zoo1jA?= =?us-ascii?Q?CCHbJ5xUX8syb1/W0cyVquzP6aoFLOwFCka8LWkEv2lAgsinjwZ4yhGrelyQ?= =?us-ascii?Q?B2aE2ZUJw1vLfr+Javx0ZpzfNkSQYO++6ECX7OPcklEJEhErg9ed6/KbwYbY?= =?us-ascii?Q?O9tsRYqgW9jLm/93aFyQi63RE9JvgWKvNY7hXE9sJrY3hmHV/XtrQRmy9Crz?= =?us-ascii?Q?KWCVj22WABF1t4CFxOSBfVeSfFmFoQnVruSevrfYgz0EyY8TEkBm3ww0Kgf6?= =?us-ascii?Q?eGc9BcjvIR73s6Uxh4PwhdemVOtws+kawoQdiIuWUbGMdLQViMxFmkDs/JNT?= =?us-ascii?Q?KNHK1FfVCn983/GKLi1gVuH9vETP4kSYH2Ym44YB14dAiv+Rb16WAX6Ei3Y3?= =?us-ascii?Q?BiRRPv/ZABAVZrFFVvCjcAK8pwgfwbvJmvwz6dsj/Y413Zxmb6ToSeZpkucP?= =?us-ascii?Q?RrFSPiuSmpnMJg6fOK9HIh1YVndY5vw3rpXW9Xu/4HvtHLJc6/0zGq7ugvIb?= =?us-ascii?Q?MLRvHQtV14fMXVx2DBBuh03NEbjnJOCNkrrSagLP3Itlk8ZHvnwGpZhfkYGi?= =?us-ascii?Q?mqiEuD/9qBTz1/xOC8/8rHJ3fSw5sGFmcYbyEwi9vn9gEvcCKEs6DdkzI6xk?= =?us-ascii?Q?9fTVEqwIXf0E1P2fE/ARn0XerWi8Rb2ebOW16JKOOD7yFsoRiOeaaSn+wCEn?= =?us-ascii?Q?z1RwanBfjcAdTL2E5qPl6/OQGT49jF69ljpVV40rl/1IkgrGJAk/8RsxgxqO?= =?us-ascii?Q?cQsykEdMuVtc3+zl1VACOusq4kSYrhHeT+rJV9HSso+e6KvlVhdbJnKPkUgm?= =?us-ascii?Q?XW6X3Y8lJhQWqlElO2gx2fTV+Sy1hby1DMxzP7s68lN1YbasPmmdv4gIuqUT?= =?us-ascii?Q?QZU8DYxT3U+aluHFWY3kNdwvoeA4CPvr+WedHIS5I6/ZXhCzWle2lhTl344Q?= =?us-ascii?Q?S2g/0jKro+CU5J7vEWkLDZNs5wz3HAC4a/oxCXfWu+vxgShSlfE/GtianJ8F?= =?us-ascii?Q?fbT4Eh1NEjCbuVEnERNySbn7JCeErhCRgoOk8OltXIGhihe65FsiRxmiTOay?= =?us-ascii?Q?H2PDVyHbFr9gGIwe0Z1h4jjuzmuv6NLAhtbPewW3U4FovUVO0iSbeLgBmJfU?= =?us-ascii?Q?GEzgKQ=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 09:39:39.6648 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bc0f563f-4085-42c6-19e0-08de5807d528 X-MS-Exchange-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: SN1PEPF0002BA4B.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB9468 Explicitly set CONFIG_MICROCODE_LOADING=n Signed-off-by: Alejandro Vallejo --- automation/gitlab-ci/analyze.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/automation/gitlab-ci/analyze.yaml b/automation/gitlab-ci/analyze.yaml index a472692fcb..b3395e2da7 100644 --- a/automation/gitlab-ci/analyze.yaml +++ b/automation/gitlab-ci/analyze.yaml @@ -93,6 +93,7 @@ eclair-x86_64-amd: CONFIG_DEBUG_LOCKS=n CONFIG_SCRUB_DEBUG=n CONFIG_XMEM_POOL_POISON=n + CONFIG_MICROCODE_LOADING=n rules: - if: $ECLAIR_SAFETY when: always -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 09:39:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 09:39:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208503.1520682 (Exim 4.92) (envelope-from ) id 1vi8DC-0001g1-Je; Tue, 20 Jan 2026 09:39:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208503.1520682; Tue, 20 Jan 2026 09:39:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi8DC-0001eO-CY; Tue, 20 Jan 2026 09:39:46 +0000 Received: by outflank-mailman (input) for mailman id 1208503; Tue, 20 Jan 2026 09:39:44 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi8DA-00018d-ME for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 09:39:44 +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 f2befd7e-f5e3-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 10:39:44 +0100 (CET) Received: from SA9PR11CA0025.namprd11.prod.outlook.com (2603:10b6:806:6e::30) by CYYPR12MB8964.namprd12.prod.outlook.com (2603:10b6:930:bc::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 09:39:39 +0000 Received: from SN1PEPF0002BA4B.namprd03.prod.outlook.com (2603:10b6:806:6e:cafe::ed) by SA9PR11CA0025.outlook.office365.com (2603:10b6:806:6e::30) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.11 via Frontend Transport; Tue, 20 Jan 2026 09:39:11 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SN1PEPF0002BA4B.mail.protection.outlook.com (10.167.242.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Tue, 20 Jan 2026 09:39:38 +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, 20 Jan 2026 03:39:35 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f2befd7e-f5e3-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=V5NMX1xnixxWayE76remcjpt71HDW8/LcsPnN3dKvHYmsYYE3dh1zmOZH8iMIzhUMOxdRJHGYVxXWYzsU/XxYTVq9sMYEiI6+OuWrBg1BOyn/doy+Gkb1/ONtiTTQywirF7UFA6WR3Ms3s0ZhozuAD6ZV4ldmq5wwR+GB0pNYltwqElPmVN1lYWt/9JpqvEr+58r5divHpDGmGfCxBO/Ez3IFJzQ+M6f33zF+ueE6eOAilfybo5k3JteGe/Q2k0pqNjDveULJzZH15byidWKK3O4Q+C7NisvpEZiAHsR3mbLAAUMOSeXi+RgE+JDUq+P7XI6vCp0RSsTLJd5fDby8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Zf2eRnQIuwJBbc97LjKnM7yuRHPy483HO3xHLUQdgl8=; b=TBZknqjaYeSwZ80AU5KI4NA70Rel4niwqDBghzkZhZYO62zCt5M/Bq/+GDyIt4GGmvDJr7qs4hzEOFtXeS/UDNDkWLzOZL0/6y0t9Aw398V0icI0HuF9hITnXCw6H2p7LH3HUtCTAky8fk7ZO+b8eH1bZhNqKzDefjvE2EHAsJsqsPFzUi/jgUfpqChSUV2uHd9OUYkFwZIqxetKisVVeJV4CnqCh/Ej3H3lPpwkYK02DhA6fgGEwcgu+Ru82C3kDhP212VtgKjV/AHsAaPbV2czKC8RTPODYbUX7u7w0kc7GhzUiYUNuIPn2S58kGnFydPryH7gP+3GJHOBBfcVTA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zf2eRnQIuwJBbc97LjKnM7yuRHPy483HO3xHLUQdgl8=; b=OruciJ9/8OkKTbbXD0Uvw00MvrWkgvlt17S6UC+z19IYutFXb0qEj6Va6DFb+W8eq6BORArIdLJyagdDTpor3mkta6v4StltzPv23pSnn6cPkZXH4U3eUhuS+avDka0SZqY1EVLvE1dgUIpJpqtiyblszZJIYKipXcJiqEt3pww= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list. Date: Tue, 20 Jan 2026 10:38:49 +0100 Message-ID: <20260120093852.2380-5-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> References: <20260120093852.2380-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: SN1PEPF0002BA4B:EE_|CYYPR12MB8964:EE_ X-MS-Office365-Filtering-Correlation-Id: 990ea3d9-9690-4cfc-b9f5-08de5807d45c 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?WCOgcKAOaHBANW35uwwUeAfvGf2eUB2iHoBaQyNByRDGpVJOIxA1WoB2EeF+?= =?us-ascii?Q?VH2cXESU/1JleBTtMQ0LPZjTAQ3/YI1tCKn1f0lIn28KyDkMvIE6HZxTQf4f?= =?us-ascii?Q?rMt66TtRGwk2o0nEkb/6YVza+aMl+A1oQeS7DUPSDdH6Mim7R6bZKybK+M6Y?= =?us-ascii?Q?HVj09h9SFW5AOoOc/tQcDQrrQt8vbwMPtJD+nsA1oYIA0bgrhykzSNzB67AQ?= =?us-ascii?Q?GbPT0smF0Dr0zLeq6SxbJNnbxvsB98MiqSi28ZBbogJJn/Yg+mJuAm5iPoHC?= =?us-ascii?Q?ZLoRxa9favmvbZ5CvoTnWMHP0pibjAFZ6S02zNzrB/HTRfvDNVvXD7BeP1+i?= =?us-ascii?Q?9lVPBCot9xMQ3XTrT0NJ1pxKAw6uW1vwmySNq5OmQnr7utTIqSeY5ulq8SZB?= =?us-ascii?Q?tr4oFcKb9GX2um0IWOvLumqHwe0FxELZNDDtp+2dPsIxCThYYhudUJGS7TFj?= =?us-ascii?Q?LRXCa+pqg/z1KF7i77sJWC6lx85ikxojpc4BqclX4spmS47KWngY8UydMFHl?= =?us-ascii?Q?mwNdhIWMfxESiW8cI+nFLdZwnzZoKCsoWOD6YyxMXJYceWAGruw+dS51r/Dc?= =?us-ascii?Q?ny7slKtGTSRClEeQvZqcuvpfjE8v47x6Hsmeu/6HQLNMtPrRyWCHNVCQ1ppF?= =?us-ascii?Q?3oaI51OGHVP6CeZZkyoMtDLMDBziMskXGH/6grsqUiTb+0NXfOybA6RJv3H5?= =?us-ascii?Q?KiBIra/xjJ2GFEX4MNP8Q5Bdu7617AK5Ly27prm2hBqZ32cdgM/7nh+nYW/R?= =?us-ascii?Q?XXIMziZUpzZMkD4cjrJQb+ZAhQDaXYXdqRU1odHNyWZC9b29uNebFAjk/NK1?= =?us-ascii?Q?+NLFVfcnjFg9BBodSsqlrZZowv2A9zKkHz0QXSgOpUkOhbBQJigYTYqbjoKW?= =?us-ascii?Q?I67KT8lfjkTExBwcU5ePaE2DO8TtDNbWs7XNHRZ8dYBIe83Es5oSP3jdxyci?= =?us-ascii?Q?wOcgF0HPvVMRRDCD237Kufvu8bdglSNfP+BheT9Otl+CSphnUt5RhZIzdrw+?= =?us-ascii?Q?CswLVscWuFZvjbVokYyujuDjQ5A8+JL2X/PiuQTss5HX7gCpfqNrIcY3EfjX?= =?us-ascii?Q?eWGQZh3oarpETM0batH6kA0o0qcoMHWsbuq1NAeZvUj1JA9pVmU48Slaia3r?= =?us-ascii?Q?5kIvikuQ9MxDvYd+vTiX+HE1sVosfbdTUKovDG7nHQ6QXwt9H6rGeRn2mgWq?= =?us-ascii?Q?HgRZSWRUKhw2S8E7MosYaQCisB9yaEaApTSgLCn4c3Hux/DZcjDGIYOk1XkJ?= =?us-ascii?Q?C7NusFazyWJskyjy5BdRvjAENp6c1m4mu7LbofcSjsUeubbNvGwVHKIFkuow?= =?us-ascii?Q?oTDYFvYugVBxgSvP044keexFNW/Xfb0CTjdWXu/evY+Sbrh3MHFIXkLQNkg1?= =?us-ascii?Q?Th55iDhhJh0+MHXugrn2lItyI33jiWHu8VYugVcbCPLUFoYXG6TBzYgcfrk9?= =?us-ascii?Q?t4n3QfH1z0Q5YLFSpp4zgDMIQC25JSXE0T51lHqWjGXW0HIP4RoTrxlS0bU/?= =?us-ascii?Q?IHPHaBGcjhX95uknCPfeFEi7YqEDPYzaoIRwXYraY7pJcdfrvkAB8A/5lnDZ?= =?us-ascii?Q?osYiLOMydyrFF8Nev99uKOeEXDnzvXD82Qd72rXBkPQky21Az1e9LPFFnvpT?= =?us-ascii?Q?qgUdzKUz7bVysjF+LlxZLze0z8W4+99+fzaFO8ooLqbAsOwSzfGtxuU399l2?= =?us-ascii?Q?/GCYuQ=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(1800799024)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 09:39:38.3398 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 990ea3d9-9690-4cfc-b9f5-08de5807d45c X-MS-Exchange-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: SN1PEPF0002BA4B.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8964 It's clean. Signed-off-by: Alejandro Vallejo --- docs/misra/exclude-list.json | 4 ---- 1 file changed, 4 deletions(-) diff --git a/docs/misra/exclude-list.json b/docs/misra/exclude-list.json index 388397dd3b..273e24db4a 100644 --- a/docs/misra/exclude-list.json +++ b/docs/misra/exclude-list.json @@ -121,10 +121,6 @@ "rel_path": "common/bunzip2.c", "comment": "Imported from Linux, ignore for now" }, - { - "rel_path": "common/earlycpio.c", - "comment": "Imported from Linux, ignore for now" - }, { "rel_path": "common/gzip/*", "comment": "Imported from Linux, ignore for now" -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 09:39:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 09:39:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208504.1520691 (Exim 4.92) (envelope-from ) id 1vi8DD-0001sP-73; Tue, 20 Jan 2026 09:39:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208504.1520691; Tue, 20 Jan 2026 09:39:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi8DD-0001qm-1x; Tue, 20 Jan 2026 09:39:47 +0000 Received: by outflank-mailman (input) for mailman id 1208504; Tue, 20 Jan 2026 09:39:46 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi8DB-0001NH-Rt for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 09:39:45 +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 f0253c26-f5e3-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 10:39:40 +0100 (CET) Received: from SN6PR04CA0094.namprd04.prod.outlook.com (2603:10b6:805:f2::35) 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.9542.9; Tue, 20 Jan 2026 09:39:32 +0000 Received: from SN1PEPF0002BA4E.namprd03.prod.outlook.com (2603:10b6:805:f2:cafe::c3) by SN6PR04CA0094.outlook.office365.com (2603:10b6:805:f2::35) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.12 via Frontend Transport; Tue, 20 Jan 2026 09:39:32 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SN1PEPF0002BA4E.mail.protection.outlook.com (10.167.242.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Tue, 20 Jan 2026 09:39:32 +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, 20 Jan 2026 03:39:29 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f0253c26-f5e3-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TxbpohVAYrDNQcg1dDDpEI3oWWHnVfhsVuHFkA8qT/V0156o6walgPUUmMAL5LohRm2nf7gu5z6hTQrG24cH4UyxeTHoTtBVdZtp5lBu7DLl16wZiDzdhuhxOT111r2NpKiSa5vofXdXMH0FawvIw/8TUZyGlpxzqHECTyhASvoW98Kp/Tu3YsNBPuChkBRkgWpmhgJDYd/yIT6KcjgxXMTBjJlLTAlEavjJPpN+IIpyu574LLp9m8ADlOkPYqXqgo/rUhQs2IBbYLVGUaLyrt4RF/gZLnD8ZBiyvifMD/RN6r/JsoLi1Vdxamco4mftjCF5/Zl5X4wkKc31+mFXpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=S7JUwPOWscttGNrjWYKOuXxkeyKAiYXYN+soRUeRFk0=; b=syZS5AFahm9lRz6g/CQqgoCHQuJsOlwQjvuxNOVPonwkpcamhXXwKm7eMQkwAYYpSWXgwAkH53Xt50KGMfnhn6ew+7CFtjfYHqtIxMQDsoXJ03zszNnOnIHaGdujIg0mwxnKRkIF+i4bg+nyeRJUqRWXEa8jmrH5pYwUv4gLj60LvabKlxNicSRG+v7kO5UAPvLffwt/cdN7Eu6GXjBX0TZcdLZHnwZ9+6hlWrHEdPzd39qyU02T7e+Zz887C88HUSGkjp89nHYlkfpZPCAwvACoXXL5HZlGB+YB+pd35l+rBEwVn0Oy9cNHe5drnhbJCy6nuCud2TOMiZn0L4JT3g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S7JUwPOWscttGNrjWYKOuXxkeyKAiYXYN+soRUeRFk0=; b=aAT788GrX+qxs+2s3ZH12Zmqw3pfc1jEf6JdyyjG7LBLaXRFq8MHzH4rqEOrmpD2ufLygJWTRS+2RvuewyJ7fp+HpSCgu5Y1cLArXyKe5AkheJ2JIgeVbreXy6acB/NmxrpgcsMsgpdsNCFwIQ4KbonS7fUnlU16bmnLnPOMlWg= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Subject: [PATCH v4 1/5] x86/ucode: Add Kconfig option to remove microcode loading Date: Tue, 20 Jan 2026 10:38:46 +0100 Message-ID: <20260120093852.2380-2-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> References: <20260120093852.2380-1-alejandro.garciavallejo@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: 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: SN1PEPF0002BA4E:EE_|CH1PR12MB9574:EE_ X-MS-Office365-Filtering-Correlation-Id: 3b4ea7b1-5b2b-46e8-7ca2-08de5807d09c 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?RjNET005SmJTektNZWY5RGhsVldyd1ozSkM4K1ZOWEZ5TFVFT1YwUnZPU2ds?= =?utf-8?B?RGZ4d2paaW10YU52WkVZTm52YnJva2ZxTEtTQk53UUlxemJxN1FoNDNESWxx?= =?utf-8?B?SDZjN0NkRi9kNHNUVnpReDgzdUF3bUkvTFZkcURVdFJGT0pkMVAwaWZyK2dC?= =?utf-8?B?cnJ4VFJ6QnNvMmNEK0h2Smg5ckJkdmZQWGhJMlFvblRzZmpEUW9IYVJSd2Iy?= =?utf-8?B?OEhjdkRsU3ZyT0o3TUdjKzAxT0lLUk9lUTRRTUtkZXJHd2U4SzAzcDQzZTJ6?= =?utf-8?B?czVTMkpxb1J2U3hPTWw0T2p4TFpicFY0ektnend5dDd6UktWUVhpVG02SjU4?= =?utf-8?B?WVgvMjFBYWwwQ3l5VFZDSmI1WHNMQi9pc09Dd1ovQkNMM0xnY0czWjN4SThp?= =?utf-8?B?K1VhOU5LaWg4YWFJR0VwTmdGT3MyUjVIcGpsSnRWazN3Vm9Ta3pZRC9SZmxT?= =?utf-8?B?TkRFT0I5cnhMcEZxcFVadFdycFZtNC9XTXpZRFNQbU8xRGZsZjhMRlk0b010?= =?utf-8?B?SmMxZ1JIb2dmdGRpL0tOK1dLS1VWa3lQVWtMcjdKdlVHSzJUT3FGU0VMVVJC?= =?utf-8?B?bWNwYUpxZWFxa3U0N20zY0RON3RVU0Q3NHQ2RllWeGR4blR5UFpNVHNscWhm?= =?utf-8?B?N25USVpLVmw1MkI0TjRUZSsveWp1N0NFK2MvVUlVMUdUQzdQUm1tNVNMZ1VP?= =?utf-8?B?bllnWXlta3MwdkF0a01oS3I4YmNTRENFZjI2WTlRYTF1Qm95Z0xhOWRLVDBs?= =?utf-8?B?TEFDSXVISXJpREdMcXpqTmUxZ01EWEY4cDU5NzdXZUFlclo2bDhMUmQ1L05y?= =?utf-8?B?cWNCV2tTcXNpMksvdGpWYmdVbjVFUWVVZzVGK2VwbG9aYVJKTTVibjhGOXZm?= =?utf-8?B?Rk1zSjl5alFCaktjNkYyeGdGMlp0WlEvSDhLS2tNOStLK21NSjJTa0V6Vy80?= =?utf-8?B?UTNIUkl3UGo1My9MYjlQTnJrbmxDWDhGUGRzeG1IOGJ1QzVUclFzTW9hREh1?= =?utf-8?B?dm80S3ZETG5ITURWTmtONkRDa3AvWWhEak1ubmMyTndmc3JpTCtlZXAvTU1J?= =?utf-8?B?RGxmYzlGbHRTMXhQcmYxeHR6ZjlYV0lnQlVvWnhjdUtnTlY2bFBEVFh3cDl0?= =?utf-8?B?UDNFcTlNREg3R01pZnRoN3ZsMEQrT2F5RHVPRlVWSXpQL2tuVzFYN2tvUnIw?= =?utf-8?B?U2tIcGN6ZGQwMnZxSDRIcmdkcU51cUFOam9PeXVScHRwSllieE5VUWRXcEk3?= =?utf-8?B?S2U5dm1jQ3V5Z2FiR3JWTGRVL0c4bHoyN1FOTU5YVnZFSGQyVWpZeTQzUGhm?= =?utf-8?B?YStocm4zTHgwUGNsREs2VEVQVmduYnM3alZLdy9nTkN6Zm5oMUdIbVJweTBQ?= =?utf-8?B?WnFxUVRUVXczMlI1RW14VHhjZ0ZhdGVUV1hqeWdWcng3SlFQUnpHTC9ZZzF5?= =?utf-8?B?WnVCZ3JUNnFMTEFGdFdGY1BPKzR5bURiaGEwZzR5T3ZVZkFpTGtGRHg2VUo5?= =?utf-8?B?bGVaOVcvU2lwdkdlZzl6SC85TUpQTTc5Rm4rRmRVaFNoRGRNd2Q2QTlYVHpB?= =?utf-8?B?alRGK2g4bFBhM0czVlU3MXNNdVo2cmNBOXRZT3dvcnpTY21XRlVtSlZLZUxv?= =?utf-8?B?L2tVdXRiS2FrTGU1OFBKZE4zTjZKczVZWHV3RlpiSjFjUDNOZjZTYzFqUUhB?= =?utf-8?B?VzdZYzQvaTNDUHUzdVFsRTBnRlk0bFJaLzRNaGJ3bVhJeUhKcVBhTUt6cW9Q?= =?utf-8?B?KzdKMThSSk5oMU5WUVFMSExhN2hYWnRSMjdWMFpvekVDT2ZkWkltOVROWG5x?= =?utf-8?B?Tk56SFAxUzNMbFJ3c1lzR2ZuT3NJNTJiL2hCbEI0NjVSUVlEc2VLV0dXWFVh?= =?utf-8?B?aVpCUnhZZmVxZ3crSzQyd1JtTmlNMUwrMG52c0J6Q28xQmk4RDRISnNVTm8x?= =?utf-8?B?MmgwWE1QeVk4NzlyODRxZzhzdUI2aXptdGRaeUV3aldPK1VBQzdJMitkWHZC?= =?utf-8?B?NTV0V3pKc2tlaTZDaVY3YVI3bVBKUi9QcnBCL0R5blF2TEZRL2lWcTRyc0Q4?= =?utf-8?B?UEVSWjhVblh1UlcvQnBlalUrRTgxWDBEck53bHZoQkhaWDFxTFZBeDY1cXho?= =?utf-8?B?LzhSb1AzYitBRkYxSk92WVVMUUhscDlSQm41b0hiSzZGaE1CY3h6M2ZLQm5i?= =?utf-8?B?TWZWMGFKWThkSEVBWkF1Sk9IejR2bGdId1lZb3NWZS9UaDBmY2phSjdHNHRh?= =?utf-8?B?VVdhcnVPWGN5a2RtWDVHaVhkRnVnPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 09:39:32.0511 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3b4ea7b1-5b2b-46e8-7ca2-08de5807d09c X-MS-Exchange-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: SN1PEPF0002BA4E.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PR12MB9574 Amend docs to reflect ucode= command/stanza depend on MICROCODE_LOADING being set. The new MICROCODE_OP() is a conditional setter for the microcode_ops struct. By using IS_ENABLED() there rather than ifdef we allow DCE to remove all statics no longer used when microcode loading is disabled without tagging them with __maybe_unused. Signed-off-by: Alejandro Vallejo Reviewed-by: Andrew Cooper --- v4: * Minor spell fix in commit message ("rather") * efi.pandoc: terminate sentence with "enabled". * xen-command-line: State applicability as first line. * reorder cpu hooks. * MICROCODE_OP() comment * MICROCODE_OP() moved next to microcode_ops * Re-arranged platform_ops to turn them into smaller hunks. --- docs/admin-guide/microcode-loading.rst | 2 ++ docs/misc/efi.pandoc | 2 ++ docs/misc/xen-command-line.pandoc | 7 ++++--- xen/arch/x86/Kconfig | 14 ++++++++++++++ xen/arch/x86/cpu/microcode/amd.c | 16 +++++++++------- xen/arch/x86/cpu/microcode/core.c | 15 ++++++++++++--- xen/arch/x86/cpu/microcode/intel.c | 11 +++++++---- xen/arch/x86/cpu/microcode/private.h | 3 +++ xen/arch/x86/efi/efi-boot.h | 3 ++- xen/arch/x86/platform_hypercall.c | 10 ++++++++-- 10 files changed, 63 insertions(+), 20 deletions(-) diff --git a/docs/admin-guide/microcode-loading.rst b/docs/admin-guide/microcode-loading.rst index a07e25802f..148bc8559b 100644 --- a/docs/admin-guide/microcode-loading.rst +++ b/docs/admin-guide/microcode-loading.rst @@ -23,6 +23,8 @@ TSX errata which necessitated disabling the feature entirely), or the addition of brand new features (e.g. the Spectre v2 controls to work around speculative execution vulnerabilities). +Microcode loading support in Xen is controlled by the +``CONFIG_MICROCODE_LOADING`` Kconfig option. Boot time microcode loading --------------------------- diff --git a/docs/misc/efi.pandoc b/docs/misc/efi.pandoc index 11c1ac3346..8198a7f063 100644 --- a/docs/misc/efi.pandoc +++ b/docs/misc/efi.pandoc @@ -104,6 +104,8 @@ Specifies an XSM module to load. Specifies a CPU microcode blob to load. (x86 only) +Only available when Xen is compiled with CONFIG_MICROCODE_LOADING enabled. + ###`dtb=` Specifies a device tree file to load. The platform firmware may provide a diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 15f7a315a4..0eca489b7d 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -2751,9 +2751,10 @@ performance. Applicability: x86 Default: `scan` is selectable via Kconfig, `nmi,digest-check` -Controls for CPU microcode loading. For early loading, this parameter can -specify how and where to find the microcode update blob. For late loading, -this parameter specifies if the update happens within a NMI handler. +Controls for CPU microcode loading, available when `CONFIG_MICROCODE_LOADING` is +enabled. For early loading, this parameter can specify how and where to find the +microcode update blob. For late loading, this parameter specifies if the update +happens within a NMI handler. 'integer' specifies the CPU microcode update blob module index. When positive, this specifies the n-th module (in the GrUB entry, zero based) to be used diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index d5705e4bff..61f58aa829 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -331,8 +331,22 @@ config REQUIRE_NX was unavailable. However, if enabled, Xen will no longer boot on any CPU which is lacking NX support. +config MICROCODE_LOADING + bool "Microcode loading" + default y + help + Microcode updates for CPUs fix errata and provide new functionality for + software to work around bugs, such as the speculative execution + vulnerabilities. It is common for OSes to carry updated microcode as + software tends to get updated more frequently than firmware. + + For embedded environments where a full firmware/software stack is being + provided, it might not be necessary for Xen to need to load microcode + itself. + config MICROCODE_SCAN_DEFAULT bool "Scan for microcode by default" + depends on MICROCODE_LOADING help During boot, Xen can scan the multiboot images for a CPIO archive containing CPU microcode to be loaded, which is Linux's mechanism for diff --git a/xen/arch/x86/cpu/microcode/amd.c b/xen/arch/x86/cpu/microcode/amd.c index 71b041c84b..c1ab6deb4d 100644 --- a/xen/arch/x86/cpu/microcode/amd.c +++ b/xen/arch/x86/cpu/microcode/amd.c @@ -561,11 +561,11 @@ static const char __initconst amd_cpio_path[] = "kernel/x86/microcode/AuthenticAMD.bin"; static const struct microcode_ops __initconst_cf_clobber amd_ucode_ops = { - .cpu_request_microcode = cpu_request_microcode, .collect_cpu_info = collect_cpu_info, - .apply_microcode = apply_microcode, - .compare = amd_compare, - .cpio_path = amd_cpio_path, + .cpu_request_microcode = MICROCODE_OP(cpu_request_microcode), + .apply_microcode = MICROCODE_OP(apply_microcode), + .compare = MICROCODE_OP(amd_compare), + .cpio_path = MICROCODE_OP(amd_cpio_path), }; void __init ucode_probe_amd(struct microcode_ops *ops) @@ -574,7 +574,8 @@ void __init ucode_probe_amd(struct microcode_ops *ops) * The Entrysign vulnerability (SB-7033, CVE-2024-36347) affects Zen1-5 * CPUs. Taint Xen if digest checking is turned off. */ - if ( boot_cpu_data.family >= 0x17 && boot_cpu_data.family <= 0x1a && + if ( IS_ENABLED(CONFIG_MICROCODE_LOADING) && + boot_cpu_data.family >= 0x17 && boot_cpu_data.family <= 0x1a && !opt_digest_check ) { printk(XENLOG_WARNING @@ -614,8 +615,9 @@ void __init amd_check_entrysign(void) unsigned int curr_rev; uint8_t fixed_rev; - if ( boot_cpu_data.vendor != X86_VENDOR_AMD || - boot_cpu_data.family < 0x17 || + if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) || + boot_cpu_data.vendor != X86_VENDOR_AMD || + boot_cpu_data.family < 0x17 || boot_cpu_data.family > 0x1a ) return; diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c index dabdb95b4c..efaf808f1a 100644 --- a/xen/arch/x86/cpu/microcode/core.c +++ b/xen/arch/x86/cpu/microcode/core.c @@ -58,7 +58,7 @@ */ #define MICROCODE_UPDATE_TIMEOUT_US 1000000 -static bool __initdata ucode_mod_forced; +static bool __initdata __maybe_unused ucode_mod_forced; static unsigned int nr_cores; /* @@ -104,6 +104,7 @@ static int __initdata opt_mod_idx; static bool __initdata opt_scan = IS_ENABLED(CONFIG_MICROCODE_SCAN_DEFAULT); bool __ro_after_init opt_digest_check = true; +#ifdef CONFIG_MICROCODE_LOADING /* * Used by the EFI path only, when xen.cfg identifies an explicit microcode * file. Overrides ucode=|scan on the regular command line. @@ -162,6 +163,7 @@ static int __init cf_check parse_ucode(const char *s) return rc; } custom_param("ucode", parse_ucode); +#endif /* CONFIG_MICROCODE_LOADING */ static struct microcode_ops __ro_after_init ucode_ops; @@ -469,7 +471,7 @@ struct ucode_buf { char buffer[]; }; -static long cf_check ucode_update_hcall_cont(void *data) +static long cf_check __maybe_unused ucode_update_hcall_cont(void *data) { struct microcode_patch *patch = NULL; int ret, result; @@ -613,6 +615,7 @@ static long cf_check ucode_update_hcall_cont(void *data) return ret; } +#ifdef CONFIG_MICROCODE_LOADING int ucode_update_hcall(XEN_GUEST_HANDLE(const_void) buf, unsigned long len, unsigned int flags) { @@ -645,6 +648,7 @@ int ucode_update_hcall(XEN_GUEST_HANDLE(const_void) buf, */ return continue_hypercall_on_cpu(0, ucode_update_hcall_cont, buffer); } +#endif /* CONFIG_MICROCODE_LOADING */ /* Load a cached update to current cpu */ int microcode_update_one(void) @@ -658,7 +662,7 @@ int microcode_update_one(void) if ( ucode_ops.collect_cpu_info ) alternative_vcall(ucode_ops.collect_cpu_info); - if ( !ucode_ops.apply_microcode ) + if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) || !ucode_ops.apply_microcode ) return -EOPNOTSUPP; spin_lock(µcode_mutex); @@ -678,6 +682,7 @@ int microcode_update_one(void) */ static int __initdata early_mod_idx = -1; +#ifdef CONFIG_MICROCODE_LOADING static int __init cf_check microcode_init_cache(void) { struct boot_info *bi = &xen_boot_info; @@ -734,6 +739,7 @@ static int __init cf_check microcode_init_cache(void) return rc; } presmp_initcall(microcode_init_cache); +#endif /* CONFIG_MICROCODE_LOADING */ /* * There are several tasks: @@ -898,6 +904,9 @@ int __init early_microcode_init(struct boot_info *bi) printk(XENLOG_INFO "BSP microcode revision: 0x%08x\n", this_cpu(cpu_sig).rev); + if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) ) + return -ENODEV; + /* * Some hypervisors deliberately report a microcode revision of -1 to * mean that they will not accept microcode updates. diff --git a/xen/arch/x86/cpu/microcode/intel.c b/xen/arch/x86/cpu/microcode/intel.c index 281993e725..dac464961a 100644 --- a/xen/arch/x86/cpu/microcode/intel.c +++ b/xen/arch/x86/cpu/microcode/intel.c @@ -408,17 +408,20 @@ static const char __initconst intel_cpio_path[] = "kernel/x86/microcode/GenuineIntel.bin"; static const struct microcode_ops __initconst_cf_clobber intel_ucode_ops = { - .cpu_request_microcode = cpu_request_microcode, .collect_cpu_info = collect_cpu_info, - .apply_microcode = apply_microcode, - .compare = intel_compare, - .cpio_path = intel_cpio_path, + .cpu_request_microcode = MICROCODE_OP(cpu_request_microcode), + .apply_microcode = MICROCODE_OP(apply_microcode), + .compare = MICROCODE_OP(intel_compare), + .cpio_path = MICROCODE_OP(intel_cpio_path), }; void __init ucode_probe_intel(struct microcode_ops *ops) { *ops = intel_ucode_ops; + if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) ) + return; + if ( !can_load_microcode() ) ops->apply_microcode = NULL; } diff --git a/xen/arch/x86/cpu/microcode/private.h b/xen/arch/x86/cpu/microcode/private.h index e6c965dc99..77ce816c1a 100644 --- a/xen/arch/x86/cpu/microcode/private.h +++ b/xen/arch/x86/cpu/microcode/private.h @@ -8,6 +8,9 @@ /* Opaque. Internals are vendor-specific. */ struct microcode_patch; +/* Aids dead-code elimination of the static hooks */ +#define MICROCODE_OP(x) (IS_ENABLED(CONFIG_MICROCODE_LOADING) ? (x) : NULL) + struct microcode_ops { /* * Parse a microcode container. Format is vendor-specific. diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h index 0194720003..42a2c46b5e 100644 --- a/xen/arch/x86/efi/efi-boot.h +++ b/xen/arch/x86/efi/efi-boot.h @@ -295,7 +295,8 @@ static void __init efi_arch_cfg_file_late(const EFI_LOADED_IMAGE *image, { union string name; - if ( read_section(image, L"ucode", &ucode, NULL) ) + if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) || + read_section(image, L"ucode", &ucode, NULL) ) return; name.s = get_value(&cfg, section, "ucode"); diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c index f8eca48170..2ac9fc2d96 100644 --- a/xen/arch/x86/platform_hypercall.c +++ b/xen/arch/x86/platform_hypercall.c @@ -317,8 +317,11 @@ ret_t do_platform_op( { XEN_GUEST_HANDLE(const_void) data; - guest_from_compat_handle(data, op->u.microcode.data); + ret = -EOPNOTSUPP; + if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) ) + break; + guest_from_compat_handle(data, op->u.microcode.data); ret = ucode_update_hcall(data, op->u.microcode.length, 0); break; } @@ -327,8 +330,11 @@ ret_t do_platform_op( { XEN_GUEST_HANDLE(const_void) data; - guest_from_compat_handle(data, op->u.microcode2.data); + ret = -EOPNOTSUPP; + if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) ) + break; + guest_from_compat_handle(data, op->u.microcode2.data); ret = ucode_update_hcall(data, op->u.microcode2.length, op->u.microcode2.flags); break; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 09:39:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 09:39:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208505.1520701 (Exim 4.92) (envelope-from ) id 1vi8DE-00023s-1V; Tue, 20 Jan 2026 09:39:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208505.1520701; Tue, 20 Jan 2026 09:39:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi8DD-00021n-Mx; Tue, 20 Jan 2026 09:39:47 +0000 Received: by outflank-mailman (input) for mailman id 1208505; Tue, 20 Jan 2026 09:39:46 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi8DC-0001NH-7H for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 09:39:46 +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 f1076146-f5e3-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 10:39:41 +0100 (CET) Received: from SA9PR13CA0140.namprd13.prod.outlook.com (2603:10b6:806:27::25) by DS4PR12MB9587.namprd12.prod.outlook.com (2603:10b6:8:282::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 09:39:34 +0000 Received: from SN1PEPF0002BA51.namprd03.prod.outlook.com (2603:10b6:806:27:cafe::27) by SA9PR13CA0140.outlook.office365.com (2603:10b6:806:27::25) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.9 via Frontend Transport; Tue, 20 Jan 2026 09:39:34 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SN1PEPF0002BA51.mail.protection.outlook.com (10.167.242.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Tue, 20 Jan 2026 09:39:34 +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, 20 Jan 2026 03:39:31 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f1076146-f5e3-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VfkDOqS31wCdYnTpShbnmcVOXFOlJEA7cLPAHAcYDvDA6/uoZ17Q4iVY0ECN9qxYDZp6AoS7/b1Rv3D0bbnWhMjXJShx5iNHZumqYXLUKtJtY0ADLzt0y1A7knynwE0NBVtqbpZo9W0aYay6gOeS9ti1aKAfXOJGhhMDbRl9UQh/ps6jSIPVlp8kqOET/tKmI8fIxOge2PE2A0HwutMrVLuwYV10HaHfPh08zt0OxLCXAKz2qwJqTbGhbPnxdA7z6+BxzBfR+TlHrRf9wELuIVm5/vyySL1hcEdMHVxMjWtPmYN+L0qea6kNxHLxBViQ0q7E/4aWsRMdQohMNLQuIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=62HqEqk8utj2zzHdDMhP2cMsxApDUfMNx+Y6Knj7xvY=; b=EJabZY8Rr85CDe2gGdcU6wKNsUowQQc4v1u3TB6gB86XTlTDGUAhfn0TLKAZf38jKgYIbPe6d2MmfBPwI0O/L9QBHtxFY/4AOd2UlEaxbk9MIIZ4+Mhaeq50IZMZiO9/PY35bh5wOW8eT9hysQqLya4Fbp6FAb1aN1p1UUzdPCWYN01cVQvpSRELSt3qfYyC89uVnNlom1hCn5dxHGTU9vnmPFw8i4uL4ZB91Emyh0FvhGk0QA1y6Fe+g+WxytfwhwtfPlxh3pCnXdAaINl1hlel8D1jSTWSqpKbW+iXAcauXMQwpclXkX6Lms7YZTbBZ7mi7lrgirvpymIZH9/Xqg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=62HqEqk8utj2zzHdDMhP2cMsxApDUfMNx+Y6Knj7xvY=; b=T7NVIjuloptUwn1HTPAvA6rY9dc1UkW3MNPE9Z3LXGsI+LEihoxiVdu+BmLpCxx665AoSkk32YJ9QSf8gQQX9P9UZ5pRGIhtRJHjHLGpjLNA+GYAU6Xu1nl1xTe48/y0fYvlXoWBeJl783g838qNwXXB+iEbzwu37hlX42dgpFU= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v4 2/5] xen: Allow lib-y targets to also be .init.o Date: Tue, 20 Jan 2026 10:38:47 +0100 Message-ID: <20260120093852.2380-3-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> References: <20260120093852.2380-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: SN1PEPF0002BA51:EE_|DS4PR12MB9587:EE_ X-MS-Office365-Filtering-Correlation-Id: 3562909c-cbe8-4789-65df-08de5807d1db 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?uMQIP/TVxaSLtVRj0dZi4wkb3WGbj4JQK4Ab6TZq9nHTKMom0CHilrbTu/Vo?= =?us-ascii?Q?yc3V18CEuXtsyZcsfrL1L/3UY+amhxZofOZ+YxaSvI9riqtI9D4GLKg5l3nX?= =?us-ascii?Q?i3uhz5nqQMwp0bdcKM7Jy6UOIrdKi5kXaDK9VUBHP12JRDkYzfqMGEpcoQ44?= =?us-ascii?Q?/5jX1sBK9nco4GuI3HUSyBH2X7lPp08GNZQ9mrOC8X8N/+tfURjYL862tqLK?= =?us-ascii?Q?S6JUTbomMeV/6HHBz9DsxH4mBZDQgdsO+/+E0Qqyd5BZABxPN4VtVbzm4du6?= =?us-ascii?Q?m+nKXqoIwzd7CRZ46kpsm7v5IJMYWj7R3C/ACuZPBuUrI7asBbhXzBc2dyxb?= =?us-ascii?Q?XPHCmpOWoNU4dp/J88CgU49U9glrUPYV0P8S+Ercd0RT9PPZ8w6md1f2He6Z?= =?us-ascii?Q?bcK3RRS3Zp7cJRwBSb1GX9IR3zIyCLah/Q/PLfK7N5JIBe1msm2ehRkLX9Ef?= =?us-ascii?Q?JG7MwRSMjnn8zjrQl3Nqc1Got+qnCaZyEJBYEYVGPF242+dKxyPPoiNXcbWN?= =?us-ascii?Q?lxAaeJZ52nqBj+D91ydDFAZpRzUiNLGU496gDTew9CtE+XExZGnDm0T4qMDR?= =?us-ascii?Q?pRA3W3m8OwzFyDq9n/9tU1VYjD6bJqZlfNeHJtL/6DHW27IANeuMuu5fob8c?= =?us-ascii?Q?Yvjuge28FPmb8UAuIeYF608s+BjniLALH5KDQM2aNxwaBtC/VRCP2xvPfIKp?= =?us-ascii?Q?A23vOSOo20r8kX/Rwl3AwaSi5rSxpIbm0FyZMmx6GGyozoJSTmF5NEzxtQxH?= =?us-ascii?Q?da68oah43Sp+RhFC/2yUOLuT8hY1d+xLqLz4RSRheh9Uk/ViAi9J9GaU0yQH?= =?us-ascii?Q?/aDsM6LRB76v+sg0TB7Q9NNTXTJU36vsBS12xQGs3Wmh5ITQWYxpfpeVCnX7?= =?us-ascii?Q?FIRPeNM+bFl2l4aKf2nXJ6JKO6ZxLN6pwEYbf6Kk/E0UFvHtb6cOfTubwoXd?= =?us-ascii?Q?h+F48DrO757mATR495y+G3jW1//nTetb6Co4/c80A1+LNDJ8zK+8Q5JqGwSK?= =?us-ascii?Q?e1SMSX6VfN+x482A3gBJnJEC7192vhme9TZ8VzlPG8X8XwRWb8H1gVs9mc8Z?= =?us-ascii?Q?BjpLkBw5fIbUh6xDaUnpMM/jGDIl4kahxI7n+qo/1mGwgznNPjlAPUkDBHG7?= =?us-ascii?Q?edeoMF3VWxdbHQba/QPftVtWQMEeQ//Xp9ZVdE7G/95aFq0MpaijxJqTAvI6?= =?us-ascii?Q?bf5cLUWTVQ3mImZDMxyQf4x04K8usjX9ihn5aATn1t85O0xDYJXpf0Na0qGs?= =?us-ascii?Q?2oTJ1vFG4MuEZ1pQNYOFP/fLHd6KVEEHuhN7s5EdPM3NWvLHlTodeheYu7GV?= =?us-ascii?Q?b/TQ6M1SLLQeTrm+iwnCQCY+6j2accDQ1NF+GfjLzWySA9TOrBYa9U69eXZY?= =?us-ascii?Q?1uqUK1fl8INyOpeQoW5huZxgH0DiGbiEoKi9L4lvoKfPkaONnrCMlyVSzPmn?= =?us-ascii?Q?QT0BwyyX5sEcWyAoX16lPRc+tt31v4wJiRc/KoP7Nm2fmYUTwWm/asQ2y3xv?= =?us-ascii?Q?idpz25lsSJxgQRZtniTEzaxIzLTV1mW6+Gt/3XFeo/nxr9aHLUPSV+1ywDWi?= =?us-ascii?Q?vnRw/WXpoVBy+agfVjdpNZwpJLwnPutLZ0X3AbhoViE9ZyU5ppCMUGdsN4w1?= =?us-ascii?Q?Hon/meMt1QICCBDtLu/k23RG9oj9iAR/VFkpKxrk+zk8K1IfTs5nEMJoqcVM?= =?us-ascii?Q?qcFcaA=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(36860700013)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 09:39:34.1409 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3562909c-cbe8-4789-65df-08de5807d1db X-MS-Exchange-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: SN1PEPF0002BA51.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR12MB9587 There's some assumptions as to which targets may be init-only. But there's little reason to preclude libraries from being init-only. Signed-off-by: Alejandro Vallejo --- xen/Rules.mk | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/xen/Rules.mk b/xen/Rules.mk index 2b28d1ac3c..2c3f836c1b 100644 --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -130,9 +130,9 @@ endif targets += $(targets-for-builtin) -$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS-y += -DINIT_SECTIONS_ONLY +$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)): CFLAGS-y += -DINIT_SECTIONS_ONLY -non-init-objects = $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(extra-y)) +non-init-objects = $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)) ifeq ($(CONFIG_CC_IS_CLANG),y) cov-cflags-$(CONFIG_COVERAGE) := -fprofile-instr-generate -fcoverage-mapping @@ -146,7 +146,7 @@ endif $(call cc-option-add,cov-cflags-$(CONFIG_COVERAGE),CC,-fprofile-update=atomic) # Reset cov-cflags-y in cases where an objects has another one as prerequisite -$(nocov-y) $(filter %.init.o, $(obj-y) $(obj-bin-y) $(extra-y)): \ +$(nocov-y) $(filter %.init.o, $(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)): \ cov-cflags-y := $(non-init-objects): _c_flags += $(cov-cflags-y) @@ -156,7 +156,7 @@ ifeq ($(CONFIG_UBSAN),y) UBSAN_FLAGS := $(filter-out -fno-%,$(CFLAGS_UBSAN)) $(filter -fno-%,$(CFLAGS_UBSAN)) # Reset UBSAN_FLAGS in cases where an objects has another one as prerequisite -$(noubsan-y) $(filter %.init.o, $(obj-y) $(obj-bin-y) $(extra-y)): \ +$(noubsan-y) $(filter %.init.o, $(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)): \ UBSAN_FLAGS := $(non-init-objects): _c_flags += $(UBSAN_FLAGS) @@ -273,7 +273,7 @@ define cmd_obj_init_o $(OBJCOPY) $(foreach s,$(SPECIAL_DATA_SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@ endef -$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): $(obj)/%.init.o: $(obj)/%.o FORCE +$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)): $(obj)/%.init.o: $(obj)/%.o FORCE $(call if_changed,obj_init_o) quiet_cmd_cpp_i_c = CPP $@ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 09:54:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 09:54:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208564.1520727 (Exim 4.92) (envelope-from ) id 1vi8RI-0006mR-7Z; Tue, 20 Jan 2026 09:54:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208564.1520727; Tue, 20 Jan 2026 09: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 1vi8RI-0006mK-4e; Tue, 20 Jan 2026 09:54:20 +0000 Received: by outflank-mailman (input) for mailman id 1208564; Tue, 20 Jan 2026 09:54: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 1vi8RG-0006Yj-Bu for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 09:54:18 +0000 Received: from CH4PR04CU002.outbound.protection.outlook.com (mail-northcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c105::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fb100f66-f5e5-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 10:54:16 +0100 (CET) Received: from PH8PR02CA0033.namprd02.prod.outlook.com (2603:10b6:510:2da::6) by DM4PR12MB5890.namprd12.prod.outlook.com (2603:10b6:8:66::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 09:54:12 +0000 Received: from CO1PEPF000044F7.namprd21.prod.outlook.com (2603:10b6:510:2da:cafe::67) by PH8PR02CA0033.outlook.office365.com (2603:10b6:510:2da::6) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.8 via Frontend Transport; Tue, 20 Jan 2026 09:54:11 +0000 Received: from satlexmb07.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_256_GCM_SHA384) id 15.20.9564.0 via Frontend Transport; Tue, 20 Jan 2026 09:54:11 +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, 20 Jan 2026 03:54:07 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fb100f66-f5e5-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lB4WXlTfdqboyj9scm3g3IJxXEycgB1KFpRUQxcXYxAFcF57XBUrA3bWGKOuG4nYqjcIiyVSVtFVSFZev4X80C2W8In9OMinHdGmj1UskGkBcgdh0Bh46IywO2nUFk7QEvVg9gNx9d1/TySyFFdQeMEZ4Hkk72wo237+pKtvPybBU8cQVFzo3uvVO+cuKwaguefXTarBtoHzi2yY6MvQZZfiKbJEWmk2pDqbeGx6pM+5CSBvEVQYj6Os0qpZEQR3NrY0u4wZdbSOVKTh1oLBz42xi15xUVgC7koMiEgehhqPM+Z8wo9dQROV0RRVN2Y/7aOusg/P6jGWd4E73ugl+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=ALJ37co92itax4shhvmhJjbaEOS6iiqt/fVSHH2YXWw=; b=Nuo4iIUjrgfNVGJYkQRi2h9q/pPyisVqEvfGKlJ8XF6Lmm0/LMWUhh6TIHpF4c0YJz754Fh8UB6k9wuSZsButjK/Bw6ZM2yhMWKqpivc0bDMu9ovAFRn8CafZoorbsTk+nRzVydGAGCb5CVv4VHtk9YsexOT5zO8acDCy7GCVM6p+Czbi4jm7ueyb+Hzh9h0AsHM+l92VCbUVxhgeWMLOruQiVTKu1KHLRin4qnxMEgxoJgqMIrh11g6AR3SwUWLdO076mvk0mX2o5auMqpYqxW6egv3cfRMfRhgGL9/YfAFWmmb5qYFuIxzPDpox9ebl5NaQ979sbRFmkfo0LJlfQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ALJ37co92itax4shhvmhJjbaEOS6iiqt/fVSHH2YXWw=; b=1iM0rJBJ24pyCfTJb1bM56R5nGcZcXMF2MRVkjWt4rfpJOZKtL/aFXaUquf+Y+PPdKcU/vZoPhwcHsCG1LcZapLz5wTHasOMM2pboIZNSKp3FwNVLYZITKyV2FIOErb/tEAPrnwxKV90Vv6mTgeHh3TKsVMyOfujPPvAD1hiy2s= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Stefano Stabellini Subject: [PATCH 1/2] x86/svm: Add infrastructure for Bus Lock Threshold Date: Tue, 20 Jan 2026 10:53:49 +0100 Message-ID: <20260120095353.2778-2-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> References: <20260120095353.2778-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: CO1PEPF000044F7:EE_|DM4PR12MB5890:EE_ X-MS-Office365-Filtering-Correlation-Id: 12e07b17-52b2-466b-16f6-08de5809dcc9 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?SKjPp0Z3nLLemRmP+Tf3pepXN/XbGlIvxrNDP2FpcPpeUEF73DYgI5BznMdH?= =?us-ascii?Q?2W+w+hANbR8qwwCwIrf9JJgRgoh4eRWkXyTpNquKBuIVe7vWFCnQp5x1garG?= =?us-ascii?Q?HJMPrxaTZWYt16sQTeY8JNF90tGqqcCHBNb3xoyDNhjl0PzXZXJ+EAw4abrO?= =?us-ascii?Q?5QhxWbx3AxBB/K5XB6mX4uSfLXbUUQMf/8ZVeXMBSm5uf2Fr1XeDB5fIjr3O?= =?us-ascii?Q?ddsKLMjwTC5K6phq9oq06fyXDBsrqYWWZhpDZOGVsT2LPZ1weMhxu2+t1miU?= =?us-ascii?Q?k/f7fdkhA82V+yzL8RTkas+fHpfYLw1X75bwGAY89tm4t02k4nLxjhU5zCb0?= =?us-ascii?Q?6CNtu99MJzqs7gbrYk/dIbydmWC5AuSaPIedDKRqP7F9tkBLwuFOASK2WVT8?= =?us-ascii?Q?uWE+tp5YCfUpYBJ7Y5jya+yQQUNW7I1YXYvRNKIFN6+xKtqLTcrj6fEI4oPC?= =?us-ascii?Q?Gjrl9mTULICZ1XOZXOtg8WtSC+MQwhNtHAeFwGxHskyyZNx7J4L4DeVhs5WM?= =?us-ascii?Q?0wwLs2S9RJhERlo1PpNISER9NiTMOeQQqWIsFK1WnHqOjVUTupb2DnprMgmi?= =?us-ascii?Q?yhCJ9Q3BJKdHLHtIap4NK9s9UxaXutLUIfK8Ahb5/JZbo4zYB5ab5Im3bH+b?= =?us-ascii?Q?AB52foblad8f1gGPrIf+dz3QoU7pq5iLQtrMLlgrxSNaN15u2ITQ3ul//0a7?= =?us-ascii?Q?zaULFyPC43rspaOGUIRpwDJbKmAifXz9GzLxNoxMonJM2MoWoA6TwQjdO3cK?= =?us-ascii?Q?dcg7k/QBYS1b37VW869WHNCDJoJrLFqC2g3GZSBfC9XbcMdGJLGvFFsOOmJm?= =?us-ascii?Q?T4FWCfOlTP7Np5/COQvDfpmmctpxo5KTubEi8oaSpFTgdQsbz61Uy5lMdssY?= =?us-ascii?Q?C5HrgDmHq2oGyNuixHkR2xqX8SmLRZiEvafGnI3xSMJMsjnD8ma9tMxTneZo?= =?us-ascii?Q?Sqkvdgw4ULqIAp0EAweir3/zrPUo20+l3/7ecFe1Wotg/78GjkPgOhZP7hlq?= =?us-ascii?Q?PAPLB7UjYpCB82Osbol+H+qYs2HtLKeFMB0qxeMMRlTOrgYCYDyUI/3jrRwD?= =?us-ascii?Q?ZZA4mkdOplsJzLxtWhkXyEL/C/SnjtlzeC+UJq5/0CZCdEpyIci5eiN6+wkz?= =?us-ascii?Q?P9KkcLfSa3I4RzGf87HDTlXaR5fGSjW4xQPciccbZqt5GlKiZ7R5xo4TxvEN?= =?us-ascii?Q?LV4dpH1OGEDfyHyEltuia3ottvvwRxkjwgggKPqZJmELK+JswLnG7HoaSFvY?= =?us-ascii?Q?tfOckBg2cJMKQVguyLLMyRGYeX0tNyYsQrkC5MFsyGh/o3q5J+nstFnxHDKC?= =?us-ascii?Q?tNorT5/nStYkrl3OPchZWKkCzlg9PIXlpXPttK37IT76t2acOhg2XDSbnhus?= =?us-ascii?Q?WWrVp9p4yCfRWfxSWwOt5loEhN+A7GNARPhpwCLvoWfYbL4Io7BGrIAb8RWr?= =?us-ascii?Q?IJd2kARC5/videSLG5MrY4cSq9DrkSQm1qF8jXzqS8V9e8bDusNIrxpY9TOO?= =?us-ascii?Q?bLNAa8oqSh94MyLbgCVK5iQEcgj9J8gkqrc7Sx3MUIq5Ebo9a92ki6sVHVDp?= =?us-ascii?Q?4/skGrLUQrd+5ib2U1lydB0ucTiwUC1hMHCi+KOh6OH4MhQqL8w/Q5NS5tzW?= =?us-ascii?Q?J6Qxm/F5nd0eiyxzl2jJuCg=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;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: 20 Jan 2026 09:54:11.4502 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 12e07b17-52b2-466b-16f6-08de5809dcc9 X-MS-Exchange-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: CO1PEPF000044F7.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5890 Add missing scaffolding to enable BusLock Threshold. That is: * Add general_intercepts_3. * Add missing VMEXIT * Adjust NPF perf counter base to immediately after the buslock counter Signed-off-by: Alejandro Vallejo --- xen/arch/x86/hvm/svm/svm.c | 1 + xen/arch/x86/hvm/svm/vmcb.h | 15 +++++++++++++-- xen/arch/x86/include/asm/hvm/svm.h | 2 ++ xen/arch/x86/include/asm/perfc_defn.h | 2 +- 4 files changed, 17 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 5d23603fc1..9748df87d8 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -2524,6 +2524,7 @@ const struct hvm_function_table * __init start_svm(void) P(cpu_has_tsc_ratio, "TSC Rate MSR"); P(cpu_has_svm_sss, "NPT Supervisor Shadow Stack"); P(cpu_has_svm_spec_ctrl, "MSR_SPEC_CTRL virtualisation"); + P(cpu_has_bus_lock_thresh, "BusLock-Intercept Filter"); #undef P if ( !printed ) diff --git a/xen/arch/x86/hvm/svm/vmcb.h b/xen/arch/x86/hvm/svm/vmcb.h index ba554a9644..85e194f247 100644 --- a/xen/arch/x86/hvm/svm/vmcb.h +++ b/xen/arch/x86/hvm/svm/vmcb.h @@ -65,6 +65,11 @@ enum GenericIntercept2bits GENERAL2_INTERCEPT_RDPRU = 1 << 14, }; +/* general 2 intercepts */ +enum GenericIntercept3bits +{ + GENERAL3_INTERCEPT_BUS_LOCK_THRESH = 1 << 5, +}; /* control register intercepts */ enum CRInterceptBits @@ -289,6 +294,7 @@ enum VMEXIT_EXITCODE VMEXIT_MWAIT_CONDITIONAL= 140, /* 0x8c */ VMEXIT_XSETBV = 141, /* 0x8d */ VMEXIT_RDPRU = 142, /* 0x8e */ + VMEXIT_BUSLOCK = 165, /* 0xa5 */ /* Remember to also update VMEXIT_NPF_PERFC! */ VMEXIT_NPF = 1024, /* 0x400, nested paging fault */ /* Remember to also update SVM_PERF_EXIT_REASON_SIZE! */ @@ -405,7 +411,8 @@ struct vmcb_struct { u32 _exception_intercepts; /* offset 0x08 - cleanbit 0 */ u32 _general1_intercepts; /* offset 0x0C - cleanbit 0 */ u32 _general2_intercepts; /* offset 0x10 - cleanbit 0 */ - u32 res01[10]; + u32 _general3_intercepts; /* offset 0x14 - cleanbit 0 */ + u32 res01[9]; u16 _pause_filter_thresh; /* offset 0x3C - cleanbit 0 */ u16 _pause_filter_count; /* offset 0x3E - cleanbit 0 */ u64 _iopm_base_pa; /* offset 0x40 - cleanbit 1 */ @@ -489,7 +496,10 @@ struct vmcb_struct { u64 nextrip; /* offset 0xC8 */ u8 guest_ins_len; /* offset 0xD0 */ u8 guest_ins[15]; /* offset 0xD1 */ - u64 res10a[100]; /* offset 0xE0 pad to save area */ + u64 res10a[8]; /* offset 0xE0 */ + u16 bus_lock_thresh; /* offset 0x120 */ + u16 res10b[3]; /* offset 0x122 */ + u64 res10c[91]; /* offset 0x128 pad to save area */ union { struct segment_register sreg[6]; @@ -583,6 +593,7 @@ VMCB_ACCESSORS(dr_intercepts, intercepts) VMCB_ACCESSORS(exception_intercepts, intercepts) VMCB_ACCESSORS(general1_intercepts, intercepts) VMCB_ACCESSORS(general2_intercepts, intercepts) +VMCB_ACCESSORS(general3_intercepts, intercepts) VMCB_ACCESSORS(pause_filter_count, intercepts) VMCB_ACCESSORS(pause_filter_thresh, intercepts) VMCB_ACCESSORS(tsc_offset, intercepts) diff --git a/xen/arch/x86/include/asm/hvm/svm.h b/xen/arch/x86/include/asm/hvm/svm.h index a6d7e4aed3..14fe4abf96 100644 --- a/xen/arch/x86/include/asm/hvm/svm.h +++ b/xen/arch/x86/include/asm/hvm/svm.h @@ -37,6 +37,7 @@ extern u32 svm_feature_flags; #define SVM_FEATURE_VGIF 16 /* Virtual GIF */ #define SVM_FEATURE_SSS 19 /* NPT Supervisor Shadow Stacks */ #define SVM_FEATURE_SPEC_CTRL 20 /* MSR_SPEC_CTRL virtualisation */ +#define SVM_FEATURE_BUS_LOCK_THRESH 29 /* Bus Lock Threshold */ static inline bool cpu_has_svm_feature(unsigned int feat) { @@ -56,6 +57,7 @@ static inline bool cpu_has_svm_feature(unsigned int feat) #define cpu_has_svm_vloadsave cpu_has_svm_feature(SVM_FEATURE_VLOADSAVE) #define cpu_has_svm_sss cpu_has_svm_feature(SVM_FEATURE_SSS) #define cpu_has_svm_spec_ctrl cpu_has_svm_feature(SVM_FEATURE_SPEC_CTRL) +#define cpu_has_bus_lock_thresh cpu_has_svm_feature(SVM_FEATURE_BUS_LOCK_THRESH) #define MSR_INTERCEPT_NONE 0 #define MSR_INTERCEPT_READ 1 diff --git a/xen/arch/x86/include/asm/perfc_defn.h b/xen/arch/x86/include/asm/perfc_defn.h index d6127cb91e..ac7439b992 100644 --- a/xen/arch/x86/include/asm/perfc_defn.h +++ b/xen/arch/x86/include/asm/perfc_defn.h @@ -7,7 +7,7 @@ PERFCOUNTER_ARRAY(exceptions, "exceptions", 32) #ifdef CONFIG_HVM #define VMX_PERF_EXIT_REASON_SIZE 76 -#define VMEXIT_NPF_PERFC 143 +#define VMEXIT_NPF_PERFC 166 #define SVM_PERF_EXIT_REASON_SIZE (VMEXIT_NPF_PERFC + 1) PERFCOUNTER_ARRAY(vmexits, "vmexits", MAX(VMX_PERF_EXIT_REASON_SIZE, SVM_PERF_EXIT_REASON_SIZE)) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 09:54:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 09:54:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208563.1520716 (Exim 4.92) (envelope-from ) id 1vi8RF-0006Yw-06; Tue, 20 Jan 2026 09:54:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208563.1520716; Tue, 20 Jan 2026 09:54:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi8RE-0006Yp-TL; Tue, 20 Jan 2026 09:54:16 +0000 Received: by outflank-mailman (input) for mailman id 1208563; Tue, 20 Jan 2026 09:54: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 1vi8RE-0006Yj-5X for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 09:54:16 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f9fa09fc-f5e5-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 10:54:14 +0100 (CET) Received: from PH8PR02CA0039.namprd02.prod.outlook.com (2603:10b6:510:2da::26) 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.9520.12; Tue, 20 Jan 2026 09:54:10 +0000 Received: from CO1PEPF000044F7.namprd21.prod.outlook.com (2603:10b6:510:2da:cafe::7b) by PH8PR02CA0039.outlook.office365.com (2603:10b6:510:2da::26) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.9 via Frontend Transport; Tue, 20 Jan 2026 09:54:10 +0000 Received: from satlexmb07.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_256_GCM_SHA384) id 15.20.9564.0 via Frontend Transport; Tue, 20 Jan 2026 09:54:09 +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, 20 Jan 2026 03:54:04 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f9fa09fc-f5e5-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=R/wkJMHnP+Fkb0e0iqE4EcWJ/cTDCDF5FTaePn09G7bcX7zOMxGOSpeGi1PKkcfS0Wm+Pn3T8yXpfCRtPW9holcuKATnHqSGmqRWSUd9I0k9pfpkQkkomMKfCE9IRdNQ9HyV1MD0CUq/CiEHm6Z0hl/1Fv2S7Ll6OUQqRLL9jsop69IET4clp5g6K90dRFeCll3bYfeHVW1ytMkhWalTezpR320ILkWk99AN3Pg7RkPAB89VFBLiAI2z3CRdksm9JOv29NETrs0kCR9ghb/d9ZvGg9F2T91rHjG7py0+ZzdMBZL17wOziccyYcZN3VOU/NXm9LSJ5zUVnUnnGmFp1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xuIeWzyGiCnRAm9Kg6QG1cEl7K4jzzok7IMZLtDUxEs=; b=Wh7rF8J0LRGXxcGfKBRj9r5nhlXSnAwdlZEaRjo8IIcuGBkLnBBBOq1kSdKSGYOjIhNQDB/czShAVSMtwkbEgqpqsgb1WDCSxiYkRVD3r8yYa6IMpS5deEV6sSXu4kAGWAaHJcHg6SG8SKMSbAQ2w4FK1d8EL0Gk+HB5y5lCNA9s7lnWgpNgq3GavKsBvHdyvmLcmMoC92UXcpyS89KCl03ZCAedbt/shKmHtIHnm3ucIT9oUQ2LCgLIcBQhzkkX44ovLNXV0naAKrwCmMrD+nH6umP2EHoJWwCQjN6DZm75OPfdR4qblHp30P7lyZdpjlDMcGorFK20jCI+utcIQQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xuIeWzyGiCnRAm9Kg6QG1cEl7K4jzzok7IMZLtDUxEs=; b=XGCd6L7KUQrNEuyY8ctW47KP39S2QXwsZzOnTVP6D16Tpd5dOSpU319Idv0HcQpIFQtZz8vluL8G0+/Xrxxw+af0FrY/Wy9511fbvQCVePEO2MMPGuqRxn43CgmceLYIP0YzXbkTd23gXpoG76kLGHDJHzy4frSP3uOWPdJ7b5c= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Stefano Stabellini Subject: [PATCH 0/2] x86/svm: Add support for Bus Lock Threshold Date: Tue, 20 Jan 2026 10:53:48 +0100 Message-ID: <20260120095353.2778-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: CO1PEPF000044F7:EE_|IA0PR12MB8929:EE_ X-MS-Office365-Filtering-Correlation-Id: ab145094-6bd8-47af-eb4c-08de5809dba3 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?GNdxnLScYsYsDwYBaRVy8z/kzd/Ltp/xnwK8CcQyLJVk0pIy1sa6S8whskqk?= =?us-ascii?Q?0oWzfE7VYVtA7uXtbGRAJE3KTFIFI7+A2aMewe9T89/t39v0+1/iVngUGNOE?= =?us-ascii?Q?gINjGNwHBrAkMyx+55sWPS4to0OnpPF6QkTOji14BpP1B4gv8dFbJ3lvxtLo?= =?us-ascii?Q?3EDZSxXCigwhfGf7e7BewtpAkMONPcJ0njbdY30SCVZrml4NLA/N9Y6IPHeg?= =?us-ascii?Q?cVD4iEbREoFWBmPx7dLEODOt4tmzzicdAC6bteXNKeQYXBUDVNANiQK7U6M3?= =?us-ascii?Q?S1jbCNUHOBPY6O+zyX9FA1JytwYPrahVJTB5dHir50mWI1YOYxtQ82vMuST2?= =?us-ascii?Q?5tmQIqzwzxLCKT1V2fofa8Kl07T28bZADEhQ6x/OBNZbwOgR+KQo4Bf2NWsE?= =?us-ascii?Q?0RMEfho1DQb5XBo+8unmXpUoERRHzJwct6C5w/mKfK0x09lDITf4xd8amxa0?= =?us-ascii?Q?wc1LTAenlYH20+sJZE+IwYEUM/r8jzWrZEuLgJ7jAm15RxTsZCypHqX6fgiD?= =?us-ascii?Q?g9JMPtw11U9xcIiHkfhI+r8068QZMylcM052FNYrHU0Y6nPWc/+uuPHSkmww?= =?us-ascii?Q?zQeWRKyfy/6gJbGql2Xet83nsJhimcWJ3Wn2frj6eOSDQ9516wEXfG7xfjIx?= =?us-ascii?Q?ouxL89hBJZ8eeHbPxtszdxLksQUwU5Tg1a7OMIy6Uf7yt47gFJ/R0JckXdyK?= =?us-ascii?Q?gbVK8OQvbXy6riExln+4OBJ0fb17Xjr08bkPRArsL3+bNz6fA4bhdE6HTeJr?= =?us-ascii?Q?/w+0tP2ydf/7WRKdGnhJXRJ96Q9n+HOGfBLs+9RbCByMuvd5G0Z7+J5E4WxH?= =?us-ascii?Q?1FduS6baTh5v3CbhHFFlM74a0HolgKwpBgMaTjFF/ooSFDNHQ3O8mRv2kywo?= =?us-ascii?Q?5tHInOrQXMwaOuQ30bFQBvPBJ1u1DzldWc5pN3cGVBtWU5ASdaVU3OZANUDs?= =?us-ascii?Q?cgTpqZmTbyfJWuZ8JE9yqW22BmY9U2z/G2i5M8gxgfXWLwvWADubqCqg9S+P?= =?us-ascii?Q?HOtsbSKhhbPGGGKnwYXtXkttIxWnfELER2yAB0D9Dq3m9obFARHIr4S6eNXb?= =?us-ascii?Q?dz/4fW4tMxMrRruwbGo08NtswsIj5fO8fuZbFb6g/170ti26QKw0L63e1CFI?= =?us-ascii?Q?OCqaMUkt86DNpRwKX3mA3UQikWcEC3RjBjtqh/SuE2cd3Twnl4K2EKPyfS6M?= =?us-ascii?Q?gvo5Kwi1dn0FO7kUjWIonpv7C4LZfeTYwhIM0Xl4dbC4akPZ6hov6ATjG+rW?= =?us-ascii?Q?B65ChcPEuRMYU04Mxg2xtKwwSHyQCR4pWHJIZAXC00gf2CPJhuxZ3XVu6zpO?= =?us-ascii?Q?ILiqZAHU64dZy3Mzmh2VUObxoPshKMoP1UjRVo+qu9+tUZprzR1eIj//h95k?= =?us-ascii?Q?AfzhTTI0rgpXHiATAYPu5PbyC4OAzplR4ymkfDDCdvJGjLHuVluVoxOZn+sk?= =?us-ascii?Q?1bObL4x+i5y6aNhYkQGLJtmWGF++HxIqgbuU+Q7XWcthyrYWQl+UXOzac3mK?= =?us-ascii?Q?p7tmaBUfDolp58HAzDLtpvVT56NhGD5QBrnW6AaNJzxCR4MC7zlvtKLnK/NE?= =?us-ascii?Q?maCfsQIk+/aoWidlDaL736bxkl0ebVcnf/NOKFBHzxIRYiKyqrBhS+EhJLLc?= =?us-ascii?Q?xS/DSTfAGXftMtreWu1F8vg=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;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: 20 Jan 2026 09:54:09.5293 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ab145094-6bd8-47af-eb4c-08de5809dba3 X-MS-Exchange-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: CO1PEPF000044F7.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8929 Bus Locks are very costly and a VM left unchecked spamming instructions that lock the memory bus (e.g: unaligned atomic CAS) makes system perf take a nosedive. This patch is similar to BLD of VMX, but for SVM. It configures all VMRUNs so they automatically exit at the first encounter of a buslock event, effectively rate-limiting them. Cheers, Alejandro Alejandro Vallejo (2): x86/svm: Add infrastructure for Bus Lock Threshold x86/svm: Intercept Bus Locks for HVM guests xen/arch/x86/hvm/svm/svm.c | 5 +++++ xen/arch/x86/hvm/svm/vmcb.c | 6 ++++++ xen/arch/x86/hvm/svm/vmcb.h | 15 +++++++++++++-- xen/arch/x86/include/asm/hvm/svm.h | 2 ++ xen/arch/x86/include/asm/perfc_defn.h | 2 +- 5 files changed, 27 insertions(+), 3 deletions(-) base-commit: 7b3e1b4e848d34c9a5b6634009959a7b9dd42104 -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 09:54:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 09:54:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208565.1520736 (Exim 4.92) (envelope-from ) id 1vi8RL-00071w-IJ; Tue, 20 Jan 2026 09:54:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208565.1520736; Tue, 20 Jan 2026 09:54: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 1vi8RL-00071o-FD; Tue, 20 Jan 2026 09:54:23 +0000 Received: by outflank-mailman (input) for mailman id 1208565; Tue, 20 Jan 2026 09: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 1vi8RJ-0006Yj-J2 for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 09:54:21 +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 fd3d2d7c-f5e5-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 10:54:20 +0100 (CET) Received: from PH8PR02CA0037.namprd02.prod.outlook.com (2603:10b6:510:2da::35) by DS7PR12MB5814.namprd12.prod.outlook.com (2603:10b6:8:76::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 09:54:13 +0000 Received: from CO1PEPF000044F7.namprd21.prod.outlook.com (2603:10b6:510:2da:cafe::69) by PH8PR02CA0037.outlook.office365.com (2603:10b6:510:2da::35) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.13 via Frontend Transport; Tue, 20 Jan 2026 09:54:12 +0000 Received: from satlexmb07.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_256_GCM_SHA384) id 15.20.9564.0 via Frontend Transport; Tue, 20 Jan 2026 09:54:12 +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, 20 Jan 2026 03:54:08 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fd3d2d7c-f5e5-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=yyvFWv3+VBwTDB5ly/AP9wyGd+/7w/KDiK488McpzGROGreGOws/ELXAdwJvmh6v03k8QLewq+X/PQglv/rHY8tTmbYgP9D+KM5Ao2/zalvwASpORK2X52ROoECvgA4nGtcY9745Den6XuO3SpKxBnCZgiJANdYgrypiDS28BYGJmD3ZwPE3rOWfks94iUX2ijRJzEtpEX5Dq1LejmvRhxspU48RW66zh0hlBcZ4eV48JQkA7mdYEb/1mcUhRD4QfH9K3yDKAi3ExkCFkM8+BcGRz3ougucWdt5/eJRAUYOIvnqaIHlrHrkLKRfo2wVvQ81ORddDaCyTe4JG8UoxHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tlelRD0l8IWBcWpAH3Cc0918m2Klv7LDj+1fptSjsws=; b=JiIA6TSQ3fm68JLI7oqZLabjgvnVwgvTbEuCaT3i7cQM2XzPShXpBJAm9cdA1Xi2Jhnb0IfQ0QchUVlLVgbUnyQzutqFGCGv+mqbAjCtq+eTiNOiPrEMk7qi813eeVYPtLn5W7oljsA+Pl9SB2l3lKQCd/gXfq4XWVsB6XBTumy7tgUq9bNcB58aN87srxXvpdD5yX6nLl73Ykvf806Ckqaajz+c6grxZJV+WD0CZvRaldkwQkUUvpkdyBRblVzVERzUV6AkMayC1qQDrIcLuE4PTAd3jfCEsPusGhBRKnLPgVJ28EAwkPukeN48sCPxYha265mzxrVq8WIbDIQNWQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tlelRD0l8IWBcWpAH3Cc0918m2Klv7LDj+1fptSjsws=; b=LdIfjEjEmXkhQHzcBU31sfI4YEi/dgN5enPulxU+GnKDVjarBcOeDxk4awEvwv3snMkkZCeidV/oFQUMwZMZ12Egr4LBLRWIVjxuVzFuusl+0wWNZfRqABR0Ydoaua2I/jOsg9GsVcLL3URaNZ+YM8HXfq9J0tuhQvoqzq2VZLw= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Stefano Stabellini Subject: [PATCH 2/2] x86/svm: Intercept Bus Locks for HVM guests Date: Tue, 20 Jan 2026 10:53:50 +0100 Message-ID: <20260120095353.2778-3-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> References: <20260120095353.2778-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: CO1PEPF000044F7:EE_|DS7PR12MB5814:EE_ X-MS-Office365-Filtering-Correlation-Id: 8120bafc-1136-43bb-938f-08de5809dd7b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|376014|36860700013; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?5mlqNkf/jsJC5sNIfaNBfTddN9Fb1Qjukj0fw85pkvyBGbwRigOftA6grPK3?= =?us-ascii?Q?3xuFm+IB8QVUy73eXsVWkQsPci0QLPJlBjfJiQi/x7WgPuybhwdUoDpL/ErS?= =?us-ascii?Q?fNQux0cLt1XXomfY+yOKINb1dzZfwjcR14CN8YcQ7GPUlZH4ak4TIJ/SRz6o?= =?us-ascii?Q?qjBrs3E3U9JEXOyjREm41ufMb3N/rFcpjmvMADx+GLeuxAwRpaZo7YG//G8v?= =?us-ascii?Q?kJ8GtPPEEa5vzWeRr10w3wV/caF8IaVhQgUwCrDx1THPyEGDDNLnsCzHxPQb?= =?us-ascii?Q?G60UhX8UMHF3GaTczpPooR8OTSjscwMztVMVlgsUo92Ik1pWbeRrfIbm0+TJ?= =?us-ascii?Q?51+MMM5XLLpu2rt4zDklXCpDOUCi7zLkh8cGHI9fqgNUJhJu2hwkOJiPacVf?= =?us-ascii?Q?l9etZk9syRabUoLtcwVpidz3IAxXQ1V93DlrpRzxURKG88/+K6kStaZlXHEb?= =?us-ascii?Q?uNtktBaD/QgqcDZQalObZd30MTRlKJlwSIAPcZ2UWaL4prTr8x0WbOuMaok1?= =?us-ascii?Q?2RQbNxHoIo81ojof6eWgo9SN2mMPt+eR8Htmxs0CRFQDmDfN7W42pGPVBrX+?= =?us-ascii?Q?9EKoaKMz/5gtrHuRj77G33FT/JF6BBNDspL4kUMhuTru8JZE7zDUvtVpoDaO?= =?us-ascii?Q?q4fhGoOTD8/jw3Wrrwytbs/y3YytXSViZVv1SppWpLxBxDdN/D6CkblY965x?= =?us-ascii?Q?cbF6lj5Zt9rqL6leq1a25KfE+MMHkvqZUPlAtD9nfFrtFfzGdf5zIEekxk3p?= =?us-ascii?Q?BAUzZUcjE6qb6AklfzMVUiVnuWpba5UH2Xo7yy3cM872lVXziZAZdivDkJyG?= =?us-ascii?Q?my9OEQ3i/uGFsU0UkFI+Omk9JmiS7Y9Fkva5wegYdc8SFdcCpduTKLhVmzeW?= =?us-ascii?Q?1lyhnyvR7hCcu4KZCsxC37sOHviOPL8/sdLNThyP+sCYsm5r5XIDjMaKkwB3?= =?us-ascii?Q?cEpfuE2yBlqOETIyTpnUVEuFQ/VSWGVk9TK92CZmIr+gon6d55n8lT3iUITf?= =?us-ascii?Q?Q6d3wWITRLlgy+rMouzUmUH48goJJ/hAP0AfksV4pJnFFPD7+Nr/pP4AxqmO?= =?us-ascii?Q?npDvM9h3+BSTOCRlZNZuKPacsge4agKBp/kbyi7i1kBb7RPR/pAqXCjWzhg0?= =?us-ascii?Q?KNOT4TWNV/Ah1brO+wgD633hbC+NNZWF/FJ77Jr+WQ0TPjmfww+Wq8LDJW+R?= =?us-ascii?Q?Qr0CPibV7mXMUFPp0dijKY636exRDcBrTJuGNMinoMTMKbHn9XbGJmPTWs8r?= =?us-ascii?Q?FvDMlICe10ETRTVk4DKX8oi2uwSqalt2QAhF0h/v1XsDKudy6pHJCHJqEeia?= =?us-ascii?Q?vf2GXd30S+RrAhDgczwZzXfNVovxCSpa+4yaPRRjmSAZ8UnNR3IeXuCnKi0E?= =?us-ascii?Q?U/eIvnWwKINz1V/KOmByLIJHZ5eQlxt819paRB80BMpdZwAEfu5o+Xgc+DEl?= =?us-ascii?Q?/GiKrGYe9NysF6BY8eTFo0pQ5D9SM7Z776BTUQ3W4dks+tz++ADQx/LQx6z/?= =?us-ascii?Q?ly+j9pQev9BofVx/VfQsYX7RcmRs8mK647Vk+qsgUqu7jhbT7zhVQtQ2wtOM?= =?us-ascii?Q?+w63V2kwp6kUK81W3CPT9lTpp1Zb9g8u0Naw5o4PoAPB6cSK2fF1wmGRZFox?= =?us-ascii?Q?D2FMBCDVVG6L207hNTw9S1U=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;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: 20 Jan 2026 09:54:12.5677 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8120bafc-1136-43bb-938f-08de5809dd7b X-MS-Exchange-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: CO1PEPF000044F7.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB5814 With the threshold initialised to 1 the guest exits at the first buslock. Initialising as zero is invalid and causes an immediate exit. Signed-off-by: Alejandro Vallejo --- xen/arch/x86/hvm/svm/svm.c | 4 ++++ xen/arch/x86/hvm/svm/vmcb.c | 6 ++++++ 2 files changed, 10 insertions(+) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 9748df87d8..dbb7f99d5e 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -3087,6 +3087,10 @@ void asmlinkage svm_vmexit_handler(void) hvm_descriptor_access_intercept(0, 0, desc, write); break; } + case VMEXIT_BUSLOCK: + perfc_incr(buslock); + vmcb->bus_lock_thresh = 1; + break; default: unexpected_exit_type: diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index cbee10d046..7a19b1ab61 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -66,6 +66,12 @@ static int construct_vmcb(struct vcpu *v) GENERAL2_INTERCEPT_XSETBV | GENERAL2_INTERCEPT_ICEBP | GENERAL2_INTERCEPT_RDPRU; + if ( cpu_has_bus_lock_thresh ) + { + vmcb->_general3_intercepts = GENERAL3_INTERCEPT_BUS_LOCK_THRESH; + vmcb->bus_lock_thresh = 1; /* trigger immediately */ + } + /* Intercept all debug-register writes. */ vmcb->_dr_intercepts = ~0u; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 09:57:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 09:57:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208594.1520746 (Exim 4.92) (envelope-from ) id 1vi8U6-00088z-VR; Tue, 20 Jan 2026 09:57:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208594.1520746; Tue, 20 Jan 2026 09:57:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi8U6-00088s-Si; Tue, 20 Jan 2026 09:57:14 +0000 Received: by outflank-mailman (input) for mailman id 1208594; Tue, 20 Jan 2026 09:57: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 1vi8U6-00088f-Ac for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 09:57:14 +0000 Received: from mail187-33.suw11.mandrillapp.com (mail187-33.suw11.mandrillapp.com [198.2.187.33]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5fb9e75d-f5e6-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 10:57:05 +0100 (CET) Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail187-33.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4dwN5q75QmzBsThRd for ; Tue, 20 Jan 2026 09:57:03 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 70b618fda82a4fdbb498f2bbe6cc4cfc; Tue, 20 Jan 2026 09:57: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: 5fb9e75d-f5e6-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1768903024; x=1769173024; bh=Td0Zid5VRB//BT4blpV+a0Bp1YjYVTUOReb8gVRMSpo=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=Zxm2CT2jenf+t5q/lL9QnFFTk5hSJDke2hTTltjYub+smaxnDOTckFYAPFL47KGFD NE1kl/IwtA0RXqXwwLX2fi3DwBjP2YWUQ0I6M48nQULcomCUc+04vsao7+zxDAosS6 KWIGopjEelFz2rvotypGKW7+x0HomrU1x21jZyfiVQnlX2dyGOhlD9QcosL4nawKsx 0JccFGN9ahmdXfTRZY2/ioOBmduiZzp2L2tjLghCwcE7CAl7gLGenlLts4Flbi8P4l R0evcjQkW8cFq96PhT6K7ZdLLs3GfCTqlakq08mAFCSxN97V+KisR2NEmOyOhKLNKa u9cn04BsncwNA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1768903024; x=1769163524; i=ngoc-tu.dinh@vates.tech; bh=Td0Zid5VRB//BT4blpV+a0Bp1YjYVTUOReb8gVRMSpo=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=hM/YMPOs/d79kosY60VD4H9o52ivNVHz/EU/RxQXO9JhGOXZmY/nH1UxsPRcfaNSw GyiYkx6sJgjiL5U+ZLDqnTg/E2Waw0KsRoQmdAfd4NRvPtStFO2NfuqB7R4J98uVFz pZ7vWjxVhME9dB6COqS3kxifo2E9uJfNpvOpmlY1xuv9ejdMmvj1eDxU0rMzjiTR/7 OoDahEsyjGcY5tAbcAkvD1tfX7l8bk0JQg/3Sl33U2FbGFyFpUC41FNtNXtuJNEwUs SFSdrW2Sh5/PGjmPGFKTp1pO4YOuXHOUBkH2/6jkMgAjoISjzyU9R6wBQmEGQwdvaY rVa8RcjGb3TJQ== From: "Tu Dinh" Subject: =?utf-8?Q?[PATCH=20v2]=20xen:=20Expose=20time=5Foffset=20in=20struct=20arch=5Fshared=5Finfo?= X-Mailer: git-send-email 2.51.2.windows.1 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1768903022467 To: xen-devel@lists.xenproject.org Cc: "Tu Dinh" , "Anthony PERARD" , "Andrew Cooper" , "Michal Orzel" , "Jan Beulich" , "Julien Grall" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" , "Bertrand Marquis" , "Volodymyr Babchuk" Message-Id: <20260120095657.237-1-ngoc-tu.dinh@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.70b618fda82a4fdbb498f2bbe6cc4cfc?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260120:md Date: Tue, 20 Jan 2026 09:57:03 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit time_offset is currently always added to wc_sec. This means that without the actual value of time_offset, guests have no way of knowing what's the actual host clock. Once the guest clock drifts beyond 1 second, updates to the guest RTC would themselves change time_offset and make it impossible to resync guest time to host time. Since there's no way to add more fields to struct shared_info, the addition has to be done through struct arch_shared_info instead. Add two fields in arch_shared_info representing time_offset's low and high 32-bit halves. Provide a new feature bit XENFEAT_shared_info_time_offset for this functionality. Signed-off-by: Tu Dinh --- v2: Remove unnecessary casts. --- tools/include/xen-foreign/reference.size | 5 ++--- xen/common/kernel.c | 3 ++- xen/common/time.c | 5 +++++ xen/include/public/arch-arm.h | 2 ++ xen/include/public/arch-ppc.h | 3 +++ xen/include/public/arch-riscv.h | 3 ++- xen/include/public/arch-x86/xen.h | 3 +++ xen/include/public/features.h | 5 +++++ 8 files changed, 24 insertions(+), 5 deletions(-) diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size index 11a06a7a43..38e799617a 100644 --- a/tools/include/xen-foreign/reference.size +++ b/tools/include/xen-foreign/reference.size @@ -9,6 +9,5 @@ vcpu_guest_context | 352 352 2800 5168 arch_vcpu_info | 0 0 24 16 vcpu_time_info | 32 32 32 32 vcpu_info | 48 48 64 64 -arch_shared_info | 0 0 28 48 -shared_info | 1088 1088 2344 3136 - +arch_shared_info | 8 8 36 56 +shared_info | 1096 1096 2352 3144 diff --git a/xen/common/kernel.c b/xen/common/kernel.c index fb45f81399..44af6f8f04 100644 --- a/xen/common/kernel.c +++ b/xen/common/kernel.c @@ -676,7 +676,8 @@ long do_xen_version(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) #ifdef CONFIG_X86 (1U << XENFEAT_vcpu_time_phys_area) | #endif - (1U << XENFEAT_runstate_phys_area); + (1U << XENFEAT_runstate_phys_area) | + (1U << XENFEAT_shared_info_time_offset); if ( VM_ASSIST(d, pae_extended_cr3) ) fi.submap |= (1U << XENFEAT_pae_pgdir_above_4gb); if ( paging_mode_translate(d) ) diff --git a/xen/common/time.c b/xen/common/time.c index c873b5731b..6f1a8a11c2 100644 --- a/xen/common/time.c +++ b/xen/common/time.c @@ -118,6 +118,11 @@ void update_domain_wallclock_time(struct domain *d) shared_info(d, wc_sec_hi) = sec >> 32; #endif + shared_info(d, arch.time_offset) = + (uint32_t)d->time_offset.seconds; + shared_info(d, arch.time_offset_hi) = + (uint32_t)(d->time_offset.seconds >> 32); + smp_wmb(); *wc_version = version_update_end(*wc_version); diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index cd563cf706..4360f9835b 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -363,6 +363,8 @@ struct arch_vcpu_info { typedef struct arch_vcpu_info arch_vcpu_info_t; struct arch_shared_info { + uint32_t time_offset; + uint32_t time_offset_hi; }; typedef struct arch_shared_info arch_shared_info_t; typedef uint64_t xen_callback_t; diff --git a/xen/include/public/arch-ppc.h b/xen/include/public/arch-ppc.h index b5e1a940a5..42ade11171 100644 --- a/xen/include/public/arch-ppc.h +++ b/xen/include/public/arch-ppc.h @@ -92,6 +92,9 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); struct arch_shared_info { uint64_t boot_timebase; + + uint32_t time_offset; + uint32_t time_offset_hi; }; struct arch_vcpu_info { diff --git a/xen/include/public/arch-riscv.h b/xen/include/public/arch-riscv.h index 360d8e6871..286bf92473 100644 --- a/xen/include/public/arch-riscv.h +++ b/xen/include/public/arch-riscv.h @@ -65,8 +65,9 @@ struct arch_vcpu_info { }; typedef struct arch_vcpu_info arch_vcpu_info_t; -/* TODO: add a placeholder entry if no real ones surface */ struct arch_shared_info { + uint32_t time_offset; + uint32_t time_offset_hi; }; typedef struct arch_shared_info arch_shared_info_t; diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h index a7bf046ee0..401583383c 100644 --- a/xen/include/public/arch-x86/xen.h +++ b/xen/include/public/arch-x86/xen.h @@ -263,6 +263,9 @@ struct arch_shared_info { /* There's no room for this field in the generic structure. */ uint32_t wc_sec_hi; #endif + + uint32_t time_offset; + uint32_t time_offset_hi; }; typedef struct arch_shared_info arch_shared_info_t; diff --git a/xen/include/public/features.h b/xen/include/public/features.h index 8801930947..b48591c17a 100644 --- a/xen/include/public/features.h +++ b/xen/include/public/features.h @@ -128,6 +128,11 @@ */ #define XENFEAT_dm_msix_all_writes 20 +/* + * arch_shared_info provides time_offset and time_offset_hi + */ +#define XENFEAT_shared_info_time_offset 21 + #define XENFEAT_NR_SUBMAPS 1 #endif /* __XEN_PUBLIC_FEATURES_H__ */ -- 2.43.0 -- Ngoc Tu Dinh | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Jan 20 10:20:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 10:20:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208613.1520757 (Exim 4.92) (envelope-from ) id 1vi8qo-0003mj-PR; Tue, 20 Jan 2026 10:20:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208613.1520757; Tue, 20 Jan 2026 10:20: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 1vi8qo-0003mc-MI; Tue, 20 Jan 2026 10:20:42 +0000 Received: by outflank-mailman (input) for mailman id 1208613; Tue, 20 Jan 2026 10:20:41 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi8qn-0003mW-Qk for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 10:20:41 +0000 Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [2a00:1450:4864:20::443]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id aaea433b-f5e9-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 11:20:39 +0100 (CET) Received: by mail-wr1-x443.google.com with SMTP id ffacd0b85a97d-4359108fd24so224012f8f.2 for ; Tue, 20 Jan 2026 02:20:39 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4356996cecasm26637728f8f.26.2026.01.20.02.20.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jan 2026 02:20:38 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: aaea433b-f5e9-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768904439; x=1769509239; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=AN6keBRBFgFoSLwk493Km5NqSYoTijt1jG98JbtbNLY=; b=fzKpyJWGLVKBx3oH2bFCmMr2cIBIojApUc2U9JFjgvmv3iBdMERx1dJ8AiTWOqXV52 HiaEXeR1vZbf3xr/ISt/vx1Op1MOPAvc3aJvvvq7Wdu/P1UY57PR1Qec3WHfYmSIgJIW FhrEPorlXEMDuuHfnx1p8NqiMAze0rXogoQyKb4pQM9cIkudxkDF4YC/ctT/BWJhGeB0 l+lXNHllw+13V2JnsOryiQExYew7IZk3Y1j+oXyDFVOqHikxT1CvQrwt+DnGCbmm6jEJ 9ptt92OiWf1eJVIvuNDFGeIcE8pZwskeCkReZDnXZU0Q+mIwvn52hvVWju3WoE2zM8WR lwdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768904439; x=1769509239; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=AN6keBRBFgFoSLwk493Km5NqSYoTijt1jG98JbtbNLY=; b=aLP2NUKgHSIOwmAKbF8OcuauTLJdPa/rlU0pUIzXirS/BOQzCj5/0nBfwTbmVgWGtu o8xCZ0/48MptJSnNUXxNGlCpjB/6S+bQsSKSQ2/EAmNwxVwh4fn8y22G4fd8h6iiFmvK swAOx6+osr4LDMVv6uI18ZXl11zAsLboRi09ZLgyPIv5rcC+lDfgpw+sGjkgcMdsGR8l a9EzcYAmnRCAdSTOc15h8ZFc7PnHSaKnYUJmU86S39niTA/2dhik86+8X77QiDh6ZOhZ ICfASnfqzN2oOZE7CA6lAbZzENPuzwjhV5AZnyzHs2/p65qlHTcK/c+sROBJP0DBF6LX oQGw== X-Forwarded-Encrypted: i=1; AJvYcCVkmCOzcmJJdDKRvgSHS2OtyVVqlzAW8QKCaD10VtFdudAvFIQkif/K4N/GVB5Iqz3HCkBzeUGorI8=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxqh6cY+hKW42Gc/XCk+aRh2c3UKPSwu9e3vJjX9StTstWbOIdc o4H98l2B5hOYriBxtH5TmvD4m34khZ03zdkGFyOi8GDCKCUbLKjGEfarDcqZbEXytw== X-Gm-Gg: AZuq6aJKS6JNhUl+cuIVKttQpJNjotT1vzUD8wYPD50H7ghCe34dbse98AVjKVmi/xp I3wRgWEn5St27kkGGAurljqZq8isCLBalUr2I+kEAHmBp8t0HGvanPH7GSchA4Rjjh92BCudM8w kzrbZJOLlEidQGGSm6u8M0j6VHb3wgCrJiDedOziQLemqnSAc3ybdMuT/VozYZbPEdFBZUd59hQ zTKZ0NcrhqZxSz7gU8TYOHaYIJNOcFfj/q4bdqCtXgHMDKQJdwX2AgMuDg7aWHywBHsMWxCT3Mp g8HLtwoQME4wQWVEkA7tNW9KWvLRolrqBpxZhTWqB7WDae31uOvyaVlCTYzacCKFM2iPUeI8Feh TiJjiZ0Tydi2IT+ILMvv2kxhT/stokVjh86Vh1fSoJH0WYKOvoZFNGgN//rLU2KsUj54hi/DpmK mYbY4id5RZc53/gE8GZBFeOiAtjFtnxMad7wRiz66iMdC/viqa4q8bvhvid/4CGvHO73aJq6GeS qQ= X-Received: by 2002:a05:6000:25c7:b0:430:fc3a:fbce with SMTP id ffacd0b85a97d-435699941abmr19821551f8f.15.1768904438820; Tue, 20 Jan 2026 02:20:38 -0800 (PST) Message-ID: Date: Tue, 20 Jan 2026 11:20:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 0/4] Add Kconfig option to remove microcode loading support To: Alejandro Vallejo Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Doug Goldstein , xen-devel@lists.xenproject.org References: <20260120093852.2380-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: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 20.01.2026 10:38, Alejandro Vallejo wrote: > The only dependency here is patch 2 going in before patch 3. Everything else > can be freely rearranged. Is this correct? Didn't you say (confirming what I observed elsewhere a little while back) that there's a complaint when a file listed in the exclusions doesn't exist anymore (which may have been cppcheck, not Eclair, but still breaking CI)? IOW can patch 4 really be separate from patch 3? Or, if its description was to be trusted, wouldn't it need to go ahead of what is now patch 3? > Cheers, > Alejandro > > Alejandro Vallejo (5): > x86/ucode: Add Kconfig option to remove microcode loading > xen: Allow lib-y targets to also be .init.o > earlycpio: lib-ify earlycpio.c > docs/misra: Remove earlycpio.c from the Eclair exclusion list. > automation: Disable ucode loading on AMD's analysis run > > automation/gitlab-ci/analyze.yaml | 1 + > docs/admin-guide/microcode-loading.rst | 2 ++ > docs/misc/efi.pandoc | 2 ++ > docs/misc/xen-command-line.pandoc | 7 ++++--- > docs/misra/exclude-list.json | 4 ---- > xen/Rules.mk | 10 +++++----- > xen/arch/x86/Kconfig | 14 ++++++++++++++ > xen/arch/x86/cpu/microcode/amd.c | 16 +++++++++------- > xen/arch/x86/cpu/microcode/core.c | 15 ++++++++++++--- > xen/arch/x86/cpu/microcode/intel.c | 11 +++++++---- > xen/arch/x86/cpu/microcode/private.h | 3 +++ > xen/arch/x86/efi/efi-boot.h | 3 ++- > xen/arch/x86/platform_hypercall.c | 10 ++++++++-- > xen/common/Makefile | 2 +- > xen/lib/Makefile | 1 + > xen/{common => lib}/earlycpio.c | 0 > 16 files changed, 71 insertions(+), 30 deletions(-) > rename xen/{common => lib}/earlycpio.c (100%) > > > base-commit: 7b3e1b4e848d34c9a5b6634009959a7b9dd42104 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 10:23:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 10:23:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208624.1520768 (Exim 4.92) (envelope-from ) id 1vi8tY-0004JO-7b; Tue, 20 Jan 2026 10:23:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208624.1520768; Tue, 20 Jan 2026 10:23: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 1vi8tY-0004JH-3e; Tue, 20 Jan 2026 10:23:32 +0000 Received: by outflank-mailman (input) for mailman id 1208624; Tue, 20 Jan 2026 10:23: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 1vi8tX-0004JB-CW for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 10:23:31 +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 10b2b6df-f5ea-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 11:23:30 +0100 (CET) Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-4359249bbacso164742f8f.0 for ; Tue, 20 Jan 2026 02:23:30 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4356996cf58sm29265883f8f.22.2026.01.20.02.23.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jan 2026 02:23:29 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 10b2b6df-f5ea-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768904609; x=1769509409; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=XWwNE4XQpYgK53ZJ0W2IGDAxdWbROmXWumqVJ7C/+34=; b=VpbpTd1xBs4hU8muvei3k+cSLv543n2jyWKJwcRlrRnbL1vHNkP7s2cj9fa/CoxVdi hm3VOyxNry5kA/KzA/WupHDQVJyE1h2QWYXFpaN8EnmJBPsY8lrvwBBZUdU7pwEZyC8+ qnANNjZE9f9o1thyNbWzoEcSCq7CFmCGHLxuFFDO7ZKr+OJwwTzKEayUFeW/RAzy7hTG Iryg3x06QYUEGOmcDSwXmBWbX2pWCXpx54jivMwcT1arVLnIAPE2EOcipgNKjrVS0Atb cf916ZUdFvnhkA9RKfbRqLVN+Lsig4oFREk89/e39lHkzvtTiTyfiMavqiHv4brn3SXg cceQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768904609; x=1769509409; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=XWwNE4XQpYgK53ZJ0W2IGDAxdWbROmXWumqVJ7C/+34=; b=DKgHouXrO/AChSXpxriuaZ0nl3cpYSwfNw8OBTLfVGNfWBeFKHys3EF5OMk/H2ByRy jEaKOmGJNn4lm36kWG8wY9J1SaggkfXnStrbQx33pHQvKLvkQIbyfHfY+sDIuK60kQRr w8XUpwaOeW3G/teoz5mQMwHiWdFXMzTEAY4WZzFCM0mi47ZdXnyh72oC8C+qhPVSGMFI t1mKAWWaBQvKpCHpYTcSb5SyFLwz5rkWraShDeTzRtrbNv7XtWVGcC0HIKlpSGzY5jUB iqx1s85eDbDIHZDtsdQQwIz3b+Vb9wtSs6hTeZ4xDRWb8wH37JvLcC8kJXiEo8hvZVev ZmZA== X-Forwarded-Encrypted: i=1; AJvYcCWWSCczoda/wyIsoV1NR24R3UfXZbexPUbOWlZJevqQGvMhbWVpqAS3gP6efDCvH6CLDop15tVr/pc=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzf3JdcRXcYXKpRGvPdIv5N177bglnuNtwjn3ZpNgPWhuz6nx7E tnMLn7LC3MG0EoPjFxySXQ0oJ2NuiptVpUMif/wjGUb2pMj5/0kbZBXs1zoaSoW42g== X-Gm-Gg: AZuq6aJal7A2WHgms9d+ASLBFzs1J/7oiMITYVvZGTllmVUXXSB80Ykc3Ff0NSXgM/D DmZnFiVNNObeNSM+6U4TR6CDpG4toOyoaON8hqDtnZNWwiZyvXUwPSLM4DJy3daHmjq2fLUMOjp 9ZSOogAnzuYVqnW/ZAaLCOxb4/PzVcra1y8dpBIYKoPpc0CMDZ8LNzP2o5YbHyuMHgdVJxzvKBB qTDzwTFmk1x1DckmmnODAsqe2PrVg4SJniF8ZH7oha6jfFgMtSBnFjcYDxyqMz0hFJlUvPmrwVA GiA7UiOvUoDh+pzv0q4avbkQFiAQNCvhrUgKUqbgtCQxJvpFPnc5HrJslhlLOPtQuaCISMLpBkV K+OThdMQClys92SSocvIPH0shbGzhsFxJliXb4WFoObTDpu3SzsKG1oGUhbPk+g1iO29oBf8JND b8hrGTQ+WfXyIxI05Z7orf3d/9hGBo5DWHy4LsdxUkovyEir6u4r02mxdokmxRL408zMLHEsCJE GA= X-Received: by 2002:a05:6000:2210:b0:435:9606:e78c with SMTP id ffacd0b85a97d-4359606f13emr193961f8f.14.1768904609462; Tue, 20 Jan 2026 02:23:29 -0800 (PST) Message-ID: Date: Tue, 20 Jan 2026 11:23:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/5] xen: Allow lib-y targets to also be .init.o To: Alejandro Vallejo Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> <20260120093852.2380-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: <20260120093852.2380-3-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 20.01.2026 10:38, Alejandro Vallejo wrote: > There's some assumptions as to which targets may be init-only. But > there's little reason to preclude libraries from being init-only. > > Signed-off-by: Alejandro Vallejo Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Tue Jan 20 10:35:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 10:35:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208641.1520777 (Exim 4.92) (envelope-from ) id 1vi94x-00069Z-Ap; Tue, 20 Jan 2026 10:35:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208641.1520777; Tue, 20 Jan 2026 10:35:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi94x-00069S-7t; Tue, 20 Jan 2026 10:35:19 +0000 Received: by outflank-mailman (input) for mailman id 1208641; Tue, 20 Jan 2026 10:35: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 1vi94v-00069M-Bw for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 10:35:17 +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 b57368d9-f5eb-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 11:35:16 +0100 (CET) Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-430f3ef2d37so4155213f8f.3 for ; Tue, 20 Jan 2026 02:35:16 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4356997eb2asm28886123f8f.37.2026.01.20.02.35.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jan 2026 02:35:15 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b57368d9-f5eb-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768905315; x=1769510115; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=AXZwvmj271zYvLNWkodrwZ3eJeR2Z4f2M0MqwFU/dUs=; b=bJFtZcIW2a74tgAQKWvsY+8WK0Su6Hh0o9hB0jxgPvGyiSzEsMoHQ0RN8gLC6ZPi8K cfYAFLXru68yhKfee2CbPJ7F6PCo2BgEhSLtvbeKddmEdUFnDSIDLEdMB8hltEo21bGj F+lxlxvBtM9RpqgZUM9c4KtDTHwrwP2uEFkJ6cuHIINhQzzOKvaq8/3AaLAwBKtQMt3G FvQmSbspml7/Undq3UN26c10awuv+UfA/08qa28paaJPEVY3j/jFYI4GN4u7xpZKdrpf bvqyXO3pIKiorziTLCpFxb2v0crR3UDO0kJyoMuf+HSTh3NIzbGA2vzZc6jYec3r95fg tMIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768905315; x=1769510115; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=AXZwvmj271zYvLNWkodrwZ3eJeR2Z4f2M0MqwFU/dUs=; b=OEjrADN4paQ9ekus9V5KLVWiCSq/wyYETdsio/sAITldqT4bwgDBPCJi4x+cgkAu/H qrc0qGRrvYFo2fETp92N+fFLDeHM/G5Na/jKoWTEwEywJiRp3m1DbHmjX5Iu153hrDuW v0UzrG2WIKllzWA3ekikI+W+WhzEn9WT93C54q0rn9XrMY6kwt1ISAD3rpQPS+DnQa9D h5Egn+EQxDoKWVTQM33dfHs8mN+67dSiIuYVJ27UBxnnJMLogw4ICFTXR2Mm8T/Hc4H7 Y5xqXLKplNCWbL4D0cAXveyP6SXrsjmX9oVWDOk8faZJOzK2fkZPdKiRN5/B7DWBCoAQ 2epg== X-Forwarded-Encrypted: i=1; AJvYcCVL04m5YHwX8NlGUj3lfSxkN3vVLDLeV5x8WVNs3x1JBnu6wFt7DPPPGWDGMRHVb2KYqa6NfUCu4xw=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx1FPy2lr1rLPTps9Igg30p5CKO1k1y4mHT5QJ5LzbGy22bSNxP N7M2D5voWccexbUOSbVFAmfG5sz5/vXy2FRr0FBvRmmYrA1jsAFnYoN9dxVE8e41gQ== X-Gm-Gg: AZuq6aKoV1+BwMqS9PPr0iLT7xBARQgqqbWz/BQRAS26npofUEFBkkQGHTewrpjUEzQ NQ6Qw6INzhvzeDRhBJ4vh/pL3+0LcnqtkZ4qQwcZ2p2fq9LyrYEt/m9YGW7DPNv74GwLE7Vyp7S WoNywMtddOpzI5k0ZYqPKUrlPi8AJBn0J1KSvc6AgohwSosNXOsR0XO1PrmI/ktqV+YwTZPH48L xUTQ48lrLmPHwoY2ExM4SPFBCZx22ZlNAZfXryP3Koe/tabjHbB4sEGXh+mFpsChw/wHW5hr4f8 HPExoQktn8KUh7ZL+26V6P3JSHbC53BTor0eTo7e9AKqj/eXV7RPKJB/FwEQ5A4AhJZ4ThVk5eu 0sMmxnpHJPI3CC3pJP0tEyJQ1XqahJMEY6Z92hx4jkDwK8Bh5hjWjtVhHD4Pi05vCb+S2XEEI56 x07G6VS637f8VOQk7nANlh5skgyQ7Rnc0167RHHV4nvjo+NRMmS499GroJh9WSZptjjMA/gyg2E hzgTV3oAwulGw== X-Received: by 2002:a05:6000:2284:b0:430:fdfc:7ddf with SMTP id ffacd0b85a97d-4358ff611cbmr2037284f8f.42.1768905315398; Tue, 20 Jan 2026 02:35:15 -0800 (PST) Message-ID: <3213454a-38cd-4e5d-8a30-853e37f70c18@suse.com> Date: Tue, 20 Jan 2026 11:35:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen: Expose time_offset in struct arch_shared_info To: Tu Dinh Cc: Anthony PERARD , Andrew Cooper , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk , xen-devel@lists.xenproject.org References: <20260120095657.237-1-ngoc-tu.dinh@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: <20260120095657.237-1-ngoc-tu.dinh@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 20.01.2026 10:57, Tu Dinh wrote: > time_offset is currently always added to wc_sec. This means that without > the actual value of time_offset, guests have no way of knowing what's > the actual host clock. Once the guest clock drifts beyond 1 second, > updates to the guest RTC would themselves change time_offset and make it > impossible to resync guest time to host time. Despite my earlier comments this part of the description looks unchanged. I still don't see why host time (or in fact about any host property) should be exposed to guests. > Since there's no way to add more fields to struct shared_info, the > addition has to be done through struct arch_shared_info instead. Add two > fields in arch_shared_info representing time_offset's low and high > 32-bit halves. Again, despite my earlier question, reasoning of why two halves rather than a (signed) 64-bit value isn't supplied here. > Provide a new feature bit XENFEAT_shared_info_time_offset for this > functionality. > > Signed-off-by: Tu Dinh > --- > v2: Remove unnecessary casts. Did you really? What about ... > --- a/xen/common/time.c > +++ b/xen/common/time.c > @@ -118,6 +118,11 @@ void update_domain_wallclock_time(struct domain *d) > shared_info(d, wc_sec_hi) = sec >> 32; > #endif > > + shared_info(d, arch.time_offset) = > + (uint32_t)d->time_offset.seconds; > + shared_info(d, arch.time_offset_hi) = > + (uint32_t)(d->time_offset.seconds >> 32); ... both of these? Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 20 10:39:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 10:39:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208651.1520786 (Exim 4.92) (envelope-from ) id 1vi98l-0006rd-QE; Tue, 20 Jan 2026 10:39:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208651.1520786; Tue, 20 Jan 2026 10: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 1vi98l-0006rW-Nb; Tue, 20 Jan 2026 10:39:15 +0000 Received: by outflank-mailman (input) for mailman id 1208651; Tue, 20 Jan 2026 10:39: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 1vi98j-0006rQ-Ip for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 10:39:13 +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 3f0f9a3d-f5ec-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 11:39:07 +0100 (CET) Received: from CH0PR03CA0192.namprd03.prod.outlook.com (2603:10b6:610:e4::17) by MW5PR12MB5624.namprd12.prod.outlook.com (2603:10b6:303:19d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 10:39:00 +0000 Received: from CH2PEPF0000009A.namprd02.prod.outlook.com (2603:10b6:610:e4:cafe::73) by CH0PR03CA0192.outlook.office365.com (2603:10b6:610:e4::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.12 via Frontend Transport; Tue, 20 Jan 2026 10:38:27 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CH2PEPF0000009A.mail.protection.outlook.com (10.167.244.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Tue, 20 Jan 2026 10:39:00 +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, 20 Jan 2026 04:38:57 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3f0f9a3d-f5ec-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=wOcKeE2419BUzpaTH5AeIg+btSSqNz7lqFfe6ZuZPjVlNscU2RRrN+t3nqh2aqJB/5uKp04bsSJH7CqCUvkpoFRgfdXec+mDHR8mqmuLYc139CM2j6AvUOWQQRirlP31/6vhI60RbmQK+rz/EldZO1cMGhfR9i/7p4N5I3a/YawduSDWr8zTGUSRkhLpsGn5hBs09eH7hux7D6EHLgtcCssGJdX9NL9CZhnRUC2zufMnQjM+NSiOpIx/mcpYcr3cMAzRF9qU6kLTd8To7CwjAtiv5X7Tgtscefr6eP3G4v6WaeBkZRt1ZmouvB8PIpK64huJJx8t+nFtASmXjh9owQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wUkRTQUOpK2l5eZy1zzqW+mxTNu0ZCipmk7i6pOAx5g=; b=FfPauaPxHCSzQ0aC3F1RR7IiVvildKfHbhw0xUxDrZ9+n9skoCNNv+13ZuVCzn7BIYRBETHGbb7zsm548YldAjTDeQV3V+BD0Ba6jmSSTQbXJ8ImLP1X1eLb2t3FI0RH/EL4AZSRc9XNI0hbaq7TpSlt6PYtR533flnptWwVSlZ3NlxW0zCea4s2vPFPkRrC3hannIkspbM1CcEQFKWFhHav/r7PznlSfm7+12+aHUs4eyU8VW36OQBKwiGcbEmjR8vn/qgYHD71Xg6SSx9jBFmQeJk3tOFqINZjAyFjQO5HxyGZKIt79XeVyzue8LBfOxtEfnoICzxVg7Q8fhvabQ== 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=wUkRTQUOpK2l5eZy1zzqW+mxTNu0ZCipmk7i6pOAx5g=; b=KXi/y67N1UzzlZhTlzzbddn6Uhdde05x703/9SKmIZIq/aaUMNmOS0cBukdF37ypt07uRpZXL3UPfnvFQG1AAKVziIkYQzqfTI66C3S0f+I8eJMph3h0hm/yI6scqjalxrEtQeakz+F9MAZnXvzv65AqODBz94U2SQlyNvfafY0= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 20 Jan 2026 11:38:55 +0100 Message-ID: CC: Andrew Cooper , Anthony PERARD , Michal Orzel , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?= , Doug Goldstein , Subject: Re: [PATCH v4 0/4] Add Kconfig option to remove microcode loading support From: Alejandro Vallejo To: Jan Beulich X-Mailer: aerc 0.20.1 References: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> In-Reply-To: X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PEPF0000009A:EE_|MW5PR12MB5624:EE_ X-MS-Office365-Filtering-Correlation-Id: 5152f203-f16c-4d61-9976-08de58101f7b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700013|7416014|376014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?UlcxTTJuZ3J2cXdwbFNESnlTWTdRb2dZS0VzQzg3WHk5Y0NDSzI4eThEV3du?= =?utf-8?B?UE1jWTh4Mk9jVFlIdjJPdHNqYXF3UHBySURQVm5PVHJMeWpmdlE4dUtRcTlJ?= =?utf-8?B?ZENmU29FcWo4ODFYNGNFclhiZ05SUUtNZko4ZUtrVUdzdDNObWFUSVZ5aE0w?= =?utf-8?B?dnRGWHhNaGpIVlRIR0J1RElOTXM3MkI4Z0Z0aW1sNk8xYi9oUjJoWGR1K01r?= =?utf-8?B?UXRHRzg2RDRFQTlFZ1J6WHRSNHBxbEdVckNTWmNYTFdEcmZnaXVtQ0xqTito?= =?utf-8?B?Y2RVWVVBK2FEQmJwdTFlREh0MGVJVHdZQnZtL25Fekx5R0FVeE1PemwvQXBF?= =?utf-8?B?TFNzRmVjMjF5Nk04UlNzNlhoMk9MazV2U1lIdVZNRHdSekRlOHBsOE1UZVE4?= =?utf-8?B?VGtGdGxKb1VrR2lLdHZ4dDBXTmcyTG55bnBJK1ZWRm5NQWJ6NWpzYXptUWxK?= =?utf-8?B?QkVWR3A3ZEJIOFNpT0R6MElFdjhvYnFUNDkyT3JqRk42Mk9CUUFoZDYxWUNL?= =?utf-8?B?eHd5QWU0ZVlkdkpZcG5ackJWZWlKc254VzJpUHhXdTI0c3VBdU5tcUNucmVW?= =?utf-8?B?Uy9wWGdTS1R6Yk9CRVloU2xGaWp5YTZqR2lIT1F4ZXZyMk15MmpYc2ZjZ1dE?= =?utf-8?B?bmhMeWxGOFVaVTVBdi9zdTA4Vk44eDlFWjJiV0FHV3pFaHV4OFpkMGJ4bXQr?= =?utf-8?B?NzU3ajZEVGF4Wk9VTXY2RDdPbVlMNGZlR3ZVbUFiaTVRWjJSQ2ZCS25hRnBk?= =?utf-8?B?NlNXNnhrYkU5NE1kMWwvVXdaSVlCT3BBZnpUbnlyMkdQeTEzZlpjMkJPTnRK?= =?utf-8?B?ejBjai95RmtzUm9yc1c4Z2dvVUZ5SUZQSm5KUmNCZkljWWI1RlQvVXlhTjBv?= =?utf-8?B?bEdDM3RPd05UdUlEeE1UcVN6cG5WMWVqWlpTaDNlWDVkZHB2WUd6dk5XLytz?= =?utf-8?B?Rm1PN0JGbk4vU2tWUG1uUXhlV2w3Q3IvNk15ckRHMndJN01VMnJ0Skt5S0o2?= =?utf-8?B?TDkyZUEwYWI2MXlwV2J2VXBZOFk1NGpjQmFKYlFWQWJBS1ozWGJ5aXdmM05w?= =?utf-8?B?TDluVmJrL0JGSEdqZ0hGWWEyRzVMNUxKcDlWVzFiNHlhN1ZKQTU4VmhtSGh4?= =?utf-8?B?bmNCWEZpZUREVExLblUyQ04wUS9najk5RFF0UERPMnRhcDgzbW42ZEVCZFc1?= =?utf-8?B?TTJxTzJHVEdRcW5QbGRmZ04zTnVOOXRrSS8rZVdoYjF3MVZFc1NvY2FndHZE?= =?utf-8?B?dTJia25nMDdOVWllZXBoUTZMUndDOEVTd3Y0cVdRMmR0eEdVd0RYWkd3VkxS?= =?utf-8?B?VWsveUVIRy9JeWhnQ1krNlFsUHpIUXpNYWRoQXNIS1BiVXpiQnZYM0FBdzRq?= =?utf-8?B?UnNKQ3lyM2VLQlZBajJvc3haUG11b3NXajZ2YTB2WEJiL0MwT1I1aHJHandt?= =?utf-8?B?NElNWTFSZXFLQ2wrQWRtNFR6alMxa1hFdnFmWkNTeTlua2JmNjI5RG12a3FP?= =?utf-8?B?YXdnTnFnTC9oMUF6dDluQ2swRExKbmxnUzRFQmcxQkU5MktuaCs4aWl6Tmph?= =?utf-8?B?OWlvQmJrVW9MVmUrOG1GS0l3QzFWSG9nRzNuNlJSK3dWazA0Um9qRDExcEtz?= =?utf-8?B?c29mVmNEblBieW5ydG5MZWRRSExQUW9mcHFoQ0Y1ZnNRTDRFWkxNNU0vdS93?= =?utf-8?B?ZjJlcS9PdzNnT1FEWExOL0lzYVF2bEJ3Z2dYT1BrbzcwTVQxbyt3cmp2em1E?= =?utf-8?B?Rms2cmxXcm90akJVa2IxUnRJOVJvbzRwd21hb2JiQWtkczd5WEdwTlM1QWRK?= =?utf-8?B?encwS09nSVV4dkRZYndzS2hCVU5sMkhVSDZMSnl1QVdxYWdtL2dhU2RRVGgy?= =?utf-8?B?MDY0ZVljamllZHlTaDVnY0ZFb3NmaVNDSmI1US9TSE9sd2Y3ZGpSNVQrd2R3?= =?utf-8?B?VXRJTHNhcjBwTFMzNE9TdzZHWFNLbGMrRDRSWEI2VkVjWUVlZXBWWGlYbGdj?= =?utf-8?B?UzRGWjM5a1c4dml2aS9oS00xeWVPUVBGY1BTOXpUVC9SNkhGMnFRcDFKZExn?= =?utf-8?B?SHZ6YUlSelJpTFRmanM3RzBzem1GSGloN2dMQzV5bzYzTEFaenRZcDBldmVa?= =?utf-8?B?QTBTSTU2anVLTWJCWFJKd2wyRGhYdDJtajJ1NkVvaDZuNm5kUEgrN3ovbEMr?= =?utf-8?B?cDBBRXZscnVhRFNsOHkwZmFhclRtUXpvNGlRVEQ1aEtPZ2Y0aHJOdmVybXBi?= =?utf-8?B?bW8wclpUWUVPdzFXclFIT29tS0VRPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(7416014)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 10:39:00.3567 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5152f203-f16c-4d61-9976-08de58101f7b X-MS-Exchange-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: CH2PEPF0000009A.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR12MB5624 On Tue Jan 20, 2026 at 11:20 AM CET, Jan Beulich wrote: > On 20.01.2026 10:38, Alejandro Vallejo wrote: >> The only dependency here is patch 2 going in before patch 3. Everything = else >> can be freely rearranged. > > Is this correct? Didn't you say (confirming what I observed elsewhere a l= ittle > while back) that there's a complaint when a file listed in the exclusions= doesn't > exist anymore (which may have been cppcheck, not Eclair, but still breaki= ng CI)? > IOW can patch 4 really be separate from patch 3? Or, if its description w= as to > be trusted, wouldn't it need to go ahead of what is now patch 3? Doh, you're right, they are out of order. Patch 4 now just removes the excl= usion so it's fine to do it separately. So patch3 <-> patch4. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Tue Jan 20 10:52:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 10:52:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208662.1520796 (Exim 4.92) (envelope-from ) id 1vi9L5-00018P-S2; Tue, 20 Jan 2026 10:51:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208662.1520796; Tue, 20 Jan 2026 10: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 1vi9L5-00018I-PQ; Tue, 20 Jan 2026 10:51:59 +0000 Received: by outflank-mailman (input) for mailman id 1208662; Tue, 20 Jan 2026 10: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 1vi9L4-00018C-Cm for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 10:51:58 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 08c0a3d2-f5ee-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 11:51:55 +0100 (CET) Received: from BY5PR04CA0004.namprd04.prod.outlook.com (2603:10b6:a03:1d0::14) by LV8PR12MB9231.namprd12.prod.outlook.com (2603:10b6:408:192::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 10:51:52 +0000 Received: from SJ1PEPF000023CF.namprd02.prod.outlook.com (2603:10b6:a03:1d0:cafe::8a) by BY5PR04CA0004.outlook.office365.com (2603:10b6:a03:1d0::14) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.12 via Frontend Transport; Tue, 20 Jan 2026 10:51:51 +0000 Received: from satlexmb07.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.9542.4 via Frontend Transport; Tue, 20 Jan 2026 10:51:51 +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, 20 Jan 2026 04:51:50 -0600 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, 20 Jan 2026 02:51:49 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 08c0a3d2-f5ee-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HhDOY8RKrpfI0/StYlIxD+nqfcpebrraGC/KR4SFMvMM1x64iVh4npTsagt1BFbEabIcF47e2AoZ5RuiiG7pph0L/lOnZ3LxNHJkAm3e39f9m8j5g2hpQBSf/XnNYWtGI2JWi+rqAMJaX/HHrwoSqsmmaIqwppVvt6Z24lda0qjC0oR2NltjUTo3tjJghZym9hQ7/2PUblXb2WzQOsCighQG747rzefuf2HAC0cADm7GkfLHSRm57AkmLErCCSIBBN9vBHU1k0mtxWFLVqn031GNpcI42SWI+s3NZpU8/k/2fD9eDTwZcNrGi+lVzKMxuJ0EpD2RtuR0Z99X+YfEPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sBwMM5Pzd6aZtuOlJqfYpYVc/kyOKJSCCZMYqJzWWv8=; b=gM36QiMTmp7bSlgYCBOzDJqRZ5KbIRPEuXAqV5embkTqTOyWh2RsaL5wRVUp9FrYUZh8p+edJ3BaCbcsXRvBq7eQR/zLEYH7tuE4lobqf7tVfkjN6nJKwBMYSWX61Hx5f2YGofESiP15O3uV0XsQfxQ7w8s2+sotr826zYtWD7glryiTA64t8bhRycayDVGrBIzl7NBQN3kzOFNalju3OOIVHWa7WjfjDb8v1mKZz/I8eLDW7A4dBBfBAWuA0c2lpeGAgItfEJMi9WYKXa4e49kgnxx7HYkplU/MyrU4wKGFFXTWL4J+i+oS9gySw5AQb7+OCKiqJ4xbhS8/YgBXIw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sBwMM5Pzd6aZtuOlJqfYpYVc/kyOKJSCCZMYqJzWWv8=; b=OYKd5csoATRZe76iIna/rwnXCvEmtirvQZ2YE6nzmFFwSvlaB1wCzFE5xMsFUxDQ+YYZ7agoSaGG1uWFHwaCbtIC3OmUY/K04ntYteA7qWeMM0DLs4F42SYcJeEsetJy8W+cE9mFdb8gHuVjoNuVqQfKQORpMO0nEDzs0cISN+w= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Michal Orzel To: CC: Michal Orzel , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Subject: [PATCH] xen/arm: Enable GICv3 by default for AArch32 MPU Date: Tue, 20 Jan 2026 11:51:41 +0100 Message-ID: <20260120105141.92578-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: SJ1PEPF000023CF:EE_|LV8PR12MB9231:EE_ X-MS-Office365-Filtering-Correlation-Id: 9ad51d06-3738-4e2b-4a61-08de5811eadc 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?IrXiij1pTDM7h49PTrQuc5UnAxXnkND4FuqwIh6cTvrBaKxG20anZVQZxfdU?= =?us-ascii?Q?0Pg1RkcVmPou2l9xXkWdTEX0IyCfGBfjBGGLFnRoroKjx1SZURSeQStHRyo/?= =?us-ascii?Q?iajJLJY+uhA08EvvnxfwIHXRrvy6uaZz6Ntf78a9F4HX16LXJgbKii0+eJ/G?= =?us-ascii?Q?o/B7SWdaaVrIsS6eTJtkgWQDJvp5U8P1p+OGSSv+A4ceFY5JianH2V+B6APA?= =?us-ascii?Q?ayRjGq3ump2zfTqV20fBiMBKTqwJZ1IH1cC4Tp+/WYrKbiE4NLsw7Wn7awwV?= =?us-ascii?Q?Z9OIOXVlnuYDIta1ri286Ye2rGCCoGPMZ7mghIoLF+67qdq/I8Z/bK3/EEcR?= =?us-ascii?Q?xI1r/KgB0RDxV+gcCTp2FiPuVEXFZPRc3NfzNLZvcNqVKlxX+lx6q2dG90DJ?= =?us-ascii?Q?FzkVsm10uhe73ZatEEEEDx5gI046360LAuSoF5KIqK5iv6msvbp2X3Uxijyz?= =?us-ascii?Q?15DQ8lcVvMK5yda1hAGw3OK3gZN88P6Tgt8YCrPnLIf8EVeXiscYFb8Hp5Q3?= =?us-ascii?Q?5Wsew4HOxtQyLouX/gPbRRIOVitUrk2RqbO92nzM7xwlvqYVtD4T0yiOyGdY?= =?us-ascii?Q?HRrIz+gqywMvyIM5uYJF6rv9tCS+fuK65t/tYlefXOdVZlEp0B840Oa1os5H?= =?us-ascii?Q?7aFaKvAkRgLe0AwkkSYGSgpOEa6dpvmpa89kRO4+WKcJXri1SsG+o4BlsRJa?= =?us-ascii?Q?aHvqcCMdxaoQt7se03PHK7+AYwOzKq36Z617qOWZtcjJdggR1ajR9T82R7vC?= =?us-ascii?Q?pMgBMua824TRqcgHAUfz/6kx98OUVxlbiw42g0jrrR6WFzDV1k4ES3Lj1Dzd?= =?us-ascii?Q?S4D4UEjIJpXp4SDmWFCeQMaLoxcgCqvQ/lQXrRb007PU55Rg593ErKd0GnsI?= =?us-ascii?Q?aAcDAa01TvYQOtap3kuc7PnNUxrsmtXsxWGsMbYJGricVxEocP7O3IARXp+Z?= =?us-ascii?Q?KUMzn3S/uweQBnmpp/Fxo0GIQNAO8ZC/xl/oY4u10MFyLfe/bTYKWyEysg7j?= =?us-ascii?Q?+0eU5oxCP+Cf2iNIdiokAm9aF7DfYGUnR6vRslxj+iq25p+w/S/e3Go0FW6u?= =?us-ascii?Q?OxzyJLlZEUxWEGur/4Rypy3+j0+UWNOxEA4qI+G8Z+E2A4XOa8JHDRCFMKHu?= =?us-ascii?Q?M+G7dmGc/4TVtuRDozaVlB4cVLLIGwLpgsG1FIeCT4WhuA3v4RYcJROFZ+ZA?= =?us-ascii?Q?VoNiZpusUWcbd+3YEPccgCirGjR4eEX6SJREr1nLSsxY7tGeqbnUGX1Xt7id?= =?us-ascii?Q?NQ/gaPfk3vsev9SEENwF2LrWRgexm4VGIDgIEJQ5W7f20ocvsBxfu30ohaHF?= =?us-ascii?Q?a7HjH6KQ6evbl75kMifEUI9xQUmuJYRs2rLf1QmiHG694ELmgcwlR791IPqg?= =?us-ascii?Q?uduKl/JIaEMFczgOtNynehWH+DHh65x3dx8yk4RPvn2EqgphK2C5BSVbY3mt?= =?us-ascii?Q?TLVQ/vtHIqKLIMjrFXKZABIjRW4GacouE7JK6sjBLPl+2Hz5G8y7vAsGQTLb?= =?us-ascii?Q?VaxYuIyfX5CvJZd+os1q/Snrqgkp18mRgcgAAqJNpBau3o/94T3KmiqFONJZ?= =?us-ascii?Q?FY4jamZq2Qzuxv2x5lyu4QViE+D8mphVxsKZZPjs6fq7R5lvrjJxRflEkyu7?= =?us-ascii?Q?eulHNueDMnAGyUEnAWDwZBKlvJ7Je7pHKz72HqrF0q0cbuOUaNc0grKdf2wU?= =?us-ascii?Q?o77wZw=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 10:51:51.0364 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9ad51d06-3738-4e2b-4a61-08de5811eadc X-MS-Exchange-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: SJ1PEPF000023CF.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR12MB9231 All the platforms where ARMv8R AArch32 is being tested use GICv3. Signed-off-by: Michal Orzel --- xen/arch/arm/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 0d81a4d8b437..442d353b4343 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -128,8 +128,7 @@ config GICV2 config GICV3 bool "GICv3 driver" depends on !NEW_VGIC - default n if ARM_32 - default y if ARM_64 + default y if ARM_64 || MPU help Driver for the ARM Generic Interrupt Controller v3. -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 10:52:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 10:52:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208669.1520807 (Exim 4.92) (envelope-from ) id 1vi9Ld-0001aV-4Y; Tue, 20 Jan 2026 10:52:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208669.1520807; Tue, 20 Jan 2026 10:52:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi9Ld-0001aO-0q; Tue, 20 Jan 2026 10:52:33 +0000 Received: by outflank-mailman (input) for mailman id 1208669; Tue, 20 Jan 2026 10:52:32 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi9Lc-0001O6-DL for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 10:52:32 +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 1e90c8b3-f5ee-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 11:52:31 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-4801c1ad878so40711535e9.1 for ; Tue, 20 Jan 2026 02:52:31 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4801e9425e9sm113695465e9.0.2026.01.20.02.52.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jan 2026 02:52:30 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1e90c8b3-f5ee-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768906351; x=1769511151; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=+ShC9hF73Gs3H1X93SkqlY+85cLkohUsLeQhumg1pTY=; b=LU+1fqO0uwtWm+OIO7/0HGXtZi/dZ4mnvQKXwqL8Wx8jaBh5tVdCSgFiL++rBmRqZt WoG9b+ssdyjO3SCT1BHd5N9bFnZqnlZsU7pxRSBYSO9L9yTngVAOQDhkI3Ve3+n8zHmL 8O1Jp0muPpSWax4NteGRSRCkhdiLtBvavJUuq0FETIqIfhsa11U7elPqqJO+Blyk3Ums y2xiFbZEZLhjMjZ2VZxARlPM6FpK1g4UuiHLhPr5m9sATEXNBglBXwotsBYW3Nlc5siE /oosw2l81XcQKifccRLhKiogO2oCl+3dkTSis+rgxBlvH0r/dlKJ3Y5Nw8EOQOU6LIM+ kMkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768906351; x=1769511151; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+ShC9hF73Gs3H1X93SkqlY+85cLkohUsLeQhumg1pTY=; b=DnfvBaaa8/VRTQpWU6tLWF+n6/g7zVODFLUvgcYdU+zrcO76S5/1+xJBFazIh3hkvu z1M7GS0R9mDm2QfLiFiiX/IFiNEkzE1SKVwg7UTi/M/JSdPukDQHt9JW4to7qVq1Rd+4 WzhDgC7tqcM7r2iiIuSpv+Q1x6zfJBWTotDATa4qC9WsTXAkqggVrL2kVXNs5+wNrWhL LxXWOe1E76cNK242RGZYWVVZ59uyACRFKaGKz1j7kOK8FaKpzwLEj2UtAdI4DeYPub1T 6tI/CAvXS2FOahm6MAVB30oXg7E1F7Xz7cCGovguU3xGevm8Z+IRPdKbP2iWPWUBJRiS iz1Q== X-Forwarded-Encrypted: i=1; AJvYcCVytB70zhA3seYWFk3Uxpx75g5Tpx0xBiUEMXt46d3UGmz1NkA9rXrGwBWb5GtSEFmGKkXGxDpixjU=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw/PwQVKZ1iFSsR+pAx7jIDzSBiRTv9dxVwxCetXUVXc6jRSq35 elIPfM1TlroCoMuzlE4sWZvRaZW4nuxwb1CcJJEwyDfoZ/1V2QFV0PgTa7tkmZsOOA== X-Gm-Gg: AY/fxX5dK97Lb3GvyCFey05gLrk1PqxvAPegC5+ao4yIZc4lbnZBsVir1EqCvGvNUy0 S7oP/TWuXxEhoB9iHKaEuub4HtzqT1muIwZ2ocprvsqvwn75alEcjVhl1wcStZjg6O8J+mZkY9k 1BUd762dME/IdQrRmn6Wl3Poufr103wFl4x34tamwNQhVG0c4fSNB+r7O50E82xfZYivph59YNf jisn5OSlojk8qHERB6K7Px0fxlmUCVmDoQR3vgtW4V7GpsZZZ8TmQ+UibTQKqKMNRFvX9j9cemx v+B/7ER3J7xXVeJLCdlj0KtjhyxOzRWYvJmKXtnmRf/qL56o60MhpV3BOZOQbE96/pZhrC/Vg7N SmRrmJusgqdRayv4jHP03QbuaPACzWXgbLeUpHmz8+SdPUi29cO8MHao9/1y6IBoPaqWjAXR1LS f49b0byEU2jJaqeNO+rHsXPs9HyHb5000WrfV+ksyIaNuJc9TKG4z8b1PRqwmWy1UwN4hAP4Zck 5U= X-Received: by 2002:a05:600c:1d14:b0:477:9cdb:e32e with SMTP id 5b1f17b1804b1-4803e7a2cb5mr17875515e9.9.1768906350759; Tue, 20 Jan 2026 02:52:30 -0800 (PST) Message-ID: <5e34118f-af8b-45ca-a5e3-ba214ab101d3@suse.com> Date: Tue, 20 Jan 2026 11:52:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 0/4] Add Kconfig option to remove microcode loading support To: Alejandro Vallejo Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Doug Goldstein , xen-devel@lists.xenproject.org References: <20260120093852.2380-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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 20.01.2026 11:38, Alejandro Vallejo wrote: > On Tue Jan 20, 2026 at 11:20 AM CET, Jan Beulich wrote: >> On 20.01.2026 10:38, Alejandro Vallejo wrote: >>> The only dependency here is patch 2 going in before patch 3. Everything else >>> can be freely rearranged. >> >> Is this correct? Didn't you say (confirming what I observed elsewhere a little >> while back) that there's a complaint when a file listed in the exclusions doesn't >> exist anymore (which may have been cppcheck, not Eclair, but still breaking CI)? >> IOW can patch 4 really be separate from patch 3? Or, if its description was to >> be trusted, wouldn't it need to go ahead of what is now patch 3? > > Doh, you're right, they are out of order. Patch 4 now just removes the exclusion > so it's fine to do it separately. I.e. the description there saying "it's clean" is accurate, and it was excluded for (effectively) no reason? > So patch3 <-> patch4. Noted. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 20 10:53:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 10:53:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208682.1520817 (Exim 4.92) (envelope-from ) id 1vi9Mr-0002Cm-HX; Tue, 20 Jan 2026 10:53:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208682.1520817; Tue, 20 Jan 2026 10:53:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi9Mr-0002Cf-Ep; Tue, 20 Jan 2026 10:53:49 +0000 Received: by outflank-mailman (input) for mailman id 1208682; Tue, 20 Jan 2026 10:53: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 1vi9Mq-0001rI-6s for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 10:53:48 +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 4a8943ab-f5ee-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 11:53:46 +0100 (CET) Received: from BYAPR07CA0042.namprd07.prod.outlook.com (2603:10b6:a03:60::19) by CH8PR12MB9766.namprd12.prod.outlook.com (2603:10b6:610:2b6::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Tue, 20 Jan 2026 10:53:41 +0000 Received: from SJ1PEPF000023CD.namprd02.prod.outlook.com (2603:10b6:a03:60:cafe::ac) by BYAPR07CA0042.outlook.office365.com (2603:10b6:a03:60::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.12 via Frontend Transport; Tue, 20 Jan 2026 10:53:43 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ1PEPF000023CD.mail.protection.outlook.com (10.167.244.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Tue, 20 Jan 2026 10:53: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, 20 Jan 2026 04:53:38 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4a8943ab-f5ee-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Il0sgbMWSnLGa7M7GA3KPFvrh9FISFUPo2JQ5wIzRz8OZN8lWEiZMbst9HmuG9x5/+IOH7q9PCQDsTIP0iXWK4ODFjtFOJyiZUemA8Xx0bHpiCUxlQcsQbHXuHOXb4GGFMjlwN9c2yNalFYTWKFkdy53HFijBeo6lGC+fl7PsSrEUQhGVB0ZKmhH4EC0x7kqUzX5sezUdfOEx7We1snqQAP3IkTEY3tHeFv53VcyjwdU6dVXyhyyFRoQU8T/s0tPodfJqECA7zRLL8z8AjbCKpVIq9mAAJ1MP5gYmDqwCUI3OUdqStXbC4vBrKHxR9+iYidZ6BeQ8vdw3/Y8Jh7YDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=H4LweEFXP9E3ooK1+olyeoE1/jdmNczE+NROlQ0WhAw=; b=jtdfLsXnUHYLb26Vkf/NQzLHWUHTT/WshJ2uFa+pL7JzlDoihmh4WV+reSZM/tjQNFgZfD3aRIRfZsuF2rSVmRzbDq+AM32WyCvQ8I02lL1jxUrUE9ZmPmqXtzrtpNjv1+bvYKdLKWhYRwLUoogJdY1QMTU79UVtrfrbVDTFPDSG8/6EtUh1Wa8W8377pk01C1C+OeailST9aK8EQ+uZPEFT1vXt+2i5wgPbaEkZOWhvfP3JwzccAoW1ivHc2o1DyBsBqypy8jNhe0euca9Rnne+32TAkbez2CSRhrULEpC2ia09hsFEMwdU+VS1sjyda11SA+JTVsDJivrl8SjJbw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H4LweEFXP9E3ooK1+olyeoE1/jdmNczE+NROlQ0WhAw=; b=vJkCJYVubRLycHIwFzO7NTFtol4pA4j0PdiN3KnJjxNwx81B1dKScovBS+1t2BkZ5JU+I7huoaZXpzyE3ivEkRQMnlDIIi8MMAbrfNiKj8cPuZWQjwg4WrbBQXC+d6GcNERoUes1byDzXcQMXTorXUkKtTX6KfJbAhsQmzPLwzE= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 20 Jan 2026 11:53:36 +0100 Message-ID: To: Alejandro Vallejo , CC: Doug Goldstein , Stefano Stabellini , Victor Lira Subject: Re: [PATCH v4 5/5] automation: Disable ucode loading on AMD's analysis run From: Alejandro Vallejo X-Mailer: aerc 0.20.1 References: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> <20260120093852.2380-6-alejandro.garciavallejo@amd.com> In-Reply-To: <20260120093852.2380-6-alejandro.garciavallejo@amd.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: SJ1PEPF000023CD:EE_|CH8PR12MB9766:EE_ X-MS-Office365-Filtering-Correlation-Id: 345686a1-c2aa-4322-40e4-08de58122c64 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?Q0dtcDczOFNGbS9ZcURETVl4MGFNNFFoa2NldUhLVTFVVkZJWHdEc2FBRFlS?= =?utf-8?B?ZmFUM3pTNzB4ampVdmJLY1EzZmh6ZkdBU01VZG11OUI4aDEzR01URVREbXBI?= =?utf-8?B?YkNEaEZXcWVUNmQzcW4wQWhWSVc0cEdXTUNBQ3FjWUNoTWhVR0NFYlRhN0V2?= =?utf-8?B?cVNMcStRMDdhcXFDVzNRTDVHQnVEMDhscENkQmp1SGN2eWNqMjRxOXpwRUdO?= =?utf-8?B?NytCYk9OaUVmVE1yZWsrQ1RKRjVwYWJoejVOSktYazVLQVJsUHp4UFJmZWk2?= =?utf-8?B?dm12dENTWm1yME96a0NxOTRvZU02ZHg4QldkMmdmb3JzM2krenhoSWVxZjVQ?= =?utf-8?B?UEVKZzU2T3lFTWZHODRqZzVuNjVYQXpLdnkxU3lsbzlMMVhhUW1oZWhTOW9z?= =?utf-8?B?ZE0xZ2ZjajB0OW5PcUtycm8zQkM2cFFLWnR2V2RqOVl1QUo5RU1HUnM2OTFR?= =?utf-8?B?M2hiNC9CWGw5WkpqQ1ZkTzM1L3BMeUZwNkFEcHlnOUIybGpDTDhHYkMvL2hl?= =?utf-8?B?NU5ac2FSTDFnekNuVWt6bXdaakFUL3dkTlVNRFl2Qll6SlRKUmhNQ3ozQkcv?= =?utf-8?B?S1h3WXJSdVF2ZFVma2x1V3FmdmVhckdrMmlpNFJ0Q3I4VUlaT3Y5SEhxaXBG?= =?utf-8?B?aVhyejArbkFiMm5zbUJGY2VFeUhQQS92aExTQ0Rxc2IvMWFubGlJd1l2R2JU?= =?utf-8?B?aHk3N1RtM2w5cElmTlNpcm1vaVlZSXM5d3RiMWVFeVE4elhmdjdGQzZ3YVRI?= =?utf-8?B?MndDS3BqMTBjTmdSK1BqYyt5WXpWQzdMSnNCM2F0NElOYWtRVVc2RUczSXkr?= =?utf-8?B?STIrYmcvS3BLR1BjM2gzZndVUE5pbW82M09mQ1ZCNmRzclVwT2ZHV0tzTE5O?= =?utf-8?B?NEF0TnE5V3BvSUR1dS9DZlFMdVBIQUdHcExEejZ6bWVGK1oxdHpTZW1sSFBZ?= =?utf-8?B?cEVYeEluT2lwcG9YWFJjaWxzandrbmJxVU5YSytQeXIrcTJHcW5JWWEySzUw?= =?utf-8?B?YXg1N0N2ZnVDL2xYYnBEMjdKYmlZT0ZJUmZsaTZ6TExPZDNkVW1PQ1YzeTFG?= =?utf-8?B?V2hGQzBDQi82WmkzWmZtVEw2c1hHV0ZFZDdGbXB4RFdoTHNSU3JsaHBkUUUw?= =?utf-8?B?VDZici9EMVlVOWhTVi8vblE4RGRSams2MFhreXNNSTJ3YW1wL0Y3RFUrQnJX?= =?utf-8?B?c0JlMzhoNlRpRFoyM3hpcVJTWEdyMnFXVktYbzlET2Rmd2JFRHlQSHdYd0V6?= =?utf-8?B?d3hDVWJtUGlNbU4xZ1hHSmxJUGtNZ3htcWpiOFZzMU55Vnl6WDNSZk9xZE11?= =?utf-8?B?WU1qbWpXZHhQTExwMU9JQTc3c0NTSFVRTHUwTE1menhiS3JnSmVoOThrUHhq?= =?utf-8?B?RVc1SkhHNUIwcEFQZ1VSR2lPK2tTejV2Y1RZVmpWTStFT3owRFQxdmlPZGF4?= =?utf-8?B?RUxaZFhzVzBHT2cwNnVIZm1aaUVZNHpyak14bDFtMmNJWVJlODg5U24vdkwx?= =?utf-8?B?emdqQ291MkFBdGQxM1hNZzU5OHArWVEvT3pMeDRCR2NJdVlNd1BrWURpaGxw?= =?utf-8?B?WU1RRTl3WERZbVpRUlBqZmYrRHVwendueVdyeWtyckZjRWY0OUdmZnNVUnJy?= =?utf-8?B?NHBmNG94YmNqOWJRT1ZDcGNEaXlWdExUdWRpcVdoZStmSTZJZXZKRkVOblAv?= =?utf-8?B?N21ab2hNaXJqeTFnWU9zUU1lK0dTSGpDREM2OVZ1eWttSnZkcUxMbDArdWE4?= =?utf-8?B?cXloTjJLNGJRRTJ3bXIrK0JtQ2RjTnFJNWFwWjJ4bVdHR3gwLytyb1ZNbytU?= =?utf-8?B?bHB6K2ZrQ1hPZDVmN2RWcXhsZ29KTS8wbUlvZnFaZ0UxaU91S1FKV2NJSmx6?= =?utf-8?B?VTBEVlJyMXV6eUkzVUpnMXo1SmNNcHJkbGc0WmJqN3I5Y1FCUk8xSDRCL3o1?= =?utf-8?B?SUlIUjI2Z09IakJRdTRoS3Bid1VtRkErcnF0SGxDZk5CVjYxcDhraTZlVkZn?= =?utf-8?B?cHN4YTdaVDJDdzNuQzFWbEkyYnVZNGpuSll5WVJWcWwzUk5JUHpaN2VVdmFa?= =?utf-8?B?ekdNUXZRblNiU2NhbUlzMGI1UUFENU11cmwzOEllNitnM0tkbWdHLzNYZDk5?= =?utf-8?B?VEU0VThYTHdJekk5Z1Z1ZEdmbC9SNjBpTVpQOEQyWHJmVW5YNW9oNEJpT3Zt?= =?utf-8?B?TnU4L25XK0pkZVczL1pGZnhGVVZQcVJpa3hNb0dIS1FYbmhORFU4WE9BQ29i?= =?utf-8?B?ZjZLcUNMUnVhVU1CSFA5dFQ3YXBBPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 10:53:40.9796 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 345686a1-c2aa-4322-40e4-08de58122c64 X-MS-Exchange-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: SJ1PEPF000023CD.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH8PR12MB9766 +Victor On Tue Jan 20, 2026 at 10:38 AM CET, Alejandro Vallejo wrote: > Explicitly set CONFIG_MICROCODE_LOADING=3Dn > > Signed-off-by: Alejandro Vallejo > --- > automation/gitlab-ci/analyze.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/automation/gitlab-ci/analyze.yaml b/automation/gitlab-ci/ana= lyze.yaml > index a472692fcb..b3395e2da7 100644 > --- a/automation/gitlab-ci/analyze.yaml > +++ b/automation/gitlab-ci/analyze.yaml > @@ -93,6 +93,7 @@ eclair-x86_64-amd: > CONFIG_DEBUG_LOCKS=3Dn > CONFIG_SCRUB_DEBUG=3Dn > CONFIG_XMEM_POOL_POISON=3Dn > + CONFIG_MICROCODE_LOADING=3Dn > rules: > - if: $ECLAIR_SAFETY > when: always From xen-devel-bounces@lists.xenproject.org Tue Jan 20 11:03:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 11:03:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208706.1520855 (Exim 4.92) (envelope-from ) id 1vi9W9-0004II-N6; Tue, 20 Jan 2026 11:03:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208706.1520855; Tue, 20 Jan 2026 11:03:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi9W9-0004IB-KO; Tue, 20 Jan 2026 11:03:25 +0000 Received: by outflank-mailman (input) for mailman id 1208706; Tue, 20 Jan 2026 11: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 1vi9W7-0004I5-FU for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 11:03:23 +0000 Received: from CY3PR05CU001.outbound.protection.outlook.com (mail-westcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c112::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a0f973f4-f5ef-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 12:03:20 +0100 (CET) Received: from BLAPR03CA0074.namprd03.prod.outlook.com (2603:10b6:208:329::19) by DS0PR12MB6606.namprd12.prod.outlook.com (2603:10b6:8:d2::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9456.14; Tue, 20 Jan 2026 11:03:16 +0000 Received: from MN1PEPF0000ECDA.namprd02.prod.outlook.com (2603:10b6:208:329:cafe::7b) by BLAPR03CA0074.outlook.office365.com (2603:10b6:208:329::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.12 via Frontend Transport; Tue, 20 Jan 2026 11:03:14 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by MN1PEPF0000ECDA.mail.protection.outlook.com (10.167.242.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Tue, 20 Jan 2026 11:03:16 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 20 Jan 2026 05:03:15 -0600 Received: from localhost (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_256_GCM_SHA384) id 15.2.2562.17; Tue, 20 Jan 2026 03:03:13 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a0f973f4-f5ef-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fh+8lXjhssQVlN3kODVZFf5dOVqIG0PSBoTKnYqvsSATGJfA4vE0Ph3HyPDhOI/yZoPLKMyiCo4was9x4eKmf2k4osR8+wasFf9HiaoqnUxJ9LvOqbAC4aXEiVd0ctTeTRb+/S/mp6sVm6+Zw7cUdh1Wtw3CnGU6uyjQnyixLlTH/etPz9qWhpNydzJVRhWaplSS5QL7IaubOMoWHTRM3pGecsg8jC5IndqI60acBhcABDFGhjfHPj+5zCyfp0DJfQwEVFaMLt7efSgnA/aWzB/JWl5L8ins+Gc36q4zV/yfb3vLwVlHKASAd9iATbtm4+mIEPOshZBjVwVog1fEww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qAaqlEIFeuFOikFHuyswMwv7u/t3Ra0RT6WIQ1l1vk8=; b=vLgQmU2eBaR33p6sX/tKTLYgyzY+484FHnHFG4pFUsK+FuFmUT0hOlHa6vYT7kHD4tRy4DrT8rcjSfSNcEBuIAbWuD0Ly7QTnWNQFzcdEb/PynPgGo8YY34iXJXXB/yFj8gy+IPgmJx7+zHGLzxlN3uw82Y/mp3F2eZ78yfOMd+acYIx20qh5vv6Ys+rulKDw9kXWSPILJshV5nnESAeT0/MCPCoywE3KhnQVAnsnu9qvnO7zadmwB1IMLkJpmeYNs+LQzw7KDgtKyNdUlfBjnIVfOQ8oD6szPc2sEeLD7s06OA/zRGpp1eNbMa0YiO7I9Cjg8H5IC5Sr/w8+8VjOg== 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=qAaqlEIFeuFOikFHuyswMwv7u/t3Ra0RT6WIQ1l1vk8=; b=X6KCLfHxumXEHVn4hT+/GQnoDm2EQ1xQdX24qM+eE+UEiBdkkLz1zNfVKgOxJh1wR7Jb6nBTAwzICwbDxxQICnb2gZYbjbyvFqfWjKpKDZKm8+hsQfjvorJ3Mjkw3Pv3H+9+q9Szrfe9eNSEW/F0aRSKKIUhgf3b2DizHOshmE8= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Tue, 20 Jan 2026 12:03:11 +0100 Message-ID: CC: Andrew Cooper , Anthony PERARD , Michal Orzel , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?= , Doug Goldstein , Subject: Re: [PATCH v4 0/4] Add Kconfig option to remove microcode loading support From: Alejandro Vallejo To: Jan Beulich X-Mailer: aerc 0.20.1 References: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> <5e34118f-af8b-45ca-a5e3-ba214ab101d3@suse.com> In-Reply-To: <5e34118f-af8b-45ca-a5e3-ba214ab101d3@suse.com> X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb09.amd.com (10.181.42.218) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN1PEPF0000ECDA:EE_|DS0PR12MB6606:EE_ X-MS-Office365-Filtering-Correlation-Id: c861e593-3bfe-4c56-28c3-08de58138336 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700013|1800799024|7416014|376014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?YThSZEt3b0RDb3c1ZElMNTErZThRNEVFQ0NsbDVwK0h0TzVvQkUxRVBtOVEy?= =?utf-8?B?MjcyaWNyeHpQcjBtSzBZYkhhS3ZoeEhyNGUzbTZ1Z1F6ZWE3eU1laHo5bTdm?= =?utf-8?B?YWcrajdTQVhMRFVESzVxQXFLbWNqQ2NWZ2ZnaW1CMWhSLy9pRHBMZTBHcUFB?= =?utf-8?B?bncrdmVoWFVkTHVNNFR5cGZtMmV3RFFNU0k3K01nMEUyNUlwNXU5ZFpGeUt2?= =?utf-8?B?MFd2UkphbUZkMjF3UDZaei9QSTJLUDZkVVA2WXJyR2RibVJhOTdRbFFBcVBW?= =?utf-8?B?OE12NjlaUzY5Q3dweTFkZDlwVFFRUjJpci8wR2sxTjdmYTZHM0xLRXlmOFNq?= =?utf-8?B?c2U2Qi9WZEhHeFhrWVBBM0pHTlNPdkNxY2VXaHZZQUI0M0wwMjFZR0pRc3pC?= =?utf-8?B?bmJSZ3dYQ0hocGdsNGh5dmxDTE96eFNSUUQxaWkzSEZ5SjNMdXRoZDVqT0Ev?= =?utf-8?B?THRFc0NZRmtNSkErSFcyTjZheC9jbkVVRVZwZU40WDFBbkNvcXNVaG9rNDFt?= =?utf-8?B?dFlOU2h6SlNmVm11UVRsek9xQUFvWDJCNEtuNE56eFhyN1hHZWhmQXZtOWYz?= =?utf-8?B?QkU0R2svMW5NRFV3ck5jSS9zdjdUWDFrd0tiMnNNZFhGMjQyQ3BpeUEzNktv?= =?utf-8?B?ZWdib0RSdUxlWTg1aWRhTE9EWUtWS21KRllJemo4K2ZTWHVPb2pEWlE1Uk04?= =?utf-8?B?RGJkWlFwVkdETnJKNTlPdStLUmJIN252cDcwMHAxR0FvZkk0M2poNjhDMDh6?= =?utf-8?B?dFp2VkVHYXVTaHoxZ25KeFRlWFZnR3ZITEFRd2FOdVMwVFdhOVFVRzA5azNR?= =?utf-8?B?Skovb25LZmpVQVgrczhDMC9oNndxVXFsL25xNHBSaXFzR3NzdksrR0ZXWVJr?= =?utf-8?B?NlkxVVBpMi83dS9seFZPZWpmRThvUkNudFNGT3RPZG80ZG82QllweEFPMmtC?= =?utf-8?B?cWozRUk0QmtWY1k1QVlvRStLanFuK2ZhVHJjZEpMbk4xZmF3bzMvUW1ZV2R0?= =?utf-8?B?Q2NQQmxWc2xVY05yV0RZc0RpVUlKeGE4a1hZVkhMeTJ5NXhYVG0xcWxjeTVt?= =?utf-8?B?aVQ2ZndCdU5Sc08vV1hGYityNWRoWUtoWktNdGo3S0lmKy9yNVp0a2YzNjg2?= =?utf-8?B?clVvVGh1Rk5QbnBmNFQ4NGs0R2E2aElhZWJQdDZabHF6QUU0T0R3K25pNGtL?= =?utf-8?B?b0p5S0ZxSU9ROTducVlyckRFU3JvUHJ3d2xYbm1ZbmlLYmpScnMrZTUveVpm?= =?utf-8?B?WllPQ2lKTFNjZDFQMTdXdTl2WXN4Z1ZSQXUrZE5Vb1VDaWcweHlSN29jbDIx?= =?utf-8?B?U2toUjdNOTRXV0lUaUtUWnRZUVhiL3Vhc25pTms2MFdkOHNCeTRZMllyeVI1?= =?utf-8?B?ZFY3VFUxZ1BQcit0cUNMcWJlMVNkNituditUUXFPNXYveEh4TFFqUzFDT25P?= =?utf-8?B?ZVpFb1VaL2JxUi9INitGeGZBNG9hQWRQVG9Jd09ldy9ZUEFLZHRMb04xenZV?= =?utf-8?B?dHNBTjhPUlRBcGFDajNnSFd2QlBlRFlGUTNMK05URWFnUFQ5VENUZ01qVzVr?= =?utf-8?B?WVRkQVJDZHdqTnBOV0xJL1JXOG9ZL2dXc1pEL0g1aFJVVzhzbC84MVNCVVRF?= =?utf-8?B?ZU1hdlRrUHhnUldXUXNubU9vZ0lUZ21ZM01mUlhVSkxLWU85Y2lobmU2QzZy?= =?utf-8?B?M0dtYUZDR2NXeDkwM3ZuMk5WbWNtbEVOTjJmU3ZPTjE1a3A0c1BjV1VXczcy?= =?utf-8?B?aEJzM2pJQWE1Tm4rQzFrQlIvZzlRTmlPam5lcitpOGJRd3oxb1U0UHcrU1pD?= =?utf-8?B?TzFsSFY3VFlmSFFqeStmYWFGMkp0WU5UaXFGdC9ESjNxM3NaTFZBTnJSNGc0?= =?utf-8?B?V1JmZTdqdjlYK29mam5WNUpjaVVWQ1pzZ2JBaDVzZXBKOXdKY2toWWswcTNV?= =?utf-8?B?ZkdzUDNVSDVyYmIzazVKUzVXTXo5K3ZEZVEwMmJrTWkyd3lzaEpiYXJFTCt1?= =?utf-8?B?ZDdnWER1WFVhSFlCNW1LYkg5bzhsSm5hS3RPajBIODFqMFF6djV5cnk4aU40?= =?utf-8?B?alpzWGdZdnlmbEFJN3l5V0hPc1NhaTR3ZXJLbFd2Z1c0Qk9zbWQ3dy9iM0xm?= =?utf-8?B?UVRsdG44M1RZU2U5TzRKR05pSEpGNWc0M2lhY3pBdjcxNXdtQzZnbmJmQXV6?= =?utf-8?B?aEcxUkZZRnFzeXQwT1U5NWlyZFJTenZnQVV0a3RCNW1MSFFBdUErS0Y2dWJ2?= =?utf-8?B?bXJQNHI2VERGbEoxazhkQUphSTFRPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(7416014)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 11:03:16.1735 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c861e593-3bfe-4c56-28c3-08de58138336 X-MS-Exchange-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: MN1PEPF0000ECDA.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6606 On Tue Jan 20, 2026 at 11:52 AM CET, Jan Beulich wrote: > On 20.01.2026 11:38, Alejandro Vallejo wrote: >> On Tue Jan 20, 2026 at 11:20 AM CET, Jan Beulich wrote: >>> On 20.01.2026 10:38, Alejandro Vallejo wrote: >>>> The only dependency here is patch 2 going in before patch 3. Everythin= g else >>>> can be freely rearranged. >>> >>> Is this correct? Didn't you say (confirming what I observed elsewhere a= little >>> while back) that there's a complaint when a file listed in the exclusio= ns doesn't >>> exist anymore (which may have been cppcheck, not Eclair, but still brea= king CI)? >>> IOW can patch 4 really be separate from patch 3? Or, if its description= was to >>> be trusted, wouldn't it need to go ahead of what is now patch 3? >>=20 >> Doh, you're right, they are out of order. Patch 4 now just removes the e= xclusion >> so it's fine to do it separately. > > I.e. the description there saying "it's clean" is accurate, and it was ex= cluded > for (effectively) no reason? All I can say is that I looked at the report after running Eclair and found= no trace of earlycpio.c in the violations. It's not clean, but I don't think i= t is as of now. As to why it was excluded in the first place, your guess is as good as mine= . Maybe all decompressors were excluded regardless of them being clean or not (e.g: zstd is also excluded). Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Tue Jan 20 11:08:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 11:08:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208714.1520865 (Exim 4.92) (envelope-from ) id 1vi9bQ-00056a-C5; Tue, 20 Jan 2026 11:08:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208714.1520865; Tue, 20 Jan 2026 11:08:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi9bQ-00056T-7y; Tue, 20 Jan 2026 11:08:52 +0000 Received: by outflank-mailman (input) for mailman id 1208714; Tue, 20 Jan 2026 11: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 1vi9bP-00056N-H0 for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 11:08:51 +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 65a3d72e-f5f0-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 12:08:49 +0100 (CET) Received: from DU2PR04CA0185.eurprd04.prod.outlook.com (2603:10a6:10:28d::10) by PAWPR08MB11509.eurprd08.prod.outlook.com (2603:10a6:102:511::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 11:08:46 +0000 Received: from DB1PEPF000509EA.eurprd03.prod.outlook.com (2603:10a6:10:28d:cafe::e1) by DU2PR04CA0185.outlook.office365.com (2603:10a6:10:28d::10) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.12 via Frontend Transport; Tue, 20 Jan 2026 11:08:46 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by DB1PEPF000509EA.mail.protection.outlook.com (10.167.242.68) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Tue, 20 Jan 2026 11:08:46 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by DBAPR08MB5640.eurprd08.prod.outlook.com (2603:10a6:10:1a3::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 11:07:43 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%4]) with mapi id 15.20.9520.010; Tue, 20 Jan 2026 11:07:43 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 65a3d72e-f5f0-11f0-b15e-2bf370ae4941 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=LdVVr5o0RYrpa1lU6vjtfqGnXpQHUN8gFTfav7myc9+AUVs9L0eBg6rn6pcXQ67w5sk5SaWIUD1P/DqbOjY1+gesg7/HyL0VeMsxEYWusvSEzs/7nIB6kj5/JSa09gLriJ0fYRgZNkKaRd5yOrR4o9tLdo7k8oeNLnlezUcdcaMLoHV6W9DMKX5cicwMttwr1mcbPuJO48kGpKHZdsIB4o+8X6R92A2YMqdTvzuaQzjO13CuxldOA32Yjvc11GfNsUxmGcSzGN4WB8RothotR8MV/VH/8UMx1Fd1eTS6eb/qyrhcKVO/sIR0GhL0aP1no4zJJguABpTwTSr2yVJ3oQ== 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=MnlXrm8hi2MTYFnU7Ey6jascFlzfZIWdJJd8IOCTS3I=; b=M8Chs73Oz8C66ypfP8PrQ163lgFA+QznVYWgtNo5ft8jYnEh3j/o5xIl/+oPIE2r3QToUz/ARKzRLdK3KPtx9RfO4Bt+TMm+ewmMFH/07nfAfljn5Po5W1uFdOoLLg/WEr0Bcz8ajD6ZNgAfO04gPBQ/VAVJbYFnltblguArtNap7V3um3i+EsdRMT3MYN6wFIqpLav7aZV/CblpppuClfObkDclLlwNKkE70qShO/fUSIVMKSFQVl+QlkaNsQcR+lbbI+Qtn/9eQ8CLvJJhDKxrtMigsD5wM99fkyosW9udL4n/7DsjsNqpag8rELH9YCkeePpCjDZqd6iijU3bFw== 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=MnlXrm8hi2MTYFnU7Ey6jascFlzfZIWdJJd8IOCTS3I=; b=ZJbQdwEuZFbgEj5aLTiYFI6wKKtJzTKoTHWxxjllrSgyMazwwnq633sGKCPT+tuDitTpPSIl4UtAdGLJWTRSwjqO7YL/0piT38mc/TIKGDsVG6bFv254Ovt1v33WvsM4/zRHHqiFVVrfwczfHUrFwzr9ow7Dc/+aohYJQm+IcNA= 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=HYAihqnErt1IIg3D+WysR4oidZaX+6RB4ekB8uZ9M8B5zbnaVYfSuYUZNG7heGcdIijr9aGIqSJmAy1hOwNsphnArTAu6zGJN6JIBXYutpnluQ07bcYbR8SZ8gW6lYwuiN+2+HlBYnVv7SHBChYdHqhzVzO6+HT0+KcxQhxNaICNhBLEawCZ044V2ZQbSonVWtsi2LEqXQAxKepkvRZw+991sL9wnigd890fl9YAlJ8DQC4bSHy/zu1jjlqvkUbSPhbv387XUhWcM+7mO4fhAyUM4xaQ3txECrCzBR2e/W/9lYdByJ1sN+TQzVZsR6VX7/h8z8+mqfcVFyGMBmkUmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MnlXrm8hi2MTYFnU7Ey6jascFlzfZIWdJJd8IOCTS3I=; b=UpxNyc+mIltCHSq7vYAGiwJ4DHZvBcUfzGW1r37FxoeXZ7yCsrDD73FJl87RSI1HCTTeQ1NfWzKGPIqkgGRHZZFaB6VQE8j0ae9NBomS8FWTJRtLYzNwOMMh9hYt5dDqMrARyITW9Q0JdkkvchZmXX+p3LiHUxrGCUZxwO+BnQ2UtpZr3m7pO3S8eCITOgiFNeBAxDCX16a+qlo/wnwBcVv8tfk8ycz0ZFQaJAOhpN9pHNET9JfrAlsdXrgNQyWikMYsnAxLL+zCAzjVq30GAFwQlPWwriFxmJy2TU8KUTZcNTWNxesxBYJbBZ5Iucqy6qGFpprc6YoHd+WCfTC3Sw== 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=MnlXrm8hi2MTYFnU7Ey6jascFlzfZIWdJJd8IOCTS3I=; b=ZJbQdwEuZFbgEj5aLTiYFI6wKKtJzTKoTHWxxjllrSgyMazwwnq633sGKCPT+tuDitTpPSIl4UtAdGLJWTRSwjqO7YL/0piT38mc/TIKGDsVG6bFv254Ovt1v33WvsM4/zRHHqiFVVrfwczfHUrFwzr9ow7Dc/+aohYJQm+IcNA= From: Bertrand Marquis To: Michal Orzel CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Volodymyr Babchuk Subject: Re: [PATCH] xen/arm: Enable GICv3 by default for AArch32 MPU Thread-Topic: [PATCH] xen/arm: Enable GICv3 by default for AArch32 MPU Thread-Index: AQHcifrM+5nrExe0Qka6ts4AH9yua7Va5fwA Date: Tue, 20 Jan 2026 11:07:43 +0000 Message-ID: <02BB90FA-2B62-49EC-B131-11C17252D442@arm.com> References: <20260120105141.92578-1-michal.orzel@amd.com> In-Reply-To: <20260120105141.92578-1-michal.orzel@amd.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.300.41.1.7) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|DBAPR08MB5640:EE_|DB1PEPF000509EA:EE_|PAWPR08MB11509:EE_ X-MS-Office365-Filtering-Correlation-Id: b0395804-9884-4f25-ffc0-08de58144831 x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|1800799024|376014|366016|38070700021; X-Microsoft-Antispam-Message-Info-Original: =?us-ascii?Q?7UY0Kbj551d6koMdMSOGTObrYi/wcjqV9raLTpcbkU/VM2Ke6BZZAS/SZORU?= =?us-ascii?Q?8EcxTnfb5Ik8QPQloH0XHq8wPWqQvfa4RuhxqNXdCQuUtibzp3IlC741E8Rr?= =?us-ascii?Q?jPJ8NnZO3VOndfDdaSXikU2NdgVUH2Vi1jxi4yBl7NGqDSiGR81udi9QZcMy?= =?us-ascii?Q?o5wrpvPnpd/r+JYKoGWVkCg4ldxk3QBHw39fNkBgEg7BIeSphGEHmUYoQM2o?= =?us-ascii?Q?tDN6Ux5mMKE3ybR2MRLAw/Vr/FJaOH5gY/q21Y3rMmxHv5H9rJfZIhEUOZXI?= =?us-ascii?Q?+nYqST/gQKGrKxf60vu9riUYQnJ8yYNqcugtUHkoaE7eqkUXBjxz0zyxELHb?= =?us-ascii?Q?Dwkl0VSykhIx3OhodqYAiC7IbfZp7xaN9VD6+DIcjRO55mzFyYRgsFeZUGHl?= =?us-ascii?Q?8fwXvf2sUbpz6Q+nyWt1RntZ2/marZYml7gI0LJkQg9AIjEfS9106s6kSs+V?= =?us-ascii?Q?lwhZWRpKYLhsrq5zGYNGaaECVp4Brw4wZamUXYqvIC9BjTsQwGuJa7j27Shg?= =?us-ascii?Q?lCoTjcijP0x9/D1fij/0tN1Sw79pz2SW5dqsN1fS5zF09NykGaoEMGYxr/vt?= =?us-ascii?Q?asWlRW1YTv+nyctT1k3SoTyZn/7PUwCY4joTKsFEZLND3VbYO+5E0BVNeEOW?= =?us-ascii?Q?U4V35j9xJErqaGWpKNr5WV779st91MyHDWLOrLiyCYASmJvSZOsUo3BlvhIZ?= =?us-ascii?Q?6F4fpz+20tqm39O+6mlbMPLx+tDuUEkRw7zeEyWz9S1EKoJyMrvnfpfTq9IM?= =?us-ascii?Q?NKIWlKINWByB24OkXkV5I7S89WkGDUQMZBHQ3MyTjxpPu4IGeS+1z/hgvPfT?= =?us-ascii?Q?iDISx1wb1oXYd0NebT7VukxNDEOMggErZImkBHOQh2Rx2LzZelL938tEvNEK?= =?us-ascii?Q?nG1bS/eeMPCT1xjgDmKRlXjzeRQYqPfz/dPSJTaMwTobU21uJ/CdfnNYUwK5?= =?us-ascii?Q?eblUirJeRifINxtgVzTEk3ASQGcgUyR0CXBnY5MZuh5Aw/4U+umHnAba1qP1?= =?us-ascii?Q?4MINtCYpk20jE2fTavzn9vR7EchgSmd9k4PhUcmZF+ULZZYqDeJARdaX7ujF?= =?us-ascii?Q?uyJXWgKpex7Mp8NErV2l9by2Lt0xI/OdYcY9u3hQ5EpFBQxaQ7qKK/O9hIcb?= =?us-ascii?Q?asPxip8hYoNRO0iSl/z6gTqKutw0Sn0TXdQTKv0pFk+zVHTQ2OAwvOf4m6zh?= =?us-ascii?Q?is9slXUS2O/+2xEbubhabv3bGq0SoH52HX7r5KSMW+Rdj1AwOLCaD61nRXuh?= =?us-ascii?Q?hsiZc6HSyQ8Sh6aifzlSWlegJuI+zB3C0GaUnJxKe0rt/7gWnZh6+n2/V0Iv?= =?us-ascii?Q?MpAd/RdEOkandNJIjhewcl33yZ2ydD7dnSzJFol9hRHaOmjCFOnwGuVm8VfH?= =?us-ascii?Q?dEiWxFNopQ1mKIe3GmaPQ0Uj8iOFmoGr9sb85oJf071uMS/8FZY3u7UFBtqP?= =?us-ascii?Q?aM+J6mcC6QqM5pYf82xZ1okGY9lLNmqZGoUfCJXKcWswwjmRcbn/kmJAOVvq?= =?us-ascii?Q?Q8F83hD+TZ3xjS61UP4qhPEor9d7ZC1NBTJvUg1Jz79jj9/eyx5NA/Ci6Mvl?= =?us-ascii?Q?b9ukyvRDbcFBwUBxco59CCIzUrzJPtXF7QVEAJd90hyvlpWJj3+pRTR2my24?= =?us-ascii?Q?GfrB0CKzIwNh4YEnJkGTnuQ=3D?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700021);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: DBAPR08MB5640 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB1PEPF000509EA.eurprd03.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: cc71b0c9-02cf-40ed-a166-08de58142269 X-Microsoft-Antispam: BCL:0;ARA:13230040|35042699022|376014|1800799024|82310400026|36860700013|14060799003|7053199007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?sjxknPM0NthELJ5SfklzfFQ+sqUF6uv9oINcna1QcWLoRaINUKNC3d28zPIu?= =?us-ascii?Q?VWK3uO2giF16xRRtqL5OaPf3vf97v/OjWpjP4uld1ygrlNomi8tB929aKs/2?= =?us-ascii?Q?wNj+rq9JxJMuzMWjrFJELHFwtTl2ns6JpDE70pUoMZNuvo6VqVp4CeJqK9l7?= =?us-ascii?Q?J7pFimSV9xo1BpiDrZgmxzlUHuORsRMdvqrX//Hmw7xx2tuBXoCnROVl4+aj?= =?us-ascii?Q?hNJ1kBa8/dPgMiTW18KLibaYRLbak8CdqdEzwGqTyyH/fhjz9p+Pekv9Cvo7?= =?us-ascii?Q?drdp3Wcoso2djR/QaknraACUvQk4izf9acw0z7HJwlm0Kz6XdQxOiiwtkgVI?= =?us-ascii?Q?KhZrdkhkf/fNKUxDR3GULew0kNk4h8drXr8VqoR+KCEu0bV42JMllr3wNDJj?= =?us-ascii?Q?0qNxjHF/fisKgI3ZFUsTsp6RMfaJAoBdcGRGI4/P1GQW7nHsiesSmusQhZqd?= =?us-ascii?Q?U7yPnksdG2WD5Do0mSb2IC0xXt2zCnQ4WVb8kUT1faa02WktFu9A8qHP4cmy?= =?us-ascii?Q?RpL9zbskJlFnL3t1ZgtDq9hyGpYCv1kvVZ8ObhCiUH6LVxu1Qvk8tzFl3nug?= =?us-ascii?Q?HwrRRRJC5dpEyQwGPNM7Lmtdia7PM3SUj5L6+HknW/yx7GUKMlRmk9hL4JjG?= =?us-ascii?Q?KN9x1mGTWh+xWoXvjC+zIjTlLjXxP9Fq6+rgckvpxtwM80OxLkponSb/Xus6?= =?us-ascii?Q?KCLZg5RjkBBze/VnolpQqlS3ih9Rj8loYxEieItkeeCxI3IUYcv2FXNEh2zq?= =?us-ascii?Q?6k60FB86JVelbwRnJXqk7moa79esMIPSrQ3Ajuni1szR7wJwfFSZDzEdO97Q?= =?us-ascii?Q?qNa1YMK7aMOrBL+YPFdRELgTORHJVs4GRiunyYbOuADTVA8By9rV8b+Gf09S?= =?us-ascii?Q?+IXk9j1QvPGMf6EGMHP0Mh5MEQxJvC0mw4Bfy8l4vm54rGrDw4d88avbudGP?= =?us-ascii?Q?JEYLzYF9zuT140ReAIj84JGK8O4IB23TJbWhE3CJgsJTWw4tYENESHGG/r7F?= =?us-ascii?Q?g92W16pQn8NqxQpJ1cztdtIyeN5n78tIP25yvxHrzDdQDEv6KD5XMPK/RIsb?= =?us-ascii?Q?BzjUlipjRqrsb12+lFcn9FMjO6kdPPtvs3JdqquxbedG6W1fWlPHNfYCXbes?= =?us-ascii?Q?dm1LkWLOHTGM+Wko+urAVseXrymJv9Y7FGgxr4GjiUFJb3oGBKsIvLLnMhKc?= =?us-ascii?Q?N/wv3icqaffnwyeetwb2gUn58PjuzPPdVYOWvx+Uq5u46rfIBsJPXOW8auV3?= =?us-ascii?Q?hjOFcjoF+tvwERyePNreAj+h/WPrUYZwr4olb0Cug7U55uNp7JvAVNTK/s4R?= =?us-ascii?Q?K+lEJkf7/U+A7GpAIqFO/jrc7B+bS++VWwFkBNgDbs2zAxOW8ty4MoFOegP0?= =?us-ascii?Q?LD8nUTgUFqPQmVzgukN0ZdhdP71XAMQsqSY46Vi9PyETyLRY1Qe8bMqte3dT?= =?us-ascii?Q?hnZGKL/nifVFe1zUEYrzIPlyZ4PHLuo5dSsWukBaQtrMuHvEnkKFrCXKr29L?= =?us-ascii?Q?yrujQ54oqr9Q0QWiK/PG8ng43LQuUO1cK7xzGWqcTCpEN7SSsCazGzc+ManP?= =?us-ascii?Q?TM5lwypLA/rjb+KYwM61eYSWdmvsNbB3JCdf7d7Zju/6xL0bHbpmfx5L34Ab?= =?us-ascii?Q?jD9AbjWlFMcwMkLuCxqXUa9k7ZcEkeKcw5c0UuC17N3jVMn3gIYXoabbT6de?= =?us-ascii?Q?EltJew=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)(35042699022)(376014)(1800799024)(82310400026)(36860700013)(14060799003)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 11:08:46.5982 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b0395804-9884-4f25-ffc0-08de58144831 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: DB1PEPF000509EA.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB11509 Hi Michal, > On 20 Jan 2026, at 11:51, Michal Orzel wrote: >=20 > All the platforms where ARMv8R AArch32 is being tested use GICv3. >=20 Make sense i think. > Signed-off-by: Michal Orzel Acked-by: Bertrand Marquis Cheers Bertrand > --- > xen/arch/arm/Kconfig | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) >=20 > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig > index 0d81a4d8b437..442d353b4343 100644 > --- a/xen/arch/arm/Kconfig > +++ b/xen/arch/arm/Kconfig > @@ -128,8 +128,7 @@ config GICV2 > config GICV3 > bool "GICv3 driver" > depends on !NEW_VGIC > - default n if ARM_32 > - default y if ARM_64 > + default y if ARM_64 || MPU > help >=20 > Driver for the ARM Generic Interrupt Controller v3. > --=20 > 2.43.0 >=20 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 11:21:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 11:21:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208728.1520874 (Exim 4.92) (envelope-from ) id 1vi9nr-0007pz-EJ; Tue, 20 Jan 2026 11:21:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208728.1520874; Tue, 20 Jan 2026 11:21:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi9nr-0007ps-Bb; Tue, 20 Jan 2026 11:21:43 +0000 Received: by outflank-mailman (input) for mailman id 1208728; Tue, 20 Jan 2026 11: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 1vi9np-0007pm-PX for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 11:21:41 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 302d7697-f5f2-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 12:21:39 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id A74024EE3C04; Tue, 20 Jan 2026 12:21:37 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 302d7697-f5f2-11f0-9ccf-f158ae23cfc8 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=1768908098; b=oqzgLYU0qhAebk7XvtzYWH2znU8wWloyLNLFHj32kik98Ojq2ITLXz9MjmV5MD8yH6EI Hxtt+uQ04NpajGL3JP1psyK+HrOXbqA+M5NlLlRGwY6vptTp1nPxswYwmSneYK9MijSf8 bsq2vXiqll/jbK7i2U//L0ml1KyKWya4oXUrEut6CrEY6cOGtUcxVODRCz3AqtbTJoq3l 0oqJAiDRcWo7V5su3oS9Uv/c3F2AofI8wAceMa8Ek2YJ6vtRVV8YPeXIMYWo6fbJV6tCq YjWCPzQncaIKhofiQ3QhV+oL4qxmtvfyR6RczKjZxI6pyyIZM9JBW0jTJtlraxbzaPKYb tYcTWknHsc0K0IQK5Np8J23LyYFIFs5uHy7lAdVIOznGt68+VHZXRhnJRllW92O89a2RX 8IuSx2oPaPFcaGyDqIIxVmP35V2qh3zEiAckJ+JS0iYxtC26yNgGL5vFbIweAolMtnK1g Dy0ww1uD/hHTXdPSlxpbYBm9FaCOn4IewHjfx3V85OmV05y/51VBxX0rdhriwg/vnPIbI FB7ZxmBdovsENB4dd3PqGoybq+8xmdH1Y9kEVWnrAUM418H1L6jNcIhWpygl0j8CkTRtr d+vUFycuJXaXRwsPoRMLO+2fHTgMyzAbw3lWL1aFXm254eBXrl5rg8cQIW67fT0= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1768908098; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=H0YnrsgOshk3GY8BSYgaoYQiHC3IDKziNnSvODu6Q+E=; b=dH6OhsZOjH8p8CvCf4nuZiRYC2ueMtZ8w/Xu3GBPraTD0SmCspkr/pT1mIAdL8YGu8Q7 BpYU5L1FXmu9E9qvbt3JxXfHUgo2P1IipVkGPRvijlr4ILfbf5WlRJKK8N7IdnWcBWk/O vp/DN4WtRUF3jvJt9ofuWbTgf/WtwW3cVlhDVr8gKuj/81s8J553NimyxNj0bDvXP8P18 y6rUxUw3Min5dAY/uYZf4GrMKgP1GChp0WsCk4cbYWwPcy0WIAd2m6kIs13ZDoRNI1Uwi nKqez0Ui3R/99HoH6/AsNQmNabC3rEn0375mrqOh7zJGn2DF9ZmXrxeMpB44HEYX6v5yJ GvCQUxnYS5ezFbIN13vtGv7/3GmDsHWP8GUQZKdq+c/RBw9GzPvkFBooCawG16/wfu0o+ l1vwUg7CUGGr/ShJhjPkn1m7cK/FJmSFm0DCy5knAdIl8Wviq5u1wZgT2Uk2+j9R38Fz1 1tKhIfMFiyPffhLI+vYnX6pfE4aoN6VOoEHc1DilL3q8RxgXTKA4SqU/Pfs1zSKvv38Vh PTrp9hgMTw5HJF4BSxrhuUbeJAFbFw1/cyVpUxFftsPgfLtJirTTw7ntw4izhzjjmW0tq dReAkdVZOicdL5zLZSzCqxv3NULOtFHEeabFNdiZe4S/3zov7mQXBpzs/XQagWw= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Tue, 20 Jan 2026 12:21:37 +0100 From: Nicola Vetrini To: Alejandro Vallejo Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Subject: Re: [PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list. In-Reply-To: <20260120093852.2380-5-alejandro.garciavallejo@amd.com> References: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> <20260120093852.2380-5-alejandro.garciavallejo@amd.com> Message-ID: <1d374226e3f91ab3bbc05c3354c8f8fe@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 2026-01-20 10:38, Alejandro Vallejo wrote: > It's clean. > > Signed-off-by: Alejandro Vallejo > --- > docs/misra/exclude-list.json | 4 ---- > 1 file changed, 4 deletions(-) > Hi. Do you have a link to a pipeline? > diff --git a/docs/misra/exclude-list.json > b/docs/misra/exclude-list.json > index 388397dd3b..273e24db4a 100644 > --- a/docs/misra/exclude-list.json > +++ b/docs/misra/exclude-list.json > @@ -121,10 +121,6 @@ > "rel_path": "common/bunzip2.c", > "comment": "Imported from Linux, ignore for now" > }, > - { > - "rel_path": "common/earlycpio.c", > - "comment": "Imported from Linux, ignore for now" > - }, > { > "rel_path": "common/gzip/*", > "comment": "Imported from Linux, ignore for now" -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 11:22:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 11:22:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208736.1520885 (Exim 4.92) (envelope-from ) id 1vi9oo-0008JE-Nl; Tue, 20 Jan 2026 11:22:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208736.1520885; Tue, 20 Jan 2026 11:22:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi9oo-0008J7-KT; Tue, 20 Jan 2026 11:22:42 +0000 Received: by outflank-mailman (input) for mailman id 1208736; Tue, 20 Jan 2026 11:22: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 1vi9on-0008Iv-1W for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 11:22:41 +0000 Received: from PH8PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170120001.outbound.protection.outlook.com [2a01:111:f403:c107::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 529b3efc-f5f2-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 12:22:38 +0100 (CET) Received: from BLAPR03CA0012.namprd03.prod.outlook.com (2603:10b6:208:32b::17) by DS7PR12MB6237.namprd12.prod.outlook.com (2603:10b6:8:97::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 11:22:31 +0000 Received: from BL6PEPF00020E60.namprd04.prod.outlook.com (2603:10b6:208:32b:cafe::99) by BLAPR03CA0012.outlook.office365.com (2603:10b6:208:32b::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.12 via Frontend Transport; Tue, 20 Jan 2026 11:22:31 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF00020E60.mail.protection.outlook.com (10.167.249.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Tue, 20 Jan 2026 11:22: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; Tue, 20 Jan 2026 05:22:29 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 529b3efc-f5f2-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=hsYMsRGOUF1vsyroJtsTgcq74HGrP5ePvvOCrXvROCGgOIIrAX6WieewMXlGDv9LKrZrRXwW0o6UqIBseKUwCGO6maDGkWwUE6z1dSYwaQlsIQ6dkEyAEv1NC8/Fb1Zd9P9QZf8g2ZgHzw0yNijCo3nTSxvV7YOuk76JfgU80W5WD0ZnQ+3aJBdw1jRlsH/yLFc1An4pPvx9HLm5ERi32dGC5H/E2y5Jf50JwEMZ3faYuUBSvXsBaNvctqK+LeaVejaz+V6tnPLvz0SMH7qWvyJ83Cd8+X7promdnXOqTT0+ltZI4lybCJ32GYyXC1OHYQ+NF32uygRsa3vEItYKGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=msUwpqeTDCH8hB32ESc6Q5VfBQUh3YmEqMuWl9Z9c10=; b=qoO8O96Neb8OuvZU8Hk+waKusED9IChpiJIEafiejn9n0pzPoffJJkHMleexGYHu7H9VRyE2aMharZcA/r9HtHXDW0Q2oUoKg8hjzPrMy6zMysW5KqpDzg4ScskeuHYxyTrJ7/sM7KZt8hzjG+xYPZMH0PhaInPX2tdVKNpeJLlx0K+zxART4TawbhTdVK3xO7JCRINvXogYbsgB7wJXoIVG5NlONh8Q6o3rWZSoidaUO9EzQNF1HIdSmprrYFaU51kyaR+hSVyRey3wIbktOIWLLHuhjgL6LW4wWGLVS91rBqCrhtqAAN7X6d/cXD8bz+VfaOKdbFlpaKYiRmCiGQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=msUwpqeTDCH8hB32ESc6Q5VfBQUh3YmEqMuWl9Z9c10=; b=VpW+AZ6TFbaH4QjbcZ7iGXFeQtFjj4DCgma7GRFf2v+8X9lhQAQ+fNnYVYTwLDlU6i1ub2gyh781hremlM1bcETVY0UsfNs3G4qoT8qqbPPtr44KkmRL9x41SpUb75ui4pQvCV77ZrdPdyohgqcREyKBa8pjHmpKgQNu9mDIyj0= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 20 Jan 2026 12:22:27 +0100 Message-ID: CC: Jan Beulich , Andrew Cooper , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , "Stefano Stabellini" Subject: Re: [PATCH 0/2] x86/svm: Add support for Bus Lock Threshold From: Alejandro Vallejo To: Alejandro Vallejo , X-Mailer: aerc 0.20.1 References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> In-Reply-To: <20260120095353.2778-1-alejandro.garciavallejo@amd.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: BL6PEPF00020E60:EE_|DS7PR12MB6237:EE_ X-MS-Office365-Filtering-Correlation-Id: ef982f27-128e-4869-2617-08de581633ee 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?cTRtRmJGK054VjE0cVRrbjE2YTMvQXdCTVN5TEo4bkxqaVBrYzRWZGczb1lp?= =?utf-8?B?K0hEd0RYcmg1U0lIMlUydlpValFLRXQwb1E2ZlNvcmR6bWVRN3RkQjhlVGFE?= =?utf-8?B?bTRYaGsxRnJWNlE0UXlGRVQvQXZrWnU5T1E5WGlUZmtOc3dHWGU2ckQxeHE0?= =?utf-8?B?M2VrVnNEaThJYTg2anJLQWFCeHhUTStqM09ITzcxTmc5SktzMTkrM2IzVlBJ?= =?utf-8?B?M3dXclZ2MW5LZnlYOVVOcFJ4WUYxaGxKMm43emV5L0VKSmQvS2ZwZjlEOWVT?= =?utf-8?B?bVFNdFZITktzRGM1TDlvUEk3MXJmSnMvUEoydnFoZWdnZEVGakFBL1ZUWHpP?= =?utf-8?B?T2Z4SVExeXlIbzI1QmlJT1Y2T25NZkNMZnlrK2syZEg5VE5IUjFaMXpzM2ww?= =?utf-8?B?OEVDWFdlNk9QM1BqTkhHSC82TEZ2Y3NnWTNKaHpqM0FMQU1RdEo2eEtBQkhq?= =?utf-8?B?NEYvSjBXR2IxSGd5L1F4Y3RwK1A0aTBXczJrUmV0OTFTV3I5elJldTBIdVE2?= =?utf-8?B?RnBPYXh6U1RESk1meHNvY1owd01PSGdUZlFRc0JqQ0ZsOTVJOGlaeFhoSFVI?= =?utf-8?B?SjR0b1hYbk9MT3pRTGxLYktQSkJlajY4YUc3TVgrT1RZbUN0NWhhQ284UXZk?= =?utf-8?B?dG1pUVZLL2NnWXNyWjRmYWJWY0UxY0FPQnRZdVRhaXVWOUY2ME8wUnhObEgw?= =?utf-8?B?QW1QTmh0WGJvQjV4d01YYUhvV1E0L3l6TVNCek5yNkhtL1RBNEMyMnFSdnNa?= =?utf-8?B?VTRSaGJlNS9HbVI4UGJ0MFlnMDgrbDZBenJGZVNNUDEyNlhGZ2ZZdmdIRyt0?= =?utf-8?B?MVJ5VzVXcldoalUySUxZV29FWCtUYTR2aHBSWEdRVWhRWE5IMHZzVDdTazhN?= =?utf-8?B?dUtac096ZEpYeW10RXFmRytBSWMySEo5NXZpV3M0YUxaenNXcThKRXRzaEpv?= =?utf-8?B?QWYxRTVHRFY1TkhNdlM1T0RpZ0tQdGFYNk9PdnVRamw2L3pkbW5rcHVLb3ly?= =?utf-8?B?d0xONERrVU5qcXBRaW1PaENoZG5sK0RkY2hyWVV0QlZIdlZENnB1Y1FkMEhO?= =?utf-8?B?TUdDaTRPaE03VnJOZFJxQTlUdVQwbGJMQzF6UzZZOERVTHJEbk94YXB2MGFk?= =?utf-8?B?U0N0elIvSWhSdWQ2d2dZU0NIZVUvZUo0UjJDbWlyM2E4b2s4Ni9aVlBmWnY4?= =?utf-8?B?amNZV3ZJajFrZG9FN2NzREtyUWVhSkRYSytuSXZlSkRLSlhYYkN1T2NYelQw?= =?utf-8?B?VzBIdkQ0WHNuRXAzODZzVnYzVDdJOHpEQ3JEWUIrN2dUd2c1RWE0T1RqVHFm?= =?utf-8?B?Y08rQVJDWXlQTkswMTU3SGtRUStBb2txOGFUZG1CRldPVmpRVksyZDhkeFA3?= =?utf-8?B?cUNXR3J4TlpTN2Vmek1BTUFoYWRyYi93cDU0RXA0QXNMSVZMM1I0b3FISWJh?= =?utf-8?B?RzFpOXFWbjl2dlN1ako1VXhlb2V5MDREMVA0UmdZNlE3WWFqa1JaaWlYaTdU?= =?utf-8?B?NEk4TEJqcEdLelg5UFViVkphdlQzZVRCdUNrUjRzdEw4Q3JIZW5FdERNNFFs?= =?utf-8?B?Q2d2bDJNZVRNNDNZUm1GWmVUcFRsM2VpSElhZVllVjlEcTlVcmNVK3NsM3pl?= =?utf-8?B?WFQ2NlRmc29KL0VDRWJnTnRwendlTlpSZWxrSE1vbEhib2dhdElrZnZEZnJ6?= =?utf-8?B?NHZUaXNoVHJVSmdxaTlCT0lZNzZyLzBSMWIyOGsxbFV0Y0NaMmhMSEd4MUpr?= =?utf-8?B?Y0g3QzlGQVhVZUpOK1RiZTRtR211U0s3MTgyR0I1aFhoY0dQTHM2L3prd2ti?= =?utf-8?B?NE1mTUZWalZRSXdqUkx5NHFMR1lyRW9INXJuOEltWU5kK3R0bGRTdFVlWUJy?= =?utf-8?B?a3lKdmlTdHdzeWNMa1NXZlpNY2lrQzdGS2d3VDcxM0hBRWowUUNYM20zQ3VV?= =?utf-8?B?VzRsV01DQnhNZXg5OUJmYnJpZXVQNnRoME1hQktnVHl4S0VtRnhXejRjUStP?= =?utf-8?B?TTBISzFBVHREb3RhTDFTa2tTV3M1bFdEaHhOZHN1dWN0RmRxYVdGaXQ1b2pF?= =?utf-8?B?UnZ3cTZ2T2krVVdKWmFISWt5L0QrT2dJcFVraldBa0lXRGQ4SVNOSjZSdmlp?= =?utf-8?B?NUlpYVpNcDNQTlV4MmRwN3JpeVA2VzhYa21LbWIyTlpqUHhXRDVVVDNBR3R0?= =?utf-8?B?ZVJSWUR0ZEtFRmp6Y2h5M3RCNlE2RmtOaTZFVEtKeFJ3M0tFSmRkZnV0MmVl?= =?utf-8?B?YVJRMGVaN2JmQ3I4a3JVcWVpMmZ3PT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 11:22:31.6523 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ef982f27-128e-4869-2617-08de581633ee X-MS-Exchange-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: BL6PEPF00020E60.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB6237 On Tue Jan 20, 2026 at 10:53 AM CET, Alejandro Vallejo wrote: > Bus Locks are very costly and a VM left unchecked spamming instructions t= hat > lock the memory bus (e.g: unaligned atomic CAS) makes system perf take a > nosedive. This patch is similar to BLD of VMX, but for SVM. It configures= all > VMRUNs so they automatically exit at the first encounter of a buslock eve= nt, > effectively rate-limiting them. Does this warrant an entry in the CHANGELOG? Cheers, Alejandro > > Cheers, > Alejandro > > Alejandro Vallejo (2): > x86/svm: Add infrastructure for Bus Lock Threshold > x86/svm: Intercept Bus Locks for HVM guests > > xen/arch/x86/hvm/svm/svm.c | 5 +++++ > xen/arch/x86/hvm/svm/vmcb.c | 6 ++++++ > xen/arch/x86/hvm/svm/vmcb.h | 15 +++++++++++++-- > xen/arch/x86/include/asm/hvm/svm.h | 2 ++ > xen/arch/x86/include/asm/perfc_defn.h | 2 +- > 5 files changed, 27 insertions(+), 3 deletions(-) > > > base-commit: 7b3e1b4e848d34c9a5b6634009959a7b9dd42104 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 11:27:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 11:27:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208745.1520895 (Exim 4.92) (envelope-from ) id 1vi9tZ-0000cO-6a; Tue, 20 Jan 2026 11:27:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208745.1520895; Tue, 20 Jan 2026 11: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 1vi9tZ-0000cH-3R; Tue, 20 Jan 2026 11:27:37 +0000 Received: by outflank-mailman (input) for mailman id 1208745; Tue, 20 Jan 2026 11:27:35 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi9tX-0000c9-TV for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 11:27:35 +0000 Received: from DM5PR21CU001.outbound.protection.outlook.com (mail-centralusazlp170110009.outbound.protection.outlook.com [2a01:111:f403:c111::9]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 035dbf58-f5f3-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 12:27:34 +0100 (CET) Received: from SN7PR04CA0181.namprd04.prod.outlook.com (2603:10b6:806:126::6) by PH7PR12MB5856.namprd12.prod.outlook.com (2603:10b6:510:1d7::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 11:27:28 +0000 Received: from SA2PEPF00001508.namprd04.prod.outlook.com (2603:10b6:806:126:cafe::9b) by SN7PR04CA0181.outlook.office365.com (2603:10b6:806:126::6) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.12 via Frontend Transport; Tue, 20 Jan 2026 11:27:28 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SA2PEPF00001508.mail.protection.outlook.com (10.167.242.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Tue, 20 Jan 2026 11:27:28 +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, 20 Jan 2026 05:27:25 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 035dbf58-f5f3-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=sOtKC+DOhNxZm5TbaYAaKd+QDB9npSrJz1Zn33AC8YSjndh56r5ZANpvVfTnWqrDfugT2SSa9JtsOsGrh52UDT+u8pHpMn9AqX23C2YVaD/zYMJVmGU2RnBSYiZz+OqMYkLdexekNWvlD7IRYwENzL4C6E6fNXBUouOPlQ5dUx5brJPENTZ14x+UsulVjuCAnvgZPEhzp4r5Lx+bkjA+/MAfxgs/DukfW00IzugYa8BuJDyttJ+84b7Kfodp5Qq/TlpIE0U+d+N6t1kox6y1xx25edOUhUZoLN2/w+lTaT5MdXkOSTDXnOvEmoHmFKXo4ARVnRG0yBLvzmFToojoRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2sF/rVKYe57a6LX6mKKlustCtZSCbtdcyWs1yNIDOwE=; b=kdKSxlSXbgpP3MZS1nToAjefKFI70ieEOu4a/d629DVnlBzJjc28mQzQbfhMLtm0rsaxWiv16SiOkAaq7QN1grlRO+mOSGSP0fRlbCpCbEBpxrrwvEG9CW53AP/rvV++xVDIEIDnbbav96uw1VXmCZ8XoX52V9/7/y1kiWPAalm8EfXR8gD85hWb6Dx6/6jhtrc97hcK288AAm2WKMBNIgGFJswbHSKWGUWIgq+6BOrrDcldNQ/N/Rz6GO4IC/dEXcc57vS4zQMaiRRI7P6qbLy9DBj4j5A1gr0Om3LFMWKs4eqj3v9JKA7XHzTf/1sJG6yiYQGjrFbfkOVFmnuvZw== 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=2sF/rVKYe57a6LX6mKKlustCtZSCbtdcyWs1yNIDOwE=; b=NGCR1VtAIZxdySQ4mUAyOxX4ByJ3V4w9TZe0uujlKJISgPeurBzYUSOStOedEeX9xyhGdJqC/seQW+yiorOfx6EMU1QgAPNtRnCjpds3T0vZW2Ytb4fLMIAhL8eUKPjjaQyjdfp4rhpoPK5kR/ubnk0Ohn9Ld9CE/yxVCqoDYGo= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 20 Jan 2026 12:27:23 +0100 Message-ID: From: Alejandro Vallejo To: Nicola Vetrini CC: , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Subject: Re: [PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list. X-Mailer: aerc 0.20.1 References: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> <20260120093852.2380-5-alejandro.garciavallejo@amd.com> <1d374226e3f91ab3bbc05c3354c8f8fe@bugseng.com> In-Reply-To: <1d374226e3f91ab3bbc05c3354c8f8fe@bugseng.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: SA2PEPF00001508:EE_|PH7PR12MB5856:EE_ X-MS-Office365-Filtering-Correlation-Id: 16de88a3-457e-459e-026b-08de5816e4ad 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?dlpsdGthMDVvRVYrN1pMdU1qWHVvYWdzdlFaQ0xrd0U1TERJTzNuVDl1VCti?= =?utf-8?B?SSsxSnZKUmVrSENKZHM0R09hb0RHMThTRXBpelJzd0p4MnVqSTdYSEVnR0hZ?= =?utf-8?B?V0lmek1Fdkd2emhZOUtFZEhTREc0czJ2cGRVdzZyb0VOZitMZUlSRXM3WGN1?= =?utf-8?B?OUg5Smk0clRKQWJiNnZScUhwOU5rbDltR05USHZaaXY0bTNsWmxhR09yTFFE?= =?utf-8?B?UmY1QitRTjgxaFVlM2czdTFWWjlMZ3dabXJHbFJrUWlERURGMEphcE95NDYx?= =?utf-8?B?NFB6c2FHSzZ5UXU2K3UwdWxNYkMrU3YyYTVwRC9rUlhlZ1RGTzltOTdwckc2?= =?utf-8?B?b3duaER5RVpyQzhKYmEybVNta2hNaU1laUJDQkcxekhqWlZXeDdmTndwVG5K?= =?utf-8?B?cDV3ayt4cTN4ZWd6eVdtWG56VlJqdkp1bWVZckVzVzhibVdIOEpnZGhsSjYz?= =?utf-8?B?U2FSbUJuUkxqWEZheVpnY2VLak9NZEpMR1VrSnVEcC9vMnJJQTJvSGtBazlv?= =?utf-8?B?VU5RWklQRlB3eXh2RXg2MDJ6aW1ZTDBMOU9iTjgrRTFiU3ZCaDFHMHFrMUVu?= =?utf-8?B?L25hQ0tZcmZTUDdBaHBOTjYrcWllSUhOYksyNVV4Uk8vNms2SzRNRmtkRlNJ?= =?utf-8?B?QXpKQ0hiU3dKTEc3UXZBWmN3RkNpM3RwY3VDOVNqZEdZWlhzbjhnQk0vc2RF?= =?utf-8?B?aTRpNFdsS1kvQ3ZEME1tR0tqUjlsQVV1NXd0NFl2em9ycGpsWlV5WGVCeVhJ?= =?utf-8?B?a2EvUCsvdDRxKzRYSW9xek14MGQwdVNWaVd5TmZGRVA0TDRwZmpPUFlHYmpW?= =?utf-8?B?ZkZoTEhnVW5lT3A0bzErWjEzT1FXekFsdG1xTTI0a0NUeG11UWpvSFFMcmtE?= =?utf-8?B?WFZEV0VJcXN0eDJVbXdLRmUvL0h6L2NER3p2OXdjQmVoYXVCTHVEMlhEZ1pl?= =?utf-8?B?dXVCMmozRWZsK2d6SzdrWGlyZVVrK2IrVHJtT0huYTdsS3EzT1ZGaGhLOFJD?= =?utf-8?B?b0dONXk5K1g3NEJQTSt2TnRzajhwRjFNSEhWOFAwN0VKbHQvWjRpdkpBZExU?= =?utf-8?B?cGxOSEtkdWsrcEtQRUxDcjMzYVNOZjV6UnhYQmdBVTRRWjdQYWVDb1ZsenZv?= =?utf-8?B?SFppbUlrWXNSRzBLeitrMDhjRE95TmhCMXpoU0l0elpQdnpvM2lybkkrQmZt?= =?utf-8?B?cHZzZVhCYm5haHFlMGM1YUI1bG50cStId29wbXlxMjJIMW1odVZkUTNwM0Ix?= =?utf-8?B?NXM3Y013bU5aRC8vSXVFSTVONXJubGxiR2lRWGFLbTF3YlNrQlZQTXloUGJI?= =?utf-8?B?WDFrem9ZdFRZbFdYenhYOEN2WThHNUY4d3V0OXQvZjRVblB0Y1lpZmxWUVFZ?= =?utf-8?B?M0VtdTZmOUg4RUtPQ1FpTnBzeFZyRTVBd0ZyY2ZzVWtodkkzNThFZVRoRDdX?= =?utf-8?B?OEJDWlgrMlFtQ3kyZXJ4blNkbFM0Z1BQNGN3dDBZUkh0ZTlDYVUyUmpFZjA3?= =?utf-8?B?ektPcE0ycWoxVDM0VG1jQVRXeEFGanJjcmVNVEZRcUI5OU81L2NFVWJPSzVU?= =?utf-8?B?Q3ZUbzhBQm1SeEhvSXdvMzBkTUZ4dUpBSUZ3cGpWWFlhaGNlaVdFZmpYRUl4?= =?utf-8?B?bHExdlNHOGNYaUp0ci94enBHMWdESHRSU25XaGE5enVwQW9EWDBIYmo2SDNW?= =?utf-8?B?bW5jc0JXN3Exekt4SkhkY0N6Y0VPT3Mwd1hOSjlucEhLSWVPSUJMZUI4Qm83?= =?utf-8?B?aGFqYXViZXcyV2NCMlBIM3JpcjNwOHNwOHVmaEhOWklHZGJFcmdvWUFXLzdZ?= =?utf-8?B?bnlneEYzWmpOckZCSEZEVDVYTkFuZlQ5ak9PQUdYbkd4bGgrMG9HN0Rsci9D?= =?utf-8?B?S2RVQVZUVU5HV1pBc3RnVndKVUt3Q3ROUHBnc2g4T1ZLdnNDL0FkejNOeWRv?= =?utf-8?B?YisyM1R6QVRvblFLaUVyclFwdHVsemN3K2FJUzdaNWs0U2FOVEdEWHV5Z3Ar?= =?utf-8?B?dUFuUU8rYTlpb3NpVHRRQ1RudTdIMzZGL0tZcUFoRjNPOUV1cVRJY1JwNHlu?= =?utf-8?B?eXk2disvL2E2TXVxanphSUV6MEdGQjhteGUrNHVFR25rZ3NsclRNVCtYVG9m?= =?utf-8?B?VytrNDRIaGdIMEJkOXZsOHlBS0lxQUNCS0U2dEpFWnEvREIrenJNYWs2Z09R?= =?utf-8?B?LzREMFVTZm9SS0tVKzFzdVdWWVkzcnA2K3Nid0ZzT0hubERsZW9reFQ0bElI?= =?utf-8?B?bmJqcThLSFE2eGF2YVVoODJnbkx3PT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 11:27:28.1598 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 16de88a3-457e-459e-026b-08de5816e4ad X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SA2PEPF00001508.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5856 On Tue Jan 20, 2026 at 12:21 PM CET, Nicola Vetrini wrote: > On 2026-01-20 10:38, Alejandro Vallejo wrote: >> It's clean. >>=20 >> Signed-off-by: Alejandro Vallejo >> --- >> docs/misra/exclude-list.json | 4 ---- >> 1 file changed, 4 deletions(-) >>=20 > > Hi. Do you have a link to a pipeline? In the cover letter. I only run it on allcode. Cheers, Alejandro > >> diff --git a/docs/misra/exclude-list.json=20 >> b/docs/misra/exclude-list.json >> index 388397dd3b..273e24db4a 100644 >> --- a/docs/misra/exclude-list.json >> +++ b/docs/misra/exclude-list.json >> @@ -121,10 +121,6 @@ >> "rel_path": "common/bunzip2.c", >> "comment": "Imported from Linux, ignore for now" >> }, >> - { >> - "rel_path": "common/earlycpio.c", >> - "comment": "Imported from Linux, ignore for now" >> - }, >> { >> "rel_path": "common/gzip/*", >> "comment": "Imported from Linux, ignore for now" From xen-devel-bounces@lists.xenproject.org Tue Jan 20 11:30:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 11:30:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208759.1520905 (Exim 4.92) (envelope-from ) id 1vi9wK-00027O-Iv; Tue, 20 Jan 2026 11:30:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208759.1520905; Tue, 20 Jan 2026 11:30:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi9wK-00027H-Fm; Tue, 20 Jan 2026 11:30:28 +0000 Received: by outflank-mailman (input) for mailman id 1208759; Tue, 20 Jan 2026 11:30:27 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vi9wJ-00027B-DW for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 11:30:27 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6a938c0b-f5f3-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 12:30:26 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 11F784EE3C04; Tue, 20 Jan 2026 12:30:25 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6a938c0b-f5f3-11f0-b15e-2bf370ae4941 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=1768908625; b=lCq4b98Mf0PertI5RkWj5GXlQfVErI68gGYMI6R7fmi1qXQB4YBi+BktvgZDzF4/Up5x jqC2OvrTwwpCfg5End/WBV/YLACcD4v4n58qBs2VyGu4bMdTxKNKhiNKbivSJLVoCRFX8 hp5aLqz2BqxviEZQPyIDJkoilMoE7HDE7XUPoq85Wp0UDJd1ay7h9O8zfyJaXQ3BPQyGl a+TpSct0Uy7oTiy0Lo5PzZzgHbR5oe9bktHc1O5m+L3U7mY9vpLbAk07VDVhnFCkWHDpw sxDXX3boJYSznHnqbNlGoCAgI1yCJaakRKhDeuJZ8PsAJmu1WuR0QzqiT9AQr4Tauttuc +oZxBTjs1imRPngFKdbGnRX57LC5lmc9zewWlGS3uSIAop2N4fh3swDijJoHZrldgixju nIknXUfOr8zc2ZDF54vGKc1MgCLS1tNQdaA69952nh0HZ6LPI9nWndw0WMGKhguYSgMLR 1DQNgOcjrMDrbQR+1C/joW//o1Lz6klALdarurFuWqaLO9L0iilacqJG3P9SAgmrR6IaC W67ClhpBOfgLe2yK1hIagPLGIIhK46SavTQRdHbz3zx5yTKD3Q6zd+ONMQXHxihdSfM6C aHZv6FZX2Rt9hVkeLS74OqGKf8vo5oHW4chmAw6KR1Lpw/Wqple+t2SAvdpTskU= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1768908625; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=T0dpN5Yol5j6OhB+Xjhb7MHZC+YeHMALVWycAZpPAp8=; b=tTEZwiQSRNoDYee+5lQJ6IoBu0Dpe5cjFLz7wO/AhsIaxSmdW5yw5rDczLoIwNJIXEjX q5XmjFz7tU9GQvr6PNKjitMyVeNd5UA03PJMQvL8TN30O71lyNWJsF/Dk2ZuMklTliRsX IvXx6Hmoh7aR74jvrkMgxquvMC+aijwXL78j7KcAvXu4M3m+JuJgOyyF3zzzsHzG3glY+ ZcbebCwPVCOTkqL04ykvIpilWAi+D068vDDPzsivzUscXtxx+G8iH6AxikiDxdCecEale 5nkZjWZyQ6nnd6GBPtojLkDCeJctk4zDby9jY2OYDomCEAkqM08EQZAOWCHBWouDqPZxx qo+pyeytJM3m0I1u1WUDb1p+2z3/aUIxwAUFrx3T1ZlboWlaJdhPU03RYwuYl65lvzX80 wMFJFnw13QUW5o2q4P8n/5rGtc7SUOFoNBXAZuhiVU5h5GNY989iVd6Bh06GvfKqAPj8D bdShHpsKvEopYYVg6lAXzC3OYSQijZEqHplPsvknZR9AHhTAv1V1bbV8jMktryq6qM9xv Al6qbd9TlfUhNoaFWeQ6zbz9R3uQNpPu6FlrMHOBpkKjEWjKnmkoV2kceNrZORxyo/NSD ifWx+ueJXu3rM8VZE7OBQLwY7Z1cKwGLUMTkmU7zRNZ8wFGGMDuAAWjksmGS4Uo= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Tue, 20 Jan 2026 12:30:25 +0100 From: Nicola Vetrini To: Alejandro Vallejo Cc: Jan Beulich , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Doug Goldstein , xen-devel@lists.xenproject.org Subject: Re: [PATCH v4 0/4] Add Kconfig option to remove microcode loading support In-Reply-To: References: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> <5e34118f-af8b-45ca-a5e3-ba214ab101d3@suse.com> Message-ID: <8f1f6f61b1e397c90c74d0138f94ba8c@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 2026-01-20 12:03, Alejandro Vallejo wrote: > On Tue Jan 20, 2026 at 11:52 AM CET, Jan Beulich wrote: >> On 20.01.2026 11:38, Alejandro Vallejo wrote: >>> On Tue Jan 20, 2026 at 11:20 AM CET, Jan Beulich wrote: >>>> On 20.01.2026 10:38, Alejandro Vallejo wrote: >>>>> The only dependency here is patch 2 going in before patch 3. >>>>> Everything else >>>>> can be freely rearranged. >>>> >>>> Is this correct? Didn't you say (confirming what I observed >>>> elsewhere a little >>>> while back) that there's a complaint when a file listed in the >>>> exclusions doesn't >>>> exist anymore (which may have been cppcheck, not Eclair, but still >>>> breaking CI)? >>>> IOW can patch 4 really be separate from patch 3? Or, if its >>>> description was to >>>> be trusted, wouldn't it need to go ahead of what is now patch 3? >>> >>> Doh, you're right, they are out of order. Patch 4 now just removes >>> the exclusion >>> so it's fine to do it separately. >> >> I.e. the description there saying "it's clean" is accurate, and it was >> excluded >> for (effectively) no reason? > > All I can say is that I looked at the report after running Eclair and > found no > trace of earlycpio.c in the violations. It's not clean, but I don't > think it > is as of now. > > As to why it was excluded in the first place, your guess is as good as > mine. > Maybe all decompressors were excluded regardless of them being clean or > not > (e.g: zstd is also excluded). > Well, the list was devised by AMD before even plumbing the MISRA checking infrastructure, so it may well be that some files in there can be removed because they have no violations on clean guidelines (that is not to say that they contain no violations at all: it may be that they have some additional ones in non-clean guidelines). > Cheers, > Alejandro -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 11:41:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 11:41:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208775.1520914 (Exim 4.92) (envelope-from ) id 1viA6m-0003vp-KG; Tue, 20 Jan 2026 11:41:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208775.1520914; Tue, 20 Jan 2026 11: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 1viA6m-0003vi-HZ; Tue, 20 Jan 2026 11:41:16 +0000 Received: by outflank-mailman (input) for mailman id 1208775; Tue, 20 Jan 2026 11:41:15 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viA6l-0003vc-LG for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 11:41:15 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id eca90d69-f5f4-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 12:41:14 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 417264EE3C04; Tue, 20 Jan 2026 12:41:13 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: eca90d69-f5f4-11f0-b15e-2bf370ae4941 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=1768909273; b=2sENNBmYoNlemZAySaSQEuUBf/kp6vdokj5ZRfSU7o0EPtraZncdNZJZfQHdSPEwur5z IXQrbvuPKDo4nq6Li+r/5hrYE1e9elofFaU6SDhCOt+tIxQ6WKPql33jczbx8S7U0WJTO 84R0PbBo8RV4SempYbmtDMp/QGT6t3ClaNj0Doklh+qUr7Y8P5dj2igqaS7HQVE/Rc/6h NmGDcHWtXSfpup4F0Dz8NsmtEPYcijtRUNKClEqndPOTQfMA7rsmWmXVyn8jwK/aLzmg2 XsdQh/BTSEJo4WxFTGC1yCQf0k8NpJrjQGY9D7RbUpffEXWwm2Brt3h35wVUo/P3zS02X OLu2bkbyJmeLjv9RADm7CiRWp6UYJXnZeNgvXErQlf8I2qgwrB3srSqGI8b1YLQK4Wwgg JtwqDpczW/d/pl6VGoLR7TyXsFYQ3w4Vehw0b0cRV4tyWa99JDgLN7+DNeByGcaglp+rn DO6rd1U3MnBwcBhCyGg+eLzfLlbOXXN47fzMBNmHinmfZwoLMGy+0eRUFKI8i3xCYpTA7 vk0L05LBKxOoO+nD7kPYDGH1vHn4aeQT7bDwEs2M025wrdBZVmOLc3GoE4OsfIoD1YSJu dAnlOqQ/JC8VCQih97DhCLTIz2kep/BUPNewwGZcc31mWZsejFauYTeTrQ2gUS8= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1768909273; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=g0LphDrjBBBcNeS6PTBpBmzF9zhHVCAUEqStmqI40k4=; b=uXIzD+LJeMNTQjfjHc+07FkoRN2lw+E2FxbDoEIqBBLFdLn859Nzim9c6wxjIj9o6gwB kYzHqkh3s7FkvAv/735LaNfvw2uZUimGrELiPipPt80hYiuRrBSIQxanHJj6smRMavDiM BKPvb2Yb00lqErKbjrshlBy5QYKRZTdiu07qmXYRwJM9k/DtxvGLcqXseLZNU3KqlN3NC cZ9O8VCJ/cM3RJZtoIH2J4qaDeMxO6egImUgDnOJRHsEFlkIDOQvnKxtcgC7dMVbD5TvH 7Adw3Zb0oEYNkDOTOjYnXap1FdVKXim/z8EaILVjcD8n9YYrynLkJlIsXjwxxjlqer3Nk 0sE6bc1M2NF9Y7Mfocsz6c4IpKP00ymtRQZHmiJC8yNGYr6LBSbW3cuqERR9uDjFHRw6f VFU4mpPSpTsCNXwLoJarqkyYWYrgoprY6oXYMDhSgc3lvG2JxhP9oZwqvnEI4rLlJNJyn yDE4hiUcut48yUxXnwr9LbapmNehUvfH2/hbigSHK9vmzCgIORZ9lDYdgNtF0+WKIb85U uNIAR9Laps8ZnDYdfczwGWWM0hRNwdwk/NOyfx/U+w68IjYUfr6foiR/OPT1EUihPFvL0 Y6uaTuR51uexJVgHnKL6JNvADN5UQ1oAJlPx3wJXtsaRFaNn/ukNX9i6Iu3jls4= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Tue, 20 Jan 2026 12:41:13 +0100 From: Nicola Vetrini To: Alejandro Vallejo Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Subject: Re: [PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list. In-Reply-To: References: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> <20260120093852.2380-5-alejandro.garciavallejo@amd.com> <1d374226e3f91ab3bbc05c3354c8f8fe@bugseng.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 2026-01-20 12:27, Alejandro Vallejo wrote: > On Tue Jan 20, 2026 at 12:21 PM CET, Nicola Vetrini wrote: >> On 2026-01-20 10:38, Alejandro Vallejo wrote: >>> It's clean. >>> >>> Signed-off-by: Alejandro Vallejo >>> --- >>> docs/misra/exclude-list.json | 4 ---- >>> 1 file changed, 4 deletions(-) >>> >> >> Hi. Do you have a link to a pipeline? > > In the cover letter. I only run it on allcode. > I see. I can spot these additional violations from earlycpio.c. It does not result in a failure, but only because x86_64-allcode has also other non-clean guidelines and is thus allowed to fail. Ideally in some copious free time I'd send a patch to create a subset of clean guidelines for the *-allcode analysis that is failing, so that the "allow_fail: true" can be removed. https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/people/agvallejo/xen/ECLAIR_normal/ucode-disable_v4/X86_64/12771570090/PROJECT.ecd;/by_main_file/xen/lib/earlycpio.c.html > Cheers, > Alejandro > >> >>> diff --git a/docs/misra/exclude-list.json >>> b/docs/misra/exclude-list.json >>> index 388397dd3b..273e24db4a 100644 >>> --- a/docs/misra/exclude-list.json >>> +++ b/docs/misra/exclude-list.json >>> @@ -121,10 +121,6 @@ >>> "rel_path": "common/bunzip2.c", >>> "comment": "Imported from Linux, ignore for now" >>> }, >>> - { >>> - "rel_path": "common/earlycpio.c", >>> - "comment": "Imported from Linux, ignore for now" >>> - }, >>> { >>> "rel_path": "common/gzip/*", >>> "comment": "Imported from Linux, ignore for now" -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 11:51:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 11:51:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208787.1520925 (Exim 4.92) (envelope-from ) id 1viAGX-0005e4-G8; Tue, 20 Jan 2026 11:51:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208787.1520925; Tue, 20 Jan 2026 11:51: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 1viAGX-0005dx-DL; Tue, 20 Jan 2026 11:51:21 +0000 Received: by outflank-mailman (input) for mailman id 1208787; Tue, 20 Jan 2026 11:51: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 1viAGW-0005do-BR for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 11:51:20 +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 5481d4c3-f5f6-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 12:51:18 +0100 (CET) Received: from DM6PR06CA0087.namprd06.prod.outlook.com (2603:10b6:5:336::20) by CYXPR12MB9442.namprd12.prod.outlook.com (2603:10b6:930:e3::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 11:51:13 +0000 Received: from DS2PEPF00003439.namprd02.prod.outlook.com (2603:10b6:5:336:cafe::c7) by DM6PR06CA0087.outlook.office365.com (2603:10b6:5:336::20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.8 via Frontend Transport; Tue, 20 Jan 2026 11:51:10 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by DS2PEPF00003439.mail.protection.outlook.com (10.167.18.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Tue, 20 Jan 2026 11:51:12 +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, 20 Jan 2026 05:51:10 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5481d4c3-f5f6-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JHZ+ABOjfhYpDhFNrWvsOOydcXbg0uuRh/yQIS9TSSTTphak2Df3AHZ1LSnn0IrgpwLqdw8jOIkb5mPMDm9r71VVopUQCOQmPXB8L8nmdUSvWEia+/X5vyG+Scg3d6WS6ij8dz1L8d1o8GzS6rJRB5HBfPEc3noByCqIdVHE04njZ8RFs7/w6UnSCKBFpxwJ2ezQy1+tz6MDZcD3J1Dj68utxLge6IAU9UW/dKPd/3nj0AyBw4gPGk12ZNkQ2pCGDZ0UJlkZLk7QrgLzDgs2fKRoV6BdQ6b16o3U6oxkJLoEMPf/3nXoAh2WcUmcUkygtLvQxK+6Ze7KBt5Nw/mCng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iKg3ttnejLm8XATwE57As9cNTXJjxx38A5bqUNnm7Ck=; b=AHE5g/qrtXjNKzC+OwhAfzwB+NP47y5BpMMp+uN2D8WftEJT3HqNanoBep2nBO0BjYbxjg0CfohnctfKfm08God42aOZBSBMbcjLJ/ABK+Nr5LRbMcfXEUWAKzM58A035N85eGiKnV4AKLPclLsJgqG0jYzc/wJfkfAQHGp8RdQjHWAXfO7PW6EjBHY6Vs7ZZXmmdYu6om8d7C7MDiLftitvdXn8zlSAmM/pLfevq3uzo+weU4S98fQ/iOC7XyrMTlhq3i46jB/9WWRZwZNI8XbzGulBnm5UbgVGGFUj7tten9AxAWRv6efXHGDdcZJTTPxpo9kJvHcx05x/JZ4kMg== 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=iKg3ttnejLm8XATwE57As9cNTXJjxx38A5bqUNnm7Ck=; b=TPs1bq4bUi316mKkyafy09HGdvCnJxSNBZ8ilAt2my/dVc+gH/2M8cSRfUH2hq8K96jnzBX5NWzB6oQo1lIbUlZjcEqYi9ZEo7pRqzuBYCmL//ft9dwsnb9rZq2XyZkOlBi6lN8snuVMsVAfw56hZzmKZaDzSj2sT1fAhZL018k= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 20 Jan 2026 12:51:08 +0100 Message-ID: CC: , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Subject: Re: [PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list. From: Alejandro Vallejo To: Nicola Vetrini X-Mailer: aerc 0.20.1 References: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> <20260120093852.2380-5-alejandro.garciavallejo@amd.com> <1d374226e3f91ab3bbc05c3354c8f8fe@bugseng.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: DS2PEPF00003439:EE_|CYXPR12MB9442:EE_ X-MS-Office365-Filtering-Correlation-Id: f1343eba-760c-4d58-8bff-08de581a35e9 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?MFBnRnJWQkE1bENSTHZzUU84d1VwY1BlN3FNb1dOSXZYbnBuSWszekZLM2ly?= =?utf-8?B?MkNLSnRaYzRoQSt4aVpQZ3ZwT1hFNFRvSW1qRXpxNzNOd2YxeTlTYkZPaEhp?= =?utf-8?B?RkpiNy80c0x4QWZaRjdpNFd0S0cwNms4ZFdzd2dxYTJpWi9qMUluRDNTaTJw?= =?utf-8?B?UXlzSC95ZURkN0hjTkV6L3RaVnJkbmpIM2V5YzZzYUJLL2hxWWsrUDZGK29H?= =?utf-8?B?Z21hamh1MkxLeTJ4WUFybysyeDhlUk1qUDZCdjFCdWdPYnFpT2hxQTd5VEhG?= =?utf-8?B?VWNrdkxvQ2Z1cDZ0SC96WmJnTFZuWWNteDU4KzkreUhwK29XOGk2NEVhd0dV?= =?utf-8?B?enRGYmhiTStjelBqZXdZV2tEVVJzUTVxdGxiZm44ckd3SG95aXlzOG5lVUdK?= =?utf-8?B?WlBTc2JoSXEvR1krL1JOVE9aT2JMbWYrd2V3clFXWWZYelk1bkJQaW5TMUU0?= =?utf-8?B?eGFnaXlFMjlsZnJOVWxXcWdUNW5ZUW9wbEEvTnpUY09IQjcwZ2EwZ2RZQnh4?= =?utf-8?B?UWRpNGpRNmRaTlMzK0hGWVBuVXlpVkdGNTRwN0V4Q0RKdkRKN05vZVkvRllX?= =?utf-8?B?Zlp2RU1iV2UrV1cxZWFhZ3Jma3crUFJBSGN3bzFYcHB6VElucEpWYW05RDRp?= =?utf-8?B?Wk45UkZOaXZEWGVvdHAreFNveW9UVW5VUmh5SVZ6djhiSlk3cHoxUFZFdldF?= =?utf-8?B?NkZ4YWZVcnV6Y25VNTV1ZTRYSzBXSytwRk4xWHhBYk9OSnlhS0dEdmt1QzdZ?= =?utf-8?B?d3BDdnhyaktZdDNFSGVQN0R5cXRoZVNZYmtueFdMUEV2ZmRvY1pjVXhrblNs?= =?utf-8?B?VUtIVTBWdTF6bVVXZUlBU1F5MWlxOVhtV2FLY242RUt3aDMyL0MzOXk2VU11?= =?utf-8?B?ZHVyaUJtbUVFWXRLWDZuZXo4MUozdFhialVPYVBpMlkrUGtMZG40QVdMenhI?= =?utf-8?B?bUFNRFJrZ3R1VGVnejNRakFRM2gzY2xFU1pOOXJEYW0yUjZZQXRLaVdidzhU?= =?utf-8?B?TSsyRUJaeE5rNEttakdscnRWRUdzZWRWTXZJMjRrOWhIQjRXY2wxZ2FBNVR0?= =?utf-8?B?OUhmQmN0N0lBa21rNlpVREF6QTgrUzA1YU8wd2tsc0Vkc2pCN1V6UzhMc1hZ?= =?utf-8?B?cllFWTBQcUh0REtKWi9OTThlT0NoOWNKQUo3NFVLR3FKdjVCVXdnVkRjRnpi?= =?utf-8?B?VFZGT0czbStLaDhkOTJmRWZBWEtGb2FudWs0Vzg1cnhrRlphWTg3eEZNa1Zt?= =?utf-8?B?WmMxYmliU2UvOGJORFBLQnFCREFyREliWGJ2RGY0dFFmTEVXUlZGekFQMnN6?= =?utf-8?B?ckxrYkwxdjJZSkIwRWFTdWFGdzlqY2R3c2p4K2hIczhZV1VqN3RmWE9hS1lK?= =?utf-8?B?WkxPWENMaC8wdW1NNnUxTUVvRFpKeGh6K25nTmExUkVpSWZqdWkxbVEzZVdy?= =?utf-8?B?QUJudEMvYWxrWXJUd2xGRWdOT1JOSnNRT0VHSWxoMUdKdlpzTXB2ZXF5b1V3?= =?utf-8?B?T2RKblRXOFBNVm9YbXFaSTZNZUgwYlFlWHdLVzB1amQ5L25mbkJBOHdqLzFL?= =?utf-8?B?TDdYOSs0VGR6eUFFTVdNY3kwMjc1cVJYcm9FRWhXMjVJd3VuKzg5dHBiUU8x?= =?utf-8?B?eFQ0R01ESUZ2NHZnalRlV1hNUHhtQ0ZUNS8rbVpzakZyd3ZzT3AzY3VQTkZV?= =?utf-8?B?UXI2dk4wSUNUVkx1eTQvMWNwU2VHb01FM2hFbHlxbWIzUVRjbVdvcHgvdVlX?= =?utf-8?B?YUNERVdEclpIY2tTSzZkcWhDS2kvczBhcmE4bDZDQ0piZ0FyNWxQdUtLQ1Zl?= =?utf-8?B?S293c2hCbU03ZE9xTEdmZXZZbHhtV3VUZXBYTkNWY0JJR2ZFbUVrYnJBRWlp?= =?utf-8?B?ditFdkFtbS9HUEhsSWxpcDFncTlsMWtpY0xHZDlhc2Q2OW55cXpMVFBYUjNC?= =?utf-8?B?OXBoZDRXQ3dEQWdtdGVLK0FoWCtwbXE1Ny9EVENMajZldGc3eFNKblQrVzY4?= =?utf-8?B?Z3N3V0RFaVVqQkZGOUtUSlJvMUJhSUhrNnFrMzRER3QvbWd6M2E4ekxzRHFw?= =?utf-8?B?UG5Od2g0eEwxZzExQlVJUDlMUGFieFVuTE8rTXR6Q2E1cVlIc3RrcGs4WmxU?= =?utf-8?B?UnhQVSthOGJIaUk1bXM5aDdCaXBGQzd4L3ErREt0TlBwWXJkaWlOOTA2OGRh?= =?utf-8?Q?BJ6CusHvVSiRJ+5oynp96RU=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(36860700013)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 11:51:12.9292 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f1343eba-760c-4d58-8bff-08de581a35e9 X-MS-Exchange-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: DS2PEPF00003439.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYXPR12MB9442 On Tue Jan 20, 2026 at 12:41 PM CET, Nicola Vetrini wrote: > On 2026-01-20 12:27, Alejandro Vallejo wrote: >> On Tue Jan 20, 2026 at 12:21 PM CET, Nicola Vetrini wrote: >>> On 2026-01-20 10:38, Alejandro Vallejo wrote: >>>> It's clean. >>>>=20 >>>> Signed-off-by: Alejandro Vallejo >>>> --- >>>> docs/misra/exclude-list.json | 4 ---- >>>> 1 file changed, 4 deletions(-) >>>>=20 >>>=20 >>> Hi. Do you have a link to a pipeline? >>=20 >> In the cover letter. I only run it on allcode. >>=20 > > I see. I can spot these additional violations from earlycpio.c. It does= =20 > not result in a failure, but only because x86_64-allcode has also other= =20 > non-clean guidelines and is thus allowed to fail. Ideally in some=20 > copious free time I'd send a patch to create a subset of clean=20 > guidelines for the *-allcode analysis that is failing, so that the=20 > "allow_fail: true" can be removed. > > https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/x= en-project/people/agvallejo/xen/ECLAIR_normal/ucode-disable_v4/X86_64/12771= 570090/PROJECT.ecd;/by_main_file/xen/lib/earlycpio.c.html The web interface doesn't allow to search?! Sigh... thanks for the pointer. I'll have a look. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Tue Jan 20 12:02:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 12:02:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208800.1520935 (Exim 4.92) (envelope-from ) id 1viARL-0007Ud-Jc; Tue, 20 Jan 2026 12:02:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208800.1520935; Tue, 20 Jan 2026 12:02: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 1viARL-0007UW-Go; Tue, 20 Jan 2026 12:02:31 +0000 Received: by outflank-mailman (input) for mailman id 1208800; Tue, 20 Jan 2026 12:02:30 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viARK-0007UP-Iu for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 12:02:30 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e3d0a1a9-f5f7-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 13:02:27 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 127674EE3BF1; Tue, 20 Jan 2026 13:02:27 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e3d0a1a9-f5f7-11f0-9ccf-f158ae23cfc8 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=1768910547; b=avZ0eKY3vGAqHeGRKpLiSeCxYnmfBl328uHXMvhgjAjwGLUvLgbU/yV8WtaY22CA7kfE l574JBfj712FdbNisxv8TQLf/IXiimg2ZM1rK+QIeoR5JghrEweWn4vgO63/2kU29ONDB iAB+21K2LqhObQV89hM08o/41Xrv1fFZ/514CaqqkRlaqEG0P7AU58X6uwowCR54dT41x T/YeX24rsxTuTOHudMtO1sTW7dNtLBMDCOKlp58ndiwEFLV4+Sfm1srOT/SwdFrK+krSd oyxsutBqkpM5cB2+qpslu3YCzYB7+6/Vdcc2w+p+4d1FCGE2tP+hp2X1KV7eZXDqS+gUw 4XBpUkWig2Gxh3ruRmzhydliROjLBFelo3xOleov2nPkopv11JuHn3ESrt+r4REyugch1 CCgb7g8prumar8fwF2Fa56AuVsvZeFHEnXPrHcrGRS30gBp/J28QAOtscZZqwBGB57v3x va3DHnKwq9Lpo/jE16uHmJ+Rn6KRLPJNfd76b+bi3HqGPH5gI7AxJsoPzCK9OTUjYYju9 MLZucQyVe1GbVOc3fCPVLq8zKsB3RnPXjD9T5lPF47b7vM315NjXfBRf8dDEYc+1q2Xho sHh+5KGPUAgALRIZC22iCQq6xQ8D1mn1PUoF8YlErDOHVPDLcfG8mkZaZaWfzpA= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1768910547; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type; bh=bOPHFfCMnh4bLWptDZ9ZCjdhNPzzJr6tewLGgz1GX+Q=; b=3MRtPzMwnmr3CHNiYUE0VWJNq1cr9EBWd87lnoDUeUpPHn+3/ByMaUfHaG4gHrMwtDXq M2okaaCiMV/tqYCv1b6+nT9/KyRifd+X6XnUSkKdHX40VtO6BD2PpJBr4QbmrZezwlbyc m2fnzquHHmfFRVWUQUHDEz+3yPI97slmFqePhGE7wT58nofP8M+5Ee8GsDlAFdoCEza8f fZoemAwfcfygI4EFXUuJwFj8h/eBhbkA9YPsWKwx8CBJVHdu6cFoNNHm00M+KT//U1GN/ lSkyxfcfIG1tLQO+jr5u/Ajkn/cGdXtmnbnW59lSsNcFe0zrkFpzCL4M2Ox7rTpfOV17l yT7j32PyzMcJdQbSMkpzXDi15ER1c8NS4KNiseB6tFzHja3inlR6Xp+iZU5A5RbbIUzWH OjJfkT888XhXX7YqABTk43owGyk2GOI+deYUrer43HzTuujvsV4BDLtSUV7RhG+zQfnLG lkJ88XMaE4nZDUpVTnqK0/TlAPw4xVU2XdWhU9EbwXG90/NGeMBvpLxqlRRPZBYo2v/4p bFq9awt4jPjBLknn6IQ2i7L+Esi69kybkGTqOGBUWuYtfP8xt0QbABoc/EVAh+9qOnMNf 5O+hdw4ny3buBZbWctQX0gm3Yu4Q/GDMYDXFiw/9bAsoZGiu0T0ZOGSKT+ofBoI= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Tue, 20 Jan 2026 13:02:27 +0100 From: Nicola Vetrini To: Alejandro Vallejo Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Subject: Re: [PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list. In-Reply-To: References: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> <20260120093852.2380-5-alejandro.garciavallejo@amd.com> <1d374226e3f91ab3bbc05c3354c8f8fe@bugseng.com> Message-ID: X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: multipart/mixed; boundary="=_01c4c3aaf12881b41ee82fe385f9161b" --=_01c4c3aaf12881b41ee82fe385f9161b Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2026-01-20 12:51, Alejandro Vallejo wrote: > On Tue Jan 20, 2026 at 12:41 PM CET, Nicola Vetrini wrote: >> On 2026-01-20 12:27, Alejandro Vallejo wrote: >>> On Tue Jan 20, 2026 at 12:21 PM CET, Nicola Vetrini wrote: >>>> On 2026-01-20 10:38, Alejandro Vallejo wrote: >>>>> It's clean. >>>>> >>>>> Signed-off-by: Alejandro Vallejo >>>>> --- >>>>> docs/misra/exclude-list.json | 4 ---- >>>>> 1 file changed, 4 deletions(-) >>>>> >>>> >>>> Hi. Do you have a link to a pipeline? >>> >>> In the cover letter. I only run it on allcode. >>> >> >> I see. I can spot these additional violations from earlycpio.c. It >> does >> not result in a failure, but only because x86_64-allcode has also >> other >> non-clean guidelines and is thus allowed to fail. Ideally in some >> copious free time I'd send a patch to create a subset of clean >> guidelines for the *-allcode analysis that is failing, so that the >> "allow_fail: true" can be removed. >> >> https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/people/agvallejo/xen/ECLAIR_normal/ucode-disable_v4/X86_64/12771570090/PROJECT.ecd;/by_main_file/xen/lib/earlycpio.c.html > > The web interface doesn't allow to search?! Sigh... thanks for the > pointer. > > I'll have a look. > It does allow searching, just not in the typical way. There is a technical reason for that that I won't go into. > Cheers, > Alejandro -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 --=_01c4c3aaf12881b41ee82fe385f9161b Content-Transfer-Encoding: base64 Content-Type: image/png; name="Screenshot from 2026-01-20 13-01-37.png" Content-Disposition: attachment; filename="Screenshot from 2026-01-20 13-01-37.png"; size=17587 iVBORw0KGgoAAAANSUhEUgAAAkYAAAFfCAYAAACr7AOiAAAABHNCSVQICAgIfAhkiAAAABl0RVh0 U29mdHdhcmUAZ25vbWUtc2NyZWVuc2hvdO8Dvz4AAAAtdEVYdENyZWF0aW9uIFRpbWUAVHVlIDIw IEphbiAyMDI2IDAxOjAxOjM3IFBNIENFVNmM+/IAACAASURBVHic7N15WFXl+vDxLwIiKPM8yaDh PKBkTog44RyKEppDR/GolDm8OaampnXS1FNplnocsnJACsNMzQFQnGcrTRSQUQQUkARlw37/EPbP LdPGRDTuz3V5yV7rGe699lLu/TzPWkurf//+SoQQQgghBLWqOwAhhBBCiBeFJEZCCCGEEEUkMRJC CCGEKKKjVMoSIyGEEEIIkBEjIYQQQggVGTESQgghhCiiU1hYWN0xCCGEEEK8EHRMTEyqOwYhhBBC iBeCllLm0oQQQgghAFl8LYQQQgiholPdAQghhBDVLXrDBuJ27CDj9Gke3LlT3eE8U3pmZpi/+irO /v68MmZMdYfzwpOpNCHEc1NYWEhSUhKOjo7VHYp4gZw5cwYADw+P5973nQsXOD5+POmnTj33vquD Rbt2dPj6a8xat67uUF5YMpUmhNDYoUOH6NGjB4aGhhgZGdG5c2d++OEHjeuPGzeO7du3A3D9+nW0 tLSqKlTxkrhw4QLdu3enR48enDt37rn2fefCBfZ3715jkiKA9FOn2N+9O3cuXKjuUF5YkhgJITTy /fff079/fzp27EhUVBQXL14kICCAt956i6VLl2rURkZGhupnW1tbgoODqypc8RK4cOECXl5eZGdn k5WVRbdu3Z5pcpSZmcn58+fL3H98/Phyp8106tVjtFJZ6h/fq1dV5bS0tWk+fTq+V64wIi8Pv7g4 OqxdSx0rK1WZ0UolfnFxFcb82qpVjFYqGVBK4tJx/XpGK5XY9uhRamzFfbdetAjK+dLx4M4djo8f X+b+v/76i7Nnz1JTb+cjiZEQokK5ublMmjSJL774gkWLFtGyZUtcXFx455132LZtG++//z6JiYlc v34dGxsbJk2ahJeXFy1atGDt2rUALFu2jH379rF48WJmzJhBSkoKQ4cOVfWxdu1a3NzcMDExoWvX rly8eBF4NLJkZ2fH/Pnzadu2LY6OjsyZM0dVb9OmTTRo0ABTU1Pat29PRETE8z044qk8nhQVe1bJ 0dWrV/n666+ZPXs2R44cKbVM9IYNGo8UPbx7l2tff632J27bNtX+Lt9/T9ulS9E1MiIxLAxFTg5u 48bR5+hRdAwMNI5bx8AA1xEjADBr1QqrTp0qFdvN4GBqm5jQat48XAICyq2XfuoU0Rs2lLovLy+P tWvXMmvWLMLCwsjMzNT4PfwTyOJrIUSFjh07xr1793jzzTdL7Ovbty8ODg7s3r2bHj16kJqaiqWl JREREaSmptK6dWuaNm3K9OnTiYqKonPnzrz33ntcv35d1UZxcvXzzz/j7u7O6tWr8fHx4cqVKwCk pKSgq6vL2bNnuX79Oi1atCAgIAAnJyfGjx/PxYsXady4MV988QUTJ07kjz/+eG7HRlReaUlRseLk 6NChQ7Rp00bjNnNzczl+/DgRERHcunULAF1dXVxdXUstH7djh8Zt309O5viECaXus/H2xtnfn7uX LrGnUycUOTlo1aqF9w8/YOTmhmmrVqQdP65RPy4BAdQ2NiY+NJT6vr40CgridlRUpWJrMWsWbT7+ GJNmzSrsL27HjlIXY9epUwcnJydu3rzJ7t272bNnD61ataJr1640btxYo/fyMpPESIgapLKjKe7u 7gDExcVhYmLCw4cPefjwYYlyNjY23Lx5k5ycHLS1tZkwYQLZ2dno6+szePBgNm/eTMuWLVEoFDx4 8IDs7GxycnIAyM7OZtOmTfzrX/+icePG5ObmMmbMGL7++mtCQkJUC3JHjBhBdnY2VlZWuLi4cPny ZWxsbNDV1eWLL75gyJAhjBgxgtGjR6v9wi1vKkVUHWdnZ5ycnEpsLy8pKlaZ5CghIYGIiAhOnTrF gwcPgEfno6enJx06dKBu3bql1ss4fVrj92JgZ0eHr75S73f3bhJ378a+d28Arq1di6LonFYWFnLI 11fj9ou5jR9PYX4+x8ePx7RFC5yHDOH01Knk3b5dZp06Vla0XrAAAJ26dXF9801QKknev7/C/so6 BnXr1mXOnDncvHmTyMhITp8+zfnz5zl//jzW1tZ4eXnRsWNH9PX1S61/8+ZN4jSYNnxaXl5eVdY2 SGIkhNCApaUl6enp5ObmlvqfYUJCAtbW1gCYmJhQp04d1T4zMzPVtFhZ0tPTS1yp5uTkRGJioiox Mjc3V+3T0dGhsLCQOnXqEBYWxrJlyxgwYAAGBgZMmzaNoKCgp36v4tkwNTUtsU2TpKhYecmRQqHg 7NmzhIeHExMTAzw6J1599VW6dOmCm5tbhe1X5pL82qamuD2xJif31i0Sd+9WrSPKLRqlelpmrVtj 0a4d8aGh5N2+TfSGDbRZsoRXxo7l8scfl1mvjqUlrT74QPU65cABjr71FqmRkRX2WdExcHJyYuTI kQwdOpQTJ05w5MgREhMT2bFjB6GhobRr146uXbuW+LdrampapYlRVZPESIgaqHgkSFMdOnTAzMyM zZs3M+GJKYV9+/Zx69YtevXqxcOHD7l79y5//fWX6pt6TEwMDg4OAGVehWZvb098fLzatri4OAYO HFhuXJmZmTx48IBt27ahUCjYv38/I0aMwNvbmyZNmjzVexXPhqGhodrryiRFxUpLju7du8fChQu5 d+8eAFZWVnh6etKxY0fq1auncdt6ZmYaJ0eZv//OrubNS933sKgNAzs7te0mzZujVasWdy9d0qiP 4sSrjoUFHb76Cj1LSwAaTZjAb598grKMhdCZv/9OmLs7DUaNouO6ddStX5+sxxaGl0fPzEyjcnXq 1KFr16507dqVmJgYjhw5wunTpzl69ChHjx7F09OTEUVro+DRZ18V/+6e1+ivLL4WQlRIT0+PFStW sGDBAj755BP+/PNPYmNjWb9+PYGBgcyePVuV/BQWFrJgwQIePHhAVFQUoaGhvPHGG6p24uLiSizm DAgIYOPGjZw7dw6FQsHq1atJSUnBx8en3Lju3bvHoEGDOHLkCDo6OlhZWaGtrV3il7J4/p5MggcM GFCppKhYVlaW2i/dhw8fqpIiBwcHxo0bR69evSqVFAGYv/pqpWMpTfKBAwC8Mm4cOkVfBrR0dOjw 1VcMvHgRu169KmxDp169R1NggFXnzriNH4/T4MEA1K1fH4f+/cutX5ifT/T//scfn32GkZsbXbZu LfeqtGJPcwxcXV0ZPnw4fn5+6Og8Glu580SC+bLfhkNGjIQQGvH19cXS0pJPP/2UL7/8kvz8fJo3 b87nn3/OoEGD1MoaGBjQpEkTjIyMWLVqlerb4+DBg5kwYQJ3795l7ty5qvL9+vUjNTWVwMBAUlJS aNGiBaGhoVhaWqp+CZbG0dGRVatWMXnyZFJSUrC2tmbNmjWqJE1UH6VSqfYLctiwYURFRXHs2LFK tdOxY0e1NSX16tWjS5cunDx5ksTERJYsWYKzszNeXl68+uqr6OrqatSus78/yfv2aVS2tDVGACfe eYekvXtJ3L0bh/79GXT1KmknTmDasiVGbm7cjooipShxAqhjbl6ineRff0XPzAxdQ0OufPEFp959 V7Wv/qBBeP/wA42Dgkj46acK4zw3Zw6OAwZg1bEjbv/+N9e+/rrc8s7+/hW2+bjbt28TGRnJsWPH +Ouvv4BHt93o0KGDWrmX/b7RcudrIWqQ4sXXVTW9FBMTg7u7O1lZWVXSvnh5GBgYqEYUiqWlpWH1 2L19NHH79m0si6aVHld8FVp4eDipqamqPjt06ECXLl2wsbGpsO2fX3ut3Ev2derV481yEvNv9fUp yMujVu3atJg1iwajRlG3fn3yUlOJDw3l/Lx5PCwaHR1dxq/a35cvx6ZrV8zbtiXM3V3txota2toM uXkTAzs7fnBzo8WsWbwydiz7e/Yk7cQJ3rx3r8Q0n03XrvgcOsSDu3f5sVEjHqSnl9qvRbt29Dt5 stzjA49GgC9evEhERARXr15FqVRSq1atcq9SUygU3L9/v8K2K6t4Kq2qF19LYiREDSKJkXhe9PT0 0NPTU9uWnp5eIskxNjZmypQppKens3r16hLtpKWlYWFhUWY/SqWSq1evcvjwYS5fvqy6KaGbmxte Xl64u7ujra1dat3iO1//056NVhE9MzN6HTxY7mNB7t69q1pDVDz1bWhoSOfOnfHy8ip1cX2xBw8e qK4QfJaeV2IkU2lCCCGeufz8/BKJUWnfw01MTFiwYAFXr14tNTGq6Lu7lpYWTZo0oUmTJmRkZBAZ GcnRo0e5du0a165do1WrVmVepWjWujW9Dh6UZ6U9ITMzkzlz5qiSTFdXV7p27Urbtm1LjAKWJj8/ /5nFWx0kMRJCPDOurq4yWiSAR1MwDx8+pHbt2s+tT3NzcwYNGsSAAQM4c+YMhw8fRqFQlFvHrHVr +p08SfSGDcTt2EHG6dP/uBEkPTMzzF99FWd//1Jv6PikgoICtLW1ad++Pd7e3tSvX1/jvh4+fPjS P0pEEiMhhBBVIi8vj1q1amk0yvAs6ejo0L59e9q3b6/x4yxeGTNGo6ShJjAyMuKTTz4p8+aYZVEo FOTl5VVRVM+PJEZCCCGqTPFNQXV0dLCwsGDBggVq02MmJiYAWFhY8MFjNyqER9Nk5a0v0kRx+0Jz urq6Gl/dV0yhUJCbm1tFET1fsvhaiBqkqhdfC1GWOnXqPNdpNfH8PHz48LmMFMniayGEEP8YeXl5 PHz4EF1dXbS1tdHW1n7pbwRYUymVSgoKCigoKCA/P/+lX1P0JEmMhBBCPBeFhYVVchm3EM+SPBJE CCGEEKKIJEZCCCGEEEVkKk0IoaJQFHLo0HESE1M0Km9vb0OvXp1krcgLJizmAh+dDOPPu5p9jo1M bZnX/nX6urSs4siEePFJYiSEUDl06Dg9enhiYqLZk8rv3MniwIHj9OzZsYojE5UxN2onCfc0v0nh n3dTeD8qWBIjIZCpNCHEYxITUzROigDMzIxJSEiuwojE06hMUlTsZnZGFUQixMtHEiMhhKiB6urq 8du4pVwK/KS6QxHihSKJkRDimTM2Nlb7Y2dnx9ChQ7l27doz7Wfz5s307dv3mbZZWU2aNOHo0aOV rjdlyhTef//9KohIM9+9/g6Nze3Q1yn7povdu3fH2NiYEydOlNjXv39/jI2NuX37dlWGWaPFxMRg bGxc3WHUOJIYCSGqxLfffssff/zBH3/8waFDhzAwMOCNN96o8GnpleHt7V2tyQXAZ599RuPGjas1 hsqa13kQ/Ru6k6t4yOCQFeWWNTMzY+fOnWrbkpOTuXjxYlWGKAAbGxu++eab6g6jxpHESAhRJSws LLC3t8fe3p7GjRszdepUYmJiyMzMZMOGDQwdOpQuXbrQoEED0tLSuHTpEn369MHR0ZEOHTqwf/9+ ADZt2kTXrl3V2u7Tpw8bNmzg8OHDLFmyBHj0RPAlS5bQrFkzGjZsyNtvv829e/dIT0/H1NSUlJRH V2gdOnQIY2NjoqOjATh16hTNmzdXa78ydSZPnszVq1eJiYnBzc2NJUuW0KVLF5o2bcrChQtVbV6/ fp0+ffpga2tLv3791EZacnNzmTNnDm5ubjRo0IBx48aRkZHxVLE/TlurFtt838Vc///WjfVt0Jr5 nQejREnAj59zOS2h3M9x4MCBhIaGUlBQoNoWEhJCv3791ModO3aM7t27Y29vz2uvvcauXbtU+1xc XDhz5ozq9eOjZefOncPLywsHBwdeffVV1q9frypX1jlRmk2bNtGmTRscHR3p27cvly9fBmDs2LHM nTtXVe7+/fvY2Njw559/lnnOAKWeo4/bvHkzvr6+BAQE0Lt3b7y9vTl+/DgA165do1mzZowbNw5H R0d++eUX0tPTGTt2LA0aNKB58+asXLkSpVLJ9evXsbS0VHvY7ZIlSxgzZgy3bt1i1KhRFR6P6dOn M3nyZFW5nj17MnbsWNXrQYMG8f3335d57IQ6SYyEEFXu3r17bNq0CWdnZ0xNTQE4ePAg77//PgcO HEBXVxdfX198fX2Ji4tj2bJljBs3juvXr+Pr68uVK1eIjY0FIDExkXPnzjFo0CC1PpYvX87u3bvZ u3cvFy9eJDc3l+nTp2NhYUGbNm0IDw8HIDIyEn19fY4cOQLAr7/+Sp8+fdTaepo6AKmpqejq6hIZ Gcnu3bv58ssv+e2331AqlQwfPpx27dpx8+ZNZs2axYEDB1T1Zs+ezcmTJ4mIiODixYsUFhYSGBj4 1HEU69ugNUMat+Nn/xnU0dHFzcyWrb6T0EKL2Ye38/ONCxV+dq1atcLMzEz1nD2AHTt28MYbb6he x8fHM3jwYAIDA4mPj2f58uUEBQWpEoXyTJs2jX/9618kJiaybt065s2bR1JSEpmZmWWeE0/auXMn ixYtYt26dcTGxtK/f38GDRpEZmYmw4YN48cff1SNVIaFhdG4cWMaNWpU5jlT7PFz1NLSskS/4eHh vPPOO+zdu5fFixczfPhwsrOzgUfnqbOzM8ePH6dLly6MHTsWLS0tLl++zC+//MK2bdv47rvvaNiw IS1btuSnn35StRsSEqJ2fIFyj0fv3r05fPgwAH/99RdXrlwhMjISeJR0Hz9+nJ49e1b4WYhHJDES QlSJQYMGYWtri42NDQ4ODkRGRvK///1Ptd/V1RUfHx9cXFzYs2cPlpaWjB8/Hm1tbTp37kzfvn35 7rvvMDExoXfv3oSEhACPfgn27NlTlWAV++abb5g5cyaOjo7UrVuXhQsXsn37dvLy8ujdu7cquYiI iGDkyJGqdUH79+8vNbl4mjqA6pu6q6srLi4uxMbGcunSJW7cuMGcOXOoXbs2np6eDBgwAHj03Kng 4GDmzZuHra0t9erVY+nSpRw6dIjk5OSnjgMg7Po5vv89Cg9bV34ft4zzYz+irq4emy5F8OnJ3WXW e9KQIUNUx//q1asolUqaNWum2v/TTz/RunVrhg0bpvr8hg0bxtatWyts29jYmN27d3PgwAEaNWpE UlIS9vb25Z4TT9qxYwdjxoyhbdu26OjoEBQUhLm5Ofv378fb25v8/HxOnjwJQHBwMAEBAUD55wyo n6OladeuHZ07dwagU6dOODg4cOjQIdX+cePG4eDgQEZGBuHh4Xz88ccYGBjg6OjIlClT2Lx5MwDD hg3jhx9+AODs2bNkZWXRo0cPtb7KOx6dO3cmLS2NuLg4oqKi6Nq1K9ra2ly7do3IyEhatGhRamIn SieJkRCiSqxevZqoqCiOHz9OTEwM586dw8PDQ7Xf1tZW9XNCQgLR0dE4Ojqq/oSGhpKc/OhWAMOH D1etc9m5c2eJb9NKpZKkpCSCgoJU9Tt27Iiuri6JiYn4+PgQERFBZmYmCQkJjBs3jiNHjpCWlsaN GzdUv9we9zR1AMzNzVU/6+joUFhYSGpqKmZmZujp6an21a9fH3j0cNWcnBzV6+I2DAwMSE5Ofuo4 io35eS3Hk6JxMrZAT1uX40nRTNi7odw6Txo6dCi7d+/mwYMHbN++HX9/f7X9aWlpODo6qm1zcnIi MTGxwrbXr1+PjY0NQUFBuLi4MHXqVHJzcys8Jx6Xnp5eZv/a2toMHTqUkJAQMjIyOHr0KH5+fhWe M6B+jpbGxsZG7bWZmRmpqakA1KpVCysrK+DR+Q2opvocHR157733VFOkfn5+nDhxgrS0NIKDgxky ZAja2tpqbZd3PPT09PD29iY8PJyIiAg8PT3p1KkTR48erTB5FiXJDR6FEFXCzs4OV1fXMvfXqvV/ 38usra3x8PBQW0OSlJSEgYEBAD169ODtt99mz549JCQk4OPjo9aWlpYW1tbWrFmzBm9vbwAUCgWx sbG4uLigra1NrVq12LhxI+3bt8fNzQ0dHR2+/PJLvL29qV275JVZLVu2rHSdstja2pKRkUFubi76 +vrAowXMFhYW6OvrY2Zmxs2bN1XHKy0tjfv372NpaYmTk9PfikNRWMCA4GWc+dejtVgDgpehKCwo t86TXFxcaNCgAfv37+eHH37gl19+Udtvb29f4sq12NhYVWKgra2t9vDYjIwM6tatS0FBAVeuXGH5 8uXo6elx8eJFRo0axZYtWyo8J57sPz4+Xm1bXFwcAwcOBB6NyAwePJgmTZrQpUsX1ehJeedMZGSk 2jlamuKE5/H3bG9vD6B2N3gbGxvVCE7x55+ZmUlOTg4ApqamdO/enZ9++onQ0NBSR9oqOh69evUi PDycmJgYvvrqK/T09AgPD+f8+fNs27at3Pch1MmIkRCi2vXr148///yTb7/9loKCAqKjo+nRowe7 dz+a7tHW1sbPz4/p06czePDgUpOBYcOGsXjxYpKSklAoFCxZsgQ/Pz/V/p49e/L555/TpUsXADw9 PVmzZk25l/s/TZ3StGjRgubNm/PBBx/w4MEDTpw4obY4OSAggMWLF5OSkkJOTg4zZ86kXbt2ODk5 PZM4MvPu03DNVBqumUpm3v1KxV5s6NChfPjhh9SvXx87Ozu1fQMGDODy5cts3bqVgoICoqKi2Lp1 q2pkqWHDhmzZsoXMzEwOHz6smm7S1tZm8uTJrF69moKCAmxtbdHS0sLMzKzCc+JxAQEBbNy4kXPn zqFQKFi9ejUpKSmqBLp58+ZYWlqyfPlytdHGis6Zipw7d46dO3eiUChYtWoVeXl5dOvWrUQ5V1dX PDw8mDVrFvfv3yczM5O33nqLDz/8UO09rFixAkNDQ9zd3Uu0UdHx8PHx4fDhwyQnJ9OkSRO8vLzY u3cvhYWFNGnSROP3JCQxEkI8xsHBljt3sjQun55+B0fH8qcbNGFpaUlISAhbtmzB2dmZ119/ncDA QEaOHKkqM2zYMBITE1XrQ540a9YsPD096dWrF87Ozpw+fZrg4GDVlISPjw937tzB09MTgC5duvDg wYNyF6U+TZ2yfP/99/z55584OTkxa9Ystau65s+fz6uvvoq3tzdNmjShoKBA7SqiysZhV8+01O3l cTIyL3e/n58f169fLzGNCY9GxIKDg1m3bh2Ojo68++67rFixQpUkLF68mD/++IPGjRvzxRdfqF1p tWnTJn7++Wfq169Px44d8fX1xc/PT6Nzoli/fv2YO3cugYGBODo6smvXLkJDQ9XW1QwbNoysrCy1 ZLKic6YiLVu2JCQkBGdnZ3788UdCQkJKHdHS0tJi8+bNZGZm0qJFC1q3bo2NjQ3Lly9XlfHx8eH+ /ftlnt8VHQ9bW1ucnJzo0KEDWlpauLi4YG5uLtNoT0FL+SxvKiKEeKEVX1lU2jdSeLRW59dfj5OY qNljPhwdbejevWOFUw7i+QqLucDiE7uIzkzVqHwjU1vmd3idPs7yrDRNbd68me3bt7Nnz57qDqXG OH/+PABeXl5V2o+sMRJCqGhpadGrlzwQ9mU3wLU1A1xbV3cYQryU5GueEEIIIUQRSYyEEEKISho9 erRMo/1DSWIkhBBCCFFEEiMhhBBCiCKSGAkhhBBCFJHESAghhBCiiCRGQgghhBBFJDESQgghhCgi iZEQQgghRBFJjIQQQgghisgjQYSogYqfOSSEEEKdjBgJIYQQQhTRUiqVyuoOQgghhBDiRSAjRkII 8Q8THx/PyJEjMTc3x8nJiUmTJpGVlVXdYQnxUpDESAjxjxAXF1fdIZRQWFhIQkLCc+3z5s2bdOrU CSsrK06fPk1oaCiJiYlMnDjxucYhxMtKEiMhhMYOHDhAr169MDU1xcTEhJ49e3Ly5MnqDovr16/j 4eHxTNtctWoVvXv3/lttjBs3ju3btwOPYtTS0noWoZVrwIABTJw4keXLl+Pq6oq7uztr165l165d FBYWVnn/QrzsJDESQmhky5Yt+Pr68vrrr3PhwgUuXLhAhw4d6NatGxcvXqzW2HJycsjLy6vWGEqT kZGh+tnW1pbg4OAq7/Pnn39mzpw5REREkJKSAoBCoajyfoX4p5DESAhRoby8PCZPnsyqVat4++23 cXJywtnZmUWLFjF27FhOnz4NwJAhQ/jPf/6jqrdt2zbVSE5AQADjxo3Dzs4OT09Prl69ipOTEyNG jMDExISwsDDS0tIYPnw4VlZWODs788knn1B8fciIESOYNm0a3bp1w9XVlfbt2/P7779TUFCAj48P 9+/fx8HBgVu3bqnFrlQqmTp1KtbW1lhbW9O/f38SExOBRwnD/PnzcXJywtramjFjxpCdnV3i/VdU bu3atTRo0AAjIyO6devG9evXWbZsGfv27WPx4sXMmDGDlJQUhg4dqlbHzc0NExMTunbtqkour1+/ jp2dHfPnz6dt27Y4OjoyZ86ccj+f1NRUWrduTUxMDI6Ojuzdu5fXX3+dGzduADBz5kz8/PyoVUv+ yxeiInIfIyFqkIiIiEqVd3d3B+Do0aNkZWXRp0+fEonD4sWLAcjOziY/P5+8vDxVmfv371NQUEB2 djYKhYI9e/awa9cu9PX1ycnJIT4+Hnt7e44dO4apqSn+/v5YWlpy6dIlMjIyGDJkCIaGhowYMYL8 /Hy2b99OREQEVlZWvPvuu8yePZtvv/2WkJAQfHx8+OOPP1SxFNu3bx979+7l9OnTGBgYMHHiRBYs WMCKFStYunQpP/74I3v27MHMzIxJkyYxYcIEvvrqK/Ly8lAoFGRnZ5db7vDhw8ycOZOQkBDc3d1Z tGgRw4YN4+DBg0RERNChQwcmTZpETEyMKradO3cyZ84cgoODadWqFWvXrqVnz56cOXOGnJwcUlJS KCws5PDhw8TExNChQwf69+9P8+bNS3xGmZmZ9OzZk549e2JhYUFwcDBjx45l69attGzZknfeeYeT J0/y66+/qh0XuZeVeFl5eXlVafvy9UEIUaH09HTq1q2Lvr7+32rHx8eHRo0aUb9+fdW2cePG4eDg QEZGBuHh4Xz88ccYGBjg6OjIlClT2Lx5s6psv379sLKyAqBHjx6qEZHyGBkZkZiYyHfffUdiYiLr 1q1jxYoVAHzzzTfMnDkTR0dH6tatTpV8wgAAIABJREFUy8KFC9m+fXuJabnyyoWEhODv74+Hhwfa 2trMnDmTTz/9tNyYduzYwZgxY2jbti06OjoEBQVhbm7O/v37VWXGjh0LgKurKy4uLsTGxpba1rRp 02jbti0fffQRhw4dIjAwkO3bt+Pp6UlcXByRkZHs2bMHExOTCo+VEEJGjISokYpHgjRlZWVFTk4O f/31F3Xr1lXbl56ejr6+fontpbGzs1N7XatWLVWiU3z1Vps2bVT7CwsLMTU1Vb02NzdXq6vJYuIO HTqwcuVK1q9fz7x582jQoAHLly/H09OTpKQkgoKCmDRpkqq8rq6uaqoNHk3FlVcuNTWVjh07qrYb GBhUeHzT09NxdHRU2+bk5ERiYqJq6vHx96qjo1Pqey0oKCAsLEw1Uubm5sbOnTt57bXXSExMxNnZ maNHj5YaQ2XPASGq2/Ma5ZQRIyFEhTw8PDA2NiYkJKTEvmnTpjF+/HgAtLW1efjwoWrfnTt31Mo+ eVXW469tbGzQ1tbm2rVrJCQkkJCQwO+//87evXsrjK+8q70SEhJo3rw5+/fvJy4ujkGDBjF69Gi0 tLSwtrbmu+++U/UXGxtLVFQULi4uam2XV87Ozk61yBkeLQR///33efjwYZlx2dvbEx8fr7YtLi5O lSRqSqlUUlBQgI7Oo++4Dg4OvPbaayxbtow33nijUm0JIR6RxEgIUaHatWuzcOFCZs2axYYNG0hM TOTGjRu8//77HDhwgBkzZgDQsGFDQkNDSU5O5vr162zYsEHjPlxdXfHw8GDWrFncv3+fzMxM3nrr LT788MMK6+rp6fHgwQOio6MpKChQ23fs2DGGDRtGQkIChoaGGBkZYWZmBsCwYcNYvHgxSUlJKBQK lixZgp+fX4n2yys3dOhQtm/fzoULFygoKGDFihWcOnWK2rVro6enR1xcHJmZmWrtBQQEsHHjRs6d O4dCoWD16tWkpKTg4+Oj8fGCRyNJ/fr147333kOhUKBUKvnoo4/YuHEj27Ztq1RbQohHZCpNCKGR t956C0NDQ7788kvmzp2Lrq4uHh4e7Nmzh5YtWwIwfvx4Lly4gIeHB46Ojrz11lsa/4LW0tJi8+bN zJo1ixYtWlBQUEDv3r0rXK8Dj5KqDh060KlTJ8LDw2natKlqn7+/P1euXKFbt27k5OTQtGlTVcI2 a9YslEolvXr1Iisri9atWxMcHIy2trZa++WV69y5M4sXL2bMmDHcvn2bdu3asXHjRgAGDx7MhAkT uHv3LnPnzlW1169fP1JTUwkMDCQlJYUWLVoQGhqKpaUl9+7d0+h4Ffviiy8YM2aMaurN3d2dffv2 lZiqE0JoRp6VJkQNUnxVmqwvEUK8bIrXGMlVaUIIIYQQz4kkRkIIIYQQRSQxEkIIIYQoIomREEII IUQRSYyEEEIIIYpIYiSEEEIIUUQSIyGEEEKIIpIYCSGEEEIUkTtfC1HD5efnk5GRUek7LgshxNMy NDTE3NwcXV3d6g6lBEmMhKjB8vPziYuLo379+ri5uVV3OEKIGiItLY24uDicnZ1fuORIEiMharCM jAzq16+PpaVldYcihKhBiv/PycjIwMbGppqjUSdrjISowe7duydJkRCiWjzNQ5OfB0mMhBBCCCGK SGIkhBBCCFFEEiMhhBBCiCKSGAkhhBBCFJHESAghhBCiiCRGQoiXSnJycnWHIESNV97VZC/ilWaV IYmREEJjycnJzJw5k27dutGxY0f8/f0JCQnRqO6NGzfo2LHj3+p/z549LFu2TPW6b9++nD179m+1 WZovvviCHTt2ALB06VLCwsLU9qenp+Pj40NGRsYz71uIF92tW7e4du0aCQkJJfbFx8dz7do1UlNT qyGyZ0MSIyGExqZOnYq2tjZfffUVO3fuJDAwkM8++4w9e/Y8l/4zMzNRKpWq1++//z6urq7PvJ+T J0/Svn17AE6cOMFrr72m2nfq1CnGjh0rSZGosQoLCwG4ffu2WgKUmppKWlqaWpmXkSRGQgiN5Ofn c+PGDUaPHo2bmxt2dnb06tWLyZMnk5mZqSq3f/9+/P396dq1KxMnTiQ+Pr7U9sord+HCBUaNGoWn pyf+/v4cO3aMCxcusHbtWk6dOkVgYCAAS5YsISYmBoDz58/z1ltv0aVLF/z9/Tl48KCqvb59+/LN N98wevRo+vbty/Tp07l//36JmIYNG0bnzp25du0ab775Jp06dSIxMRE/Pz9ycnI4fvw4CxYsICgo 6JkcUyFeRnZ2dhgZGQGQmJhIZmYmd+/eJTExEQAjIyNsbW2rM8S/RRIjIYRGdHV16du3L3PnzuX7 77/n6tWrFBYW4ufnx/Dhw4FHycnixYuZPXs2Bw4cwNPTk8mTJ6NQKNTaKq9cVlYWU6ZMYfDgwYSH hzNp0iRmzJiBq6sr//73v2nXrh3r169Xay85OZl33nmHIUOGcPjwYWbOnMnChQu5cOGCqszZs2dZ t24dP/74I/Hx8SWmxwC2bt3KihUr8PT05MiRIyxZsoQePXpw5MgR6tWrR9OmTdm1axeenp5VcISF eHk0aNAAfX19AGJiYlRfUPT19WnQoEF1hva3SWIkhNDYwoULmThxIr///jtTp07F29ubDz/8kKys LAB27dpFv379cHd3R0dHh+HDh1NQUMCZM2fU2imvXFRUFNbW1vj6+qKtrY2npydff/01enp6ZcZ1 6NAhmjRpQv/+/dHW1qZt27b079+f3bt3q8oMHDiQ2rVro6enR9u2bcscybp48SKtWrUC4NKlS7i7 u6v2GRsbv3APvBSiOtSqVYtXXnkFHR0d1fS2jo4Or7zyCrVqvdyphTxEVgihsby8PLp160a3bt2A RwstV65cyZw5c1i9ejW3bt3i0qVL/PLLL6o6+fn53Lp1S+2ZbOWVy87OxtraWq3fZs2alRvXnTt3 Sgzd29racurUKdVrExMT1c/a2toUFBSUaMff35+4uDjVOqr8/Hx0dHRYuXIl+/fvp169euXGIYR4 +UliJITQyIEDB/joo4/Yt2+fatSkfv36jBo1iilTpgBgYWHBiBEj1NbgxMfHY2VlRVJSkmpbeeXC w8O5ffu2Wt8bNmygR48eaGlplRqbjY0NFy9eVNuWlJSEmZlZpd7jjh076Nu3L9u3b8fQ0JAePXqw Z88eateuXal2hPinKywsJDo6GoVCofp3qVAoiI6OpnHjxi/1qNHLG7kQ4rnq3LkzdevWZfr06Rw7 doz4+HiOHTvGZ599RqdOnQDo378/O3fu5LfffkOpVBIZGckbb7xRItEpr1zHjh25ffs2u3fvprCw kKNHj7JlyxaMjIyoXbs2GRkZpKenq7Xn7e1NdHQ0u3fvpqCggHPnzvHzzz/Tp0+fSr3H7OxstLW1 MTQ0JCUlBTMzM0mKhCjFjRs3yM3NBcDV1VV1dWhubi43btyoztD+NhkxEkJopE6dOqxdu5ZVq1ax YMECsrKyMDc3p3v37qqRn/bt2zNt2jQWLlxIamoqtra2fPLJJ9SvX1/tP8vyygF89tlnLF++nGXL lmFnZ8enn36KiYkJ7du3Z9OmTbz55pvs27dP1Z6lpSX//e9/+eyzz1i6dCkWFhbMmjVLdcm9pq5d u0bDhg0BiI6OVv0shPg/xVPeAA4ODqppagcHBxITE8nOziY1NbXElPjLQkv5+E1BhBD/aBEREQCq BcXR0dG0bdu2OkMSQrxkUlJSSE5OxsrKCkdHR7V9CQkJ3L59GwcHB40So7Nnz/LKK69o1O/58+cB 8PLyqnzQlSAjRkIIIYTQmK2tLRYWFqVeoeno6IiNjc1LffWmrDESQgghRKWUl/i8zEkRSGIkhBBC CKEiiZEQQgghRBFJjIQQQgghikhiJIQQQghRRBIjIWowQ0ND0tLSqjsMIUQNlJaWhqGhYXWHUYIk RkLUYObm5sTHx0tyJIR4rtLS0oiPj8fc3Ly6QylB7mMkRA2mq6uLs7MzGRkZZT5tXgghnjVDQ0Oc nZ1fyEv7JTESoobT1dXFxsYGGxub6g5FCCGqnUylCSGEEEIUkcRICCGEEKKIJEZCCCGEEEUkMRJC CCGEKCKJkRBCCCFEEUmMhBBCCCGK6Pj7+1d3DEKI5+Ttt98G4O7du9UciRBCPJ2qzlt0mjVrVqUd CCFePHFxcdUdghBCPJWqzltkKk0IIYQQoojc+VqIGiQ8PPyp6i1YsIAFCxYQHh5O165dX5i/i+MS QohnRWvBggXK6g5CCCGEEOJFIFNpQogKPe1IU1V70eLKzMys7hCEEH+TllKplBEjIUSlxMXFMX36 dA4ePMj9+/dp2LAh77zzDhMmTABg/fr1fPvtty9c4lKVtmzZwo4dOwgLC3vmbY8YMYKGDRvKtKEQ z4GMGAkhKvTkL+QBAwago6PD4cOHuXr1KnPnzmXGjBls2bKlWuOqThkZGcj3TCFefpIYCSEq9HgC 8vDhQ3777TdmzJhBq1atcHZ2JiAggKVLl5KRkaEqd//+fQIDAzE1NcXJyYkdO3ao9h05coT27dtj ZGRE8+bN2blzJwCTJk1i/PjxqnIdO3Zk2LBhqtc+Pj5s2rSp1LiK2djYMG3aNExNTZk9ezYKhYL5 8+fj5OSEtbU1Y8aMITs7G3g0stWzZ08GDhyIp6cn7dq14+jRoxXG+WQ/I0eOZMGCBRw8eBBPT0+U SiVTp07F2toaa2tr+vfvT2JiYolYK/N+4+Li6N69O3Xr1qVNmzb89ttvqnLbt2+nWbNmmJiY0L17 d65duwbA1atXcXJyYsSIEZiYmBAWFlbu8RBCAEohhKjABx98oPZ6xIgRyiZNmihXrlypPHv2rFKh UKjtX7dunRJQbtiwQXn//n3lp59+qjQ2NlYWFBQoY2Njlfr6+spNmzYp8/PzlYcPH1YaGhoqjxw5 oty7d6/SxcVFqVQqlffu3VMaGRkpbWxslEqlUvnXX38pDQwMlKmpqWXGpVQqldbW1so+ffoo4+Pj lcnJycpFixYpW7RooYyLi1Peu3dP+cYbbyhHjRqlilNLS0t5+PBhpVKpVIaHhyvNzc2VmZmZ5cZZ Wj8rV65U9uvXT6lUKpW7d+9WNm3aVHn37l3lgwcPlAEBAcqJEyeWiFXT9/vmm28qLSwslMePH1dm Z2cr/fz8lP3791cqlUplZGSksl69esrIyEjlw4cPlStXrlQ2bNhQ+fDhQ+WVK1eUgHLevHnKmzdv Ku/du1fu8RBCKJVyub4QNUhERESlyru7uwMwbdo0tVGFVatWERYWxq5du1i6dCk5OTkMGjSIhQsX YmZmRm5uLk2aNMHPz4/8/Hz8/Px47733uHnzJlu3bqV169YMGjSI+/fv06ZNGwICAli/fj3Lli0j NTWVS5cuce3aNby8vDhz5gxnzpwhNjaW5s2bU6dOHVUsT8YFUFhYyJAhQzA2NgZg3bp1LF68GFNT UwoLC5k3bx4tW7Zk2bJl5Obm0q5dO9q0aUN2djbu7u7Y29uza9cuEhMTy4yzZcuWJfrJy8tDoVCQ nZ2Njo4O8fHxrFmzhj59+rBmzRpq1apVItY2bdpo9H7z8/MZPHgwTZs2RalU4uvry5IlS8jOzmbN mjUEBATQqlUrcnNzGTNmDCtXruTnn3/GwcEBgFGjRmFiYkJhYWG5x6NOnToAnD9/vlLniRDPk5eX V5W2L1NpQogKffzxx2qvc3NzGThwIP/73/+4evUq4eHhpKamMmbMGFUZMzMz1c96enoAFBQUkJaW hqOjo1p7Tk5OJCYmoqenh7e3N+Hh4URERODp6UmnTp04evQo+/fvp0+fPuXGVczOzg4ApVJJUlIS QUFBODo64ujoSMeOHdHV1VVNbdnY2KjVNTMzIzU1tdw4n+znSR06dGDlypXs2rULDw8PXnvtNSIj I0uUq8z7ffJ4FhQUAJCYmMi3336ren+Ojo6kpaWRkJAAQK1atbCystL4eAhR08mIkRA1UPFIkKZm z56t+jk0NJTJkycTHR1N7dq1AWjYsCFTpkzR6BlG9vb2nDhxQm1bbGys6pd3r169CA8PJyYmhq++ +go9PT3Cw8M5f/4827ZtKzOux2lpaan+tra2Zs2aNXh7ewOgUCiIjY3FxcWFqKgoVQLxeCz29vZo aWmVG+fj/Tz5c0JCAs2bN2f//v1kZ2ezatUqRo8eTWxsbIlYK/N+S2NjY8Pbb7/N/PnzVdtu3LiB nZ0dCQkJJWIs73gUq+z5IcTz8LxGMmXESAhRocdHZnx8fDA0NGTEiBEcOHCA69ev8+uvvzJv3jx8 fHwqbGvAgAFcvnyZrVu3UlBQQFRUFFu3blUlVT4+Phw+fJjk5GSaNGmCl5cXe/fupbCwkCZNmpQZ V1mGDRvG4sWLSUpKQqFQsGTJEvz8/FT7z507x86dO1EoFKxatYq8vDy6detWYZxP0tPTIzU1ldTU VI4dO8awYcNISEjA0NAQIyMjtRGfx1Xm/ZZm+PDhbNiwgTNnzqBUKtmzZw/t27cnKSnpqY6HEDWd jBgJISr0+MiMvr4+v/zyCwsWLGDChAncuXMHa2trXn/9dbVRi7LY2toSHBzMvHnz+H//7/9ha2vL ihUr6Natm2q/k5MTTk5OaGlp4eLigrm5eYlptCfjKsusWbNQKpX06tWLrKwsWrduTXBwMNra2gC0 bNmSkJAQpkyZQqNGjQgJCcHAwAADA4Ny43xSt27dWLFiBZ07d+batWtcuXKFbt26kZOTQ9OmTdmw YUOZx0PT91tWvx9//DFBQUEkJiZSv359Nm/eTMOGDVVXp1XmeAhR08kNHoWoQYoXX1d2quTjjz/W KAl53v5uXJs3b2b79u3s2bPnGUYlhKgKxVNpsvhaCFHtXsSkCF7cuIQQLy9JjIQQFSq+JL14Tc+L 8ndxXEII8azIVJoQNcjTTqUJIUR1k6k0IYQQQojnTBIjIYQQQogikhgJIYQQQhSRxEgIIYQQoogk RkIIIYQQRSQxEkIIIYQoIomREEIIIUQReVaaEEIlLOYCH50M48+7KRqVb2Rqy7z2r9PXpWUVRyaE EM+HJEZCCJW5UTtJuHdH4/J/3k3h/ajgf1RiZGxszKxZs5g9e7bqWWya/m1sbExWVlZ1v4VnIj09 nTNnzhAbG6tReRcXFzw8PLCwsHgu7QlRVeTO10LUIBXd+drsy6CnavdO0JdPHZN48aSnpxMcHIy3 tzctW7ZES0ur3PJKpZJLly5x+PBhhg4dWiKZedbtiZpJ7nwthHgh1dXV47dxS7kU+EmV9lNYWEhi YmKV9lGa4uewPe+6L5IzZ87g7e1Nq1at1JIYhUJBcHAwCoVCrbyWlhatWrXC29ubM2fOaNxeWSpq T4iqJImREKJSvnv9HRqb26GvU7vMMp9//jn29va4uLgQGBj4VAnDu+++y48//qhR2cjISF555RWs ra1ZtGgRffv2BWDt2rUMHjy4Uv3Onj1b7fW4ceM0jv/Jui+Kxz+PwsLCCsvHxsbSsmXJ6dHCwkKS kpLKbKNly5alTpWV1V5FympPiKokiZEQQmPzOg+if0N3chUPGRyyosxyGzduZOHChZw/f56goCAG DRpU6b7u3NF8rdPOnTvx8vLiypUrjBw5kvfff7/S/RV7MgmaOHGixvG/qCNGj38etWpp9t++JiM7 lanzrNsToqpIYiSEKEFbqxbbfN/FXL+ealvfBq2Z33kwSpQE/Pg5l9MSSq3bvXt3bt68yUcffcSq VatYs2aNauRnzJgxvPvuu7i5udG7d2/u3LnD0KFDcXJyonnz5kybNg2FQsHnn3/OwYMHWbp0KfPm zSs31jlz5rBjxw5++eUX/vWvfxEZGcmSJUtKlCsoKGDJkiU0a9aMhg0b8vbbb3Pv3r0S5Z4c9Xk8 /u+//55WrVrh5ORE9+7diYqKKrcuQG5uLnPmzMHNzY0GDRowbtw4MjIyANi8eTP+/v6MHTuW1157 jTZt2rBr1y5V3UuXLtGnTx8cHR3p0KED+/fvL/M4bNq0iTZt2uDo6Ejfvn25fPkyUPLz2LVrF1ZW VmW2I0RNJ4mREKKEvg1aM6RxO372n0EdHV3czGzZ6jsJLbSYfXg7P9+4UGbdgwcPYmdnx//+9z/m zp1bYv+vv/5KWFgYa9euZcWKFZibmxMTE0NERASRkZHs2rWLd999l+7duzNjxgw+/PDDcmP96KOP 8PX1ZcKECWpJxZOWL1/O7t272bt3LxcvXiQ3N5fp06eXKFfWqE92djaTJ08mODiYmzdv4u/vz9Sp UyusO3v2bE6ePElERAQXL16ksLCQwMBAteMxZswYTp48ycyZM5k2bRqFhYVkZmbi6+uLr68vcXFx LFu2jHHjxnH9+vUSfezcuZNFixaxbt06YmNj6d+/P4MGDSIzM7PE59GuXTs2b95c5nF6XEZGBmlp aeWWSUtLUyV6QvwTyOX6QogSwq6f4/vfoxjerBO/j1uGTT1j9LR12XQpgk9P7v5bbfv4+NCoUSPg 0aXxe/fu5YcffqBbt26cOnVK46meyvrmm29YvHgxjo6OACxcuJCWLVvy3//+lzp16qjKlbVOqHbt 2ujq6rJx40aGDBlCYGAg48ePVyvzZF2lUklwcDDfffcdtra2ACxduhRXV1eSk5MBcHNzo1OnTgD0 7NmTf//732RlZfHLL79gaWmp6qNz58707duX7777jg8++ECtnx07djBmzBjatm0LQFBQEJs3b2b/ /v34+/urlbW1tVXFUpG8vDxCQ0Px9fXF3t6+xP7ExERCQ0M1nmr85ptvNJoiNTMzY9SoURq1KcSz JomREKJUY35ei4uJFR3sXwHgeFI0E/Zu+Nvt2tnZqX4unjpbtmwZ//73v+nSpQurVq1SJS/PilKp JCkpiaCgICZNmqTarqurS2JiIg0bNlRtK74n0ZPq1KlDWFgYy5YtY8CAARgYGDBt2jSCgoLKrJuX l0dOTg7169dXbTM3N8fAwECVGJmbm6v2FSeFhYWFJCQkEB0drXYsFAoFAwcOLBFbenp6iWPm5OT0 t6/qs7e3p0ePHuzatQt/f3+MjIxU+27fvs1PP/1Ez549S02aSiPJjngZyFSaEKJUisICBgQvIy4r jbisNAYEL0NRWPC32318Qe1vv/3G6NGjOXXqFJcvX0ZfX585c+aUKPcs+rS2tua7774jISGBhIQE YmNjiYqKwsXFRa1sWSNGmZmZPHjwgG3bthEfH8/nn3/O3LlzuXLlSpl19fX1MTMz4+bNm6ptaWlp 3L9/H0tLy3Jjtra2xsPDQxVvQkICZ86c4T//+U+Jsvb29sTHx6tti4uLeyZriRo1aoSHhwchISGq NVlZWVmEhITg4eGhGv0T4p9CEiMhRJky8+7TcM1UGq6ZSmbe/Wfe/vr165k+fTp//fUXFhYW6Orq YmZmBoCenh5xcXFkZmY+k76GDRvG4sWLSUpKQqFQsGTJEvz8/EqUK2uN0b179xg0aBBHjhxBR0cH KysrtLW1MTQ0LLduQEAAixcvJiUlhZycHGbOnEm7du1wcnIqN95+/frx559/8u2331JQUEB0dDQ9 evRg9+6SU5kBAQFs3LiRc+fOoVAoWL16NSkpKfj4+JQom5ycTFhYWLl9P6ldu3a4uLgQGhoKwK5d u2jQoAHt2rWrVDtCvAwkMRJCqNjVM610HScj84oLlWHRokVoaWnRtGlT1XTWggULABg8eDDbt29n 2rRpT93+42bNmoWnpye9evXC2dmZ06dPExwcjLa2tlq5skaMHB0dWbVqFZMnT8bW1pbAwEDWrFmD g4NDuXXnz5/Pq6++ire3N02aNKGgoIDvv/++wngtLS0JCQlhy5YtODs78/rrrxMYGMjIkSNLlO3X rx9z584lMDAQR0dHdu3aRWhoaKmjUqdPn2bs2LEV9v/kQxF69uyJiYkJAKampvTs2bPCOprue5Z1 hPi75JEgQtQgFT0SJCzmAotP7CI6M1Wj9hqZ2jK/w+v0cf7nPCutrDVGVV33RbJ3716cnZ1p1aqV 2vb8/HxOnjzJa6+9hq6ubol6Fy9eJC4ujt69e2vUXkXKak/UTM/rkSCSGAlRg1SUGAkB8qw08WKS xEgI8cy9jInR1atXGTFiRJn7P/jgAwYMGPDM+jM2NmbWrFnMnj1bNQKk6d/GxsZkZWU9s1iqU3p6 OmfOnNH4kRwuLi54eHiUmcQ86/ZEzSOJkRDimXsZEyMhhIDnlxjJ4mshhBBCiCKSGAkhhBBCFJE7 XwtRw+Xn55ORkVHqA1WFEKIqGBoaYm5uXurVjdVNEiMharD8/Hzi4uKoX78+bm5u1R2OEKKGSEtL Iy4uDmdn5xcuOZLESIgaLCMjg/r161f4eAohhHiWiv/PycjIwMbGppqjUSdrjISowe7duydJkRCi WlhaWr6QU/iSGAkhhBBCFJHESAghhBCiiCRGQgghhBBFJDESQgghhCgiiZEQQgghRBFJjIQQQggh ikhiJIR47nbs2MGkSZOqOwwhhChBEiMhhBBCiCJy52shhMauXbvGsmXLiI6OxsbGhkmTJtGpUycA /vjjDz777DNiY2PJzc2lbdu2LFq0CCMjI+bMmYOBgQFHjx7FwcGBXr16VfM7EUKI0smIkRBCI9nZ 2QQFBdGjRw8OHjzI9OnTmTt3LvHx8SiVSmbMmEHXrl3Zt28fP/30E7dv3+bHH39U1T927Bhr1qxh 0aJF1fguhBCifJIYCSE0EhERgZmZGW+88Qba2tq0bduWrl27EhYWBsCXX36Jv78/Dx8+JCMjAxMT EzIyMlT1O3fujIuLC3Z2dtX1FoQQokIylSaE0MitW7e4efMmXbt2VW0rKCjA29sbLS0tfv/9d6ZN m0Z2djYNGzYkMzMTpVKpKmtlZVUNUQshROVIYiSE0IiFhQXNmjVjw4YNqm23b9+mTp06JCUl8cEH H/DVV1/Rpk0bAObMmaNWX0v7ejKhAAAD9ElEQVRL67nGK4QQT0Om0oQQGvHy8iI2NpaffvqJwsJC bt68yVtvvUV4eDg5OTnAo+QJ4MyZMxw5coT8/PzqDFkIISpNRoyEEBoxMzPjiy++YOXKlaxYsQID AwOGDBnCwIEDARg5ciRjx45FV1cXBwcHBg4cSHR0dDVHLYQQlaOlfHwRgBDiHy0iIgIAd3d3AKKj o2nbtm11hiSEqMHOnj3LK6+8olHZ8+fPA49Gr6uSTKUJIYQQQhSRxEgIIYQQoogkRkIIIYQQRSQx EkIIIYQoIomREEIIIUQRSYyEEEIIIYpIYiREDWZoaEja/2/nDm0khqEoinqBYVBIYPpvZnoIjaaG WXLZ8PVKOaeCB6++Jd/36hnAA933PbZtWz3jizCCB9v3fVzXJY6AP3Xf97iua+z7vnrKFz9fw4PN Ocd5nuP9fo/rulbPAR5i27ZxnueYc66e8kUYwcPNOcdxHOM4jtVTAJbzlAYAEGEEABBhBAAQYQQA EGEEABBhBAAQYQQAEP8YwQO9Xq/VEwD+JRcjAID8fD6fz+oRAAD/gYsRAECEEQBAhBEAQIQRAECE EQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQR AECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEA QIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBA hBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECE EQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQR AECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEA QIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBA hBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECE EQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQR AECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEAQIQRAECEEQBAhBEA QIQRAECEEQBAfgHNDyrVACnldQAAAABJRU5ErkJggg== --=_01c4c3aaf12881b41ee82fe385f9161b-- From xen-devel-bounces@lists.xenproject.org Tue Jan 20 12:10:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 12:10:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208811.1520944 (Exim 4.92) (envelope-from ) id 1viAYU-0008CB-AX; Tue, 20 Jan 2026 12:09:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208811.1520944; Tue, 20 Jan 2026 12:09:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viAYU-0008C4-7R; Tue, 20 Jan 2026 12:09:54 +0000 Received: by outflank-mailman (input) for mailman id 1208811; Tue, 20 Jan 2026 12:09: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 1viAYT-0008Bt-DR for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 12:09:53 +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 eb7fd377-f5f8-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 13:09:50 +0100 (CET) Received: from MW4PR03CA0088.namprd03.prod.outlook.com (2603:10b6:303:b6::33) by DM6PR12MB4139.namprd12.prod.outlook.com (2603:10b6:5:214::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 12:09:46 +0000 Received: from CO1PEPF000044F8.namprd21.prod.outlook.com (2603:10b6:303:b6:cafe::8) by MW4PR03CA0088.outlook.office365.com (2603:10b6:303:b6::33) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.8 via Frontend Transport; Tue, 20 Jan 2026 12:09:44 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CO1PEPF000044F8.mail.protection.outlook.com (10.167.241.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.0 via Frontend Transport; Tue, 20 Jan 2026 12:09: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; Tue, 20 Jan 2026 06:09:42 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: eb7fd377-f5f8-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nMTXDhT5tGr2RQ2HfTC2nKgxz7XvSPp8tYWSG1QVniyy/5ZdFY0xNuE4Qc52SLjW40yqnRzT+wsYNCQTmWr5S+J0NjPIZ60rGl6lYMJigs/TfwcVYccUjSu2rbALqKbL2zCcsSUpKNf3+jvfug4GU8GKBcCI1aF+tyz/tbHCQ7fDTSNnkHt0fGqC14M1dw4pK5iGmJPAlfNtb3MqjKqrf0e8MOFQOPHAhVBmFnboZsldnJdZoCdxFLDx5w61NeIQ6fveDtSe8UeGyzOsD2W6Xe0glrOlKDUDVS5ZAXMWIEpbb/qGf/BnaQXAOloXvzGcAC/uTTnQNDE1h+ryEnCGbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sS2HGwOpJ9ILdUn0TXiUmZMJgrnPhsnR1OONZcpWWOs=; b=EJ273e24Ln80nGLK0ophS19qLm6CrQ3FRnXlgsYo11cqb1ASpm9wx5Zgn2dYJljuLqUUrjNnezHyy+uHn7n3eOKuED64TgRKY3g94SC/4A0cB4Pi8SbrobDsyFEvU6lDIlLA08ZJx7IAvV0HQJGggbkuc8lS9SKtO3pj5NLjlrI2wv0cfPlxAhmrt6vaqxYite2bLka+KGpEh8L2SorqdKgB6/hR6QI1ILejvI7dPl7/n5EOZmJn4Hi1pX4JyHudTp0xQDrImZiYUz2LREfm3oLMKRuS74WHqLDu2x9XTtjh9SxBW+Zs7ZYm+SU6ihGCsu3UpLp5y0c6AebWzMmlpA== 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=sS2HGwOpJ9ILdUn0TXiUmZMJgrnPhsnR1OONZcpWWOs=; b=Lkhj9sjdwDXLBlE5swzTThPyLMD0VsBOiGR4EJYeMMUiJcc4XDHiZwa9k/nbPGPbQ+FIsrCVOKbrYMp9NRm3toH2ozPrLRaCDZgWv7G1MIaPJnn8ZrWiYFOpRsVjWzA6U8lzGlkZ4pTX/Yy4wXudjEjiyMDiGNezDk4mgo+YRx8= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 20 Jan 2026 13:09:40 +0100 Message-ID: CC: , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Xen-devel Subject: Re: [PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list. From: Alejandro Vallejo To: Alejandro Vallejo , Nicola Vetrini X-Mailer: aerc 0.20.1 References: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> <20260120093852.2380-5-alejandro.garciavallejo@amd.com> <1d374226e3f91ab3bbc05c3354c8f8fe@bugseng.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: CO1PEPF000044F8:EE_|DM6PR12MB4139:EE_ X-MS-Office365-Filtering-Correlation-Id: 6b60ebb9-0823-456c-7546-08de581ccce0 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?ODRYMFEvUzlWa3U3cDBHdml3bFVkaWlGaXhqSXdJN0NwQmVlSFMyN2pOY3hy?= =?utf-8?B?UkVhODA1dEVWN1VnZWRNc0J5RnU4SWMxUUJuUXpLeVJSczhraUUrek5CYnNz?= =?utf-8?B?TlB4Ymk1UVV0YlF1VnJ6dENlenRPbnpWVXNYWjMvTWt3OU1NR3FOVk9mSlRt?= =?utf-8?B?Ly9EdmJTSGFRTDBPS3lNS0JpV1J0YmYvL0JFUHg5S1E3K0J4U2ZFK1lRNmpS?= =?utf-8?B?VFFLeVp0N1RoU1lubEZZclpIWUdrMUYzK2VYVGRDdTVGVE9ka293RUxWcVpJ?= =?utf-8?B?b0NtdndCTVNESUhWQ3owVlZ2cHFEYzNSMGlhQTJiWnRIVXNaaXl1WlN1U3R5?= =?utf-8?B?R3RNSkFxcHF1SkRGZnZ2dG5mYWxON01JUE1xSXZhWjdQMmtsUENaWU11V0xM?= =?utf-8?B?TVFMRlVNdlp6RURxRFhRRWJLOXZMRHAvME5RUExqSk5Qd0tGeFN2bzNKQ2pJ?= =?utf-8?B?Q1JCZDZmcVVNTWJrbDdxNUhWQWF4ajhPRjFwRUVuaXNiaStva2JHa0JkRXFT?= =?utf-8?B?ckwyb21iWGkrRnRsVFl4ckQrejBubytwcnVGZGF3OGZLMTJrVzhiVzdZUlkv?= =?utf-8?B?TTQrWkRDS044UmdGc1oyOVRERldIZGFOSzRiajhjd0IyekFZNHpxaFFSakpj?= =?utf-8?B?djVZVzN5TmJNZitobHA5UTJMVHRyVHU2V2Q2ZDBCK3NHTVljc1NBQldjYTg4?= =?utf-8?B?WDQvYWZvT3VVK01hVHRpa2p6TE9SdVRzUHVYaUdWSXV5RFprVkpUSEFpVVo1?= =?utf-8?B?TjAwVFZRVFBYalNmYWtuWll4UGFSSHoxQ25vd0g2eW5WZlRvOU5ZTU5yUm9Q?= =?utf-8?B?NHBiU0pvRDN0UDNSNlpzYzVDdDYzRTRqeGF6ZmdqTnlmQzI1WmxWUDdPRk80?= =?utf-8?B?cjc5dGw4SlJVOFliWWRmeWJIalhFYmFqd3FRV2RTRTB3SG0xVjNoMlF1YVJn?= =?utf-8?B?QXRqS0VmZEJKODhLaDE0SDBBbDFtMFdFaldyMUZpczhkeVI3Q0F2UzhXc2FK?= =?utf-8?B?OVpxV3FQN1d4NHpJY0I2dXJsRVdJRXBvMnBDak9ZL2pueWg2SjkwckRCcGtE?= =?utf-8?B?eXBlWGtIUWovRUNCaTJpd0FEMFkzUS9JMVppMDFUS3ZGbmZyMkx6emRTbjM5?= =?utf-8?B?WGRQU0JwWWFBem0yRGVnTkE4VHBjYzlscDMvcDVXN0lkMCsvZTNiWnJDN01a?= =?utf-8?B?SWRMcXZhaklNd25oUGJWWUd6NkZqblF2Z3EvcDdvZGlGMkFVYkxIbThRVTMv?= =?utf-8?B?aWtRMTBPODlnUitWNWFNY21nTVRHWm53cDBtTW53S280cVpXb08xL01PalQx?= =?utf-8?B?SmlxalNKNGJKKzQ0T1A2cnVET2hTQlZxQlg1cm5UTllYbklyVnJyaUUxc1p3?= =?utf-8?B?YjBhV2VQM1ozbkxJK3hpTTR4cmgyZ1JoVlR4Y0JLaUVSbHlCODdkaGNJazRT?= =?utf-8?B?d1NlTFYrRml0L1Z5UWVhRTBsODdhaTQzOGF3Y1VKSko4SUx5RTJhNDlLMkF6?= =?utf-8?B?WUNnMVo4Vm53UmpHOVQrVXdQV3JLQlNBRm9xTnlRS2drSGhwMW9CT1FadUFl?= =?utf-8?B?dzJUK3FMZmZCNExyczgyNXA2SHg0VXZoOEJPY1h5TTFxME1JV0JXSFUrZkhV?= =?utf-8?B?Vjc0Y2R1MEkvRE41WWhRRXBVaUxqVjVKZW80aTJ5OEpubTBza2Z3dHdMbGR2?= =?utf-8?B?VEFQRXk1U2RSRkZPa3lpeUsxbUxwZTh5ekRZOVcxbWM5REE4eXhXS25OenF6?= =?utf-8?B?WVI2czJoekpFdjIwakF5cENCMkxGWmhDczMzK0pXMHVMVUcxYWI0UlJFOHI2?= =?utf-8?B?bFYxRXpBYksrSFJVZXdPQXR4V01IV2JLN1VHZW80RVBnVWRsOUpJcjFhbmsx?= =?utf-8?B?aG1xd1hFczFMVEdoWTBTakRxQWhZV0xSZkZabG1EUG45RzZRL1VTdmljYTBM?= =?utf-8?B?OTdyeDlOK0VpandJeEMrWDQ0YllpbUVaamJOa25iYkFCRUdUMEk3TUd2bFFv?= =?utf-8?B?eGhMQzFmUDkxZVJBNUIrdTI5SGpheHA4V1NQUVArSjJ0ZXRYd0x6cUt4Mk51?= =?utf-8?B?QUtJT2h3cU9xZGxtUnJ3dEV6bGp2TTN1Wm5qYmJ3NndjbU1SRloyMnB1UXRr?= =?utf-8?Q?50WKp8ZhCYVD2Wb27kRai4jY5?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;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: 20 Jan 2026 12:09:45.1977 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6b60ebb9-0823-456c-7546-08de581ccce0 X-MS-Exchange-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: CO1PEPF000044F8.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4139 On Tue Jan 20, 2026 at 12:51 PM CET, Alejandro Vallejo wrote: > On Tue Jan 20, 2026 at 12:41 PM CET, Nicola Vetrini wrote: >> On 2026-01-20 12:27, Alejandro Vallejo wrote: >>> On Tue Jan 20, 2026 at 12:21 PM CET, Nicola Vetrini wrote: >>>> On 2026-01-20 10:38, Alejandro Vallejo wrote: >>>>> It's clean. >>>>>=20 >>>>> Signed-off-by: Alejandro Vallejo >>>>> --- >>>>> docs/misra/exclude-list.json | 4 ---- >>>>> 1 file changed, 4 deletions(-) >>>>>=20 >>>>=20 >>>> Hi. Do you have a link to a pipeline? >>>=20 >>> In the cover letter. I only run it on allcode. >>>=20 >> >> I see. I can spot these additional violations from earlycpio.c. It does= =20 >> not result in a failure, but only because x86_64-allcode has also other= =20 >> non-clean guidelines and is thus allowed to fail. Ideally in some=20 >> copious free time I'd send a patch to create a subset of clean=20 >> guidelines for the *-allcode analysis that is failing, so that the=20 >> "allow_fail: true" can be removed. >> >> https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/= xen-project/people/agvallejo/xen/ECLAIR_normal/ucode-disable_v4/X86_64/1277= 1570090/PROJECT.ecd;/by_main_file/xen/lib/earlycpio.c.html > > The web interface doesn't allow to search?! Sigh... thanks for the pointe= r. It's your usual mess of miscasting, enum-as-int, etc. Would you rather keep the exclusion and deal with it later or let it pile u= p? I just don't have the time to go into it myself. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Tue Jan 20 12:12:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 12:12:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208823.1520955 (Exim 4.92) (envelope-from ) id 1viAb2-0001IZ-PY; Tue, 20 Jan 2026 12:12:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208823.1520955; Tue, 20 Jan 2026 12:12:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viAb2-0001IS-N4; Tue, 20 Jan 2026 12:12:32 +0000 Received: by outflank-mailman (input) for mailman id 1208823; Tue, 20 Jan 2026 12:12: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 1viAb1-0001IM-VK for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 12:12:32 +0000 Received: from mail14.wdc04.mandrillapp.com (mail14.wdc04.mandrillapp.com [205.201.139.14]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 49f25c09-f5f9-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 13:12:29 +0100 (CET) Received: from pmta16.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail14.wdc04.mandrillapp.com (Mailchimp) with ESMTP id 4dwR636n25z8XS0yM for ; Tue, 20 Jan 2026 12:12:27 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id ee886b8fb1314c1c84d06adf7cbdb819; Tue, 20 Jan 2026 12:12: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: 49f25c09-f5f9-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1768911147; x=1769181147; bh=wKT9Fl0NmSHSWf8iFV43O6AxB+It7qf1xSBZsR0J08Q=; 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=bcEp8tDZqHKGBdbsU3Nk3+LyRG3VUypk6MK3Cz8TpCc+6go3/pP8o4gLQU8ijO82G 1DndcBCk6HvxT2ekV9N8thMWpcGERpTwKhgudI6O/e/DhoKXaBQtJ91Nzr0TLSJ4Ca T7/lNgx3iPXuQJVqQ3A96fxhYlyAbX0YdNVNdQudaF4Ow6TrIChy4gmXT1E+tJ9YS/ yeoSLR/obO3mpc00hAvcyZ91wc1r6MW76mh2fWIdFU0+r23kK6O1iS5m1dLhqFmwVK 7xsBa8zkQBXnH5DQ4kfVcHbMx3KfrOo1wewo985/4oMuW5f9QPVPFUcNc1EkWHTgJ9 uB1x2ItoKEvuA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1768911147; x=1769171647; i=ngoc-tu.dinh@vates.tech; bh=wKT9Fl0NmSHSWf8iFV43O6AxB+It7qf1xSBZsR0J08Q=; 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=KYft1wh306YONTkIOBMbJuUOGHCPl5cY01ZvX1AERtqcaR2M2zoKvlgS+8P9ADnIg q0ka1asESwLZ39U/Q1iqSCYZgcvGRpsXbe7iHQossq5VBYjdDj8k6JxezSydqRBkwH WTkzWzfCcZUJnwYBLCFmSfph18I5o1cfs+NtnYu+ecWJ8xR6U36CVst/wK0dZNs0bd UE7wSONRgxEKQy3gnLvH9Wjo4x/nyIfza11k6iZZTnkHEQLuuDE+CrEML2bTk0rZDh o0Xd4RokN6VW33PEHRDkHO4kCkXGi6vREy4ymud07lcoprmfiStGMasSEBhPT+ABIC lHW+MF+ViKPyA== From: "Tu Dinh" Subject: =?utf-8?Q?Re:=20[PATCH=20v2]=20xen:=20Expose=20time=5Foffset=20in=20struct=20arch=5Fshared=5Finfo?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1768911146170 Message-Id: To: "Jan Beulich" Cc: "Anthony PERARD" , "Andrew Cooper" , "Michal Orzel" , "Julien Grall" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" , "Bertrand Marquis" , "Volodymyr Babchuk" , xen-devel@lists.xenproject.org References: <20260120095657.237-1-ngoc-tu.dinh@vates.tech> <3213454a-38cd-4e5d-8a30-853e37f70c18@suse.com> In-Reply-To: <3213454a-38cd-4e5d-8a30-853e37f70c18@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.ee886b8fb1314c1c84d06adf7cbdb819?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260120:md Date: Tue, 20 Jan 2026 12:12:27 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 20/01/2026 11:35, Jan Beulich wrote: > On 20.01.2026 10:57, Tu Dinh wrote: >> time_offset is currently always added to wc_sec. This means that without >> the actual value of time_offset, guests have no way of knowing what's >> the actual host clock. Once the guest clock drifts beyond 1 second, >> updates to the guest RTC would themselves change time_offset and make it >> impossible to resync guest time to host time. > > Despite my earlier comments this part of the description looks unchanged. > I still don't see why host time (or in fact about any host property) should > be exposed to guests. > I've answered this question in a followup reply from November, which I'll reproduce here: vRTC drift can happen for other reasons. For example, Windows can write to the RTC at any time; if a guest clock drift has already happened (e.g. after a migration), an unfortunately-timed RTC write will make it permanent. Windows time providers don't have the ability to control when Windows writes to RTC either. Thus the "real" host clock time is needed to help the VM adjust to the correct time. IOW, it's the distinction between "keeping track of already correct time" versus "correcting wrong time by adjusting the offset"; the latter is what I'm looking for. (Follow up: Here's my attempt to rewrite the description to account for the above) Xen currently does not expose the host's wall clock time in shared_info. This means while shared_info can be used as an alternative to the emulated RTC, it can't be used to keep the virtual wall clock in sync. Expose the time_offset value in struct shared_info in order to allow guests to synchronize their own wall clock to that of the host. This is needed because on Windows guests, the PV drivers don't control the timing of RTC updates, as this is done by the kernel itself periodically. If the guest's internal clock deviates from the RTC (e.g. after resuming from suspend), a RTC write would cause time_offset to deviate from the supposed value (timezone offset) and thus cause the RTC to become incorrect. Provide a new feature bit XENFEAT_shared_info_time_offset for this functionality. >> Since there's no way to add more fields to struct shared_info, the >> addition has to be done through struct arch_shared_info instead. Add two >> fields in arch_shared_info representing time_offset's low and high >> 32-bit halves. > > Again, despite my earlier question, reasoning of why two halves rather than > a (signed) 64-bit value isn't supplied here. > This was also in my last email: Both are just for easy consumption of the time offset on 32-bit guests. Unsigned is particularly because these are only parts of an int64_t (and therefore have no signedness themselves) and I prefer to let the conversion happen after reading the two fields. (Follow up: Also, the alignment of int64_t differs between GCC and MSVC compilers. Using int64_t here would change the alignment of struct arch_shared_info) >> Provide a new feature bit XENFEAT_shared_info_time_offset for this >> functionality. >> >> Signed-off-by: Tu Dinh >> --- >> v2: Remove unnecessary casts. > > Did you really? What about ... > >> --- a/xen/common/time.c >> +++ b/xen/common/time.c >> @@ -118,6 +118,11 @@ void update_domain_wallclock_time(struct domain *d) >> shared_info(d, wc_sec_hi) = sec >> 32; >> #endif >> >> + shared_info(d, arch.time_offset) = >> + (uint32_t)d->time_offset.seconds; >> + shared_info(d, arch.time_offset_hi) = >> + (uint32_t)(d->time_offset.seconds >> 32); > > ... both of these? > I thought these downcasts should be explicit. I can remove these as well. NB: A blank line in reference.size was lost when preparing the patch, I'll fix it in the resend > Jan -- Ngoc Tu Dinh | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Jan 20 12:27:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 12:27:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208833.1520964 (Exim 4.92) (envelope-from ) id 1viApm-00034m-2e; Tue, 20 Jan 2026 12:27:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208833.1520964; Tue, 20 Jan 2026 12: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 1viApl-00034f-Vj; Tue, 20 Jan 2026 12:27:45 +0000 Received: by outflank-mailman (input) for mailman id 1208833; Tue, 20 Jan 2026 12:27: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 1viApk-00034Z-40 for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 12:27:44 +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 698df239-f5fb-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 13:27:41 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id D94D66011F; Tue, 20 Jan 2026 12:27:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6533FC19423; Tue, 20 Jan 2026 12:27: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: 698df239-f5fb-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768912059; bh=b7Mbdz/B6k9B79H7XOHyXFan5oK4QyoZB2R8RyLKnA0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qyvATZaSrEe49sh1pTLv223SMZUXupyJ7AEH8b7OsfHEeQacfJO00Zf/WzAHWL9E4 YdtXc3YZVh9NSGcUhAD2bQvcACJ5PrjSRas0X6y7UOImj3QPKnx5QP1rSKYrFh5Mts ukTURbyHiw+A+Kz5Vf26qHNwrORw2S4F45MPwEjPavVEHNIxp5dnd7uk7o0/DPXX7+ g73KWaKHxGDsX8vefv3wZzROajBumN3ybV4NMn2T3AnSa9jpAw36eCJjIuqT/JPkF0 Dt5GgYa0z7KnbSSkgeEZDb889qUkR918KJJZNX1gKKxnazEduQBZ+Q4614JxO2KCTn WhoIppH/1oyUw== Date: Tue, 20 Jan 2026 12:27:33 +0000 From: Will Deacon To: Barry Song <21cnbao@gmail.com> Cc: catalin.marinas@arm.com, m.szyprowski@samsung.com, robin.murphy@arm.com, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Barry Song , Leon Romanovsky , Ada Couprie Diaz , Ard Biesheuvel , Marc Zyngier , Anshuman Khandual , Ryan Roberts , Suren Baghdasaryan , Tangquan Zheng Subject: Re: [PATCH v2 1/8] arm64: Provide dcache_by_myline_op_nosync helper Message-ID: References: <20251226225254.46197-1-21cnbao@gmail.com> <20251226225254.46197-2-21cnbao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251226225254.46197-2-21cnbao@gmail.com> On Sat, Dec 27, 2025 at 11:52:41AM +1300, Barry Song wrote: > From: Barry Song > > dcache_by_myline_op ensures completion of the data cache operations for a > region, while dcache_by_myline_op_nosync only issues them without waiting. > This enables deferred synchronization so completion for multiple regions > can be handled together later. > > Cc: Leon Romanovsky > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Marek Szyprowski > Cc: Robin Murphy > Cc: Ada Couprie Diaz > Cc: Ard Biesheuvel > Cc: Marc Zyngier > Cc: Anshuman Khandual > Cc: Ryan Roberts > Cc: Suren Baghdasaryan > Cc: Tangquan Zheng > Signed-off-by: Barry Song > --- > arch/arm64/include/asm/assembler.h | 24 +++++++++++++++++++----- > arch/arm64/kernel/relocate_kernel.S | 3 ++- > 2 files changed, 21 insertions(+), 6 deletions(-) > > diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h > index f0ca7196f6fa..b408ed61866f 100644 > --- a/arch/arm64/include/asm/assembler.h > +++ b/arch/arm64/include/asm/assembler.h > @@ -371,14 +371,13 @@ alternative_endif > * [start, end) with dcache line size explicitly provided. > * > * op: operation passed to dc instruction > - * domain: domain used in dsb instruction > * start: starting virtual address of the region > * end: end virtual address of the region > * linesz: dcache line size > * fixup: optional label to branch to on user fault > * Corrupts: start, end, tmp > */ > - .macro dcache_by_myline_op op, domain, start, end, linesz, tmp, fixup > + .macro raw_dcache_by_myline_op op, start, end, linesz, tmp, fixup > sub \tmp, \linesz, #1 > bic \start, \start, \tmp > .Ldcache_op\@: > @@ -402,14 +401,13 @@ alternative_endif > add \start, \start, \linesz > cmp \start, \end > b.lo .Ldcache_op\@ > - dsb \domain Naming nit, but I'd prefer this to be dcache_by_myline_op_nosync() for consistency with the other macros that you're adding. The 'raw' prefix is used by raw_dcache_line_size() to indicate that we're getting the value from the underlying hardware register. > > _cond_uaccess_extable .Ldcache_op\@, \fixup > .endm > > /* > * Macro to perform a data cache maintenance for the interval > - * [start, end) > + * [start, end) and wait for completion > * > * op: operation passed to dc instruction > * domain: domain used in dsb instruction > @@ -420,7 +418,23 @@ alternative_endif > */ > .macro dcache_by_line_op op, domain, start, end, tmp1, tmp2, fixup > dcache_line_size \tmp1, \tmp2 > - dcache_by_myline_op \op, \domain, \start, \end, \tmp1, \tmp2, \fixup > + raw_dcache_by_myline_op \op, \start, \end, \tmp1, \tmp2, \fixup > + dsb \domain > + .endm This could just be dcache_by_line_op_nosync() + dsb. Will From xen-devel-bounces@lists.xenproject.org Tue Jan 20 12:33:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 12:33:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208842.1520975 (Exim 4.92) (envelope-from ) id 1viAvg-0004ep-M2; Tue, 20 Jan 2026 12:33:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208842.1520975; Tue, 20 Jan 2026 12:33:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viAvg-0004ei-Ih; Tue, 20 Jan 2026 12:33:52 +0000 Received: by outflank-mailman (input) for mailman id 1208842; Tue, 20 Jan 2026 12:33:50 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viAve-0004eb-N8 for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 12:33: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 43fecaeb-f5fc-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 13:33:48 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 5099943FA3; Tue, 20 Jan 2026 12:33:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 001ABC16AAE; Tue, 20 Jan 2026 12:33: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: 43fecaeb-f5fc-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768912426; bh=Y0bXJFrIMQu42HkX8sO2hSl2uRvMmAIUm4N1kYYXYbg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TxGZV8yxxs7f9OIOe/76/YrYaqjVeBTLmNJdeq9rZnYXtQBKVVFzF9G+vZXhnfGlh vT9CZ7egfF2YJDaVzTZCoXW7WvjE6P9hHlULJeQGsNLJOVQ6GN8ql7pboCjgU4WGCe Vt8ME1f66ylY9a+GCkoyhnoJhXrb39PCRzYGGNaz54bIGYkZiF1bgZi24H9uytWylw 9Pa1LQ5sYMXUi5RHj69gPO6rv2NvuLMgE69i3zkNmc//4jIPBEZz5BqT8SQXYiPd6j m+4BX8yGRcFm1xNp3e9O6KxgephbObAfu5q0mTQt6b0ny660NNsJKm//uUu92158VD Rk2ttoJ8XgDvA== Date: Tue, 20 Jan 2026 12:33:39 +0000 From: Will Deacon To: Barry Song <21cnbao@gmail.com> Cc: catalin.marinas@arm.com, m.szyprowski@samsung.com, robin.murphy@arm.com, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Barry Song , Leon Romanovsky , Ada Couprie Diaz , Ard Biesheuvel , Marc Zyngier , Anshuman Khandual , Ryan Roberts , Suren Baghdasaryan , Tangquan Zheng Subject: Re: [PATCH v2 3/8] arm64: Provide dcache_inval_poc_nosync helper Message-ID: References: <20251226225254.46197-1-21cnbao@gmail.com> <20251226225254.46197-4-21cnbao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251226225254.46197-4-21cnbao@gmail.com> On Sat, Dec 27, 2025 at 11:52:43AM +1300, Barry Song wrote: > From: Barry Song > > dcache_inval_poc_nosync does not wait for the data cache invalidation to > complete. Later, we defer the synchronization so we can wait for all SG > entries together. > > Cc: Leon Romanovsky > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Marek Szyprowski > Cc: Robin Murphy > Cc: Ada Couprie Diaz > Cc: Ard Biesheuvel > Cc: Marc Zyngier > Cc: Anshuman Khandual > Cc: Ryan Roberts > Cc: Suren Baghdasaryan > Cc: Tangquan Zheng > Signed-off-by: Barry Song > --- > arch/arm64/include/asm/cacheflush.h | 1 + > arch/arm64/mm/cache.S | 42 +++++++++++++++++++++-------- > 2 files changed, 32 insertions(+), 11 deletions(-) > > diff --git a/arch/arm64/include/asm/cacheflush.h b/arch/arm64/include/asm/cacheflush.h > index 9b6d0a62cf3d..382b4ac3734d 100644 > --- a/arch/arm64/include/asm/cacheflush.h > +++ b/arch/arm64/include/asm/cacheflush.h > @@ -74,6 +74,7 @@ extern void icache_inval_pou(unsigned long start, unsigned long end); > extern void dcache_clean_inval_poc(unsigned long start, unsigned long end); > extern void dcache_inval_poc(unsigned long start, unsigned long end); > extern void dcache_clean_poc(unsigned long start, unsigned long end); > +extern void dcache_inval_poc_nosync(unsigned long start, unsigned long end); > extern void dcache_clean_poc_nosync(unsigned long start, unsigned long end); > extern void dcache_clean_pop(unsigned long start, unsigned long end); > extern void dcache_clean_pou(unsigned long start, unsigned long end); > diff --git a/arch/arm64/mm/cache.S b/arch/arm64/mm/cache.S > index 4a7c7e03785d..99a093d3aecb 100644 > --- a/arch/arm64/mm/cache.S > +++ b/arch/arm64/mm/cache.S > @@ -132,17 +132,7 @@ alternative_else_nop_endif > ret > SYM_FUNC_END(dcache_clean_pou) > > -/* > - * dcache_inval_poc(start, end) > - * > - * Ensure that any D-cache lines for the interval [start, end) > - * are invalidated. Any partial lines at the ends of the interval are > - * also cleaned to PoC to prevent data loss. > - * > - * - start - kernel start address of region > - * - end - kernel end address of region > - */ > -SYM_FUNC_START(__pi_dcache_inval_poc) > +.macro raw_dcache_inval_poc_macro > dcache_line_size x2, x3 > sub x3, x2, #1 > tst x1, x3 // end cache line aligned? > @@ -158,11 +148,41 @@ SYM_FUNC_START(__pi_dcache_inval_poc) > 3: add x0, x0, x2 > cmp x0, x1 > b.lo 2b > +.endm > + > +/* > + * dcache_inval_poc(start, end) > + * > + * Ensure that any D-cache lines for the interval [start, end) > + * are invalidated. Any partial lines at the ends of the interval are > + * also cleaned to PoC to prevent data loss. > + * > + * - start - kernel start address of region > + * - end - kernel end address of region > + */ > +SYM_FUNC_START(__pi_dcache_inval_poc) > + raw_dcache_inval_poc_macro > dsb sy > ret > SYM_FUNC_END(__pi_dcache_inval_poc) > SYM_FUNC_ALIAS(dcache_inval_poc, __pi_dcache_inval_poc) > > +/* > + * dcache_inval_poc_nosync(start, end) > + * > + * Issue the instructions of D-cache lines for the interval [start, end) > + * for invalidation. Not necessarily cleaned to PoC till an explicit dsb > + * sy is issued later > + * > + * - start - kernel start address of region > + * - end - kernel end address of region > + */ > +SYM_FUNC_START(__pi_dcache_inval_poc_nosync) > + raw_dcache_inval_poc_macro > + ret Sorry, similar naming nit to the other patch. Let's have the macro use the 'nosync' suffix instead of the 'raw' prefix. You can chuck some underscores at it if you want to keep the name of this function the same. Will From xen-devel-bounces@lists.xenproject.org Tue Jan 20 12:42:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 12:42:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208851.1520984 (Exim 4.92) (envelope-from ) id 1viB3s-0006Jp-Do; Tue, 20 Jan 2026 12:42:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208851.1520984; Tue, 20 Jan 2026 12:42:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viB3s-0006Ji-Aw; Tue, 20 Jan 2026 12:42:20 +0000 Received: by outflank-mailman (input) for mailman id 1208851; Tue, 20 Jan 2026 12:42:19 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viB3r-0006Jc-Ja for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 12:42:19 +0000 Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [2a00:1450:4864:20::430]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 73e80b21-f5fd-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 13:42:17 +0100 (CET) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-42fed090e5fso3059430f8f.1 for ; Tue, 20 Jan 2026 04:42:17 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43595e0a6fasm1032337f8f.10.2026.01.20.04.42.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jan 2026 04:42:15 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 73e80b21-f5fd-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768912936; x=1769517736; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=ii0uNLoX1b/x7y05Hjvm5oMk9ua2Woof/cAthaXuj7o=; b=Mva6r9dWau2cFAvpo5QhJ/mvGjsu9sNaLKUrpF+CiObudWpm08lzyEgz0ugADiFcED RiBuMxjR3LQT/t+AY05BQ8Aozjnc+mEuM0fs+4X/fyrfvOglEy5br3jX1A8ghvi4qUY7 tldn7Q03uEXfm4HrNIJIkNs5WLSDUm8x2U0K1HtzLsxZQIjYH4xfU4bdaoHH4r+Mhk87 gAPdf84387MsNrdW3SJPYuuBh2pD/sozo4ga6OEjlM5RunoQgOCLlZ1doN7qecJMIx9+ MP0Dy+S6TpsSJA1puHCpUhNZBcTTPG6XdU5KFLiwf3gP8mPGU2eJtWtOVu9PicduZCKT lD3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768912936; x=1769517736; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ii0uNLoX1b/x7y05Hjvm5oMk9ua2Woof/cAthaXuj7o=; b=gD+DS9Y43cbT8B6te4XjEoJDbkwTXy7AYMJI+dh6Fg6DKTw/YQq+VDCSAz4YgAOXrn 33YUgt/oNhK13Gisw7Q2z31j0g2l+8v+JE1LybxkwdTWnHRRhr0Tt6J9D8NwqSDE948M ACMBZSZXZL+VWK753Q8f6Cn3FZrr/xC6bYoLMt//fwLaWXEEtDSqij4PwjYrQXpGyeMr 0NvFzb5fmtutLeOLb6sXWnOHkMintdyJJrabgcSL2XgM+UulJNkjsFYeye4QUyT++/nR nCInyQFGA8aEZ4H2mLIEz+FQeLBpSbVxXV+SF5L+QiJq4nU7s6g2TeqV4L0yUnerlEKu zGzg== X-Forwarded-Encrypted: i=1; AJvYcCVHgGGOuvAKz7hgc2MZQC/oz4frpB0Rl8KK+5eOWKCyPUhnfAs0TQ3NDENpHbXEnj+QWluKBPD+umI=@lists.xenproject.org X-Gm-Message-State: AOJu0YwPTm6H9682Tazp6h99rzRfuSSKE152B71tbKPvSUJL77K4t3vN lwd9vrTT0Kw2lG3CIjZDVU6rR6LZb5Xk9hCKkWMY/WltPLh3KxOkxraekWVkqBuzGw== X-Gm-Gg: AZuq6aJHWDTaaBb2Sje7p5JfblLZq8Xv3NeF+ipYx49ESv2SSHhlhxXZgaujunSfhXM eQCrozv0CAyJ8XMg78sRAYAebTEnxovhGpll+2xFNiUgOf1T4+tV0qtBQ9q4Qqj7/hdoztrcmT8 LOw2mOjLYNcfQdLlFsg8eDmfjSr6S4z6eolhJ10v2Hdm+UZt79SA5YW0w0gIEvBGTwkn3xYACvf 5h8MI4hw20ZILwbfiCLawxjh/x8QXo0O1/8omB5M4vpwDuf1Irigqt9fNl17Y+Zf1oEYxuLBz9x vuzgfjLJkwehO5E0hkSG5xK5f6/7QW9RzEqzMTZuuckLzIF36V1Z/V5Flnpvi1uuhahwWa+FFRz WcnKSmEKvzOHnP+HyyeR2a3GJEa6WrNBrrBWovOLgCg0jdOPxvz6mWhYf0lQCEzCOhIvLU7gOaP yeH+Vw+qacVXhf6Tvcgs7gd4ZRmVPZzjvVhpXVP1tNedm9Fw5IScYHEVJkdG7BztrkBBlv884Bk Ca1G8BH6Vtmhg== X-Received: by 2002:a05:6000:2083:b0:432:8537:8592 with SMTP id ffacd0b85a97d-4356997867cmr18660075f8f.4.1768912936301; Tue, 20 Jan 2026 04:42:16 -0800 (PST) Message-ID: <7a61a16c-93d7-4cc2-bc47-11e236cf83fb@suse.com> Date: Tue, 20 Jan 2026 13:42:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen: Expose time_offset in struct arch_shared_info To: Tu Dinh Cc: Anthony PERARD , Andrew Cooper , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk , xen-devel@lists.xenproject.org References: <20260120095657.237-1-ngoc-tu.dinh@vates.tech> <3213454a-38cd-4e5d-8a30-853e37f70c18@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 20.01.2026 13:12, Tu Dinh wrote: > On 20/01/2026 11:35, Jan Beulich wrote: >> On 20.01.2026 10:57, Tu Dinh wrote: >>> time_offset is currently always added to wc_sec. This means that without >>> the actual value of time_offset, guests have no way of knowing what's >>> the actual host clock. Once the guest clock drifts beyond 1 second, >>> updates to the guest RTC would themselves change time_offset and make it >>> impossible to resync guest time to host time. >> >> Despite my earlier comments this part of the description looks unchanged. >> I still don't see why host time (or in fact about any host property) should >> be exposed to guests. > > I've answered this question in a followup reply from November, which > I'll reproduce here: I did read your reply, yet nothing of it appeared here as additional justification. Plus I fear I don't view any of this a basis to suggest to expose some host property to guests. >>> Since there's no way to add more fields to struct shared_info, the >>> addition has to be done through struct arch_shared_info instead. Add two >>> fields in arch_shared_info representing time_offset's low and high >>> 32-bit halves. >> >> Again, despite my earlier question, reasoning of why two halves rather than >> a (signed) 64-bit value isn't supplied here. > > This was also in my last email: > > Both are just for easy consumption of the time offset on 32-bit guests. I don't buy this. I should probably have replied to this effect when you first wrote it. {,u}int64_t is hardly a hurdle anymore there. Nor would I expect any halfway up-to-date 32-bit guest to manage time as a 32-bit quantity anymore. > Unsigned is particularly because these are only parts of an int64_t (and > therefore have no signedness themselves) and I prefer to let the > conversion happen after reading the two fields. There may be benefits to this, yes, but imo they want to be spelled out, rather than left vague. > (Follow up: Also, the alignment of int64_t differs between GCC and MSVC > compilers. Using int64_t here would change the alignment of struct > arch_shared_info) Does it? For which target and in which way? This would, after all, render other uses of {,u}int64_t in the public headers problematic as well. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 20 13:11:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 13:11:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208870.1520994 (Exim 4.92) (envelope-from ) id 1viBVs-000233-IK; Tue, 20 Jan 2026 13:11:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208870.1520994; Tue, 20 Jan 2026 13: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 1viBVs-00022w-FU; Tue, 20 Jan 2026 13:11:16 +0000 Received: by outflank-mailman (input) for mailman id 1208870; Tue, 20 Jan 2026 13: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 1viBVr-00022q-07 for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 13:11:15 +0000 Received: from mail14.wdc04.mandrillapp.com (mail14.wdc04.mandrillapp.com [205.201.139.14]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7de76de6-f601-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 14:11:12 +0100 (CET) Received: from pmta16.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail14.wdc04.mandrillapp.com (Mailchimp) with ESMTP id 4dwSPq09Jrz8XS27G for ; Tue, 20 Jan 2026 13:11:11 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 4824c57c7d5041c48b98d46479d3b06c; Tue, 20 Jan 2026 13:11: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: 7de76de6-f601-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1768914671; x=1769184671; bh=VxAoZGVlST9OVVrgCzYWr7DYbVd9xEIUsiIJJpE4u9A=; 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=VqKdqIipNzQtTyMU1KEO6mKOhNLCw5wXOgrLyCEXcRgPHD9VVSHMx4KKLWBPCXk1f /5Dym6SajcdzQaEv88ao6uRYb1lgfgxLuqDsLH9FlOkwMLgFIn+Pg33jvNWz6MiGox XR9bUQBxCmfk94ZvFLVEY3MdSYQtlfvSV3fs0t/PxxOkcfHE2m8PUzi/F4oEIxuViE UzkU0rwXMRW42D4HjlgJUOry+o+OgYpD1iS+scwzqvs39Il1Xqq2rk4qQWgrXY2g7b JCVcXb1d0CsYnOLo7MM7WGo0leI0zFlmyGvsI0a15yB+mfDCx8obl37eiq5dVDmZla e+zZQ31ZFHHbg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1768914671; x=1769175171; i=teddy.astie@vates.tech; bh=VxAoZGVlST9OVVrgCzYWr7DYbVd9xEIUsiIJJpE4u9A=; 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=el4SK0duTM5mAenFWxcESjlBnjRMJEfnnqYUID686s4E1JbYkdWCc8r7Bglrz7RqP iImNVSfFvRkhqEst/Hr9ely0EeIQg0Fuzp0hy8faUlgmLui7iepX2nc3vGQXcs3tj1 jZgN/ey0QTj6HrmIloGz2c4mUDma8e5hoHem48R6/aeXH16mXZe8hSV3cdOVcv9BXt 78ZfbIjw9WfnZ0K06/elxQ+69DRoOkO8XoTwsVClVQakd+JsW/cFgyXaVohyoygLXv RKm0kcFymYBVyEcHMq4/PKFRIV5k+pl7/Mx4trzutfHgSpdSeahN1xte4YlCwlzrS4 Zq+l3czkDJRhA== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=202/2]=20x86/svm:=20Intercept=20Bus=20Locks=20for=20HVM=20guests?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1768914669437 Message-Id: <5c554703-f7e6-4625-be07-4fc607b2c4b5@vates.tech> To: "Alejandro Vallejo" , xen-devel@lists.xenproject.org Cc: "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Jason Andryuk" , "Stefano Stabellini" References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> <20260120095353.2778-3-alejandro.garciavallejo@amd.com> In-Reply-To: <20260120095353.2778-3-alejandro.garciavallejo@amd.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.4824c57c7d5041c48b98d46479d3b06c?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260120:md Date: Tue, 20 Jan 2026 13:11:10 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, some questions Le 20/01/2026 =C3=A0 10:56, Alejandro Vallejo a =C3=A9crit=C2=A0: > With the threshold initialised to 1 the guest exits at the first > buslock. Initialising as zero is invalid and causes an immediate exit. > > Signed-off-by: Alejandro Vallejo > --- > xen/arch/x86/hvm/svm/svm.c | 4 ++++ > xen/arch/x86/hvm/svm/vmcb.c | 6 ++++++ > 2 files changed, 10 insertions(+) > > diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c > index 9748df87d8..dbb7f99d5e 100644 > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -3087,6 +3087,10 @@ void asmlinkage svm_vmexit_handler(void) > hvm_descriptor_access_intercept(0, 0, desc, write); > break; > } > + case VMEXIT_BUSLOCK: > + perfc_incr(buslock); > + vmcb->bus_lock_thresh =3D 1; > + break; > > default: > unexpected_exit_type: > diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c > index cbee10d046..7a19b1ab61 100644 > --- a/xen/arch/x86/hvm/svm/vmcb.c > +++ b/xen/arch/x86/hvm/svm/vmcb.c > @@ -66,6 +66,12 @@ static int construct_vmcb(struct vcpu *v) > GENERAL2_INTERCEPT_XSETBV | GENERAL2_INTERCEPT_ICEBP = | > GENERAL2_INTERCEPT_RDPRU; > > + if ( cpu_has_bus_lock_thresh ) > + { > + vmcb->_general3_intercepts =3D GENERAL3_INTERCEPT_BUS_LOCK_THRES= H; > + vmcb->bus_lock_thresh =3D 1; /* trigger immediately */ > + } > + > /* Intercept all debug-register writes. */ > vmcb->_dr_intercepts =3D ~0u; > According to APM, INTERCEPT_BUS_LOCK_THRESH does > Intercept bus lock operations when Bus Lock Threshold Counter is 0 I assume that when set to 0, we intercept all bus locks, so if set to 1, every 2 bus lock (since we first go from 1 to 0, then at 0 we intercept the next one) ? I think we want that to be tunable, as intercepting all bus locks may be too extreme we probably want to intercept every few ones instead. 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 Jan 20 13:12:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 13:12:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208878.1521004 (Exim 4.92) (envelope-from ) id 1viBWt-0002Vg-R5; Tue, 20 Jan 2026 13:12:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208878.1521004; Tue, 20 Jan 2026 13: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 1viBWt-0002VZ-OH; Tue, 20 Jan 2026 13:12:19 +0000 Received: by outflank-mailman (input) for mailman id 1208878; Tue, 20 Jan 2026 13:12:18 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viBWs-0002Ip-Ij for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 13:12:18 +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 a3e0cf2b-f601-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 14:12:16 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB5678.namprd03.prod.outlook.com (2603:10b6:a03:2d4::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Tue, 20 Jan 2026 13:12:12 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Tue, 20 Jan 2026 13:12:12 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a3e0cf2b-f601-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DNO2obZ4s+NF1tgTiqrYQo7qGkHVB1ZdBiIsrKVXmUEHT84OZsRVjafNeu6POUfNy942owf+F/cJVAi4aKsSWFiw0dFqbcouxIGfEseUZUFSB3n/3/qWorUoAKnobTgNpBQG5yaIKPqfpDbadA9BI/0jUFknAvinRVvMkBUDydBIqUT8b9A1fl3hB4cURJN20BE0dCZFDzY1aJ5KttmvvyEEM6XV0MtyGLhuMsF1ML/4j823rfEi3GFVWN2puL7EaH4ziHeO/OAi2TwW7KmwKf2rGRIbjRHym0hXbPleo8TJpFUV/f1O6kxTTUPYg461Fz+WnH5dACzyEwLoiF7qfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DyCajYi4UBGlA1x2vDE96X+W3jTH9wnPpNGsALWMpe0=; b=oC5JQ5FgA+uoK/4K99dT4/5pfbX8lpFV/XdXtaZ1YRZxPCNmWlltEo4D1saMeJax79h5fgPv6YpcSaBFj/qZZqlO1p6KzCM6fHVgNCU4sWnnOVpMLMhnDjAy8h6XShSJw8QUZTwy9UHJ0xt/HjEf7x9WIoO2uVaeZE+/bmmSWhONR/6fJuyy45Yt5ihCHLaoyhpMq4+nzn1rMIRxBAiXve96RA4uWZAhUPibbwsFevZodtYxO7eLsYfuFhCx4AixNFtYGJsosk91Rq1efgeB6bjvjCS6SWztQp3504BhI+bZdI6+ZQ+Sy2hnMWXHulDI/t45wHvs4EzhZu1hAcI38w== 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=DyCajYi4UBGlA1x2vDE96X+W3jTH9wnPpNGsALWMpe0=; b=UuSUsOMJEu+cQqfXjIkliXMhv7JDOEP8RT59ZUzm3FORLLN2m7PKZsaL5bML2RieWVevvX9Kq5oYfxw7h8CPKP+X2PF2oL5lPu1KGxGc92qJuApaJgZzpFGWK9qd0TLt2lTHvkiD2s2MEC1T1D66SYnEfGroCZqGwTG4QIHDyMk= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <010b9a56-4e43-4813-b705-e34d8b4a67c5@citrix.com> Date: Tue, 20 Jan 2026 13:12:08 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Stefano Stabellini Subject: Re: [PATCH 1/2] x86/svm: Add infrastructure for Bus Lock Threshold To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> <20260120095353.2778-2-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260120095353.2778-2-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0471.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a8::8) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ0PR03MB5678:EE_ X-MS-Office365-Filtering-Correlation-Id: 24a56578-d3d4-4d08-85d3-08de58258645 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?QU5xTGhweWxzaG5yTFQxZ3ROdU50OFRxWUg4RUZXTERaVFpOazVlWjMvNFcx?= =?utf-8?B?RWhCY1BSMmluTWJGUUFJWCtycnk0R2NQd3RlWmVobXhkU1EzUkdhcTMvTHFJ?= =?utf-8?B?QjZWMVBScWVEVzIzWXk0NVVlMm9UTmUzVWdhaDVvYjAyczRCZkl5cVY4T3lu?= =?utf-8?B?RGt4dC9kVUdLT2F1bWdqMnZwVjhZMERjTURMMDhVN1RpRnovTUpuQVpaVDZ4?= =?utf-8?B?RWJuWS9CN2pMcDVyY1JENUREblVUODVub05HWDl4UmlVU1hWYjdoZVVrVGpO?= =?utf-8?B?SU9iVzFOS2RwWkVXWHZ0UkoxTjVEeFpRNHYrVkF4YzFPOEE0Z2xBaFMzZENy?= =?utf-8?B?MXRobW9Kc01Qc1VEcG5kMDYxQng2Qm00THlSODlXZWpHRGxzVkQ1dnZQYkR2?= =?utf-8?B?S2hqcDBNL2tXd1ZIMWVHS1lrbDZDZkw2OWlNMGdLc1REQzRYWVpPNDI4ZkdC?= =?utf-8?B?cDlKNnNqd3dCR1VTZzg4aVdGclFjUS9DS1NjVHRsdkRCMXVmeXZBSFg0eUp4?= =?utf-8?B?Y3FuTkFsaGlUK1VxS2M4SkRqUUs1RmdETGxtVk9xaXFLWUNseVl6TDRhRHY3?= =?utf-8?B?MUJkWjRnZ2NNMXZCcFNMSjFuelJqbGF0SEtpcW5uYzdzVTlqRFlXUVhldlM1?= =?utf-8?B?ZjZsSVdzZFpNdzlrQWtpOGRYblErL1Fwa3hobGF5Zys1QzN0Q3Z5WDVGaHh4?= =?utf-8?B?WHRkSDg5VXhjQ0VHb3Z3NzJ4R0QwY3ZZcnFTalNrWEl3N1VUbjUxRzhkOHEw?= =?utf-8?B?dSt2SExmcHovWXlHYVJJL2xhT3RmOG1KYlpXODVOUEZaSWVMRXBMcWVieXZX?= =?utf-8?B?VUw2eHA5aW9pN2VhOUN3dkFCZjAyYWlEbk1NMFVUSGdmVldsaFRYQnJuWHcy?= =?utf-8?B?OXkwbzFGSVRqbVRZOWRRVEgvRXJCNzJLUktRVCtKM2xKQ0wvYkdXbFJXOWk3?= =?utf-8?B?cXBwZ0hJckpxSkhiU2dLd2lMUUJrV3pWdDVodjhEczZHTFg4L0pPRmFrUDRt?= =?utf-8?B?eTQ5ak83YVZQaityV1pqQXlYdHhuakNZOVVjK2NkQjk3ZzNzcXRWcGtKdCtu?= =?utf-8?B?YUdVNnhGbG0wcXlSSjZaVFAzcEJtV01MR1I5Qm5rSThyVDlodjN6Uk5Kblox?= =?utf-8?B?S29vWkwrYXVyNndnUnhucnB6anBPMWpHM2swd1NJN0kvbjl0NGw1b29CRTRO?= =?utf-8?B?Q2M5UGh4dXhUamtHT2gvQnVuTGtmVWx4K0NIYU5mdTFtSmZvc1g5ZURLZFo0?= =?utf-8?B?b3lGRUFWQkc1WHF0TWtmQzExTWZ1YTR6cE1KaXJ0SWd1VVZ4TUVhUmppOVZO?= =?utf-8?B?YTJ6TGRDelJVRFprNURUS0tncm9tb1JhOU8rT08vSFo0ZkRzMWJ4QUhqOXNk?= =?utf-8?B?NGZZUEgxcGo1cW9rNWx3bVB6V2xwb3hXcWRTNVh4T0ZUOVBWK3h3SjgwOVNz?= =?utf-8?B?c0xLNGl4SnRqQW1oVnZuR0ZxRGxqTEhPdDVDNTA4dlljTmtLVXIwMjlCbVdX?= =?utf-8?B?d2lLMDNNMDZodWlmbVdJbjFHUUFmV2NZMFVVZmp1T0VzQkFCNFVrS0t4UGR5?= =?utf-8?B?eitnTmc3aFRlM0tLR21XLzFkL2NOcVhNMVpwZjlwOHhxaGE4Ymo3czd6UFh4?= =?utf-8?B?bjZtVlpuL1kxd1dUekFZYzFjeHZoSjYydlRJdlBNQWF2L3Y0TlhjTENsb25C?= =?utf-8?B?KzU5YmhvYzEwd3ZtRCtFTlNCVDVkMzgvRGQzdDVlRi9LTFR2b0JaVHJnZzdJ?= =?utf-8?B?akx3UFg4L3cxM2ZHMlM3cm9WcXhLem8yamwyVE1RZWlhY0sxakR1ZnVMNTJa?= =?utf-8?B?cE1JYjRsYlBKS3l1ODNST2F0Z3VyaXhQazZPdWY4K244ZkhVeXVGWGhZOW5M?= =?utf-8?B?L2xvek53THRtdThwUXYzblZhTTZqQjZFdTFDM2QrQjM3emN4eW5seUdjWTBy?= =?utf-8?B?b2lqUElqSkRQejU4TTJUSmZQSHpWaUtGUjFSTHNMWTVjUFRNVUZ3SUl5K1Z3?= =?utf-8?B?OCtMSlBqT1hHYk5oemZYSDdyMk90ZVBjZkhuNXY3RitDajVwckhFL0dFZ1B6?= =?utf-8?B?UzZkQlg1QmwrZFJibTZ5Z2xJVjVydHp3aFovVDRJR0QxQTdvZDA2bHpxOHVm?= =?utf-8?Q?CSnU=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WTRIVlB4T2NKd2NWZXdpN1l1SDJLQ1JvMTgwU1VrRVRGL1p3RktHaW5MYk5N?= =?utf-8?B?TW50cnk3S0gxbDRWN3dzOElrWEZaL2dLWm1KOHRFTzQzZEdkcUl2YVZDc3VG?= =?utf-8?B?UzBEQmYwOWZ2bUtyOWV5Z2FielROKzU5Zm9YV3dNZU5DV0s2bTdaZUtNME41?= =?utf-8?B?YWZzQW9XWXpRODFheTRjNHpJQTNHYWhzQTBpeVJTQmx6aXAraVYvcG9RUENi?= =?utf-8?B?VDNoOWkweWJBcEJ3aHE0T0YxRmdSbWs5VnFGWWFmKzB6a2VBTFVPZm1HdEdD?= =?utf-8?B?aWx6T0pWNHl6Rk1UOE1ROHgwZE5IVVczL0pNVldsUFZ0OWhGblpmS1NzUTVr?= =?utf-8?B?OHk4MmpoZklyWm5rT25DbEFqRTErSUYrQU9oOFVUcHkvS2NvQWhiVnJFanVk?= =?utf-8?B?M1kxMW91MVh5SCt4NXBRU2JKdDV6bWt3eHRGc3hVcklvcHZqQy9SekhwY2VR?= =?utf-8?B?UnVvMG1GZm1XWEdrOFNQaEQ2UnhBcUYxSHJtd2VBeGYwcXlhcmN3a3pvWjhm?= =?utf-8?B?b2FpWGhFNVVPbmQvcVN1Vkh5Y1hYQitLTi9XckVvM2laSVVqOCswb0NSek9I?= =?utf-8?B?UmFPWFo4VW9yZXlxenNjSms0UEQra0ttRGNGdzM5eDNzMWNWL1JLbWN6cGZR?= =?utf-8?B?TS96YTVOei9iZjZydXNPU3Z3SEIvVE5DK0N0d0Z4aXhKNGVaWnlVbjdmSkEz?= =?utf-8?B?WEt1UHYyWTNNUW5wSDY1RDIxNWlpcXV4enBWUjNCditvNGZkVkVlbjlQSm9J?= =?utf-8?B?ZDNCYlljUVJ4SmlWYUVkM09xT2Z1MlR0WW5BTS9UdHNCY1RDLyt6MG9CbFlM?= =?utf-8?B?L1grbkgrdFhXcUtEVUE0eWxMOCt5Mk1HNzNiaiswcXZheEYxV3pDc3h1dXVU?= =?utf-8?B?RlJrUk0rT01KNEZXUTBjTlFoYzErWDF2c3VNaG9JdFljQzJJZ1dRTjFDRXJn?= =?utf-8?B?czZCY0lTY09ESERXSWhZMXJyUGZmVnAydzV5TVYzckZlZFFPUStLajNCTzNt?= =?utf-8?B?Rlcxc1ZhUHpVY2tNcUJkL3FmaUZIaGpobmlFUlpsTWcwbkJQMUNBUDFaK0xE?= =?utf-8?B?ZCtXZXl2L2ppeXJMMzJITHFpMHBkZFZMRHAwUHRoRGhiNWxtc0hPL1Z4eFZv?= =?utf-8?B?RmVJbHlZVnVHZm84eWhDN1BNZ1drRnZRZVBzOWw2TEx0cEk1TytOWFBxN2xB?= =?utf-8?B?Uk1vbWpVSUJtZUZYbldnZkNBRHVqY0phRWRENG83RDFiQUI5ODBUZ0N1T1h3?= =?utf-8?B?NHE4RjdBSnlReElHeDNsVlVkamtRWS9RcTBiTDRYb1VYY3JBa2VTYWZpbUxX?= =?utf-8?B?RnV5bUdNSGZBTWpUaHErQ1dMc0VwOURiY1VHVkFxOEJFQndTSnlPWGh2bDU4?= =?utf-8?B?Uno2RmphZW4rcVlEc2ZZK0I5UDB2QUlDTmZPelZJYlIzRGpvUjhQczdQbFhB?= =?utf-8?B?cFZEL0lmUWFwN3o5cTVTZUNZekpKM0UrM3hBUlQ0QzdzODdsbS9ZWkIzc3JK?= =?utf-8?B?MWhvUmM3aGxMcU5wbTlrTDcxYjFSdThhRnJHZVNzanMyYWhuMXJJQnl2dSt2?= =?utf-8?B?SjFNMHJ0ZW9GakFxeFZub29JQ0hJcXF4ZXNzWTE0SlNBZmtqMCt2QVdxR1Fo?= =?utf-8?B?YURtR3ZMYzNES1QrYWRtRlc0OHlZVWpBM1BnMXdCWmJkZ0djNHBrMm11aGtj?= =?utf-8?B?ZG5WM0NqV1pwQWt2b2RmOXZBS3ZVVmVSVUNPMVlYc2p1K0dRd0pkd3F4eWFj?= =?utf-8?B?SUpSdVBtZkgxTFhpbnlsM0tsMmFObTNtazc4QXo2d2RiWGNOcHFKQmE5cEZq?= =?utf-8?B?Yy9rTFZXS2dCbjdQWnRCMVZRdHVBa09IY1BpVXBWTEVrNitOeHZTdkZxOFlI?= =?utf-8?B?azd1WVVhejI5VlZjK0JjNmZJVmJ2cjdoNXljbFJGMHpySkxSN0dENm52cTQw?= =?utf-8?B?QkRFdThwSzNZMUtIM0RXdTFJUnVxZzgwTXpTTG50aWtRcHZ3dkdUUmdqbnow?= =?utf-8?B?TTJFM1ZNbi9GR0ZTTGtDZXQwcmljZjNKaitJSHZhVmlnSmZndWdnckNHZkhO?= =?utf-8?B?RUhxSHBEK29ZbWlJb2pkZU9kY3VZRDhielBkUW9qbDJianlFZ0pTcmdObm9C?= =?utf-8?B?RElEb1lPb0tZVFJBTlU3VmxacVl5WitoY0s1NlV0a0FhbTVRbzMwVEVVaXlH?= =?utf-8?B?cW8wMDdtYlluZXZtam1hdUk5YytMbzFYNHp3bU5FQjRPejlpalVvSXlGaVFm?= =?utf-8?B?Q21VOWN6Z3prR2RBaVFWRU9iaUs5MzJVb0xkZWJtYVRrdFNPV05CVTAxL3Vl?= =?utf-8?B?dFY4cDUvM3QxOUZMam1lZWZmb0RRVjczWG9LMmZtSDBjZnc5UVhUZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 24a56578-d3d4-4d08-85d3-08de58258645 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 13:12:12.4430 (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: WiDLka+YJ9phB2wThiuciRlRu3MjTeF4kGX69CBlqygLxn3dtGcsQOXXxKV+o/uE2Bn8tIQuQDSGGI4Pta0vPz1qpYTPjmZ+BacjMhW5Bc0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5678 On 20/01/2026 9:53 am, Alejandro Vallejo wrote: > diff --git a/xen/arch/x86/hvm/svm/vmcb.h b/xen/arch/x86/hvm/svm/vmcb.h > index ba554a9644..85e194f247 100644 > --- a/xen/arch/x86/hvm/svm/vmcb.h > +++ b/xen/arch/x86/hvm/svm/vmcb.h > @@ -65,6 +65,11 @@ enum GenericIntercept2bits > GENERAL2_INTERCEPT_RDPRU = 1 << 14, > }; > > +/* general 2 intercepts */ > +enum GenericIntercept3bits > +{ > + GENERAL3_INTERCEPT_BUS_LOCK_THRESH = 1 << 5, > +}; Abbreviating thresh like this not great. For the intercept, it can probably just be called BUS_LOCK.  There's no other form of such intercept. > > /* control register intercepts */ > enum CRInterceptBits > @@ -289,6 +294,7 @@ enum VMEXIT_EXITCODE > VMEXIT_MWAIT_CONDITIONAL= 140, /* 0x8c */ > VMEXIT_XSETBV = 141, /* 0x8d */ > VMEXIT_RDPRU = 142, /* 0x8e */ > + VMEXIT_BUSLOCK = 165, /* 0xa5 */ VMEXIT_BUS_LOCK for consistency. > /* Remember to also update VMEXIT_NPF_PERFC! */ > VMEXIT_NPF = 1024, /* 0x400, nested paging fault */ > /* Remember to also update SVM_PERF_EXIT_REASON_SIZE! */ > @@ -405,7 +411,8 @@ struct vmcb_struct { > u32 _exception_intercepts; /* offset 0x08 - cleanbit 0 */ > u32 _general1_intercepts; /* offset 0x0C - cleanbit 0 */ > u32 _general2_intercepts; /* offset 0x10 - cleanbit 0 */ > - u32 res01[10]; > + u32 _general3_intercepts; /* offset 0x14 - cleanbit 0 */ > + u32 res01[9]; > u16 _pause_filter_thresh; /* offset 0x3C - cleanbit 0 */ > u16 _pause_filter_count; /* offset 0x3E - cleanbit 0 */ > u64 _iopm_base_pa; /* offset 0x40 - cleanbit 1 */ > @@ -489,7 +496,10 @@ struct vmcb_struct { > u64 nextrip; /* offset 0xC8 */ > u8 guest_ins_len; /* offset 0xD0 */ > u8 guest_ins[15]; /* offset 0xD1 */ > - u64 res10a[100]; /* offset 0xE0 pad to save area */ > + u64 res10a[8]; /* offset 0xE0 */ > + u16 bus_lock_thresh; /* offset 0x120 */ bus_lock_count, which is basically it's APM name anyway. > diff --git a/xen/arch/x86/include/asm/hvm/svm.h b/xen/arch/x86/include/asm/hvm/svm.h > index a6d7e4aed3..14fe4abf96 100644 > --- a/xen/arch/x86/include/asm/hvm/svm.h > +++ b/xen/arch/x86/include/asm/hvm/svm.h > @@ -37,6 +37,7 @@ extern u32 svm_feature_flags; > #define SVM_FEATURE_VGIF 16 /* Virtual GIF */ > #define SVM_FEATURE_SSS 19 /* NPT Supervisor Shadow Stacks */ > #define SVM_FEATURE_SPEC_CTRL 20 /* MSR_SPEC_CTRL virtualisation */ > +#define SVM_FEATURE_BUS_LOCK_THRESH 29 /* Bus Lock Threshold */ > > static inline bool cpu_has_svm_feature(unsigned int feat) > { > @@ -56,6 +57,7 @@ static inline bool cpu_has_svm_feature(unsigned int feat) > #define cpu_has_svm_vloadsave cpu_has_svm_feature(SVM_FEATURE_VLOADSAVE) > #define cpu_has_svm_sss cpu_has_svm_feature(SVM_FEATURE_SSS) > #define cpu_has_svm_spec_ctrl cpu_has_svm_feature(SVM_FEATURE_SPEC_CTRL) > +#define cpu_has_bus_lock_thresh cpu_has_svm_feature(SVM_FEATURE_BUS_LOCK_THRESH) We actually discussed this on the x86 call just yesterday.  This wants an svm infix to match the others, and the thresh suffix can be dropped. I can fix all of these on commit. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 20 13:18:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 13:18:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208888.1521014 (Exim 4.92) (envelope-from ) id 1viBcx-0003Jt-Eu; Tue, 20 Jan 2026 13:18:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208888.1521014; Tue, 20 Jan 2026 13: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 1viBcx-0003Jm-CD; Tue, 20 Jan 2026 13:18:35 +0000 Received: by outflank-mailman (input) for mailman id 1208888; Tue, 20 Jan 2026 13:18: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 1viBcv-0003Jg-RK for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 13:18:33 +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 8309331e-f602-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 14:18:31 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB5678.namprd03.prod.outlook.com (2603:10b6:a03:2d4::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Tue, 20 Jan 2026 13:18:27 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Tue, 20 Jan 2026 13:18: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: 8309331e-f602-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Z88yJQQ0IJDQCCo6H/Nm3Q3UZniZm9Hh5isNbNoGLOzMSNR8eD6q/ODj2jky3p71b+fnFb5fsp9fBbm7J0C2S3yGNJGHj86li8LmkRZKfq7pALafTaT/nX3SeAVkQkgNa7pWxgy75V6hYf/WQgE7DxdZpmL7/mFzgsH6CMhy7OnxPwj/TPXyZ8eeMzZZ42uzV1Tx9oHD2cDzLobjMc3S+uI2/nQs4tM+sDtjcc1scW0+BVmp3IGkaTLKAEC4iPEy2cGwLOJmYHER+9twMs2gOyu84xbF0h++xuqi8UE0p5e79W27+yTWH04XVF72UwlDK7D5VCcup8Z0/8vz1Ps59g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BCIrhLfAYPh3ncIVmSj2a6/5TuraJFCtzQLNfB+5OlI=; b=QnLGMwqsAvvIkjVdIrl1rUQuNRZYh9Hxe5GPnqhO6F8Ge/qa5z5MP2twTZMmYxIEKYtK6cdLiGKcQNRARlNWJIWsjt6F7rQ89AoRB+2tTTl9H/iy0JY+UszbEeXWnIgQVEWjoxO2CmNGWekNiNfeFXngH1LCUaJacbcnYCeBGj9XlgL5QmhjtDE0djxuO6zbZZHSZxBBvG/qqh7adnGQRIIW736671zJhajdE8v/DjqC9c3V8XZbfN5LO9H4jkR/19+rjsBFyU5MI5OctK+FxTFPWZR6sosbCNTkWrdXgQBp+MY8Eglnr5GNc2VkRov6XSvhy2ink+X3wRIMHEa+HA== 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=BCIrhLfAYPh3ncIVmSj2a6/5TuraJFCtzQLNfB+5OlI=; b=nFXJxDwVvy09JFjfEsik4ex7iGeU0uTYMWd0MrrE/RC1xcbBpaY4WQx+g+dvrxLFBiij8hXIZpUW0OIt/GpObCNFv/avmgadQ2F3QoeUx+N973vyWtzFsYD1UkJ+ijAq7hr82Js7V/8ltfCp6zhulkMJ/WPvLP+lThm97pVyjiY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <5a4aa1d9-dafb-453c-bd4c-8da860519f01@citrix.com> Date: Tue, 20 Jan 2026 13:18:23 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Stefano Stabellini Subject: Re: [PATCH 2/2] x86/svm: Intercept Bus Locks for HVM guests To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> <20260120095353.2778-3-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260120095353.2778-3-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0494.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1ab::13) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ0PR03MB5678:EE_ X-MS-Office365-Filtering-Correlation-Id: e59a3415-7372-448c-4a29-08de58266560 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?ZmlQMXVpRDNxalhkdld0OHNXeVNIOUJaZnQwbnlSRk5XWWVaUlhRSmFNL0Zv?= =?utf-8?B?YlFIM3I5QzF2U1RGUTFvTmhpV3FNRHRxL1Ewb1Frakh0dk9rNDhHL2lzbEJP?= =?utf-8?B?dFFBZGF0NWFGK3JXUHVxS3VaU1NuZmtZblhoUGpiNGRKT2dRNnArcGRKbWNC?= =?utf-8?B?T3FzTEdKVnNtZ2FNSVlvWkxqUlM4N1ZvTUFORm5hZFgwUWxucEUzM0V6Y0cy?= =?utf-8?B?dDNuSm1yUzR0bC9NUElrQUlIQ2QwdXdaSndXRml4TTF3N2kwdGpzc0V2TkdV?= =?utf-8?B?eEZaeUZqT1NuMk1pS2J0bXR2SXpIRmpvYVp4NzZBWkdHYUlySnJiSHhzbEx1?= =?utf-8?B?bGZPa2J4czR2cTRpQVVXVzRsT2pJdWIrbHh2a2l0RnN4WHhWaHYzV0ZHV2h6?= =?utf-8?B?cTFQUWYrRkcvR3VlVVBsNHVpcjhVbnVaOXVXelVDODdWU2Q0Nm0rUFhkNHhh?= =?utf-8?B?eXJUZXFXcTdMZzJZSzNaUWhzVmgwc0p1aCtqY3EvZ0g5Y1lGNnVRWDZhbnhD?= =?utf-8?B?WWRhNks5amZsQmVLNGxhK00wU1FVVGtNTGpwVHFjM3Axb3lhbzJuOW5oSUFp?= =?utf-8?B?ZzZDTktvcm8vSllmOUYvVnpleWd6MzdtTVdwYXJ3R09PTnhHdGhUamQ1ZmJv?= =?utf-8?B?QW95QnV6cVVneGlhdUkyZFJQSTYrRHZWWC9XbjZqSngvN2RCWUhwbW1oRS9D?= =?utf-8?B?RlFuRFkvb1BsblJ2ZVk3ckhGZGZSeHJ1cktRa0Z1YVdJM1lGOGhrV1ByNkp3?= =?utf-8?B?TWtPNytCS2RlV2NHczVzM25pNTRSOEhHeHNIVk1vR3hQSjRwZ3o2WUo2MXRZ?= =?utf-8?B?NFQ0WkN5UHhsd2dESy9OckZYMk11NGIwbjlkamMrVWZ5UnNsNVpuRDdLZUlu?= =?utf-8?B?NGp0YTdrNG11aDNpbzRaV2hsRGNZdmIzMThYc1haWTdyMlVuT0piVmFmRDY5?= =?utf-8?B?cFdXRzIwNWFnNnBnV0JQdmxlZXZGMTVHWjNscTJDM2QzL0ZQenYzTmpDL0JF?= =?utf-8?B?Mk1xWCtoYmZSUkgvb0pnNFJQOWFxQzMwTnhCejBSY3ZndHY3U2g0OWJYWFd6?= =?utf-8?B?bGdzVzJzS2dIYmZacnh0c3B0aDgwcExkWVJHdi9hVWcxaXlRdnZ3NzI1SDhX?= =?utf-8?B?Yksrci9FZGlXYUxLOStDczQwVTlkU0tkRDBSZThDOTFhTEpab2E5VVNrQUxS?= =?utf-8?B?blFlSUNhZ1Q2OHFZSmQyV05kWFhWMGd0R3dSUzVjUmtQYXUveGFtbml1cXI2?= =?utf-8?B?cWJhY0NHRjA4bjVSa2RJWWxRV3lvdXZ6UnEvSkxqUG5HMFZaczlEWHdwc1VF?= =?utf-8?B?emFRLzQ0dEkzNzh2Mk5wMHhoMFVVeGw4dUVxUWlmTTBRMFJxcHQ0bm9MZFox?= =?utf-8?B?Vi95RkdkWE5tMnZDT2toQ1c3UjM5cGd2TmtHUjdIVGRrMk9RL3FMZDRHeHd2?= =?utf-8?B?ZWY2R1FyWEF1ejJQYjVRaDhUbW0zaGhiQklMRk1IaGJqZllDTjQ4aStZdzl5?= =?utf-8?B?M01tSU92bjFobGE1M2c3bTdXU2J0c1lEYW5lK2ZDckNSK2lyaHp3SXovakx6?= =?utf-8?B?VnpoYzA1eDdRa0RrN0hyeEErNS9VN0JPRkVWQXhrU3dkQVk0ZzFuVEFjY2lD?= =?utf-8?B?Rmh0bU9PT2Fydm9NUTd2MWtWTDFKK3ZTakFBSFNCbTFMc29VTWZnYlU0cEtP?= =?utf-8?B?KzZmZUY4MWJPSnd5c2hYZDRNQmxjM3hPaGVjYTdTUGNsY25vZi9KZC9WQWRO?= =?utf-8?B?Q2ZROXhjZFlkOWZWMzNuTUh4bDI3aU5hdTFSYnhYcFFVY0lvZ2padjFzbGRy?= =?utf-8?B?NFlxMmp3TEQ5eXp5N0dNaUpXWWh1VkJ1Qy9DVTBPaWcreDFjSXRYWWk0WHpz?= =?utf-8?B?dHQ4SGlNNk4rdWZUWERSVHhMaktucHluYU9kZFJ3aWJCNWZ4Tnc1MTdVNnJF?= =?utf-8?B?Ynp1UmJrK2V5c3pxNnZyNW9qY01kQzFiSklnNmFGN2dXRE5YVUtjWGN1STdF?= =?utf-8?B?bWRFQ2VtVC9hcjJQYUlVd3ExZkpVZ3VJNTJSY0x4SUt1RERvV0R6SDZtU2R3?= =?utf-8?B?N0pVNXRFUC81WUZMdUxXN3FHVnBLcTZucUhaQmJUc3MwekFGSzRZOTVsS05O?= =?utf-8?Q?Lkkg=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OVpmSSs2SjJ3RVhvWWMzN3VucGpYM2RLMWEvOFlSdGlUWmVhQldETkVuR1k3?= =?utf-8?B?cnFiVVptSnl2TVB0WVVFSXNtdXdWQVNZeTF4N1M1TlV6NEM1Ym1DK3A4amJ5?= =?utf-8?B?TVhrYitiWVRSSFVqdldOZG1ubloyNDZ1SzJpWVpjQ0dMTWxZNnFVelE2S0M5?= =?utf-8?B?R2twM3h2dnF1TmowcUdEcHdHa25rV1dyem12cjRsaWJ2ZXV2TUc3b29KVjJs?= =?utf-8?B?cnc2ZEtHUUhLY04rVDhGR0VhdHVabmhDMUtuOFE0MmZ6cXkvanNwUTd6aERF?= =?utf-8?B?REZhRGpVcXpNbVVxWVhlSmE1OGFsblZlOVliUFFjSGhZQ1BlS3NickpTNllt?= =?utf-8?B?ckNpZ1hZbnZPQVZOQjR0TnFHc2R4akg4Z2d4cXV0WEx2OEcvYU14elFrcWQ0?= =?utf-8?B?V1hSSUVHdXZ4ZGpWLzVmMG1JODV1SVNzNTRBR25xYk9TZE1zVEt3N1hKVmY3?= =?utf-8?B?bDh6NFpXSzNvdGw4dXZ1ZndGRjlHcmN0bFBjY1NzVjdsS0M3cm5MdWZnTlhG?= =?utf-8?B?TDJMT1orell6V25JREg5WURBSHk5SzdCelRNVUN2RWRmVXpZQWhKRWY5R2Jp?= =?utf-8?B?aGIvYU5Eb2FoVlBGM3VKcGN3M0dZNHVoYXFpQTNqLzY0cUk2ZW9zdTZTLzFF?= =?utf-8?B?QTU2T1ZRQjZlN1JHcis5bGN6bGdjZXFzd2FVYTczTE40ZEVlU0xFYjgwdnpR?= =?utf-8?B?SEEzWXpxb016SFovelZ1c2dTdU5JQUxVSEZnRmlzNCtESUs5YkNFUVVteFJT?= =?utf-8?B?aDBvckljYWc1U1VYVW50WFYxRXVIWDZVSWpFWWZDdlBjRmdPRktDdVFZellj?= =?utf-8?B?K05WSnRhdnZ1NGhDYXR5QkhiUVdTRDlIZzk5aTEyWm5VZmVvRUV4ankxekpa?= =?utf-8?B?ekM5NlNRdzVXMVJPeVNDdEhNS0FNT0F2Lzg5RDFzakhmNjJNT1BrMHFWbE5Q?= =?utf-8?B?dWNtU1Y0ekVEelRSRW9EMWhsRDdTZDhzeXFleFBqODVQUEttcytSUS9kU2M1?= =?utf-8?B?RzZzWjB6cXB1VUpvL1hYUEVkODJuRis4dGg3U1A3NFlUdngrRUpCN2dKeE9l?= =?utf-8?B?NmpERlFrd3V5N2xSZFVnZCszTEFxbEorcUw4eHRwUXFyRFlPSEVRWU9TWGZn?= =?utf-8?B?aDV4aUY0NkowYVVvZ2FlU2hXWlFaWGFxckdYWXdnWVVWYjMrOFU1c2g0SGpp?= =?utf-8?B?Q09TYXB2L3NzN2ZwV2VFditqU1BUelVLV05TZjZ6VHd3RVZBcGJVYWRyUkwx?= =?utf-8?B?aG9reWJyUjgzQXd5TnhDaEE5VTlhOXQ3amdqb3Jmbkx1WUMzSXpLZm1wVWQ0?= =?utf-8?B?SlFxdDdDRUtidlJPRlBkM3hqZ3VrZE5CVWlUNmxJSTl2Q2IyZG13RXVBU25V?= =?utf-8?B?TFcrMlhSODJKODgvQlM0dEY1MTNmM0l1WDY0eTZnZTI4SWhkdTVINmhzTFBY?= =?utf-8?B?R2krdnhoQ0p5YlN1NEt4dG8wdnpJckxzTzYrT29UQU9SS1NkZzRpeWJ5N3Q5?= =?utf-8?B?RVgwUWFUeHh3NDBSYm5oVVB2R1c0aThTTmk2d3ZkdWdaelBwUkVSTVRobE1C?= =?utf-8?B?WG1EdWRWZXRnYlQ1WlZlTXh1ZVI2ZHZZeWZ4Vm8zTjRteW5hMWs0QTR6S2VF?= =?utf-8?B?L3Jrb2NwSTJGcklLVjFBeFcxR2hnL3gwOHorNFVSSEw1S3ZVTUNyL0oxSnAz?= =?utf-8?B?MGk5dU43YzJkME0yWU1ISXAzS1ZhZkV0OGlrSGk3WWk3RkgweGQrK2JudUd0?= =?utf-8?B?aE9NUUxlOEMvNWdQVmpxQzhWSXkwTDJVZk5CSWhUdFNTdTlJME9IWHp2M3Vo?= =?utf-8?B?WnByU2dFUkN2TVBUVGJGdWoxUW1xRFBRbVVxQlVaSVh6T2UzMjNVV2YrMkF4?= =?utf-8?B?bDgwSXFzbXZPazhUU0lMSXV4eHUzOVhIbGtYNno2VktRbU41Z0I5T3JpaG9w?= =?utf-8?B?ZnBENCtLZGNUS0pBdHVyUGxFN2dLd3BSMmlzekxrSThBNFE2SGovS3lXNTdJ?= =?utf-8?B?WXZTdEZac21rVnk4ZXU5VDRkS3pVYmo3TmV2amxKRDc1bHB2WjZ4cDA1WGoz?= =?utf-8?B?UHN4VTZldS9xQXNEUE9KM1lRRGYrQTB2VXNod09VQllkMlBZd3ZFdUcvcVZE?= =?utf-8?B?aFJoZWl4eFdNV3dYak0zMWk5NGExb2gyeG5qc1Z2WU5ycERja1czc2Q2SHQx?= =?utf-8?B?WW55WnpaMmVVT21NZ0xxSDk3TzRnajV1NE5iM1JCbDNnaWdJbkxIQkp2N3h2?= =?utf-8?B?RjlJMlJET3NmTS83VWZpbi9YMWkrTHhOeDJjVkhPU2hoUDlWVG90Nko3T1Ri?= =?utf-8?B?Ty93VkhqRzh1ZkFBUCtGYyttQXYyUWNvaUdpWGpCZk9xZk1VanNTWkdva2xv?= =?utf-8?Q?+3/HfPOJu/KkjaRw=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: e59a3415-7372-448c-4a29-08de58266560 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 13:18:26.7458 (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: JER1sKyLRBHZgqgM9K/fyASV1M7h4jP4eVZLc80NRXlksCSGqzExgJpd7FtDCA8uuRQmjyy6FIafmF0qD8U2jtlHvk4Q58GSf8Am7xZh740= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5678 On 20/01/2026 9:53 am, Alejandro Vallejo wrote: > With the threshold initialised to 1 the guest exits at the first > buslock. Initialising as zero is invalid and causes an immediate exit. What do you mean by this?  A VMRUN failure, or a livelock? > > Signed-off-by: Alejandro Vallejo > --- > xen/arch/x86/hvm/svm/svm.c | 4 ++++ > xen/arch/x86/hvm/svm/vmcb.c | 6 ++++++ > 2 files changed, 10 insertions(+) > > diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c > index 9748df87d8..dbb7f99d5e 100644 > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -3087,6 +3087,10 @@ void asmlinkage svm_vmexit_handler(void) > hvm_descriptor_access_intercept(0, 0, desc, write); > break; > } Blank line. > + case VMEXIT_BUSLOCK: > + perfc_incr(buslock); > + vmcb->bus_lock_thresh = 1; > + break; > > default: > unexpected_exit_type: > diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c > index cbee10d046..7a19b1ab61 100644 > --- a/xen/arch/x86/hvm/svm/vmcb.c > +++ b/xen/arch/x86/hvm/svm/vmcb.c > @@ -66,6 +66,12 @@ static int construct_vmcb(struct vcpu *v) > GENERAL2_INTERCEPT_XSETBV | GENERAL2_INTERCEPT_ICEBP | > GENERAL2_INTERCEPT_RDPRU; > > + if ( cpu_has_bus_lock_thresh ) > + { > + vmcb->_general3_intercepts = GENERAL3_INTERCEPT_BUS_LOCK_THRESH; |= > + vmcb->bus_lock_thresh = 1; /* trigger immediately */ Really?  The APM states: On processors that support Bus Lock Threshold (indicated by CPUID Fn8000_000A_EDX[29] BusLockThreshold=1), the VMCB provides a Bus Lock Threshold enable bit and an unsigned 16-bit Bus Lock Threshold count. On VMRUN, this value is loaded into an internal count register. Before the processor executes a bus lock in the guest, it checks the value of this register. If the value is greater than 0, the processor executes the bus lock successfully and decrements the count. If the value is 0, the bus lock is not executed and a #VMEXIT to the VMM is taken. So according to the APM, setting the count to 1 will permit one bus lock then exit (fault style) immediately before the next.  This also says that a count of 0 is a legal state. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 20 13:19:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 13:19:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208896.1521024 (Exim 4.92) (envelope-from ) id 1viBdU-0003nV-QE; Tue, 20 Jan 2026 13:19:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208896.1521024; Tue, 20 Jan 2026 13: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 1viBdU-0003nO-Nf; Tue, 20 Jan 2026 13:19:08 +0000 Received: by outflank-mailman (input) for mailman id 1208896; Tue, 20 Jan 2026 13:19: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 1viBdT-0003Jg-10 for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 13:19:07 +0000 Received: from mail187-33.suw11.mandrillapp.com (mail187-33.suw11.mandrillapp.com [198.2.187.33]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 959bbeb5-f602-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 14:19:01 +0100 (CET) Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail187-33.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4dwSZr22GyzBsV0KN for ; Tue, 20 Jan 2026 13:19:00 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 05aa0d6be7e14def852090f37a81eab6; Tue, 20 Jan 2026 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: 959bbeb5-f602-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1768915140; x=1769185140; bh=WkIIMde5sciFLIx0qV4+ykvVAFvf3u+QJqei95/bfSo=; 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=N1asEcGt7zOkrCZk1XnFFUbAwoy0KbKcVebgJSLeWnuFxezJgfFdEYXx1AMSkD9xS E1o3iNInE47UaKEYRUIy53wE1H/nUC7RLXSK0ON7qhSMGVZGWGPHon7n7nyf2IPpuh HZna6uS8NmS/AOeezuwxSqW8jeV6MFdAP+mTid94zute8/dBCLuoC4FYfE7ZUgqzOJ MFitjt9PW2JxxgLk9Sd8BbdpXc/h6ifZAoPPwL28WeS85CFXAXWrWUvn2quHdSXYYQ bHbId7MAhIcKa6kdgojdDz6wM5Kygj98whxrTrYEnzVTFEgYDw3/nZvPBMqqPZC/1c cYYgCoVjERjeg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1768915140; x=1769175640; i=teddy.astie@vates.tech; bh=WkIIMde5sciFLIx0qV4+ykvVAFvf3u+QJqei95/bfSo=; 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=e6JYbsKSD6rYwZ4aIZEM4+IhyjcTFqp0m2cPFrDlvZhdKoEkxYcJ6kg8i8gMotiwC v7bdURTQbHlSK9XW5iYcXLBG1BBcc9mbwPwSejllBzlyYQ7Eawfx6BbFnclOa9Puij biWbolcxyCF4sQyPpyZR4+3MDug0dNKsnifz8AaFNFsoU13TvApnIBQnbWNtpeA0CI Era6Kc4wLrNrmn1F//3iLItI5iysiXmMiA9qCWO06MCGiSVI2JqyIFiWXLBr7vVoDu R0Dx/Aj42+a85mTvilJd2mbMeiyoJW3S/AjpEoE+L6x1yg0DRJ64ZyGgFb/3NHwzwX 058ssLy36s8cg== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=201/2]=20x86/svm:=20Add=20infrastructure=20for=20Bus=20Lock=20Threshold?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1768915138738 Message-Id: <9097240c-a892-41e8-a686-b89d84d0c03f@vates.tech> To: "Alejandro Vallejo" , xen-devel@lists.xenproject.org Cc: "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Jason Andryuk" , "Stefano Stabellini" References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> <20260120095353.2778-2-alejandro.garciavallejo@amd.com> In-Reply-To: <20260120095353.2778-2-alejandro.garciavallejo@amd.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.05aa0d6be7e14def852090f37a81eab6?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260120:md Date: Tue, 20 Jan 2026 13:19:00 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, Le 20/01/2026 =C3=A0 10:56, Alejandro Vallejo a =C3=A9crit=C2=A0: > Add missing scaffolding to enable BusLock Threshold. That is: > > * Add general_intercepts_3. > * Add missing VMEXIT > * Adjust NPF perf counter base to immediately after the buslock counte= r > > Signed-off-by: Alejandro Vallejo > --- > xen/arch/x86/hvm/svm/svm.c | 1 + > xen/arch/x86/hvm/svm/vmcb.h | 15 +++++++++++++-- > xen/arch/x86/include/asm/hvm/svm.h | 2 ++ > xen/arch/x86/include/asm/perfc_defn.h | 2 +- > 4 files changed, 17 insertions(+), 3 deletions(-) > > diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c > index 5d23603fc1..9748df87d8 100644 > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -2524,6 +2524,7 @@ const struct hvm_function_table * __init start_svm(= void) > P(cpu_has_tsc_ratio, "TSC Rate MSR"); > P(cpu_has_svm_sss, "NPT Supervisor Shadow Stack"); > P(cpu_has_svm_spec_ctrl, "MSR_SPEC_CTRL virtualisation"); > + P(cpu_has_bus_lock_thresh, "BusLock-Intercept Filter"); > #undef P > > if ( !printed ) > diff --git a/xen/arch/x86/hvm/svm/vmcb.h b/xen/arch/x86/hvm/svm/vmcb.h > index ba554a9644..85e194f247 100644 > --- a/xen/arch/x86/hvm/svm/vmcb.h > +++ b/xen/arch/x86/hvm/svm/vmcb.h > @@ -65,6 +65,11 @@ enum GenericIntercept2bits > GENERAL2_INTERCEPT_RDPRU =3D 1 << 14, > }; > > +/* general 2 intercepts */ nit, you want to says general 3 intercepts > +enum GenericIntercept3bits > +{ > + GENERAL3_INTERCEPT_BUS_LOCK_THRESH =3D 1 << 5, > +}; > > /* control register intercepts */ > enum CRInterceptBits > @@ -289,6 +294,7 @@ enum VMEXIT_EXITCODE > VMEXIT_MWAIT_CONDITIONAL=3D 140, /* 0x8c */ > VMEXIT_XSETBV =3D 141, /* 0x8d */ > VMEXIT_RDPRU =3D 142, /* 0x8e */ > + VMEXIT_BUSLOCK =3D 165, /* 0xa5 */ > /* Remember to also update VMEXIT_NPF_PERFC! */ > VMEXIT_NPF =3D 1024, /* 0x400, nested paging fault */ > /* Remember to also update SVM_PERF_EXIT_REASON_SIZE! */ > @@ -405,7 +411,8 @@ struct vmcb_struct { > u32 _exception_intercepts; /* offset 0x08 - cleanbit 0 */ > u32 _general1_intercepts; /* offset 0x0C - cleanbit 0 */ > u32 _general2_intercepts; /* offset 0x10 - cleanbit 0 */ > - u32 res01[10]; > + u32 _general3_intercepts; /* offset 0x14 - cleanbit 0 */ > + u32 res01[9]; > u16 _pause_filter_thresh; /* offset 0x3C - cleanbit 0 */ > u16 _pause_filter_count; /* offset 0x3E - cleanbit 0 */ > u64 _iopm_base_pa; /* offset 0x40 - cleanbit 1 */ > @@ -489,7 +496,10 @@ struct vmcb_struct { > u64 nextrip; /* offset 0xC8 */ > u8 guest_ins_len; /* offset 0xD0 */ > u8 guest_ins[15]; /* offset 0xD1 */ > - u64 res10a[100]; /* offset 0xE0 pad to save area */ > + u64 res10a[8]; /* offset 0xE0 */ > + u16 bus_lock_thresh; /* offset 0x120 */ > + u16 res10b[3]; /* offset 0x122 */ > + u64 res10c[91]; /* offset 0x128 pad to save area */ > > union { > struct segment_register sreg[6]; > @@ -583,6 +593,7 @@ VMCB_ACCESSORS(dr_intercepts, intercepts) > VMCB_ACCESSORS(exception_intercepts, intercepts) > VMCB_ACCESSORS(general1_intercepts, intercepts) > VMCB_ACCESSORS(general2_intercepts, intercepts) > +VMCB_ACCESSORS(general3_intercepts, intercepts) > VMCB_ACCESSORS(pause_filter_count, intercepts) > VMCB_ACCESSORS(pause_filter_thresh, intercepts) > VMCB_ACCESSORS(tsc_offset, intercepts) > diff --git a/xen/arch/x86/include/asm/hvm/svm.h b/xen/arch/x86/include/as= m/hvm/svm.h > index a6d7e4aed3..14fe4abf96 100644 > --- a/xen/arch/x86/include/asm/hvm/svm.h > +++ b/xen/arch/x86/include/asm/hvm/svm.h > @@ -37,6 +37,7 @@ extern u32 svm_feature_flags; > #define SVM_FEATURE_VGIF 16 /* Virtual GIF */ > #define SVM_FEATURE_SSS 19 /* NPT Supervisor Shadow Stacks */ > #define SVM_FEATURE_SPEC_CTRL 20 /* MSR_SPEC_CTRL virtualisation */ > +#define SVM_FEATURE_BUS_LOCK_THRESH 29 /* Bus Lock Threshold */ > > static inline bool cpu_has_svm_feature(unsigned int feat) > { > @@ -56,6 +57,7 @@ static inline bool cpu_has_svm_feature(unsigned int fea= t) > #define cpu_has_svm_vloadsave cpu_has_svm_feature(SVM_FEATURE_VLOADSAVE= ) > #define cpu_has_svm_sss cpu_has_svm_feature(SVM_FEATURE_SSS) > #define cpu_has_svm_spec_ctrl cpu_has_svm_feature(SVM_FEATURE_SPEC_CTRL= ) > +#define cpu_has_bus_lock_thresh cpu_has_svm_feature(SVM_FEATURE_BUS_LOCK= _THRESH) > > #define MSR_INTERCEPT_NONE 0 > #define MSR_INTERCEPT_READ 1 > diff --git a/xen/arch/x86/include/asm/perfc_defn.h b/xen/arch/x86/include= /asm/perfc_defn.h > index d6127cb91e..ac7439b992 100644 > --- a/xen/arch/x86/include/asm/perfc_defn.h > +++ b/xen/arch/x86/include/asm/perfc_defn.h > @@ -7,7 +7,7 @@ PERFCOUNTER_ARRAY(exceptions, "exceptions", 32) > #ifdef CONFIG_HVM > > #define VMX_PERF_EXIT_REASON_SIZE 76 > -#define VMEXIT_NPF_PERFC 143 > +#define VMEXIT_NPF_PERFC 166 > #define SVM_PERF_EXIT_REASON_SIZE (VMEXIT_NPF_PERFC + 1) > PERFCOUNTER_ARRAY(vmexits, "vmexits", > MAX(VMX_PERF_EXIT_REASON_SIZE, SVM_PERF_EXIT_REASON_S= IZE)) With that changed, Reviewed-by: Teddy Astie -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Jan 20 13:21:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 13:21:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208906.1521035 (Exim 4.92) (envelope-from ) id 1viBfV-0005KL-6s; Tue, 20 Jan 2026 13:21:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208906.1521035; Tue, 20 Jan 2026 13:21: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 1viBfV-0005KE-3D; Tue, 20 Jan 2026 13:21:13 +0000 Received: by outflank-mailman (input) for mailman id 1208906; Tue, 20 Jan 2026 13:21:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viBfU-0005K5-Fs for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 13:21:12 +0000 Received: from BN1PR04CU002.outbound.protection.outlook.com (mail-eastus2azlp170100001.outbound.protection.outlook.com [2a01:111:f403:c110::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e2d716f3-f602-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 14:21:11 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MN2PR03MB5149.namprd03.prod.outlook.com (2603:10b6:208:1a4::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 13:21:08 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Tue, 20 Jan 2026 13:21: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: e2d716f3-f602-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VrOIIGCLu2oBRhuelGVdcj8ZMHoQQEgPHTnPsENNQNZcdlduCAz1PWxcq+lghlNWd4fhwXZC+BJeNBNg4ewYE97TuPAY2VMHHPg4B/bHyc+V3YX+2FfxXz0XiMmhI5j1ZCJY0kOAjmW6Vu79CrYRfWyU+8Kk9p2yd1Aki2WOGlcCBD6P25yZe939kV0CSB91T48fTbZTm1Tet7Iv+mXrMDQBcULJ4PvC87RFyoWkG5tCotaUqQpBbyJnuNGjE83Ttp972ZSI8nNu9uD0HiK07U2CyiwI+DB5bqnh1IOZGhL3O48wOvPByLwQbAtWe6UcGABMR8VS8XwFMfnqNYuxig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OOpw9wumMgg40LcpJzhhw6lrd8Hnq4Geo65K0tCzFkc=; b=Va61nO/WmTexJVzw5KNGNVNOedE3ed5Kfm/qU4I5b1Vu9xyaIl5ia8/awu7zvnEa45RLSTPJUBROcljcuHA5vSOi/ZJc8RjDBTh3osxIR+fXZvbjJCC1w7ZpmTzXbCOuFP6WX5yZBRSkvwaUyTgTupl1+JjBEAknqxAzK55eHXqfaWlHXxJ4HSgdCCNZeMGqp6zKIARj6vSwsFCbviCx7kIH1PgoFPbMFs+49G9AJ2wicQxjpyWg5uoMVG/ohqpgtRXD0wkt9rgapL+HRBpoDK2zdslyV9zZjnbKjNBtaDRBu1jWpWqDa/G5s+ys+CZU/dBfa0SYcO+mAOIDUEeNbw== 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=OOpw9wumMgg40LcpJzhhw6lrd8Hnq4Geo65K0tCzFkc=; b=cz+e6ZWuw9By6KawBbOJtxAGc60OUk84XGTUwdC98TW5JGsQDTNhuzN5vbAGcXxfajeIZQBbc1AbvL+wF/Z/+uy8m2M7lbpZrZtHt0bEHJSf8LIwB004SeyanC26H9rXUy57cd7K9NMbcbUKatPtNRZn9liydk+c5VZS4QhDEZ4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <3c87050e-d153-447c-9eaa-b49a7ab1c75d@citrix.com> Date: Tue, 20 Jan 2026 13:21:04 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Stefano Stabellini Subject: Re: [PATCH 0/2] x86/svm: Add support for Bus Lock Threshold To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0187.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a::31) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MN2PR03MB5149:EE_ X-MS-Office365-Filtering-Correlation-Id: ad91f36a-dcbf-4c21-b076-08de5826c5cf 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?MHo4OGpIakZ6d21rTm5mVVhtTGxrd1RXMTZDTC9BYW56QUs5S1VGUzNBczBR?= =?utf-8?B?Z3prUzRDRHA3eGRRa2p0N0FrNTU4Z28rcDNDczdxb2R6NWhESVpidlcrbEVy?= =?utf-8?B?YWRsa2s2TFU4VHRWdnVkUTRxcmRYMlhDRStVWFRyaXU3ZlVmNE8xbWV3S1dN?= =?utf-8?B?L3Z6MVg2allFaVVoOXlLTE00OTdGdUgwQjRBTEZmM2hnVVhmbkRZMGRocUNk?= =?utf-8?B?K2llTVdZSmpBQXZrRGlZM2hWSTRXZWM3WjNsbS9vVElCbHVBOUFFVTUwZkww?= =?utf-8?B?YVVlWnNsVkVQYTVqejllemwwaklWQzl6bUhhSG51d2VEdXRzeHdYNTBpYTNR?= =?utf-8?B?aUdwUnplQ2dmYlpRZUhxMHE1T3E5ckN4QVdmNXJNL2dsRUVoTm1uZ1NLQTlz?= =?utf-8?B?SzZrTXNRM09VZXM0UFNicnNoZ1JPQ3d1eWRlWm9Mc0hWaitHVmpiUkZMOUxq?= =?utf-8?B?U0JSTHE5YitjdUJheEM0WEpoUVRNTGRqZTJpeEwrUjZ4TGdMR2piUGVKOXp2?= =?utf-8?B?TzFsZTIzVmQ4TXpkLytGSzRTOHc4Qms3UWlqZ3ZXQzdKK0dRSytKWktkRTgx?= =?utf-8?B?WHFpcldtYmhDUXNlSTJPMXVFbDdCeHZWZEtrblZUQit1ZEFOTitvcXphNUlL?= =?utf-8?B?R3RPTGRVSGJodWM1SGtMcHJYcnRmTVlyUER6NDRGeVMrcnhqV0NxTjZGN09F?= =?utf-8?B?Q1Q2cFNTZXlkYWxtSHVTWjRoeUMza3pqRkRXWnNuK1lEdlorR2RITENpSmc0?= =?utf-8?B?cVJEdGZFN0JXak1SSmJMQWtGalBaanRiMVVHUEhRV09iNmpHTXExc3hveG5i?= =?utf-8?B?enBqMWFwemNoT25Ib3ZhYkdWUjYwMC9sWCttV3V5LzRQQkRsMXV1cW56eXpx?= =?utf-8?B?bmhMWkZQQTg3SDk3YklrTy9sWk5ZR0tUUG1SZEJQZUsydHg0WkFMZHl2eW1t?= =?utf-8?B?SHQwcTFtT3NNcitvV0FYL0doSzYwbS9YekRwaW5ZOVRoUWd3dHhXQWRrZ2hC?= =?utf-8?B?VmxnWFNWSW9pZ08vaFpqVURlZm9NQjdja28xTXdQcW5LZ0R0NU1UcFlvcUJp?= =?utf-8?B?N2c5Z0N3VWVVNDd3QjNLYTVINjl1NEhYUjIxMDRwWmt4TlZGendxdXp0UjB4?= =?utf-8?B?dDRsM000SDhxVVhucDljSDVCZ01temhkQlFBTnJBdWlSRTNwL0lLekp2dXk0?= =?utf-8?B?Nm5IOU0xVm1VcHdMRUV4YnJHM2tudVNDckpXZkVHVDJSTFphRkM0dEV2OXNB?= =?utf-8?B?Q3pmWFlRU2swUzA4RUtYSmlvaDBqSXU3T2tOeTJKZEh6UEMwZytmUk0vMWZF?= =?utf-8?B?RkhhakNnK01STmZkTUNleHphSU1kNXJTTDhuVy9aV2ZVQXk2azNsa01HMEpD?= =?utf-8?B?LytmYU5RcE9URmxQTEFUTDNOSElEeDJ4emtHcmt6dEFCOFpYYVFtRE5IRkQx?= =?utf-8?B?VkpkTVk1QlVKaVgwYkhZQTh6dTR3c2Zyayt2WUNQTnFBcEI3SEtwVEhQVkND?= =?utf-8?B?RTZYWU9rT2cyVG5rOWVxRWU4KzA2UmJDZDBDMW1hNFh3dThmVlZFK1VVUnRk?= =?utf-8?B?TW4yUTBteUNHd0piWnRWekVzbW5rRTNkQW9aZ0lzRUdoSDd2aDN1cVhBblEw?= =?utf-8?B?eS9FMWIrelEzQjVZdFQ5TVpFU2FEUGJtbS9zcnNhK2d0ZmIxclhsUE1HeUto?= =?utf-8?B?NkdxeCtNaW5IcmlzY0F2b095MDFTSTNPeG9pNHlhMmtnbUhVY3pDMkprRXhE?= =?utf-8?B?R3llMUEvK2RjRFZRZDZwSmptK3NtL1d0TEV3cDZpRmFIWUJSTnJmeURkL0VJ?= =?utf-8?B?ODlYckRIRVgzOHVnZEplemdIZGt0clN1V2ljNFo1dVdNTE9vVDhCTGhlczFH?= =?utf-8?B?Njlrd3pDbTZZY0RZTmRjb1VmNkk0anhHQ1lyeTdaQ3MrR2VoQnZNMEs0cDdW?= =?utf-8?B?ZmJSNmorWEM4MS9mUWtYTER6bVVQSjlkRHBBT0Q2eHpiZG9NbVo2ZXVNUVdH?= =?utf-8?B?SjN5c3FVYiszMWJ0U0h1dnBpKzdQRUU3ZmlJU0tIbnZEUC9nWlkzMWZrOXJt?= =?utf-8?B?eHdBYm9VUEx4SlZwam5EWVZ1UUplM2FEVVRacFFTV2I5RzVzbGZjY2E2NEVM?= =?utf-8?Q?xaTU=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZkllQzFQVEhYSUdIZzNCUkY2RDhkemo1S0dkcGRuR0ZYcmJWM2w4V2tUMm4r?= =?utf-8?B?dTZUeDlJekNCVnJScGowVis0d01mUjhNd1o3RG12blVJN0VNSTRjUTJFeTNa?= =?utf-8?B?eW9ZdEZVdlZjUXhCSlE0TDJjRG1NNnNPeG1DMGNVOGIrTHE4L1ltbHRlQnZa?= =?utf-8?B?SlNXaSt5WHpzOU1wazZLUHYvd2MycVlVVUd1aFVPOUNBaThkVlpaY3NFc244?= =?utf-8?B?dGhGTDMxYWZvSU1iZkFJSlJucVo3dEVneks5dkpUSXUralF2RFozNFpXVGo5?= =?utf-8?B?TkUzZW5ndDZicm93ODZFeGN1VDhFU0xvVitRbldqdXRjK281VG5HeXptQVdJ?= =?utf-8?B?VnJGMzdJYzBJNnpQbXBwVVJsbWM1cVd4YVFJSDFiY2NUZXlZdG5kb3AzeFFo?= =?utf-8?B?dnJDQWFYdkNyVVBpQVdEcTBzenV1dTI4eHhHdERESFg1eEVlbHo3SU9JWTc0?= =?utf-8?B?NHNhaXJneHc4dEZZSlc5QW1FZ1JkNmVjZ2wyTTBRY3puSmJIZGJmYnlUaWVw?= =?utf-8?B?ejI2cnczYzBDU1RyL2J2eWhZdUZMdmZ4dXM0UzNzRWJ6dWhpdkxWYTZFdmll?= =?utf-8?B?RUt4SUpaci9XL25GTjUvdUNFVFM0VE1Kalh2OTR5YkxXcVZYSTdIY21MaHIy?= =?utf-8?B?M1VVUUw3VjNoa1J6eE9uc0QvQnZjLzh2ODkzVUhncWtsRitRTytkSjV5cDQ5?= =?utf-8?B?cnZ1TzlXYTFJQko0Nmtmc0U2a2cxNDVoU0MvN0pTY2t3WXA0NkR5VGZGWDBs?= =?utf-8?B?WkFTZ3FMdFlWNHZTUW9VcXgxamQrQkJzYWV2VURtWld3QXN2QktUYyt1c3A3?= =?utf-8?B?T3RLUGRURFEzM3gySm12RGs3d21iUmQ5NkVQRi9QRm1nNU1UNjNrdEdOZXI4?= =?utf-8?B?WkZBc1VoY0VIU2drVmtJeFBPVkY5eXZML0xDVjY2SHk3WWNmWVF1N0FPOTM0?= =?utf-8?B?LzYwR3ZIcGh2ZjJuQ1E1Rks0NTE2SmVObXpMWU8yamhsUUljdm5OMkhrVGZ3?= =?utf-8?B?L0kwR2Z6ZENqL1d0TjNtWDh4U1JTSVZBeTQrejZDRXlPYmVacmNIVnF5WVgv?= =?utf-8?B?RUo2WGdRRzRwZThKRVRNTEFrZGRraUFtS2JUeEYwWUI2T0J0WkNGRmxvWEN0?= =?utf-8?B?S3Y2ZDVldU96ZUZRRFc0dlpzUDdnR3pQNjlLd3JHcE14WGc4WUlRMU55c1Bk?= =?utf-8?B?MzZqNDhUREc5WVlQOEZWOURMalhJc3FidnJPbmlqb3BpeVY5aWNCQVpDMG1Y?= =?utf-8?B?MEVSeHQ4c25JUVc3djhkNkJ1Mm9lbERuUERPbG1jVnR6bzRWL2NSVDdST0pX?= =?utf-8?B?aGV3cTVmQm9ERFdzZnMrR0w2WlZUQlU5UXNWSmxLbWVuU2pIdkdOdDRmcWFY?= =?utf-8?B?Njc3QVplODNuY2p4ZVYzQkRYSFpqNWRnU2ZNVFhiZWlEcEI1WjZhSERtZ3I0?= =?utf-8?B?Q3VRTkRaL1Q5NzFaU2QybnVsK2NGY2MrYkU2YTZLWEtwMzlPMy93UWJzd29x?= =?utf-8?B?Q3dsRWZ0MWxKU3Uzdy8weDRBcC9yQy8vWkpUdGpGR0pLM3g0alFLckdzTVVG?= =?utf-8?B?V2JwMFc2cHhMUnNzOCs4SUo5dFpQYStPVnR5TlZaT1lwL1BWd3NySHAyeXZm?= =?utf-8?B?MFZ3SUdEWkhXeUtva1hlMml6azY2djhaQ0ZmMUpIQTEwQk1HM28zK0g5aGR5?= =?utf-8?B?RVMzK1lSOFYzN1FmZVR2U2ttaFIyYWZsVkY4Qnhnc0xvUVlocWo1OXo0d0ov?= =?utf-8?B?V2VVbW1kYkpWWGNjRWs5UGo5OEI4VWZTWUVYaWQ3eXZkc0xSRElac3hqdjNp?= =?utf-8?B?c3VnWkRNSTRCeEZ3WGhydEEzTXpiM1dFVThFcFd6dFA4eUdEV0tsTnMrd3dr?= =?utf-8?B?Q2V2OFFaK3NBUW5kSmlyMlV5b0xPb0tIU1VZTTM1c2h5NmVGNmlNNmRVMEtQ?= =?utf-8?B?Q2NqVytEOGEvMnpsRC80aWVnbDVUR1dXZ1AyNDhENEVnMmtFcml1OUlKOFRz?= =?utf-8?B?RnJRTElWV2VTMml3YXlNZTlmWWFrM0UwWmxPT1VwY0tobVVjMkJkcEw4ODdp?= =?utf-8?B?WllWbEVpdHkxQ3lhZnVhU21ORFU0WjN3anFsRUN1TkQ0WmJQSGo1dFdOVDgr?= =?utf-8?B?eFVhVklkN3J0YStaUEMvL0JjY1dISW9yT0Q4UmgycEV5UXJDRlBEMlhzSTBo?= =?utf-8?B?cXlYV1BDWldtUnpkTGZ1RElYejUyU2xGR0xCNy9icExlVTUybituRDdZSHc3?= =?utf-8?B?K3piWUlZcWJmc3VENmpyNWRxVWk4MmdHOVhWb2lOcG56dzFPNEhxcWhGYjF4?= =?utf-8?B?Q3R2ME9yQjJSbitiUVF4S2Q2L0JWVW0xWjZLYUVBWEYzSHIvUlFtWHc1TnhV?= =?utf-8?Q?QN+iscb/jWlykr1g=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ad91f36a-dcbf-4c21-b076-08de5826c5cf X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 13:21:08.4576 (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: iOj88jaRbFeOcFz38kfU0lRpLX91BHoQdlo4W9cGs6tbp8T3YnUxdcw2byHzr169NgoeLWXeKqtrHbOOCutu29ETfRKCJobsKyGSPWjyRXE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR03MB5149 On 20/01/2026 11:22 am, Alejandro Vallejo wrote: > On Tue Jan 20, 2026 at 10:53 AM CET, Alejandro Vallejo wrote: >> Bus Locks are very costly and a VM left unchecked spamming instructions that >> lock the memory bus (e.g: unaligned atomic CAS) makes system perf take a >> nosedive. This patch is similar to BLD of VMX, but for SVM. It configures all >> VMRUNs so they automatically exit at the first encounter of a buslock event, >> effectively rate-limiting them. > Does this warrant an entry in the CHANGELOG? The Intel side got one (back in 4.18 and in the section about Sapphire Rapids). ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 20 13:27:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 13:27:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208918.1521044 (Exim 4.92) (envelope-from ) id 1viBlB-0005wq-Pt; Tue, 20 Jan 2026 13:27:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208918.1521044; Tue, 20 Jan 2026 13:27:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viBlB-0005wj-NC; Tue, 20 Jan 2026 13:27:05 +0000 Received: by outflank-mailman (input) for mailman id 1208918; Tue, 20 Jan 2026 13:27: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 1viBlB-0005wd-04 for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 13:27:05 +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 b53c0346-f603-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 14:27:03 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-47ee3a63300so50799205e9.2 for ; Tue, 20 Jan 2026 05:27:03 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4801e8c05c3sm242097895e9.11.2026.01.20.05.27.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jan 2026 05:27:02 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b53c0346-f603-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768915623; x=1769520423; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=ro5fZMz1QFlYEX9GcN9zu5ztXhQFBw1ixLnJ/d8V9y8=; b=ayVep8E1LCVrhz/yc++D/Vb5/ccHESOqr5rvt7qA7LAGjLKbaBZQtFVffk42OOYetj BjKc6WyoQP0uJbGJRVohUrWkcPQtoO2ivRScPjnoYwySlZ1fcfMS9Eg+m3XLWwD3FgHQ /nJGxYhnw+JTDkVYkmcxz4PN0evNNJmgiHgk6EcKsPWpLMykZQeL2roA59d4Bh4WM+gH 3/aLD8Ozi0h1g9dpzlgURZZnkXbrVXv6j/OwbWNPJlByeP50QKwb/geJIWuUX/92X1Jn 7IbNR8wXYUgylimJljTQL+Z9Loc6/8vyDK2GOF5UbeaEKYHxbLzCRhUXNAOFWA/QoB+k 1vXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768915623; x=1769520423; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ro5fZMz1QFlYEX9GcN9zu5ztXhQFBw1ixLnJ/d8V9y8=; b=Cx3X6J2cW+rfbG1M9holE+JZ5Tad6X4gp7LiALyENCR9hK/oufRbBl3Uq4lyJ4lbn+ eOV7i+sA5QilfKK+L6Yxe2mjRtUcJX9dJlO7sv5VmuEPV5PIIfYW50gDptHWtNcHAfk4 i5WyDgG0Aa0/FCXptqRTKfIQra0MNn7RnmBmLgC3RUgZ9rnzqHQV1+mTr+67PlyFENYw DhxziXn0VOjQbiJOnymhVFJkMvgCNm2vXk41KOCKDAwmyhkeijl03zHNNuOUQ/IQ/a5o D+S9y/rbqQyccc3/ynmULzqzaSg47dFd7YJkQ/p2q/3/gS65+zByUPU2/8ChzaV/WvNN k74Q== X-Forwarded-Encrypted: i=1; AJvYcCXTe5pJt1SC+9QG/cjSHQ3ehEApWrCo8JII3ePTkMJZtoYkC0MrSQCQIqJSVAbNrfikcC3jlYeJQuM=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw8BAVdMnr5itBJLDNUVJbGEV8iX1uFkDeRXKkMXWWEZslZL5xe sP5YUwGyWVq6Go1/wxIggg2ckqJBShrVpA7m777vFLgk/6UIx8EPQhRkrjmdE/mmZg== X-Gm-Gg: AY/fxX6z1OtNTuofqhsoD938/uXO+tslY7WnFFnlpRc4CCGNOJarZwLghpRiFm/0eUq SrAZRW3bQcBOHIm0DqV2EU+HEn57exhU1h/5oC4XfW24TYqnzhLM26JbN+3odMwW3G05vBT2RmG zdqO0ggqqQFE2CJ4FQxwPJiNbzgE1UsQKhapqEcXXkmzwDbzfSMCEUD8ZDyvPgkFxuyjqz2FxeK 7WNBzaenlZ4izeYOic3LNRGKgzm5Zty9d96CJMGTcQ9s8DZIHzb5LKo2p9OvxqU1kceGp0wos31 wXmcew9QUDyPZD9ZYw29Cy7jQ9O48Y+D6CfJJg0WtX14DHlo8ezSDuwjbK09Yb2FB0jowO6QOF6 mykDJKp9DqQ44IaYR3NoIqPDT1nTpvqyqbPZ+4Nq6KdwGkzuJJl9WADdi4jxfXH7WhfqBqAwie6 ayjzSFuNEt4q4GeRLn2WJzafaQwuCq2jd7bvjHEADZNWy0cBHQh7u5G7BW4jN+cBXqaO3/7cvhf HQ= X-Received: by 2002:a05:600c:4ecd:b0:477:6e02:54a5 with SMTP id 5b1f17b1804b1-4803e7e7c57mr22395545e9.18.1768915623054; Tue, 20 Jan 2026 05:27:03 -0800 (PST) Message-ID: <00f36b33-65d5-4681-84d5-e1b2cbd8830d@suse.com> Date: Tue, 20 Jan 2026 14:27:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] x86/svm: Intercept Bus Locks for HVM guests To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Alejandro Vallejo , xen-devel@lists.xenproject.org, Stefano Stabellini References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> <20260120095353.2778-3-alejandro.garciavallejo@amd.com> <5a4aa1d9-dafb-453c-bd4c-8da860519f01@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: <5a4aa1d9-dafb-453c-bd4c-8da860519f01@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 20.01.2026 14:18, Andrew Cooper wrote: > On 20/01/2026 9:53 am, Alejandro Vallejo wrote: >> --- a/xen/arch/x86/hvm/svm/vmcb.c >> +++ b/xen/arch/x86/hvm/svm/vmcb.c >> @@ -66,6 +66,12 @@ static int construct_vmcb(struct vcpu *v) >> GENERAL2_INTERCEPT_XSETBV | GENERAL2_INTERCEPT_ICEBP | >> GENERAL2_INTERCEPT_RDPRU; >> >> + if ( cpu_has_bus_lock_thresh ) >> + { >> + vmcb->_general3_intercepts = GENERAL3_INTERCEPT_BUS_LOCK_THRESH; > > |= > >> + vmcb->bus_lock_thresh = 1; /* trigger immediately */ > > Really?  The APM states: > > On processors that support Bus Lock Threshold (indicated by CPUID > Fn8000_000A_EDX[29] BusLockThreshold=1), the VMCB provides a Bus Lock > Threshold enable bit and an unsigned 16-bit Bus Lock Threshold count. On > VMRUN, this value is loaded into an internal count register. Before the > processor executes a bus lock in the guest, it checks the value of this > register. If the value is greater than 0, the processor executes the bus > lock successfully and decrements the count. If the value is 0, the bus > lock is not executed and a #VMEXIT to the VMM is taken. > > So according to the APM, setting the count to 1 will permit one bus lock > then exit (fault style) immediately before the next.  This also says > that a count of 0 is a legal state. But then you'd livelock the guest as soon as it uses a bus lock. Are you suggesting to set to 1 in response to a bus lock exit, and keep at 0 at all other times? Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 20 13:29:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 13:29:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208927.1521055 (Exim 4.92) (envelope-from ) id 1viBnM-0006pv-5V; Tue, 20 Jan 2026 13:29:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208927.1521055; Tue, 20 Jan 2026 13:29:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viBnM-0006po-1V; Tue, 20 Jan 2026 13:29:20 +0000 Received: by outflank-mailman (input) for mailman id 1208927; Tue, 20 Jan 2026 13: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 1viBnK-0006pi-M8 for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 13:29:18 +0000 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [2a00:1450:4864:20::32c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 045a74aa-f604-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 14:29:16 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-47d6a1f08bbso19136125e9.2 for ; Tue, 20 Jan 2026 05:29:16 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47f4289b7aasm309353185e9.2.2026.01.20.05.29.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jan 2026 05:29:15 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 045a74aa-f604-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768915756; x=1769520556; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=T0/E/8/PFiDDA3wDagPkrKF0rtZHrQpHDuwXfKVvmKE=; b=XVTD0cSrMfZQc02xbBTaROejPv5zaildzGkbh6g51sCeLNwhMV0S8r5yanpMtHQdKC hRFax9oAnPKZ2gtQDyKUr/HNvYCVQh6b76KezeDM14SvxJ4FNTSvJr2zKBFfQXnH1aDT HcqsX8ETtgHXPphpQXP6fiHimYvbbbZnXgjYLKlkz6vqi6UYaXL2YArKXrLyDB6FHrkS d+vqfiW/0TFnk7gqh/fFzxSugSx/rBnyitaXzkZ40N0IZCDVqV0i/RXP8+01SMHc9oCz Y+h9Og8P3BOKEvQFF8SK/T/gPCuYF6k4/BJEh5obHJlkVQh/Ruf82dXyf0xFIbYLmgBb G9TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768915756; x=1769520556; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=T0/E/8/PFiDDA3wDagPkrKF0rtZHrQpHDuwXfKVvmKE=; b=AiT3DZFZaI1GRE/1AGRaRBN6M0/aW7ziPsDSlbsfo0A+nAiWHN7O4LL7yOW4ecyhh1 lsAEFwsG7/XdYPM5k6HYcNtV+njc+coC+SY9EI1BYRAQGLmcFYGRQUAtD7BA0Pkw6UXv pgcQeUMhCabvw5N5w/bM5ORHmqmXy/lX+u7IAoTv7V8j9wLBZzMhGKRz6ghSobLgoo/d tMOlIHAevTgo6DU12dpN7+rq9aQmw5BsWMWh195R3klPa8UbccWQfjqYB8chDkVWKoiI +E/bzNX3lAeOdOpK6q+nXosWud5h+lmSpOfxs9bf8Kxzmv7MU/FpMQgAFDCYuNzun5AO sHig== X-Forwarded-Encrypted: i=1; AJvYcCV8JZxbPFIAn1mOOVk6I9+G6zH/nBBlCo0Q+nudJ6WqH9u1m6U6/rjE+/K124cJASNpeXQGbXrHZZE=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz2Ku0+ZiXqvQ6iYvMNdFqIW5qxUMr0Pn1oDkWy5QDyWEUX6cwb wXlemO6C4fXhBA7Fbqzl2xGfjHUqSnkvjCTwO8QjIhJchCN8g0cDkpS9cCHBfj4Esg== X-Gm-Gg: AY/fxX6sObP5ZFprF6cYEg4QCuzSgBdfnecHCEi7y9lp9uZ+KpYmjH7yhsZO3inipqH BORrFBwmKJEUmNa57jgQXNoA+YjcKtneKKK6wOaz17/p1Jd+3CqVn2T4/jhRsg4mSKLaoZmTnJP MAVlSl3AejI9va8sCAbB05wrB/ZxuGV0C0zgTMJSPVj5djRWCeatHSdbJSR9Ik1Y/+sNtUf/eXV 2/Z9eUw6DhnxRVlWtGRUfPkZXM7EpLhEBWAgrFxaOG9knYdpW6lEDC6R+rFmYLTsUzNI8zJYHWv WxOqCM3cYCcdurW4EoZHsbp/WXpfGGtJulD8/SHndfwwHqYpzlrxltPuTirzdcUdb4KkWUe749W PX7riGZ013C843jbSBQnxVgn+erN+cVXvfyuVumrZsIwpnpks82RA0GyUAJwYfUmwFUCvMW6F0T pxkhKA+dhrnY26x8V7qUrKL+S7MDsz5u5HGDT/PW2Ruc18w8L9BdY8fw4HMYr72BOYXcB3ZrNoA J0= X-Received: by 2002:a05:600c:35c3:b0:47a:81b7:9a20 with SMTP id 5b1f17b1804b1-4801eac0617mr193173915e9.9.1768915755735; Tue, 20 Jan 2026 05:29:15 -0800 (PST) Message-ID: Date: Tue, 20 Jan 2026 14:29:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] x86/svm: Intercept Bus Locks for HVM guests To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Stefano Stabellini , Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> <20260120095353.2778-3-alejandro.garciavallejo@amd.com> <5c554703-f7e6-4625-be07-4fc607b2c4b5@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: <5c554703-f7e6-4625-be07-4fc607b2c4b5@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 20.01.2026 14:11, Teddy Astie wrote: > Le 20/01/2026 à 10:56, Alejandro Vallejo a écrit : >> --- a/xen/arch/x86/hvm/svm/vmcb.c >> +++ b/xen/arch/x86/hvm/svm/vmcb.c >> @@ -66,6 +66,12 @@ static int construct_vmcb(struct vcpu *v) >> GENERAL2_INTERCEPT_XSETBV | GENERAL2_INTERCEPT_ICEBP | >> GENERAL2_INTERCEPT_RDPRU; >> >> + if ( cpu_has_bus_lock_thresh ) >> + { >> + vmcb->_general3_intercepts = GENERAL3_INTERCEPT_BUS_LOCK_THRESH; >> + vmcb->bus_lock_thresh = 1; /* trigger immediately */ >> + } >> + >> /* Intercept all debug-register writes. */ >> vmcb->_dr_intercepts = ~0u; >> > > According to APM, > > INTERCEPT_BUS_LOCK_THRESH does > > Intercept bus lock operations when Bus Lock Threshold Counter is 0 > > I assume that when set to 0, we intercept all bus locks, so if set to 1, > every 2 bus lock (since we first go from 1 to 0, then at 0 we intercept > the next one) ? > > I think we want that to be tunable, as intercepting all bus locks may be > too extreme we probably want to intercept every few ones instead. Otoh bus locks (as opposed to cache locks) would better be rare, or else perhaps such a guest deserves some extra slowing down? Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 20 13:29:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 13:29:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208938.1521064 (Exim 4.92) (envelope-from ) id 1viBny-0007MW-GM; Tue, 20 Jan 2026 13:29:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208938.1521064; Tue, 20 Jan 2026 13: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 1viBny-0007ML-Dh; Tue, 20 Jan 2026 13:29:58 +0000 Received: by outflank-mailman (input) for mailman id 1208938; Tue, 20 Jan 2026 13:29: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 1viBnx-00076a-9Q for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 13:29: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 1b8bc0f4-f604-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 14:29:56 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by PH0PR03MB5814.namprd03.prod.outlook.com (2603:10b6:510:38::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.11; Tue, 20 Jan 2026 13:29:53 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Tue, 20 Jan 2026 13:29: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: 1b8bc0f4-f604-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qDpmRyx658HqU2LHnhPkEc15jkUVrFkywiqJl3ZbzMssHbnF0B3w08DJesCIA8mgRiCye2duMbkGMSbjpBScGktqg85kcp3PJqBckxuRYrbQPQPNz7QvtbMyLWZUHDU0CXFw+UPToT+dmOaRdQuLrml6FIJ5JK1ejZwANU6Kzf9+FdRc46LW50a/cRCgyZCKUTeG6THoI6LWaO3ORARfg1m79RtGjeeoXcpLMpv78JHMC473gcE7HwtcNDIVRUbe9gQs+4eRDvR2c3G1bqzGPa8noxk49+UNcy142PFw0sbtaE09Hu4sXJIcE21R+C1RMLFVqfv4LwWpV3UlWL04ew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=c3KrVPRaIiECjYbYSaGxk2ViYhhaRcd18ddTvf/i5ko=; b=wizV+IlqfLslykvbRpH2DMwe/wTVkAwEpq1apKCVDIACG7Kb6ggk334tQVRj84i3N3/lyUdE7HqSCyWVC2f9Gn9HCe/LP3wUIG8zNksTnS40DMwVgdwnvhtH6so/uFm5XXpAKhg4wDkfLyblcqIlf8S9kRorS4sovhkPNy0OlWl9QdHOC05whx1lpOvS1SpgLNgl2fD86ATRf1TBrPDx0iEVCKFfg+tNIKOyGLnIhfdk4nwAo+5wos4+jkpRk+pALawyWjZXZdXCR7Ruy6yIoopd88J9qekLQsf847VsuYj7Qid0aRpUu17WNmCQxQIeNaNO2ZdBMKaagcCIRHn8RQ== 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=c3KrVPRaIiECjYbYSaGxk2ViYhhaRcd18ddTvf/i5ko=; b=J+VEdOb/HWyW9XJX4/nbMrTAiHgQuS+TRz0zP/BhqL2GB8x1j3Rz+lQydQiNco9zGZ1Zg82r+cSfgQU+0fFGOdeYaFYjew/4mO0kY1PSRf8JKBTnlpwCOldlFW5tiCDNMUWNjjUirccPDbqZRxfWf0w3wwT+dRtF0wXej2igzpo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Tue, 20 Jan 2026 13:29:49 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Alejandro Vallejo , xen-devel@lists.xenproject.org, Stefano Stabellini Subject: Re: [PATCH 2/2] x86/svm: Intercept Bus Locks for HVM guests To: Jan Beulich References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> <20260120095353.2778-3-alejandro.garciavallejo@amd.com> <5a4aa1d9-dafb-453c-bd4c-8da860519f01@citrix.com> <00f36b33-65d5-4681-84d5-e1b2cbd8830d@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <00f36b33-65d5-4681-84d5-e1b2cbd8830d@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0046.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2ac::20) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PH0PR03MB5814:EE_ X-MS-Office365-Filtering-Correlation-Id: 063e26b3-d214-418c-c7fa-08de5827fe7f 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?VFFmTGxvVXVwc1NlRUVIZ1ZhNkh3NS8vWkc0MVI0N1d1aEswSXNVdHFxbXU4?= =?utf-8?B?WmRyeTZXbkxLaHlOTG1qV1J5MmxvRFZGSkhsc1F5NDZjVGZMMUYxTU16MXYy?= =?utf-8?B?YTFkdStFS0xoenlvRTdHQm9CU1dRTUlObnNnbzVKcXg4c09yQTVaeDZ3d2hi?= =?utf-8?B?VGNBcnFWOW5FdEcvQmlxaDlNYndZVXN4RE56ZXY1V2NBSnhORnVpeEUyZGly?= =?utf-8?B?VmhDSmtERjE2dmxkZVkydmV6bHN5b3hYRXFTWnZ0bnZSZkg4S1Q3TlExbUdu?= =?utf-8?B?dURFeGF2cm56QzN4Zk9DUVB3bWRIUXRPTEFPQ3V0bytsaWNHV2g4OTg0cVNO?= =?utf-8?B?TFc4SGNqMXE3WExUVEM1ZUI4dHBSYlNMMC9keG91NFJ1NlY5aTdjNWl3T2ox?= =?utf-8?B?TS9nRmNHZmJGSHRCYU5ERjNWb01SRzVCdjBBVS9hcmFNVEtJTmMwRFkzY3pM?= =?utf-8?B?NTdXL3NrT0tSM3BEYk13N216a2pxL1JTSGx1dWc4dC9ZRVZDMDJqdmJCdUhB?= =?utf-8?B?aHFoT3RwOVNmbVVDblg3dFBwcWU0ZHVCVmhCZE9QcHhHTUVPWmtqZWxHUXBE?= =?utf-8?B?eW1FRHJPeGFBc1hwUElxTE9QNDZzWjkzNExpa09DenBISXBrQ3dNcDhHMkxG?= =?utf-8?B?M3AyVEttN2NsS3lQS0ZZcFhzSjFkRzFRclRWQnN5SVVWbXhYd0NkT3Fwb0hM?= =?utf-8?B?T0QrMUxtWU9iVDlodWcvK0xiWU9mQldwam94NEZST2xQWVo1UVhVUnFjdm5V?= =?utf-8?B?SWd5L3JjWEF6VjM0dGIzOWQwaGo0d3lndHZ2UWVnL2IrMEt1QVcxQmh6MzBW?= =?utf-8?B?U1l4VWYzZDRHYTNZdHEzUHZPR2NReCs5Mkorb1BUOGtOSU1BcjJUajRwWEtz?= =?utf-8?B?WS82TjN3WlVCcFdrbnNJbnVsV0pZbnZpUXo1bmJnKzgrRlZTbXJ5QzBUOUhB?= =?utf-8?B?TGFyQnNhdXBWdndwSFhQL0dZcHd6Um4rUFlDeWErOXBNMHFPbnZsbFd6U2x4?= =?utf-8?B?WFBwZDBubWZMUG9ZZ0hrMGxQbjRTQnZBUklnc3VRK2J0a3RiZTBrcjBSNXZ4?= =?utf-8?B?a2d0QkJVNjhaenJsZmYwV1JPS01BL3JJeUZuSndkR1JKSUt6OXQxYVl3OHB3?= =?utf-8?B?NDVISnF0RGJ5bk5FM0s1WjZUbFNjQXQvSzhpL2wwZnJiTm84Ty9TVnQzSnVF?= =?utf-8?B?U3BtUGNmM1krYWs0aENxQzkrSUNseFMvRkxveGxld09MaWdDNWxhVVZRaWdP?= =?utf-8?B?bDdlTFZaNmJrWnlJNjZCeXFCbDYvd3VoREpmRmIzU0YydEhFc01YRHV4b09V?= =?utf-8?B?aDdRSW5kY0lBMWkzWWt0UE9LS0xUenplZGVJV1FoSGVhcUlFeTFIUS91OW94?= =?utf-8?B?Y3oyVXVLbE1iTElSVXMwTmZqQk9lWUgralF5d1NpajZXODZ1czljSzkwYkIz?= =?utf-8?B?ak5HTGlpZXM1Tk5oNVoyOVBtRXZPTFp3YkFoYzdlYldEajRIVE5mcUVkR1ho?= =?utf-8?B?cWZSZ0lOV000NUVyT2MwS3NWMmdOczI5ZVp3cE5tK05yamZJNWVYb28rcFly?= =?utf-8?B?L3FZU0NvWldoSTJGYk9Hb1dRRmV4R2ptRlF3SWEzcmYvYWRJaDNFU2d3ZHZJ?= =?utf-8?B?LzVLZmJNNUVQWmduMi9ycUxPV1NOSUJiOUY4V3VOVE5TVE1WTWo1OGVFb0wz?= =?utf-8?B?ZUdHRDZ6MXhOSnZyVCtDZWxucE0wdFU1S0dHZ1hnY25vRWlEOWpTa2t2MnMw?= =?utf-8?B?TTNPcUIyL1N5WXllRFhlR243SVB3djg0aGx2TnI0R082NWdDWGdQa2NQRFk5?= =?utf-8?B?ckNTMklCQ1lnbnFSdmV0QWExWStVUVJqOHhNai9lRXRXQ0ZCb3RHYXQzbFI2?= =?utf-8?B?TGNIOHN3ai9hRS9OUEpRT2oxeXFYTTZxVGcvQjB3dXVoRURwTXFIbXpnMmk3?= =?utf-8?B?TENUZ2NONFBPM0JYMTdVWXZRRml6TWxuU2MyUUY5aUZRMEhJWkgzTUtZRy9X?= =?utf-8?B?MVl2ckNVS084cXpISDBYRENjOENnY0FBWEFDRDJRVWtUaUllcTFiNWlCZFY3?= =?utf-8?B?cmRJYWtzTytqcndXVis3cXI4NXRiWUo1cDlVQTJmTy9WaG8xNUJPYlNadnk0?= =?utf-8?Q?E6no=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dzdOcWpjK2JjUld3WUZlVHNLNHFJaXFlSzVPODFtQnpRZ1BOdU9qQVJsSDNN?= =?utf-8?B?cm4yNFlteEZpbjJGY1N0bmNQSkFsTEw3TkJCc3FWZTZtTUVFUGRoY2hGbklU?= =?utf-8?B?a3VRRUV4c1UrdUVUb3YxTTY4bjZWMFBvM2JheDB5US9PbEdsTGtUcEFpT3pB?= =?utf-8?B?NURqYWVzSmYzeElrcnNWZDdOTmdpQzlXbzBsODlEWXBrSDZJejBENWtnc00v?= =?utf-8?B?ay8wK0xvaWYyQ25vOGlIQlpDMjU5dEZLODVaRTRSQlZhbWdtN25ad1phZjhs?= =?utf-8?B?Wks5S1J0TTNUWDZsc2VMbHhmYnNlOHY2SmlHRitrajRxRDBETzNsOStvQ2FI?= =?utf-8?B?dkJpbU9PcGdQNDQ0bndSd3ZmZm9YWVVXNHJ6TU5SaXRMTzhqc1EvT0RRSVpC?= =?utf-8?B?K2Jza2VVOS9GVFlDbEVpYVNRZjhuVjUwMVU5WDFOOWdEQWhNaU81Y3RSM3Nz?= =?utf-8?B?bTVVYS9XejM2Y0ljbXpTd1htT0ROajk2bkRvUVlUMlUxV0VxeFlyR0J2MldS?= =?utf-8?B?Q3oyY3FiS2pxbWI5MDN0Z3k0dDU2ZTFiRytjb0FpQjdkS1FBVjFMeHI3cG5X?= =?utf-8?B?NTUvTGpNazlFenZXMmhQZWl5MnJUOU8va2thYWNkdzV1WitRaEwycjNIYVRl?= =?utf-8?B?aXlQcDRKelNNMDFlM25WMW10YlI2c282QVVRazZWOTdjV3RWZHYvSUY5dHhQ?= =?utf-8?B?Zi9tQ1VxeU82YTdYU2FubWR4OFlUMXNmcUFzZXJEbzNSN3UzTzhMRHQ2eHNI?= =?utf-8?B?a3BSNGdFdnErQ3RhZk9ibnR3UmNmenYxOVdaeHd0UTR5cVZKTGJ3clpJQUdi?= =?utf-8?B?WkFsSjZINSt6amhXeXdrZytMOUR5UXozQXM1V0IzY2h5aXpMcGVSQi83c1g3?= =?utf-8?B?Umd2dkQrK1dxdjZMdVhzTndXZU1odk5FZnlpMkFxNzFmU3RNaDVGbkgremdw?= =?utf-8?B?cXc2dTJnaVMwQ1dXZUtOY3BObW9oVzlMaytJRWtDcUxOT3YwYnY5dHFKQUpv?= =?utf-8?B?ZWZoM1kvbG9ZSElYaFlzRXhZKzJBcC9JQUJ6ajRiaHN4cU5PSThwdm1pNXhG?= =?utf-8?B?U20vUzZHZCs3VW5IM1E4eHZGeHJIT2h3VEpTVUpxWlVWcVh0NXUvQUQ4VEFy?= =?utf-8?B?ZjdSNy9EdTZ0M0doT1RQcjZhMlJ3eU5JemxDd0dwY3Y0NlJCaTBMTll4ZEV6?= =?utf-8?B?TWhoL2JSZDRZWmY2UHdlZ2RmZVdxeDM2RVJTWFBGclFmOERRRUl5LzZUa25z?= =?utf-8?B?MmR6TSsrVXhuTHJkSWNsNFhiZWhDWFBQdVA3QWVTMWJyKzlYYThhUmduSlNs?= =?utf-8?B?Y1ZmMzk3bG5teHA1NFB3OEJvcVo4QWlNb1A1MkxkTEtVMXhEVllvQjBQMHh1?= =?utf-8?B?MlRwU3hCeUw3NXViLzF4alAxcTY4ZVd1VWZSVWw0WTgrV0dLZkJYajN4cll4?= =?utf-8?B?UzV6ZzQzSjNGYnhaN3FwZ0wvcHFXZ1cxM2M0TU45VzVrbEk0QVFWSGJaekUz?= =?utf-8?B?SG1uNFBjRmFZZVRmWnZXeVVldlcrOU5aL0REREw1c3dSemoxMmRCbTF3ZzZD?= =?utf-8?B?aXoxYmIyNklhTmVFTlBEOTltaGFKamptTGdXUERic2dVSHY0S3V4NDViMmE2?= =?utf-8?B?Y1FqdmsyZklLMzMxQzlTS1d2VFh6OTUwNzhWbDBzNGM2U0E3SlJWL1BJQ3Zo?= =?utf-8?B?dDVUczF6VzFNZHg3KzAxL1UwUWd0dXBaSXg3a1o4eFNtK3h2Rjd0SjJ6UjFy?= =?utf-8?B?NTVvMmJTVlU5QjJ4Y1V5WC8yaGNPL2VRU09OUk1iRzNtQnFsd3RBeXU3MmM2?= =?utf-8?B?NGl1UE5FN0ZJRFBMTW9WRC9SNmVjaGZzRUo5RFJGRmE4SkFhVzdtMkpzVzRN?= =?utf-8?B?OVQzZ1EwV3QxWGRWUHAzbkRLSTBtY0dXeHQ5UjNmaUcrQTB1MGZrellKcVU2?= =?utf-8?B?UVJLclYrTEp4K0xIYVZaakZSc1N1bTdrNldOczUzSU1MV2RwSVZKM2ZTVkV2?= =?utf-8?B?QUh6dzlzc1IwK2MzZ01ZeXZUZ3RLVmd1dzBCNHFWWDVaMkxlZWVwS1l1R2pq?= =?utf-8?B?bWY0dWRHdlNzNUs4anNaYUhnL3NMTHpoWkk2TldiaTY4RU5zMkdsODJPaVNq?= =?utf-8?B?SDNsbEhiRnlkcVVWS2ZENm9KWE4rWmVuNTVCUW1NM2RTbUdqWTNYWkd1clF1?= =?utf-8?B?UlBrWGN6VzRhVjRWWUJoVmxSV3FXeXpHc0p0SEZ2MU1oQkh4Zi9IZ09oaTVm?= =?utf-8?B?OWdvdkQ3VjJtY1JPTm5vL3VPL0ErRy9zbm1jRUhpcFNVblQrTWEyK3RKaXNu?= =?utf-8?B?NWFDQ0dwdDU3cm45ZGhWU09RRTlyZ1RIVXgzVkFLMkwzTVB5N3pOeGRYdVBO?= =?utf-8?Q?rGoE1OhExmK4aBho=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 063e26b3-d214-418c-c7fa-08de5827fe7f X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 13:29:53.1511 (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: 1+e7PCal8BSykJApApseIxTJgok149bl4ECK1s92AOvOfRgOJJQt9OzMqn0z50grnQuIxmGkoH4vykSCLw+wVp5mCyFJeWWI6UiCPz3WjjA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB5814 On 20/01/2026 1:27 pm, Jan Beulich wrote: > On 20.01.2026 14:18, Andrew Cooper wrote: >> On 20/01/2026 9:53 am, Alejandro Vallejo wrote: >>> --- a/xen/arch/x86/hvm/svm/vmcb.c >>> +++ b/xen/arch/x86/hvm/svm/vmcb.c >>> @@ -66,6 +66,12 @@ static int construct_vmcb(struct vcpu *v) >>> GENERAL2_INTERCEPT_XSETBV | GENERAL2_INTERCEPT_ICEBP | >>> GENERAL2_INTERCEPT_RDPRU; >>> >>> + if ( cpu_has_bus_lock_thresh ) >>> + { >>> + vmcb->_general3_intercepts = GENERAL3_INTERCEPT_BUS_LOCK_THRESH; >> |= >> >>> + vmcb->bus_lock_thresh = 1; /* trigger immediately */ >> Really?  The APM states: >> >> On processors that support Bus Lock Threshold (indicated by CPUID >> Fn8000_000A_EDX[29] BusLockThreshold=1), the VMCB provides a Bus Lock >> Threshold enable bit and an unsigned 16-bit Bus Lock Threshold count. On >> VMRUN, this value is loaded into an internal count register. Before the >> processor executes a bus lock in the guest, it checks the value of this >> register. If the value is greater than 0, the processor executes the bus >> lock successfully and decrements the count. If the value is 0, the bus >> lock is not executed and a #VMEXIT to the VMM is taken. >> >> So according to the APM, setting the count to 1 will permit one bus lock >> then exit (fault style) immediately before the next.  This also says >> that a count of 0 is a legal state. > But then you'd livelock the guest as soon as it uses a bus lock. Are you > suggesting to set to 1 in response to a bus lock exit, and keep at 0 at > all other times? I should have been clearer.  I'm complaining at the "trigger immediately" comment, because I don't think that's a correct statement of how hardware behaves. Simply dropping the comment would be ok, but I'd also like to understand hardware behaviour if it differs from what the APM says. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 20 13:30:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 13:30:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208945.1521074 (Exim 4.92) (envelope-from ) id 1viBoJ-0000Gm-Nf; Tue, 20 Jan 2026 13:30:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208945.1521074; Tue, 20 Jan 2026 13:30:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viBoJ-0000Gf-Ku; Tue, 20 Jan 2026 13:30:19 +0000 Received: by outflank-mailman (input) for mailman id 1208945; Tue, 20 Jan 2026 13: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 1viBoH-00009h-Tl for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 13:30:17 +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 28059d8c-f604-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 14:30:16 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-47f3b7ef761so30746255e9.0 for ; Tue, 20 Jan 2026 05:30:16 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47f4b2755absm379579935e9.15.2026.01.20.05.30.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jan 2026 05:30:15 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 28059d8c-f604-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768915815; x=1769520615; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=0w9bDEgrBJjkQxZF/X5ijftacxNzcsqnhAvj6yqc/1E=; b=T3aOxtU/zl4EqicKNw8uVKiB6kvG1SZ57uBL0TMBzwzG70e4TSOq112WEUh39ZHdPH qeHjzGIfkUNBv5HzufP7VVaQLSsD8LHwUrHznBLNbXmFsNrUmgr8nNmXJQ363qxg3Rye Ip2PSXF4Jb0bey8l04bbxY83nI9fVJhKKSxPnHxL/+/P7VeyAZ1fO/l+Rv6u3ABt0IWt vGN34wvJ5RlnWWo2fzZc7S3brCiPZYXOVivuO6bY9Ng+1CAitKWf47/x+Ua2cneBm+FQ ztYzAaCvXc0dKLe5rzTJ1UZ3KSg4uYzoLKbPGTi21EGjeg4l5mo/EJjo4wccTH5RDIgj LrLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768915815; x=1769520615; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0w9bDEgrBJjkQxZF/X5ijftacxNzcsqnhAvj6yqc/1E=; b=Wc6RuOdrP1Zn1k9BrxALq0sTtgYlcnaAdZOOnVy+KoAQzC6khxMRnON+vWpVPZfyWQ K0VmrknGLzBwfF7prYwEXKRr+cyjNVMBzP0AaxdnD26JOuC56+n+iBI2dJmiJMu80fyS hU+aMbh7T7Eb6FwHH28ZW4nXyk1NYf3QIkZH8B6LS1nbcHelH5VpiTv0V2AfO4Tgtqn6 QPymP/v+tsUjhLmi0ZkLEnsMUfO0zU+arMIosROujhA/rqm8clGUa7Boy8ddKwxfzVhC SgeK4+663NkGWybyWLSDGNPYEZr2VArqjU8k2PODSHmW08Q0PngOUToy9h776Ya/Jqit R1Qw== X-Forwarded-Encrypted: i=1; AJvYcCVOSQzfN5zS1PmgVG/ITEUGothUkPuNhUokomM+p89DJ3gSyjtK+DwOTS7pbltDM1KQ/4MyxeeR+yY=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzo+l1LURGT4+sd0XY2YxjDnZXivPLQ3HXPK6ZFav2agJe9Nmi7 sEGhWFbfnG5gCZ0yzyNRJysidJvveFRqvb7DbDzWbP5Dcu6hymEDNt1/LwSeVmhM+g== X-Gm-Gg: AY/fxX6tTR5BTWxeH41CRJRGFkSKXBuOBGrlkqAPBZFLEMKawp01LfplMDbwHFwfhLY M05EUIzYWIY6h0Dnu0Zydei6hOLYeH0Da7itdUg7O7gm6c9ZZRN1dVB1JNGr7VwR9NytYrr8eR0 UYxKY7rZDcPiWdopDFqLO2YSNRhsJrD6R/rTBokfI89OjOdYNQD7gCtP33BkfqFrIgfWZwOy4Ec 44ipSBj+kOtD02qPTdzgLqEqsHmTgd/8S8Wu3rxS0BM6BEPND5OLWrkUQ0MnwgCJrFyLYCv+o8G UomuVnoVfaED+mkXEb0aZPUBmEjWNGjtrbqWtTacC7H/pBTP2XVkd96AU7mxyiMu4ChHFii+spb CMHSCwA+1nOleyty3T//Ypy+PsVl8RHb8rwWNdHnTkQ8NBjwHU2K5PgDmr+xj9M/+MgAyWM/Qcj ODwkcLqAIlzGFkytAUUXP+qkAcnd5YEtrc+hWylNqy+qhISni7q1RckHGA69dBme0CDlPT939qA aM= X-Received: by 2002:a05:600c:4e43:b0:47b:deb9:f8a with SMTP id 5b1f17b1804b1-4803e7f1887mr24181565e9.30.1768915815568; Tue, 20 Jan 2026 05:30:15 -0800 (PST) Message-ID: Date: Tue, 20 Jan 2026 14:30:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] x86/svm: Add infrastructure for Bus Lock Threshold To: Teddy Astie , Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> <20260120095353.2778-2-alejandro.garciavallejo@amd.com> <9097240c-a892-41e8-a686-b89d84d0c03f@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: <9097240c-a892-41e8-a686-b89d84d0c03f@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 20.01.2026 14:19, Teddy Astie wrote: > Le 20/01/2026 à 10:56, Alejandro Vallejo a écrit : >> --- a/xen/arch/x86/hvm/svm/vmcb.h >> +++ b/xen/arch/x86/hvm/svm/vmcb.h >> @@ -65,6 +65,11 @@ enum GenericIntercept2bits >> GENERAL2_INTERCEPT_RDPRU = 1 << 14, >> }; >> >> +/* general 2 intercepts */ > > nit, you want to says general 3 intercepts And then, further nit, also get comment style right. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 20 13:34:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 13:34:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208959.1521086 (Exim 4.92) (envelope-from ) id 1viBsd-0000yc-97; Tue, 20 Jan 2026 13:34:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208959.1521086; Tue, 20 Jan 2026 13:34:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viBsd-0000yV-5P; Tue, 20 Jan 2026 13:34:47 +0000 Received: by outflank-mailman (input) for mailman id 1208959; Tue, 20 Jan 2026 13:34:46 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viBsc-0000yP-S2 for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 13:34:46 +0000 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [2a00:1450:4864:20::32c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c88f307a-f604-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 14:34:45 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-47f3b7ef761so30785565e9.0 for ; Tue, 20 Jan 2026 05:34:45 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4801fe44b37sm102211415e9.12.2026.01.20.05.34.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jan 2026 05:34:44 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c88f307a-f604-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768916085; x=1769520885; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=yh6uUep2v4139MULI5v+0nX6QdvAhnoFj/UdwM/pElg=; b=Z5TH5zL6qjYnS7F0L66RNWZve4srwmPWuhCftvonvJAmmh3GxQWo+X4LjCVls+aO1i d3IgzsqpOQpUigyEpakbbSyxA5An4iTdpDX7HUjk2JawMBcR/sS1+XKPPCls0O15rnZn D1cv1+Re3pp1wFjt4J4xzP/Ma1cPrSDehd/jqp8RFhg50BhkVFiSXuX7rD5/ArwcTysx r5lNleJLzhuseXBhSrGyZ8HO9JQVVDxXyjo5bJ4gaw2R7CFYywvTqscsvrODt4unetq6 CdCF6RhtWT3QKuypbBIpvfqbVneS06PZP07HlJYjH0hpi1QZVzGpl2ED5qF0st/Uaj6r rDMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768916085; x=1769520885; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yh6uUep2v4139MULI5v+0nX6QdvAhnoFj/UdwM/pElg=; b=Oh10pZ5vToM9irEY0RIgX63MdD+x64ubSGzX2X39/pF0OEfDujsqYpyMOQrDQTe7lI zvyD1JXBBi+fqeB339O9/CBhBX69LMuO+MwbV9ZqHRCIcE0WB1eIjRnxQH6dHIbGuboA RFDP51MxQScR+1wVMjQ5xGdjTkyVlNtg6bBaj7/9Mg8slOk6GwSQoswfLuZqd4RU06UW XXGMXXx5PrqRD2x39c52Qp2UBWSePDNQYB6Bkv+/oblsF5NlweiVnXfkQ5gejyreLtIx 8U1voBi03Dq4OUVgEDTZRT1K1LOHPaWxTEtIzqAQYuq/HY6TfSWIj/5CAdIpZkI1dXJF V5gA== X-Forwarded-Encrypted: i=1; AJvYcCXxceqlZdDmcdlHbQLx1yIDUKVTA/Ti2fspgKq2T5tJOD5OoXoGoZn05nEfu2L3g2N9VY4+fnH/suI=@lists.xenproject.org X-Gm-Message-State: AOJu0YzIabXImXkZgwHhovcsqyOTD8LJG36LFM2bd9Nv/q1hsWC0jSuz 2HcmmfR87eujILZw3upwAvhDHXAeo8VAYSGZiVgu3T9FhOy3Owm6D1KoDx88Uu8eFg== X-Gm-Gg: AY/fxX7w+T2mDawDWVykPmkyjnFHypwxG8MKCDLoujZtSqQvqB5KB2eSEACTJIe/aYJ hQ4PH4K2qxhzaBrQEuFNb6OmZ/1ibFJ/aLv9I7c5hA8YvtiagqKVby/KLP5jUNsvya/bZVp16r3 wLzeaeW5EtDIsvNwCXixIHgfoAsDgIcxbfS0RtNfljjSPlP/yqWb2cC2VPRrBr9FrpZTE2iHh0U xIyw5StCZ+Unh1n6oxQtx+m1dOfrICTeMKrnZUiRFuAomYL9+Nla2oYF0aSbBC1dmS2zb6/DqNq n6aBxJqg5AvIE8XDzwN/c0qbSp9wicmcbi8DllIyiwD84RVBS5GutVhlOP93Ro4DrW8Vssxw21g aF4YVTMOLFHYJILuTTub0LQpgIevoJ1LwzFGKqYkS/T8YO8LJUajjRTHMVYn6WQXDdRqU9wNqK2 VoovxhRyJc4dlBt9OW0FcEgRHTBg3yw3SZ0QdOcXGrrsqlMtlHNzN8hgjwj0mXT9Hhrs2Ammk8b Ts= X-Received: by 2002:a05:600c:4e05:b0:45d:d97c:236c with SMTP id 5b1f17b1804b1-480416867d8mr5249075e9.21.1768916084924; Tue, 20 Jan 2026 05:34:44 -0800 (PST) Message-ID: Date: Tue, 20 Jan 2026 14:34:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] x86/svm: Intercept Bus Locks for HVM guests To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Alejandro Vallejo , xen-devel@lists.xenproject.org, Stefano Stabellini References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> <20260120095353.2778-3-alejandro.garciavallejo@amd.com> <5a4aa1d9-dafb-453c-bd4c-8da860519f01@citrix.com> <00f36b33-65d5-4681-84d5-e1b2cbd8830d@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 20.01.2026 14:29, Andrew Cooper wrote: > On 20/01/2026 1:27 pm, Jan Beulich wrote: >> On 20.01.2026 14:18, Andrew Cooper wrote: >>> On 20/01/2026 9:53 am, Alejandro Vallejo wrote: >>>> --- a/xen/arch/x86/hvm/svm/vmcb.c >>>> +++ b/xen/arch/x86/hvm/svm/vmcb.c >>>> @@ -66,6 +66,12 @@ static int construct_vmcb(struct vcpu *v) >>>> GENERAL2_INTERCEPT_XSETBV | GENERAL2_INTERCEPT_ICEBP | >>>> GENERAL2_INTERCEPT_RDPRU; >>>> >>>> + if ( cpu_has_bus_lock_thresh ) >>>> + { >>>> + vmcb->_general3_intercepts = GENERAL3_INTERCEPT_BUS_LOCK_THRESH; >>> |= >>> >>>> + vmcb->bus_lock_thresh = 1; /* trigger immediately */ >>> Really?  The APM states: >>> >>> On processors that support Bus Lock Threshold (indicated by CPUID >>> Fn8000_000A_EDX[29] BusLockThreshold=1), the VMCB provides a Bus Lock >>> Threshold enable bit and an unsigned 16-bit Bus Lock Threshold count. On >>> VMRUN, this value is loaded into an internal count register. Before the >>> processor executes a bus lock in the guest, it checks the value of this >>> register. If the value is greater than 0, the processor executes the bus >>> lock successfully and decrements the count. If the value is 0, the bus >>> lock is not executed and a #VMEXIT to the VMM is taken. >>> >>> So according to the APM, setting the count to 1 will permit one bus lock >>> then exit (fault style) immediately before the next.  This also says >>> that a count of 0 is a legal state. >> But then you'd livelock the guest as soon as it uses a bus lock. Are you >> suggesting to set to 1 in response to a bus lock exit, and keep at 0 at >> all other times? > > I should have been clearer.  I'm complaining at the "trigger > immediately" comment, because I don't think that's a correct statement > of how hardware behaves. In turn I should have looked at the patch itself before commenting. The other setting to 1 is what makes sense, and what ought to prevent a livelock. The one here indeed raises questions. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 20 13:56:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 13:56:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208969.1521095 (Exim 4.92) (envelope-from ) id 1viCDo-0004Qe-0f; Tue, 20 Jan 2026 13:56:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208969.1521095; Tue, 20 Jan 2026 13:56:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viCDn-0004QX-Sv; Tue, 20 Jan 2026 13:56:39 +0000 Received: by outflank-mailman (input) for mailman id 1208969; Tue, 20 Jan 2026 13: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 1viCDm-0004QR-OD for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 13:56:38 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d4962e16-f607-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 14:56:35 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS0PR03MB7251.namprd03.prod.outlook.com (2603:10b6:8:116::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 13:56:28 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Tue, 20 Jan 2026 13:56: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: d4962e16-f607-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UqyCb8CL7N4+KzbhP/4CwJI8nkrpUg4zgJ1/YSOYVcOPqrORJmtWDFSELpk+BsKJRaZ8pnjVmkPYYSQiZkM7TmwTKYmZP8Z4DmZO5oycYTbAF7z4mnJKaPBxf1ZsynmLDtkMXRUEk7ynu5pWNxRnL6jnmOepfdzZ9p5yDA3sf5eQbY+GnG7u5tyf8/AncuLFJt2klT1mRxKm4YLZQcjLqKLSMj6xbZ6km3JmTzQ9gbCg3iLi3jMbVIBRRuhuG/qfzRmTDESYlsUvB1H8lb0v/lbPmxTTIiMlGoEkKdxcGxc/11IDou2yv90hKIzG9NAfFxuFMOWUuPIC9jV0HtbGaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vapi+1mXZ8RzyX51bHKRSTNZbdAe8NhJOKDNADouAs4=; b=RQg6e3qqbGzAKeHhneNw186EEZovXwf1WixqMZfno/GIwPYvGjl/o1sbEYGnwC2iri5ZzFY2rQRNHNWjiTZt+Wu0LsPZAMtTtZxSbTGTNt9Y0kQ8E9L5YQLtRd23wlDMRI9BWoc3GUq7PdlC68PVEEHVAsHSIV7HeRm+4txdWoMGXoMklzVWUhYcusNeA8bbzpnPBmi1qYUpIM+K5Jvvq3EubK9GnIseQjCA3JBV2SMaQceAa76PPYJprL7EaIq6HZxs2dzs72yWrtu3kUMFlmVbY/CqvCTSq/MLVRKiwbq2GDqqiMy4/Y4jD42Lm7F7rROeqG0e9ls/TZDCIaUHeA== 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=vapi+1mXZ8RzyX51bHKRSTNZbdAe8NhJOKDNADouAs4=; b=gD8bGF+qMM/WW1kTwg47ZEVpMuJpChMU/BFMkwSTDIGIdtjMOKQmASOcZZ7EJqqBXlF8RCWYmJ8xt8azTuVzS7BpJYiHU9GbzTUZtxJsTnY2zQa3g1eL1Xbi+H3Y6f3sx99lTbKFlqB22ystGeQrWs3i3etcYdYctS0TlybFwEc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <5e57b6b9-6fe4-49a5-bba0-fdf9e48bbb99@citrix.com> Date: Tue, 20 Jan 2026 13:56:25 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel , Oleksii Kurochko Subject: Re: [PATCH] x86/intel: Drop more cpuid_mask_* infrastructure To: Jan Beulich References: <20260119193901.1354905-1-andrew.cooper3@citrix.com> <14a32e1f-c5ca-4d1c-b54b-c565184bd6e7@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <14a32e1f-c5ca-4d1c-b54b-c565184bd6e7@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0429.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a0::33) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS0PR03MB7251:EE_ X-MS-Office365-Filtering-Correlation-Id: 3db900b7-276d-4bd7-5b4f-08de582bb586 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?cTF1MmRxYldIT0N6Qk1WM2JIekJZMUdpbXJPYi81aEpqNmRuWTJCS01GbFIw?= =?utf-8?B?blNFUlJsVWpkVEdaa0ozM3kydkg2czBpdnM2Snp6ak14YlgzSDdmVGxZRVFk?= =?utf-8?B?RzZUeG5hMlU5K24xOVFYYVlkeTFFZW5XYnFNakZHUVk0Sk1UZTBuVWdvRlA1?= =?utf-8?B?VTg4eU41cjJtQ0lUNHpMQjIxd0I1SnlrbHhDTHFzcDRxK0lPOGlpYVZsbmdu?= =?utf-8?B?UEhrblphd1pnU0V1bUhZNW11Sk5hZDZxUWRFRE4vcHRFL0dmT2d5OVA5VTFE?= =?utf-8?B?VVd0cU1aSFg5V3VoWko0anliOUdBenUweEc0SnRncGpNZERwa01zQ1ZzRzBp?= =?utf-8?B?YUJlRnJuN0t1M09VN1FsSDAyUWRMK0dxUFIyaHdPN3RJcVhzaEtreEE1TnF1?= =?utf-8?B?RTdMQWdwbC9USkk5WGFSajVWZUpNYUhOYzU0R1B4TTJnM0xmYlBXUUMxWkIv?= =?utf-8?B?SFVkeUhTczFzN1VRVGY0S0Z3NW9QSnZRd3UrSVJHSkZVMmdrUEEwNmVYb3dO?= =?utf-8?B?YjQxcjBid2dMTEIxdDVFZU1oMjBmQWFwbjJ0SVpGM0lYRS9ycUdzR0tDQVVh?= =?utf-8?B?SC9WcFd5eDg0ZmVKZlJZU2NtK0tENE5TSTFHMnJSYThQcU5sYk1ET2xGSkxL?= =?utf-8?B?M0NYakpDSmhMMm1pSFcwbTFFb3g5bGEvWVIzUW5vSnZDSllXMlp6WGVyQ1VG?= =?utf-8?B?dE9MeTlKZ1llaEt5SWFpMExYTWt0SW9MYW55Znd5WGVVZ0dBQUo0Wmc0SFlV?= =?utf-8?B?TVNGM0s1ZjRIMkZWVDFZbHdSUzFKaVVDUENoSGN4ODFqTTFsN0VLTG5MTWRF?= =?utf-8?B?TnZYelhEbnRiQnBsUTBHTUQ2MTQrR0R5TkNKcUI1enZSamhyZGV3MDVrTmhR?= =?utf-8?B?TjlodlN3OXdsdXV2UWV1RkIraFN4dHlSc0kyZVFTVFZ0ZDhtcGcvTk1yQkwz?= =?utf-8?B?SmFyUWIzWkZrUmZKaFdvOTJ1MEwwdllKdFhYUnM1OU1sR3p3TkpZRFdMbmdS?= =?utf-8?B?SlpDMWt1blhSd3BOREdxYXZadExid1daaFdWbmdpVWdWNHFNZ1paaVFKZGpT?= =?utf-8?B?bzhGMHl0VGJKSlNFaGc2T2g5UTUzbmNKUUkwUlNzWTM5cWpSOHZNVXZ5Wmp2?= =?utf-8?B?NTZVbkF5T3krRjdVa2E2MDczUkZLczZlOEc2Qzk2NmkyN1BGeWNHYUd6eDNL?= =?utf-8?B?NVBYZ2RiZlZ2Y0l3bVNUUDFtb2w4R2d5WHU4ZTUxcThWbkh0S0dPLzhuK045?= =?utf-8?B?MHhIM2szVkhBLzBTaDlmMXdxdUc4UWJLZk1mYUoyN2F1Z21ndWpXZjhCdkN1?= =?utf-8?B?V3NOTEZ0WWUwaUtCNzY5RUFvRWg5SVNTM2oxZ2RFNHB5WE5VV0tTa21NSVVu?= =?utf-8?B?OFhBaXphd3paVUp3VitBbE56eFJkcVhGTCtMbTcyOUlId1VHQjI0M0xDaWVU?= =?utf-8?B?RldmaVFkNGNkblRIa0tKYmhjcGxtL2EwSERoYVJxRjRoWTJRS1ZRNEpMUG9K?= =?utf-8?B?dVpzL0ZMOEFKQ1BjTG1XRGJMZXRaVm9CbFgyRitRUU50V3o5VDlVeXpGSEEy?= =?utf-8?B?R3JGRW5MbnROUUh6VTVWdUN4UHZUaWNvMEdNRENrVFlqRW9iWGI1N1krcUxR?= =?utf-8?B?T1Z3Yy9WS2F4Yi9zVEF2YVlwSUovTXZRemF2Z1c5dGkra0dUUmJmd0JkRjU3?= =?utf-8?B?bHEwZ1l3Mm54dzV6cEhscllobzFiY0JJVU0rTUxVUHRjVERoWmRINWppbVZ2?= =?utf-8?B?UE5tNndYblZPZkd1TzYyZWxINGJSeThBMm5hbWpPNiszNW1taGJTSW1QdzVE?= =?utf-8?B?djhXR2VLMGJldTU2MEhwcHVWdmhlUXUzUDJHeTFCK3M0bWhCZ2Q5REpDUDZo?= =?utf-8?B?cVhnREREbkxYWktTbllPdGZxcmVaakVRMlZqZnduUFVXVlhKMDR0N0t0TUZh?= =?utf-8?B?dEs0K28vcWQxSThPZXRSSFRZMXV4UTFBQTBZaXhCZnkrQTROTEV2RVM5bXZP?= =?utf-8?B?SnVIbXRJd0FSK1djVzBma29td1RFSWlVdnR1TkkrVGcvTy9qcGE3QThWSThq?= =?utf-8?Q?aQJ0oy?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Sm82TkpieGd0Y1N0ZkFrUFFTeWFWeVRqR1pSSGNyRkR2MW5xTjBxTHhDdHJv?= =?utf-8?B?SklsYUErdVEyRzZONFdiU0trZVI0Si9SZVQwdFluSWJEZTQ3aTZ1aXdmVGhk?= =?utf-8?B?WnUydXNHNHRuTzUzQlUydnBZRGVKRlJWZTNVaHN6VU5yd2o5bUF5TWJrL1JE?= =?utf-8?B?ck43bTRGSnZaaUZBZGNLR1JsV0NLMG9TZGV3emF4RytuTGRkOWtyM2xkSHB6?= =?utf-8?B?ZzZ0dndqcDJjUk54MmFHL3VqUXVWQ0lXRDBSTE9iWXVvTmVzTm5QUVc2bllH?= =?utf-8?B?bkh1MjhobDg3b211V1ByZUUzRENsTGV3Q3BTSmNEM2Y4NkZtWjRNc0s1RXJj?= =?utf-8?B?NEdOR1ZtZFFWVHhIWGZ0bGtoU0dQZVVGR1RqU3NZa0JMRlZvRXpzRkJhTUxa?= =?utf-8?B?MGszTkVpSHRVNzVrOS96ZUFEWktWUUd5bXF2S21aNVZQUEMzaFNhd2JGc1Fu?= =?utf-8?B?RTY0SkhkTFRWcnI2QXFiUkc5TUtWYjhWMStGZEJVVG9wbUtLWGV1aFpOa1BX?= =?utf-8?B?d3NhR0V4VDhPT2Z1R2JKSVZxczlKZ2pOM0dvdzNWdUtDMkZxdUR2V25HOTdM?= =?utf-8?B?Z05CL3hCVHJQMVVQZlgyR1g4Z1RvV1hzZkdXSkYzK0VFenJnbTdFSUpOdTZ6?= =?utf-8?B?cVZxM1JVemsxOW1OYzNxeVdtS0ZpYjFOUjZEZ3FMMDhYb25JcjZUNW5BNGM4?= =?utf-8?B?d2dUdlZMWHQ2RGpnU2lMMzRxM3diVm9XNUdNV085Z2loUXQyUWJzcndqVW5i?= =?utf-8?B?b09kd0VhZ25BQkpNcmNqbStEdThpRzNEVTMzS0JrL2k3NGVBOGlJNEI0NzFt?= =?utf-8?B?UkxSMTdHUWkvSlByajBESE4zQjN3RTNuTmxjK05Ib3lqMEtEQUJMZ1N4dExE?= =?utf-8?B?aTNYZTl1TXFmS21aMzJkaUp4L0lXeXpwMVNuRTBwaHh4OEkvM3g0SmQzdUNm?= =?utf-8?B?aHptNGQvaE0xUXlIQTNJbzB5WlpORjZvdnplRU9ScVVLeHZ6cEsxbXZad2Vi?= =?utf-8?B?NDZxVWUyc01BSTFNbFlBbnJqSUhzaUw0Y2M1aHZwSkpzWllPWkdZY004UFRM?= =?utf-8?B?QnRrWDBaYnJEQ00xN3AyTE5iOHRpZmlyNFVmWjErMk1xc1hZdkZEaE1XQmo1?= =?utf-8?B?TmhuVklzT3Z1Nk1HbnpSdDVyNGp3dFRiYTF4Um9EUFBEOHllVVJBWWV5WVBU?= =?utf-8?B?KzF3bGNoSVhVMjZLdFA3UGdKMWpzRGVUN0Z2eS9iY0RxenNKeGdGWllyZC9Q?= =?utf-8?B?RUplQmhRaW84bWdGN2ZQcllqZkx6MUhoVERQS1hkOXlpSXhBdG5NWmJXT1Ir?= =?utf-8?B?a2JQNXpsUEozdVdMRklidEdaM2hvVjk3dnY1MGZrU0tVYkw2R3dnUEhEeEta?= =?utf-8?B?ZjNXSzlRK2RjSXZvS0UvcE91YlpjUmNFOFVrVVNlSE1PWGU5d0psT3BFOFY0?= =?utf-8?B?d0kxVGhCRExlaEFuZGhvTUpqS3RCbTM1OExOVGttbjJobWVoRHVoNDhBUXhj?= =?utf-8?B?ekhEWVNxMHJsWjlTZW0xeWRyNXFKNXZaZ2hwcGxRbzNNdk9jZW5CNSt6N2s3?= =?utf-8?B?ZjU5S0cwenFQQnArblVnQmZGSytNaTU1TGR3Z3BjYy9Vbm1aYzFKWmV1d2dX?= =?utf-8?B?MVBBU1preDVhQkc4ay9McXpRN3dabWtmQ1djVitrb0xQWDNRY0tTYUtTcVZZ?= =?utf-8?B?RXlTSzVnV29nYUowMHpUSXV4cVF2dFYvSmp0ZkV1K1BZVUwxUVF6Z3JZek12?= =?utf-8?B?TGxtczdRQjREdnlPZGdNODY1NVBRZjZwVlFNQjVJdkxGRTZzYWZVU2phQTh0?= =?utf-8?B?Z2xoKzRCOFFRV3NOL0JEOHc5R2xSL2FZU3BGVUdvQzJOUDNDeUJDd2daQmJV?= =?utf-8?B?aWY0QnhLcDROOTc1VkJ1ODRsNGY2OVJVSU5RL0dScUhrYU5vdWI0M0xsYm16?= =?utf-8?B?NlM5clZScHRwcHlxdDFjTkZQQXNDMWpwMWFrTnVRRW1BTHM5M1F1Z1d2RGl4?= =?utf-8?B?S1BDM21GSjNWSWV2SGtsWStsdFRLWU9RZmVxNE5HWUkvUHJIaVlubTEvTTdJ?= =?utf-8?B?dGlxalVldmg4TFdoSDZjemNJTXBBci9IMlIxRjZ4SDZnVytPdktaejNwMUlL?= =?utf-8?B?SmNCTGNHa1NzUXJZOVJmcHpnZjNzcmNqT1NrQUpQVG14a25VNitaL1U3OCta?= =?utf-8?B?RE11bUVpaUk1MXYyZncycHdEY3QveGRRd1lhUDVNZVgwYlFsSjVRQ2dnMHpl?= =?utf-8?B?eGFFWEZQaTNMVzUxNU82aDUxTVROTDU3c2k0TVV2M1lKbVhudkpoTUpLZFNn?= =?utf-8?B?dkE3VU0zREYvWSsrMFpsakN5NHFhOUsvdnNEcTlUYmQ0UnJwaFhzcHY0Qjh3?= =?utf-8?Q?xt4oLb8MFjsTfjQo=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3db900b7-276d-4bd7-5b4f-08de582bb586 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 13:56:28.7104 (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: ec5AVA4BFirynOoEJE2pwUBQGyazM/wyIrsFpQZRku8u7ZsGAeBcQ1PYvXoMGCJMCLldM1v4h7Kdn/n/i/CCWq3TvPkB869UdY+BBate/ow= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB7251 On 20/01/2026 7:50 am, Jan Beulich wrote: > On 19.01.2026 20:39, Andrew Cooper wrote: >> Despite removing references from the documentation, the Intel parts of CPUID >> Masking were accidentally left behind and still active. >> >> Intel CPUID Masking is even more niche than AMD masking, as the MSRs only >> exist between Nehalem and SandyBridge, Turns out it was Core2, not Nehalem. >> being fully replaced with CPUID >> Faulting from IvyBridge onwards. >> >> Fixes: 317051c2f032 ("x86/amd: Drop the cpuid_mask_* command line options") >> Signed-off-by: Andrew Cooper > Acked-by: Jan Beulich Thanks. > > Yet I think you also want to edit the CHANGELOG.md entry the other commit put > in place, to not have that remain AMD-only? Good point.  I can fold in this minor adjustment: diff --git a/CHANGELOG.md b/CHANGELOG.md index 7de34f64d1e6..53d92a259731 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -12,9 +12,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)    ### Removed   - On x86: -   - The cpuid_mask_* command line options for legacy AMD CPUs.  These were +   - The cpuid_mask_* command line options for legacy CPUs.  These were       deprecated in Xen 4.7 and noted not to work correctly with AMD CPUs from -     2011 onwards. +     2011 onwards, nor work at all with Intel CPUs from 2012.     - Xenoprofile support.  Oprofile themselves removed support for Xen in 2014       prior to the version 1.0 release, and there has been no development since       before then in Xen. which covers things suitably. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 20 13:58:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 13:58:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208981.1521106 (Exim 4.92) (envelope-from ) id 1viCFJ-0005B6-Fb; Tue, 20 Jan 2026 13:58:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208981.1521106; Tue, 20 Jan 2026 13:58: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 1viCFJ-0005Az-BU; Tue, 20 Jan 2026 13:58:13 +0000 Received: by outflank-mailman (input) for mailman id 1208981; Tue, 20 Jan 2026 13:58:11 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viCFH-0005Ao-EZ for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 13:58:11 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0b116760-f608-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 14:58:09 +0100 (CET) Received: from BY3PR05CA0022.namprd05.prod.outlook.com (2603:10b6:a03:254::27) by CH1PR12MB9600.namprd12.prod.outlook.com (2603:10b6:610:2ae::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Tue, 20 Jan 2026 13:57:58 +0000 Received: from CO1PEPF000044F0.namprd05.prod.outlook.com (2603:10b6:a03:254:cafe::a9) by BY3PR05CA0022.outlook.office365.com (2603:10b6:a03:254::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.8 via Frontend Transport; Tue, 20 Jan 2026 13:57:58 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CO1PEPF000044F0.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.9542.4 via Frontend Transport; Tue, 20 Jan 2026 13:57: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; Tue, 20 Jan 2026 07:57:54 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0b116760-f608-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AopPg9THoOIknOlQGWXAW54zCb3FNrS03PSctsnpUYWXOnti81C6jBxn1wtXtv6YH+Gy0DmEGwA9ldZj/5zrEzAXBo2Kt4pRQDdKb6rucJv7MLfHmeKGZP4T3620we1NeFzzFIUsH6TNLAv+0N81RWUm8A0Imn/3Vthr3b9S2PriqgD3LRNGdcFnipG+nyWe3pQ5/YElu1oa0B7CCgpLO80sRW6Cyf86zmpv+orVPjKInHY5Ra0uSWFaHVthDqPi3LHAph6FDSVLgNhb/Udjz0nAt6o3O7XvbvPhmLvh3YnbovDbDMxJXGT6tmfAiQLh7Yx0QrQ5jisfWTBbgLwOVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=W8CGmBzqZv+YO4Pg8zzYB4tgZG4wHe2PlGGzoW7v3mo=; b=yZ9+vgcvoUV0d9OTUaHiGm8E/5n+WzKOu4lfFa89YnyQO8RlwN8megjZB3svnHDuhlmLqCP1FxWGRsJoboTl/dACWU8FNg7CtQLeQ/te0ff91w28gTL+VSNqs8zOiqbdnP3NKrY1Zyq90OGbI/rqZSpk6W32O8QCmFR4gtcPlYNGib29bPXBBwvB0igccQYDM6v9p7WlZMDruQbQ6QDpnYNp7TJB0lshawekxcPy1EtDVXic4SP2/UKjOlCfcGFRaESDUH/mUSYQGEbq8BUpTqUdLP3qIwTZOs4/sdMd4T6mAqVl1CZWzzXCleLeMCOJ7hozVle8WwAYi6JJuu+XXg== 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=W8CGmBzqZv+YO4Pg8zzYB4tgZG4wHe2PlGGzoW7v3mo=; b=5pJFx+s9WY8XHq4Kp4SwIh0q+odS/YVgSZGutdpZMiISq1MaD/WqmeeGVWOLH5QgulJI4GGIq1O+P4vDCZeUZkN/a7cuK2MRRqS6pklwo/S0y75Yw+eZcN7bKRHPhIY6u0AHFnWUCsmyCojAqJyM2QBnWNXNgdS1m8IK5wIU8Rg= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 20 Jan 2026 14:57:52 +0100 Message-ID: From: Alejandro Vallejo To: Andrew Cooper , CC: Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , "Stefano Stabellini" Subject: Re: [PATCH 1/2] x86/svm: Add infrastructure for Bus Lock Threshold X-Mailer: aerc 0.20.1 References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> <20260120095353.2778-2-alejandro.garciavallejo@amd.com> <010b9a56-4e43-4813-b705-e34d8b4a67c5@citrix.com> In-Reply-To: <010b9a56-4e43-4813-b705-e34d8b4a67c5@citrix.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: CO1PEPF000044F0:EE_|CH1PR12MB9600:EE_ X-MS-Office365-Filtering-Correlation-Id: 319e291d-fda1-4934-5ec0-08de582beacb 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?cFRxbzNwbUdIakRlcEFEK2pISG4rSTR2dG1YeUhNWVI1bkxlTWU5b0pzam9Y?= =?utf-8?B?NVVnMVJSaFhOVkt6bjZBZzNuSVdmS3ZyV0U2WUNaTm5WRXRFYVBTUlh1ZkFQ?= =?utf-8?B?c2NzcXJyQ2FBck15TE9UY1R6cWNMMmo3dlUvdjQ3N3k1eWQ5UlpySEZIOE1D?= =?utf-8?B?cFJ2MzlabkE4RkVNZ0tQRk9ueHU4dDMreEN3QVg3Q2poa05XalhRNWVSWDls?= =?utf-8?B?WmRaK2pvNFJNUGw1ZWh1dHVDaUNkbDNJcG9DdTJESHJSTVBGSm1XbDRERlgx?= =?utf-8?B?cHRiN01WUTdWYXBaRm5WajRZVFQvQjA0YjRhRVduREdqSVJDZG1zTXZiYU9m?= =?utf-8?B?bHRwK0grc2IwdnFwT0J1THFyWCtSZUdlc25XSlpsMzBnMDhZREtrWi9SVkFy?= =?utf-8?B?a3Vha3VSRCtjNk5yTU1SL0VWTVJhdHlBTE9MVVFPd29vaW1ZWWNvTFhQUkd0?= =?utf-8?B?b0RSWVptbWhCeU90U29UZjYxWThRa3hid3AxY1hSTDhLTU9HVkRrcDVHMHNJ?= =?utf-8?B?dHFycTh4QnpiNDk2eDlidVIvT2Y4UHZvSGtIOUQwVm1ZamFISWdNc1V2TGty?= =?utf-8?B?THcrZGJCMDZKVXBKMVlCd3htMDh2QjVyaHcvNjEzdlRXcmc2RmxZditQcm44?= =?utf-8?B?dXR3RTNRekJXemR6MmNwSk9OZTNoMEEyM1p1TWFTVTgrT2g2UjBzNzNLaDFL?= =?utf-8?B?Z1ZzUU9tamkxMVJrTUpydGdxMGt3Z0c0QVhDRENRS2tyV05ER2YzakpmeFlU?= =?utf-8?B?SHpVNllaVnl5azhRYjdETXVxeUZJbGVMTHZlVW1iV283QVBiZ1NTZDRCNGUr?= =?utf-8?B?L3NEcjZPMFpQcVEwNERCeElZcnRYOTRSWU9lSDZJb092NFlpaWNKSHNCd0dH?= =?utf-8?B?ZkhvK0Nsb3RiZnVrNFQ2NEE0ZnltVFVHVkRHQ1ZzMXNOZGZkbDcyNW5yUzRa?= =?utf-8?B?ajE2QmJsb09obHFTbjVoSmVtLzVDTk93RjRiNFN1RE5maHVBVDNEZWdJb29T?= =?utf-8?B?RzNxZmlyYmxPd3Q0LzVmeHo5c2lMSjVPRzBkUU9wTnNITHVWUEdOUUFKc3Vh?= =?utf-8?B?eTFnOE5vWDFjK0lJdlFLdWJ1Z2NQTzRmelplQkw1b2kxOHRUWU9jdVNhQ3ZZ?= =?utf-8?B?Z2dWMFptUm1zSGova0VFWXdJeVkxRE9oMkg0U3NrUHBCbDJoTUt6a09BRFRJ?= =?utf-8?B?aDlYRjJxeGg4eGV5YUx6clBGODFibEtteWR5SThwUi9XKzIyOEVQUlpvSlhz?= =?utf-8?B?b1BCa2lweGV1VFpuYUxYejI2MFVmU1JtdUhUYmk0QkxqRDF2ZjBGT01YYTd1?= =?utf-8?B?ZGN3M2JWc3V4MXRVU2NiSTQ0L1hmTDcwVTFGemU2RjhGZjBXWDcwVHlFVTBa?= =?utf-8?B?Q3RsYUdVMXpNaERGL05JdjdsT1pNOEE4aWZHRFZ1TUpDOC80aTRvSUU2SEh1?= =?utf-8?B?bjJaK1ZwdkhhTm9RWjN5aW9ITTdHRG4waTg0aSs4YkpQMWg4Wk85MW4vMnVV?= =?utf-8?B?am5tdkZFZC80T2tqNkk0Zno4VGtRbzdkL3ZaOElNWE9VVzhvaXRkbGVGbk9Y?= =?utf-8?B?cW1GNUxEN1RiaFJBMU9KUStFUmk5a1VsNHZHYksxZ1ZHelJYaW9JSTRweTVw?= =?utf-8?B?RkVzbFNBZWs3YThmQ2ZZYWFuY1p4QThQWHZuakc0MXJjYTBLTTRPOXhtZE1q?= =?utf-8?B?WDBlaHZXRXEvak1nRzUzY01qWXJKdWE4K0xtd1Q3MXRmOXNacTR5TVBFSUhp?= =?utf-8?B?NVM3SE1NY21CTlpHdmdpa0NzaGVzSW1SWGtXTTdCZWQwSUovV1lDTGt1LzlO?= =?utf-8?B?emExQk5hSXRuQ25iVi9xakN4NDVFL3ZzUFpncUNpamk5U0g2cFlRTlV5RjQ4?= =?utf-8?B?WW5ZaWhQSjJYRXlFZis5a1Z4S3NNUE04b0J2L2VjclRta2tjVWJqSmwxd21J?= =?utf-8?B?d0laTFp5MGRlY2VWNEFhaDdWRjFyVEJSNUhJNjBNdnVKbC9WbFpZcjdJbjRM?= =?utf-8?B?OFlOWFV0QXVEWkxnZXc0VlZCR2N2ekJ6cHBaMWZNMS9yYWxMWHhMcDUzdXdB?= =?utf-8?B?VW43U0JkRjZZcFlKTDkxTlNLTSs3ZGZ0Z0tONkFHZkh3OEpSQTV6eElWQkl3?= =?utf-8?B?ZzZKQXJva2FhckxIcUo2WHRseVFiclZDWEtsTENWcWVLZU9jazFFOEQyTG1Q?= =?utf-8?B?SXJJTTVnNHJoaHZzNG9seWRXR1J5d2Q0R3BYZEtZcGN3NnRJdkxwODdGdERr?= =?utf-8?B?cmpNMmFYd1RsMzRCd3pZQzRLQVpnPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 13:57:57.8469 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 319e291d-fda1-4934-5ec0-08de582beacb X-MS-Exchange-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: CO1PEPF000044F0.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PR12MB9600 On Tue Jan 20, 2026 at 2:12 PM CET, Andrew Cooper wrote: > On 20/01/2026 9:53 am, Alejandro Vallejo wrote: >> diff --git a/xen/arch/x86/hvm/svm/vmcb.h b/xen/arch/x86/hvm/svm/vmcb.h >> index ba554a9644..85e194f247 100644 >> --- a/xen/arch/x86/hvm/svm/vmcb.h >> +++ b/xen/arch/x86/hvm/svm/vmcb.h >> @@ -65,6 +65,11 @@ enum GenericIntercept2bits >> GENERAL2_INTERCEPT_RDPRU =3D 1 << 14, >> }; >> =20 >> +/* general 2 intercepts */ >> +enum GenericIntercept3bits >> +{ >> + GENERAL3_INTERCEPT_BUS_LOCK_THRESH =3D 1 << 5, >> +}; > > Abbreviating thresh like this not great. > > For the intercept, it can probably just be called BUS_LOCK.=C2=A0 There's= no > other form of such intercept. > >> =20 >> /* control register intercepts */ >> enum CRInterceptBits >> @@ -289,6 +294,7 @@ enum VMEXIT_EXITCODE >> VMEXIT_MWAIT_CONDITIONAL=3D 140, /* 0x8c */ >> VMEXIT_XSETBV =3D 141, /* 0x8d */ >> VMEXIT_RDPRU =3D 142, /* 0x8e */ >> + VMEXIT_BUSLOCK =3D 165, /* 0xa5 */ > > VMEXIT_BUS_LOCK for consistency. > >> /* Remember to also update VMEXIT_NPF_PERFC! */ >> VMEXIT_NPF =3D 1024, /* 0x400, nested paging fault */ >> /* Remember to also update SVM_PERF_EXIT_REASON_SIZE! */ >> @@ -405,7 +411,8 @@ struct vmcb_struct { >> u32 _exception_intercepts; /* offset 0x08 - cleanbit 0 */ >> u32 _general1_intercepts; /* offset 0x0C - cleanbit 0 */ >> u32 _general2_intercepts; /* offset 0x10 - cleanbit 0 */ >> - u32 res01[10]; >> + u32 _general3_intercepts; /* offset 0x14 - cleanbit 0 */ >> + u32 res01[9]; >> u16 _pause_filter_thresh; /* offset 0x3C - cleanbit 0 */ >> u16 _pause_filter_count; /* offset 0x3E - cleanbit 0 */ >> u64 _iopm_base_pa; /* offset 0x40 - cleanbit 1 */ >> @@ -489,7 +496,10 @@ struct vmcb_struct { >> u64 nextrip; /* offset 0xC8 */ >> u8 guest_ins_len; /* offset 0xD0 */ >> u8 guest_ins[15]; /* offset 0xD1 */ >> - u64 res10a[100]; /* offset 0xE0 pad to save area */ >> + u64 res10a[8]; /* offset 0xE0 */ >> + u16 bus_lock_thresh; /* offset 0x120 */ > > bus_lock_count, which is basically it's APM name anyway. > >> diff --git a/xen/arch/x86/include/asm/hvm/svm.h b/xen/arch/x86/include/a= sm/hvm/svm.h >> index a6d7e4aed3..14fe4abf96 100644 >> --- a/xen/arch/x86/include/asm/hvm/svm.h >> +++ b/xen/arch/x86/include/asm/hvm/svm.h >> @@ -37,6 +37,7 @@ extern u32 svm_feature_flags; >> #define SVM_FEATURE_VGIF 16 /* Virtual GIF */ >> #define SVM_FEATURE_SSS 19 /* NPT Supervisor Shadow Stacks */ >> #define SVM_FEATURE_SPEC_CTRL 20 /* MSR_SPEC_CTRL virtualisation */ >> +#define SVM_FEATURE_BUS_LOCK_THRESH 29 /* Bus Lock Threshold */ >> =20 >> static inline bool cpu_has_svm_feature(unsigned int feat) >> { >> @@ -56,6 +57,7 @@ static inline bool cpu_has_svm_feature(unsigned int fe= at) >> #define cpu_has_svm_vloadsave cpu_has_svm_feature(SVM_FEATURE_VLOADSAVE= ) >> #define cpu_has_svm_sss cpu_has_svm_feature(SVM_FEATURE_SSS) >> #define cpu_has_svm_spec_ctrl cpu_has_svm_feature(SVM_FEATURE_SPEC_CTRL= ) >> +#define cpu_has_bus_lock_thresh cpu_has_svm_feature(SVM_FEATURE_BUS_LOC= K_THRESH) > > We actually discussed this on the x86 call just yesterday.=C2=A0 This wan= ts > an svm infix to match the others, and the thresh suffix can be dropped. > > I can fix all of these on commit. Fine by me. Is that an implicit R-by? Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Tue Jan 20 13:58:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 13:58:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1208987.1521114 (Exim 4.92) (envelope-from ) id 1viCFq-0005eB-Lt; Tue, 20 Jan 2026 13:58:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1208987.1521114; Tue, 20 Jan 2026 13:58:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viCFq-0005e4-J8; Tue, 20 Jan 2026 13:58:46 +0000 Received: by outflank-mailman (input) for mailman id 1208987; Tue, 20 Jan 2026 13:58: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 1viCFp-0005cY-En for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 13:58:45 +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 1ec004e7-f608-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 14:58:39 +0100 (CET) Received: from MN2PR04CA0019.namprd04.prod.outlook.com (2603:10b6:208:d4::32) by DM6PR12MB4155.namprd12.prod.outlook.com (2603:10b6:5:221::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 13:58:34 +0000 Received: from BL6PEPF0002256F.namprd02.prod.outlook.com (2603:10b6:208:d4:cafe::96) by MN2PR04CA0019.outlook.office365.com (2603:10b6:208:d4::32) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.10 via Frontend Transport; Tue, 20 Jan 2026 13:58:26 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF0002256F.mail.protection.outlook.com (10.167.249.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Tue, 20 Jan 2026 13:58: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; Tue, 20 Jan 2026 07:58:30 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1ec004e7-f608-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Qa9gULsltpffN/UhPm1LhSYx5KCRdY96cs2E0O6O5aYMNFq8gJPdg2uwEcP20limVfWHiECLg0ZIHxhEnYdCj7+N4IOYyKc2GZtFuKQNxKOYCvcDo5wdJdiJWWa8FGdTuumEP9CCTvVmdjXeD+Q7A+X9DriwgOXvfWD8XNf9BqQA4HnHzI7wpB/tBgwsTKr+oDXJpY021Ur01TpPVNyaQt+3tRDxPwU6OvaIKofutXP7yewn6uYxPIzVVY73jact7SfpmZUSeQozFIx1nR/w49i1lc6IXRcun8NKXFGp+2zsSpYmJMuT0baM2bdMpXxQoqka8azddG9NBlSrGncOWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DtTJahCmtQW+pKLvp1uMxtrsmJN+a/9CGtZ7z4PWElE=; b=nfgVlQtMA+2jL2NsDySpWrnHp4AgeF+o0udSYq1sEkS6O7Vxyg8bDK94ekHBTvS7ttaMrYU5bY+cbuufBtzLN3YC7lJMrkZCl/gU0c7q0OIjAiydemMwXmrPS7Jb1FGHllmYLO6IFLQhZiOI7FCappietKYCnUmbKZcKQ/+OrXiPceVCtzuQw9HUGeV/Wwuy6jKBlmaA+MIe8gjQkHlPIShNlonqVnB+QeTuySy40hC4ZD16mCwnVewsoiaXB5mK8LABAq/u7eXeGDhtIqJJllvyvBSKcaStwIPqH+vfSHvSjMWir8tXM+DFHsAQC/1pZ1qy/B7l80rb4Bu1mZB44w== 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=DtTJahCmtQW+pKLvp1uMxtrsmJN+a/9CGtZ7z4PWElE=; b=xGRwJf4zSk+lipGdqt0+07+ZwiR1kd8VnoG4SzE8FH67EEdqM+9Ehf1Nfb/6WmaAP1wNftJ57gIf+qNI5UwNqlr08R+usZwGXxTJE9O0oV/YpovitmtZBmnl8hzGcqQ2TKi++NzgJqhXV0Vnkip33xxdWqB/io7gAePNm7m4SMc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 20 Jan 2026 14:58:28 +0100 Message-ID: To: Teddy Astie , CC: Jan Beulich , Andrew Cooper , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , "Stefano Stabellini" Subject: Re: [PATCH 1/2] x86/svm: Add infrastructure for Bus Lock Threshold From: Alejandro Vallejo X-Mailer: aerc 0.20.1 References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> <20260120095353.2778-2-alejandro.garciavallejo@amd.com> <9097240c-a892-41e8-a686-b89d84d0c03f@vates.tech> In-Reply-To: <9097240c-a892-41e8-a686-b89d84d0c03f@vates.tech> 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: BL6PEPF0002256F:EE_|DM6PR12MB4155:EE_ X-MS-Office365-Filtering-Correlation-Id: d25b0cbd-b214-4892-6382-08de582c005c 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?VVVPQ3A1dW9UZFRrelMxWkVFT25FUFVKTCtZajQ5bHJ5Z2tpZkEvQXJPYXRy?= =?utf-8?B?WThLbm1ZQUhnb2taaDZrSENqamFOVlVCZW9XTnlyc3lqanRmUW0yakQ5S29X?= =?utf-8?B?VGR5T3RDbXRyQ0g4cXlCbTM3anlPNXhlVWlIZXMxVGtEMWpnSkk4d0pVQUpN?= =?utf-8?B?elBLL09ZazhvWkd3NTFKeHZPYVFVelZwMXdzWENrY1g2QnJDd0Z6dzQ5WGxn?= =?utf-8?B?MWtvcXBsbVBXZTNsUEZ0UGFMS29RZVg5T2J2Qjd5WHN5d28vdFd2NnIzN3h6?= =?utf-8?B?Uk9zdU5VcWQrRnlTWUFhYndZNFRaRHdna0pGT0RrZVpmdmY1USthdEJJWWdF?= =?utf-8?B?cHFwSmxYanpoMUNPa2s1aC8zam5DRGxKV2Q0V3E3eEw0Ump0aUhtSjdXTGVK?= =?utf-8?B?WXVTQjJSWGQ2NFRaVmhOMDNIai9sUGRRUFppYzUyZkdjYVg2a2N3bVYxODFG?= =?utf-8?B?ZmVqNHFHRnl5ZzFLOXEvRkRRRWNtVmxTbEJvTGhaemgxdDBWLzQ4bUgxR0lJ?= =?utf-8?B?T0RMRkJYYVQ5eXZTbWE2eUhzMk9NbSs1Yi8vbUkvU003dnU2VnU5S0d5bVF5?= =?utf-8?B?bDgvRlY5ak94dHBGRUxwZmw2Z1M2b2NwWURmV2E3Unp5MDVRTzhhTWRodDBx?= =?utf-8?B?VGY0OGl1NVgrcVJTN0o1azJYN21BUk54elBkZFlwK2FlSHhnOFFWSHppalkw?= =?utf-8?B?NmRwbzVWTVJ0QlBtb2pUdmg2bG42eG90NFBQaFExVTI2OURGcnNHSXZXeWNE?= =?utf-8?B?RGNXS0E3ejA4Q3MrK0N2Ym80ZkptWG9Kdm1PU2sxaSs0cHpCUmRabWVmK3A1?= =?utf-8?B?QTFTWkoxTmJmMkYzY3ZRUWsxejdqUFFNL3NBMmZQRGNoUldYVFVLN2VNOHVa?= =?utf-8?B?aDF1NkhTdUhjU0VBR2xZOWtRVVBnYkdZQXU3QWM0VnF5RkVDVDhpUnZUNXpj?= =?utf-8?B?K2VQRXI1RTRXY2lsU1owekgrSVBtcUIyTUtxdEJHckQ4VitER2hzU3V3eURP?= =?utf-8?B?eWdHa0NrMEhaNjNVY243ZCs4MXBDckVKTWVzVlJLZU13TlpjUStNME5WTTNZ?= =?utf-8?B?ZWdYRVBWRGdBYWRwV1lXRnlnL2JyK3dpNEFlNUdkSFgyOWtPN0J3U1hkWHFL?= =?utf-8?B?aDBxb2pmUzV1NUFOTmVCcDNMd211dzFyaVdQRDhIU0hoR0hqOHJHbG5JV01X?= =?utf-8?B?V3FkSGFXSnFiQ09LaTJkZUw5cHBDOEh3UkNScXlDc1RqUFZFSzNVTkg5Z2pm?= =?utf-8?B?TktBNkxNWHljMkk0VTdEeHF4YUE5V0dnejY4cER1QVR1TkxpK084UzgyQ2xH?= =?utf-8?B?V2g3eEpRd0Z0bEprZnNpTk5UMXhnVzRPdjB4djhpZTVGNU0zc205UEdsaE9Q?= =?utf-8?B?L2pqRVVhV2ZqMDRTbnBXbkMwMkd1RWYydzJJYXFXYkZhNE1Kb3pwbnA0RGN6?= =?utf-8?B?NmR3WHVlcUMrUEVVOEcveEp4M1FLWlRBMDNZUElXRjAwL2RUZ1RoNEI3RHE5?= =?utf-8?B?TU5Ydmw1Z3VaYXFQZDZCVVpOOTNIanlQN1d4OUtZRDZkdmhiWFZQNUtEWnU1?= =?utf-8?B?dVpYYTBKcFZROERuYUtJelRqQlJDQkVseUkzTUdDekxBVnpSZFVidnZWL1FI?= =?utf-8?B?ZDE3V1o5QXBJL1V3cjdmQXZVSnhhR1RsYzZSMC94SkVwUHFRZWtJb1NIUmFs?= =?utf-8?B?S2xKMGZmd0tTQTBmU01LeVE5RzNEWVlVK0pjN05rSko0cnh3WittMW5sR01y?= =?utf-8?B?TGZvckZ3T0E0TnlhT1hCWlJuUE15VXlFelBjK09UL1pIbWVQK1ZGbDlVSFA1?= =?utf-8?B?b0hGaW8xMGRjR1h0RGx2Z2FWalhQZ3MrNXFXaC83WDEyM3owMWtrT2w5cGph?= =?utf-8?B?Z1h4b1FNM2NYVmFESlVxYkRwU1hmTllxb2svNHBGd090NGNsRGMvc0VuMy9y?= =?utf-8?B?NDRUNHNxYXVWQ1A2NHJzc3hpSFlrRGk3Z3dUUURiaWdoUDZwekdKY3UyNlp2?= =?utf-8?B?MUozQllmZjdyRlovaHZuZjJYQTgvd0FvMC9EWnZRdkJpNGhQdDZmTThET2ND?= =?utf-8?B?a1JhNVp3QktmN09OYys3SnVLL3RQclZLV1BhUHdFZndZVjNtUG04K2V2bTdO?= =?utf-8?B?NFZ5SGIzeUFsemY0YncyL0Rzc3NUYlhDT2UwUE1qdE5tclhUYVAxUnlUdTEv?= =?utf-8?B?UExGSUhLcnZ5d2laV1BxZ0VkcHVBRnUxN0JocnhZUm5iWlVtU3A4ajBIRzgw?= =?utf-8?B?R0p3YUV0Y0Jkd0x0NTRpdUg1STBBPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(36860700013)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 13:58:34.0585 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d25b0cbd-b214-4892-6382-08de582c005c X-MS-Exchange-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: BL6PEPF0002256F.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4155 On Tue Jan 20, 2026 at 2:18 PM CET, Teddy Astie wrote: > Hello, > > Le 20/01/2026 =C3=A0 10:56, Alejandro Vallejo a =C3=A9crit=C2=A0: >> Add missing scaffolding to enable BusLock Threshold. That is: >>=20 >> * Add general_intercepts_3. >> * Add missing VMEXIT >> * Adjust NPF perf counter base to immediately after the buslock count= er >>=20 >> Signed-off-by: Alejandro Vallejo >> --- >> xen/arch/x86/hvm/svm/svm.c | 1 + >> xen/arch/x86/hvm/svm/vmcb.h | 15 +++++++++++++-- >> xen/arch/x86/include/asm/hvm/svm.h | 2 ++ >> xen/arch/x86/include/asm/perfc_defn.h | 2 +- >> 4 files changed, 17 insertions(+), 3 deletions(-) >>=20 >> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c >> index 5d23603fc1..9748df87d8 100644 >> --- a/xen/arch/x86/hvm/svm/svm.c >> +++ b/xen/arch/x86/hvm/svm/svm.c >> @@ -2524,6 +2524,7 @@ const struct hvm_function_table * __init start_svm= (void) >> P(cpu_has_tsc_ratio, "TSC Rate MSR"); >> P(cpu_has_svm_sss, "NPT Supervisor Shadow Stack"); >> P(cpu_has_svm_spec_ctrl, "MSR_SPEC_CTRL virtualisation"); >> + P(cpu_has_bus_lock_thresh, "BusLock-Intercept Filter"); >> #undef P >> =20 >> if ( !printed ) >> diff --git a/xen/arch/x86/hvm/svm/vmcb.h b/xen/arch/x86/hvm/svm/vmcb.h >> index ba554a9644..85e194f247 100644 >> --- a/xen/arch/x86/hvm/svm/vmcb.h >> +++ b/xen/arch/x86/hvm/svm/vmcb.h >> @@ -65,6 +65,11 @@ enum GenericIntercept2bits >> GENERAL2_INTERCEPT_RDPRU =3D 1 << 14, >> }; >> =20 >> +/* general 2 intercepts */ > > nit, you want to says general 3 intercepts I do. Well spotted > >> +enum GenericIntercept3bits >> +{ >> + GENERAL3_INTERCEPT_BUS_LOCK_THRESH =3D 1 << 5, >> +}; >> =20 >> /* control register intercepts */ >> enum CRInterceptBits >> @@ -289,6 +294,7 @@ enum VMEXIT_EXITCODE >> VMEXIT_MWAIT_CONDITIONAL=3D 140, /* 0x8c */ >> VMEXIT_XSETBV =3D 141, /* 0x8d */ >> VMEXIT_RDPRU =3D 142, /* 0x8e */ >> + VMEXIT_BUSLOCK =3D 165, /* 0xa5 */ >> /* Remember to also update VMEXIT_NPF_PERFC! */ >> VMEXIT_NPF =3D 1024, /* 0x400, nested paging fault */ >> /* Remember to also update SVM_PERF_EXIT_REASON_SIZE! */ >> @@ -405,7 +411,8 @@ struct vmcb_struct { >> u32 _exception_intercepts; /* offset 0x08 - cleanbit 0 */ >> u32 _general1_intercepts; /* offset 0x0C - cleanbit 0 */ >> u32 _general2_intercepts; /* offset 0x10 - cleanbit 0 */ >> - u32 res01[10]; >> + u32 _general3_intercepts; /* offset 0x14 - cleanbit 0 */ >> + u32 res01[9]; >> u16 _pause_filter_thresh; /* offset 0x3C - cleanbit 0 */ >> u16 _pause_filter_count; /* offset 0x3E - cleanbit 0 */ >> u64 _iopm_base_pa; /* offset 0x40 - cleanbit 1 */ >> @@ -489,7 +496,10 @@ struct vmcb_struct { >> u64 nextrip; /* offset 0xC8 */ >> u8 guest_ins_len; /* offset 0xD0 */ >> u8 guest_ins[15]; /* offset 0xD1 */ >> - u64 res10a[100]; /* offset 0xE0 pad to save area */ >> + u64 res10a[8]; /* offset 0xE0 */ >> + u16 bus_lock_thresh; /* offset 0x120 */ >> + u16 res10b[3]; /* offset 0x122 */ >> + u64 res10c[91]; /* offset 0x128 pad to save area */ >> =20 >> union { >> struct segment_register sreg[6]; >> @@ -583,6 +593,7 @@ VMCB_ACCESSORS(dr_intercepts, intercepts) >> VMCB_ACCESSORS(exception_intercepts, intercepts) >> VMCB_ACCESSORS(general1_intercepts, intercepts) >> VMCB_ACCESSORS(general2_intercepts, intercepts) >> +VMCB_ACCESSORS(general3_intercepts, intercepts) >> VMCB_ACCESSORS(pause_filter_count, intercepts) >> VMCB_ACCESSORS(pause_filter_thresh, intercepts) >> VMCB_ACCESSORS(tsc_offset, intercepts) >> diff --git a/xen/arch/x86/include/asm/hvm/svm.h b/xen/arch/x86/include/a= sm/hvm/svm.h >> index a6d7e4aed3..14fe4abf96 100644 >> --- a/xen/arch/x86/include/asm/hvm/svm.h >> +++ b/xen/arch/x86/include/asm/hvm/svm.h >> @@ -37,6 +37,7 @@ extern u32 svm_feature_flags; >> #define SVM_FEATURE_VGIF 16 /* Virtual GIF */ >> #define SVM_FEATURE_SSS 19 /* NPT Supervisor Shadow Stacks *= / >> #define SVM_FEATURE_SPEC_CTRL 20 /* MSR_SPEC_CTRL virtualisation *= / >> +#define SVM_FEATURE_BUS_LOCK_THRESH 29 /* Bus Lock Threshold */ >> =20 >> static inline bool cpu_has_svm_feature(unsigned int feat) >> { >> @@ -56,6 +57,7 @@ static inline bool cpu_has_svm_feature(unsigned int fe= at) >> #define cpu_has_svm_vloadsave cpu_has_svm_feature(SVM_FEATURE_VLOADSAV= E) >> #define cpu_has_svm_sss cpu_has_svm_feature(SVM_FEATURE_SSS) >> #define cpu_has_svm_spec_ctrl cpu_has_svm_feature(SVM_FEATURE_SPEC_CTR= L) >> +#define cpu_has_bus_lock_thresh cpu_has_svm_feature(SVM_FEATURE_BUS_LOC= K_THRESH) >> =20 >> #define MSR_INTERCEPT_NONE 0 >> #define MSR_INTERCEPT_READ 1 >> diff --git a/xen/arch/x86/include/asm/perfc_defn.h b/xen/arch/x86/includ= e/asm/perfc_defn.h >> index d6127cb91e..ac7439b992 100644 >> --- a/xen/arch/x86/include/asm/perfc_defn.h >> +++ b/xen/arch/x86/include/asm/perfc_defn.h >> @@ -7,7 +7,7 @@ PERFCOUNTER_ARRAY(exceptions, "exceptions", 32= ) >> #ifdef CONFIG_HVM >> =20 >> #define VMX_PERF_EXIT_REASON_SIZE 76 >> -#define VMEXIT_NPF_PERFC 143 >> +#define VMEXIT_NPF_PERFC 166 >> #define SVM_PERF_EXIT_REASON_SIZE (VMEXIT_NPF_PERFC + 1) >> PERFCOUNTER_ARRAY(vmexits, "vmexits", >> MAX(VMX_PERF_EXIT_REASON_SIZE, SVM_PERF_EXIT_REASON_= SIZE)) > > With that changed, Reviewed-by: Teddy Astie Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Tue Jan 20 14:07:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 14:07:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209003.1521125 (Exim 4.92) (envelope-from ) id 1viCOB-0007OI-Dm; Tue, 20 Jan 2026 14:07:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209003.1521125; Tue, 20 Jan 2026 14:07: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 1viCOB-0007OB-AL; Tue, 20 Jan 2026 14:07:23 +0000 Received: by outflank-mailman (input) for mailman id 1209003; Tue, 20 Jan 2026 14:07: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 1viCOA-0007O5-0h for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 14:07:22 +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 53b5dcfd-f609-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 15:07:18 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SJ2PR03MB7401.namprd03.prod.outlook.com (2603:10b6:a03:55b::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.2; Tue, 20 Jan 2026 14:07:14 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Tue, 20 Jan 2026 14:07: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: 53b5dcfd-f609-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=hWOs/I/WS0Fz9T5aSPGH12DPof26/fhvAUAHZE5w9Qdq0/xWZnfqjt4HUW7uMBaFs897O6X3Blhc+m2eWMEHT4i7MbXcCV1bdT38lYraKZ+R9L3p5nYoY1ZsuB43d2TjigsgMTkkdxI+NPMh16ihBAgArEK8xooXVCYzBOcD3RP+yNLnhLvI4LXD339zSRibxOl/yb9tXMtyM1ijwz3psVOri9whEcXIgtgtwjde6JO5IhWorsiV5184NaDeawf1CJUGK/3uf2I2lvaHTI9X4GEl/Si7SNtKRuOorf6z4QptN4QGa5sSPljObCFiDmx7ykirGNA5AL+og/FjQLfuLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+wMCjCg+l8nU5MPqP9WwnsjLA9RyAISWe+1h3Mco8JI=; b=QtMuHm2ZtpHg4kh4v3Xsvfk+n63u0cXpZQTGgqqclwc6csTfnWRd2SMmKUOixCipIBATeb3ApVukiggAaiUQ9az3v9MtcAWympXryYzJ+erxu9cVJqPEVevTxhIczKU3K/yKFWjmRXyhanuXmL+FCBecohqise/i0j6bAuWd7g8wF44mznQLRMKS8Z0zUPCEvpjDPuboh5nNEAWj9XTwvQ3RLuCFDeuyxs25jg6YyG1D+voFjq+UlJN3sDgJhobGwU4tVBnT33olblzzrx3q7UnSA5rGtzfhMfywxE38L64umtq+8eafzAc20OCWTLV16gduANRf9ZhtA13YyYD8cQ== 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=+wMCjCg+l8nU5MPqP9WwnsjLA9RyAISWe+1h3Mco8JI=; b=BK7ll5+xMEVOEq6ximn+UnY7/G8Mu0VhHFYJy6ofWydX7lriUI6TTc8UdeOaX0FlrRQWFGs94unmxsHHhT2coUGOThpMu43EhNs2gp6pTlNALTJpual6Sn8HM2KfKH9Tqg4VpkvW7Hvl6jf0gmI4KrSaT33l4LX2k1bXxBZg12Y= 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, linux-kernel@vger.kernel.org Cc: Roger Pau Monne , James Dingwall , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Subject: [PATCH] Partial revert "x86/xen: fix balloon target initialization for PVH dom0" Date: Tue, 20 Jan 2026 15:06:47 +0100 Message-ID: <20260120140648.25977-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: PA7P264CA0313.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:395::27) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SJ2PR03MB7401:EE_ X-MS-Office365-Filtering-Correlation-Id: b14598df-5945-471d-e395-08de582d3635 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?Vkd1UlFxMVBRTzB6UVF4VEJZVUR3djZDSnRUUjJkRG1IZ3lYVWhuRlQ0UnFy?= =?utf-8?B?d0Fjakt4V040RCtJNjlzY25kcUxxVDg4SnFVYjEyWWMzMHZ4dG9ScFlXYmZP?= =?utf-8?B?VGtjSGVyN2s3NG9aNElvN0MwOWR6RTYzZkxKVi9kaHVPUWVYWlltZG9RcFRt?= =?utf-8?B?MThhYlZTT1NsazhSRUNsZzJGNmZCNjNkQlJlRndwOWt6bENJQkR5QTBpaHBz?= =?utf-8?B?MHZpSFlrOFBmWnNOaEEvQm1PQTdqQ3hTVy9GT1RDbmJiWEJwZUhPdUJMbHdj?= =?utf-8?B?ZnBUR3h5bDYvRDlRNEt5ODRPdHhQaC8wNkVpK1dHbkloZERWZ2tiTkh1Uzdi?= =?utf-8?B?QU9PWXdPTEhRajlhU1BCSllKOEwyczV0dzY0SWNFd2lMaUJNOFk2d0doVHFJ?= =?utf-8?B?a3hMZFNaMWIzOVNyZGJJSEE1WWY3MTROWnFkNFBsSnFQS2d5SG1vdUd0MFlS?= =?utf-8?B?M1prQ2dON1F6NkRZdTBZYk5FU000TW1DbmRCNFlVWlZCUEhDeTNDUjJvb2wy?= =?utf-8?B?Rzhsc3Nkai9LQnZDMVJLeG1XYnIxWHozVlMxRDN4TmlkUFVtNUxkdTVrZG16?= =?utf-8?B?NFNlREs4WGI1TnVWWEhrd0hjTVJ6NzF1SktsVGRDOTBmdWhYU1RGSHBOeUJK?= =?utf-8?B?MVpYZCtQZUhOWHJjaDNGeFNDSjhWZ0pZbVpoMmp5UW1IQitXYVlSTFdoUTVE?= =?utf-8?B?MENRakdNaXpQV1NsKzJvWi9ZaWxoS0hPYUNDN0xVT05ZU09DNU0wancrRFlB?= =?utf-8?B?c3VQaElJRzdSRzlhdW5tVTdxUlllVG0yMnFJMjNiV0dWc1B1cDhTWXllTDlM?= =?utf-8?B?cnR3SGxpVGZKWXE4Umh1N3JTZGJDc2ZxL2VFeDUxS0ZNYnhYSE1tMTliZndB?= =?utf-8?B?cWp0WjhvY3NidkMrTG0zYnVGNWpvUTV4S3IvYnllbDAwM2lrTVZPUXpRZnEy?= =?utf-8?B?dEFsYy9Bdk1PS2E5aWdHMkFzVVFrb2VFTEJ3ejlUZFhadTFxSGh0eENJSEpl?= =?utf-8?B?VUtzdUVpU3hSemE4d2RsYzJnWURhWUhjUzIyQmgrWjNONkRzZlppbStPRTdk?= =?utf-8?B?clBiNWtucHczZmM1L0poNG9YQXZUVEhlNExOc2J1WEsrSFZuRnUwVXF5bUUw?= =?utf-8?B?RkxkNlhuVzVGUmF5aXo2THlpYUdxVVlJUUpkSE9zSWdvR29EdDU3RWlPUk00?= =?utf-8?B?ZGFvYlJSb0lKMTZ4Q1RMRmZzdGlxeDRUUDBsQkZzRVAyWXJqd0xacHMwUlVV?= =?utf-8?B?UUlNTkxGLy92Y08rcmMreU5Fakw1Z3QrWlV5MzZlcFdmOFJQUW5kdzZjTEcr?= =?utf-8?B?WWNhLzVnYzJ6dDI4OUtPYmJkVHlEaFc4K2YrS21EQUZnZ2hwS0FZQVIveGRT?= =?utf-8?B?SnREZDZGQy9tMUxWTTAvV3RuK2NET0lVellWWVdLa0R0M0tkQzVjVXhjVkFV?= =?utf-8?B?bHdxa1o1WHlOVTNCYzh3TUIvL0VjYlk1YmljVlVTSzBPd0RoOTg5c0NlMUkv?= =?utf-8?B?UWtKOXUwOUVEK1pqVWc3ZW1TR1hOWmtFcEJKcFF2NVlCU2xLeCtmZzRQVG1m?= =?utf-8?B?RDQ3ZTk2QkJJQzV2c3ROdFdlT09CcG5GTlg1OTQxV3pVV2toZS8zaXJZenJu?= =?utf-8?B?cUYvWE91di9HZWFPOFFlVFVwakdTZ1Q0T0g2NVhXVVZXd3o4bGVOcGdJc05o?= =?utf-8?B?RVZ2aC85cUg3TXN6WlF3ZjFMWU44bFNVekdKUkdtbzFZendqek0wekNNN0c1?= =?utf-8?B?QTJ2RXYvQ3J1N1JmOGJjTmRBZTl4ajJxbGU2UGNvS2FCZ1JNSy8zRVJxMUcy?= =?utf-8?B?RDFHd0MwY1A2T0VqYXhiZVNaOTVpbnp0VFZKOTJ4Wkxabk41QVZRaTJnMXpw?= =?utf-8?B?UlRvRElLVXQ1OFBMaEd3KzFrYlpHVlo3ZmhzalhtZXdtRWZPcnVoZkRzL0JO?= =?utf-8?B?SlZtYWpEei85aVNtTmZ1UTVoRWFHbFlZbUJCZStISUloVzdmdHBQSVBuQmdH?= =?utf-8?B?azNVOWtmelFUWnNVenoxTnFCQThraGVDSmlEalVQTURCQVpMSnYyNEF0Rkt0?= =?utf-8?B?ZE1EWm1qN0tWRUI5UThCMTFoMVExRVQ2YVdKVk8yL2VCZk50MmJGaldURERn?= =?utf-8?Q?rYxo=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UG0wc3ovY2JndlVTRm5rUVNZcXYwUUgwMFpKYm9sY2RzSlYxSVJ2aWlUaC9x?= =?utf-8?B?UThKTVpxZTVOcEJETEo5d0pKSGpyNCtncVpHZmtyUll5U0hXM1QzdnNhN2VG?= =?utf-8?B?KzcxRWgrbW5VakZUUVhoK29HSEVrejRiT1ZYQko0S0ZLb0gyd2FRRXdBOWhB?= =?utf-8?B?WWpDem9tdFp1Q2tXM2xZV2FNMWRIbWlBZ2tVcDhKZlp5NituYmxrNTEweTBX?= =?utf-8?B?ZHNldUo4YnhhZS8zUDZaeVBicDhtZ3NKbmlVeXdKZm1zSVFva2tFVzRlb2FU?= =?utf-8?B?TkpicFB0c1B6VmEzNERXL0h3Ymx1T2JpYnhkMVNkMjRCN2YwV1ZmdFM2NUN6?= =?utf-8?B?WTJyVlpRYSt4Y2xCQlhJeWRxYzdUbVdIdmdIZFk5VHVicXd6Ylp1NExWSjJH?= =?utf-8?B?TXViZXdySTBHcFFLNmhQcVd5M1ZXZ1kxNGdJWnRyREN0dW90TWh0MEZUWnRJ?= =?utf-8?B?Z3BrYUhoWjVvM2xEejcxa0hWQ0VWR0owbXYxMjhKRmhaNlAwMzdyWGFZNUE1?= =?utf-8?B?NDZ0dm83bzRxTDFNZ3BGd2FpV29ZOElhV3huejlmU0FCV204YjBjdXJtVCsv?= =?utf-8?B?QU90aFJtcnR1SURWQWdlb2EvbTNrNTVZTVc2OHFsWTd6V0ZRb1NQUDVQZlVU?= =?utf-8?B?QlVEYzBGNlpzTU9uVDFpdnNFbXZwbXlhREZKc2YydFpycUprS1o5OEtZNGpI?= =?utf-8?B?QUh6dEdORDVCdTFVK08zdDlWSmJzeHZ0WU9ETTFtWkZzOVBGMzZLdUoxRFRR?= =?utf-8?B?Tk5xYXdXUlVROHlWdnFxRVo1bG5ZY0FKZklaZ3Z4T2tjREoycTBseDlrNlB5?= =?utf-8?B?REdnVERJbnlNZmJ4VDZHcTIybnFETG1tTThWS0d4MVZaQTd1NjFsTGJzV0x6?= =?utf-8?B?NlBSd1kzTWhrVDEyVjBWSzVFaS9XTk1pdnRpV2dYLzRVdmdSSFpDbURyTHd0?= =?utf-8?B?b09qZnFJaitvck92SXJ6akpIQi9Kc2VWWVNkejBienZ6c2FIODBPQUl2d3l4?= =?utf-8?B?UnhJV01kVkk5RjZzUGc0QVpSQ2FhcjYzd1djbHFDSE9YR2RNV2Q5eFAvTXA0?= =?utf-8?B?REt5RklJTXU3L3RXd1pzKy9Wbkh4dHZkZGdydHgxb1ZFTVczY2JlMDEyZnBu?= =?utf-8?B?SnhNQ0MrWWhBVnpMTlc1OVRiczlDR3B4WHlmZGIwUFQ5NHRNVGFSdmlkWFd4?= =?utf-8?B?WUY2RXlVSmxuaVlkVXdyTjlLMlhBdnNtSTBORS9BbVBLa0hIYmR6M1Z4NlEv?= =?utf-8?B?KzFSYTNIcmdSNTlMNnRNcUoyNVJRaTVkQW1lY1ViWmFaSjYrWlFtSndUNnBt?= =?utf-8?B?Nk0xZmxBYTBabGo0WndRZnJRcEhOOUxJMGYyd3dmVUFLM0hxa0J1OVVJZk51?= =?utf-8?B?T2praTRaM2hPNHEwMXpaVkV4azNCV3lRWkRpUlRwNnFReXN0cUxPQXhobnpN?= =?utf-8?B?N1Fpa1BMRTZ5MGhNY0RXNlZFSXdFZzBibXNIWFVOdWtWdmFhRyt3MVB6dmNa?= =?utf-8?B?TTM1K3Y5YXQ5eUt3K1F5MVJKREFiM2xTUWcySXdRTXhMU2ZYREZsbWFJTldr?= =?utf-8?B?bE9Oa2ltTDFmcVFIL2RxSWJEVzJNSnVtdjZwbUFDRFBWQTFqSjg0RUtDaUV0?= =?utf-8?B?Z05xaDU1d1ljcHdWNTl5NFVuaFdESnIwWmdGL0NDdzFWQkxhdjNhaC92NDk1?= =?utf-8?B?VHU0V2hKQUV5aVBGUk5LMzJPeXlBN1UvVG45djIyRDNtYXh3TUYyZE02ekhr?= =?utf-8?B?ZWVMUzZGSkJLVmJ0QnN0aElDaHozcWlGM2JFSEZGRmlhWWhISEZTV28wSTFp?= =?utf-8?B?ay90OU5SVi9rbW1HRzFHd1l2aUJyc1czK293WU96VU1xRXRCdjcyVlJ5MU9U?= =?utf-8?B?K1ZOd3JST2g2NzRwUG9qcHVFc1UzS2tIeTFXQ0ZWRWxDRmtRM2RUT0s3TUwv?= =?utf-8?B?R24xV0NKUWlOUThUa3JxQnVldmp5NTBIR0FFWUxRTGN4NWpIUXZtQ0hwdlBF?= =?utf-8?B?d0k0b1JXYkdhU3M5d285VEVpWEVQQVdMNVMxTjJxLzdjNHIyT2czWUxEaHB5?= =?utf-8?B?dUJYVzFaVHlCa3BLd2ZJOWJ3c21YaUdlYkVlS094cnFxa1dvcUUwU2xVdSsr?= =?utf-8?B?WHNJSHhtTFNCRmJ5WnRwVmJHdDF5VFcxSk4rUDZhck04WEZuS2NHNEVVVDZv?= =?utf-8?B?NktTMU1uZ3RTN0Z4RGZUblJEZXAwSy92NER5cU1waG15M1p3ZEdzd0dPWTRO?= =?utf-8?B?UjZrczBXVURUWWFvN09jSHg2RnRxRTgvQ0lFMisvYy9BcHFDaDRoakppajRN?= =?utf-8?B?UHdNSldxejFwMjdVTC9nOFlYR1R0YjJ0aTFzWGFvMThzM1NSRWdIdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b14598df-5945-471d-e395-08de582d3635 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 14:07:14.1920 (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: kef7MiHVSzi/BUsSaJFcm2QO4YgMqU0XPkzJYKqeRisKQmttZb6Jr2KVMHx+mEYvCvMObCl3D//kqt5DukyfzA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR03MB7401 This partially reverts commit 87af633689ce16ddb166c80f32b120e50b1295de so the current memory target for PV guests is still fetched from start_info->nr_pages, which matches exactly what the toolstack sets the initial memory target to. Using get_num_physpages() is possible on PV also, but needs adjusting to take into account the ISA hole and the PFN at 0 not considered usable memory depite being populated, and hence would need extra adjustments. Instead of carrying those extra adjustments switch back to the previous code. That leaves Linux with a difference in how current memory target is obtained for HVM vs PV, but that's better than adding extra logic just for PV. Also, for HVM the target is not (and has never been) accurately calculated, as in that case part of what starts as guest memory is reused by hvmloader and possibly other firmware to store ACPI tables and similar firmware information, thus the memory is no longer being reported as RAM in the memory map. Reported-by: James Dingwall Signed-off-by: Roger Pau Monné --- drivers/xen/balloon.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 49c3f9926394..e799650f6c8c 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -724,6 +724,7 @@ static int __init balloon_add_regions(void) static int __init balloon_init(void) { struct task_struct *task; + unsigned long current_pages; int rc; if (!xen_domain()) @@ -731,12 +732,15 @@ static int __init balloon_init(void) pr_info("Initialising balloon driver\n"); - if (xen_released_pages >= get_num_physpages()) { + current_pages = xen_pv_domain() ? min(xen_start_info->nr_pages, max_pfn) + : get_num_physpages(); + + if (xen_released_pages >= current_pages) { WARN(1, "Released pages underflow current target"); return -ERANGE; } - balloon_stats.current_pages = get_num_physpages() - xen_released_pages; + balloon_stats.current_pages = current_pages - xen_released_pages; balloon_stats.target_pages = balloon_stats.current_pages; balloon_stats.balloon_low = 0; balloon_stats.balloon_high = 0; -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 14:07:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 14:07:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209012.1521134 (Exim 4.92) (envelope-from ) id 1viCOl-00083W-Ou; Tue, 20 Jan 2026 14:07:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209012.1521134; Tue, 20 Jan 2026 14:07:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viCOl-00083P-Lo; Tue, 20 Jan 2026 14:07:59 +0000 Received: by outflank-mailman (input) for mailman id 1209012; Tue, 20 Jan 2026 14:07: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 1viCOk-0007O5-IV for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 14:07:58 +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 6adbdadb-f609-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 15:07:56 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB5632.namprd03.prod.outlook.com (2603:10b6:a03:28a::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 14:07:53 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Tue, 20 Jan 2026 14:07:53 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6adbdadb-f609-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Fj8TJg2keQX7WRjrwmNK7YTbRVyB5245Gw+SZMSHTu+XxmpGad/vOOfrMgoElIyqoSp/LMo5T/UHOGEVE9fgmQ6Bz1dtA+tV1H2bEKuxUJdCxlRD8/zzZ8Elg9ipBs3xuShEfb9EdC4WJbQXG7Ly7TqPu3dQYr0U8b7mwaf6/fziFmYy5X5miGqINLCzzzBJHoHVpY9Rzob/0WnMO7X7mZgkz8W7KBNVZVHkRprhMNDH6ulDPAhwr17laT/Vv+1cHJF9swuFRUlUpRR7uyzPZjmBeooFHm0yik/nIkBfggsrxzTjuXYbLGrAitl8bRSXTwVBpo7Am7u0JHtHUZMsuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KEvV2hGjhqbkoILmhOE5HLRnQ0qgPeIKeqryF3Vjh7E=; b=fUOqvNTGvIPnYd+s/ymt/dVrJEfqX4QiRKihj4ss0VpcxJoqsAkWhW0e588CVgcxWtFZVwO+O15Fqn9d04J22tRNEXMOfdx4e+Cx7svJpnxYh8UHW1B+lLFn0KQTMZJXuhZ0MPu4mFGF1x/7yrd7u6+BqjqVT3oBT1fEFRQupZOP48e0yWb4S/K6/JixVNU3q4JKa70AXlxXtkYT+j3A7bX08f6YDWI2Hd1XL23zXhwNPUJIP306ryhQSjzgJgYLaLti2SiTs2bzf3Rr8Q3ZLLwC89Vy1vHabXfFh9YDJ9mzVWsgi6KzbQ9L+J/S297itJIZU4MtoJlgubrzpirUxQ== 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=KEvV2hGjhqbkoILmhOE5HLRnQ0qgPeIKeqryF3Vjh7E=; b=vG4eA75Mr8ryuXRuU7c1HnZ2IcQZKXVatSlinSlSzQHwdd22rrShsrk5ybEkV5dvXqNiYtVRaCg0LosT5B3GSvd7PU4MmWlIuWZaNdkD2v6IKVzFmk/7kAJzOn3/LY8xwXqb1K3BIoVSFTNVBRWV5OVOvOXOwfdh9ENqLuwXtEM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <39c11b77-7a82-4a4a-bc1f-d1153907a085@citrix.com> Date: Tue, 20 Jan 2026 14:07:49 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini Subject: Re: [PATCH v4 3/5] earlycpio: lib-ify earlycpio.c To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> <20260120093852.2380-4-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260120093852.2380-4-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0234.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:315::11) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ0PR03MB5632:EE_ X-MS-Office365-Filtering-Correlation-Id: 52055c12-a8df-4956-3f84-08de582d4d51 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?L09nem5kZ1czaXBXT1BjYlJIaThMY2s0cTBVaklqSlZwb1dDdC8yb3VCNm82?= =?utf-8?B?U2dsekNOQ2pXbXhlZ0kwb3UvajlpOUt2VkdYTHR2Wk9FeDFJQnVpbVdhMVJi?= =?utf-8?B?UmxLdFdwL3gxNHhpVVE0UVk2c1RMMEZTb1MwNE1rZlk3VWVzZGhZL1JVV2hp?= =?utf-8?B?cE52ZDU4cXJMdVRELzRBaUNHWTdKT0JVZmVwV1lmQWxPVytlU3gxNzRHTFRP?= =?utf-8?B?cVJ0MVpEcEhuekJEZ2J0YWEwbzRBa0FEKzZXVk1ST1d0NDlHZVdsMS9CL05Z?= =?utf-8?B?Vm85dG5qNnREcE5qUkNOZENSL1VrQVdBT1dSRWNjMEtSNE03Mzh4SjJ3RTho?= =?utf-8?B?bGIxVkRNWHExbGVvWGx5NnhoUUlMMFpCZTN0M3dCWWl1ZG5KZ2JSUjNnOWN0?= =?utf-8?B?ZjBNTzZCN1M4eDJ2dU5sUCs3YkRCcEp5dnZlWEcyaTBtM1ZEUVhnbXFDdXFF?= =?utf-8?B?azR6SFJQdmxWTUxtb1NxOVZCZWJwV1pUK2JYL29OUitIRldFTFYzaU5pSHhO?= =?utf-8?B?NGZhM3JzQ1FsMkd2Q0RuVWhJeisvbjBmTEppQzJJdVIvZVI2Qy9ST0dtdTdr?= =?utf-8?B?YkRuY3Q2Tzl3ekVkMWdiVTA5SGc3cnVOVU96OWxlK21jcEtqcVRZQ0grNTdT?= =?utf-8?B?cmtyQmIvNXhvMlc4Qms4QmtEYVhLOHV5VnVVb3JpZXk3T3JEMmlxRFBBVGVE?= =?utf-8?B?OGVUL09pTWppUmRaUjAvVGpGb3dOWGVwZ3hVc3hjTER2c1BJZGJ0Qi9Vbkxv?= =?utf-8?B?L0hHUWpRenA0ODRqSHl2QmxIUDF5YW8xMm5MVExTRGhGbjRyOU9zTk1zUkVi?= =?utf-8?B?UkkxK3ZidzR6WGxuQVVlNUxOWTR3cCsvR2JhclB4VDUvYWJsTTRJcmNKMmlh?= =?utf-8?B?Q2pad3U3V3JQdnZsNmtadjBrYkJZciszK1F0c3NFOFNNSFN3NU44REErQ1hN?= =?utf-8?B?NSsvc3N3ZWtkb0RMM2JHeG1rSE9kSlk0cTBBdzErdmJsNERFeG1NMmJ0UDdy?= =?utf-8?B?cCt4d0dMNnVLUFF3ZEpSR0RKUTV2Zy8yUzMzdks2Wk5QaDBvT3JiQ1p5WEtQ?= =?utf-8?B?VTVBODVaZ29uT1pobVNNVHRLS1JqaCttcVBpd0hxNWxnemVHaUF5N2pCNU1o?= =?utf-8?B?OGxsUEtsbTl5WHVpekpFNDIwTGExSmh2VHNKemxHc0ZUT0JlSGhCTmlpR1M1?= =?utf-8?B?VmNXbXV4ODRyQ2ZSM2Q1Lzk4WE15cnNxcUllWmhkamkwUXhTRUtnQ0JrVXp1?= =?utf-8?B?Ty8vSDFhSUZDZk9hY0ZYcmJOM3NNM21ka1dSNStrdGxLeHRzVlNhWjRGbmdm?= =?utf-8?B?WUtDeUlLVnNOb3dDTlNKL0RpTnQ3a29ITkpvaTFaNUFCdWdGNklTZVZ6b1pY?= =?utf-8?B?RDlIRG5UQlMxdkE1ckIxSy9QNzQ0a2ZsT0xFbmlXaEJDWHdKenVPNVZOV0hP?= =?utf-8?B?Wjk2a2hRcFZRYkdxMW9ablJpb1I2bHFyS1l5dFNvTFd0a0ZyNVlZS0pMMER1?= =?utf-8?B?WmN2Z3ZrWGpuMW5DdGJuMEk4eTVTV3JLWkpjdEdxVUgzOE5mRC9IOC9BMkFP?= =?utf-8?B?Y1A1VStCajhMY3dSaFJXQWhGR1h1SGV5UVhVaGRQS2lKc2hQMlRSLzd5bEhY?= =?utf-8?B?SHdyQmwrcTRjd1hndE9haVdVWnI5SHp5aUtpNnk4Y0gvNUtTcmpxdFVSYVM1?= =?utf-8?B?M0loTHlOV3M3cThZVGRhZ0QwbXNaUlF3RnZGSkJ3ZmsvZDZCc2l6d244bWJ6?= =?utf-8?B?OUhFMTkzQlVua2dDTFVnN1E3eFdsMHExZkhZaGRZT2svSThsMEcySVZJT1Aw?= =?utf-8?B?aktndzBkcmxwK1ArZnk0enhJdm1nd2lkTEVUMGV0UkRCM1VCRlBreVdOVldC?= =?utf-8?B?KzNrbHZRdy84N3JISDN6aEl1U1lCOFZoMEdrTUhKRTh6M29FRFJXSzdJaHRp?= =?utf-8?B?bTFzVXdsaUY1VEc2MU5mZlg5VUs1Umh5RENHbUo1UitlT21rcy9JK2psZHVU?= =?utf-8?B?dlZ5amZzUlNsbUdlWmhURUVjK09rMG9FVmFnV2pXYithaW5FYUdjbFl6NWFU?= =?utf-8?B?Rm5GbC93cnUvaExtS0txVmw2U0VaTnVGanFLaytpSzE4b0E2K2FtbGQ1WDB2?= =?utf-8?Q?SWu8=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cHBjYXR4d21RTC9zYlNQREgrUlMrajVkS01xUWYyek0ramg3eGN2eDdQWlZ1?= =?utf-8?B?cFhQcVpmL3o5cFVwQ0U5YS9Ucm96bkFhZHMycHFiVGdxb2wvK3FkcWExa3dN?= =?utf-8?B?cjVUcGF4VmhnMVdUZkJ4WEI2bFA1YkdCNWdWK1p6VkE1a3JCM0lZWUdNYm5K?= =?utf-8?B?WWhBaEtNMVN4a1ZnSGpXbjd3TTVIR1ROM1NPb0xYT3NYTDVnaHZteFJnaTVi?= =?utf-8?B?R1ExcFc3R3Y1SURiN3M0S1QzeG9sWGlic0d5clUvWUsrclIzYnNRQUxtOXdt?= =?utf-8?B?Y0txQmkxMHN0TG1KVUl2bDBvVFNvWVJvamVMbm5XdjlPVGRDc00xVmtPYk5m?= =?utf-8?B?S0xkOEs4T3ova2d3MmFWSEU4bE9sK1B6TktyVjM2QVRzTTNsc1RiR0VmVGRq?= =?utf-8?B?bE40VisxMzZxLzhWeW80R3hDb3VkVWhCVWZ2WlY1MStydjk0Y3gzUW1aVmZv?= =?utf-8?B?aWZpTVhlRVhvTm9VVlRtaVAyRlh1K2Myak5IbEpyQlZ3MHg0SURFSS8xdlQx?= =?utf-8?B?VHB2V1lodkY4cjIrcUN2MmpYUUFtNFFJSE1hSGtSWnBSVkl0ZHJtV2JUaklG?= =?utf-8?B?RXZmbWVQUjczeWJQdDN5ak5ocExwUlFXOU50Z3RkQ0d6MmlGWHNjOXFvWHhS?= =?utf-8?B?OVd6dmZJUDk2OW01bVJOSWF6UkFRR25tVE9UUEgyWTJzdDhmSkhFZjA4aHJ4?= =?utf-8?B?YzBqRW5GSldRYm1paTkxcXovN1NLS05aWmdRcTBDZ082MWxIVGtycTRsQlE1?= =?utf-8?B?Q2hPejd2OHowQ3dPUVc1MEd0UnpyNHJ1Mk1oQ09FYXBRa29KcGJ0Wm51TmRo?= =?utf-8?B?bW9pWTVFUS8vdXdVWHgvOWw1dGs4WlNxYkpLejd6RkExN1pmc28zbCtVZkwz?= =?utf-8?B?ZmFiSlUwYVpKeGJTQ3Zkek9tVEpwY3FKZzJQaUk5aFpKais1dW0wbVFrblFF?= =?utf-8?B?VlRFTXRLMjcvYkg3RGg3L2FyTkE2WlFoVE5GeVpDQ3dBYmpybWpzOEwrdVF4?= =?utf-8?B?a0hkcklIMzB5amx4QUNPSklzV1MwS28rSW53clFMUFZJVnAyd1NGWjg0ekJ5?= =?utf-8?B?emVlckNwT0FKb1FrTGUybVc3T2JkZFV3Mmc3WHFEYWJsQyswV2hScXYwaUtG?= =?utf-8?B?SWp3RTV5WHlycG92Vmh4dk40QldXWUlkWCs0SnlQOWpCZjRFWEpjSUZLelhQ?= =?utf-8?B?cVlYTW9WeFBkV0pHeEJORk5UNEVLOGZPT01zdUZJWlB5U0R0eVVvSVZVbDQz?= =?utf-8?B?b21yd1JGVjhCclBiSkNYcDAyVkRXdXhDaHNqZEdwb1BHRnVaNTdYZ0wyeWNJ?= =?utf-8?B?WDRoVHJrcHIxVFlTUDR3b0xTS0tITlZ1TEpiVjVpdTVhSFY1ZlZ4aVBpL1dB?= =?utf-8?B?VTYrbDFybUs0NXk4MStBaTI0RS82N0ZxcVl4a2g2bWRacmViK0NCQU5EVkNk?= =?utf-8?B?aXhKRDdhbTMxdmxuM3ZWdXhWMUs0R3BGVXdtbG9OY0dySThXUnRKdFZtS0hi?= =?utf-8?B?OExMZzNKMVBYcmxvVFg5VU1kTzE0QUh6b2N0QjhHZTVmRStId2g2a3pXQmRw?= =?utf-8?B?UkkyWEhTaWFEbnEzZ044M0I5b25NcmRuSHA5cXJxU3RFY3BrUnUrUkRrOXFN?= =?utf-8?B?VTNTdmcwSTVyWEE1OU1lb3ovWWJ3djAwWnhxTUhPK0VaM3lOT3QvVGN3RUNk?= =?utf-8?B?U0ZrUzN4TEZsMG1IeTNmSEZRRzJ0NGxxU20wNTgyMU1sSFBhbWhaUGh6OXEr?= =?utf-8?B?Ukh4NFlNNHpqMGhqa25oK3JPUzd0dlJSZDVGbVd2Z0VrYlp3ZjZJQmhDQzRW?= =?utf-8?B?amhhWHIwRHppUlJSbUpyWHBlQmNIYld4OVNQdnl0b0V6S3VrK3A4WWJJRW9h?= =?utf-8?B?L0hyVGZQSmtNcFd0aVYxRzRNTU1uL3ZtbkYvMWIzQkwydVVRTGQvajZqcDdD?= =?utf-8?B?QVlSM2gyZVhpeWNkNzVEQmFvZ09yL0RHUnFpUGNsMEUzTlViaHRHN3JrTzRR?= =?utf-8?B?THNBUHlBSEw0eEUvcTI5KzJ3VEFjdEpvMHBqMkxxRVNubGhGbFZFUEdYdW52?= =?utf-8?B?ME5KZXcxbTVCRWRVOWxTWXZkd2pBSyttQU1EZWpmUGZoYStRbUZEYmtNczV1?= =?utf-8?B?TkoxNmJKRnpPcU51Sm1pVXpTdG5ITjVlZ0lQMWtNcHA4L2l0Q0NTQ3d6UEFZ?= =?utf-8?B?WlMwR1lSSHNXdzZkc3dGdHN1YnlPWEdpZTNrc0xPMmJYbDJPQWM0UWNmZ0JQ?= =?utf-8?B?ZjRtV1VnSXRHVDJ4TzBDamlVem96SHNtSVEwMEdIejBzZ0t6c0tkN0dWa0FR?= =?utf-8?B?NmY3SVNNanBHTEtEM0xLeFRlMWRYRzlyNFh4Z1RoSEhsR252anlPR0Vhdm41?= =?utf-8?Q?9pEAtkVEjGMGCQjs=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 52055c12-a8df-4956-3f84-08de582d4d51 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 14:07:52.9222 (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: ggXVF6dV+wqHD5TKDcstP3q/sRnzesrTFNXkPj2qCKMPjsZHe/zIrQFTnVM+eVHiDazRD1obWA5cX5l9kuXho+qf9+jI+NVFGK6UsUkbb9E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5632 On 20/01/2026 9:38 am, Alejandro Vallejo wrote: > It's only used for microcode loading on x86. By lib-ifying it we can make > it go away automatically when microcode loading becomes an optional > feature in follow-up patches. > > Signed-off-by: Alejandro Vallejo Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Tue Jan 20 14:09:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 14:09:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209021.1521145 (Exim 4.92) (envelope-from ) id 1viCQW-0000KV-40; Tue, 20 Jan 2026 14:09:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209021.1521145; Tue, 20 Jan 2026 14:09:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viCQW-0000KO-1G; Tue, 20 Jan 2026 14:09:48 +0000 Received: by outflank-mailman (input) for mailman id 1209021; Tue, 20 Jan 2026 14:09:47 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viCQV-0000KI-7f for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 14:09:47 +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 ab681d62-f609-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 15:09:45 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB5632.namprd03.prod.outlook.com (2603:10b6:a03:28a::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 14:09:41 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Tue, 20 Jan 2026 14: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" X-Inumbo-ID: ab681d62-f609-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kpzqQd4/wPiXgNxUGv91N/L+1g2Yn5cVD1gd/Ir6x7SGszO32/+HaWp5X+qVME8DD1fWYdJwzdzjzPdghV09mg8phmqUChb4XrQP9FB5X3Cn80yyCdjUescXtMLBy8qk9tCTzymZtHRN8yd4EY6c0KP6cdZyHNIgW1MSJBNeqyLBHmKk1p8wMG4QGRhLSyaSQda7y/ouYiN/UuNp675EN10c3Ty8ia3GRQEGvhI5HTtgF5xb6DurrhZ32zYGKmJvo9ln6KmZHMH0FTB8mrCK8w59OCrobHEpfQ5IfU0cnRzTEu/GcHFu1ahmnkx9xc1p+ZsW6u6wJUSG/jouMxBRlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0UruohLUsRKdrKxS02n9udW8OL+3E2mfwtuJ1S5dpTs=; b=Eq3CzoAhqEZG4zAVCYCHE2AeUL5VQtHLlm80lG18t1Bqkgy3bTqoUU1YlDpgL6jSqXMLUU7dLdNMNWyITXogg6W14XsHm88OpnQ2XM5dvkSir8+x78/8dbnGWpmwK06mfi+NyjmfK69hrDFOIzXyztOPz2gabX2lZ51NjRjI1U4CvWYNovOzdqd2s6ZD47ZGGlHWj1ZAvzN6o/pu9deCaLUc6k8ODACF4L3yZbFkmdkYHMWiOohr/bcDP6fzLC9lOGt0AsbEUvXn/H+H4KOldibt8NWs9YLr2VdhdVpjqAxo/+dLQk9QJcUiEz//GGuiVnM606OhgJQQC5yrYIvLpA== 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=0UruohLUsRKdrKxS02n9udW8OL+3E2mfwtuJ1S5dpTs=; b=BXTBPFN1fy5IAYId8pBVQMTnjlVbFsZ42pxA5PB1d7XjL7ZfQTwQWxcuQ37ip4qWGnwrSZWXFrARR05Y1LH6i5+n54Z4mDaWsL4Pak6OWNYxr4NtDRQB5m6hskn5VD+4x9q+PehLW5K53XHZWvmypEpUtIdDPP+HwdoHgPT73W4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Tue, 20 Jan 2026 14:09:37 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= Subject: Re: [PATCH v4 1/5] x86/ucode: Add Kconfig option to remove microcode loading To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> <20260120093852.2380-2-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260120093852.2380-2-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0236.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:315::15) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ0PR03MB5632:EE_ X-MS-Office365-Filtering-Correlation-Id: b860b654-740b-482c-4b99-08de582d8df6 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?QkUvSDZQTjd1NGE1S3lhbnFUelZjTzFQd2pxZi95NE81dHRTbjNFcDZ6Vngy?= =?utf-8?B?SXJuVWFPaFNVNU9EaGFJV3YzUkhQdGZXOFFRaW1mS0JQWmFrTGdneXFkT0tx?= =?utf-8?B?K2RMdVpiL3pOeHZUZzhZWlB1Ukc5YUMrQkdkQzhrM1pFOU9PY2ZYOGpkNlNP?= =?utf-8?B?dVVFM3E4aGxEbFluVW5SSUJvZXJKRmFnSXBzb01KQkxiWXJub3hSMytSUUxo?= =?utf-8?B?V0NiV28xV3YrOGlrMDhoNzFSVGl6K0thS3RoTDIxTGt1aW9SZW5wb0J4QXMw?= =?utf-8?B?UjNlUnpoNW10aFI0SlBNVzFTYlozUkM3bktQdXFhdVZMSEVPc1pYc3MwL1ZQ?= =?utf-8?B?V2hKRDE2LzY2M1RGanlWNXY3eXlnc1F6MTBYb1hNSUtaNmE0MHl6RXBaTEZp?= =?utf-8?B?Zm8reTJLUWtCSEJnaVFsQThIWmloai9tbmhlQjFjbzM1d0ltZnVERkNuTHRQ?= =?utf-8?B?MFU1aWhvd2VzdnVnUGpCTTlFOVZSSWtHMTcvVSt1VHJFYnJaMFk0NUc4UWI1?= =?utf-8?B?Z2VCdy9DM0RzTlhsN0NjNmhVbGNTTWJKSTJobjBaejZmSUZSeEdiTENDUG03?= =?utf-8?B?NUtlcEMyaUhiV1ArZFMxcGhOeXFSSUJFeG1yU25lN0xhd3B0cWFaenJuL1pV?= =?utf-8?B?WGVXQXd6TDZhSUhVZXFaenNONGk0ZTB6QjY1M3hJbWY1VDJRZlM5VnhYNUd3?= =?utf-8?B?dlBudDNTZllPRTVsN0U2QUhmcFdJUWNnYzNScGluWHhLMWlhZEkrZmdDNzJE?= =?utf-8?B?NHkxNXp4NFplQm1TZEl1TXA2aTQ2YnlNU1lzNndrdmQvSDN3YmxMWW9TOEt5?= =?utf-8?B?dUV1UkhkeVpLbS92VFY4eXl1Rkd4eHFzUmdkb0N4NmczWXB6M1B2YWRyU0Z0?= =?utf-8?B?YjZGb3pkTWREL0lZSUdRZmpKY2k2ZW9UaTNTK1Vnbkp5NVF0R212K25DRURH?= =?utf-8?B?cVBVL25JaTR5TkRzd2hMNjVSczFHbFV1d0tkRzRtWUZRNU42WjM0MWNzYjNi?= =?utf-8?B?QzN0MktPQ1JVMkRpendIVTVsb09oVEpBSmZoN0VPTm01WmxwWExwZTR5NTFX?= =?utf-8?B?eXJOTzEvckdHRE9RS3RSWU1wVFAyZWp0dWZvUW95cTdPRkpKVDhsRXRNNXRv?= =?utf-8?B?bzdFOHFUajBIdFNTbndXUVdpOE1oSEl0TnMwN0VyMk5jZi9CU2M5QTFQM0RZ?= =?utf-8?B?OHh2ZHdDalg1OTlGd2V4eDF6T0dtd2wwV2wyNzZxaWdLRlNKdmlNSFNmRmVp?= =?utf-8?B?NEFwSnhMdEhoZytCbnlIeUc3N2lGQUh5QWQ5cjNHNSs5MWljTlRQcjM3MUFt?= =?utf-8?B?a204VlZzdmZHZzM1ckwrNEJzQTJVVnRGUUJXOS9hZlZvUHpRc2xyR2RTRGEz?= =?utf-8?B?ck5GZ1hvVC94ZW93eWQzU1puMjZLVktkQ2dOc0xZNW1tSUIyb0wvY2svc1Fn?= =?utf-8?B?a2dJblZneWlYODlNSWduVzFCaDhIOUVrdURzWU1PbGZKYlBGWHVkWHVJbWFp?= =?utf-8?B?NjJkaE9ORmdsT2xZWXlFeC9ISy9wem5Fd1ZPZXU3MWZYSW0yMjFaS3k3cXZn?= =?utf-8?B?aCthUHhxYlRNYTcvTk1SZ0pXZVJTbFZwNFR5WE9NMERKRWIvSm1sV2lIVGZN?= =?utf-8?B?ZXMwTy9nd3dLU1NxSHdodkhYN1c4eU1yTE9wemxEazVGT0prSFFKblRQOTBS?= =?utf-8?B?c3VzK25BOFZheFN0TnZTaHE0eTZBTzlmTGFhTjAxQWs5L0YxcHFkQktCNHRu?= =?utf-8?B?SFZzS1o5VlZFQStHbzllMjZKZys4S0hjamVna2tyOXNsazVqWkEveDJ0YW81?= =?utf-8?B?YjFiNmpvL3ZieVdvWlYyc0w3NjFKV2V2aFFmdFZPUjRsSEdwTWdLMnlpdVNT?= =?utf-8?B?Tnp6MzMvOWdDQmdiaUhIUWhVZzFwRm55M1ViZjY1eUU2Ymprc2ZKTlZWR3Qy?= =?utf-8?B?RFB3T2l2bG1lV3dWNUM0RUlHUVJiS0hGa29pZTh2NHpOS2RxQ0Z2a1U3RmNM?= =?utf-8?B?UmJQd0QwNkZ6U1k5Ui9HV1FGZ1FhK0hndCtwbkxnaFNkTG9VSmE5K1l5K2U5?= =?utf-8?B?Ym9aTEs5N3czQnhqZ2JPcTNWY05aL3hvQ1oyMXg3NDRyVmpmSlBxTnVMTENn?= =?utf-8?Q?GjdA=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cGZWZ2JEWjl0QldlQWp3ZGRSNFJNV3NDUlJtSXJjQ016K21xamoyekI0Qkta?= =?utf-8?B?c2pQVjZRaVBNYVdjZzFOTFZOTjBvMTYrckc2TElUNVZSS3FLSHMzL3d6WmIz?= =?utf-8?B?K1g5TkdxeGNWaVVKQ2hMaTFFc2pVNDBZQkVFelE2d0tINmFyOXlrYWdZbFVO?= =?utf-8?B?MFRNKzlMRU0yNjYyNDJqNzFYazZrK2FQSnkvSFdlTElXT1ZPeG5xemsrbFBK?= =?utf-8?B?bkhjdGk2N0Ryb3ZxMjVhNVFSL0JpeVRENTd1UGVlZmVBdHNrZU1FUWFBOTNZ?= =?utf-8?B?MDlCOVlUNG1tMkpKSDE5ZXZJQUlwelIzUjZ3Wnc0c01YdDF1Z21Rc1dzcDNp?= =?utf-8?B?MXZYbmcxUFFiTHhqbXM3WWZ6Rk4yeVJJU1JyKzBzUEs5Rmc4aE8zSGlLR1Q5?= =?utf-8?B?VXgyR2tDVnNDaEtBWWo1M0lKVFdIUzdraVQ1bFJBUWJSNm5BL0YwTVZoWmJk?= =?utf-8?B?TDcvRDUvV1JhZXhzZVhxWVhpWG9mNGRSWlF3b2wrSXFBWERKVGV2YWQxeXdF?= =?utf-8?B?T1FUR1l5aWNHQjBHdUVmZFExdm5Sc29CNlNGK2JyNEVCUlVZckFvUEpBaFhG?= =?utf-8?B?bnVQWmtCUmwrYjhvMGlBUWllVFFhS3FsRlFlNjlaV0RTNnE5L3NvaE82dU1C?= =?utf-8?B?MFd5N2tLM0kxYVpGUnBBVVpkUlJNa3FyRGhOa2h6Y2FzNGtsMDkzUlVWRFRp?= =?utf-8?B?OElFSnpkUW1SamhTK1NFUjF5NWR2RmtwZHJmb1dnSWhPMmhtbHJSR3hyZ1VK?= =?utf-8?B?ajRoUmRkM2I4OWQ5ZCtJZGlvbnJKTGZsT0FQZHBjTFByemVoUVAzc0lTVEI4?= =?utf-8?B?UTU0djlCeXdSUXcwR1M4UEprT1A1M05SUUQrT2F4ckgybVlSOGExS2dCai8x?= =?utf-8?B?b2VHZUQ1RnNscEJSOEZOUnE4QXM2ek52NkEzZmJKNlFZQWRkTHBCZ3dNRVYx?= =?utf-8?B?ZjZBb2Y3Tk9XcUNzYlNOeFVPS0ZRVFNFcnZ2MDl4dmFOMlphOCtGT0h6bDRF?= =?utf-8?B?SUNMRWdxOStmcDhLOS9XV3lKSDVEMHh5d2E3eEI3OUppS0IyR2hzRTR1MmxV?= =?utf-8?B?bWt4N1htVitwb3RKRU82RXpiR0hXR0tweDVtaWY2alR3SU5HTHFOMTVBUW5p?= =?utf-8?B?cmJUcEhhdWNmZkRQYTgwOW10RVYrSXhLNEdqWCtQb1BVZDc5b25yRjEvRncr?= =?utf-8?B?cytsUnhlNTBMTk5XNW1FQjZ0WC85ZHR6MFBOTnlYb284Z2owMWRhQ0d2UDhM?= =?utf-8?B?ZVpOanBzbzcyMm1Dbi9VMWY5dTM2OFNrYWJxR01yVTlFNTIvVXZnSWVIWVdE?= =?utf-8?B?eHdXaTBOMGR2N0VRdHlUakduMWF5V1AwOEFyeXZVbUdGc2JEYy9McDVwUzV6?= =?utf-8?B?VlBxK3E1N2pnNWYzaDZxUCt4am9KMENKQ1ZNRFpNbUx0R3FGeWhHQmxnZ3k4?= =?utf-8?B?RU5mejhwcjlvWEl0Rjc3ZkJoY0Z0U0J3NkNUdVNoa29uR1lEZVFKd2c0c1J1?= =?utf-8?B?L1E3M1d1U2Q0Q0dqL1VXbXpLL0VjU0w0VmtQMStFOFJSWTNxWU9iY0x6RlN6?= =?utf-8?B?YXBzRzRvaVpXWXdZTCtCajdtUW9OWFBia3BNdXU4dlkyUHRyREdDdnhMbWJY?= =?utf-8?B?ckk4THZvYVlWQkI0VVdnNVhSeDJkZUR5bmlHS2gxcGVhdHI0aGdiQmY4Nnlu?= =?utf-8?B?dGIxa3NjTGRJMnNrQU5ScHFxbEszYXJYVU9VeXVzd2gvV3NGZW1UaUw0ZEFI?= =?utf-8?B?cldNSFZ4dEZkckNZY2QvTGdpemt4NnRwcUdPS3JGdVc5ODlJRFNra0NkTTc2?= =?utf-8?B?Y1ZlWVlNalcwRkRTOUdWVHhzRXZnV1FkbFFFcXlraHgzL3ZVZ0FRc0xET2dS?= =?utf-8?B?TVArQm1tV1BiRDU2TUdGbXNGcEN3NjRwWDc1YklDVTdGMGZJbFV2UHBzZDBi?= =?utf-8?B?S2g0TTNRL1RWbE1TRFcySzNLc0U3SUoxTnU3UGFIRkVFL3JEWDlEMmtvaHpM?= =?utf-8?B?OThnYzhuOTBRZmlranpsQWJUeTlFVFpLcEV2VnZLWC9rZzYvT3FuZ084OVNt?= =?utf-8?B?a0VKOHExK015aHhkNVA3M1dHcFhOZ0FwRmxiT0dUL2h5REcxejZsRm5WL1By?= =?utf-8?B?RGprK1VZKzJuUVByZTcvRFdPWndiOHI4NlJMVlB2UTNtQk1nUG9qeExOMXNY?= =?utf-8?B?cFhONGlWVCtwYzNySEYrUDZmWlJUU25XcFBOOUdVUnVXdk1vRzR0ZFVjcHZL?= =?utf-8?B?bjdIYzFJSkNUanpaVmIzdUsrQ0Y5aFBReDUzQ3FBbExaVEpRTlJFejlVVWJE?= =?utf-8?B?ak9BVG04MGdXbmMxeGJ3QUNNSlN2cWNuajhmblpRSjBxTXFiZHI2Y2VrdjhF?= =?utf-8?Q?xMhO95PjqZPtv60I=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b860b654-740b-482c-4b99-08de582d8df6 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 14:09:41.3154 (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: OEJV+cTbzCnEND9grcjlbfEbAl9ey3nLbYgjf+hh3h/pJSVAR7F+yuF14VXLvae44bPFi5Fn2d9zVKrEc088Q0efg1OOHtb+/+W87ceDO9E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5632 On 20/01/2026 9:38 am, Alejandro Vallejo wrote: > diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c > index f8eca48170..2ac9fc2d96 100644 > --- a/xen/arch/x86/platform_hypercall.c > +++ b/xen/arch/x86/platform_hypercall.c > @@ -317,8 +317,11 @@ ret_t do_platform_op( > { > XEN_GUEST_HANDLE(const_void) data; > > - guest_from_compat_handle(data, op->u.microcode.data); > + ret = -EOPNOTSUPP; > + if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) ) > + break; > > + guest_from_compat_handle(data, op->u.microcode.data); > ret = ucode_update_hcall(data, op->u.microcode.length, 0); > break; > } > @@ -327,8 +330,11 @@ ret_t do_platform_op( > { > XEN_GUEST_HANDLE(const_void) data; > > - guest_from_compat_handle(data, op->u.microcode2.data); > + ret = -EOPNOTSUPP; > + if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) ) > + break; > > + guest_from_compat_handle(data, op->u.microcode2.data); > ret = ucode_update_hcall(data, op->u.microcode2.length, > op->u.microcode2.flags); > break; Very minor.  This diff looks like this because you've dropped the blank line between guest_from_compat_handle() and ucode_update_hcall().  That can also be fixed up on commit. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 20 14:12:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 14:12:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209031.1521154 (Exim 4.92) (envelope-from ) id 1viCST-0001mP-FI; Tue, 20 Jan 2026 14:11:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209031.1521154; Tue, 20 Jan 2026 14:11:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viCST-0001mI-CY; Tue, 20 Jan 2026 14:11:49 +0000 Received: by outflank-mailman (input) for mailman id 1209031; Tue, 20 Jan 2026 14:11:47 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viCSR-0001mC-Sp for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 14:11:47 +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 f3f16e0a-f609-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 15:11:46 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB5632.namprd03.prod.outlook.com (2603:10b6:a03:28a::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 14:11:43 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Tue, 20 Jan 2026 14:11: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: f3f16e0a-f609-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IxQWjVuQ6tLqRm7+bVKHzFjwW5rmNIXlHHKCHh0o3edmdjiSwsWHDkOeYIuHHZB093oVirdBfqkhkp9nr4fRkhJfXR1vvnaWWeIbeA9nTH2LITArRs7XNzmRkadik/02Q2tNWXL6cM3aRRPmq6p4XzXyu4ENF8MQEJpUVjR8lzJVdW3hm72VjsIlbuO4tjU6bmPDTwygNxJvB/8xc2N2crhO52eai/B5dm303xWE78Zc7Z80fnf5oN+qoR6FivJbGIxoEpVBRVCAQcHXq7kANQb4ksbx8ROX4zALgG5F1tpm09jQcmDoOZP108LkbDYmJ2gJEtM5QQL+RTD/oGt1VQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4S9DL7+9HUcvOJXrLiFOh5eTvIEQMG+V35wWBjoTjLc=; b=BjLijTN2jI7NOOUfmFGxTmLgh3iQgYvwVDOly2dpNduBLBBPvoq2KPZmqVuTk0kyWT0FuNt4v/UMQ0bWLkCJ6U+VuY4TSQ5Mxsk3lVJgHzKacz9+5pM0ATIep6/Orsil/2G0x0gmtOndW7ECniiv/t9xU2/dURX5B3qzM+vhcRfXRPBAF90rsM7p5YDi62+IrJtnQJgtroGorZCaX3mvIfxBbipFKP1Kk1CX7lESE8Hr23M1c1sEj4AxfrA0NJC1d7Cza7i8dxzJxKiWeNNL5hhnU1UoA1dsNkdERaRwVZ3yVuUrGHfx34AJ7R71j+FkOYpiKTtBMrWRcMepVCq1wg== 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=4S9DL7+9HUcvOJXrLiFOh5eTvIEQMG+V35wWBjoTjLc=; b=AdfffHJ32ebj08wbSH5EA02bUEmeU9XK/Bsb4WCGuAZJKsN9PKIAwuk9XoIAUExx8uNgTuIpfZgcW293LP7Rce3d7uhZQIoef67UVtVC83wIXpBsxnHjB4puEhgcHAPwR4IHSZFA3S3Iw6xb7t1RYhRu/Hri5F2xFJ8Ec5h1FKE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Tue, 20 Jan 2026 14:11:40 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Alejandro Vallejo , xen-devel@lists.xenproject.org, Stefano Stabellini Subject: Re: [PATCH 2/2] x86/svm: Intercept Bus Locks for HVM guests To: Jan Beulich References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> <20260120095353.2778-3-alejandro.garciavallejo@amd.com> <5a4aa1d9-dafb-453c-bd4c-8da860519f01@citrix.com> <00f36b33-65d5-4681-84d5-e1b2cbd8830d@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LNXP265CA0006.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5e::18) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ0PR03MB5632:EE_ X-MS-Office365-Filtering-Correlation-Id: cad7a916-dc2f-4da0-9a39-08de582dd6b7 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?Q3JpQm9leGF5d1lyMDJ5enUzN2VNTFFLaTJLL1lBMnh4RXNwZXpRUVBBeTds?= =?utf-8?B?TzJodHllNUZGLy9CMzdKaFRETkdtZmxqYUxGZmc0bVlWaUVRVFordDdGdE00?= =?utf-8?B?RDI3TTlJYk5OT0MrV2czWGNlSHRSSzF2TnQzYm43ZktRclpQTWxhVjk1Z05M?= =?utf-8?B?VW1YbC9Ha3prZFg1ZTdqdXJhcG56YWFoV2ZCbWVibkRJNUlNSHI3TU5rVFBM?= =?utf-8?B?SVJRYU9ZNEJhMnBwYUxMVzc2RDk3eEx1V0EwSkVucEo0TFNleEhVZHNodElH?= =?utf-8?B?UGhjcTJ4a2RIWHNISnk4d1BUdnErY3hpMnc3ekV5bk5wQ1U5dkNZTGw4cDVS?= =?utf-8?B?YURDZXc4aXVKYy9CQ3ZtaXlMaU5zbG1NVjJTL3VmY29pYzk0bjlBUE5RRURk?= =?utf-8?B?dXRWMkR3RlhFMDV5MEFaRW4yVHBBcGZJQnpjRDEvcHFuVlpaUWpwNk5yd3A1?= =?utf-8?B?c2JkalAzRmRXN3RiMVVnOFJNNUV1MEc4VmhTUTdwSVZQaW1hYmJYSlpsMHo0?= =?utf-8?B?ODdnSUk1QlNGTEIvWlNXcXZ2aW45eVhuaG03OHZJcXZYNFhqT1VMc0V2Rnp6?= =?utf-8?B?RjJRZzJYZHFzMnIzWXJtOWxjUnIwOTdNY29KaWk5SytjT1hzcmJDUlp6Vnhm?= =?utf-8?B?bmVBL2x0SUk0QmFuekUzRU5jdSszYjVPdENoT2dPaFhYTzVTOTE5OVYxRnFj?= =?utf-8?B?eFlxUC90a3NXVkZXY2N2OFgrd2VKRFJHSEQ3cER2bDhaeWlrRk9GN0VxRWRo?= =?utf-8?B?MjdxV1ZFRm93Qis0bkhXK2R5R3h6UjM1T0ViRXVzWHFmZjFQSXJ3ek11ME5H?= =?utf-8?B?TGhaZUlkN1hkZTBiT2FPeWdydi9uM3NUemROem1KcWFvSldLeG8zR1cxT2hR?= =?utf-8?B?dXdSbXdpNmQ2NFNRU0pyWjJmZkxCUmwwa1d5WjNjWlk5RW5adEdTdXFnWHFW?= =?utf-8?B?UFMzK1g5R3BVcll1Q3V2WjZrVGlrMlFNV1IzenZtcWFlNUJtSCtxYUVFRmFy?= =?utf-8?B?V3RLTzlQeHBBV2V5eUhJUHBlQlU1ZEpNRUx1Q1d4bm84STc1TlhLOG9oN2t6?= =?utf-8?B?eTNaUkUvb1RNVjJjNEhlRnY4UnFROWVEaS9tTlZaVmc1cGE2TVdRUXM1RmxR?= =?utf-8?B?SmdvaHh3MWIvUU1BN3p1d1lGSnUyNDVaWVhKOGNEZUl4cnFIc1NDMDliRmhV?= =?utf-8?B?SWI4eWFjZEpWNlJjYzRZaUFpSEpGZW52a1BHODhaL2MwbXdEL3RRcDEwa3A4?= =?utf-8?B?aVJaU21oUElYM1JNaU52cDRGZzJzeDBmdHJabFZRc2lLZS9TeVdCNTBLR3Vk?= =?utf-8?B?eEZPUTQzU2cxR3Q2aUI2YU9USkNnRno0V2lScE0vYkJzRmMyQk9nSC93amta?= =?utf-8?B?KyszREx3azQ3TnNUdlhHWlpsQ1NoaW9oMUZqMlF5MzlnbXZqeGtORW9Jc2s5?= =?utf-8?B?aGxRTWxub3QxbWg0QmgzcHZiemFsTjE0T3F6clQwS1dwaFlhNXJ5KzRiZ0F4?= =?utf-8?B?TlJhcDNPTmhRN2xLaEh2MElGRFJTRmY2WnBJQXAxeGd1OE5xNU9SS0tZOGpV?= =?utf-8?B?UUluSmZ0NjJnSXg1RzhCZjhUc3NqRXJ1VVlpbVFjbE1UMk54SFhIUWZDMHVh?= =?utf-8?B?dVZpVW51Y3JhclpMK0cvTDJ6dWlwRml0Y09WaEFWV2JnU05kRHhTdkIzbHFN?= =?utf-8?B?Z3ZiR3dvSTlxNGE4UUFLWmZRZ0d3YXBKaXpDcDFmdmFrbEo5d05VUm1iUGwr?= =?utf-8?B?dUhscTdiUkd3QnBGM0RDNTk1VG5KdjZRenJaeVVTT2dtTWNhS2dGRnBXUkdY?= =?utf-8?B?L0lCU0x2MmtYSGFRQzVLbXd3dGdOY2dVek9SUGtqaDJ3UWkyQ3hFZmhOQkx5?= =?utf-8?B?d2hHOXhRNS9lMjJSRU04QmlDUVNzWVgyYVlidWVzK2NmVWtiQ1dHY3BBTnh0?= =?utf-8?B?UCs2ZEpIUEVzQ09wVmh4RXFqaXVqa0ROY0t0NkVNWEtGbjBRZHhGOVVycmR3?= =?utf-8?B?MHhUa2xrTEVpUUNyblZrcHM5Y0xKN01RZWlSQWpSbEt0eDZYMnA1TFRnVHlW?= =?utf-8?B?MVJoY29HQlJUTUZ2L1V4ZngzdGhzM1hZdjJWeGl3TmN4S0R3NmpEdS81dDZP?= =?utf-8?Q?tO+s=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TjQzbjNxWi85VUp4cmFVTVR6N1owRU9JNFFJQ0dNUVhIRkRaOVZqL2FZTndt?= =?utf-8?B?M2FqbW5HYUszZERNYm1iVisrQUthYm05U2dQU0F2akxnc2k2TjJLQlFVcXJx?= =?utf-8?B?MTBLdWF5QTg3dGsrR2ZBY1kyb2pYbFI0aDR2dDBaYk1keXVTTkhzRC84Y05D?= =?utf-8?B?anVzWEoxN21UNHovZmtnOG0rRVc0azhVSHBDWlhLbWRKaEw0eVlSYVkzd0or?= =?utf-8?B?WElhQS9tRUc2ekk1STN4cko4emVUdExmd2UvdWhjeW9zdGxBbTU4Z2x1T3RK?= =?utf-8?B?NUF5RmpURzk3a1VHS2VxM0RqZk1IN1MwRVorU2NDOUtpdThVSDNPRWtZVERo?= =?utf-8?B?VjV1OEZwVld5cGM2NlpWTy9aaHRic1pvTXBsMUlzUXZuK2p6YmdOcXc3KzU2?= =?utf-8?B?bjJnMFlCcVVGSWp2T1RSM290NzcwREdOd0JBUnZabE1tOEV2ZkNEUzJIbFVs?= =?utf-8?B?VWNCZmtmSzNra2wwbXV2RktoZjdDcUFtTlR1QW52SkpWa3A5OE9GcmNHS29y?= =?utf-8?B?WWRIRzVmbllSQmY2SFp5bDdsT3RmRjNEb1ZIczVoWXA2WlBjNDJBYmZ2OFho?= =?utf-8?B?REZWd1NoN04zY2xxSkd2UThuOHZ4T0oxdXBlaEFMM3I1NXRMUXRiS2hCMGFJ?= =?utf-8?B?TjU5MGo1R1J2M1NvVCtJdndxSVdFQ05udFFZcmFwUWMySWtsQSsvOUlOM3FJ?= =?utf-8?B?SytPenhKN2xxdk96bmVmK2EzVlZEeDlPclIwMXJSS0d3dHVMbUhUaW5GMC9w?= =?utf-8?B?OGZTTngvQmJ0VlpoSHN5TVcrN1U2amZWZVFHaU16M2ZRMmFIYk9tQTJ2Yzh6?= =?utf-8?B?azFXek5vUmZTOVFWbGFiM3h6c216YkEwT3pjTXJKWVVOVkdDQ2tBUkJpUmp1?= =?utf-8?B?QkZkNi9VRGltOUpuWU1Md09JbjE5NVJUUXlhKzF3Vnh6ZHR5UWRqZHV1UDJI?= =?utf-8?B?c2UyLzRmU01BcjEzVzdFUFpqRUJFSWFzOElYOUo4UzVBSm5FeFRZNEZuU0dE?= =?utf-8?B?NlRMVnd6QTJNTVhBS0hSWUhlbzhnUnhjTklqZG1uTTVxUWsrOENsY2NIcVda?= =?utf-8?B?cDB3YWtGQmxwbk92WE11Rmx6bGVuZkliSU9IMUd1YW5wWGUzUUY1bWVCN3lG?= =?utf-8?B?UStMVTFtL1EwMVZnUWE3bFJWZ3dpTFRZODlDTTdMbDZnRTd6dm5SY3plOWhS?= =?utf-8?B?eU9ZVEY2ZGV6ci9icGU0ak9zWk1reHBkV3N1bHZHcG5EdzNNQi95YmFjSSty?= =?utf-8?B?aHZPVlJXR1RYRFVZWm1MOGIvbDlBUklpUDJYeTZxUjdpamNQcm1PdUhqU0JD?= =?utf-8?B?ZjFRVXRoT2JHYXVyYjFkanUra0RHbzdQMllveG5ueUR4QzFMMnllWldBWnBn?= =?utf-8?B?VUJzQStTNFM0MWl2TlVqMFFpQlZibCtQdGFrZURoUUQ1d2t3OWhmTHhiYWlM?= =?utf-8?B?dUNOaEk3eUZ3Q2NRczFQS0ZEVTYrSWZJakxnckxxcVk4aU5aUlRNd08ySzVj?= =?utf-8?B?bmVtTEtYQTFRQ282UkpnaE0yTldnb2F5cks1ZWkyaS9ML2xRMzJDVGoyVHZk?= =?utf-8?B?WCtTMUdYdHZQWnhlKzJiZE9pZ2VJME1qWFlKWG9XajBpUW52cFZUR1hGVTlo?= =?utf-8?B?eGZITmRMRWtoRlN4dUJLaDk4UXVwRTVJSXFMYUliWWdML1BkNkdZTmY3Umth?= =?utf-8?B?QzNxNkZVcFhCdFNHSkNJZTZMTjNkazNpdmU0SWp4d3psbGluU3B4WlFJaGdr?= =?utf-8?B?Z1dIN0dySEpncFRaVXdQb0pzd0hJMENnaE1HMTNqVW1nVmhKZUxnYU9TTHNi?= =?utf-8?B?YmgrczhxdjNBRXpob2tOTEppUHBUUkdqeG9qVTVBWFFEbjA1U2NTdndjZ2VT?= =?utf-8?B?a1JneVVRQTBDUnRncVZzNFVjd1VuT21pUmJCZUduMXptM3ZwRUl6NTVuRDhP?= =?utf-8?B?TmFTZ1lYVVJ3S2hlL1lRRVlua04yaGlEZUtjeUx6K3hHUnBoMXVLanE2Y1ZL?= =?utf-8?B?LzRPSWE0YTV0T20rUXlGZ0hhT1dEQjZGRklrQUYvZ3RtdVMyWDhHb0J6Qmkz?= =?utf-8?B?RzhLUVE5ZnRvT2ZYdllwcm5KT3lFeVhYK0FMV3ovbHJBTFJZRlI2bDN3dVlW?= =?utf-8?B?R2U4Yml5K1Fib3h2VjBqanAzZWhvYldEUE1RSGJOY21LdUtyenlGb0VoVytn?= =?utf-8?B?cEVnWFVGVFpzblEwSjFQMHh0YWc1alFoN0FpZi9rWXJrV3RBQW4ydFFBYTIw?= =?utf-8?B?WUlmZ3J3TWxienZjTVVhcG1GOGt4dlBRcTZrcnNFMElEUUl5MlBrd2tjOTY2?= =?utf-8?B?MjlyR3BEQ1p4ZmszZDNaWU9jRGFyUEdndytDS0xEcElCQkpiQ1NXQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: cad7a916-dc2f-4da0-9a39-08de582dd6b7 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 14:11:43.3083 (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: /MW1Sdd7taQ89oung0tfBOqnHA59yAd5ZyxZmOdNIKsqYUyds1xRxILtXun72usfJI49lUj8MoIic7eL1XX7e+byse781J3cELsibvc5tko= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5632 On 20/01/2026 1:34 pm, Jan Beulich wrote: > On 20.01.2026 14:29, Andrew Cooper wrote: >> On 20/01/2026 1:27 pm, Jan Beulich wrote: >>> On 20.01.2026 14:18, Andrew Cooper wrote: >>>> On 20/01/2026 9:53 am, Alejandro Vallejo wrote: >>>>> --- a/xen/arch/x86/hvm/svm/vmcb.c >>>>> +++ b/xen/arch/x86/hvm/svm/vmcb.c >>>>> @@ -66,6 +66,12 @@ static int construct_vmcb(struct vcpu *v) >>>>> GENERAL2_INTERCEPT_XSETBV | GENERAL2_INTERCEPT_ICEBP | >>>>> GENERAL2_INTERCEPT_RDPRU; >>>>> >>>>> + if ( cpu_has_bus_lock_thresh ) >>>>> + { >>>>> + vmcb->_general3_intercepts = GENERAL3_INTERCEPT_BUS_LOCK_THRESH; >>>> |= >>>> >>>>> + vmcb->bus_lock_thresh = 1; /* trigger immediately */ >>>> Really?  The APM states: >>>> >>>> On processors that support Bus Lock Threshold (indicated by CPUID >>>> Fn8000_000A_EDX[29] BusLockThreshold=1), the VMCB provides a Bus Lock >>>> Threshold enable bit and an unsigned 16-bit Bus Lock Threshold count. On >>>> VMRUN, this value is loaded into an internal count register. Before the >>>> processor executes a bus lock in the guest, it checks the value of this >>>> register. If the value is greater than 0, the processor executes the bus >>>> lock successfully and decrements the count. If the value is 0, the bus >>>> lock is not executed and a #VMEXIT to the VMM is taken. >>>> >>>> So according to the APM, setting the count to 1 will permit one bus lock >>>> then exit (fault style) immediately before the next.  This also says >>>> that a count of 0 is a legal state. >>> But then you'd livelock the guest as soon as it uses a bus lock. Are you >>> suggesting to set to 1 in response to a bus lock exit, and keep at 0 at >>> all other times? >> I should have been clearer.  I'm complaining at the "trigger >> immediately" comment, because I don't think that's a correct statement >> of how hardware behaves. > In turn I should have looked at the patch itself before commenting. The > other setting to 1 is what makes sense, and what ought to prevent a > livelock. The one here indeed raises questions. Setting it to 1 here is fine.  This is the constructor for VMCBs, and *something* needs to make the state consistent with the setting we chose at runtime. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 20 14:17:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 14:17:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209048.1521166 (Exim 4.92) (envelope-from ) id 1viCXZ-0002RU-7G; Tue, 20 Jan 2026 14:17:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209048.1521166; Tue, 20 Jan 2026 14:17:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viCXZ-0002RN-2T; Tue, 20 Jan 2026 14:17:05 +0000 Received: by outflank-mailman (input) for mailman id 1209048; Tue, 20 Jan 2026 14:17: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 1viCXX-0002RH-KN for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 14:17:03 +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 b00b6294-f60a-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 15:17:01 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-4801d1daf53so38387795e9.2 for ; Tue, 20 Jan 2026 06:17:01 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47f4b2672d6sm312046325e9.14.2026.01.20.06.16.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jan 2026 06:17:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b00b6294-f60a-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768918621; x=1769523421; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=7ivYj0JM7gFDh5SiBScTEsztjhvkAlR13S/xH0TUM0c=; b=AmcdHY+QjcQx/WLhPtItAhtpC75BkVyV/5LdnzA6GCaam2d7IwEg8RwoO1qjNPRGn4 RXs8Mi8YZK+Rt1wstdFLmXdlVMSAXKOT0VtaMCvzxHHr08vEjMPxPL3IyADF2kkBKHom jzIiwV+3qBzHxlvi3i+mvJHxhUAYTpI3RLqrO9IOZLE3MFEhgLqxhBt4D3uNdJQIDmXt qI3IV94mgex1OvOX2QILfjlnohldpSXfqaYDDspZS+7Mpq4o/1hpjljs8KTE94q1a4eT Y0+1Q2L2KV47ejKwGD8RrRNzKEPEsyNmH3Aq2kV5/nDzBVJPXYQtMTpbbxu2KnpWDP7b 0ncA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768918621; x=1769523421; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7ivYj0JM7gFDh5SiBScTEsztjhvkAlR13S/xH0TUM0c=; b=aGY/80P0JqJ5ZbaRNMhDzo2YgdSvjUIM7X/jW0bVNPvc5YSbmVekJOeTmtBX1MI9v5 BTsVjrQoanipC1nKsROLPj868ZgDeQTanRtxH5zo61aGUtPf/KGgN+5oHNZtLo/yOi6N 7u/AdmfxGVQ+yZMCgbtk4w8EOqmV7USt/pU7ssS3DMW+fV6VwOLWUKktL+ioh7ns0+uv ZPwr4tcNtYhtxmk3OSDEJo32Yy7V2ZO5lq8QY2ANN8QZX3SadUtqTSwAKHFwwshR2eCM BTSOD4rlKlj6egbiYMP8q3gYAaTcmMMiUjpLfdXuXq7jyWZzenXTYh8yUlQ+xe1Qn+0p 4uNQ== X-Forwarded-Encrypted: i=1; AJvYcCWjYdoilDuz5xgRHa9/3FhMsCwM/KMqML/Xgvuc+oBxXAzkHiHhE6/In5ez4eOJjH8IF3q48sIIPJQ=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw88chAAQrGOBhyrkJpCHniOYsLgszoPbS0l7OPZtvSjiAuvldv WXLc7v0svvYTnw/Thumb9acYXWKuCYiJEj0rHKR+O26xQMTwFQBSfaJ0SSuGd/LZmw== X-Gm-Gg: AY/fxX5CEpV6u2BiTNPekImzzQMmylGyT8EhBa1EodzwaA1Ly8ZbSq6afjZaHWAcmyd UBQ9cVlsgvlaVzyl79rDMZ/vGItt9gvE2JnSX8kAHRSBlxhiYmVcwSI3do3xomjk+PAAzql4SXV /6DT1oUJ1ZguoyOMESETbxhPm97qhyS8pSMkyuJWLZYFqaceCLPWkl1ut4W0euLDGAMHVcLf9Gr MlDs4YbSELyrusmUMfRAofzSSCkBgVCemrakZ7Pa4IqmvawUOsEYqaVLc+4xZtfvsSrPB8X5vTD 4+fjD6k4MmhgTjP481WAf4rtQRSy7Hqw2/MpGv3bDIwdv3ROh2w3N8MMXSQiXRGoWUJ99aArfPU dKeVX97Ql0tlp/OPBVyhyKkJVpCkYQLPJB0KhGUChOD9TnmkpwdZB1d0CoU6FOhndGW4CCVyms+ db35R103v2HTUY1s/ngrNsOjWZ1mOL5OIT83Dm3foRUAV4Q5BwcUHAPZki8xOO7Zh53tlcrnGpK XM= X-Received: by 2002:a05:600c:8b8c:b0:46f:c55a:5a8d with SMTP id 5b1f17b1804b1-4801e2efd61mr188693765e9.4.1768918620665; Tue, 20 Jan 2026 06:17:00 -0800 (PST) Message-ID: Date: Tue, 20 Jan 2026 15:16:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] x86/svm: Intercept Bus Locks for HVM guests To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Alejandro Vallejo , xen-devel@lists.xenproject.org, Stefano Stabellini References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> <20260120095353.2778-3-alejandro.garciavallejo@amd.com> <5a4aa1d9-dafb-453c-bd4c-8da860519f01@citrix.com> <00f36b33-65d5-4681-84d5-e1b2cbd8830d@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 20.01.2026 15:11, Andrew Cooper wrote: > On 20/01/2026 1:34 pm, Jan Beulich wrote: >> On 20.01.2026 14:29, Andrew Cooper wrote: >>> On 20/01/2026 1:27 pm, Jan Beulich wrote: >>>> On 20.01.2026 14:18, Andrew Cooper wrote: >>>>> On 20/01/2026 9:53 am, Alejandro Vallejo wrote: >>>>>> --- a/xen/arch/x86/hvm/svm/vmcb.c >>>>>> +++ b/xen/arch/x86/hvm/svm/vmcb.c >>>>>> @@ -66,6 +66,12 @@ static int construct_vmcb(struct vcpu *v) >>>>>> GENERAL2_INTERCEPT_XSETBV | GENERAL2_INTERCEPT_ICEBP | >>>>>> GENERAL2_INTERCEPT_RDPRU; >>>>>> >>>>>> + if ( cpu_has_bus_lock_thresh ) >>>>>> + { >>>>>> + vmcb->_general3_intercepts = GENERAL3_INTERCEPT_BUS_LOCK_THRESH; >>>>> |= >>>>> >>>>>> + vmcb->bus_lock_thresh = 1; /* trigger immediately */ >>>>> Really?  The APM states: >>>>> >>>>> On processors that support Bus Lock Threshold (indicated by CPUID >>>>> Fn8000_000A_EDX[29] BusLockThreshold=1), the VMCB provides a Bus Lock >>>>> Threshold enable bit and an unsigned 16-bit Bus Lock Threshold count. On >>>>> VMRUN, this value is loaded into an internal count register. Before the >>>>> processor executes a bus lock in the guest, it checks the value of this >>>>> register. If the value is greater than 0, the processor executes the bus >>>>> lock successfully and decrements the count. If the value is 0, the bus >>>>> lock is not executed and a #VMEXIT to the VMM is taken. >>>>> >>>>> So according to the APM, setting the count to 1 will permit one bus lock >>>>> then exit (fault style) immediately before the next.  This also says >>>>> that a count of 0 is a legal state. >>>> But then you'd livelock the guest as soon as it uses a bus lock. Are you >>>> suggesting to set to 1 in response to a bus lock exit, and keep at 0 at >>>> all other times? >>> I should have been clearer.  I'm complaining at the "trigger >>> immediately" comment, because I don't think that's a correct statement >>> of how hardware behaves. >> In turn I should have looked at the patch itself before commenting. The >> other setting to 1 is what makes sense, and what ought to prevent a >> livelock. The one here indeed raises questions. > > Setting it to 1 here is fine.  This is the constructor for VMCBs, and > *something* needs to make the state consistent with the setting we chose > at runtime. But the setting at runtime is generally going to be 0: When the guest exits for an intercepted bus lock, we'll set the threshold to 1, re-enter the guest, it'll retry the bus-locking insn, the counter will be decremented to 0, and the guest will continue to run with that value being zero. Until the next insn taking a bus lock. So starting with 0 would overall be more consistent. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 20 14:20:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 14:20:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209057.1521175 (Exim 4.92) (envelope-from ) id 1viCar-0004Is-Io; Tue, 20 Jan 2026 14:20:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209057.1521175; Tue, 20 Jan 2026 14: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 1viCar-0004Il-G3; Tue, 20 Jan 2026 14:20:29 +0000 Received: by outflank-mailman (input) for mailman id 1209057; Tue, 20 Jan 2026 14: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 1viCaq-0004IG-5J for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 14:20:28 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2911cec6-f60b-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 15:20:24 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 8A7694EE3BF1; Tue, 20 Jan 2026 15:20:23 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2911cec6-f60b-11f0-b15e-2bf370ae4941 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=1768918823; b=CB55ofH04DEjlVEofm4qEM0P2XnqAo7KmX7qq2xqP7FFRkqY19mKui3Ys2iTElMAUi3t L6wlJwmcnZ7fn3tjlA/bQvjqmKBG13i7dBZExzS0/DdxqYy3nEZ2hrt+CIfY9iOuijQ10 BjRGUWXJ2+zrZ/pVuuK4o+k1FAASlP7GZJsftAVudYRZhhiPvt3LQfGBrrKwuLyUnT8yw lsVXiTbMumns4cWzIoZLtzbDx3RBFdOuFBZuvOgnNRi/qP8WSmhOPz1oiJNGJaI0okedb j/zs5qI90nYdD7hb3TXtBraX/uIwklSeF5YLLLUcEm2OId7KnNKTlZLlkjq6fvsnjxa7M NDjTZC6x4ge/pt/bcXfO6oYxzY73brpIaECUUPEMyn1teJp4J/D0yFFyLJBRM6c1dHGdP u/ADPqpG8dkQOBNPzLFH0lqt0kuV3qvXRkr7Ee+O+4sHSq4g2ecLqsl9L8snN/ixxt9Nw Vx70a8wp/T/vHswSrJedENUgqSJ6UVlgcx5c5dB88lqKdefl7ZOylBBD23bM0+xSmbGQf sbB6bZAl84aMA+/I+c7JZnu9g3VYzffk09r5fV37uLEOcCtvbhrt+vSi/F9xOyG7Q+SD+ MAxDxozY815K1sQ2bU1ZH1ZPxB3BkQAPAG9dCmR2vnXwAAaFlbmMnbJX95bXnkE= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1768918823; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=qt+S6uyW/K0pgpTSAzdgtw0W1RwId9+iIyB8zzdbrfI=; b=E6OPlXr1amIxx3qVVkbBP08WaN5hFEODpnAOBbzMqC1Vu+dUEEANwfcbA6tIdmr6BtCv 7l8xgL2EOZC9HTOFwTd8zMOkSrt8rzYmHBz1HUOhmBsI0NwkRGIX0ibA6EfBgSaK0uDmC jikTzshw6vsRp4kiYowUmTXuBy0i9SjTBZfmUNK6wH1gdSubi0TmyfelYrXTBfdsBBM5v 2qxZJlNSh/dW6X5ZYE044VIbIEI7iKgArDZ6PogQ1rJ+p7EigfYycQQ3beYhTkdYohAZk l1v1fKDQEeOStY9bwaA1QanOeOQe0E9YmBIZwsbhzOqbrAIio2d9cagYdF9WLiGWdaJF/ 51pWLosHtsENxoDv1js03+lwmBrlL/PbNWTWWvWB3Fb5gy1S2v5YJ5vHn1aeLfctmeJW5 GiDPWHr3DTf+JyQK3dsG2hP9WT5vcp/Zkavw3tnWv0jE6AKkfBYyjXphoH50tV+/fy/F9 9Xz6QSS3FQru0mwOLCaOLhFMIOMXFGlgnC0TaeMr6XCJSdNZKEYxX0cuGfaGKXTbbr4BM 3V6CoLrhs2CtuREpfJ8pZqjiqKY5U0m7guZK83GsgGj5h8OD28y3lBRuOtLGJPCSECIKb BV6vEpQXCnH2KmekJTRGdztjW4YzyEKdTC0iNg1trK25fGH5aXp6Xl6s6jYh0JE= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Tue, 20 Jan 2026 15:20:23 +0100 From: Nicola Vetrini To: Alejandro Vallejo , Andrew Cooper3 , Jbeulich Cc: xen-devel@lists.xenproject.org, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Xen-devel Subject: Re: [PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list. In-Reply-To: References: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> <20260120093852.2380-5-alejandro.garciavallejo@amd.com> <1d374226e3f91ab3bbc05c3354c8f8fe@bugseng.com> Message-ID: <0a6eca6eb344e9829ed9e0b381f26e95@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 2026-01-20 13:09, Alejandro Vallejo wrote: > On Tue Jan 20, 2026 at 12:51 PM CET, Alejandro Vallejo wrote: >> On Tue Jan 20, 2026 at 12:41 PM CET, Nicola Vetrini wrote: >>> On 2026-01-20 12:27, Alejandro Vallejo wrote: >>>> On Tue Jan 20, 2026 at 12:21 PM CET, Nicola Vetrini wrote: >>>>> On 2026-01-20 10:38, Alejandro Vallejo wrote: >>>>>> It's clean. >>>>>> >>>>>> Signed-off-by: Alejandro Vallejo >>>>>> --- >>>>>> docs/misra/exclude-list.json | 4 ---- >>>>>> 1 file changed, 4 deletions(-) >>>>>> >>>>> >>>>> Hi. Do you have a link to a pipeline? >>>> >>>> In the cover letter. I only run it on allcode. >>>> >>> >>> I see. I can spot these additional violations from earlycpio.c. It >>> does >>> not result in a failure, but only because x86_64-allcode has also >>> other >>> non-clean guidelines and is thus allowed to fail. Ideally in some >>> copious free time I'd send a patch to create a subset of clean >>> guidelines for the *-allcode analysis that is failing, so that the >>> "allow_fail: true" can be removed. >>> >>> https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/people/agvallejo/xen/ECLAIR_normal/ucode-disable_v4/X86_64/12771570090/PROJECT.ecd;/by_main_file/xen/lib/earlycpio.c.html >> >> The web interface doesn't allow to search?! Sigh... thanks for the >> pointer. > > It's your usual mess of miscasting, enum-as-int, etc. > > Would you rather keep the exclusion and deal with it later or let it > pile up? > I just don't have the time to go into it myself. > Well, including more stuff in the scan doesn't hurt and it's only a handful of reports that could be fixed, but the maintainers will have the final say. This file is not really inside my area as a reviewer, but if it helps: Reviewed-by: Nicola Vetrini -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 14:27:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 14:27:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209068.1521185 (Exim 4.92) (envelope-from ) id 1viChH-0004tZ-67; Tue, 20 Jan 2026 14:27:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209068.1521185; Tue, 20 Jan 2026 14:27:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viChH-0004tS-2q; Tue, 20 Jan 2026 14:27:07 +0000 Received: by outflank-mailman (input) for mailman id 1209068; Tue, 20 Jan 2026 14:27: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 1viChF-0004tM-No for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 14:27:05 +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 17496ade-f60c-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 15:27:04 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS7PR03MB5590.namprd03.prod.outlook.com (2603:10b6:5:2c8::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 14:26:58 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Tue, 20 Jan 2026 14:26: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: 17496ade-f60c-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=chkx7TLfKkiIPkcNOeNp/sqL8cfiD20m6Z6wh0mlujq7sZuujIcXnJ3U/FB2CO9TiPvU/DBsUwrVyDvGlhKBjoTb9EVrendgojXI4G5H2msiYqxeNzB7CsUNww3zRFPwbbFTlFHW46CxqdbLDuirKY9rlUaulo+HqOoSqLPTGK3xsVt3OOuNEzdUc0/MppbQQvuoSDVVqM0AbVS290vnB2KtLFIefHj3DRaPcz2TKuuJBl+cKS94KIrQL65xd3BOa0RJ3fh0TUKxDIHVoqteP8pPrR+g3qaPm721+krAjo/SAEbxTOo0cVSkw5g7Z02NCwYYq+HWksyiAE2jQKnUHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4jgcWLKYtKi4sNyZTzLKVqtZU5hpw87Qe1wOTMcopT8=; b=fatR519X94YLZNXS8JmOUqsQMsGyr6RVyptUEwStQY8bGm3wj0GyC5UexjRWQcjOFOBpTTyQHvr5YjXf0Pz0hzYwbSOydUHio2MyqVFpugYAguADukEQilBpyFjAVmUwM1OjTsy7KdRhNaMJq+3wUiFFr/lkW1v96D/3NlR2eLoRWIFBZTNJ4n3s5lW92zb3Ca+QDZpydxBSh4IEe5QFdVpCaYTMtIVQSo9XP2vpnM8wJaviqtkEWbLh0SmdJ9BTjsGlJphkVWrpxsFWpz3g5KQlfFE+t1wtxH9bG5OMEG3s5fmrMfkX0pVUL4iA0hKoce/eXdvKUPCVV9mYZ5+7NQ== 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=4jgcWLKYtKi4sNyZTzLKVqtZU5hpw87Qe1wOTMcopT8=; b=Sqhzv804WolwtNahnE9/t/agCHiRHaJgTeIOqFuA8t+01bVybCknQBWF3jNqwbDD1rA6qA8SKe/wIr6aJrUDwEFXGQPOl7fJJIF068ioEkg0A6NXLvVMGfHdiCVn1YgLr9mXihfs+ztNxNzkeXXZrteHX8CLH8jFJ4Rd2nu63Wg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <4ec779cb-3cbf-42cf-b744-80145d3cd54c@citrix.com> Date: Tue, 20 Jan 2026 14:26:54 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Alejandro Vallejo , xen-devel@lists.xenproject.org, Stefano Stabellini Subject: Re: [PATCH 2/2] x86/svm: Intercept Bus Locks for HVM guests To: Jan Beulich References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> <20260120095353.2778-3-alejandro.garciavallejo@amd.com> <5a4aa1d9-dafb-453c-bd4c-8da860519f01@citrix.com> <00f36b33-65d5-4681-84d5-e1b2cbd8830d@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0640.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:296::21) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS7PR03MB5590:EE_ X-MS-Office365-Filtering-Correlation-Id: 62935cc5-bab4-4894-d6c3-08de582ff7e5 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?Q0s4MFN5ajZLSmJHamo0OEhJczJtWVNGa3JnNmJxVUkzSFRXUkpQUDJMS0sz?= =?utf-8?B?QWU4WTl4MmN3NW9GS254SG9wc08ycXhIaHdnRkpEZkFielZDeHh2dWFRRHZt?= =?utf-8?B?V0hIY0tadDgyKzZiNGN2YmtyRW9pd1ptMGhZUGx3a3NNaytSbXgzanJYWFpt?= =?utf-8?B?SjM0NmFhbkRxWGZvQTBwcnl5UW9RRTA5RldRb2hTSW4xOTd3dE0zNGVDekYr?= =?utf-8?B?bFBaVHd2VzVGZE9vR3dNSVY4Q2JkSGR3L2JXcG9mS3lObEZXdkdsYzZWM0do?= =?utf-8?B?T3Z5MWVUMXBZYzUyRGp5VEhHWVVUQnAveGZHNFRlL1RDUDB2UFNJYUJCQ3lZ?= =?utf-8?B?c0pORThuZTVBUStEVHB4dU5VNDJrdDZHK3ErSE91YzlNU3dtUm83aUgwQ3BI?= =?utf-8?B?WHNQVEdlc2NKRi9MZ2c1WTdGcGU4cmJUbWE1QWNTazlJQjRHTEUvV0tVOWF3?= =?utf-8?B?L1o2dXFXT3BPcmdnMlBqRy9kN3BSUks3NGgzSHF2VDFNM0lUcjd1b09YSTBH?= =?utf-8?B?WFAzV3FrRWc4KzBzbG1RamRpa1pNV25YYWh6NmZhYm5TMDluT3JUeGNmU2c3?= =?utf-8?B?Q1VVL3lRMFBXNVo4VGJWUzR4ZjdYR3BDTURIN1BlcGZNRFk3eDRRZzZXa2JE?= =?utf-8?B?OWhOdmZJSmVFTzh1UW9scWtLR1ZxK3VDelhpNEtQL25SYVExVU1pWi8vNU5N?= =?utf-8?B?bFNwTXR6alc4aERkSFlZbndxTUhJZUQ0QUV5ek5Kd1dGTnl2M09TNGhlUjlO?= =?utf-8?B?aXBpeTZpYnVQZUJDVDNlY2ZDQk5RYXNsbE03RUp5QVdlMjRsS1ZyMkNtWEMx?= =?utf-8?B?RmY2cXh2aURuMW5mZTB6N3d6OWtxZ0RhelBDMzlwakFSbnhodEFaQnN1eGpJ?= =?utf-8?B?RC8xY3FoNnR1RmJTZlVUUWdNM1c0RlNpdTJrSm9ZMWFQRktuTG5JNjdYWUdw?= =?utf-8?B?eGE1V3AyMjVqcVBjUGpkdWJpU1R1bmVRTGgzQlNuVGZYczZRQkdHODBMOXlw?= =?utf-8?B?akFBNkphcm9YbzJRN3cweU83VU1JUjA4S2VFK3FhS3JDc2N0UmNzUHV4bDdB?= =?utf-8?B?bjNwOVBBb3hoT1doTEhtUHg1MzUxcUNNem4zdHNlUU9IQ3VQdzc3c3VRYUdJ?= =?utf-8?B?Z0M3K2lEWFgrNllwZHFscWh1dHZFMy9Ld3BpNE1MTHU2WXJqTTgra1I1dTBp?= =?utf-8?B?VEZtY2t2V1pJREZ2b09CNno5eGk2ZEcyQjYvVUhwTzJzbnR1SUlBZTBNS0s3?= =?utf-8?B?RjZhc3JYVGwvNUlmL2l5RzFCM1h3WGV0STAwWWYrRW1UN2xuMVFVSDRab1RY?= =?utf-8?B?bmNTaG9HQ0hPcEpEcmhWWVcrb0xHTWF2REl0QmpCUit0dnp1L1hONVIxcHJz?= =?utf-8?B?UklIUjdoaURQNnlXbXVrY1hPTFErdlp1YU44SUw3VTNlaDNaMGswUG1aOWVw?= =?utf-8?B?dnNzeWNCRG5xMldZNXJuMkVpSFFSVnBLMmgzVEVtcnR1My9uL09JeTZQU3ZP?= =?utf-8?B?T2R2WS9KMWhJemhoUEVCUGZ1YWVnTmpCL3NJcjZXQ054c3RUZmhLd3lGVzY3?= =?utf-8?B?OTZIby84M25uKys3Qk9DTktlZ1VvR2RHRDRoSXRCdEY1bkdzWDV6QXo5RUU3?= =?utf-8?B?d2N5NHlnWkxPbWxzSlNUbGRVWC9IOWRNUjl2RFlpSSt2bmsrUXBERTlDaWx5?= =?utf-8?B?THluakIray81eUlKeGJNYmg4dG84RTFxSkZHcUl6Nm1SSno5cVUzd0dPSGpQ?= =?utf-8?B?VmcyRUpoVjhjamtYTGZUTmZSREJpTkdKc0NiOXNOMXRHcUFncVhQMU1rQWg4?= =?utf-8?B?aHFlRFZhTE9WbmlrTEQ0L3FjS1VkdjNkanQ0alk0UWczV2w1dDV6RE1NbUNw?= =?utf-8?B?VVk5QmhvMEZVWG1BQVBRWW4yK2MxVW9yRVdiOVRBcTNwMG5tR2tFRUN5K0dh?= =?utf-8?B?QWVhNzQ2TDg1Q1F5K3FnR3l1ZWxrMElEcldlRFQwcjhLTVptY28xY2IyVVd0?= =?utf-8?B?Y2x6THdOUS91aWl1dUhSZGpLUGgxYzE3Uld1cmpmbjI5dzVwU2FGMzZKcmJD?= =?utf-8?B?a0NIT1lLNjA0OVE3cXJYcFByMzEzQlhub1VBeDBmTlBkcFhOVmJoWGVOelJq?= =?utf-8?Q?bC7c=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YUpuUTN4cVlWZmhSSnV1UHpybCtMRWEzcUJ2SjQ3TVNnMXR1UHlTMGJqdlA4?= =?utf-8?B?VUpqTDBLUlNUaVVMOFJicXBRZXM4U2ZZVkxSdTJKL3RjOGM5SHdCanZ1ZUlM?= =?utf-8?B?R0NoM1ZpOURNaTFkdktKU2YwdmlrVWdBSGZLZHRtRmVtdmVVeTd0RFBzMmdv?= =?utf-8?B?em1EZVFEcGxmamNUODU4OS9kZEdwaWp6cWhFTlVqdGt0T1U1bXlWbkJtSnM4?= =?utf-8?B?S2x5ckx4Wkw2YjhoSjdLbHRaeCtxV0tORFdyMnNoVHAxMytSNUJjOFo3VnBG?= =?utf-8?B?QWt5MVJ5bWFrRWdBaUVhWGZzc1dYbVN3WHhkZ0hTR2d6Nk5zcG5DalIreW5j?= =?utf-8?B?bFFBZzdtNmkzYmhPWTJxZTVIMW9rQm83V20xMW5aWEFKZ2xPenRJRmtzSDFD?= =?utf-8?B?dUVlM2hhWnNSbXhNd3oxSDR2bE9FZ3hjVDM3L0xBU2VvV2h0aWZ6dDdrdjho?= =?utf-8?B?OEozWi9iQ1NTRGRhWWo1QzZWRWpJYThLMWdmTC81Mlg2RHhDZ2RrZ3JhTWRo?= =?utf-8?B?VDFoYjlyekNCVVZFMm1NRk9aSEt6NjdtcC9MVXdSbU1RdzNrcUV1QVY1d3Zo?= =?utf-8?B?OHo3Ym9hQ3hsaXZqeDZtQjlGZ3lIOHRKdGlSOGJ1MXBOQms4cEdtUGZ1V0ds?= =?utf-8?B?UXpNRGxJbWlIcTB3Z1pFbGxQdkNIc285Ryt2eS9zQ3o1eXV0eWtydGVjV1RU?= =?utf-8?B?dEVCdTNUSS9yNFVUY2Y1U0V1R2JnV0x5a09lTE1FZWh4QXo0c3hqcW9pd2FB?= =?utf-8?B?dVRua1BlTGp6d1I4cWRxQkZSM3F6Vjg2VUduTkpPUzlZWFRQM2EycFkzVkYv?= =?utf-8?B?S3IvR1lMRzQ0NDZVeHFwOWdiWFB0STZRYS9RQWNQS0NzR0xoamFsc0ViMmJG?= =?utf-8?B?dXc1TEs3ZFJRV3drMHkreGg0aGUwRVdSY2EwK1BFT0pPNEsrTW9lZEtiQkdx?= =?utf-8?B?aG8vdFl1dVJ3Ry9KanZBNXV4TVZLZlFSUVRXbjBuSi84cUFmc0E4dTFTZXl3?= =?utf-8?B?SVBEbTNadGZUSGxPVHIvMTUyQjUrRWM0UWRYT2NOM1pyeDVSMUd4OEJwOUxt?= =?utf-8?B?UHdwTjhBU1ZDcjI4QWpUeGpkMzlnL0s3MmdSeUFGZkw0WHJoZ0RnT3BwenNn?= =?utf-8?B?S0VnVjRRaEROekVWaUV4a3VFN0MzQXhUcEh2RVJhMlJtY3Q0ZU5ud1FLVjZE?= =?utf-8?B?V2NRWk5JRWExcWhLWUgyN21XWVhOcG5nVEJMTUNQV1h6NnphZFJmY21lZm15?= =?utf-8?B?S3RqWkdzWGQyZngxNDRCTjBxRFJRNzQ5NlE2ZWw5WlhkL0k1Q2c5V3ZkcjFK?= =?utf-8?B?SXVyWjRjUG92YWFhaDhicUw1OTEyRXUzd2NvYnQ1VXBCaTVLQ2RoTEhqbFFa?= =?utf-8?B?SVdOak1MSzh3dS9NTUNVSGdkRytnWmRzSXc4dEZxZnZTQzVkQVEwRnhPUkhC?= =?utf-8?B?V1lSNlU4MytQQWMzc3J5MnBVRWpEQnNDVmd5MUVnRXdLUHMvcjVra3liRUc4?= =?utf-8?B?S1UzR2RJZGY4MXNFeFJKMFczSm1lNFczUC9xb0RlSDczYTBUTG5TZm5DSkhn?= =?utf-8?B?STh6ZWtqbVpsK2VQNzRFdmc0YStpUXhTTHRleTN5ekZkSnptSUJPaUdJSXd3?= =?utf-8?B?UitwTFRIdk0xb3BTcVBEc0FOWEdBd1FrWVFEMmxEMnVoV0NIR2U2MUJpU2pk?= =?utf-8?B?RDFXUGt4MFFCeXhvcG9GZE9qa0l3SVBMeGJyMStyblhSdDBUK0VPNWRrWTZO?= =?utf-8?B?ZHFqemNqSHFoV1l4TGM5K1NrYXZtWS9Zc2pjbG94THkzY3pHT05FMmkxQkpX?= =?utf-8?B?ajRMR1Vvakwvd0pwZWZVRyszbFhLSDkwNVZUdlFQcitrVE1LMXRVQi9xb3Nz?= =?utf-8?B?RXhzeXhtTCtEeE50TEhNa2cwVzRwMjdCbWkyS3gvcU0wL0drZVhhaHhpUkln?= =?utf-8?B?STllR29WL3lGRWpFWVhLVFpoRlVYT0hBdDlrbkY2OHZSRGsreGNjTjJKMnRB?= =?utf-8?B?WjJzaUQySm1WQ09zdlNTOWxRZ3BxZDNxdnExYUUrWHdOd3JoMmZ6NFNTWFVm?= =?utf-8?B?UEp4eDhOL001a0RVbnRFdHRaeEhtUzZja1VqR1RKaVFFU3RWekVsNStiWDBQ?= =?utf-8?B?UFp5TnNOUERnazEwRGpKeFkveUNpUFJ3ckU5SS9DS3Vnci9OWXhRZ0RBdzRJ?= =?utf-8?B?eVo1eTcrdklPRjBpV1pQTkZleURxeHZMUmJtTXRVYWY5VWhybTBpUzZIWng0?= =?utf-8?B?ZmFqRFpnbk9aYU1QRXk3UldrYUFPS0gwS0JnZzN4SFFoOFNGcFREcGU0aThW?= =?utf-8?B?eDEyaXR2OXNwL2p4aUVRYmhiUFZwNFdmV2hsd1h6dXh3N2x3cXFOYXkvaUZs?= =?utf-8?Q?ZMr4KQjHxOto1IC8=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 62935cc5-bab4-4894-d6c3-08de582ff7e5 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 14:26:58.0560 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: UZZqzhr2rd5xocEbxueHBbCk7M0jz/zdxyw6OqUzdq40FM4hHL+6qTQSyrLreIsMK8VLgjdRag2AvrrPGKWrw52vGRhaQaCgmySzUzNe3r0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5590 On 20/01/2026 2:16 pm, Jan Beulich wrote: > On 20.01.2026 15:11, Andrew Cooper wrote: >> On 20/01/2026 1:34 pm, Jan Beulich wrote: >>> On 20.01.2026 14:29, Andrew Cooper wrote: >>>> On 20/01/2026 1:27 pm, Jan Beulich wrote: >>>>> On 20.01.2026 14:18, Andrew Cooper wrote: >>>>>> On 20/01/2026 9:53 am, Alejandro Vallejo wrote: >>>>>>> --- a/xen/arch/x86/hvm/svm/vmcb.c >>>>>>> +++ b/xen/arch/x86/hvm/svm/vmcb.c >>>>>>> @@ -66,6 +66,12 @@ static int construct_vmcb(struct vcpu *v) >>>>>>> GENERAL2_INTERCEPT_XSETBV | GENERAL2_INTERCEPT_ICEBP | >>>>>>> GENERAL2_INTERCEPT_RDPRU; >>>>>>> >>>>>>> + if ( cpu_has_bus_lock_thresh ) >>>>>>> + { >>>>>>> + vmcb->_general3_intercepts = GENERAL3_INTERCEPT_BUS_LOCK_THRESH; >>>>>> |= >>>>>> >>>>>>> + vmcb->bus_lock_thresh = 1; /* trigger immediately */ >>>>>> Really?  The APM states: >>>>>> >>>>>> On processors that support Bus Lock Threshold (indicated by CPUID >>>>>> Fn8000_000A_EDX[29] BusLockThreshold=1), the VMCB provides a Bus Lock >>>>>> Threshold enable bit and an unsigned 16-bit Bus Lock Threshold count. On >>>>>> VMRUN, this value is loaded into an internal count register. Before the >>>>>> processor executes a bus lock in the guest, it checks the value of this >>>>>> register. If the value is greater than 0, the processor executes the bus >>>>>> lock successfully and decrements the count. If the value is 0, the bus >>>>>> lock is not executed and a #VMEXIT to the VMM is taken. >>>>>> >>>>>> So according to the APM, setting the count to 1 will permit one bus lock >>>>>> then exit (fault style) immediately before the next.  This also says >>>>>> that a count of 0 is a legal state. >>>>> But then you'd livelock the guest as soon as it uses a bus lock. Are you >>>>> suggesting to set to 1 in response to a bus lock exit, and keep at 0 at >>>>> all other times? >>>> I should have been clearer.  I'm complaining at the "trigger >>>> immediately" comment, because I don't think that's a correct statement >>>> of how hardware behaves. >>> In turn I should have looked at the patch itself before commenting. The >>> other setting to 1 is what makes sense, and what ought to prevent a >>> livelock. The one here indeed raises questions. >> Setting it to 1 here is fine.  This is the constructor for VMCBs, and >> *something* needs to make the state consistent with the setting we chose >> at runtime. > But the setting at runtime is generally going to be 0 First, we need clarity on what "Initialising as zero is invalid and causes an immediate exit." means. > : When the guest exits > for an intercepted bus lock, we'll set the threshold to 1, re-enter the > guest, it'll retry the bus-locking insn, the counter will be decremented to > 0, and the guest will continue to run with that value being zero. Until the > next insn taking a bus lock. So starting with 0 would overall be more > consistent. Assuming we can set 0, then yes we could drive SVM like this.  However, we cannot do the same for PV or VT-x guests, both of which are strictly trap behaviour. So for that reason alone, we probably wouldn't want to drive SVM differently to other guest types. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 20 14:33:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 14:33:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209081.1521194 (Exim 4.92) (envelope-from ) id 1viCmx-0006pc-TW; Tue, 20 Jan 2026 14:32:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209081.1521194; Tue, 20 Jan 2026 14:32:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viCmx-0006pV-Qk; Tue, 20 Jan 2026 14:32:59 +0000 Received: by outflank-mailman (input) for mailman id 1209081; Tue, 20 Jan 2026 14:32:58 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viCmw-0006pP-QB for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 14:32:58 +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 e9633b56-f60c-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 15:32:56 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-48039fdc8aeso8290545e9.3 for ; Tue, 20 Jan 2026 06:32:56 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4801e80c477sm293813625e9.0.2026.01.20.06.32.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jan 2026 06:32:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e9633b56-f60c-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768919576; x=1769524376; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=yCHzPdOlsZNzg+yXYhpb/iP44Gag993dv0Kake6nFsk=; b=FMsZeZamwq01BerTePNoi56dEJpKLRUthIkSnTYhSoWHn5hzMaVU8kfsg4saxDX9nl URtQe/NP1SteGl6MNpWbCmRGUBeaZXG+Nu/JfJbz/Knt4zJbIEL7QLd0HoI3QHcbqIUJ WOKs+c/9TkoNi1aSngt5oCNrYxbZxVkbhsLLDExyHsderlWWRO9FTzUxlMvsVB3AqQlF BR+OW9D8ZTz7sGVI9OkviN2w2lJKqvkSOwJwi6bB4uQi05xAq9t+iDJhUPi5ktZqF3cX j9uPdsU31Sa2OAKqxeYtsUn/F6DMWe8DJzRCP3XGJeLodUXfg0pmyWwi10oYMRYGTpz+ niQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768919576; x=1769524376; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yCHzPdOlsZNzg+yXYhpb/iP44Gag993dv0Kake6nFsk=; b=KkRV2ii5Sr+H4RgFVcatOJ3V7qfBzZHcCU8X1ojSR1UE0U1N9XQ5BJ4jnbTn7tmbAF kySS05gtzI2ovPauCWYzo8UgjZLIzWbpsLufA29DnNYU3RhlLDbXEE8iYeWvfMkpP8/9 p2hhvdeAXLvn2DVuGvJ40R4rqEO3LRCnvGXuhsYZmlfN5Bo5KUYl10MxHfzhoS1Wq/ol mJZNpHtFYmFc2DO7UhpcG9mC7b7rQdobxAkr8K/mnxO4uYfDBo4XKw3FaU/PwSgeTooO 0i4ZxA5H4FMdAg5YALSN/yTjkcQ8W4SGURjbiTL/DizTJU1Lh1Fi95m5HyJhnOeLyLyu vFyQ== X-Forwarded-Encrypted: i=1; AJvYcCW7leiWdp37SPdzY6vs4MEjgSlN43mvJTAiWsxprJxPOeV8c36uwEEgqdQCSbzuv6yI1XRB2ZtxqVQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YxzyLF0JxFgmwF4X/EVJcpJZkxdmZWuS4FbeGB7wGg/ZhuLImst wkr00yen4K0R8YwPHrMCqjLVAUkqZ29bromoustg7Ugq3vbCYcHWVf4TMTzcmfmJAg== X-Gm-Gg: AY/fxX7ziMz8c0hct/RB4OUwj5esxFjwKD7/TB/CoLnU3PZMCF6SPALHXkC4ISt0WGo PrkcXaSGc6YnwGR5i+dYCGayPXaIII9C/azHxkra5ZoDB/VdyetsVTJ+8XqQPaz+kfiavJjQaL/ iejEmKVhbCO3ZDMEv+N66Wg/W6293Cbt1kWtddOexLNyau4qgspq1xAejittWEhzmNHexiroPBD HmpSKAgSMCM0GF1/1/8nwNMlU09sWnOWbaLfL8YLYjE3SclDVwnQZqqnMqG/NVjw0+mny5off/t mdA1PJWQCyuQImKwnlGMsjNuIc8qOuU4znKQxTSfT7fiNqzdEQPjX4OB36gllz8w1dJ9O4fUkrU 59etKVBGjV5Z7Ooj6YzgdtVwdtyKYL+C7vBib1mcPo6ncT6diVtxnCEEh6DmlD0gnxFYPp/iohw /0SFVZKUMXww2hvyZtaDDYwSu+K/yLqNdAix8eUBOat8PHDyic4gJG/lKxl9HV/9nQCXGKGGneg J0= X-Received: by 2002:a05:600c:6085:b0:477:7ab8:aba with SMTP id 5b1f17b1804b1-4803e79b854mr30543375e9.1.1768919575935; Tue, 20 Jan 2026 06:32:55 -0800 (PST) Message-ID: <48ccad85-8b6b-40ae-938e-b6ef9dae0ccf@suse.com> Date: Tue, 20 Jan 2026 15:32:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] x86/svm: Intercept Bus Locks for HVM guests To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Alejandro Vallejo , xen-devel@lists.xenproject.org, Stefano Stabellini References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> <20260120095353.2778-3-alejandro.garciavallejo@amd.com> <5a4aa1d9-dafb-453c-bd4c-8da860519f01@citrix.com> <00f36b33-65d5-4681-84d5-e1b2cbd8830d@suse.com> <4ec779cb-3cbf-42cf-b744-80145d3cd54c@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: <4ec779cb-3cbf-42cf-b744-80145d3cd54c@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 20.01.2026 15:26, Andrew Cooper wrote: > On 20/01/2026 2:16 pm, Jan Beulich wrote: >> On 20.01.2026 15:11, Andrew Cooper wrote: >>> On 20/01/2026 1:34 pm, Jan Beulich wrote: >>>> On 20.01.2026 14:29, Andrew Cooper wrote: >>>>> On 20/01/2026 1:27 pm, Jan Beulich wrote: >>>>>> On 20.01.2026 14:18, Andrew Cooper wrote: >>>>>>> On 20/01/2026 9:53 am, Alejandro Vallejo wrote: >>>>>>>> --- a/xen/arch/x86/hvm/svm/vmcb.c >>>>>>>> +++ b/xen/arch/x86/hvm/svm/vmcb.c >>>>>>>> @@ -66,6 +66,12 @@ static int construct_vmcb(struct vcpu *v) >>>>>>>> GENERAL2_INTERCEPT_XSETBV | GENERAL2_INTERCEPT_ICEBP | >>>>>>>> GENERAL2_INTERCEPT_RDPRU; >>>>>>>> >>>>>>>> + if ( cpu_has_bus_lock_thresh ) >>>>>>>> + { >>>>>>>> + vmcb->_general3_intercepts = GENERAL3_INTERCEPT_BUS_LOCK_THRESH; >>>>>>> |= >>>>>>> >>>>>>>> + vmcb->bus_lock_thresh = 1; /* trigger immediately */ >>>>>>> Really?  The APM states: >>>>>>> >>>>>>> On processors that support Bus Lock Threshold (indicated by CPUID >>>>>>> Fn8000_000A_EDX[29] BusLockThreshold=1), the VMCB provides a Bus Lock >>>>>>> Threshold enable bit and an unsigned 16-bit Bus Lock Threshold count. On >>>>>>> VMRUN, this value is loaded into an internal count register. Before the >>>>>>> processor executes a bus lock in the guest, it checks the value of this >>>>>>> register. If the value is greater than 0, the processor executes the bus >>>>>>> lock successfully and decrements the count. If the value is 0, the bus >>>>>>> lock is not executed and a #VMEXIT to the VMM is taken. >>>>>>> >>>>>>> So according to the APM, setting the count to 1 will permit one bus lock >>>>>>> then exit (fault style) immediately before the next.  This also says >>>>>>> that a count of 0 is a legal state. >>>>>> But then you'd livelock the guest as soon as it uses a bus lock. Are you >>>>>> suggesting to set to 1 in response to a bus lock exit, and keep at 0 at >>>>>> all other times? >>>>> I should have been clearer.  I'm complaining at the "trigger >>>>> immediately" comment, because I don't think that's a correct statement >>>>> of how hardware behaves. >>>> In turn I should have looked at the patch itself before commenting. The >>>> other setting to 1 is what makes sense, and what ought to prevent a >>>> livelock. The one here indeed raises questions. >>> Setting it to 1 here is fine.  This is the constructor for VMCBs, and >>> *something* needs to make the state consistent with the setting we chose >>> at runtime. >> But the setting at runtime is generally going to be 0 > > First, we need clarity on what "Initialising as zero is invalid and > causes an immediate exit." means. +1 >> : When the guest exits >> for an intercepted bus lock, we'll set the threshold to 1, re-enter the >> guest, it'll retry the bus-locking insn, the counter will be decremented to >> 0, and the guest will continue to run with that value being zero. Until the >> next insn taking a bus lock. So starting with 0 would overall be more >> consistent. > > Assuming we can set 0, then yes we could drive SVM like this.  However, > we cannot do the same for PV or VT-x guests, both of which are strictly > trap behaviour. > > So for that reason alone, we probably wouldn't want to drive SVM > differently to other guest types. Yet we can't abstract away the fault vs trap behavioral difference. I'd take a different position: To have behavior as similar as possible, we'd want it to be uniform how many bus locks we allow to be used without us noticing. If we trap after the first one for VMX, we ought to fault on the first one for SVM (provided that's possible in practice). Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 20 14:42:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 14:42:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209089.1521204 (Exim 4.92) (envelope-from ) id 1viCvm-0000Le-Nz; Tue, 20 Jan 2026 14:42:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209089.1521204; Tue, 20 Jan 2026 14: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 1viCvm-0000LX-LA; Tue, 20 Jan 2026 14:42:06 +0000 Received: by outflank-mailman (input) for mailman id 1209089; Tue, 20 Jan 2026 14:42: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 1viCvk-0000LR-TL for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 14:42:04 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2dfac964-f60e-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 15:42:02 +0100 (CET) Received: from CYXP220CA0005.NAMP220.PROD.OUTLOOK.COM (2603:10b6:930:ee::9) by PH0PR12MB8798.namprd12.prod.outlook.com (2603:10b6:510:28d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 14:41:56 +0000 Received: from CY4PEPF0000EE37.namprd05.prod.outlook.com (2603:10b6:930:ee:cafe::d4) by CYXP220CA0005.outlook.office365.com (2603:10b6:930:ee::9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.9 via Frontend Transport; Tue, 20 Jan 2026 14:41:57 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY4PEPF0000EE37.mail.protection.outlook.com (10.167.242.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Tue, 20 Jan 2026 14:41:55 +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, 20 Jan 2026 08:41:53 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2dfac964-f60e-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZohLDdIpVPd4QT4jddnMdnwCp5r8Ks4g4pcTLHXTWbX7Hvki2MnwhsW35eZNteNufR087ekQtDNNRxr+tOgmvf5ge/wpdjyVBPF8nCAfilieD1APRRjncibadd/lXuKw4ouphduP9mG+NDB50EW7A4Be0raRLNU5hUFF/uMQC8rHBPAxacYkSmI5gycDNv68CrI/6aJ3PJaotV22XsMY2c5Q07EH+RarzwCUbsx3t+2Ref5EZnn3jdAM50ZFRBM4c2e6bym8YviJY8CFdgfyR8lvkDFnJKuZU6e/YH1FId2NxIZJ7l6+BdefekqzOJD8G+tUoloCAaU64IzxojILgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=RPbcw+ui/fJN2VTuuPN9dNeVCrPVeklnWr9PY372TSI=; b=UzDkgqyOvStbPP03mmF87BFIQ/HvCUSBg7d25s4+aLBzHEBY9sbYLKQtQvVytQ0O9certZ51AVQZIuEFqK4ECzZ0PvBSKGRa/2WDNqNU0b8HF+F09N2Oc+T8Ru+S4XgRSDp7kx8uye8UX6Z7+sZ7ZJkveNQ6PXL2VVjDpa9vCZyy8moQe/kcmNs0toDuM2dUCd6WTVOhQ3meTmlSGCOUON7BP2TGZtL8YhIcE6xz7lfR2aKZsyUgJp9V6wSTY5OBgaq5IrutI/IYHLL17onOWxQOVI5Eb68iAjsbDqCIc7jWkW7sEPyY36eu90xn15Fwo7ORrER4klvWZQCZNzSqnA== 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=RPbcw+ui/fJN2VTuuPN9dNeVCrPVeklnWr9PY372TSI=; b=hEsDNmfNCFqwhMu4Ngm4NKipcQHy7JboCf8StxCkgCRc69QXfeK0cWk+ZLeMgYSuXiBgWyLlJIAzHEpgC04cOALgztr3Vk3aWWK6L/EYeRi+5tfmQTfAXeh1ffZ21kvAdj6YnIupIkNgUMeaOqq/HqzOP0JTRZDZNt8JUypY/1o= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 20 Jan 2026 15:41:52 +0100 Message-ID: CC: Andrew Cooper , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Stefano Stabellini , Subject: Re: [PATCH 2/2] x86/svm: Intercept Bus Locks for HVM guests From: Alejandro Vallejo To: Jan Beulich , Teddy Astie X-Mailer: aerc 0.20.1 References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> <20260120095353.2778-3-alejandro.garciavallejo@amd.com> <5c554703-f7e6-4625-be07-4fc607b2c4b5@vates.tech> 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: CY4PEPF0000EE37:EE_|PH0PR12MB8798:EE_ X-MS-Office365-Filtering-Correlation-Id: 1a9d4e15-ecc7-41f2-0db7-08de58320f08 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?RmMzQnRHbUgxeWJzZW91RER1TzN6REhKSEdTV3hpNVd5NElVai9CWEk0K0Vy?= =?utf-8?B?ZndSVDF6aldKRWpQd1c4N2J5TURjaVlHK1FLa1d1T2t3VmZ3ZUF0dXQ4aHR3?= =?utf-8?B?eFdNS3d0dzdmck9GUFRZb21uVTRuRFNTb0Jlc0JHWGtPWFY2ZmpHekExVThh?= =?utf-8?B?U1EyUzBpYytCcXN1QThwK3hsZHNoaGoyU2o5M1hOTDlIYUs1UWJVZzVoUC9Q?= =?utf-8?B?SW1EY2tnWDlnbFdveUdKY2lLRjRubEhuOVMxS0lvSFNxckpYMXZoRGszc3dR?= =?utf-8?B?bHBuajBGbm91akJqa2ZDb1orT3NyaFFSOVAxd3RhSUZ1WUtnSU9NdzZsVlpq?= =?utf-8?B?RnZRelBOUktZUUlmYWwvZm93SHpxZ2V3eDlXdGE2aHY2ZFlPdVNGaTRnMU9a?= =?utf-8?B?bjI5TWY0NGU5R3htTjErU09tZHUydmdoS1YyanJ3ZVlLbVJPeEk1U0Z1UFNU?= =?utf-8?B?V3FKM3FSYnc5QkcraXIrQlBMemF3VG83aUprSEVLME12M25YWWdUREFmTUVV?= =?utf-8?B?QzU5NmRNbTNGSXhyR1FEQnJFajJwaVAzNnBhRDVNNUNrMmtyNzFmSTQvem9P?= =?utf-8?B?ekVNbnpzN3BubVlmL0xESyt0TXNmM3pXb0grQjdxOVJISGlxLzdtNXViUUdK?= =?utf-8?B?QmUzTURrSlBtZDRHRzM3ZlhjYmFEcUpsR1RGY0wxOGNXeTRqOS9jdVRvZ2Z1?= =?utf-8?B?OWdzVDk3T2JzblZad0JCNjJ4RzhRVk90c1M4d1dKSy85YTRoU3dlTTJuZ0ZN?= =?utf-8?B?UllBbWI2U1NYYjJJbjBrSFVQRUNtRXhoeXJhdk9CazVWcTNkSktvaEpJSVhx?= =?utf-8?B?SHBtYkpZQU5Edk1LWkYxTjFxaTdGTW9xZHQwWmR5NHB6WW5QQ3FHWDRWZ0Zl?= =?utf-8?B?L3RIMlFJM0RDSXpkbkFxYjhxWmFqVnhQc1h4VDRTcDJQWm8vejMrdWVFMmIw?= =?utf-8?B?RVBOUmJybDJoTVh4VVQ4RW43V3ZoRnpuNzNZTkkyOHNqWDVPemhXQ05kSzNE?= =?utf-8?B?ak5qY2VueEcvbVB4Z2pudGJMSkJBUnFXOGNoWmxLS2JSdDNtTFV5dzhDaGZJ?= =?utf-8?B?NU5EZERVNWxHSTBmVU9wbkdmZ0I5UncyNWxlenRpNGpIWXBWYnZXU1NWdVpP?= =?utf-8?B?dnRKdG1SVTREZ2JlaGVaeUJMMWh6b0s2SE1ZWU5aYWNoSkNrdnlsNEtvcmNC?= =?utf-8?B?V2loNUtSVFM3MHpPMTRHRll4MEZ3a05rZ1k0dEtZa1hvdCt3NTFKa256V3N2?= =?utf-8?B?SWRsalB6UUl1cWpHK2VyWUlkUDBBU1JmYUxHZjN3cUVIeXVBVTBaTTlqaWR5?= =?utf-8?B?b2xFWFN6RFhpOFFFdVRYbkN6VkNWYjc5NTczaVhuZ2l6TWpZUXZPUjZVclB5?= =?utf-8?B?WC9DUjBTa0g5T1pGVk9OREs3bmF1TUVuQVNybXpIS1gvUXlVMk4ySXRvdC8v?= =?utf-8?B?SWJYa2xOdUUvazVkQ21wY0w0ZWUvbHFjQllKM2xTSGtiZldmaDVUNVZwL2x6?= =?utf-8?B?ZVNuejZsS05HMW5nRmwyS1poTXRsZEJDaFJTbE56RnNhVVJ1WnF5ZWZabDVS?= =?utf-8?B?SVJGVzJwd2dOUmg0UVdtUUd2ZFZXTEJvMTlDeXMxSFl5NDhKRXZha1Bkcldx?= =?utf-8?B?SXlkRGhZWWZXYjhMZUpkS25EWmRNd0lQQmhaMjhuaWxNcno0VFRUbUdZT3k5?= =?utf-8?B?c3U1UVdibEFPZmlSOVBVaWJUVndPbStXQU9iWGpiTXI0aUtQdGNWQTNVYUZt?= =?utf-8?B?ZVU3ejJBQ1l2TzQycHNQUzg1ai9OYUloeEJWS3dIVEpHNGFEVW5YZjR5Rkdj?= =?utf-8?B?R3dOV3pBOUFSazZGRmhmaW4xT3EvbVlOREZQS29aMjk5b3JWVm16bi9BeEgy?= =?utf-8?B?V0VJWVN2am5mQlVQZ2ExWWFXOEJzb21JY04xMmo2ZXVLNW9EdXdmY1VkTHBw?= =?utf-8?B?anBVSWY3VkFsSjBKK25OcXRHZk1SNEVNaUJJcExsUzgrR1FYR0tnVUtUdldn?= =?utf-8?B?Z2xUU2hoQzRQUm9BczIzdW5wUmZyZXQwTzRtOFl1QVhHeURYTU1PTTBPTGJz?= =?utf-8?B?Nk5mbEk4YUo4QUhIOVB1UDlLMUxITi9xVVc5UDdiVTcraXo3OTZVdFlPRTVl?= =?utf-8?B?ZWNIRS8rckovWEIrU3owWXNMd2J6cHlOS280R2V2YWRlTTROZ3ZUTEhYMXo2?= =?utf-8?B?Nkc4aEVyM1oyNEswSmdhNXA2N0JHK2JVR0c2UXJRZkRXZnZQZENkeDFKOUxm?= =?utf-8?B?cmlXMWVLRjJXUTNKckFVS1lPdDVnPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 14:41:55.6114 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1a9d4e15-ecc7-41f2-0db7-08de58320f08 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000EE37.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB8798 On Tue Jan 20, 2026 at 2:29 PM CET, Jan Beulich wrote: > On 20.01.2026 14:11, Teddy Astie wrote: >> Le 20/01/2026 =C3=A0 10:56, Alejandro Vallejo a =C3=A9crit=C2=A0: >>> --- a/xen/arch/x86/hvm/svm/vmcb.c >>> +++ b/xen/arch/x86/hvm/svm/vmcb.c >>> @@ -66,6 +66,12 @@ static int construct_vmcb(struct vcpu *v) >>> GENERAL2_INTERCEPT_XSETBV | GENERAL2_INTERCEPT_ICEBP = | >>> GENERAL2_INTERCEPT_RDPRU; >>> =20 >>> + if ( cpu_has_bus_lock_thresh ) >>> + { >>> + vmcb->_general3_intercepts =3D GENERAL3_INTERCEPT_BUS_LOCK_THR= ESH; >>> + vmcb->bus_lock_thresh =3D 1; /* trigger immediately */ >>> + } >>> + >>> /* Intercept all debug-register writes. */ >>> vmcb->_dr_intercepts =3D ~0u; >>> =20 >>=20 >> According to APM, >>=20 >> INTERCEPT_BUS_LOCK_THRESH does >> > Intercept bus lock operations when Bus Lock Threshold Counter is 0 >>=20 >> I assume that when set to 0, we intercept all bus locks, so if set to 1,= =20 >> every 2 bus lock (since we first go from 1 to 0, then at 0 we intercept= =20 >> the next one) ? Correct >>=20 >> I think we want that to be tunable, as intercepting all bus locks may be= =20 >> too extreme we probably want to intercept every few ones instead. > > Otoh bus locks (as opposed to cache locks) would better be rare, or else > perhaps such a guest deserves some extra slowing down? > > Jan I agree with Jan. buslock operations are so rare it's not worth being lenie= nt about them. They ought to be more expensive than they currently are for the caller, in fact, so they notice and not do it because there's rarely a rati= onale for them to exist at all. I'd be happier if the ISA didn't allow them at al= l. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Tue Jan 20 15:15:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 15:15:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209101.1521214 (Exim 4.92) (envelope-from ) id 1viDRb-0004qf-3t; Tue, 20 Jan 2026 15:14:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209101.1521214; Tue, 20 Jan 2026 15: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 1viDRb-0004qY-1J; Tue, 20 Jan 2026 15:14:59 +0000 Received: by outflank-mailman (input) for mailman id 1209101; Tue, 20 Jan 2026 15:14: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 1viDRZ-0004qN-LW for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 15:14:57 +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 c469c1e3-f612-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 16:14:53 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA1PR03MB6419.namprd03.prod.outlook.com (2603:10b6:806:1c2::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Tue, 20 Jan 2026 15:14:48 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Tue, 20 Jan 2026 15:14: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: c469c1e3-f612-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iTnmBKNbQjefLXC1NoFMHU3Hi907K8uZVYS7wTMWAXNzO90+ePY1jTgpfhFgfqOBqw4oTRGuHN1lftx5+qEdceKSNCeghuhZRa6EmQY84+1AiVP0aE/eetumMC2PPq1+SO62Tyi/wr67M4/xsVIe7702KVM+W1drTxh9Z2H625Bul6WNm93fDKWkoG7Eii0QnL9uOiVDJzH6R8rAemaBZgnwd8TwQxYUHXmcz0qsZC1fvqWQJdn4Kw8X2Wd6RKVxlo8l7RBcEYi6QznzZWjHKtG69bTwDoDb+yaZzh0hoJVxIdG7+/lV0TjprR4w8Gk5fXvzWf7b8Ff/fSK0o1kJZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lp9k0SGCJ5kwC7jsQWpBu3yCDk7tRTXusSApoQK+Zg4=; b=JgznqKozsHZcI9qrAJ8Y0544J+GAQ7Y3F/P4jGP9zKWyi6aeUfS3cshzygwWIh0XlLLFJtOgF2F0hfn4KnKnKZgzyOwk51OKG3KhDEsA45FTH7dZuTTdwGfHETw/FITRrDeQTfwSLEI7T2a1RmQrIC6yGoMwndu7zc2+n8olUw6U3EWJREkgX9TTSCO9jV9F+FLEpZW6GAlk6audQJsBHL2WCfGK+Dg1cV/I8fWi+VRfL09HvdnY/C9px0iAVa8coVYCb9BpH3e8RkwbcjNfO0kW84B2tTuVeFehg62fkGS0ZBE4nidms4g9Uq0IsUg+dlT23gezScbpcAmLtihcGw== 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=lp9k0SGCJ5kwC7jsQWpBu3yCDk7tRTXusSApoQK+Zg4=; b=s5a2HkaAzu9jioV2GNut6MyNI2hmtg1LVYgJasviM1CvLSoLj9aoxNrxKzbgtjrDvuNFhL02ePP1d0pIUVgWxgGfkMR3wqcTh11CKzjLjMPl5qvLSR5/+gmaw7X2Mf17idibWc6BSLkzdqIsBa8TGhh/rO7vJBW1RW4fpx662uU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Tue, 20 Jan 2026 15:14:44 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , xen-devel@lists.xenproject.org, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Xen-devel Subject: Re: [PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list. To: Nicola Vetrini , Alejandro Vallejo , Jbeulich References: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> <20260120093852.2380-5-alejandro.garciavallejo@amd.com> <1d374226e3f91ab3bbc05c3354c8f8fe@bugseng.com> <0a6eca6eb344e9829ed9e0b381f26e95@bugseng.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <0a6eca6eb344e9829ed9e0b381f26e95@bugseng.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0479.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a8::16) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA1PR03MB6419:EE_ X-MS-Office365-Filtering-Correlation-Id: 2b9e5914-70f7-44ba-de0d-08de5836a6a5 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?dGUvL2NJbUcvNlRvY1JWTThEV1N6Qzl6SnJmSlBOMm1HdTRyWnBBa1U2dS95?= =?utf-8?B?a0N2UTNjOU9TazFsVnExbndqdHRlTG9Sb2tWNzVKQVo0R3VWVUc4NXNvdW1x?= =?utf-8?B?dHM1RXI5Yk11RFJxOEtYTXk2ZHUvUnUzc3A1cWI1MGprV1J6OFZ4Z2lIYmh3?= =?utf-8?B?eS9RRmRaS254REtSZUxVcW9vYW9iU3F0SmFJdm9Zb2RkVzlPb0xvWHFHYkN6?= =?utf-8?B?M1ZmaWZDTjJZRzBKK3p3bkp2dnFPektKcC92NkU3S1Q4aGZzczFzcjlpbC9H?= =?utf-8?B?VkVDbENXcUVsOGRJcWd1TUNqWnZYOXBxSzhSdFU3azlST2RiR2FEdUorY0hr?= =?utf-8?B?YVhvRHFha2pyd3RyUHpkc04wWEV1TUhnREFWZ1lCVkVOUGxFbjlweVQ5VDMy?= =?utf-8?B?K00raVNBMXhaMFFXbDVkSjQ2VFlmeWFPcWNJMC9hdEFpVjMxQk9kOUdnTXIw?= =?utf-8?B?TytxK2duRFJMTkZybHdGdmFWNmRaSDhtQXJnbDNEZGJYeHFyMWpUTXZqWFVj?= =?utf-8?B?c0xuRmxDSFRQVlZMWGpnbThaaC9mblo2ZFlkVEUvWUkyc2Z5bnUxeTBtV2Fr?= =?utf-8?B?ZTJmd3dmVTBZWGprbDJVRHYxMCtycFJ0cnZBbjIrZG8ySE9xSXR1MTNRQjls?= =?utf-8?B?UExNbU41UUt0a3ZKN2J2YThMZHF6MzdZa2R3b0d3N284OC9zMXRhd21IbERN?= =?utf-8?B?dTdua0Q4ZE92bENQZG9VWVNERVR2QlkvcmlsSDhnQXlwWnI3SjN1U014TVRL?= =?utf-8?B?SE9iMFREOFBmMm9xUFFOY2FxVTJDOFZ3bS9wQmhZaXlOSmJqRW03SkdnU0Ju?= =?utf-8?B?TDdXSHJRMXdXaExzUDN6US9TME94RGpkRm1BK1FGVlR4YTlkbTBGNDFzM2lR?= =?utf-8?B?SElkbENTek5FZks4VE1PRHhvbVNwTytZd2xvV2llWEJpTnNFMWptZFZRT0F1?= =?utf-8?B?SDdmaTV4MUpxcHRDVkJLWms5QWxwS0orbkIvYlR1S0h4RzhpU2ZmYXJEV3h6?= =?utf-8?B?aGJhQkQ3bzNDWVp1OS9XUjJtY0ZxRDg1VEJIVk9MY1ZoUzlxRnRIR3BtYldY?= =?utf-8?B?THNBWGRJSFN1N3d0YW5tQ3NGa3IxOUdyS2x0ME1JMzVBMVZEd05SQWU3NWlh?= =?utf-8?B?RGxhSHNncXhmNDRyTUZOQ3RzcUF0eXZNRkh1bTZoMm40TUFqcEUxbit6L28r?= =?utf-8?B?Q3hWMWszN0ttK3lTbHVNRFloWHJNa0gvZEp4M0RlenBxbGpMaVQyeXhtYk45?= =?utf-8?B?UEpDZG8rZytFcGZsUFRwSjRveGhNODlYbVJhZ0pJZ0pmRVhxbkErVW8vTnZE?= =?utf-8?B?Zit2NnVwbTNUaG94VEVGQjF4Vzl6SHdNR2ZueVc1U0U3Vm1VVXdIVjBqdFdu?= =?utf-8?B?OW9KVzhOQVRDQmd6REFhMS93dzFDQ1l2eDhTTHVHMUtKUllUR1hsTlVQWHVu?= =?utf-8?B?MTExajA4MnRPbUtBU0NaZ0tmTDVLd0NSZGVMSzV6dnJOcHFIOXBHeEpZQmUy?= =?utf-8?B?UDhDaVd3dDQzK3lqcnM3R1FtYXpXODRZWGs3RlVoZE14b0pEcWRZc2QxRjBh?= =?utf-8?B?RHZRQkdaZnFzeDdQS05PYkxKTGhQQitiVktRS0FtL0xPNlhiZE1yUHlnendJ?= =?utf-8?B?TitSR3k3TlB5eEhwNDRXNlFMeXZPdUVybkFCUHdpVVU5cytiN0Y3QXlLUDBL?= =?utf-8?B?WUZLQ2xmWDNrVzI0REdSNjAzK0l0cUhaOTNOT3U3Ni9HU2dFYUZMUXZkaWdE?= =?utf-8?B?c21qWTdsNlFqTU11UC95ckhtY2FRaHVteHR4ZW1vUWtkaXRrUTZNdmI2dTV2?= =?utf-8?B?dm5WemwyTnFVVzV3cTE0ZEN1WnNxTlZSVXE1V3BFL0hvNXJvTjZ1NENyNTYr?= =?utf-8?B?QXBqb1NVWUI2VnVKRjhwTFd6ZG9nNnIyRklMMk1SRHVCcFBLWkE0YTRZeis2?= =?utf-8?B?SnVWQ1FhbGthT3NEQ2VERkxVOG45NTVaN1dEcmhPV3h1VUlrTkkrQUxrVzBZ?= =?utf-8?B?MG9pcFZPZHUyZmlwVit3blY4RnI2c0twWU1zRktLL1JHT0hsVFhkNnFIQlFU?= =?utf-8?Q?KmGh8F?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MHRsODZnNis5NzZqL1hCc2FBd0NHbXFBdlJMSHBCeEZzellsWm1IUGRMd3gz?= =?utf-8?B?NVprZ0VwMHg0YjdRRHE2dHFOTG52amIyYk04eFlmUWNwYlJDKzlzQkEvNXdh?= =?utf-8?B?RitTTmdDTThEMFAzV3JMTEJGYlh6emc3U1Q2elY5czIyNXZGbGpKTmgwd0N2?= =?utf-8?B?b2pDd0IyTFBYRjc0cm53THl1Q0hBM3BteVliODJKc2lZL1d4Y1ArNFNSNUZt?= =?utf-8?B?VU5NVy90bXNJSGFlQVlDMGpnUjJsTGI2RGVpWDJ3ZFhCbEd3Sm0yN0pVakVY?= =?utf-8?B?MktmZW03cTJDcDJnaGVnVTFLcVNoeUNqcWpUcDA1S1FyRDJ5ME15UWRRcCtq?= =?utf-8?B?cGl3bHBPc0o2eGJoeGtOSWlwYThTamtiZEdQZG9OSW1NeHRHWmUyb2t1K21u?= =?utf-8?B?Sm11Q0lQZ2pUSlgrdFlMZmhyMVI5MzhScEhLdHlKUDFLblVSRDhMblBZVW5o?= =?utf-8?B?UjVTbVVObkNjYnZZejE1R29WNUxmUnNQWHZCeGQrOE9tOW9RQXB1RFZnV1Vl?= =?utf-8?B?RzZ3ZlRPZkJRQ1IrSDRORDBLTGtZMHYzWXh0bERrUWhPTlF0OElRRHA4cXhM?= =?utf-8?B?dFFkdUNkMDFsQlZab09CczY5TjVMeTZIU01TWDZ3dVlzTUhEV2RSUXRxcFlx?= =?utf-8?B?am9ZaDcvamVUS0tCc2dyQ0w5REVaRTQzbFd4N3VrQmROaHJRajZUaFovZ0Jv?= =?utf-8?B?WWx4WTljV0VaT25qc3UwbGltWG1Tandqd09PMGhuWDVOOE8rV1F1MzNydnlP?= =?utf-8?B?ZGhwZllHVmFIZFJ4YzdXMEdXMkFtYjNMa2hPMEg5Qmc4WStKbXR4ditCU2ZL?= =?utf-8?B?SlR6RVd4VFg3SElaTDd6cHk1ZTZFK20rQ1FsN2RkaURmM3R5MGt0TXJoUVNG?= =?utf-8?B?WlJYb2NDOWRFNFNSL1dNK0VabG1JTlcvRzhxRlkybXhEdFgyZG0rRWJPK2dw?= =?utf-8?B?NFFORENQV3pPU3c3dVlUaEk1NjJkMnRkNzhlbnhyYWwrdGlZNWNkSE55M2FP?= =?utf-8?B?c09yaHVocnpKNEJPTTJPckFBdGlkUVR3THA3OHJudVpJeUNweEFlaHN6b08z?= =?utf-8?B?ak1JcWJ4OHpoWm0wL1dKTVhqNXFGNTJkeGJyYlFJWnR5WGluZzJvMTBNWmtE?= =?utf-8?B?REZsdjFJZUJDRU9jSG5hTHRpVXduZGw1ZGFGLzFrYnFXZnMwb3Zhd2FxMzRh?= =?utf-8?B?MUVHSUM4Wm8vazZkbEZ1a0RPR0ZqZWpQbVdRSjZiNmVhcW52dTkwWTJGKzdp?= =?utf-8?B?SXptVnFaVXFISGJFeFpWYlFoM3d4SG9nWHh2cmJLSTZMNFRxUEVKTUwvMDEv?= =?utf-8?B?WGsxT3lZYUQrSHozUzNzM2d3clR1S3d2a21BMEVyNmdhdndJUjZDR0xHelNF?= =?utf-8?B?UTJaNEdxdXFCWWJlL3A5dUJCUFZWUGhuMGRKNDhSaEpqRndKT3lDZkRJYU9Q?= =?utf-8?B?SHJRZHYxd1hYM1c1c1FNamF1TmR0bFl1UDlVQVY5Qk1TNldMNE5GczBtT0JV?= =?utf-8?B?VmtPK1hWNE9VczI4aHhqYWlQMGFFYkx0aityZlBDQkUzcnBlV0E4cndRZmxO?= =?utf-8?B?b2RPOWNJZjNoY2FnUTlob3N6VmJkQmZhajVrVWRNOWp3L0hwRE1jSDNTWG1w?= =?utf-8?B?NmlZYmVrb3l0dDRlc1ZVZlhpT1VWQkszWTdDY1lDZFZKbGx1ckRrTCtFaUFt?= =?utf-8?B?azhQaG9NTDd0bHp2eEJaZDZYd0xmRU5EMVBnWGdldUowWG5KbExiRytucUNS?= =?utf-8?B?OXF4SnVMV1NQSUw5QmpaeHd4VnFOUDJ4WnpQZnBpOVJTdE9hRVFNOSsva2Rh?= =?utf-8?B?K3BGL1BRcWhOaS90YlozdG1UK0FFS1BJcGJIMEF0akNqdVJueEk3NnJITlhB?= =?utf-8?B?TU96b0h3bDE1MGlVVUdyWUJBWkRjZWxSS3JTZFNSdHE1VzVSbkNUK3N0dENj?= =?utf-8?B?UUFTVnJOcmh4Q3VPT3lsOGhiVHRmMWZFNE5Kb2NTVUJpNm1BQ1ZFZ3ZaOHRo?= =?utf-8?B?Nlp5aXI4K3BFS290MTlDcmtxbEJMVFF3MGh1OUNvNm9PSjRLRGx0c2RMeXNL?= =?utf-8?B?Um1ObVlnalFaK1JjdGRQdHRuZDU3aWlFUS9ObU4zdDVwcEw1RGJkdDBSWHBF?= =?utf-8?B?OVZ1RFlUY01acGFyZmZzblQ4a1hsTEp4Wkc1TDUvL2RSMlRTQk0vL0U2dXpJ?= =?utf-8?B?WEgvcVM4bE80RnNWNTczU0Q5TjJlVXRsUW5EQklIdzFyVVUyS3BsYU5BUHpw?= =?utf-8?B?ZlpWRTF5MDhGaTFRZDF2V2JkZ3RXanpNSDIwd0VpcENOYzRlVzRkVHkrSDhD?= =?utf-8?B?eVVuclNScHpHWi9pSEtzK2JhbkpncnB2UkoxV1lYeTdHYTkyVGJrbk92ZnlT?= =?utf-8?Q?LhadviOqJlTCNYjs=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2b9e5914-70f7-44ba-de0d-08de5836a6a5 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 15:14:48.1545 (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: UZATXbk/Pq1/mUM2xHQAjvxpMHJH+AH70BGs9x47+8+5+kjuyqF+h3aGuxyx1ynigyqHPkUib48j2sxxRodzdGgXQ4jpgeznfv9ftiFyBCM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR03MB6419 On 20/01/2026 2:20 pm, Nicola Vetrini wrote: > On 2026-01-20 13:09, Alejandro Vallejo wrote: >> On Tue Jan 20, 2026 at 12:51 PM CET, Alejandro Vallejo wrote: >>> On Tue Jan 20, 2026 at 12:41 PM CET, Nicola Vetrini wrote: >>>> On 2026-01-20 12:27, Alejandro Vallejo wrote: >>>>> On Tue Jan 20, 2026 at 12:21 PM CET, Nicola Vetrini wrote: >>>>>> On 2026-01-20 10:38, Alejandro Vallejo wrote: >>>>>>> It's clean. >>>>>>> >>>>>>> Signed-off-by: Alejandro Vallejo >>>>>>> --- >>>>>>>  docs/misra/exclude-list.json | 4 ---- >>>>>>>  1 file changed, 4 deletions(-) >>>>>>> >>>>>> >>>>>> Hi. Do you have a link to a pipeline? >>>>> >>>>> In the cover letter. I only run it on allcode. >>>>> >>>> >>>> I see. I can spot these additional violations from earlycpio.c. It >>>> does >>>> not result in a failure, but only because x86_64-allcode has also >>>> other >>>> non-clean guidelines and is thus allowed to fail. Ideally in some >>>> copious free time I'd send a patch to create a subset of clean >>>> guidelines for the *-allcode analysis that is failing, so that the >>>> "allow_fail: true" can be removed. >>>> >>>> https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/people/agvallejo/xen/ECLAIR_normal/ucode-disable_v4/X86_64/12771570090/PROJECT.ecd;/by_main_file/xen/lib/earlycpio.c.html >>>> >>> >>> The web interface doesn't allow to search?! Sigh... thanks for the >>> pointer. >> >> It's your usual mess of miscasting, enum-as-int, etc. >> >> Would you rather keep the exclusion and deal with it later or let it >> pile up? >> I just don't have the time to go into it myself. >> > > Well, including more stuff in the scan doesn't hurt and it's only a > handful of reports that could be fixed, but the maintainers will have > the final say. This file is not really inside my area as a reviewer, > but if it helps: > > Reviewed-by: Nicola Vetrini > I'm not seeing anything in that report that's on the clean and blocking list.  But to double check, I've started https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2274001675 which is this patch in isolation to see if anything shows up in the *-amd runs. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 20 15:26:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 15:26:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209114.1521225 (Exim 4.92) (envelope-from ) id 1viDcJ-0006iU-8a; Tue, 20 Jan 2026 15:26:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209114.1521225; Tue, 20 Jan 2026 15:26:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viDcJ-0006iN-5y; Tue, 20 Jan 2026 15:26:03 +0000 Received: by outflank-mailman (input) for mailman id 1209114; Tue, 20 Jan 2026 15:26:02 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viDcI-0006i9-Sp for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 15:26:02 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 532fbb5f-f614-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 16:26:00 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 201EE4EE0750; Tue, 20 Jan 2026 16:25:59 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 532fbb5f-f614-11f0-b15e-2bf370ae4941 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=1768922759; b=QXXljVw3Ko32xeaD7dLhUbUFYt1hLvmB3kAbizDrsgd/5U5iB0Ebm2/lCpFGNBK51Nk7 OEHp7vkhFp5XP1uATZuhg24+VdjaO7OjjiQzEkuozVU7SpVw44PoE4XyopHrP7GtjqSgj MVSONRym29ETU2GnJ5KruaeR+f6vq9YkLam4gLqXLTgGr3yBYJvGxdFd4lIDcawQ/RPL+ JK9bkA2PM6NfZcfH5yP8PA4wa9lLj/h/C994OCC77jEBQNv5ybhhyUWts2kbBIQq1o+MP 0vJGEPon+nq+CqYOyMSWDWR4exZYOAzuR7sjCdQuj2dzztT4dd5NIeTe23MSGal6ZbYs/ oDTHoaEQREpfa3zPmPLxh8a1IzprqGlDBm828gt1zSzt23qTo9FlPkB92a0l2qqeLqhay J8ac5dL3Z2RG4yfEld6wkenbtyvAo++HvkhZvsDsh0bKN6a1SRzBbrmivaw8XtADXs5q7 Lk0kecCBpR6a1b2UcGSWsv/hkLUFP2IJ4V3DwQe8TfYNAA8COs3n85RVtI4XJqqIunFH0 XAbXxO8pDDMmjaVaoxXFZkj5R10AN5ASqyIvYsaPUjWGKd9f0oE/Z47WkIV3p8+r79aQm Upe5S6YPe+fPUH0dFETdS5LJzxxC31NsPtajGU0Lqe6sJBXRKoAyxTAQPfyU0o8= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1768922759; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=1X2fBUsSdCnu5gLNKdnwWlqRGMJT3adt2MdAjjk/8v4=; b=wVJYO5UD2qGmfqzQmLJwlrav/KjWokxvbIyxNKTXyabowpNu5diNoyZuCX18VSm2jV4I RQkYl+vpu/ZBO4V1Rv5iEEVCR5xMJ8GWG4kJBOM6ibhh7tS9pOlDe2tZpJKY3QeauaJmp GPaGD4j/S5MjnGMTX2Z54Nbd+AHNY7eclIHw2+1ksDwFw9VyFlh8DGnRqq+ehAwOFl2wG 8x6vY72dwcq9wQAFZ3eBh85oHQ6q/dq8oEGrRrEoLech5qTrrJcIPfLFUuXvoYXNRG3uf ZR+rk17i27gvyX9CQ75NOAPpNwYF6toqxWqoC2rZ+3TKTwB7EZ+zOC8ys+Tgbdj3BRwM1 raQN1s75ptSO3s4wU7mBnM0wlBMrn4/wXOTlE1eqxWWYjognT2pxi2l7lJ1OdzjBKAGNX Kgn+g5o5xc6jGvTmm22QDgf2NM1LOVFqLaQ+dIEWVOmIutX8Wihwtk1ugUtli5tpyNJO8 RQdzC8nKpsqXivVonQNxHwfZ5fbHOIQBBT9w6y0QJWBm8cXQW2la/zcC4zkp89JdDZmMY 7IKo9lS/xyp+d8geMbCTUUrUM/2WbKEZiE+BGtrNDM1JnUsIuodNIUQVesduEUpiChSxR bFgzQajC8ZulNuIHjugyBYH7mOm3ktdgOlOOIftJkKq80QoTDMSW54BpMDp7gPI= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Tue, 20 Jan 2026 16:25:59 +0100 From: Nicola Vetrini To: Andrew Cooper Cc: Alejandro Vallejo , Jbeulich , xen-devel@lists.xenproject.org, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Xen-devel Subject: Re: [PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list. In-Reply-To: References: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> <20260120093852.2380-5-alejandro.garciavallejo@amd.com> <1d374226e3f91ab3bbc05c3354c8f8fe@bugseng.com> <0a6eca6eb344e9829ed9e0b381f26e95@bugseng.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 2026-01-20 16:14, Andrew Cooper wrote: > On 20/01/2026 2:20 pm, Nicola Vetrini wrote: >> On 2026-01-20 13:09, Alejandro Vallejo wrote: >>> On Tue Jan 20, 2026 at 12:51 PM CET, Alejandro Vallejo wrote: >>>> On Tue Jan 20, 2026 at 12:41 PM CET, Nicola Vetrini wrote: >>>>> On 2026-01-20 12:27, Alejandro Vallejo wrote: >>>>>> On Tue Jan 20, 2026 at 12:21 PM CET, Nicola Vetrini wrote: >>>>>>> On 2026-01-20 10:38, Alejandro Vallejo wrote: >>>>>>>> It's clean. >>>>>>>> >>>>>>>> Signed-off-by: Alejandro Vallejo >>>>>>>> >>>>>>>> --- >>>>>>>>  docs/misra/exclude-list.json | 4 ---- >>>>>>>>  1 file changed, 4 deletions(-) >>>>>>>> >>>>>>> >>>>>>> Hi. Do you have a link to a pipeline? >>>>>> >>>>>> In the cover letter. I only run it on allcode. >>>>>> >>>>> >>>>> I see. I can spot these additional violations from earlycpio.c. It >>>>> does >>>>> not result in a failure, but only because x86_64-allcode has also >>>>> other >>>>> non-clean guidelines and is thus allowed to fail. Ideally in some >>>>> copious free time I'd send a patch to create a subset of clean >>>>> guidelines for the *-allcode analysis that is failing, so that the >>>>> "allow_fail: true" can be removed. >>>>> >>>>> https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/people/agvallejo/xen/ECLAIR_normal/ucode-disable_v4/X86_64/12771570090/PROJECT.ecd;/by_main_file/xen/lib/earlycpio.c.html >>>>> >>>> >>>> The web interface doesn't allow to search?! Sigh... thanks for the >>>> pointer. >>> >>> It's your usual mess of miscasting, enum-as-int, etc. >>> >>> Would you rather keep the exclusion and deal with it later or let it >>> pile up? >>> I just don't have the time to go into it myself. >>> >> >> Well, including more stuff in the scan doesn't hurt and it's only a >> handful of reports that could be fixed, but the maintainers will have >> the final say. This file is not really inside my area as a reviewer, >> but if it helps: >> >> Reviewed-by: Nicola Vetrini >> > > I'm not seeing anything in that report that's on the clean and blocking > list.  But to double check, I've started > > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2274001675 > > which is this patch in isolation to see if anything shows up in the > *-amd runs. > https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/people/agvallejo/xen/ECLAIR_normal/ucode-disable_v4/X86_64/12771570090/PROJECT.ecd;/by_main_file/xen/lib/earlycpio.c.html#{"select":true,"selection":{"hiddenAreaKinds":[],"hiddenSubareaKinds":[],"show":true,"selector":{"enabled":true,"negated":false,"kind":1,"children":[{"enabled":true,"negated":false,"kind":0,"domain":"clean","inputs":[{"enabled":true,"text":"added"}]},{"enabled":true,"negated":true,"kind":0,"domain":"kind","inputs":[{"enabled":true,"text":"caution"}]}]}}} Looks ugly, but it's a direct view into the clean:added selection: R10.2, R20.7, R7.1 in short. -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 15:28:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 15:28:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209121.1521236 (Exim 4.92) (envelope-from ) id 1viDeL-0007MY-Ls; Tue, 20 Jan 2026 15:28:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209121.1521236; Tue, 20 Jan 2026 15:28:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viDeL-0007MR-HK; Tue, 20 Jan 2026 15:28:09 +0000 Received: by outflank-mailman (input) for mailman id 1209121; Tue, 20 Jan 2026 15:28: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 1viDeK-0007MF-C2 for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 15:28:08 +0000 Received: from mail14.wdc04.mandrillapp.com (mail14.wdc04.mandrillapp.com [205.201.139.14]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 994665e8-f614-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 16:27:58 +0100 (CET) Received: from pmta16.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail14.wdc04.mandrillapp.com (Mailchimp) with ESMTP id 4dwWRd2xwTz8XRwk8 for ; Tue, 20 Jan 2026 15:27:57 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 1547d01774b0433ab9b06053565abfce; Tue, 20 Jan 2026 15:27: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: 994665e8-f614-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1768922877; x=1769192877; bh=PKhCAAD87VzD+4z95CXnWFWiEpmifOzout8OQHxo4rw=; 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=VUOQew70N9S1Rzjtzu0zy1tX+Z7RPGy9ygVb+mTnouIONTF4IIJMDH0uz4vJEBDQt JTENXMNCWl7SgZLRCaiewhcFdOABDXKoJ6ljvqcTf/KAz38LseZE3EN2w9xhqK/R15 SlbwESkdFkEw3aFFbsTB9EVK/NbGXVkAzO3R/ddMVwNCwaKAaP/wX1GeUycvd0MnXi nyPWJQne7FPN8RY2kop2wSJ7OPGOp6u7Ks4zZMGdZ8oVd6f9tBEb5r/77ft1QI603R 8LUYOsvWWWxj1s8AcuSgCisiOvLlmNyKocJQ5QRd5TCRBcoiq1mh802u/3vYGngBxm 0AbeN+eYp6fwg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1768922877; x=1769183377; i=ngoc-tu.dinh@vates.tech; bh=PKhCAAD87VzD+4z95CXnWFWiEpmifOzout8OQHxo4rw=; 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=xs7w+B6m7Wwubhguafks/+/8BEO/IeVOmdKBCXmencwFD2QAWCNRnggOKjYv1qr+I NzLX1q+ExcrScK//pRjudGuP9hjRuZq1RllfAIMZW7uOPaNPd+rPt5hy1hV9zin2fl mGqe7gcBP/Hz/Z8usAWJ6VNHzyy23T+I/hseRBDymRzAxEI1NCGnItonD2eBp7PHbi V4E0V/wBSU/x1yd0y6cj5aLWF3qxTalK4NLVwMXi4UNQsjoWUYUgPiflcWsiKweYTl MtVdCwYmL6dl+6UwAacww0uq8JlwVh0GbT+1ttr7ChTPzXH06HNiUG1k9drH+Kz045 hjSWnrrm5u9Pg== From: "Tu Dinh" Subject: =?utf-8?Q?Re:=20[PATCH=20v2]=20xen:=20Expose=20time=5Foffset=20in=20struct=20arch=5Fshared=5Finfo?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1768922875712 Message-Id: <9df8cf47-d3ec-474e-b1c8-7978e55627d6@vates.tech> To: "Jan Beulich" Cc: "Anthony PERARD" , "Andrew Cooper" , "Michal Orzel" , "Julien Grall" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" , "Bertrand Marquis" , "Volodymyr Babchuk" , xen-devel@lists.xenproject.org References: <20260120095657.237-1-ngoc-tu.dinh@vates.tech> <3213454a-38cd-4e5d-8a30-853e37f70c18@suse.com> <7a61a16c-93d7-4cc2-bc47-11e236cf83fb@suse.com> In-Reply-To: <7a61a16c-93d7-4cc2-bc47-11e236cf83fb@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.1547d01774b0433ab9b06053565abfce?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260120:md Date: Tue, 20 Jan 2026 15:27:57 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 20/01/2026 13:42, Jan Beulich wrote: > On 20.01.2026 13:12, Tu Dinh wrote: >> On 20/01/2026 11:35, Jan Beulich wrote: >>> On 20.01.2026 10:57, Tu Dinh wrote: >>>> time_offset is currently always added to wc_sec. This means that without >>>> the actual value of time_offset, guests have no way of knowing what's >>>> the actual host clock. Once the guest clock drifts beyond 1 second, >>>> updates to the guest RTC would themselves change time_offset and make it >>>> impossible to resync guest time to host time. >>> >>> Despite my earlier comments this part of the description looks unchanged. >>> I still don't see why host time (or in fact about any host property) should >>> be exposed to guests. >> >> I've answered this question in a followup reply from November, which >> I'll reproduce here: > > I did read your reply, yet nothing of it appeared here as additional > justification. Is the new description OK for you? > Plus I fear I don't view any of this a basis to suggest > to expose some host property to guests. > The only host property being exposed would be the UTC wallclock as kept track by the host (as is specified by XENPF_settime). This information (wallclock from an external reference) is necessary for guest timesync, whereas an RTC which guests can update by themselves simply cannot be used for this purpose. Also, IMO Xen is the right place for adding proper timekeeping to the guest, as it's aware of both the "true" time as tracked by the host's hardware and the guest's TSC values (used for virtual clock calculations. Similar functionalities are provided by other hypervisors (KVM ptpclock, Hyper-V). >>>> Since there's no way to add more fields to struct shared_info, the >>>> addition has to be done through struct arch_shared_info instead. Add two >>>> fields in arch_shared_info representing time_offset's low and high >>>> 32-bit halves. >>> >>> Again, despite my earlier question, reasoning of why two halves rather than >>> a (signed) 64-bit value isn't supplied here. >> >> This was also in my last email: >> >> Both are just for easy consumption of the time offset on 32-bit guests. > > I don't buy this. I should probably have replied to this effect when > you first wrote it. {,u}int64_t is hardly a hurdle anymore there. Nor > would I expect any halfway up-to-date 32-bit guest to manage time as > a 32-bit quantity anymore. > >> Unsigned is particularly because these are only parts of an int64_t (and >> therefore have no signedness themselves) and I prefer to let the >> conversion happen after reading the two fields. > > There may be benefits to this, yes, but imo they want to be spelled out, > rather than left vague. > >> (Follow up: Also, the alignment of int64_t differs between GCC and MSVC >> compilers. Using int64_t here would change the alignment of struct >> arch_shared_info) > > Does it? For which target and in which way? This would, after all, render > other uses of {,u}int64_t in the public headers problematic as well. > For the x86 32-bit target, the Windows ABI uses 8-byte alignment for (u)int64_t as opposed to 4-byte for the System V ABI [1]. Most of the other uses of 64-bit integers look to be manually aligned and/or using (u)int64_aligned_t (I haven't looked at them all). I can switch time_offset to int64_aligned_t and avoid the issues above. [1] https://godbolt.org/z/x8o8K51Kv > Jan -- Ngoc Tu Dinh | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Jan 20 15:28:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 15:28:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209123.1521245 (Exim 4.92) (envelope-from ) id 1viDeb-0007fK-Rt; Tue, 20 Jan 2026 15:28:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209123.1521245; Tue, 20 Jan 2026 15: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 1viDeb-0007fD-Ov; Tue, 20 Jan 2026 15:28:25 +0000 Received: by outflank-mailman (input) for mailman id 1209123; Tue, 20 Jan 2026 15:28: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 1viDea-0007MF-Qu for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 15:28:24 +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 a6fbb0db-f614-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 16:28:22 +0100 (CET) Received: from DS7PR03CA0248.namprd03.prod.outlook.com (2603:10b6:5:3b3::13) by BY5PR12MB4324.namprd12.prod.outlook.com (2603:10b6:a03:209::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Tue, 20 Jan 2026 15:28:18 +0000 Received: from DS2PEPF0000343B.namprd02.prod.outlook.com (2603:10b6:5:3b3:cafe::b8) by DS7PR03CA0248.outlook.office365.com (2603:10b6:5:3b3::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.9 via Frontend Transport; Tue, 20 Jan 2026 15:28:13 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by DS2PEPF0000343B.mail.protection.outlook.com (10.167.18.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Tue, 20 Jan 2026 15:28:16 +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, 20 Jan 2026 09:28:14 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a6fbb0db-f614-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=g4r8vx7hdyFra6jZt8eu3Hx6RaDGT3fq3o3dt4sadqHXnkekjKe9fUboRRCCrKPeETGu1EXGVubrt8uBtteTIY1xmjSo8TiM6qo5TgwXag/cEvMTvJnCQn3xiDGZCAsIT24ULszKNSzyO7tZWEeuQ5/p2X0v25r8HE6YsqxDUPe5hCidSu2SudoF35VHeU0YI60SvLyI261Y6eQynF0AMQsWIsbpq9C953/MS9y8vZU29isyPQZ8AizFMW3N3SvTwpJt5xBSpHYAJb9SiKTIKtY33/Ih+VPMP/I6PJa/eXYf57pTWuc2AnTCxFoYao1XyOq3+ZWr+glbFu32u21WZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KOuSx538KMBfkUxjrEMNsTmB1lgKlsAkuQAWP2CoswM=; b=XRPinwiCzWs54AHR6YybdjtdyOSKxd4nZd8FSLkLU2NBPcx7ppMM2Y7bA8qCJBK/kHKVX+0nnvqAs5+opFaIR3w98izFuT8eZhlMVE8rTSGL7EvZaSomiC5WKsSu6uNhDRJcshIexz19BuR/a5bEoHuZxfA4mTW7QQq16u5ngiYX9ToaAR7kn8xFNNqVnGEU37sngqzRtBFfKuhh0xp4Qbxgw1claRQFN4G8+gq6oljEg+dWVGXEGtLs2iRR54I/Rx6UGVJgI4vvKsZ8+VbBfv2R04r8onWeB6g/MEqf5o0H5RZ4uZFWzl9S1lQym8jEPIjklxk2eAebgb7XVoFQPA== 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=KOuSx538KMBfkUxjrEMNsTmB1lgKlsAkuQAWP2CoswM=; b=LbYx/mT6zXkqfHWVuTD9vQT+Bid5ACFeHOXJxGmfUN8/mAfwy9GKZkZIFIoWDBx3RwCG/lCjEfa/Sq3F92B08qzPJw9k9jKe/3qhgagpY+MHZD5gKO6sY80tGxZeylZtyKIiNIUp8EokPeEppMEgYtwa1PWMBHzv/dooL0MfUig= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 20 Jan 2026 16:28:13 +0100 Message-ID: CC: =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , , "Stefano Stabellini" Subject: Re: [PATCH 2/2] x86/svm: Intercept Bus Locks for HVM guests From: Alejandro Vallejo To: Jan Beulich , Andrew Cooper X-Mailer: aerc 0.20.1 References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> <20260120095353.2778-3-alejandro.garciavallejo@amd.com> <5a4aa1d9-dafb-453c-bd4c-8da860519f01@citrix.com> <00f36b33-65d5-4681-84d5-e1b2cbd8830d@suse.com> <4ec779cb-3cbf-42cf-b744-80145d3cd54c@citrix.com> <48ccad85-8b6b-40ae-938e-b6ef9dae0ccf@suse.com> In-Reply-To: <48ccad85-8b6b-40ae-938e-b6ef9dae0ccf@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: DS2PEPF0000343B:EE_|BY5PR12MB4324:EE_ X-MS-Office365-Filtering-Correlation-Id: a0736131-fdd6-4b2f-cc92-08de58388848 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?eU1wcTdhNmxZNWZ3NTFTRlhreEIrRU1XOFFlSWdJYU1KWWcydCs5b29UazNO?= =?utf-8?B?K25JY1NVK1pjcEpYbHRtN3R2RHY3bWExbVBvNS9XU2J5STgzcmMzcWdadDdR?= =?utf-8?B?L1dMUWEyTkhYVGtjK2Z1MVJlb0F6MlJkYWlXZyt5NS9tT2N0c3NSdEtaTVpl?= =?utf-8?B?UnNQYzlYYXRkMVZ0dldKYUtkeWxwOEQvYW9tbWtHbEtWemdjUFp3c000NWlo?= =?utf-8?B?Q2t3K1ZWZ0szNzViOTVCVmhYOGVsUmthbVNBdzRQQXpYN00yOHlTT0xJMUMx?= =?utf-8?B?eElqYldTVW4vRWtJa2Npd2ZWR0pmOTMxb1VzaDhwTDNqeGl2dFFubVI2VlA0?= =?utf-8?B?eUcvbDY0b1R6NWl6NU55bHA2VExFOHluSG1JbWxYeFc2NWpNSmE2ZHJOQlZJ?= =?utf-8?B?Q2o2VUc4NDFPMktlSlNabW00RUFwcTEwcGE0ZVJMU3JzYlg2ai9UZEdTVlBn?= =?utf-8?B?OHVVY2tJdU0raVMxVzFoUnplMU0yWDRvVVFnTGVLL3VIZG1vNEN3bExwamc4?= =?utf-8?B?T1JsTndITHNQVnljUitLLzJHRlZXc21uVldWQkxiRXpMS0lpMGdSdi9MRGJM?= =?utf-8?B?ZmhjNmdCMGVnR0NMdE1ZWjg4MXRKYzlsQXhTTUFaRkZWUUU5bDBvRjlGTkxG?= =?utf-8?B?akxhbGZqd3FHWnFZcS9VdUJQbWw3ZWpGS1MreDFUMkNEZGtyT25Jdi91eGNq?= =?utf-8?B?NmMzdUNkbm5BaXVsbENSMlZoK2FMQUZzd2pvVVFEakxLZTltRXNxRlBBVnFP?= =?utf-8?B?RC9QcHA3Mk52MnFhdFFFL282aGVSalRRb01lR3o4NHdNMkE2bzZTbFN1MS8v?= =?utf-8?B?czU4ZVZDQ1VwbTRUZit1ZXVEbU9hemxRMWZpaW04NEMxVFZKOHI4Q2V5SWxv?= =?utf-8?B?cXRrYzU4c29pU1YzS0lNOWdpNDFWcEN4RDhaMEZxckxGV21HMWV5NnpxRys2?= =?utf-8?B?QlZCektDWXZGTVhxYUwwVVhmUGNyNW9oZ2dXMzdxYmpBODgrbGppWUZlaFAx?= =?utf-8?B?N3VBRzJoVStILzNjYXJYSEJ6RHV6azdJbFUvNVdPOTEwWVRhcVdlUFlxdlAz?= =?utf-8?B?Q1NCVHVXSmFjaCtzTEszMjJGUXdxOFhpZURUcm9JcGEvVE1tenNiSWg3RkFt?= =?utf-8?B?eG14WWdJM3d5Vld4NDZ5QjdZWUo3bWo4eVdPSC8rV2ExM0tDcGcyUWF0TjdB?= =?utf-8?B?NzJ6TC8vOWxXQ2dET2VEYmxMWDJzb2k5dXdyb1VKRUM0WlhXZmJoSVBseEFO?= =?utf-8?B?ZmYxWGE0RjV3Wm5hNnptMk1JaWJBaGpIS3VkSGxiWW5SVzBVK1p4UUsxdC9z?= =?utf-8?B?K1VIV0d2d1ZDalA2S292andXY3NZaVpVZUl5UkxCV0NtTTBzSXduRVp3STdO?= =?utf-8?B?RE1MblpHRWFDaFp5VHNkTEtZTXVHcHU3TzZtYzZYbFRzaUhlc3RIYlMvZFdw?= =?utf-8?B?Sk1yM0VNR1U1SzJQOFMvNDRYZ0kxVnd1U1ZrSm5DZGd0T25RWFVSSE1MWmxL?= =?utf-8?B?VjFDUFY4ZFdEbDdkOTZWRWlMTlkwSXUxZklYRG1GNVBscGxjMXdzaXk0MnN6?= =?utf-8?B?d3JjVEZhdjJBZ1lWSFNtMmlsVnljUXpRNjR0bkUrYW1UV1hjcy84Y2hvbjY3?= =?utf-8?B?aVJvb0ZpRUhHaWxkemhYWWxib1l3bitsV3FYc0ZYQVNnVGt1d3pzeGN6bHFx?= =?utf-8?B?blRrV05QR0VzWWpmb0tneVNJU2ZLZm5vOHRkTEQ2VmRJUTM5RXBJbHNFbjV6?= =?utf-8?B?ZGRtSUxrdVlKTGtvMWZqWUZsNjVjc1IrVmdGRmgwbFFzNzQ3RHd4LzFMSWJM?= =?utf-8?B?ZU1PRVN5NFVoZkNUK21IRkFLL3NmKzNNUnpacDh3YWdvc1ZaTkNycU1kK1Rv?= =?utf-8?B?VW9pOTFCNStxY3dJelJqS1c4S2dtU3ZxRElxdHVQQnhSWU94WDhzSUVRR0hi?= =?utf-8?B?MGowSjRQREFrYTZpY2V1cVlsTUFEVGU1cExZdy95cHZmWEJkb0lrVkQybFZD?= =?utf-8?B?bzEyRkk1cWpHR1VoRTd3VzJsSUk2djk3VktzZDZxK2hmaVhlUG1Yck9iSVFP?= =?utf-8?B?L3Z6SzVYOE9zRGZha2FqRWdtZDBPdkpYajAyK0tHWFo3TmdNTVpQT0V4R3pN?= =?utf-8?B?d3Nqb3o2M3F5MVVzUnhGRWNXekpwWmpOeE5HWjBncDE0YW5aQTd0QklHV1Zq?= =?utf-8?B?NmJPZE1STzlXM2JWbHVweW9oazk0SjVNWWI1LzQ2bUVOd1orUnhLc09yK21j?= =?utf-8?B?dVJvOUJDeGNhOGRpVDAzanhkSVlRPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 15:28:16.0651 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a0736131-fdd6-4b2f-cc92-08de58388848 X-MS-Exchange-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: DS2PEPF0000343B.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4324 On Tue Jan 20, 2026 at 3:32 PM CET, Jan Beulich wrote: > On 20.01.2026 15:26, Andrew Cooper wrote: >> On 20/01/2026 2:16 pm, Jan Beulich wrote: >>> On 20.01.2026 15:11, Andrew Cooper wrote: >>>> On 20/01/2026 1:34 pm, Jan Beulich wrote: >>>>> On 20.01.2026 14:29, Andrew Cooper wrote: >>>>>> On 20/01/2026 1:27 pm, Jan Beulich wrote: >>>>>>> On 20.01.2026 14:18, Andrew Cooper wrote: >>>>>>>> On 20/01/2026 9:53 am, Alejandro Vallejo wrote: >>>>>>>>> --- a/xen/arch/x86/hvm/svm/vmcb.c >>>>>>>>> +++ b/xen/arch/x86/hvm/svm/vmcb.c >>>>>>>>> @@ -66,6 +66,12 @@ static int construct_vmcb(struct vcpu *v) >>>>>>>>> GENERAL2_INTERCEPT_XSETBV | GENERAL2_INTERCEPT_ICEB= P | >>>>>>>>> GENERAL2_INTERCEPT_RDPRU; >>>>>>>>> =20 >>>>>>>>> + if ( cpu_has_bus_lock_thresh ) >>>>>>>>> + { >>>>>>>>> + vmcb->_general3_intercepts =3D GENERAL3_INTERCEPT_BUS_LO= CK_THRESH; >>>>>>>> |=3D >>>>>>>> >>>>>>>>> + vmcb->bus_lock_thresh =3D 1; /* trigger immediately */ >>>>>>>> Really?=C2=A0 The APM states: >>>>>>>> >>>>>>>> On processors that support Bus Lock Threshold (indicated by CPUID >>>>>>>> Fn8000_000A_EDX[29] BusLockThreshold=3D1), the VMCB provides a Bus= Lock >>>>>>>> Threshold enable bit and an unsigned 16-bit Bus Lock Threshold cou= nt. On >>>>>>>> VMRUN, this value is loaded into an internal count register. Befor= e the >>>>>>>> processor executes a bus lock in the guest, it checks the value of= this >>>>>>>> register. If the value is greater than 0, the processor executes t= he bus >>>>>>>> lock successfully and decrements the count. If the value is 0, the= bus >>>>>>>> lock is not executed and a #VMEXIT to the VMM is taken. >>>>>>>> >>>>>>>> So according to the APM, setting the count to 1 will permit one bu= s lock >>>>>>>> then exit (fault style) immediately before the next.=C2=A0 This al= so says >>>>>>>> that a count of 0 is a legal state. >>>>>>> But then you'd livelock the guest as soon as it uses a bus lock. Ar= e you >>>>>>> suggesting to set to 1 in response to a bus lock exit, and keep at = 0 at >>>>>>> all other times? >>>>>> I should have been clearer.=C2=A0 I'm complaining at the "trigger >>>>>> immediately" comment, because I don't think that's a correct stateme= nt >>>>>> of how hardware behaves. >>>>> In turn I should have looked at the patch itself before commenting. T= he >>>>> other setting to 1 is what makes sense, and what ought to prevent a >>>>> livelock. The one here indeed raises questions. >>>> Setting it to 1 here is fine.=C2=A0 This is the constructor for VMCBs,= and >>>> *something* needs to make the state consistent with the setting we cho= se >>>> at runtime. >>> But the setting at runtime is generally going to be 0 >>=20 >> First, we need clarity on what "Initialising as zero is invalid and >> causes an immediate exit." means. > > +1 The exit is not an VMEXIT_INVALID, if that's your fear. Let me clarify: The TL;DR is that the commit message is the unfortunate side effect of tryi= ng to remember why I did something a while ago and not remembering very well. Initialy I had zero at both the initialiser and the reset. That doesn't get very far until you notice the behaviour is a fault and not a trap, which th= e APM states as: ``` If the value is 0, the bus lock is not executed and a #VMEXIT to the VMM is taken ``` Then in order to go past that boundary the reset must be set at 1, or the g= uest loops. The initialisation may start at either (though zero would be more consistent). I guess over time I just internalised a bit too much "I can't exec vmrun wi= th a counter of 0". I'll send a v2 with the initialiser set to zero and an amended commit messa= ge. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Tue Jan 20 15:29:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 15:29:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209141.1521254 (Exim 4.92) (envelope-from ) id 1viDg0-0008PE-5R; Tue, 20 Jan 2026 15:29:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209141.1521254; Tue, 20 Jan 2026 15:29:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viDg0-0008P7-2c; Tue, 20 Jan 2026 15:29:52 +0000 Received: by outflank-mailman (input) for mailman id 1209141; Tue, 20 Jan 2026 15: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 1viDfy-0008Ow-Lm for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 15:29:50 +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 da595e14-f614-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 16:29:48 +0100 (CET) Received: from BLAPR03CA0014.namprd03.prod.outlook.com (2603:10b6:208:32b::19) by MN2PR12MB4109.namprd12.prod.outlook.com (2603:10b6:208:1d9::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Tue, 20 Jan 2026 15:29:43 +0000 Received: from BL6PEPF00022575.namprd02.prod.outlook.com (2603:10b6:208:32b:cafe::f1) by BLAPR03CA0014.outlook.office365.com (2603:10b6:208:32b::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.12 via Frontend Transport; Tue, 20 Jan 2026 15:29:43 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF00022575.mail.protection.outlook.com (10.167.249.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Tue, 20 Jan 2026 15:29:43 +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, 20 Jan 2026 09:29:41 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: da595e14-f614-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=YtUrFs6N6d2zwGTkYX47q1J2I080/Of0ichJIDvmrCFsqrveJQtCyfecInzJ871lmwp2OCY5V4UY2ZC018M/wJztNZZwY8d9qoEYoAYHl+jJj2aFiTZOGkkAuSHzX+kuteO0d1uwrGS39+ETXmUHsMaDPOa7BU8pnJByE2/OHBnXv8AMs32I6NuCM4VBPcCvbRhFRCUrJiAVRYumJxUqN7ZTBoqAlWTqPN/e1BWdZfHOCps47agLgtnUKGIxvhbpGHxPdG5vlq0NYUQs9eziJ+PIApju3luxkmtXQPNlSoGEQ2TRN+RygOuXwq+eskCL33uK0OxMIzDIzhc8WKpxFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=o9JCMNMBer5Wp1TRYXZxQi8tNDNDYcjg0B2NevyZzQk=; b=KBbDkRrTYEQbQPBfCZXu68fJBZv6WoPpjLV/ZH1SjO9sAXVDmEoZ7zgTttwwCc2K3SOBUM/iOYlVKTHMBh9BcamcHNz/jP00nT5UmvZzKG1qjehBSffs5j6ujNcpAJlAjwKoKh5k6VIBzsShiTqcwbWKQBQIzbdCCYzDnE6vyvOj4o61U9lhmquZJS91Z7JZy7p0Es4OVibAu8ggqkd0UjuIjcemCeNciCU9W5IYj9m+X+FnWk/grFmwkT0CYG9BjTbUcfuFi4IOO7Zs1U+rdTZMJG0kA47+ayecYXRmLn5oR1TVd3+jjiDcUDGFMVFI4eF4AkMaf9diGCs4op498Q== 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=o9JCMNMBer5Wp1TRYXZxQi8tNDNDYcjg0B2NevyZzQk=; b=ffAD5tUWxcSZ5FY8gXNzY225f8EaHgL5oN0/Cj3Oi82tuUtP+WU3dttSmfJ0EM2WjZb+HXmOMLucEy0TfXqddVImbGUg/RchoIHMwQY90wkRFI1Z/+CCAq+XztMONFJrsvUEnIkCUzbR2AmwjRI7DULtpCypPmrM2FFblR9n1Nc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 20 Jan 2026 16:29:40 +0100 Message-ID: CC: Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?= Subject: Re: [PATCH v4 1/5] x86/ucode: Add Kconfig option to remove microcode loading From: Alejandro Vallejo To: Andrew Cooper , X-Mailer: aerc 0.20.1 References: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> <20260120093852.2380-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: BL6PEPF00022575:EE_|MN2PR12MB4109:EE_ X-MS-Office365-Filtering-Correlation-Id: ead18343-f110-4adb-bad0-08de5838bc72 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?KzQ2U3JSWWJwR1RoRERWcmIwcWdTenRYOU1yejVSL0lhZTd4WXN4NjhxY1A5?= =?utf-8?B?NlRLVVFRZnhLMUluazdkZVhsSkZQMDRtL0lET2U0dDRYRlZ1VkZHZGVNUms5?= =?utf-8?B?K2lwUStoRHpFU0hFbXZ5aEU1bS9zSHVieEhzd0UvV0JHbVdlVGN6T3ZuNWpP?= =?utf-8?B?OXRHS0NCVXphTnFXNWE4bncvK2t5cENNMTlFdHJnc2xLeWRJYnJwWlBmbWxF?= =?utf-8?B?Yzg3bHpvOHI0cWNPWW5ucGFCa3Bqcyt4U3I0a2Q5VXhyVDh0YzJaTEhDZ1B5?= =?utf-8?B?b3BMZXNRWGhqZ285bDErZ1owUEdlM1N5aGFWa3ZiUC90VFhVZjJJazBNQkln?= =?utf-8?B?VC9SYmdWSG1NS29Ia2lHK08xN01rc1hGNndDQ1pTTkdDKzFzWUtId3VsRW5K?= =?utf-8?B?M0VBbXdOK3lBOG4wa0xvbklTY2lxeGRjaEUxVTdubW1XSUFqVFRna1diR1JK?= =?utf-8?B?UlBwd0Exb3FaWDRhMVQ1RUdYbXh5TWpIOVZyUTJDajgxL1RtRmdkQ0NmeVVB?= =?utf-8?B?ZnEyZTg4WW5KbWUvaVZLVktDMnRDTlN0NlRGS2RSRUVVMDk4MExBcjI2WGxW?= =?utf-8?B?dmtqZ3l5TENLTU0yUEIyaW9DMGZXQ1ZvQ1ZFeWtUNjFYenU3UDJCaDBYbGVF?= =?utf-8?B?SkpZTWVLM09sWksvcUhTbW8rdzJ4bnMvUGNmYWp0d3lWbGFwaFBycnNtNHI4?= =?utf-8?B?VFM3Ykh1YmpUOEdkcXZUU1dKNE4xcDFiS0JnL2hSa2VPNjlNdkpteFRxTE1V?= =?utf-8?B?UEo5a09BcWUxRmtWb0JBdWo4WC9wdW5VUXVmcWtQb2FNaEJzajJ3cHZiQnRL?= =?utf-8?B?THhTSDY4NWhWSEp1cWN0c1gvSHdNUktoWllhYWJvWUdiam1PMEtseXp1UnJt?= =?utf-8?B?emFzZ0pGdDhKQmZDb245NmtxV0RORkI3dWdmdG5BUHREdFFkQjdSTSs4VHly?= =?utf-8?B?cXRhUnl0TGtJMHVFQ3d4V1Yya2Y5cEhOMDR1TFk1blZ2Vkx5S0dEMlkvcmw2?= =?utf-8?B?V1lsbnp4bFJZencrVFF2YnJVZXFFZ1QwVmt2QU5JS01LdFJHNWR2ZWdmMHJr?= =?utf-8?B?NHMrR1djZUR0WlZSN1EwWDVNSEhEOW4xZ29BcHNab3JaWkluYXRkNEk0SFBl?= =?utf-8?B?ejJ1NjllVkFSNCthY0Z1TlZyRVI2QXJXUk5raWdIWFF2VG9CQm1saThlbk5S?= =?utf-8?B?b3pXOEtrdUpNVm1jQWY1bjlVYnI4NmJhMjVJTDFoSTE3KzVWS1plekN3dGpR?= =?utf-8?B?RVE1QStkVi9GWk13MGxiS0c2ay9xSVBWblBFelA2UEpQTld2SUFnN3pGQUV1?= =?utf-8?B?dXJKWjlUT2hxT090QUQ1WHhkeDdCSHhtU1NXd1JoNTBRMkJ1WWhPdEQvMmY2?= =?utf-8?B?dHpZQ0xjemYxbGVaRzVwNElTTnh1TkttakFNcUFudkxCendtRFpwdVVkV3h0?= =?utf-8?B?UlkyMEMrS1B6enM4ckRNbjY3NmtmbUlFUTR4czY0aC9MamFFYWNnSlEvakRB?= =?utf-8?B?RkNRZUMvcHRpMkVWTmNha3lvU3VISzRVVnN1dy9TQTR4NW9XTlkrcy93M2ZU?= =?utf-8?B?djVnTm0zc0NGVUlnK1FtZ1FDaGlPUXlYYjE1Sm8zdGIvRUt5U204aUpDWENU?= =?utf-8?B?V3MxUTVERFRHMC82NVdzVFRyS2h2dVIzYjhnK21kRTBGdnhZR2VwYW5KVCs4?= =?utf-8?B?SGRHeTF1T3Awc3hWNGtxMjdFSXdlY1BLRDlpMlpYSmV0SHpEN1JBeUJsVGRG?= =?utf-8?B?WXNucm1qRTZ4aHhpMUFhYXM2N3BCOFNpWmZGdlUvNW05Q2ltVEFRZmZxUjMz?= =?utf-8?B?UVY1Y2xCYmFGeGxZQUFOTUYwRjQ5d0NxdFNaeExTYnNkS0c1VzMwaEVIeE1w?= =?utf-8?B?STd5Qk9MRXdOR0JaSlRuenl0cDBZQ0h5c09Ec1BFQW5FZ05ER1BSeGJqNWFk?= =?utf-8?B?ZlkwUk1CQW9XTGhkVDR3N0ZtcGxVM0hzdERCY1lscUlDd21oNlZjaXNYbzFa?= =?utf-8?B?cTFIN2l5TnIwZ3J0TmNLclBPbzNEZitQUmlEOHdhSGpneE9GUlBVaHpKV3d2?= =?utf-8?B?ZFltMEdXSlp2MWUwQXpZTVdZVm9xZ0phRlIzQStRVmxCUTZNQUVvT2hwWE44?= =?utf-8?B?K2RleW56dkNQSjZQQnl2VXNyZmY3UmpEWVJTVy9iL0ptRGxOSGpBQlFLR0Qx?= =?utf-8?B?YzhxREZBalBGTzNkYWtwNGduVXRXYW1zK2V3TTdHb3grZTBCQ2VBL1FId0x4?= =?utf-8?B?eFU4Z2NzN3B4bWRoWkxENTZGOFN3PT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 15:29:43.5805 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ead18343-f110-4adb-bad0-08de5838bc72 X-MS-Exchange-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: BL6PEPF00022575.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4109 On Tue Jan 20, 2026 at 3:09 PM CET, Andrew Cooper wrote: > On 20/01/2026 9:38 am, Alejandro Vallejo wrote: >> diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_h= ypercall.c >> index f8eca48170..2ac9fc2d96 100644 >> --- a/xen/arch/x86/platform_hypercall.c >> +++ b/xen/arch/x86/platform_hypercall.c >> @@ -317,8 +317,11 @@ ret_t do_platform_op( >> { >> XEN_GUEST_HANDLE(const_void) data; >> =20 >> - guest_from_compat_handle(data, op->u.microcode.data); >> + ret =3D -EOPNOTSUPP; >> + if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) ) >> + break; >> =20 >> + guest_from_compat_handle(data, op->u.microcode.data); >> ret =3D ucode_update_hcall(data, op->u.microcode.length, 0); >> break; >> } >> @@ -327,8 +330,11 @@ ret_t do_platform_op( >> { >> XEN_GUEST_HANDLE(const_void) data; >> =20 >> - guest_from_compat_handle(data, op->u.microcode2.data); >> + ret =3D -EOPNOTSUPP; >> + if ( !IS_ENABLED(CONFIG_MICROCODE_LOADING) ) >> + break; >> =20 >> + guest_from_compat_handle(data, op->u.microcode2.data); >> ret =3D ucode_update_hcall(data, op->u.microcode2.length, >> op->u.microcode2.flags); >> break; > > Very minor.=C2=A0 This diff looks like this because you've dropped the bl= ank > line between guest_from_compat_handle() and ucode_update_hcall().=C2=A0 T= hat > can also be fixed up on commit. sure > > ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 20 15:33:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 15:33:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209155.1521265 (Exim 4.92) (envelope-from ) id 1viDjM-0001Xn-MV; Tue, 20 Jan 2026 15:33:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209155.1521265; Tue, 20 Jan 2026 15:33:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viDjM-0001Xg-JT; Tue, 20 Jan 2026 15:33:20 +0000 Received: by outflank-mailman (input) for mailman id 1209155; Tue, 20 Jan 2026 15:33: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 1viDjL-0001Xa-5i for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 15:33:19 +0000 Received: from CH4PR04CU002.outbound.protection.outlook.com (mail-northcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c105::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 578db704-f615-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 16:33:18 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SN7PR03MB7058.namprd03.prod.outlook.com (2603:10b6:806:353::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 15:33:10 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Tue, 20 Jan 2026 15:33: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: 578db704-f615-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=achTzX66ko6AXWtAetp9orG8EnuuGZmRZsWhN9naL6ZX9wH52aPnhLfAioF29V2qt5w4pS6YzVknA5nPBxVshNVAil6EwNcQa0DC7ewQswNP9d9UWCXQSCVpF2xZNIFE1LO78lU0aMpunAffDcSckwtpZS0OyDATIYZKgDcwz74rZluxeUlHs6ktubJnJqdoBo0qlwmsXeiltfR8/UTDWjsGvtiFkdeo0tF17kIvktK1JoJL2SCAuzOm1F0DEhkVusxseastOmPFZmktEsE5MwxSqEGL3XGaTwVxIO7ojyCZdXx4/nkdHXOWlH6ovJpfFZ9ZQyrtGDq4dA0GvzSK0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Dy496zTH/Lr4IN5cUi/7GmFfoC/qmaNauHa9lWQdFw0=; b=phWZQY3SPcqi/iuz7yWSFiLwEcMqYBmACsQGsg3/se6w2VtV4liS0gvc2p+FBzCYMsbJldIVOY3NKfYRxWVgBKaASeNI6DTK5tsSAtuwZONAO8FVDcxEop9JfArgbPnRnAO/U2ygFMQd8+qyHFc3JYOEaWikJgC469ei5gjtWmmw/aMykaiDAH2KEVWrPF/2vs7gY/almFR+VG40s+SNEP3HcxB33WQYqdOfk/jZ2qAvAh7GOpkwwK7EWJ0i/BPtD+8oJTL61HiLQj65z1RvivnJnQtIAr2G7JV17KV1tgHyRQuhLd07kyxEJzvHw521AdxmYZj0JKWPrFQha9qWgA== 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=Dy496zTH/Lr4IN5cUi/7GmFfoC/qmaNauHa9lWQdFw0=; b=eKPhrHT7zImeIkg60+RP7GPOhEDCDWshKT3BY+r3WvZ3WkIsW6HIdFr7EqU9X+X0dBFvzv4D3E309Ediea5DtnDTWrSS37HbqOASLHBOtg4HLCLNVSE9G90xswx+3nRlLEuR2SjigO9JdVAb64GCnwuTfGWwOsE9xyUEMizKb3Y= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Tue, 20 Jan 2026 16:33:07 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: xen-devel@lists.xenproject.org Cc: linux-kernel@vger.kernel.org, James Dingwall , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Subject: Re: [PATCH] Partial revert "x86/xen: fix balloon target initialization for PVH dom0" Message-ID: References: <20260120140648.25977-1-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260120140648.25977-1-roger.pau@citrix.com> X-ClientProxiedBy: MR1P264CA0218.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:56::11) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SN7PR03MB7058:EE_ X-MS-Office365-Filtering-Correlation-Id: d0295c90-99ac-4517-294d-08de583937d2 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?Sy9ZUHJNS1FreVRUbFJ5Q3JiQmtHUHRNekFJTUFxQWVBR21Ga2ZXVFNVRXBi?= =?utf-8?B?SSs0aEdFcHhQeXQwUU9talhReHZ0dmZsbWNlSnVFNGRXUHAzQmpDaUVUMGpE?= =?utf-8?B?MW9JbFVDZG9EYkthK0hQMzU4ZVB0ZUIrR1pGcFR2ejVjR1BMUTQ4U09qNE0z?= =?utf-8?B?bW9PWjVpRHhLY2N1Qm5nVjFUL0tKaUtsckxHZS9oYnRHQTZZbkNtbUJzb1pT?= =?utf-8?B?SGFQVlo1UkFoa0xGVWh3U1E1K216UnZyYXREazVpYmIvb1VDdEJFNkFVMkdG?= =?utf-8?B?S1dEYTl6bGlsRldpeDdPN2VBOC9iN0JMbkZoKy9qRHdBbnpPMmhCT3I2QWVm?= =?utf-8?B?Q3E1UTJsOC90aXFtS29HaGYwbVFFRVErS0JSTU4yT2FkOTRJK2IwellwVXRK?= =?utf-8?B?RXY3cWM4Y1AxdnVqbHdjZDdNdEZ0R3hzeTNlazdkM0ZvSkhFamVqaXNpdlBo?= =?utf-8?B?WC9CY2NTSTlCdWY2VE13NTdONGF4U3gxR1RaWHR2VVRFMVpHRFBweHdRMDdz?= =?utf-8?B?dFlxUENmNVFjM2hyR1NvNmp2a201cjJtMTJrdU16VXRIM0RsZEtFVXBUWUlL?= =?utf-8?B?RXFmWFFIMDFxVmRwb1pIaUxIa09lUmdIUTlxUExLOWdIdVNHdFA4VmNPQnlw?= =?utf-8?B?enRPdVhja2ZzMUdUM1JvYkV5LzFsb0hoT3JlQ0lVYXdOR2FCdGd5eUdhSm1F?= =?utf-8?B?NjJPdmUvaTRNUlh5VldNSXJ4STI1Nk1HOFRyTXNhcnJXQVRybW5BejVBN0VC?= =?utf-8?B?YWEwNkw5Szk0STlTQ1JzcGl5QkNCRFo4YTk3cVM3dk5DUmZDbTZDK1VPQWpP?= =?utf-8?B?RlVlTUVvbitoSkRzUE80NGFyQzZheHhpRWhnRjh3U3ZDb2kwWndOUVBISlFR?= =?utf-8?B?aDM4aXMrMExoMDZPNTYvZ1gyNjdqdFYreU94RDBWZk9YU0ZWd0dXb2ZySGZw?= =?utf-8?B?RUFyU0VXdFVTL1ZYK3lsYXRSb1dSeWZnSFZRdEtjUkpZM0FteENaV054Skg2?= =?utf-8?B?L3RVNUVEbzJQMWtSQ1M0QTdNUFlkMjJaZVVOdUJmd0MwbG1qZmxxSEtkOGoz?= =?utf-8?B?MkRUeUx4YTh2UmRtZGgrQm9MT0N0bVhNMjVOMEtvVVJsUzFpU1hBRDcwL0pI?= =?utf-8?B?Z21jU1hJZndVVnI4SXd5L0xiS1V5cVdzb01Uc2pMKzhPYnFkSDFhNVYrL3hn?= =?utf-8?B?VWFPY0pCbzlVRFR5K3R4ODg1aURmcVF6YkhUNGRoZm9LR3hzanRRVHFHMjI5?= =?utf-8?B?N294NXFlRDcxZkpTcDFzZnltV3hBUE5SZmZnNGZEamJGTndWamFmRXRpL3ZQ?= =?utf-8?B?VVNpS1F1b0hNTnIvTm5adng1cW9sV1U3MlNWUXI0VDkzNW5QbmRyYXlBOWh6?= =?utf-8?B?UFFlWXpwNENrUDNhU0JuL2JsNWhsVDNCOHNDTElwZlF5bmVxM0FGVHRmMFRw?= =?utf-8?B?STh0RkxpeEhSekdkNG5yaVJlQ0xEdjFGZHdVSlRUU1NlbHY4UlZsSmhPUTVL?= =?utf-8?B?QXdiTjZsSEhIMzNOc2lJZ3hST3pHUVpoRjdJVFJ0cW5JdlN3a3JDaXdTOXNC?= =?utf-8?B?c0srejBFNXo1NktoaHdGL0NZQktTVlZqNFE2aG8ycGxlR0FHZnBFeklXUHRC?= =?utf-8?B?WGtaeXZUc0hjWk5JSGszZk9nTFExODlDYnhOSXM2dEZDY3Ixdk1SWjJ0RWVw?= =?utf-8?B?eGFGaU9FTHhxNHZ6VHMvK2l2Q3Bhakt4QW5OYzUzVXUrSTFLZFJkQVZnS2Er?= =?utf-8?B?ZXNUamt0aUlhY2VNR1NoYW5kcHRZYlVmT3pkRjdxbnZxOStSZ01DbUdrTWt5?= =?utf-8?B?dS90VU95V0FXc3pDZFpoR3JuV0dtOFkrK3dPUlRYL2NEV09jUXp3NTdIbVVL?= =?utf-8?B?RTVqZjFLTDdBVGNmeFdXWitpNjN5aVdUMGR5MGRFOWFPRXZZcW40dVA3TzNV?= =?utf-8?B?cjlrL1FLbDlrUGxsY2Y1UC9IYUpwcVQ4M3gySU1GVmNnNnY4bU96VHlMRnZq?= =?utf-8?B?Z0wrMmc5b1hMakVrTWgrYkFYNzJHMjFwekVvQjV3ckNkMUl3NnJlb3c3a1pX?= =?utf-8?B?dUVMd3I0TTdsUEdoaDBDWS9SL0Q5TnRIaTN6VFRYRHlqSmIwYmhwcEI4Zk9L?= =?utf-8?Q?P4g4=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NTY2OU0xcnUzOWh3WWkwMkRiSGF5TGFqYjZRWW4xbUFqTHhNYVJCeEdaZWZR?= =?utf-8?B?VmsrcCtvdk5nUkR1Y0lTamFJWUlIaUpOOGtKeUtmVU1XejJobnVnaTZ4b3l5?= =?utf-8?B?dkJqODFzV2Y0QnNwdGpycE5sOWwzK1laQTArMmlzcDFqT09JUjdFRkZUcEFi?= =?utf-8?B?MWIvT3R5S0pzTFVxd3NFOEl1aUNGUGpsdE9JTFByWVNjWXZLeVZkeUp4RGxW?= =?utf-8?B?eWgxN29heDdUMTZicURaVTlMdWNkbFdlL054SzB2eEx1Wld3QURMWXJLbHZV?= =?utf-8?B?bHpyRHJQYVRtc3RlU2NjRGhYS2htWVMzWTNUa2tyQzlLZFlrSUhYcktINHFT?= =?utf-8?B?ZzJLK2hXRDFqYjhlR0txVVNHM05RQ1RoQ1hKMUZKZHVEUTVwdEJiM3p3MEFy?= =?utf-8?B?UHRJb2dhS0tKV1J0THBDY3ZWdmJ2UHlzNnZlakt5WU5BWjRaVnBXaGFWdE4x?= =?utf-8?B?elZ1Z2R6d1BGaW5vUmorQXVyQ1ZNaWtMT1o5aU1tazFKNiswK2F4Um04c3Nu?= =?utf-8?B?aGlTS2pZQWxGU1lpMk9UMDdlN2xQRURYZXBEY0paelhJU2xIRU4zalRoL010?= =?utf-8?B?bHdwajMxbVhwOU10d2hWTkpDdFVVenR6Tksvckw1cnBXNnBVYUpZQU9IenVE?= =?utf-8?B?NjJ3dThmc3RWYk55bU9HR3RmUXlvZWxrSlNFcXJEb2tZTlB1SnFXOGRYTXJU?= =?utf-8?B?WTlsNURDY1hldTF4UWFGcmo3ZDJ1d0JoTVJhQjBUaURRUEhNUkNObmhDQXc0?= =?utf-8?B?a2UrQ25KK1ErOThtV3F1cTlESTlySUNDa01TaER2c2lFdWVuVkNmNWwrYmNZ?= =?utf-8?B?dTBMMld3eUJleTFXWWJBRTlXY016SE51bFczcTExSVA0cllGd3NlemNmYUYx?= =?utf-8?B?MW1HTTl5TC9ESzhQQTFNYlNNeG05Mkt2OWtSN2NvcGdyL2JoRVhwVmJLZXpl?= =?utf-8?B?NS9MK3RYR1ZYOUg4RmpqZHJqbGN1K0xtUnMrUG1HMFpwSk5UcjVOd2hBd3Ns?= =?utf-8?B?bXVONmY2dm5iQTdmbk93Vk9XZVJneWxIbEI4RnZ6Yzg4aTJub0JlTWtYVzJU?= =?utf-8?B?dW5iMlVvR2JqblREVkt5SmJKK1ptVGRJZzZRYSt3OWlDd0E2TWNzci9jSVFN?= =?utf-8?B?a2hlYUJrMENQTUVFN2xzOU05WndBTDlRU0tpc043aHFkL3JLZlZuOW82VE5K?= =?utf-8?B?VDJBT2E1L0RaeDhkbmgvTVZXVXpDS2kzYW1Sc2Q3Y2gxeHJMVVBxcjZEUTRP?= =?utf-8?B?U2pqQjM1dVJYdTBXVko2UEVzTnVYY2Z4VjJaNUJIdnN2L0Exb2RIOFpzNnBm?= =?utf-8?B?ZGtaNWxJN1UvYXRkRVQwVStQWUV3VFdMMHJ3Z20xYzRzM3dabGU3Y21XZHBH?= =?utf-8?B?aTFXbS9WYkQ0QjJ2cEY5dFNoMFBMUmhaZS9Ldmwxa1kyYkgvcmtNYmRBc2xa?= =?utf-8?B?WVk0ZndzMjBvcE8rUnk1Zzgxc3BLc2Z3elJDM2hrSjl0WUlxMVNscjczcDV2?= =?utf-8?B?STJHdm16UnA0dmpJc3ZzRFNsbjE4WjJldmJtWXBNREtyWGI0cTd2ZFFXQU1M?= =?utf-8?B?SDRBQVJISU53cW1wczR5WnNjWXU1Um1VdGxra3VzWmpUZTlsVzI3dmFhMTVx?= =?utf-8?B?WnBQZGNEUVR5TnM0ajA4Z1FWUUdwQzRGLzZoS2huQVRzMmVPUVgySHBvU1B3?= =?utf-8?B?VWhsSFlWSjVpT0VEWEF2N243dGJlMEQ0K2d6SWsveEZPT1psbWRuZkhxbVNz?= =?utf-8?B?SVNMTXBWRlZYR25zU3ZwVjNYbDFkZHErMGxVc0IyMloyMlV5V3o3b2RPay93?= =?utf-8?B?LzVXL1ZqZWNTWkxoZERKRGVQZzZ6T3dVT2JGVHcreGJTR2FxbjJlaS9WRFNQ?= =?utf-8?B?QWxwLzJCb0dXU2RMczNjZG9QWFZFaFB5OVBFbHpOUyttWWZxcXBTVk00QVdu?= =?utf-8?B?dS9SbThXV2ZkOGdSUHg1UDZUdjMvdXM1TGlpajNMbjBZZmhuYWhBL3RzcmlX?= =?utf-8?B?L1VYMVk3c2ZZNHBHRVZsNVR5V3RkbUZld25ORFowMlFZZXZpazBKUUdOc3Ji?= =?utf-8?B?TGZjaENWNEk4Zi9zK1hPcXJJU1BXQ3VPVitwTFl3aldZRTFkWGlsTmt6RWtH?= =?utf-8?B?ZlREOFJXMWU2Y3VQcDBnNXMyTEtkcllVaTk4V3Z5OGRqWVJXM2czQlNPVG9w?= =?utf-8?B?bE4vaG1pQmhzbTYxekM5UDZNRlZmQ01uRk10LzF2NkZqSU9KNERneFZ2RFMv?= =?utf-8?B?WmxkbHAzUEdBalc4eWlGM3dzNHBBUVNwVTFuRnJMbUlnMDRQMFNBL2ZjZGo5?= =?utf-8?B?Z21hMzd2ZFI4WmtMS240amtVTC9TVXdlYTVodEJMMUtBbXBsNmdVQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: d0295c90-99ac-4517-294d-08de583937d2 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 15:33:10.7041 (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: j4tm7rNxoZm0hzxcxjgNoQfWSIDAc+F236W/rnXoxNcFh8ziDRSpIBUQYsbSLTo67G+uCYkwebwahNGKe0+mGw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR03MB7058 On Tue, Jan 20, 2026 at 03:06:47PM +0100, Roger Pau Monne wrote: > This partially reverts commit 87af633689ce16ddb166c80f32b120e50b1295de so > the current memory target for PV guests is still fetched from > start_info->nr_pages, which matches exactly what the toolstack sets the > initial memory target to. > > Using get_num_physpages() is possible on PV also, but needs adjusting to > take into account the ISA hole and the PFN at 0 not considered usable > memory depite being populated, and hence would need extra adjustments. > Instead of carrying those extra adjustments switch back to the previous > code. That leaves Linux with a difference in how current memory target is > obtained for HVM vs PV, but that's better than adding extra logic just for > PV. > > Also, for HVM the target is not (and has never been) accurately calculated, > as in that case part of what starts as guest memory is reused by hvmloader > and possibly other firmware to store ACPI tables and similar firmware > information, thus the memory is no longer being reported as RAM in the > memory map. > While kind of obvious, I guess this needs a: Fixes: 87af633689ce ("x86/xen: fix balloon target initialization for PVH dom0") So it doesn't fall through the cracks for backports. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jan 20 15:39:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 15:39:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209165.1521275 (Exim 4.92) (envelope-from ) id 1viDpV-0002O9-9q; Tue, 20 Jan 2026 15:39:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209165.1521275; Tue, 20 Jan 2026 15:39:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viDpV-0002O2-6L; Tue, 20 Jan 2026 15:39:41 +0000 Received: by outflank-mailman (input) for mailman id 1209165; Tue, 20 Jan 2026 15:39: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 1viDpT-0002Nt-7V for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 15:39:39 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3a7ae049-f616-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 16:39:38 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-4801c731d0aso33059795e9.1 for ; Tue, 20 Jan 2026 07:39:37 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4801fe44b37sm104253375e9.12.2026.01.20.07.39.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jan 2026 07:39:36 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3a7ae049-f616-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768923577; x=1769528377; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=YgF1C7fHVhgUxnxy9+cYOJzNcc1oO4I1//7mzKOZDqE=; b=I7OesFj2C9JREeLcDDB3OWkCZgEhu/+cvEUEvb675PR7pbUHreLrNg1Dsiu5jyVoJ6 QkeG2k6FkNTMUu+dxPDTuwrQEPpFRaNegU/vkr9ik+cXa5vXjpRFYmyDcnKLa8PgHspQ 7GocnWcu0kz9rRWItKVTbs1LRbQf7Y4+1FaaVsWWX5GnSlRxXxhxLkuoqs8a5kVth8Np IYEzyNigmSQw+zjbMY441BdnHtHXbENvHwAhbsv2LoYNB2WolrA0jRxLI+E/k9tQs+TG cRFSnQFM+xJ+3/6yQWiutgwsmVf1WBpwqHerrcgHiOJ2flRNmDX6ktY+VBIDlAOrXiYa irQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768923577; x=1769528377; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=YgF1C7fHVhgUxnxy9+cYOJzNcc1oO4I1//7mzKOZDqE=; b=GP7470CI5Iv8zgvDo+UKtQXNxJrelyu4LF7xWnx4mdA3dCrp5GyaOxboUZoQ4Bqhov r8YMVMQqXILS4Eosd2peq6YG8XePysptni0B1iaVOV0/owHQbndI9XPrGD2c5J56mUyP JMwfxpTlkwP/ZdDaGMdGFgIBjEJ1H/MtKcgQcQt+7ja8etm1FiA8QcHuX8T30aadok0n 9qZ46pr28mU1QttI79BENwhrupFNiSMEowJ9X+eq4tUzFL230kZrJJlq/PLO6QzD4NHx l4SPFQL27QONgyZ2RJiuv6TG2i6fL7Zzu8jthEuABzqF3GRzt6zm6GP0GZxOgT+dqBip oOVg== X-Forwarded-Encrypted: i=1; AJvYcCV4E19nFi/mxsK2e+s7clWlOi6IpWpPgqCCPbP2yJ9CRclJuJ9atUbZ/nrCFbXSXiAkNaOCFFedrMc=@lists.xenproject.org X-Gm-Message-State: AOJu0YxdFE4PpVxgwKOWnv6HqO/yaW5+LqLh39tFAGHeCU5PJwHeaEeu q2vE2qR4I3PL0IqVlfU98TZ8SY78tuRBwEtxgsZNM5cTlU7hBvDgmF/YH3vLPZS5Cg== X-Gm-Gg: AY/fxX7aU7RO4G7E0kF3AdZ6ezuR5Uzo8QMn4ZlhQ3cGbqe4tmU56BniFwjxpIf6ZTz eJGvb3nhL99zuQiO1fiI9V4q7ERvDj32/INC9QSJascY3vyiWGgk/fKPEDMlBfa6j6n5IY7qRh3 OF2rZGAMeX8Ggw2rnLqGfLHNwpC/+8Wo6qRMsp6yxqRKpbmcPlsi4kpD1a+1+WguEPqQk6pB8yD qO1fHEMHcCXkOKdPVzys08iqIpDJZ9ORIzGPgBr/K9ydNv8rOvo1bu1BCIaN5Pcxpxrfi8STW7l CBeJ0Xo0fSpoLHnV02COr8Efnk7XgOhKGm1YFlVE8owS3byFrXwnnaJHQK5wmINGyQECoWAfeIi rTulWDloVrpPRNGFL+EMpgNc+0/axaolHUi9JLa2fWAQXyRg2g7iJCoRqB5JBwFTtY6oSkV9V/M gCDMnhKF2PAhu3RNdV2JNdkUmwgOzRp5wluf4LFEDNH/s8g4iOMDkab/ZNdeRPO7qt9AbpIsY9a uY= X-Received: by 2002:a05:600c:64c3:b0:47d:92bb:2723 with SMTP id 5b1f17b1804b1-4801e30a168mr167775515e9.3.1768923577246; Tue, 20 Jan 2026 07:39:37 -0800 (PST) Message-ID: Date: Tue, 20 Jan 2026 16:39:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen: Expose time_offset in struct arch_shared_info To: Tu Dinh Cc: Anthony PERARD , Andrew Cooper , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk , xen-devel@lists.xenproject.org References: <20260120095657.237-1-ngoc-tu.dinh@vates.tech> <3213454a-38cd-4e5d-8a30-853e37f70c18@suse.com> <7a61a16c-93d7-4cc2-bc47-11e236cf83fb@suse.com> <9df8cf47-d3ec-474e-b1c8-7978e55627d6@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: <9df8cf47-d3ec-474e-b1c8-7978e55627d6@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 20.01.2026 16:27, Tu Dinh wrote: > On 20/01/2026 13:42, Jan Beulich wrote: >> On 20.01.2026 13:12, Tu Dinh wrote: >>> On 20/01/2026 11:35, Jan Beulich wrote: >>>> On 20.01.2026 10:57, Tu Dinh wrote: >>>>> time_offset is currently always added to wc_sec. This means that without >>>>> the actual value of time_offset, guests have no way of knowing what's >>>>> the actual host clock. Once the guest clock drifts beyond 1 second, >>>>> updates to the guest RTC would themselves change time_offset and make it >>>>> impossible to resync guest time to host time. >>>> >>>> Despite my earlier comments this part of the description looks unchanged. >>>> I still don't see why host time (or in fact about any host property) should >>>> be exposed to guests. >>> >>> I've answered this question in a followup reply from November, which >>> I'll reproduce here: >> >> I did read your reply, yet nothing of it appeared here as additional >> justification. > > Is the new description OK for you? Which new description? So far I only saw your responses to my questions, not an updated patch description. >> Plus I fear I don't view any of this a basis to suggest >> to expose some host property to guests. > > The only host property being exposed would be the UTC wallclock as kept > track by the host (as is specified by XENPF_settime). This information > (wallclock from an external reference) is necessary for guest timesync, > whereas an RTC which guests can update by themselves simply cannot be > used for this purpose. What the guest can do to its (virtual) RTC is no different from what an OS running bare metal can do to the real RTC. Running on bare metal, you also don't have any other reference (without using e.g. NTP). >>>>> Since there's no way to add more fields to struct shared_info, the >>>>> addition has to be done through struct arch_shared_info instead. Add two >>>>> fields in arch_shared_info representing time_offset's low and high >>>>> 32-bit halves. >>>> >>>> Again, despite my earlier question, reasoning of why two halves rather than >>>> a (signed) 64-bit value isn't supplied here. >>> >>> This was also in my last email: >>> >>> Both are just for easy consumption of the time offset on 32-bit guests. >> >> I don't buy this. I should probably have replied to this effect when >> you first wrote it. {,u}int64_t is hardly a hurdle anymore there. Nor >> would I expect any halfway up-to-date 32-bit guest to manage time as >> a 32-bit quantity anymore. >> >>> Unsigned is particularly because these are only parts of an int64_t (and >>> therefore have no signedness themselves) and I prefer to let the >>> conversion happen after reading the two fields. >> >> There may be benefits to this, yes, but imo they want to be spelled out, >> rather than left vague. >> >>> (Follow up: Also, the alignment of int64_t differs between GCC and MSVC >>> compilers. Using int64_t here would change the alignment of struct >>> arch_shared_info) >> >> Does it? For which target and in which way? This would, after all, render >> other uses of {,u}int64_t in the public headers problematic as well. > > For the x86 32-bit target, the Windows ABI uses 8-byte alignment for > (u)int64_t as opposed to 4-byte for the System V ABI [1]. Oh, right, I should have recalled this. Iirc there was an unwritten assumption that for Windows the public headers may need some massaging. > Most of the > other uses of 64-bit integers look to be manually aligned and/or using > (u)int64_aligned_t (I haven't looked at them all). I can switch > time_offset to int64_aligned_t and avoid the issues above. Except that int64_aligned_t can be used in __XEN_TOOLS__ guarded areas only, for not being possible to make available with plain C89 / C99. So here we're working out a reason why the field may indeed better be split. Albeit as said, other areas of the public headers use {,u}int64_t as well, so maybe this still would only be a pretty weak reason (and you could make sure the field is properly padded for the x86-32 case). Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 20 15:41:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 15:41:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209178.1521285 (Exim 4.92) (envelope-from ) id 1viDrV-0003qz-KN; Tue, 20 Jan 2026 15:41:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209178.1521285; Tue, 20 Jan 2026 15:41:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viDrV-0003qs-HQ; Tue, 20 Jan 2026 15:41:45 +0000 Received: by outflank-mailman (input) for mailman id 1209178; Tue, 20 Jan 2026 15:41:44 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viDrU-0003qf-P4 for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 15:41:44 +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 8285e378-f616-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 16:41:40 +0100 (CET) Received: from SN7PR04CA0179.namprd04.prod.outlook.com (2603:10b6:806:125::34) by BY5PR12MB4065.namprd12.prod.outlook.com (2603:10b6:a03:202::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Tue, 20 Jan 2026 15:41:35 +0000 Received: from SA2PEPF00003F63.namprd04.prod.outlook.com (2603:10b6:806:125:cafe::4e) by SN7PR04CA0179.outlook.office365.com (2603:10b6:806:125::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.11 via Frontend Transport; Tue, 20 Jan 2026 15:41:34 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SA2PEPF00003F63.mail.protection.outlook.com (10.167.248.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Tue, 20 Jan 2026 15:41: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; Tue, 20 Jan 2026 09:41:32 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8285e378-f616-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Pixu8xJkCFNmzG+2p5EtmVacX7LQDczeA3QBZjUx2zW7opSFd3vJN6Aah0pSSotyyY4EqWqigDyGJW2mICPedYTfPOiLetZexXKkO7AZSGjn8zi/Dn5NAea8zyNERMoqc0S+2TpxsBO/lP1hy1Q4StRpyAzc/DCjrEtjVZuUXjZhSQ2QAnQ8tL8NfGV+4q2ar6z6A5Ucmktoy+VsKSwPNEMtZIum4m9X/ALVrBQd2eo9pELuS6hOUaN790vWyZjqrcobs1BIxkfj4UDVnxdaTxRKShh2wBnSwhH567LdwM7Y4Dd0JSnQDe3oDjHgfHYMIcJibPp+9oI/AuiAvcGYKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZBG90rR2/J7jngo9T9ZlDK3DYeox/fWTuf/UqvJHEF8=; b=BIpBx2ujeW3DfIJb1vlhE0gyWs7jpQVHDbhlYt9ioJHak0jH01sHqnJL4DnU2QzGGZ4nw2oZlDe93SCNoZDP8bgXchBBw4StzxY5lRYjQGm44jnwqIVwuTVzvub5imliXqvnpsfgNx+G0jT4/dNkOilsjRfPI16OcEFGR8piznBo5EhlmJZkcKh8t/O1YvF78FlL53MRDICyh6vrHbK4kuAKRH9GyhvA/1SUp4AVdlN4YEogWhWyWHmwyPthsrq54h7mkGS4z4FL/+6sqwyVJfqjsAG/W692yYH26a/M88otmIkofYCCFhmES05d0ehRkFgBxLDUJ62dlLi9HCw/lg== 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=ZBG90rR2/J7jngo9T9ZlDK3DYeox/fWTuf/UqvJHEF8=; b=GIqAr4fbzouty+q7OmJoZiLF4lpWcICpP/zHidWf2VmFLyoU+iOPo7zjbxNC3PlEC0YvmTsP3A748izh+XEMIOQEdK+rbWSf8s1FcD19znhRTKF8d7MYlggq0dvo8QUnV+KDHqLxKSS7XxjKn8isJ8S3tXtSO0Vij+H90ZYkyds= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 20 Jan 2026 16:41:31 +0100 Message-ID: CC: =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , , "Stefano Stabellini" , Xen-devel Subject: Re: [PATCH 2/2] x86/svm: Intercept Bus Locks for HVM guests From: Alejandro Vallejo To: Alejandro Vallejo , Jan Beulich , Andrew Cooper X-Mailer: aerc 0.20.1 References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> <20260120095353.2778-3-alejandro.garciavallejo@amd.com> <5a4aa1d9-dafb-453c-bd4c-8da860519f01@citrix.com> <00f36b33-65d5-4681-84d5-e1b2cbd8830d@suse.com> <4ec779cb-3cbf-42cf-b744-80145d3cd54c@citrix.com> <48ccad85-8b6b-40ae-938e-b6ef9dae0ccf@suse.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: SA2PEPF00003F63:EE_|BY5PR12MB4065:EE_ X-MS-Office365-Filtering-Correlation-Id: 048e6fb7-3dc5-4503-0cfc-08de583a6424 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?ODZySFQyTWNScnMzcDRUZzV4T0Z1cklJVkszbThUc244UGZhc1JjT29jOTQ1?= =?utf-8?B?R0pKbzlOM2NjbURoV2w1M2Yya01vSFJTTTZUc090N2lIUWh3M0l2VC9LN1Zl?= =?utf-8?B?N3U0ZEhzdFlhWnhuM0JqRFV1T2lsL2JIM0twQUVncWw0SHREcnRNUWRacHl3?= =?utf-8?B?R2VYREJDRkJwNVNwbjMrZHBFSlFrQW9ITDNFeFZmTy9qVjRHcEpyS1JjYUFE?= =?utf-8?B?NWVSdE9uR1YwVVdSaGVxeFhXV2pLb0djU0lWOUtCb05VeWdzKzhCY3ZYeG5p?= =?utf-8?B?aXc4NHNLV3lFUFRxZjdhN29NeVlTanBBUmxCejRsdTR6RThlTldxRG45aGRJ?= =?utf-8?B?RWJ5eEdhY2FKbTI1T0s2emdLRmYwc1VsVXVNaGlraFlteGZ0VzA5SVJ1S1lL?= =?utf-8?B?eTFab3EzdndWNmZiUmU2STgyYXFmN1JnbUZMMlVoenpuOXlWK3RoNnJOZXlZ?= =?utf-8?B?czZYM1Y1c1JkSitxZDI1ZWR6Rnl3L1FiTFA5SU9qRXdUYlhVaUx3ai9zUlVm?= =?utf-8?B?T2kydG91TWwxSkFoakNMK2RWUWJIQUZTSHRXek5LT21xblBKcXVrRHI5THpZ?= =?utf-8?B?b09JOFZWV3NpSUNYc0dtcHFHYlhZeW1yNExCR1c4ZUNERzh4OG53b1BueFZo?= =?utf-8?B?emlJSWZGODF5S2VGTlhYUTF5NEdXNGdtaUQ3Z29KSTFJelBWR29UQ2ZDRThG?= =?utf-8?B?eXhZZFg3M0Z2RDdaZGQzK2RwclBaWWZBeXpFN1VuS0FYcjRkMSs1azQrQjFy?= =?utf-8?B?UXlVVUlKU0Q2SmdoZnJuL2QydkdFRFNNRmJmWmR5NzB4YzRjSndKWk41UlpU?= =?utf-8?B?KzlLYXdVRENObUcwVVR0R1lCZlBBZlJvNzF0dThVMXV3aFU4OW5HeXlEZW5o?= =?utf-8?B?Ry9YQ3NLSXNzdWVySm9hTHJEakZ2YXVqS0JJbHJFQjdkK09DbTN6eUNUVEpu?= =?utf-8?B?R2syRDZQWjFIWWdYZWZqVHQwSEZOYWRZeTl0M1M1MWVCS2ZweFF3WW83Sk9B?= =?utf-8?B?WG9kODRCSG1vQWZIdXJ3aE1aWFZhL3pPdnJJNE9jUmRnOUNidkkzRlhBUXR0?= =?utf-8?B?ekZJRFdUaGZJdFJtMkZnU1FJNWZ5MjArMVM0QUJEdjNoU0pMditqbmFCSXV5?= =?utf-8?B?a1VTb3FlTVdxbHhRcW1tdGxOYXdsaFlJdURXL1dTYkdjWE9PU0s5S3h2ejVp?= =?utf-8?B?dmc0cHJXQVNTdUxtL1FUdHZvMFZGUXl6alppL1ErSHBJNlV3R2pvM1dZOXIr?= =?utf-8?B?ZE1EY0pweTkyU3lJMXc1eGdyOHo2bmpLZHA2YkhyNTk5a200dTI1bWpUcWcz?= =?utf-8?B?Y1ErQTBJdFhPSVdWNUt5anlZeGhSZ0xGSUZ1MjVnanE2N0oxWURqM0ZxVnZE?= =?utf-8?B?OVg4OG9mNVlJbUVoQmR1dE8yak80ZzRFTjV3YUR5MlIvdmduSDg2YnN0RHM2?= =?utf-8?B?S1BGNE13NEdSUWZDRDdwYTc1U1FmTERhRVN4L2x4ZjVIcVF3TlA1UDVOZTJ0?= =?utf-8?B?YXVyUTR0NGlPR1QwVWlEclppUmRBcS8vNGJsVHh0RFVwY2ZaV0RmcnFSSVFH?= =?utf-8?B?R3hvQTl5SXFtK1JDeXo1djNUWjFuNlNNQkxSdmowb2JZQ1hBczNRMzNVVlNU?= =?utf-8?B?S084aXljMDlmcVRreDlxZlBPUGhjMDQ5U1g1c3k5UkFZMDFvTmg3YkNlQTd1?= =?utf-8?B?d3Y2eTlkZmdBak9aNjdxUUlKK0RLVTFCeU03eGM5bnRtQmJyRUJ0RjBLUnJy?= =?utf-8?B?NFhQa0lvY0hubUU3c3owcll2U2M2NU5GaGtad3FBVVhpbndobnJWZGlhUVZ6?= =?utf-8?B?Mk5kZE9obnZhc3B0cmxtN0I3NFZvQ3ZMSkplUSswRlVqekNyMWZmUTFObUVj?= =?utf-8?B?SUk1UjdxMy9ZL2w2ZDlWRC9SR09NVEJzTzBYRnQ4UTNtMWs3eDdmZ2tUdFBo?= =?utf-8?B?bWxEV08vRVY5eUN2ZkFhMm9BR1V2SENvMzFrTERVQmlJNWpreXFvZG1uOVI4?= =?utf-8?B?RlptT2tneTk1Ni9lZlFNQVJTdUx5eWlpakpJeDRxM2I4YjA5WEhVU3NVZU5S?= =?utf-8?B?QmJtRmY4LzFXVmRxYkNBNk93NVhuVEhLMTgxcThmQk9YMnIza055cHRrWDJ6?= =?utf-8?B?WG04bWxlNHlhVW81aTErNGUzWGN1OXBJeW9Za3NSbzZwbjVsN1hwWno3TlVQ?= =?utf-8?B?b3VNVkszYUE3dmNVNlBxUmtWbiszNmtBRFdEVmhJelRsbzZkcmFYQkdHZjVn?= =?utf-8?B?a2FSeHlHUjdESXViUVN5Mk9HNzdnPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 15:41:34.4001 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 048e6fb7-3dc5-4503-0cfc-08de583a6424 X-MS-Exchange-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: SA2PEPF00003F63.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4065 On Tue Jan 20, 2026 at 4:28 PM CET, Alejandro Vallejo wrote: > On Tue Jan 20, 2026 at 3:32 PM CET, Jan Beulich wrote: >> On 20.01.2026 15:26, Andrew Cooper wrote: >>> On 20/01/2026 2:16 pm, Jan Beulich wrote: >>>> On 20.01.2026 15:11, Andrew Cooper wrote: >>>>> On 20/01/2026 1:34 pm, Jan Beulich wrote: >>>>>> On 20.01.2026 14:29, Andrew Cooper wrote: >>>>>>> On 20/01/2026 1:27 pm, Jan Beulich wrote: >>>>>>>> On 20.01.2026 14:18, Andrew Cooper wrote: >>>>>>>>> On 20/01/2026 9:53 am, Alejandro Vallejo wrote: >>>>>>>>>> --- a/xen/arch/x86/hvm/svm/vmcb.c >>>>>>>>>> +++ b/xen/arch/x86/hvm/svm/vmcb.c >>>>>>>>>> @@ -66,6 +66,12 @@ static int construct_vmcb(struct vcpu *v) >>>>>>>>>> GENERAL2_INTERCEPT_XSETBV | GENERAL2_INTERCEPT_ICE= BP | >>>>>>>>>> GENERAL2_INTERCEPT_RDPRU; >>>>>>>>>> =20 >>>>>>>>>> + if ( cpu_has_bus_lock_thresh ) >>>>>>>>>> + { >>>>>>>>>> + vmcb->_general3_intercepts =3D GENERAL3_INTERCEPT_BUS_L= OCK_THRESH; >>>>>>>>> |=3D >>>>>>>>> >>>>>>>>>> + vmcb->bus_lock_thresh =3D 1; /* trigger immediately */ >>>>>>>>> Really?=C2=A0 The APM states: >>>>>>>>> >>>>>>>>> On processors that support Bus Lock Threshold (indicated by CPUID >>>>>>>>> Fn8000_000A_EDX[29] BusLockThreshold=3D1), the VMCB provides a Bu= s Lock >>>>>>>>> Threshold enable bit and an unsigned 16-bit Bus Lock Threshold co= unt. On >>>>>>>>> VMRUN, this value is loaded into an internal count register. Befo= re the >>>>>>>>> processor executes a bus lock in the guest, it checks the value o= f this >>>>>>>>> register. If the value is greater than 0, the processor executes = the bus >>>>>>>>> lock successfully and decrements the count. If the value is 0, th= e bus >>>>>>>>> lock is not executed and a #VMEXIT to the VMM is taken. >>>>>>>>> >>>>>>>>> So according to the APM, setting the count to 1 will permit one b= us lock >>>>>>>>> then exit (fault style) immediately before the next.=C2=A0 This a= lso says >>>>>>>>> that a count of 0 is a legal state. >>>>>>>> But then you'd livelock the guest as soon as it uses a bus lock. A= re you >>>>>>>> suggesting to set to 1 in response to a bus lock exit, and keep at= 0 at >>>>>>>> all other times? >>>>>>> I should have been clearer.=C2=A0 I'm complaining at the "trigger >>>>>>> immediately" comment, because I don't think that's a correct statem= ent >>>>>>> of how hardware behaves. >>>>>> In turn I should have looked at the patch itself before commenting. = The >>>>>> other setting to 1 is what makes sense, and what ought to prevent a >>>>>> livelock. The one here indeed raises questions. >>>>> Setting it to 1 here is fine.=C2=A0 This is the constructor for VMCBs= , and >>>>> *something* needs to make the state consistent with the setting we ch= ose >>>>> at runtime. >>>> But the setting at runtime is generally going to be 0 >>>=20 >>> First, we need clarity on what "Initialising as zero is invalid and >>> causes an immediate exit." means. >> >> +1 > > The exit is not an VMEXIT_INVALID, if that's your fear. Let me clarify: > > The TL;DR is that the commit message is the unfortunate side effect of tr= ying > to remember why I did something a while ago and not remembering very well= . > > Initialy I had zero at both the initialiser and the reset. That doesn't g= et > very far until you notice the behaviour is a fault and not a trap, which = the APM > states as: > > ``` > If the value is 0, the bus lock is not executed and a #VMEXIT to the VMM = is > taken > ``` > > Then in order to go past that boundary the reset must be set at 1, or the= guest > loops. The initialisation may start at either (though zero would be more > consistent). > > I guess over time I just internalised a bit too much "I can't exec vmrun = with > a counter of 0". > > I'll send a v2 with the initialiser set to zero and an amended commit mes= sage. ... pending a hardware test, because the board I have with me ATM doesn't support the feature and need to get ahold of one. > > Cheers, > Alejandro From xen-devel-bounces@lists.xenproject.org Tue Jan 20 15:53:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 15:53:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209193.1521294 (Exim 4.92) (envelope-from ) id 1viE2l-0005l7-P0; Tue, 20 Jan 2026 15:53:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209193.1521294; Tue, 20 Jan 2026 15: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 1viE2l-0005l0-Ly; Tue, 20 Jan 2026 15:53:23 +0000 Received: by outflank-mailman (input) for mailman id 1209193; Tue, 20 Jan 2026 15:53: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 1viE2j-0005ku-JD for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 15:53:22 +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 21a362b4-f618-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 16:53:15 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by VI2PR03MB10811.eurprd03.prod.outlook.com (2603:10a6:800:280::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 15:53:12 +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.9520.011; Tue, 20 Jan 2026 15:53: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: 21a362b4-f618-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=s4iwhp8qZaoLU9Z05f2Odfmuj0lWo8EeiMkXnn+Uqr6ojGFeJvM24Vv9CTbXE3QqysNmUjXVVfqhuJrFrqi0T4maiuaIOuMhitgiLMA0wS8YZ/u9OR7qyayxi8oSuuMEpuwSvyNp3MUHAskd8KT7TOTihDQUwSo/qMBRJcMIxNsHDLg3wpMFQD21lZaUI6NIraBO1L01RuMZWaTrZqWtfyXl5XxmJ2CKKFWAHB2ZTu0L5BqQntbGAcFSARxZ8SrajpCPVtS+uVkbQ4MJg6lU8KSwdFkSnJ5QbJx2vdL9Ydru6xArjn9syMp46omztvduo3ncwdPlKbugP9Ns0UFdTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2cfc7MshSvZl/VX07+T+7MFV4PooLWxIesbYiRJZWpc=; b=MSweDBBfRbwoG7ymnzgEeaDWrUiusthDvCA8HLYcPO+50JmfMejedvN+EEF/C7kOEspaqrz/fuJdnnDIkngPoTYHohKgNeA8P3MrjnPYDfd5wfv9TpI4bEthCMC6IHCSnbNdyaKcfKB1F8OxeYx+luo9I2VxoMbNPaUZKPOy6vgDalmYvpAmbUIh+K0xxCldHSV0xsyshnkpZPOXUq8eW05ocZJ5My3EXzBNh8yfCL1RwxuOo4gW/xzGoHwDAW4Wm1dTdcBMGwPm06M8Qd2+2xbweg48jY6+sJZtSlEhVDqm3n4ZUSbGlcai3//3Tl/nqDCtbK9DCqBLbkUoYLr9yw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2cfc7MshSvZl/VX07+T+7MFV4PooLWxIesbYiRJZWpc=; b=u2cNQuQyH2K9gQhiQHFKpeT1yx6xqQvNaFd0lC70ywEWdZOlPbInkrnCRXLQ/jZaQudxUf/MMu8Q+LaruAmG0FatTPchlT/FzXa/kcOxTw/2x/OOCX486j+DbYbLGXoNSfD9W80erQjrb0JOWe4gfdCF42p0heDnP0eKWMcQC2fYEGmT6fZ1d9XCT+GM53eGkojNx0rmJvtGnMAzIy5rOzFeHoUoaFqv0tRd7OCCL5BQMqOd7UYFTP+MyANMBkEy5jHdMeIwQsomuDsstYJpexdn/aX9HigUd3LhN3KaWMhgMfN4BIHpRM8ORoSfB65QHWlw/6BKaLBW5BZJ4ejDhg== 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 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [PATCH v7 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHchYPEY703sAu32kaCSJHhjFUjhrVSbXkAgAKOa4CAAFUugIAEnmUAgAAWGoCAATknAA== Date: Tue, 20 Jan 2026 15:53:11 +0000 Message-ID: <4278b6df-11fc-403f-b498-16afe3e0c779@epam.com> References: <5177397f-d596-40b3-9207-f0de63a24ee6@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_|VI2PR03MB10811:EE_ x-ms-office365-filtering-correlation-id: 3bd1cd3c-9692-4dba-fd10-08de583c03d5 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|7416014|366016|1800799024|38070700021|19052099003; x-microsoft-antispam-message-info: =?utf-8?B?TGlCYXozM2JmL3E5ZkVrSlFBbnh1bGthYTVZbXNkRytsZmJnRkFUUG14alYx?= =?utf-8?B?VUFLWEVjMDNzU3c5dG5nbkZWdCtmdGhKMmVTeFZVbWdBNGkzYnFQVVNHb2Zr?= =?utf-8?B?c1ltN2oxVy91VzBMMDhnOFpBdHhoSjM4b09sYm10T3Z6NEdvNGlNc1R3eXg0?= =?utf-8?B?RVVEN0phcHZ2aGZsZ2NZby9QRFlHK3pCaCtlcnpway9TNWNKamJlVWJMTUlI?= =?utf-8?B?ck5SNEpLYVcvaXl1NmV5RlpubmxpTTd5b1p3aVd1eFJMSFgvV2lKVUtKVDEz?= =?utf-8?B?MWdUZnRtQnFWNkYrZit1RVIvSVNsaGVtMzdxazVvQUVLZEptS09vbG5QYy9B?= =?utf-8?B?MEhXdW4xZTJ1WFMySGFLTUNiVkFZRlQyOHVvaEtUSlRadUtsMkZJMzBBWW1X?= =?utf-8?B?MUJoSlk3VEFXdEVvOHBvdWFKdElzdWd4OFhuSnZnWitiUlJ3aU1oT3poU1lL?= =?utf-8?B?WnhnVFNCNHI5MExyaXlqeVBHZUlxZ0Y1UDNsMGVvNmticDJzZk5jdm1JNzlv?= =?utf-8?B?MThKU0p0UlA4WVlOVmJnbGZla2w5YzNWNlQ3akVzS1NxeDZTakFNUzlWSFRu?= =?utf-8?B?MGdUMEswNytrRlQramwxdWVnb1JWVW9hY1VDMlRqVGtGVFFLcnVXcVFFOEpi?= =?utf-8?B?TURBd0c0YnBiQmJva0IxNXRmbllLdXFaZ1RXdE8vd2l1bElobVNscmZZcGcw?= =?utf-8?B?SGpreStFVWd5SVJiM1pGZWZLenZ2bElvWDY2OFJpcVJMUURDckxtb3pBWjIx?= =?utf-8?B?VUt0SG9LbTJFampGMmFETTBZanBKSngwYU13VUVLSyttK0tSTWYyQWQralZw?= =?utf-8?B?Q1cxQ016N2pNZlVVRnZzazMyeTMrb1h6T1JveUsrbWE0YUJaVks3TVkxZkVD?= =?utf-8?B?dC9HMnJ6MmhwOW14VVJJajF0d0x3cmxKd05TR1RnUWU3QzV6Zk1tRVFhUDN1?= =?utf-8?B?U2YxQ2xNdzlqMmZoNFFEQ0xIV0FybmhKQUZMUlZYcXdncTNPei80VWwzbldM?= =?utf-8?B?a2JsVGNZZVBoam9mYUl5a0hHSXhoZU84NzRpLzhTbzc2V0lrMEpBTjY3VHRy?= =?utf-8?B?VURUOHN2WHkzcVB1OVVJRTF0Y3Q5RGxmVWJIVGNnMkpTbTBTOUFqZFM4OUFZ?= =?utf-8?B?dGlRcEpTTGRQOEtuejZ2RXIyNVdxOW9TSnc0cWNwZ1RrRXZ5Rmh5MDBRaVhh?= =?utf-8?B?NUxaRlN3TnA2YmdyVDRpeUxiOGo1UzFtd0d4Z2hEeHBNNkV4Nmh3REdvZWlK?= =?utf-8?B?V0tXRm90bGI4SlhINVZobDIxL0xQQ3grdHI3cFFJak96cWVxTlEveXN6Y0FU?= =?utf-8?B?cVJBY1o2MUpkeEd5UWtrVFlMUGFOSnR0TE1iMU56WWtIMDVMUE1mUGNsdy9F?= =?utf-8?B?VlZSQWFRSHhvdnR0bHNxYmplRmdPT1FhSFh4TlhGcHB6R0N1V2dNbnpYOXpV?= =?utf-8?B?bmx0bTZjVWNScTIxMGMrVVMzckFtL1dNZnZNYndqNTlBb2FtZlVrc2g1SHdq?= =?utf-8?B?bWtYMzRLaUFBeVg2ZWsydUVXUUtnWFVCMnRmOWx6d096ZGpLMlUrcThiU3pD?= =?utf-8?B?ZlRNd3hxMUpqNDNLYk96L3lqYlBGOVJhOGhvcEEvU1ZyYmRhZTBOS3pZelUv?= =?utf-8?B?QWhRWk8vcEpFTWppZHRTa1hwNStMTU1jT1FoTkExSjBIYjNDYi9SWnZXc1Ft?= =?utf-8?B?SnExQ2N5MnhQZk02Qk1OTnJzVTNodFFKREJSVGE4NS9kTElMMVpHVHBYWEY5?= =?utf-8?B?d2N6WjdmMDd4bUgzS2JiaGZIOEFiandBbWtqN3hSdVNyMkM3eElGSEI3U1d6?= =?utf-8?B?aVU3L1h4eWswK1BFZ1V1MGl6bUp4SVV3NG9CMnpESHJpdkhuNElpVW5nc0Yw?= =?utf-8?B?MklIeDE0NkRvWWUwdm9Uc0duWDYrZTNTOC9LRS92ZndCTmJWallrbmIzMW5v?= =?utf-8?B?WCtUMUQrdWJJMzRDWmZBbEJXOE5Nc2xqZlVkck1yc3V6eCthaFV4emtQOUwv?= =?utf-8?B?T2pPMzRoWjBpVk5IbDhXMWF4MVFwSlVvVm01ZzBONTViWDRqZnAwSHl2cDVX?= =?utf-8?B?bmk2VXdPeGt3dzhLYjRFeDFva2l2UEFVRXd4cGZXTHRYbUxJcENGMHVkMUc4?= =?utf-8?B?OTdleVBlbDdXMUtGMlJJNWFxUk01VVFDUGpjYUJOc2xoYmx5Q2hGRDBRVG1G?= =?utf-8?Q?ZWmyBfk8i193Jp9Al86AeLY=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(1800799024)(38070700021)(19052099003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MERvTy92Z1FYV3NPOGo0VUllUW5UU0VtTWdxYXlCaDVGSU9rVVhLN3loczhX?= =?utf-8?B?TUU1bWluWXY2aGU4dGJyU3h1cXVOazVYVFBKb3BCSnpEZStsSXllT241UUZp?= =?utf-8?B?UW9vVCs2bm44RzdRNmM4cjNMTVZrOS9CaU01V2F6d2dMQi9Cdm5ocWVYaXA4?= =?utf-8?B?RGUwcG1ZS0podjBIaHJWQk5SYThiRlk5eFpDWFVDbUFFbXB3N05wNFVFbUhi?= =?utf-8?B?dDVadmZSQU5sa0Z2elJKZ3NBbTlGQ0RTbjdIM2tTTk54K0FNWDhIVElwSjBa?= =?utf-8?B?U2VYZFd4VXk4R3NuVWQ4b0U5bnl6RXJoZ3ZEaEFHcVdaRzF3dGVHSUZQQkRK?= =?utf-8?B?WnVGbXRmdTRmakRXT1JsRU5tK2hEYy9SQ1VLTHkvUWNQanh1WUxITFhhMDNt?= =?utf-8?B?Sk1ubVVEK3pXVEFIcmFKNWszN1JTSVhwQ1ZraDdoQmpUVHNqWFd4OEpsMnNm?= =?utf-8?B?YXVuOGNIRGVLM2VUWCtEQzJOam5uWnBuU0kvYTA0NTY3eXBLMXR2bVZPSFJu?= =?utf-8?B?V2QwcTduUDB1cEJYRG9Edmt0SVRGYXNMUitXR2pUT2lOWU1Yazc2K2VyMTRy?= =?utf-8?B?MnJtaDMyaTJKcFJxbGJIYXZYUDJyL0tLT09adHVqRTRCeU0ySkR4b0VHejRn?= =?utf-8?B?VGQzV0FQOW8vdXZnRVoyUEUwQkdZVjZNYTJRWVdpbndrYkx5SkZSMktWS21p?= =?utf-8?B?YXM4Rk90YTc2Q1MzLzg2QXNVZGtxaVdQZ0ExOWdMeUpuQTlCZTQ4RHVKenJ5?= =?utf-8?B?ektWV3hZaW8yTG0rZTVZcnRDN3B2eTJUUHJ4QXdTWTBpeTJVc2w1OThIWTRk?= =?utf-8?B?Z3hKL2NNa1hic2pyRXlVTlluNjdWUUZyOWZQMnVPQW0vbG1aam9ZRnBRSSt2?= =?utf-8?B?ZGdvcUV4VTVvZmNVeW83bWhVMWNtNE5iaHpUWlNER0lncEZ3ZDFhWmdmd1Fp?= =?utf-8?B?YnR1STlYUXdWeGppSXVqeVJYODR4LytSSVRDM2hpdjZ6VFNhMGtBaERYcHYr?= =?utf-8?B?U2c3aUxkQWVBVThUMjlpVDFhTjl2RzE1d3QxY3VGZDBWckVKWEZwQVZJdzdp?= =?utf-8?B?bURPWFpVV0xlcy91dGw5QzN5MGI5UjR5L083bDNleDJqZHdVamhzWVNxQS9D?= =?utf-8?B?OXpOYmV0K0JmVmgwTFowTVN4cWNRalR2UDRBZzN4YkV5bmN6cjFjd3RoeURN?= =?utf-8?B?WHZnOTdsVHdUbGkzcUh3TVhIbUVEWWxrdW1rSkh3ZmoyTHdXcUxNLzUxWHlK?= =?utf-8?B?MHVYd1AwbUtldm1ISTVMTFhyR1NiKy96WjYxNG5ac1JhRWdVQUZIR0FEaytS?= =?utf-8?B?MDRrUmpKa1hHSnpzVER6NS9VZU0rbTNleFdzbVJXZU9YVDA4MzdoRUsrcVJS?= =?utf-8?B?NXl6WkluMGR1QkFDRXo1bkhlYkFQK2FFVXhhUmZuZ0VMR09SdHBKYnlKMDFx?= =?utf-8?B?L1QyQXJVK254MWs4citlNC9LOXFEcHNTVmRQazRLMEd5dmVvZ2ZKTHdLSFhS?= =?utf-8?B?cS9hTWhqSmlSdy9KL1VMVzF3amRWcGR5OVUrbU1XdTBJeUNWWllpdU9GVVR0?= =?utf-8?B?ZTZ2R3VkZW40UHl2MVN5WkhEUWJRbFFmRUJqclByZmtrZnlIUWJTc3YyTUh2?= =?utf-8?B?WTNOeG1VZWdNa29sczVZYU8raWJnNVZ3YWI0ZUtmcnBJci91VTBPazkyOXlG?= =?utf-8?B?SU9zN291TVk5YVpXSXJOaC9GZWV2QlhPSy9qTTdpb2Y1SkNTb0lpYlZVS29M?= =?utf-8?B?czRtaEtibStlUXgwOC9CNDVjRllYeGY1cnFnTldSRlpQdlNHcFdGYVhmcVZ5?= =?utf-8?B?Z3prS1VMS2ZpREMwU1RGQlNHc2tOcHJUMmQ1QzFjUUo5NnBMSTNJc0NOcG0r?= =?utf-8?B?RXprN0hqelMxQTNJdnY4cFZ4NFU4WFdKbFhHbTZETlJPTlhBblltUVlNVFU1?= =?utf-8?B?b3Njc0Eranc5cStuR245RG5NOFQyLzNuTXhaK0J6aE40MytENWh0QzJRdTRh?= =?utf-8?B?ZldSWkZNdnI4ZnM3U0FOclpoRnREWmRGYXBMelY0QmZWbFhPVHpydXBteHN5?= =?utf-8?B?MVFFRUx0VGVjcjFjWWFsTGlPTVhFYzI0bzAxQ2g0RjM3V013K0UyaEZyK1VQ?= =?utf-8?B?OWI3SVZWQTg5L1FSQkNlakM2d3dOaDQxY0xTMjFUai9zaVBFUk5uSHBwNTJt?= =?utf-8?B?bWVGZlFEMW8xUDNHckJLaEhZS2hTZGRmQ21Uekh6WFNCVGpFLzZYbzNLNUor?= =?utf-8?B?TlJ6S29scEYwVE9zR0NuRnVVVUo0R1ZUVnRTTU9YUEV3WFVZYllwTUhJT0Rt?= =?utf-8?B?VjdXT3dPR3RIdXRkNDZFSFJ5YjlRcXdMOW9NbWVqa3RieDJ1N3ZWRWNHNURM?= =?utf-8?Q?u1x0MUILGipHhQ5w=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: PAVPR03MB8946.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3bd1cd3c-9692-4dba-fd10-08de583c03d5 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2026 15:53:11.8299 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /lWNwDt0LxE/FijKOhHQplK3aNHgNqxDi6e0m64c5V1y/wSJuG4iibJ1KjCieA6RYwNtQgwnTl0mr7lltyrMrjP1prUkRb2zbAZ9Zp0JcD4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI2PR03MB10811 DQoNCk9uIDE5LzAxLzIwMjYgMjM6MTIsIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4gT24g TW9uLCAxOSBKYW4gMjAyNiwgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+PiBPbiAxNi8wMS8y MDI2IDIzOjIxLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+Pj4gT24gRnJpLCAxNiBKYW4g MjAyNiwgT2xla3NpaSBNb2lzaWVpZXYgd3JvdGU6DQo+Pj4+IEhpIFN0ZWZhbm8sDQo+Pj4+IFBs ZWFzZSBzZWUgYmVsb3cuDQo+Pj4+DQo+Pj4+IE9uIDE1LzAxLzIwMjYgMDM6MTQsIFN0ZWZhbm8g U3RhYmVsbGluaSB3cm90ZToNCj4+Pj4+IEhpIE9sZWtzaWksDQo+Pj4+Pg0KPj4+Pj4gSSBhbSBm aW5lIHdpdGggdGhlIGdvYWxzIGFuZCB0aGUgc3RyYXRlZ3kgdG8gYWNoaWV2ZSB0aGUgZ29hbHMg YnV0IHRoZXJlDQo+Pj4+PiBhcmUgc29tZSBmaW5lciBkZXRhaWxzIHRoYXQgZG9uJ3QgbWFrZSBz ZW5zZSB0byBtZS4gSSBhcG9sb2dpemUgaWYgSSBhbQ0KPj4+Pj4gYXNraW5nIHRoZSBzYW1lIHF1 ZXN0aW9ucyB5b3UgaGF2ZSBhbHJlYWR5IGFuc3dlcmVkIGFzIHNvbWUgdGltZSBhcw0KPj4+Pj4g cGFzc2VkIGZyb20gdGhlIGxhc3QgaW50ZXJhY3Rpb24uDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IE9u IFdlZCwgMTQgSmFuIDIwMjYsIE9sZWtzaWkgTW9pc2llaWV2IHdyb3RlOg0KPj4+Pj4+IFRoaXMg cGF0Y2ggaW50cm9kdWNlcyBTQ0kgZHJpdmVyIHRvIHN1cHBvcnQgZm9yIEFSTSBFTDMgVHJ1c3Rl ZCBGaXJtd2FyZS1BDQo+Pj4+Pj4gKFRGLUEpIHdoaWNoIHByb3ZpZGVzIFNDTUkgaW50ZXJmYWNl IHdpdGggbXVsdGktYWdlbnQgc3VwcG9ydCwgYXMgc2hvd24NCj4+Pj4+PiBiZWxvdy4NCj4+Pj4+ Pg0KPj4+Pj4+ICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KPj4+Pj4+ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KPj4+Pj4+ICAgICAgfCBFTDMgVEYtQSBTQ01JICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KPj4+Pj4+ICAgICAgKy0tLS0tLS0rLS0rLS0tLS0tLSstLSstLS0tLS0tKy0tKy0tLS0tLS0r Kw0KPj4+Pj4+ICAgICAgfHNobWVtMSB8ICB8c2htZW0wIHwgIHxzaG1lbTIgfCAgfHNobWVtWCB8 DQo+Pj4+Pj4gICAgICArLS0tLS0rLSsgICstLS0rLS0tKyAgKy0tKy0tLS0rICArLS0tKy0tLSsN Cj4+Pj4+PiBzbWMtaWQxIHwgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgICB8DQo+Pj4+Pj4g YWdlbnQxICB8ICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgfA0KPj4+Pj4+ICAgICAgKy0t LS0tdi0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tKw0KPj4+Pj4+ICAgICAgfCAg ICAgICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgIHwgICAgfA0KPj4+Pj4+ICAgICAgfCAg ICAgICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgIHwgICAgfA0KPj4+Pj4+ICAgICAgKy0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tKw0KPj4+Pj4+ICAgICAgICAg ICAgIHNtYy1pZDAgfCAgc21jLWlkMnwgICAgc21jLWlkWHwNCj4+Pj4+PiAgICAgICAgICAgICBh Z2VudDAgIHwgIGFnZW50MiB8ICAgIGFnZW50WCB8DQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICB8ICAgICAgICAgfCAgICAgICAgICAgfA0KPj4+Pj4+ICAgICAgICAgICAgICAgICstLS0tdi0t LSsgICstLXYtLS0tLSsgICstLXYtLS0tLSsNCj4+Pj4+PiAgICAgICAgICAgICAgICB8ICAgICAg ICB8ICB8ICAgICAgICB8ICB8ICAgICAgICB8DQo+Pj4+Pj4gICAgICAgICAgICAgICAgfCBEb20w ICAgfCAgfCBEb20xICAgfCAgfCBEb21YICAgfA0KPj4+Pj4+ICAgICAgICAgICAgICAgIHwgICAg ICAgIHwgIHwgICAgICAgIHwgIHwgICAgICAgIHwNCj4+Pj4+PiAgICAgICAgICAgICAgICB8ICAg ICAgICB8ICB8ICAgICAgICB8ICB8ICAgICAgICB8DQo+Pj4+Pj4gICAgICAgICAgICAgICAgKy0t LS0tLS0tKyAgKy0tLS0tLS0tKyAgKy0tLS0tLS0tKw0KPj4+Pj4+DQo+Pj4+Pj4gVGhlIEVMMyBT Q01JIG11bHRpLWFnZW50IGZpcm13YXJlIGlzIGV4cGVjdGVkIHRvIHByb3ZpZGUgU0NNSSBTTUMg c2hhcmVkDQo+Pj4+Pj4gbWVtb3J5IHRyYW5zcG9ydCBmb3IgZXZlcnkgQWdlbnQgaW4gdGhlIHN5 c3RlbS4NCj4+Pj4+Pg0KPj4+Pj4+IFRoZSBTQ01JIEFnZW50IHRyYW5zcG9ydCBjaGFubmVsIGRl ZmluZWQgYnkgcGFpcjoNCj4+Pj4+PiAgICAgLSBzbWMtaWQ6IFNNQyBpZCB1c2VkIGZvciBEb29y YmVsbA0KPj4+Pj4+ICAgICAtIHNobWVtOiBzaGFyZWQgbWVtb3J5IGZvciBtZXNzYWdlcyB0cmFu c2ZlciwgWGVuIHBhZ2UNCj4+Pj4+PiAgICAgYWxpZ25lZC4gU2hhcmVkIG1lbW9ydCBpcyBtYXBw ZWQgd2l0aCB0aGUgZm9sbG93aW5nIGZsYWdzOg0KPj4+Pj4+ICAgICBNVF9ERVZJQ0VfbkduUkUu DQo+Pj4+Pj4NCj4+Pj4+PiBUaGUgZm9sbHdvaW5nIFNDTUkgQWdlbnRzIGFyZSBleHBlY3RlZCB0 byBiZSBkZWZpbmVkIGJ5IFNDTUkgRlcgdG8gZW5hYmxlIFNDTUkNCj4+Pj4+PiBtdWx0aS1hZ2Vu dCBmdW5jdGlvbmFsaXR5IHVuZGVyIFhlbjoNCj4+Pj4+PiAtIFhlbiBtYW5hZ2VtZW50IGFnZW50 OiB0cnVzdGVkIGFnZW50cyB0aGF0IGFjY2Vzc2VzIHRvIHRoZSBCYXNlIFByb3RvY29sDQo+Pj4+ Pj4gY29tbWFuZHMgdG8gY29uZmlndXJlIGFnZW50IHNwZWNpZmljIHBlcm1pc3Npb25zDQo+Pj4+ Pj4gLSBPU1BNIFZNIGFnZW50czogbm9uLXRydXN0ZWQgYWdlbnQsIG9uZSBmb3IgZWFjaCBHdWVz dCBkb21haW4gd2hpY2ggaXMNCj4+Pj4+PiAgICAgIGFsbG93ZWQgZGlyZWN0IEhXIGFjY2Vzcy4g QXQgbGVhc3Qgb25lIE9TUE0gVk0gYWdlbnQgaGFzIHRvIGJlIHByb3ZpZGVkDQo+Pj4+Pj4gICAg ICBieSBGVyBpZiBIVyBpcyBoYW5kbGVkIG9ubHkgYnkgRG9tMCBvciBEcml2ZXIgRG9tYWluLg0K Pj4+Pj4+DQo+Pj4+Pj4gVGhlIEVMMyBTQ01JIEZXIGlzIGV4cGVjdGVkIHRvIGltcGxlbWVudCBm b2xsb3dpbmcgQmFzZSBwcm90b2NvbCBtZXNzYWdlczoNCj4+Pj4+PiAtIEJBU0VfRElTQ09WRVJf QUdFTlQgKG9wdGlvbmFsIGlmIGFnZW50X2lkIHdhcyBwcm92aWRlZCkNCj4+Pj4+PiAtIEJBU0Vf UkVTRVRfQUdFTlRfQ09ORklHVVJBVElPTiAob3B0aW9uYWwpDQo+Pj4+Pj4gLSBCQVNFX1NFVF9E RVZJQ0VfUEVSTUlTU0lPTlMgKG9wdGlvbmFsKQ0KPj4+Pj4+DQo+Pj4+Pj4gVGhlIFNDSSBTQ01J IFNNQyBtdWx0aS1hZ2VudCBkcml2ZXIgaW1wbGVtZW50cyBmb2xsb3dpbmcNCj4+Pj4+PiBmdW5j dGlvbmFsaXR5Og0KPj4+Pj4+IC0gVGhlIGRyaXZlciBpcyBpbml0aWFsaXplZCBmcm9tIHRoZSBY ZW4gU0NNSSBjb250YWluZXIgYGB4ZW5fc2NtaV9jb25maWdgYA0KPj4+Pj4+ICAgICAgKGNvbXBh dGlibGUgYGB4ZW4sc2NpYGApIHBsYWNlZCB1bmRlciBgYC9jaG9zZW4veGVuYGAuIE9ubHkgdGhl DQo+Pj4+Pj4gICAgICBgYGFybSxzY21pLXNtY2BgIG5vZGUgdGhhdCBpcyBhIGNoaWxkIG9mIHRo aXMgY29udGFpbmVyIHdpbGwgYmluZCB0byBYZW47DQo+Pj4+Pj4gICAgICBvdGhlciBTQ01JIG5v ZGVzIChmb3IgZXhhbXBsZSB1bmRlciBgYC9maXJtd2FyZWBgKSBhcmUgaWdub3JlZCB0byBhdm9p ZA0KPj4+Pj4+ICAgICAgc3RlYWxpbmcgdGhlIGhvc3QgT1NQTSBpbnN0YW5jZS4NCj4+Pj4+Pg0K Pj4+Pj4+IHNjbWlfc2htXzE6IHNyYW1ANDdmZjEwMDAgew0KPj4+Pj4+ICAgICAgICAgICAgICBj b21wYXRpYmxlID0gImFybSxzY21pLXNobWVtIjsNCj4+Pj4+PiAgICAgICAgICAgICAgcmVnID0g PDB4MCAweDQ3ZmYxMDAwIDB4MCAweDEwMDA+Ow0KPj4+Pj4+IH07DQo+Pj4+Pj4gc2NtaV94ZW46 IHNjbWkgew0KPj4+Pj4+ICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zbWMiOw0K Pj4+Pj4+ICAgICAgICAgICAgYXJtLHNtYy1pZCA9IDwweDgyMDAwMDAzPjsgPC0tLSBYZW4gbWFu YWdlbWVudCBhZ2VudCBzbWMtaWQNCj4+Pj4+PiAgICAgICAgICAgICNhZGRyZXNzLWNlbGxzID0g PCAxPjsNCj4+Pj4+PiAgICAgICAgICAgICNzaXplLWNlbGxzID0gPCAwPjsNCj4+Pj4+PiAgICAg ICAgICAgICNhY2Nlc3MtY29udHJvbGxlci1jZWxscyA9IDwgMT47DQo+Pj4+Pj4gICAgICAgICAg ICBzaG1lbSA9IDwmc2NtaV9zaG1fMT47IDwtLS0gWGVuIG1hbmFnZW1lbnQgYWdlbnQgc2htZW0N Cj4+Pj4+PiB9Ow0KPj4+Pj4+DQo+Pj4+Pj4gLSBUaGUgZHJpdmVyIG9idGFpbnMgWGVuIHNwZWNp ZmljIFNDTUkgQWdlbnQncyBjb25maWd1cmF0aW9uIGZyb20gdGhlDQo+Pj4+Pj4gICAgICBIb3N0 IERULCBwcm9iZXMgQWdlbnRzIGFuZCBidWlsZHMgU0NNSSBBZ2VudHMgbGlzdC4gVGhlIEFnZW50 cw0KPj4+Pj4+ICAgICAgY29uZmlndXJhdGlvbiBpcyB0YWtlbiBmcm9tICJzY21pLXNlY29uZGFy eS1hZ2VudHMiIHByb3BlcnR5IHdoZXJlDQo+Pj4+Pj4gICAgICBmaXJzdCBpdGVtIGlzICJhcm0s c21jLWlkIiwgc2Vjb25kIC0gImFybSxzY21pLXNobWVtIiBwaGFuZGxlIGFuZA0KPj4+Pj4+ICAg ICAgdGhpcmQgaXMgb3B0aW9uYWwgImFnZW50X2lkIjoNCj4+Pj4+Pg0KPj4+Pj4+IC8gew0KPj4+ Pj4+ICAgICAgY2hvc2VuIHsNCj4+Pj4+PiAgICAgICAgeGVuIHsNCj4+Pj4+PiAgICAgICAgICBy YW5nZXM7DQo+Pj4+Pj4gICAgICAgICAgeGVuX3NjbWlfY29uZmlnIHsNCj4+Pj4+PiAgICAgICAg ICAgIGNvbXBhdGlibGUgPSAieGVuLHNjaSI7DQo+Pj4+Pj4gICAgICAgICAgICAjYWRkcmVzcy1j ZWxscyA9IDwyPjsNCj4+Pj4+PiAgICAgICAgICAgICNzaXplLWNlbGxzID0gPDI+Ow0KPj4+Pj4+ ICAgICAgICAgICAgcmFuZ2VzOw0KPj4+Pj4+DQo+Pj4+Pj4gICAgICAgICAgICBzY21pX3NobV8w OiBzcmFtQDQ3ZmYwMDAwIHsNCj4+Pj4+PiAgICAgICAgICAgICAgY29tcGF0aWJsZSA9ICJhcm0s c2NtaS1zaG1lbSI7DQo+Pj4+Pj4gICAgICAgICAgICAgIHJlZyA9IDwweDAgMHg0N2ZmMDAwMCAw eDAgMHgxMDAwPjsNCj4+Pj4+PiAgICAgICAgICAgIH07DQo+Pj4+Pj4NCj4+Pj4+PiAgICAgICAg ICAgIC8qIFhlbiBTQ01JIG1hbmFnZW1lbnQgY2hhbm5lbCAqLw0KPj4+Pj4+ICAgICAgICAgICAg c2NtaV9zaG1fMTogc3JhbUA0N2ZmMTAwMCB7DQo+Pj4+Pj4gICAgICAgICAgICAgIGNvbXBhdGli bGUgPSAiYXJtLHNjbWktc2htZW0iOw0KPj4+Pj4+ICAgICAgICAgICAgICByZWcgPSA8MHgwIDB4 NDdmZjEwMDAgMHgwIDB4MTAwMD47DQo+Pj4+Pj4gICAgICAgICAgICB9Ow0KPj4+Pj4+DQo+Pj4+ Pj4gICAgICAgICAgICBzY21pX3NobV8yOiBzcmFtQDQ3ZmYyMDAwIHsNCj4+Pj4+PiAgICAgICAg ICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+Pj4+Pj4gICAgICAgICAgICAg IHJlZyA9IDwweDAgMHg0N2ZmMjAwMCAweDAgMHgxMDAwPjsNCj4+Pj4+PiAgICAgICAgICAgIH07 DQo+Pj4+Pj4NCj4+Pj4+PiAgICAgICAgICAgIHNjbWlfc2htXzM6IHNyYW1ANDdmZjMwMDAgew0K Pj4+Pj4+ICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxzY21pLXNobWVtIjsNCj4+Pj4+ PiAgICAgICAgICAgICAgcmVnID0gPDB4MCAweDQ3ZmYzMDAwIDB4MCAweDEwMDA+Ow0KPj4+Pj4+ ICAgICAgICAgICAgfTsNCj4+Pj4+Pg0KPj4+Pj4+ICAgICAgICAgICAgc2NtaS1zZWNvbmRhcnkt YWdlbnRzID0gPA0KPj4+Pj4+ICAgICAgICAgICAgICAweDgyMDAwMDAyICZzY21pX3NobV8wIDAN Cj4+Pj4+IDB4ODIwMDAwMDIgaXMgdGhlIHNhbWUgZnVuY19pZCBhcy4uLg0KPj4+Pj4NCj4+Pj4+ DQo+Pj4+Pj4gICAgICAgICAgICAgIDB4ODIwMDAwMDQgJnNjbWlfc2htXzIgMg0KPj4+Pj4+ICAg ICAgICAgICAgICAweDgyMDAwMDA1ICZzY21pX3NobV8zIDM+OyA8LS0tIGZ1bmNfaWQsIHNobWVt LCBhZ2VudF9pZA0KPj4+Pj4+ICAgICAgICAgICAgI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxs cyA9IDwzPjsNCj4+Pj4+Pg0KPj4+Pj4+ICAgICAgICAgICAgc2NtaV94ZW46IHNjbWkgew0KPj4+ Pj4+ICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxzY21pLXNtYyI7DQo+Pj4+Pj4gICAg ICAgICAgICAgIGFybSxzbWMtaWQgPSA8MHg4MjAwMDAwMj47IDwtLS0gWGVuIG1hbmFnZW1lbnQg YWdlbnQgZnVuY19pZA0KPj4+Pj4gYXMgdGhlIG9uZSB1c2VkIGZvciBYZW4uIFRoaXMgY2Fubm90 IGJlIHJpZ2h0Pw0KPj4+Pj4NCj4+Pj4gVGhhdCdzIHJpZ2h0LiBIZXJlIHNob3VsZCBiZSAweDgy MDAwMDAzLg0KPj4+Pj4+ICAgICAgICAgICAgICAjYWRkcmVzcy1jZWxscyA9IDwxPjsNCj4+Pj4+ PiAgICAgICAgICAgICAgI3NpemUtY2VsbHMgPSA8MD47DQo+Pj4+Pj4gICAgICAgICAgICAgICNh Y2Nlc3MtY29udHJvbGxlci1jZWxscyA9IDwxPjsNCj4+Pj4+PiAgICAgICAgICAgICAgc2htZW0g PSA8JnNjbWlfc2htXzE+OyA8LS0tIFhlbiBtYW5hZ2VtZW50IGFnZW50IHNobWVtDQo+Pj4+Pj4g ICAgICAgICAgICB9Ow0KPj4+Pj4+ICAgICAgICAgIH07DQo+Pj4+Pj4gICAgICAgIH07DQo+Pj4+ Pj4gICAgICB9Ow0KPj4+Pj4+IH07DQo+Pj4+Pj4NCj4+Pj4+PiAvIHsNCj4+Pj4+PiAgICAgICAg LyoNCj4+Pj4+PiAgICAgICAgICogSG9zdCBTQ01JIE9TUE0gY2hhbm5lbCAtIHByb3ZpZGVkIHRv IHRoZSBEb20wIGFzIGlzIGlmIFNDTUkNCj4+Pj4+PiAgICAgICAgICogZW5hYmxlZCBmb3IgaXQs IGlnbm9yZWQgYnkgWGVuIG11bHRpLWFnZW50IG1lZGlhdG9yDQo+Pj4+Pj4gICAgICAgICAqLw0K Pj4+Pj4+ICAgICAgICBzY21pX3NobTogc3JhbUA0N2ZmMDAwMCB7DQo+Pj4+Pj4gICAgICAgICAg ICAgICAgY29tcGF0aWJsZSA9ICJhcm0sc2NtaS1zaG1lbSI7DQo+Pj4+Pj4gICAgICAgICAgICAg ICAgcmVnID0gPDB4MCAweDQ3ZmYwMDAwIDB4MCAweDEwMDA+Ow0KPj4+Pj4+ICAgICAgICB9Ow0K Pj4+Pj4gdGhpcyBpcyB0aGUgc2FtZSBhcyAmc2NtaV9zaG1fMCB3aGljaCBJIGd1ZXNzIGlzIGlu dGVuZGVkPw0KPj4+Pj4NCj4+Pj4gaXQgaXMuIHRvIG1hdGNoIEhvc3QgRFQuDQo+Pj4+Pj4gICAg ICAgIGZpcm13YXJlIHsNCj4+Pj4+PiAgICAgICAgICBzY21pOiBzY21pIHsNCj4+Pj4+PiAgICAg ICAgICAgIGNvbXBhdGlibGUgPSAiYXJtLHNjbWktc21jIjsNCj4+Pj4+PiAgICAgICAgICAgIGFy bSxzbWMtaWQgPSA8MHg4MjAwMDAwMj47IDwtLS0gSG9zdCBPU1BNIGFnZW50IHNtYy1pZA0KPj4+ Pj4gYnV0IHRoaXMgYWdhaW4gaXMgdGhlIHNhbWUgc21jLWlkIG1lYW50IHRvIGJlIHVzZWQgYnkg WGVuLg0KPj4+Pj4NCj4+Pj4+IElmIDB4ODIwMDAwMDIgaXMgdGhlIHByaXZpbGVnZWQgaW50ZXJm YWNlLCB0aGVuIGl0IGlzIE9LIGZvciBYZW4gYW5kDQo+Pj4+PiBhbHNvIGJhcmVtZXRhbCBMaW51 eCB0byB1c2UgaXQsIGJ1dCBMaW51eCBEb20wIHNob3VsZCBub3QgYmUgdXNpbmcgaXQ/DQo+Pj4+ PiBPciBpcyB0aGUgc21jLWlkIGludGVyY2hhbmdlYWJsZSBhbmQgbm90IG5lY2Vzc2FyaWx5IHRp ZWQgdG8gdGhlDQo+Pj4+PiBhZ2VudC1pZD8NCj4+Pj4+DQo+Pj4+PiBJIHRoaW5rIGVpdGhlciB3 YXkgdGhpcyBkZXRhaWwgc2hvdWxkIGJlIGNsYXJpZmllZCBpbiB0aGUgZG9jcy4gU3BlYWtpbmcN Cj4+Pj4+IG9mIGRvY3MsIHRoZSBuZXh0IHBhdGNoIGludHJvZHVjaW5nIHRoZSBkb2MgaXMgbm90 IHVwLXRvLWRhdGUgd2l0aCB0aGlzDQo+Pj4+PiBwYXRjaC4NCj4+Pj4+DQo+Pj4+IEluIG15IGN1 cnJlbnQgY29uZmlndXJhdGlvbiwgSSBoYXZlIHRoZSBmb2xsb3dpbmcgc2V0dXA6DQo+Pj4+DQo+ Pj4+IFRoZSBYZW4gcHJpdmlsZWdlZCBpbnRlcmZhY2Ugb3BlcmF0ZXMgdGhyb3VnaCBmdW5jX2lk IDB4ODIwMDAwMDMuDQo+Pj4+IGZ1bmNfaWQgMHg4MjAwMDAwMiBpcyB1c2VkIGZvciBEb21haW4t MCwgaW4gb3JkZXIgdG8ga2VlcCB0aGUgRGV2aWNlDQo+Pj4+IFRyZWUgKERUKSBjb25zaXN0ZW50 IGJldHdlZW4gWGVuIGFuZCBiYXJlLW1ldGFsIGNvbmZpZ3VyYXRpb25zLg0KPj4+PiBJIGFtIHVu c3VyZSBob3cgYmVzdCB0byBkb2N1bWVudCB0aGlzLCBzaW5jZSB0aGUgaW1wbGVtZW50YXRpb24g ZG9lcw0KPj4+PiBub3Qgc3RyaWN0bHkgcmVxdWlyZSB0aGlzIHNwZWNpZmljIGNvbmZpZ3VyYXRp b24gYW5kIGFsbG93cyBmbGV4aWJpbGl0eQ0KPj4+PiBmb3IgdGhlDQo+Pj4+IGVuZCB1c2VyLiBN eSBpbnRlbnRpb24gaXMgdG8gcHJvdmlkZSBhbiBleGFtcGxlIGNvbmZpZ3VyYXRpb24gaW4gdGhl IERUDQo+Pj4+IGV4YW1wbGVzIHRoYXQgaXMgbW9zdCBsaWtlbHkgdG8gYmUgdXNlZCBhcyBhIHJl ZmVyZW5jZSBmb3IgcmVhbC13b3JsZA0KPj4+PiBzZXR1cHMuDQo+Pj4gWWVzLCBJIGFtIGFsaWdu ZWQgd2l0aCB0aGF0DQo+Pj4NCj4+Pg0KPj4+PiBBdCB0aGlzIHN0YWdlLCBJIGJlbGlldmUgdGhl IG1vc3QgYXBwcm9wcmlhdGUgYXBwcm9hY2ggaXMgdG8gaW5jbHVkZSBhIG5vdGUNCj4+Pj4gaW4g dGhlIGRvY3VtZW50YXRpb24gc3RhdGluZyB0aGF0IHRoZSBleGFtcGxlcyBpbGx1c3RyYXRlIGEg Y29uZmlndXJhdGlvbg0KPj4+PiB0aGF0IGFsaWducyB3ZWxsIHdpdGggdGhlIFhlbiBhcmNoaXRl Y3R1cmUsIGJ1dCBvdGhlciBjb25maWd1cmF0aW9ucyBhcmUNCj4+Pj4gcG9zc2libGUgZGVwZW5k aW5nIG9uIHVzZXIgcmVxdWlyZW1lbnRzLg0KPj4+IFllcy4gVGhlIGltcG9ydGFudCBkZXRhaWwg aXMgdG8gZXhwbGFpbiB0aGF0IHRoZSBzYW1lIGNvbmZpZ3VyYXRpb24NCj4+PiB3b3JrcyBmb3Ig Ym90aCBMaW51eCBiYXJlbWV0YWwgYW5kIExpbnV4IERvbTAuIEluIHRoZSBMaW51eCBEb20wIGNh c2UsDQo+Pj4gdGhlIHByaXZpbGVnZWQgU0NNSSBjb25uZWN0aW9uIGRpZmZlcnMgZnJvbSB0aGUg b25lIG9mIExpbnV4IERvbTAgYW5kIGl0DQo+Pj4gaXMgdGhlIG9uZSB1c2VkIGJ5IFhlbi4NCj4+ Pg0KPj4+IEJhcmVtZXRhbCBMaW51eDogZnVuY19pZCAweDgyMDAwMDAyLCBzY21pLXNobWVtIDB4 NDdmZjAwMDANCj4+PiBEb20wIExpbnV4OiBmdW5jX2lkIDB4ODIwMDAwMDIsIHNjbWktc2htZW0g MHg0N2ZmMDAwMA0KPj4+IFhlbjogZnVuY19pZCAweDgyMDAwMDAzLCBzY21pLXNobWVtIDB4NDdm ZjEwMDANCj4+Pg0KPj4+IFRoaXMgd29ya3MgYmVjYXVzZSwgSSBhbSBndWVzc2luZywgdGhlIHBy aXZpbGVnZWQgU0NNSSBjb25uZWN0aW9uIGlzIG5vdA0KPj4+IHRpZWQgdG8gZnVuY19pZCAweDgy MDAwMDAyLCBzY21pLXNobWVtIDB4NDdmZjAwMDAuDQo+Pj4NCj4+PiBUaGUgcHJvYmxlbSBvY2N1 cnMgd2hlbiB0aGVyZSBjYW4gYmUgb25seSBvbmUgcHJpdmlsZWdlZCBTQ01JIGNvbm5lY3Rpb24N Cj4+PiBhbmQgaXQgaXMgdGllZCB0byBmdW5jX2lkIDB4ODIwMDAwMDIsIHNjbWktc2htZW0gMHg0 N2ZmMDAwMCB3aGljaCBpcyB0aGUNCj4+PiBvbmUgZGVzY3JpYmVkIGluIHRoZSBIb3N0IERULiBJ biB3aGljaCBjYXNlLCBMaW51eCBEb20wIGVuZHMgdXAgd2l0aCB0aGUNCj4+PiBwcml2aWxlZ2Vk IGNvbm5lY3Rpb24sIG5vdCBYZW4uDQo+Pj4NCj4+PiBJIHRoaW5rIHdlIHNob3VsZCBleHBsYWlu IHdoeSB0aGlzIHByb2JsZW0gZG9lcyBub3Qgb2NjdXIuDQo+Pj4NCj4+Pg0KPj4+Pj4+ICAgICAg ICAgICAgI2FkZHJlc3MtY2VsbHMgPSA8IDE+Ow0KPj4+Pj4+ICAgICAgICAgICAgI3NpemUtY2Vs bHMgPSA8IDA+Ow0KPj4+Pj4+ICAgICAgICAgICAgc2htZW0gPSA8JnNjbWlfc2htPjsgPC0tLSBI b3N0IE9TUE0gYWdlbnQgc2htZW0NCj4+Pj4+Pg0KPj4+Pj4+ICAgICAgICAgICAgcHJvdG9jb2xA WHsNCj4+Pj4+PiAgICAgICAgICAgIH07DQo+Pj4+Pj4gICAgICAgICAgfTsNCj4+Pj4+PiAgICAg ICB9Ow0KPj4+Pj4+IH07DQo+Pj4+Pj4NCj4+Pj4+PiBUaGlzIGFwcHJvYWNoIGFsbG93cyBkZWZp bmluZyBtdWx0aXBsZSBTQ01JIEFnZW50cyBieSBhZGRpbmcNCj4+Pj4+PiBYZW4tc3BlY2lmaWMg cHJvcGVydGllcyB1bmRlciB0aGUgYGAvY2hvc2VuYGAgbm9kZSB0byB0aGUgSG9zdCBEZXZpY2UN Cj4+Pj4+PiBUcmVlLCBsZWF2aW5nIHRoZSBtYWluIHBhcnQgdW5jaGFuZ2VkLiBUaGUgSG9zdCBE VCBTQ01JIGNoYW5uZWwgd2lsbA0KPj4+Pj4+IGJlIHBhc3NlZCB0byBEb20wLg0KPj4+Pj4+DQo+ Pj4+Pj4gVGhlIFhlbiBtYW5hZ2VtZW50IGFnZW50IGlzIGRlc2NyaWJlZCBhcyBhIGBgc2NtaV94 ZW5gYCBub2RlIHVuZGVyIHRoZQ0KPj4+Pj4+IGBgeGVuLHNjaWBgIGNvbWFwdGlibGUgbm9kZSwg d2hpY2ggaXMgdXNlZCBieSBYZW4gdG8gY29udHJvbCBvdGhlcg0KPj4+Pj4+IFNDTUkgQWdlbnRz IGluIHRoZSBzeXN0ZW0uDQo+Pj4+Pj4NCj4+Pj4+PiBBbGwgc2Vjb25kYXJ5IGFnZW50cycgY29u ZmlndXJhdGlvbnMgYXJlIHByb3ZpZGVkIGluIHRoZQ0KPj4+Pj4+IGBgc2NtaS1zZWNvbmRhcnkt YWdlbnRzYGAgcHJvcGVydHkgd2l0aCBhbiBvcHRpb25hbCBgYGFnZW50X2lkYGAgZmllbGQuDQo+ Pj4+Pj4NCj4+Pj4+PiBUaGUgYGBhZ2VudF9pZGBgIGZyb20gdGhlIGBgc2NtaS1zZWNvbmRhcnkt YWdlbnRzYGAgcHJvcGVydHkgaXMgdXNlZA0KPj4+Pj4+IHRvIGlkZW50aWZ5IHRoZSBhZ2VudCBp biB0aGUgc3lzdGVtIGFuZCBjYW4gYmUgb21pdHRlZCBieSBzZXR0aW5nDQo+Pj4+Pj4gYGAjc2Nt aS1zZWNvbmRhcnktYWdlbnRzLWNlbGxzID0gPDI+YGAsIHNvIHRoZSBTZWNvbmRhcnkgQWdlbnRz DQo+Pj4+Pj4gY29uZmlndXJhdGlvbiB3aWxsIGxvb2sgbGlrZSB0aGlzOg0KPj4+Pj4+DQo+Pj4+ Pj4gLyB7DQo+Pj4+Pj4gICAgICBjaG9zZW4gew0KPj4+Pj4+ICAgICAgICB4ZW4gew0KPj4+Pj4+ ICAgICAgICAgIHhlbl9zY21pX2NvbmZpZyB7DQo+Pj4+Pj4gICAgICAgICAgICBjb21wYXRpYmxl ID0gInhlbixzY2kiOw0KPj4+Pj4+ICAgICAgICAgICAgI2FkZHJlc3MtY2VsbHMgPSA8Mj47DQo+ Pj4+Pj4gICAgICAgICAgICAjc2l6ZS1jZWxscyA9IDwyPjsNCj4+Pj4+PiAgICAgICAgICAgIHJh bmdlczsNCj4+Pj4+Pg0KPj4+Pj4+ICAgICAgICAgICAgLyogU2hhcmVkIG1lbW9yeSBub2RlcyBh cyBkZWZpbmVkIGVhcmxpZXIgKi8NCj4+Pj4+Pg0KPj4+Pj4+ICAgICAgICAgICAgc2NtaS1zZWNv bmRhcnktYWdlbnRzID0gPA0KPj4+Pj4+ICAgICAgICAgICAgICAweDgyMDAwMDAzICZzY21pX3No bV8wDQo+Pj4+Pj4gICAgICAgICAgICAgIDB4ODIwMDAwMDQgJnNjbWlfc2htXzINCj4+Pj4+PiAg ICAgICAgICAgICAgMHg4MjAwMDAwNSAmc2NtaV9zaG1fMw0KPj4+Pj4+ICAgICAgICAgICAgICAw eDgyMDAwMDA2ICZzY21pX3NobV80PjsNCj4+Pj4+PiAgICAgICAgICAgICNzY21pLXNlY29uZGFy eS1hZ2VudHMtY2VsbHMgPSA8Mj47DQo+Pj4+Pj4gICAgICAgICAgfTsNCj4+Pj4+PiAgICAgICAg fTsNCj4+Pj4+PiAgICAgIH07DQo+Pj4+Pj4gfQ0KPj4+Pj4+DQo+Pj4+Pj4gSW4gdGhpcyBjYXNl LCBYZW4gd2lsbCB1c2UgdGhlIGBgU0NNSV9CQVNFX0RJU0NPVkVSX0FHRU5UYGAgY2FsbCB0bw0K Pj4+Pj4+IGRpc2NvdmVyIHRoZSBgYGFnZW50X2lkYGAgZm9yIGVhY2ggc2Vjb25kYXJ5IGFnZW50 LiBQcm92aWRpbmcgdGhlDQo+Pj4+Pj4gYGBhZ2VudF9pZGBgIGluIHRoZSBgYHNjbWktc2Vjb25k YXJ5LWFnZW50c2BgIHByb3BlcnR5IGFsbG93cyBza2lwcGluZw0KPj4+Pj4+IHRoZSBkaXNjb3Zl cnkgY2FsbCwgd2hpY2ggaXMgdXNlZnVsIHdoZW4gdGhlIHNlY29uZGFyeSBhZ2VudCdzIHNoYXJl ZA0KPj4+Pj4+IG1lbW9yeSBpcyBub3QgYWNjZXNzaWJsZSBieSBYZW4gb3Igd2hlbiBib290IHRp bWUgaXMgaW1wb3J0YW50IGJlY2F1c2UNCj4+Pj4+PiBpdCBhbGxvd3Mgc2tpcHBpbmcgdGhlIGFn ZW50IGRpc2NvdmVyeSBwcm9jZWR1cmUuDQo+Pj4+Pj4NCj4+Pj4+PiAgICAgIE5vdGUgdGhhdCBY ZW4gaXMgdGhlIG9ubHkgb25lIGVudHJ5IGluIHRoZSBzeXN0ZW0gd2hpY2ggbmVlZCB0byBrbm93 DQo+Pj4+Pj4gICAgICBhYm91dCBTQ01JIG11bHRpLWFnZW50IHN1cHBvcnQuDQo+Pj4+Pj4NCj4+ Pj4+PiAtIEl0IGltcGxlbWVudHMgdGhlIFNDSSBzdWJzeXN0ZW0gaW50ZXJmYWNlIHJlcXVpcmVk IGZvciBjb25maWd1cmluZyBhbmQNCj4+Pj4+PiBlbmFibGluZyBTQ01JIGZ1bmN0aW9uYWxpdHkg Zm9yIERvbTAvaHdkb20gYW5kIEd1ZXN0IGRvbWFpbnMuIFRvIGVuYWJsZQ0KPj4+Pj4+IFNDTUkg ZnVuY3Rpb25hbGl0eSBmb3IgZG9tYWluIGl0IGhhcyB0byBiZSBjb25maWd1cmVkIHdpdGggdW5p cXVlIHN1cHBvcnRlZA0KPj4+Pj4+IFNDTUkgQWdlbnRfaWQgYW5kIHVzZSBjb3JyZXNwb25kaW5n IFNDTUkgU01DIHNoYXJlZCBtZW1vcnkgdHJhbnNwb3J0DQo+Pj4+Pj4gW3NtYy1pZCwgc2htZW1d IGRlZmluZWQgZm9yIHRoaXMgU0NNSSBBZ2VudF9pZC4NCj4+Pj4+PiAtIE9uY2UgWGVuIGRvbWFp biBpcyBjb25maWd1cmVkIGl0IGNhbiBjb21tdW5pY2F0ZSB3aXRoIEVMMyBTQ01JIEZXOg0KPj4+ Pj4+ICAgICAgLS0gemVyby1jb3B5LCB0aGUgZ3Vlc3QgZG9tYWluIHB1dHMgU0NNSSBtZXNzYWdl IGluIHNobWVtOw0KPj4+Pj4+ICAgICAgLS0gdGhlIGd1ZXN0IHRyaWdnZXJzIFNNQyBleGNlcHRp b24gd2l0aCBzbWMtaWQgKGRvb3JiZWxsKTsNCj4+Pj4+PiAgICAgIC0tIHRoZSBYZW4gZHJpdmVy IGNhdGNoZXMgZXhjZXB0aW9uLCBkbyBjaGVja3MgYW5kIHN5bmNocm9ub3VzbHkgZm9yd2FyZHMN Cj4+Pj4+PiAgICAgIGl0IHRvIEVMMyBGVy4NCj4+Pj4+PiAtIHRoZSBYZW4gZHJpdmVyIHNlbmRz IEJBU0VfUkVTRVRfQUdFTlRfQ09ORklHVVJBVElPTiBtZXNzYWdlIHRvIFhlbg0KPj4+Pj4+ICAg ICAgbWFuYWdlbWVudCBhZ2VudCBjaGFubmVsIG9uIGRvbWFpbiBkZXN0cm95IGV2ZW50LiBUaGlz IGFsbG93cyB0byByZXNldA0KPj4+Pj4+ICAgICAgcmVzb3VyY2VzIHVzZWQgYnkgZG9tYWluIGFu ZCBzbyBpbXBsZW1lbnQgdXNlLWNhc2UgbGlrZSBkb21haW4gcmVib290Lg0KPj4+Pj4+DQo+Pj4+ Pj4gRG9tMCBFbmFibGUgU0NNSSBTTUM6DQo+Pj4+Pj4gICAgIC0gcGFzcyBkb20wX3NjbWlfYWdl bnRfaWQ9PGFnZW50X2lkPiBpbiBYZW4gY29tbWFuZCBsaW5lLiBpZiBub3QgcHJvdmlkZWQNCj4+ Pj4+PiAgICAgICBTQ01JIHdpbGwgYmUgZGlzYWJsZWQgZm9yIERvbTAgYW5kIGFsbCBTQ01JIG5v ZGVzIHJlbW92ZWQgZnJvbSBEb20wIERULg0KPj4+Pj4+ICAgICAgIFRoZSBkcml2ZXIgdXBkYXRl cyBEb20wIERUIFNDTUkgbm9kZSAiYXJtLHNtYy1pZCIgdmFsdWUgYW5kIGZpeCB1cCBzaG1lbQ0K Pj4+Pj4+ICAgICAgIG5vZGUgYWNjb3JkaW5nIHRvIGFzc2lnbmVkIGFnZW50X2lkLg0KPj4+Pj4g R2l2ZW4gdGhhdCBldmVyeXRoaW5nIGVsc2UsIHRoZSBlbnRpcmUgY29uZmlndXJhdGlvbiwgaXMg YmFzZWQgb24gZGV2aWNlDQo+Pj4+PiB0cmVlLCBJIHRoaW5rIGl0IG1ha2VzIHNlbnNlIHRvIGFs c28gY29uZmlndXJlIHRoaXMgdmlhIGRldmljZSB0cmVlDQo+Pj4+PiBpbnN0ZWFkIG9mIGEgY29t bWFuZCBsaW5lLg0KPj4+Pj4NCj4+Pj4+IFRoaXMgY291bGQgYmUgYW5vdGhlciBwYXJhbWV0ZXIg dW5kZXIgeGVuX3NjbWlfY29uZmlnLiBXaGF0IGRvIHlvdQ0KPj4+Pj4gdGhpbms/DQo+Pj4+Pg0K Pj4+PiBUaGUgYGBkb20wX3NjbWlfYWdlbnRfaWRgYCBwYXJhbWV0ZXIgd2FzIGludHJvZHVjZWQg dG8ga2VlcCB0aGUgRG9tMA0KPj4+PiBjb25maWd1cmF0aW9uIHNlcGFyYXRlIGZyb20gdGhlIHhl bl9zY21pX2NvbmZpZyBub2RlLCB3aGljaCBpcyBpbnRlbmRlZA0KPj4+PiBzcGVjaWZpY2FsbHkg Zm9yIFhlbiBTQ01JIGNvbmZpZ3VyYXRpb24uIEluIG15IG9waW5pb24sIGFkZGluZyBEb20wLXNw ZWNpZmljDQo+Pj4+IGNvbmZpZ3VyYXRpb24gdG8geGVuX3NjbWlfY29uZmlnIHdvdWxkIG1peCB0 aGUgcHVycG9zZXMgb2YgdGhlIG5vZGUgYW5kDQo+Pj4+IHJlZHVjZSBjbGFyaXR5Lg0KPj4+Pg0K Pj4+PiBBZGRpdGlvbmFsbHksIHRoZSBgYGRvbTBfc2NtaV9hZ2VudF9pZGBgIHBhcmFtZXRlciBp cyBzaW1pbGFyIHRvIHRoZQ0KPj4+PiBgYGFnZW50X2lkYGAgcGFyYW1ldGVyIHVzZWQgZm9yIGFy bV9zY2kgaW4geGwuY2ZnLiBUaGlzIGFwcHJvYWNoIGVuc3VyZXMNCj4+Pj4gdGhhdA0KPj4+PiB0 aGUgRG9tMCBjb25maWd1cmF0aW9uIGlzIGFzIGNvbnNpc3RlbnQgYXMgcG9zc2libGUgd2l0aCB0 aGUNCj4+Pj4gY29uZmlndXJhdGlvbiBmb3INCj4+Pj4gb3RoZXIgZG9tYWlucy4NCj4+Pj4NCj4+ Pj4gT3ZlcmFsbCwgSSBiZWxpZXZlIHRoaXMgbWFrZXMgdGhlIGNvbmZpZ3VyYXRpb24gbGVzcyBj b25mdXNpbmcsIGFzIGl0IGFsbG93cw0KPj4+PiB1cyB0byBzZXQgc2ltaWxhciBwYXJhbWV0ZXJz IGZvciBib3RoIERvbTAgYW5kIG90aGVyIGRvbWFpbnMgaW4gYSBjbGVhcg0KPj4+PiBhbmQgb3Jn YW5pemVkIG1hbm5lci4NCj4+PiBXZSBhcmUgaGVhZGluZyBpbiBhIGRpcmVjdGlvbiB3aGVyZSBE b20wIGhhcyBpdHMgb3duIHNlcGFyYXRlIGRvbWFpbg0KPj4+IG5vZGUgc2ltaWxhcmx5IHRvIG90 aGVyIERvbTBsZXNzIGRvbWFpbnMuIE1hbnkgb2YgdGhlc2UgY2hhbmdlcyBoYXZlDQo+Pj4gYWxy ZWFkeSBiZWVuIGNvbW1pdHRlZCBhcyBwYXJ0IG9mIEhhcmR3YXJlIERvbWFpbiAvIENvbnRyb2wg RG9tYWluDQo+Pj4gc2VwYXJhdGlvbiB3b3JrIGJ5IEphc29uLg0KPj4+DQo+Pj4gSW4gYSB3b3Js ZCB3aGVyZSBEb20wLCBsaWtlIG90aGVyIERvbVVzLCBoYXMgaXRzIG93biBjb25maWd1cmF0aW9u IG5vZGUNCj4+PiBhbmQgYWxzbyBEb20wIGNhbiBiZSBzcGxpdCBiZXR3ZWVuIEhhcmR3YXJlIERv bWFpbiBhbmQgQ29udHJvbCBEb21haW4sDQo+Pj4gaXQgZG9lc24ndCBtYWtlIHNlbnNlIHRvIHVz ZSBEb20wIGNvbW1hbmQgbGluZSBvcHRpb25zIGFueW1vcmUuIEl0IGlzDQo+Pj4gYWxyZWFkeSBw b3NzaWJsZSB0byBhc3NpZ24gRG9tMCAicG93ZXJzIiB0byBhIGRvbTBsZXNzIGRvbWFpbiBmb3IN Cj4+PiBleGFtcGxlLg0KPj4+DQo+Pj4gSSBjYW4gc2VlIGl0IGlzIHdvcnRoIGRpc2N1c3Npbmcg Y29tbWFuZCBsaW5lIG9wdGlvbnMgZm9yIGRvbTAgaW4NCj4+PiBzaXR1YXRpb25zIHdoZXJlIERl dmljZSBUcmVlIG1pZ2h0IG5vdCBiZSBwcmVzZW50IChkYXRhY2VudGVyDQo+Pj4gY29uZmlndXJh dGlvbiBvbiBBQ1BJIHN5c3RlbSkgYnV0IGluIHRoaXMgY2FzZSB3aGVyZSBEZXZpY2UgVHJlZSBj aGFuZ2VzDQo+Pj4gYXJlIHJlcXVpcmVkLCBJIHRoaW5rIGl0IGRvZXNuJ3QgbWFrZSBzZW5zZSB0 byBhZGQgRG9tMCBjb21tYW5kIGxpbmUNCj4+PiBvcHRpb25zIGFzIHRoZXkgYXJlIGxlc3MgZmxl eGlibGUgYW5kIGEgZHVwbGljYXRlIG9mIG90aGVyIG9wdGlvbnMgd2UNCj4+PiBtdXN0IGhhdmUg YW55d2F5Lg0KPj4gVGhhdCBtYWtlcyBzZW5zZSB0byBtZS4gU2luY2Ugd2UgYXJlIG1vdmluZyB0 byB0aGUgRG9tMCBEZXZpY2UgVHJlZQ0KPj4gY29uZmlndXJhdGlvbiwNCj4+IEkgY2FuIG1vdmUg YGBkb20wX3NjbWlfYWdlbnRfaWRgYCBpbnNpZGUgdGhlIGBgeGVuLHNjaWBgIG5vZGUgYW5kIHJl bmFtZQ0KPj4gaXQgYXMgdGhlDQo+PiBgYGFnZW50X2lkYGAgcHJvcGVydHkuDQo+Pg0KPj4gV291 bGQgeW91IHJlY29tbWVuZCBkcm9wcGluZyB0aGUgYGBkb20wX3NjbWlfYWdlbnRfaWRgYCBjb21t YW5kIGxpbmUNCj4+IHBhcmFtZXRlcg0KPj4gZW50aXJlbHksIG9yIHNob3VsZCBJIGtlZXAgaXQg YXMgYSBiYWNrdXAgb3B0aW9uPw0KPiBJIHdvdWxkIGRyb3AgdGhlIGNvbW1hbmQgbGluZSBwYXJh bWV0ZXIgZW50aXJlbHkNCkkgd291bGQgbGlrZSB0byBhZGQgb25lIG1vcmUgb2JzZXJ2YXRpb24g ZnJvbSBteQ0KaW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZToNCg0KVGhlIG1haW4gZGlmZmVyZW5j ZSBiZXR3ZWVuIERvbTAgYW5kIGRvbTBsZXNzIGNvbmZpZ3VyYXRpb25zIGlzIHRoYXQsDQpmb3Ig ZG9tMGxlc3MsIHdlIGhhdmUgYSBzZXBhcmF0ZSBub2RlIGZvciBlYWNoIGRvbWFpbiwgZm9yIGV4 YW1wbGU6DQoNCkRvbTBsZXNzIGNvbmZpZ3VyYXRpb246DQoNCiDCoCB4ZW4sZG9tYWluQDEgew0K IMKgwqDCoMKgwqAgY29tcGF0aWJsZSA9ICJ4ZW4sZG9tYWluIjsNCiDCoMKgwqDCoMKgIHhlbixz Y2lfdHlwZSA9ICJzY21pX3NtY19tdWx0aWFnZW50IjsNCiDCoMKgwqDCoMKgIHhlbixzY2ktYWdl bnQtaWQgPSA8Mj47DQogwqDCoMKgwqDCoCAvKiBvdGhlciBkb21haW4gcHJvcGVydGllcyBoZXJl ICovDQogwqDCoMKgIH07DQoNCkhvd2V2ZXIsIGZvciBEb20wLCB3ZSBvbmx5IGhhdmUgdGhlIGZv bGxvd2luZyBub2RlOg0KDQogwqAgY2hvc2VuIHsNCiDCoMKgwqAgeGVuIHsNCiDCoMKgwqDCoMKg IHJhbmdlczsNCiDCoMKgwqDCoMKgIHhlbl9zY21pX2NvbmZpZyB7DQogwqDCoMKgwqDCoMKgwqAg Y29tcGF0aWJsZSA9ICJ4ZW4sc2NpIjsNCiDCoMKgwqDCoMKgwqDCoCAuLi4uDQogwqDCoMKgwqDC oCB9Ow0KIMKgwqAgfTsNCn07DQoNCndoaWNoIGRlc2NyaWJlcyB0aGUgU0NJIGNvbmZpZ3VyYXRp b24gZm9yIFhlbi4NCg0KVGhlcmVmb3JlLCBJIGJlbGlldmUgdGhhdCB1c2luZyB0aGUgcHJvcGVy dHkgbmFtZQ0KYGBhZ2VudF9pZGBgYCBjb3VsZCBiZSBjb25mdXNpbmcgaW4gdGhpcyBjb250ZXh0 Lg0KSSBzdWdnZXN0IG5hbWluZyBpdCB4ZW4sZG9tMC1zY2ktYWdlbnQtaWQgaW5zdGVhZC4NCg0K VGhlIGRldmljZSB0cmVlIHdvdWxkIHRoZW4gbG9vayBsaWtlIHRoaXM6DQogwqAgY2hvc2VuIHsN CiDCoMKgwqAgeGVuIHsNCiDCoMKgwqDCoMKgIHJhbmdlczsNCiDCoMKgwqDCoMKgIHhlbl9zY21p X2NvbmZpZyB7DQogwqDCoMKgwqDCoMKgwqAgY29tcGF0aWJsZSA9ICJ4ZW4sc2NpIjsNCiDCoMKg wqDCoMKgwqDCoCAuLi4uDQogwqDCoMKgIMKgwqDCoCB4ZW4sZG9tMC1zY2ktYWdlbnQtaWQgPSA8 MD47wqAgLyogRG9tMCBhZ2VudCBJRCAqLyA8LS0tLS0NCiDCoMKgwqDCoMKgIH07DQogwqDCoCB9 Ow0KfTsNCg0KRG9lcyB0aGlzIGFwcHJvYWNoIGxvb2sgZ29vZCB0byB5b3U/DQoNCk9sZWtzaWku From xen-devel-bounces@lists.xenproject.org Tue Jan 20 16:07:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 16:07:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209210.1521304 (Exim 4.92) (envelope-from ) id 1viEFv-0008Dx-18; Tue, 20 Jan 2026 16:06:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209210.1521304; Tue, 20 Jan 2026 16:06: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 1viEFu-0008Dq-Uq; Tue, 20 Jan 2026 16:06:58 +0000 Received: by outflank-mailman (input) for mailman id 1209210; Tue, 20 Jan 2026 16: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 1viEFt-0008Dk-R2 for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 16:06:57 +0000 Received: from mail14.wdc04.mandrillapp.com (mail14.wdc04.mandrillapp.com [205.201.139.14]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0a7b181d-f61a-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 17:06:56 +0100 (CET) Received: from pmta16.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail14.wdc04.mandrillapp.com (Mailchimp) with ESMTP id 4dwXJZ4gL6z8XTp13 for ; Tue, 20 Jan 2026 16:06:54 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id fea1a1dc604b4b15bf4e24531857cda3; Tue, 20 Jan 2026 16:06:54 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0a7b181d-f61a-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1768925214; x=1769195214; bh=Lcb43l5hrinde7Pn53T0xofB3DStwPFHexX0oDp/UEg=; 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=ZNw+9e0T0sofKw2UIi6eta+w0uRgC+uuMtcExneenqkYJKHLW+K2KgHxsSVVdJC3Z nSe62xUYdEpan8ObqID6TUPplufGby+YSiD9tKNjAvEIh7E61xsaMeJeqptgcsafmS +w5Rvst9AUAcm34TJALyik58BmsCa+Rs+Bwjq2sZFYN4jKLZ7tHx27GSw4mAOgUpJL 1hokSpGFDEuXCA/bPs5DdR+qQQoOhN48iEbaSt9sADTri4eV9FGtd4z7Ui7f8AtlR2 88cQxB314uNZtwCYAKqv8lLJaKyRHBokit2QIkKeZJeQl/17LY9M3xBof+Xp4h/QAk /VqdHxsqrsa9w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1768925214; x=1769185714; i=ngoc-tu.dinh@vates.tech; bh=Lcb43l5hrinde7Pn53T0xofB3DStwPFHexX0oDp/UEg=; 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=J3dGOx+S/M1A02IC4YtdtJpkEOHnz29dCBT9L1r47fXfg09pwanSmk0isgLaArenI 8+lFT54FZuof4/ryCn9XWp8umfGgjNbYRj/Dq1cC/4MmTfAJG8pxAjp1y0KivZLNuy qAxItyK0Z9SBFAfxOjSW1SXh/t4AUJcifA34+0+egqYvp7krZLONnU8T8spRtEANFh /o+CTJoXB2KNCbLfsEUmFm0yIRqU2R+xPlDbEKFGRZLKPJtnvfn97FZS8OlDl3/vGO Mj2h2tuiLM3zR0tYuVUOTepeY+PNZ3tdg9S546kcJKTRqFlS1EBohymhZz0JZeAnxK iIUi+toOd0QPQ== From: "Tu Dinh" Subject: =?utf-8?Q?Re:=20[PATCH=20v2]=20xen:=20Expose=20time=5Foffset=20in=20struct=20arch=5Fshared=5Finfo?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1768925212872 Message-Id: To: "Jan Beulich" Cc: "Anthony PERARD" , "Andrew Cooper" , "Michal Orzel" , "Julien Grall" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" , "Bertrand Marquis" , "Volodymyr Babchuk" , xen-devel@lists.xenproject.org References: <20260120095657.237-1-ngoc-tu.dinh@vates.tech> <3213454a-38cd-4e5d-8a30-853e37f70c18@suse.com> <7a61a16c-93d7-4cc2-bc47-11e236cf83fb@suse.com> <9df8cf47-d3ec-474e-b1c8-7978e55627d6@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.fea1a1dc604b4b15bf4e24531857cda3?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260120:md Date: Tue, 20 Jan 2026 16:06:54 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 20/01/2026 16:39, Jan Beulich wrote: > On 20.01.2026 16:27, Tu Dinh wrote: >> On 20/01/2026 13:42, Jan Beulich wrote: >>> On 20.01.2026 13:12, Tu Dinh wrote: >>>> On 20/01/2026 11:35, Jan Beulich wrote: >>>>> On 20.01.2026 10:57, Tu Dinh wrote: >>>>>> time_offset is currently always added to wc_sec. This means that without >>>>>> the actual value of time_offset, guests have no way of knowing what's >>>>>> the actual host clock. Once the guest clock drifts beyond 1 second, >>>>>> updates to the guest RTC would themselves change time_offset and make it >>>>>> impossible to resync guest time to host time. >>>>> >>>>> Despite my earlier comments this part of the description looks unchanged. >>>>> I still don't see why host time (or in fact about any host property) should >>>>> be exposed to guests. >>>> >>>> I've answered this question in a followup reply from November, which >>>> I'll reproduce here: >>> >>> I did read your reply, yet nothing of it appeared here as additional >>> justification. >> >> Is the new description OK for you? > > Which new description? So far I only saw your responses to my questions, not > an updated patch description. > Maybe my last email wasn't clear, it was in the part marked "Follow up", reproduced below: Xen currently does not expose the host's wall clock time in shared_info. This means while shared_info can be used as an alternative to the emulated RTC, it can't be used to keep the virtual wall clock in sync. Expose the time_offset value in struct shared_info in order to allow guests to synchronize their own wall clock to that of the host. This is needed because on Windows guests, the PV drivers don't control the timing of RTC updates, as this is done by the kernel itself periodically. If the guest's internal clock deviates from the RTC (e.g. after resuming from suspend), a RTC write would cause time_offset to deviate from the supposed value (timezone offset) and thus cause the RTC to become incorrect. Provide a new feature bit XENFEAT_shared_info_time_offset for this functionality. >>> Plus I fear I don't view any of this a basis to suggest >>> to expose some host property to guests. >> >> The only host property being exposed would be the UTC wallclock as kept >> track by the host (as is specified by XENPF_settime). This information >> (wallclock from an external reference) is necessary for guest timesync, >> whereas an RTC which guests can update by themselves simply cannot be >> used for this purpose. > > What the guest can do to its (virtual) RTC is no different from what an OS > running bare metal can do to the real RTC. Running on bare metal, you also > don't have any other reference (without using e.g. NTP). > Since shared_info is a paravirtualized interface that's not meant to replicate real hardware, I don't think it needs to be bound to the functionalities of bare-metal RTC; for once, the host already provides guests with high-precision wallclock more than what the emulated RTC offer (via vcpu_time_info_t). Adding precision sync is also valuable for VMs using this interface. >>>>>> Since there's no way to add more fields to struct shared_info, the >>>>>> addition has to be done through struct arch_shared_info instead. Add two >>>>>> fields in arch_shared_info representing time_offset's low and high >>>>>> 32-bit halves. >>>>> >>>>> Again, despite my earlier question, reasoning of why two halves rather than >>>>> a (signed) 64-bit value isn't supplied here. >>>> >>>> This was also in my last email: >>>> >>>> Both are just for easy consumption of the time offset on 32-bit guests. >>> >>> I don't buy this. I should probably have replied to this effect when >>> you first wrote it. {,u}int64_t is hardly a hurdle anymore there. Nor >>> would I expect any halfway up-to-date 32-bit guest to manage time as >>> a 32-bit quantity anymore. >>> >>>> Unsigned is particularly because these are only parts of an int64_t (and >>>> therefore have no signedness themselves) and I prefer to let the >>>> conversion happen after reading the two fields. >>> >>> There may be benefits to this, yes, but imo they want to be spelled out, >>> rather than left vague. >>> >>>> (Follow up: Also, the alignment of int64_t differs between GCC and MSVC >>>> compilers. Using int64_t here would change the alignment of struct >>>> arch_shared_info) >>> >>> Does it? For which target and in which way? This would, after all, render >>> other uses of {,u}int64_t in the public headers problematic as well. >> >> For the x86 32-bit target, the Windows ABI uses 8-byte alignment for >> (u)int64_t as opposed to 4-byte for the System V ABI [1]. > > Oh, right, I should have recalled this. Iirc there was an unwritten assumption > that for Windows the public headers may need some massaging. > >> Most of the >> other uses of 64-bit integers look to be manually aligned and/or using >> (u)int64_aligned_t (I haven't looked at them all). I can switch >> time_offset to int64_aligned_t and avoid the issues above. > > Except that int64_aligned_t can be used in __XEN_TOOLS__ guarded areas only, > for not being possible to make available with plain C89 / C99. So here we're > working out a reason why the field may indeed better be split. Albeit as > said, other areas of the public headers use {,u}int64_t as well, so maybe > this still would only be a pretty weak reason (and you could make sure the > field is properly padded for the x86-32 case). > I see, I didn't realize that int64_aligned_t is for __XEN_TOOLS__ only. > and you could make sure the field is properly padded for the x86-32 case This would not be possible either, as using int64_t would increase the alignment of arch_shared_info to 8 on MSVC. Since wc_sec_hi is not defined on x86-32, shared_info->arch is on a 4-byte offset (modulo 8), and so its layout would be broken on this compiler if int64_t were to be used. > Jan -- Ngoc Tu Dinh | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Jan 20 17:32:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 17:32:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209236.1521327 (Exim 4.92) (envelope-from ) id 1viFa9-0002l1-Jf; Tue, 20 Jan 2026 17:31:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209236.1521327; Tue, 20 Jan 2026 17:31: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 1viFa9-0002ku-H3; Tue, 20 Jan 2026 17:31:57 +0000 Received: by outflank-mailman (input) for mailman id 1209236; Tue, 20 Jan 2026 17:31:57 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viFa8-0002Vt-RU for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 17:31:56 +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 e8d29e9e-f625-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 18:31:53 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MN2PR03MB5309.namprd03.prod.outlook.com (2603:10b6:208:1eb::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Tue, 20 Jan 2026 17:31:49 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Tue, 20 Jan 2026 17:31: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: e8d29e9e-f625-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=uc9bEBvbhKa+h93JzJ2A0T+dD/JdJNQ6Hg8hlQrjYRONWxoaWxKBWg/QpqXkmEnJ9gBBNUlEDYqEXWNWAmA6MnM5/UJfLYAai/IS1oLdaZOKa2m6oGUK4pz5DIqCKuIa1JBqWRPT0mHkvUPV+n4J4eQ/EXG6FvgQz2ZjEbM2u65f5wgg33Py13Wve7eaUpT2DTw3VNIla8y2oGG3b9EWlHOtWi1exgcNjml/vbOyYX0X3Nre9DDEwdiOsaPKcjmdEzzEPRa5HwY3Rk1325ptwLYRT+PZbxsRf/ek7HwaP3OvSvIxX+GL8ekagaot6tl0NMxgBK88wqg2fsY6t1NV8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Mx6myohIm13VyIszTbrMs5hKisSzjFDtROryRvQaC9o=; b=wTNgGp19Yevi7o1GUiwGGsAI4+Ugpp0M4HZDFFm9dfmKhnE3eQC1kssUhceilPH3lzNmP9tKMOKpCXrkFEZhz68nmfVBKk4y6kNnc1GU+94ALB+7ElkeSDW+UrU+ic7eQqinARtTVGkwYc7nhCJOJG1VTQ63WjJ9FCZJfkDxWiF3HJ/+B4tnZkFjKXAUCOUQm+t86gQrpyxzL2m/IYS18RqTad2vJW6rdHoCYfVcs84/aWIwbTXGM4sDoEQZkph22XUzU33JKQl7N6IJRsmc7ogls0y78iJ9iPFsvAecG1+wYHHbRutTAp54Z9Uxv2+8qiKUx7XtMELIQCByC8XqfA== 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=Mx6myohIm13VyIszTbrMs5hKisSzjFDtROryRvQaC9o=; b=C7CMV3y7gSoyooSCmLXKrFSlsd6O6/nQ1KVLjWXBGeP4pVSbhYmnUkNkpHe7RXmYBkL/u+aWgTGKtNxUJVVbmDLWO1FQrcEz9utpTnBGFjr8V4ZRIOOxwnjAwvtGkqmBVlL8lF96Cv0z/KX4vfbCUjE194wfeshePTH1CNiAPs4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <9085b5dd-af68-42c3-bd8d-ddbecd8ad7db@citrix.com> Date: Tue, 20 Jan 2026 17:31:45 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Alejandro Vallejo , Jbeulich , xen-devel@lists.xenproject.org, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Xen-devel Subject: Re: [PATCH v4 4/5] docs/misra: Remove earlycpio.c from the Eclair exclusion list. To: Nicola Vetrini References: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> <20260120093852.2380-5-alejandro.garciavallejo@amd.com> <1d374226e3f91ab3bbc05c3354c8f8fe@bugseng.com> <0a6eca6eb344e9829ed9e0b381f26e95@bugseng.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0200.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a5::7) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MN2PR03MB5309:EE_ X-MS-Office365-Filtering-Correlation-Id: 65f06b1d-9602-4888-4b0b-08de5849caaa 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?RUpwYlVwT0M2a3U5TlMyOUtlVSsyMEVkc0tldkxqWmpOdXIxdUNadHlxWlRG?= =?utf-8?B?UmtHVFlORXoySTNSL2RFVXZWb3hQNXRjR0hyNDVkLzZkWFZIVXl4dE52Rmp3?= =?utf-8?B?aVhoOVVLeStlemp5YWJPN2h2L3NNZ2FGc2hQSHlMOHVwZk9Zd0JUU3R0RWtv?= =?utf-8?B?QlhtTmJJOFdtb1Zha0J0Q3ErMndQMGx1WDRYTElaY3NGYWNRdnJtd2dVN1Rr?= =?utf-8?B?QnY3N1krTnVmd3Z6UVZ1ak5PbTZ1YmhVTGhMc2NCZ1VDZmk4M2JCdVc5M1o0?= =?utf-8?B?dERYc1daTlpPVmtTQTUvYVQ4TWZZSSsvNWdaaWxwZUVKNFBmdFh3UjhSTk9x?= =?utf-8?B?ODlIdmFTeW5lMnQ4Rm5sZVpCcjZCYkdhellaQUdJRG9BVU1SWkJhUCs4cndt?= =?utf-8?B?K0VFdE1XeEszV1c4NlRZNkRESUUxQ0VuUUc2b0U3NmFSbHhpWkdaVUw1YVFk?= =?utf-8?B?UFFYZTRLNkxYcnBXRE5icjU1ditETnlReTF4VjcyY0Q4aGZLdkhkWUN1aWp5?= =?utf-8?B?N2pPWld4ZFBUUjhDQVlhZFlxYjR0R1REMTh6RFp1SURSeDd5YWN6d2tTb3Fa?= =?utf-8?B?UzcxQ2FJN0hzbVgwbFM4cUs1UHgvdjFjYW1mV1FtSEoxWHlJMG14UngrdWI2?= =?utf-8?B?V2FnTVF0YlE3Z1hOS3grZEJPeXJGNUttdEVVTzhlQjd0U0xwcDFOaE5rczZm?= =?utf-8?B?STRjOE9sdHdqdVZyTlFPbzJpUko0b3YwVVZ5YWg0RmNyRnl1empadWlTVnlF?= =?utf-8?B?M0k3QnZ1amhseWphM3NlMlI2MlppZmh3cmEwZ25JQ0ZKSjNXVG1nZk90UENp?= =?utf-8?B?aXhpbE1XZE9vUUFSQnFQTkdSazFYM0IwQkJwakdMbDkzdG9kdWtHbkJvc21v?= =?utf-8?B?Mk0vZTZIUFlzbmowU3RweHNxYmxoNHJQOElnMjJWWE9pVHV2YjQrcEVBNGYy?= =?utf-8?B?cEpVK2FXb0JjUmFzN0NKb3R0cFdiYXlJRGJWYlVZYXBhVGFQUVN6NzVGR3JG?= =?utf-8?B?NnZKT2s1MzRXNE9lbHhuWnZsWWpxcmJRUzJ3L2Q1cDJvN21rUmRzVnBuU2dY?= =?utf-8?B?SGh1ekh5ekxCMllFWllIUGp5MkthQklENlQ5eC9Jd0t2ekVMMTM0c1MwVFFa?= =?utf-8?B?ODJHTDEyMmF3Wmthc2hMbVovc2hwdmxUVUg5NXFFWWpVMnJvQUdxWjJEZ1Jk?= =?utf-8?B?UWZqL2YyWFY1clNLR3BqRWVWTGpmbkRjdFV2aWFWNlBaWFQ2aVhtWUlnK0tX?= =?utf-8?B?UzFFcVkwMExsZWhRbmJjYkVycytZN055SC9UVFNrTllhTmIxOFJLN1FZdG50?= =?utf-8?B?eUtFKzhOVWpHTmthREphNGowV2RndUJtUlUrbVdnWGlHRzlmVUREbFcvRnY1?= =?utf-8?B?N1RnYVN0eU9oNW9VTWNlWTFaNlZnUjczZUd5MC9EUy9ITGhlaFY1MVRaVlBW?= =?utf-8?B?Wnl0dCtiWGkvVTlhSHBFdUl5VVJibmNweG1Ea2ZUT0RMZXVEOERTN0ZNU3hQ?= =?utf-8?B?WE9sc1ZhZnI5MFc2SXhUV01YcnNhM3FBa1hiYStSclp2c0VjME5MeDFmMGJr?= =?utf-8?B?bGJBNXJCUkRMN09DRDBXMXZuVUlFSGpHa2RsK0xJcDBKZWZNdmc4NjVsWVlK?= =?utf-8?B?SUJVdStEdUhCYXlpREE1eU1GTkdRQUtyUmlZVmV6c2Njb3NWZXppTk8xNjFn?= =?utf-8?B?eUJBVEdoVU9RdU80R1IramdhdjVSK2RYTG5VRS93S1hJRnRJa3daVFhTdVdu?= =?utf-8?B?Z3FjWHM1UTB3RGhzV2dQNEtvSXRQMlpVc0h0Yy9iQnd2dzB1M3BNYWY0YkR3?= =?utf-8?B?N1V1NzByMFRXaFJjSmtBTDZxVG1KVW5zR0lSYXVVdVpyWngzaE13QllveXVr?= =?utf-8?B?cS9TQ25QNjZ4WS85Uzk5VWM4azVrOVFzbElVYU5iUU5sbFduTzRTUzRwbVB0?= =?utf-8?B?SnNjQlcyK2lCbEpvUnArZ1BYcVpHeGR5Z1hmRVFCd2RXREFPUjh1ck1UWHNR?= =?utf-8?B?U2VzWGhpaWRpMHNxQVd6Um5ySnVWT2x6ZmMyckVadm1zL0pDbzBpS1pZcXk1?= =?utf-8?Q?E606dg?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NUw4Q0laM2hOT1VvRHdRb3ZrY0Q0ODBBMDRGV1VER2xqUHpoc1JXNEhLZGhE?= =?utf-8?B?VTh1Qk10dVZjVm5POGJlRitUcnJ3eWo5dWlMdk9oRDRlUHVyZXoxejF0UEw4?= =?utf-8?B?bFF4Q0IxckZzemRTckQ0OXhtQWhCZWRlaitVWGRPcURXVC9RTEU5RVdqQmwz?= =?utf-8?B?VWVmeGZSSzV6Z0tEM2dJVm1vb3NBUHN5NWdmN3B2RGFpTmxpVVR5eHQ0ZjFL?= =?utf-8?B?WTNkQnd0MVcxb24vZGV0WExOZEFkQm1oVlJyTUlwQ1ZzNUR6ekRteVpzZmFG?= =?utf-8?B?S251Uk9XdXEvL3gvNEh3OGxzVjJBaURWbmsyT2QrY1Y1VlpCOE1UR1NObHgx?= =?utf-8?B?cFhJZjUvSWx6THJBY2ZrYTYzS0ZsNkVKbFcvSW9BZzNNYUduTE52elA1RDZY?= =?utf-8?B?NTRYY2p4SWJxS3FpaG1RdFl3c3lXMkRSWFBjbUUvYXNkcUNxdW1ISmJaMGYw?= =?utf-8?B?VjdYSDViQ0hDZ1o4MmdNdVVtZUVJWkx4Mk9vV0FtY1MrdUY3c0VpUUJ5eFUx?= =?utf-8?B?NnpuNnEvc1hLS0hYRndieXN6ZHhxU2lFWUpNNDZlNEMxbG1qR05XSDhsNERq?= =?utf-8?B?dnBnRjlEZEViYlB4cnVQWGluQXpTWUxLMjZkenp0Qlg1YXdKcXRNVlpFMEZH?= =?utf-8?B?WitUTkVDcE8ySklJakFPNlNPSGZsSVF4Mm1iY1hRblF2aG1mNnRUSWRIM1dM?= =?utf-8?B?ZmsxR1Fpanh0K3JGVzJOamlYbzBwMlkrOFcydGhvNlR1S0poelZqcm1pUXRB?= =?utf-8?B?TmpBazVCODI3VTdzNG9NYzUydjAvK3FFVU40NXV2VmZ6STdMRXFpdE1wV3dS?= =?utf-8?B?TGo3KzdDeFFYSnV4UWV3U1MwWWtpZHRBQk5jYi9xTERqVmhSdTFPaUlOMTQw?= =?utf-8?B?S0RFMldKTm4xb1ZxdWJZRGRCbkQ1VFZ3R1FacmJzMmxjTE95NFc1Y0l2RnlC?= =?utf-8?B?a1UvTWEwRmhPWDRGaGR3R0JJcUxvUmI5TXVlald5RzNkcy83MXkwaTIyT3VB?= =?utf-8?B?Q3VFaGtvcGZEVGlvQkhMc0hHOXltUXh4djFGeFFPdVhtcG5ScVprQmtRNU90?= =?utf-8?B?UUtPZitlNWhwUHNwcmdKdWMxR2hwY095MlJXR1RVaXNERVIwWW9FMkpDRjd2?= =?utf-8?B?VFVpclp0SHhrK3ZPMXBLSVl3eUE0TFhSV3U2M0p5Rm1YRytSQlE2RUxsb3Iv?= =?utf-8?B?TmxCQ2tqOXhMTU9UZE5YZUJkYTRCYkd2N25SWVBtOXFUaFQ4V0drWU5hcXR6?= =?utf-8?B?OVFpYnJkWnErdUxkOUdvVjBNamNQSTdoWHRDNWJsRVBKN3pxU3AwRFBWbHRC?= =?utf-8?B?ZmRuaHpBYXRGOWlVdUpXd2x0dHh5YlNoUTFMdWh3cStudVdiMWIzZTlQZ1FN?= =?utf-8?B?aFhOMU4yU3lPV0NCVUdFb0pjZloveWVwRWJZNnRXT2k1K3l4SG5qVnRUUVll?= =?utf-8?B?Y1FEbjNDZmdEempobkpId3JnS05FUHkzYVYrc0hFMEV1ejNmTDdsZHBSZEZ2?= =?utf-8?B?MTdlTXJxcUpxaDR4SURHY2pKSFc5MGQ1Y1IwY2g1dnMzREZZQUZ2S2FpVFZD?= =?utf-8?B?ZCttRStMamc1enVCaWdXNTF6SHB6U0x4R09sVFRHVjUvdTNUZEo3bmtmVXFx?= =?utf-8?B?dlU5dUdWbkc0aFZZelhHbnhPMTl4UWU0QndnOTYxYjdJZzhvQzlLMEk5Unp6?= =?utf-8?B?RHBZOEhaR1N4NEhDQ24rNWtmWVNQVVlLYnF2V0tpMjI4MFVjMzQrSVhWQ2Ft?= =?utf-8?B?cjFHcUpWU2FzTW1UcTR6Rzc0OXNocjBpdExxbkM1MnZrU1V0ekRqRFVhZ21W?= =?utf-8?B?cldxSkVhTlBIRjlrOTUzQVhKa2IvNXV6cWJuOHk0b1d2NjBVc3BrOFdSQlps?= =?utf-8?B?OFNWZEY1eFpkR3NRemVmOUUva0l3c0Z1c0RiN3ZOcGxxRlZrWHhwSmlQaEx1?= =?utf-8?B?NmFja2Y3ZmNjYXNTOTJTY0oxL05tMEo2cVEwSUZIKzl5QlBMcjl2TTNCaVp4?= =?utf-8?B?L2RFWVY1NUlLbzc0RDV5ZmNpK1hoSlBHRWRXeUFONnNaNU56WHRVMHdxc2RM?= =?utf-8?B?UDNRWk9naE42a213a0I2SG1qUzd3dXR4ZnVoYytkSDNqSjNvMmcxNTMwLzJN?= =?utf-8?B?Z0ZQdC9lRXRMN001WFNhWFZkTjZKZE1BKyt0NXI0WVhXbTR0cXpQOGQ3a0xj?= =?utf-8?B?WHhYUVozOGw1YkhBSi9ZVFU0WEUxbWlEbzM1THhzN3Q0eFZhbzdCd2p4c0hk?= =?utf-8?B?blFUNEdjR3FkQzdRTC9kN0xNQzY3TVZmdGtObkhJc3o3SENMalFYbU5YSFph?= =?utf-8?B?b1ZmaHZwVDJBUmFCNUZLZlAyOGY4d3ZjdDU1eDdIKy9vdThXbjZMN1lmVzQ2?= =?utf-8?Q?eGd59PHwOnAGRXh4=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 65f06b1d-9602-4888-4b0b-08de5849caaa X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 17:31:49.0100 (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: cGr2kRhNyfn+aP7cBwLwsTYqPFlOMoJZSmE3KI+9G5hi5MBVcA3hswmpmXYNkNMMOyWPjqPTF2qVTG3G596An/XQFOTs0S36reERPqQfWE0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR03MB5309 On 20/01/2026 3:25 pm, Nicola Vetrini wrote: > On 2026-01-20 16:14, Andrew Cooper wrote: >> On 20/01/2026 2:20 pm, Nicola Vetrini wrote: >>> On 2026-01-20 13:09, Alejandro Vallejo wrote: >>>> On Tue Jan 20, 2026 at 12:51 PM CET, Alejandro Vallejo wrote: >>>>> On Tue Jan 20, 2026 at 12:41 PM CET, Nicola Vetrini wrote: >>>>>> On 2026-01-20 12:27, Alejandro Vallejo wrote: >>>>>>> On Tue Jan 20, 2026 at 12:21 PM CET, Nicola Vetrini wrote: >>>>>>>> On 2026-01-20 10:38, Alejandro Vallejo wrote: >>>>>>>>> It's clean. >>>>>>>>> >>>>>>>>> Signed-off-by: Alejandro Vallejo >>>>>>>>> >>>>>>>>> --- >>>>>>>>>  docs/misra/exclude-list.json | 4 ---- >>>>>>>>>  1 file changed, 4 deletions(-) >>>>>>>>> >>>>>>>> >>>>>>>> Hi. Do you have a link to a pipeline? >>>>>>> >>>>>>> In the cover letter. I only run it on allcode. >>>>>>> >>>>>> >>>>>> I see. I can spot these additional violations from earlycpio.c. It >>>>>> does >>>>>> not result in a failure, but only because x86_64-allcode has also >>>>>> other >>>>>> non-clean guidelines and is thus allowed to fail. Ideally in some >>>>>> copious free time I'd send a patch to create a subset of clean >>>>>> guidelines for the *-allcode analysis that is failing, so that the >>>>>> "allow_fail: true" can be removed. >>>>>> >>>>>> https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/people/agvallejo/xen/ECLAIR_normal/ucode-disable_v4/X86_64/12771570090/PROJECT.ecd;/by_main_file/xen/lib/earlycpio.c.html >>>>>> >>>>>> >>>>> >>>>> The web interface doesn't allow to search?! Sigh... thanks for the >>>>> pointer. >>>> >>>> It's your usual mess of miscasting, enum-as-int, etc. >>>> >>>> Would you rather keep the exclusion and deal with it later or let it >>>> pile up? >>>> I just don't have the time to go into it myself. >>>> >>> >>> Well, including more stuff in the scan doesn't hurt and it's only a >>> handful of reports that could be fixed, but the maintainers will have >>> the final say. This file is not really inside my area as a reviewer, >>> but if it helps: >>> >>> Reviewed-by: Nicola Vetrini >>> >> >> I'm not seeing anything in that report that's on the clean and blocking >> list.  But to double check, I've started >> >> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2274001675 >> >> >> which is this patch in isolation to see if anything shows up in the >> *-amd runs. >> > > https://eclair-analysis-logs.xenproject.org/fs/space/verdesse0/XEN.ecdf/xen-project/people/agvallejo/xen/ECLAIR_normal/ucode-disable_v4/X86_64/12771570090/PROJECT.ecd;/by_main_file/xen/lib/earlycpio.c.html#{"select":true,"selection":{"hiddenAreaKinds":[],"hiddenSubareaKinds":[],"show":true,"selector":{"enabled":true,"negated":false,"kind":1,"children":[{"enabled":true,"negated":false,"kind":0,"domain":"clean","inputs":[{"enabled":true,"text":"added"}]},{"enabled":true,"negated":true,"kind":0,"domain":"kind","inputs":[{"enabled":true,"text":"caution"}]}]}}} > > > Looks ugly, but it's a direct view into the clean:added selection: > R10.2, R20.7, R7.1 in short. > And to follow up: https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/12783298989 So, earlycpio.c is not clean to the clean-subset for the AMD target build. In terms of ordering the series, patches 1 and 5 want to go in first, to get ucode disabled in the AMD target build. This patch wants merging into 3 for bisectibility reasons, but the justification wanted is "so it's included in the *-allcode" analysis. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 20 17:32:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 17:32:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209235.1521318 (Exim 4.92) (envelope-from ) id 1viFZz-0002W6-DP; Tue, 20 Jan 2026 17:31:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209235.1521318; Tue, 20 Jan 2026 17: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 1viFZz-0002Vz-9g; Tue, 20 Jan 2026 17:31:47 +0000 Received: by outflank-mailman (input) for mailman id 1209235; Tue, 20 Jan 2026 17:31: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 1viFZx-0002Vt-RE for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 17:31:45 +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 e271ebd4-f625-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 18:31:43 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by MN2PR03MB5294.namprd03.prod.outlook.com (2603:10b6:208:1e2::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Tue, 20 Jan 2026 17:31:40 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Tue, 20 Jan 2026 17: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: e271ebd4-f625-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SiwU7vWb5dHqETTcdOhStW23viFY7x6IXLeUlTTNDFbLL8j5a/hevFtKL9ejYQgFxlsGnWTVyHHN4C6fsDW8W6klYzLcrOlBuGXwr9frwW0T+eo8Ak2ap5Lp9gpK7m6vUaQYPunNcE0vV+wjZpm7+BmMKQxQxDubE6hhlelQk25aeeYWRs6nbs9Mfj/bJJ9dnbgEgOm/mIZqfcvmPJSL1hAWl8MIAfHC6o8koz/p4p+4vvLpiVzSQEOo0H+Au1oiCXKHsBW6seD9A9f/ytwaQgsY477uDkDii63wz8ry3ZfN2holeH9sokfmxfO2zATCSvTL0vRB86dQx0sEjEmrWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YewgtYiC5iSiwIqlkS8dxSZPEdP7HnCbd7VakS5urhg=; b=h+JrEd12ZkU96leoK2HdxOlvE3DJVRME0XVX/d5LyYBiU3lioCR+5OZM09GCf/3OmCdpXU6kCQyY9NdWGEk5n0HpQOcKsJ2HxjpGZFkpN7r3YVo2SQ1XDvd0dmlHvw/sywtzjoLVyd1AChntlymFL78bFARw7yLRy+MIfXLx6WXF8LYUw5zaCYVBpCOSO22fB5mXsG70sE7Mbp0WaZqsswsINpXqPX110ChFvFVZD/rmRtmN91ubLjqMyhkRsRnihwXzG+alBYRvbKYfHpKq5ZGEReF9fLAfuz8qIJxVz97HKAx5wWahetlznDj1IO8EQqXUDiiTgCcPwowzAzh1+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=YewgtYiC5iSiwIqlkS8dxSZPEdP7HnCbd7VakS5urhg=; b=Zfr0d6gTBHRBcLpxrmK1p5kOtArD/S2qdyUq4B4ioeDifkX0DU0FjfxtLiitB4jJclSAiuj3PBXLHffcWVzj5WYAKdkAuVRlLvIhbYLmTDI/aJ9Bm6XY8TwN6aeMI8WiEQVkKjFhMPAhTnL8rhGuTiSv59Chj6/zN3ChVJu24f8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Tue, 20 Jan 2026 18:31:31 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jiqian Chen Cc: xen-devel@lists.xenproject.org, Huang Rui Subject: Re: [RESEND PATCH v12 1/3] vpci/rebar: Implement cleanup function for Rebar Message-ID: References: <20251208081815.3105930-1-Jiqian.Chen@amd.com> <20251208081815.3105930-2-Jiqian.Chen@amd.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20251208081815.3105930-2-Jiqian.Chen@amd.com> X-ClientProxiedBy: MA3P292CA0058.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:48::7) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|MN2PR03MB5294:EE_ X-MS-Office365-Filtering-Correlation-Id: 7b7bb7fe-3353-4255-6aaa-08de5849c565 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?UHUwZm0wd0hXVzJQN3dsU0RZWnE2OUFaajlka3hMMmpnWktVZ3NBTHRZUVI4?= =?utf-8?B?eC9hc2ZLMXVPdndlM1hTdHVoNGp2SXR4WjBYTzNHeFl2OE5CR1UyZmd1RHFZ?= =?utf-8?B?K2NkSWNwRlBpcDEwQyszZnplUzNybmdQUDNST3FyczR5Y2xrUVNma2JZVTg5?= =?utf-8?B?Qm8yU2tjajMxUCtNblVBTHM1RWsxMXd0S204U3kyV1l0TVA3ckczT3JkajJZ?= =?utf-8?B?b09LbGJYeFdSRGtYQnBHb3FaSWY0ZG5jSHh6c25YbEVsM2lodWNnZTVvTktV?= =?utf-8?B?cmJUMHRiZTFBOVpCUWJyejhoNzRKbFg0UEhUTGdnK3dKdXdleHV1RGhaS29X?= =?utf-8?B?QkxJMytGSkNLcXlXRnB5L0tkSERubkNBSWdnSVFWN2c5UUJ1OGs1aGFsU2dM?= =?utf-8?B?b0hmVnY0Y2ZuK1MvZHZCejZoUTE2U0RKN0cvTnV5U1NvV1hpVE1YdnhqR0xT?= =?utf-8?B?aDZBL1YxUnBEZGh0NmFMYTBrR0FaeEl6NEZRTXJjNUNEaDZaRXhOUythWTlC?= =?utf-8?B?VjJkZnl2RnJhdVJQVzhkQVRIUjNzRTNYU3BrTXNXcnFVVTl6UXFlWWR2YkQv?= =?utf-8?B?SXZVSUIrMitGM2RvUi9TNTFNamxDZ3VITWptMjZKY3FJL1UzTC9JT0kybXpu?= =?utf-8?B?YVZKYmFHSG1pRUFlc3ByQmtxWklPb3NrZTJNTTc3TXR0Qi9NejNEbVZIcTVn?= =?utf-8?B?cVBGaHVPN2EyR2JlOWxucFNPbTVweVBjSnpUelk4alNpUlcrMjdWSHJKTFA4?= =?utf-8?B?MU5nVmVYazBUekhpRjFRWTFqVHd5bjJPWkZkdXJ4cVUwUEozbTBoTENMc3RV?= =?utf-8?B?NnN1ajAzbkhqRXhmRVdPdkNHRFNoa3Q5TDNLVnFYZzVCUWRxT3lEMW5YNDBx?= =?utf-8?B?RllBbnJvdkpTYlRncnJwZEtpZDVFcUdvV0lDL0c1blpKYnk4cGRRWEpxd2J1?= =?utf-8?B?ems4dTFzRSt1S2d2T3VFVW9CbmdYVWRNNHF0QTdaWW1pb3A1emZ1UUFkSEcr?= =?utf-8?B?Tldrb0Z6anpGZERsR2J4Vko0TzkwRjNud3JXSUVCQlRzdG14bFBEWnorUTh4?= =?utf-8?B?UTYxUnNsRG40TmVVSklzMHVWeURaYm1EaWJhVEM0a3Fsd2xZME5PbENhc2N4?= =?utf-8?B?bmxabk5sSVByTjlyeTNqeldnZjdUdjBtZXZxN2ZQaE1kS1RaRHN3NTdoRFNj?= =?utf-8?B?aVlPNGxRQU9VbUliaVcvSHI5amkvNFVCYzV1dE16UE9CQkYyQTB0M0dzdGFS?= =?utf-8?B?ZU9DWnRBNURmV0dLank1OHZVanl4VnNUbWxWWDJTb2N2bUdNQmhpaCtxRDg4?= =?utf-8?B?Q3ZCQ0twK2V4dko1L281c1RnSERteG4wUnNGQnB4QzR1NkZJN3lYR2FNdFVK?= =?utf-8?B?Rlh5OHA2aUxqSGVJOVByVzlVY3plYWlaeUt0blZaVVpvaGFmWGRqM3pMcW9R?= =?utf-8?B?MSt4YStjT1BUR1F5SlNxS0NkNXBGY3RXN1NYSHZFVHNNZS9xUlhlVnJIcFkr?= =?utf-8?B?NElma21La2JES2lEMy9teFBKdjVsTFl2LzBnWDJ5eEdVSHh0aXRxaVJoLzI0?= =?utf-8?B?MlJWZ1Z6NElHNk94U1lPbmc2aGN5WllVTnVmTDhpNWdWS2I1bzhRdTVtdEJ6?= =?utf-8?B?b0szdGtoRVd4T0F2V2cwTjZLTzdBNGhUajN5N2VPckI0ZVB5OTRLcXhWU09i?= =?utf-8?B?aE9HTk9LaHhzNFRFNUltZ0NBY2ZNQWQzVk5RNGJ6WDR2LyszVUNEbllxSG9Y?= =?utf-8?B?WC9FOUM2ZFh4UkFSRDJCS3dXaHdWb01tRTBQN1NBc2NsaU4vR3g4UFRHUmtR?= =?utf-8?B?RzdudGZnY05FaW9QSGdOU3Voa1U3c2lZVElORmNMUUQ3UGpDV0ZEbWFhdFNU?= =?utf-8?B?S3c1UHgvUktxZHpyNGI3R1IzTUljZ0dDQStEUFlqNlNBSXFGQkptc3lWRkRu?= =?utf-8?B?NGlBNkEyNzZCT1l6N0ZiQkNJT3ZLakhGU1liOUhWbysray9CVkM4S2daeDBM?= =?utf-8?B?NGx4ZmtyVVk4eWtQdkVMQXZNRytCUmxzVTdJbU9ncWJRNVhhYVE3TTdIYmlQ?= =?utf-8?B?QzBiUnMzOSs2Y1hLcUlHeHc4ZXdhaGtxYnBPWmtaSkdkblViY3ZKQVdNVzhI?= =?utf-8?Q?WQtw=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SmF6WjZXT0VOUmx5WExzMlhsN1lCbUJyc0k5aERSMlF6VmdvT1RaRXNaU3dY?= =?utf-8?B?TVVwM3lGMVBxQVRaTEdIVkJSQ0orRjR1ZjhIMG5CamVDUGpEQ1JYWURkUnlx?= =?utf-8?B?dENSOFlTVFZVVFowZ3hkalN6cVpIcXNHME5OS3NpdWxNdU03V1AxWWxKSGhD?= =?utf-8?B?N2xFd2VCMGpFbVVZSWlMaUtUV0hydmE3YjhxZHgycEMyN0hWdVVxK0ozOU9N?= =?utf-8?B?ZEhYUFBkc01PYzJvTG0wRkE2dEFVSlVLQXR2OFJSRi9JM0VxWEZ0TTF3bDZX?= =?utf-8?B?VyswZjdFUHE2ZU82VS9GRnE5NktQSTdoSXN3ZVMwdkZEbGVUVHNydVJ4Rm9k?= =?utf-8?B?K003WWdIRnRWMlhwZ2JxYWpXOU1TaEcvQ1lmTURtY1NtMjF2WjhVYkw5K2FQ?= =?utf-8?B?aThBbXQzRk9aWUE0RmFmaEpVVGhYYlFWNWdWRk1uQlY1ckRqMjhsWjczb25h?= =?utf-8?B?aHYwOVFpMVhQd212SWRScFZaNS9rRGszanVZcnNkLzNMT25zRWRsUGNiRkRa?= =?utf-8?B?N0NEY3B0Z2h4djd4cEEvcE4xelNMa281K1IvbDFTeWJobC9hTVRncWpXMDlp?= =?utf-8?B?c0ZKZTFXMTZ3NllqL2hQQm9PSmllc1BGK2tKRk1GUmFGV3hhN2hSaktHdXIv?= =?utf-8?B?NkhxS21sOG91QW85NHgvdVdqQ2RaYVFaNE9YaGFzYnRudmgvV3h4L3QzN2pR?= =?utf-8?B?TTNzaHlIMk94SGtBS2ZEbzNINC9UK2xvSmgyZzlRcG1HYXdubXZFL2pSa1dw?= =?utf-8?B?UlUwZmh1TzhyZVhXbXZnVzBUUHFaK1ZRcG1JS0xKMnZtRXd4UkJITEZ5VFZC?= =?utf-8?B?MzJ3ZUVJeVlSUmJJeDROa2ZhMVVCQXRHVy8wTWlBWDlYeTFwSHk3aFBmdmFS?= =?utf-8?B?TURJTkh2djRUYzE4Nyt3OUpBZ29YdEJ0Z3l2VEc4bHZrM3JiT0tVQ0dtdmdK?= =?utf-8?B?WWs4Q3hJZ3VucTgyOGs2eHV6ZTdDbDlNV2Z4TkJ3NERPbEUyOTVwcmlzSkJT?= =?utf-8?B?ODZHVk5sQUVWajRsbHYzWUlaQ25sb1RlRXc1QVdJMkFUTFVVZFd4WG1nQ2dT?= =?utf-8?B?TGQ1dGxDdFpJSjlJOHBKb0hFb2J3bTJ2ckIrbm1lZ1IvM1JwaHM4bDBmWXUv?= =?utf-8?B?U2VCL2lIZ01HNHdoODBFZnpWaHcyMGlHd1o5a0lpRUJqbFZvWjZFdUo0cXB5?= =?utf-8?B?aklGOHE3NFV2TFZTWmluVlByQ0tiQVdmMmxOZlpySkVRNks4bnlxNEVRWVgz?= =?utf-8?B?bEtYM1BmVEp5TUM0MkM4Rnh6R0h4d2l4c1dMVUpQS20vRHBDYTNIYkRGT2la?= =?utf-8?B?NlBXWGh2UGMzaXZlb1RYMFl2MWRmeVVZaDhYT1pXT2FPL29vSE5DSmk3dXdC?= =?utf-8?B?eERmcUo2UjQwY05LUWQzQ0RNZ05FUFFJcWRGUW5HenlvMGEwSWdPdm5KQ3k0?= =?utf-8?B?ODFZaTFWcForRFFUckJSc29QZjFza2c2eFIvbzJieHlNMWJpbWdXaUhjQzVE?= =?utf-8?B?QzUwM0gzc1lSZlFiMUxLWWowbHA2V0VYdmNXZDU4akRpcm9jNHpsbkxpbnFr?= =?utf-8?B?VDF4M3l0VSs5QWVvWWcwMm9VQys4WkFqMWNZaHhIbkl1ZFNDczRQVStRQVIr?= =?utf-8?B?THc2dVdxQ1BhdWdnUU54SmZtTnVlNXc2RWJvSTV1MFpaeGxYOUNmOWJnbm1n?= =?utf-8?B?TTI1UCtockRKYzNGTXE4enZIR0h2TXlkSUVZU0xCM2MwUjJNS1diV1FpWFpP?= =?utf-8?B?R3RCSDRLbVBJMzV5TTVzQU1VMTQ1UWx5OUc3UzlqZEFpZ1Bwc3E0YUhvK2lw?= =?utf-8?B?YllUWVJqQ1oxWVZhdjR0RjJVMXl4bHdxZVBVZUVhK0U4ZUVVSkVQWXVkZkNv?= =?utf-8?B?QkxmZDVWRm1TSHYyTU9PdjlKSlpzOXM2c2NzRkZaMnRBNmZBK21KY0FWemxB?= =?utf-8?B?WGRtcjk3VmlrWG1NRDZQT3haTXlFWWUwQ01aK2drUk91WjJwQ0REVmZVTE90?= =?utf-8?B?UFZ5a2VoYzJyMHZqQ1VyaGtXbldDbktQQ0tJWXFjdHoxenlxU2dCaUwxcmR0?= =?utf-8?B?QVVkd3J4eWxaMW5VYmN3b29janMyK3NQVnhXSS9PR1ZBYzNlZGkxZVp4WW1U?= =?utf-8?B?RXFpeFQzQ0hOTU9CR1ZJL2hsRTBBNXdadE5MNEFDR243ZjZzUVY4dXNFU2ta?= =?utf-8?B?VGlGaTQvY2x5VXZlTktGT1gxMkhTaSs3alR4dXpZY1VLNmorbUtiY2NrYUxB?= =?utf-8?B?Q1Z1NzBFTVYzWHNUK0Q0RnQxZmJHV0hIRytOTWdmenRNdmd1RXI1V3E0UExU?= =?utf-8?B?cGFFV3cwY3UxbU5scldXYUdaQjFZSC83aDJHc0YycWtyVkdCWm5KUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7b7bb7fe-3353-4255-6aaa-08de5849c565 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 17:31:40.2003 (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: B39ri5+LZjsOGulJUX+D/a8nX3CeVy7hRkanch20/EQbj3jSnll63JBYe+3mlYKkTJxLA0yRpVw/skvIVHGZEw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR03MB5294 On Mon, Dec 08, 2025 at 04:18:13PM +0800, Jiqian Chen wrote: > 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 Reviewed-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jan 20 18:24:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 18:24:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209274.1521338 (Exim 4.92) (envelope-from ) id 1viGOV-0000oZ-8Y; Tue, 20 Jan 2026 18:23:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209274.1521338; Tue, 20 Jan 2026 18:23: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 1viGOV-0000oS-58; Tue, 20 Jan 2026 18:23:59 +0000 Received: by outflank-mailman (input) for mailman id 1209274; Tue, 20 Jan 2026 18: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 1viGOU-0000oM-42 for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 18:23:58 +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 2c3304e0-f62d-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 19:23:52 +0100 (CET) Received: from AM4PR03MB11152.eurprd03.prod.outlook.com (2603:10a6:20b:6cc::22) by GV1PR03MB10775.eurprd03.prod.outlook.com (2603:10a6:150:200::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 18:23:48 +0000 Received: from AM4PR03MB11152.eurprd03.prod.outlook.com ([fe80::ef31:b87:b7b4:ddbb]) by AM4PR03MB11152.eurprd03.prod.outlook.com ([fe80::ef31:b87:b7b4:ddbb%4]) with mapi id 15.20.9520.006; Tue, 20 Jan 2026 18:23: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: 2c3304e0-f62d-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XOoSJ9HC/OhTECCzqe3Q5u5fOsymJmCrpUWQLjiBaS+AH9yjXsY5iFYnKOxnVugeXJbxmOIsnGgUGqLCsYr8NW/8awAqUgdT4A4a/hji3WVp/0CgqkcZqmi3TNuQxvS6mFwvFI88JP17ECTMwpZnNYOuP+TdhWV8W6sBQ9EDdybUYBvubGYQP5jfp5QZKQ5nYU8fTUAA/mFk6+nECkk4byOEUsnWTaQUAWrPyRwXDYQQ8ftCj3JYhy41/d2moueQbOCYLT3UL1O8I8Qz4Eo3vpmy279gWjHBnLubwPYGprUcCxnDZnyMkf85uz83Sn4ThyyryvOaVjls9hBQrPa/TA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xbWEWJU/0bw/0f2OVvUtHrkNhgI03KuSe4SeOEOT50w=; b=jv3TnyHqqXa4QzUuUN6zYfEFcDkhfeOM+u2CCsGjzRQyZc9tjmk93HTGlaHJFQDWagiVotgJ2aZzNJ+bPvTgILpqb6mSaK64+CN2g12iM3AMWMjbXKZkbrPq/6yGDE/CqnzZNX810IKOMktTmJxumqg6kM+Hk/D4ro4BXYCaidyoF/Xtu1c3SHb9I0dpmSLft2tUvebNAe/xRLCKhBq3NahaYw08tD50t+jyYxPZ2zCl11yxhzCzBHI0UNGqIIBOyGtg+JMTlCc6JO5oxJJh15o+9RDrpIPY9yE6rNzWL5iBm/y6GhL4Xv+T9pXL7hoGaAALnKBTxWuxtg9OvyPI2w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xbWEWJU/0bw/0f2OVvUtHrkNhgI03KuSe4SeOEOT50w=; b=aDFAk3cgb4tvFQhgLP4g2j4JUTlE9BhDa55QTT+MwZDLPzrdPlGxB/hbf+xCVgbh77prnKnQAg2ohQ5xYpjhY4+xJyN+tEUveTjywxt4IC+eataIKnimaMDWGNJzUVYyHDFb8VMw6TrR5jXxdgEIOlwBaMvrpDh+YZbYO1bLxvHcgmHVckgjIcutsJtStXLDwX9tk/VDb9qKd93p/wLM2GzAHi8+W79HFZr3wV4lFhwZcq6UsnM7cjnUblGVl9IvMIfBGGbnYlrmXIsycQdjRb85bjUe0RpUbf69uyPkBL07fL4CQhQw3/Xc+2QSwugoRPaEZV/+L1KZlSb35wi+pg== From: Oleksandr Tyshchenko To: "xen-devel@lists.xenproject.org" CC: Michal Orzel , Ayan Kumar Halder , Stefano Stabellini Subject: [ImageBuilder][PATCH] uboot-script-gen: Add support for specifying domain P2M pool size Thread-Topic: [ImageBuilder][PATCH] uboot-script-gen: Add support for specifying domain P2M pool size Thread-Index: AQHcijnrd0sgeuOEFUiPnDmCo+f/yg== Date: Tue, 20 Jan 2026 18:23:48 +0000 Message-ID: <20260120182346.114435-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: AM4PR03MB11152:EE_|GV1PR03MB10775:EE_ x-ms-office365-filtering-correlation-id: 14d53995-e042-47ab-7fc2-08de58510dd4 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|42112799006|366016|376014|38070700021; x-microsoft-antispam-message-info: =?iso-8859-1?Q?RdrRH5nYxpTeMLLO0Q81cmFOCRCUQaLG59t3wI8iYlNgkEC41LJNwDxFB9?= =?iso-8859-1?Q?txSGjTOoUcJoe7b+wCctp+I+oop26w8x/acivNvwYZjy5+CETztfLFXjkH?= =?iso-8859-1?Q?brnQV1espqUgqsHSSTWvinvLgqjRB/ENJhho221ERA3OzZ+hPwC6iaToNb?= =?iso-8859-1?Q?r61jk5fVuBF+P9qrce9siuMDPU4KSKNCSSrynGAOLBLid6LBaQg0D32833?= =?iso-8859-1?Q?7Z5fbuUVVdaNYoblhCkpNbWrjLR/ZHfdaQXe1PEKHKjibx5wtN+bfGmL38?= =?iso-8859-1?Q?zyCmOWQjpARKKsnDGR/VImMrX0t6epwpBVUD0Dd8aHtNFKk1qH/qdOxEOf?= =?iso-8859-1?Q?LWIJDmUSt3IpcixtnlSMNF6SGdDLG6NBwbvmq3Jh6opcWiOMoTBC5AgocX?= =?iso-8859-1?Q?qIchGhWS7SB5Qmem+qVPaBaS1uZdVWbxITVschjtCQu4NwpwtSOkYN4+4i?= =?iso-8859-1?Q?3/fleijwKFVszXdbHJEDvh5piyC95qDAbtY/khsPcxWinfzeIrt4JAwoYZ?= =?iso-8859-1?Q?IjWhaaK74SklAwDl67Kc5RxDUkuzsMwvr8mpvjOEGurFU+1UV1KsmbIN/l?= =?iso-8859-1?Q?L7FJ3dQC5pTBgUqInf7x2f2vNopxdR4em4i4QARl7LLoNUytmuOvSJqFg8?= =?iso-8859-1?Q?4vrBNI/3NDqAdHcGPukT+Xx8RXFX+CT5PkfXd/tnTg5k868gAE+SC9YPfP?= =?iso-8859-1?Q?hAGYZquEbqpl/0lS/Mv3yDkjGDm3Pq025x3DlnqkkXM613hGqvzmNot3s6?= =?iso-8859-1?Q?dQsaG5tjCs+aODXzmLS4MG0JWYY++lUeCgEe4krX6uoAXe3xFisLhyNGb1?= =?iso-8859-1?Q?aBvgLUH8Sflxh7qcshCoZyK9tpUqZ2qtn7Q4yiloSt/H1E1Sz9Src6fZQ9?= =?iso-8859-1?Q?ovA4QNYI4EsAJKhXqTgN2UUmUffT2AdWkmnRXMbfvPh7xL1Zoy1MEGfL0K?= =?iso-8859-1?Q?ql0gbkdARDynZd+AWUfOztmTttzvsFa+FnOgZN9YWSSkQLLLzvhI8KP5+a?= =?iso-8859-1?Q?bS7ja4ONcHpPKe3DmqIOzI7dhDwtelSTLLqA0dr52PVIqgQDOyy3mMtFLE?= =?iso-8859-1?Q?/eABGFaAMfNTKM7D/6ETh3zgBn8oEoGwgB76kRNv6myZUtPbCy5s5K33/a?= =?iso-8859-1?Q?7J3HQf5KiVW5R4w33Z7cZk9IXuUmt0QSCLBvBzfcv8SZCRQ7m/5tkBuh1H?= =?iso-8859-1?Q?XJyPIhfB2O1hXTEwWCr1SboFD1kVGY6n51154KZ4yJ9m+J5/5y+SkrHbSB?= =?iso-8859-1?Q?fU1s5oOIezNXHMSGxw8XDe2NsKApX8uAVYJX/rKi2i8G907bFwks7Nyp4A?= =?iso-8859-1?Q?igol/Hci8fSuuPt5sV5QWEEdhjdzWDYYVCkfeLSFzsFV2dVAIgMQGHKaX8?= =?iso-8859-1?Q?9369FQYnHeO6WqI5rK4xr1Rs5RvBL5Hhutl5eI+5zzpcwySeyXUcq5f0XP?= =?iso-8859-1?Q?SlFCuW9ALSoWKZtF41dSUYTVnRxtqnSPgQceXAMJEebv9Nu4zZ0IDKMDqh?= =?iso-8859-1?Q?jI1DoR5cwXlMHUVz9Y+OP9CXAdg+aK7jpN25RE/CBLC2JOD831Zd8BP/i6?= =?iso-8859-1?Q?6oUUgF8gpu/NAbkyb+rs9c5jIAgYAw8N+wfY/ZlIjje9Uqhgw30jWaI7rN?= =?iso-8859-1?Q?ABvJlrjHjIrBGF+Y+FgA8GX5KcMkthLFZPSX9I47vX08wqbHBPuc31wKJ9?= =?iso-8859-1?Q?V8gAPMW5HYfsGM+wyd4=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM4PR03MB11152.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(42112799006)(366016)(376014)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?Kwj9R3sOpxmdAvam29Pe/Qdg4dqgIZ4y0UdFbdT+P240If49DzDR4a1Pmf?= =?iso-8859-1?Q?ox0fWdvgZJyp6nS7POnOn96YGeBmAkCGH4gfaHYBx34aPqAKf3VzH0EXz6?= =?iso-8859-1?Q?ouA7vhBz1TRl8SSiGCOxI3wiiYxJbBq6CcKwhcZYelydcjFEzu1UFJPnK+?= =?iso-8859-1?Q?UOfCIOa7dRqdzxa36B0w/kasx59MqKJX5ukm27VgZ+TPTllUkjcPiZ10BM?= =?iso-8859-1?Q?e2QU2RqKfnkSO7WYDem2XNj8mCcSy8rsQmBGq2Ek7+dDnYQ4BKRGfcnUn8?= =?iso-8859-1?Q?nbruKx5XZgnnCafmKVi4KUkP3E+1xWz+qkj9I1XEaLWbJP/Rdvp0+bOxwS?= =?iso-8859-1?Q?D7IzKb72f84B1hLBxz3/nWXJP32+iXs9U2sfRin58vRcuRhB6JIc8D5nLK?= =?iso-8859-1?Q?p18srn9DCQ2XqrZrdu8UV0e3s9hK59fbUU6k50uEl9cU5m1lBoFAGYHYvj?= =?iso-8859-1?Q?jtro/1pxUXXtSnxXM0GX0wWWKDcW6qesgj34xUyqvbeBM1G+VbM/BSifOR?= =?iso-8859-1?Q?pR6kYYJKbq3jiwp1yNffdng8w+o01rsj+Z+VGRClxzg9PbnxIgV1RnR/3x?= =?iso-8859-1?Q?CHH8EuLmkIMPegTO/sCldvrkvYU54MO3qvYOuzf/RbP8Zmmdd52mlmeWb3?= =?iso-8859-1?Q?a+Ok5Jh4D76rPfDojCSkS+77GHbW6pB814cIPSZibRbH9qS/Alp1drvEnv?= =?iso-8859-1?Q?HqjNnTULrlNMMV3ljxO10e6L63zz8R59w49n4nDvuj1q9GRzmxkWK1acmn?= =?iso-8859-1?Q?tlDEx18XCbyAk/tWEH4Ud7PyTIQjI0WRiBcGhGBGkUGH0+uwaRHwd41Zid?= =?iso-8859-1?Q?NSMsldFlWaJP1UfgxCo70uYrt+LVBu4TkBykcJfWXeUyQgYfWtoj6E1KqO?= =?iso-8859-1?Q?tYHS9RL3q65urpFmzhaV+jRCdR4yI84YhgH7p+QG/TaKaKxm9D9M35u2sG?= =?iso-8859-1?Q?0NjjYitAx2yR71lU7QyH4u8FFNhXi84hPKKS9yUXvUNl42tczQapT1Qy+m?= =?iso-8859-1?Q?UU0MW/zoH5p1svq3PPD+1UMXjsu4xfL6kC7KF2MF5Cgb6NimUCBOkWxtUA?= =?iso-8859-1?Q?8sSI0bUbOfLFKumsAHRMs3UYUnBwYmtKFsdJWCvayl/NU3OWeIoFqMrMBd?= =?iso-8859-1?Q?erCm8dLbRTEP0DfCIPbkisKe+eUKR2JhJcJdftDdUaV/qyJDc0cvugkKaq?= =?iso-8859-1?Q?wRfjOm8KipePCZJUlnzBgoiq7+XsvepRLEGog3tTTvHC1PYi/l9zAw68sA?= =?iso-8859-1?Q?yZDMiCDwCDY7M33CASrN1efimPqh59Ki5SmKhc3sdO8cHIRIgfyeZMKZRN?= =?iso-8859-1?Q?O1PMw4xQlK39tUDyqbOqQ3nne9xgJADvzmhS8f5yXkapu881zOmz6d0aID?= =?iso-8859-1?Q?BF8INPphC93IuX7KZrau4cQ8KOwx5oscH4ltoBbBi/uxlLRuMwMMHCvwVM?= =?iso-8859-1?Q?RCluKmbXCfr09j2T2oYyK1Y2a+kNbo+hL2gpmD7LeDmH59tm0lFmcnuJ9O?= =?iso-8859-1?Q?ztwEqVZuuDbss7sIxNa8mEAt/UeIOsTPo/xdG8K3apFmQWcHYmcssDc8Li?= =?iso-8859-1?Q?AnjOzlaC5YNIL5xrTf3ZLnBId0RFkm5whjsfKl03z25R2xRizScfiRpcxT?= =?iso-8859-1?Q?vQgGztUqBhDz/KxplEM+JmzIKNq9fxpfCi5QoOS7sljxK7pRFyiC9fsaOv?= =?iso-8859-1?Q?S/j4KGZcIpwe1CVoBxRa5TtUkqcX4eS1rMrE2uAu1i5nn8nazdh9dseLyz?= =?iso-8859-1?Q?sUNQpVi9sbILePgzKgW6N8Pt56GhdlxNLOvAcJboZuB60GFpEhfBshhWuT?= =?iso-8859-1?Q?eQOOWv43UvJ86qjYSZ3Rz1XnU1/1xDY=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: AM4PR03MB11152.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 14d53995-e042-47ab-7fc2-08de58510dd4 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2026 18:23:48.0584 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: f7BRcf+Iy8aINJkgMrJleYVmZLFHqTTImhUGm28bY+2dDWM9FNGZ5tJhlFYasqxTzUoCBEKkwAI/A1VgTVIep1ed1cYkXe6WhjEeRMFey9Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB10775 The DOMU_P2M_MEM_MB configuration option is used to specify the amount of megabytes of RAM used for the domain P2M pool. It allows users to manually define the memory size reserved for P2M structures in non-hardware domains, overriding the default value calculated by Xen. Signed-off-by: Oleksandr Tyshchenko --- README.md | 7 +++++++ scripts/uboot-script-gen | 5 +++++ 2 files changed, 12 insertions(+) diff --git a/README.md b/README.md index 983cbbc..c7ae98e 100644 --- a/README.md +++ b/README.md @@ -203,6 +203,13 @@ Where: NOTE that with this option, user needs to manually set xen,passthrough in xen.dtb. =20 +- DOMU_P2M_MEM_MB[number] is optional 32-bit integer specifying the amount + of megabytes of RAM used for the domain P2M pool. If not set, the defaul= t + size is calculated by Xen. + Note that the P2M pool is used to allocate pages for P2M structures for + non-hardware domains. For the hardware domain, P2M pages are allocated + directly from the heap. + - DOMU_MEM[number] is the amount of memory for the VM in MB, default 512MB =20 - DOMU_VCPUS[number] is the number of vcpus for the VM, default 1 diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen index d18ac55..0c86c2d 100755 --- a/scripts/uboot-script-gen +++ b/scripts/uboot-script-gen @@ -514,6 +514,11 @@ function xen_device_tree_editing() dt_set "/chosen/domU$i" "passthrough" "str" "enabled" fi =20 + if test -n "${DOMU_P2M_MEM_MB[$i]}" + then + dt_set "/chosen/domU$i" "xen,domain-p2m-mem-mb" "int" "${DOMU_= P2M_MEM_MB[$i]}" + fi + if test -n "${DOMU_SHARED_MEM[i]}" then add_device_tree_static_shared_mem "/chosen/domU${i}" "${DOMU_S= HARED_MEM[i]}" --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 18:39:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 18:39:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209287.1521347 (Exim 4.92) (envelope-from ) id 1viGdc-0002Vw-F1; Tue, 20 Jan 2026 18:39:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209287.1521347; Tue, 20 Jan 2026 18:39:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viGdc-0002Vp-CL; Tue, 20 Jan 2026 18:39:36 +0000 Received: by outflank-mailman (input) for mailman id 1209287; Tue, 20 Jan 2026 18:39:35 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viGdb-0002Vj-Nt for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 18:39:35 +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 5b639f81-f62f-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 19:39:33 +0100 (CET) Received: from PH5P220CA0005.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:34a::15) by IA0PR12MB7601.namprd12.prod.outlook.com (2603:10b6:208:43b::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 18:39:26 +0000 Received: from CY4PEPF0000EE35.namprd05.prod.outlook.com (2603:10b6:510:34a:cafe::c0) by PH5P220CA0005.outlook.office365.com (2603:10b6:510:34a::15) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.9 via Frontend Transport; Tue, 20 Jan 2026 18:39:28 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY4PEPF0000EE35.mail.protection.outlook.com (10.167.242.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Tue, 20 Jan 2026 18:39:26 +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, 20 Jan 2026 12:39:24 -0600 Received: from [10.71.192.102] (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, 20 Jan 2026 10:39:23 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5b639f81-f62f-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=WuHoWlyxnhlT2dGfXDLLHmYJ/GRmO2SYy14uQhtGYl+IbUFlSYTrcNRvLnqdCljBJUbiRxpKi6umr6LFbAOD4FCNfaU+if1fcZKGyg/qRhTeZYTkTNLw3u7uvgwYKlqSB6GeHoCMlmr7GgteyuYzBF3/igmne1RmfaViTG7tZl7P8gA78RGQVibHq2cXJ0ijBt15g0rEMBXqggvloaYczyJO3qGUbbaGHuO4ePTQjhtkI+I8MLJRDpuQsiUzbhmaJ7VQmQVq1pJKg1zsmyCLz1SUf6RxR182nd36FL0exVNuK5gaPbJW7QJ8QesE+/hoN5i2Rl0dGKDg6yo15T00Vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9lrCCxiD8hJQD3hxgO2twKCy00V5+OdjsauUV3ipJiE=; b=VUp+45hxqqbCJwQ107tU4Ego3RgcgIISDZv8+Yi/eWOdeM2HQPNsJOydMF3EDRyq7z1T721dHQwuwgGNAEkxcTraeO6xTgAfZuFAltqbO2JXFGxWCWF0gtFwV9jbzz5UFEIxCq0V4ceegYzoJOU366LlBv9fFuGmnpFx9FBJ1nEnMYGLhykd6WSp6W8JDfqJSvJu+AHvmBKV+956nlDulGrbDpZoLh0otjFEBTwNpO3VRO+LQgnghP+Eu0QY9e8/cE8ayUrduRP6kTvoA3u/v5hPQQs7z/VssuYUlJQuzyAFkKjOJXdYCkXKAEei3wvDmfnzalCBkHUKtZZ+b5aS5w== 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=9lrCCxiD8hJQD3hxgO2twKCy00V5+OdjsauUV3ipJiE=; b=C2z1fxeZk7KFUarHhNQiSxR3DK2zmDXRPyX+nRyhKcTgZfoIgvLR8V2nFcIx+QDL8SvCSay79hiey0MoNZpyG+RvhChRF0sReMUVG2vuZS0L1vNYTmqBTwNWq1UGhYr1f34wZT1QkSpqgsef2voRq8AmsCCXeiehDpGRtZAZyQk= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <7dfe66e7-73ae-4420-8e3e-e7acf814ddf0@amd.com> Date: Tue, 20 Jan 2026 18:39:22 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [ImageBuilder][PATCH] uboot-script-gen: Add support for specifying domain P2M pool size To: Oleksandr Tyshchenko , "xen-devel@lists.xenproject.org" CC: Michal Orzel , Stefano Stabellini References: <20260120182346.114435-1-oleksandr_tyshchenko@epam.com> Content-Language: en-US From: "Halder, Ayan Kumar" In-Reply-To: <20260120182346.114435-1-oleksandr_tyshchenko@epam.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000EE35:EE_|IA0PR12MB7601:EE_ X-MS-Office365-Filtering-Correlation-Id: 83864497-bd64-4643-9455-08de58533d26 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?bzRnZE8rRzFGZkc2amZDMHF3YTM5SldwVmN0ZkhrTWhJQTVWVFpEbkhwUVhu?= =?utf-8?B?N0FuMy8vV0ZDZ2plcWtNOHU3KzZlcC9OV2tCM2h4SmljSjRpSHdZdTB5anRV?= =?utf-8?B?OGxJY0x4aTJ4ZEpsWS95Z2dDK0ZnQ0NaeU4xSlN0bWFISy9sZTJMa0NkWTJS?= =?utf-8?B?V0R2d0ZDVTRsM3ZWTU1Xbk1FWUJvWlFNdm9UdXV1RlNpYkJ0R091RTAzdzln?= =?utf-8?B?TXQ4WDY0Q2VxTmFIRERLK0pJMFRENkV4clhPcGdFN1g2RHh1R2k3Ulg2Zjcr?= =?utf-8?B?TUhNc045TW4zSWdwZVpSZzNRNUtsSmZ5ZjUwRjRqOTk5eERHYUZnTzJReG5E?= =?utf-8?B?UElWSXBZcGhuTVk2WEtYcklEQWYzY0o0L3BIaEExbTUvZ3RPWEI4ellWTEJa?= =?utf-8?B?SGZ5MFc0eWh4OEFVQzhGK1l6WVRLbkxSV1duZ05zMXZwRk80R1ZUMmlDT013?= =?utf-8?B?dlJkalJWTXlWL1IyZ3BlQ1FQZ3BaUGZBV04waXBCakltSzJLSlZORDRDWHdB?= =?utf-8?B?UUlGVmZ1cWYxeWlXdG9tMWloemQ2c1QyWURKVUVFK1FIbzFIajFlRlY1b2lN?= =?utf-8?B?S1FIUU5ML0ZXRGtpeDJhZjlDNWltM1ZLcGZuZGxmbXlwTGRCR3E3Z1RqUnRL?= =?utf-8?B?dk0zN3BMTGN5Tmc4ZU1tRFhSdFBuSEdqaDFkY1dHdk82akkyZ0dRUEJTNHE4?= =?utf-8?B?eVRoejk3VVRBUHRnK3hibzJ1MHV0RFhGbnlMNUZIdmJqaFV1V0swLzBZamZw?= =?utf-8?B?RkR5b2taUmhkOVUycWI1ZWpSa2hMeHpEZmpYekpRT2pHNXV5TUhjcC9JWVdE?= =?utf-8?B?YWsrOThSdWdGTlJGSEJOL1ZKRzZqYzEvTmI2b2UrZWtZZktYQUordHphQnJB?= =?utf-8?B?em5IanVzdkNCYlFhd04rMXJScDVRNnY1MkNkMnBKZ0VBclp6MkdVdVNCUWpO?= =?utf-8?B?V3puOFVESENjUG5PVXJqbVlJcUhoWjN2NGlTVXBZeGIwVi9ldGV4bGJHWC9y?= =?utf-8?B?UkR4dkF6SE9NV2FRY2tmRWpPSU1GTWh2MVQweDZHQlhteTRJckZaMVJaekZ3?= =?utf-8?B?N2NwL1lDYUs5NnZpQnIyemRxblV4MDNoT0N2M1Bnem1MYkVUVVJvbDRHUFJO?= =?utf-8?B?ejJpTmRhMEVPZXBHREQ5QmxMTkJsWTFSRS9wM3FYc0dzSTEycm1FdEZzS2Vk?= =?utf-8?B?NlZ1cmZJa1hJVkI3UXM3Y1R4QkdKQ3lRcmhBZU0yVFpTU3dpdEFtNW9aREFY?= =?utf-8?B?MTlvSTJxR296enppR3dCYzdTdiswdThyelJ4Y3FhVzFFV0toS0Jnc2V2dUFC?= =?utf-8?B?WGhSYzU1Z1luYld4S05USzMzNG5tSUU1VzNCdTB5QWdhQTk1dUYxbmVVWnZz?= =?utf-8?B?Zmh0QnNZZUFZdjc5d21LYU9BbGlld1AvdytMYXluQ3BiTjhwdXFRQmZZREU1?= =?utf-8?B?dDRncWpNelJUUmNNVTVpMGd0ellERTljVTB3ejFZeWw3eTNnZGpSMmprTWRH?= =?utf-8?B?NXhYM1VpZnR0ZG5YUmh6eitmSU52OHVabTFwOG9NQU9tRmVKWGpHSTBGbSt6?= =?utf-8?B?bUh3V1JXOU5CT1RGVklKckZobjJQcDF4NUZPNmpnZmEwdDdtcEdvbXhGM2Vj?= =?utf-8?B?aEZueGh6QjRqelFrTENicUJNQk5mZ2JKS1piQ01tRFZPcGtjTldncFdjNnhX?= =?utf-8?B?Ylphc3FRUWMxWVJtN2x3c1pJSWJuMTNCWVdqOHdNMy9GVmFXN3RsTnUvTzcw?= =?utf-8?B?V2hMaVBza1dXYUJ3cW5kT3ZEN3dJc21qNDl4WFdYQUhHMmp2OUhLUFVHb056?= =?utf-8?B?cEgvVXdLYkcyalZ6MjJXRHRUa2w1aHZwOHE5Tm5HS3BqTitsZXFmVTZocVNj?= =?utf-8?B?bjRxWXdjbFhsQWg3WE1Qd1duUldnamFrZFlEM3hVVE9yck1TSC9UZ3JjZ1Bi?= =?utf-8?B?ZHpQRXFyaDBQRmlGQnZwRHhHSkltL1h5UUJoU3pERHBQSkhnMTRkNjRwNUMv?= =?utf-8?B?MTZPYUFiZSt2TDJudDNCczJDYjB2VFE1b3J2eDNBMWRQREs1SWFOOWp6anRE?= =?utf-8?B?RjFsSHJpaGNJNFN1Kzc4NzZQbklWckJteXBGaEFLd05VbnZiblR0WHdXNWxs?= =?utf-8?B?dGJJUi8ybTRxU2VUTTN3SWdjQUJ1SVpkTGllRmZxZmZGdFJlYXg5bWFERW42?= =?utf-8?B?clFzbWdoTUEzTkZYbUlOTVhaeHgxZnVjN0wybTJjNjVLb0NnRE9BRG0xemVn?= =?utf-8?B?d0FRK2psUkRhVk1LNEgwYmpiUm1nPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700013)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 18:39:26.4255 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 83864497-bd64-4643-9455-08de58533d26 X-MS-Exchange-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: CY4PEPF0000EE35.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB7601 Hi Oleksandr, On 20/01/2026 18:23, Oleksandr Tyshchenko wrote: > The DOMU_P2M_MEM_MB configuration option is used to specify > the amount of megabytes of RAM used for the domain P2M pool. > It allows users to manually define the memory size reserved for > P2M structures in non-hardware domains, overriding the default > value calculated by Xen. > > Signed-off-by: Oleksandr Tyshchenko Reviewed-by: Ayan Kumar Halder with a question > --- > README.md | 7 +++++++ > scripts/uboot-script-gen | 5 +++++ > 2 files changed, 12 insertions(+) > > diff --git a/README.md b/README.md > index 983cbbc..c7ae98e 100644 > --- a/README.md > +++ b/README.md > @@ -203,6 +203,13 @@ Where: > NOTE that with this option, user needs to manually set xen,passthrough > in xen.dtb. > > +- DOMU_P2M_MEM_MB[number] is optional 32-bit integer specifying the amount > + of megabytes of RAM used for the domain P2M pool. If not set, the default > + size is calculated by Xen. > + Note that the P2M pool is used to allocate pages for P2M structures for > + non-hardware domains. For the hardware domain, P2M pages are allocated > + directly from the heap. > + > - DOMU_MEM[number] is the amount of memory for the VM in MB, default 512MB > > - DOMU_VCPUS[number] is the number of vcpus for the VM, default 1 > diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen > index d18ac55..0c86c2d 100755 > --- a/scripts/uboot-script-gen > +++ b/scripts/uboot-script-gen > @@ -514,6 +514,11 @@ function xen_device_tree_editing() > dt_set "/chosen/domU$i" "passthrough" "str" "enabled" > fi > > + if test -n "${DOMU_P2M_MEM_MB[$i]}" > + then > + dt_set "/chosen/domU$i" "xen,domain-p2m-mem-mb" Was this property recently introduced in Xen ? If so, it may be good to refer Xen's commit id. - Ayan From xen-devel-bounces@lists.xenproject.org Tue Jan 20 18:59:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 18:59:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209299.1521357 (Exim 4.92) (envelope-from ) id 1viGwp-0005Jt-SC; Tue, 20 Jan 2026 18:59:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209299.1521357; Tue, 20 Jan 2026 18:59: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 1viGwp-0005Jm-PW; Tue, 20 Jan 2026 18:59:27 +0000 Received: by outflank-mailman (input) for mailman id 1209299; Tue, 20 Jan 2026 18:59:26 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viGwo-0005Jg-Cb for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 18:59:26 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1viGwo-00Crcn-0t; Tue, 20 Jan 2026 18:59: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 1viGwn-00BwMN-1f; Tue, 20 Jan 2026 18:59: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:Message-ID:Date: Subject:Cc:To:From; bh=ZkHW951EcvlKRgwnk8lLtbogl+mge00JxhboUAq9tIk=; b=HGNt8b 1wr9mfy6GAzqmpXnpL0af7qlLBz5U+Nf9/LCYCXOkQpVTMgdsbwiPlY+l2hOb3lGuo9Au3LAd9IAI 4FhCTGxpaMQYfpuNNIdZ8n7FPl/vGQWVyNoYDpiyc5pPmY4Rk7WooIKRWZ8bmwoJCUHUBFlURA/79 mzuAiSDtP8Y=; 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 v4] INSTALL: remove unsupported XEN_CONFIG_EXPERT from documentation Date: Tue, 20 Jan 2026 10:59:05 -0800 Message-ID: <20260120185904.979992-2-dmukhin@ford.com> X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Denis Mukhin Remove XEN_CONFIG_EXPERT explanation and also correct information in the entire "Xen Hypervisor" section. Amends: 37339ba9ef46 ("automation: Remove XEN_CONFIG_EXPERT leftovers") Suggested-by: Stefano Stabellini Signed-off-by: Denis Mukhin --- Changes since v3: - text correction suggested by Jan - Link to v3: https://lore.kernel.org/xen-devel/20260120071654.640873-3-dmukhin@ford.com/ --- INSTALL | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/INSTALL b/INSTALL index c2e756bf4b2b..fb9efe884fb1 100644 --- a/INSTALL +++ b/INSTALL @@ -25,19 +25,12 @@ Xen Hypervisor Xen itself is configured via a `kconfig' system borrowed from Linux. See https://www.kernel.org/doc/html/v5.4/kbuild/. -Note that unlike with Linux, and contrary to that document, you cannot -look at Kconfig files, or the default or generated config files etc., -to find available configuration options. This is because it is only -supported (and security supported) by the Xen Project, to change a -small subset of the options. Attempts to change other options will be -silently overridden. The only way to find which configuration options -are available is to run `make menuconfig' or the like. - -You can counter-override this behaviour by setting XEN_CONFIG_EXPERT=y -in your environment. However, doing this is not supported and the -resulting configurations do not receive security support. If you set -this variable there is nothing stopping you setting dangerously -experimental combinations of features - not even any warnings. +Only a subset of options is supported or security-supported by Xen +Project. You can explore all available options, including unsupported +ones and those recommended only for expert users, e.g. by using `make +menuconfig` and enabling `CONFIG_UNSUPPORTED` and/or `CONFIG_EXPERT`. +However, enabling these options is not supported, and configurations +resulting from them do not receive security support. Options recognized by configure =============================== -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 20 19:30:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 19:30:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209313.1521368 (Exim 4.92) (envelope-from ) id 1viHR1-0001jJ-5n; Tue, 20 Jan 2026 19:30:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209313.1521368; Tue, 20 Jan 2026 19:30:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viHR1-0001jC-2z; Tue, 20 Jan 2026 19:30:39 +0000 Received: by outflank-mailman (input) for mailman id 1209313; Tue, 20 Jan 2026 19:30:38 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viHR0-0001j6-1W for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 19:30:38 +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 7aee976e-f636-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 20:30:31 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 3D2024371F; Tue, 20 Jan 2026 19:30:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7C7E2C16AAE; Tue, 20 Jan 2026 19:30: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: 7aee976e-f636-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768937429; bh=HCy+gefaPOQHIiQVT6+7rc0PqTa3aSWejYFbSe+K/sM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=YVXAJBS7knwgvrIf0MH4ifgHEwPnIEoNO17FWM4dC0gc09GB9Zq3zhFeU3HKyWPPn sP4XqQJIsxObYX14TET8wVkNqSzuzjinHz8czpTaGfkLQayPr7VVv1qhSG6/ffnxDQ jPIv8KgUKN5NDpaHPy1XdZgk5pyWPrwL+S6N762MIQyTNc68Otf+hv50QLGoHwQH2W NhJJ5quhvMveEbReQ0Ia1i7NDfKCyZfpoFJ18mAVjcTHOV3i3eychB+/V1KGp6rtKA mV4kZgXj5juFKodyOSZDnrSop+sbK0w4kMUdgjmhihN/0dANplrRI8w2iv7s47hyh+ vK1I7EeAEvJJw== Date: Tue, 20 Jan 2026 11:30:26 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Oleksii Moisieiev cc: Stefano Stabellini , "xen-devel@lists.xenproject.org" , Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Volodymyr Babchuk , Grygorii Strashko Subject: Re: [PATCH v7 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver In-Reply-To: <4278b6df-11fc-403f-b498-16afe3e0c779@epam.com> Message-ID: References: <5177397f-d596-40b3-9207-f0de63a24ee6@epam.com> <4278b6df-11fc-403f-b498-16afe3e0c779@epam.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-646006288-1768937429=:7192" 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-646006288-1768937429=:7192 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Tue, 20 Jan 2026, Oleksii Moisieiev wrote: > On 19/01/2026 23:12, Stefano Stabellini wrote: > > On Mon, 19 Jan 2026, Oleksii Moisieiev wrote: > >> On 16/01/2026 23:21, Stefano Stabellini wrote: > >>> On Fri, 16 Jan 2026, Oleksii Moisieiev wrote: > >>>> Hi Stefano, > >>>> Please see below. > >>>> > >>>> On 15/01/2026 03:14, Stefano Stabellini wrote: > >>>>> Hi Oleksii, > >>>>> > >>>>> I am fine with the goals and the strategy to achieve the goals but there > >>>>> are some finer details that don't make sense to me. I apologize if I am > >>>>> asking the same questions you have already answered as some time as > >>>>> passed from the last interaction. > >>>>> > >>>>> > >>>>> On Wed, 14 Jan 2026, Oleksii Moisieiev wrote: > >>>>>> This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-A > >>>>>> (TF-A) which provides SCMI interface with multi-agent support, as shown > >>>>>> below. > >>>>>> > >>>>>> +-----------------------------------------+ > >>>>>> | | > >>>>>> | EL3 TF-A SCMI | > >>>>>> +-------+--+-------+--+-------+--+-------++ > >>>>>> |shmem1 | |shmem0 | |shmem2 | |shmemX | > >>>>>> +-----+-+ +---+---+ +--+----+ +---+---+ > >>>>>> smc-id1 | | | | > >>>>>> agent1 | | | | > >>>>>> +-----v--------+---------+-----------+----+ > >>>>>> | | | | | > >>>>>> | | | | | > >>>>>> +--------------+---------+-----------+----+ > >>>>>> smc-id0 | smc-id2| smc-idX| > >>>>>> agent0 | agent2 | agentX | > >>>>>> | | | > >>>>>> +----v---+ +--v-----+ +--v-----+ > >>>>>> | | | | | | > >>>>>> | Dom0 | | Dom1 | | DomX | > >>>>>> | | | | | | > >>>>>> | | | | | | > >>>>>> +--------+ +--------+ +--------+ > >>>>>> > >>>>>> The EL3 SCMI multi-agent firmware is expected to provide SCMI SMC shared > >>>>>> memory transport for every Agent in the system. > >>>>>> > >>>>>> The SCMI Agent transport channel defined by pair: > >>>>>> - smc-id: SMC id used for Doorbell > >>>>>> - shmem: shared memory for messages transfer, Xen page > >>>>>> aligned. Shared memort is mapped with the following flags: > >>>>>> MT_DEVICE_nGnRE. > >>>>>> > >>>>>> The follwoing SCMI Agents are expected to be defined by SCMI FW to enable SCMI > >>>>>> multi-agent functionality under Xen: > >>>>>> - Xen management agent: trusted agents that accesses to the Base Protocol > >>>>>> commands to configure agent specific permissions > >>>>>> - OSPM VM agents: non-trusted agent, one for each Guest domain which is > >>>>>> allowed direct HW access. At least one OSPM VM agent has to be provided > >>>>>> by FW if HW is handled only by Dom0 or Driver Domain. > >>>>>> > >>>>>> The EL3 SCMI FW is expected to implement following Base protocol messages: > >>>>>> - BASE_DISCOVER_AGENT (optional if agent_id was provided) > >>>>>> - BASE_RESET_AGENT_CONFIGURATION (optional) > >>>>>> - BASE_SET_DEVICE_PERMISSIONS (optional) > >>>>>> > >>>>>> The SCI SCMI SMC multi-agent driver implements following > >>>>>> functionality: > >>>>>> - The driver is initialized from the Xen SCMI container ``xen_scmi_config`` > >>>>>> (compatible ``xen,sci``) placed under ``/chosen/xen``. Only the > >>>>>> ``arm,scmi-smc`` node that is a child of this container will bind to Xen; > >>>>>> other SCMI nodes (for example under ``/firmware``) are ignored to avoid > >>>>>> stealing the host OSPM instance. > >>>>>> > >>>>>> scmi_shm_1: sram@47ff1000 { > >>>>>> compatible = "arm,scmi-shmem"; > >>>>>> reg = <0x0 0x47ff1000 0x0 0x1000>; > >>>>>> }; > >>>>>> scmi_xen: scmi { > >>>>>> compatible = "arm,scmi-smc"; > >>>>>> arm,smc-id = <0x82000003>; <--- Xen management agent smc-id > >>>>>> #address-cells = < 1>; > >>>>>> #size-cells = < 0>; > >>>>>> #access-controller-cells = < 1>; > >>>>>> shmem = <&scmi_shm_1>; <--- Xen management agent shmem > >>>>>> }; > >>>>>> > >>>>>> - The driver obtains Xen specific SCMI Agent's configuration from the > >>>>>> Host DT, probes Agents and builds SCMI Agents list. The Agents > >>>>>> configuration is taken from "scmi-secondary-agents" property where > >>>>>> first item is "arm,smc-id", second - "arm,scmi-shmem" phandle and > >>>>>> third is optional "agent_id": > >>>>>> > >>>>>> / { > >>>>>> chosen { > >>>>>> xen { > >>>>>> ranges; > >>>>>> xen_scmi_config { > >>>>>> compatible = "xen,sci"; > >>>>>> #address-cells = <2>; > >>>>>> #size-cells = <2>; > >>>>>> ranges; > >>>>>> > >>>>>> scmi_shm_0: sram@47ff0000 { > >>>>>> compatible = "arm,scmi-shmem"; > >>>>>> reg = <0x0 0x47ff0000 0x0 0x1000>; > >>>>>> }; > >>>>>> > >>>>>> /* Xen SCMI management channel */ > >>>>>> scmi_shm_1: sram@47ff1000 { > >>>>>> compatible = "arm,scmi-shmem"; > >>>>>> reg = <0x0 0x47ff1000 0x0 0x1000>; > >>>>>> }; > >>>>>> > >>>>>> scmi_shm_2: sram@47ff2000 { > >>>>>> compatible = "arm,scmi-shmem"; > >>>>>> reg = <0x0 0x47ff2000 0x0 0x1000>; > >>>>>> }; > >>>>>> > >>>>>> scmi_shm_3: sram@47ff3000 { > >>>>>> compatible = "arm,scmi-shmem"; > >>>>>> reg = <0x0 0x47ff3000 0x0 0x1000>; > >>>>>> }; > >>>>>> > >>>>>> scmi-secondary-agents = < > >>>>>> 0x82000002 &scmi_shm_0 0 > >>>>> 0x82000002 is the same func_id as... > >>>>> > >>>>> > >>>>>> 0x82000004 &scmi_shm_2 2 > >>>>>> 0x82000005 &scmi_shm_3 3>; <--- func_id, shmem, agent_id > >>>>>> #scmi-secondary-agents-cells = <3>; > >>>>>> > >>>>>> scmi_xen: scmi { > >>>>>> compatible = "arm,scmi-smc"; > >>>>>> arm,smc-id = <0x82000002>; <--- Xen management agent func_id > >>>>> as the one used for Xen. This cannot be right? > >>>>> > >>>> That's right. Here should be 0x82000003. > >>>>>> #address-cells = <1>; > >>>>>> #size-cells = <0>; > >>>>>> #access-controller-cells = <1>; > >>>>>> shmem = <&scmi_shm_1>; <--- Xen management agent shmem > >>>>>> }; > >>>>>> }; > >>>>>> }; > >>>>>> }; > >>>>>> }; > >>>>>> > >>>>>> / { > >>>>>> /* > >>>>>> * Host SCMI OSPM channel - provided to the Dom0 as is if SCMI > >>>>>> * enabled for it, ignored by Xen multi-agent mediator > >>>>>> */ > >>>>>> scmi_shm: sram@47ff0000 { > >>>>>> compatible = "arm,scmi-shmem"; > >>>>>> reg = <0x0 0x47ff0000 0x0 0x1000>; > >>>>>> }; > >>>>> this is the same as &scmi_shm_0 which I guess is intended? > >>>>> > >>>> it is. to match Host DT. > >>>>>> firmware { > >>>>>> scmi: scmi { > >>>>>> compatible = "arm,scmi-smc"; > >>>>>> arm,smc-id = <0x82000002>; <--- Host OSPM agent smc-id > >>>>> but this again is the same smc-id meant to be used by Xen. > >>>>> > >>>>> If 0x82000002 is the privileged interface, then it is OK for Xen and > >>>>> also baremetal Linux to use it, but Linux Dom0 should not be using it? > >>>>> Or is the smc-id interchangeable and not necessarily tied to the > >>>>> agent-id? > >>>>> > >>>>> I think either way this detail should be clarified in the docs. Speaking > >>>>> of docs, the next patch introducing the doc is not up-to-date with this > >>>>> patch. > >>>>> > >>>> In my current configuration, I have the following setup: > >>>> > >>>> The Xen privileged interface operates through func_id 0x82000003. > >>>> func_id 0x82000002 is used for Domain-0, in order to keep the Device > >>>> Tree (DT) consistent between Xen and bare-metal configurations. > >>>> I am unsure how best to document this, since the implementation does > >>>> not strictly require this specific configuration and allows flexibility > >>>> for the > >>>> end user. My intention is to provide an example configuration in the DT > >>>> examples that is most likely to be used as a reference for real-world > >>>> setups. > >>> Yes, I am aligned with that > >>> > >>> > >>>> At this stage, I believe the most appropriate approach is to include a note > >>>> in the documentation stating that the examples illustrate a configuration > >>>> that aligns well with the Xen architecture, but other configurations are > >>>> possible depending on user requirements. > >>> Yes. The important detail is to explain that the same configuration > >>> works for both Linux baremetal and Linux Dom0. In the Linux Dom0 case, > >>> the privileged SCMI connection differs from the one of Linux Dom0 and it > >>> is the one used by Xen. > >>> > >>> Baremetal Linux: func_id 0x82000002, scmi-shmem 0x47ff0000 > >>> Dom0 Linux: func_id 0x82000002, scmi-shmem 0x47ff0000 > >>> Xen: func_id 0x82000003, scmi-shmem 0x47ff1000 > >>> > >>> This works because, I am guessing, the privileged SCMI connection is not > >>> tied to func_id 0x82000002, scmi-shmem 0x47ff0000. > >>> > >>> The problem occurs when there can be only one privileged SCMI connection > >>> and it is tied to func_id 0x82000002, scmi-shmem 0x47ff0000 which is the > >>> one described in the Host DT. In which case, Linux Dom0 ends up with the > >>> privileged connection, not Xen. > >>> > >>> I think we should explain why this problem does not occur. > >>> > >>> > >>>>>> #address-cells = < 1>; > >>>>>> #size-cells = < 0>; > >>>>>> shmem = <&scmi_shm>; <--- Host OSPM agent shmem > >>>>>> > >>>>>> protocol@X{ > >>>>>> }; > >>>>>> }; > >>>>>> }; > >>>>>> }; > >>>>>> > >>>>>> This approach allows defining multiple SCMI Agents by adding > >>>>>> Xen-specific properties under the ``/chosen`` node to the Host Device > >>>>>> Tree, leaving the main part unchanged. The Host DT SCMI channel will > >>>>>> be passed to Dom0. > >>>>>> > >>>>>> The Xen management agent is described as a ``scmi_xen`` node under the > >>>>>> ``xen,sci`` comaptible node, which is used by Xen to control other > >>>>>> SCMI Agents in the system. > >>>>>> > >>>>>> All secondary agents' configurations are provided in the > >>>>>> ``scmi-secondary-agents`` property with an optional ``agent_id`` field. > >>>>>> > >>>>>> The ``agent_id`` from the ``scmi-secondary-agents`` property is used > >>>>>> to identify the agent in the system and can be omitted by setting > >>>>>> ``#scmi-secondary-agents-cells = <2>``, so the Secondary Agents > >>>>>> configuration will look like this: > >>>>>> > >>>>>> / { > >>>>>> chosen { > >>>>>> xen { > >>>>>> xen_scmi_config { > >>>>>> compatible = "xen,sci"; > >>>>>> #address-cells = <2>; > >>>>>> #size-cells = <2>; > >>>>>> ranges; > >>>>>> > >>>>>> /* Shared memory nodes as defined earlier */ > >>>>>> > >>>>>> scmi-secondary-agents = < > >>>>>> 0x82000003 &scmi_shm_0 > >>>>>> 0x82000004 &scmi_shm_2 > >>>>>> 0x82000005 &scmi_shm_3 > >>>>>> 0x82000006 &scmi_shm_4>; > >>>>>> #scmi-secondary-agents-cells = <2>; > >>>>>> }; > >>>>>> }; > >>>>>> }; > >>>>>> } > >>>>>> > >>>>>> In this case, Xen will use the ``SCMI_BASE_DISCOVER_AGENT`` call to > >>>>>> discover the ``agent_id`` for each secondary agent. Providing the > >>>>>> ``agent_id`` in the ``scmi-secondary-agents`` property allows skipping > >>>>>> the discovery call, which is useful when the secondary agent's shared > >>>>>> memory is not accessible by Xen or when boot time is important because > >>>>>> it allows skipping the agent discovery procedure. > >>>>>> > >>>>>> Note that Xen is the only one entry in the system which need to know > >>>>>> about SCMI multi-agent support. > >>>>>> > >>>>>> - It implements the SCI subsystem interface required for configuring and > >>>>>> enabling SCMI functionality for Dom0/hwdom and Guest domains. To enable > >>>>>> SCMI functionality for domain it has to be configured with unique supported > >>>>>> SCMI Agent_id and use corresponding SCMI SMC shared memory transport > >>>>>> [smc-id, shmem] defined for this SCMI Agent_id. > >>>>>> - Once Xen domain is configured it can communicate with EL3 SCMI FW: > >>>>>> -- zero-copy, the guest domain puts SCMI message in shmem; > >>>>>> -- the guest triggers SMC exception with smc-id (doorbell); > >>>>>> -- the Xen driver catches exception, do checks and synchronously forwards > >>>>>> it to EL3 FW. > >>>>>> - the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen > >>>>>> management agent channel on domain destroy event. This allows to reset > >>>>>> resources used by domain and so implement use-case like domain reboot. > >>>>>> > >>>>>> Dom0 Enable SCMI SMC: > >>>>>> - pass dom0_scmi_agent_id= in Xen command line. if not provided > >>>>>> SCMI will be disabled for Dom0 and all SCMI nodes removed from Dom0 DT. > >>>>>> The driver updates Dom0 DT SCMI node "arm,smc-id" value and fix up shmem > >>>>>> node according to assigned agent_id. > >>>>> Given that everything else, the entire configuration, is based on device > >>>>> tree, I think it makes sense to also configure this via device tree > >>>>> instead of a command line. > >>>>> > >>>>> This could be another parameter under xen_scmi_config. What do you > >>>>> think? > >>>>> > >>>> The ``dom0_scmi_agent_id`` parameter was introduced to keep the Dom0 > >>>> configuration separate from the xen_scmi_config node, which is intended > >>>> specifically for Xen SCMI configuration. In my opinion, adding Dom0-specific > >>>> configuration to xen_scmi_config would mix the purposes of the node and > >>>> reduce clarity. > >>>> > >>>> Additionally, the ``dom0_scmi_agent_id`` parameter is similar to the > >>>> ``agent_id`` parameter used for arm_sci in xl.cfg. This approach ensures > >>>> that > >>>> the Dom0 configuration is as consistent as possible with the > >>>> configuration for > >>>> other domains. > >>>> > >>>> Overall, I believe this makes the configuration less confusing, as it allows > >>>> us to set similar parameters for both Dom0 and other domains in a clear > >>>> and organized manner. > >>> We are heading in a direction where Dom0 has its own separate domain > >>> node similarly to other Dom0less domains. Many of these changes have > >>> already been committed as part of Hardware Domain / Control Domain > >>> separation work by Jason. > >>> > >>> In a world where Dom0, like other DomUs, has its own configuration node > >>> and also Dom0 can be split between Hardware Domain and Control Domain, > >>> it doesn't make sense to use Dom0 command line options anymore. It is > >>> already possible to assign Dom0 "powers" to a dom0less domain for > >>> example. > >>> > >>> I can see it is worth discussing command line options for dom0 in > >>> situations where Device Tree might not be present (datacenter > >>> configuration on ACPI system) but in this case where Device Tree changes > >>> are required, I think it doesn't make sense to add Dom0 command line > >>> options as they are less flexible and a duplicate of other options we > >>> must have anyway. > >> That makes sense to me. Since we are moving to the Dom0 Device Tree > >> configuration, > >> I can move ``dom0_scmi_agent_id`` inside the ``xen,sci`` node and rename > >> it as the > >> ``agent_id`` property. > >> > >> Would you recommend dropping the ``dom0_scmi_agent_id`` command line > >> parameter > >> entirely, or should I keep it as a backup option? > > I would drop the command line parameter entirely > I would like to add one more observation from my > implementation experience: > > The main difference between Dom0 and dom0less configurations is that, > for dom0less, we have a separate node for each domain, for example: > > Dom0less configuration: > >   xen,domain@1 { >       compatible = "xen,domain"; >       xen,sci_type = "scmi_smc_multiagent"; >       xen,sci-agent-id = <2>; >       /* other domain properties here */ >     }; > > However, for Dom0, we only have the following node: > >   chosen { >     xen { >       ranges; >       xen_scmi_config { >         compatible = "xen,sci"; >         .... >       }; >    }; > }; > > which describes the SCI configuration for Xen. > > Therefore, I believe that using the property name > ``agent_id``` could be confusing in this context. > I suggest naming it xen,dom0-sci-agent-id instead. > > The device tree would then look like this: >   chosen { >     xen { >       ranges; >       xen_scmi_config { >         compatible = "xen,sci"; >         .... >         xen,dom0-sci-agent-id = <0>;  /* Dom0 agent ID */ <----- >       }; >    }; > }; > > Does this approach look good to you? Yes, it look OK. It is already possible to create a dom0less device tree node for Dom0, simply by using capabilities. However, the older device tree bindings where dom0 doesn't have a node is also still supported and for that it makes sense to introduce xen,dom0-sci-agent-id. --8323329-646006288-1768937429=:7192-- From xen-devel-bounces@lists.xenproject.org Tue Jan 20 20:10:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 20:10:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209332.1521378 (Exim 4.92) (envelope-from ) id 1viI3R-0006qf-9N; Tue, 20 Jan 2026 20:10:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209332.1521378; Tue, 20 Jan 2026 20: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 1viI3R-0006qY-5Z; Tue, 20 Jan 2026 20:10:21 +0000 Received: by outflank-mailman (input) for mailman id 1209332; Tue, 20 Jan 2026 20: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 1viI3Q-0006qQ-LX for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 20:10:20 +0000 Received: from CH4PR04CU002.outbound.protection.outlook.com (mail-northcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c105::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 09c6ac1d-f63c-11f0-b15e-2bf370ae4941; Tue, 20 Jan 2026 21:10:18 +0100 (CET) Received: from IA1P220CA0013.NAMP220.PROD.OUTLOOK.COM (2603:10b6:208:464::17) by DS2PR12MB9637.namprd12.prod.outlook.com (2603:10b6:8:27b::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 20:10:13 +0000 Received: from MN1PEPF0000F0E2.namprd04.prod.outlook.com (2603:10b6:208:464:cafe::27) by IA1P220CA0013.outlook.office365.com (2603:10b6:208:464::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9520.13 via Frontend Transport; Tue, 20 Jan 2026 20:10:13 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by MN1PEPF0000F0E2.mail.protection.outlook.com (10.167.242.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Tue, 20 Jan 2026 20:10:12 +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; Tue, 20 Jan 2026 14:10:12 -0600 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 20 Jan 2026 12:10:12 -0800 Received: from [192.168.244.38] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Tue, 20 Jan 2026 14:10:12 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 09c6ac1d-f63c-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fbWqCUrVUO9VgfMOQ2hU2CeMda8xcBgdJa+t8ba4tttxJWmHDrjhW/K8xmRdvt8j1P0Zn9SqBr8ofARUGKN3Y2yPv2eA8HSDECcXocev70C4Cj7j4hWuafrCJvj2LjgxZAnkhBEcehEijxn92zKvGhtc5TgShll/lbLBnbvTdbNxRU33sHsH9m7yCsBewpRH4BSn1iTtjukSpMadARNeyPd8wfXAjTGZ5ZW+/Q8r+lkgNcHZBuH9YXCe1b3gpAjm2x6DtejXwU4PTmlozbUi8tksaJ5n6LDS9ps4Sl00XwEMpsfrtunoowkOdYlygPbwqq9g8MYkkdUTimmyz1Sa7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aRwN2pwTFxG1BFiT1VepMXbP6XJ/Yt99EVG8jEO6EQw=; b=PJ8IhuzWMRTMew0N7OLDp8FEkT+Hz2g0/mH3kNCPp+StgKd9Qqw4OEvJUD0ZRwn2JzoeRiZwQedGb32Uf62xKywRkvQQlp3yJXcYI6OMxR35dmKAVqfulkrFKrFGFxZ5AkMmUvE9Vm2b/hbdL2ZIYPMSRWHlPl/Z5w20OtS9jqyyqZrQUlP2aNNBu+0xzSFsINZ1ZNNTf4LASaB/BDgg8UVeN4XVFUXlY/rJVvZk/HHDQr/6veTH6kgzA1xUJ7T2Cpp6EVulpQVJVawvo25jlr6gvQhgNxd9OwZ+khpb084B+W5QteJN0z4DelYYGxtiPwC2kXWW2QeqKd5Hzhp8GA== 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=aRwN2pwTFxG1BFiT1VepMXbP6XJ/Yt99EVG8jEO6EQw=; b=NhN/rwcJaxAdpmB0+Vn5WyaLHP6b7bs5xFldTMvQeXd2xpEdkwSjaqJjjDfAKBuBQKKBHiGBvthANVL5uHkNaLe7mWpar0Hv1gO8vOjMsvOv6Vjhb0VUhY3oejWoBZLHyJwXWXTqGVGgmmvQpDA8loQSXreRWKVgXP/8AOxwx+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 Message-ID: Date: Tue, 20 Jan 2026 15:10:06 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Partial revert "x86/xen: fix balloon target initialization for PVH dom0" To: Roger Pau Monne , , CC: James Dingwall , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko References: <20260120140648.25977-1-roger.pau@citrix.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <20260120140648.25977-1-roger.pau@citrix.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN1PEPF0000F0E2:EE_|DS2PR12MB9637:EE_ X-MS-Office365-Filtering-Correlation-Id: 723c8ece-fbeb-4e02-f8db-08de585feb8c 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?MmxNLzNsZVI5TmJjSlJzdWpsajBmUGc5WS9vVWpVL3h5QWE5REl0c3I0Mk5s?= =?utf-8?B?ZytLaUJDN1NNbGZIT2JNZ0Z5NTc5UGRIc0hObWxqYXBOa0tGajZwOEh5TVlo?= =?utf-8?B?L2w0cTVrc2MyeDF5Rm5EaHRmckNva0IybG5NYytBL1hJUjVEMFY5TkJPbSt0?= =?utf-8?B?UDArdHZFelRld0dkeGFFZkV3akRCeTIzL3A4OWs5dmNCY1l0NFFQdGc0d1FN?= =?utf-8?B?aXBqVEl0THhPVXpwRlk5YWF2T1FPNG9KaWc5S1k4cExpeHpoajUwY09jT1VD?= =?utf-8?B?dzZYMHdwRlVFNDk5UzN0OVQ1OGRhWUhLNVlXcTRhNEF3TkM5RUE3SUoxNDJB?= =?utf-8?B?cit3dkY4ODVzRUo3ZXJka0RXMXQ4VHRtZUFXS0VLVlNZbEdxNHM3MTdDUEN6?= =?utf-8?B?ZndacmFyNVc2UkJ0dXlMbnNTM1JEajRPU04rbHgxSiswWEJvVjNhT3JnY2Vx?= =?utf-8?B?ays1TSt6ZEVYbTloQzJNY2xrcUxWbVZZWE93WmxEMTc5SzhzSGI3bTR6ZjVB?= =?utf-8?B?TWRZWURIUFJLb2x4WWRrQkRNUTdreERMbjgwVnRweUxyY2RLMVdpRHRwQ29J?= =?utf-8?B?OGFJbEwzbS9IbHQwSWFadDFhNHFyR2MxKy9wOGN5b3hVSUgwY0xFc1RXWkht?= =?utf-8?B?K0xsbXd3VHJMUmxHRC9GVlZYaURoQUN1eEVZLzBvMnZ2MGJPaTIwalNSQ1VB?= =?utf-8?B?Z0xodVZ6NlFmdWxaa3VvQVQyYzMzZElIWDFuTHRod0RhWCtFSmpLdVhjNWt1?= =?utf-8?B?VWc2WE1sZjdRK21NQTlYSklpWmZKRTJiSTZuQWE5TzBGcno2K1RJdklRWjZE?= =?utf-8?B?bEhDdEFqOVNoSVFWMjdkckZab09tV1c4WFQ0RXRKdmV6U1h2eEZaR3ZsUFl4?= =?utf-8?B?blJyUEVDWDVjWEJpUzlma2V1NE56ZWNCSFphOFJuOUNoYTJtWlc5Mkw4YXhy?= =?utf-8?B?a2wrYVU2VUZLaExpLy9NcTFIeDhncVhnREx4NmthcFZWb0ZmVk9VWFhWcnBK?= =?utf-8?B?ajdDYTNLSHVaZXpaK1l2aEdXK2V3b0tpbzhYSW1VZlVjU3JiTFplYTJNWVk3?= =?utf-8?B?TmxRdkdVb25iKzE4elhvVnJnMlZVcUQvSG5Ebm5wTVk3RC9FZzVVMjVQTkVk?= =?utf-8?B?bHZJS1pteThKcW9uUWkxTGRLaHc3VTVuaDFJU2UzelFNeThGNjdKeVRkOVJL?= =?utf-8?B?Mkp4VmV3ZWtuWk9wdE84QlBsL0NXVS9EcXAySWcwZjJFQ3FPaXFoNGZRNS9C?= =?utf-8?B?cDNXcXVtUml2Rk9uQUNRY3BlZWl3alErRVhVNkJTSUNNdzR4UzZENUVTNi9N?= =?utf-8?B?WmFJVHlkUWtLUFptdDM4SDNBTk8xUmJINWFsdnhTQ0k4SkRaR3pxbkJhYlJ2?= =?utf-8?B?eTJaekZUYzFsUklmN3FLSnJmL0puT1BEL3Z2dXRESUJqejdHMXJ4NVc5cUdW?= =?utf-8?B?a0dxL0tTY1hZR0ZPK05VSDlFa2c4VEZjV1QxSlNEQ1d4QUpoc0tZUThDVTIr?= =?utf-8?B?cEpWb3A3dXBJUndFSnFxRzFBQjUwTkh0disxWHp6bjhadXZDUFNWNSsxSmFq?= =?utf-8?B?aU42VFlhdmtLYVdqc3Q3dWVUL2g4QWVjcGtFZ3liVmt6VU5zQlRnTVNYdWk4?= =?utf-8?B?N01FbWVPS0xwYm1iek5FNjJERnBpN3d2Mi9qNlpzY0g0aW1iTFlGM0YzMzFS?= =?utf-8?B?K2VuYnJuS1VSbFBPTDdQUlZlMStYQmRwQzRPUlpJUzlXRUFBa0lwRUVxVXBy?= =?utf-8?B?WmV1eXkydVlGTXhMRXpjdEViUU8yWDVSUzZlaVJxMjBaVHFqbi9aWHBjVjV6?= =?utf-8?B?NS9RamtqSkRQOU9PZkdrNzkrUkw1Y1A4WHdnKzFOcG9uV2hLZ0VpcTBnSjlB?= =?utf-8?B?UkpNcWpGKytBUU91cGJRdXdmWXBqWVl1NjEzNisyZllPc3VORkk3YU9aMW9E?= =?utf-8?B?czd3UGxSRHlySEZCWnRwZ2R1T1dCNld4cmQvZFhibE9TRVpZNEJkanRFS25H?= =?utf-8?B?Y1kzcjNPcVY3RVluTm5FSDFxbnAweTRFKzlSLzdKNlRHMEtDNVBzcXVVQXk1?= =?utf-8?B?bXlQeEpva0dIdWw4YnZvY2xXVmYycVdHZFJCbW9vMHhFeVpWeXd4bW9qUXBp?= =?utf-8?B?QXN3V1dhLy95YldGdmxWU2QzclRVWjZxbUwxbkUvaWxBdmtEMGdCaTBWSFRN?= =?utf-8?B?UVp1cEpaZkkvSkJiTXArczJTMzZtdnVMNk1EcVBnR2VsVEN4ODN3UTVpRERM?= =?utf-8?B?OWZmR1dMeWZHZDR3a1cwYUs1WmpnPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(376014)(36860700013)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 20:10:12.9853 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 723c8ece-fbeb-4e02-f8db-08de585feb8c X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: MN1PEPF0000F0E2.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS2PR12MB9637 On 2026-01-20 09:06, Roger Pau Monne wrote: > This partially reverts commit 87af633689ce16ddb166c80f32b120e50b1295de so > the current memory target for PV guests is still fetched from > start_info->nr_pages, which matches exactly what the toolstack sets the > initial memory target to. > > Using get_num_physpages() is possible on PV also, but needs adjusting to > take into account the ISA hole and the PFN at 0 not considered usable > memory depite being populated, and hence would need extra adjustments. > Instead of carrying those extra adjustments switch back to the previous > code. That leaves Linux with a difference in how current memory target is > obtained for HVM vs PV, but that's better than adding extra logic just for > PV. > > Also, for HVM the target is not (and has never been) accurately calculated, > as in that case part of what starts as guest memory is reused by hvmloader > and possibly other firmware to store ACPI tables and similar firmware > information, thus the memory is no longer being reported as RAM in the > memory map. > > Reported-by: James Dingwall > Signed-off-by: Roger Pau Monné Reviewed-by: Jason Andryuk Thanks, Jason From xen-devel-bounces@lists.xenproject.org Tue Jan 20 22:04:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 20 Jan 2026 22:04:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209351.1521388 (Exim 4.92) (envelope-from ) id 1viJpf-0002iU-4K; Tue, 20 Jan 2026 22:04:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209351.1521388; Tue, 20 Jan 2026 22:04: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 1viJpf-0002iN-18; Tue, 20 Jan 2026 22:04:15 +0000 Received: by outflank-mailman (input) for mailman id 1209351; Tue, 20 Jan 2026 22:04:13 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viJpd-0002iH-JP for xen-devel@lists.xenproject.org; Tue, 20 Jan 2026 22:04:13 +0000 Received: from CY3PR05CU001.outbound.protection.outlook.com (mail-westcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c112::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f21d6194-f64b-11f0-9ccf-f158ae23cfc8; Tue, 20 Jan 2026 23:04:10 +0100 (CET) Received: from BN9PR03CA0147.namprd03.prod.outlook.com (2603:10b6:408:fe::32) by SN7PR12MB7299.namprd12.prod.outlook.com (2603:10b6:806:2af::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Tue, 20 Jan 2026 22:04:05 +0000 Received: from BN2PEPF0000449D.namprd02.prod.outlook.com (2603:10b6:408:fe:cafe::7d) by BN9PR03CA0147.outlook.office365.com (2603:10b6:408:fe::32) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.9 via Frontend Transport; Tue, 20 Jan 2026 22:04:02 +0000 Received: from satlexmb08.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_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Tue, 20 Jan 2026 22:04:05 +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; Tue, 20 Jan 2026 16:04:01 -0600 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 20 Jan 2026 16:04:01 -0600 Received: from [192.168.244.38] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Tue, 20 Jan 2026 16:04:01 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f21d6194-f64b-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=G2KzZ0Jv8hb7SJ/gN9vshAlVokMB9v5cLCw7cly7oHKx+P2cGEIc7u5cgalhxAY5Oos87yBXPPR44AV9mICs5w+3wzWJj5D4+sX/XP/Cb8PRa69/7zXBrudyXJYxbpJZoskNB1jvd47F9vfUuv3gZhPZoa4VWj/GIVoCmcMUUO+BD4C6vTTNOZ8DrpWx0AZRPwuU45JIiHy595Ex/uMPHyrKJPvtBTItclvuH270Vjp40fMYmKWivjXZnE+gvIAm6u4CS6ll1Hz3FGa2RES0PUktvkRcaHxICcdAhWvhYfDewUeUYduZK6yayaJdalL8nF6TOnWSR4aJgHz1XFm4lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2CZ1dnt1lNwrbVox00zyWzt2jGmgrmLLiOCyztI1bBI=; b=ZfYzV0MsJtwxW+oNbEv5wrPohec1yvevYvKTdXRfrPo3cH3VKxLCdb+G+/tyb9ojIImtWhPVbatO/4OHGqAhPryzSxLEHE3sng20xe61ELu+YUyGV9qWonZ3CkXa+8SagQpGD7Nv3d7xWRmfHh7VanPKuvHpjhEL1W8QuIBICQLn05EA4gEH+4w5uErfTuRmnytqdJTX4R7I+Dg6SqLhE4IGLXNz9EibjYFcWx7mg2LTOoTlYdu+tPg56IGF0uu/dOKqBi4QvpToFsBTYhrR3mrlUHhMvEBQTY9ES5qfq3qRwpMePMAzf0TuDW4FRHkuZoluVgfv1eaaJBm61jp4Gw== 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=2CZ1dnt1lNwrbVox00zyWzt2jGmgrmLLiOCyztI1bBI=; b=akwJP73T3yKmzcrIiL686vzUCDByWKEgKL2kdDREPEYTqjevTPzNVfaTe9qZysJ2ZBztdjRFmhNOFUxDtgkp1Xd6HWQtZkLYGr2x10y2hREMED/5iunN5ayN7xJwON9RPoYCMFcd67u1bzZMfQ5Kg5hPM/a5iVCAkx7EAg/iHJc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <57308b26-8a52-4914-a0f4-7fb8446252ad@amd.com> Date: Tue, 20 Jan 2026 17:04:00 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Strange symbols_lookup() behaviour in test-symbols on arm64 CI To: Jan Beulich , Mykola Kvach CC: Xen-devel , Volodymyr Babchuk References: <10aaed6d-6cb1-4bed-aa8c-5f9761f04fde@suse.com> <35819233-07ba-4e00-8939-74b2f4454250@suse.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: BN2PEPF0000449D:EE_|SN7PR12MB7299:EE_ X-MS-Office365-Filtering-Correlation-Id: 58f05c4a-f9fb-46a7-1946-08de586fd415 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|36860700013|82310400026|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?RmlNKys4T3ZTdEhiVW9WZ082UndzTnhuRVE4MitPbWFxSEZXdVQ3Zkx6SjJ3?= =?utf-8?B?ekJ4RnpHVVVRdDYxMktSeTF5WEd5aTBFRERGKzNLZVgvckFOc0UzK0pzckdW?= =?utf-8?B?T0ZGb052R2Mya0doTE1VL0gybE44RWhScTJLU0M3ZEpNT0dBeWJyQUtoYWh1?= =?utf-8?B?bTVDSW03a3h6cWNDQ0pNK0p1M1p6VGQzcnVwYWhRN1pvVVhoZEUxT3hod056?= =?utf-8?B?TFlDQ1c2Y0pQU3VibHZIYThHVzMwaVlPbS80WU5xM1dHQjlCZ2RxS3FsVHF4?= =?utf-8?B?Q3VCb3huZkwzMzFCTnoyL0dUQVhtZnNBV0RrQ295UHdEZmNiZW5MTzVmZTVP?= =?utf-8?B?dVFqeFNjZFlLMjN4cHB3d3RVMkdsVXZydkx0LzRJVnZic1Znb0hKeCtZc1oz?= =?utf-8?B?VCtRZkNIaHVqYW4zbnFseGNiS3RPdHpFZXpQaVgweGhEZDhKdk51VzZTVC9r?= =?utf-8?B?V0cwenJoVnpITzJSOVN1TUUxV2t4cFFVRnU4bW9UVGxRZmxlOFhHaWVsaVBr?= =?utf-8?B?L0M4SDlZRS9OdmxIOVY5VnJxb00rdXB2UGFJTWpaNUhCaE56N0w2eFp1VmJl?= =?utf-8?B?bkRmNTVEM3lRd3kxVXRuWVg1S25zWk1DUU45ajFBREF4eURmWUJmVG92UXU1?= =?utf-8?B?SlE3OGVqTUQwcElnenR3Vy84OTc3WkdVY1gyOHhHbXVQdHh5TGNOaFN4U0J4?= =?utf-8?B?VkEzWW02ZnliQ0p5ako4dmx6dUppYzRYV2NzcmdCVzVtNlRUT01xUEM0aDBq?= =?utf-8?B?RWdhTVBUYTJsRUtqT1N1RzdHVFJMdDh1SEZOWEJPQk9QZ3U5U3YrbVdKVnJS?= =?utf-8?B?Lzc3a0VxS3NqTWFqcmdDOWhYZHpiZGxQaW1hc0RIMU9sSHV3MWFpZGgzL0or?= =?utf-8?B?S1F3SzFvTUc4d2Q2cHltaG5jS3cyZzRCTTJnS3ZVUlpON2k4b3BESnVseE1N?= =?utf-8?B?Wmd0ZENSSzFkdWY2cldwczlzczlBZWg5Zi9adVRwRjR4ZXJrOVhwcUVyUXZK?= =?utf-8?B?cUFUL0VvTWxiT2dwQTJlbExVK2djbm9OaFoxNFBYUFdKM3lPTDdOVWo5UGx4?= =?utf-8?B?dFNDQ0VIVmd5MEFqSkxURUx2SFRsbUdkUzNjeTJrNHRqMUJRU3FZMFYyZnZ6?= =?utf-8?B?UW9mZzh5SElUZVdHQWllbnJmV0gxK0tOSEJjMUlOZHFJZmkwSzdPcUhBZ0kv?= =?utf-8?B?Rmt4UmxxVFlZanFkaEZqR0dpT2hIUGNabzRla3dFdk1tMHE1YjFTT0FMU1Mw?= =?utf-8?B?NFlGRytLMU1iQStkZ3BDOVFEQ1VHbXlKcUNCN1UwNHV0bG1WWnd6VWI4bzY5?= =?utf-8?B?MitEOWJlTldjS09YZjZVNENBVVBWbmJEa3psL0NaazcycVcyOGZjcnhydXVE?= =?utf-8?B?dDZURHpwdzZBWUVDQUdZdFpuTHEvQ2pDYXp1RE5XMVk3VWVXT3VtSzNBRFkw?= =?utf-8?B?K0lPKytUL3JSdklaMDVVMXNVYk5TR0I3ZzdNdGhtSWszejRzekdwVW42ZEZG?= =?utf-8?B?MlIwQ2s0RldtUjlxVDA0M3RrY1VCd0xtbDRhV08yQ1F1eFBCTFNQSXlCVVUr?= =?utf-8?B?TVNscWhHUmNncFl6V0ZvVEJxaGVONGdQQno4WmNxTWJNcFNmTC8vVWs5aWgv?= =?utf-8?B?cVdZV2F2Q09MT1FxUXhxRmJEZU9jVlZIdGR6M3M1ZTdnSWtleWNyMDBSSlFW?= =?utf-8?B?U1UzNFZhNXp6RkJ4L1lSSnp3MmxzeEltakV5U0crMTZUYU1rbTNIL1Y4NEtL?= =?utf-8?B?clh5RitiWHBRRHc3TW5oMERKdGpDQ1BQQW82L0xjNFA5Yk0vWHd0U1lyS2Ew?= =?utf-8?B?dW5vOVM5RGducXBtdjhyUjF4dk1xV25TcGE0VmdLdHhZZmpNZjZaVmpEYkdy?= =?utf-8?B?cHpaQ1NlYmRwMTV3N1c0d1NvN2VYb3ZieHNUNTc1SFRLR2Z2MTlLamNodU9E?= =?utf-8?B?Y0d5amRkMGVMM1hPQ1BoNTl0QzRZdTNUbGR5dFlFUzJCdS9UY0ZzcHdIY2NY?= =?utf-8?B?WGJRbXJSTzU4MURjWE5LOEFUcHZlbWpDOCtmN2FNVzBBRzVUdjY5cEFIOURT?= =?utf-8?B?ZWZMcWVrL1ZzQSs4ZXZaVEV1Vm1URHBCVC95cE5KRGtVTkovc24yVWp5RXNa?= =?utf-8?B?bUxDWWlnQ09wS1JtSzBHQ2VvRTZTbUdtSnRkc3ZzK005RHNrZXYzRk0xaXZo?= =?utf-8?B?WHBWSEtBOEt2dnBOYmRBNnVmb0grVTRHVmgwdnNJSmNmNThqeFhCRktZbTBw?= =?utf-8?Q?phRWY2xsQGeZzjB9pFV0ZYEr4Df7s8t1OjtluAvpVA=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(36860700013)(82310400026)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2026 22:04:05.5542 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 58f05c4a-f9fb-46a7-1946-08de586fd415 X-MS-Exchange-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: BN2PEPF0000449D.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB7299 On 2026-01-15 11:57, Jan Beulich wrote: > On 15.01.2026 16:33, Jan Beulich wrote: >> On 14.01.2026 07:00, Mykola Kvach wrote: >>> On Mon, Dec 15, 2025 at 1:27 PM Jan Beulich wrote: >>>> On 15.12.2025 12:00, Mykola Kvach wrote: >>>>> On Thu, Dec 11, 2025 at 6:40 PM Jan Beulich wrote: >>>>>> On 11.12.2025 17:30, Mykola Kvach wrote: >>>>>>> I have now attached the corresponding build log. >>>>>> >>>>>> Okay, so indeed not a table size change issue here. Then I fear some instrumenting >>>>>> will be needed to at least know what exactly is going wrong. Alternatively you could >>>>>> arrange for the intermediate binaries to not be deleted, and make them available >>>>>> somehow / somewhere for me to see whether by inspection I can gain some clue. >>>>> >>>>> I prepared a small patch to keep the intermediate artifacts instead of >>>>> deleting them. >>>>> >>>>> It removes two cleanup commands: >>>>> xen/arch/arm/Makefile: drops rm -f $(@D)/.$(@F).[0-9]* (keeps >>>>> .xen-syms.* intermediates) >>>> >>>> This alone should be sufficient. >>> >>> Understood. I have rerun the build with the cleanup line removed >>> so the intermediate .xen-syms.* files are kept. >>> >>> The build artifacts are available here: >>> https://gitlab.com/xen-project/people/mykola_kvach/xen/-/jobs/12707528457/artifacts/browse/xen/ >> >> Apart from the intermediate files there's a file named xen there, but xen-syms >> is missing. I'll see what I can do without that. > > Actually, can you give the patch below a try? That would explain the 24-byte > difference (albeit I'm struggling with some other aspects of a proper > explanation). I had qemu-smoke-dom0less-arm32-gcc-debug-staticmem fail in CI with: test_symbols: non-zero offset (0x48c) unexpected https://gitlab.com/xen-project/people/jandryuk-amd/xen/-/jobs/12787541697 With your patch added on top, it passed: https://gitlab.com/xen-project/people/jandryuk-amd/xen/-/jobs/12788189122 Tested-by: Jason Andryuk The branch includes --gc-sections and associated changes, fwiw. Thanks, Jason > > --- a/xen/arch/arm/Makefile > +++ b/xen/arch/arm/Makefile > @@ -87,13 +87,13 @@ endif > $(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds > $(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S > $(MAKE) $(build)=$(@D) $(dot-target).0.o > - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< \ > + $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ > $(dot-target).0.o -o $(dot-target).0 > $(NM) -pa --format=sysv $(dot-target).0 \ > | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ > > $(dot-target).1.S > $(MAKE) $(build)=$(@D) $(dot-target).1.o > - $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< \ > + $(LD) $(XEN_LDFLAGS) -T $(obj)/xen.lds $< $(build_id_linker) \ > $(dot-target).1.o -o $(dot-target).1 > $(NM) -pa --format=sysv $(dot-target).1 \ > | $(objtree)/tools/symbols $(all_symbols) --sysv --sort \ > From xen-devel-bounces@lists.xenproject.org Wed Jan 21 00:07:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 00:07:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209368.1521398 (Exim 4.92) (envelope-from ) id 1viLkh-0000Gp-Pl; Wed, 21 Jan 2026 00:07:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209368.1521398; Wed, 21 Jan 2026 00:07:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viLkh-0000Gi-NE; Wed, 21 Jan 2026 00:07:15 +0000 Received: by outflank-mailman (input) for mailman id 1209368; Wed, 21 Jan 2026 00:07:14 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viLkg-0000GX-5W for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 00:07:14 +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 213132a8-f65d-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 01:07:10 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 1D1EC4088D; Wed, 21 Jan 2026 00:07:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9F533C16AAE; Wed, 21 Jan 2026 00:07:07 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 213132a8-f65d-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768954029; bh=L0X3vSYqtAqnjQdqjelUxd34olRrSKja0RM8RlVgAME=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=g6NOfqVCeAuDfsrPoPgEywU1x340Xk8SKqgmiSyGq7ny6hKQ1lUBvoOSPwtiDb68e FW2arWXs0Vmn9A4ZOOsD2IXQLyS1hju7qRc4xyDHObfRrNWwoeDMShyzAcCmwFOj63 Q2hAUdMUAsH92HT8uaOdf35GD1OHagdmDh1UVHPvqW0CP2VT9q005Ftf9Cf8q1erAV 0RxctcDpX//DHdK+5Pp5xCgWSE4qsBo+6ZOCwW41IEbUFUjsZWkNBEEmBSp2/uiC3N 2FQ08ng9AsuziLcWB+4ZzW/AQiGPgfdtsANKY6RQ6d6NBql97JJLLyWMx7FLZghOfV Bo2hJ7/6RtxDA== Date: Tue, 20 Jan 2026 16:07:06 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Jan Beulich cc: Stefano Stabellini , grygorii_strashko@epam.com, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Victor Lira , andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH v3] xen/console: handle multiple domains using console_io hypercalls In-Reply-To: <32d0a9a2-89df-4e20-8f7a-0f069cbff11f@suse.com> Message-ID: References: <63c35c5e-577b-4346-b600-03808306177f@suse.com> <32d0a9a2-89df-4e20-8f7a-0f069cbff11f@suse.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-1619268939-1768953762=:7192" Content-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1619268939-1768953762=:7192 Content-Type: text/plain; CHARSET=US-ASCII Content-ID: On Tue, 20 Jan 2026, Jan Beulich wrote: > On 20.01.2026 00:23, Stefano Stabellini wrote: > > On Mon, 19 Jan 2026, Jan Beulich wrote: > >> On 14.01.2026 01:39, Stefano Stabellini wrote: > >>> @@ -815,6 +831,11 @@ long do_console_io( > >>> if ( count > INT_MAX ) > >>> break; > >>> > >>> + d = console_get_domain(); > >>> + console_put_domain(d); > >>> + if ( d != current->domain ) > >>> + return 0; > >> > >> This isn't atomic (as in: in a suitably locked region) with ... > >> > >>> @@ -830,7 +851,10 @@ long do_console_io( > >>> break; > >>> } > >>> rc += len; > >>> - serial_rx_cons += len; > >>> + nrspin_lock_irq(&console_lock); > >>> + if ( serial_rx_cons != serial_rx_prod ) > >>> + serial_rx_cons += len; > >>> + nrspin_unlock_irq(&console_lock); > >>> } > >>> break; > >> > >> ... this. If the focus domain changes after the check in the earlier hunk, > >> I think you need to also return with no input here. Or you need to acquire > >> the lock earlier (and then similarly in console_switch_input()), albeit > >> that would then mean holding it across a copy-to-guest. Which technically > >> is perhaps not a problem, but it leaves an uneasy feeling. > > > > I thought about it when writing this patch and I had the same feeling as > > you. However, especially considering the other feedback, I don't see > > another viable solution. > > Taking just the logic here, an option might be to re-check the focus domain > once holding the lock, and discard the most recent chunk of input from what > would go back to the caller if the focus changed. But that would come with > its own new complexities. I attempted to make changes on top of v4 so that copy_to_guest_offset is not called with the lock held. I did introduce a focus domain check in the CONSOLEIO_read while loop, but didn't discard input because now the focus domain is only changed with the console_lock held and also the while loop is executed with the console_lock held (except for copy_to_guest_offset) so as far as I can tell it shouldn't be possible that a domain is reading someone else's input data. >From 71de8ddd0ce31090362115a3d54d1ebe161c229f Mon Sep 17 00:00:00 2001 From: Stefano Stabellini Date: Fri, 16 Jan 2026 13:07:43 -0800 Subject: [PATCH v5] xen/console: handle multiple domains using console_io hypercalls Allow multiple dom0less domains to use the console_io hypercalls to print to the console. Handle them in a similar way to vpl011: only the domain which has focus can read from the console. All domains can write to the console but the ones without focus have a prefix. In this case the prefix is applied by using guest_printk instead of printk or console_puts which is what the original code was already doing. When switching focus using Ctrl-AAA, discard any unread data in the input buffer. Input is read quickly and the user would be aware of it being slow or stuck as they use Ctrl-AAA to switch focus domain. In that situation, it is to be expected that the unread input is lost. The domain writes are buffered when the domain is not in focus. Push out the buffer when the domain enters focus. Add the console_lock around serial_rx_prod and serial_rx_cons modifications to protect it against concurrent writes to it. Also protect against changes of domain with focus while reading from the serial. Signed-off-by: Stefano Stabellini --- xen/drivers/char/console.c | 56 ++++++++++++++++++++++++++++++++------ 1 file changed, 47 insertions(+), 9 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 7b176da71a..5c621b39bd 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -521,6 +521,8 @@ struct domain *console_get_domain(void) { struct domain *d; + nrspin_lock_irq(&console_lock); + if ( console_rx == 0 ) return NULL; @@ -540,6 +542,8 @@ void console_put_domain(struct domain *d) { if ( d ) rcu_unlock_domain(d); + + nrspin_unlock_irq(&console_lock); } static void console_switch_input(void) @@ -574,8 +578,12 @@ static void console_switch_input(void) if ( !d->console.input_allowed ) continue; - console_rx = next_rx; printk("*** Serial input to DOM%u", domid); + nrspin_lock_irq(&console_lock); + console_rx = next_rx; + /* Don't let the next dom read the previous dom's unread data. */ + serial_rx_cons = serial_rx_prod; + nrspin_unlock_irq(&console_lock); break; } } @@ -596,8 +604,19 @@ static void __serial_rx(char c) d = console_get_domain(); if ( !d ) + { + console_put_domain(d); return; + } +#ifdef CONFIG_SBSA_VUART_CONSOLE + /* Prioritize vpl011 if enabled for this domain */ + if ( d->arch.vpl011.base_addr ) + { + /* Deliver input to the emulated UART. */ + rc = vpl011_rx_char_xen(d, c); + } else +#endif if ( is_hardware_domain(d) || IS_ENABLED(CONFIG_DOM0LESS_BOOT) ) { /* @@ -613,11 +632,6 @@ static void __serial_rx(char c) */ send_guest_domain_virq(d, VIRQ_CONSOLE); } -#ifdef CONFIG_SBSA_VUART_CONSOLE - else - /* Deliver input to the emulated UART. */ - rc = vpl011_rx_char_xen(d, c); -#endif if ( consoled_is_enabled() ) /* Deliver input to the PV shim console. */ @@ -729,6 +743,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, unsigned int flags = opt_console_to_ring ? CONSOLE_ALL : CONSOLE_DEFAULT; struct domain *cd = current->domain; + struct domain *input; while ( count > 0 ) { @@ -741,17 +756,23 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, if ( copy_from_guest(kbuf, buffer, kcount) ) return -EFAULT; - if ( is_hardware_domain(cd) ) + input = console_get_domain(); + if ( input && cd == input ) { + if ( cd->pbuf_idx ) + { + console_send(cd->pbuf, cd->pbuf_idx, flags); + cd->pbuf_idx = 0; + } /* Use direct console output as it could be interactive */ - nrspin_lock_irq(&console_lock); console_send(kbuf, kcount, flags); - nrspin_unlock_irq(&console_lock); + console_put_domain(input); } else { char *kin = kbuf, *kout = kbuf, c; + console_put_domain(input); /* Strip non-printable characters */ do { @@ -793,6 +814,7 @@ long do_console_io( { long rc; unsigned int idx, len; + struct domain *d; rc = xsm_console_io(XSM_OTHER, current->domain, cmd); if ( rc ) @@ -813,6 +835,13 @@ long do_console_io( if ( count > INT_MAX ) break; + d = console_get_domain(); + if ( d != current->domain ) + { + console_put_domain(d); + return 0; + } + rc = 0; while ( (serial_rx_cons != serial_rx_prod) && (rc < count) ) { @@ -822,14 +851,23 @@ long do_console_io( len = SERIAL_RX_SIZE - idx; if ( (rc + len) > count ) len = count - rc; + + console_put_domain(d); if ( copy_to_guest_offset(buffer, rc, &serial_rx_ring[idx], len) ) { rc = -EFAULT; break; } + d = console_get_domain(); + if ( d != current->domain ) + { + console_put_domain(d); + break; + } rc += len; serial_rx_cons += len; } + console_put_domain(d); break; default: rc = -ENOSYS; -- 2.25.1 --8323329-1619268939-1768953762=:7192 Content-Type: text/x-diff; NAME=incremental.patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME=incremental.patch ZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL2NoYXIvY29uc29sZS5jIGIveGVu L2RyaXZlcnMvY2hhci9jb25zb2xlLmMNCmluZGV4IGFjZmM0OWQ1NTguLjVj NjIxYjM5YmQgMTAwNjQ0DQotLS0gYS94ZW4vZHJpdmVycy9jaGFyL2NvbnNv bGUuYw0KKysrIGIveGVuL2RyaXZlcnMvY2hhci9jb25zb2xlLmMNCkBAIC01 MjEsNiArNTIxLDggQEAgc3RydWN0IGRvbWFpbiAqY29uc29sZV9nZXRfZG9t YWluKHZvaWQpDQogew0KICAgICBzdHJ1Y3QgZG9tYWluICpkOw0KIA0KKyAg ICBucnNwaW5fbG9ja19pcnEoJmNvbnNvbGVfbG9jayk7DQorDQogICAgIGlm ICggY29uc29sZV9yeCA9PSAwICkNCiAgICAgICAgICAgICByZXR1cm4gTlVM TDsNCiANCkBAIC01NDAsNiArNTQyLDggQEAgdm9pZCBjb25zb2xlX3B1dF9k b21haW4oc3RydWN0IGRvbWFpbiAqZCkNCiB7DQogICAgIGlmICggZCApDQog ICAgICAgICByY3VfdW5sb2NrX2RvbWFpbihkKTsNCisNCisgICAgbnJzcGlu X3VubG9ja19pcnEoJmNvbnNvbGVfbG9jayk7DQogfQ0KIA0KIHN0YXRpYyB2 b2lkIGNvbnNvbGVfc3dpdGNoX2lucHV0KHZvaWQpDQpAQCAtNTk4LDExICs2 MDIsMTAgQEAgc3RhdGljIHZvaWQgX19zZXJpYWxfcngoY2hhciBjKQ0KICAg ICBpZiAoIGNvbnNvbGVfcnggPT0gMCApDQogICAgICAgICByZXR1cm4gaGFu ZGxlX2tleXByZXNzKGMsIGZhbHNlKTsNCiANCi0gICAgbnJzcGluX2xvY2tf aXJxKCZjb25zb2xlX2xvY2spOw0KICAgICBkID0gY29uc29sZV9nZXRfZG9t YWluKCk7DQogICAgIGlmICggIWQgKQ0KICAgICB7DQotICAgICAgICBucnNw aW5fdW5sb2NrX2lycSgmY29uc29sZV9sb2NrKTsNCisgICAgICAgIGNvbnNv bGVfcHV0X2RvbWFpbihkKTsNCiAgICAgICAgIHJldHVybjsNCiAgICAgfQ0K IA0KQEAgLTY0MCw3ICs2NDMsNiBAQCBzdGF0aWMgdm9pZCBfX3NlcmlhbF9y eChjaGFyIGMpDQogICAgICAgICAgICAgICAgICAgICAgcmMpOw0KIA0KICAg ICBjb25zb2xlX3B1dF9kb21haW4oZCk7DQotICAgIG5yc3Bpbl91bmxvY2tf aXJxKCZjb25zb2xlX2xvY2spOw0KIH0NCiANCiBzdGF0aWMgdm9pZCBjZl9j aGVjayBzZXJpYWxfcngoY2hhciBjKQ0KQEAgLTc1NCw3ICs3NTYsNiBAQCBz dGF0aWMgbG9uZyBndWVzdF9jb25zb2xlX3dyaXRlKFhFTl9HVUVTVF9IQU5E TEVfUEFSQU0oY2hhcikgYnVmZmVyLA0KICAgICAgICAgaWYgKCBjb3B5X2Zy b21fZ3Vlc3Qoa2J1ZiwgYnVmZmVyLCBrY291bnQpICkNCiAgICAgICAgICAg ICByZXR1cm4gLUVGQVVMVDsNCiANCi0gICAgICAgIG5yc3Bpbl9sb2NrX2ly cSgmY29uc29sZV9sb2NrKTsNCiAgICAgICAgIGlucHV0ID0gY29uc29sZV9n ZXRfZG9tYWluKCk7DQogICAgICAgICBpZiAoIGlucHV0ICYmIGNkID09IGlu cHV0ICkNCiAgICAgICAgIHsNCkBAIC03NjYsMTQgKzc2NywxMiBAQCBzdGF0 aWMgbG9uZyBndWVzdF9jb25zb2xlX3dyaXRlKFhFTl9HVUVTVF9IQU5ETEVf UEFSQU0oY2hhcikgYnVmZmVyLA0KICAgICAgICAgICAgIC8qIFVzZSBkaXJl Y3QgY29uc29sZSBvdXRwdXQgYXMgaXQgY291bGQgYmUgaW50ZXJhY3RpdmUg Ki8NCiAgICAgICAgICAgICBjb25zb2xlX3NlbmQoa2J1Ziwga2NvdW50LCBm bGFncyk7DQogICAgICAgICAgICAgY29uc29sZV9wdXRfZG9tYWluKGlucHV0 KTsNCi0gICAgICAgICAgICBucnNwaW5fdW5sb2NrX2lycSgmY29uc29sZV9s b2NrKTsNCiAgICAgICAgIH0NCiAgICAgICAgIGVsc2UNCiAgICAgICAgIHsN CiAgICAgICAgICAgICBjaGFyICpraW4gPSBrYnVmLCAqa291dCA9IGtidWYs IGM7DQogDQogICAgICAgICAgICAgY29uc29sZV9wdXRfZG9tYWluKGlucHV0 KTsNCi0gICAgICAgICAgICBucnNwaW5fdW5sb2NrX2lycSgmY29uc29sZV9s b2NrKTsNCiAgICAgICAgICAgICAvKiBTdHJpcCBub24tcHJpbnRhYmxlIGNo YXJhY3RlcnMgKi8NCiAgICAgICAgICAgICBkbw0KICAgICAgICAgICAgIHsN CkBAIC04MzYsMTIgKzgzNSwxMCBAQCBsb25nIGRvX2NvbnNvbGVfaW8oDQog ICAgICAgICBpZiAoIGNvdW50ID4gSU5UX01BWCApDQogICAgICAgICAgICAg YnJlYWs7DQogDQotICAgICAgICBucnNwaW5fbG9ja19pcnEoJmNvbnNvbGVf bG9jayk7DQogICAgICAgICBkID0gY29uc29sZV9nZXRfZG9tYWluKCk7DQog ICAgICAgICBpZiAoIGQgIT0gY3VycmVudC0+ZG9tYWluICkNCiAgICAgICAg IHsNCiAgICAgICAgICAgICBjb25zb2xlX3B1dF9kb21haW4oZCk7DQotICAg ICAgICAgICAgbnJzcGluX3VubG9ja19pcnEoJmNvbnNvbGVfbG9jayk7DQog ICAgICAgICAgICAgcmV0dXJuIDA7DQogICAgICAgICB9DQogDQpAQCAtODU0 LDE4ICs4NTEsMjMgQEAgbG9uZyBkb19jb25zb2xlX2lvKA0KICAgICAgICAg ICAgICAgICBsZW4gPSBTRVJJQUxfUlhfU0laRSAtIGlkeDsNCiAgICAgICAg ICAgICBpZiAoIChyYyArIGxlbikgPiBjb3VudCApDQogICAgICAgICAgICAg ICAgIGxlbiA9IGNvdW50IC0gcmM7DQorDQorICAgICAgICAgICAgY29uc29s ZV9wdXRfZG9tYWluKGQpOw0KICAgICAgICAgICAgIGlmICggY29weV90b19n dWVzdF9vZmZzZXQoYnVmZmVyLCByYywgJnNlcmlhbF9yeF9yaW5nW2lkeF0s IGxlbikgKQ0KICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgcmMg PSAtRUZBVUxUOw0KKyAgICAgICAgICAgICAgICBicmVhazsNCisgICAgICAg ICAgICB9DQorICAgICAgICAgICAgZCA9IGNvbnNvbGVfZ2V0X2RvbWFpbigp Ow0KKyAgICAgICAgICAgIGlmICggZCAhPSBjdXJyZW50LT5kb21haW4gKQ0K KyAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgY29uc29sZV9wdXRf ZG9tYWluKGQpOw0KLSAgICAgICAgICAgICAgICBucnNwaW5fdW5sb2NrX2ly cSgmY29uc29sZV9sb2NrKTsNCiAgICAgICAgICAgICAgICAgYnJlYWs7DQog ICAgICAgICAgICAgfQ0KICAgICAgICAgICAgIHJjICs9IGxlbjsNCiAgICAg ICAgICAgICBzZXJpYWxfcnhfY29ucyArPSBsZW47DQogICAgICAgICB9DQog ICAgICAgICBjb25zb2xlX3B1dF9kb21haW4oZCk7DQotICAgICAgICBucnNw aW5fdW5sb2NrX2lycSgmY29uc29sZV9sb2NrKTsNCiAgICAgICAgIGJyZWFr Ow0KICAgICBkZWZhdWx0Og0KICAgICAgICAgcmMgPSAtRU5PU1lTOw0K --8323329-1619268939-1768953762=:7192-- From xen-devel-bounces@lists.xenproject.org Wed Jan 21 00:23:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 00:23:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209389.1521407 (Exim 4.92) (envelope-from ) id 1viM0X-00030g-9I; Wed, 21 Jan 2026 00:23:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209389.1521407; Wed, 21 Jan 2026 00:23:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viM0X-00030Z-6c; Wed, 21 Jan 2026 00:23:37 +0000 Received: by outflank-mailman (input) for mailman id 1209389; Wed, 21 Jan 2026 00:23: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 1viM0W-00030T-3C for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 00:23:36 +0000 Received: from PA4PR04CU001.outbound.protection.outlook.com (mail-francecentralazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c20a::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6bf5e4ca-f65f-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 01:23:34 +0100 (CET) Received: from GV1PR03MB10456.eurprd03.prod.outlook.com (2603:10a6:150:16a::21) by AS8PR03MB8692.eurprd03.prod.outlook.com (2603:10a6:20b:561::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Wed, 21 Jan 2026 00:23:31 +0000 Received: from GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e]) by GV1PR03MB10456.eurprd03.prod.outlook.com ([fe80::a41e:5aa8:e298:757e%7]) with mapi id 15.20.9520.012; Wed, 21 Jan 2026 00:23: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: 6bf5e4ca-f65f-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=zHleMKmTI4G4/DCNuTSKk5SZYySChP5TtjuG7fJggejwqW1A4DSWFSqBWQjTl4vVBk40b0IdGNph2+6iKEKJ8/+uC86bmLBFeBHZygZVi7XZQJd1jLP99ABWW2gyx/Apo0HykTHD46xlm2RCaGEhQPYeVBsABBLCS59XRMgMO2BSytMSM6ozup0ROibgmul8JUk92dpX00vyS3vE3aV6tDgSJY/oomhaEeFVdWqx3eH0kO04SvEszDbeRAnk3YgvD5KKPeyWjG+1M0bZxpX08eBv8dbItcKwUdLaULjTkrLPyfxUOv+c3m9AFty2pH5bir9lqG2qaWhh45xKcJnlIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pz6fcZmmXaisVHNt9FM7kTrs2YMShlGtjjiiWGKLvVw=; b=yx9Y2i3G6EHX1/v3MhAMPrC0hecaFYf9qsPgZS2+eTXGgs8ABkGtHw/OKlxoI9bFisKtyGy8xQzj984lX2M2Sg1f2fzYPH6fKjWnHbFDZXs0ObSTwrkuQRDvIC/ZdNUNuOda3G1prFifFUDU1fJgUqevPGD6zez7DaZhmKZhFthPcMV32M1KOKBz6Qt7wSZR9EUCiD6m1Lgi3t5wTzNgXU+2WaNtKODIn7xZ36P46x7L9JLGg7BiF8ooV/FikoZ9bajHJfR1jptfKg5H+Y4TmqiVbVYl4PO1upUB68rJehFX0JX5TluWQysGPql1byIog3NqITgYPkGVolrrbkmhQg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pz6fcZmmXaisVHNt9FM7kTrs2YMShlGtjjiiWGKLvVw=; b=Y8+SctKjEUX9JOGjDbgiIwH3ao57FtrdzPLQns9yIhf48Aqohiyxe1l1b9+WH8H4S0Wo6vkMtyKx5CJ1GXv4sOihJta21HYztyvS6qAWUKUxFtEGaJAljbMbokOwnTvliYtlxc1X9CP4ovf5zvda1hWTcXLWvHfndrGFmIQjYgXUCGwlf8v7FW5gabFiuY9Az9lCAIxWFUBKO8mATecqd5LPg2CfadRHT5Yh9MDybwi3cT8ZcSlSKVJmiuZ7PHbhU0o1pER9n7HFXwBEPaughlr1biWyKI7bwQCyqJoyvYAfo4IguN3qBvOlHXwYo7x487mzocRVjCmfZohKZzT/PA== From: Volodymyr Babchuk To: Jan Beulich CC: Oleksii Kurochko , Michal Orzel , Julien Grall , Stefano Stabellini , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , "xen-devel@lists.xenproject.org" Subject: Re: [Arm] Re: [PATCH v1 11/15] xen/riscv: introduce ns_to_ticks() Thread-Topic: [Arm] Re: [PATCH v1 11/15] xen/riscv: introduce ns_to_ticks() Thread-Index: AQHcdPdXiMhfHHwKbka54SohlbcU+g== Date: Wed, 21 Jan 2026 00:23:31 +0000 Message-ID: <87bjin6cgd.fsf@epam.com> References: <369eb1d7-864e-4432-9729-57786d0c191f@suse.com> In-Reply-To: <369eb1d7-864e-4432-9729-57786d0c191f@suse.com> (Jan Beulich's message of "Mon, 12 Jan 2026 15:59:13 +0100") Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: GV1PR03MB10456:EE_|AS8PR03MB8692:EE_ x-ms-office365-filtering-correlation-id: 3355b6b1-e7d0-4c1c-f916-08de58834e66 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|7416014|376014|42112799006|366016|1800799024|38070700021; x-microsoft-antispam-message-info: =?iso-8859-1?Q?EEgiTyWNDHrgYrDzQWXvcGFUHXW2XGNxPm470mYnnGwoMltgF0SgX9DyiV?= =?iso-8859-1?Q?wzn2vDt8ZwwKhXt22tu9Jc1haSgS3pZq5igs8CKepg/YnwsQ5EVYVrspAR?= =?iso-8859-1?Q?icwMgrEJXmzma28lGEKd76q4+tKEPT+qtUWxnBDqc2CyHL2cYEk/tV+kGW?= =?iso-8859-1?Q?Xwmy/pEGHBPC3c/JVmxt16bgL/CGQNcMmPEllxr5o0wf4f26TXOX9RM4Eq?= =?iso-8859-1?Q?igPPT8KSU8lA5/dxTylZ9OGNPWeXCcLa4jhSlS4yiozkziGm/lv8G1gNq3?= =?iso-8859-1?Q?/cdFpvgSucqBYgnosvoZ8a0o5KQcOwdIociLxnIcAofdWFrVVnWPahaHoa?= =?iso-8859-1?Q?sMQ4OyasKKfCInBIr6aRihPNvzalxUrnnd9JoTW0DD8qf4SqmdMOlStpYY?= =?iso-8859-1?Q?pE85GS7/QDIDoX7OU1PW6tDQrl89v78nGHP7+Q7JMYMfKTnxvM3uuPCAnS?= =?iso-8859-1?Q?O7Oe8IoEfWYj51mVavzMW7SCk41pGSgxfJ5TljKi8a8ESWRUXX+rA7p2ob?= =?iso-8859-1?Q?f1dIlmA5ZiayScrJsBKospiMzJAs7UyPPzgDPHe4EsJFRtfhSHeKCY3YMs?= =?iso-8859-1?Q?UuPn5t25WAjfIF7LHzB4QVyjEidt+O/e5VXBylwa7VQjKcSql7NvjygTgJ?= =?iso-8859-1?Q?ND1ydknsLUIJvVzXbqg5jM/m9ZB7937QRelaMRs+X/ZsjsfaT5ZPgMkO09?= =?iso-8859-1?Q?+2Akd6tHbzpp9dhznhJEtiM3lIhmBy0DgDg9JUcZs0AXBLsM+dT8tQqJpM?= =?iso-8859-1?Q?lCqNt0sQ9W8hEqk3oKniNE5AMJjeauot6zYDfA9GSKaJRQq5CUlu3ksemK?= =?iso-8859-1?Q?oSgLl3FFfRRfMd7xx6QEAlSRCvkPP3MjGwJAzMQo4VeArCLLNnU/hK8NQd?= =?iso-8859-1?Q?fWxHZx3jQVdBBjJIOcQJ5mmiK9YytxqSpJoHvFp1UX70oxn5CvL4u0RJC/?= =?iso-8859-1?Q?s8CFAxF4gCmwe0eB96nstGvSoNHhBZO/plSTpx9o1I2YVl+Hnk2AzcB7OR?= =?iso-8859-1?Q?pTkLQIkrW1KrNzagNAcJVLXTtcB9NFFBLYgpinDDsseFH6RiSBtp6xcdEx?= =?iso-8859-1?Q?R5utzC6Dhkc7QySqm2lxij9RHlDFS+9kwwUSVAhFpATbjAdHYWCIPh/Y21?= =?iso-8859-1?Q?U14d0WM8WqgWz5kVPfdeSnhq4kh9/f5CSJk0AtU48l4l3xkkeLcevk05S+?= =?iso-8859-1?Q?2K4F5EgyMMaYry3dlV4AIJzqtEN7EqD1jXZ9SZv+WlMf7VTlTzWCCG3nmh?= =?iso-8859-1?Q?hDLDCC8Mly7bsosh4tgUh/Ut5dc3IkaqAGsR1C9FYn4kGla7k+evgS4y9h?= =?iso-8859-1?Q?iTjlJXloJqcQI6vuQjIHDJBsCDfCyDwU/57IPiD8EQsHmEy8nB7keoFYzJ?= =?iso-8859-1?Q?TaWibjCOVeAqON9pwZ2VHLhLJjKnoWcsgdxAc++X348pqPIJOFAgubCbtR?= =?iso-8859-1?Q?EhvMG9qfCky2j8RphZvUFlgFPx5caXvzPYHTiLUub4iEvWlb1WkttBkxYe?= =?iso-8859-1?Q?vp31G5SoORJC0iI3OGAs7cEAdkHRaUbITA2Nj5s5m7wPJ4CLDSWa4AiBN3?= =?iso-8859-1?Q?bRXVPFsyYu6QExc2JZnt+8sNDb7TJIoTUzbdmtHt6kL+mhcaI3/e6plvFT?= =?iso-8859-1?Q?I9inNIa6I0cWQVy9lv2/1vQhboLmagKQXlFfUkz5KEBfbBgKPSrT8SO8fo?= =?iso-8859-1?Q?oNtN5SmcDNnzLL7GyaY=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:GV1PR03MB10456.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(42112799006)(366016)(1800799024)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?+5jrbJgW4tcXlVUe9dUIF+ygKfe9x+VK5cCT1o0hup5h3R55bl/94pf1nS?= =?iso-8859-1?Q?1q1yS8i/m1k5Pzx4xDy/QbiaxW80C/FbygqjtmZ1Ls2BRs98Ym5/R/U115?= =?iso-8859-1?Q?MFNc8DweOdzLmsT3pYUtWut+0AxhgpAGILgr816FZr1v8O0u7XLzTjLwE1?= =?iso-8859-1?Q?fsoPYVYhLS8b29gMaFIvabDKPmLtk7WrbWli925qPwUDnWD+mwsJfy2QGM?= =?iso-8859-1?Q?NwE9Rky9xPgweCorept3kWcinZPLFOSLr6p6sbVbE/twRf0RXqufTO1+Yz?= =?iso-8859-1?Q?ue8gUm1JvO0A5hBLT2E128qKNy1rSSDTG5+7fQYW4ehtrykwxTNOf2Y2dg?= =?iso-8859-1?Q?I+Od6KPIA2fmj5X5SDF5DxS0bxIMknsJB3vtxKxFFOlw3HNLSl5Z42hPXp?= =?iso-8859-1?Q?3MZIojkpac4k0rBC84eFRuRWS4wMPzsCwT9w91j0uwVoNLUWkMAT8bsFcR?= =?iso-8859-1?Q?kcjLDRL8QNyu2UksSCkBcowBl71ZeeLfZYosoKjLzxySRkXsKaf+QsFxU7?= =?iso-8859-1?Q?lQvURU97k9Y0dheSA9E+u0FZnm1f02m7Jeb8W8Nd6ZtxD4eZD0/asE3hgh?= =?iso-8859-1?Q?dEM2gtAQWJ2CUX+OadJAnLyKD/g7D3zSxR/YWFM4WmUvDll6L5pTmfLaxI?= =?iso-8859-1?Q?LQY2pwPLyyK79/B+nUJIZLg37LaDTP41P1dhm4Cg/DKSbOnR9/BfIAvHMx?= =?iso-8859-1?Q?gyreCPIJbQl18zVG65H3F2/T9KOS3bWQLQqbiXPta9PG0Zi/HNRu1A3UX9?= =?iso-8859-1?Q?1hH6rRJk8tmBVbugzuU+Kxk4gajxzl7Y7JVQCNo4GNY0whWol0uGv+KbCw?= =?iso-8859-1?Q?WOu/Q8NqrWcQeEsgMyIS8bSNWf+AT52d8+VUGmh5yWY+vfjotl8fTak1li?= =?iso-8859-1?Q?kCVdIaeET0QpyCx18C5yN9JqRUc+FpPj4W2gXbd/hn4TSvq8duLMc8tGLj?= =?iso-8859-1?Q?elWT5wiQe+pFKcbTnDIqdJmNAuAeppkLaXmpeT/80FSKDSaG8piCrm3Z2t?= =?iso-8859-1?Q?dDU+iq6t9JuqRkm/NKtusIjHR/iHWINcdADOjQoLgdQHwhv/FOE3Sybtbd?= =?iso-8859-1?Q?yhWzZUhOB6z7lpM5SW0y6jRB3tD+aKMT5GKJn5u+r1dIpsvw3qBr2Qo/9u?= =?iso-8859-1?Q?g3IPnfQczUSFT4+vGph/uCbA0C4HhRXudW5jwu+QWleZQz7cOfnSCZ4bHU?= =?iso-8859-1?Q?6E+ZvYVu7SKXaToqEEJM+t5CTmaxROdoNRdbevtYsAfmXciVJp6aoZWje8?= =?iso-8859-1?Q?G6BCHyxmdXIU4HE8+JgGTizQ/IxX3E42qq5GYsnFvRW3EwXNXpCt6sn3Ma?= =?iso-8859-1?Q?Dw1/NGzDcbHW3wO2lKsWTR4+HwO7PHPX/qHsegG1ChtynZnFsQwcV00vAB?= =?iso-8859-1?Q?CBC89aRHuMxse4/OamUZ9endiYnl/LxmNreCZPmc0FHCmYmvrqdaByyFi5?= =?iso-8859-1?Q?SR9HzgnS9Ut51pUXLFsigIzIwP+tjRAnLUgoT9L0UuaXzyPRu1xeP1cfV3?= =?iso-8859-1?Q?SA5ZTb2XbDnfLCkejegzbKsPKMGBhtz09hYFkNdB1LPh3Bsr34Kehp3Nch?= =?iso-8859-1?Q?xAsFYTBEiuap6kGM6ac60Lcuphu+Di07toeADdPjc2pdoNwDoW8UFGcVIm?= =?iso-8859-1?Q?Kd9gImREXYEasVKEXcHpcBIFB2WoWX6qqrVEFpHZXfOicBQmyEm3VCs1vz?= =?iso-8859-1?Q?RyeWGAAev/lpSppsTQLT96C2d4BviWTs4EkZBnujsX9/R8lvyVZ+GxibnB?= =?iso-8859-1?Q?Nu0dkH0yGRwtlRCh06vLMT/0O77sX1D9/hA4n0zbJaEvN3KdvXuDqNjqg3?= =?iso-8859-1?Q?imaOshW2DlZM4IoF+QN8qHJgmdG1GDs=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: 3355b6b1-e7d0-4c1c-f916-08de58834e66 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2026 00:23:31.2464 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rB/Carb+TEC0vUrasIH1Tvk1GqHtx3XA9HfNkvNCManbmcQrCTvxJvgsxcUGvLEDVD1VwrhJ4+5aQHrlSBv/gZBN3EE8i15LJ4ZQ6ltQGzI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8692 Hi Jan, Jan Beulich writes: > On 24.12.2025 18:03, Oleksii Kurochko wrote: >> Signed-off-by: Oleksii Kurochko >> --- >> xen/arch/riscv/include/asm/time.h | 5 +++++ >> 1 file changed, 5 insertions(+) > > Looks okay and read to go in as is (no dependencies on earlier patches af= aics), > but: > >> --- a/xen/arch/riscv/include/asm/time.h >> +++ b/xen/arch/riscv/include/asm/time.h >> @@ -29,6 +29,11 @@ static inline s_time_t ticks_to_ns(uint64_t ticks) >> return muldiv64(ticks, MILLISECS(1), cpu_khz); >> } >> =20 >> +static inline uint64_t ns_to_ticks(s_time_t ns) >> +{ >> + return muldiv64(ns, cpu_khz, MILLISECS(1)); >> +} > > It's hard to see what's arch-dependent about this or ticks_to_ns(). They'= re > similar but not identical to Arm's version, and I actually wonder why tha= t > difference exists. Questions to Arm people: > 1) Why are they out-of-line functions there? That's interesting question. According to git blame this is how it was introduced in 2012 and after that no one touched this part. Original patch had cntfrq defined as `static`, this explains why these functions were declared out-of-line. > 2) Why the involvement of the constant 1000 there? 1000 * cpu_khz can > actually overflow in 32 bits. The forms above aren't prone to such an > issue. Patch "xen: move XEN_SYSCTL_physinfo, XEN_SYSCTL_numainfo and XEN_SYSCTL_topologyinfo to common code" (096578b4e48) changed hz to khz. This added that 1000 multiplication. Also this patch removed `static` qualifier from the counter variable. Anyways, latest ARM ARM suggests that timer frequency should be fixed at 1GHz, which is shy of 32-bit overflow. So most new platforms will be fine. And older platforms had much lower frequencies. > If the delta isn't justified, I think we'd better put RISC-V's functions = in > common code (xen/time.h). They're not presently needed by x86, but as > inline functions they also shouldn't do any harm. I'm mere reviewer, but I agree that proposed approach is better and more resilient. --=20 WBR, Volodymyr= From xen-devel-bounces@lists.xenproject.org Wed Jan 21 01:20:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 01:20:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209400.1521418 (Exim 4.92) (envelope-from ) id 1viMst-000062-AT; Wed, 21 Jan 2026 01:19:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209400.1521418; Wed, 21 Jan 2026 01:19:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viMst-00005u-5e; Wed, 21 Jan 2026 01:19:47 +0000 Received: by outflank-mailman (input) for mailman id 1209400; Wed, 21 Jan 2026 01:19: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 1viMsr-00005o-Qa for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 01:19:45 +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 434a2b10-f667-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 02:19:42 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 4E1ED60051; Wed, 21 Jan 2026 01:19:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E6F4C16AAE; Wed, 21 Jan 2026 01:19: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: 434a2b10-f667-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768958381; bh=gyRuce2gAMFd7Kf+AIbt/VKe3z2siCjHdmIEWBGHDgY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=BXChK3/hFw7xNsDxiEk+a6VD0tDY6aeS23lbOl9HWy+9TN1Q++GayE3hlidcd43Aj b473UShyLOVs1ExKIaO3kGxPJRriVEpjwW7UuDWqYZrb0zH4NQIiaRAaBxxA/2bmSW rkcseWZcbKYVbJbodBlT+h4L274jTjT72skMY7z47fWHLbiAEGyC0KR9fo/f1nyENe Ka/4FPEvDxnVWjWEqAx88w5yX4KNARd1t7u5liyiLBuonviEZxr+rPEJ5svogmdHdE KEGojP09//roEsQJfRHCAhs4k/hhYfU/PqTUhr5rHCnfoC+I93EAQtVP+BtRZ6mCjX dphN7EFAcJ4yQ== Date: Tue, 20 Jan 2026 17:19:38 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Volodymyr Babchuk cc: Jan Beulich , Oleksii Kurochko , Michal Orzel , Julien Grall , Stefano Stabellini , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" Subject: Re: [Arm] Re: [PATCH v1 11/15] xen/riscv: introduce ns_to_ticks() In-Reply-To: <87bjin6cgd.fsf@epam.com> Message-ID: References: <369eb1d7-864e-4432-9729-57786d0c191f@suse.com> <87bjin6cgd.fsf@epam.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Wed, 21 Jan 2026, Volodymyr Babchuk wrote: > > On 24.12.2025 18:03, Oleksii Kurochko wrote: > >> Signed-off-by: Oleksii Kurochko > >> --- > >> xen/arch/riscv/include/asm/time.h | 5 +++++ > >> 1 file changed, 5 insertions(+) > > > > Looks okay and read to go in as is (no dependencies on earlier patches afaics), > > but: > > > >> --- a/xen/arch/riscv/include/asm/time.h > >> +++ b/xen/arch/riscv/include/asm/time.h > >> @@ -29,6 +29,11 @@ static inline s_time_t ticks_to_ns(uint64_t ticks) > >> return muldiv64(ticks, MILLISECS(1), cpu_khz); > >> } > >> > >> +static inline uint64_t ns_to_ticks(s_time_t ns) > >> +{ > >> + return muldiv64(ns, cpu_khz, MILLISECS(1)); > >> +} > > > > It's hard to see what's arch-dependent about this or ticks_to_ns(). They're > > similar but not identical to Arm's version, and I actually wonder why that > > difference exists. Questions to Arm people: > > 1) Why are they out-of-line functions there? > > That's interesting question. According to git blame this is how it was > introduced in 2012 and after that no one touched this part. Original > patch had cntfrq defined as `static`, this explains why these functions > were declared out-of-line. > > > 2) Why the involvement of the constant 1000 there? 1000 * cpu_khz can > > actually overflow in 32 bits. The forms above aren't prone to such an > > issue. > > Patch "xen: move XEN_SYSCTL_physinfo, XEN_SYSCTL_numainfo and > XEN_SYSCTL_topologyinfo to common code" (096578b4e48) changed hz to > khz. This added that 1000 multiplication. Also this patch removed > `static` qualifier from the counter variable. > > Anyways, latest ARM ARM suggests that timer frequency should be fixed at > 1GHz, which is shy of 32-bit overflow. So most new platforms will be > fine. And older platforms had much lower frequencies. > > > If the delta isn't justified, I think we'd better put RISC-V's functions in > > common code (xen/time.h). They're not presently needed by x86, but as > > inline functions they also shouldn't do any harm. > > I'm mere reviewer, but I agree that proposed approach is better and more > resilient. Yes I agree too. From xen-devel-bounces@lists.xenproject.org Wed Jan 21 08:31:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 08:31:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209436.1521428 (Exim 4.92) (envelope-from ) id 1viTcP-00089N-Pj; Wed, 21 Jan 2026 08:31:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209436.1521428; Wed, 21 Jan 2026 08: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 1viTcP-00089G-Ms; Wed, 21 Jan 2026 08:31:13 +0000 Received: by outflank-mailman (input) for mailman id 1209436; Wed, 21 Jan 2026 08:26: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 1viTXW-000789-7Z for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 08:26:10 +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 d553e3e0-f6a2-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 09:26:08 +0100 (CET) Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-2a79998d35aso4250965ad.0 for ; Wed, 21 Jan 2026 00:26:08 -0800 (PST) Received: from d.home.mmyangfl.tk ([2001:19f0:8001:1644:5400:5ff:fe3e:12b1]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a7190d14cfsm147637005ad.38.2026.01.21.00.26.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Jan 2026 00:26:05 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d553e3e0-f6a2-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768983966; x=1769588766; 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=pOfh991Nf5x6cbHEyitGr4ECnygIc5lXslxo+H2b9a0=; b=iIHjYIW8ExwXFwlPRkAudkl7I+1lSaKNkXmOJF5466GmpMZH0jqFzU4DMYW4jvXcr6 3SuAMOeMg7G53Qmk4ABhyQE172ne35AUns8rTnRYVjoIMwPXtUmc1ZQPUeVwYURs/7ej s+Qiq0RNByLheOSwMfB0N3MNoiM0kupd+5Q+CcrpqRz+L+sv62g2uSHz/Aa2JqW3JsBJ ZSJKEpoh4LoOWBcg1Ihd1viN1XUq59MQfj076iHGVobqhvjCqfGa+NUKN438rxP3tjpW n/OauMlPgjKgzfTXJ973Tqe1TGYZKcKrdB49bnrheBVYwjg72fJBZnPQWLSZnS/0qz08 DILg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768983966; x=1769588766; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=pOfh991Nf5x6cbHEyitGr4ECnygIc5lXslxo+H2b9a0=; b=UWG5pDcLb37f64PVzm1eZi1PlX8eLywPRp3oNF7gMjtoTlKbnm2Vg9uleNOWq3uEtz 3+iwJ54JHLU5Ff3iBCnhEzY7DRozZIWMXoN339qB3ss03/FSAbxggO1gx7e66Vu/MBbD QjK3/mPgv90NcBQ1+ewVxYFDt1y7V4BP9Y32HEyzhyL/F25H4uATAS4LxK0ZxhsSVlOf gHnF8immIL2Xo5tBX35nqeMFwCWu2hNroPkmJlfCqcb7OVhntXwIH2oCK/vPB2ks/ILW 7BJIOYF7K52lbCH9HbLKiS70JRw5s0pXwVqUMm5iWXdPGxw6vQC+euM3/bwlwLjB1il2 re5g== X-Forwarded-Encrypted: i=1; AJvYcCWec4VErRlIKOzGzMVmDeHOuU7lvEOWJK+14qbAxEy/G0Ak9Ap8TGLcKtXJp/D58GgscWB/MkYEy4g=@lists.xenproject.org X-Gm-Message-State: AOJu0YzROORnaLeLpHidK/6cVkeysCi5Nm+sDXyiPShkiSeBqTsFiPWf wQnYez7SOmBGN4uKd0R63qMpGmnKHX4ihrR/ILCrh6zwYZehIAX0TSqsAlXocg== X-Gm-Gg: AZuq6aJGzT4GunRCqyUlFjdL1jKtRLKoer6/kjpZ6hLRMAQIVbAGT4K3W/0bA7e/EFM z980qSDL08YOVroxYl/9Wun2EQffJFRHlgnSySSDwjM/UJyYgyWueYzvGMpi1a/KJLlsUnR2cn8 2eYOVESrd4/H3AUrLBoB4yHWLgvU0czuvnG8n8pp1LP4hkfqMzWx4CDOpnQM2PbZsjAQFyDa+Pc HE1lv0hUztrwHp+1yP3ZkO/KvWvaISDHPlarOimAmBPp1WZ3oHzkSMGuXYebgJ8ywt5adCcLOoi UoqMhf7E0wDhCx8Kd7b4mivWpXuAywVcC/d2Bd+wocNjaRFMg1Uw5rdEm2M2BVbGI5PsPMhDYyB eArGS0Tt3f58okGTR5bcWtQp2W12kMUv6De4vibFAZKvzQXa24wTUBlgK9h1R/DY0/Wn5mVhxiN DxD3DNG1wAhKeSmZA9FPC1BdmY7UbaNbgxqfidSRwmQQ0PMT4lzGP6gA== X-Received: by 2002:a17:903:1110:b0:271:479d:3dcb with SMTP id d9443c01a7336-2a717518996mr161853105ad.6.1768983966532; Wed, 21 Jan 2026 00:26:06 -0800 (PST) From: David Yang To: netdev@vger.kernel.org Cc: David Yang , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Subject: [PATCH net-next] xen/netfront: Use u64_stats_t with u64_stats_sync properly Date: Wed, 21 Jan 2026 16:25:46 +0800 Message-ID: <20260121082550.2389249-1-mmyangfl@gmail.com> X-Mailer: git-send-email 2.51.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On 64bit arches, struct u64_stats_sync is empty and provides no help against load/store tearing. Convert to u64_stats_t to ensure atomic operations. Signed-off-by: David Yang --- drivers/net/xen-netfront.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 7c2220366623..0969d5c9f6b7 100644 --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -97,8 +97,8 @@ struct netfront_cb { static DECLARE_WAIT_QUEUE_HEAD(module_wq); struct netfront_stats { - u64 packets; - u64 bytes; + u64_stats_t packets; + u64_stats_t bytes; struct u64_stats_sync syncp; }; @@ -634,8 +634,8 @@ static int xennet_xdp_xmit_one(struct net_device *dev, notify_remote_via_irq(queue->tx_irq); u64_stats_update_begin(&tx_stats->syncp); - tx_stats->bytes += xdpf->len; - tx_stats->packets++; + u64_stats_add(&tx_stats->bytes, xdpf->len); + u64_stats_inc(&tx_stats->packets); u64_stats_update_end(&tx_stats->syncp); return 0; @@ -843,8 +843,8 @@ static netdev_tx_t xennet_start_xmit(struct sk_buff *skb, struct net_device *dev notify_remote_via_irq(queue->tx_irq); u64_stats_update_begin(&tx_stats->syncp); - tx_stats->bytes += skb->len; - tx_stats->packets++; + u64_stats_add(&tx_stats->bytes, skb->len); + u64_stats_inc(&tx_stats->packets); u64_stats_update_end(&tx_stats->syncp); if (!netfront_tx_slot_available(queue)) @@ -1249,8 +1249,8 @@ static int handle_incoming_queue(struct netfront_queue *queue, } u64_stats_update_begin(&rx_stats->syncp); - rx_stats->packets++; - rx_stats->bytes += skb->len; + u64_stats_inc(&rx_stats->packets); + u64_stats_add(&rx_stats->bytes, skb->len); u64_stats_update_end(&rx_stats->syncp); /* Pass it up. */ @@ -1400,14 +1400,14 @@ static void xennet_get_stats64(struct net_device *dev, do { start = u64_stats_fetch_begin(&tx_stats->syncp); - tx_packets = tx_stats->packets; - tx_bytes = tx_stats->bytes; + tx_packets = u64_stats_read(&tx_stats->packets); + tx_bytes = u64_stats_read(&tx_stats->bytes); } while (u64_stats_fetch_retry(&tx_stats->syncp, start)); do { start = u64_stats_fetch_begin(&rx_stats->syncp); - rx_packets = rx_stats->packets; - rx_bytes = rx_stats->bytes; + rx_packets = u64_stats_read(&rx_stats->packets); + rx_bytes = u64_stats_read(&rx_stats->bytes); } while (u64_stats_fetch_retry(&rx_stats->syncp, start)); tot->rx_packets += rx_packets; -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 21 08:56:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 08:56:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209449.1521437 (Exim 4.92) (envelope-from ) id 1viU0k-0002XJ-LK; Wed, 21 Jan 2026 08:56:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209449.1521437; Wed, 21 Jan 2026 08:56: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 1viU0k-0002XC-IT; Wed, 21 Jan 2026 08:56:22 +0000 Received: by outflank-mailman (input) for mailman id 1209449; Wed, 21 Jan 2026 08:56: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 1viU0j-0002X3-Lo for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 08:56:21 +0000 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170100009.outbound.protection.outlook.com [2a01:111:f403:c107::9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0c20b97b-f6a7-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 09:56:19 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by MW4PR03MB7009.namprd03.prod.outlook.com (2603:10b6:303:1a4::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Wed, 21 Jan 2026 08:56:14 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Wed, 21 Jan 2026 08:56:14 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0c20b97b-f6a7-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tbG3NOaG8MUQdUXZE5skW/K/L+Sb7A46ZmbV/ar+0IJaww+yaHdN4eHzo3rMMOXAFszx8TwxnYnihmeOyGafCIEOCFQeMce1+LEtn/q6zJlGIaCpYRTi7OHpUMSDPzqi63vMSrl6WNLAIWOTxYEB+EVzslWYPDAih0BXz4MRTOy2lXiVDw+jytokaayvd/IpqYo3b9v1UfewnZV6MxBlLv78lWoOQNmQNfemWBihSJ/pG4sqt3vcWEQG6MIbGVI8Eg71XXnNpv2wDZur1qx/s653wax7ktmYiMZZXL6HmeUQj1HlE1lp5ov28qnw2Un20ph4z3rVT/+rMwCd9BX8RQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dsFM0pb1Rf2vqmhsegcRTSqeECXcMspiYcNU1CZRN14=; b=nsNY2jvScyqdiz76yyM1Oc+/8NJ05oCK2Au+FoC3TNV/xaX3B/RifoSoMv2tgaGzoq/0bKYDwsXwb/B3SdNXyXxNFExS2TDlJIzWUdgjSRQNsZ4QrhRhXyH1XFg4MmuDgpGCA0VO0DGM/Bwaube7ZqLk0boUBKRAVag6pKsO7H+TIR2bCtTK0YIt5LsQSZxSzeqQiIRt18d65ZIr1iWzzrmtLkETgPhStt5MCgNZkBPZC+ZKBv8J01nn6T0Ec7itiINS8CwHQYMh4K7VgsXpvZqvqNouvJR8Te039G3MooBWOaE3IgA0LGcASg71E1DrG7KnFANohjLx0NICurJyVg== 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=dsFM0pb1Rf2vqmhsegcRTSqeECXcMspiYcNU1CZRN14=; b=md6DPJs8qLUGXMjrMEeOAy8zbTNsxt6CsRrhgmf+uYy+3oE3pkD/dlS0iqJQpH0jrPRW5SsmuSkr+B0/aemg2dPWkHldcHxu12KPmF9dD5bIPj31MmGQnxuKVN8KnaxXzGIxsLi3Mrs8RFDriGagVi8ItNLglQv1AO38WhVy5HY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 21 Jan 2026 09:56:11 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jiqian Chen Cc: xen-devel@lists.xenproject.org, Huang Rui Subject: Re: [RESEND PATCH v12 2/3] vpci/msi: Implement cleanup function for MSI Message-ID: References: <20251208081815.3105930-1-Jiqian.Chen@amd.com> <20251208081815.3105930-3-Jiqian.Chen@amd.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20251208081815.3105930-3-Jiqian.Chen@amd.com> X-ClientProxiedBy: MA3P292CA0037.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:46::19) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|MW4PR03MB7009:EE_ X-MS-Office365-Filtering-Correlation-Id: 3f4b9e16-1246-4f07-d405-08de58caee76 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?Wk4rY2NsTnJtLzZTcHNXY0NGcW5mS2dNaUppeHVvWHRYRnZFQjB2SlNBTmhr?= =?utf-8?B?ZHkvZ0hKVFVrUHN5ZWg5a3dtNTVUcGRNRCtTY0JZRFVDQ2wwVlE1cndsVmcr?= =?utf-8?B?TWxReGl6KzBVZGNkcVZnWFcxbE5CL0RSN3ZiUlBFK3RWdm1ma1JXYWxnSEJz?= =?utf-8?B?SnZvTW5yNDNvN29RNnBNU0txeVM3ZUVWQ2Myd251WENucVpxbHpodHhDajlk?= =?utf-8?B?LzNPUkRKaVZ4WnlBck4ydzJtS0J1a283V1hGbEdsdFUxaFR2eFRuTFBwY0lj?= =?utf-8?B?RkFZNjZEVXovMXovalhtbk1JNy80WkFUT044OTYwOGF1Q2JsMnVSbHlxM0Jn?= =?utf-8?B?RTRodWRES3R4dEJoM1JIZ1ZDVXZYMHVURXJ6Yi9aUXVPR0hFQW5pTm5XU1lR?= =?utf-8?B?TlI1WG13aUd0MVlwdWJnL2dQZEpKMVFqcDhnT2RNeGpTY3lsMUVRRUtZUVFy?= =?utf-8?B?UUJxYzk0M2Uwb2hSU0ZCeERiT3hHU1VMNW01Y3o1amtXTEFXN3grOTNLNXda?= =?utf-8?B?QTlLd1NGdHpYWmpXMlNNNTU5VDZtaEJkVHpmVFVxV045emNQMmtXWnhoT3Y4?= =?utf-8?B?TWZ5MjJ2TnNzZkd1N2Z2N0hIRjZPRHFOd1pZcnVIVUIxaGIvM20vNWxlQWlY?= =?utf-8?B?U2FTRThrZ2ZNUUF4MDdqVzNyZ0k2cUZRZGNBdjZjM3FDdEIwVVR3TW54OHNW?= =?utf-8?B?b3dFTkJnVE1Qc3h1QjVJN2RORlZEY1VHb0lmeVJIZ0tZVDc0YW9wQmZMcHdv?= =?utf-8?B?UHVSN0hFazRzTVV6Y295ZnBLdWVrN2djbjk3clZxS1pXNmRud01NZkpPblRl?= =?utf-8?B?Qnp4NEJEOHpJYTRLU2RiSmZhbDkwMmx0R2ExbE5EdVptRVA1c3lkc1BVWHNp?= =?utf-8?B?RTRWUVdlOEZxcjUzc0xMSE9KWEdEYjE3UjBrbUlrNm00VzJiN3A4bGJBdFBU?= =?utf-8?B?dSs1b1VqQ01Cd0x4V1RvQjZzWjNoeXBXb2wrbEJMVmJXaGpyZm1ZTVNhM0xv?= =?utf-8?B?cEd1VDZlbkJmRGhkMlY1YVRlYUFQdDB2QW1aYmxSSDI0b1VhNjR5MUxJemtG?= =?utf-8?B?YTdwSjFaOXlMTmVmZm5JbncyeExjNGpuL3ZjeGJXcFNlY3NJU1dxR1JRQVdT?= =?utf-8?B?NFNiU2N3TE9LSDJsZDI2a3VpS0xtWWI4LzEyaVdSWWRhZ1hNblBOMFFXU2d3?= =?utf-8?B?eFJaK2FIVVZLYkVZWldHYWtWQlFTYktWV2lIU0E3NC9NSVpMVjRyb01qRm50?= =?utf-8?B?bENCVno4d2ZSU3h3RkI4YXhiRTRXYVhISGtJcmJxdmN3UGtMc29mYzJON242?= =?utf-8?B?SGVhVWNNNDJMUEs3VURRWUtlOW1malhFKzFrb0Z5Ri8zbWdoZXVxM1JEQ2Fx?= =?utf-8?B?aytMYjdZZU1xcktKYWp6TkpzK21OSlhyY2VxOGozbXBPR3dVWHBwSU50bHM0?= =?utf-8?B?OCtXNkZ1ZElqRi9QZ0hxNzFKcGlWdHd6ejFCVjdMRlI1bFN5cWE0OVltOGJi?= =?utf-8?B?ZVJ3N2d4Y1pEbFk5czRLbDBmNlA3aDN0SWxaTSs0NlNKMGxjOUNzcFltenpy?= =?utf-8?B?aFlSNjVQMUZndG5WbTdvRVpEVFZ2aVZ5ZmUyS2F0VGtkNm1zUW1ZZC9EaEpC?= =?utf-8?B?UUZlaW9zeXNrTkRUZFdlTlcvUDI1SmtzMVdBSUIybkpJbXRlMWlDZ29FbW5o?= =?utf-8?B?TktKSUg2dDFJQUpUYTlYN1llVENYdzVJT2JwQ0FKZms1MFQzaEg2V1RRMWhh?= =?utf-8?B?R1JTdi9WV0NISG94RkYrYlZremh3OWRzNythdEVkMk5nWlhmbmRQcXhDcGJm?= =?utf-8?B?S0VkYmpuWlNmQlJxbEJNRWdUdVRDek5jL3hVZ0NwaUhGMW9HeXdKRVpFZDhL?= =?utf-8?B?K3dUeHhkTDBjOGx6NVU5cXRGcDBaVDZtT2tWSWR5U2ZOM0FyKyt1NGhNSHNi?= =?utf-8?B?dWNpQzFBWFdkWTRaSldNV3FjeWdDRDRGamFSR3YwKzE4R0RrNTR6U2VTLzB5?= =?utf-8?B?M0dDV2xNSktZWUVLV2xCcUNobVVMem1IcjVDanZjU2ZlbU95Z3JjQThMcGZv?= =?utf-8?B?dTlHSXNYQkhWc0g5MWxGZkxOQ1ltd1R1STRscnIyN3dWMVIxckxvY25OdzYw?= =?utf-8?Q?mN4o=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?amxVRjZBYlJ2N2VYSkF4MTJPU01Wc2dQMXZodjhhZHhsaWN3ZjBwaU9Fc3Q1?= =?utf-8?B?RGI4YWswVHk5eFZkL3dqcFU1Vk1UcmxjMHdtZkludVRGb0NUOHlET2I0NW9x?= =?utf-8?B?OGtkVzA1V1d1a0tGWEZWNG1leCtURmNBckVvWTE1ZjRTdld2dEZlMmREMVEw?= =?utf-8?B?azVSd0tvdEpBOCtFMlU4SERZN0h4Ykg2VEMvLzFURFpJQlBNU1ZXVkJjMlU3?= =?utf-8?B?dTAwVUJVVW45amJZdS9IdGFHN2puWkVUZ1k3L0JpL2hrQkE2czljcVExcWYr?= =?utf-8?B?ekswektEbjNTR2dScXA3bXBlUFB2T3M1VWk1MGFMem9BRXFTRGt2ZW4rWS90?= =?utf-8?B?NllLazNlZE5KL2pId3Z2V2E4RC9ZYWN6NE1kMWF4aEE4Q21OU0JmNXJBT3h6?= =?utf-8?B?cGdCanJLZGlyblJXbU54b284Zk1zb2tnbVZ3TExXc0oyVXZCR2RFZm5jVklH?= =?utf-8?B?c1B3UTNQZkhhU0hSaXltSlgrZjFDVHEwTkFoSVNpVnRYTVJFKzB2SHc2N25H?= =?utf-8?B?WjhTOWJ2N214S3FkdC85bitaMHVUa0FMc2RCNWZQRExYT2liZ3R3OExwVTlm?= =?utf-8?B?cnllbEZRajRmYUJTTlJGL3ZjankxcEtEVUc4Z01qYm9QdWxkenJhM1RoNjYw?= =?utf-8?B?ME1GRDNpd1ozS20rVjY3T1pHYkJSMlY2NWRvY3JaUUNBZkxHdTNQdURidWp3?= =?utf-8?B?THdhd05VWE9QV25yMTZCc2VGdG5TWEI4QmxWSVQ1bmo2QWppMmZwU3JrYWdq?= =?utf-8?B?STdkMzhBQlFMYzhPbTArZDE3eHNWazlVN0U0QUl1UjByV3RaRFF5UmdvZmR1?= =?utf-8?B?YjUwajdoY2dmSmwxVDgrYkNydjVlWTA1STRFNDZiZE5IUC90OE5aOEpUUVl0?= =?utf-8?B?K005QU5sT2NBWjVjNTZXaUZTZ24xNkJ6Y2plRWR1cnVUb1BiQjRJdkgrOUsw?= =?utf-8?B?TGQ1UWFUdVJpR3ZqVjVFYXgvV3BhNmhwN3lHRGJsa2Z2YVZrdnl1VklzNm9z?= =?utf-8?B?K0p6L3JqeUNBenpacU1LYVg0U3pueTNXT2tDdWFOK1I4UVY5RnFtNHpWMkhr?= =?utf-8?B?Z2ZuZGQ4RmN3NlVJYmJUR1NVNG9ZRDcvdWxldFdlZFA3S3d3Q04waU1oZXJu?= =?utf-8?B?Y1V1TGg5K0dwMVBQVXdsb1hNa2ZOWWFhQmNSUVA1UkxDaDFaWFJEM1JGY3l6?= =?utf-8?B?VnBQaFM5aDc2Q05uTE1pTW1lMUhBYWhrT3o4MHR5cnp5cVU0MGpha0s2TjIr?= =?utf-8?B?M05xV1d2QkR4K3JTdzRyMnhubCs2Z0k5V1V6dGxvb3drZ0Q2WUpzc3oyNGxh?= =?utf-8?B?YWY4U1ZySDFsZGozd2x3YmRiTWNCMm1NTGVCYTMwSllscjVTckJRNUJmbnE3?= =?utf-8?B?aGVzNTdTOVMzM3BOKzk5V1QralNOUnEwL3lybHVMczNJbG0ySW5FREdmSFRU?= =?utf-8?B?QzlWZVJEcFErc3QrRVpLU0JsekxCbi8yWkxLRTd0OWNHRFVFTGlNd3hSRUNE?= =?utf-8?B?cmNBZzVpRU96SFg2aHFKbVBZT3ZPdXU2Mzk0bGkrR2hDcXVpbzhla0QrZXlq?= =?utf-8?B?NGh5eitOV2Y0a09YWGErcmZVZ29nNnVveHFtRkwrdWs1MmdvTE1ra3F2RjZr?= =?utf-8?B?cTh3RTEzdElJdnd5MmJuRG1XYTZCOGxCOFYzS3dkYmZSd1Awc2svMGhIcHZj?= =?utf-8?B?ZGJ0elFmejVFT1dWajM0M2k0KzcrN215ZUplTlIyM3FPNDdhSzNUZThhOE1C?= =?utf-8?B?b2JkRy92QlhsZnFHVlJuVGZidllMY0hMQ25pMUY2aU5xTzN5MGt4N0NUMjZw?= =?utf-8?B?UStaemFSbUpLOEhEOTh3b3haM3lCa3VkZndmSjRqdEk1RHBURCtvbHlwaDJO?= =?utf-8?B?bEVWeWJCVWoxTkVlL05NTVN4ZzJ0blhUU2VLZk5ObEhLd3RET05LQm9YYUJM?= =?utf-8?B?UmtSWGpoVzNKbW55enBBNWxna0hLWlF6VlgrRjNObDhJU21LY1RnaUx3S292?= =?utf-8?B?ZzQ2VHp0eENaVEZZMWlaWTdvRTc5N21BT3lmT0szTTZweEtHZEJYT01UNXo5?= =?utf-8?B?L3gzRVBVQ3B5OC9xb1lkN0dKWkNkbFNJVGgzK0I3Vy9oeCt4Yk8zS1ZvNkVH?= =?utf-8?B?ZEV5MlQ3WDU3S2R1eFNzdWJxWCs5VlBUTDkxMURNeERadkpLS3dHQ3VvY0ph?= =?utf-8?B?Qjg2eDFIaFlnRnpWeXFiUWhnZVNuOVJOVXZ2M2tpSHc1NWpRUm5nbE55UkFU?= =?utf-8?B?NFczSU40K2dDamREZkoycHNlUDQ1c3pYZGs5eGxRdVdyZ2NCcGU2cnFaZVUr?= =?utf-8?B?TnRJaDlkQWkzQldUMndwMlE0RXQzbHRNdk81SlBqUDBXcUpZQUZuQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3f4b9e16-1246-4f07-d405-08de58caee76 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 08:56:14.3081 (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: y5vsz8oq8ggld0EyBbCZTgcWUJ5MsXh1hDGE3ycQ8sLcuK8usraGx3Ga9+6lj8scPWNNMOysuhuHkMjCQk4hhw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR03MB7009 On Mon, Dec 08, 2025 at 04:18:14PM +0800, Jiqian Chen wrote: > 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; Nit: I think you could narrow the scope of end and define it inside the if ( vpci->msi ) { ... } block? > + 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); Strictly speaking (also in the previous patch), we only need to do this hiding for the hardware domain. For domUs access to the control register would be ignored by default. Would you be OK to add an: if ( !is_hardware_domain(pdev->domain) ) return 0; Ahead of the call to add the vpci_hw_read16 trap register? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 21 08:58:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 08:58:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209461.1521448 (Exim 4.92) (envelope-from ) id 1viU37-0003Cj-7n; Wed, 21 Jan 2026 08:58:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209461.1521448; Wed, 21 Jan 2026 08:58:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viU37-0003Cc-4d; Wed, 21 Jan 2026 08:58:49 +0000 Received: by outflank-mailman (input) for mailman id 1209461; Wed, 21 Jan 2026 08:58: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 1viU35-0003Az-KV for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 08:58:47 +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 651057e5-f6a7-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 09:58:46 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by LV4PR03MB8210.namprd03.prod.outlook.com (2603:10b6:408:2de::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 08:58:43 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Wed, 21 Jan 2026 08:58: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: 651057e5-f6a7-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lEHFnL4gKFIO5QwwTWLZYRkNQjcs6SzrGsV6iTl33he3mRJ+YDhYzVvMyVmOiTj1pvDcEEai1EFD7T6S4++NeRzCsYbeRYdri5rvqRBK+yicRRmemOYaBuV6NEJG9kbNLmSXyqUTbHbzY9zIXSMIdLclBZN7cUGReamY7p68/z7vswrB2o93xdyvdG40nJh7CkclrhZqdgxr9YdCLQG/5eiPXuC9B/rNXKS9kB3PlAqrsCqDfc/C8TSJzl7bGyh1kWxo2n+zUM/K27mqHNXwOTw9B4tkJ9n7c7KpaCHhgIHT3uoKFFpa0TxB5A6IVXvxDao4m26klorBwTF//qPmug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CMuGCgRmH5MgxUN6mJfbu884doXdknrIKiMb/spnFNY=; b=EAqUXfd33DRgk+yYly3vG8lOyYJwPfcK+LRjE4KNaeE96bEQiEppk9Yfa+SzqbvM/Sq2OXr+Zi89Ak2E3iyIvuYC5Fu815dRAV0uxj3BPJCkK2ZWL90iGNRLGm3dCMtISWTICEN74Ju5C/FXVymMwIzrNg5kbW2SLvIiUmbZX/djUO+eXLMtGl3Wf6m3sURX2UAVHOmUwICoCqQqG7WV2DPVp/0JH0Kyek+kdjyQoluk4ldTR04ME66NIuHvKALH7gjMpsySdfWi9nLEhwNJfIt+H27z2uOQWHhYP88G08azigr0cQ3OqEYxNWj/YE8Lbp5ZesM7PYQCvKnphrOoIA== 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=CMuGCgRmH5MgxUN6mJfbu884doXdknrIKiMb/spnFNY=; b=R/Ns7dWyhobDIxoocd3RiAWzN0z9FTf/19ipFF4Rtc7VFr/p41H/c01t5wezDSZoHl7cdiJds+d7Ce7NcZkmkPKAjn4TeNuAD8Hc8guIVvXbScT4rXgN/+I2QgtYfKDfA8gl3nqaSNmQGfk/XDfiNTawclMk84Yjay0U7Ke8oQY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <388ef292-d0c5-4942-8760-b3666ebbb991@citrix.com> Date: Wed, 21 Jan 2026 08:58:39 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] x86/CPU: extend is_forced_cpu_cap()'s "reach" To: Jan Beulich , "xen-devel@lists.xenproject.org" References: Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0116.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2c3::16) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|LV4PR03MB8210:EE_ X-MS-Office365-Filtering-Correlation-Id: c107c157-7833-43bc-fb95-08de58cb4723 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?VXN1YUp4NzBJQnp6OEhpUWVlWEtwclp6cjhWTjhXY0ZrWXRFM3FnVndVUi9u?= =?utf-8?B?MEZQdWdrN2hpTlVuWnlkQ3VEbUxPaW5jdVRMOEVJK0NIbWhTM3JIWmRjRFFi?= =?utf-8?B?aFJCY09CL2tTYk5SMXZaSFBjUkl2eSsvcGpCVjNzNjlFTlJtaTFNQTU2SUJG?= =?utf-8?B?NUpkYS9kdEsrVU5HcmE1b0k3QjFRN1JCN2NKelB1b3VzeXE1ejF4TFpZK2Z4?= =?utf-8?B?aVpGYTlMUGllbnFkU1ZQVTFpbUtOMnJpN1JwSWppM2RGZnNNKzMrdURrYWx5?= =?utf-8?B?ZllqYzBhYzJGeWp5N2RBZ3NUdnJDK1p3VXpRNlpCTzBQdks5bVR2UyttMUl0?= =?utf-8?B?aHFsR0Fqb1ZyUGFFTDNrMk8zQVY0c2s0b1MwSWQvYUVzQVN1NWd1RUUwb3BF?= =?utf-8?B?aTNSR3UrUVVNTk5IQnNoV3VZWTJJK2ZjM3RxV2tKblNxSDRZK3RtcDV0SVN1?= =?utf-8?B?OHZ4aEpZUTFRSkFxeDlsWHcyM0c1cm5QdnJxSEJWaUlIRk13ZGYveS9SZ1l4?= =?utf-8?B?R2ZTWWZBMHBBcFY5SGYrWFl1eTg2V1FpeFRGTGFGa0FZVys4TmtFenVyU0w4?= =?utf-8?B?NFYrNThUMlZnNTR3RGdPYzVoQ3d4SWhZcHhyMjFSTUVWZjJhVDRCZi9ob0Js?= =?utf-8?B?QVdXUHdKSXVBSDRHbWQ1c1Uxb205WHpFUTdBd3ExMC9uWEFWMzRxVGdYaWFR?= =?utf-8?B?OHNLa09nbUZ3dEQ3TlNsM2x1ckRXZUlCSmhMY1NmUXExQmIyWUp3MmgzWjBI?= =?utf-8?B?SFZJaHBJbnVURFBFVk9ha2FWVUgwNGR5ZmZrQUtNcWlqUDF6YXRDb2lReFJZ?= =?utf-8?B?QUZFMXNBRldIbVRoM2NRL1EySTNxd2tQamhIL3BLbTZwMzJpQUJrdUFLc05X?= =?utf-8?B?b1VObEI1RUxXY1I1R1AyWVhtSzlBM3BHQkZzRy85aTF6elpyZnpIWE5renIz?= =?utf-8?B?Q0RyV0lYSXV1NFZJM2RkMlBlejEwSTNUMno4Q2ZFc09JRmdaVGppQURLMTN6?= =?utf-8?B?N1N6YU9LWUd1ZkpQc1BFVTBjNExheXFHc1ZyOG5rYllSVSttS0FURFdaeVNB?= =?utf-8?B?ak5SS3pXakR2RS9MV2xCS1NMamtTekFBYlU5RHFhcE10NzcxS3pldGR3Ujhu?= =?utf-8?B?R2tyUUI1WEVZc1R2Sm11dDNXOWxiaWRZLzQyU2hCZUNocElHcnpoN2NFd0xm?= =?utf-8?B?U29YOHhDVnZZZGp4VytSM1JWeXdHZHdnUU9LY1U3YXRHT1RoeXNtT21KRFpZ?= =?utf-8?B?MXo5T3ZOU3RRTDY1MmMzUWdwK1Y1QkZYdDUyK1RaaTRTR2JwY1ZhYXBEZlpD?= =?utf-8?B?Mm44MTY3NUc4UFp1c2R5RCtVZ3RHYU9YQ3E3dzlUS3duRU1hRVFINFc3dnZ4?= =?utf-8?B?cUJmS1k1RGdEVmVNQnhPaG5DTHJCdHdMejFQcTZjajNYTCtSOGg0LzlmWVZE?= =?utf-8?B?eDJMMVFrWVdUY0Flb2JVR09sYlZSd0RSdUQveEFYWEg2VmlUQ0syTTF6NDdK?= =?utf-8?B?a2pWM3N3eGVzVmd2a25hVjErUkl3TS9aaFJpZ3lCRU5MeFQ0RGV1QWlhQW10?= =?utf-8?B?MTNGSkZrTzJhM2xWQWpabjBDN21LdGNNUDRQdFJtd0ZpSUZGQXhCdER0Mktw?= =?utf-8?B?NGZldVVyTXo4Wlp3Z0ZPRUUzb0N3aGUxaWRlQ3lJR0s5MDB0WEZ5TlB4WlBM?= =?utf-8?B?aHpoS0dvYldYNXBhc2FKcVFJY2ZqN0ZCcmlpOGZSQ0xMa2tDeUVIbVdTLy9L?= =?utf-8?B?Qko4SUpDZ0N1dkozdkt5UjFuUTI5UXFsUUtHQWV3S2tTWkQzS0Q0cnJic0pZ?= =?utf-8?B?OGxURGNuWk85MS9hSjBqUk5IUGtMZ1hhMGtseVpVemsvOVhLY3pVejBIV2w4?= =?utf-8?B?VTFmVnhVQ1ZwU2pNRy96b2hFNk5PRldncys1L0ErYncvQk45bjF0R0J5alFk?= =?utf-8?B?aXRIN3FKTG5XSWRwSXE5RitGRWtaUWdWQnp0Qy9xNEVrWUl2aGNGMjhna25q?= =?utf-8?B?KzJQb0l4VThJaFRLai9UdTh6S0FPbHpDL2dBNWwxNTRGSnM2U3NPMk9TMnJW?= =?utf-8?B?YmlmbVhUenpkQUluSVJ1Y0ovV2lucDU2a2poN2s1YTAzNjM0WXQ0RG1JTk9D?= =?utf-8?Q?R8M4=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SVVqMkphc0Z6MmJLKzJPRG9RMW9lUzV4NzhSQUNYVUsyQnlrTk13QVVJZk1p?= =?utf-8?B?U2NVWHJtOUdGNkUyeEdscjhsVTlXbnBlTTh3MU9yV1Myd2x3T3VoYllNdEJs?= =?utf-8?B?T0ZaSWsrbDFjV0ZiTGFCbER3bmg3a0JpcXFOMzQwRmN3cjB6U0JVZXpaU2VI?= =?utf-8?B?Mkw5MVNkOGZPMUhiTnYydHJ6ZndpTmhlVnZpU2V1eERLL0o4QTdIY2xTTUlz?= =?utf-8?B?dUJXQlV2Z3FiMkc4WUdKSWZ1dmZYVVlNRW5WMzdJc1Nuc1Y2QW5tSVdNSmdY?= =?utf-8?B?QjV4L1JtUkxTZGxMNkNCc1Qyd1R5QzZzY1o0WkVqc203ZXE0a3ZUeXVUNXZC?= =?utf-8?B?Q1JTQ21aaUNCemFYeVlRNHh2dlp5eDNkbU1ZaXkweHU2MW5JWURQalZGSjhl?= =?utf-8?B?UVpLMGs3QlljbFNCalNiQlp5aEdjMjEra2tRUHU0REtSMHlaK3ZwOGtmZ3lv?= =?utf-8?B?RkVXYzJsaFpMUUNkenZ6Z0J2QVZUTEpKcEc1LzdaWkxoeVFETzh6MnJINERB?= =?utf-8?B?alMrSzR6U1FtZnM1emRFeHd6QmxiU2dKd2RBcnBRdGMzMmJlSHAyYXVYcjkz?= =?utf-8?B?dFdUTVRhR2lVNmJ1T3RmRzF5d0c0V3l2MWFuUisvMU85d1luenJzSmVQcjRF?= =?utf-8?B?RzJTeUkwRDRJbHI1ZWRqbEtDNlFYQVVIZEczWml6RytBODNaanc2Y25XOG10?= =?utf-8?B?empaS2JTN2t6RHp4K3QzZURTVjFoRC9SWFY5WjFCaVR2VHd4eWlPczFBU1da?= =?utf-8?B?SGZLOCtzUUFxMDJ3MnI4Q0lCb0x5K3BxZm9xTkxGblhaNkoxaGRHYWYvUi8w?= =?utf-8?B?NVh2SG9sQzArSGJFdUN3RGRKQzFodURGdVRpcVFHNm9jMHUxSmZhV2pPb0w3?= =?utf-8?B?clR0Q1dXTC96Yi9GeGEyNzVhK0Q0TkRJR2ZxamVrZHVLdEx1UDgrNXBZR21J?= =?utf-8?B?WmxpcDJaekhZTExmM3hxSm5CNDlJdWVMbmpOSmFVYVVBendDTThyY2ZYemlo?= =?utf-8?B?L3lLUkFiMUJKU0ljMHNyWDB0WHlqcUd1TmpEd0RrY2w1ZUtTT3FpUXhjS0pW?= =?utf-8?B?cmFSM252U1B0Zlp1QmlRYTNraW5iOFVSTkpBbXZnU0dTU003c0l2MkZSelMr?= =?utf-8?B?VG1xejk1aFNKZ20xMFlXMjhXc1NVcUtLbVI4eCtra1lxN3NEVFhvMFJpcG9F?= =?utf-8?B?L1E0THIvcnF4R3l6S3FvQUNnOXRWbUR3ZXFqdEkwSGNTY3k4Tk5vUkN4WDd3?= =?utf-8?B?Y0dMZTIzcStWWlR3RTFpUmNWOFZ6WFpOM0lxMEFvREIxMzltVzl3SmR2YjJ4?= =?utf-8?B?Q2VodGp1LzRvdk9KSk0zSzVyZXY1RS9vYW9RanF1NUhta05TL2hPbEVFNW1i?= =?utf-8?B?SHpCTTQzaFZBRktlTlg3Sks4SUQyZldCcW0rbGY0UmlLZTZrdkdQN1ViNXAr?= =?utf-8?B?Tk9TU0lsMGluekxtcXZBQ2tGeXdmSm4wVjhyeDEydm5iQkhuMDNjcU5KMEVy?= =?utf-8?B?VVh0ajFtSjkvT0hMTTRRWFhPcThBWmlmbnZNYktBcGJzQis2aFpzaVlwSlV1?= =?utf-8?B?UDRyZ3A4STlNMzVUa0VGamkxN1BRUFk3b1JuOERVeWRxeVZRZnp0b2lyNnBY?= =?utf-8?B?R3I5SGpQK21YVGwvNXkvNkhEQU4xNnhNbng0ZmtrUVhiLzVMQTNqM1JQeGw2?= =?utf-8?B?VWNVcyt2Rm1kTEkvY21XSm0rWUxtYVN1bTA5NnZRcFNtbklpYWJFRnlqY2N4?= =?utf-8?B?VURlYm1pZWFMUHlLcjhwN1pSUkNWakJaQ01SYzAwcXFwOHdSOVhXNW4zZnRN?= =?utf-8?B?N1Fxa2pscU9XTkV1cFVnWVZyMHdOREhzR1BkSytNa2JMNFV2M2dRNFU3WXl6?= =?utf-8?B?RWQ2T1o1Zk04dU9KR245a3ZoYWh6Nk82NGpKSG9XN0RSVVZRT0oxYnR4dWdV?= =?utf-8?B?QnpRSURzUUFPOFBoc21hcDJvUlFlQ0lJYUJjRDYzUGdzSlVud2FIOVFIUnBs?= =?utf-8?B?OXZmd0Q2UFhtREl3S0xmTEFqbXFmRHhORk1SQkdhWnIrZ0xVK3d3V1R5L2Vu?= =?utf-8?B?QTJlcWxKU2xHQndLSGpSVDg4RjBvSGp6S21IN29JQXVHdzNOSjZXTHNlV0xK?= =?utf-8?B?dE1XOUZ2eEliR1c0NCtPRmh2UmlGMnhQdmQyRDdFbERMcU15bnRlQnRzbFpt?= =?utf-8?B?YkcrYlNuRmRlMUNYWVMwZnBrTmVKTzhkb2tXSjREZGtVSyttQUJuQk5HRU5G?= =?utf-8?B?WGIyMVpFaWZhaGxoQzNEOFB2Ty9Pcm5XZC9vcGNoTnl3bkV5Y3dyZUVRYlhN?= =?utf-8?B?RzVVMHVBZy9STjFXQWpaVU5zMFRQZXJWMzB6UWNpVnBwYzlVQzU0M1g1TkNw?= =?utf-8?Q?cgX92ykpX9ubaB8M=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: c107c157-7833-43bc-fb95-08de58cb4723 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 08:58:43.0380 (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: Cehy43vpOdmWF0AhLlNh1vDsLEt61K1j3lAY/yPn2AgYbwnjDHprPX1AMWtavMrMBRYh8puZK3gFG4Xl9c26LlgEC+jqw0e+Rl/scBn7XcQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV4PR03MB8210 On 04/08/2025 12:28 pm, Jan Beulich wrote: > "cpuid=no-rdrand" cannot actually be used to suppress the respective > boot warning on certain AMD hardware. That's because cleared_caps[] are > only applied after the ->c_init() hooks ran, i.e. cpu_has() still > returns true in init_amd(). > > Fixes: 93401e28a84b ("x86: clear RDRAND CPUID bit on AMD family 15h/16h") > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Wed Jan 21 09:14:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 09:14:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209472.1521457 (Exim 4.92) (envelope-from ) id 1viUI0-0005wu-GY; Wed, 21 Jan 2026 09:14:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209472.1521457; Wed, 21 Jan 2026 09: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 1viUI0-0005wn-Do; Wed, 21 Jan 2026 09:14:12 +0000 Received: by outflank-mailman (input) for mailman id 1209472; Wed, 21 Jan 2026 09: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 1viUHz-0005wh-Nr for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 09:14:11 +0000 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [2a00:1450:4864:20::42b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 88277220-f6a9-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 10:14:04 +0100 (CET) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-4359108fd24so883587f8f.2 for ; Wed, 21 Jan 2026 01:14:04 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4358e24cef3sm10229744f8f.0.2026.01.21.01.14.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jan 2026 01:14:03 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 88277220-f6a9-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768986844; x=1769591644; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=6HzjjKPEIpyXy3gjMXzlNi0Cnx/knsl6TGedTyMHAqo=; b=P0V/cpApz0xcAXCC8kE3H54DmHWBYSpsISlwUY/LA5oYmFwIf/dlp8/V+jAy+7yEMV mGqskOHgntGzjJdME+wUGtHujk7RH92+N/FBKuIhCWcqnTwywWbupoTYX+ooa77qxerp i2Xbsv9CX8ekyVmioRBWrlOV1Vp03pV80d56KI2EgwVsoyijrI3CAbYiX0TKNJUemw6w xZKYjvLM3HCtsWzGThysSqsrK0FnxamjhMBvNc7uMujNRTTtqRTfvq2rkrclAs9Z4Zm+ SYLshXzKNU/C7+TDWn9EoTxKkpfTXsjJFJLtWIVeD9Z5s3wL4VrEmTnIRcig3QUbCAFp +/VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768986844; x=1769591644; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6HzjjKPEIpyXy3gjMXzlNi0Cnx/knsl6TGedTyMHAqo=; b=o3V4yf2W4kUdGIALqjqmDP5/rvYs350dQsElcclGNUN4Z20blVZrLbODxmHpsi5O1V dQ2GUol1+t/OOP0WFmCuFHa71t4Ouv17Yr9RNaBW96JzLUf+ctr8Gg2GfOjscpRjvrz8 xMfttSwnI1faCn4Y5hhrbZGaLna0PBmCef02pZbdg+vKSeIAsAps8maeN+X4cX5TTpHX siNk7sSYu6/3P/fzKVukBjxw6Jg7Xe7yLecrMKT+jlzkOwXUc3FpHghhcIccaO5PEDH0 /Nsmz02lbevkpcMtf/wdBf4ao6T2ihJ3XYZdvza9RmpTnKGuDL7CYyidFkx01jF0Cg1l ugIA== X-Forwarded-Encrypted: i=1; AJvYcCU1fEU2eJlArRe3GKCgTKjAq/zJhiZTQxHEeOfz2JFcqaFlvwieuiGWGU9z30Eu5DA0fqwnpMBklTg=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx8HTzDHon4ZUMqzaHfur9m4P9u1cCv3RKV6w7EalHFbTotyXwV zWeyB8Y+1Yhn7uG+skV1O6Y/2Ut1T3y1aNc6y1P8KiAFN++hf9TIwc4YFidJ77cb9Q== X-Gm-Gg: AZuq6aLekG6Un4irE3D9OCT6J0vRouFaClEXcKGwDlwLbF3742uj1QAlwMOORYD4HTN 7dSxSGBp0qIj/QHMYksDN5vy2vwXBrIfM+TGGQnO3BmlatVCjh3Gbsum1DQR9rm2nh4g1RXBt7b I+OG922ZKbi+xdjZ6V3CGtMa9BUAIzkGtR8N5r3gcgQTsl7tCF9QHPmLk7332cm8Pt5WnrapjY2 G8bOobkypfpoaU0MJUhJlKQ5JkAKX746mrz1KPF2umPwdHQa1CUTPSmtL6a4bH1pC4vXxtr47o9 kNG6hD5TQtyNxTBieowy0WDWDhKL6AC+e+3RPQYcYo54+M//hvhm9LdWdHqPm+Frxjr6t8zvS0x gDRDqufza0yN7Dkuz5rsPxT8frwKnQQaV2ELUWu6lBKy2M6uOwdOcZ92x09U9LNUY5pjycpxjAi +mhTdDFbbd1Cx6+HER3g77HEJKjWE8CUtRNZ129vwPcGVbVhH79saRKfk7hhj2phfq1km1oe+Y1 ZM= X-Received: by 2002:a05:6000:2c10:b0:435:9522:2bc2 with SMTP id ffacd0b85a97d-43595222e62mr6184110f8f.38.1768986843725; Wed, 21 Jan 2026 01:14:03 -0800 (PST) Message-ID: <637ad4a0-bc8f-4e75-8906-643f28f94a2b@suse.com> Date: Wed, 21 Jan 2026 10:14:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen: Expose time_offset in struct arch_shared_info To: Tu Dinh Cc: Anthony PERARD , Andrew Cooper , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk , xen-devel@lists.xenproject.org References: <20260120095657.237-1-ngoc-tu.dinh@vates.tech> <3213454a-38cd-4e5d-8a30-853e37f70c18@suse.com> <7a61a16c-93d7-4cc2-bc47-11e236cf83fb@suse.com> <9df8cf47-d3ec-474e-b1c8-7978e55627d6@vates.tech> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 20.01.2026 17:06, Tu Dinh wrote: > On 20/01/2026 16:39, Jan Beulich wrote: >> On 20.01.2026 16:27, Tu Dinh wrote: >>> On 20/01/2026 13:42, Jan Beulich wrote: >>>> On 20.01.2026 13:12, Tu Dinh wrote: >>>>> On 20/01/2026 11:35, Jan Beulich wrote: >>>>>> On 20.01.2026 10:57, Tu Dinh wrote: >>>>>>> time_offset is currently always added to wc_sec. This means that without >>>>>>> the actual value of time_offset, guests have no way of knowing what's >>>>>>> the actual host clock. Once the guest clock drifts beyond 1 second, >>>>>>> updates to the guest RTC would themselves change time_offset and make it >>>>>>> impossible to resync guest time to host time. >>>>>> >>>>>> Despite my earlier comments this part of the description looks unchanged. >>>>>> I still don't see why host time (or in fact about any host property) should >>>>>> be exposed to guests. >>>>> >>>>> I've answered this question in a followup reply from November, which >>>>> I'll reproduce here: >>>> >>>> I did read your reply, yet nothing of it appeared here as additional >>>> justification. >>> >>> Is the new description OK for you? >> >> Which new description? So far I only saw your responses to my questions, not >> an updated patch description. >> > > Maybe my last email wasn't clear, it was in the part marked "Follow up", > reproduced below: > > Xen currently does not expose the host's wall clock time in shared_info. > This means while shared_info can be used as an alternative to the > emulated RTC, it can't be used to keep the virtual wall clock in sync. > Expose the time_offset value in struct shared_info in order to allow > guests to synchronize their own wall clock to that of the host. > > This is needed because on Windows guests, the PV drivers don't control > the timing of RTC updates, as this is done by the kernel itself > periodically. If the guest's internal clock deviates from the RTC (e.g. > after resuming from suspend), a RTC write would cause time_offset to > deviate from the supposed value (timezone offset) and thus cause the RTC > to become incorrect. What I still can't extract from this is why Windows running bare-metal is fine but Windows running on Xen's vRTC isn't. If there's a problem with our vRTC, shouldn't that be addressed there? Also, just ftaod: If other maintainers find this convincing, my failure to understand shouldn't get in the way. They may still approve this change, i.e. I'm not vetoing it. It's just that as of now I also wouldn't ack it. Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 21 09:17:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 09:17:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209484.1521467 (Exim 4.92) (envelope-from ) id 1viULU-0006Zw-VH; Wed, 21 Jan 2026 09:17:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209484.1521467; Wed, 21 Jan 2026 09:17:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viULU-0006Zp-SJ; Wed, 21 Jan 2026 09:17:48 +0000 Received: by outflank-mailman (input) for mailman id 1209484; Wed, 21 Jan 2026 09: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 1viULT-0006Zj-QF for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 09:17:48 +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 0b784f89-f6aa-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 10:17:45 +0100 (CET) Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18) by SJ2PR12MB8133.namprd12.prod.outlook.com (2603:10b6:a03:4af::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 09:17:42 +0000 Received: from BL1PR12MB5849.namprd12.prod.outlook.com ([fe80::53da:e77e:261e:5a29]) by BL1PR12MB5849.namprd12.prod.outlook.com ([fe80::53da:e77e:261e:5a29%5]) with mapi id 15.20.9542.008; Wed, 21 Jan 2026 09:17: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: 0b784f89-f6aa-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=OVNyafOquDZ6r3wqR6eAq2ZgQxslIcyzeGrOKBifFjn9LnEyMgLnaDjTbAiS5M+Q5gFLqb7P8gVuHlvgdh89SbeqLFum0h3hLWbXpPcZDW1OWUYAPnaBCCPvi2OYMVCATJpfU6GJJQqlqpWMwT2cNeSh5Gb/tlFKdtzAtw8teHjQjV8kUihwpVkZYmSukvVx2pkMH551hDwn9ImIhK3JDGgCCbwXI2VrhccEF+Kb5NnXy6x7+Pcm8qG95St0OI7lV/srS1QPMLGyo7zje3Y1LjHc+mth1+uHIEGpDhPFowmOi4G5FHc9QU6Lk+UhsJMFf9EarzCkPPj8cU7BfRUz7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uocHU4LzLMLoUS9x6jLgMdGbCEpafNB+1BukWes3N9A=; b=bnwmZP/jr2OCb98+CaK/I/ICv24ezDEeHQNORfrGEz84w9HrBRY+rYG1LlZLSOk4kMl73QQVFWQWxemH2w3phT9NnHRcaCYPnPZINrrc6W1j0NKtRBvWMItj1irODWsZ/FaXsKYrzfiyncSUIuVfjy5ypyu4td1WHN7dWzB3atsArlLYiNt6htz9m/Nt+pXG0Bcsb7nCV/W818h7SLwyC/ZNkmJmwaBvXLuSRoaNDSm/TBoh0j5L35m/a+57Sbkeq8NHTD7kDBfF9IeWLs8a4FelYutMRkWVf449lq5KOx4M8RwXgsox4LNER9JREbcD5M2FecpxJMyccZUk/onK3w== 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=uocHU4LzLMLoUS9x6jLgMdGbCEpafNB+1BukWes3N9A=; b=HkARCpIrwgP5lKXSPLyQuyt7S0dVtdmtHQO8S8jRToNb6ELiWNTkyB93Ox6XzZMRDMFlYcbf+wZMg1BvOaYdBskonqgf5XrrPSJFOPkWEg2TrY/hN0EBBuCPTQec4JwgKS7n1TSKEhHm6Pd5nOa0GuGN9/DY/g0enY+sxNr6A34= From: "Chen, Jiqian" To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= CC: "xen-devel@lists.xenproject.org" , "Chen, Jiqian" , "Huang, Ray" Subject: Re: [RESEND PATCH v12 2/3] vpci/msi: Implement cleanup function for MSI Thread-Topic: [RESEND PATCH v12 2/3] vpci/msi: Implement cleanup function for MSI Thread-Index: AQHcaBtBN3StFxVxMUK3Tlwpczk4lLVcl12AgACLCwA= Date: Wed, 21 Jan 2026 09:17:41 +0000 Message-ID: References: <20251208081815.3105930-1-Jiqian.Chen@amd.com> <20251208081815.3105930-3-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.9542.003) 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_|SJ2PR12MB8133:EE_ x-ms-office365-filtering-correlation-id: bd8ff779-9c05-4460-1398-08de58cdee17 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?cDJzcVM0VTlkYTlYcnU2V0ZXQ1pGZnB5WkJMRlIyZmgrSTNTZGpCamQ2UUdk?= =?utf-8?B?SWVrTTBxeTZOc1lyVTBCWEFMVjUyUFZwWXFhdlZCRXRFVFYrWXBPS3FLL0Y3?= =?utf-8?B?b3N2dGRTL0c0bGpKdFZkN010MkcycXRMRnlZUmYwcDcyUUNLdk1MYzJKRlFM?= =?utf-8?B?dVpmMlJ2SjZOdGZMdzhhTzFkR1IrRnR4MWlxendSalIxTUF2OVlyVzlBeXE1?= =?utf-8?B?NCsrSWQvWFdJbWRnYWxiRVptU2lndFV1UFNxTThBdGVTQ2pibHNSYXhycWdK?= =?utf-8?B?VUJyU2piYUtxa1RIS1NhODBPWFcvSUhIK3JkN0lkdGx3UVU5YTV1dmxmamVa?= =?utf-8?B?Ym85UDNOSTZ5a2h2RXNNN3Fhem9qaGtJc2QrQURaUDMwWE16WGdtbUhTSFNU?= =?utf-8?B?cTJvZGl0RzlocGt0bU9mdmpuUHlaZFRPa0F5QzR0TERQN0k2NnFubWVxVlYv?= =?utf-8?B?c01qQlZMZGRMREdsV3JjZnFJek9SVFhIMENJYmUzNzFVM3FuNTFkVzU4d3pR?= =?utf-8?B?QWI0RUpDUEsySmg5blg5NEV1OE9idkZPd2dHbVNtQ0RGVmZFYXdoQkJIY0lt?= =?utf-8?B?dmZ5QjVXeGtudXBJWTR0akZkSTVvZksrVXNpWExqcTJTZWlHUzlmTm1yMUFL?= =?utf-8?B?MkExRkFub3ZENmNuSTRvcDZ2MFFSVWxzQjhRTW1IWDZzcTd6QzJ0Y2R5QU92?= =?utf-8?B?OVRuZEhNaXdDSHJOL1V4TC9ZS2h4MjdiQzEwcjNnMVFXWVZVRUI2M2l3SXR5?= =?utf-8?B?R3AzUmJsMW1zZW1lZHhmaXkxUHJITENxcFkxN05oV0RtdmVZNklrOTJlZm5l?= =?utf-8?B?MDdoZjhSTHAxMDlYTllNNzFTaFV1d1lJSzd4UXQzb0VOcVZpcWhoS0NhRkZo?= =?utf-8?B?MDhLYTZNeWxqSEl1cXlSZXlWS2UvQysxVkRTcENWSXZXT2RVWVZjRVJ0TzlD?= =?utf-8?B?aTZ0T0xNU1JMcmhWajJHRnR3Mi8wcjBCOUxKVkRCaTY5Zm9BRXh2STh1SUY1?= =?utf-8?B?SS9LLzZWaUxQM3BPSGFsUUxKcjhaWVZ6US9CQ2VLZVhnNGdaOWZYQThMUk9L?= =?utf-8?B?YzNxSHlCdEdKUWR4T1lHUzFVTHlaVG45aDZ5VWJ0OHN1WGhmcWxjTTZuRGZH?= =?utf-8?B?ZXhudEkyekRkWkw3L1pWY0Jxbk9LV3o1MXR0RUxNM1dlYXp5TEhVK2U3ME5i?= =?utf-8?B?eVlMaklIenJFcDd4YTA5WE9mbWwyeW5adGhOaGdMTTZqWW5uMXIvZitiZU5z?= =?utf-8?B?aWxKZ1JudVV2ekFPOEJpOEl0aEc5WHFpdll2UXpZTGcvWjNKZysvTzRrOFd2?= =?utf-8?B?aVdNZ3VsaGR6b010U1VuRDlXTWJLSjYxM3p0UUFOOEhDdE1zYklrOFgxYUdl?= =?utf-8?B?OU1MOHJrR2V2YmZYKzI0T3k1OHQ2dGw5eGRGbTQxQ3RjMzZmUHhWNW9VSnpZ?= =?utf-8?B?U2FQRktWM0s1Ym5tazdobTg0a3ZFVmZMcW5MQWJCUFBzTklvMkt3Y1JySFFC?= =?utf-8?B?T3RDU2pTbUh2Y1kzbE1XbGNia2YwejdaS0xrc0VVaUFseVBNck5sN3dqd3l4?= =?utf-8?B?eHBENmdQWUx2dHU5QW9nN0hpWXJuNEtIc3hlelRDY3BEZVVqVWk0b0lPS0g2?= =?utf-8?B?Z1dnMGdyK05udjBuY1JhZ1Q1bTVLUEhBOU5vV1dWMjUrMzBQanJ3bkpZbGJS?= =?utf-8?B?NHFvMy96Vm0wZjhwU1JtZmh3c0NpY2hoaFRoSVZMNVY4a0c3OTE0SjZQbmEw?= =?utf-8?B?NWZ5dkp1NVVVcmltL1ZBREdTRDJQQ0hsVUQralVaOGVzZVlqY3ZCWkZreWsr?= =?utf-8?B?ZTUyc21INkZSM1M4RDUzSFZteW1VV1hhRlBaVEw2YTJyL2lVV0N0bUtIQjZH?= =?utf-8?B?eEcrNm5oOGJnRFRCN2syME5zRFBEcHRWVGw3aVdSamNQV3JEWWE1c0lpK0Ni?= =?utf-8?B?aFNoU2tuY1IvY1hMYTVINjY5cVlmU3RWcFM1R09ISGRqR2xrOVFKTXBFRGZE?= =?utf-8?B?QTRQYU1rd3RKdlhhSXk3Unl6YlJrVnhCZ3J6Z1hydWJRcmZuYnFsOXI5bWRR?= =?utf-8?B?TGlhSGw4eVdTYzFPNzNHbWoySHFNTXdxdUlmakUyLzUzdkQ2cnJKK1dPZkhi?= =?utf-8?B?bG5kQ1FsdkIyenZiUGpobVdFNXp4c2FoV1NSQzdyZTVWT1gwUTVSQmpCeVhD?= =?utf-8?Q?6x2BDH6E7TevVDx4gXGD1y0=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?TGpObFozR3FvVU9RcDVpdVlFRGxvVllHVldMM0VKNHphM1VxWW84Ny81M0sx?= =?utf-8?B?N3hiMFZCM3FpT0x0N0FCa0ZLbisrUkwxZFdPLzJpTnM3RHVodFlpeEhPME0w?= =?utf-8?B?K1BSMTl6Z0hBTy8zeEZnSW9JZ0JkRE10T2RxQXI5UEt1STN4a2N0eVFaVWxH?= =?utf-8?B?Y3ZSc2JFUVFnR1laa2V4d2hiSUZMcHdQMHdKbm9HcFBPeklhVFVrZk45bzBC?= =?utf-8?B?VEd0dytnak5OVENYa3NMUDJMbndPcHo5TFJYd2ZpZkNEOXl5MzVBSmlPb09h?= =?utf-8?B?ZzUydklhU2dEb1BUZDhLU0dqZ3hOVGtUK1VqdGVVdDZIUldzT3dhN3lGOFJr?= =?utf-8?B?SWVjdTd6bzJNdkZyS3VZSURjNkNLcmVsTFNLUGh1bFF6Qk1RLzJ3Y3p1VG9j?= =?utf-8?B?c0o2OXg1NW1CeDBkZmhvclo1VnNFS3dYRFJvcG1SZ0Y2RFRmZHZBeXdIZDdX?= =?utf-8?B?MFVEVVFaTUw1NFVpSzdzQzM1TEx4YTF3WEV5c0orZjJwcGJQV1k4L25mYWJ2?= =?utf-8?B?MWlWb0luMTR2ODNRNG81d1JWMXdtcEU2dnBYZDN4TmN6dHBHK2lpakdhdTdh?= =?utf-8?B?QzVsWTZ3aWJidHBTSmpoVGtDejdmUWtTN3UwVFdic290Y1cwTGgyRHZ5T3dR?= =?utf-8?B?emFHd1NoVnB3clh6YzlzMFhUeWp2R2pheTJLeEhpYVpMNHRScFByaTFVcDFK?= =?utf-8?B?d000VXNpWTlUQnR0QUNSNEVEV2w2emFVeEFTcHJUSGM2N3o5RXFDTm9DS3E1?= =?utf-8?B?MDdjYS9iYzNpaE1pZXc0KzVJNy85UitvWTEyamV2K21KRGlCQUlOWUVhTXNz?= =?utf-8?B?R1NkVlJtMW5ZL2s0bGxTd0ZjR1kzeWJIUnlCbDFzZkFOOTE4MURWSzF3c0Rw?= =?utf-8?B?ek0vNGYvMzdOSzVMOCsxUGRvRVQ0Vlhwb0VKUkoyQ0E1bEUvSk5wOE16bGVr?= =?utf-8?B?L3NaL3d1dVFETThCWFFOWjRneHgycGp1cGZta0ptbGlRc3JVbC9xc1dBS0hk?= =?utf-8?B?cmNJZ0lubmpoQnFwY215L0d0RHcyTm8zM1U2SlM3MDJONzNvZkZsYWwwZ283?= =?utf-8?B?Y3V6cEZKdTA1Vm5pK2RYUW0wbW9HZjNxWGMzVE5SU3BEMWFIOEtBUmVNOHBP?= =?utf-8?B?MUUyYXhsUDAzK0djMzU1bzRqcjRneWlYTThRSEU0bWVaNFpISTgwL0psbEtO?= =?utf-8?B?WnU1VGNzZCtvZEw5RkxHQkx0N2JkVjVOMFd0NW0vMG9uNzhlSnNCN3lXMWc4?= =?utf-8?B?NGpOeTFqMFBjRXFzdzdLcHR5WVAxN1R2V3plRXQxR2dWS3grNjE4YWY3WkNK?= =?utf-8?B?TTRlWWhyMzRQMnhmbmwwK0YxMG5tSnFkd1Y2VldwdDNMWlVLbm02L0ZtaXpn?= =?utf-8?B?bDZSNG9jTGsrNVdvdUdnRythR3FhL3pFYzV4a0EyYjVIbnpvWTk3RzZ2NTF4?= =?utf-8?B?dTBodlFhY1VWRjVSZ21kYzdEdXZvRXFIUDRScHhDMXJsNXFMeHIwWk1QTkNI?= =?utf-8?B?d1RHU2R1ZlZvTWx6NDlFRUEyKzI2STJZdFdtTXhIemxBaFlaZ0JjTjFVL3A2?= =?utf-8?B?d2wyWnptRjBUL1UrZEJoREtjeUZvOU5YLzhPTGlsQXFuTmhwRTQwbHdpUFZB?= =?utf-8?B?UVNFS3VJNFZMTVdTMVJmc2VGUVNrVElTdXFEOHMvZWFGVUUxRXM3NFRYcVNO?= =?utf-8?B?NFNIeVE2U3dORmh3VEhnZHlZVTRBczhvMXY2ZURXQWJocG8zYXZ3MTNEeEx2?= =?utf-8?B?eDI1VkZPbWFXYitrdERpMUlDOXBVblVxWUkrbWI0L256YVhKQk1oVG1DaHhW?= =?utf-8?B?NnFEMytYbEZQZ2M5bTVUSzNTRmYxTFF1T3NXd0R2anR3YTBVSWJBQmVFQlp4?= =?utf-8?B?OG1Bd296Q2tOZ010OWpEb0FRWjZwTVg0aGkyV0s4YW5iMEFLR0pXcnVTM00w?= =?utf-8?B?bzhnZmxldW5nSzhIK1dYejllbGNYcVd1UkF4dDVHOXJuakJkVG9ZUmZmOFNV?= =?utf-8?B?cjQxcmIyOEhHYWpUNnQzL0pWMTN1RDVFNHM3RW1QYmI4U0FvSTJ1S0VZZTJv?= =?utf-8?B?dXNKN1Y4U0xmWW5odVZqbUl5aERwTDZxVXRTK0NqV0lDeVNGbFpBNDNZUk1F?= =?utf-8?B?N09scG1nRUlPNWVLUWtwZXhheEYyRmdiOGlISzBYUmdxUmN4Vm01eXRVN1I5?= =?utf-8?B?dFJFVS9DNDhlZGcycERKaG93bXY0MlhDcEI3QjBVYXRRUmNwQ083RHFrczRr?= =?utf-8?B?R1BiZWdQcjZBL2JUL2FtMVFuRGVKNEVHemoyZUhaVlNlS2dQKzJ2MTdzOHBD?= =?utf-8?Q?KDT0e+NdvFkjoFPw6I?= 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: bd8ff779-9c05-4460-1398-08de58cdee17 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2026 09:17:41.8752 (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: 7p+ZspWyQDjSFlFpetSpxi0grM9bwn0SUbGAnlLikSDxz3ak3yMeor8GxsEJp5FMXxc4ZA77ngcPRRRdRNF6ZQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB8133 T24gMjAyNi8xLzIxIDE2OjU2LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOg0KPiBPbiBNb24sIERl YyAwOCwgMjAyNSBhdCAwNDoxODoxNFBNICswODAwLCBKaXFpYW4gQ2hlbiB3cm90ZToNCj4+IFdo ZW4gTVNJIGluaXRpYWxpemF0aW9uIGZhaWxzLCB2UENJIGhpZGVzIHRoZSBjYXBhYmlsaXR5LCBi dXQNCj4+IHJlbW92aW5nIGhhbmRsZXJzIGFuZCBkYXRhcyB3b24ndCBiZSBwZXJmb3JtZWQgdW50 aWwgdGhlIGRldmljZSBpcw0KPj4gZGVhc3NpZ25lZC4gU28sIGltcGxlbWVudCBNU0kgY2xlYW51 cCBob29rIHRoYXQgd2lsbCBiZSBjYWxsZWQgdG8NCj4+IGNsZWFudXAgTVNJIHJlbGF0ZWQgaGFu ZGxlcnMgYW5kIGZyZWUgaXQncyBhc3NvY2lhdGVkIGRhdGEgd2hlbg0KPj4gaW5pdGlhbGl6YXRp b24gZmFpbHMuDQo+Pg0KPj4gU2luY2UgY2xlYW51cCBmdW5jdGlvbiBvZiBNU0kgaXMgaW1wbGVt ZW50ZWQsIGRlbGV0ZSB0aGUgb3Blbi1jb2RlDQo+PiBpbiB2cGNpX2RlYXNzaWduX2RldmljZSgp Lg0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6IEppcWlhbiBDaGVuIDxKaXFpYW4uQ2hlbkBhbWQuY29t Pg0KPj4gLS0tDQo+PiBjYzogIlJvZ2VyIFBhdSBNb25uw6kiIDxyb2dlci5wYXVAY2l0cml4LmNv bT4NCj4+IC0tLQ0KPj4gdjExLT52MTIgY2hhbmdlczoNCj4+ICogSW4gY2xlYW51cF9tc2koKSwg bW92ZSAiaWYgKCAhaGlkZSApIiBhYm92ZSB2cGNpX3JlbW92ZV9yZWdpc3RlcnMoKQ0KPj4gICBz aW5jZSBkZWFzc2lnbiBkZXZpY2Ugd2lsbCBkbyByZW1vdmluZyByZWdpc3RlcnMgaXRzZWxmLg0K Pj4gKiBSZWFkIGFkZHJlc3M2NCBhbmQgbWFzayBpbmZvIGZyb20gaGFyZHdhcmUgc2luY2UgdGhl eSBhcmUgbm90IHJlbGlhYmxlDQo+PiAgIHdoZW4gaW5pdF9tc2kgZmFpbHMuDQo+Pg0KPj4gdjEw LT52MTEgY2hhbmdlczoNCj4+ICogQWRkIGhpZGUgcGFyYXRlbWVyIHRvIGNsZWFudXBfbXNpKCku DQo+PiAqIENoZWNrIGhpZGUsIGlmIGZhbHNlIHJldHVybiBkaXJlY3RseSBpbnN0ZWFkIG9mIGxl dHRpbmcgY3RybCBSTy4NCj4+ICogRGVsZXRlIHhmcmVlKHBkZXYtPnZwY2ktPm1zaSk7IGluIHZw Y2lfZGVhc3NpZ25fZGV2aWNlKCkuDQo+PiAqIFJlbW92ZSBSb2dlcidzIFJldmlld2VkLWJ5IHNp bmNlIHBhdGNoIGNoYW5nZS4NCj4+DQo+PiB2OS0+djEwIGNoYW5nZXM6DQo+PiBOby4NCj4+DQo+ PiB2OC0+djkgY2hhbmdlczoNCj4+ICogQWRkIFJvZ2VyJ3MgUmV2aWV3ZWQtYnkuDQo+Pg0KPj4g djctPnY4IGNoYW5nZXM6DQo+PiAqIEFkZCBhIGNvbW1lbnQgdG8gZGVzY3JpYmUgd2h5ICItMiIg aW4gY2xlYW51cF9tc2koKS4NCj4+ICogR2l2ZW4gdGhlIGNvZGUgaW4gdnBjaV9yZW1vdmVfcmVn aXN0ZXJzKCkgYW4gZXJyb3IgaW4gdGhlIHJlbW92YWwgb2YNCj4+ICAgcmVnaXN0ZXJzIHdvdWxk IGxpa2VseSBpbXBseSBtZW1vcnkgY29ycnVwdGlvbiwgYXQgd2hpY2ggcG9pbnQgaXQncw0KPj4g ICBiZXN0IHRvIGZ1bGx5IGRpc2FibGUgdGhlIGRldmljZS4gU28sIFJvbGxiYWNrIHRoZSBsYXN0 IHR3byBtb2RpZmljYXRpb25zIG9mIHY3Lg0KPj4NCj4+IHY2LT52NyBjaGFuZ2VzOg0KPj4gKiBD aGFuZ2UgdGhlIHBvaW50ZXIgcGFyYW1ldGVyIG9mIGNsZWFudXBfbXNpKCkgdG8gYmUgY29uc3Qu DQo+PiAqIFdoZW4gdnBjaV9yZW1vdmVfcmVnaXN0ZXJzKCkgaW4gY2xlYW51cF9tc2koKSBmYWls cywgbm90IHRvIHJldHVybg0KPj4gICBkaXJlY3RseSwgaW5zdGVhZCB0cnkgdG8gZnJlZSBtc2kg YW5kIHJlLWFkZCBjdHJsIGhhbmRsZXIuDQo+PiAqIFBhc3MgcGRldi0+dnBjaSBpbnRvIHZwY2lf YWRkX3JlZ2lzdGVyKCkgaW5zdGVhZCBvZiBwZGV2LT52cGNpLT5tc2kgaW4NCj4+ICAgaW5pdF9t c2koKSBzaW5jZSB3ZSBuZWVkIHRoYXQgZXZlcnkgaGFuZGxlciByZWFsaXplIHRoYXQgbXNpIGlz IE5VTEwNCj4+ICAgd2hlbiBtc2kgaXMgZnJlZSBidXQgaGFuZGxlcnMgYXJlIHN0aWxsIGluIHRo ZXJlLg0KPj4NCj4+IHY1LT52NiBjaGFuZ2VzOg0KPj4gTm8uDQo+Pg0KPj4gdjQtPnY1IGNoYW5n ZXM6DQo+PiAqIENoYW5nZSBkZWZpbml0aW9uICJzdGF0aWMgdm9pZCBjbGVhbnVwX21zaSIgdG8g InN0YXRpYyBpbnQgY2ZfY2hlY2sgY2xlYW51cF9tc2kiDQo+PiAgIHNpbmNlIGNsZWFudXAgaG9v ayBpcyBjaGFuZ2VkIHRvIGJlIGludC4NCj4+ICogQWRkIGEgcmVhZC1vbmx5IHJlZ2lzdGVyIGZv ciBNU0kgQ29udHJvbCBSZWdpc3RlciBpbiB0aGUgZW5kIG9mIGNsZWFudXBfbXNpLg0KPj4NCj4+ IHYzLT52NCBjaGFuZ2VzOg0KPj4gKiBDaGFuZ2UgZnVuY3Rpb24gbmFtZSBmcm9tIGZpbmlfbXNp KCkgdG8gY2xlYW51cF9tc2koKS4NCj4+ICogUmVtb3ZlIHVubmVjZXNzYXJ5IGNvbW1lbnQuDQo+ PiAqIENoYW5nZSB0byB1c2UgWEZSRUUgdG8gZnJlZSB2cGNpLT5tc2kuDQo+Pg0KPj4gdjItPnYz IGNoYW5nZXM6DQo+PiAqIFJlbW92ZSBhbGwgZmFpbCBwYXRoLCBhbmQgdXNlIGZpbmlfbXNpKCkg aG9vayBpbnN0ZWFkLg0KPj4gKiBDaGFuZ2UgdGhlIG1ldGhvZCB0byBjYWxjdWxhdGluZyB0aGUg c2l6ZSBvZiBtc2kgcmVnaXN0ZXJzLg0KPj4NCj4+IHYxLT52MiBjaGFuZ2VzOg0KPj4gKiBBZGRl ZCBhIG5ldyBmdW5jdGlvbiBmaW5pX21zaSB0byBmcmVlIGFsbCBNU0kgcmVzb3VyY2VzIGluc3Rl YWQgb2YgdXNpbmcgYW4gYXJyYXkNCj4+ICAgdG8gcmVjb3JkIHJlZ2lzdGVyZWQgcmVnaXN0ZXJz Lg0KPj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+IEppcWlhbiBDaGVuLg0KPj4gLS0tDQo+PiAgeGVu L2RyaXZlcnMvdnBjaS9tc2kuYyAgfCA1NSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrLQ0KPj4gIHhlbi9kcml2ZXJzL3ZwY2kvdnBjaS5jIHwgIDEgLQ0KPj4gIDIgZmls ZXMgY2hhbmdlZCwgNTQgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkNCj4+DQo+PiBkaWZm IC0tZ2l0IGEveGVuL2RyaXZlcnMvdnBjaS9tc2kuYyBiL3hlbi9kcml2ZXJzL3ZwY2kvbXNpLmMN Cj4+IGluZGV4IGMzZWJhNGUxNDg3MC4uMTgxZWM5MDJkZmZiIDEwMDY0NA0KPj4gLS0tIGEveGVu L2RyaXZlcnMvdnBjaS9tc2kuYw0KPj4gKysrIGIveGVuL2RyaXZlcnMvdnBjaS9tc2kuYw0KPj4g QEAgLTE5Myw2ICsxOTMsNTkgQEAgc3RhdGljIHZvaWQgY2ZfY2hlY2sgbWFza193cml0ZSgNCj4+ ICAgICAgbXNpLT5tYXNrID0gdmFsOw0KPj4gIH0NCj4+ICANCj4+ICtzdGF0aWMgaW50IGNmX2No ZWNrIGNsZWFudXBfbXNpKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2LCBib29sIGhpZGUpDQo+ PiArew0KPj4gKyAgICBpbnQgcmM7DQo+PiArICAgIHVuc2lnbmVkIGludCBlbmQ7DQo+IA0KPiBO aXQ6IEkgdGhpbmsgeW91IGNvdWxkIG5hcnJvdyB0aGUgc2NvcGUgb2YgZW5kIGFuZCBkZWZpbmUg aXQgaW5zaWRlDQo+IHRoZSBpZiAoIHZwY2ktPm1zaSApIHsgLi4uIH0gYmxvY2s/DQpXaWxsIGNo YW5nZS4NCg0KPiANCj4+ICsgICAgc3RydWN0IHZwY2kgKnZwY2kgPSBwZGV2LT52cGNpOw0KPj4g KyAgICBjb25zdCB1bnNpZ25lZCBpbnQgbXNpX3BvcyA9IHBkZXYtPm1zaV9wb3M7DQo+PiArICAg IGNvbnN0IHVuc2lnbmVkIGludCBjdHJsID0gbXNpX2NvbnRyb2xfcmVnKG1zaV9wb3MpOw0KPj4g Kw0KPj4gKyAgICBpZiAoICFoaWRlICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgWEZSRUUodnBj aS0+bXNpKTsNCj4+ICsgICAgICAgIHJldHVybiAwOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAg IGlmICggdnBjaS0+bXNpICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgdWludDE2X3QgY29udHJv bCA9IHBjaV9jb25mX3JlYWQxNihwZGV2LT5zYmRmLCBjdHJsKTsNCj4+ICsgICAgICAgIGJvb2wg YWRkcmVzczY0ID0gaXNfNjRiaXRfYWRkcmVzcyhjb250cm9sKTsNCj4+ICsNCj4+ICsgICAgICAg IGlmICggaXNfbWFza19iaXRfc3VwcG9ydChjb250cm9sKSApDQo+PiArICAgICAgICAgICAgZW5k ID0gbXNpX3BlbmRpbmdfYml0c19yZWcobXNpX3BvcywgYWRkcmVzczY0KTsNCj4+ICsgICAgICAg IGVsc2UNCj4+ICsgICAgICAgICAgICAvKg0KPj4gKyAgICAgICAgICAgICogIi0yIiBoZXJlIGlz IHRvIGN1dCB0aGUgcmVzZXJ2ZWQgMiBieXRlcyBvZiBNZXNzYWdlIERhdGEgd2hlbg0KPj4gKyAg ICAgICAgICAgICogdGhlcmUgaXMgbm8gbWFza2luZyBzdXBwb3J0Lg0KPj4gKyAgICAgICAgICAg ICovDQo+PiArICAgICAgICAgICAgZW5kID0gbXNpX21hc2tfYml0c19yZWcobXNpX3BvcywgYWRk cmVzczY0KSAtIDI7DQo+PiArDQo+PiArICAgICAgICByYyA9IHZwY2lfcmVtb3ZlX3JlZ2lzdGVy cyh2cGNpLCBjdHJsLCBlbmQgLSBjdHJsKTsNCj4+ICsgICAgICAgIGlmICggcmMgKQ0KPj4gKyAg ICAgICAgew0KPj4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICIlcGQgJXBwOiBmYWls IHRvIHJlbW92ZSBNU0kgaGFuZGxlcnMgcmM9JWRcbiIsDQo+PiArICAgICAgICAgICAgICAgIHBk ZXYtPmRvbWFpbiwgJnBkZXYtPnNiZGYsIHJjKTsNCj4+ICsgICAgICAgICAgICBBU1NFUlRfVU5S RUFDSEFCTEUoKTsNCj4+ICsgICAgICAgICAgICByZXR1cm4gcmM7DQo+PiArICAgICAgICB9DQo+ PiArDQo+PiArICAgICAgICBYRlJFRSh2cGNpLT5tc2kpOw0KPj4gKyAgICB9DQo+PiArDQo+PiAr ICAgIC8qDQo+PiArICAgICAqIFRoZSBkcml2ZXIgbWF5IG5vdCB0cmF2ZXJzZSB0aGUgY2FwYWJp bGl0eSBsaXN0IGFuZCB0aGluayBkZXZpY2UNCj4+ICsgICAgICogc3VwcG9ydHMgTVNJIGJ5IGRl ZmF1bHQuIFNvIGhlcmUgbGV0IHRoZSBjb250cm9sIHJlZ2lzdGVyIG9mIE1TSQ0KPj4gKyAgICAg KiBiZSBSZWFkLU9ubHkgaXMgdG8gZW5zdXJlIE1TSSBkaXNhYmxlZC4NCj4+ICsgICAgICovDQo+ PiArICAgIHJjID0gdnBjaV9hZGRfcmVnaXN0ZXIodnBjaSwgdnBjaV9od19yZWFkMTYsIE5VTEws IGN0cmwsIDIsIE5VTEwpOw0KPj4gKyAgICBpZiAoIHJjICkNCj4+ICsgICAgICAgIHByaW50ayhY RU5MT0dfRVJSICIlcGQgJXBwOiBmYWlsIHRvIGFkZCBNU0kgY3RybCBoYW5kbGVyIHJjPSVkXG4i LA0KPj4gKyAgICAgICAgICAgICAgIHBkZXYtPmRvbWFpbiwgJnBkZXYtPnNiZGYsIHJjKTsNCj4g DQo+IFN0cmljdGx5IHNwZWFraW5nIChhbHNvIGluIHRoZSBwcmV2aW91cyBwYXRjaCksIHdlIG9u bHkgbmVlZCB0byBkbw0KRXh0ZW5kZWQgY2FwYWJpbGl0aWVzIGFyZSBub3QgZXhwb3NlIGZvciBk b21VcyBjdXJyZW50bHksIGFuZCBhbGwgdGhlIHBsYWNlcyBjYWxsIGNsZWFudXBfcmViYXIgYWxy ZWFkeSBjaGVjayAiIWlzX2hhcmR3YXJlX2RvbWFpbihwZGV2LT5kb21haW4pIiwgc28gcmViYXIg bWF5IG5vdCBuZWVkIHRoaXMgPw0KbXNpeC5jIG5lZWRzIHRoaXMgdG9vLCBJIHRoaW5rLg0KDQo+ IHRoaXMgaGlkaW5nIGZvciB0aGUgaGFyZHdhcmUgZG9tYWluLiAgRm9yIGRvbVVzIGFjY2VzcyB0 byB0aGUgY29udHJvbA0KPiByZWdpc3RlciB3b3VsZCBiZSBpZ25vcmVkIGJ5IGRlZmF1bHQuDQo+ IA0KPiBXb3VsZCB5b3UgYmUgT0sgdG8gYWRkIGFuOg0KPiANCj4gaWYgKCAhaXNfaGFyZHdhcmVf ZG9tYWluKHBkZXYtPmRvbWFpbikgKQ0KPiAgICAgcmV0dXJuIDA7DQo+IA0KPiBBaGVhZCBvZiB0 aGUgY2FsbCB0byBhZGQgdGhlIHZwY2lfaHdfcmVhZDE2IHRyYXAgcmVnaXN0ZXI/DQpPSywgd2ls bCBjaGFuZ2UgaW4gbmV4dCB2ZXJzaW9uLg0KDQo+IA0KPiBUaGFua3MsIFJvZ2VyLg0KDQotLSAN CkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0KDQo= From xen-devel-bounces@lists.xenproject.org Wed Jan 21 09:21:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 09:21:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209497.1521477 (Exim 4.92) (envelope-from ) id 1viUOm-00089N-Hn; Wed, 21 Jan 2026 09:21:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209497.1521477; Wed, 21 Jan 2026 09:21: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 1viUOm-00089G-Ez; Wed, 21 Jan 2026 09:21:12 +0000 Received: by outflank-mailman (input) for mailman id 1209497; Wed, 21 Jan 2026 09:21: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 1viUOl-000899-Ix for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 09:21:11 +0000 Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [2a00:1450:4864:20::443]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 85f596f5-f6aa-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 10:21:10 +0100 (CET) Received: by mail-wr1-x443.google.com with SMTP id ffacd0b85a97d-4327790c4e9so3815840f8f.2 for ; Wed, 21 Jan 2026 01:21:10 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435996540cesm4270963f8f.43.2026.01.21.01.21.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jan 2026 01:21:09 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 85f596f5-f6aa-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768987270; x=1769592070; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=vfjQgxm4n9abxdeNdftR2RZkYcKEtwary1CnpBEn1Ys=; b=TeEv5akJ7xudRW3KEX/bAiQGNgwdWJJfReJSZM7YbBdebgoR0qqDoPwy+CplDuG6Kr 6tCNLzU7pq4STXGLNdX8SE2Jhinmximb/dNMyUOsXrYTntyhjXPqMTw04RTVJ92QdOA4 IVCxvD5g9vLUIICIQEZ86B3f1gax8td4zfkHqFXJYlQSjZXAODe6/4VTazGmXrpYEdhI 55gmWrsuqav2NC9xkyux1vKFiRn5Nncx1cIVOrdmG/NkJfUqa9xXGiRyjkgbJsAcqrPP z8ZDeGCsHblDXB0pIjr9yHUQ4BYG+jTFAI4q3vTS09QF1gHdBQZaoQy5RpG7f+ihOYSH HLQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768987270; x=1769592070; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vfjQgxm4n9abxdeNdftR2RZkYcKEtwary1CnpBEn1Ys=; b=fA/cZaFTWSU1+j2RWi1Qbp9ZwxRw94SgbvCEj8D0VefemO8h+7rXAHe7nCg1Fdfkez 6A8iBkmDpl3V7thGJ0i6IshrBqIllrCb1PUKSe3Rrbm+2qrc0gkva0RLEVZwBrcJi+5b go4VDTMZ90ORn0HFKVWSbQlVzpQT2HX/O2FxC/s2mEWcTgYc8ECXd78s6TMM7lHlujqr xhuEu5GfWlGOv5mym5ypyC1hAxUr1JYpHwOfr9Z6l4z4tOZ2lIsydgHkUJA0IJ1Pipeo EDR/0Zhw8cVEucVZa100YNCtygoYVC9XtTtPcYApTYHHwV5ZF2tbmXqT/YO8bs3qYILx 6uDw== X-Forwarded-Encrypted: i=1; AJvYcCXorIe4KHGGIQ6feoySJD2v1zTVYdJmRtAv04BPnJIQ7Xv2S16ksl5pIcuD65Cc5LFlk+c8K/UgdRk=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxf8mB3pQ/5Y7FPogW4pJwbTRizhgcsGV3kMqZJwhuJvpWowm0P eEi8haU2ZleSAgWW3ZubKzQsBwwsvoYId6hbsuBWBlR3nlMrOfIVs6UHeKg72U/hzw== X-Gm-Gg: AZuq6aKE2dyBU0ss5O8VA9R1cRJNhseu9CZf+6Z1PacXI/tVYZYN96vKCDXYel+qbQJ 8Jn3g8qR1IpRNJ3As8oAlb1YD0qjSYL6wL+pCHNNY5dqxLj/k9CnXqzHUWUsjmLxmr0EbULHCEn EbDFUhjdoti4LzmqoQ2l9fx3uC/vnUsQ5F1nwj/OEw1TZpUB/kszb1rEvK8c2b8KLl3EPtvJoQX WZ2R3Jy9JlHMiQkYTDJWeBHvKNf+BI1Y3OfaB2dXWSKXSz6XntDCCcsXCzpOwS9yBArH1R5o9cv nt9Cj00zLfSDT8bhKLcFwCXoh0uXEgygaRfPHZcuf4ITE+bWA7z899TbxMVZynOr2Kh9+hJm3oI 6Bx4HMX/3aSQG2E4sX3SpI5XjcgdycU/zaeelfSmpn3a+YELlfMyW2DW7kl5mrHRbh54seki2NY MKja4X241yhIbiR0cBDMdO/1wW0BHp7cX3dt/gYHSgeFe47Kcs70HpSC8JOzTYFL1wLAOjajGGl k8= X-Received: by 2002:a05:6000:1aca:b0:435:a135:7776 with SMTP id ffacd0b85a97d-435a1357a1emr1158004f8f.61.1768987269660; Wed, 21 Jan 2026 01:21:09 -0800 (PST) Message-ID: <7cb0a7c3-7f00-4bf7-8d2d-88e46d9f23cb@suse.com> Date: Wed, 21 Jan 2026 10:21:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] INSTALL: remove unsupported XEN_CONFIG_EXPERT from documentation 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: <20260120185904.979992-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: <20260120185904.979992-2-dmukhin@ford.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 20.01.2026 19:59, dmukhin@xen.org wrote: > From: Denis Mukhin > > Remove XEN_CONFIG_EXPERT explanation and also correct information in > the entire "Xen Hypervisor" section. > > Amends: 37339ba9ef46 ("automation: Remove XEN_CONFIG_EXPERT leftovers") > Suggested-by: Stefano Stabellini > Signed-off-by: Denis Mukhin > --- > Changes since v3: > - text correction suggested by Jan > - Link to v3: https://lore.kernel.org/xen-devel/20260120071654.640873-3-dmukhin@ford.com/ > --- > INSTALL | 19 ++++++------------- > 1 file changed, 6 insertions(+), 13 deletions(-) Yet sadly the A-b was now lost. No need to re-submit just for this, though. Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 21 09:24:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 09:24:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209510.1521489 (Exim 4.92) (envelope-from ) id 1viUSF-0000Gz-1R; Wed, 21 Jan 2026 09:24:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209510.1521489; Wed, 21 Jan 2026 09:24: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 1viUSE-0000Gs-TS; Wed, 21 Jan 2026 09:24:46 +0000 Received: by outflank-mailman (input) for mailman id 1209510; Wed, 21 Jan 2026 09:24:45 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viUSC-0000G0-Sq for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 09:24:45 +0000 Received: from mail187-33.suw11.mandrillapp.com (mail187-33.suw11.mandrillapp.com [198.2.187.33]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 047a298b-f6ab-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 10:24:43 +0100 (CET) Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail187-33.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4dwzL14QVxzBsTlVv for ; Wed, 21 Jan 2026 09:24:41 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 21f11a052a8b4be2bb0127288a1f1759; Wed, 21 Jan 2026 09:24:41 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 047a298b-f6ab-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1768987481; x=1769257481; bh=cv2SMcAX98AyU28O0Hlj/72KU32pmfoNEhIbQqbLB/c=; 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=iY2yhbGae7poL6oTiVZZ7bzdD4pgQxblAWjitavkeRTekyaIArnzx2ftuAk6HLbJw Mhdj/OC1lzJRt4YETYG/kLXWxfidOyIVn3yvlW/DmsodFOjx7uwdOU1VLlyx3AdODR Fi0i17V66tSfKh/LMON9ZQlFl7fj9B21ilbk7wOEMDEVdeUumBtxlK5/UuJ57xw6Rk 4KBzUYLVOH9TxBhseDGPhRIhH8qeMkKzHQr0vPGRbTpsS5uyGbupODT0CJtxf+eZig iourTPnCyfrZwCQk97RP3WJlYaLxe4DNpTUencgPNglIBZ6xhY0MpPSAV0UxEh9e2r LNcJIiUJQdkpA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1768987481; x=1769247981; i=teddy.astie@vates.tech; bh=cv2SMcAX98AyU28O0Hlj/72KU32pmfoNEhIbQqbLB/c=; 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=XU6OOZFT4s5SMR3iHsGA5GpEcN5dm2pbdYSgvrKkM7+bYo3Df7EWEXLDlr1E/XCO6 VLrSJkWWznWLXG1AhsqIg65w6v1qLk6vZNdm0VF4htRG5CcQ4TWBRz/BhYtRHqwVpZ dSbi6KjazJa9v4p0P9AR+TPKrdXW348Lqkkvo/dPWQvBUeK7cZsO3KkDd0I93XBFr6 KDNS2Bb+f+crQ2ZeaY/WXhl/AwzoSmc1Ka95QwCtnRqfdM/mecX4JaB5aVVbsJkRLe 5q6qArkWWrHVLtIXKFvu1aMnGnuvRDVCg95NwhmjpYYY4/da84bxkE5Wo17zk4cVW1 CMvLEEykpY+Vw== From: "Teddy Astie" Subject: =?utf-8?Q?[PING][RFC=20PATCH=20v2]=20x86/hvm:=20Allow=20pre-enabling=20x2apic=20mode=20on=20BSP?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1768987480338 Message-Id: <33b95315-1c7c-4be7-872f-27e8b16efb5a@vates.tech> To: xen-devel@lists.xenproject.org Cc: "Anthony PERARD" , "Juergen Gross" , "Andrew Cooper" , "Jan Beulich" , "Alejandro Vallejo" , "Grygorii Strashko" References: <0cb4d1f91212a65baf924ed0ef825d8adb4b5423.1762958551.git.teddy.astie@vates.tech> In-Reply-To: <0cb4d1f91212a65baf924ed0ef825d8adb4b5423.1762958551.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.21f11a052a8b4be2bb0127288a1f1759?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260121:md Date: Wed, 21 Jan 2026 09:24:41 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 12/11/2025 =C3=A0 15:51, Teddy Astie a =C3=A9crit=C2=A0: > Introduce a new option to start the BSP vCPU in x2APIC mode instead > of xAPIC mode. Expose this in xl through a new "x2apic_mode" option. > > Signed-off-by: Teddy Astie > --- > Cc: Andrew Cooper > Cc: Jan Beulich > Cc: Alejandro Vallejo > Cc: Grygorii Strashko > > Later on, we could consider with this option to use x2APIC ACPI > tables instead of xAPIC ones. > > There is also some room into introducing a new Kconfig option to > only support x2apic mode, which would change how the "Xen default" > would behave. > > changed in v2: > - only pre-enable instead of forcing > - use domain builder to pre-enable instead of introducing a new domain = creation flag > > v1: > - https://lore.kernel.org/xen-devel/d498a50f6187b362ac5da3c6a7a7c348f35dc= 4b3.1761761288.git.teddy.astie@vates.tech/ > --- > docs/man/xl.cfg.5.pod.in | 16 ++++++++++++ > tools/include/libxl.h | 8 ++++++ > tools/include/xenguest.h | 4 +++ > tools/libs/guest/xg_dom_x86.c | 42 ++++++++++++++++++++++++++++++++ > tools/libs/light/libxl_types.idl | 1 + > tools/libs/light/libxl_x86.c | 4 +++ > tools/xl/xl_parse.c | 11 +++++++++ > 7 files changed, 86 insertions(+) > > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in > index ad1553c5e9..0f7a89fe92 100644 > --- a/docs/man/xl.cfg.5.pod.in > +++ b/docs/man/xl.cfg.5.pod.in > @@ -3198,6 +3198,22 @@ option. > > If using this option is necessary to fix an issue, please report a bug. > > +=3Ditem B > + > +Sets the x2apic mode of the domain. The valid values are as follows: > + > +=3Dover 4 > + > +=3Ditem B<"default"> > + > +Use default Xen LAPIC behavior. > + > +=3Ditem B<"pre_enable"> > + > +Initially enable x2apic for the BSP of the domain. > + > +=3Dback > + > =3Dback > > =3Dhead1 SEE ALSO > diff --git a/tools/include/libxl.h b/tools/include/libxl.h > index bc35e412da..9850e8aa41 100644 > --- a/tools/include/libxl.h > +++ b/tools/include/libxl.h > @@ -1537,6 +1537,14 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst= , const libxl_mac *src); > */ > #define LIBXL_HAVE_XEN_PLATFORM_PCI_BAR_UC > > +/* > + * LIBXL_HAVE_X2APIC_PREENABLE > + * > + * libxl_domain_build_info contains a boolean 'arch_x86.x2apic_preenable= ' field > + * to initially set the BSP LAPIC in x2APIC mode. > + */ > +#define LIBXL_HAVE_X2APIC_PREENABLE > + > typedef char **libxl_string_list; > void libxl_string_list_dispose(libxl_string_list *sl); > int libxl_string_list_length(const libxl_string_list *sl); > diff --git a/tools/include/xenguest.h b/tools/include/xenguest.h > index c88958faa9..408a0c77e8 100644 > --- a/tools/include/xenguest.h > +++ b/tools/include/xenguest.h > @@ -223,6 +223,10 @@ struct xc_dom_image { > /* If unset disables the setup of the IOREQ pages. */ > bool device_model; > > +#if defined(__i386__) || defined(__x86_64__) > + bool preenable_x2apic; /* 1 makes x2APIC enabled initially, 0 keeps = default Xen behavior */ > +#endif > + > /* BIOS/Firmware passed to HVMLOADER */ > struct xc_hvm_firmware_module system_firmware_module; > > diff --git a/tools/libs/guest/xg_dom_x86.c b/tools/libs/guest/xg_dom_x86.= c > index a82b481a12..43ada5a6ac 100644 > --- a/tools/libs/guest/xg_dom_x86.c > +++ b/tools/libs/guest/xg_dom_x86.c > @@ -58,6 +58,9 @@ > #define MTRR_TYPE_WRBACK 6 > #define MTRR_DEF_TYPE_ENABLE (1u << 11) > > +#define APIC_BASE_EXTD (1UL << 10) > +#define APIC_BASE_ENABLE (1UL << 11) > + > #define SPECIALPAGE_PAGING 0 > #define SPECIALPAGE_ACCESS 1 > #define SPECIALPAGE_SHARING 2 > @@ -1131,6 +1134,45 @@ static int vcpu_hvm(struct xc_dom_image *dom) > } > } > > + if ( dom->preenable_x2apic ) > + { > + struct { > + struct hvm_save_descriptor header_d; > + HVM_SAVE_TYPE(HEADER) header; > + struct hvm_save_descriptor lapic_d; > + HVM_SAVE_TYPE(LAPIC) lapic; > + struct hvm_save_descriptor end_d; > + HVM_SAVE_TYPE(END) end; > + } lapic =3D { > + .header_d =3D bsp_ctx.header_d, > + .header =3D bsp_ctx.header, > + .lapic_d.typecode =3D HVM_SAVE_CODE(LAPIC), > + .lapic_d.length =3D HVM_SAVE_LENGTH(LAPIC), > + .end_d =3D bsp_ctx.end_d, > + .end =3D bsp_ctx.end, > + }; > + const HVM_SAVE_TYPE(LAPIC) *lapic_record =3D > + hvm_get_save_record(full_ctx, HVM_SAVE_CODE(LAPIC), 0); > + > + if ( !lapic_record ) > + { > + xc_dom_panic(dom->xch, XC_INTERNAL_ERROR, > + "%s: unable to get LAPIC save record", __func__= ); > + goto out; > + } > + > + memcpy(&lapic.lapic, lapic_record, sizeof(lapic.lapic)); > + > + lapic.lapic.apic_base_msr |=3D APIC_BASE_ENABLE | APIC_BASE_EXTD= ; > + > + rc =3D xc_domain_hvm_setcontext(dom->xch, dom->guest_domid, > + (uint8_t *)&lapic, sizeof(lapic)); > + > + if ( rc !=3D 0 ) > + xc_dom_panic(dom->xch, XC_INTERNAL_ERROR, > + "%s: SETHVMCONTEXT failed (rc=3D%d)", __func__,= rc); > + } > + > /* > * Loading the BSP context should be done in the last call to setco= ntext, > * since each setcontext call will put all vCPUs down. > diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_ty= pes.idl > index d64a573ff3..9fdf89d88b 100644 > --- a/tools/libs/light/libxl_types.idl > +++ b/tools/libs/light/libxl_types.idl > @@ -738,6 +738,7 @@ libxl_domain_build_info =3D Struct("domain_build_info= ",[ > ("arm_sci", libxl_arm_sci), > ])), > ("arch_x86", Struct(None, [("msr_relaxed", libxl_defbool), > + ("x2apic_preenable", libxl_defbool) > ])), > # Alternate p2m is not bound to any architecture or guest type, as = it is > # supported by x86 HVM and ARM support is planned. > diff --git a/tools/libs/light/libxl_x86.c b/tools/libs/light/libxl_x86.c > index 60d4e8661c..f9725f069a 100644 > --- a/tools/libs/light/libxl_x86.c > +++ b/tools/libs/light/libxl_x86.c > @@ -555,6 +555,9 @@ int libxl__arch_domain_init_hw_description(libxl__gc = *gc, > libxl__domain_build_state *s= tate, > struct xc_dom_image *dom) > { > + if (libxl_defbool_val(d_config->b_info.arch_x86.x2apic_preenable)) > + dom->preenable_x2apic =3D true; > + > return 0; > } > > @@ -818,6 +821,7 @@ int libxl__arch_domain_build_info_setdefault(libxl__g= c *gc, > { > libxl_defbool_setdefault(&b_info->acpi, true); > libxl_defbool_setdefault(&b_info->arch_x86.msr_relaxed, false); > + libxl_defbool_setdefault(&b_info->arch_x86.x2apic_preenable, false); > libxl_defbool_setdefault(&b_info->trap_unmapped_accesses, false); > > if (b_info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM) { > diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c > index af86d3186d..92bf9d2ad5 100644 > --- a/tools/xl/xl_parse.c > +++ b/tools/xl/xl_parse.c > @@ -3040,6 +3040,17 @@ skip_usbdev: > "WARNING: msr_relaxed will be removed in future ver= sions.\n" > "If it fixes an issue you are having please report = to " > "xen-devel@lists.xenproject.org.\n"); > + > + if (!xlu_cfg_get_string(config, "x2apic_mode", &buf, 1)) { > + if (!strcmp(buf, "pre_enable")) > + libxl_defbool_set(&b_info->arch_x86.x2apic_preenable, true); > + else if (!strcmp(buf, "default")) > + libxl_defbool_set(&b_info->arch_x86.x2apic_preenable, false)= ; > + else { > + fprintf(stderr, "Unknown x2apic mode \"%s\" specified\n", bu= f); > + exit(EXIT_FAILURE); > + } > + } > > xlu_cfg_get_defbool(config, "vpmu", &b_info->vpmu, 0); > I haven't received a feedback on this. Aside the eventual future use of x2APIC ACPI tables, are there objections for this patch ? -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Wed Jan 21 09:25:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 09:25:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209515.1521498 (Exim 4.92) (envelope-from ) id 1viUSg-0000g1-84; Wed, 21 Jan 2026 09:25:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209515.1521498; Wed, 21 Jan 2026 09:25: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 1viUSg-0000fu-5R; Wed, 21 Jan 2026 09:25:14 +0000 Received: by outflank-mailman (input) for mailman id 1209515; Wed, 21 Jan 2026 09:25: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 1viUSe-0000G0-JQ for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 09:25:12 +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 15722a0e-f6ab-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 10:25:12 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by CH5PR03MB7813.namprd03.prod.outlook.com (2603:10b6:610:211::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 09:25:08 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Wed, 21 Jan 2026 09:25: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: 15722a0e-f6ab-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mlqGnG6NsyYX9eMkan5UlZCWuwR90AqqNTi+UPCl5bK4+plv9Oogw6qsCCVrksa4GLEJo9x7IUGOSu87bDWD9TwinrDLdVuLLtGY2zjinT7/+HuNCDpMK72D2ydJwI7H1YFMfiZIO3I00ZvGPyCHnvie25tUSlmVL1QM7rjglFTCJbXaBbKbQiyWQWWHoyXxHbY418Tk2QVrriycLxZdr8f/+aoSI1YESdXgIQS0eNbIcAI+/B9sglBH+75cdm1CsSm3XtOfhvWSjHOMXTEm7gWIAbmlF0PujJd3TylFtuAKPJWkSrNLp1fdp+H7amql4J6wJCXejlS+ONWBlRZ35Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=g8r1lcbXfsVh1K6p3d0MIQfigTu3wxvHHlPVRDjCrEA=; b=t8Q1hYLGj90hktHDxYh04WFqNctF+sNzVgJ1RsJt/W8qRZIu28YA5TUMoanFLwTRV/+wFluBTKkqiGlcwB04TQCabQZXpllm7D4xQn3BzYFv+kScP3k7KOF07FI6MO/wwd8baIwZPbRhZulkyPgjKI6/UWiTOO73rYvokIuv5orXxvZ1/nx+LnytZ5maKjdTBkW2EMH/GH5yyiL4CcwvMNu5c68KWUsVP7jUbe2xy5JPFAIaRbnaHCiKnbcai/kzZoG2dLHcVzZXaPaAd8HWPRG2l1uuw33tUyHKKWyx8gWZa8gfCu8BXvZT5TohJr0u3oibds9NfAtD4TL0T8VPiw== 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=g8r1lcbXfsVh1K6p3d0MIQfigTu3wxvHHlPVRDjCrEA=; b=nV2BD7jMCqQtI0rqZrgMrnS+kqSrjElnZ76CjMB3O7TPnqMfld4vUEJHX807gOoEXDoKux33JNAN7BsLu8GxoqfMp8IfldSdtAUYXQwtWNNwOYUeDsBDA4iIOcW3/uCQZlxWVDaFhWIa75LtzEwKQerbjsTN7C8v3AT1EZ7laAM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 21 Jan 2026 10:25:05 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jiqian Chen Cc: xen-devel@lists.xenproject.org, Huang Rui Subject: Re: [RESEND PATCH v12 3/3] vpci/msix: Implement cleanup function for MSI-X Message-ID: References: <20251208081815.3105930-1-Jiqian.Chen@amd.com> <20251208081815.3105930-4-Jiqian.Chen@amd.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20251208081815.3105930-4-Jiqian.Chen@amd.com> X-ClientProxiedBy: MA3P292CA0001.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:2c::7) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|CH5PR03MB7813:EE_ X-MS-Office365-Filtering-Correlation-Id: 0e4e5ba1-4ffb-4b0f-4711-08de58cef812 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?OGwvZFNiYlNCNVhONlFDMkdJMHRuSDRMZkZrTHJ3MmV6MFhTTWFNVVByNjg0?= =?utf-8?B?Nis5TDYzUEJUMUllKzFiNmNTbFNuSklxa0NnbzB1VTdCeTVBNWEyN1Y5a2tn?= =?utf-8?B?aVpvcnI1SWdQd3h6TnJpQWhHem1WOFEzZmRTc1pQcHZXZ3hMYnJMVWpCLy96?= =?utf-8?B?MEh6bko1M3JlZmk5TmlUSzBpejFqbnMxanZTYXlNKzhXQytrczB1ZVpzOUc3?= =?utf-8?B?cE1ibWRMNWQ2NjBHQnAvTEdUbnZRRXNRekFxY0FoQW54dEljUVZCODRHQ01H?= =?utf-8?B?cXVCYzZOYUxnVi9Nclh6T1NSMFRBSTJ6ZFI2Y1RmYjl5WTRoakZWQTJBcHI0?= =?utf-8?B?Uk5BZU5mRDZjUVBjM0VGTTVxTEUwbFc3eFBDc2RwNW5qRHJVMnpKSUNtUFF4?= =?utf-8?B?MjJwUkQ5cHVuQWoyM04zREhCclRyUGRjL0FLR3prdTY4ZkNzbm1HVjlZZWVZ?= =?utf-8?B?SWhlRE5DZ29EZ3hzUGh2Y0cvZjFlV1VUNjh0UXVyMXJCREhuZHFNUkRjVEpw?= =?utf-8?B?eUVHdG93VVIvSGFwK2lTV014dERKYmcrUFBHT3VSY2pHMXBSNW02cllWRVMw?= =?utf-8?B?cVFvNlBodDE2L200R2J6TVkweTVKM3lZcGkrN3NlaXBMeFRZYzd4RnhGNy81?= =?utf-8?B?WDNpOEQwY1ZVUmlOMXNEclFhR2JJNVJDZHNYQVJJbUFEYmh1UXFFUW4wUExp?= =?utf-8?B?R0pBUngrWk1xbEhlUjlFeWNqUlhqd0NZemFrL1JUbk0wT0s4UkNaMFZWOTZX?= =?utf-8?B?d2tNT0dhanlXdVg0VTRjaGNZZDdVZWRWd2hWQVNYZjZEdDYvUkpaay9lOE5z?= =?utf-8?B?NTlKZXUyeVBxbWY2d1lHYnFQR3FlQk9LRmVvbGk0Rmp6WmZkTGI0RUxrN0Qw?= =?utf-8?B?QkNCUGNIVmprMzJnS3hZR0hSVlZiS283eS9iMHpzcWNEODZJVnV6elhmVnJl?= =?utf-8?B?NU03SzFiNGhwbEkvbHBQb0RLR2wwWUJlYjU3eE0zRk9VWmtHQ29hbHBONnRk?= =?utf-8?B?eUVUTUY1OVBmcmxWU053eXc4WHFUdUpaZVhaVzdiWWdacjNDY1REdVFyTXVX?= =?utf-8?B?ekNuQ29sS3ZMUXFQMEJJSFR5V3VwbEdpYWpkaUVVMkVDcmw4N0pXa2ZaNitX?= =?utf-8?B?ZVlMVW9pSlhDQXFTQUNPS1ExSG9iU3lvZVo5eHhaY0lBQWxFZmVQY1hDOTlu?= =?utf-8?B?OTA5Y2J0cFFYcGtpYXhvYkc3TGgxa2NMM1JvQmtNb0J0VmJTWU9VVVp2NEJv?= =?utf-8?B?VzJGbFE3RUhWWnFxNmg5N1R4aG5ZVzQrc29EWVhtQkVkRnE0US9xSnRhT1dm?= =?utf-8?B?L2YvR0JqUGlUSGR5UW9qYTF6MlFxVnBkcVRQbCtMMGtZWDE3bXdOMjROV0Qz?= =?utf-8?B?eVY4SUM1Mzc4SXlKMnB2cnR3UVJWQ2V6UnpLenNXSktRVkF3aWlia3dPcDQy?= =?utf-8?B?R01hNlY5d3lEY1FqanQ3VEVlY0tHRHJoQm53cXdlQWtIUkJIR1cvZmVlYUZa?= =?utf-8?B?UERUNkNvZmkzWkgvTzRmL2x4TGg3OHlFNy9FN0xyR1laSzdvOXVaN2ZOVXpT?= =?utf-8?B?dmJkWU4xZFNUMTlnUlQ0cndqdmhuK0dtSzZPVFNSblVkSWhNY1ZFZk8rUWxH?= =?utf-8?B?NTFubW1odHRWaDVHKzg1dEwrWWJkRnQ2R0RnQTQzVXhSYzZPbVJudlUyc0dY?= =?utf-8?B?U1N5d1BCditoYWxvRlY3N2VHTlQwOTZhTm55MUdzdlI5ZGJ3UUtVYksxbWlw?= =?utf-8?B?K2tvZEh6dlU3RFFZRDhBSnp6bnpVWDl5d1JTdEM4NjUxdG9kbkt5NEtCaFJS?= =?utf-8?B?bDEzZndkVXpOR1BRSit2bHlzYW1JU0NyQnBGMnhuUkZsRHQvL0tCREJ5a0tK?= =?utf-8?B?SW5IM0hTU3Y1TkVmQWZWb1ZSY3RlKzRXeHhhbTZiYklJcGJUWlRWUmhxdzF6?= =?utf-8?B?VEgwaEJVYk5IbkxjVkFJS3FjbE1yaWNCRnpYOU1aWGR0aWF1b21TWDhybWMx?= =?utf-8?B?bEs5c3VVNjJ1eUlGV01BZU9mbXdxTStsV1YxeDdxTTB3L2NSWTZmU3Z4Kzd0?= =?utf-8?B?MUNKZUR2NWtnemhSV01QOGlLZER2QUJINjNhdTJ0TE9DSlFzVDFyWExvL0VG?= =?utf-8?Q?0VaA=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VnV0MHUwNkhPZ0dJYVo2bHVWYnl1SkhlWkF6aEFXdmV3Q1A4Vy9obzdJS0kw?= =?utf-8?B?MldPWEU1Wmw1VnUzMkRmeERNUW03UllEcjl4SWNCUEdpNmFIbDAvMnJRZEJr?= =?utf-8?B?UklVWUVhdlh4dlhmT0kxQUVhcEJlMmtTKzROc0NIVlJoTWlYUXk3eTRpSWhv?= =?utf-8?B?QzZteHMwdUhURGsxTkpJVTF0dGZ0NEticlFaRzBVRlNsWm1QTHRCaUVnMnN4?= =?utf-8?B?WTl2YmhYMXNWeG9kMEJHdW40M2h6ZG5UV0c4MHpDU2ZtNTh4eVZNMGFZSW1v?= =?utf-8?B?SVNCUzdCS2R6VXNDNFhOUTVQQ2FtRzZ0a0ZrR0FCckZtVzBjUHR3TTdlZFpH?= =?utf-8?B?alYxQmtVTWVPeUhoQzkrcEFWOEJpRkwrb3pnb2hSL09MRXYvV3MzdmE4bGFt?= =?utf-8?B?QlFyZWUwYXdFdGlJSU9waUdZaFFudjBPSWVwcDZ0RWNnd1c0ZkJhbEtISE91?= =?utf-8?B?YlhjRU5peWEzSmduQlBKTjQ0RVkyUkxwWnFyc1RNZEQrRmYyZkhsY2ttVk9j?= =?utf-8?B?OEltejg3cnFLRnp0U1EzU1JSTWFVMjFCWStJb0swNm9IODk4Zm45UVFxTWxa?= =?utf-8?B?dGFxWXBKeDlnNmNVQXNWcWRSSFo4SXRnV090QVdveVlSZFVoeTBYa29VTTFO?= =?utf-8?B?OXRURGF5RVRwNWJvWVdmL1dGNHJGTFNZTmlFalBiYWtwS3EvMUlzYnI2SUJP?= =?utf-8?B?NVB4bS9QdkZRRmZwSTdza0ZwQml3QWtXbTlPeTRCNzN2VUQrMmJXaFNtZ1Bp?= =?utf-8?B?ZkthRVpoVVJ1bVFYdkFaczJ2SXlDUDMwWUJvYk1CWm1YVGhxNzlWNFR5R1g4?= =?utf-8?B?bkw4V013U3ljZjZzdkVFR3RIeFNFeWFMUDBqOFRBVzJKSW5IUjhnQThFMity?= =?utf-8?B?Vk94M0RvWURndVNtODExU0Z5eVRvU2JUK2VEMVI3SUxWOUF3YU9oL3ZuUm15?= =?utf-8?B?UUozb3hWM1B4ekFEM1IybjRyUFJwQ1R4WCtsdGhMYlZuaUx3TTdJakNzbmF1?= =?utf-8?B?aDhrZThoTTcxWnB4TTd6a0tTS3p5R0Zsc1JGUFNwZmhMMkZ3NXpHaVFNTkFW?= =?utf-8?B?THpkU2RtdHkvZVZvM3VjNTJDTXp3ZDg0Qms1ZERhWDBobGRkeFdKUUV6Snl2?= =?utf-8?B?cnJoZ3AzUmNXOXQxVFFTZVZPUTlRQ2xNaXYrd09vWFRqMTAwLzh5QXpFcGVi?= =?utf-8?B?eUxHSUlUU0NiTTVqSGNLRmxEYU9PZ2ExZGprUzA2UHJUZVZLRHNnTit3elJP?= =?utf-8?B?NURNZkxWK1A3N3lJbGdrc1pwNGZYVDJjcUdWL0t6MCtLam11ZEdjOXJqM3M2?= =?utf-8?B?M0M5aUZPbVBvM0dEelV2NktWSXluZ29YUVEzVU41SlBYNTZjYm0ycW1peFMx?= =?utf-8?B?bjZmb092MHVheFBTa1MrWllWcW5wQjd5WEJBWHZkWGZhbTk5UDl0NEVTZExo?= =?utf-8?B?VWYzTGVFUFpZcktXay9JK01obzJmd3BBMTRlMkFPTU9hQ05HQzBtOHAzb0lH?= =?utf-8?B?SU1SZVRKUGxvMUUvQndlNXcxWjVDcnJlOGEwaHcyQWhWMEEwd0ZzcUNWZFRl?= =?utf-8?B?MStMb0Y2VXJLYTFqNjRQY2dNVW1pU2xuNHlEZ2J2YnYvdE5EU2hjbnc0M1FT?= =?utf-8?B?Wm9SQjRtRWkwVThSNkJmamV6VVhXejRISnZpUEJsOEk1M0tnVVI5cHBRandu?= =?utf-8?B?OTVDaEVrSWdMK1RzSGdVOWVQT2RIT3VVOWEyNzlyRU5janBDcUUyS1FONVpG?= =?utf-8?B?eWlObDIxWFM4WHBrNkRvVldMM3JaMUNORGVGa3dIU0lhamI5Wk1OZ2phTmVB?= =?utf-8?B?ZVAxelNHMlVGMVAzNHRnV25kT3cvTG5BTkg4MmtKQnJXZFlVVmJZblNCOGpK?= =?utf-8?B?TnI2UDd2djBVWk9vdGVGRjhrTUNGOXNMWlIzc0NQa09KNUNpemUvRnhzeXVQ?= =?utf-8?B?ZzZGVmx6SzdyWGxYYTIvT1dyY1ZTLzhVaGJFTzRhcVN4Ty82cEMyMWJXUFRa?= =?utf-8?B?SUVGUmFxV256MkNSVDZDQUxIRENvcnpkSFhyc01CekRLbVdyK1BYWGhkaDdy?= =?utf-8?B?Ulk1bXV3TkVDOHVYRXhBZjdvQitNcFZCdzNhOTdMUmlVUWJBanJLNU85a0Rx?= =?utf-8?B?SWQva2VHOXQzVlVINGNFUkNScldsZ05SQlRQMndad3ZtNVY2ckQ2WFpSQUF3?= =?utf-8?B?OEwya1UzY1Q0emYzVElWOFRyem1wdGN5c2NxQkRpZGFPWWdNamxjdGpudWJ0?= =?utf-8?B?SUcvaWRTZGx2KzBCc0lMYVVHNFhLVzRXV20yVGpKWUtTRnJNUUQ0QXRmNVhL?= =?utf-8?B?QUZXRzdhbHFqa2lLcXpzYmdHdURmdVVFOEllVWsxRFowdDhiYVNEdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0e4e5ba1-4ffb-4b0f-4711-08de58cef812 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 09:25:08.3631 (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: 6pv+IakyBM3zv0NYIQaATIorvmkjAK2qG3+UYAQEu3lygw3XIVm3vW7Ez0VyWlX+62F+Vw0PLHpgewiYKTG72w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH5PR03MB7813 On Mon, Dec 08, 2025 at 04:18:15PM +0800, Jiqian Chen wrote: > 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 032e471bb1c0..8dcf2cf9d598 100644 > --- a/xen/drivers/vpci/msix.c > +++ b/xen/drivers/vpci/msix.c > @@ -656,6 +656,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); Like the previous patch, I don't think this last bit is relevant for domUs? Only the hardware domain needs to have the control register explicitly handled. I don't mind adjusting at commit if we agree. Reviewed-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 21 09:34:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 09:34:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209530.1521507 (Exim 4.92) (envelope-from ) id 1viUb5-0002fL-36; Wed, 21 Jan 2026 09:33:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209530.1521507; Wed, 21 Jan 2026 09:33:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viUb5-0002fE-0R; Wed, 21 Jan 2026 09:33:55 +0000 Received: by outflank-mailman (input) for mailman id 1209530; Wed, 21 Jan 2026 09:33:54 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viUb3-0002f8-VE for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 09:33:54 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4aa5eb8c-f6ac-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 10:33:51 +0100 (CET) Received: from BL1PR12MB5849.namprd12.prod.outlook.com (2603:10b6:208:384::18) by BL1PR12MB5850.namprd12.prod.outlook.com (2603:10b6:208:395::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 09:33:45 +0000 Received: from BL1PR12MB5849.namprd12.prod.outlook.com ([fe80::53da:e77e:261e:5a29]) by BL1PR12MB5849.namprd12.prod.outlook.com ([fe80::53da:e77e:261e:5a29%5]) with mapi id 15.20.9542.008; Wed, 21 Jan 2026 09:33:45 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4aa5eb8c-f6ac-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=WyEQr2QgU2P69MdPuFWm81M9N49dOjPeAV6/lR/QO8+Lvb3yaFQISf+9Tf/yl0AD7WV07LTPN29sze4s98MGEoI6F1+CkFLbJxGcXbabMezSpnV0HpA6zHsy1faWJnYsm8u2PmJDsFJQJ2Y6W8xqautU19B4hCzRm47dRqsd3vw0IN00DsOGa1n+8pxuZAB1KIj0HBhfoEqM/oEwWtwWsPvICbt2+2dO+8o7h0n/NDWKEfYwqGPGqSGPOlkX//Ffsb+9wELxtJHSg6SoLc0RwVNkIvfoBr45s4RgAJOm6YBJMtFLzqGdNtw9/fUw8RUdoo0AbQKLx+DpEU+p+7vTDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qHDsPPZ6/dZq8EHsYQlXHVTlvVeY6Dm6FkYjz+rLXiA=; b=MxSM0SKOhK4iNt54Br/mRNmAXSTZTZK3CFlYtzYowOkHhSeE0zlPTP8buliSqoP6RhKxt8+C58t8w6lb3KORMIbloypqhPy33QTLQtoz1FiAc2SvF7CB5vWm+1EVdB6znJivMowbTR+ZnKNQJaAsd8c6evPCtMzNrJ2z7tviyYJGDXItkmr148P/bXhhCQ7ZYDjJNz7Z8JNLI2QWE9+IKvCxB4V4sNaZnbWeKLpQWO+jhuwvZ19344AljKQo9Bs7KoztDVTdGT8k6+9Zp25eLFjcg58PYOhsmkxOqlUoLaSMLEuv+ONewUp0NtJYfbC6AjfI3fbFaSVWimZCwx1b/Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qHDsPPZ6/dZq8EHsYQlXHVTlvVeY6Dm6FkYjz+rLXiA=; b=v7LF0zpvrGrTSMq8kKX6Xhb3QJv/t1X+YVz7oORF25pJIqEF4DRws/1iuoURqdNwRGdzdjZQ/vna7A4qft8rsPOcJoGn3VD1MjsTePcQ/uqP9tvg8Tmf/Mstu20SdwetRQBf2UxNVpYfix/X3/tKJnJsZmEbWcdKhhpHirOp4M8= From: "Chen, Jiqian" To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= CC: "xen-devel@lists.xenproject.org" , "Huang, Ray" , "Chen, Jiqian" Subject: Re: [RESEND PATCH v12 3/3] vpci/msix: Implement cleanup function for MSI-X Thread-Topic: [RESEND PATCH v12 3/3] vpci/msix: Implement cleanup function for MSI-X Thread-Index: AQHcaBtCn9gZDX/DWkaHFEYDT3YAlrVcn3CAgACGhwA= Date: Wed, 21 Jan 2026 09:33:44 +0000 Message-ID: References: <20251208081815.3105930-1-Jiqian.Chen@amd.com> <20251208081815.3105930-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.9542.003) 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_|BL1PR12MB5850:EE_ x-ms-office365-filtering-correlation-id: 249c40bd-4410-458c-b35e-08de58d02c14 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?MXdodEd3a2dHeURVNmpSK0JNU05xeDBxU0txaVRuenhYdnhuVjhrMWpiL3Zq?= =?utf-8?B?Rmt1ek5kb1I5cG9yZlVNWWRCYmVxNGZxQzFqUEl2Mkh4RDVCMDVLNGRRQUJx?= =?utf-8?B?Z0t4OUdrcHNQTzBwWW5vZzQwbWxwOGRvckNLUGxha0xGNitlNnJMUHRFVEUv?= =?utf-8?B?cUtFbUVxZlhMbUNxbmQvdFV6bnE0b2ZpQ2JFVGxzMjVTY3QxYjAwWFdOWHdk?= =?utf-8?B?d2FVeHR3Y2ZQMFhOa3pqaENxd09DTHdhbHRGY1hoQTBBbm55d1crMkUzUlc0?= =?utf-8?B?bjlWQ1RTTjR6dFRMYlplNEJVSDRQWFpBYlE4anpiUTgvbEpjQXhzY29lOTdC?= =?utf-8?B?QURHTERnOTBUeFNIL04zMkVDOElRSTI0ZVFRMngvR2g5VlFZZk9QbDR4dmlt?= =?utf-8?B?WXAvWDVBTjZJRVhDS2JSY0VTQWJZNUNUOU11VDU2bnk3a1hQc2p0Sm1wcysy?= =?utf-8?B?SDhnSDU0V0p0blRieWExUE5SdjE3SHk3WWNtUHlaczJZa1FuWWVpdklDUDd3?= =?utf-8?B?VUxOMVVhUU1tWFN0djY5amFhWndrSi9Ddzc0YW9EeHlYOTRTcXZOOFhYM2p0?= =?utf-8?B?TGxTa21zTXZ0d0FMQk1KejdGclArYW1Fbmt4WmRZODlxZzJYVFRxNzBHWVBq?= =?utf-8?B?Z2J2NjBPV3VjUzRuUm1lQ2M4cXgyOXBaWG53Q0pBWU41Ym9yeStVeHMrY0NZ?= =?utf-8?B?eVVEaTJnakNJU2JuTkV6K0MycU9TYURzMjFIZWNBREFpZ1E1SEtBRkVzQkRS?= =?utf-8?B?ZFA3SmR1MmFsdU40dlFSeFgrZ0wrb1RIdGxML0ZOcjdyb0JhenQ3QVViKy96?= =?utf-8?B?c2J3bEZvQ1dCMzlnbFphSUUxcThMdUZmaVpya0w3QzhaaytTeXNpMXF3amVB?= =?utf-8?B?MVhJQzZNQ0VzdHMyWERBMnBwaTRreFE4N2FOUlhTamRCNWhFZURFVmg5UnVF?= =?utf-8?B?U3dTZGpyeC96ZzRsUHJOa1Z6K2xjb1ZJVW5xZmlER0dtbzB1OEF1V25ONmhk?= =?utf-8?B?Vm95THB4Q1h2V2poZDZlZ0hMYnZRU0djbzhpVnkrMWZVL05ncFk3N1c0Qlhx?= =?utf-8?B?SG12WnR6QXIxVk8zUHQydkxRU0phblpsOEhlS2ZsY3g3K0ltb002VTdWMVAx?= =?utf-8?B?RVc0dXQ5ZVpvUVhBYXMxTDYva3E3WThNZG54d21qajBOTVBabFMvOHRrNjJi?= =?utf-8?B?NzdYY00xYVhOTU5DQjR3enltRDdWMWN3Y25oTWFaNEFnenU3T0J5WkxVLzhN?= =?utf-8?B?aFlYSzZtU1B6aUlmMVp0RFdLK0VsS05KK3BLQm9NWGEyVDY3dUVhMnpER1BR?= =?utf-8?B?dVZ2OHhwQ1BWTGRWckFCSFZ0aHoveUtibHFrU0E5djRrUzJSWWhidFdNZlZy?= =?utf-8?B?cSt4MEpYZTVXSmNyTG9qdURUS0FtbURRWU1jWHFxR2d2N1ByMkExZmc5NERk?= =?utf-8?B?WlMzRGVlbTZrMnVMcEwzTk9FRm5BWnpkU2Q3b1dHU0YzU0dKM1JvU3dvZWhX?= =?utf-8?B?dGRMTW83c2FnMk5LbGdvSVVLRkh1TDc3NjROSVAxMEgvMUZ1NUZoYzNHR1pq?= =?utf-8?B?RkEvUG56aXovM3F1WEk4eWxVZHVUTGJPVndWZnFBM2NLWXVrczQySFA4TXpr?= =?utf-8?B?QndQdE9IOEQvNy83aEFaSVpuS2YxVGI4RlJyV2drN1prdWM2VXh4bnR5K2xI?= =?utf-8?B?VmNEMXdRd3ByL0ptWDk3aG9CVURLYUdBN3lCa0ZNRW9ISUc1UGFkYnB0a3Nl?= =?utf-8?B?WngzWWFCVTBRTkdWQ0VCaWEwQTNoS1YrQkJXMEFGelZhSFJwQUIvamNwbFM3?= =?utf-8?B?RlJ4dzhlRFRiTm43WVZYeFdzSFE1WVpxMDMzRGJPTEFDVXl6N2w0clpzamlL?= =?utf-8?B?Sll1TUorNEhiUmVSRG9KOXovaHpWdUp2dWt3SldVS2J3VWdZTnVvNytHTGo3?= =?utf-8?B?MWNaWUNOdFh0c3oyZFBvZmxvVFVzd2QrMWRobjdPZG1iSk90OG4zWVo0Q3l2?= =?utf-8?B?b2xOOGJpZmlEb3pHb1VLVUhKUjBDTGJQZkVxV290MjhLODdCOWxaTkZwU215?= =?utf-8?B?YWNBZ2JHRjNZaGM4L0hNMXB6SjlvRVpTWFd0TmlVQWxRVTB6T2VvWjRqUThN?= =?utf-8?B?RVNNTkxlZ0pTd1R1c1haUXNUMTR2eTNWR1FLZlQyZDZob3ZRM0Fnem4ydWxO?= =?utf-8?Q?wm1BDugU6j52gXBR6H2SFJg=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?Rjd5dmdaMFYrMndPbG9ITk4yczVzUHJaTUFMRm5nakFSU0lYbUlHSVJndHUw?= =?utf-8?B?alRDdzRFbDljNnB1bU8weXVZdFEzdXJNb1UyYmRGRElOT2IwY3BWbGo4cHox?= =?utf-8?B?bVRPbGZLNjFOendWaktnQ2YrM1JXb29NaGZxdnFxVGdPSTd6cVZHeHc2SzN4?= =?utf-8?B?emtLd0dFcTNNN0RNS1N0ZmNDTGNjSk5Ha2ROS2l1WWQ4MURhWitmZUtDdVJ1?= =?utf-8?B?VmJmMldONms3QnZLa05rK0V4UW5iay9IOXQ4Wm1PN2NWWmNpSEZ4dTM3bjd4?= =?utf-8?B?SGpITVBKOVJKaW5WZzhRSStBOXVrQmJ5cWxWQzMxbHJnMlBZV2Q3bHNIZ2I4?= =?utf-8?B?bjNndEFTZjdTcmRYbGVoblVRcGJ0THlTZng2VmtGZG1wdWVneTNrZ29PdGhl?= =?utf-8?B?ZWxLanIxKy9QVktjR2s3Z3hqaDdYdjJveERMeUFHaVl0akZscXp3WWwrd0Rq?= =?utf-8?B?dXFNU1dHRzZuSlFnNTFFck5sY25oa2VaT0drQ0ZYa29EaUwxWGxsWEdNdlFO?= =?utf-8?B?aG11cDNudUxJU2NUOWI1SlNHMjBlRUg5ZjJmZzQ2VTA3VTc0QXNtNGJIQ2kw?= =?utf-8?B?VVkzdUV1MG5kOEdLNzVVYWw5dnRvejhBc2IvbVFhVFp2NmEvbkYxZ2ZNZVRh?= =?utf-8?B?RW80UnF2TFBlT0Z2K3JjY2ZqS3E0Q3JDS1NvVitFb3o0NkZMQ2dPVDBPOUJp?= =?utf-8?B?cnVlYURJcDlvN2hmaWtFeDY1NjZNWi9oQi9Sa0hHdWp2M0N1OXNlUTVsL1RJ?= =?utf-8?B?TndzNG94Vk54QkZsVlFhMi9KZklWUy9GK1RKMXZYYzdzNkZlY21DTjNKekl6?= =?utf-8?B?aHdRYWhFU3p3Z1VDVGVnSjVJWFV6bWxJUmtyaW1nRTYxMkl6eEpmY1VhdXR2?= =?utf-8?B?cDlGYUNpK0NRWDFxdVREbkNhN2NTUFdMZjFVaVRVM2RYREtVUit6aUloYUFO?= =?utf-8?B?TWFEVnF6WW5BaVJzRVdVZ0JOVzZnTzhSNU5DdFFvS3VWcjRadVVSQmlQV0lh?= =?utf-8?B?U2RKRlJtbUEwTXR2QzBNcytvelhORVpyMWRndSsrVGZnRjRIeENxc0hqZTQ3?= =?utf-8?B?UWFXdzVwcWE2bEt2Z3lqWGt6enlIdmRyV3htZk9uRmMwQzJuenczTk9kSloy?= =?utf-8?B?U1FJSzdxbEUvaW0ybjhjMk1yWXhvT2p4bk4wRHh1NVQwS0hmMTVDL05NdnBQ?= =?utf-8?B?eTJKNmFzT283bDJ4ZTJKYWlKb2swWTdBaFdzYk5TNHpWdnlBZWRzRHh4TkZN?= =?utf-8?B?eVdoU3gvaHNWcmNmeVo4WEVwQ0JRWkZDVG1JMUFKN2ZyUHI4QXBMMFo0M2I4?= =?utf-8?B?NTNpT2NRQnR0dXJiSzdkK3NtZ3BxOG1HZDE2TGJJZGFDU2J3WU00bXlmT0Ez?= =?utf-8?B?UFJYUEhKRWZ1Q29JUjhFSE9TQzNSTDAvbjViZDdnMW1wZWR1NGVia2NraWh0?= =?utf-8?B?QmtDVzIrOUMzOWMyWjUyWTRwVWJVUUs3elhHWHJtNjE0TzMzWUhyS0hNdVJl?= =?utf-8?B?L2RpcW11dzFPd0kxMWhXYWcvT3UreS9IM0VFeHg5ZGFZdGMwcko4UXpydXdX?= =?utf-8?B?Vkp2M1VOa1JsTXYvOEhYWk1XZU5pb2tHM0huTk1uUitsU3J6cWEwcTlZTTl4?= =?utf-8?B?NCtpQ0JVaWZZVUJEMEw0ZS80Yk0xS0lTNWF5WW5taHRVTm9zTjlRQ0NkSzlj?= =?utf-8?B?dXBReXd6cDlxNVp3dmlXTVdDaUI0enVpSmsvZit3TVU0eWJueGpnRVd4YUpp?= =?utf-8?B?U00vSzJVVkRLbzZ5Lzl2NUVLSkJ0MUY4V1RxUS9LZzN0UTR3U1V0Z2V0Q1ZZ?= =?utf-8?B?ekY4RkRQMTc5YVRMSHlnaXVuZ2l6VnlGOFd2VEdYVmlCNVU3RFBBaGtKalFy?= =?utf-8?B?STJTeWV1aGRldWJWQ1pJZnpjMTZnWmZCU0RHYytqbXZSOFZDcmEvVjRPS2Y4?= =?utf-8?B?V1IwOGRJcFh5VTBwWjdKZUIyOHBsVVRER0xWcEl3ak1KQnVzWW9uOXMwK3hV?= =?utf-8?B?VTBXOGxLVjlXeWsrclR3V2V5ZzJpbzY1dTlEM2dwSWtWakc1SGZ6WWU1Y21F?= =?utf-8?B?VmIzNkluMEZqZ1pkN0s0am1KMkRaQS9QRXN4eEM2NmdOci9KTTg1dkR3Z3Bv?= =?utf-8?B?dzJVUEJMZ3RJQ0d1bW95dWFyU1B3Y2ZKa2IvV09ZZWdITXE1NE9Vbm1ROCtz?= =?utf-8?B?SE9Fcm1Ga3VuZkdDVWJIVHFQbVdMeXlZWXVHY0t0T0s3L2NqV0xqUVcxYjhP?= =?utf-8?B?amZGVUp4ZkNpMDI5a0tCS1F1MXNvcE8vdnNEQ3hoclEyNCtGRXdrOHN1Tzdq?= =?utf-8?Q?ta73w8ADB6ZOJ9n4bn?= Content-Type: text/plain; charset="utf-8" Content-ID: <357B352A7A389C46B633E7C93423262C@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: 249c40bd-4410-458c-b35e-08de58d02c14 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2026 09:33:44.8966 (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: c8cSmM0AeeSBrS2D+iZMqbYaRz35rWHX0Si5RhSPRlUtmtxNEFvkL8CrkjNEnOJJf31Vu9TVBQjGo8Tl0Yxt3g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5850 T24gMjAyNi8xLzIxIDE3OjI1LCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOg0KPiBPbiBNb24sIERl YyAwOCwgMjAyNSBhdCAwNDoxODoxNVBNICswODAwLCBKaXFpYW4gQ2hlbiB3cm90ZToNCj4+IFdo ZW4gTVNJLVggaW5pdGlhbGl6YXRpb24gZmFpbHMsIHZQQ0kgaGlkZXMgdGhlIGNhcGFiaWxpdHks IGJ1dA0KPj4gcmVtb3ZpbmcgaGFuZGxlcnMgYW5kIGRhdGFzIHdvbid0IGJlIHBlcmZvcm1lZCB1 bnRpbCB0aGUgZGV2aWNlIGlzDQo+PiBkZWFzc2lnbmVkLiBTbywgaW1wbGVtZW50IE1TSS1YIGNs ZWFudXAgaG9vayB0aGF0IHdpbGwgYmUgY2FsbGVkDQo+PiB0byBjbGVhbnVwIE1TSS1YIHJlbGF0 ZWQgaGFuZGxlcnMgYW5kIGZyZWUgaXQncyBhc3NvY2lhdGVkIGRhdGEgd2hlbg0KPj4gaW5pdGlh bGl6YXRpb24gZmFpbHMuDQo+Pg0KPj4gU2luY2UgY2xlYW51cCBmdW5jdGlvbiBvZiBNU0ktWCBp cyBpbXBsZW1lbnRlZCwgZGVsZXRlIHRoZSBvcGVuLWNvZGUNCj4+IGluIHZwY2lfZGVhc3NpZ25f ZGV2aWNlKCkuDQo+Pg0KPj4gU2lnbmVkLW9mZi1ieTogSmlxaWFuIENoZW4gPEppcWlhbi5DaGVu QGFtZC5jb20+DQo+PiAtLS0NCj4+IGNjOiAiUm9nZXIgUGF1IE1vbm7DqSIgPHJvZ2VyLnBhdUBj aXRyaXguY29tPg0KPj4gLS0tDQo+PiB2MTEtPnYxMiBjaGFuZ2VzOg0KPj4gKiBJbiBjbGVhbnVw X21zaXgoKSwgbW92ZSBjaGVjayAiaWYgKCAhaGlkZSApIiBhYm92ZSB2cGNpX3JlbW92ZV9yZWdp c3RlcnMoKS4NCj4+ICogUmVtb3ZlIHRoZSBjaGVjayAiIXBkZXYtPm1zaXhfcG9zIiBzaW5jZSBj dXJyZW50IGNhbGxlcnMgYWxyZWFkeSBkbyB0aGF0Lg0KPj4NCj4+IHYxMC0+djExIGNoYW5nZXM6 DQo+PiAqIE1vdmUgY2FsbGluZyBhbGwgY2xlYW51cCBob29rIGluIHZwY2lfZGVhc3NpZ25fZGV2 aWNlKCkgb3V0IG9mIHRoaXMgcGF0Y2guDQo+PiAqIEFkZCBoaWRlIHBhcmFtZXRlciB0byBjbGVh bnVwX21zaXgoKS4NCj4+ICogQ2hlY2sgaGlkZSwgaWYgaXQgaXMgZmFsc2UsIHJldHVybiBkaXJl Y3RseSBpbnN0ZWFkIG9mIGxldHRpbmcgY3RybCBSTy4NCj4+DQo+PiB2OS0+djEwIGNoYW5nZXM6 DQo+PiAqIENhbGwgYWxsIGNsZWFudXAgaG9vayBpbiB2cGNpX2RlYXNzaWduX2RldmljZSgpIGlu c3RlYWQgb2YgY2xlYW51cF9tc2l4KCkuDQo+Pg0KPj4gdjgtPnY5IGNoYW5nZXM6DQo+PiAqIE1v ZGlmeSBjb21taXQgbWVzc2FnZS4NCj4+ICogQ2FsbCBjbGVhbnVwX21zaXgoKSBpbiB2cGNpX2Rl YXNzaWduX2RldmljZSgpIHRvIHJlbW92ZSB0aGUgb3Blbi1jb2RlIHRvIGNsZWFudXAgbXNpeCBk YXRhcy4NCj4+ICogSW4gY2xlYW51cF9tc2l4KCksIG1vdmUgImxpc3RfZGVsKCZ2cGNpLT5tc2l4 LT5uZXh0KTsiIGFib3ZlIGZvciBsb29wIG9mIGlvdW5tYXAgbXNpeCB0YWJsZXMuDQo+Pg0KPj4g djctPnY4IGNoYW5nZXM6DQo+PiAqIEdpdmVuIHRoZSBjb2RlIGluIHZwY2lfcmVtb3ZlX3JlZ2lz dGVycygpIGFuIGVycm9yIGluIHRoZSByZW1vdmFsIG9mDQo+PiAgIHJlZ2lzdGVycyB3b3VsZCBs aWtlbHkgaW1wbHkgbWVtb3J5IGNvcnJ1cHRpb24sIGF0IHdoaWNoIHBvaW50IGl0J3MNCj4+ICAg YmVzdCB0byBmdWxseSBkaXNhYmxlIHRoZSBkZXZpY2UuIFNvLCBSb2xsYmFjayB0aGUgbGFzdCB0 d28gbW9kaWZpY2F0aW9ucyBvZiB2Ny4NCj4+DQo+PiB2Ni0+djcgY2hhbmdlczoNCj4+ICogQ2hh bmdlIHRoZSBwb2ludGVyIHBhcmFtZXRlciBvZiBjbGVhbnVwX21zaXgoKSB0byBiZSBjb25zdC4N Cj4+ICogV2hlbiB2cGNpX3JlbW92ZV9yZWdpc3RlcnMoKSBpbiBjbGVhbnVwX21zaXgoKSBmYWls cywgbm90IHRvIHJldHVybg0KPj4gICBkaXJlY3RseSwgaW5zdGVhZCB0cnkgdG8gZnJlZSBtc2l4 IGFuZCByZS1hZGQgY3RybCBoYW5kbGVyLg0KPj4gKiBQYXNzIHBkZXYtPnZwY2kgaW50byB2cGNp X2FkZF9yZWdpc3RlcigpIGluc3RlYWQgb2YgcGRldi0+dnBjaS0+bXNpeCBpbg0KPj4gICBpbml0 X21zaXgoKSBzaW5jZSB3ZSBuZWVkIHRoYXQgZXZlcnkgaGFuZGxlciByZWFsaXplIHRoYXQgbXNp eCBpcyBOVUxMDQo+PiAgIHdoZW4gbXNpeCBpcyBmcmVlZCBidXQgaGFuZGxlcnMgYXJlIHN0aWxs IGluIHRoZXJlLg0KPj4NCj4+IHY1LT52NiBjaGFuZ2VzOg0KPj4gKiBDaGFuZ2UgdGhlIGxvZ2lj IHRvIGFkZCBkdW1teSBoYW5kbGVyIHdoZW4gIXZwY2ktPm1zaXggaW4gY2xlYW51cF9tc2l4KCku DQo+Pg0KPj4gdjQtPnY1IGNoYW5nZXM6DQo+PiAqIENoYW5nZSBkZWZpbml0aW9uICJzdGF0aWMg dm9pZCBjbGVhbnVwX21zaXgiIHRvICJzdGF0aWMgaW50IGNmX2NoZWNrIGNsZWFudXBfbXNpeCIN Cj4+ICAgc2luY2UgY2xlYW51cCBob29rIGlzIGNoYW5nZWQgdG8gYmUgaW50Lg0KPj4gKiBBZGQg YSByZWFkLW9ubHkgcmVnaXN0ZXIgZm9yIE1TSVggQ29udHJvbCBSZWdpc3RlciBpbiB0aGUgZW5k IG9mIGNsZWFudXBfbXNpeCgpLg0KPj4NCj4+IHYzLT52NCBjaGFuZ2VzOg0KPj4gKiBDaGFuZ2Ug ZnVuY3Rpb24gbmFtZSBmcm9tIGZpbmlfbXNpeCgpIHRvIGNsZWFudXBfbXNpeCgpLg0KPj4gKiBD aGFuZ2UgdG8gdXNlIFhGUkVFIHRvIGZyZWUgdnBjaS0+bXNpeC4NCj4+ICogSW4gY2xlYW51cCBm dW5jdGlvbiwgY2hhbmdlIHRoZSBzZXF1ZW5jZSBvZiBjaGVjayBhbmQgcmVtb3ZlIGFjdGlvbiBh Y2NvcmRpbmcgdG8NCj4+ICAgaW5pdF9tc2l4KCkuDQo+Pg0KPj4gdjItPnYzIGNoYW5nZXM6DQo+ PiAqIFJlbW92ZSB1bm5lY2Vzc2FyeSBjbGVhbiBvcGVyYXRpb25zIGluIGZpbmlfbXNpeCgpLg0K Pj4NCj4+IHYxLT52MiBjaGFuZ2VzOg0KPj4gbmV3IHBhdGNoLg0KPj4NCj4+IEJlc3QgcmVnYXJk cywNCj4+IEppcWlhbiBDaGVuLg0KPj4gLS0tDQo+PiAgeGVuL2RyaXZlcnMvdnBjaS9tc2l4LmMg fCA0NCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrLQ0KPj4gIHhlbi9k cml2ZXJzL3ZwY2kvdnBjaS5jIHwgIDggLS0tLS0tLS0NCj4+ICAyIGZpbGVzIGNoYW5nZWQsIDQz IGluc2VydGlvbnMoKyksIDkgZGVsZXRpb25zKC0pDQo+Pg0KPj4gZGlmZiAtLWdpdCBhL3hlbi9k cml2ZXJzL3ZwY2kvbXNpeC5jIGIveGVuL2RyaXZlcnMvdnBjaS9tc2l4LmMNCj4+IGluZGV4IDAz MmU0NzFiYjFjMC4uOGRjZjJjZjlkNTk4IDEwMDY0NA0KPj4gLS0tIGEveGVuL2RyaXZlcnMvdnBj aS9tc2l4LmMNCj4+ICsrKyBiL3hlbi9kcml2ZXJzL3ZwY2kvbXNpeC5jDQo+PiBAQCAtNjU2LDYg KzY1Niw0OCBAQCBpbnQgdnBjaV9tYWtlX21zaXhfaG9sZShjb25zdCBzdHJ1Y3QgcGNpX2RldiAq cGRldikNCj4+ICAgICAgcmV0dXJuIDA7DQo+PiAgfQ0KPj4gIA0KPj4gK3N0YXRpYyBpbnQgY2Zf Y2hlY2sgY2xlYW51cF9tc2l4KGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2LCBib29sIGhpZGUp DQo+PiArew0KPj4gKyAgICBpbnQgcmM7DQo+PiArICAgIHN0cnVjdCB2cGNpICp2cGNpID0gcGRl di0+dnBjaTsNCj4+ICsgICAgY29uc3QgdW5zaWduZWQgaW50IG1zaXhfcG9zID0gcGRldi0+bXNp eF9wb3M7DQo+PiArDQo+PiArICAgIGlmICggdnBjaS0+bXNpeCApDQo+PiArICAgIHsNCj4+ICsg ICAgICAgIGxpc3RfZGVsKCZ2cGNpLT5tc2l4LT5uZXh0KTsNCj4+ICsgICAgICAgIGZvciAoIHVu c2lnbmVkIGludCBpID0gMDsgaSA8IEFSUkFZX1NJWkUodnBjaS0+bXNpeC0+dGFibGUpOyBpKysg KQ0KPj4gKyAgICAgICAgICAgIGlmICggdnBjaS0+bXNpeC0+dGFibGVbaV0gKQ0KPj4gKyAgICAg ICAgICAgICAgICBpb3VubWFwKHZwY2ktPm1zaXgtPnRhYmxlW2ldKTsNCj4+ICsNCj4+ICsgICAg ICAgIFhGUkVFKHZwY2ktPm1zaXgpOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIGlmICggIWhp ZGUgKQ0KPj4gKyAgICAgICAgcmV0dXJuIDA7DQo+PiArDQo+PiArICAgIHJjID0gdnBjaV9yZW1v dmVfcmVnaXN0ZXJzKHZwY2ksIG1zaXhfY29udHJvbF9yZWcobXNpeF9wb3MpLCAyKTsNCj4+ICsg ICAgaWYgKCByYyApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICIl cGQgJXBwOiBmYWlsIHRvIHJlbW92ZSBNU0lYIGhhbmRsZXJzIHJjPSVkXG4iLA0KPj4gKyAgICAg ICAgICAgICAgIHBkZXYtPmRvbWFpbiwgJnBkZXYtPnNiZGYsIHJjKTsNCj4+ICsgICAgICAgIEFT U0VSVF9VTlJFQUNIQUJMRSgpOw0KPj4gKyAgICAgICAgcmV0dXJuIHJjOw0KPj4gKyAgICB9DQo+ PiArDQo+PiArICAgIC8qDQo+PiArICAgICAqIFRoZSBkcml2ZXIgbWF5IG5vdCB0cmF2ZXJzZSB0 aGUgY2FwYWJpbGl0eSBsaXN0IGFuZCB0aGluayBkZXZpY2UNCj4+ICsgICAgICogc3VwcG9ydHMg TVNJWCBieSBkZWZhdWx0LiBTbyBoZXJlIGxldCB0aGUgY29udHJvbCByZWdpc3RlciBvZiBNU0lY DQo+PiArICAgICAqIGJlIFJlYWQtT25seSBpcyB0byBlbnN1cmUgTVNJWCBkaXNhYmxlZC4NCj4+ ICsgICAgICovDQo+PiArICAgIHJjID0gdnBjaV9hZGRfcmVnaXN0ZXIodnBjaSwgdnBjaV9od19y ZWFkMTYsIE5VTEwsDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgbXNpeF9jb250cm9s X3JlZyhtc2l4X3BvcyksIDIsIE5VTEwpOw0KPj4gKyAgICBpZiAoIHJjICkNCj4+ICsgICAgICAg IHByaW50ayhYRU5MT0dfRVJSICIlcGQgJXBwOiBmYWlsIHRvIGFkZCBNU0lYIGN0cmwgaGFuZGxl ciByYz0lZFxuIiwNCj4+ICsgICAgICAgICAgICAgICBwZGV2LT5kb21haW4sICZwZGV2LT5zYmRm LCByYyk7DQo+IA0KPiBMaWtlIHRoZSBwcmV2aW91cyBwYXRjaCwgSSBkb24ndCB0aGluayB0aGlz IGxhc3QgYml0IGlzIHJlbGV2YW50IGZvcg0KPiBkb21Vcz8gIE9ubHkgdGhlIGhhcmR3YXJlIGRv bWFpbiBuZWVkcyB0byBoYXZlIHRoZSBjb250cm9sIHJlZ2lzdGVyDQo+IGV4cGxpY2l0bHkgaGFu ZGxlZC4NCj4gDQo+IEkgZG9uJ3QgbWluZCBhZGp1c3RpbmcgYXQgY29tbWl0IGlmIHdlIGFncmVl Lg0KSSBhZ3JlZSB3aXRoIHlvdS4NClRoYW5rIHlvdSBmb3IgaGVscCB0byBtYWtlIGNoYW5nZXMg b2YgdGhpcyBhbmQgcHJldmlvdXMgcGF0Y2ggd2hlbiB5b3Ugc3VibWl0Lg0KDQo+IA0KPiBSZXZp ZXdlZC1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+DQo+IA0KPiBU aGFua3MsIFJvZ2VyLg0KDQotLSANCkJlc3QgcmVnYXJkcywNCkppcWlhbiBDaGVuLg0KDQo= From xen-devel-bounces@lists.xenproject.org Wed Jan 21 10:06:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 10:06:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209548.1521517 (Exim 4.92) (envelope-from ) id 1viV63-00075a-L3; Wed, 21 Jan 2026 10:05:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209548.1521517; Wed, 21 Jan 2026 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 1viV63-00075T-Hv; Wed, 21 Jan 2026 10:05:55 +0000 Received: by outflank-mailman (input) for mailman id 1209548; Wed, 21 Jan 2026 10:05: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 1viV62-00075N-L9 for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 10:05:54 +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 c520ceff-f6b0-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 11:05:53 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-47ee974e230so50286615e9.2 for ; Wed, 21 Jan 2026 02:05:53 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48042c5965fsm16673495e9.17.2026.01.21.02.05.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jan 2026 02:05:52 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c520ceff-f6b0-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768989953; x=1769594753; 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=GxKCIkkJG3xB6JSWikT5kTdRTUB4DNUXfQt8pyX8HK4=; b=M9bIlFTb1kZAzxHn+4u3xVymTWhfPPSrrdWHabD/wr2wklHz5m/WkLsjxdkRU2YWEO scE6hDnifbaa4u5oHiypO2jkbxHaVnQBEVJWt0H7Zrib0Npj6XmWAFOjVueNv3boC9Zp T+M0JyvPAGc7XflRMbbQszJL3cUJFF03C2Q9O6B7Y5pjvwthUpG5DK/DN3ToDNlc6q+m mD6t+lOsoqVY7SebugYm71fa+cHjZCsvdcSHemPsNoEnlOKsM5UucVfapdsITju89eEm ObTsmOpIk7HQ1VP9NCWFZerEXCKiXXaMljsrvEJkwo7PF1LsDUp9nZVv4kk0vBk5aW6M MRkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768989953; x=1769594753; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GxKCIkkJG3xB6JSWikT5kTdRTUB4DNUXfQt8pyX8HK4=; b=a1/zPj4UFyGQxkeO7gl/4ASgzXB2gbIELn47k98tQtCfYSFGHJuwn3Xf2aEScY0W7F fXTrwCGkxQb8TEuVGvQ1yM3pYGv4+jFVAvvFA8+76ZY65X4g7VgnlmVz/2jEfVpxmmMo F7GifsgDIWt1RXc67wINJw4MWL5zlU/Ju8blLfWDntGeS/bTmrbcTC26WDyqppZkjrv9 smGmTcAO0oi7Dkww9u9M7aaVpkaFf1bUl9F305WA+pA7U6GTY1g7EcZ71WluOUzQJPZb YFvZ2FZGEy7lVblHJ/OdXqAQGhIih96BP74Sh2K9tHyLH5eJzRE910hLMY27m2zzgmyW r9Hg== X-Gm-Message-State: AOJu0YxHv0IDLbZlRKTYPzlZaevFU16OQ99WHRqywudWSC2eBkG8mE5R c1eOEdwbmpTRz8VkQOvAIFkG8npxNHJ0s2kCMj24gDIc9G14yHdbbzU5oIjvl0kthqWHSgMyHQz QRxs= X-Gm-Gg: AZuq6aLl5mMNuaxvPIMsqSZtKJvfih4yIZj+WJ9ajQSpTNpbq3sJv6PpOAWalisJdlP gVohvrWAK16eGWEDx1113Nb0BQiEzEi1vpc5Gf5OLUQKE0IPAILwx9r+kI7s+6ab0mUq+c6fy2N FfDyXe6P1TX79+v+0ysVDxrpF+PpYA0IHwAYcHbbp7FJDJTveFWf5oxvn/n38C1nT45b/jjukRX jg4srhfZU2tD1CqAR4Z85NHwXM5+VDGh4t3CgF9XpVmgQ9PWYFIHDThK2/p6fzK1ITYO7OYHlYH mZjp+Y2NmyHXVIQx4APrv00ViqzJdrmdz4Iu8GN56MfGMrvI2eCDS6AVbX68i7EXALzemFC2z4v K32q7RDc8+0TWb8O0nAjlhaChRx+Jms7JfZkykdsnbyN49Ec8PWCPjJaqFj1ETut3zNbEXFPvPM KE9StJMHxqp4xjdEuj1IG4nCJHF6aLxevg1TsrPEIk+/LuE2PZUy72L9bk19RWvEG0kFtc4c9tJ sA= X-Received: by 2002:a05:600c:4692:b0:46f:d682:3c3d with SMTP id 5b1f17b1804b1-4803e7a4b90mr60794575e9.13.1768989952641; Wed, 21 Jan 2026 02:05:52 -0800 (PST) Message-ID: <27f291a3-6546-4834-a9cd-22a4636b152e@suse.com> Date: Wed, 21 Jan 2026 11:05:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Marek Marczykowski , Daniel Smith From: Jan Beulich Subject: [PATCH] x86/EFI: correct symbol table generation with older GNU ld Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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 See the extensive code comment. This isn't really nice, but unless I'm overlooking something there doesn't look to be a way to have the linker strip individual symbols while doing its work. Fixes: bf6501a62e80 ("x86-64: EFI boot code") Reported-by: Roger Pau Monné Signed-off-by: Jan Beulich --- Should we try to somehow avoid the introduction of the two symbols when using new enough ld, i.e. relocs-dummy.o not needing linking in? --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -339,6 +339,24 @@ SECTIONS *(.reloc) __base_relocs_end = .; } + + /* + * When efi/relocs-dummy.o is linked into the first-pass binary, the two + * symbols supplied by it (for ./Makefile to use) may appear in the symbol + * table (newer linkers strip them, for not being properly representable). + * No such symbols would appear during subsequent passes. At least some of + * those older ld versions emit VIRT_START as absolute, but ALT_START as if + * it was part of .text. The symbols tool generating our own symbol table + * would hence not ignore it when passed --all-symbols, leading to the 2nd + * pass binary having one more symbol than the final (3rd pass) one. + * + * Arrange for both (just in case) symbols to always be there, and to always + * be absolute (zero). + */ + PROVIDE(VIRT_START = 0); + PROVIDE(ALT_START = 0); + VIRT_START &= 0; + ALT_START &= 0; #elif defined(XEN_BUILD_EFI) /* * Due to the way EFI support is currently implemented, these two symbols From xen-devel-bounces@lists.xenproject.org Wed Jan 21 10:13:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 10:13:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209558.1521527 (Exim 4.92) (envelope-from ) id 1viVCr-0000Fj-A6; Wed, 21 Jan 2026 10:12:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209558.1521527; Wed, 21 Jan 2026 10:12:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viVCr-0000Fb-7a; Wed, 21 Jan 2026 10:12:57 +0000 Received: by outflank-mailman (input) for mailman id 1209558; Wed, 21 Jan 2026 10:12: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 1viVCp-0000FV-HR for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 10:12:55 +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 bfd934a7-f6b1-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 11:12:53 +0100 (CET) Received: from AM4PR03MB11152.eurprd03.prod.outlook.com (2603:10a6:20b:6cc::22) by AS2PR03MB8772.eurprd03.prod.outlook.com (2603:10a6:20b:553::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 10:12:50 +0000 Received: from AM4PR03MB11152.eurprd03.prod.outlook.com ([fe80::ef31:b87:b7b4:ddbb]) by AM4PR03MB11152.eurprd03.prod.outlook.com ([fe80::ef31:b87:b7b4:ddbb%4]) with mapi id 15.20.9520.006; Wed, 21 Jan 2026 10:12: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: bfd934a7-f6b1-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Vgl+hc4/FuBLefjGA53Ho2eunNAVWZiHGP0lUyXooh1+bTErtoBHHQsptc4sCkdaE06542bM88lLZ+4pmKFrE/Xrc2MmScrMHlKSw3zbDPVtj3tVvojuzuKsuvl4fJZINIoS6ZKM1pS2JWlFhOApqYtDztlcF8t8ix2yjxUPJpaJAt/FiLbvh/ZFUIslhtRhfoWiyCl3/rVf2k5KcoBX2iDF+YspkKrdui9rtqNPQAdyFtQGGy2nMEBhlpVdy8MsRlTYlG99IjFrYV8zhH0zlEnWi2ZaXtc22BopRAaX0anUuMm2LhpiFCIZ85oykwo+Y5zb8lRyNJzb04DwH/WE2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5Jjdh5X98Iwpaq5E6u5s/W4d3SPNINX+DlilZ/kV/7Y=; b=JNyxerMe9wQWlgVQ/xLknhFnQCwu40Cc9EOcnX0cF4gdMvF/vnkwjESy5oMConrrBuBdN5Tt4ZPveOc7rwfQbBWNn6sfbOuOxARFS8sUpZFDPnN0N2aFX1NWs7k/XpePHc9p0sysF1DU0+gub8UWbFuDinMKoAlZ6sKvaZZgq2pkUEtayznZ5qiAAafr3n5UxNNqMnLeaZ8BnWqNXWCBgzGiHaAdcMUtiGyWvcF8q32iCT8J4dt/c6XD3fKJpNo+1XeNxrgIYh0+LuqyT4CQfFBDhV3iYXkN1GI5forphOE59zrFi0c1psn79QkHSwkY+ElmaFpoll0pRkAczdR94A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5Jjdh5X98Iwpaq5E6u5s/W4d3SPNINX+DlilZ/kV/7Y=; b=XqOv07ezLfeSltA7kwia+SwlK8T2Wlx844hWMVqXwU3EyhQgkV7KijPq9xZihG0bozgUPoSwSq8xL85UxMbzvK2kEJBDj/32+WWxJitPxNdKpurQ8XdYIfOacvKW4HG6VI5WJpUR04k1xLH6ggPmxb0wWEG5x5ShsDRm/Z+4p0z/nIGthFAas2u1qxWjxH+z6DpKlP03lUHNqzYzj3FAHggdHuOak2ys9Xi2L6sc/36rbAI++FH2J1LCVRovDDtBinqT4Hpf+jN/gvIp3bMrkUBRUS2fHE5tpH2fDKW7kPE1W4tP1EV4nw511rndqg1x1dpU9V/5az+u1IvXDrGO8Q== From: Oleksandr Tyshchenko To: "Halder, Ayan Kumar" , "xen-devel@lists.xenproject.org" CC: Michal Orzel , Stefano Stabellini Subject: Re: [ImageBuilder][PATCH] uboot-script-gen: Add support for specifying domain P2M pool size Thread-Topic: [ImageBuilder][PATCH] uboot-script-gen: Add support for specifying domain P2M pool size Thread-Index: AQHcijnrd0sgeuOEFUiPnDmCo+f/yrVbY7wAgAEEwYA= Date: Wed, 21 Jan 2026 10:12:45 +0000 Message-ID: References: <20260120182346.114435-1-oleksandr_tyshchenko@epam.com> <7dfe66e7-73ae-4420-8e3e-e7acf814ddf0@amd.com> In-Reply-To: <7dfe66e7-73ae-4420-8e3e-e7acf814ddf0@amd.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: AM4PR03MB11152:EE_|AS2PR03MB8772:EE_ x-ms-office365-filtering-correlation-id: 64ad7a35-8771-4a63-e52d-08de58d59f62 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|42112799006|1800799024|366016|376014|38070700021; x-microsoft-antispam-message-info: =?utf-8?B?OWhXZTMwVk9UaDE0NFNsaS9pUFMzcHBjb0RkRmtCT1hoRGJjNnhJa25jSU12?= =?utf-8?B?MFMxbWdER212N2REOER0SzR2OC9MOXpOK1RRNDdsZExEay84U2FXcVVZWGZk?= =?utf-8?B?ZkxZNjU0RFVvTkxmUGIxZTNIVXNnZDY5QWlhcUZEVzBCcyt4MGxvK3AwT3ow?= =?utf-8?B?aVFyK0JDRnhWaElxcldLaU92NHdJZTFKa3ZtZnl6Nis3YUhaNVVYaUJPNFhk?= =?utf-8?B?U2dvZzcyYmtDNGdUd05jMXZIdHRHdnQ0bEhqSWp0aTJlR2lqUFUyTzNCNGRT?= =?utf-8?B?SXFQNWxlZ1FRVnBVQ1BqUWZvb3hNUXJQbFFZMG5nQnRxbElNbHhVVG9MYzVi?= =?utf-8?B?Tk93UUY1aUdQM1JVc011VGNWbkRyL1FXY21rREZTUkZsb0VFN1U0dUw5ekpi?= =?utf-8?B?OUNHT0g4UFdQRzc0OHJlWVFWb2p0cmpYYmFpYlN3dG14ZjF6ZHVMR1hIQ0U5?= =?utf-8?B?MXQ4YVlmb1FuOHlRcEorRnUwRWJ6ZDJCM3c4OEpwUzhYRVFVZHdIWXRJb3Rl?= =?utf-8?B?bHF0ZVR6eXJYeHMyelhaWWhUMDNGdXBQTFN3MS9Xbm1td2RadVQyWHBVc21K?= =?utf-8?B?RFRkeDd4dzBPM2RSem1oOGoxWnNSd1JIUDRObjJaTkN0Y24vQ0oxd0FGSzJ1?= =?utf-8?B?SzlqUHUvSllrUXpQbEdLN1NlWmc5Z2YxU0VUUzc3R0hjTk9ycVN3NHB3U1Fa?= =?utf-8?B?K2hiTHNXQWdnZG9HSFNDdjJUbHZ5MDFrSDdJWEhIcjhUR0dFWFZtVGtPVmxi?= =?utf-8?B?N29ub1VXcVZKQUg2NUNWdURkU1VVQ09iUFVEOWRpZFA3SDVsTkJudXptZW55?= =?utf-8?B?YWdqMEpGaHhqc1VDc21zTzdSMUFBWk92eit2UDhUVkRsR1JXT3BhNGRlNGZa?= =?utf-8?B?OXhxYmE4NWtHRWhSRm52NXoxREF1N1ZrTXlOalBXNUFZRjdNQzRyaGZnN1Yr?= =?utf-8?B?aHlGMlB5REZVdndOOEY0V1VnWjZHS09YVEExU2VKMjIxZmxrNmZjUlV6cldr?= =?utf-8?B?Z3lpbEFOQTR0ZEVrYXpSbHNXYkNVTWdJbjExS2JIRGJhbW5WaVZZWFkwclNn?= =?utf-8?B?VDVHOW9odEpIZXp1QksySmsySktOcVFGYU52MTZLcHAzWGd5d2RIUkRnTkJN?= =?utf-8?B?NEJ0d2toeGgxU0NyRCt6S09ySDVmT1RFb1lkb0RDd2V4UFJuZThLYWhXZnVX?= =?utf-8?B?N01EMUhaYTRtVEMyRnJVNUp4U3FFWER0eld5UUtrSFlUdlhndUpFQW9FNTMw?= =?utf-8?B?cWZNdStnaXhjSlk0aVg0S2JwbHJKcHZBdmpaQTdsZElGR2NxR3VGN0poeGhx?= =?utf-8?B?UDV0bDRuL2IvcWJVdnZIcjhYbkE3Q3JMSXRrbFN2dEhGWlF2UStPRXQ2ZTM5?= =?utf-8?B?SGduQVg2WlIrOVRiZTdycHNsRXhadE1SNENZYllaOWdaVnlQMEFGaFM3VkpZ?= =?utf-8?B?MTBWYjhhaVJ6cFVFbnNxbEVFdEJkaFpuR2RIV2RxNjg5MWErREV4ZUZnMU9h?= =?utf-8?B?dmhPMmI3U25GcHZ2TXQ5YW5WV050UllqMkFSOGxTbk1FbXpsd0lDa3lqeENi?= =?utf-8?B?QjRHV2VrbVozeWxsUWVscGJHZ2VYM3lqenJpd05rU3pDdmpUSURTWlFzSzJU?= =?utf-8?B?VHM4ODJTaCtPUGg4UmV4NWE4S0liRDFVRGhqTlZrNGtjWG83SlZxeHNMQUhy?= =?utf-8?B?ZUhLU2QxM1FBdldEeFlVNUNWUU9qaGpJUjFrSlZWdHpSUm5jUjRqRDhBZmJQ?= =?utf-8?B?OVcray93V2NGRS82a3NpVGpISXg0NXNaaFR5dDlBNG9LNGpCek9COGE2Tmly?= =?utf-8?B?RXFKT3dONHZnRk9RNVdwMmZ3WWxvaWxxa3lHdFE0R2tIVVgyZ1BUNW5yY1li?= =?utf-8?B?NjMrb3l6eTZwMU5NUnFnTitja1ZZemVlMHZLYmhWOHFHeTc3eUtmV2FIS2VQ?= =?utf-8?B?c2IySTRWVTBrT3ZqWHlBZmt3Q3VyQlc3ZzY4bHptSVBkZTlKRXg0bEdKNFda?= =?utf-8?B?VnN4bi9oU0VtTTBEbmtucFZFTVZvQWtsdFlJcjlMTXJGdHB2MGdGamwyNWI0?= =?utf-8?B?YVVMbkgzeFlmcHdKSlhRcHc0am01VnNuWkZ5TmZ2WGpNNXo5K3J5eWZYVFBL?= =?utf-8?B?cHorTnFOeGlFdUZXSy80ZTFGUEJ4UUtZbWlqK2c2cGNyMHdKYmVvMGV0eWJk?= =?utf-8?Q?5x/yrvnhNPCQgxe4jXfGf20=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM4PR03MB11152.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(42112799006)(1800799024)(366016)(376014)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Z1N1NStYU2k0dUMrcUN0aTBuamJ5QXd1cTJuVUpQcjRMWnhibG42aFNhVCs2?= =?utf-8?B?bG5XK05na2N6Q0NLQWdXcXIrRm5BeVFZQ0NEODNYaGJQVjZBZVc1bnF3bVFY?= =?utf-8?B?YUt4TEplblVOem8zV0FIZC9Nb29ITUpKWnl3OWtxZW1vQk5qYmo5eWsxaHlt?= =?utf-8?B?RHBNdHlBK24zWjdGUmFkNjNjNCswS2FpQStmeCthSjE0WEw2OTVyN2Iwb3lz?= =?utf-8?B?bTBCbEl3aHBpbGI3M05wU3F2QndzK3NUL1phdjRGM1lxL3RNL2JxRHp0Zm1S?= =?utf-8?B?WnZZYXluUTloMlpTdkczR1NmMHhBWHNFRDhLdHdxUm1JbXE2OXV1MWoxdDVq?= =?utf-8?B?eHNMRkt1RkhqYVU1bDhJL3FjVXlXSXRrQ29TQ09IbEFSUDJFR2FadDR4eTI1?= =?utf-8?B?QXExQUdMb2pERTIrcGRWL0twSXpuaVdHbDYxbjN2b0t4S2pseUZKaXNITXV5?= =?utf-8?B?cTJQM1BCQWNmM1ZRTjFVYmxtZTFiZXpKWkd2QmNIZytJYlZ3QXBvRDcwdlVn?= =?utf-8?B?VDhwRXB2ZkNQL2RpWVFFeVQxdVRoL1J3NUpvNCtRbWZZRVE3cnJ3SG5WK1Y3?= =?utf-8?B?aDJJVVFTRSttTnNpRnFocXU4SXE1SDN6YTNOS0YrY09mYklaYnlOUVJuU2U0?= =?utf-8?B?cm8ySDZ1OUpJQkorMkpnbFRDb1BNZXd2bHJZak5VN3dtMkRaUDN2OGRwNmxL?= =?utf-8?B?VFhhejNFMDFUSHVEanBtR0tNNnR6dXgrM3EyVjFTSHdEc1VpYnVvYWppMWhI?= =?utf-8?B?SEgzVWxOay9jYi95bVBMUi9tQy9tTSsvM1RXcWcrMVJrbzlCcmYwRGlXTlhG?= =?utf-8?B?akZLL1lkcWo3SnkzRWwzSUZvelBpQ1BrRE1rSjM1YjF0ZEh3bTY4cWtXMEgw?= =?utf-8?B?cDBCZTg3eGlCNjlUS0FwTkdPd3AxWWEyMjhnQkM2Wm9ZbXRFUnVPTDJ0SkxX?= =?utf-8?B?aEpsdXFKeGYxSVFoU0lZNTNaWTVHWnlHTG9IQVU4QzU0L3RTTGR3RDFmT3F5?= =?utf-8?B?LzBPYkFGQ01Yd3liMUp1b1FMOEhXQmp6TzlieCtnMjJsZWJlMjU0bm5Td3cv?= =?utf-8?B?Tmh5WGVxTkpXRGU1TEVwOWY1bEZ5NkpFOEJITjlqemh4TlpabGxrWkZnTTl4?= =?utf-8?B?cFQ5dEJPemV2UjFPeXVwRTlCYmh6SG91cytyU3dybTdTK0hMRm43N0llSGRq?= =?utf-8?B?QmxnbEsxbHl3dDVxTzljVDN2YmJmL2M5RkhjajBIRXdUdHZJd1M3NGtjNmlh?= =?utf-8?B?ZWx2KzFReWxEYm82NEdxWkJrR2xIdTNYWlBjaUd0d2R6ZytOc3dmclpPZ0pH?= =?utf-8?B?a21VOTdQRHQ1WnA2K0xpUVdHK3Rvd1JSdVduYmxJczk1bDFUTWt4RkNSVXdH?= =?utf-8?B?TDU5TkcxWDR2Z3o2QVc0d2JJaGwrSkErdHoxQ0VvSFhxZDF0ZDJ1NkRwZnlt?= =?utf-8?B?bUpTS2FSeW02SjI0MDZnd1IyTXFKd004STlZWU9Ra09vWExuU1BWMUkyZ01s?= =?utf-8?B?clNDRXQ4cXBkZERGN1dTcXV5WFpQNmp2Q0R2dUxNUk90SUhXZFp3WlBZdW82?= =?utf-8?B?ODdqNTNMSXY0eHIySTRlZWkzZzREUU9kQzhUWmQvc2dPMytnMUwxRDN2emZV?= =?utf-8?B?dytNbEVQaU1zRk9tVnNYSU1UWmFla0hmVGN2R3Qvc3V6a1JaYkVQYWZkTnpo?= =?utf-8?B?ZndPRktEaEcxRkRRdkxoajRxUVVaMVFscXJ1M3oxRmpvL3c5cnN0MlA2emo3?= =?utf-8?B?SVhwTHMxak12VlBNNnQrRkpVR3JZMXh6U216eEVzdFV6U29nY21xV3FYWW5i?= =?utf-8?B?NzNkMUtPM1BKeVBJMmRMSFhvUnlsMHlwUjRjL3FsckVsNlpudDhuRFhFYzZx?= =?utf-8?B?Z1VqcTBvcWdBSCt6SDI3RVhmb3dlY0lmUThYYlM1MlQreUtkYm5UUG5LYzlu?= =?utf-8?B?ZkdRWXNjNzRLVGd1NUNVZldPRTMyc0VGVzRhOGRwdlVxZDNJaWVpdlBJU0R5?= =?utf-8?B?V29VYWZlN0FFV0p3WFFlUlBvcHdPbjlQM1oxRVNIc1pGbW9WYm1OT0VIS2xa?= =?utf-8?B?bzdtaHBwYnA0R3ArRnJXbHNXMzZ3MFZpcG9YclZ4RG0yMWkraWtLQ3l6eXdK?= =?utf-8?B?MEtJSTBRekFnUEdSeVE2dmNXMWFLTWNpODBJMHV3aGRESjVUdUVPWS95RzJN?= =?utf-8?B?SDJQU2g2b0tndWN4a05vdUJ1Y09NUEhTUmpWeGprME5kd1lQOHFZSm5Ceitl?= =?utf-8?B?ZWIrVFA4S0lyZlM5SGN4N0hUZ3FkYk01OHMxNzFMTHZUbUpydlYxckUrbE5R?= =?utf-8?B?SzlUSGJkbkJFZ2VhRUV0WlB5dWlHMEw0cEtxb3FCU0hFVU93amtRQkFpQ3Jv?= =?utf-8?Q?v9NSTVSvSZnSpA87hzlQbQXPsXHsIjl6CoOzK?= Content-Type: text/plain; charset="utf-8" Content-ID: <8CDCA8B98599914B87B95D60F57B6E36@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: AM4PR03MB11152.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 64ad7a35-8771-4a63-e52d-08de58d59f62 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2026 10:12:45.8218 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fB0jUBAZe0f6ot2/bShox5Ycf6Cwsf6B6IepWU7C4kmQJvMjA10j28nHkjKuAxVapbLZFBCc7L43zu+Iqo5FhdehAvIXoqLUELL5PiYPvBQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB8772 DQoNCk9uIDIwLjAxLjI2IDIwOjM5LCBIYWxkZXIsIEF5YW4gS3VtYXIgd3JvdGU6DQo+IEhpIE9s ZWtzYW5kciwNCg0KSGVsbG8gQXlhbg0KDQo+IA0KPiBPbiAyMC8wMS8yMDI2IDE4OjIzLCBPbGVr c2FuZHIgVHlzaGNoZW5rbyB3cm90ZToNCj4+IFRoZSBET01VX1AyTV9NRU1fTUIgY29uZmlndXJh dGlvbiBvcHRpb24gaXMgdXNlZCB0byBzcGVjaWZ5DQo+PiB0aGUgYW1vdW50IG9mIG1lZ2FieXRl cyBvZiBSQU0gdXNlZCBmb3IgdGhlIGRvbWFpbiBQMk0gcG9vbC4NCj4+IEl0IGFsbG93cyB1c2Vy cyB0byBtYW51YWxseSBkZWZpbmUgdGhlIG1lbW9yeSBzaXplIHJlc2VydmVkIGZvcg0KPj4gUDJN IHN0cnVjdHVyZXMgaW4gbm9uLWhhcmR3YXJlIGRvbWFpbnMsIG92ZXJyaWRpbmcgdGhlIGRlZmF1 bHQNCj4+IHZhbHVlIGNhbGN1bGF0ZWQgYnkgWGVuLg0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6IE9s ZWtzYW5kciBUeXNoY2hlbmtvIDxvbGVrc2FuZHJfdHlzaGNoZW5rb0BlcGFtLmNvbT4NCj4gDQo+ IFJldmlld2VkLWJ5OiBBeWFuIEt1bWFyIEhhbGRlciA8YXlhbi5rdW1hci5oYWxkZXJAYW1kLmNv bT4NCg0KdGhhbmtzDQoNCg0KPiANCj4gd2l0aCBhIHF1ZXN0aW9uDQo+IA0KPj4gLS0tDQo+PiDC oCBSRUFETUUubWTCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfCA3ICsrKysrKysNCj4+ IMKgIHNjcmlwdHMvdWJvb3Qtc2NyaXB0LWdlbiB8IDUgKysrKysNCj4+IMKgIDIgZmlsZXMgY2hh bmdlZCwgMTIgaW5zZXJ0aW9ucygrKQ0KPj4NCj4+IGRpZmYgLS1naXQgYS9SRUFETUUubWQgYi9S RUFETUUubWQNCj4+IGluZGV4IDk4M2NiYmMuLmM3YWU5OGUgMTAwNjQ0DQo+PiAtLS0gYS9SRUFE TUUubWQNCj4+ICsrKyBiL1JFQURNRS5tZA0KPj4gQEAgLTIwMyw2ICsyMDMsMTMgQEAgV2hlcmU6 DQo+PiDCoMKgwqAgTk9URSB0aGF0IHdpdGggdGhpcyBvcHRpb24sIHVzZXIgbmVlZHMgdG8gbWFu dWFsbHkgc2V0IA0KPj4geGVuLHBhc3N0aHJvdWdoDQo+PiDCoMKgwqAgaW4geGVuLmR0Yi4NCj4+ ICstIERPTVVfUDJNX01FTV9NQltudW1iZXJdIGlzIG9wdGlvbmFsIDMyLWJpdCBpbnRlZ2VyIHNw ZWNpZnlpbmcgdGhlIA0KPj4gYW1vdW50DQo+PiArwqAgb2YgbWVnYWJ5dGVzIG9mIFJBTSB1c2Vk IGZvciB0aGUgZG9tYWluIFAyTSBwb29sLiBJZiBub3Qgc2V0LCB0aGUgDQo+PiBkZWZhdWx0DQo+ PiArwqAgc2l6ZSBpcyBjYWxjdWxhdGVkIGJ5IFhlbi4NCj4+ICvCoCBOb3RlIHRoYXQgdGhlIFAy TSBwb29sIGlzIHVzZWQgdG8gYWxsb2NhdGUgcGFnZXMgZm9yIFAyTSBzdHJ1Y3R1cmVzIA0KPj4g Zm9yDQo+PiArwqAgbm9uLWhhcmR3YXJlIGRvbWFpbnMuIEZvciB0aGUgaGFyZHdhcmUgZG9tYWlu LCBQMk0gcGFnZXMgYXJlIGFsbG9jYXRlZA0KPj4gK8KgIGRpcmVjdGx5IGZyb20gdGhlIGhlYXAu DQo+PiArDQo+PiDCoCAtIERPTVVfTUVNW251bWJlcl0gaXMgdGhlIGFtb3VudCBvZiBtZW1vcnkg Zm9yIHRoZSBWTSBpbiBNQiwgZGVmYXVsdCANCj4+IDUxMk1CDQo+PiDCoCAtIERPTVVfVkNQVVNb bnVtYmVyXSBpcyB0aGUgbnVtYmVyIG9mIHZjcHVzIGZvciB0aGUgVk0sIGRlZmF1bHQgMQ0KPj4g ZGlmZiAtLWdpdCBhL3NjcmlwdHMvdWJvb3Qtc2NyaXB0LWdlbiBiL3NjcmlwdHMvdWJvb3Qtc2Ny aXB0LWdlbg0KPj4gaW5kZXggZDE4YWM1NS4uMGM4NmMyZCAxMDA3NTUNCj4+IC0tLSBhL3Njcmlw dHMvdWJvb3Qtc2NyaXB0LWdlbg0KPj4gKysrIGIvc2NyaXB0cy91Ym9vdC1zY3JpcHQtZ2VuDQo+ PiBAQCAtNTE0LDYgKzUxNCwxMSBAQCBmdW5jdGlvbiB4ZW5fZGV2aWNlX3RyZWVfZWRpdGluZygp DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBkdF9zZXQgIi9jaG9zZW4vZG9tVSRpIiAi cGFzc3Rocm91Z2giICJzdHIiICJlbmFibGVkIg0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgIGZpDQo+ PiArwqDCoMKgwqDCoMKgwqAgaWYgdGVzdCAtbiAiJHtET01VX1AyTV9NRU1fTUJbJGldfSINCj4+ ICvCoMKgwqDCoMKgwqDCoCB0aGVuDQo+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBkdF9zZXQg Ii9jaG9zZW4vZG9tVSRpIiAieGVuLGRvbWFpbi1wMm0tbWVtLW1iIg0KPiANCj4gV2FzIHRoaXMg cHJvcGVydHkgcmVjZW50bHkgaW50cm9kdWNlZCBpbiBYZW4gPw0KDQpOby4gSXQgd2FzIGludHJv ZHVjZWQgbW9yZSB0aGFuIDMgeWVhcnMgYWdvIGJ5IHRoZSBmb2xsb3dpbmcgY29tbWl0IA0KY2Jl YTVhMTE0OWNhN2ZkNGI3Y2RiZmEzZWMyZTRmMTA5YjYwMWZmNyDigJx4ZW4vYXJtOiBBbGxvY2F0 ZSBhbmQgZnJlZSBQMk0gDQpwYWdlcyBmcm9tIHRoZSBQMk0gcG9vbOKAnS4NCg0KDQogIElmIHNv LCBpdCBtYXkgYmUgZ29vZCB0bw0KPiByZWZlciBYZW4ncyBjb21taXQgaWQuDQo+IA0KPiAtIEF5 YW4NCj4gDQo= From xen-devel-bounces@lists.xenproject.org Wed Jan 21 10:15:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 10:15:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209571.1521538 (Exim 4.92) (envelope-from ) id 1viVEu-0000qm-PZ; Wed, 21 Jan 2026 10:15:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209571.1521538; Wed, 21 Jan 2026 10:15:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viVEu-0000qf-MD; Wed, 21 Jan 2026 10:15:04 +0000 Received: by outflank-mailman (input) for mailman id 1209571; Wed, 21 Jan 2026 10:15: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 1viVEt-0000qS-Di for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 10:15:03 +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 0b92b4d0-f6b2-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 11:15:01 +0100 (CET) Received: from MN2PR10CA0034.namprd10.prod.outlook.com (2603:10b6:208:120::47) by MW3PR12MB4476.namprd12.prod.outlook.com (2603:10b6:303:2d::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Wed, 21 Jan 2026 10:14:57 +0000 Received: from BL6PEPF00020E62.namprd04.prod.outlook.com (2603:10b6:208:120:cafe::82) by MN2PR10CA0034.outlook.office365.com (2603:10b6:208:120::47) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.9 via Frontend Transport; Wed, 21 Jan 2026 10:14:56 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF00020E62.mail.protection.outlook.com (10.167.249.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Wed, 21 Jan 2026 10:14: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, 21 Jan 2026 04:14:55 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0b92b4d0-f6b2-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lrDogGQnxmp2zTt5CQh+Yl/NCjXmReTCfsBaVtvZ88fh7Gra9GS0FotXyxEkRJsFGHGfleMv7qBfHvDYvraZlDkP3k/foSYPYiBgMj+3pSNQONwwPYY3y0XPQGkQNRJdJ3tOU/tSa/L7oztA/Pb3TOfWF8tlivyA04dqnQin9RTrdI8+C1wCz4scINLw27PSwaHjDFlRQnqJPJFruvQkLaxUCu9GuzV70aj3ULOyJyCu0+YXUJpB7t7lHXHOaKjp+6hGR0d+YdzR8eDuM+Ab21ZhyJTlrA+wH3q+ZwZfRge4qP/U7GVckkaH8ij90WJuKG3DY2TT7IuJtqWtZXZSoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kb/tGiyo3qWKeaMR0COArIKTzjNddp3s/jztw8KHiG4=; b=sX6RjPHc72jxNXPXLUbBCGdsVptYihoDucUCS6jdnvUcg3/gu5ws3NB8tHUtIU9CfD5zQ0dwdwpQr8AqsukG/lds0faYCsfmDt5+lrDG+byWjdOMhRY0djjV0ULI15cRBJP+9N53pIWyzMu3AkEs0C58ea82xBO66chJ340CjcjWjdoQAHmazA+IhQkYMkwfk8oTKNDDTnX0EQaztXXhc5tW9qzKpWydm5SD7L8b56PjO5rU1fqzXGHeWKIBlc9vfVYQcEMfe8yoLttYNZNVnSYne/+3q6Ri4CstrviaaT/W46XAwejbts49KonnFv2PJLRt9WFv4+Eglo84JOUGeg== 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=kb/tGiyo3qWKeaMR0COArIKTzjNddp3s/jztw8KHiG4=; b=5aqNW6pVPZbx5Sa/iCqShgGb7xpnUcpm3hx++snenVdppPO6bqStzEXOiAcmw5vU/jifdOpVoTv5vHsOAw8PXFfKfFRIUJQH7/4xs4AB/Y3FqBx3fvxzMUDflI9IBOiRpAVD2AEDr5PGnKR92WgHx5Xk5Q+S+0X11WVDoTv8B20= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 21 Jan 2026 11:14:53 +0100 Message-ID: CC: Anthony PERARD , Juergen Gross , Andrew Cooper , "Jan Beulich" , Grygorii Strashko Subject: Re: [RFC PATCH v2] x86/hvm: Allow pre-enabling x2apic mode on BSP From: Alejandro Vallejo To: Teddy Astie , X-Mailer: aerc 0.20.1 References: <0cb4d1f91212a65baf924ed0ef825d8adb4b5423.1762958551.git.teddy.astie@vates.tech> In-Reply-To: <0cb4d1f91212a65baf924ed0ef825d8adb4b5423.1762958551.git.teddy.astie@vates.tech> 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: BL6PEPF00020E62:EE_|MW3PR12MB4476:EE_ X-MS-Office365-Filtering-Correlation-Id: 569e70f8-3c70-4186-9b90-08de58d5ed6d 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?R3VpQWRmbWtIT244SWVHWkdkRjd5dzU3WHlZQ0o3VUFQRkZIVFdjdmNKMk1i?= =?utf-8?B?NUJ0SWZSTEo3V244dHd6alk4elpaZGhhcFhXK2p0eDlSMlNrdXlEYWRZeE1F?= =?utf-8?B?MlhoMy8wTW42ZzdoKzV3RnVya01sRFk5QlpqNzZjb2dwRE14OU9yY2pIY1h3?= =?utf-8?B?TTRkVStVUFZ5dzNoNWlYeHpPL2FYRlc0Z0Z1MjQwcnlYOEtWbHBBOXR5L2xY?= =?utf-8?B?cXp4VmNGczJ5Q1NROWdOalpIWXdpcGhhQnJTNTNSUExrelU2ZVQ1ZitvNGFQ?= =?utf-8?B?eDQyakhvajZOd0tvWk1Ea3FwUW5MbmNxQXYzZFdyaVBzWWpHYm01NGxxM1ZL?= =?utf-8?B?N0xxd1dSc2FhYStUNTRCZ2E4eXkyZStBZXFHWUVCTEFVR2hoczZtQ3Q1MUdv?= =?utf-8?B?bzBGM3ZLKzFsNWVBeW42NnZaZ0IvMUNJSFpCTHBaSUZGMmtQUjYvcjF1SkJV?= =?utf-8?B?SjZaMkRRbjFEUWdUV3FCcWNvTjFtTi9LVU1OK0ZDeTlETk9SZnZkcjRab1ZH?= =?utf-8?B?dkhTc3p1WTA3OTRRbjBGWDZQMDRuaERPZDlJRHhoYWhZTHhoNHJPNFdhaWlU?= =?utf-8?B?b29PRFNwOW9YYjRZOG13dlZIOTI0M2ZvODk3TjFYSmZIMDEyWDg5Ym9BRlNI?= =?utf-8?B?V1lnY3BUNVdPdzhuWis3RWhJcUJoNXVJV1VHMEVVN2hsazVkbnRWTi9NTk0x?= =?utf-8?B?WU1VdDNSTndaelY3cXlPTm9rM2VjRGpkaFJLa1AwTHhId1NwRk9sNEtNVlFM?= =?utf-8?B?R2VXT1IyZlZ3anpwSGh4dU14V3krTU9ua3dVMHQ1VHFFcUlRcDJsWVRZWURi?= =?utf-8?B?VmEvTVpSQytsQzlLaGJVMWNPUFMxNTdSeDE1bHRUMzhnZWZ6SmliU1UvUXc1?= =?utf-8?B?MlF6eHpMMjZKWUZqOGJycmRMMEZVUHJ2UHQzVTFFZkZyS1NqNkpMZnl4QUZB?= =?utf-8?B?SmQ5SFdsOWlqNEdIdnJRZUlzK2F6anZSbjExdU9QYU5tN0s3YjM3WGdyRUhw?= =?utf-8?B?S1ZhaytZNDcxalpkaStLM1FJMHRHVEFuYkJ3VCtyUHUrV1RFb2k5RkdCV00x?= =?utf-8?B?SGxlNG9nVXVpaFV5cVFEaWp6NUwwcm43bDJHRWlKQTQvT1lzZEhPd2dvNUl6?= =?utf-8?B?ZUgzZW9KVjNjUnNqVXJnZUlGTWtQbFE3RGoxK1FRRzMrMENYaVJVWndzZmg1?= =?utf-8?B?U2N5dCtiaWFPRVVEWWNvZ0R1NjAzdEYzd042Qm1vNW1qZXo2ckx2bXhYY1RO?= =?utf-8?B?NElPUDRud29YOVdLbElXaWRlNjljS01VenIxenh1K1ByamYyb3M5Vnp1VE56?= =?utf-8?B?K3kwV0cyY0JjWDZNY2xwTXBWSWFuYjVRd2VlK1F3Z2FkWXdhQTFkdVFRREdl?= =?utf-8?B?dFRGRDNaMTJaVlpoNGVkSWlyWkxNS2o5L2FZOVNoVHd4OTE4cUZNRGtrd1k3?= =?utf-8?B?N3lmamxuemJaKysyZzNEYnl6UmxhbldSdW1hRFFPSUxLcDQzTHgyTCtEREJl?= =?utf-8?B?OXJBdTIxN29rejFhbHdZRm5rcnkyaWd3UW0yRGZUNGo2eE8vRmVxMFZvQ1dZ?= =?utf-8?B?Q254blhrdFFBV0NoK1lwdXVnR1Z3S2VyQXV0RmFyUlhjaFM5ZWZrZnQwMlQ2?= =?utf-8?B?bmZxWC9OdHlKSWdhaVdtT0JSOW4xN1RsYUQvMDVxMFVLUHdiejB3eGNvT2RT?= =?utf-8?B?SlFVNjF2OHNWMGtCcEF0U2d5WnVxeGMvU0N4TU85V01vY2p0WG1rSjZPOUg0?= =?utf-8?B?YktlRjlWaHJ1aTFLZzhhRXZiRld1WS91QmVXRTVMWnlZeGx0QjlpR1hydHRZ?= =?utf-8?B?ZDFUMyt3SnhLcU1mUzN0Z1IybmtOOFpZS2kxZUpvYW5OV3ZoYUJPcWQ3Y2t2?= =?utf-8?B?ZHQ1amU0VUZ0cDBZdUQrUVdCTlh6dTZ2Y1V2L0lhVFZhb0pGSHNGa2dPSUdY?= =?utf-8?B?TXRVOVBkSVRtTmo4REZaMzZZdVJVTHZQVEVBZjFPQXBUWXRlNnU3WkhoeE1n?= =?utf-8?B?OXN2ZCs2cmUySmpQYzlsMS9ENFRMQ0d3dTJrc2xtbzdtL2xuT0tkd3FJaWx1?= =?utf-8?B?bEhGclZiK3pFb1grOGxicTJ6QUdJY290TTN0Ry8yRG5MMW0yZDhseE13Zzlh?= =?utf-8?B?VDdGNHdGZGErMVVzZWFxSitZcDB2c1JwZkN5WnFmWEFkV3dpRlRsNFhTV3FB?= =?utf-8?B?aWgyc1hzZEtPVUVPRGlidEUzcWhHK3RhTDlSWCtZU2F1cXlVMzQ1bzdKNnhW?= =?utf-8?B?a3ptaEhKb0FwUzB5bVdBRmh5SlZBPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(36860700013)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 10:14:56.7413 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 569e70f8-3c70-4186-9b90-08de58d5ed6d X-MS-Exchange-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: BL6PEPF00020E62.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR12MB4476 On Wed Nov 12, 2025 at 3:51 PM CET, Teddy Astie wrote: > Introduce a new option to start the BSP vCPU in x2APIC mode instead > of xAPIC mode. Expose this in xl through a new "x2apic_mode" option. > > Signed-off-by: Teddy Astie > --- > Cc: Andrew Cooper > Cc: Jan Beulich > Cc: Alejandro Vallejo > Cc: Grygorii Strashko > > Later on, we could consider with this option to use x2APIC ACPI > tables instead of xAPIC ones. > > There is also some room into introducing a new Kconfig option to > only support x2apic mode, which would change how the "Xen default" > would behave. > > changed in v2: > - only pre-enable instead of forcing > - use domain builder to pre-enable instead of introducing a new domain c= reation flag Hmmm. For dom0less/Hyperlaunch and CPU hotplug it'd be beneficial to actual= ly have it in the domain creation struct, I think, annoying as this might soun= d (because it's a circle back to what you had before) could we keep the misc_= flag with the different meaning of "preenable x2APIC" rather than "force"? Then on each vCPU creation (or even hotplug) we could check whether they ne= ed to be preinitialised as x2APIC or not. Otherwise hotplug needs different treat= ment. On the plus side, Hyperlaunch would merely have a new trivial binding rathe= r than an ad-hoc solution. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Wed Jan 21 10:45:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 10:45:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209590.1521547 (Exim 4.92) (envelope-from ) id 1viVhh-0004wm-W8; Wed, 21 Jan 2026 10:44:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209590.1521547; Wed, 21 Jan 2026 10:44:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viVhh-0004wf-Tb; Wed, 21 Jan 2026 10:44:49 +0000 Received: by outflank-mailman (input) for mailman id 1209590; Wed, 21 Jan 2026 10:44: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 1viVhh-0004wZ-4v for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 10:44:49 +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 3410c81b-f6b6-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 11:44:48 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS2PR03MB8465.namprd03.prod.outlook.com (2603:10b6:8:32b::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 10:44:44 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Wed, 21 Jan 2026 10:44: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: 3410c81b-f6b6-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Pj/TaHskxK5ojStGnYaDZq6Pm0xU5XIzYIVugDqVy8kai6I39mpH/EDHcfGGg4cVAMrt2Ig/BDnMKNnj4Twqva+ElKK0STMzVMWJo4EXWctxic/oNhjobKOidwcjezBOdRiCMiyBZ1efUtEj7W650bBjK1RUe/5ebimCY5UlS3RO6SctXYkCOTQ8zMPLdb6gUhlh/7MTAZvDfEva8KJDmWFmlN1tLMRDzURWkwGLsLgiEmSq4gsI/FgmuVkGvKcYLArqtoczBEHio+kodHa1yfhG5VHSmTG00V3b8PniaYcW7XdNHB1A/OySLVj8GGSr+rYa+jHQFPW6v6l9zUSvVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/1sCkk9HBRqH78MMZZKGvEHnm57eyzSriRmSJeR7KLg=; b=Zq6ScSaNsflSw8qIJbuYByeVSP1VhBbFZs5CYlj0H4wUEMheDyBrRxvne1n8cT/vxR9ebxm8nB4jgZhRMnvJ5j3NNqVhMgqY1ZXq1VhAknDpzOxtj+MOjQLihtck8SOIhjwtu0s4krCWNNmmWOdErhMnCnC2Av3yP8hxWmfN0PYMrZpZgfgFe6vRpx7P6AyHjiImDQOLISaFJp6wZRLoUFbimzeH2OazXPaXtULLDUIKg/eTX+Fy5b2L729CDJbEWcm8jakiN5nWnhIaGTnRwtD+nzLg5YGFQAemS34HfjZWx9zytl5qFKRfToldlN6TxZgU+AxZC3YJ+o7v/pJbFg== 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=/1sCkk9HBRqH78MMZZKGvEHnm57eyzSriRmSJeR7KLg=; b=enQ+sNsIF2PGxqsq5htd+evkNYutyQSlkazxRlN8jFK+t+VfWl+1hlCvjD25DtaqyDNQlLcH+ozbbPLE1cHciS2ZGOTF4ziTa2wyZ8Xc8FMhCEidS0p5zRApbtytKsXswCjXeNVMV3U5qIkCtq1TKWRbSE+NNjYVyWaCFx4ddjc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <95c6eb65-44ef-4a2d-8353-27363b952076@citrix.com> Date: Wed, 21 Jan 2026 10:44:41 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Doug Goldstein , Stefano Stabellini Subject: Re: [PATCH v4 5/5] automation: Disable ucode loading on AMD's analysis run To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> <20260120093852.2380-6-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260120093852.2380-6-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P123CA0065.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1::29) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS2PR03MB8465:EE_ X-MS-Office365-Filtering-Correlation-Id: 6d4cc9db-7a26-406d-8739-08de58da16f1 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?Q2R6aXJ5UmVSWEErOEl3Q09KMEJxNitmUlR4ZGlqWngvQ3pLMEo4MlZPejB0?= =?utf-8?B?d0NhV2E0UDAvT0F4RDlOcU53VU5GRC9YRFF0Z2VDSEE3b1UzMkVpUXBsTDV3?= =?utf-8?B?ZGM2a0tRQ2g0QkRsRmJqVVZnRWpxQ0U1TlNBTjNibE8xTDdQN21LajJmVkFH?= =?utf-8?B?MDdJSW1CaWxhR0JZdG9nVCtLTVRPNEdoRTFXOVNHbENiaE1wTnB6UlFEa3VL?= =?utf-8?B?SjRDVFN0RXBlSi9Yb3lzVkI3TmdqU3o1TE16ZTZSTG5QSGxCczJxZ3Q5cVI2?= =?utf-8?B?R3R4M01XRXZvVy82eUxYL2xFU0ZCV1g3ZzRTNlhQOEhwekhxcmFZYUh0MUlH?= =?utf-8?B?UWlnQSs2S3FHR3FqVy9CR0JBa3JLM3NGYklLZllEdU9pQlBsZ1hvSTR4Y0ZT?= =?utf-8?B?ZTllaFd6OFVpTDY2OEtyTmZFSjNBeXd1MlE0aytpaXhhUjdZakpRcmRKek0y?= =?utf-8?B?WEROUUtWSUxFVHVWK0VRK3o1RklTTnV4UUNmengvQkZLY2NXTWtMcWx5OHg3?= =?utf-8?B?QStCQU1jRDdEZjlQbVRMdmlTRkp2aWxPb2hxN2FJakhOQjJOdEdrSnhoUDY5?= =?utf-8?B?YW5hUWZnSFo5UjFWRGUwV2dlMnNqRjhOa2tzcDBFclZXLzBDMllFbXFTNDNC?= =?utf-8?B?OFZOMjNaTlEvMFJvMGlhME85YVF0bHhlSEFGN1FiWXV0eG9Pb1dZSUpyYXRT?= =?utf-8?B?OEpqeTVTMlV2QUpWcGNPb1JPYkxhMnI3VHZzYitNUFI0NjJIU0tibVc3VUZi?= =?utf-8?B?Qk11UUxkcEo3R3ZPR0tCZHhCSkpzTDhiZzVDQUhveHZ1MWIxMVNKZFh5VnpG?= =?utf-8?B?ZWllTDJUbjFIcVB0N1U2UTBOWlA1eGt2WTFDZStiSEVwZTRyd1NNZWptZFli?= =?utf-8?B?Mm5OaWNTZnplNzN2L2poK1ZtWnZNd3N5RHVzVWU3ZFkwVkg1Q1c2Q3RaUWRp?= =?utf-8?B?K3dLR25UOHRUcm5hYWk3dmg0S0ExdEFYSXVjbDhBQTgzOStxTEt0R0VwTnc0?= =?utf-8?B?VEJseS8wTUhWOFZlUkVwNnpuYW9SaG5oMzQvNjU4OXU5TFRmQ0JMZWdwME5h?= =?utf-8?B?b1o4N3gvbWJPVzdSRENxSXZEbHNSclF0SDNmeUpyNXBmOHJJbFZBNDZOVkFT?= =?utf-8?B?ZFVBZ0wvNHY5Z29JdklXUTRIUlE0aGlOTVZkSmVIMTVIOEdFTXMvMENWUFVJ?= =?utf-8?B?VUVNK0puQ09ZbVFMVDJzMGJrWEVKakJhanJuMDdZZTZxK1M1c3YzZkRPY2Jn?= =?utf-8?B?RncyYWhNQ2ZaUTJmN2lLRU9RWUdYanlXT3Jub0t6VnNEQ2dxVzlHeEVSbnJD?= =?utf-8?B?V0phbE9LSWp6OG4yemtUelp0Vm92ckxYcGNHai9Ybm00NVY2b1pzMHdaQUJv?= =?utf-8?B?QzVqSWtPb1RMNU1YMGh1ZXdSbmxLbzNrNDVFY2d3ZUlXS1Ixa09aUUxkK3pW?= =?utf-8?B?cnI5T2U0K28wSCt0b25mNllhNWJJQWZUWCt0TXBkcGFQMFQraW1NaFk0b1lU?= =?utf-8?B?azBLK0tqWjZkUlE1bTNRNHV5WC9UNmJ2bXoxNEs3b3VCcGQ3L3UwVm0zcTFZ?= =?utf-8?B?VVk1VUZxd0Q1TEZQL2VFWkx3T284L2hZU0daRHVmV0FoT1VSWVhZaGxaWEFK?= =?utf-8?B?WFNIbk1pT24zdmJBQ3BlbEUzbG1saEFRMWpQLy85L0Zpa2NjTWlXSXo4TW1m?= =?utf-8?B?dWZSQjl3ckNjTTJvcHhtdndFZkFwMG5zMWFOaVhhSFJCMXk2d3doOXU1cGMr?= =?utf-8?B?RC8reDZuYWxCeWpWb1djdzh5cWxxQnJoRFpWdVdyKzJ3ZkYxd1h4QXNUTnVt?= =?utf-8?B?dHVnZjNoL2JZN2c1Und0OG9jeFFBUXY3RE80dU1icThqeFRqWHV4V2l1ZXV3?= =?utf-8?B?WmFkRTkwT1Z6RXJuM1FCSmJQNllSSmlJMGlPZjc2TkJDOWZKeFN4Z290cjdN?= =?utf-8?B?TXFndVNPT1ZobDhIeFZnQmtQQ0wwS3Vtajl1cy8ySC8xaDVnZitTUEFHanJt?= =?utf-8?B?dDZGQlU5bURsL3BpajRQZ3BuQURVVkYzTkNpRktaREcvbzhJZ3dnbVZMOGwx?= =?utf-8?B?VkYvZCtnUzlNR0gzWllXNTI0SkE1ZHhuVGpkdXE4VjN3dHUxNGsrYWk1UEFz?= =?utf-8?Q?10Ow=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NGx2dXhpWWI2K3BZS3MzYkdKcHM2NE1xaVFuVlNVNjBjQ0RDR1pvUkdtYitB?= =?utf-8?B?V2U0VS82dHdTUEhvQWh5bmFUdDI1c0MvaXNTUFV1ZmVjZ3ZQNXVPWEZncjdP?= =?utf-8?B?NWszUWtIMDZ1MFBWdHo1Q0RibXo5V2cxN0RDY1FxZ09ab3dyOUo0b3hPaHRE?= =?utf-8?B?bG1HREt0SEsxVmYyY21wRUV6eXJBeW4zdWF2cTlTTkFLQkpGNVNxWXZsOHNj?= =?utf-8?B?UnNCM2srOUQ5NUdDV2VLcVBTemlVNmlSRkRraDhCbTkrendzdzZzQnc3aXNo?= =?utf-8?B?U3ppTzFlUDArMCsrdDNCdFoxc2x1ZEZWbWlTYjJkWXNFejZXRzJTWFJwUEV3?= =?utf-8?B?N1VZL0RjbENqL0N1UWpJeXNTcGlRRThOK3kyTWs2SldVbnp6Yjkvd09MUjhu?= =?utf-8?B?M0dMMGJnZDFWclk4dW5ZUHVGaHBFd2wzTDRGMlZoNlRONFdETjBsVWl6eFRR?= =?utf-8?B?NEE0QTdDSGdkUWg1QlNhN0pNLzlrd0hDNkhOTDFCaDhSMHA4UEV6czlJUy9q?= =?utf-8?B?aUZkejlSWjRld3RYd1VxcVlxNFo5V1htZXc0UCtjVGNSdFF2TERvK1BtKzdp?= =?utf-8?B?bWVwbW1tcS9GeWduQkNyTzZNS1RHZFByMWRPUTNyd0pHUCtwVVRhRW9HMUNE?= =?utf-8?B?dkFJZDNQWEFrZlo5YisrYzI4cWlvSE01VngxN090VXJaZzlyQkd3eGtvVERX?= =?utf-8?B?emRNNXZIZm5ucjZFWTk4Z2ttZ21JUCtSUnV1WVIvUE9FRXNIM3FSd0E3MFlQ?= =?utf-8?B?R3pJelBGckpPRW5iUlRQblV5VC90cnc0cGN2L2xlVm1xc254OTFuQXZQSE85?= =?utf-8?B?SmFBbDZYWXEvQ2tWWXhzYlYvV3UzRHFPMmFETVhhVFdWaDR3TE5MemhhMG4r?= =?utf-8?B?MzkrT0daQ01CeXdvTDdkeDRGRTJvcDJxNkVEZTJ1YjdJV3lBaldqVWhGY05t?= =?utf-8?B?QktueHJoZ3pWT20vdjU4Zmp6ZkNOaHZRR2wwV2NtWlBBRmI4Ly93VTVSbGxx?= =?utf-8?B?YzM0YzJCVHorbmVHNGZaVnhXNE90Nk83cklubGxXVVpmNGQ2MUFKUkM1eDh6?= =?utf-8?B?YUtOSVdNckF3RnFENmlqS1hPK3M2Z2NYNWoxMmIrSVJuUndsM3dXaG1hR3NR?= =?utf-8?B?TDdQaGw2eXpISXFXYXRmVDhOVE92SmhYQ2g5bDFORTQ3TlZaeFBZSkhrUVZl?= =?utf-8?B?NE02amNZQmdyUjY3dXBxMWRMTVJOZEszNUJlaXZGUDhqWlh2dTQ1M3VQZEFr?= =?utf-8?B?ZFp1VEZFNmREMjZraHcrRFJpT1BSbG9xZndJMUhuQVRhK0pOUTI1YWJDL2t5?= =?utf-8?B?Nms4dzJvdzhYU05tRUVIdFBnSjFLR1BZT1lZb0V1S25aaHU2V0VEKzdXTmJV?= =?utf-8?B?UDhNbXVoM1k1cjFoNFh0Z0pHQzl4dWpVSkdsWjd4cWVmN1pzSkxVVlhLVjBs?= =?utf-8?B?RDNiNGRxTWdnWE1zbGZHQkcxV3dnMHRDSDkvSE14RUdPQUpuUUtLQVNJYlBR?= =?utf-8?B?U3FhQ2I5OCtWYmxEUU5SOHNEeE5uTXRSNEVTb3U5dnBRcjRUVG1VYUYrMmJn?= =?utf-8?B?cXJiR1l0Z0x2RHZvSGdCKzFOT3ZBZjJMTDZoYXJEdkw5QkpzeVdlWFFoMUtQ?= =?utf-8?B?NWVBeEZTZmNSeEovamFPRm5QZ3ZrWDQxV1BnZVZuOW5xek1BR2R4c1U5V3JQ?= =?utf-8?B?N3lnY0Zxb08wcGhWcGJOSmZ1Z3pJaCt5dHY1OFNIV1o0b1NOMXdqMzlYRlpy?= =?utf-8?B?T1lZOHZHWmQwTjkzQXhwY21TckJseENOdUJRS0tkV0lkZnVXaEt6M1R4Ykhz?= =?utf-8?B?c1VpVW4zZldtYlJGWTI3MThiZllSRU1GcDQ5Q252anI1VU04eTRGeno2LzZL?= =?utf-8?B?a1hBOWE0VVdoTlkwWEJ5bDJMVmt0S3hJV1I4OUJVNUhic0lSdkNKNlJjSm9W?= =?utf-8?B?dGk2MytVaVhMc2FGL2Y3bjF5S2ZrNEJvaTZ5bCtGbFVtSkRUV2FKaG55dkZU?= =?utf-8?B?RUwzdlBDTDVLakVtZHBHWG83SEFYREtoLytCMkY0cmk4Y1JxZld3cnlDZXJR?= =?utf-8?B?WW5BeGFWdjEwM0hFY1dkVi9jVUEwT2FjM1lOVkFPMkVVVzNRb3VHdlpHVXZa?= =?utf-8?B?a1JXRG1vdmJiaHVlSGIyeUpJbFlkVmlpeGhKOUNoSHZKSWJPVlA5RXVUU01S?= =?utf-8?B?S3dPQ3NkdFBXeU13M250MHZPTDZMdWk4NEhtcytzM04zYnBVRm85R2dvRnh2?= =?utf-8?B?UE44aWdhekxrSXZ1a2Voczk3Mm1JcTQxczEyM1hKNlBoUmlwOFRaN0hySjg3?= =?utf-8?B?Y2NkcE9LWnVvUXFidGR0SHJHTDJ4WlBUVGtYSXUwMEtYRjlydVN2U1dyOU1q?= =?utf-8?Q?ftqfLAwret0R7k54=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6d4cc9db-7a26-406d-8739-08de58da16f1 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 10:44:44.4917 (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: 2pQAVlVOT+paxDOPPRyfQdLaHgYQKKWoGW14oEZ50th1eKgDvMucnhETsIIMRfwhzbFDP0ofz8SmyeH1n7YnZvPtx+GFONpBiBXaBBACq3Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS2PR03MB8465 On 20/01/2026 9:38 am, Alejandro Vallejo wrote: > Explicitly set CONFIG_MICROCODE_LOADING=n > > Signed-off-by: Alejandro Vallejo Acked-by: Andrew Cooper I've discussed this enough with Stefano in the past to know that it's part of ThePlan(tm). ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jan 21 11:03:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 11:03:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209602.1521559 (Exim 4.92) (envelope-from ) id 1viVzp-0007lP-Fj; Wed, 21 Jan 2026 11:03:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209602.1521559; Wed, 21 Jan 2026 11:03:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viVzp-0007lI-Bh; Wed, 21 Jan 2026 11:03:33 +0000 Received: by outflank-mailman (input) for mailman id 1209602; Wed, 21 Jan 2026 11:03: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 1viVzo-0007lC-GG for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 11:03:32 +0000 Received: from smarthost01c.ixn.mail.zen.net.uk (smarthost01c.ixn.mail.zen.net.uk [212.23.1.22]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d13409b8-f6b8-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 12:03:29 +0100 (CET) Received: from [217.155.64.189] (helo=mail0.xen.dingwall.me.uk) by smarthost01c.ixn.mail.zen.net.uk with esmtpsa (TLS1.0) tls TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (Exim 4.95) (envelope-from ) id 1viVzh-00DBO0-Dx; Wed, 21 Jan 2026 11:03:25 +0000 Received: from localhost (localhost [IPv6:::1]) by mail0.xen.dingwall.me.uk (Postfix) with ESMTP id E2887DF39CA; Wed, 21 Jan 2026 11:03:24 +0000 (GMT) Received: from mail0.xen.dingwall.me.uk ([127.0.0.1]) by localhost (mail0.xen.dingwall.me.uk [127.0.0.1]) (amavis, port 10024) with ESMTP id LBUjXomlv6gY; Wed, 21 Jan 2026 11:03:24 +0000 (GMT) Received: from behemoth.dingwall.me.uk (behemoth.dingwall.me.uk [IPv6:2a02:8010:698e:302::c0a8:105]) by dingwall.me.uk (Postfix) with ESMTP id 90D7FDF39C7; Wed, 21 Jan 2026 11:03:24 +0000 (GMT) Received: by behemoth.dingwall.me.uk (Postfix, from userid 1000) id 5284E10CB0F3; Wed, 21 Jan 2026 11:03:23 +0000 (GMT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d13409b8-f6b8-11f0-b15e-2bf370ae4941 X-Virus-Scanned: Debian amavis at dingwall.me.uk Date: Wed, 21 Jan 2026 11:03:23 +0000 From: James Dingwall To: Roger Pau Monne Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Subject: Re: [PATCH] Partial revert "x86/xen: fix balloon target initialization for PVH dom0" Message-ID: References: <20260120140648.25977-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260120140648.25977-1-roger.pau@citrix.com> X-Originating-smarthost01c-IP: [217.155.64.189] Feedback-ID: 217.155.64.189 On Tue, Jan 20, 2026 at 03:06:47PM +0100, Roger Pau Monne wrote: > This partially reverts commit 87af633689ce16ddb166c80f32b120e50b1295de so > the current memory target for PV guests is still fetched from > start_info->nr_pages, which matches exactly what the toolstack sets the > initial memory target to. > > Using get_num_physpages() is possible on PV also, but needs adjusting to > take into account the ISA hole and the PFN at 0 not considered usable > memory depite being populated, and hence would need extra adjustments. > Instead of carrying those extra adjustments switch back to the previous > code. That leaves Linux with a difference in how current memory target is > obtained for HVM vs PV, but that's better than adding extra logic just for > PV. > > Also, for HVM the target is not (and has never been) accurately calculated, > as in that case part of what starts as guest memory is reused by hvmloader > and possibly other firmware to store ACPI tables and similar firmware > information, thus the memory is no longer being reported as RAM in the > memory map. > > Reported-by: James Dingwall > Signed-off-by: Roger Pau Monn > --- > drivers/xen/balloon.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > index 49c3f9926394..e799650f6c8c 100644 > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -724,6 +724,7 @@ static int __init balloon_add_regions(void) > static int __init balloon_init(void) > { > struct task_struct *task; > + unsigned long current_pages; > int rc; > > if (!xen_domain()) > @@ -731,12 +732,15 @@ static int __init balloon_init(void) > > pr_info("Initialising balloon driver\n"); > > - if (xen_released_pages >= get_num_physpages()) { > + current_pages = xen_pv_domain() ? min(xen_start_info->nr_pages, max_pfn) > + : get_num_physpages(); > + > + if (xen_released_pages >= current_pages) { > WARN(1, "Released pages underflow current target"); > return -ERANGE; > } > > - balloon_stats.current_pages = get_num_physpages() - xen_released_pages; > + balloon_stats.current_pages = current_pages - xen_released_pages; > balloon_stats.target_pages = balloon_stats.current_pages; > balloon_stats.balloon_low = 0; > balloon_stats.balloon_high = 0; > -- > 2.51.0 > Thank you Roger, I tested this patch on the system which originally showed the error and the pci passthrough now works as expected. Regards, James From xen-devel-bounces@lists.xenproject.org Wed Jan 21 11:17:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 11:17:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209617.1521567 (Exim 4.92) (envelope-from ) id 1viWD6-00013D-Hx; Wed, 21 Jan 2026 11:17:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209617.1521567; Wed, 21 Jan 2026 11:17: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 1viWD6-000136-FE; Wed, 21 Jan 2026 11:17:16 +0000 Received: by outflank-mailman (input) for mailman id 1209617; Wed, 21 Jan 2026 11:17:15 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viWD5-00012v-Bc for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 11:17:15 +0000 Received: from SA9PR02CU001.outbound.protection.outlook.com (mail-southcentralusazlp170130001.outbound.protection.outlook.com [2a01:111:f403:c10c::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id bc411f27-f6ba-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 12:17:14 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by LV5PR03MB8409.namprd03.prod.outlook.com (2603:10b6:408:35c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Wed, 21 Jan 2026 11:17:11 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Wed, 21 Jan 2026 11:17: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: bc411f27-f6ba-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=f21WM8A86tgTBvzKpsCfMpBlcL3i/CM4EEhOkUQiolSoHTfZ3RxgygdT1i7I2JEEfNLQ4MndeAy1XE2cTm6bRf/ZCNmtfrJUw4gCIbn7ixycD+gKupQg1fh75ChpbVe62Jmx27f53YJZkAl/LflUzHkGOlGnDoJ/RIyV8TlabDogzt/V/bQ0WtrhNaY1UCORCSzJ+WNtf9g8qk1d4+mQpbyrj8PGanmmK02yA/si0tcI3PmfddSXuTTiTTFhPWtc+B7186BzlHw7up+u3mTdv4nyHC0AVsfYj0W/1ADZINmouXa044CQC91IPaHtweBzR0114BwRr53X9A6zGfSaSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sKv0P6YLHMGbIrPftXIXlkcyzSLEj4XBAkEKLdidU7Y=; b=pAXZNTydn3UpXIoqiMciwNtXZHdMf7Dy4nQ7o64dKm0Nnu0IfiIA3Tjua9qnQlpKCyUG/EGZlsdLGBEy9tYmzgGajofZmWiKFLENExZAqNbuaP1BjzynOngyfRm6YcKXmsFqH/FH3SuCmdgOhwS4a2LgYsZjRCSJ9nhuc7FunruitsmxnBgeztS0NPVIxyr9XZ2Bhh2UtIelZG+ZucpIookSAF1xWgDRt4WN+53g1wKIJ3smoqLzn/kW9FGgSZcjuiUiR3RE5xZJr0EqcUmHOzV/FiCkLLX1B47l53l9rbdM7wG9Cb6VlMaQAcwIMwIUZmGi6UwVy3x/K/Fc3v0seg== 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=sKv0P6YLHMGbIrPftXIXlkcyzSLEj4XBAkEKLdidU7Y=; b=y8nUov5QDWnxUsagC2u/8Wx3tHwxaxIe9AiIG6wQ1ilulcgiW0I5ZQJsNwIB970WGt/McW0X8wYlQsvxIy5VYzjtRT+ulKYoNHK+xOWDoPeHfwUC+OJ/3fBWfMRFbDOvaPm8h2B279aFT6496FrauL0Pi+toEbobTUsE2iZV1qc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 21 Jan 2026 12:17:04 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jason Andryuk Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, James Dingwall , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Subject: Re: [PATCH] Partial revert "x86/xen: fix balloon target initialization for PVH dom0" Message-ID: References: <20260120140648.25977-1-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: PR3P193CA0052.EURP193.PROD.OUTLOOK.COM (2603:10a6:102:51::27) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|LV5PR03MB8409:EE_ X-MS-Office365-Filtering-Correlation-Id: 234588b7-f69e-4543-2417-08de58de9e60 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?dGZpYzJWS1VvdjhxT3JLdCtMOWNzOGUxd3RFVHBRM0ZGYlhISXBRNndOODFH?= =?utf-8?B?TE9KaE9GOUw5OTNOUmttamQ4bjFUZStCNFE0Y0RLbllFOVdZNjhJU3NpNThw?= =?utf-8?B?c3hJbC82UDF4VVpnUEtrY3A0Z1cydFZLdzhCWDRZai9jVlNWWjQydzcwQklK?= =?utf-8?B?VHV6YjNxS253QXFZSUVkYm14LzdFWlJKdjl4RTYycWd1aDBJWUoyKzNYQlVx?= =?utf-8?B?cEdtRUlFUk85aWY2VXY2ZU4zS1hMWGtiL3MyVlF1UlEzd1NHd2VMekZtYzNh?= =?utf-8?B?azFzeUlGZTNJTngrQzlmb2xybHc0UTlMMngzbWN2dzdRNTlMelJObnZLb3Bh?= =?utf-8?B?TWp4blJCMWJmR051djVmcVBZWkVQb0VtWkJEaExxRkVjUHpJS2VTNnRaZ0l4?= =?utf-8?B?VzFkSzdGL0w4cCtmL2xQMUkrSlNoOVJuVDBoVDh0ekhGc3RPRG81cXZUNXNH?= =?utf-8?B?aUo0QUpOenFwWC9kUjdWdHgxdndON3JTZjJYSHZxQkNyWDA1YVZrNmN0UXQ0?= =?utf-8?B?VngycW5Tc1c3Q1R2VVpZYndQS2NDOXNZWEJydE43VTMxdGZScWRsWkYza2ta?= =?utf-8?B?cWVyT1N5eTl0c08rcWJaOWpYZWg2anRUbWM3ODdqZzZOVy9tajBudUZHS0NT?= =?utf-8?B?Nk1GZllQci9qa2hHUkhiMVZEbmR5ZjN4NjBuVnpnTklwcUJJb3k4K0pPbVVw?= =?utf-8?B?WHZMZmNCWVBoczU3YzFoN0o4WkVXdkVtUEd3Sm9PSVA0dFcvSGNYbWtWZ3ZJ?= =?utf-8?B?QklLMSs1NldJVS8rVWNtcjZWc016cUpzOVdpLzJYbXhhajZhaFRmQllIcUVG?= =?utf-8?B?VzRpUi9WN2NkQ0J5MGFlQnJsclpzaFRhbk8rVHZtNGFJV0dzV215czBZNEFF?= =?utf-8?B?a1dRaHlXYUNpUEd3TnhjOUJRNzF2UVArSEY1VHREWWhBanI1QWIreE5DVW5y?= =?utf-8?B?Z1ZrWDV4M3lXTmd5U3U5S0x5RVd0N2NtWmFrRS9IL1FKTDFTSkhKV3lVNzZT?= =?utf-8?B?SEEzU3lMMlZaN0dneEphUUJQWDZnL2dvNmFoT2c4enpydmJQNnk4L1NFMnBu?= =?utf-8?B?T29lenJPa2NCc3ZvU2Zyc0ZZY250OFN6NEdqYUhaVnYxWGZzKzZvRXJXRk1C?= =?utf-8?B?dWs2dFU1ekhKYmZ0NWVLaVZsMGFDS0dqZ1cwYlN4RXNvRVZRL1FIbU5zMXNU?= =?utf-8?B?NEpLbFhZcWhEQ1lEVDVOcVo4eWs1YkNzUytwMmxLNENzMDB6aStsNVdDaUxj?= =?utf-8?B?RHhOd0xqM3VtQ1ZlZTRZSVJZVGFpejlFZHU5Vm42UkdQNFNiZ1k0bXBMRWlm?= =?utf-8?B?aS94d0FtcWxmS0V2ZGV3dWwrK00zYlhiYXViemNCNWIyWDdiZ0MyZm5uYU5o?= =?utf-8?B?TCtvOTFsT3pPWDBkK3NCd3VhaUtkaFZHeStLWWhUSVo4RmNkSWc5TXpaWUxl?= =?utf-8?B?UzN0RVVhTHJHNEhrNXZsVmh0ekg0SEdxMmZFbUo5aU5Ca1g0cko1bFd3SDlS?= =?utf-8?B?MndZM0hEalQ1WUtyU2RPTTIrUGl5U3ZqaWZDSnNpS3RwVTZlWnh6WnVVY2Jk?= =?utf-8?B?NzdUOGhVcXpCZHZCRGdYQVhMZVR6TTZkUm9wZi83THFEQ1pPM3RWZXJBMElw?= =?utf-8?B?NHdLQ0tpU05oOFJFa3lXQWdBdTg3bUl0RkZ5V0dTK0lvOWpnM3dTQm1mZFYr?= =?utf-8?B?UlI0MnpwaTFGZWE4RTlqWlFpTFQvSEkwWGo3S05Pd0pSUHZQcFM0MVEzRzF6?= =?utf-8?B?OHJTVG50Zzg5VnNFcklmMHhBTnVEQ1d1bFQ1bC9WNzdMdHB5OFJFQlUvNzZ1?= =?utf-8?B?V2pDdzlCWGI0ZFNPMnNMRTBVZG1wUEFQeWtIUzRjVGtVM3dGYzMxV250THdm?= =?utf-8?B?TThZUEtpeXBqMzNOQzdYSDV4S1RNOGdEYUExSXVGNlhUSUtzWW5yR2c0dmw0?= =?utf-8?B?NEZrRHo5YitNdVI0UmNsbDZwbXg0b3liZTladFY5MkdQci94eHZ6a1BiVWkw?= =?utf-8?B?NmVteEZhd3NOQ3lxYXkySjJtTzJCZEoyc3hpajRWMThqc0N2VXhVcjNBVEpY?= =?utf-8?B?VU02SzF0K2Q5T2F3bkQ1OXp4a0tCZ2tkNmFWVmN4VmR4NjFjdnRKeVo3M3Q5?= =?utf-8?Q?xnsU=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bEtiSDZFb3lRQmZoWi9yWjF6b0o3ak9FajJGV1lMLzFINm5EQVVZcE1sVWtR?= =?utf-8?B?L1Zrd0Y4bU5MTk5BUWN2cVBRdG1nbmZJT2liRHl4bWFHT3o1ektBNy9aVGhY?= =?utf-8?B?YkUyem5SdmRucWF0K3RXQzgzRUtpRHFlOVl1RUxwQXBOcUd6TnlteDVkU2cy?= =?utf-8?B?RS9KKzNObVFweCttVW54K09pQTcyczJlbDhjV1l2QUMvcThKVEMydDBQSlhI?= =?utf-8?B?ODkyNHdYVElvZHRVL1Nsa2NxVkttbzlGVWw0QVFSTHlRT2UvOUhublY1SnQx?= =?utf-8?B?WVk1bU81OGZGVVZudW1nbEJNL0RkZG1hZU05QlVFWUhGM2paUi9kcXVCN0hQ?= =?utf-8?B?YTE3NTBsVk1PYkoyTjFUY2YydGJ3YTRhcGtrRmY5OFJidllnNXpwZEI2OFhI?= =?utf-8?B?MmVncmRZSWd3UnFVZ3lNVTgrbDVsdUJqSFJxbGR5WmErVTVvNHY2MVVxZzIr?= =?utf-8?B?QlhodUtrTE16b3ZNSzZlQkRKRmJ0SG5vdGhGWExyK2JWMkFjOE5Sa2ZSSXht?= =?utf-8?B?SFJpSlhTajROL015OENSR3lTTTN5ZnlmSmVDR0NERmt3cnNFUVF4d1NudURK?= =?utf-8?B?NEhTdFdoSjBGYjhnaDZEdVVuK25VcnVVaFNZZGlUaCt5ZEF5QjUweUQ4MTBF?= =?utf-8?B?QzcyMnlZL3M5N3U0R0o5MzFTbzhMc0ROeFBwbzFVbktGSG96enNEN3pjcnk1?= =?utf-8?B?cEpvOEZ5cXFJaTltQjNPSHNmOVBtYXhKbFVhcDlEK0JQQ01wRFRpeU9lS2ds?= =?utf-8?B?NFA2Q25tb3NOKzBXdzNyTlMvMFRCY1hTM0E0bmFnS294Q1B6VWJzWlBYS0hI?= =?utf-8?B?d1p2Y2ZEYmZ5dE9Qa3dXcWxTbFMzY3VMU2ZXWmxoWER6NGkzTFkvSWZLT05s?= =?utf-8?B?ZndFM1F4NFFjQUNKMmFlUjU3bnhkeFlUN2k5VmtkU1RxRHp4MjBVckpsVksv?= =?utf-8?B?K3VOeXMvdXFsS25JMGx6TE0yc1YyNDY0TSsrQlpEeE4rRjZqaHNUZjBDanEy?= =?utf-8?B?V0licjRNaVVuQlpoc094UC8zbUlaL0UzVjRGY3JYM3RScUVNWWZucmpLSzhF?= =?utf-8?B?Ujl0SFNtVFo2QTgyakZYZHByeVlKaHNlQ250L0hTeDNIS2ZZSHJOQmxFM2RP?= =?utf-8?B?RmlSbldKclBHNzMycHI1ejRpZVY0eHFaV2RkVXk0bjc5QjBtMDFjWUNqN3lo?= =?utf-8?B?TzhiOFlPU01RbFVjRXNRTXJWdDhmWUV2UVhMK1poQUpCTERBU3BJTVlVZmhu?= =?utf-8?B?V1RPOEZ5MlpId25PdERZWHJIYWZrREhSRDhVSGFmdkcycUlBa2hIZ3ptemtB?= =?utf-8?B?Z3JTb2h6cEc5cEp3SGFPRHNlc1FOVkJoSlh2Q0FGVm1aZlpKRys4eFJZeTBP?= =?utf-8?B?Ym5XS2FNSlJmS3dPajZGZCswTExSMmNlZENRVEFURmhGVHRPNWNVQmdTVTZv?= =?utf-8?B?RDlhNDQxZkc0WWtSQm1DY0JWYVpmL3N2MFlodFJBZjhyVS9DMEswaFN4bUFz?= =?utf-8?B?WHVrTVAwMW4yMy8zUktROVhEOWhZMDQ2UUZpMnc0ZHpTR0xMQ1RkR2JVNjFi?= =?utf-8?B?c0NnNmxMV0lZK0F4U1ovVCt0MEozRUVTWUd1eEh0SkphOWhjMi9pa2h3WUV1?= =?utf-8?B?MzY0djg2RU5ldk9GRlVTUEhRYU1ZeUJ4dnJiN0hJUXJ5dDROdUk3Q1dDVERm?= =?utf-8?B?Wnk5a0dCejB0UVBpVUFiRy9VN1JLaXFlcldEZi92TC9qMmQ0YVUvcVRkWDlV?= =?utf-8?B?ZTNjT3dKRmMrOE9LYUdod2gvRTNRY1hzWlBmMWNWRThsdERSRjhFNUllQXNV?= =?utf-8?B?ZFRVOW5DY09qZGMvQVk0TWVWbkF1QWI5ZXVPdHF4NmI4dWZRbDVxR1pWZC9j?= =?utf-8?B?N2JpUW9jdVk0cTYxZ1krMGozMjQ5V2pzWHlHVFhGY1BDd3FZWUUxa2lYbnVw?= =?utf-8?B?UXE1OVhOTWF5ZnNXcVJiMmxVU2UrOExiSDB5SUJJYmNaS3NUTlBFZTZXYjFj?= =?utf-8?B?MWlrNjgydFRxVlo4TVpBbjdoaWh3MlVLclNXZVJoL1pON05YSmptbWkwSXJ0?= =?utf-8?B?eHF1TjZQK3BNRE53Y0NSckRwU2JBdDRkMGZobG9lenorOThxYzYxdmVDSWZQ?= =?utf-8?B?aVJkNnR1bjNIVnZBN2ZFU2RxN2RjYzRDM1EyZ2pnMitJTEFCK0hlR1dBdnlS?= =?utf-8?B?Y0xrSml2eVQ1eGp3SXV4eGRtZUREOHpMeTRINVlkVmZqUUViRG9oM2p4MDNX?= =?utf-8?B?SE9maUpWZjBvNHk4L25pM3FsODFsellRM0xxMWpqYm5UM0lpci9KSEt0QU5k?= =?utf-8?B?SEVCd3lxZHNENmVDNSthZnVGdklSYkJJNGdWNURMcFJ1L2czWFhVdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 234588b7-f69e-4543-2417-08de58de9e60 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 11:17:09.8257 (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: JCf4i/bB0t5tTnLGY23+GDNXnTWusXPJsj+A4dGhjIZkrNpy5Uy4tskvzzog/XvE4/rVtiMS3WUPoM+pRKid/g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV5PR03MB8409 On Tue, Jan 20, 2026 at 03:10:06PM -0500, Jason Andryuk wrote: > On 2026-01-20 09:06, Roger Pau Monne wrote: > > This partially reverts commit 87af633689ce16ddb166c80f32b120e50b1295de so > > the current memory target for PV guests is still fetched from > > start_info->nr_pages, which matches exactly what the toolstack sets the > > initial memory target to. > > > > Using get_num_physpages() is possible on PV also, but needs adjusting to > > take into account the ISA hole and the PFN at 0 not considered usable > > memory depite being populated, and hence would need extra adjustments. > > Instead of carrying those extra adjustments switch back to the previous > > code. That leaves Linux with a difference in how current memory target is > > obtained for HVM vs PV, but that's better than adding extra logic just for > > PV. > > > > Also, for HVM the target is not (and has never been) accurately calculated, > > as in that case part of what starts as guest memory is reused by hvmloader > > and possibly other firmware to store ACPI tables and similar firmware > > information, thus the memory is no longer being reported as RAM in the > > memory map. > > > > Reported-by: James Dingwall > > Signed-off-by: Roger Pau Monné > > Reviewed-by: Jason Andryuk Thanks. I've been considering what we discussed and as a separate follow up we might want to attempt to switch to using `XENMEM_current_reservation` for dom0? It might make the accounting in PVH dom0 better, as that's what the toolstack uses to set the xenstore target when initializing dom0 values. Regards, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 21 11:47:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 11:47:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209642.1521578 (Exim 4.92) (envelope-from ) id 1viWfv-0005Ci-SY; Wed, 21 Jan 2026 11:47:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209642.1521578; Wed, 21 Jan 2026 11:47:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viWfv-0005Cb-PV; Wed, 21 Jan 2026 11:47:03 +0000 Received: by outflank-mailman (input) for mailman id 1209642; Wed, 21 Jan 2026 11:47: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 1viWft-0005CO-Sm for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 11:47:02 +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 e561d388-f6be-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 12:47:01 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB5536.namprd03.prod.outlook.com (2603:10b6:a03:28a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 11:46:57 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Wed, 21 Jan 2026 11:46: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: e561d388-f6be-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=NpDqEZU8GEwecuPeEZ7Dw6LN4jSazb5mxEBJuu8CG6qcJhW3XCozzM9AtGH8BHCTOc6I7lCdMtKsVCAnjNf2+59jqaPGKUW1qEVqAQMWyqmDdwMWmhNsDE4aHEpAeg7Q00YE8Z2G3b7hcR4tcGGn/EUijsdI1Mix3H0tzwE3SJKazei2EXB/Q/bx7KIyVPWElp+rRJwjZSz7CJCiSlrqdE9TogNfYBKQx1Ud2LiIwP9rAxYOzFKeutNqSG3ndCNzv6BnvPwLKe082K2iX2Tq7QqikOepmretijYKdQfJ+/m2dYqiNigWN/VQorHuPKjEKzBXhIbgTL+eILu8CZo8Gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vZ4bFcGFTRZHAmeK/YLqceUf8iIRLY9rilOKREF96c8=; b=yQ9UmO6BylDc5H+J5UMyn6fmVMWTBHV2OcoAPIyg6u+iuU/cNXql63CAocrTo/o21lfYG1MJtTRHSsgz9xY+X6NVMB8hPnyRZlRASZ3UsB6lgnDN2kYNWDN8u25u1oYB2Zfl2fAEO07qdB3EMmTVM292O72KzIcvW/58EsBA7z0RdSHdViuqnFiWhSK0yBn3SBLgZgkeuUrGKnPsxi6fsBFqDticwOkfLktv3kEJoKCNtiOVGXyhkDJbQ87KULiWzYNZzLD+UpoBQg6sepZUS99yZVGD6/KKBGAzSEs5K6zoSJYZL8GxInYHwig86oWkFBBmGKg/y8r4JaVLeik4zw== 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=vZ4bFcGFTRZHAmeK/YLqceUf8iIRLY9rilOKREF96c8=; b=lo8AutfZa8/zj16vwkokXSSVWaPhicjh9ybw3XBb0rZoQOQvOe9Kw24Y9ADB0gxpN70ubqgpfNulwVDBQs96b5ZZijnpjUE8HZc1HgJHuSkGgAI8ZpDvtDR55Tgs2Lg6g2kN5XhHMDStOy8AgId5xgWqQmgeqIfmS7pSGoNAZiE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Wed, 21 Jan 2026 11:46:54 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel Subject: Re: [PATCH 1/3] x86/amd: Fold another DE_CFG edit into amd_init_de_cfg() To: Jan Beulich References: <20251202105710.1472927-1-andrew.cooper3@citrix.com> <20251202105710.1472927-2-andrew.cooper3@citrix.com> <55f40e49-027b-4162-94f0-54573fb1abc0@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <55f40e49-027b-4162-94f0-54573fb1abc0@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0698.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:37b::11) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ0PR03MB5536:EE_ X-MS-Office365-Filtering-Correlation-Id: 3b3bfbf7-2ecd-45a5-08c1-08de58e2c825 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?SHB0eVhqWFBKejhtM1Z5M2JKZWZlUEQraUFSU0xjUFp3UzJEdUlpWGRMVEpj?= =?utf-8?B?eVRUckNMelFQTUUwVnQycURhN25pV2xyUDFpZndqaElZQ1Y5K0MyeFpBZjhp?= =?utf-8?B?a0ZkRmw3ZFhmVTd4MjNjcjVJZGhmVWN2bFZQSVBoOCtHODJkTVpjRDQvTmF1?= =?utf-8?B?R2ZBS3FNOGd1MDAvZVczUjhSeHowVGFPbVZxcU40eitTNWF0LzNkR3RXMTRD?= =?utf-8?B?THEzK0FtSjluWnQ5VFg0TmZ3Y2NPY29nSkwxTlVoTFZtZ1hpMWZ2MTJmcmpv?= =?utf-8?B?TmVxV2FjMi9WQWZvS1FQZmpPeUtpWG5KUkgyT21SVWZJeVllNzM1YUpCL3JV?= =?utf-8?B?LzM0cVpvVWtpcWw2a1AzNVNTMm5Ga2lkbzVNa2NJMlpvdWNJWVg2M1JyUDBG?= =?utf-8?B?c2lyekVWS2MyWm85R2x4SXV4b25ENFZKZWcrNHp5UEZ4aGg0NFFQSnExYVRt?= =?utf-8?B?KzYvYzFaem9zWFg3MGFtUWZBNWwyTEM4R1VMSU1oWHUzV1BqWFZ0ck9UcHA4?= =?utf-8?B?M01PVGk2aDl4Y3pMdjFJK2FzcUZlZ3FGWi95TVdWaHlzUlBvL0FyWUF2N0x2?= =?utf-8?B?VGNuVzA0Ykc0WkRSMXZGVzVTUUQyV3Nub0xVZVViYnRaenU2VVN1WUFpeGha?= =?utf-8?B?YU1rVFNMcEVnU0JVK3VybTVIMlVVdVNKZXYvdXpwUWlXR05LcDYvVTJmSVA1?= =?utf-8?B?cEV1UzVBOWhGZklCRG11aXl3UUFtU1VPUzQvemoyd0xqS0pIUnczaTduYW9G?= =?utf-8?B?NldiYlMvblVGL2pDcmsrOHNPckFmTU13b05hM0N5bXM0NXQ2b0dLdUdiMmhW?= =?utf-8?B?bkJjRWxQYWxuK0VXdDdmelozc0U0cUVnckFFUkZSeGFnRE56djhIZTRVWEpH?= =?utf-8?B?UUQrbGFqU0srRjdZcW5CM3NTR3ZXbVNEbjEzL2d0S0RuZk9DbnBNVUVHWTcv?= =?utf-8?B?czFIM1AzZXkrOW0ra09OaXZ6U1dQbWZDdEd2MlFoZFJUeDBudU8vZmE4dHFy?= =?utf-8?B?bXFaclpHdnNYR25oanA0WVpiU3lHUWU0TnVieGJ3U2NnMEIvTlFlVGQ0WHoy?= =?utf-8?B?Q0ZTd2ZYckdoYmNWTUFTYTlIdXQ1RnFnS1lBR1kwRFhnM2xRMTFkSXV3bW9D?= =?utf-8?B?OWkrZlJVYWJlU2NzYk9VVHc1RTgwQThHcE1XemxEekR4MlJnVncvZFM5VTVo?= =?utf-8?B?bkZGQ0ZtaGFhd1B5cGFtcHlVckMweDN2a3grRm16cStDN1NjWC9ueTJvQUhY?= =?utf-8?B?NFdXdmd2Yi9yU0VPZE0vNGR3OStycVIwUXVvcktsQ0krZkJxT3FYbmlMWlhn?= =?utf-8?B?SkxuLy9jcUlrSDFUN1RGR05yQ1RZUVlXRDM0REp6cGZPOUpLcy9vMWh4TlZn?= =?utf-8?B?Qk5YNkkvS3NKY1dwUEVHUHhYZGkvYS8yait3UWMwaTA1Q1hxU1BJN2FPdTNh?= =?utf-8?B?UGVRVXNhZnNSQVZudTdrOW5sd3g1bTJtTG9mRWpmN0taY0RheU1jTXhCKzRS?= =?utf-8?B?enViSm9Vd085Tk5tYW8zSW9yUEpLUDVNQW16MllVTWk3cGNOYktNbXo0T0xu?= =?utf-8?B?SU1vOEt5am9wQWtjdXpEZ3pZKzZDY2F4RVN3U3hWYjJaL3VVQWUvbWFvTEsr?= =?utf-8?B?K0tYNGFld3k5bzNiOHFGdXh4ZGYyVnQ5Nk1Pc3QzMTJrYTBKa0YvZkM4Qi9n?= =?utf-8?B?aVdOcVhYM1E3SGprWDF3SE41Vm1LZ2QweFJaeFNnYnZpTlVGclFwbE03U2F0?= =?utf-8?B?TFJaYXRKait1Y1JKS3JmTTVpbUloVjJsTDVMR2U5UjYyNWJQdEwwR2t1aDNh?= =?utf-8?B?MUFLZFpLUlN4bUg1aUJWdndtZmxMVWhXRzUwZVRDWlVnVnExalFvdk56Tmh6?= =?utf-8?B?R0lEK3pKamNoeHplenJXS3JiN2FpZzA3V043V0ZOVklIK1VaaTVUOWFmRzJh?= =?utf-8?B?SC9sUHIvbUxlMHpwSjREYnk1a2NkbFNxcm9meXAyNitPTDBIc295c3VhRjUv?= =?utf-8?B?TkJHQWd5Y0JZWUdsNHMzSDRLaU4xcjBQS0lCRkt1eEowYU16SFIxUGZ4cnNG?= =?utf-8?B?ZGJIVmRtaG9XKy9DVDRyN1dXSDZHcy8xM2NaNlZqZ3JtcnNtR25lRlY0VVFS?= =?utf-8?Q?XxQ0=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UTdXalVBbS9ESkRFdExvTjNEM3d4TUxqQmlTeGp3YmUwK3ROLzZyT2dyaDNy?= =?utf-8?B?NVVQS2xlL3grVk10RWtGVC9EMGZPbGp1eXpkc1N3ckFXeUI3c0tvSkJIRVR6?= =?utf-8?B?dHY1WW5hWlowczBDNE8xVk80T1VqdDJEcHhpTlpnWk8xWFpRUXdvZWhyWWh4?= =?utf-8?B?czBONGZ4bWJaVERiNk5BZnNJWmhISG1SOWkrL2ViaWVHaUw4aTQ1UEwremxm?= =?utf-8?B?dEJUK0VpMHVZYjg2QXdKYzhLUWJBZ0NkYUl2WEx1aGk5dVFVWFc4R1Vub2RK?= =?utf-8?B?SzNkSGUzalc4UXdWQ0lVSFk0UmVyTzlqZjIwaE5mUDhGZm9wbXRWTWxRRGha?= =?utf-8?B?OGFGRmRuVkR1b0hzYWtrOGVvT3R4N1MrampmeHNaQVZFa2VVZGNOZFAyLzJM?= =?utf-8?B?NVVYcVZwbkZCaEJZYzE4NWF3MkhlMVFMYXAxYTdabS9IUHFxSG9qeWRxanQz?= =?utf-8?B?UjMwRHd3Y1pWKzUza0M5aU1NY1NIWGR2NlBIbEtzcXpxZEQ1R1lsRW02QytF?= =?utf-8?B?b2N0ZU1GYlpsN0w2aVpXV2diOG5oTUFWK3A3blBJQU5YMGZweWhYQjFSVklU?= =?utf-8?B?eEMrdkc0YTloTTZWZm8xMmltT3BTMjl3UXBib0lnL3RieDY1Y2FSeHBpU3V0?= =?utf-8?B?eVJtTjRucTlJVmRkaDdGa243RlpsNklzZjdLMVRLZ2w2S3RNNjdmeTFGMVVw?= =?utf-8?B?TU9BeTdublR5bm52ZVo4RklXK1VCQWlDN011NkJ1TzhPSFN0M29wYXJjbU41?= =?utf-8?B?TVo4Q0dQbCtkT3lCNWJyTlZRcFh5OVVFVXVINHp6Z3lOUU8xTFIwamJoL2Nx?= =?utf-8?B?L3JqOTVaaEVTQXdFWWdrZmdlZWFhOXB4V0NqQXhITDFLTytGNUVDR0lNa2Nw?= =?utf-8?B?ejk3b29ad2xWekhBOFZGWjJvQkt0ZEU1S3pneVo2cWtOUlRHKzVYeHRXR05H?= =?utf-8?B?UkRKbFNBZVZFdXl6aW1qNlgyU2t4WEZrV3dnRktzc0p0VUxxRDJvZ3M5d2h5?= =?utf-8?B?SDc3bUp5YXF1b3hwZnFWeWtEYmw4a1VhL1o0d25kajBTZkpMeDdsZ0JKazdQ?= =?utf-8?B?ejFwS0VwM2NoVUVadUZHaG9UbkFKVnA0bXFUc2xwU2NPM1JtTldiZ1JKclBs?= =?utf-8?B?UEZJa1l1STI5VEJhYkthdE1yWXBrbDZ6NG9PYnk3MHRjNkptNkVnMnBCR0Ro?= =?utf-8?B?b2NqSUg5eGc2aDNUaGtsdTVlZ08vK3RITmZqZ0g4SC94OGp3UnkraUhpd2NH?= =?utf-8?B?UXl0bVJtVXBtSC84QzNYak9UUk1GUTluMGpNSEtaa092WXdCRThlN0FIRVY3?= =?utf-8?B?N3ZHZmJRZGU2ME1KMjl2ZWJqMFRqQjEyaTF0TTRqQkdKcm5DeVhpZUdyeXdR?= =?utf-8?B?dzR3NjZRMW9Db2JWQWxUTlA5NFBnTGdTOXVLRTZUQm9aVy90cHBITzZJZk1Z?= =?utf-8?B?VFltSmc1UUQxdTlXdWJ2MmNVK2xwV01nbXhLTEJLZEMybUU4bkpXTklsQjFw?= =?utf-8?B?WUZEdEg5eUVjdmp0M2hqZEpNbC96MzA2UFAwOFFYU0kzQVZsVFc0SHN4UU5W?= =?utf-8?B?VGt1ODlWN1V0ZElGOWxxQ2V1RlBTejVKSEg2QmdpZTVwRWt5WGRwTUZYMWdU?= =?utf-8?B?c1NqOHhkMmR0QlpFTjdON2tuQkUybm5seDAwWVF1MWRPeHZQb0s5TENZa0g4?= =?utf-8?B?azNBaHFLdmUvVGRDQzZUMW1GRDFCeHMvSEJkYVk4NUpvSU1aSFdTTytUMUVP?= =?utf-8?B?bnJwWTA3UGh6OFJnUG1kUjJoRDljcXI0bTNtbjE1K1JaeWFZbGE1bHVYYlIy?= =?utf-8?B?emFjeTI5LzN4N296S0U4VTJCaUlwRG04NUhvZ1pvNlF3bU5OUWVETXg4S2pw?= =?utf-8?B?b2xETFRYWTlsdEh3WFVsQWtFVDVuV2JVbEpSVCtvZXpoV29vVGlyQnJhYytl?= =?utf-8?B?UFRjMEdTVUdsbDU3MlY3RmU4eWNOUlIzb0hRdnlUbjJBM3luYzJvZ0xtdFhE?= =?utf-8?B?VkFiK1Vwb29vZFJWaDhWTWtudWttc1hGQ0VFS0ZYa3dJd21haEw4Vmo5MUZm?= =?utf-8?B?MTduOHJlV1hUWjFMdEJ1ajdMdGM5U3dWd0kzUHdBTFBRdElDS2RxVk5oeHlQ?= =?utf-8?B?Mi9CdkZWeSt3V09QSW5WNjYrUjNKUU1nR00zUGVDWEZOeTVMaVdwbUVyUVg2?= =?utf-8?B?bzdEUXRVejdXd0pZT1QxbWxuVXJPRjZIZTIydnVHcnE2aDJ2MUNEbTVDME1J?= =?utf-8?B?d2xlVit1R2ZlSFhuKy9MZmtjcGpxaVZMY3hVMnBWWnZTYWFNMVRwRHdEakht?= =?utf-8?B?YmJoQjBPbWlGV2FpcEFJZUlvYkRLaXVNTXNnYnZIc3AybVA2K1ZZcjFpOFFq?= =?utf-8?Q?KYTcXTgonycpSBdM=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3b3bfbf7-2ecd-45a5-08c1-08de58e2c825 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 11:46:57.7609 (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: AAxAD0FimWSrcplLyYd8nTVI/u9yKTmaWz0EJhRMIR4w22SIITohi+Tj9RLdNd8j9boMz+Rr86QGkPK/9uN3DRiCEkXYyrDVVVo+Th40NKs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5536 On 08/12/2025 9:17 am, Jan Beulich wrote: > On 02.12.2025 11:57, Andrew Cooper wrote: >> Fam12h processors aren't SMT-capable so there are no race condition worries >> with this path. Nevertheless, group it together with the other DE_CFG >> modifications. > With this, ... > >> Fixes: d0c75dc4c028 ("x86/amd: Fix race editing DE_CFG") > ... isn't this more like Amends:? Aiui this wouldn't need backporting. This does want backporting. d0c75dc4c028 explains how it's buggy to have multiple pieces of logic writing to DE_CFG, and here's yet another one. It's only a latent bug because Fam12 doesn't have CMT/SMT, and this property is not discussed, meaning that the logic as-is comes across as unsafe. > >> --- a/xen/arch/x86/cpu/amd.c >> +++ b/xen/arch/x86/cpu/amd.c >> @@ -920,6 +920,13 @@ void amd_init_de_cfg(const struct cpuinfo_x86 *c) >> if ( zenbleed_use_chickenbit() ) >> new |= (1 << 9); >> >> + /* >> + * Erratum #665, doc 44739. Integer divide instructions may cause >> + * unpredictable behaviour. >> + */ >> + if ( c->family == 0x12 ) >> + new |= 1U << 31; >> + >> /* Avoid reading DE_CFG if we don't intend to change anything. */ >> if ( !new ) >> return; >> @@ -1201,15 +1208,6 @@ static void cf_check init_amd(struct cpuinfo_x86 *c) >> smp_processor_id()); >> wrmsrl(MSR_AMD64_LS_CFG, value | (1 << 15)); >> } >> - } else if (c->x86 == 0x12) { >> - rdmsrl(MSR_AMD64_DE_CFG, value); >> - if (!(value & (1U << 31))) { >> - if (c == &boot_cpu_data || opt_cpu_info) >> - printk_once(XENLOG_WARNING >> - "CPU%u: Applying workaround for erratum 665\n", >> - smp_processor_id()); >> - wrmsrl(MSR_AMD64_DE_CFG, value | (1U << 31)); >> - } >> } > Are you deliberately getting rid of the log message? Yes, it's basically line noise. Most errata like this are not handled at all, and this is not overly noteworthy.  If it were at debug level then maybe, but certainly not at warning.  Fam12h were rare in the first place and are museum pieces these days. > And I assume it is deliberate that the adjustment no longer is done when we're > running virtualized ourselves? Of course.  It's pointless, and a readback would show that the write had had no effect. > > Both imo want making explicit in the description. I've updated the commit message to: x86/amd: Fold another DE_CFG edit into amd_init_de_cfg()      As amd_init_de_cfg() states, it's only safe for there to be one location writing to DE_CFG.  This happens to be a latent bug rather than a real one because Fam12h CPUs aren't SMT-capable.  Nevertheless, group it together with the other DE_CFG modifications.      This removes a printk() which is not noteworthy, and skips the adjustment entirely under virt, where the attempted write wouldn't have stuck anyway. Fixes: d0c75dc4c028 ("x86/amd: Fix race editing DE_CFG") Signed-off-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Wed Jan 21 11:52:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 11:52:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209653.1521589 (Exim 4.92) (envelope-from ) id 1viWlP-0006oc-G0; Wed, 21 Jan 2026 11:52:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209653.1521589; Wed, 21 Jan 2026 11: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 1viWlP-0006oV-C5; Wed, 21 Jan 2026 11:52:43 +0000 Received: by outflank-mailman (input) for mailman id 1209653; Wed, 21 Jan 2026 11:52: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 1viWlP-0006oP-1O for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 11:52:43 +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 afbca963-f6bf-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 12:52:40 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB5536.namprd03.prod.outlook.com (2603:10b6:a03:28a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 11:52:37 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Wed, 21 Jan 2026 11:52:37 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: afbca963-f6bf-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=d8OrcXjSgx3gwc+ZC+CY3T+yN5vfI3edTLlG73bmtVWPGsXNX9EC7paNJ34ZYwW8TkY1DBz4Eu36qIH0LxoaO5esslToPCearJMvNLwaHk1Xn2/ROTY1VmF6T3IFDJnmteGNxETePkMdVFdPcEW7FGloP0NzlJ0wYZwq/+AypYjqX7vp6/Y4X9lqFeUiNWjo1M947k0gVZOVhc0xjZNmko0UJ4ILRN0cbK8Pu969gL1x6st9Ew8KZ0VsYaOMp+iexZ9gnCWFRpcBDbdIZqze3C7eB+TPu2NYDxo6tOoT1UNssDxDIUi9gf8hBJS0lewrjgSTCPfGhoHZWfz+JC/D9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1RJSalKceLaiqmm9kVfC+nw7lO8PCaF+4fKwp08Acf4=; b=IeVMFy7p8IwFbFOQvm2pdJZf2m4lUKuKYQK35SQ5iSHqFvh1Su7bDoZ+mEOfuGVOROla8NimikgLhW4ucuveFU+vbWCO3IRDI/UH+/Jdj0nzfOlROhewrZ13/3MPqAA/OLE2Rk5ZfDXfviHo5IGrJMTTQ6VyyAxPej6ywCMk2qCSo+7swhWG52T1TvKXPhDLVnca0VlJ/+7T5H6FMAmQ8w40+swB0k/ilBe4bZWkVz3nZ3kqqj9twTvObCIaUStNRBhsyvaCuQSDQJxlg0d3WR46dbMKcriyOasq+ZpYQc0NbQMgXF4F970YALu3udFrzNPVqopPc6hbWasQpH61Eg== 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=1RJSalKceLaiqmm9kVfC+nw7lO8PCaF+4fKwp08Acf4=; b=KwmijWF+jI2+eQgAR2VKOI5aDnTa6NYShEXG1L+M19yia87c1p0eTV4sjra895/TqTtXU1TnZs6z8bRG0sbSdNPC9ecu6CgeC0EKbQUW1pP/NXthBDtjudoIJ0wwF+NV7gFKN0IrR8gB8JMnnaH7fi+MeeNye92c4EKjZfvIaNw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <4762dc23-cf30-43b0-ae19-fceabea5d8c3@citrix.com> Date: Wed, 21 Jan 2026 11:52:34 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel Subject: Re: [PATCH 2/3] x86/amd: Exclude K8 RevD and earlier from levelling To: Jan Beulich References: <20251202105710.1472927-1-andrew.cooper3@citrix.com> <20251202105710.1472927-3-andrew.cooper3@citrix.com> <7d019929-24df-4523-9817-6c17017c2320@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <7d019929-24df-4523-9817-6c17017c2320@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0378.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a3::30) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ0PR03MB5536:EE_ X-MS-Office365-Filtering-Correlation-Id: f1f9eb51-342d-4ccf-d949-08de58e392bf 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?QjNOZUVOOFRwRFVmK1dZSmhwWGVOMGRRZURWYkFRV1JPcWlUK3htSUx4WFMr?= =?utf-8?B?djlPd0NhSU1Ic3dFZDlHSlBtVlVnT2NuOGx0QjRLZXFxL01zeHZjQUNET0FY?= =?utf-8?B?YUo3Z2hrS0w4a2Iveko1U2JFclJGQkpIdytoN3drYXZlV0NkUUdFVHI2Z2Mr?= =?utf-8?B?Vm1kZVV1cE1jSnZBakl3aEp2L2ZwczlkNXZ6V2x2VHEwa3UrengzZEpvVXFo?= =?utf-8?B?YUwxSWJQVGtFVUJUNGRvU2FLdVFDUU1DbE1rMXpqOGgxK054bVl4enp2ZEE1?= =?utf-8?B?K0oyU2NvUWxJanZoazVJQk9XOWR3UXdvQ0JYVnMrT3RIalRlaHFXMFBySU5F?= =?utf-8?B?L1BvWFQwUFkwQ25sQWpkUklUaEY1dXMvMFkrV3dpa1hwZDl4M3dvS3RKZnM1?= =?utf-8?B?VGc4dElqSDVNTjY2aEdxNmt6anZSdjRmRlZkc005czJOODRKdURqUXFuNUNH?= =?utf-8?B?MGlzR0dGN2FMdzRhUEJ6NGdOQWNlbmVKMG9CaUF1UGZrSmRVdmFkT0g5M21I?= =?utf-8?B?VC9oV1ZkbjNQVlF6ci9tSENVUVVFZ24rMlRWUjZXNEwrWGZsdXJOYVRYM1NV?= =?utf-8?B?Y0dVVHFFU0pjQ3Z5dHB5TzFpVEN5TG8zMCtCYWpKcG1RbXRqMEZrK0dIZ1N5?= =?utf-8?B?dE9KbGlPaE9wOStMbEJZeFlvRGZkTnBKSXMreHpyT3Raa0I3WWp0dSs1aU9U?= =?utf-8?B?dS9CMmIwY1BTc2VndGZKNHIrZm9jemlBREJ5NXF0Z24vdkp0UStRclkxZXhz?= =?utf-8?B?eVJVSTZEb1UzV3EyLzJYVDFveUR2Y1VUakp1cWVqQ2hodDd3ZzZEUjUvcmZW?= =?utf-8?B?dVN2Y3FBbmpoQVFQMm43ZlZCT2w3b3VLMUJ4SDhUejFUMEx3KzVLRG1MZVVH?= =?utf-8?B?aXB3Wm1kU0xRK2pIMWdwaGpWcWZGQmpncTFzaUVSN0RpWWx4S1Rva0FUUk9n?= =?utf-8?B?UmVvajJyYWhIdmRLQXBEbzA3TFYvWnl0RzhYU2FSMGlXaUNqNXE5YWtjeFcz?= =?utf-8?B?TCtDR0ZxdnhQQVpXaXc5NUF3MUpmZ3JNcHdKdFVDUlpMZU15d2tDSHltVGE0?= =?utf-8?B?cWtEWW0vWklpQWdNby81Nm1GSkgvdkMzeUNDVE9rd2lDNjlsMVA0V24xRjZS?= =?utf-8?B?Y0ljbTlKSStEcG5BNHNYWXI0K3Z5ZXMyOVo0R1dxSnc1bnJhWUFySG0vbmNx?= =?utf-8?B?blQ2WkNMeHV6UEV0eU15d2VVMDcyenRBVVdTK01lNDVFSk1RbWNjM2RMWmlk?= =?utf-8?B?K1ZSWitjL0I3eXpyMXFKY25vTVBjNi9lZzF5ZlQvcmRpak5ReTluSVg2U0g3?= =?utf-8?B?SXBoVWg1aEdSNnMzMStPYmRza2J1N2RSRkd6a3NlQkJlcHlzRCsvUlV6TkQ3?= =?utf-8?B?cmdONjVTWXRUcE8rL05QQ2MxMm9iK3ZTYWZBL25zTW80eGtQVWpOV0tqMWV1?= =?utf-8?B?THFrMnE4Q0ZYTG1RWTU2ZTQvTHV3RVArUDBqcjlKU1RQMFkwNmF1cmJmcWVP?= =?utf-8?B?eG9VdkNmdmROTkd5RCtyNGNmVWxYdnJWcUhjZDdqZjBsS0RwS0J6Q1Q5c3ph?= =?utf-8?B?ZkRvc1VPb3BMV0ZkWFplNHN0R2FpcTBtMExqWGtyNlExRndHSlA5dXhtYVlZ?= =?utf-8?B?QUpTWlpLM2ZuejhLSjRFVmlIeHVvaitOYkJHWk5pNENSOVF2NXphdDNaWHZn?= =?utf-8?B?OHVyN0p6WWtiMVZvZDBaamFMdkI0RDRIdzJGcEVTeWxTZHIzM2dHcERwZnMy?= =?utf-8?B?c0djOVBkNVB5dXpGcDlERHpXVVFsM3lyUSttT2VZNngzejVJZUVMMVZ6MHo0?= =?utf-8?B?amJLanQ4K2djblBwejNORHBNbGRGSCszc0s3dk5IM3FMNTVHaGM0TzJIUlAy?= =?utf-8?B?Wk9sUlpwVENHMEtFVGlaZzRQOEFjYkFqZGpyTmMyWjR6NnA3MTI1TkVmM2Jw?= =?utf-8?B?NDlEK1pBNERFYXhCcmkrRC9aSldXWDhJRHZKMXBqTTgwdDExbVhKbVN4ZDRT?= =?utf-8?B?Rlk1V0lKOEhDSzMwZkVkZHVVVjJPSHVCbG84eU1PbjZaSmxtbmNRTzAwNnJm?= =?utf-8?B?UXdDWnVFL1pMNytvM051dmtCaExmNkpOTnA3bFpISVB0M3JqTXpPVFBRR1d2?= =?utf-8?Q?aies=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WnhlQThFUXpidDVyb0QxNUdxbnhTNXVEZ0dGRTZaM0kxb3J4elJPcll1eEZy?= =?utf-8?B?Z1psZFNxcHhSVUtRUURjU3I5dWFrZFgrYStWT3dZVVlKcmp2b3BjaUVMUWIz?= =?utf-8?B?VWU2cHV2SDVwM2JhZVcreG9mV3EyR3JsUStTNkpMNTlUM3JlNlBLM0pnWHpj?= =?utf-8?B?QXhDcElHaWJ5TGs1MUtUNUYraXFyREdGbUxaNGtQL1ozVVh4VXEyYnhGU3NU?= =?utf-8?B?RmdVTlZ6cU5DY1dhOXJKcDVxRGUrck5qcGgzWjJ0NWRzYkZXL0o4UmY3d0JL?= =?utf-8?B?TUNRYWpxTThRL1lvaUl1aGliZWUzVTFVd0ZZQzBvcWxTYW8yZ0taNExMZjZS?= =?utf-8?B?cTZMSHdQMjZFcW1NOUZ1WFJZS3lnUHFjblBYSTJZRFB6OTYxL1FqM2tYb0F3?= =?utf-8?B?UkN4dXh4WkswS3ltZlJsM1RJWHMyb3JZWExZWVpvNWY4RnV2QnRSTk4rdHo3?= =?utf-8?B?bkZzdzIrWEo2bDRMZE95OTg3Q252ZnhuQ2Nrd21nZlZKNTNKZ2hTSWY0NElj?= =?utf-8?B?YkF3U3VLZFFWcDFmeDF4RTMyOHZMNHVpOGd6WWtWOWp3NWgzWDBpT1RMM3E4?= =?utf-8?B?WXRDeWRKSi9QVS9EMjBrMzdTekJndnhwckE3UW13b1pMN29iQjA2Sm5ZdURh?= =?utf-8?B?Zk41dERCUUdIVGdhN2ROd1hJVXp2TVRrWkVwZVY1ZGFGUi9mZXlBZlE1eTQx?= =?utf-8?B?aWM0V3hmb01haTAzeUQ0c1diUVhMQW5VeHdVMjVtQmRaa0tNNkxKUllvTlgx?= =?utf-8?B?eDZMdmtkR3M0NGg4ekVSdVBBNGM3OWpqVENTM1JoZ014aDhKQnhYZENFd3V3?= =?utf-8?B?MmFPRHFCU3hZWmhaSVBCZFVYRjQzWWhxckcrenIyQm55QVY0TG9UeUJRcDJM?= =?utf-8?B?RkxNRW9reFBta0VIOHhMQitRSnpCUkdCWVhIcEFUU3BNQ21PbStndWxZYVc5?= =?utf-8?B?OVN1RktVZi9KUFNQYllJQUpTWnZzeWhsbk1pYk90ZWdYekFUbHI3cXNFNDZS?= =?utf-8?B?NWVXSTdiUVJtQ1dWWUpMU1BubU41ZFExSXBsdkNJMkZwcElOSGJ5eHQ4eFdX?= =?utf-8?B?MFJ5b1p0VzJvcG1lQnd1czJCODZyQUkzaithblJRYkxwdGxONFd2RVgwWERY?= =?utf-8?B?blRycTVSakNkaTdqYkNDUTQ4NmtveGhnYXZlOFFkYm5WeDdMYUs0aFljdTFX?= =?utf-8?B?WkZQUFVpZzVydG5WWDVsKzc4Q1RaOVB4bWZwM2E2YVVPdDVRVDVGRjFkR0x2?= =?utf-8?B?RnZFZFpLemEvcXIzaXVVZTczRHZqTkZCbzIxcDh0MFpISkMxbzdnbWlabGV5?= =?utf-8?B?cUJ3Kzd5STNYSTJzeWMrYlBiVjlnSWhzRGdRdE1sNXJZdGh2OFc2RnNCclQ3?= =?utf-8?B?aWdVMVdZV2Zhd2YyMWh5RitTN0x6eU9CdTBma25lRm1XOFk5bC9oNDJKZklw?= =?utf-8?B?dmVKUzFGWDZNRjJHZ012SnM1MThoZGFxb2pHemZRTlQreENqcmEwVTltUTUz?= =?utf-8?B?T0QvYlluMGRqMjRDUmMvdk5admdzR1hMMFhHYXdwRlA1c0VVa3RURVVsOVdW?= =?utf-8?B?ZmZ0dWwxWStFUzgzUi9tcDJ1TmJUOGI5T3dLNVhvaGg1NzZEQnRFaldncUFx?= =?utf-8?B?TmwxRzVWTFQ5ZzU4M0cvL01nQXVpT1RRUThMWjJ3SjZLNzZTMVpVU3BMZURu?= =?utf-8?B?VWhZbDJmR0daZXFza0FIalVUV2E3UFhhQUNEQTVMcVZpUW9nWjdWZ292blli?= =?utf-8?B?MlVCTkFQbHovWjFFU1NXMjIxdzRmclhkZi91a1lkUWQ0ZEpndjBIcHN6YWwy?= =?utf-8?B?dkl5UWJCZ1BESVBVQWdRZ3cvaDRnUURKKy9UcjJIU1VGbnlEc2drc1hMbDlo?= =?utf-8?B?ZjV1VWRpMitGcnYrNzBDNndrcHJRbGY3STFCOXczQU4xT295UXk0d0pzaTY2?= =?utf-8?B?OWswaDM4dWVWazRxZXprdHNIckZZdTkxenE4YW0wV3hXcGNHZHA3SnpMV2lR?= =?utf-8?B?dmpEaHJQOEt5TGk1aHdvdVFPQ1cwUHl6WG4zWXlsNlhPeTByWlNiSGlhVFFW?= =?utf-8?B?UkNnczZCQ3A5UllVT3QxRlZvUjRPa0pzUnRRUkV1VG10ditwRXVRdW5wMkFI?= =?utf-8?B?ZnVvSnhTVmttUWUzcjNncS9ZNytTaUJlU3hoUnowQUw0Q1c3dzNPRG83QmNN?= =?utf-8?B?NThqVzlPbHFhRU5hTjM2aWFCTWxYQWJ1Q09hZlU3ZSs1T1d2cUhaZWw5dEVZ?= =?utf-8?B?S1ozS2tsdjdkY2ovRnFBZHFHNStJZndVYzhqNkpBWTRQQ21COHdTZ2tuWCsz?= =?utf-8?B?T0U5d05yWUpHSnlqYjlRaEFMeXk2NDE3VTdkZ0JXaXB1Y09iWE5EaVRoMWZt?= =?utf-8?Q?62eM3I/W51EHu+rk=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: f1f9eb51-342d-4ccf-d949-08de58e392bf X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 11:52:37.8037 (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: SXZTuEWQOfVK0Yvf07nVI+O53CusYKpDFGvSslqIm4LPxacSLqcMeJhO2j8Vn46ihcOkWZdYCVbm89SViSX/RoFugGmrhjmfvfba5XEG5P8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5536 On 08/12/2025 9:25 am, Jan Beulich wrote: > On 02.12.2025 11:57, Andrew Cooper wrote: >> Between RevD and RevE silicon, the feature MSRs moved location. This property >> is highlighted by the suggested workaround for Erratum #110 which gives the >> two different MSRs for the extended feature leaf. >> >> The other feature MSRs are not given and while they're easy enough to figure >> out I don't have any K8's to test the result with. > I can see where you're coming from, but shouldn't we then first document those > extremely old models as unsupported in SUPPORT.md? Not especially, no. There are Intel CPUs with no levelling capabilities at all, that have no (non)support statement.  The levelling on most AMD CPUs is incomplete too. PV Guest Kernels are required to use FEP to get the Xen-approved version; it's only userspace which ends up adversely affected. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jan 21 11:59:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 11:59:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209662.1521598 (Exim 4.92) (envelope-from ) id 1viWrY-0007ZF-3p; Wed, 21 Jan 2026 11:59:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209662.1521598; Wed, 21 Jan 2026 11:59:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viWrY-0007Z8-0X; Wed, 21 Jan 2026 11:59:04 +0000 Received: by outflank-mailman (input) for mailman id 1209662; Wed, 21 Jan 2026 11:59: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 1viWrX-0007Z0-Aa for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 11:59: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 93010c36-f6c0-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 12:59:01 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DM6PR03MB5130.namprd03.prod.outlook.com (2603:10b6:5:1e3::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 11:58:57 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Wed, 21 Jan 2026 11:58: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: 93010c36-f6c0-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=c5sZM0it/JCjCRqPvJ3UvckDdhYyCAkI5g40gwjM2atRSChqn8IYJALewf7bsK/L3HbgoCt769JWMAb2HgmoiwsvwdMiZOOUiYIPTby2uodIuglqDFN4TAXHxlaoYs29T/VswfU2SlQTBVXaZIHDn8bdcHtiKuKJAj3X0pwwpLxFvxxDPHMutMzOeCVbj/Z4lfN9XjppF6MTYU4b4H0rl+sgfgtSWivOFBV2UzqCINDn0J3RzqVFfuSP43xSVrFh4VB3nxOmIbXBNuQfdNv1GLpdJ4Z1/LoNkWVKuXXj17P+3q/FY3JQIThp2QNTKxxmwYPuydqunvAFcWieW+oSgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3VM9xryBx8vMeosmXSUtzaIrbqm5eYskiAubR3TMpDo=; b=YiK0BSzr+zvX1tZwd1G5QZiAAPc5suOLlnfRPCVSkZVLrdomvxI1JfosME+xcH1l7jmkZv1sZZKzGF4iX7VMCWVglyhbg6pJg75Gm+xnZLP3RJXfwIj2m28pXtd56sRV7FNAbjSf8ckb3FgfNveWxif8KPUlaElFl3UC4dFNI3fn8A1YG1c+4VgEMPtXCGIawWlh89C5tIfsbmER/kMVmAR9aV3EyQCZ/XOfmJG209i67yDVuJLTqgsu12SK3ng5JeMvf8L7blgViVoGAUJyRrR9zKQ+AC/DIiCWh5XupFVYfaF/bJ5/qDgLrjzu974KjTlBLYea3NKkKaQMu412Uw== 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=3VM9xryBx8vMeosmXSUtzaIrbqm5eYskiAubR3TMpDo=; b=Hj8EyOZ4fHt3ArYwgLgEXlARla2rZDwD1WkXat7w5EEG+TShC7eaauS6V7nMzSwxLlvkotg+1OJsAQT3lak33kvdno7xqdFyRczZdeIq3YtWgI9dNg0tlyUFShVR6NOD9PYAdgH217NewmIBB8UrbAXg0r0M1kNjnXqR+xn9or4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Wed, 21 Jan 2026 11:58:54 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel Subject: Re: [PATCH 3/3] x86/amd: Delay amd_init_levelling() until after fixes to the CPUID MSRs To: Jan Beulich References: <20251202105710.1472927-1-andrew.cooper3@citrix.com> <20251202105710.1472927-4-andrew.cooper3@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0145.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2c4::7) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DM6PR03MB5130:EE_ X-MS-Office365-Filtering-Correlation-Id: 445c3f53-d7f2-440a-798c-08de58e4753d 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?TTZZTXpYbnV3MGE1eGpJYlZXNVJ2Y3NQemxrQUdwNXQ0d2ZjeTNxd3lZYzhE?= =?utf-8?B?R2ZxMEhIbGtRUUlacVErbjIrSDhMK3pVc0o0blRySFdxUzUzcjZERFAvaHVt?= =?utf-8?B?Y2MwTGxucm5QT1BBMWc4YjI3NjBJalRPQkQwUGNUdzgvd1BPeXlmOG04T0M1?= =?utf-8?B?a21rWnk2ejV3bEpBbTZEU3hpVnNDSXRzVHpTUTN2U09POU1xOXI5Z0dsa0g1?= =?utf-8?B?cWNremRSSEVnME5xMXZiVldlUEhYT0RmcjM0T3YyZnQzUHU5cE1DblNRcXBs?= =?utf-8?B?RmFJaDlheHFVbnhxTzlxRmVrWFdJUS9rTmlTdUxaWm5IbHF6bmthSGJZTzVk?= =?utf-8?B?OFpldk5zQmYyZVdpUFBkR1lkYVBPSTF5NHBTUG1ncG8wK3J0VEpvei9vZkx5?= =?utf-8?B?RDl6VFFXcnF6OVNkSVhrWjgwUEVhZmdZWFhwZmhYUjZOQWJ4UWpGM1dHQ2hK?= =?utf-8?B?Zi9ZUWR2S21XMVBPemNHbEVaZUk5ZHdzSFIzYzIyaWE4OFNJU2I1WHpQL1BT?= =?utf-8?B?cTgxenp3WEg3MDVMY3UyejZmdEFQcW8zZXJIVld5VjhNVEZsR1MvTTFueFV4?= =?utf-8?B?bHhhbEtMM0s2K1JGMXpCeVY2Tk90Q0thWUxHdXk5Vkx1bDlISHhGVTJMdUE3?= =?utf-8?B?TGtSWTh5RUM1L0hMU3RNTjZOS2VENEJ5MFlDL0RRUU84NUZDZk1Sczh3U0Zw?= =?utf-8?B?YjRDQ1RzbjRqNHhhVXVLMFJ5UWxzTkZhbWNEZGp6SXNzQno0Qzl1Mm1PbzQw?= =?utf-8?B?SnNvb0ZtS2dydkhiT3ViUGIxQ1RtdFFiSzJtOEhnbkx5SWFIbUtEUXI4N1lJ?= =?utf-8?B?bC84SjJOMlA0bEVUaWlFWlduT25TUXF2Z0t6MVEvbkZWR08ydHBVdDhJNUs3?= =?utf-8?B?U2pOaDRlWmtHc2ZkZW51eGlYUGozR20vOHI4SHcxY0d6d1ZoRUwrVzQ5M0VN?= =?utf-8?B?bU0rdXFCdGdKU0p5MXhMWUNZTGlZSXVadEM2ZlAya2pwcElTVEREYTdWYmQx?= =?utf-8?B?d1lmWHBCSHBwNEh6MGJHelBUTHBSRDd1MjlRUGZpZ2w3dXRqbTBzVDNuNVc3?= =?utf-8?B?NE5ld0FaQStZWnZDQ3JES20vVXlYVkRrak5ENG9oeHlGd3BIUHl3LzNpQnhv?= =?utf-8?B?dkUwVWVBdHVwUGszbGNmOGFDQ01OTXpUaHg0cUkrQlFSZ1RTTXA2MU9nVmpj?= =?utf-8?B?TXE3b0llYUE0UHdiekRHWG80NlcwMXkyVlUwcmgwNWVhMWpWL3MycXNZSUpv?= =?utf-8?B?Rit6d3JoZS9RTlkyekE4eExMd1pPVyttTXpodlJKOVQ4cXI2Zko3QVU5eVNW?= =?utf-8?B?TUZOSktKdEFFL3FpaHU0emNsMUhEWUkyczFsNnZ0SEZTRGxPVEprQnFRK1h4?= =?utf-8?B?cFRmM1A4K1lrRlJrb2FnYmxTa2hiUFdhM0g5UXhVQWlWOUlVVER0ZlVKVmFT?= =?utf-8?B?RXpVWUpvRkZUM2U2WkNEMFJSUUNkbXFxY0tBN0xrY1NCZ01jNnVkSU1KYll2?= =?utf-8?B?WGtXb0RTc0hpZ0JLOW5aNGRJRldpTVZkR3g5c0lLMzN4Unc0ZFpEdS9heFdP?= =?utf-8?B?QkNnRXplMlFYRVJFL0VXSWNpcVl1b21jbExlVDQ5aU5VQlhYbUh1cnhDSUFW?= =?utf-8?B?NG9BWEgweXl6Ukl2WXF5K2t3WEFhUVJEb2piRStHMldtNnJtbDVkZmVQRFpv?= =?utf-8?B?Nk0ySXQzdzYvNEovSzlqM3JXcmVXYVhLTUVtVGxDa1VRN05IM1FaQ25jYWFk?= =?utf-8?B?ZnIwcE1SdUtWYlc5Z2NNZENtUGtRSlRmZ1FzVUJHUndEVkUwbzM0ZDIvMlYz?= =?utf-8?B?M2pCSnZuRk82d0xjcytWTDR2T3BESytTVTFNQ0xEa1Fud1ZZWUJ2MGU2TjE5?= =?utf-8?B?Vmp0Q2hRdlRmS1RvZC9Ha0IzU1UrM0tVOWhOWEhmS2FvR1BTNk0zS21RK2hW?= =?utf-8?B?VFdPZFZlU2RHN0RhekVtZ3dzd0dKZjNSTnNqdzhUZTBQdEJtQTVjLzlKT0RU?= =?utf-8?B?bkxoYU84WnQwdnIwZWkxeDdRNHFHSXZyQnVsdGxkRzd0OVFKUGNSOWk3TjBs?= =?utf-8?B?Z1BQZUJmeGVFQkRmNzFrODZMZXVDdTFPamlJeEtlWE43K21UWVNNOGczY1Fi?= =?utf-8?Q?ilVU=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SHhBREN0L0dNS2RSVW1sUGI5UUxmc1EzZGhYdFhHRUNuT215RU1uWTZwUkZN?= =?utf-8?B?WFAzQWhQN0ZWeXZvRGdlb0xvZjU5bnJZMENCbXpRRTBCUDNDR2RZTE0zSzk0?= =?utf-8?B?WTZWc1FVVHdLWE5mdUlyOUpZdHFwcnRyS1VmUDNVcGxtbldaK2hxeExtU1Vi?= =?utf-8?B?dHNkZU1qc1UyT3l2ZlVBSDRXb2pNZlRLZGtwajF4QlR4M0VENzdpUXZJakRU?= =?utf-8?B?YzZQWUhqalpPeExoN3lGOFZ4b0NoK1NybHR6SUcyRFowVGI4UVlhK0lZVmE3?= =?utf-8?B?N0NxbE5WcGU2SWMwMW9YQndSSEtKdmN3Skx6ZmdwNlpxWDZuT0pXbXZMNVhB?= =?utf-8?B?TFFLL0RXWFFKNTZrVDl0ZFJWMTJyb3p1WjYrN1Rsb05vRXhHMU9tYU1sRTlN?= =?utf-8?B?NWsrNS9xN0RabThGM2ZzTVFQdGd4UDIzQkl1all0QWV6YkJsc0hlZng1bDJD?= =?utf-8?B?OXRaNTNHZFduSWp3OWt3MUNYbzVhWFRPZUdmZHhUTlVaMVRKSHB5SUFZTmJw?= =?utf-8?B?NnVxYnpHRFRNM05XeVNxSmdySUFlYndldkNWNm9oZXBTMW9CQmorcjRKekNG?= =?utf-8?B?Zmw4OWJOL0JXNXB0dUFkOHNNYy9KSjJuSGxRWHJ5VCt6c3BndkszOVA4ZVRB?= =?utf-8?B?WUhqWGdqZkltOWg2cXprUk9QMG1Db1VHaFJ6V1lKa0VxdU04ekpCa0lSeElO?= =?utf-8?B?UlJLQzhCdE85emdBTUZqWjRtZlNpZUcwUGgyNlVnUjVhZHZpanZ1R2NxZ1Qr?= =?utf-8?B?ZC82OGNZQnNoYUlIaitOZ1FtdjFSSWJlVDVmSlVNbElqbHFpSXdoOVhNMHNR?= =?utf-8?B?Rm91Sk1lNzZHUi9rNDVycGRVNmx6cnMzQjV6Z3JhU2J5dkYxazVvcCt3ZEQy?= =?utf-8?B?ak0xTHRJcTlKN0NYSWpIcVBnWFlxeXUvaDlHMDlYV2JHRnFKT3B0aDY2NlRj?= =?utf-8?B?bHROeHFrRUdsNW5hNlNBSGswelF1SHVFVkR0eFJubG5kSmExcHJ4WTVuQnN2?= =?utf-8?B?cDF1bHVBcEFxYUNuS0hFTWlNaEQ0RlNaUW9oRllhTENTRGJqbG9pNm9qZWFH?= =?utf-8?B?QVBCaG9kTzdaUVZWYlM1ZnMzY25qMkdNM0ZPV2JIRzZ6aDJsSytDbmJ2cW9p?= =?utf-8?B?VGRpZUZ6aVVSbjJqb20yZEpPTTRZV1RqVXFHbEJJR3F5YXRuSWdTSVR6QWgw?= =?utf-8?B?aS9EUmtBdlVvbjV4alAvb0ovMGZaSjNVZkk4M0ZOWXROZksxbG5IUTJZUXU4?= =?utf-8?B?a2pFa1JTbndjZ003SVNaWllGUVFkbElRQ3pNV2lneE5LTXdXZkdkUDFvVGNE?= =?utf-8?B?a1RiK1p1bTg5a3BkTTR5TzNwWGErUUtqdUMwRUpFZmt2cno0V29DZG03emNy?= =?utf-8?B?aGExUm0xeVRqaXljQVAyRUtwTmFWOXdtQUk0S3ErOEZBM3JtY3l1NGRkWC9C?= =?utf-8?B?TWlNSkJ4OWczS2dYcmpiWko4cDhzUUJvcUl0eDc1dVRQS2c4VUVmZWNlcllJ?= =?utf-8?B?S1Z4a3ZrYlhrc2p0ODhnbVNpSkhWalpDMWt3T2o2U3laRFFsOVpmcDhKaUwx?= =?utf-8?B?NGlkZ0VRTUVWUFY3N2JvSUNZNUJsNzN4MTQzSEFLaGdkWXR2RWpnbFQzNHds?= =?utf-8?B?ZHZ2K0VyTGlBSkxkTmVHQmhoRmhScDdzUGd2QWJXODMvdWl3MlJBRXMxdVVR?= =?utf-8?B?U213M1AvTktRSnpDMElXRDlCMDViYS8wNVdKNm9sYWFiTml4SDFyYTZVbCt3?= =?utf-8?B?Q2NCU3JiRXlqc20wc3pUS1JOcjlneW54d1JnMks0dlYveDdPbUhhME5GLzFt?= =?utf-8?B?ZGhocUptTDZUVUtqbVlJdzNjeHVWd2E2M29zK3JuZ1R4OTJjNHdXWEtxbzA1?= =?utf-8?B?L0cvOUR5S25LZzFTaFV2b2VDeENOUTloK0FWbTJZcGFlVHI4azl2cnNmQWZB?= =?utf-8?B?aEJaVTE4bkc1TzBaWWhTaSt5emRVZU1Ed05sMjROTXVoSWloK05DUHNlbFdM?= =?utf-8?B?RFJrV2FJZy91S093ZmxndUlZeVczN25BTmFVSWFvR1JpZTlESDdLOUlQOXFP?= =?utf-8?B?aFM5ZHcvc2hrRDZIVXg3cEg2TFNRU0JaMERUcEVxbk8yOFJTRDM2TWRmbnB6?= =?utf-8?B?VjRXQW9JZDMzK2ZZWFpjTGc0L1FDL0Qzb0lTZVY4bDM4RTh1dTVFM28vVjV2?= =?utf-8?B?SFlNenduaExsZ1BPZm9TWFo4YnNNWGVuRnUvMTFrREdaS0ZFa3h3Rk5xdFps?= =?utf-8?B?ZEFTekhJNUZKKzgwbU1UMmdMcGx4RCtqY3V2aXFtTFFlVmZKRm5CSDFBTWIz?= =?utf-8?B?ejk0TGtkSmI4SFR3ZDNkTDlRajJuOHBQYU95cFprQWc5YkFEYy9za0Nua20y?= =?utf-8?Q?IEEwlnZlXKE8hqH0=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 445c3f53-d7f2-440a-798c-08de58e4753d X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 11:58:57.7781 (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: A3pgrsl5WhfulqPNhT2juLUGRzTpS+3W7BRF56syAzHhGt0f+nk2Wvp0YHeLgN/2PwUHvpjNr/ZHULXgbW2PDE6PiYLd5UJd+X25NSiC+BY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR03MB5130 On 08/12/2025 9:41 am, Jan Beulich wrote: > On 02.12.2025 11:57, Andrew Cooper wrote: >> There's no need for amd_init_levelling() to be specifically early. In fact, >> it must be after init_amd() edits the feature MSRs, e.g. enabling TOPOEXT on >> Fam15h, or we revert the change on the next context switch. > However, ... > >> @@ -1270,10 +1262,14 @@ static void cf_check init_amd(struct cpuinfo_x86 *c) >> check_syscfg_dram_mod_en(); >> >> amd_log_freq(c); >> + >> + if (c == &boot_cpu_data) >> + amd_init_levelling(); /* After CPUID MSR adjustments. */ >> + >> + ctxt_switch_levelling(NULL); >> } > ... this new placement conflicts with the two RDSEED patches which have been > pending for a while / too long. Even moving up wouldn't help, as the TOPOEXT > re-enabling is after the switch() that the RDSEED changes are being fit into. > Surely I could re-base accordingly, but it kind of feels that the older > changes should go in first, with whatever adjustments necessary done either > here, or (in a preparatory and agreed upon manner) right there, or entirely > independently. > > Looks like it would be possible to move the TOPOEXT re-enabling ahead of that > very switch(), for the code above then to be inserted between that and said > switch(). The NX fixes also need to re-activate a CPUID bit, so I'm going to have to rework this all differently anyway. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jan 21 12:41:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 12:41:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209688.1521620 (Exim 4.92) (envelope-from ) id 1viXW6-0005X0-FZ; Wed, 21 Jan 2026 12:40:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209688.1521620; Wed, 21 Jan 2026 12: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 1viXW6-0005Ws-Al; Wed, 21 Jan 2026 12:40:58 +0000 Received: by outflank-mailman (input) for mailman id 1209688; Wed, 21 Jan 2026 12:40: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 1viXW5-0005Wh-4R for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 12:40:57 +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 6caef466-f6c6-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 13:40:54 +0100 (CET) Received: from PH0PR07CA0048.namprd07.prod.outlook.com (2603:10b6:510:e::23) by CY1PR12MB9651.namprd12.prod.outlook.com (2603:10b6:930:104::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Wed, 21 Jan 2026 12:40:49 +0000 Received: from CY4PEPF0000EE37.namprd05.prod.outlook.com (2603:10b6:510:e:cafe::4a) by PH0PR07CA0048.outlook.office365.com (2603:10b6:510:e::23) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Wed, 21 Jan 2026 12:40:39 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY4PEPF0000EE37.mail.protection.outlook.com (10.167.242.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Wed, 21 Jan 2026 12:40:49 +0000 Received: from localhost (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 21 Jan 2026 06:40:47 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6caef466-f6c6-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Kq+nk7Dln4/a8KblEwSl5xVkI+scHN01i3Wx6rFbjcB5yt3jpWXxw62JqEt+56su+UqXJLyV4R/I95v6+oRIKxZLihm8LNYuEoqtYoQWB4tkMmC72WJB1jdDrTt0PhgfJQrumhDCTaqALJEemNg+5xdaT27QsvtknIpuw/Grzr0+Z0ZuJ5TicpacyeXFS6Z8HMbcTZ0MbQUGPZ3poXmst0YC6LwRWS/mZOJcmWlvzJtnrSBsZi2z2diHLGDofT9/u8iBx+oB2qOQPSFVcFPbxenGh9Q93xJTdELwFST7OPFskaHW76xmzxWL3khVLefqgeDzWMBESoWH3e9RJJ4DAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KDTbiEe+7vOD9nVnUGjI676FssFr+cbGLwlghSkzKGE=; b=U36/n7M0VPRs8mo1qz5PmSeNRriHuweOg3E1vjCTxlMH8san/qDCC5JHivj8ysqE1jmXn4sAO87HbP2LNtZhmlMBkxHBI41ybxEd29BncgJKMNumzRlFaymCoGL7CBKFR+k+fAngY/JHrpsG21jP8jbsuXdVR0c6bPMwokJyyzeIY8xPg5uz1Zb8XneY+D5947JXdcYoj5rIxTfNZjqdP3gE33wnJoblZ2Kr2ngdm/KSemlbE6kD9VGcqTCvsQNYMaZWNUtKCTmpNv/8lPNPJ9F8rZ/XwLI01sJCJCip8cZsYZZw3l1mq7ccA7rw+WN7r8DTiVylpQwgp68aV51rVA== 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=KDTbiEe+7vOD9nVnUGjI676FssFr+cbGLwlghSkzKGE=; b=xjtFECg14/nGTu406BkEownZLqsWmWD3KeuSqG5n0AWf+7RP1tJnLXW7jOO16OQdyC0PFODV588WtOsfSkK2+ov7lf5Qx6RUMUcfSYi4VuctPlIG7+QoAG8gFRns/NK6LcdHwGheP1LyOBsM6PRB9Ng6jDq3qYMjC72EGmSaua4= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 21 Jan 2026 13:40:45 +0100 Message-ID: To: Jan Beulich , Teddy Astie CC: Andrew Cooper , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Stefano Stabellini , Subject: Re: [PATCH 1/2] x86/svm: Add infrastructure for Bus Lock Threshold From: Alejandro Vallejo X-Mailer: aerc 0.20.1 References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> <20260120095353.2778-2-alejandro.garciavallejo@amd.com> <9097240c-a892-41e8-a686-b89d84d0c03f@vates.tech> 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: CY4PEPF0000EE37:EE_|CY1PR12MB9651:EE_ X-MS-Office365-Filtering-Correlation-Id: ee34a112-950b-49ce-1d99-08de58ea4e43 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700013|82310400026|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?andDaE1uRWdKSkhJV1ZvUTVrTndJQVRFei9tdDFHcTFPbTllVzBYQzhrMVpv?= =?utf-8?B?dlFoMnZhSjNVVU51TzJXNFczdlR3YTZMejlVM1Jucm9Dd1NROGNxVmRuWGxS?= =?utf-8?B?NHBjQVZQbFM2WVFKVGtFNDVGY05yc3U4M1hRcGM0QkhHMGFKb2p6eUdCRzEx?= =?utf-8?B?WlN6Z1NjLzNhcThOOGZjNlRYekRPc2RHYTVnOG9zT0RkWUF0eWpWQWc2b3N2?= =?utf-8?B?RHZNd3ZoVzVVUlJqbW9IMDRURGZpZnc5dkRvWHJXaFNPbGdvOEhweEl6eHhP?= =?utf-8?B?WndUSVpqdDhyVnEydUZQMG1JZEFWZjV3YUI5dkdTRVV5Z0c1SE4vMmU1SzZp?= =?utf-8?B?cGVsRUtFUW9mWTRPQTdVc3lISkhyV2RCNXJSTmlOVkpyVVdDdnhSeXNUaEVZ?= =?utf-8?B?UnFpTHlRMHFxNWNzUHp5ZnFtUnFDVnJmWGdGZi9ZVTJtN2V4eEJ1Nm05R213?= =?utf-8?B?c1VzM3cwbHdmdTRzUDRJa0F3S0trTkRWM3JyQ3ZBQzNFMGtDRDVuOGcwTGZ1?= =?utf-8?B?c3p5S2h4SWZPYnhWRmJqc0R1cGdlOVJJamxDQWdNVWJMVVAvSit6RmFtU244?= =?utf-8?B?bFZKRE9EUlhsb2J2UXEycUVtcDNoUGZSYU1zSElUOWpDbEo5NGNoT1EzeG41?= =?utf-8?B?R0o1VnMzK2pjR0xSN2kyOC9OOGYvWFhvS1R5VWVjYmxESXMzVFJ3ZEtZWXNW?= =?utf-8?B?NFQwUjFCL0YyUU9TTW5wc1VRQ3haSHJjditsaVFCclhUT3Q1Mmg2dXNwQnVK?= =?utf-8?B?VU1wQ1BHOSszSkNjY29LazhkMDNvWDBnNDdVOXltekI4SVhUVXZVUEtRZlow?= =?utf-8?B?M3hBZUVIdU5nL1hpWmF3Q0RCSFYxWVlhbWNMVnFDQTJncGhYTTFpRDlXaG11?= =?utf-8?B?SFBRTnVsRXBKTFV5ZWhNTHNsTnRFdmNZeVFqUGxQbWZhaVFsNkttcnZSUjY3?= =?utf-8?B?MGM5SXlucDUzODk2OWFoWUg5WlcwRDZ6QmVEZHloejBWclYyeWVGc0JPYVRB?= =?utf-8?B?WjhabUsvZWZZYy9DVkplay9lQXRNdkp2U1pOUzFEWld0WTg1c1JpTXprdW5U?= =?utf-8?B?THMycXJFREFhcXh0cWhRaDJLWW5HdUFYbGl3UUprd1JCT2l0ZC9xVE5LTGNK?= =?utf-8?B?T0hjd0YzMG1yakdPWGp2Q2Fjblh3WDJxMmQ0TWNzVmpiUXkvM3VFQkdNWnp3?= =?utf-8?B?aHkvM2hQNDk4MC9PcHVURGRoWExWUWxxbzRXQnpiWEJFK3N6RVZaNFRnaWxN?= =?utf-8?B?SldhcFNrNzhCcEdGaW50ak5XOEFwZHdUM1VBL1A3bGxSU3ltTlZUVS9XQkpa?= =?utf-8?B?TmxFM2tpakU0YlAxTVR6Z3g1ZGhVKzBKZUxpZStkVlNuRGFtVzBnR2VCWHdr?= =?utf-8?B?d05ZZ0FhdEhYai8rWUVrem5Lc3h2QTI5VnNxQzZSdTJhSkJiRDZoMVA0TmNU?= =?utf-8?B?bmZDMFlhMk40Z0JjQTNYeFBINTRNK3orN0UwTTdvcUNzV2FsanY1MkVYQ1F4?= =?utf-8?B?NmxTZ1krNzdUbWFsVi94ZUd1YjJVUmxybGNtSHVEdXFsVUxvNW5YWWJrM1Jk?= =?utf-8?B?WjBTUXpXMHQwSDR3ck5TdnhvZGJROTdsQklGL1lRN1RkeEUyN1lJZUExUmFQ?= =?utf-8?B?dDUvMHR1TEFVczRJeGNBNG1TcG1TZi84WE1MMTBZTGh0R09PU1B4VHVDRTNZ?= =?utf-8?B?KzNTSzkySDVTbGh6SUJFMHJjMUpEcE9HdW5QK3Y5bzZ3OGg3WFVoOE5NaCtM?= =?utf-8?B?M2J2aVljYUNWNCtzZUVTUndaWkhsMU85TEMvNTc5ZGFaQVdpcktMTEFhL3ha?= =?utf-8?B?RUltRWkweTc2ZHkxV05HcHFhS04yeHROZTdHNkhhbUlWZGpmTWVHcVg0VEha?= =?utf-8?B?MEdvamJTakRjN0pMOU1TUXdtcWRBSVhoN2JXSlBLVFF1M2FSRlpaVDRCMXJw?= =?utf-8?B?NXFZY2VPaVhHZ1NvcHRqS2NBKzZpcmNha2dYbWZVenYvbVk2RjgwTEllTTBo?= =?utf-8?B?ZWh3TVFoV21FcDhBUUVuRkV6Nm5Oc1lEVFpDb2NOV2VhRkdvdkpNUDZ1Mmxp?= =?utf-8?B?MW9mcXhKb1VnQTdqcWV5L08rMGlxRGpOM1VTUmRTRzN5bnpoeFplYnRXMWVa?= =?utf-8?B?Z1pGZGY1RGtuS0VFYTdTZkxzMWo5WWE2alF1TFhON2h3bTJINHhPNlpkaS9Z?= =?utf-8?B?ZGtpVXBXVFdiSG9zbzFiemJPYTJBaDNjd2xaK0dHL0JneDdnVHRab2F1Mi9H?= =?utf-8?B?RXBJOVpETWcvKytoeHFsOVhMTUtnPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(82310400026)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 12:40:49.0926 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ee34a112-950b-49ce-1d99-08de58ea4e43 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000EE37.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR12MB9651 On Tue Jan 20, 2026 at 2:30 PM CET, Jan Beulich wrote: > On 20.01.2026 14:19, Teddy Astie wrote: >> Le 20/01/2026 =C3=A0 10:56, Alejandro Vallejo a =C3=A9crit=C2=A0: >>> --- a/xen/arch/x86/hvm/svm/vmcb.h >>> +++ b/xen/arch/x86/hvm/svm/vmcb.h >>> @@ -65,6 +65,11 @@ enum GenericIntercept2bits >>> GENERAL2_INTERCEPT_RDPRU =3D 1 << 14, >>> }; >>> =20 >>> +/* general 2 intercepts */ >>=20 >> nit, you want to says general 3 intercepts > > And then, further nit, also get comment style right. > > Jan What do you mean by comment style? it's a /* ... */ oneliner that matches what the other general intercepts say. What am I missing? Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Wed Jan 21 13:02:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 13:02:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209706.1521631 (Exim 4.92) (envelope-from ) id 1viXqY-0008UA-0g; Wed, 21 Jan 2026 13:02:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209706.1521631; Wed, 21 Jan 2026 13:02: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 1viXqX-0008U3-T3; Wed, 21 Jan 2026 13:02:05 +0000 Received: by outflank-mailman (input) for mailman id 1209706; Wed, 21 Jan 2026 13:02: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 1viXqW-0008Ts-Mh for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 13:02:04 +0000 Received: from mail187-33.suw11.mandrillapp.com (mail187-33.suw11.mandrillapp.com [198.2.187.33]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5ff6c2f2-f6c9-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 14:02:01 +0100 (CET) Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail187-33.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4dx48m0tfjzBsTrcD for ; Wed, 21 Jan 2026 13:02:00 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id bafad410bad14741bff91d9a6e359c7a; Wed, 21 Jan 2026 13:02: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: 5ff6c2f2-f6c9-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1769000520; x=1769270520; bh=Ok32w0YNU9W7wLHmbAtvd49p84lfkCbb0Aa/amd7EiE=; 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=G5nH1EGkX1OSyJgQOTSA9nI+nlHZ1R1OabBGLCu6fshata8UotkVV/WcaCHOb4cuW czC18begRrdda+M9el/Hk+B30B+B6HqeFE5MwlVIOUpTvcJGd3fvTN7pwTIiZcOhsB zq1ExVBdz3ZFN0mV1M8eyqibL72DVfo1oCNs7Xf57ruLoZx62+kCwoO3SqqKWyYaw5 0aWTrp5Awsmw2p9eh5F0RMTvqc5W1qHl3BAbNDRnFTp7l3ZBhif4bZz+yOVBBPSB/a VAfneKqPbo16iwmIbmO/KutBtfeLxAHkwtaDkHFHSeFGKcd8cV4BpRTr/k1kU/jtq5 9Uw5YMGwAQ4QQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1769000520; x=1769261020; i=ngoc-tu.dinh@vates.tech; bh=Ok32w0YNU9W7wLHmbAtvd49p84lfkCbb0Aa/amd7EiE=; 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=NmgopeAmWeRidxJr0TJbChOUrrIqg3CTjebDKN954nCqm955Qh0jZeFpivV+Y39C7 3omZm/0aFcmQxz5Q/V3lcSThQQoV5WwvpU9nQMPmX6EAgpUC4RurtS7QGLJwraEemb pnhnOgcmH0C6usGPcPaVPYC5cNmwtHbkbCTMrXFg68YokCitxdpB2ArUGaYqwJVmzg KyM97Bw/WWBaolkrXmXrcSpJ1DCpRY8eN5ZRgsF0YX6YW+N71cSnR/GA7WFt096yBY X+3o/q63bT8ZC+wAFvLNIAiAB5YB+hDQmgWppoiYnhtvXAG0k6Tj9WsCW5xH+H7Bcs 2HuIw3wft0NJw== From: "Tu Dinh" Subject: =?utf-8?Q?Re:=20[PATCH=20v2]=20xen:=20Expose=20time=5Foffset=20in=20struct=20arch=5Fshared=5Finfo?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1769000518308 Message-Id: <3bde98b0-5563-4e17-bcc5-c622863d3b07@vates.tech> To: "Jan Beulich" Cc: "Anthony PERARD" , "Andrew Cooper" , "Michal Orzel" , "Julien Grall" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" , "Bertrand Marquis" , "Volodymyr Babchuk" , xen-devel@lists.xenproject.org References: <20260120095657.237-1-ngoc-tu.dinh@vates.tech> <3213454a-38cd-4e5d-8a30-853e37f70c18@suse.com> <7a61a16c-93d7-4cc2-bc47-11e236cf83fb@suse.com> <9df8cf47-d3ec-474e-b1c8-7978e55627d6@vates.tech> <637ad4a0-bc8f-4e75-8906-643f28f94a2b@suse.com> In-Reply-To: <637ad4a0-bc8f-4e75-8906-643f28f94a2b@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.bafad410bad14741bff91d9a6e359c7a?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260121:md Date: Wed, 21 Jan 2026 13:02:00 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hello, On 21/01/2026 10:17, Jan Beulich wrote: > On 20.01.2026 17:06, Tu Dinh wrote: >> On 20/01/2026 16:39, Jan Beulich wrote: >>> On 20.01.2026 16:27, Tu Dinh wrote: >>>> On 20/01/2026 13:42, Jan Beulich wrote: >>>>> On 20.01.2026 13:12, Tu Dinh wrote: >>>>>> On 20/01/2026 11:35, Jan Beulich wrote: >>>>>>> On 20.01.2026 10:57, Tu Dinh wrote: >>>>>>>> time_offset is currently always added to wc_sec. This means that without >>>>>>>> the actual value of time_offset, guests have no way of knowing what's >>>>>>>> the actual host clock. Once the guest clock drifts beyond 1 second, >>>>>>>> updates to the guest RTC would themselves change time_offset and make it >>>>>>>> impossible to resync guest time to host time. >>>>>>> >>>>>>> Despite my earlier comments this part of the description looks unchanged. >>>>>>> I still don't see why host time (or in fact about any host property) should >>>>>>> be exposed to guests. >>>>>> >>>>>> I've answered this question in a followup reply from November, which >>>>>> I'll reproduce here: >>>>> >>>>> I did read your reply, yet nothing of it appeared here as additional >>>>> justification. >>>> >>>> Is the new description OK for you? >>> >>> Which new description? So far I only saw your responses to my questions, not >>> an updated patch description. >>> >> >> Maybe my last email wasn't clear, it was in the part marked "Follow up", >> reproduced below: >> >> Xen currently does not expose the host's wall clock time in shared_info. >> This means while shared_info can be used as an alternative to the >> emulated RTC, it can't be used to keep the virtual wall clock in sync. >> Expose the time_offset value in struct shared_info in order to allow >> guests to synchronize their own wall clock to that of the host. >> >> This is needed because on Windows guests, the PV drivers don't control >> the timing of RTC updates, as this is done by the kernel itself >> periodically. If the guest's internal clock deviates from the RTC (e.g. >> after resuming from suspend), a RTC write would cause time_offset to >> deviate from the supposed value (timezone offset) and thus cause the RTC >> to become incorrect. > > What I still can't extract from this is why Windows running bare-metal is > fine but Windows running on Xen's vRTC isn't. If there's a problem with > our vRTC, shouldn't that be addressed there? > In this case, it's not because the vRTC emulation was wrong, but rather because Windows's internal wallclock is not Xen-aware and needs to be synchronized after some Xen-specific events. So it's more of an accommodation for Windows guests. Also, Windows timekeeping integrates closely with its internal time service, which assumes a NTP-like interface (and thus an external time reference). The current way of time synchronization in the Windows PV drivers doesn't work well in this model, which is why I'm looking for a way to get the external time reference from Xen. > Also, just ftaod: If other maintainers find this convincing, my failure to > understand shouldn't get in the way. They may still approve this change, > i.e. I'm not vetoing it. It's just that as of now I also wouldn't ack it. > > Jan > -- Ngoc Tu Dinh | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Wed Jan 21 13:06:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 13:06:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209719.1521640 (Exim 4.92) (envelope-from ) id 1viXuv-0000d0-GX; Wed, 21 Jan 2026 13:06:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209719.1521640; Wed, 21 Jan 2026 13:06:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viXuv-0000ct-Db; Wed, 21 Jan 2026 13:06:37 +0000 Received: by outflank-mailman (input) for mailman id 1209719; Wed, 21 Jan 2026 13:06: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 1viXuu-0000cn-Kp for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 13:06:36 +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 012f1942-f6ca-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 14:06:31 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-47edd6111b4so62638845e9.1 for ; Wed, 21 Jan 2026 05:06:31 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4801e8caceesm308018595e9.13.2026.01.21.05.06.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jan 2026 05:06:30 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 012f1942-f6ca-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769000791; x=1769605591; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=uwKgYVO7Zu6VftyCo1VUWHNj5/MR7CPIRmVZ475YIwY=; b=LlUae3S3PTjBqFM2B6ggVv0FncOwlamWXkIg0sKfBb6OmATLHy6/ruj7dDL+TvZ2R2 DqT5R4bKuCWZ5uWwACFlz6+KLM1Ip23M6KtxrpgGpZVC1WUCJdbaDOEmbEi520xdhfqS J5sECN3HXVu12x/N+gCBmX9msjAnicKVU7rWvoyZhWqO8x6wp730/9CS6ODp4pQ4iSXy fXM2OzKwpfEHd1SSkf+kO9o3jF5AMvVyENHzgLM5o8kOzSvVjklSVBEEm0X/jYlLU/db Slt4SIzGLL5EXzEhBYFguar5m1GpNJ2ou8+wn1v9OfjGv5jG80EbyT1cSFTkTxY6HcBA SILQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769000791; x=1769605591; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uwKgYVO7Zu6VftyCo1VUWHNj5/MR7CPIRmVZ475YIwY=; b=QuRGGrAGsjk3+pF0LKbVG9NY7Q6YkADTV+R30k6V8JArlfZLSUP4UXyYzThzHWQ4Id kQbfAUjgkTFFkORYyTvLncd1nDRbZ0014KGqNsVKtoFqHfOcDfWSjDa4whjGZRKsDv5N GZ30B/pma5EFOHeY2PW+f/5vQvdSEm8BswSEiWlJKYKT7lV6YpzXMyeaSZ7iBY7OdcV2 DbOR6BVhmR89WQKcFO88CeeI/bkQf6sBufMMea+u8d8CJQlIHac5sioTjrJHk8LiuLw9 DTPV+Qr7sAy2Z/BFy598YYqpBF/7qRPSfILLDAqi3u6mSsvLISzm0cMCL5yp7HLBVKwr XjdQ== X-Forwarded-Encrypted: i=1; AJvYcCUtO+Eq6CRYZliATpU3BCwY7LUDnOFiykpaVTINndBMAQY+aOjrF3reuzyN45w8r1ZLZPX0M1I7Abw=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzl/Ezj/v6lMQqJOVpJHwKIOBRPTpYoHl9kkkbdMeh2/1zpkaf+ wLnMh8gRYKVLgBpxJBqkWdpknF3DyIdu51OFiYzaB0tefnIqSVSeGKKVV3RuYzseyA== X-Gm-Gg: AZuq6aIrjfpNxP46shOkpFeLxDoUHGiuGpPOOPopfXsmZSGCFg3eJ8goyeuZamwTqPb mBZxXhaNuEbV6wgPgPKTM/KlB4kpC2n5aHq2/bhJ5cfutAIj4xs4vPObzzvtGqtyuKhm7+N8kt5 /6jvYyVyhK01vKfMLlDZBTIpvSqxd1pqVGviSot5DvAvXfRSOwGUSfcs5fMqpyIynv+7cFb08is FHLhGHUNqiQrdK/2+Atd0h+1XBzzwiVyCw6jr9GMMn8F6X5azbLV5gVbmn8cq9NTvH49r5AkOnc lT8eGUt+kgWVSi64nzO47icVU4UkfezNlOuqjllyNX6sXQPlzRdPMJ1Fzu7z9OjbvpGZNw9XfqM 4wQbN/s4Uka+KoFGFqhI7GugzW1uGe7YLoCMfv7G792fOSKNOf4ep28nJaKw7RjrMlBZPtAvr+T AMZ0VLnyHNLwF4n5im3RkqvmUE/eMsjK/1w5XIFQV2MFTpUhu8aCy2Q62bA7cSvA3RgizQJRZHK wY= X-Received: by 2002:a05:600c:458c:b0:47d:6856:9bd9 with SMTP id 5b1f17b1804b1-4801e3342bamr187365965e9.23.1769000790611; Wed, 21 Jan 2026 05:06:30 -0800 (PST) Message-ID: <169c3509-b2fe-4a5f-8184-0aa9c089ccce@suse.com> Date: Wed, 21 Jan 2026 14:06:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen: Expose time_offset in struct arch_shared_info To: Tu Dinh Cc: Anthony PERARD , Andrew Cooper , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk , xen-devel@lists.xenproject.org References: <20260120095657.237-1-ngoc-tu.dinh@vates.tech> <3213454a-38cd-4e5d-8a30-853e37f70c18@suse.com> <7a61a16c-93d7-4cc2-bc47-11e236cf83fb@suse.com> <9df8cf47-d3ec-474e-b1c8-7978e55627d6@vates.tech> <637ad4a0-bc8f-4e75-8906-643f28f94a2b@suse.com> <3bde98b0-5563-4e17-bcc5-c622863d3b07@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: <3bde98b0-5563-4e17-bcc5-c622863d3b07@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 21.01.2026 14:02, Tu Dinh wrote: > Hello, > > On 21/01/2026 10:17, Jan Beulich wrote: >> On 20.01.2026 17:06, Tu Dinh wrote: >>> On 20/01/2026 16:39, Jan Beulich wrote: >>>> On 20.01.2026 16:27, Tu Dinh wrote: >>>>> On 20/01/2026 13:42, Jan Beulich wrote: >>>>>> On 20.01.2026 13:12, Tu Dinh wrote: >>>>>>> On 20/01/2026 11:35, Jan Beulich wrote: >>>>>>>> On 20.01.2026 10:57, Tu Dinh wrote: >>>>>>>>> time_offset is currently always added to wc_sec. This means that without >>>>>>>>> the actual value of time_offset, guests have no way of knowing what's >>>>>>>>> the actual host clock. Once the guest clock drifts beyond 1 second, >>>>>>>>> updates to the guest RTC would themselves change time_offset and make it >>>>>>>>> impossible to resync guest time to host time. >>>>>>>> >>>>>>>> Despite my earlier comments this part of the description looks unchanged. >>>>>>>> I still don't see why host time (or in fact about any host property) should >>>>>>>> be exposed to guests. >>>>>>> >>>>>>> I've answered this question in a followup reply from November, which >>>>>>> I'll reproduce here: >>>>>> >>>>>> I did read your reply, yet nothing of it appeared here as additional >>>>>> justification. >>>>> >>>>> Is the new description OK for you? >>>> >>>> Which new description? So far I only saw your responses to my questions, not >>>> an updated patch description. >>>> >>> >>> Maybe my last email wasn't clear, it was in the part marked "Follow up", >>> reproduced below: >>> >>> Xen currently does not expose the host's wall clock time in shared_info. >>> This means while shared_info can be used as an alternative to the >>> emulated RTC, it can't be used to keep the virtual wall clock in sync. >>> Expose the time_offset value in struct shared_info in order to allow >>> guests to synchronize their own wall clock to that of the host. >>> >>> This is needed because on Windows guests, the PV drivers don't control >>> the timing of RTC updates, as this is done by the kernel itself >>> periodically. If the guest's internal clock deviates from the RTC (e.g. >>> after resuming from suspend), a RTC write would cause time_offset to >>> deviate from the supposed value (timezone offset) and thus cause the RTC >>> to become incorrect. >> >> What I still can't extract from this is why Windows running bare-metal is >> fine but Windows running on Xen's vRTC isn't. If there's a problem with >> our vRTC, shouldn't that be addressed there? >> > > In this case, it's not because the vRTC emulation was wrong, but rather > because Windows's internal wallclock is not Xen-aware And it shouldn't need to be. > and needs to be > synchronized after some Xen-specific events. So it's more of an > accommodation for Windows guests. > > Also, Windows timekeeping integrates closely with its internal time > service, which assumes a NTP-like interface (and thus an external time > reference). The current way of time synchronization in the Windows PV > drivers doesn't work well in this model, which is why I'm looking for a > way to get the external time reference from Xen. Are you suggesting then that plain Windows is fine, but Windows with the PV drivers isn't? That would look to be an issue with the PV drivers then, wouldn't it? Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 21 13:07:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 13:07:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209731.1521650 (Exim 4.92) (envelope-from ) id 1viXwA-0001Go-Qj; Wed, 21 Jan 2026 13:07:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209731.1521650; Wed, 21 Jan 2026 13:07:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viXwA-0001Gh-Nd; Wed, 21 Jan 2026 13:07:54 +0000 Received: by outflank-mailman (input) for mailman id 1209731; Wed, 21 Jan 2026 13:07: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 1viXw9-0001Gb-Go for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 13:07:53 +0000 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [2a00:1450:4864:20::32c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 308802a1-f6ca-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 14:07:50 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-47ee974e230so52086725e9.2 for ; Wed, 21 Jan 2026 05:07:51 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47f4289b83csm364497775e9.3.2026.01.21.05.07.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jan 2026 05:07:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 308802a1-f6ca-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769000871; x=1769605671; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=RC3aKYFO0y6kmE9cbciU8IYBTDsNgRQzMZKRAHRzV84=; b=JAIPNLvFumVQQa5oi0o756JeeYdhu5vCCUUPqcUtzxtt0LEolxpThVPRdOoWYytK9I IpxGkYBfeW3M0iiHhKIF8A3++hlHBbelXL9p8CxIcp345dl5o7jnZ2TsXmaGFfhK6tfz PWdlEeXnWKA6P3JhqOH/tqIAVr52lV3whuXhdLWksm0C/gQlJnQoILISOBw/MJyLHRhM 99+N62bTiXtQJNJjUCnVNgQeitIeA8t+RU+sOIHa0XZEq7yssUZdDi/OfN/0Q4nnAf54 jwG81+UsL8YFwUUf8Nf6xBrZici2hpJBlEEmIs06gRj5amIqnUn+QHUVzsnzgASmvBS/ Sf0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769000871; x=1769605671; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=RC3aKYFO0y6kmE9cbciU8IYBTDsNgRQzMZKRAHRzV84=; b=hvVZZgRPAxyfRn7pnrRomIC/daIXpqnLnk37rmzaxDOPw2BHWkAuDCnegobek3fJxy LWBYMyVClD16BWgyM5xeb818EgDKBT9DRDmjtCk0Pgs7H+34sMfcP2ZtRQJk2Ws5YT2+ V1+r7UYCIvIdTZEdRuSJWrXjWqZK7ACzl1bDftcUQy2Oq62f5WN0su4sHFpJA+2vCCmP zlP0A2wN7xC8Sm+mtE76aBOHPCBL+sWpiTSdV/3r+rndeVNfKjirUqyvY58u3bi0LNck gqM63a/KWGp+zJhIqIKLyZ5c1hH6gOPWGeJgx1jqOkGc1wmLBjsC8HZJJeJQ6kZu7ryP CnZQ== X-Forwarded-Encrypted: i=1; AJvYcCWF+sYNz2jTkPbmIrX2lsVi4TB5Z3znodbyngtzDkMtqPFIxJ1W1Y1xRe5srORKIkj/V6btY99US7E=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy7cd1tO4j7Eej8mvSv9ARfIrHuL1UUkXGRCm7aR3iIxHIWguYh fyUoDaFsAi+r51hVRpig1+Mze3nat9tIGVbqxSY/qwNnOAEd/ReGK+gzRQSLsOwkKw== X-Gm-Gg: AZuq6aKLdAerEg4MINzOuzu3c2cQ2M5LN4ORWCZP2zMGhf9Ljk16pnkMZmSnWQCxhRS WkL3uzZDyD34BdDmiTdrgx0RwKo4KBq3HtzKeU0ZvMruMBYhlY8p2aZkJEjhNcc21uFElifmHHa 7KMRKU2ZXKHF/u8UPl7iad/B0ikA4LC41NYpUcSym4ppE+En/n4th6r/SQK1lv2FpDVII6L2FAZ 2pzpNDtmMmKIzUGlxU1D6FQpIRGcB2/LYyZjh+z9RfM+R1uKI4npfyG7OwWeXQ8zkY/SQvBIsnk vN4RNUYw8/bmh57W1QaxkccVohho3GGyzDwyKuqVpcaZdnB12u4QMEQeB2FRfak5EUWhKrO3Ry8 fF495lIU/gFfJRS3kcGNfYmwurfZmEWESykBew8EZhhVqYIaJg8DH4pdPloDYOaZ49CSSLie68g oYF+OU12E0ko1Xhm27XNRtq1erJOhcvOZFS1pzOOvQWBZmgRgvKVY/nVrNVTmKLAfswiGxLA3c7 FM= X-Received: by 2002:a05:600c:4fcb:b0:47a:7fd0:9eea with SMTP id 5b1f17b1804b1-4803e79b85fmr77553605e9.3.1769000870547; Wed, 21 Jan 2026 05:07:50 -0800 (PST) Message-ID: <8d627df5-5de5-49bd-ad15-abe2bad486f7@suse.com> Date: Wed, 21 Jan 2026 14:07:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] x86/svm: Add infrastructure for Bus Lock Threshold To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Stefano Stabellini , xen-devel@lists.xenproject.org, Teddy Astie References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> <20260120095353.2778-2-alejandro.garciavallejo@amd.com> <9097240c-a892-41e8-a686-b89d84d0c03f@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 21.01.2026 13:40, Alejandro Vallejo wrote: > On Tue Jan 20, 2026 at 2:30 PM CET, Jan Beulich wrote: >> On 20.01.2026 14:19, Teddy Astie wrote: >>> Le 20/01/2026 à 10:56, Alejandro Vallejo a écrit : >>>> --- a/xen/arch/x86/hvm/svm/vmcb.h >>>> +++ b/xen/arch/x86/hvm/svm/vmcb.h >>>> @@ -65,6 +65,11 @@ enum GenericIntercept2bits >>>> GENERAL2_INTERCEPT_RDPRU = 1 << 14, >>>> }; >>>> >>>> +/* general 2 intercepts */ >>> >>> nit, you want to says general 3 intercepts >> >> And then, further nit, also get comment style right. > > What do you mean by comment style? it's a /* ... */ oneliner that matches > what the other general intercepts say. What am I missing? Quote from ./CODING_STYLE: "Multi-word comments should begin with a capital letter." Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 21 13:15:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 13:15:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209749.1521660 (Exim 4.92) (envelope-from ) id 1viY35-0002vK-LE; Wed, 21 Jan 2026 13:15:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209749.1521660; Wed, 21 Jan 2026 13:15:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viY35-0002vC-He; Wed, 21 Jan 2026 13:15:03 +0000 Received: by outflank-mailman (input) for mailman id 1209749; Wed, 21 Jan 2026 13:15: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 1viY34-0002v5-5o for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 13:15:02 +0000 Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2ec5a011-f6cb-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 14:14:58 +0100 (CET) Received: by mx.zohomail.com with SMTPS id 1769001292609701.0291516613988; Wed, 21 Jan 2026 05:14:52 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2ec5a011-f6cb-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; t=1769001295; cv=none; d=zohomail.com; s=zohoarc; b=M2yZL+1bpzKrs0V2Fz/Y16XnbdlmdquZ4u5jQF3ieN4G3gguEzobiZrG+OOi4es8K3UYPz4QsJZi7WO77B0U5MYAXjeIrhuQ/FxEqslqxlIAuql04UfxmWASCnhBtQGFyc7e4FMkumO5V4uMqDDizzMGlC63xBCn0hNrVFdL6mU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1769001295; 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=uns7QSNwfZ2z5ZOIiY2IgtVjluIMmOQ+/lgCVL/SR2s=; b=PHiKR95QYygf4n9MGF4LTShg5fT2SY31QGxkEpfJITFDtJswzjGRxDZVKG0cSVoSEaLIUOPWEJjgiGDeTpocArdV/dqL34RLXSwaut3OIPncsXAPyanY+lPc4DMRSpi64S/10NkMutrHd48/qd42SZev42/DheZnCrl/wNMF0JU= 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=1769001295; s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com; h=Date:Date:From:From:To:To:CC:Subject:Subject:In-Reply-To:References:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc; bh=uns7QSNwfZ2z5ZOIiY2IgtVjluIMmOQ+/lgCVL/SR2s=; b=f7feDF8b0178TjdrJ9Muxy8OhkGxf+vCon8SaHPSEGh8iVuQH42mFa0E5m1gDSRz 6kizpSHtxUt/5k/6guj5xVsBOdIAZC4NGEt2N4mMX8si4pnPkH3K6hVIy10NDrq5bi0 Ly6oJIqzMWxohkDMZfrnyIsHgRLNC8wbjTez/kKU= Date: Wed, 21 Jan 2026 07:14:50 -0600 From: "Daniel P. Smith" To: Jan Beulich CC: "xen-devel@lists.xenproject.org" Subject: Re: Ping: [PATCH] flask: fix gcov build with gcc14+ User-Agent: Thunderbird for Android In-Reply-To: <0e188989-9190-4f3b-9c45-f4e3d460daca@suse.com> References: <875df90d-1d3a-416b-a958-3d3a31144f85@suse.com> <0e188989-9190-4f3b-9c45-f4e3d460daca@suse.com> Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=----MLLG3S4YYFTXRL55FX0UXOCNVBH9PH Content-Transfer-Encoding: 7bit X-ZohoMailClient: External ------MLLG3S4YYFTXRL55FX0UXOCNVBH9PH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jan,=20 Apologies, I've been on travel for the last two weeks and I wasn't comfort= able acking this with just a read of the diff=2E The thing that bothers me = that I want to understand better is why only after the else does it worry a= bout null terminated=2E Additionally, stepping back, a casual reader of the= code is going to wonder why only after some reads into the buffer does it = need a null while others do not=2E I think most people would find that as a= red flag that an underlying issue is getting papers papered over=2E I will= be back from travel this weekend and I will sit down and review with more = context=2E=20 V/r, DPS=20 On January 19, 2026 8:50:02 AM CST, Jan Beulich wrot= e: >Daniel, > >On 08=2E01=2E2026 10:18, Jan Beulich wrote: >> Gcc's "threading" of conditionals can lead to undue warnings, as report= ed >> in e=2Eg=2E https://gcc=2Egnu=2Eorg/bugzilla/show_bug=2Ecgi?id=3D116519= (no matter >> that the overall situation is different there)=2E While my gcc15 compla= ins >> ("buf[2] may be used uninitialized in this function") about only two of >> the three instances (not about the one in type_read()), adjust all thre= e >> to be on the safe side=2E >>=20 >> Signed-off-by: Jan Beulich > >any chance of an ack (or otherwise)? > >Thanks, Jan > >> --- >> While auditing uses of next_entry(), I noticed POLICYDB_VERSION_ROLETRA= NS >> dependent ones in policydb_read(): How come the 4th slot isn't used at = all >> there (not even checked for being e=2Eg=2E zero, i=2Ee=2E holding no us= eful data)? >> Then again other instances can be found where data is read but outright >> ignored=2E >>=20 >> --- a/xen/xsm/flask/ss/policydb=2Ec >> +++ b/xen/xsm/flask/ss/policydb=2Ec >> @@ -1271,7 +1271,10 @@ static int cf_check role_read(struct pol >> if ( ver >=3D POLICYDB_VERSION_BOUNDARY ) >> rc =3D next_entry(buf, fp, sizeof(buf[0]) * 3); >> else >> + { >> rc =3D next_entry(buf, fp, sizeof(buf[0]) * 2); >> + buf[2] =3D cpu_to_le32(0); /* gcc14 onwards */ >> + } >> =20 >> if ( rc < 0 ) >> goto bad; >> @@ -1342,7 +1345,10 @@ static int cf_check type_read(struct pol >> if ( ver >=3D POLICYDB_VERSION_BOUNDARY ) >> rc =3D next_entry(buf, fp, sizeof(buf[0]) * 4); >> else >> + { >> rc =3D next_entry(buf, fp, sizeof(buf[0]) * 3); >> + buf[3] =3D cpu_to_le32(0); /* gcc14 onwards */ >> + } >> =20 >> if ( rc < 0 ) >> goto bad; >> @@ -1436,7 +1442,10 @@ static int cf_check user_read(struct pol >> if ( ver >=3D POLICYDB_VERSION_BOUNDARY ) >> rc =3D next_entry(buf, fp, sizeof(buf[0]) * 3); >> else >> + { >> rc =3D next_entry(buf, fp, sizeof(buf[0]) * 2); >> + buf[2] =3D cpu_to_le32(0); /* gcc14 onwards */ >> + } >> =20 >> if ( rc < 0 ) >> goto bad; > ------MLLG3S4YYFTXRL55FX0UXOCNVBH9PH Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Jan,

Apologies, I've bee= n on travel for the last two weeks and I wasn't comfortable acking this wit= h just a read of the diff=2E The thing that bothers me that I want to under= stand better is why only after the else does it worry about null terminated= =2E Additionally, stepping back, a casual reader of the code is going to wo= nder why only after some reads into the buffer does it need a null while ot= hers do not=2E I think most people would find that as a red flag that an un= derlying issue is getting papers papered over=2E I will be back from travel= this weekend and I will sit down and review with more context=2E

V= /r,
DPS


On Ja= nuary 19, 2026 8:50:02 AM CST, Jan Beulich <jbeulich@suse=2Ecom> wrot= e:
Daniel,

On 08=2E01=2E2026 1=
0:18, Jan Beulich wrote:
Gcc's "threading" of conditionals can lead to u=
ndue warnings, as reported
in e=2Eg=2E https://gcc=2Egnu=2Eorg/bugzilla/sho=
w_bug=2Ecgi?id=3D116519 (no matter
that the overall situation is dif=
ferent there)=2E While my gcc15 complains
("buf[2] may be used uninitial=
ized in this function") about only two of
the three instances (not about=
 the one in type_read()), adjust all three
to be on the safe side=2E
=

Signed-off-by: Jan Beulich <jbeulich@suse=2Ecom>

any chance of an ack (or otherwise)?

Tha=
nks, Jan

While auditing uses of next_entry(), I noticed POLICYDB_V=
ERSION_ROLETRANS
dependent ones in policydb_read(): How come the 4th slo=
t isn't used at all
there (not even checked for being e=2Eg=2E zero, i=
=2Ee=2E holding no useful data)?
Then again other instances can be found=
 where data is read but outright
ignored=2E

--- a/xen/xsm/flask/s=
s/policydb=2Ec
+++ b/xen/xsm/flask/ss/policydb=2Ec
@@ -1271,7 +1271,1=
0 @@ static int cf_check role_read(struct pol
     if ( ver >=3D POLI=
CYDB_VERSION_BOUNDARY )
         rc =3D next_entry(buf, fp, sizeof(buf[0=
]) * 3);
     else
+    {
         rc =3D next_entry(buf, fp, size=
of(buf[0]) * 2);
+        buf[2] =3D cpu_to_le32(0); /* gcc14 onwards */=

+    }
 
     if ( rc < 0 )
         goto bad;
@@ -1342,=
7 +1345,10 @@ static int cf_check type_read(struct pol
     if ( ver >=
;=3D POLICYDB_VERSION_BOUNDARY )
         rc =3D next_entry(buf, fp, siz=
eof(buf[0]) * 4);
     else
+    {
         rc =3D next_entry(buf,=
 fp, sizeof(buf[0]) * 3);
+        buf[3] =3D cpu_to_le32(0); /* gcc14 o=
nwards */
+    }
 
     if ( rc < 0 )
         goto bad;
=
@@ -1436,7 +1442,10 @@ static int cf_check user_read(struct pol
     if =
( ver >=3D POLICYDB_VERSION_BOUNDARY )
         rc =3D next_entry(buf=
, fp, sizeof(buf[0]) * 3);
     else
+    {
         rc =3D next_e=
ntry(buf, fp, sizeof(buf[0]) * 2);
+        buf[2] =3D cpu_to_le32(0); /=
* gcc14 onwards */
+    }
 
     if ( rc < 0 )
         goto=
 bad;

=
------MLLG3S4YYFTXRL55FX0UXOCNVBH9PH-- From xen-devel-bounces@lists.xenproject.org Wed Jan 21 13:25:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 13:25:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209763.1521682 (Exim 4.92) (envelope-from ) id 1viYDU-0004mE-MN; Wed, 21 Jan 2026 13:25:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209763.1521682; Wed, 21 Jan 2026 13:25:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viYDU-0004m7-Iq; Wed, 21 Jan 2026 13:25:48 +0000 Received: by outflank-mailman (input) for mailman id 1209763; Wed, 21 Jan 2026 13:25: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 1viYDS-0004m1-OZ for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 13:25:47 +0000 Received: from mail187-33.suw11.mandrillapp.com (mail187-33.suw11.mandrillapp.com [198.2.187.33]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ac5b29bc-f6cc-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 14:25:38 +0100 (CET) Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail187-33.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4dx4h02gRNzBsTwB1 for ; Wed, 21 Jan 2026 13:25:36 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id ec6f7ea80c0c48b891d46cce46e4e117; Wed, 21 Jan 2026 13:25: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: ac5b29bc-f6cc-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1769001936; x=1769271936; bh=mxXHzAiccdxttWHerv55pkGSDXmpXkI6NpSj/Q4Ei8M=; 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=ApWmXe1UpmYlF3Q60CTZdKxwK/JVZPftSbCYl5QZ3fhDxRFOZa6hnDc8JnClOf0h5 DnA7KnBJze5YGAb0GsWZXIZmyzlfJ+I4wEVxjwZZEfLmKsr/dx20wiyjbMbrCjSImR BuLTkLq69VZLg4hfKI21sbx3VrVbraqA1F3opU+zOiw48HLFUObtKkIl6gL1HiCvkh L+WPhO/DlaahwNqOEVv/FMwp+Fh3au8FTN2p/XJEfid5pcbrZZ/WK0yHGCqdUgOvUP sS6nE1TR52xbtH2Osbpr28g5CStCwARcmHtJ65WkWhbBN0qt5wV8Ce9JGHl7qb7IFc GJ36ieQW50h/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1769001936; x=1769262436; i=ngoc-tu.dinh@vates.tech; bh=mxXHzAiccdxttWHerv55pkGSDXmpXkI6NpSj/Q4Ei8M=; 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=yj77X/q6ZgWI7+5EbJZAfoGim9u3pSw3XOLTyd+7UM387u9zk2XU0+QBIr1xhL2Ap V8RbSXoBt0YOKzHXNdn5DPLjmUM1f0Zk9OZTu141TH2Xo7DV+hD7NSRULH6BfjqQbB snVKir+HSE1eRSAZIwusro567IRKV4aK/F6HQ/t62ffa0KpeH1GRU5cfWPI39rGCH7 Q+svy1akkAjVhCYLhLPBHqkM8YruYTssG+N3p+hrOESUNXBoBvGf0skBvEsg1JWRF2 OYlKSrVlECdaqhJg9TGuUXW4uihmjIw71wp4OxD7qjj2+aTHoxsxSweXnXC0hWsm5R pUyUPv6jNFRxQ== From: "Tu Dinh" Subject: =?utf-8?Q?Re:=20[PATCH=20v2]=20xen:=20Expose=20time=5Foffset=20in=20struct=20arch=5Fshared=5Finfo?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1769001934525 Message-Id: <6ed580a8-92a9-4e50-9c40-d38db3e3f94c@vates.tech> To: "Jan Beulich" Cc: "Anthony PERARD" , "Andrew Cooper" , "Michal Orzel" , "Julien Grall" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" , "Bertrand Marquis" , "Volodymyr Babchuk" , xen-devel@lists.xenproject.org References: <20260120095657.237-1-ngoc-tu.dinh@vates.tech> <3213454a-38cd-4e5d-8a30-853e37f70c18@suse.com> <7a61a16c-93d7-4cc2-bc47-11e236cf83fb@suse.com> <9df8cf47-d3ec-474e-b1c8-7978e55627d6@vates.tech> <637ad4a0-bc8f-4e75-8906-643f28f94a2b@suse.com> <3bde98b0-5563-4e17-bcc5-c622863d3b07@vates.tech> <169c3509-b2fe-4a5f-8184-0aa9c089ccce@suse.com> In-Reply-To: <169c3509-b2fe-4a5f-8184-0aa9c089ccce@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.ec6f7ea80c0c48b891d46cce46e4e117?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260121:md Date: Wed, 21 Jan 2026 13:25:36 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 21/01/2026 14:06, Jan Beulich wrote: > On 21.01.2026 14:02, Tu Dinh wrote: >> Hello, >> >> On 21/01/2026 10:17, Jan Beulich wrote: >>> On 20.01.2026 17:06, Tu Dinh wrote: >>>> On 20/01/2026 16:39, Jan Beulich wrote: >>>>> On 20.01.2026 16:27, Tu Dinh wrote: >>>>>> On 20/01/2026 13:42, Jan Beulich wrote: >>>>>>> On 20.01.2026 13:12, Tu Dinh wrote: >>>>>>>> On 20/01/2026 11:35, Jan Beulich wrote: >>>>>>>>> On 20.01.2026 10:57, Tu Dinh wrote: >>>>>>>>>> time_offset is currently always added to wc_sec. This means that without >>>>>>>>>> the actual value of time_offset, guests have no way of knowing what's >>>>>>>>>> the actual host clock. Once the guest clock drifts beyond 1 second, >>>>>>>>>> updates to the guest RTC would themselves change time_offset and make it >>>>>>>>>> impossible to resync guest time to host time. >>>>>>>>> >>>>>>>>> Despite my earlier comments this part of the description looks unchanged. >>>>>>>>> I still don't see why host time (or in fact about any host property) should >>>>>>>>> be exposed to guests. >>>>>>>> >>>>>>>> I've answered this question in a followup reply from November, which >>>>>>>> I'll reproduce here: >>>>>>> >>>>>>> I did read your reply, yet nothing of it appeared here as additional >>>>>>> justification. >>>>>> >>>>>> Is the new description OK for you? >>>>> >>>>> Which new description? So far I only saw your responses to my questions, not >>>>> an updated patch description. >>>>> >>>> >>>> Maybe my last email wasn't clear, it was in the part marked "Follow up", >>>> reproduced below: >>>> >>>> Xen currently does not expose the host's wall clock time in shared_info. >>>> This means while shared_info can be used as an alternative to the >>>> emulated RTC, it can't be used to keep the virtual wall clock in sync. >>>> Expose the time_offset value in struct shared_info in order to allow >>>> guests to synchronize their own wall clock to that of the host. >>>> >>>> This is needed because on Windows guests, the PV drivers don't control >>>> the timing of RTC updates, as this is done by the kernel itself >>>> periodically. If the guest's internal clock deviates from the RTC (e.g. >>>> after resuming from suspend), a RTC write would cause time_offset to >>>> deviate from the supposed value (timezone offset) and thus cause the RTC >>>> to become incorrect. >>> >>> What I still can't extract from this is why Windows running bare-metal is >>> fine but Windows running on Xen's vRTC isn't. If there's a problem with >>> our vRTC, shouldn't that be addressed there? >>> >> >> In this case, it's not because the vRTC emulation was wrong, but rather >> because Windows's internal wallclock is not Xen-aware > > And it shouldn't need to be. > >> and needs to be >> synchronized after some Xen-specific events. So it's more of an >> accommodation for Windows guests. >> >> Also, Windows timekeeping integrates closely with its internal time >> service, which assumes a NTP-like interface (and thus an external time >> reference). The current way of time synchronization in the Windows PV >> drivers doesn't work well in this model, which is why I'm looking for a >> way to get the external time reference from Xen. > > Are you suggesting then that plain Windows is fine, but Windows with the > PV drivers isn't? That would look to be an issue with the PV drivers then, > wouldn't it? > No, it just means that Windows running on Xen without PV drivers is not fine, and the PV drivers currently need this feature in order to correctly sync the guest time. This new functionality will be used in the Windows PV drivers if it were to be merged. > Jan -- Ngoc Tu Dinh | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Wed Jan 21 13:35:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 13:35:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209776.1521692 (Exim 4.92) (envelope-from ) id 1viYNA-0006SR-HT; Wed, 21 Jan 2026 13:35:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209776.1521692; Wed, 21 Jan 2026 13: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 1viYNA-0006SK-E5; Wed, 21 Jan 2026 13:35:48 +0000 Received: by outflank-mailman (input) for mailman id 1209776; Wed, 21 Jan 2026 13: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 1viYN8-0006SE-Tf for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 13:35:46 +0000 Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [2a00:1450:4864:20::343]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 15ce69a8-f6ce-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 14:35:44 +0100 (CET) Received: by mail-wm1-x343.google.com with SMTP id 5b1f17b1804b1-47ee76e8656so78433375e9.0 for ; Wed, 21 Jan 2026 05:35:44 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-480424b18cesm22965855e9.4.2026.01.21.05.35.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jan 2026 05:35:43 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 15ce69a8-f6ce-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769002544; x=1769607344; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=yQovsb7SCNmMa5eCw3inpi109iAlgBpcsjpnhwrrQAk=; b=bG/xsU2StOraR6lI0GsaHnEFsIrlAu9y48OK2v0G8G/poO3aUodlk+V8xa2Ho116Gs ruTfBqjjTbmpv9LtB4aAGMmZ2EaBraVqSYLcTqm/SojS7CqMQsxS3k3BTi4gwN96XViR LxiU5niCp5yJ/zoJjtVmgYvL14R/Ull81Kc/hsTwvYdDdc8aHisAzSPxkMnk7v2fYOWp Hm8s5pGmTtLU0/7t1TNfVfidD4+JXKovT82tY6ZM2gQrT6xB7bPH9kaCEg/lR8bMUy0g lO/EHEjt76g+O7/pLgws5vU74nLPFfslNznpxA4/r7yOpK/ptxSCvOM9NEf978ue4Chp SzKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769002544; x=1769607344; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yQovsb7SCNmMa5eCw3inpi109iAlgBpcsjpnhwrrQAk=; b=ND10IhlEqoH3qY+b88xtV5d1MVdUeR44ZlIrPZPVxe4vp5Zrk8r5uz2Dku1d26psgL 2RDGHTdQPoG+f4WpJWqlucFOBstQVJGe7MCba/qk3vopdwk8jS0fSuldT5x9BxFA6IKF bGGdAstaHhSRvhYB4ZVTAMiHfRWSpI+UO2i8kR1P+OZAAG3JuK83BLiKup0ebrsLLSt7 nJrYZKCFHRBjLBecSiu0MRU9M0GpafSKIsrDWNAswyzncbmvjT6G1Vx33BqDnZGssH7n dFUWs8h4zZ28XH+8JjP0D5Vgb1t2u6shNxcBvNJ7xGBNSk5T2e897hkjX4gyb6/iuYqY 7EgA== X-Gm-Message-State: AOJu0YzeaeYBFDlxPPrhgq/n++5hFi1M9SgM7kykXJoDPkQllk8v4SB1 j/u71UbRGMiEIi3U9UhiUYPHo5e8xLBwYw6OnfZJEEZ/YkF8M5oTkOxu/W0hvqZKqXDNFg3DdwZ w9bkKrQ== X-Gm-Gg: AZuq6aIv8Ykc5j+aACbAyyXEG5zUva1zyOlvODnQevpitk6NsFLbQzCMPTEIYDbyP61 sqToO10NJ7lT1aO34DRSJzAV6cEf9fe1ohdY6aq0xqy5UY9noEjJpYikqOsTXaATfo1a/O/c4aP d43O3u5Zsa0vR1TdYyAb46jtbiOoylX7+2wzM3uiMlVjed/oD1oYm6jeRQ4u5WSdC2N6amys0uC UrwUOrH3y0HmXgkWp0HinUndq1Wvr4EyvM1Enm+146PfC7SCwyQtHfV8IpREVAyhoBDlRZ5Lyyg 0r0ZCXSrWcaFz9xwKJ3tjQQpqdcWLhQ17EtnXwvsEbltHv51zgzsKgKUUGZQykvqJ+8TJzoOVHY HFkqQ7h2X8tatZW+OlT6ATfFZf1fpzhqBJKfmXn1nQoEodg/QEiMgQUlBlLpmK6yWtssYyCEYTA 8rFqmvsqUF2QR/3+lLgPamxmbCPyKmHfzIalFLwBImXLRYGb4DlwlLN62/WN0CCgfbABNFVPKKm Xw= X-Received: by 2002:a05:600c:3f0f:b0:47e:e076:c7a2 with SMTP id 5b1f17b1804b1-4803e7a2d74mr85355355e9.15.1769002543654; Wed, 21 Jan 2026 05:35:43 -0800 (PST) Message-ID: Date: Wed, 21 Jan 2026 14:35:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Ping: [PATCH] flask: fix gcov build with gcc14+ To: "Daniel P. Smith" Cc: "xen-devel@lists.xenproject.org" References: <875df90d-1d3a-416b-a958-3d3a31144f85@suse.com> <0e188989-9190-4f3b-9c45-f4e3d460daca@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 21.01.2026 14:14, Daniel P. Smith wrote: > Apologies, I've been on travel for the last two weeks and I wasn't comfortable acking this with just a read of the diff. The thing that bothers me that I want to understand better is why only after the else does it worry about null terminated. Additionally, stepping back, a casual reader of the code is going to wonder why only after some reads into the buffer does it need a null while others do not. I'm curious to know of an example or two which you refer to here, as ... > I think most people would find that as a red flag that an underlying issue is getting papers papered over. I will be back from travel this weekend and I will sit down and review with more context. > > V/r, > DPS > > On January 19, 2026 8:50:02 AM CST, Jan Beulich wrote: >> Daniel, >> >> On 08.01.2026 10:18, Jan Beulich wrote: >>> Gcc's "threading" of conditionals can lead to undue warnings, as reported >>> in e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116519 (no matter >>> that the overall situation is different there). While my gcc15 complains >>> ("buf[2] may be used uninitialized in this function") about only two of >>> the three instances (not about the one in type_read()), adjust all three >>> to be on the safe side. ... I've already extended the change to cover all three similar patterns, no matter that only two triggered a warning. Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 21 13:41:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 13:41:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209786.1521702 (Exim 4.92) (envelope-from ) id 1viYSD-00084y-5t; Wed, 21 Jan 2026 13:41:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209786.1521702; Wed, 21 Jan 2026 13: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 1viYSD-00084r-2E; Wed, 21 Jan 2026 13:41:01 +0000 Received: by outflank-mailman (input) for mailman id 1209786; Wed, 21 Jan 2026 13:41: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 1viYSC-00084l-JZ for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 13:41:00 +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 d0d1657f-f6ce-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 14:40:57 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-47ff94b46afso8553265e9.1 for ; Wed, 21 Jan 2026 05:40:58 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4356997e6cdsm38148531f8f.31.2026.01.21.05.40.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jan 2026 05:40:57 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d0d1657f-f6ce-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769002857; x=1769607657; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=FIHjcHzlX+JKkZyWGPWJkD7XCPOEBDcAXVZ3w2QFXKI=; b=C7eqYl/1z27ocDUBbB1T/hnqUTmAQvfGHHUw7abW3nD8fb/7ol7CbWo8j5Cn8CsU8A MGMTmZpEVlSQyItV2+X22xI1F6pzx/5lPgvBlFAaez7TV64L2CH6wKJWxiMMKDX0+l1g 0aiy/9rS6Wg5zqYbumCTRGPgVRVkBQ/sTqsQpYUevV6ZSOOdLawIngwKNTKpwX4zqiYR rpKYd5L+snK+H1OOQ2LNXHY0Y011OXRQegyjb2ZuZKcz3+CboFvK2/4dJwNxGsVGRelI q02+1Yivu82zfd3m5hF1HxCNecshVIKIuG7OVEhLgKAE+QSRwjnuf4nLL7HU+ozoWtdE NY8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769002857; x=1769607657; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=FIHjcHzlX+JKkZyWGPWJkD7XCPOEBDcAXVZ3w2QFXKI=; b=EcQnX/n5exuGngNxf9Qm6OMhvutKwZUm1bTZOL3dPjmlkTYx3qCUh3SBBIQuhHIstD tePZFxVwYKzqyZbq/Ah2opnwZhHkjCl5d8EUSn3aX2LUlU6if1EPFgCY835vY1McauHH FakrC03c3woXzYXN2LLZmk69G3w5zwC+feVdCqoZVYafVoF+U3cyL19imuZcCOZphQ5O 0lPn2SI5H+SfpROvo7UohKsgt+x0d7IiIgg0LSW6Oc6OZTsZjTnB7Z1Sm1YWQr26+yJN qLtlAbJ3W6XYK3i/0Q/Ks3aXzSqxv4pvU2DoxzQ8B9BqMouZZ+5FttTrkNzaQApK8iF9 gsfA== X-Forwarded-Encrypted: i=1; AJvYcCU8+0XQfw+HJrgd66PzMJvZjBzMkLy3f6pSBF2RQk9HbqiF/jjZ42nGjp56F/9ENBTrlFx4cxgC6rk=@lists.xenproject.org X-Gm-Message-State: AOJu0YwZpJRh/61t1Aq7UfxEOdDVcDskJjbRQ1iIq8LXJKgNKGyJcpm1 K5RfvLaQXZBgLK3vga/hiWH+FmlnesWvOAU6E12xlr2Kd9d7T3Q60Ic7O+vMWg+ZqQ== X-Gm-Gg: AZuq6aLAxYEOoQtcExxx1KkZajwSqxmi1QutX6dZTORG3Luzk6f9nors9oKJmoMlfHU EDfJcCskdsuqfoKBDSul6LK7ESu5zXiret+qtIliRIG72WyU2I2aHxFkJhkthCL1o4JXOd8BOtJ 1SN+n+4GKGqyX9w6ObLLLG0yF6aBlxjWPshql8vEQzmbMcxYNxvsT4iyviHHu3mqEswPlPYmHMt DY9ssZH0dgYujWXPelytEka0s53K2pe6mYdLZWRPgeGMxdTmZ1GTu9UbS4ww2aNCaRF4ZWc8iu+ hJHYwA6rxCZBY6PU2hQ6IwAq9taJSEdg7LEbOXCGEh1lRUJCCUfHYQsENhs0hsiizoLNUxuYI0x k2mFskQHLX33vFDC1SIgzAGzI2f4862bUdhHGTnW3MflgSw4dB8xMc0I9d4vtPOdlsGK2D5F/hz jwQZkzBWbKZngkjMoigUGMgF7TqsBnv87XJ9qAtvZ2YSedKi3+LxylMfM62NrvVieKkoXtOjUNj 7pNbROhs0DwAA== X-Received: by 2002:a05:600c:3e08:b0:480:1c1c:47d6 with SMTP id 5b1f17b1804b1-4801e53c069mr224552965e9.6.1769002857453; Wed, 21 Jan 2026 05:40:57 -0800 (PST) Message-ID: <2dc8f5e0-5fa3-4165-88bd-be4246989817@suse.com> Date: Wed, 21 Jan 2026 14:40:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] x86/amd: Fold another DE_CFG edit into amd_init_de_cfg() To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20251202105710.1472927-1-andrew.cooper3@citrix.com> <20251202105710.1472927-2-andrew.cooper3@citrix.com> <55f40e49-027b-4162-94f0-54573fb1abc0@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 21.01.2026 12:46, Andrew Cooper wrote: > On 08/12/2025 9:17 am, Jan Beulich wrote: >> On 02.12.2025 11:57, Andrew Cooper wrote: >>> Fam12h processors aren't SMT-capable so there are no race condition worries >>> with this path. Nevertheless, group it together with the other DE_CFG >>> modifications. >> With this, ... >> >>> Fixes: d0c75dc4c028 ("x86/amd: Fix race editing DE_CFG") >> ... isn't this more like Amends:? Aiui this wouldn't need backporting. > > This does want backporting. > > d0c75dc4c028 explains how it's buggy to have multiple pieces of logic > writing to DE_CFG, and here's yet another one. > > It's only a latent bug because Fam12 doesn't have CMT/SMT, and this > property is not discussed, meaning that the logic as-is comes across as > unsafe. Hmm, this last part again leaves me with the impression that backport isn't strictly needed. (We often don't when addressing only a latent issue.) >>> --- a/xen/arch/x86/cpu/amd.c >>> +++ b/xen/arch/x86/cpu/amd.c >>> @@ -920,6 +920,13 @@ void amd_init_de_cfg(const struct cpuinfo_x86 *c) >>> if ( zenbleed_use_chickenbit() ) >>> new |= (1 << 9); >>> >>> + /* >>> + * Erratum #665, doc 44739. Integer divide instructions may cause >>> + * unpredictable behaviour. >>> + */ >>> + if ( c->family == 0x12 ) >>> + new |= 1U << 31; >>> + >>> /* Avoid reading DE_CFG if we don't intend to change anything. */ >>> if ( !new ) >>> return; >>> @@ -1201,15 +1208,6 @@ static void cf_check init_amd(struct cpuinfo_x86 *c) >>> smp_processor_id()); >>> wrmsrl(MSR_AMD64_LS_CFG, value | (1 << 15)); >>> } >>> - } else if (c->x86 == 0x12) { >>> - rdmsrl(MSR_AMD64_DE_CFG, value); >>> - if (!(value & (1U << 31))) { >>> - if (c == &boot_cpu_data || opt_cpu_info) >>> - printk_once(XENLOG_WARNING >>> - "CPU%u: Applying workaround for erratum 665\n", >>> - smp_processor_id()); >>> - wrmsrl(MSR_AMD64_DE_CFG, value | (1U << 31)); >>> - } >>> } >> Are you deliberately getting rid of the log message? > > Yes, it's basically line noise. > > Most errata like this are not handled at all, and this is not overly > noteworthy.  If it were at debug level then maybe, but certainly not at > warning.  > > Fam12h were rare in the first place and are museum pieces these days. > >> And I assume it is deliberate that the adjustment no longer is done when we're >> running virtualized ourselves? > > Of course.  It's pointless, and a readback would show that the write had > had no effect. > >> >> Both imo want making explicit in the description. > > I've updated the commit message to: > > x86/amd: Fold another DE_CFG edit into amd_init_de_cfg() >      > As amd_init_de_cfg() states, it's only safe for there to be one location > writing to DE_CFG.  This happens to be a latent bug rather than a real one > because Fam12h CPUs aren't SMT-capable.  Nevertheless, group it together > with > the other DE_CFG modifications. >      > This removes a printk() which is not noteworthy, and skips the adjustment > entirely under virt, where the attempted write wouldn't have stuck anyway. > > Fixes: d0c75dc4c028 ("x86/amd: Fix race editing DE_CFG") > Signed-off-by: Andrew Cooper Thanks, this reads good to me: Acked-by: Jan Beulich I'd like to understand the backporting (or not) aspect, though, in order to properly know whether to pick this up once you put it in. Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 21 13:42:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 13:42:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209800.1521712 (Exim 4.92) (envelope-from ) id 1viYTN-0000CH-KD; Wed, 21 Jan 2026 13:42:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209800.1521712; Wed, 21 Jan 2026 13:42: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 1viYTN-0000CA-HV; Wed, 21 Jan 2026 13:42:13 +0000 Received: by outflank-mailman (input) for mailman id 1209800; Wed, 21 Jan 2026 13:42: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 1viYTM-0000C1-Qi for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 13:42:12 +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 fc90b268-f6ce-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 14:42:11 +0100 (CET) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-42fbc305914so5363453f8f.0 for ; Wed, 21 Jan 2026 05:42:11 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43569921facsm35233789f8f.5.2026.01.21.05.42.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jan 2026 05:42:10 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fc90b268-f6ce-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769002930; x=1769607730; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=cs5bIakwvvdAUWgATm5aIb+v+sRloirld+uTq/fbZLM=; b=A0H4LPkouQUMxDrR2z47aVg3jLDeHicZTlWHhSwhX9y2LOR1m6xz2OugGaz2vkInEP yTVjFW+1LX4NSU6E2WGOo1o/zfOIP0Rt4+KTZgUHqWOtBDn8NL/7dWD2j0yK8TJ2HlnS qPmnm49Fvav0JcalZfu6W7xYzGrGSs1tBrLJlqXqQ+9ZAd0Nz5Vj9gfrws0IyyIqMzZZ yPGQc+qSWykeDbj9WgKIlINZcb54WgHkjyrEAxB+GXhZDGgkTbV3T3gLJ+SEbenxjtDK JQHK0xCbU664crU60ydZd72RxNSc00QHUAVjEhekxK3/6I98RTWuZFOJzOdDdJwtohPw cxeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769002930; x=1769607730; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=cs5bIakwvvdAUWgATm5aIb+v+sRloirld+uTq/fbZLM=; b=SO/iyRXXuDt7tMPNtH1sJkck+Lr6rC2UNBuBJNVhnzqiQCkBU4XuuiJQSwe103Nnxk /kkNmSWH+OSRO6ui6M0jRiq5mqmgjUfAKIUHC3R2IToR1E6mIgo0H1WRmTUzLGEZYPnp 5qhPJe/YExQ4iAjmqI8cQSp7Ttaf5KOJm4pWQsbpx8AJGoUGc5+BBGjd4hoBa+yuFUez kGQEtgQSon8o5ruV2u7f4xU+izMgijZK/qW8qB/Lhr7bR0dRGTz0Txi2VR2aLrcXb9bs NQS9ZaqnzpvQ1tmEtweHibfYsPudtXzEJ/YHTnNG3h+VI6DF6iNdiXOZQZ1CEpaeierz 15Lw== X-Forwarded-Encrypted: i=1; AJvYcCU73MewJWgkeSYtGnZkxf9LNW0Rwxs9MfuhzpPC/dg27EeGtnx5Rm9Nx7ufoNDjylqbD0h7Ky4ap5Q=@lists.xenproject.org X-Gm-Message-State: AOJu0YyTf7p+fP6bcXv4poJc7GAqomlz5c0r409GACIN9yMX1owu/u9u dAimXvKkta4Ce0utoluqAI9JXWDluTnc9fGf00WCezeCqHY2EwxJa3lag6PcuTV9FA== X-Gm-Gg: AZuq6aI7M+9HePpNPsUh9kjB+p/SffByxkRwGTtTkvm1RPG0mofaoUpe4mp93NUy28h X37TtNkaHJRuXPUYRBFBsOsN8MWajFqvROxSeIek6+Q/HUMqXlBU7pBudM32DupyhD9Qd5w6G+5 S3tvnhPW1mhY67W3h3Kq/kBN/PWTs7uGnwEcWzU47hPPN6+kNfYkKeE+VpPgEtY1RO8hwyacd41 tHZYIO1NBy+BGoR4lU07zu598+e8aoI+k3mzcrg3jNZCYdqj/qcw3lceFJYXxkdN6Z+EHNkZ70r mWsCo01M4AFpzVy1kW9kayihDRfoy2xX5uK43Ye01iArKpT7pmbxvKUQp0zpbs/jxHRKRwnLKgO tte6uRgrt1+W4Dyo1UTLjRoYaavFfnWYvmy52dp1/jesZbYTUwYBiu3f3IS5LKU47WP3jrINxBV zjICwrIwU0YTklqiXRtD1HWMlZ9ER0Kmof3jZ2J3tzPnoChGqkO8IF14t3jvWrqQyHxthBCGlgO XM= X-Received: by 2002:a05:6000:208a:b0:430:fd0f:2910 with SMTP id ffacd0b85a97d-4358fed868dmr9707003f8f.26.1769002930333; Wed, 21 Jan 2026 05:42:10 -0800 (PST) Message-ID: Date: Wed, 21 Jan 2026 14:42:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/3] x86/amd: Exclude K8 RevD and earlier from levelling To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20251202105710.1472927-1-andrew.cooper3@citrix.com> <20251202105710.1472927-3-andrew.cooper3@citrix.com> <7d019929-24df-4523-9817-6c17017c2320@suse.com> <4762dc23-cf30-43b0-ae19-fceabea5d8c3@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: <4762dc23-cf30-43b0-ae19-fceabea5d8c3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 21.01.2026 12:52, Andrew Cooper wrote: > On 08/12/2025 9:25 am, Jan Beulich wrote: >> On 02.12.2025 11:57, Andrew Cooper wrote: >>> Between RevD and RevE silicon, the feature MSRs moved location. This property >>> is highlighted by the suggested workaround for Erratum #110 which gives the >>> two different MSRs for the extended feature leaf. >>> >>> The other feature MSRs are not given and while they're easy enough to figure >>> out I don't have any K8's to test the result with. >> I can see where you're coming from, but shouldn't we then first document those >> extremely old models as unsupported in SUPPORT.md? > > Not especially, no. > > There are Intel CPUs with no levelling capabilities at all, that have no > (non)support statement.  The levelling on most AMD CPUs is incomplete too. Hmm, true. Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 21 14:30:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 14:30:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209826.1521732 (Exim 4.92) (envelope-from ) id 1viZDu-000796-7m; Wed, 21 Jan 2026 14:30:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209826.1521732; Wed, 21 Jan 2026 14: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 1viZDu-00078z-4I; Wed, 21 Jan 2026 14:30:18 +0000 Received: by outflank-mailman (input) for mailman id 1209826; Wed, 21 Jan 2026 14:30:16 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viZDs-0006vP-6g for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 14:30:16 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b1a13f4b-f6d5-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 15:30:12 +0100 (CET) Received: from MN2PR07CA0022.namprd07.prod.outlook.com (2603:10b6:208:1a0::32) by SA1PR12MB8142.namprd12.prod.outlook.com (2603:10b6:806:334::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 14:30:05 +0000 Received: from BL6PEPF0001AB78.namprd02.prod.outlook.com (2603:10b6:208:1a0:cafe::35) by MN2PR07CA0022.outlook.office365.com (2603:10b6:208:1a0::32) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.10 via Frontend Transport; Wed, 21 Jan 2026 14:29:59 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF0001AB78.mail.protection.outlook.com (10.167.242.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Wed, 21 Jan 2026 14:30:04 +0000 Received: from xcbagarciav01.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 21 Jan 2026 08:29:57 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b1a13f4b-f6d5-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=hqadDK1Qv0i2agxIOQ5NbOvyBjAM0pujouGtyzxwBHfOxiRILh8SroAiV5vN8H6jHkJ4dGaBubsLVXeuno8cx4HqqvxGZTqla637jxzUjiYkutXpiLrUlFQ07XqZKDGFInddjeoYbDMI34H6DnEJgaY+eF4AUMhGOF9CL7E2qC7X1iAm7e0ELxORgkee17EhRKSPKksqgUOWa7z+ydjI/Ff7YBrpg564SItrNwSJA+5PmUeVsvc+k7dVV92NW7TiUWm9WgyEwbZWA5WBb9SKeeSkOka1zvEH9CdxUrQbm/jBRTdUOecP97RhUs/XCVLvxrClQvRmdneoZk1pp4wCgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tSKGe52NO3EUM355UnfiNliL5Anqp2e0DuhAflIiAW8=; b=aUf6iVIatbqoh+H0ulQ/jPX4Ov+a+sJhXDMlDAFkLOIhJVDOyR8Rgh9Wvyrq8hKprknYKY1v+rDqwVXpOsj/knE6D8W4BF8mw8PQ0/sbL/O8/b4v6VzUuXzzknk7RkGi7JhTpT9TSsEk/0T6walLE/Lq2+B37ppGfnfyFmyLmOXitcPxW7+5Qdza2u1Sm0hsy/t4N1mNcEKfc0tQkY/y6kXW8RQY9zH0l2DLAqNMa15vKSkCg3GWlGd1M+2vcyE6B0So0m4Y82aQBK/PuYoc373TrOzSeZ7TgkMP+/mw2uFivum+j6mwOWMFhVhgn35aIsK7vgI0WvKfyJaGvJdimw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tSKGe52NO3EUM355UnfiNliL5Anqp2e0DuhAflIiAW8=; b=QwX3QIvGObIckLnyr9LOrG57tJCAismjObm+E+SVUi7kUEnTiYxLgx/d9snxpNPqgnh7I7Ksg5jI2sxUpJuWNfMNfKVkiCU+3tLAulG26KHIHkxj+lRGc5Sz7L7skkLuy66RsDbwTyI6n/00SOfFDWe2KdQRGEBB9Xptb17I+XU= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: [PATCH v2 1/3] x86/svm: Add infrastructure for Bus Lock Threshold Date: Wed, 21 Jan 2026 15:28:53 +0100 Message-ID: <20260121142857.39069-2-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260121142857.39069-1-alejandro.garciavallejo@amd.com> References: <20260121142857.39069-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: BL6PEPF0001AB78:EE_|SA1PR12MB8142:EE_ X-MS-Office365-Filtering-Correlation-Id: 90b5902e-1054-479b-2f9b-08de58f991ba 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?qBggbYLY9aFGdpPhZXTem2aQVRZxZ3V6sW2PNRAJJc6ZN8r2HudpMDg+TuVL?= =?us-ascii?Q?UxoMLrVF0sjR3E7O/OVocH5MdMSUAw60AazDiUtHrVenbc3R56rWBoRi0h7/?= =?us-ascii?Q?g1pIWKXVwg6i+wlahToLpkcJ+2ZGzBsa0isvWJ2ovDTJtwEcJNNfxLLN/W3n?= =?us-ascii?Q?36LuU/8+C53Yxqxw9s71NocBy4u7+EGPJ1ZVsieNwovW0Ej3HLyRbJUbx/dh?= =?us-ascii?Q?wDWiYgN/mfeYa/Aa9/OwX5V31ld+Yp8Fzzrf7q7YCcjmiD3ze75YilKsbz3O?= =?us-ascii?Q?+OHNIgKIZZWs3D83A6YwB/4LGa7Crps49UlvpH0Wzdr9sVoYnmIzWR22S7O1?= =?us-ascii?Q?M7EK/twE7g58w0IkN7K97Ky1jdUvalPV2of2pSZ7c7xp83pTPuHDeJuuLwC+?= =?us-ascii?Q?KQ/Qk6UK34+nvv018cRFf9I0SSE/TM4zURSbNN1aBjCqMY8PXfPsWVkW+WgX?= =?us-ascii?Q?83NgmsRfFEZbWYSOtjy9dumqXYxEGuQ1H+gs70wkCpf3i/AviqSfzGer4yB8?= =?us-ascii?Q?iz2w0ea2yjfdMYcVwEmJnnPJz7+OUjjSMSUbI9EfhdjT6SXfkng0+YbxFuRM?= =?us-ascii?Q?2Iyvh/PQNBjpv5aUfQuKI7XWkb7MTL7MA/VEss4X/7C1MMfOdkt2qI63Dszp?= =?us-ascii?Q?G2qmWSWkIuuvEid42RpDryINC5Cwhrsl7079RnHVNRPBB/Nbj4BayVXCQ/06?= =?us-ascii?Q?JwgKrwQuzO14wrB6dCfzrpRSFAnqyiysBzr1aECSTjP8IFQLq4mnyhPLjlj/?= =?us-ascii?Q?D1ag2BNe/1W697bpcKzDmfrzpS7MWWHu8IaKfmS9D8ho2sMvKu4nGyv7e7aF?= =?us-ascii?Q?Lep+0nV5uyXXXEdIdFWuZXHqH4peZlrjobmwO1jtCkGh+OIb+1I3MEGbAdiM?= =?us-ascii?Q?yNO0xGw1FTc/cm0nuv6jPmIc1s96VfBCHJA0FNwpiqo37dUsHw/WK7RyKpX9?= =?us-ascii?Q?Ax3pAgB3UmFfTS97A0aVeKPn6YemTohyxOCnxNRhA1ia9VB7OcMlyhM5Rwav?= =?us-ascii?Q?0C1IG1ahWiktzwiM18A6HhhxnkHJMMAuJGkALwlEmwncvane05vEnPsJ0RIO?= =?us-ascii?Q?yRL00Xm1voGJkX2W10gZplwuGzJFLNcEiIRPN16SxNM/bSFeP9YYSdLmLRsp?= =?us-ascii?Q?q0Nbm0zQgnstJ+aZTlW2/4BLNznFDLk0EpaQp7D5J2yt8xiUriwnOKF5uhLQ?= =?us-ascii?Q?YciqDjpbsPCKKF13tSyvC71JiyR96GeGfrT2CZNjCI2s3bkGYHcRlXZ7afb3?= =?us-ascii?Q?i+cYwXEFJn16TC/MhfTDJtv9D+fF3j0weJ3TuV8ToqifvdUbD7uZn+z0EPBl?= =?us-ascii?Q?0hGwSKBnePFtxSL32Hpe0zg1XTkbw9kknhUXYRX3T23oqWSpIJ8qAWeiBWVz?= =?us-ascii?Q?JTBHPv4DL1hJsmVaG0PhHKd6CDm7gaPUQlbenOZiBE2XEAusiETGumumWL4U?= =?us-ascii?Q?rT7WskF+n0krZ9pHdohREmo38xKkCo16uwlY7B6Mj3b+Z4MVdICaE0FnJzw8?= =?us-ascii?Q?9VpJP/yRX5e27P2M8faIg5SgglFUlQZhAkbFxIQ9IYiP8hrPm1sQ8EHYD+gn?= =?us-ascii?Q?M+BiVsoou38GvnhHEoKZa01YPuisXvf4VZvyeTXfaRHW4sVu6DTpANKPoAh7?= =?us-ascii?Q?+NIrccwKtkTS1mb+aqYIbzimKBEnSjzF9Su2AuHKz/arlwB1/bYruMsR6v4X?= =?us-ascii?Q?Hvj5ow=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 14:30:04.7744 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 90b5902e-1054-479b-2f9b-08de58f991ba X-MS-Exchange-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: BL6PEPF0001AB78.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB8142 Add missing scaffolding to enable BusLock Threshold. That is: * Add general_intercepts_3. * Add missing VMEXIT * Adjust NPF perf counter base to immediately after the buslock counter Signed-off-by: Alejandro Vallejo Reviewed-by: Teddy Astie --- v2: * s/general intercepts 2/general intercepts 3/ * removed _thresh suffix * added missing _svm_ infix in the SVM feature --- xen/arch/x86/hvm/svm/vmcb.h | 15 +++++++++++++-- xen/arch/x86/include/asm/hvm/svm.h | 2 ++ xen/arch/x86/include/asm/perfc_defn.h | 2 +- 3 files changed, 16 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/hvm/svm/vmcb.h b/xen/arch/x86/hvm/svm/vmcb.h index ba554a9644..231f9b1b06 100644 --- a/xen/arch/x86/hvm/svm/vmcb.h +++ b/xen/arch/x86/hvm/svm/vmcb.h @@ -65,6 +65,11 @@ enum GenericIntercept2bits GENERAL2_INTERCEPT_RDPRU = 1 << 14, }; +/* general 3 intercepts */ +enum GenericIntercept3bits +{ + GENERAL3_INTERCEPT_BUS_LOCK_THRESH = 1 << 5, +}; /* control register intercepts */ enum CRInterceptBits @@ -289,6 +294,7 @@ enum VMEXIT_EXITCODE VMEXIT_MWAIT_CONDITIONAL= 140, /* 0x8c */ VMEXIT_XSETBV = 141, /* 0x8d */ VMEXIT_RDPRU = 142, /* 0x8e */ + VMEXIT_BUS_LOCK = 165, /* 0xa5 */ /* Remember to also update VMEXIT_NPF_PERFC! */ VMEXIT_NPF = 1024, /* 0x400, nested paging fault */ /* Remember to also update SVM_PERF_EXIT_REASON_SIZE! */ @@ -405,7 +411,8 @@ struct vmcb_struct { u32 _exception_intercepts; /* offset 0x08 - cleanbit 0 */ u32 _general1_intercepts; /* offset 0x0C - cleanbit 0 */ u32 _general2_intercepts; /* offset 0x10 - cleanbit 0 */ - u32 res01[10]; + u32 _general3_intercepts; /* offset 0x14 - cleanbit 0 */ + u32 res01[9]; u16 _pause_filter_thresh; /* offset 0x3C - cleanbit 0 */ u16 _pause_filter_count; /* offset 0x3E - cleanbit 0 */ u64 _iopm_base_pa; /* offset 0x40 - cleanbit 1 */ @@ -489,7 +496,10 @@ struct vmcb_struct { u64 nextrip; /* offset 0xC8 */ u8 guest_ins_len; /* offset 0xD0 */ u8 guest_ins[15]; /* offset 0xD1 */ - u64 res10a[100]; /* offset 0xE0 pad to save area */ + u64 res10a[8]; /* offset 0xE0 */ + u16 bus_lock_thresh; /* offset 0x120 */ + u16 res10b[3]; /* offset 0x122 */ + u64 res10c[91]; /* offset 0x128 pad to save area */ union { struct segment_register sreg[6]; @@ -583,6 +593,7 @@ VMCB_ACCESSORS(dr_intercepts, intercepts) VMCB_ACCESSORS(exception_intercepts, intercepts) VMCB_ACCESSORS(general1_intercepts, intercepts) VMCB_ACCESSORS(general2_intercepts, intercepts) +VMCB_ACCESSORS(general3_intercepts, intercepts) VMCB_ACCESSORS(pause_filter_count, intercepts) VMCB_ACCESSORS(pause_filter_thresh, intercepts) VMCB_ACCESSORS(tsc_offset, intercepts) diff --git a/xen/arch/x86/include/asm/hvm/svm.h b/xen/arch/x86/include/asm/hvm/svm.h index a6d7e4aed3..15f0268be7 100644 --- a/xen/arch/x86/include/asm/hvm/svm.h +++ b/xen/arch/x86/include/asm/hvm/svm.h @@ -37,6 +37,7 @@ extern u32 svm_feature_flags; #define SVM_FEATURE_VGIF 16 /* Virtual GIF */ #define SVM_FEATURE_SSS 19 /* NPT Supervisor Shadow Stacks */ #define SVM_FEATURE_SPEC_CTRL 20 /* MSR_SPEC_CTRL virtualisation */ +#define SVM_FEATURE_BUS_LOCK 29 /* Bus Lock Threshold */ static inline bool cpu_has_svm_feature(unsigned int feat) { @@ -56,6 +57,7 @@ static inline bool cpu_has_svm_feature(unsigned int feat) #define cpu_has_svm_vloadsave cpu_has_svm_feature(SVM_FEATURE_VLOADSAVE) #define cpu_has_svm_sss cpu_has_svm_feature(SVM_FEATURE_SSS) #define cpu_has_svm_spec_ctrl cpu_has_svm_feature(SVM_FEATURE_SPEC_CTRL) +#define cpu_has_svm_bus_lock cpu_has_svm_feature(SVM_FEATURE_BUS_LOCK) #define MSR_INTERCEPT_NONE 0 #define MSR_INTERCEPT_READ 1 diff --git a/xen/arch/x86/include/asm/perfc_defn.h b/xen/arch/x86/include/asm/perfc_defn.h index d6127cb91e..ac7439b992 100644 --- a/xen/arch/x86/include/asm/perfc_defn.h +++ b/xen/arch/x86/include/asm/perfc_defn.h @@ -7,7 +7,7 @@ PERFCOUNTER_ARRAY(exceptions, "exceptions", 32) #ifdef CONFIG_HVM #define VMX_PERF_EXIT_REASON_SIZE 76 -#define VMEXIT_NPF_PERFC 143 +#define VMEXIT_NPF_PERFC 166 #define SVM_PERF_EXIT_REASON_SIZE (VMEXIT_NPF_PERFC + 1) PERFCOUNTER_ARRAY(vmexits, "vmexits", MAX(VMX_PERF_EXIT_REASON_SIZE, SVM_PERF_EXIT_REASON_SIZE)) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 21 14:30:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 14:30:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209827.1521737 (Exim 4.92) (envelope-from ) id 1viZDu-0007CG-G7; Wed, 21 Jan 2026 14:30:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209827.1521737; Wed, 21 Jan 2026 14: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 1viZDu-0007Br-BO; Wed, 21 Jan 2026 14:30:18 +0000 Received: by outflank-mailman (input) for mailman id 1209827; Wed, 21 Jan 2026 14:30:16 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viZDs-0006vP-GG for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 14:30:16 +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 b21b3698-f6d5-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 15:30:12 +0100 (CET) Received: from MN2PR07CA0021.namprd07.prod.outlook.com (2603:10b6:208:1a0::31) by MN0PR12MB5979.namprd12.prod.outlook.com (2603:10b6:208:37e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 14:30:04 +0000 Received: from BL6PEPF0001AB78.namprd02.prod.outlook.com (2603:10b6:208:1a0:cafe::94) by MN2PR07CA0021.outlook.office365.com (2603:10b6:208:1a0::31) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.9 via Frontend Transport; Wed, 21 Jan 2026 14:29:57 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF0001AB78.mail.protection.outlook.com (10.167.242.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Wed, 21 Jan 2026 14:29:57 +0000 Received: from xcbagarciav01.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 21 Jan 2026 08:29:55 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b21b3698-f6d5-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=KRn0zPRCiuvYDH//aXD7NbQwPl6LlXpN5nxnXBG4Ja1cdEi8vy4E5qRGVh1Oce+bFssjRv+aU/eGUvyFj/EyYjqpmRpD1qfP9+ytMsUXJmhhhCAiPoac2sswCfnS8z1Z50HLsD/g+CCH6ElgvQ+aLtAV3Scg/i3EuZPfCBBLXEC8SRjumeqki6GjDMmqcMXmzbC5Ac5i9Ke+eUNE414ArNj3UfZ8Nj2hQ87GKfVJhZJXBF329R5CqF8Lao5ZZc19PBTPOls5y74qpsTI36HsjcYKI3UGqdVqK7fvWNLB9WINoH7dEX2x8eVbH2wss6pDhXlfOqeTFXCOLD47xjIRhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NB/bRU2K+Hx6Vf9hp6DVAPKBk1y2bdwkPR9p0WpfVXk=; b=I9UnAmd6UhBii4U2XueoQuU8q+dGMOon3Zyufpntn1rfsgmUO1SsQNJYNYkEWZuzq48oW9oMyLwzV8JREdtxEfObPbs9F1+MUUxQj+nTD62UPHv4jWRU3M8/KnxEv0BBBF/9aKKYYiYLaRvFJqKBNN9/OM8dmpywIeQcOVLIylw9rOPWgC9EZU3QFLmsm2ofkWxAYlgYlMZtgiWjSnUgwlwCaemLjhV2DBLK2MpwBnbyhut7gVaKsbKJvZ5Ob5bjNOpBi7dos9gMDrRdp+wxhG9yIrDX2OQIAJup98fvesAW9hsBdGA698wtyLKnFMOxE6YYiomOkbfvX+9z1GH8qQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NB/bRU2K+Hx6Vf9hp6DVAPKBk1y2bdwkPR9p0WpfVXk=; b=IGOoULY+XQcjVXRraQii5WcZWmoNHnCX2s1BLRZTfIgDBMjKBijETMjbdzCS5lYImsit2Adts1u6To3n2zBvQ0LmcIhjq43LxPvjvuSq5FmT21rNzv4wnDkIIbzjslU9qxTWxDze0+obR1Fz2J1IloF4uq3u0mVQUUt7aBgaA2E= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Oleksii Kurochko , Community Manager Subject: [PATCH v2 0/3] x86/svm: Add support for Bus Lock Threshold Date: Wed, 21 Jan 2026 15:28:52 +0100 Message-ID: <20260121142857.39069-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: BL6PEPF0001AB78:EE_|MN0PR12MB5979:EE_ X-MS-Office365-Filtering-Correlation-Id: d98dbdab-82df-4681-d1ed-08de58f98d87 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: =?us-ascii?Q?kmx0z1wsPEtHoI3LtvIq4vGHjMMf7QRXvaGb4hzC2kNDM4KPKjUM3aCsha6R?= =?us-ascii?Q?izMCh5kfhaU8zx9Gi6AEkyit427nt4Boa6+lGQAv2FyABeREaQDzL7Dako57?= =?us-ascii?Q?Zh9xk5ftk3xA7jmH8+2FgJtBnstYTRiJK794KMZMjJ/yhDYKlmDD26JnXNpw?= =?us-ascii?Q?TzO9QxEbwsu/iDwtf7NX/LNMH++jztRq2OflGGWOc86dl22Fd0C0RmK3dVrU?= =?us-ascii?Q?iAKw0sxAk+zNvlH3jezbPnOhrcl5aZVT912m2QoDsO7DKVd8tcD+WmYQix9W?= =?us-ascii?Q?TFds8wtMZpsNMyGuXoOaKJBXkavYS/VDk9FD+qhajk+KfEgGBG2F82xC/tFP?= =?us-ascii?Q?xkM5MCa/0efBaFxQlVMldpGA45X9tM5Rx2MCVZ9UI3gyjG3ijcIGS48Gjdfg?= =?us-ascii?Q?RC7y0pPEsjnY1EEx4EAI2TQjyGPz3lQMbbXgfr1RaycTGjXD9EkJ61Mh/GQi?= =?us-ascii?Q?i6RMNrwFd3tjsMv1PSXWd760IjFpR8g6OCk6l6g0QuQzcDaiPnimlFxfxlLb?= =?us-ascii?Q?X/KAg7O4UWRKo49mCaVyzPa92tTJXb+hW+zKEtCTK+8Tfdf283Q+VumYd485?= =?us-ascii?Q?fFpf+r280Dd3OP6b+KQAasERuKyAmwarbm5LVc7/2ExNYNFbp2FqJmdspxAN?= =?us-ascii?Q?tgt15rxOgoQyQ7VgpoqYX5AvEfRT83OVIlN0QheMPKuX/s0vzfwS8xmOnoCc?= =?us-ascii?Q?GhpXBatlUC2PdT1KUw4YchjruojmO754S9ZRfUtFlUYksxlYU/ORZRftDpvd?= =?us-ascii?Q?yNLIoFxBO5y1s0uo3BWZJ9Z+t7hJdoU0iXF5LgkENFMGF9XIAw/36NT7Jois?= =?us-ascii?Q?BKiuud0L6ySuzF+gXzJD+1WjgMRs30MEVlOn9PZgggSD6WeX9RV1/LQdXeNM?= =?us-ascii?Q?hq8ou5hbHV71iGzkCNLqt+6PUWXegvPZvueF8bkW3GHyyNkzKvYcscdYlnDv?= =?us-ascii?Q?x086qRChN6vmUAQ7IIL1ZMMrtqyQPrgLXIZ4v+hh4FokoFYYq4UTEm4hK0a7?= =?us-ascii?Q?gAu35uE5eAGi881ZPA3ATqH9y8YOkkMwefx1gEj/5DSx3x80TOKY1ZSa35kx?= =?us-ascii?Q?L+vpyj024nWAqX6A39CmBR3hss4A+28y0MdVB/mzw3Fda+p3qiSy9WSEbLte?= =?us-ascii?Q?9Sb1E0H4RofbMKoa/iCGqhEZggZq3WqQUWnDJ1sh9EoLreI1EMqN9HLwL+ZV?= =?us-ascii?Q?lvV1CfzcxEyflrwfsNzLSM78sIxDQmqu6SjuymLU/Ah3eypa/IUpwJmz15To?= =?us-ascii?Q?78dJm4hNpsAG8hTrfyX5fVYke7jK+GP83JfuI2q0NTFcwz7Sy8lY0KKjS11Y?= =?us-ascii?Q?QKUHkSSd6do5/hgfbhiU1Auqt+dPpmt9qaR7o5Vx6orEyfzwaKNm++LUCXBq?= =?us-ascii?Q?/qwfscz6P6p7Vj637WB7K9PQb12oAW7yQsR0OuDYkoYwGH+mabWjrk+w3oZA?= =?us-ascii?Q?HfBg42W+At+iAjgXbiaG7+mBAco4/loASB4Hb3RTkw2KO21Gr90/YPD/hZ7O?= =?us-ascii?Q?XWJWQptw3xMMFUcgQWmNFHsKyuiVvySPre0b2/0+5J6txYFoZeYdy6tmVr4S?= =?us-ascii?Q?qU/m17g9ZamS7eIeiB5Hng/FoA3xw8WoL+0DmerV+jak1ICQZTedXsh+hXzF?= =?us-ascii?Q?T2crfL1V7q52IOEqv/K//4AiL+ORS2MaPIJY0YzRKloZMj0RIPCSeJKsHgr/?= =?us-ascii?Q?DjZwog=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(82310400026)(1800799024)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 14:29:57.7348 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d98dbdab-82df-4681-d1ed-08de58f98d87 X-MS-Exchange-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: BL6PEPF0001AB78.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5979 Hi, v1: https://lore.kernel.org/xen-devel/20260120095353.2778-1-alejandro.garciavallejo@amd.com pipeline (in progress): https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/2276726870 Original cover letter: Bus Locks are very costly and a VM left unchecked spamming instructions that lock the memory bus (e.g: unaligned atomic CAS) makes system perf take a nosedive. This patch is similar to BLD of VMX, but for SVM. It configures all VMRUNs so they automatically exit at the first encounter of a buslock event, effectively rate-limiting them. Cheers, Alejandro Alejandro Vallejo (3): x86/svm: Add infrastructure for Bus Lock Threshold x86/svm: Intercept Bus Locks for HVM guests CHANGELOG: Note the new SVM bus-lock intercept CHANGELOG.md | 3 +++ xen/arch/x86/hvm/svm/svm.c | 6 ++++++ xen/arch/x86/hvm/svm/vmcb.c | 3 +++ xen/arch/x86/hvm/svm/vmcb.h | 15 +++++++++++++-- xen/arch/x86/include/asm/hvm/svm.h | 2 ++ xen/arch/x86/include/asm/perfc_defn.h | 2 +- 6 files changed, 28 insertions(+), 3 deletions(-) base-commit: 61204ed24ba4537d6eff56594faa5d23cacb8310 -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 21 14:30:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 14:30:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209825.1521721 (Exim 4.92) (envelope-from ) id 1viZDs-0006vm-Vm; Wed, 21 Jan 2026 14:30:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209825.1521721; Wed, 21 Jan 2026 14:30: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 1viZDs-0006vf-TB; Wed, 21 Jan 2026 14:30:16 +0000 Received: by outflank-mailman (input) for mailman id 1209825; Wed, 21 Jan 2026 14:30:16 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viZDr-0006vP-Qe for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 14:30:15 +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 b0cdb3ca-f6d5-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 15:30:11 +0100 (CET) Received: from MN2PR07CA0017.namprd07.prod.outlook.com (2603:10b6:208:1a0::27) by CH3PR12MB7545.namprd12.prod.outlook.com (2603:10b6:610:146::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 14:30:05 +0000 Received: from BL6PEPF0001AB78.namprd02.prod.outlook.com (2603:10b6:208:1a0:cafe::ad) by MN2PR07CA0017.outlook.office365.com (2603:10b6:208:1a0::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.9 via Frontend Transport; Wed, 21 Jan 2026 14:30:03 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF0001AB78.mail.protection.outlook.com (10.167.242.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Wed, 21 Jan 2026 14:30:05 +0000 Received: from xcbagarciav01.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 21 Jan 2026 08:29:59 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b0cdb3ca-f6d5-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QvLvv+FEqey4y586Ljw+gykamMZ9gw6N+/JGfh6GVBU7s9+aWlpfTDaA7+3xEdwWsn2DF54A40UwDKbWlDxI+zWdJTJoN3nZu9vPtLv5gi1AFqvlrhUeQPN6KSDaG0UM0HFGS972LU0eou95dA8FCwKq1w104Mib7y/Xsu+NyZL961FAL4Bw0Rtwmqxn5ik45f3mQ3K+hmEejOn9RUe9OfQMBdHaIxPdumXux6RWmdQpGXJeloPx4GKdxUs6NhGgDOtZIuimeOdPyr7YMdVc8Kd8ISZ14M9Qns5TPrgXV2nV5JqlGLMRZ2Z2K7NbWLWUuPMXmsXuP4LohxAb8iKAKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UFUWMJIT5ILfQMVeeOtM43khGeImb8Dazel0lpTU+JI=; b=PPSHd1rU910IYCDj95oR6HvpDL78hj7kZpTkyVtc5oYkmWBhL5TV168ujJ2F6iU4tq3aggu3KfxdxPlx6QSFHwqskrFFOys9rqGKVBEN6uAomzOf8OOLDhgW2sdI5XpEckLmSoer+GRBfH/I8/Sd6rVd3Txeof8nIPKaS3QyPgAWmDVLnFE2hSBGMQOj/UwSpBHPPxAIOK4e7/uyINhkJNsSC3yyFF+ARSev/mI8gQwrtiYyqsGLNXRRs7ORChMlwHzphgzGLLln4B3/Zl/ZIXI9Q2VSLzSK8NB2WSjkztTAZTJY0PsqZ/WheTLEldtRJO6JGKivtMszxLPN9+T+Hw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UFUWMJIT5ILfQMVeeOtM43khGeImb8Dazel0lpTU+JI=; b=W5tfzqibdDGkr3+zti6Sj+Pgi77hGPrae8n0idwiEaIvL1TmvNCqm8X37CUCV3hWS4JWWmlvGJA8hzhSXcOC9tovf6O7L8PsxoACZCUmKbY6zIXqiqEvTtgkqFN7pJcI214DFM/y90d0s7pQDiGXpRdz+MAyu85RTL41KmfptV4= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk Subject: [PATCH v2 2/3] x86/svm: Intercept Bus Locks for HVM guests Date: Wed, 21 Jan 2026 15:28:54 +0100 Message-ID: <20260121142857.39069-3-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260121142857.39069-1-alejandro.garciavallejo@amd.com> References: <20260121142857.39069-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: BL6PEPF0001AB78:EE_|CH3PR12MB7545:EE_ X-MS-Office365-Filtering-Correlation-Id: 2c03ed46-9e11-4612-ca8c-08de58f99228 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?OkJlMPmvVlRd6iA0o4qTGp9Eco6j6T+UqYFQFtOHjT+8fHCs3NZMQyO3QNPS?= =?us-ascii?Q?SpyXRI5NT49an83+yi5LT29YmKhFmnNoh8q18oBCnCYUIMmMsLo9qYwr73Et?= =?us-ascii?Q?OK06AMazSUbkBgsZUohTYFmAkw1cXwOwLjXCC/sVcnx1Z1/g6WAr6/PjFNBR?= =?us-ascii?Q?FN23rxUt0NUKx+pMtwC0wO7m8djF3MkAKZbVwk1lrbJ0EhBQo3HYt2o2xfhG?= =?us-ascii?Q?ZFpn4NMZ4YKbq/tsIEu7bgEcweue3lwEM+NWCG37WkmTBI1fBfkYjoboNVQB?= =?us-ascii?Q?wKZBRqP92akkbwoTl2qLbql2vwdOY7zjGjnq/sooHvunX67yJtGdkka+UTcZ?= =?us-ascii?Q?md4qdv6Gs5CLG55RdeJ4qst06QlhDfVycOZVJTE66uD+y0rVqC3B44bBfkF7?= =?us-ascii?Q?Qnw90H46rrinadadKQdIrrIyumyXiIyepNh8AI9jmygGExlwC/rtpY6DT/7n?= =?us-ascii?Q?+VF8PEWVrKMMGccuucJ1cvYIATu8DoQMJLkrvlqRoN/704uw40MIwqFjehC6?= =?us-ascii?Q?ZJ54TBZmw6xWMM3lk9bVzDXXgr0ZY7SoXEc4wBRBbKj+/BfKriJ3aEPH2k8S?= =?us-ascii?Q?vyU4s3wJUb9j+IRhOrj7OY9J+D+88RYaXM4XLDiExgh/pIDlRx10KNlEKq9t?= =?us-ascii?Q?VxHr0VGPQVtTgCqY/34HNDc8lzdsfTc7c+uA0+C4E5f6Wsph4IzwOp0cBysJ?= =?us-ascii?Q?MV4pxYtONqfwjpXutDoNbKmv80rAJhLqP76VJbYKVz9/mW/gBf11mWcwmmLJ?= =?us-ascii?Q?P2DQOr16Eepfjv2lbWQ9/CVseu2QlNBboeJ7AtrclaHYlfoPmaIKEtsszBRp?= =?us-ascii?Q?vexPJoHr5YecIGMmxZyI0qnF/WLHyO35EFY1Z+zQGlqotDMIaqzJ47R0FbdZ?= =?us-ascii?Q?M8237oRyd6YetvQT3xUCaquSWq649i1zVFZj+AHDZEP2/xF+tAI9EB3ciL1U?= =?us-ascii?Q?FsjpaxgdAdULqGa1XasMJ7obV0sgHQSo7ee0Um+sa6DBFbSHohNpaIWKu6+7?= =?us-ascii?Q?nKU9CgQos3GLMR81o7PK81Kyu/3Wuc25GmSBLnE9jaVd9NOjEaba0kXUJhDV?= =?us-ascii?Q?z5N8YLHthAF7Ax5TGc4RXJEXDe2e2DN5OFElHjZNtlaIu9HMGK5D1j3L+VpO?= =?us-ascii?Q?NSAwH+PAXMGSwzyOqxnHlyjraxzbLpFyXexgHNvaavC20Nys+QcPgp3w8I39?= =?us-ascii?Q?2m9P/Jw8hq7OmZxFJn8Lbp9WSPhbq8Ewv2O/v1dJlMGWqxpv2Jt7jyabK5cn?= =?us-ascii?Q?OTUBK4Xl99hSHRupcCb5iYwylY6CqXpOtbbbO2UVyEpfs5cJ7CoxPoJF6SlU?= =?us-ascii?Q?fTGG3DRVWSkmtr1UkPeJBrKotx+l0oWFncqaaF2vr8MUs3RFd2evGBlNaod9?= =?us-ascii?Q?6ou2Rvk2liX/LmvxjJnLikuuM5+pZ/xPv7c/3Lo06Lm4efqdAHRV5gLjG/G/?= =?us-ascii?Q?0FEbVPfYWHA3ge1RerTITW91+esn5Y4mFfS8d22svrm3WLDoLxSBE9Dhxj6c?= =?us-ascii?Q?zqw6nVOeBjJDHrtLTT7inuXhNKSc8SWgCeBfHtQiat8RV0UcnrNzjTtU0sLr?= =?us-ascii?Q?lNJgI8rfmoIF8lZvP6h29HDfqZ1JYROFZtZwlexiNhpcs5CziCYjQb1nN8WY?= =?us-ascii?Q?Wvh2qgLz0BaOvgNuvt384G57gt0SqB9d5Gk5DbhhPautKMibLn/bLg0mZLLU?= =?us-ascii?Q?Tb5kBA=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 14:30:05.4981 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2c03ed46-9e11-4612-ca8c-08de58f99228 X-MS-Exchange-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: BL6PEPF0001AB78.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7545 Configure the Bus Lock intercept when supported by the host. The VMCB counter is initialised to zero so it fires upon the first instruction that locks the bus. On the #VMEXIT handler that counter is set to 1 because it has fault behaviour and the offending instruction needs to re-execute. Signed-off-by: Alejandro Vallejo --- v2: * Moved the P() call to this patch. We don't want to print until the feature is fully supported. * Removed the initialisation of the counter to 1 in vmcb.c, so it's implicitly zero-initialised. --- xen/arch/x86/hvm/svm/svm.c | 6 ++++++ xen/arch/x86/hvm/svm/vmcb.c | 3 +++ xen/arch/x86/hvm/svm/vmcb.h | 4 ++-- 3 files changed, 11 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 5d23603fc1..abda5a9063 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -2524,6 +2524,7 @@ const struct hvm_function_table * __init start_svm(void) P(cpu_has_tsc_ratio, "TSC Rate MSR"); P(cpu_has_svm_sss, "NPT Supervisor Shadow Stack"); P(cpu_has_svm_spec_ctrl, "MSR_SPEC_CTRL virtualisation"); + P(cpu_has_svm_bus_lock, "BusLock-Intercept Filter"); #undef P if ( !printed ) @@ -3087,6 +3088,11 @@ void asmlinkage svm_vmexit_handler(void) break; } + case VMEXIT_BUS_LOCK: + perfc_incr(buslock); + vmcb->bus_lock_count = 1; + break; + default: unexpected_exit_type: gprintk(XENLOG_ERR, "Unexpected vmexit: reason %#"PRIx64", " diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index cbee10d046..15223a693e 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -66,6 +66,9 @@ static int construct_vmcb(struct vcpu *v) GENERAL2_INTERCEPT_XSETBV | GENERAL2_INTERCEPT_ICEBP | GENERAL2_INTERCEPT_RDPRU; + if ( cpu_has_svm_bus_lock ) + vmcb->_general3_intercepts |= GENERAL3_INTERCEPT_BUS_LOCK; + /* Intercept all debug-register writes. */ vmcb->_dr_intercepts = ~0u; diff --git a/xen/arch/x86/hvm/svm/vmcb.h b/xen/arch/x86/hvm/svm/vmcb.h index 231f9b1b06..68cf5eaf0b 100644 --- a/xen/arch/x86/hvm/svm/vmcb.h +++ b/xen/arch/x86/hvm/svm/vmcb.h @@ -68,7 +68,7 @@ enum GenericIntercept2bits /* general 3 intercepts */ enum GenericIntercept3bits { - GENERAL3_INTERCEPT_BUS_LOCK_THRESH = 1 << 5, + GENERAL3_INTERCEPT_BUS_LOCK = 1 << 5, }; /* control register intercepts */ @@ -497,7 +497,7 @@ struct vmcb_struct { u8 guest_ins_len; /* offset 0xD0 */ u8 guest_ins[15]; /* offset 0xD1 */ u64 res10a[8]; /* offset 0xE0 */ - u16 bus_lock_thresh; /* offset 0x120 */ + u16 bus_lock_count; /* offset 0x120 */ u16 res10b[3]; /* offset 0x122 */ u64 res10c[91]; /* offset 0x128 pad to save area */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 21 14:30:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 14:30:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209828.1521747 (Exim 4.92) (envelope-from ) id 1viZDv-0007Nv-0c; Wed, 21 Jan 2026 14:30:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209828.1521747; Wed, 21 Jan 2026 14: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 1viZDu-0007KQ-Pu; Wed, 21 Jan 2026 14:30:18 +0000 Received: by outflank-mailman (input) for mailman id 1209828; Wed, 21 Jan 2026 14: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 1viZDt-0006vP-GP for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 14:30:17 +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 b3667767-f6d5-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 15:30:15 +0100 (CET) Received: from MN2PR07CA0010.namprd07.prod.outlook.com (2603:10b6:208:1a0::20) 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.9542.10; Wed, 21 Jan 2026 14:30:09 +0000 Received: from BL6PEPF0001AB78.namprd02.prod.outlook.com (2603:10b6:208:1a0:cafe::4) by MN2PR07CA0010.outlook.office365.com (2603:10b6:208:1a0::20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Wed, 21 Jan 2026 14:30:07 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF0001AB78.mail.protection.outlook.com (10.167.242.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Wed, 21 Jan 2026 14:30:07 +0000 Received: from xcbagarciav01.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 21 Jan 2026 08:30:01 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b3667767-f6d5-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=esOxIYS2LiIhmNk6ZshNwIWIxf2PphzNLZHbgLkU+kteLXNfdX7lB71+ajvS1ftfl+aqmQWpduIjMUZuNOAYflqY6PmX7zc/04SyYdojAJ7zSYaMd3ymo4rImXEjSdBNH45LEuTmyjHbOOKiBsBQ8fTTLVE5Rl3MuMbxFgN/yHaV9rzmdS8gmCc39UvewnsDuCFpNFH9H1QSAYHjkMsJ1XCqsDRIaTJnwWaKZ0bQnMU8BY4Ig/SiDmWSzpRyNZFwzS0yMCCxZYqUImif+cPHkZsgM5B9388d9fdvFml8QvcW1ZDS2Ihi1owqzdD8KaNjbIwPHuKocy/i/uXmYHQItA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pQaQz/co1dWKOQJegRLRV/x0sT/NPpp7Wh/Pk2meZ2I=; b=BiiWPQivei4D0Ht/IIJxMqJ00zd3mGw7QhOnGsm9Fqj9d5Y6Rsyk8/beynKXynnPFjlE8kKMoREVjz3bjfAhrT8RhWLP4JpE4LpedJZ93113hfR0dsNNQvCmC3oq6mFcS8tx9ILjjCO+f/7sqkOE5szKG9NeXm3FCSlRwDKznqlcyMFcfEcVOOKXP7mdIQxo6qUe+Xd/UKwpIHEJ2a16LB9cWFe3UUetwBKlwvSKB3681oXGiJN2+n8X5APFq6FqQX2tGxDaDeH3S4j7AFkbuLfDW6irxXWUBDzOgGMAt6bjSvWMrqjiw19ZJL9TClApzLPYBx+I7I3sPNMS7abaOw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pQaQz/co1dWKOQJegRLRV/x0sT/NPpp7Wh/Pk2meZ2I=; b=rh1Iqpqa75jTYWNy8BTUJRXpAxOmcE9vNlNECjFyxatHQn6kbK+sEk2uH2UDYFk0PmpM+xv7AdTqp1aKztD63yCviTNoNJJgdlWWVXB+Faj8ages+pEmF887+iZE4h+yIED5Hl/1lAt42gAHxeHW3VSVEbN3Rg0aTvvsqeY5iVc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alejandro Vallejo To: CC: Alejandro Vallejo , Oleksii Kurochko , Community Manager Subject: [PATCH v2 3/3] CHANGELOG: Note the new SVM bus-lock intercept Date: Wed, 21 Jan 2026 15:28:55 +0100 Message-ID: <20260121142857.39069-4-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260121142857.39069-1-alejandro.garciavallejo@amd.com> References: <20260121142857.39069-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: BL6PEPF0001AB78:EE_|CH1PR12MB9720:EE_ X-MS-Office365-Filtering-Correlation-Id: 3aa9d2c2-f45d-4d29-0c31-08de58f9937d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|82310400026|36860700013|1800799024|13003099007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?pfZrC5XgLexW+KXFhPAjKP4OQf9+o3GsPLVurtuPDyzt5pdHTRtXt/24DMTa?= =?us-ascii?Q?YfsG1lbmlLwcQiRDROFCry3IpXQg7m192HFt4tkwkEtAfozlYGBSaHqy1Yt0?= =?us-ascii?Q?EoeF7uBma0dq1/BfmfVbp/1cXrIpb5KOiNumkDOhKqRBC+ZaYtb4Cb9hPIMf?= =?us-ascii?Q?1xW5gYEX9rYZiWzI3w35aMenmHw/D6owCk7LR32LMSB5YJt0UJt5TsjU0o3W?= =?us-ascii?Q?xgHHL7ewnYr7sFWl6agBI2mYdztF4jlImk+N37eOqJYVxt1bXcJh3AZBSBVQ?= =?us-ascii?Q?ShcqiBD4pBmCfT1tJMD/v8JRW3xJEK+KJfgslyviTaN8BrJhOWRfV9uImzvv?= =?us-ascii?Q?fsCbZ+qIOIV7gADLUp33stWufJkvaK/sSyTT8OVhjHdNh68SkY4Whq7nrf5N?= =?us-ascii?Q?E7DtoDTF17DX52DOgWtcPXCJkWr60AR3qW6RNGpjhpnN18hXYzw0DB2hgxWS?= =?us-ascii?Q?oH53PIyFfjdOIcMBbUxv33/ZAAf7REHKiduNi1JUc7/6sUyZJJp/i4O8WebL?= =?us-ascii?Q?L8ZKRVzv8EBdzo61ZXG2inXe+D5MxXHCnS0Z/AEf2wSNNp7ST1EQngdxJyxg?= =?us-ascii?Q?cVhjoUP9LSTJoFuZBtCbpBAGZgGI8RkTEeIMZwevuNiPTeR6kGrBeBN76/46?= =?us-ascii?Q?tSpeHtGZA/pzFqTLNzkoqRqkAoQdNX910DJCVym5SCYeYe3/Z9NU5eNYyU9m?= =?us-ascii?Q?nnPI4BcFrFuWA+AoJuXbAIhuWU0g/RGuMWz05S/9OHPlxBFYFTQ1iNL1Lv0t?= =?us-ascii?Q?EIbvN1aF+gtljPDMgs33I0Wer7fz1dIAuWcjPjLsJm/MNHsY04/rMABAejwk?= =?us-ascii?Q?ndgUZYoHbSwFVaxQOVDk6v9yLriyin9kfcESzcUKaT+P6003TnyleFaffC5y?= =?us-ascii?Q?b1/N8++IntRG6lB3+PbQLay3l+q/KQ4b7r/caWEdg87pBuOQtNuLYbNvBwur?= =?us-ascii?Q?JP/oq8Ng3yW52rDOr8iL4tOg1QB6StNee1MlATXAygiJH14n3cip0ce3uJ/D?= =?us-ascii?Q?oXXBXtb2KFhaIlXfVAF8b8NjnVWPQGIaUe+cc4BEJiHuUO2lYYbWQIDB/poW?= =?us-ascii?Q?6SnEyOJgg43NI7OTFxrqDYdbGNNmm74pEWHmnbWWHRTFhk8vKJs/AlHAk6pO?= =?us-ascii?Q?/W66Q1yKAezqTjJEfE0sHUZkrGn6DWRjy0kNjz1c2Uq1jxEGIkUERJWxVqpw?= =?us-ascii?Q?IeE9Hc0np54lqCMpiIEcOleMWwklGhqExpWGbFZaMs91fNWZE++fBbKRsm7z?= =?us-ascii?Q?YqckoDDppKEnKvufEE5BwFBdqbOLNlYF5Mmf/AdhG2gTcQqQtA+PexN6tzub?= =?us-ascii?Q?e09mYYpMGfLLKJGAAkYHXmcNa2yh/EY0+1YchZ3vU6C0rtSwhHg5EXHloHwW?= =?us-ascii?Q?nncRkfVspi2b7+03K4p6PVK/tZSIIfQoTAIHZk21gmK1/HNOM3ml52Zf4hCh?= =?us-ascii?Q?sJZMIyjbh0LJsrjxclJMIW+WOk2v7zJBMS7HRcRRJ5l6THNZze49Xtki5YHj?= =?us-ascii?Q?6vYcGsi2mFUnwWa/scrq74HYVOa/l7zD48Hv3tlRcvu+ZE6/7zTyxN6jlq16?= =?us-ascii?Q?ZUKTWP+3zUGVlMVmqAA6uxr6U2seZnNyjTdzAPBcSZfnGwr51Xn2pvHae8SG?= =?us-ascii?Q?RA=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(36860700013)(1800799024)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 14:30:07.7300 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3aa9d2c2-f45d-4d29-0c31-08de58f9937d X-MS-Exchange-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: BL6PEPF0001AB78.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PR12MB9720 Signed-off-by: Alejandro Vallejo --- CHANGELOG.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 53d92a2597..07c1745f22 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -9,6 +9,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) ### Changed ### Added + - On x86: + - AMD bus-lock detect, used by Xen to mitigate (by rate-limiting) the + system wide impact of an HVM guest misusing atomic instructions. ### Removed - On x86: -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 21 15:10:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 15:10:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209879.1521763 (Exim 4.92) (envelope-from ) id 1viZqp-0005Rh-RD; Wed, 21 Jan 2026 15:10:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209879.1521763; Wed, 21 Jan 2026 15:10:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viZqp-0005Ra-Ne; Wed, 21 Jan 2026 15:10:31 +0000 Received: by outflank-mailman (input) for mailman id 1209879; Wed, 21 Jan 2026 15:10: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 1viZqn-0005RP-U2 for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 15:10:29 +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 51501b5e-f6db-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 16:10:28 +0100 (CET) Received: from CH2PR07CA0053.namprd07.prod.outlook.com (2603:10b6:610:5b::27) by IA1PR12MB8538.namprd12.prod.outlook.com (2603:10b6:208:455::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.10; Wed, 21 Jan 2026 15:10:22 +0000 Received: from DS3PEPF0000C37D.namprd04.prod.outlook.com (2603:10b6:610:5b:cafe::be) by CH2PR07CA0053.outlook.office365.com (2603:10b6:610:5b::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.9 via Frontend Transport; Wed, 21 Jan 2026 15:10:21 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by DS3PEPF0000C37D.mail.protection.outlook.com (10.167.23.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Wed, 21 Jan 2026 15:10:22 +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, 21 Jan 2026 09:10:20 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 51501b5e-f6db-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iyr+U0S1klq0P0K9s2y60wn8dUsDuoEXlRs4Q0dGBqA8mp8plQP5fNC0NrUHUaPCQsejzdbvkDvwhzu8wBM9tiRegVsAELhhPdpSjKkOydLcQn4+G9CAafnL/o3G5JJ04uDzdMsMsVFEmuwHWQ97eQfN3BIxNbPQlfLcgw7K97z/HG57Gv2L6mKOl2cThm0FIkmw7BWrmBpA4KppLH2UkUEc4kojSpF+AkNOh8s3+wc4dSMWbNRQoEOk25QINaa2NeuYumIv6D8GqrwwZ/x0jUaOz8gcuR1qAMStJ98u7TTQHh86veI7bC7mduhuE6cuORpIR0S42OF42VyOYqWK7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=D9c5l+oGHnTXRL1LappdvbRkqqUgTw/8u1ICx4VqNYU=; b=jdRpv6GxnFPc+gjN2LigS/dQ6Qo0w8IPcwM6FNNPEB0O5F6gsmuVSHZJn85H7jn6Ypbrohlc24r9VCHCacPjAGjnbap9C6kxjRl+8GY02JiAc3dg0dYXsV9N+bFjYNgWhHVRKZmjvLIZseS4ej3mYWphkg3awsGx5AMVphE33hiFuhb7xhfI4yT4PGASoWjGiy2orR4YPwTh0Zzh+pNrEJpsb0Qdh2UTC1y6tgBXbRgb8ps3dBrUZO61f2t1v2sOqxj+CCqnfvscXkBNaEO6V9SB65yXIx9RFksAAG18KsRNstRE8IggYQ9jLkfC1DKMF+nQ+bq14AXpXDnKHuZmtw== 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=D9c5l+oGHnTXRL1LappdvbRkqqUgTw/8u1ICx4VqNYU=; b=H9bQsP03hAoOR8ix0YgWDreI/DhdmBbnUAw/LIE1SMAL1hA8a43NCIuLIupnWriRoMfZAMZtFEKRXRn01D2rsc1k+QKvAuq3C7wHQjojQV0h0nTa8k1+ssj8STxxp6nJziCDDTIkwykzt3639o8HPV1t+1prhb2s50HkwaMH6pM= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 21 Jan 2026 16:10:18 +0100 Message-ID: CC: Andrew Cooper , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Stefano Stabellini , , Teddy Astie Subject: Re: [PATCH 1/2] x86/svm: Add infrastructure for Bus Lock Threshold From: Alejandro Vallejo To: Jan Beulich X-Mailer: aerc 0.20.1 References: <20260120095353.2778-1-alejandro.garciavallejo@amd.com> <20260120095353.2778-2-alejandro.garciavallejo@amd.com> <9097240c-a892-41e8-a686-b89d84d0c03f@vates.tech> <8d627df5-5de5-49bd-ad15-abe2bad486f7@suse.com> In-Reply-To: <8d627df5-5de5-49bd-ad15-abe2bad486f7@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: DS3PEPF0000C37D:EE_|IA1PR12MB8538:EE_ X-MS-Office365-Filtering-Correlation-Id: c6b64272-4204-46ab-b365-08de58ff32a2 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?UEdXb1liNW1YUVNLMSs1S1pNUU9NaGtHWndrUlFMTSttdUczWVgvb0tFWkJR?= =?utf-8?B?bHN4d0FKZkw5Y0dMTW9uWmIzenlEN1FLQklzaC9zQVRoV2dqL2krOHkrRk81?= =?utf-8?B?OTN2TGZDTjlPZ1dRUGdaekdpVFlGVjUzU092QjdxektFb2Q3b0doNnJyZisr?= =?utf-8?B?Z2VTK0xhY24zYXQ3VHFUYXRmZFdoeU9UeEJ1U2NUaFVaRGdhK2lDRFZKRksx?= =?utf-8?B?dEpndDErWld1SVJQYVFEZEMvMGhwS1N4aGRkMFRQMkp1czl4WjlBaFNMenZQ?= =?utf-8?B?Q2N4Y1FqL1kwaEt3UE5KVXIzTmlnWFBYTlFYRnVEUEQzOWlWWGwvUDdqamxY?= =?utf-8?B?STZWdmovUDAvK3pvK3YvWUh2RzlOT1FYMzYrdGRHK3BwVE1XS1pnMlh2Ulg0?= =?utf-8?B?TVFvczhZZzdDSldKaHVWSDVUeVpPcENBWitJaVBPa2NTUS9QaCtrZ1M0Yloy?= =?utf-8?B?MitVZUpDOFE3Y1E3bHViYmpjSkIxY1hIVHNZK2ltd25JVk04amhmV1FPajkx?= =?utf-8?B?UHNUYmRFaTVXNnZzYjVZWnFZcWhmVGFETTkrcUgyMFZJbnpVbERPbE45c0tq?= =?utf-8?B?OWxtNW1MZmRQS3hKQ1VGOXVRWnc5bStpeExQTGo0QlRhckQ4ZzF3ZUNFKzVu?= =?utf-8?B?di9JK0VIU2pLV2lFcjdESVBwc0VoUUQ1MjQxRGNKdjRLb3A5endhRVNvY0lv?= =?utf-8?B?L3lmN3Nhb0thYWJldHRnZUkvcDNDUU55NkxHVG1iME55MnNxaGZGbnVXTkQ2?= =?utf-8?B?N2tVMHgydWMxd1M1N3FRc0g5KzVGS3N1dzFCTXRqaG5EQllESWRNK1htZjFO?= =?utf-8?B?NzdlMkxZV3ZIbGRua2t4eTdtMElZbzJkZStMV0YySWZ2VDJVQVZNOXl4QU5S?= =?utf-8?B?WWljQ002SUdUL3FQRW16NmNRTjR5WTRTQUNKRTMxRzJjQTl4Nm9wdlFyN1VN?= =?utf-8?B?ODhpeGUvTE1RZ1p3clRXaEp1RmN4UWRoYk12SVpQRDh0UC9BL3dha1Q5OTJ2?= =?utf-8?B?OE1qQ3V3dUpVNlRUeW5FN0VkRmRWZlFrSmtjcUZmN1luVC8zamtZYVYxcWtD?= =?utf-8?B?UUxYOEc3clE2Njh0TzhaV01tejNnVjRsbldqVXJlcWdmYWxFSjFYeWYxM3or?= =?utf-8?B?U0R3OURhSHdFRDZYKzdiQkQ4S2RvTkU1b00wTHk0YTl5MFB0aWNXQWNQajBI?= =?utf-8?B?bDZTam1WZkYxbE1QM3h3WVM5T0NObzlZOGR5T3g2RHovQnA0bmVxd3VibWQy?= =?utf-8?B?bjRYc2lMT0szQUs2a3BsNGhUb25SaVZxQlBxMWFLcGRnVmJTaU5xWmlzVGR4?= =?utf-8?B?bE5DRERieXluQkMzeXVNdTI2dk9SZkp1a2JQRE83V0ZxSm5xR2tqUlNoei9M?= =?utf-8?B?YmdEVzI3MTNVdFRraDFtVmVoRm44VzZ0ZmJMbjJvS1ZLWHhzR3VQT2tjWTBm?= =?utf-8?B?ejJab0ZlakY5STMwUG1EZDdyd0tReG56WERPNFU3T2grQXdFYU1icGgrdjNE?= =?utf-8?B?Rm5VTy9XNXo3Sk9oejU0VGZvVEhqaFgzdkFRakFHSkdHY3Bhc0N1Y010Wmph?= =?utf-8?B?ZUQ2bS9KRk8zbVlNMGNDSHNtUUdBUWw5cHNJZGVrTjRxVzQya3VGVEtWcEhi?= =?utf-8?B?S1NPVkdTOWRuNXM3a2k4UXY4SVhtUi9EQjlXM3lmV1hMeXFHNDlXbE9BaU53?= =?utf-8?B?bktUV2xUR2w5UVc0VVdUMHNBNDY1MzBtd1IwZm00S1RSWmdiNm5mZmR2WlAz?= =?utf-8?B?MW5xblFJY3BYekdBS09NRFpoeFRnamZFUVEvWjhiNzd6L1dNUEY2T1FuTVhZ?= =?utf-8?B?TUUxZ2JmdWovdTRrSWd5QkppWTV4YzNZdWM1M0dLM05Ea2dOQmQ3T3Z2ak5E?= =?utf-8?B?SDFCZCswWnlFT3ROc0VkZFE0aHJ6SkoyUXFnWHdtbkxTb1hEWE5UYk1nTmZh?= =?utf-8?B?Q3QzNW5NckNGTTVHZ2Z0a3dLTnB3TFRtdTFrbEsycm1uS0pMK1dDSytKcXNo?= =?utf-8?B?UGMvMlJrUS8rbWRSb2p6MDE0bWE2bEFKcUx6VlkvSGVNZDEremM4Qi9peURF?= =?utf-8?B?ZEVRdFdTZGljVG80eVcydGRnWDJHYWlXQjByd0Fobkd1NnFKREJBc2pXM3Z6?= =?utf-8?B?Q3pFSTJxQVhWcjh5L1BSbGg4YjI4NDJRUjczOXpXV3g1NkhHNm42OGJDNmZG?= =?utf-8?B?cThBaENzQ29IUzd1KzdkK0t0amFqWnlFTXNwQm82R015cmE1cldBNkVrd1dH?= =?utf-8?B?UVBrV0FiZTlRNWJZcGl6eXJzV2NnPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(1800799024)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 15:10:22.1762 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c6b64272-4204-46ab-b365-08de58ff32a2 X-MS-Exchange-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: DS3PEPF0000C37D.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8538 On Wed Jan 21, 2026 at 2:07 PM CET, Jan Beulich wrote: > On 21.01.2026 13:40, Alejandro Vallejo wrote: >> On Tue Jan 20, 2026 at 2:30 PM CET, Jan Beulich wrote: >>> On 20.01.2026 14:19, Teddy Astie wrote: >>>> Le 20/01/2026 =C3=A0 10:56, Alejandro Vallejo a =C3=A9crit=C2=A0: >>>>> --- a/xen/arch/x86/hvm/svm/vmcb.h >>>>> +++ b/xen/arch/x86/hvm/svm/vmcb.h >>>>> @@ -65,6 +65,11 @@ enum GenericIntercept2bits >>>>> GENERAL2_INTERCEPT_RDPRU =3D 1 << 14, >>>>> }; >>>>> =20 >>>>> +/* general 2 intercepts */ >>>> >>>> nit, you want to says general 3 intercepts >>> >>> And then, further nit, also get comment style right. >>=20 >> What do you mean by comment style? it's a /* ... */ oneliner that matche= s >> what the other general intercepts say. What am I missing? > > Quote from ./CODING_STYLE: > > "Multi-word comments should begin with a capital letter." > > Jan Ack. Though also from CODING_STYLE: "In general you should copy the style of the surrounding code." and intercept groups 1 and 2 also start in lowercase. I'll correct both as = well. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Wed Jan 21 15:14:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 15:14:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209888.1521772 (Exim 4.92) (envelope-from ) id 1viZuM-00060F-94; Wed, 21 Jan 2026 15:14:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209888.1521772; Wed, 21 Jan 2026 15:14:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viZuM-000608-58; Wed, 21 Jan 2026 15:14:10 +0000 Received: by outflank-mailman (input) for mailman id 1209888; Wed, 21 Jan 2026 15:14:08 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viZuK-0005zn-DF for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 15:14:08 +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 d2dace9a-f6db-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 16:14:05 +0100 (CET) Received: from SJ0PR05CA0131.namprd05.prod.outlook.com (2603:10b6:a03:33d::16) by LV2PR12MB5920.namprd12.prod.outlook.com (2603:10b6:408:172::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 15:14:00 +0000 Received: from MWH0EPF000A6734.namprd04.prod.outlook.com (2603:10b6:a03:33d:cafe::d5) by SJ0PR05CA0131.outlook.office365.com (2603:10b6:a03:33d::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.9 via Frontend Transport; Wed, 21 Jan 2026 15:14:00 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by MWH0EPF000A6734.mail.protection.outlook.com (10.167.249.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Wed, 21 Jan 2026 15:13: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; Wed, 21 Jan 2026 09:13:53 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d2dace9a-f6db-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jLIq2Hm4ZG+f99+mZb/W7TyqRT1FHjZ3+m1dzGNThKhzJAb4A6xR72QYs1+jaraac82Ys4NXODCmXwZzSSJ0MqyNJt41BDAo0t2K4ZV8BAoecl4OBfbBrJTam64tCq8ou64wp/Nn1RHqt7ZyAReogjLMXjjk2awZm7/aSWkPca/BCjx3/RUuOWuzY6vs4GybqwauUnabgeOWzwS8ClW9baHOe1mDk8YHMxn7Km65ZkJzo2fSH0y5JXz9pmGXalLkdA94HlZbwJGpD+B/qlEKCyjOXkN5k96q1rg7IgnKvs3uQm3dQmVNIG0qYboYriDqBJNpohILV19WOmbxbehyQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bLvqchy5GUHxBItgzBiidBSNDV6sdsLnkBQ6qcWBSDw=; b=xJB79TGwugCzWJhb7TSeiC+lvB+ma8lgLMw+mnWOPUWptXmKOX7BLq3mcKGtkrqnA6CWfy1TtPiQ0z/hl+ogpKFfTla15eRfRJ3det8UmCPzAJxCiawiapp7YmXyIZFrJ5b4cJL97kxjgo4ttR5NxNVVwVZd+bHjbVO6tA2iBJS/c+OG3kBNPUW64B+SMDvJdNTeL0VRRc4lHL8RWin9HMPiBrwGuV2zfb9QFWJJXB/wqSKxUid6WhcSKB3nVw2r7qGJsyYRWrkLMyxuBylHaLr/98jC4ctaE1Gd22ynWZyE0rrBAGZkCJDX3KVb/FDhiIWUZ0DUft3CTvABdBV/UQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bLvqchy5GUHxBItgzBiidBSNDV6sdsLnkBQ6qcWBSDw=; b=3ZGuqqb5Jh7iB3zXzPyuiVajwr0lLsMJRc94SUUZhW3rA21BxrwBtayF59E9eEzKtBify618GWKF0F3DCHCIbIPpz/M+Lf27BFZFYMmEUu/HHyEViYQ6A5Twgd5Eq5q9t9qMjlUwp/NyK0gayna4bbKUfp0M2nfZTybp90oz8s8= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 21 Jan 2026 16:13:51 +0100 Message-ID: To: Alejandro Vallejo , CC: Jan Beulich , Andrew Cooper , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: Re: [PATCH v2 1/3] x86/svm: Add infrastructure for Bus Lock Threshold From: Alejandro Vallejo X-Mailer: aerc 0.20.1 References: <20260121142857.39069-1-alejandro.garciavallejo@amd.com> <20260121142857.39069-2-alejandro.garciavallejo@amd.com> In-Reply-To: <20260121142857.39069-2-alejandro.garciavallejo@amd.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: MWH0EPF000A6734:EE_|LV2PR12MB5920:EE_ X-MS-Office365-Filtering-Correlation-Id: 83b471ce-d714-48ab-147e-08de58ffb2c4 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?TEhZQ3k5ZlBpNDY5KytzVCtYUXpWZVcwSGJGSmF2Z3B0RFo5Zk1zK3ZZYXdy?= =?utf-8?B?OWNMaUZEUjRoUmZqLzRvbG0relBHVUplSXJ1Z1FyVEpXUUlPdDk2UDhtWnNl?= =?utf-8?B?cHlWaFRtempSbDhOOVRSYWhGMTdLWS9QOVFoRlQ1ZTg5b1NnRUIyWDJIdUFw?= =?utf-8?B?T0lhVUV4M2E2NTRaUDhOY2pRZVVGOElDSXQ5dDQ3U3ErVmwwTWNXY0ZyTFQ0?= =?utf-8?B?cTFtVUdTRHJlR0FIYXd5SXVsNklHTS90eVF5WmR0cGd2NEtIWnhlTXJaZmNs?= =?utf-8?B?VllCQUVBcTZFUkU3K2tqRXBEN29sYkp3ZENJa3JYZDlpLzUvcHFqeTlSdW5Z?= =?utf-8?B?VVR0YUxLTXo3MVlFTjdGMktkLy8wVjlMNTA0dmRtUTRyK2hVS1pVR2VBNTF1?= =?utf-8?B?U25salk4a0JvSXBNYXdzTDlrM01tbUJhZkEyaHVmR0JlaGJKeHA4OS8rdmVW?= =?utf-8?B?SVR2RHNBUWYyczBvdmVES2h0TmdPeTcwUjdnMDJ6TlpTYnE2ZnMxWlBoZ1pD?= =?utf-8?B?dXd5MWhiSGFaWFV6NjBVLzJ2bUlZeVpwcS9URjd4VzV3K0xGeWFFWTRVUTJ6?= =?utf-8?B?dEtCMi9YRUlQTkZFUmdycGsvN093c0FLM1VzT1ZMTkc1anh3R1dJSnU5SUgy?= =?utf-8?B?Zm5aVngxWEZkQk93czJscFl4MXJCeFA1VWhHNnRnQTBFbjg2a0dCbXUxeW53?= =?utf-8?B?SkMvSzROa2hhajhMdTg3bGJzTVphdFdGcm1GMUtxZWFWVC84S2RJK0lMdkhM?= =?utf-8?B?a2cwZ2JrZGk1TmFkY2MwczFqcGpwbVBXNWpkK3ZmcW15c09CUDdkbmVIQXZ4?= =?utf-8?B?NDBFK0owZGdObTdPY0lFQURaZkc4bnQyT0FHeGpnZWU0K2FZMmRSSmc5Sk8z?= =?utf-8?B?TS9ZUnRidWp0Vng0UmlsSnVmOEJZeVBZdm1GTHZYVWYwVmVYNHlhUStqZExY?= =?utf-8?B?V3orZVVGcGRoYUZOWTlXNlA4d0FBYkoybEVFZDZSZExqTW1ER1NNNWZPUnpH?= =?utf-8?B?SE1vRFBZTHkzM0YrWlMwQ2FjcnNzZW5GWnJjZmpObDlveXRQeFBEM3dHaVRU?= =?utf-8?B?d01hVkZlOUZlamV4R1A3MnpDSzVwVmhRQVk5eDlJcXVScGRTZmx6cUtkN2Zu?= =?utf-8?B?UnBqd3VmdkFhT0JteWVod1NFazBDU1IxalkyU3dtWWFGRFlkcGFZQVpuamxG?= =?utf-8?B?akdxTlhobVV2U0xRQXBRNWJONmVxcnNUNmdvbmFQL3JDVXpOeDVPOWVteFlF?= =?utf-8?B?SkprT3lTZHMwQjhjM0p2TVVRS3J2YTNaS1NkU3d5d0hUbzhDaWcvdjZhUkVz?= =?utf-8?B?b1FjQ1V3R3pRM3RBc0cxOVBWZjU1ZXI2bnI3d1dVdmtZYWhsV3hLYUdOZXVt?= =?utf-8?B?cGxydHdHU0VTSm9mV01UWTBlcEYvTk5kd0NYakRYVFUxOGlWTURkOERJUXc5?= =?utf-8?B?VWl0UWJkeEsyS2JJeHY4NXlXZUVHbUZJYXlCNFNqOHp2TTlEaFIzUTlVU3ZG?= =?utf-8?B?bmVTT2ZqcmZqUElnVzRIYis5cEk0RHY4cmZDTFdJZEMrMmxDV05YL2kwczRh?= =?utf-8?B?UUNaenlSYlYybFp1aE9QWFF3RU1NUWxHV3JBVVRGT0tWcExyNjdadWdraTNt?= =?utf-8?B?cUJ4N3ZMUUd2b3R5SWJVWDFrTUVGZ2FHUGVvRTdYdzZWVDFhTjRBeEdiODBC?= =?utf-8?B?YmdMSWNpSEtQMCs5TlRPZTkwQTMwY3lMR2tzNmNaZ1BXeW51dThNY0lkS3ZV?= =?utf-8?B?Zm5FcWZrUktmcHZmTGsyc0w3MG9Scm1EbEJoUWJManptemY2MGlqckJJTStx?= =?utf-8?B?YUxmQ3ZlTkdzVUV6ZS90akVXc1g0TmVOWFFSZ1NvZ2J1aThsWmtxTVN6L3Bw?= =?utf-8?B?QWdINTFTR3ZoY2FRVHdQWDZ6MGliZlVrRllpU0JiUFllakdCNURoNzRycGxj?= =?utf-8?B?NmVQMUNPdTlJRlRnd0lEVTBZMVZOYTd3aytPUjFYaU84UmxqREo3NE1uTTBM?= =?utf-8?B?Y1BkeWF6WlZ0NE9paG91dnBZd0NLdE5JTGZ2OFJTVFNCbTZZWmpaN3FUZTFj?= =?utf-8?B?bFFwNUVROVgySGhISi9MRVNJbDJ2aUxOaEJFL3NrQ2RzTlRWRGwvQ0VINzZ3?= =?utf-8?B?ci91V2E5cy9sNC9uN0NDbzdUaW1ERFJ3Wm5NWmx0L29IU0h4aG1UM2pTcnN3?= =?utf-8?B?bVpuTTRMdVdzajBScVBlOHlaalY5QWJyNmJCcTEyS1JZOFVpUzU4d2RUeHBl?= =?utf-8?B?Wko0bHhBbld4ZERTSmRqWXdWd2NRPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(1800799024)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 15:13:57.0953 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 83b471ce-d714-48ab-147e-08de58ffb2c4 X-MS-Exchange-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: MWH0EPF000A6734.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR12MB5920 On Wed Jan 21, 2026 at 3:28 PM CET, Alejandro Vallejo wrote: > Add missing scaffolding to enable BusLock Threshold. That is: > > * Add general_intercepts_3. > * Add missing VMEXIT > * Adjust NPF perf counter base to immediately after the buslock counter > > Signed-off-by: Alejandro Vallejo > Reviewed-by: Teddy Astie > --- > v2: > * s/general intercepts 2/general intercepts 3/ > * removed _thresh suffix > * added missing _svm_ infix in the SVM feature > --- > xen/arch/x86/hvm/svm/vmcb.h | 15 +++++++++++++-- > xen/arch/x86/include/asm/hvm/svm.h | 2 ++ > xen/arch/x86/include/asm/perfc_defn.h | 2 +- > 3 files changed, 16 insertions(+), 3 deletions(-) > > diff --git a/xen/arch/x86/hvm/svm/vmcb.h b/xen/arch/x86/hvm/svm/vmcb.h > index ba554a9644..231f9b1b06 100644 > --- a/xen/arch/x86/hvm/svm/vmcb.h > +++ b/xen/arch/x86/hvm/svm/vmcb.h > @@ -65,6 +65,11 @@ enum GenericIntercept2bits > GENERAL2_INTERCEPT_RDPRU =3D 1 << 14, > }; > =20 > +/* general 3 intercepts */ I had already sent v2 by the time I noticed the request to capitalise G. Fe= el free to fix on commit or let me know to resend. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Wed Jan 21 15:25:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 15:25:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209904.1521781 (Exim 4.92) (envelope-from ) id 1via4g-0007pD-7G; Wed, 21 Jan 2026 15:24:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209904.1521781; Wed, 21 Jan 2026 15: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 1via4g-0007p6-47; Wed, 21 Jan 2026 15:24:50 +0000 Received: by outflank-mailman (input) for mailman id 1209904; Wed, 21 Jan 2026 15:24: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 1via4f-0007p0-E0 for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 15:24:49 +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 5176f14a-f6dd-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 16:24:46 +0100 (CET) Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-42fbbc3df8fso3924600f8f.2 for ; Wed, 21 Jan 2026 07:24:46 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4356992c6f2sm35956454f8f.19.2026.01.21.07.24.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jan 2026 07:24:45 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5176f14a-f6dd-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769009086; x=1769613886; 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=RZTtEpTOESTRhjvdUIXoliaEt16A7QryGKFv1Djsn9s=; b=H5liwMET1tmWIf9E6zfbuFBFByZTs4JeX3Dm6scJbK4xdia3di2DgeYg3j24h9hA+P 8e/H99msMxFYbxElM1zprhi8yIqu7qXFNINRwr4WSEXDn1qEpkbFHg8D8Vcl0FoSiyFd H/WZHSBr5nNFFhqjTxPfkmgs+7t/kc3STKmeq2yY4DDQrkjiNBwjbn70lfe5CO3h4rzf LU/tBkJp4D1sqyy70np78+jhDIpGMNYQRdUVYnwZPv9tkfme4A37n7toHJ+8d6JTpFwy nYsrCv86yn3WtO/ZRKMiZjz4VbGTDnx8zy1JBS1/7ncXQXE257trO0Hv0vI+FlavHf+I xDWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769009086; x=1769613886; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RZTtEpTOESTRhjvdUIXoliaEt16A7QryGKFv1Djsn9s=; b=aPGnEZdbIPmiC5hW8DhIHH9RzcfFbRyb8XXbisGNZY0OPDR+GYcU3QUArW2n8WNWPe 3TSx9nTy+1JUCrE/uxKsqkvOVFhhzvX8NZ6ypDTrdYlhj9B6tUflWTDO89glKWulyODf i1d5s7T55jlnjx8P12+eDD6EKw/Y4Izk7YPm0grWTj+U7CwgmQx/JnmSmyDOPlRUNWHp 0SOcCigYPixIwpvG4kg1ytFCv9CD5wVaDSkD1vMfHVqJGwhyYdN0rR0kKJ14HMxXJXgB qWyB2CI8xScP+HiyMu0AcQd3cjNiBGv3o+4lib5FouxZCcCkUKm6nCpmRNB5MUcfCuwe g/Pg== X-Gm-Message-State: AOJu0YyJoRu2lt1ynOvlTnjwpQxgu3qDsKh0tZWCoaOtzokmnMSv0oP/ cZFmtHxS6AVrBTK1E5W3+ro4vT7eVRA/yNDppfwFh6A3ys/8wcyHdg1F9fNx0K7yyfZDsxrLEtn Id+k= X-Gm-Gg: AZuq6aJvc6wSqp6OaPc9VA6LPD+6gcIOdQdYfSQql3RF5/8dBcGWC2Hw3l/0PrTh5IW oY7Ma9dI4DFAi6BId7y1hKvUumTSxAt8msiyHKa8LGkwK0CK72nGIE8moNvvN/09nLib0C/WMcC p6k3+QNuR4cVYl84X8Tq27nlsRD8gmpCNOOm8MHkS+XowHpud8yItp3s+bot1vHz9Me18Nec802 uZ4dp6wcW7DIUYUg7zROQCe466dbNFYzbZrLusLW/60evVKvgtYjuY8gUBgpQSOzC8fIqTgrg1D veXTmQfnHz9lVcM6ILDjzIqk3+RzhwZSXCjoTXciGSxOCSMgvl6hJLyffBj6g9MzHdRKOXW26pM GAcVykVqwPT0BTxSprF/M4QQhr50rvtKOch6KUMjKmE855euX3xwHckiDTtkUvnI8i7GsJlNQel ggx71gyIHqbPFBkOl7UBDcW8QWjMvQtphB5l9nWJ7wsx1IA/W25yTOCvnp8L9vQFjKjtx2j/P2A uw= X-Received: by 2002:a05:6000:18a8:b0:431:fc:694a with SMTP id ffacd0b85a97d-4358ff3f160mr9211207f8f.12.1769009085753; Wed, 21 Jan 2026 07:24:45 -0800 (PST) Message-ID: <980b3fe5-ce30-449b-8e0b-d0f6e91dc688@suse.com> Date: Wed, 21 Jan 2026 16:24:43 +0100 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: ensure sorting by value yields reproducible outcome Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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 qsort() implementations have freedom towards actions taken when two items compare equal. The latest with the introduction of fake "end" symbols, inconsistent sorting between the 1st and 2nd run can lead to extra "end" symbols in one of the runs, making the resulting symbol table partly unusable. (Note in particular that --warn-dup or --error-dup are passed only on the 2nd run, and only for xen.syms, and that option has the effect of doing a name sort ahead of doing the address sort. I.e. the inputs to the 2nd qsort() are pretty different between the 1st and 2nd runs.) Make the result stable by using original order to break ties. Fixes: d3b637fba31b ("symbols: arrange to know where functions end") Reported-by: Roger Pau Monné Signed-off-by: Jan Beulich --- I can't exclude the unreliable sorting could have other bad effects, in which case some much older commit would likely need referencing by Fixes:. --- a/xen/tools/symbols.c +++ b/xen/tools/symbols.c @@ -40,6 +40,7 @@ struct sym_entry { unsigned long long addr; unsigned long size; unsigned int len; + unsigned int orig_idx; unsigned char *sym; char *orig_symbol; unsigned int addr_idx; @@ -247,6 +248,9 @@ static void read_map(FILE *in) exit (1); } } + + table[table_cnt].orig_idx = table_cnt; + if (read_symbol(in, &table[table_cnt]) == 0) table_cnt++; } @@ -639,7 +643,11 @@ static int compare_value(const void *p1, return -1; if (isupper(*sym2->sym)) return +1; - return 0; + + /* Explicitly request "keep original order" otherwise. */ + if (sym1->orig_idx < sym2->orig_idx) + return -1; + return sym1->orig_idx > sym2->orig_idx; } static int compare_name(const void *p1, const void *p2) From xen-devel-bounces@lists.xenproject.org Wed Jan 21 15:26:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 15:26:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209911.1521793 (Exim 4.92) (envelope-from ) id 1via5y-0008Ih-I7; Wed, 21 Jan 2026 15:26:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209911.1521793; Wed, 21 Jan 2026 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 1via5y-0008Ia-DL; Wed, 21 Jan 2026 15:26:10 +0000 Received: by outflank-mailman (input) for mailman id 1209911; Wed, 21 Jan 2026 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 1via5x-0008IQ-DX for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 15:26:09 +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 80e7860b-f6dd-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 16:26:07 +0100 (CET) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-4327555464cso3652196f8f.1 for ; Wed, 21 Jan 2026 07:26:06 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43569921dddsm38605495f8f.6.2026.01.21.07.26.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jan 2026 07:26:05 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 80e7860b-f6dd-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769009165; x=1769613965; 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=eSECRAgdJ7kh97tI1tfVcwsS2/Sh8RoFc4OEZoh/Wu0=; b=aHk3NoDL62knARGgtdwwq1BBypHfzxsby73koXeqYOcS+qIY5BcUd2ghM3VW4paB6V QL+1deMNKlZZFWcAgXverBDaGj8T2/5HmAbKOQFYNJ89RoDljX/+u8lZi7V5v/sLU4HW W6/eM7OaJ0jgi07YnDMz9ngrhLTlQx+XGXjiyJYK26+ceVBEW08/17SU+09UfemSneLp LAVy6kf09TSFWDT3wKnjsMXv/oIHDAedPRtIfc0MbjVkOgm4n/dSK3/Oc5n2JFTWHJYQ N+azcuDgO9CovDaRiUIRRhZSltGeqTrCxF9WRkUBPpTxfUlhQrdhZwTGXfICmwFQeqm5 LuFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769009165; x=1769613965; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=eSECRAgdJ7kh97tI1tfVcwsS2/Sh8RoFc4OEZoh/Wu0=; b=b+eWzN4uQUxvjxY51ftugMtBqxGRLVbacvw89d/MZVdo2RYS5iN3ljhzjxEvH9TIUa JeGNoGgRyqeDuorxqB+PKM3QtvgMtT6mAS49a9UrJxiDYUi+LPtFLzRdBxmpaZrgquFa oBaZQXIXmw2qbjA+XFYOpU6qOTJbDQXiaf5LBAWInNwwguXVvHDm8r8D9bYXuEw+cQgC 01e68y/JgHdiCxbks/tQMn4/ILLC2KUU833MWhkdGxT8JBz4aQFesuZVddPgLNGx1Y6d p3dK4X1JCkA4KL7huYTbYzfMiksXcves6hHB799H3K8R+D2mP4ehMXfgUmtdxXSDnDr9 BN/A== X-Gm-Message-State: AOJu0YwpOXmGfRx5Ew62nD45aAhDk0yi8gf8qE6ugo3BegAZE0rf8xxj 7M+vgH47bFppGMO0mEzaLPcrMWmJadoDV6sPDBgd8gKt7ol6RjX/had3g4ylphSE12ddJ3pgNq3 zCd8= X-Gm-Gg: AZuq6aLb8UHoPzFr5mnRaalTe0sN0saEipKGNOcCveSNthk+pVkd6TLeuebE42RVIUS EoXLqXtD37wIYeMcZ9ayWYOLJ/MGvBWIgqbyMynLDm/8mBQ5ZBkLb0pvaT6n61inkcb5cCoMboS AwL7KC2twtCYu5htL99nXTxG3Cx1uACcMBE+bVn7AAImj/UZwy3W9hz/ksicYiBkiSM4BElpb9m v31MF3WtHRno2eTtm2GYhf8QFCniYuhjLf7xBZztgUReg+3rCDVV/4+2CL60+kKUj5QSDwks//U 5ODBZzHSKALEDom9ophNTuVpruXu9chclFWHc038vOjrjQqeQ/m6p3PSSlvrniez/iUEuEJVPqu tLgpkK3SImPm8opuxvaIgR7LdwGIE8egDcIawnScs9TJR4NlrupPnOplpZPabLZeF2F0v1kSQD8 TpLuLsq5dAV8qjQ6gVTidtsLDmDbfv5Mv9bI6/+B5Sp/5WtTEGA9zQRn6+GB9xv31MK1t2zXYfd sw= X-Received: by 2002:a05:600c:a412:b0:479:3a86:dc1d with SMTP id 5b1f17b1804b1-4803f2a438fmr65180595e9.37.1769009165525; Wed, 21 Jan 2026 07:26:05 -0800 (PST) Message-ID: <9dc297d2-08f1-460a-b513-91deaecbd2d4@suse.com> Date: Wed, 21 Jan 2026 16:26:03 +0100 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: don't omit "end" symbols upon mixed code / data aliases Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit At the example of _sinitext - that symbol has four aliases on x86: __init_begin, __2M_init_start, __2M_rodata_end, and whatever the first function in .init.text. With the GNU toolchain all of them are marked 'T' or 't'. With Clang/LLVM, however, some are marked 'r'. Since, to save space, we want fake "end" symbols only for text, right now want_symbol_end() has a respective check. That is getting in the way, however, when the final of those symbols is 'r'. Remove the check and instead zap the size for anything that is non-code. Fixes: 6eede548df21 ('symbols: avoid emitting "end" symbols for data items') Signed-off-by: Jan Beulich --- Roger, just fyi that I think that this change would mask the other issue that you reported, without actually adressing the underlying problem. Hence both changes will be wanted. --- a/xen/tools/symbols.c +++ b/xen/tools/symbols.c @@ -164,6 +164,10 @@ static int read_symbol(FILE *in, struct else if (str[0] == '$') goto skip_tail; + /* We want fake "end" symbols only for text / code. */ + if (toupper((uint8_t)stype) != 'T') + s->size = 0; + /* include the type field in the symbol name, so that it gets * compressed together */ s->len = strlen(str) + 1; @@ -312,7 +316,6 @@ static int compare_name_orig(const void static bool want_symbol_end(unsigned int idx) { return table[idx].size && - toupper(table[idx].type) == 'T' && (idx + 1 == table_cnt || table[idx].addr + table[idx].size < table[idx + 1].addr); } From xen-devel-bounces@lists.xenproject.org Wed Jan 21 15:36:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 15:36:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209929.1521806 (Exim 4.92) (envelope-from ) id 1viaFC-0001ij-DJ; Wed, 21 Jan 2026 15:35:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209929.1521806; Wed, 21 Jan 2026 15:35:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viaFC-0001ic-9B; Wed, 21 Jan 2026 15:35:42 +0000 Received: by outflank-mailman (input) for mailman id 1209929; Wed, 21 Jan 2026 15:35:41 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viaFB-0001iW-86 for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 15:35:41 +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 d5c1711d-f6de-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 16:35:39 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA3PR03MB8352.namprd03.prod.outlook.com (2603:10b6:806:466::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Wed, 21 Jan 2026 15:35:35 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Wed, 21 Jan 2026 15:35:35 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d5c1711d-f6de-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=htBiYI/ER1F0xunbZzb1Tkn4wBzO1uQ/m7pfUn01484tE+J+Olyfi+Nrx5qo4LH+uEDHX4bE3ImckFWJWQPz/9Y3apDQOuzgI/hIcD82zu4pQ1eIYlz8D1CMcsEfC+X6ePwW6JfqUbkcJDGCZa0Yfu+3juEvJUfOC7hO8RMVoAPL7nonNBQtttlKDUT1MtOaN73+LPF38wSNlpGPmblLMjc9H/cqoKBe/Xfu5QMBbcn9H3DW3Il4P8dCkNcWwpxWCjo37VHKGEtsncqwsQaeUZNVAdT75u6ChULn/MxIz3cpxnaDvPEAT/driWQ7GhsgIDPTnPQTQ5mebul4od6kXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rRoU1iEdKjIswk6mIvdZfWB7lGau8bj22VbTsylW6mY=; b=rmv3BjovLBFDhYJUQ0PRL7XBs89oiCH61Ln31GoQsFI/mVOe+OzBkWE1FMFraJoOqjnDdc3r8VaSk5VQSbfS34wBGLBsBhBEzI9Akx516MYXnHI7qM2P+9sc73Ccd43ZzOOQXPu3knsOKWY+wyAnjuBLvnHjbjFzo7L6DVr2NpqIPTIJkQs1bU63hiZlb9we4ROZpArgu3YRVuPv5rMFZ4fxmhCmNpPYJJCihvrLTuRr0+xQQOyncI0ckrt5dImAL8w+m3cFVgecSkYyfnjPzgDedIrNVEiqpvI/xDKkmvvR66GjwP8MncypsyT3pw5ig+hVyms12YPt0OrMQiAu5g== 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=rRoU1iEdKjIswk6mIvdZfWB7lGau8bj22VbTsylW6mY=; b=gl34fVAk4AdmxabzYU8WZrSiBLYdhmr+qYKofQXZASyL3xyVv/PU5h/axEyHi02OoqqADhsZ75iaUrtGBOy7gjMkuRg+c9A20mkF8o46W+ut5NSImILK9Tp5/qYk+w1hS8yPfWqpoci4HU2Fx99dhrAqxq08zXeKFvOlK/UWmTo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <7fbc3acf-b878-4a82-bc08-89b91fb9aca6@citrix.com> Date: Wed, 21 Jan 2026 15:35:32 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk Subject: Re: [PATCH v2 2/3] x86/svm: Intercept Bus Locks for HVM guests To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260121142857.39069-1-alejandro.garciavallejo@amd.com> <20260121142857.39069-3-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260121142857.39069-3-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0043.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2ac::22) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA3PR03MB8352:EE_ X-MS-Office365-Filtering-Correlation-Id: 6cbfa8da-f453-4267-d379-08de5902b8be 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?d25YZEZnb2J4RjYrMHB2NWJ1WmZXc3VnM0NiazFnVkI2V1NtT0Q5eDkxdzgx?= =?utf-8?B?TXRRVXdaTUFzL21kdWNLUmRCK0ZIWnlQQXZ1UldyNWtjTlI5SE9COXJmMkFj?= =?utf-8?B?WTdCQ1plRjJubkgxRy9KTG1hYUFjTTJKVlFyc1pJeXo3QXVwOG5KUjEvSnNY?= =?utf-8?B?ejVWcjZJTzFnbVVJQXdKUWxaR0tQcUFTd1FGYzNieTVwaTdlMWNmUHRmamJu?= =?utf-8?B?TGMva2orc1hEVSs1VXh1Y0ZESEduNXZhTHpUNFVPb0cvYnRLdFd4SjRxMjEx?= =?utf-8?B?N2tMcThZTU9IMlF2MnM0cU1VVmVveGpoOExGTU82TzJZNUViaU5yOElvYjVS?= =?utf-8?B?NGw5NEZ1eTdnWUdiM0Nyemh1WGtRaTRqbVNPdkszc1BDVkdQY2tJamVHOXc0?= =?utf-8?B?OE9adWZ2ZDNuOVliNjgzd2ZiaXQxN21ZdXA2aHExU2tSa2NpRnYzRVBrWFY0?= =?utf-8?B?aWhYeFh2d1AzeXJMVHI0NzlLeENqc3dHVzU2NHFiQVJzcVVjSzNTYWovSmhv?= =?utf-8?B?MzA2Ri91WVJsTFk1SFJic2R1eElObDZ6OUYwMEw3ZzZJRThMZjIrU0o1Q0hz?= =?utf-8?B?cDFiN0diRUVXOVRoYVc5cHdUVUl6bU95VXoxZ2tONEdhTXFRMlpLcjlZT0hp?= =?utf-8?B?SGpBN3VsQktXY2tIRDJjMFkxeXJmb01INGpHQTl4THBDeDRneWhXK2NJZzY1?= =?utf-8?B?RTRyVkNBU1h1dm1kVzc4NkxSSFhpd25WeitoRzJoa3NKenNkQXNKdUZ1cDVK?= =?utf-8?B?b0xZUUdBK081KzZBcGRWMmV1d1g1Q2NVb1lOQmZyMUU1T1FpNlpkc2wxeHQ2?= =?utf-8?B?YUZXcWcrb0VTak9hRjlUb0lmMGgwaG9ON3RXSGp6T2Q4R3dwQmFFM0o0RUd6?= =?utf-8?B?RHRLbngxdmNiU2ZPdTZCUGhFQk5ZWFZMb1NTMStFN1k4Y3VDY0hpQWxCZlNy?= =?utf-8?B?cGw5TVhGTXV3dS9DZGxBajlBSXptN050T3k4VENzNEtWSnlyVmFhb0hvRTJC?= =?utf-8?B?emUrMUZVZlZ3NStiNkNTUEc1UzYvOFYyUE5WdEhaazRmblhpZUpkNW1KSENP?= =?utf-8?B?ZTcxNDh2eCtlUEQ4dmpsVGxFYzI1MWdDc0hyRkExYWFVcUdwZlRlYTFaNXY4?= =?utf-8?B?VWE4VlhIK1BJWW9LcU1Hd2VsY09tZkFCaWU3RWl1TERTdFhVeXo2bml3amZS?= =?utf-8?B?Wmp5ODVpR3NqdWl3WmdmdTBDamd0VThKdDZqQXB0eHlpQ1hMMElLeHlyZ1VH?= =?utf-8?B?Myt1UFpQYlBWNzgzZG5QUDNTZzl2MkVKWk9XV1RCejcyU0lFTHM3MWZTQVhj?= =?utf-8?B?b0kzSGl4TUo5bjRGc0tCTmk0bExPZkdQMHNBYmcyKzJpM0lMWXIxMW41MjdQ?= =?utf-8?B?OTlvSmdZcFpoU2NrRXppOU00T2JlVnJYTG9udmZFT2gwQUczOVFFaVF2ekRJ?= =?utf-8?B?R3RCdVJ0ZlRIZmZTbGpPRUhaUEZqQU9RY1BoczVyeUdWWURtbFRoVDJnRi9W?= =?utf-8?B?WTZpeXJMR0NkRmRBUFBYb2RqNnNWR0xVMTZuNEI5bkNvRUlxa3U1YUw4SW9Y?= =?utf-8?B?T2h3ZEpqVSt5UjEzbkQ3RWpvM1VIcXNVQkliaUw5M0lIbUE0VEwyS3dpTis0?= =?utf-8?B?RkNjcHIyQ1BQQWIxa2JSNWI3aVlYMG5QMzQzbmd0WFk5RVpnRWFCeWZtVnF2?= =?utf-8?B?R0ZDQ09CQ1EwdEE3ZWNXL3Fjek5veVZQLy9PaVNaMGRrbmNqRlY2d3huODhV?= =?utf-8?B?dnQzQjJyTE9naGV3OWxTYlVVTWlqdkJYb3JBeC9RWDQ5bG51dFVaVG9DcTF5?= =?utf-8?B?VlQrTC9aZjVVNGlvelpzRkUyK2lQVjRwL1V4c2grTjhZcTlrN0luVjRUaHpW?= =?utf-8?B?VWVOV2dlY3hSblVzdlNaUzNrM1d2eUJybzh3VE45V3kzWXl0bmZVTkdnRXd3?= =?utf-8?B?VE1mczI1WGZMYTJZdmd1dFRORUNHWW5jUmJnY1hwOUdlV1V2VzNRQ0RuQk9M?= =?utf-8?B?Smt3Y0taWWxwcjFEK3c4TFJhTE9IQVhFakRJNkNhS3A0RFhoWkpUTlNkaTVB?= =?utf-8?B?QXdLaDRlZUFBRTlRZEVucVl5TVYzZGVYdkcxYlY1dlJSYkg0OXBZUjFXWWo1?= =?utf-8?Q?jwe8=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VGJZRFpuSnZTYWxBT0tjd0ZJQzM0ci80RjZBUXg4TERsREIxOWlsaUR0dWdD?= =?utf-8?B?cHFLUzhkdStnSUFwNnlUOWVKbzdZUTdEZkZBYVJFNmZnRTVRbEJOZENxQ0pp?= =?utf-8?B?NzMrcVVkTnNHUUltc1FBUGpUQUluWG5obnhVUzZSRnlpbzI1eDh6REk2S1FZ?= =?utf-8?B?SHVmSG10RHRNcWw4dFpZU0d5d3BHVzU5b3IraWFBUXgwaERTSTF4ZHM3SnJy?= =?utf-8?B?dXp5L1ZhZGNYSDJ6dlBYOVBFb3E0dTYvU1NUYnVoVjBUZEQ3aHhUUXozcGNn?= =?utf-8?B?M2lkSHVVaERoRHE4cDU1VW1KR1VGOFJ5Z1dWZmxBWG9ON1R1elcvL3UvN1hj?= =?utf-8?B?ZmY0OU92OVUyYmFaTjBPUFBGS3JXS0lOdWwrdC9rTzBONVVEQXVEenZ5TWVU?= =?utf-8?B?NGRGakJRNk9KaExVMjZpbWpyZnYwckhQWUNWMlV6WjcwdElDZUpEZktqSUJN?= =?utf-8?B?L1hyeW9SWmpkTDJqQWFTdDJ0NDBzK3RWWm5wdUxUOC9Ydy9xUWRwK1Jyb1BQ?= =?utf-8?B?N043M3ByeS9aQlRrMFlwS2V0UlJwcm5sbklFVDJEOGJwMHFEdWl4YWVVWVhz?= =?utf-8?B?d3ZLUGg5MTBLeHI2R2RoL3pNYWNFVDAyanZsNzhtRHJsMUs3b3FRWFpBRTkx?= =?utf-8?B?Y0p2MWc5R29MMzhiQWM4Mjh2SVVqOGxSSVRxVFhFZHBiR05BWkpxeENkQ00x?= =?utf-8?B?eWF3dnRkMmUrQTJUZXJHV2pEV05NcXRsUG8zMWZIVXROUTViWmNva2xZSDFT?= =?utf-8?B?MDM5TVNsRUVvbGc3Y1BYUHd2UDVvV0p2MWVDL1hSNUxMcHIwa2JablVMaERj?= =?utf-8?B?VFVWdFNuaURLZ3BCcTBVc0ovOEdDSmJuTkpqdUJNV2QzOUluQ3dZM2tzOU1M?= =?utf-8?B?UDMxaHA2bTZYekZRT1BoT1B1N1VuQnJjMkt6cWc5eUdjeEhFWCtUd2hxOStr?= =?utf-8?B?TnRtRG5yMXlWa3NySy9Ka01xL1J5ajRBZ2RFVTlBckRta0JYa29kYVRKYjhj?= =?utf-8?B?VDlTMXdaeVkxYk9PdHcrTDQ3cTZDQUJYdWRmWFhzTWtlbUxRdW1uTUNDaVZs?= =?utf-8?B?SXpOYThObkIyRmR1ZWdJemFLZlhSQmYxQTJmdWlSa2xGSU1yTno0dHVvWjg4?= =?utf-8?B?Z3VGWlNGQTZKZExwMWpLclMxdXF4NGVRMFJBczlja1BsWitMamtid00wTFFX?= =?utf-8?B?UkM4d2EwOFIrVzRQRTdXeXJFeDJFMTVPclNpMmtnM2JRbGdtUi94WWtMa2Fr?= =?utf-8?B?blJSZG5qRVhXVVovVWxSaVE3Wko2cndIRXBiUVRrNW1pUXVjTHJsdEl4NUJR?= =?utf-8?B?UGhabEQwNTIyVzNnQnhDRTlKVC9MNlJ5UnRFZXJCYWJrVE1JV2o0cEVnMmtk?= =?utf-8?B?VTNPZkUrL2hieGVNVmJ6RU45TzByallPR0lzTGVmdjJLVCtub3Q4K1ZOcysv?= =?utf-8?B?VXN1NlVUOVhNV0xmaG1sYUszeXBHWmtMTytjUURFM3RQTzJLT1VRUWprUjBm?= =?utf-8?B?UW1NVDYwUlhlV1BtWm1UOHhtUmhDNEpSQWxJcjlxN2xtbWpuN1RiSVN2R3Bl?= =?utf-8?B?QjRna0t1YnFvZi9NWDNEci9EbzJySjVvdWdIOFpOQWVyMzNuVHhsYVBzaUd6?= =?utf-8?B?K0pZdXdTN2puMTBQay8waXlYdUorcERMdUR0R2F6bHJhYS8xT0d1Mys3Slk2?= =?utf-8?B?Q2FsTzNoa2Y4SW9nVCtMclJWQ3RqVEZ6UmpkU2p5b3ZnQ09kaGpCY2E2NzdG?= =?utf-8?B?ZzRlUUFMSXUrV1VoNjQ3Z1VJR1BteUlJTmlSYVNUY3BEd2FiSG5QZCtDN3dF?= =?utf-8?B?SElRcXRUVGNBTGpiSk1ZajlpT1NJakJ3SlhZenptOWtROG1uNFdCV2swazJM?= =?utf-8?B?NjArUWRlMVRhVU8yQ1FEdkpSTWVPVHVkd2l3dWgyQjRrTENWSzdEZkQzd1V1?= =?utf-8?B?bFVIU2Rheit0YTk1T1duOTdXSWxnczkybEM2ZWVqbG5DMXFSQTBWcnptWmhZ?= =?utf-8?B?cFVwRWR6aVBYVTlISEpnMFV3b3pkcU16TktocHZ0NmN1S2ZDb2J6VlVBVGJP?= =?utf-8?B?SDk4eDkwMHc5NW1qYkFCWHlocVh2bVloK0wrd3libUc2Vml1azVLRS9uOTZ4?= =?utf-8?B?QnpnQ3BiNnRseU00WWtNOHpham9wc2IrYk9CVk9udzZXUUFhSENlY2NlWmUr?= =?utf-8?B?d0MxUDc1anZ0L3NSUjFmdDkvK0Y4N1NadnUzT1F6TUxnbGQ3eTJSY0x3VFBn?= =?utf-8?B?T1dNT1dYSkVvWExEVFAwU2tvUjN0NTJ1cW5HVGZST0E5dmdXL3NHc0ZqaEsx?= =?utf-8?B?Uit1czRueHl3VkdqU3gxVkh0RFNYcTRpYlgvRHE3KzBJWlpRV2RXTW9PclZi?= =?utf-8?Q?DeLPpNEG0WsmoQgs=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6cbfa8da-f453-4267-d379-08de5902b8be X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 15:35:35.8240 (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: S1T6ZqqLlK93fdQMuV2VO+XVheEb0lM9W6k74+Wq+yYCBHsHd3ugHKDHBAgmNt5HstVSK9HHnwY/5jfeJpqIo6JeNbd1YmwwfYc3EQ7hjPw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR03MB8352 On 21/01/2026 2:28 pm, Alejandro Vallejo wrote: > Configure the Bus Lock intercept when supported by the host. "which is available on Zen4 and later". (I think ?) > diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c > index 5d23603fc1..abda5a9063 100644 > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -2524,6 +2524,7 @@ const struct hvm_function_table * __init start_svm(void) > P(cpu_has_tsc_ratio, "TSC Rate MSR"); > P(cpu_has_svm_sss, "NPT Supervisor Shadow Stack"); > P(cpu_has_svm_spec_ctrl, "MSR_SPEC_CTRL virtualisation"); > + P(cpu_has_svm_bus_lock, "BusLock-Intercept Filter"); "Bus Lock Filter".  The Intercept part isn't terribly useful. > #undef P > > if ( !printed ) > @@ -3087,6 +3088,11 @@ void asmlinkage svm_vmexit_handler(void) > break; > } > > + case VMEXIT_BUS_LOCK: > + perfc_incr(buslock); > + vmcb->bus_lock_count = 1; > + break; This needs an explanation of the behaviour. /* This is a fault and blocked the Bus Lock inducing action.  We're only interested in rate limiting the guest, so credit it one "lock" in order to re-execute the instruction. */ > + > default: > unexpected_exit_type: > gprintk(XENLOG_ERR, "Unexpected vmexit: reason %#"PRIx64", " > diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c > index cbee10d046..15223a693e 100644 > --- a/xen/arch/x86/hvm/svm/vmcb.c > +++ b/xen/arch/x86/hvm/svm/vmcb.c > @@ -66,6 +66,9 @@ static int construct_vmcb(struct vcpu *v) > GENERAL2_INTERCEPT_XSETBV | GENERAL2_INTERCEPT_ICEBP | > GENERAL2_INTERCEPT_RDPRU; > > + if ( cpu_has_svm_bus_lock ) > + vmcb->_general3_intercepts |= GENERAL3_INTERCEPT_BUS_LOCK; > + This wants a justification for why it's unconditional.  Something like: /* Well behaved logic shouldn't ever Bus Lock, but we care about rate limiting buggy/malicious cases. */ > /* Intercept all debug-register writes. */ > vmcb->_dr_intercepts = ~0u; > > diff --git a/xen/arch/x86/hvm/svm/vmcb.h b/xen/arch/x86/hvm/svm/vmcb.h > index 231f9b1b06..68cf5eaf0b 100644 > --- a/xen/arch/x86/hvm/svm/vmcb.h > +++ b/xen/arch/x86/hvm/svm/vmcb.h > @@ -68,7 +68,7 @@ enum GenericIntercept2bits > /* general 3 intercepts */ > enum GenericIntercept3bits > { > - GENERAL3_INTERCEPT_BUS_LOCK_THRESH = 1 << 5, > + GENERAL3_INTERCEPT_BUS_LOCK = 1 << 5, > }; > > /* control register intercepts */ > @@ -497,7 +497,7 @@ struct vmcb_struct { > u8 guest_ins_len; /* offset 0xD0 */ > u8 guest_ins[15]; /* offset 0xD1 */ > u64 res10a[8]; /* offset 0xE0 */ > - u16 bus_lock_thresh; /* offset 0x120 */ > + u16 bus_lock_count; /* offset 0x120 */ > u16 res10b[3]; /* offset 0x122 */ > u64 res10c[91]; /* offset 0x128 pad to save area */ > Both of these hunks want moving into the prior patch, which resolves one of my concerns there. All can be fixed on commit. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jan 21 15:48:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 15:48:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209949.1521823 (Exim 4.92) (envelope-from ) id 1viaRU-0003pv-TO; Wed, 21 Jan 2026 15:48:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209949.1521823; Wed, 21 Jan 2026 15:48:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viaRU-0003pk-Ok; Wed, 21 Jan 2026 15:48:24 +0000 Received: by outflank-mailman (input) for mailman id 1209949; Wed, 21 Jan 2026 15:48:23 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viaRT-0003mT-7G for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 15:48:23 +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 9c417d03-f6e0-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 16:48:21 +0100 (CET) Received: from BN9PR03CA0488.namprd03.prod.outlook.com (2603:10b6:408:130::13) by CH1PPF0B4A257F6.namprd12.prod.outlook.com (2603:10b6:61f:fc00::605) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 15:48:15 +0000 Received: from BN1PEPF00004683.namprd03.prod.outlook.com (2603:10b6:408:130:cafe::a0) by BN9PR03CA0488.outlook.office365.com (2603:10b6:408:130::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.9 via Frontend Transport; Wed, 21 Jan 2026 15:48:06 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN1PEPF00004683.mail.protection.outlook.com (10.167.243.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Wed, 21 Jan 2026 15:48:15 +0000 Received: from xcbagarciav01.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 21 Jan 2026 09:48:12 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9c417d03-f6e0-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=KVlH5mRGBpElNskBUSQBa8ePqq5KqxNO7QHBLhwjOuMWQqAERO/cjnERGLCDBvf+C7peiSTeJ3W4YmFdodZmt4OvXQ1WCS9awjBDekvJUt/MhE0u0OryhOxCoRfuA8gs3J8cmr/K1li0iV4w+v5CewL5yAWrhpXlYm7n+9h/wGt1gAoWHG53Xf2G1CDxmEk5CDp6dsAF70iV8OQY5YH0vySk2+MaCN0zxrFrFdA38tCyIudEpJmumwwVA0OtkDPEDsp+l1i4GLy4xXeaDa/On4ki8rj/57FVzKVF78D2Nfxa4Qd/ILCjs+uTZFgH6idHr6BwdIOISoOGhAR6kB2jew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3hEcp5FuV32q9O8AGTwJAtTSdTYQ5bAV1OGHL0IDGXc=; b=dAeMAS95HOGlJNSwyS363y7npnE/Dw+sdI44VUhvfrnpZANNSAu3iu7hWbgnLX0SHHbZNfNa8sDr+9BA0LHrHBWqtoHB5cyra1zxHV0yMm6mDbn2FDSGszTeJo8Lmc31eQrOUddIeEysmSWqr0GrC4aA8FYcWXoJdACSmY7Kp/vdRcSgBwiW84Z7aSsL847//P/1DiScMNbUOD4mCoYwqIrJOkMM408l3E98ox8lpfDQ6/j+399D3qhQxEhCkJcUsOiCJIiEm57u9erHjaEd6o8ccyNPb3V+wT2qg2otR+kxYZ+5Y0MJdsSBLJA4ijI2JZ81jzmF5yjsXSz+NMZ/aw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3hEcp5FuV32q9O8AGTwJAtTSdTYQ5bAV1OGHL0IDGXc=; b=KRZI97vci0YMiu5g2Nzw1/1+aGXunWzcN0x2f9JLPC+9EFNQCgdeZoRdyPMlRUUmnGepC4WvnMt1G6tvkA8E36mJF5E3hXV8lwNCt1k7AzAEEMggnjEJl7IobLK/p5rNFjjVFypupHmH0/k5vUptmO8utOXC0BVMt6swjItInwQ= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v5 1/2] xen: Allow lib-y targets to also be .init.o Date: Wed, 21 Jan 2026 16:47:54 +0100 Message-ID: <20260121154757.44350-2-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260121154757.44350-1-alejandro.garciavallejo@amd.com> References: <20260121154757.44350-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: BN1PEPF00004683:EE_|CH1PPF0B4A257F6:EE_ X-MS-Office365-Filtering-Correlation-Id: 0781965f-80b0-478c-5b9d-08de59047d71 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?PH/kHBcEUNFtUP2dLAKQDTIkm0DiCvbj6VjUaRPRUD2fjaA+KuWw3tRkrdjP?= =?us-ascii?Q?WYQFr69mv03MBb3DnBwUh8busvuhtVGlAGjo3mMqKAKbyVbOJXty9TFrBNhN?= =?us-ascii?Q?thlxIOj4As/dBl8TbD99vetCHHEhqi9IbzSTue77wZX97IJ0T+G+xOLKCeOQ?= =?us-ascii?Q?4RHlnaxpjSfLHj8CGH/q+oVt+1H0hs3BYAsV8IOz6KKZpD3RwMVBiqE0eyK8?= =?us-ascii?Q?OnaWfpMXlA2oalYisVW2o8DGWnqb/OZ2iwUP6hYWrsl9cLbzz07J3XZqajS0?= =?us-ascii?Q?pMfih+1r6r+04ITg+89Ol6VVar7S9aOny6dqJp4ltqS+4vaRsGqie/1ASRTM?= =?us-ascii?Q?0Dm1P8Se24j1zyyWC4qzxGkzsHGSzWSdS8EnHrmP3BylbwmsbHEXKnBwD84x?= =?us-ascii?Q?TMTVanf58KYV3HYHhbkjNp5VE0/GephXN6MHwKtfCqtk8R2XTPxKyJLl0A8P?= =?us-ascii?Q?svHnr+hwSBDDyDR2v1p7FIJM+nKxU8RgumQsPNt9GG51PZ3zedgak7l4q+tj?= =?us-ascii?Q?bI8NKvY1Gc9hnv7mGyaeVy/qY830ey2rXe7TmUJEjncITMLtDQAAAaXqEuCo?= =?us-ascii?Q?wFXCq6jUmVfA3ZDkflVKWfnQKp1VjH10p/PKn6DaUDNg783Ae0wX+CKPx0qz?= =?us-ascii?Q?5sqHl+TBV27u6z2ynjok8d68V0GF0ksEfaHxHfwwI3CoiQV9PY7acf5iDjMu?= =?us-ascii?Q?HV3YKhFaxnTJTpvlmLglGatD6zhW5Z6/tgBLEHbT7/ihYr/Iu/t/StDKYe25?= =?us-ascii?Q?nYNLJCwbHLpZdWIUWz/Uuhb2YhCyZzZ6h95X6jLxaEAb9uxDB5fvP8XmU9KJ?= =?us-ascii?Q?O2FTOD+KZ6eH0Ql36QPbGuxJmW4Mw9T8ki+NnveHvIV1xvuei9PtIIKUwL5y?= =?us-ascii?Q?BzAtZcGCV20bIe8vOROBcgkywdqOkJEHgRdQI2fImnbULw/mF8O4lU6/U1Je?= =?us-ascii?Q?dPCczimPCV9aIie8dQexDPFAq8dpe1Zp9XDNpETT8ixNW58vdvDP+WdAQBhT?= =?us-ascii?Q?bIlpMiGpjqnVmBOhxdJs2T29/XXDwtWo/p0mX+kMHeAxbIb1HQ2I/iWLyvGd?= =?us-ascii?Q?3IoS3DYK8VtZVVlY4DzJZu+PwjwWOonsRhhyZWN8mnZ1Z6n3oJTCJWnejed7?= =?us-ascii?Q?JbmwPR8tESdR3OLj/dNxfonR0+JYd6hTAg3QT71IejET+lSnKKpz07n2an1x?= =?us-ascii?Q?2r+SOahXs11kRC2kZYSaInNoZLuvwGhDV0GPUhPL8+ICZx2Gs+P9Nf0qHR0R?= =?us-ascii?Q?SLjgkTFKDwgO2Z4hhLF2ugbvvjw7Jj681BrYJg7IwjwjN1XKqKcVKJCNp6wG?= =?us-ascii?Q?O0VIXIrM8mBuYJ8ZhGuS/Zf4NvgZJ4avzuiA9AlWAN1zMvEs0WzFYmjdgJti?= =?us-ascii?Q?0d+OSugzxytR16VQXKvwfuSaoRmhgZ/b8gs+UmjhZ+HMuxh99KbdTMNK7guR?= =?us-ascii?Q?/6re3ATWJc5PGhPjIVcVBTCKQ9do0UySXcMEDU+PD5f8ax+KJ75FLRLi5vZe?= =?us-ascii?Q?juowAAxBTlojC4TuiepjfQuj5Ps3nxw2IIwFyimusZJ7e0859+tLDJGYRveJ?= =?us-ascii?Q?ciAAk/cr84uUfp5oZDxeBYMYJyjokvoOMMicj06UMibfgwhwjd9Bpr0JjDNb?= =?us-ascii?Q?J3aZIVSNgX8L0NstIcLQ6fJuwwV5CHmkXzwgdZ5jXHvK8cW61yVL7N8zJvbm?= =?us-ascii?Q?g8hbGA=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(1800799024)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 15:48:15.2080 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0781965f-80b0-478c-5b9d-08de59047d71 X-MS-Exchange-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: BN1PEPF00004683.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH1PPF0B4A257F6 There's some assumptions as to which targets may be init-only. But there's little reason to preclude libraries from being init-only. Signed-off-by: Alejandro Vallejo Reviewed-by: Jan Beulich --- xen/Rules.mk | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/xen/Rules.mk b/xen/Rules.mk index 2b28d1ac3c..2c3f836c1b 100644 --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -130,9 +130,9 @@ endif targets += $(targets-for-builtin) -$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS-y += -DINIT_SECTIONS_ONLY +$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)): CFLAGS-y += -DINIT_SECTIONS_ONLY -non-init-objects = $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(extra-y)) +non-init-objects = $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)) ifeq ($(CONFIG_CC_IS_CLANG),y) cov-cflags-$(CONFIG_COVERAGE) := -fprofile-instr-generate -fcoverage-mapping @@ -146,7 +146,7 @@ endif $(call cc-option-add,cov-cflags-$(CONFIG_COVERAGE),CC,-fprofile-update=atomic) # Reset cov-cflags-y in cases where an objects has another one as prerequisite -$(nocov-y) $(filter %.init.o, $(obj-y) $(obj-bin-y) $(extra-y)): \ +$(nocov-y) $(filter %.init.o, $(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)): \ cov-cflags-y := $(non-init-objects): _c_flags += $(cov-cflags-y) @@ -156,7 +156,7 @@ ifeq ($(CONFIG_UBSAN),y) UBSAN_FLAGS := $(filter-out -fno-%,$(CFLAGS_UBSAN)) $(filter -fno-%,$(CFLAGS_UBSAN)) # Reset UBSAN_FLAGS in cases where an objects has another one as prerequisite -$(noubsan-y) $(filter %.init.o, $(obj-y) $(obj-bin-y) $(extra-y)): \ +$(noubsan-y) $(filter %.init.o, $(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)): \ UBSAN_FLAGS := $(non-init-objects): _c_flags += $(UBSAN_FLAGS) @@ -273,7 +273,7 @@ define cmd_obj_init_o $(OBJCOPY) $(foreach s,$(SPECIAL_DATA_SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@ endef -$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): $(obj)/%.init.o: $(obj)/%.o FORCE +$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)): $(obj)/%.init.o: $(obj)/%.o FORCE $(call if_changed,obj_init_o) quiet_cmd_cpp_i_c = CPP $@ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 21 15:48:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 15:48:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209948.1521818 (Exim 4.92) (envelope-from ) id 1viaRU-0003ml-LW; Wed, 21 Jan 2026 15:48:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209948.1521818; Wed, 21 Jan 2026 15:48:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viaRU-0003me-Ho; Wed, 21 Jan 2026 15:48:24 +0000 Received: by outflank-mailman (input) for mailman id 1209948; Wed, 21 Jan 2026 15:48: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 1viaRS-0003mT-I0 for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 15:48: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 9b34a977-f6e0-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 16:48:19 +0100 (CET) Received: from BN9PR03CA0495.namprd03.prod.outlook.com (2603:10b6:408:130::20) by DS0PR12MB8367.namprd12.prod.outlook.com (2603:10b6:8:fd::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Wed, 21 Jan 2026 15:48:14 +0000 Received: from BN1PEPF00004683.namprd03.prod.outlook.com (2603:10b6:408:130:cafe::c4) by BN9PR03CA0495.outlook.office365.com (2603:10b6:408:130::20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.9 via Frontend Transport; Wed, 21 Jan 2026 15:48:11 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN1PEPF00004683.mail.protection.outlook.com (10.167.243.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Wed, 21 Jan 2026 15:48:13 +0000 Received: from xcbagarciav01.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 21 Jan 2026 09:48:09 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9b34a977-f6e0-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Hu9OdlCnb5K0yJdWCQLLhUZJGLdXrebvwSBS8fKk3Gssrb4MMgGaj58KvKNm8DEctJeKXugz+jXvxiYRCw2KSEaGJQvRSsVUhqSo92NoBeN6lXH2XMG1+Dtb9d7rZCSIVWq9hdn8yxUULx+DZEXvTmHYy49lDKU8gPXKVIcaSQORmiwdBJdgvN75thaPnsC+VTtgXavN8YCbagJDEPJ/BhROS2khbNDymw5xexKnoayaNEUAU0IUB4q9JqoR+92vjFGMlB4EuuPhMjZn5XHVIOZ6D8bbIJQkxZh8n9F4n4qxTT4HQ/NvvqM8XXxMaKiBqPlx7+miEWd8AnJnsDixow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jqFMrGJ4uCXNp+b6CIgI8rhPMQFYCHwkDp5xmNbYZYk=; b=W/sfOjxmvLNMJaabt/BFqmXw2KMBF1sLq+O+mKb8msVczxxKZgYuLEqsIizThmHZxG4S5EYQ22SZg2ODfbLMZdWZ79ZzYFIKb/lTtg4fxUXHt1yB6+QCBU9Cbv5SWsmyvhY/opulYvoxANNlWqwYUKuO97mrXikoWAI7r9MlbSjmyHpbYufkAeIbapBDQ0PL5dNAaA+nR0dJF/UAoLHFHxE5J/rr29WSHDSkdpWVr8K/0OLi5I5BDf+oF/pyibsgqtf/gpOatZoL2A3ChJ6lE+cOryqINggIrwFsTBuSNgNMPU26MIQYIqimNwPqRUM72QjqvFs6UWcYSeHVDW3Twg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jqFMrGJ4uCXNp+b6CIgI8rhPMQFYCHwkDp5xmNbYZYk=; b=DOTp6yz7T9b7rD5pWLTbzLFGA+rj5DJKWS3Rbd8r9E2hHtuQPZEtsKFTL5RfUxt8qgWyvf4GLDzyb5Rmx3swfpmQ+Ry6e67BI9JnJRgfIZYbjtDGOGBjbtsGEqZkz4Q1cWR51/NmXGLg4VuZ42ge1rf74T/P/v5oGnuwCUBanZM= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v5 0/2] Date: Wed, 21 Jan 2026 16:47:53 +0100 Message-ID: <20260121154757.44350-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: BN1PEPF00004683:EE_|DS0PR12MB8367:EE_ X-MS-Office365-Filtering-Correlation-Id: 097453d9-c1f0-4f27-e31f-08de59047ca3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|376014|1800799024|36860700013|13003099007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?TI6Oz+WLBZKOxn1PNztzj1sa2F15CNv1rqvn/6EJ90FJz5Irlk1sSwqfi8ON?= =?us-ascii?Q?0vdMZJY6UcLlmennMw0Tjdvwc7I9KS0f/AN1v7VKv4/Iqjaz3F+C5hKBlosf?= =?us-ascii?Q?yzfggmChZP+JKkUI+hkiW1chx07dZEj2NOMGqrj+KmFf9A8pCEEvDAhKtyEX?= =?us-ascii?Q?pOjDPkfNP3u3iEK7MPuVHrMxYk02zDfviOVqN7igcbYA327l8jKQemNHBiqh?= =?us-ascii?Q?XVBG2AjPk4dJ27BcRbKTlztY9wQtF5RU+t3slHcertpsdFLYb1heEVwMyUDu?= =?us-ascii?Q?vnQQJ7gsiXT1BhEDEmbYaPKLbCFZPq9ENOSoRm4i7que5bmCY+v1EzQpv9uH?= =?us-ascii?Q?VydpPcYOrWmXHWUv7AGEkeAkSg58cbcUY7GYyPop720Tvw+MtVUWxCuluGK9?= =?us-ascii?Q?BHALzgfxvN6HYB4FNXXOAoj0gumEf6FzQW6BfnH2p6/sruQ2nBkDxYr8Zd4g?= =?us-ascii?Q?GJOpwbSgN3ZWuoQbSkWbTXZlYWhbI93iOYE5FFO98M/Nby1mBQoyoeNS/BNF?= =?us-ascii?Q?7Mpi8kjR9LW7zsggk1WZ4ezK17nlEncY/vmAe6enl709Mt1LyY7IU+pMY+0A?= =?us-ascii?Q?kSQqJVvR5BK5eivwC520fy5rpgW/uA8q54XMNPDpI+BPT0k5Yqodp7O3w9bQ?= =?us-ascii?Q?v71TajTcr4nq7gqC6aunM/yspU3X0cs6hsH4HcdWNuX1t8plfDompWokKtGC?= =?us-ascii?Q?4by+PE+vTyXB7Xxyuhrr19ZBauvd7ijH8NKWsirCP88ngh4rXsP6zJRdajgC?= =?us-ascii?Q?LfsiIFokCyuCP0LI0NSGqyfKA51RjaHgrZGSHhJtH7LqSWbLrMj0tFgwE1Uh?= =?us-ascii?Q?kGFHtvlAcXoTERRwZaLfwoOLa7g+cWw34UdcQbM0FPj3j4S9HONyCDk/WmLx?= =?us-ascii?Q?8wpVgU0bk+cvkvYsK/wVNm08mWLlSGlQTmqYnG8BD1zzRaGSVgLPJNOFK3xh?= =?us-ascii?Q?ruIQi6q3glcZMPuwUIpv5ghXDLymHzl5VWQlQ2WhVUy7ztRJCDZwgIADjnJE?= =?us-ascii?Q?3hTtnwn69vCOmiDUXFHjt7zLdWuOhZQocnQlMStpXFT9x1FxTeqfDGRTLiyF?= =?us-ascii?Q?WgHUOggN/+D3MxzMS/QFEbgbNHNMQeZk020V/9HswHmgjG+WEv/wzzkGOyRb?= =?us-ascii?Q?y5yI92TfiOMCYbE4+4J2hRu4hFsMOox3bMBfPH1tVzezunz9BfG/+umLGVC7?= =?us-ascii?Q?moXQ95AqlfAwnIFLdga/HAAa9PGDR13RpN8dMW+CBqgjbP/6mLQ8NbuUNYpl?= =?us-ascii?Q?0z7lulx0r1BD9w7bN4ebrzSFJW0L3Vlp8ZdI1xeY4oNLpRnvehgV8jEXcb9K?= =?us-ascii?Q?P69oGiOONdHKWqul9A3iED9SfuoOe5tpRBJX0Q0dRZg04gPx5nQmv20ShLhv?= =?us-ascii?Q?cOOgYeYnt+AuvaV0NDOSVQaPrtDbawiuCj0MFsFEMDiiR7IaTml2HE+zc3OI?= =?us-ascii?Q?LGWz631UKgOYe1s+OD1OEKa4Vnc7aQ4UTnD4OEUEO07bZ+ScExpq8LZYRXHM?= =?us-ascii?Q?3i6l8uFx1m5hfEnEjpquZzvciqB2xhtwSbqkC4Xf6SkytH9/ddLrN9RaZEqC?= =?us-ascii?Q?dhSUKM0Ztqn2vTTu3GjdeHoZUhBalSH+/Xtwpuiq0UNzXAeSzTqo4T7bkur1?= =?us-ascii?Q?R+p6YU+pTziARp5nRTnkPf2qlYjNuyTXA7KWnfEghDMWcHtBCxhRStPWVcAZ?= =?us-ascii?Q?3ClfgfFo8pxrs2z8pESp/Mk3a8M=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(1800799024)(36860700013)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 15:48:13.8613 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 097453d9-c1f0-4f27-e31f-08de59047ca3 X-MS-Exchange-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: BN1PEPF00004683.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8367 Hi, Not very related to microcode anymore, but this was part of the microcode series, so... v1: https://lore.kernel.org/xen-devel/20251112162219.226075-1-alejandro.garciavallejo@amd.com/ v2: https://lore.kernel.org/xen-devel/20260112150259.74535-1-alejandro.garciavallejo@amd.com/ v3: https://lore.kernel.org/xen-devel/20260113122109.62399-1-alejandro.garciavallejo@amd.com/ v4: https://lore.kernel.org/xen-devel/20260120093852.2380-1-alejandro.garciavallejo@amd.com/ Alejandro Vallejo (2): xen: Allow lib-y targets to also be .init.o earlycpio: lib-ify earlycpio.c docs/misra/exclude-list.json | 4 ---- xen/Rules.mk | 10 +++++----- xen/common/Makefile | 2 +- xen/lib/Makefile | 1 + xen/{common => lib}/earlycpio.c | 0 5 files changed, 7 insertions(+), 10 deletions(-) rename xen/{common => lib}/earlycpio.c (100%) base-commit: 61204ed24ba4537d6eff56594faa5d23cacb8310 -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 21 15:48:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 15:48:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209950.1521838 (Exim 4.92) (envelope-from ) id 1viaRc-0004HD-2g; Wed, 21 Jan 2026 15:48:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209950.1521838; Wed, 21 Jan 2026 15:48:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viaRb-0004H4-W9; Wed, 21 Jan 2026 15:48:31 +0000 Received: by outflank-mailman (input) for mailman id 1209950; Wed, 21 Jan 2026 15: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 1viaRa-0003mT-WB for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 15:48:30 +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 9f3bed62-f6e0-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 16:48:26 +0100 (CET) Received: from BN9PR03CA0501.namprd03.prod.outlook.com (2603:10b6:408:130::26) by IA0PPF1D04084C7.namprd12.prod.outlook.com (2603:10b6:20f:fc04::bca) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 15:48:17 +0000 Received: from BN1PEPF00004683.namprd03.prod.outlook.com (2603:10b6:408:130:cafe::1) by BN9PR03CA0501.outlook.office365.com (2603:10b6:408:130::26) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.9 via Frontend Transport; Wed, 21 Jan 2026 15:48:05 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN1PEPF00004683.mail.protection.outlook.com (10.167.243.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Wed, 21 Jan 2026 15:48:17 +0000 Received: from xcbagarciav01.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 21 Jan 2026 09:48:15 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9f3bed62-f6e0-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VAJUJmbpeXrzePvjVr6HMMol6P3HK/tLtawa3WKzr+ADubChz6iE191YKFvlIYAIPBGFmBLLxTaJWdIGkQU+52fLFSMGsQmUqYtMRJ4KHoiW/McGvHy8CLpGWcxtoU5alpEc2thYhVEbIhkRAq+XszcVhDmhyCDbqRHke6ED3drI4GoBbb0dWTHaNIJQClyKHr5lflhHyvma+Y0ZS/621iZTqLBsmGruAOx48GNyDecA/zzszLP+HRomBiadLx4UFwOlJjF1UHfyoen6VA6F/R9m6gQ9CzsFKTMai/NKY8YI/7WL81tM/hbkH3zMr5i1iHxS34FoX0VJuTuIJAfkPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=C0nJyS0lJh1a1xRmIBV+i5/oNc1aFwWikBJTjecHGaQ=; b=ef+eY43iqra0xWedgFxhngqiJTlc3StRNe48fv0f2qUJVX0kL1x9n9CnK+kj49C1rdCr7lumjowIY8KWmOn10CGr5TclmbA1C8N+RU3DRhUEaMAq0MaVvpAK/ZG/OI8e3OFMbwdz0/FYpg6MMtjp5brtm0Z0D5fJiWNTO59VLlX26NbtsfJhb2byQnZNAj+1oCgNvhUNCRnSMjUDga+ms4Ila4x9uQGnNFLNbFtZhpmQOcOlRM1a64HwNViP+J9UC2pHjlyPvRtwi4Yj5gHtKEFcVQOe0ibuLarU5iTl6WClfswi/qh5Bt3PjpD4Hvmnt0LmdrWWH4pk0TJbl/ilXw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C0nJyS0lJh1a1xRmIBV+i5/oNc1aFwWikBJTjecHGaQ=; b=dcdLReqsF9dKIPa7E0j7umppyTPnu5RQ+HHkNjEgHajqnIYoDbhuS6UWeh/Y8jI3abq7W4Bxl/SHvTYq/k/XGy5i6dzMKWuJGnGU8S9vTtbxs6gWlWS+e1saENoGDdGasMgtnt7RqhrT8ShB84RzOXruvoa2aRZszOHCcuM4wEU= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , "Nicola Vetrini" Subject: [PATCH v5 2/2] earlycpio: lib-ify earlycpio.c Date: Wed, 21 Jan 2026 16:47:55 +0100 Message-ID: <20260121154757.44350-3-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260121154757.44350-1-alejandro.garciavallejo@amd.com> References: <20260121154757.44350-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: BN1PEPF00004683:EE_|IA0PPF1D04084C7:EE_ X-MS-Office365-Filtering-Correlation-Id: 2fa495f3-d856-43b7-31b1-08de59047efb 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?vLJaaYRPMldccqaHviov5PrVmJtDonlD85C6liRmGauMDWSev2ntau+U1RTy?= =?us-ascii?Q?a/IKPN65OKEfn9UNS9ZhJGKUgCk3hS9XH0uf9NXOu7+RsozzL5KSGnjeM4Ai?= =?us-ascii?Q?K6ZXzfsvn1/aqy0krJSLwU7jMHetSnUNrGTR14gEJq255chq2D+T0IX39gTb?= =?us-ascii?Q?z0/N2cAEzbtSlk4I6Z0Om2j1mEl7Mm7jvvuAQeYqQDwF75b9qcoF2vWYlsni?= =?us-ascii?Q?7H8etWuc1se/wE0cM1mJ4vUojex6S4EMEzH+ofXtdg4DMAIxC2jcHxpLyKFV?= =?us-ascii?Q?V+efu40xkJLIzQ/h4ylEjbWTMxvg6oFNNVEcIITkKHPTp3O2wpFI8yM7d9i1?= =?us-ascii?Q?3UqOQUHaVxLuaFJuU5e4VDK6AHDqwsWlxhIzIDhkcCgusQBjDFY0xTIAWElQ?= =?us-ascii?Q?s/erOLuTZXd5NyeBJSiekQLNG6KfXkjQoqSh5Qr0uDvwWSq5+kMV9Dm6kVp0?= =?us-ascii?Q?z/PktMAaLg2x1vPt4VCfzN3IW+p6bdDJmS3sKpUAw/jlETBzKkYTy9GjUuB7?= =?us-ascii?Q?jnG0An1gR+vEBUS6/jF2DM8/hVAiY57cKN1ygbS15fxh2hTIlEOY9Svh4Q7p?= =?us-ascii?Q?BDU+j//rtO1Tw4eCWgt6r1PwO7hheUcaVAG7HeIjXEH5z2ws0LED6dNuk2Rk?= =?us-ascii?Q?gr+4oNgbyoYOm0Pl4pV57KJkw3OfT/kMa3yiPruiZc9BkiSLwpyLzIcDKkXQ?= =?us-ascii?Q?YdZn+8AXVhBjaUS5htO11OX45GPIparuh+enN8TMjHh4XENpBkeJqcVBxb3b?= =?us-ascii?Q?vq0djQ0ZkS+bTSLnhHv1EmuuQd6Egoz8YU6CZkrAQmyZ9iiZRomXBVXF3/wT?= =?us-ascii?Q?nLBZ2XsRinM0eqh3pcY2CeXwd9uqf1QNPq/cW3HykoOIRthIZKWcYymbxiSm?= =?us-ascii?Q?cVb3SvVtGHXDZFeynw3hn7yCUgyViTSJ+x/BiDkA2Uu7N9CA+ZdfmfI0jgE5?= =?us-ascii?Q?stxA6T7UBrQAk5+m1qGHTucYOG1GOxyHlvBJ8ZluxJ0MOB68at+FjAUdaCrV?= =?us-ascii?Q?sXSin71cmQQheWH14guHmm/lqNgCW1CoqbnQ10anum3FZozaru5SHLDCDRyl?= =?us-ascii?Q?HwlMqPn9pV9SWXH62UAjsABehfcUjSiw493vm4QwUHG7WUa/OZqcNcL+iQF6?= =?us-ascii?Q?Gp4l2YGNkxsiruk9dORK/FcJvhtRonl3+LI4onj0ytpsGhRMvGBVs+WRNOzQ?= =?us-ascii?Q?5JEr+9/WDssRl8X4V+96BKCo+znvvzsT0Dv8qEq7jWfPgFa0oZCC9BN+7+xk?= =?us-ascii?Q?27mjgG93QRUC49jSR0rIV0OxRQTrizXBiAtXfL3l1G67TJ9sri0dwElmVFW0?= =?us-ascii?Q?iXSj5RF2MmLuSivW3KQKF7txEQa7IyBbP6at6mTXYHNZziHU8+4kyTjCuARL?= =?us-ascii?Q?nLLL/BAGAMxoONomY1IKwaGnTZxGqOQPgfjcsSd6QDfwSfIykfBfnbBw/f1u?= =?us-ascii?Q?0uLJt37XMVQc0IX1/XIXhSYqOiZBwPTCVU0Xs/UXbgqHHKkA5PqiYnyv2Jwk?= =?us-ascii?Q?yFOiqR/JyY1zp5aoxOCsrjMkBRB38RvgQ+EVADaJurSeURGcKwRpVdAda4mt?= =?us-ascii?Q?7a1S79HT1yBss8Xfx3OAyiGidMyLHHhdOLNqCAADzrnCzzPjIEjFNs4TA/dC?= =?us-ascii?Q?Rm9rO/HZG05riY79XzNz3FapcpI1TbSp4Sel2KF8PKelUfvp2I+xVC+wodHc?= =?us-ascii?Q?N0tztw=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 15:48:17.7877 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2fa495f3-d856-43b7-31b1-08de59047efb X-MS-Exchange-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: BN1PEPF00004683.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PPF1D04084C7 It's only used for microcode loading on x86. By lib-ifying it we can make it go away automatically when microcode loading becomes an optional feature in follow-up patches. The exclude-list.json file goes stale after the move, so remove the entry for earlycpio.c now that it's not included in AMD's build. Its breakages will be fixed in due time and not ignored. Signed-off-by: Alejandro Vallejo Acked-by: Andrew Cooper # lib-ify only Reviewed-by: Nicola Vetrini # exclude-list.json --- docs/misra/exclude-list.json | 4 ---- xen/common/Makefile | 2 +- xen/lib/Makefile | 1 + xen/{common => lib}/earlycpio.c | 0 4 files changed, 2 insertions(+), 5 deletions(-) rename xen/{common => lib}/earlycpio.c (100%) diff --git a/docs/misra/exclude-list.json b/docs/misra/exclude-list.json index 388397dd3b..273e24db4a 100644 --- a/docs/misra/exclude-list.json +++ b/docs/misra/exclude-list.json @@ -121,10 +121,6 @@ "rel_path": "common/bunzip2.c", "comment": "Imported from Linux, ignore for now" }, - { - "rel_path": "common/earlycpio.c", - "comment": "Imported from Linux, ignore for now" - }, { "rel_path": "common/gzip/*", "comment": "Imported from Linux, ignore for now" diff --git a/xen/common/Makefile b/xen/common/Makefile index 92c97d641e..4fc0c15088 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -65,7 +65,7 @@ obj-y += wait.o obj-bin-y += warning.init.o obj-y += xmalloc_tlsf.o -obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo unlz4 unzstd earlycpio,$(n).init.o) +obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo unlzo unlz4 unzstd,$(n).init.o) obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o xlat.o) diff --git a/xen/lib/Makefile b/xen/lib/Makefile index efca830d92..3b0137902c 100644 --- a/xen/lib/Makefile +++ b/xen/lib/Makefile @@ -3,6 +3,7 @@ obj-$(CONFIG_X86) += x86/ lib-y += bsearch.o lib-y += ctors.o lib-y += ctype.o +lib-y += earlycpio.init.o lib-y += find-next-bit.o lib-y += generic-ffsl.o lib-y += generic-flsl.o diff --git a/xen/common/earlycpio.c b/xen/lib/earlycpio.c similarity index 100% rename from xen/common/earlycpio.c rename to xen/lib/earlycpio.c -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 21 16:04:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 16:04:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1209989.1521847 (Exim 4.92) (envelope-from ) id 1viagx-0008DP-IR; Wed, 21 Jan 2026 16:04:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1209989.1521847; Wed, 21 Jan 2026 16: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 1viagx-0008DI-Fp; Wed, 21 Jan 2026 16:04:23 +0000 Received: by outflank-mailman (input) for mailman id 1209989; Wed, 21 Jan 2026 16:04: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 1viagw-0008DC-88 for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 16:04:22 +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 d641adef-f6e2-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 17:04:19 +0100 (CET) Received: from CH5P223CA0016.NAMP223.PROD.OUTLOOK.COM (2603:10b6:610:1f3::21) by CH3PR12MB7641.namprd12.prod.outlook.com (2603:10b6:610:150::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 16:04:12 +0000 Received: from CH2PEPF00000149.namprd02.prod.outlook.com (2603:10b6:610:1f3:cafe::cb) by CH5P223CA0016.outlook.office365.com (2603:10b6:610:1f3::21) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.9 via Frontend Transport; Wed, 21 Jan 2026 16:04:10 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CH2PEPF00000149.mail.protection.outlook.com (10.167.244.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Wed, 21 Jan 2026 16:04:12 +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, 21 Jan 2026 10:04:08 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d641adef-f6e2-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UrpsPhY7QmaH09+jujG50Xrz5PlD45ozhcUva6jgNwdp0hRLc84lmIIMlT8DKv+UnSl2Kkd+j6ugIlm/bNg5tNIcyFofKuHC3BtxT7WdeXYETcZkH6UgnRC4zGFXQMpxxuCy9OUDZemIWqA9lPrL2pUnfpeIDgzHVVhjMPdjcAF/1ouYvJY6tCEaRC1l98OScM5qdHLyNTIkkcEbOV+AfQukGE1fxZzARB7NjhqrPP/6dpe1iP4rP5/0PTCFvRZ3qL9SfWhyYO7ZVDmz99I0CutwRLF0fH08M2JZ6IoyY5dGZx+HcnbFavy5VeP7Gf0lNVZdnn9QuTpPZ0WHD/KM4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=78r8h8ctwyWiwA+WDjonPYBlUeIDTZEOTkJ7K9cXGZI=; b=ovPLFmoEt7W2/HETdXe7d25FdBcjoLEK1y3jpDXWWfrT0cG0hA3c74bv7skYmFthN6eqHlabqs1F0XYpdUxVI1kuCZeAMY1+8gAtuuGo6cPtuXzXkjETnS0zGhzW9r76l4+S8dVC7wCVmVWsUOkhHvUIM/d/a/sRA8/ougK8uWT11DhslC929CPykDL0nZMCE/DwMA8al67hby4XuPpeFIkzmrKaNvcCbs9TK2Fv5t07tZRr1mMPYJ3PgfOaShAX3awTFVsxaMpmWZjmySRWs8RCv4AvMBiQDuGCvtEQcT8zB9qAWt3HtcTw5Nutg+eMqjztgCyPsMeaD7kLR6Ku0Q== 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=78r8h8ctwyWiwA+WDjonPYBlUeIDTZEOTkJ7K9cXGZI=; b=kFCb1hZUfn6Xow5t5Vgg1mWoL/obeQWMwLRbuYsY8CDEKmFQEUoVCC7E4Q5XSCtpUtfel5bAnJed7Y2EDjk88MkN7m5t40h8bIAANxqJPYerHyHWxhlDrIAMzPDOfb+yAHBnl+AEDfv38c6tYGiTd6/6hF5cwOME8JJhVbZ/hEs= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 21 Jan 2026 17:04:06 +0100 Message-ID: To: Andrew Cooper , CC: Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk Subject: Re: [PATCH v2 2/3] x86/svm: Intercept Bus Locks for HVM guests From: Alejandro Vallejo X-Mailer: aerc 0.20.1 References: <20260121142857.39069-1-alejandro.garciavallejo@amd.com> <20260121142857.39069-3-alejandro.garciavallejo@amd.com> <7fbc3acf-b878-4a82-bc08-89b91fb9aca6@citrix.com> In-Reply-To: <7fbc3acf-b878-4a82-bc08-89b91fb9aca6@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: CH2PEPF00000149:EE_|CH3PR12MB7641:EE_ X-MS-Office365-Filtering-Correlation-Id: 6d01eb6b-d7d8-40ba-81e0-08de5906b7cc 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?UVk5TEl4VGR2bGRrTytHVHFpUU85K3dKekxIZzUzbm1JRXZiTmhmQUpEdmdF?= =?utf-8?B?aEFudXFrTElqeGFUN0JmVTVtU3MyUXJjVE1SUk1IRXI1STJOdS9vTjRZNkpJ?= =?utf-8?B?N0NXeWJjSVl6aDlvR2R4TjltcVE0elNVVXNkK2p1d1NzTWNMZDRxRnBSSXMz?= =?utf-8?B?ZmtKTzQwc2tjSW1tcVN3TUxmRmt3VU9MbkxlZ0I1cTZ3cW5vMnNjeXhWWElk?= =?utf-8?B?RXR5Mm96Mm15Mk95UmVrREM5VDUwR1hrUHNEUVlZQzRiS3RPdjZVUzNCcUw4?= =?utf-8?B?NWhwY2pMVUJ3TjkzNFpYZmExZ2FmeUxZVFVNbzFGc1h2dnQ2T0hqaitUZlBy?= =?utf-8?B?NThRN2ErcXoveWpya3dHNzFObzVCd1RzMmwxaFJsVGhFeENtOVQwczVaWTQ0?= =?utf-8?B?eHA4NTE2dE12WU9VSU9weDNQa1BNeXZBcEZ1OHFUaU44T2RLVHN3djdSK0tx?= =?utf-8?B?K2Q5QjMrMS9GbHBBNGRHdFBXaXd4bk0reFVRREROSkxFUnR4MUJpNnBWVzZa?= =?utf-8?B?dEhoT1k2WS93SFdrblNGVERMeG03WEhIbWRxdC9YNzcxOGN2QXR0Z1N2RklU?= =?utf-8?B?WHc4Tmt3UHhJZzRpVjlvZitBWDRJQmEyNmN0RDNlVTkyTlkya3VQeGRYZit4?= =?utf-8?B?bDFmUDFzMytMZkdyT2xEcElhako1RUx5MUsySnU1ZkU5V2ovWnR4Vkd1NkNy?= =?utf-8?B?WFlWOEI5Tjc1dmM0V0RlSW8zZXAyL25yMHRFTzY0VTl4djBueEtxSnptYitU?= =?utf-8?B?OXd2MzJ6VzZxbXk1N3VqNGl0UXJ2eWhGT2dkdkI4REdrSStsSjhtckR5bFdu?= =?utf-8?B?N2Z0R0QyaXQ4Y0I2a2NmajhKSDcvR20xcEJ5L05SNnM4RktEM2FRc0dOY2U3?= =?utf-8?B?eG41UHVEaVJOSS9CM1Bxc05Yc0xMV0hOclg2dE5hb2lQTkY2WjhlSkttZVNl?= =?utf-8?B?Q094NzR2WkIxK0VGdW5Wc1BpSUYyaFEzKzMrSWF2VTlCTUE5TTVBWmU1d0Z4?= =?utf-8?B?eHBySHJhRzZjZE1jcHJhM0YwbE8xSUNtZ21DNzFXUk9iNmp6KzdtMk1PRnRS?= =?utf-8?B?S1VhSmZmUUNXbmdnZGhzMVowcGl0OUNhaS9kMFRIcksweUZvR1NiTFRTUXVE?= =?utf-8?B?NjdvTnZ0LzlHdmMrb1Z6MU8wdTNSamVNWlJjZW4zaG5MTElBMWdjQlZkd0Uz?= =?utf-8?B?N2llbllOb2Z4ZExXN1p0Mm9Ta2hBbkoyTkxndXEvUFBQZlFnQzArNzhjNTVT?= =?utf-8?B?Y0w3NzB4NHVuMWYxM296VkIrOVdaZkJyZmFoSHRpR1hVOEhTOFI2K2RqTXQ0?= =?utf-8?B?OWovYWxvNW00Y3NxL0VleXArbkdvTlJjT0FvN3FKSEN5SkV5N2JCY1k0RUtD?= =?utf-8?B?QTBwRjRCdFJVeDA2eDhxSS9KQmdGRWRWMjJoU1VkUnZkMk1ybnFVcHFvNFR3?= =?utf-8?B?RWFtbEFSSE4yalFjYVR6SG5BOFc0YVpMNC8xYmd5S0ZYV2g4RFdzeEhTbWt3?= =?utf-8?B?VHZncDhKZ0RPYWM0RTR1OThxMFRaRGx5R3NxSTVkUk50MmNhcWg4YzdKaGZz?= =?utf-8?B?SS9NZ0F6RlM0dkliZW1IazUzMWNsMno2RS8rVDBXbmZRQ0lTTC9EeEcvZlZl?= =?utf-8?B?eldUTHVJRzFPZDZPUFRTWlpBLzYrcVhmOGlVR0JNODhnNmZKcERzSmgrUTI5?= =?utf-8?B?aDZqUjUrSFp3dVVJaE5QaVc0QzlWL1ZTYUU1NEl3S1NNNU9HUmIrU0JWTDZu?= =?utf-8?B?dWtuZnh4RXNNYnBwNkpzVGFSK0NiSjYvSGtUVmFBS2w1cGlZZ1lOQ2F2WFZC?= =?utf-8?B?K2pPWTRRakJLejBnVkhqRW5wUDRYajUya3J6WGtoQmFsWDdISXl0YmVtdHE1?= =?utf-8?B?cnB1QlBmZzhZRVhVdlVqT0NuSVRMQnR2eHFVdEFoa1lONnlQRFRlclJ2bFcv?= =?utf-8?B?V0JUWUZsQzJVQlhYTTd2dHU3RUlldGFqQUkyUGFMU0szVnp0ZVNvNmMvQjk4?= =?utf-8?B?VzBGYWw5L0hhZCtZNkQ4R1k3RFdrV291WUswNzk5ZnJHazVkYkFGWUhIb2pk?= =?utf-8?B?ZllhU2tEc2Y3OUNJVGNFaFBGMW1wVlVPMFNud3FqL0lLY2tac1k3WUVjb3Qz?= =?utf-8?B?MmtBaWY0QmZqRjBDaTg2MnpNRTJCUkMrMzYyRjl4OGI3SHY1bGVYSGJ5MEh4?= =?utf-8?B?c2I3aUh6bDVCQTNYNXVsS0o2YThDTURwRFdGMmN0cUNxZ0U4dXNERUVoZWdF?= =?utf-8?B?b2hEbXNVUlJtU2R3T3BEeEdTL2ZnPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(376014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 16:04:12.0963 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6d01eb6b-d7d8-40ba-81e0-08de5906b7cc X-MS-Exchange-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: CH2PEPF00000149.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7641 On Wed Jan 21, 2026 at 4:35 PM CET, Andrew Cooper wrote: > On 21/01/2026 2:28 pm, Alejandro Vallejo wrote: >> Configure the Bus Lock intercept when supported by the host. > > "which is available on Zen4 and later". > > (I think ?) I don't mind the addition, but does it really matter for the purposes of th= e commit message? > > >> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c >> index 5d23603fc1..abda5a9063 100644 >> --- a/xen/arch/x86/hvm/svm/svm.c >> +++ b/xen/arch/x86/hvm/svm/svm.c >> @@ -2524,6 +2524,7 @@ const struct hvm_function_table * __init start_svm= (void) >> P(cpu_has_tsc_ratio, "TSC Rate MSR"); >> P(cpu_has_svm_sss, "NPT Supervisor Shadow Stack"); >> P(cpu_has_svm_spec_ctrl, "MSR_SPEC_CTRL virtualisation"); >> + P(cpu_has_svm_bus_lock, "BusLock-Intercept Filter"); > > "Bus Lock Filter".=C2=A0 The Intercept part isn't terribly useful. sure > >> #undef P >> =20 >> if ( !printed ) >> @@ -3087,6 +3088,11 @@ void asmlinkage svm_vmexit_handler(void) >> break; >> } >> =20 >> + case VMEXIT_BUS_LOCK: >> + perfc_incr(buslock); >> + vmcb->bus_lock_count =3D 1; >> + break; > > This needs an explanation of the behaviour. > > /* This is a fault and blocked the Bus Lock inducing action.=C2=A0 We're = only > interested in rate limiting the guest, so credit it one "lock" in order > to re-execute the instruction. */ fair > >> + >> default: >> unexpected_exit_type: >> gprintk(XENLOG_ERR, "Unexpected vmexit: reason %#"PRIx64", " >> diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c >> index cbee10d046..15223a693e 100644 >> --- a/xen/arch/x86/hvm/svm/vmcb.c >> +++ b/xen/arch/x86/hvm/svm/vmcb.c >> @@ -66,6 +66,9 @@ static int construct_vmcb(struct vcpu *v) >> GENERAL2_INTERCEPT_XSETBV | GENERAL2_INTERCEPT_ICEBP = | >> GENERAL2_INTERCEPT_RDPRU; >> =20 >> + if ( cpu_has_svm_bus_lock ) >> + vmcb->_general3_intercepts |=3D GENERAL3_INTERCEPT_BUS_LOCK; >> + > > This wants a justification for why it's unconditional.=C2=A0 Something li= ke: > > /* Well behaved logic shouldn't ever Bus Lock, but we care about rate > limiting buggy/malicious cases. */ > > >> /* Intercept all debug-register writes. */ >> vmcb->_dr_intercepts =3D ~0u; >> =20 >> diff --git a/xen/arch/x86/hvm/svm/vmcb.h b/xen/arch/x86/hvm/svm/vmcb.h >> index 231f9b1b06..68cf5eaf0b 100644 >> --- a/xen/arch/x86/hvm/svm/vmcb.h >> +++ b/xen/arch/x86/hvm/svm/vmcb.h >> @@ -68,7 +68,7 @@ enum GenericIntercept2bits >> /* general 3 intercepts */ >> enum GenericIntercept3bits >> { >> - GENERAL3_INTERCEPT_BUS_LOCK_THRESH =3D 1 << 5, >> + GENERAL3_INTERCEPT_BUS_LOCK =3D 1 << 5, >> }; >> =20 >> /* control register intercepts */ >> @@ -497,7 +497,7 @@ struct vmcb_struct { >> u8 guest_ins_len; /* offset 0xD0 */ >> u8 guest_ins[15]; /* offset 0xD1 */ >> u64 res10a[8]; /* offset 0xE0 */ >> - u16 bus_lock_thresh; /* offset 0x120 */ >> + u16 bus_lock_count; /* offset 0x120 */ >> u16 res10b[3]; /* offset 0x122 */ >> u64 res10c[91]; /* offset 0x128 pad to save area */ >> =20 > > Both of these hunks want moving into the prior patch, which resolves one > of my concerns there. Damn it. Needless to say, this not where I meant them to be. > > All can be fixed on commit. thanks. > > ~Andrew Cheers, alejandro From xen-devel-bounces@lists.xenproject.org Wed Jan 21 16:19:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 16:19:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210002.1521858 (Exim 4.92) (envelope-from ) id 1viav6-0001g0-Oy; Wed, 21 Jan 2026 16:19:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210002.1521858; Wed, 21 Jan 2026 16:19: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 1viav6-0001ft-M9; Wed, 21 Jan 2026 16:19:00 +0000 Received: by outflank-mailman (input) for mailman id 1210002; Wed, 21 Jan 2026 16:18: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 1viav5-0001fn-32 for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 16:18:59 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e3614264-f6e4-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 17:18:57 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-47edd6111b4so343695e9.1 for ; Wed, 21 Jan 2026 08:18:57 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47f4b2755absm484644635e9.15.2026.01.21.08.18.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jan 2026 08:18:56 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e3614264-f6e4-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769012337; x=1769617137; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=OP0CG/u1l6e0yIA6ogjxbsWgPalv04WrU/mmRvS/0xk=; b=HOassdZrXbr/fxhYneBYM89f+vx0c36SFMSpLcS8fFNoBqIZAAKWvlk50LOK519lFM R8oPvrTU4qi23lifMhZKaRk20d6fwVfAKQ8fZF35/ki0yW6Ln3Em+aI0ZTubDR2U98V/ aFwZZdBMxqp1QOkqEUj8XmdX33gr0GVKuaQ0HNytzpt3vGj9vskwO2S0CIeQWXyGeJTU gpwghAJvcpDS6yAAUG9mn9+5o7baOCpO/EfZn8IaHAFiBHlBPkqp6EFWlakAPZgF25b5 nzrmuJ8F4ZDSZydooRLhdZUw57g3Mtf5Xmb23PzGPjWbbuqbBnPXTjpmj174nEBXdFQN uvPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769012337; x=1769617137; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=OP0CG/u1l6e0yIA6ogjxbsWgPalv04WrU/mmRvS/0xk=; b=WjOB8hWu5xq40PMEsmrN/WBdxh3gAKXZSQHYjkXaWB/Jc7NMLHdxkgGxjZ3Wpa0XIs KPODZMLLp/F7tVJGyBtQPCOD5X3sDeFF3CUMqcW9ReudYUPujYD1CEiLl0Ty2pCnHQD6 FsI/0CCvBC27T12F63MtQW98m+rTTbEHN1BswTTy0z4naBK+Y0iXNkulOSQGEXU1Xc3M hteocSDShPqV5uGypR9O3IECJEPXBMxQP9qHWGoIuH7ZQBvUYruRdc/11QS/hhRahjI4 mN0W0U5yla1AFAmF34Lanbz8q6H1uBfipLNFjPfai3iDHzxRNvl9fXZZqnJEwp6DWXgz oVaw== X-Forwarded-Encrypted: i=1; AJvYcCXWi8/sGcreypb0Sw1LZ4yEI6IOl7pxcovSYxubBgyrz2jQ2kGOtca1wlY2xth+bz+0IAht+RXkNHs=@lists.xenproject.org X-Gm-Message-State: AOJu0YyElLl9P4jt7PgYI3xENq2bXrsEZq85Bt6RDisWavB/yC1EYB1b 1UoSG0aC0sl/BUEkik2A6Y7+4/HWFijHAOHYpX4yjv6gKfJACTO57FdnGIxw/xApCQ== X-Gm-Gg: AZuq6aLPM+Fqsn7Ubt1r+BBaqtn/jxvWttNRKC60/0b+2wFADzulMBsTMDBbPVyCLKr d8nXP9bh3ONQfc80oIVaOq32nP24Z/VgaXExYfnoI9ivIPCbzOM+12egXd3uN0+bcwJyHPocqgX 8eVBddYhwKzYLxlPXbONzEVa8zoXzljlbGRvwKA5Dj+ejHWhJqTNFmqqYzxKZUC/10pSTJLbAlP dJ52DG5GruaI078zwsqIPsOQ3PnidWwXRgRd8eyNjr3qX8CRr0lHngEi7BovoBmZDFm1KCVlApw 4Dk/bzUz2TSvOufXMzc6C7fCN9CzeRLk1PiXeIzoxcUDdQYeWhiifJJd5+5h2GnNBQp4hCgCbku Dk9sL8kOGo4VT6r3J3Bnah1C3k7NwO2vpZCEj4G0n0q6Mm/2g/FS7gmVjox0aASTCMkZ1Rhs96B B+ad+fakdRIsULanJoFINtroQRYy1l/qwfbfAA7TtvQkAPUaTtRHBNVQDKlct8Gc7VbCvO1hV8m Qw= X-Received: by 2002:a05:600c:1991:b0:47d:6140:3284 with SMTP id 5b1f17b1804b1-4801e34b5a7mr217830685e9.37.1769012337137; Wed, 21 Jan 2026 08:18:57 -0800 (PST) Message-ID: <873867dc-79d8-4ed3-94f7-1c7823db7957@suse.com> Date: Wed, 21 Jan 2026 17:18:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] xen/console: handle multiple domains using console_io hypercalls To: Stefano Stabellini Cc: grygorii_strashko@epam.com, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Victor Lira , andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org References: <63c35c5e-577b-4346-b600-03808306177f@suse.com> <32d0a9a2-89df-4e20-8f7a-0f069cbff11f@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 21.01.2026 01:07, Stefano Stabellini wrote: > --- a/xen/drivers/char/console.c > +++ b/xen/drivers/char/console.c > @@ -521,6 +521,8 @@ struct domain *console_get_domain(void) > { > struct domain *d; > > + nrspin_lock_irq(&console_lock); > + > if ( console_rx == 0 ) > return NULL; > > @@ -540,6 +542,8 @@ void console_put_domain(struct domain *d) > { > if ( d ) > rcu_unlock_domain(d); > + > + nrspin_unlock_irq(&console_lock); > } Hmm, I'd much prefer if we could avoid this. The functions aren't even static, and new uses could easily appear. Such a locking model, even disabling IRQs, feels pretty dangerous. (If it was to be kept, prominent comments would need adding imo. However, for now I'm not going to make any effort to verify this is actually safe, on the assumption that this will go away again.) > @@ -596,8 +604,19 @@ static void __serial_rx(char c) > > d = console_get_domain(); > if ( !d ) > + { > + console_put_domain(d); > return; > + } > > +#ifdef CONFIG_SBSA_VUART_CONSOLE > + /* Prioritize vpl011 if enabled for this domain */ > + if ( d->arch.vpl011.base_addr ) > + { > + /* Deliver input to the emulated UART. */ > + rc = vpl011_rx_char_xen(d, c); > + } else Nit: Style. > +#endif > if ( is_hardware_domain(d) || IS_ENABLED(CONFIG_DOM0LESS_BOOT) ) > { > /* > @@ -613,11 +632,6 @@ static void __serial_rx(char c) > */ > send_guest_domain_virq(d, VIRQ_CONSOLE); > } > -#ifdef CONFIG_SBSA_VUART_CONSOLE > - else > - /* Deliver input to the emulated UART. */ > - rc = vpl011_rx_char_xen(d, c); > -#endif I don't understand this movement, and iirc it also wasn't there in v3. There's no explanation in the description, unless I'm overlooking the crucial few words. > @@ -741,17 +756,23 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, > if ( copy_from_guest(kbuf, buffer, kcount) ) > return -EFAULT; > > - if ( is_hardware_domain(cd) ) > + input = console_get_domain(); > + if ( input && cd == input ) > { > + if ( cd->pbuf_idx ) > + { > + console_send(cd->pbuf, cd->pbuf_idx, flags); > + cd->pbuf_idx = 0; > + } > /* Use direct console output as it could be interactive */ > - nrspin_lock_irq(&console_lock); > console_send(kbuf, kcount, flags); > - nrspin_unlock_irq(&console_lock); > + console_put_domain(input); > } > else > { > char *kin = kbuf, *kout = kbuf, c; > > + console_put_domain(input); > /* Strip non-printable characters */ > do > { The folding of locking into console_{get,put}_domain() again results in overly long windows where the "put" is still outstanding. As said before, the current domain can't go away behind your back. > @@ -813,6 +835,13 @@ long do_console_io( > if ( count > INT_MAX ) > break; > > + d = console_get_domain(); > + if ( d != current->domain ) > + { > + console_put_domain(d); > + return 0; > + } > + > rc = 0; > while ( (serial_rx_cons != serial_rx_prod) && (rc < count) ) > { > @@ -822,14 +851,23 @@ long do_console_io( > len = SERIAL_RX_SIZE - idx; > if ( (rc + len) > count ) > len = count - rc; > + > + console_put_domain(d); > if ( copy_to_guest_offset(buffer, rc, &serial_rx_ring[idx], len) ) > { > rc = -EFAULT; > break; > } > + d = console_get_domain(); > + if ( d != current->domain ) > + { > + console_put_domain(d); > + break; > + } > rc += len; > serial_rx_cons += len; > } > + console_put_domain(d); > break; This is pretty horrible, don't you agree? Demonstrated by the fact that you look to have encoded a double put: The 2nd to last one conflicts with the one right after the loop. Whereas the earlier "break" has no reference at all, but still takes the path with the "put" right after the loop. At the same time it also looks wrong to simply drop that last "put". Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 21 16:19:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 16:19:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210006.1521867 (Exim 4.92) (envelope-from ) id 1viavN-0001z1-W0; Wed, 21 Jan 2026 16:19:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210006.1521867; Wed, 21 Jan 2026 16: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 1viavN-0001yt-TI; Wed, 21 Jan 2026 16:19:17 +0000 Received: by outflank-mailman (input) for mailman id 1210006; Wed, 21 Jan 2026 16: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 1viavM-0001fn-L6 for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 16:19:16 +0000 Received: from CH4PR04CU002.outbound.protection.outlook.com (mail-northcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c105::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ecfbe5c0-f6e4-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 17:19:16 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DS0PR03MB7677.namprd03.prod.outlook.com (2603:10b6:8:1f8::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Wed, 21 Jan 2026 16:19:08 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Wed, 21 Jan 2026 16:19: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: ecfbe5c0-f6e4-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Z2Fy1zKuG/2+AGVzeP6hyvY2W5AT5tefTATAlwQdJZOHOxsLqLNdE1MQWYbEFmplsoi49PNtB1LZbblBrkCRYdxJATad85I3shOl5KRDVLi7dQDu6x+6o5EumIdNK6qaqbutOiPRd6Mx25rzVZ4u7P2RLCWoDMbLNlYSSLffx5KdHPSktXJK8YJCQuoipcUlv+kY881cf1vjWKIGUU2hLi/I19YfLj3SUcBVnfeocxPPNysd0qPbFlUGBjFYhwuITN7IMagoJ2ac3Nfp1j6O+4xNN4UZMQNgA77gATGztuZiZezcRZV3jmZojk1Nyfg0GC98IDV+DPpOrShm4aCNHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MrL40zoKsUTP6RSqiAVWjE+F74fL8LTYeUMQC72YRIc=; b=qFK1CuskYXei8x6dXY7JhOEHBwTHq9Agen2/36Ye1DpPoP2fwVIb8DSJQ17w64pI0RxrZpUhE+sbEX/648zQQMdgynFB66rxtzLfODjzXyLTEbVDT+/y9YptSlU0vfPEDqkqd7/vIWT3ftjsHrhQVAfd6v4qaxMlMTzYeYCwLVY7TOge4RX6BGHynU9nxKwCTxNFUst3T5zIKeLvAx8RK3VYhjaJjIuxAzEAmL544eRHLWF3qD8xuVj+naDCBdLsismKP+eYFKzxul2C+nj1kX63lSHvlx5XilohcTt5cZ6zhnt/p3qc3SenF+tVOW0LvXRYxZeaToTGiTqVR8wr5g== 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=MrL40zoKsUTP6RSqiAVWjE+F74fL8LTYeUMQC72YRIc=; b=KMpK/3FSJ2g1YXgJ7CQ3yP/rKZgQ0UHHFPXfVG6ifAXBcILCMMvJUJ/+Q9g+pj7UiS8QVpc+iPx/tGo5Jjggx/uC30ru6IJpcF19ftuUwD4TGU9qfUAkPO2Q0ICWuSms5Qx3ChHyPk2v4uXLrG0x4BWzY/yHgugJv/fr2zs2o88= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 21 Jan 2026 17:19:05 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH v4 1/8] x86/HPET: avoid indirect call to event handler Message-ID: References: <57f34114-54b7-483d-8ac0-e9fa49df959f@suse.com> <1af753e5-33a1-46de-a407-969059e7228f@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1af753e5-33a1-46de-a407-969059e7228f@suse.com> X-ClientProxiedBy: MA3P292CA0029.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:47::16) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DS0PR03MB7677:EE_ X-MS-Office365-Filtering-Correlation-Id: 30907d5b-3d46-4744-2e7d-08de5908cdf8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?eFVtUy8xUy9jNWkvVGZuRk9zSVRNS0ZsYjBQUWgzYlkzWlNFdTM0TldoVGlF?= =?utf-8?B?VzlWTUllT3ZKMWFIejVtZG9LTW11QUsram9QOGV2ZXBJeVk5eWNMY3dqQXU0?= =?utf-8?B?VEhqaDJqbmtGTFFETjZaRWFLSXhxMmU0TVIyUEg4WnptOEVWMjh6WGpZN1FY?= =?utf-8?B?TXRsbDRWT0tJb21MaStsb0JocXEyNTJYNGN3WlhxRHJnSFczWjh0MDRxNTlX?= =?utf-8?B?Ry9Kam4xSUh3TnZOWElYV1lDUUFiZVN1d0Nza2FlZ0M4SW9HZy80T0xVbXdj?= =?utf-8?B?U2hwM2c0cEFrTUtXRlFrREM1ckRqWngyUEpsNUVEUkRvQ3J5aDNYOUpiZ1Z6?= =?utf-8?B?MFZUM2UxYXAwRU8wc2hJRmhqdlVDaldOYmFxcHRib0lobER3NWp0MFZQcEFH?= =?utf-8?B?bEVmTXpDd25aR1gxc1NxcWVWMWg0djJhckdHdERVSUxacE5LYUpzYWRJeGpq?= =?utf-8?B?L2hxZ0hDaVJWMXFiN0VqbTlHNEkxVi9nY1UxbW5jcmlDNHV3aFBXSEZTeTBh?= =?utf-8?B?NGRpdjlpTlcxOXdvNWZzQ25JL0I2Zm1teldCbGZsYkh1YU9rU0NiVXR4b3J1?= =?utf-8?B?YUpsSXpRSDBHUFd1ODlzd0RQZ1RkRjV4dkJOWlE4THE1YkMvTDRwM0RwVHdP?= =?utf-8?B?T3A5UVJ2QTJTVmV5Mm9hWTMyT0ZySUZJYVF0ajlLTk9SN1BnQlRnOXAvaGdq?= =?utf-8?B?T0ZDYUp0VnY0bkc0VTU0Wm0vS1FpUEdRSHlEVXBxVFRXSGhFNXl2VFJxWGxG?= =?utf-8?B?NStFc3R5bzE0MG1vUExGQWttNGQ0OXpiSERYVDZqSGhJVDFhTm84UWFkLzV3?= =?utf-8?B?VjhnL0FRRWhockszRUNsVTEzRHZnblZkZE0yN1NlYlJ4eDdjM3NJcFY4NU9z?= =?utf-8?B?NURGOE5oRTI5VXJEVXppSTExRllPa0ZzN0c0M1V0RkRyNEx1UC8vNHl1R1pQ?= =?utf-8?B?dHpaaHREYnJPdzViWE9ZaHFha25lb3BkVVR0aG51ZUxobUEwb0tlU0RMRjJK?= =?utf-8?B?R1A3Z09Ka3I1R2tYVmpWSjBZc0NkUXB3em11WW56ZU9JWlJEcHora1dwOFZz?= =?utf-8?B?SVpITzA2YjVMOG1KS1hWNGh3NEI4RHRmTzkwNEtUS2UwazQ0bmFuNlBrbEZk?= =?utf-8?B?UGREZEd6TzlTZXl5OWwvc3U3TWdwbzF4SnA1R2ZaU1RIVHRkeXpzWldManY4?= =?utf-8?B?ZFB4eGFIbnRVVDRBemFCc0dwODVRNHNFUmtXbmhEalhzUnZnV0RzZTF5RGRK?= =?utf-8?B?K2V6ZWc5Rk42ZEYxOU9DOVNod3ZaM1RnTTJUdTRkMm5pUWNBUENRLzJoV3RM?= =?utf-8?B?ZU55akFibldHUGJycmZ5N1F1VWthNmRVaWZpcy94bm9jakUwZkcxYi9zeHh5?= =?utf-8?B?Y2NHcEhFWjFyVTNzUm9VMGU4MGRrTXR1RzU4QmtVK0llcnRBaElJMldWdGov?= =?utf-8?B?T1BDRnNmemdNRDVYS2l1NWVvYjI0LzI0akFsZ3RZVHNQK3RVYTNMVTNZRlFt?= =?utf-8?B?OUFwc0pZL2lCNWZ2d0llY0E4dVEya1VvM20yMURITzNZMXVraTZQWVV3ajd4?= =?utf-8?B?RTE3NU5nbENISG4wbnQxYkNsWGtMb2VrU1hNS1hsaGRFVnExOEF3ajBBYjk2?= =?utf-8?B?bEUvZ2VvQ1dUcE8yWGY2eEp3aTZ3Qk9mR2c2aVFaNVBpN2tiN1NMR1Q5K2tR?= =?utf-8?B?aG5iRTZNamp4b1JrWVdDb1YveURGSXZ2Q1U2czkvU041Tm41UGpqRXlFdnBG?= =?utf-8?B?UG9JSUt1VVV2S2xwbW95ZzYveVFRVnArMnVmY0ZHTXMyR2Y4SGdNcWs2VEN4?= =?utf-8?B?bHRBYkRXa0Raems3enE1M2VoUDVQNVgzUXBremVPZUFJWGZnejNuNWpuMjZG?= =?utf-8?B?ZGx2RU1RSHI5UkcvWVo5S0NDbmQ2N2U1RkljYm9KMUZJQWIvUE9JQlNRMW9Q?= =?utf-8?B?MEV5WTlvRnFqNlZQWmtyTVE2MTFSNnRjM2R4a1VrcWQ0WkxRZlFXWWIxbzk0?= =?utf-8?B?blJMUVd0dmhtL3FRSTBBckZiS2RDNkNkV3N4TTlkektmQy8rUXYrUmh2OVp2?= =?utf-8?B?dm9wYm5CRmMweVArWWVxWko2YlhIVHdiL3R6VWh4ZXdZeFNpV2I3azNZWnhv?= =?utf-8?Q?OPKk=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SjVHd3JtU2xIMGFaUnc2bjlucUtTdjNMaWxsaGFqVjhZYTR5eWNsZm5RdzN4?= =?utf-8?B?WkxGb2dma1crNXNhS0FhZVhZTldlQ3RyTC9Qb0o4Zk90YmdpVkR1aVI2ZGlz?= =?utf-8?B?Y0JaVklKTktkK3gzZHNjVTFlL3V6YXNsQUExQm5WTEU1NnVEdFdkL3UvVW1T?= =?utf-8?B?eFZSbW1USW1GR2M5b05zNjRRbjhKcHVhMk5meFVZbXE3TjVPaWRsQ0ZsUDVo?= =?utf-8?B?SlpCME1CMmkvZll0aWFkMzFpOTRYcXBEMkVpN1ZjNjZnNldSNWRBc3RoTUQz?= =?utf-8?B?NVZSYm1NZmpRSlUxWHBtd3l1azVRckphcHMvR0FDaDIvKzJFSko0dEM5RGpO?= =?utf-8?B?RWllQ2pneWE4cERsT3NvdEs0L0VzWFBYQXYyMDdPTVNwcXRWYm9aTUhKZFdz?= =?utf-8?B?NXZzdW9YeWdTUkVIOVYwOFZtdGNYU2hLNE9oOGZaL2w0QnJDVVNnQlZCY0lV?= =?utf-8?B?bjFKTTlla0x5R3EzYzZVOVV1MEFFUXl5VS8xOVhvS0JtYjdaaEc2MzlsL0Q3?= =?utf-8?B?bnF4czQxeXYxa1I0c3d0T01jbkVwbXFDb1k4OEpvSlpncmx4VjhuZm9uU2l6?= =?utf-8?B?WkZXTGF4WWNoVU1naFMzZURvN1V1RUxBMlVFeGpxVllTaHVtYmMxM25sajRE?= =?utf-8?B?L3N4STc2dllFYnk1REV0UjZMQi9xNEpXOGE0UEd4b0M5dnd4QTdGYWprUlV1?= =?utf-8?B?VWM2RzduVldheUlLeFhnelFvSGc5NGlHcmNZR25RWmZWVUFRd24zZ0xYakMz?= =?utf-8?B?NllxUDNXWk9qWXo2Y1Y4VmU1VmdYVHhvRm5zbHY0S1FyOThoa0J4QWtJeHB6?= =?utf-8?B?cG5xTTBXMlFFZnNQYmljRi9EdzhTWlVOV0lqamNkblhkbkpyR2VzYUFFRkFp?= =?utf-8?B?dzlORUpBMHlpL2JsL3hjRlJMb3B6ZDRZaE9BRDJMNS9OMWVhMFQycmRMd3A5?= =?utf-8?B?N0ptTzBUVGRyQ0kreFh6eUI2UnliT2V0Q25pWU5BeHBSQXRBMUM5UklvbzBa?= =?utf-8?B?c2ZIakM0b1hPNWVMUzlVbHdWeDdjZThTTmRUWDMxRmNHR0p3c0hSbzcrenRH?= =?utf-8?B?cDRqY0lBSXV1Sk9idlo4QSs4OHg0cG54VDNuRVlRdmZkTzdSbTdCcEFQSDUz?= =?utf-8?B?eGVtMGR1NGE2VFFkQjZPRmtlTG9zNHdhTStOVFg0ckhtYWQvbVNROUE1ZGto?= =?utf-8?B?T1JyZlRMYmp0NTBQdFg2LzhGUTladlhaeVZnUGpvMlRsQ3poN3Z6QjZwLzFZ?= =?utf-8?B?Q2dEOXJzZ01oRU5oekRkcEo4MkNkbWJTMW03Z1VPTTdBUlh3Zk5EQzhLbG10?= =?utf-8?B?RFM4OUcwenNCcFVtd1o3ZFZMZEVtZExpVllZUE9tNnVlNHpVRnU5STdjMTRm?= =?utf-8?B?NHo1MHMzNGhSSWVFYzdJeVRxdUE1b2N5d2F1aVM0RnpqZ2lRWlg3VGdRUDlL?= =?utf-8?B?WnlwOGszbVJ5dE9yL0NCbFptS2lIc01vTW5idEdOQndGb3NZRGx0eldzZ2kv?= =?utf-8?B?MFI4THRncXdIMzdpWm1hUHpmYmx3clZyUllObGR2THJVeHhFTitYUEZVZVlW?= =?utf-8?B?b3h5bVVRbGJIbzB5Q2k2a3RlUkJSTnVJRFp2ekpKWFRKUnNPRFVta3dNa3da?= =?utf-8?B?MXBoM2pXbHUrRTU1dkNVTjZzQk9WNVVza1RWQXVlQXFEV21HcU82Yldtd2RZ?= =?utf-8?B?dU9pcFMxSkxsZFZ5UmdHd1VOaGFqbUNuczY0Uk9vYkE5VFpiVTFXbElWTEQv?= =?utf-8?B?cUwrOS8rMU9YMWN5VXB2SU12V1dXWWowOHoxeE9kYW9yNk9Rd1h5RlphbUcw?= =?utf-8?B?amlRLzJhQzhYWjlLU3c4RGx2MUZlSWlPQmt2ZWg0dG9qYTZPQVNRU0ZwUkNo?= =?utf-8?B?djR2QUpFZXRMSmJ4WFY5cUhqL2FyWmtSN3UwY0hUaytHam9IdWhrWFEzd0ow?= =?utf-8?B?QXd0MWdzTnowUmI4YzZUcFN6Wkd5Sm56cVJKM1hobUVhZDQ0TEJLeFBXNkdV?= =?utf-8?B?bVpzRzVONUs4aFpDbWt3L0lCSVdtaG0vSmpxRDBlek1nZUl0SGtYeklVRm1R?= =?utf-8?B?ejZUUER2eUY4K2JTMWtralBER0szMFpkNEJpa2UvbUVidjE4TEZaWERVODQw?= =?utf-8?B?dFlCUTJJNXhZVk1pbmtEU1MycHJwNlEycVVBRnlPalpmdlBCdWNkWjd5cEVO?= =?utf-8?B?SUNwM3lsem5IZDRid2dmZkF3b1J6MzNDdTNLZ0gzSnF5Q1RRSjFPMUtadkxo?= =?utf-8?B?cVBJc3VFV29JUFZhZkwvNGI2Wm41cElXMXFxWUx1OE5VempIYUNBblNDeTNN?= =?utf-8?B?SEdGUThQSytuS3JBRFB5NGk4a3NNNjlhWlN5blNQTldDa05CelUrZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 30907d5b-3d46-4744-2e7d-08de5908cdf8 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 16:19:08.4381 (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: nKYPP9Jg3Qul2ipl2zWPHIDDEovzesVHx4cKEHmR94pidFtIbG4MTSdu99vqTNtJWrUvlzKbyIEGgOgfTv9AxQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB7677 On Mon, Nov 17, 2025 at 03:37:04PM +0100, Jan Beulich wrote: > It's only ever handle_hpet_broadcast() that's used. While we now don't > enable IRQs right away, still play safe and convert the function pointer > to a boolean, to make sure no calls occur too early. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné > --- > v2: Re-base over changes earlier in the series. > > --- a/xen/arch/x86/hpet.c > +++ b/xen/arch/x86/hpet.c > @@ -40,7 +40,7 @@ struct hpet_event_channel > s_time_t next_event; > cpumask_var_t cpumask; > spinlock_t lock; > - void (*event_handler)(struct hpet_event_channel *ch); > + bool event_handler; It would be nice to also get rid of this field, but I don't see any other input that we could use to ensure the channel is ready to receive interrupts. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 21 17:16:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 17:16:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210036.1521877 (Exim 4.92) (envelope-from ) id 1vibok-000181-3r; Wed, 21 Jan 2026 17:16:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210036.1521877; Wed, 21 Jan 2026 17: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 1vibok-00017u-0b; Wed, 21 Jan 2026 17:16:30 +0000 Received: by outflank-mailman (input) for mailman id 1210036; Wed, 21 Jan 2026 17: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 1viboj-00017o-FX for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 17:16:29 +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 ea45fbff-f6ec-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 18:16:26 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by CH2PR03MB8088.namprd03.prod.outlook.com (2603:10b6:610:280::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 17:16:22 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Wed, 21 Jan 2026 17:16:22 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ea45fbff-f6ec-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=zFpTqrYhsdbUQ9QB0upGA4uwLJCzEyim0Fu3PDvDHc6iKCMurnDkkCKvesUDoJDf6vJ341Oqspi+mDC+zc7vixPUGwNjUCxCPYPopV4M80MQ49KcmcjEfNBSctzt/aMwpEcEcksfU8VYhmk9y6LFIfMeN5iT8xpUM/JOEFaLKOqPE4qXT5YyOF+5EYxV8cKQ/AL4vxc/n6nDsRCKGg/CuNYtwhdPJMQMiSz+lsSMn37UBoZgQfxJKRDDzoHWREfy0CBugwWwhSecleEgwhjaKGHVp3OeCG4WCtKG24p1YDY1yK92WgYYDtS0BXkXmEiugkGkR4hV69l74e9HKWum4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OLbjfQE4Klx8uy2BarYQguK2zlMlRWrgXo0OPhjiZo4=; b=V83xloAjqhcI87Mv/JABp/mo3WUDfV3GrcrNnhg6WFQE2qpjvXEAmnIrSUZEOcaOEpuPbhYsohlhvhupMlsShcCniMJRlW3CnxyhyjwaNRnI+FZdYBdqGK3jUhUU3qEMblTdI9n4FR6J9lw7Ci1pqZ8hEpq6rGKyewaJChzZo/E59fDeXY7UVaPyWJuLwlXmQzlzT9dFIwwTXfhH0T3efjgIZc5ZSJghsHUe8p+ilYBKDBLaiKvRl0TrbnmrPCUC/0/941bwjVTiVhGSWP59adVQsVwtjhvqYkwpH7zN+A3SCwsXEE02a9wGx4e4/iXErx7WGjGZAOoxntyk6PHgmQ== 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=OLbjfQE4Klx8uy2BarYQguK2zlMlRWrgXo0OPhjiZo4=; b=eeyyRaSA6A+fJ2nPF5DSVqdI/u9ccjdJx+a+7mIaT8WwKqu0R/97RLikjaIkIKJhSOZ5z1uLCvRBr6EUtYKGXbztsb20V3F8g9bg3AHCx2o63J2CjTru5Y6rR0tHVJqfLauM+c2FeunB62/7Pszg2aQp3/vP53FRurhWesxQxzE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 21 Jan 2026 18:16:18 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel Subject: Re: [PATCH] symbols: don't omit "end" symbols upon mixed code / data aliases Message-ID: References: <9dc297d2-08f1-460a-b513-91deaecbd2d4@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9dc297d2-08f1-460a-b513-91deaecbd2d4@suse.com> X-ClientProxiedBy: MR1P264CA0022.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:2f::9) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|CH2PR03MB8088:EE_ X-MS-Office365-Filtering-Correlation-Id: b6182846-20fa-4bd8-d7ce-08de5910cc94 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?c0FLZVl0TkZaMXVpck9PZmt5TUhUeGVsZDVzSVlXMHJ4YWlUMjFaMFhkZWk0?= =?utf-8?B?ZUZTdjdBaUs2VGUzZXlYSkNHY3NBaDFPbU5tYVUrdmRZZnhDc2VZNTRxOWc5?= =?utf-8?B?eHRrR3lCYk1RRE1RdSsyTTNOOStzWDJEU2Y0ZUN3bFZFNnBtaXNOVXlnMVA2?= =?utf-8?B?bk9FcmcvWkpMN3FyUWpJUUxSM3RQMlhnSllrSko5c1pKN0puTXpJUy82OVRy?= =?utf-8?B?T3FEc2MxMGx0aVJjWmlGbWxCMUJublpvdHR6UWU4WThTQkFFYmd2eXg4Yi92?= =?utf-8?B?NStUUVJORTJnSGk1NGthSklCdlZDVFd4THBNaUNudmkrUzZtejlQTkU0dFZq?= =?utf-8?B?am8wL2xUWEx1TElhS1YramdEQ242NGc5dnJDdmF5NHhyb05OVy9weWg3TnV2?= =?utf-8?B?QXdVWm9pektRYWNlR1hVTk04TFNodTRod0R5OFY4YktlSXN2WGxaNTZVazcw?= =?utf-8?B?UU5XWm82MzZmODkzdEN3N2NYUExidG1tSURNcHRya04ycG9oRXhWazltaEFT?= =?utf-8?B?bWs0ZFhkNy9nQUM1SmRvbkpGTEhUelkwWklKbFFiN0QrdzVSbERNeTFnUTla?= =?utf-8?B?YVNFOVpRVzJSVUZ5V0doWjFpZkRVd21qalY4dDBLN2QyS1U2clFZcFZCc013?= =?utf-8?B?TnEvTGtqeFVpbXdzVC94UDVFZ1UrTU5qZk14bWpzeTByck5sdVNFeFRXME5R?= =?utf-8?B?cVJ3T0RIYmNZMHZobGhqUTc1T3lUVit6anZOYUFteVU2ajlQSkc0Sm03NDBl?= =?utf-8?B?WWZFSkVobGRkOTlMQzhaeFRLTjVBQmlPdFlJbWhGU2tjcDRDL3UwQnhlcXl2?= =?utf-8?B?UjZOSkROS3F0TGRuc0tDQ0plSUwxTFhEei94bGVZUjVrbFJCTE5iSUtTYUI1?= =?utf-8?B?TG1NR25MVFJCNlRDZElQSHpvaHlrOUVXRXFiTGZvOWlaYzJ1OHlKZzE5S2lH?= =?utf-8?B?TmRDVkVWZnd2ZHVPUm5UQmdWcGhSS0o3R0FxQ1lzZ2g1TXRQKzFiQkNEVEZk?= =?utf-8?B?RXh4OERkbE9xdHRNZXJ5NzVxRFlzUXVvN3JLazZNcStncjlUOVk2REZwRFpw?= =?utf-8?B?Y3BWdjRrRzF0c3pLYldrVEtpaWNoUUhrakRhVVZJbUp3THlBR0Yvbzh5aVVv?= =?utf-8?B?akYrZCtmSEgwQ2JaM25XMktpQUxCSzN6QnE1YkJBVGpUc2VhT2t5U2tnOTRt?= =?utf-8?B?bW0xUlpnSlpCUE1FZTM3MkpvdThwRytvODlJaEEvM0lSLzUxMTR4YUQvaEIy?= =?utf-8?B?UkJ4aVk0YlE4Wm5IWTJzQklKWlBGM0Z0d3UzbmR1Y1ZvYzdkbHBVcUdmTWNz?= =?utf-8?B?aEthYUhnUEM2MFExTzdCZzJXeXkyZzhtbkVocDlNQ0JGN0hSc0NNQzBzU2Mv?= =?utf-8?B?R2JlM1VnN2s3c3BxajRidHlSWllhcDBYVE5EMHIrMFNEMmxJYldtOHFOcmVP?= =?utf-8?B?SkhkcW9EeHhRMnVXYmcrOXRRVlRlNG9Eb1AreURyQUxuamJjcGhKcDFmYmpv?= =?utf-8?B?dHMra1FSNVJ3c1kxWGtETVZCampsZ1JjQVcwSk50WGtPMVFIamgvQU1yNHM0?= =?utf-8?B?QU9NV0dDanFYeU5MYiswVGpLbEVHYWh4anlrR0hPSUE1aVhLZzluMEQwODJB?= =?utf-8?B?aUQrcWZqTmVKYWxJOW4yMFZ0ZzlLQjY5cng5Y1NrREUrTVVMZkliY3dZRWRN?= =?utf-8?B?bE5VeVBlMVJ1N1pIWnFVSTBFVERZZkxHR3U3WnJnWXJlL2RDT3dNWDFyM1pl?= =?utf-8?B?VGxoc3I5eTc0a1NObnNjc0I5cG1Lc2ROaEd3VTBnT3hqdVB0TzNhbFo1RXNi?= =?utf-8?B?SXk2YXVPdGJkdDBoVktRUGZKRzk3UVgyVDJXMHZFR0RHZStGM3pvdUlwRWti?= =?utf-8?B?K043THpTeS9QZzJNc3p5c1RzamdmT2k5NVJPd1FCU0NhSmN3all5TkZFTnB5?= =?utf-8?B?d3UyV21zZEt5dWRaMi9zMlZnZjZ6TElSNUcyUFVYdVhlc0F0ZWMxcTU1M1lW?= =?utf-8?B?Z2dlVHhWT0ExUnRjTjV5SDBjSlI3QTB4dEl1WXk1ZWR0N3c0UkJYUUV2TTE3?= =?utf-8?B?SDFSZ0pIUkdOVnRaQTAxUlZ5clU1UFptSTVyM3B4TFhmNXZKY2VVaUREWW9O?= =?utf-8?Q?6z4c=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UGdVVDEyTGZMQVJROU5wYXk5K3JvVGNGSTE3a2hmYUp6SHdzbnFpcGtOZjJP?= =?utf-8?B?NzZLZVhXWFV2OEFWRWlFZDFsa3lsVzc1UGp5VXI1Y3NHbHBZN0lrclV0d252?= =?utf-8?B?eUVNQnppaExJbEVZNGYxbzB5OVBJS2kvWGdnd1NDcGFZMHRCdWppaG5FSE0y?= =?utf-8?B?QktrVDRwdnNTeWFXTFBEZ21tN3c0Q1NLcVdUL21ET0dxVHN4QjZ4R0Z3ZFhH?= =?utf-8?B?RWVmam1oS3JlNHNud2RwaDFoY3h3OGxON29QcGZqV2MxelhYUzFUeGNZSlRN?= =?utf-8?B?Z2VacWNJclVhWFUzRXg4M3FCUFplOXV2MWFPc3c0ekZWeFVpVXBFVkxjQkNx?= =?utf-8?B?Wk9BbHpWa1ZOb0NmUU51V2dkYnBTOUtCcFpYelVLdm5NUnI1Q2xTUHdOSDdZ?= =?utf-8?B?YldDQldSVzVPMlFjY3R4TnR5L3RHNTFET1lPZzd2ck05eUxTeVVsbmR2R21a?= =?utf-8?B?NmZLanhCUzE1Y0c1QTJMV1Z3NGtZR3RwdUMweENtaUtFK1h4dTZQNHhMejlY?= =?utf-8?B?aDdTc1hncU5mVnY1SG54KzUzcElacVk3a1NHMDdnUG0zSmtnQUVKcDYzdEx3?= =?utf-8?B?TnA0QjJpUFpwZU1QV1lKRU5MTDZlQVdzT2VFRU56Mmp4SUNsU2lBTkl1N24z?= =?utf-8?B?eVpuUWxqRmhpSkxickVRUTlTd0VzVU05OTlGR1ZScyt0WnFSV3VzS1pjNkNs?= =?utf-8?B?ZmZSbDRVYWhmUVR5WDBBajdqQ3NJUThmRDg2SExFZTYzeFVESFpmRE56bk5V?= =?utf-8?B?cnIxeHgyZFVnTlRNZCtGYXVvQm9wTmhPR1JBQitldFhJRDRFQXZ2Qnl0ZlF4?= =?utf-8?B?OHlkV2taOWhLc3VIVnpnMHJKSFNqUEVaUzU1ZWxpWk90VzVCRG44cGNCSU5F?= =?utf-8?B?bDhISkd0dEVSVzA5RFZJRkFsOVErOUNrZUFaTlh5d0FpWENnbHgxYkpCa0c0?= =?utf-8?B?VkNvbWU4bnU5T2pnVUR4TlBUM2NSL0I0eUphWHZkMHdGdVZMUnlPYWJQaEJw?= =?utf-8?B?bDFCeW9kd3NmMmplaXY4NEpTSXR5ZFN2NHBzUTRhVUQ1R0hPN3lyK3VjR29J?= =?utf-8?B?U2JLaUs1c3o1bGZ5NWhrUFppTHkwb2tKc0s4OTFhUndIVG1DcTNTTmN1d29m?= =?utf-8?B?ZHEwUTcxS2xhS0FjNjlzQnRNSnB6VlFQZWRRdmlKZnI5Wk9MdU1kdEVGMFhx?= =?utf-8?B?NGtpd3NVM2NsUnBzQkNqSUM4aTY0YWZOSVA2SnAyMFNuS21aekJxaGRGM3E5?= =?utf-8?B?Sk1EZjhKVm1yTkxUSUxuQXZtL0pkSmxFZzU5RlJDMHV0T0V4cTA5Z2w3Z1Zy?= =?utf-8?B?WjZjWHVpT210U3BDTG0rTTROSlord1RuUTVzdyt5NEtXbVhoczU2Rkl4YU9N?= =?utf-8?B?Y3ZpZVNDdHYxUUR0ellUaXpkTkk0MDdXRGR2WmNlN1hFd2tYSVhqaWJ4cmZV?= =?utf-8?B?RUJJaGN0L3NkQUlvcXFGT1hidG11Tno3VHVkT3JpYlpUQUYvQnFRc0F2Y3NH?= =?utf-8?B?b04yRHhWdGFJSkE0d1lvNFN0UmFHS0ZIbGZtbjgvVzdkMzAxaGtxMWQzOXp6?= =?utf-8?B?bElISXJRdENPL2xkOXpGSVUzNUJDSm9CTFN1U2pQdnM3c1NocVNhcjAxQzBr?= =?utf-8?B?NWtDQUJSRDRuQW1FNUd3Q2h0NVlVVVpTOTFVMVRTWGdCL0JGUWdoYm9aTUth?= =?utf-8?B?T2dTOHB3NThGaVY5Y1VlaTI0dWhTRG8rNzlseHpLcGNLQndKazRiRDB4c1N3?= =?utf-8?B?MmU4aVlLWjlWMXlPVmNWQVA5TUFUU0xKQ0ptOWE0cjBQRUpTdlpUNkU1enhD?= =?utf-8?B?WEJuaFdla29UT0R2WDlnc3dMbWFwNFBsYUZ5TXI0OVEvZDJOQTJPSldBNkc1?= =?utf-8?B?RVFCcUM5a3E5YXNwMmx5bjRsVEEzcE9hSEZGd3FtU1FCd0tidm1VbXNDL2c2?= =?utf-8?B?cEpHZm56b1lwakNtN05kajVHZVZ0bjc0UlBoSGpKQW82NWEySHU2OFlGOWw3?= =?utf-8?B?NExlanJBUGFMR2lacHlDc1FaWk1xSytranFGb00rSUE5NkF6V21uNFdYK0NR?= =?utf-8?B?YmFTRHRBdldDUS9aUFFuUytGSlRodHJxcWVCRjhRMDBqQkRWRm9sVFdZVUpw?= =?utf-8?B?ZnkrZUN5L3BaNXo5SUlwLzc4dSsrWEorS0lINy8yWG82TzVMOWQ0S1MzQ293?= =?utf-8?B?NHZRM2xHQlA5c1R3Y1ZJWk5DTElOYzZEOHhHMS9vcVdQMkJJYUE1SUtGRDli?= =?utf-8?B?S0N0bkpKZjZ6S2h3Z0t3dHByNm1RUmZpNFVqTUpMblV4WW9HR28zbHJWTmt6?= =?utf-8?B?eDdSZnNNcVNYWkl2QmdnM1ZmY0JaYXk2RzJtNUEreitLZEhCcWg4UT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b6182846-20fa-4bd8-d7ce-08de5910cc94 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 17:16:22.0989 (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: 9Ig9k7OvRZcLnu4s2/yU8c75bVmxao94wHB+TNEih/4+EDJ1SZboD5CAN6HR79sBlAH3F/lt3dghh0MLc9sEkg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR03MB8088 On Wed, Jan 21, 2026 at 04:26:03PM +0100, Jan Beulich wrote: > At the example of _sinitext - that symbol has four aliases on x86: > __init_begin, __2M_init_start, __2M_rodata_end, and whatever the first > function in .init.text. With the GNU toolchain all of them are marked > 'T' or 't'. With Clang/LLVM, however, some are marked 'r'. Since, to > save space, we want fake "end" symbols only for text, right now > want_symbol_end() has a respective check. That is getting in the way, > however, when the final of those symbols is 'r'. Remove the check and > instead zap the size for anything that is non-code. > > Fixes: 6eede548df21 ('symbols: avoid emitting "end" symbols for data items') > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné > --- > Roger, just fyi that I think that this change would mask the other issue > that you reported, without actually adressing the underlying problem. > Hence both changes will be wanted. Yes, it does indeed mask the other issue. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 21 17:22:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 17:22:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210048.1521887 (Exim 4.92) (envelope-from ) id 1vibtz-0002gr-Nc; Wed, 21 Jan 2026 17:21:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210048.1521887; Wed, 21 Jan 2026 17: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 1vibtz-0002gk-Ka; Wed, 21 Jan 2026 17:21:55 +0000 Received: by outflank-mailman (input) for mailman id 1210048; Wed, 21 Jan 2026 17: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 1vibty-0002gc-2R for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 17:21:54 +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 aaa4120f-f6ed-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 18:21:49 +0100 (CET) Received: from SA9PR13CA0163.namprd13.prod.outlook.com (2603:10b6:806:28::18) 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.9542.10; Wed, 21 Jan 2026 17:21:40 +0000 Received: from SA2PEPF00003F64.namprd04.prod.outlook.com (2603:10b6:806:28:cafe::d) by SA9PR13CA0163.outlook.office365.com (2603:10b6:806:28::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.5 via Frontend Transport; Wed, 21 Jan 2026 17:21:40 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SA2PEPF00003F64.mail.protection.outlook.com (10.167.248.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.4 via Frontend Transport; Wed, 21 Jan 2026 17:21:40 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Wed, 21 Jan 2026 11:21:39 -0600 Received: from [172.23.120.160] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Wed, 21 Jan 2026 09:21:39 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: aaa4120f-f6ed-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iEBLTQdLaZzI0i1ut6Fx4yJ9s7Tk88mZHKX9kXeXizDcHMFsF8R26SvsS3153g3M2ngVO5QuBNmQQZOuyUVBi6S0W9Av12F8jQVOzcNftOtvP2siuAfAYJM+sq3mbNWAJU61hXZd3WejnzxOKbWSBPcXdygrBWFoPmyMEQTr3stnifljDCAk0KZTEOjXxs6bwUWUXyXtugWKud+iSTsS9llyyYS9v2hH1DA7njjFu+coE6+fDfSC9GB5druKKTHgiNgOWzS7qVdATntHrAGrJ7b1cwhVN1TKQOkgmV20RbfxXSbnLdivR0ZaUihVGWH5mDetWJRUJqgxsfg2xeqMEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=K2PBgN1DZxFQMsLGYC42x1npEsrXcOCJE54+BbmokI4=; b=F8VO/MhqnP6SZZO+yNzl89PgqSCxgqwEv6NDTw6WA+TLIV3aGiSF4TljaliSSYE/TLh2ZzrMei2WgzLg/SypxWJczSUITAs5v/HbThXpBDcEehEmITdkcvOHPfwUraAnvB4Z/JWQUrfpCt1c3aDpSobf6NjrXt+AHu8YlY125jTrpOr9KTRg1OHDkRps5GDFm1ylfKs4ArEvswMvahi5gS6ZDyDoHxA8rvqpzHxdYCj4ZxTw5d7XLOScUJ6fKqoYHT4NI3GRAkgHMl5iHhK/8JCpGieHlYnTOT3RlV+fmwoKxvpeYhErjJ0WODlFlbqLewis1rHKeHNmnUXOo5aZUg== 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=K2PBgN1DZxFQMsLGYC42x1npEsrXcOCJE54+BbmokI4=; b=dGK8EDgO2xcHfW4qdrl9odzpLGO3ZFWlOzg3fq/KQeOEZObzOL1C4szHyW95v00eCm5TEob9rR36j9OwnZLzR1DHA4FVqD2T7lQEr6Y2wh2wWgoi2BSDMie3iidajyucFgtIclOqz9G0t96gUtEujcWCcL/hUIcqBzEQiUsvwWQ= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 Content-Type: multipart/mixed; boundary="------------3R2aBtpkKtA2sevLQ5GxD4pB" Message-ID: Date: Wed, 21 Jan 2026 12:21:33 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Partial revert "x86/xen: fix balloon target initialization for PVH dom0" To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= CC: , , James Dingwall , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko References: <20260120140648.25977-1-roger.pau@citrix.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA2PEPF00003F64:EE_|MN2PR12MB4334:EE_ X-MS-Office365-Filtering-Correlation-Id: b75fe344-7d49-4cd6-58d4-08de59118a4f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026|4013099003|4053099003|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?NGRJSHVPQ0Q1MHN5MVpXdENUMWl1dXhSRE5DTWthaGgwdkVGQnIxcnpmdkJQ?= =?utf-8?B?OXJpNW9pVUVNYlRYQjlnWmQ0cGRoMWVRNXBQeVBFWE9lZk1mMDV6eDVuQktz?= =?utf-8?B?Q25OVnJRM3A4ZEtUV2dwMkxRM1A1RnhnUTVPR0RoT2FwRFlkYktBV1o0dHZM?= =?utf-8?B?WmQ3WHBld1E3KzJxTmJHVWlsZWRUS2JVVFltM1U1dWM3QnNWd2xnMTlKWjNu?= =?utf-8?B?SkI4V0QzVFZIZllzcVl1Y3ZEa3pNei9QWFVhbGxrakZlZW5jdGZxdFZxRjFp?= =?utf-8?B?Y1IxTDlkRDR3VStxTDEyTFZ1LzVzaW83a3FjWHkyZkVmTk9vRXMzWnlsZmFC?= =?utf-8?B?MVJJR2pVYTJnbkEyTUpMVEJta29vN1F3dTc4WjVPZStvdmtKMjBoL2Z5TGFZ?= =?utf-8?B?MnlYZEI0bDczVDl5T2JEQjZzMitNTWxHbDNNL2w4OVJwK3B4UWFoMU9obExU?= =?utf-8?B?VDY5cWN2dnY4cGdsdXUzVnRMMWJxdlpoMzJTUE40b3hPM0ZyMjZpMWdEeVQv?= =?utf-8?B?NlpjSEEyNG1GbFNWVVJ4L0RScUtIcTI3QzZrbFZQcDNWWGo2VWxUWWtlOHVu?= =?utf-8?B?OGNnelFRZHRGU2ZiWnlURmt1bk4ydmVFTmdQNFNmSHdpSkkrb1ByWnE4eXlE?= =?utf-8?B?bW8rb1NFVHlmWkJoRG41dmlyNHJpdWZJZVNiNDRsNmIxMU5Cenc1SjBLSXhy?= =?utf-8?B?emxnREQzVnB2bTFIZUpUek81eWdleTA4Nzg2bmlHSFZhL29xR2Q4NENCSVZH?= =?utf-8?B?OERsNis2Z3ZuY3VoQ2NhbnhoVDJoSzNKZ2Z0aUlVaXRWaU9SNEJNY2dWZXFh?= =?utf-8?B?dFRtd1R4cEd0aVd5SHlmM0dJWTk0TkQ5NnZSaDZrU2xVQnNkbWlySE02ZDcr?= =?utf-8?B?cG1WSDFrYnJid1lpaDVQMTVTQXNoejV3MGJRbFkyOFVqQk9sUGpNN3BRZWRj?= =?utf-8?B?QWVleXVjM3pxYm1jcTZjNkVJajA1anJFZ0RpQklLMmowQldtVDlkckZKZ2NP?= =?utf-8?B?dkFBVXVKZHY1MFdOVFBJQldLR2VVbXY1by9UNmttQWFMUXBSMU1xZFBvdGRP?= =?utf-8?B?RjM4bWJLS1hZcko2ejZ2Z3pXSXRmKzFmNFhzTFNGVzRHYURkMmt4OXRTa2J1?= =?utf-8?B?eGY4VVlMK2NIYW1Ub0lGQ0JrNDlQR09lUVIwKzY1d29LcnVGZUpMbUNvdm1Z?= =?utf-8?B?NWEwU21LcDhWVzNGbEdxK0pUZUdBVHFSdHdTTXZVcmR3anBwa1hRV29PWkxZ?= =?utf-8?B?VEJvbUg3WVVDSnNCc2RCRXEzWDdHR20vc3FZRm15N3Y4Q0dxbnEwV2xvQWJF?= =?utf-8?B?N25QMmh5NmdnNlgvVGxUakF1Vm5jNHQ1RnVYUmFqODZNL3MzVDdZL1Uya1dX?= =?utf-8?B?WFV5cEI2b3JBcTRPOGRZUUFoRVFSVG9YT0luUk1yMmpMcVBGR2VZaHMyVGkr?= =?utf-8?B?Nm1FOHU0MGVxNjZkQks1NFhpMnFsNjgrT256bFRBSXBRVTJ3T0d4dVFHMXJD?= =?utf-8?B?VHJ1dTA1Q09LU1NmUEQrM3EvbzBsRzVhOEtTZnZUKzYwMG1kSjVsbmduU2s0?= =?utf-8?B?SmY2SGdaZXh2ZDVqZmlIQ1ZWRWZITGFSQmxWNVhVaGZQRThmYkZCWVVuYzE0?= =?utf-8?B?cWZ5Uk8yOVhTaXdxL0JJaVQzb2c0T2dMQjdGeTNycnZTYW84a01HM2l1Q0gz?= =?utf-8?B?SUl1RGdKNGlvd0lUdDhHUGNJYzh6bjgvNFZPOTNVeWFqemFtdTlxUjkyY0VE?= =?utf-8?B?aXBYWWNGRDMxTlpPMkNnVEJGNk5VRkNYeWpiQnlKL1R4ejgyYy9Ubm43cGQ3?= =?utf-8?B?ckRORjBhNStaVzlxb3hBRFZ5V1F5K0R5eEpnS1RKeHFYNE5QYTA4U0VBRXJo?= =?utf-8?B?MWNMcVdGbjZSMnpCbkoyN2pJN0tHUHBWdHlSdlp6VG41YkJaTUVsN2dUTk94?= =?utf-8?B?UFdiRW14WkVkS1ZGRFJXMllsYmc4VEl0VFJxSjNlK1F5OS9oTkNkUG41SERM?= =?utf-8?B?R1hFOFlySEZCSUxVNGtjTmV6UWE1a0NBM0gvN3RuT09xMTBxOXpsdHcyOXFN?= =?utf-8?B?QlZiMitwTVJiWE9oS1J3U3ZnbWgyU1hZelNCMis4Y1lKTmJOZzAxNmxvdGRl?= =?utf-8?B?emF2M0k5TGFpYmkyM0Z2dndHdWFzaUxpSE1IemFtRDM1amdURytaQnNmQXdX?= =?utf-8?B?VzNzUnZRN2ZXMEJ5MmUxTkdxOENkNXYwczV6R2dabkhQVForMWJENXZpV2hW?= =?utf-8?B?MzhaMGhRc20rWG5mTTY4RkZiVUdnPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026)(4013099003)(4053099003)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 17:21:40.2334 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b75fe344-7d49-4cd6-58d4-08de59118a4f X-MS-Exchange-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: SA2PEPF00003F64.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4334 --------------3R2aBtpkKtA2sevLQ5GxD4pB Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit On 2026-01-21 06:17, Roger Pau Monné wrote: > On Tue, Jan 20, 2026 at 03:10:06PM -0500, Jason Andryuk wrote: >> On 2026-01-20 09:06, Roger Pau Monne wrote: >>> This partially reverts commit 87af633689ce16ddb166c80f32b120e50b1295de so >>> the current memory target for PV guests is still fetched from >>> start_info->nr_pages, which matches exactly what the toolstack sets the >>> initial memory target to. >>> >>> Using get_num_physpages() is possible on PV also, but needs adjusting to >>> take into account the ISA hole and the PFN at 0 not considered usable >>> memory depite being populated, and hence would need extra adjustments. >>> Instead of carrying those extra adjustments switch back to the previous >>> code. That leaves Linux with a difference in how current memory target is >>> obtained for HVM vs PV, but that's better than adding extra logic just for >>> PV. >>> >>> Also, for HVM the target is not (and has never been) accurately calculated, >>> as in that case part of what starts as guest memory is reused by hvmloader >>> and possibly other firmware to store ACPI tables and similar firmware >>> information, thus the memory is no longer being reported as RAM in the >>> memory map. >>> >>> Reported-by: James Dingwall >>> Signed-off-by: Roger Pau Monné >> >> Reviewed-by: Jason Andryuk > > Thanks. > > I've been considering what we discussed and as a separate follow up we > might want to attempt to switch to using `XENMEM_current_reservation` > for dom0? It might make the accounting in PVH dom0 better, as that's > what the toolstack uses to set the xenstore target when initializing > dom0 values. Yes, I thought that could be a follow on. I've attached what I have tested, but it is based on a branch pre-dating xen_released_pages. xenmem_current_reservation with PVH dom0 seemed good without the xen_released_pages adjustment, but I don't know what that would be for a PVH dom0. Regards, Jason --------------3R2aBtpkKtA2sevLQ5GxD4pB Content-Type: text/x-patch; charset="UTF-8"; name="0001-xen-balloon-Initialize-dom0-with-XENMEM_current_rese.patch" Content-Disposition: attachment; filename*0="0001-xen-balloon-Initialize-dom0-with-XENMEM_current_rese.pa"; filename*1="tch" Content-Transfer-Encoding: base64 RnJvbSA4YjYyOGFkMGViZTUyYzMwZTMxMjk4ZTg2OGYyZjUxODdmMmY1MmRhIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKYXNvbiBBbmRyeXVrIDxqYXNvbi5hbmRyeXVrQGFt ZC5jb20+CkRhdGU6IEZyaSwgNyBOb3YgMjAyNSAxNjo0NDo1MyAtMDUwMApTdWJqZWN0OiBb UEFUQ0hdIHhlbi9iYWxsb29uOiBJbml0aWFsaXplIGRvbTAgd2l0aCBYRU5NRU1fY3VycmVu dF9yZXNlcnZhdGlvbgoKVGhlIGJhbGxvb24gZHJpdmVyIGJhc2VzIGl0cyBhY3Rpb24gb2Zm IHRoZSBtZW1vcnkvdGFyZ2V0IGFuZAptZW1vcnkvc3RhdGljLW1heCB4ZW5zdG9yZSBrZXlz LiAgVGhlc2UgYXJlIHNldCBieSB0aGUgdG9vbHN0YWNrIGFuZAptYXRjaCB0aGUgZG9tYWlu J3MgaHlwZXJ2aXNvciBhbGxvY2F0ZWQgcGFnZXMgLSBkb21haW5fdG90X3BhZ2VzKCkuCgpI b3dldmVyLCBQVkggYW5kIEhWTSBkb21haW5zIHF1ZXJ5IGdldF9udW1fcGh5c3BhZ2VzKCkg Zm9yIHRoZSBpbml0aWFsCmJhbGxvb24gZHJpdmVyIGN1cnJlbnQgYW5kIHRhcmdldCBwYWdl cy4gIGdldF9udW1fcGh5c3BhZ2VzKCkgaXMgZGlmZmVyZW50CmZyb20gZG9tX3RvdGFpbl9w YWdlcygpLCBhbmQgaGFzIGJlZW4gb2JzZXJ2ZWQgd2F5IG9mZiBpbiBhIFBWSCBkb20wLgpI ZXJlIGEgUFZIIGRvbTAgaXMgYXNzaWduZWQgOTE3NTAzIHBhZ2VzICgzLjVHQiksIGJ1dApn ZXRfbnVtX3BoeXNwYWdlcygpIGlzIDczMTI0NTU6CnhlbjpiYWxsb29uOiBwYWdlcyBjdXJy IDczMTI0NTUgdGFyZ2V0IDczMTI0NTUKeGVuOmJhbGxvb246IGN1cnJlbnRfcmVzZXJ2YXRp b24gOTE3NTAzCgpXaGlsZSBYZW4gdHJ1bmNhdGVkIHRoZSBQVkggZG9tMCBtZW1vcnkgbWFw J3MgUkFNLCBMaW51eCB1bmRvZXMgdGhhdApvcGVyYXRpb24gYW5kIHJlc3RvcmVzIFJBTSBy ZWdpb25zIGluIHB2aF9yZXNlcnZlX2V4dHJhX21lbW9yeSgpLgoKVXNlIFhFTk1FTV9jdXJy ZW50X3JldmVyYXRpb24gdG8gaW5pdGlhbGl6ZSB0aGUgYmFsbG9vbiBkcml2ZXIgY3VycmVu dAphbmQgdGFyZ2V0IHBhZ2VzLiAgVGhpcyBpcyB0aGUgaHlwZXJ2aXNvciB2YWx1ZSwgYW5k IG1hdGNoZXMgd2hhdCB0aGUKdG9vbHN0YWNrIHdyaXRlcy4gIFRoaXMgYXZvaWRzIGFueSBi YWxsb29uaW5nIGZyb20gdGhlIGluaXRhbAphbGxvY2F0aW9uLiAgV2hpbGUgZG9tVXMgYXJl IGFmZmVjdGVkLCB0aGUgaW1wbGljYXRpb25zIG9mIHRoZSBjaGFuZ2UKYXJlIHVuY2xlYXIg LSBvbmx5IG1ha2UgdGhlIGNoYW5nZSBmb3IgZG9tMC4KClNpZ25lZC1vZmYtYnk6IEphc29u IEFuZHJ5dWsgPGphc29uLmFuZHJ5dWtAYW1kLmNvbT4KLS0tCiBkcml2ZXJzL3hlbi9iYWxs b29uLmMgICAgICAgICAgfCA5ICsrKysrKy0tLQogZHJpdmVycy94ZW4vbWVtLXJlc2VydmF0 aW9uLmMgIHwgOCArKysrKysrKwogaW5jbHVkZS94ZW4vaW50ZXJmYWNlL21lbW9yeS5oIHwg NSArKysrKwogaW5jbHVkZS94ZW4vbWVtLXJlc2VydmF0aW9uLmggIHwgMiArKwogNCBmaWxl cyBjaGFuZ2VkLCAyMSBpbnNlcnRpb25zKCspLCAzIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdp dCBhL2RyaXZlcnMveGVuL2JhbGxvb24uYyBiL2RyaXZlcnMveGVuL2JhbGxvb24uYwppbmRl eCA1MjgzOTUxMzNiNGYuLmZhNmNiZTZjZTJjYSAxMDA2NDQKLS0tIGEvZHJpdmVycy94ZW4v YmFsbG9vbi5jCisrKyBiL2RyaXZlcnMveGVuL2JhbGxvb24uYwpAQCAtNzEzLDEwICs3MTMs MTMgQEAgc3RhdGljIGludCBfX2luaXQgYmFsbG9vbl9pbml0KHZvaWQpCiAKICNpZmRlZiBD T05GSUdfWEVOX1BWCiAJYmFsbG9vbl9zdGF0cy5jdXJyZW50X3BhZ2VzID0geGVuX3B2X2Rv bWFpbigpCi0JCT8gbWluKHhlbl9zdGFydF9pbmZvLT5ucl9wYWdlcyAtIHhlbl9yZWxlYXNl ZF9wYWdlcywgbWF4X3BmbikKLQkJOiBnZXRfbnVtX3BoeXNwYWdlcygpOworCQk/IG1pbih4 ZW5fc3RhcnRfaW5mby0+bnJfcGFnZXMgLSB4ZW5fcmVsZWFzZWRfcGFnZXMsIG1heF9wZm4p IDoKKwkJeGVuX2luaXRpYWxfZG9tYWluKCkgPyB4ZW5tZW1fY3VycmVudF9yZXNlcnZhdGlv bigpIDoKKwkJCQkgICAgICAgZ2V0X251bV9waHlzcGFnZXMoKTsKICNlbHNlCi0JYmFsbG9v bl9zdGF0cy5jdXJyZW50X3BhZ2VzID0gZ2V0X251bV9waHlzcGFnZXMoKTsKKwliYWxsb29u X3N0YXRzLmN1cnJlbnRfcGFnZXMgPQorCQl4ZW5faW5pdGlhbF9kb21haW4oKSA/IHhlbm1l bV9jdXJyZW50X3Jlc2VydmF0aW9uKCkgOgorCQkJCSAgICAgICBnZXRfbnVtX3BoeXNwYWdl cygpOwogI2VuZGlmCiAJYmFsbG9vbl9zdGF0cy50YXJnZXRfcGFnZXMgID0gYmFsbG9vbl9z dGF0cy5jdXJyZW50X3BhZ2VzOwogCWJhbGxvb25fc3RhdHMuYmFsbG9vbl9sb3cgICA9IDA7 CmRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9tZW0tcmVzZXJ2YXRpb24uYyBiL2RyaXZlcnMv eGVuL21lbS1yZXNlcnZhdGlvbi5jCmluZGV4IDI0NjQ4ODM2ZTBkNC4uNDBjNWM0MGQzNGZl IDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi9tZW0tcmVzZXJ2YXRpb24uYworKysgYi9kcml2 ZXJzL3hlbi9tZW0tcmVzZXJ2YXRpb24uYwpAQCAtMTEzLDMgKzExMywxMSBAQCBpbnQgeGVu bWVtX3Jlc2VydmF0aW9uX2RlY3JlYXNlKGludCBjb3VudCwgeGVuX3Bmbl90ICpmcmFtZXMp CiAJcmV0dXJuIEhZUEVSVklTT1JfbWVtb3J5X29wKFhFTk1FTV9kZWNyZWFzZV9yZXNlcnZh dGlvbiwgJnJlc2VydmF0aW9uKTsKIH0KIEVYUE9SVF9TWU1CT0xfR1BMKHhlbm1lbV9yZXNl cnZhdGlvbl9kZWNyZWFzZSk7CisKK2xvbmcgeGVubWVtX2N1cnJlbnRfcmVzZXJ2YXRpb24o dm9pZCkKK3sKKwlzdHJ1Y3QgeGVuX21lbW9yeV9kb21haW4gZG9tYWluID0geyAuZG9taWQg PSBET01JRF9TRUxGIH07CisKKwlyZXR1cm4gSFlQRVJWSVNPUl9tZW1vcnlfb3AoWEVOTUVN X2N1cnJlbnRfcmVzZXJ2YXRpb24sICZkb21haW4pOworfQorRVhQT1JUX1NZTUJPTF9HUEwo eGVubWVtX2N1cnJlbnRfcmVzZXJ2YXRpb24pOwpkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4v aW50ZXJmYWNlL21lbW9yeS5oIGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL21lbW9yeS5oCmlu ZGV4IDFhMzcxYTgyNWM1NS4uNzI2MTlhNzVmZWQyIDEwMDY0NAotLS0gYS9pbmNsdWRlL3hl bi9pbnRlcmZhY2UvbWVtb3J5LmgKKysrIGIvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL21lbW9y eS5oCkBAIC0xMDQsNiArMTA0LDExIEBAIERFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKHhl bl9tZW1vcnlfZXhjaGFuZ2UpOwogICovCiAjZGVmaW5lIFhFTk1FTV9tYXhpbXVtX3JhbV9w YWdlICAgICAyCiAKK3N0cnVjdCB4ZW5fbWVtb3J5X2RvbWFpbiB7CisgICAgLyogW0lOXSBE b21haW4gaW5mb3JtYXRpb24gaXMgYmVpbmcgcXVlcmllZCBmb3IuICovCisgICAgZG9taWRf dCBkb21pZDsKK307CisKIC8qCiAgKiBSZXR1cm5zIHRoZSBjdXJyZW50IG9yIG1heGltdW0g bWVtb3J5IHJlc2VydmF0aW9uLCBpbiBwYWdlcywgb2YgdGhlCiAgKiBzcGVjaWZpZWQgZG9t YWluIChtYXkgYmUgRE9NSURfU0VMRikuIFJldHVybnMgLXZlIGVycmNvZGUgb24gZmFpbHVy ZS4KZGlmZiAtLWdpdCBhL2luY2x1ZGUveGVuL21lbS1yZXNlcnZhdGlvbi5oIGIvaW5jbHVk ZS94ZW4vbWVtLXJlc2VydmF0aW9uLmgKaW5kZXggYTJhYjUxNmZjZDJjLi5lODZmMGRjZDdi N2YgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVuL21lbS1yZXNlcnZhdGlvbi5oCisrKyBiL2lu Y2x1ZGUveGVuL21lbS1yZXNlcnZhdGlvbi5oCkBAIC01Nyw0ICs1Nyw2IEBAIGludCB4ZW5t ZW1fcmVzZXJ2YXRpb25faW5jcmVhc2UoaW50IGNvdW50LCB4ZW5fcGZuX3QgKmZyYW1lcyk7 CiAKIGludCB4ZW5tZW1fcmVzZXJ2YXRpb25fZGVjcmVhc2UoaW50IGNvdW50LCB4ZW5fcGZu X3QgKmZyYW1lcyk7CiAKK2xvbmcgeGVubWVtX2N1cnJlbnRfcmVzZXJ2YXRpb24odm9pZCk7 CisKICNlbmRpZgotLSAKMi41Mi4wCgo= --------------3R2aBtpkKtA2sevLQ5GxD4pB-- From xen-devel-bounces@lists.xenproject.org Wed Jan 21 17:22:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 17:22:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210056.1521898 (Exim 4.92) (envelope-from ) id 1vibuV-00037X-Vi; Wed, 21 Jan 2026 17:22:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210056.1521898; Wed, 21 Jan 2026 17: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 1vibuV-00037Q-Sr; Wed, 21 Jan 2026 17:22:27 +0000 Received: by outflank-mailman (input) for mailman id 1210056; Wed, 21 Jan 2026 17:22: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 1vibuU-0002vb-Lc for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 17:22:26 +0000 Received: from DM1PR04CU001.outbound.protection.outlook.com (mail-centralusazlp170100005.outbound.protection.outlook.com [2a01:111:f403:c111::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c0b9e4ae-f6ed-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 18:22:26 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DS7PR03MB8241.namprd03.prod.outlook.com (2603:10b6:8:268::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 17:22:23 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Wed, 21 Jan 2026 17:22: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: c0b9e4ae-f6ed-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lsWM9C4FU7yyj0obhNdgq5YDT91qFH/8vHaXiKsH63A486khHJn2+vMLwutWamGnDp4Jldm7eUWs30BZp3wvdpXj7xXElv3E8FOnuBOBgl0CmjgFxWuOTSAiMMmf6k0IzRLTwnxhQmcTwqT3t1mzr3vVmHwkpSLAN3qZSNDyfcE0Ak9OBKcmcAltKbUTrHekTa6GXW0ln+sCYm0BEbmGZu1YJCKLk+d5qbNpeMFOhv6kt5uq1Cbs9q69Bs7hMaMrlH7GZBzbPFP6Ibv8Pq4qziGNoLGtvbNofY6R0j3rRHD9tOXwdZQDzJQuBfeH1my7IVGdoX8kxlU9RXKVIhHwPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5zGftGTYjP7yuwq+tx02Mk2FlcNJSw+Iwt+/cRGtx7w=; b=gimVI4YSgVKcvDYlPgGNo4sm01Bu9nhmPiefrzR5Itdq4mOeFIhDCW5Aiok14OelWfU2xRuoj4/PUp9Qjk2XRJHLiHGBgjs26Li1WqWSHLPwseuF3SQu4sXRkmnesNNMDpte9VTsC+wFq5oWizVDwrL5KeJi2up7DQWI0EnBmdmirAc305NZNQeVV8uUJXcwigweb3i9xGt8vUc6LZg4WRpSlQiXiva0VX1MP4644ICq1k2bcQ3rarYOr4a4OvikaDRYBGVW3oi4wIae7MLRdFRB6ieWiSYS10wv8RG7McjpbZUJWUS/SgnXd7KP5ypE57x/HfXEHEQEdPlOTdrMhA== 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=5zGftGTYjP7yuwq+tx02Mk2FlcNJSw+Iwt+/cRGtx7w=; b=cJbmrM2/38iTLzbsvAObqDVuA9kR1abTreCSJPhDs1HBjqfCcuf3a9lh/FefW9NPeedfMkQ+eH7RIRRXPPopeDgWrQ5TtBD4AKeIgYITd88bucLqE3JJVI5z/ot/K2gmdT35tyINplHb+y4xS7sRZQFrDrxBwTm+H1jaVQ1PPPY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 21 Jan 2026 18:22:19 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel Subject: Re: [PATCH] symbols: ensure sorting by value yields reproducible outcome Message-ID: References: <980b3fe5-ce30-449b-8e0b-d0f6e91dc688@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <980b3fe5-ce30-449b-8e0b-d0f6e91dc688@suse.com> X-ClientProxiedBy: MR1P264CA0154.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:54::20) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DS7PR03MB8241:EE_ X-MS-Office365-Filtering-Correlation-Id: a8148c24-a5c0-40c2-887d-08de5911a3ca 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?MDM0Q0hVYVJRakRwVlBFR0tyaXNPYVEwUE1xaGxwUVQvb1FHdWFCQ1J1ZlVa?= =?utf-8?B?ajB5WFpselZHN3dmdmhocW5iOEE0MS9aTXErY1h4QlhNemUwdlFMWVpuRlhQ?= =?utf-8?B?YXRMd3VkYXlPdUNacXdPcVhPemhwcVRWOUc1aVpma05DU1dvNUlCdzlIQXc0?= =?utf-8?B?cVhleWRvYkdYV2ZSVDJ1VFlUNW00eE9lSjBGNHhFb0J2SHFkR0JGSTFrU2VN?= =?utf-8?B?NFdvb2xOa3BlQkVPL2tUWGV6UE9GS256NllMWVk5bVV5QWd4RUdHVjlFb3hI?= =?utf-8?B?MVdGbGJMNG5MckFRNVhEVVdRWHBRNU9mZTBxZExyQjQrbUQ0azBDdUJ4THYv?= =?utf-8?B?eHNqV2JHOW5RaCtReGQ5dVBVN0VaSFRhSXVkUHdEQUxnZ2Y1TzNzeHZZSjJl?= =?utf-8?B?a3dxaXBZRDUzcTYzWURTNlczSDI4TUQvQzRRK1RtckN6MGZTSmIzeHJqSURa?= =?utf-8?B?dldqSWcwSGZ2NEcrb2t1YTE2UzY3MGhQOHZ6b3lCenRvcC9TSnpxR3pxRWxy?= =?utf-8?B?Z1lucVpMcFZNdkQwWUh5ZDhDMkc5QTc1enZTaVk0MXpMaENPaDZTK2U5VUJO?= =?utf-8?B?QzduYWhhdFdxeUg4WGhNT0NyNkY3eEw5bUVhNWx6ODlpSkpwRFZ4dkh5MDh3?= =?utf-8?B?UkpicXAwT1BDZGpsU0ptbXNMY01RTDBza05uVkhoeHpDckRvKy9NRFpJcFE3?= =?utf-8?B?b1d4WVROMWdNUEtFK2txNlozL0xoZEpsZUlObnpPWDF4KzlnTTJrbkFNWVg2?= =?utf-8?B?cUZlQnhqNzFWRkR4T0Nsbm5sUnV5L253dk1wN1djeGpRUS9aVm9ubkZnZHBM?= =?utf-8?B?VHlXR2MxMVp6d0FIUXpzb1ozTWErUUFBdGg1MlQ2emhDQlY4WUNSVGZrUWVm?= =?utf-8?B?YzRDSHlPZUNZeGNHaHYwVXd2cDdDQkZzL1ZSVDZvbll1bTFmcWZNb3Fna0hX?= =?utf-8?B?eG5sbjdNbk5vMFBQR0gzRWFZTW12MXFzQ0o3dGR2NERLOU1aQlN1UUpwT2pr?= =?utf-8?B?Z0toUk5PZ0p3OWVPbTRkOW1WenVTR01QU2ZIK1JhY1lhVWtka09JbS9lRWN4?= =?utf-8?B?VmlRdTFzMTk2R3dDdWtBWThocTQxU3NyYXFpTThUeXI4V25Rd3A1cWtTY2pi?= =?utf-8?B?bWpaWmYydy9ET25DWnBkalVRY2VKSm13Mzg0VXpJWDdkL0NjNW9nOVhONVFT?= =?utf-8?B?dnFabi9TYmdrVlBaa2xUV244cysvOXFsbmFzOVo1ZGZuQVBvWHUyaGRpVyt4?= =?utf-8?B?bmZrL2NvaHUvOVpIVTFwY2lrWlArc1NwZnJXeCt3eVptS2tKbm1NWlpjQW9l?= =?utf-8?B?UGhIQmVpSDA4K282Zy9hRktmNHF1Y216dVdzcW5DUUt1RFVha0pLN2tQUTJR?= =?utf-8?B?V3pQYzd3NEhLQ3hTREZidUhlaWZmRE1mL1NYQmw3U1JWNHJ6VnpnRkpRRHlh?= =?utf-8?B?R0kvV2dJRndZaHdCeW4wb1VUS0t4ai9QMm8yVFZ3WHgwVjR6UFlaMzk5Y3kz?= =?utf-8?B?cVZFZnlFdG9FUW5UaGJEclFyeVJoZFEwTU5qa0J0ZkhiK2N4bmJtM2oyc0xH?= =?utf-8?B?dmJnRkdYem5vZDdzdVFkNUF3SHh1NGUveExpVGNDZ2FreTdJQjVUSUFsU0lX?= =?utf-8?B?aTh3UENaQzJUWHNlVkdQTU1uUVgvNjZSN0kwN2RYUyt3c1dNdFlzQ3BWK2RR?= =?utf-8?B?KzFBYzRHbCtOMm44Zi9RR1NOZEhGYlR4MXFuM25sRnJ5eVhmSHNpSm5qZm5D?= =?utf-8?B?S216R2dlNUppRWNlNmZ5ZzN4V2RLanZHSTY2clZsSlgyTkJ6NkIyanlsY2N4?= =?utf-8?B?RmswQkFwWkFvVWtudGNEM0tIaG1yN3BnRjNjaEFFTC8xYU9NeCtmUGxwRjNw?= =?utf-8?B?QzVuajQwbHY2c2IrMlBFUW4ycnFETEZIcG9aa2ZLRGNhc29sc1AxaUFoS3Vl?= =?utf-8?B?MC9rOGNIV0tXcjZaZ1k4RU5mM0ZZc3BBcVJZYUZXNFRkRnRSNERQTnZydVgw?= =?utf-8?B?ZVJGMXdrTkNDUml6Y1FTSkllc3F6ZmJIYU9vY2ttaWxyOVV1ZDAvWmY3WVlY?= =?utf-8?B?Wk1JT2ROWStyY1NnTERKZzdncmtLMmN1aUVyODVteWpVSWhSbVBqdjk2QzBa?= =?utf-8?Q?jBEI=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?V2hHVEpyVW5kODgxVmpwYjlvdDVaOEZTMzY2RlVDaUYyelNLM1RQS1RTdGJJ?= =?utf-8?B?STc2UFFKZlJGeXZKSi9kYnpPczdkQ1pPdjRmUE5CTTcrbnlJWE5hRmF2Uk5w?= =?utf-8?B?MmZmSmprRlZHSytnN1BFeEk2aEw0VVl5elArbTZDTm0xUjJQRWlxdU53VDdv?= =?utf-8?B?VDFrVHI3ZTdZRWtxVHNUd3AwOHQrdEVEcmpWVFY5NWtBZlREelBOTkZnMnlz?= =?utf-8?B?Nmh0MFdwQjBjODV4b1I2QzVadXBvMVM2UnZDN3R3OVV3Q2N5Y004OTdpalk4?= =?utf-8?B?WDNJaW9YZDE0WnhPNUdPVXJpcTduTzhJZ05WTXIvU3pHbTNUVkVCWXRoeWJE?= =?utf-8?B?TWcwRjAveVYrY3dra0xob3UxWHdNVlE4a1c2eTJMK21OTWxQaVlZYnZma3JI?= =?utf-8?B?VytmOVJRazZseFRLZnpuWUJSazFNN01PRjAvRUMwZGtvMnI3ZEpPN3JPajM4?= =?utf-8?B?STZhYWhmbUE2VUVuV2NReElWaENLNkRneldFMUFUUGVpZitnMnRHd3VacDNq?= =?utf-8?B?YXM0QkJsdHZzazR3a3h4ZkxzWmNEbGlxUGpsZFhXU1hiVHoxV1dsdlY4Z05H?= =?utf-8?B?Ym9aMDUxSU5xTkJjODBmdEJ2eW1WVWVLdGVnS0k3cTk3RW5oMWVadHdlOUlN?= =?utf-8?B?NHB6L3oxdEY2Rk1PaU5YN3JJNmU0dnJxVkxmQ2VXVTlTNlhyODZidDJzdjla?= =?utf-8?B?aDMweG5sYWw1ZG1tT2JXcUtHa0pOYnIyUjFBQmdIYm1EU3lFZjRRTW82UmtL?= =?utf-8?B?cnRRNlFsSmhiZGloQTZWQ01WN2UvclQ3dUxXVFhNN09zanlFZzVrc3dxSFYz?= =?utf-8?B?Qk52eGRxcm0vTURaTWp1bWhsLzUrTlNEcWl4YWFWRmkxdnRoOWdGY3JvaE5I?= =?utf-8?B?NHJIZzNpWk41bXNhUGU4TklFM0NRMUVFSXNWZ0FWSGkvaG1TQWtWR1ZzNnJT?= =?utf-8?B?U1pDSmt5Y2hnanNZWUNBTk5JbzUyWmw5V3ZLb0ViY2tDQjE2TVZmeFVuNHpo?= =?utf-8?B?dUFCb0hkRHdZYWNGNktpckxIWEN3bEx5dkdaVHNDQkRBVmhtb0YvQXJJWFBR?= =?utf-8?B?bklVRGFObEFxeSszNktsY0ZDWS8vWUdqZzBsWkZlV1A5QmdPSkVsVkp6bm9D?= =?utf-8?B?NU9xbzI1UG9RQkNkb3d0RU1kL0JQWmh1Nk9UMjUxNmc3Q3phZTBTaUV6WWJo?= =?utf-8?B?VDRtbVVMeHpzWVJzanlxRzl3Sm8vT2ordXFsNEZqL0llcTUwcTF2VmQ0RDF0?= =?utf-8?B?Y1cveW5sTk1NYnF0VERRQk9qbSt2bnQvaENaRGo0SjNDR01qL0JOcmZ6NUJj?= =?utf-8?B?WitDWWwxVnpoZHN4NW1UVUxXNS9tOGNtTno4M0lqVUhOTUU4UVFydDErUVNi?= =?utf-8?B?K29MVHhlZGkzYnBGZW1yYVBWMzJHWCtidGVqdUV6N2V3RjhNdlJLNTlJbUZ6?= =?utf-8?B?Q0NsL1Q2NFU1MXhyd2dJazZMNHNLd0JWYk40U2tMOWlrTVkvNWRpRzJrNVN1?= =?utf-8?B?QnZENjlUZ0M2cFZKY21UTTg1MUZZY0xhK3Y5Uzdnd3VrSjRocmNDL29idGVi?= =?utf-8?B?a0paUHNkL0E3QW5EeFFtbkVveURyTnZhUlJjWHBvOGRoZndRRmhFZHBTbWJr?= =?utf-8?B?SGo2MzZMZTQrazAvNjlXeVNpWmRHN3ZyYURXUTZ2eDZmQXNGZFduTmRQZkZ2?= =?utf-8?B?Tm9jaDA2bWJXZHozYTIzcmtDVE9hUi9tSm1kbnFpMnUwN2R3M3dsQ0g4eFlY?= =?utf-8?B?L2M1a1p3U25WQ25xUnhORVpjQmhPay9EWnBBakhxRmhiNzRaMWVUb1BPMmZG?= =?utf-8?B?WGdzc0V4L3Bta0Y3VjBxNXVpRlczYzhKclZodzk5dC95V2k2MXdQaWpuWmll?= =?utf-8?B?QWdQSjdZSHA4bVZ4d0JkWHJTa2dFZkMwZmVrb1dNNnBERUhmSlgySjk1RWZQ?= =?utf-8?B?citJcnQ3ZkgvdjhvQzRVWkloT1U0RnZSbnU5RjhKTlgwZ3dILy9rd2ZhQTN3?= =?utf-8?B?MjlDdHZyREhkbjRJY3c3d2NIdlc0TkxMeWlBZU1FejNFVHNKdENqTmdCTUpz?= =?utf-8?B?cWtTVWRCZTU0NTJqYkg1djFxUEF3QzZiMkhYVC9YM09FSTQwUzhlMHZuM1Qx?= =?utf-8?B?SUZWSEpXRnJuZ1VvRGpYTkQrQUJQU3N1WlhyZmZCcUJZSmk4MXNmdzRMWU83?= =?utf-8?B?R1F6U0FhVkc1MlVybXdUTG1URGtEQUpxdXpDVXZEbVVNQjlibVRON2s0S3N3?= =?utf-8?B?THdSMm4yL0Q3ZDUzazFEMnAzL1hYbEtOYnhQc3padkdvb3JwYUZXUUoxdU1F?= =?utf-8?B?TE1TZFRqeFM0UE5qNWV2R2tVVG42bkh3Ni9yK3FrNGY0SDZyeFdxUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a8148c24-a5c0-40c2-887d-08de5911a3ca X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 17:22:23.1621 (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: J4RJEpTY+Ge+s5+1Ef+mIb+ki/IwCciNwh5h+mcE5ZbPunmgcwqKjiLuNiOZOiRgyxClOr81S09x5gCko5EFgw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB8241 On Wed, Jan 21, 2026 at 04:24:43PM +0100, Jan Beulich wrote: > qsort() implementations have freedom towards actions taken when two items > compare equal. The latest with the introduction of fake "end" symbols, > inconsistent sorting between the 1st and 2nd run can lead to extra "end" > symbols in one of the runs, making the resulting symbol table partly > unusable. (Note in particular that --warn-dup or --error-dup are passed > only on the 2nd run, and only for xen.syms, and that option has the effect > of doing a name sort ahead of doing the address sort. I.e. the inputs to > the 2nd qsort() are pretty different between the 1st and 2nd runs.) > > Make the result stable by using original order to break ties. > > Fixes: d3b637fba31b ("symbols: arrange to know where functions end") > Reported-by: Roger Pau Monné > Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monné > --- > I can't exclude the unreliable sorting could have other bad effects, in > which case some much older commit would likely need referencing by Fixes:. Lacking a more clear indicator I'm fine to use the current Fixes reference. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 21 17:34:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 17:34:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210080.1521908 (Exim 4.92) (envelope-from ) id 1vic5b-0004zd-1F; Wed, 21 Jan 2026 17:33:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210080.1521908; Wed, 21 Jan 2026 17:33:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vic5a-0004zW-Ut; Wed, 21 Jan 2026 17:33:54 +0000 Received: by outflank-mailman (input) for mailman id 1210080; Wed, 21 Jan 2026 17:33:53 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vic5Z-0004zK-FY for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 17:33:53 +0000 Received: from SA9PR02CU001.outbound.protection.outlook.com (mail-southcentralusazlp170130001.outbound.protection.outlook.com [2a01:111:f403:c10c::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 594e98c9-f6ef-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 18:33:51 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA0PR03MB5579.namprd03.prod.outlook.com (2603:10b6:806:b7::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Wed, 21 Jan 2026 17:33:48 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Wed, 21 Jan 2026 17:33: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: 594e98c9-f6ef-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=GLM2V7Z+rej+B/ebLn6K/ZJdMhWWqLOaKcjlAsXXwjmqnpVhF0ANl6VlXmr9nHZExqJAybnKKx6k6ZuHxgnCL1MGAFX8TBZIim9XXZAwa+lm2qEJZc3fMfEmFQaBupiLKlHfGyLubkQoN1g2M1cWaJOQ7NijU5faoOK3agY3oyneVaR2iPqmVZcFK1gziQl+RHz8ByBMCOddj6qoUiVdnIDi3eDES4LoSstqVyrS2oNvCoj1pRE+JTvgoyFZ15861S4PeEZPsLUUzpvxl0x8ESieCc46mGEkPVUoBCNp47yoavYxD3T3pdI77Bb6a3Z7FXNARFhB7uml70usCkSDsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5mlf0EoKlcLPA4FV/FDAgNfurSltHR/Tz60fc3BYg4Y=; b=mkI41il5Ogw5GwLWJu+FyOg+vOgGkv2oLXaftJm9InCsqe0iF7f9LIAbXB5DjH1PY0/My1KxjMTBCUXRfHsrJvBouGON0lwTLWSjIMIMApccfQ1aw34UZBMVY1giMewp4nNU5vwqujAr7aXlBsZj+oOnl70UVL9LgPudHzUlSQ33x+OJCMNKQzbC2tfn7cY8hi5hOmZ7o9VjZidoIhi9lEqiK4Hezek1BK3+haeqhAecs5AVrlM3J2xItorCgP4nhtfs8wE6h/FqUfFInYQ3P/hirqmxCCao78WULZN4k3vuGx2949F6B66XAkgMqdTo6CBjj17ABYAfUfmfHHca3g== 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=5mlf0EoKlcLPA4FV/FDAgNfurSltHR/Tz60fc3BYg4Y=; b=Hn39StSSAo8UrMSo0WKuyslgKq3EfmWFG8mJx43wDnDYkfqR6Py78++mr3Jfz2Yz8K17VSdbkXOTbgy/L4b9Ua+c5+bo+4XYmW5cMIpR1p7NKErZBh9g7nT7/l6fIiNUh4a07GudbMiZBV0srWgaHRI6cw8Y8SjcY7VEa7L3yGU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Wed, 21 Jan 2026 17:33:44 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: Re: [PATCH v2 1/3] x86/svm: Add infrastructure for Bus Lock Threshold To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260121142857.39069-1-alejandro.garciavallejo@amd.com> <20260121142857.39069-2-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260121142857.39069-2-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0363.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18e::8) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA0PR03MB5579:EE_ X-MS-Office365-Filtering-Correlation-Id: 18adff49-8fd1-4b13-8b4b-08de59133c0b 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?WnZoSDlZL1RVdEVvbmE2MVB2VGlNK3VVWTU5U1FIMGh5RjRZTkFhRmdWSHk2?= =?utf-8?B?ZXdjOG9adW02WUd2ZExxZkp3aTd5ZFVibStBODJheENkOHovK3dMM3FxT2Rj?= =?utf-8?B?bldkODFJM2x6Rno0bS9CMDVPbjR4dnRGbU1DM1hKR3lyaWRFeEcxU2Yrc2Zw?= =?utf-8?B?dTdaVUN4amJWNTFxbnJvbU9ma21nWkE0NkRJTk1YamxkWUVwNytWc0ZJd2cr?= =?utf-8?B?c3cxdEt0REhGenFrZ0RldFpxWERvQTJZUU1yVHg3M0FCWGN1NmlXU3VuV1NS?= =?utf-8?B?d0tVQzNJUUVFM3JGYlRNVCtjOUljaXYxWTNNNElMTG0zTzljdFA0TjZUQTlE?= =?utf-8?B?KzBLZ1VJYmt2V2hKUzFPSFhiM1grRFV2KzFOQWx5UGJ6emJFK2FYbXRMaENn?= =?utf-8?B?RnRxTDhaZ2lZV2tJRWVOUVJJM2txS0NBOTVsUldTaTB6eUQwc0oyaW9CclBT?= =?utf-8?B?NUtwNjg2Z0VCakJPMjg3YmlqUTdhb2VGb21BaFZVOEFpT0ZJV1gydmxISWxP?= =?utf-8?B?d2NNd1VhaDJNekVITGYrcHFyR1NLOHMvTWNoRUVyVnkrb0xDaU8zS3pnZXMw?= =?utf-8?B?ZUxZT0U1aC9zbHpzNm5SOFFuRkdXc1Z4dDR2bERnL2kxanRjWHFMV0lsdEsw?= =?utf-8?B?V08rNHZpcDVZT20xSUxWbS9BVXcyMnpiWVE2eEFjcGQ3cFQ1c2hEZXhsd2Ex?= =?utf-8?B?UmhvUFVRRENaOW42eWJUb2pXM05RRHVpVWpWTmxMZ2RRUFVXOHg0enJ6QURY?= =?utf-8?B?QTVnVVFQUjNzYnFBRExBR01WalRzdXlRUjFvU05kUXRYZU5NZWwwd1RhSmlt?= =?utf-8?B?RFFkT21ycDJkZE5Uc3FXTGZhcXRDVU94bVpJYTlUN28rNTYxWTlVWGFZWmpj?= =?utf-8?B?TEM4eEYxNE94VmNwdDlqdldhM3FDRFo0OUdoMVREdGpEaUlJaS9pWUxuMW5J?= =?utf-8?B?b0hnbm1DWXlYcW1KOHZkSFN0dlJIeENIKzh2WjhBR3cyVFJqd0RmMjBobFpZ?= =?utf-8?B?cHhVck9pb0VPUVJuV21RNW9LUDAvUDdGZ1h3RXM3RTB1TUU0VlZ6Y0Fxb3lP?= =?utf-8?B?YkV5ZXdlRkY4TllDN1c5cnV2eC85Z2hBL0ZGRzVrQ0V6THNUVlBVSlA0Zkdk?= =?utf-8?B?RmZOUjNSZ3BrUUZHN05ncTNTLzcwTzdHbW5OajUvckx2cHUrS0F0dDN1NXFQ?= =?utf-8?B?YlQ2WDMxSG5uR3FZcnFvdE5ySnVkZXp6c3MxdENlSEVPTTdxYzNUMCtJcGIx?= =?utf-8?B?RkEzdnlZYS9YVXd2RkVXbytOSkQ4RTgyRGFja1M4UStJMUxzblFaTlRWcFpl?= =?utf-8?B?Sjl4eGpndklsZzA2cFhqYmlGQ1ZMQ3NVYUJvemozSVFrUFIwekhlbjZka0Jx?= =?utf-8?B?NFRyWlNyT2lxd2prTkUvaEJjeEpZZzgxY09FMEVXZzhmZTFPbnp2WWlGbVhS?= =?utf-8?B?Y2lRNXBKRW1TR2FuQWdWanJiMTBwR1ZhcTVkMXpkVzFPRVNTYnFrMHV5ZVox?= =?utf-8?B?WFJMNEVvMkVpQUtnYWtQNWZtUkRzOE1Wb2dIbHlyZldVcnc1c0RZN0p6cGxY?= =?utf-8?B?ampodlgzeE0vaHMxSldHeEduUmtjN003T2t2aUdQS2M1TnpydzNhOVhoc0RK?= =?utf-8?B?L2t3TXRpeWhTN1I2T3hLaUkxeEY0bnJEVFE2UWx6elVTeFd2blQ2bkc4c014?= =?utf-8?B?bStra2FUQW1TVm9IdHF1UUQxQUcxRU5neERwTHdkK2RQVFJESFRZMmVyZHhp?= =?utf-8?B?Zm9mTEZIM2dleTBxNm0wSlh1cFF2bHFUVGsyR25ENkoxQ1lBVFFYemZRdjdB?= =?utf-8?B?MndQSGNnRnd2Y2lGajNYTDZGVFdsNDFRUnd4S0pQT2JWOGI4dHdyZVF4WjVi?= =?utf-8?B?a3R2alg5VmRMWUVuTlg4VWVqVVdwdURXaFlPTUdYbXZSM3ZrU2xlT0YrS29Q?= =?utf-8?B?YkRPRVZob2hoc1BwSmFRdGNVLzJCMFdoNnY5dG10SWdaNE84RS9mZkU2SkNG?= =?utf-8?B?N3dNTUpWd1RLdkJYNThGVFJDdnV5ekdMSmU3ejVOTjdjY0RocnlMdURjc3hN?= =?utf-8?B?b21Ed1h3N3hMOHl6VkgrMFI3RlFXU3FCdHpZSTFlSGY4RW9LY2wxc3d1M3Jy?= =?utf-8?Q?oMsI=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ejJ0QnVnYXdpY1VUdUR3am0xdVp2MXZONHdCNWFyQ0xOa25UcFAybUdjbzgr?= =?utf-8?B?ZWRFNkpraVNrRjRuUVhFcituMW8zMlR5WjdGOG12b0hRdUlFUnJjVnllbkV1?= =?utf-8?B?TjllZExCRnA0SWhqTXRlZisrVFVlSjlJQkV0amRrZkRRODk4UHlUdjJYVGRo?= =?utf-8?B?bGYvT1RHT0oyNmQ0MHVReEhLTUcxUXl0OW9DakVYZGRYS1FOeW41WTNKQk90?= =?utf-8?B?Nk5YU3cxY09GOUlCNjNYdGZhVEU4YWh0Z2NpV0tmLzdqb2p2QWVUYWpkOE9r?= =?utf-8?B?eFJuUnRkVVlMOXJhMTV6NDA2VlBvdmpQMzFBUHlEYzRMQXFBOUMyWTNjS1V3?= =?utf-8?B?RlhVTTMzTzJHdGZhbUFhUTJyWmFmckwxWGhtK1kwTkw4c3pGc3ZOUGlDS3JV?= =?utf-8?B?ZnRYUGc1aXN0RGs1cUxmb21jbGlCVnVyYmhuaHBEY0ZwaU1VeDYxeER1WEg5?= =?utf-8?B?UnVidDFEb0FWN0Y5ZVpzNHBrN2JMZCtWYXlhT2x2N2o3c2FCcHJmZDJ3U2dn?= =?utf-8?B?ZmVPOXFDMmZpZzV1cGRZRUZIYmErd2FZL0x0YVJ5c2ZPeHNoRVNnSE1jN1Rv?= =?utf-8?B?YXRzcXlrTHArYzV2Rlk4bmp4WXdYb28wM1ZWNDE3OFFMa0NlOUI0aW9zc3dD?= =?utf-8?B?akZqQWc2MUdwNnlTUHEzOVlVRzJTemFZYXlzUGtpd1BmNmxNT0tlNlk3cjlW?= =?utf-8?B?S0JRSkZJZnFsd2tkNEpmU1hDaUgrT3RVYnNheXdOODkvV2NKWnVSMlVHQTFl?= =?utf-8?B?RGV1ZUZHUXNzUHZTK25uNXR1emhnVzlDMEN1ZCt5THNTZWNJVnN6MGV3R2pM?= =?utf-8?B?Q0k3UHBNSW50WFlPeWVFeWluWms4WGdudTN3RXRLa3hTSldXMStVdUJsOHNo?= =?utf-8?B?ZmcwQVV0NEJKSlJIS3VlZlRoMkJHWXVIWGM3NXNvbUlLd0lCbng5WnY0NGhP?= =?utf-8?B?bnFLV3NCQjd1NVNBcnlZc0x5TC9vTU9iY2xiY0Y2OGhpMGphK0tVanVEMUEy?= =?utf-8?B?OXdVRHdNSDQ1TDRxNlQwZmhNMVBZWjNUcDlkdkI0S3Izb1hoRjJuZDNOOFNK?= =?utf-8?B?Q0FnQ1NycmVCdEhybW1qakJKbkFKdlg4WTFod0RYaTZYYWRqamd1RjJ6MElC?= =?utf-8?B?WDhpSk03WExkY3lFUzF6RXA0cG5TRVhDVkEwclRONmRWcFZtL1JuWHovR3BX?= =?utf-8?B?TmlGQXdPZWdSdXlNWExjTkJiS1RSSXhIV3MveGN5Zkd3S1FyaUFFNSs2WThM?= =?utf-8?B?TGFMdVVkRk9VYjQwL2NUQ1lrUHBrSDFaQWtwcmlxWHppVkNkZ3Vid3dRbG43?= =?utf-8?B?UTh4WHhjRlZVeVlmVkVVbkNMdUhDbFRkNDNpckc5V3RrMklBZWU3dW96UGNE?= =?utf-8?B?VWF1V2E3Mnh3MXcxdkFtTURRYWN3eE9UcEpWcUN4TTc1ZS8yaVpzMi9MeTRr?= =?utf-8?B?QldMa0xURmYxYlBUWHgvdkJWTmJoR2dBT2dJemhreHh4bXdZRG95enN0ZXgx?= =?utf-8?B?Nmt5ampNMHZ4RlgrUHluVUtJWFhFWkxoaHU3K1pHdmJOejlkbHZ3aGNUbDcy?= =?utf-8?B?cUIrT3YvOWVUU3M3a2dwWlVBTnY0dTlsU1NLOFNONDhUZllmQzgrSmNGNVBD?= =?utf-8?B?ejQwZGpKMGpFZ2VQZWw5RHFEc2s2L0hPTlBZWXJpU0RhMUhwT1p6aGtmb3Ri?= =?utf-8?B?bndvVUpUMmNsVUZnbDdHaURWanJQV0J4U3VSVFQzeFpLRGlwNU9QaFNjRzNr?= =?utf-8?B?ZTh1WXNMZVZwN0pLWGYwNkF1VERMK2xsWXo2cDBxYlRHNlQwYmxqVjFVSkhX?= =?utf-8?B?SHRSOXo3MitzTEcyTzNCQXNod2F6Ykp0Wnh1aWR3R0U1SG1ORys0Tklud1VM?= =?utf-8?B?ZXY5UG5SZkE5NHBJUmRiQ09zaU5mTHBlWGtFTmxmVHFScWtrRXg4UHZ3bFZZ?= =?utf-8?B?UmlZZFpHd0VsUGRFSWQ2S09MVGovVy9XT1JYSlpmb2gzU1IwK1dHOXV5YW5U?= =?utf-8?B?Y3FQcTIvV01DLzVvcFdwNG5teWZTYXhjNk1GbTVYVWdJTWxoRStyQytiSHlL?= =?utf-8?B?RlN1WUUxT0wrcThMVDVmak5lU3JwVUprZkExRmtPN3JkTE8yYXp4Vjc4ZzNu?= =?utf-8?B?RWN6aVN0ZTlZbks5dHNDUEYxeFZEbkdGNFRzZFRrbFZVNVpMbTNmbkxYNXhM?= =?utf-8?B?ZFZxVDZEYjQ3UzdYS0NQc0YydVNOU2RhVFBRMFplUWtucjhUOTBuYjVpUzVR?= =?utf-8?B?dnM2dStVMFc3V0lVQjI3MXhqbTYzQVZHaDJ5R1Y0YkJPa3k5TE5vWFhPc2pE?= =?utf-8?B?YWpJVWQ4NkV2ck9uSjh0ZkVKQ1JRMzlqeFBQM01La1lyQ1lUdU12UT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 18adff49-8fd1-4b13-8b4b-08de59133c0b X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 17:33:48.0646 (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: jp+ddHeaY19/mMOyRCAXHABdgzzGpHJzO/N2K1rCjtKGI1VeDQIKt5r4FmlfGjzI50UYIR/w9tpfIRn+o7YSsEsv9mSDrkTMGv5otQVy9TU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR03MB5579 On 21/01/2026 2:28 pm, Alejandro Vallejo wrote: > Add missing scaffolding to enable BusLock Threshold. That is: > > * Add general_intercepts_3. > * Add missing VMEXIT > * Adjust NPF perf counter base to immediately after the buslock counter > > Signed-off-by: Alejandro Vallejo > Reviewed-by: Teddy Astie > --- > v2: > * s/general intercepts 2/general intercepts 3/ > * removed _thresh suffix > * added missing _svm_ infix in the SVM feature > --- > xen/arch/x86/hvm/svm/vmcb.h | 15 +++++++++++++-- > xen/arch/x86/include/asm/hvm/svm.h | 2 ++ > xen/arch/x86/include/asm/perfc_defn.h | 2 +- > 3 files changed, 16 insertions(+), 3 deletions(-) > > diff --git a/xen/arch/x86/hvm/svm/vmcb.h b/xen/arch/x86/hvm/svm/vmcb.h > index ba554a9644..231f9b1b06 100644 > --- a/xen/arch/x86/hvm/svm/vmcb.h > +++ b/xen/arch/x86/hvm/svm/vmcb.h > @@ -65,6 +65,11 @@ enum GenericIntercept2bits > GENERAL2_INTERCEPT_RDPRU = 1 << 14, > }; > > +/* general 3 intercepts */ All these comments are useless.  I'll do a prep patch to delete them, so they can't be used as a source of patch nitpicking. > +enum GenericIntercept3bits > +{ > + GENERAL3_INTERCEPT_BUS_LOCK_THRESH = 1 << 5, > +}; > > /* control register intercepts */ > enum CRInterceptBits > @@ -289,6 +294,7 @@ enum VMEXIT_EXITCODE > VMEXIT_MWAIT_CONDITIONAL= 140, /* 0x8c */ > VMEXIT_XSETBV = 141, /* 0x8d */ > VMEXIT_RDPRU = 142, /* 0x8e */ > + VMEXIT_BUS_LOCK = 165, /* 0xa5 */ > /* Remember to also update VMEXIT_NPF_PERFC! */ > VMEXIT_NPF = 1024, /* 0x400, nested paging fault */ > /* Remember to also update SVM_PERF_EXIT_REASON_SIZE! */ > @@ -405,7 +411,8 @@ struct vmcb_struct { > u32 _exception_intercepts; /* offset 0x08 - cleanbit 0 */ > u32 _general1_intercepts; /* offset 0x0C - cleanbit 0 */ > u32 _general2_intercepts; /* offset 0x10 - cleanbit 0 */ > - u32 res01[10]; > + u32 _general3_intercepts; /* offset 0x14 - cleanbit 0 */ > + u32 res01[9]; > u16 _pause_filter_thresh; /* offset 0x3C - cleanbit 0 */ > u16 _pause_filter_count; /* offset 0x3E - cleanbit 0 */ > u64 _iopm_base_pa; /* offset 0x40 - cleanbit 1 */ > @@ -489,7 +496,10 @@ struct vmcb_struct { > u64 nextrip; /* offset 0xC8 */ > u8 guest_ins_len; /* offset 0xD0 */ > u8 guest_ins[15]; /* offset 0xD1 */ > - u64 res10a[100]; /* offset 0xE0 pad to save area */ > + u64 res10a[8]; /* offset 0xE0 */ > + u16 bus_lock_thresh; /* offset 0x120 */ > + u16 res10b[3]; /* offset 0x122 */ > + u64 res10c[91]; /* offset 0x128 pad to save area */ > This wants a matching hunk: diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index cbee10d0463d..8734fd2bca11 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -430,9 +430,14 @@ static void __init __maybe_unused build_assertions(void)        /* Build-time check of the VMCB layout. */      BUILD_BUG_ON(sizeof(vmcb) != PAGE_SIZE); + +    /* Control area */      BUILD_BUG_ON(offsetof(typeof(vmcb), _pause_filter_thresh) != 0x03c);      BUILD_BUG_ON(offsetof(typeof(vmcb), _vintr)               != 0x060);      BUILD_BUG_ON(offsetof(typeof(vmcb), event_inj)            != 0x0a8); +    BUILD_BUG_ON(offsetof(typeof(vmcb), bus_lock_count)       != 0x120); + +    /* State Save area */      BUILD_BUG_ON(offsetof(typeof(vmcb), es)                   != 0x400);      BUILD_BUG_ON(offsetof(typeof(vmcb), _cpl)                 != 0x4cb);      BUILD_BUG_ON(offsetof(typeof(vmcb), _cr4)                 != 0x548); Despite all the comments, it's very easy to res[] arrays wrong when splitting them like this. I can fold on commit. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jan 21 17:38:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 17:38:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210092.1521917 (Exim 4.92) (envelope-from ) id 1vicAA-0005b4-Ic; Wed, 21 Jan 2026 17:38:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210092.1521917; Wed, 21 Jan 2026 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 1vicAA-0005ax-Fj; Wed, 21 Jan 2026 17:38:38 +0000 Received: by outflank-mailman (input) for mailman id 1210092; Wed, 21 Jan 2026 17:38:36 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vicA8-0005ar-Jg for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 17:38: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 01da070e-f6f0-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 18:38:34 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by MN6PR03MB7549.namprd03.prod.outlook.com (2603:10b6:208:4ff::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 17:38:30 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Wed, 21 Jan 2026 17:38: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: 01da070e-f6f0-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xmV3FKSDMQNi4Jiw5DnrbkwUiZ3Ije58o7Vv0TlX7Qn+d016Y5+TZNP8SPH9MtZmKNJ3vuoP3sSKSOVYXRRvaZeZA+8H+4bdYKbog6pgaVSmq993kg0ZwHZ/zSeX+QhmOpdUPb4YG+VqegjFXBp6kloTbMv9BJXhFFG96tpEfJF08x2Lt9D61EcPEv77wrSf15Dml6zZqlG56zlDcw2jShD8JL9fyLG2J0faVgmNPB4eILrszGQqrSX3Usdx5AjsbvYZlMCJ7vEWSLyABhj7nYJC80s/t4MkSstUoYeZqN1SSi7B8+alGvUwPfka7+K4nl0puOkJuzjgrYec46ZGkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=r6A+lY0SRR4CJo46JRobHYSeSuuY3PRPG+P3sN2Bx4M=; b=l8LgJThAGXrIE/Yv26EZLlARCciHwdKstgFGtmMtJf/srRsNlYLQz8kVxo15Lj3b3rLCvTVcYXlH5tvGyKBN3c0X3bzl1Dbugr49DVVQxLEdD0sCGgvRauNi0/1Xz80Ii4HjY1ARnJuw3Htf8LpWnN19yne8Lb7mXhyoHKA+CRjQoBKomBRrQqNSWwYfoxhtE45VM9z57QKmInAxSjBKmbR8puCNuzcJNFqdj1nFWFQeO7FO5GoXIyYTTZ3aqE+oyhb3e3VlP1zQXzE7ZyNFaqvGSguGUHDyxKm8EjERTjArWSOLEme+xvehezmfiimUVvqWCho/LOeJkS4A7eEbUQ== 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=r6A+lY0SRR4CJo46JRobHYSeSuuY3PRPG+P3sN2Bx4M=; b=zAfIHuTSySi8j0wNqDBMZgDhv4exG6VDoUP9HSQj7uCftSDLvyweQOTV9GVv86bY3ybSnSo24hMb/v7n5iSxb6HHUbOd5c7LZZsHtXgU1PeB4Fj419IRtqQLd9cNdJFFbDQCAX1czZYx/AbmAJo5SUVmN/f1+wMmWHz2xWBue6w= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 21 Jan 2026 18:38:27 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel Subject: Re: [PATCH v2] symbols: check table sizes don't change between linking passes 2 and 3 Message-ID: References: <7e550d03-13c3-4607-bfa5-1a4bd57ecef6@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7e550d03-13c3-4607-bfa5-1a4bd57ecef6@suse.com> X-ClientProxiedBy: MR1P264CA0022.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:2f::9) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|MN6PR03MB7549:EE_ X-MS-Office365-Filtering-Correlation-Id: cf9ea854-5d57-49f1-b3d7-08de5913e467 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?SHhTeUs5T0g1SEhWaER2ZjBLenVWTVJ6bjkrLzBGWENhbHlpZll3WU5aZHly?= =?utf-8?B?T2VCRTg1VS9PeGk3ekNtNElPMTUrMy9NdFVLbXAvU3NCZzY2YXhhalVFa1pW?= =?utf-8?B?dDJQSGY4WlNNUFd6VTFGV0I0d0xFRjk0SWcvaFQraG9nMGMvWHlSU29lM2h3?= =?utf-8?B?RDYrQW9WbmRoSUNXQ1FhbXBPWE4wWXh0VFZHMVFTNE81K1BqdnhtT3dUU2hs?= =?utf-8?B?dWd3SFZFU3Z3dG1UbEthU0N6NzQxNkgvUmg1Mmpud3NQd1RFanlBMjl1eFVJ?= =?utf-8?B?elpOTmRwbWsyeTJJR293MHJvUnNkVndzY2tkQ0FNdkdNenJkZmptRVpqSHBx?= =?utf-8?B?RzN2R1V4RWpVbE85bE5BelAwWTYzQkdGdVl5eUpPaldHQW1OUUNVYmhobkNO?= =?utf-8?B?cGRLUDlQS0ovM0dZL2NWck9JbWxPL3BnZFB1T0JnZHV3L3RmMTBzY1RYY3k5?= =?utf-8?B?RVNCeUkyRE1yS2J5SVpJV0JPbDRQTjg3WnY4KzRLZ2dpVGlHZ09WYmZHSnJv?= =?utf-8?B?MXJZaWI5R3pSbnhvRExKdFFaMld2L1FQOEx5NmNWVHBHVUtNWmU1eHpKNFYr?= =?utf-8?B?TXdGamF4UXZkT3djUHBJTXplbThiQjUyM0grUlFlc0pKMG9FNXVKaVVUR1p5?= =?utf-8?B?MXpSK3A0czgrbXp2K3h1Rm55dmtUejVwVUxrb3VLTWQ0ekZFcmMreTY1bkFE?= =?utf-8?B?N3NLTDVVV2xSbGp4SzhIby9YeEp6YmQvb3lPYm9zZGNMZHFVNFhzbko1NnJw?= =?utf-8?B?N05tK3oydTFjYitwVUlzKzlKazFqc3hsSmp3bUJqZWloZitKUkNLbVloNG04?= =?utf-8?B?M09iMDVPY05QWTVDVVF3UHB0L29WOUJJR1JlNVF3dnpjYWI3cDZucFNQRU1I?= =?utf-8?B?cDlzdHdLVmJQZFB5TmJTTW16cDRYSnh1N3Rja0prcVJpQ2Yvb3VJSDVnaSsx?= =?utf-8?B?SWk4MHZrUXRVdG5EK3A2RzR1Vi9QN2Ryd0FTSDJzL2laR3N3dWpDZDRsNVhB?= =?utf-8?B?Q1hIcUQ1YS94aVNGWWxTS1pianZkU2RtY0JUK2FYb1FKR1ZuYVpldlZoNFY1?= =?utf-8?B?TVRVOFlqb3FRZm0zOU45SitjMm1PZ2FYbWFURVB5UVBxQmcraWZuYkxST3lP?= =?utf-8?B?M1RMRjAzZjk3VHM2ang0SUg5Q0dGNWpjYUYwaG9uaXYzUFBGTGpIdTEzayta?= =?utf-8?B?aklCa0J4VmNLMXRWNWsyUDJhWVVVZVVFY0N2dnFOYndOdTRna0lTZURCd1Iz?= =?utf-8?B?N2NzaUFRTCtzRGRyY1NzdXNkREhKdG45Q0IxVGlWVS95cURLK2pXazVoWnVK?= =?utf-8?B?bkdFcDhsRmhNRUEzSkU1V1hZZ0RaUzhQUnJ5ellGbGl1UlFBR1FES0kwS0Nv?= =?utf-8?B?QnljdWtIT3YyMmRjOVNJdDJVY2ZyREhlVHBvMkUyQWNWbnh1dEFFNEhkQlpm?= =?utf-8?B?OFNPcU5CMWpLWlRHalFTLzFFY05mZ3UxaEJGdTFSNnlUUDZDT09zeWxUNStz?= =?utf-8?B?S3lCODk2MGNHZVozcnNwSk9wL3pxd3lrV29sblBYTVJHWTRtUFJuaHFZSXJR?= =?utf-8?B?T0FscklBQWJLN1U0VEUwMGgvbTlEV0c0N3VXOVZ3ZndlM1U0MFRpMjllbjJU?= =?utf-8?B?OWZkUE5QRGtRdnN3YjdUZ3p5TzY3MEg3dks4d2ZtYWR5dlc3bTJpM0VlYmkz?= =?utf-8?B?NUpvNytCTEM5SkJoNTJYTTVIakI2c2drL3FRVTBGaU5YR0pzc2kwcjBLRjRT?= =?utf-8?B?VlRMV2dCSlZGN0xuRUtrdVJjWUtyT0JkT0laMzBVUzhIc1MvZDZxbXZ4Q2xI?= =?utf-8?B?N29ManZ4eE90d2RndXgzVEdMbDVxbk9jcWlFTzh6eG91REg0bWRLYm5LckJE?= =?utf-8?B?c1Ayek5Hdm1JZnBHTWVKRzkzWW5CTkpSeGRQQm15OTBRK251OGdmUVZ4SGxK?= =?utf-8?B?UHd1Qlh3M2JPK0hLaHhaNHpqN0hOSUVpNUJLZjd4Wkh0V25CaStLZzZHK3lD?= =?utf-8?B?MHc2eHp1bEZLbGZ0bGJtZlpPdklSQ01wQzh1RksrZHR2Vnh1RTZUQ25OWFpU?= =?utf-8?B?WlBnMzlqRUNJcThrSUVhVjAvbkRKazV1N09VQSswalRlOExwSEdTWnBINGVB?= =?utf-8?Q?PZtw=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YXpwc29mUzMyL0k2VHdyUVo0TldZRFhhbnk4ZDhmVXNQZmZZeUZjVWdNbEgz?= =?utf-8?B?VDdja2lEOVMrWXBvZ2xENFRJZ1ErTnQ2TmdhbDFEQTduTlpnSzJVOGVCb0VW?= =?utf-8?B?aHVrMmJXMmhhcWlEQ25tYks4c0pFS0Y1NlBuT2krVVFNZVJpeTBBdktSclRv?= =?utf-8?B?RkF6ODdrRjJGK3hWZWZzY2NISGVmU1JuZ2hJTUlCSG5yTGtRV0lJU2NETmtq?= =?utf-8?B?aVBCQ2NiN3M1bjF3ampJUlhQb0pDbXlnWjZtdEpLSitCVkhkRFhodmlNc0VV?= =?utf-8?B?ZXBHUXpLYmtZODA2YmxXL0E1Tk5HaVdkY3lEUGx5N0pLU1hESUNlVGZkTzZT?= =?utf-8?B?M1kzRktoRVFlUmV6NlJGYkNGYkZBdEtTSXM0N095c0VYejlxdG1NQXJhcWlV?= =?utf-8?B?REprZkVRNEJkN0ZXM01qdHBKZU16OUlEemxFM2lEZFVEZTFxUDlWZVNXdlBv?= =?utf-8?B?Y1puU0duaDJDZFNaRXVwSUpVYWdHZkJkUzZiWkxaWS9zSnJvYWI3TGVwTExH?= =?utf-8?B?REZCYnIyUlN1TDBWdU9DN3lJWFJtbURhUGdxK1duTFNUMGJ4bVA3bGN3SGRo?= =?utf-8?B?dENJYVJYYVNWcWU1cGs4d3BYa3BsbXFNMFNIZVVzTTUrdHNSTU5HNnh6YVln?= =?utf-8?B?SytXSklmc01hMXFxWURvWDJmOC9KOWh4eXpjRCtmZmhFTmIzbmEvZjJZMDdx?= =?utf-8?B?c21VNUlpNFJRNzdFZkJHUXFVN0Qwb255QkZEWCt4dFd0ZWJoTVRPbDF2Q21Z?= =?utf-8?B?WGZ5Smx5bC9QQzlES3c3N0VtbEJaSEFZL0wvbVZ1K00zempSS1dodytrT05B?= =?utf-8?B?VktiOUFmeTdnUE9LTnpHVGFYQjI0NkNmNnFaR1M0bU53Wi8wNS9lY1VhRStr?= =?utf-8?B?WW1nUEtpalU0Tk4vOEdKcTZDTzExZ2ZXaHZGSkRvWEJWc0h6TTlZdHROSjhU?= =?utf-8?B?aXFySUpjUnM0aC9VNVpKNTlVVVJEUnh3RURDMlVMZ2pERVVPSXdPR2pIei9x?= =?utf-8?B?RTlFanV6L3BOL0xTMm44ZHZsOThJRWNOcWh5Z2tETlk3REgrdHBOQlFwR3Ns?= =?utf-8?B?WDFzY0hiR0kxWVNRY1BNUXRCdmNmenV6elZHclVGeGhSbkY4LzVpbnV6YitO?= =?utf-8?B?Wk1jSmlMRko4RXhsK0lOQnJLdnc0cXl2em5GUFhSRk91ZENYck50eDRuSW5h?= =?utf-8?B?d1BYZlloQU15SnFRR3VkUGwxUWFvWG8ycTRqeEJnQ2N4SGkxNWw1OTF4eWhT?= =?utf-8?B?MERsVTdXUGxweFRuT0lTb1NVQWloc0cxb0hBZWxzK2FPVkNDc1R6b21EbWJs?= =?utf-8?B?RnpuQko3YjdZSFNzZnh4ZjdoYlhBdWpkeFlWZmRlTFptV0pzbCt2eC84UjBt?= =?utf-8?B?eldocnZjUkwyMk1URmhzZE04c2pQOXMyMW9ueXA3aFZLeUZ6bUlRR2N1d0Fl?= =?utf-8?B?RjUxOTNLMnBpZUNwZXk1eVNiS201SnhMYmZkdzZEWUU0QmIzZTRNSGFDZkZC?= =?utf-8?B?MEFpM2E1WCttZjJ3cFdjQ25mMmpBa3NPc1d5eWljbXBuZjZFV1lKQUNRZzh6?= =?utf-8?B?R2g0SjNHNkt5Y2xRTHMycW9nbDFLclJOS01iMG1ZZjB4akhXVGRQT2JsK1Iv?= =?utf-8?B?TXdaMDRRUDBIVytjL3M2cWFSbXZqeVk3U3JRVzVNa1ZhN25nUzZHSkhYQko1?= =?utf-8?B?S20rZkJidG1FQXh5RUVGcnN6RWo0S3ZNbUcwTEd5SWNVRzNpYmsrVWsvNWdp?= =?utf-8?B?Skk5U1ZuSURsM3ZIYzlRTkZkVVhFVW1rV1FBUWNHb0EzNUY5dXVzcEhCU1BQ?= =?utf-8?B?anR3OXZrZ0pRc09mMlp1SVk2Z3N5bk15NmJkeXRwUDZyL3h5Nk1KTnZKRnJL?= =?utf-8?B?eWpxbWRLUzkweTBQek9zZjY0TjAwSXo4MDRDcU9sUVlOcjgzZEdBcGZkSEM4?= =?utf-8?B?RTRhUG9KYXBMSHZGRzg2UUVoV1JSQWlFOUdmdUpQVm0rTTNRM2xqWTkxUkdH?= =?utf-8?B?b2lrdlc2K1hUWFNuNzRQaEI3dU90MFk0N1hFcDZyR3oxTWVFTXowcG9NcndT?= =?utf-8?B?RzluTTV4Z2hZVjVPUWRQK25VZ3hrVnNKTUhuS21ZNmZjSzRGc1lsQ2twM2dx?= =?utf-8?B?OG54U2F2aHMrZ1VLcGIxdDJnVUNVQ3ZLNitSQ2RvUzc4aEtaWGJsUWZ1dERk?= =?utf-8?B?RVVjMzVic0dFOE1ZZFVkQlExWGVpWUNQVW41OFFjOHNkcnl1eWx5VjhRTlgr?= =?utf-8?B?T2hoeUVqQzlwRXhlbzhWV3RUUTBMSUxSMUFBSzlVYlNURC9vQndVamltRTRz?= =?utf-8?B?Y1llTVJ2WkFIbk4rcmJnYVJxVUF1eEtnSnAzd084ODZvUERiai9zdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: cf9ea854-5d57-49f1-b3d7-08de5913e467 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 17:38:30.7297 (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: avJXJG33wob9ejvm/Rxdq9bPYH/orZ2ZN1hmaRpEu/KJ9D1x7L0gqk9Jrl3KcuqqgTfyonuHLDPvo4E2rrJg3w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR03MB7549 On Tue, Dec 09, 2025 at 11:11:40AM +0100, Jan Beulich wrote: > While sizes (and possibly positions) of the symbol table related symbols > (and as a result other ones) are expected to change from linking pass 1 > to pass 2, no such change should happen anymore from pass 2 to pass 3, or > else the internally recorded symbol table wouldn't represent the ELF or > PE/COFF ones. > > For comparing to be actually useful, i.e. most notably also covering the > last of the arrays emitted, symbol sizes need establishing. Make use of > the xen/linkage.h machinery to achieve that. > > Suggested-by: Roger Pau Monné > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 21 17:43:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 17:43:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210104.1521927 (Exim 4.92) (envelope-from ) id 1vicEm-00077z-3T; Wed, 21 Jan 2026 17:43:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210104.1521927; Wed, 21 Jan 2026 17: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 1vicEm-00077s-0P; Wed, 21 Jan 2026 17:43:24 +0000 Received: by outflank-mailman (input) for mailman id 1210104; Wed, 21 Jan 2026 17:43: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 1vicEl-00077K-8s for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 17:43:23 +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 abf3666b-f6f0-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 18:43:19 +0100 (CET) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-43246af170aso56414f8f.0 for ; Wed, 21 Jan 2026 09:43:18 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43596b62700sm9702651f8f.42.2026.01.21.09.43.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Jan 2026 09:43:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: abf3666b-f6f0-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1769017398; x=1769622198; 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=v9y2S3cd3EBdIWGtGldmEHVozUbvuRK7dO8V2IFvzEI=; b=HMdl6zrpoyMmisPGBFI6jxw1bGFY/54uk65Gi92+iwdOsPq/3OnfKQmIgq5BjXRZze asKAdAOgknjx5ka3izp2Eczdv2R5aPnKCbM8mu6AtgkDbtaP0gHiYpDlz7Z+NFlawUzh 4Srp7UArknOMk02iWopB3mHCV5LJicOPAGczI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769017398; x=1769622198; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=v9y2S3cd3EBdIWGtGldmEHVozUbvuRK7dO8V2IFvzEI=; b=u0Nd5gaTYTxhz4rUfpnWcvUxuVl61sXSa7TQWyEZRhFVFw4WX2iyteeAv6+NC3Rs7J MHGMw4D70ViIp0K2yLPigXNYB6B1hJXsmpIZKjK9A2XfGLgktrjyCbZ/hEF+S2G5CEHU QJYKf0S/hvjv02gMZk+zbYmt8tArKDybrHmlgz6LUKylpWaoVxeHqtCfzTedQOP97Say e5D6sEi7jR/ov6Jkj6jMVvbw+vLPSWprMhzgOAzELFgIMYQ81DtRYxVJPUSuLOH1rEp1 DzPRfPdob5G69vCDXMiiddcCu0GFwSkMYL9gzRw8CwaS8rzalY9v1vf82L1Gl4NiD6eW xduw== X-Gm-Message-State: AOJu0YwQcyBfjzNif5mOrYY9Bexqj6pK/cO4QB2/tpMlmYTCgalIFZHh mXDKcV+ZKvR1g4XuDQzFqjVXwG/ncA08fAA9p4wXPNehOGp2v/85HXQpJKH0JepDzwfUsa3L9Um boDa/ X-Gm-Gg: AZuq6aL0WZs4TdjkeEGkFIHNhGmRawE4pdF/AZ2Kj0Z0Jx3fDHMYpPkiENNBXkup0kO WgWctuB4Nk+7ahT0p4cbHV8cO5xB9LBnPG/hYsRbtEmb4U09Yz6vvUdBjcyg/LGY0DVEvAWDsZE rrv3v4R+3nCnClkcdHFwyD8zsjzJgVWDkYiD1zENrpHNrCB5lsMh3l7aPh1m9HieBHIu+GAIvlX ifZHjilC8nlT1Mk6fnmjcUXS7+U2jmL5Rk5kAITsauDS5BW+lyG8PH2/n46c41taL0Vv6frtTR8 pXECSpeFMmC7K2EkjTAqf5qB3IN3ss+Nb+1LTquaughPoSfBPQxFeHkzxpWExxHxkD7NrUZb7sn dZUuMk1mAB8Aav9vkzk0fFUETarkQ7NeYh78vHXUkkbRLJ8Z/BPEPFKPlU/mMOq8R61vE0TeNWO bpBEbZ+RDyoAGBQQkBUwKUdRmfF6ICG0/Ir2uV9SWRGDA9FkeN4zmpOKG6T6fkH3/DZOzfYbo2 X-Received: by 2002:a05:6000:2502:b0:430:f593:aa34 with SMTP id ffacd0b85a97d-435a5fd0604mr461458f8f.17.1769017397088; Wed, 21 Jan 2026 09:43:17 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Alejandro Vallejo Subject: [PATCH] x86/svm: Adjust VMCB comments Date: Wed, 21 Jan 2026 17:43:14 +0000 Message-Id: <20260121174314.1465759-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 Intercept comments provide no value whatsoever. For the VMCB, label the Control area and State Save area, which are the names given by the APM. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Alejandro Vallejo --- xen/arch/x86/hvm/svm/vmcb.c | 4 ++++ xen/arch/x86/hvm/svm/vmcb.h | 8 ++------ 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index cbee10d0463d..72173c8fdd6a 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -430,9 +430,13 @@ static void __init __maybe_unused build_assertions(void) /* Build-time check of the VMCB layout. */ BUILD_BUG_ON(sizeof(vmcb) != PAGE_SIZE); + + /* Control area */ BUILD_BUG_ON(offsetof(typeof(vmcb), _pause_filter_thresh) != 0x03c); BUILD_BUG_ON(offsetof(typeof(vmcb), _vintr) != 0x060); BUILD_BUG_ON(offsetof(typeof(vmcb), event_inj) != 0x0a8); + + /* State Save area */ BUILD_BUG_ON(offsetof(typeof(vmcb), es) != 0x400); BUILD_BUG_ON(offsetof(typeof(vmcb), _cpl) != 0x4cb); BUILD_BUG_ON(offsetof(typeof(vmcb), _cr4) != 0x548); diff --git a/xen/arch/x86/hvm/svm/vmcb.h b/xen/arch/x86/hvm/svm/vmcb.h index ba554a964487..c64386e7ef85 100644 --- a/xen/arch/x86/hvm/svm/vmcb.h +++ b/xen/arch/x86/hvm/svm/vmcb.h @@ -8,7 +8,6 @@ struct vcpu; -/* general 1 intercepts */ enum GenericIntercept1bits { GENERAL1_INTERCEPT_INTR = 1 << 0, @@ -45,7 +44,6 @@ enum GenericIntercept1bits GENERAL1_INTERCEPT_SHUTDOWN_EVT = 1u << 31 }; -/* general 2 intercepts */ enum GenericIntercept2bits { GENERAL2_INTERCEPT_VMRUN = 1 << 0, @@ -65,8 +63,6 @@ enum GenericIntercept2bits GENERAL2_INTERCEPT_RDPRU = 1 << 14, }; - -/* control register intercepts */ enum CRInterceptBits { CR_INTERCEPT_CR0_READ = 1 << 0, @@ -103,8 +99,6 @@ enum CRInterceptBits CR_INTERCEPT_CR15_WRITE = 1u << 31, }; - -/* debug register intercepts */ enum DRInterceptBits { DR_INTERCEPT_DR0_READ = 1 << 0, @@ -400,6 +394,7 @@ typedef union #define MSRPM_SIZE (8 * 1024) struct vmcb_struct { + /* Control area */ u32 _cr_intercepts; /* offset 0x00 - cleanbit 0 */ u32 _dr_intercepts; /* offset 0x04 - cleanbit 0 */ u32 _exception_intercepts; /* offset 0x08 - cleanbit 0 */ @@ -491,6 +486,7 @@ struct vmcb_struct { u8 guest_ins[15]; /* offset 0xD1 */ u64 res10a[100]; /* offset 0xE0 pad to save area */ + /* State Save area */ union { struct segment_register sreg[6]; struct { -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Wed Jan 21 17:49:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 17:49:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210120.1521938 (Exim 4.92) (envelope-from ) id 1vicKO-0007wT-QN; Wed, 21 Jan 2026 17:49:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210120.1521938; Wed, 21 Jan 2026 17: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 1vicKO-0007wM-Nd; Wed, 21 Jan 2026 17:49:12 +0000 Received: by outflank-mailman (input) for mailman id 1210120; Wed, 21 Jan 2026 17:49: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 1vicKN-0007wG-HR for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 17:49:11 +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 7c9ebde2-f6f1-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 18:49:08 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DS1PR03MB7822.namprd03.prod.outlook.com (2603:10b6:8:21e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.10; Wed, 21 Jan 2026 17:49:05 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Wed, 21 Jan 2026 17:49: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: 7c9ebde2-f6f1-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UMwr0ikJ1+9FroUhnSQtbpaFURJ5Ik39nzlZlq0D83xxKuVDCmM67DjAJwNwOAEpSV5fy8ghw1oCw9TMckWwPZag4HBIl9CXDes6UMdV+wwwNPoOdV9jV/EOJN0a+XxV4ywd/B4kOnmIVxSYz7/QlORlLwUpdWU1M5Ye/wae+un1LVu4ebGBTFMQcw+4uhmAJqI/6f2WNrTxMrYs1ITJNT/AVEITeRXh7BAyh75OgwutUQpmE0pHTdY08H8obDMNJhe4EmCd9FFZVE//ZBTMoeykuEisBh0i9s5UNb4ova5E3esaBd/X+V+s8oUc/FHlk7QwRjBt42Z3g1M1CZKpRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=t0cczWyKNa7cIIXwA2GYSVC70Yghs+2kyaWTjSUaepo=; b=sFWHMwgGJdthGKtpOpCd+KuE23+80dIgz8BuAI6SZWZscGlZbABkP8CYATebr7ngececkG6Gf9PEDEAYnyIOIDNpucUvTQWP2tUA6w6Vwk+EY991Y/MQrFgaTEowax/3hPxUWwvDhPeWvKfnndHyUcCsHi1L3w94m9AHyhrVGPzzaLZjtMxbowvsTd+98YeQQQ8lWsy/thMeXtIRuDU0nPVMp1iT7wDYsEDdpxaaADPR7coNKd9+au08YmLBZD95+PRaV6KpFXYD16GJZzHioV8racVFdpTXu6Y/ZyA8FGStdwhgYwgzEfIdVKCl2etpPPW5PMdzZgt9RwQHTARrdA== 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=t0cczWyKNa7cIIXwA2GYSVC70Yghs+2kyaWTjSUaepo=; b=N8iuBTIqPrrhuYlhbUcLlkayQcfIhTNh7BNvpY6uBG5GqjO8Ai/P0ALKT+s2zVkU/MdE27b5Pdev6rhXbInpTtGXsvTh9xfA1G1kcKcbLiCx71razK/ugGZ2xeiCubmcj2TN3YuHMvQKobAVRhTL6PLpx4rVNsPBeM+2JNkM30k= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 21 Jan 2026 18:49:01 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jason Andryuk Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, James Dingwall , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Subject: Re: [PATCH] Partial revert "x86/xen: fix balloon target initialization for PVH dom0" Message-ID: References: <20260120140648.25977-1-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: MA3P292CA0067.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:49::8) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DS1PR03MB7822:EE_ X-MS-Office365-Filtering-Correlation-Id: 4ece9cfd-22d2-4b0b-3586-08de59155e75 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?QTNQd1djajA0bmg2TEFtbTZEV0w0NzF6VHF2R2ljOFNWa1ltZWJQUmFHTnFF?= =?utf-8?B?WWZIOHBPQ3VGd0hpd3FUc0VwRmEybG1yZVN5aEhVeHdPK0J3OEUvMDJNemxN?= =?utf-8?B?MHRHT2Z3MUZIVHZEYnVldU1pUHBnaWNhbGNkNjRZVlArM0dLTEl5d0dGb2xN?= =?utf-8?B?Ky82U1VCSi84ckkwQUxNME11YTFEZ3grVUNaT09nZXpTZllsdjJvdXJhUFlV?= =?utf-8?B?ZXBqalltbDlCNGJrSWYvT09ONlVEdzcyRlRUZmx4Tys4SEdzQVF4aUVrKzFM?= =?utf-8?B?SUNQZkFYbnI1cmZjRVltR0RHVXRqWEJ0RXVJM3hKaDFLeHgrRlZUOGo5QnY3?= =?utf-8?B?SlM4NDcwcmJ2VEtlNzlhZDlHb2Uxa1NhaG40bVBmdG1sUXArZXN0R3RzQzRm?= =?utf-8?B?dU5RQzJtelllZFVCYlhVRDMrWlRlc28veEdTeGh1M0FUci9nV0dZOFNhMXh3?= =?utf-8?B?d3hxYWtFZFZVQzdMdG9PRXNEUThER3ZNa1kvdGNjUDVsSDhjUHVEY0pSZDZO?= =?utf-8?B?bExyN003ZlY5ZmdTYlc3ODBQQ0lhU21UNXZEVld2bHFGeTY3cUxCR2NFSzFP?= =?utf-8?B?RHFvWTU5bjNrUVYxazdqUHZxRkZPK0JNekIvRzg1QzdkY2hOcUZsYkdlcHBJ?= =?utf-8?B?LzFjOFp2bjY3Z2E5KzVwZU1CSkJUaHhVckUvL2RIdWJQUkdMTjNoc2VqS3hw?= =?utf-8?B?elJTVnBiZkQ3TmZPMlAzK0NJK1F6cWFPK2Z1QUhCTDRlcVZoeEM4Y0RvL1By?= =?utf-8?B?ako2QTkxNXlkbk1xYXcxTmJydjh6Nk5KaEJiWVU5QkRBbC9PbitRaE9nYzly?= =?utf-8?B?WlZkbHZzWVJRUUxQYTlkaDBrVEh5U3JiZVlwLzAwYzhXcTJSRlNsendFZmZu?= =?utf-8?B?c2tzc0xtSnNYUFBVcytmbDkyMnAyR3RpaVp0WW9TbmlaaGQzeFI3VG9Ud3BZ?= =?utf-8?B?a0dmdnlNSzJhZENQdURsNHU5ZlhqN2NWd25wZEo1eFB3RUtDMWxDZHArVWhN?= =?utf-8?B?RWt5NE5FcUIrcGxCZUVJNzVlY3RHWnNZZ1BNMmFBN29kaWpvT3JtWVZ1Mzda?= =?utf-8?B?dFhaQjR3aXBhVEpjQ21xcjRKVWhRK3R4OEVtdG1nVkd4SXJwQWwweWRKSk83?= =?utf-8?B?MzFsajdEeFVvTVZ4aldUeGp4TFlpU2l4MkpsOHU0anN5Rm4yaTlMalFPR05C?= =?utf-8?B?aU1DVmtwZk14ZzdaRDJrMEZpb1YreVh6KzRtdytTOW1RK0FQc1VRVENYZkRl?= =?utf-8?B?UnBIbzUyTk1waG1rYzBOR1Z6cWt4TXM2MTduWFhXNEdmbjFNeTdhaUFFZ0lY?= =?utf-8?B?QUVzNmoyQm9xdFM2ZmdINVhzSExmZm9ST1pRRDZzdzBFdEtyV21Mc3ZmUWRu?= =?utf-8?B?bUJQN1ViTXRoT3VwZ3RlWjU0dWU4emdkU2VObFcxNnRqdTdCSXo0NUN2SERW?= =?utf-8?B?bUtXK0t3bUtsQzZvSVhYSVdhYTFsV2E5aUhFc21ORGZ6bzZJNEY1ejJFT1hl?= =?utf-8?B?Sk9SWkVvVFBub3pONHY1eDdyait2dTRiSmExSUdOa2ZxcmRLWTBZeVBrTHF1?= =?utf-8?B?VmkxZmFZc0FRQmhBMmFjcEdZSFdqb0VqVk4yU0cxZkFwUEV1b1lIK1YxLzBI?= =?utf-8?B?c3paQ2U4eGdtZm1QRlQ3UVBEU3Btd2pmSmlKU1FVNE0vUnBvVUdNWWVFNXhL?= =?utf-8?B?c1lmQWswa1JENmptalErdWZVNWhOK2k5ZldrMXAwait0VENicnFEam9uZHZO?= =?utf-8?B?UGd2b2FHMFBsbmMyb1NXNmdDZTNqdVlPMXFncDZYMWt2ak5POG5aSnlwZ2l5?= =?utf-8?B?V1RhRjJ3WW9SMENlbVF5TUhxK1ZIMjBYallxZk15ODIzNDFramRCZnFEVk9H?= =?utf-8?B?dUFPd3dWTklTbzg1WU9zdXp1YWVzUlN2QkZmSEphN0pJeEZVQzRYZUd5d1JD?= =?utf-8?B?OE5GbjNHNUZQUDFOaUxrSGcxaGlpQy9sbU9BM0l2OTRIT05wTjZEYjJWNUV0?= =?utf-8?B?QUYvZTExL2RwbExtQ2NhRldMUkU5YmVsMS83aFlDNWkvWkJGZk5QM2FKMTFS?= =?utf-8?B?T2Z1NEhQQlI5eVE3bXVyanJGL0I3Z0lQMUxsSkhnYUk1Z0RvdWZTMGY3VE1L?= =?utf-8?Q?Q8xw=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dGJNVGYvWWJNUElqZ09zbU8wVGhHbnhKQ3luSnlHQzJlK2NBWGh0Nmk3bk13?= =?utf-8?B?STdPR1NJT2FJNkdZM0Z6b2F5MnErMldCSHNjb0J2Y2VKUVBUK0hOVm9VbkZr?= =?utf-8?B?bkxnbURWdzNSaThGeWk3RWtHKzkwdjgvcSt5Vkc2QTNwK0ZYbCtsSHR2bk9C?= =?utf-8?B?b0R3bElEYjNoMFJvNTVPV1ZITzdwWjdkbUFUOGNWQmRZZi9WQ1NLdXdHd29F?= =?utf-8?B?bHh1azlMT0pMbndUUzNUd01kcnROVWplNDAzSURlZm1tcEtBTDh6ckowdWNv?= =?utf-8?B?blh3L2JwSk5WY1BPK2VmbkUzTWVtUGVCRkFUY0tJM045OS9xRzRHU1RVbWxl?= =?utf-8?B?QW9HanNFVmZ6cGV2eVJJT3psSTZtR0orZUxhS1BFMjJhSE5KOU4wWUhmenBU?= =?utf-8?B?K3NEVnJWYVRtRW9xTVA1a3hIdWxtTVpWRTlVeXczc2hLZ2ZkZlk5RHVQSFBK?= =?utf-8?B?d0hSa3FtZWlUeGwyckRWc2dMRFRDVWh1RlYxY1JabTQyT2tRTVppNFlaRlJ0?= =?utf-8?B?Y1MxQWV0Rnl6NDR0R0UvcUdEYzIwNXBIU2tJZlgxYzJYTHc4dElwKzBuZGxt?= =?utf-8?B?L3NVcEVkTk1QWTJGQlB5QlJDODZ6OTRSU05XUTYyL2lTaUo1MFdaOTREd1ox?= =?utf-8?B?NFExS1JLUFk0Tk9URGlHdC9YbU4rWER1a29VQm53eWNiOS9Gb1pNNkN4d0Vp?= =?utf-8?B?OVhiQkxqRmFPNFhWWnhPMWhnd0RROFh6Mm16R2VNcVJYcE5FQm5IUGxhSnd5?= =?utf-8?B?ZEdhN0ViUkFyaXplMXU0aTdlcmhjN0tNaXpDZGd0eUxLNFpuL1dQcURQMlN6?= =?utf-8?B?OHg2MUJ0QmtrTjRSMm1BTGRCNmFvSjhQSFhGOFh3QU1GNWo1R29RcG8zOS9K?= =?utf-8?B?MmpPM0dXTUk0ODA0UDE2NDNBU0NSKzlISVVDZFBYSzlkemJWM0RQc2p5T3FW?= =?utf-8?B?NG4vZTZTa2cwMHJmQ2hPQkVQaStSbjg1SVZxTmxRV2R6RHdENWpkcUNQcW5x?= =?utf-8?B?ZTdFWS9zaU9pMGtyOFZNNUNUZTBjYkJhbDhpMitNNlIyZjdiNFlMUEcvSjln?= =?utf-8?B?TitIV2FldE5NUEdXRG5ZMkxsOWxHbUNnYm45ZDdTR0EyVzZmVUIyRnlZTGVN?= =?utf-8?B?N0FMZ3VFdUUzMnV6MGF0ZlNwL2EvNnBiay9DUzVmckMrNUN0U3Z3K0NpREJ5?= =?utf-8?B?UjhyR3VhUThSK1FOWEFRY0p2aC90ZDV2WHFXak9nektDbVh1UHl4K0xKSU1G?= =?utf-8?B?djlSTjRJSFptZGtPYmUwQUNJTXdXaTErcWg2MlRJTUlidVNCamZ5MlRaUVc1?= =?utf-8?B?Z1V5aGFtZGlSSGh3VWVjUndtTmN6ZWdzL3NhUUttMVhwRnowUVB0eUlwUU5U?= =?utf-8?B?YlczckVlYThDL2crWHVPZTh6WXoyMENTQmZ1bkViNXBWM3J6c0ZlM21qamFt?= =?utf-8?B?b0o4djFJNUUzazNUcmFSVnRCeUhzYzhaR0J5UDkvSEs0Zmk2YTBRQVVaM1Vt?= =?utf-8?B?cjNCeCtxMG13N0tvbGNTelVCTWNBeExWaGZEM2c4SU9JandaYlNzWG5QbTl0?= =?utf-8?B?MWx3ald2ZVE3SlNSNTUvcWlxMVd4ejZOU0xWSEZGTGtoWVRWZkNhVEZYeFdk?= =?utf-8?B?WnBSQWlXSTlyUDRvVWQzWXcvZXV5d2lpK1hheEY2ZGk0Nk9QYmhTb0c5OHlW?= =?utf-8?B?RzBxdmdydWdPdWtjaXd1TENsM3dyVDNrbG9zblo5ZjVvaE01dDlwQkZHT2pP?= =?utf-8?B?VEoyazFaZ2VRcHNiN2Jhc29IUXo1LysxRDBTcVVMajc3Q0Z2b01uODJjUmto?= =?utf-8?B?VnB5R1hjS0dRUThsWThmUnBvbzZVTE0xNU9IZkJtNGtwWTFia21lNlJVUUxF?= =?utf-8?B?bHlXKzBtSkpISFhiMlc2RU9RQjdnQ3FIZHJHcmNPczRLSDBuazhycy9saUw4?= =?utf-8?B?b0Y2VkhSVVpzMmxHc0tMV1BHclMyZ2poMjlDQjdyNzZKVnBFTUZhV25Xc1ZK?= =?utf-8?B?dDM2VU9XTnlldXVmSW4vNVdCU0xVQkt1VjRtVFBNcmZkYlVWdXQxWVk3Wnc4?= =?utf-8?B?QXgyczNmN1NubGxkSG9QN0pLa1Z4Tnd1ekQ1L3JQRGlYcjZwenNqYjM3eTMx?= =?utf-8?B?Y0I5ajY5ZE12d3ZiVmtpTGxxRklpV2VuYzh4bHRiTVM4ZjFrbVI3N01QaGlK?= =?utf-8?B?ejFiTElsNnhyVmRreWUyLytNMXRvVHpQdnR4VTMrMVFzVzNmYUZleDFreW80?= =?utf-8?B?WDFGckhaN01YWURiV0dXY0kzWkRSbG91QnVXOGRHVDRHVEIvMWJkQUl5V0Ry?= =?utf-8?B?b2ttR2huOXZsOWFZSEtpUlo2enRiYTlmT1B6ZXE5UVdRclkwWTcrZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4ece9cfd-22d2-4b0b-3586-08de59155e75 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 17:49:04.9387 (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: vNNghCLLA4Wt3weJJXD7nTh8e0Xpiy1kwsb7ABsoKkeLMCs21rnEYlbRcPEpR/rOIbhFiGRyYoEORhlSVCGl+w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS1PR03MB7822 On Wed, Jan 21, 2026 at 12:21:33PM -0500, Jason Andryuk wrote: > On 2026-01-21 06:17, Roger Pau Monné wrote: > > On Tue, Jan 20, 2026 at 03:10:06PM -0500, Jason Andryuk wrote: > > > On 2026-01-20 09:06, Roger Pau Monne wrote: > > > > This partially reverts commit 87af633689ce16ddb166c80f32b120e50b1295de so > > > > the current memory target for PV guests is still fetched from > > > > start_info->nr_pages, which matches exactly what the toolstack sets the > > > > initial memory target to. > > > > > > > > Using get_num_physpages() is possible on PV also, but needs adjusting to > > > > take into account the ISA hole and the PFN at 0 not considered usable > > > > memory depite being populated, and hence would need extra adjustments. > > > > Instead of carrying those extra adjustments switch back to the previous > > > > code. That leaves Linux with a difference in how current memory target is > > > > obtained for HVM vs PV, but that's better than adding extra logic just for > > > > PV. > > > > > > > > Also, for HVM the target is not (and has never been) accurately calculated, > > > > as in that case part of what starts as guest memory is reused by hvmloader > > > > and possibly other firmware to store ACPI tables and similar firmware > > > > information, thus the memory is no longer being reported as RAM in the > > > > memory map. > > > > > > > > Reported-by: James Dingwall > > > > Signed-off-by: Roger Pau Monné > > > > > > Reviewed-by: Jason Andryuk > > > > Thanks. > > > > I've been considering what we discussed and as a separate follow up we > > might want to attempt to switch to using `XENMEM_current_reservation` > > for dom0? It might make the accounting in PVH dom0 better, as that's > > what the toolstack uses to set the xenstore target when initializing > > dom0 values. > > Yes, I thought that could be a follow on. I've attached what I have tested, > but it is based on a branch pre-dating xen_released_pages. > xenmem_current_reservation with PVH dom0 seemed good without the > xen_released_pages adjustment, but I don't know what that would be for a PVH > dom0. > > Regards, > Jason > From 8b628ad0ebe52c30e31298e868f2f5187f2f52da Mon Sep 17 00:00:00 2001 > From: Jason Andryuk > Date: Fri, 7 Nov 2025 16:44:53 -0500 > Subject: [PATCH] xen/balloon: Initialize dom0 with XENMEM_current_reservation > > The balloon driver bases its action off the memory/target and > memory/static-max xenstore keys. These are set by the toolstack and > match the domain's hypervisor allocated pages - domain_tot_pages(). > > However, PVH and HVM domains query get_num_physpages() for the initial > balloon driver current and target pages. get_num_physpages() is different > from dom_totain_pages(), and has been observed way off in a PVH dom0. > Here a PVH dom0 is assigned 917503 pages (3.5GB), but > get_num_physpages() is 7312455: > xen:balloon: pages curr 7312455 target 7312455 > xen:balloon: current_reservation 917503 > > While Xen truncated the PVH dom0 memory map's RAM, Linux undoes that > operation and restores RAM regions in pvh_reserve_extra_memory(). > > Use XENMEM_current_reveration to initialize the balloon driver current > and target pages. This is the hypervisor value, and matches what the > toolstack writes. This avoids any ballooning from the inital > allocation. While domUs are affected, the implications of the change > are unclear - only make the change for dom0. > > Signed-off-by: Jason Andryuk > --- > drivers/xen/balloon.c | 9 ++++++--- > drivers/xen/mem-reservation.c | 8 ++++++++ > include/xen/interface/memory.h | 5 +++++ > include/xen/mem-reservation.h | 2 ++ > 4 files changed, 21 insertions(+), 3 deletions(-) > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > index 528395133b4f..fa6cbe6ce2ca 100644 > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -713,10 +713,13 @@ static int __init balloon_init(void) > > #ifdef CONFIG_XEN_PV > balloon_stats.current_pages = xen_pv_domain() > - ? min(xen_start_info->nr_pages - xen_released_pages, max_pfn) > - : get_num_physpages(); > + ? min(xen_start_info->nr_pages - xen_released_pages, max_pfn) : > + xen_initial_domain() ? xenmem_current_reservation() : > + get_num_physpages(); > #else > - balloon_stats.current_pages = get_num_physpages(); > + balloon_stats.current_pages = > + xen_initial_domain() ? xenmem_current_reservation() : > + get_num_physpages(); > #endif > balloon_stats.target_pages = balloon_stats.current_pages; > balloon_stats.balloon_low = 0; > diff --git a/drivers/xen/mem-reservation.c b/drivers/xen/mem-reservation.c > index 24648836e0d4..40c5c40d34fe 100644 > --- a/drivers/xen/mem-reservation.c > +++ b/drivers/xen/mem-reservation.c > @@ -113,3 +113,11 @@ int xenmem_reservation_decrease(int count, xen_pfn_t *frames) > return HYPERVISOR_memory_op(XENMEM_decrease_reservation, &reservation); > } > EXPORT_SYMBOL_GPL(xenmem_reservation_decrease); > + > +long xenmem_current_reservation(void) > +{ > + struct xen_memory_domain domain = { .domid = DOMID_SELF }; > + > + return HYPERVISOR_memory_op(XENMEM_current_reservation, &domain); > +} > +EXPORT_SYMBOL_GPL(xenmem_current_reservation); > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h > index 1a371a825c55..72619a75fed2 100644 > --- a/include/xen/interface/memory.h > +++ b/include/xen/interface/memory.h > @@ -104,6 +104,11 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_exchange); > */ > #define XENMEM_maximum_ram_page 2 > > +struct xen_memory_domain { > + /* [IN] Domain information is being queried for. */ > + domid_t domid; > +}; Other callers that would use xen_memory_domain just pass a pointer to a domid_t, I think you could simplify the patch to the diff below, which sits on top of the patch here: I haven't tested it yet to see whether that's OK to do on PV, I would think PV and PVH would be the same here, since the setting of the xenstore target value is based in the return of XENMEM_current_reservation for both. Thanks, Roger. --- diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index e799650f6c8c..c592d7bae8c3 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -724,7 +724,8 @@ static int __init balloon_add_regions(void) static int __init balloon_init(void) { struct task_struct *task; - unsigned long current_pages; + unsigned long current_pages = 0; + domid_t domid = DOMID_SELF; int rc; if (!xen_domain()) @@ -732,8 +733,13 @@ static int __init balloon_init(void) pr_info("Initialising balloon driver\n"); - current_pages = xen_pv_domain() ? min(xen_start_info->nr_pages, max_pfn) - : get_num_physpages(); + if (xen_initial_domain()) + current_pages = HYPERVISOR_memory_op(XENMEM_current_reservation, + &domid); + if (current_pages <= 0) + current_pages = + xen_pv_domain() ? min(xen_start_info->nr_pages, max_pfn) + : get_num_physpages(); if (xen_released_pages >= current_pages) { WARN(1, "Released pages underflow current target"); From xen-devel-bounces@lists.xenproject.org Wed Jan 21 17:56:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 17:56:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210130.1521948 (Exim 4.92) (envelope-from ) id 1vicR0-000132-FR; Wed, 21 Jan 2026 17:56:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210130.1521948; Wed, 21 Jan 2026 17:56:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vicR0-00012v-CN; Wed, 21 Jan 2026 17:56:02 +0000 Received: by outflank-mailman (input) for mailman id 1210130; Wed, 21 Jan 2026 17:56: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 1vicQz-00012p-AP for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 17:56:01 +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 710ff9ad-f6f2-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 18:56:00 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SJ2PR03MB7500.namprd03.prod.outlook.com (2603:10b6:a03:559::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 17:55:53 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9520.005; Wed, 21 Jan 2026 17:55: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: 710ff9ad-f6f2-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kP2N5f+yNmNDsKLwddFWZHeah5yY7zrnJN7brJdupBuBPgQ6e0uGmZyufD3pkIny4e1O4NP5WNFqmaefiwUZO50NBK181L/mNl9omPptkit0o4n1zOU1o1OGdCuP0gUhfCgCtJCY4eU2iAMPqNYHdXTIiPpblVSAPGtP1DfAn7fpPmmYn+m8ztqJbjakOxgPXPsqJSWFVwGMYA3+STeC67Oel3w1Jbk4R5tkudv8kcX6M0mAl3NZM245cOe6vb6g8IXTRdgXjnV0qOK8b5qvLPN+j0KAYghgsxoc192nH4iEwZTVNMqF6DFmPsYZCMrYp2pZH+WhHKu7Kebo1n8lBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qXLG5js2bmCVC7w+J77wWpSarpQwuBXm6HqW1ce1Dkg=; b=jquJf3CIl9eL4Ndtwict7W6qUIVrrOT8dVzEVITSo4w+Is/X6ehiiAUCXlR5UjWwH2ned2u5kAdmyueM/byJgVso99S9KTegSULtlwAcmUDB3wpEc64o/kR4ZNizLzpGSWNrdwLWgKORclp1anEQrQDswqsBwOj3PhaJeDwfI1F9odwen+Suz//hCA9EN54usIWfA+vGxRnjlmo0/9iVUom1IeqVd5NXtstwI51C1FVVJHakL5rAPxFJLU6kCN5WRHOo2jmobM7UAlwVKmYDDZ8R/9yR+KGgH8ho8VHXbLEFVMwkP/681zY4qbeBalbo3bcNSiR34wBrjwLq0gcn1w== 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=qXLG5js2bmCVC7w+J77wWpSarpQwuBXm6HqW1ce1Dkg=; b=NZk95bryHK+WL8oAs/Uzzr+XvNgAYoNfBW80yynljRb34cfn7WhMPcTk/77oqo2uw1IYbQSrbCdtlgLz+rmMsdh3rTRyeFPT3XnzMfUtShVFngS3WgKbrEAXcshjR/8tWFTV8PkHXPysqLZCrmu8NZvJTob+ysdy4w7zb3w0aOY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 21 Jan 2026 18:55:49 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH v4 2/8] x86/HPET: make another channel flags update atomic Message-ID: References: <57f34114-54b7-483d-8ac0-e9fa49df959f@suse.com> <757cba5d-2c9f-40ae-8eae-6309979bbba5@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <757cba5d-2c9f-40ae-8eae-6309979bbba5@suse.com> X-ClientProxiedBy: MR1P264CA0202.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:57::19) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SJ2PR03MB7500:EE_ X-MS-Office365-Filtering-Correlation-Id: 014a11d4-8280-4f90-847a-08de591651b4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?b0lZYWhRS2VUSDB6OU1rWEZYcjdmMFZlbVdOYzZSeW4yVWxncDBRU0xXUVZy?= =?utf-8?B?cFFXK2g1eGJRT3ExSU9iUGt1cEdGdTNvVkFkOEFqOUxxNzZRNmxrV3BaVENl?= =?utf-8?B?RjNOZG5DVE5EdGk0eGoxYmpMQ0tYblQ3NWp3WEtQTjBDTTZ1WDJGaHVYRUxE?= =?utf-8?B?eE9XVW5BUXBhOUk2UTRpQTB3SGZuekNDRndOOUM3bmRRV01DQ2psaFl5S3ht?= =?utf-8?B?NjBwWjFYalFxWUNmM2YzZzZiQ21sWkJnYUsrWXFTOVNCMy8wbzdFcUlyL1l6?= =?utf-8?B?M1hoWXhINWtaTXZ2cGlPUzRnWmhxQ2dhZXQxOXllSjFsUTdEZUppbDRUTCtH?= =?utf-8?B?c2pHWUZYQWE5RGRHb1V3TlVIcFdKV1QxZDNqemo3a1hYMTF2MS9vd25yWmda?= =?utf-8?B?c3I1WDZYTGRuM0VoOHJaRC9HNjlRYkR5VXJWeUlJZnpZRWhDTWwxTmoraXhi?= =?utf-8?B?Yk5mU1VVMHhGeElXL2VLL0xYWVRkUVB3NVltQzU4R3lBN3o5VzZSeWtycU1v?= =?utf-8?B?UGIrMVVVbElZNmpHUXkrUHdwUVdmaXQxSHZCa01FSXV3UG1MZEtUUGRGSnR3?= =?utf-8?B?MG11ZHZhUTVyVTJkam1ocmRRTUhyYTU0VzJXckRQRTRWTzl2bFN0VTZCcy9G?= =?utf-8?B?U1BVMElCY24wRHovUjVFK0o0TVlqOWpIWDF0TWF6NDlic1pFRmNCejhDZzdm?= =?utf-8?B?bzZ6R1kvaGtYY0ozcnp5TnB5bllSbXlYNS8yNTEvRTA3ai9yVHRUaFhROFRR?= =?utf-8?B?RkUzMXVYQUFNTG54YTF6bU5teThBZnJTL0VJQ3JHb2RFSVRoN0dvMUFhSW9o?= =?utf-8?B?cmg2Slk5Q3J1eXZZQnd5aEFRcUJ4SmpZMm0zNk8relZsNWtqMFc5Z0JZeFpi?= =?utf-8?B?ZXlkcER4OGo0MmhucnVZek9lVDdGRTRYREJ3SHA5OFBVc1ZmMVVUZ3JuSCtK?= =?utf-8?B?ODRUUENlanhWRW1PQXRGN0tBZjFVRTNGVDE2QWdrMzlKbWpqN3Ryb1BrVENO?= =?utf-8?B?WVB3T1F0bWtXZXRJeGZaRzBlZzVQWndocUhqRGVCUXFiTkROZ3U5WEdWSW05?= =?utf-8?B?QktlWlVQY3FUWXhQUnlzSXJybWpsTjFSczJDRXhiWis1NjJ3UTlZMU1leGRh?= =?utf-8?B?MGtUZnZDVFFpemo5YXdjR2szVE41SnZaUGhRVEgyZXFKdXRFSU5vaGhkV1NN?= =?utf-8?B?aENvVWFuNkFrY3ovd1JFWjVRL2ZsU2NqY0JPdXdPSHZycFZRWDRxU1NEOHph?= =?utf-8?B?TWpOY3c3NjdqeHEzcU1WSXJ1WHpHc2JucEoxUnpuR1NmWWpyUVYvaEp6TWtv?= =?utf-8?B?cEtzaVJ3Q2Nmclladm5WRVlNeTFoTnpJVmd6K0xDYUx1MnF1dmdKSlo1Wis4?= =?utf-8?B?b2JHR0ExL2phVTNOU1hDYTFvd2VMaU9LM0ViWTVGV1VxSld6dzFLM1Z0eWpZ?= =?utf-8?B?RFFYeDlVd2lXSko0UUxLYmFDblMraDViZTNlejF4dEdpMU1TNm9wMnFNNE5k?= =?utf-8?B?bVRGWW91b09wcExaS1dTdk8vc2ZBdjhHeS96VHRJY2lKZXd6VmlneTd2Nk1x?= =?utf-8?B?N1NhbTlWbzROazhXK1JsZnU2REEzTk8vMFJUMEFreEExRDlhd3lJQzdSMG0w?= =?utf-8?B?ZE1EOVd0VDdiVGZvYkFlanFHakpEOXdFVXJaRTVXYWJtdkZQYUFoeVMxQ2Ns?= =?utf-8?B?cXVWSldJV3JIa1c3WTFrZUo4WlBpYnFSNVEvd3VHckthb21OdjFjOEIvcVNU?= =?utf-8?B?K2Q4Ulo1aW1vcmZha1Nmb3ZRYTI2RUVYM3FQU0V0U2dtVW5LUzZxM3VWdHEz?= =?utf-8?B?bHErd2FGNzVOSFQ3RW9NMmxSaURXTXZGVG1nOFhRTUFienhoNFdFc05TRS9Y?= =?utf-8?B?emVya0NaTUdEbzVZdnVRSHpKT0lHb2hveGIyMlZYSFFTT1REYkNNR0lSRitI?= =?utf-8?B?T1JQUkgzTXhKL1JiajJBMGFkTDh2WCsyVmVjQUliN0UxSFFqUDd4dmQwOWNQ?= =?utf-8?B?N3BicHB0bHVTQkNoWisxNzExMTlwdTNRelVtQnZ0S3JoK1FqOGdqaEhncXlo?= =?utf-8?B?YzRnTTd6OVN3WlFQWS9aUTZwWFFaR1lUZDVTMXhLS3FlYjNaSXhVbm8wZzQ5?= =?utf-8?Q?QI/c=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TGZGK0s0OWVnZ0xxaWtFWEZCcmcrWEJDcGpaaTlxSjB0cGtPdzVvTFovTXMz?= =?utf-8?B?eXhtYTBjTXVnK0t4ZXlHV3o1Y3RpRlBJRjVrMWdva2Q4U3dNd0dIZ0JxR25D?= =?utf-8?B?K21KdU9LY0RzUEhpeVVXR3dlVWRsalhYTzRqbWZUd1ZLY3M0VjNmenRaZWpD?= =?utf-8?B?ZW5URktxUkVaYW1ibmhNM3A3dmFjQ0FaZmVPOUU0ckt3WEtTblUzRHIwZnlW?= =?utf-8?B?UlgyT1NVaFJWbTRDUURYdklTUU4yUE1HK0hmNkcyQWo0M2xBUWxQOTB0Rzlz?= =?utf-8?B?M3B2WXkvM3l0ZUU0by85SVdmcjgzOVcrdm84YytGKzRmZkpjSGxPbFRlcnZh?= =?utf-8?B?SjJVUWJuNTdPRTh4QU1pZVQ4ODNMS084bGFUR3dTMEUwdkJ6RUlmd2xFanU5?= =?utf-8?B?c2F2SkZFNGNDbWYzTGFVK1Y5bXZYTER5YUVBdk5iK09sKzdmWGpwWi9uTkQ0?= =?utf-8?B?MDVaZWVRalZETmdNWDd4Qng1WDFWVTdQNkZpOG9ZYVd5clp4MTJYQWRKb3FY?= =?utf-8?B?azFTc3F4b3k0ZEZVMCtnZnk5eXlzN0d5WDRqTnhZRndhZjN3K0JaSFlxV1N1?= =?utf-8?B?SStOSEsxVnovTGZOd0RUeEIvUWQyRU9vc3l0N1VhVHNqb3JFNFlxM2grTlVT?= =?utf-8?B?Z0lzQ3UzUVpKQmxwM0I1NERuSnhodDdRdTdaTDJXMDFxV0hsbmNTdmN2eUZX?= =?utf-8?B?cmJDY2RTNDdhVnQvRFhPVFNqOE1nR3A3dzBvdkZNZ0FaQlRZTVpKYW9JLzli?= =?utf-8?B?U3JTdU43cmtBT3ZON1pVV0E5dXFyekVFemFYaHNLUWV1T2xPR0w0U1llUzBa?= =?utf-8?B?UzRiWG5YbXpaNTJhMms2NXRxay9WYm9EOU1tenNtbWs2dncxeEVXVEdrUzUv?= =?utf-8?B?ZjY3eE9HS2E1YTlVUkdxdkhtOTUvRno5bkRSOVZCaTRwRDlSNXI0WXlxNitV?= =?utf-8?B?NXlVZkI1cmdIbm5Gei9SNDAyWXBSL3c0QUNJL0NzbXRzaUM1L2FlY25xdmpJ?= =?utf-8?B?c2pNSnFxd0ovaHJ5SmtTbHdtS0t3eFR3dHIwZXRhZUc4b3IzVFlHUUloT2Zo?= =?utf-8?B?eDRZVGZ5MmE0MkxSUHFQdTVLa290OTQ4SklhYSswaEhDSXhCYXpmSVpkc3JZ?= =?utf-8?B?bXgrSWpEczlJRHczakU0ODI0czhvNWFhTXkwaWlJRTZoUUdUZ0M0WG5aVXJT?= =?utf-8?B?L0ZxSVRITlZoUHAreTNXWWttVTV2eW9qS1lhRlV5R0VZVGc3YlFOVTRkTE52?= =?utf-8?B?S1NKbVVzUllrMy9XVXVnL1JZSkVlaGEvOFRxVUk2dVlML1ZCZmthMHQvOEtF?= =?utf-8?B?djRFek4wUGxYTm41RzJJbGQ4SlZMODlCR0l6NnUzN2MwS21rTStjM0pnc01E?= =?utf-8?B?emVzd3hScThLS0R5b0lpeGZDK2x1TFlNU2VHSU1mTGJHRzF5WUlOSWxrWFdk?= =?utf-8?B?QXpSQ0gyZENCWnFOMnFFK0svb3VsRWNMc1diSTRoVGYzOG8rV2FOOVJnTmdL?= =?utf-8?B?cHNCei9Rc3FJNHpHbVdGMHFGYS9mTVY0RlJPSUJpUmNIYU1IdUdWNjFtZ3ZX?= =?utf-8?B?Uk9GcW80WmIrcGc2L1A1eCs3Q09nRmJuSVZNeWpQL0JFYzNlMnhlV1ExRWs0?= =?utf-8?B?RHVZdzFTUHJMY01Cbmc1VXQ5ZWNNaHNxVnFLdXhBdTlkSExWRmtBaExpUUt4?= =?utf-8?B?cEREYUlKRmR1MVd6RmM1OGg3bFFaUUF3bGFzYnZjdVJlam1TOCtPNG1oQTVw?= =?utf-8?B?elg0YjJUSzU3TVlXK0tvbG1vSkQ3TWpmdS84RDhIWWJlUUNQOWFzQUovR1B1?= =?utf-8?B?Uy9QMnNLQ01tZHJRclF6b0xwdG1XZmpOY0JFekUvN0Z1SEpKSzNnQ0pIanRM?= =?utf-8?B?Rm55VEE4MlkvRUZFR0xhb1YrbWUzbU91dWdMWDlySFNiZCtwRzF5a2ZFcmdE?= =?utf-8?B?dXV1cU5jMWpzTnNRM2pSeHJqNmVGb1lwSklLdEdBNk9qS2tBcDVyQjViWTNE?= =?utf-8?B?UklCWC92N2VUcjhWeTVzL2Z4Q1BOZDJsNWxCM1ZOZnhWZmFxWVJxYWtzMXlU?= =?utf-8?B?OTlHVHFaRWxuM0NuSHVxcDgzd1Z2allONlE0NzBzRWNlallmSk56NnlxWWNv?= =?utf-8?B?aVB3OFlpTmxhU0tpNnlqV0s3QzRwTmhRRG9CVFpuWFBFQ3BvbWd5MmVGVXMr?= =?utf-8?B?MGFtbW1pUGI1dXJDNDZXOXFBRWdSRXhyNlJKaHBkUU9PMWV4NDFHQlRRWEds?= =?utf-8?B?RStrY0xqY3JSQ2ZHK1dKcnJ2K0ZMVnZMLzAxeUl2V1hXVVAzenhsQnN3OGw3?= =?utf-8?B?U1F1Rkw4TmlkZ1VWb3Z6bHFRbjM4NmFJTVpDY1R6SVpQQnJGSEdxZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 014a11d4-8280-4f90-847a-08de591651b4 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 17:55:53.0728 (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: +SOTp7pNu8lONOEWVHwvJ2Ziit/M5KGIFVXwLnR6hy2HEJc0GS7xz6lOAFzq5w8wBIwC2RBJSfpWwwK0KBWh/A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR03MB7500 On Mon, Nov 17, 2025 at 03:37:21PM +0100, Jan Beulich wrote: > Unlike the setting of HPET_EVT_LEGACY in hpet_broadcast_init(), the > setting of HPET_EVT_DISABLE in hpet_disable_legacy_broadcast() isn't init- > only and hence can race other flag manipulation (not all of which occur > while holding the channel's lock). While possibly any such updates would > only ever occur when HPET_EVT_LEGACY isn't set in the first place, this > doesn't look straightforward to prove, so better be on the safe side. > > Fixes: d09486dba36a ("cpuidle: Enable hpet broadcast by default") > Signed-off-by: Jan Beulich I also think it's quite likely that hpet_disable_legacy_broadcast() is not possible to be used concurrently while the setting of the other flags, that seem to happen in broadcast mode only, but better be on the safe side. Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 21 18:36:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 18:36:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210150.1521958 (Exim 4.92) (envelope-from ) id 1vid4C-0006Rs-Gp; Wed, 21 Jan 2026 18:36:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210150.1521958; Wed, 21 Jan 2026 18:36:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vid4C-0006Rl-DH; Wed, 21 Jan 2026 18:36:32 +0000 Received: by outflank-mailman (input) for mailman id 1210150; Wed, 21 Jan 2026 18:36: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 1vid4A-0006Rf-Lm for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 18:36:30 +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 185560b2-f6f8-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 19:36:28 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS7PR03MB5445.namprd03.prod.outlook.com (2603:10b6:5:2d0::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.9; Wed, 21 Jan 2026 18:36:24 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Wed, 21 Jan 2026 18:36: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: 185560b2-f6f8-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=b6DwqXCP/6JE6szDpUk3chBFVTKSx13xgCwpOaVi6B8OaKaNJzErFuU4R0icMT3fNDVVd/AECbs58VluKKZp11NSxjbfE/TYo+OiKS3w4F/7D2HX5QtSxdNNCTkqrtPIhXKnb5NgqIrLq8WuqVeC0WkgU/dJ9j0FOvALdcKKCzxbkgxEJ3Oe1CJoULpsuYmuOmtgO+4/WU6hIFuo6aDrZUVeyJ/Jh/Z2BkCa8iDjIOZ16rAI3ay7AA9V31l3szlRda/bnSPtQKHfpkVfwV2pd4bSQEHQ1/P3WEjALc0aSNkrbFvYqxt174G58DoZ291wq7NJTuABp6/g9aldW+RTZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wtGQX27Q3ZsY+bGqINgv6ClmHXKPnPmPTyr+7RkbJlw=; b=xK4uKqRxmW0W0cRcU9AJtjB1CZGkCdScN/O6AFWqArjK66vQGZvc+2X/HE+VFg8ybrENjUdTAm1jt6BpYHJm2GswUsFynTHZ+fJG6MHI8rufPiCMlZYO3tl5EpbRcXLJCaaIYxBU7x+Hc7FHkzl/mxF0q9mZIkzCtgd+oGgHH8iz+MhJVXvryK//zxhUT+zT6uK5THCL+zqTUjTq9pEQdhuOO5MO30qkaM3wj4CWua56+8zUH9LeXLzwzFfYvOwb9fHQB9ZGApbf7WTDZV/dZSNKdJ6ywgXwwPWV1ZvE5vlK0H05tOFNECgyAcgpnc1c39GmvfXmzt042z6VcDQnnw== 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=wtGQX27Q3ZsY+bGqINgv6ClmHXKPnPmPTyr+7RkbJlw=; b=RqY38WuSsKXIVTWoOK57vbdoxyz1QBbmgHviWvEPeo+o42vtmgXcrKugopbEfPpGIEMKE4rY/E/ompdOWkIfMFPS0nqXlIpe1ROrouiw2jiVwu5UTskJDcpzZKIuvJEdqIYX5dMLNEl94MPRuhzIb88yGD9PJs0VW8rR5L8TnFg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Wed, 21 Jan 2026 18:36:21 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Oleksii Kurochko , Community Manager Subject: Re: [PATCH v2 3/3] CHANGELOG: Note the new SVM bus-lock intercept To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260121142857.39069-1-alejandro.garciavallejo@amd.com> <20260121142857.39069-4-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260121142857.39069-4-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0592.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:295::9) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS7PR03MB5445:EE_ X-MS-Office365-Filtering-Correlation-Id: cbf647ca-47b3-4569-159a-08de591bfaf6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|13003099007|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?dmV3SFByRy9XRnpMSkZwWUNaSTQ1N2pMUGkxbjIxWGVYSjJPdnl5Q2IwUDVG?= =?utf-8?B?ZVY1YW9yN2hCRnpmOCs2eGxtdGFYdWhhTC9DVktENk5wT2NZZWNlZnRWWHF1?= =?utf-8?B?ejFvS3MrNjZ6amRjRkJLeVNIR25KeGRRL2c4N2xaQ09kQ1gra3FBRktwUFRZ?= =?utf-8?B?ZW96eUFZNFZEMjlDVE1EcEliVlNwb0RDT096U0V1VTVNY0VaMVVRaXltWkcz?= =?utf-8?B?TDIxZHVjYWFPVlFyenBJREYyeVFPS2c0YVFpOGlQZ2ovYUNmUmFZTmtRUlpn?= =?utf-8?B?Q2xKZHRuMVdHNTJ1bnhiaU1ObGF3Z2o2STJxK25nMkk0ZElSTVdNdUpQdDl2?= =?utf-8?B?QkoxdWc4NEg0NFA2QWsrNTFnNlpCc1JlTUhtL2RNM3k3dzFKZFlLSzBoTk1m?= =?utf-8?B?Ujl1bXcyZVpPS1g0VHRrVU5PMkx0M2J4Rk85aFFDS1ZMaUc1bTBYOHlzdlRW?= =?utf-8?B?NzI0ZXJ1bk0wVTR0Y3B3UDFHNHRGTlNYSjdDYm15Q3lJSitITGk1Q01QdU1U?= =?utf-8?B?bEN2dGo3RDYxKzluUUY0TWMzcklYSEc4ZFZWRWIvcU8xUDc2L1NDUmhUTFg1?= =?utf-8?B?UkZEM0tJZ1V6dWRzWmI2ZG1lQ0t0NW5iUWNUZzUxeDhJajI5Rzl0T3NDNXl3?= =?utf-8?B?cnlWZ3lhck1ab05kM09hTmpiZjZVcW5jRlhnajA1ZEtyalo3YjRSeGtQUDdJ?= =?utf-8?B?WVBJNDZMM3VlZUYrcHZFc21PQkpKaC9YYmswT21reXliMU55bnZVR1o3cE9R?= =?utf-8?B?YmFhUDhiZHI1SW4rQy9TV2N4NDUwOGxYYzUrOFpoM0RZN0ZIRjl1a25iNnNQ?= =?utf-8?B?U2t3VTVyb1FiTFFEVTEwcG9uMmF2VFRPTTdlVlBFOTdiRXlic1h3QjdQUzJp?= =?utf-8?B?eWxBQVR5RzhnRzJKYXJIVGRmOE1CWXVuSGdRaGNIUk1FZXpRdmV4eWUzVGVC?= =?utf-8?B?RDJpL1FUYUNucTdGUmtwS25qUUVKWU8vL0VPaXBmOHZ3b2o1dTh5c0dCMHBG?= =?utf-8?B?dXY5eGdJd09oV3RaUUIzR0ZnMjRIRXJPbmtncklsWFZBZEZxSzhFb2x4STZC?= =?utf-8?B?TVlsWDcyN3hrTlRDV09Iek5FaDZqTGJTNVQ0Zm5CZC9qTVRpNlVQRldRbG1G?= =?utf-8?B?a2ZJS3RCVVA0QWVvTGN0ZjIxZ3hQNnRYOGhncnFYL3RyZENlY1FYK1FjcUJx?= =?utf-8?B?UW1HK0pXYnRqSlNXMGpOK3JoTlZSbWRXQkx5ZHE4Z3Q4WEdHUEcrdGliY3Zl?= =?utf-8?B?Y1VhVVk3bFpkSU9kM1l6WGZ5WU5iYXJJYUp4UzArOHVBNVhOSHJaTkIxT0o5?= =?utf-8?B?czYxZzNSNDcwMXVxUUxpRHZ5VjZwUGM5RGpuZy9UcEc0cHFLM1UzVHBsbCtM?= =?utf-8?B?cEk3M3RsUVozbENYdkJmWEt4bmtiYi9ReDg2ZTc5MUxzbTRtbUNRU2JqVVVD?= =?utf-8?B?M1AxU2lzMzFZTmg4VlRZbmNGa0VzMU1xWDVYcDE0b2I4elRGWnArMmMrSXp6?= =?utf-8?B?TnVBNUZkQ2kweUlubU5sRWU2eUc3YUxqY0VkUS9DbkRHZ3VlVCtrR3pWRm15?= =?utf-8?B?TlBoZmttSjhTbkQ2RVdJT1RFMjQrNnlhVUhyU3N1V0FpQWM1UGJKUFZrcm9L?= =?utf-8?B?THlMYjZxeEtpQWV3NmluY3hwaEhwbURRZFhpUzRkNmY1OWo0YkN4NUZ0eHV0?= =?utf-8?B?aDZEdTlTTkxVUldxbWl5Q3lpWll0VGxTbVcrUGp3QTFYaERFOEtEMjVVNG9Y?= =?utf-8?B?RHdSSXdabDUzSktzUnVkQjNHd0Rld2dVMUZxZm5lY2Z6LzMzUVg5Z0tDMmZI?= =?utf-8?B?YkRWTzBneld5ZEJ4Rjk2WGJpK0ZPRFFnTTgxRTJ2Q3FzMDY0N2xZcTJaRk1J?= =?utf-8?B?MElKbTJVSFFYbUtCMEgxZmlZWDIrY0ZTeWZvU28rcDJuTVJpSHl3V2JFSUow?= =?utf-8?B?YVI5VEZld21YeUJKRHpzaEs2Q1pPUzF2T2lZWkFLRHpLTmhCMmR6bXVjaG1y?= =?utf-8?B?YncweFhhK2c1dEF3MFV5bHFhMUd5Q1dYamd5dXNWWldQUVRMYW9iZ0pIUXJk?= =?utf-8?Q?C0yuEX?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(13003099007)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?V01mcE01L3JnR2NwaStrN1ZRKzltQmtidWpjenp3SGE1YzhZS3dtWGpWb2Vo?= =?utf-8?B?Q1hBODZrK0lMKy9XOFVWUEdoRFBtN0xJZHZkcGQzV0JXV1M1aXVrWVhOSU9D?= =?utf-8?B?ZEdwYUFuS3pPUU9Rd0ljVU02Wk0xVTFYdkdjSktwanVvcm9uMmFxS2w5ZE5m?= =?utf-8?B?UFhZVnNTSFc4YW9mOWdMTVIvYnJKc21tOTU2YitCdFl4NzI1aHBLZGxtdzdJ?= =?utf-8?B?MFRCR3YzTjV2dHBVVjFYVkpXSy9PQTkxQ3Z1dlkzbitUZnMrcDhPaHFMSW4r?= =?utf-8?B?VzFSb2NmWWIrUkxmakxuK3ZIcmZxWXNZLy9EWjY2UFl0dmwrTGhoVkhjcVBq?= =?utf-8?B?eERPQ3IxSGxiTHE3N0xJSzdlYUNpM1VTWDR3WXBxSHFlczA1MkN0UFhxTGdO?= =?utf-8?B?WUl6VDlQQzNvUGkwZTkvNGQwaXlPOFBrdlNaZll1U1ZWb1pBMFJXYnlvVWtz?= =?utf-8?B?UVE4MytEWVFQWk50cDdPWU8zbHZnNDg0ZTZkYUFxMW9EMnZXUlFqcU0xbW5P?= =?utf-8?B?d3Erc01qenJ2NldXTWNON0U0bm5yekp4NUY1V2lmaXpTQXUxdHEwY3RPOGNU?= =?utf-8?B?Vm1xVVFOYkpnSWVnMlkrb3BwTDlSTVhBcXdJVEV5UWdGZUlMR0VOd0hCY1Vr?= =?utf-8?B?UnRXWnBGU2ZCYnAyWjllY04vVDVUOEd2K2RHODM5VXBYZVMwNHlFMTQ3Y0JM?= =?utf-8?B?dFRiR2FaajRXUkN4S0owb1EzRGUxRWFBVWppVFFWUXprMjlsUlJSNkUvYWZD?= =?utf-8?B?T1Z5MjNHUlVvUXB5cG15djlDZE5LK0tvbzRZdjFxd3FRQko2T3FnSndTVjVC?= =?utf-8?B?dlNXMHBEcTRiNEo5eDRDTHBJQmVCRFZ2TUVpd2xOZHYrVHkvZDBhcDRzM3Zp?= =?utf-8?B?U3Yvb1h1bjNZOGxkY2ZFRFVwdW1CV0ZJV1JhZmthUjdRZkQrMHRCLzZpNDNy?= =?utf-8?B?Nmw0TXpiWjZaaFpVRGdETGorTkZ4T0FEN08wZGdFSVlYOUtOQ1Zka3hEMXlz?= =?utf-8?B?MlJiZ0VydDNHaVV4RFJmSGJ4VXk5ZkZ3Q0FFV3YwMVQwYlNGVm9Cb1htZXZa?= =?utf-8?B?c2Q3NVB5dVNXcUlrVldpSTM0WFhtUExMQWxGWGRTbUhpYnY0SXhPT1p1SnA2?= =?utf-8?B?enFMS3JqMTdvYndjSm41WEtJL1hGR29hZEV0c2JiOWtqR2EzSE1NbllhTlNC?= =?utf-8?B?Y0o4SG02dy9VY3M3UmhGVzB5Q0d3VkV4VjBReGlTaENkd2tUUkx2bVZ5NXlM?= =?utf-8?B?RXNueU1wY0ptRVFFRzVUcGVuZXA1TUUxenBKcU1XRHlLMVNwWmU4WjhCdEI5?= =?utf-8?B?WUJ0eEhvZjhhbERPTis1NzV1RFNWenpmSmhSNmpJaWdtNCt6UnJnNzBBeXV0?= =?utf-8?B?bzIyYnlVd0pLRk5COFR3M1JRTlJFcHlGdzRKTDdpbTZaaDh5cVFMK0dtY1BR?= =?utf-8?B?NnhHTnJQUTNOMnJ5TnFpNW1HcXRtZExmZWRybzVNc2VQa1dWbjFlemRXd1N4?= =?utf-8?B?OTBlNjN5VWs5N2t6YThrMXdGK3pxSHc4b3BWNnZWdHFVQ3RvOG5hK1FGcDNz?= =?utf-8?B?WjBBREMxQXBzR1ZLV3l5NDdFRkg4cUlzV2NCVVg2OXpTaVo1U3dTd1lJMlVT?= =?utf-8?B?UW5OdlArMVQ5emJCWTBUUVcyVzh4TW1DcjZKMWx0V2hMOFEzUmw0RTBTclNi?= =?utf-8?B?ODVtVk5aOHYxMzlkOExCV1ZRb2JPZE1ZY2g3SXZWRzN0UjBUa1hhTUtZcUFx?= =?utf-8?B?ZERES0RITTRJeG9MVGxheHNVUUNUam9nTUNaajY3aTNwblY5THZRR293MTdt?= =?utf-8?B?WHBJYWQ4SlJodG1wQnN0TWtGblAyaFhxbGJwYXVBWkM4enFKcGpha2FFY0Jx?= =?utf-8?B?d1NMc05WZDVXVmYwL0ZtR0l2Tk42UVpSUFNkQUdpZDcxaVZWOHFVcDY5QU02?= =?utf-8?B?d0FFMDNlajI3cytiRWNKcnN3K01xSE51Uis3T1ZnbXlBVm5VazBjRmtySUtr?= =?utf-8?B?TjFQbE02WEFHTmJyNWM1SmNsMzBFSWJFK2RGMjRxUGtsMFo2akRONjhLRy9B?= =?utf-8?B?VTJMYUVreXI1TmR1WlgyUW9mdmd5c04yRlNwcU9vajBMTlh5Z050bHRRb0Qy?= =?utf-8?B?c0lzY3lYRERQRlZUZnRGc0xacWcyZjNqRVZCQXIyYm4vdTFlbU80MTRuMVZS?= =?utf-8?B?WmJicG81a1VBdmQzQU0rcmZPdU45Zm5USlg3dkxXTG1yeXpKZGQ4a0NvNzcv?= =?utf-8?B?YkMxV1BIYUNYOVJ0WTh2TWVqdmR4UHpQQ0M1RFNsbTVMek1oZ0syODg4Skow?= =?utf-8?B?cFg5emNGam9MejMwcHVieFRZamxPSG9CaHdySXJWZFh3RGErL3BEL0ZqYkVw?= =?utf-8?Q?enYZFCxRirdbtis8=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: cbf647ca-47b3-4569-159a-08de591bfaf6 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 18:36:24.4162 (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: beNVW1Mlp81jHFrleZdpNQsBx6YNzxygrxUikfN1Uf6uPyAyzFT/71h764YUeeGkv2+7iK08pVA2VMZhlwuBe4PBfaL5auXWlHzb+kxFj0A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5445 On 21/01/2026 2:28 pm, Alejandro Vallejo wrote: > Signed-off-by: Alejandro Vallejo > --- > CHANGELOG.md | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/CHANGELOG.md b/CHANGELOG.md > index 53d92a2597..07c1745f22 100644 > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -9,6 +9,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) > ### Changed > > ### Added > + - On x86: > + - AMD bus-lock detect, used by Xen to mitigate (by rate-limiting) the > + system wide impact of an HVM guest misusing atomic instructions. > A little too much copy&paste from the SPR section.  This wants unindenting by one level. Also, this text most importantly needs to identify which hardware the feature exists in.  I've reworked it to: diff --git a/CHANGELOG.md b/CHANGELOG.md index 53d92a259731..9c3bf0411ccc 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -9,6 +9,10 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)  ### Changed    ### Added + - On x86: +   - Support for Bus Lock Threshold on AMD Zen5 and later CPUs, used by Xen to +     mitigate (by rate-limiting) the system wide impact of an HVM guest +     misusing atomic instructions.    ### Removed   - On x86: The internet suggests that it's Zen5 rather than Zen4. Also I personally put the CHANGELOG update in the commit which finally implements the feature, rather than doing it after the fact.  This is more helpful when git blame-ing CHANGELOG to find things. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jan 21 18:44:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 18:44:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210165.1521987 (Exim 4.92) (envelope-from ) id 1vidBc-0008VO-Sy; Wed, 21 Jan 2026 18:44:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210165.1521987; Wed, 21 Jan 2026 18:44:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vidBc-0008VF-Q0; Wed, 21 Jan 2026 18:44:12 +0000 Received: by outflank-mailman (input) for mailman id 1210165; Wed, 21 Jan 2026 18:44: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 1vidBb-00083G-IM for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 18:44:11 +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 2c166339-f6f9-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 19:44:09 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by PAVPR03MB8945.eurprd03.prod.outlook.com (2603:10a6:102:322::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 18:43: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%5]) with mapi id 15.20.9542.008; Wed, 21 Jan 2026 18:43:53 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2c166339-f6f9-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tiwdzwxiSbIimjSfNuYPbg6CVzwWVTK+aCAaWM/LITO4/RxFArLqyagkt7Y+l7YBiFDlOq14vh8+OoUdnbIEuwW1WM+QeunzvWy2gNgbgSdcPllEcVMt9EwnIjiXIyqvW7xqFJtHdwETtAilbxR2cYcaVySAvIbj0TOjPOZ54M5tvSZ6mSZGidwcglIyH+bTPckuAtmu1FKEeEu3jpFb/uWwaXaAJ5oX+dDvgslQ2XgDRQyWMAuSQf9YS4na5Q6ArZI4CjZj3FibgTyhWNelC1dEnh45eQ6PTF9+T+5NIbdukEokpX6F4jZXD006WoJexRN7yG+FVXFnaqHeX+BtOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lzWySzET2/4GXGQxRXNBl6NOiWtba9SrTs7vJ5u/CHw=; b=V0C0B9hjXAUR2O7J9ap7bVBO4LJG+0yJXk+ihgb0K/ilNMrv41fVW7SHAolk6MULOtT4MNejQfhPnstf1JoEceI1KLl1JtJygWbxOFe6tmSTnSro83iEJEPoVlAzUey1+rmeJ2/64Inpsqg6ixHFOmki8aNlw2uSSrAlSFBydraPRP0pBXWiLd4/zorh7QbFC4kKwfvhejZYLovCrcraepw84FG7pl7mcyZ4s4H0lyOmIMYxWG4y52l2r16dQENqmA9FerQvjfEgfT7YYdl3UU42QiaBX8afiHI7ZblIpULPvYelsajY/00KBEkCDtjxJq0mEkP29Ii3hKmniWgw+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=lzWySzET2/4GXGQxRXNBl6NOiWtba9SrTs7vJ5u/CHw=; b=axA+tLuCAbA7uZtthwBuFns7xgvy6OCOsGDee3O0REbHTZuZx16y0Pf3pyuodVWWPPyyb7g4RCqLn2iY0qeNAxMmATHP3luoBU7jxIklYwa/REI10AzsPhQl39I8MDevJ9Stqj0Krwkzdhdp5JBlXWOSjNBmQnwL2+vaunSpJyPCwyaSQZEtUcPwHsMNQK41ZKYxNkCd8w8sIgWYNe1BncW4HpDdL4yeJX7QbYXvz+O+cFcQTgsfvf2BigtYdn5oDu44NCIxDQvXcmY3mtvxaUruSMOVnIIutyPUyPMsFiYb7en2drHOE320UZB0apOzoKpNWvJ8hKm7HTPlKXRgmw== 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 , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v8 0/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent support Thread-Topic: [PATCH v8 0/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent support Thread-Index: AQHciwXkopibo92WQkGjFOJW4wGoeg== Date: Wed, 21 Jan 2026 18:43: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_|PAVPR03MB8945:EE_ x-ms-office365-filtering-correlation-id: 8be6b88c-e009-401b-e2ae-08de591d06eb 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: =?utf-8?B?NUtPTzJqYWkyMWhhdEVnSDNLdnk0RUhBT3NYbWU3dTNMS0N4aEsrcHJUR3VY?= =?utf-8?B?ZUJ0dGdTVlRUQkZtL1lROUJrYkhaRmxHYVZCU3o4bndMb2FtMjZnRk9ZSUVR?= =?utf-8?B?K3VJVWdSTGo3THlnUmhNWC8waWUxMVlOMFhrVFhhdS9nWVpWTjVISExhbm5G?= =?utf-8?B?dmV0QnhZY0NQay9tMzh4Smo1MHdHOU0vUmVQakExVFV1VFRQM0kyVTFDVHV5?= =?utf-8?B?RGc5dnVXc1d6T3BnSFJqTTB3amRBR2lvZHJva3U1VDB5K0dmaW9rakRONWR3?= =?utf-8?B?a0hMTU1EQnM0OWVKZG5Ja05OYzZCQ1RTRlZrQnRRUml5b3d2enMvZ2pNMW16?= =?utf-8?B?UkZvQWorYzNKV1J3SlIrWHhWeTM0R290bUV0MkR4ZHRsMkRWcVJidlpZenZy?= =?utf-8?B?T3dhYlRLdVZzUFNiaVpoVWtMclVzTzR3c2dRdW55UmM0N2FUZjhxbzdvWE9K?= =?utf-8?B?SXVGeWc3SUEvSXNkVFZHYW0wTGJYWkJ4ckNnRzlzK1BCSS94WUJET1hwMWpz?= =?utf-8?B?VzlCekJIMDBLemtYeDJrTVpWUkl3VFQ5UG1aMDYyTm1MNlVMQWdlMnBlY0Zu?= =?utf-8?B?ZFNHMEV3eFVKRTZyZGdPbU5kOHRBazNCUWQvUzR4TVVlL2pDc2RCWG5GSllv?= =?utf-8?B?NVJKVjBEVDdqU0VhNWZSc1JxL2Z1bXdMSXdoc01FL2szeWtkK3BHOVFrSHl6?= =?utf-8?B?WXR6ZkJvMm52bFNsNnVjL0o2bzVlSW5naVZseUt4Yi9nT0xKM3F3RGlwRmxI?= =?utf-8?B?K2FLMVZqSUd1dk5zTVJ1a3h1dXV6RnNHbjdNcHVOWjlIZHBEVVVDQWgrVzVj?= =?utf-8?B?MGc0Vmd5cWFnZVRUUFhGc2pMd1VXb1pmVitmcG5Jb29vRUVOOW1zRlBiKzdV?= =?utf-8?B?Y2xNM085K1JMbDJaNWwxeW53SDd6cy81UXd5R29qNG9mc1AzQ0FFVHFXTHow?= =?utf-8?B?RFNNRDJMRDlBMEdGQ1JVaEkxVWJUTkovSE9VSG0yZnlTQWRpek0ydXZGeGQx?= =?utf-8?B?elU0YzZBd3JUUFQwUk45Wjl0L2gyN0ZCT21xK2diUG9NSDJrVXNZNFd0ZDhH?= =?utf-8?B?dWt6Q3JLTm1RZXdHLzIwRjFyS0gwY2dKeHF6Si9PSmxqc3ZEM1VUTFg0Ymh5?= =?utf-8?B?aDhzUFFzRy8rcEZOYnVwSFd3YnpqWTBqVHlNV3NVUmZrNGNoTXRVY1gyOGdW?= =?utf-8?B?SnpFTmlDN0tKcUJIMFg0SW1TOERkLzZxZkJ5bFl0djZvV1A0bWtLamd5Y3RU?= =?utf-8?B?blJ2cTY0T1VsbzgyUE5pYXhrMHJ1Y2IydzRQVHJKaGsrTEJqWVMzYTQ2aVBP?= =?utf-8?B?WC9GM05sVTJJckhyREFqb3U2bmNNTThVVThkMnlIZ0xtTnZwRlVvV0pHS1JB?= =?utf-8?B?NVZZMlpmNXl4K1BhSy8wdG00VkFZWVh3ZUpGWDcySm1WTmlXWkxjTWsyejVY?= =?utf-8?B?U242WnlrMkwzUXVUSDUwV2hGeGNISXFlajBWWHptVTZ2dTZ1dzg1d291dEpV?= =?utf-8?B?MzROTG1qUVVwenVmMXM4M2cwSi9xdjhadUcyZGpxdFNVb0FmZlJTNGtPaU1l?= =?utf-8?B?NFFZQ2dmYVhVRG5WbzFRS3g3bjBGTTBKTXZHdEd6U1pidHAyY0tkMU9GTkMy?= =?utf-8?B?ZCs0bGp4Mk5Qd1JWNHg0NjhOK0hHamlkT0FGUmVxbnJLNlpuemJ5R283NWhT?= =?utf-8?B?eU5RQ0tmZVpFclVFLzBFMVhCa2dBc2tzSWNTSndsU256S2taODRMaFVEUTlv?= =?utf-8?B?YVVBMjVCMmtSVmcwbHJBdlRTTVdMNDQrUXA1bW43TFp5T2pPWVJhYkd1QTRC?= =?utf-8?B?VnF2S3EveWxoTmprRnFQaTVkZlo4Y2h3Wlc3YkRxKzlHSHFEa215enR2WDIv?= =?utf-8?B?UHVrY0M5YkZpWkNBZnozVS9na1Axazc2ZjZ0djMxRll5NnprVWRucm5GZ1d1?= =?utf-8?B?UnBZQjkzUUJtaW9PU0FnK1ZQRWI2THdiQU5UbW9FUU1QcjJycGJqdzN3TmJt?= =?utf-8?B?blpUVGhTSkdhWjZTaTZ5ampQN3d0cEhUNkdvRHo5dmJaYjVFYkRwTlYweEJQ?= =?utf-8?B?ZzhRUnZNR2lBSVNlOFpxZkhDS1g1N3ptMFhGTVg1VXVFTCtGZ2xyZWdCbHM0?= =?utf-8?B?dkhlcEp4L3JnRjJ1SWVQTVVBYnhRYWVZN0FmSUZ4QXh1a00zN1Zad0R6ZE5W?= =?utf-8?Q?2j1P4JqNQvGBj10FZ05mTvA=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)(376014)(7416014)(1800799024)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bUNIeExydFFLY3huWHJSZ2VCeGkxTk5uM3V6MGNBaWpZL0p1ZUdTVEp5aXZv?= =?utf-8?B?K01TSzdDb0U4Y3lwemtDUWNucFhLV1IvV250TWUwUWNDWHVHc0lLWWxBeTR1?= =?utf-8?B?Y0w5QjdZRTF6NFpHdGZzWDhFNFNSOTAzb2FPUlR0RlREVkRSSXFoMkFyczFY?= =?utf-8?B?NW1nUjgrdHNXYTEvU0xBVkVlWm9abW5JNzFKSmVGTll5RzNIUmp0UnU5WVNq?= =?utf-8?B?YThnMkZmTmhoOTlWYWRuOXBKNC85b3BPdGtvRzQvME85RWViQVIxc0s1QUNi?= =?utf-8?B?SEo1aklzdWM5enBQYzhpVjBYQ2k2T2k5b0Y5VVpwSzB3SFpTSDRCSzEvK2gz?= =?utf-8?B?NDBVajNrMFZueFg4T3FiZ3ltdHR5bEsxUjg3MHRsaWNuYmJZdWFLOGhOVmJy?= =?utf-8?B?Tm9IQ2I4M3ZSUExEWHcxdzFsejFlNVRUdHZHckFieFVQZE9XS0RPRVpVTHFv?= =?utf-8?B?a1Y5eVFCUDdNQW9wQnRsUXlzME1kQzZNQ2ZxVjMxaGRSSjdpYzltYzRpZ1Ju?= =?utf-8?B?R0tURm5wNFhpenlFYmd2L1JraExES1F6dlJLMGRJTHM3QWxPK0JwM2FYc3NJ?= =?utf-8?B?eVhEVWtZNnl2MUw0azE2WmdhZk9EeGlTZlpud1FkZmhWZ0JjOVIvR1pKOWNO?= =?utf-8?B?dFg4YncyNVZBMysrV0ExSTlnamI1WGNaQnd5Q2VhallJbTFyMTFDUzBleWdB?= =?utf-8?B?dmpHTEpBeks0aStPSmVvaXYxOXcrMThyT0JVNDdxbDlKdjdBRlFUZ1M2by9I?= =?utf-8?B?bGU3OUN1ejlxMUxIQmJqMVVyajZ5QmZsU0JQZ2tGYzVYSHpTK3c2dndhUzl1?= =?utf-8?B?YlZxSG5VdXovczlTSTVMcm1kdExIM1ZNd3RIU3RIWWNKOWZuU0MwS2VzQ0JT?= =?utf-8?B?WlZXTmFxRFNwY0pBMFpPd2pzMXhGMjBaRVBoblFsbFNsdUZ4ZnFaK3BSVXB5?= =?utf-8?B?L2p4UERIOFVWOWphaGFwcEcrVk5LS3FoU2U0VzhEUEd1a1pCT1I4WWF1RkJx?= =?utf-8?B?aXZnekM4VktQeXVsd0l5VnlzSkgxYjlzWWFrOFltQ2gvMnZDK01MMVZHTHBL?= =?utf-8?B?cmpVNmlLbDM2V3VxR0M4VkdJSUo4T013L3RIM0Z6b1BpT2lLcUVEaGJKemdR?= =?utf-8?B?RUh4eHdyTXpqUDIyR2Z4ai9oZUdiOGJtWmQydjQ0Z25BSFRiMWpRQUhMbnBF?= =?utf-8?B?MTB6MjgrdTJpMVl4UTU0QXg0NjNQQWZqWnhLWnhKNmtzWVhOMkEvVTNlRGox?= =?utf-8?B?Q2N1L3RYTzhQaTZZYnVBbGdJUWYwSzVrdmVOYS9OZ0czY0o1Y3d6ZnNmTmhz?= =?utf-8?B?TXdJazhqcnNCc0JYRGQyMXh1ejFWMjhPUUdiMFIyRHl0c0gvUDZwRWJteTR1?= =?utf-8?B?L0VzajhxTzh3M1RuaUhBSmNXU3kwNjd0ZXpTcjBzLzFDZlc3M3RjWVljZkxN?= =?utf-8?B?ZE9Md3BKR0h2MWZjVm9EK2diaE5lYXJlV3J0SGtqWVZNbFlRWjlQejJYdHVE?= =?utf-8?B?amNDQXhHcHBGVmNQOStibWt1azBZRDNjVUYvNDg0bUI5NDBkZ1V4ZGlSRzRW?= =?utf-8?B?TmFocjBZU0NLMjRrM2R4aXBpOHVDcmNWc0RjcTJUNXRVVWVBVFBJWXQrY3p0?= =?utf-8?B?aGNPVTRrS3NLV2d5bThtSDNvempqZ2lnRjlzOVBqRU9JemRzTS9OeEJ6Yjlz?= =?utf-8?B?dUFWL0crSlhUT1JSNmFvdmVuMkpXUWozeXZsNU95czJrLzdnZ0JLckV1a0xF?= =?utf-8?B?VjhEOEJldER4RVpNeDU1TXQzVXZ2WFR5eENTbWluVjg4RGRCZzJ2ZWNSdyta?= =?utf-8?B?eFM0aytQL0M4bmxwcitxZXNJU2lOTDlob3p5WmZHOEFlYzBLRXJhSHIrK2kr?= =?utf-8?B?Z0hDaFkyWlNHcFU1V245UjJRcFBNVlZEditDdDd3bDZqSUJsOU5iUER5SW1v?= =?utf-8?B?SkMxNUU0SDU2UEVUUm1xaFJ6NzhuUGt5M1hPT1JFRlpzbXJGNHFZSU9jTk15?= =?utf-8?B?TTVsOFNUanh1MnF5b3AvSDVGSjJlRHVyRTVqN2hZRi94cXMvOHdOaVVJMjRv?= =?utf-8?B?bnY1T2UxNmhzNVBGcUNodkE5SnpIN0pUZFlBeXNFV2IwbUlWK0IzZGQ5cjZF?= =?utf-8?B?aTVVUk9HanFEZU9wazBLcVN3OVMwcCt0TzAwSEpFRTFjL0ZwUW9QdmkrQUZ0?= =?utf-8?B?SEljZkF6b0RFODRlNXdOa0hhKzZ5ZzZUS2ovb09lTFF0Sm8vSFVWK214a01V?= =?utf-8?B?bXJ3eE9vaVIra1pWWVJUTUpVbU9haXdxOG41Sy85aVNCZS9GaWI1V2FnTDYr?= =?utf-8?B?SjkxbXYrZjF1cG1XdFI2MmtlMjV0TGMyWi9IVUtrS3VHRjRhSVhldlRMRVlw?= =?utf-8?Q?zBzU8ZKfisKPnONs=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <1BE1B58F7F91AC4C921185735E6F95E5@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: 8be6b88c-e009-401b-e2ae-08de591d06eb X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2026 18:43:53.7703 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4voT/VNQ13UMJw/J65zChMsKxrLOsI+4mM7RiwqViM1YiZvj6r+TS1lYWj19Tp8ZH2y/8aU6b6Lyw4hH/ox8HEZ3FX23pP1lJlJh5gdDodQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB8945 SW5yb2R1Y2luZyBwYXRjaCBzZXJpZXMgd2hpY2ggaW5jbHVkZXMgaW1wbGVtZW50YXRpb24gb2Yg dGhlIFNDSSBTQ01JDQpTTUMgbXVsdGktYWdlbnQgc3VwcG9ydC4NClRoaXMgcGF0Y2ggc2VyaWVz IGZvbGxvd3MgUkZDIHY1IFszXSBzZXJpZXMgd2hpY2ggd2FzIGludHJvZHVjaW5nIGJvdGgNClND TUkgc2luZ2xlLWFnZW50IGFuZCBtdWx0aS1hZ2VudCBzdXBwb3J0LiBBZnRlciB0aGUgZGlzY3Vz c2lvbiBpdCB3YXMNCmRlY2lkZWQgdG8gc3BsaXQgZmVhdHVyZXMgYW5kIHVwc3RyZWFtIHNpbmdl LWFnZW50IHN1cHBvcnQgZmlyc3QuIFRoaXMNCmZlYXR1cmUgaXMgbWVyZ2VkIGZvciBub3cgdG8g djQuMjEtcmMyLg0KSSdtIHN0YXJ0aW5nIHRoaXMgcGF0Y2ggc2VyaWVzIGZyb20gdjYgdG8gc2F2 ZSB0aGUgZGlzY3Vzc2lvbiBoaXN0b3J5DQphbmQgZG9uJ3QgYnJlYWsgY2hhbmdlcyBsb2cuDQoN ClBhdGNoIC0geGVuL2RvbWN0bDogZXh0ZW5kIFhFTl9ET01DVExfYXNzaWduX2RldmljZSB0byBo YW5kbGUgbm90DQpvbmx5IGlvbW11DQotIGFkZCBjaGFpbmdlZCBoYW5kbGluZyBvZiBhc3NpZ25l ZCBEVCBkZXZpY2VzIHRvIHN1cHBvcnQNCmFjY2Vzcy1jb250cm9sbGVyIGZ1bmN0aW9uYWxpdHkg dGhyb3VnaCBTQ0kgZnJhbWV3b3JrLg0KQ2hhbmdlIHdhcyBkb25lIGluIHR3byBwYXJ0czoNCiAt IGNhbGwgdG8gc2NpX2RvX2RvbWN0bCgpIHRvIGRvX2RvbWN0bCgpDQogLSB1cGRhdGUgaW9tbXVf ZG9fZHRfZG9tY3RsKCkgdG8gY2hlY2sgZm9yIGR0X2RldmljZV9pc19wcm90ZWN0ZWQoKQ0KIGFu ZCBub3QgZmFpbCBpZiBEVCBkZXZpY2UgaXMgbm90IHByb3RlY3RlZCBieSBJT01NVQ0KDQpQYXRj aCAtIHhlbi9hcm06IHNjbWk6IGludHJvZHVjZSBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJp dmVyDQotIGFkZCBYZW4tc3BlY2lmaWMgU0NNSSBjb250YWluZXIgY29tcGF0aWJsZSBgeGVuLHNj aWANCiAgdW5kZXIgYC9jaG9zZW4veGVuYDsgWGVuIGJpbmRzIG9ubHkgdG8gdGhlIGBhcm0sc2Nt aS1zbWNgIGluc2lkZSBpdCBhbmQNCiAgaWdub3JlcyBvdGhlciBTQ01JIG5vZGVzIChlLmcuIHVu ZGVyIGAvZmlybXdhcmVgKS4NCi0gYWRkIGBzY21pLXNlY29uZGFyeS1hZ2VudHNgIGFuZCBgI3Nj bWktc2Vjb25kYXJ5LWFnZW50cy1jZWxsc2AgdG8gZGVzY3JpYmUNCiAgZnVuY19pZC9zaG1lbS8o b3B0aW9uYWwgYWdlbnRfaWQpIHR1cGxlcyBmb3Igc2Vjb25kYXJ5IGFnZW50cy4NCi0gZWFjaCBn dWVzdCB1c2luZyBTQ01JIHN1cHBsaWVzIGl0cyBhZ2VudF9pZCAoZG9tMCB2aWENCiAgYHhlbSxk b20wLXNjaS1hZ2VudC1pZD1gIHBhcmFtZXRlciBpbiB4ZW4sc2NpIGNvbXBhdGlibGUgbm9kZSwN CiAgdG9vbHN0YWNrIHZpYSBgYXJtX3NjaSA9ICJ0eXBlPXNjbWlfc21jX211bHRpYWdlbnQsYWdl bnRfaWQ9Li4uImAsIGRvbTBsZXNzDQogIHZpYSBgeGVuLHNjaV90eXBlYCArIGB4ZW4sc2NpLWFn ZW50LWlkYCBpbiBgeGVuLGRvbWFpbmApLg0KLSBmYWN0b3Igb3V0IFNDTUkgZ2VuZXJpYyBkZWZp bml0aW9ucyBhbmQgc2htZW0gY29kZS4NCi0gcGFzc3Rocm91Z2ggY29uZmlndXJhdGlvbiBmb3Ig U0NNSSBndWVzdHMgbWlycm9ycyBvdGhlciBIVyBwYXNzdGhyb3VnaC4NCg0KUGF0Y2ggLSBkb2Nz OiBhcm06IGFkZCBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJpdmVyIGRvY3MNCi0gZG9jdW1l bnQgdGhlIFhlbiBTQ01JIGNvbnRhaW5lciB1bmRlciBgL2Nob3Nlbi94ZW4veGVuX3NjbWlfY29u ZmlnYCBhbmQgdGhlDQogIG1lZGlhdG9y4oCZcyBiaW5kaW5nIHJ1bGVzOyB1cGRhdGUgZXhhbXBs ZXMgYWNjb3JkaW5nbHkuDQoNCkFsbCBYZW4tc3BlY2lmaWMgU0NNSSBjb25maWd1cmF0aW9uIG5v dyBsaXZlcyB1bmRlciBgL2Nob3Nlbi9gDQp0byBrZWVwIGhvc3QgRFQgY2hhbmdlcyBpc29sYXRl ZCB3aGlsZSBsZWF2aW5nIHRoZSBob3N0IGAvZmlybXdhcmUvc2NtaWANCnVudG91Y2hlZCBmb3Ig RG9tMCBjb25zdW1wdGlvbi4NCg0KQ29kZSBjYW4gYmUgZm91bmQgYXQ6DQpodHRwczovL2dpdGh1 Yi5jb20vb2xla3NpaW1vaXNpZWlldi94ZW4vdHJlZS9zY21pX21hX3Vwc3RydjYNCg0KWzFdIFJG QyB2MjoNCmh0dHA6Ly9wYXRjaHdvcmsua2VybmVsLm9yZy9wcm9qZWN0L3hlbi1kZXZlbC9jb3Zl ci9jb3Zlci4xNjQ0MzQxNjM1LmdpdC5vbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbS8NClsyXSBS RkMgdjM6DQpodHRwczovL3BhdGNod29yay5rZXJuZWwub3JnL3Byb2plY3QveGVuLWRldmVsL3Bh dGNoLzIwMjUwMzExMTExNjE4LjE4NTA5MjctMS1ncnlnb3JpaV9zdHJhc2hrb0BlcGFtLmNvbQ0K WzNdIFJGQyB2NToNCmh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC9jb3Zlci4xNzUz MTg0NDg3LmdpdC5vbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbS8NCls0XSBTQ01JIHNpbmdsZS1h Z2VudDoNCmh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC9jb3Zlci4xNzU2OTk1NTk1 LmdpdC5vbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbS8NClNDTUkgc3BlYzoNCmh0dHBzOi8vZGV2 ZWxvcGVyLmFybS5jb20vZG9jdW1lbnRhdGlvbi9kZW4wMDU2L2UvP2xhbmc9ZW4NCg0KU0NNSSBi aW5kaW5nczoNCmh0dHBzOi8vd2ViLmdpdC5rZXJuZWwub3JnL3B1Yi9zY20vbGludXgva2VybmVs L2dpdC90b3J2YWxkcy9saW51eC5naXQvdHJlZS9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmlu ZGluZ3MvZmlybXdhcmUvYXJtLHNjbWkueWFtbA0KaHR0cHM6Ly93ZWIuZ2l0Lmtlcm5lbC5vcmcv cHViL3NjbS9saW51eC9rZXJuZWwvZ2l0L3RvcnZhbGRzL2xpbnV4LmdpdC90cmVlL0RvY3VtZW50 YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9hY2Nlc3MtY29udHJvbGxlcnMvYWNjZXNzLWNvbnRy b2xsZXJzLnlhbWwNCg0KUmVmZXJlbmNlIEVMMyBGVzoNClJQSTU6IGh0dHBzOi8vZ2l0aHViLmNv bS94ZW4tdHJvb3BzL2FybS10cnVzdGVkLWZpcm13YXJlL2NvbW1pdHMvcnBpNV9kZXYvDQpSZW5l c2FzIHY0aDoNCmh0dHBzOi8vZ2l0aHViLmNvbS9HcnlnaXJpaVMvYXJtLXRydXN0ZWQtZmlybXdh cmUvY29tbWl0cy9yY2FyX2dlbjRfdjIuN192NHgtc2NtaV91cGQvDQoNCmJhc2UtY29tbWl0OiBk YmU2MGYyNDRjIChVcGRhdGUgWGVuIHRvIDQuMjEsIDIwMjUtMDItMjEpDQoNCkNoYW5nZXMgaW4g djg6DQotIGNoZWNrIGZvciBDT05GSUdfQVJNX1NDSSB0byBiZSBlYmFibGVkIGluc3RlYWQgb2Yg Q09NRklHX0FSTSBiZWZvcmUNCmNhbGxpbmcgc2NpX2RvX2RvbWN0bA0KLSByZXdvcmsgc2NpX2Rv X2RvbWN0bCBjYWxsIHRvIGF2b2lkIGV4dHJhIGNoZWNrcywgaW1wcm92ZWQgZXJyb3INCmhhbmRs aW5nLg0KLSBkbyBub3QgcHJvcGFnYXRlIHJldDEgaWYgc2NpX2RvX2RvbWN0bCByZXR1cm5lZCBw b3NpdGl2ZSByZXQNCi0gdXBkYXRlZCBjb21tZW50IGluIGRvbWN0bC5jIGNvZGUNCi0gc3dpdGNo ZWQgdG8gb3JkZXJlZCBhY2Nlc3NvcnMgdG8gYWRkcmVzcyB0aGUgb3JkZXJpbmcgYW5kIGJhcnJp ZXINCmNvbmNlcm5zLg0KLSB1cGRhdGVkIHRoZSBkb2N1bWVudGF0aW9uIHRvIG1hdGNoIHRoZSBp bXBsZW1lbnRhdGlvbiBhbmQgZXhwbGljaXRseQ0Kc3RhdGUgdGhlIHN1cHBvcnRlZCBhY2Nlc3Mg c2l6ZXMgYW5kIGdyYW51bGFyaXR5Lg0KLSByZW5hbWUgbWVtY3B5XyogaW1wbGVtZW50YXRpb24g ZmlsZXMgdG8gbWVtY3B1LSogdG8gZm9sbG93IG5hbWluZw0KY29udmVuc2lvbg0KLSBmaXggaW5k ZW50YXRpb24gdG8gbWF0Y2ggWGVuIHN0eWxlDQotIGZpeCBpbnRlbmRhdGlvbiB0byBtYXRjaCBY ZW4gc3R5bGUNCi0gbW92ZSBtZW1jcHkte2Zyb20vdG99aW8gdG8gbW9yZSBjb252ZW5pZW50IGxp YnJhcnkgcGxhY2UNCi0gdXBkYXRlIHhlbl9zY21pIGZ1bmNfaWQgaW4gY29tbWl0IGRlc2NyaXB0 aW9uDQotIHVwZGF0ZWQgZG9jdW1lbnRhdGlvbiB3aXRoIHRoZSBuZXcgRFQgZm9ybWF0DQotIHVw ZGF0ZWQgb3B0X2RvbTBfc2NtaV9hZ2VudF9pZCBzZXR0aW5nIHRvIGF2b2lkIGl0IHRvIGJlIGVx dWFsDQpTQ01JX0FHRU5UX0lEX0lOVkFMSUQuDQotIGNoYW5nZWQgU0NNSV9BR0VOVF9JRF9JTlZB TElEIGZyb20gMHhmZiB0byBVSU5UOF9NQVggd2hpY2ggbWFrZXMNCmNvZGUgbW9yZSBjbGVhciBz aG93aW5nIHRoYXQgVUlOVDhfTUFYIGlzIHRoZWF0ZWQgbGlrZSBpbnZhbGlkDQphZ2VudF9pZCBh bmQgY291bGRuJ3QgYmUgdXNlZC4gQWxzbyBleGNsdWRlZCBTQ01JX0FHRU5UX0lEX0lOVkFMSUQN CmZyb20gYWNjZXB0YWJsZSB2YWx1ZSByYW5nZQ0KLSByZW1vdmUgb3V0ZGF0ZWQgeGVuLGNvbmZp ZyBwcm9wZXJ0eSBpZ25vcmUsIGFkZGVkIHhlbixzY2kgY29tcGF0aWJsZQ0KdG8gc2tpcF9tYXRj aGVzIGluIGhhbmRsZV9ub2RlDQotIGFkZCBkb2N1bWVudGF0aW9uIGZvciBwcmUtZXhpc3Rpbmcg c2NtaS1zbWMtcGFzc3Rocm91Z2ggY29tbWFuZCBsaW5lDQpvcHRpb24gaW4gYWxwaGFiZXRpY2Fs bHkgY29ycmVjdCBsb2NhdGlvbiAoaW4gJ3MnIHNlY3Rpb24pDQotIGFkZCBub3RlIHRvIGNvbW1p dCBkZXNjcmlwdGlvbiBhYm91dCBkb2N1bWVudGF0aW9uIGZvciBwcmV2aW91c2x5DQp1bmRvY3Vt ZW50ZWQgc2NtaS1zbWMtcGFzc3Rocm91Z2gNCi0gRml4IFNNQyBJRHMgaW4gRFQgZXhhbXBsZXMg KFhlbiBtYW5hZ2VtZW50IHVzZXMgMHg4MjAwMDAwMywgRG9tMCB1c2VzIDB4ODIwMDAwMDIpDQot IEFkZCBleHBsaWNpdCBub3RlIGV4cGxhaW5pbmcgd2h5IERvbTAgYW5kIFhlbiBjaGFubmVscyBk byBub3QgY29uZmxpY3QNCi0gRG9jdW1lbnQgZG9tMGxlc3MgbXVsdGktYWdlbnQgY29uZmlndXJh dGlvbiBleGFtcGxlICh4ZW4sc2NpX3R5cGUgLyB4ZW4sc2NpLWFnZW50LWlkKQ0KLSBBZGQgc2Nt aV94ZW4gbm9kZSB0byBhZ2VudC1kaXNjb3ZlcnkgZXhhbXBsZSB3aXRoICNzY21pLXNlY29uZGFy eS1hZ2VudHMtY2VsbHMgPSAyDQotIERyb3AgZG9tMD1zY2ktYWdlbnQtaWQgY29tbWFuZCBsaW5l IGhhbmRsaW5nOyBEb20wIFNDTUkgaXMgbm93IGVuYWJsZWQgdmlhDQogIHhlbixkb20wLXNjaS1h Z2VudC1pZCBpbiB0aGUgeGVuLHNjaSBEVCBjb250YWluZXINCi0gUmVmcmVzaCBkb2NzIGFuZCBl eGFtcGxlcyB0byBtZW50aW9uIHRoZSBEVCBwcm9wZXJ0eSBpbnN0ZWFkIG9mIHRoZSBjbWRsaW5l IG9wdGlvbg0KLSB1cGRhdGUgZG9jdW1lbnRhdGlvbiB0byBtYXRjaCB0aGUgbGFzdCBEVCBmb3Jt YXQNCi0gZml4ZWQgUlNUOiAiLi4uIGNvZGUtYmxvY2s6OiBkdHMiIC0+ICIuLiBjb2RlLWJsb2Nr OjogZHRzIg0KLSB1cGRhdGUgZG9jdW1lbnRhdGlvbiB3aXRoIGRvbTBsZXNzIGNvbmZpZ3VyYXRp b24gZXhhbXBsZQ0KLSB1cGRhdGUgZG9jdW1lbnRhdGlvbiB3aXRoIG5ldyBwYXJhbSB4ZW4sZG9t MC1zY2ktYWdlbnQtaWQNCmluc3RlYWQgb2YgdGhlIGNvbW1hbmQgbGluZSBwYXJhbWV0ZXINCg0K Q2hhbmdlcyBpbiB2NzoNCi0gdXBkYXRlIGRvbWN0bCB0byBidWlsZCBvbiBib3RoIEFybSBhbmQg eDg2IHBsYXRmb3Jtcw0KLSBtb3ZlIHJldDEgZGVjbGFyYXRpb24gdG8gdGhlIHRvcCBvZiB0aGUg ZnVuY3Rpb24gYXMgcmVxdWlyZWQgYnkgY29kZQ0Kc3R5bGUNCi0geDg2IGd1aWRhbmNlOiByZW1v dmVkIHRoZSBzcGVjdWxhdGl2ZSBub3RlOyBoZWFkZXIgbm93IGp1c3Qgc2F5cw0KICBlYWNoIGFy Y2ggc3VwcGxpZXMgaXRzIG93biBpbXBsZW1lbnRhdGlvbiBvciBtYWNyby4NCi0gbmFtZSBzcGFj aW5nOiBkcm9wcGVkIHRoZSBkb3VibGUtdW5kZXJzY29yZTsgdGhlIGhlbHBlcnMgYXJlIG5vdw0K ICBtZW1jcHlfZnJvbWlvIC8gbWVtY3B5X3RvaW8uIFRoZSBoZWFkZXIgYWxzbyBleHBsaWNpdGx5 IGFsbG93cyBhbg0KICBhcmNoIHRvIGRlZmluZSB0aGVzZSBhcyBtYWNyb3MgYmVmb3JlIGluY2x1 ZGluZyBpdC4NCi0gdXBkYXRlZCBpby5jIHRvIGtlZXAgMzItYml0IHRyYW5zZmVycyBzYWZlIG9u IGFybTMyDQotIG1vdmVkIHRvIF9fcmF3X3JlYWQqL19fcmF3X3dyaXRlKiBhY2Nlc3NvcnMgdG8g YXZvaWQgZW5kaWFubmVzcyBjb252ZXJzaW9uLg0KLSBzcGxpdCB0aGUgaGVscGVycyBpbnRvIHNl cGFyYXRlIGNvbXBpbGF0aW9uIHVuaXRzDQotIHJld29yayBzY21pIG5vZGVzIGZvciB4ZW4gdG8g bWF0Y2ggb24gY29tcGF0aWJsZSBzdHJpbmcgaW5zdGVhZCBvZg0KdGhlIGRpcmVjdCBwYXRoDQot IHVwZGF0ZSBkb2N1bWVudGF0aW9uIGluIHNlY3Rpb24gb2YgdGhlIHhlbl9zY21pIGNvbmZpZ3Vy YXRpb24gd2hpY2gNCmlzIG1hdGNoZWQgYnkgInhlbixzY2kiIGNvbXBhdGlibGUgaW5zdGVhZCBv ZiB0aGUgZGlyZWN0IHBhdGguDQoNCkNoYW5nZXMgaW4gdjY6DQotIGNoYW5nZSBpb21tdV9kb19k b21jdGwgYW5kIHNjaV9kb19kb21jdGwgY29tbWFuZCBvcmRlciBhbmQNCmNhbGwgc2NpX2RvX2Rv bWN0bCBmaXJzdCB3aGljaCB3aWxsIHByb2R1Y2UgY2xlYW5lciBjb2RlIHBhdGguDQpBbHNvIGRy b3BwZWQgY2hhbmdpbmcgcmV0dXJuIGNvZGUgd2hlbiBpb21tdSB3YXMgZGlzYWJsZWQgaW4NCmlv bW11X2RvX2RvbWN0bC4NCi0gc29ydGVkIG9ianMgaW4gTWFrZWZpbGUgYWxoYWJldGljYWxseQ0K LSBhZGRlZCBuZXdsaW5lIGF0IHRoZSBlbmQgb2YgTWFrZWZpbGUNCi0gdXNlZCB1aW50e059X3Qg aW50ZWFkIG9mIHV7Tn0NCi0gYWRkIGNvbW1lbnQgYWJvdXQgd2h5IDMyIGJpdCBJTyBvcGVyYXRp b25zIHdlcmUgdXNlZA0KLSB1cGRhdGVkIGNhc3Qgb3BlcnRhaW9ucyB0byBhdm9pZCBkcm9wcGlu ZyBjb25zdG5lc3Mgd2hpY2ggaXMgd3JvbmcNCi0gbW92ZSBmdW5jdGlvbiBkZWZpbml0aW9ucyB0 byBnZW5lcmljIHBsYWNlIHNvIHRoZSBjb3VsZCBiZSByZXVzZWQgYnkNCm90aGVyIGFyY2gNCi0g YWRkIFNQRFggdGFnIHRvIGlvLmMNCi0gdXBkYXRlZCBzY21pLXNobWVtIHRvIHVzZSBpby5oIGZy b20gZ2VuZXJpYyBsb2NhdGlvbg0KLSB1cGRhdGUgc2NtaV9hZ2VudF9pZCBwYXJhbWV0ZXIgdG8g YmUgcHJvdmlkZWQgaW5zaWRlIGRvbTA9IHBhcmFtZXRlcg0KbGlzdCBhbmQgaGF2ZSB0aGUgZm9s bG93aW5nIGZvcm1hdCAiZG9tMD1zY2ktYWdlbnQtaWQ9MCINClRoaXMgY2hhbmdlIHdhcyBkb25l IGFzIGEgcmVzcG9uc2UgZm9yIFN0ZWZhbm8gY29tbWVudCBhbmQNCnJlcXVpcmVzIGEgbG90IG9m IGNvZGUgY2hhbmdlcywgYnV0IHByb2R1Y2VzIG11Y2ggY2xlYW5lciBzb2x1dGlvbg0KdGhhdCdz IHdoeSBJJ3ZlIGFkZGVkIGl0IHRvIHRoZSBjb2RlLg0KLSBmaXggZmlsZSBjb21tZW50cyBhbmQg cmV0dXJuIGNvZGVzDQotIGZpeCBsZW5naHQgY2hlY2tzIGluIHNobWVtX3tnZXQscHV0fV9tZXNz YWdlIHRvIHVzZSBvZmZzZXRvZg0KLSByZW1vdmUgbGVuIG1lbWJlciBmcm9tIHNjbWlfY2hhbm5l bCBzdHJ1Y3R1cmUgYXMgaXQgaXMgbm90IHVzZWQNCi0gc2V0IHNjbWktc2Vjb25kYXJ5LWFnZW50 cyBwcm9wZXJ0eSB0byBiZSBtYW5kYXRvcnkgc2luY2UgaWYgbm8NCnNlY29uZGFyeSBhZ2VudHMg d2VyZSBwcm92aWRlZCB0aGVuIHRoZXJlIGlzIG5vIHNlbmNlIHRvIGVuYWJsZSBzY21pDQp3aGVu IG5vIHNlY29uZGFyeSBhZ2VudHMgYXJlIHBvcHVsYXRlZCB0byB0aGUgRG9tYWlucw0KLSB1cGRh dGUgZG9jdW1lbnRhdGlvbiBpbiBib290aW5nLnR4dCwgYWRkZWQgeGVuX3NjbWkgbm9kZSB0byB0 aGUNCmV4YW1wbGUNCi0gYWRqdXN0IGQtPmFyY2guc2NpX2VuYWJsZWQgdmFsdWUgaW4gc2NtaV9k b21haW5fZGVzdHJveQ0KLSBmaXggbG9jayBtYW5hZ2VtZW50IGluIHNtY19jcmVhdGVfY2hhbm5l bCBjYWxsDQotIGF2b2lkIGV4dHJhIG1hcF9jaGFubmVsX21lbW9yeSBjb21tYW5kIGZvciBYZW4g bWFuYWdlbWVudCBjaGFubmVsDQpiZWNhdXNlIGNvbGxlY3RfYWdlbnRfaWQgY2FsbCB1bm1hcHMg bWVtb3J5IGlmIERPTUlEX1hFTiBpcyBub3QNCnNldC4gU28gZm9yIFhlbiBtYW5hZ2VtZW50IGNo YW5uZWwgd2UgY2FuIGluaXQgZG9tYWluX2lkIGFkIERPTUlEX1hFTg0KYmVmb3JlIGNhbGxpbmcg Y29sbGVjdF9hZ2VudF9pZCBzbyBtZW1vcnkgc2hvdWxkbid0IGJlIHVubWFwcGVkLg0KLSByZW1v dmUgYWxsIEhWQyBtZW50aW9ucyBmcm9tIHRoZSBtdWx0aS1hZ2VudCBkb2MNCi0gdXBkYXRlIHNj aS1hZ2VudC1pZCBwYXJhbWV0ZXIgZGVzY3JpcHRpb24gaW4gdGhlIGRvY3VtZW50YXRpb24NCi0g YWRkIG1pc3NpbmcgU2lnbi1vZg0KLSBtaW5vciBmaXhlcyBhY3Jvc3MgdGhlIGRvY3VtZW50DQoN CkNoYW5nZXMgaW4gdjU6DQotIHJldHVybiAtRUlOVkFMIGlmIG1lZGlhdG9yIHdpdGhvdXQgYXNz aWduX2R0X2RldmljZSB3YXMgcHJvdmlkZWQNCi0gaW52ZXJ0IHJldHVybiBjb2RlIGNoZWNrIGZv ciBpb21tdV9kb19kb21jdGwgaW4NClhFTl9ET01DVExfYXNzaWduX2RldmljZSBkb21jdGwgcHJv Y2Vzc2luZyB0byBtYWtlIGNsZWFuZXIgY29kZQ0KLSBjaGFuZ2UgLUVOT1RTVVBQIGVycm9yIGNv ZGUgdG8gLUVOWElPIGluIHNjaV9kb19kb21jdGwNCi0gaGFuZGxlIC1FTlhJTyByZXR1cm4gY29t ZGUgb2YgaW9tbXVfZG9fZG9tY3RsDQotIGxlYXZlICFkdF9kZXZpY2VfaXNfcHJvdGVjdGVkIGNo ZWNrIGluIGlvbW11X2RvX2R0X2RvbWN0bCB0byBtYWtlDQpjb2RlIHdvcmsgdGhlIHNhbWUgd2F5 IGl0J3MgZG9uZSBpbiAiaGFuZGxlX2RldmljZSIgY2FsbCB3aGlsZQ0KY3JlYXRpbmcgaHdkb20o ZG9tMCkgYW5kICJoYW5kbGVfcGFzc3Rocm91Z2hfcHJvcCIgY2FsbCBmb3IgZG9tMGxlc3MNCmNy ZWF0aW9uDQotIGRyb3AgcmV0dXJuIGNoZWNrIGZyb20gc2NpX2Fzc2lnbl9kdF9kZXZpY2UgY2Fs bCBhcyBub3QgbmVlZGVkDQotIGRvIG5vdCByZXR1cm4gRUlOVkFMIHdoZW4gYWRkaWduX2R0X2Rl dmljZSBpcyBub3Qgc2V0LiBUaGF0IGlzDQpiZWNhdXNlIHRoaXMgY2FsbGJhY2sgaXMgb3B0aW9u YWwgYW5kIG5vdCBpbXBsZW1lbnRlZCBpbiBzaW5nbGUtYWdlbnQgZHJpdmVyDQotIG1vdmUgbWVt Y3B5X3RvaW8vZnJvbWlvIHRvIHRoZSBnZW5lcmljIHBsYWNlDQotIGZpeCBkZXZpY2UtdHJlZSBl eGFtcGxlIGZvcm1hdCBpbiBib290aW5nLnR4dCwgYWRkZWQgIjsiIGFmdGVyICJ9Ii4NCi0gdXBk YXRlIGRlZmluZSBpbiBzY21pLXByb3RvLmgNCi0gdXBkYXRlIGRlZmluZSBpbiBzY21pLXNobWVt LmggZmlsZQ0KLSBzY21pX2Fzc2lnbl9kZXZpY2UgLSBkbyBub3QgaWdub3JlIC1FT1BOT1RTVVBQ IHJldHVybg0KY29kZSBvZiB0aGUgZG9fc21jX3hmZXINCi0gcmVtb3ZlIG92ZXJ3cml0aW5nIGFn ZW50X2NoYW5uZWwtPmFnZW50X2lkIGFmdGVyDQpTQ01JX0JBU0VfRElTQ09WRVJfQUdFTlQgY2Fs bA0KLSBhZGQgbXVsdGktYWdlbnQgZmlsZXMgdG8gdGhlIE1BSU5UQUlORVJTDQotIGFkZCBTQ01J IG11bHRpLWFnZW50IGRlc2NyaXB0aW9uIHRvIHRoZSBTVVBQT1JULm1kDQotIGhhbmRsZSBBUk1f U01DQ0NfSU5WQUxJRF9QQVJBTUVURVIgcmV0dXJuIGNvZGUgYW5kIHJldHVybiAtRUlOVkFMDQpm b3Igc21jIGNhbGwNCi0gdXBkYXRlZCBjb2xsZWN0X2FnZW50cyBmdW5jdGlvbi4gU2V0IGFnZW50 X2lkIHBhcmFtZXRlciBhcyBvcHRpb25hbA0KaW4gc2NtaS1zZWNvbmRhcnktYWdlbnRzIGRldmlj ZS10cmVlIHByb3BlcnR5DQotIGludHJvZHVjZSAiI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxs cyIgcGFyYW1ldGVyIHRvIHNldCBpZg0KYWdlbnRfaWQgd2FzIHByb3ZpZGVkDQotIHJlYW5tZSB4 ZW4sc2NtaS1zZWNvbmRhcnktYWdlbnRzIHByb3BlcnR5IHRvIHNjbWktc2Vjb25kYXJ5LWFnZW50 cw0KLSBtb3ZlIG1lbWNwdV90b2lvL2Zyb21pbyBmb3IgdGhlIGdlbmVyaWMgcGxhY2UNCi0gdXBk YXRlIFhlbiB0byBnZXQgbWFuYWdlbWVudCBjaGFubmVsIGZyb20gL2Nob3Nlbi94ZW4sY29uZmln IG5vZGUNCi0gZ2V0IGh5cGVydmlzb3IgY2hhbm5uZWwgZnJvbSBub2RlIGluc3RlYWQgb2YgdXNp bmcgaGFyZGNvZGVkDQotIHVwZGF0ZSBoYW5kbGluZyBzY21pIGFuZCBzaG1lbSBub2RlcyBmb3Ig dGhlIGRvbWFpbg0KLSBTZXQgbXVsdGktYWdlbnQgZHJpdmVyIHRvIHN1cHBvcnQgb25seSBBcm02 NA0KLSByZXdvcmsgbXVsdGktYWdlbnQgZHJpdmVyIHRvIGxlYXZlIEhvc3QgRGV2aWNlLXRyZWUg dW5tb2RpZmllZA0KDQpDaGFuZ2VzIGluIHY0Og0KLSB0b29sc3RhY2sgY29tbWVudHMgZnJvbSBB bnRob255IFBFUkFSRA0KLSBhZGRlZCBkb20wbGVzcyBzdXBwb3J0DQotIGFkZGVkIGRvYyBmb3Ig InhlbixzY21pLXNlY29uZGFyeS1hZ2VudHMiDQoNCkdyeWdvcmlpIFN0cmFzaGtvICgyKToNCiAg eGVuL2RvbWN0bDogY2hhaW4gU0NJIGhhbmRsaW5nIGJlZm9yZSBJT01NVSBpbiBhc3NpZ25fZGV2 aWNlIGRvbWN0bA0KICBkb2NzOiBhcm06IGFkZCBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJp dmVyIGRvY3MNCg0KT2xla3NpaSBNb2lzaWVpZXYgKDMpOg0KICB4ZW46IGFybTogc21jY2M6IGFk ZCBJTlZBTElEX1BBUkFNRVRFUiBlcnJvciBjb2RlDQogIGxpYi9hcm06IEFkZCBJL08gbWVtb3J5 IGNvcHkgaGVscGVycw0KICB4ZW4vYXJtOiBzY21pOiBpbnRyb2R1Y2UgU0NJIFNDTUkgU01DIG11 bHRpLWFnZW50IGRyaXZlcg0KDQogTUFJTlRBSU5FUlMgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICA0ICsNCiBTVVBQT1JULm1kICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgMTEgKw0KIC4uLi9hcm0vZmlybXdhcmUvYXJtLXNjbWkucnN0ICAgICAgICAg ICAgICAgICB8IDQyMCArKysrKysrKysNCiBkb2NzL21hbi94bC5jZmcuNS5wb2QuaW4gICAgICAg ICAgICAgICAgICAgICAgfCAgMTMgKw0KIGRvY3MvbWlzYy9hcm0vZGV2aWNlLXRyZWUvYm9vdGlu Zy50eHQgICAgICAgICB8IDE5NiArKysrKw0KIGRvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBh bmRvYyAgICAgICAgICAgICB8ICAgMiArLQ0KIHRvb2xzL2xpYnMvbGlnaHQvbGlieGxfYXJtLmMg ICAgICAgICAgICAgICAgICB8ICAgNCArDQogdG9vbHMvbGlicy9saWdodC9saWJ4bF90eXBlcy5p ZGwgICAgICAgICAgICAgIHwgICA0ICstDQogdG9vbHMveGwveGxfcGFyc2UuYyAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgIDEyICsNCiB4ZW4vYXJjaC9hcm0vTWFrZWZpbGUgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgIDEgKw0KIHhlbi9hcmNoL2FybS9hcmNoLm1rICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgMSArDQogeGVuL2FyY2gvYXJtL2RvbTBsZXNzLWJ1aWxkLmMgICAg ICAgICAgICAgICAgIHwgIDExICsNCiB4ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMgICAgICAg ICAgICAgICAgICAgfCAgNDEgKy0NCiB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvS2NvbmZpZyAgICAg ICAgICAgICAgICAgfCAgMTIgKw0KIHhlbi9hcmNoL2FybS9maXJtd2FyZS9NYWtlZmlsZSAgICAg ICAgICAgICAgICB8ICAgMSArDQogeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjaS5jICAgICAgICAg ICAgICAgICAgIHwgIDM1ICsNCiB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1wcm90by5oICAg ICAgICAgICAgfCAxNjQgKysrKw0KIHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNobWVtLmMg ICAgICAgICAgICB8IDExNSArKysNCiB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zaG1lbS5o ICAgICAgICAgICAgfCAgNDUgKw0KIHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNtYy1tdWx0 aWFnZW50LmMgICB8IDgxMyArKysrKysrKysrKysrKysrKysNCiB4ZW4vYXJjaC9hcm0vaW5jbHVk ZS9hc20vZmlybXdhcmUvc2NpLmggICAgICAgfCAgMTQgKw0KIHhlbi9hcmNoL2FybS9pbmNsdWRl L2FzbS9zbWNjYy5oICAgICAgICAgICAgICB8ICAgMSArDQogeGVuL2FyY2gvYXJtL2xpYi9NYWtl ZmlsZSAgICAgICAgICAgICAgICAgICAgIHwgICAyICsNCiB4ZW4vYXJjaC9hcm0vbGliL21lbWNw eS1mcm9taW8uYyAgICAgICAgICAgICAgfCAgNDggKysNCiB4ZW4vYXJjaC9hcm0vbGliL21lbWNw eS10b2lvLmMgICAgICAgICAgICAgICAgfCAgNDggKysNCiB4ZW4vY29tbW9uL2RvbWN0bC5jICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgMjYgKy0NCiB4ZW4vZHJpdmVycy9wYXNzdGhyb3Vn aC9kZXZpY2VfdHJlZS5jICAgICAgICAgfCAgIDYgKw0KIHhlbi9pbmNsdWRlL3B1YmxpYy9hcmNo LWFybS5oICAgICAgICAgICAgICAgICB8ICAgMyArDQogeGVuL2luY2x1ZGUveGVuL2xpYi9pby5o ICAgICAgICAgICAgICAgICAgICAgIHwgIDcxICsrDQogMjkgZmlsZXMgY2hhbmdlZCwgMjEyMCBp bnNlcnRpb25zKCspLCA0IGRlbGV0aW9ucygtKQ0KIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vYXJj aC9hcm0vZmlybXdhcmUvc2NtaS1wcm90by5oDQogY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9hcmNo L2FybS9maXJtd2FyZS9zY21pLXNobWVtLmMNCiBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gv YXJtL2Zpcm13YXJlL3NjbWktc2htZW0uaA0KIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vYXJjaC9h cm0vZmlybXdhcmUvc2NtaS1zbWMtbXVsdGlhZ2VudC5jDQogY3JlYXRlIG1vZGUgMTAwNjQ0IHhl bi9hcmNoL2FybS9saWIvTWFrZWZpbGUNCiBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvYXJt L2xpYi9tZW1jcHktZnJvbWlvLmMNCiBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvYXJtL2xp Yi9tZW1jcHktdG9pby5jDQogY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9pbmNsdWRlL3hlbi9saWIv aW8uaA0KDQotLSANCjIuMzQuMQ0K From xen-devel-bounces@lists.xenproject.org Wed Jan 21 18:44:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 18:44:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210164.1521973 (Exim 4.92) (envelope-from ) id 1vidBa-00086f-Fj; Wed, 21 Jan 2026 18:44:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210164.1521973; Wed, 21 Jan 2026 18:44:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vidBa-00086a-Cn; Wed, 21 Jan 2026 18:44:10 +0000 Received: by outflank-mailman (input) for mailman id 1210164; Wed, 21 Jan 2026 18:44: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 1vidBZ-00083G-Ka for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 18:44:09 +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 2b2c8f64-f6f9-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 19:44:08 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by PAVPR03MB8945.eurprd03.prod.outlook.com (2603:10a6:102:322::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 18:43:56 +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.9542.008; Wed, 21 Jan 2026 18:43: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: 2b2c8f64-f6f9-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XP6YubQ4FqRjxZJkDzUVdL9122ldrKbHl52xcVo33VsQuGQDnDBpcdqzs4343zUej1o63BGCnRBQe2TqvXGWlj8cZBA9JzFGRulNtlj0HAjO3oTdZ5+J2kB3SzRhlU1mAw6DLteG5u4QZ7GEMnQFAYg83HVS60/JUZFdEI90dGlYqCxYHz2rCKzMIp/vxk8WswNKWhQIqre/bT9A8Q/KEY4eey7O4yJk3LduHwgyJMCD4aGq1jTZ04mDgq+KqJvGRENDZCPqlRBLmhnJlAj6wDoJZRfhwpeQGDAYoFGgsIaAAH7asz+uXvM47xmF6zXSG++bGvIneQ2DLLmK7n3otw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7Nk1CN+j4B/Mq/rCvZP0747CGWDJEwdX0Pe1Pu44Qbs=; b=OpIwUcOpc5CUgcjQEtItC+HQdhoKMVDDvUQxnE2ocBsADYn3DCxuJpYbvoi73IimQcxjHiEVd58Ns54eo84cVSitchK1yNUVB7EHC6rKovWnW3GYLjhcsMaqnTbtoeh3xOce4XF3XNDV0emO+HtxNgzH1oeRb/jO241niGoBGleUEj6cPd3LcwVBOAqAGKK1Ohic5qa5+GLtufwOTQuQQ72oayIcmQ0lZAGk66nOWnveGHdEVi2ThKXkG1zvZ/Fa1swwNFUBlD5/00TGK/9eyCf6OD96cuTy4IqWn32DIPwK9/qKKSpXJbbSOp9jPAlIVEsrofG63NbQWtfk04qqVA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7Nk1CN+j4B/Mq/rCvZP0747CGWDJEwdX0Pe1Pu44Qbs=; b=uemVPyneA0ye0XhCsRn/KNp6Yeq5/rntat7Msjiv6tEvcLVj2IIE19u+c1MLbUS/OUNrXYByz4UBvfujvcJXCaHsRIz+tBejSgvCxGzx90CgdFaUeQqT0Ob+56+nLHDTsCVNCnwU4O36k/sFy+IhUBLkzAihB3CjvMZSuZ7awHZoNqaJwCYqH1+n5XZE0wg4D+/vMdWymKzZfAe6tjY1PhUGo20SjzjSF0HgjGrFvKVNYy4+sN9/iL8Banc9CAwDil+tInNO8ctAu4xoDTSE4/ZoCMoLy1nvFsHdKAwi/ohS8vO+S/367u+RhgOg1rzuPf4v6uKVNDTRqrNH/lOEQA== 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/5] xen: arm: smccc: add INVALID_PARAMETER error code Thread-Topic: [PATCH v8 2/5] xen: arm: smccc: add INVALID_PARAMETER error code Thread-Index: AQHciwXkoCbVDuwd90KU3/bSFw0oPg== Date: Wed, 21 Jan 2026 18:43:54 +0000 Message-ID: <8b964d9b6a50053d8a2e485a672b0fd3bc2e0c7c.1769020872.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_|PAVPR03MB8945:EE_ x-ms-office365-filtering-correlation-id: 2f37e1db-2e67-4122-d414-08de591d077a 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?c7cQ5AKRjUAWwniKXPiW4OcfEARbbNmeGrjoPPsGTlK6az7hpd0Ru03oRp?= =?iso-8859-1?Q?jovYpNJj2vipQuVOkvjW/Gnqhn7pjkMEw1SD/spWdoPM7fvuRf7vNQ9HdJ?= =?iso-8859-1?Q?BsObRd4hh9sikZBLvDEdcoycV0aM4kK/Ww6ojKki7Pf2O9MOXsP3xuOa5s?= =?iso-8859-1?Q?SgOBwCDrH9gWe4vxYub3TtNro3vgLn8GHQSIbDnkp+kRy+nYUqVIZL2o0i?= =?iso-8859-1?Q?deseXg1DmmH7dhKEfZnNGwV1rUHIeGyRu+Y5nW1ZUjlmb+GSOj8l8J7WbE?= =?iso-8859-1?Q?Dhr6uE/0G9FjsqdNFwVOGsugLmsaPvE+TEOs2dnFboH1rqY6maf1aGgxA0?= =?iso-8859-1?Q?gLyDkuftga4EgWnShgV84/sSPv5zJqV1JEUl1iKycG952sYzwjDkoHMkMO?= =?iso-8859-1?Q?eDhcgV7pcTs1NoFYb/kAD5Nq2g9/wlGFwxMJJj7ak85xlKgu+Z5oCIRcAU?= =?iso-8859-1?Q?s7l4SSa6R+OYGEUVT9bYtcRXRy/BMkcPyGyP7WJEttaITZmCVKGlmmrr19?= =?iso-8859-1?Q?OD1GtYNcdMUHv3FWIlT6UHX4ahsEjGnES30J+kWKKxkaU7dGM3DAkW705b?= =?iso-8859-1?Q?+7Zpzjyyp1f7O7Lme9tnL6YKkTRfVGkzOjsOIcbjrUR+n7tJmHTL4UQu6K?= =?iso-8859-1?Q?LJCOQNS1whWqoARfUKV62MNqd/8oH2ldCnFCJpcm/7B9Wr3pG5KMeneuyX?= =?iso-8859-1?Q?L93LzT1c6pDXe3cJmqilIMfd/eGX2qREaI2cn9IHqqll1hOXWcGCKV8jUY?= =?iso-8859-1?Q?hAznfyLYg/vnbvNnlpb1ux0osLz/RVZzoPWWkwl2TRsQIO3BjfPEqHvkTn?= =?iso-8859-1?Q?/SZjWQ9Aaqwd1ybrOAK0AlY+bqLp6ATqD/Vihr4QAw/6xT75eOSwqYfIGj?= =?iso-8859-1?Q?gnbmoZjdzvNwGiMMmh3s+LLWcbDCcqcGjJZ8RlKTdDJUD3FAZY91AUJQCY?= =?iso-8859-1?Q?yQfWCkTYR/9jZOdLdUgz32OYzinmJ2DxwkF/lctgn/hZwykT6ikiEkG8Wy?= =?iso-8859-1?Q?u8FUr8cpB8WzClO4uUAkMstLpatOWiE0ktmqawN/6gq3OwpAYjiZNFy7a0?= =?iso-8859-1?Q?+LPMCo10s5CzBsz5xQA11ICU2RquMq1cY3Y4fL8QSfQfrhr3Q1emDZf6v9?= =?iso-8859-1?Q?b1Pyc+wdZuJUQa8SS0r/Ia9N7H6gKFghBXizF1evQr5y+xdJB71f4JLOGV?= =?iso-8859-1?Q?bwc4iVSgTjywSdNx6HizLUAynwe2OZH4tuJIuFK0AtJHE+7qStLTFOfGpg?= =?iso-8859-1?Q?VEfeOwQtgJ4hGrovntnUEQhi6ofKgL2J+m55NJQFA6p4D2f3Xu73G5gLev?= =?iso-8859-1?Q?Oyc1ntEsOw6LEOsVDkr/bb91u4h9t1HP4DDOac6gM+YdKlyncr+hLXgJZx?= =?iso-8859-1?Q?ftobtC7m7euLuIGeJGVT09UXaQe7xTFHc6K6zh2AMj1maLEX9SXLCrhdMT?= =?iso-8859-1?Q?sAZFs/x+th8Avkf0EnAZJsfZdTME2W2W0nq+3vsCFBTgTJpU8NAEMEDOzz?= =?iso-8859-1?Q?qL57YyPchz2ro4aFhV382Zr8PSSTZ+Ozc9Y/1gkH43VZjozhcto6FZpiCK?= =?iso-8859-1?Q?5ATYYT1x089jK+u9NadOB8B4gjQwWO6Lag3lSQKoEHTP95uyA6KIe+9i92?= =?iso-8859-1?Q?oEzrTyIkSWHLQI/2r8mNVTmWltqoDsrre86rA0GPWCEzyzPT1uUDcUc2jm?= =?iso-8859-1?Q?1PwxWpC2pghBD5sg+jA=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)(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?jvSNFgD2SIJBrpfxzFJWqwMgyw1UijiwNi3Ccwn+kOsnjf6MjndT8kbU1e?= =?iso-8859-1?Q?H72gPJZRADd+AtBQ0urDm/WpFtgDRcxx7fIrkryNTfLr4elfkfpBY0cyyB?= =?iso-8859-1?Q?KOH0//wjHnZ4N+bmvQIIkv0BlsIGytMystcNj7Pq0tlstmbbR0lomPiebR?= =?iso-8859-1?Q?PWqaFX1H5EMMGiYe3k9H0hRDqkEGhNEXD9e4QGd/TQCQ1fwbXxja87hAkh?= =?iso-8859-1?Q?ttX0zJtwnqahwRigBeRON8Hor2albtILmnOlUWs171PXdF5IkvUqwHWe65?= =?iso-8859-1?Q?XHEG6ttdXD0w2q3INdr2eqFzkkPvt82MQZyLLyWkiDDX/TaLGidMY8y5QW?= =?iso-8859-1?Q?2R3VYmuF4d90eqG74u+8yuajmnkKOJCMF9ioHGvL9VhXgJJt0zAQFfUOB3?= =?iso-8859-1?Q?w6d+ipQ8qzFSRq+fuBIRTUQWH6J20bU7uQyi0+mHTxhiW2eH8HB1vDJK1U?= =?iso-8859-1?Q?S9B0Z+AVJcr/qCtsGF9byQUby2+47dKpLx8g4GdxIajzMxdB6z2vV5p/tQ?= =?iso-8859-1?Q?zsnqXzH3zHHjJH3rjwNz7qAw62/11hIe3Qp3J0AbUNXwoMgmX2H5xpX2TG?= =?iso-8859-1?Q?N0THfplGruMLO5hwTl8DTV2OTIakEnxY32wk47uYFWCJxkqxuvbYgxqljM?= =?iso-8859-1?Q?YgS3mUEe5I7n8sggebNvkiXkPHrUvCQ36vxsAIYfgoC+2NbFtEONa7C9jf?= =?iso-8859-1?Q?bDTP5RjnXH13/Jaut2NrcZpJZKVyIS0eNbjAMynwj1fyqalZ7NadgceL0M?= =?iso-8859-1?Q?x/Ko4LRs1Dq43fxpoODmYU04yAIDHiI1ev+7lskc/X/oBBKoskyDfgSlu3?= =?iso-8859-1?Q?cYsenIEs4pCssWHCYaDdWgdKwtutIiq/qq1UrgVYQjy7CrNUNQFAOD2EDc?= =?iso-8859-1?Q?1uYDQD0kLh0TG9Dr0lnILCP98aXAcwZkzUM9ru065ZFyGt6Gcea8XwmSEq?= =?iso-8859-1?Q?JR2PWHvOTTsDyHWEvLiWNPTI879GygITFEvqIrml8iEEqJZpiqz4GF8Jkw?= =?iso-8859-1?Q?+5OEtDn8pHNSSAxlknL6lwiGkajKRE29XeGg0H2pX34tOmK3ZQtX8DUS5t?= =?iso-8859-1?Q?jw4HohM9yywfR8j28kEqhAeY+/XmQDWjHYDlZP8Oiu3NVeYe8Bhp8nP+df?= =?iso-8859-1?Q?kWRFuekyZpryecdDHGgulnPDoOwVIHxOIwJcK4VuW2QLSHvierr2nd8nOG?= =?iso-8859-1?Q?Kf0P1SMOKZ37A8nsynFaplT11g3Me7g5QhcFD2euBpgoQyhNVd9nLlIwWw?= =?iso-8859-1?Q?qGvYaRdkm4+R2GhS8E/LrTAscMBdUe/WqwxTzfNmNlKu0M69Y7XDWxyN+N?= =?iso-8859-1?Q?WPDBCP+2EASRdgTcEq6huwDjD1ilgYvW2Ru7MeExzuy8opqTxcuXb+oquo?= =?iso-8859-1?Q?3klIZWjfkiwSxOPkbfUNjD6rnKn5iqRArPUBwf7uKc3DvaSQEn3l0ZCGa8?= =?iso-8859-1?Q?pPdehUUlS3kg/omfEqB9kvOMyYtnpaW4x+HfGUfe8NGlr+aKiv3jZm5SVz?= =?iso-8859-1?Q?17O6GGKA0bVKdOf7Q4rtCy//2ZpO9HJRlUq8QEBA4/dQPJqk29aFj3MRO+?= =?iso-8859-1?Q?tXpBmpU9Qsoxufjsnv+vw/pNCpscvo7SAAHvQUSUZLZdl3xrOyNliXrQ1C?= =?iso-8859-1?Q?5sgi8BAJx8+x4s4MIJ1MAc/vlV81khLIDHZCsvt/Ao8wFYMbFlrvO1+cSZ?= =?iso-8859-1?Q?wQqZ8nzbgq4P9suKkks63T7FzRnThSUUq8wC2EJG5yVuwaPQmrj5iwmGiG?= =?iso-8859-1?Q?JCcGpn8YF7EImh/ROlmEiepQB+oqyZLTyfDXCQYURhoKcglYTjEMZRFCJQ?= =?iso-8859-1?Q?l3E1MD8m9QjLpHmAaWaaOEgtoD1WU5I=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: 2f37e1db-2e67-4122-d414-08de591d077a X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2026 18:43:54.7007 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xKxNBv+04QIbHYHkFpG3lrHLdOD4wGOpPOshn/3Dd1lq9KFDry1QchT/HONLjr7Frls1jIy7emgMw4QO0SgUwTQaTQ92D/CudHFfUQfzRPU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB8945 According to the "7.1 Return Codes" section of DEN0028 [1] INVALID_PARAMETER code (-3) is returned when one of the call parameters has a non-supported value. Adding this error code to the common smccc header file. [1]: https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6 Signed-off-by: Oleksii Moisieiev --- xen/arch/arm/include/asm/smccc.h | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/sm= ccc.h index 441b3ab65d..478444fb09 100644 --- a/xen/arch/arm/include/asm/smccc.h +++ b/xen/arch/arm/include/asm/smccc.h @@ -381,6 +381,7 @@ void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs = *args, 0x3FFF) =20 /* SMCCC error codes */ +#define ARM_SMCCC_INVALID_PARAMETER (-3) #define ARM_SMCCC_NOT_REQUIRED (-2) #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION (-1) #define ARM_SMCCC_NOT_SUPPORTED (-1) --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Jan 21 18:44:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 18:44:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210163.1521967 (Exim 4.92) (envelope-from ) id 1vidBa-00083Y-8A; Wed, 21 Jan 2026 18:44:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210163.1521967; Wed, 21 Jan 2026 18:44:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vidBa-00083R-5J; Wed, 21 Jan 2026 18:44:10 +0000 Received: by outflank-mailman (input) for mailman id 1210163; Wed, 21 Jan 2026 18:44: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 1vidBZ-00083G-1q for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 18:44:09 +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 29bb788b-f6f9-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 19:44:05 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by PAVPR03MB8945.eurprd03.prod.outlook.com (2603:10a6:102:322::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 18:43:57 +0000 Received: from PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc%5]) with mapi id 15.20.9542.008; Wed, 21 Jan 2026 18:43: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: 29bb788b-f6f9-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XN3bII5KRrKprbZcdO96keIyguuSczTRGUqeNGkt3fV3gC3DQVQtKpROWFBnAgtD0l3A5BztITaLzJbhg6kyI+L99SlvMNWMpYvF70+1+DXlHw+alRdxvDvky/i9zM7Bc5fRCRIQsK7w9CMuEhS0+Pk/OtS+M/o4/u2s94FYZFaA1Wp2nfUjvadQEUNsjnjeRGIIe0pMR9R+ggWUQ/vjU8knn+nfSmWxWhJQ2PGlQu/75Lj09dNSRYbie5TxyTK6j/Hudd4+d8PLU71UhfBJFooorpCsCnilNH0W+J/Q67fTFGEniSLLK96Uz/TUFucdGS1j952ZJ48Y7d6HwpWIpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lgFnC943YKWfNBpj2PlihUbnDFNiYD7hP1fbiPXbYg0=; b=T3ILay8laRxweTJ9KWsMA1y3qP8iZMk6b0AAmDf12oJdP719ZVbHqNJYi6rUbc9ui4rifVo29AwI2h2GNAWEvICWGaPkePjacaDIR9Ai5QCoaA6YfGPx584+Z5C6TBtVrbooZ1/9quDBweaS+2idCQoqeWduFo0fjLXTiYTtiyy0biUsuW48KqnGdOvjBGlR2IfBJ1R3hPdaZoEhKSNLydstj1smKGZCdrLRp4kwku5ltg5myiWQUvnLskuf4CLwp3qMSM7xFrbMTG82PxTy6b/d9+zslpz9Vvb4rkn2zRrWknMyvxsnntrdkqD2IKJd7wTmhvFdOWJqJ7SYQ+qSQA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lgFnC943YKWfNBpj2PlihUbnDFNiYD7hP1fbiPXbYg0=; b=lyQhC9ptIvtIFeagZ9/rSkl4JTUB77OEX9NNcl3oxV8Cnvm8ioNO28GQ/CJOyK0WJQD+55D4ekZQhOiRcERRh7W+/8FU3bcCjC5lFqwTfryNk6dEnsOUd+woCYfuKeDAAjlOQXaIYZyEdUUyNhE2ZY3DyeLhIa6up+rAJ7VnYLiATIZhKoS3cK7d15F1Dccylr9+EUVC3BQzXNMnkwaWxA2TZrBSepfXGtDVvKSc6w2oXM1Vuj/VCWu93vw7Y88Ngy216px6r6/qkh+q01kJsg/EhgpI+fK8ADG9707Fl6rQUQqou6d9k5+C6tRR43tlO5Q7ZMamZtaLrTaQYeCedg== 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/5] lib/arm: Add I/O memory copy helpers Thread-Topic: [PATCH v8 3/5] lib/arm: Add I/O memory copy helpers Thread-Index: AQHciwXl2jVTGILzyE6wM0DfzctyvA== Date: Wed, 21 Jan 2026 18:43:55 +0000 Message-ID: <07fded74c7bc375a4e77596866072b65a546f8e6.1769020872.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_|PAVPR03MB8945:EE_ x-ms-office365-filtering-correlation-id: 42d3c5c3-9da1-474e-1fad-08de591d08d9 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?nEMRlWtfYkqnh960u5F4I4D8NCtVaEUmTYCllL7yI9h/yf1UW3C79AWujv?= =?iso-8859-1?Q?+R1+3ba3a+jdvNaLHT843fEb6fDM0snGw1IZM/0ToBU0tLsIzqrSF5oVV5?= =?iso-8859-1?Q?L3aSpfxYLrxbhXTxFGRKSAHa1vKKhOob/DFcjyvPLGILCXErSQ0WCXrQEH?= =?iso-8859-1?Q?2u7tw/FIQ5pOefICzZlSdIHwkO+kw3lMvj5Sz3pYPrplniR4UsREU8KALZ?= =?iso-8859-1?Q?gZiKHNTNNXyIxDirprEzWoATnum39P45MMdNgjx5hQPw77yS/Z4IQcs3Vv?= =?iso-8859-1?Q?WQFKB5aCiTjNI+aLlaEswOOs7Qg3zJpZM/0OU2PUcTb8MwKD2/bH82VOlK?= =?iso-8859-1?Q?JEp44zKbYMOu7hKT+obafLF8VVB0DlMjwQ5/WY9g1bDcr1sXlkdXC3r7y0?= =?iso-8859-1?Q?IORxY30pf0D7iYT9WMkNGMRcZ7BKOCH2QjdA45QLsI5Z/OdXoeBctVee5T?= =?iso-8859-1?Q?IUXKUS7nUelXdQnPMiXvXQBATF5FW1/8aJcqr7SzVMKN+MoYaOshh/smm3?= =?iso-8859-1?Q?Va6pkQxU1+mG/dl6YrxboZwBL5PKRZpBQX/sohrZAQsMP+vBsx+DkpwG2J?= =?iso-8859-1?Q?YNP71mSti84aPnvXb2zcp1g/6rygi2Z5Ieg/c+bisbLJ7eTxTMz3+55Ydc?= =?iso-8859-1?Q?FLo/RC8JzuMFr8hTycTHFylbOX2ZBF0x58maNf5z+KYqo9BVpns7YvVYwx?= =?iso-8859-1?Q?dARmXoUzEAa43pt97P4RxodIx5zy29HlIUnsTvac5Rdr6TWq+WWnEifqkl?= =?iso-8859-1?Q?uDLpfvKK6ms/BuWyG9tCj879qfXyMn2NjxqxJIvBlbLXwds5dJ9z7PJiOV?= =?iso-8859-1?Q?MGpTHFdZ8BnFHTSsw10zm83+GZScLkxVhRXmj+f4irkEcTjGancgWFty9m?= =?iso-8859-1?Q?tC+1vfa9IWmiDUaxyP5aZgi9+9U+Iy0uBWbFNU3jLXBJJc2GI+Ou5+snrN?= =?iso-8859-1?Q?GjCJQAmxN6AUBLQMmx0x7bRmFo+iJBsc5qhinWlOG+i4Wj8e9SWpuavAXb?= =?iso-8859-1?Q?42ESIMwaJtAvc0CZvq5od57vTpRe/duHr9QwNhwwk/V4CvPEAT60Asr/4i?= =?iso-8859-1?Q?BVnRBW0qRTGKg0X8YYWyELVOvlSFn929nYwgndTTHsIXTEDsbXjfOS4clE?= =?iso-8859-1?Q?/6sVglVypCLOt56/YabXSwHdFWNOV2DFy68twf5dbIIVqlT6AmaHqIA7N8?= =?iso-8859-1?Q?peOpfvkI2z1HbeUIASFRm3zTWIMTfNbOC3UYbpNlUF3lRasBAMib/hEw9S?= =?iso-8859-1?Q?uIwt1kXho/tvUpah8VhCFntdifkAz/oWePsSmsoXhOgktaBHy6IXYdsoIo?= =?iso-8859-1?Q?7eEnTdrtSbPJUu3h019CybPDTF26qazYEqEQLmTJoJkWN5WMZjac+6HAa5?= =?iso-8859-1?Q?Fd/GYSI/uOYMEDhcjtju3REyCnQUVr0Ofd5LqJ6kfOIBbydrXppyw+DQ60?= =?iso-8859-1?Q?QTI28JDYNbf9YWjZ6wuAqC6Io6v/p7APFvTVaEkvMf5gz5KKyXUrrjZdiV?= =?iso-8859-1?Q?B6b/5dGLbgL5euc9Y5lfe4FCNP+5obKUoJHwRGhBBtxROcvBcogAD9IbuU?= =?iso-8859-1?Q?0urgzxzipZIkNepVzsSXnoDQybnOZRojB0grfs1xlSzrBw70cCXmjwj2YT?= =?iso-8859-1?Q?49+cOk5ocLNL7H7pbODzrGfRk87sytTkxaTBGDG8RIgxSlhANiBiIUgDzT?= =?iso-8859-1?Q?XagD7n0vGXayG+u/cvo=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)(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?tFQ3FhNGapOUWjksGoJo/TQjfOaPWaatW/GCW0YT5uZ7KaHXQMbgqZdjbk?= =?iso-8859-1?Q?XkV++Frh0aKZMRrHddZPrUWlRI6tfR8d9pNPMdNLvigh7Z+wH7rAVssFPk?= =?iso-8859-1?Q?4upHw5sg6ZF6G+/dZ3dGrSceR8iqo6lAk0VuJgQhb1AYnR5RliA1auySq+?= =?iso-8859-1?Q?+lq/wAF83YfysxCStyrXIEtgsXYzOVXoCFtnr780xzCJKBlIGQFhAbkp9z?= =?iso-8859-1?Q?s4zyOu0GdzXM39h73dM/DhehpDqO0J5U1olqsPYxSOfxe+Ok+UVbe36Q5z?= =?iso-8859-1?Q?6iRkc9/4fseys3dfWOZdofFSIdjl7a7FGJDKWv21u/JCmd+A6HiF71vhTQ?= =?iso-8859-1?Q?wRO2+jEhO+e4N/Cf+H8S/QHXQWd3xvSuputon5i2hCFY2EDOlpsJPExdJ3?= =?iso-8859-1?Q?uFjCLrq/nlxZ+ZyrNyu9DKobKIpVhwcreCn+qT4tiqhekKNlMI9SRYN2Vv?= =?iso-8859-1?Q?qS0kT5kj9GkboeKJi+vCP4k9Yz/evSDocUxQAoTYX/xu2fFcnXONN+D/Q6?= =?iso-8859-1?Q?NmzWc4Ijk2ajpI8fY2+s23pXrxxMtjGf00URnW4x6QTcrxWMvItdntBM03?= =?iso-8859-1?Q?lHvWZW7WzFDA+sr3lie7jzRp1aXqoDPnjFhqs+XQjD4VhRQY4s5AdEqPzK?= =?iso-8859-1?Q?H7MCLgUZMDOWfDl1Wh7/t1nTxcH1/c4yq4qdAPE9mFdSPnTWQhMOLJIPhP?= =?iso-8859-1?Q?qC2NZXfsZR8NXnZ2TdOvQee5X7nUMjHvpJSFGkaNL3Gb+M04/nPfCW+T0+?= =?iso-8859-1?Q?DyA4V9gq1htrjaD4Eyys4OlQZCLb/qO/BTXEePwkSDR5BBlVbSVTSNlCbA?= =?iso-8859-1?Q?0eQ8Vg7Ur4gnWJFU5431k+0/HXld//Un9d6o8IWQj1HavgBfWNdVTsrk2m?= =?iso-8859-1?Q?Ml9Ef0Sm1y4ZlT56TBC6yArsc5s8F4it6g4yIAQeO1Ma71bOF6eTS5TUqH?= =?iso-8859-1?Q?86Tq1f3HJw11XWnnFXB182QAZtyEAgA3ofIFrLUIJ4fhmDoczlXfxWSxl8?= =?iso-8859-1?Q?xI7SJ6v2N9NzDh89oufMq/pR3lMBsnQDN9sbXVbkHJU9m2VtH34NUEXtR6?= =?iso-8859-1?Q?rkl28i44h/wKLYFQrQkHDT7ANmeLju2Lh2jxssv043kIy6m29d3perVb3P?= =?iso-8859-1?Q?Ob2ZeSU2edxiTmwdx9SBgY2INJqj+zck9YNBwFC3Xw/os/rm76fTuJk+FB?= =?iso-8859-1?Q?F2PFnzqBUHqJsk6gPL81zFEwxwCc0vO+QijMNDXX/mHRq+mh+8DtMSlGPP?= =?iso-8859-1?Q?Bild0jTi5OGj0RYaZbNGVR0CfT6b4Om+SaKq/MLRWV0UU84e5Yx6QjNik2?= =?iso-8859-1?Q?DRMy6iYyO1cJm9IOf55LJb5ELoZSB5RxiBrq+zxhbYztfsCljdpBFFhYpt?= =?iso-8859-1?Q?itBN15SenW05ZFQOwTm3jW4UvskKI0cBU5qc2HD7OXoozw6Y0W+DPftOAN?= =?iso-8859-1?Q?YYk4wp/diAU58esEpAPqf8SMJwIIOsSKTOm2iGA7tZeIlZU2q8hpx1/eJj?= =?iso-8859-1?Q?MQvsLBB+uU/GDxt2hKXdC+v2mrRPeoGui/ykvjciY0Pj8HFJ8XeozrutDY?= =?iso-8859-1?Q?0qY7aXzbj3gVOCYAPhvRUChTMc3fpd4aRrtWmjxkXhwSemT8pC/ggREHKB?= =?iso-8859-1?Q?0+OkiHgqHllwOoA8rol4WHi1nGscKWfeUf+cv4a4hXotAgxi3h0OaJsjZm?= =?iso-8859-1?Q?O+YUlH7AKyMqdtVRZ8eCVe9gp9YCLe99IgyT3O/50e3ZkN06j1e/NbhRFH?= =?iso-8859-1?Q?kJXyjDhRy9F0upAijQMUIe/Y1tG2VajmUQd1MFkXFdI+1zyEfbF7Y8UMdq?= =?iso-8859-1?Q?LKzt7Lt3fwKXenxb1NPPq/A8iJawMss=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: 42d3c5c3-9da1-474e-1fad-08de591d08d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2026 18:43:55.2048 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CxOB6Y71XWX4tL8JCES9xcOZ7+fTQcuZBxCz1VY1rn0pd1xXnfXEQaulvEsZxEqLub0NssLc4ymzARTsk+SiBztYie9+mBuqtQZAKxu0DmI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB8945 This commit introduces two helper functions, `memcpy-fromio` and `memcpy-toio`, to provide a robust mechanism for copying data between standard memory and memory-mapped I/O (MMIO) space for the ARM architecture. These helpers handle alignment safely by using ordered byte accesses for any leading/trailing unaligned bytes and ordered 32-bit accesses for the aligned bulk transfer. Using the ordered `readb/readl` and `writeb/writel` accessors avoids unintended endianness conversion while respecting device ordering requirements on ARM32/ARM64 hardware that may not support 64-bit MMIO atomically. The interface lives in the generic header so other architectures can provide their own implementations (as macros or functions). The ARM implementation is placed under `arch/arm/lib/` (mirroring the x86 reference layout) and is split into separate compilation units added via the architecture-specific lib Makefile. Signed-off-by: Oleksii Moisieiev --- Changes in v8: - switched to ordered accessors to address the ordering and barrier concerns. - updated the documentation to match the implementation and explicitly state the supported access sizes and granularity. - rename memcpy_* implementation files to memcpu-* to follow naming convension - fix indentation to match Xen style - fix intendation to match Xen style - move memcpy-{from/to}io to more convenient library place Changes in v7: - x86 guidance: removed the speculative note; header now just says each arch supplies its own implementation or macro. - name spacing: dropped the double-underscore; the helpers are now memcpy_fromio / memcpy_toio. The header also explicitly allows an arch to define these as macros before including it. - updated io.c to keep 32-bit transfers safe on arm32 - moved to __raw_read*/__raw_write* accessors to avoid endianness conversio= n. - split the helpers into separate compilation units Changes in v6: - sorted objs in Makefile alhabetically - added newline at the end of Makefile - used uint{N}_t intead of u{N} - add comment about why 32 bit IO operations were used - updated cast opertaions to avoid dropping constness which is wrong - move function definitions to generic place so the could be reused by other arch - add SPDX tag to io.c Changes in v5: - move memcpy_toio/fromio to the generic place xen/arch/arm/Makefile | 1 + xen/arch/arm/arch.mk | 1 + xen/arch/arm/lib/Makefile | 2 + xen/arch/arm/lib/memcpy-fromio.c | 48 +++++++++++++++++++++ xen/arch/arm/lib/memcpy-toio.c | 48 +++++++++++++++++++++ xen/include/xen/lib/io.h | 71 ++++++++++++++++++++++++++++++++ 6 files changed, 171 insertions(+) create mode 100644 xen/arch/arm/lib/Makefile create mode 100644 xen/arch/arm/lib/memcpy-fromio.c create mode 100644 xen/arch/arm/lib/memcpy-toio.c create mode 100644 xen/include/xen/lib/io.h diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile index 7494a0f926..bd8638c8a7 100644 --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -10,6 +10,7 @@ endif obj-y +=3D firmware/ obj-$(CONFIG_TEE) +=3D tee/ obj-$(CONFIG_HAS_VPCI) +=3D vpci.o +obj-y +=3D lib/ =20 obj-$(CONFIG_HAS_ALTERNATIVE) +=3D alternative.o obj-y +=3D cpuerrata.o diff --git a/xen/arch/arm/arch.mk b/xen/arch/arm/arch.mk index dea8dbd18a..0c28dbeb87 100644 --- a/xen/arch/arm/arch.mk +++ b/xen/arch/arm/arch.mk @@ -2,6 +2,7 @@ # arm-specific definitions =20 ARCH_LIBS-y +=3D arch/arm/$(ARCH)/lib/lib.a +ALL_LIBS-y +=3D arch/arm/lib/lib.a =20 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS)) $(call cc-option-add,CFLAGS,CC,-Wnested-externs) diff --git a/xen/arch/arm/lib/Makefile b/xen/arch/arm/lib/Makefile new file mode 100644 index 0000000000..07a0d9186c --- /dev/null +++ b/xen/arch/arm/lib/Makefile @@ -0,0 +1,2 @@ +lib-y +=3D memcpy-fromio.o +lib-y +=3D memcpy-toio.o diff --git a/xen/arch/arm/lib/memcpy-fromio.c b/xen/arch/arm/lib/memcpy-fro= mio.c new file mode 100644 index 0000000000..85377137c3 --- /dev/null +++ b/xen/arch/arm/lib/memcpy-fromio.c @@ -0,0 +1,48 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#include +#include + +/* + * Use ordered 8-bit and 32-bit IO accessors for portability across + * ARM32/ARM64 where 64-bit accesses may not be atomic and some devices + * only support 32-bit aligned accesses. + */ + +void memcpy_fromio(void *to, const volatile void __iomem *from, + size_t count) +{ + while ( count && (!IS_ALIGNED((unsigned long)from, 4) || + !IS_ALIGNED((unsigned long)to, 4)) ) + { + *(uint8_t *)to =3D readb(from); + from++; + to++; + count--; + } + + while ( count >=3D 4 ) + { + *(uint32_t *)to =3D readl(from); + from +=3D 4; + to +=3D 4; + count -=3D 4; + } + + while ( count ) + { + *(uint8_t *)to =3D readb(from); + from++; + to++; + count--; + } +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 8 + * tab-width: 8 + * indent-tabs-mode: t + * End: + */ diff --git a/xen/arch/arm/lib/memcpy-toio.c b/xen/arch/arm/lib/memcpy-toio.= c new file mode 100644 index 0000000000..588497ed0f --- /dev/null +++ b/xen/arch/arm/lib/memcpy-toio.c @@ -0,0 +1,48 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#include +#include + +/* + * Use ordered 8-bit and 32-bit IO accessors for portability across + * ARM32/ARM64 where 64-bit accesses may not be atomic and some devices + * only support 32-bit aligned accesses. + */ + +void memcpy_toio(volatile void __iomem *to, const void *from, + size_t count) +{ + while ( count && (!IS_ALIGNED((unsigned long)to, 4) || + !IS_ALIGNED((unsigned long)from, 4)) ) + { + writeb(*(const uint8_t *)from, to); + from++; + to++; + count--; + } + + while ( count >=3D 4 ) + { + writel(*(const uint32_t *)from, to); + from +=3D 4; + to +=3D 4; + count -=3D 4; + } + + while ( count ) + { + writeb(*(const uint8_t *)from, to); + from++; + to++; + count--; + } +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 8 + * tab-width: 8 + * indent-tabs-mode: t + * End: + */ diff --git a/xen/include/xen/lib/io.h b/xen/include/xen/lib/io.h new file mode 100644 index 0000000000..1c0865401e --- /dev/null +++ b/xen/include/xen/lib/io.h @@ -0,0 +1,71 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Generic I/O memory copy function prototypes. + * + * These functions provide low-level implementation for copying data betwe= en + * regular memory and I/O memory regions. Each architecture must provide i= ts + * own implementation based on the specific requirements of the architectu= re's + * memory model and I/O access patterns. An architecture may supply these = as + * functions or as macros in its own headers before including this file. + * + * Architecture-specific implementations: + * =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 + * Each architecture should implement these functions in xen/lib//io= .c + * (or define them as macros) based on their hardware requirements. See + * xen/lib/arm/io.c for an example using explicit I/O accessors. + */ + +#ifndef _XEN_LIB_IO_H +#define _XEN_LIB_IO_H + +#include + +/* + * memcpy_fromio - Copy data from I/O memory space to regular memory + * @to: Destination buffer in regular memory + * @from: Source address in I/O memory space (must be marked __iomem) + * @count: Number of bytes to copy + * + * This function handles copying from memory-mapped I/O regions using + * architecture-appropriate I/O accessor functions (e.g. readb/readl on Ar= m) + * that already impose the required ordering for device accesses. Typical + * implementations may: + * - Handle leading/trailing unaligned bytes with 8-bit accesses + * - Use the widest safe aligned access size supported by the target (ofte= n + * 32-bit on Arm where 64-bit MMIO may not be atomic) + * - Rely on MMIO accessors to provide the needed barriers + * + * Limitations: + * - Only suitable for devices that tolerate 8-bit and 32-bit accesses; it= is + * not valid for devices that require strictly 16-bit or 64-bit access s= izes. + * - Callers must ensure the target MMIO region is mapped with appropriate + * device attributes. + */ +extern void memcpy_fromio(void *to, const volatile void __iomem *from, + size_t count); + +/* + * memcpy_toio - Copy data from regular memory to I/O memory space + * @to: Destination address in I/O memory space (must be marked __iomem) + * @from: Source buffer in regular memory + * @count: Number of bytes to copy + * + * This function handles copying to memory-mapped I/O regions using + * architecture-appropriate I/O accessor functions (e.g. writeb/writel on = Arm) + * that already impose the required ordering for device accesses. Typical + * implementations may: + * - Handle leading/trailing unaligned bytes with 8-bit accesses + * - Use the widest safe aligned access size supported by the target (ofte= n + * 32-bit on Arm where 64-bit MMIO may not be atomic) + * - Rely on MMIO accessors to provide the needed barriers + * + * Limitations: + * - Only suitable for devices that tolerate 8-bit and 32-bit accesses; it= is + * not valid for devices that require strictly 16-bit or 64-bit access s= izes. + * - Callers must ensure the target MMIO region is mapped with appropriate + * device attributes. + */ +extern void memcpy_toio(volatile void __iomem *to, const void *from, + size_t count); + +#endif /* _XEN_LIB_IO_H */ --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Jan 21 18:44:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 18:44:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210166.1521998 (Exim 4.92) (envelope-from ) id 1vidBf-0000L4-95; Wed, 21 Jan 2026 18:44:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210166.1521998; Wed, 21 Jan 2026 18: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 1vidBf-0000Kw-5d; Wed, 21 Jan 2026 18:44:15 +0000 Received: by outflank-mailman (input) for mailman id 1210166; Wed, 21 Jan 2026 18:44: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 1vidBd-00083G-Mf for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 18:44: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 2d3c95db-f6f9-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 19:44:11 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by PAVPR03MB8945.eurprd03.prod.outlook.com (2603:10a6:102:322::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 18:43: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%5]) with mapi id 15.20.9542.008; Wed, 21 Jan 2026 18:43: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: 2d3c95db-f6f9-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=YG80mM+Mdv8mUw4nz956SA4aFCOSzKSa7DPYjCECZYlMjsnmANghzEtDllhVTF6XVCVta5BTAKB8gFffKlLLGkwQb4Wsb9EAMg746TA18YurxC/MsWl8cAbG507bbDOT54qqgvKvZmrJIw0BmRunWzXBuhMTW1GNzUFUaPbY0P1M0ktgPPw2q6h6jgQvDvX/y0xBkbOKw0JoMQySzB4UMoIYWhf2kUEM6ligZ3lktwjrXElKzTXonM4afaZHEpby5Vp2BxPynOpoAjO8TcbwAlPlzn7m5sXs5Grvz0xluXVMfDmiHqg8uhBRvwrxw7uNXylOxEuyxXAKmah3mqJb7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0x5Toi5O1tcXhnydAj6PUK5eC3l3b3k896d9Upmr358=; b=YSdpvPtupjM/SpMeZSn1BR57Z+fQQ8x/rLsByeeZ8VmkiZrhsLF7Wi38zt+TGfvI69uzjWWu2sb2/DxuHB1Vu+4MbAmsEZsEYS+O9Ivwcg/FzZj8LDDDmp3obkxPRXOkgxDGQb4G6SLqY7b7Lcjol5ptYviiZumFy9/k/cbXCeubtukTxXeyl2fED3TzAubde3+Mb28448uNL/Pg6WBCJWtoX0uk0fEOW97m1P3avP+goonWmwcdrizA25+bWwkxe7UH+kttCYbDF2/uGVlAB9ht+ZNypz9M2KNGAIQcG7kG51Qw94k0W5bz2tXKq2Pn4IMn8mQiHmDU8MnVcgn+hw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0x5Toi5O1tcXhnydAj6PUK5eC3l3b3k896d9Upmr358=; b=vJhTxr7mEClSahZ6DSHX1Z+IFs85cvyrOo7qgC8jpDgv91L7gowbt2qL7C9diJSL6FpC6z58kJ8XypFESE9U+hyx3zwQMamzSEvrF2vQFMzVmRrNg9TY5elaSp1ABaAVd32u18W1n2DYTookFcJWLLVo//FWNRj048kuB6uOnqHZS5MZf85kxHYz+zltGNwQYIs8CCJbTDVVg5BAeqt8yHCAotWQ31FFYu6SiN3oRyhm59h7nFl+5vYSsU6W7tQXyaCEKb9Pje0HMCFbqE1i2j+lK0JpdF1Z8+41tory2idpHisr4URHytuAjfOei8CyIU5P4Rc2mYcMO8wyYSdJSA== 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 5/5] docs: arm: add SCI SCMI SMC multi-agent driver docs Thread-Topic: [PATCH v8 5/5] docs: arm: add SCI SCMI SMC multi-agent driver docs Thread-Index: AQHciwXlP9Ogh5hL/k+s7e3EDf9c/Q== Date: Wed, 21 Jan 2026 18:43:56 +0000 Message-ID: <18730683fa731383231fbce51dc188a978304ff0.1769020872.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_|PAVPR03MB8945:EE_ x-ms-office365-filtering-correlation-id: 4548fb3a-79ae-473e-d4d0-08de591d09bf 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?y3g/nDJZoD9IdknXshYQ0+/FFw5YmKJXj5uqeqizpYdQpHnGCoa6uP+3nR?= =?iso-8859-1?Q?aVQd+ZUWrkNk8hzZdOg5O3vhsPUC5K/oNbiV4rHlPGS/J4PgAQbma7kqxg?= =?iso-8859-1?Q?Cl7X7+TuVbA7ojWZq+n8mpPbqCRnvwlBKCzg59AOlYMqtYm5+eUh7gJMr2?= =?iso-8859-1?Q?86SdpqSEaYXpTlqYPqP7mZBPx+IJUe5js0MyX0zsCJeFQ65i4ExQuuNpC9?= =?iso-8859-1?Q?vOb5nilw1k7b3HjooMopQQpfyvJeeWkr+cu4VvBwL7QdRKkKcpBIg7eSJG?= =?iso-8859-1?Q?lYWubwFP5/BfTDzfdZA66pEUmmZ1Dp4bdjgWbrUdnZwTCHvhew+dStEO/B?= =?iso-8859-1?Q?RMIqK/XBW+spYeItgDmFG8ionrABzlZornCCEM3TXoAeY4kjVuhg6+e4eh?= =?iso-8859-1?Q?7CqfjmaxoundhKhvgkCssjhfBA4I1L5Bo1h7Bjw/sjCr9AL4nM6frUlFEg?= =?iso-8859-1?Q?GzJTRaqvnzu3cnZQdofQaoW0xqlwDyTN8va0/ReTsNO5L6GO47QsaN3CGB?= =?iso-8859-1?Q?abdvCv+a083JyPnVnfB4iv2qgAOnD5s08TIjYL/5pxYgk4QvZgCETM8xv0?= =?iso-8859-1?Q?sS7UV5tt+RSiCMj14oExYuCzSlMQclmC21cb0LZbHZ0AU/JoCExf4+R7Sb?= =?iso-8859-1?Q?IqEhoLg9KGnPxcZLDVD3QbH58I+Zjq9RRBDSL+AM3c9niRqzF5jJ4yUGAX?= =?iso-8859-1?Q?fpzzt1eYUjuoCocQbOvk5aMdy/Rp52aiZs0NqjDvWS/YGpDa6u+kcUMyAQ?= =?iso-8859-1?Q?O9Hs2bweJ7rjidop7fCkaQDx0mrAdCRimrJsDZevEvS5Am36lfajBEpyhB?= =?iso-8859-1?Q?fOj1RC0P6qKW7l6eq1Ih1q/Wkh7Zuv8qsWZ3jp0t6S9xVfWM5GfH36wGKu?= =?iso-8859-1?Q?dkWXzZbmy7OkVekWRM7gLYsGirDMxzJMUGyJiGH40RDxv0vZ5M3MySw+OM?= =?iso-8859-1?Q?HRbmezsuZmlGXKWTl9w+0fWfzzNnJeWpB7IGqYxqLO5iJn8ZsWhEfyO9ld?= =?iso-8859-1?Q?wRR47nfhmOeZ7DCt/3XcnH0m6kRzAl7NA0kTG7vzF1ZppoSyiNMFTMBwVF?= =?iso-8859-1?Q?Yf4NKxoeyna8mJZRfic3mpy7xfIyrc1d13foAKcLJ6KR0XAvX4djMU2vlr?= =?iso-8859-1?Q?OliJfDL2yXz6Qdmjcw758DK+VW1Hm06LY9DfVhRyeKQpXC1zrEKZmHSYO5?= =?iso-8859-1?Q?uxN69yKCH5MNexHmXKqbsp9Zh5H/BvIPnfmwgfzkCPOR1AMSpuhhFC9YfR?= =?iso-8859-1?Q?RlIpbkRrW8a58XttxPpG1L5GrlQ+GmiQTCRpuzb2wYhMv8QLiJ9Q9ha+WT?= =?iso-8859-1?Q?+cslwFPJckBzCB13QjWD6NjIbz3efowquVunjW1JyCL+Iuo64wbUGNh8oM?= =?iso-8859-1?Q?xnqUOHdg86jxDl+Pjxgu2hCVDXnNTVJcnC2hZ56lVMyd4HgKJG1WCZ9PxC?= =?iso-8859-1?Q?ayCLTzkBTHfbCEgbR2lmLuGUGKMYe7AftFzd0tzr1WgNlQjrKfiYdfnr+p?= =?iso-8859-1?Q?DdSCwCp9Gya94Z6d7AQ3loctT5PGW1rqnqFpbiE57Pi8vTobClFmOXN5Nw?= =?iso-8859-1?Q?qWfpqUSgoQLF8BK+N/lXuJdPERSn+Ag/d65OjucGLM5ylYKV9Rn+AReTAX?= =?iso-8859-1?Q?MtaklvRogQCn4kr1nlN6h0zIhQYNlaelQ23hiospxepY6berVNpPkTbyDn?= =?iso-8859-1?Q?jdKv1huBRVUsQw1LZpA=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)(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?OESh/f+GGfO/9CzjGkHGoN1x71px/T2qqpFn2ZPPZaO3NxkdgC5cptI5+B?= =?iso-8859-1?Q?fYa9wwb4K9ZrzPkcvha9srTTkmpT4aU17Dh9stjrt+vKbXC/MmE8VkDSr6?= =?iso-8859-1?Q?IGalMSsaa4Vm4NJbmN37y/zr5a0FqbLgdCgkvKyRXRUupQ//3cJChGUVzF?= =?iso-8859-1?Q?SCu7UiJRIdzF8Aa4L3/S1cS6ud3hlVktgd909AaLBy7/khw84lSWuQcdf1?= =?iso-8859-1?Q?S6RmkWM7SazzxsLA0U3WYMMePdyEIyqLMqSZp+D0LkrzllCaY/ExlK8EAJ?= =?iso-8859-1?Q?GfTjP+99/ck4OYaYHaLPK1s0bNDL+seX3h1Bu6NHv1PVeDsQ9k13hSfVyQ?= =?iso-8859-1?Q?AFrsLXmSFQxFqzj9MExDA/q0G69M4wJPNACWh2otdfOiFcpOrD1vgnY5Xm?= =?iso-8859-1?Q?KmGJD7J/y3UK0BhkfX8BECAgcOMV4u17rja/gZw9wbR1Sxe+CoRegM5Uag?= =?iso-8859-1?Q?OsFNEsn6Z/trdJE2DXCLW4ojWbhqeYcLLCslKZv/QNFFxZOhHeZ07YFxzt?= =?iso-8859-1?Q?EvThN1G2mTnd6pqSQqyaPGRHP6CUCeAC18/Xmysq/Z+BkZPNnIWI+1W7DT?= =?iso-8859-1?Q?jvBwFv2L8OSVHGef/31UeTTptP7z5/LPUzIbnLgkK3opo8A2kMbb5dT4iD?= =?iso-8859-1?Q?iRa6AJDESDsx0e5/0J67nYyo1FRSs51pSQT8YM+jz1IF2gi0eJL65rI22U?= =?iso-8859-1?Q?YQDvX8A69mgF19S7pKstQtDJRypAyfxe4iVO13tEg+kDYHjQ49tFvYgNQA?= =?iso-8859-1?Q?D0AFu3fzsMqYBxF+kR67dtDf0kf6citS8kk9JqfUIBzd/ayMApRaNFHWWe?= =?iso-8859-1?Q?9541vqL6DlqbNX7LR1JsSh60LG3T4UE527CcBRtXwxmHhX1zPM4XINf4Gf?= =?iso-8859-1?Q?7AEoYnWQNBzvQbIbpLs8KgHSE4jNEF0cED+Nq7jFcGgMr87YXTNDEke7wI?= =?iso-8859-1?Q?TwKuG/Q3+mke8faiU/AxAXBUmKj2Oe7aWiEGYudaKmJU72r/RPd6K2jvCQ?= =?iso-8859-1?Q?dPIS1XZ+ixu7JKB4g+ezMjTCqnMc/Gu2FwpvGtyvShPxK412uubcls9XaH?= =?iso-8859-1?Q?k3xGpKZLKCFlND5NxPpaqQy2Auvjr1U/nF3bz2IJ47C/x7q/um1n8D8UDf?= =?iso-8859-1?Q?fJotfGH19MMCzszbNT9+vEdcsBhEPJwkO7FD397M2H4xvtGWuV4v7c0UQi?= =?iso-8859-1?Q?1A0PlTzyXjz2JnwWG021YkkANC8tT9h0vcOib/MkF9DdCboevZEM425O7J?= =?iso-8859-1?Q?WNjJ394hkLSiHm5aOrSAk0GsrWGKPi8SCL4b8zQjDMuRyd3l7loW83blca?= =?iso-8859-1?Q?TcodZsQvS8QXqPz5NjxhaZ5oipYjOsVeAMGxiJHaB9MJiKpbJKxPXm+Fru?= =?iso-8859-1?Q?BwLJOpSj5a5oASW5/ZSbEo6bmhn+wlurLrSDW+7PEbrRRPm2vV7Mc82JYg?= =?iso-8859-1?Q?+IVLepcgSM4HAfpz50WZHXyUPfW6hPSEcqgdfoWJp4GEA+rLbc45pWF3cU?= =?iso-8859-1?Q?XXthsonyY4iS6irPhceHXavyq/9pm5yEMYiBMBXtngYUBsaN+WQCiAD29P?= =?iso-8859-1?Q?PC41y4NXrZUOGzMJ4B5ofPlpMISXVs231QQdJHyA0VJDx6m0E8vIV6S9QT?= =?iso-8859-1?Q?A1bI4Dy7ExKLllPXJum+T7xcmQmmj3K1kpzqdvyXWbTcz8nQvD9P7M+cdE?= =?iso-8859-1?Q?OIDtt4ySgU0aD1PrRNsfb21bJzC+SlWvD1WqEm+nNjOSWEbtlgvjwMFvMV?= =?iso-8859-1?Q?KRpI5/PIGKmAWdRZ5oBjKXOcGLvqQtF6vwZ419N06vo5Jjd8KNFXTdc7pw?= =?iso-8859-1?Q?Yr/hi2YAyktw0jKZEqlgSXK+dQqLlaQ=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: 4548fb3a-79ae-473e-d4d0-08de591d09bf X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2026 18:43:56.3160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1YOPCModIIRfBGlT+9b09ucyVgXLK027+G3zvae6o94Ty0TFC3Mey+sNYeqef9q/xYE8aJE+1wRb1dGPt25TE6HNkogOcc4IvsPayzvAs0w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB8945 From: Grygorii Strashko Add SCI SCMI SMC multi-agent driver documentation. It includes a detailed description of the SCMI multi-agent driver. This document explains the driver's functionality, configuration, and the compilation process. The Xen SCMI multi-agent driver is designed to provide SCMI access to system resources from different domains. Signed-off-by: Grygorii Strashko Signed-off-by: Oleksii Moisieiev --- Changes in v8: - update documentation to match the last DT format - fixed RST: "... code-block:: dts" -> ".. code-block:: dts" - update documentation with dom0less configuration example - update documentation with new param xen,dom0-sci-agent-id instead of the command line parameter Changes in v7: - update documentation in section of the xen_scmi configuration which is matched by "xen,sci" compatible instead of the direct path. Changes in v6: - remove all HVC mentions from the multi-agent doc - update sci-agent-id parameter description in the documentation - add missing Sign-of - minor fixes across the document Changes in v5: - rework multi-agent driver to leave Host Device-tree unmodified .../arm/firmware/arm-scmi.rst | 420 ++++++++++++++++++ 1 file changed, 420 insertions(+) diff --git a/docs/hypervisor-guide/arm/firmware/arm-scmi.rst b/docs/hypervi= sor-guide/arm/firmware/arm-scmi.rst index d9698f4e4b..2497a870f3 100644 --- a/docs/hypervisor-guide/arm/firmware/arm-scmi.rst +++ b/docs/hypervisor-guide/arm/firmware/arm-scmi.rst @@ -36,6 +36,8 @@ The below sections describe SCMI support options availabl= e for Xen. =20 | [1] `Arm SCMI `= _ | [2] `System Control and Management Interface (SCMI) bindings `_ +| [3] `Generic Domain Access Controllers bindings `_ + =20 Simple SCMI over SMC calls forwarding driver (EL3) ------------------------------------------------------ @@ -189,3 +191,421 @@ except explicitly enabling SCMI with "arm_sci" xl.cfg= option. -> xen,reg =3D <0x0 0x47ff0000 0x0 0x1000 0x0 0x22001000>; -> xen,force-assign-without-iommu; }; + +SCMI SMC multi-agent driver (EL3) +------------------------------------- + +The SCMI SMC multi-agent driver enables support for ARM EL3 Trusted Firmwa= re-A (TF-A) which +provides SCMI interface with multi-agent support, as shown below. + +:: + + +-----------------------------------------+ + | | + | EL3 TF-A SCMI | + +-------+--+-------+--+-------+--+-------++ + |shmem1 | |shmem0 | |shmem2 | |shmemX | + +-----+-+ +---+---+ +--+----+ +---+---+ + smc-id1 | | | | + agent1 | | | | + +-----v--------+---------+-----------+----+ + | | | | | + | | | | | + +--------------+---------+-----------+----+ + smc-id0 | smc-id2| smc-idX| + agent0 | agent2 | agentX | + | | | + +----v---+ +--v-----+ +--v-----+ + | | | | | | + | Dom0 | | Dom1 | | DomX | + | | | | | | + | | | | | | + +--------+ +--------+ +--------+ + +The EL3 SCMI multi-agent firmware is expected to provide SCMI SMC shared-m= emory transport +for every Agent in the system. The SCMI Agent transport channel defined by= pair: + +- smc-id: SMC function id used for Doorbell +- shmem: shared memory for messages transfer, **Xen page aligned**. + Shared memory is mapped with the following flags: MT_DEVICE_nGnRE and _P= AGE_DEVICE, indicating that this + memory is mapped as device memory. + +The following SCMI Agents are expected to be defined by SCMI FW to enable = SCMI multi-agent functionality +under Xen: + +- Xen management agent: trusted agents that accesses to the Base Protocol = commands to configure + agent specific permissions +- OSPM VM agents: non-trusted agent, one for each Guest domain which is a= llowed direct HW access. + At least one OSPM VM agent has to be provided by FW if HW is handled onl= y by Dom0 or Driver Domain. + +The EL3 SCMI FW is expected to implement following Base protocol messages: + +- BASE_DISCOVER_AGENT (optional if agent_id was provided) +- BASE_RESET_AGENT_CONFIGURATION (optional) +- BASE_SET_DEVICE_PERMISSIONS (optional) + +The number of supported SCMI agents and their transport specifications are= SCMI FW implementation +specific. + +Compiling with multi-agent support +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To build with the SCMI SMC multi-agent driver support, enable Kconfig opti= on: + +:: + + CONFIG_SCMI_SMC_MA + + +Driver functionality +^^^^^^^^^^^^^^^^^^^^ + +The SCI SCMI SMC multi-agent driver implements following functionality: + +- The driver is initialized from the Xen SCMI container ``xen_scmi_config`= ` + under ``/chosen/xen`` (for example ``/chosen/xen/xen_scmi_config/scmi``)= . + Only one SCMI interface is supported. The SCMI configuration must live u= nder + the Xen SCMI container ``xen,sci`` beneath ``/chosen``. + The Xen SCMI mediator will bind only to the "arm,scmi-smc" node that is = a child of + this "xen,sci" container; any other "arm,scmi-smc" nodes (for example un= der + "/firmware") are ignored to avoid stealing the host's SCMI OSPM instance= . + +.. code-block:: dts + + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; <--- Xen management agent smc-id + #address-cells =3D < 1>; + #size-cells =3D < 0>; + #access-controller-cells =3D < 1>; + shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem + }; + +.. note:: + This layout keeps the Host DT unchanged for Dom0 and baremetal Linux by + using func_id 0x82000002 / shmem 0x47ff0000 for Dom0, while Xen uses a + separate privileged channel func_id 0x82000003 / shmem 0x47ff1000. EL3 + firmware enforces permissions per agent_id, so there is no conflict bet= ween + Dom0 and Xen channels. + +- The driver obtains Xen specific SCMI Agent's configuration from the Host= DT, probes Agents and + builds SCMI Agents list. The Agents configuration is taken from "scmi-se= condary-agents" + property where first item is "arm,smc-id", second - "arm,scmi-shmem" pha= ndle and third is + optional "agent_id": + +.. code-block:: dts + + chosen { + ranges; <--- set default ranges so address can be translated when pa= rsing scmi_shm node + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; <--- set default ranges so address can be translated whe= n parsing scmi_shm node + scmi-secondary-agents =3D < + 0x82000002 &scmi_shm_0 0 + 0x82000004 &scmi_shm_2 2 + 0x82000005 &scmi_shm_3 3 + 0x82000006 &scmi_shm_4 4>; + #scmi-secondary-agents-cells =3D <3>; <--- optional, default 3 + xen,dom0-sci-agent-id =3D <0>; /* Dom0 agent ID */ + + scmi_shm_0 : sram@47ff0000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff0000 0x0 0x1000>; + }; + + scmi_shm_2: sram@47ff2000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff2000 0x0 0x1000>; + }; + scmi_shm_3: sram@47ff3000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff3000 0x0 0x1000>; + }; + scmi_shm_4: sram@47ff4000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff4000 0x0 0x1000>; + }; + + // Xen SCMI management channel + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; <--- Xen management agent smc-i= d + #address-cells =3D < 1>; + #size-cells =3D < 0>; + #access-controller-cells =3D < 1>; + shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem + }; + }; + }; + }; + + /{ + // Host SCMI OSPM channel - provided to the Dom0 as is if SCMI ena= bled for it + scmi_shm: sram@47ff0000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff0000 0x0 0x1000>; + }; + + firmware { + scmi: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000002>; <--- Host OSPM agent smc-id + #address-cells =3D < 1>; + #size-cells =3D < 0>; + shmem =3D <&scmi_shm>; <--- Host OSPM agent shmem + + protocol@X{ + }; + }; + }; + }; + + This approach allows defining multiple SCMI Agents by adding Xen-specifi= c properties under + the ``/chosen`` node to the Host Device Tree, leaving the main part unch= anged. The Host DT + SCMI channel will be passed to Dom0. + + The Xen management agent is described as a ``scmi_xen`` node under the `= `xen,sci`` compatible node, + which is used by Xen to control other SCMI Agents in the system. + + All secondary agents' configurations are provided in the ``scmi-secondar= y-agents`` property with + an optional ``agent_id`` field. + + The ``agent_id`` from the ``scmi-secondary-agents`` property is used to = identify the agent in the + system and can be omitted by setting ``#scmi-secondary-agents-cells =3D = <2>``, so the Secondary + Agents configuration will look like this: + +.. code-block:: dts + + chosen { + xen { + xen_scmi_config { + compatible =3D "xen,sci"; + scmi-secondary-agents =3D < + 0x82000002 &scmi_shm_0 + 0x82000004 &scmi_shm_2 + 0x82000005 &scmi_shm_3 + 0x82000006 &scmi_shm_4>; + #scmi-secondary-agents-cells =3D <2>; + }; + }; + } + + In this case, Xen will use the ``SCMI_BASE_DISCOVER_AGENT`` call to disc= over the ``agent_id`` + for each secondary agent. Providing the ``agent_id`` in the ``scmi-secon= dary-agents`` property + allows skipping the discovery call, which is useful when the secondary a= gent's shared memory is + not accessible by Xen or when boot time is important because it allows s= kipping the agent + discovery procedure. + +.. note:: + + Note that Xen is the only one entry in the system which need to know a= bout SCMI multi-agent support. + +- The driver implements the SCI subsystem interface required for configuri= ng and enabling SCMI + functionality for Dom0/hwdom and Guest domains. To enable SCMI functiona= lity for guest domain + it has to be configured with unique supported SCMI Agent_id and use corr= esponding SCMI SMC + shared-memory transport ``[smc-id, shmem]`` defined for this SCMI Agent_= id. + +- Once Xen domain is configured it can communicate with EL3 SCMI FW: + + - zero-copy, the guest domain puts/gets SCMI message in/from shmem; + - the guest triggers SMC exception with agent "smc-id" (doorbell); + - the Xen driver catches exception, do checks and synchronously forwards= it to EL3 FW. + +- the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen manag= ement agent channel on + domain destroy event. This allows to reset resources used by domain and = so implement use-case + like domain reboot. + + +Configure SCMI for Dom0 +^^^^^^^^^^^^^^^^^^^^^^^ +Set the Dom0 SCMI agent ID in the device tree using the Xen SCMI container= under ``/chosen``. +Add ``xen,dom0-sci-agent-id`` to the ``xen,sci`` node. If the property is = absent, SCMI stays +disabled for Dom0 and the SCMI nodes are removed from Dom0 DT. + +.. code-block:: dts + + chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + xen,dom0-sci-agent-id =3D <0>; /* Dom0 agent ID */ + /* scmi-secondary-agents and scmi_xen as shown above */ + }; + }; + }; + +Xen utilizes the Host DT ``/firmware/scmi`` node to configure the Dom0 SCM= I agent, leaving the +rest of the Host DT unchanged except for the Xen-specific properties under= ``/chosen``. If the +``/firmware/scmi`` node is missing or disabled, the Dom0 SCMI agent will n= ot be configured. + +.. note:: + + The ``xen,dom0-sci-agent-id`` value must match the ``func_id`` and ``shm= em`` pairing provided by + the EL3 firmware for Dom0 (for example in the ``/firmware/scmi`` node). + +Configure SCMI for for guest domain with toolstack +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* In domain's xl.cfg file add **"arm_sci"** option as below + +:: + + arm_sci =3D "type=3Dscmi_smc_multiagent,agent_id=3D2" + +* In domain's xl.cfg file enable access to the "arm,scmi-shmem" which shou= ld correspond + assigned "agent_id" for the domain, for example: + +:: + + iomem =3D [ + "47ff2,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. + The "arm,smc-id" should correspond assigned agent_id for the domain: + +.. 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"; + arm,smc-id =3D <0x82000004>; <--- smc-id for agent_id= =3D2 + shmem =3D <&scmi_shm_0>; + ... + } + } + } + +**Device specific access control** + +The XEN SCMI SMC multi-agent driver performs "access-controller" provider = function in case +EL3 SCMI FW implements SCMI "4.2.1.1 Device specific access control" and p= rovides the +BASE_SET_DEVICE_PERMISSIONS command to configure the devices that an agent= s have access to. +The Host DT SCMI node should have "#access-controller-cells=3D<1>" propert= y and DT devices should +be bound to the SCMI node using Access Controllers bindings [3]. + +For example: + +.. code-block:: dts + + &i2c1 { + access-controllers =3D <&scmi 0>; + }; + +Use domain's xl.cfg file **"dtdev"** property to assign SCMI devices from = toolstack to the guest: + +:: + + dtdev =3D [ + "/soc/i2c@e6508000", + ] + +.. note:: + + xl.cfg:"dtdev" need contain all nodes which are under SCMI management = (not only those which are + behind IOMMU) and passed-through to the guest domain. + +Configure SCMI for predefined domains (dom0less) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* add "xen,sci_type" and "xen,sci-agent-id" properties for required DomU (= "xen,domain") node + +:: + + xen,sci_type=3D"scmi_smc_multiagent" + xen,sci-agent-id=3D2 + +* add scmi nodes to the Driver domain partial device tree the same way as = above (toolstack case) and + enable access to the "arm,scmi-shmem" according to the dom0less document= ation. For example: + +.. code-block:: dts + + 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; + }; + +* For SCMI device access control configure pass-through devices in the gue= st partial DT according to + the dom0less documentation and ensure that devices SCMI management has "= xen,path" property set: + +Example (dom0less, multi-agent): + +.. code-block:: dts + + chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + + /* Xen management channel shared memory */ + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + + scmi_shm_domu: sram@47ff2000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff2000 0x0 0x1000>; + }; + + scmi-secondary-agents =3D < + 0x82000004 &scmi_shm_domu 2>; + #scmi-secondary-agents-cells =3D <3>; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; + #address-cells =3D <1>; + #size-cells =3D <0>; + #access-controller-cells =3D <1>; + shmem =3D <&scmi_shm_1>; + }; + }; + }; + + xen,domain@1 { + compatible =3D "xen,domain"; + xen,sci_type =3D "scmi_smc_multiagent"; + xen,sci-agent-id =3D <2>; + /* other domain properties here */ + }; + }; + +.. code-block:: dts + + i2c@e6508000 { + ... + reg =3D <0x00 0xe6508000 0x00 0x1000>; + -> xen,path =3D "/soc/i2c@e6508000" + -> xen,reg =3D <0x0 0xe6508000 0x0 0x1000 0x0 0xe6508000>; + -> xen,force-assign-without-iommu; + }; --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Jan 21 18:44:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 18:44:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210167.1522008 (Exim 4.92) (envelope-from ) id 1vidBg-0000aY-H2; Wed, 21 Jan 2026 18:44:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210167.1522008; Wed, 21 Jan 2026 18:44:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vidBg-0000aH-DI; Wed, 21 Jan 2026 18:44:16 +0000 Received: by outflank-mailman (input) for mailman id 1210167; Wed, 21 Jan 2026 18:44: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 1vidBf-00083G-Pl for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 18:44:15 +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 267dabec-f6f9-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 19:44:00 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by PAVPR03MB8945.eurprd03.prod.outlook.com (2603:10a6:102:322::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 18:43: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%5]) with mapi id 15.20.9542.008; Wed, 21 Jan 2026 18:43: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: 267dabec-f6f9-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=oVUJqrvO/NYDXN1+VZ5D09D6JCX46NffDGr0Mf7VAzeUI/V+Gn0JL2akZii5k8YbprPxPMAVrPfiPrk+QttNG184RtZUJWlBdTC3ZJtPVu2BwZvGNbXQJf3AlMgx5v5wIn6zvXMlXGDegsyp2aEkrClTtCKg1wERyIV6z+h3PDRYT40M3Q5pL37mPbtdyXY4Y/Fe91Er6nVSIfYVbwLgdVEOt83W3NuPNBQ0OSFwJVj8aNzsX42Ppev29tdxuZ2ALlZyKXEiM7ybXrG1/ZbkxFahzAY+sFuKoi5k3/d98DozCL1R0wKk863Qc4ppjdDttjnCjQUXpcaNmOFJSTKdsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bOobHsh0E9gHuvqfUlo0ZCNmxQatFISIpahpkrH2p3o=; b=KbfAFXNKN52oElkRhIVX44+9D+qAWbx8/orlkBszjXMshx21n/swOSYh+En9V6uoxlFbqwcXKOKWTC7GDGEAope/EopuzieNFP+PU10ARFs1J/bcKamdWl1njh+PQ3admg9WH/CGUjXYcbjht/ZTHQRNygtLqBk561sBqYSoxgw+iJaZ1NBlphU89C0gi/1UhBhccd/47qDU5oYLjv8uL2PUgV/R6y8nn2OeN1KwziklrjImZMF41vH/JS5UuOXYZC8U5W0mZOit5nEQKSc0o1E6CaV/p46cPHI9Ccd81rVB0qWUEWFxCXNGdq+VhHvu1xgixtMNuj1N9QH1wc1iZQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bOobHsh0E9gHuvqfUlo0ZCNmxQatFISIpahpkrH2p3o=; b=GFdSadp2Jb1pMNTFoGznnRa5T5gTxWrIKb+hRvVhOJpzhQAQLG5k9OiAxA0FVyi/lBGroTKQcqKuZb0p6wbrmYM6sXgau0uIrjSShj02wb0ex0eJQoQ5dTQjdo9mLaIzlk/EUyX4RRGX8wBBRT7dsUvcuGoN20US8x9EAhLHchYYpxiF1nY2ztt7nQzmpumPXH8XQtC5Q1d0ptteG8QJX/yObqI9nC3TGF58Xcyw6AxHFxt6ZpDAdulxZPTzmpffq4XX3wxQxsQG+I8KZ1WJHiEjZa6bNZevJh2r9SBqcUq2q7sFyTncrAQsGYqUabogKBpzuvczfB9fo9sA5XCatg== 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 , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v8 1/5] xen/domctl: chain SCI handling before IOMMU in assign_device domctl Thread-Topic: [PATCH v8 1/5] xen/domctl: chain SCI handling before IOMMU in assign_device domctl Thread-Index: AQHciwXk/uoXY0zPp0qUEySvGl6zVA== Date: Wed, 21 Jan 2026 18:43:54 +0000 Message-ID: <8482f823e945060d1a36469f14f94aa6251e3f71.1769020872.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_|PAVPR03MB8945:EE_ x-ms-office365-filtering-correlation-id: e31b9f11-b8b0-42fa-b271-08de591d073a 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: =?utf-8?B?Sk1Gb3RnV1c2eEdYV1FXUjk3blpSUUFuSVZEOGpreDdjSkhndGo2em03ZHhQ?= =?utf-8?B?MXZmWWp6aDJ1ZG9wenZ4djNGWnh1djc4dFBiQlI1d0FBYU9QcnFOTXlCY2RP?= =?utf-8?B?VXVCZkJCWDhqQi95TDhCV0QvOWNFMUo0RE9GbzhuMUxrR1U4eXo2ZDhKbjhT?= =?utf-8?B?QzNqVjExcGw4dDk0ZWZ5a1htU2k2SEVLYUVCc1lEeDU0QkRySnhqWDZjSXg0?= =?utf-8?B?MmQ3SG9YU2QybnRCT2RaU2g5WW1SWlJ1Zmswd0xLUktqa0t4RG1Rd1BvQXlM?= =?utf-8?B?dlF5NWRYRmlQV0hFODJSQjBrbGluclJHS2oxckNOK1k5WDVBZTZJdVh4NFV6?= =?utf-8?B?bkdOWUZpRXhvTk1yb2tXWisxeG1yY2dYaUt2aUxOVU1LYkEyNEdZWkZVVUJP?= =?utf-8?B?bjY4WEN6VHRwSjNkaEwxeTJLcC9hWnVIUTFqTHY0ZDBkWVEzUUxyVzF6N0dp?= =?utf-8?B?cEF4VGpEYlZBbS82MFNkY2VKVGtEeGdDWjllNkJJeUxlYms2MzRFZW9zcitj?= =?utf-8?B?WHhYS0plSUdTRGpuYnZLcGxrV1VXempUUkZ6cCtSTEZsOEdXSEk4R2xrR3pt?= =?utf-8?B?MU84UWhLQW1IUGdSYTNWZG0vU1lVYWo2c0ZxWkVnTDdpdWFLemo0UUU0b29S?= =?utf-8?B?dVV3ZkxiWjhYUlFPMmp6cnVZdXBKMG5wa2JDSjg1NWFPcFZUOVBsa3ZqMjRO?= =?utf-8?B?dFdPRlMzSHc0Y1hrc0RkN3dvaDd3WmxJVitzamxEOUtHQ0JaT0xiUzV2bk1V?= =?utf-8?B?ZU45NkpYUmRoYmVmSzFVT09HOXRDVHRkMW1KT29YWnhCQmswRDVVdDFPelZO?= =?utf-8?B?dTRReURuaGpmNVMxT2JDNElCV3Nvd0dsY1p2VzAzTXcxL1BPeXowVnNNU0Zy?= =?utf-8?B?Rld6QnljY0VJc3p1TWRUeFplYmJnY0JYZCtjVWhqOVA2S3l5VkVpWitmakNL?= =?utf-8?B?dkJQZWMxSDV2RnBiT3hmVWM4bmFtL3R5QkF0bjFzMDVoaHVKaFRJVFl1STdn?= =?utf-8?B?K2NWaG5SdDY1UCtFMWJkbmFVQ0QxclV3eCtoeUZFYVFZYjI2NUZMZmdKQmo0?= =?utf-8?B?amxiczd6dFVCZUhYaE9haEdQNnFuRURXREp4bjNTTWFCaDlEZUJ2cjJxRFBz?= =?utf-8?B?eFFiRG52REt3eHBVakJsQUtHQUxWL3pjRUtEV2NxWVJaRTF1ZFovVWUyL3Nx?= =?utf-8?B?WS9rejlHRnViQUFEUnhnbFRvZEYvcTd2eDdUMFBlai9rYWMzaDIwV0EwMGt4?= =?utf-8?B?cWplN0J4K1I5UG5SUjUwdUlmdUVKYVhKNzVKRHdWT0U4dVdHY3RueTkxdEJp?= =?utf-8?B?czQyRnovRkpVbzNLWlBJS0pGN0VUYTVCUUU5M2R0cVNZNXNrUUpCeGhnOWo0?= =?utf-8?B?U2Z2Nlo5QWJNVGd5QzZIRFQ0L0NHWlgzVTJXRzB0ZkZjaUNNVnBiWk13R3Fl?= =?utf-8?B?S3JIeTVzM2FaUktEN2xpdFRqRFFFNzh6dklscy9WdFRFWUFlVmpBVHZMQ1JX?= =?utf-8?B?dmJ1M3NCMVJ5MERyRnVicDYrVWo2anpaQ292VjhYTk1xMDEyYVowZndUYzhw?= =?utf-8?B?MDRpY3RaZ1daSUZjNGdWZktYOC9FcmhqeEM5SUZUY3U1R00yUkY4cXU3QjVm?= =?utf-8?B?b01SQ2d1Mk5sY0ViQzZ2dFFVTFpxbXNPend0d2p5UVFYd3dRVG0xVjZVYjlR?= =?utf-8?B?Y3owQm1sdm84UERKQ3k3V3g5SUViVXFQdHBPZjNMV3JmVlNpa2RIK3V4MWpk?= =?utf-8?B?QzRQTHZrM2w0UjdCN1Nza29SeGlIZ29tdTlER1lCcTloRHFtOUV6dVBSelAr?= =?utf-8?B?OFZ0bFJZTkdheEtHY3kyN3cyanFSd29OVGVRRkdCdVZBMXZHTm5YMHU3QWNH?= =?utf-8?B?RkRvdGNmbFJzZllsQ09KK0lEd3dna3ppb253UWZJMm9Ua0t5NkVnN2RCcm9L?= =?utf-8?B?N01LcUxlODRpaVFJbkhFVEZuT3hoMGF1N1lUUHZXV3JPbll3dWtpdVU2NE9l?= =?utf-8?B?c2ZpSU1zc0NKaGFZVllTMFQ5OEtIRTBmUy83Y29xSjdZTm5oOXh3aDdmN1Z5?= =?utf-8?B?SEpxSzhvLzRNVjVVM0pmTHBXNVhtQ1ZYWmZ0aVZOVzcrYWZXWDFnUnU3OUlF?= =?utf-8?B?RjA5TlBTREZwSVh0L1ZqQURFQllaa2NHTms5YnM5TTJLeGxSbDFjRDZMaXN3?= =?utf-8?Q?xXfhS7X3YkZ2yvr9PbW1Z+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)(366016)(376014)(7416014)(1800799024)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Wnl5NmlZaXUwbGtmWDdPNE5CYzIzdkJ4YXV4ZDZUblpwYzRqLzlEVDlFYjZl?= =?utf-8?B?VkxlaTg3NFJ3OFdsWXRUa0JTZm5lazJnZ1BBdVpXTlJGYjJVY0NmaEUvazZS?= =?utf-8?B?VWZ6SlFURjczM1hZd0RmMUJxb2ptOFRlS2d6Z3BzRDZYdlJuMHJVUEl0clR2?= =?utf-8?B?d3djNk1Kc3dHZjJ5dEFmMTM3OVJYa1RnTWo1TnpMdUNscWcrVzFhUFJzYVZN?= =?utf-8?B?dXdkeDNhckNocFJ4UFMrOU9Ld0JXQS96bXNJRHFNYnA5VExYY0RuVG1NVDB3?= =?utf-8?B?TXRFZHNqSm5jd0dxaHZnc2lnc05mcCt2eXhyZmZ2QXU3U0dwZTN4NmpVY1lT?= =?utf-8?B?WXhnNlhtemR6ejlBS01YWUZMTDEzSWRXTitSMEluc2lSeDU4aldlTEJxZGcw?= =?utf-8?B?dnJ6WUtnK2RSQ3d6cEltMTJ3MXIwak0xNGhJSjJ5bFdqaW1OeHkwYlYxZkFa?= =?utf-8?B?Q2lmb2NpdEpFbFhlYjRHbUxRc1VtQU9DNTh3OFVsKzU1WUxPd05XbmEyNEZN?= =?utf-8?B?YjhtWGFPUUNKc2RCWCthNmpuVE10TVJuOTZUaEtFU1VTNmExMWpTdmZQdEZQ?= =?utf-8?B?ZFQ3UlBES0NsVWk3SWFNMGZEV2dLTE9CMXNKZmhtcmMxZlV5M05hQWdOTUNU?= =?utf-8?B?Yi9sSS9xbHgxNFhOaHlLR1Q3SHpIQ2RYbXQxWTRaa2xnc3JmeDJxWFNJVEFM?= =?utf-8?B?anlYOGRnVnpFdjVUeS9JZk9zRjNLNEtpK1NzeEVpV1BlNVVaZ1IvVWpHQ2ha?= =?utf-8?B?Znk3dmNmRENwbzIwZlk3TmYwRzZBZWM2anRUMG1ZdVIwS1N5cGRzTUcvaWZh?= =?utf-8?B?Y2JlTkI5eDdvT0ZHdjJyTjh5ckQwQXdic2RmU0Q2WGI5SUlWMEM0UVlaM1Zr?= =?utf-8?B?RTVNb1h1clpzQ2w0V05WSTd3akszWnBtZ0dFOVF3WWpXOG94bnkxdXBsTWwv?= =?utf-8?B?NFJUU29qQzh6ejIrb25kaWg4bTZFT3lnZVRVeE9YRkp3SUVmaDZCTW9CS2JE?= =?utf-8?B?dnBwN3JndzVNOS95L04yUW5GY3lvMCtqVjFTT2Z6b3I0Y0FwbzZJNDNGRW45?= =?utf-8?B?RDUrSk5JU09ic1Z0Y1ZoQlRRNTFFc3BZZkx5SzQ2OVl5bTVYcEJhTHkrS2lV?= =?utf-8?B?RytyN2FmeWJFZjR4bEREY2V2cG9hREJsWjA0WW1Eb2E4RFkwR3hLNVltTjdF?= =?utf-8?B?d0VQN0NBUHhUSFRFdUpGRkx6ejhWcWI3czlHR3pjRzBzcThZVG5WUUk2bE9s?= =?utf-8?B?ZEcvM0MvMVdZUVpPalA1dnFIZU82VHBCNHJJRlh2ZDFmcGhhMkJMSWEzWFpC?= =?utf-8?B?YzhNVHc1dm1qSzVGRnRqWWhjaW56T3J3ZHMvRUZRSkpZNVN5b2laUEdqWE40?= =?utf-8?B?NDcvTU1RL1VyZU1hN3ZJQmRLbGkwK2s0akZ0aXV6RFoyZDd1ZTVyOFBvWFNo?= =?utf-8?B?Z1RkQStHcTBBSzNTVGFLUjc3aUJidVBWbDhKaGJVenVhamlFWUt1QWt4RWpk?= =?utf-8?B?WFY0NEtyN3NpVDE2T1lMU283NFhBT25pekNZeGgxZzcvbngxSzIzVmhWNXI2?= =?utf-8?B?azRIWHQ4WnFFUG85YTY3SlYrY1JJczRodDJxTXRsZjM2L016Y240N29IdDY2?= =?utf-8?B?K3Y3Sks3OUFVeWhkd0NrU0wxTjJ0QXkxOUtzd3ptbWN5Y3RudEhzbmpNWlhD?= =?utf-8?B?WG84ZEJ1WEJyZmNMK1BZOGhvTTd3RnFHUVd1aHRhWEdXWjF0U2lqOU5IN1Zr?= =?utf-8?B?enFodEFzWmxvenh6MXB5T25GSVZaM1VmTlE5UkR2WlJESTlJQ1VwUGF0WWFm?= =?utf-8?B?Kysra0NzQ0JlbFpGZ3R2S3RTYkpVdlBsRWJzYVJ0SWNtTVAvSUs0MEhuaUk2?= =?utf-8?B?WXZEaWtKSWQwckRubXdzSEwxWm1oWFZtNjRlcHdNYkFZSkZTSUhtb0s4U0pk?= =?utf-8?B?WEJGWXRybGNBTDFUcEJ0azgwYWkrcWR1L2N3NlhTRU15Y2xiVFlTWm03ZGRZ?= =?utf-8?B?TXRVaEgvNDRWUEhCVTFNM0NBSXhUSnNUWnlTdGZKYUZRUVhPQUxqSWtIQ0hK?= =?utf-8?B?dkRrK2JCdEdFbmJyTXdxSXA3c2xRS0RKdzJLb3lzYzBUdjBnTUs0V0dOWDhj?= =?utf-8?B?NWZIZ2IyYm56bXVFb2FhUU1XcXNJYmZTT0hWUzQ3N2I4T2ZkNXVlWjN1Z2lS?= =?utf-8?B?U1kwam1uY0hsbjRKeStBREhyMzdaK1dTeXhLWU5WQzV5SXo3dFp0aEQrYXJt?= =?utf-8?B?Q3kwOE1RNnQwYlNOYktGSG5OQmtyemFyMWhGaHhFaGhVb1p1eUZnWXNCTUxH?= =?utf-8?B?UjBFTVd2S0UwOE1GMVJKZnJjbXJwYit3aUdIbFVFZDdWQUxDTmEwQU5lYll3?= =?utf-8?Q?GbE7WpNq08JTchN8=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <3135C440941BC145810BD9B21C77EEB6@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: e31b9f11-b8b0-42fa-b271-08de591d073a X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2026 18:43:54.2837 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CqAEWV69xiC0Azdiw83VoPm8Vubqo/8eJS+0cLaSA+7tm6XsIQH4cCcUr9qbffTpWC3PHvtu/jMCYMfE74i/9ncmywiU8QZOgVcD6xcMSCE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB8945 RnJvbTogR3J5Z29yaWkgU3RyYXNoa28gPGdyeWdvcmlpX3N0cmFzaGtvQGVwYW0uY29tPg0KDQpB ZGQgY2hhaW5lZCBoYW5kbGluZyBvZiBhc3NpZ25lZCBEVCBkZXZpY2VzIHRvIHN1cHBvcnQgYWNj ZXNzLWNvbnRyb2xsZXINCmZ1bmN0aW9uYWxpdHkgdGhyb3VnaCBTQ0kgZnJhbWV3b3JrLCBzbyBh IERUIGRldmljZSBhc3NpZ24gcmVxdWVzdCBjYW4gYmUNCnBhc3NlZCB0byBmaXJtd2FyZSBmb3Ig cHJvY2Vzc2luZyBhbmQgZW5hYmxpbmcgVk0gYWNjZXNzIHRvIHRoZSByZXF1ZXN0ZWQNCmRldmlj ZSAoZm9yIGV4YW1wbGUsIGRldmljZSBwb3dlciBtYW5hZ2VtZW50IHRocm91Z2ggU0NNSSkuDQoN ClRoZSBTQ0kgYWNjZXNzLWNvbnRyb2xsZXIgRFQgZGV2aWNlIHByb2Nlc3NpbmcgaXMgY2FsbGVk IGJlZm9yZSB0aGUgSU9NTVUNCnBhdGguIEl0IHJ1bnMgZm9yIGFueSBEVC1kZXNjcmliZWQgZGV2 aWNlIChwcm90ZWN0ZWQgb3Igbm90LCBhbmQgZXZlbiB3aGVuDQp0aGUgSU9NTVUgaXMgZGlzYWJs ZWQpLiBUaGUgSU9NTVUgcGF0aCByZW1haW5zIHVuY2hhbmdlZCBmb3IgUENJIGRldmljZXM7DQpv bmx5IHRoZSBEVCBwYXRoIGlzIHJlbGF4ZWQgdG8gcGVybWl0IG5vbi1JT01NVSBkZXZpY2VzLg0K DQpUaGlzIGxldHMgeGwuY2ZnOiJkdGRldiIgbGlzdCBib3RoIElPTU1VLXByb3RlY3RlZCBhbmQg bm9uLXByb3RlY3RlZCBEVA0KZGV2aWNlczoNCg0KZHRkZXYgPSBbDQogICAgIi9zb2MvdmlkZW9A ZTZlZjAwMDAiLCA8LSBJT01NVSBwcm90ZWN0ZWQgZGV2aWNlDQogICAgIi9zb2MvaTJjQGU2NTA4 MDAwIiwgPC0gbm90IElPTU1VIHByb3RlY3RlZCBkZXZpY2UNCl0NCg0KVGhlIGNoYW5nZSBpcyBk b25lIGluIHR3byBwYXJ0czoNCjEpIGNhbGwgc2NpX2RvX2RvbWN0bCgpIGluIGRvX2RvbWN0bCgp IGJlZm9yZSBJT01NVSBwcm9jZXNzaW5nIGFuZA0KcHJvcGFnYXRlIGl0cyBlcnJvciBpZiBpdCBm YWlscyB3aGlsZSB0aGUgSU9NTVUgcGF0aCBzdWNjZWVkcyAodW5oYW5kbGVkDQpjYXNlcyByZXR1 cm4gLUVOWElPIGFuZCBhcmUgaWdub3JlZCk7DQoyKSB1cGRhdGUgaW9tbXVfZG9fZHRfZG9tY3Rs KCkgdG8gY2hlY2sgZm9yIGR0X2RldmljZV9pc19wcm90ZWN0ZWQoKSBhbmQNCm5vdCBmYWlsIGlm IERUIGRldmljZSBpcyBub3QgcHJvdGVjdGVkIGJ5IElPTU1VLiBpb21tdV9kb19wY2lfZG9tY3Rs DQpkb2Vzbid0IG5lZWQgdG8gYmUgdXBkYXRlZCBiZWNhdXNlIGlvbW11X2RvX2RvbWN0bCBmaXJz dCB0cmllcw0KaW9tbXVfZG9fcGNpX2RvbWN0bCAod2hlbiBDT05GSUdfSEFTX1BDSSkgYW5kIGZh bGxzIGJhY2sgdG8NCmlvbW11X2RvX2R0X2RvbWN0bCBvbmx5IGlmIFBDSSByZXR1cm5zIC1FTk9E RVYuDQoNClRoZSBuZXcgZHRfZGV2aWNlX2lzX3Byb3RlY3RlZCgpIGJ5cGFzcyBpbiBpb21tdV9k b19kdF9kb21jdGwgb25seQ0KYXBwbGllcyB0byBEVC1kZXNjcmliZWQgZGV2aWNlczsgU0NJIHBh cmFtZXRlcnMgYXJlIGNhcnJpZWQgdmlhIERUDQpub2Rlcy4gUENJIGRldmljZXMgaGFuZGxlZCBi eSBpb21tdV9kb19wY2lfZG9tY3RsIGRvIG5vdCBjYXJyeSBEVC9TQ0kNCm1ldGFkYXRhIGluIHRo aXMgcGF0aCwgc28gdGhlcmUgaXMgbm8gbm90aW9uIG9mIOKAnFNDSSBwYXJhbWV0ZXJzIG9uIGEN Cm5vbi1JT01NVS1wcm90ZWN0ZWQgUENJIGRldmljZeKAnSBmb3IgaXQgdG8gaW50ZXJwcmV0IG9y IHRvIHNraXAuIFRoZSBQQ0kNCnBhdGggc2hvdWxkIGNvbnRpbnVlIHRvIHJlcG9ydCBlcnJvcnMg aWYgYXNzaWdubWVudCBjYW5ub3QgYmUgcGVyZm9ybWVkDQpieSB0aGUgSU9NTVUgbGF5ZXIuIFNv IHdlIHNob3VsZCBsZWF2ZSBpb21tdV9kb19wY2lfZG9tY3RsIHVuY2hhbmdlZDsgdGhlDQpTQ0kv RFQtc3BlY2lmaWMgcmVsYXhhdGlvbnMgYmVsb25nIG9ubHkgaW4gdGhlIERUIHBhdGguIEFsc28g U0NJIGhhbmRsaW5nDQpvbmx5IGV4aXN0cyB3aGVuIERUIGlzIHByZXNlbnQuDQoNClNpZ25lZC1v ZmYtYnk6IEdyeWdvcmlpIFN0cmFzaGtvIDxncnlnb3JpaV9zdHJhc2hrb0BlcGFtLmNvbT4NClNp Z25lZC1vZmYtYnk6IE9sZWtzaWkgTW9pc2llaWV2IDxvbGVrc2lpX21vaXNpZWlldkBlcGFtLmNv bT4NCi0tLQ0KDQpDaGFuZ2VzIGluIHY4Og0KLSBjaGVjayBmb3IgQ09ORklHX0FSTV9TQ0kgdG8g YmUgZWJhYmxlZCBpbnN0ZWFkIG9mIENPTUZJR19BUk0gYmVmb3JlDQpjYWxsaW5nIHNjaV9kb19k b21jdGwNCi0gcmV3b3JrIHNjaV9kb19kb21jdGwgY2FsbCB0byBhdm9pZCBleHRyYSBjaGVja3Ms IGltcHJvdmVkIGVycm9yDQpoYW5kbGluZy4NCi0gZG8gbm90IHByb3BhZ2F0ZSByZXQxIGlmIHNj aV9kb19kb21jdGwgcmV0dXJuZWQgcG9zaXRpdmUgcmV0DQotIHVwZGF0ZWQgY29tbWVudCBpbiBk b21jdGwuYyBjb2RlDQoNCkNoYW5nZXMgaW4gdjc6DQotIHVwZGF0ZSBkb21jdGwgdG8gYnVpbGQg b24gYm90aCBBcm0gYW5kIHg4NiBwbGF0Zm9ybXMNCi0gbW92ZSByZXQxIGRlY2xhcmF0aW9uIHRv IHRoZSB0b3Agb2YgdGhlIGZ1bmN0aW9uIGFzIHJlcXVpcmVkIGJ5IGNvZGUNCnN0eWxlDQoNCkNo YW5nZXMgaW4gdjY6DQotIGNoYW5nZSBpb21tdV9kb19kb21jdGwgYW5kIHNjaV9kb19kb21jdGwg Y29tbWFuZCBvcmRlciBhbmQNCmNhbGwgc2NpX2RvX2RvbWN0bCBmaXJzdCB3aGljaCB3aWxsIHBy b2R1Y2UgY2xlYW5lciBjb2RlIHBhdGguDQpBbHNvIGRyb3BwZWQgY2hhbmdpbmcgcmV0dXJuIGNv ZGUgd2hlbiBpb21tdSB3YXMgZGlzYWJsZWQgaW4NCmlvbW11X2RvX2RvbWN0bC4NCg0KQ2hhbmdl cyBpbiB2NToNCi0gcmV0dXJuIC1FSU5WQUwgaWYgbWVkaWF0b3Igd2l0aG91dCBhc3NpZ25fZHRf ZGV2aWNlIHdhcyBwcm92aWRlZA0KLSBpbnZlcnQgcmV0dXJuIGNvZGUgY2hlY2sgZm9yIGlvbW11 X2RvX2RvbWN0bCBpbg0KWEVOX0RPTUNUTF9hc3NpZ25fZGV2aWNlIGRvbWN0bCBwcm9jZXNzaW5n IHRvIG1ha2UgY2xlYW5lciBjb2RlDQotIGNoYW5nZSAtRU5PVFNVUFAgZXJyb3IgY29kZSB0byAt RU5YSU8gaW4gc2NpX2RvX2RvbWN0bA0KLSBoYW5kbGUgLUVOWElPIHJldHVybiBjb21kZSBvZiBp b21tdV9kb19kb21jdGwNCi0gbGVhdmUgIWR0X2RldmljZV9pc19wcm90ZWN0ZWQgY2hlY2sgaW4g aW9tbXVfZG9fZHRfZG9tY3RsIHRvIG1ha2UNCmNvZGUgd29yayB0aGUgc2FtZSB3YXkgaXQncyBk b25lIGluICJoYW5kbGVfZGV2aWNlIiBjYWxsIHdoaWxlDQpjcmVhdGluZyBod2RvbShkb20wKSBh bmQgImhhbmRsZV9wYXNzdGhyb3VnaF9wcm9wIiBjYWxsIGZvciBkb20wbGVzcw0KY3JlYXRpb24N Ci0gZHJvcCByZXR1cm4gY2hlY2sgZnJvbSBzY2lfYXNzaWduX2R0X2RldmljZSBjYWxsIGFzIG5v dCBuZWVkZWQNCi0gZG8gbm90IHJldHVybiBFSU5WQUwgd2hlbiBhZGRpZ25fZHRfZGV2aWNlIGlz IG5vdCBzZXQuIFRoYXQgaXMNCmJlY2F1c2UgdGhpcyBjYWxsYmFjayBpcyBvcHRpb25hbCBhbmQg bm90IGltcGxlbWVudGVkIGluIHNpbmdsZS1hZ2VudCBkcml2ZXINCg0KIHhlbi9hcmNoL2FybS9m aXJtd2FyZS9zY2kuYyAgICAgICAgICAgICB8IDM1ICsrKysrKysrKysrKysrKysrKysrKysrKysN CiB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vZmlybXdhcmUvc2NpLmggfCAxNCArKysrKysrKysr DQogeGVuL2NvbW1vbi9kb21jdGwuYyAgICAgICAgICAgICAgICAgICAgIHwgMjYgKysrKysrKysr KysrKysrKystDQogeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvZGV2aWNlX3RyZWUuYyAgIHwgIDYg KysrKysNCiA0IGZpbGVzIGNoYW5nZWQsIDgwIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkN Cg0KZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY2kuYyBiL3hlbi9hcmNoL2Fy bS9maXJtd2FyZS9zY2kuYw0KaW5kZXggYWE5M2NkYTdmMC4uMzFhN2U1YzI4YiAxMDA2NDQNCi0t LSBhL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY2kuYw0KKysrIGIveGVuL2FyY2gvYXJtL2Zpcm13 YXJlL3NjaS5jDQpAQCAtMTI2LDYgKzEyNiw0MSBAQCBpbnQgc2NpX2Fzc2lnbl9kdF9kZXZpY2Uo c3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IGR0X2RldmljZV9ub2RlICpkZXYpDQogICAgIHJldHVy biAwOw0KIH0NCiANCitpbnQgc2NpX2RvX2RvbWN0bChzdHJ1Y3QgeGVuX2RvbWN0bCAqZG9tY3Rs LCBzdHJ1Y3QgZG9tYWluICpkLA0KKyAgICAgICAgICAgICAgICAgIFhFTl9HVUVTVF9IQU5ETEVf UEFSQU0oeGVuX2RvbWN0bF90KSB1X2RvbWN0bCkNCit7DQorICAgIHN0cnVjdCBkdF9kZXZpY2Vf bm9kZSAqZGV2Ow0KKyAgICBpbnQgcmV0ID0gMDsNCisNCisgICAgc3dpdGNoICggZG9tY3RsLT5j bWQgKQ0KKyAgICB7DQorICAgIGNhc2UgWEVOX0RPTUNUTF9hc3NpZ25fZGV2aWNlOg0KKyAgICAg ICAgcmV0ID0gLUVOWElPOw0KKyAgICAgICAgaWYgKCBkb21jdGwtPnUuYXNzaWduX2RldmljZS5k ZXYgIT0gWEVOX0RPTUNUTF9ERVZfRFQgKQ0KKyAgICAgICAgICAgIGJyZWFrOw0KKw0KKyAgICAg ICAgaWYgKCAhY3VyX21lZGlhdG9yICkNCisgICAgICAgICAgICBicmVhazsNCisNCisgICAgICAg IGlmICggIWN1cl9tZWRpYXRvci0+YXNzaWduX2R0X2RldmljZSApDQorICAgICAgICAgICAgYnJl YWs7DQorDQorICAgICAgICByZXQgPSBkdF9maW5kX25vZGVfYnlfZ3BhdGgoZG9tY3RsLT51LmFz c2lnbl9kZXZpY2UudS5kdC5wYXRoLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGRvbWN0bC0+dS5hc3NpZ25fZGV2aWNlLnUuZHQuc2l6ZSwgJmRldik7DQorICAgICAgICBp ZiAoIHJldCApDQorICAgICAgICAgICAgcmV0dXJuIHJldDsNCisNCisgICAgICAgIHJldCA9IHNj aV9hc3NpZ25fZHRfZGV2aWNlKGQsIGRldik7DQorDQorICAgICAgICBicmVhazsNCisgICAgZGVm YXVsdDoNCisgICAgICAgIC8qIGRvIG5vdCBmYWlsIGhlcmUgYXMgY2FsbCBpcyBjaGFpbmVkIHdp dGggaW9tbXUgaGFuZGxpbmcgKi8NCisgICAgICAgIGJyZWFrOw0KKyAgICB9DQorDQorICAgIHJl dHVybiByZXQ7DQorfQ0KKw0KIHN0YXRpYyBpbnQgX19pbml0IHNjaV9pbml0KHZvaWQpDQogew0K ICAgICBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKm5wOw0KZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2Fy bS9pbmNsdWRlL2FzbS9maXJtd2FyZS9zY2kuaCBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9m aXJtd2FyZS9zY2kuaA0KaW5kZXggMzUwMDIxNmJjMi4uYTJkMzE0ZTYyNyAxMDA2NDQNCi0tLSBh L3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9maXJtd2FyZS9zY2kuaA0KKysrIGIveGVuL2FyY2gv YXJtL2luY2x1ZGUvYXNtL2Zpcm13YXJlL3NjaS5oDQpAQCAtMTQ2LDYgKzE0NiwxNCBAQCBpbnQg c2NpX2R0X2ZpbmFsaXplKHN0cnVjdCBkb21haW4gKmQsIHZvaWQgKmZkdCk7DQogICogY29udHJv bCIgZnVuY3Rpb25hbGl0eS4NCiAgKi8NCiBpbnQgc2NpX2Fzc2lnbl9kdF9kZXZpY2Uoc3RydWN0 IGRvbWFpbiAqZCwgc3RydWN0IGR0X2RldmljZV9ub2RlICpkZXYpOw0KKw0KKy8qDQorICogU0NJ IGRvbWN0bCBoYW5kbGVyDQorICoNCisgKiBPbmx5IFhFTl9ET01DVExfYXNzaWduX2RldmljZSBp cyBoYW5kbGVkIGZvciBub3cuDQorICovDQoraW50IHNjaV9kb19kb21jdGwoc3RydWN0IHhlbl9k b21jdGwgKmRvbWN0bCwgc3RydWN0IGRvbWFpbiAqZCwNCisgICAgICAgICAgICAgICAgICBYRU5f R1VFU1RfSEFORExFX1BBUkFNKHhlbl9kb21jdGxfdCkgdV9kb21jdGwpOw0KICNlbHNlDQogDQog c3RhdGljIGlubGluZSBib29sIHNjaV9kb21haW5faXNfZW5hYmxlZChzdHJ1Y3QgZG9tYWluICpk KQ0KQEAgLTE5NSw2ICsyMDMsMTIgQEAgc3RhdGljIGlubGluZSBpbnQgc2NpX2Fzc2lnbl9kdF9k ZXZpY2Uoc3RydWN0IGRvbWFpbiAqZCwNCiAgICAgcmV0dXJuIDA7DQogfQ0KIA0KK3N0YXRpYyBp bmxpbmUgaW50IHNjaV9kb19kb21jdGwoc3RydWN0IHhlbl9kb21jdGwgKmRvbWN0bCwgc3RydWN0 IGRvbWFpbiAqZCwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFhFTl9HVUVTVF9I QU5ETEVfUEFSQU0oeGVuX2RvbWN0bF90KSB1X2RvbWN0bCkNCit7DQorICAgIHJldHVybiAwOw0K K30NCisNCiAjZW5kaWYgLyogQ09ORklHX0FSTV9TQ0kgKi8NCiANCiAjZW5kaWYgLyogX19BU01f QVJNX1NDSV9IICovDQpkaWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9kb21jdGwuYyBiL3hlbi9jb21t b24vZG9tY3RsLmMNCmluZGV4IDI5YTc3MjZkMzIuLmNkODdjMTVmZTYgMTAwNjQ0DQotLS0gYS94 ZW4vY29tbW9uL2RvbWN0bC5jDQorKysgYi94ZW4vY29tbW9uL2RvbWN0bC5jDQpAQCAtMjksNiAr MjksOSBAQA0KICNpbmNsdWRlIDx4ZW4veHZtYWxsb2MuaD4NCiANCiAjaW5jbHVkZSA8YXNtL2N1 cnJlbnQuaD4NCisjaWZkZWYgQ09ORklHX0FSTQ0KKyNpbmNsdWRlIDxhc20vZmlybXdhcmUvc2Np Lmg+DQorI2VuZGlmDQogI2luY2x1ZGUgPGFzbS9pcnEuaD4NCiAjaW5jbHVkZSA8YXNtL3BhZ2Uu aD4NCiAjaW5jbHVkZSA8YXNtL3AybS5oPg0KQEAgLTI3NCw3ICsyNzcsNyBAQCBzdGF0aWMgYm9v bCBpc19zdGFibGVfZG9tY3RsKHVpbnQzMl90IGNtZCkNCiANCiBsb25nIGRvX2RvbWN0bChYRU5f R1VFU1RfSEFORExFX1BBUkFNKHhlbl9kb21jdGxfdCkgdV9kb21jdGwpDQogew0KLSAgICBsb25n IHJldCA9IDA7DQorICAgIGxvbmcgcmV0ID0gMCwgcmV0MSA9IDA7DQogICAgIGJvb2wgY29weWJh Y2sgPSBmYWxzZTsNCiAgICAgc3RydWN0IHhlbl9kb21jdGwgY3Vyb3AsICpvcCA9ICZjdXJvcDsN CiAgICAgc3RydWN0IGRvbWFpbiAqZDsNCkBAIC04MzMsNyArODM2LDI4IEBAIGxvbmcgZG9fZG9t Y3RsKFhFTl9HVUVTVF9IQU5ETEVfUEFSQU0oeGVuX2RvbWN0bF90KSB1X2RvbWN0bCkNCiAgICAg Y2FzZSBYRU5fRE9NQ1RMX3Rlc3RfYXNzaWduX2RldmljZToNCiAgICAgY2FzZSBYRU5fRE9NQ1RM X2RlYXNzaWduX2RldmljZToNCiAgICAgY2FzZSBYRU5fRE9NQ1RMX2dldF9kZXZpY2VfZ3JvdXA6 DQorICAgICAgICAvKg0KKyAgICAgICAgICogQ2hhaW4gU0NJIERUIGhhbmRsaW5nIGFoZWFkIG9m IHRoZSBJT01NVSBwYXRoIHNvIGFuIFNDSSBtZWRpYXRvcg0KKyAgICAgICAgICogY2FuIGF1dGhv cmlzZSBhY2Nlc3MtY29udHJvbGxlZCBEVCBkZXZpY2VzLiBVbmhhbmRsZWQgY2FzZXMgcmVwb3J0 DQorICAgICAgICAgKiAtRU5YSU8sIHdoaWNoIGlzIGlnbm9yZWQuDQorICAgICAgICAgKi8NCisg ICAgICAgIHJldDEgPSAtRU5YSU87DQorICAgICNpZiBJU19FTkFCTEVEKENPTkZJR19BUk1fU0NJ KQ0KKyAgICAgICAgcmV0MSA9IHNjaV9kb19kb21jdGwob3AsIGQsIHVfZG9tY3RsKTsNCisgICAg I2VuZGlmDQorDQogICAgICAgICByZXQgPSBpb21tdV9kb19kb21jdGwob3AsIGQsIHVfZG9tY3Rs KTsNCisgICAgICAgIGlmICggcmV0IDwgMCApDQorICAgICAgICAgICAgcmV0dXJuIHJldDsNCisN CisgICAgICAgIC8qDQorICAgICAgICAgKiBJZiBJT01NVSBwcm9jZXNzaW5nIHdhcyBzdWNjZXNz ZnVsLCBjaGVjayBmb3IgU0NJIHByb2Nlc3NpbmcgcmV0dXJuDQorICAgICAgICAgKiBjb2RlIGFu ZCBpZiBpdCBmYWlsZWQgdGhlbiBvdmVyd3JpdGUgdGhlIHJldHVybiBjb2RlIHRvIHByb3BhZ2F0 ZQ0KKyAgICAgICAgICogU0NJIGZhaWx1cmUgYmFjayB0byBjYWxsZXIuDQorICAgICAgICAgKi8N CisgICAgICAgIGlmICggcmV0MSAhPSAtRU5YSU8gJiYgcmV0MSA8IDAgKQ0KKyAgICAgICAgICAg IHJldCA9IHJldDE7DQorDQogICAgICAgICBicmVhazsNCiANCiAgICAgY2FzZSBYRU5fRE9NQ1RM X2dldF9wYWdpbmdfbWVtcG9vbF9zaXplOg0KZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3Bhc3N0 aHJvdWdoL2RldmljZV90cmVlLmMgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9kZXZpY2VfdHJl ZS5jDQppbmRleCBmNTg1MGEyNjA3Li4yOWE0NGRjNzczIDEwMDY0NA0KLS0tIGEveGVuL2RyaXZl cnMvcGFzc3Rocm91Z2gvZGV2aWNlX3RyZWUuYw0KKysrIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91 Z2gvZGV2aWNlX3RyZWUuYw0KQEAgLTM3OSw2ICszNzksMTIgQEAgaW50IGlvbW11X2RvX2R0X2Rv bWN0bChzdHJ1Y3QgeGVuX2RvbWN0bCAqZG9tY3RsLCBzdHJ1Y3QgZG9tYWluICpkLA0KICAgICAg ICAgICAgIGJyZWFrOw0KICAgICAgICAgfQ0KIA0KKyAgICAgICAgaWYgKCAhZHRfZGV2aWNlX2lz X3Byb3RlY3RlZChkZXYpICkNCisgICAgICAgIHsNCisgICAgICAgICAgICByZXQgPSAwOw0KKyAg ICAgICAgICAgIGJyZWFrOw0KKyAgICAgICAgfQ0KKw0KICAgICAgICAgcmV0ID0gaW9tbXVfYXNz aWduX2R0X2RldmljZShkLCBkZXYpOw0KIA0KICAgICAgICAgaWYgKCByZXQgKQ0KLS0gDQoyLjM0 LjENCg== From xen-devel-bounces@lists.xenproject.org Wed Jan 21 18:44:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 18:44:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210168.1522018 (Exim 4.92) (envelope-from ) id 1vidBi-0000tE-W6; Wed, 21 Jan 2026 18:44:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210168.1522018; Wed, 21 Jan 2026 18: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 1vidBi-0000t5-Sd; Wed, 21 Jan 2026 18:44:18 +0000 Received: by outflank-mailman (input) for mailman id 1210168; Wed, 21 Jan 2026 18:44: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 1vidBg-00083G-Pn for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 18:44:17 +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 2e819d6d-f6f9-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 19:44:13 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by PAVPR03MB8945.eurprd03.prod.outlook.com (2603:10a6:102:322::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 18:43:57 +0000 Received: from PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc%5]) with mapi id 15.20.9542.008; Wed, 21 Jan 2026 18:43: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: 2e819d6d-f6f9-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TNg8Q5QaXqoSnRyThIzFIxGCcugCoXI0Du4YNmXa5D2iWDiZ+CKU+JSX2R2JENbFNUSrpOQDAW9dNkRRcsWZPuhj6wRwRm+Ec7sRKbu1NbAR0eLDRzjmj1N2kx1vEc7LaaFUMT04ZP+jjb060UhhccI4T8h3q20m2R3hbMI5yO/BjxSCpB9YavWfhPmne8XBSyRxcEMO8XTa055qOiTUY+Zg2Q50psLXv8yLYT1b9iKqwJVV+MkUmnmDKqla2ONko1V8pQbszEBACaeD/ZkgNujA0gBkM4ocLxu26yk/4PFTQ2yf1EKugwAI/43KOO3GX2m9eCZ7m7GxPi7TKdxg7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5Fhp/kP8N1NJs9TdCl5nqofZ9x3PA7HOZuf3aahU/X4=; b=kvnx13U38DoSN9Ju+8iO8qOTstEovphJrkgUgovvz1MP2gzujXUc5LmIjunChh2pMQH9AjB6H7jT301h4tpOdamKRWkpFiDDXon4jLtVfb35KAPNCV2xqH1IspigeIIX2pygpHNaQr0Jnzbs5YmMtsK8EqRyeiJMecY/HNd7TTZzlJSZo6wUYV2r7NXX5HAhu/JJmXbbwgEemehtWX5h//ph9IIH/Tz51hX0Z82ldqboR3kMMrbPJl+n50hyFQ8MAnAnPtSN3TSEYYvX2Txsn/VYZ0lLROh0GkIMZues4AqOcGBlQpj+Y3dMdawoIs0t43E6zKAlALeUJ6uwRguj0g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5Fhp/kP8N1NJs9TdCl5nqofZ9x3PA7HOZuf3aahU/X4=; b=Zq5jMl1Y3c56c/Y5MGzJEYXl8tGVbsXf+57fbXFwrw6fRIvb6Rhf3qE/rcTh30mFRwHEDMnejaV9BeoqGRsQjTZKWfBYLVruyOlWcu5HDe7ezIZXVuOZO5pedpplZ1PvqvwXgoxhQeTviBPN8xvr652Dw/J3ZQn7b/aNRCgRFR7nCjk0Oe2h0zkhjRRm4/pZwdk+zcOTQBp+2KG1/pNZfxrBD9g3sALKtuxrpr5X6eqYnO5Ywwutkt2NjwatyscFtvpRXodtw6JofarKgr7Z+8cpKAU5V98m5hqBP1O189d8NxQdar/Hh4iUgv2JgU12mQtR+eqxbuBghn9Hys0OjQ== 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/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [PATCH v8 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHciwXlwgLiqFlETUSoWi6AzAQyog== Date: Wed, 21 Jan 2026 18:43: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_|PAVPR03MB8945:EE_ x-ms-office365-filtering-correlation-id: d56be86d-225e-4116-0ea7-08de591d090e 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?kdAMiIyETDSVgvmUQXaYTcNGsCa7tdswteANrT4soq7yYdWsKvpPkNk5Sg?= =?iso-8859-1?Q?yumb9UF+wQZPlOv5JgWmy+Myv0YyfQeKelsM9ScUtn/RN+pxMo8d2ijTio?= =?iso-8859-1?Q?PyHM8dlsQ1PhiFAUbQThSTDoZNJT9GLMxw+ORW3m212yzt2O0Gt5qV+ecm?= =?iso-8859-1?Q?wyO0k6Exg9ih/P7fZjUsgyACeKWIZc/FkIa7OV7lDs30+wLv2zcDQu3VgS?= =?iso-8859-1?Q?qtBdor1ZNTR6uafLTUubwbr6ZRTBF/05uoZ5PNzlukLsiTZCh0f8bo5iTF?= =?iso-8859-1?Q?WiKp6GG/b9VALfwVDplGe57NF2TMa4mY6wnuWr38MAuoEDuR7H9UVwEtVL?= =?iso-8859-1?Q?aRxAfjUC+bY9Z+GnVReyrK+iE5GlFsP7Akl6/kGtcC6wh7t77bd8e56Eo5?= =?iso-8859-1?Q?7qaqHTRxMy+2ym0g3CmNeCwA93cudCoBz2iTRRoZi2zyEFUjbghnHIgTNG?= =?iso-8859-1?Q?G2NO9phI4c7OW9/5BsG4C3MwLwWCe8WebnFyzLZ2lrdLhzgcJByPTMKxGv?= =?iso-8859-1?Q?py6ZlIPYj1f9jWTf/Wxco23sFJsmVlgMwqDO/xjyP5v9zndUIdfKI1tYG+?= =?iso-8859-1?Q?dwITh1iAGrr0kKxZrg2VNrut6WEcFdZpIjdlgVhAKgGQjOCoBy1xBrE/bC?= =?iso-8859-1?Q?1OMEZ9fw1qb6fva6xu+bc4Z+cT/9zaeFTSKYIpKDXKSlkjjQb5kiZYuQJ7?= =?iso-8859-1?Q?/TO2S9YWhEsyz90W53uLHi5TlIt9XkKwjWa0Gne9iJGBixBBsT+JfG2Grq?= =?iso-8859-1?Q?H7EQGJRMqdAxfdeus+9BGLh1K1+gWYuTsJcakupTw3r6wOb+5m5Q4KeEgp?= =?iso-8859-1?Q?gAgGZFX8QZQ1+Vq05LKkewuadE0ghtcL23+MSb+me0h9QM/0XuRKDAVIVh?= =?iso-8859-1?Q?dXb2PtBaN15tcOP23KYAkvTdmaUea3hWR4exbXHwrBmHyRZaCSVjdWungt?= =?iso-8859-1?Q?UYzp+7eoTS+3tFGYZDfptGgWBVUW5SB+0gDuyloPFFDeulmH02gquReqTH?= =?iso-8859-1?Q?uLhMZa7eXKnTHE5wdBxT6XRgl3tv3MWW9Cgia0gEk1XIW9WqfC3x1CSrH2?= =?iso-8859-1?Q?mjUVXtjMSLnO82aJQA2dw0iPK77ZDpiuqhNgRarX29FRnjzZZOck4gPxNq?= =?iso-8859-1?Q?maboLXnHr5RyWm939V7WOVA3CKNvrbR1avANuEZCAdED5vgIHHyJ187MF2?= =?iso-8859-1?Q?1W/9laJ2akybwqOrxJ57lI3uCnFypWagqWNXnLFUGgdtvxSxN/rn//R0M1?= =?iso-8859-1?Q?OHxuL1yw31LWTS513RxTcMYI/N9PvlnQvtSbKaP4Q66RJlS1wO0YtaxVaS?= =?iso-8859-1?Q?2lakPeFEb36/i0+K8V2tUHz6nnQLwErRBeMitzwjfokCMbH6Bk0vxSlmOC?= =?iso-8859-1?Q?MW9cbFG9F71VccRO74coz90wFCbWx6WzDX5UsjPuWudSTkjhq+D4T87szF?= =?iso-8859-1?Q?DQa7hPXBfHS2/i2E5YHXV/dTpO3JXLpiw29tDpkhpR+pZlOV1eW+UKQqGK?= =?iso-8859-1?Q?oZETxbfGUcsEqGFj8KshpgczPGvtuZDoNvhgZiTVIY1yUayw23IiL3ysi7?= =?iso-8859-1?Q?WaPerufVzaJU7ZgjJ3kN1v7Uw2DbZjddARUZrA3mt7EIEVKqnIQzsZiWOE?= =?iso-8859-1?Q?9EikpnpXspOF3Cau0MOI/f6ZnBC4uVnzOeK3heHWVLF3MUP5hrDTHZhq6I?= =?iso-8859-1?Q?8tvzAMJdqViuVG71cHs=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)(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?pBjU1zrFJvAtlrY/zX6QWa7QXrjoCRgzZUQX3Uyko7AEDUxJJvQJ8dm1DI?= =?iso-8859-1?Q?Gpg5AAQUlBShMn7iwosjQNztZhf3IpzMwtzVJQFJ0QwGtmizkyA54eXhom?= =?iso-8859-1?Q?sS028dI8bfwn8aP+Ei5FoOeHuyE0JJusfGyo/EXuzeYK4slY6GfhVPraLX?= =?iso-8859-1?Q?Fw7UPpHu6OatCfmSpGW+2Ow8lLtzDoY1COGB3cndGX9+xN4ngyLT/O1bT1?= =?iso-8859-1?Q?W7XXyG7XAnnW69S/3ee8w0Cfy3TQ6EycZSvpFJ4wq2NdtGJd6/rjGOV5lP?= =?iso-8859-1?Q?cN9UuIJZMTreCSQtAvtxh0hsttdSXQdV+RuaLt3SFZQ2H9nWGw//8f0pqT?= =?iso-8859-1?Q?RQqGojsUP73P+y4oBnCQ73qqai0NXvus+aNLs05MnjdCE0sEhwa8tiOaR6?= =?iso-8859-1?Q?QAU8MCsDlVgoPmJLNZYH2tu2OsoPwGaUG6/2znA6lh+KUgV/s67kRadl+W?= =?iso-8859-1?Q?ce58SddbNtmN+vuRApGLoPnGdbmUaFCoF0ctnLV4L75rIiyeDF0RHiCNe0?= =?iso-8859-1?Q?CZZHWopQ2KnkpXv2TYMq8XQLBdEJDP1x4T73Dv+zgmZz5gradzq9s2dzJw?= =?iso-8859-1?Q?eJ6h0ulcJapIK2HRvSocMDatN6CKGp7sBrgnC8SgEEZUVDVXWvWjd0Is3c?= =?iso-8859-1?Q?6zX6zudt0G9i6fnHrmrUzwOHVfeWov06YBlPBnAfzfzyUm6OrE20aKpjJS?= =?iso-8859-1?Q?q71vMBPYYzsBueidR0j6oXSSynBwc9vWsjeJBezBXArG7O9O4AsBu+kPQW?= =?iso-8859-1?Q?IlnEnwBcr8gw4HQkq+0hJANrl3+MfS0PZFUT6hCqpDCpPNkVH2C5i0CrEu?= =?iso-8859-1?Q?Wdfaf3slEfbk7IHvevaRhMHRPBXLVXQ67ODJsiaQ50fSiEp5MCQTJpQT5B?= =?iso-8859-1?Q?gzevrxs4QYdcQ1iU2z3hNNzD+M/g1mnnJBv3xJhoWxzjJn6LhrF5wYQ4Mz?= =?iso-8859-1?Q?iJLhMslvV3ZRRGEwx0881lFTds8MZ1kU6DnoPtxIBOpagI23w2g0TaKSjR?= =?iso-8859-1?Q?ylX+3Bmt7jXLTGtMgN5OS9ezkvrtS1i4molDQk2q0SO2+WMWBJ705j3ydf?= =?iso-8859-1?Q?HQ5b4wwlrGBD1WZmTcx11HiKgUnMBNiFVtnMHJc1JTAZsWtPNxZpNyKvvE?= =?iso-8859-1?Q?APguL1aBnSE2MBdR+3sYDRW6jV2gRj7G25Dyq4fvrKVgUmsy2Q+s7g1R2A?= =?iso-8859-1?Q?IL9HJOQ19j0ICE8zKFs/0Fcrogqb279/kOI1QEZecG851Dcze/OJPh41Wp?= =?iso-8859-1?Q?YrFY9XxLH0uKNgYPXWSGKTcbmKeGfvQQEqK1+CrBPSM7ErAPTmixw1VxQa?= =?iso-8859-1?Q?GNVQjq2HYGFEUFZvAftoIuhh3rSXisDZr/VXQyK5sh9fzW9HvvD9AUZd2W?= =?iso-8859-1?Q?vkdyEujmiJIxzEwItq3uZDuuvPyTTLA2F3m5seHHnsDzBvAIQ/R6tGn7zi?= =?iso-8859-1?Q?snecaVzbw95jFMPnGdbqI4AVp4pUF5iR0zEndUnQ4SEPdQcX3+2DER9UxK?= =?iso-8859-1?Q?xSXr9ciUzL7wS9nxaYUW7h3Hacx9aOLV8di/2DhxyrYFxZe6WMkaLPq4Ob?= =?iso-8859-1?Q?hyIhoO5QvHQz8Okvmh2RhukS0aZ/1BDCY+EWLusY56LwwRLCFcbB9LoUyo?= =?iso-8859-1?Q?t76Vkev68fhw/KVkWRMgrGkuk15CYAQpB6v2O/jntE4RYe7ffF7ukT+CqZ?= =?iso-8859-1?Q?CNr+npQm3F5wX6vUt49RnSOdbWCSxlEH++Mx5xJe0YOEV4XqIa1gxv4zEj?= =?iso-8859-1?Q?v/S6ZNN4LLWmok3DmsfHUYoUteg4RAfQo1N6PXAhI+lcsH8Mpx/RB9k1rk?= =?iso-8859-1?Q?MTXFCM5FGk3z7CZXbUgQ9yoYIr1p+a4=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: d56be86d-225e-4116-0ea7-08de591d090e X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2026 18:43:55.8268 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Xg+QSNdIf4bI7RmJVG2U1GJc8l2UbwQyVecS3N0Cd/sYoUqxhSVgiGthiOyeqEAItzR1Plb9Ah0F/VqwMHtaHQaiy5zS/+uc8EoMtihwDnE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB8945 This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-A (TF-A) which provides SCMI interface with multi-agent support, as shown below. +-----------------------------------------+ | | | EL3 TF-A SCMI | +-------+--+-------+--+-------+--+-------++ |shmem1 | |shmem0 | |shmem2 | |shmemX | +-----+-+ +---+---+ +--+----+ +---+---+ smc-id1 | | | | agent1 | | | | +-----v--------+---------+-----------+----+ | | | | | | | | | | +--------------+---------+-----------+----+ smc-id0 | smc-id2| smc-idX| agent0 | agent2 | agentX | | | | +----v---+ +--v-----+ +--v-----+ | | | | | | | Dom0 | | Dom1 | | DomX | | | | | | | | | | | | | +--------+ +--------+ +--------+ The EL3 SCMI multi-agent firmware is expected to provide SCMI SMC shared memory transport for every Agent in the system. The SCMI Agent transport channel defined by pair: - smc-id: SMC id used for Doorbell - shmem: shared memory for messages transfer, Xen page aligned. Shared memort is mapped with the following flags: MT_DEVICE_nGnRE. The follwoing SCMI Agents are expected to be defined by SCMI FW to enable S= CMI multi-agent functionality under Xen: - Xen management agent: trusted agents that accesses to the Base Protocol commands to configure agent specific permissions - OSPM VM agents: non-trusted agent, one for each Guest domain which is allowed direct HW access. At least one OSPM VM agent has to be provided by FW if HW is handled only by Dom0 or Driver Domain. The EL3 SCMI FW is expected to implement following Base protocol messages: - BASE_DISCOVER_AGENT (optional if agent_id was provided) - BASE_RESET_AGENT_CONFIGURATION (optional) - BASE_SET_DEVICE_PERMISSIONS (optional) The SCI SCMI SMC multi-agent driver implements following functionality: - The driver is initialized from the Xen SCMI container ``xen_scmi_config`` (compatible ``xen,sci``) placed under ``/chosen/xen``. Only the ``arm,scmi-smc`` node that is a child of this container will bind to Xen; other SCMI nodes (for example under ``/firmware``) are ignored to avoid stealing the host OSPM instance. scmi_shm_1: sram@47ff1000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff1000 0x0 0x1000>; }; scmi_xen: scmi { compatible =3D "arm,scmi-smc"; arm,smc-id =3D <0x82000003>; <--- Xen management agent smc-id #address-cells =3D < 1>; #size-cells =3D < 0>; #access-controller-cells =3D < 1>; shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem }; - The driver obtains Xen specific SCMI Agent's configuration from the Host DT, probes Agents and builds SCMI Agents list. The Agents configuration is taken from "scmi-secondary-agents" property where first item is "arm,smc-id", second - "arm,scmi-shmem" phandle and third is optional "agent_id": / { chosen { xen { ranges; xen_scmi_config { compatible =3D "xen,sci"; #address-cells =3D <2>; #size-cells =3D <2>; ranges; scmi_shm_0: sram@47ff0000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff0000 0x0 0x1000>; }; /* Xen SCMI management channel */ scmi_shm_1: sram@47ff1000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff1000 0x0 0x1000>; }; scmi_shm_2: sram@47ff2000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff2000 0x0 0x1000>; }; scmi_shm_3: sram@47ff3000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff3000 0x0 0x1000>; }; scmi-secondary-agents =3D < 0x82000002 &scmi_shm_0 0 0x82000004 &scmi_shm_2 2 0x82000005 &scmi_shm_3 3>; <--- func_id, shmem, agent_id #scmi-secondary-agents-cells =3D <3>; xen,dom0-sci-agent-id =3D <0>; scmi_xen: scmi { compatible =3D "arm,scmi-smc"; arm,smc-id =3D <0x82000003>; <--- Xen management agent func_id #address-cells =3D <1>; #size-cells =3D <0>; #access-controller-cells =3D <1>; shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem }; }; }; }; }; / { /* * Host SCMI OSPM channel - provided to the Dom0 as is if SCMI * enabled for it, ignored by Xen multi-agent mediator */ scmi_shm: sram@47ff0000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff0000 0x0 0x1000>; }; firmware { scmi: scmi { compatible =3D "arm,scmi-smc"; arm,smc-id =3D <0x82000002>; <--- Host OSPM agent smc-id #address-cells =3D < 1>; #size-cells =3D < 0>; shmem =3D <&scmi_shm>; <--- Host OSPM agent shmem protocol@X{ }; }; }; }; This approach allows defining multiple SCMI Agents by adding Xen-specific properties under the ``/chosen`` node to the Host Device Tree, leaving the main part unchanged. The Host DT SCMI channel will be passed to Dom0. The Xen management agent is described as a ``scmi_xen`` node under the ``xen,sci`` comaptible node, which is used by Xen to control other SCMI Agents in the system. All secondary agents' configurations are provided in the ``scmi-secondary-agents`` property with an optional ``agent_id`` field. The ``agent_id`` from the ``scmi-secondary-agents`` property is used to identify the agent in the system and can be omitted by setting ``#scmi-secondary-agents-cells =3D <2>``, so the Secondary Agents configuration will look like this: / { chosen { xen { xen_scmi_config { compatible =3D "xen,sci"; #address-cells =3D <2>; #size-cells =3D <2>; ranges; /* Shared memory nodes as defined earlier */ scmi-secondary-agents =3D < 0x82000003 &scmi_shm_0 0x82000004 &scmi_shm_2 0x82000005 &scmi_shm_3 0x82000006 &scmi_shm_4>; #scmi-secondary-agents-cells =3D <2>; }; }; }; } In this case, Xen will use the ``SCMI_BASE_DISCOVER_AGENT`` call to discover the ``agent_id`` for each secondary agent. Providing the ``agent_id`` in the ``scmi-secondary-agents`` property allows skipping the discovery call, which is useful when the secondary agent's shared memory is not accessible by Xen or when boot time is important because it allows skipping the agent discovery procedure. Note that Xen is the only one entry in the system which need to know about SCMI multi-agent support. SMC ID Configuration and SCMI Connection Compatibility: The configuration allows the same device tree to work for both baremetal Linux and Linux Dom0. This is achieved because: - Baremetal Linux uses: func_id 0x82000002, scmi-shmem 0x47ff0000 - Dom0 Linux uses: func_id 0x82000002, scmi-shmem 0x47ff0000 - Xen management uses: func_id 0x82000003, scmi-shmem 0x47ff1000 This works because the privileged SCMI connection in EL3 firmware is not tied exclusively to func_id 0x82000002. The EL3 firmware supports multiple SCMI agents with different SMC IDs and shared memory regions. Each agent (Dom0 via 0x82000002, Xen via 0x82000003, other domains via additional func_ids) has an independent communication channel to the firmware. The key distinction is that Xen's management channel (0x82000003) is used for privileged operations like agent configuration and device permissions (BASE_SET_DEVICE_PERMISSIONS, BASE_RESET_AGENT_CONFIGURATION), while Dom0's channel (0x82000002) is used for standard SCMI protocol operations (power, clock, sensor management, etc.). The firmware enforces different permission levels for each agent based on their agent_id, not the SMC ID. Therefore, there is no conflict: Linux Dom0 retains its standard SCMI connection for hardware management, while Xen uses its separate privileged channel for mediating access between multiple domains. - It implements the SCI subsystem interface required for configuring and enabling SCMI functionality for Dom0/hwdom and Guest domains. To enable SCMI functionality for domain it has to be configured with unique supported SCMI Agent_id and use corresponding SCMI SMC shared memory transport [smc-id, shmem] defined for this SCMI Agent_id. - Once Xen domain is configured it can communicate with EL3 SCMI FW: -- zero-copy, the guest domain puts SCMI message in shmem; -- the guest triggers SMC exception with smc-id (doorbell); -- the Xen driver catches exception, do checks and synchronously forwards it to EL3 FW. - the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen management agent channel on domain destroy event. This allows to reset resources used by domain and so implement use-case like domain reboot. Dom0 Enable SCMI SMC: - set xen,dom0-sci-agent-id=3D under the xen,sci container in the Host DT. If the property is absent, SCMI is disabled for Dom0 and all SCMI nodes are removed from the Dom0 DT. The driver updates the Dom0 DT SCMI node "arm,smc-id" value and fixes up the shmem node according to the assigned agent_id. - pass dom0=3Dsci-agent-id=3D in Xen command line. if not provid= ed SCMI will be disabled for Dom0 and all SCMI nodes removed from Dom0 DT. The driver updates Dom0 DT SCMI node "arm,smc-id" value and fix up shmem node according to assigned agent_id. Guest domains enable SCMI SMC: - xl.cfg: add configuration option as below arm_sci =3D "type=3Dscmi_smc_multiagent,agent_id=3D2" - xl.cfg: enable access to the "arm,scmi-shmem" which should correspond assigned agent_id for the domain, for example: iomem =3D [ "47ff2,1@22001", ] - DT: add SCMI nodes to the Driver domain partial device tree as in the below example. The "arm,smc-id" should correspond assigned agent_id for the domain: passthrough { scmi_shm_0: sram@22001000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x22001000 0x0 0x1000>; }; firmware { compatible =3D "simple-bus"; scmi: scmi { compatible =3D "arm,scmi-smc"; arm,smc-id =3D <0x82000004>; shmem =3D <&scmi_shm_0>; ... } } } SCMI "4.2.1.1 Device specific access control" The XEN SCI SCMI SMC multi-agent driver performs "access-controller" provider function in case EL3 SCMI FW implements SCMI "4.2.1.1 Device specific access control" and provides the BASE_SET_DEVICE_PERMISSIONS command to configure the devices that an agents have access to. The DT SCMI node should "#access-controller-cells=3D<1>" property and DT devices should be bound to the Xen SCMI. &i2c1 { access-controllers =3D <&scmi 0>; }; The Dom0 and dom0less domains DT devices will be processed automatically through sci_assign_dt_device() call, but to assign SCMI devices from toolstack the xl.cfg:"dtdev" property shall be used: dtdev =3D [ "/soc/i2c@e6508000", ] xl.cfg:dtdev will contain all nodes which are under SCMI management (not only those which are behind IOMMU). Additionally, this patch adds documentation for the pre-existing scmi-smc-passthrough command line option, which was previously undocumented. [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/= tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml [2] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/= tree/Documentation/devicetree/bindings/access-controllers/access-controller= s.yaml Signed-off-by: Grygorii Strashko Signed-off-by: Oleksii Moisieiev --- Changes in v8: - update xen_scmi func_id in commit description - updated documentation with the new DT format - updated opt_dom0_scmi_agent_id setting to avoid it to be equal SCMI_AGENT_ID_INVALID. - changed SCMI_AGENT_ID_INVALID from 0xff to UINT8_MAX which makes code more clear showing that UINT8_MAX is theated like invalid agent_id and couldn't be used. Also excluded SCMI_AGENT_ID_INVALID from acceptable value range - remove outdated xen,config property ignore, added xen,sci compatible to skip_matches in handle_node - add documentation for pre-existing scmi-smc-passthrough command line option in alphabetically correct location (in 's' section) - add note to commit description about documentation for previously undocumented scmi-smc-passthrough - Fix SMC IDs in DT examples (Xen management uses 0x82000003, Dom0 uses 0x8= 2000002) - Add explicit note explaining why Dom0 and Xen channels do not conflict - Document dom0less multi-agent configuration example (xen,sci_type / xen,s= ci-agent-id) - Add scmi_xen node to agent-discovery example with #scmi-secondary-agents-= cells =3D 2 - Drop dom0=3Dsci-agent-id command line handling; Dom0 SCMI is now enabled = via xen,dom0-sci-agent-id in the xen,sci DT container - Refresh docs and examples to mention the DT property instead of the cmdli= ne option Changes in v7: - rework scmi nodes for xen to match on compatible string instead of the direct path Changes in v6: - updated scmi-shmem to use io.h from generic location - update scmi_agent_id parameter to be provided inside dom0=3D parameter list and have the following format "dom0=3Dsci-agent-id=3D0" This change was done as a response for Stefano comment and requires a lot of code changes, but produces much cleaner solution that's why I've added it to the code. - fix file comments and return codes - fix lenght checks in shmem_{get,put}_message to use offsetof - remove len member from scmi_channel structure as it is not used - set scmi-secondary-agents property to be mandatory since if no secondary agents were provided then there is no sence to enable scmi when no secondary agents are populated to the Domains - update documentation in booting.txt, added xen_scmi node to the example - adjust d->arch.sci_enabled value in scmi_domain_destroy - fix lock management in smc_create_channel call - avoid extra map_channel_memory command for Xen management channel because collect_agent_id call unmaps memory if DOMID_XEN is not set. So for Xen management channel we can init domain_id ad DOMID_XEN before calling collect_agent_id so memory shouldn't be unmapped. Changes in v5: - fix device-tree example format in booting.txt, added ";" after "}". - update define in scmi-proto.h - update define in scmi-shmem.h file - scmi_assign_device - do not ignore -EOPNOTSUPP return code of the do_smc_xfer - remove overwriting agent_channel->agent_id after SCMI_BASE_DISCOVER_AGENT call - add multi-agent files to the MAINTAINERS - add SCMI multi-agent description to the SUPPORT.md - handle ARM_SMCCC_INVALID_PARAMETER return code and return -EINVAL for smc call - updated collect_agents function. Set agent_id parameter as optional in scmi-secondary-agents device-tree property - introduce "#scmi-secondary-agents-cells" parameter to set if agent_id was provided - reanme xen,scmi-secondary-agents property to scmi-secondary-agents - move memcpu_toio/fromio for the generic place - update Xen to get management channel from /chosen/xen,config node - get hypervisor channnel from node instead of using hardcoded - update handling scmi and shmem nodes for the domain - Set multi-agent driver to support only Arm64 Changes in v4: - toolstack comments from Anthony PERARD - added dom0less support - added doc for "xen,scmi-secondary-agents" MAINTAINERS | 4 + SUPPORT.md | 11 + docs/man/xl.cfg.5.pod.in | 13 + docs/misc/arm/device-tree/booting.txt | 196 +++++ docs/misc/xen-command-line.pandoc | 2 +- tools/libs/light/libxl_arm.c | 4 + tools/libs/light/libxl_types.idl | 4 +- tools/xl/xl_parse.c | 12 + xen/arch/arm/dom0less-build.c | 11 + xen/arch/arm/domain_build.c | 41 +- xen/arch/arm/firmware/Kconfig | 12 + xen/arch/arm/firmware/Makefile | 1 + xen/arch/arm/firmware/scmi-proto.h | 164 ++++ xen/arch/arm/firmware/scmi-shmem.c | 115 +++ xen/arch/arm/firmware/scmi-shmem.h | 45 ++ xen/arch/arm/firmware/scmi-smc-multiagent.c | 813 ++++++++++++++++++++ xen/include/public/arch-arm.h | 3 + 17 files changed, 1448 insertions(+), 3 deletions(-) create mode 100644 xen/arch/arm/firmware/scmi-proto.h create mode 100644 xen/arch/arm/firmware/scmi-shmem.c create mode 100644 xen/arch/arm/firmware/scmi-shmem.h create mode 100644 xen/arch/arm/firmware/scmi-smc-multiagent.c diff --git a/MAINTAINERS b/MAINTAINERS index bf00be928c..a6802d5970 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -530,6 +530,10 @@ R: Oleksii Moisieiev S: Supported F: xen/arch/arm/firmware/sci.c F: xen/arch/arm/include/asm/firmware/sci.h +F: xen/arch/arm/firmware/scmi-smc-multiagent.c +F: xen/arch/arm/firmware/scmi-shmem.c +F: xen/arch/arm/firmware/scmi-shmem.h +F: xen/arch/arm/firmware/scmi-proto.h =20 SEABIOS UPSTREAM M: Wei Liu diff --git a/SUPPORT.md b/SUPPORT.md index d441bccf37..03e3985da2 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -956,6 +956,17 @@ by hwdom. Some platforms use SCMI for access to system= -level resources. =20 Status: Supported =20 +### Arm: SCMI SMC multi-agent support + +Enable support for the multi-agent configuration of the EL3 Firmware, whic= h +allows Xen to provide an SCMI interface to the Domains. +Xen manages access permissions to the HW resources and provides an SCMI in= terface +to the Domains. Each Domain is represented as a separate Agent, which can +communicate with EL3 Firmware using a dedicated shared memory region, and +notifications are passed through by Xen. + + Status, ARM64: Tech Preview + ### ARM: Guest PSCI support =20 Emulated PSCI interface exposed to guests. We support all mandatory diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in index 27c455210b..6943ae29ad 100644 --- a/docs/man/xl.cfg.5.pod.in +++ b/docs/man/xl.cfg.5.pod.in @@ -3156,8 +3156,21 @@ single SCMI OSPM agent support. Should be used together with B Xen command line option. =20 +=3Ditem B + +Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI ov= er +SMC calls forwarding from domain to the EL3 firmware (like Trusted Firmwar= e-A) +with a multi SCMI OSPM agent support. The SCMI B should be +specified for the guest. + =3Dback =20 +=3Ditem B + +Specifies a non-zero ARM SCI agent id for the guest. This option is mandat= ory +if the SCMI SMC support is enabled for the guest. The agent ids of domains +existing on a single host must be unique and in the range [1..255]. + =3Dback =20 =3Dback diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-t= ree/booting.txt index 977b428608..6b88dae347 100644 --- a/docs/misc/arm/device-tree/booting.txt +++ b/docs/misc/arm/device-tree/booting.txt @@ -322,6 +322,20 @@ with the following properties: Should be used together with scmi-smc-passthrough Xen command line option. =20 + - "scmi_smc_multiagent" + + Enables ARM SCMI SMC multi-agent support for the guest by enabling SCM= I over + SMC calls forwarding from domain to the EL3 firmware (like ARM + Trusted Firmware-A) with a multi SCMI OSPM agent support. + The SCMI agent_id should be specified for the guest with "xen,sci-agen= t-id" + property. + +- "xen,sci-agent-id" + + Specifies ARM SCMI agent id for the guest. This option is mandatory if= the + SCMI SMC "scmi_smc_multiagent" support is enabled for the guest. The a= gent ids + of guest must be unique and in the range [0..255]. + Under the "xen,domain" compatible node, one or more sub-nodes are present for the DomU kernel and ramdisk. =20 @@ -824,3 +838,185 @@ The automatically allocated static shared memory will= get mapped at 0x80000000 in DomU1 guest physical address space, and at 0x90000000 in Dom= U2 guest physical address space. DomU1 is explicitly defined as the owner dom= ain, and DomU2 is the borrower domain. + +SCMI SMC multi-agent support +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D + +For enabling the ARM SCMI SMC multi-agent support (enabled by CONFIG_SCMI_= SMC_MA) +the Xen specific SCMI Agent's configuration shall be provided in the Host = DT +according to the SCMI compliant EL3 Firmware specification with ARM SMC/HV= C +transport. The SCMI configuration must live under the Xen SCMI container +"xen,sci" beneath "/chosen" (for example "/chosen/xen/xen_scmi_config/scmi= "). The +Xen SCMI mediator will bind only to the "arm,scmi-smc" node that is a chil= d of +this "xen,sci" container; any other "arm,scmi-smc" nodes (for example unde= r +"/firmware") are ignored to avoid stealing the host's SCMI OSPM instance. + +- scmi-secondary-agents + + Defines a set of SCMI agents configuration supported by SCMI EL3 FW an= d + available for Xen. Each Agent defined as triple consisting of: + SMC/HVC function_id assigned for the agent transport ("arm,smc-id"), + phandle to SCMI SHM assigned for the agent transport ("arm,scmi-shmem"= ), + SCMI agent_id (optional) if not set - Xen will determine Agent ID for + each provided channel using BASE_DISCOVER_AGENT message. + +- xen,dom0-sci-agent-id + + Optional. Specifies the Dom0/hwdom SCMI agent_id inside the ``xen,sci`= ` + container. When provided, Dom0 will be configured for SCMI multi-agent + support; when omitted, SCMI remains disabled for Dom0. The value must + match the ``func_id`` and shmem pairing that EL3 firmware exposes for + Dom0 (for example via ``/firmware/scmi``). + +As an example: + +/ { + chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + + scmi_shm_0: sram@47ff0000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff0000 0x0 0x1000>; + }; + + /* Xen SCMI management channel */ + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + + scmi_shm_2: sram@47ff2000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff2000 0x0 0x1000>; + }; + + scmi_shm_3: sram@47ff3000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff3000 0x0 0x1000>; + }; + + xen,dom0-sci-agent-id =3D <0>; <--- dom0 agent id + scmi-secondary-agents =3D < + 0x82000002 &scmi_shm_0 0 + 0x82000004 &scmi_shm_2 2 + 0x82000005 &scmi_shm_3 3>; <--- func_id, shmem, agent_= id + #scmi-secondary-agents-cells =3D <3>; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; <--- Xen management agent= func_id + #address-cells =3D <1>; + #size-cells =3D <0>; + #access-controller-cells =3D <1>; + shmem =3D <&scmi_shm_1>; <--- Xen management agent shm= em + }; + }; + }; + }; +}; + +Note: This example keeps the Host DT unchanged for Dom0 and baremetal Linu= x +by using func_id 0x82000002 / shmem 0x47ff0000 for Dom0, while Xen uses a +separate privileged channel func_id 0x82000003 / shmem 0x47ff1000. EL3 +firmware enforces permissions per agent_id, so there is no conflict betwee= n +Dom0 and Xen channels. + +- #scmi-secondary-agents-cells + + Defines whether Agent_id is set in the "scmi-secondary-agents" propert= y. + Possible values are: 2, 3. + When set to 3 (the default), expect agent_id to be present in the seco= ndary + agents list. + When set to 2, agent_id will be discovered for each channel using + BASE_DISCOVER_AGENT message. + + +Example: + +/ { + chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + + /* Shared memory nodes as in the previous example */ + + scmi-secondary-agents =3D < + 0x82000002 &scmi_shm_0 + 0x82000004 &scmi_shm_2 + 0x82000005 &scmi_shm_3 + 0x82000006 &scmi_shm_4>; + #scmi-secondary-agents-cells =3D <2>; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; <--- Xen management agent= func_id + #address-cells =3D <1>; + #size-cells =3D <0>; + #access-controller-cells =3D <1>; + shmem =3D <&scmi_shm_1>; <--- Xen management agent shm= em + }; + }; + }; + }; +}; + +Dom0less example (multi-agent) +------------------------------- + +Below is a minimal dom0less configuration showing how to enable SCMI SMC +multi-agent for a pre-defined guest domain using xen,sci_type and +xen,sci-agent-id, together with the Xen SCMI container: + +chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + + /* Xen management channel shared memory */ + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + + scmi_shm_domu: sram@47ff2000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff2000 0x0 0x1000>; + }; + + scmi-secondary-agents =3D < + 0x82000004 &scmi_shm_domu 2>; + #scmi-secondary-agents-cells =3D <3>; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; + #address-cells =3D <1>; + #size-cells =3D <0>; + #access-controller-cells =3D <1>; + shmem =3D <&scmi_shm_1>; + }; + }; + }; + + xen,domain@1 { + compatible =3D "xen,domain"; + xen,sci_type =3D "scmi_smc_multiagent"; + xen,sci-agent-id =3D <2>; + /* Additional domain properties (memory, cpus, kernels, etc.) */ + }; +}; diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line= .pandoc index 15f7a315a4..268df3010b 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -789,7 +789,7 @@ Specify the bit width of the DMA heap. cpuid-faulting=3D, msr-relaxed=3D, pf-fixup=3D ] (x86) =20 - =3D List of [ sve=3D ] (Arm64) + =3D List of [ sve=3D ] (Arm) =20 Controls for how dom0 is constructed on x86 systems. =20 diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c index e4407d6e3f..be0e6263ae 100644 --- a/tools/libs/light/libxl_arm.c +++ b/tools/libs/light/libxl_arm.c @@ -240,6 +240,10 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc, case LIBXL_ARM_SCI_TYPE_SCMI_SMC: config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; break; + case LIBXL_ARM_SCI_TYPE_SCMI_SMC_MULTIAGENT: + config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_M= A; + config->arch.arm_sci_agent_id =3D d_config->b_info.arch_arm.arm_sc= i.agent_id; + break; default: LOG(ERROR, "Unknown ARM_SCI type %d", d_config->b_info.arch_arm.arm_sci.type); diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_type= s.idl index 4a958f69f4..9bfbf09145 100644 --- a/tools/libs/light/libxl_types.idl +++ b/tools/libs/light/libxl_types.idl @@ -554,11 +554,13 @@ libxl_sve_type =3D Enumeration("sve_type", [ =20 libxl_arm_sci_type =3D Enumeration("arm_sci_type", [ (0, "none"), - (1, "scmi_smc") + (1, "scmi_smc"), + (2, "scmi_smc_multiagent") ], init_val =3D "LIBXL_ARM_SCI_TYPE_NONE") =20 libxl_arm_sci =3D Struct("arm_sci", [ ("type", libxl_arm_sci_type), + ("agent_id", uint8) ]) =20 libxl_rdm_reserve =3D Struct("rdm_reserve", [ diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c index 1cc41f1bff..0c389d25f9 100644 --- a/tools/xl/xl_parse.c +++ b/tools/xl/xl_parse.c @@ -1306,6 +1306,18 @@ static int parse_arm_sci_config(XLU_Config *cfg, lib= xl_arm_sci *arm_sci, } } =20 + if (MATCH_OPTION("agent_id", ptr, oparg)) { + unsigned long val =3D parse_ulong(oparg); + + if (!val || val > 255) { + fprintf(stderr, "An invalid ARM_SCI agent_id specified (%l= u). Valid range [1..255]\n", + val); + ret =3D ERROR_INVAL; + goto out; + } + arm_sci->agent_id =3D val; + } + ptr =3D strtok(NULL, ","); } =20 diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index 4181c10538..ddadc89148 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -299,6 +299,17 @@ static int __init domu_dt_sci_parse(struct dt_device_n= ode *node, d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE; else if ( !strcmp(sci_type, "scmi_smc") ) d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; + else if ( !strcmp(sci_type, "scmi_smc_multiagent") ) + { + uint32_t agent_id =3D 0; + + if ( !dt_property_read_u32(node, "xen,sci-agent-id", &agent_id) || + agent_id > UINT8_MAX ) + return -EINVAL; + + d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA= ; + d_cfg->arch.arm_sci_agent_id =3D agent_id; + } else { printk(XENLOG_ERR "xen,sci_type in not valid (%s) for domain %s\n"= , diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 986a456f17..0796561306 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -86,6 +86,37 @@ int __init parse_arch_dom0_param(const char *s, const ch= ar *e) return -EINVAL; } =20 +/* SCMI agent ID for dom0 obtained from xen,sci container */ +#define SCMI_AGENT_ID_INVALID UINT8_MAX + +static uint8_t __init get_dom0_scmi_agent_id(void) +{ + const struct dt_device_node *config_node; + u32 val; + const struct dt_property *prop; + + config_node =3D dt_find_compatible_node(NULL, NULL, "xen,sci"); + if ( !config_node ) + return SCMI_AGENT_ID_INVALID; + + prop =3D dt_find_property(config_node, "xen,dom0-sci-agent-id", NULL); + if ( !prop ) + return SCMI_AGENT_ID_INVALID; + + if ( !dt_property_read_u32(config_node, "xen,dom0-sci-agent-id", &val)= ) + return SCMI_AGENT_ID_INVALID; + + if ( val >=3D SCMI_AGENT_ID_INVALID ) + { + printk(XENLOG_WARNING + "Invalid xen,dom0-sci-agent-id=3D%u, SCMI disabled for Dom0\n= ", + val); + return SCMI_AGENT_ID_INVALID; + } + + return val; +} + /* Override macros from asm/page.h to make them work with mfn_t */ #undef virt_to_mfn #define virt_to_mfn(va) _mfn(__virt_to_mfn(va)) @@ -509,7 +540,7 @@ static int __init write_properties(struct domain *d, st= ruct kernel_info *kinfo, dt_property_name_is_equal(prop, "linux,uefi-mmap-start") = || dt_property_name_is_equal(prop, "linux,uefi-mmap-size") |= | dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-siz= e") || - dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-ver= ")) + dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-ver= ") ) continue; =20 if ( dt_property_name_is_equal(prop, "xen,dom0-bootargs") ) @@ -1459,6 +1490,7 @@ static int __init handle_node(struct domain *d, struc= t kernel_info *kinfo, DT_MATCH_TYPE("memory"), /* The memory mapped timer is not supported by Xen. */ DT_MATCH_COMPATIBLE("arm,armv7-timer-mem"), + DT_MATCH_COMPATIBLE("xen,sci"), { /* sentinel */ }, }; static const struct dt_device_match timer_matches[] __initconst =3D @@ -1947,6 +1979,13 @@ void __init create_dom0(void) dom0_cfg.arch.tee_type =3D tee_get_type(); dom0_cfg.max_vcpus =3D dom0_max_vcpus(); =20 + /* Set up SCMI agent ID if provided in the xen,sci container */ + dom0_cfg.arch.arm_sci_agent_id =3D get_dom0_scmi_agent_id(); + dom0_cfg.arch.arm_sci_type =3D (dom0_cfg.arch.arm_sci_agent_id !=3D + SCMI_AGENT_ID_INVALID) ? + XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA : + XEN_DOMCTL_CONFIG_ARM_SCI_NONE; + if ( iommu_enabled ) dom0_cfg.flags |=3D XEN_DOMCTL_CDF_iommu; =20 diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig index 5c5f0880c4..972cd9b173 100644 --- a/xen/arch/arm/firmware/Kconfig +++ b/xen/arch/arm/firmware/Kconfig @@ -29,6 +29,18 @@ config SCMI_SMC driver domain. Use with EL3 firmware which supports only single SCMI OSPM agent. =20 +config SCMI_SMC_MA + bool "Enable ARM SCMI SMC multi-agent driver" + depends on ARM_64 + select ARM_SCI + help + Enables SCMI SMC/HVC multi-agent in XEN to pass SCMI requests from Doma= ins + to EL3 firmware (TF-A) which supports multi-agent feature. + This feature allows to enable SCMI per Domain using unique SCMI agent_i= d, + so Domain is identified by EL3 firmware as an SCMI Agent and can access + allowed platform resources through dedicated SMC/HVC Shared memory base= d + transport. + endchoice =20 endmenu diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefil= e index 71bdefc24a..37927e690e 100644 --- a/xen/arch/arm/firmware/Makefile +++ b/xen/arch/arm/firmware/Makefile @@ -1,2 +1,3 @@ obj-$(CONFIG_ARM_SCI) +=3D sci.o obj-$(CONFIG_SCMI_SMC) +=3D scmi-smc.o +obj-$(CONFIG_SCMI_SMC_MA) +=3D scmi-shmem.o scmi-smc-multiagent.o diff --git a/xen/arch/arm/firmware/scmi-proto.h b/xen/arch/arm/firmware/scm= i-proto.h new file mode 100644 index 0000000000..49f63cfc0a --- /dev/null +++ b/xen/arch/arm/firmware/scmi-proto.h @@ -0,0 +1,164 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Arm System Control and Management Interface definitions + * Version 3.0 (DEN0056C) + * + * Copyright (c) 2025 EPAM Systems + */ + +#ifndef ARM_FIRMWARE_SCMI_PROTO_H_ +#define ARM_FIRMWARE_SCMI_PROTO_H_ + +#include + +#define SCMI_SHORT_NAME_MAX_SIZE 16 + +/* SCMI status codes. See section 4.1.4 */ +#define SCMI_SUCCESS 0 +#define SCMI_NOT_SUPPORTED (-1) +#define SCMI_INVALID_PARAMETERS (-2) +#define SCMI_DENIED (-3) +#define SCMI_NOT_FOUND (-4) +#define SCMI_OUT_OF_RANGE (-5) +#define SCMI_BUSY (-6) +#define SCMI_COMMS_ERROR (-7) +#define SCMI_GENERIC_ERROR (-8) +#define SCMI_HARDWARE_ERROR (-9) +#define SCMI_PROTOCOL_ERROR (-10) + +/* Protocol IDs */ +#define SCMI_BASE_PROTOCOL 0x10 + +/* Base protocol message IDs */ +#define SCMI_BASE_PROTOCOL_VERSION 0x0 +#define SCMI_BASE_PROTOCOL_ATTIBUTES 0x1 +#define SCMI_BASE_PROTOCOL_MESSAGE_ATTRIBUTES 0x2 +#define SCMI_BASE_DISCOVER_AGENT 0x7 +#define SCMI_BASE_SET_DEVICE_PERMISSIONS 0x9 +#define SCMI_BASE_RESET_AGENT_CONFIGURATION 0xB + +typedef struct scmi_msg_header { + uint8_t id; + uint8_t type; + uint8_t protocol; + uint32_t status; +} scmi_msg_header_t; + +/* Table 2 Message header format */ +#define SCMI_HDR_ID GENMASK(7, 0) +#define SCMI_HDR_TYPE GENMASK(9, 8) +#define SCMI_HDR_PROTO GENMASK(17, 10) + +#define SCMI_FIELD_GET(_mask, _reg) = \ + ((typeof(_mask))(((_reg) & (_mask)) >> (ffs64(_mask) - 1))) +#define SCMI_FIELD_PREP(_mask, _val) = \ + (((typeof(_mask))(_val) << (ffs64(_mask) - 1)) & (_mask)) + +static inline uint32_t pack_scmi_header(scmi_msg_header_t *hdr) +{ + return SCMI_FIELD_PREP(SCMI_HDR_ID, hdr->id) | + SCMI_FIELD_PREP(SCMI_HDR_TYPE, hdr->type) | + SCMI_FIELD_PREP(SCMI_HDR_PROTO, hdr->protocol); +} + +static inline void unpack_scmi_header(uint32_t msg_hdr, scmi_msg_header_t = *hdr) +{ + hdr->id =3D SCMI_FIELD_GET(SCMI_HDR_ID, msg_hdr); + hdr->type =3D SCMI_FIELD_GET(SCMI_HDR_TYPE, msg_hdr); + hdr->protocol =3D SCMI_FIELD_GET(SCMI_HDR_PROTO, msg_hdr); +} + +static inline int scmi_to_xen_errno(int scmi_status) +{ + if ( scmi_status =3D=3D SCMI_SUCCESS ) + return 0; + + switch ( scmi_status ) + { + case SCMI_NOT_SUPPORTED: + return -EOPNOTSUPP; + case SCMI_INVALID_PARAMETERS: + return -EINVAL; + case SCMI_DENIED: + return -EACCES; + case SCMI_NOT_FOUND: + return -ENOENT; + case SCMI_OUT_OF_RANGE: + return -ERANGE; + case SCMI_BUSY: + return -EBUSY; + case SCMI_COMMS_ERROR: + return -ENOTCONN; + case SCMI_GENERIC_ERROR: + return -EIO; + case SCMI_HARDWARE_ERROR: + return -ENXIO; + case SCMI_PROTOCOL_ERROR: + return -EBADMSG; + default: + return -EINVAL; + } +} + +/* PROTOCOL_VERSION */ +#define SCMI_VERSION_MINOR GENMASK(15, 0) +#define SCMI_VERSION_MAJOR GENMASK(31, 16) + +struct scmi_msg_prot_version_p2a { + uint32_t version; +} __packed; + +/* BASE PROTOCOL_ATTRIBUTES */ +#define SCMI_BASE_ATTR_NUM_PROTO GENMASK(7, 0) +#define SCMI_BASE_ATTR_NUM_AGENT GENMASK(15, 8) + +struct scmi_msg_base_attributes_p2a { + uint32_t attributes; +} __packed; + +/* + * BASE_DISCOVER_AGENT + */ +#define SCMI_BASE_AGENT_ID_OWN 0xFFFFFFFF + +struct scmi_msg_base_discover_agent_a2p { + uint32_t agent_id; +} __packed; + +struct scmi_msg_base_discover_agent_p2a { + uint32_t agent_id; + char name[SCMI_SHORT_NAME_MAX_SIZE]; +} __packed; + +/* + * BASE_SET_DEVICE_PERMISSIONS + */ +#define SCMI_BASE_DEVICE_ACCESS_ALLOW BIT(0, UL) + +struct scmi_msg_base_set_device_permissions_a2p { + uint32_t agent_id; + uint32_t device_id; + uint32_t flags; +} __packed; + +/* + * BASE_RESET_AGENT_CONFIGURATION + */ +#define SCMI_BASE_AGENT_PERMISSIONS_RESET BIT(0, UL) + +struct scmi_msg_base_reset_agent_cfg_a2p { + uint32_t agent_id; + uint32_t flags; +} __packed; + +#endif /* ARM_FIRMWARE_SCMI_PROTO_H_ */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/firmware/scmi-shmem.c b/xen/arch/arm/firmware/scm= i-shmem.c new file mode 100644 index 0000000000..112507ba2a --- /dev/null +++ b/xen/arch/arm/firmware/scmi-shmem.c @@ -0,0 +1,115 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * SMC/HVC shmem transport implementation used by + * SCI SCMI multi-agent driver. + * + * Oleksii Moisieiev + * Copyright (c) 2025 EPAM Systems + */ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include +#include +#include + +#include "scmi-proto.h" +#include "scmi-shmem.h" + +static inline int +shmem_channel_is_free(const volatile struct scmi_shared_mem __iomem *shmem= ) +{ + return (readl(&shmem->channel_status) & + SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE) ? 0 : -EBUSY; +} + +int shmem_put_message(volatile struct scmi_shared_mem __iomem *shmem, + scmi_msg_header_t *hdr, void *data, int len) +{ + int ret; + + if ( (len + offsetof(struct scmi_shared_mem, msg_payload)) > + SCMI_SHMEM_MAPPED_SIZE ) + { + printk(XENLOG_ERR "scmi: Wrong size of smc message. Data is invali= d\n"); + return -EINVAL; + } + + ret =3D shmem_channel_is_free(shmem); + if ( ret ) + return ret; + + writel_relaxed(0x0, &shmem->channel_status); + /* Writing 0x0 right now, but "shmem"_FLAG_INTR_ENABLED can be set */ + writel_relaxed(0x0, &shmem->flags); + writel_relaxed(sizeof(shmem->msg_header) + len, &shmem->length); + writel(pack_scmi_header(hdr), &shmem->msg_header); + + if ( len > 0 && data ) + memcpy_toio(shmem->msg_payload, data, len); + + return 0; +} + +int shmem_get_response(const volatile struct scmi_shared_mem __iomem *shme= m, + scmi_msg_header_t *hdr, void *data, int len) +{ + int recv_len; + int ret; + int pad =3D sizeof(hdr->status); + + if ( len >=3D SCMI_SHMEM_MAPPED_SIZE - + offsetof(struct scmi_shared_mem, msg_payload) ) + { + printk(XENLOG_ERR + "scmi: Wrong size of input smc message. Data may be invalid= \n"); + return -EINVAL; + } + + ret =3D shmem_channel_is_free(shmem); + if ( ret ) + return ret; + + recv_len =3D readl(&shmem->length) - sizeof(shmem->msg_header); + + if ( recv_len < 0 ) + { + printk(XENLOG_ERR + "scmi: Wrong size of smc message. Data may be invalid\n"); + return -EINVAL; + } + + unpack_scmi_header(readl(&shmem->msg_header), hdr); + + hdr->status =3D readl(&shmem->msg_payload); + recv_len =3D recv_len > pad ? recv_len - pad : 0; + + ret =3D scmi_to_xen_errno(hdr->status); + if ( ret ) + { + printk(XENLOG_DEBUG "scmi: Error received: %d\n", ret); + return ret; + } + + if ( recv_len > len ) + { + printk(XENLOG_ERR + "scmi: Not enough buffer for message %d, expecting %d\n", + recv_len, len); + return -EINVAL; + } + + if ( recv_len > 0 ) + memcpy_fromio(data, shmem->msg_payload + pad, recv_len); + + return 0; +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/firmware/scmi-shmem.h b/xen/arch/arm/firmware/scm= i-shmem.h new file mode 100644 index 0000000000..7313cb6b26 --- /dev/null +++ b/xen/arch/arm/firmware/scmi-shmem.h @@ -0,0 +1,45 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Arm System Control and Management Interface definitions + * Version 3.0 (DEN0056C) + * Shared Memory based Transport + * + * Copyright (c) 2024 EPAM Systems + */ + +#ifndef ARM_FIRMWARE_SCMI_SHMEM_H_ +#define ARM_FIRMWARE_SCMI_SHMEM_H_ + +#include + +#define SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE BIT(0, UL) +#define SCMI_SHMEM_CHAN_STAT_CHANNEL_ERROR BIT(1, UL) + +struct scmi_shared_mem { + uint32_t reserved; + uint32_t channel_status; + uint32_t reserved1[2]; + uint32_t flags; + uint32_t length; + uint32_t msg_header; + uint8_t msg_payload[]; +}; + +#define SCMI_SHMEM_MAPPED_SIZE PAGE_SIZE + +int shmem_put_message(volatile struct scmi_shared_mem __iomem *shmem, + scmi_msg_header_t *hdr, void *data, int len); + +int shmem_get_response(const volatile struct scmi_shared_mem __iomem *shme= m, + scmi_msg_header_t *hdr, void *data, int len); +#endif /* ARM_FIRMWARE_SCMI_SHMEM_H_ */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/firmware/scmi-smc-multiagent.c b/xen/arch/arm/fir= mware/scmi-smc-multiagent.c new file mode 100644 index 0000000000..8f68063be9 --- /dev/null +++ b/xen/arch/arm/firmware/scmi-smc-multiagent.c @@ -0,0 +1,813 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * SCI SCMI multi-agent driver, using SMC/HVC shmem as transport. + * + * Oleksii Moisieiev + * Copyright (c) 2025 EPAM Systems + */ + +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include "scmi-proto.h" +#include "scmi-shmem.h" + +#define SCMI_SECONDARY_AGENTS "scmi-secondary-agents" + +struct scmi_channel { + uint32_t agent_id; + uint32_t func_id; + domid_t domain_id; + uint64_t paddr; + struct scmi_shared_mem __iomem *shmem; + spinlock_t lock; + struct list_head list; +}; + +struct scmi_data { + struct list_head channel_list; + spinlock_t channel_list_lock; + uint32_t func_id; + bool initialized; + uint32_t shmem_phandle; + uint32_t hyp_channel_agent_id; + struct dt_device_node *dt_dev; +}; + +static struct scmi_data scmi_data; + +static bool scmi_is_under_xen_sci(const struct dt_device_node *node) +{ + const struct dt_device_node *p; + + for ( p =3D node->parent; p; p =3D p->parent ) + if ( dt_device_is_compatible(p, "xen,sci") ) + return true; + + return false; +} + +static int send_smc_message(struct scmi_channel *chan_info, + scmi_msg_header_t *hdr, void *data, int len) +{ + struct arm_smccc_res resp; + int ret; + + ret =3D shmem_put_message(chan_info->shmem, hdr, data, len); + if ( ret ) + return ret; + + arm_smccc_1_1_smc(chan_info->func_id, 0, 0, 0, 0, 0, 0, 0, &resp); + + if ( resp.a0 =3D=3D ARM_SMCCC_INVALID_PARAMETER ) + return -EINVAL; + + if ( resp.a0 ) + return -EOPNOTSUPP; + + return 0; +} + +static int do_smc_xfer(struct scmi_channel *chan_info, scmi_msg_header_t *= hdr, + void *tx_data, int tx_size, void *rx_data, int rx_s= ize) +{ + int ret =3D 0; + + ASSERT(chan_info && chan_info->shmem); + + if ( !hdr ) + return -EINVAL; + + spin_lock(&chan_info->lock); + + printk(XENLOG_DEBUG + "scmi: agent_id =3D %d msg_id =3D %x type =3D %d, proto =3D %x\= n", + chan_info->agent_id, hdr->id, hdr->type, hdr->protocol); + + ret =3D send_smc_message(chan_info, hdr, tx_data, tx_size); + if ( ret ) + goto clean; + + ret =3D shmem_get_response(chan_info->shmem, hdr, rx_data, rx_size); + +clean: + printk(XENLOG_DEBUG + "scmi: get smc response agent_id =3D %d msg_id =3D %x proto =3D= %x res=3D%d\n", + chan_info->agent_id, hdr->id, hdr->protocol, ret); + + spin_unlock(&chan_info->lock); + + return ret; +} + +static struct scmi_channel *get_channel_by_id(uint32_t agent_id) +{ + struct scmi_channel *curr; + bool found =3D false; + + spin_lock(&scmi_data.channel_list_lock); + list_for_each_entry(curr, &scmi_data.channel_list, list) + { + if ( curr->agent_id =3D=3D agent_id ) + { + found =3D true; + break; + } + } + + spin_unlock(&scmi_data.channel_list_lock); + if ( found ) + return curr; + + return NULL; +} + +static struct scmi_channel *acquire_scmi_channel(struct domain *d, + uint32_t agent_id) +{ + struct scmi_channel *curr; + struct scmi_channel *ret =3D ERR_PTR(-ENOENT); + + spin_lock(&scmi_data.channel_list_lock); + list_for_each_entry(curr, &scmi_data.channel_list, list) + { + if ( curr->agent_id =3D=3D agent_id ) + { + if ( curr->domain_id !=3D DOMID_INVALID ) + { + ret =3D ERR_PTR(-EEXIST); + break; + } + + curr->domain_id =3D d->domain_id; + ret =3D curr; + break; + } + } + + spin_unlock(&scmi_data.channel_list_lock); + + return ret; +} + +static void relinquish_scmi_channel(struct scmi_channel *channel) +{ + ASSERT(channel !=3D NULL); + + spin_lock(&scmi_data.channel_list_lock); + channel->domain_id =3D DOMID_INVALID; + spin_unlock(&scmi_data.channel_list_lock); +} + +static int map_channel_memory(struct scmi_channel *channel) +{ + ASSERT(channel && channel->paddr); + channel->shmem =3D ioremap_nocache(channel->paddr, SCMI_SHMEM_MAPPED_S= IZE); + if ( !channel->shmem ) + return -ENOMEM; + + channel->shmem->channel_status =3D SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE; + printk(XENLOG_DEBUG "scmi: Got shmem %lx after vmap %p\n", channel->pa= ddr, + channel->shmem); + + return 0; +} + +static void unmap_channel_memory(struct scmi_channel *channel) +{ + ASSERT(channel && channel->shmem); + iounmap(channel->shmem); + channel->shmem =3D NULL; +} + +static struct scmi_channel *smc_create_channel(uint32_t agent_id, + uint32_t func_id, uint64_t = addr) +{ + struct scmi_channel *channel, *curr; + + spin_lock(&scmi_data.channel_list_lock); + + /* Check if channel already exists while holding the lock */ + list_for_each_entry(curr, &scmi_data.channel_list, list) + { + if ( curr->agent_id =3D=3D agent_id ) + { + spin_unlock(&scmi_data.channel_list_lock); + return ERR_PTR(-EEXIST); + } + } + + channel =3D xmalloc(struct scmi_channel); + if ( !channel ) + { + spin_unlock(&scmi_data.channel_list_lock); + return ERR_PTR(-ENOMEM); + } + + spin_lock_init(&channel->lock); + channel->agent_id =3D agent_id; + channel->func_id =3D func_id; + channel->domain_id =3D DOMID_INVALID; + channel->shmem =3D NULL; + channel->paddr =3D addr; + list_add_tail(&channel->list, &scmi_data.channel_list); + + spin_unlock(&scmi_data.channel_list_lock); + return channel; +} + +static void free_channel_list(void) +{ + struct scmi_channel *curr, *_curr; + + list_for_each_entry_safe(curr, _curr, &scmi_data.channel_list, list) + { + list_del(&curr->list); + xfree(curr); + } +} + +static int __init +scmi_dt_read_hyp_channel_addr(struct dt_device_node *scmi_node, u64 *addr, + u64 *size) +{ + struct dt_device_node *shmem_node; + const __be32 *prop; + + prop =3D dt_get_property(scmi_node, "shmem", NULL); + if ( !prop ) + return -EINVAL; + + shmem_node =3D dt_find_node_by_phandle(be32_to_cpu(*prop)); + if ( IS_ERR_OR_NULL(shmem_node) ) + { + printk(XENLOG_ERR + "scmi: Device tree error, can't parse reserved memory %ld\n= ", + PTR_ERR(shmem_node)); + return PTR_ERR(shmem_node); + } + + return dt_device_get_address(shmem_node, 0, addr, size); +} + +/* + * Handle Dom0 SCMI specific DT nodes + * + * Make a decision on copying SCMI specific nodes into Dom0 device tree. + * For SCMI multi-agent case: + * - shmem nodes will not be copied and generated instead if SCMI + * is enabled for Dom0 + * - scmi node will be copied if SCMI is enabled for Dom0 + */ +static bool scmi_dt_handle_node(struct domain *d, struct dt_device_node *n= ode) +{ + 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 */ }, + }; + + if ( !scmi_data.initialized ) + return false; + + /* 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; + } + + /* drop scmi if not enabled */ + if ( dt_match_node(scmi_matches, node) && !sci_domain_is_enabled(d) ) + { + dt_dprintk(" Skip scmi node\n"); + return true; + } + + return false; +} + +static int scmi_assign_device(uint32_t agent_id, uint32_t device_id, + uint32_t flags) +{ + struct scmi_msg_base_set_device_permissions_a2p tx; + struct scmi_channel *channel; + scmi_msg_header_t hdr; + + channel =3D get_channel_by_id(scmi_data.hyp_channel_agent_id); + if ( !channel ) + return -EINVAL; + + hdr.id =3D SCMI_BASE_SET_DEVICE_PERMISSIONS; + hdr.type =3D 0; + hdr.protocol =3D SCMI_BASE_PROTOCOL; + + tx.agent_id =3D agent_id; + tx.device_id =3D device_id; + tx.flags =3D flags; + + return do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0); +} + +static int scmi_dt_assign_device(struct domain *d, + struct dt_phandle_args *ac_spec) +{ + struct scmi_channel *agent_channel; + uint32_t scmi_device_id =3D ac_spec->args[0]; + int ret; + + if ( !d->arch.sci_data ) + return 0; + + /* The access-controllers is specified for DT dev, but it's not a SCMI= */ + if ( ac_spec->np !=3D scmi_data.dt_dev ) + return 0; + + agent_channel =3D d->arch.sci_data; + + spin_lock(&agent_channel->lock); + + ret =3D scmi_assign_device(agent_channel->agent_id, scmi_device_id, + SCMI_BASE_DEVICE_ACCESS_ALLOW); + if ( ret ) + { + printk(XENLOG_ERR + "scmi: could not assign dev for %pd agent:%d dev_id:%u (%d)= ", + d, agent_channel->agent_id, scmi_device_id, ret); + } + + spin_unlock(&agent_channel->lock); + return ret; +} + +static int collect_agent_id(struct scmi_channel *agent_channel) +{ + int ret; + scmi_msg_header_t hdr; + struct scmi_msg_base_discover_agent_p2a da_rx; + struct scmi_msg_base_discover_agent_a2p da_tx; + + ret =3D map_channel_memory(agent_channel); + if ( ret ) + return ret; + + hdr.id =3D SCMI_BASE_DISCOVER_AGENT; + hdr.type =3D 0; + hdr.protocol =3D SCMI_BASE_PROTOCOL; + + da_tx.agent_id =3D agent_channel->agent_id; + + ret =3D do_smc_xfer(agent_channel, &hdr, &da_tx, sizeof(da_tx), &da_rx= , + sizeof(da_rx)); + if ( agent_channel->domain_id !=3D DOMID_XEN ) + unmap_channel_memory(agent_channel); + if ( ret ) + return ret; + + printk(XENLOG_DEBUG "id=3D0x%x name=3D%s\n", da_rx.agent_id, da_rx.nam= e); + agent_channel->agent_id =3D da_rx.agent_id; + return 0; +} + +static __init int collect_agents(struct dt_device_node *scmi_node) +{ + const struct dt_device_node *config_node; + const __be32 *prop; + uint32_t len; + const __be32 *end; + uint32_t cells_per_entry =3D 3; /* Default to 3 cells if property is a= bsent. */ + + config_node =3D dt_find_compatible_node(NULL, NULL, "xen,sci"); + if ( !config_node ) + { + printk(XENLOG_WARNING "scmi: xen,sci node not found, no agents to = collect.\n"); + return -ENOENT; + } + + /* Check for the optional '#scmi-secondary-agents-cells' property. */ + if ( dt_property_read_u32(config_node, "#scmi-secondary-agents-cells", + &cells_per_entry) ) + { + if ( cells_per_entry !=3D 2 && cells_per_entry !=3D 3 ) + { + printk(XENLOG_ERR "scmi: Invalid #scmi-secondary-agents-cells = value: %u\n", + cells_per_entry); + return -EINVAL; + } + } + + prop =3D dt_get_property(config_node, SCMI_SECONDARY_AGENTS, &len); + if ( !prop ) + { + printk(XENLOG_ERR "scmi: No %s property found, no agents to collec= t.\n", + SCMI_SECONDARY_AGENTS); + return -EINVAL; + } + + /* Validate that the property length is a multiple of the cell size. *= / + if ( len =3D=3D 0 || len % (cells_per_entry * sizeof(uint32_t)) !=3D 0= ) + { + printk(XENLOG_ERR "scmi: Invalid length of %s property: %u for %u = cells per entry\n", + SCMI_SECONDARY_AGENTS, len, cells_per_entry); + return -EINVAL; + } + + end =3D (const __be32 *)((const u8 *)prop + len); + + for ( ; prop < end; ) + { + uint32_t agent_id; + uint32_t smc_id; + uint32_t shmem_phandle; + struct dt_device_node *node; + u64 addr, size; + int ret; + struct scmi_channel *agent_channel; + + smc_id =3D be32_to_cpu(*prop++); + shmem_phandle =3D be32_to_cpu(*prop++); + + if ( cells_per_entry =3D=3D 3 ) + agent_id =3D be32_to_cpu(*prop++); + else + agent_id =3D SCMI_BASE_AGENT_ID_OWN; + + node =3D dt_find_node_by_phandle(shmem_phandle); + if ( !node ) + { + printk(XENLOG_ERR "scmi: Could not find shmem node for agent %= u\n", + agent_id); + return -EINVAL; + } + + ret =3D dt_device_get_address(node, 0, &addr, &size); + if ( ret ) + { + printk(XENLOG_ERR + "scmi: Could not read shmem address for agent %u: %d\n"= , + agent_id, ret); + return ret; + } + + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) ) + { + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); + return -EINVAL; + } + + agent_channel =3D smc_create_channel(agent_id, smc_id, addr); + if ( IS_ERR(agent_channel) ) + { + printk(XENLOG_ERR "scmi: Could not create channel for agent %u= : %ld\n", + agent_id, PTR_ERR(agent_channel)); + return PTR_ERR(agent_channel); + } + + if ( cells_per_entry =3D=3D 2 ) + { + ret =3D collect_agent_id(agent_channel); + if ( ret ) + return ret; + } + + printk(XENLOG_DEBUG "scmi: Agent %u SMC %X addr %lx\n", agent_chan= nel->agent_id, + smc_id, (unsigned long)addr); + } + + return 0; +} + +static int scmi_domain_init(struct domain *d, + struct xen_domctl_createdomain *config) +{ + struct scmi_channel *channel; + int ret; + + if ( !scmi_data.initialized ) + return 0; + + /* + * SCMI support is configured via: + * - For dom0: xen,dom0-sci-agent-id property under the xen,sci contai= ner + * - For dom0less: xen,sci-agent-id in the domain node + * The config->arch.arm_sci_type and config->arch.arm_sci_agent_id + * are already set by domain_build.c or dom0less-build.c + */ + + if ( config->arch.arm_sci_type =3D=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE ) + return 0; + + channel =3D acquire_scmi_channel(d, config->arch.arm_sci_agent_id); + if ( IS_ERR(channel) ) + { + printk(XENLOG_ERR + "scmi: Failed to acquire SCMI channel for agent_id %u: %ld\= n", + config->arch.arm_sci_agent_id, PTR_ERR(channel)); + return PTR_ERR(channel); + } + + printk(XENLOG_INFO + "scmi: Acquire channel id =3D 0x%x, domain_id =3D %d paddr =3D = 0x%lx\n", + channel->agent_id, channel->domain_id, channel->paddr); + + /* + * Dom0 (if present) needs to have an access to the guest memory range + * to satisfy iomem_access_permitted() check in XEN_DOMCTL_iomem_permi= ssion + * domctl. + */ + if ( hardware_domain && !is_hardware_domain(d) ) + { + ret =3D iomem_permit_access(hardware_domain, paddr_to_pfn(channel-= >paddr), + paddr_to_pfn(channel->paddr + PAGE_SIZE = - 1)); + if ( ret ) + goto error; + } + + d->arch.sci_data =3D channel; + d->arch.sci_enabled =3D true; + + return 0; + +error: + relinquish_scmi_channel(channel); + return ret; +} + +int scmi_domain_sanitise_config(struct xen_domctl_createdomain *config) +{ + if ( config->arch.arm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE && + config->arch.arm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC= _MA ) + { + dprintk(XENLOG_INFO, "scmi: Unsupported ARM_SCI type\n"); + return -EINVAL; + } + + return 0; +} + +static int scmi_relinquish_resources(struct domain *d) +{ + int ret; + struct scmi_channel *channel, *agent_channel; + scmi_msg_header_t hdr; + struct scmi_msg_base_reset_agent_cfg_a2p tx; + + if ( !d->arch.sci_data ) + return 0; + + agent_channel =3D d->arch.sci_data; + + spin_lock(&agent_channel->lock); + tx.agent_id =3D agent_channel->agent_id; + spin_unlock(&agent_channel->lock); + + channel =3D get_channel_by_id(scmi_data.hyp_channel_agent_id); + if ( !channel ) + { + printk(XENLOG_ERR + "scmi: Unable to get Hypervisor scmi channel for domain %d\= n", + d->domain_id); + return -EINVAL; + } + + hdr.id =3D SCMI_BASE_RESET_AGENT_CONFIGURATION; + hdr.type =3D 0; + hdr.protocol =3D SCMI_BASE_PROTOCOL; + + tx.flags =3D 0; + + ret =3D do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0); + if ( ret =3D=3D -EOPNOTSUPP ) + return 0; + + return ret; +} + +static void scmi_domain_destroy(struct domain *d) +{ + struct scmi_channel *channel; + + if ( !d->arch.sci_data ) + return; + + channel =3D d->arch.sci_data; + spin_lock(&channel->lock); + + relinquish_scmi_channel(channel); + printk(XENLOG_DEBUG "scmi: Free domain %d\n", d->domain_id); + + d->arch.sci_data =3D NULL; + d->arch.sci_enabled =3D false; + + spin_unlock(&channel->lock); +} + +static bool scmi_handle_call(struct cpu_user_regs *regs) +{ + uint32_t fid =3D (uint32_t)get_user_reg(regs, 0); + struct scmi_channel *agent_channel; + struct domain *d =3D current->domain; + struct arm_smccc_res resp; + bool res =3D false; + + if ( !sci_domain_is_enabled(d) ) + return false; + + agent_channel =3D d->arch.sci_data; + spin_lock(&agent_channel->lock); + + if ( agent_channel->func_id !=3D fid ) + { + res =3D false; + goto unlock; + } + + arm_smccc_1_1_smc(fid, + get_user_reg(regs, 1), + get_user_reg(regs, 2), + get_user_reg(regs, 3), + get_user_reg(regs, 4), + get_user_reg(regs, 5), + get_user_reg(regs, 6), + get_user_reg(regs, 7), + &resp); + + set_user_reg(regs, 0, resp.a0); + set_user_reg(regs, 1, resp.a1); + set_user_reg(regs, 2, resp.a2); + set_user_reg(regs, 3, resp.a3); + res =3D true; +unlock: + spin_unlock(&agent_channel->lock); + + return res; +} + +static const struct sci_mediator_ops scmi_ops =3D { + .domain_init =3D scmi_domain_init, + .domain_destroy =3D scmi_domain_destroy, + .relinquish_resources =3D scmi_relinquish_resources, + .handle_call =3D scmi_handle_call, + .dom0_dt_handle_node =3D scmi_dt_handle_node, + .domain_sanitise_config =3D scmi_domain_sanitise_config, + .assign_dt_device =3D scmi_dt_assign_device, +}; + +static int __init scmi_check_smccc_ver(void) +{ + if ( smccc_ver < ARM_SMCCC_VERSION_1_1 ) + { + printk(XENLOG_WARNING + "scmi: No SMCCC 1.1 support, SCMI calls forwarding disabled= \n"); + return -ENOSYS; + } + + return 0; +} + +static int __init scmi_dt_hyp_channel_read(struct dt_device_node *scmi_nod= e, + struct scmi_data *scmi_data, + u64 *addr) +{ + int ret; + u64 size; + + if ( !dt_property_read_u32(scmi_node, "arm,smc-id", &scmi_data->func_i= d) ) + { + printk(XENLOG_ERR "scmi: unable to read smc-id from DT\n"); + return -ENOENT; + } + + ret =3D scmi_dt_read_hyp_channel_addr(scmi_node, addr, &size); + if ( IS_ERR_VALUE(ret) ) + return -ENOENT; + + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) ) + { + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); + return -EINVAL; + } + + return 0; +} + +static __init int scmi_probe(struct dt_device_node *scmi_node, const void = *data) +{ + u64 addr; + int ret; + struct scmi_channel *channel; + unsigned int n_agents; + scmi_msg_header_t hdr; + struct scmi_msg_base_attributes_p2a rx; + + ASSERT(scmi_node !=3D NULL); + + /* + * Only bind to the SCMI node provided by Xen under the xen,sci contai= ner + * (e.g. /chosen/xen/xen_scmi_config/scmi). This avoids binding to fir= mware + * SCMI nodes that belong to the host OSPM and keeps the mediator scop= ed to + * Xen-provided configuration only. + */ + if ( !scmi_is_under_xen_sci(scmi_node) ) + return -ENODEV; + + INIT_LIST_HEAD(&scmi_data.channel_list); + spin_lock_init(&scmi_data.channel_list_lock); + + if ( !acpi_disabled ) + { + printk(XENLOG_WARNING "scmi: is not supported when using ACPI\n"); + return -EINVAL; + } + + ret =3D scmi_check_smccc_ver(); + if ( ret ) + return ret; + + ret =3D scmi_dt_hyp_channel_read(scmi_node, &scmi_data, &addr); + if ( ret ) + return ret; + + scmi_data.dt_dev =3D scmi_node; + + channel =3D smc_create_channel(SCMI_BASE_AGENT_ID_OWN, scmi_data.func_= id, addr); + if ( IS_ERR(channel) ) + goto out; + + /* Mark as Xen management channel before collecting agent ID */ + channel->domain_id =3D DOMID_XEN; + + /* Request agent id for Xen management channel */ + ret =3D collect_agent_id(channel); + if ( ret ) + goto error; + + /* Save the agent id for Xen management channel */ + scmi_data.hyp_channel_agent_id =3D channel->agent_id; + + hdr.id =3D SCMI_BASE_PROTOCOL_ATTIBUTES; + hdr.type =3D 0; + hdr.protocol =3D SCMI_BASE_PROTOCOL; + + ret =3D do_smc_xfer(channel, &hdr, NULL, 0, &rx, sizeof(rx)); + if ( ret ) + goto error; + + n_agents =3D SCMI_FIELD_GET(SCMI_BASE_ATTR_NUM_AGENT, rx.attributes); + printk(XENLOG_DEBUG "scmi: Got agent count %d\n", n_agents); + ret =3D collect_agents(scmi_node); + if ( ret ) + goto error; + + ret =3D sci_register(&scmi_ops); + if ( ret ) + { + printk(XENLOG_ERR "SCMI: mediator already registered (ret =3D %d)\= n", + ret); + return ret; + } + + scmi_data.initialized =3D true; + goto out; + +error: + unmap_channel_memory(channel); + free_channel_list(); +out: + return ret; +} + +static const struct dt_device_match scmi_smc_match[] __initconst =3D { + DT_MATCH_COMPATIBLE("arm,scmi-smc"), + { /* sentinel */ }, +}; + +DT_DEVICE_START(scmi_smc_ma, "SCMI SMC MEDIATOR", DEVICE_FIRMWARE) + .dt_match =3D scmi_smc_match, + .init =3D scmi_probe, +DT_DEVICE_END + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index d30a288592..8f0f68544e 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -329,6 +329,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); =20 #define XEN_DOMCTL_CONFIG_ARM_SCI_NONE 0 #define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC 1 +#define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA 2 =20 struct xen_arch_domainconfig { /* IN/OUT */ @@ -355,6 +356,8 @@ struct xen_arch_domainconfig { uint32_t clock_frequency; /* IN */ uint8_t arm_sci_type; + /* IN */ + uint8_t arm_sci_agent_id; }; #endif /* __XEN__ || __XEN_TOOLS__ */ =20 --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Wed Jan 21 19:38:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 19:38:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210242.1522027 (Exim 4.92) (envelope-from ) id 1vie1X-0000uD-2V; Wed, 21 Jan 2026 19:37:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210242.1522027; Wed, 21 Jan 2026 19:37:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vie1W-0000u6-W4; Wed, 21 Jan 2026 19:37:50 +0000 Received: by outflank-mailman (input) for mailman id 1210242; Wed, 21 Jan 2026 19:37: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 1vie1V-0000u0-RQ for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 19:37:49 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a958ae2d-f700-11f0-9ccf-f158ae23cfc8; Wed, 21 Jan 2026 20:37:47 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ2PR03MB7499.namprd03.prod.outlook.com (2603:10b6:a03:556::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Wed, 21 Jan 2026 19:37:31 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Wed, 21 Jan 2026 19:37:31 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a958ae2d-f700-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=m/89oHjKfvI/zsGj4o2Bp6lxE7FRYYBadjUTvmTpcTDIpcbyMJGCfu/4zenRHswB8kVDGqeAoev1m/XXqxoApSay4pJzgdPu1dhA+bi53BL57b1KFJQmZKArSOaJQCzSdPSHZQChGYfmHOrfMkHze/w9XKtFSwgAhmn1hyoEPbNjVPgMddfGi+w7X2vyQpOOem7+vjE6bPpFP7ZVRZMrpU/sUkepvhkgdIpmWluvx5y2sDFxgfV6MGX1V9ie5TDljhGvRvHA13o3L8dn26av/IqOhp8mpgX+9xIy4wIDLT/qd3YWQ6B8PufxlBTXSAu2mwVb3HLxca1uQUqLMc6+qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hSIQnihWBTGLNNhyFlRPTs2hQiNRhL30wvoBa53DoMg=; b=b0QFxkeYMnAKy/LQqSu5ZizwVrP5f7+rfzv0mH/58zwQPJqRszZC0ZOIsUsNfXjPbBEpgzpR/04/iE5WMPOwm8Or1pPxOh05v+NmN9BvxEvXp9/eEEBY4gqTQbVqZiABXFtOTVYtBCk4NSDaudLEnqTmvs30jz73NinRDELrwZmc5/KZXbU6ahbKb9hjYOdyJ12MYdb1vQ8tQBxJNqKbcHwzS+u5WaJGX2AoJ0mHmx+J077GuMLHfy/BmfsakA1QetgHXjm1T9ymcQXbqpIzxeb2UX2Yea5e8gL2yrTto6d8USE5F0GEQsWiqJfGeaYFcogRlKF2vxHh8YMl6X872g== 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=hSIQnihWBTGLNNhyFlRPTs2hQiNRhL30wvoBa53DoMg=; b=IshFluRlEh08SDESxD4R++KOl4pfJCzzgJukhW6AECSZg1Wl1+j0L4jmoPruZD2z2zky3uUT57QoeHfP5wslQl13KVlTNXG5niln8Jv355nCYaSPMlcnvBkHHbA4WkKvvIU4KTATd7VkiRnZvmeRVW4kvsFJwNCz4ANR90tU8gU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <546d2385-5119-408b-9da2-35e09d2e7536@citrix.com> Date: Wed, 21 Jan 2026 19:37:27 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Nicola Vetrini Subject: Re: [PATCH v5 2/2] earlycpio: lib-ify earlycpio.c To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260121154757.44350-1-alejandro.garciavallejo@amd.com> <20260121154757.44350-3-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260121154757.44350-3-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0154.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:188::15) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ2PR03MB7499:EE_ X-MS-Office365-Filtering-Correlation-Id: 08f17da6-a2cd-4440-a65b-08de592484ad X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?a3FiK3k4djBGYzhjZXNlNDF1eE1ucjFZQTJmVzhxQit3aDZqVW5oRXR1L1Fp?= =?utf-8?B?U1BHSnFnVWs0dVlKRHV5RkNjem9ZQVo3QWFxeGl4RVN4V0ZMNmhlYnpCQzU1?= =?utf-8?B?QW8xOU56NlpGeWE2RVhvL1drV0xwbVhpNHZNWlZBQlR6Vml1UkFMR2Q3OG9F?= =?utf-8?B?QTNFY3R5YXYvYjROdFZWR0s1allhbnhlc09nbUJycjVaQ2ZVbjBqNWgzWjY4?= =?utf-8?B?NlUyYzdtZHk3akRyRGF3NllVRWxTSStYQUNvUzgyTmttS2JHN1pMME9ZMkMz?= =?utf-8?B?QTRKN0I0ZUVPZHpCaDdQV29KK2tWK3lrNlZQS2N0eGVXQWxub1B4ZXlxZ041?= =?utf-8?B?RUZIa2wrdUdPa3ZQaiszVXZtL2tLZXVDTU4xLy9wY2drVTdPQTdvMmdpSEJu?= =?utf-8?B?MCtiTS9QdmFnQjRVYzNRc2F4M09pUXpKSUtUQ3FPd3ZtSHFDckMyL1VsbDFZ?= =?utf-8?B?NjVUWjF5RmFDdlAwUXBRQUhkamtHdHNLN2h4MlV3OXpKZklOTGZOOGNreG9O?= =?utf-8?B?TGhQbXBWdjRTWVNkQ01Nam1LMGkvK0tTMkN4ck9jQ25NSVVNS21JbnlyMXZh?= =?utf-8?B?NWZxSWVhL1JrYzN6Yy96WnJFc0Q4QlNOWTNJUUtZTlYvaU8xU2sraDllN1B0?= =?utf-8?B?SFFPbFBteFRONkRzRktFdXFsOVF6SWtXSk1kUFZ0TzFMNGlKTTRadTMvbnox?= =?utf-8?B?RWFkN3FldE0va3BPVXAzS25KdG52M2JJdi9yU3VQcG5aaTFVTUhpT1JFVXk1?= =?utf-8?B?ZzBRcGcxTFF2UXdtSVp0U09ubU11RVg4YmtIQlhDV2dDWFVwQm11S2FqMjky?= =?utf-8?B?SVdQc3p6QTg4ckdRdTRPQmxmZlNDS0U3K3RxOC94SUlBY1FUd0hmb1VOaVE4?= =?utf-8?B?bG5LVHBXY0J4MjYxektRK3kvbndvSlhDb3ZWQ25pUS9nL21lUEFqdFMxY0NB?= =?utf-8?B?YUt6NURTYnhIZ0orUFFMVm1HdFBZd3JJZzdxQjFKWHQvNUlQc3p1UUt2MmVT?= =?utf-8?B?UG1INks2V0tZZEFyUnhLWk0xbC9mQW1rd05NbGcwa2NZSjQvNW52ejBzSnM5?= =?utf-8?B?VDlGQXpsZWpQRlZ2dWlhL0Q0bk5LWDVKN3YzSjFBeUZwRGo1Unprc3psa2xK?= =?utf-8?B?eFRFQU5mNngwMzc4ZTJYYjRSeHNuQlpRVitXdU4xVlRGbnZpcXFLaDc4YnZy?= =?utf-8?B?Nm1HaUxadCtzMjJCKzM4MTRIVlN3Y25FS1RscHRnUzNMYkdIMTJ0cHY3VlM0?= =?utf-8?B?T3ZybkZwa2IzaUdyMnlXSkJ0YVM5Wk5iS1pESVdsdlU1SDdPZXpPMHY1ZExh?= =?utf-8?B?d2tKSTNNOXJOMzBEYTZhdVZMTDJta1lBODUvczNKUEVXZnEwd0VaSFZOaHBU?= =?utf-8?B?UlI0SG5OMUdwcy9nL0taWUlZdGpmaHNYQnNMaFpBU2tTM2l1elZZd05PWnll?= =?utf-8?B?RzVveEdHenA1WmJKZGxTSVFvYlpyT2VZcVNSZFBzenRwRWsvV1VTb2Jua0Fk?= =?utf-8?B?VEVMUk1nTzFUSE5lR1lzUCthTlQreTRURy9Sdi9EbVZSL3pKWEtkWno2bmdD?= =?utf-8?B?NkF0NHRORUcvZGZ6UVZ3eGpqUkxCWjdmUjlSN2F3ekdISFNwOVdrK29ITlRD?= =?utf-8?B?dzhyWjBETWxqRHJNdmxtR3Mrb1dTS3AwZFprL2p6UXhpV2hFWklpODQwNmVN?= =?utf-8?B?UmpERi9VcGxUVzB2bGRrOUZEbnd4Zk95Z3laZEg3a2xOT2kyRTNhdnpmazdX?= =?utf-8?B?dE5QMnp0b05XMFdONmw4L3Z4RUpXT1U0MkZOZHpNeTFvWVBmRTArTG54VDlp?= =?utf-8?B?NitzQlRLcDV3T29SZVRaZjZneG4wNVRZVTFHN0VOOHo3dmRodlBxUkI5dHcv?= =?utf-8?B?cnNYdXNhdkJISGY5WGZXU2tER2FadmtDNDU3Z1V2UFdZMTdjNDdORTd2Y0pu?= =?utf-8?B?K0VVeER4S2lBaXFtYXJuWFpHTXA0aWRBWVpDbkJvVGNtajFSVFlNM2RPY1Q5?= =?utf-8?B?d0wreVNMWmIrVHdJY29YZ1ZPMHVoeGVTcm9sb0FwendKQTlWdzJBM3c3eVdj?= =?utf-8?B?ODhyN0JTTzI3a0VNS2JqYVJMcVBGZjVkc0syYitqYk1MYzh0QWwxRmduTHZr?= =?utf-8?Q?UGIk=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?L2prdjVzenhQNUtxb0dvMSswQk40STdHWGVEVElzZjVHbVZwU0FnaHpUQVFv?= =?utf-8?B?eVJWcVozR3dVOGpvTFJ1bjNlYVFKQ1JoUFNPNFdnOW1VZ0FGbzByNlU0QjBQ?= =?utf-8?B?RDUwZnpjNkowbVlvTGF5ZUMzSFJhTWtqMG01NWxqdVdnVTlSQUYrMmtFMjhP?= =?utf-8?B?bFc5TU03ZEZiTzE2VytvK2FJWk5GV1ZrbkJOVDV4Vk1GM3d4TDNMUE5GQzZy?= =?utf-8?B?RXRIcm5yMWcyaTFzM0prZUVrejNPZzJKL1FiVVIrU2Rjb3JURjJoeVB4Q1Js?= =?utf-8?B?MXliOEM1aTVNcjZmb2laVXdaeFdkM05UNDBGL1RVUElia0d1VThiYkE2bm1X?= =?utf-8?B?UjNpbGdqSTRkMFY0UWRDNlpqZ24zbXlYdDQ4b2xGbjUzZVBZRXNsZDZSMlBW?= =?utf-8?B?dlVBaHBYUkoxK24zc1V2cDVMK2VJVDFpbEhFTUI5SjNhbVdHb2QwUXBmcmIw?= =?utf-8?B?MG1XK0F2cTVXUTFnOWVaTXlGT3F1YzIrUGhsSHlpQ1Fpc0svdWVScjhqUCtl?= =?utf-8?B?eW4wMWlZUWlHVE40dFpFbWRwM2psS1ozOWZPQytnVnVHclZhYVluanZ5QzNu?= =?utf-8?B?TnkwMWx0ZTNYSTBSdHJpeUs0ZHBNUkllMkpNcGNyYkpibG1ZWm90ZjFMZ2l1?= =?utf-8?B?R25PQ1hYbDlzMXJqeFhab2x2aE5mdlRSaEVkdzl3UENoc0lHRTZnV29vbGZh?= =?utf-8?B?RUcxSHROWWNyMHVnUHNmbmRkRmd2VW4vS3FzZHdaNWVUL1dmaExSTEVSUGJ4?= =?utf-8?B?OHlacjZ5YTJDN09Fc21jc1BJazF2bktnZGtncnpyczViTzJDYVBhdUd4Ly9U?= =?utf-8?B?dU4zcUozUGZpVzM5L1E5TkVRcWo3RTlPNkg0WFprWWZZbWtoTEhEMmI2VC83?= =?utf-8?B?Y2dDYmU3WUN1ZmRsWHk2MHEvRFFDelVLOUk2V1pENHhHY1dmaVlLZklsVTVl?= =?utf-8?B?Z1V4eG4vN2NBTW8wbmNRVklMQ3hSdTZ0WmtBbFQ2bkxCaUJyYkhNNzVRV1dy?= =?utf-8?B?dTk1cFpiUWRVMVB2aEVNVCs0amZORU9wTzlobldHejNPTm91Q081UGx5aFdy?= =?utf-8?B?eVQ5OHRlbHNUTEU2TWx0ck13MWVYS2VtTmphWEtuV0pNOTB0cys3MUI4UnVX?= =?utf-8?B?ZURVZGRlNHZoa2hHVXJuNU9HaGRiV3NZWk9ma0I0aVIycVRtb3dhd3lmSFhW?= =?utf-8?B?NnBmcGpvMHJCc2dHMC9pQ2tLQTVqL0tIRE9ZaFdBclM3TUNGaE11SkNpcVFY?= =?utf-8?B?NkM1R3J6eDNva0hLUy9YTUNmT1RPd085eUhpMHNYcWNjS1gzbVZ6MWdqYlgv?= =?utf-8?B?T3MyK2pESm5vZE5hWXZNK0l5VzlVb3czNEUwSnRxaFpVZThHT1JlRm9mR1Bs?= =?utf-8?B?VHU0UURhWEs0K3gwb0VJNFpxVlZEYmJuVFc0T3dSMFdNT00wZEZubXBJa2Js?= =?utf-8?B?Y0pWT1JyYjBDSFBKcXNyWHB3dFh3Y0EwaTBLU3UzMlNVYVkyWWZpdHZsYmRK?= =?utf-8?B?S2NQcHdaS1hJNWZGbGppWm1PRkFTakpJN3NncVh1VjBETlRJQnoyYWJuTS9x?= =?utf-8?B?NnhXOFpwWUQ2SzJQMlM3Tks2eFd1c0Z3dGdYbkw1Rk1waWw3MmxUNy9FcTRl?= =?utf-8?B?aW5uUURNVWhVWlFHNG1LTGtORkd0U3EzdVVpRkE2Nm9WQ3gvTmFXOWpFREox?= =?utf-8?B?ODQvb0hMeVduMVBaYVdtYU90Unp6ZnBHa1Rnc2FQRlZXcUZxdll6RnNrRHU5?= =?utf-8?B?V1JLUStuK1NTRlpza3BEY3VKbnJ1NmlJd3F2Nkh0R05XRzVzdnlqZTJ6L3Rn?= =?utf-8?B?ei9ra1JneE9aZnowMEh2cndLM1FCSEE4RTNkR3ZwRG85T1l4NHZHWXVmY2Nx?= =?utf-8?B?QXpiYzRXS0l4dVB0VVFETTRBZEdocnIrQWVwTjNVZkV3U25JR2Uya3ZpZlh1?= =?utf-8?B?TCtzT05CL2tPRm5KVmhDRVZIaUR3TXBncGdQVmw0RWovN3l4NDlteEIrYkY0?= =?utf-8?B?V0drNktHQVhJSlhXWVpiQUdPdjUwbXhQVmxGOXpiM1dEcmMrL3dyelN3NXNo?= =?utf-8?B?Nzg5RGthOTlKbUtqNlAyRURSbWN6REl6Q3FVeHUxdDdwWERCZmhiZE9BUXNr?= =?utf-8?B?dmJzelRTTHJVKzlabGVhQUVtN3lGN0l1cmJJWE5mNzVDcGVPWVdsSmJwdDFC?= =?utf-8?B?cFpwS2xramN6NzlPMTF6Zk1TdTJyUFRjei9Ia2NUbEkrNG52eWhBdndGWnhr?= =?utf-8?B?NGdIM0VqR1RYTlg5ejNlUW5MTXZ4RCt4cS9kVWR5L1ZWUTVqU1N2UVFGbXZs?= =?utf-8?B?VEF1OXF5UWxFRFdORHdPMk5yZWZDbGhBdUdNb0grc3VxWm5oYzJub1lXMzZD?= =?utf-8?Q?RbeUkvtPlIbP1SYY=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 08f17da6-a2cd-4440-a65b-08de592484ad X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2026 19:37:31.5371 (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: EzezxlJn6PzZ28jpZhI7XHA4YlhpbfJ1EGgMPo7Pl6cAe+UwyfAeVk7Gj+9qstKt9dR+K4b+x/NPi8kSgqh310aQXNRsjFqNyggerwqWMG4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR03MB7499 On 21/01/2026 3:47 pm, Alejandro Vallejo wrote: > It's only used for microcode loading on x86. By lib-ifying it we can make > it go away automatically when microcode loading becomes an optional > feature in follow-up patches. Given what's committed, this becomes "when CONFIG_MICROCODE_LOADING=n" now. > The exclude-list.json file goes stale after the move, so remove the entry > for earlycpio.c now that it's not included in AMD's build. > > Its breakages will be fixed in due time and not ignored. ---8<--- exclude-list.json becomes stale with the move, but earlycpio is now absent entirely in the *-amd target build, so the violations don't matter. Simply drop the exclusion, so the logic gets scanned as part of the *-allcode targets. ---8<--- > > Signed-off-by: Alejandro Vallejo > Acked-by: Andrew Cooper # lib-ify only > Reviewed-by: Nicola Vetrini # exclude-list.json Consider my A-by extended to a full R-by, and this looks fine to go in now. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jan 21 19:55:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 21 Jan 2026 19:55:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210255.1522037 (Exim 4.92) (envelope-from ) id 1vieIc-0003f0-EF; Wed, 21 Jan 2026 19:55:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210255.1522037; Wed, 21 Jan 2026 19:55:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vieIc-0003et-BC; Wed, 21 Jan 2026 19:55:30 +0000 Received: by outflank-mailman (input) for mailman id 1210255; Wed, 21 Jan 2026 19:55: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 1vieIb-0003en-6U for xen-devel@lists.xenproject.org; Wed, 21 Jan 2026 19:55:29 +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 215489ae-f703-11f0-b15e-2bf370ae4941; Wed, 21 Jan 2026 20:55:27 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 82C7F600AA; Wed, 21 Jan 2026 19:55:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93150C4CEF1; Wed, 21 Jan 2026 19:55: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: 215489ae-f703-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769025325; bh=4YFQuSQdmutjU4oIbDaR0LBdGgXmLDotmJCaLOVfG/0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=d9nYAYukHBJdMaXtH+cD2mJshmiDRDkdQOgU/k+kaUZmF4E2QEtv7SzjciHXYmf/K AzUGs6ddKirslE3/srltcioN9FUiALpVZhcLrw9gSpIKGnKkqB+/m4CVc1WPN0jukg MZD+RKGhf1EYH1AEjXWrki/NHh0+NmDuz4VW8W9CzUsgyi22GaYJHYKKTU4dmgG7ES bXe67bzDvthM0mjbkFGDb+j6NAPPw+9YMbQUwhfMdDBnzhGM7V/ERcs5+W8TpZzG0g +eUE2nREzrjg205m4uAOFmDdd+Lgo5bbMjKfj5E4y6SWSZSjYafzMi1k0MFbdOK8oi zJ2pYLQX1GLcg== Date: Wed, 21 Jan 2026 11:55:23 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Andrew Cooper cc: Alejandro Vallejo , xen-devel@lists.xenproject.org, Doug Goldstein , Stefano Stabellini Subject: Re: [PATCH v4 5/5] automation: Disable ucode loading on AMD's analysis run In-Reply-To: <95c6eb65-44ef-4a2d-8353-27363b952076@citrix.com> Message-ID: References: <20260120093852.2380-1-alejandro.garciavallejo@amd.com> <20260120093852.2380-6-alejandro.garciavallejo@amd.com> <95c6eb65-44ef-4a2d-8353-27363b952076@citrix.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Wed, 21 Jan 2026, Andrew Cooper wrote: > On 20/01/2026 9:38 am, Alejandro Vallejo wrote: > > Explicitly set CONFIG_MICROCODE_LOADING=n > > > > Signed-off-by: Alejandro Vallejo > > Acked-by: Andrew Cooper > > I've discussed this enough with Stefano in the past to know that it's > part of ThePlan(tm). Yep, thanks Andrew. Ack from me as well. From xen-devel-bounces@lists.xenproject.org Thu Jan 22 01:35:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 01:35:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210329.1522048 (Exim 4.92) (envelope-from ) id 1vijbE-0000FP-QP; Thu, 22 Jan 2026 01:35:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210329.1522048; Thu, 22 Jan 2026 01:35:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vijbE-0000FH-Li; Thu, 22 Jan 2026 01:35:04 +0000 Received: by outflank-mailman (input) for mailman id 1210329; Thu, 22 Jan 2026 01:35:02 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vijbC-0000F9-Qa for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 01:35:02 +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 9012099c-f732-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 02:35:00 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id E274E40448; Thu, 22 Jan 2026 01:34:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7C066C4CEF1; Thu, 22 Jan 2026 01:34: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: 9012099c-f732-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769045697; bh=YmwG5XqwcJY3E9hnlisguppPgD11x4/SdCrdc5SMDE8=; h=Date:From:To:cc:Subject:From; b=btAfPPcshxTpTna23/cM20kqvtSxSLOlVArYCiRJKF9D2yfBGpenN9/RUHaJmHJrh IpcPK4hXySGIkaA6UXA+KjrwUp6ApcD53wnmapMGSCu2Glfxvl9w5EeHiG3M09PNwY giLZmDJtdyTIzNRj7PVYv0fwbCojMo1yLTq8JLBw3wA+KetIcS+Y1NTgQsThbvqgXY 6LdjUUhMFrzr3lYPASjrYtz9ilEafHJ0NZNvur4s+ji/Cj3RrJvrYSIXkgReE5ETwu E9gfsVvpiuyLXuxfv4xFylZuOiKbIzXJdkA65KmG+PtevOdudaTqf+7MWoGKBALxKX Gg9DgEOAKcUVA== Date: Wed, 21 Jan 2026 17:34:54 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: xen-devel@lists.xenproject.org cc: grygorii_strashko@epam.com, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Victor Lira , andrew.cooper3@citrix.com, sstabellini@kernel.org, jbeulich@suse.com Subject: [PATCH v6] xen/console: handle multiple domains using console_io hypercalls Message-ID: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Allow multiple dom0less domains to use the console_io hypercalls to print to the console. Handle them in a similar way to vpl011: only the domain which has focus can read from the console. All domains can write to the console but the ones without focus have a prefix. In this case the prefix is applied by using guest_printk instead of printk or console_puts which is what the original code was already doing. When switching focus using Ctrl-AAA, discard any unread data in the input buffer. Input is read quickly and the user would be aware of it being slow or stuck as they use Ctrl-AAA to switch focus domain. In that situation, it is to be expected that the unread input is lost. The domain writes are buffered when the domain is not in focus. Push out the buffer after the domain enters focus on the first guest write. Move the vpl011 check first so that if vpl011 is enabled, it will be used. In the future, the is_hardware_domain path might also be used by other predefined domains so it makes sense to prioritize vpl011 to retain the current behavior on ARM. Locking updates: - Guard every mutation of serial_rx_cons/prod with console_lock and discard unread input under the lock when switching focus (including when returning to Xen) so that cross-domain reads can't see stale data - Require is_focus_domain() callers to hold console_lock, and take that lock around the entire CONSOLEIO_read loop, re-checking focus after each chunk so a focus change simply stops further copies without duplicating or leaking input - Hold cd->pbuf_lock while flushing buffered writes in the focus path so the direct-write fast path does not race buffered guests or HVM debug output Signed-off-by: Stefano Stabellini --- Changes in v6: - moved locks out of console_get/put_domain - reworked locking from the ground up - introduced is_focus_domain - improved commit message --- xen/drivers/char/console.c | 64 +++++++++++++++++++++++++++++--------- 1 file changed, 49 insertions(+), 15 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 2bdb4d5fb4..d586572c5e 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -540,6 +540,11 @@ void console_put_domain(struct domain *d) rcu_unlock_domain(d); } +static bool is_focus_domain(struct domain *d) +{ + return d != NULL && d->domain_id == console_rx - 1; +} + static void console_switch_input(void) { unsigned int next_rx = console_rx; @@ -555,8 +560,11 @@ static void console_switch_input(void) if ( next_rx++ >= max_console_rx ) { - console_rx = 0; printk("*** Serial input to Xen"); + nrspin_lock_irq(&console_lock); + console_rx = 0; + serial_rx_cons = serial_rx_prod; + nrspin_unlock_irq(&console_lock); break; } @@ -575,8 +583,12 @@ static void console_switch_input(void) rcu_unlock_domain(d); - console_rx = next_rx; printk("*** Serial input to DOM%u", domid); + nrspin_lock_irq(&console_lock); + console_rx = next_rx; + /* Don't let the next dom read the previous dom's unread data. */ + serial_rx_cons = serial_rx_prod; + nrspin_unlock_irq(&console_lock); break; } } @@ -599,14 +611,25 @@ static void __serial_rx(char c) if ( !d ) return; +#ifdef CONFIG_SBSA_VUART_CONSOLE + /* Prioritize vpl011 if enabled for this domain */ + if ( d->arch.vpl011.base_addr ) + { + /* Deliver input to the emulated UART. */ + rc = vpl011_rx_char_xen(d, c); + } + else +#endif if ( is_hardware_domain(d) ) { /* * Deliver input to the hardware domain buffer, unless it is * already full. */ + nrspin_lock_irq(&console_lock); if ( (serial_rx_prod - serial_rx_cons) != SERIAL_RX_SIZE ) serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c; + nrspin_unlock_irq(&console_lock); /* * Always notify the hardware domain: prevents receive path from @@ -614,11 +637,6 @@ static void __serial_rx(char c) */ send_global_virq(VIRQ_CONSOLE); } -#ifdef CONFIG_SBSA_VUART_CONSOLE - else - /* Deliver input to the emulated UART. */ - rc = vpl011_rx_char_xen(d, c); -#endif if ( consoled_is_enabled() ) /* Deliver input to the PV shim console. */ @@ -730,6 +748,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, unsigned int flags = opt_console_to_ring ? CONSOLE_ALL : CONSOLE_DEFAULT; struct domain *cd = current->domain; + struct domain_console *cons = cd->console; while ( count > 0 ) { @@ -742,18 +761,25 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, if ( copy_from_guest(kbuf, buffer, kcount) ) return -EFAULT; - if ( is_hardware_domain(cd) ) + spin_lock(&cons->lock); + nrspin_lock_irq(&console_lock); + if ( is_focus_domain(cd) ) { + if ( cons->idx ) + { + console_send(cons->buf, cons->idx, flags); + cons->idx = 0; + } /* Use direct console output as it could be interactive */ - nrspin_lock_irq(&console_lock); console_send(kbuf, kcount, flags); nrspin_unlock_irq(&console_lock); + spin_unlock(&cons->lock); } else { char *kin = kbuf, *kout = kbuf, c; - struct domain_console *cons = cd->console; + nrspin_unlock_irq(&console_lock); /* Strip non-printable characters */ do { @@ -765,7 +791,6 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, } while ( --kcount > 0 ); *kout = '\0'; - spin_lock(&cons->lock); kcount = kin - kbuf; if ( c != '\n' && (cons->idx + (kout - kbuf) < (ARRAY_SIZE(cons->buf) - 1)) ) @@ -815,6 +840,13 @@ long do_console_io( if ( count > INT_MAX ) break; + nrspin_lock_irq(&console_lock); + if ( !is_focus_domain(current->domain) ) + { + nrspin_unlock_irq(&console_lock); + return 0; + } + rc = 0; while ( (serial_rx_cons != serial_rx_prod) && (rc < count) ) { @@ -824,14 +856,16 @@ long do_console_io( len = SERIAL_RX_SIZE - idx; if ( (rc + len) > count ) len = count - rc; + nrspin_unlock_irq(&console_lock); if ( copy_to_guest_offset(buffer, rc, &serial_rx_ring[idx], len) ) - { - rc = -EFAULT; - break; - } + return -EFAULT; rc += len; + nrspin_lock_irq(&console_lock); + if ( !is_focus_domain(current->domain) ) + break; serial_rx_cons += len; } + nrspin_unlock_irq(&console_lock); break; default: rc = -ENOSYS; -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 01:36:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 01:36:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210336.1522058 (Exim 4.92) (envelope-from ) id 1vijcR-0000iD-2w; Thu, 22 Jan 2026 01:36:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210336.1522058; Thu, 22 Jan 2026 01: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 1vijcQ-0000i6-VR; Thu, 22 Jan 2026 01:36:18 +0000 Received: by outflank-mailman (input) for mailman id 1210336; Thu, 22 Jan 2026 01:36:18 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vijcQ-0000ht-8P for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 01:36:18 +0000 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bd72d40c-f732-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 02:36:15 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 79BEE43672; Thu, 22 Jan 2026 01:36:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0BFA9C4CEF1; Thu, 22 Jan 2026 01:36: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: bd72d40c-f732-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769045774; bh=UeCrploEJESDU7p7RW9wlv0RsbYrboGocgLNdFLhbfE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=UpylZrayYuuVZGibjJdymgA7l5STHTz8UlBDrdMNvfVtUEl9fTNBpoEAWJfoUA2RP +lKMEaaP4lq+6LijUle7BpRAQxIV7YJtKS1Q8f6cShqoHdhEuKPKtDeAQR55KqXSi4 vLVdWlkt3sCvyt+xCYuHiof6tEFSavRAdWYordlTFcjWka62gVp8cuN81Z+tjBvVu8 XXMj99uwxlrZniShINfMl5y+ImkY6dVekutGj16puKRIPm2d0Qj52DqFSQ8TrzSBS7 5M9Srg6wevKXmNNBkCIws5ZwVmCNXlUjr4unhg2MpHry3txdAY7HwHkmApbpN8Rd5+ DkQwnb+m2EyZQ== Date: Wed, 21 Jan 2026 17:36:11 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Jan Beulich cc: Stefano Stabellini , grygorii_strashko@epam.com, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Victor Lira , andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH v3] xen/console: handle multiple domains using console_io hypercalls In-Reply-To: <873867dc-79d8-4ed3-94f7-1c7823db7957@suse.com> Message-ID: References: <63c35c5e-577b-4346-b600-03808306177f@suse.com> <32d0a9a2-89df-4e20-8f7a-0f069cbff11f@suse.com> <873867dc-79d8-4ed3-94f7-1c7823db7957@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, 21 Jan 2026, Jan Beulich wrote: > On 21.01.2026 01:07, Stefano Stabellini wrote: > > --- a/xen/drivers/char/console.c > > +++ b/xen/drivers/char/console.c > > @@ -521,6 +521,8 @@ struct domain *console_get_domain(void) > > { > > struct domain *d; > > > > + nrspin_lock_irq(&console_lock); > > + > > if ( console_rx == 0 ) > > return NULL; > > > > @@ -540,6 +542,8 @@ void console_put_domain(struct domain *d) > > { > > if ( d ) > > rcu_unlock_domain(d); > > + > > + nrspin_unlock_irq(&console_lock); > > } > > Hmm, I'd much prefer if we could avoid this. The functions aren't even > static, and new uses could easily appear. Such a locking model, even > disabling IRQs, feels pretty dangerous. (If it was to be kept, prominent > comments would need adding imo. However, for now I'm not going to make > any effort to verify this is actually safe, on the assumption that this > will go away again.) It is totally fine to get rid of it and revert back to explicit locks outside of the console_get_domain and console_put_domain functions as it was done in v4: https://marc.info/?l=xen-devel&m=176886821718712 However, the locked regions would still need to extended, more on this below. > > @@ -596,8 +604,19 @@ static void __serial_rx(char c) > > > > d = console_get_domain(); > > if ( !d ) > > + { > > + console_put_domain(d); > > return; > > + } > > > > +#ifdef CONFIG_SBSA_VUART_CONSOLE > > + /* Prioritize vpl011 if enabled for this domain */ > > + if ( d->arch.vpl011.base_addr ) > > + { > > + /* Deliver input to the emulated UART. */ > > + rc = vpl011_rx_char_xen(d, c); > > + } else > > Nit: Style. > > > +#endif > > if ( is_hardware_domain(d) || IS_ENABLED(CONFIG_DOM0LESS_BOOT) ) > > { > > /* > > @@ -613,11 +632,6 @@ static void __serial_rx(char c) > > */ > > send_guest_domain_virq(d, VIRQ_CONSOLE); > > } > > -#ifdef CONFIG_SBSA_VUART_CONSOLE > > - else > > - /* Deliver input to the emulated UART. */ > > - rc = vpl011_rx_char_xen(d, c); > > -#endif > > I don't understand this movement, and iirc it also wasn't there in v3. > There's no explanation in the description, unless I'm overlooking the > crucial few words. This chunk fixes an unrelated bug on ARM. We need to move the CONFIG_SBSA_VUART_CONSOLE check earlier otherwise this patch will never be taken when IS_ENABLED(CONFIG_DOM0LESS_BOOT). I wrote a note in the changelog here: https://marc.info/?l=xen-devel&m=176886821718712 - if vpl011 is enabled, send characters to it (retains current behavior on ARM) I'll be clearer in the next commit message. > > @@ -741,17 +756,23 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, > > if ( copy_from_guest(kbuf, buffer, kcount) ) > > return -EFAULT; > > > > - if ( is_hardware_domain(cd) ) > > + input = console_get_domain(); > > + if ( input && cd == input ) > > { > > + if ( cd->pbuf_idx ) > > + { > > + console_send(cd->pbuf, cd->pbuf_idx, flags); > > + cd->pbuf_idx = 0; > > + } > > /* Use direct console output as it could be interactive */ > > - nrspin_lock_irq(&console_lock); > > console_send(kbuf, kcount, flags); > > - nrspin_unlock_irq(&console_lock); > > + console_put_domain(input); > > } > > else > > { > > char *kin = kbuf, *kout = kbuf, c; > > > > + console_put_domain(input); > > /* Strip non-printable characters */ > > do > > { > > The folding of locking into console_{get,put}_domain() again results in overly > long windows where the "put" is still outstanding. As said before, the current > domain can't go away behind your back. I wrote in the commit message: "Add the console_lock around serial_rx_prod and serial_rx_cons modifications to protect it against concurrent writes to it. Also protect against changes of domain with focus while reading from the serial." Following your past review comments, I switched to using the console_lock (folded into console_get/put_domain, but it can be separate) to protect both serial_rx_prod/serial_rx_cons accesses and also console_rx accesses. > > @@ -813,6 +835,13 @@ long do_console_io( > > if ( count > INT_MAX ) > > break; > > > > + d = console_get_domain(); > > + if ( d != current->domain ) > > + { > > + console_put_domain(d); > > + return 0; > > + } > > + > > rc = 0; > > while ( (serial_rx_cons != serial_rx_prod) && (rc < count) ) > > { > > @@ -822,14 +851,23 @@ long do_console_io( > > len = SERIAL_RX_SIZE - idx; > > if ( (rc + len) > count ) > > len = count - rc; > > + > > + console_put_domain(d); > > if ( copy_to_guest_offset(buffer, rc, &serial_rx_ring[idx], len) ) > > { > > rc = -EFAULT; > > break; > > } > > + d = console_get_domain(); > > + if ( d != current->domain ) > > + { > > + console_put_domain(d); > > + break; > > + } > > rc += len; > > serial_rx_cons += len; > > } > > + console_put_domain(d); > > break; > > This is pretty horrible, don't you agree? Demonstrated by the fact that you > look to have encoded a double put: The 2nd to last one conflicts with the > one right after the loop. Whereas the earlier "break" has no reference at > all, but still takes the path with the "put" right after the loop. At the > same time it also looks wrong to simply drop that last "put". Yes I agree it is horrible. I did a deep review of all locking scenarios and moved console_lock out of console_get/put_domain. I sent out an update, expanding the commit message to explain the locking, and re-testing all scenarios on both ARM and x86. https://marc.info/?l=xen-devel&m=176904847332141 There were at 2-3 locking issues in this version of the patch and they have all being resolved now. From xen-devel-bounces@lists.xenproject.org Thu Jan 22 07:17:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 07:17:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210401.1522068 (Exim 4.92) (envelope-from ) id 1viowb-0006nx-8T; Thu, 22 Jan 2026 07:17:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210401.1522068; Thu, 22 Jan 2026 07:17: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 1viowb-0006nq-5e; Thu, 22 Jan 2026 07:17:29 +0000 Received: by outflank-mailman (input) for mailman id 1210401; Thu, 22 Jan 2026 07: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 1viowZ-0006nk-CK for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 07:17:27 +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 66d97088-f762-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 08:17:25 +0100 (CET) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-42fbc544b09so412354f8f.1 for ; Wed, 21 Jan 2026 23:17:25 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43569926ffcsm41143730f8f.18.2026.01.21.23.17.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jan 2026 23:17:24 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 66d97088-f762-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769066245; x=1769671045; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=UHTJ6KXNWoh0hdGrTW1lhA6H3qMn440dQudni+jBuvg=; b=g7v6fbjWb+NpftWuToKdjJK3yfxcbMsBPUhyYL1QWyUqgeHBnROBi0xFNLJfSmyzmm Tu1qmDPVKrPoHHwr+Ju+4WSRGpP7QzoSdHDq+46Gi4x/d9P608imz5W4wbdJ79h9eRdh yxZ//vd8d/R3G3HujPPMnNJb3NEiapfAb81hP3Vg2JE1sXDZGdedZvTsEyIn9yGNaXPH 6zFCzEDyad3c5fcUej2F1hnTtDgugi89tLubYUWWyFQg8E8MMh1LWZks+M4Xic6NDheA /GeEUr3Xb2PrR0rSnvygSoXKIpPq6AHXiM8kW/E3o3fm/2koc3mdyYzY1VxwdTdF8HIA NPSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769066245; x=1769671045; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=UHTJ6KXNWoh0hdGrTW1lhA6H3qMn440dQudni+jBuvg=; b=A/NfLVpwIRWUGBjKOspGCBYZrrcZd1f01euuuUEHnK/JRvePi9c9sORKs8h33azJRf 4L7X2FzXEkzWmj/S/7DfWzEXzSiiIX5DpAh/CdY3yRitNKIN/R7BBSFaYzse2+zX88Ih feGnhHzZhIdJFo0hdZ8IQteO2LfyfDLoocc4YGDNQKYRezeW2W9dNUO83Pd5HDCjN3DM ybf0neeu7MIWLBbIRMBxhsEkqW55xA3Mdc2d2rN/DFNrEfUz6dAY4Gzu+BOVMNOPImHh q/XY6jXfQIxsF9tqE36ivSx2oEZ43mczzbl6pEV3z8ckLQq4JSdgp+lXFTU46tC6SyjS YuTQ== X-Gm-Message-State: AOJu0YzgFP+uwwPOXzTOmGdynwu8jVi6bEkuNGT78uOkMGmyQEApGXsR PNCRhtPoom5Ojmyakj99I8xWE0fNkowoZP8/ppi4+BXpn5HuwfXpPBvuAX9AZZQeZA== X-Gm-Gg: AZuq6aIsO4EMSDQusLVqbzLx8QtWhUwhsORhVmhuVCNCSTmLmQDqVERq1xz2UarJFYz RQsjgfkDqDNAJDbjcnYKFycgrp0ewXp8QqzZANQYEEX+TTeNE9U0OW97Jd6dV/SRsOfX//dgYSk TYPB+p+v8yCqN2eX4R0OfMJEJrcEHR3d4R0tGkI+hRL623gwxEmTlOao5WfTuuKPTzFMPeBnjwk exD8F8WsAgTmAoCDOBbD2hPRnH+kzC8orQfMlZYMegoMy03G+Gi2W/gIUbrMKV0jFaHtuhPre7F 2PNYFuiczU1UeVnfW5WiRSlL11WGnxpcyC5A22gTYsYE+xEKBm0QyFNyqp8Zb39SywRL2yXjDmM j4TTlcV0xsOHP8lUjuxZlNIwPY9a1mKr1LTlIZznHWXC8NrmDHc8VIc9V0F4YmSHqLeUWxBaE9U /ynp1eiAEevkaIp1VGsTbz1HXne90MzO4hfX2tCGDoyWrK7pgOB9cfYUfX/otj+/jsqXyYEjxCH X4= X-Received: by 2002:a05:6000:402a:b0:42f:b581:c69a with SMTP id ffacd0b85a97d-4358ff1c1f1mr13520631f8f.5.1769066244781; Wed, 21 Jan 2026 23:17:24 -0800 (PST) Message-ID: <634471a1-1185-4644-aeea-7891e62bc1f0@suse.com> Date: Thu, 22 Jan 2026 08:17:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Partial revert "x86/xen: fix balloon target initialization for PVH dom0" To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, James Dingwall , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Jason Andryuk References: <20260120140648.25977-1-roger.pau@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 21.01.2026 18:49, Roger Pau Monné wrote: > --- a/drivers/xen/balloon.c > +++ b/drivers/xen/balloon.c > @@ -724,7 +724,8 @@ static int __init balloon_add_regions(void) > static int __init balloon_init(void) > { > struct task_struct *task; > - unsigned long current_pages; > + unsigned long current_pages = 0; With this, ... > @@ -732,8 +733,13 @@ static int __init balloon_init(void) > > pr_info("Initialising balloon driver\n"); > > - current_pages = xen_pv_domain() ? min(xen_start_info->nr_pages, max_pfn) > - : get_num_physpages(); > + if (xen_initial_domain()) > + current_pages = HYPERVISOR_memory_op(XENMEM_current_reservation, > + &domid); > + if (current_pages <= 0) ... why <= ? Gives the impression you may mean to cover HYPERVISOR_memory_op() returning an error, yet that'll require a signed long variable then. Jan > + current_pages = > + xen_pv_domain() ? min(xen_start_info->nr_pages, max_pfn) > + : get_num_physpages(); > > if (xen_released_pages >= current_pages) { > WARN(1, "Released pages underflow current target"); > From xen-devel-bounces@lists.xenproject.org Thu Jan 22 07:21:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 07:21:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210409.1522077 (Exim 4.92) (envelope-from ) id 1vip0w-0008JU-Pz; Thu, 22 Jan 2026 07:21:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210409.1522077; Thu, 22 Jan 2026 07:21:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vip0w-0008JN-N1; Thu, 22 Jan 2026 07:21:58 +0000 Received: by outflank-mailman (input) for mailman id 1210409; Thu, 22 Jan 2026 07: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 1vip0v-0008JH-Nt for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 07:21:57 +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 08681493-f763-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 08:21:56 +0100 (CET) Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-432d2c7dd52so609140f8f.2 for ; Wed, 21 Jan 2026 23:21:56 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435924ae723sm15983260f8f.41.2026.01.21.23.21.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jan 2026 23:21:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 08681493-f763-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769066516; x=1769671316; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=1f/8vCASIfL1ZKsOCXvbw+kI5xMaZrYATdc8FjFcukc=; b=f4EcEzOupaLskxB+6WU21bQS+1Q5E/7G0MuWqJRbZwWTcSQ9AkByXgucL1xYekFMqB oBSQFLfPbHUBCXNJDbLXqV4YirfloNO8Pje4UGKe4gtjCeOzxLyZyrwRi1gmIbFVLAem szlWGfICUFC0T0t/5GuaJU3gbdmFGC25XBNWMk/u5VWhh6AqzqIkglbAAET2d3agwnVL +ud861kDqwMDpC1o/cnh/aAYyKJjRkQ7KvC7TEsPkdkQBJkmJprl/34YQkZs+4yf84/a 8+HdzT1x1cVH5kMZTML11I/h1dIxtEkiFhWUiRpYpfXAD66rMwpzepQnM63RWJuL29nR aXdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769066516; x=1769671316; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=1f/8vCASIfL1ZKsOCXvbw+kI5xMaZrYATdc8FjFcukc=; b=gViB6hCLE+6tDvnA/yEDZetedkHeGZDmfXYi/VMgMA9PRpKmsdU4yypyVd44SkJ8qS 9cYugyO5XykYckhZjrd/fcigrt5c/LvOHPH6osRoxiwqDg/nhiGw2M/eqHbEuyDeRIDw Yj8j6cypdgapcJYA+SKiYTjkjpId6wqT2d3t/yOV9wq5rAnXNUywUnDQ7IFb0n9uBFzJ SSig9OXax46Jj7v9zW/fYOUyFm6W2McN5/pLN1J+//6elS48plZ/+ZVT0brJ44hXfRaH p82I/pOUffC1FHbWVqQ6H+/J8ezUQBzz2MtjjqsP4ijb+H7U/qnmHLn/ERAENpGzkga/ 5DSA== X-Forwarded-Encrypted: i=1; AJvYcCXYkYRr0XrIfvhwBQI4T8VxcyeDw9QA4eqB1F5+IjtGWand0+jXtQ8GuapIzuaSDFT2nb/t0SyPuy4=@lists.xenproject.org X-Gm-Message-State: AOJu0YxWahHNIBMmWAOWTpWRx0vMSzAq0uQhO33WkVqFe/sifKxzEYKd 3Q9YTTqlTAS83L1VTT2pEYa0KxeEttURUy58uwnRJTx2CYnVf/Dk5EqgGp+3j5fekg== X-Gm-Gg: AZuq6aK0nBWTWpCa9ToAf+DNN9uIpDEAt5MNI+UjN8pydXGW5pqWfioErzPPjlQ32HB MAb1fKJ9004TPqsvzD+yvLzHhVVFTj4VSLqPFltN63zKKIz7l9iaEEeoozMrSj2LhIby82uppZn xnU6AybVx60nOKhyUdtH2jXwyC3DxaR+xHsi7n5BkUR65zhjQmEi8RrDdKgsm89ASYylDYI06sN DerLKyMXIWG0YFX4WflHS1h7HkabJMoeYwGBC2j2rfWa/VyKa0ebiiM/nRCzD3YhOmaDWSqvXyQ UBSFwmgSooskbPJxeNcvh+KtZThK1r6ngiwdstURddv7t0CFw0B4U5leypR/ZH8OOT0VRtsaOUI myMBZUWvMZy5SqC5V7Sm3toR2dwMfm4FNYDk80R+hxYSt09M2sYv6Oc+MNxqVyjUN0U6VmTIAoK i1Lleo8afOx4d6nRI5XJDucvBA7r/qKgmORqLwVJpxEJQcnUFo9D1wPWFnmyQIo4IahHiy+6s6h aF6YKkcW3+3tw== X-Received: by 2002:a05:6000:25c5:b0:431:104:6daf with SMTP id ffacd0b85a97d-4358ff39880mr13942566f8f.54.1769066516020; Wed, 21 Jan 2026 23:21:56 -0800 (PST) Message-ID: <093938c2-58fa-4f8b-a05d-19bec67c5eb9@suse.com> Date: Thu, 22 Jan 2026 08:21:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver To: Oleksii Moisieiev Cc: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 21.01.2026 19:43, Oleksii Moisieiev wrote: > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -530,6 +530,10 @@ R: Oleksii Moisieiev > S: Supported > F: xen/arch/arm/firmware/sci.c > F: xen/arch/arm/include/asm/firmware/sci.h > +F: xen/arch/arm/firmware/scmi-smc-multiagent.c > +F: xen/arch/arm/firmware/scmi-shmem.c > +F: xen/arch/arm/firmware/scmi-shmem.h > +F: xen/arch/arm/firmware/scmi-proto.h Two nits: For one, alphabetically sorted please. And then, why not go with a single line: F: xen/arch/arm/firmware/scmi-*.[ch] ? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 07:42:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 07:42:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210423.1522088 (Exim 4.92) (envelope-from ) id 1vipKZ-0002d2-Cm; Thu, 22 Jan 2026 07:42:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210423.1522088; Thu, 22 Jan 2026 07:42:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vipKZ-0002cv-98; Thu, 22 Jan 2026 07:42:15 +0000 Received: by outflank-mailman (input) for mailman id 1210423; Thu, 22 Jan 2026 07: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 1vipKX-0002cp-SC for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 07:42:13 +0000 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [2a00:1450:4864:20::342]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id dc38d6d1-f765-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 08:42:10 +0100 (CET) Received: by mail-wm1-x342.google.com with SMTP id 5b1f17b1804b1-47edd9024b1so4758705e9.3 for ; Wed, 21 Jan 2026 23:42:10 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-480470474cbsm46588095e9.8.2026.01.21.23.42.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jan 2026 23:42:09 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dc38d6d1-f765-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769067730; x=1769672530; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=3E5sqRuBQgolxN7FI5gsTKtcwWCuLAPbpvFnWDfRTUE=; b=UY4udsxmaBGNbhY7GdxR7HM4/bKLp339jJfR3DDEoSwLiTRJV3yKAcbZIa12ICP10X fRJdlUK7TClT1giSmAoKPN10/+SUaWkxY8VqlLZb5cVAcUk/vaqCCm97pihK34hsmQL3 JE1iPhMYx/7p3x/0EbRcA6ZMfOhqPYHovLoLvPKekDBJ25ZDUSGdaFyPahxtPTAvGhYt 2D8NAqXX7kjNFhpbNmV3jk65JnjiFOBZA8TAD08eppAQtIzZ05fFWfc+o72hLmfWI/Cx h7s5UyL1WUg70q1PNNtdOAuCgKqJjg9NKxe5rvZ89//PxLhHUOTwWnL1nC5I/R97N8Rr sqIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769067730; x=1769672530; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3E5sqRuBQgolxN7FI5gsTKtcwWCuLAPbpvFnWDfRTUE=; b=lijF8l0RPfIYKl7z4HfLJkf+kQl3+MTqLO5S1K7czZqFUykcHM1Qm01vPEgi18M86u KOspzadaOJvQiddUkpT4OHQA0PIIIKYjzaQjhbk3Uk0/K/PPHCMRpM/FrtHiPdkxeDQM waxBOjrOv9rItSa9bW2TopGiwfv4Fx4K8iUknxJ+EemPjzbT22nwprl9bzxFAKnweHIj MNTjx373eRaIJp1wbrH/R7ri0z6BKujPiDr2QviYtpIjeh8hLmDAx5ChaVd1P5ucqH24 +V9kt3g85fCe9XolhzAR6NLk8NRC1E/hiOXe131z3PBUp28H2B3pLxjOdRlkkDVcKNjd RDhQ== X-Forwarded-Encrypted: i=1; AJvYcCXzLKEfO7qViGf4KlZHreKg79S5oG3mJ7F46IQ5ZwhqzO1BvNDUVTsEX9od5EQt+zJ6gRSk2CNsQh0=@lists.xenproject.org X-Gm-Message-State: AOJu0YwvnF+xBRUJFwGC1jTxS0VbgZfO8vwyABTx+jHC2JaQkR5M0lku SVk+7hjkfNkPYJ5ES/6mEUI0EZdE0Da6SikOrrErj/Wgsj1Fc8FqSZTPe6Tq9qq/Ow== X-Gm-Gg: AZuq6aIEQTQ/2kjBRvi2zdi6/DloahgTxMdBGllRzC2r/qJogbqbbZuOG8HzGFYzIt5 fBh0vNIisJRVv0/xMBsumpEXq6qOCBYRNPyol0tDXt0anNQ3rBqE5Bvpn09Onr818PJjJrcxWP+ oALHZsJqx95vcLY33GPLmUBl9BRSL729xjgQHo8+W9yd0NMXhaCk4VBOEwbwBr7gI3m2qecrog9 pzIHSxScD8tYAlUd3ZL2mw61/PnSwy+D/usI/GgPehUWmsAUsVDAJj9m3BraB0iLFGIpI0INdB5 /qcLl2CT6Kd3frvnlbDazMokAJ4zIqZUDsoAZkFsO5gjy7K9rilPCMHjn48HirrpTCmLxhS7iOf CnEPUm8xTv3PHFHTBNp8nmGY2eFw1FB6ah9XAIN5uNdmcgcML2xnOn1IHSf66qoKOE/jg+RxqNt b27P2S/Oh3iQfEF0+4XiN8BUew/9iNswGMhJ0KEp/CHaLoG0wwTH50PWIwVF0pPohjtH87c0VFH JM= X-Received: by 2002:a05:600c:3107:b0:477:561f:6fc8 with SMTP id 5b1f17b1804b1-4801eab9e76mr257829385e9.5.1769067730120; Wed, 21 Jan 2026 23:42:10 -0800 (PST) Message-ID: <313181b8-d204-4073-9726-1009644ccf8b@suse.com> Date: Thu, 22 Jan 2026 08:42:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 3/5] lib/arm: Add I/O memory copy helpers To: Oleksii Moisieiev Cc: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" References: <07fded74c7bc375a4e77596866072b65a546f8e6.1769020872.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: <07fded74c7bc375a4e77596866072b65a546f8e6.1769020872.git.oleksii_moisieiev@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 21.01.2026 19:43, Oleksii Moisieiev wrote: > This commit introduces two helper functions, `memcpy-fromio` and > `memcpy-toio`, to provide a robust mechanism for copying data between > standard memory and memory-mapped I/O (MMIO) space for the ARM > architecture. No helpers of this name are being introduced, as what's spelled out above aren't even identifiers. Also instead of the quoting we've been trying to uniformly identify functions in descriptions by adding parentheses: memcpy_fromio(). Plus, nit: Please don't use "This commit ..." or alike in descriptions. > --- a/xen/arch/arm/Makefile > +++ b/xen/arch/arm/Makefile > @@ -10,6 +10,7 @@ endif > obj-y += firmware/ > obj-$(CONFIG_TEE) += tee/ > obj-$(CONFIG_HAS_VPCI) += vpci.o > +obj-y += lib/ Yes, sorting in this section was already screwed. But why make the problem worse? > --- a/xen/arch/arm/arch.mk > +++ b/xen/arch/arm/arch.mk > @@ -2,6 +2,7 @@ > # arm-specific definitions > > ARCH_LIBS-y += arch/arm/$(ARCH)/lib/lib.a > +ALL_LIBS-y += arch/arm/lib/lib.a Conceivable generic helpers of the same names could be introduced. In that case this choice of yours would lead to them being used, instead of the Arm ones. IOW I think you want to add to ARCH_LIBS here. > --- /dev/null > +++ b/xen/arch/arm/lib/memcpy-fromio.c > @@ -0,0 +1,48 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#include > +#include Preferably the other way around, and with a blank line between them. (But see below as to the header being generic; if it wasn't, this remark wouldn't apply anymore.) > --- /dev/null > +++ b/xen/include/xen/lib/io.h > @@ -0,0 +1,71 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Generic I/O memory copy function prototypes. > + * > + * These functions provide low-level implementation for copying data between > + * regular memory and I/O memory regions. Each architecture must provide its > + * own implementation based on the specific requirements of the architecture's > + * memory model and I/O access patterns. An architecture may supply these as > + * functions or as macros in its own headers before including this file. > + * > + * Architecture-specific implementations: > + * ===================================== > + * Each architecture should implement these functions in xen/lib//io.c > + * (or define them as macros) based on their hardware requirements. See > + * xen/lib/arm/io.c for an example using explicit I/O accessors. > + */ The file name referenced is unhelpful and actually wrong for the Arm functions you add here. > +#ifndef _XEN_LIB_IO_H > +#define _XEN_LIB_IO_H > + > +#include > + > +/* > + * memcpy_fromio - Copy data from I/O memory space to regular memory > + * @to: Destination buffer in regular memory > + * @from: Source address in I/O memory space (must be marked __iomem) > + * @count: Number of bytes to copy > + * > + * This function handles copying from memory-mapped I/O regions using > + * architecture-appropriate I/O accessor functions (e.g. readb/readl on Arm) > + * that already impose the required ordering for device accesses. Typical > + * implementations may: > + * - Handle leading/trailing unaligned bytes with 8-bit accesses This is either imprecise, or the implementation is wrong: From context, this ought to be talking solely of the MMIO side of the operation. Yet if src and dst are misaligned with one another, you'd do the entire operation in 8-bit chunks. For devices requiring aligned 32-bit accesses that won't work at all. > + * - Use the widest safe aligned access size supported by the target (often > + * 32-bit on Arm where 64-bit MMIO may not be atomic) > + * - Rely on MMIO accessors to provide the needed barriers > + * > + * Limitations: > + * - Only suitable for devices that tolerate 8-bit and 32-bit accesses; it is > + * not valid for devices that require strictly 16-bit or 64-bit access sizes. > + * - Callers must ensure the target MMIO region is mapped with appropriate > + * device attributes. > + */ The description is now valid for the Arm implementation you supply, but the header we're in is a generic one. Imo, generic constraints should be reduced as much as possible, like dealing with leading / trailing sub-32-bit items by doing at most one 8-bit access followed by at most one 16-bit one (the other way around for the trailing part). Or else the header should be Arm- only as well (more strict constraints on Arm would make these functions potentially unusable from generic code, after all). Along these lines, "device attributes" is Arm terminology, aiui. Also, if indeed a generic header, why xen/lib/io.h and not xen/io.h (which already exists)? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 07:51:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 07:51:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210432.1522098 (Exim 4.92) (envelope-from ) id 1vipTI-0004Hl-4i; Thu, 22 Jan 2026 07:51:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210432.1522098; Thu, 22 Jan 2026 07:51:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vipTI-0004He-22; Thu, 22 Jan 2026 07:51:16 +0000 Received: by outflank-mailman (input) for mailman id 1210432; Thu, 22 Jan 2026 07: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 1vipTG-0004HY-LH for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 07:51:14 +0000 Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [2a00:1450:4864:20::341]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1f6b7512-f767-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 08:51:13 +0100 (CET) Received: by mail-wm1-x341.google.com with SMTP id 5b1f17b1804b1-47d63594f7eso5397245e9.0 for ; Wed, 21 Jan 2026 23:51:13 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-480470287c3sm48570075e9.3.2026.01.21.23.51.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jan 2026 23:51:12 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1f6b7512-f767-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769068272; x=1769673072; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=SyJeTi7i/D3MREEF/w/xuHxWikcUo5WC7W0cCWWhhxI=; b=FVvvwnNGTL9XOYdptjJW5PcyLVJV1XXABXBLeSEjKMidYa+yOeQUEL4Lf7k9c9OnBZ euPjUSt3U6OLDqEY6iqumjqxB1A3BEYXdhwnegjXJBtexkM9xrZYDjIsX4dbTNOWW7Kj dj+cm57l5f3n25uAtOVUYP6lfPsu6SPSp5LIOdWkZ36xLh/qx4H8YXDw01FEriAinydQ zf1wSlRq3XraDgNZkLngl5p+dmAm018zBcOkYjNTsrDqaqzWUn6x4h5VWCT+UFH2UdaQ L9fN9vZFWqGWzbibBKK5Ddqy/H7OjXq/MLDViPKDGfBqBi+8n5e+dBlcxvjs68RuBNQv ZcRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769068272; x=1769673072; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=SyJeTi7i/D3MREEF/w/xuHxWikcUo5WC7W0cCWWhhxI=; b=syhSmbQbH2/0G1bNZK94+aKpPlws4WAadaFCxKCjiuvMY+BzdvdRzOu8apNli6AtqT Kxps65csrE3Dc/18I8KUpIoz/eYN54Ggq6naYQ6s5BzrkLG95Vlr6axwOfEmJo557e/A M13+CKoG/5ZrwpdX/dO0/sGA0Op2yiipOZxeMpY4IuTyqhjPrDSL5Mn0miH/ee5kAhvT onpSA1/AF4TNCUAJ0NsRlZw7WL0xhbpsJwa4Xgipot7YtX60bibNGGpCW9PrHHe9U4jL Oj/HM3IoFPSW+ZfZioetsY3JbksRbyeaBLFp6XaxEniJCI9hguIduiE4NYf0o0DvHCGl YqlA== X-Forwarded-Encrypted: i=1; AJvYcCUX8vgEmJ4PyjH8+uD3eyZ4CMjiJcaUS1wjdAIOZh1ZDS8nLSYs7xBXlE/30ig42opFfmq9RjAgBaA=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz2U7ljkWwGPJMT2BsbI6NlmwR+C6qUBGcPOXwyLiSwS/VQ3jeh e4cME8A87/MjHG3NHUFbY44DzdSFH1BbevJldNsAjxX/Zqqu+eKLY6FSfiNqyvSVJg== X-Gm-Gg: AZuq6aLyQKmrlFhyuW3mDtXI1Yi5zIXgXbZ8vULF0iDjbugP+npZVZXj/WycyfgWgaP 40qnvpFyyVHGW7rsJGHGLXMJRwGabv8F3Zk1hL+tvKbvUcji6LJoxIS0KO14Q1tCymqkpAgd4dD X+fZ3LMyGHZpZ00JsYC0BpZqnL/iq1VmjQE4/F8OLSn8cYf85tLhCLEAZPufjqCqvqJprWQIdNV 4a2sVi6O+0WBAreK3wLRqsGJ32d5wfR4L6hvIIkLeV407iC0wxp+ghhxAd87mgomo7gupSi/M6A K84NdxBMd8BAbsdTSDNoCbviPLeX7e7uJ6rJrRsp4O9Y7aBSNcpPBkLD1Z2wAbuReJKoRR1bmrA y/9AIs2sTrgnyj+MCp6n+5EptaUx2Yo7+WHeX9CJvfFYYjHZeC8lPCpuZuAusjF+l0nMOahMDeH CobTfZ5xwitdag1rPYGtG2Fsv+Epz4sIecnWlrrsTVw9a72SqOO6589vckB71WnVZRs8G1puVqA DgUMagBhWtpzg== X-Received: by 2002:a05:600c:1387:b0:47a:935f:618e with SMTP id 5b1f17b1804b1-4801e30ba55mr320222835e9.15.1769068272498; Wed, 21 Jan 2026 23:51:12 -0800 (PST) Message-ID: <114d2326-112b-41ea-8c32-12b785f8e7a0@suse.com> Date: Thu, 22 Jan 2026 08:51:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 1/5] xen/domctl: chain SCI handling before IOMMU in assign_device domctl To: Oleksii Moisieiev Cc: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" References: <8482f823e945060d1a36469f14f94aa6251e3f71.1769020872.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: <8482f823e945060d1a36469f14f94aa6251e3f71.1769020872.git.oleksii_moisieiev@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 21.01.2026 19:43, Oleksii Moisieiev wrote: > --- a/xen/arch/arm/firmware/sci.c > +++ b/xen/arch/arm/firmware/sci.c > @@ -126,6 +126,41 @@ int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev) > return 0; > } > > +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d, > + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) > +{ > + struct dt_device_node *dev; > + int ret = 0; > + > + switch ( domctl->cmd ) > + { > + case XEN_DOMCTL_assign_device: > + ret = -ENXIO; > + if ( domctl->u.assign_device.dev != XEN_DOMCTL_DEV_DT ) > + break; > + > + if ( !cur_mediator ) > + break; > + > + if ( !cur_mediator->assign_dt_device ) > + break; > + > + ret = dt_find_node_by_gpath(domctl->u.assign_device.u.dt.path, > + domctl->u.assign_device.u.dt.size, &dev); > + if ( ret ) > + return ret; > + > + ret = sci_assign_dt_device(d, dev); > + > + break; > + default: Nit: Blank line above here please. > @@ -274,7 +277,7 @@ static bool is_stable_domctl(uint32_t cmd) > > long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) > { > - long ret = 0; > + long ret = 0, ret1 = 0; This initializer isn't really needed, with ... > @@ -833,7 +836,28 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) > case XEN_DOMCTL_test_assign_device: > case XEN_DOMCTL_deassign_device: > case XEN_DOMCTL_get_device_group: > + /* > + * Chain SCI DT handling ahead of the IOMMU path so an SCI mediator > + * can authorise access-controlled DT devices. Unhandled cases report > + * -ENXIO, which is ignored. > + */ > + ret1 = -ENXIO; ... this, is it? In fact, why not use -ENXIO as initializer? > + #if IS_ENABLED(CONFIG_ARM_SCI) > + ret1 = sci_do_domctl(op, d, u_domctl); > + #endif Why the indentation of the pre-processor directives? At the very least the #-es want to be in the first column, but I see no reason for the indentation at all. > ret = iommu_do_domctl(op, d, u_domctl); > + if ( ret < 0 ) > + return ret; You can't simply return here, as we may be holding an RCU lock on the domain. > + /* > + * If IOMMU processing was successful, check for SCI processing return > + * code and if it failed then overwrite the return code to propagate > + * SCI failure back to caller. > + */ > + if ( ret1 != -ENXIO && ret1 < 0 ) > + ret = ret1; So if IOMMU processing was successful and because of SCI you return an error here, why would the IOMMU part not need undoing? Or to ask differently, if SCI said "no", why even try the IOMMU operation? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 07:54:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 07:54:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210444.1522109 (Exim 4.92) (envelope-from ) id 1vipWq-0004to-OO; Thu, 22 Jan 2026 07:54:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210444.1522109; Thu, 22 Jan 2026 07:54:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vipWq-0004th-KC; Thu, 22 Jan 2026 07:54:56 +0000 Received: by outflank-mailman (input) for mailman id 1210444; Thu, 22 Jan 2026 07:54:55 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vipWp-0004tI-2K for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 07:54:55 +0000 Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [2a00:1450:4864:20::433]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a2f173f4-f767-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 08:54:53 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-42fed090e5fso398628f8f.1 for ; Wed, 21 Jan 2026 23:54:53 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43569921df9sm43894070f8f.3.2026.01.21.23.54.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jan 2026 23:54:52 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a2f173f4-f767-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769068493; x=1769673293; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=uy+/25C8wIOG9YLs0RH4n9xE0hTdhTudv1wLOOGooe8=; b=WB7Y6E60D68Q5YuuHyX/cMqOdXSspUxMnSbsqbZtzKVL/H4tKPamu644zr4lDxLbCz 4ZroHlANr+Prf2j4zIw+2Ov5rzH6S/e6wiw8EgQjMUnOM0vrlr+VzZQohFzfk5IMMlkD 1danedkAieN3lSChPNqcqv+cSdgDq1B4vjlGvW95lcgoOpNbWXe4hah7Z+M7EE9+9z2y lzyIRWSPnzAcJ1qrvgQDGV+uagoRHlojOghhV4tj7+9bUA+rrAXbNYzQ2YoAIwiF/vpk s1956GNUt4wT1ZV+hegW13X0PReYD+fU/tfYg7Y7zXRnseJ4DHxYxzUxCF66sMqDG3kh J1Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769068493; x=1769673293; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uy+/25C8wIOG9YLs0RH4n9xE0hTdhTudv1wLOOGooe8=; b=rqGBucgq0OIMZ+XBcD1cOL7cjmU/L3Rwyt3DxF5h+9MPgdzZTHnC79XhajXZwxVdya dT/3aUZZuD65eZjLC5e8S7rhFmlx2qVqohXd3pQB8FzAfUydXxQKRtlwarGJGdz7X5dG 9uzaBvyq2IZAQRQS2eJFBh51nIqY3cyJUNcOXPsztXQeBCEPPvCVW483bKf9BQbbN86i U1tHdGtrPvXVvyUF2K++QlmUNK7J4t9OMoiQRFAF03JiGlJvrCA5O98S3W/Zvi2X8zMG nqmirFWr8OwOrfSRmCP73/xdiKN4pz5uV8ki9x7Ud7lkYEW1CIclydYj+wJ0sEkG1w4D MqpQ== X-Forwarded-Encrypted: i=1; AJvYcCX4yKHbUs/EHiFDwXjFPTGrBLE6F+zKkCg61HBxdKR8wDMi8o8FQU7HQKhjyXkCz3LXJixC4WZTYZc=@lists.xenproject.org X-Gm-Message-State: AOJu0YwY3su/qtRrtr22YjA2ZHMYsEvInFXDIYkuFTDU//FPUgqfGzTL 8uVbi69CwUgaYzOIF7jypB5fLYc9dtJN2/W8ZZc5F63WR2i6vjGpwL8UyW3CxNNKng== X-Gm-Gg: AZuq6aKj+PDyNhpnzsYVHvNz3c4nJj3SH50hBShuCjOPGW2qhlEtm7Il/atoY+mwuA5 +NTemviNjXGjKcUJBPggW3775S4pY4up1C7PCVnNHxkHfXBjV3YQKDnXJjA4uRoClXCEGZu68V2 4pHowYo1jG+Er+u5wRUjV5qppZT5GEy3J6gI4A8BhsxsM7h7S6j1hPOYUGN4Go4cJOkdzpi2VZ8 5dK5KY8IA1czBi8LvkanMtmv9s3z3v600c3i80px2sRG97pP1LKYHc3z+M8PkD6fvsI7cBeUzvh YE6K9O76W4GhOJg9pbjI0mx2+lNwcQ3G7Rau1dq1iw8dVy5B9EJm2gLN9D9H3K+dNzHAxrVzbtU jw+/CKyF5C9iVoErxbahd8jNHI2fV//JUetWcimpw8DLzLp30ek2CSMjCkV15P4efEW56xTHHmi rvieaYDsUAR1NOPfocncxVaLBdsJuWRtD3Zj7FTpp6vplM4hqQLur/2Db2pIQtQc8YRcuPlZmOd jkz0WJTPnp6og== X-Received: by 2002:a05:6000:3105:b0:435:985c:48f8 with SMTP id ffacd0b85a97d-435985c49b9mr10065607f8f.45.1769068493178; Wed, 21 Jan 2026 23:54:53 -0800 (PST) Message-ID: <8f1fce9a-fc2b-48ce-8c50-2c18fe82e399@suse.com> Date: Thu, 22 Jan 2026 08:54:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/svm: Adjust VMCB comments To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alejandro Vallejo , Xen-devel References: <20260121174314.1465759-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: <20260121174314.1465759-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 21.01.2026 18:43, Andrew Cooper wrote: > The Intercept comments provide no value whatsoever. For the VMCB, label the > Control area and State Save area, which are the names given by the APM. > > No functional change. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Jan 22 07:57:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 07:57:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210456.1522118 (Exim 4.92) (envelope-from ) id 1vipZQ-0005Ye-4M; Thu, 22 Jan 2026 07:57:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210456.1522118; Thu, 22 Jan 2026 07:57:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vipZQ-0005YX-0o; Thu, 22 Jan 2026 07:57:36 +0000 Received: by outflank-mailman (input) for mailman id 1210456; Thu, 22 Jan 2026 07:57:34 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vipZO-0005YP-3F for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 07:57:34 +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 fc472674-f767-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 08:57:23 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-4801d98cf39so4794935e9.1 for ; Wed, 21 Jan 2026 23:57:23 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48042c3a7c1sm44415875e9.13.2026.01.21.23.57.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jan 2026 23:57:22 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fc472674-f767-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769068643; x=1769673443; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=hJ5QI+JCFKHvCKRoA5RCRgCJTYL60OewmCHZVlb1My4=; b=SjEpgt7DTp/r8AA15LRQ4paqNxup2LMsVkWcA/xPYIClFtXyOVl7OY6VoPDAIsZ/5V lrKoAWocBdk3Rw3eTnZMv2/PeiivKK32g96XXzM0u7cALXSAp3q4Z5nXa/THXUTC3AH4 1LeRzS3epOZexIPPE5TE29MXU/20bKyKqDCIftQe8vm5hRTIv5WhjoU7CZb8A5l+IT+2 SFNEZ69rfmHuUugeNA1BBitbmVob2TjvCdA/awbedcZZNI6vlJqDbir8LgQlvm50xSDP ASoVeqJ+ONeWEwdELaOyBCTV7dfchaHgSVxYs11B9XJYJgQn2ysi6LFQImN4f1Lw7e/3 hTIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769068643; x=1769673443; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hJ5QI+JCFKHvCKRoA5RCRgCJTYL60OewmCHZVlb1My4=; b=Ln1dWO/SX9HOy0pB/K3MhdOxCKD9FNPRti9IJ6lldKGfyBHRK3shfzVhxs6xfossAP IQnNwG0lNsXxNkC6OrXshKEeuIDfErjJIoSRhVVB60wlxAnavQP+9MmEve9y9kNv2Qxu 30PcfYw/Bo1iHBB3qY9LR+Dx4NrfugfCuuH6JxYvcubsf9SMVVII59pZ96e4/cHVezwu MS/WwQ7w/2GuvecAUu7ORNTnL0+jWiEW0O9FHb93AU8PbUg3VxGOpMy+ak9MystaHLgF lE/ethg9jmxuAcJFuAnyeIkRHRzSiSoIDhPgfOUnEMGO3vkWYl8DM9fhKGsHD8alh6bQ a6kw== X-Forwarded-Encrypted: i=1; AJvYcCXql9vd1BgP8e8PB+9Cr08FGHAlUGF+ISB7wiVbdNInxFwJ98rgQ6rpt84Ydofrck9sbgau6uOkuXc=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz3iZ48BN/3l4MytoQODs6nje75TBt8bPcbauyXg2We2EG3XiUZ S5cevD88vntDoqBl299BVoJ6pzOcCXsytQiC0b7GoJM9gVD92/wxkbsfl7YamXfkhQ== X-Gm-Gg: AZuq6aK+clMBoDregCYo6smGt+qMStwBPunCCvV7aDyB6qOJcaN+fDZSdbCORLWQW+B i6zSujew5XBdR7xIQ3DVNtv2dWg7FVpFQB8rVTKgH9LsSj70kUUJnQrgxrYFkuCi9QOiIjTRmV8 Q7dpAlgu7GlBthqLWtRzsoWpfrbDnCDakgL4D10RsxU9aXnmfSzQaVRSicODU14LFwkB9jrD91V Rl+oe15SGoeEPjZLrd5ShYB1klnjfphVHiUzinKIIkWGCb+pXmu4oqm80M47XUJcyfDLZZt0yR1 sTOyYA1cj6dQD4hdgnxLzEBQI3BZaDqMNYnEbvKbKnF2GGPDJ2b4m/vpMaoj4kEiJyvmxprCKOX x9EV5qZZ1Z7TUf8BiuGj9mPliMTJVeAjk/1dzvofutZ8lS8GXmYTFmDbI9zGxt0hXdPqO99DhwM 7Eew80EA9p8FaMndiLepIHKdqn7Kyq78dGrwfWfZgsi6UcfY6e6YA2iN0WtiFxVGhRLasp7yVAK H5Jr8cqEhQo4g== X-Received: by 2002:a05:600c:37cf:b0:471:1765:839c with SMTP id 5b1f17b1804b1-4801eb041f7mr275900315e9.20.1769068643023; Wed, 21 Jan 2026 23:57:23 -0800 (PST) Message-ID: Date: Thu, 22 Jan 2026 08:57:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] xen/console: handle multiple domains using console_io hypercalls To: Stefano Stabellini Cc: grygorii_strashko@epam.com, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Victor Lira , andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org References: <63c35c5e-577b-4346-b600-03808306177f@suse.com> <32d0a9a2-89df-4e20-8f7a-0f069cbff11f@suse.com> <873867dc-79d8-4ed3-94f7-1c7823db7957@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 22.01.2026 02:36, Stefano Stabellini wrote: > On Wed, 21 Jan 2026, Jan Beulich wrote: >> On 21.01.2026 01:07, Stefano Stabellini wrote: >>> @@ -596,8 +604,19 @@ static void __serial_rx(char c) >>> >>> d = console_get_domain(); >>> if ( !d ) >>> + { >>> + console_put_domain(d); >>> return; >>> + } >>> >>> +#ifdef CONFIG_SBSA_VUART_CONSOLE >>> + /* Prioritize vpl011 if enabled for this domain */ >>> + if ( d->arch.vpl011.base_addr ) >>> + { >>> + /* Deliver input to the emulated UART. */ >>> + rc = vpl011_rx_char_xen(d, c); >>> + } else >> >> Nit: Style. >> >>> +#endif >>> if ( is_hardware_domain(d) || IS_ENABLED(CONFIG_DOM0LESS_BOOT) ) >>> { >>> /* >>> @@ -613,11 +632,6 @@ static void __serial_rx(char c) >>> */ >>> send_guest_domain_virq(d, VIRQ_CONSOLE); >>> } >>> -#ifdef CONFIG_SBSA_VUART_CONSOLE >>> - else >>> - /* Deliver input to the emulated UART. */ >>> - rc = vpl011_rx_char_xen(d, c); >>> -#endif >> >> I don't understand this movement, and iirc it also wasn't there in v3. >> There's no explanation in the description, unless I'm overlooking the >> crucial few words. > > This chunk fixes an unrelated bug on ARM. We need to move the > CONFIG_SBSA_VUART_CONSOLE check earlier otherwise this patch will never > be taken when IS_ENABLED(CONFIG_DOM0LESS_BOOT). Which suggests it wants to be a separate, backportable patch? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 08:24:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 08:24:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210476.1522128 (Exim 4.92) (envelope-from ) id 1vipys-0001fC-Fp; Thu, 22 Jan 2026 08:23:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210476.1522128; Thu, 22 Jan 2026 08:23: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 1vipys-0001f5-Cj; Thu, 22 Jan 2026 08:23:54 +0000 Received: by outflank-mailman (input) for mailman id 1210476; Thu, 22 Jan 2026 08:23: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 1vipyr-0001ez-8D for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 08:23:53 +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 adeca11c-f76b-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 09:23:51 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by PH0PR03MB6938.namprd03.prod.outlook.com (2603:10b6:510:16c::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Thu, 22 Jan 2026 08:23:47 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 08:23: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: adeca11c-f76b-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=uzX47nrBqRlxBqmqq9r67p5WRr+8GiTBMjndYSgqehzcHrHgtOVCDHjChHSOuR6MRHrMxHT+rBk5v2jPvO7Rq/NgJLmWwCy/ZaKpbW2UUHnvLxPfEisR9j/SjFLq0mqNoSypTm7YFsClyXPbsAS8ac+5JUtRCStLz9xKd/cZHsCEs33Drlj9nT61cLqM/Vyqse55YH037pTH+/O0h1MzvEH27goeI5Yovoc7vl3B+uB6XXCmUN4v+9df4HF0D8TnjikbNt93XDJj1nQXf5LGs2gOa3/YDuiXAfIT8PDEuuoyJCPR2LfYNi3rMvdJndUKXJh9HvbjPZ/T7q7oKKQEXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jWx11zkhJal/3cG430UB5J5NPVmKeBxVAY+JCjZJie8=; b=yKn6A5lYb89WYaOiie9gqumaLsmJt1AYEPuvusqFuQl72udQzcuEz5EhZp1uOK8m7rEOmipDV27khGShjGCWKI1Nxv7GjYNE/Rv0/X3MjPxUCgJSK0eiY9adD0nClz/AmfYlYd0O2++ub8HR9nvasajj0sJ4ko1xXzum56p+ucq+cKwnMYhWZU5DSlcxe3hPK0Fw4uFyMY0qb/TqZ4OqW4ThuUjLdQNSfwI8WFW5Pp0Igl/sGQu4t0yhNaGKR8XYhqLJD5uCjsu7jWySqb1BjRiq00veAqWt9ZY1fDpN9IGrltIHslwK4rgJxhs1OS8NrXKWUYHOwLIaJyYI12l1gA== 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=jWx11zkhJal/3cG430UB5J5NPVmKeBxVAY+JCjZJie8=; b=Ytc+BReW8KGJxas4GBPDW0VsEkcj2VF26zEkCjF83lZKKpIVe9qtMTg2SuMO/YK8FmfGsSsGbFu736iVlKWFYSpDnSIE7pt4NeYCF35jgw3llmvouNcxdT7eUG1xJk07vfWj5OiPv82R7bel7g3XN+QW1+hb9wFTaPxSs96hcrs= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 22 Jan 2026 09:23:43 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, James Dingwall , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Jason Andryuk Subject: Re: [PATCH] Partial revert "x86/xen: fix balloon target initialization for PVH dom0" Message-ID: References: <20260120140648.25977-1-roger.pau@citrix.com> <634471a1-1185-4644-aeea-7891e62bc1f0@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <634471a1-1185-4644-aeea-7891e62bc1f0@suse.com> X-ClientProxiedBy: MA2P292CA0009.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:1::14) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|PH0PR03MB6938:EE_ X-MS-Office365-Filtering-Correlation-Id: 93d73caf-3410-4bf6-182d-08de598f900d 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?SHRiamgvSUNwYURRVXR5UjMwVEx1NlJaQ1RyTW5EWEw2NHJSZmFKK2p0cjA3?= =?utf-8?B?a0VPdzN5d0lFVTdQRVp4MXNlNGRUeDNXQUswcURIQWRkTWR6bldXOU5JZE5o?= =?utf-8?B?aWhqb3JoNFVjMWthYlJxSTZwQlF2L3haNldxeURPQm13SXVXZjdLVmI5QzRC?= =?utf-8?B?dXNiQlVwV0dwZm5OU1FrOGYxT3c1MlVDVXdLcjFwY21qdlFSaWFkNyt4dVg2?= =?utf-8?B?VUZ5M3hGdWtzZHNPVnVoemRockxCMVpmTXVTNnl4NHlEVUY0L2hlK1g1QUxL?= =?utf-8?B?SUFhNGRqZUt5SUVKV283Z2VvZWFJSFJNQWtvYm00Y2V1a2Q2cWtGcjd3S2c1?= =?utf-8?B?SFF4UGVBU1h1YzNldml0SlFXYmg3M1J5TlhGQWtBUzZic1duMUJ2VW9ERm9Z?= =?utf-8?B?OG42cEJrMWw1S1l2ZVBDTXZaUTE0eGhYU0h3OHNXVzhlaUY5RVRUL1l6dHVm?= =?utf-8?B?VjMzb3VuRWkzVDZodmsrUndtWDdTc3psMm9hQjhSMG1yQW15Y0dXOHZ3dXVC?= =?utf-8?B?VjNIYlNqY3o5SUdJTDVTUTYxVjU4UG5TQUd5T2dZSXZmQmNRNkpiVGxsK0lS?= =?utf-8?B?ZTNmSk9aaWVLU29zK1RPQkQ1emo5MnBiRlBBZGJrVC9VK3lDNG5VajBNeVdV?= =?utf-8?B?Zm50bHo0RHRkRzRpS3pyR0xNeXYvNmNzSkhpVzVQR090UkxObkh1MTZhQkFY?= =?utf-8?B?Y3BDSFlUbDZIR1VKUWJXVFBPYS9lZGViTVczQWprM1pTWmF1M3hDMTRlMnVC?= =?utf-8?B?N2tIbVYxVERkamNVNzlOOGZ5YzhyS3hjYUJhVTJ3VktVdEZxYUJkM28xT2pp?= =?utf-8?B?Vzh5eTVGQWRlRDIvSFk2V3l4ODFVVmVFV3h5MFBKeTZ5cyt3ZmFJenJXZi9K?= =?utf-8?B?L2p4Njg5ZzBENmtma0oreDZkVTZUcjVZVWtSUUM0d3lodE5pYXo4VXpDRE9G?= =?utf-8?B?MHh3UTdxbUhtQytFQS8rOUwrUmhhSFZVZEtTR3VNTS9NalRDc0RpRHRYSnRl?= =?utf-8?B?RWZEVGFBa1FOOVpSK1hFK044T0RIdXBOSGxqcGh2SnJPaUtyZ1lmRWJmUFd6?= =?utf-8?B?UkdJWFFBWTRtSkFZZDRMU1dSdzZBdWphN2N1QVJsN29scnJ6dmFBdG1Kc2lq?= =?utf-8?B?NWl0Z0M2OWFsZHRCNVNaR3pNZjc1eXdZM1U5NXp5WG5xamwwNSt3VXI0Syti?= =?utf-8?B?Z1p4WktxRHR1YVlGdGFaQ1lsYTQrZnNmdk9aZXY1SVJPTUVJdFBhUVVqbHVP?= =?utf-8?B?ZVd1OFNvTUpmVGJjcnB1dDlTZWovYmJsbHRWRTh1dXBCTVVLeWxMSS9VZDA1?= =?utf-8?B?SlZBZTY5eFVtbDlHb3lRSlUveEd0bFVPUnFMSm05a05mTDBoUzg2MXJIVXUz?= =?utf-8?B?Sml4L09zZ3dNUWhUWmpCcTFiOUxtWDdwS2pHZUMrZ2RndHFrQ1ZLYVZsMWhM?= =?utf-8?B?eksxZWdCaHRNT3BwY0xwaGFzKy92a3dRVGtmRjdtVHNJMkhsdWVSR0kydndm?= =?utf-8?B?Um5NaUFtNXE5ZUFTVnYzcEpnby8yYVl1Y0p1NDc0ODBkT0paSmhaODl6SzhG?= =?utf-8?B?d3FCZlVDTWVkdDQ3UzRNTi9UbjBHb3diTmlkR2cwTWJSVkVQUU9Da3VwZlRr?= =?utf-8?B?L1E0TWUvbjYyblYrMll4amxtNC9Ed0hMMjJFdEFwd0d4SEZSUHVneUEyZUJl?= =?utf-8?B?K1M4VC85L3pJTjl4N3lDOTZNbHk2bTBpUmUrbHh0d2dhOVIzS21aMndFLzQy?= =?utf-8?B?MnExcFhzTlROOGh5TkxPcDkzNDlLRDlRSWxQQWpsZ3A3U0I1bE1DYlBzRWJi?= =?utf-8?B?czE0L21mdW1WSE5NV0VJUnpIdTJDTDM2akFTRFlmWkg1Z2JzSzlxQWdWWU5J?= =?utf-8?B?Z1QxU0l6RFlMeTFpcHhkSllyNUU5b1daMFc3UCthVThUaEZ5U0RjUnFoVlV2?= =?utf-8?B?bW1tdURPaEYwNTg4UU9rVjJtYSs4UTk4RTl4QUxycFlmNmtjdGxhMTFSSGVM?= =?utf-8?B?NjV6ME5IN045ajV1Z2tPRnNjQm01ZjlMN05tbUwrZVZIdkh3LzN6SzNRblht?= =?utf-8?B?MEthRlpVZG5VSmhCc0NudklPRFFMeWVmNFpTRTUzQ1dydWRiRW5nY3Y4OTMy?= =?utf-8?Q?BF5M=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cW9kdWpjcXBJZk5kMks5UUZIYkRrOWw3QXdxMzBVcVdvNnJ2VjB6MHlyZWRO?= =?utf-8?B?MGp1NkVPOHJDcXRWL3Fnbkl1UVBsWis2MW50dFlQUFBvWGJjMk5JR04yTkhZ?= =?utf-8?B?dlJKTkR2UHVDMXA1SWY5NVlQdWdYZ25POVY2UExOcXdDOU1hdmV2RlFjVWg1?= =?utf-8?B?TWZZeG5ZQVRVZ2ZQOVNsd2NEK2M1NENlUVh3R3A3clFVVDVXTWFSUHFGRXpK?= =?utf-8?B?b2E3eWNLQ2lTMlVzeEpTVmd2TCtwSFRtcTM4Z2wweksrM0pEa21LRzBFQ0s5?= =?utf-8?B?d3dQQjJPM2xzaFhZV0pRSHF5QlZCVXhHeEtISmVkZVJraTVvYy9aWmQzalhU?= =?utf-8?B?L0ErVERYYmVwQnYwR0FvQm1CekJQRTAzcUVZdWxrbHBzUDUrUEM5a1Fwa2wx?= =?utf-8?B?b1BYVW5uR2JBRVNzcHVXNzJzZEZlMnJYbU54RU41V2g1dFo0WVNZZjc0MEFY?= =?utf-8?B?QjF1N3A5K0dBWUkyVnQ5ZWRVWEtSb2YrVThaaWhjcUZVQ3RkNHdySFU0L1dw?= =?utf-8?B?Zm9xMHg0azJvWjJrMVFETmVYTmtranpSVEJ6QjVEbE5tNXp2bkg0ZWRiMWVS?= =?utf-8?B?UXBxZXB5aXZOWlVCaktmL1Vsa25UdkJCUmRhckJjbGRMa1V0RUV1M3R5bXc0?= =?utf-8?B?UDl0cUMxbzFVMlFJRmwwbnV6Z09RSHNaQVhyNVJTWjduc25NZUhCTk9lVUcw?= =?utf-8?B?Rk93Y1MyR0taOGw0b2xLdDQ0amRxd0FGZklzSitXSC9sWkFGTDRuR1BoR3po?= =?utf-8?B?ME1LOExFNTVoZkF5M1pCOEJQazBscVk3VFgrV3E2YUhUN1M3VmRMU2ZCQmlU?= =?utf-8?B?SjFZVHdXeUZ5Zmh5QVhYZHlWQS9GM1IvRjlZZEovVW5qaDBONUh3UlBzMkhi?= =?utf-8?B?MGdRV3ZTbGxyQ1ZjbmRoUUVHM2hUN1BXMGgyeEczSVdyWWNncEFOeHZjSGRS?= =?utf-8?B?QmEwTkN1OHRPYVltVHA2bXdTaWdyRm9KYm80ZnRMeGZiTUtHQit6MUVoeDVV?= =?utf-8?B?U2x3Nk5rNEdjNWhFdkUrWHpsSnVOTEJPKzR6bndrekpxOUNWaHh1YkJtcFdD?= =?utf-8?B?QURwdk1KckY3NkVuS0V0UnNjWU8xQW1SbmlzWXMwU1hmYy9iTEhMd3ErK0hQ?= =?utf-8?B?QWtxSytiL1k4OW5rWmthMWNUWkxlcXF1RlI3b3ozeWFWUzY2d0p5WDVIcjhG?= =?utf-8?B?ekk0QUZyNExmcWxzbDVhU3RFTzNudXZYenV4cGtUR0s0VzYrUGd1d01yN1Z1?= =?utf-8?B?ZU8wbm9UM09tK05NZ2tYTGRPU3R5d1Q0ZzF4Qyt4K0JiNmVJckhhRFAwcnpM?= =?utf-8?B?RVcwSjFMSTJGOG1yVGorTFhtWHlTSSs4enZoVWJ4LzJBUTRKUkJ4SzUwVW5E?= =?utf-8?B?RUpnYllRRkMwVFNKNHlEM0ZQdUtWS2FRR1BxdkpDai9ZNjdTUmM5TjgrZHFm?= =?utf-8?B?dThncmhOVGpsdkl3dkVBTVY3bnA4YXdQeEhpclpCUVpHb0tWck9WUktwU2xS?= =?utf-8?B?ckRDUFFFRndLcWhNYjJhN0dwZ1NNVTIzUGdmemFSL3ljQUVJNkNSeXhTNDB3?= =?utf-8?B?a29GL053aHoySGMwYjI3cnEyVHlYeWY4SU1kN1dlNGV0OXpxc0NUVEtKNWVq?= =?utf-8?B?OEEvV2J4bDFqc2YxYUFnempIY1RaakJYT0Q2WDJsNUt4NHRqVW91b3U4NEFt?= =?utf-8?B?dGdieDNlTzh5elZzOVJLdHQ4MUtURmJUSGtsVE5IVU85T0xldTJzeG1ZWEEv?= =?utf-8?B?SEtkY3M2eXZpRGZtVXg4VW10L1h6cHVQbXZiNWppWVVLYThoZ3lkMTVlZmUx?= =?utf-8?B?T1oyZUY5MlFkdFh4RHl3NE1iS2R2VUtjaGd5RUhFWjg1dUFQMTRQVUpreVR2?= =?utf-8?B?dThYRHY4MFRWdnpoSkdHeVU3d0psbVRZNUVESUkxTERRVmhRNHJOcGwzWGgw?= =?utf-8?B?eWpLVmNza1ZRWE5WZkdGd05UN2NGZ1J3bzN0Y3ErSFlsUlg2MzhVZG1pbGFo?= =?utf-8?B?NkZIb09Gb3Y0RHI0bWFMRXo3MHg1RVVlczdTTW4vT01qMkN4amJzRHpRdTNI?= =?utf-8?B?WXNkOGE0NHVNUE93S2M1RnNJWnNuQ2E3SzhOanFaQTIvZzlPeVFvRkVqS3h1?= =?utf-8?B?ZDhNMEFuNHZMU3BoblBxb0hsMGZvUW1MNWV0aFBCOWZQTFpmeDMvZFZZQTJ3?= =?utf-8?B?Z01aVVJYZWtQbmdKKzhpdmdVemlnOTlIMWVxQXROdjJFYnVVbDYxSDJKNjVp?= =?utf-8?B?eWJnUWZYQ2ZzQkJjY2trSTh2S0lZdnVEMzNqOVAzV1o2bGFqa211aEFYM1dL?= =?utf-8?B?TUh6WWRpWG5mQVdHWGJTY0hCb3RXcTlweFlVWFlaQVlyeGpRalh1dz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 93d73caf-3410-4bf6-182d-08de598f900d X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 08:23:46.7696 (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: qTEcWNEgdpiBgoCWRQyBVBVZBpFp6yvjXQTp3zH+w3IaaLqk6MqoV1B7PAosU+xiEQAACiRYNSj+HtKXuqproA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB6938 On Thu, Jan 22, 2026 at 08:17:22AM +0100, Jan Beulich wrote: > On 21.01.2026 18:49, Roger Pau Monné wrote: > > --- a/drivers/xen/balloon.c > > +++ b/drivers/xen/balloon.c > > @@ -724,7 +724,8 @@ static int __init balloon_add_regions(void) > > static int __init balloon_init(void) > > { > > struct task_struct *task; > > - unsigned long current_pages; > > + unsigned long current_pages = 0; > > With this, ... > > > @@ -732,8 +733,13 @@ static int __init balloon_init(void) > > > > pr_info("Initialising balloon driver\n"); > > > > - current_pages = xen_pv_domain() ? min(xen_start_info->nr_pages, max_pfn) > > - : get_num_physpages(); > > + if (xen_initial_domain()) > > + current_pages = HYPERVISOR_memory_op(XENMEM_current_reservation, > > + &domid); > > + if (current_pages <= 0) > > ... why <= ? Gives the impression you may mean to cover HYPERVISOR_memory_op() > returning an error, yet that'll require a signed long variable then. Oh, indeed, current_pages should be signed long. This was an untested mash-up of a slightly different patch, where I didn't realize that current_pages was unsigned. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 22 08:27:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 08:27:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210485.1522137 (Exim 4.92) (envelope-from ) id 1viq2O-0002HP-Uw; Thu, 22 Jan 2026 08:27:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210485.1522137; Thu, 22 Jan 2026 08: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 1viq2O-0002HI-SO; Thu, 22 Jan 2026 08:27:32 +0000 Received: by outflank-mailman (input) for mailman id 1210485; Thu, 22 Jan 2026 08:27:31 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viq2N-0002Fr-1Q for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 08:27:31 +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 303ec741-f76c-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 09:27:28 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-4801c731d0aso5154855e9.1 for ; Thu, 22 Jan 2026 00:27:28 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804705b277sm50856265e9.12.2026.01.22.00.27.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 00:27:27 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 303ec741-f76c-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769070448; x=1769675248; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=xa2uxM+IG3DuME+srypNySynCcFVcooq6Q82WVDSmwA=; b=R+6w5Wu/ZMh3L+a/grNn1T2TlBo025vXTrqryVvbNWZxdzao+MpYMLXCWxaMnY1n9b MtS1rdls5XuAIu27FhpLlexMHNSCTxf31b+uQWpwHjSsSqWAsmwd+9v4PLdH4obb3PBu FC16Hh6Ds9TJMlJSwZjzQloYelTq+KB9DSSIKYmtDQtn2e+nMd6lvZM4XEMSILdMzys2 l/jmhECPpSWwGyk2KA0He34VCGH/NZt6q9ZAoUqhgLcyrwe1qQH9zK8xZjpxp25/9yra OnrRPSjMxMpabYxOGOcWqneAYdO7syEB8lvGQAPbntcrrLTW4oZmUJpuVFyBFm5SA1d7 KHFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769070448; x=1769675248; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xa2uxM+IG3DuME+srypNySynCcFVcooq6Q82WVDSmwA=; b=LetbVDLmz3iOqtsgTTfCIZ2EiiQFPLAP15YUXfK6glZpahJA+tNMX86Mlp6Ssmid9c iWS/gbLyj0bnie0/rjX4mujaFLOMvtfIcWljUumbAKwymOKvr7qlm6f7uKex+A9GxM2I lWVMhHQYQ42eAfjMaDzXFfA+NTyLMD3u67oq5Tr2hJj93xZCRYMDcKbE6bMKkEfj0vh2 2PF9W/iunsEubx4kStkNAtGXjn8k7WGohNhTE1Pai5/sZ2kxgKVT805a5WamlBIriBt4 AxMBtqHMsgS+sC2cOSA5MtiU7Vc1juzRqvljN5ATASDpHjLO309JlaqAI5QM3/aotnOR yxqw== X-Forwarded-Encrypted: i=1; AJvYcCXT5+tP1ympjn10ekopL8Ev40Zm6WMLlclkrmjlbsqIRUdNelLOioefvb4LnObItz8W4HDHUOd6mLU=@lists.xenproject.org X-Gm-Message-State: AOJu0YyBSwLzJd2tEb9T2o0ERA1ZFjbafNZASBnjDB81YKFszvGLSL0x n1BXlzwe9wuhcym+sawR6djV1VRnG0ZVH+N9j9XFQuknJP3J17raLPplbitsfnxFeG1xlKw+kdQ Uvik= X-Gm-Gg: AZuq6aJh8rTwQNUIfoAXZSirB8Qn75YbzicydWam8R8W01WP3lF4wC480h8DFAwHSOO MB6f+wRMSkms57g0CTM26e4gbsowjAfIvOG2pFyANuAPMDsx39WlzhGk+9iKul3ZNix0dUjvRx2 Cki07kWXiXp9YMe8U+ZCIhF7rzUEIY6Dw/Rnf3F26UI3PjWQ9NAfEIc8t7Bc4QR75kW9ucxLPcv d3ODvt2IKEMYRjQzca5YuENrQv7eUouxqb3AqPUFPcyOQhJ6htTexvqkgcHRCG7BX5n25HTRLOI jkj9WybmmCxJydUXiLxdP97p6ObZjgdAzhY3Pofm1VovNmDCxczjgiCBZJfyb+8IhOmS8CX8Vti 8c7s2cZwt462U43/YRqmTzD0mZt3vWBpS/7qS2I0PZ5GPHIrddUGHcFbDmBDVZI/RbBTSiIeR0v MXWtw+1EZTOb8/SubPRGMBqEWusrn0P9MX1YYtTF0bN8vf9AZ1JRMZ4sXE6j5hVnhpN//gj+AxX 6w= X-Received: by 2002:a05:600c:4e43:b0:477:73e9:dbe7 with SMTP id 5b1f17b1804b1-4801e358875mr284169175e9.35.1769070448132; Thu, 22 Jan 2026 00:27:28 -0800 (PST) Message-ID: <5948da25-0b4d-48a5-983f-0fc9424774b3@suse.com> Date: Thu, 22 Jan 2026 09:27:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 2/2] earlycpio: lib-ify earlycpio.c To: Alejandro Vallejo Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Nicola Vetrini , xen-devel@lists.xenproject.org References: <20260121154757.44350-1-alejandro.garciavallejo@amd.com> <20260121154757.44350-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: <20260121154757.44350-3-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 21.01.2026 16:47, Alejandro Vallejo wrote: > --- a/docs/misra/exclude-list.json > +++ b/docs/misra/exclude-list.json > @@ -121,10 +121,6 @@ > "rel_path": "common/bunzip2.c", > "comment": "Imported from Linux, ignore for now" > }, > - { > - "rel_path": "common/earlycpio.c", > - "comment": "Imported from Linux, ignore for now" > - }, > { > "rel_path": "common/gzip/*", > "comment": "Imported from Linux, ignore for now" Judging from Andrew's https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2277362625 this doesn't quite work. As I had expected, since the file is compiled unconditionally now in its new location, some violations are now also unconditionally reported. (Some, checked for at linking time only, may not be reported anymore for the *-amd analysis jobs.) Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 08:29:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 08:29:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210498.1522148 (Exim 4.92) (envelope-from ) id 1viq4O-0002w9-EF; Thu, 22 Jan 2026 08:29:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210498.1522148; Thu, 22 Jan 2026 08: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 1viq4O-0002w2-Ad; Thu, 22 Jan 2026 08:29:36 +0000 Received: by outflank-mailman (input) for mailman id 1210498; Thu, 22 Jan 2026 08: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 1viq4M-0002vw-PQ for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 08:29:35 +0000 Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [2607:f8b0:4864:20::72f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7a49b83b-f76c-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 09:29:33 +0100 (CET) Received: by mail-qk1-x72f.google.com with SMTP id af79cd13be357-8c52c1d2a7bso200367285a.0 for ; Thu, 22 Jan 2026 00:29:33 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7a49b83b-f76c-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; t=1769070572; cv=none; d=google.com; s=arc-20240605; b=avXR1E9lz6o8AjEMeuC9cOTKIpdsP/FC6k1rQcbyY3KFW5qIyikb3NOZT7Ru+bj8Hg P804ItQ1bRxXC/D3DrgzrMf6m86RjAG2wlk+KIz2X1PFIUdrxo6ZJnfb27H56nRhJgIS CKu5A5gzypat7WbIk/qx0IPc458BxeqZ4K7u8tsi/5wLJ3KPN9uQyXj9jbQ7u8u897KY cKyWGthC748n2u0H4UtCL2sia3ajJN/SZ7kbsgLHnkFMVbuB6363afSQyYC1dok3jbH8 4mQ9pbGK2Qh1PETBSMTgZg0J44MOxxE2mvnGAY3S4HnJcIZwj4/gkBl5BR7inBz9PwFS YTjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=/tzrRzNe1Oo179OoUJ9uBcIR8npvWm7/ge/DfccjyDI=; fh=quJY5mN2l4ZorNvEoO9ngNXalhEvTdq/+W8CvHWhECs=; b=GvSQFFbJfcXTQIbkTgRGQIrm8OGiaRez64B6L+2mB05B2A/A++A66HDxar4jDAXS+o rdEdtxagbqVt57mf0DcsG9iDJhWvpRgxKiOG50lQpqosfaMXWWFl271zyOQxqJ9Z3ihM 0wgScb4wzAsUzHAUJsRjJQYJE/OvGBxYDWD2SH08dciWtJ+B0qPu+HguMeB3gO/Mo1yy Ky5qmtmhwbZkyh4r5Tqrvz1kfJHLNfBfaTuY9ltbiVejG/4ahCcNqX7L7iFHUxh7FMrV 5n5rrop2VpsU5mvXvVSDe04khrLRJF6kBkI+a2+8q7tYivctcDWADHN+Lc63yMzA00O2 C1Xw==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769070572; x=1769675372; darn=lists.xenproject.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=/tzrRzNe1Oo179OoUJ9uBcIR8npvWm7/ge/DfccjyDI=; b=IkW6/ar7pWaJSwLg58kk78kUApZ/SDq+wbo7lNEb9BTGeasHHrHRexS+E4120cYseG jFfkFEURcUSOF2KvgeiSjVmXOFC1nZpBLsF1/DW6DRwQf77GQFNKlinb51YSgw7sLGEj GT2+JJBKtrt8a3MDhhwFkYwwE4EItqsJaW0AMUCoSmfBO05dwtWLTkALUt83btrhdxtB JO6ZoYxiILVcQoY2uFikJizyA2J+fy3BChhJJHLR1ZpMp/U45pT/z1KwSH5ZqLTVPlYt DHuKuCtSR+Ix8r2rUVemDyX/cQdAeS7nyeykKCh3bXT4T8tA8SpO5R3+EOqpwwAVlsvG fS7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769070572; x=1769675372; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/tzrRzNe1Oo179OoUJ9uBcIR8npvWm7/ge/DfccjyDI=; b=N5sYxw7YtQ4kB5ZXI32DL0sfhF0BFtApD4WePUVNtuPSB78mBPLBrOmv8dbCRUm/yv 6uj7y7p9ixdy38lgldmdVDd7w6nPP0DdbO434F/00DcLuxI40/U/GeP9yXiChAZ+9ssF 4TrXSxRadbvfU05/nVZjm1m+0Nnf+rc01qSvGSnAH3fYyYfEHD0KFNozXAbbxu9b3TMZ zn0pzEFNyZQmSC4bFYtcsF8UWFMcxudHJwCzAjeHp4iwe7X09n2bMEeQlaioZ8MCsx+x /oPNzVWTOa3xxZwQzYLwAh2Rm/a+IVlvvaifALYpp6ZkeCqdOpvjm6TJEl/sEg5l4Iy6 WEow== X-Gm-Message-State: AOJu0Yx66qsl2htcUe92vTM41D82h4uBDi3IFZX6pRHygjwi2q73ihPN S3GRKCZO0BNztxzwU7MbOn88nr+qfk5pjglrHdhenGD193doNj73blDSJft+sPLzseAJRzwQBn8 /iyrujc6yiRXs+jsCF8tLTlZYmp7nQTj/gWUi9SI= X-Gm-Gg: AZuq6aIvl5oMNcNQ5So37NWpy+NSa7X7GzbiSNKTo7xweAlPOX2My/nUTJvzoZIFnGj AQYKbTuFa/5UZ9fmM3B4bZm1noqtJCvn2tmO6ryzDhS/GZIyom9WJtZ4hZueyGkmjw91L3Nydcx 6r5WiEAff4PbMFX0KQKmFiDlJxyPQzCXNp8tsJMCMsX+7MCwz8aRYXBYUj4ZbZR2zObYCwFdzk/ bXMnbH9Kq6/FoOsBzrOe3YekVY85LFbp2KFFS1Rj9JRuc/7V/qA65jD2CajLFxACEgUfQ== X-Received: by 2002:a05:620a:1a0f:b0:88e:1be9:cf65 with SMTP id af79cd13be357-8c6da8f7ba4mr298937885a.39.1769070572184; Thu, 22 Jan 2026 00:29:32 -0800 (PST) MIME-Version: 1.0 From: junxiao wang Date: Thu, 22 Jan 2026 16:29:20 +0800 X-Gm-Features: AZwV_QjZwnAYb_jjm-IIETxsYSuRNw5RUypPs2NUttAkdOFZpWxS34TFkjSk4DU Message-ID: Subject: [ANNOUNCE] minivmi: Zero-dependency, minimal Xen VMI learning project (<500 lines C) To: xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Hi everyone, I would like to share a small open-source project I've been working on, called minivmi. Repo: https://github.com/ania0-art/minivmi Why I built this: While learning Xen Virtual Machine Introspection (VMI), I identified a gap in the available resources for beginners. Existing production libraries like LibVMI, while powerful, utilize heavy abstraction layers that can obscure the underlying mechanisms. On the other hand, while Xen includes a test utility (xen-access.c) within its source tree, it is tightly coupled with the Xen build system and lacks educational documentation. minivmi extracts these core concepts into a standalone, zero-dependency project based on Xen 4.11 and Ubuntu 20.04. It allows students to build with a single `make` command, serving as the "Hello World" that the ecosystem has been missing. What it is: minivmi is a "bare-metal" style VMI implementation written in pure C (< 500 lines). It intentionally bypasses high-level wrappers and interacts directly with libxc, xenstore, and xenevtchn. It demonstrates the minimal viable path to: 1. Enumerate domains using libxc. 2. Enable vm_event via xc_monitor_enable. 3. Monitor CR3 (Context Switch) events by manually handling the shared ring buffer (req_prod/rsp_prod) and event channels. Current Limitations: Currently, the project focuses strictly on the event interception mechanism (Hypercalls & Ring Buffer). It does not yet implement software page-table walking or memory introspection, keeping the codebase minimal for understanding the control flow first. Goal: This project is strictly educational. It aims to serve as a white-box reference for anyone teaching or learning Xen internals, bridging the gap between theory and implementation. I hope this might be useful for the community's educational resources. Feedback is welcome! Best regards, Junxiao Wang From xen-devel-bounces@lists.xenproject.org Thu Jan 22 08:50:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 08:50:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210512.1522159 (Exim 4.92) (envelope-from ) id 1viqOO-0006sP-1d; Thu, 22 Jan 2026 08:50:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210512.1522159; Thu, 22 Jan 2026 08:50:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viqON-0006sI-UE; Thu, 22 Jan 2026 08:50:15 +0000 Received: by outflank-mailman (input) for mailman id 1210512; Thu, 22 Jan 2026 08:50:15 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viqON-0006sB-FC for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 08:50:15 +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 5d77eade-f76f-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 09:50:14 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by BLAPR03MB5652.namprd03.prod.outlook.com (2603:10b6:208:296::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Thu, 22 Jan 2026 08:50:09 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 08:50:08 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5d77eade-f76f-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DPy7EP3B2M9VsSUa0/L5/2J0hQeWLjb6qdaUlYlz78lBACO1gIQlqsweMmN7cs/zuKqNpTdca+U67Dq5O2YVBa+YJN9PJ+N6wL9oXTpphB8UiDqh4vlo39qHgsPKGqYZKs7u47wTSEInJFja17jwL6Q7WKOU+0h3j7cwW4SoWhQgnTr+T4eWxTAKI3u5G6scrWHbRDjVbUsPPM1FUXoguRmELg9GMBR0Efo+K8RtptQ1r7JF5n6KMdnk7GW/MgEw8rw6tD7HktdeC+12YYsfmLuPV2DwgUlQqM+u8vn95VquouLDB42hGcRyNrLx8rPydjEkEICUdCIhGuYr16yK+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=q3iOoc/nuBc5WkLGONORTWrb2TgKuY7zFb0BolB3EXs=; b=XifPg48VbS+/QGBnFQ3+9WAuIibUUHcwYjfd618kkZdeM+7D9mLeZAK1yKqw7iJSVXzo9An2iC1JpMqVEae/ZzHSdfKnvR7HoW+HVwRJHFrgwmdXF82baxyuqcNTdgD3y0VqOMrmIJ3rpLg0wji/d2fW/YRnUzLeJsYzy9O5cUNQ9PmD+JsqoVCEziBRc2KK0MLtiRtR1QdfY7mtca4rO8N62wPfYuIF1I7UiWCdPBR7zLShxjGy+3c1qL4kxWkm1J5hmST6eoNiTdrBlKcJljBO4ZAZ/09t8G7f6kdhvX8J096IBJAndoYc5/VCB1ID8eGk8+utQCmVTRnHsaxVjg== 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=q3iOoc/nuBc5WkLGONORTWrb2TgKuY7zFb0BolB3EXs=; b=qeYqqPhUsJOLhL14hh4UClLQbe4o+WsG26pwoLpq3zDCYWXyskgbwGXDsSxZofmoX9PUbdnJu5KBvnOnADRGbuLSyNM/iFaD1i5a/VHSAh75iVeEpUPxVV/WmpqiBOXJ1JIOE15d+B2biS3OnEKyNrbCmWtX3CjMDrMqzoTeU98= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 22 Jan 2026 09:50:05 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH v4 3/8] x86/HPET: move legacy tick IRQ count adjustment Message-ID: References: <57f34114-54b7-483d-8ac0-e9fa49df959f@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: MA3P292CA0013.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:2c::6) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|BLAPR03MB5652:EE_ X-MS-Office365-Filtering-Correlation-Id: bf196b5d-be88-4717-5df4-08de59933f17 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?ZjVtUFNtS2hUVjVNWkdSVEhKWkw3d1lBU0dZd2lYL0RwUDM5YWZmc2UwNFM4?= =?utf-8?B?YnB1aVYvWXJrMnlrdFU3VU1SVG5sY3B6MWh1d2svZjJMalN3QUpMeVYrK0w2?= =?utf-8?B?Z1J0MEFBbnZhQnduRE1Hdnh4cnNWNmdPTDhCOHNTcm1WQTRvU0gvTlFaZTYw?= =?utf-8?B?bU4wbUZSMG5xc0ZraW5Ob0toRCtZeEdzSVRXM1ROVGQvTWpkT3JVVzJlQTVB?= =?utf-8?B?V0ZieVZ6SllRdjlXNk1XVk9QMFVQQUhxb2JsZEt2THA1cUpTSzFVNUo2QW02?= =?utf-8?B?akJ1eTNtOFFXQlVnOVQwdlRmRXhYZTI1UUo1azJJQjNjV2g4djFRa2t6Ums4?= =?utf-8?B?NVN3NFFMeFczbE5VbkQvRGg4V0s4NWdsL2ZjblA5djBCSTBFVjhob2M3UWRx?= =?utf-8?B?STlMTGZnbm9UZmVJVU1oem5CQTJSU3NEVzJzd3NPcHJ0RFI2ZWZJMS9ETFlV?= =?utf-8?B?RVdaS2MxajBURzY4ekhwYXRjR3o5VzJYVzdsZ0pXd2FweHNmRGhUeTVqRnlW?= =?utf-8?B?bDdYb0ZDblB2Z1VlREZrQnBjOGwxeCt1L0xaRFRxdGxRQWJBdEJjSTBuQWdR?= =?utf-8?B?bnJ1T0JWNzN1Njd6RmZzZ0FvbVRpV21KVVdTcFJHSmhYODJkUFhkQ3pHbldO?= =?utf-8?B?Q1RXdHBnSjZwRjhTWGh2aldyT1ZwQndnQWNNYWVFMTRmSjhVbmhRcy9ZbDVU?= =?utf-8?B?TTJHbmNOdHhLMlBnVW4xQVBibkZ3MUNINlBrMnNVY1E2M1NHVEtmNEVRYSs3?= =?utf-8?B?U1dZamVDaGtOTlJGUm9zRGJpRHVRQlRCMVRJK0Z1T0d5ZWdjVW0rV3U4bTR4?= =?utf-8?B?OWVJcGFoUXdqN1RJSGlnVEdWekN0RVIyUHJQYjV3R2hCM0pIYWJpVzl6UWV5?= =?utf-8?B?Vm9FVTgyWDFYZVZiNGhISkJvbTRFVWtSaERhZ01BYU5VdDVNaXJiSHBoaDZy?= =?utf-8?B?Vmg1Tk5JOXJFTkY1Sll1czBlaDFrRVY5OGhoaE9qTzhSVGxrbU5USGd1MUF5?= =?utf-8?B?T3gvQmJXS2VMYUFZOVZBWVFmSStFKzVzRGpTOHAzd0dXNGV6WGh5czkrd04x?= =?utf-8?B?MHM4TDZMc2QybzBTK3RnaDZDbjZiZ3h1U1VVYkRlWUl6Q2JXSHJMemJYNHF0?= =?utf-8?B?U3RLenlFelBONkMzcVBQUTNMeHliUHZBbUpJNTJmNUVuSjlhMnNWclYwWGlY?= =?utf-8?B?Um1hSHV3MDNTYkxrUGdwSjd0V252VjdRTFcxUUFselZac3FJaUFoZExhY08z?= =?utf-8?B?c21SMEZLTktRcWtSWXBwdjhsKzNmcXVocE9JVGF3R1JMVGZmaGxpR1pEd2E1?= =?utf-8?B?WmJDYk51MWdiK2cvK0VVcllWZE5xVnZmQmY1eEtNMVVJWk5tS2g1SVVSc21O?= =?utf-8?B?dGtsak02SzlmNy9zK0N2STVuZi80VDlvV1AzM3E1YkRrdmw1aTh2dDlwRGdK?= =?utf-8?B?bTh4RlQ1NnlaUTZ0VUViTUxWRUMxbjdMNVpScXVUTW5kYTltWnNRcGVPelVv?= =?utf-8?B?bUROOXFCZ2M5SFNib0JqMldlVndBaWpCS2Z2Zlorc0tkOUdvUXdDSEh3N1Jj?= =?utf-8?B?Mi9FRDhiV3UyMmtnSklOR3VESkVsMklrQ0JtRXRyYmtkTnhmSkxYVUQrUjAw?= =?utf-8?B?Tm9tQmt5QnFwWk9yMmNzMWdwUnJ6cThmT3lJeTI0ci96Lzkrak1kWVM0SkRy?= =?utf-8?B?SHRtUkVaYWRUQWdwRVIyUnArNVlLc0J1WERyd0NnNEN4ZGNPa083ZTlwa21m?= =?utf-8?B?ZHo5T0hiTFA1V3hNL0FUeUlKZDBqT2RIVEN6Sk1jb2RpY1h6eDZ4NVVyS1NN?= =?utf-8?B?cVAvT2o2VmM5ZDk1N0RZa0lvNldseVlWZkxlNHRlZDZRM0dlMFI1cHkxeXlL?= =?utf-8?B?UG1kN09LRUpMMW0xczk2ejEvVlMrMHpPTHB4QSt5TkRxWFFpdmZ3QUMxbU9r?= =?utf-8?B?VmlGdStYeG9IVGdmaW9TOXAxTzR4ajF3R0R4WnNnYUFDMWxpMGxqRjZiSzRy?= =?utf-8?B?RjNBbGhGSlFhZG9jZjAyMytQcXZDYTFoUk0xVWJQdkJuTFVpLzJBb3lGR1lQ?= =?utf-8?B?VU9NSU55Qk1NWkI4bDdBcEVXTlh5a3JZWklNbFhlaWJ0VWJueU1DbnpyQWJ0?= =?utf-8?Q?lpgs=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZjFvdnQwMW5yZnhlQldzZC9MK1lQZXVDeGVOM1h4YnpqenhWODU3bFd6Q0hY?= =?utf-8?B?UHlnUnRZdzBneWhsdlEvemxueGNiR2FXMWRwSGpPNHJhRXRSU0puSDhPSWlE?= =?utf-8?B?SUNtQ0FsOXVJSm05Zis1ZHNzNXE3Z21tZUxPRlAvSld0SzkxU2g1M0lMbVFl?= =?utf-8?B?RWIwWmsvVTBnK0dqWmFnUXRhS256czNSaHZMejl2MjZkanZSRnc0WjdvQlFZ?= =?utf-8?B?SUZJL0xKeVJiUy80VGcwdUFHeEc1WlplMW16WW5naWc5NUNsMWhXQW45RWNp?= =?utf-8?B?azEzRHFWM2VncTl0REI1L2pvVFV5T1BGdWZVRUF2L3VJMjZMRlZzeEJ0bC9X?= =?utf-8?B?NGR1RzVibzlRR3NXZnZSckdjYXRPdUZNa3M1YnJJQStEZ1VleFhIa3l0Qk92?= =?utf-8?B?cjIxRFc1b0hjNUZ5VTY2Z2J6UkRNVHBSTldsZFhqcTY1RTNObXZuVDRwUHVx?= =?utf-8?B?UVFCK0dRbjFqQnNiWmpzV1BvNCtOQWJJOWtXc3U4cGpWbkdHclp4REU2NmVJ?= =?utf-8?B?eDR4dTQ2bTFQQlNucVV6WllvTVVDTXFuQklsSTQrODJkMWcrOENkQ2F1Zjc2?= =?utf-8?B?dm11RUhUMUlNRDM3YnRxdk52TGNkM1FaVEJ6dUdsNjM0c2hLalNFdmNVT3NI?= =?utf-8?B?bkQzbVRwTHpOanh3cmhZNjdsU0N3Z0ZiSEJaVXN6NlhBWDFjRDlLOU44NGhu?= =?utf-8?B?bXAwdmZMY2NraTJYaUk1TmFhZGxXb2gwRitwQis4Qy9LRDZNekx0ZEhmdS9z?= =?utf-8?B?VlRtSEt4SSthZ25Wa09jYXdNRnc1cmU5MEUrK3RrYWt1Zm9lNWlvRGxKcnpI?= =?utf-8?B?TGliRjVzcFAweHFSMmpDeGQ2OCtGTE00aEk2VzI5MFFVa2g5UTM3TXhXNVNx?= =?utf-8?B?OVYxN0F1YTRob1Bsb3RDVG1qL21RQVR4MFlYWlg3VkJVY0t3NkFHbHV6ZDYz?= =?utf-8?B?Z0NaRUZZUWJUd0VqdElRM0M5Ny9Hc2FqYWg5RTNVR25aOTdSTjBsZXF5RUtJ?= =?utf-8?B?dHRkWW9yQldMcTA5OW5TZFZmWWlCQnhEU0NLdHVmMVNLajhRYVdqZ0YvTzRs?= =?utf-8?B?WW1IZllxaVNpRGs0eUY3MnBvcHA3NndaRkE5QlYzMk91MitlTHk5dis0T25m?= =?utf-8?B?NFNpcURJaXFoL0xMN05HYU9jWXdLVGs1MTRNLzV6ejBoKzFEN3Z2ZlcxSFJV?= =?utf-8?B?WnN1ZE0za2cxMURJZGcrOGxhZDR1SlNvMHJDcU1lbW9keE1Gci9kcEg4WVVB?= =?utf-8?B?RzI3UjJrZ2NQWkQ0UlhVOHNLVWJLUXIvMEs5NGlXUVdDTEwvdzJkY2xrb2J4?= =?utf-8?B?Kzg5OUpHWm45eURUVjM3UStnV1huQmxOQ0w4Q2ZmbnNzai9zL3JSNy9SSUtl?= =?utf-8?B?VjdnVVRwYzRtR0RoOUMycFFtY29iOTFJb254TTMvZVRQejBFcDhYVDJLOVVy?= =?utf-8?B?UnNjL2R0TGVlcklHdXBXTVNqMVV1L0RScHljNHdOMGpRckprUVFKcGpoVE9K?= =?utf-8?B?d3N6cjhhL0FhbHVFR0J6cnpaaGJUYW5LNytCZzdxVkg4M3IxQ24yRmdsbGJB?= =?utf-8?B?VW4xUEE0VjhhelI5WmZzNHFNZmt6ZnZnWFhScjcxalhHYkFWNkl4bGg4dmdQ?= =?utf-8?B?cXdMNzlFSlg4d3UwWVZDN3plcnN4RkpHdG5vSU5CbUpOZm0wNzAvK2pzUEJZ?= =?utf-8?B?RXFSVEo1UGlFVnI4SjI0TjB2T1ZCRGZtSnhVdUYwWUdEYjhCRWUzNEJBaTdF?= =?utf-8?B?LzExamJCTS9tcTU0Z056djdNdW5CUEF5b0IvRjROUTQyUUZuRHgwdGJNZkJp?= =?utf-8?B?ZytBK0ZmZDZIb0lNck9EL3lDbzkrY1lmM2xkb0d3TlZsTEI5QXRiakVCZlVP?= =?utf-8?B?TEZrOE1OM2tmbkRjR2FyaFpvOUhyVms2MHZqNlU3TmJpN3doSjN5YUYxNFRL?= =?utf-8?B?Znp5SVNUelVBMG5qc3Z5eDZxb2dEUnlPa0V0WlcrbnczUUhqR2tiSGxIRzNH?= =?utf-8?B?a2gyV1Q4UjFDMUo0OGhIWjBwcDhEU0Z5RDM0Z1lsWlV6cWg0WHBsQUJYbzBv?= =?utf-8?B?aEhTSm1SVlJCMGJodDZLRC93bCt1cGp1ais1c1RKTmpDL3BxbGZCSkJBN3JU?= =?utf-8?B?Yk9ERzZsSEZNbkJXYlhWZ2c0cFg3cVpYV2VLT3BxRkEyT2FJdVNOL0N5S1JL?= =?utf-8?B?b0hjWWxCbG8zb3pyYmpFM1J0QmhGNmh3VE53TDlqVDJoVyszNUM0ek5ZSGRE?= =?utf-8?B?alFCaStqUktsMzJwQWsyNy8rVUU4ckZ6MTltYlZVMWtiTFl3TE0yaFZJcGRz?= =?utf-8?B?RWdEVk5XRk16aXN3ay9Lalp4MGdJNU9SaWRHSW1QT2JrV1lnVVlRQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: bf196b5d-be88-4717-5df4-08de59933f17 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 08:50:08.9024 (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: ggz3vXJcdLSpXsD2c/+FWCyZZqK3CVpQsE0B7kqK5HUKkn1qPaf3YZVZ8KOI+XT70dD433PsdUsWp4DbP3nUIQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR03MB5652 On Mon, Nov 17, 2025 at 03:37:45PM +0100, Jan Beulich wrote: > If already we play with the IRQ count, we should do so only if we actually > "consume" the interrupt; normal timer IRQs should not have any adjustment > done. > > Fixes: 353533232730 ("cpuidle: fix the menu governor to enhance IO performance") > Signed-off-by: Jan Beulich > --- > _Why_ we do these adjustments (also elsewhere) I don't really know. I think I have an idea of what's going on here. This accounting is used by the idle governor to decide when to go idle. On Linux (where the code is imported from) the governor took into account the inflight IO request state. However that's not available to Xen and instead they decided to mimic the tracking of the IO activity by counting interrupts. I bet then realized the timer interrupt would "skew" those results and make it look like there's IO activity when the system is otherwise mostly idle. > > --- a/xen/arch/x86/hpet.c > +++ b/xen/arch/x86/hpet.c > @@ -808,13 +808,13 @@ int hpet_broadcast_is_available(void) > > int hpet_legacy_irq_tick(void) > { > - this_cpu(irq_count)--; I think you want to pull this decrease into timer_interrupt() itself, so it does the decrease unconditionally of whether the interrupt is a legacy HPET one or from the PIT? By gating the decrease on the interrupt having been originated from the HPET you completely avoid the decrease in the PIT case AFAICT. > - > if ( !hpet_events || > (hpet_events->flags & (HPET_EVT_DISABLE|HPET_EVT_LEGACY)) != > HPET_EVT_LEGACY ) > return 0; > > + this_cpu(irq_count)--; Also in hpet_interrupt_handler() we might consider only doing the decrease after we ensure it's not a spurious interrupt? We don't seem to decrease irq_count for spurious interrupts elsewhere. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 22 09:01:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 09:01:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210522.1522168 (Exim 4.92) (envelope-from ) id 1viqYk-0000Ch-Vd; Thu, 22 Jan 2026 09:00:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210522.1522168; Thu, 22 Jan 2026 09: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 1viqYk-0000Ca-SJ; Thu, 22 Jan 2026 09:00:58 +0000 Received: by outflank-mailman (input) for mailman id 1210522; Thu, 22 Jan 2026 09: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 1viqYj-0000CO-RS for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 09:00:57 +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 dbad8b9e-f770-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 10:00:55 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by CH0PR03MB6097.namprd03.prod.outlook.com (2603:10b6:610:b8::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Thu, 22 Jan 2026 09:00:50 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 09:00: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: dbad8b9e-f770-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=r+zzs3O8eitSAFql7SaePECkpQtXbp/X1VCsAueDWTHwhnsKtW78uY+4TiGlXyd1kFuWXHNPZJvohLG2opi0RDyQ0vbbaiY2C14XIUGwR3jrF39hgQgzJ/eFmF6Z5keL8da1MP0FUOldwNht68Hkl2ecOLtbuCgvxc++gtomkt6hw/soLxulaokGu3wJ9l+7q0BH9EX8Hih/akrHsV8/2f4ZNMwcH21z3qgNEhq7Bh2CWhu8c4zYOwczgaJjkzXwngLNGJT99TZguS9tKLre2Q9eZRJ06Z6M2FgCv7mGDK8pWIFOCJZ38cfA59/k0EkxYUsiegsHJtOm5EqsmYTJdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=N3vaAuAOpN+ljOXQh5R2SPVbD4JdpTaE3Ki3qgQEFaY=; b=SULWPunwnBF4VWExJlB+dLaryGxBmtqd7qRme/t5VV0dNmeK1nmSGObUN/EDj726NWe06DxVhWffzRZXYbSg24vyfwAW9FP/K1mFQW81vytNObxGozN8a8bcO+gmVkN8SQMu9jzobjQAldNsO9BnAOMaw5Pb1iieTriGz1rEg7ULS40RxiW+d37tAcCjcNVaiNj/ap3UtdiXE0cGYf7qFM3wSmPRLTf1tSFxMk9DXZYTGPxKO/q/UdDEZV0Awbg/NYd14aySfEe8WDNfr8ENGitHsF7QyQiUL2b076OasnHwGho2rxPBIjnmIQtgoqDmB4R1y7J9dB+vDj7n/LU9qw== 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=N3vaAuAOpN+ljOXQh5R2SPVbD4JdpTaE3Ki3qgQEFaY=; b=g+4VrX8I/U2GpIokrMJ6sdZbcoZNm1kEJtp8TSrbodSHZmQIqmDYYF5Z7kEW9JkrWhT4hIRawezUVOjvAYHoeysCsyxCPI2NgcP5XzPNClyeu+LEez1biEwBHt20DBf077EYrJMLfuCm+I1i1qsYI428AS916LCuEoJL4HLGpiA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 22 Jan 2026 10:00:46 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH v4 4/8] x86/HPET: reduce hpet_next_event() call sites Message-ID: References: <57f34114-54b7-483d-8ac0-e9fa49df959f@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: MA2P292CA0006.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:1::7) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|CH0PR03MB6097:EE_ X-MS-Office365-Filtering-Correlation-Id: 62be205a-86a6-4f91-2f1a-08de5994bda8 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?c3pmQ0JvVjR0TXF4OE9tODNTYzRXWVNZUVRKUGhLTTZBeU9zVGdtbU1xSVgx?= =?utf-8?B?Z3hJWXlKdmlXVzlQazBiNWVwUUlMZVVQOUwyVWNkbGlWODdJeWtOZDhqYVhj?= =?utf-8?B?YVl6ZlhLUkNmVkFLRHlKWFFTMk5qb2QxT0VMR3l4MWdGSTFZMUJPckxTTmNI?= =?utf-8?B?Q04xY2dSUlVmbGJMUU1kOGRhWFR4c2tYenFQcGYrM0tXSmJRaUpZQkxrUXd5?= =?utf-8?B?MVFOMVJseUZpdHI3TTVYVjYyRkV3WFp5QW1YM05CeGhBUmI2dEtNVFB4QjRw?= =?utf-8?B?eGZMWmp2Wkh6NFRyWEVzUTV6T3NpdGUrTFVzMW56MWU3Y2ErSTAwZmExa3hq?= =?utf-8?B?MzV0bVJsVXFvaGdHcW05Z1l1eTlQSjBubVExRmthRHJHVHJ5SzltNG1zMUV4?= =?utf-8?B?WWduQmhJTDA0NmJMbHVkU05XSWJid2FmZ3lZbUpEODhzbUdTWGtPL2RNSnYx?= =?utf-8?B?bzBBTjE3YWxtdUo3RE5iekNCRHVYVyt5QWRBVWRvU2xRcytiYTQwNmJoVlNo?= =?utf-8?B?ZnB1VEZjdzczSkp3T0hlalphNGpHK1lYQmtLcTZXNjlYM2Z4a2tQdmtoR2lM?= =?utf-8?B?WnZJUDRKRHpFTFVKOFhEczAyUTFZU2t3Z21abGtCSmtHelNkUnhhQ0hWcnRO?= =?utf-8?B?by95NXNSSWdXWGt3WU9XdWNpSFNLNWZtdzcwMUJrbHhEeFdvclJEcllDZVE5?= =?utf-8?B?cm1wcTIwK1BuUUNvTi9xYmxPSE9pOGpFQm5aK1VCeExoTFBLcXFLQmtpZGNL?= =?utf-8?B?bTZrSVRoLzV6bEpic2pIaHhUWTFUeTMrVk8wZTkrZlllMzMyY2lzZGRkNmxI?= =?utf-8?B?RkpTQ1VKYTNBeGJyRERBdHNSMEdMcTlJM3hDL0psdHdPYkFVM3ZDUGNNYjF5?= =?utf-8?B?MGMvS1BiUEh6Z0krLzN6TmpNK09ad29BWGE3aE1JZTZsWlBYakNtdmwyd2NK?= =?utf-8?B?N1NlcEczcXNMN1lZSkYxL25iUVRTTWJrenRVdXE2clIwZ3NmMkt3SmFobno0?= =?utf-8?B?VGdHcVNHVUdIVk5qVTlGM2ZpNE9nbTdZMFJBQmh0ejltdjJkazI2ZGo5QnJq?= =?utf-8?B?aXBOL1Q4cXZlZGR3U3J3K0xPc0pXcnpQZUhQdmlMK1NjSjR1cTl5UU1SVzI3?= =?utf-8?B?Sm5jbzNZcEJmUE9weSsxcFdpSzdacm1HWHJ1OXA1NjhmUEhXaUdBSDZZbTd5?= =?utf-8?B?elpPODN1ZGpEN0FDdEdBcW4vakdjc0pwZm91V215VDc0dEpoYmJvK2U2SlQy?= =?utf-8?B?YnFOWEFCUU1wN0hHU0VMelpVRWNJMzF6OWhRWEIyZlNYWlBEMnhpdHl3Zno3?= =?utf-8?B?R1EvcVhyUGVtNVo2S1B0RHZnUWZFMTJkWFlSM3BNajRpeU8zMk51Y01FbkVH?= =?utf-8?B?cDBBR1R0bWpOcjdQZURhMEJTVEhWbEhvRE9Tb0t2K2hRMVVVTGlzMjlFaG9y?= =?utf-8?B?NkVKajFOTVgrcGI3WkRHMjRKcXlWbzBlUmxaSlBMalRkNXcwS2dGMEpSNWl1?= =?utf-8?B?MUI1Q0RHYVpnK1ZZUUVoUXNoNWowTExoNVRJSmcrNFZNd05OVFN3M0trQjlP?= =?utf-8?B?MDZoazNoaWlCWEl1bmhPT0RSNFpWTmN2MSswU0Erc1BESzFCdG9lb3ZkREtn?= =?utf-8?B?UTZ6eGlxMytRZkFNcDRFZmJWaTJEZlpBcWdIWE5IV1VtL1NETENMUUpjVjdC?= =?utf-8?B?SXFBN0xrN1ZVS2QvTWR1M1liSkkyTWE5TUhBb0RnR056UktzRllXZWNmTkIv?= =?utf-8?B?VlRyM1NDUS84MlJaUXk0STZMUTcxcnhUMlhqNWFWc3BockpMcXVvN3lvdGhO?= =?utf-8?B?R1hXRElVazVpbGxEak9JLzhPSkdHUFQ5SEloYmRIUmZNT3ZyWjBBc2hiVVJX?= =?utf-8?B?S3JpVDE5amZiakRTWXlycFlzeEZrSzB3Njk3aGFOeHFpemx1VGNZVFJvUGhQ?= =?utf-8?B?eThJTUloUGMrSkFmbEVqYzJadkVqUGZSdGZhbmxKTkI3ZmVNQytuR2Qxanl6?= =?utf-8?B?aWlLZ05ocjJyc1RiS1Y1NmZDUkhEb1lCQjRaS0VwU1ErSzdTYzI5T0JGSWtm?= =?utf-8?B?K2s4cnBDNnZWa2JocjU5cGV4YmFRc2txMFNhM1RzZ1liaVplK0JyMk9XdE9i?= =?utf-8?Q?2kJc=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RzZLdVF4NWt3Q0kwZWNrVmFjK1pnZC9RN052ZlJrVmxrdmRHTmZiaHJVTDZ6?= =?utf-8?B?NWZDdGxBbEk3dVJCd0NVbWZwb1pGblRDWGFPWm1VNXp3M3dtTmZOZWh0eWJS?= =?utf-8?B?Vk5pVEw0MFMyWVVWWk9BdXRjOGlhK3p3b1lJbThzRnNaZEprYnZJZWVKRE1u?= =?utf-8?B?VWxGVlAveXRtWXFqZXNGMjNUVWl5OGxZVFFVSlJDaWhaakVlVHplaSs4Y0Rt?= =?utf-8?B?ZlBNTHV4S3VOTDMza1ZWQmVDeEJDaUkvb2NyZGJyOGFjZWxNbUtuUDJ2Nm5p?= =?utf-8?B?TnlRMlJoaXhlREpnc2ZOOFQzRmNVUjZwNXllZmxYS3V4eE4yTkg0MDJMVExM?= =?utf-8?B?cWRPVENDQmE5YmZUbnAweXg3YlNGWWg2WXBGZUJqR2ZwU2dua25tQ3ZsMW1R?= =?utf-8?B?bUFySXhQa2lQaXErdk9reFlXUDlKVGp5SHR1SHFSMTVRZVVhdy9vTkR0R255?= =?utf-8?B?VVRac2RSOUZ5VjRoZENqZEpaWEdtN05nRXc1T0g0K1dhVytnd1IxNlNUOFEz?= =?utf-8?B?Z2dSOG02WldIdE81VEhiOHlwN0xLRDFOY0pRSDRmd3QrZlE4dDZRVThwck9u?= =?utf-8?B?R25qc1ZGWW9vdDU1K1A2Y1JvVEdudERoTXh1Y2N4aFcrc1NtVTVmS2p2UnBH?= =?utf-8?B?bDc0NHA3WFM5S3NTZENkR3cza1Z2amZZVjQwRVp6RVFORGF5NS9CaDF4M3FE?= =?utf-8?B?U0hOeHU2U2pyYVlCektFL21VQjk0Z1lHaUJBbXlNVUZwQkVEQmVyckcraXkz?= =?utf-8?B?bWE2ODZJRjVBTGtoTFhIT0JkTkQ2K0NHRjVjMFlybTRHQzdSL3lkMXNMVWhl?= =?utf-8?B?US9ESVJjQjJpdVZrUDRzR0xBVm9VUmsvQmZwalRmRzNxazNjRDVMSUFPSTEx?= =?utf-8?B?R1J4R2ovQnNPNjRWdDF2ajRseklQOU5RcWJteVI2cE96M3FwUjBiM1F5YzRH?= =?utf-8?B?R1ZCcWVuU2FqVEZPTEJMZWhiSUVBOHBXaHhPY3luOUh5ZXJFNjlwNnB4U0J1?= =?utf-8?B?V21mRjdZWEFROHRIKzNpVXc0U2JBTGpXSEJ3RW9PRTNKdTZUVHBKclQ4bnZD?= =?utf-8?B?RGx5dDJLK0lpd1RFQjN0NjR1d3V1aUZucHBXNmg4c3RkcWlDVFpBMGxqaktt?= =?utf-8?B?NWVScURHWEpZaWRFMk1mdFlaS2R5RnVYSGdqd094RnRsejFVSnhMYjlaM1o5?= =?utf-8?B?RDMvM2V3a25IY2tIaHN5K2I4aXBmOHVGVzB1a1ROK0liSGtNa1U0c3lEYllR?= =?utf-8?B?SS85QkV5dWlQdDFnd3ptTmlWa3puSWE3MWVLQmNWS2FlQ3FKM2FySE5KZDNk?= =?utf-8?B?YWlLZzh2b3pGbGdzRkxqRVlBZ2hrNmFrSjlFYVJnMFFnb29oODhkUFp6WC9s?= =?utf-8?B?OTQ5QjNMYStSOE5HOWY5VnVJRUhxdHVTL2JMQWJyL29lSXZBK0NqWjRiVS9Q?= =?utf-8?B?cmNDd0RpemFpU3RPWVJtVFFhTEZVTldiRm94NG9DSjhHMUpZZm81MVp4S1Nq?= =?utf-8?B?WEttQVlDOFM1bDNjQ0JBR3ZkZnlXRGF2c29Oajczbno3Q3J0c2M1T2dWbjZB?= =?utf-8?B?UTFKUjJaazlOY3ZLWUZYdGh3OHB6WjlkK1BydFowUTJzL1NXK2x6SURkYVQr?= =?utf-8?B?T0U5N2EweStpVHVBYW5NbU0ydzlqdTNUNGdhMm5POEtoaGRXWlFFNTFQdTJC?= =?utf-8?B?Ump3SEhTeGpwQkpaWjgrZitqLzZndmFIR0JBZGZibXFNOVovOVZPcFdkY0RH?= =?utf-8?B?V2xzMTdML3h6YWRMOThKMHdCdGtOb3NwOXhURTdoblJFWXRUM3ZucnVuTFI1?= =?utf-8?B?Zi9iTEhteVZTTmFsd2tLTmxwWDFjNWwvWGQ3VWN5TXR5R2RESUdITlUraisv?= =?utf-8?B?cEJ3Qld3TGQwTnl2ZTdoSS85KzM0L1BqdUpTS2FCSDJWR0FtMitWQ2RTUHlt?= =?utf-8?B?UTNzdHIrRzYxZUV6SDMvVkJDL0pYblRBQitrbkVMZjNRd3FXWDQvQzBVUUpD?= =?utf-8?B?Q21mYnNIQTV4WHFZZXV1Q3RwSkFLcTdWN21hdE8wVzZpdGFSaTd0akxhM2hI?= =?utf-8?B?WlRURzMycWo2ZVE3blpIU1VVeklhOTh3T3BEdEt0c2tMdlhKTnJFNXB2YjFv?= =?utf-8?B?c2taRDBNa3ZaV1IrYmF0emI1TUkrYWlleldzdHBFNjk2VnQ3U3ZEbzlNcG8w?= =?utf-8?B?U3VGK1RJVEFrd3doSWpSZzVOVC9GU011dG1NQVVlSTNBNXBzY1ZJM1NkNndF?= =?utf-8?B?a0FzTW9tYUNCUW5KdFFibFVCdm0xTTVndlBySllQT1Rpa25TTzlVRXJqYWJY?= =?utf-8?B?WURqcDQ3cGZGa3ZlcTdSQmc2Z2duYnkwN3p6K1IvSTNhbjZWUWRSUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 62be205a-86a6-4f91-2f1a-08de5994bda8 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 09:00:50.6490 (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: SHYzYtj64fCBafytVv75uAPqfvLWmUk0WKg06oBoTGRd+FcE9DFl+P2iF9Zx145XXm8wbQiwGQZhxzchx5YYaw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR03MB6097 On Mon, Nov 17, 2025 at 03:38:43PM +0100, Jan Beulich wrote: > I'm surprised gcc doesn't manage to do that: At least in debug builds two > call sites exist, just like source code has it. That's not necessary > though - by using do/while we can reduce this to a single call site. Then > the function will be inlined. > > While improving code gen, also switch the function's 2nd parameter to > unsigned. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 22 09:03:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 09:03:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210534.1522178 (Exim 4.92) (envelope-from ) id 1viqaz-0000m8-Eh; Thu, 22 Jan 2026 09:03:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210534.1522178; Thu, 22 Jan 2026 09:03: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 1viqaz-0000m1-Br; Thu, 22 Jan 2026 09:03:17 +0000 Received: by outflank-mailman (input) for mailman id 1210534; Thu, 22 Jan 2026 09:03: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 1viqax-0000ls-Qq for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 09:03:15 +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 2e288429-f771-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 10:03:13 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SA1PR03MB6612.namprd03.prod.outlook.com (2603:10b6:806:1cb::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Thu, 22 Jan 2026 09:03:09 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 09:03: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: 2e288429-f771-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xAM9SgQdpMJNGsi/A7/z9J6J0jblqrhlGBkVCgg75Wzk68ejr73WJgcofdEmsBfij7K54/CouYLRSWmuVXeECrrjYIji3GvqoFG8dTbLFUAep2YTFYW9GAOyuC3IUEHPT2qYugSB72aHGQoIPAawqKDeOyArtQAozWunJbL/DgGabdPuNWenTleHUimfLJHeoHuCF8Un41GvomaKgvTJlG5yAQYpwHncgM9AKefm3sphMYHwUj0y/O5qgd2+FgMlYErDWwC0r4lc+k4zL1Vk4lR9l+CZoXaALrgtOl/S+MOlGCreuEw6jCjydKLU9cOkN+HlAgk2r4c6HMOTnvX3/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6jnphzctb+7lIRKrxEX309Ls5U7f/H6HAe4WlzmKt08=; b=VK1NnD1203vaU6DBb8Vy+m7fcLmPnplnjnJwTwIF9t1uSxIcw4oQrV5q2EDEGR1IRWK+gWat1zbBS3KEYLO3mUV5GX6mltx9dkntFzxJGWRuHIy+l0u2C/bpUnSerf1nNOxtQAE4SUBKs9KIB/o9Y3aPcZ3/gRYZ+g+1rbZH9jOwf+Of25shm7mTxdfyEt8NVGZ8C4Kdxux1Y/CjEzJO9jQbKAxEv/GcV9/8Hj1GkFJZXwKLX2uvkIFdIhZ/qZ7AbKMFQ8cxJ898NuRfkSIFUyhQ2gkO+bIpY7HdGYVFZmHl4qUkATpiHm2ukPmYtalVHiTIeqlNmCVlYgpzW6ye6Q== 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=6jnphzctb+7lIRKrxEX309Ls5U7f/H6HAe4WlzmKt08=; b=pEc4GUWyDzbnVwfEWS+CMdDxRi211VzWW9rWL60Z7m6XEicZ0NVtc20ZuSCg3gCZuC0kRvlP8HgN5d3aTb3eQwDHDc3IpgU/R8HtbK/cJA7ZOkUhc0Km31fSXUxCKnrXy48KJnubKA9hmjIgQtu6AGk0QPheGeGx5Vow+fGclqk= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 22 Jan 2026 10:03:05 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH v4 5/8] x86/HPET: drop "long timeout" handling from reprogram_hpet_evt_channel() Message-ID: References: <57f34114-54b7-483d-8ac0-e9fa49df959f@suse.com> <54dbc592-93a6-47bb-9304-14addd41610f@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <54dbc592-93a6-47bb-9304-14addd41610f@suse.com> X-ClientProxiedBy: MR1P264CA0039.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:3e::31) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SA1PR03MB6612:EE_ X-MS-Office365-Filtering-Correlation-Id: e6d0fe59-e9bf-44a1-d89c-08de59951037 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?V285MGRBSGJuKzZ6SS9uMHgwRytOY01PT3N0a0FmOWNnMHBKZ1dMWmZSOFdU?= =?utf-8?B?WlozQ0ZOUmdrM0g1bFBOKzJXaEhzVjlOSlpzK3ZqckFuKzZXTXU4ZElnV2ps?= =?utf-8?B?QlpFbUlJOEhHKzFrUTgvem52OEZhMVZIVm1jWXJkWEtqVmZmb3AvQVpLRXRa?= =?utf-8?B?eWxva0JaY3RiVnRiNVMvRmZ3RURHd01YR1VOQUZPb3F1anlLQkZBaVZhWTlZ?= =?utf-8?B?RnAwZjloNEF2S3NXUEF0THVHUVRLWjFneHF6V0ZMdURjcG9pR242bGg2T2tP?= =?utf-8?B?WUw4RzVMMUJDcEdvbkI0V0dHZXlweUdvR09IWStPYStSV2FKTEt3RTZvcHlF?= =?utf-8?B?VlhwbzZaMzdDdXJsY2E1Y3lPRkdOVW9yWHI3VGxnWk9FYmZxeDh3NGY1VWpH?= =?utf-8?B?WEJZakdBSG1SZ2NDU1hpV1JjUVFsVTNTZXpQVm5SMzhrZ0NpZVNiT3c5OUxp?= =?utf-8?B?Yk5ZZU9Vdm1JaW12UzhQTG05MjlNTWh6Tml1SWRkWHNiRW9oRmZYSTN5WnNk?= =?utf-8?B?VmIwZ2gyVHJ0N1gyUUUzQlE1RUgycVNVeUFyRjVsSFJ3dEhMTlpZbDdBNmZ4?= =?utf-8?B?Y1BNb3VKVzBCelRSbERFWENNUVlBK3htS0dabFpDVGxGczZZOXhxbEMxbUtu?= =?utf-8?B?bEQzd1l3d2xhQVZwR1RhR3pEQlFicmlkclpUUE5qNklPeGNvOUxCUGRCWGx4?= =?utf-8?B?b2lUaXFpckRXZzVCd1IxTURhYy80OFUzNHI1Wlh6c1Jkb05MeGJ3Z25kVnE5?= =?utf-8?B?OW1hSVV0SENTQVlESDJlR0U0MTNxUnJyRUZZWDcxaWlrTk1RSTRHdGE4ckFo?= =?utf-8?B?WVdMaDJ2aXFyUVNWa3JxOTBBUEs5OHVFTWRwbUZtTmRaVEdqUU1KR3ZXWWgy?= =?utf-8?B?QjhsSER3OG14cUVqWkI0dk4xTFRML1JlYjhyT0JWRUc2eGR1QlRvMy9PakRx?= =?utf-8?B?byt4SkJ2ZWVTdlZ3RGdLU0hWR2doRXFZbWlMVFhJamkrRDlNMDdRelNUVUJr?= =?utf-8?B?dnNqdUt2ek5hYkNDb1R4YmNYN05iWEh4YUtMZGpJUGkyQ253YXhlVldiZU0x?= =?utf-8?B?SXpITFFZV201U3ZWMUlBT1RpSEN1b1JzOVdpWTZLOWRob1JQaEFyQlIvaGhH?= =?utf-8?B?ejE3YldxbytSV1R2d0p2MEhnS0hEcEIrNVMxcWJtQVVEV0VGaEZyaCt2TDlI?= =?utf-8?B?eHpFL1o5dmxoSUhoQitQY0Y0RFBTZHhrMTZ1eFZONGoxdVZNWm1UZlJEUTNG?= =?utf-8?B?d1N3MU1PYzltRHRhai91VGlaaFBzTDhRMCtPS1pWbnlCdGJrUXRGTlIwekRq?= =?utf-8?B?d05tTjBKRXN1azlXempMZzNJMG53RCsySFNJcFRhdTdjK2JwK1NrNHJHOFhE?= =?utf-8?B?amkzMit3eDFKTDZmOWhLWVBaUEtjcUtGTEhpT2ZFaW5sdHBSdGRlek9la0Nt?= =?utf-8?B?bXNuZ2Q2UWhuMjRuRWp0UnFhTU5XdE43QStRZHphSnFNdnoyRGRabDl5YlFy?= =?utf-8?B?VFpqQXlkQ2ZyZ3NHQVVSbWZSenRVWFRJMHBkZEYwQU4xd0R1R3R5NEhidjlq?= =?utf-8?B?TVJaQmxZTEVRRUFGbllVU1NOaThTaWtQUmUvMXBzNVllWUhSS09VZFRiTjFT?= =?utf-8?B?RWplUDhJUG1TY0hyM2p1K1VBY1hPSFJvUTJrMlluNXRLd1lrWG8zNjlXenM5?= =?utf-8?B?czZFdFprTTJGcDcrSnRkcHJWWXQ0L1ByaG1Kd2pvdDVMQVNmSFpmdGFxMjAy?= =?utf-8?B?dXVXaDgwMzhVYVVLNDc4RkJjNTdXSFY5V2U5QzlMS2NIWGdpb0tIT21HZlFs?= =?utf-8?B?eWZPK2d6SHVJUjFIMTJRNi9pRGVTRndZRVd5S2E0R2xIU1RjZ3NUNElJOWc0?= =?utf-8?B?M21wbmNNczBEWUdxZEdlVENubkRZZHF6QWljb1FEM2xmTnRrMUsweFVlb2or?= =?utf-8?B?QSt0NUxqOXozck1LTTF0SVpQWExtSlVPR2xTek1TMzNReElSMG1GTkV4aWpY?= =?utf-8?B?OU5LZDJUT0VhVEt2ZERFT2ZBRW1BQU9xU2Y1VDg3dng4OEZWL1FTZWFuVjkr?= =?utf-8?B?LzcxUSthTjJiSStwQzZxUXhrci9YRDJ4NXdwbTFBVmdJRnZSWXZIM3M0MmtZ?= =?utf-8?Q?HcSs=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Yis2Zm84S3dmcWpvcTI3NHdtOEZ2QmVHQzhmSUYwUHdXaG9PcHNjOElaZzZq?= =?utf-8?B?b1RkT2VqMVhIMjVEZmIrSThXL0dzSlBNYzdTZGN0WFlTVXZScTZIelp4YVFW?= =?utf-8?B?K2pCaUxMVnorYXNYRjdGWjN2UHRBekpZRlRCdmxyWEdUbXl1Zzl3TGdGR29O?= =?utf-8?B?dEtrZ2t5RFNVQzZqU0ZJbEgvUEZGK0pyTnFJeW5pNE9TeGtHdmpsbS9TbjZ1?= =?utf-8?B?UVUvbHl4Q2l5YjBXeVVORi9NVHlVdEpQWDljZkFYQWFDMlJLajBoU0xidUZP?= =?utf-8?B?MmNBUWFKTDR2WVB2cTBxeGNhcVNqLyt3eGhWVHZwTEcvOWplMEQxR3Vldldj?= =?utf-8?B?WFloclh6N0k3WmI1L0hObGIxcGR0cVM1U0xDVHRnQnVhSEhmQUFJUUZCQ00v?= =?utf-8?B?WVdUSTlQTHBFWTdtTGpKM1hMSWVudEtZMmJLVDVNbUs0c29qTjhuS1JnRTdB?= =?utf-8?B?MWQvZENuQXBSb0JUM21raW11dnNQL1F2S0lMT1g3NHhNUFBxZFlKUU8vdHM1?= =?utf-8?B?RUo1RmlxdUZGSnpmelQ5T0JwUHFEVHJabk1WMmx5clNGbUZrN1g0dlMwWUs1?= =?utf-8?B?UVRNcjQ0QjZ5K0RkSWpaTi94Q0JTdzJqd0V0cWJrQTBldSs1UFZUeTNIOHkw?= =?utf-8?B?ZjNTQ3oxUnVDb2hmL3BIaHAxRk54RFFSNVYweG1HWlBxNy9FeHk2eFo5MkZS?= =?utf-8?B?akhlUkY5ekcxUGVHV3Z2M1k2a0NLcG9YeDgzUW95Y2NUQjg1UHVXbU1zZUhz?= =?utf-8?B?Q3lZM0tIVVg1NUxNZ3hTTktSeEhBRjJiUGMvOFhlNWVGdFJXQW8xWEY3cmFl?= =?utf-8?B?QmFydVUvNER0cTJKNmoxc1BnamdkWm5kL0pNTkkxU3M4NHh4WFEydEFBQ1gy?= =?utf-8?B?UWRKWWoyWm5VNVgzMU1LM0kxNjBzcEQ4R3lKdHgyT3FRUVBVdFVGb1JDYzFm?= =?utf-8?B?a0RkTEppTFU1aUFKemIyWFJFRlBHcnAyMHBzUmRwTzJ5VzRxQktSQ0o0NVJ0?= =?utf-8?B?ZEhMSVpSZkZTNFEvSXRIVTJBMG9Xb3FRWlZiWXVYTFdmbE1HR0c2TVlKWm9M?= =?utf-8?B?UEdreGVmelBzdUtpTnVFSG1VWkR0SnVRWWlBc2VNTGpWaXptZnI1aFVHN3Fi?= =?utf-8?B?STdvd01uWGNEbE5ZQTd0VGtKL3ZLdmlsYk9mRENYM3JYZWt3RUgwM2hSTDl2?= =?utf-8?B?ZE8vT3hZNzJmSHpUMi9VbURaclRDTG8xS2xIZmVOMlhTaWkxVG03ZUVuSm9t?= =?utf-8?B?UHJWRjZ4cVErblJSbjFmTzN0NDl2SzNNTkJWU0V5Sjk2cmhTVjBKM25LVUpL?= =?utf-8?B?Q0wwbE1USXFidHp4Y0RjamxEUG4rRHNVOCtuYW5GOE5hcUhsdFF4QlNhS2JE?= =?utf-8?B?bjN1RVpna3VXRC9HUFNHTnBiVVZYdmVMMHVHTGxkUy9IdzB6aTZBcVRnRHNs?= =?utf-8?B?Qk8veHRpT1BMOG5FdklzbzNtYUhkR0NnN0Q2MlVDVkx0bkJucklCY0hlZGZz?= =?utf-8?B?M215Uk0rVk0vc1lkWklqK3o3RCsvYkpRUTdmeHJJQzRwYlA4SFF4UHpnSnJ1?= =?utf-8?B?d2FiSUhDdzhMcGhtRk9LTEtIbnQ1UWJoaXMxZE5aQTJIcHVXV21sM0lrSm9v?= =?utf-8?B?MDNvR2kyWTFTT3RaRXoyZTdqejFCc21aUlV3TTFTU2ZUcTlSSStCWjlZaVZx?= =?utf-8?B?N2xHcTZSaXRmOUZ3aUZmNEhscU9qWDFKd2pCaXpWQUZhbUNyZ3Y1aDFpbitF?= =?utf-8?B?ODA3QWVGYlBRTE90cG8wSU9HMW1wY2QrVXMrb2ZxdE5NRUZFRjhQaXF4VFIx?= =?utf-8?B?a2MwcDFZWGdpSGNZVEpQL2VPcnFvMTVxZG1LTEkxVWJ6Q3FrN0NZRTNDR2JV?= =?utf-8?B?czZ6VVgvQk5TUDg1WDBiZ1NERTNmaXlCeWhFcldkdGtSWSswZ2ZZQVhqZVFQ?= =?utf-8?B?M1I3RXYrZlN1TjB4VE5XOUI5cGtHckU5UWd3RnpzMk5NY3hwM1RJMUszbzlr?= =?utf-8?B?c0hkUWMzZUZPcXJ3RnRoMjBaUjdNNkIzREJsTCtxNVI5clRzMm5sN3lpVVpD?= =?utf-8?B?R2dZc1ducjF0ZFg5S0VVbzZtQkJkVWpjbGIwbGtvTFhoNDhUUXE5aGJkR09Q?= =?utf-8?B?NjBodXBCdjkxL2RhYWRoM1dzSEkzZ2VPbjhDVVJkczJ1NnUxN0ZJa1RXMjZu?= =?utf-8?B?Q0FpZDVmUGMwSmZybWVYRjF3V1R5emtnOVBGWjg2Ym5lbzBUbU0ya3VWYU1q?= =?utf-8?B?Qk1CbXFCRmRoaWdSOE44NXRuVmpYSGorUDUycEsxUzVIejJUYzZVSE9JeU95?= =?utf-8?B?Qnd1RFBVRGdHWWZ6TTFkdS85WVZJRThKZDgrV21kNEUwVE9QdU9PZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: e6d0fe59-e9bf-44a1-d89c-08de59951037 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 09:03:09.1479 (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: cdlXjNkalCZnavuwhOboowEEAv6oUSuwSXskUmCZYTV6bcuhK8GEqtE1qYFRQddEx9XG+vu3QnMo236KZW3Clw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR03MB6612 On Mon, Nov 17, 2025 at 03:39:03PM +0100, Jan Beulich wrote: > Neither caller passes STIME_MAX, so (bogusly) handling the case isn't > necessary. > > "Bogusly" because with 32-bit counters, writing 0 means on average half > the wrapping period until an interrupt would be raised, while of course > in extreme cases an interrupt would be raised almost right away. > > Amends: aa42fc0e9cd9 ("cpuidle: remove hpet access in hpet_broadcast_exit") > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné > --- > v3: Drop the code instead of adjusting it. > > --- a/xen/arch/x86/hpet.c > +++ b/xen/arch/x86/hpet.c > @@ -162,13 +162,6 @@ static int reprogram_hpet_evt_channel( > > ch->next_event = expire; > > - if ( expire == STIME_MAX ) > - { > - /* We assume it will take a long time for the timer to wrap. */ > - hpet_write32(0, HPET_Tn_CMP(ch->idx)); > - return 0; > - } I wouldn't mind if you replaced this with an ASSERT(expire != STIME_MAX); Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 22 09:19:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 09:19:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210545.1522188 (Exim 4.92) (envelope-from ) id 1viqqN-0002hW-MI; Thu, 22 Jan 2026 09:19:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210545.1522188; Thu, 22 Jan 2026 09:19: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 1viqqN-0002hP-J6; Thu, 22 Jan 2026 09:19:11 +0000 Received: by outflank-mailman (input) for mailman id 1210545; Thu, 22 Jan 2026 09:19: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 1viqqL-0002hJ-Pv for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 09:19:09 +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 66fe9051-f773-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 10:19:08 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SA3PR03MB7253.namprd03.prod.outlook.com (2603:10b6:806:2fd::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Thu, 22 Jan 2026 09:19:03 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 09:19: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: 66fe9051-f773-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IO97ZJ8vY+PS9cI5p5YslZ3v4zQDo4G4xbVguYsw1bAxGP/TFqoMkqA4GS6Ixr980olZFKAMYu006thiPZiV6ma63spjUjI3s8+WrB+JgGnfhSfWTFPi5I+tyNkTu9eZ9E/SDvk8zG3v/v/mD2ZhI+zsZr427/+8aQ4at7bIj49cmy6+uzgoIMhwf3PERhjjo4rSPsvs5Dg+MzIIrysU1MOjgMQGpSIVk1GhnU48AEXlisXg296kVLDPxSTe7odD7P12DGKI9QSSotKu1KDUlPFk13oh5asEr8X3V/2z/9n6YWhX5ARGa/iWOModsFsI5Ri4clYcGiK3xo8nGZ7E5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LHgE5m6QECRx5+eJgIROoUPUitr4gYlcUJhTZpAIDDQ=; b=nEPCScuZ4susrIDoHioe76vWT6vsun7nbTQbAX0774adb1pwhV+gunK0hC6ocr/YYebJy3JdsXx0IeX/Sths/V1kBS/6j7eH5IeknzMnrJspOMY5H6xMw5EHR/xlo46pR7IT/HTqJ9E9y9kOMQGpxdWDAhB8GEI1xWuSJLqeOFA7QYA5Myj63IMZERBQDNYA7DP2cHM7K3KFVb+2OGDtN7YWKM5jXYRyYhinhawEK3QUj4dUJwM7yZITwr0UW039JzzduSdZ9YDdkIflGRDUETrDEO/ydBP47n2kBf1dyJFwqLq+j06SjMVegPE+Y1JerUxPyvcbhZZf5j+NMRjMXQ== 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=LHgE5m6QECRx5+eJgIROoUPUitr4gYlcUJhTZpAIDDQ=; b=aOvovKCXN9wk0lDfkKY+lLVoUDor1yHWOxHdiUXnJ2zGSwx0dA1UZP/6CasSXnxqXWltyzctKBHtKzmgS5w/swUt/6pLWnjjAMdqaIuor8bOEx2PXSvEijs0HqA5a13fVINkMaYe5I7l1c4n5mVuXDMfXEg+UyynXRa2TXb79GY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 22 Jan 2026 10:18:59 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH v4 6/8] x86/HPET: simplify "expire" check a little in reprogram_hpet_evt_channel() Message-ID: References: <57f34114-54b7-483d-8ac0-e9fa49df959f@suse.com> <0bc920e2-2e32-4b3d-9ed0-a2c2b34e9591@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0bc920e2-2e32-4b3d-9ed0-a2c2b34e9591@suse.com> X-ClientProxiedBy: MR1P264CA0032.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:2f::19) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SA3PR03MB7253:EE_ X-MS-Office365-Filtering-Correlation-Id: 6b7334c5-af94-4479-c210-08de599748b1 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?N0lDYjdKTVo2UTN0dFE0TW9ZamtaMjNPbmUxSDN1TW5vc3I5aUVsUTk2dHZh?= =?utf-8?B?VWNUR0Q0TTBnN2tCelU1Qm9SVkRudVZUZ2paREdhNTFRNDhGck9RWXhWaDky?= =?utf-8?B?MkcrUlBrSGNzalVaSTZjV2k0K2huNEZibFpsM1lVbU1BT095MmQ4WTZZZG1D?= =?utf-8?B?djJUeGFlUEpUNXBoUHdzdWZyV1BpQXNWOHJVSmpLaTByNFd6VWxSWE9QeHNI?= =?utf-8?B?eDc2Tm84SWJzeGtDTmF0bUxMZ05HZHJ6TXZKc09aVXE4OEdHMlU2UndHclQy?= =?utf-8?B?WGRwL3lOazBSNGd1c0M4dDhPa0g1Q1lOLzNiS2drZVNZeUFja21SVVoxdTlG?= =?utf-8?B?VjBhdEZJZjA4eXIxNk5URGhvRWNmSWxrZU11OUhGZDRDUVpsYVo2azJwOE5H?= =?utf-8?B?emZoNTZ6dzB5SGcvYURWdDNqY2NndkR0ajJYQmM1TEQyMWE1VDdiRmVud1NB?= =?utf-8?B?ckxTNndJLzB1U3VRM2lnQnlIaXpaRzUzWVN0UC94d2UxNzVXQVFqdVZtUmRV?= =?utf-8?B?d3NLWkdtQW5jeXdUR041ZW1ReUE1VFI2N2lJT25rTm16azU0cmp6cGt2NzJR?= =?utf-8?B?MTNlWlFUbktBNXFTa1c5aWJPMGd2c05tVXo3a2N1R3dUdTRjZ0cva1A4UlZ5?= =?utf-8?B?eUZibTZwT3VUSXdSM2ZGTkdxYXA0MG5zdU1scHFHUTVraEhNV0xWL1JpQlhP?= =?utf-8?B?MXpKemhQSHF1aVJpR0VKTHppbFB6cEc1NTV1dmNoYjVSZUVVSDNKSzJnaVZz?= =?utf-8?B?ZC9qRjU4eGM1RE0vUXN2Z01lT2VZdnVocDQrTTFiZk1TSmJ6Y1VJQkVQMGVt?= =?utf-8?B?bUJpcW5aaDV5Z3pmWmZxVWU4ZENicGlLQUI1aDJVdkdGRXBEK0U2cU1Qb01L?= =?utf-8?B?bXBtSHMyTjlPaWJuOWZ4dVBlL0VBdDBsOCtpVmRGeW9SbE1hT3RZSjEreFgr?= =?utf-8?B?L3gwVjV0K2FrU3RSY25VcHhyZU9zUy9hSEMvUFpwdWpVMmRBWXJkeXFVTUxs?= =?utf-8?B?by9yN2FGL0hVQVpOb25jMXQveEhpMmRUM1dPUitoS0F5cHZoZHgwcHNFc1Jl?= =?utf-8?B?cGpHc1VMSXlsdWQrcmNRR3RNSUtzaTBhQUhkajZ5dFJFdENEZ1l3RENpNjg3?= =?utf-8?B?alEvK0tZNUQ5VnBWZlorR2daRi9jdkJaR0h4MXMvaTBhNkxMamZIdE1ncFpy?= =?utf-8?B?Q1NucHhzTndLNDhVN2lHc2ljMWI3RzJRSmdLekNxS2JTbGtzZUtRZktjdXV0?= =?utf-8?B?a3I5VFFiSzZZaGFLZ0F1UXBUbnNNL0Q3RGUzTVhtRURWQWlKYjJubmt3MFQx?= =?utf-8?B?Y3ZnV3dZbE1BSWVaLzhLMUxZcXZ0UFlrZGNzOVpXUmdKbUI4bzNZTXFLYVoy?= =?utf-8?B?OEhibjQxOURFS2U2a0xxY3NYbi8zdlV5RWpvdm5qaTVUVzZDMC9sd2h6WE5r?= =?utf-8?B?eGZDRjFHeU1YWVVMc0RUcThoUktFZUROa1NsTEY2MDk0SVQzTDUrMGp4SUNv?= =?utf-8?B?cjZVRmhSR3VtdkRSeDZzQklrSGJaZTArbWRFenE1WnpxVnJkNHZvQXcrWkc5?= =?utf-8?B?VlJ2WE1XWUY4VzU1d2VOZlF5cmpiVXh0dlJWdE9GNGZISGprYTdJMGhqVUdj?= =?utf-8?B?b3pyNGphM3hmdjh3cG0xZURtaURxVzBxcHIzcDdjUjVIVHFESGVOWmpjWVNT?= =?utf-8?B?bDk5VnV0L1RodFBJTXpSa09ad25lOGc5WUpuUmN0ZHZMVitjb2xDZTk3M3VT?= =?utf-8?B?b0FiWkhDVUNkRkZ0aEZUMnoxOHhQUXNzY2lqbVZsWWxMbzZSbjFMR2thTWtn?= =?utf-8?B?MWNGb1EzQmhNb2M4MjBvS1hJNXZmcjJwS2JQUnNEOGxpZG95Z1hLcjd1ekti?= =?utf-8?B?WjdFS3lPNHZRVUdJSGpUVXVHcnE0YXFwTFhmMGJDRDlZMTdBbEdPYzY1NUFP?= =?utf-8?B?TS9JUHVoVEU4eFE5N1NybCtTVi9YTHRPWkYvS1Z0N0FiSytaYUE3eitrWUcx?= =?utf-8?B?UUphMFFTZ1pXZ0JxTjlGY0JYL1EvY0N4K0VPS2haYzRTWmtDMElVVExjK3BV?= =?utf-8?B?aVpRY2JNckwzcTNJY0tTNUNscW0yRU1paHNjME9PRHhDR2xPMkh1d0hTYU9B?= =?utf-8?Q?t9Vo=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OWJ6bVkvZy9NRnlyK0lHd0lIbGFrZWtPaElNR3loWWdyeVNqOStNRXRQTEJO?= =?utf-8?B?bXNUTjFibjBnNGhoV0tYL0NvYTlCdlNLOTZqVEhqQmg5emluaElRd0xlRkE3?= =?utf-8?B?cVZ1RW9maWkraEREWnluRDZVWTV4YzZSUEFSc3ljWGRIK2p2YlZVb0FPaDBk?= =?utf-8?B?QzF1cGVTUklDSzk1Qm91UUd0UnJLVi9WZVRTbkNvc3VYNHByVnpYWGN4bkto?= =?utf-8?B?WXRwQUEwMmorYklYQTh5am84NlJrdmx1eWU3NisxK3Fyd3lsZkdHYlVDa0FT?= =?utf-8?B?U0RqMndlaHlWVGFqS2g4dWxCb0NzK2pTZXVZUnJwY2orQXl0SUxNT01yK1RL?= =?utf-8?B?OVVzZmJSbXBiMkl1QWhEUjNTeFJhNjdRNkV5SFpLZmFoZHpnTjdnY3oxWVdi?= =?utf-8?B?Ynh5b1FWOGpRWHRsY1c3OTlNOU9kQkk2cmZFWUhsUnM2bDhieEJJbDIrbVdW?= =?utf-8?B?UndJL0JGd2k4dzJMVnRTV2EvTHhqNjFUdzd6UTVpTlpZOGxFTmJvdzk1U1kr?= =?utf-8?B?TGU4NEZvSDZQQlNNQ2Q5Yy9jeGdLT05VcERGUm0wbVV5Qm1LcjRkRTFIQXlk?= =?utf-8?B?SWFVWncvUnR3NVlTNWRrcFAwWHBKRVVWc3NuaHpiOEtNNUUyREltbDQzWURP?= =?utf-8?B?YWx4aXpncjRKdnorYlNaOFZINjkwVGoveVl0N0YzL1QvZ2VsQUdNektwTVhR?= =?utf-8?B?bTBFNkxsOTI4OG9ILzVtKzEzZ09CeGpZUlM4YTdnTlA4NE8wNElMOHJiZGRE?= =?utf-8?B?SXB2LzdVeFo2THhSK3NpSCsxTVdwQ24zK3AvaHo4dkJvaUl0YjQxZ1J5WjQ0?= =?utf-8?B?bVk3VWZWb0NkbUxPNk50YW1RZ1RxcGNNNlJ4azg5d21BeEdBbG1mVzYxcHdL?= =?utf-8?B?RU5BZ2VPSjl5eVBjSytUbmd4NnlHZmdjSm5rTkxvN2pXeVcza0UrcXQ1VTZX?= =?utf-8?B?b2cybk95N201Vy9SeFZaUHlXc3Z0My9MMkd5VURFRmVBT09LeTNURGlGQnlq?= =?utf-8?B?ZmRla1JjU2JHcWFla3gwWVNPWEFJd01SMEw5czJGYzNCOE0yN3RGNC9wUmxv?= =?utf-8?B?eXVNM0lVWFgwZHJtUmhYYW4xUnJQLzVyQ1ludzhlajB3Y3hqQ1RlTnhjQkpS?= =?utf-8?B?L3lhdlhCa2NBQS9Fc0l5MDVtM2lkTHl2NFVqWmlsSjcvd05hVVhqZDY4b1ha?= =?utf-8?B?VlNYODB1UmVvU2FzWEJQNDkrUkIyL0d4TVROSTl1SnhzWlFHOUpDUjZtbkgr?= =?utf-8?B?cCtWbnZKZHVHZU9iVnQ3eGZGUHlSUTJIM1ArOWZVVEtCNVlPYVRJR2V6UEhx?= =?utf-8?B?cmlPcWhLSHhJM05PTUhFaDBnbDVEamhqbFNHWnJvNUFuWDNjUVBQQmZQRHFC?= =?utf-8?B?YTM5a1p5c2JPM29RYkpCc3JzaXFsRXdoeHltTkltbFY2SGIzWVhSMFg2TDVF?= =?utf-8?B?eTZVSTROZGt3L1BIZE14Q1FSL3ZGK2RYdzQvSVBZbU94NGE4U0xYSUhJYWNY?= =?utf-8?B?KzZQYzZJbmh5WXUvako3UzRvMWhwRW0zdkRCMmpLNGdiQWxiQnBvd00yRUF3?= =?utf-8?B?YjRFcEdNQ1k4WVV0dE5ZN2EySXk2dkZBS0lTWHhEVjQ2SytjT0t3d29HeXVG?= =?utf-8?B?OFFneHVQNkRSQUgvdms3Q1NzMkROanFxSlZHT2FveS9iR05sNTdzR0prbXN6?= =?utf-8?B?ZXFZejFHaTV6RXgyNHNrYlJ6L3Y2a0hDQWhTVEhBWUl1REZmNnYzYTk3NXNH?= =?utf-8?B?OVpFcDB3REIzY2N2R2hpS2o0dGdGSEl5RWRPTmJRUFBLZEVtS1I0MWdPQjdB?= =?utf-8?B?RUFoRXJxZUF0OEFONlIyZElJV24rbzBuVHNkSStvZjNlVGN5STJDWVdpcnRY?= =?utf-8?B?bkQ1N0FaU0hqUWZOZ1luQXVWNTY2WTdreW5FckNubGt2eWRmRnRXTkNDVmxF?= =?utf-8?B?SDJhRnJoL010MkxlV2lXM2dGSjNyUEhyZzVFN3EycnQ1SEpFb1dqZW1IL2VK?= =?utf-8?B?aHlRWFIwb0hQY3Y2b2lvTmRscVBNY3FWQnc1QXMxWGZ4QnFLVU8ydHd2RmU3?= =?utf-8?B?cDRpZk91UFlITEQ2MkltTml4OERSUFVxempYNERZR0VSd09oZ0dGOWYwTWx3?= =?utf-8?B?dTdxZDhCMGJnT1pNRUlLcmtWSVlIZFQ0THJQZ2xEakNpeE96Yko5Mm05ZnRY?= =?utf-8?B?S0ZEbG9YRFAzMFkzYXArRWo4b09IMzNvbUtlR0pjdFIrOTVmb2tJMlZPMjR1?= =?utf-8?B?NE5FbmdnZTE4dU9ZVUErNkVzQWpzVVk4RXdVbEJMTWxFeXcrWTk2QllOZkkr?= =?utf-8?B?ZGQ0c0NZbVZhZHRiT2NId01ZS1hVNHJxWDR6U2JNVnVIZUl0bThRZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6b7334c5-af94-4479-c210-08de599748b1 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 09:19:03.0928 (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: cvuuLiupbAG7C2Uv/QJ7Z+gIZwaz/JKwiDTwEtQorBSFgZZgTwVYWY73ktex67zHhYvMmhiUnFTWlRku1FYEUw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR03MB7253 On Mon, Nov 17, 2025 at 03:39:30PM +0100, Jan Beulich wrote: > When this was added, the log message was updated correctly, but the zero > case was needlessly checked separately: hpet_broadcast_enter() had a zero > check added at the same time, while handle_hpet_broadcast() can't possibly > pass 0 here anyway. > > Fixes: 7145897cfb81 ("cpuidle: Fix for timer_deadline==0 case") > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Similar to the previous commit, I wonder whether it would make sense to add an ASSERT_UNREACHABLE() if that error path is not reachable given the logic in the callers. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 22 09:23:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 09:23:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210553.1522197 (Exim 4.92) (envelope-from ) id 1viqui-0004C8-A5; Thu, 22 Jan 2026 09:23:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210553.1522197; Thu, 22 Jan 2026 09:23:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viqui-0004C0-2i; Thu, 22 Jan 2026 09:23:40 +0000 Received: by outflank-mailman (input) for mailman id 1210553; Thu, 22 Jan 2026 09:23:39 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viquh-0004Bu-QE for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 09:23:39 +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 07994dce-f774-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 10:23:36 +0100 (CET) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-42fbc305882so446912f8f.0 for ; Thu, 22 Jan 2026 01:23:36 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4356997df75sm43672878f8f.29.2026.01.22.01.23.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 01:23:35 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 07994dce-f774-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769073816; x=1769678616; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=xWzwu8aKaM9lAYfK0GbQBSQtYNB+KIXFdUJh9rrO2fU=; b=GlGlakpt+mQMETDBa19oBCIEgxmqXO4SV48RFY5/EWdQKI1vp5s+B5s2PM4RkbbJzX BQEnF8qkKUVKttlovw7/YlMkHI5HULLPiJ/Ud5tUmMj7L+tOvg8EwT1sGGZm8NM4K34t n5NDujvf5S2Ymc6LyFwHeXPpI5106v2MwcGZeLG+rpTcATFD5zoIWAeTQyKzM1iT+Ipj 1RYDWZrpQY8H25u9GH7SlVAeBE0jZL3GWWQ65PsPhrPhxDXRiEDQzKflD05NZ/i2Tga/ t3ndkBbbmY9fbNQ/x+FRJFjbkR9Jflh0ofsdfkVoqLgb5Ndw8uTVhiZApFLid+WvWjJW 8yrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769073816; x=1769678616; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xWzwu8aKaM9lAYfK0GbQBSQtYNB+KIXFdUJh9rrO2fU=; b=WTyxieJaUzA8Y1537N7C2Z8c21ooeFDpZyFlGwDPV9cnsO4zBbc3JB1/X27QrAGL1E eL0ptfb5/bU70w/aq9o9vhs5iikvY0yxkmkbSxwpw6k4YHZy/puvpDzsi8Yo8zphD9Rr FAef8FPwa7+RiFz1FlkCutfXZP4DMOtzHpNLlDRdeP7QNrBHO5QLVwbcWRoaxYJu7OtO bKf43TXD5aK42/zgsEc6rXaabH07/fP2GwMkGfaKAR7CN5jfOrsyTvL0uMADap/8g+b6 mUa2Dt7ik9FAQULA3XYwuY41MejMEUnf/leyMJB43NhBEeVklYq1Mzl5dWvQLufE5kgM spkQ== X-Gm-Message-State: AOJu0Yxmu7e4l06inLY1CvoumRGTeMosmvjDmM6A5FilAL/CJa0+vncc rftEFnzC8hTHAwPyAWEQRoDn7YFtwsgeTSN+Wq15h3RPDFgawBBiZEP6Kc/WGMnb6Q== X-Gm-Gg: AZuq6aLex11cmhq+8sDmZe5vQCVk5m9r6EeL26O4JLecHKpnQnE9DwO8vunKC9TyljY udM4tjj1SNGIoV6QsAmVHLCMUnaWdhqRVinRSXn/e3N9OyQ34H050eN4dRQrvIz9UnQUxr/xOoN Qegf/QuycVmk+kD6NchU08ENaHZuVq3k08MGXJDhVcUr+CCE1bm+CJ+0teCP7VetL7l7Nhu6rcg V2H2p3V37qyxhMxWOvMga4sK96eq7+L6xBcH+3X1aSCaIjleIOsFNV8LsGBQQ/7O/meEnIZk0OU uk1B4y9BfIXG712QNealvpK8/FLyp824pGU+HutdfNHqLSac5v1Wc1fgB1W6s2QXs8buzGlQsWu iLW0F3q/XW7RWigj+dhhD6RM6jiLZ7ehRYiD0ubH9kdGgsOK/Ulz5RRz1vC6DZmjRXHrSM6hZKN oeTR01FOyRQzjbQ6Yp40ZydS3hC4a3LRUB2Qh0j2HadxNl1Zu0ZXX3H+iRdX3QFm9cxEXv+DF5G Elsm/CFoQQMCg== X-Received: by 2002:a05:6000:4021:b0:430:f1e8:ed86 with SMTP id ffacd0b85a97d-43569972babmr29203280f8f.4.1769073815951; Thu, 22 Jan 2026 01:23:35 -0800 (PST) Message-ID: <48cd047d-4043-4879-b4e8-84a08ab786ef@suse.com> Date: Thu, 22 Jan 2026 10:23:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 5/8] x86/HPET: drop "long timeout" handling from reprogram_hpet_evt_channel() To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper References: <57f34114-54b7-483d-8ac0-e9fa49df959f@suse.com> <54dbc592-93a6-47bb-9304-14addd41610f@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 22.01.2026 10:03, Roger Pau Monné wrote: > On Mon, Nov 17, 2025 at 03:39:03PM +0100, Jan Beulich wrote: >> Neither caller passes STIME_MAX, so (bogusly) handling the case isn't >> necessary. >> >> "Bogusly" because with 32-bit counters, writing 0 means on average half >> the wrapping period until an interrupt would be raised, while of course >> in extreme cases an interrupt would be raised almost right away. >> >> Amends: aa42fc0e9cd9 ("cpuidle: remove hpet access in hpet_broadcast_exit") >> Signed-off-by: Jan Beulich > > Acked-by: Roger Pau Monné Thanks. >> --- a/xen/arch/x86/hpet.c >> +++ b/xen/arch/x86/hpet.c >> @@ -162,13 +162,6 @@ static int reprogram_hpet_evt_channel( >> >> ch->next_event = expire; >> >> - if ( expire == STIME_MAX ) >> - { >> - /* We assume it will take a long time for the timer to wrap. */ >> - hpet_write32(0, HPET_Tn_CMP(ch->idx)); >> - return 0; >> - } > > I wouldn't mind if you replaced this with an ASSERT(expire != STIME_MAX); Hmm, yes, can do. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 09:25:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 09:25:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210563.1522207 (Exim 4.92) (envelope-from ) id 1viqvp-0004lp-J8; Thu, 22 Jan 2026 09:24:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210563.1522207; Thu, 22 Jan 2026 09:24:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viqvp-0004li-Ga; Thu, 22 Jan 2026 09:24:49 +0000 Received: by outflank-mailman (input) for mailman id 1210563; Thu, 22 Jan 2026 09: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 1viqvn-0004la-W6 for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 09:24:48 +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 2fd0cfd1-f774-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 10:24:45 +0100 (CET) Received: from DS7PR03CA0125.namprd03.prod.outlook.com (2603:10b6:5:3b4::10) by MN2PR12MB4487.namprd12.prod.outlook.com (2603:10b6:208:264::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Thu, 22 Jan 2026 09:24:37 +0000 Received: from CY4PEPF0000FCBE.namprd03.prod.outlook.com (2603:10b6:5:3b4:cafe::12) by DS7PR03CA0125.outlook.office365.com (2603:10b6:5:3b4::10) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.10 via Frontend Transport; Thu, 22 Jan 2026 09:24:26 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY4PEPF0000FCBE.mail.protection.outlook.com (10.167.242.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Thu, 22 Jan 2026 09:24:37 +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, 22 Jan 2026 03:24:35 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2fd0cfd1-f774-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=PnKNF3C7Zjqh2EZc5k67a/RLjGvBz52E8kiXRNtxG33ANUo4QupJPes+oEAUJn1Klg/g/0zxcOEm+CcUZbme48n0XDNSbaQVZaWFOoXn9EwsSNzfkBXTHJX7x7QrnLuSSsdaAQ35XUXYxiGgeR47u11jfdAGkiIrEj2tqJl8j0+UaPXDJbADvRBAFmIXidIzl2e22XFFiQETnsG7erpCo2cSlfuvIU8sRq3ys25U/OxM9vmoB0/6yXklBrTyu5D+T/rasS1T1ReC0iGUsuK8RDP4MSHaOyG5yx9ADUrw1MEOOyHuxZrT9wHKPIxkfzYJMq5D29y1VxLOW2gHvi9mGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-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/oFnyNESESwLZyDcTFYh20C3cx2/Zljso7Pp2lKN9A=; b=roxdxz/N7979wNKhIjVF9vO7DWXGmcqFydx/nOiCdIdxbMVMwd4rHdttmFCHxeCgm0h9xgdiuJQVjEF4dqOCVw0R6sTs7v8PUmozCNOdx0pQe0Ar+88w0U7ZsEAPKexSG6EF2j3m4M0l+Pt1jb3jLxMUvuB6a44ZF5yb3x8FMB/wKs8RYV3gIPx6OiJWnJUftywrj14V7RYdhSDg3mT2tiyNGwZwMEQkAEhUXAiFRmANflpDjPHMUY4KEru92OfaZom1uIfRvwK46LkWLhOVQoCtm3Crprtu4krn0wQGBYTFPO4HkXRPPGg9GcJJ2t/Z4XroPw6aXGup/Jo8qTOKBA== 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=G/oFnyNESESwLZyDcTFYh20C3cx2/Zljso7Pp2lKN9A=; b=050BU1b78oeO/gAjhDVLdKrJ3Ivs9HHdw/oMHZHmvThW0zVj9V6KSN4b7XlR/h0F4XQtYgKYgWAF3+A2qphTN6WrlY1gCh17/aj8WKUnzuNvb47O2VdH1O/t3YJg9T26aGJsNZ7o2LgY0xcqqfi9d3JnZatLZE5pBhuIPrCnL0k= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 22 Jan 2026 10:24:32 +0100 Message-ID: To: Andrew Cooper , CC: Oleksii Kurochko , Community Manager Subject: Re: [PATCH v2 3/3] CHANGELOG: Note the new SVM bus-lock intercept From: Alejandro Vallejo X-Mailer: aerc 0.20.1 References: <20260121142857.39069-1-alejandro.garciavallejo@amd.com> <20260121142857.39069-4-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: CY4PEPF0000FCBE:EE_|MN2PR12MB4487:EE_ X-MS-Office365-Filtering-Correlation-Id: 62fa6c00-ca81-4510-6a8e-08de59981028 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026|13003099007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?MjVIVy9qSzNYQXRBNEkrUFhrUCtodEU2amh6VUxNcm9jTlB0blo2SVFlZ2pS?= =?utf-8?B?eDhiQ2RrZ2JzZDlsM2tMc00zdzBVRUltR2R0cEhHaENYenJRTWpFY3hIMEdM?= =?utf-8?B?TXJlamhSNlUvdm5qSWRsYmFaUm0zTzdGSXBVKzRZbVRKRmxxTXlnZG9ZKzAz?= =?utf-8?B?SEhmSVdZbGFzWGxaRi9mSHpOd1FsOFdxTTFKZ2RZUXJIK1lhaWRmUjBlZlNM?= =?utf-8?B?MnhaQW16UUhXRC9SRFlPTjY5RmRrUmFLcDVlWTdJTnZLd2pVZmhDQzMzczFZ?= =?utf-8?B?UVNUOGRmVmVuL01xclhuYUEzRkN5QURSdUlyMGYxcGhwcmlrbEZFY01yUFVk?= =?utf-8?B?MUhUSUpNVlhSb0hiemhITFQ4aFk2OXdIZldGYmFIYjMwaFlENEpSRkVkQXlE?= =?utf-8?B?RmhmNU42MFFuUGEwZVEvUWJ3NjVwcHROOFgvOHplK0VXZ1d0clJRQWFVbDFa?= =?utf-8?B?bG12elRQdHhxVjFPVzgxWG1PanM4Z1prNzFJSWN4aDh1enhTeWtGY1V4Ym90?= =?utf-8?B?bEJmeXpJb2RLWlBXSlh1aTNJWHlPSGxWdzVwTEdzU0diM3dyb0R6VHVROXZB?= =?utf-8?B?YmcveDNhc0hwVVFyeDBTWU1sa2RNNEg3by9FUzlaRFpwSTBkNXk0NTU0WFN0?= =?utf-8?B?VlpqNjZQWmtyOVdENXAzbDgzRFVYLzRaUUdsWGRYVTNrM2FscUxCVUdSSUNv?= =?utf-8?B?Y1JtS1VIOVFsYWU1V1kxM0dQdUFkd041YW1JWStYanlXTDJhM09LMGZ0aVB5?= =?utf-8?B?M1RVeHBQRDV5WkM1OGZETTFQeHhwQmljWkpmeGdRTU5rOXo0S3hQbTdzYXp2?= =?utf-8?B?T1BjVzk3MVpZcDAxMTIzWk1YbzFjMndXbDRPbndJK2dOUStkUDBMNjhHTWIy?= =?utf-8?B?cXdocUoyT2FRV1VLVldvcUlQYWZiYUJFbkxNdVJVSDZBR052LzVPajNiNFBx?= =?utf-8?B?V3M0V2lPNFBxSkVJZlQ3V1J6QVM2bC91WVZxQm5pMFNOa21MOTF4WUEwNFhr?= =?utf-8?B?T1NhUzhjbU42RWU0MVdUcThOSTF2enluVExOUjRWZkRXdFlwY1NuRGE2dEtx?= =?utf-8?B?Y2phTVlPdnU2VzFJaVlsSWZWMnRuVmd2a1BkbU5PUU5DOS82YS9XTGFsNVZh?= =?utf-8?B?Q0dzVG42WmdLcFQwelJVYjV3aGhUUUVZMGc0NTQzcFNTdVpuOEpKUkgxZXA1?= =?utf-8?B?QVE4SFRpajlSZDNXUE9oU2FVUm44Q0FnMVlwWEVXMUJYMEVNVFEyM0ZQeUNq?= =?utf-8?B?MmZ0Vno2N0ZoRVRUVVhhSFhCaUJwSWpkODFoUzZDZ3E3YUh6ZmZ6aE5CZTZ5?= =?utf-8?B?Z3F1NVY5c3djcjFTWWxKUUpVYkdKOTF4YXN2cXIvK2lTYytHcitZbWJjU2do?= =?utf-8?B?andZdHRtdzg1c25vZmZYdEdmUEpneWdLeUFsU0dqcWY2SGU1NWtPY2VkdjZK?= =?utf-8?B?RUkrc1k0N0YybzI3VGJ3ZHpJZWlQeDdyRzFMZStLekZySmV1MVpHdnBuSUlF?= =?utf-8?B?ZXROa2VtcldYa28wbzFnNDBuNDZTY1pHbDRyV25McWN4UG9UU096b1prY1RF?= =?utf-8?B?eVhrV2drWXZ5U1FiM0NOSVVtY0tSOVlwMEo0Vkc0RU1HcmRiMDFka29MZFdH?= =?utf-8?B?MkZKL3hpZXdxcHBLL2tBSDZ0SWZLbGNscnZpSHVoTEovbkY5TkNYc3VGR2pO?= =?utf-8?B?Rklvdm1odWlMSEtKMmdIeEdsZWIwS1hGYUNBeDc0QXhKcFA1Tk5rMk5LSFNF?= =?utf-8?B?MlB2SmZRSXJ1Z0QwVjNaanppVHVRZ0JtVms3cFhUSFEzY01uNHlvZ0VIWjly?= =?utf-8?B?NVpZRXhEdUxjU0xKY3ppQW5ocTJYTmU4YXRCUWM2eGE3K2M1MnRna2MwK01Z?= =?utf-8?B?UE5GdXpRQ3piWEJyQldyRkJvN1l2bTNRaWdZczhmb0dLSUdjaFNTeklTZXNF?= =?utf-8?B?T1N6OW1vcGxYNDhaa2dxWExqRWZWUkZxT1Jvb0pDdHRMTkhvVHNsZ3l0ZlNm?= =?utf-8?B?M1JJbTdQOEhlVjF2T29rWGU2SXNiVGJsQmkwVWczKzdDUXRQSkd6L1RWcDVw?= =?utf-8?B?a3RuZ2J1ZDhUbEZXeG5XRmI3U3VKd0ExbkFFRDZEOWRQNW5FT0trSmdkdk0w?= =?utf-8?B?bjlZaDZab3ArSFRzT0JJQ1kyTmVKazhzZTE1UVdVRmdCV3JJMUNXbHVJWlcy?= =?utf-8?B?S3c9PQ==?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 09:24:37.3302 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 62fa6c00-ca81-4510-6a8e-08de59981028 X-MS-Exchange-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: CY4PEPF0000FCBE.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4487 On Wed Jan 21, 2026 at 7:36 PM CET, Andrew Cooper wrote: > On 21/01/2026 2:28 pm, Alejandro Vallejo wrote: >> Signed-off-by: Alejandro Vallejo >> --- >> CHANGELOG.md | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/CHANGELOG.md b/CHANGELOG.md >> index 53d92a2597..07c1745f22 100644 >> --- a/CHANGELOG.md >> +++ b/CHANGELOG.md >> @@ -9,6 +9,9 @@ The format is based on [Keep a Changelog](https://keepac= hangelog.com/en/1.0.0/) >> ### Changed >> =20 >> ### Added >> + - On x86: >> + - AMD bus-lock detect, used by Xen to mitigate (by rate-limiting) = the >> + system wide impact of an HVM guest misusing atomic instructions. >> =20 > > A little too much copy&paste from the SPR section.=C2=A0 This wants > unindenting by one level. > > Also, this text most importantly needs to identify which hardware the > feature exists in.=C2=A0 I've reworked it to: > > diff --git a/CHANGELOG.md b/CHANGELOG.md > index 53d92a259731..9c3bf0411ccc 100644 > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -9,6 +9,10 @@ The format is based on [Keep a > Changelog](https://keepachangelog.com/en/1.0.0/) > =C2=A0### Changed > =C2=A0 > =C2=A0### Added > + - On x86: > +=C2=A0=C2=A0 - Support for Bus Lock Threshold on AMD Zen5 and later CPUs= , used by > Xen to > +=C2=A0=C2=A0=C2=A0=C2=A0 mitigate (by rate-limiting) the system wide imp= act of an HVM guest > +=C2=A0=C2=A0=C2=A0=C2=A0 misusing atomic instructions. > =C2=A0 > =C2=A0### Removed > =C2=A0 - On x86: > > > The internet suggests that it's Zen5 rather than Zen4. > > Also I personally put the CHANGELOG update in the commit which finally > implements the feature, rather than doing it after the fact.=C2=A0 This i= s > more helpful when git blame-ing CHANGELOG to find things. > > ~Andrew Sure, fixing up the prior patch sounds good to me. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Thu Jan 22 09:28:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 09:28:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210575.1522218 (Exim 4.92) (envelope-from ) id 1viqzp-0005YL-4T; Thu, 22 Jan 2026 09:28:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210575.1522218; Thu, 22 Jan 2026 09:28:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viqzo-0005YE-Vn; Thu, 22 Jan 2026 09:28:56 +0000 Received: by outflank-mailman (input) for mailman id 1210575; Thu, 22 Jan 2026 09:28:56 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viqzo-0005Xp-0S for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 09:28:56 +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 c531a3f6-f774-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 10:28:54 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-47d63594f7eso6443975e9.0 for ; Thu, 22 Jan 2026 01:28:54 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-480497035cdsm15214865e9.19.2026.01.22.01.28.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 01:28:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c531a3f6-f774-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769074134; x=1769678934; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Wc9AqtrxitJ6rxcMDvLhYEG147LWguTFiQKngD4K1x8=; b=DvT3JK25okfaLpn3w2iy+eawBLrrgG84QKgEu0SIahaa4s/K/PZ/vgZ1du0PLnDF1/ auVI/l7tLp1lNLSIxCU4q7DbNGDXNmlo+ws+gOmHGYkM0PT5u0nM0jydHYxAgsFGcH94 qHI8Vgrxr2sphxS0uvOV0WYIY5hbwS4xEkMe9ZwoKU+y2UkhdHVfettbRdsWblULiVqf Wc9UEaPW7wWH4N70taWkCyUEiGOozB/q3V/ou/Et8LPYSUq+ry/+eUM2x/XVovZIcOVH 4lTBPk1An7qiDhMN+4a8l9KBxRsagSR69HFELlkq8i0PI9kD25brHvQnr1AiKh5/4BTk ccHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769074134; x=1769678934; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Wc9AqtrxitJ6rxcMDvLhYEG147LWguTFiQKngD4K1x8=; b=UKr+6E3xJ4CjrTWcRImOcZyUKxObnmuvmcyS7/ZllzFvdmHpCVLpOb195AWd2s9jnJ WjsbgYmycglInMv/cB1kyJRYYwA40ug/cdUijUdBcATEXNuTj47iLPruXQJi+aTCCL4T gEHp5HN7t9dl6gmU5slq69t9LePJjqymONwqU9C2FZUZvRRt1da0rwBwuovfdkC9dPfn u9fK34H3tHG7wthHaWrsYqONwcQCGD7V6Gk9A0emEgs6KoHA8taNlSndg3qfJSCVWMIq hPmHvQa5J3f+XpUwUaBmiLXeVtcjq4xhQoYZrOQ24rRmGwwt++bukg5gbVFQ9WCAYC16 lnbw== X-Gm-Message-State: AOJu0YwzvOjAv4ZNzH8N9ufhu6HlPBigNIFYsWlzFJm1ZJQLxJ6YxRq9 /tdT3jfZeabZR6nbqIuYOfVw/zW2Bq0LFDW+Mmd4UxC5juHN4ZlRYQrzntuhqRMCnQ== X-Gm-Gg: AZuq6aJVRB6jZMj0tf8Ie6Xx5w9Hpqf/q9JiLNyDAoUA1DRXfCJexfwn2FgeIh2Zyu1 fBbttT7ITJhCqNcDgEI/XgvGfW6RudKexmEQYYMefeDmDOPv2qA1s94uuyBJuTiQ94pKoEHk2ey EfgFvpnPvERbTTbEEgeXuqVAkjzhUMRubFhnWLWuMc+QHPKM1hZ8Hn3G6bkFKOWOurhXET00dss WqmnW1ofoqeUcu1qCeUTwCDbLxQ0RAV28L2mtWBQJNPpmZUCtpgJJLsOBkx4CtA9GplEhHhX5CR f/lvHLN/IVxJu0UcegUIai//dxC09tJ39YOii48kK8KWRU1Wnvst0Yb3hT+xl1BUoJXmxkjEqXg TAFdtNweDU/C+ufpuMyCHZDgYc9MAaMbmQqPZKeDbi8fPUoNoPrll1GBJKlUc4yV45l1OPskWm1 Buorlv7a0eCapgu909MLRPkWrlG9eOz7vWGlHxkY7uJSyH5amk0VUJQPM3gJCcvx9whDN7Ocl3R rM= X-Received: by 2002:a05:600c:1d1d:b0:480:39ad:3b7c with SMTP id 5b1f17b1804b1-4803bdb88bcmr164470225e9.16.1769074133950; Thu, 22 Jan 2026 01:28:53 -0800 (PST) Message-ID: Date: Thu, 22 Jan 2026 10:28:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 6/8] x86/HPET: simplify "expire" check a little in reprogram_hpet_evt_channel() To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper References: <57f34114-54b7-483d-8ac0-e9fa49df959f@suse.com> <0bc920e2-2e32-4b3d-9ed0-a2c2b34e9591@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 22.01.2026 10:18, Roger Pau Monné wrote: > On Mon, Nov 17, 2025 at 03:39:30PM +0100, Jan Beulich wrote: >> When this was added, the log message was updated correctly, but the zero >> case was needlessly checked separately: hpet_broadcast_enter() had a zero >> check added at the same time, while handle_hpet_broadcast() can't possibly >> pass 0 here anyway. >> >> Fixes: 7145897cfb81 ("cpuidle: Fix for timer_deadline==0 case") >> Signed-off-by: Jan Beulich > > Acked-by: Roger Pau Monné Thanks. > Similar to the previous commit, I wonder whether it would make sense > to add an ASSERT_UNREACHABLE() if that error path is not reachable > given the logic in the callers. That would mean if ( unlikely(expire < 0) ) { printk(KERN_DEBUG "reprogram: expire <= 0\n"); return -ETIME; } if ( unlikely(expire == 0) ) { ASSERT_UNREACHABLE(); return -ETIME; } which I fear I don't like (for going too far). Even if ( unlikely(expire <= 0) ) { printk(KERN_DEBUG "reprogram: expire <= 0\n"); ASSERT(expire); return -ETIME; } I'd be uncertain about, as that needlessly gives 0 a meaning that isn't required anymore in this function. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 09:41:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 09:41:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210592.1522228 (Exim 4.92) (envelope-from ) id 1virBx-0008Lk-4C; Thu, 22 Jan 2026 09:41:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210592.1522228; Thu, 22 Jan 2026 09:41:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1virBx-0008Ld-19; Thu, 22 Jan 2026 09:41:29 +0000 Received: by outflank-mailman (input) for mailman id 1210592; Thu, 22 Jan 2026 09: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 1virBw-0008LX-0y for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 09:41:28 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 85700530-f776-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 10:41:26 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-480142406b3so5392205e9.1 for ; Thu, 22 Jan 2026 01:41:26 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-480424b18cesm48843975e9.4.2026.01.22.01.41.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 01:41:25 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 85700530-f776-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769074886; x=1769679686; 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=OY4of4wZVXqJ4i7T1N0G0Je3n9ZPZD7LNw16h8CICfc=; b=U7Iudd1Zx2aJty13COOIdCDVeQ4rlktaj52jdg2ri6LVyQtI2Nsfjt6yHga0ukd7im 1BJhTj+lraO3HdMYRxgJOYGWgOAX7ikUt6BOlP4rMZzBFcwxINuzguuL0F2kXJNQuweG I0DMkAtsNRb8OvHI4Y1faWZcvVeH8EZvbVfeluNTXJ98Tv87bo+jLqb7gP6FdzjRzcIo HRolxbf7JhwqVbi2ShEyfiplHBSTQbfgHzJJSyC5V2nJOk1bIPstIrt/NukQHyQEwTfr tdE4TVugxQxHR7ESvJ2JzbTlq1EC81Npxk9IDbYe4Vm85KIUJeqQ2FglW+SD3Msfundp SNPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769074886; x=1769679686; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=OY4of4wZVXqJ4i7T1N0G0Je3n9ZPZD7LNw16h8CICfc=; b=BLcydK1UagVVoXxzCp+By0Nl4eqOcb00J8Ji9ZmZJdCrhJ6R2e5LPnd7xepYkW+gXx nMCY7YC0E746/WpbD/k9bxgp1BC2x8yc9DU7bd1NDcb/Oy0HMXMb0aedq31ckRULdj6d 0qfmo2KDSxqRq5PUbmA0Lq4a2z97ZNer1J7Tdwl7ztKtBjRGeBnd6hSkJGMtGVLaB08s 7A8TH9tLMGwLRyZ3rhFFLshZMRXFBQO5eigAtKLyWAVkFWeIfHtPgicXooWZc2G6uI+S yNSfW/lmAqcb4zZG5tFs04Onu/HMpKb1IN3UHZhauRNND4PrfRJboydgXA/e0g4JGlQr FuVQ== X-Gm-Message-State: AOJu0YwZb6bek9iHPVrCAsiVpcTxFU2TYU+3UEymjXrQnzJ7wySBxkzo JS9niNShAzvCuKbd9V8LOR5Aynehxxo089E7P0+1TyXXC5Bo4iV5/1kZuCAo2l7/A6ABTTKTQ0o zpxM= X-Gm-Gg: AZuq6aIf8lDO3hm32ilCpVZFbUB85dJz+YQhva4e/v/ORq2CmUoz1xilw8mjpq2sO0n GrbnfW+tcphqJ1kuEQu3M+4tdjewOm9/fCZJMBRqoW+NZYKQiay15qCgantVpiluuOZsb1JVSKS oOYRlhSpFWnsAvV9gNKYezd/ioLzDoTs5+DLFPrTpBJIGBeLhS2mmXSsKVmKpuNKvAJcVH/jm0c SxiDf/zkqhQ/LAGvOi7B8mjr1E8qEhPDMqbCTegqaqLuQpZjTm+Ux86cdqaZb3dh9+zixqHvPuG /D6XUNuqSlPCwfS3W0TBYliw+leWDP0gRTXeektBKRkpdWoAFovvl98Mk0uy7Sv0rJ6J1LDtDTr IZbiaf1MB+MtVoZE16jKUihY7461J1eGtHdMkX5uSUgR2U65NcC9KJe5tlZvJuVYpSy08dumKk1 7PJTq+jkkeiZhEJ9HmG44gEuG5vjy85uI5C1LGJ8+NAW6GF8/97ckbsKYjj3iqzccwLEhSXX2Di wM= X-Received: by 2002:a05:600c:4e4e:b0:477:7725:c16a with SMTP id 5b1f17b1804b1-4801e30b74emr313302865e9.10.1769074886003; Thu, 22 Jan 2026 01:41:26 -0800 (PST) Message-ID: Date: Thu, 22 Jan 2026 10:41:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH 0/5] cpufreq: driver data Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Main goal being to eliminate the somewhat risky, as identified in earlier discussion, use of per-CPU data indexed by struct cpufreq_policy's cpu field. 1: eliminate cpufreq_drv_data[] 2: hwp: move driver data into policy 3: amd-cppc: move driver data into policy 4: amd-cppc: move epp_init into driver data 5: amd-cppc: move pxfreq_mhz into driver data Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 09:42:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 09:42:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210599.1522238 (Exim 4.92) (envelope-from ) id 1virCg-0000NQ-DO; Thu, 22 Jan 2026 09:42:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210599.1522238; Thu, 22 Jan 2026 09:42:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1virCg-0000NJ-9e; Thu, 22 Jan 2026 09:42:14 +0000 Received: by outflank-mailman (input) for mailman id 1210599; Thu, 22 Jan 2026 09:42: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 1virCe-0000Cq-BI for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 09:42:12 +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 9f1d9ebf-f776-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 10:42:10 +0100 (CET) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-42fed090e5fso489641f8f.1 for ; Thu, 22 Jan 2026 01:42:10 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43569921dddsm45228367f8f.6.2026.01.22.01.42.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 01:42:08 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9f1d9ebf-f776-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769074929; x=1769679729; 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=+LBvT2kvUK3KCeIm+D2kNPm3jZj59Qe7BGo6Y0fvc0k=; b=ZQ7RTcvJWN/9IWjMf0le5/e1893FOvXUdmt6HIq+6SeBW0bcNFkojfNvnlLoAjIPNs Fz1WyR9eb1oR2d7NRUEOABbgcDgs5E5fSWT1rDmgjHsAL3ta2stdzT/Cja/GQxH2+Qze Ho9NyaXP4VU5GzIkBNCi4mDTxRfywJSAJgVxlK7YsWmOcnz3LfhYvAvQfHzmvYfFnKFY txCcxp+7WQdUCdnw9BFaI2WHxAqW2VwXmY9B+dGMVAxxwOuV7Nz7Yiw48oCSXubqLNLo iGHsjoH+pIV+73AHsaKrCbsWQzsJ+W5hZIz9+xFa34rfspZwL7Z2HsQCr3lrwWw9jwJA 0NHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769074929; x=1769679729; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+LBvT2kvUK3KCeIm+D2kNPm3jZj59Qe7BGo6Y0fvc0k=; b=KjC+RjN2t+h1Lhn8hs5dLlHuJl3IusPHGJZPnI6tvC0BlhtuCHLWyrZLRGbqI3hENf vPyr9/oNGa/3GqVoaAQfUnTR5w2V6+Mkps/ZheA+i11XVxcmafjnDbF99FBXVuYdYbgM 4Pe9UzfkxT45h1Bt1YtueVWsEzeaTmzLknk5LGpKb8YisN+pTd9Gg5Uz722gXeJgW9sq 2gTnFNRWGj6f2BdqVvRKc6a5/dfwJVX96a4SJIXeAAhowv2+RVwekLmFZ7H7QK0k6E8L XjVkTA52jjqCz/X6BOdGb+AGpitJ7gI9qknbfZXy/r4J4jU6YAEL3feNIqpVj4gukeDl e2Zw== X-Gm-Message-State: AOJu0YyLFmOh6aZtWzutGDWjM8LQsLlMP1DZsCaCdoqESB/k5EZxv5Oh itRHZtF64yicd9l/22UAL0cmrTYgPQEhu2w4pR5dbUmZnOUSibVEZwim5sKNfE+64M/P/GxVaRH OSnY= X-Gm-Gg: AZuq6aISpUGEvU/hDxWdK5cyErne06KZ18GDbK7qbpnOYgLRmwHkljY0qzKmgHUhgdd AB2xJWis44ZSXYWe896GaOGwy/DQu7EKQBsLWBjgI6M4WeB3fxORZBmhOqowjHUtxXvS5V75rnZ lcyMKvGqzCXvTNYTP2ckuObkBWV8VaikxMGh1R/467gqZdOWZK1gba/tW0ri25utUT7pu9xML+4 7zUJjBJEe3KcdVJqskDlJQ4BSkQ9WyL9fCMKF+EtdUu++ABBXkT545BPLZ6CQAPgnxf3dPY3Keb lTQ+qjPRZ4v1tFyIyBNs8c3X9ckfMIWedxlbxWRzPFqRxYVRBraxEJJ6eitWOqLRQI/3jRfJ0Q9 SJwdpcN6ZQO1R95VqZbtK5DIjvRC1iZ0JjPg7VHyfS7E6IudyDaa6fDU4PkCo5Cf6CYNB2+s8Uh MBcjaL/rNtAJBYoVHgoU7uiDY110PkkQ8z8/J3CzP2m8IifzXKjj9G+sQCoAPz9uFhnkvoqmtfk uQ= X-Received: by 2002:a05:6000:430d:b0:435:95dc:b8ca with SMTP id ffacd0b85a97d-43595dcbaacmr11899384f8f.40.1769074929068; Thu, 22 Jan 2026 01:42:09 -0800 (PST) Message-ID: Date: Thu, 22 Jan 2026 10:42:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 1/5] cpufreq: eliminate cpufreq_drv_data[] 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 Possibly many slots of it may be unused (all of them when the HWP or CPPC drivers are in use), as it's always strictly associated with the CPU recorded in a policy (irrespective of that CPU intermediately being taken offline). It is shared by all CPUs sharing a policy. We could therefore put the respective pointers in struct cpufreq_policy, but even that level of indirection is pointless. Embed the driver data structure directly in the policy one. Signed-off-by: Jan Beulich --- v2: Re-base, use union. --- a/xen/arch/x86/acpi/cpufreq/acpi.c +++ b/xen/arch/x86/acpi/cpufreq/acpi.c @@ -174,17 +174,18 @@ static u32 get_cur_val(const cpumask_t * return 0; policy = per_cpu(cpufreq_cpu_policy, cpu); - if (!policy || !cpufreq_drv_data[policy->cpu]) + if ( !policy ) return 0; - switch (cpufreq_drv_data[policy->cpu]->arch_cpu_flags) { + switch ( policy->drv_data.acpi.arch_cpu_flags ) + { case SYSTEM_INTEL_MSR_CAPABLE: cmd.type = SYSTEM_INTEL_MSR_CAPABLE; cmd.addr.msr.reg = MSR_IA32_PERF_STATUS; break; case SYSTEM_IO_CAPABLE: cmd.type = SYSTEM_IO_CAPABLE; - perf = cpufreq_drv_data[policy->cpu]->acpi_data; + perf = policy->drv_data.acpi.acpi_data; cmd.addr.io.port = perf->control_register.address; cmd.addr.io.bit_width = perf->control_register.bit_width; break; @@ -210,9 +211,8 @@ static unsigned int cf_check get_cur_fre if (!policy) return 0; - data = cpufreq_drv_data[policy->cpu]; - if (unlikely(data == NULL || - data->acpi_data == NULL || data->freq_table == NULL)) + data = &policy->drv_data.acpi; + if ( !data->acpi_data || !data->freq_table ) return 0; return extract_freq(get_cur_val(cpumask_of(cpu)), data); @@ -252,7 +252,7 @@ static int cf_check acpi_cpufreq_target( struct cpufreq_policy *policy, unsigned int target_freq, unsigned int relation) { - struct acpi_cpufreq_data *data = cpufreq_drv_data[policy->cpu]; + struct acpi_cpufreq_data *data = &policy->drv_data.acpi; struct processor_performance *perf; struct cpufreq_freqs freqs; cpumask_t online_policy_cpus; @@ -262,10 +262,8 @@ static int cf_check acpi_cpufreq_target( unsigned int j; int result = 0; - if (unlikely(data == NULL || - data->acpi_data == NULL || data->freq_table == NULL)) { + if ( !data->acpi_data || !data->freq_table ) return -ENODEV; - } if (policy->turbo == CPUFREQ_TURBO_DISABLED) if (target_freq > policy->cpuinfo.second_max_freq) @@ -331,11 +329,9 @@ static int cf_check acpi_cpufreq_target( static int cf_check acpi_cpufreq_verify(struct cpufreq_policy *policy) { - struct acpi_cpufreq_data *data; struct processor_performance *perf; - if (!policy || !(data = cpufreq_drv_data[policy->cpu]) || - !processor_pminfo[policy->cpu]) + if ( !policy || !processor_pminfo[policy->cpu] ) return -EINVAL; perf = &processor_pminfo[policy->cpu]->perf; @@ -343,7 +339,8 @@ static int cf_check acpi_cpufreq_verify( cpufreq_verify_within_limits(policy, 0, perf->states[perf->platform_limit].core_frequency * 1000); - return cpufreq_frequency_table_verify(policy, data->freq_table); + return cpufreq_frequency_table_verify(policy, + policy->drv_data.acpi.freq_table); } static unsigned long @@ -379,17 +376,11 @@ static int cf_check acpi_cpufreq_cpu_ini unsigned int i; unsigned int valid_states = 0; unsigned int cpu = policy->cpu; - struct acpi_cpufreq_data *data; + struct acpi_cpufreq_data *data = &policy->drv_data.acpi; unsigned int result = 0; struct cpuinfo_x86 *c = &cpu_data[policy->cpu]; struct processor_performance *perf; - data = xzalloc(struct acpi_cpufreq_data); - if (!data) - return -ENOMEM; - - cpufreq_drv_data[cpu] = data; - data->acpi_data = &processor_pminfo[cpu]->perf; perf = data->acpi_data; @@ -406,23 +397,18 @@ static int cf_check acpi_cpufreq_cpu_ini if (cpufreq_verbose) printk("xen_pminfo: @acpi_cpufreq_cpu_init," "HARDWARE addr space\n"); - if (!cpu_has(c, X86_FEATURE_EIST)) { - result = -ENODEV; - goto err_unreg; - } + if ( !cpu_has(c, X86_FEATURE_EIST) ) + return -ENODEV; data->arch_cpu_flags = SYSTEM_INTEL_MSR_CAPABLE; break; default: - result = -ENODEV; - goto err_unreg; + return -ENODEV; } data->freq_table = xmalloc_array(struct cpufreq_frequency_table, (perf->state_count+1)); - if (!data->freq_table) { - result = -ENOMEM; - goto err_unreg; - } + if ( !data->freq_table ) + return -ENOMEM; /* detect transition latency */ policy->cpuinfo.transition_latency = 0; @@ -480,23 +466,14 @@ static int cf_check acpi_cpufreq_cpu_ini return result; err_freqfree: - xfree(data->freq_table); -err_unreg: - xfree(data); - cpufreq_drv_data[cpu] = NULL; + XFREE(data->freq_table); return result; } static int cf_check acpi_cpufreq_cpu_exit(struct cpufreq_policy *policy) { - struct acpi_cpufreq_data *data = cpufreq_drv_data[policy->cpu]; - - if (data) { - cpufreq_drv_data[policy->cpu] = NULL; - xfree(data->freq_table); - xfree(data); - } + XFREE(policy->drv_data.acpi.freq_table); return 0; } --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c @@ -35,8 +35,6 @@ #include -struct acpi_cpufreq_data *cpufreq_drv_data[NR_CPUS]; - struct perf_pair { union { struct { --- a/xen/arch/x86/acpi/cpufreq/powernow.c +++ b/xen/arch/x86/acpi/cpufreq/powernow.c @@ -84,16 +84,14 @@ static int cf_check powernow_cpufreq_tar struct cpufreq_policy *policy, unsigned int target_freq, unsigned int relation) { - struct acpi_cpufreq_data *data = cpufreq_drv_data[policy->cpu]; + struct acpi_cpufreq_data *data = &policy->drv_data.acpi; struct processor_performance *perf; unsigned int next_state; /* Index into freq_table */ unsigned int next_perf_state; /* Index into perf table */ int result; - if (unlikely(data == NULL || - data->acpi_data == NULL || data->freq_table == NULL)) { + if ( !data->acpi_data || !data->freq_table ) return -ENODEV; - } perf = data->acpi_data; result = cpufreq_frequency_table_target(policy, @@ -187,11 +185,9 @@ static void cf_check get_cpu_data(void * static int cf_check powernow_cpufreq_verify(struct cpufreq_policy *policy) { - struct acpi_cpufreq_data *data; struct processor_performance *perf; - if (!policy || !(data = cpufreq_drv_data[policy->cpu]) || - !processor_pminfo[policy->cpu]) + if ( !policy || !processor_pminfo[policy->cpu] ) return -EINVAL; perf = &processor_pminfo[policy->cpu]->perf; @@ -199,7 +195,8 @@ static int cf_check powernow_cpufreq_ver cpufreq_verify_within_limits(policy, 0, perf->states[perf->platform_limit].core_frequency * 1000); - return cpufreq_frequency_table_verify(policy, data->freq_table); + return cpufreq_frequency_table_verify(policy, + policy->drv_data.acpi.freq_table); } static int cf_check powernow_cpufreq_cpu_init(struct cpufreq_policy *policy) @@ -207,18 +204,12 @@ static int cf_check powernow_cpufreq_cpu unsigned int i; unsigned int valid_states = 0; unsigned int cpu = policy->cpu; - struct acpi_cpufreq_data *data; + struct acpi_cpufreq_data *data = &policy->drv_data.acpi; unsigned int result = 0; struct processor_performance *perf; struct amd_cpu_data info; struct cpuinfo_x86 *c = &cpu_data[policy->cpu]; - data = xzalloc(struct acpi_cpufreq_data); - if (!data) - return -ENOMEM; - - cpufreq_drv_data[cpu] = data; - data->acpi_data = &processor_pminfo[cpu]->perf; info.perf = perf = data->acpi_data; @@ -230,8 +221,7 @@ static int cf_check powernow_cpufreq_cpu if (cpumask_weight(policy->cpus) != 1) { printk(XENLOG_WARNING "Unsupported sharing type %d (%u CPUs)\n", policy->shared_type, cpumask_weight(policy->cpus)); - result = -ENODEV; - goto err_unreg; + return -ENODEV; } } else { cpumask_copy(policy->cpus, cpumask_of(cpu)); @@ -240,21 +230,16 @@ static int cf_check powernow_cpufreq_cpu /* capability check */ if (perf->state_count <= 1) { printk("No P-States\n"); - result = -ENODEV; - goto err_unreg; + return -ENODEV; } - if (perf->control_register.space_id != perf->status_register.space_id) { - result = -ENODEV; - goto err_unreg; - } + if ( perf->control_register.space_id != perf->status_register.space_id ) + return -ENODEV; data->freq_table = xmalloc_array(struct cpufreq_frequency_table, (perf->state_count+1)); - if (!data->freq_table) { - result = -ENOMEM; - goto err_unreg; - } + if ( !data->freq_table ) + return -ENOMEM; /* detect transition latency */ policy->cpuinfo.transition_latency = 0; @@ -300,23 +285,14 @@ static int cf_check powernow_cpufreq_cpu return result; err_freqfree: - xfree(data->freq_table); -err_unreg: - xfree(data); - cpufreq_drv_data[cpu] = NULL; + XFREE(data->freq_table); return result; } static int cf_check powernow_cpufreq_cpu_exit(struct cpufreq_policy *policy) { - struct acpi_cpufreq_data *data = cpufreq_drv_data[policy->cpu]; - - if (data) { - cpufreq_drv_data[policy->cpu] = NULL; - xfree(data->freq_table); - xfree(data); - } + XFREE(policy->drv_data.acpi.freq_table); return 0; } --- a/xen/include/acpi/cpufreq/cpufreq.h +++ b/xen/include/acpi/cpufreq/cpufreq.h @@ -38,8 +38,6 @@ struct acpi_cpufreq_data { unsigned int arch_cpu_flags; }; -extern struct acpi_cpufreq_data *cpufreq_drv_data[NR_CPUS]; - struct cpufreq_cpuinfo { unsigned int max_freq; unsigned int second_max_freq; /* P1 if Turbo Mode is on */ @@ -82,6 +80,10 @@ struct cpufreq_policy { * -1 for disable, 1 for enabled * See CPUFREQ_TURBO_* below for defines */ unsigned int policy; /* CPUFREQ_POLICY_* */ + + union { + struct acpi_cpufreq_data acpi; + } drv_data; }; DECLARE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_policy); From xen-devel-bounces@lists.xenproject.org Thu Jan 22 09:42:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 09:42:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210605.1522247 (Exim 4.92) (envelope-from ) id 1virD1-0000nQ-NY; Thu, 22 Jan 2026 09:42:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210605.1522247; Thu, 22 Jan 2026 09:42:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1virD1-0000nJ-Ks; Thu, 22 Jan 2026 09:42:35 +0000 Received: by outflank-mailman (input) for mailman id 1210605; Thu, 22 Jan 2026 09:42: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 1virD1-0000n5-6R for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 09:42:35 +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 ac6b6b62-f776-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 10:42:32 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-435a517be33so472792f8f.0 for ; Thu, 22 Jan 2026 01:42:32 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4356997e664sm39449748f8f.30.2026.01.22.01.42.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 01:42:31 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ac6b6b62-f776-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769074951; x=1769679751; 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=9YAbpFp0YVR8E7C5PwaC48OUfTxt5vy1yYtA+A0DwVE=; b=NWG42c/AGxEXOQb/sedzm9pwIcypv9/oZBbQlAU+M++XKeWD0LVrKpTi4T8HXyG+bu VzyMLfz0t1Xga+eGeb/3AMEyH5tNAjWCf7wZHfCunQ6I3gf6ba293p9YKVc7VgjNBJs4 JWjE+huUVpBiH38UCHdO8PMQO5it9U2eSA/tXuljzwm5019avzuQXiTrpiV8KNvLF+k6 ZNL3Z61186UFmYLWpi6+KsVaeCR+kQq33V6PDW/hBgA9lZUEerRBi+FZQvDaH2eTu/SN /8YEipnQfiefmRH5OMcTwzVw+RgfE167DCBPRPzwtxW9p1YcTlmaH2OiM9WH/LASIJnv lpnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769074951; x=1769679751; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=9YAbpFp0YVR8E7C5PwaC48OUfTxt5vy1yYtA+A0DwVE=; b=mr5oEXhGYcIQ2UfO44TF/BKIDjAnk6NxUOoTraqPlkJ3R+saNfKutZmvW1bQcfFTco vF1RNXn8Nv76Nu3dtIC5T/0gcK4qXkjcOEMG1DV1QWra+HMJW6MBCCiH+3/bnxghlJkQ 5QnOsqGj0cVvf8LRD1vdswZ/pIPwY/MwtUDPfEFEshdLyHYqD9qPVwYm0J3rHffkwbEl pyBottSfLAKrbzdx5yh/9cgjr7woeI5H2a0Uo7tzC+hL3/3DO55a03/sma6siKstLHEr AdiIt6C3FKvrTF8flA6Z0MDQd4mIG1Z2jnpOQCH73zncMHympHX83EeS+YCRDr/CSoUz KjuA== X-Gm-Message-State: AOJu0YwMugu+OZYl17S8GZmTx2CP6LeRbx7eBTD3ra76kyMrfghlyUcH 7AAKEPGzfdEjNDAKQGiB9cIQ6DZJOItxaN/9wRV2DIcMWZ7HW8PXmQnOAxo1c9eeXhBXlpOAtaB KZLI= X-Gm-Gg: AZuq6aKTbZkTRcUK+fJfUI/yeAhXSukA9a071r2dM5dvwr6jhNW/81PgLEuLR/h6/ks Ovf1CUSb6rJw4F4kBEHDLCql3tmOj27r4OSLa27x4lM8/ZO8u6Fm70l0JO3SmJMDFwuKUQG6HcO VceEjwBcXz/Mnn1ZR+G546GfSp7rrCLelFUUHhp6UqSKcFseU7H3JkXTWFaL8zm/nw2LoAu/8Af X7fF4FTvCwhPC4WBsCMpLPEEeKTTiqfo52CBAcIk/uLQ4dk6F8gBMEFBS/6aDgYPx5h/5ESmB3L 3S7H0+OHTLIEkcmIclz4Fk6BM5HVD8Oahan05vqneN5nxLG2UhLTxLHjbeokpiaYfEwnyYy5DQB QRZFAbJ8YtqVd48RrcXjFclv2Tsm35dd4gGDDEz++mWCyInpI9rcQwz4E7oFn+sZXMBEf/NpKf0 F3xaDGxzSaxwF2G+3H5qk9wwsht8oZIy33XAMowUPEE3/43smD09J64yznnJK1mzX12zI1MOl4G 5Vn68QFWAEU+g== X-Received: by 2002:a05:6000:40ce:b0:435:9612:2d3b with SMTP id ffacd0b85a97d-43596122f2amr12716492f8f.44.1769074951391; Thu, 22 Jan 2026 01:42:31 -0800 (PST) Message-ID: <8441ada5-e2ed-4d79-822c-ecf1ce3c9484@suse.com> Date: Thu, 22 Jan 2026 10:42:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 2/5] cpufreq/hwp: move driver data into policy From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk 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 Share space with the ACPI and powernow drivers, avoiding a separate allocation for each CPU. Except for get_hwp_para() all use sites already have the policy available, and this one function can simply be brought closer to its sibling set_hwp_para(). This then also eliminates the concern over hwp_cpufreq_cpu_init() being called for all CPUs, or a CPU going offline that's recorded in policy->cpu (which would result in accesses of per-CPU data of offline CPUs). Signed-off-by: Jan Beulich --- hwp_cpufreq_target() still requires policy->cpu to be online, though. --- a/xen/arch/x86/acpi/cpufreq/hwp.c +++ b/xen/arch/x86/acpi/cpufreq/hwp.c @@ -22,50 +22,6 @@ static bool __read_mostly feature_hdc; static bool __ro_after_init opt_cpufreq_hdc = true; -union hwp_request -{ - struct - { - unsigned int min_perf:8; - unsigned int max_perf:8; - unsigned int desired:8; - unsigned int energy_perf:8; - unsigned int activity_window:10; - bool package_control:1; - unsigned int :16; - bool activity_window_valid:1; - bool energy_perf_valid:1; - bool desired_valid:1; - bool max_perf_valid:1; - bool min_perf_valid:1; - }; - uint64_t raw; -}; - -struct hwp_drv_data -{ - union - { - uint64_t hwp_caps; - struct - { - unsigned int highest:8; - unsigned int guaranteed:8; - unsigned int most_efficient:8; - unsigned int lowest:8; - unsigned int :32; - } hw; - }; - union hwp_request curr_req; - int ret; - uint16_t activity_window; - uint8_t minimum; - uint8_t maximum; - 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) #define hwp_info(fmt, args...) printk(XENLOG_INFO "HWP: " fmt, ## args) @@ -212,7 +168,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->drv_data.hwp; if ( !cpu_has_hwp_activity_window && data->activity_window ) { @@ -226,8 +182,8 @@ static int cf_check hwp_cpufreq_verify(s 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 cpufreq_policy *policy = info; + struct hwp_drv_data *data = &policy->drv_data.hwp; union hwp_request hwp_req = data->curr_req; data->ret = 0; @@ -247,7 +203,7 @@ static int cf_check hwp_cpufreq_target(s 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->drv_data.hwp; /* Zero everything to ensure reserved bits are zero... */ union hwp_request hwp_req = { .raw = 0 }; @@ -338,7 +294,7 @@ static void hwp_get_cpu_speeds(struct cp 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->drv_data.hwp; uint64_t val; /* @@ -406,23 +362,15 @@ static int cf_check hwp_cpufreq_cpu_init static bool __read_mostly first_run = true; static union hwp_request initial_req; unsigned int cpu = policy->cpu; - struct hwp_drv_data *data; - - data = xzalloc(struct hwp_drv_data); - if ( !data ) - return -ENOMEM; + struct hwp_drv_data *data = &policy->drv_data.hwp; policy->governor = &cpufreq_gov_hwp; - per_cpu(hwp_drv_data, cpu) = 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); return -ENODEV; } @@ -450,11 +398,6 @@ static int cf_check hwp_cpufreq_cpu_init 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); - return 0; } @@ -467,8 +410,8 @@ static int cf_check hwp_cpufreq_cpu_exit */ 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 cpufreq_policy *policy = info; + struct hwp_drv_data *data = &policy->drv_data.hwp; uint64_t msr; data->ret = 0; @@ -499,7 +442,7 @@ static int cf_check hwp_cpufreq_update(u { on_selected_cpus(cpumask_of(cpu), hwp_set_misc_turbo, policy, 1); - return per_cpu(hwp_drv_data, cpu)->ret; + return policy->drv_data.hwp.ret; } #endif /* CONFIG_PM_OP */ @@ -516,12 +459,12 @@ hwp_cpufreq_driver = { }; #ifdef CONFIG_PM_OP -int get_hwp_para(unsigned int cpu, +int get_hwp_para(const struct cpufreq_policy *policy, struct xen_get_cppc_para *cppc_para) { - const struct hwp_drv_data *data = per_cpu(hwp_drv_data, cpu); + const struct hwp_drv_data *data = &policy->drv_data.hwp; - if ( data == NULL ) + if ( !data->maximum ) return -ENODATA; cppc_para->features = @@ -542,11 +485,10 @@ 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->drv_data.hwp; bool cleared_act_window = false; - if ( data == NULL ) + if ( !data->maximum ) return -ENOENT; /* Validate all parameters - Disallow reserved bits. */ --- a/xen/drivers/acpi/pm-op.c +++ b/xen/drivers/acpi/pm-op.c @@ -80,10 +80,12 @@ static int read_scaling_available_govern static int get_cpufreq_cppc(unsigned int cpu, struct xen_get_cppc_para *cppc_para) { + const struct cpufreq_policy *policy = + per_cpu(cpufreq_cpu_policy, cpu); int ret = -ENODEV; - if ( hwp_active() ) - ret = get_hwp_para(cpu, cppc_para); + if ( policy && hwp_active() ) + ret = get_hwp_para(policy, cppc_para); return ret; } --- a/xen/include/acpi/cpufreq/cpufreq.h +++ b/xen/include/acpi/cpufreq/cpufreq.h @@ -38,6 +38,42 @@ struct acpi_cpufreq_data { unsigned int arch_cpu_flags; }; +struct hwp_drv_data { + union { + uint64_t hwp_caps; + struct { + unsigned int highest:8; + unsigned int guaranteed:8; + unsigned int most_efficient:8; + unsigned int lowest:8; + unsigned int :32; + } hw; + }; + union hwp_request { + struct { + unsigned int min_perf:8; + unsigned int max_perf:8; + unsigned int desired:8; + unsigned int energy_perf:8; + unsigned int activity_window:10; + bool package_control:1; + unsigned int :16; + bool activity_window_valid:1; + bool energy_perf_valid:1; + bool desired_valid:1; + bool max_perf_valid:1; + bool min_perf_valid:1; + }; + uint64_t raw; + } curr_req; + int ret; + uint16_t activity_window; + uint8_t minimum; + uint8_t maximum; + uint8_t desired; + uint8_t energy_perf; +}; + struct cpufreq_cpuinfo { unsigned int max_freq; unsigned int second_max_freq; /* P1 if Turbo Mode is on */ @@ -83,6 +119,7 @@ struct cpufreq_policy { union { struct acpi_cpufreq_data acpi; + struct hwp_drv_data hwp; } drv_data; }; DECLARE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_policy); @@ -286,7 +323,7 @@ bool hwp_active(void); static inline bool hwp_active(void) { return false; } #endif -int get_hwp_para(unsigned int cpu, +int get_hwp_para(const struct cpufreq_policy *policy, struct xen_get_cppc_para *cppc_para); int set_hwp_para(struct cpufreq_policy *policy, struct xen_set_cppc_para *set_cppc); From xen-devel-bounces@lists.xenproject.org Thu Jan 22 09:43:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 09:43:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210618.1522257 (Exim 4.92) (envelope-from ) id 1virDT-0001Os-WC; Thu, 22 Jan 2026 09:43:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210618.1522257; Thu, 22 Jan 2026 09:43: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 1virDT-0001Ol-T5; Thu, 22 Jan 2026 09:43:03 +0000 Received: by outflank-mailman (input) for mailman id 1210618; Thu, 22 Jan 2026 09:43: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 1virDS-0000n5-Pp for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 09:43:02 +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 be0b3283-f776-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 10:43:01 +0100 (CET) Received: by mail-wr1-x431.google.com with SMTP id ffacd0b85a97d-432d256c2e6so672963f8f.3 for ; Thu, 22 Jan 2026 01:43:01 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4358e24cef3sm18577240f8f.0.2026.01.22.01.43.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 01:43:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: be0b3283-f776-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769074981; x=1769679781; 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=uV5LcusP8Do+2RUwQ8ia4mLDrNFGaesbuxHKzbM03Ek=; b=WbezmzfJQrEaY/fpVT29xyQOe8m1VPRviGyI1i5lES6K4MRad4/EOxmTBoTw+3F+px aKBJHlXw90NpOots4NuFMbodaOEKp3jJpFfJZd+Rz/+8v6M9zRezm2FyhRvckO0ILD2C HPiCATrX9+LDuoC1MWB8tpCphbdqYGmld7173saCGaCZVXc7kV8uKggL4H81vBE68QMY mIkUpV9Ev6MTTitSFSa1AgFQi+u0LgP64QegzPe5QGmjtdyFSBmakgdZwGSqRcuFbtcY xsGREcAteU1TjQ3fZeYHnRO7HHrRNHY1JQk/Os4zlq7Ot8lcr/vpYOadf2RT2zGdqWDz YF7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769074981; x=1769679781; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uV5LcusP8Do+2RUwQ8ia4mLDrNFGaesbuxHKzbM03Ek=; b=muhkaso9OkzSrQKs+zJUROm2OBQ0jHh/b3pu3G+RV2812FwUKuDDTcLz5LwtqvKaR6 KucxDn7skMtZW3x7sZslcekCFPXwpkDqk3kes9KNcEQBIEttF0ipdGuRvTNbekxaF6Yl cffZ/HcFPgrIhG8gUvjDeXmMoKPDYxTsTTfHuNc5X0o6l9Dyd8ySWqwUlSR2pLi6KerU CELXAZyaJTtZGstfAkewrcMJy3YfjFerSwKwN0Usv7fKCYq04xykPiDUFvRkeDGTeweo rr1Crnxk+ivHCSV/jwIywGA5+iTj+2BC036XvGLUGwGWQlovGyDGfA/cPecKqo4BSEyU Recg== X-Gm-Message-State: AOJu0Yzs0DwxziR3HrcqFXK4wRFOch6d31U4S59Jtj5AmEDEphpBdvgf ndqC2tvMjjwEbqJz6lSBytxzeVLg4gjOL2bgrp+sAxshys5QWHDJkzGei+evXyPYo/x0LLhE47g o5Vw= X-Gm-Gg: AZuq6aKAMfUGbM20nMwWZdiwgZQYXIrqWfspQZrwWexVuylEnZ3805eRN4XFOrGjYwa ty2dMEzpdlvVtS2d6DkcQAht7jyw0usL8yiljWa9hf91cbeavmiuc+zapWC6tKoGRP1YpKMwq/q CpCLlqtobOXtSp59qnQq8+s7cOyNRgtToEjdV9AN0qlHQp4vquTMn6Xw+SNZ/RTvm3z6wD5JEe1 wp6t0KrA2FImXSTH1i6uXyf5OO6ZzYLwOfFF0SsItJmhIrQdqpuBfzMdtOQZwxlcDcvwHz+gNKY clTgto9kPkg5zXBKWeUPgnT9Rt+VrYzNJZcu0usKrUsQT7AVerKnB9qq4gyYG8Au3q0erWirUsi 5rzvDqJTU/gzt0H9W0ZlsFXG9JdG0tJxdud2w+K494Jv10mQtBWfY2SPkYkoDCJpt88V0Ec0vhO HL2Z/PbyjrHfjBguiP61aN0uSzzbZcEL1XFDmNVM3uQVsts/gLrlyk7sJTQHiir1CRdUiP9ZjrE MY= X-Received: by 2002:a5d:5cca:0:b0:435:9691:d525 with SMTP id ffacd0b85a97d-4359691d56amr11311318f8f.13.1769074980896; Thu, 22 Jan 2026 01:43:00 -0800 (PST) Message-ID: <519e16df-150a-4336-95dc-b26b8332a884@suse.com> Date: Thu, 22 Jan 2026 10:42:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 3/5] cpufreq/amd-cppc: move driver data into policy From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Penny Zheng 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 Share space with the ACPI, powernow, and HWP drivers, avoiding a separate allocation for each CPU. This then also reduces the concern over amd_cppc_cpufreq_cpu_init() being called for all CPUs, or a CPU going offline that's recorded in policy->cpu (which would result in accesses of per-CPU data of offline CPUs). Signed-off-by: Jan Beulich --- amd_cppc_cpufreq_target() (together with amd_cppc_write_request()) still requires policy->cpu to be online, though. --- a/xen/arch/x86/acpi/cpufreq/amd-cppc.c +++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c @@ -31,81 +31,6 @@ }) /* - * 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. In active mode, des_perf must be zero. - * Field epp represents energy performance preference, which only has meaning - * 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 -{ - 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 */ @@ -279,11 +204,11 @@ static void cf_check amd_cppc_write_requ 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) +static void amd_cppc_write_request(struct cpufreq_policy *policy, + 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); + struct amd_cppc_drv_data *data = &policy->drv_data.amd_cppc; uint64_t prev = data->req.raw; data->req.min_perf = min_perf; @@ -295,15 +220,15 @@ static void amd_cppc_write_request(unsig if ( prev == data->req.raw ) return; - on_selected_cpus(cpumask_of(cpu), amd_cppc_write_request_msrs, data, 1); + on_selected_cpus(cpumask_of(policy->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); + const struct amd_cppc_drv_data *data = &policy->drv_data.amd_cppc; uint8_t des_perf; int res; @@ -320,7 +245,7 @@ static int cf_check amd_cppc_cpufreq_tar * 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, + amd_cppc_write_request(policy, data->caps.lowest_nonlinear_perf, des_perf, data->caps.highest_perf, /* Pre-defined BIOS value for passive mode */ per_cpu(epp_init, policy->cpu)); @@ -330,7 +255,7 @@ static int cf_check amd_cppc_cpufreq_tar 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); + struct amd_cppc_drv_data *data = &policy->drv_data.amd_cppc; uint64_t val; unsigned int min_freq = 0, nominal_freq = 0, max_freq; @@ -431,24 +356,16 @@ static void amd_cppc_boost_init(struct c 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 amd_cppc_cpufreq_init_perf(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; + struct amd_cppc_drv_data *data = &policy->drv_data.amd_cppc; 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); /* @@ -506,8 +423,7 @@ static void amd_cppc_prepare_policy(stru 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); + const struct amd_cppc_drv_data *data = &policy->drv_data.amd_cppc; /* * On default, set min_perf with lowest_nonlinear_perf, and max_perf @@ -560,7 +476,7 @@ static int cf_check amd_cppc_epp_set_pol amd_cppc_prepare_policy(policy, &max_perf, &min_perf, &epp); - amd_cppc_write_request(policy->cpu, min_perf, + amd_cppc_write_request(policy, min_perf, 0 /* no des_perf in active mode */, max_perf, epp); return 0; --- a/xen/include/acpi/cpufreq/cpufreq.h +++ b/xen/include/acpi/cpufreq/cpufreq.h @@ -74,6 +74,78 @@ struct hwp_drv_data { uint8_t energy_perf; }; +/* + * 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. In active mode, des_perf must be zero. + * Field epp represents energy performance preference, which only has meaning + * 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 { + 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; +}; + struct cpufreq_cpuinfo { unsigned int max_freq; unsigned int second_max_freq; /* P1 if Turbo Mode is on */ @@ -120,6 +192,7 @@ struct cpufreq_policy { union { struct acpi_cpufreq_data acpi; struct hwp_drv_data hwp; + struct amd_cppc_drv_data amd_cppc; } drv_data; }; DECLARE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_policy); From xen-devel-bounces@lists.xenproject.org Thu Jan 22 09:43:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 09:43:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210627.1522268 (Exim 4.92) (envelope-from ) id 1virDz-0001uE-Bu; Thu, 22 Jan 2026 09:43:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210627.1522268; Thu, 22 Jan 2026 09:43:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1virDz-0001u7-8U; Thu, 22 Jan 2026 09:43:35 +0000 Received: by outflank-mailman (input) for mailman id 1210627; Thu, 22 Jan 2026 09:43: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 1virDx-0000Cq-Ij for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 09:43:33 +0000 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [2a00:1450:4864:20::332]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d00f037f-f776-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 10:43:31 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-47eddddcdcfso4122285e9.1 for ; Thu, 22 Jan 2026 01:43:31 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4359f4a7ac7sm10309584f8f.20.2026.01.22.01.43.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 01:43:31 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d00f037f-f776-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769075011; x=1769679811; 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=fLtQAXdQpvWtzRgQd0SjG5ynKciIprq6k8v637TMVBw=; b=LzdoENZUScrhFuFxf7Fjc/dTAWkpXES6wuoLMMAQYHVEwzxI+uSjrujMk5E6023rCf wlmp5Th0QqT/LjFgPQY/0f2hBhy89wO5U1mMPwh4yK/60aKn/2LXqBZ0mFuJqkw/v8XZ tJAHJW3oNgsRo6BfnDQjTJ8JcInIjdxuuxutUbuZsMYu/kR4mKnwtBWpdeGTcNO0bxak lXsoCr/HgPEX/oe60Z65PFgiuO8DT9JCYFvub+fBqbRQZuSF0k/3gmIqFzCAkVod7rUw tiKOwh9y45fiS3q2dwqT1zzUO4Z37aogiQWy8kgndE92yobVqx2/CrYqgakTrO4Q4gEH Oirg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769075011; x=1769679811; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=fLtQAXdQpvWtzRgQd0SjG5ynKciIprq6k8v637TMVBw=; b=KPc/L3f1K93oNVNT5KUMf35kOZuOscb/eTfgMfFCfWZWdYEGLU2FTEmniYcL/sfnKh YtsSz5kBBKE2DJGZjKN9L0DzHlf1gT73rIpn31mXbKnm3BFFO6OAqhUqtlOp+ZKFZL3N RB0Pyaj6/YKgik2zXYqOJGQnmAI86pnfICldVs29iok7EsZ0g6KESSimVrgaxJaGsyJg netmr+xgYdR9gBG+HK9GUULYo3Fc3/Lqa6X9rxcFxOpnkm0xz29C/17p7A7Q/AqUG8cq TwjjbZVHosODfoIA9akyENHaeT8JJS7gwJi20tiAo/NjaVE+9wrPEDun4fO9YEJWVyyg 5tcQ== X-Gm-Message-State: AOJu0YxEG7BUZ4JIxIC+rCRHDZ9A5AprxY+dCA/WboJjVYDHBFHLI45l Lb2LdbFBn7ZfQoC85GCHH4xnEROtRTK2gT6FUA3E41cMZBjNez3cm+QLhbajtqmsWaMVpdWtVku rxgo= X-Gm-Gg: AZuq6aLYPk4CTeh28aZF0JeLo7M36Meib01rtsU3kd6CXxiuuHuTYHkRdJk4pq7BCl9 FqcV0Fcs/PtPFQzVAFbKlWz2rXxdOtDAySodVJj8YsVZ3FZm7H7u3rBERz5hfpFWuO5tuh6617e OoyBpSvvZaW1COEDhErTbx5FzpD9cylZ3WwTE8X3G4CApYu3nVYWE9ct1M7TINrMkl4n0B+98gn X3TkDvajRp+YhYXB3cxtNOUdtJj25SUGGHzzdK/1iLCDw5PL6fQUy7vG0Jrrh29cqk1H2e3rhvs DdnBXfcoVvH43UIlsuZC6GrCOy1bDk84kwVRuOT2cVursCBzBmbLgcKXrdg4rj6brEVKZx/eu7x VQxQN6227FLta9uc7GydHzt02UZ3jiL1a8rhwkB17VKH/lVmY1gPuHJ0RPC/ej7LbVXtcpsLKcz FyqSVMZbZI40kt0roiPaQWA50fxyYXVGI16lnP1Xlz6FpXNyWX6JjKKmajw5ULr8yzi50aJxXw4 T8= X-Received: by 2002:a05:600c:6215:b0:47a:9560:5944 with SMTP id 5b1f17b1804b1-480432c4b7cmr79750625e9.34.1769075011276; Thu, 22 Jan 2026 01:43:31 -0800 (PST) Message-ID: <18639925-4e8f-4d58-a850-291d7ac0e6da@suse.com> Date: Thu, 22 Jan 2026 10:43:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 4/5] cpufreq/amd-cppc: move epp_init into driver data From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Penny Zheng 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 No reason for it to be a separate per-CPU item; it's connected to a struct cpufreq_policy instance just like other driver data. This further reduces the concern over amd_cppc_cpufreq_cpu_init() being called for all CPUs, or a CPU going offline that's recorded in policy->cpu (which would result in accesses of per-CPU data of offline CPUs). Signed-off-by: Jan Beulich --- a/xen/arch/x86/acpi/cpufreq/amd-cppc.c +++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c @@ -35,7 +35,6 @@ * 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); #ifndef NDEBUG static bool __ro_after_init opt_active_mode; #else @@ -248,7 +247,7 @@ static int cf_check amd_cppc_cpufreq_tar amd_cppc_write_request(policy, data->caps.lowest_nonlinear_perf, des_perf, data->caps.highest_perf, /* Pre-defined BIOS value for passive mode */ - per_cpu(epp_init, policy->cpu)); + data->epp_init); return 0; } @@ -326,7 +325,7 @@ static void cf_check amd_cppc_init_msrs( /* 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); + data->epp_init = MASK_EXTR(val, AMD_CPPC_EPP_MASK); return; @@ -465,7 +464,7 @@ static void amd_cppc_prepare_policy(stru break; default: - *epp = per_cpu(epp_init, policy->cpu); + *epp = data->epp_init; break; } } --- a/xen/include/acpi/cpufreq/cpufreq.h +++ b/xen/include/acpi/cpufreq/cpufreq.h @@ -143,6 +143,8 @@ struct amd_cppc_drv_data { }; } req; + uint8_t epp_init; + int err; }; From xen-devel-bounces@lists.xenproject.org Thu Jan 22 09:48:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 09:48:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210640.1522278 (Exim 4.92) (envelope-from ) id 1virIQ-0002uB-SD; Thu, 22 Jan 2026 09:48:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210640.1522278; Thu, 22 Jan 2026 09:48: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 1virIQ-0002u4-Ot; Thu, 22 Jan 2026 09:48:10 +0000 Received: by outflank-mailman (input) for mailman id 1210640; Thu, 22 Jan 2026 09:48: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 1virEI-0000Cq-UU for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 09:43:54 +0000 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [2a00:1450:4864:20::331]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id dcbeb970-f776-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 10:43:53 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-47fedb7c68dso7544205e9.2 for ; Thu, 22 Jan 2026 01:43:53 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48042b6a3e2sm51107065e9.1.2026.01.22.01.43.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 01:43:52 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dcbeb970-f776-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769075032; x=1769679832; 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=b6ZgQHfjrDjWEfMOq63jsxR+PhNdjaZ5C3nYexbwyrk=; b=WWPRZnDyYKIE6CYBNkSihkY4kPKFBzzPCPIKO99ioJ12UwC0rZ5GGoe/CnD+gPMCZS ZkDssxYdhW1FE3jIaF+B6LNsdkKhtF8JuA7+1WvQDb1E4pHT4B5Cg9ZVWZzeDBcRJt/F J7HvuX4OvorlZZZpMux6ukRpWaj4O0qcUbgONu+ggNt7qk4qBfYROCFeEuegvDhQvtFh 8+0VFOsNVGI7J2HPeJSp6IfUvDWZup2zD+QxNBzVV2M4Jgjjemr61m5fl6lomsF4yl4F Q3YGeVnzKIUybE/bfW3YmG/7vk5s8nNSBaYBQIBTkEt1+m4I4Q9dQ5/0xBuyw74ag6tO rc2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769075032; x=1769679832; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=b6ZgQHfjrDjWEfMOq63jsxR+PhNdjaZ5C3nYexbwyrk=; b=shoruM9WxfBJoGC+qj74RzGegsm4LSnwuixmqDGn1RvpQ9/DmNVaNUiNdj0PMUd3+y soy/81DFC37tfsxaqoI0rSbwhwk1HtEH0Z93NSJVMyIIy0XdtFjJqhPZnmpzG/FpnSek kaw0ZWd+PcpGjHZIiCfWOM9YBbvYX/6YWDunUMGBC5JOXZS6vB4Ajyy48Qq/QXwtMYbp Xvl5MeX+ScCV9tanqhtLjtjL/lQ1ZML022OKQ47IlPNToBv+6resxu5Zgm4BV8G27BJ4 eboQeRxk9eRi7fwb0qtJZYpY4HG2SQtNRbnbakLhqaRpQ7Ur2IfJvwf4wi5Cr1HjtpUO gt4A== X-Gm-Message-State: AOJu0Yw+uEuTnh7STHF6Pg6vf5/QroX+Q7BpjnOQ28A4qp3zTEeZ0kaO 7QbWLoN/cT1C3TU0VWU40sX9dGQzEERnweJ+CkMfQ34KIYg8AQ40EqeSuojBxjsEubUe8LzXbKh XF+k= X-Gm-Gg: AZuq6aLkNToiUNYWiYUEi3+S1YRgY5c396sOYo/T7Nc7a/NxYAEI71ARL0SS/ghAg85 kqLbhkauvpMmMELsW/OqXY7X2dO1NaGocPigHMlaDdabUU3Fi5xpAVZIaofH0IxazKT+cTNMLF/ v1fMo2rKF2ZWAc1m7vG2pVva9b+l1qwqQ7UHSiXufBntTufONTu0TYeoKsNfYYmbzz1rOgQErPl lxUrAMNLtC2CNll0b+u+nOFeiPg5JCXnzbHiiWBo1x4PCo/AgohcXvAn5jc/ckgNJXMZxaCLz31 5IT6rUwgFOHo1hz9FWrWCndMyibv6d+xK0TN2YJy0nfHvkhaOIL7iAUEoV0tZDLqvms82UYhD8W 4MyfJOtPWjGg4wz1q7+lKUobQ+GxNxnCkW6FcOgU0IDab1gUlIV9DTXyq6/2Nrk+AkJvd7H14yT XVzkhFirQk18NgPGA45Jl/08veEO4Ro/N1uPpFfrzBFAyU3zQp/nS6Xo6vkIOgYbB1GN4eSL+wP Kc= X-Received: by 2002:a05:600c:8b67:b0:47d:3ffb:16c9 with SMTP id 5b1f17b1804b1-4801e342091mr235179655e9.23.1769075032572; Thu, 22 Jan 2026 01:43:52 -0800 (PST) Message-ID: <715604a8-265b-4832-8001-1a2dbdc870bb@suse.com> Date: Thu, 22 Jan 2026 10:43:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH 5/5] cpufreq/amd-cppc: move pxfreq_mhz into driver data From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Penny Zheng 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 No reason for it to be a separate per-CPU item; it's connected to a struct cpufreq_policy instance just like other driver data. This also eliminates the concern over amd_cppc_cpufreq_cpu_init() being called for all CPUs, or a CPU going offline that's recorded in policy->cpu (which would result in accesses of per-CPU data of offline CPUs). Signed-off-by: Jan Beulich --- a/xen/arch/x86/acpi/cpufreq/amd-cppc.c +++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c @@ -30,11 +30,6 @@ printk(XENLOG_DEBUG "AMD-CPPC: CPU%u " fmt, cpu, ## args); \ }) -/* - * Core max frequency read from PstateDef as anchor point - * for freq-to-perf transition - */ -static DEFINE_PER_CPU_READ_MOSTLY(unsigned int, pxfreq_mhz); #ifndef NDEBUG static bool __ro_after_init opt_active_mode; #else @@ -117,7 +112,7 @@ static int amd_cppc_khz_to_perf(const st { /* Read Processor Max Speed(MHz) as anchor point */ mul = data->caps.highest_perf; - div = this_cpu(pxfreq_mhz); + div = data->pxfreq_mhz; if ( !div ) return -EOPNOTSUPP; } @@ -160,7 +155,7 @@ static int amd_get_cpc_freq(const struct } /* Read Processor Max Speed(MHz) as anchor point */ - mul = this_cpu(pxfreq_mhz); + mul = data->pxfreq_mhz; if ( !mul ) return -EOPNOTSUPP; div = data->caps.highest_perf; @@ -287,7 +282,7 @@ static void cf_check amd_cppc_init_msrs( } amd_process_freq(&cpu_data[policy->cpu], - NULL, NULL, &this_cpu(pxfreq_mhz)); + NULL, NULL, &data->pxfreq_mhz); data->err = amd_get_cpc_freq(data, data->cppc_data->cpc.lowest_mhz, data->caps.lowest_perf, &min_freq); --- a/xen/include/acpi/cpufreq/cpufreq.h +++ b/xen/include/acpi/cpufreq/cpufreq.h @@ -145,6 +145,12 @@ struct amd_cppc_drv_data { uint8_t epp_init; + /* + * Core max frequency read from PstateDef as anchor point + * for freq-to-perf transition + */ + unsigned int pxfreq_mhz; + int err; }; From xen-devel-bounces@lists.xenproject.org Thu Jan 22 09:49:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 09:49:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210658.1522287 (Exim 4.92) (envelope-from ) id 1virJi-0003Vq-46; Thu, 22 Jan 2026 09:49:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210658.1522287; Thu, 22 Jan 2026 09:49:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1virJi-0003Vj-1W; Thu, 22 Jan 2026 09:49:30 +0000 Received: by outflank-mailman (input) for mailman id 1210658; Thu, 22 Jan 2026 09:49: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 1virJg-0003Vd-EM for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 09:49:28 +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 a35bff41-f777-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 10:49:26 +0100 (CET) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-4359a16a400so658115f8f.1 for ; Thu, 22 Jan 2026 01:49:26 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-480470bfe42sm53188735e9.9.2026.01.22.01.49.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 01:49:25 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a35bff41-f777-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769075366; x=1769680166; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=q4fCqo5ONabOxDETkRzIQs/C9xZZRh/QiADKln5rAdU=; b=E9vR/c8PQbfQIVu3g8VY5Kfvwa9x62gifQRUwzk8jCEcMRRXpnnMMCgL7wME3tyYqI 0q6BFPynfwGmn7vkKFW5S4HtlHk4D/a0ikBcDZOSFJzkYHyJ8UhsWsQwQPY8ceE1QY9m ipaDlXm/PMD35DMW5Umjjw192CtTAkwluXqVgo0NEtJrAGBQN9/i9+c/VmRakqe7OgW0 gYXyBmZugyrlat/m1FgrurqUWXNoMM9IvNI8uP/eUnk0h/8DBMbM5AgWHP2RA/HaVKBO pNib3Nha9rfxJvEc5KMegpaLWXxw6SlQezpqSTL3a5V/4b015dEp2weJvAKGp6Cjwzqk 066A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769075366; x=1769680166; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=q4fCqo5ONabOxDETkRzIQs/C9xZZRh/QiADKln5rAdU=; b=Td+lumt+Luob4B+/vSu5VaDX5a+SErV4YmX71ZeMPzapi4GKL4HW0YMh1oVbKS95hE xRn/qX4qgnDyzTEoUlpiFLKZAcQRJ5wHW4ORbdi9n/yJ1OsG4EzNj0ixTDiMQH8yntBv f3XEvcYioYY4UWUWkq45uouDFPuavFS7WO4/w5Ghfr5j+M7o6b5XVRSh0f7UpICq/CaA /U+/yB6SRK7FZUEJNrZv7jlcOz+shZj1rqO30rzIvRtJOocMhQpiO3VKVS32DfGAGL+M 4fOBxSuCeGOmUUcToPPrCGzLpkK1duiiT/T9xMMu6/0xgANFxPtjoUmz5h9Xy/mE8IjF iGwA== X-Forwarded-Encrypted: i=1; AJvYcCVRLzvrmtEJq7ENLlQW7748JJ0pUOQ/Wy5Vk50fTFTZL2TNuE6b7ZgF8Ezj7eC7ZxU7UiiLWU6N7EE=@lists.xenproject.org X-Gm-Message-State: AOJu0YylfQ/6J98Rij0Xo9f1/sLs07pJYHvGNf/WmE/hR3MZ+xbRlTMY v2SwhgzWVjvdRzTHrHRma5DM9JyEZKCrXSiBV3dXUKzXXWMWnEFT5bd2qtpe8lZo1w== X-Gm-Gg: AZuq6aLxKsBPX/CsQjdZ7L7eTMcRxpfzztXgbmiDxRPpQZoZaNV2x8J7BZBrIhMptUs UKvwjn7WWeZZ5NAleXKA4Zf4Gr4/RaRfmZWwWYR6XfBHKPVXooNiNVeEifEqkEZPYJmqeiUMlci OXyml53k9EqvYV56mTDJMNOLb4BlP0Exd0LlQFDtDukLdMybNu/WAf7eK2SXvizuLHWe8iNSuKr 1ABvqjwOGa67BE1vViJ+M9gQHeLYjnW40oFEsvqJGFfrhqI669eHcuyqCzIB6s23jYsB7idiThd srPkOVwr0sEQR7NfnADISjkfz1DV9841jWgPaGgoVdTV1eBtnOJyrKOVVF7kOU700UGH9zSX6Wx R/Bb6hZ8CJWjIOgK+FfoiakfvkIJ2u8jQSQs1iB737EjGQLpnl+mVfcHB+aprJWcE2Cn2oaMjcX u6Bz1QpOrpzQsiFcX94t+chIvhAvDFgmoeTeTFEKrTS0KeY1IyN/RPqLPZmuSrWnJGcuHwwnpom cdHei1aJaBwFg== X-Received: by 2002:a05:600c:4fcb:b0:477:58:7cf4 with SMTP id 5b1f17b1804b1-4803e7900c5mr121624285e9.4.1769075365721; Thu, 22 Jan 2026 01:49:25 -0800 (PST) Message-ID: <526ef477-0730-4e22-a82f-4c598ad78e0a@suse.com> Date: Thu, 22 Jan 2026 10:49:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/2] xen: Allow lib-y targets to also be .init.o To: Alejandro Vallejo Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260121154757.44350-1-alejandro.garciavallejo@amd.com> <20260121154757.44350-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: <20260121154757.44350-2-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 21.01.2026 16:47, Alejandro Vallejo wrote: > There's some assumptions as to which targets may be init-only. But > there's little reason to preclude libraries from being init-only. > > Signed-off-by: Alejandro Vallejo > Reviewed-by: Jan Beulich I can't tell (yet) what it is, but as per CI something's clearly wrong with this change. Both xilinx-smoke-dom0less-arm64-* and qemu-smoke-dom0*-debug* fail with it in place. qemu-smoke-dom0-arm64-gcc (no "debug") was fine, suggesting it may be an early assertion triggering. Nothing in the logs though. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 10:01:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 10:01:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210674.1522298 (Exim 4.92) (envelope-from ) id 1virVL-0006Sn-4X; Thu, 22 Jan 2026 10:01:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210674.1522298; Thu, 22 Jan 2026 10: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 1virVL-0006Sg-1f; Thu, 22 Jan 2026 10:01:31 +0000 Received: by outflank-mailman (input) for mailman id 1210674; Thu, 22 Jan 2026 10:01: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 1virVK-0006Sa-BP for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 10:01:30 +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 5168a8cf-f779-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 11:01:27 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-47ee3a63300so8574025e9.2 for ; Thu, 22 Jan 2026 02:01:27 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804702fab2sm54081865e9.1.2026.01.22.02.01.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 02:01:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5168a8cf-f779-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769076087; x=1769680887; 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=Bz3q4wptmIgWHxWg3eFEYGpWgJA5shrc0daZoi+lUQs=; b=XNKRlTP31yzBgOjeS6T04SwNNtHsmJFFlw78jP7w/+2okHDhIQ5psvtszQjSCtjY+8 eSpPR8FRXkBkBPXKGbvAhZHMyG808fxGwylk3cDlprKff2VgR4ngtoQ0KuF1tjAZSbBP tIbrqlvQ6eLoGxcHBmXgJkkAx7zhk8hSwKXzNXlUG1tO5s2TCDeCA0GRsfXilYWiKuxq Ia3QaJzwMT0CdFq4WoIn+3Qe/MZuEIxAiB6GqIGxKNyZTdU+/kvT19xgwRoKXuBhjc3k 9hgBPwGOciWgZZk49yF1Cttv9FZBRuBfNm80Qd+mXxN/nGLC6LrHJe20gbjjMroIHmeV oXaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769076087; x=1769680887; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Bz3q4wptmIgWHxWg3eFEYGpWgJA5shrc0daZoi+lUQs=; b=jTPoRGDK5EtxZctYO/Y4dPO+hSsqGUJoqdrLB9IlD4GSmu1tEoRz1PTRlcq4bZU3uz WfafNmCImlQA+rLQhXkrdXHOdNgoJpIrXSUSTMWC3bVAjOXHiusGUGSQ2tJ2ZiuQmFxe d1+83rCjUUDtIbQcOx8jcjk4ihpWBnThvZonwkdmXujF+spL7j56sJT395rm+87sPvgy XbeWH6B1bpkTzM6aWeimrFIwzv8Pj1T+OpXsG2eQJyG+qQ+GPHkLacjHsAbVr3KiLqti ohe2867HSroPXnQ8/T9qXMqckG3WyZ6Zox3dPvxb6xkMMKR9kswr1x+ZjHJR0OMQF2bb Vm3w== X-Forwarded-Encrypted: i=1; AJvYcCVlfn1thbSp9seMqkJXypp9HnhpeXgraSEfl09Lz/8WfvAB9y1eHlycfXBkdTNvzdyjmuNROgBoypA=@lists.xenproject.org X-Gm-Message-State: AOJu0YxgXKvOTim8tUoR5uWzbam2euPrkAtTWcBU/6ABoz8sNs/n9Yff pTOZ3xgBtmvJ+VVc2SU6RRbkixA7j+3xUwOarGcejFAdFaLYMDZ3MslGY55zAgg1oA== X-Gm-Gg: AZuq6aKyIW803eBE5OiBky6IMWn7WE/JFTSHaxAVSgISmDXbbrfeP+LIKYozpGXf2G5 DUWskg0CMq/kecSEtRWWd/uph+e463E0/YScvXByK+UgEuDKgPAh0TL/fYWZww9oQhaUXtNEK1R eFMPtU5x0QGyNRDm5Bl/WqWg9Xp+ZPAicMRtyMWUg+csWvO8RMxkchlm++GyicOlu4WF60E3FKq GK/4DOdaqgu/4Ted8YsmHp7precFw3+ZcZ3I+88EM5yJ2PnhB7kFGG0oQhtndu5pT6exXT+l4t7 qEelZnaVTB/QfplkgyOhmLdqT3T0uu1WknQYkkItKt0IId57OI9I1vo9IPlnbwpy/KgRhwei3QK E9iIa+JK9fM3indzbMFagfYak+62CpuKkyeHDGsszXE3a5abgC1vvB4wxrW8TxdlhfJySj1ViIb 3GBjFN9AiaRDI+3KQmWFYn5lr3+bPMvD0t+vXo7k7yJCdaRHprU/EHe8YjXobVcVWnZyXZRlrIA PI= X-Received: by 2002:a05:600c:3e12:b0:477:76c2:49c9 with SMTP id 5b1f17b1804b1-4803e78ff26mr116539645e9.2.1769076087216; Thu, 22 Jan 2026 02:01:27 -0800 (PST) Message-ID: Date: Thu, 22 Jan 2026 11:01:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/2] xen: Allow lib-y targets to also be .init.o From: Jan Beulich To: Alejandro Vallejo Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260121154757.44350-1-alejandro.garciavallejo@amd.com> <20260121154757.44350-2-alejandro.garciavallejo@amd.com> <526ef477-0730-4e22-a82f-4c598ad78e0a@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: <526ef477-0730-4e22-a82f-4c598ad78e0a@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 22.01.2026 10:49, Jan Beulich wrote: > On 21.01.2026 16:47, Alejandro Vallejo wrote: >> There's some assumptions as to which targets may be init-only. But >> there's little reason to preclude libraries from being init-only. >> >> Signed-off-by: Alejandro Vallejo >> Reviewed-by: Jan Beulich > > I can't tell (yet) what it is, but as per CI something's clearly wrong with this > change. Both xilinx-smoke-dom0less-arm64-* and qemu-smoke-dom0*-debug* fail with > it in place. qemu-smoke-dom0-arm64-gcc (no "debug") was fine, suggesting it may > be an early assertion triggering. Or an early UBSAN failure. I think ... >> --- a/xen/Rules.mk >> +++ b/xen/Rules.mk >> @@ -130,9 +130,9 @@ endif >> >> targets += $(targets-for-builtin) >> >> -$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS-y += -DINIT_SECTIONS_ONLY >> +$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)): CFLAGS-y += -DINIT_SECTIONS_ONLY >> >> -non-init-objects = $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(extra-y)) >> +non-init-objects = $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)) ... this is the problem: You're _adding_ library files here which weren't there before. Why $(lib-y) isn't here I don't really known, but as per the CI results there must be a reason for this. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 10:05:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 10:05:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210688.1522307 (Exim 4.92) (envelope-from ) id 1virZ7-00075i-Nz; Thu, 22 Jan 2026 10:05:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210688.1522307; Thu, 22 Jan 2026 10:05:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1virZ7-00075b-LQ; Thu, 22 Jan 2026 10:05:25 +0000 Received: by outflank-mailman (input) for mailman id 1210688; Thu, 22 Jan 2026 10:05: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 1virZ6-00075V-Ld for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 10:05:24 +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 dd3fcd8a-f779-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 11:05:23 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SJ0PR03MB6502.namprd03.prod.outlook.com (2603:10b6:a03:38e::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Thu, 22 Jan 2026 10:05:15 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 10:05: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: dd3fcd8a-f779-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nXXw03V9QtBm0dB5stzl0iVhWiz19MQmGmfxhHZFNDjVBzGl/OQZfFrUkyJzu5IruLMgrgatnwwCXFE3LPsss0Puk9+loxnTQzJcpmap7zDp8L5Pb37ZNZLNIgbF3oNauhS3rF5s7zMpOocdfGbP3oacHRTP13cFTiZqx5ftJUWxZd10rzIbiv2M0yfbalcoCbnrS04ZAfhAecLdYFRp3vyIC8BVRam+0yn679RQZ5ikRKlEw7D6Kq24Ow1Bcf5+akiFlEwA2MuAkQhkqw91TW6VOPTwwPCUIUpDe652Jx8W48LHa14R1irz1yupj8pp/ZNH5PSeCijrN5IuX55v1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2P0OrTzrEB8z8isqkI+y7pRtgtDM55aReYKK6wcLRyw=; b=sleFYB/lvV0XXcoshUYj+7jkaosrcK8nWyzLekr0kEtUDpw8yLbjcNBbVK4KVtHopO4pkGAipKbQtrd12Z1ONZFYwE1uxVtW8TebjWSLRp7YRDH40MS+xfqaci4R75k+XOTOWrj75wjJljU+6sWgGusXtPaoT8+4LEf7p4H3rJiu4oS2nicV9xJGLru+lw86uIpvA4ckpLmGOeevBos1idXRCAH3fXvonq7x9LyLVXAbNFFezbJHePw/Ed0/iudmn/b+veFNpnamdEoM8nlfX+YPG3082FeqLVnmLUcCloa82UBRw+Z8bDxXCUR3RDfXKce6nVeyVS+fx1OW+4skmA== 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=2P0OrTzrEB8z8isqkI+y7pRtgtDM55aReYKK6wcLRyw=; b=PV1/C4NEQr3JhfVErujSIcyhpVxXMbDNoZuYA8oGvjQE0Q8jBZuRl2KiX+1Tgf/7ZD5j7zKvK/IF0fubz+VVzGXoy6MsVVtLAgFuw8m2A8iDBRuhEOvMLNPkX+HoIX5e2L77KFGPebQ/IJNm8WIz3o3Vtl6XJlVGet1vDAs8KD0= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 22 Jan 2026 11:05:08 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH v4 7/8] x86/HPET: drop .set_affinity hook Message-ID: References: <57f34114-54b7-483d-8ac0-e9fa49df959f@suse.com> <5e09670f-dd80-4dfe-a8d6-182545b744ee@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5e09670f-dd80-4dfe-a8d6-182545b744ee@suse.com> X-ClientProxiedBy: PA7P264CA0076.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:349::15) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SJ0PR03MB6502:EE_ X-MS-Office365-Filtering-Correlation-Id: 8185b18e-8351-4847-5f3a-08de599dbcd0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?QW9EOFhCM0hFQldhQS85YkVSK3dJcjMrajhZbCtmUDgybXhUNEFEMHNpTmVJ?= =?utf-8?B?ajZSaEorVlFvWjVWWmVlNXFIR0tYcnhrNGpyQVptY0F1YklyL2Juby9jaVN4?= =?utf-8?B?bG55Y3FmRlVOTGFzaXJQMVEwM28xRVdqekpxNkRQSjgwdU0zczVWNkRzTEJZ?= =?utf-8?B?b1ZXV3FOdnZ3T204RGM2NzNsdUEyMDdoZ21COXJhSWQ1dnFFN1QxeXpOL0Nl?= =?utf-8?B?NXkvUUUyNThPbGMxelRHeUFLbEg4VlpMamdZNWVMMTk1MFRtSnVNaEJ0WWZk?= =?utf-8?B?ekhRMllrK0Z1S1BRWUtUcFlNYnoreDVtODN1TFZUR2x5Nzg2aVdCTlI3ejFv?= =?utf-8?B?NEx6SUd5cC9qUEFWanRVQ004aktTRnZPM0h0emdGb082YytCeTJudmFVVCtJ?= =?utf-8?B?RGZtT1h3SXk2T0QrN1ZyMTdLK2oxdjZrQlpMbzhPT01pcG9jU1F6OGduZUg4?= =?utf-8?B?NmRhbkwwb2ZOUElLdElTTy9lSTM0VWczVVVlNTBhMzdwTm9QSG02VnY4YnQx?= =?utf-8?B?NTJzVWI0U0xJVDBuL1NiOWtMcDJLcG93ZUR0b00rM2lVY0crV0p1NGdhNDln?= =?utf-8?B?aWtqWGJVNVJ6WnJPaXZuOXlyVzVCUWp2VDE2eWFrZmpWLzJvY2g3OFpHeE45?= =?utf-8?B?QXZxclE3WkQzcHFBTSsyMmlUYUhJUHdKS3ZpU1JYZ2tXRFdPdkNYWi9Wd1I2?= =?utf-8?B?VXZ5V1FMOTNxcFZrNjFtKzhlL1RnbWN2WDFzTklCQTdKQ2taMTB5dkdLZm9E?= =?utf-8?B?WFY0SzlxRHo2SVBGdFcwWnBSM253U1lhd0Uybk5uaFUvd0JBelhra1JYMXkx?= =?utf-8?B?aE1JOEhJcVYyditGQittK1dOSk85MTQwWUZBMjBiU0h2dHU0L2tqMkdod1Vp?= =?utf-8?B?V21jeStZWHZ5MktMaVdzbmRMbzBHZXlWR3hlSFhCOTNLSWFLQXd3b0Zib3Bj?= =?utf-8?B?YXk5UUdTcndMendwYW90TEt2VUI4d1RnSnZ4S25PYXpLaWloZHdMeHRmY3NK?= =?utf-8?B?czdTeHU2UHExaVIzalNrMWRHZ3BGTWZBemxBZWZGZlJCWDNLZk5sblY0Ylhr?= =?utf-8?B?UE1lZ1lqOEJEQXZaWklmYlRKTFNaL2QySlcrNk4vMFQ5TzJob2VJNkpLWkc3?= =?utf-8?B?aGV2aEI2ZTAvS1UyWDc0VmpoVkhmdlEyV1hPQjlmWklYaG5nZmVEMHRhUEpw?= =?utf-8?B?cW9wWko0bnBJa0d2WiszQmFKQ0RmNEhQR1RzalJzY21QVU9EQlIxVnZJUVhR?= =?utf-8?B?SW5yRWFGNmJXWUJocTNnZlFFRVdRVHlrbFRHUDgxM1drMEFFQXRKOGdjdERN?= =?utf-8?B?SVp2RHFreUE4dmpDUU1neWRzb0JtemVuVzR2a2NPOTRodi9nWWhpdzd0SnRi?= =?utf-8?B?ZUZvSUQyLy93SDQ2UWc5ZHZ1RkUzUUJra21aazU5WGhkOWRQTHVRekFGRVFW?= =?utf-8?B?STJaV2ZvSmtHc0FYOVg3allEOUJKckQ4b3JEcUtCdlFFMERyM0RvSGhFRytu?= =?utf-8?B?cGpYcFMrWk1lWUhSUGJEaG9RUWNDMlprMDRHaUljZXU1eFRweVBxbWFINWN6?= =?utf-8?B?RWphYVg1d0JYS2F5NFZGVVpuVVlaT2VFSy9mVy96UURkZ2Z4b2JOMGxwejVa?= =?utf-8?B?SnlKRjFuV1B3UWRoTXBEbDM3NTZMcVFwM2RPd3h0VVpUS21pZFlnMkl0Y3p4?= =?utf-8?B?aGVsMzMwdm1WQXdBVkZoTWV1bnpnbEJZb1F4V1lHcUNRMVhxOE5NWUx4Nzll?= =?utf-8?B?RHJvWnJ2Z21jUExzUVNmM0M1U3B4MHBKT3crbWhRNUJPVWREZGhpK3J5S0Jn?= =?utf-8?B?bXpZcXUxVXJ1UEIra0Q2TFo1Mmd3R2NCcGsraUZvbHlEcUlaeHB2Qy85RWhN?= =?utf-8?B?Q3JjcXp3L2x6MzNZVzdwNzNGZGVScGcyRTVnSVVpK2k2V1VRbDFnenNBTkJS?= =?utf-8?B?azBldlZSWVlKU1RxbjFITi9nOFFuR2hHOHFFWHhRM0FQNERvdTJOdCtkT1F1?= =?utf-8?B?NnJVVVhSV0dyZjFXOTQ3ZDNRZnA3ZDI0dEU4eUJ0cmVKTmpSdDJKWHRpWE9Z?= =?utf-8?B?T3kwVDc3U1hJN0lrSTRlNThCVnI5a2NXSXprbzRaNkRjdFE0NnlDV1VrLzZw?= =?utf-8?Q?Nna8=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ai9obUNsaTVIR3ZRcVV6REdEd09NOU9YWTBnbWk0VzE0NlZIYm41YlBsek9T?= =?utf-8?B?K0JuV3lIWVRTT1NNZk85NUtjRzAzWGpyZFFsR3NvUFU3ZG13ajFrRVk4ZXpw?= =?utf-8?B?bmhQRTRJZkVDMzlsenBTR1dUZFphRURJZzNyRk5VVnk1QzJTZzVLVVdZaXVM?= =?utf-8?B?Q1dzTUVsZ1lYM2JJZ1RsZmVFd2RUM3lFQ0FPcFVDWWtPR0RZeTg2cmkxbCti?= =?utf-8?B?bU84MExwb0JQT293OUlIMzJmelVSNEtUVXpuMTBYcXBKYTMvZFVCMTBhdUM3?= =?utf-8?B?MmtOdFRQYnd3Uzh0ZzExamRIRzdFWWI0YjJLWWhrV2l4UFVGSUd4N3R4Nm93?= =?utf-8?B?cUUza213RUVxVkt2L0JTRWFXYVFUL3JBbzVadXI5RmNPSWFwSlgyTXdIVk9D?= =?utf-8?B?THRnTEM0WmpRNGJPelVTODdkcHo2RzZzYnUzODNxYmJETU5VVXh4Q21GRlBj?= =?utf-8?B?NkdrcjdLTEZQbDl0eGJjT2hBdml4MTZTN1MrcFA5R2JlYTZ2c0RxaldFVkgz?= =?utf-8?B?V3BRbmR4ZjNhcTNaWWRJQ1ViT0FGMkhMREczWU5xbTZzMjZ0U2p0NkxTUFZx?= =?utf-8?B?ZjF4R2t0bHl3alpNU1ZYbml2SXlzYk41bjR0bkhoUUZ0eXg0SnBreE1OOTlN?= =?utf-8?B?alRzOUhKcEV1eVNqODdYSDNBYmJJcTBKNXlCeERNTEw4RE5OeXFHdkx4c2lO?= =?utf-8?B?b2htb2EzZXBEVFJCLy9Tc3k4bmp0NEFmVVY3MUNUV3c4ZUpCRWJqVUtKalVD?= =?utf-8?B?RnFncUZuRzR6WWNyc0JyWk5hVTBzZkM3c2I3TEJGMVZUbzBBUHdaZWtEeXBV?= =?utf-8?B?VzYzUzF2NEY1TFd1cUFiZXpOYjFJblRJajFITC9iaFZZV0tHVWhsT2w1dVZl?= =?utf-8?B?MmlnOTJPUHVBMmxqdEw1UmpGQXNBT3UrRC9UYzBKbDZQSzNSdncvOXErZmxX?= =?utf-8?B?eDlTSmQxVUk0MWJUaHBHMjcvNzRWSnRoOEowZmtxdTRHZmUxWFRRZ1Zyc21x?= =?utf-8?B?S1BwVEtZUGNUbUtSZmtiV0tLZmhYNjJxVGxwTFpHZStKWW1SNnZIaEdNbXFx?= =?utf-8?B?bWE2THk5KzJJaUxuSWIxQ2JtMGU0TnFQUW9rRU1iNFVDTlE0Q05OVU02TWVK?= =?utf-8?B?MkNWVTl5SFdOYmNuR2VNUnhvY0dVVDhYUS9JU0JxejEzRWNpYTduUTJNb0Q1?= =?utf-8?B?YXhCRTdBeGRLaHlweE05Vm5BR3NxcmNPcVRoa3dkaFdqZmRVZ2U1elpSVWNo?= =?utf-8?B?WndZSmtVWFRoVktVSzFITitXbS83Z3o1QzVLOHhIa1IzNmR6RXZJTDFEbmZ1?= =?utf-8?B?ZXZpV3ZNRWdJdDFhVnpBbVJGZHl1ZTIwVTNMd3N0bVlwM2ZZM2RJQUJWMndP?= =?utf-8?B?MEFpdFNTZFExYkJ4QlNGYXpCQ0ttaEx2cUQ2YXlZSzV3SENwSlNoam9vS3ZE?= =?utf-8?B?emdZVzBDQlc5RW5ZUXBGWis5bjREeUo5MnpEd2lHNVBsL3BYRkI4TmxvZWto?= =?utf-8?B?MHI5VjlUOVpGcEdJR2dIOFMxbzhkSFF4NUx1NnN6ZCtlbFFDWW1pSmQxWjMw?= =?utf-8?B?RHdidml0aW5wOUhPUWljck5CcFZ3QnFRVGVSb0FpelFvbE5SWndOSEdVaEFr?= =?utf-8?B?VXlCREsvUFo2NThxODlwYmZXVHVJNE9qNy9aeXRQNkNMdmdObmZGaVU0SW5V?= =?utf-8?B?K1ZLcnFxTVg3RXBHdGNPVmlZZ2lEMEZkMDRWOFgrZ2dUVlhHSFoweFN0eGV4?= =?utf-8?B?cDhSa2tmVmFWNDdVelZqTCs1TkNLOGhWUmx4Yzc3dGFJR2hrNmd4S3BFZ3li?= =?utf-8?B?ZkE2SjRyaytRcjZlNFlzeE5oSk5jZVcrV0c5ZklodDFzbnd3NmdPNVJPSTZh?= =?utf-8?B?Q0UyNWFvaldUYUNxdU1NbzcyT2NpWlFNQ3h0YkpvZlB5ZkVqWnNwRVRhTmp3?= =?utf-8?B?YWRxWHJQYlhiNk1xc3czM1I5TlpDMmptS0JZSlV5SUllb3Rsb1AwQlVoYXcy?= =?utf-8?B?eUFPekZPcTk5S3MyRFFhanBWRThHcVFFaFY1akNuRHFiYkFubTl5eEVPK0Ir?= =?utf-8?B?bTduaUt1VkhaSmlYRmI4ODZrWVg2U1Bnb1hWcWVHMSt4QjNjVmQ4bVBTWWJm?= =?utf-8?B?MzhmN3MrVHVYYndwVlBtR2E4VjYzMGFxZ3dxNmpNMGxEd0hUNHpQb2I3YUpp?= =?utf-8?B?ejNGbmdoTTQrdUZQWGU4dU5JSG5JUVJxb0xXRFRURVp6Mm1peW1HbTRvYktv?= =?utf-8?B?Nk53SmpjTzhGR1FRUXl0WTUwdFpGQnVoQURFOG9sVlNIVm1uQUcwYXdoc3RJ?= =?utf-8?B?OEdpZ3R0TGhsRHpQTTAzZVVQRnlPUzYxZnZHVGhtRENuSjJKT2tNdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8185b18e-8351-4847-5f3a-08de599dbcd0 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 10:05:14.8365 (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: 6JGAn4PFzh8LcL/Dh9qI7N2YwXRNr7fMKfhaFNDtfYNZj67RZtet+/8TiwnwFJqZgjdm4hB92QErBhHFJBHoMQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB6502 On Mon, Nov 17, 2025 at 03:39:50PM +0100, Jan Beulich wrote: > No IRQ balancing is supposed to be happening on the broadcast IRQs. The > only entity responsible for fiddling with the CPU affinities is > set_channel_irq_affinity(). They shouldn't even be fiddled with when > offlining a CPU: A CPU going down can't at the same time be idle. Some > properties (->arch.cpu_mask in particular) may transiently reference an > offline CPU, but that'll be adjusted as soon as a channel goes into active > use again. Hm, we where likely pointlessly migrating the HPET vector in fixup_irqs() previous to this change, but such movement shouldn't be fatal, just pointless. > Along with adjusting fixup_irqs() (in a more general way, i.e. covering all > vectors which are marked in use globally), also adjust section placement of > used_vectors. > > Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 22 10:06:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 10:06:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210695.1522318 (Exim 4.92) (envelope-from ) id 1viraQ-0007a0-2f; Thu, 22 Jan 2026 10:06:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210695.1522318; Thu, 22 Jan 2026 10:06: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 1viraP-0007Zt-Uw; Thu, 22 Jan 2026 10:06:45 +0000 Received: by outflank-mailman (input) for mailman id 1210695; Thu, 22 Jan 2026 10:06:44 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viraN-0007Zl-G2 for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 10:06:44 +0000 Received: from out28-101.mail.aliyun.com (out28-101.mail.aliyun.com [115.124.28.101]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 08fbd6d5-f77a-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 11:06:38 +0100 (CET) Received: from localhost(mailfrom:houwenlong.hwl@antgroup.com fp:SMTPD_---.gCtgiB8_1769076393 cluster:ay29) by smtp.aliyun-inc.com; Thu, 22 Jan 2026 18:06:33 +0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 08fbd6d5-f77a-11f0-b15e-2bf370ae4941 DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=antgroup.com; s=default; t=1769076395; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=+IzdvJQKHxyyb3zk/1TUPey9oqBuebDgXOHFwXWkTQw=; b=FeFS8h/I4CvU0AfgwAdQHTmGyoeo0sRtDLr2bvnUbJQtmgBFIxTSbRwJFWidAcqUX1xmR4zICSx2LvwlpZ/uCNHd4Om6ZlJ/O93bHEbSa6SeQUgXcWmwViAxIjTkTsKZsT0QotHD9dZ67gdjzAeFyxZnlQkhICGh7OIA/BCUtyM= From: Hou Wenlong To: linux-kernel@vger.kernel.org Cc: Hou Wenlong , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Boris Ostrovsky , Ard Biesheuvel , Thomas Huth , Kiryl Shutsemau , Uros Bizjak , Brian Gerst , xen-devel@lists.xenproject.org Subject: [PATCH] x86/xen: Build identity mapping page tables dynamically for XENPV Date: Thu, 22 Jan 2026 18:06:14 +0800 Message-Id: <453981eae7e8158307f971d1632d5023adbe03c3.1769074722.git.houwenlong.hwl@antgroup.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit After commit 47ffe0578aee ("x86/pvh: Add 64bit relocation page tables"), the PVH entry uses a new set of page tables instead of the preconstructed page tables in head64.S. Since those preconstructed page tables are only used in XENPV now and XENPV does not actually need the preconstructed identity page tables directly, they can be filled in xen_setup_kernel_pagetable(). Therefore, build the identity mapping page table dynamically to remove the preconstructed page tables and make the code cleaner. Signed-off-by: Hou Wenlong --- arch/x86/include/asm/pgtable_64.h | 2 -- arch/x86/kernel/head_64.S | 28 ---------------------------- arch/x86/xen/mmu_pv.c | 9 +++++++++ 3 files changed, 9 insertions(+), 30 deletions(-) diff --git a/arch/x86/include/asm/pgtable_64.h b/arch/x86/include/asm/pgtable_64.h index f06e5d6a2747..ce45882ccd07 100644 --- a/arch/x86/include/asm/pgtable_64.h +++ b/arch/x86/include/asm/pgtable_64.h @@ -19,10 +19,8 @@ extern p4d_t level4_kernel_pgt[512]; extern p4d_t level4_ident_pgt[512]; extern pud_t level3_kernel_pgt[512]; -extern pud_t level3_ident_pgt[512]; extern pmd_t level2_kernel_pgt[512]; extern pmd_t level2_fixmap_pgt[512]; -extern pmd_t level2_ident_pgt[512]; extern pte_t level1_fixmap_pgt[512 * FIXMAP_PMD_NUM]; extern pgd_t init_top_pgt[]; diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S index 21816b48537c..85d4a5094f6b 100644 --- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -616,38 +616,10 @@ SYM_DATA(early_recursion_flag, .long 0) .data -#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH) -SYM_DATA_START_PTI_ALIGNED(init_top_pgt) - .quad level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC - .org init_top_pgt + L4_PAGE_OFFSET*8, 0 - .quad level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC - .org init_top_pgt + L4_START_KERNEL*8, 0 - /* (2^48-(2*1024*1024*1024))/(2^39) = 511 */ - .quad level3_kernel_pgt - __START_KERNEL_map + _PAGE_TABLE_NOENC - .fill PTI_USER_PGD_FILL,8,0 -SYM_DATA_END(init_top_pgt) - -SYM_DATA_START_PAGE_ALIGNED(level3_ident_pgt) - .quad level2_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC - .fill 511, 8, 0 -SYM_DATA_END(level3_ident_pgt) -SYM_DATA_START_PAGE_ALIGNED(level2_ident_pgt) - /* - * Since I easily can, map the first 1G. - * Don't set NX because code runs from these pages. - * - * Note: This sets _PAGE_GLOBAL despite whether - * the CPU supports it or it is enabled. But, - * the CPU should ignore the bit. - */ - PMDS(0, __PAGE_KERNEL_IDENT_LARGE_EXEC, PTRS_PER_PMD) -SYM_DATA_END(level2_ident_pgt) -#else SYM_DATA_START_PTI_ALIGNED(init_top_pgt) .fill 512,8,0 .fill PTI_USER_PGD_FILL,8,0 SYM_DATA_END(init_top_pgt) -#endif SYM_DATA_START_PAGE_ALIGNED(level4_kernel_pgt) .fill 511,8,0 diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c index 9fa00c4a8858..7d77c233002b 100644 --- a/arch/x86/xen/mmu_pv.c +++ b/arch/x86/xen/mmu_pv.c @@ -105,6 +105,9 @@ pte_t xen_make_pte_init(pteval_t pte); static pud_t level3_user_vsyscall[PTRS_PER_PUD] __page_aligned_bss; #endif +static pud_t level3_ident_pgt[PTRS_PER_PUD] __page_aligned_bss; +static pmd_t level2_ident_pgt[PTRS_PER_PMD] __page_aligned_bss; + /* * Protects atomic reservation decrease/increase against concurrent increases. * Also protects non-atomic updates of current_pages and balloon lists. @@ -1773,6 +1776,12 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn) /* Zap identity mapping */ init_top_pgt[0] = __pgd(0); + init_top_pgt[pgd_index(__PAGE_OFFSET_BASE_L4)].pgd = + __pa_symbol(level3_ident_pgt) + _KERNPG_TABLE_NOENC; + init_top_pgt[pgd_index(__START_KERNEL_map)].pgd = + __pa_symbol(level3_kernel_pgt) + _PAGE_TABLE_NOENC; + level3_ident_pgt[0].pud = __pa_symbol(level2_ident_pgt) + _KERNPG_TABLE_NOENC; + /* Pre-constructed entries are in pfn, so convert to mfn */ /* L4[273] -> level3_ident_pgt */ /* L4[511] -> level3_kernel_pgt */ -- 2.31.1 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 10:10:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 10:10:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210705.1522327 (Exim 4.92) (envelope-from ) id 1vireJ-00011S-GV; Thu, 22 Jan 2026 10:10:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210705.1522327; Thu, 22 Jan 2026 10: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 1vireJ-00011L-DG; Thu, 22 Jan 2026 10:10:47 +0000 Received: by outflank-mailman (input) for mailman id 1210705; Thu, 22 Jan 2026 10: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 1vireI-00011F-4M for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 10:10: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 9c6e5bb7-f77a-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 11:10:43 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by BN9PR03MB6123.namprd03.prod.outlook.com (2603:10b6:408:11c::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Thu, 22 Jan 2026 10:10:41 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 10:10:41 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9c6e5bb7-f77a-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fQGABl65XVTxAxWnuhVcS5Niia+PHrwJhni50a1OVqs+esAxwD9uz1frUo4NFnoJ/xtgMEpUozAmOdvS2tRA7rlPaHssSVf9hUDYskYgJ7aJtpAjvbPQG9exeJdpTSlUUl+J/89nZq8S4hfgnctRrn1T98w+V2cp/RXUp8d27iYdteAj9qrCKp1YuSruaAe4RvlROQ9nu9hxiBlrTKK5lubg08BaMs8MQUJ8WS1z/zI5plf9Qh2WL/b7e0hXZIoH5aqjq6Nu3kRYYo68CUREh73MpK356fXdEDCGGAZ2ucytDoe5wkbSpc/VO/FYct0Cc4AtvwEs8CYkTvmY3ctxKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Jxwn6ez9iCqgQgbEK9PUYb4V9q+oTsOG9wl4sbnLa1Q=; b=eV3Q8mqF+bEFwY1KnUp4WyxXHyMN/JmcrbPkASBB18Ql/LKqOfZ0ttza3JA12oKGWqK625ZaXCp7r+mcFsID4Re1dw5rYMNHRaBpoxhF0TfDFG3qHBp9jfm8E1v5N1E5suSHBDCILxefQcHCBHF3okkDxZFzOkoNPJyDByuAeeLyNSChMgCC7a2iHjshFfZABtdTmtE8y6ilxbK3oxMbZ1Po6GW1WJixNI3tw2FSrDVlIQG7t282ILLBqf0/7GJva0Wc1zv9cRL5bD9xiMpNF7UJ1kQvxDZatfw94af7C1+XUGoVfTVVlQnZETiNHkNEAnQdrWJZtzMdMOKdXxxTbg== 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=Jxwn6ez9iCqgQgbEK9PUYb4V9q+oTsOG9wl4sbnLa1Q=; b=CCZ5MWIl/ywtPacKZXH8imLq1KjwCwIDWhv5Xlv9pAtnuqg79DDpCgBdumDUU1diOjev7PEH833MG6gsD57lCVkjMevxKY+ndF6zz4sVDWtAGFE2pB60QtEWX1XApzcohwrFcUKXPHhXMDpfkBD1KjGxioKDIgbkyajZSCEHwnk= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 22 Jan 2026 11:10:38 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH v4 6/8] x86/HPET: simplify "expire" check a little in reprogram_hpet_evt_channel() Message-ID: References: <57f34114-54b7-483d-8ac0-e9fa49df959f@suse.com> <0bc920e2-2e32-4b3d-9ed0-a2c2b34e9591@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: MA4P292CA0001.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:2d::20) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|BN9PR03MB6123:EE_ X-MS-Office365-Filtering-Correlation-Id: de53e53e-d51c-472f-e391-08de599e7f51 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?eDVuMW9zL3BMUFp3M3gzeCtUTUE1cWxZbVUxWGNnVEtBclNjZERBQmlqRFJT?= =?utf-8?B?c2lWdXhuakRYTndPM0c0WlppV2gvTXlTdkI3SXpDZXdrSXZuVHhjYkVEbnRD?= =?utf-8?B?R1c0V014ZUQrL2c4MkorZDBLN255ZGsrQUxxZUdhOWIzbWVpQXRiMUI3U2dH?= =?utf-8?B?TlE2MnJNajBNTDFzZFJVMWg0TTdVN256Z1d2a2phSCtZTVd2SEFLbjFyTmc1?= =?utf-8?B?ZDI5N1E1ZWZGMXhuUFBTaTQrYWM0UXQreHNON3Q1d1BQYnlVMTVXb1ljQVJu?= =?utf-8?B?SU9nRWVEYnVZWG1FemYrdytXNU5KaVAvNWxDTnpvZ1ZuSWNWbWd6QXNCOUNF?= =?utf-8?B?TUtJODdHTGpnSmVITmh0UjJnQmJnUy9XUmZNQmlGRWhXNzVoMStPRWZuaTN2?= =?utf-8?B?M294WE1LejErczVSU2wyUHlrZS8wc3owSGh2VHg4Q2gwSW8vaHQ5b3JrWVR5?= =?utf-8?B?NFd2MjVNVi9tMG5IVUZLYmsyS1dLUkhtSXJuTTVQSHFKOFBHdFVsaEJraWxX?= =?utf-8?B?N01rckVjWC9wTDQwcTI1Vm81V042QUJpZCtXOWlNYm93RThNUFZVbzd1d2JH?= =?utf-8?B?VDR2cjgvT0ZMVFlLRnYyR0J2bUJnRDRQbGVDY2JFN1lycTFWcDJaMEtwSjZG?= =?utf-8?B?Z1RXeUFpc0JKMTFJdk1WTC9vMjFoNnY0bjAzMW5lRFNZSTRIV0RBYXZhT2Zp?= =?utf-8?B?a3I0dWFGMHJEN0MzV2xzRXVVeG1zU05rYVlTYnN2V3d3Z1FXMityTU9DRm1D?= =?utf-8?B?ZkZ0eHRpWVdPU0VmaXBYd0tDYWUzYXBCTDFJR09WYW45ZHNNRmdScm1BNE1E?= =?utf-8?B?ZWNMZ1N5dmRQUDFpRkdPOW9zN24rVlh4ZU5PeGtkMytOOXJJampjbktTVjdz?= =?utf-8?B?eHF6cnpNbEcxbVExMDNmbmNCQ28wZ3hWd0FsVHBkRkpjcytLbzArZ01GZWpM?= =?utf-8?B?Q3ZmRDRXdExqM1pFQXFKbHBvMFdpQ01tb0JRL2FoNU4zalNWTjE4YkFia2tv?= =?utf-8?B?TlFTUHBMd0R2MC90VlZ6cEJZS2RBem54ZEZEU1VKWVQzTkFKTFJlaUxkS2pN?= =?utf-8?B?eXZHR0dZaW5jS0RuVHdpRUU5emoydmkza0loN0tOTmVKY0k0aXlvWkhkdU1u?= =?utf-8?B?TkRqRnZqVGdQRCtZQUdYYlNZL2t0MHNQRytlaG1IaHFOUXBQcStLYmJKbWRV?= =?utf-8?B?bWJwbTVCWVpxc0UybGs1b2h6WE9GRUNncXk3RnRkb3dQd3pVYkNoVGRJRTJ0?= =?utf-8?B?dld6aDdLMjhyVjQrSzNBSTJwN0x6YVNHUm9yQVNxR05pcWtuT1lxdTVUdEZi?= =?utf-8?B?RHZ4MllLM0RJQmlaLytwR0FzN1BsNDJ6bE5jSzRVVjF1WnZnekxrcFgwRWs5?= =?utf-8?B?ajlPT2ltb3ZVak1Cb0FwMEt3cndjdWl1cmtqdmpGUktROC9JSldSaGNLYklh?= =?utf-8?B?ME1LQXpmRFN1dTUvc0ZjSXlSYk4xL2ZRYlJuTTVpNHJ4Q2wvcldubVRkdnc0?= =?utf-8?B?YTlOVnpWWVM0bGo3TmxBTHFSZU83dTRYVWViSXl2djZjMlN0SjQxbytRamk0?= =?utf-8?B?RERBMlNBMzNyQUUxYjR6aG9ic0xIWk9kdDdpcm9DZmxVNEN0M2tzTkU5WlY3?= =?utf-8?B?a0h2ajJQelVCL3JYTmJpcTUrSFNWYVJCZFNWOUpzb0pKT25La2dyTWxhSEx0?= =?utf-8?B?eXhvRm5sSFZqRFlxOXZENlJDaVZkWW1QcEYvYkNMU3hPTklRVERpNmRNQ1do?= =?utf-8?B?MCtXNlBUcHlOREovSUF2QjFpd1FYL2hXTDVOVURkSzdmRmZsYWxoTFAybmpC?= =?utf-8?B?ODd6MFF5aEJMdFJTTHloQmxVc2IzQ0N6OFhHU1F0Q05aK2RFcE41Ui94MklR?= =?utf-8?B?cGhkT0V6Mi9FTEoydFR5MGVhOGdzS2NsdGxOdWFVWGJ2Y0FsbHBmYXdBSmFp?= =?utf-8?B?dnMzc3p5ZUVaQXVyK2N1VUNuUjlJZHpNaU1ORXpNV3AvcjFGR1dpT1dDQVls?= =?utf-8?B?VWdZQ29QYjB2ZXI0c3o2ZmVTWUZjdG8wclZodFRNV3FEcDZqcFZMc010ZXVB?= =?utf-8?B?VEJXb1ppVnBLUGx3WHhOdEQrYnNNL3B4UkJjVWI0RkpCdWVrbXZVTUxjSzQv?= =?utf-8?Q?nX5A=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?N0VTdTdHSlZOUmZ6TWptY0JSUCt1NUpwUHArZE80NW1mbVhLSU9wazdONEFM?= =?utf-8?B?Tzlzb2dWUGp4Q1UyUzJjSTIrc3N6ZmJmWW5tVTI1Sk5DRXVqNkR0VGxuNlJz?= =?utf-8?B?TkF6enRRRFMyeG15MjVlaTM4NlgwUFJ1d0FPOWRGbVJyMXBPekdKSTljZmhG?= =?utf-8?B?aUVFdEpKaHE5L2J4bDduUW9pV1pETFM0MHdTWGNCbEYzbjgrNytTMWF0OGZ0?= =?utf-8?B?YUlYdk1yd0R0eDkvVVpGem5jUkRhelIzaWVaTVZhSDZCeTMyTHBiT0s1Y3F2?= =?utf-8?B?Z1h3dFFiVm4vL2hTT0tPak1vVnZsbnZMNDg4QWp3RElMTW11clNkNkp1cklF?= =?utf-8?B?K3BraFRrUlNPUVRyV3lZUHlESkVXRzRpb1R3eG1UaDRwKzdDSU85NzR5QWFy?= =?utf-8?B?TVlOZWpiNnh1VXVLZmd1ejBCOGVRRXcybno2NEpzN0hqbnM1Z0JOMkJHWnVy?= =?utf-8?B?ZGFyako0UEN0MGZ4YTIrK3lHSGJwcTZLY1hrQjhlUG5hbVgvb1lLMVYzTnN5?= =?utf-8?B?QVIvYk5jQjdkT0NDNWN5ZEs3alBqNGJiaGJkeml6eEpyZUZxSmJOZk5Xd01Y?= =?utf-8?B?UU5iZ21uRHRvWHZSc0tzcWZWbFlMbjJpQUtkUmg0ZXhpNGpDNURyVUtXeGJL?= =?utf-8?B?OGh5VTNITitZTm8xKzVKaGkwR3VYaUJ3SHUxUXhkVUtCc2NoSzRxeEo0UldG?= =?utf-8?B?TmRqVzBFOVZZb0ZBZitKMDNBZWJkbEtZSTR5Q24yZFpiZXpsVzEwd2xhdXhS?= =?utf-8?B?Ynp1LzUvWWlnRGhMTFdxRjJMWnpkRUNIdFRnckovVEhFZm5NN1lVVFZZUVQz?= =?utf-8?B?TngrYTBmb1lGQUlOYlJRSXZkVVlyR1ZMaUJYUlhPSC93NUlWWU1DUWJQWmFr?= =?utf-8?B?MFZzdWJtZTdKWk9SS0ozc2dpWFV5VGwyNlVONmg0NlFCTzFVSGF5dGRYMmxG?= =?utf-8?B?WmNLMmN6bnU1OExBeGsvUXRrOUVHTzQ4WWJFc3NXUVB6UllheXJKNlBqZXM5?= =?utf-8?B?QXpyU3U3Y2lTREFBVS8vbUZ3TlJ3dFdET0tySlNGTDVHbDI0MjFQdU1YRjNw?= =?utf-8?B?ZnU0Nm5QYWQzWW9RaUJqUWVQdjBiNDdxY1F2M3pkQzE5cGZsZ1N4bU5zamlV?= =?utf-8?B?SFNmaWh2amgvbzVMN1dlYmtOdktHclVFQzF4RFVEcUJWN0xQVjNsNUE1SGhx?= =?utf-8?B?ZDhOWDVVV0Nqb05Vb3U4NWJFZmFVYjAxWnBxbHV4bWM3Qm94WTJiVzQ2MEor?= =?utf-8?B?eFVVcDNicDYvR2xobWVZWmp4UTJCdzRpZnpCd2lZcy9waEZyZFpZS202Yy9S?= =?utf-8?B?RE00RC96KzA1MzhIdjVTSHUwQUVLSXNtcEFzT2x0OXdBMHFPVzhiZkVuZXFX?= =?utf-8?B?Rzg1WG9Ibmp3K0I1QmREUXFvRGRkcEV3bkNrWnFxRlpHUTRZR1BFSkRvS1g1?= =?utf-8?B?R1BEL1k1aUJsRGxRWU5Hb1EvMzJ5Q0czeEEydUYyUFRMLzRXYTlpbEdBUGlX?= =?utf-8?B?dzlrNzUySjF4UlZQLzBOVk54MVJucFdlQ2pIekU1bWVQMWdwTm5pbDJ0VVBm?= =?utf-8?B?amJtYVU1UFhtT0tSREhWY3R3Ky9lOUxkQVpWQTMrVGRGTk5zclpBeElDY0xT?= =?utf-8?B?ajk3RGV0TnUzK05ZYzM3enZnSGpUQ2ovQnNIbmc4M0wwSTJibkVncE5GMWQx?= =?utf-8?B?cHVzaXRYNUIxMUlMMTRuSHh3a2x5MnhLYkVGSHc4QmVDcllLdXVTUS9DWWVI?= =?utf-8?B?dG8xdmFiTnFPTEliekxnYUovTjBlL1ZhbjdrbEMxeFRnQ0RteTl2WmRvdE1H?= =?utf-8?B?Y293cURtUUhGa2hDc3ZVUlJSWmgwdzdDOVgvNUVSVFhKZm9VdUF3bndFTVVG?= =?utf-8?B?R1BlaS83QXZvRHRvS2NwbVRVak9hNE9YejB3OUdTZTd0TTRMOWZqb05vVHRz?= =?utf-8?B?aFlDb1Q4RldYdVlFbTdRTkt3dEltRjhaTW51dCtGMUFLNU1NYitURTdQOGt3?= =?utf-8?B?UERISi9UY3ZvTitRRkl0aEtnWUtjRHEzTWZaeHpwQ1FtVlNtdTNKQ2JhNnN6?= =?utf-8?B?QUVYWkU1Uy84OEdNdkkwcFg0RG0yOFhaMnk3R1E5ZkRpM1hqMzFzckg5TUky?= =?utf-8?B?c2tFSFp4VmNlcEttamVuRnhxVEZwWkJ5a2N3ck9SUTFRc1lsWWUxWW9oWk5V?= =?utf-8?B?YXgzclkzZjNNVThoSVpZdU85ZHBRWXlyKzRkZnY0VkxDcXQwdy9NQzNyN3hT?= =?utf-8?B?WVZWeGxOSjY1clhlS3V3WFdiSU1LT3VSaFpHWGJGQUNGZ1FuRmR0NSs3ckhX?= =?utf-8?B?c1hmMmM0UkVKUjMvN3VkeEFzRVFJSHJ3OWx4QVBCZ0hPcS93Rkw4Zz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: de53e53e-d51c-472f-e391-08de599e7f51 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 10:10:41.0942 (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: +msJ9dB8gi2w8WOL+0Mue5VTeBgB0Wys8Wfu8POIsOEZ95erzqysHKav16bssAXqKY5x6o0uP6YcZ5XS6ts/Ow== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR03MB6123 On Thu, Jan 22, 2026 at 10:28:51AM +0100, Jan Beulich wrote: > On 22.01.2026 10:18, Roger Pau Monné wrote: > > On Mon, Nov 17, 2025 at 03:39:30PM +0100, Jan Beulich wrote: > >> When this was added, the log message was updated correctly, but the zero > >> case was needlessly checked separately: hpet_broadcast_enter() had a zero > >> check added at the same time, while handle_hpet_broadcast() can't possibly > >> pass 0 here anyway. > >> > >> Fixes: 7145897cfb81 ("cpuidle: Fix for timer_deadline==0 case") > >> Signed-off-by: Jan Beulich > > > > Acked-by: Roger Pau Monné > > Thanks. > > > Similar to the previous commit, I wonder whether it would make sense > > to add an ASSERT_UNREACHABLE() if that error path is not reachable > > given the logic in the callers. > > That would mean > > if ( unlikely(expire < 0) ) > { > printk(KERN_DEBUG "reprogram: expire <= 0\n"); > return -ETIME; > } > > if ( unlikely(expire == 0) ) > { > ASSERT_UNREACHABLE(); > return -ETIME; > } > > which I fear I don't like (for going too far). Even > > if ( unlikely(expire <= 0) ) > { > printk(KERN_DEBUG "reprogram: expire <= 0\n"); > ASSERT(expire); > return -ETIME; > } > > I'd be uncertain about, as that needlessly gives 0 a meaning that isn't > required anymore in this function. Hm, OK, I was under the impression that both < 0 and 0 should never be passed by the callers. If expire == 0 is a possible input then I don't think the ASSERT() is that helpful. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 22 10:16:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 10:16:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210719.1522338 (Exim 4.92) (envelope-from ) id 1virjH-0001e3-8Q; Thu, 22 Jan 2026 10:15:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210719.1522338; Thu, 22 Jan 2026 10:15:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1virjH-0001dw-4s; Thu, 22 Jan 2026 10:15:55 +0000 Received: by outflank-mailman (input) for mailman id 1210719; Thu, 22 Jan 2026 10:15:54 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1virjG-0001dq-2f for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 10:15:54 +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 54b6e558-f77b-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 11:15:52 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-4359a316d89so595679f8f.0 for ; Thu, 22 Jan 2026 02:15:52 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43569921f6esm43318391f8f.4.2026.01.22.02.15.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 02:15:51 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 54b6e558-f77b-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769076952; x=1769681752; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=gtI3LJk8eA89K0J+wFA71yh6MR8g8c0uIDVzZE+j6NY=; b=QikTSDvo5Qo7VfuELTaTcOq3e2dXhLcbMAUyY2YBeFYVN9rwOYFd4t/bGW13uH7cO/ tokJS/cx3hNdJBooqg+a5Jd7P07nmw3ODvCuv1ZU3o/6tnjfTQiJBT7lvHPgJreotpNz rIrn8DZHR8uuWqOMc1MURTE+byiDtp9x+H+tkUrxzA2FSC9e3+hdl3HsrXoNGYhm7lfH i7HAH3QjLWKEEH5PIM1fz+g+N3n60UXUoDiToCpENM8EzhYJTaNO6A3NQFXBH9V2ik6E 5MfTcrkITUd3SS7VXyBBJpdLWPmkBY84g77RFydQ4m+2qvS2roW8tmuTMSjuyz/KYrhp Ra6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769076952; x=1769681752; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gtI3LJk8eA89K0J+wFA71yh6MR8g8c0uIDVzZE+j6NY=; b=fyuBQbMatCUctw4nUZTxa/AIRv76dpExNo2Jst+Dg5EqwkbX7aWtfitQS3GVjnPfxx TPUTzhMnyE/RDhRywI5rFDubUv2b4ulinaj6HbCOO2TgmS7E8xPRsRDPf2Acm2HLdB3k ayJhxZ2P91pQAvrr5YNtfpUu7dsnUEAVmTfK6b9znYAb7aHi0B1txyYCNpBvw09L+bBS 9gSJS7I49jxjD+SjYBrFzi1+8/F+7z5tTKN+GQCrDCrcdl/VJ/VDmxpZ2FMsknPJumns HOcGuol0QpbX4bhj8XBgVo8XiiW1HQAlp441N6uLbP8HR0uIzYWmfVAQRoJQZDslr5tH 1lNA== X-Gm-Message-State: AOJu0YxH3/ffQSsLMq29O9BDxvvLIzwctT7xoXJA4k5+n95EwctIZesl I9IYCbak1QNEUZJdULFTIl4Q+G+FMmcuIztKF/KBroEVYEyofjUsjrB4qpN0H7LqRg== X-Gm-Gg: AZuq6aL5VfoCnniawAWC1BHwA3YJs7LqgPwHAIos9X7Ahq9yxQlzEST+khNbeOuvKP4 BKptNNkd3LpVx9ikUL0QCp1UKT/n2BqpVRGV9HCFHzWBvxMvrAzzbs790V6QpTQzzcTxN0lhIGq 19AdlBZiEoJonDWy3NunNx/wjxeAiVIph3tRLpxMTBwc55Oe0JyRSsm3gNM3l0Kl92PA1ULzTD7 XfwYI7czevOPe3D0qtYxZl9os8gJ6Qho6Z9nxNxkl2q66zODzsFjrYJ21CyLn0S4MzmyyJXl21b QvKkn3uYCeXv3lwT+KSa9cOWgsZ5wGwv6pXq0QYKjJ9u62jmqd4IYuEIb+Ar6UVLZsPYgxSS/SN XlvU6lcqMARk4/L9RofrjKT0CGbhJjVyhQ99Zk53feuetQ3lcjm7CvbYzqz2kAWYWaSuwp84Q7P 5IsyWsxaVw3MhadtkeoC2qvKFmYGgb+czbB3yQR3Nm7FA68UKQdPJpegDaQgy4UDT2dQDNKkaI4 Zltri0lk6RN9Q== X-Received: by 2002:a05:6000:1a8f:b0:435:9ea8:8b83 with SMTP id ffacd0b85a97d-4359ea8944dmr9040247f8f.19.1769076951832; Thu, 22 Jan 2026 02:15:51 -0800 (PST) Message-ID: <73daede9-d7ac-44bf-a018-b76d39b3eeb4@suse.com> Date: Thu, 22 Jan 2026 11:15:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 6/8] x86/HPET: simplify "expire" check a little in reprogram_hpet_evt_channel() To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper References: <57f34114-54b7-483d-8ac0-e9fa49df959f@suse.com> <0bc920e2-2e32-4b3d-9ed0-a2c2b34e9591@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 22.01.2026 11:10, Roger Pau Monné wrote: > On Thu, Jan 22, 2026 at 10:28:51AM +0100, Jan Beulich wrote: >> On 22.01.2026 10:18, Roger Pau Monné wrote: >>> On Mon, Nov 17, 2025 at 03:39:30PM +0100, Jan Beulich wrote: >>>> When this was added, the log message was updated correctly, but the zero >>>> case was needlessly checked separately: hpet_broadcast_enter() had a zero >>>> check added at the same time, while handle_hpet_broadcast() can't possibly >>>> pass 0 here anyway. >>>> >>>> Fixes: 7145897cfb81 ("cpuidle: Fix for timer_deadline==0 case") >>>> Signed-off-by: Jan Beulich >>> >>> Acked-by: Roger Pau Monné >> >> Thanks. >> >>> Similar to the previous commit, I wonder whether it would make sense >>> to add an ASSERT_UNREACHABLE() if that error path is not reachable >>> given the logic in the callers. >> >> That would mean >> >> if ( unlikely(expire < 0) ) >> { >> printk(KERN_DEBUG "reprogram: expire <= 0\n"); >> return -ETIME; >> } >> >> if ( unlikely(expire == 0) ) >> { >> ASSERT_UNREACHABLE(); >> return -ETIME; >> } >> >> which I fear I don't like (for going too far). Even >> >> if ( unlikely(expire <= 0) ) >> { >> printk(KERN_DEBUG "reprogram: expire <= 0\n"); >> ASSERT(expire); >> return -ETIME; >> } >> >> I'd be uncertain about, as that needlessly gives 0 a meaning that isn't >> required anymore in this function. > > Hm, OK, I was under the impression that both < 0 and 0 should never be > passed by the callers. If expire == 0 is a possible input then I > don't think the ASSERT() is that helpful. Oh, so you were after if ( unlikely(expire <= 0) ) { printk(KERN_DEBUG "reprogram: expire <= 0\n"); ASSERT_UNREACHABLE(); return -ETIME; } (perhaps even with the printk() dropped)? That I could buy off on, as NOW() is expected to only ever return valid (positive) s_time_t values. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 10:24:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 10:24:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210731.1522348 (Exim 4.92) (envelope-from ) id 1virr5-0003aM-12; Thu, 22 Jan 2026 10:23:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210731.1522348; Thu, 22 Jan 2026 10:23: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 1virr4-0003aF-UW; Thu, 22 Jan 2026 10:23:58 +0000 Received: by outflank-mailman (input) for mailman id 1210731; Thu, 22 Jan 2026 10: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 1virr3-0003Zt-OW for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 10:23:57 +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 729c38e4-f77c-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 11:23:53 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DM6PR03MB5177.namprd03.prod.outlook.com (2603:10b6:5:22b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.11; Thu, 22 Jan 2026 10:23:48 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 10:23: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: 729c38e4-f77c-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nmFf3n8OHQgdnRbrp6JU1Y2TCe5/TS2YyN1rmoYzhrPo7O7EynBkLmmOCenJZvjKGHewVmJg6YWD1ZHIHFLGWL+e5pLsuIgFIy5iNXwOpsOuzVMMyJr1Li4ApMT86aQ88U4m8ECMzn2tlBq7Sn57AidaSBeQELqM/Yn7w+8pNyMxlXS4CTzsHaenzTZTNiLgWhoe7NaMckKTwsU5RmJIy+JyPJR3R6iZfxjcmqyfRAcr5GHgqvZQxYkJUa/+uDHCUVgWDIK6QP1/EMl/YKIr5gujgQYWtyI4hMu8IHYJraGhqawTVZnJsNqvKcUB7zPvYac4cDW4F3C1BNsX8I2XNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XVF/8qbQOIejmy75Xasc0uICoy3EWmNEGvLlAINjnE4=; b=w3HHfhhWuIgRP4V5Zcj5eIykvNhqK23eFfbFDjcvzrRjZPiolRqdch7wJLPQ8iu1SXKrNYFiOfwlYHN5k5TK7d7Z7lFxPCoHUpbPAGlXht1uZOwjsGAMu83aNfs51FaljotXA8Aqr0vTKLl3bCgljSy6SOyD1U/xqre8nK00t5t6koVBin9H0Uz8vottJ2zpd0/DnhIwt2ZYemjOw1XeN45w/X9O27ySAFiDPnCPuBkbiohpETVsbOtSAVtUruIRrUlVlRA0el45/WIUx6gqTVfe8cUZpV1keddvljioEYw9az9jh/TUlnOsnfU2YD2zYXVjEBnfYQ66fZG03dnM1w== 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=XVF/8qbQOIejmy75Xasc0uICoy3EWmNEGvLlAINjnE4=; b=f1/+q7B0geYH3GCsDEyfCMH/X6z4i07tzdHW/I6K4hjUX15UqOl85pFdsq6PRf6hDzgP9c6NlknaUNVhJ/JfEfdbf18xTOqk9YdjcZr87meoO03+kS1dpOjpjklLcbgguJtGC48QW98gI6yEjhwXy1Wer6aneijzd91hoSU3ws4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 22 Jan 2026 11:23:43 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH v4 8/8] x86/HPET: don't arbitrarily cap delta in reprogram_hpet_evt_channel() Message-ID: References: <57f34114-54b7-483d-8ac0-e9fa49df959f@suse.com> <37cdba83-9bf8-493a-9a7b-5ec11c32159a@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <37cdba83-9bf8-493a-9a7b-5ec11c32159a@suse.com> X-ClientProxiedBy: PR3P193CA0050.EURP193.PROD.OUTLOOK.COM (2603:10a6:102:51::25) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DM6PR03MB5177:EE_ X-MS-Office365-Filtering-Correlation-Id: 205086a2-d452-405e-13a1-08de59a05443 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?eTJNY1JSM2JjTk9rMWNtMU9xVDdrQlZtNFVIR3c4NUdlM014OGVXTktuVzRB?= =?utf-8?B?WHZFVVMxeG9mVlN2RlRmUWFxSHdTcGcrVFM2U0VZeEZ3S3FuTm1PaTVocFd0?= =?utf-8?B?OGRQdDBZNk80SWp2Tlk0djE4amw4U2FHTXpvZXQ4MDRDMEx3UU80RnkrZFlG?= =?utf-8?B?VnQvSi8zcm11cnZQK2JQUys0UUVLeTdLY3JSRlR4TDB4STJxbTRoZEpCQ0ZE?= =?utf-8?B?ajN1YVE5SXNLUVRSbFFhbFJ6d253RGk3THdxcEpDRmc4UzB2Mm9pcEJCNGgr?= =?utf-8?B?TG5EdTZTZVpveG0xQksvZWlZK3JkSlRWbHdmRHlEcWRWazY1K080Z2RkYXZ6?= =?utf-8?B?UnBuUnNnalVGRmxrMFFRSmJFSHZDZy9HWEhhcDhhd2xielIwbGxxSnYxL3k4?= =?utf-8?B?ZjNjd0JUdGxvelhWbjJKZG9SWEo5cjV0bFhxSWtHVmNPbDNCcWtDbnNRWjVn?= =?utf-8?B?aWNIQVBLWFdPeG9PU3prSHc1R0JTV1lSSFNEUGUxR01WRnlXaEdYcEJkMTM2?= =?utf-8?B?M1llQUcxTjRPMXUyWjJSMXp3QTR2OG1mM055aFJJN0gvOUFySWxlMldjU0VB?= =?utf-8?B?b1pGK09tUGN0bFIxa3lleGR5WU5KTU44NVdrSjc2b09kZlZBdy9rZWRFV29W?= =?utf-8?B?dkxicmZZUDFmekw1Z1FKR1pNRlBuUFUvSU9OSGw1cnNtU1JjM0w2alFrVHFm?= =?utf-8?B?dE90K2Z5bUwxdDVScVF3NG95N0h5TEZsWVU0dFN4UEpZcXJIRnJ5YVlHQ1U1?= =?utf-8?B?OHNERXJHQzZnQVI2RDkwSEZVbFh3aUVpTTFhR3I5WDR3NTljcnFPcGFmbUpE?= =?utf-8?B?RUtVYmUyanVUWGJBdG5QZjg0RGhPSTZoTmhJWTRCYkducHZwYm80YjZQSVZ5?= =?utf-8?B?RmtSdWNUK0xLc2J2bzRWcm1Ocmt5RFBXVXpMZU9CelhhcUVuNU1RcUF2Qkcy?= =?utf-8?B?TDRjTVBRNmNoQ3A4VDk2OE5RQWdKeHNPSDhGTitoNzJzZ3AxUUZ1aUdERnB5?= =?utf-8?B?MG5lbXdLdGpKWFZjUHdqTDJmdXUzRmlNSU5NZlc3OXpVQ3BiS0t6cGRGcUhw?= =?utf-8?B?ZlZJbDB4VnUxUW1jM3l4aTI5MFhaOTBMZ2lva0Z3S0hmRVozTjNSMlR2MnU0?= =?utf-8?B?bW9DUXdPa3c5MElPWXd5NW0zTzVKc2xaZUZZeUJkUDF4bkExNWNsVFpFQVJV?= =?utf-8?B?aEljUWZYNSt2VXIxd0lES2o2UkVqemwrN0Rub1JpZmc2TDBxck8wQ0dlclVF?= =?utf-8?B?OGNBYmc3bDRmbU1HYjQwMXViVjk4aVB5ckNkL1dXblF5bzhUUG5mZGNtY1VB?= =?utf-8?B?NkNkZ3FBektHb09kR3BwSWxxZFZBb2hoUExzU1hkZHlpRGJkQzI0cFQzY3ZB?= =?utf-8?B?eW10T2pYaDRjaGkzTDBOMVUwbkhrREZ2K3Z0Slk5elFTOEsvUnlBbytIL2VN?= =?utf-8?B?MEhqWkZjZVRUVmFpZkpQdS9pOFRMcDJ2SFFncVAvRU9QeTN2SnM1RXhqWmNM?= =?utf-8?B?eks0bVVweGFHVjlvcWlrTElvOHEwUlFxdXBDMlJDQnUrUU02ZmV4RXlLOXVT?= =?utf-8?B?V0VhM0N3SHltSGh4cm1xdTU2b1ZNK3hMeHFscStBZGhXdTduYmNYc3hrNWYw?= =?utf-8?B?Tms3bkExMmY5RENOQ3JKNDQ4eDVNU3hmUWNkb3M2RW5OSVJReERkSzlZWnNn?= =?utf-8?B?ZnN4d1hvdS94dG5SVklWcGh2REh1TWdWTDVLN1FhOTVRV0pQUFNWZ0FoQTV6?= =?utf-8?B?VlZuNTIvT01OUGkra0pyUU0wYzd3ZUtqSjYrN1RmY1ZwQXNSby96VVgxMFEz?= =?utf-8?B?Q1NrdXdMWFJMeWlxbGlmZzJZd21UVk9ZSWRDL0NZRXpDVzFQSHdPamcrUnQr?= =?utf-8?B?VHZmYzlrTmUveWkvTlc2alN4RGtaNHdOTGVpN0Y1VnhFTVZtMnFHang2d1kv?= =?utf-8?B?akZHUjhHSjdNQk9HSlNJLzFPdklqbE9jRmhjQ2VSSEpPM29ycGU1QXhIWjVR?= =?utf-8?B?cXlvMXVaZEJQMWU4akNsUFRsbS9BRzdZUkhaeHJycys2K0kvdG14Uk0zOFdE?= =?utf-8?B?YThrVVpXRmE5aFYxNWRkVGxvMW9SazBkdjVIanlDMTUxTU94b3hkdTJBTXRI?= =?utf-8?Q?qTT8=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TmFtcEtJMERDSzY2MW9ZUE11YU16eUhGSXpkUkR5eEd2b3NwY2JFWGYwMStD?= =?utf-8?B?UmltVm5BdUFmNFFtRTEyVGs2OWdHOEREODJPaCt2U2k5eTRPVDQ0TUU3cnFM?= =?utf-8?B?V1pNZUNKU1BOWEUwbnBaQXZvVzM2ekJ1SVdyaG4wNlc0RERXQVhYTHkxa09q?= =?utf-8?B?V2RRd0J6dzh3NWlBRzFWTEpLUEEwSGh2NjNFNjI2VDBJRUJsQWFVZ1EvOURF?= =?utf-8?B?U2VYWkZnck5rV3hteHlHb0RQcys1c3RUUk82Q2dTckZJT2kvUWFrUC8vL1A5?= =?utf-8?B?ZHNQblhkcTBURWxMb1VId0dwbTVCUnl1bWEreDRkU2FzZFpNTTk2Ukl3dHBL?= =?utf-8?B?TnloSFNjM1pycUF0MFZ0TC9VcEFza2J2K0JmM2FTYTlRZHJPMGxHQzZDcHdy?= =?utf-8?B?YUdNTENuMk9OMGF0ZUltL0FzSnJvSUNSODZSWWxVbFhLTm9yMzBISE9Kb0Nk?= =?utf-8?B?TlR3WkxCMEp1TWZnZTdZUHA3UkUvTDdJcHFMRGZDQkkrZWx3ZHZkUnB5VVpU?= =?utf-8?B?Qm4zSVFsR1ppZTZwc3hEcHY5SU4vQSs2TE9sMHFsQUJOdnNVTFlZR3l3V2c5?= =?utf-8?B?cnpIZXkvcHVqNmx4V0hRLzk1aFcrQlgrR2ZOekc1R3hWZUVYVlpTWlJnb2JT?= =?utf-8?B?SU8zckJMZDMvc2tmOURkb3h6S2Q4Nk9sdTZTQ2pkTk4reHZjVXVGeW9vRlk4?= =?utf-8?B?UVZhWUJsQzhMekF1c0FEdmZkUEJZcTNhVG9QdGlzL1J6S214ZmxBM2lSTkR5?= =?utf-8?B?RVhCVHpkamlvNmFxOVE0YThZRjBia2VYSGZETDlsdHZPRllqK0s4VGdMenhC?= =?utf-8?B?aFBtUWhtc0d2Wm0wRHhhWDlhOUo3Smw2S1hEQ25LWmZkSmhWaXNTUmNRRjRU?= =?utf-8?B?WjZXejRUNGF0RHgyK3BpblF1R0IrNXc0NVdsOXh0dnRZZWU2dFQvbkVZaERW?= =?utf-8?B?Z05kMUFmUDRnVDYzdGgrTUkvZlFNQU9ROEk0Q2J0c0tqREcyVTRhditXem00?= =?utf-8?B?OEJpdjRPRGlZQzJBdE5HZFQ1V0kvNTZRWjdpM2JYbHl6U05JYkcrYW40TDNP?= =?utf-8?B?dllBTHhjMy80bkkvSzNFSzFzNlZ0ODl4UFZQY0t0dThyTnZPcHJEWTlJZE8v?= =?utf-8?B?Znh2MGNwcWhYZjAvQ3FRdnRBZGZmRk1yQU9PR0hiR2NhVytESVhGTUVWZE1a?= =?utf-8?B?SjRNZ0xBaWtRS0Q3M3NiQlpkQmxlb0t3ZDRDbllRRkJNQW15MnQ2UDFHeG05?= =?utf-8?B?REd6cjBxVC9CTURKK2ovdmpoRnBpczBzWGNEMzJuZkNQTUF4bWkyUlBDdkxj?= =?utf-8?B?TkNBR1ozRkxKZCszUU0vZVJmbkFaS1g5alFGYmFFc0FYZnZTemlXMlN4UXhl?= =?utf-8?B?bWVKc0xoelcrTkdiZkVTbE02M012M1RHaXJvakNnQzJzS21hbkVlLzlKelZz?= =?utf-8?B?bFR1aEhnUlgvbSszL2FPS2dsMjhnWmFMamsxRnJqR2p6aGlUck1EUnBGdG1N?= =?utf-8?B?S0dySTlkYkxNY2FDN1FFZlNxQ09ZcjBoTFRLWG9BM2Y4TmJYeWlReWhiYkN0?= =?utf-8?B?Um1KU0FLVkgvNCtzNlEvU0o4cUxqeXlGSVd1OHdPc3B6TEpldElHYkJaNHd4?= =?utf-8?B?bGdRblk1TVpERUk1RFp0c0daUGZRNG5PTlA1WVd2bkhSL3IrdDVmZ1RjMGRt?= =?utf-8?B?NDdOaVk1LzVpNlVGam00d2UyVHo1d0FDbEFad2oyMkVSOVRLQmJoSWZTV0FI?= =?utf-8?B?WHluRFlRN3JTV3dRVXZhZWxVNjNRRHB5eWw1RTUyeEh5aGNXUmFtYjhNdG44?= =?utf-8?B?M2l1azk0UmVqaXZpdkxWNlBMT3FrMGlpc0pueGt0L1JxYjBFNUw1TTNwVk5o?= =?utf-8?B?Qi9JVktnVGRFOS96bWxWUjRzV0lPVkVyY1lKR29mMnRWWmJUdkFKMDJOa2R6?= =?utf-8?B?VEhEMm0rbFFHeVJLRGIzSGsvcjU4NTJGYTBsYjRHOTRqRFhzbVVxb2VWMkhE?= =?utf-8?B?blltT2daRTZjSlp0ZExCdHNsZ2VHQkJNUlR2ckpyRFRFbWcybUxLdmR1d0hm?= =?utf-8?B?UGJYSHg0MzBaUkFkdkN1QkpFcHJvU0xlZ2hBaUZ0ZTNkakVSMUM1RXhtNHFi?= =?utf-8?B?K1R4NlV4RWF6U2ZQbUJQTnB1NWdhdG5SNFdRanRBdG1nb25lamR0eUNNclNR?= =?utf-8?B?TllYTjd2Wko2Q1ZPZDBOY2VmQ0wzRVE1K3FwTWhzUWZtbHI3QXFvSGQxbVdD?= =?utf-8?B?VUhBV3RvRGtJeWIzRUhSS0pLWWFEbTJMU0gxMFVRODFBd1V6cVlpaGFmSDVZ?= =?utf-8?B?TVgwbkN0R2dLcmpQWXhaSFdhR3lHV3dQbkNDQ1NqMUlWSStHSGtSZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 205086a2-d452-405e-13a1-08de59a05443 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 10:23:47.9197 (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: qov2ZTe39s1dPu34vLwUecuBYaEqCnab2ql651WRAjaLpuggxBOerRZq2ff6N6f7VJlLsWj50AdWTpXOcvF0+Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR03MB5177 On Mon, Nov 17, 2025 at 03:40:08PM +0100, Jan Beulich wrote: > There's no reason to set an arbitrary upper bound of 10 seconds. We can > simply set the comparator such that it'll take a whole cycle through all > 32-bit values until the next interrupt would be raised. (For an extremely > fast-running HPET [400 MHz and up] 10 seconds would also be too long.) > > Signed-off-by: Jan Beulich > --- > v4: New. > > --- a/xen/arch/x86/hpet.c > +++ b/xen/arch/x86/hpet.c > @@ -23,7 +23,6 @@ > #include > #include > > -#define MAX_DELTA_NS MILLISECS(10*1000) > #define MIN_DELTA_NS MICROSECS(20) > > #define HPET_EVT_USED_BIT 0 > @@ -162,10 +161,15 @@ static int reprogram_hpet_evt_channel( > > ch->next_event = expire; > > - delta = min_t(int64_t, delta, MAX_DELTA_NS); > delta = max_t(int64_t, delta, MIN_DELTA_NS); > delta = ns2ticks(delta, ch->shift, ch->mult); > > + if ( delta > UINT32_MAX ) > + { > + hpet_write32(hpet_read32(HPET_COUNTER), HPET_Tn_CMP(ch->idx)); Should Xen disable interrupts around this call to avoid unexpected latency between the counter read and the comparator write? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 22 10:32:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 10:32:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210741.1522358 (Exim 4.92) (envelope-from ) id 1viryo-0005Ry-Ok; Thu, 22 Jan 2026 10:31:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210741.1522358; Thu, 22 Jan 2026 10:31:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viryo-0005Rr-Kw; Thu, 22 Jan 2026 10:31:58 +0000 Received: by outflank-mailman (input) for mailman id 1210741; Thu, 22 Jan 2026 10:31:57 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viryn-0005Rl-S5 for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 10:31:57 +0000 Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [2a00:1450:4864:20::32b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 92752df8-f77d-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 11:31:55 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-47d59da3d81so12720875e9.0 for ; Thu, 22 Jan 2026 02:31:55 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48046fb7eaasm59070595e9.0.2026.01.22.02.31.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 02:31:54 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 92752df8-f77d-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769077914; x=1769682714; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=dtaKnWYlt8TU2qsWm/+dzT/V8/xGYzGeC9aAYJAeiwY=; b=e6EzjLlfFHnW7ow2CgtI8XVsgJcrXyuA3Tg/vWqMuGmx//06qqMHdKg6ePzLS/003T KJdR1xHxDhnnxSz/kKKIJ2iU3MnIqHtIbjAXZJu7afT0+7UuhOGSD6cVFXqJoP79rT4/ I6xJb4qj81rQG+rLnllwbl2Lr/vDn5C65A3lYqJQmeDoze0xgNfsuGDNBgbsZlz0Bppp DQkBQ4BVY0w93S2rDBS8u3iMBWnZ+i4eS23Us22zaMYpHZcdZubO/5+tKJioHc8I/xr/ 8Phhta6LQ6gC+zOqM4Uxjxg/OREH0doA9qC2+Ey1aST0pOOZ5Sga8UeMbODWEWOLDcqc ZZBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769077914; x=1769682714; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=dtaKnWYlt8TU2qsWm/+dzT/V8/xGYzGeC9aAYJAeiwY=; b=AOKjCPi5vsir5dECvThFBJOqDKm45PCW3zmhC3johmUYwis1rQ7453GPOJZlUuwbUu EOMWd4EmojhzYzmjffhqT5K+zZdi+gYbxLfRIzJqsflTzIbxRyvUdd2re6d5CJC1FvkI krSpHuSdkbC0EQVEafS4wNQMlox6dHh8MGkwaZm+diu/agjRkq0JFfxnyfVJ+mESIFFZ JZiGIfikiM00iG84kPVBSqPd1yAi7AMCcXNSaEMkegncjSpVI+VOAhWytPIfLQ0qVyUt 4RLx1/AygQfBpr3lDfj61RBVXZCORlNVw0FWe0gQNsbZ4YQ5rhNS+5hxDldneWQcktAb 8OaQ== X-Gm-Message-State: AOJu0YyPUQeW5ZslkXFF24bTHLTNRkMqf9gnk62GZbqRhdDRZFkPp+9v PBrp6czbdCqcOpQiLwPrjMct7kUFOBYXCoFwUgC9uBb2uVzTf2K3uUGzqmpYQmBcng== X-Gm-Gg: AZuq6aJblEm+h6A8p5N8Nxs580j1J6yabyeG1YZPmAuZFhBBTnlIxWFX8ucf+jbAICe GAdigDdRrGQpo1hFqUmZmZ58UkxhQWcUzZWQChlVLLIMVgVdbfVfPa1dnuJAoDD5s0zGgwQNZuA B0+2aGqLQ/xfh9vIUCW8Hk3iq5x/VFwgBlNuDZtfBIppQw/mQMrreAlAWzf8NznBQidmFgjEPiY fF6LP6O3/fSQzpUf2cvbQU0YpbepyNgB3Xl0bSbyXtjWimbmf/4HBGSYlrZyXHPrB6f5ZQ0+gGl DwwS1BegcfxL7xa686515EH+9Cd8zW6EVppHBPkvG1xx7d4m0bDjlXupzHwka8P6soIXiTisH/8 GYi+2NubyAoiyk/yKhimmT6EVdkfT3o3s2+njyUUGAUZ/Tj7o4ojLbZpC3JYYnwyjd04p+o2qU9 r2Cg7wsqoVphGOq1Wlcj7lFLcZrr6W//JcQq1b9sio7rmnyKKzZBcXsTW/2nBeENZRoVAxYmm60 Rc= X-Received: by 2002:a05:600c:1906:b0:479:13e9:3d64 with SMTP id 5b1f17b1804b1-4804709ab9cmr42986685e9.15.1769077914398; Thu, 22 Jan 2026 02:31:54 -0800 (PST) Message-ID: Date: Thu, 22 Jan 2026 11:31:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 3/8] x86/HPET: move legacy tick IRQ count adjustment To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper References: <57f34114-54b7-483d-8ac0-e9fa49df959f@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 22.01.2026 09:50, Roger Pau Monné wrote: > On Mon, Nov 17, 2025 at 03:37:45PM +0100, Jan Beulich wrote: >> If already we play with the IRQ count, we should do so only if we actually >> "consume" the interrupt; normal timer IRQs should not have any adjustment >> done. >> >> Fixes: 353533232730 ("cpuidle: fix the menu governor to enhance IO performance") >> Signed-off-by: Jan Beulich >> --- >> _Why_ we do these adjustments (also elsewhere) I don't really know. > > I think I have an idea of what's going on here. This accounting is > used by the idle governor to decide when to go idle. On Linux (where > the code is imported from) the governor took into account the inflight > IO request state. However that's not available to Xen and instead > they decided to mimic the tracking of the IO activity by counting > interrupts. I bet then realized the timer interrupt would "skew" > those results and make it look like there's IO activity when the > system is otherwise mostly idle. Hmm, yes, that sounds pretty plausible. Except for one aspect: Why would it be I/O that the governor would care about? It wants to judge by the system being busy, and timer interrupts generally are an indication of busyness. Just not broadcast ones. Hence ... >> --- a/xen/arch/x86/hpet.c >> +++ b/xen/arch/x86/hpet.c >> @@ -808,13 +808,13 @@ int hpet_broadcast_is_available(void) >> >> int hpet_legacy_irq_tick(void) >> { >> - this_cpu(irq_count)--; > > I think you want to pull this decrease into timer_interrupt() itself, > so it does the decrease unconditionally of whether the interrupt is a > legacy HPET one or from the PIT? ... I think moving to timer_interrupt() would actually be wrong. > By gating the decrease on the interrupt having been originated from > the HPET you completely avoid the decrease in the PIT case AFAICT. > >> - >> if ( !hpet_events || >> (hpet_events->flags & (HPET_EVT_DISABLE|HPET_EVT_LEGACY)) != >> HPET_EVT_LEGACY ) >> return 0; >> >> + this_cpu(irq_count)--; > > Also in hpet_interrupt_handler() we might consider only doing the > decrease after we ensure it's not a spurious interrupt? We don't seem > to decrease irq_count for spurious interrupts elsewhere. Even a spurious interrupt is only an idle management auxiliary one (i.e. really an artifact thereof). It doesn't hint at the system being busy. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 10:35:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 10:35:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210755.1522368 (Exim 4.92) (envelope-from ) id 1vis1x-000607-55; Thu, 22 Jan 2026 10:35:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210755.1522368; Thu, 22 Jan 2026 10:35: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 1vis1x-000600-22; Thu, 22 Jan 2026 10:35:13 +0000 Received: by outflank-mailman (input) for mailman id 1210755; Thu, 22 Jan 2026 10: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 1vis1v-0005zu-Bm for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 10:35:11 +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 0629426b-f77e-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 11:35:09 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-43246af170aso504333f8f.0 for ; Thu, 22 Jan 2026 02:35:09 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43595e0a6fasm15676442f8f.10.2026.01.22.02.35.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 02:35:08 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0629426b-f77e-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769078108; x=1769682908; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=9W697KmD3NrZjlIy5dYmKifNka1kkrawLJNHvYhEe3U=; b=M9bouvtzjpuksnQ0+UEkO+qscruyNes3WOmsHuEUtPLnlcKfMDRw2GH+7obBGsdzcK Galc1baJy65fhZ4yHTtlCocjn674TnbJN/0mTjvn6pdTrmbu3X1jPmDZnyBu7hqgtRU0 ENDi9SKsUW0vOldKkIZMvJ3pSYx5lkkcl7wSgMpc4PvOOOEuDhSw7MMCOPxUjkmB/zTB OqHKbEPYY874sWE3KbJOfbMb73SnqsfXQiN3JGtfupHFuYNbNUiV9HUNabUX5OgLNMsS yfyVI82SjRoFa0jYPT1sJgkMmv6U6xdv0AcdkLDAxVGi1bd4wkosusENGOgZFaVuAEfy M4Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769078108; x=1769682908; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=9W697KmD3NrZjlIy5dYmKifNka1kkrawLJNHvYhEe3U=; b=kfA8FGEVmttpxAJWf8YUoaf59Qat//5DukX3Xd065Ycl2c47DFRIQEO4LJ+3HK03IT iiGERNio11hZf2avok8euUrbVQm/sn2wqYp1rwhVcZhKnDXzFzdfiqM8xBVnD+WAEiYC SxXLWhe8fk7Fot2xh7E3d+aNCqh40rz22TadD944ousbpoSm1YMZgaZRHeg0Iz8kancu Vw9nxBuEozjO4l/um86U8X1CqWN6LQQ08lcPMTUIiJzABnQ6BQuoNaSHkaTxF9MJyoEY nnWN7vt1h2yvEJqp+JMfGf/kf3o5mXuKR07xFCI8oILOvzGpWN8TH12p/2573sUJZiLF 0N1w== X-Gm-Message-State: AOJu0YwN21RUm/8uEFIdKdnVvp1Af3xcGAzZIR6SGoOP0lBZAmSRuTLj 46jMiPpGA/sLTvQwOMeg77ztp0SbDEwQPdKEEaXwLM9ha9EBSxJBdcYlALcmFiQhi170kSbUM4d jpPA= X-Gm-Gg: AZuq6aIvSFwWuazTEPnXZKRsKMYvvwymsWJsYMLVVbDZTT1/sV5dQhvR9YlodlaAsbe rCMhhq5AvCrwNMXnjSdSGkDwLH5hPRGez6DZOACkYWvMRP4aX+bTXj+J0t3MEAKQV0ZOcfGmyiI Z5v0AJh4oYmQz8M+SL9Y4oPxgzPhm+quaNjLAZS0Spm0Sl9W5bQqHfdNebS+2XXrwY6KIJWrJy6 1fh9TKltN+hP8mvPaLW/TgWSyO4z5V0jr+o3D04Zz89L6W1PNrfM6M0IvdLddzI2N9EBmN6VM0Y UXFnbjr+Vu/J3WB3G47zPdatJf0bDTEpwY7Ef0yVblPHjRmucVVcjq0PY3mqLyL3ECOkEe0zX9e FXvow+yOkiIlgqIk5/i+hCZeupqn7cRQtpd0RcAnI4Im4zCSyYzyxkeLHxv4WK63K5C15muHdoa Y6ZqSUKQDk78qDkJZkEQDmjLbWYHGjJ0aOCcSz7bE9UGSW+5n71Ep/140BwKvQ94dq/QoxAUPBa EY= X-Received: by 2002:a5d:5d0e:0:b0:435:953e:5897 with SMTP id ffacd0b85a97d-435a5fe530emr4442812f8f.25.1769078108497; Thu, 22 Jan 2026 02:35:08 -0800 (PST) Message-ID: <72bff85d-9771-4998-bc80-1efe2d453e6e@suse.com> Date: Thu, 22 Jan 2026 11:35:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 8/8] x86/HPET: don't arbitrarily cap delta in reprogram_hpet_evt_channel() To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper References: <57f34114-54b7-483d-8ac0-e9fa49df959f@suse.com> <37cdba83-9bf8-493a-9a7b-5ec11c32159a@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 22.01.2026 11:23, Roger Pau Monné wrote: > On Mon, Nov 17, 2025 at 03:40:08PM +0100, Jan Beulich wrote: >> @@ -162,10 +161,15 @@ static int reprogram_hpet_evt_channel( >> >> ch->next_event = expire; >> >> - delta = min_t(int64_t, delta, MAX_DELTA_NS); >> delta = max_t(int64_t, delta, MIN_DELTA_NS); >> delta = ns2ticks(delta, ch->shift, ch->mult); >> >> + if ( delta > UINT32_MAX ) >> + { >> + hpet_write32(hpet_read32(HPET_COUNTER), HPET_Tn_CMP(ch->idx)); > > Should Xen disable interrupts around this call to avoid unexpected > latency between the counter read and the comparator write? Such latency could then still arise, due NMI or SMI. What's your underlying concern here? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 11:02:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 11:02:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210784.1522397 (Exim 4.92) (envelope-from ) id 1visSS-00024s-CS; Thu, 22 Jan 2026 11:02:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210784.1522397; Thu, 22 Jan 2026 11:02:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1visSS-00024l-9d; Thu, 22 Jan 2026 11:02:36 +0000 Received: by outflank-mailman (input) for mailman id 1210784; Thu, 22 Jan 2026 11:02: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 1visSR-00024f-Ed for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 11:02:35 +0000 Received: from SN4PR0501CU005.outbound.protection.outlook.com (mail-southcentralusazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c10d::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d960ba43-f781-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 12:02:32 +0100 (CET) Received: from BL1PR13CA0310.namprd13.prod.outlook.com (2603:10b6:208:2c1::15) by CH3PR12MB7570.namprd12.prod.outlook.com (2603:10b6:610:149::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Thu, 22 Jan 2026 11:02:27 +0000 Received: from BL02EPF0001A103.namprd05.prod.outlook.com (2603:10b6:208:2c1:cafe::7f) by BL1PR13CA0310.outlook.office365.com (2603:10b6:208:2c1::15) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.2 via Frontend Transport; Thu, 22 Jan 2026 11:02:26 +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.9564.3 via Frontend Transport; Thu, 22 Jan 2026 11:02:26 +0000 Received: from localhost (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 22 Jan 2026 05:02:24 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d960ba43-f781-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=zDI/e30euLTNY6CPFkIE+KAIETIzGGyPI9sHOdUxds81pnyZuItVh0N6OQpkQAIbJq9g7B4zMuVDYQFDehzkZcdvMGiFdYGpxKOj7c8A0W6qD70bUVMfMzqo4YRgSuBk93fBj+j9YlVj8yiAv3N203ZfkfH7fj1+9F6FW+KeJ/SIrGZpzzdn4YxD0+OwT3qgwL28STmEQC+RQP8NlFIBUqpoNT7UbpnQWXj8fePa6A3i45nkThbiRQoCgR0ipiszc2W/Yfgq5JjsgjCQo5UZ0MQB3yCtpslkUvoPivOue7jq/ggnh0ZvJHDlbDx0+cHbcNHEo67jaw00pyn5OtQGLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LM8YiTQwtVwHP2YnilcnhoC7qDPxU22vJbVwDpcGvwU=; b=rvn1jnjImJL6ZLTiSnyurTUxxfbtF8rVjKqHTEHP68qMHVC8oGtj/TH8wdbJ1zXIRaYAfyoTerN9b8yjpWIbXdo2fmL/fgtXunHQ33ueQn301HQmKB68n6CK3bOWwzG7Xy7UZfqfN8/nSK7D4ya5ZUWYRMwBqEQXJ/8oy8GrEX+AzsZQDjmVi1tDLejqkR94PO7kw1M412AxT/QCTi+kf5zKuPO/Mwxnnxt2daGFR07MB6CZ00YkWmrJFujnsxLD3okhKViWV6DgS61GqAR+rID5iyt9JCDXm2sVD+jFunBexNgA4gOb1TjiDcxfoiOC/di8urtH7hztdgSrYU20UA== 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=LM8YiTQwtVwHP2YnilcnhoC7qDPxU22vJbVwDpcGvwU=; b=GCQDfeEaNiimlj4+ujOJCRYJUhpBblD9H5Y8EEDEe/6N3WxDsyINV78OsS+X83WAwuWX08T2xYL7vPjNoSgNHs92A1gTLfmdvsdiNQDdtm3EOhpsHC81oasdIYLVq4cmLux6XElTtLMuYv33Y3V9yq9xeA2uhNWF7cy04iPKIU0= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 22 Jan 2026 12:02:23 +0100 Message-ID: To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Michal Orzel , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Subject: Re: [PATCH v5 1/2] xen: Allow lib-y targets to also be .init.o From: Alejandro Vallejo X-Mailer: aerc 0.20.1 References: <20260121154757.44350-1-alejandro.garciavallejo@amd.com> <20260121154757.44350-2-alejandro.garciavallejo@amd.com> <526ef477-0730-4e22-a82f-4c598ad78e0a@suse.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_|CH3PR12MB7570:EE_ X-MS-Office365-Filtering-Correlation-Id: 25159a5a-d254-46a4-a866-08de59a5ba9c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|36860700013|82310400026|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?eCtGRnBSbkpPNjk1Q3ZaNW8ySmJra08vUDdDSFkvT3RyKzQ1TU11N210N0tV?= =?utf-8?B?MHIyWTZmN1V3dVNXUmlHZnBINGxpZ0RNQ2lFV1BDOTI0SGVwMk5lN1BxWXc0?= =?utf-8?B?a2k5Mm1xMTB3a256Z2dtT3lNVGtqUFo4U3pRK0tROGdYMU42eHU2bkVYLzFM?= =?utf-8?B?anNDWjhLQnk3SHJVWG9aaEMxZHVlMFNtUVBYVXhwVGFURGJDRUh2Mnl0UlQx?= =?utf-8?B?eUxZbXpsQ2VhWWs0OWFzK0thWDNOQXBEUHlkWWZxMTAwV010Mmc5VEF2MUlk?= =?utf-8?B?a3dBNk15ckl1V3Ayc3MzbG1jS0hHeUJyQlhaYUJxZGovbkYvMnNhK0tGYkpy?= =?utf-8?B?TTRRWnpwalJsdW13Mm5rK3l5TFRLSU1iazd2S1YzNnZmbjlnY01vUWxDYVE0?= =?utf-8?B?ZXNKNXcrdC8rb2hwblU4U1RweU5PRXFvV2ViUkVDamtqeTErVjFLREJDRkN3?= =?utf-8?B?N21YQWJLQ1E4eDZQUFlyclFtQ1ZiUExYN3NZOU9WQ2t0RlNZYllWRXA2SkJ2?= =?utf-8?B?ZTgyOFRVM2N5TzRGUzliREVyT1FOeEl4czY5eE5hUTgwWTFXVEFGcnJPam5N?= =?utf-8?B?d2QrRmpSVEppdVZDVHgyV3F0Y2pyWk9CMDRSRnMwa1dVY3F1bWNQWjJzVkRB?= =?utf-8?B?UmdpYWd5SWN6bjhxVTdwdVU2bDBLaUMvZWtFZ2IyUE9vM0pTaFF6Y2RTc1FC?= =?utf-8?B?dnl6WFg1aFNPM1RSbjdUVzVtOWNUcC9NclBlemYxVVhJZkNwclhodWNDUmsr?= =?utf-8?B?MWl0aHBFY3Ftd0xKZUxneGlDN0Mwa3dOQWxmeWJ6YVlBVzI4K0pmdzRnR0RW?= =?utf-8?B?QlA4aTgwZGcxQkJFRW9qR2dLVlFueGdiY09tTmlyeEFaWHFodW0zL1R1dXNK?= =?utf-8?B?eTVlNlJ2eDBSV1c2dkEzN3AwWWFFc3dBWVhsUXFhSmVHdEg0ZUhCRG8yTWhL?= =?utf-8?B?TlhjR0RiSjdSSWxKcDFmazZ4aVZwemhwTzQ3NWx6Vm9vQmtySEdKeklBaFhN?= =?utf-8?B?c3NFdkJTb3htQXZxZnM0UVBOSVpmMTRFM3Y1a1JjQ3Y0RlJrSk9USGxUYzdF?= =?utf-8?B?aHNjZkg4cURiUllIRll1Rk15QlkzUWpMd0R0NEl1UG13VkFDck1KYWpFYjZY?= =?utf-8?B?ckNnWjdlUERLYS9TcVozcjVWRXlJVXJRalk5S1orRkIvaXJFendXRmJPZDZt?= =?utf-8?B?QmFmdFdHcDgxMVFCUjFSVjZKdGoxNHVjT1ZzTVlqMmJQWGdJWEt2K2tEUmF0?= =?utf-8?B?dDlITDNQckNWL25yZjJubXg5aGp0dFNNdWxieU5uTUk0Nmc0VnZJelJnRWNs?= =?utf-8?B?bUJzVjdVd0k1L05yOVVSK0JTRTRyWnZlWmtOa3F5aWR2elpRajlDMU1KeHVj?= =?utf-8?B?VlNLTE8zVUlWMVhzeGxORVMzaHhJbnZsRUN3TkhTbzFDQnFydjBlZ0dONmdT?= =?utf-8?B?Zjdoblc4NExHTGRWdnBUYndpdTZHdVJKUTdvcE1nVmhyWmxUUjFXQmlSZkI3?= =?utf-8?B?NkplWHBXOHZRcXJGditTK2dnbktXQkI5Q0dNWTRhZzYzcUt5TmpLc1dUQVcr?= =?utf-8?B?ZFFEeHFmazlyNUl2NXVLZXhRZXk5OU4xTGQ4Zk5jbmYxU0pxeU9RMHRYdVh4?= =?utf-8?B?bzRhQVBrK3BqaENNeFUzNCswUnZqV21sVXozdk5ZSk9jR2JwaS9Pak9xSHB6?= =?utf-8?B?ZE1xMW1LbjRHOWVRVlZIL0V3Snk1SVBaL2h3aHRvQm1OaFpTTVM3RlVEYTJV?= =?utf-8?B?NkFzWGRaQkF4QmFabGlOWE4xYXpiQThJckd2VWtuWXR2azRiSS9GSDJJTnU2?= =?utf-8?B?Z3ZXczFmcUtTcUp0TDF3ZGVJK2xZa2t6NEwyNGRFTDJJMDJoRE9TRVlKZTd2?= =?utf-8?B?WVl3enRkZUxkbnF5bkRjUGVZRUdqK3YyZVdJVnR4REV5bC9oc3QzdkRudjdG?= =?utf-8?B?SHQ0WGl2Wm40cU9KWnhhSzc1T1JBZncvcG1GcWpaWW5WOCtMeUNreTgwcUFR?= =?utf-8?B?cEtzeWtWMlFNNUh4RFpLb0oxd0FrT1ZLdzZIL0tuUEduTUkyb1RHZkJwOFZK?= =?utf-8?B?Mm5PQWxHWmxqL1pxQlVLMGc4NnNNeHgzeEVhdWI3SXc1OGgwenBDYldmcmh6?= =?utf-8?B?S0x6dHptZmlyemprUnJSQUNia2g4MU5oUWdvYXUxbXczVjY1OTNhWHJvbW9q?= =?utf-8?B?ZVVVWkFCM0ZPR3hSM3RVanYrMlJ3STlBWUZBOG9RN1l0YmlVU1hjY21qbEpP?= =?utf-8?B?aFl2MHpFVDd6b1gyQVlRUjdwcjNBPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(36860700013)(82310400026)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 11:02:26.8058 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 25159a5a-d254-46a4-a866-08de59a5ba9c X-MS-Exchange-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: CH3PR12MB7570 On Thu Jan 22, 2026 at 11:01 AM CET, Jan Beulich wrote: > On 22.01.2026 10:49, Jan Beulich wrote: >> On 21.01.2026 16:47, Alejandro Vallejo wrote: >>> There's some assumptions as to which targets may be init-only. But >>> there's little reason to preclude libraries from being init-only. >>> >>> Signed-off-by: Alejandro Vallejo >>> Reviewed-by: Jan Beulich >>=20 >> I can't tell (yet) what it is, but as per CI something's clearly wrong w= ith this >> change. Both xilinx-smoke-dom0less-arm64-* and qemu-smoke-dom0*-debug* f= ail with >> it in place. qemu-smoke-dom0-arm64-gcc (no "debug") was fine, suggesting= it may >> be an early assertion triggering. > > Or an early UBSAN failure. I think ... > >>> --- a/xen/Rules.mk >>> +++ b/xen/Rules.mk >>> @@ -130,9 +130,9 @@ endif >>> =20 >>> targets +=3D $(targets-for-builtin) >>> =20 >>> -$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS-y +=3D -DI= NIT_SECTIONS_ONLY >>> +$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)): CFLAGS-y= +=3D -DINIT_SECTIONS_ONLY >>> =20 >>> -non-init-objects =3D $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(ex= tra-y)) >>> +non-init-objects =3D $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(ex= tra-y) $(lib-y)) > > ... this is the problem: You're _adding_ library files here which weren't= there > before. Why $(lib-y) isn't here I don't really known, but as per the CI r= esults > there must be a reason for this. Apologies for the unintended breakage. I should've checked the baseline for arm before ruling out this patch being the cause (it did fire in my pipelin= e, but didn't consider how this could affect arm and attributed it to a spurio= us failure). So we're neither doing UBSAN nor collecting coverage data from libs? Great.= One more task to the pile, I guess. Seeing how... $(non-init-objects): _c_flags +=3D $(cov-cflags-y) [snip] $(non-init-objects): _c_flags +=3D $(UBSAN_FLAGS) I'll try to clean this mess. :/ Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Thu Jan 22 11:04:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 11:04:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210794.1522408 (Exim 4.92) (envelope-from ) id 1visUf-0002ba-Nl; Thu, 22 Jan 2026 11:04:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210794.1522408; Thu, 22 Jan 2026 11:04:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1visUf-0002bT-KQ; Thu, 22 Jan 2026 11:04:53 +0000 Received: by outflank-mailman (input) for mailman id 1210794; Thu, 22 Jan 2026 11:04:53 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1visUf-0002bL-4t for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 11:04:53 +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 2c1fcd18-f782-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 12:04:50 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-47ee301a06aso9776275e9.0 for ; Thu, 22 Jan 2026 03:04:50 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48047028928sm89321675e9.2.2026.01.22.03.04.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 03:04:49 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2c1fcd18-f782-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769079890; x=1769684690; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=y94U3Ze7VtP0cnM/GCfNajfKHqNRb/fpqW8q52vpjAs=; b=EVMgqtNEXi3SwD+hafSaCW9XQeMQnKnNs9v36jfNtv9yDcQssUy14P70Jrx10vWdeF mjwoElrlT+zUmPkOOlbJSgAMOlnBxnIBHWsW4q152tQFEzy7h5pCcm0cFIOa7zymaEkf ecPSMEagtX6FBxrUDcnsHAwOlfCRrZMrcGFZGD0+VbrhA/vtoXg9Ibg15wrSFwWk1Wm+ tzTJ+GsyiBSGz+oFBv50hpM8c8U3iyVsyoi2ymEb01wotF7jGy/c2YFxD8SCdk5c2vMZ rjj7EsnXQKxrL7pldO3ng+lURzWmyxSAq1jlUKajj+82G+0R0BS1ufpsmz1gCgrxcgYr 9/HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769079890; x=1769684690; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=y94U3Ze7VtP0cnM/GCfNajfKHqNRb/fpqW8q52vpjAs=; b=CWDSKBplN9jlz/kutUlUuhvyErqvdP4IzJ60Lctte6+i+InmQQ6ku0mv01A+/OU9Am S4pDKlX2WvZMOJKVjQzUeRJ1H0v6WfQoy6bTd//jarzjVOq51Ifb1GwC6vzHDKOta6N1 U9BtZLJd5WVq3Bja6/8GHGeK0+PzNcgRTHjaMLjBIrilFZNBJ3nDUC9FZ32jRPl4MLvN K0c7U1FzK+GaGVLLMZfwekiTnORZ6ZkuMcpkgacRiIU+4SURT3olRaecoK5o8FK/Tl2V SbrYlzxhdr2CXXivRFYOw77hjc0+W2Wi9QlOVejKPF0cHEuPoNLLxg3yQ2wAQy7E63BW 4Jkw== X-Forwarded-Encrypted: i=1; AJvYcCWbfqp6xqLgNCQWUU0Lon374f/YU79ZAMMvlBtrB90N+oX2HKPSflxt0HzeYAdElEwpRmPdL/wWe2o=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw384e0PzCaws1cn+H+MrAJu25mfD+p26sCGcqnB1zrlZplBbr4 yvR2JWkiICH39Aq3WFwOeyZXo3/M7ZYFdulD8IdJ34nLJI6mFAX8t6zNdUdBkbJHKQx21pWbX1h GV5U= X-Gm-Gg: AZuq6aKQFVlD52v+096liPVAgklFq5SBdFF8cG04FDIzf0T9mHNqPDV7wfgsnUiODLt njt1aXADlsA+oKAI85gxTc+MKsBcIZKHeP2SzXP21hASEydN84w/kN0pHQ7s/gm8cD7YQI2y/YX CsUk917J7kUAaaAKAQLQRf2MxygeDxSvkI5OUW7VzP7Ga7d+7VTY4F+7ZZOBysaoNn8+kEB5c6F hXYdxvfgbyoM3nbtK9mkqlh2cyJQfX0pKqbzSYi0CQX5QD50Af4wzJg6Vwt0MbdTWki4jjwnK2y j45QppXKoqZ7/usPocA9ECP0/90m+IMb2vl+pZx2mo1RP3N+d53Kuctk3tPYOHfHXBRNHbJ97wj n3kqEFADxtdfu4ZOos1DlJqvSpws8YD/zmigfcExO2NK4WH3MJ3DJzaJ3gcQw7m93VvWNAeuugx aESiscAIwowKz+3tMfD+GXiVPKyrkSVbTJ6mnvIrCVdOvRLMdCIO6LtY1Uwe+AgID09kX456/x+ Zk= X-Received: by 2002:a05:600c:4e89:b0:475:dd89:acb with SMTP id 5b1f17b1804b1-4801eb035ecmr286705645e9.22.1769079889939; Thu, 22 Jan 2026 03:04:49 -0800 (PST) Message-ID: <7304f5e0-f55c-45c5-ae4c-3d3adc53a0b3@suse.com> Date: Thu, 22 Jan 2026 12:04:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/2] xen: Allow lib-y targets to also be .init.o To: Alejandro Vallejo Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260121154757.44350-1-alejandro.garciavallejo@amd.com> <20260121154757.44350-2-alejandro.garciavallejo@amd.com> <526ef477-0730-4e22-a82f-4c598ad78e0a@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 22.01.2026 12:02, Alejandro Vallejo wrote: > On Thu Jan 22, 2026 at 11:01 AM CET, Jan Beulich wrote: >> On 22.01.2026 10:49, Jan Beulich wrote: >>> On 21.01.2026 16:47, Alejandro Vallejo wrote: >>>> There's some assumptions as to which targets may be init-only. But >>>> there's little reason to preclude libraries from being init-only. >>>> >>>> Signed-off-by: Alejandro Vallejo >>>> Reviewed-by: Jan Beulich >>> >>> I can't tell (yet) what it is, but as per CI something's clearly wrong with this >>> change. Both xilinx-smoke-dom0less-arm64-* and qemu-smoke-dom0*-debug* fail with >>> it in place. qemu-smoke-dom0-arm64-gcc (no "debug") was fine, suggesting it may >>> be an early assertion triggering. >> >> Or an early UBSAN failure. I think ... >> >>>> --- a/xen/Rules.mk >>>> +++ b/xen/Rules.mk >>>> @@ -130,9 +130,9 @@ endif >>>> >>>> targets += $(targets-for-builtin) >>>> >>>> -$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS-y += -DINIT_SECTIONS_ONLY >>>> +$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)): CFLAGS-y += -DINIT_SECTIONS_ONLY >>>> >>>> -non-init-objects = $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(extra-y)) >>>> +non-init-objects = $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)) >> >> ... this is the problem: You're _adding_ library files here which weren't there >> before. Why $(lib-y) isn't here I don't really known, but as per the CI results >> there must be a reason for this. > > Apologies for the unintended breakage. I should've checked the baseline for > arm before ruling out this patch being the cause (it did fire in my pipeline, > but didn't consider how this could affect arm and attributed it to a spurious > failure). > > So we're neither doing UBSAN nor collecting coverage data from libs? Great. One > more task to the pile, I guess. Seeing how... > > $(non-init-objects): _c_flags += $(cov-cflags-y) > [snip] > $(non-init-objects): _c_flags += $(UBSAN_FLAGS) > > I'll try to clean this mess. :/ In the meantime, should I give your patch another try with that one change dropped? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 11:21:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 11:21:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210809.1522418 (Exim 4.92) (envelope-from ) id 1visl5-0005U8-1w; Thu, 22 Jan 2026 11:21:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210809.1522418; Thu, 22 Jan 2026 11: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 1visl4-0005U1-VS; Thu, 22 Jan 2026 11:21:50 +0000 Received: by outflank-mailman (input) for mailman id 1210809; Thu, 22 Jan 2026 11:21:49 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1visl3-0005Tv-Jp for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 11:21:49 +0000 Received: from CH1PR05CU001.outbound.protection.outlook.com (mail-northcentralusazlp170100001.outbound.protection.outlook.com [2a01:111:f403:c105::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8a570426-f784-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 12:21:48 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by BL4PR03MB8051.namprd03.prod.outlook.com (2603:10b6:208:58d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Thu, 22 Jan 2026 11:21:45 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 11:21:45 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8a570426-f784-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UXRJEkKIJR3vW6MjGQ1oBd4EXCtlp1RX30QDd98hRlSB06VzIzBqN0yFxboPq2U8MOxTwo74CHOb28CjukCgX0mmuOaquodLcUj1ZIQ9qT0kclLKlap7/a9NRbrGM0tc+L6h/NN+LevmuhhWyoKSM8X1mEO3ewNdn/WD1l8KLMwNbsCwR+ibYRPZjqLEc7b6tJ0NNLxfo58w5IAMClmJGvpqXBwgugBPKmcnjA10NwIzK5W2TXaNAN3qwM+malSVP4D89DsbBJBxD6kaLsTOylBpjfS8GN7GiJSl1cuD5RR0aXf+nkHxyDL3BVz70oIy0GpKKSjMfTPtrCJK1KDsWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=f1umjDa2o12H+ndM7WMGAge8jra05SYf+bYKrmKi5ig=; b=q/rIse4E2T1YPLsh6ihTuRqHNb0ccfbpWsW6Sb3klxoa8NsTp1CtGxjpwoYs+Rj8f+tEsn2NZ3SGrc2WSmoi/oYnh/Rt3xPl+e3T1ra5yKe6MM9GrM5SK1WWr/jZHfQ9GktvYwzcO6sdYvVE4pn/GDBGQwhIbCTA05PRLizKKnzNSrvQAEUycEzzm1GWu0QZ6I+UhCjTphF3p6/Xmu1hTQmveq7wRnqDm1H9sAAA+uvnFbPc0RRl3VJBNwD9uf7RTeAFiOWv75Q5W4N0m6bcWahYG40PCvgcRn5EJZJqp9ftTwPup5zYMEzxTW+wfkCmOHEhOzNkoRpaghs+hiyrFA== 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=f1umjDa2o12H+ndM7WMGAge8jra05SYf+bYKrmKi5ig=; b=PgE7JdlrB366KdYBRnXFYozNgjZagZ7U2jCYBuZvt1tCpFwXGwRthW1cGjvd66DfUJ2a2pdNADJp2BYhHj9qwJQYaCg1xycDMcyG831d1eaRQuUoNs4bjfbTAGyjI5lUE/PFf6EoeDJXB9ZwaorP1s3gTfTIiiy9NP7etntMQyU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 22 Jan 2026 12:21:42 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH v4 3/8] x86/HPET: move legacy tick IRQ count adjustment Message-ID: References: <57f34114-54b7-483d-8ac0-e9fa49df959f@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: MA2P292CA0024.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250::6) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|BL4PR03MB8051:EE_ X-MS-Office365-Filtering-Correlation-Id: 280d122d-895b-4d17-4ea5-08de59a86cf2 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?bEEvd1RVUWdGZzc1QmFSa3hWdVBrNTIweHRZTVQxM0NLaUVyZ2hEWUwxR214?= =?utf-8?B?cElZS2hpYkhzVVg0UEhkYjZ5ZW5uc3Z3VWxocWhuRVg0WnJUZFNPTy9yMHk1?= =?utf-8?B?WTBrc1FJbzlUQm5JYkVsV1F6RjRJSFBhbHRvQ1Rrc3MvWHJ2V1RqOUpWeXlO?= =?utf-8?B?Nk9FYVJSWWZYUGpmcG9QU2dsUHlLaDM4RjYwNGJXL1Eram45bWYyUTBEL2hk?= =?utf-8?B?WHJXOVh5TW8zeE5JSGdoSDBNbHZsUGU2UUlJTXhQUUFzck1GUmc0bkpuN3hi?= =?utf-8?B?RXRSRHhpd1Y4cXFjRWwvUGlGdlc0VWd6QWdJUkIvK3A1cGVianpGbUYwd1I5?= =?utf-8?B?VGFtbUU5ZG5SQ2d3czhqZXMybVlZRGdnOWp0MHVTTXhhUVFuVko3YUZoMkFq?= =?utf-8?B?UlZXdlZpREkwanM3ZWJqdU9Ud3RYaFlIU2NmYlY4K2p6NXFlaXdheTJEbHB5?= =?utf-8?B?TVFLK3dZZDFxbUtrdWtuY0FXbmFaSEtuWHErSnVGZE5MdmhPeUpyLzFJNEFQ?= =?utf-8?B?N3hLV0diVldWT25LditJRi9ab0cwbEt4cTF0MFRvUjJXM0xzd2lJL2oycTd4?= =?utf-8?B?V3RlOGNFL0xkVGJkeGNNKzgwTFJWNUxBZmJpRURRajZJQVVoN1JxRTlWc0N1?= =?utf-8?B?dXRSTWZISkg0QThJb1Q2azAzR2kxOXVLNnVNaWJuNWgyaEJWN2RPbW1CSVBt?= =?utf-8?B?RURnWm00NG9kclFSSjdnZXkzL3hBNm1vcXBQU1JpOHpiWHNCakZzTzdFc05o?= =?utf-8?B?RXlCWTkvRmFkT3lraTN6NW5VdmdPR2Q2SEM0ZVJTcmdwdFpjTWdIZTNveEtK?= =?utf-8?B?bWZML1A5QVhVUWRUdXo3ZDhmQ0FiUXovM2x6ZjhrUEhLQUZEN3pibHdMU3V5?= =?utf-8?B?RXhiN205bFZiZmVNbHJDeW5GRnl0TG8vRWdqT1JZZlcyZi9hRjVjRWRRbzZG?= =?utf-8?B?M21JbWhVbDRDWjMrYTY4Q3ZhVEx6Y2VJQmNoQmdsRnpPL1NzV1l2N0prdGI2?= =?utf-8?B?ZDNVRFNmTDJVU21pSGpjaTcrV1Fxbm12ejRLRG1ieERzcEROYlJHVzdBQkVx?= =?utf-8?B?emdGNGhINkpqai9OQ2pJQnBVV0thT20yY1dCakU1MjhXNExwMVBGK2JCNXNR?= =?utf-8?B?WE94R2owWG9tTy9kTHpnRFRxVkdlVTVTMjArMVdDVzFrRjFIaGU5aUVFY0ll?= =?utf-8?B?cG81Y2tQVnUwOGJRd2JsR1ZtZTY1d3V4WFArN0lTejVVdzZFWXhCRW44NmZG?= =?utf-8?B?dHFpQVk5anNCbFkyTWNmUW1RS3hIcjJWdmpUQ3NSQ2hhdUtjNmxQOHV0N25h?= =?utf-8?B?Qmx4RUZ6QkRTUS92Y1FqQlF3b3ZoS0ZHcHNtaG1wMUE1d1g3bXRoZGFPRU54?= =?utf-8?B?ekFURnBBVHl3RFlTUTRUUkdIMTlzQkxkSzNyNVdKbHJ0UENTZ3dhZ0RkdU1s?= =?utf-8?B?aUtJalY4ZHBsUDhmcklrU2dqOVBMdlRGT0krcHcwMkdGSzh6NVFCRnRHd0dL?= =?utf-8?B?M2FJUlladEpuQ3Y3M01HMEZQWXJYbUVid2V0cnFLeFFDbHRkZ2dvL2FuLzQ0?= =?utf-8?B?L25nWVJOdXZSQUJYZGVUYTdQa3VxZWtlTjlLc2Z0T2daUzFMQWE1RlY5bHhE?= =?utf-8?B?S1JCSmVnSmplTUxyc09GSkZzZkUvNzFvbkE1Zzk0NjNPMEhKQkNENE9WWGRU?= =?utf-8?B?VEtnZ0hJa3NTcDNMa28xb21Eelptb05TNEpCS1ZQZlFlb2pTaXFIS0RQcDNH?= =?utf-8?B?Ym1vcnZzY0Ntbk9UZ2ZNdmtkbWJhSytRM1QyUEt6dElzaHFaRExtdVZJSTV1?= =?utf-8?B?OUhMcGhMZnJFYXRjQWxadnB5QTVqanU4Z0VRUjBnVlVROFJaQ2VaYjNyeHMx?= =?utf-8?B?QlBlVk1RSlVGTW1LczRZS3g4OE9tdG4reHZkRU11cElyRFg4NUpSak1xLzNh?= =?utf-8?B?K0YrUkdyZkhrK1hTdmsvT09CWittK1dZKzV2RFpTSjg2Q2NWd0ZpOVhCYjJL?= =?utf-8?B?ck1XMTFHWG40RWlyUkVaUzVJZWgzNm44NGxIU0h5ZkFCTTFFUkFTaTBQTXYz?= =?utf-8?B?OE1XdGpQdUoxZ084NWNmWE5IaEs3eDdrNGo2RWtFVmRyTENSWmdLVGUyQnND?= =?utf-8?Q?tnoU=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dU1nOUdUakJBODZuRUJ5dVhoalpwc2dISTFpVDdqTGdvRGlYdit5WWRjSXJ5?= =?utf-8?B?QTMyOXhiUnR0RklaODVwK3lWWi9LeFNTMVZTbjR6U2dKR0JValhSUXlLcHJj?= =?utf-8?B?ekM0akZWRWFHY0FXaVIyK0pyYU13KzF4cFl1RHJjUGFWMDVPU1V3SjFhVUt2?= =?utf-8?B?aEFOdC9TMENSb2dMNzlHOEEwYlN2TFBuTVhDbHlLVjlzUzZMMHMvc2dHWFp4?= =?utf-8?B?MlZjWlFZT2M3bmVyd1dFcFpUNnhlekpoMnRRblR6QlR6dDdKRENJSHVFd3p0?= =?utf-8?B?MGJ6aHlUL0w2Ymd6dEFVTzJSY2JjbnFJbnVWOWR1QUd6YXprZ2ZaZUxmeDdr?= =?utf-8?B?azVxOTcybmp6UGlUbzZjWXQ2WUFFdzltemNReXRjVnBnMXZEdEd4d2k1NTV3?= =?utf-8?B?WFFnRXZJUDNob05wYU9OMkpXYXRUUDRFNmkrM3NxeE1JN080VTVEYldnb2Rr?= =?utf-8?B?dlUvSkRVU2VMcXJMZ0hENENKSlZqbVhFc05vVUFNK0RVK0ZHTlRCTWkvMnJN?= =?utf-8?B?U3hGUWgySDYwNCsxcXp2T0xkY1VIR1JrL1ZKNkpvNm9TQXZXanVuTkwrb2VB?= =?utf-8?B?WDV1QVZZNDRTWTh3ZG1EVi90Y3VuZ1hTYUlmd1l1azJiejFVMjFSQmFVTm44?= =?utf-8?B?WVNUSWdhSHlrWmdXMUZFVEV6ZThKaFpnVjIwaVp1Q2N5RG1PTEJvMUFMM3M5?= =?utf-8?B?UnFXcC9nRnJScmJFL3Z6Z1ZpemhycGVCTTU2elAzSHVGS2k2bkNHaExBdlYw?= =?utf-8?B?Q3pSY2JyNVd2UGJNb3dOUy9BeVd4Ym1pSG9PSStYaWYrSWFheHBDYkRNRG1T?= =?utf-8?B?RVlnUnBHVmZxNjFsT1BtVzBzanc3TXdXcWlJeFJCcGZKMlhtQXU4TWZ6UXBN?= =?utf-8?B?d29ETml1bjZQZFJqM0IvUXVJVWpOSUUrdjZXSkZSR0g0WndOd1FacVhvVFhr?= =?utf-8?B?NWpadUFPczNQQlB6RWk5UnRGS3Z2WTArTnNYZHVpaHpNdk81azVnSDUxbElz?= =?utf-8?B?NStZQjhVeTF4MUtpZWlhK2Fnd1ZSaTFvREJFTnZVbGxlQ1BzeVpkUXZjMVMr?= =?utf-8?B?Tm5sWTZYVFR1SENTTWVWSVFWUkt5ZnFITi9PUGlqTXlObU8vRXo4Y1ZJRkxX?= =?utf-8?B?c0lPdHBrckVoa3h6dGZSMjlXYU1ZdFpwMHk4RzE2TXNoczh2a0thL2NFdVRW?= =?utf-8?B?ajdONC9Lb2ZSNG9DSkp0VHRUZDBtYkVncHdTRnpMNHlKdG5CSHZ5VjdvdFdQ?= =?utf-8?B?Yy9qTW45ZmNDZ1VXTVpUb3NkZnE0NUwzZXFJN3U1TUtvNWd4elVhUlFCRENZ?= =?utf-8?B?MFlZUVl4bmwrbStyM2Z0TVdKc244Mm9zeUxDUmQ1VFlMRGRGUDlWbzkrNTZH?= =?utf-8?B?WjVLa3NoMXJrYkdycmtyNVd6bFFOR2J5ajUzbU40dWg2QUsxWkRZL2xpNmVX?= =?utf-8?B?N1p0ZzlUOHBWL2JvQ0sxaXJPNWhOSm5hNWRlYnBvV0FUT2UwUVMyd0RFcGgz?= =?utf-8?B?Q3F5Rm1FNTdjK1o1YytZZXQrdURkcksrTEVsRkNqZ09ZMEYwR3pCeUkrd2RD?= =?utf-8?B?VUtIbFhBekJHRURGN0JiMnQ1eVpyeGRlRjkrbXYwU2xzelE1K004REZJem1I?= =?utf-8?B?bTFYYzJDbmk0RGFmQXZDdHFma0VBNlg1QnVtYTJuMzdYOEdOMldwcTJsWm9h?= =?utf-8?B?OFN4V09tN3l0NWVyY0NEVUpzeGNmR24zbzlSQzZmY2I1R3FtMHVBN25Bc1Fv?= =?utf-8?B?T3VML0ZsTkV5cWRaSGlXSXR6UFp3ejFzYjkrM3FwbFp5S0RrdmhyZXBTQ0Ix?= =?utf-8?B?SnFYZkNSZ3ZQSExWUlhiVXFPNktIUFdnc0sxclJmeGwxU0dZMnFJRmZrN2Jq?= =?utf-8?B?a2JlaUtpaE50MGZXUU9jUDY3MmRkMnZVUkFCS012ZXA1bW9tdGw4clc0cW1a?= =?utf-8?B?cjY2clBGcUNxMWswaUY1bmtCZ2VKRnl0QUtyN0VLL2QvbjduYVBUVGUrbDVu?= =?utf-8?B?WWVtWXFxbVBPRUhxK3RQY2xEM3p5bGhFa09ocis4MUhXYmhGOEJmVVJrNHht?= =?utf-8?B?UHVXVG4vOWJ2MzA1eDZvai9sWWFFbVR6RTNVRDhpeVdhYWJxOW0wenhHYk5v?= =?utf-8?B?azlIMkhTRFlIRzRIaEZvYVJ2QkJkb05oKzBncS8zditxS1FvNUtIclZGaFZr?= =?utf-8?B?NmF0U05BWmhrRjJpU0ZaRWdQa3lld1plSUhjOEZFK0dTZE9YSjFvUWphdVZB?= =?utf-8?B?ZFZPZEx2UHI5TDJ2dW9VN3NpS3ZGMDFTTDhKcGExUzNiVm91VWUyMmNYV3lx?= =?utf-8?B?UUZmNGVSU1I2ZHp6Yi81a2kzYVRpRlhiM21kL1h3TnQySTZTaXVwZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 280d122d-895b-4d17-4ea5-08de59a86cf2 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 11:21:45.2420 (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: 3YpiHMKsu40YHTpfXT8j12CkQ24wlVQ3ohGtZKHBsZE2ltxVr7czOFJmIAEJrC2VjXP8J71LcQZJljf9weydBg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL4PR03MB8051 On Thu, Jan 22, 2026 at 11:31:52AM +0100, Jan Beulich wrote: > On 22.01.2026 09:50, Roger Pau Monné wrote: > > On Mon, Nov 17, 2025 at 03:37:45PM +0100, Jan Beulich wrote: > >> If already we play with the IRQ count, we should do so only if we actually > >> "consume" the interrupt; normal timer IRQs should not have any adjustment > >> done. > >> > >> Fixes: 353533232730 ("cpuidle: fix the menu governor to enhance IO performance") > >> Signed-off-by: Jan Beulich > >> --- > >> _Why_ we do these adjustments (also elsewhere) I don't really know. > > > > I think I have an idea of what's going on here. This accounting is > > used by the idle governor to decide when to go idle. On Linux (where > > the code is imported from) the governor took into account the inflight > > IO request state. However that's not available to Xen and instead > > they decided to mimic the tracking of the IO activity by counting > > interrupts. I bet then realized the timer interrupt would "skew" > > those results and make it look like there's IO activity when the > > system is otherwise mostly idle. > > Hmm, yes, that sounds pretty plausible. Except for one aspect: Why would > it be I/O that the governor would care about? This is all hypothetical, I don't know the real reasons. I think they aimed to avoid putting the system in deep idle states if there's IO gong on, regardless of whether the CPU is otherwise idle. Putting the system in those deeper idle states would also increase interrupt latency. I'm not arguing the initial purpose was correct, just attempting to make sense of all of this. > It wants to judge by the > system being busy, and timer interrupts generally are an indication of > busyness. Just not broadcast ones. Hence ... > > >> --- a/xen/arch/x86/hpet.c > >> +++ b/xen/arch/x86/hpet.c > >> @@ -808,13 +808,13 @@ int hpet_broadcast_is_available(void) > >> > >> int hpet_legacy_irq_tick(void) > >> { > >> - this_cpu(irq_count)--; > > > > I think you want to pull this decrease into timer_interrupt() itself, > > so it does the decrease unconditionally of whether the interrupt is a > > legacy HPET one or from the PIT? > > ... I think moving to timer_interrupt() would actually be wrong. Hm, I see. It's only HPET broadcast we want to avoid accounting for. > > By gating the decrease on the interrupt having been originated from > > the HPET you completely avoid the decrease in the PIT case AFAICT. > > > >> - > >> if ( !hpet_events || > >> (hpet_events->flags & (HPET_EVT_DISABLE|HPET_EVT_LEGACY)) != > >> HPET_EVT_LEGACY ) > >> return 0; > >> > >> + this_cpu(irq_count)--; > > > > Also in hpet_interrupt_handler() we might consider only doing the > > decrease after we ensure it's not a spurious interrupt? We don't seem > > to decrease irq_count for spurious interrupts elsewhere. > > Even a spurious interrupt is only an idle management auxiliary one (i.e. > really an artifact thereof). It doesn't hint at the system being busy. Right, I was mislead and somehow assumed the intent was to avoid this counting for all timer interrupts. Instead is just the HPET broadcast that not accounted for. Reviewed-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 22 11:29:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 11:29:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210824.1522428 (Exim 4.92) (envelope-from ) id 1vissI-0006Fi-Sx; Thu, 22 Jan 2026 11:29:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210824.1522428; Thu, 22 Jan 2026 11:29: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 1vissI-0006Fb-QH; Thu, 22 Jan 2026 11:29:18 +0000 Received: by outflank-mailman (input) for mailman id 1210824; Thu, 22 Jan 2026 11:29: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 1vissH-0006FV-7O for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 11:29:17 +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 9469e9b5-f785-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 12:29:15 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DSWPR03MB989131.namprd03.prod.outlook.com (2603:10b6:8:35e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Thu, 22 Jan 2026 11:29:12 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 11:29: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: 9469e9b5-f785-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kc8+4HGUOO8oapIS8Ms7+vpARSYiAD7gpv0mmVAq3em2po27h7z85uF0B0gDYXwzsE3mKDg3MCkFfn1eP5LhDgkUV0oLWpdEdX8MU5Pp39YHX/SdyF5WHVcLUm1bg3aOcphS88jsv4q85YYexfG8ibC5qfmbPEYuhf4xw/jJpZIlmKbwFvVkB4nnSrGQ5urvul/K6dLmYc+zQN7/P20IAfk9Drav6m1lhXOjgAUwDC3jftlZDpumXVd2HVf7XIY2cfSaE9Xp0lJ65Ws3MuAMjdk5bPS1ENO2hVYFjGfMDLV6eJdSS+AGIkoygEZLhF91BRlX+zT9UabzgMhTQGRkMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7gcUJCYdFH8VVWljgHuoSQiTwCh92/y7kYgFfRNKOUM=; b=oWANhRousfD1bXbYwqAyLdPvpgfKkfFYTj0VFwCIgDh8qjEGuM3lLI+UvXdmuh/bMYGCJyLaWVOeFp52kDDclsHvinOztIkn60GmR9lnLneI4RRV15ndUqyDf3FVe2PwqauZnNi587pF2FyJWtIsmxm+FaZaRI2zGJxHBjkLVpySG92euF/OJtAhUD3aXvRMC1bJkP19BxDFeJV8K0OL5ClIXxcIHSIRE/TZs6Ry08rZWYU4gJoRNkxX0RBNz1ZqTmaJe/glQjn2PG2lmwEvKHhG8rIico/LEZFtj+l1B5F5N+l21QV607Bskspd29XooVzrbjZzfAN+r4G24Vci+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7gcUJCYdFH8VVWljgHuoSQiTwCh92/y7kYgFfRNKOUM=; b=IXk5PciCWVYo5zf6WrdanLlySg8Qvla2R3eW40HJBxO0iYysAuiWXAe+f+j5xtCAmgi4riAJO7i8vY2RzoX/OKV7Cuab8vuVvVTj0ExknXr0uMnfvt1oZMuVEgk2ImFjQz4h9jzf7OgyvjNv8VrdqGmtU2/qGD5RgohGkjycrtY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 22 Jan 2026 12:29:08 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH v4 8/8] x86/HPET: don't arbitrarily cap delta in reprogram_hpet_evt_channel() Message-ID: References: <57f34114-54b7-483d-8ac0-e9fa49df959f@suse.com> <37cdba83-9bf8-493a-9a7b-5ec11c32159a@suse.com> <72bff85d-9771-4998-bc80-1efe2d453e6e@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <72bff85d-9771-4998-bc80-1efe2d453e6e@suse.com> X-ClientProxiedBy: MR1P264CA0118.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:50::25) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DSWPR03MB989131:EE_ X-MS-Office365-Filtering-Correlation-Id: ce2c2afe-6e7a-4daa-f1bf-08de59a9777b 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?TktFbFliVXdrRmQwL1B2WGtzS202L2lYcVlRcG91ZjlqYU4weDJ0MkZOZzc0?= =?utf-8?B?SzV0c0RKeHM0cTRCdGM1YkRxZ3FJTWVqM2loUG9YWk5Kc3hDODVNOFBpQkVy?= =?utf-8?B?b3M2bzRsM3ArbmZsR0NLQlZqQjczZCtjQlYzbUNDM0UzU2hjL1dlQk4vU0hU?= =?utf-8?B?bWY3dUFMTFpNd3BhVm5CZ2hHSm5tUWV6SXBZVlJUNGcxZFdqc3BEVTNKRFl6?= =?utf-8?B?WjNDTkJNbFdFWGpNS1FTYldZVzdRNDFjdWk3WGkrczlObzFvdDlUM2pRakVU?= =?utf-8?B?UStlci9kck1PY1gxN2xQTmMwNVVTYmFmSHBPNjJabG9WMHJlcFd5Y1Y2Rk9s?= =?utf-8?B?TFZOV0xXcFo0ZXg1TWw4MURCWjdTSXkvZUtMS0VkRVNsMmhUWjBaOW9zTzFY?= =?utf-8?B?ZERzU1JCeVlXRktnWDdoRmpQYjRIZ1h4d3RGVG5YUGVCOEo0L0xFUXlSWDdB?= =?utf-8?B?UTkyL0hmUEducWpITkFUTytzYTRjZ0hyaUVpd2pkK1ZnK0xhWmppTTRGV2Zh?= =?utf-8?B?NUR6ODJWUUROS1hFY3dWNkVtSkY5WURkOFRSQTh4SWIzL1ZQMDQzcVNBRmNw?= =?utf-8?B?THN1WHFKd3M2dHZiL1laZ0ovWEVKZE0vRmJVK0VMYTBXYk5uUzNMK3NqYkhM?= =?utf-8?B?SHllYm81OFpHTlJ2RjYzaDdCV0N1NUQzSzRPVkViQjZFWWRVQjJXcFBZVWNJ?= =?utf-8?B?czhtZDMwdlVrVnZCOUFteE1EWGlrZm8vTHE0WWpzR3hlbjBEd1lDbHVqQVEy?= =?utf-8?B?Q3JpOG1ZK1gxZnB5NUhlSE5wQXNXMzVuazFqaklCS0s4SXVzQ3phZjJRRVkx?= =?utf-8?B?MDBqRUthbEkzdGVseXBWc284SUpyeVVpNEpaRFYxNjR6cnM1ZjNKZ3hZUVoy?= =?utf-8?B?Qzlkcm9ETFVndG9mejZLOVRoMjdXUmJkZ3NCL3JCMEI0UlZIRXRqMEFndlVT?= =?utf-8?B?UFZQYXB0RmF2UXphVGIrdnZOZnpBZTROZjFxUklpYzBFcU9oWlp4dC80dGlQ?= =?utf-8?B?NDZBQU0vNU5zamlIcHNBRGs0czBQdU5HVytKcDBZTDhhS2loZlpsMkZkTkVU?= =?utf-8?B?VEJqWkRzNXhJRE8vcElGN1F3MWEvL3UvNDdsODNiVFFLTHovVW4zL3JOTnFh?= =?utf-8?B?N0ZtWUJDeGNTbDdyZUhZSkJsVDZjZjloemJJQzROdDNVeUgwS2Z4NHRKUVVo?= =?utf-8?B?YkRxOUpITVdRRnFNRVFRSVF5L0lUc29NNHhLeFE4bDRwbmpTczZ1UUpLYU05?= =?utf-8?B?Z0lkaXNiVytFNU9WY2tFQXNxQUNkblNURGlYK25rOEFRRU1seG96NlBwWGFY?= =?utf-8?B?VC9RRHJzeTRUM211d3JwY25xckFBdnJBL3FjU21ENVhVQ2NOZHA5RWhDUVds?= =?utf-8?B?ODlUNXhLVHV4QXRaY0Y2M0lEekI1THl3RE81UWlaRm5jczVGRkRubjlTdys5?= =?utf-8?B?cS9EOFl1MXJuR0szL1NkWXhOSmlNeGhlT1Jkdnc2WlFFOU5LMHJFVzBDS2dT?= =?utf-8?B?dU9JMlVaVm5qbVJmWVVEUTZRT1ByTnFxTWZpZzdhTUpPUFlrZ3oxVXQwemhj?= =?utf-8?B?aTN2V3VaZ1ZiUmFaRHh2aHZTK2pQdjVuUzJLUmlQbENUTEliNC84M1dPcndJ?= =?utf-8?B?ZTRWNE5yVzJxVXNsSzI5ZnVXcjhRR1BTOC9kcitmZ09wbUJTNi9xSTZRaFBV?= =?utf-8?B?VWpDMEpuM0hJUkZ2eXZwdVdKV3c3T3Rrelo5cWdITEhXUTd6T0RYakNBYmlJ?= =?utf-8?B?OGFrMDBIVkZDSGtYdjFkVllndWNGb3lObU9XSFVCSnBpL0JkYkVjd1VSbzdU?= =?utf-8?B?T25PekNESktOVVVTT3NMU0hCblAxcDd2WVo0dVhzb2VnS0hOQ3ZrYmdsOWpm?= =?utf-8?B?b2N6VVQxSklma2RYUUNKSk5sQ0xYeFBXQlNGZG91cTNFUERuK1pHM252M3JE?= =?utf-8?B?NUZLTCt0UjczbGVKVkcxZ05HQmdKdG95U2JDanRQbDRmWkFGVE9MeW5ReE9P?= =?utf-8?B?a2lFVUNwenNUVnBmUUVUTkhxTG1aTWNjWk9ObG00bkRWSTBCWDFmdm9URDFB?= =?utf-8?B?NXNiZGkyN1NxUmkxS1piNWdxd0dZdUNOU01tSi9tdTVpaW9oREJPUDNxRjJt?= =?utf-8?Q?WFgI=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eEJwbE1QaFczdm91cksxdTVXbHBDb2NJTXZBU25CNFFpYTBuZVBMYVBrTkhw?= =?utf-8?B?enordW03Z2ppSk03V1N4YnZMeklpaXJMdnNxWEdBalhKbmR0RGdqb1dyN0Fx?= =?utf-8?B?Ykt6SW43MFRRYVhDaVFFNkpIM2VIVVBrRk9aSEp5WGtiNW1hY1JMVXJoVWN2?= =?utf-8?B?YVR6UzBsN3RVOWxXTjc0a2cyanlhN1hicmpsU3RaQmhjdlc3ME1MVVFsbVJU?= =?utf-8?B?N1lEU3NTMzd0akgrM3NLUFRzTC83R3MxY0hIM2YyUWZNbGd6Ry9aUHppeGVq?= =?utf-8?B?VmNzQlVjTkZsZjBaalFYeTljQTU3YnFreVFJc1VoM1o2Z09Ea2RTaFNsRExN?= =?utf-8?B?QURTNHQxT01acmVTb25nR1BTd0l2N2hDWjc4cDFYT1NlN1d1c2R2Q1Y2OGNk?= =?utf-8?B?RjBzV2tOaW04blJNZ1FoQU1lYXExYU9xVkM0UHVuTWl0aVBlSWMwZEVZdkVh?= =?utf-8?B?RmF5TmQxdGxjNEU5QVMzaVpERUZ0NXp0QWpEM2hyS3ltZzJRNmlWQ3BsaEVh?= =?utf-8?B?bFprUk05NU5CUmpYTXhuQUJucDlxYjhZd096YVVlYVVUVUVXOWQ5ck1VTmpq?= =?utf-8?B?ZHh2aldBVjR3Y3pHblVLRndCMzFQWTUxRDY4ZitGTGVOQjFTckZZSkdKUjFW?= =?utf-8?B?a2E5Zno1UlkyTTFPNmtBWG9pTnFnNWdEZ3lmcjU4QW5Ydm1iTkJOZ3dmQVdn?= =?utf-8?B?eDVGNTZwcVdqNmZlYnRzK3d3c3VxWmFQZkdtQ0dxdDRIekVTcy83VUt3eWsw?= =?utf-8?B?Ykl3ZkowMUx2NENlcGNudWhIdU9yMEsyQ0l4TEhERjl6enVVT2UrM3FETXRM?= =?utf-8?B?RGpSSndGa1FIME5tV0lEZ3U2OUtFVEpMV21LVHllMGczRVg5T1BpUi9VNWY0?= =?utf-8?B?cE5wbmVkMU03dnBUSlBmNG9uZ043QkVOSElxVEo5Wi8yMXNwM1VhQ0ZhU3Mr?= =?utf-8?B?amczaHRVM25qRVhSa0Y3VGM2Nm5WQkFrbURienBFVnIrV2dQcXZMRDQraGkx?= =?utf-8?B?SjNyTEFpbTM3MnhGSmdhOG9mdE9XK2ZSZUczRU9NUWhtSWZtTnpkbjlnck9L?= =?utf-8?B?OWJNVnlwUml1dGpWVzI3a09CcVVtSDJnbk8yL3U4aityZFV0YTFXTHFrNmVX?= =?utf-8?B?UHRkVGVSSzlJc2JSNVB0dVZSbWhGaWJSSWxZNGpmYUdhRk55OXlNRURjSkNY?= =?utf-8?B?RUFpTDNaUEVSaDU2dWpvMDdPU1ZBc25kR1I5ekVTMlI4WXMxczRwTzE4aVZl?= =?utf-8?B?ekJKZjF1ME5GeTIzYXVtNFBkMDhNMHJ1RTRNb051RnQ5OFdFTEJYWWYreWtC?= =?utf-8?B?ZHdVR1hLeFdhZngycmRzaTV4aXBsYUZDem4zRDZpa0ZhWFdYQitSQzFWcjEy?= =?utf-8?B?RzZ3eU1PYlRBNmplK0dZYmtQcjh1UEFCWTlJVlk5QkhHb1pPbk8xM0VEL05y?= =?utf-8?B?TG1aVXBDTGZrVk5LM281TjNIZjFaV0NvWjA2K3RsZXFxV2QrM3BsZk5CMitR?= =?utf-8?B?KzVGTDV4OW1jVlhtcTFRTDBzZVI5VGJOQWNhWEVVVXFUaFpTNmlMTUZ6WlRP?= =?utf-8?B?OHVYTDBDUWx3N3hQZFFrQlc4cUhuMVkzQTJhekpxcjJBR2svazliU2p4WXB6?= =?utf-8?B?WjBqK0Z2dTNiVDcvQ1NOWExYU3VLNHBKcXN6Z3BnTUlOVFpOZ2E5eEwvSkwy?= =?utf-8?B?UXJqTGNjQ1F2Y2FQMTFteE1DUm9zVEY4WnVYSFpabVFWSFlMajc0L1ozb2lV?= =?utf-8?B?UHFQNUo0TUdsUmllelhHQmE1ZmYwakxlNXFEZnNsK2hvNjg0Sk5GUXk1Vmsy?= =?utf-8?B?SWVvNmhDWWZUc2ozNzU4WGsxVlljQS9mSVluZXVFbkQ1M0x2SlFMNGREeEdG?= =?utf-8?B?aVVaeTF6OWNrdWY2dUdtRzhacGt0TmJnamhjZ1RsOVo5SkNiMG91TkZkOWNE?= =?utf-8?B?TG1kV3hGOGt0UU8rd256RXRYdUJXU0NBa2xCSlZDTjZwL1NFTHRxWFhRMTF0?= =?utf-8?B?VjByWHczY1RSUzk0Q2NoNGQzOVhZVTkzbTZpclQ3OE14NzBtdUNEUlYxRDE4?= =?utf-8?B?c0daMVp6Q0lVbkJmeUJnN3BVRXRZd1Z3c0k3YXJSaG01aVVpa01oam1wODJL?= =?utf-8?B?Z3ZwMzEvYU9zY2ZlUHlPTlFQWkFtd3E4dlpnV3hBc3V1SStpa2dtUnhScGVk?= =?utf-8?B?SVlDeFp3b2s3dU4vcitiNys1b0F6N1ROcmxCVlBFZWlLQVFtUTVtZC84dFNK?= =?utf-8?B?bGJCdGtGZjFOckRZUHNpREgwZmNhVEFhTE1WemxxMnJDb1VKb1N1RXpvdjRD?= =?utf-8?B?aTlWUVZSeU5DV0Eyc283MWtVNnBVNG4wSG5uSUppU0NnZ0JkMkZCdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce2c2afe-6e7a-4daa-f1bf-08de59a9777b X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 11:29:12.3995 (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: tf10HH9Z99KbxUSgT+v/k8LGETLwrVj8dXB0Ma3GHBXdGjmHCEmBJvb71qv9TPec5kcfWLhuQZ0n17HVxQ1TlQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSWPR03MB989131 On Thu, Jan 22, 2026 at 11:35:06AM +0100, Jan Beulich wrote: > On 22.01.2026 11:23, Roger Pau Monné wrote: > > On Mon, Nov 17, 2025 at 03:40:08PM +0100, Jan Beulich wrote: > >> @@ -162,10 +161,15 @@ static int reprogram_hpet_evt_channel( > >> > >> ch->next_event = expire; > >> > >> - delta = min_t(int64_t, delta, MAX_DELTA_NS); > >> delta = max_t(int64_t, delta, MIN_DELTA_NS); > >> delta = ns2ticks(delta, ch->shift, ch->mult); > >> > >> + if ( delta > UINT32_MAX ) > >> + { > >> + hpet_write32(hpet_read32(HPET_COUNTER), HPET_Tn_CMP(ch->idx)); > > > > Should Xen disable interrupts around this call to avoid unexpected > > latency between the counter read and the comparator write? > > Such latency could then still arise, due NMI or SMI. What's your underlying > concern here? For NMI or SMI there isn't much we can do. I guess this is much less of a concern here than it is in hpet_next_event(), given the next event is expected to be after a full HPET counter period. One of those events taking a full HPET counter period overlap would make a lot of others things explode. Reviewed-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 22 11:30:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 11:30:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210832.1522438 (Exim 4.92) (envelope-from ) id 1visti-0007hC-7H; Thu, 22 Jan 2026 11:30:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210832.1522438; Thu, 22 Jan 2026 11:30:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1visti-0007h5-4C; Thu, 22 Jan 2026 11:30:46 +0000 Received: by outflank-mailman (input) for mailman id 1210832; Thu, 22 Jan 2026 11:30:44 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vistg-0007gx-Cg for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 11:30:44 +0000 Received: from BN1PR04CU002.outbound.protection.outlook.com (mail-eastus2azlp170100001.outbound.protection.outlook.com [2a01:111:f403:c110::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c8d5827c-f785-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 12:30:42 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DSWPR03MB989131.namprd03.prod.outlook.com (2603:10b6:8:35e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Thu, 22 Jan 2026 11:30:39 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 11:30: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: c8d5827c-f785-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tgZIUBd04z37zCkRc3G0RwFJrcCmk9jiqQVY3FwqI0jkeL87q7wmNd87gdrsp6Lj+xlqNx+M0MeldzmSHyRfXeZIJXdY1jZEQtcF9a+QEgV/Xv1THEHS/pMF836pNt47xVdPKI6dLEYdwRxJR+gSATY02XX24CsXXvzojogLtcOuFYij47yhToOCopW2D3u6l7bmsXF8QoqR8MHp1KD21LLDgenpkNLHFMNxmydwBgy5XWxfI6gIrum6fVCnE0n88jQ34J2YlzNWOzYm3xwWMxwws4Jzjro3lJlDaU7Dyiak/gpSioL+G5W+PvW+s/DXg+L9EUrofyWg5rIkbyXRHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=JteJpugi06cOlCuufZCG6soSAeIsxv7YIA30SgVlhzA=; b=qPQ178azSxxUgUJsjUD5z9ylXJSfGn0VK5XdyQcTF62RUuI5d73zRkszquoMcyPbS4cGJl1u5qkttFjwMLflcv0iRWgTHgnXuB72gScdMaydIIqPnp86d3wYFNHTvLCr7+GfwriFmeIos7U/+MQDLNyvUyGUBs+voaJypIB66a8Ibkoqd+OxaDhgIVVcRSrVtB982ZlhTeEL/RnJio8pxk18QsVg81Z+q9dYHHnH1TAkPlEsd0odr06mqrUm4NbN5/nb8eTFT1pqtBL18QJLknudtfnbti1OzK3qypKMiaL6E1M+9WObHvheKw033DT7R+I31YzpqVOEsm569VW5Iw== 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=JteJpugi06cOlCuufZCG6soSAeIsxv7YIA30SgVlhzA=; b=VyOgZ8b7WlEhjV2OvUusIAHv0eap1H8+VbyRfJw8/5PaGO6C6iiTj0so8HV932x5rlD9GK2t38R/kOZjZqU64DRvVUdU93TzjUIDBCbxxI8ycegykLn5IESSQTMRPLogrSAnbABOm/jGxlVz3EUxwaStTndea4Mvo3vdusVATZw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 22 Jan 2026 12:30:35 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH v4 6/8] x86/HPET: simplify "expire" check a little in reprogram_hpet_evt_channel() Message-ID: References: <57f34114-54b7-483d-8ac0-e9fa49df959f@suse.com> <0bc920e2-2e32-4b3d-9ed0-a2c2b34e9591@suse.com> <73daede9-d7ac-44bf-a018-b76d39b3eeb4@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <73daede9-d7ac-44bf-a018-b76d39b3eeb4@suse.com> X-ClientProxiedBy: PA7P264CA0528.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:3db::13) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DSWPR03MB989131:EE_ X-MS-Office365-Filtering-Correlation-Id: 873eb92b-073e-4965-fbe0-08de59a9ab7d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?OUxGdjJJVmFWSklLRGU0U3RTZ05QM2dtMURha1R0SHdZSGtUaENmc0V0MmdJ?= =?utf-8?B?Z2ZHdVJBbE8xUEE1V1JjdHRTcE80VDRLamlLbVdpaW1xbXFDUFdOb2V0a3pa?= =?utf-8?B?bHhENnhCUzUzMk9tOGpsVnk3dHUxK3pCOEJXSnN0eWk2TWUzV1dJa00rM1Ni?= =?utf-8?B?dG1lTzdjSWRSUHhDNGIzVHZHZ0N3UGJVT1dsbjZGVmZrd2N5RFM5L3NWeDlK?= =?utf-8?B?anE4MWRCL2pDYkhpalQ0bGpBMXpDVU54ZFp4ZHg4d1Z4M3dJdXBicFp2bXBL?= =?utf-8?B?cnNDQVZnU2VGaDJqcHZqblNpSW9SQlRJS3VvbzVCYkYweUIycnNpMExSQ3Ar?= =?utf-8?B?SmRVN1FIcGczc2hqVkZWWGJZT3BQM2NCdmV4bGdIdWgwcjlxa1I3ZXNTTFk3?= =?utf-8?B?dFRhTXpVWDArQ3c1MFZIRUhyVWhFVkJrRUo0eGpkU3pXZEJucVNCYk13WXJk?= =?utf-8?B?SUlBNXRGR1pqWFBiN2I4NWROOFhhNkQxQjR5T2tGTlNvS2l1aSt6R21VRU5M?= =?utf-8?B?dENsV1IzOWxYNmFkdFFNT1VWZUpnSVZqd3locVpVZWRyMjJjTzE1Z3ZFL3Q1?= =?utf-8?B?dDRCYXozK0luVWdLVENIa1MzRlpnR1E0dU4zNjhCdmlQUEp4TkR5cWd4RjhL?= =?utf-8?B?aU1SNWxKTVBYTkI1WHRnd2JWS2FObndCRHdXS2VvN0hmZ1hRZDJUTyt1VW1w?= =?utf-8?B?VVp1QXk1N2Y5YkZOS0NCYUFoMEw1Qlp1QklEK2J1L1hpaHRrSWJpTzd6d3RO?= =?utf-8?B?SlZDSkZGWFgvNVVITXJianFqa2RKbjRaajZtMzNjbEt4blNmUHZYdHlCbjA5?= =?utf-8?B?ZjRqK3F1V1lQMEZ6Y3VYMkpCNG5rdDlCemlPU09qVlBTMzlNaXU2ZS82OUtW?= =?utf-8?B?S2xqNTNSUnAzWm52QnpROVBGNCtYRDRDeGRCSHJxeFJuOXlLVWxJYmJjQ0Rk?= =?utf-8?B?WndCSUVoUEF5NmVOc3NNZng0aGlYZ1VMOThHVHZZak1YU3ZhM0ZDSjREN0hH?= =?utf-8?B?SmZ0ekNaUkRtSkNvSGR1VlR1VXhpTVhrNjdCbW5kSVVvMWU3VXNINlo4cGdq?= =?utf-8?B?MytzaTA5RXoyU2lPWkZJQWtFaXVwTW5xY3JLY3ZGYkVHekVCZ0FPQ0lwb1JY?= =?utf-8?B?Mzk1ZVdvNldCZ1M3RjZLeStraDVsNUtnblZzOWJyZFQxSU5ETElBWEhVc29S?= =?utf-8?B?UEgrdHA5bDAralN0RUJCMEJMeWZ0TGM3Mk9KWFR0S2ZHbmZKQ1hSc1FLc0xQ?= =?utf-8?B?TEVweFNMMGRFaDlRdzYrL3pCbDVSbmVvNUxOTVlkWHpIRFpRaURSSEFCU0ZU?= =?utf-8?B?Y0swa2E1STBUdVpsbmJHdm5WdEsrNzBzSHppNEowT28yU1FDM0UwdFBhelpK?= =?utf-8?B?OTBubDZOTlpubmlGTkVqaS9JV253Q2RQeWR4b2tMa0xmdm1maVk3TTM2QnRG?= =?utf-8?B?WlJUMW5SbjhUdHprZkpZQzV4Z2RINFRSN1hrMDczVXFPRVgzQm1XYTVqekpJ?= =?utf-8?B?cFd6VGZKeGIrVUtraEg5U1FETWJNTnp2YlZyVGM2Um5Feld1RHlQYk5Za0Ru?= =?utf-8?B?bDRvZ1dZT0QwbnVLQ0EyejdlZ09VeVBUUURTeDduNTRCeHIrblBQWlo4Y1JH?= =?utf-8?B?RWpTMUNrYk9vNEZ6cUJheHN2bnR5S1NMd3NXaHpuUllWRjNTM05vVytqVzRq?= =?utf-8?B?ckQxT1Y2aVBxdm1pZzc3eTJQOFZ4a1hPTWcrNnV0M1Rad2NjYk9ZTzhXc090?= =?utf-8?B?TWVaa2Fkc3dOazF4QXFodHFJTlZTMkxGMlBTVUZrZUtqNVNtdUVETGlMN3JQ?= =?utf-8?B?WXd4SzZ0TCthUVo0ajBTUkl1VmMzcy8wVWw5RGM1NHpwRWpNL09tTlNCclJ5?= =?utf-8?B?L1ZNbVcyellKRy9Pc0J6N25BSDRWL243Z2NKM29zZXlBb1IxUFY1d0NzbWFS?= =?utf-8?B?d0FuOVNsNmFRVXdFeEQ1Y3VUbmtiYmxReUZVMEN1cjM1RjlSajV4M0IrYVhB?= =?utf-8?B?NkcxVnFvZHdIVFZzMTFGTGJsb0xKci9ldmd0dEVoZDRxS1k4OFRNTEtmWlRT?= =?utf-8?B?RWZjZFM0TXltUk5sWkRoR1VwV2dTYUUweTZjenljVUdkeUYvL2JOTTI4NjJj?= =?utf-8?Q?EllY=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?am05MFh3ckMyQm1yL0RSSExqV0JJcEJVcnFwYWE2dS9IcC9vK0xJOGR6SCtl?= =?utf-8?B?aDdjNkpLUjZqdFlUdmViQzhaMWRVWGtaaUNyb2s2Z0dBQmNCTkp0SU5QVUhy?= =?utf-8?B?YlQ1a2FTQWJWOHphS3Z1KytHdWRURlV1UTNvd3FscE8wczZvL2FOU0RIblJJ?= =?utf-8?B?TTFUUldEM2d6ZjY4YUQ4ZDJ4cHNTd0tTcFd4eGFtdUNaVGpEbXJJMUptVGhF?= =?utf-8?B?ZVBKUlVWWkhXMEcrYzBYbmFJeUtBMS9kWXlLemlaZU8rSCt6aWhuRHB0VXV2?= =?utf-8?B?dlFvemg0M2xMQnhOYWR2MFBKR01UaWQrMXluOWYySEhKaUhqNm9ITVBCa2Rx?= =?utf-8?B?VVRjWjJUZnJ3WkZQOTZKdy9YN1BxV0t0WWF0YjBjNWdrK0lIaU8wMFZRS3hQ?= =?utf-8?B?SmNta1QzSTNjK3g3anR4a3V1NU1jWnFtY1E3ZlVzbHFrWWdrSXVHak56T1h6?= =?utf-8?B?cWd4dnJ1QmZoNUNUcHUxWTVpQjhFcjRJM0paODFQY0xiZUtxd1BjeFA0endH?= =?utf-8?B?RjNYTmpCN2w1RXBZVjBpZVpUQzRhVEp0cDJaSDk3aVI5dUZ4WEw2c2xwRldK?= =?utf-8?B?K3V2eHdLV1RpNTQ1V1JlNk1ua2ZiOENMT3dOOHhxdnEzc25JMGx5cEpkb2FB?= =?utf-8?B?bERMMzB3cVdKT0xTZVM3K3FSeDhOVEkrRS9pankrRUlpbXlhcVljNlhwNUJa?= =?utf-8?B?eU1tNlIvVmVnTDVabU55dllxY2c0eVl6Rkc5T0FGbzRka2M2Vmk2alFyQk5V?= =?utf-8?B?YS9SdmxpbjhwVlQ3QTVuZmlHWEJpSytzNkpmVGFPeXNZYzN3K01CdVlPRCsx?= =?utf-8?B?dlpzRHp6VDA3cVdHNXo2eEc3TWsvdC95SWUwdVg4R2lVa0tubFQreDNENjZm?= =?utf-8?B?bkFZRDZNK0xGZWFOMmdpMkZMVEorakJvdExTYXI3cHBBQVlhQW04OTNtVnNv?= =?utf-8?B?ZzhLSlZRaENCM1BydldGOWRSNnBUM3ZEY1l3eWpJRldhY0FYVFNLVkkxZmJP?= =?utf-8?B?L3kwS3AwcDA2b1psdXFHU08xekRmbHJlRmNaNnYydXpYMXVZM2U3NXI5ekZz?= =?utf-8?B?RlpMbE05V09mL0hDUkpnM1hTN3pseC9LbDJlcUQyeWVqdlJPTDFoelNhU3Z1?= =?utf-8?B?TW5XeWZVaVlMejZ6THZXSmlLV1kzdE1yd0RndWNTbG1vaDRpaHVVaXcxNEdQ?= =?utf-8?B?WC9Lem1KYWVNRWxPN2lHNnZpVVJVWGxYQVRoVndTUUJBUG8veWt5c2V0NFJQ?= =?utf-8?B?aU95aXlzOW80NkR0SmFyczRXWEpJejk5b2QyTVBZSmVCRWVQVjVVbU5zR1Ax?= =?utf-8?B?RWF1WDM3UmRtQ1U3VkgyM0NJQ3RQanFNSnlMa09EWE1Nd0xGZzNRNmlTbHlo?= =?utf-8?B?ajlVc2dGaTJ6Y09FcUx1Z25ZYmRlcE01ZUNLNXdrUERhckRNUTZOc0ZQdmZC?= =?utf-8?B?SG9CRlBHTEJmeTFWZTFhYlhSRSsvSlVQNW5UUHRFcEFCS3dGMFBoYlNFYVBm?= =?utf-8?B?dEFjNFdlY1RPZlI3NGNqQzR3UmorUXUyMEVwUnlsdldXeVpWZDYvV0tlaTNa?= =?utf-8?B?d1UzdDlqZnBlTEIvQ1RXVllNcmQyMTVOTkxxSlg3TE16RVl0eEpTYVdwMENn?= =?utf-8?B?RTdBWVRFTUNqQUhPbDZmZnJTK2NXaGlqV0NkMlg3RG1MeTNYbEs0LzhwYmN1?= =?utf-8?B?eDVxeDB4V0o5NHJVQ0w3T1ZlMU9UcWxaR3J3UnNhcGx3QWFhNGFOcnBnVEFS?= =?utf-8?B?SmpERyt0bXVZU3ROblk1R1RxblR0MFV4MWxycXVwQzJLazRzUi9nL240a2pn?= =?utf-8?B?cHlTVjRFSitGRUZkL1BFU0t4NUtaZkVOUXpwa3NuQURrQ2lTeXo3bExPYVRW?= =?utf-8?B?SG5LZ3c2RldYUXM4MWhrblRHVDM5NEFlTWoxdnFXY0lZYlJoblBsdlBxRlJO?= =?utf-8?B?V016MHlKdVFsd3BnYUhwSlEzNXloSHBGWUxLdExhZ0hWR3ZzSndHaEF4cjYy?= =?utf-8?B?SURUSk5lc3JIY2I5UW9JWnRDeGNXeGNBK1kxMjl4VDNqdlY1VUdtc3ZaTkNt?= =?utf-8?B?N3FoWlBOeW1nckx5d0NSTnAwV2plakQzSUhFQk9RcEgzSVJ6VGJlYkcrM0ph?= =?utf-8?B?bDVveWo5SSs1MjRtMnFENHBLRWF0RmxnMUxPUm01M2JKYk1DR0FVVEFwaVY5?= =?utf-8?B?RGhJa2syK2NXR1E3cENYejQzOHc1SXR4MXpROUNtZVp0UnJoZ0ZvcGw5cEtq?= =?utf-8?B?ck4yeWVLak9xNlZkMnFYSmovVS9rRXFZQjRNZDZ0dHJtZktzN1BPakN0YVEv?= =?utf-8?B?eUMwL3ZJTGtCOEpFK1JOZlNqaW1tRERYQjVpbXpDNEdhUGFqN0hoQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 873eb92b-073e-4965-fbe0-08de59a9ab7d X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 11:30:39.6592 (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: 7QosyKAJu0GhLL8hbMFRVkxMhCR6OsoepQTdf/2J11wwgjdcxTUNKm8JGxHXipA3axpjnVI9Ujk+n+ETH9yptA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DSWPR03MB989131 On Thu, Jan 22, 2026 at 11:15:49AM +0100, Jan Beulich wrote: > On 22.01.2026 11:10, Roger Pau Monné wrote: > > On Thu, Jan 22, 2026 at 10:28:51AM +0100, Jan Beulich wrote: > >> On 22.01.2026 10:18, Roger Pau Monné wrote: > >>> On Mon, Nov 17, 2025 at 03:39:30PM +0100, Jan Beulich wrote: > >>>> When this was added, the log message was updated correctly, but the zero > >>>> case was needlessly checked separately: hpet_broadcast_enter() had a zero > >>>> check added at the same time, while handle_hpet_broadcast() can't possibly > >>>> pass 0 here anyway. > >>>> > >>>> Fixes: 7145897cfb81 ("cpuidle: Fix for timer_deadline==0 case") > >>>> Signed-off-by: Jan Beulich > >>> > >>> Acked-by: Roger Pau Monné > >> > >> Thanks. > >> > >>> Similar to the previous commit, I wonder whether it would make sense > >>> to add an ASSERT_UNREACHABLE() if that error path is not reachable > >>> given the logic in the callers. > >> > >> That would mean > >> > >> if ( unlikely(expire < 0) ) > >> { > >> printk(KERN_DEBUG "reprogram: expire <= 0\n"); > >> return -ETIME; > >> } > >> > >> if ( unlikely(expire == 0) ) > >> { > >> ASSERT_UNREACHABLE(); > >> return -ETIME; > >> } > >> > >> which I fear I don't like (for going too far). Even > >> > >> if ( unlikely(expire <= 0) ) > >> { > >> printk(KERN_DEBUG "reprogram: expire <= 0\n"); > >> ASSERT(expire); > >> return -ETIME; > >> } > >> > >> I'd be uncertain about, as that needlessly gives 0 a meaning that isn't > >> required anymore in this function. > > > > Hm, OK, I was under the impression that both < 0 and 0 should never be > > passed by the callers. If expire == 0 is a possible input then I > > don't think the ASSERT() is that helpful. > > Oh, so you were after > > if ( unlikely(expire <= 0) ) > { > printk(KERN_DEBUG "reprogram: expire <= 0\n"); > ASSERT_UNREACHABLE(); > return -ETIME; > } > > (perhaps even with the printk() dropped)? That I could buy off on, as NOW() > is expected to only ever return valid (positive) s_time_t values. Yes, that's what I was thinking off, but your previous reply made me think there are possible cases where expire < 0 gets passed to the function? If that's not the case, adding the ASSERT_UNREACHABLE() would be my preference. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 22 11:44:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 11:44:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210856.1522448 (Exim 4.92) (envelope-from ) id 1vit7B-00015H-C6; Thu, 22 Jan 2026 11:44:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210856.1522448; Thu, 22 Jan 2026 11:44:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vit7B-00015A-9E; Thu, 22 Jan 2026 11:44:41 +0000 Received: by outflank-mailman (input) for mailman id 1210856; Thu, 22 Jan 2026 11:44: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 1vit7A-000151-C1 for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 11:44:40 +0000 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id bad5e380-f787-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 12:44:37 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 6E13440E02E6; Thu, 22 Jan 2026 11:44:35 +0000 (UTC) Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id c9X8eFFdOq-3; Thu, 22 Jan 2026 11:44:31 +0000 (UTC) Received: from zn.tnic (pd953023b.dip0.t-ipconnect.de [217.83.2.59]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with UTF8SMTPSA id 1169040E00DE; Thu, 22 Jan 2026 11:44: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: bad5e380-f787-11f0-b15e-2bf370ae4941 X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key) header.d=alien8.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1769082270; bh=rZtylzp0qFkAcv+z+2JtsaoyVGWifq81W5X/Ip6miJc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UybqXXvpCysjUW5YuOLTI9itbPaqwV+kzNUhng7iNTwX6hDULT5M9y7IbtcWXh7b0 MH9XvNYf1FZEvPZwBrMsVSGmYAbPbW1H0LGjtKdROfqad4cVS8TS5rsT47T9pD6f/W dlZUlfpcQs5LonbzMfu+k1JSNgE9V9tXIcdgZLOfz3JHuz2k5wkrAPmWxCpcI/PdxH ZWNOH54TdhGWa4c/PcPeKI0cxszFx6GGiCph2WJALcCt+g0abq/1kRDoMK64tLtl6S xvVqpWdBnrL6YUT0xcbehVj4Zdgt048du/Q9Q6oPaFoIsLB/BArthY1VUUOBBwnONn 9MShccXfa0NTt7y3PxyR9H3NswWF0ewXzCgt930ZneBbWc4hGQeojtrsQFwcguUi6I SLW9D/LgMdI7/DNmsT6rQg2yQOjqz92GdiMmX2J+nR6MI/7/rzcuIJv3ZhMx8qxawS C2r6nZ8cx3FTD1ayfABapmh9Jh1ur4L2OPn4Zw4aWgbhzAOS6Z9IY4GThc952vM2Vf M6MrCLec8fKnPvVfx+R0zXZTpgmeKVIwgVFHvtBMyDhUQ5lhRz2FTzwKDOW+NgVKZn 4ibSeuFziIXsvkDmZCZcOT2YtD/oKCqR+vAisRULjy0C3wmaY/33wFDLNOB/WVtcbo NQHYImsorZNzYeivc+9HTOzw= Date: Thu, 22 Jan 2026 12:44:09 +0100 From: Borislav Petkov To: Hou Wenlong Cc: linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Boris Ostrovsky , Ard Biesheuvel , Thomas Huth , Kiryl Shutsemau , Uros Bizjak , Brian Gerst , xen-devel@lists.xenproject.org Subject: Re: [PATCH] x86/xen: Build identity mapping page tables dynamically for XENPV Message-ID: <20260122114409.GBaXINiSQrMS994TkE@fat_crate.local> References: <453981eae7e8158307f971d1632d5023adbe03c3.1769074722.git.houwenlong.hwl@antgroup.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <453981eae7e8158307f971d1632d5023adbe03c3.1769074722.git.houwenlong.hwl@antgroup.com> On Thu, Jan 22, 2026 at 06:06:14PM +0800, Hou Wenlong wrote: > After commit 47ffe0578aee ("x86/pvh: Add 64bit relocation page tables"), > the PVH entry uses a new set of page tables instead of the > preconstructed page tables in head64.S. Since those preconstructed page > tables are only used in XENPV now and XENPV does not actually need the > preconstructed identity page tables directly, they can be filled in > xen_setup_kernel_pagetable(). Therefore, build the identity mapping page > table dynamically to remove the preconstructed page tables and make the > code cleaner. > > Signed-off-by: Hou Wenlong > --- > arch/x86/include/asm/pgtable_64.h | 2 -- > arch/x86/kernel/head_64.S | 28 ---------------------------- > arch/x86/xen/mmu_pv.c | 9 +++++++++ > 3 files changed, 9 insertions(+), 30 deletions(-) > > diff --git a/arch/x86/include/asm/pgtable_64.h b/arch/x86/include/asm/pgtable_64.h > index f06e5d6a2747..ce45882ccd07 100644 > --- a/arch/x86/include/asm/pgtable_64.h > +++ b/arch/x86/include/asm/pgtable_64.h > @@ -19,10 +19,8 @@ > extern p4d_t level4_kernel_pgt[512]; > extern p4d_t level4_ident_pgt[512]; > extern pud_t level3_kernel_pgt[512]; > -extern pud_t level3_ident_pgt[512]; > extern pmd_t level2_kernel_pgt[512]; > extern pmd_t level2_fixmap_pgt[512]; > -extern pmd_t level2_ident_pgt[512]; > extern pte_t level1_fixmap_pgt[512 * FIXMAP_PMD_NUM]; > extern pgd_t init_top_pgt[]; > > diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S > index 21816b48537c..85d4a5094f6b 100644 > --- a/arch/x86/kernel/head_64.S > +++ b/arch/x86/kernel/head_64.S > @@ -616,38 +616,10 @@ SYM_DATA(early_recursion_flag, .long 0) > > .data > > -#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH) > -SYM_DATA_START_PTI_ALIGNED(init_top_pgt) > - .quad level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC > - .org init_top_pgt + L4_PAGE_OFFSET*8, 0 > - .quad level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC > - .org init_top_pgt + L4_START_KERNEL*8, 0 > - /* (2^48-(2*1024*1024*1024))/(2^39) = 511 */ > - .quad level3_kernel_pgt - __START_KERNEL_map + _PAGE_TABLE_NOENC > - .fill PTI_USER_PGD_FILL,8,0 > -SYM_DATA_END(init_top_pgt) > - > -SYM_DATA_START_PAGE_ALIGNED(level3_ident_pgt) > - .quad level2_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC > - .fill 511, 8, 0 > -SYM_DATA_END(level3_ident_pgt) > -SYM_DATA_START_PAGE_ALIGNED(level2_ident_pgt) > - /* > - * Since I easily can, map the first 1G. > - * Don't set NX because code runs from these pages. > - * > - * Note: This sets _PAGE_GLOBAL despite whether > - * the CPU supports it or it is enabled. But, > - * the CPU should ignore the bit. > - */ > - PMDS(0, __PAGE_KERNEL_IDENT_LARGE_EXEC, PTRS_PER_PMD) > -SYM_DATA_END(level2_ident_pgt) > -#else > SYM_DATA_START_PTI_ALIGNED(init_top_pgt) > .fill 512,8,0 > .fill PTI_USER_PGD_FILL,8,0 > SYM_DATA_END(init_top_pgt) > -#endif > > SYM_DATA_START_PAGE_ALIGNED(level4_kernel_pgt) > .fill 511,8,0 > diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c > index 9fa00c4a8858..7d77c233002b 100644 > --- a/arch/x86/xen/mmu_pv.c > +++ b/arch/x86/xen/mmu_pv.c > @@ -105,6 +105,9 @@ pte_t xen_make_pte_init(pteval_t pte); > static pud_t level3_user_vsyscall[PTRS_PER_PUD] __page_aligned_bss; > #endif > > +static pud_t level3_ident_pgt[PTRS_PER_PUD] __page_aligned_bss; > +static pmd_t level2_ident_pgt[PTRS_PER_PMD] __page_aligned_bss; > + > /* > * Protects atomic reservation decrease/increase against concurrent increases. > * Also protects non-atomic updates of current_pages and balloon lists. > @@ -1773,6 +1776,12 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn) > /* Zap identity mapping */ > init_top_pgt[0] = __pgd(0); > > + init_top_pgt[pgd_index(__PAGE_OFFSET_BASE_L4)].pgd = > + __pa_symbol(level3_ident_pgt) + _KERNPG_TABLE_NOENC; > + init_top_pgt[pgd_index(__START_KERNEL_map)].pgd = > + __pa_symbol(level3_kernel_pgt) + _PAGE_TABLE_NOENC; > + level3_ident_pgt[0].pud = __pa_symbol(level2_ident_pgt) + _KERNPG_TABLE_NOENC; > + > /* Pre-constructed entries are in pfn, so convert to mfn */ > /* L4[273] -> level3_ident_pgt */ > /* L4[511] -> level3_kernel_pgt */ I obviously am very much in agreement with the arch/x86/kernel/head_64.S hunk, removing all that gunk. Provided there's no some gotcha in that change which Xen people would hopefully point out and the pagetables look the same: Acked-by: Borislav Petkov (AMD) If people want me to take it through tip, just holler. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette From xen-devel-bounces@lists.xenproject.org Thu Jan 22 12:10:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 12:10:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210880.1522478 (Exim 4.92) (envelope-from ) id 1vitVw-0005D0-MH; Thu, 22 Jan 2026 12:10:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210880.1522478; Thu, 22 Jan 2026 12: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 1vitVw-0005Ct-Ja; Thu, 22 Jan 2026 12:10:16 +0000 Received: by outflank-mailman (input) for mailman id 1210880; Thu, 22 Jan 2026 12: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 1vitVv-0005Cn-K5 for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 12:10: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 4e14e1bd-f78b-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 13:10:14 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id EDB544431B; Thu, 22 Jan 2026 12:10:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C3CB5C116C6; Thu, 22 Jan 2026 12:10:11 +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 8B9533808200; Thu, 22 Jan 2026 12:10: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: 4e14e1bd-f78b-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769083811; bh=XngWy+6ViL5NLbBW8pb6CJtphxGdqQrHvhYeab9cySY=; h=Subject:From:Date:References:In-Reply-To:To:Cc:From; b=q++0p+RqQASndA1LmpBwQqbWmWBcETme7USzJB/kbWukUzdsEZSB9dug35CdZPEok r57Y2kbptHXd7Ek92q1t8KCvK1/606dlCvXXeslRBAEWwH04cPwu8ENuSXsgl9CfsZ 3Juj3wjikSq+kydHYAM9OqYUdQuPT04G6bKZkNb7gg3lwhEFwwlZtRDUcxJ+50HtqF zcfxBEtGbbZgDTt3YJ+BySCECSPBNdR6CJcGw90PhYfP7dG8qyZEw1narbFmiAlajU Sry8mIDf5FeNw3Mjp2YEHmrTMgsYBQVQqgUj4v/8tKjcZiZK4fd+kqTJ6m/wbKFrbJ O+BG9VaepTNmA== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [PATCH net-next] xen/netfront: Use u64_stats_t with u64_stats_sync properly From: patchwork-bot+netdevbpf@kernel.org Message-Id: <176908380810.1694846.13399878058009113913.git-patchwork-notify@kernel.org> Date: Thu, 22 Jan 2026 12:10:08 +0000 References: <20260121082550.2389249-1-mmyangfl@gmail.com> In-Reply-To: <20260121082550.2389249-1-mmyangfl@gmail.com> To: Yangfl Cc: netdev@vger.kernel.org, jgross@suse.com, sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Hello: This patch was applied to netdev/net-next.git (main) by Paolo Abeni : On Wed, 21 Jan 2026 16:25:46 +0800 you wrote: > On 64bit arches, struct u64_stats_sync is empty and provides no help > against load/store tearing. Convert to u64_stats_t to ensure atomic > operations. > > Signed-off-by: David Yang > --- > drivers/net/xen-netfront.c | 24 ++++++++++++------------ > 1 file changed, 12 insertions(+), 12 deletions(-) Here is the summary with links: - [net-next] xen/netfront: Use u64_stats_t with u64_stats_sync properly https://git.kernel.org/netdev/net-next/c/a2ba9902e4b9 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html From xen-devel-bounces@lists.xenproject.org Thu Jan 22 12:12:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 12:12:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210896.1522488 (Exim 4.92) (envelope-from ) id 1vitYD-0005hv-1N; Thu, 22 Jan 2026 12:12:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210896.1522488; Thu, 22 Jan 2026 12:12:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vitYC-0005ho-UP; Thu, 22 Jan 2026 12:12:36 +0000 Received: by outflank-mailman (input) for mailman id 1210896; Thu, 22 Jan 2026 12:12:35 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vitYB-0005hi-6a for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 12:12:35 +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 a1e9fb5e-f78b-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 13:12:33 +0100 (CET) Received: from BL1PR13CA0254.namprd13.prod.outlook.com (2603:10b6:208:2ba::19) by DM4PR12MB8569.namprd12.prod.outlook.com (2603:10b6:8:18a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Thu, 22 Jan 2026 12:12:27 +0000 Received: from BL02EPF0001A100.namprd03.prod.outlook.com (2603:10b6:208:2ba:cafe::f6) by BL1PR13CA0254.outlook.office365.com (2603:10b6:208:2ba::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Thu, 22 Jan 2026 12:12:24 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL02EPF0001A100.mail.protection.outlook.com (10.167.242.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Thu, 22 Jan 2026 12:12: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; Thu, 22 Jan 2026 06:12:25 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a1e9fb5e-f78b-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=D8ScAi3WN6Wjzw8BZEFmGsdfV9ogBJEifUD+X0zQjb+v2PYG8q1u1EAtRGC3N9eIEEaMPz2Vm8xO30vLBMfiQQ7MIZMGrBl6NVPi4WG5XeQ4+oNqAV1A1YPww/PWZoZq/fLM5vtkHkNWLKB8+GelMwCpTZfwouDonigykIMq8MUMsN7V+cfhIZzpFueEYYC5lKdHi74kIuTwqW75XFQAnVkGXlLHV2rRK723g/2ylEDj2TTBm84DaGUz2AsqezYvTxskcuMUIoB3Yku7FiCDRtfinqa1tgcXVsu+TyTJpDVdYPE1OVrBHR9O5C9rCU/G7JZKZk3v5B8cD8GibWdbGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iDr0xrEgeEMieZpD7AE89s8wHRx3himgYI7UM5k53uw=; b=ODHj4ENCAaVpZzDPZMboA2TDhH+ZGXDNbF30ef/zvE/huf488JK+lchrNfKnaqhAvsNvHm+PjfUbh85pKrcsSm3Rn3IUgv+ukCP8ukGc5YQATjrx/SjT0bCtVJIXKS+ZVEoDlPBl5cZFyzDWN5jrd92TMD3E+czXazjHjfuwhvmIY8vMnQ1DyOleiwh6xOHOx1FUCnL//7Tkn+F2Tknt31tVXGQsZk1+mtyCZSiesvgUBKlS7+t2GCaHiMgXw90Hkn5CRe7ZB0u4raQPfxTDBkOdmwNXuKQE6MlyaRui38yg1NQG9IMBEdgYxLzLM2ZnxcGeZP9oNDWXDjpHpnHBPA== 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=iDr0xrEgeEMieZpD7AE89s8wHRx3himgYI7UM5k53uw=; b=DyTQr2vBjMRlKhwzuHfKf8fkFcqQf8zhhb+2fKqChYkUJHFlqtpAOiai9nxlofUDw4ozaANmo0Tp5Qt8XiWbeG8VrGQBKcvnIWyfPo78GcBCmkplZ7HA49OhHeur4CQhyIoD5njpC7r+zR00LTp7pmC+FPVQzo2ouOt1FnJQ3KM= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 22 Jan 2026 13:12:24 +0100 Message-ID: CC: Andrew Cooper , Anthony PERARD , Michal Orzel , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Subject: Re: [PATCH v5 1/2] xen: Allow lib-y targets to also be .init.o From: Alejandro Vallejo To: Jan Beulich X-Mailer: aerc 0.20.1 References: <20260121154757.44350-1-alejandro.garciavallejo@amd.com> <20260121154757.44350-2-alejandro.garciavallejo@amd.com> <526ef477-0730-4e22-a82f-4c598ad78e0a@suse.com> <7304f5e0-f55c-45c5-ae4c-3d3adc53a0b3@suse.com> In-Reply-To: <7304f5e0-f55c-45c5-ae4c-3d3adc53a0b3@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: BL02EPF0001A100:EE_|DM4PR12MB8569:EE_ X-MS-Office365-Filtering-Correlation-Id: 5fac3d5a-4f3f-46a6-51a5-08de59af826b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?VFgrQ3JZbTZNd3JmWm1hLzgxWnFla3laS0d4eThZLzlpdG5nVjN5Vm96RXl1?= =?utf-8?B?SldNU3VtaUFMbjMxaldGeERLcVlNZWQ4TklGU2xoT3BiQkJuWjRiR1VFUDEx?= =?utf-8?B?SW13VEZ2R2JNekJVeDRoOExrbTJTY3JUNklsNlA1Y0dWcTc0UWYxckQxaE9q?= =?utf-8?B?VS9oQUYvUFhWcXNEWm9qSlhRK0FvRjN0OUhnQmV6aFRrd0RpZk1teTg1OTlE?= =?utf-8?B?ZUFRU3RiQm5KUy8wMCt1TGExL0hjRlk0QTF4TEs4NWxibXovajZYSVVSWnUy?= =?utf-8?B?OElzZmZNdVgwKzVxZS9Sb2lscXB4ZjEwYm82YlZmVEdHdFBwTk02Z2ZPQy9F?= =?utf-8?B?czZvaURPVDl5ZlV0STQrNnBVTjM5ZUhvWWp0bUtwQk5OMkJKTWN0ZU5kdjVD?= =?utf-8?B?ak5CcGhhQWVhM0xHQWJOTWZuUnVrenBtUTVJSnV0MnZzVWdzNmwyRDhOb3F2?= =?utf-8?B?YXgyQWJLdEptQU5ZUWJrUGdLWlJpRll6akd6djMyWmlUaTNoTC9ZN2tLV1FH?= =?utf-8?B?bTQrWGhrM003Ykx5TEZKM3lFb3JrNFg4MXBndEovdFZvNUN3RVBEclJDT0JT?= =?utf-8?B?SVU0Z2oySStVazA3SUtSOUFHT1lTQklQL3IycXVxdEpjeGpZTEJDU1dDcWxu?= =?utf-8?B?SXJZU0g4TjlNZUpFUVNzOWozWm9mTTZlaWJWU2hUQkllSEZ1NlZwbnpsdnpw?= =?utf-8?B?aXp4MWJ6MzRGTUQ0QXc0NFZrZVZGS3BQc3l2ejFJWGdPM0Zjd0hkVERaaDdU?= =?utf-8?B?ak9sQ2FsV2p4WVkrZWNiWHRtL0ZwUE5GdGRpWSthb1ZZeEo4YUtWMnIwVDkz?= =?utf-8?B?V0d0TEVIYktmMUxONVJwZmRHOE9MeDJqcWFJV29HckY4c2Y0QUc1VmlLMTB2?= =?utf-8?B?ZUM3YXY0aTBRd2J6VkUxTW9vaUlBOXlnOElnRFhMTksxMFhhVmdWYmRZWWt4?= =?utf-8?B?TnBYZWlmVlJGWFNvZHI3QUVROTBtRkN3ak1yRStCemUrOXd2VXdISUsydWxv?= =?utf-8?B?cmRuSmRFN3k3MXF3ZW03eEI0d0VqQS9aMGdVWE5sRTRhTm9UenZzOVZPdFFP?= =?utf-8?B?NEJVL3BjMS82Tk42NGVOTlpGVUxnbWdQWktMeGhCZXVRc2w4dm5qK1pzR0F5?= =?utf-8?B?d0RIanhqSjdTbWtQTDkzRjN0TjFvSzJEWUg4ZVNFUjZ2Ukx3emM4NTlwK25D?= =?utf-8?B?Z0l6QmxDd0FiQ1EzQTdmN3pxQUtqMWphejE1c3pnR21CU3VRa29aUUVFeDZH?= =?utf-8?B?aGE4UElhZ3UwVHZIaXFtTjJ0b3VnVVR3c1U4SUtVQjFQMWVObXNOSU43Ny9Q?= =?utf-8?B?eDNQRE9jM1g4TXdkRi9veEZWTGJ6SFFUQmxlbjd3VTF1WVlmNGw3NG5kd1g4?= =?utf-8?B?Q0wxK0d5VFAxdEs2R2RCOERLcjZwSER0RklOVitJNDQwL3duQkQwNHVKWTFm?= =?utf-8?B?UVBqRDJtdW8xcGtEME9POTNkU3NOdm1YMnU4WUpoUWZlNjk0V1ZmTEVJVHFB?= =?utf-8?B?RExLZGZ2cDdVM044RXVrck45UU5zOUxZSzExZ2xCUFgwQm45Wi8vaG1qRXgw?= =?utf-8?B?VzdtRjFRTyt5d0pybTVCY25HcTRBQUk2SHh3UHBDN3hHZTVqRFFLSG1kVmhH?= =?utf-8?B?ZlpZYVh5UWRLSGltdCtkTFczVUpiUXBZUnRiZElKakh3aE85WHVha1ZXNnlF?= =?utf-8?B?a0NPZXdNSUhrb252SGg5S0I2NW9YVDd2eUVyamFueEFkMUJqMDMwL0ZqZnhn?= =?utf-8?B?YkJwditqSmRYblZXMm9OcWhUUkU5QTMwaHg0d2UvR2NZL3dIYS9FeGtWZFl4?= =?utf-8?B?Rk9NdTloeWJ3dDZ2RWFUZHF1T0pwc2tORHZ3TEhCOC8xZTZGM2t3OG9uTUpU?= =?utf-8?B?SE9OSmxpbC9qNHBKWWxWeUw2WkoxQm5sekcwUXlVSGxkUDJwSDhrcEtmWktv?= =?utf-8?B?eGtGcFJSNkc2K2pCLzBMWDdhMlZEK1VKMkdZS25vU0F1cnptWUlkVmozWENj?= =?utf-8?B?N29KUUFaMjNuUm9FVWZnQ3JaWVJwcGpZSzQxQUlVWStkV09STVVsZi91SnBa?= =?utf-8?B?SGZmaDdXWllMNTVzUlc3UGNYUFh4UVc3ZmVuaGIwUXNwREVCUksvOU5nbTRa?= =?utf-8?B?ZkFnalZpdFlxU3RUYTRaZUZNSjZDK0p2aitWM2taR1NlRStxOFBEN1ExTWds?= =?utf-8?B?cnovUkxHd0R2NEpSdER5QmZDTHY5c3VvcmdzTDZnT0l6cEo5aWprbGNWMWtO?= =?utf-8?B?T0tGNi8zSUttZDRWT3lMYjhKSlZnPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 12:12:27.4968 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5fac3d5a-4f3f-46a6-51a5-08de59af826b X-MS-Exchange-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: BL02EPF0001A100.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB8569 On Thu Jan 22, 2026 at 12:04 PM CET, Jan Beulich wrote: > On 22.01.2026 12:02, Alejandro Vallejo wrote: >> On Thu Jan 22, 2026 at 11:01 AM CET, Jan Beulich wrote: >>> On 22.01.2026 10:49, Jan Beulich wrote: >>>> On 21.01.2026 16:47, Alejandro Vallejo wrote: >>>>> There's some assumptions as to which targets may be init-only. But >>>>> there's little reason to preclude libraries from being init-only. >>>>> >>>>> Signed-off-by: Alejandro Vallejo >>>>> Reviewed-by: Jan Beulich >>>> >>>> I can't tell (yet) what it is, but as per CI something's clearly wrong= with this >>>> change. Both xilinx-smoke-dom0less-arm64-* and qemu-smoke-dom0*-debug*= fail with >>>> it in place. qemu-smoke-dom0-arm64-gcc (no "debug") was fine, suggesti= ng it may >>>> be an early assertion triggering. >>> >>> Or an early UBSAN failure. I think ... >>> >>>>> --- a/xen/Rules.mk >>>>> +++ b/xen/Rules.mk >>>>> @@ -130,9 +130,9 @@ endif >>>>> =20 >>>>> targets +=3D $(targets-for-builtin) >>>>> =20 >>>>> -$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS-y +=3D -= DINIT_SECTIONS_ONLY >>>>> +$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)): CFLAGS= -y +=3D -DINIT_SECTIONS_ONLY >>>>> =20 >>>>> -non-init-objects =3D $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(= extra-y)) >>>>> +non-init-objects =3D $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(= extra-y) $(lib-y)) >>> >>> ... this is the problem: You're _adding_ library files here which weren= 't there >>> before. Why $(lib-y) isn't here I don't really known, but as per the CI= results >>> there must be a reason for this. >>=20 >> Apologies for the unintended breakage. I should've checked the baseline = for >> arm before ruling out this patch being the cause (it did fire in my pipe= line, >> but didn't consider how this could affect arm and attributed it to a spu= rious >> failure). >>=20 >> So we're neither doing UBSAN nor collecting coverage data from libs? Gre= at. One >> more task to the pile, I guess. Seeing how... >>=20 >> $(non-init-objects): _c_flags +=3D $(cov-cflags-y) >> [snip] >> $(non-init-objects): _c_flags +=3D $(UBSAN_FLAGS) >>=20 >> I'll try to clean this mess. :/ > > In the meantime, should I give your patch another try with that one chang= e dropped? > > Jan Sure, thanks. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Thu Jan 22 12:49:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 12:49:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210919.1522498 (Exim 4.92) (envelope-from ) id 1viu7B-0001Rd-GI; Thu, 22 Jan 2026 12:48:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210919.1522498; Thu, 22 Jan 2026 12:48:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viu7B-0001RW-Ck; Thu, 22 Jan 2026 12:48:45 +0000 Received: by outflank-mailman (input) for mailman id 1210919; Thu, 22 Jan 2026 12:48: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 1viu79-0001RQ-7d for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 12:48:43 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id adcf277e-f790-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 13:48:42 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by PH0PR03MB6431.namprd03.prod.outlook.com (2603:10b6:510:a9::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Thu, 22 Jan 2026 12:48:38 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 12:48: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: adcf277e-f790-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=sVkqCy5ROR0awHRARzHEuk+KVEAEgT7TGtgAgEcrj07TN3vXHPAOJvepp19xxaUO5UIx6aXgs6WwcS+peaInGZEEKdsTpuyUf21aaJN6TcL6+aujz6xq6GTbU8Ip1ZVkB1Gk7MlOubhV6MLgg9bh9c14wlPmhxq+Ph4hf12WpdjNxFXCd5/tlYPuLV9m//jufc1z9oddN3kYYAZe6hvja/pwEnNXGhNL7zDh8/3tthjmenSvQJLfdX9Mibg99dDz1bnqkqpxYsU1nQWFgGOC57/luShbK99FviHBq3Q6CMxePS7ZH1fQU9Zx/7aptTokHf4yDExCZHIXk/eVAMBaww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=T8CnykyKv1MBEKdGCYPN8J5Hpx0U3SeHZN6YJIEBc90=; b=IXLp1pSKqdF0DAQhNBmiuOQpabCuTGvvwTtmcd4ai+nAq+/ii/NaQYQWYmw/+NqJAnEmgSiQYjsdiA6Cssd9827LSIjP7jIkHRjYReddZcK9sgxoyHH8EliiC9HvNAFmyCOfcnSpFrEc4du6Rm+yMxfOymX1Ae7C/7O0WvomMKW4ubsergwNxr0MuYkQ0Uv7+1PqDN1ACEgpnLPWBF9/SFYVbOh5tBgFG/lPApVZrIDpf0fg92ksluTjhTlovUzQOLmZJaaIcq3I/nB8oMw7kvUG0+4Mz3rO/25vxqRtQUDTxQlDBXCuQ2LwCepZvHLgeB2jNhW4Tg+0AJXTD0o/yg== 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=T8CnykyKv1MBEKdGCYPN8J5Hpx0U3SeHZN6YJIEBc90=; b=dfap9WINqFysQbmvoGhNMLAqKKe4hmGLAkzNemRQYqY5V5ut8/sg0gBoTGXMM0zFU2rN7Gzzi8BrUfA6uLS2hDlGpWOPc/eGKvp4f8i/LEk58RE8Fd5IZOk92bC1rbjE2MTFKaBNEqszvcOd2+SHh5BMXxwDPsx1+COEa3ZZY40= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 22 Jan 2026 13:48:34 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH v2 2/3] xen/mm: allow deferred scrub of physmap populate allocated pages Message-ID: References: <20260115111804.40199-1-roger.pau@citrix.com> <20260115111804.40199-3-roger.pau@citrix.com> <7387457f-104a-436d-96ae-b70c77745200@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7387457f-104a-436d-96ae-b70c77745200@suse.com> X-ClientProxiedBy: PA7P264CA0438.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:37d::16) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|PH0PR03MB6431:EE_ X-MS-Office365-Filtering-Correlation-Id: ea0bd31f-b60e-4fae-03c2-08de59b4903d 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?WUsxS3dSVkJVc01OeTZ3Yi9KOUJJVE45clJWS2tiSEZVSXcycHNZVkozcFhj?= =?utf-8?B?K3dKbFdWTStiUGRPVkVJcDJBMEt0R2tXNG1NOW9VNTQ0N29RUUF1YW5tYzg2?= =?utf-8?B?bmRYRkRNeUFVbEt0ZWMyb2gxN2pWd0JLQnJqUGc4ZFZtTmVCZUNmekhQTmdO?= =?utf-8?B?QTZLZkxsR0hUWDBEN1lpa1J3N0t3QUovNHh5YUlJSkRQV0lvcXl4ZFREY01s?= =?utf-8?B?V0xya1hnVjQ2RlZHbXh6dnlFM3RNVlMxbFoveFg3dzZKT3VQYi9UbktnZG1u?= =?utf-8?B?eUpkbEQxTnFFUTNhalVaWmthR3B6UnRVc0NrcUJJTzE3M09ncHg5Wld0SEsz?= =?utf-8?B?clhZdkVPTkdGQnNvQ0F2aThkRDBQMUdWVDFQSGxXYjkzYk5sSi9vcC9nMzBQ?= =?utf-8?B?dm4yK28za045c1RiY1Jrb0hibE1QMnRtSUhiczhXRUp2SEV6MkxvTWd5eVhX?= =?utf-8?B?eTczM3NXbklNVkVFdVd0R3krbTF3WW1ndHl2R1RjTlplMTVFbjJEME54VVpw?= =?utf-8?B?N0R1b1Z6WUhLWWk1eXRZYXIyU3ZBMUloU1JmWlZja20yT1lGcGt5MEZVc2Fj?= =?utf-8?B?ZnpyRXl4cml0ZTNpZTUyVFBKN0t0aTBmcTlRZ3pDVTZpemhhQTdOdk1jdHlu?= =?utf-8?B?WkVWTklQQnpxdjJDQ0h2N2ExcUJQczJNSHo4M2RQYjdhcnpyaUFZcVJXcGE4?= =?utf-8?B?WnQvNTQrV0ZwQzlBVEJUeUpHZm96SHRXeTNIbDI1YldFMTBjS01sTzhJeDg5?= =?utf-8?B?eGdjU1hVTFZDWTdqb3lhVWdpeGl6aDBValZNUWsrYmR1ZVh4Ykc5eXl1UGcv?= =?utf-8?B?RzNSaWZDRGVSb0hER2Y5T3pIdHNaczZIVmYvQzg1MitFaCt0OC9mZUhWR0x5?= =?utf-8?B?RWRNWmU0dXZ5bVoyNVc0QkRoQ1lPeUhBREU5OGpyTElRK2JDMGlvdEFrM3pF?= =?utf-8?B?dFlwdVAzZjNlSTQxamcwWkdTR05CQXgySm5lTEUrUnpsdXlieVhwamZqU3o5?= =?utf-8?B?YVNFeERzVmN0Z0NBbzNlR2NDeXVwRHgvL2lXdkZFTE9qNys2OHZXMWZscXE0?= =?utf-8?B?UHc1WHdoeUM3ellUV0ZTTUE3M0lJWUJ0T3N2VkhOWWVGMEc5R1lZSWJhTm95?= =?utf-8?B?NXMvTlJyNFczQS9GNGxoeW16N242YU1RdUM0ZklHR2N5UHRXSnJ1OVRiYkM4?= =?utf-8?B?aGtndENZRnV1VElmR3k5aTJuc3FRK1BZOVR6WElmQWtnNVI3VjY0ZUtQU3FJ?= =?utf-8?B?VDBhYXN1aVVwNUNMbVlJTGordXlHRlUxcmhaMDh5VGxYRXVHSVQwc0picmQ2?= =?utf-8?B?U2FUWUU5QWMrMUhTODE5N0MvWHJMZERITDBrdmdNbDZhVWVjMUNpUnNSUDY4?= =?utf-8?B?akZwbUY1RlVaT0lPemhMWitia1NNZWxMUFp5ZjdDZTVheVNrazdURHY5WDlV?= =?utf-8?B?L2Z2M2JabjNlc2hhNzRkVTQwYllFU2xSOEVEdjZLWHBDWDZCSmVaQlVRSVZ1?= =?utf-8?B?dlpEUjFJb0NKZElzKzlkN1JEWjhxWGFKb3dDYVVHMFgzMWxHUXIrRjJHYkZE?= =?utf-8?B?bFBDUUg1TXIrczR3UGpiRnBYUHBQNmtHeElGdnlkSDJ6SWhCN09zRnR5SWw2?= =?utf-8?B?QmhleXBGck5hNWNNMVBhUEFaMUVYL0VseWVUSHArUlN6aDdWb0tmM2tiTno5?= =?utf-8?B?WEdVRU9nNnd1OGpHY3JrNWhjM0RsSE5jMWZKaXRjeTRwOVMzQWsvc3FUQmVo?= =?utf-8?B?cnlpTFNvblkxeTZZSzFRdDRnN0srNzlLQ1l4OWo2VnV4RDMza2ZHQzY1ZGsz?= =?utf-8?B?V2dXOTF2aW5HTG90NnI3R255dFVxV25LeDQzUHZyMHRFR29ySmN6am9KS3I5?= =?utf-8?B?TnlKODZJZFJVWTBHbkdmT0tTYk5LS29hUFRIV1pRZlhBMjRKaGNRbkYxTTZE?= =?utf-8?B?bk9paWpzRTcxWkpUSGVRMktWN1ErZHBBME84TzZSaHA0cWdZYzVwVHBPK3Ny?= =?utf-8?B?NnFrU3E2d1ZaUGd5MCtuNHdGdWF1NFJTeGJPM0lMT0ZsYWtxLzZadENUT2kv?= =?utf-8?B?ZE9UMUlDdXVZZy9GRlBxcFJ2dFkzMEdYL0tUZHRzeXR0REZEMzZTeWMxb1hG?= =?utf-8?Q?q4Vs=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RGVDS1VkajhIYmRhVjlDNnd4bE5JenAyVGdiZ1ZvVlgxbWp6ZkdrUkhSTmJx?= =?utf-8?B?aGdlVE9hUGRQY0FKQjVrWUFqR1hRdjBhd1JYd1pnRzFUcGwyNnZGS3dFYkU5?= =?utf-8?B?SEcyWm1LZmFUalk4T2ZyblNub08wekxFWWVHOHV3dFlNOVdTZVc1Nm9iMEgy?= =?utf-8?B?WXdTRGFvZTVkb0ozczJrcUdXYmFVcVJ0b0RKTlBTelRoZFQ3dFFobGwzRDZq?= =?utf-8?B?WHY1eVVReFplV1ZqOTA4ZCtSOXRNenBnckdwRkZxR2xJbVJWbDhjbDM2ckRk?= =?utf-8?B?aXB1d3RsdnBrVm83N3Q3Q1U2b3dqb0FWQTlubk9nMGRmcHJOUE9Ud2I5Qjdn?= =?utf-8?B?bVdmWEQzL3orUkcvMkdidU5BcGtMZk5DdDJoWHQ5OHc0YnRMUzRRcTkxMk5D?= =?utf-8?B?Q0VzTWxOSEZUdkQ4VXE5UE1JUzhZNlRFUDh5c3djaTVwTUFTSzQzSm15N09T?= =?utf-8?B?UDN2T2xoems2cGY2OHhkZ1ZkUUZqTGxITmlUSDN5UnB5TUp1UGdiQzZOdWZv?= =?utf-8?B?NWhzdmRMU1BkRFA5b2VKMnZyTlRZWXh3b1hvRnVyeXdnWFFQZlJIN2t1eDE2?= =?utf-8?B?M2VlUjBVQXdiVWNTcXFMQit6dDlTZmo2RXZuZHZHQ2ExYXQ5cjN4ZnN0bktk?= =?utf-8?B?UVhVN2svbE9qTGJtcFlaUjNLMmdyZ2hoWkgwUFVrR0RuZzJFdWRacnhLSHgy?= =?utf-8?B?bTZOd2hWMHR6S2FCMGdmZFlneTk5VHhPY09QQlpLS0QrZVdWUmppei82bHYv?= =?utf-8?B?OXdYRW1oeU1LdXlVa3RyZzdXWGZPRmtib2FjdExzYmNBbmo5RXpPUXh0Zmd3?= =?utf-8?B?c0NtTnRBOG9mSC9YVXorN1NFbUtwZ3VDaGVESnhYR1Z6M3BvQUZPQWJmYlVW?= =?utf-8?B?MFpETDdpKzVCM3BRQ01qckJ2Ti9aeWxWYVZTNFF5dWlTb092cC9IMGRlTE9x?= =?utf-8?B?b3l2OC9HNVBHQm92RjlBK0lxenlScFR5cjMxRDlFbjBCQUFWcm1GSnFHWHhP?= =?utf-8?B?c20rUXFzYUtGYlpXM3JPbkM3ZlRxTW1OQ1lnUWJYVFg2NVlwMjlET2VQbmFG?= =?utf-8?B?T0VVa1Y3cDk0b3AvMU96RlhNUXM2MnUwVWt2ZUlpbFV4ejRIZEZacnQ4RXF3?= =?utf-8?B?MXNya08yYkRaRnNoY3JqTzUrMzMyemdyR1pCS3ZtbURIbU9LUmROZXFWVlkw?= =?utf-8?B?ZjgwVXJhb1REbDZqSWY5Z21TckpML3kwRVRDRThFNDlod1h6ZTZDSzlKWXdN?= =?utf-8?B?WmJwbVhtWVFoMFFEdFdEZnZVbk1sOXRQWXVUblN0VDRxbjF0MVplbjg1NWww?= =?utf-8?B?QkFOVUU0dWVtRGI5c3h4MVZiaEF0TE1CMWl5eWxuWVZITUw2VjB3ajVNcE5m?= =?utf-8?B?cFNCV29hRTNUZ204ZjdSWTUwRFRGdmZRd2JWMWphQ1F6NDRxZEh5SFRSRmhD?= =?utf-8?B?S3VxeGtOaFJnY25jSEtKZk94NkVyZ2xOS1VvMHdZc3pxN2FJV3hUbTVZUXVP?= =?utf-8?B?bi95aHJSRlNaa0pVVEZDQ2swUTZwelg0MDlXUDc5WHh6ZGNsWUd2TVlzTEhs?= =?utf-8?B?VUM5VCt1SW9KMVdZNTNsbXF5eXFCWDRzNWJEYTZHVzM4OVNET2psOUhMV3gw?= =?utf-8?B?RlcrL0FHUGU2RGUzbVdvL0VJQ2F5UHU0cFRYN3FwT1NEUGZvTFd4NWo1T2tV?= =?utf-8?B?aEZ6NTFzUjJ3MjhBeXdsZTJDbnR2Z09KVzE3bGdQa1QxQUlJK0FzdmhTL0Iv?= =?utf-8?B?VHpuL3NtUmxLdUZKcVNXNUJNODQ4NmlpSkZEMS90OFlua0pQMVVkYmlGSDhw?= =?utf-8?B?WXdGUCtPT0ZWY1RFcjJLY3kzTHhCNzVaZjhZNWdOL1dRR3A4NkowaHhrejVG?= =?utf-8?B?YzFEbzJ2TFJNeGdkejVDb255YW5uRVdnUlNOSmt3Vk1oNzBuenFVYzE2cFdP?= =?utf-8?B?NEJUYkJ0bGx2UUhzcVNBMStxUWoxVlo0YmcydHRBOVB3QnR3VzdRaWhaQUsz?= =?utf-8?B?OW1pWHE4N1UzQUt5ZUw4cDkrdTJMamNnYjR3VHR0Y05JdlE0d3ptVThJK0dK?= =?utf-8?B?TzA5bnI2YVNrVWxiSnROQWRFUEs4cHE5WFdRWHNyQWd3YUowNXdLekk3eDNj?= =?utf-8?B?RnU5Uks3bk10TmR6b1B2NGZjUEs5KzBVQ0NYdjhVd2lTS0Fpc1VSWnBzSXlJ?= =?utf-8?B?bHlGTUNicG1LbGM1SmFHY1RKMHBhRGtjTTVTRDNjalVNZmtnSnBHdjlnRFRD?= =?utf-8?B?MENISFlSR25YbTlnMmhDZkx5UVVzeStJczRhc0hzSEJ0bS9FVEFYOENORG00?= =?utf-8?B?elFPODMxMDQ5RXRjSTNMYnlDQjhyNUJBUDVIR096MmRyY2VhR2xWUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ea0bd31f-b60e-4fae-03c2-08de59b4903d X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 12:48:38.4519 (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: X38PfrfOi3CN6eWwXh9c2InoBTH/kybfbmifdEDlhMrkKadVwxqvGOpXSVWwhn4yr04vm82fvo4b9hcSFayeqg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB6431 On Mon, Jan 19, 2026 at 02:00:49PM +0100, Jan Beulich wrote: > On 15.01.2026 12:18, Roger Pau Monne wrote: > > --- a/xen/common/domain.c > > +++ b/xen/common/domain.c > > @@ -722,6 +722,15 @@ static void _domain_destroy(struct domain *d) > > > > XVFREE(d->console); > > > > + if ( d->pending_scrub ) > > + { > > + BUG_ON(d->creation_finished); > > + free_domheap_pages(d->pending_scrub, d->pending_scrub_order); > > + d->pending_scrub = NULL; > > + d->pending_scrub_order = 0; > > + d->pending_scrub_index = 0; > > + } > > Because of the other zeroing wanted (it's not strictly needed, is it?), > it may be a little awkward to use FREE_DOMHEAP_PAGES() here. Yet I would > still have recommended to avoid its open-coding, if only we had such a > wrapper already. I don't mind introducing a FREE_DOMHEAP_PAGES() wrapper in this same patch, if you are OK with it. > Would this better be done earlier, in domain_kill(), to avoid needlessly > holding back memory that isn't going to be used by this domain anymore? > Would require the spinlock be acquired to guard against a racing > stash_allocation(), I suppose. In fact freeing right in > domain_unpause_by_systemcontroller() might be yet better (albeit without > eliminating the need to do it here or in domain_kill()). Even with a lock taken moving to domain_kill() would be racy. A rogue toolstack could keep trying to issue populate_physmap hypercalls which would fail in the assign_pages() call, but it could still leave pending pages in d->pending_scrub, as the assign_pages() call happens strictly after the scrubbing is done. > > @@ -1678,6 +1687,14 @@ int domain_unpause_by_systemcontroller(struct domain *d) > > */ > > if ( new == 0 && !d->creation_finished ) > > { > > + if ( d->pending_scrub ) > > + { > > + printk(XENLOG_ERR > > + "%pd: cannot be started with pending dirty pages, destroying\n", > > s/dirty/unscrubbed/ to avoid ambiguity with "dirty" as in "needing writeback"? > > > --- a/xen/common/memory.c > > +++ b/xen/common/memory.c > > @@ -159,6 +159,74 @@ static void increase_reservation(struct memop_args *a) > > a->nr_done = i; > > } > > > > +/* > > + * Temporary storage for a domain assigned page that's not been fully scrubbed. > > + * Stored pages must be domheap ones. > > + * > > + * The stashed page can be freed at any time by Xen, the caller must pass the > > + * order and NUMA node requirement to the fetch function to ensure the > > + * currently stashed page matches it's requirements. > > + */ > > +static void stash_allocation(struct domain *d, struct page_info *page, > > + unsigned int order, unsigned int scrub_index) > > +{ > > + BUG_ON(d->creation_finished); > > Is this valid here and ... > > > + rspin_lock(&d->page_alloc_lock); > > + > > + /* > > + * Drop any stashed allocation to accommodated the current one. This > > + * interface is designed to be used for single-threaded domain creation. > > + */ > > + if ( d->pending_scrub ) > > + free_domheap_pages(d->pending_scrub, d->pending_scrub_order); > > + > > + d->pending_scrub_index = scrub_index; > > + d->pending_scrub_order = order; > > + d->pending_scrub = page; > > + > > + rspin_unlock(&d->page_alloc_lock); > > +} > > + > > +static struct page_info *get_stashed_allocation(struct domain *d, > > + unsigned int order, > > + nodeid_t node, > > + unsigned int *scrub_index) > > +{ > > + struct page_info *page = NULL; > > + > > + BUG_ON(d->creation_finished && d->pending_scrub); > > ... here? A badly behaved toolstack could do a populate in parallel with > the initial unpause, couldn't it? Oh, I think I've forgot to refresh before sending the patch . I have those as ASSERTs in my local copy anyway. But yes, you are right, populate_physmap() is not done while holding the domctl lock, so it can race with an unpause. I will remove the ASSERTs. > > + rspin_lock(&d->page_alloc_lock); > > + > > + /* > > + * If there's a pending page to scrub check it satisfies the current > > + * request. If it doesn't keep it stashed and return NULL. > > + */ > > + if ( !d->pending_scrub || d->pending_scrub_order != order || > > + (node != NUMA_NO_NODE && node != page_to_nid(d->pending_scrub)) ) > > Ah, and MEMF_exact_node is handled in the caller. > > > + goto done; > > + else > > + { > > + page = d->pending_scrub; > > + *scrub_index = d->pending_scrub_index; > > + } > > + > > + /* > > + * The caller now owns the page, clear stashed information. Prevent > > + * concurrent usages of get_stashed_allocation() from returning the same > > + * page to different contexts. > > + */ > > + d->pending_scrub_index = 0; > > + d->pending_scrub_order = 0; > > + d->pending_scrub = NULL; > > + > > + done: > > + rspin_unlock(&d->page_alloc_lock); > > + > > + return page; > > +} > > Hmm, you free the earlier allocation only in stash_allocation(), i.e. that > memory isn't available to fulfill the present request. (I do understand > that the freeing there can't be dropped, to deal with possible races > caused by the toolstack.) Since we expect populate_physmap(9 to be executed sequentially by the toolstack I would argue it's fine to hold onto that memory. Otherwise I could possibly free in get_stashed_allocation() when the request doesn't match what's stashed. I opted for freeing later in stash_allocation() to maybe give time for the other parallel caller to finish the scrubbing. > The use of "goto" here also looks a little odd, as it would be easy to get > away without. Or else I'd like to ask that the "else" be dropped. Hm, OK, let me use an unlock + return and also drop the else then. I think that's clearer. > > @@ -286,6 +365,30 @@ static void populate_physmap(struct memop_args *a) > > goto out; > > } > > > > + if ( !d->creation_finished ) > > + { > > + unsigned int dirty_cnt = 0, j; > > Declaring (another) j here is going to upset Eclair, I fear, as ... > > > + /* Check if there's anything to scrub. */ > > + for ( j = scrub_start; j < (1U << a->extent_order); j++ ) > > + { > > + if ( !test_and_clear_bit(_PGC_need_scrub, > > + &page[j].count_info) ) > > + continue; > > + > > + scrub_one_page(&page[j], true); > > + > > + if ( (j + 1) != (1U << a->extent_order) && > > + !(++dirty_cnt & 0xff) && > > + hypercall_preempt_check() ) > > + { > > + a->preempted = 1; > > + stash_allocation(d, page, a->extent_order, ++j); > > Better j + 1, as j's value isn't supposed to be used any further? > > > + goto out; > > + } > > + } > > + } > > + > > if ( unlikely(a->memflags & MEMF_no_tlbflush) ) > > { > > for ( j = 0; j < (1U << a->extent_order); j++ ) > > ... for this to work there must already be one available from an outer scope. Indeed, I've removed that outrageous j variable. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 22 12:50:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 12:50:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210935.1522508 (Exim 4.92) (envelope-from ) id 1viu93-0002yi-US; Thu, 22 Jan 2026 12:50:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210935.1522508; Thu, 22 Jan 2026 12:50:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viu93-0002yb-Qp; Thu, 22 Jan 2026 12:50:41 +0000 Received: by outflank-mailman (input) for mailman id 1210935; Thu, 22 Jan 2026 12:50:41 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viu92-0002yV-V0 for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 12:50:40 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f41a7452-f790-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 13:50:40 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS7PR03MB5592.namprd03.prod.outlook.com (2603:10b6:5:2c2::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Thu, 22 Jan 2026 12:50:36 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Thu, 22 Jan 2026 12:50: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: f41a7452-f790-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=K8JL67FpODbMaE/ZIp5XW8VtZRzVQIusRq4+ZXlHflg/pJsPtNYwYhUFeJazKK2c/w3KiykTlj393Xst2Wx/KUmdwOzG5+1ZByJdAagF3RilG/jqxB7BVykMMvCsTvA5MF9ekKDPYagcq6yQR5yNql7xpGOfoTshmLzbo+snEvZdgNRBKaZ1iUqPe3X+pAeYB6/JskiUMbACxLC+ldU8E+qKGe5meKB6eodSfsnQOYMvdjrPhu4sjpnEIE0hstGqcczwrxq6FU5lYrZT1j0R780IV7GuzjSvAsb+/HAfkBsbdk57w5JZt5d5Apqixm0VFJzX4V67gEd13JwVznhaqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xVo6bcO928HmmvC+3nXtZDNNIpqerp+tl/3J5S3LZFI=; b=BX9Y2SMlePdqvs4LlDBjR+BPLozPkXZLnKSLOVohiAhbPuShwbX7ebs/9b2WiJ45kYvod5FYERSSTFNtdPwUkhEaNf7SLv0zY4s5LmoFP5bfP1Ls9EpRJgYE6X1nwiPDe+vPbFEUIVT1+CcqkS1Lu74JpbLPkI8YmG65VHbbLkTusL1vtOA/Tc/X6bBd2yyeUr/xvhDeJ2yhiOYa1f+Ch6ifHkE+0qzMicCT3u3en0KFiRdw1qO+IUU7+2po1XnIARjJSRFgTtAoghavYQ+O8aopuauEDqXpcEyk5C6A5NlkSIMD9WFqI+nPGz+n5ORVrGNBiym9YTeOd/P2UFFrsw== 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=xVo6bcO928HmmvC+3nXtZDNNIpqerp+tl/3J5S3LZFI=; b=XYCI8CFmLTwj/BUQ6ZS1zzvg/c2I5cknrC8hMVTB33rctmcITUuZVcZQtynbyYbRbHqi4svetyFgiAmg7MsG9JMoQMi0j8aIZz+0rT6vEWTms6GNxLG1lnUPP0G2rhiBIXeppZPovgJ6KGHObLvgQ3o9xEoLcbu0BLSDt9eK9oA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <947a4230-4a1e-4178-b7f0-ae5618f4303d@citrix.com> Date: Thu, 22 Jan 2026 12:50:32 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Nicola Vetrini , xen-devel@lists.xenproject.org Subject: Re: [PATCH v5 2/2] earlycpio: lib-ify earlycpio.c To: Jan Beulich , Alejandro Vallejo References: <20260121154757.44350-1-alejandro.garciavallejo@amd.com> <20260121154757.44350-3-alejandro.garciavallejo@amd.com> <5948da25-0b4d-48a5-983f-0fc9424774b3@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <5948da25-0b4d-48a5-983f-0fc9424774b3@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO3P123CA0007.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:ba::12) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS7PR03MB5592:EE_ X-MS-Office365-Filtering-Correlation-Id: 1477943e-8faf-45a2-9bd5-08de59b4d6a4 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?ZlByYUtibm1wK3c0VHgxdTNkc2lkVU12RGZoS0tzTE1CM1VlNFNpMXZ1M3hY?= =?utf-8?B?aUtiaE5TK0FDQWRGd1BiQUg0T1RZU0hTNDlEUWJMU3QxRWZJRDRYNEdoS3hR?= =?utf-8?B?L0tYZmVjeUVBbWl5UUxjeFJuYmNnTnpNRUhGWXpsQjJtL2d6S1phNXVnVDVR?= =?utf-8?B?S2lqcTFlUjE1WHZIc2RTNkpVYWczSkJYZkRTa2NjZXI3U04rUDhkcEw1WEJ6?= =?utf-8?B?a0JHb25scWVoRlNjRHRuRExsTmJ4a2tYdEtrMGlpbnc1ZE9wcnZub2hYTlpS?= =?utf-8?B?Um9yRHcrRHp0NXEwNTVIaUpkT3VFZ0NEejJRL1VRb0JNL09UWldOb0hGQWJO?= =?utf-8?B?S3JKRHluc2h2QjAxYXJCMGw1QzhuTWpId0NKdFpiQzVQekhGL0RJNzJOVUJY?= =?utf-8?B?K1dUWTdvNGFJNFpKTUFvODloR1JRMmUyc3JLSm82d0VjSEFDTEdlOVJiWWFw?= =?utf-8?B?NGJrYWtPeXJoaTZyUkJEOHFERWQzWUlTZkdEc3dobGdTa2swQVp1aSs3VUVG?= =?utf-8?B?SXpYdXlIemt1aGFGalRua0ozcVErZWh2dDdqWkh5eW5XWWFaUGRGYmdQRWsw?= =?utf-8?B?RjJKNEg0ZWJjYkxtZXVaSU9FQVVOdzZuWTR5UnN1cGxQL1F0bGl2aUdqY2pn?= =?utf-8?B?MkdnQUQ0Q3kxQ2RTN2JyUUhkanZiZXBiYVNKN1paaXBaencxVG1KMGZBcGdV?= =?utf-8?B?RHpJeGdiSVI4Y2xjbmQ0bGV1UE5lVHBsMjRYTVhaYVlHV1UweWdKUU9CaktW?= =?utf-8?B?a25KOHNrUSt4YlFVdzQzTVZMaEVUVlZOMjI5S0UrKysrVXBST2IreEdtcUZy?= =?utf-8?B?aFJnUEtQek95UjhQckYvQXBQRVhvc0FVcjFES1hBcU1ucGFCNkNoNnRYWUNv?= =?utf-8?B?ZVFpWjVrQ0wybWxUdm1oTTVMT1BSUDUydWZ1bGYzNm1TS2hqSFRFSVJOR3pt?= =?utf-8?B?SFp3aXdRaFFaNFl5YVFncGt5MkppU09HOVZ4dFltbE8xWnA0MGJqWkEwdGlM?= =?utf-8?B?UG90RWpjNzBpTEpnQURVdkk1UlhaRTlxaDFGTFJwdndXWDg2VHREa2RRQXkr?= =?utf-8?B?MTJEa3JsN3N6d0c0YWFjanljVU1KZFh0Y1RHUVJ0OGx1aVRwaGhobUVvK0RG?= =?utf-8?B?cjVCYVVnRDdwR2luSHhNbVdZazRDUGl6VzhPdXlSTWZ4eG10UUZOQklpdUYw?= =?utf-8?B?T0hhQk9xMUdudC9qeTVEK3FqZ2YzNXd2R2NRb3Q3bENKaW1IVkVOY0NHN3ND?= =?utf-8?B?cEo2c29wcHhkRmIzNXptS0VidVJkcnlUcHBOT1lvUGg1RHJRSDg1eVJMdi9u?= =?utf-8?B?NVpDQ1ROaks1M0h6OFRhL3krdFA5d3ZVTDJFbExKem4zV0tPODc3b2ZwWXc2?= =?utf-8?B?R0FsWDJOV01ITDltZmhvdUFZdFErVVBLc2VnaEFwbVJiR0lTR2FMNm0zbzN2?= =?utf-8?B?cVNIOUNGSThGN0ZZZEF1SVBVNElxYTZxdmdxMllpWitTamhVc0tJT1hkOFpE?= =?utf-8?B?U25jeklBOFRvY2lsWjFVN1QwSGVZSmFHZkF3N0NkWXpJT1RYcTMzV3M0bFF6?= =?utf-8?B?bVNkYzR0SVpBejlOUG84cHNqZlNyNE9mcytXaHBoTmwzeXpHa2xvZGJlSS9v?= =?utf-8?B?NElzQlRsN2dYZ0tnaXRnRHVBbmdMQTN6MlJ5aUFrTGNvZnVNS0k5cFF5VWVw?= =?utf-8?B?cEFzamVTSk96TVdSN3BpUFpyTUROS3d2aVQyMm1UNkozNVNWM2Q1dlNjWjhl?= =?utf-8?B?UU1wdVp0MGlXdXdwTDRxUmF2aDJNTXY4NXExLzNCbVJWQk0wU2ZpYkN2R3Fv?= =?utf-8?B?TGF4VFlLTGs0TU91NUhZUzdnOENpN1B5dUNsbzhVS2R5M0kwK2ZWUkM5c3Zy?= =?utf-8?B?K095RE5WRkkvcUVLdndoWTh1WlFWZG8rTWFjSkRad2Z1K3hldjV0VmJ5S1BO?= =?utf-8?B?c1dyU3psZllxVW1qMWdSYzZKS29QMW9iWkZKek14NnZQbW1ubEhSeE9PcXN1?= =?utf-8?B?MlNGOXk3cFFYSlZ5QnZaSFVLcVhuMXdublFHOXdHWHZIVHZaSXRyVHMwUjRx?= =?utf-8?B?SkIwSWNSbVZ6WkxrM3dnOXIxSStmaUJ4ZG43Tmk2YldjUmtJUFc2TlR1MkFF?= =?utf-8?Q?y8O8=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?d0hyY3FadDErSVNtQVpVb290RzRwc2N4dkI1VllzdGJuRHlmM0RZOUVOS1Np?= =?utf-8?B?SitVYkFBWXdKR3U2N0lIUFFyRHhwOUFrWGdVWVNFajllUlRha09jeFFWMG4z?= =?utf-8?B?eHZySktITXdqajVmdXV5b2N3b21wNW03ekpHVTZYejdqN0Q0dE1neldHYXoy?= =?utf-8?B?RWMzWjFUc3U4SVp4YmM4eDJlSzQrRWRvbmt3cVZ5ZUJkdExXdFFaZDhzNWxI?= =?utf-8?B?ZlgzRmlIREJGWVJOS0R5Z0VwQ0dOMDJHdU9rbDZDMVlQQy8rTzIvWXdDYlFC?= =?utf-8?B?RDc4RU1OR3lqZ0MvVi9KYklNek5YOTVzQW9qMU0wYWdPQkI4TGptVTZBWnVV?= =?utf-8?B?NjBzSS9aWjEyWkpaL0t5cy8rTDl4UWVOZmtVNTd1VndzdjVjRjRsMHdXbEJC?= =?utf-8?B?QmtpeDh3Vy9mME9lVDNUcjBoTHp2K0lnOThTWnJvQk9WMnVBRnEvTUVkTXBq?= =?utf-8?B?a3dvWGdOOE9JTHVDMmgxU1FZcGdJaWVxcFNsNm9LbTNoRG1zcWVKUEZ2MHYw?= =?utf-8?B?eDdpTG8ybTdYQ2M4dEZwYnZMWkxRM2owZkdlaVBmVEJuY2U1UStTcUNsWldm?= =?utf-8?B?Yng1Q2lsdGVaQjdXUklaanJGa21sOHNoWXhWQzQrM3E1Zkw0VmIwRXR3MVpW?= =?utf-8?B?Z2dFRXVMMzFhVnMwYXdVM1dwb1lYKzFscWZIWlJmZ1F4bVdlaEYyVW85Tmlj?= =?utf-8?B?TlNDeVFkd3VYMVRxRDByVGU4ZURDVGFVcnFGL1paazM1K05GZXN3Y2xCNFdI?= =?utf-8?B?Tk1rVnZYbkpBL0IzNzlyVU9iTlVtZUVTNXMvREpwa2R1b1pwZ0U2blY5N0VT?= =?utf-8?B?RGN0K3QzTENHMXVVQTIrVG92b3FiRm1Vem9PNjBMZnl6ZW8rQ1h6aWZGZ2N5?= =?utf-8?B?YzdLb1QyMEF2Qit2OUtWcC9FdHYwVnBPUGp1UWZqV1o2Wm9OVGVKcHFHeE1m?= =?utf-8?B?aWV3SVZmVDhpSDNNR24wckZnQlcvME5zdnA2dFFjejFhL1psbUxVMkhCWmZF?= =?utf-8?B?andiYXgvQnYxTTJWNFlTR3hZSGpiWDk1MU5qblVJWjBNUStyTUN2eUc0UHdF?= =?utf-8?B?S0p0SGVsZmx2SUxBQWIrbXJSZWUxM0swRm1RNUxlUTcwSUpjWUNUZjJJYzJX?= =?utf-8?B?SnpNVFJwVEJ6TWd4K2t1ZmR1dTRjb3ZDeWpFM2lLMkpkRXl4N0FOSUZxOEU0?= =?utf-8?B?cGEyVkdCVUh1aE1lNm0rK2ttQjBicFJRckpFdG1hNlJ4Y2RnSklONno2cEhh?= =?utf-8?B?cUNlL0c2VUQ1cjZrSTgweVV0SE82NUxsV2hveWNBdHRwNFRRRDhnT0xkUkto?= =?utf-8?B?TWRNVlZremlRbTRzZWQwR2diTEhaTHRCSHBiMDNBVGdjUUY5amt4S045czlJ?= =?utf-8?B?NldyejZTTkZYRFpiVFFvM214aHVMM2N6VHhkTHVNWVdRNjFMUzIwbXdmeDA0?= =?utf-8?B?elREeGJUVWJxQkU4NVYzRG1kc0NBcjFWV2sxWTJ1SUs0OG5Pa0x4R3NUTm1z?= =?utf-8?B?Z1JZTGR1U1hZU0ZHVGdpOWdjd0FSMW9kNU9Ya09WMnVreFc4R3lOc1F1YnMy?= =?utf-8?B?MkRFNnByT2d1YWlBNjYwVEJNeFQ3US9sdkFiVC9nRzFlZUNheHZIcWFPeTNV?= =?utf-8?B?NUQ4Y1JnbUNpYzFuWm50SC9URnhJVjRjSmQyb3dOeW04NlhBbjFrb2hXTXZB?= =?utf-8?B?UkR0Z3BKU1ZHRTJMY2l3VWwra0lIVW9VMk9wdUJSR3ZsS3hYdEpqZWtBQmlM?= =?utf-8?B?Y1JYY08vSEcwaEdNMHNsNWNJNDJSOEZwQ1RtUHJyT3lhWFBvMGsxNTBoeVdD?= =?utf-8?B?cHRmMi9VYnN5bEFqd2F2VUxVSXB2MEZ0ekYzV2R3WkJSVmxGOUdmQjZmdHBG?= =?utf-8?B?aDMxMDlRQjVxS0lRMUlSN2pYMEFidjR6ejVmOEFSczJLM2FDNW42TnlWVVM1?= =?utf-8?B?ZW0xMEpYUE5vblZBZUY2bFhNVk5OMDBrbGcxWGxTSldTWnVpeFI3UzRxWW91?= =?utf-8?B?ejF4TjgwZEY4OG0wOGNUd1R5U0ZKSFVDbkZXTktGY3NXN1lUOE5BVmxUdjJR?= =?utf-8?B?ZWExTzdCZVpTdzhMeHBRNXpWVE5NblZRNjM3MTFkOVBhdGdNTUlNbjZwZkhY?= =?utf-8?B?Lyt3MVVFU1lNZW1mT3pFc0F0eVFPZW1xeU1jRVloRzYvbU5EdkJtbnRCRnEx?= =?utf-8?B?SkVuYjNVbGkweGN4NmRqWXI5bEkzMnlXTnRVMzR4Nk1OTEJ2UWxsSGx5ZFdn?= =?utf-8?B?QTZ5ekNtR1o1U2psQkdBMFFycmhYenVBNy9qblZYSWhsMnA5WVAwcEYvWTFM?= =?utf-8?B?ZkVsbHBtNzN3eGszYy8rVldtdUcvNmI2V1pneXZ3NDdOZjQ2MDlJZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1477943e-8faf-45a2-9bd5-08de59b4d6a4 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 12:50:36.4846 (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: usSBWf+hoTXdR/H8PFYLCZmRDiK5LlpPaEUeJc8SQNMUixdr3VJd84fBrxYVxHsTHHHjdS/92XHUG04Cet0tsLcUL9nNSY58xPd+NjScGZ8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5592 On 22/01/2026 8:27 am, Jan Beulich wrote: > On 21.01.2026 16:47, Alejandro Vallejo wrote: >> --- a/docs/misra/exclude-list.json >> +++ b/docs/misra/exclude-list.json >> @@ -121,10 +121,6 @@ >> "rel_path": "common/bunzip2.c", >> "comment": "Imported from Linux, ignore for now" >> }, >> - { >> - "rel_path": "common/earlycpio.c", >> - "comment": "Imported from Linux, ignore for now" >> - }, >> { >> "rel_path": "common/gzip/*", >> "comment": "Imported from Linux, ignore for now" > Judging from Andrew's > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2277362625 > this doesn't quite work. As I had expected, since the file is compiled > unconditionally now in its new location, some violations are now also > unconditionally reported. (Some, checked for at linking time only, may not > be reported anymore for the *-amd analysis jobs.) Yeah, in hindsight this seems obvious, given that we're compiling then discarding. There are two options: 1. Use an earlier form which adds the new location to the exclude list  (Still needs to be in this patch for bisectibility.) 2. Fix up the violations first (only 6 in total) Two of the violations look easy to fix, two need the deviation for octal numbers, but two essentially-char violations look to be hard.  The logic is doing ASCII manipulation in what I would consider to be the appropriate/canonical way, but Eclair does not like the mixture of ints and character literals. I dislike option 1, but as (contrary to my expectations) this is interfering with the *-amd build, I'll tolerate it. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Jan 22 12:50:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 12:50:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210940.1522518 (Exim 4.92) (envelope-from ) id 1viu9I-0003IY-3q; Thu, 22 Jan 2026 12:50:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210940.1522518; Thu, 22 Jan 2026 12:50:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viu9I-0003IR-16; Thu, 22 Jan 2026 12:50:56 +0000 Received: by outflank-mailman (input) for mailman id 1210940; Thu, 22 Jan 2026 12:50:55 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viu9H-0002yV-DC for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 12:50:55 +0000 Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [2a00:1450:4864:20::433]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fd5387bf-f790-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 13:50:54 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-43596062728so1356469f8f.1 for ; Thu, 22 Jan 2026 04:50:54 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4356997eb2asm45168641f8f.37.2026.01.22.04.50.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 04:50:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fd5387bf-f790-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769086254; x=1769691054; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=UO7uZjZYmc1bcmXjhuWQh0Sc+e0WOSN2fGwCuajDxzk=; b=FDnIDg8AtT6cWo0dgpxjulZkzi8uogPzwZ+MFKE9B12xoVT6vLH3bLxMRrOrggpoKm MMAwuzjnA0JydNaTGCfNlpmBlUvRqfZAqZdH8NkWWqVC0s0Wi6Ow2WAClzae2H5dWGqZ rQjJS3wsr8wZ3OI7vgn2uMhBRZ6Z66JA12IVaMyK5LVvt0pXXilZ855LlnS/yeD7t+S4 6EPZeGuxHXzNOao/f32+KsyZ8gZqdMI6lQqRuYMLKinyYqaq8E5RoFNe4u8vXyhIT24c lYDPvpkGgEsamKnB1Gw9E4eR0Jt18kW9BtfQ/R9d0dANHq1mH7g7XJT5DNSt4KvKj4X3 KCSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769086254; x=1769691054; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=UO7uZjZYmc1bcmXjhuWQh0Sc+e0WOSN2fGwCuajDxzk=; b=SAO+JL9I8+DcjYHoEd+LpLYiikFhFXB+brTzOJ0VDW+QG+vEMZ4+xt8fUsy9Qip1az xXVcqN8S3FphThgGAEEv2aF92ONh6ZWpETBi1cqx4r39Xae+/gMF014HM+bkWVC3fV6x Y7LfW3jRCq4eobl6qjrgz8FossVYuyIuzjOx95O4txwTS9vezpJtciLpow9oF0iPKauv ASilKn0rHXNPzjPb+GuW/QSSaPat4FurT+HoFgI4oGqJXYj131xO4soDWXlT9fIRFDie O3bBeIyDX4vIpOJiZcDTFv/kvL4UFClWs0nBui/qlB2dxH4wLqDv85AM7gvnKqrB1Hvu a1zQ== X-Gm-Message-State: AOJu0Ywx1/q2+tMvt/tL60ZSplMH/vZaevrk2+3zeyfPxE7qUoSFfeVW AYKHoUmSg4dduJvT4xO32jHD3IMIWi6Ct4+wInbuw7MrOlgn37H4R0YJm7+hfMdX0A== X-Gm-Gg: AZuq6aKQGsLYlpdpLDhWLgTuUR0xTENmQBZazKZHg6yJ1eaYJ860XOILEnFwBTYIeXV TuiIrfZdiq3TQi3Nwq6NkLoD6Wh9/bOl5nXYf8ic58BjMv5rFcgGM+h+Zt5AfHCOy0IYIjiPP+p 5pj94rCcM7r1aRzjsnu7Xp0T6Noor4Jq0BVYoRHyDTqa5jjmhzbS7hbH467y/ik+nLLlpJoI4Tg kBZHfpFQxfFJGT1oyTP0hRZ6qf2j5DDHttznWxs4v3rVFo+foqRK3AMBTb8xUicq7IenBIaWkKC gwAPE6ODsI/lQKGhFPc+yMLLgQvM+dhzynopRMvwdQ1i24zxADp+tqHzVbSJvCr2WcQeXn4gEPF bKjNWfJV28uXjG1wdwrgOxEh5p+FN7xANAfTIajDnTCM703HgHpcLshKsxnZwrw1uB/JifVNSxd ANO0yjEfXbdJrEgn8fGjJ/R+WCti081xBiJ0zU5jwXmfUEDIrtwqk43PZweXRtMTp/WaYeu8MPZ 80= X-Received: by 2002:a05:6000:1869:b0:435:a43b:2dde with SMTP id ffacd0b85a97d-435a5f755femr5701456f8f.15.1769086254053; Thu, 22 Jan 2026 04:50:54 -0800 (PST) Message-ID: Date: Thu, 22 Jan 2026 13:50:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 6/8] x86/HPET: simplify "expire" check a little in reprogram_hpet_evt_channel() To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper References: <57f34114-54b7-483d-8ac0-e9fa49df959f@suse.com> <0bc920e2-2e32-4b3d-9ed0-a2c2b34e9591@suse.com> <73daede9-d7ac-44bf-a018-b76d39b3eeb4@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 22.01.2026 12:30, Roger Pau Monné wrote: > On Thu, Jan 22, 2026 at 11:15:49AM +0100, Jan Beulich wrote: >> On 22.01.2026 11:10, Roger Pau Monné wrote: >>> On Thu, Jan 22, 2026 at 10:28:51AM +0100, Jan Beulich wrote: >>>> On 22.01.2026 10:18, Roger Pau Monné wrote: >>>>> On Mon, Nov 17, 2025 at 03:39:30PM +0100, Jan Beulich wrote: >>>>>> When this was added, the log message was updated correctly, but the zero >>>>>> case was needlessly checked separately: hpet_broadcast_enter() had a zero >>>>>> check added at the same time, while handle_hpet_broadcast() can't possibly >>>>>> pass 0 here anyway. >>>>>> >>>>>> Fixes: 7145897cfb81 ("cpuidle: Fix for timer_deadline==0 case") >>>>>> Signed-off-by: Jan Beulich >>>>> >>>>> Acked-by: Roger Pau Monné >>>> >>>> Thanks. >>>> >>>>> Similar to the previous commit, I wonder whether it would make sense >>>>> to add an ASSERT_UNREACHABLE() if that error path is not reachable >>>>> given the logic in the callers. >>>> >>>> That would mean >>>> >>>> if ( unlikely(expire < 0) ) >>>> { >>>> printk(KERN_DEBUG "reprogram: expire <= 0\n"); >>>> return -ETIME; >>>> } >>>> >>>> if ( unlikely(expire == 0) ) >>>> { >>>> ASSERT_UNREACHABLE(); >>>> return -ETIME; >>>> } >>>> >>>> which I fear I don't like (for going too far). Even >>>> >>>> if ( unlikely(expire <= 0) ) >>>> { >>>> printk(KERN_DEBUG "reprogram: expire <= 0\n"); >>>> ASSERT(expire); >>>> return -ETIME; >>>> } >>>> >>>> I'd be uncertain about, as that needlessly gives 0 a meaning that isn't >>>> required anymore in this function. >>> >>> Hm, OK, I was under the impression that both < 0 and 0 should never be >>> passed by the callers. If expire == 0 is a possible input then I >>> don't think the ASSERT() is that helpful. >> >> Oh, so you were after >> >> if ( unlikely(expire <= 0) ) >> { >> printk(KERN_DEBUG "reprogram: expire <= 0\n"); >> ASSERT_UNREACHABLE(); >> return -ETIME; >> } >> >> (perhaps even with the printk() dropped)? That I could buy off on, as NOW() >> is expected to only ever return valid (positive) s_time_t values. > > Yes, that's what I was thinking off, but your previous reply made me > think there are possible cases where expire < 0 gets passed to the > function? No, I don't think there are any. > If that's not the case, adding the ASSERT_UNREACHABLE() would be my > preference. Okay, that's what I'll commit then. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 12:55:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 12:55:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210958.1522527 (Exim 4.92) (envelope-from ) id 1viuDS-00044C-Kz; Thu, 22 Jan 2026 12:55:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210958.1522527; Thu, 22 Jan 2026 12: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 1viuDS-000445-IK; Thu, 22 Jan 2026 12:55:14 +0000 Received: by outflank-mailman (input) for mailman id 1210958; Thu, 22 Jan 2026 12:55: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 1viuDR-00043z-7S for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 12:55:13 +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 9546d650-f791-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 13:55:11 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DS0PR03MB8296.namprd03.prod.outlook.com (2603:10b6:8:292::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Thu, 22 Jan 2026 12:55:07 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 12:55: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: 9546d650-f791-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jv/0uYgoeqXAmhEO+tTgRbDH6GxrZN2dQMPGkTxxvtXrhn/0JKQlqovWWYZZTKelR4VxDdbT9YhDE7Xd8IskmB5Z0K/Rzye1kthr46Z89wGLrcT6TWfVT8LsKytrab+iY/oen+/vqJAWeXDgrJJdedeteTSvfnxRrjXAoB7RJKHdshl3nZgYSAZhCqo1gkk3FYVPAM/CN9T9IztIioD26//HaJv8FC0+V9o2vxvnaqw8UhMoDiLXUWkJyIyNCPJ1I6ZR4F0lTGbVpi+zcGyChI8QLAO9scT5G8sAZEZmXuNlCZ1Y+eosNSizWdB/0uy5w3XfphpYhp6fE/VbNWPjcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NGtUQ2CHyM8PU1owUC/wH4D1Y2o/0voT2bp1DKQNoVI=; b=oJqb2dIzseXUHHfzCdTgZnQcXAzlvP1LWhAPtlyIqSiPLGomT5DIEPiiTtuTfXZzMw/PtJb6afSJr4tgxDJijxi2b6WK4GselSfF4V6Cv6z2W/v54/blgoRpCVQsfUthNOCcF0OshFl4iJgZOjLkii0ZeyOMmRDSKcADMW6hnTiCtJVndADkmjP6Nw+S8UIufuNREBiGwOHIT0Zmu/zFoJdsog6lpQQNWw7XMVQ+uGJpDteyw+cFO3H0uMlXJ7J4bZJAfTBrN69VobwlX1RNgyBi0tMjaBVYEFMbtAFUlEG2KjiDQO+sKmZLpE2KBQ2sxrkxB0jyKm1EqFicrkRIrQ== 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=NGtUQ2CHyM8PU1owUC/wH4D1Y2o/0voT2bp1DKQNoVI=; b=DtSjIlJt3n7y/Aym/rvsAY1oqxvFPxcq/uXOIlosffa9CiFlE/98WnVdECWdDeRDKdMIWhfXrKWRwst1lVq4RVO7DsR7KPUlGOe0jClvlv7ms9goGc1uaYLVCYdfx2vbFZsF9dLnaxJqrXkCJEjuFPYRHrnedgEejctS0qN2B2w= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 22 Jan 2026 13:55:04 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH v2 3/3] xen/mm: limit non-scrubbed allocations to a specific order Message-ID: References: <20260115111804.40199-1-roger.pau@citrix.com> <20260115111804.40199-4-roger.pau@citrix.com> <858d73b3-2feb-419f-bf3b-9a264e9f9af8@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <858d73b3-2feb-419f-bf3b-9a264e9f9af8@suse.com> X-ClientProxiedBy: MA3P292CA0015.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:2c::11) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DS0PR03MB8296:EE_ X-MS-Office365-Filtering-Correlation-Id: 1d6c6471-efbb-4c19-d170-08de59b5781e 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?Ykczc2NCL2NocFJmeWZraURiblU5TzBPQ2IzYnluN1NQdTVtcXRtZm1HM2U0?= =?utf-8?B?aUdVNm0xTGFQT0VmejRKdjRjNmVYQll0NUlDcEhWQi95WE5NQ1l1MGR3d1Nk?= =?utf-8?B?NC84b2dJbG5mTHZYeEFDUFNZOGtWVTVIUG11a21pZUtQZFEwSHZxNFdjM0pM?= =?utf-8?B?dXgrUFU5eXRyZVBsZUNJUzVQVkQ3czFGbVN3eTR4YUJEdXQ1TU83SmFHZXpS?= =?utf-8?B?dVNValZnYTI2d0RYL0s4dWx4dUszVVlxUjJhanVReFdOeHh5M2d2Y3BLWjBF?= =?utf-8?B?SjBZOWdnUkxaa21mNkl2QWxFOEtqbXpkL1lUSlJBTXBObmJhemthSysvWnpF?= =?utf-8?B?a0IrZW11NWFMRmZ3bUU0R1MxWGR2T2FwaGN5bmttMVpmTkl6YlR6dzNXVHpk?= =?utf-8?B?Z2ZJZmhNUlljbjNETDcyNVIwMjFYRjFjTE51NXRqTzFOL29hbFpDaHNXbWtY?= =?utf-8?B?T0Qwa1oxYWd6Z1ZCMmplaGRXRllFcDB3dzdzRk5oVldocVUrUnJxVmJNbEFH?= =?utf-8?B?UlFsWVVvYk1hdnBEZ3VqNDVuYzY2c01oWXV2SUlER3lTK2J6Q3pBRlhFLzdZ?= =?utf-8?B?SzFDOU9SekJTdUI1NWtnUXR2cDBZcHdoQlpuUG5oTDd4UGdlNTh6blBPSE5L?= =?utf-8?B?enZJS0d5T2RRQW5IQUl3TFhJS0NCRFFsTUJCazhUOE1yQWN6OXJPczE5Y2NE?= =?utf-8?B?RXZ0ZmlUVysvM0pTSUVWZ09qN3NXY0IycGdRbE9HUEVvOVhIeHUzUUEwdTBQ?= =?utf-8?B?czFITGFoQlNKWmR0U0htd0U4SHNjcXdMZ094aCs1Y29WYitFK1hXVjJsSzVO?= =?utf-8?B?TzR3OFNlZm5BUDhDZmsxTWJtOVRHZFRyRDhCRHlFRTFTaEJPeE5SVXZTQzh0?= =?utf-8?B?ZzExbERMWlp0VkhhNHRpRHRLM1hjU0NXdTBRN3BTajhySS9aL1lCUmJuaFpM?= =?utf-8?B?bDZkVmpveEtibURjOTlFcXNIdWVqSzhQeGlTYjhMSkhsNm4rNEpqVjZYQmVy?= =?utf-8?B?Wkx3RXRNQjEyc3V2RUpTYzJPdGdGY0JaeVMrbGlRcHlYNUVLZGh0RHBST2t4?= =?utf-8?B?dGZ0VGNSNkYxTFFDeFgzUFZZaUNZdUNsSmpSd1VKRUpzN0pGQjRYV1d0V2ly?= =?utf-8?B?UlhzT3FlcTQ5Ykc4dHpGNE9OU283K0RYOS93d2NXb1RRT21GNWJhczRHbDcx?= =?utf-8?B?NDV5Q2U2Q0hQMXJVSHhWUWxKNUFNbWppWDFMMnVSRVlLTkZXQm9sR3V6OVhu?= =?utf-8?B?NzhRWnpJU0lGLzk0RXIzK3Axb2d2ZGdUdE1VUHo4V2FKeWkzN0lnWUREaWg4?= =?utf-8?B?NDhZM1lRdzFVTUd3alZHTzcza2VrSWgxVnN1N3VJT1B3ekxpL0pReE1OU2w1?= =?utf-8?B?VG1UQWFJTm53T2lpcDAvYWZ3WVBxVVl1dWpYZDI5Z0tvZzJzU0o1SW5FUkUy?= =?utf-8?B?QXYyRklrWUZYM3hYdiszd0NQOURwTTlncjRVbC94dS9xLzYyc01uUTZBRjRI?= =?utf-8?B?U1FWSXJ4WkZTZG44WVhhQzBqTHRuWXdWMkkyT3lISndhL0xEMllxWDJOcTFt?= =?utf-8?B?NGxFd2gxL0ptdEcrVkhWMEpiMUh0bHdGOXlWV0tsUTJjeFo5bHU5Ty9iUGtK?= =?utf-8?B?cHBNU2pNMGxMbVg4MWVLZWthSGEyOVZYc2ZzSVRwZ0hGUFJVYUZyMHNkSzVt?= =?utf-8?B?bVM0dUhIRGgvdGJnODkrRWF3LzJkWThoV3BUdlVpVExvNEJaNEJrZytyQllu?= =?utf-8?B?THpXN0JjejUycUpXTnNBeWlXYVhVMnZHL3Nyb1YxaklhaE9NYU9FcFdQS2Fx?= =?utf-8?B?ZDlRQSs1Z3Nvdkt0Y0VFNVROZzJYYWQySGxNTlpwS2ZCM3o0U3J2UW9Md2tl?= =?utf-8?B?VXJpRUxrSHArb0NyLzRLYnZ2QTJMMk1ZMXZ0V1NGNWxoWTdmM3EyRXlXNmY0?= =?utf-8?B?UW5heVN4aUFTL2ZweWJ1SE9yWmgzUlBsZWQ0aVVqUFZ4bmlIOXFIOTRNNkVq?= =?utf-8?B?WWhTR0czSHEyd0tVOHhMQU1EN2NZL1hVRzVyZmgwNjNrdUtGQmVxekhxdWpu?= =?utf-8?B?dEZGMjZxVWlkeWVJb2hJM05JaWhYd3liNU42RDhDL3J5TjU4b1RhVjE3ZHU4?= =?utf-8?Q?aNcY=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WGZacDlDeUdnR3lUNmxTTTdvek83VzRYTEFMK2p4MmdPRndVdmpBNEl2U2k5?= =?utf-8?B?bzFQejdYbVpmL0o3N3RrbjNPNHVyWGFPVkJkdUlFd1FXdFl4aXk3TzJLNGw1?= =?utf-8?B?aGZaUUpzQVVPSE85SGhQSWdjQVY4MmxiZnpBZTZpN0tteWRIblhnczc5QUpQ?= =?utf-8?B?ZEo3TFNyREVWK2Q2VlcwN0lxSnhLY1k1d2FLVUJLVVJsc24xV05XNUNsc00r?= =?utf-8?B?QzcxLzRRenFEeFQ0OFFQRHNneHAyQWFXbXlFcFdtdzg0WmlRUHowTHFrZkNO?= =?utf-8?B?NGFYeUQ2MWtPaTZWSVI1YmR1alY4VW1HWkpkakxPTjVTOE42MW1veW1aMDhB?= =?utf-8?B?a3VyemYrVzVnWE5OQXRWTlJTLy9iM0VzeTMrZ1hhM0ZBcE9Vb2U3RlNubS8x?= =?utf-8?B?M2ZzQWgvMVhYR2gzNGdFN2dVM0xmbTNOTE9oYlp3a1JmaXJ0a0ppQ0k2T25R?= =?utf-8?B?VktDL0hLNFpFR3NLOFhkSFhoMVVNYlFjMDJZNVpwdzBpYzJ3MGhYbk54WXc3?= =?utf-8?B?bUhzb0dLWWhpcG10TDM3cVR0OWtxc2FybWpjRmxkY2tyS0t4OU0xWXdEOVZ3?= =?utf-8?B?ZExhVEVnQS9LeHZRMnhDVTVWVCs1ZWd3QStFdURQTVNsUHpKcVRKRlVDTXNY?= =?utf-8?B?ZkMwalIxVXRJUGRKcjRpOXpiTjd4cTBDWkp4UDh2ZkxEMzhtc203VDZ1aGli?= =?utf-8?B?ekovWTVXQkdmVXF4bkJEcnQyYUZBM1RvZHQ4YXZkT2dsQ25DYVFSOG5mZGZT?= =?utf-8?B?c2NlcXczZWRvRlFTKzlqRHA4ZmY2MFV4c1NtSzljdmxXTXVLK0pJYld6Wlly?= =?utf-8?B?SjVjU0xSNVV6SHBoeUNFWSt6VW5udVdOYzFHb0xyb1VqamxFSGhPcEsxOXJi?= =?utf-8?B?aktSU1owbjJKQ1BOU2syR1EweUZyalZGK2NRaFpidnlvb3d5UXN3UHA2d2dy?= =?utf-8?B?cGNtTCtYNGNBUXhRMmFtMVRlZUVDTDcxc3U1d3h4M3NzM3piMERSY1JhWS8w?= =?utf-8?B?UFRGbEVKRE5iYXJqR2xiWVpqc29nQWxBNVJOekJTdHpaRG55bE9YLzMwSUE2?= =?utf-8?B?Q1lmdnhESm9hdEhnc3RZdll2WmF3eUM1bkJRTGUyWDhtTzFMWWJibjdLQXRZ?= =?utf-8?B?ODEvT2EwYzRPaUNsSDJtUGl0eEt1K1pOWHUxN0NBRlcxRVo0R3ozK2hsN0tY?= =?utf-8?B?QXNlUVN4T0p3TVpnSWZ0Ry9tc1NMOFlHekVoaWVrWHVlbTRKdlljTW5wSUJa?= =?utf-8?B?OG9oWm9uK1IrYlpUV0tBU3hScVdGaHFSWU9mTGtVd1RFTWozd2UzSHJmZStq?= =?utf-8?B?TDNvamxrZW5LaFYyZ2lyVTVCQktiS25WYTlORXFJa3NkZ21EQTltVXIwWWxW?= =?utf-8?B?V0U3UTU4TFNZUmp1VWoxeEN6REg1NkxPQTFVTCtIWnd1YlhQQnN2OFVyS1p2?= =?utf-8?B?TDkxTFo4NkxnaElKTUtTVnVHaEhmZEJqbHNjQXBMUXVodi9zWFVqaXpvUkZB?= =?utf-8?B?NFBKM3piTGJZUmpTK1VTVzFOUCtibmJvdnErb1ZNckNXQkR5bE1QTDNjaDJ1?= =?utf-8?B?UG5RdHFnNGFnV05EL2lBaTBuSmZPaEJNUmlsdzZXRlBnNWNoSGp0cUdtT1E3?= =?utf-8?B?dFNjakFUU3hWWWNqSXd3Tk1uZWVQYzNsUmVXTXFBOXR4R3k0T3Zsb290RFVz?= =?utf-8?B?Z1prRG0xZm52OGR3WHl3b1FEblJ5djVqNldCK0R6dDVnZzRxOHFacTFUQUFk?= =?utf-8?B?dzJFUVBlbjI2bHc0SU04SkFkUzdQa2ZRaE1nRWN4US9uSnNEcDRFa1pwbEhP?= =?utf-8?B?Uk1rSWxzc1pJMkN6c1Z5VHlid1dxYTBjRE52N0dlbG5EaGV3NnNsMytSUU1D?= =?utf-8?B?YVVSV3hoeXg5RE5oM2JmcXpheWhYNWIvWmlaVHVIdDJsSVVuL3RacVNFakRC?= =?utf-8?B?TzhtQUJJM2J6dWw3RDQxbXQ5Uzk5d1d6TDZlWVZNK0pUWmdmN01TN21Ma0dv?= =?utf-8?B?djNzaFppU1FPY0Vpbk5TdXE0UlNqVXZrQlpOZnM1M0FNYTgyYnNENDVjaTA3?= =?utf-8?B?UnB3ZVlGV1RscHRiTkR3ZDZQWWQ3WUpWMFlERHRXMy9OUm5Sd2llTDBldnlK?= =?utf-8?B?RzdnRWRqVDgvRUh2RFIyWTIxSUVxaEJkZkZkSGFRUGpqbUU2UnQ0ZVNTMTlJ?= =?utf-8?B?ZmllMWZNbHRVeHYyMWd4K01aUk5tYUVORkR3U3k3SXdiaFNGaG9QdE1sdWtT?= =?utf-8?B?VitqdFBPRmdKeU04OFhTSWZDbmc5UUIwSWlIVk9Xc1VGU0pzWVVwUXpLUmF6?= =?utf-8?B?NzdQVTdscTdLaEVxRkpvWGU0Q0RQSGM3em42SEVnd1hVMnp2TEpwdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1d6c6471-efbb-4c19-d170-08de59b5781e X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 12:55:07.4522 (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: bRogNPMglCuU2i5j906fawo6DlbZBcYYzKvcV2cW3WES9rD/v0YJ452rFTALCZ3RftIX/1bMfedJjIEMKGZIoQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB8296 On Mon, Jan 19, 2026 at 05:13:25PM +0100, Jan Beulich wrote: > On 15.01.2026 12:18, Roger Pau Monne wrote: > > --- a/docs/misc/xen-command-line.pandoc > > +++ b/docs/misc/xen-command-line.pandoc > > @@ -1822,6 +1822,15 @@ Specify the deepest C-state CPUs are permitted to be placed in, and > > optionally the maximum sub C-state to be used used. The latter only applies > > to the highest permitted C-state. > > > > +### max-order-dirty > > +> `= ` > > + > > +Specify the maximum allocation order allowed when scrubbing allocated pages > > +in-place. The allocation is non-preemptive, and hence the value must be keep > > +low enough to avoid hogging the CPU for too long. > > + > > +Defaults to `CONFIG_DIRTY_MAX_ORDER` or if unset to `CONFIG_DOMU_MAX_ORDER`. > > This may end up misleading, as - despite their names - these aren't really > Kconfig settings that people could easily control in their builds. But those have different default values depending on the architecture, hence I didn't know what else to reference to as the default. I'm open to suggestions, but I think we need to reference some default value so the user knows where to look for. > > ### max_gsi_irqs (x86) > > > `= ` > > I also wonder whether your addition wouldn't more naturally go a litter > further down, by assuming / implying that the sorting used largely ignores > separator characters (underscore vs dash here). My bad, I think I've originally named it max-dirty-order and forgot to move it down when renaming to max-order-dirty. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 22 13:00:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 13:00:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210973.1522539 (Exim 4.92) (envelope-from ) id 1viuIZ-0005w8-CX; Thu, 22 Jan 2026 13:00:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210973.1522539; Thu, 22 Jan 2026 13:00:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viuIZ-0005w1-7s; Thu, 22 Jan 2026 13:00:31 +0000 Received: by outflank-mailman (input) for mailman id 1210973; Thu, 22 Jan 2026 13:00:30 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viuIY-0005vv-4Z for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 13:00:30 +0000 Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [2a00:1450:4864:20::430]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 535620c0-f792-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 14:00:28 +0100 (CET) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-435a11957f6so763011f8f.0 for ; Thu, 22 Jan 2026 05:00:28 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4356992c6f2sm42901805f8f.19.2026.01.22.05.00.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 05:00:27 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 535620c0-f792-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769086828; x=1769691628; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=xW2ErgZF2t+Xs5pfDMWviwYjHbuakFt5IED0dS0RWEg=; b=bJJWLSyxoO0gQPQJRNCpRj/JnWsfI9oCR6d2ClXlqeVpZc1W22kJxfJ3UJxqJOC3pB +IsjSRFdq5SzwDtbGZjmnUATlIj/v1j8rfu4G7yGSY9FVRl30dAuFeTuPA3XjDaEpCki W5c+CBCG2oQoaUTdzxGQw76SU6nC1HxzuwsBuR+e8Ct411g7NlcSinFQEXXDV7jD6D2j Nxp0a9s0vz/L3wdBfhBIzQOvtgpGvQXv0WdEhFDkIIASKmrmqucm8LN8tGrZprLPK82P YXq3qRNkXFk64+wIg/b6gtklTyGMIVXPcnYT1QAl7A6R9XE1rdj/5nyzt2WvMR5iGPh3 ii5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769086828; x=1769691628; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xW2ErgZF2t+Xs5pfDMWviwYjHbuakFt5IED0dS0RWEg=; b=DJM4ioXYD+tmHkGXyZ9mFb7OakWOxi1jzk7BHqgI4Oh/i92nusxbrJkO4b/C0qyM4L SXA9TW60M6cqHHRoZrxFRJebmrcuM7YOkVXWlvfRGE1KDKxeLDylOwZnpKnpmDBflR5x i2GwQuPzMS1KcsikjOrQt+UTWFu9odkytaCWGss43PBAQrccGyS7esljkIwSE+f9gOun L3TaSTku/L9IFaPt6U8y2Iz4FDWW4Fe3inF7b94maQjlDq8iKjXBodVCrb2l6a6L87os 4UGwDR3PTo/WHRbbuN7m9ZmV7Spe+QNjnqcOGu2DnkWx2/jB7OI1Iz0XVNi58Z+vEfNj 8jYA== X-Forwarded-Encrypted: i=1; AJvYcCULu2F0iOUbe7n95DfVNP84P/D0fWCQw+733bhur/mnaVOnpibDoN80gy5+wEgFi5rUQmj9WoFxjw8=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz4rLAEbzDKKHYIfNGDyHTyEyXq58sfw4cZrx4xIuoJFfrR8I/M MVtkczyL7XsWEizDuMiYWpFvupdCm0RPjD0l6+5bCbqJvEJoKMDPO6MI1ONwaPvQOQ== X-Gm-Gg: AZuq6aKHUZ8k2GbqdS3KTjV/mxJTZ3aHmDLJV7TFlOt+QDfB4RYV1ByWFR5lvRcUJoe t07Z9isBM1J6gffu4G8Gcxeq6W15Fy07OBXHIZYaNVwWXW1r3JruDvWtKwgw+eQbxlVUor3dD/X SeNQ23xiiFj66Fut7adheXUsrkXdXbfbGMaAleohc/pI+etefwsAVER/+MLV772malfSfab9MFR 6mpOQobL7Sl+/RO1uELqcHcw+yTTtmmoe0F3m0MF7AjolXddrrxz6e1ikCac3tGvizpMbXDbD7O thNSHvNuASabl4E3uaJZPdXKwqDVR0N245OiAstpyEORUtqQBJvfiwvDYKxuNRs+P0UmgH6d8nC D6f3f1B3nNOIiVLPlbLC4pr1sw7GdLw5gMPQdnY3XswPoCkhAEnhxwRc5cD7flRDbgQeIxkGHqz KBdec2AvFKPXobPO+gWibn+vp61JmoP1ZvswAS0jPhvMIro3FBINzS+17NDgRAnfaiKf16T/mWj C8= X-Received: by 2002:a05:6000:2893:b0:435:a83e:88e with SMTP id ffacd0b85a97d-435a83e0961mr3491779f8f.2.1769086827585; Thu, 22 Jan 2026 05:00:27 -0800 (PST) Message-ID: <26d15493-cb05-4253-afa6-6b1490ad0d20@suse.com> Date: Thu, 22 Jan 2026 14:00:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/3] xen/mm: allow deferred scrub of physmap populate allocated pages To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260115111804.40199-1-roger.pau@citrix.com> <20260115111804.40199-3-roger.pau@citrix.com> <7387457f-104a-436d-96ae-b70c77745200@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 22.01.2026 13:48, Roger Pau Monné wrote: > On Mon, Jan 19, 2026 at 02:00:49PM +0100, Jan Beulich wrote: >> On 15.01.2026 12:18, Roger Pau Monne wrote: >>> --- a/xen/common/domain.c >>> +++ b/xen/common/domain.c >>> @@ -722,6 +722,15 @@ static void _domain_destroy(struct domain *d) >>> >>> XVFREE(d->console); >>> >>> + if ( d->pending_scrub ) >>> + { >>> + BUG_ON(d->creation_finished); >>> + free_domheap_pages(d->pending_scrub, d->pending_scrub_order); >>> + d->pending_scrub = NULL; >>> + d->pending_scrub_order = 0; >>> + d->pending_scrub_index = 0; >>> + } >> >> Because of the other zeroing wanted (it's not strictly needed, is it?), >> it may be a little awkward to use FREE_DOMHEAP_PAGES() here. Yet I would >> still have recommended to avoid its open-coding, if only we had such a >> wrapper already. > > I don't mind introducing a FREE_DOMHEAP_PAGES() wrapper in this same > patch, if you are OK with it. I'd be fine with that. >> Would this better be done earlier, in domain_kill(), to avoid needlessly >> holding back memory that isn't going to be used by this domain anymore? >> Would require the spinlock be acquired to guard against a racing >> stash_allocation(), I suppose. In fact freeing right in >> domain_unpause_by_systemcontroller() might be yet better (albeit without >> eliminating the need to do it here or in domain_kill()). > > Even with a lock taken moving to domain_kill() would be racy. A rogue > toolstack could keep trying to issue populate_physmap hypercalls which > would fail in the assign_pages() call, but it could still leave > pending pages in d->pending_scrub, as the assign_pages() call happens > strictly after the scrubbing is done. As indicated, the freeing here may need to stay. But making an attempt far earlier may help the system overall. >>> + /* >>> + * If there's a pending page to scrub check it satisfies the current >>> + * request. If it doesn't keep it stashed and return NULL. >>> + */ >>> + if ( !d->pending_scrub || d->pending_scrub_order != order || >>> + (node != NUMA_NO_NODE && node != page_to_nid(d->pending_scrub)) ) >> >> Ah, and MEMF_exact_node is handled in the caller. >> >>> + goto done; >>> + else >>> + { >>> + page = d->pending_scrub; >>> + *scrub_index = d->pending_scrub_index; >>> + } >>> + >>> + /* >>> + * The caller now owns the page, clear stashed information. Prevent >>> + * concurrent usages of get_stashed_allocation() from returning the same >>> + * page to different contexts. >>> + */ >>> + d->pending_scrub_index = 0; >>> + d->pending_scrub_order = 0; >>> + d->pending_scrub = NULL; >>> + >>> + done: >>> + rspin_unlock(&d->page_alloc_lock); >>> + >>> + return page; >>> +} >> >> Hmm, you free the earlier allocation only in stash_allocation(), i.e. that >> memory isn't available to fulfill the present request. (I do understand >> that the freeing there can't be dropped, to deal with possible races >> caused by the toolstack.) > > Since we expect populate_physmap(9 to be executed sequentially by the > toolstack I would argue it's fine to hold onto that memory. Here you say "sequentially", just to ... > Otherwise > I could possibly free in get_stashed_allocation() when the request > doesn't match what's stashed. I opted for freeing later in > stash_allocation() to maybe give time for the other parallel caller to > finish the scrubbing. ... assume non-sequential behavior here. I guess I'm a little confused. (Yes, freeing right in get_stashed_allocation() is what I'd expect.) >> The use of "goto" here also looks a little odd, as it would be easy to get >> away without. Or else I'd like to ask that the "else" be dropped. > > Hm, OK, let me use an unlock + return and also drop the else then. I > think that's clearer. I think if() with the condition inverted and a single unlock+return at the end would be easiest to follow. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 13:06:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 13:06:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210986.1522548 (Exim 4.92) (envelope-from ) id 1viuNu-0006Vm-Tg; Thu, 22 Jan 2026 13:06:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210986.1522548; Thu, 22 Jan 2026 13:06:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viuNu-0006Vf-Po; Thu, 22 Jan 2026 13:06:02 +0000 Received: by outflank-mailman (input) for mailman id 1210986; Thu, 22 Jan 2026 13:06:02 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viuNt-0006VZ-VR for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 13:06:01 +0000 Received: from CH1PR05CU001.outbound.protection.outlook.com (mail-northcentralusazlp170100001.outbound.protection.outlook.com [2a01:111:f403:c105::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1911a418-f793-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 14:06:01 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SN7PR03MB7153.namprd03.prod.outlook.com (2603:10b6:806:353::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Thu, 22 Jan 2026 13:05:57 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 13:05: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: 1911a418-f793-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=W1yjiRSuntZluOvc7P/qmBiZ+81oueGiPtprw7Klxj6hd2u8wqjEPmQZFS/5V5CslMHul8DsNciCsg9M7bn4Yhg9dOvmq322v/Yz5BuFQPXep/PdYq/qV0k+1oV9oo77+RfNZtecfWQGIadn2drGlqBdBr8xiK/5o7X5yv+aPamg8Q7CK/qXYMlTco/5dFiqr7Ey0aH7kbvxMUbZhexEGNFPlUv4p2H0GEZ2ShsNURl7CvFunlZGcPjXens3UV4HHkdsprFcuXOzd/Y7DrHoYEmFwEDtUfilp8XYXZlaf3LEFO5VRJcVdhvCxFk5+GSjFl9+309SpG91+gUwnyWkQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=cFD/qT4OVfg9dr7c4d4vbfsAInr6LCgB7utzTN1z3rc=; b=j8dPL6WDDxOUyC3qBx31qTQEplk4paKwxSHyMuULiMJupviFNDwpslqdw/alFKXbmZzN8aqnitTV41S7p2bMklU0zl3n5DeIrUTu+sJlKNc+Gxm4sz/SPuIDlIDLbcmnIPIMXRIuXFXNzD23ocCEJu7C0Z5r2V8bYiGl9EFqKpYPhYvcql4bdLmfapDKeI9RI91qNI3hP2PnKIDJPftOi7y3odYCkr5MZKM9exgCaDI2QdIGKagACknF4wdWqTUCHZauRi+PnB96h4ggFiRIhnsq/P9LoG0AakHehznhkn9lhDBS2thws5tAd0FEFbhZ5H01OmzGZllhxwoS3FhQog== 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=cFD/qT4OVfg9dr7c4d4vbfsAInr6LCgB7utzTN1z3rc=; b=0TuNunIeeRMJl3tJW5PTa1xNW+DO1xRuGGHcAjCXlfPV+JMC5as8gjuLJ5bS63SYnIxOlBjIe619WXOrH8m8WFFUz5WUVb3SoKHnp35p9LxUUIMXlW8tJkxAN9LWqAtucCiLjUzrFlJ+BYtmCEm6x90XF5L2hw6Lh9DYdhq+xcg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 22 Jan 2026 14:05:53 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH v2 3/3] xen/mm: limit non-scrubbed allocations to a specific order Message-ID: References: <20260115111804.40199-1-roger.pau@citrix.com> <20260115111804.40199-4-roger.pau@citrix.com> <858d73b3-2feb-419f-bf3b-9a264e9f9af8@suse.com> <97127b23-4e4c-4b06-a8bb-b1dad31bf0b0@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <97127b23-4e4c-4b06-a8bb-b1dad31bf0b0@suse.com> X-ClientProxiedBy: MR1P264CA0077.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:3f::9) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SN7PR03MB7153:EE_ X-MS-Office365-Filtering-Correlation-Id: b64d5b5b-28d0-4475-137a-08de59b6fb7c 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?SU5nWXhyRkNPKzhTYzFwNkRwQjg5L2RMYWc4STRpV2QrejFNMXJ4VUd1bktN?= =?utf-8?B?Q0l2Q241WUl0RnZ2bTBiN2RQM1h4T1d4NEpWcFBOZnpKTFRKNmgwN1EzMndx?= =?utf-8?B?WU1tMjd5d0tpb0NraVVpbzRPUzJUS1YwejFNK0N0bGpSQ1pXdDV5TmZ2elBU?= =?utf-8?B?Sno1eUluakpMWmI5U0I3SGZGdFg5VmhpeVRJeWlaS0FtTmgrOHQ5NURlOHhk?= =?utf-8?B?Yld5MkdlM2I4c2lsTU5HMVRJaUkyaHJZUGNVdkhwTUVmL3dUUVRCU0VUVllF?= =?utf-8?B?ZVk4OUJYbDhHcG9qR0I3NDlVM2ZjZEFnNkpjNFdldk9xYWxaajIwYlZrMlVB?= =?utf-8?B?d01hSGVjNytYekpDRE1aVXhaYWtHMVJUM2JIelU2bVg2WHlrcW45S0xmNCt6?= =?utf-8?B?UXF2RUxKdVJpVkNDdzB4YWc4YktWajlBY2owTlN6UHFlZmNENUU3Y0NTMnZK?= =?utf-8?B?Q0NYUGlObkNaaDJnWnhwdUZFVVlQenVSRXdJOVZ2VnZFWm1udGZkVlhuSk93?= =?utf-8?B?OXR5OFdrRitTRTFNWFB3QjlmcFRnd21XZmRCUHh4U0NPQjhRVWE5Qk1tRzEz?= =?utf-8?B?ek5TSHpidnBMQzJFc1NLdjVwOE4xdXQ5T2pYdUQ5NVdUbm42bUp2S1ZFTjZ6?= =?utf-8?B?dms4RmFjMnBncERsd3M4WVNnWG9QMjVWekhyc1ltaHNhWmN0N3JMVFR4YXl6?= =?utf-8?B?WTlUQ2kxUXJmc0F5OEJOZUk4a00xcWZ2b3h4RnA1L3R6bllXb3E1ZFd4ckRs?= =?utf-8?B?ODhSMWdCdkdIRUEzb0xFdHowQVY4MjdvWlZSNjJaaU4zRlNTbHNpMCtiR0JK?= =?utf-8?B?VCtZRjBDSzg5VlpSUUFLdld1QWphSDdoQ1NrMjQvbVZGT2pVazBpdUhVLzM1?= =?utf-8?B?OVV1cnJTSzlLT0hTNE9JVktHZTJwNlhyUGpQZm1VTEpPZGM5MzBzWTRVMmRi?= =?utf-8?B?KytnL0ZtQmI5M0VhSEtRWkxXVXBFd0t2b3NndUI2bWZZdjVsOEcvSW42azJV?= =?utf-8?B?T0NyUloyT2VxWlNubmo1dEV3WU9BUnlUL2R3djU0ZVlBNFA0ZDZpQkhVa2Uy?= =?utf-8?B?UzVIVmNydjJWeGF2NUErYlNITm5rK2MwQXJmbHZkdWMzbVdaWFMwUTF2VjVF?= =?utf-8?B?Ymw3d1cvMWIvL2xaUUhGTVlwSDN2SlJQUFQ4VE8zc1M2ekUrSUo3VXBvQXRP?= =?utf-8?B?ZEthMWtlZnd6bmUxRjdVNy95bDZiRkJPbDRQb0x5amlSWmFyYWZOaTJWOG55?= =?utf-8?B?Q3JZY1pCR3BqSHZWaTVDeW53c3JNZXhuVk4yVzRodSs5UzFZV2FaOUgvWnNF?= =?utf-8?B?aVFsWmFEWWJmMnlUZllwWWNabGU5bDlQbkJEQ3JnSHVwOEMrQVVtTTNLbVA2?= =?utf-8?B?Q0k5R1hWc1VKazJmWWZKZ29ZUGtzSDhyamt6SUpkdnl5b21naGtXbE1GL1g5?= =?utf-8?B?aEZZUFkvK2pBTVRsWEgyNjNSMlJubzUxSGFrdkNtdGEvTVRRSDdGbjFIbU9C?= =?utf-8?B?Umg5M3pjNW9BSDJNUE16N1dUWnFzeUEvRms4QzVySExBbjdoRFdZVU9IbFQ4?= =?utf-8?B?YXR1Vy9wRExTanBGTms0UzlpZGlra2dHL1hXV1VXZ1ZtVlkxaFBrZ3NQckRN?= =?utf-8?B?NlQreXBXdCtobVFWbk0wWDBUa2JkcGtDSjRNd0I4RlA5QlQzQnhBUkYydk9G?= =?utf-8?B?emxYczVPaTJvNDFZNm9mNzlwbHlYV0hMVUR0c3NFV3VTcnhQd2JJQi9WcWox?= =?utf-8?B?NEtFYWJreTBPM1RPS09VYzdUYUltRjF0Q29NbU0ydnkyUnVoMzM4aEFKLzVN?= =?utf-8?B?NjVjd3VHRHlQZEhpRVFTYXdNUWZ4MW5xcWowM3JLMWtlTTNrVjRNMzN3Q0l6?= =?utf-8?B?cmEyVnZxcVdZRnZQSXRZOFB1a2lsNGZOOW5obFNSeEppNFpqTFVLT2tWVTBO?= =?utf-8?B?Ym8vb1NOT25zUzFPeTlLKy9ORzBPbS9hT0FqUnhBZ3lUdTdHZml6TWJFaFdE?= =?utf-8?B?b3Z3YTIvRFBmQkM4UERFbUZ1Szl5dTJ2Z2NPUkQvZjV0MUNXVHFWOWlFeWxS?= =?utf-8?B?dVdnUmFUY1JZTHF4V0xjWEx3RU1aNldJbWtmdFlKdlFaN2VMdEJTcUNzcXJh?= =?utf-8?Q?1KjE=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dzBMU2xORysycHc3cys1bmlObWRUc1JFYWM1RzNmTmczVVJ3NS9XNzBIRWw1?= =?utf-8?B?WERZNHEvWk83RFZveHMyODZRRFhXUDI2MHRybmFsTUgwWnNMc0pSNVY4Qy8r?= =?utf-8?B?RHpPTVhHam5udVgyRG5OZ0JhMG5IY3BFRDRvNjNqSGpqVU14bCtBRm1jZGJx?= =?utf-8?B?cEVEdExZVWswdVhQMi9GMC9yaWd6Mk5SaHFxQmlXMFVsQ1dNdXVOUlhSUjRL?= =?utf-8?B?bmV3QkFuREZrTUJPdFpETGlDVlpqdG94cXVkakNkUDJYTXdmK0puTUlkdFpX?= =?utf-8?B?MFRpWkx0VEdINFBPME1jeHdwV09ud0pONWZqRmg2U2RRSk4rc2JDRnJkZmxH?= =?utf-8?B?V1cxYkhBMXFaQjU1RTBxeThqVk9xWmxMR0J5UXFRK2FROE5heW1GYXlaMlJP?= =?utf-8?B?TnhMcWw2MWdPVExmYXZTSmFMdjRHSm1ySHplaG1KRGFYOW5kOU15Mm9JOTEz?= =?utf-8?B?cStYVVVCZWFSMTJ1RDRYM0lraFU0WmhnMmlqRFdMMU5xWTB6UHNzRlVOWDJH?= =?utf-8?B?VDc5WGhTWDc4d1FpMUFBWUJwMUkzdFJ3bUlQVlZhUFBKN3BndDdSOEtvTWVt?= =?utf-8?B?SGVuM1k3QkxXaGlqYURiTFBpSjhBYldaTkNyQWtlVG1SYmJXa05YNzM3YjZI?= =?utf-8?B?ZjM4eDFjMDJrNDFSZmZCZS9OZ0RXRExzTG1YYVE5cWxlTUN1Rzc0ei91SWxG?= =?utf-8?B?clBrWmlSNlgxVUc4MDBLblU3YkhWVFpvQVlmYm8xZDdVWFVEZXBBak1obWdr?= =?utf-8?B?UjMwcm9RMkF2UThhOEg4ZDBPZ1ZMNW1TQ0lNNlRieVVQZXdJU0pLTWpOc0RI?= =?utf-8?B?b0JCUGdkUExFdUhNSGtWbDF4T2F2TFdFcGhFN2tPcnFVNFFwSngxN0lUS1A4?= =?utf-8?B?RkxQRVdMQ2lVc0s0emh1OGVYbEwxanpka3BrNVVaQ01zVUVnNWpJTG85Y2dw?= =?utf-8?B?YVFsb1ljVGk1a0dPOU12YlJZRGpxMjgrZm1UTllPN3BLSVVoUHg2b0l4SzZn?= =?utf-8?B?amRKbmg1azB6Tmc5TEQxYnlkUDFtSndKQTBRSHQyQ25qVGt0bTBUWjA4UURO?= =?utf-8?B?bnVudkxNSnlPOElZZW1iK0Y1YVB5UHZBNnQvWWxJVkg1ZDdJY1owalBFK0tP?= =?utf-8?B?a2Q0TWxFR3A1L0xBU0ZFMXFsUW9BbXJVb2MydXZDZVUxQUJzTlQySVRYMGxR?= =?utf-8?B?dHVNSExvT29GWHR5OUU0UmExdEZUcWRKOWc0NmxqbUNKQmJ0cURzV2RwZkFE?= =?utf-8?B?TVJxbStqMC9ZK3htNk12U2owdDB4QWlzeVl3cTNKemYybU5MYjhUNkpnUTlx?= =?utf-8?B?Y1I0L1hwTnFMWEl2MnRIMHpIaWpBUkJrYzhkY0RkSkJqcWlaQkFZMXdlNWlD?= =?utf-8?B?ZGFENjYrc3FEMXdFUVlOZlV6emxwdzdNOWl4QzZDMGZPRXAyZnlNRlhwQ2dK?= =?utf-8?B?Q3NBemlaRkVBbTJJaVlGRHlFSUNSMy9SNUJINFg4Wm1USndDd2dSMUxqM1h5?= =?utf-8?B?Kzc1V3lWelJlMHQxNTJBMzI0MGVDR1l1SytKVnRWNTlCMkpkcXliSWZoRUUy?= =?utf-8?B?eGhXZlVadkd3dG5LcGhDS2JRVjc3TjRRV3JwQmt0alUzWXc2U3k0L2VCZTVM?= =?utf-8?B?QVBzWkJ2dCtSd3N4aVpaMHFGaWZOOHJydFd5Q1FRRytDaFpnbnYxUmk1anNi?= =?utf-8?B?OUNobkZNTksweGFCQmtDOThrOWllem9aQzhlM3hBd0plWXE0RkFXL09zTm5P?= =?utf-8?B?NFdsNjlKTjlEa3RjZEVSUjhTdURMTVdyeTJFZDh2M3JxZk5zcmVPOTB5Tytl?= =?utf-8?B?ZUswei9vK1k2Y0drZ0t5emliYVdGL2FpTEI4Y3lGLzRwRjhxSVpNd0xGajhB?= =?utf-8?B?YWxZd2FnVXRPdlB0Y0x5TVdaV0dLVlZxOCtIUXorQzJ2UXJZQ1VXMmw0eit2?= =?utf-8?B?dzR2V3ZVZGxSOURBeHN3M3FiTjArbnBtSWNFOEppclE5bDhFVDdHQ0dkaEZ4?= =?utf-8?B?VjF3Z0FpVGlmaHlOQnNFanpOdVJ0LytQSXhKK1BRdGlWL0JGK25STDQ3NWNz?= =?utf-8?B?eEpuMURncDJ2Z1pua2oxWXJKc2J3dklpUFlhQUx1NCs5RDgvTWJnTzV0dE9L?= =?utf-8?B?YXNnRUhGMjQxbHlnYVpPcXBZR0QyZGxVUUh3a0p1MVRxbnpFSkxMOTZxOEZM?= =?utf-8?B?bTF6dEVtRzFtNk5WSjFMMTRqdm8rNFI2QzduV3JGNzdMZDllaUN4aU5iekYx?= =?utf-8?B?REVkWndpeE45R1h4THMwYi8xYTl4Yy9rOWhtTXA2eGlpOXRLTnBmSjBOTGNM?= =?utf-8?B?Tkl5UG8vRENMeWh4aG15SkRQbzUxRXo3Rm5qQ0Rwc0h3M2I2cEg2Zz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b64d5b5b-28d0-4475-137a-08de59b6fb7c X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 13:05:57.3291 (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: 8WKqmwZTpG07j2wqTCOs6MsU9+XYdCEhZJaqfFcWi+pNCEGm2H3P15/nDNb2Umb01kYgUA6lTkEqY7vCLbM3fg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR03MB7153 On Tue, Jan 20, 2026 at 08:25:49AM +0100, Jan Beulich wrote: > On 19.01.2026 17:13, Jan Beulich wrote: > > On 15.01.2026 12:18, Roger Pau Monne wrote: > >> The current logic allows for up to 1G pages to be scrubbed in place, which > >> can cause the watchdog to trigger in practice. Reduce the limit for > >> in-place scrubbed allocations to a newly introduced define: > >> CONFIG_DIRTY_MAX_ORDER. This currently defaults to CONFIG_DOMU_MAX_ORDER > >> on all architectures. Also introduce a command line option to set the > >> value. > >> > >> Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed") > >> Signed-off-by: Roger Pau Monné > >> --- > >> Changes since v1: > >> - Split from previous patch. > >> - Introduce a command line option to set the limit. > >> --- > >> docs/misc/xen-command-line.pandoc | 9 +++++++++ > >> xen/common/page_alloc.c | 23 ++++++++++++++++++++++- > >> 2 files changed, 31 insertions(+), 1 deletion(-) > > > > If you confine the change to page_alloc.c, won't this mean that patch 2's > > passing of MEMF_no_scrub will then also be bounded (in which case the need > > for patch 2 would largely disappear)? > > This was rubbish, sorry. Besides my being thick-headed I can only attribute > this to the double negation in !(memflags & MEMF_no_scrub). > > I have another concern, though: You effectively undermine ptdom_max_order, > which is even more of a problem as that would also affect Dom0's ability to > obtain larger contiguous I/O buffers. Perhaps DIRTY_MAX_ORDER ought to > default to PTDOM_MAX_ORDER (if HAS_PASSTHROUGH)? OK, yes, I can default to PTDOM_MAX_ORDER instead of DOMU_MAX_ORDER. > Yet then command line > options may also need tying together, such that people using > "memop-max-order=" to alter (increase) ptdom_max_order won't need to > additionally use "max-order-dirty="? At which point maybe the new option > shouldn't be a standalone one, but be added to "memop-max-order=" (despite > it being effected in alloc_heap_pages())? I had concerns about adding it to "memop-max-order=" because it's effect is not limited to "issued by the various kinds of domain", this is an option that affects all allocations. I could try expanding the option description to reflect that, but I wasn't sure whether it would lead to confusion (as all options there are per-domain currently). Also if added to "memop-max-order=" the parsing function needs to be adjust a bit to consume an extra parameter in the !HAS_PASSTHROUGH case (which is not much of an issue). Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 22 13:07:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 13:07:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1210994.1522557 (Exim 4.92) (envelope-from ) id 1viuPP-00074u-6i; Thu, 22 Jan 2026 13:07:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1210994.1522557; Thu, 22 Jan 2026 13:07:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viuPP-00074n-3V; Thu, 22 Jan 2026 13:07:35 +0000 Received: by outflank-mailman (input) for mailman id 1210994; Thu, 22 Jan 2026 13:07: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 1viuPO-00074h-DV for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 13:07:34 +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 4fe36d6b-f793-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 14:07:32 +0100 (CET) Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-432d28870ddso557062f8f.3 for ; Thu, 22 Jan 2026 05:07:32 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43596291e0asm16097810f8f.15.2026.01.22.05.07.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 05:07:31 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4fe36d6b-f793-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769087251; x=1769692051; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=yNTP+eYEmV3w6t6J7C5LKXYlmhLrORYUk+EXWQH+UNw=; b=UazU7fKR7uH8aZAsj2JU7eUk79xJG+OaBEgdtA4c/kGxdv72zwW8UAXm+zMLMfvTYn STIIF1/M/xBWjTajrf39mH1UxFS3H7XE0fif/uYVD9vgOGIYUc2nBqvpI+HykR/c3X98 gK6/oh060QYfroBpAqI1nCK6kLFIiDgNgr22ow+fnLXNP+5XN3G4WJQW+0ptH8ZiSP6T wrkXa/6CZu4c54tAAqrz7EzZb+UuUlHJjS72MQKPMax7Je92Cc9+jlpMG7umZOLd2Q46 kiS4Iwj4sSkzrG6vzCi0lF5x7/ckbukGSZzp9++hUsiKI5BolLH5C0B+m1jSnapGQe7A 6Cdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769087251; x=1769692051; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yNTP+eYEmV3w6t6J7C5LKXYlmhLrORYUk+EXWQH+UNw=; b=w+p7dhu6V2a47vpW1Ok4+KT4/22SfKo/SCTLteFV1OdrPaNOA6epajnl2tcyBaKVvc a46sJl3BQ6oiLnmsVkF2PgUGf+jYcVitMiQH8zscGHVfl0x07JflP4/UUcsFbyKFf4av X0L4dGoWxlPK2nh7EytC9EFDhbKTTVPVY8Zn5jHistO5XzPc8ZvhYJz4P2/HJTmPgymx R66Azv9m7aPjfxucoS201lZOxhVZSaLtykaCRvJDJpb7BwnNhPraJCbgyh4pbdWXLBYl XEYCRBmQQPfG/GFsNgtAEJKt9QNIJUnZkvbrAi2vYng75HIWaGvdGFE8Z/CTQo4eWPEo +VlQ== X-Forwarded-Encrypted: i=1; AJvYcCVSkHZ7ILMl+SDMujlE0MBt+UtCI1e9IiMMiW6HEgTHjL9Z9DzSk2OHB0kINvivqAWg4eKys8XjPBY=@lists.xenproject.org X-Gm-Message-State: AOJu0YwNgbgUVjqFa3ip3p1wb79a/YkXLcpms+TooOloKjOV4q0X07PN TKbH3T39ja1s+eWbQZUNkaMUgZUuOc3F/FsIoVzeXttrZE1Ekk5NmHKkIWjw2uDhHw== X-Gm-Gg: AZuq6aKXWiooZfEPHCoxVNZjfXtRmXxhDZpAIy5+WbKWgHK9MwQBy4k4Z62qvTcinmg mJIjKfyg4OV6YDaoFjsmObBNCPGFkuxV8jGahmIG6jl35S1SZjseP4FulosJGM28AzT9mkBrRJp jmMAOUt9ZTzsETCr7dFLD6TFJTGl9zzUaQU+i97dvSTQSQYlEpo5UCd49uOaajBTV2Wdpdrt0w7 tjTYMIjFQ9x9EqPCkfyiBI4vRx97so5AI0lUGfCUIg5hZreao6a1KRc8yjFurzJ9FlgLxiIp7zu 6R8kN3l6gSbSlaIm5OPZXH+jJtAa84AIYx4wr9TEEuxilKlEWjcR5JGqFaOTyMzBWpJeG5RoR7M +w5irSFAv7d/W3utUHu95xDHRfaOs9dP/6gjsyuT5SYzNNcFM3CoKHkWGXhU5tsO+5TZGcrW68H quKcnVH64S664ooRRaX9CHHlMvxX7e54fAwMIprt6S13rJIAWRLZ0WjOA8/hGrwmDODQv42+L8S jk= X-Received: by 2002:a05:6000:2505:b0:435:af89:11be with SMTP id ffacd0b85a97d-435af89120emr1402722f8f.15.1769087251523; Thu, 22 Jan 2026 05:07:31 -0800 (PST) Message-ID: Date: Thu, 22 Jan 2026 14:07:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/3] xen/mm: limit non-scrubbed allocations to a specific order To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260115111804.40199-1-roger.pau@citrix.com> <20260115111804.40199-4-roger.pau@citrix.com> <858d73b3-2feb-419f-bf3b-9a264e9f9af8@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 22.01.2026 13:55, Roger Pau Monné wrote: > On Mon, Jan 19, 2026 at 05:13:25PM +0100, Jan Beulich wrote: >> On 15.01.2026 12:18, Roger Pau Monne wrote: >>> --- a/docs/misc/xen-command-line.pandoc >>> +++ b/docs/misc/xen-command-line.pandoc >>> @@ -1822,6 +1822,15 @@ Specify the deepest C-state CPUs are permitted to be placed in, and >>> optionally the maximum sub C-state to be used used. The latter only applies >>> to the highest permitted C-state. >>> >>> +### max-order-dirty >>> +> `= ` >>> + >>> +Specify the maximum allocation order allowed when scrubbing allocated pages >>> +in-place. The allocation is non-preemptive, and hence the value must be keep >>> +low enough to avoid hogging the CPU for too long. >>> + >>> +Defaults to `CONFIG_DIRTY_MAX_ORDER` or if unset to `CONFIG_DOMU_MAX_ORDER`. >> >> This may end up misleading, as - despite their names - these aren't really >> Kconfig settings that people could easily control in their builds. > > But those have different default values depending on the architecture, > hence I didn't know what else to reference to as the default. I'm > open to suggestions, but I think we need to reference some default > value so the user knows where to look for. I agree something needs saying. In the absence of anything better we may be able to think of, perhaps simply clarify that these are #define-s in source, not Kconfig settings? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 13:09:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 13:09:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211010.1522568 (Exim 4.92) (envelope-from ) id 1viuRa-0007tI-KD; Thu, 22 Jan 2026 13:09:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211010.1522568; Thu, 22 Jan 2026 13:09:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viuRa-0007tB-HP; Thu, 22 Jan 2026 13:09:50 +0000 Received: by outflank-mailman (input) for mailman id 1211010; Thu, 22 Jan 2026 13:09:49 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viuRZ-0007t5-Hj for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 13:09:49 +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 a04c2676-f793-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 14:09:47 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-47ee4338e01so5862295e9.2 for ; Thu, 22 Jan 2026 05:09:47 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43569921facsm42863280f8f.5.2026.01.22.05.09.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 05:09:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a04c2676-f793-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769087386; x=1769692186; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=7OSGJaWFTQVWZfE69s8ozooWMhYaLI9iwnCjkHUWTpQ=; b=S/0M2GXVI08Wo7Ul/LkAgLXsgzdF8dV1yVmvyXE3lAz4TKZUD1swhbQP+n9ZF0s36d cLYDZHkn0uWm4vAVWm7ieBd64hlDJ0i8c7B7DGSiKzwmfierNTPRv88EsUu2SG16bGGN Q7QXUBIVMh8G622QHmXNA3XEcZ1xIR+h0Txznt9MV4cotTmaDXU91PupxdoNU3w8aifo RmD5tc8goa5ehroVj+Sy8opLSv2PhU53dr5C0eEcxfCjht2FYp06dhBSsEsNoKdpEJAF v/cixIW9+qnldGrpW3SSeZwZZcFS6UilGWulCR6B2UvCns8DWDdF/cRwRaIOqj054uax Urnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769087386; x=1769692186; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7OSGJaWFTQVWZfE69s8ozooWMhYaLI9iwnCjkHUWTpQ=; b=cYWf9WLAWFk1rGq9QHPoxUN0rk1WP5m3Qj2C0AbhwWxmRdvk6pZo5eEaLt/T9cGrA/ D+DE8isYE+eFhAUZk5C7H87Sn4vwsATM25T8bp+IJBdtb988wzLgYihGEiiWVIsxpivY R9Nc7Um2ln0icDZZEA0RoFSyQ2bCls+dxK417V3YupQi97oUG0yAEfqWwKOERbPZAyAl 8qZXYHpEO+jlnF8861Yxabyedte6IXY9YAGqW0ENI4TPwUP/rQiu73SKU0iIgQMcjn1o v+sI/sAgf8KEWL/khmVK0qp6ybW2Bu9u9FL6rTrtO2Di8qfzKpVIBORK2IS9z82OapBc jmwQ== X-Forwarded-Encrypted: i=1; AJvYcCXXLR0UpGEkXYivud7jozGQn7SR6k1LPaAENqJWmgeMjGSjUZpfGltZgyebHDvWgEnLkjLhuAw+NZ0=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx6J5IbG7Zz/IU0dEjalVnXZiYVufoOu3Xdq7SRG9Au+vwMVn66 2PEfBKyHLPyTnPa7NzmZmzOVAwfNqAE4GZ+MlzOL6+zBjcUt6CWQr6sBbjbdVQ/zIQ== X-Gm-Gg: AZuq6aIleeCaaTTAgFhzSmUBU03Uk8ZkWxNBXzJIkoYV9dnognc1775oDL7fv0Hvc2W f5RhIKrJFoyGECWzMnU9DumHlpMEQ73XUwYy2K+FMlAoKwOW0UAiCGzj8+0kKAtCT6YA1MbV1tp 1PO2rZUK+OSmTpg65ghR9DoQRT7sQyi30m4elnBtfESrHPdldWf6dImTy+aieuq2vviJW3K56Gu kJDR2+5XtQHg/B6/y0G0X2ACKX9kB6SmMa4llT38YzumBQPjgE9WxqcM7B3puHwq4KabkGl7WDU oPJVfsFHC+FQnQMmAkNJXtkv9mRaldG1Pl9UdHpJpsjUz63wcPH+FfM4aIMqWSXXe+oYH1pmLlT nO5mmX+xBzvldyqwyIYcaaD8WTGEmcyRnsaYurqDDd7UmuPJwiuqTwGgUipnZR0XJrF4kvJp7hZ 7EH8JzYpyLwqGx1h/8Wvazl2CQVX57qMGWaoa57ok+SpLJzXXJuln69DQZrUDFWamzwFypEYEE8 ts= X-Received: by 2002:a05:6000:2406:b0:430:8583:d189 with SMTP id ffacd0b85a97d-4356a051afbmr34449511f8f.39.1769087386472; Thu, 22 Jan 2026 05:09:46 -0800 (PST) Message-ID: <7a90ab94-3eb0-4d3f-8128-210baed60e3c@suse.com> Date: Thu, 22 Jan 2026 14:09:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/3] xen/mm: limit non-scrubbed allocations to a specific order To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260115111804.40199-1-roger.pau@citrix.com> <20260115111804.40199-4-roger.pau@citrix.com> <858d73b3-2feb-419f-bf3b-9a264e9f9af8@suse.com> <97127b23-4e4c-4b06-a8bb-b1dad31bf0b0@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 22.01.2026 14:05, Roger Pau Monné wrote: > On Tue, Jan 20, 2026 at 08:25:49AM +0100, Jan Beulich wrote: >> On 19.01.2026 17:13, Jan Beulich wrote: >>> On 15.01.2026 12:18, Roger Pau Monne wrote: >>>> The current logic allows for up to 1G pages to be scrubbed in place, which >>>> can cause the watchdog to trigger in practice. Reduce the limit for >>>> in-place scrubbed allocations to a newly introduced define: >>>> CONFIG_DIRTY_MAX_ORDER. This currently defaults to CONFIG_DOMU_MAX_ORDER >>>> on all architectures. Also introduce a command line option to set the >>>> value. >>>> >>>> Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed") >>>> Signed-off-by: Roger Pau Monné >>>> --- >>>> Changes since v1: >>>> - Split from previous patch. >>>> - Introduce a command line option to set the limit. >>>> --- >>>> docs/misc/xen-command-line.pandoc | 9 +++++++++ >>>> xen/common/page_alloc.c | 23 ++++++++++++++++++++++- >>>> 2 files changed, 31 insertions(+), 1 deletion(-) >>> >>> If you confine the change to page_alloc.c, won't this mean that patch 2's >>> passing of MEMF_no_scrub will then also be bounded (in which case the need >>> for patch 2 would largely disappear)? >> >> This was rubbish, sorry. Besides my being thick-headed I can only attribute >> this to the double negation in !(memflags & MEMF_no_scrub). >> >> I have another concern, though: You effectively undermine ptdom_max_order, >> which is even more of a problem as that would also affect Dom0's ability to >> obtain larger contiguous I/O buffers. Perhaps DIRTY_MAX_ORDER ought to >> default to PTDOM_MAX_ORDER (if HAS_PASSTHROUGH)? > > OK, yes, I can default to PTDOM_MAX_ORDER instead of DOMU_MAX_ORDER. > >> Yet then command line >> options may also need tying together, such that people using >> "memop-max-order=" to alter (increase) ptdom_max_order won't need to >> additionally use "max-order-dirty="? At which point maybe the new option >> shouldn't be a standalone one, but be added to "memop-max-order=" (despite >> it being effected in alloc_heap_pages())? > > I had concerns about adding it to "memop-max-order=" because it's effect > is not limited to "issued by the various kinds of domain", this is an > option that affects all allocations. I could try expanding the option > description to reflect that, but I wasn't sure whether it would lead > to confusion (as all options there are per-domain currently). Hmm, fair point. Let's keep it separate then. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 13:48:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 13:48:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211038.1522579 (Exim 4.92) (envelope-from ) id 1viv2k-0004w0-Dy; Thu, 22 Jan 2026 13:48:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211038.1522579; Thu, 22 Jan 2026 13: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 1viv2k-0004vt-9e; Thu, 22 Jan 2026 13:48:14 +0000 Received: by outflank-mailman (input) for mailman id 1211038; Thu, 22 Jan 2026 13:48:12 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viv2i-0004vn-FT for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 13:48:12 +0000 Received: from mail186-9.suw21.mandrillapp.com (mail186-9.suw21.mandrillapp.com [198.2.186.9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id fc47dae6-f798-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 14:48:09 +0100 (CET) Received: from pmta10.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail186-9.suw21.mandrillapp.com (Mailchimp) with ESMTP id 4dxj7X1X9FzK5vkCS for ; Thu, 22 Jan 2026 13:48:08 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 60ebe441a5b84f7b906ad5121b15d0da; Thu, 22 Jan 2026 13: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: fc47dae6-f798-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1769089688; x=1769359688; bh=hTDH/bCW4NxcGMHCphf3VXFB1sPxgz5d+CFEu1tvX44=; 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=p/O7GpaCI4Wp5r3cz+6BNdcMlpvIDIAxsziyasfFelyFn8gVx8hZF+69+Tw6zKhxR 63hTCHwlu2NQBja7kbVHrjSfE0+bmi9Oa6sCKPc7A+IJOgCquUs93S5CwhY3Kul8pM cXWx1XNG8A+Uei+bywhlrMT99ixBu0qZwhBNLXosVUhkEaXLx3tRgCjgqselZzmjqc MMzbgOITGmhOeeOwdmurbQAaT7UY5moDyS0vWa33Jpp45WC93pESNQbDVFQRyvsV1y V7jrDzFia8dlSGyJp7b/Ov+7Bs7VkGLGj3yRjOiBEx3eSUaDtszQeayELgOQr8z54y WXrusHfCnkLiA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1769089688; x=1769350188; i=julian.vetter@vates.tech; bh=hTDH/bCW4NxcGMHCphf3VXFB1sPxgz5d+CFEu1tvX44=; 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=gDQEOgXGqk9Hbw02Ilaf4Xg08WF3WFUdika+tOR5ESBC+s6ZTbchDw3pkdWK/Zc0W P9Ro2Bv/c/YRgi43VvcSDfT+sS7ezMRdov5A/cxvHMcsXoXp5bjAjo6dIxqRuN0zbu jeRa2xqLxyxYkoxB7Q0b6G39ZLZr+uIB3ptXV0ACv7jQEOg/4eTJWomEvH4jNwvBKH GnanaUchFrksN4dXfv844IFMNHNHeRSuQmPOguIcCss1WzruQyu2niKxfFyz/ygsPd rrOCLOnIuLELA4XlKb7MpXk+0ILDXeDJx2PsoQJECzir4Wx+ub+JKSYNT4oBwoUWJk f4+lzUuQVaOUg== From: "Julian Vetter" Subject: =?utf-8?Q?Re:=20[PATCH]=20xen:=20Move=20NX=20handling=20to=20a=20dedicated=20place?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1769089686711 Message-Id: <4a38c2ae-dc60-4fed-b30e-81a02b657e92@vates.tech> To: "Andrew Cooper" , xen-devel@lists.xenproject.org Cc: "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Daniel P . Smith" , "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" , "Jan Beulich" References: <20260115151658.3725784-1-julian.vetter@vates.tech> <69b511db-654d-46b3-aca3-3f37f30d3473@citrix.com> <335949fc-059e-477c-9b2b-ddcd2f144300@citrix.com> In-Reply-To: <335949fc-059e-477c-9b2b-ddcd2f144300@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.60ebe441a5b84f7b906ad5121b15d0da?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260122:md Date: Thu, 22 Jan 2026 13:48:08 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/19/26 20:01, Andrew Cooper wrote: > On 19/01/2026 10:34 am, Julian Vetter wrote: >> On 1/15/26 4:50 PM, Andrew Cooper wrote: >>> On 15/01/2026 3:17 pm, Julian Vetter wrote: >>>> +{ >>>> + uint64_t misc_enable; >>>> + uint32_t eax, ebx, ecx, edx; >>>> + >>>> + if ( !boot_cpu_has(X86_FEATURE_NX) ) >>>> + { >>>> + /* Intel: try to unhide NX by clearing XD_DISABLE */ >>>> + cpuid(0, &eax, &ebx, &ecx, &edx); >>>> + if ( ebx =3D=3D X86_VENDOR_INTEL_EBX && >>>> + ecx =3D=3D X86_VENDOR_INTEL_ECX && >>>> + edx =3D=3D X86_VENDOR_INTEL_EDX ) >>>> + { >>>> + rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable); >>>> + if ( misc_enable & MSR_IA32_MISC_ENABLE_XD_DISABLE ) >>>> + { >>>> + misc_enable &=3D ~MSR_IA32_MISC_ENABLE_XD_DISABLE; >>>> + wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable); >>>> + >>>> + /* Re-read CPUID after having cleared XD_DISABLE */ >>>> + boot_cpu_data.x86_capability[FEATURESET_e1d] =3D cpui= d_edx(0x80000001U); >>>> + >>>> + /* Adjust misc_enable_off for secondary startup and w= akeup code */ >>>> + bootsym(trampoline_misc_enable_off) |=3D MSR_IA32_MIS= C_ENABLE_XD_DISABLE; >>>> + printk(KERN_INFO "re-enabled NX (Execute Disable) pro= tection\n"); >>>> + } >>>> + } >>>> + /* AMD: nothing we can do - NX must be enabled in BIOS */ >>> The BIOS is only hiding the CPUID bit.=C2=A0 It's not blocking the use = of NX. >> Yes, you're right. >>> You want to do a wrmsr_safe() trying to set EFER.NXE, and if it >>> succeeds, set the NX bit in MSR_K8_EXT_FEATURE_MASK to "unhide" it in >>> regular CPUID.=C2=A0 This is a little more tricky to arrange because it= needs >>> doing on each CPU, not just the BSP. >> Ok, yes, I have modified the AMD side to use MSR_K8_EXT_FEATURE_MASK to >> "unhide" it. > > Great.=C2=A0 And contrary to the other thread, this really must modify th= e > mask MSRs rather than use setup_force_cpu_cap(), because we still need > it to be visible to PV guest kernels which can't see Xen's choice of > setup_force_cpu_cap(). > >> >>>> + } >>>> + >>>> + /* Enable EFER.NXE only if NX is available */ >>>> + if ( boot_cpu_has(X86_FEATURE_NX) ) >>>> + { >>>> + if ( !(read_efer() & EFER_NXE) ) >>>> + write_efer(read_efer() | EFER_NXE); >>>> + >>>> + /* Adjust trampoline_efer for secondary startup and wakeup co= de */ >>>> + bootsym(trampoline_efer) |=3D EFER_NXE; >>>> + } >>>> + >>>> + if ( IS_ENABLED(CONFIG_REQUIRE_NX) && !boot_cpu_has(X86_FEATURE_N= X) ) >>>> + panic("This build of Xen requires NX support\n"); >>>> +} >>>> + >>>> /* How much of the directmap is prebuilt at compile time. */ >>>> #define PREBUILT_MAP_LIMIT (1 << L2_PAGETABLE_SHIFT) >>>> >>>> @@ -1159,6 +1203,8 @@ void asmlinkage __init noreturn __start_xen(void= ) >>>> rdmsrl(MSR_EFER, this_cpu(efer)); >>>> asm volatile ( "mov %%cr4,%0" : "=3Dr" (info->cr4) ); >>>> >>>> + nx_init(); >>>> + >>>> /* Enable NMIs. Our loader (e.g. Tboot) may have left them dis= abled. */ >>>> enable_nmis(); >>>> >>> This is too early, as can be seen by the need to make a cpuid() call >>> rather than using boot_cpu_data. >>> >>> The cleanup I wanted to do was to create/rework early_cpu_init() to get >>> things in a better order, so the panic() could go at the end here.=C2= =A0 The >>> current split we've got of early/regular CPU init was inherited from >>> Linux and can be collapsed substantially. >> I have tried to add the logic into the early_init_{intel,amd}() >> functions. But it seems this is already too late in the boot chain. This >> is why I put into an extra function which is called earlier. Because it >> seems there are already pages with PAGE_NX being used on the way to >> early_init_{intel,amd}(). Because when I put my code into >> early_init_intel I get a fault and a reboot. What do you suggest? > > Have you got the backtrace available? Yes. Here it is. Although I saw before when enabling 'CONFIG_MICROCODE_LOADING' it faults even earlier, somewhere in 'find_cpio_data()', but with the same EC =3D 0x0009 (Protection violation, Reserved bit violation). Xen 4.22-unstable (XEN) Xen version 4.22-unstable (julian@work) (gcc (Debian 15.2.0-12) 15.2.0) debug=3Dy Thu Jan 22 14:28:58 CET 2026 (XEN) Latest ChangeSet: Tue Jan 13 16:50:12 2026 +0100 git:ce886ef641 (XEN) build-id: 2e72a4b08fca3ae0f0ed9af0dd3a5de947a966d0 (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 55 (0x37), Stepping 8 (raw 00030678) (XEN) BSP microcode revision: 0x00000836 (XEN) Bootloader: GRUB 2.12 (XEN) Command line: dom0_mem=3D1232M,max:1232M watchdog ucode=3Dscan dom0_max_vcpus=3D1-1 com1=3D115200,8n1 console=3Dcom1 (XEN) Xen image load base address: 0xb5800000 (XEN) Video information: (XEN) VGA is graphics mode 800x600, 32 bpp (XEN) Disc information: (XEN) Found 0 MBR signatures (XEN) Found 1 EDD information structures (XEN) EFI RAM map: (XEN) [0000000000000000, 000000000003efff] (usable) (XEN) [000000000003f000, 000000000003ffff] (ACPI NVS) (XEN) [0000000000040000, 000000000009ffff] (usable) (XEN) [0000000000100000, 000000001effffff] (usable) (XEN) [000000001f000000, 000000001f0fffff] (reserved) (XEN) [000000001f100000, 000000001fffffff] (usable) (XEN) [0000000020000000, 00000000200fffff] (reserved) (XEN) [0000000020100000, 00000000b9377fff] (usable) (XEN) [00000000b9378000, 00000000b93a7fff] (reserved) (XEN) [00000000b93a8000, 00000000b94bdfff] (usable) (XEN) [00000000b94be000, 00000000b98d6fff] (ACPI NVS) (XEN) [00000000b98d7000, 00000000b9bb0fff] (reserved) (XEN) [00000000b9bb1000, 00000000b9bb1fff] (usable) (XEN) [00000000b9bb2000, 00000000b9bf3fff] (reserved) (XEN) [00000000b9bf4000, 00000000b9d6dfff] (usable) (XEN) [00000000b9d6e000, 00000000b9ff9fff] (reserved) (XEN) [00000000b9ffa000, 00000000b9ffffff] (usable) (XEN) [00000000e00f8000, 00000000e00f8fff] (reserved) (XEN) [00000000fed01000, 00000000fed01fff] (reserved) (XEN) [00000000fed08000, 00000000fed08fff] (reserved) (XEN) [00000000ffb00000, 00000000ffffffff] (reserved) (XEN) [0000000100000000, 000000013fffffff] (usable) (XEN) Early fatal page fault at e008:ffff82d0403b38e0 (cr2=3D0000000001100202, ec=3D0009) (XEN) ----[ Xen-4.22-unstable x86_64 debug=3Dy Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: e008:[] memcmp+0x20/0x46 (XEN) RFLAGS: 0000000000010002 CONTEXT: hypervisor (XEN) rax: 0000000000000000 rbx: 0000000001100000 rcx: 0000000000000000 (XEN) rdx: 0000000000000004 rsi: ffff82d0404a0d23 rdi: 0000000001100202 (XEN) rbp: ffff82d040497d88 rsp: ffff82d040497d78 r8: 0000000000000016 (XEN) r9: ffff82d04061a180 r10: ffff82d04061a188 r11: 0000000000000010 (XEN) r12: 0000000001100000 r13: 0000000000000001 r14: ffff82d0404d2b80 (XEN) r15: ffff82d040462750 cr0: 0000000080050033 cr4: 00000000000000a0 (XEN) cr3: 00000000b5d0e000 cr2: 0000000001100202 (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) Xen code around (memcmp+0x20/0x46): (XEN) 0f 1f 84 00 00 00 00 00 <0f> b6 04 0f 44 0f b6 04 0e 44 29 c0 75 13 48 83 (XEN) Xen stack trace from rsp=3Dffff82d040497d78: (XEN) ffff82d040483f79 0000000000696630 ffff82d040497db0 ffff82d040483fd= 2 (XEN) 0000000000696630 ffff82d040200000 0000000000000001 ffff82d040497ef= 8 (XEN) ffff82d04047c4ac 0000000000000000 0000000000000000 000000000000000= 0 (XEN) ffff82d04062c6d8 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000140000 0000000000000000 000000000000000= 1 (XEN) 0000000000000000 0000000000000000 ffff82d040497f08 ffff82d0404d2b8= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000800000000 000000010000006e 000000000000000= 3 (XEN) 00000000000002f8 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000099f30ba0 0000000099feeda7 0000000000000000 ffff82d040497ff= f (XEN) 00000000b9cf3920 ffff82d0402043e8 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000e01000000000 0000000000000000 000000000000000= 0 (XEN) 00000000000000a0 0000000000000000 0000000000000000 000000000000000= 0 (XEN) Xen call trace: (XEN) [] R memcmp+0x20/0x46 (XEN) [] S arch/x86/bzimage.c#bzimage_check+0x2e/0x73 (XEN) [] F bzimage_headroom+0x14/0xa5 (XEN) [] F __start_xen+0x908/0x2452 (XEN) [] F __high_start+0xb8/0xc0 (XEN) (XEN) Pagetable walk from 0000000001100202: (XEN) L4[0x000] =3D 00000000b5c9d063 ffffffffffffffff (XEN) (XEN) **************************************** (XEN) Panic on CPU 0: (XEN) FATAL TRAP: vec 14, #PF[0009] IN INTERRUPT CONTEXT (XEN) **************************************** > > It's probably easiest if I prototype the split I'd like to see, and you > integrate with that. > > ~Andrew -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Thu Jan 22 13:52:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 13:52:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211047.1522589 (Exim 4.92) (envelope-from ) id 1viv6y-0006RY-U3; Thu, 22 Jan 2026 13:52:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211047.1522589; Thu, 22 Jan 2026 13:52: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 1viv6y-0006RR-PH; Thu, 22 Jan 2026 13:52:36 +0000 Received: by outflank-mailman (input) for mailman id 1211047; Thu, 22 Jan 2026 13:52: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 1viv6x-0006Qv-19 for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 13:52:35 +0000 Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [2a00:1450:4864:20::42c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 94d52166-f799-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 14:52:25 +0100 (CET) Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-432d2c96215so832248f8f.3 for ; Thu, 22 Jan 2026 05:52:25 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4356996dad0sm46002480f8f.27.2026.01.22.05.52.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 05:52:23 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 94d52166-f799-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769089944; x=1769694744; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=RzZ1gMh2XpKN7+QP8m00bK0rxa+qAEBlf8BXdkoaeag=; b=Ldv45Dqge3GgSsbdiLZ5djwEJtpQLtGjImu+WaVp79e5hh0VW02zHamV9+FxqDMiq3 gyezSchiR4uuc0NsYwU7RqfTVMky5yZwjLV7Z2JaV58/3J1g2HvMoTes3R+xg+mX7pzm YxNvGpxHVmHziWq51UMvWta+jyDEq5mRC8iFgKWBLbdqgv7LkeR260NN0Qh5HlWoJHRM 2AcYsLJ7dDNF/pOIfNk3Oh+56yFWvIZ4sHQnKEPnNqvlfjw+i9C4Pn2SnnaYIIwLWyxo AWjZveGoiFCpAVaVoY4l3ekSrl7VmJcLUe8mc8r/jSvw2XeSvEggkGpC0fboq8XqvZ1H kR9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769089944; x=1769694744; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=RzZ1gMh2XpKN7+QP8m00bK0rxa+qAEBlf8BXdkoaeag=; b=b20i4nTr5JY2Kg+HlqId824lerpaiBsru8L1+B7VmsCIEqhwCPfvpw1f399b16GpWD W/tcVjeE9aUF7BCeYoAqEmduayKPSgKGYjhRPFxeyVEabV9uZrugzRz+AUcZI2nNK2Dv MdidZMuXxambGoU9C5q4hAnGiuE4GZruU4vUKqZ56a6PRRKRec/BFdqvTEj4sawuO6Oa x6Mo6IqoESHl0K5u1s/HKk+cqUQfzrL7YrZkHk/4w51KZiv7EMXsrlIDhjWqLLJoFxpe g5BrCet5YOtqFwznmP3FXrpSfJp1dGoHKGvpl8Y7NCwTAjsRW7S0LKoOAftCaltiS7kA lmig== X-Forwarded-Encrypted: i=1; AJvYcCVAk/pa6C5EhVKCUUx9J7zjSj5GxsGsTOd4Mkj2gQAT36RmaYq+j7j700l6SlXxU+jjh7wBddoeD44=@lists.xenproject.org X-Gm-Message-State: AOJu0YwIer+vVBKdoRc9Co+u1VZ8SdZjKqKpafEzU8asN9bLqmoQR6cZ XdqIn9Oa5sRTHcrE2D2Aqq12hw/D6aYWwr9VivNSnow5qWdymwewTdfBrnzMOQQmMw== X-Gm-Gg: AZuq6aLwFCe3xivZ3g0kMWs6I3AHRHdCOFHNQ7sTWHUnKW0YgeCKV+49ZIp1Y+m20k7 EGywfnjKATp4CDu87mAL8b7WabQWvyCGPwUqMdVJK6Pd5ti1+i8ebZN2dr18E9iueYwvTFurJqS YgYIw/QBes1id6Z4A4hYlhOLacDixWy8WSTat2TXzSY3JstagsRsCRWgdcfrjXpipHeCJ863GS5 UC9nJ5KMXduHOdEnSS5kmeeebW79h8IHTahlpg3zri4vmwT+SlLr4YAk6RPlAGOGJCc0avvZzUU Ue89pyOSlxjIBh0VTOyeO0mXHs6dtBPXPk4qbZq2HNzDDNJnGPKrkVE+ur4k+f7xQ1uvw4EkIyr Jsk0h/LsMFSCzP/bKpxRccwhY4Ayrp9Cm2c9++qPx72J4xTSf78ZRvqT+75Rteds06pY+DRCkRz ZwQVmCa6gNY3sXAkGNb09anOKxz1iUa4g1xmelF5LaTjEOcNpFlInFwPwGST1tApFGbQgxb9ylW Zs= X-Received: by 2002:a5d:588a:0:b0:431:62:d946 with SMTP id ffacd0b85a97d-43569999473mr32504416f8f.23.1769089944119; Thu, 22 Jan 2026 05:52:24 -0800 (PST) Message-ID: <912ff342-f5aa-44fa-8a91-43be4363776e@suse.com> Date: Thu, 22 Jan 2026 14:52:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6] xen/console: handle multiple domains using console_io hypercalls To: Stefano Stabellini Cc: grygorii_strashko@epam.com, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Victor Lira , andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 22.01.2026 02:34, Stefano Stabellini wrote: > Allow multiple dom0less domains to use the console_io hypercalls to > print to the console. Handle them in a similar way to vpl011: only the > domain which has focus can read from the console. All domains can write > to the console but the ones without focus have a prefix. In this case > the prefix is applied by using guest_printk instead of printk or > console_puts which is what the original code was already doing. > > When switching focus using Ctrl-AAA, discard any unread data in the > input buffer. Input is read quickly and the user would be aware of it > being slow or stuck as they use Ctrl-AAA to switch focus domain. > In that situation, it is to be expected that the unread input is lost. > > The domain writes are buffered when the domain is not in focus. Push out > the buffer after the domain enters focus on the first guest write. > > Move the vpl011 check first so that if vpl011 is enabled, it will be > used. In the future, the is_hardware_domain path might also be used by > other predefined domains so it makes sense to prioritize vpl011 to > retain the current behavior on ARM. As indicated elsewhere already, I think this wants moving out of here. A question is going to be whether the consoled part then also wants moving ahead (albeit I fear for now I don't really understand the need for this movement, seeing that the is_hardware_domain() check there remains as is). > Locking updates: > > - Guard every mutation of serial_rx_cons/prod with console_lock and > discard unread input under the lock when switching focus (including when > returning to Xen) so that cross-domain reads can't see stale data > > - Require is_focus_domain() callers to hold console_lock, and take that > lock around the entire CONSOLEIO_read loop, re-checking focus after each > chunk so a focus change simply stops further copies without duplicating > or leaking input Shouldn't this then ... > - Hold cd->pbuf_lock while flushing buffered writes in the focus path > so the direct-write fast path does not race buffered guests or HVM > debug output (What's ->pbuf_lock again?) > --- a/xen/drivers/char/console.c > +++ b/xen/drivers/char/console.c > @@ -540,6 +540,11 @@ void console_put_domain(struct domain *d) > rcu_unlock_domain(d); > } > > +static bool is_focus_domain(struct domain *d) > +{ > + return d != NULL && d->domain_id == console_rx - 1; > +} ... be expressed in a comment here as well (or even an assertion)? Also please make the function parameter pointer-to-const. > @@ -599,14 +611,25 @@ static void __serial_rx(char c) > if ( !d ) > return; > > +#ifdef CONFIG_SBSA_VUART_CONSOLE > + /* Prioritize vpl011 if enabled for this domain */ > + if ( d->arch.vpl011.base_addr ) > + { > + /* Deliver input to the emulated UART. */ > + rc = vpl011_rx_char_xen(d, c); > + } > + else > +#endif > if ( is_hardware_domain(d) ) > { > /* > * Deliver input to the hardware domain buffer, unless it is > * already full. > */ > + nrspin_lock_irq(&console_lock); > if ( (serial_rx_prod - serial_rx_cons) != SERIAL_RX_SIZE ) > serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c; > + nrspin_unlock_irq(&console_lock); Hmm, now that there's more context here: The comment looks to still be correct as per the enclosing if(), but how does that fit with the purpose of this patch? Isn't it part of the goal to allow input to non-hwdom as well? > @@ -742,18 +761,25 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, > if ( copy_from_guest(kbuf, buffer, kcount) ) > return -EFAULT; > > - if ( is_hardware_domain(cd) ) > + spin_lock(&cons->lock); > + nrspin_lock_irq(&console_lock); This double lock (and the need for this specific order) might better be commented upon, too. > + if ( is_focus_domain(cd) ) > { > + if ( cons->idx ) > + { > + console_send(cons->buf, cons->idx, flags); > + cons->idx = 0; > + } > /* Use direct console output as it could be interactive */ > - nrspin_lock_irq(&console_lock); > console_send(kbuf, kcount, flags); > nrspin_unlock_irq(&console_lock); > + spin_unlock(&cons->lock); Why is it that this lock can be dropped only here? It's not needed anymore past the if()'s body? > } > else > { > char *kin = kbuf, *kout = kbuf, c; > - struct domain_console *cons = cd->console; > > + nrspin_unlock_irq(&console_lock); > /* Strip non-printable characters */ Blank line between these? > @@ -824,14 +856,16 @@ long do_console_io( > len = SERIAL_RX_SIZE - idx; > if ( (rc + len) > count ) > len = count - rc; > + nrspin_unlock_irq(&console_lock); > if ( copy_to_guest_offset(buffer, rc, &serial_rx_ring[idx], len) ) > - { > - rc = -EFAULT; > - break; > - } > + return -EFAULT; > rc += len; > + nrspin_lock_irq(&console_lock); > + if ( !is_focus_domain(current->domain) ) > + break; > serial_rx_cons += len; The placement of the check between both updates wants commenting upon, imo. Another blank line or two would also help, I think. > } > + nrspin_unlock_irq(&console_lock); > break; > default: > rc = -ENOSYS; Much better locking-wise here than in the earlier version. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 13:57:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 13:57:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211065.1522599 (Exim 4.92) (envelope-from ) id 1vivBz-0007Ea-JN; Thu, 22 Jan 2026 13:57:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211065.1522599; Thu, 22 Jan 2026 13:57:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vivBz-0007ET-FY; Thu, 22 Jan 2026 13:57:47 +0000 Received: by outflank-mailman (input) for mailman id 1211065; Thu, 22 Jan 2026 13:57: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 1vivBy-0007EN-Su for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 13:57:47 +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 5315cee0-f79a-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 14:57:45 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BN9PR03MB5961.namprd03.prod.outlook.com (2603:10b6:408:132::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Thu, 22 Jan 2026 13:57:41 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Thu, 22 Jan 2026 13:57: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: 5315cee0-f79a-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=C1o1cAPkIj+Ci03DwE6Cnkk56yEqTSP55dJHG4c3yZar4F4oDRthejUZMcUGP1qq58yOrdGx37627OCYwFEAAggHBwBmIiivrm/o87AplK2pigxg4Z3KnhwrnXzZIIV7eZJFg+ymAhZnBEoKt4lxFASnfLEF2WXcaynWu8GNmB3feDYC9k9VwTaepAH4p0i2NRAQh4zq5wIEfhNGq33kpItACLFim8+NiNpdO5rsqPvgkUXqC+ybksbVHbeR0EM6ktQxztrLXBcXOWVXEl4tO1OjLv4qWUyqoKXFExrQP6JISu2Mg0efU6c0ylaBf2PX1eEcoiTP3rZU5yBIqLQmxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=t1FFRucpM+bdPc7KImaXQWQqKD8h7VBjbhr+XSgUbQY=; b=XkUFLpckiUkilZjHn3eZNIOQn7UsjQfcfezWcvnbAzq+8WrWpFautwLbGMsWKG2bHlRO5Q546YoAThKOVrWKPpnyPHKb3T/Lj5wBAPQW3jkW6ItbNlQPdtfl+Cqzx4ZEMUJXXMct+Ho1xb9BTV1EI4+VwMDylP4L73mS+UVUcbeUnFm2SB9SKcPXnRjoC8GsjiEDfey0/NWEYQ2un+3j+kMLvMF1m4UTuyTiPdhKZpcR2b19sbYHJ4CfpAK0bzkshn+13j+EK1zdI4NUm9bWaN9NhOWpd+gyGuc4MiA3SwHQA9fy4HgAII206SgRfs+ickucReDREwbFXj1UoWkUFw== 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=t1FFRucpM+bdPc7KImaXQWQqKD8h7VBjbhr+XSgUbQY=; b=n4JimyYLUb6t53tBzNdqVUCDo09jHwcS9PqqkljU/au5YDdd8+R8ebbYlpZaY1YuYOVd4NCVQ3Y3ZmYJj4pLUpWb+yhNXuG6tAGoL+tDeiBq+WOoNW/34gd1PCl+vb+/y11e8Bguzj6eMSVZps9fdyB72HqNTapsEZg4PvW4TWI= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <92c02d2f-ccc5-42ce-ba0c-076fdc75e1fe@citrix.com> Date: Thu, 22 Jan 2026 13:57:37 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P . Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Jan Beulich Subject: Re: [PATCH] xen: Move NX handling to a dedicated place To: Julian Vetter , xen-devel@lists.xenproject.org References: <20260115151658.3725784-1-julian.vetter@vates.tech> <69b511db-654d-46b3-aca3-3f37f30d3473@citrix.com> <335949fc-059e-477c-9b2b-ddcd2f144300@citrix.com> <4a38c2ae-dc60-4fed-b30e-81a02b657e92@vates.tech> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <4a38c2ae-dc60-4fed-b30e-81a02b657e92@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0055.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:153::6) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BN9PR03MB5961:EE_ X-MS-Office365-Filtering-Correlation-Id: e53c4833-cfba-4974-1485-08de59be3593 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?TTNZc25DZTlFZDJuYXBmWnE3T3o2NGc3OWZQZGdoSWZoKzJpUEhVL204NE1p?= =?utf-8?B?N3ltL1hNUklYOFF6a1NLOW92dnhrTWlWU1FxN05ndE9BWWd2SSt3b01kckhE?= =?utf-8?B?ZGFHbzJ5WWU1Y3p3eFJ4blBYUjArZjVvRWVnZDljRmFBTjJSTjJHbTYyeTBn?= =?utf-8?B?V0FybGY5cHdvRDlqTHU1b2YzUlJsNVc5aml5MDczSnQrVWwzcTVLYTVhMkRp?= =?utf-8?B?ek9rMy91QllTMUhZUi9hME1WTTRWODlPUkdYbXlvRTVsOVZOb1ZBUFFvbG5J?= =?utf-8?B?Uk0wcHdxMjkwQ1Q2Q25PTHlscXZMMjJScWp5ZlhpbG43TWJxK1VLOHA0V0dt?= =?utf-8?B?bDh4NDdiTkxJWG1VUHB6eVZiSlFadTlsazlwWlNiR0E2R1k0bVlIbHg0UWZ1?= =?utf-8?B?ZEczaDlXaDU3RXk2d0ZYaE1pMTRDWGJodjN0NGlmMmdXeUI1M25KZGVZeVh3?= =?utf-8?B?UXNLNGtkbEhWOVgwbFBNY0ZOWFNPVHQ1ZmtrU1lSVGp5OE10WnZCVEJTYlBH?= =?utf-8?B?N0lDMmxoZDBON0xQS2ExQnVVc3hWb29yb0hKQjAvSFF0NzIyQnZ5Z0JFZzB4?= =?utf-8?B?Slc3bnd3cEJRaStEUXdiaDMvSm9GeExvM3JFQlJLUGJ2RXovR2VIWHdIWjV6?= =?utf-8?B?YTBQbktzdzlWbi9DY1FYY3V6Nkh3YzJqWU1hMzdTNXYvd2Q1eEN5OEdLTVBL?= =?utf-8?B?NGpLb2gwZjNuYVNVSlVUNXZNVHJQcExzTTRsLzlpTTZobWR4Yk5veENiQytk?= =?utf-8?B?SnBvVGplSEswWGNOVXpoS2lhK1I2Zzh1MDg3N1RxOXhHS1NXZndDelRYYjhu?= =?utf-8?B?Slk4UVN3Q01Jd0w3T1pOa1QrSXBma05qWldWNlFFYmVmZ1hJS1l0TzI2ZWRy?= =?utf-8?B?amhhOEVLMld1WXZINUZ2QUVTVWpYcDZWNVVKSTFEVWJPanA3bjVQTW1yclk4?= =?utf-8?B?UzFXTmxVd0xGd0V2amRwbTlvYnhvOEpROVVIZTlianAxR2VLMG5iQnNMUG9i?= =?utf-8?B?N0dmNzlFeng2eTk5MG43RjR6OHFtREQ4bUtGTWVKZzI1N2UrV0YvL2FTTGQ5?= =?utf-8?B?bnlQc29HNDdJTEl3b0tEOFhNSHRHRGFzRkpSWEl3RzRabldoejdiOFlKcDZQ?= =?utf-8?B?QXBtMmx5aU9FaUlRRTg5UEVqM1V1MHJRQi9wWTE4N1YzWm5kOVdHTmNCQzBB?= =?utf-8?B?TThuM2k2d0FXSnlhMWluWnUwQlZKeVh4OHZxVkt6by9yd0xTQytySnM3c253?= =?utf-8?B?bU53RU9TcUErb2F1NHNCRU5YZlM5T3ZyWEFuSjdPVERTL0lCOWFITksyQ1FK?= =?utf-8?B?cTFqSk9aSUJscGVxTW9XNlpwUUJQMnl6djJ2SkFEU1ZZUmE5akFLMkpMTU5O?= =?utf-8?B?VzZCdzdQWmxycUpjQ3NGSlBRYnl6TEdOc1VRay9EWVpOUzhqeXI4RFV0YTV1?= =?utf-8?B?WU9wTlZFRjdiUTFvUUFOMmxMRXVsQ1hBN2VCN0pEMmM4ZTVzZ05Zd0lCblkw?= =?utf-8?B?V3A5V2lFQ1VtWGdTaHlJOTJaeVpSZlhlY2d0UXNOaGVPT3NIMXBzQjk0SE93?= =?utf-8?B?MWQvSkRoUjBWdHRibG8wNGN6L0ZoQkNmaGszUVFsdG5qRWNXMEFZeGlPQUY0?= =?utf-8?B?b3hmZ2tFMEdBY3ExdGFKUnVObytGNnlqeXREbTFzTXcwcFpLYld4VnUvSzR3?= =?utf-8?B?NEhpMWw5bEh3M0trRTFwMFpPbEovazFuUmdGUzJaR2ljNzdnUmVkaVpQZEo1?= =?utf-8?B?WGhVVUFCWXZLMExaTjlMTk9iVzc4MEY5V1R3SjVSZENNb2VWWitaTEorcDE5?= =?utf-8?B?L2hHTVZmZTJBRXIrK2lXblNVSXZ4U0Fndmp5VUJBQytoNnB6R3RsOFlPUnRY?= =?utf-8?B?VFVMNysxSG04ck9zYVZwZm9FdFB3ZHp4TiszQlhTUUFDRm1iOWgxOHJGM1J1?= =?utf-8?B?UERXbVZNTzQ1eW13VXcvZ1YycjRySFlEV0p1UG9XQjN6SFRDaW1scTRSZU5J?= =?utf-8?B?aFA2SWgzTlA4L2N5eUJOaTNDZUhqTnJaUWNBazlTYTVUYnEzRkw3VHNkMUha?= =?utf-8?B?OUJQcnJxdHZHM3dLYlMyOTRheGVqajBiemUwVUszMnVyT2tQbm1BbEVEa292?= =?utf-8?Q?LAaM=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?a2F3U0ttM1FWeGJuWmhtMVBTd1RHZFgzOHlSUHhEaG5LMU8rNlFkTGU5SjNB?= =?utf-8?B?SlY0cnU0azJJak5pSWs3YnVXcmlWTWoxbEZqM0VmcW5VZmRJSEFqaFh1dGpN?= =?utf-8?B?eUJhQ3BRVjVyYWRjaVdZU2puSFpoOEVINGxzWm9YMTY4NFgxMFJTRGhwT2NE?= =?utf-8?B?cG83N3g5cm5WUFc1NlJtN2ZOV2RIb3BCMHNZTlY4K2ZXbFpnZEpsK3RNRWdu?= =?utf-8?B?UldvS25wM0lRa25yMFJGakx4TnBmdWQrckhUandiUTV1cUVJL3hjbFBPWTFM?= =?utf-8?B?dFpLM1hDQlJnMVFyL25HL0tqY2I1WHBJVEJGQ2tPWmlDcUVKdE85Nk92cWJS?= =?utf-8?B?Z0FJcGo1aUc4c1djd2drVVVYSy9pazNzQXljUTBhU2VQZGJVTGZxU0tIaVoz?= =?utf-8?B?d3ByYU9ZOGJzQUFwaVJndDk0YlQ3MU5nbStSaE5QeHpCOHArZThYWHZnVkJ2?= =?utf-8?B?SEpHTG9jVFVEbVh2bUJxS0xDQUFLaXBNZU51K0ZFRDFhVWpnQ1BNYmtmT1Mr?= =?utf-8?B?dnIyb0NNdHN3aWIvQnhXL2lsMk53NnpRNDdBcHFzL2ZpcFpZR0czWTYyTURk?= =?utf-8?B?UVIxNS9tS1FKYXRZRXY3QXFEQkFYazZQWHV2bGRxOE8wclM0WERiOVdidFdQ?= =?utf-8?B?c0VUUkVKZWhvUHR6cUhrcE9NaWdTbXhINkRUN1FGblpZRWE5OVU1NzlOdUNi?= =?utf-8?B?dnBibmd3WmNwVHZXQTYvRXB5UVlOWHVXc0o4SDNaYmQ2TkN5T01sYjdSMkNp?= =?utf-8?B?UCtMSmdCUnlpVkpQdm9vV1hXSC9JVDhnNVltUStnb2VoZk43K3o5VXQyWUo2?= =?utf-8?B?NUNwZ2pOWjYvNnR3SGxsNzM4WXhUWjllS2pBWDNJdVU5WEFlSHRkN0F2MXEz?= =?utf-8?B?TXRjQmVkVklJR2hmTG8vWE90Q2h5aitHOXl2YllJQ096My9rdjVjN0ZtaW5Q?= =?utf-8?B?ZXdFcDBiRjdidG91NWRxU1FqZ1JIZlN1eHBQUE5RYjZwVno0RnQ0R0pHRzM2?= =?utf-8?B?RkxOeXlDcXkrV3FNdHl5VVlUOTRtM1g4QzhOUG5VckN1bjkwcXJOSzU0TU8v?= =?utf-8?B?YVl4OFdhTHBkZlFSSDRmaHlpSTNJZkFDbExKZmtqbWhieDFqVkpNZklRNFhi?= =?utf-8?B?aWRORmUzZFdJZFBZUFYxY21EYWFPc2pwNHlqSFZwc25TVE1qVTF5d1NySEZw?= =?utf-8?B?aXJYZW5iaEJ0MUEyK1JCbTY5bjUvaVZhdCttK1FIc3Zxck5pOFV0SjhNdUJR?= =?utf-8?B?Ym03elM4aFBDQ1grSWZvK0lJTFRPcS9EaVo4eVY0R1lHUFJpMjN3Qmg2MTdE?= =?utf-8?B?eFVaT0hOYXVxdVF2bzFraU52R1hjNnQwNjdYWlBZV3dJMHpvWERBWUxyVVNx?= =?utf-8?B?NGVweHlQWGZYOXdNQ3BVQURsK0pEUGljV3Q3d0g5RkZzQW5MeTZqVkMxb3ll?= =?utf-8?B?QndyTEFPYkUzYVlPYitZVFM3MmlmMTBCRXBPaWhWVmxEVzhlTEcwSWhnNnU3?= =?utf-8?B?SVJHNHRTd1c2RDdVMXJ6NWxQbXFZb2lDUXc4endhTXNwWnhzWHNFSnE5bHJq?= =?utf-8?B?R1dTMnh1SHFVbkJodkpOQXB0Vm9EZjNvWGZrSDYwanJTeWEvSGJLbCt4eUk1?= =?utf-8?B?RDh4azZZVjQ0TU8rT0FIT202cjBWOVV6Wll2bUF1SmtBajdZY2lXTFhMQVp4?= =?utf-8?B?L1NPTXFCMzY0R3hUWk9xUHd1RStWN0Vnbkdta3MvTGdXa1M1bUVuWUJPU3pD?= =?utf-8?B?Sm1EVk1VMmNmSXRTSzc2eGZlNDFWejNkTHc2bEZHT1VNN1d6UkV6c3V5cjBv?= =?utf-8?B?YlpXNW9FZjNpWHFCNWZkR0dtS05sM3MrYkx2d29sczRzM01zVUNsTEdXZitX?= =?utf-8?B?NDM4VnpYS2pveEg2aDZkdWFJQXRySlIycGNWUUJRblRLeFdRTVE2SnNUVVV6?= =?utf-8?B?R0RqSWQvZ2xRSjZXWEVlWGVsWUYyYUxOZlhkQ3o0eTN0alhFaStzMHlveS9E?= =?utf-8?B?TUhLU1RkYVJRQjd3WWQ1Q2x5ZUZEM0ZwcVp4YW82c0dJb1hSOS9nam9QYzFu?= =?utf-8?B?dStSenRRYVdZRDZrazVoNWRhcFZtU1c2RU9MN04xNGZRTmZxc2NTVjl6UFdj?= =?utf-8?B?RjZBN3VOejJaTVlGVTI3YmtFa2crdTRWNEdKdEEwamZZMG1reThWdjg0U3Bh?= =?utf-8?B?aU5sVjVWUVVKV1hMd0NJS3d6OWkrTys4YWpLaU1MT2hrZWNzZUxYc2ZBUGdk?= =?utf-8?B?ZFMxaGx2S2dRckJCdS8xanNvZ1YvTFdOU2swS2txZjI3MHkvKzF5YVNxd0lq?= =?utf-8?B?YU9MSUkwU2tMT2dMT0djVUgzSDBuRkhNeS94RmxHS2NNbk1vNHJRQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: e53c4833-cfba-4974-1485-08de59be3593 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 13:57:41.1473 (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: /gpLcgzoHFHKipvmeTgb0yOnj+TosuGXWb7iPIIXisjPKWJYLQIiDTDMTCg6xgtQSu6bXSAh1SVIKR/PvgwJYdgdFm2LsOc2H9uboshJ8Ro= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR03MB5961 On 22/01/2026 1:48 pm, Julian Vetter wrote: > On 1/19/26 20:01, Andrew Cooper wrote: >> On 19/01/2026 10:34 am, Julian Vetter wrote: >>> On 1/15/26 4:50 PM, Andrew Cooper wrote: >>>> On 15/01/2026 3:17 pm, Julian Vetter wrote: >>>>> +{ >>>>> + uint64_t misc_enable; >>>>> + uint32_t eax, ebx, ecx, edx; >>>>> + >>>>> + if ( !boot_cpu_has(X86_FEATURE_NX) ) >>>>> + { >>>>> + /* Intel: try to unhide NX by clearing XD_DISABLE */ >>>>> + cpuid(0, &eax, &ebx, &ecx, &edx); >>>>> + if ( ebx == X86_VENDOR_INTEL_EBX && >>>>> + ecx == X86_VENDOR_INTEL_ECX && >>>>> + edx == X86_VENDOR_INTEL_EDX ) >>>>> + { >>>>> + rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable); >>>>> + if ( misc_enable & MSR_IA32_MISC_ENABLE_XD_DISABLE ) >>>>> + { >>>>> + misc_enable &= ~MSR_IA32_MISC_ENABLE_XD_DISABLE; >>>>> + wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable); >>>>> + >>>>> + /* Re-read CPUID after having cleared XD_DISABLE */ >>>>> + boot_cpu_data.x86_capability[FEATURESET_e1d] = cpuid_edx(0x80000001U); >>>>> + >>>>> + /* Adjust misc_enable_off for secondary startup and wakeup code */ >>>>> + bootsym(trampoline_misc_enable_off) |= MSR_IA32_MISC_ENABLE_XD_DISABLE; >>>>> + printk(KERN_INFO "re-enabled NX (Execute Disable) protection\n"); >>>>> + } >>>>> + } >>>>> + /* AMD: nothing we can do - NX must be enabled in BIOS */ >>>> The BIOS is only hiding the CPUID bit.  It's not blocking the use of NX. >>> Yes, you're right. >>>> You want to do a wrmsr_safe() trying to set EFER.NXE, and if it >>>> succeeds, set the NX bit in MSR_K8_EXT_FEATURE_MASK to "unhide" it in >>>> regular CPUID.  This is a little more tricky to arrange because it needs >>>> doing on each CPU, not just the BSP. >>> Ok, yes, I have modified the AMD side to use MSR_K8_EXT_FEATURE_MASK to >>> "unhide" it. >> Great.  And contrary to the other thread, this really must modify the >> mask MSRs rather than use setup_force_cpu_cap(), because we still need >> it to be visible to PV guest kernels which can't see Xen's choice of >> setup_force_cpu_cap(). >> >>>>> + } >>>>> + >>>>> + /* Enable EFER.NXE only if NX is available */ >>>>> + if ( boot_cpu_has(X86_FEATURE_NX) ) >>>>> + { >>>>> + if ( !(read_efer() & EFER_NXE) ) >>>>> + write_efer(read_efer() | EFER_NXE); >>>>> + >>>>> + /* Adjust trampoline_efer for secondary startup and wakeup code */ >>>>> + bootsym(trampoline_efer) |= EFER_NXE; >>>>> + } >>>>> + >>>>> + if ( IS_ENABLED(CONFIG_REQUIRE_NX) && !boot_cpu_has(X86_FEATURE_NX) ) >>>>> + panic("This build of Xen requires NX support\n"); >>>>> +} >>>>> + >>>>> /* How much of the directmap is prebuilt at compile time. */ >>>>> #define PREBUILT_MAP_LIMIT (1 << L2_PAGETABLE_SHIFT) >>>>> >>>>> @@ -1159,6 +1203,8 @@ void asmlinkage __init noreturn __start_xen(void) >>>>> rdmsrl(MSR_EFER, this_cpu(efer)); >>>>> asm volatile ( "mov %%cr4,%0" : "=r" (info->cr4) ); >>>>> >>>>> + nx_init(); >>>>> + >>>>> /* Enable NMIs. Our loader (e.g. Tboot) may have left them disabled. */ >>>>> enable_nmis(); >>>>> >>>> This is too early, as can be seen by the need to make a cpuid() call >>>> rather than using boot_cpu_data. >>>> >>>> The cleanup I wanted to do was to create/rework early_cpu_init() to get >>>> things in a better order, so the panic() could go at the end here.  The >>>> current split we've got of early/regular CPU init was inherited from >>>> Linux and can be collapsed substantially. >>> I have tried to add the logic into the early_init_{intel,amd}() >>> functions. But it seems this is already too late in the boot chain. This >>> is why I put into an extra function which is called earlier. Because it >>> seems there are already pages with PAGE_NX being used on the way to >>> early_init_{intel,amd}(). Because when I put my code into >>> early_init_intel I get a fault and a reboot. What do you suggest? >> Have you got the backtrace available? > Yes. Here it is. Although I saw before when enabling > 'CONFIG_MICROCODE_LOADING' it faults even earlier, somewhere in > 'find_cpio_data()', but with the same EC = 0x0009 (Protection violation, > Reserved bit violation). That's to be expected.  bootstrap_map_bm() uses PAGE_HYPERVISOR which has NX set in it. > > Xen 4.22-unstable > (XEN) Xen version 4.22-unstable (julian@work) (gcc (Debian 15.2.0-12) > 15.2.0) debug=y Thu Jan 22 14:28:58 CET 2026 > (XEN) Latest ChangeSet: Tue Jan 13 16:50:12 2026 +0100 git:ce886ef641 > (XEN) build-id: 2e72a4b08fca3ae0f0ed9af0dd3a5de947a966d0 > (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 55 (0x37), Stepping 8 > (raw 00030678) > (XEN) BSP microcode revision: 0x00000836 > (XEN) Bootloader: GRUB 2.12 > (XEN) Command line: dom0_mem=1232M,max:1232M watchdog ucode=scan > dom0_max_vcpus=1-1 com1=115200,8n1 console=com1 > (XEN) Xen image load base address: 0xb5800000 > (XEN) Video information: > (XEN) VGA is graphics mode 800x600, 32 bpp > (XEN) Disc information: > (XEN) Found 0 MBR signatures > (XEN) Found 1 EDD information structures > (XEN) EFI RAM map: > (XEN) [0000000000000000, 000000000003efff] (usable) > (XEN) [000000000003f000, 000000000003ffff] (ACPI NVS) > (XEN) [0000000000040000, 000000000009ffff] (usable) > (XEN) [0000000000100000, 000000001effffff] (usable) > (XEN) [000000001f000000, 000000001f0fffff] (reserved) > (XEN) [000000001f100000, 000000001fffffff] (usable) > (XEN) [0000000020000000, 00000000200fffff] (reserved) > (XEN) [0000000020100000, 00000000b9377fff] (usable) > (XEN) [00000000b9378000, 00000000b93a7fff] (reserved) > (XEN) [00000000b93a8000, 00000000b94bdfff] (usable) > (XEN) [00000000b94be000, 00000000b98d6fff] (ACPI NVS) > (XEN) [00000000b98d7000, 00000000b9bb0fff] (reserved) > (XEN) [00000000b9bb1000, 00000000b9bb1fff] (usable) > (XEN) [00000000b9bb2000, 00000000b9bf3fff] (reserved) > (XEN) [00000000b9bf4000, 00000000b9d6dfff] (usable) > (XEN) [00000000b9d6e000, 00000000b9ff9fff] (reserved) > (XEN) [00000000b9ffa000, 00000000b9ffffff] (usable) > (XEN) [00000000e00f8000, 00000000e00f8fff] (reserved) > (XEN) [00000000fed01000, 00000000fed01fff] (reserved) > (XEN) [00000000fed08000, 00000000fed08fff] (reserved) > (XEN) [00000000ffb00000, 00000000ffffffff] (reserved) > (XEN) [0000000100000000, 000000013fffffff] (usable) > (XEN) Early fatal page fault at e008:ffff82d0403b38e0 > (cr2=0000000001100202, ec=0009) > (XEN) ----[ Xen-4.22-unstable x86_64 debug=y Not tainted ]---- > (XEN) CPU: 0 > (XEN) RIP: e008:[] memcmp+0x20/0x46 > (XEN) RFLAGS: 0000000000010002 CONTEXT: hypervisor > (XEN) rax: 0000000000000000 rbx: 0000000001100000 rcx: 0000000000000000 > (XEN) rdx: 0000000000000004 rsi: ffff82d0404a0d23 rdi: 0000000001100202 > (XEN) rbp: ffff82d040497d88 rsp: ffff82d040497d78 r8: 0000000000000016 > (XEN) r9: ffff82d04061a180 r10: ffff82d04061a188 r11: 0000000000000010 > (XEN) r12: 0000000001100000 r13: 0000000000000001 r14: ffff82d0404d2b80 > (XEN) r15: ffff82d040462750 cr0: 0000000080050033 cr4: 00000000000000a0 > (XEN) cr3: 00000000b5d0e000 cr2: 0000000001100202 > (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000 > (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 > (XEN) Xen code around (memcmp+0x20/0x46): > (XEN) 0f 1f 84 00 00 00 00 00 <0f> b6 04 0f 44 0f b6 04 0e 44 29 c0 75 > 13 48 83 > (XEN) Xen stack trace from rsp=ffff82d040497d78: > (XEN) ffff82d040483f79 0000000000696630 ffff82d040497db0 ffff82d040483fd2 > (XEN) 0000000000696630 ffff82d040200000 0000000000000001 ffff82d040497ef8 > (XEN) ffff82d04047c4ac 0000000000000000 0000000000000000 0000000000000000 > (XEN) ffff82d04062c6d8 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000140000 0000000000000000 0000000000000001 > (XEN) 0000000000000000 0000000000000000 ffff82d040497f08 ffff82d0404d2b80 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000800000000 000000010000006e 0000000000000003 > (XEN) 00000000000002f8 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000099f30ba0 0000000099feeda7 0000000000000000 ffff82d040497fff > (XEN) 00000000b9cf3920 ffff82d0402043e8 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000e01000000000 0000000000000000 0000000000000000 > (XEN) 00000000000000a0 0000000000000000 0000000000000000 0000000000000000 > (XEN) Xen call trace: > (XEN) [] R memcmp+0x20/0x46 > (XEN) [] S arch/x86/bzimage.c#bzimage_check+0x2e/0x73 > (XEN) [] F bzimage_headroom+0x14/0xa5 > (XEN) [] F __start_xen+0x908/0x2452 > (XEN) [] F __high_start+0xb8/0xc0 > (XEN) > (XEN) Pagetable walk from 0000000001100202: > (XEN) L4[0x000] = 00000000b5c9d063 ffffffffffffffff > (XEN) > (XEN) **************************************** > (XEN) Panic on CPU 0: > (XEN) FATAL TRAP: vec 14, #PF[0009] IN INTERRUPT CONTEXT > (XEN) **************************************** Huh, that means we have a bug in the pagewalk rendering.  It shouldn't give up like that. >> It's probably easiest if I prototype the split I'd like to see, and you >> integrate with that. I've had a go at this.  It's a 6 patch series and growing.  The early logic is horribly tangled, but there's a lot to delete in it. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Jan 22 14:09:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 14:09:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211075.1522617 (Exim 4.92) (envelope-from ) id 1vivNI-0000sl-SZ; Thu, 22 Jan 2026 14:09:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211075.1522617; Thu, 22 Jan 2026 14:09:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vivNI-0000se-PN; Thu, 22 Jan 2026 14:09:28 +0000 Received: by outflank-mailman (input) for mailman id 1211075; Thu, 22 Jan 2026 14:09: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 1vivNH-0000f4-7b for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 14:09:27 +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 f4da1d78-f79b-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 15:09:25 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-4801d98cf39so7916265e9.1 for ; Thu, 22 Jan 2026 06:09:25 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-480470474cbsm69600245e9.8.2026.01.22.06.09.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 06:09:23 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f4da1d78-f79b-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769090964; x=1769695764; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=dQkypLvfVUt90SuOF6MlV8sgfE9yil7rd9/f4gPGUaY=; b=CqofZ3+PsQIwolRgT4CD9+Zne58jocjKKkB6tzk6CIvhKNe4ZAnTJcQsjj403r0Zk9 oZ3cL4zYZxqdylQHWiGaTJ4oE3nUOa4QVKfOc+UKbKyWcMTAG+oLfkyB18VMVQCVSq2R zKLppD02J1lR+td+DBxf58x9ZuiPPOrH3npM9VdMwFm8/DcSRJN+7vxpCWzvkcMYqH0i 7JUvVCyccRFWSvCWF6kcyFI7gvsdRhdBTS/JS7PqcQzxoKhmsftmAMWqjMd/8juTocQG S3J5DlqYO99fUWrqpr7krogaVTZvPFHnWpJ4srS/Gj6U5LufdenpSj9IM1rqe+wVBzFS y/Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769090964; x=1769695764; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=dQkypLvfVUt90SuOF6MlV8sgfE9yil7rd9/f4gPGUaY=; b=thM2a4icjvxWc0nYN2IWS3D0OxTyb7Gt9XWGRDw6l8xQtAanty1VWne+2eVWZRBQI/ 0BMji6ZdzWT5c0MVrZareXjKpVX5FKBFMBvgyrz1qzN9f1NcIpqF66/VcJiBqk1YfEl+ VM1JqJWbrgng1KDBIhR29UhDKBPWcSVP9iDOFa9YCDtGyTkz8UkBVTHrddezKqBeChtJ cujS9qFk+mRDYOvOENWcoIciCZsRPFnpJ6ySV6ZeoePG4K9hrqClC13lTe/lxQ1mlSiV UH1oKF20B3CFoQ/nJ6boZRyDQ/AAV7BmqX6gxx7WKxhp6lu4rw0wo0QYaRyrOhF5Gqhg LvmA== X-Forwarded-Encrypted: i=1; AJvYcCUdw84JdUQl6+S68DQvb0SmbXvyLMAfUinAgOFOAJA7Pc+QJNhaF0EHbnu+OkVF1ZXVR9SKBtyPTWQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YyLBoqy3Jk1e872/g10AwxStyyJ/V8mTfIvix2Fwvz+85lQUGTa cKtrrCotlngBZB19ccL91T3lSbgD8rg42CQIPMC+15+ipI6sH0uIAsYl987iEeDfEg== X-Gm-Gg: AZuq6aKC6GBHlQmQeZ40fSPewmurgaccDAuP2Xrf8v+oUQMQA145IexJiI9A40DkYmk ZjfXYYMgCMTE96Hn8ifJy1i5PoV0FZx8w9aQj9flTFPylsyFapFt52MZ3M4jcKbPhkQxPR6CoO0 KuP4um/F5gdsATo6cTie20BxTuBkM7Sml/eU+BRc09MIgIMC5+AiFeIWDD8ns5bTcs/H/n8r+rj l3CZHG/krUCCuufC9AYyV07rwHBF8qP9uUHaSAB5mlGgQhd8O5vVjJsUVbGfb41ngM5j6vRrsgU UldrbAUYWqp4YcixSu5oorqAk/XbUDvn2+SegE3Tbuxst+60dzwPxVwDjfRZN1eCYM80hWWCex8 8PtIx/xbnr9Tg4woXBDDHG75IK8lm9sUVgVw0UwpdiqIjcGRmM6Rd6vzYe2sZKHcTn/PNv9Ltei MjpUeXDEfSaOrcq4bcOdWVN0g+nXei//XKYOiFWJ952rZt2mVwlvT0/qbJP9aXp6uH3UkyiIj6+ xvYBepg/XdkUw== X-Received: by 2002:a05:600c:3509:b0:47a:94fc:d057 with SMTP id 5b1f17b1804b1-4801eab54e2mr258889475e9.2.1769090964288; Thu, 22 Jan 2026 06:09:24 -0800 (PST) Message-ID: Date: Thu, 22 Jan 2026 15:09:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen: Move NX handling to a dedicated place To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P . Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Julian Vetter , xen-devel@lists.xenproject.org References: <20260115151658.3725784-1-julian.vetter@vates.tech> <69b511db-654d-46b3-aca3-3f37f30d3473@citrix.com> <335949fc-059e-477c-9b2b-ddcd2f144300@citrix.com> <4a38c2ae-dc60-4fed-b30e-81a02b657e92@vates.tech> <92c02d2f-ccc5-42ce-ba0c-076fdc75e1fe@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: <92c02d2f-ccc5-42ce-ba0c-076fdc75e1fe@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 22.01.2026 14:57, Andrew Cooper wrote: > On 22/01/2026 1:48 pm, Julian Vetter wrote: >> (XEN) Early fatal page fault at e008:ffff82d0403b38e0 >> (cr2=0000000001100202, ec=0009) >> (XEN) ----[ Xen-4.22-unstable x86_64 debug=y Not tainted ]---- >> (XEN) CPU: 0 >> (XEN) RIP: e008:[] memcmp+0x20/0x46 >> (XEN) RFLAGS: 0000000000010002 CONTEXT: hypervisor >> (XEN) rax: 0000000000000000 rbx: 0000000001100000 rcx: 0000000000000000 >> (XEN) rdx: 0000000000000004 rsi: ffff82d0404a0d23 rdi: 0000000001100202 >> (XEN) rbp: ffff82d040497d88 rsp: ffff82d040497d78 r8: 0000000000000016 >> (XEN) r9: ffff82d04061a180 r10: ffff82d04061a188 r11: 0000000000000010 >> (XEN) r12: 0000000001100000 r13: 0000000000000001 r14: ffff82d0404d2b80 >> (XEN) r15: ffff82d040462750 cr0: 0000000080050033 cr4: 00000000000000a0 >> (XEN) cr3: 00000000b5d0e000 cr2: 0000000001100202 >> (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000 >> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 >> (XEN) Xen code around (memcmp+0x20/0x46): >> (XEN) 0f 1f 84 00 00 00 00 00 <0f> b6 04 0f 44 0f b6 04 0e 44 29 c0 75 >> 13 48 83 >> (XEN) Xen stack trace from rsp=ffff82d040497d78: >> (XEN) ffff82d040483f79 0000000000696630 ffff82d040497db0 ffff82d040483fd2 >> (XEN) 0000000000696630 ffff82d040200000 0000000000000001 ffff82d040497ef8 >> (XEN) ffff82d04047c4ac 0000000000000000 0000000000000000 0000000000000000 >> (XEN) ffff82d04062c6d8 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000140000 0000000000000000 0000000000000001 >> (XEN) 0000000000000000 0000000000000000 ffff82d040497f08 ffff82d0404d2b80 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000800000000 000000010000006e 0000000000000003 >> (XEN) 00000000000002f8 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000099f30ba0 0000000099feeda7 0000000000000000 ffff82d040497fff >> (XEN) 00000000b9cf3920 ffff82d0402043e8 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000e01000000000 0000000000000000 0000000000000000 >> (XEN) 00000000000000a0 0000000000000000 0000000000000000 0000000000000000 >> (XEN) Xen call trace: >> (XEN) [] R memcmp+0x20/0x46 >> (XEN) [] S arch/x86/bzimage.c#bzimage_check+0x2e/0x73 >> (XEN) [] F bzimage_headroom+0x14/0xa5 >> (XEN) [] F __start_xen+0x908/0x2452 >> (XEN) [] F __high_start+0xb8/0xc0 >> (XEN) >> (XEN) Pagetable walk from 0000000001100202: >> (XEN) L4[0x000] = 00000000b5c9d063 ffffffffffffffff >> (XEN) >> (XEN) **************************************** >> (XEN) Panic on CPU 0: >> (XEN) FATAL TRAP: vec 14, #PF[0009] IN INTERRUPT CONTEXT >> (XEN) **************************************** > > Huh, that means we have a bug in the pagewalk rendering.  It shouldn't > give up like that. Is it perhaps too early for mfn_valid() to return "true" for the page table page in question? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 14:09:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 14:09:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211074.1522608 (Exim 4.92) (envelope-from ) id 1vivNH-0000fM-Ic; Thu, 22 Jan 2026 14:09:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211074.1522608; Thu, 22 Jan 2026 14: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 1vivNH-0000fF-Fq; Thu, 22 Jan 2026 14:09:27 +0000 Received: by outflank-mailman (input) for mailman id 1211074; Thu, 22 Jan 2026 14:09:26 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vivNG-0000f4-Kj for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 14:09: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 f43f948d-f79b-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 15:09:24 +0100 (CET) Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-435903c4040so693867f8f.3 for ; Thu, 22 Jan 2026 06:09:24 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-480470474cbsm69600245e9.8.2026.01.22.06.09.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 06:09:22 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f43f948d-f79b-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769090963; x=1769695763; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=dQkypLvfVUt90SuOF6MlV8sgfE9yil7rd9/f4gPGUaY=; b=XzHmuxDaon1VQ4Ijd9fN8Tut60TBL2hohPXDjs43ETf+e2UbsiFR8ugjSdAnPVPChy +jbLFcbXdXVWqN6XqNttx1p7EZJaNOIx9akVQ/bgLoapaLBjBb7zL5ibUhrKwEMpShH+ qH2jRr1eiSpf/2v9GbM2GwGFKZNGc94zs51uGmKUxRAR2EcjlQFdqnOfcXHQW5gcNfd6 zUkV6o7dJURgQNvJ+GbYgbmve3/qcnFQWX50P0np6+XnZyAFND0a1ORiXiwCAteoo9dg +v2VLk7YG/ezJ55dr1ZbZ51sLyOixK6N6bCYdtgWaYa55+jsGJMBqlLBsU1mtxIJ8JDu JIkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769090963; x=1769695763; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=dQkypLvfVUt90SuOF6MlV8sgfE9yil7rd9/f4gPGUaY=; b=ho/niADnjOkxDvHtsKV60IlZWRepP9wtqr81/BdanIrdDYTvQRao2OUK0pDCiqEqNg Eb76PWBkdX6h3rtri6vMb/9OiJfKMF2jx5fg4tHj2UskIwYnlO93TzfO7UpiuXsQzM47 hg80zi/SLlXHCB1PDJs5rtLfi/gNxnwBf0PkdoC4PHPMLqT9rvS1UadML2Y7GRrz+Js1 0a+jsyhXKTxtj32h3IpvmxOJWk1/ECJ8mIFhUi9+9nZ1eGDaHn0456ueS47gM2iFo0s9 8B6LSdeUVvOY1tL/ZFVOsvR/CgZAWwOzB3KEd8+rgmZUnMERasdBfiTmy2fUAn7He629 HoOw== X-Forwarded-Encrypted: i=1; AJvYcCUCxa/tj2A76qsSw5LvIulUxlxSh9JBW5zwRUt1mS7sK/IH/ZVs++pzNatyX7z2Db57APVCsEuP090=@lists.xenproject.org X-Gm-Message-State: AOJu0YwGCt3VHUu4kgBtn7S3xOQuNT78KHdrjp4AaoPj7UrTPX1LVgBX k5WOkeavGKB3yqW/BTPH2hGeVKd2akbYjVHHncofLXK0J2GIyhQteQ9lQaGlCNvWOBbQalRDCCe xej0= X-Gm-Gg: AZuq6aKl1DqS4EYmgmvDSvXAv8iyYWg8ofs8L2xPidfmBiJszPC2P3ZqFQxyszVxMDX XklA4haiIQItLKH4LEdew83hUfOWopeZtNRwYrZr2BlaiuURX3VsApyQxUuIlWPU+erzldVsTwp nEI3EiQ8hr7GOZzFX5x02cYRhOdA2BpWNCJpB12RIpwBWhGm5eKqRCtsskdcLrqpgZohIetpjGf Q1tgStGnyUAdrgIlIirAvkPDVpFEwp79Dz0XZZv6OH6C5lnY7eZRCMfiVWY5NvWAY+DhYAntuJT RnWEzPOfiUDHZph7nxwUlSNg5sIe2ZW/n5gPb92VkhLBGyIKZwEgCzwSGz3y14mRThnVkQ+u4B7 w1ac14SRAYhZHDKVR1LJ7aIjZL85RrKI5i9xRjFICFpCo9Hovy1cqkqVIit/98zcC4ImywxiYco nD4Tiej7CLHfZLZ3xQTRPiicoDAGnHe8w7MbBs9ncQCBidtxh+3blPsmUjWnD+XlIxHqxgs0g1x rg= X-Received: by 2002:a05:600c:4e90:b0:47e:e20e:bba3 with SMTP id 5b1f17b1804b1-4801eab54ccmr297319965e9.7.1769090963277; Thu, 22 Jan 2026 06:09:23 -0800 (PST) Message-ID: <05c85ff9-4e17-4a24-90b6-6d1195a50505@suse.com> Date: Thu, 22 Jan 2026 15:09:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen: Move NX handling to a dedicated place To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P . Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Julian Vetter , xen-devel@lists.xenproject.org References: <20260115151658.3725784-1-julian.vetter@vates.tech> <69b511db-654d-46b3-aca3-3f37f30d3473@citrix.com> <335949fc-059e-477c-9b2b-ddcd2f144300@citrix.com> <4a38c2ae-dc60-4fed-b30e-81a02b657e92@vates.tech> <92c02d2f-ccc5-42ce-ba0c-076fdc75e1fe@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: <92c02d2f-ccc5-42ce-ba0c-076fdc75e1fe@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 22.01.2026 14:57, Andrew Cooper wrote: > On 22/01/2026 1:48 pm, Julian Vetter wrote: >> (XEN) Early fatal page fault at e008:ffff82d0403b38e0 >> (cr2=0000000001100202, ec=0009) >> (XEN) ----[ Xen-4.22-unstable x86_64 debug=y Not tainted ]---- >> (XEN) CPU: 0 >> (XEN) RIP: e008:[] memcmp+0x20/0x46 >> (XEN) RFLAGS: 0000000000010002 CONTEXT: hypervisor >> (XEN) rax: 0000000000000000 rbx: 0000000001100000 rcx: 0000000000000000 >> (XEN) rdx: 0000000000000004 rsi: ffff82d0404a0d23 rdi: 0000000001100202 >> (XEN) rbp: ffff82d040497d88 rsp: ffff82d040497d78 r8: 0000000000000016 >> (XEN) r9: ffff82d04061a180 r10: ffff82d04061a188 r11: 0000000000000010 >> (XEN) r12: 0000000001100000 r13: 0000000000000001 r14: ffff82d0404d2b80 >> (XEN) r15: ffff82d040462750 cr0: 0000000080050033 cr4: 00000000000000a0 >> (XEN) cr3: 00000000b5d0e000 cr2: 0000000001100202 >> (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000 >> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 >> (XEN) Xen code around (memcmp+0x20/0x46): >> (XEN) 0f 1f 84 00 00 00 00 00 <0f> b6 04 0f 44 0f b6 04 0e 44 29 c0 75 >> 13 48 83 >> (XEN) Xen stack trace from rsp=ffff82d040497d78: >> (XEN) ffff82d040483f79 0000000000696630 ffff82d040497db0 ffff82d040483fd2 >> (XEN) 0000000000696630 ffff82d040200000 0000000000000001 ffff82d040497ef8 >> (XEN) ffff82d04047c4ac 0000000000000000 0000000000000000 0000000000000000 >> (XEN) ffff82d04062c6d8 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000140000 0000000000000000 0000000000000001 >> (XEN) 0000000000000000 0000000000000000 ffff82d040497f08 ffff82d0404d2b80 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000800000000 000000010000006e 0000000000000003 >> (XEN) 00000000000002f8 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000099f30ba0 0000000099feeda7 0000000000000000 ffff82d040497fff >> (XEN) 00000000b9cf3920 ffff82d0402043e8 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >> (XEN) 0000000000000000 0000e01000000000 0000000000000000 0000000000000000 >> (XEN) 00000000000000a0 0000000000000000 0000000000000000 0000000000000000 >> (XEN) Xen call trace: >> (XEN) [] R memcmp+0x20/0x46 >> (XEN) [] S arch/x86/bzimage.c#bzimage_check+0x2e/0x73 >> (XEN) [] F bzimage_headroom+0x14/0xa5 >> (XEN) [] F __start_xen+0x908/0x2452 >> (XEN) [] F __high_start+0xb8/0xc0 >> (XEN) >> (XEN) Pagetable walk from 0000000001100202: >> (XEN) L4[0x000] = 00000000b5c9d063 ffffffffffffffff >> (XEN) >> (XEN) **************************************** >> (XEN) Panic on CPU 0: >> (XEN) FATAL TRAP: vec 14, #PF[0009] IN INTERRUPT CONTEXT >> (XEN) **************************************** > > Huh, that means we have a bug in the pagewalk rendering.  It shouldn't > give up like that. Is it perhaps too early for mfn_valid() to return "true" for the page table page in question? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 14:12:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 14:12:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211096.1522628 (Exim 4.92) (envelope-from ) id 1vivQ6-0002hd-8X; Thu, 22 Jan 2026 14:12:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211096.1522628; Thu, 22 Jan 2026 14: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 1vivQ6-0002hW-5l; Thu, 22 Jan 2026 14:12:22 +0000 Received: by outflank-mailman (input) for mailman id 1211096; Thu, 22 Jan 2026 14:12:20 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vivQ4-0002hQ-Sl for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 14:12:20 +0000 Received: from mx-robo01.bitdefender.com (mx-robo.bitdefender.com [195.189.155.117]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5ccc64b5-f79c-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 15:12:19 +0100 (CET) Received: from mdontu-l.bitdefender.biz (unknown [10.22.91.150]) by mx-robo01.bitdefender.com (Postfix) with ESMTP id 7F11CA4; Thu, 22 Jan 2026 16:12:18 +0200 (EET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5ccc64b5-f79c-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bitdefender.com; s=mx-robo; t=1769091138; bh=Kk50ChF+yX2UTCKAMx8cwaUVuymeyydjBUGzAqwieV4=; h=From:To:Cc:Subject:Date:From; b=BidChGXg9fNijGEH5osx1WXCHtvpfuPPtROFgxxH4PhozYXKuhc64d6Mb2olqFhRh av4KlJt4oaOjAmpaFF9UrAFmT+bZWGN5bgHkf0BSLtySl1tOFvlvXPB6FvUxhoO4y8 gTAtZTKAImHc3RuYS0BYa/kiEcFrRGTGWH37eGjY= X-Is-Junk-Enabled: fGZTSsP0qEJE2AIKtlSuFiRRwg9xyHmJ From: =?UTF-8?q?Mihai=20Don=C8=9Bu?= To: xen-devel@lists.xenproject.org Cc: alexandru.isaila@gmail.com, petrepircalabu@yahoo.com, =?UTF-8?q?Mihai=20Don=C8=9Bu?= , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH] MAINTAINERS: remove Alexandru Isaila and Petre Pircalabu as vm_event reviewers Date: Thu, 22 Jan 2026 16:11:54 +0200 Message-ID: <43ab3051082a2f9a0291752ace7104738c1156fb.1769089923.git.mdontu@bitdefender.com> X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Alexandru and Petre are no longer with Bitdefender. Signed-off-by: Mihai Donțu --- MAINTAINERS | 2 -- 1 file changed, 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index bf00be928c..0ceb4bba21 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -569,8 +569,6 @@ F: tools/ VM EVENT, MEM ACCESS and MONITOR M: Tamas K Lengyel -R: Alexandru Isaila -R: Petre Pircalabu S: Supported F: tools/misc/xen-access.c F: xen/arch/*/*/mem_access.c -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 14:16:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 14:16:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211110.1522638 (Exim 4.92) (envelope-from ) id 1vivTt-0003Gb-Mp; Thu, 22 Jan 2026 14:16:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211110.1522638; Thu, 22 Jan 2026 14: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 1vivTt-0003GU-JQ; Thu, 22 Jan 2026 14:16:17 +0000 Received: by outflank-mailman (input) for mailman id 1211110; Thu, 22 Jan 2026 14: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 1vivTq-0003GO-Ox for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 14:16:16 +0000 Received: from out28-101.mail.aliyun.com (out28-101.mail.aliyun.com [115.124.28.101]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e493f5e5-f79c-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 15:16:10 +0100 (CET) Received: from localhost(mailfrom:houwenlong.hwl@antgroup.com fp:SMTPD_---.gD836R0_1769091362 cluster:ay29) by smtp.aliyun-inc.com; Thu, 22 Jan 2026 22:16:03 +0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e493f5e5-f79c-11f0-b15e-2bf370ae4941 DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=antgroup.com; s=default; t=1769091366; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=ZypD3Y1+lQi6OI5xAxzyvlb7R9txghHEaqtepZwmpfE=; b=ETPh++TXfeNnyFkI0PhEMjUylGYe+NgDAMJv2l+hMOsgK0uOoPbWUe0llf7W5rfMciDV1cXQ3qWDtNA+cZcyZF30famleGI2zdk4L9FD/C2OLI5SzXxmiE1pWfE2AlE6Z0gyAZyUZJfslYUMyIKrxQH8pHLL23SmWJu/AFjIKQA= From: Hou Wenlong To: linux-kernel@vger.kernel.org Cc: Hou Wenlong , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Boris Ostrovsky , Peter Zijlstra , "Rafael J. Wysocki" , K Prateek Nayak , Li Chen , Brian Gerst , Sohil Mehta , Tim Chen , Patryk Wlazlyn , Eric Dumazet , xen-devel@lists.xenproject.org Subject: [PATCH 1/2] x86/smp: Move the static call update for 'smp_ops' into smp_prepare_boot_cpu() Date: Thu, 22 Jan 2026 22:15:43 +0800 Message-Id: X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The commit 1f60230cdc63 ("x86/smp: Use static_call for arch_send_call_function_ipi()") changed to use a static call for arch_send_call_function_ipi(), which causes two problems: First, the KVM guest also changes 'smp_ops.send_call_func_ipi' when the PV sched yield feature is available. However, the missing static_call_update() breaks the PV sched yield feature. Additionally, xen_smp_init() is called before static_call_init() during the booting of the XENPV guest, which triggers a warning in __static_call_update(). To simplify, move the static call update for 'smp_ops' into smp_prepare_boot_cpu() to address these two problems together. Fixes: 1f60230cdc63 ("x86/smp: Use static_call for arch_send_call_function_ipi()") Signed-off-by: Hou Wenlong --- I'm not sure if the XEN part is okay or not. I think there should be no IPI before smp_prepare_boot_cpu(), and even if there is, it's okay for the KVM guest to use the native version before smp_prepare_boot_cpu(). --- arch/x86/kernel/smpboot.c | 1 + arch/x86/xen/smp_hvm.c | 1 - arch/x86/xen/smp_pv.c | 1 - 3 files changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index 5cd6950ab672..84b8a4163ddb 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -1088,6 +1088,7 @@ void __init smp_prepare_cpus_common(void) void __init smp_prepare_boot_cpu(void) { + x86_smp_ops_static_call_update(); smp_ops.smp_prepare_boot_cpu(); } diff --git a/arch/x86/xen/smp_hvm.c b/arch/x86/xen/smp_hvm.c index 5ea0f53e4ea3..485c1d8804f7 100644 --- a/arch/x86/xen/smp_hvm.c +++ b/arch/x86/xen/smp_hvm.c @@ -85,5 +85,4 @@ void __init xen_hvm_smp_init(void) smp_ops.smp_send_reschedule = xen_smp_send_reschedule; smp_ops.send_call_func_ipi = xen_smp_send_call_function_ipi; smp_ops.send_call_func_single_ipi = xen_smp_send_call_function_single_ipi; - x86_smp_ops_static_call_update(); } diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c index 72a334b32c32..c40f326f0c3a 100644 --- a/arch/x86/xen/smp_pv.c +++ b/arch/x86/xen/smp_pv.c @@ -441,7 +441,6 @@ static const struct smp_ops xen_smp_ops __initconst = { void __init xen_smp_init(void) { smp_ops = xen_smp_ops; - x86_smp_ops_static_call_update(); /* Avoid searching for BIOS MP tables */ x86_init.mpparse.find_mptable = x86_init_noop; -- 2.31.1 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 14:18:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 14:18:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211121.1522647 (Exim 4.92) (envelope-from ) id 1vivVe-0003rz-Vt; Thu, 22 Jan 2026 14:18:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211121.1522647; Thu, 22 Jan 2026 14:18: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 1vivVe-0003rs-TG; Thu, 22 Jan 2026 14:18:06 +0000 Received: by outflank-mailman (input) for mailman id 1211121; Thu, 22 Jan 2026 14: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 1vivVe-0003rk-2X for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 14:18:06 +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 2a1614f5-f79d-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 15:18:03 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-435903c4040so701735f8f.3 for ; Thu, 22 Jan 2026 06:18:03 -0800 (PST) Received: from fedora ([193.77.86.199]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43596090493sm17670486f8f.25.2026.01.22.06.18.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 06:18:02 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2a1614f5-f79d-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769091483; x=1769696283; 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=q+pquAPCPEsXczBKivIRW/RcYCaQ4i6RQW605EButWU=; b=ZtkhO0gb2nGuL5hV6Ps5HLxdEdnf/Zli1dzFPRImaXpXReJJnG4sMdDIuCXZ4N2UJC 0IQPJQ2MVsjpfVV46WtRiJxnU6T1umV5QWkhZso40RcNfBRa+FgtMS+1zbfH/Z282ekP NB8qJWDNGoAUxa5L2MVWksZB51oSfszgYxKaCH4YOpz+Jk3VxNUgaP4Of6WG6XSoisw/ 2HJ7snN16qPzCXeBBfnbsCURLN4dXHdFhcEJG5AtUtnH5wrGi0BYEBF4LrwBmwpEO9Tm sou9sPd4DkCuSRwo6quFfKDcBk3Yq6g4KqS82PAb2JCokXDVlODnylNXIY06PFueYhVk 3VQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769091483; x=1769696283; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=q+pquAPCPEsXczBKivIRW/RcYCaQ4i6RQW605EButWU=; b=c8EKVO2wpyZWbz4VJbuhFDc1sScxJGoITomrl4uEIlt4oUJfaWYVuVqsmyZ2NZ1E2E 5AQA2h6wsOVJR/kgxg6EbkxpFGhH0pf/e+hq9dFPyC+BcZRViIOnK/qOKVHtoeXZ6ndj lHFACn/EswWxGKRglkc9uXtsuEpsBIkq47fmQwewxFr+vG5dv51uDc2cDXHrqacsEmH2 BOp10xXNXpZroiRDaJMtBNWcjnIepI1fCI/J+oDTGd5KAXD8fd8To7b1EvJRtx9vx7yi LgY/T4Cv/DmMi4oil+rB5dJiRPtwtThSkivuHGnfo0dIdkcyndsMPhli9VlKCjhcn0/L h7GQ== X-Gm-Message-State: AOJu0Yw26ZVnA9t7xawJ7iHc3b8Lr8CnR5j45j9KvxlPNZGnTKgPhtQB 3y1wWLt4Fzh2bFV/glvnZ2lMwUffxyCaVdW46hoWEt9bkv7wP6BAB+0CMkMO09KR X-Gm-Gg: AZuq6aI4+dG3BChu0nTe6gFYV+IRkyvY8kpNlOzgFy+pUAQduVSyVsb2OppIq/DP8dm XuqRu5aaT2SMYo4+4WPZodkeLh2fm0qYbIjIXpVwWMfT9ybNOjAttTYeqeEvHI72DTkWyMzoJii tOAPLHrYpE8tol1OVBZB8pOMC0LONSk00aFU3bpAOfGdpOX2uwM9Hux9ixcoVtnJV2LaCjYhiBv GO02Z0wRZ/X7JGXuS1udHTEwQGWWW0ZxGHFW0Oz/IKGRwM2xbr0p2BwJ/FxBxFf5CGX22GnXn/v YwaTdFy7MPzSjDYPMIM8EcHTcORLsrSN0DKpmbNNddbHEUmsKpunEqVo7c0JUFaxVVk/zAhdFTn OT+Ztx7wjOVu1lDGNRAC/EfjAaw6bjGIA4tyVMUgPFbbnpBdfsK1aDtMW50vcUH9IDiJaIOjbnv glk2AmnWlcK/HAJFp1JGE9trso7DIILubO86zLZ8epPceduL4ZQiCZ2g== X-Received: by 2002:a05:6000:240c:b0:430:fd60:93fb with SMTP id ffacd0b85a97d-4356a053cbamr34015845f8f.32.1769091482500; Thu, 22 Jan 2026 06:18:02 -0800 (PST) From: Uros Bizjak To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Cc: Uros Bizjak , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Subject: [PATCH] xen/mcelog: simplify MCE_GETCLEAR_FLAGS using xchg() Date: Thu, 22 Jan 2026 15:17:07 +0100 Message-ID: <20260122141754.116129-1-ubizjak@gmail.com> X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The MCE_GETCLEAR_FLAGS ioctl retrieves xen_mcelog.flags while atomically clearing it. This was previously implemented using a cmpxchg() loop. Replace the cmpxchg() loop with a single xchg(), which provides the same atomic get-and-clear semantics, avoids retry spinning under contention, and simplifies the code. The code on x86_64 improves from: 186: 8b 15 00 00 00 00 mov 0x0(%rip),%edx 18c: 89 d0 mov %edx,%eax 18e: f0 0f b1 0d 00 00 00 lock cmpxchg %ecx,0x0(%rip) 195: 00 196: 39 c2 cmp %eax,%edx 198: 75 ec jne 186 <...> to just: 186: 87 05 00 00 00 00 xchg %eax,0x0(%rip) No functional change intended. Signed-off-by: Uros Bizjak Cc: Juergen Gross Cc: Stefano Stabellini Cc: Oleksandr Tyshchenko --- drivers/xen/mcelog.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c index 4f65b641c054..abe658c73b7b 100644 --- a/drivers/xen/mcelog.c +++ b/drivers/xen/mcelog.c @@ -165,9 +165,7 @@ static long xen_mce_chrdev_ioctl(struct file *f, unsigned int cmd, case MCE_GETCLEAR_FLAGS: { unsigned flags; - do { - flags = xen_mcelog.flags; - } while (cmpxchg(&xen_mcelog.flags, flags, 0) != flags); + flags = xchg(&xen_mcelog.flags, 0); return put_user(flags, p); } -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 14:18:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 14:18:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211130.1522658 (Exim 4.92) (envelope-from ) id 1vivWA-0004S8-8L; Thu, 22 Jan 2026 14:18:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211130.1522658; Thu, 22 Jan 2026 14:18:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vivWA-0004S1-4a; Thu, 22 Jan 2026 14:18:38 +0000 Received: by outflank-mailman (input) for mailman id 1211130; Thu, 22 Jan 2026 14:18:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vivW9-00049z-Gw for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 14:18:37 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3d814ce1-f79d-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 15:18:36 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 6A3034EE3C11; Thu, 22 Jan 2026 15:18:35 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3d814ce1-f79d-11f0-b15e-2bf370ae4941 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=1769091515; b=U6c53olXA5TCoCcp5wu3MuNKA69TufPb4JyVyYSBJynx0unGkzIL4OePIRVc92ldLHb+ yEwkGs7+u9J6YygRtasAEBkjx3rJoW55bXnY4Bx88YYMAYvc4+T2dH7afIV9MERb6LTgg gFEgTmfm/K+8KuFCSyNrb5vvygt2PSnu0FBfRlavBcH1s4onYFtvOJnOait4nGhlZGxGg TzXMXvZFSO2gTYK1iUWOAZYy9t15/gmUjWDhwKbhWbJ93WBLvm1gHK5dBHJ5prUcAHn9j qIYgYOYnOnyiHXe1FcvAp6IYmBkolyh+ugWq93R56kMN3horRAFe4ZcvP/euU6sKPMQGz VJBHPSrK42p3LNiixi1takbDUhOYMgcUIAi2/U8Y+99pG41gdAYQVA+4mQCrxJFFB4680 2PEdHTZygMZGDKTK4YOj6XWlQr6CX9/3iE3W7/YgsiNhPmOc/uyRhnh3INSY55idJhGvX p7lk4kYmzXMuVHRxGfmPR2/mQ8fgoOTaGUmThuNkQBp1lbJzpc6GxYuAaA6LKiBfPuI5F qbkk5HMsc9rWBUcy/00pEqvtkIX5FZ4nVCr6Zy/jRQOT1YGEgbSUdkXpY+LxvUN6epT06 ICdqA7cTBgsaBLSXrLOcrVsFWqZo7MmW+Y0COtIdeeumKsKzxPHlp/wk58EKiio= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1769091515; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=rZgi7txDtcK8WRlhPaJZ0sQJZAUgCPUk3UvQylM6vao=; b=SMYusmknzl05yyYV7I5elQxIv3SNtdZIbbwLjY6M1hV3GGkk5puwcoWVQUgOT7l4tEiT UBqmuRGI9GRIznHHguyu6suhQsWrhAwNMlAnt+crqLWM+5vQdXtETqaI0N3ZCI29+1Apy ZCtImZjcr/bTXXtQ0yQKbQTZvaQYJaAnHJdxMbgvSrXb72Mf7eI3dEOTyQC+fCSsfLcXe aTSZECrMgocFfy8mLtGEsA2FjZjCdzlMRtYItdxJdb0s5tdCY9GScPa1bhwcmK/IIcKTW /7qYayMToYNn5TXqX/twgaIKpS5khsHOW9cW+LMuNYX1+rZnyCPg93f0xrXnhnJY9ZPWB ENKaGp45LVmzMlvT5P8m1ZKntWG/zC13pN/ZV3Fx8QFwUh3+090fkTXCq34P7+hP5Bw9G FWwU2loql8YIfhB5kuRi8DMIAeFoIfabqtR1MGCZlCnr/WWox2jbGftKosQjQLNF9RqCt UOJkaSm+hcUTgKYprRwHahqEDebY9RbN889sezIxkiT1K3Jqn2Kcx3aANIEC45951KMi/ vv2JX4dAI6uHqCF/IFPMe6C1UQikOClukzuCb+iuaki2BlWHPCMLx3CqW4fs5ff7OpR0W yOvXV+YHty4BdM798SbhkKZw2zVczSSk2L7PrE+CCNKkXA1LG+Q0mspErRar6/4= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Thu, 22 Jan 2026 15:18:35 +0100 From: Nicola Vetrini To: Andrew Cooper Cc: Jan Beulich , Alejandro Vallejo , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH v5 2/2] earlycpio: lib-ify earlycpio.c In-Reply-To: <947a4230-4a1e-4178-b7f0-ae5618f4303d@citrix.com> References: <20260121154757.44350-1-alejandro.garciavallejo@amd.com> <20260121154757.44350-3-alejandro.garciavallejo@amd.com> <5948da25-0b4d-48a5-983f-0fc9424774b3@suse.com> <947a4230-4a1e-4178-b7f0-ae5618f4303d@citrix.com> Message-ID: <02004b6ee5ddb57f4b834163a955d29b@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2026-01-22 13:50, Andrew Cooper wrote: > On 22/01/2026 8:27 am, Jan Beulich wrote: >> On 21.01.2026 16:47, Alejandro Vallejo wrote: >>> --- a/docs/misra/exclude-list.json >>> +++ b/docs/misra/exclude-list.json >>> @@ -121,10 +121,6 @@ >>> "rel_path": "common/bunzip2.c", >>> "comment": "Imported from Linux, ignore for now" >>> }, >>> - { >>> - "rel_path": "common/earlycpio.c", >>> - "comment": "Imported from Linux, ignore for now" >>> - }, >>> { >>> "rel_path": "common/gzip/*", >>> "comment": "Imported from Linux, ignore for now" >> Judging from Andrew's >> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2277362625 >> this doesn't quite work. As I had expected, since the file is compiled >> unconditionally now in its new location, some violations are now also >> unconditionally reported. (Some, checked for at linking time only, may >> not >> be reported anymore for the *-amd analysis jobs.) > > Yeah, in hindsight this seems obvious, given that we're compiling then > discarding. > > There are two options: > > 1. Use an earlier form which adds the new location to the exclude list  > (Still needs to be in this patch for bisectibility.) > 2. Fix up the violations first (only 6 in total) > > Two of the violations look easy to fix, two need the deviation for > octal > numbers, but two essentially-char violations look to be hard.  The > logic > is doing ASCII manipulation in what I would consider to be the > appropriate/canonical way, but Eclair does not like the mixture of ints > and character literals. > > I dislike option 1, but as (contrary to my expectations) this is > interfering with the *-amd build, I'll tolerate it. > I agree that Solution 1 is the easiest to implement. An alternative could be to fix the regressions for R7.1 and R20.7 (they're trivial) regardless and add casts to sidestep MISRA for R10.2. -- 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 Jan 22 14:19:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 14:19:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211142.1522668 (Exim 4.92) (envelope-from ) id 1vivWp-00052t-JR; Thu, 22 Jan 2026 14:19:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211142.1522668; Thu, 22 Jan 2026 14:19:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vivWp-00052m-FC; Thu, 22 Jan 2026 14:19:19 +0000 Received: by outflank-mailman (input) for mailman id 1211142; Thu, 22 Jan 2026 14:19: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 1vivWn-0004qM-Rq for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 14:19:17 +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 55373f6f-f79d-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 15:19:16 +0100 (CET) Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-43284ed32a0so674895f8f.3 for ; Thu, 22 Jan 2026 06:19:16 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4356996dadbsm44443000f8f.21.2026.01.22.06.19.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 06:19:15 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 55373f6f-f79d-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769091555; x=1769696355; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=3V4F2HUnuMCGUe57Is6YggIZWzIe5UpHKoR6Mo845WI=; b=ZmPFw+nUucpuLXEBcr6P1GVQjL3PzAqM4efFUNu49gMvZqhDvnNbohxdJQ5fhcV1Cp CvWa9XP384Fxr7ZpPQIooTpaZSZ+n3lPHvm8pW+t+P6K2ADdYum3AwWSzRiChEhYsCpK BV7AQ8eARtK81jzPVkgm1xab9vrB4Hfc1FXl+BVrcFz+7ZY2NGzE2xORg6/A3gE4XbXU OaWsQmJMABlbl9Ym69RVKXDcQiElVcUQd/zLhSsrU52U+t4VB1prthD4CUvLIqxC5o4j izeVzX6uvFRDuKIclmyS5SAlJUjOR4pT9Jx/NWy13qWKSvK1uhFjpBXkkM3me64b9tFg 5snQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769091555; x=1769696355; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3V4F2HUnuMCGUe57Is6YggIZWzIe5UpHKoR6Mo845WI=; b=TDl4bUz4hnt59k1az3f3vvltKObfJYlx9XIlPR/H3l5Y9Qyn+BstHhdkYQL1y0DsmK mP1dV5U+aGXnYehqBnfWuGJ2Aiaa73v1IP2k60XNrMYIZH5TkR0ji6r4T+Uhq6gTOWR8 Skx6S9LhiNMaht6CtHAzhJArtMyadlevm79lODuT9/6vA8r/rbebayf7UcWedcytAPLN XnP6cGRzyLMja48tforEq5O7c+ynojM+SHFJr8q+nCqo6NaT7Gl/cQVx7q/krgvXOfQb jmHr9CEWDWKuaLtPibQ/CTpJRDHUOv21ow9hlUrTEQ/ubiRgwbn18vDZIVq+8rQLKCv7 WIzw== X-Forwarded-Encrypted: i=1; AJvYcCXyIXnyp1+LHMY0HB1tJYlVqNfftW8Ji9OiZQRDot31d7YTLlW3OwpdXMitp2Jk3qFZFSnyFgYMKlE=@lists.xenproject.org X-Gm-Message-State: AOJu0YxP0wawHdzzQKcFHGfjksVWhfaOlQpzoyT9nL3HIB9AQr7/bwd8 VitpRorHvQ8oq3d9Qf6xoCOXsnc1qc80GyLUJ4Kat3IBIJpUhaVME1c3oY3B2MuNzA== X-Gm-Gg: AZuq6aIj43B5Y+uxVFiOaqDfC66Y9IbK1TlegAZrBZPzalC85c0XSbaL5Ph2fEpphYT +tKRPAiRUbr08AmqjWfYFwWx+UsBs+tJ5HFc49Rjk2b7QweqynbytomBOVZxNCKlJ4mMKRjjAnz 6YQaNQ2nVsf4NfXj7bQLd7/WeJo/LjkKqqtLYxpKN9xPIAqktxMt8PuAK5aANTZz9VvaOg6q46W 5Lbt3b2aAYQuc3jkwtH9scReJZULtGuxR3069T5FPWepvf8eKoT5PldPHig6gJLcX6nyZlLZvzn 0w21qCGPJRYxirvk08lhpcjgC4lqDGSGi6moCEjyYrfR4p7s0ZkhDw/xtuygVpppO51pu3ZfcHK BkGMQMTaHF7/I4cs4OEXy1kcEXEpRAtKG0J6pdMZEtaE0at80H9e9bq3vKrNJISRBgGqASNVe0S 9uqBQXh5KYHBPb8QbCztsNnklIhljkVifsMfwajo/TA5yPOUvgl7ZORKSgXINNoFgAHxftZVnVY FQ= X-Received: by 2002:a05:6000:4287:b0:432:84ef:756c with SMTP id ffacd0b85a97d-43569bc7422mr30253138f8f.50.1769091555547; Thu, 22 Jan 2026 06:19:15 -0800 (PST) Message-ID: Date: Thu, 22 Jan 2026 15:19:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] MAINTAINERS: remove Alexandru Isaila and Petre Pircalabu as vm_event reviewers To: =?UTF-8?Q?Mihai_Don=C8=9Bu?= Cc: alexandru.isaila@gmail.com, petrepircalabu@yahoo.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: <43ab3051082a2f9a0291752ace7104738c1156fb.1769089923.git.mdontu@bitdefender.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <43ab3051082a2f9a0291752ace7104738c1156fb.1769089923.git.mdontu@bitdefender.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 22.01.2026 15:11, Mihai Donțu wrote: > Alexandru and Petre are no longer with Bitdefender. > > Signed-off-by: Mihai Donțu Acked-by: Jan Beulich I did observe their email addresses bouncing, and just earlier today I had fired off an email to Razvan, trying to figure out their status. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 14:22:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 14:22:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211155.1522678 (Exim 4.92) (envelope-from ) id 1vivZQ-0006Zl-UR; Thu, 22 Jan 2026 14:22:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211155.1522678; Thu, 22 Jan 2026 14: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 1vivZQ-0006Ze-Rn; Thu, 22 Jan 2026 14:22:00 +0000 Received: by outflank-mailman (input) for mailman id 1211155; Thu, 22 Jan 2026 14: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 1vivZP-0006ZC-30 for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 14:21:59 +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 b50f3f7b-f79d-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 15:21:56 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-47eddddcdcfso6118685e9.1 for ; Thu, 22 Jan 2026 06:21:56 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804704b712sm68649175e9.8.2026.01.22.06.21.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 06:21:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b50f3f7b-f79d-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769091716; x=1769696516; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=KWBtxKj07s4HLwGJTh9AK3keI4THEAKode/ZcAbQeyE=; b=QprBXNybt+jmnR21NTXQH2PYEQBk5EoeU+CGc5pJ544DoF5ek9ISjEjw2y4MhUpfxr DlcgQZUg0YLhNntYEjWSw1NmMc4+vcBAger0362/tte5w2jmW7/VxTGwNsB6ZsseJ1i2 0ILMAcNjipHHQqb4OoU9wM2EYFc7n0fi+Pe5Yqgy4nxYO4/brIzHbV5r8f+QvEJyRdCu 2pur9uYyZi8ZU7qL+EJrHJNl3xaZEBufdnk3j7JfhMUYsJdUmcSgQTQInvmGlDk7/rVK mbJi3tgQhZxZTk5PAlH3EEK8uOy2jHhjnnEoZtB1kq8TV3ZnUUyMKlZiqbk7wLsCVQ7A YYlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769091716; x=1769696516; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=KWBtxKj07s4HLwGJTh9AK3keI4THEAKode/ZcAbQeyE=; b=q/O1HJMlOTUJzOCOQ0AI+JS3/PLHcdYzNX5TIdMBxz5U1IHsPtVKL9DR31J4Fr/ekK SyF8ReCyG1ObDJzpIBDR0OqxesqtpmaBKODtXv7AML+0VIRQ9GR9CQ5GfKQET67e2TDk UtlK+rA7Nds3+ozNf0zd6MPzJ5OG7mLOLVauP0/GXNmGrmSh1aEqUhAMRPALU9YBaxOI +XbyxW1OLKwB7cxJUD8ugAnOj5ICTsF3ZvqDR2NLLBVF+MgHgw7N0LZSab0f237oOIl5 keAw+0WmD8KAKt4sX92EuWVbGwinJibezQW9986isSQeHphWYf4SSvillgpR5MyDJg9+ VKOQ== X-Forwarded-Encrypted: i=1; AJvYcCUtP4u//IsY8j2RluJmsm37HK1bDumufdYTJkefKlncxanfwGLawF+3fTllbWUyeE0wApLIuvgX3iA=@lists.xenproject.org X-Gm-Message-State: AOJu0YxDZErms5Il2Bm2EdcVvCuBJ02YC8ZKjE+AMM+O0k+DV8T++V7p 2eAusGk3JJU95lBymwJXQqRst4jfSj4Tqmk6THNgNuO+ybUgjFfSGh6nIYhvod4/VA== X-Gm-Gg: AZuq6aKv8/yvMVhTwX/QNwPWFXEoYMXHw3lzH5fcORqaDamIkjQN810AjFgcrCprDpf ikFw880Rms6bb4E9nBzthnE5JgZQNTsAaB+bhubrim72Se6+f8hcX+Dy5z5VhFxGKbEKWF8rwx/ P1NFFeyq0H2tdXOWxZ9vbIL2cfXGBQKuMWv7ogMrijKEohLewbS67vPXlXOcl91l0aIOStpTBvC yP1U5AHlBQQ49Yh+it3j44c5TrdBy1uxAd5KeFqsHg7O5LeSEta3SBUHhEcwR5o9OHQkjYzfU24 U6aKtery74eFj8PCeq4LfTUkn5fgV312MEy+s0S39uHBI/z0T0K/X2S72kBZ+rXo4qjoElCigRA dylwIILCa7ixw7BrhvptuUAYF6uHx6pSOL43q0nR35sx5FrgxxpwUzEzwARQ4krQkaRABMziPJ8 Vb2XyGEUgCuU9LaHTNrA+5ltI/QYI9taYWLbscJXLaQWt3annP9Ta1ir4GkNDG0FS0ThbsXLItc /PPSKugKGKRqg== X-Received: by 2002:a05:600c:1552:b0:47e:e946:3a72 with SMTP id 5b1f17b1804b1-4801eb0e021mr302727105e9.27.1769091716256; Thu, 22 Jan 2026 06:21:56 -0800 (PST) Message-ID: <60e77689-7fed-432d-ab8d-621690e6a323@suse.com> Date: Thu, 22 Jan 2026 15:21:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/mcelog: simplify MCE_GETCLEAR_FLAGS using xchg() To: Uros Bizjak Cc: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org References: <20260122141754.116129-1-ubizjak@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: <20260122141754.116129-1-ubizjak@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 22.01.2026 15:17, Uros Bizjak wrote: > The MCE_GETCLEAR_FLAGS ioctl retrieves xen_mcelog.flags while > atomically clearing it. This was previously implemented using a > cmpxchg() loop. > > Replace the cmpxchg() loop with a single xchg(), which provides the > same atomic get-and-clear semantics, avoids retry spinning under > contention, and simplifies the code. > > The code on x86_64 improves from: > > 186: 8b 15 00 00 00 00 mov 0x0(%rip),%edx > 18c: 89 d0 mov %edx,%eax > 18e: f0 0f b1 0d 00 00 00 lock cmpxchg %ecx,0x0(%rip) > 195: 00 > 196: 39 c2 cmp %eax,%edx > 198: 75 ec jne 186 <...> > > to just: > > 186: 87 05 00 00 00 00 xchg %eax,0x0(%rip) > > No functional change intended. > > Signed-off-by: Uros Bizjak Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Jan 22 14:22:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 14:22:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211156.1522683 (Exim 4.92) (envelope-from ) id 1vivZR-0006cv-6s; Thu, 22 Jan 2026 14:22:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211156.1522683; Thu, 22 Jan 2026 14:22:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vivZR-0006cC-27; Thu, 22 Jan 2026 14:22:01 +0000 Received: by outflank-mailman (input) for mailman id 1211156; Thu, 22 Jan 2026 14:21: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 1vivZP-0006ZI-Pf for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 14:21:59 +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 b5e3d227-f79d-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 15:21:58 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-4801d24d91bso10981425e9.2 for ; Thu, 22 Jan 2026 06:21:58 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804704b712sm68649175e9.8.2026.01.22.06.21.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 06:21:56 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b5e3d227-f79d-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769091718; x=1769696518; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=KWBtxKj07s4HLwGJTh9AK3keI4THEAKode/ZcAbQeyE=; b=Qrqni8+dwRr+VhF2fN/ihloAr9hAL54AOIIB5WgxwGLtYbfMgny60JhMq0VYTgPqgN mldeyAB4ecNX8uCaHzy5Qr+Y1gnyCVs5oz6mcR6p4c9GDAL5NkmjsyFmi/qv4ptzzbYQ ki1JXSZESdjYnn597WQG5fWkcwbY+3VJGB9jCOYTF8GidHxuot0eUjvxYixgGn9jpvGh 2x+xPb6KP5zsm24Eac0kk6uuVdaIwLJjG/h6MUnkaStyu94mbN0Huwgx5WTgD+xalOEm c/26Vm5g6FnHnK6+lhtlvgxxoK+3QGMubAzwMwsRbUzy6z8PyDTpJcYduiYOUQjX9pzI KYCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769091718; x=1769696518; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=KWBtxKj07s4HLwGJTh9AK3keI4THEAKode/ZcAbQeyE=; b=wWvbBPFFrazDGK5ZMkNuFZtexqMP8PjezqA3iYvvXkSIa9NEshWWJQkYFXHNH+aDN0 1qT8UMetJzaQeE/7lTTaHY/0Hj7uCGi61iQh9m8Gw0z7+A0UIg+4nt7hdmFsROvWyNRl KxjGSUmn3W6FtPYO+LH+SO2Gb12RWmSZV5xOX7IYriCKFU45xGONZSKwfM8GwBDSrAzr 60Ok+uImtuBCzyarf9hjiP5s7LuicHLqCX9WEmkjB9M6lkwDGsGDO6gBP6HgQ6lp12e8 s/ujgvDu42/SnRSOl38OGsUL2Y+fBr14UJqet5jR5R5t5dxPdYNxnMGb9rh0c+YDew0T d0cQ== X-Forwarded-Encrypted: i=1; AJvYcCUmTeRAFh/9r3Rg+mkWndhNaj9sGuy11gjBQsmGPocWEEapd8X5Z7OVD3FlWH7Dn2gaI0OiFnTqDjY=@lists.xenproject.org X-Gm-Message-State: AOJu0YyDmZwd9LuAaHUKfyYW0a+CqaGhP2GHNVJEcqVH+aRBcxGOWx9V KAa0ZfGKuVXhl1o2KlqEHpyweZn4RAllYixaFTlVyYDGk5msLR3kyCUcj0wl8VMiKjRc+WL2VZr Wlf4= X-Gm-Gg: AZuq6aKTAryTDHqGTsvhl5z8cYqlX819t983NUpZjQAir1WJUj7PLyBmni2YBX+YODD hwrrcrzfjJr0B9SCmQ7IYNNJvxgh6M8nRnkjppHdewx7RUXpopHGQMMpwGuhPs9M4XfHXmz7h80 964on38cjQ9bQH5uyHN0ExpPTIngmVpQHYoIYodzY2IViyR3IU9jNawUmB6T+ksyXmVH89l98/W wWeQAbGLZabh34RDR0KRgeiYazHkuXdkvVCcDCAqYbdOHyT2I5jiqlPG0I6Lyuwk967eHMrq7gG fNvr3LXx9/m4Ye6WqhRddPzzSK2Svjda5mfwIjIvRH7xHtIjyEPkDhQ+Q7GoaZ+OBmaa/rB2fNd dxqJUY3WBOXqOm7gfCdai0YcVj4ISte8qdnMt/RhogpBXslXUoNPy08EnkrkX0pXTCuTZWfVCoF xYOZgsYOdbIpsu2swaXYxpjRAvg0s2zIiYW4BYMbs/EguvHgjcS42rhFlUfRZ+0iTzS+qtJI6h0 rc= X-Received: by 2002:a05:600c:1990:b0:480:3b26:82c3 with SMTP id 5b1f17b1804b1-4803e7e819dmr135375095e9.20.1769091717597; Thu, 22 Jan 2026 06:21:57 -0800 (PST) Message-ID: <17b237ae-d3c8-4491-8eb5-6ebb4a25a8fc@suse.com> Date: Thu, 22 Jan 2026 15:21:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/mcelog: simplify MCE_GETCLEAR_FLAGS using xchg() To: Uros Bizjak Cc: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org References: <20260122141754.116129-1-ubizjak@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: <20260122141754.116129-1-ubizjak@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 22.01.2026 15:17, Uros Bizjak wrote: > The MCE_GETCLEAR_FLAGS ioctl retrieves xen_mcelog.flags while > atomically clearing it. This was previously implemented using a > cmpxchg() loop. > > Replace the cmpxchg() loop with a single xchg(), which provides the > same atomic get-and-clear semantics, avoids retry spinning under > contention, and simplifies the code. > > The code on x86_64 improves from: > > 186: 8b 15 00 00 00 00 mov 0x0(%rip),%edx > 18c: 89 d0 mov %edx,%eax > 18e: f0 0f b1 0d 00 00 00 lock cmpxchg %ecx,0x0(%rip) > 195: 00 > 196: 39 c2 cmp %eax,%edx > 198: 75 ec jne 186 <...> > > to just: > > 186: 87 05 00 00 00 00 xchg %eax,0x0(%rip) > > No functional change intended. > > Signed-off-by: Uros Bizjak Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Jan 22 14:22:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 14:22:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211159.1522697 (Exim 4.92) (envelope-from ) id 1vivZc-00078A-CQ; Thu, 22 Jan 2026 14:22:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211159.1522697; Thu, 22 Jan 2026 14:22:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vivZc-000782-9P; Thu, 22 Jan 2026 14:22:12 +0000 Received: by outflank-mailman (input) for mailman id 1211159; Thu, 22 Jan 2026 14: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 1vivZa-0006ZC-Io for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 14:22:10 +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 bb87f6d3-f79d-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 15:22:08 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MN2PR03MB5149.namprd03.prod.outlook.com (2603:10b6:208:1a4::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Thu, 22 Jan 2026 14:22:05 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Thu, 22 Jan 2026 14:22: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: bb87f6d3-f79d-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Zc5rMJabjY6vDDDhRuVedUqNlrK9lzR2Fux+Qs+p7Fuf67k1GwxaJiVHSQeMFyGxw+ss6yO3M0IwbM6VXQFod5Ph9bOseFjm0XM+AMH0cuRquPumWz2OF8+D+kUbM0oNcs0flsSuggOW3cxA8Uk+DEDJFTtVs7/DIoNfNC2IrmOOkFrqC9ZVYCfWYonSStllq+bvDQFLp8JTe7m8VCoex8bswj83FL4O6K0weCD2j1EH0werkG3Yw9Ev07HSRMw5x41/EfdgaUapiW6I1c/4JonqIsNQ7nsZqk8lQVjE16JGAcl2hJLXi+kAQMIhh/XR00P48PNsr2kNPTvSV6lXxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=a2pp6K0iL+LUPLiBUkm9GiBqMMcAbkMFilWT6ZXr7S8=; b=mIjx2OvXTJ3A2n2JM6G9f+1U9XSrYitHIVe5P9H4qvgCi0jzUWccIbXqftqwt6gUs3nsF0OjHSyQ+6D2rf16a9QJFPGh4OgNFUDjX9TtPlUjshZicsb0uAna5aFM3Nb3PsUfJJoLltiKL1QuarNZ8vRxGN+ujIM3d1VRNEBPaPBouqjzU5iQ6sE4ovu9Sj2JzsMWzPmjbQdey5H1ng6z1TytlZqH0J7ZBkXHjXxhzjlbJaETYbwV0HyRaOIezPOt7KCtZsI/swOgNduCtkDolj+sKcD9CpsmafB1W31PgRFF6+GX3Im+UAN/Bo8UUU+HgrjTAUSu+HE3tqKATYrX7Q== 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=a2pp6K0iL+LUPLiBUkm9GiBqMMcAbkMFilWT6ZXr7S8=; b=cJkeQvl6Qp+g6RfZNzoP7BYYvQ5Ai3OYWbi65soXV5CXwkJuL5g1KDoouMhth3uP3IBUtVeX6oJG8+uY3hINpt1WszFyKZvMeaQqmAnHHCoRkmJaHa1BiHyuAfYfgO/LfLWX3ksm+yZRZf10gxFCc+OGmZfD9eiDb/dt9jvq7x4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Thu, 22 Jan 2026 14:22:01 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Subject: Re: [PATCH] xen/mcelog: simplify MCE_GETCLEAR_FLAGS using xchg() To: Uros Bizjak , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org References: <20260122141754.116129-1-ubizjak@gmail.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260122141754.116129-1-ubizjak@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0186.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a::30) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MN2PR03MB5149:EE_ X-MS-Office365-Filtering-Correlation-Id: 86a1a5c3-3750-4f7e-9f06-08de59c19e6c 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?bS9BUGRSVjBQSVBnRXloVXlvbjkycVQ4cFFZTWVsenZOSGUzNTJvNHhsMDdr?= =?utf-8?B?OHBEKyt5N3RjTXdCUG5BME9wUUdIaDFzUVdUbnlGWFNHc0hiM2tibmdubVMy?= =?utf-8?B?WUR6ZFZZbGNjcllWQzVMVjVhUTZ2YmR2RkpxMlhkem1VYU9WNVJWbm1rMXNI?= =?utf-8?B?L1RDU1MvSmFpcElBT2tWSllFZW9zQ0JURlpvMDlJMm5RN2o3akRPZUhOeTdm?= =?utf-8?B?NERwbXB6aXRGS2RZZG1tNkllRkc5VWNVKzI3L0tqSi9SVE9pV3g0c0htYWlB?= =?utf-8?B?ekliZE8xemRsUjY4M0Y1ZVJEcXV6bjJCL2g0YUViS1pBSTlBZWxtSE1Yallo?= =?utf-8?B?WnFmN2VyTi9ZcFl2TkJnWFdZKzBjdHVaS1NUY0JMUlBtZkRGS3NwNTUvbXRn?= =?utf-8?B?bGE2bXZSTU9wNnZNOGdTL0JtQVJMc2FSNEdrVlNVVHIyclZvQWplOVlQRHhZ?= =?utf-8?B?RDBiMkhxOTJINGZ2Rk80Nmgwb29IMERtTTRNOXdUNHI2aE9POWh2b0ZtV2kv?= =?utf-8?B?cEpVUjNWTVpTcXEvMFBySEdaTXI0OEttWDRmTG1FZDJUUWpXdFk2ZEtiSzl1?= =?utf-8?B?am4vdG02ZlVVZ1FlVG9WVDVoQ0hXd0dMeDZDODBCUEoxWlg5WGFLYkx3NzhL?= =?utf-8?B?a1NjNDBNdVZOVnhDbVJ2Um83TjFLR2xKcVlkZG05NnhkQ2FpMW5WdGEwZ1g5?= =?utf-8?B?T3FZRkVvektmbldjUHYrbXVBbzNua0gvaSswNlVMblppcnJSQUZBeW5RS2R5?= =?utf-8?B?a0pYaEdPZVpGQllkbEtQL1hEZTRMQUo0YTFlTm5EU0trYVVNYzFsWTJBN002?= =?utf-8?B?KzUzTU03dTRhZ1J1OU82SFUvR25GT3hEZ0xCaFphQ2xXRkFQSGlUbFgvWkM2?= =?utf-8?B?MHZ6a0hoemU4TW5vU1RqNkpIcFVOc1NJNjNVZXN1YlpBMGZ3V01qczBoNGxX?= =?utf-8?B?NTkxTWxINjg0VWpvcDRUQnphdXRNcm92a3kyWmZPRU9JcXJWaENocWFqU2Qr?= =?utf-8?B?dEw0VEpxMWhGR25OckpKWVZWWjBxWDRiV25xdXpZSjhkUUN4czh5MHRpTi9x?= =?utf-8?B?bkc2R1U2Q3N4bkk1Ri9JMXVIc3lWdW45UmE0SFgvVnNsc1Y5RzIzRDFqYXZ6?= =?utf-8?B?b3hDWnRCUWhXZTBEOW0yV00vUkJxSUJSNTRYS3lTQjAwTDh6NWttMEcvZEEw?= =?utf-8?B?bVNqVFFNTHFzZ0h6QmN3WXYxbFBkRHQ4L2x0Rkc2cExqREFaNUJVb2pMSk42?= =?utf-8?B?ZDh6c3dKSExnbmZ6TnMyU1JRUTZvTzZIdUFlNDNoeHdLREtvMTZaVDRIU2hO?= =?utf-8?B?VHBZS1pXQnFpOGFGRVk4OEx0ZlBRSS9PdGFoaTUrOFFnRXhSR0JXRUlzYzgy?= =?utf-8?B?VERjWWdrTUR3R25jdDFqZlUvM0toalpXUVVVQmtkUTJncGtOdG9HOVNBbVkv?= =?utf-8?B?dFN5dmZsM08rVUtud2xKc1VJYkxRVHN0bHlqWkc2czJlZHlYem12aGFaTHBp?= =?utf-8?B?WDBjNUs2RFAwbGs5WXNaN1hYWVdIZFFpL0oxNXVOVG9yc1lrOW1NTDBXSXkz?= =?utf-8?B?TUFxaDNZQm1YcVczV3IvRDFIUEZCamRWYmZhRjJPM1lZbFhvKzJSUE5lMTBa?= =?utf-8?B?ak5uOVRBQkdTTmZvb3JpZDgwNWUzc1VRTVF4b20xZC9jM2lHbUpIaUhjL1Yx?= =?utf-8?B?Y09Nak96ZzJZUHRVb3U5WEppR3o4QTVmNnN6Ymd6cllTd21haDlZc0dJNjV6?= =?utf-8?B?eWpGeCswMHdsUGxWU1hxUXQ3ejRtZjM2RUp2Mlhhbnh5WDREWkpNQ2JHSW9W?= =?utf-8?B?SVRkRHFxWHlJTFQ5RjRXVU44VUl1NGdJcXVtdm01VEp5dTJzRWhGeGg3VGZw?= =?utf-8?B?amJWZzNVeUFGSTh0Z3lyam5kS0cycklNQVJTa3hZWGxmbHlZUTZ2VnZRYjZa?= =?utf-8?B?ZCtPOHh4YmdZS3dnMEhkNVh0aC9OU0Vqa3NaakFVVzgxbUliRW9EeDRDdVZZ?= =?utf-8?B?U0RuenJLVmN0Z2Q2Y0hzZjlSb0V6WGZwVDdqQXpNL3hvdUJBTHA5QzE1UVBE?= =?utf-8?B?dDZqWEdpUE1Gbm9xd2NhaE9Iejlyd2ord0RoMytyeHJjRHUweXhVQlNLUm9q?= =?utf-8?Q?SMBo=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WHF4aDMzRHJPdW9VNmlyVGk2OUlKSUE5VXIxNGs2WDBuclBjUjZ4RW1icnNh?= =?utf-8?B?SWkxWVB3NWlpa21aNmJQZ1FMeHJ2TVJ0WkJnd2ZNSzIxYmRvTklsWUovd1Vx?= =?utf-8?B?RHNEcmVaSVlNMC9xa0lldll6UDNPS1V6K1RsS2hwSlZDTW5EbDluNnFWVE1L?= =?utf-8?B?d1JFbkhZWFRBQk1wWVZIdVZrSHpvbUw5QWpRcEVkSlp1NmsremR0ZDdiUmFo?= =?utf-8?B?U0h4OHJ1UnBvVlNaS3QyVnRPQVZHQVBkUVVzcWN0UmszV0FIN2t0RytuSS93?= =?utf-8?B?UlpvRytLamdKOWxFbVhpMjd5ZVlLUnlPSzJYRnZoVFpjQUtSdHgzeDJkQ29j?= =?utf-8?B?TUQ0M2lYVXpteE9ZL0dGUW5CUW9Ccm5md0lKdXVwaDJNSWlod0hSQkRYUjBq?= =?utf-8?B?SEJMQTZBclR6Z0swSkREQTMwREZ6RHluVm4yemRNWis0QWw0WEh0RTUxK24z?= =?utf-8?B?djE1N0RteDNkK3Z5czhSQW1tT3M4ZU8vK09hK042d1hPN21tbVRGbmM2Nm9m?= =?utf-8?B?cElXRXF2WFpjdTdPTzVKZUtFc3FzL2ZUZDlEd3VPTkoybXltb2o4U1k1aW1G?= =?utf-8?B?UE0xNlFoQm0vMHltODVPUlVqYitOOWJrSWtEWTVSS3VHM0t1elhsbzdXbjk4?= =?utf-8?B?Ymo4a0ZlTkRFKyttZHk2aXBzdmJLbU11MzVtVWJDN1NTbXdCMGVLeFYyYU1p?= =?utf-8?B?TW5mT2UrUEt2SVdFc2U2Rm4wSFExQ1I5c01HQW53UU1PSVRmZW1qQjhRUDBx?= =?utf-8?B?TGxEZFdBZHpxYzRDUDFFcXVxaFFHTVFuYlZmcUhxQ2M4dFpyWExaQ1B2ODFw?= =?utf-8?B?WS9MaC9XTGZrbWE2L1lnMFVkamhSTzd4RVZtS0g5ZHZRRXJ1blhyMEs3SEN0?= =?utf-8?B?V2h2R3N2WDlrZ2NvMXFTcmxzY0ptY01Zd0I5Rm5nOGVFZXJBN1FYNHVxYXBD?= =?utf-8?B?R2l1NWZ5WHBXWkIyallGRFpmZW4yeDR1a3dwL1NIUXk0dnh1a29tb29SVDJv?= =?utf-8?B?N0tsTTZITTkvU0RzeVU0REU1RGNBczk1dXZSRUlRZFJpTGQ0RVJHaEp4T2pD?= =?utf-8?B?RFRIaTdWQXBEZzBHMi9sQyszTzhsVkowWDV0WGw2RUVQQmNKbnh2N0VVKzdv?= =?utf-8?B?aVM2M243WEo3T3ZKb2lLdk9adExyOVNBVkExM2hycVcvd0Y5NnEzTllBY21x?= =?utf-8?B?ZlVHa3lKejA2NkVuVTk3V2hsaUZxZUR6VXR5SVFoSHVNRENmVDY2RGF6ZEIy?= =?utf-8?B?bXRZS2dUSDBpdjVraWNib1htTzd5ZTdjdlNteXMzSlRpb3FRcE5yc0hpUUdI?= =?utf-8?B?TkZlU1JDeUc3NWZLM29XVWsyZWQ5V0ZQbEVreXpySWRHRThzN0lXWVBsTy9H?= =?utf-8?B?VSt2cUZqQVErZHdOTXQvV2dyUUZDMnF1cDM2WEVmTG00R29oVyt3aU94RjdD?= =?utf-8?B?RFFrRnc1UWJQOGVrZlZtcS8xNVdkTGc2N2h1U25tWis3WmpRZkRRdGVzZ0VG?= =?utf-8?B?aFJDNXRMRXpIUWFuRUx1MFhTeGdVVnBSL2pzd0RrakdxOElQUTdNU2NaYlpC?= =?utf-8?B?UFN2V0lwN1o5QTViRnVMRWhLR2IvcU8zQnIxMHJNMEljZGhqQ1UrYXdMUlpT?= =?utf-8?B?WXJ6OEZrTlJXWGpwU2wvQmRGMUpYMUlGWDlWYXJPTk5Oa215YlpTRnZEU3RV?= =?utf-8?B?dFRBV2xGaXE1OXRrQzhUTWFxOTA2Q2JCM2JlOG1FRzZ2M2lGUnFEYzYwa0My?= =?utf-8?B?OURiZU5qNUhmSDRHVVdrVVZJdHNFN1czTnJKMmt0TFkrSDRTQ044eXBFZnAx?= =?utf-8?B?aWFCa2txeDM4S0dscHJXTkw4R25VbUVMWndLMzRNam0rN1dZdEJMMTB6UzEx?= =?utf-8?B?clllUnVoZ3lyTytwUU5oTUJtaXlGd0pSY3BWQUF6VE9qYi9abjFFL3NEbzUr?= =?utf-8?B?RDhpYkpJSDNXRlc2bm1Xak5RWDFIQStkdzcvMjBZcm9ETHRHdzZPSzdVVk1C?= =?utf-8?B?eW9CWW84SEZBQXlIQmZCeUZhV09NNmp6TkxRa0Z4TDNpSXdjbHdoWFVjK1Bx?= =?utf-8?B?MzU3czRkT0JyK0hrZjFSTml2RVk3Vkx4azZCV0ZjR1BWNFhJNmRNNDM5Nkt2?= =?utf-8?B?WU95ZFYwaEk2R1VKMFluNmw2azlvb3pHOTF5NVlNTjhuV1FrQmpPTnNkYW53?= =?utf-8?B?TE5sQ1BIWG1kb0lHNTd0bWoxOHNSTXErbmpmY1BtSHZscGRIbDA2aU1TNnhm?= =?utf-8?B?U0hSdk1YTE8zMDk2a1RlY1I0YjhOYklEZTh6Um5waTlrOHVSanVyeXZ1S1Er?= =?utf-8?B?VEZXWitIQjBoRE5Oc0Q5VnZnVHd3NVZldkM1bjVGdHpFMXBNa1Ivbm43OGhx?= =?utf-8?Q?Yk8KCYD1RCX/jcSY=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 86a1a5c3-3750-4f7e-9f06-08de59c19e6c X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 14:22:05.6137 (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: gXlPP6zD1lwmZTZIuOZBo3NsPX/TLg1FFvNp57yDPImqPtlwNYfDW9XJ1Kmu7S81qheBXqPLkMZZQbJHmw5U/mdVWJzCIMxcXJWaM+wZ3hY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR03MB5149 On 22/01/2026 2:17 pm, Uros Bizjak wrote: > The MCE_GETCLEAR_FLAGS ioctl retrieves xen_mcelog.flags while > atomically clearing it. This was previously implemented using a > cmpxchg() loop. > > Replace the cmpxchg() loop with a single xchg(), which provides the > same atomic get-and-clear semantics, avoids retry spinning under > contention, and simplifies the code. > > The code on x86_64 improves from: > > 186: 8b 15 00 00 00 00 mov 0x0(%rip),%edx > 18c: 89 d0 mov %edx,%eax > 18e: f0 0f b1 0d 00 00 00 lock cmpxchg %ecx,0x0(%rip) > 195: 00 > 196: 39 c2 cmp %eax,%edx > 198: 75 ec jne 186 <...> > > to just: > > 186: 87 05 00 00 00 00 xchg %eax,0x0(%rip) > > No functional change intended. > > Signed-off-by: Uros Bizjak > Cc: Juergen Gross > Cc: Stefano Stabellini > Cc: Oleksandr Tyshchenko > --- > drivers/xen/mcelog.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/xen/mcelog.c b/drivers/xen/mcelog.c > index 4f65b641c054..abe658c73b7b 100644 > --- a/drivers/xen/mcelog.c > +++ b/drivers/xen/mcelog.c > @@ -165,9 +165,7 @@ static long xen_mce_chrdev_ioctl(struct file *f, unsigned int cmd, > case MCE_GETCLEAR_FLAGS: { > unsigned flags; > > - do { > - flags = xen_mcelog.flags; > - } while (cmpxchg(&xen_mcelog.flags, flags, 0) != flags); > + flags = xchg(&xen_mcelog.flags, 0); > > return put_user(flags, p); > } Oh yeah, that was very daft beforehand. Reviewed-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Thu Jan 22 14:22:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 14:22:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211167.1522707 (Exim 4.92) (envelope-from ) id 1vivZo-0007b0-Q2; Thu, 22 Jan 2026 14:22:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211167.1522707; Thu, 22 Jan 2026 14:22:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vivZo-0007at-NZ; Thu, 22 Jan 2026 14:22:24 +0000 Received: by outflank-mailman (input) for mailman id 1211167; Thu, 22 Jan 2026 14:22:24 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vivZn-0006ZI-W7 for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 14:22:23 +0000 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c4c9374d-f79d-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 15:22:23 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 1CB3940E02E6; Thu, 22 Jan 2026 14:22:21 +0000 (UTC) Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DMMlNX1pwdPh; Thu, 22 Jan 2026 14:22:18 +0000 (UTC) Received: from zn.tnic (pd953023b.dip0.t-ipconnect.de [217.83.2.59]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with UTF8SMTPSA id BCA0B40E027A; Thu, 22 Jan 2026 14:21: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: c4c9374d-f79d-11f0-b15e-2bf370ae4941 X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key) header.d=alien8.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1769091737; bh=F8/cDg8dqL5KJe1easlfTdEAUVQhlPJZ3aHQ6mYvBTU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iJ3WBinh+XcE+G/KfxLdDGCXADNRC9ycWVeM2gABf0SdO8V9yXTM1WBn15ikHgJIT M6JboIoIcrDLHxvifc+9Rjllxl4a6WvScepwxfgtT9SOVQ9n4YJnEvd9XdYjn+znje EaCisS7Pw8BsAGasRjcFY8RRw2gcJBAhoMrGalf7k4BF61trK+dCkmYgdF96Flg8nC JTe/8fSuEo8/JOzdLETpMfATpvyI8r1Fj5Iw/WG53f07ifzAmQ4PSJGOlYZmpm1IWn WZe7K7UwZteZZoy+a22HE8oKTqQJ1nZluAsSoMuqV+9w5PSQmtC/FKCxv7v/kFS3L+ x0xHzifg7elq9pl7P3ucTvRZp/k1jA9S1cgvrkCkM2KB7cxWNEG6l6wkgFyN01LjTP 3j0JsT1CM2nqFyf8qIaZmA53Jrx+LlkrwFh5p+HLAcejQYnaz64KSLayjjKxit9PpU +bd4EqnsjnLmpmORLKHpIZ+z+k1wGtptAEZPLUDByscrKyUO7FIM9MkeYMKGkUBkX9 X/sPrZSXo0Xxb2kO8p8uOydIfBzyFMKKo7CggP0pmRMzLD2hP71SOAyZ1aL2jlOOdP /5y1JH2lt/gVIerwgWc9dK0cWdpeONREfMJpOl3jNWUIgjMthftBkryLuix/kVV7Is bO6g82DIs31iXATqIrXJrsx4= Date: Thu, 22 Jan 2026 15:21:56 +0100 From: Borislav Petkov To: Hou Wenlong Cc: linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Boris Ostrovsky , Peter Zijlstra , "Rafael J. Wysocki" , K Prateek Nayak , Li Chen , Brian Gerst , Sohil Mehta , Tim Chen , Patryk Wlazlyn , Eric Dumazet , xen-devel@lists.xenproject.org Subject: Re: [PATCH 1/2] x86/smp: Move the static call update for 'smp_ops' into smp_prepare_boot_cpu() Message-ID: <20260122142156.GEaXIyhNQeGvOR5yyu@fat_crate.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Thu, Jan 22, 2026 at 10:15:43PM +0800, Hou Wenlong wrote: > The commit 1f60230cdc63 ("x86/smp: Use static_call for > arch_send_call_function_ipi()") changed to use a static call for > arch_send_call_function_ipi(), which causes two problems: > > First, the KVM guest also changes 'smp_ops.send_call_func_ipi' when the > PV sched yield feature is available. However, the missing > static_call_update() breaks the PV sched yield feature. > > Additionally, xen_smp_init() is called before static_call_init() during > the booting of the XENPV guest, which triggers a warning in > __static_call_update(). > > To simplify, move the static call update for 'smp_ops' into > smp_prepare_boot_cpu() to address these two problems together. > > Fixes: 1f60230cdc63 ("x86/smp: Use static_call for arch_send_call_function_ipi()") > Signed-off-by: Hou Wenlong > --- > I'm not sure if the XEN part is okay or not. I think there should be no > IPI before smp_prepare_boot_cpu(), and even if there is, it's okay for > the KVM guest to use the native version before smp_prepare_boot_cpu(). All three commits zapped from tip:x86/core. We can try again once this is resolved. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette From xen-devel-bounces@lists.xenproject.org Thu Jan 22 14:40:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 14:40:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211205.1522730 (Exim 4.92) (envelope-from ) id 1vivr4-0003Bi-Ao; Thu, 22 Jan 2026 14:40:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211205.1522730; Thu, 22 Jan 2026 14:40: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 1vivr4-0003Bb-81; Thu, 22 Jan 2026 14:40:14 +0000 Received: by outflank-mailman (input) for mailman id 1211205; Thu, 22 Jan 2026 14:40: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 1vivr2-0003BV-Pq for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 14:40:12 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3f65397b-f7a0-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 15:40:08 +0100 (CET) Received: from DM6PR02CA0132.namprd02.prod.outlook.com (2603:10b6:5:1b4::34) by DS5PPFA33D606F8.namprd12.prod.outlook.com (2603:10b6:f:fc00::65b) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Thu, 22 Jan 2026 14:40:03 +0000 Received: from DS3PEPF000099D9.namprd04.prod.outlook.com (2603:10b6:5:1b4:cafe::cc) by DM6PR02CA0132.outlook.office365.com (2603:10b6:5:1b4::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.10 via Frontend Transport; Thu, 22 Jan 2026 14:39:54 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by DS3PEPF000099D9.mail.protection.outlook.com (10.167.17.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Thu, 22 Jan 2026 14:40:02 +0000 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.2562.17; Thu, 22 Jan 2026 08:40:01 -0600 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; Thu, 22 Jan 2026 08:40:01 -0600 Received: from [172.23.120.160] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Thu, 22 Jan 2026 06:40:00 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3f65397b-f7a0-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iVHewvbGwC3AJzgFxZVSbCsEIKnnh5T7RUXUb8dfNwlENONkdHmy82hbJdF+00CRwvp6b02YXcUCELgqmN1GmDyPWVAxvNnqyOk9mjh7Yzjt0gde45MCWhDWN2Y7aMnfMlN4ONcRVOe6KN//xNlFYe8S1/w4FLnEkSTWBEbair/OJze+K/dhl+0r0NpUCwovaBxeZtbR3TfLfz8r3G5Xry9RMHqrohs2Xe5hneif+OgjPfQnVFU8EBLXICXXTZVjeOb5UpLkUwrFMqjoaiQuXzmzoNCdhkFCNp4fy3t96zapicKa6/WUfbsvasHTKXC3QSbCOierC0960HrcIfCmLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4rnVIdtsp6adCpj2/AzCDEMpWp/XE1GW63wMHnfkltg=; b=K4heggcivcOBfbeSimYwaI+vx25AaTMusLj1d3N2+eftPOVD3UdTlUf/xUZOevMo1OGsIC5I9eW9VAKSQerghGBIj6R2OqCqbhLmAzPbjoBjWj19eJ/lJ1tcP+Ro/YRerk1kpFHzKXYte8uZyKmy8huM78NAK0MM3132LnctY3PrWzAI4HZATRNoa9ynMWJp4M72/zBhhJN+sDhSvx+RdY4H12dx1W5FDX6OJwxBkFVdwIexsI7HCABlPWn1sEDpjY4UpVVPQc9Tw7JzlzG5qd7/IM4n+aI20W/Ntq1MED2j+KdALZZQeCvX+nnMI2+qwqx1phqNSxQtlkU2NkJnQw== 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=4rnVIdtsp6adCpj2/AzCDEMpWp/XE1GW63wMHnfkltg=; b=uVWFGT3fCFtTBSNc0wKMIrkjbhHRIEbTDe+W5P2Wiopz814QjGVCYMPTLTIhqKhYSn0KKmT+Y1XvN5eEuBepvbNeQqrtK5ixyD1TzIHVYPuZdnTkQCkHJLFKa0qKhzivrymeLwXzM+8NxWq7I58kVGKXLjwmL3Yk3NN4uL/T/yY= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: Thu, 22 Jan 2026 09:40:01 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Partial revert "x86/xen: fix balloon target initialization for PVH dom0" To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= CC: , , "James Dingwall" , Juergen Gross , "Stefano Stabellini" , Oleksandr Tyshchenko References: <20260120140648.25977-1-roger.pau@citrix.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS3PEPF000099D9:EE_|DS5PPFA33D606F8:EE_ X-MS-Office365-Filtering-Correlation-Id: f71e561f-7ab9-48d6-1896-08de59c42023 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?anpqSGtNVFlIdlJyeTR3L0VpTE43OXNXRk8yd0JCL0pTZTZ3aEtrZmg5enFD?= =?utf-8?B?Q2lyVzJmTnlQbWpWZ04vUGpxUHhyZmhJWHBoTmNWRm5OZVlNdkZvU1I1OFJB?= =?utf-8?B?cHpiQlZBVDVxNHpsQlV0YlpuVnpJclBjbTRWejdCYTZWenAwaXp2SmtDcGlV?= =?utf-8?B?OTBEYm82ZmhFWitkK3B1MFh4QjZzOHh5cTRoWkJPVHcrR3FYZkhjS2hENDNG?= =?utf-8?B?SFJ1cS9NMTU2aXhEbGxWN2lZY2c0QkUrVkNxd3R2R3ExZW5HVnBUaTRrKzdt?= =?utf-8?B?VWd6ZjdBVy9qNTVQcHR3bDZydTdiT2RGTUtRUVFwbXJBOTBVSTZtU3E1UUdR?= =?utf-8?B?UHgvYk9IeGFWQkdsblpXNTNEY3Z0OU0vc3RvcVZCeXJkV1N6MEt5ZllQeElV?= =?utf-8?B?U1EvWnJnZHRqVVM2SXQyUzZyczM4NGR4WDFleitYNFBiSUdPV3ZKbGMzVXQ5?= =?utf-8?B?OWZBalNuZ1N4cGhwTUNwamxKc1UwYlhHTzRHZWtqME9JQkFYRzBvMWxOTnpG?= =?utf-8?B?Z3pYSkNlS0dTajBPR3E2b3R5dWtENm9pTlI4QzBrRnBwSmFFck0vdDFvRlMz?= =?utf-8?B?MWNEeFVVbzlBcjYvbWd1TFBjYVB5WkdmYUtReWFvaEppRk1MZFlmSm1vQ045?= =?utf-8?B?azhTbjFrVzhDTkk5NGVhVFdjbXVxbldRNVB4QU1JUVFXQUhGRWtxM2RNWlp6?= =?utf-8?B?amlIZDlSRTRuR29KamZtV0tnK0k3NVpIMVg0R2RFblNIRDl3bW1UKzFzRzA5?= =?utf-8?B?dXB3NjV2ZlhuVG5CVjRpWWhNY3lHRUVxZzBzMGRvWEtYZmFyTXNobG9YNDgv?= =?utf-8?B?MndOaS9ZK2J0emFXd3IwemlXRkw5OXdtTkhmS1drRVA3N0g4SGVNVE1vUlpp?= =?utf-8?B?YWlmclFCczd0c1ZjRzdONkdzRXgvM0MrU3RnZFBib2xmUzV6bzl1ODFiSHo4?= =?utf-8?B?Nms5SHVENFlkZCs2czNoRVNHYkVSOHB5Qk81Sm9LanVHWnJEQVdpUzRaMTFS?= =?utf-8?B?THRCYlpRbDRrZDBxTHpuL1R6S3FiUTAyelRhQlpDMkhVV2JEN29vL1ROT2JH?= =?utf-8?B?ZW5xY0pzUWp4bStkUko3eTV1SjJKdFgrNjF0UG1wZDArNUU3ZHFSYWduU1Iw?= =?utf-8?B?VVMyTGN5MzVZQ0dDSk9ZdWFRcUhMMmlzZ2VnOUJJYmxydEhDZ1ZucFVjRVFN?= =?utf-8?B?R3dTdThOZ3dwby9xS1UxK0hMbVl4aUtrZG1Rd1I5cjEvMnVwMXFBR1l4TWVz?= =?utf-8?B?anBlZnd1U0oyRXZoRW9nNGRsWFpVQ21ETE1odEZBVjFPbE8xL2lEQkxwa2dQ?= =?utf-8?B?STNyTzArT1dHVjdndzlnb0MyWkFrNUswSnprZEducEtNK3pHSEFCYzh3U29I?= =?utf-8?B?dFpuM1kzc0VBZkpqeDhxUnVaZVFUNmVIOXlrRlhhemlMbW9XVk5DVXgvNGFS?= =?utf-8?B?SjZOOWtVZytJWFlRTFg4Z1dqdEx6ZGk4QVdmYUMyWlFiUnRvS2FTNTdzMTRK?= =?utf-8?B?ZFg3N21CNXBGYnkvZkhFNFJKazNHcVlKTDR3TmVoMmQ1RUpnMTdXZWVoUURP?= =?utf-8?B?Z25xMG9rVEhuRUNsWEU3eHJiNER2d1RycTdDZ3lkaGE1cUIrZ0lPd3BlOVBR?= =?utf-8?B?QUU2K28zRWkzR2pUR1FNSnRxYzlFb1R2cmVmNCtXc09mbVUxUThOcW9jbWNk?= =?utf-8?B?cHM4eTVWR2orR0tIcE9scUdvM2dqZjlJNUEya1FVUDdubHYwMXFBelJmR0Mx?= =?utf-8?B?NktiTllLaWJiRGhhYXFwMEZIN3BxWFFUOXZFRVF6V0JWYUdQVzc3VGZZd08y?= =?utf-8?B?eGlLLzNqRE9OSzU4Vkt0em1iWVlxT3F1K2txdjUweTNxSEhZN3B0RzFnMFR1?= =?utf-8?B?UGZ2bUJyS2VZZHZjTlRmUjFiU1lKWnd0Q2NTd0NoZUZaZVU0N3NBaFB4ejBX?= =?utf-8?B?TVhrZXVVNzI0bzhTd2VsRzJVRDVJaFd1MktKMExCV1lPM3VOWEV5N1RPeTgr?= =?utf-8?B?b2JyV2tmSnN5c201dzVSLzJQaHhQQmRYVzFYVFZFWE0zRkFQWkZQK0NXQngr?= =?utf-8?B?WGx4U0UrQmZmRnZoeEJXKzlCN1VNOWhjWVFQM3hycXpVTTdGYkdCT3o5S0F1?= =?utf-8?B?MS8zWk9Ddi9zSTAxN1BSVWdaQmk5YmxCbkUxUGwrYi8zK01VYW5laEJqY1cw?= =?utf-8?B?VTA4SW0rMW45TTJIUjdsZW1TUWl5UDI2ZTlyZHRLV2I0MkptUWxkbjU4a3Rl?= =?utf-8?B?QU5RTUFQaEs4TE5KNUhyUUp2Ty9BPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 14:40:02.0428 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f71e561f-7ab9-48d6-1896-08de59c42023 X-MS-Exchange-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: DS3PEPF000099D9.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS5PPFA33D606F8 On 2026-01-21 12:49, Roger Pau Monné wrote: > On Wed, Jan 21, 2026 at 12:21:33PM -0500, Jason Andryuk wrote: >> On 2026-01-21 06:17, Roger Pau Monné wrote: >>> On Tue, Jan 20, 2026 at 03:10:06PM -0500, Jason Andryuk wrote: >>>> On 2026-01-20 09:06, Roger Pau Monne wrote: >>>>> This partially reverts commit 87af633689ce16ddb166c80f32b120e50b1295de so >>>>> the current memory target for PV guests is still fetched from >>>>> start_info->nr_pages, which matches exactly what the toolstack sets the >>>>> initial memory target to. >>>>> >>>>> Using get_num_physpages() is possible on PV also, but needs adjusting to >>>>> take into account the ISA hole and the PFN at 0 not considered usable >>>>> memory depite being populated, and hence would need extra adjustments. >>>>> Instead of carrying those extra adjustments switch back to the previous >>>>> code. That leaves Linux with a difference in how current memory target is >>>>> obtained for HVM vs PV, but that's better than adding extra logic just for >>>>> PV. >>>>> >>>>> Also, for HVM the target is not (and has never been) accurately calculated, >>>>> as in that case part of what starts as guest memory is reused by hvmloader >>>>> and possibly other firmware to store ACPI tables and similar firmware >>>>> information, thus the memory is no longer being reported as RAM in the >>>>> memory map. >>>>> >>>>> Reported-by: James Dingwall >>>>> Signed-off-by: Roger Pau Monné >>>> >>>> Reviewed-by: Jason Andryuk >>> >>> Thanks. >>> >>> I've been considering what we discussed and as a separate follow up we >>> might want to attempt to switch to using `XENMEM_current_reservation` >>> for dom0? It might make the accounting in PVH dom0 better, as that's >>> what the toolstack uses to set the xenstore target when initializing >>> dom0 values. >> >> Yes, I thought that could be a follow on. I've attached what I have tested, >> but it is based on a branch pre-dating xen_released_pages. >> xenmem_current_reservation with PVH dom0 seemed good without the >> xen_released_pages adjustment, but I don't know what that would be for a PVH >> dom0. >> >> Regards, >> Jason > >> From 8b628ad0ebe52c30e31298e868f2f5187f2f52da Mon Sep 17 00:00:00 2001 >> From: Jason Andryuk >> Date: Fri, 7 Nov 2025 16:44:53 -0500 >> Subject: [PATCH] xen/balloon: Initialize dom0 with XENMEM_current_reservation >> >> The balloon driver bases its action off the memory/target and >> memory/static-max xenstore keys. These are set by the toolstack and >> match the domain's hypervisor allocated pages - domain_tot_pages(). >> >> However, PVH and HVM domains query get_num_physpages() for the initial >> balloon driver current and target pages. get_num_physpages() is different >> from dom_totain_pages(), and has been observed way off in a PVH dom0. >> Here a PVH dom0 is assigned 917503 pages (3.5GB), but >> get_num_physpages() is 7312455: >> xen:balloon: pages curr 7312455 target 7312455 >> xen:balloon: current_reservation 917503 >> >> While Xen truncated the PVH dom0 memory map's RAM, Linux undoes that >> operation and restores RAM regions in pvh_reserve_extra_memory(). >> >> Use XENMEM_current_reveration to initialize the balloon driver current >> and target pages. This is the hypervisor value, and matches what the >> toolstack writes. This avoids any ballooning from the inital >> allocation. While domUs are affected, the implications of the change >> are unclear - only make the change for dom0. >> >> Signed-off-by: Jason Andryuk >> --- >> drivers/xen/balloon.c | 9 ++++++--- >> drivers/xen/mem-reservation.c | 8 ++++++++ >> include/xen/interface/memory.h | 5 +++++ >> include/xen/mem-reservation.h | 2 ++ >> 4 files changed, 21 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c >> index 528395133b4f..fa6cbe6ce2ca 100644 >> --- a/drivers/xen/balloon.c >> +++ b/drivers/xen/balloon.c >> @@ -713,10 +713,13 @@ static int __init balloon_init(void) >> >> #ifdef CONFIG_XEN_PV >> balloon_stats.current_pages = xen_pv_domain() >> - ? min(xen_start_info->nr_pages - xen_released_pages, max_pfn) >> - : get_num_physpages(); >> + ? min(xen_start_info->nr_pages - xen_released_pages, max_pfn) : >> + xen_initial_domain() ? xenmem_current_reservation() : >> + get_num_physpages(); >> #else >> - balloon_stats.current_pages = get_num_physpages(); >> + balloon_stats.current_pages = >> + xen_initial_domain() ? xenmem_current_reservation() : >> + get_num_physpages(); >> #endif >> balloon_stats.target_pages = balloon_stats.current_pages; >> balloon_stats.balloon_low = 0; >> diff --git a/drivers/xen/mem-reservation.c b/drivers/xen/mem-reservation.c >> index 24648836e0d4..40c5c40d34fe 100644 >> --- a/drivers/xen/mem-reservation.c >> +++ b/drivers/xen/mem-reservation.c >> @@ -113,3 +113,11 @@ int xenmem_reservation_decrease(int count, xen_pfn_t *frames) >> return HYPERVISOR_memory_op(XENMEM_decrease_reservation, &reservation); >> } >> EXPORT_SYMBOL_GPL(xenmem_reservation_decrease); >> + >> +long xenmem_current_reservation(void) >> +{ >> + struct xen_memory_domain domain = { .domid = DOMID_SELF }; >> + >> + return HYPERVISOR_memory_op(XENMEM_current_reservation, &domain); >> +} >> +EXPORT_SYMBOL_GPL(xenmem_current_reservation); >> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h >> index 1a371a825c55..72619a75fed2 100644 >> --- a/include/xen/interface/memory.h >> +++ b/include/xen/interface/memory.h >> @@ -104,6 +104,11 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_exchange); >> */ >> #define XENMEM_maximum_ram_page 2 >> >> +struct xen_memory_domain { >> + /* [IN] Domain information is being queried for. */ >> + domid_t domid; >> +}; > > Other callers that would use xen_memory_domain just pass a pointer to > a domid_t, I think you could simplify the patch to the diff below, > which sits on top of the patch here: Ah, yes, xen_memory_domain is just wrapping a domid. > > I haven't tested it yet to see whether that's OK to do on PV, I would > think PV and PVH would be the same here, since the setting of the > xenstore target value is based in the return of > XENMEM_current_reservation for both. On a system with 32GB and dom0=pvh dom0_mem=7G: [ 0.295201] xen:balloon: current_pages: 1835007 get_num_physpages 8220126 xen_released_pages 6385120 [ 0.295201] ------------[ cut here ]------------ [ 0.295201] Released pages underflow current target 8220126 - 6385120 = 1835006 And also for PV: [ 1.406923] xen:balloon: current_pages: 1835008 get_num_physpages 8220127 xen_released_pages 6385120 [ 1.406928] ------------[ cut here ]------------ [ 1.406931] Released pages underflow current target So we don't want to subtract xen_released_pages for dom0. Is xen_released_pages expected to be non-zero for a domU? IIRC, for a domU, xl writes the xenstore nodes as the ~build time memory value, which doesn't include video ram. Later QEMU populates the videoram, which increases current reservation. Then the two values don't match when the domU initializes the balloon values. Regards, Jason From xen-devel-bounces@lists.xenproject.org Thu Jan 22 15:53:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 15:53:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211254.1522772 (Exim 4.92) (envelope-from ) id 1viwzC-0004if-Lf; Thu, 22 Jan 2026 15:52:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211254.1522772; Thu, 22 Jan 2026 15:52:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viwzC-0004iY-In; Thu, 22 Jan 2026 15:52:42 +0000 Received: by outflank-mailman (input) for mailman id 1211254; Thu, 22 Jan 2026 15:52:41 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viwzB-0004iS-E0 for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 15:52:41 +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 612cf647-f7aa-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 16:52:39 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-48049955f7fso8007575e9.0 for ; Thu, 22 Jan 2026 07:52:39 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48048b49880sm62345445e9.11.2026.01.22.07.52.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 07:52:38 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 612cf647-f7aa-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769097159; x=1769701959; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=nZIawYq0A2BmElPcAHp1yYp0QcDuY8+KPx7RCo74AlU=; b=GRrzPPnL33fszIZPUqpBSuLIaStCzcN8ePKva0Sbp6eG9Ld3N8cdltG3KcRoSWP8om b7RcQ4WD/yxNN2/HQGjmQWAsEeYKLCdTXpBp2ZvC5GhIU0UaY8BLCwNed6ZHv2QkSeyH yeVhry0D/dmKno3ddZe8RmEJ+6wJKOBsi7jZEDDGpgkA9f6GtpmuYnJYGI3IYiFJX3GE chciJuFUOX75+WLoUlLHhrqBuVSMzDN/WjA9846nTzB5Bj/rlBO5A2S1oBd9Ba24wpqf 1A8WlQaAFtfWyT9dOJpRAEurx/W/8ASZ7JIH/y8XbfSyWsOghpj34TziHqijHgZXdQIf C9pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769097159; x=1769701959; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nZIawYq0A2BmElPcAHp1yYp0QcDuY8+KPx7RCo74AlU=; b=ebt5miR99OCZ5ydC2ZkOJygivLNaFicNWaPkUfL4bwAzXRRFQW2UcdnmTZBTKwups2 kfxHU4HO8FoIDVZvm9YSR4ssMf8s3jQtQpp8d1O3argNhlO+PqWD7yjxpoCrbA3HSS02 GHyAg51ABCX41CAXk5lqNjIAih9lt0IvKbnEMwNOYlRUpg1BQzVr12Ys6p/MY1dcPcyo Qt07IjYjb1bZVg3bYugNpqsMwJpwBbHg/o0ImJdbg/lPHFq6KfW3aLcWCmNt6Sh5jVBQ hUnhwRk+pnSe1rtAklz06CdY7dbx4VIJOPVal9jSCH7Dz0WSSyLVgYFAyQjiVd6qLbKb Xp8Q== X-Forwarded-Encrypted: i=1; AJvYcCWANIur0FfzTwmR1/YCcMA018r9vWn94oduz8Xn1WxcEKUunLGC/T7DkY9yz0isVGh4RAr3A/YVFB0=@lists.xenproject.org X-Gm-Message-State: AOJu0YxDiNAFueYpNWcs9Xbo13VUSV/7IARL8SkBOaRwgHpl/2G6bBpV lKTGh5GlmbFoPSBgK1EaDaTcj0uYMJW863jzrvMhJpZGeMExQmy0yGjhVqY4Lt7RcA== X-Gm-Gg: AZuq6aLaeyH++boGqFfdRmYSxtZOySpXrgO4vqhcp+oof8/k77wiHWM0aJkWqRVibVt n+NMVyZMFxG1GNf2pbz1Mt4XFqS5ii3dqWLUFpKQoJyLbkevitp1DeV4dS9uiamXxDXSxuq3qVH TQ4A7HhtJbih72q2chTNBy0mFfi0F1UDcnard2zZbP9OjJ98tCiIhhcz7oTZD3rOS8slA3b7izM a+Bdhf0pNgEnBBhrxXnWcSkoA7Non3N+VRhkXs7KgL6+PcVi93qGtwlfzW9BnQoD/4t2fsqO+/S htl8iTE6rqSI5wwBGm1ZUJc/1404tzh9w5S0uiR6N/ec10KFsJsJ8zWceU5zZFveVm/t2XEFC0H YQWoKHDB4Yz8bvfJ/ZIZFtRN1t79QfNJ/2sbFGKuDzOfdM0Uc0E1yfmSNCIJEpKlWYDupfD3gZK 1wU6N0IRrEroT3OqRhW4Sq4lbDYWRIVCUQbiQjTsf9E6TEfM4vMn3per5QfcAxJVQRb3XKMdv71 rI= X-Received: by 2002:a05:600c:8b86:b0:480:4ae2:def1 with SMTP id 5b1f17b1804b1-4804c96110bmr1269925e9.13.1769097159037; Thu, 22 Jan 2026 07:52:39 -0800 (PST) Message-ID: <1483a375-9662-48b8-8bf2-8cc83386b068@suse.com> Date: Thu, 22 Jan 2026 16:52:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 14/22] x86/boot: choose AP stack based on APIC ID To: Sergii Dmytruk Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org, trenchboot-devel@googlegroups.com References: <16a5438f73a026d4db1a5340f599d4839c74fcc6.1748611041.git.sergii.dmytruk@3mdeb.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <16a5438f73a026d4db1a5340f599d4839c74fcc6.1748611041.git.sergii.dmytruk@3mdeb.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.05.2025 15:17, Sergii Dmytruk wrote: > --- a/xen/arch/x86/boot/trampoline.S > +++ b/xen/arch/x86/boot/trampoline.S > @@ -71,6 +71,27 @@ trampoline_protmode_entry: > mov $X86_CR4_PAE,%ecx > mov %ecx,%cr4 > > + /* > + * Get APIC ID while we're in non-paged mode. Start by checking if > + * x2APIC is enabled. > + */ > + mov $MSR_APIC_BASE, %ecx > + rdmsr > + test $APIC_BASE_EXTD, %eax > + jnz .Lx2apic > + > + /* Not x2APIC, read from MMIO */ > + and $APIC_BASE_ADDR_MASK, %eax > + mov APIC_ID(%eax), %esp > + shr $24, %esp I have to admit that I'm rather hesitant towards seeing %esp used like this. > --- a/xen/arch/x86/boot/x86_64.S > +++ b/xen/arch/x86/boot/x86_64.S > @@ -15,7 +15,33 @@ ENTRY(__high_start) > mov $XEN_MINIMAL_CR4,%rcx > mov %rcx,%cr4 > > - mov stack_start(%rip),%rsp > + test %ebx,%ebx > + cmovz stack_start(%rip), %rsp > + jz .L_stack_set > + > + /* APs only: get stack base from APIC ID saved in %esp. */ > + mov $-1, %rax Here and below 32-bit insn would do fine. However, ... > + lea x86_cpu_to_apicid(%rip), %rcx > +1: > + add $1, %rax > + cmp $NR_CPUS, %eax > + jb 2f > + hlt > +2: > + cmp %esp, (%rcx, %rax, 4) > + jne 1b ... can't all of this be a simple REPNE SCASL? As to the upper bound of NR_CPUS, do we really need to look this far? > + /* %eax is now Xen CPU index. */ > + lea stack_base(%rip), %rcx > + mov (%rcx, %rax, 8), %rsp > + > + test %rsp,%rsp Nit: Blank after comma please. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 15:56:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 15:56:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211268.1522783 (Exim 4.92) (envelope-from ) id 1vix2r-0005M2-68; Thu, 22 Jan 2026 15:56:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211268.1522783; Thu, 22 Jan 2026 15:56:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vix2r-0005Lv-23; Thu, 22 Jan 2026 15:56:29 +0000 Received: by outflank-mailman (input) for mailman id 1211268; Thu, 22 Jan 2026 15:56:27 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vix2p-0005Lp-Oc for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 15:56:27 +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 e86acdd8-f7aa-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 16:56:26 +0100 (CET) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-6581234d208so2237617a12.3 for ; Thu, 22 Jan 2026 07:56:26 -0800 (PST) Received: from ?IPV6:2a00:12d0:af5b:2f01:4042:c03:ce4d:a5a1? (2a00-12d0-af5b-2f01-4042-c03-ce4d-a5a1.ip.tng.de. [2a00:12d0:af5b:2f01:4042:c03:ce4d:a5a1]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b884b989b02sm54552666b.62.2026.01.22.07.56.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 07:56:25 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e86acdd8-f7aa-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769097386; x=1769702186; 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=1/E7sdcisxXYhHIbZbpS6V5IWZlmj/jfjvJggi/9Dbg=; b=Qe16ODlqI3KGdscRTDAX9w2b2qpr79+DcAY+qXSQAziZVRPXItN1Ii6W9X7KPEc4Y7 yLekdrZaPqZf8IUl9AJgXzU/dvnGRRxZCgDUUp2LD7lIrpxExbGomoE3/ur+/pv5sqZb 2hbnOpgxlrWU0ayeuP/LX02AE+tCxCjf0E8U/V+KNqlYESXV6FG4To7zs3v+BCvRRjHf 7FSCUPYAN6Lgzici/T0PApIe1EPmlYuNL9wXoLOF2fdchUd28R8XwVVomTaivD4eQtWI BCQjTb3sMLo/JxFVxlXYs+TXhVGI8YJoWjYaI+37Qlf+nMWZnGVhjhb6H2Yfi7Eay+U+ keXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769097386; x=1769702186; h=autocrypt:subject:from:to:content-language:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=1/E7sdcisxXYhHIbZbpS6V5IWZlmj/jfjvJggi/9Dbg=; b=c8NHPWatZK+xxn6ywVlm9kZhj4yMnXbyVbOFD0zYnOUipovXJ0tFtqzFQO2o3nu0Ra gUXhUBTx7JBYwX0xGuR+hsd583qq56fflyv1kGLZSPQZBKO2LT2j+dau0FAWRBP+QIWy HuXUUYxp9Aac5A470Ntj+kCuvbeIk7l5yeZeGf65GaUyVOwCnJfJp7PScSvcO0d8jf08 ECPbOJeiFPwWcjrb2ng4nhHRhfx5WfYK+w2gGfiXsjL5ankKkLPep9fzxAHeQjgZ/zmT gmRIJl0GZ6ZVCsS93naAZaez14e2UHo6DbaVP6vuord2RmhcuRa4J9/y7wJ4WZWGKf8d D4Yw== X-Gm-Message-State: AOJu0Yxlb/iReQq7C5vdKEleJURJSwgaTmmtMiXPZ2Kcno85ZawuUM+9 /qgX8DlB0QuZDWeHEZGPKksBNZWICSrU7RbWirmAx8OzM1MWKEsARzIUTcfgqa4e6KYfLO3TwvQ /zHUNOZI= X-Gm-Gg: AZuq6aJdWTDqEI/zmtWU182qMpyqD3KVxQXQhKntci9it0ABIYelaEWCu+IRsHpcXUo PCHntl6JVJja/5AOaD54SIgmBRLJxwA/i1MZwIanZfX4HPsFi+SR7W5A2x07FIspudJGfxu1Mvy CvVCVLnWQdjp6LKdZu2HEYdyRVnWTNI7Y1Xm1CPVl1Veb0PXVRlAhwmZyFRpXm9HIXTMW1hugtk KNhdbShyG7dC4WoHuarladf/FnW/TAQltMTKIM3ij5VKamragHjsbmvEaKQ/iMaKXfxbdgBSycz 3WrnxqHqTfyX4K4fiG509gbEqALbO26+df9JIRcsQLwNdIcgU8WYP+VvuIMY4GbFyLTnN9jgpLZ JqJ/Pe9uH1nJUPLt6TlIyDN5dDfI/kdqXDj/3Ccf4thZFKsdDCmcgyffCsTAieb9T7WUS0bK0YU lBP3DY6gGo4eXGCUIAwJ1DKcjBaErQpnYKp0N76riKlUDlmbwvriOvAW5iXXICyr26D/dFvY7z4 vLY8twBq5renV+ZAsK4q7d348aBixHmu9FoZw== X-Received: by 2002:a17:907:948f:b0:b87:3168:2cb9 with SMTP id a640c23a62f3a-b8796b2178dmr1987517066b.32.1769097385730; Thu, 22 Jan 2026 07:56:25 -0800 (PST) Message-ID: <145af46c-eab5-4d0f-ba35-4ae646c0e4cd@suse.com> Date: Thu, 22 Jan 2026 16:56:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" , Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Subject: MTRR init sequence in Xen 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== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------f9dRvQ5fLZLOAKtEW5irvQSx" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------f9dRvQ5fLZLOAKtEW5irvQSx Content-Type: multipart/mixed; boundary="------------AC0R6yBgxZpaPSJgT0trKQPY"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: "xen-devel@lists.xenproject.org" , Jan Beulich , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Message-ID: <145af46c-eab5-4d0f-ba35-4ae646c0e4cd@suse.com> Subject: MTRR init sequence in Xen 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= --------------AC0R6yBgxZpaPSJgT0trKQPY Content-Type: multipart/mixed; boundary="------------dDvoG3z1uC73B4WytztUhJg1" --------------dDvoG3z1uC73B4WytztUhJg1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SnVzdCBhcyBhIGhlYWRzIHVwOiBhIGhhcmR3YXJlIHBhcnRuZXIgb2YgU1VTRSBoYXMgc2Vl biBoYXJkIGxvY2t1cHMNCm9mIHRoZSBMaW51eCBrZXJuZWwgZHVyaW5nIGJvb3Qgb24gYSBu ZXcgbWFjaGluZS4gVGhpcyBtYWNoaW5lIGhhcw0KOCBOVU1BIG5vZGVzIGFuZCA5NjAgQ1BV cy4gVGhlIGhhbmcgb2NjdXJzIGluIHJvdWdobHkgMS41JSBvZiB0aGUgYm9vdA0KYXR0ZW1w dHMgaW4gTVRSUiBpbml0aWFsaXphdGlvbiBvZiB0aGUgQVBzLg0KDQpJIGhhdmUgc2VudCBh IHNtYWxsIHBhdGNoIHNlcmllcyB0byBMS01MIHdoaWNoIHNlZW1zIHRvIGZpeCB0aGUgcHJv YmxlbToNCmh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL2xrbWwvMjAyNjAxMjExNDExMDYuNzU1 NDU4LTEtamdyb3NzQHN1c2UuY29tLw0KDQpBcyBYZW4gTVRSUiBoYW5kbGluZyBpcyB0YWtl biBmcm9tIHRoZSBMaW51eCBrZXJuZWwsIEkgZ3Vlc3MgdGhlIHNhbWUNCnByb2JsZW0gY291 bGQgaGFwcGVuIGluIFhlbiwgdG9vLg0KDQpBcyB0aGUgaGFuZyBhbHdheXMgb2NjdXJyZWQg d2hpbGUgd2FpdGluZyBmb3IgdGhlIGxvY2ssIHdoaWNoIGlzDQpzZXJpYWxpemluZyB0aGUg c2luZ2xlIENQVXMgZG9pbmcgTVRSUiBpbml0aWFsaXphdGlvbiwgbXkgc29sdXRpb24gd2Fz DQp0byBlbGltaW5hdGUgdGhlIGxvY2ssIGFsbG93aW5nIGFsbCBBUHMgdG8gaW5pdCBNVFJS cyBpbiBwYXJhbGxlbC4NCg0KTWF5YmUgd2Ugd2FudCB0byBkbyB0aGUgc2FtZSBpbiBYZW4u DQoNCg0KSnVlcmdlbg0K --------------dDvoG3z1uC73B4WytztUhJg1 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----- --------------dDvoG3z1uC73B4WytztUhJg1-- --------------AC0R6yBgxZpaPSJgT0trKQPY-- --------------f9dRvQ5fLZLOAKtEW5irvQSx 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/Ey8FAmlySKgFAwAAAAAACgkQsN6d1ii/Ey+h oQgAld3oL3uRUs0I0lu/REhpayF7B1QSGKyzvj2+yZL6Wbz/6Pasvf5RJj21zbcw17MHld3HPyVf Iv4K3qOB02AZDC2clXuMcb6TPt+NJvDiJ0XE8Og48jCIBG6rFm63FnH1Tu6D2yNNcacZl4p1SzHW 2pl8C+fhVOJdELpxZdnzeTyCmYQJWg+lzc91E4B3IUYrk9KArOTltavrHQIbd61THCfHGGzkn5+v 1LZJjcrRAkEyGgMl6G5aSHxRUaDQtXgh2aosO7MUOTGDslCl2P9L8YgshCOyNAEeQrWF0KrX0Yne TKijMJQyBRFfkKrUsnhhadF3RK1+7PMnzUaQbB93WQ== =AyRC -----END PGP SIGNATURE----- --------------f9dRvQ5fLZLOAKtEW5irvQSx-- From xen-devel-bounces@lists.xenproject.org Thu Jan 22 15:58:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 15:58:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211277.1522793 (Exim 4.92) (envelope-from ) id 1vix5C-00067v-Hp; Thu, 22 Jan 2026 15:58:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211277.1522793; Thu, 22 Jan 2026 15: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 1vix5C-00067o-E6; Thu, 22 Jan 2026 15:58:54 +0000 Received: by outflank-mailman (input) for mailman id 1211277; Thu, 22 Jan 2026 15: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 1vix5B-00067i-9G for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 15:58:53 +0000 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [2a00:1450:4864:20::329]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3ee9b0f8-f7ab-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 16:58:51 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-47fedb7c68dso12499185e9.2 for ; Thu, 22 Jan 2026 07:58:51 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804703b59esm77178195e9.4.2026.01.22.07.58.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 07:58:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3ee9b0f8-f7ab-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769097531; x=1769702331; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=8K/rAlcKVeT/EVpgXAT2xI8jG/2oag+MCKdQk5/VHMw=; b=Efym1oPrsXPWpnT1ih92WXnTVI722vCig4WDmQF17xssY/PRygZFwmio+jSQWo9DId kqJ0Hf5Q6kUSRWuJghA4L7eglgbssJp4IOIlWwAiuvokj+aLdA/8BJZqXkb/+ERGIS6E 3EXxXHKpgIkBt2FSJ3JodU5LqDIh7p4u4jWfOfQpzrM2nSjRAqr1B8UAU+EbJUG9V/0H NkYT2x5W6MWKJU0a+c5WKTxoZh1PcODjfowzaPmok/aPuZp/p9XqV6KV9y++x6+F3RBx EZWv3iUHocdhILV90r8iCXwwq+sCkuznSEuJ4LOlkP3Mdmdn1UFtjwj0gs11XpwyF4Ka 6/mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769097531; x=1769702331; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8K/rAlcKVeT/EVpgXAT2xI8jG/2oag+MCKdQk5/VHMw=; b=ZVHtrAvLqfm21G/z5Wj5661GJ/NAR04Sp3WPmW4vgprsdbPyI1cOhCOrj7MgYMcCJY Tcuw81HuJU3TEVhQ2qlXODj8yS9NNXe0zDOGXsuOvD0SduOfa6nzKbzzbNubI5hA+55B weHmrz7j2C/vfvCE+0YD8pQjX30Z5pd7iMUYlj4BQAD43m0Kd/qjRMyBeUISgeguTlQ9 b+ieq7TVK6bsIaseXxqz8zWdVpCHDm4sW1kMaQnZuMMZgIERO8nj5AuXt/zMh6S1KcJF /b3W5eNwOtR/vD1GjwVPou4p3nFlpOsIw+OQeOcHsDukpu+Oojp2YBdVdlLa2SL8lpE0 t9cg== X-Forwarded-Encrypted: i=1; AJvYcCXuZ4KVQmIrLFKtTsp6Efrr0PvxO9EeuhZW78yktvQLQOfRas5CSYSETIX94mEUsbvZtISI3i8z1/g=@lists.xenproject.org X-Gm-Message-State: AOJu0YzdFKL1zjWtuHDgYymKKBeyqc3InKmU2hY0RdLw33NdZzoqxXnE 464AEHhUX0dg95Z6ditvI5PewtTyXeojUw8yhaLbe3ByHMCdYDyBCiD7oq8ORk8/Yw== X-Gm-Gg: AZuq6aKl8TBwA8e+SAm72SotO2HbtKiuQcU2yTZvjVFfk2u5oDtIhUgswjQNlmi+DmQ U2d8rJHGm4LIglO0Ec6Cn9QEKwUNSXnPwqmvoo4keM7zqN2zdy+F5kDT5RVEvnotpxfWSbk7vV2 bdokjrvrz1XOULAjO9HHfqGNh+v+nre+6aZlkYarogt/dZF/MEa53TIzVOEjPlJJowSipVbqTln 9kRwYKC3Kaoje87UDHuLsdKuqnsvHSSMegpDY2/5EH3OqU2sPDO7simAzZBtOjN0gH3zxVpeyor r7C30LzsNY6ymGKkQss1eazK+jZL3f/b63QgZbQ7ctBrOLO/F+TKtxrC6PutKVKtwBQNyJi16Aa 9buIXOjcmyUklGRKyPJQJrATn2Y+EF/1ens2wL3Cv97F+nOApq0kaHvktxjiLjiLfTaZxJC1KYK +mFBlVzBWCajAoGJxWSxrQiNbSP2h4CioE1zHzRyTLGrmGDdoUL+YbS9pyH6R7Ui+WgXAxJ9/Nr 1o= X-Received: by 2002:a05:600c:528e:b0:47e:e78a:c833 with SMTP id 5b1f17b1804b1-4804c9cf320mr1190195e9.32.1769097531087; Thu, 22 Jan 2026 07:58:51 -0800 (PST) Message-ID: Date: Thu, 22 Jan 2026 16:58:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 21/22] x86/cpu: report SMX, TXT and SKINIT capabilities 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: <6fb0f217027fc323d3c23e94bb99bc56e06f9763.1748611041.git.sergii.dmytruk@3mdeb.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <6fb0f217027fc323d3c23e94bb99bc56e06f9763.1748611041.git.sergii.dmytruk@3mdeb.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.05.2025 15:18, Sergii Dmytruk wrote: > --- a/xen/arch/x86/cpu/amd.c > +++ b/xen/arch/x86/cpu/amd.c > @@ -688,6 +688,21 @@ void amd_log_freq(const struct cpuinfo_x86 *c) > #undef FREQ > } > > +void amd_log_skinit(const struct cpuinfo_x86 *c) > +{ > + /* > + * Run only on BSP and not during resume to report the capability only once. > + */ > + if ( system_state != SYS_STATE_resume && smp_processor_id() ) > + return; Comment and code look to not fit together. DYM if ( system_state == SYS_STATE_resume || smp_processor_id() ) return; ? > @@ -633,6 +634,49 @@ static void init_intel_perf(struct cpuinfo_x86 *c) > } > } > > +/* > + * Print out the SMX and TXT capabilties, so that dom0 can determine if the > + * system is DRTM-capable. > + */ > +static void intel_log_smx_txt(void) > +{ > + unsigned long cr4_val, getsec_caps; > + > + /* > + * Run only on BSP and not during resume to report the capability only once. > + */ > + if ( system_state != SYS_STATE_resume && smp_processor_id() ) > + return; Same here? > + printk("CPU: SMX capability "); > + if ( !test_bit(X86_FEATURE_SMX, &boot_cpu_data.x86_capability) ) > + { > + printk("not supported\n"); > + return; > + } > + printk("supported\n"); > + > + /* Can't run GETSEC without VMX and SMX */ > + if ( !test_bit(X86_FEATURE_VMX, &boot_cpu_data.x86_capability) ) > + return; > + > + cr4_val = read_cr4(); > + if ( !(cr4_val & X86_CR4_SMXE) ) > + write_cr4(cr4_val | X86_CR4_SMXE); > + > + asm volatile ("getsec\n" > + : "=a" (getsec_caps) > + : "a" (GETSEC_CAPABILITIES), "b" (0) :); > + > + if ( getsec_caps & GETSEC_CAP_TXT_CHIPSET ) > + printk("Chipset supports TXT\n"); > + else > + printk("Chipset does not support TXT\n"); > + > + if ( !(cr4_val & X86_CR4_SMXE) ) > + write_cr4(cr4_val & ~X86_CR4_SMXE); Move this ahead of the printk()s? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:22:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:22:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211298.1522818 (Exim 4.92) (envelope-from ) id 1vixSB-0002Vb-CU; Thu, 22 Jan 2026 16:22:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211298.1522818; Thu, 22 Jan 2026 16:22:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vixSB-0002VU-84; Thu, 22 Jan 2026 16:22:39 +0000 Received: by outflank-mailman (input) for mailman id 1211298; Thu, 22 Jan 2026 16:22:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vixS9-0002V9-M2 for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:22:37 +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 8fee6e51-f7ae-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 17:22:36 +0100 (CET) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-b871cfb49e6so174280166b.1 for ; Thu, 22 Jan 2026 08:22:36 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b884f07db73sm40271766b.23.2026.01.22.08.22.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 08:22:34 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8fee6e51-f7ae-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769098955; x=1769703755; 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=gT21tN79WcEssuBmR/ZOAcBk2DbZ2TjBGzC2/72cKMc=; b=h4NP6tpJ5joG4rLlxXzEOoUzuUNjDgSt6YVf7gSjKxQ1/x79nBKst9osIwIm7FbiN1 wuXhG/rJ85UQ4rH4kxSBcEqRq94otstPcgw6LTSI/g9zsW29WRCcvJp4ip9+Jfag3ecI 8aIeIfm1bl8L8opw7h+r0eebk5ZGrOPTmiFMzaNZc0z7471McUdBjguL9ExVgSRnIBuY pFBdzoAB9ZqYtShjJdlkuKNlGd7Jb4/dyJ/ugzkC8KH4WoKVCG+Ix9MC6rLMAiHWV1KD Lr5ZUwxN3hSOtnOFSzzQKv2kSB4f/033sj+36fVbtLbbtKnvjO/aVYoSprdzRUOM9jH/ OQYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769098955; x=1769703755; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gT21tN79WcEssuBmR/ZOAcBk2DbZ2TjBGzC2/72cKMc=; b=MO12j+dSyh8+WymJMapmkpNAYQF/w26CfkMEJq4ZZrf7GJ7vVNdyw3J5jDk9JnivxR HIH/2k9KVqK9Q7K4QywT/qGIN68jPN579DDkg2zPCNvO5yn8KxMtFCqUBuwrACeMjhhn L7Lg0Ds68LGfy+ey7D3xtAzgy0tGmGAyHtIotcIz/vpbG4dHnGL0t7OZu9Zeu7pyIjN6 egJR4ikSbNn1x30bYxyrkg34c0/3YG0ua0WgYHuj8P2U0rq9AS3LuHNKWpI+zrqr6C3C YMBYPvF0XCDxOCehXqJjplioi4W/+8JWR9XAYiTwUD15eujdgc8Z/S0fJhj0TV0A/xPF zngA== X-Forwarded-Encrypted: i=1; AJvYcCUYctOFF/ASWwYk35efe5gt1mCi6IiiLz+gooWc9j401YY+fTXsPVB9NHhXCL1lqJeRyqoRHVNjPOI=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx6WEsOvpQ/wELnrfr4RJ+quQcHrJ000ex0o5Ca0Cre4/cdhqqT AsTn+6STxzgHJkwNg1WNFv6avXllh7dvGn6GoyEVJgYZh3GDWZL0UQ0eSPlNRg== X-Gm-Gg: AZuq6aJxVx7ivFlHPTV/DsAsAVvmrQuroU+WOMenmvTTYy20+s4AbmEtQHeGJA+ncU/ yp2Na1VJqRIv61ed1QyZve1kpUcSldyGe3rYqlgvPhd4B1uf+2VlIm0vY2ywCngWTKK0HCFY0uT A1+7ePIeRniDVi6rDRQwjroIpvKXJ3eT/m6t3VUmbw4zRVSiR2OMWpe4mMcqEwLqukmmwC0kSWk hZmzUUNY/DJ6iOZCai6lwSAv3TVJS+4PylSfxSDeljEOu1UMXDLJsDvubpVjZWzPeJlMgxMVbCV S3LayBhcdr8CV9PKEaYcopt4QPMH7iOEZ4GtfbJY8mLnKcQDCsNNvRVEmsNrPH066GvXDqMCsKL HMOS7IA5JnhPB+mXbfklrWiU1NNhR9D59V/tweh8DhWeL7GwToJjjR/BUVNlgbXdFEZ4lD8Azhd j2winJWTmpaP3Lrrk/Hl3jXWjfaRRQu7mtQnguJ21JGwjFoxIEnZIgelvG2V43jm8= X-Received: by 2002:a17:907:d8a:b0:b77:1d75:8b78 with SMTP id a640c23a62f3a-b8796b9dc30mr1825226766b.53.1769098955256; Thu, 22 Jan 2026 08:22:35 -0800 (PST) Message-ID: Date: Thu, 22 Jan 2026 17:22:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] kconfig: adjust NR_CPUS defaults 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: <1caed635-3d9b-47ed-b8fb-d6c391293059@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1caed635-3d9b-47ed-b8fb-d6c391293059@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/14/26 12:33 PM, Jan Beulich wrote: > Discussion of a RISC-V change revealed that for PPC and RISC-V we don't > really set any default, but rather rely on internals of kconfig picking > the lowest of the permitted values in such a case. Let's make this > explicit, requiring architectures that mean to permit SMP by default to > explicitly record some sensible value here. > > Leverage the adjustment to the "1" case to simplify all subsequent ones. > > Signed-off-by: Jan Beulich LGTM: Reviewed-by: Oleksii Kurochko Now I have to drop the same patch from my list. Likely I checked my e-mail before sending it. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:24:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:24:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211313.1522856 (Exim 4.92) (envelope-from ) id 1vixU1-0003IB-Ty; Thu, 22 Jan 2026 16:24:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211313.1522856; Thu, 22 Jan 2026 16:24:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vixU1-0003I4-RA; Thu, 22 Jan 2026 16:24:33 +0000 Received: by outflank-mailman (input) for mailman id 1211313; Thu, 22 Jan 2026 16:24:32 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vixU0-0003Hw-IY for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:24:32 +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 d36cf289-f7ae-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 17:24:30 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-b884ad1026cso95786166b.2 for ; Thu, 22 Jan 2026 08:24:29 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b879bd278fdsm1669246266b.28.2026.01.22.08.24.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 08:24:28 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d36cf289-f7ae-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769099069; x=1769703869; 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=HXhTFmWrWJsM7q4e6xgXiqRMeFzIExHfk5wiecob6a8=; b=MYeeYPj1A6qQJi18Sq0eYhZvAPMM5kqgrsc2Q6XaxbgvfnsKX8NhLjk21GIKwGN1/r Ild1cHA5fDf6bgaK7DT+P8JVNq/STgOQt2i39sX1xonKXDEbJeMIWtFcXbmkdtwLzK2n QiZvR+dqP0BeelTYc3aose29c0c1Qu94GY5WkkFfevI3BWwlcQdL/ywb/s5zN2S91fKg oHRsyLdTc1ELztIb8DXI0QyTyJbkikrvG9gB15S6J6i82e/CixtVzyfnbAwjURuiSbJp VJ7Oq4Fq/PpmxIaJFO9oSjceTSpFV4JE3FlPEn/7xyIsYJd5qDOKJpGG1P0Kfwyh+0Ys hpzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769099069; x=1769703869; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HXhTFmWrWJsM7q4e6xgXiqRMeFzIExHfk5wiecob6a8=; b=oMkWw0+/ric851dLx2ibQYZvL2U5T+DyTfbE1rZa2hdQkdN+keVcr8lxuaSsMRgFgZ +YOvij52+gpdNJcvCykPQCgLcZ+TA00BPu0FoH+OTCRtXPghtJdhjAr3+q91aCV4+h2l N/2O/0/Zy+uzYSCohgv3uwyKaSqcCmGfS6L521lR9Dsyt7/HBtFKhtekFTCDzpruxVZD 6jAiJ30U/NMesRGbn8CHY9SnS6Ocs/q+LFo09Ga7uasDj3Eb0W6R+ml8ZToTz+EGbTEz ccHzBYWa5naQFaxnBqsdn68zGfRkeM44rN9phzFcv9p8pESGXKBCqncgv5TWPI5Prfnm WGqQ== X-Forwarded-Encrypted: i=1; AJvYcCWXm/2gjBf2EeiFyJ1J6IANebXWSFChzz2vaOflZIgNLVI0VYUztDvXvPK97I5vGwrAqnPimpcYaqE=@lists.xenproject.org X-Gm-Message-State: AOJu0YzX894md4u/GVBMSjiYpyzXz0XcTtFOGRXgDWZB4OkIS9gzYECr WagJiEz+DLTwvPeAfaEJDgRiDOBchqjDtNt9aUO0eatXII8L3uw7YeC5gc/WSw== X-Gm-Gg: AZuq6aILnEk8RgQmtz844RCEtDPSNQUttaJMaMR8ZzsC5saz9sjkfxo6zimCElnJe9/ xn6kOZtidF26CjWQ/xxugYlkaXcf+fg77ugFs8L0+GVwd12Lw5FdWfqzWii0NWYx4tUA/sSH3Jf yXNh+bi3IeSqWqnhSvPrsQBBhmNEoZ5UQYFpuHfg9oOieyhQJtogcf3r9A7sII96trBRjIyjq3f C/YjQrik27O8W9t5jBWpIzdwCvTagd9td5B7j18GyDCYv+yrpRGtmbBdTQM4KuIAt9Q5o/ckXG2 vWu2+b1bvMnk2SDzdReu0MtodGFbi+nlsakf1rYgjZx6Y6RQB+jKbxXcBDYPDBxMzd1gml3pN/a xTPVdD4/xDgRtQuOG80tJM8FE/6O8zCj1Dw1Q+I+e378P4/gDkmCB6xiAoRHZGteRAbc/q6TuFj 6A58sM2VHFr8BbHXszLjpbEeN6F5hwxeRgU2XM3NGx7sZaL0b3vbWVAuuBi/D/Q1pGLsQFpet8P A== X-Received: by 2002:a17:907:a4e:b0:b87:778b:89ba with SMTP id a640c23a62f3a-b8800652889mr776595766b.39.1769099068425; Thu, 22 Jan 2026 08:24:28 -0800 (PST) Message-ID: <21a22ddf-cde9-46b2-ad05-f88b62bf8ebe@gmail.com> Date: Thu, 22 Jan 2026 17:24:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/intel: Drop more cpuid_mask_* infrastructure To: Andrew Cooper , Jan Beulich Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260119193901.1354905-1-andrew.cooper3@citrix.com> <14a32e1f-c5ca-4d1c-b54b-c565184bd6e7@suse.com> <5e57b6b9-6fe4-49a5-bba0-fdf9e48bbb99@citrix.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <5e57b6b9-6fe4-49a5-bba0-fdf9e48bbb99@citrix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/20/26 2:56 PM, Andrew Cooper wrote: > On 20/01/2026 7:50 am, Jan Beulich wrote: >> On 19.01.2026 20:39, Andrew Cooper wrote: >>> Despite removing references from the documentation, the Intel parts of CPUID >>> Masking were accidentally left behind and still active. >>> >>> Intel CPUID Masking is even more niche than AMD masking, as the MSRs only >>> exist between Nehalem and SandyBridge, > Turns out it was Core2, not Nehalem. > >>> being fully replaced with CPUID >>> Faulting from IvyBridge onwards. >>> >>> Fixes: 317051c2f032 ("x86/amd: Drop the cpuid_mask_* command line options") >>> Signed-off-by: Andrew Cooper >> Acked-by: Jan Beulich > Thanks. > >> Yet I think you also want to edit the CHANGELOG.md entry the other commit put >> in place, to not have that remain AMD-only? > Good point.  I can fold in this minor adjustment: > > diff --git a/CHANGELOG.md b/CHANGELOG.md > index 7de34f64d1e6..53d92a259731 100644 > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -12,9 +12,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) > >  ### Removed >   - On x86: > -   - The cpuid_mask_* command line options for legacy AMD CPUs.  These were > +   - The cpuid_mask_* command line options for legacy CPUs.  These were >       deprecated in Xen 4.7 and noted not to work correctly with AMD CPUs from > -     2011 onwards. > +     2011 onwards, nor work at all with Intel CPUs from 2012. >     - Xenoprofile support.  Oprofile themselves removed support for Xen in 2014 >       prior to the version 1.0 release, and there has been no development since >       before then in Xen. > > > which covers things suitably. LGTM: Acked-by: Oleksii Kurochko Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:41:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:41:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211332.1522866 (Exim 4.92) (envelope-from ) id 1vixkH-0006ad-7l; Thu, 22 Jan 2026 16:41:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211332.1522866; Thu, 22 Jan 2026 16:41:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vixkH-0006aW-4i; Thu, 22 Jan 2026 16:41:21 +0000 Received: by outflank-mailman (input) for mailman id 1211332; Thu, 22 Jan 2026 16:41: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 1vixkG-0006aP-5S for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:41:20 +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 29ccbf42-f7b1-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 17:41:13 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-47ee2715254so6691285e9.3 for ; Thu, 22 Jan 2026 08:41:13 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804ce3274csm506665e9.0.2026.01.22.08.41.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 08:41:12 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 29ccbf42-f7b1-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769100073; x=1769704873; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=fXdUIoK+UHr9m/hbfvjoIUCGRpiigaqs5cY9PvbeFq8=; b=TMOfgNlGORiPLV7HgIfO3O1GozQ6ht9X4RoGc01e0tuBSucIPazDEvrvf6bmCI6s1H 3B+MM8/Rj/hBVnS6QEZaIc+rXBgCVMcXgQBk2hmEiXGKD3SnPyEL2dCoklC9vIk7PVN2 /dtxyqYMh028W7IVhU1RXddXDe/b0Y6mYzuTfW4BwYqLMlHMauvOKgJecFRAh6k1+qje OTN71QxvYgfcrnhlbrwnrpY3qYm4xXIVMCwtpt0kYq83wl9MaH2o9Qh2S69czsop0ZXn KrQF362VJ1sH3rIuVNc+tTraeAnc/NBWol7L9/WfnzX3ZXHbzGPRZJfENiWV/0mRbMh5 g3NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769100073; x=1769704873; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=fXdUIoK+UHr9m/hbfvjoIUCGRpiigaqs5cY9PvbeFq8=; b=DZnLYvNV8tcGCZ3PRUGrmV2+dL9qXud2BXFK3edfPiCo7qU5NHPr1KQ/tcBh6U7xav LcbLQR8vysCWMzI0XlTBqfzqyQ8i63aByh3SloF5TI4IGm22bBPzYJkfxKXVOdXGIyae G1dTlywLKooZYEvp/NxS0Uprnzs2hTEiTA8HyKP81xNKqbdQkkmhdvE0evtqEQy3Ph2w hn1awwkf20hSVmSD3sk37H+KAhzVAENjaHhhmP2FtNBEoKZ4Q/kJ1t1AGk3XBnhyp8/R eUNBvl5m4O4i1yJrG8NBPuZgDjxVcR7Ho0/PtkTMTwqSEbOuWKdHISdcdrbbt8fmI6el Qxvg== X-Forwarded-Encrypted: i=1; AJvYcCXJFDSMaNqFaRYCE92EEEr9GV0WYYROUMULggXhwDlX4rfxcuSm4JRsqaOtfVuo9vzF9MY4VUpYrRY=@lists.xenproject.org X-Gm-Message-State: AOJu0YyRC9lELUzmhLwfd67SfAyuY9tPPU6SO6TknjNoZgWh75104up2 KQPWX05IWifurO79g9MDomFQHsb5ZeQto4Ykryy0/iBupUAXTw/kf0XtCHC/c7YQnw== X-Gm-Gg: AZuq6aITDAYPTxG6kIXCU1MSfSAmyl5gHWlsQWIM+uVpbxytvqsjNFpdZwxxxQpSaPX 9FyBBytj33xm8wpIaHh5G+CF803iEhkfr0XO3XM1RmTF9bA2RqH3ZspxTgSXPFRdNzBQYPWq7EB Fj1vaqU+moAJdQXrKtQmBL1m2teyFvgkO7Du9saVnLtbYXK9v0r8q4s+yOZaoUAtd3F+WR6ETo2 FdRVcLQ9wvtKIMrOytDW6OS36mDmHdVPlVDh1aMWJM7sOBPmep00h4lkftyM8OrkFc9bG47aRCR tb00xicZkBEThRVix9z8vUv5GHxYCcXbb0Q7D4twtxRCAXdcdZfjlhs2jQ8LEFpRqrD8XrJP2Tn cYcR6OLMx0eEA8DOgxoXnE04Kc6hJwoaPLz9gB6wUxfSir/Ov8C85d8NC4SGAxOPAjJJ69WwbOf FZWCSD8QuBkkSAjkrRhwT29dva59i3IyACPzaSUSjbLQ7QOChP+LGug4IkUFSAgDRPHobqqMUle 0g= X-Received: by 2002:a05:600c:3e10:b0:477:9814:6882 with SMTP id 5b1f17b1804b1-4804c947a33mr3966605e9.5.1769100072666; Thu, 22 Jan 2026 08:41:12 -0800 (PST) Message-ID: Date: Thu, 22 Jan 2026 17:41:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 15/22] x86/smpboot.c: TXT AP bringup 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: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+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.05.2025 15:17, Sergii Dmytruk wrote: > @@ -154,6 +164,13 @@ gdt_48: > .quad 0x00cf93000000ffff /* 0x0018: ring 0 data */ > .quad 0x00009b000000ffff /* 0x0020: real-mode code @ BOOT_TRAMPOLINE */ > .quad 0x000093000000ffff /* 0x0028: real-mode data @ BOOT_TRAMPOLINE */ > + /* > + * Intel TXT requires these two in exact order. This isn't compatible > + * with order required by syscall, so we have duplicated entries... > + * If order ever changes, update selector numbers in asm/intel-txt.h. > + */ > + .quad 0x00cf9b000000ffff /* 0x0030: ring 0 code, 32-bit mode */ > + .quad 0x00cf93000000ffff /* 0x0038: ring 0 data */ Especially since the corresponding #define-s sit ... > --- a/xen/arch/x86/include/asm/intel-txt.h > +++ b/xen/arch/x86/include/asm/intel-txt.h > @@ -91,6 +91,9 @@ > > #define SLAUNCH_BOOTLOADER_MAGIC 0x4c534254 > > +#define TXT_AP_BOOT_CS 0x0030 > +#define TXT_AP_BOOT_DS 0x0038 ... entirely elsewhere, I think at least the comments above want to mention these names. (Even better would be to not hard-code these numbers, or to use the numbers to establish the offsets in trampoline_gdt.) > @@ -321,6 +323,29 @@ void asmlinkage start_secondary(void) > struct cpu_info *info = get_cpu_info(); > unsigned int cpu = smp_processor_id(); > > + if ( ap_boot_method == AP_BOOT_TXT ) { Style nit (also again later): Brace on its own line please. > + uint64_t misc_enable; > + uint32_t my_apicid; > + struct txt_sinit_mle_data *sinit_mle = > + txt_sinit_mle_data_start(__va(txt_read(TXTCR_HEAP_BASE))); > + > + /* TXT released us with MONITOR disabled in IA32_MISC_ENABLE. */ > + rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable); > + wrmsrl(MSR_IA32_MISC_ENABLE, > + misc_enable | MSR_IA32_MISC_ENABLE_MONITOR_ENABLE); > + > + /* get_apic_id() reads from x2APIC if it thinks it is enabled. */ > + x2apic_ap_setup(); > + my_apicid = get_apic_id(); Despite the comment putting the call to x2apic_ap_setup() here looks rather arbitrary. Also you do nothing about the other call from smp_callin(). Surely the function better wouldn't be called twice? > + while ( my_apicid != x86_cpu_to_apicid[cpu] ) { > + asm volatile ("monitor; xor %0,%0; mwait" > + :: "a"(__va(sinit_mle->rlp_wakeup_addr)), "c"(0), You alter %0, so it can't be just an input. > + "d"(0) : "memory"); > + cpu = smp_processor_id(); What purpose does this serve? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:47:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:47:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211345.1522886 (Exim 4.92) (envelope-from ) id 1vixqV-0007WK-3Q; Thu, 22 Jan 2026 16:47:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211345.1522886; Thu, 22 Jan 2026 16:47:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vixqU-0007W9-Vv; Thu, 22 Jan 2026 16:47:46 +0000 Received: by outflank-mailman (input) for mailman id 1211345; Thu, 22 Jan 2026 16:47:45 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vixqT-0007Id-Ct for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:47:45 +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 12e17298-f7b2-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 17:47:44 +0100 (CET) Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-6505d3b84bcso1589974a12.3 for ; Thu, 22 Jan 2026 08:47:44 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b879513e951sm1686014966b.7.2026.01.22.08.47.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 08:47:42 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 12e17298-f7b2-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769100463; x=1769705263; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=6yeF8Jc7Y0UzeLgMob1T0cLJ1Uc8AiT2zOW9g8mOyGs=; b=dzhzdsGsNLUKHpBU1UeScuv5wScuBRKU41tApu0ec6Ko407QhGrku7BMwOcOTMVW82 mou3M9EPJIJchXivtYowS/iQA0+2HlsJ2JnNlfwEpPybLDHJimQy35bNdcVwCBBqiI+y lfEm7oonjgtr+cF96EG5QAR1KJlSAo9dcFyBpH2347BKpJuSv4UUGUOg7oFwFRB1jOYd b3U9XSuTCsXKfc7sgq3jUVDFGE2UNAjysRFU4m/na5rLyL8Fs7/ArE9OoeKEwTmmozCu 1Tr4PSIaYVbeDQWGs1kCx1hUc4seq4hkiTBFtYUHwpFtRzO7nuf+D0otCDNwWUsytFrN VZeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769100463; x=1769705263; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=6yeF8Jc7Y0UzeLgMob1T0cLJ1Uc8AiT2zOW9g8mOyGs=; b=WY5fya9N7r/5XHy2AFxGHWjmncvj0nPZvhiqZL9HVjxHnQLof7k/2r53ZtnpQj9XOp 8GmPieC7dvMXkNqXDB/UM8fe2Kjzs6YxCrBNTTqsBjV9OJLJiPsxPChDSOFwibMrghFS 9Ki7wyimUpBdv1vvOJoBHWcIJ/CEArtsoWURWKGcrUYywhocSxXvlUrzLl7vedHlx/Hr xX4OWcY9WeOnBbpx78bxYvJgleydJFRLT/naZrKWKDjsh96RWMeplOMZc3tZvajQtkVW 3e3LrA4nXh8vw9BMm5O8jPntFmBbRK4Zi8yI+fRGbShLoPmsspKFlYS1qNgJ6Tg49jV+ svlA== X-Gm-Message-State: AOJu0YzYDl3k7LDpSrPNcGSF23TMZzKJOWknRlbJGlPWcK51wMfMsSXa LojmIOdLGNIqwjsEoDsdDr7FQAy+DSr+kWrtNz4cX5xQFBSSPQIn7lY4tuSTvA== X-Gm-Gg: AZuq6aJsIpbUBvfNeU0MUKKCtKBd093hpPJdUJCrL/zbpiGQZ/J0lLpgSDwbERmVXns sJkwO9UjWzY0vzh5ozRo5hkA3p+DmgNRwCws1RYUgSkUwcAec7sn15ULbr6/u5t8Q1dgYTHc0bj XdckiET5x34xgu8Jz8n3s9yBmTwIfUPyUpRxweftoAaYm7PvTLG/AI8ZCJ5LdJheGdWFQufDaAV eyOU2C1eMSYqK6k8ibYuzXZv2FvCeI1CgU0sfIUs/m7pustwOymx4mHClKPOXWAhtERawDGABTr 5ZGfQtBXwb+d1m8MntvQL8nnahpnoTx4Hv3ujCY+T1MAoumwQjTu825i+s5beOSXfn88CLESk/t GXUJmQoaRNSAf4ipJZemOUDPVF5rb3ucBS/Q+nSFQSBFjn1V6N/IyKiSJRCG5CcFFdpkGq9T0AZ RCXYz3Ve0Genk2iLW8eQnkSIe86BVDSCG8YYC0lSJ4+ptVypq4uEZ1Xw== X-Received: by 2002:a17:907:1ca9:b0:b87:35fc:ae5f with SMTP id a640c23a62f3a-b87930381c7mr2000586266b.52.1769100463285; Thu, 22 Jan 2026 08:47:43 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Romain Caritey Subject: [PATCH v2 03/16] xen/riscv: implement vcpu_csr_init() Date: Thu, 22 Jan 2026 17:47:18 +0100 Message-ID: <57ef3bcff854d4b50641641d300b3e8aa715c3c3.1769099885.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Introduce vcpu_csr_init() to set up the initial hypervisor-visible CSR state for a vCPU before it is first scheduled. The function configures trap and interrupt delegation to VS-mode by setting the appropriate bits in the hedeleg and hideleg registers, initializes hstatus so that execution enters VS-mode when control is passed to the guest, and restricts guest access to hardware performance counters by initializing hcounteren, as unrestricted access would require additional handling in Xen. When the Smstateen and SSAIA extensions are available, access to AIA CSRs and IMSIC guest interrupt files is enabled by setting the corresponding bits in hstateen0, avoiding unnecessary traps into Xen (note that SVSLCT(Supervisor Virtual Select) name is used intead of CSRIND as OpenSBI uses such name and riscv_encoding.h is mostly based on it). If the Svpbmt extension is supported, the PBMTE bit is set in henvcfg to allow its use for VS-stage address translation. Guest access to the ENVCFG CSR is also enabled by setting ENVCFG bit in hstateen0, as a guest may need to control certain characteristics of the U-mode (VU-mode when V=1) execution environment. For CSRs that may contain read-only bits (e.g. hedeleg, hideleg, hstateen0), the written value is re-read from hardware and cached in vcpu->arch to avoid divergence between the software state and the actual CSR contents. As hstatus is not part of struct arch_vcpu (it already resides in struct cpu_user_regs), introduce vcpu_guest_cpu_user_regs() to provide a uniform way to access hstatus and other guest CPU user registers. This establishes a consistent and well-defined initial CSR state for vCPUs prior to their first context switch. Signed-off-by: Oleksii Kurochko --- Changes in v2: - As hstatus isn't a part of arch_vcpu structure (as it is already a part of cpu_user_regs) introduce vcpu_guest_cpu_user_regs() to be able to access hstatus and other CPU user regs. - Sort hideleg bit setting by value. Drop a stray blank. - Drop | when the first initialization of hcounteren and hennvcfg happen. - Introduce HEDELEG_DEFAULT. Sort set bits by value and use BIT() macros instead of open-coding it. - Apply pattern csr_write() -> csr_read() for hedeleg and hideleg instead of direct bit setting in v->arch.h{i,e}deleg as it could be that for some reason some bits of hedeleg and hideleg are r/o. The similar patter is used for hstateen0 as some of the bits could be r/o. - Add check that SSAIA is avaialable before setting of SMSTATEEN0_AIA | SMSTATEEN0_IMSIC | SMSTATEEN0_SVSLCT bits. - Drop local variables hstatus, hideleg and hedeleg as they aren't used anymore. --- xen/arch/riscv/cpufeature.c | 1 + xen/arch/riscv/domain.c | 73 +++++++++++++++++++++ xen/arch/riscv/include/asm/cpufeature.h | 1 + xen/arch/riscv/include/asm/current.h | 2 + xen/arch/riscv/include/asm/riscv_encoding.h | 2 + 5 files changed, 79 insertions(+) diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c index 02b68aeaa49f..03e27b037be0 100644 --- a/xen/arch/riscv/cpufeature.c +++ b/xen/arch/riscv/cpufeature.c @@ -137,6 +137,7 @@ const struct riscv_isa_ext_data __initconst riscv_isa_ext[] = { RISCV_ISA_EXT_DATA(zbb), RISCV_ISA_EXT_DATA(zbs), RISCV_ISA_EXT_DATA(smaia), + RISCV_ISA_EXT_DATA(smstateen), RISCV_ISA_EXT_DATA(ssaia), RISCV_ISA_EXT_DATA(svade), RISCV_ISA_EXT_DATA(svpbmt), diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 9c546267881b..3ae5fa3a8805 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -5,6 +5,77 @@ #include #include +#include +#include +#include + +#define HEDELEG_DEFAULT (BIT(CAUSE_MISALIGNED_FETCH, U) | \ + BIT(CAUSE_FETCH_ACCESS, U) | \ + BIT(CAUSE_ILLEGAL_INSTRUCTION, U) | \ + BIT(CAUSE_BREAKPOINT, U) | \ + BIT(CAUSE_MISALIGNED_LOAD, U) | \ + BIT(CAUSE_LOAD_ACCESS, U) | \ + BIT(CAUSE_MISALIGNED_STORE, U) | \ + BIT(CAUSE_STORE_ACCESS, U) | \ + BIT(CAUSE_USER_ECALL, U) | \ + BIT(CAUSE_FETCH_PAGE_FAULT, U) | \ + BIT(CAUSE_LOAD_PAGE_FAULT, U) | \ + BIT(CAUSE_STORE_PAGE_FAULT, U)) + +#define HIDELEG_DEFAULT (MIP_VSSIP | MIP_VSTIP | MIP_VSEIP) + +static void vcpu_csr_init(struct vcpu *v) +{ + register_t hstateen0; + + csr_write(CSR_HEDELEG, HEDELEG_DEFAULT); + v->arch.hedeleg = csr_read(CSR_HEDELEG); + + vcpu_guest_cpu_user_regs(v)->hstatus = HSTATUS_SPV | HSTATUS_SPVP; + + csr_write(CSR_HIDELEG, HIDELEG_DEFAULT); + v->arch.hideleg = csr_read(CSR_HIDELEG); + + /* + * VS should access only the time counter directly. + * Everything else should trap. + */ + v->arch.hcounteren = HCOUNTEREN_TM; + + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) ) + { + csr_write(CSR_HENVCFG, ENVCFG_PBMTE); + v->arch.henvcfg = csr_read(CSR_HENVCFG); + } + + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) + { + if (riscv_isa_extension_available(NULL, RISCV_ISA_EXT_ssaia)) + /* + * If the hypervisor extension is implemented, the same three + * bitsare defined also in hypervisor CSR hstateen0 but concern + * only the state potentially accessible to a virtual machine + * executing in privilege modes VS and VU: + * bit 60 CSRs siselect and sireg (really vsiselect and + * vsireg) + * bit 59 CSRs siph and sieh (RV32 only) and stopi (really + * vsiph, vsieh, and vstopi) + * bit 58 all state of IMSIC guest interrupt files, including + * CSR stopei (really vstopei) + * If one of these bits is zero in hstateen0, and the same bit is + * one in mstateen0, then an attempt to access the corresponding + * state from VS or VU-mode raises a virtual instruction exception. + */ + hstateen0 = SMSTATEEN0_AIA | SMSTATEEN0_IMSIC | SMSTATEEN0_SVSLCT; + + /* Allow guest to access CSR_ENVCFG */ + hstateen0 |= SMSTATEEN0_HSENVCFG; + + csr_write(CSR_HSTATEEN0, hstateen0); + v->arch.hstateen0 = csr_read(CSR_HSTATEEN0); + } +} + static void continue_new_vcpu(struct vcpu *prev) { BUG_ON("unimplemented\n"); @@ -33,6 +104,8 @@ int arch_vcpu_create(struct vcpu *v) v->arch.xen_saved_context.sp = (register_t)v->arch.cpu_info; v->arch.xen_saved_context.ra = (register_t)continue_new_vcpu; + vcpu_csr_init(v); + /* Idle VCPUs don't need the rest of this setup */ if ( is_idle_vcpu(v) ) return rc; diff --git a/xen/arch/riscv/include/asm/cpufeature.h b/xen/arch/riscv/include/asm/cpufeature.h index b69616038888..ef02a3e26d2c 100644 --- a/xen/arch/riscv/include/asm/cpufeature.h +++ b/xen/arch/riscv/include/asm/cpufeature.h @@ -36,6 +36,7 @@ enum riscv_isa_ext_id { RISCV_ISA_EXT_zbb, RISCV_ISA_EXT_zbs, RISCV_ISA_EXT_smaia, + RISCV_ISA_EXT_smstateen, RISCV_ISA_EXT_ssaia, RISCV_ISA_EXT_svade, RISCV_ISA_EXT_svpbmt, diff --git a/xen/arch/riscv/include/asm/current.h b/xen/arch/riscv/include/asm/current.h index 58c9f1506b7c..5fbee8182caa 100644 --- a/xen/arch/riscv/include/asm/current.h +++ b/xen/arch/riscv/include/asm/current.h @@ -48,6 +48,8 @@ DECLARE_PER_CPU(struct vcpu *, curr_vcpu); #define get_cpu_current(cpu) per_cpu(curr_vcpu, cpu) #define guest_cpu_user_regs() ({ BUG_ON("unimplemented"); NULL; }) +#define vcpu_guest_cpu_user_regs(vcpu) \ + (&(vcpu)->arch.cpu_info->guest_cpu_user_regs) #define switch_stack_and_jump(stack, fn) do { \ asm volatile ( \ diff --git a/xen/arch/riscv/include/asm/riscv_encoding.h b/xen/arch/riscv/include/asm/riscv_encoding.h index 1f7e612366f8..dd15731a86fa 100644 --- a/xen/arch/riscv/include/asm/riscv_encoding.h +++ b/xen/arch/riscv/include/asm/riscv_encoding.h @@ -228,6 +228,8 @@ #define ENVCFG_CBIE_INV _UL(0x3) #define ENVCFG_FIOM _UL(0x1) +#define HCOUNTEREN_TM BIT(1, U) + /* ===== User-level CSRs ===== */ /* User Trap Setup (N-extension) */ -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:47:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:47:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211344.1522875 (Exim 4.92) (envelope-from ) id 1vixqT-0007J1-S5; Thu, 22 Jan 2026 16:47:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211344.1522875; Thu, 22 Jan 2026 16:47: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 1vixqT-0007Iu-PX; Thu, 22 Jan 2026 16:47:45 +0000 Received: by outflank-mailman (input) for mailman id 1211344; Thu, 22 Jan 2026 16:47:45 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vixqT-0007Id-21 for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:47:45 +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 1194e987-f7b2-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 17:47:42 +0100 (CET) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-b87003e998bso401411466b.1 for ; Thu, 22 Jan 2026 08:47:42 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b879513e951sm1686014966b.7.2026.01.22.08.47.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 08:47:40 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1194e987-f7b2-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769100461; x=1769705261; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=tIURivnVVNz+Sg90MgEK4c9c+A2jqXCTv9hUdU686As=; b=WQhqzsRpWji3kJNWGbP3Rhp1SgAbH4gHXfNhHHofUvRtZPvI1zdSXBroVAFNq8W31Q PxQ/irR7Yy24poddgqj2VeWl0nZ/HKLHhGfMj+WHP1vII7bxHLfnP9kVnb49KweLLDas COIz+i15MNruyRkiyFmE5WAfPyXozxPFZle9tFH0SkOMi1GfHaDAp5IP/MWPaOHoNTAD Wf6ZtwDWck9yy0n4vJtxDsYNd7elaQ1XHeMPb6KoOH7MoJrrrnVX2PfQ6K7BbD824Omy uOUFc3Xw3RTfsXI5/Hx17VE812u1NxhWzSFlPJDfRwS6nZ/TXnIDmWrY9wOWa3L66OUZ xwDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769100461; x=1769705261; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=tIURivnVVNz+Sg90MgEK4c9c+A2jqXCTv9hUdU686As=; b=sx9m6J93ggmO7CMyfMJTb4zoCAFN0EYOsZwioqY7wX6xKT8E5kLFRlO/GLNgmJ0lf8 mkPWHn11bpki6iD0hlOHzL4MLDCjy9+6a51RxmlmZdkWMs7ixuNmcu1cOQVIhJWOBV2c Ng+SB1Hud+r17Xm7/NBgFaN7VTzUHcFA/aLI2PMmX+P6T5oX360SjcHGSkXM1Lu3qJCa ZGDdDSznLGQ2iU2OzSQn+B+4hHmunptejn4jkG5sHAwWVWVn97z67utwWYyhOBxyfCXS CDh9UGFkUCQ6hv5cW+MqOIXA0Bf8hKijSHflZs/UgcU5NXRuJvZRj5/HBkB6uWd9Ae/p FFWw== X-Gm-Message-State: AOJu0YwsAkESGxsS/KjenWwCHM0bZYskbGN7FKNhA3PY/rKZxS8rHlIE L4mYrVcPpR1VvQWq4f+wAzJAluXdB5+tmmgtGTLis/0gsgCT7Dgh9Cd1lmui2g== X-Gm-Gg: AZuq6aI6rbwsaQiXB3mJipuJPCvLKPXjnxUXcXXwzESIvGOb5lLQ+nFXAEYcTzpe8bT E+MSQYd0niVilNgLzeTLdgJmQ2PD6HuinHOsS53iRYuVSPJ9bZjvPjKJGVJRUgGfeC4eUts9hEQ n9doz0s37Bw/dB0nO0c10tzt65oUCzbTw99GzCmf4fJcpawfERU9yu+QU9C1/8CMEdS5itCeoGO rATDzSf8xhmn4nr/7J1u1if1DsGIZQfkE4Iugb0FVDrfTMnQqZSCfLVrLFyuO36sRGXeAlqnHxZ r2WyvIN8t+TrCryIiFZDtBGUHMW+WuVbV7KeYu5KG/NczfqF6PShV8eVkiFwIMSZ62XwOYhuL6z gzrGeHpkaHZUvF6kT1atGNWDAP+QPwPi/2W929+jnwPhjGhozSSpjNiqJOHuwvlJ/aVYshkiM/H zOE5Aqm7BXn2Q6PvGqDaQUleWq5mFF4cA2VQgaVFCniH+2Ja98HZ/h9A== X-Received: by 2002:a17:907:7251:b0:b79:eba9:83b4 with SMTP id a640c23a62f3a-b885a262ce4mr3468666b.6.1769100461100; Thu, 22 Jan 2026 08:47:41 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Romain Caritey Subject: [PATCH v2 01/16] xen/riscv: introduce struct arch_vcpu Date: Thu, 22 Jan 2026 17:47:16 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Introdce struct arch_vcpu to hold RISC-V vCPU-specific state. The structure contains: - Guest-visible CSR state, used to save and restore vCPU execution state across context switches. hstatus isn't added here as it is already part of cpu_user_regs struct. - Callee-saved registers used to preserve Xen’s own execution context when switching between vCPU stacks. It is going to be used in the following way (pseudocode): context_switch(prev_vcpu, next_vcpu): ... /* Switch from previous stack to the next stack. */ __context_switch(prev_vcpu, next_vcpu); ... schedule_tail(prev_vcpu): Save and restore vCPU's CSRs. The Xen-saved context allows __context_switch() to switch execution from the previous vCPU’s stack to the next vCPU’s stack and later resume execution on the original stack when switching back. During vCPU creation, the Xen-saved context is going to be initialized with: - SP pointing to the newly allocated vCPU stack - RA pointing to a helper that performs final vCPU setup before transferring control to the guest After the first execution of __context_switch(), RA naturally points to the instruction following the call site, and the remaining callee-saved registers contain the Xen register state at the time of the switch. Signed-off-by: Oleksii Kurochko --- Changes in v2: - Drop hstatus from struct arch_vcpu as it is stored in struct cpu_user_regs which will be stored on top of vCPU's stack. - Drop the comment above ra in xen_saved_context struct as it is potentially misleading. --- xen/arch/riscv/include/asm/domain.h | 57 ++++++++++++++++++++++++++++- 1 file changed, 55 insertions(+), 2 deletions(-) diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h index 316e7c6c8448..0d9b4c4b525e 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -22,9 +22,62 @@ struct hvm_domain struct arch_vcpu_io { }; -struct arch_vcpu { +struct arch_vcpu +{ struct vcpu_vmid vmid; -}; + + /* + * Callee saved registers for Xen's state deep in the callframe used to + * switch from prev's stack to the next's stack during context switch. + */ + struct + { + register_t s0; + register_t s1; + register_t s2; + register_t s3; + register_t s4; + register_t s5; + register_t s6; + register_t s7; + register_t s8; + register_t s9; + register_t s10; + register_t s11; + register_t sp; + register_t gp; + register_t ra; + } xen_saved_context; + + /* CSRs */ + register_t hedeleg; + register_t hideleg; + register_t hvip; + register_t hip; + register_t hie; + register_t hgeie; + register_t henvcfg; + register_t hcounteren; + register_t htimedelta; + register_t htval; + register_t htinst; + register_t hstateen0; +#ifdef CONFIG_RISCV_32 + register_t henvcfgh; + register_t htimedeltah; +#endif + + /* VCSRs */ + register_t vsstatus; + register_t vsip; + register_t vsie; + register_t vstvec; + register_t vsscratch; + register_t vscause; + register_t vstval; + register_t vsatp; + register_t vsepc; +} __cacheline_aligned; struct paging_domain { spinlock_t lock; -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:47:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:47:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211346.1522891 (Exim 4.92) (envelope-from ) id 1vixqV-0007XY-DT; Thu, 22 Jan 2026 16:47:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211346.1522891; Thu, 22 Jan 2026 16:47:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vixqV-0007Ww-5y; Thu, 22 Jan 2026 16:47:47 +0000 Received: by outflank-mailman (input) for mailman id 1211346; Thu, 22 Jan 2026 16:47: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 1vixqT-0007Ij-JI for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:47:45 +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 123f9bb3-f7b2-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 17:47:43 +0100 (CET) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-652fdd043f9so2075721a12.1 for ; Thu, 22 Jan 2026 08:47:43 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b879513e951sm1686014966b.7.2026.01.22.08.47.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 08:47:41 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 123f9bb3-f7b2-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769100462; x=1769705262; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Xs+SAk+ck32r+yVPkjsZQLd/gIzJLULQhlXaIyvjgE4=; b=irLUHRdrFHl4hUrYUNLBQvgcZvUHl/W6AhVMuC+92akbisiP7xieXVhHbHPqbGAopM 0XK9bCgoIZq0PRT4o5xchKmCKQXXwwTN8Pu7YhjtnD9c85D47LDPtZ+SB/E5n1LXSG8E /LLcpPwvw7pVp8NfNM91VM/TCYrCqyJt34+aN0AxJcOcmklEqDzho6rm27nVYfDsN3qg 3Cqt8/2z24elMWbi+1F4lyQFi1g65Uf8JtD+seRZBQ1CaglqBkV+ntSbfVD9CCsyctk5 NGwLapD54aGL21E6bPkfH9XnJOEfmnNdSOtu9uq3hWB0vYPBV4vinxHGzpc/8w6oeXQu 6R0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769100462; x=1769705262; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Xs+SAk+ck32r+yVPkjsZQLd/gIzJLULQhlXaIyvjgE4=; b=dtIJVq21uX872/HMxE9g+UMMcB/NHVgWxZ+EPai7+74Vm89EIFULXxVrFuVZBgaRHc Gr4jMAXFsLniLycSJHgcXZJpCEKgVDwLX7alRCExl/+Qc8yn73p6v6OGfNo4HlYaj+dK a99RlOeT619dGas4Yvd1y7NIvLmTKQpDGxgKRjxrzzONZLcEhQ2SqcD/z6jQXKa6TjMe Bxj9K3YbbXbxv2OAGTqIC65LEINSqrkH53YXHqSpd0BqXgO6+sFQOaPSpCxPtB3ZzDCS Z/3C78fuBmAhZuZsnfmA16Zm4xh9vMYlRiKJJWbsiPoJcc6c4fMUTQFC8ZgVIXIVysFG SefA== X-Gm-Message-State: AOJu0YzJGNthqEhoOd230vNQzaXw4VLVMqTSHL+Vzr5VYD2Rggp/dUmD SPHqaoWf7e4/uFeYVbBmqJ5alyBmj0IzsvclibRU+1IxgyLZWnnEObWXmJzMEw== X-Gm-Gg: AZuq6aLag382gogFX7hOA+u1MfDAKPmqsBXczLow8HmUTilL42uMMgxzNKNJ/bnEY1/ xFdyu/DVab6UNOiA1PwvkKE0btcxhCrHdn22vAQUXuYiSnBwgPCoNu9bwmuKdtXDoAk3+r1++VW okTwYJeTbBWsifDVDLsL8tHvv5qQ8RXn9hdQwypoHpvzR97TpFKzKjDe0/mrenS3q1VcSRQLCSF ayzoxrzPevc+81oO4Q+Mbc+7iIhCvnOhOInt2CGm7mq+7HjxYHyX3tqwONyqVFxBNPd8XPMMKcq b/R8WlHhlB6TJmzDN+OOOd2O8PbJKGXzyxLIvx3Goq6Okuq8lLWvjJOgower/xFIWhnpBbzsM4T i6pnoJzQ/O8mPbBBO2MBC1yACXPgoH9DovftnLnQ9bMApjXeSm4o1Hf4cCNxqvMYLLUm62Oaljx kUPuHGYahtDL8dzok9imAaJfBJJDa553anUP3ngs3QSK1mgGSAr88hkA== X-Received: by 2002:a17:907:26c8:b0:b7c:e320:5228 with SMTP id a640c23a62f3a-b8792e0e967mr1833140566b.22.1769100462166; Thu, 22 Jan 2026 08:47:42 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Romain Caritey Subject: [PATCH v2 02/16] xen/riscv: implement arch_vcpu_{create,destroy}() Date: Thu, 22 Jan 2026 17:47:17 +0100 Message-ID: <08b582179ebc4241140000972d89209c84c90fa4.1769099885.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Introduce architecture-specific functions to create and destroy VCPUs. Note that arch_vcpu_create() currently returns -EOPNOTSUPP, as the virtual timer and interrupt controller are not yet implemented. As part of this change, add continue_new_vcpu(), which will be used after the first context_switch() of a new vCPU. Since this functionality is not yet implemented, continue_new_vcpu() is currently provided as a stub. Update the STACK_SIZE definition and introduce STACK_ORDER (to align with other architectures) for allocating the vCPU stack. Introduce struct cpu_info to store per-vCPU state that lives at the top of the vCPU's stack. Signed-off-by: Oleksii Kurochko --- Changes in v2: - Drop BUILD_BUG_ON() in arch_vcpu_create() as a check isn't very useful. - Use vzalloc() instead of alloc_xenheap_page() to use the larger domheap to allocate vCPU's stack. - Drop printk() inside arch_vcpu_create() to not have potential big noise in console as it could be that an amount of vCPUs is pretty big. - Use XVFREE() instead of free_xenheap_pages() as vCPU's stack allocation happens with a usage of vzalloc() now. - Drop stack field as it is enough to have only cpu_info as stack pointer could be calculated based on cpu_info. - Drop cast when v.arch.cpu_info is inialized as it is not necessary to have it. - Drop memset() for arch.cpu_info() as it is enough to have vzalloc(). --- xen/arch/riscv/Makefile | 1 + xen/arch/riscv/domain.c | 59 ++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/config.h | 3 +- xen/arch/riscv/include/asm/current.h | 6 +++ xen/arch/riscv/include/asm/domain.h | 2 + xen/arch/riscv/stubs.c | 10 ----- 6 files changed, 70 insertions(+), 11 deletions(-) create mode 100644 xen/arch/riscv/domain.c diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile index 87c1148b0010..8863d4b15605 100644 --- a/xen/arch/riscv/Makefile +++ b/xen/arch/riscv/Makefile @@ -1,5 +1,6 @@ obj-y += aplic.o obj-y += cpufeature.o +obj-y += domain.o obj-$(CONFIG_EARLY_PRINTK) += early_printk.o obj-y += entry.o obj-y += imsic.o diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c new file mode 100644 index 000000000000..9c546267881b --- /dev/null +++ b/xen/arch/riscv/domain.c @@ -0,0 +1,59 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include +#include +#include +#include + +static void continue_new_vcpu(struct vcpu *prev) +{ + BUG_ON("unimplemented\n"); +} + +static void __init __maybe_unused build_assertions(void) +{ + /* + * Enforce the requirement documented in struct cpu_info that + * guest_cpu_user_regs must be the first field. + */ + BUILD_BUG_ON(offsetof(struct cpu_info, guest_cpu_user_regs) != 0); +} + +int arch_vcpu_create(struct vcpu *v) +{ + int rc = 0; + void *stack = vzalloc(STACK_SIZE); + + if ( !stack ) + return -ENOMEM; + + v->arch.cpu_info = stack + STACK_SIZE - sizeof(struct cpu_info); + memset(v->arch.cpu_info, 0, sizeof(*v->arch.cpu_info)); + + v->arch.xen_saved_context.sp = (register_t)v->arch.cpu_info; + v->arch.xen_saved_context.ra = (register_t)continue_new_vcpu; + + /* Idle VCPUs don't need the rest of this setup */ + if ( is_idle_vcpu(v) ) + return rc; + + /* + * As the vtimer and interrupt controller (IC) are not yet implemented, + * return an error. + * + * TODO: Drop this once the vtimer and IC are implemented. + */ + rc = -EOPNOTSUPP; + goto fail; + + return rc; + + fail: + arch_vcpu_destroy(v); + return rc; +} + +void arch_vcpu_destroy(struct vcpu *v) +{ + vfree((char *)v->arch.cpu_info + sizeof(struct cpu_info)); +} diff --git a/xen/arch/riscv/include/asm/config.h b/xen/arch/riscv/include/asm/config.h index 1e08d3bf78be..86a95df018b5 100644 --- a/xen/arch/riscv/include/asm/config.h +++ b/xen/arch/riscv/include/asm/config.h @@ -143,7 +143,8 @@ #define SMP_CACHE_BYTES (1 << 6) -#define STACK_SIZE PAGE_SIZE +#define STACK_ORDER 3 +#define STACK_SIZE (PAGE_SIZE << STACK_ORDER) #define IDENT_AREA_SIZE 64 diff --git a/xen/arch/riscv/include/asm/current.h b/xen/arch/riscv/include/asm/current.h index 0c3ea70c2ec8..58c9f1506b7c 100644 --- a/xen/arch/riscv/include/asm/current.h +++ b/xen/arch/riscv/include/asm/current.h @@ -21,6 +21,12 @@ struct pcpu_info { /* tp points to one of these */ extern struct pcpu_info pcpu_info[NR_CPUS]; +/* Per-VCPU state that lives at the top of the stack */ +struct cpu_info { + /* This should be the first member. */ + struct cpu_user_regs guest_cpu_user_regs; +}; + #define set_processor_id(id) do { \ tp->processor_id = (id); \ } while (0) diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h index 0d9b4c4b525e..ec7786c76199 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -49,6 +49,8 @@ struct arch_vcpu register_t ra; } xen_saved_context; + struct cpu_info *cpu_info; + /* CSRs */ register_t hedeleg; register_t hideleg; diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c index 29bdb65afbdf..9e30a9a3b50b 100644 --- a/xen/arch/riscv/stubs.c +++ b/xen/arch/riscv/stubs.c @@ -121,16 +121,6 @@ void dump_pageframe_info(struct domain *d) BUG_ON("unimplemented"); } -int arch_vcpu_create(struct vcpu *v) -{ - BUG_ON("unimplemented"); -} - -void arch_vcpu_destroy(struct vcpu *v) -{ - BUG_ON("unimplemented"); -} - void vcpu_switch_to_aarch64_mode(struct vcpu *v) { BUG_ON("unimplemented"); -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:47:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:47:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211347.1522895 (Exim 4.92) (envelope-from ) id 1vixqV-0007fE-MJ; Thu, 22 Jan 2026 16:47:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211347.1522895; Thu, 22 Jan 2026 16:47:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vixqV-0007cV-ID; Thu, 22 Jan 2026 16:47:47 +0000 Received: by outflank-mailman (input) for mailman id 1211347; Thu, 22 Jan 2026 16:47: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 1vixqU-0007Id-Vj for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:47:46 +0000 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [2a00:1450:4864:20::62b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 142313d6-f7b2-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 17:47:46 +0100 (CET) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-b8838339fc6so177815366b.0 for ; Thu, 22 Jan 2026 08:47:46 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b879513e951sm1686014966b.7.2026.01.22.08.47.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 08:47:44 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 142313d6-f7b2-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769100466; x=1769705266; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=XPAdNKHF5EjavsXAwjuKNGFWuBxYMr4iJeXH7Q9PsSE=; b=D4DReNfAPDbKDfXZ9/zF05gQc9KT9hisuLnKY2ogQ3YXLLlpaedpE3RzuwlC0oM/ij leONacPy+wcBeT3IMrn6aU6WiSyiZNZl2V6StbWiXJq78sSA3A3mPF8ILfcDIxqgK596 U5D7/C+sQL3niabL9BaXxFPK5ZtVVTbo4JwlfasICzVlrdBKn3GsduMiSH1RczU9Yf2z iMFRIxSmcEFUURSWQ5Wwx4W+jXKoIvnB+/m46mkcPjPCt75MHpBz0Os4EpUFm8ck8me2 gKZPe5aah3G7rT6axasNVKnBfMLiLLJcD45ySE6KVIEpyEWpI/rTcudja61EeRpgmPL+ 8RTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769100466; x=1769705266; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=XPAdNKHF5EjavsXAwjuKNGFWuBxYMr4iJeXH7Q9PsSE=; b=kDVC/+Ls/xf9Cz3W2N9dIKAgIRnANQI4MCsESBuZAATw2diLaSURtsWcajl+3ix2Dd BdJTz6ASnW3PQnTZGRIBlTpcIgoGFL4zf8AGLm/P2gwjo4yPJw3ubtMh5awwr4N52/A2 /sVYiX3utcz3uZYTdrWFvrX1PV2GwcJSzxaAmkzYH84RiIqtDyV+IUMKK/RUa9LXzgIE z5xWo6iE0lo6BGmP0wRuP8Z+Ran5MLmUo/8ROHI1xWn2QUyQ599kOHmaBFHTt/aCX1pd HoU7p5ANhE8UjvCyl8qqfNKq1AKuUQ9aL86dwmQ0kYAs5uLBdUCtI6Zr/tM18x0mPXii vBtw== X-Gm-Message-State: AOJu0YwBWNwuBW0KM2OuxK98jgNSRwpYz/TsVcNrfkvegRrYDTTzMI7Z 5OXrmMv6KWWh21brppvTLTmfCQFfZL3E/lduJOJiu4rrd7Z0WOcN92I35DYxkA== X-Gm-Gg: AZuq6aLdmR/A2xgQ6qh2HJbQ08E/ZCcy/2SFYtme0iuRsOYXPKiLECXqeY5Fi3Tux23 xRhxhbOjrvP7Eb1uxn0um2Rlsh+TUWD/DOP6Qe1OifaHYdQSU8tUntZFQ9KQr/JToRwERYjrZOW GSj6oDAEsSCzWdJ/ujbZqU1YJvGdTBrBiBnlcgPCJvgkXKtzPcF7LFGOP+cOVfSUyjuengPgqwQ Jjcrn9TbAn3uRpiALwSxURmHV3cBwuv134rrNX6lPM47kAXDKUWAldqF4pu0vZdO43IENXrIxs0 EA7Kx1penMkq2vGZG+32quUw4QmmN80sReod48RfBOYf8oN9uLYzUlccUsdAmWYmWMXfLoGaGAy WFO/D7s7E86uqYBq+IR5xnlXr1ED/MKAlfsX27XWKcrJVX6oLa26rQbN+HlpuzwWX5225hpo9sN sHFOhCxmOR7Cv61dHHqcx4v6yp61+hQCUtCKuCDnOLshnC1+NzHaxaSrGA8BB5uWCz X-Received: by 2002:a17:907:9803:b0:b87:7430:d5d7 with SMTP id a640c23a62f3a-b8831b40942mr252088866b.9.1769100465342; Thu, 22 Jan 2026 08:47:45 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Romain Caritey Subject: [PATCH v2 05/16] xen/riscv: introduce tracking of pending vCPU interrupts, part 2 Date: Thu, 22 Jan 2026 17:47:20 +0100 Message-ID: <58a7723ec48d84b91fd4730fe3ae653f55a0fd99.1769099885.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This patch is based on Linux kernel 6.16.0. Add the consumer side (vcpu_flush_interrupts()) of the lockless pending interrupt tracking introduced in part 1 (for producers). According, to the design only one consumer is possible, and it is vCPU itself. vcpu_flush_interrupts() is expected to be ran (as guests aren't ran now due to the lack of functionality) before the hypervisor returns control to the guest. Producers may set bits in irqs_pending_mask without a lock. Clearing bits in irqs_pending_mask is performed only by the consumer via xchg() (with aquire & release semantics). The consumer must not write to irqs_pending and must not act on bits that are not set in the mask. Otherwise, extra synchronization should be provided. The worst thing which could happen with such approach is that a new pending bit will be set to irqs_pending bitmap during update of hvip variable in vcpu_flush_interrupt() but it isn't problem as the new pending bit won't be lost and just be proceded during the next flush. It is possible a guest could have pending bit not result in the hardware register without to be marked pending in irq_pending bitmap as: According to the RISC-V ISA specification: Bits hip.VSSIP and hie.VSSIE are the interrupt-pending and interrupt-enable bits for VS-level software interrupts. VSSIP in hip is an alias (writable) of the same bit in hvip. Additionally: When bit 2 of hideleg is zero, vsip.SSIP and vsie.SSIE are read-only zeros. Else, vsip.SSIP and vsie.SSIE are aliases of hip.VSSIP and hie.VSSIE. This means the guest may modify vsip.SSIP, which implicitly updates hip.VSSIP and the bit being writable with 1 would also trigger an interrupt as according to the RISC-V spec: These conditions for an interrupt trap to occur must be evaluated in a bounded amount of time from when an interrupt becomes, or ceases to be, pending in sip, and must also be evaluated immediately following the execution of an SRET instruction or an explicit write to a CSR on which these interrupt trap conditions expressly depend (including sip, sie and sstatus). What means that IRQ_VS_SOFT must be synchronized separately, what is done in vcpu_sync_interrupts(). Note, also, that IRQ_PMU_OVF would want to be synced for the similar reason as IRQ_VS_SOFT, but isn't sync-ed now as PMU isn't supported now. For the remaining VS-level interrupt types (IRQ_VS_TIMER and IRQ_VS_EXT), the specification states they cannot be modified by the guest and are read-only: Bits hip.VSEIP and hie.VSEIE are the interrupt-pending and interrupt-enable bits for VS-level external interrupts. VSEIP is read-only in hip, and is the logical-OR of these interrupt sources: • bit VSEIP of hvip; • the bit of hgeip selected by hstatus.VGEIN; and • any other platform-specific external interrupt signal directed to VS-level. Bits hip.VSTIP and hie.VSTIE are the interrupt-pending and interrupt-enable bits for VS-level timer interrupts. VSTIP is read-only in hip, and is the logical-OR of hvip.VSTIP and any other platform-specific timer interrupt signal directed to VS-level. Thus, for these interrupt types, it is sufficient to use vcpu_set_interrupt() and vcpu_unset_interrupt(), and flush them during the call of vcpu_flush_interrupts(). As AIA specs introduced hviph register which would want to be updated when guest related AIA code will be introduced vcpu_update_hvip() is introduced instead of just open-code it in vcpu_flush_interrupts(). Signed-off-by: Oleksii Kurochko --- Changes in v2: - New patch. --- xen/arch/riscv/domain.c | 65 +++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/domain.h | 3 ++ 2 files changed, 68 insertions(+) diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 3777888f34ea..c078d595df9c 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -171,3 +171,68 @@ int vcpu_unset_interrupt(struct vcpu *v, unsigned int irq) return 0; } + +static void vcpu_update_hvip(struct vcpu *v) +{ + csr_write(CSR_HVIP, v->arch.hvip); +} + +void vcpu_flush_interrupts(struct vcpu *v) +{ + register_t *hvip = &v->arch.hvip; + + unsigned long mask, val; + + if ( ACCESS_ONCE(v->arch.irqs_pending_mask[0]) ) + { + mask = xchg(&v->arch.irqs_pending_mask[0], 0UL); + val = ACCESS_ONCE(v->arch.irqs_pending[0]) & mask; + + *hvip &= ~mask; + *hvip |= val; + } + + /* + * Flush AIA high interrupts. + * + * It is necessary to do only for CONFIG_RISCV_32 which isn't supported + * now. + */ +#ifdef CONFIG_RISCV_32 +# error "Update hviph" +#endif + + vcpu_update_hvip(v); +} + +void vcpu_sync_interrupts(struct vcpu *v) +{ + unsigned long hvip; + + /* Read current HVIP and VSIE CSRs */ + v->arch.vsie = csr_read(CSR_VSIE); + + /* Sync-up HVIP.VSSIP bit changes does by Guest */ + hvip = csr_read(CSR_HVIP); + if ( (v->arch.hvip ^ hvip) & BIT(IRQ_VS_SOFT, UL) ) + { + if ( !test_and_set_bit(IRQ_VS_SOFT, + &v->arch.irqs_pending_mask) ) + { + if ( hvip & BIT(IRQ_VS_SOFT, UL) ) + set_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); + else + clear_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); + } + } + + /* + * Sync-up AIA high interrupts. + * + * It is necessary to do only for CONFIG_RISCV_32 which isn't supported + * now. + */ +#ifdef CONFIG_RISCV_32 +# error "Update vsieh" +#endif +} diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h index b8178447c68f..fa083094b43e 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -136,6 +136,9 @@ static inline void arch_vcpu_block(struct vcpu *v) {} int vcpu_set_interrupt(struct vcpu *v, unsigned int irq); int vcpu_unset_interrupt(struct vcpu *v, unsigned int irq); +void vcpu_flush_interrupts(struct vcpu *v); +void vcpu_sync_interrupts(struct vcpu *v); + #endif /* ASM__RISCV__DOMAIN_H */ /* -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:47:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:47:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211348.1522915 (Exim 4.92) (envelope-from ) id 1vixqX-00086M-0M; Thu, 22 Jan 2026 16:47:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211348.1522915; Thu, 22 Jan 2026 16: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 1vixqW-00085k-Pi; Thu, 22 Jan 2026 16:47:48 +0000 Received: by outflank-mailman (input) for mailman id 1211348; Thu, 22 Jan 2026 16:47: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 1vixqV-0007Ij-36 for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:47: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 137f69b1-f7b2-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 17:47:45 +0100 (CET) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-b884ad1026cso100345066b.2 for ; Thu, 22 Jan 2026 08:47:45 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b879513e951sm1686014966b.7.2026.01.22.08.47.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 08:47:44 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 137f69b1-f7b2-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769100464; x=1769705264; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ZiDH4E+mr1/aSbgm5OGQwje0WHckqigBRFb2xamzygw=; b=jnvEBez1Ry9P3ZK8fjJtjD43sFT9HQmGsQa/0SEReCubcoFiswCZ6gqzCPmvznhNh8 HaKQefC82h8jNlsESFANZUomkdO3hF631H8KwLwJ5qcLSD8iJEFkl23tvhK4BNAxWRFO ViHJ1mguW8CLvn0g/xH9UW3heSQSLduQeZVU5vJyaltd+EGonmQSVqzfBcv/Jfc4jiX0 4Jj+xHbkZ6fPAAY2b+dqzLu6SnkaZIXXDZs0baN+D03i6XGh8VYCLNBMASdUQV36tayi oX48ZBrdmdqHRK2frWz4eIQjn/Qg87o6likcwodNL+CX1FEXYzwnEuRzmbASRA/XIvCW D9Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769100464; x=1769705264; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=ZiDH4E+mr1/aSbgm5OGQwje0WHckqigBRFb2xamzygw=; b=py4v1Tb1hU9Tb8qV85BI13w3zA2TFBDUICw6glYH/aFfaowMZixNUpSIS4dGSk5Ea4 dMN/XtHeTs05mGKuE617uSPjhyIl7AjQgeZFceCUYmS1/1KI3HOmOicwv5B7jIniq67T /CGTniwpt4Xxg0h+mSUDzyr5P1uPP5BIveUhMj+YVFUvNUnbWyzKfKOAJp9dxv9DbOC0 8dKXTysNYtYmzn1i5Vi2hhGtbQRX6Su3YkTI+sxZrWZTex59XDU1LSGKGn5iP4jtt1Vg nGH7h9IEFj8iYw+MCsP+NKaB1u7HUkVIHqZJvVUQUNA0TxTQA9m6wVCm+GDLhohgWQlk 1Fyg== X-Gm-Message-State: AOJu0Yzr91f7r347Iw6QY7YjiMYTMRut9t04PEuffUp+tM7rnTUY8E3W ZQ3G4/md949lFeIT2THCglHtzOB3yZ6zwLv3foxblIvHOKTv2Ucs5E25xF9hUw== X-Gm-Gg: AZuq6aK0bwCcnOAaxGC93v+RblntYXCeKi1BgXfavWeLDWRVicMppzDCrSusASXndI1 gyEPyQlGttq4XMc7uFRZTfTE6FmfFU0lQTDoT8Tml+yQhk7MuJuIpf9Ipe7QV9xYio6s03cWDvh w9RfuJQ6DgHCD/d0X5z2rVj46WogcXgvHArbjV/iePZiDq6ejIrYrWCgnYt+P2+G7oJEoGCJRNJ gPe19ENca6lWpeX78RYADNoQIMRZm/5lJ5m0DEl529MwcycjSM0KgRC4WMVb+7vtDXDqr4KUT7d n1/m2wnS9feubJmm8LFx5y3/uGqsb0gtGS1+t+4plHIrpi5Eueqxclw9MQsoTtHvZLJlp7JWswp 3N0gtn58sZgYMpTYqNn3+zrtaie0Nq8MBV9fG2wbIjYWpmSEWBjzqodgDpuNQmA364aed8q7NX5 bQ1cIupQ/5G8Z4ZC/MnnTvtLLEsNvSx9kYRFo3QlfT75t2iXD2abDdr5pgb6mTKGAg X-Received: by 2002:a17:907:e158:b0:b88:22f1:769d with SMTP id a640c23a62f3a-b8822f18d1emr325009566b.19.1769100464298; Thu, 22 Jan 2026 08:47:44 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Romain Caritey Subject: [PATCH v2 04/16] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 Date: Thu, 22 Jan 2026 17:47:19 +0100 Message-ID: <7b5b7cceb8a131b198d33a83f49ed112ff310389.1769099885.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Based on Linux kernel v6.16.0. Add lockless tracking of pending vCPU interrupts using atomic bitops. Two bitmaps are introduced: - irqs_pending — interrupts currently pending for the vCPU - irqs_pending_mask — bits that have changed in irqs_pending The design follows a multi-producer, single-consumer model, where the consumer is the vCPU itself. Producers may set bits in irqs_pending_mask without a lock. Clearing bits in irqs_pending_mask is performed only by the consumer via xchg_acquire(). The consumer must not write to irqs_pending and must not act on bits that are not set in the mask. Otherwise, extra synchronization should be provided. On RISC-V interrupts are not injected via guest registers, so pending interrupts must be recorded in irqs_pending (using the new vcpu_{un}set_interrupt() helpers) and flushed to the guest by updating HVIP before returning control to the guest. The consumer side is implemented in a follow-up patch. A barrier between updating irqs_pending and setting the corresponding mask bit in vcpu_set_interrupt() / vcpu_unset_interrupt() guarantees that if the consumer observes a mask bit set, the corresponding pending bit is also visible. This prevents missed interrupts during the flush. Signed-off-by: Oleksii Kurochko --- Changes in V2: - Move the patch before an introduction of vtimer. - Drop bitmap_zero() of irqs_pending and irqs_pending_mask bitmaps as vcpu structure starts out all zeros. - Drop const for irq argument of vcpu_{un}set_interrupt(). - Drop check "irq < IRQ_LOCAL_MAX" in vcpu_{un}set_interrupt() as it could lead to overrun of irqs_pending and irqs_pending_mask bitmaps. - Drop IRQ_LOCAL_MAX as there is no usage for it now. --- xen/arch/riscv/domain.c | 41 +++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/domain.h | 19 +++++++++++++ 2 files changed, 60 insertions(+) diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 3ae5fa3a8805..3777888f34ea 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -5,6 +5,7 @@ #include #include +#include #include #include #include @@ -130,3 +131,43 @@ void arch_vcpu_destroy(struct vcpu *v) { vfree((char *)v->arch.cpu_info + sizeof(struct cpu_info)); } + +int vcpu_set_interrupt(struct vcpu *v, unsigned int irq) +{ + /* + * We only allow VS-mode software, timer, and external + * interrupts when irq is one of the local interrupts + * defined by RISC-V privilege specification. + */ + if ( irq != IRQ_VS_SOFT && + irq != IRQ_VS_TIMER && + irq != IRQ_VS_EXT ) + return -EINVAL; + + set_bit(irq, v->arch.irqs_pending); + smp_mb__before_atomic(); + set_bit(irq, v->arch.irqs_pending_mask); + + vcpu_kick(v); + + return 0; +} + +int vcpu_unset_interrupt(struct vcpu *v, unsigned int irq) +{ + /* + * We only allow VS-mode software, timer, external + * interrupts when irq is one of the local interrupts + * defined by RISC-V privilege specification. + */ + if ( irq != IRQ_VS_SOFT && + irq != IRQ_VS_TIMER && + irq != IRQ_VS_EXT ) + return -EINVAL; + + clear_bit(irq, v->arch.irqs_pending); + smp_mb__before_atomic(); + set_bit(irq, v->arch.irqs_pending_mask); + + return 0; +} diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h index ec7786c76199..b8178447c68f 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -79,6 +79,22 @@ struct arch_vcpu register_t vstval; register_t vsatp; register_t vsepc; + + /* + * VCPU interrupts + * + * We have a lockless approach for tracking pending VCPU interrupts + * implemented using atomic bitops. The irqs_pending bitmap represent + * pending interrupts whereas irqs_pending_mask represent bits changed + * in irqs_pending. Our approach is modeled around multiple producer + * and single consumer problem where the consumer is the VCPU itself. + * + * DECLARE_BITMAP() is needed here to support 64 vCPU local interrupts + * on RV32 host. + */ +#define RISCV_VCPU_NR_IRQS 64 + DECLARE_BITMAP(irqs_pending, RISCV_VCPU_NR_IRQS); + DECLARE_BITMAP(irqs_pending_mask, RISCV_VCPU_NR_IRQS); } __cacheline_aligned; struct paging_domain { @@ -117,6 +133,9 @@ static inline void update_guest_memory_policy(struct vcpu *v, static inline void arch_vcpu_block(struct vcpu *v) {} +int vcpu_set_interrupt(struct vcpu *v, unsigned int irq); +int vcpu_unset_interrupt(struct vcpu *v, unsigned int irq); + #endif /* ASM__RISCV__DOMAIN_H */ /* -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:47:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:47:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211349.1522926 (Exim 4.92) (envelope-from ) id 1vixqY-0008St-DJ; Thu, 22 Jan 2026 16:47:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211349.1522926; Thu, 22 Jan 2026 16:47:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vixqY-0008Si-99; Thu, 22 Jan 2026 16:47:50 +0000 Received: by outflank-mailman (input) for mailman id 1211349; Thu, 22 Jan 2026 16:47:48 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vixqW-0007Id-HX for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:47:48 +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 14e09f29-f7b2-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 17:47:47 +0100 (CET) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-b79f8f7ea43so103703766b.2 for ; Thu, 22 Jan 2026 08:47:47 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b879513e951sm1686014966b.7.2026.01.22.08.47.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 08:47:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 14e09f29-f7b2-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769100467; x=1769705267; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ha0IH64FmrGoMb6j9b2jIRmC/orgpSfo7QhViTDdwG8=; b=YAS9O7nNZfFjmmwqZSl7XLm5X/vnqIhk1MQ7fa1h+H6Mb+5aUe67A6Eyk5Ut1Bkj3Z tqsMhJXp8Z306AE2TfGGd4FpIzGQUbpoFRMunwHVCYRQyB/pTz38plkwo9yhll3UepMW taLpSjotSX/XxmynSquAcn7y6M9JG5u/jW8kPYQJ8KFe7IRIBL6evsgT4b0S69p4574J CiLDZBdEegSylMXd84kqBC50SFHFLQGy6R+3rDDBQOYu5Y493fV969/Dcaf4FGWswS3e +GCYl3FLHjp5PeLp5Qd7ZrE3haXf7fCHu7zyjY3P6Ba0uJ9Qc0GhMkooGzEfWDhQviu6 z6Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769100467; x=1769705267; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=ha0IH64FmrGoMb6j9b2jIRmC/orgpSfo7QhViTDdwG8=; b=cnuxJzhX8d1O5HNCfkhu+0uJAbb0DLy4Za+Kkssx5UPJBL/2O5ZtjfJNlTSUG/RmPb lPS7msF75pkirArj4KSz1256ZdMC3I9qgtJ5x8N8M/N9a2Uu/QZaHZK9FQym+apljL7Z Z5+B9ymFeOKEQIHCajO3B9yMh8Ec1BuMdDDeMD6+TdefNsykIH0nwUVxGD5Dh1QL4n0u CHHZ6NXcj+4fqD5iLNwo/MaNy+STUvbfp8svjPuU+ARQX8K5aTUZagb9uJDPqML2zU/N xqrpgH5QmRJ7Wi7yB/XovjJVf31BVunMVe4Gp4ddsyCdoF89Y4tLZbrCqnVm7p7yVuJ8 oZmQ== X-Gm-Message-State: AOJu0YwbMLQpLjimYWSzcM/IAK+QAfKIh9tyYSRndJNYJ6bV/ZreAyzW mLUleRo9PTHqoUkWwHcKfjmawXoPUjpTtZubMZvDS+2tmLo/MJDHilIdCYlkmg== X-Gm-Gg: AZuq6aL2Wi9hkphDa8PmTlDq4PtgpDGPqg0L8eNlX5C1LISQTDa/8zKVC4s4H2a+/q5 j8Q4aOT6qBxDiEvc4ICPMD3oWGsXj0x/dMYsFg3v1ifG/NsOCgvZS1iceuGBzv0JBI9y4PyD0r8 7u8DsQdpCJAJgAMPrs2QEdaBQFM1SQPlpYrsrPzAj/bg7Re7JM8RBUZZvoz//afQmcTpPFSH0oo 4Vs8pOFMcgYX7HWEvla82Nr9tMKvVxuo8/EtyUxHtvxqpG5tImvft4RiaPSSgGZtJ+gKpZ2Hoxm HVSaXFt/fEOAVsUw8fEFOvt6eKDl4EG9XTzx8Fg/v5cOSvctABa/BPhIKlzvYekBqnEZoouQyaf 9sdLQmxTjhwM5ruo08v9T60wS5qikkl3TkwCfwZgK9dBQKZecYzcvtkbX1oYq+KP9+cGLcD20/x R7C/szD/rhIKrlFD0xkv/yCWvSYpffKw0bX3euyEjk5l9906873EsEVA== X-Received: by 2002:a17:907:1b25:b0:b80:4030:1eca with SMTP id a640c23a62f3a-b880023748emr716691166b.2.1769100466636; Thu, 22 Jan 2026 08:47:46 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Alistair Francis , Connor Davis , Romain Caritey Subject: [PATCH v2 06/16] xen/time: move ticks<->ns helpers to common code Date: Thu, 22 Jan 2026 17:47:21 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ticks_to_ns() and ns_to_ticks() are not architecture-specific, so provide a common implementation that is more resilient to overflow than the historical Arm version. This is not a practical issue for Arm, as the latest ARM ARM that timer frequency should be fixed at 1 GHz and older platforms used much lower rates, which is shy of 32-bit overflow. As the helpers are declared as static inline, they should not affect x86, which does not use them. On Arm, these helpers were historically implemented as out-of-line functions because the counter frequency was originally defined as static and unavailable to headers [1]. Later changes [2] removed this restriction, but the helpers remained unchanged. Now they can be implemented as static inline without any issues. Centralising the helpers avoids duplication and removes subtle differences between architectures while keeping the implementation simple. Drop redundant includes where already pulls it in. No functional change is intended. [1] ddee56dc2994 arm: driver for the generic timer for ARMv7 [2] 096578b4e489 xen: move XEN_SYSCTL_physinfo, XEN_SYSCTL_numainfo and XEN_SYSCTL_topologyinfo to common code Signed-off-by: Oleksii Kurochko Suggested-by: Jan Beulich --- Changes in v2: - Move ns_to_ticks() and ticks_to_ns() to common code. --- xen/arch/arm/include/asm/time.h | 3 --- xen/arch/arm/time.c | 11 ----------- xen/arch/arm/vtimer.c | 2 +- xen/arch/riscv/include/asm/time.h | 5 ----- xen/arch/riscv/time.c | 1 + xen/include/xen/time.h | 11 +++++++++++ 6 files changed, 13 insertions(+), 20 deletions(-) diff --git a/xen/arch/arm/include/asm/time.h b/xen/arch/arm/include/asm/time.h index 49ad8c1a6d47..c194dbb9f52d 100644 --- a/xen/arch/arm/include/asm/time.h +++ b/xen/arch/arm/include/asm/time.h @@ -101,9 +101,6 @@ extern void init_timer_interrupt(void); /* Counter value at boot time */ extern uint64_t boot_count; -extern s_time_t ticks_to_ns(uint64_t ticks); -extern uint64_t ns_to_ticks(s_time_t ns); - void preinit_xen_time(void); void force_update_vcpu_system_time(struct vcpu *v); diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c index cc3fcf47b66a..a12912a106a0 100644 --- a/xen/arch/arm/time.c +++ b/xen/arch/arm/time.c @@ -27,7 +27,6 @@ #include #include #include -#include #include uint64_t __read_mostly boot_count; @@ -47,16 +46,6 @@ unsigned int timer_get_irq(enum timer_ppi ppi) return timer_irq[ppi]; } -/*static inline*/ s_time_t ticks_to_ns(uint64_t ticks) -{ - return muldiv64(ticks, SECONDS(1), 1000 * cpu_khz); -} - -/*static inline*/ uint64_t ns_to_ticks(s_time_t ns) -{ - return muldiv64(ns, 1000 * cpu_khz, SECONDS(1)); -} - static __initdata struct dt_device_node *timer; #ifdef CONFIG_ACPI diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c index d2124b175521..2e85ff2b6e62 100644 --- a/xen/arch/arm/vtimer.c +++ b/xen/arch/arm/vtimer.c @@ -12,13 +12,13 @@ #include #include #include +#include #include #include #include #include #include -#include #include #include #include diff --git a/xen/arch/riscv/include/asm/time.h b/xen/arch/riscv/include/asm/time.h index 1e7801e2ea0e..be3875b9984e 100644 --- a/xen/arch/riscv/include/asm/time.h +++ b/xen/arch/riscv/include/asm/time.h @@ -24,11 +24,6 @@ static inline cycles_t get_cycles(void) return csr_read(CSR_TIME); } -static inline s_time_t ticks_to_ns(uint64_t ticks) -{ - return muldiv64(ticks, MILLISECS(1), cpu_khz); -} - void preinit_xen_time(void); #endif /* ASM__RISCV__TIME_H */ diff --git a/xen/arch/riscv/time.c b/xen/arch/riscv/time.c index e962f8518d78..2c7af0a5d63b 100644 --- a/xen/arch/riscv/time.c +++ b/xen/arch/riscv/time.c @@ -4,6 +4,7 @@ #include #include #include +#include #include unsigned long __ro_after_init cpu_khz; /* CPU clock frequency in kHz. */ diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h index fe0d7a578a99..2185dd26a439 100644 --- a/xen/include/xen/time.h +++ b/xen/include/xen/time.h @@ -8,6 +8,7 @@ #ifndef __XEN_TIME_H__ #define __XEN_TIME_H__ +#include #include #include @@ -75,6 +76,16 @@ extern void send_timer_event(struct vcpu *v); void domain_set_time_offset(struct domain *d, int64_t time_offset_seconds); +static inline s_time_t ticks_to_ns(uint64_t ticks) +{ + return muldiv64(ticks, MILLISECS(1), cpu_khz); +} + +static inline uint64_t ns_to_ticks(s_time_t ns) +{ + return muldiv64(ns, cpu_khz, MILLISECS(1)); +} + #include #endif /* __XEN_TIME_H__ */ -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:47:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:47:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211350.1522936 (Exim 4.92) (envelope-from ) id 1vixqa-0000Nb-NZ; Thu, 22 Jan 2026 16:47:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211350.1522936; Thu, 22 Jan 2026 16: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 1vixqa-0000NK-Ii; Thu, 22 Jan 2026 16:47:52 +0000 Received: by outflank-mailman (input) for mailman id 1211350; Thu, 22 Jan 2026 16:47: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 1vixqY-0007Id-Vv for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:47: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 10f638db-f7b2-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 17:47:41 +0100 (CET) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-64b7318f1b0so1615058a12.2 for ; Thu, 22 Jan 2026 08:47:41 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b879513e951sm1686014966b.7.2026.01.22.08.47.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 08:47:39 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 10f638db-f7b2-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769100460; x=1769705260; 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=XJbG6vfGmuAQ64APf6ZJ70lw3nhTcRe8DrgXDE4zMmo=; b=nC61hGXxEFUtEjIfBkkb3bAKR8b7y+hDQGUf8YCOiirkUAtlP0daT3ioGb4VglEBIP 9Myy1I3yEEnQvPqowDzbH8k9mDyTr/UMokFLbQMOdMJ10EvB7dwym7GEO1Jff4s0r6RU KT+DM0GbiG9SEEeUlWx3+Y76Hc2NOysx2lHqrlTKzWvEZpDnx3MKZtzGM6KSUoWeslZ8 1DK8hUVLxDO2ImksypOFWvZ730SizV/VW80lNgy0qyPHUIqcAQkkHsCJ3PhWXhNuRTUq i9oj7hxFV4L64d0IxSKICXKc80rPZc/yWzAkK4DIsE15zIYvThEXFaFRnz8a7pwTEk9p c7WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769100460; x=1769705260; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=XJbG6vfGmuAQ64APf6ZJ70lw3nhTcRe8DrgXDE4zMmo=; b=VH46pEgOqQSxXFdSNwFUe7QFA0g7AW4PW6Fr2nCa7ao59qLIoma/RPTqt7CPT6UOMZ ++3hgypUsQpH+zkpsDKgV6jDV7PxB6vGu7bUc9Z39r6BCr0UiJdfOdWlTBH/JpjA+Hm+ Yin98Imzq7m6pTkX2+7nsqTTCZh+it6ZavJf1Nq+/94SukqY1cfqwnF8/NVsLc6y+G+8 78V3GB4VxJ3fKnGko93NiupEjs/jC+HPMHvGqM8yMrKMWNXWpfTh+zPXeuW8PmeiHPkJ X1g8GYTb1VjF21QdSuAkdmzkBo3lS39WjZ7HiCa4eqrE3pQZ1S5saH9YyOOleDI5Wv7Y JR6A== X-Gm-Message-State: AOJu0YwG230vEBOg+zXGeIBQcw0gxFdOWvtUTcUHaGadpCUAjhCg5DQC WFlv7DqG/BzhbckDx0bm7VAL6dk4wczl3Twi2Er02bjrNihYqn7fieSP9Xwu1A== X-Gm-Gg: AZuq6aKZFpWgz2sXUhlg6ZDHbbSTPMaVX12Qzdh1KMmGFjYbJ/iUrjUXiUnBLqBElEO qtZOVuWCmN/H4p+OMFVeTnu9KMErDINT9fA4BOj6RKq8BbFti9ddGvcVl3X4Hhrf7DtXVIKvOt/ kdAtUgny9lv8tVurfM1+evZm41Tkz+fYN626U03BOn3itXJ2WKXJK6HWqFMJxOGeEWxnBvAeO8D Sl11OyZCAj0urD0ytLiAx8PVz8o2/HnEavxyiLUPfKZlfcMdeBK2pW35CWK9fdbgwKrgJJlBz5V bLZowO+957hR9t+4eJiftpL4LXgP5rKabaQj4GEVWuSkRD7v9RcZKpYiz2EdFPhdZRFcBhQgaDr ElHCSU9nE8P6a4t0jNCLGSZ53GvGgnYny2zyVcNaeDXDoqSXy6VSxeDUN496qPRIqnazESLCq/Y iOdroHjXYQ4aOxY8An3lZ3NpdYyIup80bIrFQrPUsvN53JG9RnN0JKug== X-Received: by 2002:a17:907:c19:b0:b87:1741:a494 with SMTP id a640c23a62f3a-b87968f5a60mr1643494466b.17.1769100459978; Thu, 22 Jan 2026 08:47:39 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Bertrand Marquis , Volodymyr Babchuk , Romain Caritey Subject: [PATCH v2 00/16] xen/riscv: introduce vtimer related things Date: Thu, 22 Jan 2026 17:47:15 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This patch series introduces the components necessary to implement a virtual timer (vtimer). Since the SSTC extension is not supported by Xen, an emulated (SBI-based) timer is required. To address this, a virtual timer built on Xen’s timer infrastructure is introduced, with save/restore support and SBI-based programming. To provide full guest software–based timer support, the following components are also introduced: - arch_vcpu_{create,destroy}() to initialize the virtual timer and other vCPU-related state not directly tied to timer functionality. As part of this work, struct arch_vcpu is introduced to describe the internal state of a virtual CPU, along with vcpu_csr_init() to initialize the relevant CSR state. - Support functions required by the virtual timer, including: - vcpu_kick(), and a stub implementation of smp_send_event_check_mask() (since SMP is not yet supported in Xen), which is used by vcpu_kick(). - Support for guest timer programming via interception of the SBI legacy SET_TIMER call from guest. - Implement reprogram_timer() using introduced sbi_set_timer(). - Initial lockless tracking of pending vCPU interrupts using atomic bitmaps. - Handling of hypervisor timer interrupts and dispatch into Xen’s generic timer softirq. --- Changes in v2: - Add consumer part of tracking of pending vCPU interrupts. - Split patch "xen/riscv: init tasklet subsystem" to two. - Patches were acked: - xen/riscv: introduce vcpu_kick() implementation - xen/riscv: implement SBI legacy SET_TIMER support for guests - All other changes are patch-specific. Please check them. --- Oleksii Kurochko (16): xen/riscv: introduce struct arch_vcpu xen/riscv: implement arch_vcpu_{create,destroy}() xen/riscv: implement vcpu_csr_init() xen/riscv: introduce tracking of pending vCPU interrupts, part 1 xen/riscv: introduce tracking of pending vCPU interrupts, part 2 xen/time: move ticks<->ns helpers to common code xen/riscv: introduce basic vtimer infrastructure for guests xen/riscv: add temporary stub for smp_send_event_check_mask() xen/riscv: introduce vcpu_kick() implementation xen/riscv: add vtimer context switch helpers xen/riscv: implement SBI legacy SET_TIMER support for guests xen/riscv: introduce sbi_set_timer() xen/riscv: implement reprogram_timer() via SBI xen/riscv: handle hypervisor timer interrupts xen/riscv: init tasklet subsystem xen/riscv: implement sync_vcpu_execstate() xen/arch/arm/include/asm/time.h | 3 - xen/arch/arm/time.c | 11 - xen/arch/arm/vtimer.c | 2 +- xen/arch/riscv/Makefile | 2 + xen/arch/riscv/cpufeature.c | 1 + xen/arch/riscv/domain.c | 279 ++++++++++++++++++++ xen/arch/riscv/include/asm/config.h | 3 +- xen/arch/riscv/include/asm/cpufeature.h | 1 + xen/arch/riscv/include/asm/current.h | 8 + xen/arch/riscv/include/asm/domain.h | 84 +++++- xen/arch/riscv/include/asm/riscv_encoding.h | 2 + xen/arch/riscv/include/asm/sbi.h | 18 ++ xen/arch/riscv/include/asm/time.h | 5 - xen/arch/riscv/include/asm/vtimer.h | 23 ++ xen/arch/riscv/sbi.c | 40 +++ xen/arch/riscv/setup.c | 3 + xen/arch/riscv/smp.c | 7 + xen/arch/riscv/stubs.c | 35 --- xen/arch/riscv/time.c | 44 +++ xen/arch/riscv/traps.c | 14 + xen/arch/riscv/vsbi/legacy-extension.c | 6 + xen/arch/riscv/vtimer.c | 88 ++++++ xen/include/xen/time.h | 11 + 23 files changed, 632 insertions(+), 58 deletions(-) create mode 100644 xen/arch/riscv/domain.c create mode 100644 xen/arch/riscv/include/asm/vtimer.h create mode 100644 xen/arch/riscv/vtimer.c -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:47:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:47:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211351.1522943 (Exim 4.92) (envelope-from ) id 1vixqb-0000Ql-8E; Thu, 22 Jan 2026 16:47:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211351.1522943; Thu, 22 Jan 2026 16:47: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 1vixqa-0000QD-Rw; Thu, 22 Jan 2026 16:47:52 +0000 Received: by outflank-mailman (input) for mailman id 1211351; Thu, 22 Jan 2026 16:47: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 1vixqZ-0007Ij-2k for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:47:51 +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 15ab09f6-f7b2-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 17:47:49 +0100 (CET) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-b87cc82fd85so200576466b.2 for ; Thu, 22 Jan 2026 08:47:48 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b879513e951sm1686014966b.7.2026.01.22.08.47.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 08:47:47 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 15ab09f6-f7b2-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769100468; x=1769705268; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=5c7RQ6OyPVY512X4e6H+NfNdqywFVdT5uOFctDjaxTg=; b=VooXe8WAyLXjDW+yhJ90+guS+IIAI6WBzr+WJVtYthd6oo0CaZjPvp+aE29zOxq9nk U2t17X45KKW2Vob85B+1UKjMKQvIFb6pZGrlprUdeJWuw5wyeJzf7490EGmCefD9hBp1 vj/4tSuP83SgDnkeDrCaMm0Th9JW/pAztWGGef35foCBz/wdmvQ9iTgslvZq2isCl7hz 0kzp9ybZYrYrEGvcbIru85WipIXA6zcyIx83A3AEF5uLf4jXmqjGaqOODInchLQkHWqf Yf2wvJbKzy04sQnllC9oDaWDOLVzkEY7AorKY3STraE46ydxK3M0W/Zq+Tt2eBmlimyU NhrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769100468; x=1769705268; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=5c7RQ6OyPVY512X4e6H+NfNdqywFVdT5uOFctDjaxTg=; b=SEKuRwcieNk3RGx70o2jV5jGkZaXZYyz5B9ihvl+IakNNQM03nbLafmhWb+0q1BljP Se6e367DMz0fYJ0kobcwu1kXCsMqc/N4iWTcdVojjgITZYeW0Z2ph+dq97bheHfk2hHK 6Vo6Rme03f4W3Cizii/pyvzljIU3xinBE9B4XFXdyDYc+P2lZGxsISK7VOak2BKWn3mM 29rldNYetS2pcFldJrfSs1zc9FVH4up5tOWelRyq4kFVUgOuLkTk1+b3w0Py2qXJNTkk cJ4zXw+V8Rl7zkrcSeOIwv2FBK4wH6gFLDehQd2K4G3/SZWOO/Rxjiwyhs4gGoK7l+Px lBPA== X-Gm-Message-State: AOJu0YytG2NH1KylYuLmIvIHNrMtdGU48LUq4+iJBeSd0yFVWkdLsCjD CBduFHZv/tsiYY6uibpEuZIDgOGN43qVLN502Xlr6Wy9JE5fqsFWxzAcFCy5Ig== X-Gm-Gg: AZuq6aJDd84EQWQYuin9Hk3m36/e/bxvvmKSikyQNOxDoXiyhDJzJSLe+luaNXwuk/3 qFOwqNYA0MhW09OA+XCl1QRYvCmC8G+vSiC3YUCW/x2yALP67a/zeua0vcG3LhbLjM2ES8zyZqB kTgEZIuw8109MYbxFURH52W2RL9HrGLmxgfF8B+OwVWx5vNRx5ZHePQXjXiZXU6Uk07x+je6fCY p+Zm7ud4dAe/y8dHjOmnYtR3emevA7GQfID03hFIxKNVWQxP/EZJ0XzhsMo2jog4XgP1zDUObWi aB6PfxGpA4wPan1jqo6tTtSvDlV0LX0Z29yAEJr1HGo3H7/cYuzHtgBUjWck+XUVwa52eDpYtMt hHeMvYRJlWpvNgxJF8VYR5tXYeRwPUfCok0tBqX4XUYImq9YBRyhiPvk1xRkaXOqMxTz/Z0CBEj cFSkxlsa9mGLauPvRngbual//U9Usj21QM0pIGNcA3ZD49rPWVTHfgXA== X-Received: by 2002:a17:906:f584:b0:b73:278a:a499 with SMTP id a640c23a62f3a-b879690c3ccmr1747464466b.15.1769100467976; Thu, 22 Jan 2026 08:47:47 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Romain Caritey Subject: [PATCH v2 07/16] xen/riscv: introduce basic vtimer infrastructure for guests Date: Thu, 22 Jan 2026 17:47:22 +0100 Message-ID: <381c200edaff013d999c6314c20e8cc8bdb5b041.1769099885.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Lay the groundwork for guest timer support by introducing a per-vCPU virtual timer backed by Xen’s common timer infrastructure. The virtual timer is programmed in response to the guest SBI sbi_set_timer() call and injects a virtual supervisor timer interrupt into the vCPU when it expires. While a dedicated struct vtimer is not strictly required at present, it is expected to become necessary once SSTC support is introduced. In particular, it will need to carry additional state such as whether SSTC is enabled, the next compare value (e.g. for the VSTIMECMP CSR) to be saved and restored across context switches, and time delta state (e.g. HTIMEDELTA) required for use cases such as migration. Introducing struct vtimer now avoids a later refactoring. Signed-off-by: Oleksii Kurochko --- Changes in v2: - Drop domain_vtimer_init() as it does nothing. - Drop "struct vcpu *v;" from struct vtimer as it could be taken from arch_vcpu using container_of(). - Drop vtimer_initialized, use t->status == TIMER_STATUS_invalid instead to understand if timer was or wasn't initialized. - Drop inclusion of xen/domain.h as xen/sched.h already includes it. - s/ xen/time.h/ xen.timer.h in vtimer.c. - Drop ULL in if-conidtion in vtimer_set_timer() as with the cast it isn't necessary to have suffix ULL. - Add migrate timer to vtimer_set_timer() to be sure that vtimer will occur on pCPU it was ran, so the signalling to that vCPU will (commonly) be cheaper. - Check if the timeout has already expired and just inject the event in vtimer_vtimer_set_timer(). - Drop const for ticks argument of vtimer_set_timer(). - Merge two patches to one: - xen/riscv: introduce vtimer - xen/riscv: introduce vtimer_set_timer() and vtimer_expired() --- xen/arch/riscv/Makefile | 1 + xen/arch/riscv/domain.c | 8 +++- xen/arch/riscv/include/asm/domain.h | 3 ++ xen/arch/riscv/include/asm/vtimer.h | 20 ++++++++ xen/arch/riscv/vtimer.c | 73 +++++++++++++++++++++++++++++ 5 files changed, 103 insertions(+), 2 deletions(-) create mode 100644 xen/arch/riscv/include/asm/vtimer.h create mode 100644 xen/arch/riscv/vtimer.c diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile index 8863d4b15605..5bd180130165 100644 --- a/xen/arch/riscv/Makefile +++ b/xen/arch/riscv/Makefile @@ -22,6 +22,7 @@ obj-y += traps.o obj-y += vmid.o obj-y += vm_event.o obj-y += vsbi/ +obj-y += vtimer.o $(TARGET): $(TARGET)-syms $(OBJCOPY) -O binary -S $< $@ diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index c078d595df9c..e38c0db62cac 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -9,6 +9,7 @@ #include #include #include +#include #define HEDELEG_DEFAULT (BIT(CAUSE_MISALIGNED_FETCH, U) | \ BIT(CAUSE_FETCH_ACCESS, U) | \ @@ -111,11 +112,14 @@ int arch_vcpu_create(struct vcpu *v) if ( is_idle_vcpu(v) ) return rc; + if ( (rc = vcpu_vtimer_init(v)) ) + goto fail; + /* - * As the vtimer and interrupt controller (IC) are not yet implemented, + * As interrupt controller (IC) is not yet implemented, * return an error. * - * TODO: Drop this once the vtimer and IC are implemented. + * TODO: Drop this once IC is implemented. */ rc = -EOPNOTSUPP; goto fail; diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h index fa083094b43e..482429d4ef33 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -8,6 +8,7 @@ #include #include +#include struct vcpu_vmid { uint64_t generation; @@ -51,6 +52,8 @@ struct arch_vcpu struct cpu_info *cpu_info; + struct vtimer vtimer; + /* CSRs */ register_t hedeleg; register_t hideleg; diff --git a/xen/arch/riscv/include/asm/vtimer.h b/xen/arch/riscv/include/asm/vtimer.h new file mode 100644 index 000000000000..0d1555511755 --- /dev/null +++ b/xen/arch/riscv/include/asm/vtimer.h @@ -0,0 +1,20 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * (c) 2023-2024 Vates + */ + +#ifndef ASM__RISCV__VTIMER_H +#define ASM__RISCV__VTIMER_H + +#include + +struct vtimer { + struct timer timer; +}; + +int vcpu_vtimer_init(struct vcpu *v); +void vcpu_timer_destroy(struct vcpu *v); + +void vtimer_set_timer(struct vtimer *t, uint64_t ticks); + +#endif /* ASM__RISCV__VTIMER_H */ diff --git a/xen/arch/riscv/vtimer.c b/xen/arch/riscv/vtimer.c new file mode 100644 index 000000000000..b6599fa383b8 --- /dev/null +++ b/xen/arch/riscv/vtimer.c @@ -0,0 +1,73 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include +#include + +#include + +static void vtimer_expired(void *data) +{ + struct vtimer *t = data; + struct arch_vcpu *avcpu = container_of(t, struct arch_vcpu, vtimer); + struct vcpu *v = container_of(avcpu, struct vcpu, arch); + + vcpu_set_interrupt(v, IRQ_VS_TIMER); +} + +int vcpu_vtimer_init(struct vcpu *v) +{ + struct vtimer *t = &v->arch.vtimer; + + init_timer(&t->timer, vtimer_expired, t, v->processor); + + return 0; +} + +void vcpu_timer_destroy(struct vcpu *v) +{ + struct vtimer *t = &v->arch.vtimer; + + if ( t->timer.status == TIMER_STATUS_invalid ) + return; + + kill_timer(&v->arch.vtimer.timer); +} + +void vtimer_set_timer(struct vtimer *t, const uint64_t ticks) +{ + struct arch_vcpu *avcpu = container_of(t, struct arch_vcpu, vtimer); + struct vcpu *v = container_of(avcpu, struct vcpu, arch); + s_time_t expires = ticks_to_ns(ticks - boot_clock_cycles); + + vcpu_unset_interrupt(v, IRQ_VS_TIMER); + + /* + * According to the RISC-V sbi spec: + * If the supervisor wishes to clear the timer interrupt without + * scheduling the next timer event, it can either request a timer + * interrupt infinitely far into the future (i.e., (uint64_t)-1), + * or it can instead mask the timer interrupt by clearing sie.STIE CSR + * bit. + */ + if ( ticks == ((uint64_t)~0) ) + { + stop_timer(&t->timer); + + return; + } + + if ( expires < NOW() ) + { + /* + * Simplify the logic if the timeout has already expired and just + * inject the event. + */ + stop_timer(&t->timer); + vcpu_set_interrupt(v, IRQ_VS_TIMER); + + return; + } + + migrate_timer(&t->timer, smp_processor_id()); + set_timer(&t->timer, expires); +} -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:47:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:47:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211352.1522948 (Exim 4.92) (envelope-from ) id 1vixqb-0000cM-Rg; Thu, 22 Jan 2026 16:47:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211352.1522948; Thu, 22 Jan 2026 16:47: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 1vixqb-0000b5-Jm; Thu, 22 Jan 2026 16:47:53 +0000 Received: by outflank-mailman (input) for mailman id 1211352; Thu, 22 Jan 2026 16: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 1vixqa-0007Ij-2q for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:47:52 +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 165fde96-f7b2-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 17:47:50 +0100 (CET) Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-b7cf4a975d2so162741766b.2 for ; Thu, 22 Jan 2026 08:47:50 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b879513e951sm1686014966b.7.2026.01.22.08.47.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 08:47:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 165fde96-f7b2-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769100469; x=1769705269; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=nhPCPrLN9zev/AujtYrNqtpuJ2Oszmh0GkcNP2XIraQ=; b=MYuuD2FrcDYLOF7v8v1l0WHSzgCRmUPD5ey1IAaXSYD50YGGUBtss480sDNr37bfHl 4N0VjrFSuSPaNEoig8DmOSFevbVcjR3oXum3S1RJis7edCOLgxEfNbTylWVmSi13aWPd bzBgHHfc5K27V5iqUvhh5Gg7rcqLLeG0g5aBpetxWoI9UQS4tRLHErQ1xCCV+93ioTDZ tNxg8JwPH/aNO2s1QLna5+ePZ2voeuV3ANlOsF6N9E5wdmgHhz+i21+lcPdK0oGOqV3k 7pvyqxoGQdweItxgHKXalpI8IZ7t/BKSA+VfSVErnQw2SpdqveEZD4nKQ3oAUriB9kFY a+Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769100469; x=1769705269; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=nhPCPrLN9zev/AujtYrNqtpuJ2Oszmh0GkcNP2XIraQ=; b=kvZt+ECwv5gpsi8O1EiCnaMlucE8KFojUvnyMlX1f27IuqMhiTu73WN7pTzkcm7lak X/zlHHhTu0ZZHDRrOAyyxOk8fsVhMrQ4ZYsSETphCnzaJhXCNsLBrNU44Ko1Sxx/o/YA p04TZnRVM/wMK8aDEFvif6mEc7XEZycqE1ksm6M6VOoUQ+BKY1lWUfySeviHtYrHsT7L yUzh37rc6lsnkIBJVUVOo2D8OW4gXf4MwiE9ElRsIL8OUUt7vKyiX65qCd+Fu55KO4/v nqEsk+V4m6b5UQt7szlJWnjwQC9gvzElHc9Ip8O9PJa8iv0HKoYG0oMFVadPUduG+9uR b7Ow== X-Gm-Message-State: AOJu0YwhpS4beNgg/rGhTD2lvnmSm/ZpEaJHTh5zjOWa2/QY4kgy60LX bXNYElU7fhDvADR1o2L9CyHSU98jr8EuW7vyEopDhcpRk9yZU0DCf3XY+ayFwQ== X-Gm-Gg: AZuq6aJdAYih20fhC5sUtXQVBAql9lD28MnruizlXm3l+QqRd6966EPiAw/+yO3tLVA QU9vgNdwh3Btr12EHkW7HJCaOEb0hUbUzQ5QcsayqEV3Hmt3kMO2Q7og/BLSx7gfZo/Eh/kcIrI Uvqs4Y0jA16qA38tu6cqN23EHRLE+uAdVBrBFqyWdDrN2LLrbL46AoeLMvklfOHqMcJ1oO4xACq OC1NX8K66VvrtM8AV8+UM4UEpaauP59S/dS8B20KGz5bnVNuHh2YYN+8Cb1Qc9SF5F1JNM1zjgR Ocom0irAsl4aXHREa2rpN+u89IOEPVH2d0sBPbaBwztflBLGOpnmV8KtAupeB1AgmIbtyi61Pyk tvB7XN21iRrFObxZve7u0fFT+FSoVWXBFKrfwQMMcRTScFcZaQWxGHVDTNL/8fzAzgR2nNjIRNg SUlEG5MaZifYES61R2yInbPy8b33ynUjTZk/TtX1nmZGHzlK5Q1Qi6Rg== X-Received: by 2002:a17:907:7250:b0:b87:3c4a:e68f with SMTP id a640c23a62f3a-b88003423b0mr654314366b.36.1769100469187; Thu, 22 Jan 2026 08:47:49 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Romain Caritey Subject: [PATCH v2 08/16] xen/riscv: add temporary stub for smp_send_event_check_mask() Date: Thu, 22 Jan 2026 17:47:23 +0100 Message-ID: <062dbab8751bd0c27b913ce78de3a3eeb0ffe22f.1769099885.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit RISC-V SMP support is not yet implemented, but smp_send_event_check_mask() is required by common code and vcpu_kick(), which is introduced later. Provide a temporary stub implementation that asserts the mask only targets CPU0. cpumask_subset() is used instead of cpumask_equal() because some callers (e.g. cpumask_raise_softirq() or cpu_raise_softirq_batch_finish()) may legitimately pass an empty mask, which would otherwise cause false failures. The BUG_ON() ensures that attempts to use this function with multiple CPUs are caught early once SMP support is introduced. Signed-off-by: Oleksii Kurochko --- Changes in v2: - use BUG_ON(cpumask_subset(...)) instead of "#ifdef NR_CPUS > 1". - Update the commit message. --- xen/arch/riscv/smp.c | 7 +++++++ xen/arch/riscv/stubs.c | 5 ----- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/xen/arch/riscv/smp.c b/xen/arch/riscv/smp.c index 4ca6a4e89200..d645364ea47d 100644 --- a/xen/arch/riscv/smp.c +++ b/xen/arch/riscv/smp.c @@ -1,3 +1,4 @@ +#include #include /* @@ -13,3 +14,9 @@ struct pcpu_info pcpu_info[NR_CPUS] = { [0 ... NR_CPUS - 1] = { .processor_id = NR_CPUS, }}; + +void smp_send_event_check_mask(const cpumask_t *mask) +{ + /* Catch missing implementation once SMP support is introduced */ + BUG_ON(!cpumask_subset(mask, cpumask_of(0))); +} diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c index 9e30a9a3b50b..c5784a436574 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 smp_send_event_check_mask(const cpumask_t *mask) -{ - BUG_ON("unimplemented"); -} - void smp_send_call_function_mask(const cpumask_t *mask) { BUG_ON("unimplemented"); -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:47:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:47:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211354.1522955 (Exim 4.92) (envelope-from ) id 1vixqc-0000jd-MM; Thu, 22 Jan 2026 16:47:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211354.1522955; Thu, 22 Jan 2026 16: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 1vixqc-0000is-9I; Thu, 22 Jan 2026 16:47:54 +0000 Received: by outflank-mailman (input) for mailman id 1211354; Thu, 22 Jan 2026 16:47: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 1vixqb-0007Ij-39 for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:47:53 +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 1718468b-f7b2-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 17:47:51 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-b876f3f603eso174720766b.0 for ; Thu, 22 Jan 2026 08:47:51 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b879513e951sm1686014966b.7.2026.01.22.08.47.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 08:47:49 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1718468b-f7b2-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769100470; x=1769705270; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=+bOmIXS7ukX07+v1FZwQcpO5Pv22L8b7W5Nzbqzk3MM=; b=Z56vXmNe0vZFGbiPjeQexcThGbP8NxeeLpnxV6YndwGnLUxx9Q46EDgVFU9Z8M8e7s HynSDVdmefqwWa18Y+n9yfTSAliiSRU35bu9kGc1iGQdo06xiB6jjWoQnHRhtyN+iAvw ny3I4pWBT0EIsKmWypu1rL4XjTclOrM/mvGehOS+Vzv+VvtlkPOSlR7p1mnLJrNOrv14 1UjM/ozgmm2j4one+o5LiI+KtMewX5U3RlvBA7VpXLdmrtQCRzwusQjo9/xXXgUhtUZU 08lQNDK5RW+Pi9gSGGn/6npbyH5jEDfGZup1QNskSV0CiLDCnKio2Ju82qtHA+/jMSB6 Y94A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769100470; x=1769705270; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=+bOmIXS7ukX07+v1FZwQcpO5Pv22L8b7W5Nzbqzk3MM=; b=hoxYf7+WKNChiix5c00LemQyNKebb51flxfOXlgfU64bDAN+uGDxxjZs9V1Q6zmeTN 4ZMxP5tG20bfta5RQM80hdC+Kb0+mFHMcvNyIdSV4s649HjftRrTOsD47sxIvoKLnmM/ f2D77zSLf/dcmTCEwjTO2tUFlqqFOt1UsFR4x+AbPECoWZXZCPTeZ40G2RqNCqM0buiD UeRnaqsv9TwahYrR1URiOjHUn+JUoFpuEdi+ewvyjzhjZe3P6Yg34olTYwZYOrrj+I+s WDBPo456RA7oR2kOb+o2bwsv5JozjF3iHGlotrevoGqMCaoT25kHvt7ZME7hiDtKLkwQ yrGA== X-Gm-Message-State: AOJu0Yzd+GE3oMnbSFsrUK3shf1YN+mY1RbtwLEj9GDpCxFFhxz6CR5X f1AOMCf74aPUHUqmJB0dP0UpWMlWHLuYbYE1WuzgwRsIYUl+6EXFakG147me9A== X-Gm-Gg: AZuq6aLnnmsXDCvKpq0IwcHYvjVJER95U8YgkDPQFajN9JPLDgAG7cS7Jt6uecnb50L P19CuGZSbqyXC1DTN3sIa843rpOTcUtEQkkrQKpXXFFrWVj6zoQ9Anmbni8wltATDqjqhaAxxjf HgENvcTyg5UjExuNBrMPkjVirzXrKiJ926jRZdW6B7wKikAGvJDq25VYxZPIX/WvV7QuXiKrhC/ 54BhzMb1Pmf3HrGHjnSkZ5mJtVP9S/Plcn4otzFbBvCyHPKvbPHDHNeB0w63KV0/HBeDoQX1IW8 0OcF7CyttVKeY1PHRt2DuObjrj/rH2zSbl3MkqwR0CXdAfomEqxrGtch24eULmgLc9n5yUk34ci Nb2pWCWR6rSXImrhx8O4U/nmcqqZ82J5PXJvwmYJlou/LC3fT6kFx3/y827aFF3gd3fM1CGEnVW URixcGCFGtG4xu+LGpgQRk7CNyLP5JD1QtSmofzByIW3LRBdxUY5I8Bw== X-Received: by 2002:a17:907:8dc3:b0:b88:587f:f594 with SMTP id a640c23a62f3a-b88587ffb0cmr29524266b.18.1769100470277; Thu, 22 Jan 2026 08:47:50 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Romain Caritey Subject: [PATCH v2 09/16] xen/riscv: introduce vcpu_kick() implementation Date: Thu, 22 Jan 2026 17:47:24 +0100 Message-ID: <0335a7db0343d81ce4256482a464e7ba5df1c204.1769099885.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Add a RISC-V implementation of vcpu_kick(), which unblocks the target vCPU and sends an event check IPI if the vCPU was running on another processor. This mirrors the behavior of Arm and enables proper vCPU wakeup handling on RISC-V. Remove the stub implementation from stubs.c, as it is now provided by arch/riscv/domain.c. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v2: - Add Acked-by: Jan Beulich . --- xen/arch/riscv/domain.c | 14 ++++++++++++++ xen/arch/riscv/stubs.c | 5 ----- 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index e38c0db62cac..13ac384c4b76 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -1,8 +1,10 @@ /* SPDX-License-Identifier: GPL-2.0-only */ +#include #include #include #include +#include #include #include @@ -240,3 +242,15 @@ void vcpu_sync_interrupts(struct vcpu *v) # error "Update vsieh" #endif } + +void vcpu_kick(struct vcpu *v) +{ + bool running = v->is_running; + + vcpu_unblock(v); + if ( running && v != current ) + { + perfc_incr(vcpu_kick); + smp_send_event_check_mask(cpumask_of(v->processor)); + } +} diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c index c5784a436574..1f0add97b361 100644 --- a/xen/arch/riscv/stubs.c +++ b/xen/arch/riscv/stubs.c @@ -208,11 +208,6 @@ void vcpu_block_unless_event_pending(struct vcpu *v) BUG_ON("unimplemented"); } -void vcpu_kick(struct vcpu *v) -{ - BUG_ON("unimplemented"); -} - unsigned long hypercall_create_continuation(unsigned int op, const char *format, ...) { -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:47:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:47:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211355.1522971 (Exim 4.92) (envelope-from ) id 1vixqe-00018n-7T; Thu, 22 Jan 2026 16:47:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211355.1522971; Thu, 22 Jan 2026 16:47: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 1vixqd-00016a-M5; Thu, 22 Jan 2026 16:47:55 +0000 Received: by outflank-mailman (input) for mailman id 1211355; Thu, 22 Jan 2026 16: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 1vixqc-0007Id-1p for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16: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 18716147-f7b2-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 17:47:53 +0100 (CET) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-b8707005183so195855266b.0 for ; Thu, 22 Jan 2026 08:47:53 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b879513e951sm1686014966b.7.2026.01.22.08.47.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 08:47:52 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 18716147-f7b2-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769100473; x=1769705273; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=yFNz2eINTf9rVU++UNSQJpwAORPoMimHJyiwu4QoyIk=; b=B39nKBiuAKmmI+eUiNNlVTEPXbQ12gOBTMtFDuNLQJ5/mvfGEJuCm2B5DCNwtg1GVc 1lvvlKIV7sLpLNKDQlnkBypxYCWQ/1HuIQdUcGfYSZ5C9conPZybhk0ceR1f+OiiqThz YWKRV8tV/PL+CTy9AkZmHuslYND5RIs9KLN+AVgRS7OnVcoG44VIdykx9Jr8JKZE3fXi I87TyyJDnZzhoNODZNLG7Fy/bAs3DESXYRafUjp8zxUX+PxobPeQwtkP0Fyd8pRFr4N+ hkNVxnFSCiYdsPjRzXueyXEQTpHe30YvwT9PMvpe7xVKyN3hceeSJJcVZLeq/a6Av2kv teJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769100473; x=1769705273; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=yFNz2eINTf9rVU++UNSQJpwAORPoMimHJyiwu4QoyIk=; b=lqmCTUe5TfUSnK1Bu2NVpEMAIXt6yKeCjFsL2ZYTPjhf1BpXIRLKmeTWiGFm8cqbkc fG6FEIq0D6olP/U2bUHIWmRDCPLdJc5D7bshuhGWdNuqKI+Z3NN9i2Ed7zob7wDNcR2Y PpylVGECn4H/HhptWnklarHDhuazzCCS74iVTMBKrElnSLuKL/8QJYUVy/AQtvH7Lnah MJK7dC1FriSdxvYBRAmQmzR9sMP9uaDQQs0UYfPPsssVpTJG5lgoGnvKVW/Aq4etLGX4 qaMWxE8mw4YiKiUZrVPcD9IKPx8EndbSJfv5JM2anXkVv1jB20mUgfMmbX6FWbM6E5sA LkVw== X-Gm-Message-State: AOJu0Yzp3mStcLV3m5ACHpGazRmxwb/qvxAjUaQp+Xc9C/++d6WyRDYI QtTL7P2jwSVvxiYlkwAkZ8W5MhVlWaDblUIDtqwzhORHP1xzGwAmkYaBye8anQ== X-Gm-Gg: AZuq6aII4n9OtrDtGADr8gZeUN+c9TqpK31qmZPkk+lym1dcBuOUpjroEmNny2SEPJM k24r5KhlcjUwfbfq5/0NY6kFWQgi42Mj9GRv+qSNjI0FwsrGy8JqE/BM9iGUSZL5DMj0xak1qIS 7UWihf3xQRUlFMQg7KIes5jCRUrmDVHfPFzJHJv6EFqmp9MLn4iZI8wrz5sTxCYT1xD0cEUSlGz 1IAWuaVfwa0CELRzHmFcTOH8EMqm3f+mn09BmY8RPO4i0isXZlavNQhz4s7+gOQIdpnv+cGytDM nt5R1M1yd1vSP2cWgOFmXhwrWJ9yLB4yaEcslRAfinQaNKD9s3cEMkggcnnkQVMs46P5E5emIuN KM4lnm+0Oo6MleJkPwT3dzoK025AI6QwgJ0zAKbtr50jVWFo4cVTTlwfWxdRNMoCr+foyHNdSDd QDnUZJ7H49pMLX5DtABkmY/8h0Kqyopxj7B6B/EfJce5Ii/INpQKYvGKnfGNj8NJF1 X-Received: by 2002:a17:907:7256:b0:b84:40d3:43e6 with SMTP id a640c23a62f3a-b8792e0b88fmr1732932566b.6.1769100472698; Thu, 22 Jan 2026 08:47:52 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Romain Caritey Subject: [PATCH v2 11/16] xen/riscv: implement SBI legacy SET_TIMER support for guests Date: Thu, 22 Jan 2026 17:47:26 +0100 Message-ID: <0cca5db24ac772b1d1145e189b26ace63ef9a58d.1769099885.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add handling of the SBI_EXT_0_1_SET_TIMER function ID to the legacy extension ecall handler. The handler now programs the vCPU’s virtual timer via vtimer_set_timer() and returns SBI_SUCCESS. This enables guests using the legacy SBI timer interface to schedule timer events correctly. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v2: - Add Acked-by: Jan Beulich . --- xen/arch/riscv/vsbi/legacy-extension.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/xen/arch/riscv/vsbi/legacy-extension.c b/xen/arch/riscv/vsbi/legacy-extension.c index 2e8df191c295..090c23440cea 100644 --- a/xen/arch/riscv/vsbi/legacy-extension.c +++ b/xen/arch/riscv/vsbi/legacy-extension.c @@ -7,6 +7,7 @@ #include #include +#include static void vsbi_print_char(char c) { @@ -44,6 +45,11 @@ static int vsbi_legacy_ecall_handler(unsigned long eid, unsigned long fid, ret = SBI_ERR_NOT_SUPPORTED; break; + case SBI_EXT_0_1_SET_TIMER: + vtimer_set_timer(¤t->arch.vtimer, regs->a0); + regs->a0 = SBI_SUCCESS; + break; + default: /* * TODO: domain_crash() is acceptable here while things are still under -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:47:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:47:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211359.1522985 (Exim 4.92) (envelope-from ) id 1vixqg-0001mB-C5; Thu, 22 Jan 2026 16:47:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211359.1522985; Thu, 22 Jan 2026 16:47:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vixqg-0001l5-6T; Thu, 22 Jan 2026 16:47:58 +0000 Received: by outflank-mailman (input) for mailman id 1211359; Thu, 22 Jan 2026 16:47: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 1vixqe-0007Id-MB for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:47:56 +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 19f3d528-f7b2-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 17:47:56 +0100 (CET) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-b884ad1026cso100380366b.2 for ; Thu, 22 Jan 2026 08:47:56 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b879513e951sm1686014966b.7.2026.01.22.08.47.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 08:47:54 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 19f3d528-f7b2-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769100475; x=1769705275; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=7mbSVBQ+1aSN6DFc+pj8xuW2JrsfZRnVra8JiKBPkJ4=; b=ezhrY/ovYEQzxYAmZDG4qvkObWVczVuGVDemzRpF0LFHcxXuCNJZiu8DD7wunJ1sLL gpGup3A0FzEZsJQjBJnOviFCpbYp+tOeRmq1C5i5gFsK3VAmYKFHbMtTYxeM/oUCjZN6 NA/I43pcupB/+dikZrXJNI8Jfe9aBbO/PjBLA+6NbcRGXya/HCqK4xYu1hdQyWw7bDzT pwCqNlRdmQvLenozUdZzimWjTgsqBCY/kk0FyaX+7b0F2RHC7tEW4KG4v30OhKetgYQW JpSc+yS3ahlQgEY3fRYOPohWXuK6iO//r3eKcwfnqMOcZYK1Z+bOkjP9eZR3AIANQ4oW M2VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769100475; x=1769705275; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=7mbSVBQ+1aSN6DFc+pj8xuW2JrsfZRnVra8JiKBPkJ4=; b=GFQbunULDnRiZibAqSyAdpxNy/5FH4QJlPBhb6y0UfF7t+cAl2UvcYoZ0x8ehoZYB4 QZSwFMOchhlCzANzAIYAjm3UWqOH7kG83yidcib6lDD5zdv3l83yihy65jXGZOGkNhux LntmqehzuEzpnawPFYnzaTm6q01l1AoJV16UmiVYjNoz5aSuIJs4Q9kcHyUYj8G20OkS 6lGXtCZXXMS8j2HLv9yUF4xhv2mnyvkgXqL5uGQG8PosEuvIlrQ7yeHuaw15xiFKqkiU 6Q1ovr0sUEzXPsSpMTttAxKCgcAqefb3XKH8/7E0o5OGIeWtvAoBHKF5P1ACmdfWhP1t ynBQ== X-Gm-Message-State: AOJu0YyN9kkke2EnF/d+4z+k5oitrrvfTJ8Ekpk9R7WmILgLEAHngZXD vakzueRZ9n3Novb9icntRB/5BYYJJdGxLkVjdSirmukvw62a2uXdE5zarqkNaA== X-Gm-Gg: AZuq6aIvp4VXgmtU1woZ9uqsg1euElExR0wo0E/Nw+YKybnpWRzgfvv3xVJ5aeQImW0 yA6KuRJbIN+sqb3M4lXItDWyeRgDbqbu66qKOmCU9jQ8XInmEzoQ/VUR5iN6euMl7bVPxAELoD3 wte2waGOkMonGkDOVc8aFczkdqwDVne5gV7doBEDzslWFalcis5Ip1PDb7oOBqDqy4rRQMtMJrf jvMLd2w11M6UKlq1L0hEDmJNxHmO6TJT5K4DSVIL9q+10m+PBeIZiiIjdcDmeVXBHgPnHNWpaP2 /a5ajNL/vMJUiT/1RLa8512kdIaBin8bruGVybHovu5marHQ6eL/Qq8xgRZR7BKfIQn7le9Rl34 sxZbqS+vAj3o2t+gQpo+VTPPGOarJb8WS17CrziUrlajShNMEUzlzCwqRYYuNkLDKDmtnNAZdu7 1JcN4OhznPviXs9SWkXMGDJbbNPqCyavg2tdo9M8ZUO25raD3gnUNHEw== X-Received: by 2002:a17:907:9805:b0:b83:6e2b:890d with SMTP id a640c23a62f3a-b8800434127mr752883766b.25.1769100475180; Thu, 22 Jan 2026 08:47:55 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Romain Caritey Subject: [PATCH v2 13/16] xen/riscv: implement reprogram_timer() via SBI Date: Thu, 22 Jan 2026 17:47:28 +0100 Message-ID: <732635f43fb80daec332f78d4442b56bf5dfda98.1769099885.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Implement reprogram_timer() on RISC-V using the standard SBI timer call. The privileged architecture only defines machine-mode timer interrupts (using mtime/mtimecmp). Therefore, timer services for S/HS/VS mode must be provided by M-mode via SBI calls. SSTC (Supervisor-mode Timer Control) is optional and is not supported on the boards available to me, so the only viable approach today is to program the timer through SBI. reprogram_timer() enables/disables the supervisor timer interrupt and programs the next timer deadline using sbi_set_timer(). If the SBI call fails, the code panics, because sbi_set_timer() is expected to return either 0 or -ENOSUPP (this has been stable from early OpenSBI versions to the latest ones). The SBI spec does not define a standard negative error code for this call, and without SSTC there is no alternative method to program the timer, so the SBI timer call must be available. reprogram_timer() currently returns int for compatibility with the existing prototype. While it might be cleaner to return bool, keeping the existing signature avoids premature changes in case sbi_set_timer() ever needs to return other values (based on which we could try to avoid panic-ing) in the future. Signed-off-by: Oleksii Kurochko --- Changes in v2: - Add TODO comment above sbi_set_timer() call. - Update the commit message. --- xen/arch/riscv/stubs.c | 5 ----- xen/arch/riscv/time.c | 43 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 43 insertions(+), 5 deletions(-) diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c index 1f0add97b361..cb7546558b8e 100644 --- a/xen/arch/riscv/stubs.c +++ b/xen/arch/riscv/stubs.c @@ -21,11 +21,6 @@ nodemask_t __read_mostly node_online_map = { { [0] = 1UL } }; /* time.c */ -int reprogram_timer(s_time_t timeout) -{ - BUG_ON("unimplemented"); -} - void send_timer_event(struct vcpu *v) { BUG_ON("unimplemented"); diff --git a/xen/arch/riscv/time.c b/xen/arch/riscv/time.c index 2c7af0a5d63b..f021ceab8ec4 100644 --- a/xen/arch/riscv/time.c +++ b/xen/arch/riscv/time.c @@ -7,6 +7,9 @@ #include #include +#include +#include + unsigned long __ro_after_init cpu_khz; /* CPU clock frequency in kHz. */ uint64_t __ro_after_init boot_clock_cycles; @@ -40,6 +43,46 @@ static void __init preinit_dt_xen_time(void) cpu_khz = rate / 1000; } +int reprogram_timer(s_time_t timeout) +{ + uint64_t deadline, now; + int rc; + + if ( timeout == 0 ) + { + /* Disable timers */ + csr_clear(CSR_SIE, BIT(IRQ_S_TIMER, UL)); + + return 1; + } + + deadline = ns_to_ticks(timeout) + boot_clock_cycles; + now = get_cycles(); + if ( deadline <= now ) + return 0; + + /* Enable timer */ + csr_set(CSR_SIE, BIT(IRQ_S_TIMER, UL)); + + /* + * TODO: When the SSTC extension is supported, it would be preferable to + * use the supervisor timer registers directly here for better + * performance, since an SBI call and context switch would no longer + * be required. + * + * This would also reduce reliance on a specific SBI implementation. + * For example, it is not ideal to panic() if sbi_set_timer() returns + * a non-zero value. Currently it can return 0 or -ENOSUPP, and + * without SSTC we still need an implementation because only the + * M-mode timer is available, and it can only be programmed in + * M-mode. + */ + if ( (rc = sbi_set_timer(deadline)) ) + panic("%s: timer wasn't set because: %d\n", __func__, rc); + + return 1; +} + void __init preinit_xen_time(void) { if ( acpi_disabled ) -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:47:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:47:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211360.1522990 (Exim 4.92) (envelope-from ) id 1vixqh-0001u9-A0; Thu, 22 Jan 2026 16:47:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211360.1522990; Thu, 22 Jan 2026 16:47: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 1vixqg-0001t0-R9; Thu, 22 Jan 2026 16:47:58 +0000 Received: by outflank-mailman (input) for mailman id 1211360; Thu, 22 Jan 2026 16:47:57 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vixqf-0007Ij-3e for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:47:57 +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 17c12453-f7b2-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 17:47:52 +0100 (CET) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-b7cf4a975d2so162748366b.2 for ; Thu, 22 Jan 2026 08:47:52 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b879513e951sm1686014966b.7.2026.01.22.08.47.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 08:47:51 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 17c12453-f7b2-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769100472; x=1769705272; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=bossoBnEH4JNpm3EBQfuiRI4dS6yLi1VOSzTCCzzE2k=; b=ajLOboWcatoihKUlCyAOFvjWaybErVFl6cMz/RNu6GmVGCuXlmZ0cK9RQCPgEWGNmc HYBLyP+t9mODCJ0HnzZIkS6R3UkJvuTqCHyrLSJCXdvzcLb+1X5fXLXNnps/AxgEbr0b 81y+lNVE/FnF+YQzlO5YWXpHmY9p+71yTQkMRTx3oq9QTzhbdm/ThUJEV8kQ2/De8eke GEUx5SpguF0lWb54lsi+XxRa1vrztdOCUOvKbtI5qQ0nEMnn9pOJgUpcT5oDiK0N0ks0 PgH3+rcCxBYa4PyMKI1DhWglPNmqIVq5VnHRQtaGnPt+AaULMxRUH0C0puGV7PfBV88V AQTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769100472; x=1769705272; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=bossoBnEH4JNpm3EBQfuiRI4dS6yLi1VOSzTCCzzE2k=; b=XU3UDJiA/higxnfdlrGQsQOX4bBcgVh9q6NfF7W9J/Kfo8dZC0xhcffiUB/jGT+CP2 SZuINAxx+2k2FIWMnnZiwoRa/bismN+EzBNOufRLWTCE1arIEA/vyIciZEvtvQ3Rp7EB PJxesCQx/Rfsve5dfcy4MZUtnlo84dEyzQC266ODd3aVPQw99gFiGNCE1UT2O7NJqACy Li3Wc3qz2qdT8QXWyWSpCI2VVeZVeB71iZJ+W6YuncDmswLBd0/j9cYThPuxQP66I/+X 9y4QIPEf/2kQ3SACFCX3L1cLadGiG/483a3m+PMWDmdw5FbMCPy/Pe8j+E5pMmGT4wx3 sb0g== X-Gm-Message-State: AOJu0YwE3338lL1xbgE2FeiW+C42UQwUNK4seGiX9cPowfA0oo/OS8fv iQQJLGV79hXt2q+HzV3+usKBbN+Qba94wCsuEsjhFnThXzAMmW7dEtxaBFl6fA== X-Gm-Gg: AZuq6aJ/t3xAAFRzUOVvfzTRSBixsKeVxahr/AwYCvtO28ccYYrfYkmqB19M1rUnFYS dPFarajGt4EHZeOvlkCr1X3LVSpbpDvairl9AY6QIEuK1weNZqhCrz+OH6IsZX+Gl+Jpt74BdkD ybXvdbmbWEmDCt3VePGoYGzVRFurRM7dv6MF6VY+XFrsF93ynOOZ0um0SSFvFSJrILZUlT+4oD2 5H/O3sCL3lMZIVQVAHTZrMFl/Bi5WHVayVENmcZfBCUqvQxfFJM/9Czy4HJGOe13Qc2RyPDW3fY 6ctr/3AflOvrBr0p5f1jfoTskdBRtb1iouhQUOIs6r42eWCcKevMFxow7oxhkBSJFFhqYvJt0lb 7SFlxBS83OPi/+YOxmkMAS7dwprciKszrOg7ozdx8CB9y05vPPljjXVTx+rWlCo+6fPxuPNfXk2 nuEvVZ3FoQT9pW8vCnZ213h3PKyCgKstXigHgeRiNnh/iBEV/fTjzK4A== X-Received: by 2002:a17:906:f5a5:b0:b80:149b:badd with SMTP id a640c23a62f3a-b8800342b42mr751480066b.37.1769100471595; Thu, 22 Jan 2026 08:47:51 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Romain Caritey Subject: [PATCH v2 10/16] xen/riscv: add vtimer context switch helpers Date: Thu, 22 Jan 2026 17:47:25 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Introduce vtimer_ctx_switch_from() and vtimer_ctx_switch_to() to handle virtual timer state across vCPU context switches. At present, vtimer_ctx_switch_from() is a no-op because the RISC-V SSTC extension, which provides a virtualization-aware timer, is not yet supported. Xen therefore relies the virtual (SBI-based) timer. The virtual timer uses Xen's internal timer infrastructure and must be associated with the pCPU on which the vCPU is currently running so that timer events can be delivered efficiently. As a result, vtimer_ctx_switch_to() migrates the timer to the target pCPU when a vCPU is scheduled in. Signed-off-by: Oleksii Kurochko --- Changes in v2: - Align the parameters names for vtimer_ctx_switch_from() and vtimer_ctx_switch_to() in declarations to match the ones in the defintions to make Misra happy. - s/vtimer_save/vtimer_ctx_switch_from. - s/vtimer_restore/vtimer_ctx_switch_to. - Update the commit message. --- xen/arch/riscv/include/asm/vtimer.h | 3 +++ xen/arch/riscv/vtimer.c | 15 +++++++++++++++ 2 files changed, 18 insertions(+) diff --git a/xen/arch/riscv/include/asm/vtimer.h b/xen/arch/riscv/include/asm/vtimer.h index 0d1555511755..52b7fb7b1cbb 100644 --- a/xen/arch/riscv/include/asm/vtimer.h +++ b/xen/arch/riscv/include/asm/vtimer.h @@ -17,4 +17,7 @@ void vcpu_timer_destroy(struct vcpu *v); void vtimer_set_timer(struct vtimer *t, uint64_t ticks); +void vtimer_ctx_switch_from(struct vcpu *p); +void vtimer_ctx_switch_to(struct vcpu *n); + #endif /* ASM__RISCV__VTIMER_H */ diff --git a/xen/arch/riscv/vtimer.c b/xen/arch/riscv/vtimer.c index b6599fa383b8..6dfd6d836260 100644 --- a/xen/arch/riscv/vtimer.c +++ b/xen/arch/riscv/vtimer.c @@ -1,5 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0-only */ +#include #include #include @@ -71,3 +72,17 @@ void vtimer_set_timer(struct vtimer *t, const uint64_t ticks) migrate_timer(&t->timer, smp_processor_id()); set_timer(&t->timer, expires); } + +void vtimer_ctx_switch_from(struct vcpu *p) +{ + ASSERT(!is_idle_vcpu(p)); + + /* Nothing to do at the moment as SSTC isn't supported now. */ +} + +void vtimer_ctx_switch_to(struct vcpu *n) +{ + ASSERT(!is_idle_vcpu(n)); + + migrate_timer(&n->arch.vtimer.timer, n->processor); +} -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:48:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:48:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211363.1523002 (Exim 4.92) (envelope-from ) id 1vixqj-0002PV-AZ; Thu, 22 Jan 2026 16:48:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211363.1523002; Thu, 22 Jan 2026 16: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 1vixqj-0002Mo-4B; Thu, 22 Jan 2026 16:48:01 +0000 Received: by outflank-mailman (input) for mailman id 1211363; Thu, 22 Jan 2026 16:47: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 1vixqg-0007Id-Mo for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:47:58 +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 1a95e4e3-f7b2-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 17:47:57 +0100 (CET) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-b872cf905d3so179241566b.2 for ; Thu, 22 Jan 2026 08:47:57 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b879513e951sm1686014966b.7.2026.01.22.08.47.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 08:47:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1a95e4e3-f7b2-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769100476; x=1769705276; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=TbDTiLjWuEzC7c6gqH8qnfrVym3BHTcxish5wSxW7l4=; b=CWdIITF/ZXYEDHdxzK1vj5zcXRYOy2bi/7+MRf0NuKpED8XisHUwoela6pvnuCjcpg uXUrpvZwUSzGoa2ibDfHRkfkftdDRhg4htBZl7t8uMznGeMqmDt0YTRx/6b/3RkcPWXr 6fz15NaeICVHYAHVsF8lXkPS2GdLFGpQMKZxdM/tT7x//UhziauLyCf0FwZLr4Xz7jsf svXJ2qtKdJ6KqWPY362vGJn+Hg8ZrfFPA9FAiZTqBuALTqRPqT69hsyC9QwD1D03p42z MNNllLPrmnkSY2fYzXrPNlQfH6FpS0fG8YkPnRLXzfoh+UmV0HTPMXQogA2pghfCQAh9 qsXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769100476; x=1769705276; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=TbDTiLjWuEzC7c6gqH8qnfrVym3BHTcxish5wSxW7l4=; b=CKyHW2rXrnTRUJeoeBDI27XYMCqsZdftKEglnZjZDfEjgllbqi1jYy8AmmmeCaL7Ik 3/XUANT9to0+HjGGm8sQ02cqQAP0qFkZKGSTAQvvu1WNq/R5jfU+lGIvuNK4xOgbqwsG hndLJgrLdRkYkviJLwkId06sJaCxB4kIf0lsVMcEwPcrQZsHA9TKIiBfRBc/UIq2GmXy oRaKatEuQSG+dBVrRHWQNpXp9xBSjFdYGtnJIpCCszNhM7A+uwhbcN8fbVoU7ejkaKtc /iRMyx6W3BV34O/0BHAzIhhfQlIBaKs7dMwtj4PlNXOVJwJ9NiizuaE0MXnfVbsofOyU Aqfg== X-Gm-Message-State: AOJu0YxYDi5qMkBQqt2Q5E6P03J1HAxyw/0KND0kJH9gwM+Gd9ofPJen cETb2n6wWd1KGYAkq3DCqGGwJ/gEyg+PENY8HGfe9JmpC0cXRy4sM+9ul1B9ig== X-Gm-Gg: AZuq6aIW9w+6Pc67hjhF/GHnNqgOJSJp643acRmfEH8GPd3f/GUiLFViBkALcaKcwk/ MPF1eONdBBu/6E+uqyz4nRk16ozXMwnRReHZ4VK9RExbgnqo33Cx/eXStn/pAGE0n9bO0P5rVAZ xjdsWkFGATHxCLL+Y9kUIhomYbYn9tEXWpMY812U/P9CFQ3TmZKoTIBA3f38wRi26k9DxBGHWsZ XgAiBxM7/8vAFDRyCVIcVHUVQ3krZ9ec33ySR89jZeMPSaFskyWtkHDoNKLfvLnaeQEsz5Mf7sn PuRuR4tA84ZxGZHb3sZqlDM7TSt7wgGQZHl4b3brLLW1BOnyTbO7az4WakceugQpeGIOHqxhOA8 To7sXXZyUZBvnIjLv13xPjdZ9yRB4S8+/apcJ17TnQmRH4Zeh6Lysm9/9KIYWUoRwNGt3bTmJQe UfjPXR+VYXH5ngLEPf4WHZq0ByC6mR7ydyjNqxIWdyMsfaZh1f/VxBY3RnVpQBFytj X-Received: by 2002:a17:906:6a14:b0:b87:173f:631 with SMTP id a640c23a62f3a-b87968e76e5mr1734061466b.25.1769100476195; Thu, 22 Jan 2026 08:47:56 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Romain Caritey Subject: [PATCH v2 14/16] xen/riscv: handle hypervisor timer interrupts Date: Thu, 22 Jan 2026 17:47:29 +0100 Message-ID: <5028577821754b86f633bedb0c32f5490ab6452c.1769099885.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Introduce timer_interrupt() to process IRQ_S_TIMER interrupts. The handler disables further timer interrupts by clearing SIE.STIE and raises TIMER_SOFTIRQ so the generic timer subsystem can perform its processing. Update do_trap() to dispatch IRQ_S_TIMER to this new handler. Signed-off-by: Oleksii Kurochko --- Changes in v2: - Drop cause argument of timer_interrupt() as it isn't used inside the function and anyway it is pretty clear what is the cause inside timer_interrupt(). --- xen/arch/riscv/traps.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c index e9c967786312..53f96f143823 100644 --- a/xen/arch/riscv/traps.c +++ b/xen/arch/riscv/traps.c @@ -10,6 +10,7 @@ #include #include #include +#include #include #include @@ -108,6 +109,15 @@ static void do_unexpected_trap(const struct cpu_user_regs *regs) die(); } +static void timer_interrupt(void) +{ + /* Disable the timer to avoid more interrupts */ + csr_clear(CSR_SIE, BIT(IRQ_S_TIMER, UL)); + + /* Signal the generic timer code to do its work */ + raise_softirq(TIMER_SOFTIRQ); +} + void do_trap(struct cpu_user_regs *cpu_regs) { register_t pc = cpu_regs->sepc; @@ -148,6 +158,10 @@ void do_trap(struct cpu_user_regs *cpu_regs) intc_handle_external_irqs(cpu_regs); break; + case IRQ_S_TIMER: + timer_interrupt(); + break; + default: break; } -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:50:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:50:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211432.1523015 (Exim 4.92) (envelope-from ) id 1vixst-00078G-Oh; Thu, 22 Jan 2026 16:50:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211432.1523015; Thu, 22 Jan 2026 16:50: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 1vixst-000789-M8; Thu, 22 Jan 2026 16:50:15 +0000 Received: by outflank-mailman (input) for mailman id 1211432; Thu, 22 Jan 2026 16:50: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 1vixss-000783-BP for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:50: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 6a51f212-f7b2-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 17:50:12 +0100 (CET) Received: from PH8PR22CA0016.namprd22.prod.outlook.com (2603:10b6:510:2d1::9) by BN7PPF0D2C72F0D.namprd12.prod.outlook.com (2603:10b6:40f:fc02::6c6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Thu, 22 Jan 2026 16:50:05 +0000 Received: from CY4PEPF0000EE36.namprd05.prod.outlook.com (2603:10b6:510:2d1:cafe::68) by PH8PR22CA0016.outlook.office365.com (2603:10b6:510:2d1::9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.11 via Frontend Transport; Thu, 22 Jan 2026 16:50:02 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY4PEPF0000EE36.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.9564.3 via Frontend Transport; Thu, 22 Jan 2026 16:50:03 +0000 Received: from xcbagarciav01.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 22 Jan 2026 10:49:59 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6a51f212-f7b2-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=F16LbJM365Mjp73ksxnDTLcGqvz77xXQTgRjVNdQoLxG6CansKNb7fWd/h9ij9ih6LEY+xenNB0w/4U+9PLSvV9EBEJ8Mf5SzhzG60Y+wEcPVcTok2XXVoqKAEsbnnSZAjvafXWlcTxTwjJDoEM6ZSjsUMc/A2udQJDYXnaQZymtJE2xVlI4CCjIG6wbXYgxrWbEWop/INi7vZubL2G8u8GFN5snF/S9LIe+JiGnK19UwWbgfFZavVmJadjznkTB9oDFXIm244oc/+711YZubi14pw1uyLkajCbQjAWBNFhxhR3NTMcT3HfhHLxWD0UmvstRIxj1nPAC57VywDiizA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9EmXfLyMCmn0zGN/UiCxh5bIuJ3Np7zB11ymzGrJfEo=; b=vDm6BA112AYdrblBXZtcb0LwTsHTIlnZQriQo0wDyHYSsCELDw724NuZTTqESovDs4tUlv8/XMaje2aWXgQF/h8tEZSpjMI5ZAiBFhOOnRBy/aZg4LuPXHAThv+U1anVNEr1UPxr4Tqmb0l+TZpJjpK+c9E+4QeNmdnTnPgbDB30qquFM0k68waSxIG4Q3ihWUFCWJu9Qoewq2N9p5Dc0DnA4kKC7WmqqfBstt2l54hstj9vZTLxjdg8eQlDsBCZqPvUf8tfyNfrkioHXfSj16a0JsFCZoLXEmAHP6fhkHbuDRDR+/wUhsKwcBkyRDPW6Wp++EhAN4pm64lOWi22OA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9EmXfLyMCmn0zGN/UiCxh5bIuJ3Np7zB11ymzGrJfEo=; b=1SOSfcadga/SqWfjU0EvCXbp0pEVQf50TL5rW7NHYMrQithJnZRSjMP/fbjripvMmUmDUnzhSmasnAjiU49x/K0ME03oPSu554GSnFp27kYR7B11O5kXHPE465+eW4jRPpytZl5vmUJ+w1OItpncHKUIhZhI+HONhHTwIJM4W5A= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk Subject: [PATCH 2/4] x86/hvm: Disable non-FEP cross-vendor handling in #UD handler Date: Thu, 22 Jan 2026 17:49:38 +0100 Message-ID: <20260122164943.20691-3-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> References: <20260122164943.20691-1-alejandro.garciavallejo@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: 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: CY4PEPF0000EE36:EE_|BN7PPF0D2C72F0D:EE_ X-MS-Office365-Filtering-Correlation-Id: 35533bef-394e-450c-9267-08de59d64a16 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?R0Y1Q25sYnZtY1pSOEEyWlZIWXdUbXNZWEVxbHhyaVdWaG9NK2p1WkxmcHR0?= =?utf-8?B?TUQ1NGVTQkd6Y1A4MVFVWERBc2VlMHRiUm5JL0FseGsvR3UzYzNMSDVhaW1Q?= =?utf-8?B?Ym5NckRXa0VqZVg2aWZxZGFyb01OeWRKYjZ2Wkh6WVhJeExwdXpGdEpkTW5V?= =?utf-8?B?emlyU0w3YXYxSk53dExFYTdpVTB5bnJ3ZlZWaUVmdE9ZZEtHY3Y5ODd0Mm9Z?= =?utf-8?B?eXpZdmVuRjNTbVVxUC9sMHhBbk1ra3dNZkdsYy9tOFpnQmVRRTllZm51ZFFn?= =?utf-8?B?SDVEb3Avc1BXaWJSeGRYS0UrYzdwZWFOUWhLNzJjUXVKaElJdFNuNDlGY2tH?= =?utf-8?B?QktHTFMvUnBuRDR6TmNobllJOXRZb0tnUWR4REdDc0JyUmFEdWtSNlZqMVFK?= =?utf-8?B?Zkp0ZVFWK3gzRGpCclNRc3pDNlVrVUNOSERXS0I4TWdhTXhqem9ZdCs3Z0VR?= =?utf-8?B?SzdNbDkvVEVLNDEyWXAwMWt3UFB6MUk1cnhRWExxOVBxM1V2OTBpUVl4eFNJ?= =?utf-8?B?VlFIb01BQXJVRE9jeE5ON2ZDWWkwdWo1dUljaG9yQlZMQ2t6WlJkM3J5NXVt?= =?utf-8?B?VjRVblZ3R29jVTlwb1VHVGY2YzNsRTRwTTE1Nm05ZmRLdGRNTVNTcUpUd3o0?= =?utf-8?B?bW1CTW9DUi9MN0g4V2NTN011c3FGa0Y5NkxGcDg2OUhmTXQwRERMNGZnOVF3?= =?utf-8?B?K1Z3KzFFS3IvakwxOGlvU0tCd2YzWTZNSitPRmh5TXBObnVCTGtwakgxUTRa?= =?utf-8?B?S1lIaTZNTm1ZK0s1MTJKcU83UjRhdUp4YjFCVGVEcWFDempxakxNeHBBR0Jx?= =?utf-8?B?c2ZuVXQyRWpUaTF6NmVocmpLZVRuVXhBWHFGUUJpaHVzVG9LSENFRHVweG1D?= =?utf-8?B?eDh4WFlmS0tFUmYzNEZXWHhDNnQ1MlJhNW5SOGJ3azlzRWRudWVKUUJqQjA2?= =?utf-8?B?bDRkam9FcGhOUnAzR2oyMU5FTkdQUzRsN3dzUlBHOCt3MjJPL0pZQkFiTjlM?= =?utf-8?B?U0xwZnZPOFl2YjRUdzkzbkRIdEdpSDBjQWRGOWJsUlBLZUxobUxuQ2JuNm5w?= =?utf-8?B?c2RBZ3N4RElZQjgyZmZzamYzVGhDSjBHdndMTlFsS0xuTmIxc29SOGpaU0VC?= =?utf-8?B?aDk5dDZzNitJdHo5UElUSm12WDJoUVYrc3lIQmY1SVJrMUZFbDBWWVI1VXpi?= =?utf-8?B?ZVFNTHpEYXdCdzJTTmMwNGt2YzQrMG8wZ2I3ZHBRVG5RY3hjNHVlV1BXVmZV?= =?utf-8?B?ZFUzaWZTV1E4cWN0cUpzOGZpZXJkUlE4LzRiZ3VCS3Q5ai9lYlMyVDJEZ3Mv?= =?utf-8?B?UWZ5MWY3dUYxVkFKVzhJUEMyby9ZdUJlVzA0dVlobmdYbHdlQ3BtTkc4RjBW?= =?utf-8?B?eGc2SzlSZjA2bEpTcm40NXRESTlUZXA1bDJZei9pU01ZcUlleDJTSkdNd2l2?= =?utf-8?B?S2szTGdHTU9kTC8yS1YvekpzMWw3MGNHQkwrd2hEUmNadHRyOWxDNDhBcno1?= =?utf-8?B?VGd6OS9lSE5YM1ZDbVhwRFlOVmI2MVBKeUxOenhLbEVodnJJNmZEQnVNM0lk?= =?utf-8?B?bERidnBOZzhod3B0UWEweU9ONmp1L1RUL1EvQVB6UGZiL1BpM2RVNU9oVGRE?= =?utf-8?B?UVdPQkxzS0d5cU93eDg1THhaY2grZHE0M0JMdDhPc3ZjSHFxRzE3VjVjcDdG?= =?utf-8?B?dC8xUEVkZ1oxbENXZU53bEpOak1tRkJNODdsU1hadjFuZmVJUVB4RWxnMnRu?= =?utf-8?B?Tmc4cTZGMnNnWUs1SFgxaXF1ZTR2ajZ1T2FjMFozUGZuUGo2SFVPTHJGU0VG?= =?utf-8?B?NnQvSmN3SnMwWUFqWG4rZURkOXE5YTg3MitjZ1B1bXNZUEhaL3NLN1V2NDRQ?= =?utf-8?B?TGRZL2E3MlRYNjZJLy83OHNjbHFWc3l4cHlxTGF2a04zclJSZUpMaDcrckxu?= =?utf-8?B?NG5oVm1tZWxqKzdYc01lYjVHTjArVmptSVdMMGkwcFY0cE04aXoxN0xmQTdq?= =?utf-8?B?SnVsbjBocWUwSXRwbisvTUh1bmJ0M3N6d0JpaWZ3MDBtSC93a0JNbHd1MVBY?= =?utf-8?B?MU9ld2VMYWdmRlJ6WUxLUUNld0FKUVIxU1BLMVJVSDhUazBuUGs3MHZHUXhK?= =?utf-8?B?ejE3aHhiQ25nWlFaUlJpZE9BeVJGUWdGeHVocjBZTzM2ZWg1SVJHTEhCUlFn?= =?utf-8?B?WVk5MmhGc3ZNQUxuUHR4SDZ4V1JUYWJQdEFjM0RHb2FqOGtRVGF2RkljU3F4?= =?utf-8?B?SkJjVDNZaHgyc0J5ajltdWh5alFnPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 16:50:03.3182 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 35533bef-394e-450c-9267-08de59d64a16 X-MS-Exchange-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: CY4PEPF0000EE36.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PPF0D2C72F0D Remove cross-vendor support now that VMs can no longer have a different vendor than the host, leaving FEP as the sole raison-d'être for #UD interception. Not a functional change. Signed-off-by: Alejandro Vallejo --- xen/arch/x86/hvm/hvm.c | 25 ++++--------------------- xen/arch/x86/hvm/svm/svm.c | 4 ++-- xen/arch/x86/hvm/vmx/vmx.c | 4 ++-- 3 files changed, 8 insertions(+), 25 deletions(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 4d37a93c57..611ff83a60 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -3832,28 +3832,13 @@ int hvm_descriptor_access_intercept(uint64_t exit_info, return X86EMUL_OKAY; } -static bool cf_check is_cross_vendor( - const struct x86_emulate_state *state, const struct x86_emulate_ctxt *ctxt) -{ - switch ( ctxt->opcode ) - { - case X86EMUL_OPC(0x0f, 0x05): /* syscall */ - case X86EMUL_OPC(0x0f, 0x34): /* sysenter */ - case X86EMUL_OPC(0x0f, 0x35): /* sysexit */ - return true; - } - - return false; -} - +#ifdef CONFIG_HVM_FEP void hvm_ud_intercept(struct cpu_user_regs *regs) { struct vcpu *cur = current; - bool should_emulate = - cur->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor; struct hvm_emulate_ctxt ctxt; - hvm_emulate_init_once(&ctxt, opt_hvm_fep ? NULL : is_cross_vendor, regs); + hvm_emulate_init_once(&ctxt, NULL, regs); if ( opt_hvm_fep ) { @@ -3878,12 +3863,9 @@ void hvm_ud_intercept(struct cpu_user_regs *regs) regs->rip = (uint32_t)regs->rip; add_taint(TAINT_HVM_FEP); - - should_emulate = true; } } - - if ( !should_emulate ) + else { hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC); return; @@ -3903,6 +3885,7 @@ void hvm_ud_intercept(struct cpu_user_regs *regs) break; } } +#endif /* CONFIG_HVM_FEP */ enum hvm_intblk hvm_interrupt_blocked(struct vcpu *v, struct hvm_intack intack) { diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 18ba837738..0658ca990f 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -589,8 +589,7 @@ static void cf_check svm_cpuid_policy_changed(struct vcpu *v) const struct cpu_policy *cp = v->domain->arch.cpu_policy; u32 bitmap = vmcb_get_exception_intercepts(vmcb); - if ( opt_hvm_fep || - (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) ) + if ( opt_hvm_fep ) bitmap |= (1U << X86_EXC_UD); else bitmap &= ~(1U << X86_EXC_UD); @@ -2810,6 +2809,7 @@ void asmlinkage svm_vmexit_handler(void) break; case VMEXIT_EXCEPTION_UD: + BUG_ON(!IS_ENABLED(CONFIG_HVM_FEP)); hvm_ud_intercept(regs); break; diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 40e4c71244..34e988ee61 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -797,8 +797,7 @@ static void cf_check vmx_cpuid_policy_changed(struct vcpu *v) const struct cpu_policy *cp = v->domain->arch.cpu_policy; int rc = 0; - if ( opt_hvm_fep || - (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) ) + if ( opt_hvm_fep ) v->arch.hvm.vmx.exception_bitmap |= (1U << X86_EXC_UD); else v->arch.hvm.vmx.exception_bitmap &= ~(1U << X86_EXC_UD); @@ -4576,6 +4575,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_regs *regs) /* Already handled above. */ break; case X86_EXC_UD: + BUG_ON(!IS_ENABLED(CONFIG_HVM_FEP)); TRACE(TRC_HVM_TRAP, vector); hvm_ud_intercept(regs); break; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:50:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:50:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211433.1523026 (Exim 4.92) (envelope-from ) id 1vixsx-0007Mi-0i; Thu, 22 Jan 2026 16:50:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211433.1523026; Thu, 22 Jan 2026 16: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 1vixsw-0007MX-Sq; Thu, 22 Jan 2026 16:50:18 +0000 Received: by outflank-mailman (input) for mailman id 1211433; Thu, 22 Jan 2026 16:50:18 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vixsw-0007Lp-0g for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:50:18 +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 6d162c35-f7b2-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 17:50:15 +0100 (CET) Received: from PH8PR22CA0014.namprd22.prod.outlook.com (2603:10b6:510:2d1::29) by SN7PR12MB8772.namprd12.prod.outlook.com (2603:10b6:806:341::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Thu, 22 Jan 2026 16:50:10 +0000 Received: from CY4PEPF0000EE36.namprd05.prod.outlook.com (2603:10b6:510:2d1:cafe::c2) by PH8PR22CA0014.outlook.office365.com (2603:10b6:510:2d1::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.11 via Frontend Transport; Thu, 22 Jan 2026 16:50:06 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY4PEPF0000EE36.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.9564.3 via Frontend Transport; Thu, 22 Jan 2026 16:50:09 +0000 Received: from xcbagarciav01.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 22 Jan 2026 10:50:02 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6d162c35-f7b2-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XYZrOXSVGnMPz9GBvjgU2qRtZmcKktu4B8tI1NPTU9LEfyicNElinuhb1maznonzRWuQqtuaCk1pdIaCUJVvTTFwEsH5R/P1v5etwgMKUx4lKxPOngnX1DemGvVYiqiV6Ix9V7NoTaID3AO8chJmzojGQunc+6PMFNAOADp/n++Zz192uBmq627S8NfaavQKsSLoeeRH+QOEn+ana/w5Xsbd4FYXnyYrgBJTgUhmh2I0gzUe+6omJ8QyKmqwrmdImky8oDWYmIVn1piX8hZQebdrWsxF4YVmo39wgSSFzJLrv0lk/Ynp4Rchfscd9Qpw1Z4SPbNRng7ZNS2b6Z6X3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TqUBinfJMYNlCATSgG74qTOPnewkTVbi9kO9zRn7zi0=; b=CEwEMzXnaME8gbYNoUM+ovhbP2TIZq02Vf6D3k4b+61n01h2/qKUwEujaI0TVm5BLYO8Ml+dwMTsC+D6EcYA+ujJszNOogAR+qH6WZW9NA7RrBn9qTVenENpaDorE+Z29FLr4W7H0y2y5LSAY+/+s6PVImaDMFs2uegqKYlAwF3na6Unfi7AjT9EaMwH6ocoqH9SIgBYXbMar6BTGDlkim0BBeChuScH8LSRrZjpkG+mFZngkHfepGKz56fOohYeVQvlp3sybajiRBJHXUKQDkz1u2Jzb226nlkq6LayAcdgJxm335syDEhT6EqT6k3oF0nYhYlWwF157Q85vSSvfA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TqUBinfJMYNlCATSgG74qTOPnewkTVbi9kO9zRn7zi0=; b=QTEatZSALdktEn3I0LkTWM94RgG4yVoT/gIesuMWyja2y5jUz4ioj7oJWWTOLVM/xjeQJKEcHtUKx9lxUfU544YpuQo9XoXoEPe4y04ESJBffkpcq5TZqCEx9zV/FxEi0RuRo5RLa54sbreW9S4PiZCWclFBr8VsEKEYOPjbzZw= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk Subject: [PATCH 4/4] x86/svm: Drop emulation of Intel's SYSENTER behaviour Date: Thu, 22 Jan 2026 17:49:40 +0100 Message-ID: <20260122164943.20691-5-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> References: <20260122164943.20691-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: CY4PEPF0000EE36:EE_|SN7PR12MB8772:EE_ X-MS-Office365-Filtering-Correlation-Id: 94ba0e70-042d-4b09-f00b-08de59d64dea 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?rqMmRNthNoJzBRvAWe3Ln9lk/GTrW8PJ7uEEUIKGWN7/bkp+EG0QPhWiMGLq?= =?us-ascii?Q?Q69l7H/ZkbuxwDl20Zf13393mOljzOisVtDxGNVXW9qHhdlmKnEn1tlPVhx8?= =?us-ascii?Q?hU1ERNxsfHxGC53vDIok2Ocz0fZLCd+GekAtuQbC5mEt9yXvNXrXxz3DNXms?= =?us-ascii?Q?Jf0jOi7HoTMAXeGUnH8AOWxWaMIe5Deo7LhoD/P9K3h7K90xwzvDtPWWuYub?= =?us-ascii?Q?/erp0tsQqZS/oa4H6HNwKzYmNNguHPCQ9Q15ipfNFZmlEZjwxfMs9fEmtEry?= =?us-ascii?Q?YREfdDcUWdVxuV6c8bkii3E9XR7BuEEenX2V1i5JPhOQiRE0kCnHYFrGRFpp?= =?us-ascii?Q?V91MN0m4MM2m/xUegEWb4poHnE9TZ4CLsnM2Htm8/+TatXpYdFjKVzOnjKfs?= =?us-ascii?Q?lkiTXc5zwanzIFJG8f2BVQT3Wggt9iVhOqY7HjtNGp1tTO0VFnGLVykUx5eR?= =?us-ascii?Q?KECXomizGPhTOpjAOdL0D5nwK8P3JrizRnOuveBi+/ppAI7BQV6X7zJsPCjm?= =?us-ascii?Q?5ejdqowOew8yiVmPQGvo4IQExfYxmzBqFKUpWvMqtHHPPATQiOohKYmIuPyM?= =?us-ascii?Q?0BfcDy457y1cyUbCf8Yy3t4xnVxXoLlnTAXdRPm6iWaT6y8tUTFEAyvoCIUf?= =?us-ascii?Q?hFyTJBipwQMEbHL5oJETxod1r3mEQxkWJo62aDeCyRNzf3icoq8xq3fZUPMQ?= =?us-ascii?Q?pN+/1UXex7hzCK0X1/F813xTxGeto7bpmgfXM79sv64xLETXg3CIvRsY5raU?= =?us-ascii?Q?eVAjbc8Gmc/DKHFo+0IJdUV4N6tG6BHukq5/Zs7SV6JNcderWVtFISkQcLQj?= =?us-ascii?Q?f0TpFb8GvsdJ264TOoAWoZ0ypQFEAPh3Ye3wbStad3tqaYVSmFUExHawfki3?= =?us-ascii?Q?FtNNA1FokHGOrfZoT5SRTEIhXtP4hiIlXz2TLlzOpDZiGVu9Sq/wASS/2YaW?= =?us-ascii?Q?Fk2GQWrvtRsSxB7vWm93klfQ7VYzeQTjnmQShyLguJFdKr82TUCfws227N8i?= =?us-ascii?Q?bW1cVY+mJWP7eusnNefkNaCoGDGetilj0ogOwRAUjOaJXD3EZFsSH76OrGUB?= =?us-ascii?Q?74UVBfLJdSojZtqFZM2wUHFowQhZkvJOGLVxhIu7pPd/1EiC2ooGcfJpWxH8?= =?us-ascii?Q?HP4EDYQv3WOrQX+lxDgAh653dug0q+pjzhXYcPGV0cH5l7FO3nC2eR3GJuu+?= =?us-ascii?Q?FhgQfZ7KvZH4pJwYwUv4LuJWOnQwHpCdsF5Bg50/j8ZYiTWOCAJzKTMIbmca?= =?us-ascii?Q?AVDoi36Uss3xA0dM8nlDg4QQyl7kBHtzl+guJ1AEeoNIpEw/qge/3LA8rOps?= =?us-ascii?Q?lAQ2zmPaYhW7sQdZlDOQsYdJTxxFAjlSLUPwfpgaUruJUBDUtAMu0LE2AmZ4?= =?us-ascii?Q?ssbLCI7KmJQ/hRDbvnp7ivX7m+pReJC44RH4t6GSeJx3XipC1DkpRaqp8ksG?= =?us-ascii?Q?++/97EP21nEw+mXh0o49vjQaVvRmr30ItrKih2Af7CEJaBBksslkWovena6Y?= =?us-ascii?Q?9Sc+oiB2xOpbwv7VMaOnOT3REXn3RfKdUIWdRyg34jGjRXGMN2E4XqJEmPht?= =?us-ascii?Q?mXwCzigbjYpVmx9Jw6fzzmqwr7LfPORZE9q8rWylD5Mm1bL2sqjeSGxCPI/4?= =?us-ascii?Q?U6cv01NGdkX94IXoiBAEI+uK97Tz8/gu78mhXqV/3zdI?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(82310400026)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 16:50:09.7449 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 94ba0e70-042d-4b09-f00b-08de59d64dea X-MS-Exchange-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: CY4PEPF0000EE36.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8772 With cross-vendor support gone, it's no longer needed. Signed-off-by: Alejandro Vallejo --- xen/arch/x86/hvm/svm/svm.c | 42 +++++++++++------------- xen/arch/x86/hvm/svm/vmcb.c | 3 ++ xen/arch/x86/include/asm/hvm/svm-types.h | 10 ------ 3 files changed, 22 insertions(+), 33 deletions(-) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 0658ca990f..e8f19dec04 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -401,10 +401,6 @@ static int svm_vmcb_save(struct vcpu *v, struct hvm_hw_cpu *c) { struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; - c->sysenter_cs = v->arch.hvm.svm.guest_sysenter_cs; - c->sysenter_esp = v->arch.hvm.svm.guest_sysenter_esp; - c->sysenter_eip = v->arch.hvm.svm.guest_sysenter_eip; - if ( vmcb->event_inj.v && hvm_event_needs_reinjection(vmcb->event_inj.type, vmcb->event_inj.vector) ) @@ -468,11 +464,6 @@ static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c) svm_update_guest_cr(v, 0, 0); svm_update_guest_cr(v, 4, 0); - /* Load sysenter MSRs into both VMCB save area and VCPU fields. */ - vmcb->sysenter_cs = v->arch.hvm.svm.guest_sysenter_cs = c->sysenter_cs; - vmcb->sysenter_esp = v->arch.hvm.svm.guest_sysenter_esp = c->sysenter_esp; - vmcb->sysenter_eip = v->arch.hvm.svm.guest_sysenter_eip = c->sysenter_eip; - if ( paging_mode_hap(v->domain) ) { vmcb_set_np(vmcb, true); @@ -501,6 +492,9 @@ static void svm_save_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data) { struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + data->sysenter_cs = vmcb->sysenter_cs; + data->sysenter_esp = vmcb->sysenter_esp; + data->sysenter_eip = vmcb->sysenter_eip; data->shadow_gs = vmcb->kerngsbase; data->msr_lstar = vmcb->lstar; data->msr_star = vmcb->star; @@ -512,11 +506,14 @@ static void svm_load_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data) { struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; - vmcb->kerngsbase = data->shadow_gs; - vmcb->lstar = data->msr_lstar; - vmcb->star = data->msr_star; - vmcb->cstar = data->msr_cstar; - vmcb->sfmask = data->msr_syscall_mask; + vmcb->sysenter_cs = data->sysenter_cs; + vmcb->sysenter_esp = data->sysenter_esp; + vmcb->sysenter_eip = data->sysenter_eip; + vmcb->kerngsbase = data->shadow_gs; + vmcb->lstar = data->msr_lstar; + vmcb->star = data->msr_star; + vmcb->cstar = data->msr_cstar; + vmcb->sfmask = data->msr_syscall_mask; v->arch.hvm.guest_efer = data->msr_efer; svm_update_guest_efer(v); } @@ -1720,12 +1717,9 @@ static int cf_check svm_msr_read_intercept( switch ( msr ) { - /* - * Sync not needed while the cross-vendor logic is in unilateral effect. case MSR_IA32_SYSENTER_CS: case MSR_IA32_SYSENTER_ESP: case MSR_IA32_SYSENTER_EIP: - */ case MSR_STAR: case MSR_LSTAR: case MSR_CSTAR: @@ -1740,13 +1734,15 @@ static int cf_check svm_msr_read_intercept( switch ( msr ) { case MSR_IA32_SYSENTER_CS: - *msr_content = v->arch.hvm.svm.guest_sysenter_cs; + *msr_content = vmcb->sysenter_cs; break; + case MSR_IA32_SYSENTER_ESP: - *msr_content = v->arch.hvm.svm.guest_sysenter_esp; + *msr_content = vmcb->sysenter_esp; break; + case MSR_IA32_SYSENTER_EIP: - *msr_content = v->arch.hvm.svm.guest_sysenter_eip; + *msr_content = vmcb->sysenter_eip; break; case MSR_STAR: @@ -1940,11 +1936,11 @@ static int cf_check svm_msr_write_intercept( switch ( msr ) { case MSR_IA32_SYSENTER_ESP: - vmcb->sysenter_esp = v->arch.hvm.svm.guest_sysenter_esp = msr_content; + vmcb->sysenter_esp = msr_content; break; case MSR_IA32_SYSENTER_EIP: - vmcb->sysenter_eip = v->arch.hvm.svm.guest_sysenter_eip = msr_content; + vmcb->sysenter_eip = msr_content; break; case MSR_LSTAR: @@ -1970,7 +1966,7 @@ static int cf_check svm_msr_write_intercept( break; case MSR_IA32_SYSENTER_CS: - vmcb->sysenter_cs = v->arch.hvm.svm.guest_sysenter_cs = msr_content; + vmcb->sysenter_cs = msr_content; break; case MSR_STAR: diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index e583ef8548..76fcaf15c2 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -97,6 +97,9 @@ static int construct_vmcb(struct vcpu *v) svm_disable_intercept_for_msr(v, MSR_LSTAR); svm_disable_intercept_for_msr(v, MSR_STAR); svm_disable_intercept_for_msr(v, MSR_SYSCALL_MASK); + svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_CS); + svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_EIP); + svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_ESP); vmcb->_msrpm_base_pa = virt_to_maddr(svm->msrpm); vmcb->_iopm_base_pa = __pa(v->domain->arch.hvm.io_bitmap); diff --git a/xen/arch/x86/include/asm/hvm/svm-types.h b/xen/arch/x86/include/asm/hvm/svm-types.h index 051b235d8f..aaee91b4b6 100644 --- a/xen/arch/x86/include/asm/hvm/svm-types.h +++ b/xen/arch/x86/include/asm/hvm/svm-types.h @@ -27,16 +27,6 @@ struct svm_vcpu { /* VMCB has a cached instruction from #PF/#NPF Decode Assist? */ uint8_t cached_insn_len; /* Zero if no cached instruction. */ - - /* - * Upper four bytes are undefined in the VMCB, therefore we can't use the - * fields in the VMCB. Write a 64bit value and then read a 64bit value is - * fine unless there's a VMRUN/VMEXIT in between which clears the upper - * four bytes. - */ - uint64_t guest_sysenter_cs; - uint64_t guest_sysenter_esp; - uint64_t guest_sysenter_eip; }; struct nestedsvm { -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:50:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:50:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211435.1523036 (Exim 4.92) (envelope-from ) id 1vixt1-0007ee-CN; Thu, 22 Jan 2026 16:50:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211435.1523036; Thu, 22 Jan 2026 16: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 1vixt1-0007eV-9T; Thu, 22 Jan 2026 16:50:23 +0000 Received: by outflank-mailman (input) for mailman id 1211435; Thu, 22 Jan 2026 16:50: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 1vixsz-000783-HK for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:50: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 67991b8f-f7b2-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 17:50:07 +0100 (CET) Received: from PH8PR22CA0013.namprd22.prod.outlook.com (2603:10b6:510:2d1::11) by DS0PR12MB6607.namprd12.prod.outlook.com (2603:10b6:8:d1::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9456.14; Thu, 22 Jan 2026 16:50:00 +0000 Received: from CY4PEPF0000EE36.namprd05.prod.outlook.com (2603:10b6:510:2d1:cafe::b7) by PH8PR22CA0013.outlook.office365.com (2603:10b6:510:2d1::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.11 via Frontend Transport; Thu, 22 Jan 2026 16:49:59 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY4PEPF0000EE36.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.9564.3 via Frontend Transport; Thu, 22 Jan 2026 16:50:00 +0000 Received: from xcbagarciav01.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 22 Jan 2026 10:49:58 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 67991b8f-f7b2-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=G2IRoyudhXNiNfHOskV+igGQTAmeb5Jh1b6MEkk8D5taKEyZV7CH1NW0yPRKvgC80QKCtWYhqUMMnVJR3q+rT5mQajrCmCIKNQklknPxzjtGP19XqL7zraER0HqTDgBlm3NKOBjX0Ey/6+UwLigkPgyp2No7M+eoTqTAE+UcEzYsGroqTASQyTg1oKWi1Gc/2dcKWdfexnTDvn5riUu6A8Kq6R8FK5g+DaNgtgt5/APbHFu0PuFg0keV8mZZGhOVNGZiqphEl0NR9ZYz+jgXDQIFA4sJQCfcWq5qRtH5nSanrd2gYb4wUgazbhAcfJ1udt26oSDTRIjZ0KCAlynzyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WMxox3x+9Ts/m2y8FFHLB2sq78zjecLlHbq/Xxc18Ig=; b=kb5QLyFihtx+GBZbkrU1q8UND0jrIMBKAQaaAe2xHLe9Vmqh/tQbIF9sNQALx0fiv22Ihff9G0O8g7pP5qWzR4GSEG8BSzVXn6EU+5LkaFSdwHek+4BQfCCzW3xqbHBvKnvgodzAOmQyTaajhUWsLolbr1F1PfA8tTTfvc9OC6cmQH/hpVfzW/Q6AWZGHteQzSJxKdeG07RrxQD13XtdmTW9lxKVUXGtoDYgyn7gNbTDAmTXWP1M5PDScrH33FYcqbPAraYHFeyVVT1bcYc1j3cC/MRfn8VHgHkM5gALjER/b5cBIGaZx6Cs9yoVtZAyHAmGZ1v4qT5gA/Xu8gFp2A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WMxox3x+9Ts/m2y8FFHLB2sq78zjecLlHbq/Xxc18Ig=; b=PxNbsqVqMo+QzEkNo2hc5ol60dkioNwOxU6Vs7qULMmVoFevZ6HdRT8zbyzs3hBRjTWAVJtoz1YORzelHg1q3+NECRSfsFj9QoAilCEKk9LTqrdZRpIsk/UnM1Vzb2BK8lzlyGbEUi+1Kv7Yl6Lr06QLvlKmqj+3VmNSbfRefJM= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alejandro Vallejo To: CC: Alejandro Vallejo , Oleksii Kurochko , Community Manager , Jan Beulich , "Andrew Cooper" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH 1/4] x86: Reject CPU policies with vendors other than the host's Date: Thu, 22 Jan 2026 17:49:37 +0100 Message-ID: <20260122164943.20691-2-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> References: <20260122164943.20691-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: CY4PEPF0000EE36:EE_|DS0PR12MB6607:EE_ X-MS-Office365-Filtering-Correlation-Id: 862483f3-570a-4893-b084-08de59d64846 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|376014|36860700013|13003099007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?nxi68i8hxVWvJWRcf1Aworwh3O3W6uCjcD+CgVXGP9H0y/6OXRX717YgDZO2?= =?us-ascii?Q?5+SWFWrZuaMb2fDKPkb0Gx7LqmU9BVDQbueXBuylj+huMdYJxxR16/VcqDTF?= =?us-ascii?Q?tn1pCPBhl8HPLi/D6Hof70UJqiF8HnGj2obpw6NkVNYHOK8lL9U/Ry23N569?= =?us-ascii?Q?P5VuCkb5G7Pz10t805K9rQo1PadHXseGrRRSms4KATAtdKmfSZC7esBiRUL7?= =?us-ascii?Q?KZb5OWb79GMc2bI+XQjP/gPj5QOSqaPF7kSrFxP4PvBxKVDG2yovPjHKnaYu?= =?us-ascii?Q?dHCYZeD5l7ImTs5nHG/KIleZGu9C3qx/VkrF/yNTKc1m8DmeHfJP0etjzR+4?= =?us-ascii?Q?jJwyWA8az8AcAFPWtd3MDWLHky9m2WhpVl2+B3hxCTZWThlSosYyzRD6wrDR?= =?us-ascii?Q?yIazp5cAUthWBSqiPc1PkuVuLJ2SAQ/7wic8WJ0E80eZOIqED/RTcwCW+AyE?= =?us-ascii?Q?Z3mK9LW/IaQiRsR0xdSdJAIGDu5epmgWsvLscAgWwVZgKcShKkNFCLM/bbIE?= =?us-ascii?Q?D8YBUUS2FD8FHkTgzXY4ANdaotvT81qk+l2KUYSrFWV10oeCazh1ZVVI64o1?= =?us-ascii?Q?t+SnMT9a+/sjZPeSmS2x/zK8MVXW+I7oBp3PKKUVgEJzM9Nv7AjKILfdPnTh?= =?us-ascii?Q?6H68yIr0zpq0QifpzFpJwqQ0C67oVR3adCBm++r2K8ck0prqEzC6LE+E34Kb?= =?us-ascii?Q?6gfwOJlgG+YirDVpoknbBzm2+8ANqD302DuSNGkLWl2H8iJcY088b9Hrawa5?= =?us-ascii?Q?ZLksGyK5MVro0BOxDVeWcJsoPb0h0camsref9XemnvGiV+NgbmSC1r6xAcKN?= =?us-ascii?Q?dGxR2JsjP06L/oqTKEkJ910YQTe05JRlruYqXZgEfm4yFpTgwp4A25Gy/DF5?= =?us-ascii?Q?CXjaiGmOrDvfJkdZ+JcBU5TlPpMJ18pF3tCQOVTvHla3IJjbjdD3fn1cA6XO?= =?us-ascii?Q?Fk/oUHZZKbkkzTQiHV7ZkTncufuRFEowsemrGKu+3kzfOlhp6GR2TF2eyU3i?= =?us-ascii?Q?jN/YgM8xmPxsoieAiUu1lVw3FIaeMxqoOiB4a5tq0ATk18B6ddI8SPyzFAgb?= =?us-ascii?Q?X0Ph/EEfPqsJS6MT3iUCnNUoxXaTJJAYuoGvUMpfoKYPa0Yfdfi1XywzaxvG?= =?us-ascii?Q?eb3yqSblK8DO89ORyGmvLBatG7bQe7TGKaVHz5FX8evs4DgNsUYboJAHCNih?= =?us-ascii?Q?MsfxcqNFGt+ail7xhw/awNyJDD7lVhUeAr21sDxrbNUsHUzzO8pvmd/bO0zH?= =?us-ascii?Q?n6qx9TQCIInm3pPzxXbDna28H23o/66+tdL/ebNsHGD8ZMHtbG1G47IUeGlJ?= =?us-ascii?Q?cLzncx9ix8I4PztPZTCW08dH2pxJabLTRAKGCUDrGyfH2e++jnwZHZP4jT2G?= =?us-ascii?Q?cu2tKBf9idvRnDDE/9mxIkU7d9OzZ3B74dtRqDVLjj/8mX4R20DUYVxkPMyX?= =?us-ascii?Q?rcSYMSRGgWAt51IhQcxN6LhUHdL6CbpcUYPVhItD/ilerbEqlt+gagB1h1Zs?= =?us-ascii?Q?wSYauwxW+YNC7okFdDt1Wa9yfgHpVE7PRFBTrXiF9Y05htl9KsXIeozAMt+t?= =?us-ascii?Q?gX6MF1HaexIvzJTamL98vOfxpZAPv9iyuaJP6JuIeKlU6VjIfGlANTlszQjt?= =?us-ascii?Q?Pw=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(376014)(36860700013)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 16:50:00.2776 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 862483f3-570a-4893-b084-08de59d64846 X-MS-Exchange-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: CY4PEPF0000EE36.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6607 While in principle it's possible to have a vendor virtualising another, this is fairly tricky in practice and comes with the world's supply of security issues. Reject any CPU policy with vendors not matching the host's. Signed-off-by: Alejandro Vallejo --- CHANGELOG.md | 4 ++++ xen/lib/x86/policy.c | 3 ++- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 18f3d10f20..eae2f961c7 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -22,6 +22,10 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) - Xenoprofile support. Oprofile themselves removed support for Xen in 2014 prior to the version 1.0 release, and there has been no development since before then in Xen. + - Cross-vendor support. Refuse to start domains whose CPU vendor differs + from the host so that security mitigations stay consistent. Cross-vendor + setups have been unreliable and not practical since 2017 with the advent of + speculation security. - Removed xenpm tool on non-x86 platforms as it doesn't actually provide anything useful outside of x86. diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c index f033d22785..4c0c5386ea 100644 --- a/xen/lib/x86/policy.c +++ b/xen/lib/x86/policy.c @@ -15,7 +15,8 @@ int x86_cpu_policies_are_compatible(const struct cpu_policy *host, #define FAIL_MSR(m) \ do { e.msr = (m); goto out; } while ( 0 ) - if ( guest->basic.max_leaf > host->basic.max_leaf ) + if ( (guest->basic.max_leaf > host->basic.max_leaf) || + (guest->x86_vendor != host->x86_vendor) ) FAIL_CPUID(0, NA); if ( guest->feat.max_subleaf > host->feat.max_subleaf ) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:50:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:50:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211437.1523046 (Exim 4.92) (envelope-from ) id 1vixt2-0007tn-L3; Thu, 22 Jan 2026 16:50:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211437.1523046; Thu, 22 Jan 2026 16:50:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vixt2-0007tf-HH; Thu, 22 Jan 2026 16:50:24 +0000 Received: by outflank-mailman (input) for mailman id 1211437; Thu, 22 Jan 2026 16:50: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 1vixt1-0007Lp-Me for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:50:23 +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 6c9c739c-f7b2-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 17:50:16 +0100 (CET) Received: from PH0PR07CA0070.namprd07.prod.outlook.com (2603:10b6:510:f::15) by DS0PR12MB8526.namprd12.prod.outlook.com (2603:10b6:8:163::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Thu, 22 Jan 2026 16:50:07 +0000 Received: from CY4PEPF0000EE31.namprd05.prod.outlook.com (2603:10b6:510:f:cafe::14) by PH0PR07CA0070.outlook.office365.com (2603:10b6:510:f::15) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.11 via Frontend Transport; Thu, 22 Jan 2026 16:49:53 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY4PEPF0000EE31.mail.protection.outlook.com (10.167.242.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Thu, 22 Jan 2026 16:50:06 +0000 Received: from xcbagarciav01.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 22 Jan 2026 10:50:01 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6c9c739c-f7b2-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bLJRub/oGtu+vwC94CnYuqyXPNHggChGau+wCN4HNthcw8nWa2UcZzOb/nbjzjSxKOKY8sEA9O5g6iZFT/Ul5xMq0aXCtxcy42JVc72UV0kQUd9rmeaIkieFYGud1Ko6XZ5JkMPoDhxkA/4xIKnld2Upd7LWGLNdxsuoVqRxWgYnsDqdOzV32plJVT8sX8JOvx5RRaGhqyzRd7tiJv0/YBnawJ0ou9dkjNR2FG0MmWfV57Hj3mg4Px2cDxVGgceknFps7VfKN/TFXUOJ8gCTBw7EUlMGzt9DKWfuj0iB3kaOThDXFVRuznYK3onrN1i+a7KHmtiGDW+2VA0slLPBOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=u2XiGBn+2TTMkvVjf7PhcT0PqgOh4b6zV4GWpM5zTgM=; b=VFY0i6kiylom7+1Nic3jtgZL6677FoPc3vFTGNHPah0FDMhexZEV1gUoeEF+jWpQ00ddNbKyKBr4ddQSZ2Z6J/J2mM5llF2IpHCBKCQWYs5gfBCQ6qNz1PjMF9zdWvY+8o7gy4+yMNcs+Kp4rHmBMTcb7gLLKSLxeW4899hzrCZv7tHgFYQ4x3qKW128/sV1po2M79lf4aXF9Fpo2g5lf9bM2zECpF5c1xFwLRwetvRCI5jsdfYT6Rwe/wLDcQ+7DP2cJiA8UvExNMjl6u8/3kYsL52wqxIAQSRkQgb4gTaozZM+wY+KDLCW8K9ucT1WLKIWZZ0XMyivLfo5u9CRwA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u2XiGBn+2TTMkvVjf7PhcT0PqgOh4b6zV4GWpM5zTgM=; b=M3i/E7+Fm1vqRKHh7Ba8Se9VvyIGxchSun6VsFI9KKt6T64oT/ItDaRS5DEUbBgW8wqWFLQ3FlXh6vHR4GQ9ANGqxVsH3eRLDqLPQeLAZlH/bl6F8KFXE9XBBsIPIj8NXsEJVMQr4wCpCsE7ARgNSwSzlA5/LFXHBX6JRKxxrN4= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH 3/4] x86/hvm: Remove cross-vendor checks from MSR handlers. Date: Thu, 22 Jan 2026 17:49:39 +0100 Message-ID: <20260122164943.20691-4-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> References: <20260122164943.20691-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: CY4PEPF0000EE31:EE_|DS0PR12MB8526:EE_ X-MS-Office365-Filtering-Correlation-Id: 50192ebd-25e5-4e4f-d5db-08de59d64c31 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?P12KV/72EIAx34JT0pwD3dLZkWzZi2WxSX+l3Wv4hq0RsAX0mnMJf7dHtwk3?= =?us-ascii?Q?3VWRD4u+N7g7/orIVcigPvkfZ/DKqcGwFnGT1jTXgWwF4U7kP0amG2BBoVOr?= =?us-ascii?Q?D/sgPK/ShC5wkRUKkC4e0dKss5RZVS8U+EYVwpxLycLrgsLqHpuU9JcG5fE4?= =?us-ascii?Q?mszUF8a/v7oR3MPpqvac81nTOsSOrrd96z5meD9/xa7ySQXqas38uk2GJE1P?= =?us-ascii?Q?+O6lsrC6uACHuTO6ffUpRZbwQEUDOjv7aAox0YWT7pNRR3vX2ap75d19w2kp?= =?us-ascii?Q?VBACnPJaXVbIkcsuFOwFLKzxphWDDkpXpkAUF9b0DW97Vj7K8HOtmnG6SaXt?= =?us-ascii?Q?F4KkZ/CAUZFI8YI1c298edY77fc+Dwno0OF6Feap8EfsJBK5KPzn6TsH2KD/?= =?us-ascii?Q?OsASRWs6QWGf45vjWYK6HwhemWf3LXEMD7oz1BpbKsLH7tMbC+m8tVLDTIC6?= =?us-ascii?Q?rpcYYC/dNLgU08/aDdBxDIhglHS4XNfDyvTK6r+4/t/biGGW5A7YH4hRgLL+?= =?us-ascii?Q?UJyS9frW+i8CYfWrNOhaAyCPXyjEZkZ8qHWX+V/tJi/iauCmvW1TyhZUwHfe?= =?us-ascii?Q?NNaDj7ahcjyhZ/GkWVTX2Rz+7Y/dvCWc3+cGSrJ2EuwhKiwxqrSO1MEfJ7YC?= =?us-ascii?Q?5BbTBZFlxgGHSFtGlj2ntE+tV5yviUn4lvio1zbD/ibfywO7jy2u+TKxk18O?= =?us-ascii?Q?mMWsBOGSuqjcceSW6lDF8LWa7mH7cAIF4VHmpA478+Ed2xsHurRXorFLPF1H?= =?us-ascii?Q?kMnbntNY5xdOMD26pfweSihCHgaLRWMbFJZEwfPOtG8AYAriEY8NWT7UACvL?= =?us-ascii?Q?GfpuKU/jG8nSWoyKbQxxt1WTUbVqRCxK+udLhMqGCxQju3gM9WrlE3GW07vA?= =?us-ascii?Q?Lico8+I0W7aEsxs0qN8xyNzcN/uJWiEqTvP8wRZKf73eBXNiSUbtA2LC04Nb?= =?us-ascii?Q?sv/yAuZ5q1gNQGtHBuo/iGqK1RpB1hLoBguR1JeCQWLVxsHZ7WRzNPU9RnWc?= =?us-ascii?Q?0sJeRfWrjFC3AwFh/LlGy8O2yuQxOruI1T2tkue6A3s31HbKtYd9Audoqbh5?= =?us-ascii?Q?5ebw+QQC2gbuURIYwBFglGkPEX7LBux+A9hazc0PxQvvowgtD19bMGwa5irM?= =?us-ascii?Q?SgkAtIEteRmbezuP44aMK3/ffC+F5EIcawfngflItbXh5dP/vuoPtKw/5h8b?= =?us-ascii?Q?N0EcJSeH+lqrPdNzVz0qX2SylluGTnW14kyzy89W88pqlJTIXTSowwZDUqUs?= =?us-ascii?Q?yslXs+eRLtrMs4nHEF+zHIg2iEdwYlboBLaGX07Su5a90aS1A8jdzQ2i7Q8t?= =?us-ascii?Q?M5xCVjB7wOHn/ahvqGl6WAby3kgAW2yIdzgjlKnbAeAB0nHms1N787ZLiAqC?= =?us-ascii?Q?ZbaEed7TC1aolw/u5hbbnX1gfeA/T4ifJNHIibKBXP/lkN0n/W5o+UNUIzKH?= =?us-ascii?Q?sjqy3LNbW5jLLn8QE8P3DAdbICXClBTR+D+UVmt7cPccK1IW7DZr52KTEOnz?= =?us-ascii?Q?W+86xUk/jIzWcUdkYjdSlHDtnTcdtsH+YVlev8Pdct9y+x/AbZwA7ZT6bz4o?= =?us-ascii?Q?iyjtecsMdTxcs/v7352wWCgBrS28RZInYnC88qTRsujC5bdkpwddlOE+KtKs?= =?us-ascii?Q?psyNpZBhXYaeIepXe2rUwG8rqrXVvOYRk2rYLfCvGYVj8AR3qG7EnU2Viqzz?= =?us-ascii?Q?XfHUwQ=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 16:50:06.8762 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 50192ebd-25e5-4e4f-d5db-08de59d64c31 X-MS-Exchange-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: CY4PEPF0000EE31.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8526 Not a functional change now that cross-vendor guests are not launchable. Signed-off-by: Alejandro Vallejo --- xen/arch/x86/msr.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c index ad75a2e108..c9cc4f0692 100644 --- a/xen/arch/x86/msr.c +++ b/xen/arch/x86/msr.c @@ -169,9 +169,9 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) break; case MSR_IA32_PLATFORM_ID: - if ( !(cp->x86_vendor & X86_VENDOR_INTEL) || - !(boot_cpu_data.x86_vendor & X86_VENDOR_INTEL) ) + if ( cp->x86_vendor != X86_VENDOR_INTEL ) goto gp_fault; + rdmsrl(MSR_IA32_PLATFORM_ID, *val); break; @@ -190,8 +190,6 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) * the guest. */ if ( !(cp->x86_vendor & (X86_VENDOR_INTEL | X86_VENDOR_AMD)) || - !(boot_cpu_data.x86_vendor & - (X86_VENDOR_INTEL | X86_VENDOR_AMD)) || rdmsr_safe(MSR_AMD_PATCHLEVEL, val) ) goto gp_fault; break; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:50:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:50:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211438.1523052 (Exim 4.92) (envelope-from ) id 1vixt3-0007xR-1I; Thu, 22 Jan 2026 16:50:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211438.1523052; Thu, 22 Jan 2026 16:50:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vixt2-0007wi-Q5; Thu, 22 Jan 2026 16:50:24 +0000 Received: by outflank-mailman (input) for mailman id 1211438; Thu, 22 Jan 2026 16:50: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 1vixt2-000783-1m for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:50:24 +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 706c6b8c-f7b2-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 17:50:22 +0100 (CET) Received: from PH8PR22CA0020.namprd22.prod.outlook.com (2603:10b6:510:2d1::27) by DS7PR12MB6336.namprd12.prod.outlook.com (2603:10b6:8:93::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.6; Thu, 22 Jan 2026 16:49:59 +0000 Received: from CY4PEPF0000EE36.namprd05.prod.outlook.com (2603:10b6:510:2d1:cafe::28) by PH8PR22CA0020.outlook.office365.com (2603:10b6:510:2d1::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.11 via Frontend Transport; Thu, 22 Jan 2026 16:49:56 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY4PEPF0000EE36.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.9564.3 via Frontend Transport; Thu, 22 Jan 2026 16:49:58 +0000 Received: from xcbagarciav01.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 22 Jan 2026 10:49:56 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 706c6b8c-f7b2-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=T+3n0cPcLdk9SVEHj7IowrD+qD4j3QTx9OdQwfolsb4sgjQ58gD6ZjRjwRmW1RsaOH9FUaQRoisXT3M26l2+3KWBftnvBrfwVa+AXcq3ccyPOsI1+LRC6AgrM6+URT2xDsqtwO71dZ1dvdgzSnr2wKZ3rgLLi74F+ze1fGdCQv1446vexcYK5ittF9ctp4GH2UqEt22XbBhWNdKuU2I2KqDyLGk/khPdO/MGTq91sGh1tn5e8qetphZQoWOpSwYy2hNz2ASbNHXEAJTb/3OIDci58r/Va3uVI78tfP9TLajam+dDgEzZJ1jg9h6lLVskUS4goXJED7/9bcv1C54dkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1q3pybJ8njcZIqPSc+UtUPk8iWYvVUF/kPq+Kf/ddO4=; b=eaiGPHbviMO9RbjfL+YOXehUABb2lj7YhCitsVWSpbBKwBEsyFUbGA+v5PLIf/hMp0yokKg4kKe3R20svQjZCTlzy5aWBRbU/UVL1RzA1Ec1+b9zmqperbA1JMpx8W8gex5+SmsTtE2ubBqMNUtZGOKrZX4n+gu2b6c9Q+ehcwdK8ealucb3sLaGCHobZeVlAYkP+uvxot2dnJYkq0fZLMsq7c+bzP3c0gY8D+oV6dNv4NGg/u8PZ8Zz0teO4FIdE+T1Lx5vjIWZGx1v7WxxvHGc05Wpphl3MSabRkCG9l+6XWGd8hY2TTUmuF5CPCHv+7Bey0aoHjCpWCfVE+APWQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1q3pybJ8njcZIqPSc+UtUPk8iWYvVUF/kPq+Kf/ddO4=; b=H+6IuLW1pD9zh+nzHkbsNKk7K/JJHTwweLyFxK7dmSQga4balB12jHmxvbRKMY9yEAGi8dhQBub1Kep5+zJwUtyY3TbmkCFVy+4xXRMMCu2qKmb1cu5sOrNdGFd/Gc8Ou+3DeDJZwggp4PIrVSgLtSfeSjYoM78d+y2Qq1CkMHM= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Alejandro Vallejo To: CC: Alejandro Vallejo , Oleksii Kurochko , Community Manager , Jan Beulich , "Andrew Cooper" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk Subject: [PATCH 0/4] x86: Drop cross-vendor support Date: Thu, 22 Jan 2026 17:49:36 +0100 Message-ID: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-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: CY4PEPF0000EE36:EE_|DS7PR12MB6336:EE_ X-MS-Office365-Filtering-Correlation-Id: bdf352a4-46f9-4ce1-911e-08de59d64760 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014|13003099007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?QlZwbWV2dzNuVlNTb1E3S0srTCtBem5Tb240aG5FVWUwNUdPTjM3YTBmS3ZO?= =?utf-8?B?TXRnUkVaM292RE9sYktXUWpJQmFmYzR5V0c0ZkRJNG1DQVptZ0JHeG9OZVg5?= =?utf-8?B?VjEydHlkRkt4cDlkakswUmJTWE53c3Q5SzRRS2JiZTlQTWNDck83TmVjcEdw?= =?utf-8?B?aWJUcERUWmNwQXV1VmVNRlpqeUFtMFZPdkl4ZmllczlKb05VdTlENHRkZXNW?= =?utf-8?B?czd6YVdROVMyMFdwbkhHdHRycFBOcWlRYU5KMTV3R3RGNFI0ejh4L0xlWTho?= =?utf-8?B?TnlRTFFqcHYyTkQyeHgvMy9QYytjQy9ZL3IwL2UyYkpWOVBhUnlxc1I5UVZ4?= =?utf-8?B?d1c5c2NhZ0hjc0c5L21OYy8rVEVoWkdpM0k5bFFqRFd4OGxHdFZhY1krVFFt?= =?utf-8?B?Tmd0TU9zQXdVUG53bTZKUWx0T3hETm1NR01RTzRDWHpiMS9LV2RIRjJOOHlH?= =?utf-8?B?dGw3dXNXVXBWeFNHdVpmbEhNWmFIV2p6QlUzcWwwY0d4U2NuV1FwNmZUS3N5?= =?utf-8?B?QkdKZVFLZmUvV3JRVFNFQXNRSTFCYzNyMjRMWmwySlVnNWRUTXNCV1A2TFdQ?= =?utf-8?B?M0pDWEFGVm45L3p6WHJQR0xzaFpzc0NxeDc0ZUF3dlpBU3JFUFhLaG56elR3?= =?utf-8?B?UFVCRlRvNlFJVFlaVjhWNjduVnB5bElHamtaM2wyZlNnZk5jeWJpbWpiMmhK?= =?utf-8?B?Z1hBemxGTVdYY3h6TkxPME43UU8xT1dvdHhXbUVHcFJtT08wdGJvWGJMVmd5?= =?utf-8?B?NUdHNWxYNVZuK3lYTjVFYmxUeEdIMGV3bXYyZm5HaUlhbis2akk0SEVzMncx?= =?utf-8?B?Rmx6WTB2NjhaSHJObjJmSkFaNlVicHdocy9rTFM4cGNveSt0TTZ1RVVUTlBq?= =?utf-8?B?aUh4SkFSa2FsU3FvR0M3RDlvNFB4Z2xHV1ZtejZvekJVc21DVlhORGYvd3Bw?= =?utf-8?B?R08zZlV5dzhwTldRbHJQWGljVzVTZjhBSXZUS01MTHgycnpmbUhaZW16Zkdu?= =?utf-8?B?VVJybG5LYmY5WWxEVjdnUVd3cXZKQ2tvMUUzdmwrQXoxZHI5NE9MVkJSLytG?= =?utf-8?B?THRTMUh5RUxLYmEveVFxMXMvSUxiaFBoZFJGVVJmbUN4bnZxSWREd1lTMXE4?= =?utf-8?B?NFJlVkhBa0pzQjhtb2Y5ZDZILzhQb1RVaks5a1k3b3FQaHJrTGZDMDRZUE1J?= =?utf-8?B?Zkc2UndVQnZNb3p4aEJRd2oxVktUa2p4T1NmUGp0cnNlUEMrWW0xRDhtcG01?= =?utf-8?B?MDlUTXdpUElvZzd3Q0NYSGpOaVdFN1dacDA1c0gzUXkwZ1lQYmZBRjlpQ0dS?= =?utf-8?B?Y1JWbXlWbjBnblNEM2dhTFFMSkZjZjVsZHFWL2FBakVvNGVhMlpNajhsWlBa?= =?utf-8?B?WHR2TWR3YWJNbkpHeEdmRVZ5dnhmMk55VE90RWJMWjI0TFp1cnJnYjUyaWth?= =?utf-8?B?anlObzBZNjdDaGVVR2g4NmxrNjQxdDRtU2ptZ2d5QjJsT05LZisrKzFFWjdj?= =?utf-8?B?YVZhU24ySmRBY2dyNzBCTmR4S2ZxTUhsOUhLTUhZcGhWcWFXNXdDS0FySHg5?= =?utf-8?B?dk1MOUxIY0pCckdsVTRzUy9qOFZGVmdsaHpCaXdwTGx3cnV5NFp2ZHQ3MS9t?= =?utf-8?B?YmQyMGIvUmNmUzhtU1M3cHlDbjVyRlFEQm1BREVVSVlGRXpCcjhYZFdkclZv?= =?utf-8?B?WUpaRkR0Z1RuSy83ME1jT1hFbU4ray8yQ2pQbEcxckNWWXBlUDlhd3p4VVhO?= =?utf-8?B?TXgrZG5QZU1TL3NEWkwvZ3VOVHRoQWdzcE8zWDFCeGxOZC9tL0NkVmxtajJm?= =?utf-8?B?UDNEdkhPVlIxQi8xSmFCV0h6emQyNVJRbWFBQk5QTmJWQkZDdTh5U3V5U3pU?= =?utf-8?B?bEdPVWRtbjcvMFdWelFrZkRvNGlTVS80c2JUamNMT2Qrc2UyalhMRHFSei9E?= =?utf-8?B?QnErT2RXMXUrUjI2K3lndWtrZUJKTm9nS09nS04vc2hGMTkxbnRlYUJtU1py?= =?utf-8?B?Ry8vRFFJUFl2d0MrOHJWL21qcGw5UExIWlFXcWJDTktjL2ZXak95a0F4aTBE?= =?utf-8?B?dDhTcHY2c0ZUdGw3RHNtVUlzaWo5T2liS1l0Y245MDB2YUxqaG93UkkxY3B1?= =?utf-8?B?NXFGRG5hSEQrVFJLOUhnakJwejFaWWVxbVNpcVEzZzlTWXFBWFdFY0twYjhI?= =?utf-8?B?a2l6THdsL0xPbDNWWXhxeDZtZWtVTExzcTFPeWhIR0o5N3hkZ2tKcVZXNDFO?= =?utf-8?B?Qk1LTXB0bkhjSUtTLy8wbS80dUpBPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 16:49:58.7703 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bdf352a4-46f9-4ce1-911e-08de59d64760 X-MS-Exchange-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: CY4PEPF0000EE36.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR12MB6336 pipeline: https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/2277124833 (pipeline differs with the CHANGELOG patch being separate. Nothing functional) As discussed in a prior RFC (https://lore.kernel.org/xen-devel/dc68b9ce-38aa-4949-b3e7-a7c0a7ee9a25@citrix.com/) this series drops cross-vendor support. It includes the policy check that was there and adds this on top: * Eliminates #UD handler when HVM_FEP is disabled. * Removes the cross-vendor checks from MSR handlers. * Eliminate Intel-behaviour hacks for SYSENTER on AMD handlers and drop intercept for SYSENTER. Open question unrelated to the series: Does it make sense to conditionalise the MSR handlers for non intercepted MSRs on HVM_FEP? Cheers, Alejandro Alejandro Vallejo (4): x86: Reject CPU policies with vendors other than the host's x86/hvm: Disable non-FEP cross-vendor handling in #UD handler x86/hvm: Remove cross-vendor checks from MSR handlers. x86/svm: Drop emulation of Intel's SYSENTER behaviour CHANGELOG.md | 4 +++ xen/arch/x86/hvm/hvm.c | 25 +++---------- xen/arch/x86/hvm/svm/svm.c | 46 +++++++++++------------- xen/arch/x86/hvm/svm/vmcb.c | 3 ++ xen/arch/x86/hvm/vmx/vmx.c | 4 +-- xen/arch/x86/include/asm/hvm/svm-types.h | 10 ------ xen/arch/x86/msr.c | 6 ++-- xen/lib/x86/policy.c | 3 +- 8 files changed, 38 insertions(+), 63 deletions(-) base-commit: 3001d9a19592bb4f12dab33f161ab2148513e30a -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:57:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:57:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211505.1523066 (Exim 4.92) (envelope-from ) id 1viy07-0001WO-Pf; Thu, 22 Jan 2026 16:57:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211505.1523066; Thu, 22 Jan 2026 16: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 1viy07-0001WH-MP; Thu, 22 Jan 2026 16:57:43 +0000 Received: by outflank-mailman (input) for mailman id 1211505; Thu, 22 Jan 2026 16: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 1viy06-0001WB-3M for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:57:42 +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 7528a3d5-f7b3-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 17:57:39 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SJ2PR03MB7354.namprd03.prod.outlook.com (2603:10b6:a03:567::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Thu, 22 Jan 2026 16:57:35 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 16:57: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: 7528a3d5-f7b3-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=dJKcjGMHCqMg1ZmvRiOdbgHlHwmyqhfvPAd+hKhe+3oDyg73BBJJFMyr8K34eXaulXIUcgNY796LxXAhJyVcwlSwmS7Z8x1LK+J/9BOHXT9e9PYj2SmmtNw5h91h3Sbs3BErvdxCxZ+K6JB8606nleZF3kbjJcxVfB2DuPcaX32PsU/pBUI267G3P2IQNBceHaPGZpB58sCso+ah2s6wV3dNIb1rUc/Gk/rcsNR8xZtNffx5QA0kd5fMlXffZWQxUsLvUY/hbPCnNdoObfMm0d4N91zInwjYe1ucGkD0+SE4nF7nGeWhlAju7tcesuarjgG9OKl3MXdNmzuOyhovGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MOzTUmvMTBwsX3Zo0Iow0xAo0xoyleaeLKb81rG3G4o=; b=WiY/G7TIAjAJIZbtZ/WTG4zTaOXymS8mJCTfnVLjGRT7/m1aGxsem/M0pAxzJQfBndr3Je0oKuaopu+7gb8SFlQHagrG0yK0dzXMVhr8uwzRZWbgLdU8k25wkj/P3McuB/7Ht1T5OPDMvzd2+LgCx9ZF8JG7SYGYWt6QQXoJdj8uhxLUcxz0VMGipt43khNBgN5N5f3ccqnjbG1OlIu3dubMbBHckmjtxwIhJlPc2YOm5kw50Jo5ErmP1y322yzD4AolqcsN2S6s7cE2gGEd/FehstB/6Zm10qHbcqAxE+OzqWnrJ9yvfjNfK/PJgNPdIxNmFeOczLmnSzxuoSrTJw== 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=MOzTUmvMTBwsX3Zo0Iow0xAo0xoyleaeLKb81rG3G4o=; b=rdZnNP2LyC6PUAz7Sc+JkrzOVLX3+GIBAgQdsVd95nYSs25aqmeqnnhF7ydWDn/uZBIpke4MXKW1crJpmqNA6EzQxASSKLuVkkt5dcbENyMyj0/8l+4OLQpDQdQdfl8W+dwB+3YAROjWuydYpRxwGOAithhkscZ5euFvoUw4TK4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 22 Jan 2026 17:57:31 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jason Andryuk Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, James Dingwall , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Subject: Re: [PATCH] Partial revert "x86/xen: fix balloon target initialization for PVH dom0" Message-ID: References: <20260120140648.25977-1-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: MR1P264CA0094.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:3f::27) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SJ2PR03MB7354:EE_ X-MS-Office365-Filtering-Correlation-Id: a3630fc0-e33f-4181-57bb-08de59d75772 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?REdrQ3JJcDkrVkc5dERJaElPbGZBY3VuakFSQ0RjbCt3VkNpYnZHNWdFRnZ3?= =?utf-8?B?KzBtRTUrTG1XMU5oVGw5b0I2UVdrOXNhcy9aeERkdTJ2TDZqMGJFOTZGTFVM?= =?utf-8?B?TEo0bitrRW43cGduQytCc3VWWU52WVgwZ1JIMHJvVmtDeXVsWkw5TzIxeUZr?= =?utf-8?B?ZnN1OFNxUGM3SnhFY0J1UkUvWGxnczZDSjJsYUxEYitpUlhIVzlPNDJ0SEZa?= =?utf-8?B?Wkk2Zmx4aUNGaC84ZVZ1Wm9nZDZuRzFHZ3ZZbmc4Tkd5Ylp4bmVZZVR1QWI2?= =?utf-8?B?QUVRTnV0Y0YvMXU5MWl4bkFhbzZZd2YveHJ0cVFraWxYdVpYQUtGWUhpOTdn?= =?utf-8?B?WE1wTlQ2MXVraE8zYStOUklhTU9XNGR4NUdZcERQZU5aKzZYUWlTcEFjS1dI?= =?utf-8?B?RHVXa09qNHExRDhtN1dzZmNKV0NMVmpUZ0FzcERqYUhqQ1pQNlNENytqVllG?= =?utf-8?B?ZTBkSVpSK2kzRzVNczR5UWRTdjBSWm5zUG4xRG1lS1J5M2R1YzNRUEdwWXp1?= =?utf-8?B?U25MVm5PR0M3ekdueHRFM0dZSnBGemM5QVlnSExrQWZFUnlMY25LZCtiVWNx?= =?utf-8?B?bk9JamMyNWUwRFcxWlQvazk1VE95elU2V3NFODJ1MExLWFJjcWtrZ2dOYWsv?= =?utf-8?B?Qk9uSDR0Y2Jjb3I2aWZGY0FocldDeERHK3NLYTFvVENmcjJINGZnNEMxYWVs?= =?utf-8?B?SHJOVVRDcktMMmhkeDZubWwrQXlHT2R5ZEQ0bFE5dmh0YjZTYlJwemVMS00v?= =?utf-8?B?T2pQM2RkVFpjYkhjaWxWNkF0YzRmZlFCNzA3c2puR293ajdBOFovVFh0b0Fv?= =?utf-8?B?M21NeUM2RzdybWMvRkxnQTRlVll1WHlDdGswVFJrSjNhVkFWb2pmYk9nbHMr?= =?utf-8?B?em5LR1FpVC9JVFRlV0t4NVJZVXFmTTk2WDJxT3hBaVp4d2RvMWloTC83REQ3?= =?utf-8?B?dndiNHYvdjN2aXAzRUJyUDJHY3U4czhWcEc3SkwxU2FaYlgwNmtRc0NNOXJq?= =?utf-8?B?Y2REOElzelNSV2RZUGJsTDZEL3hFcEp3N0VqQXpOQ0tmZVRGd1hGaHl3Y2hH?= =?utf-8?B?RDYxWHE3Mit3VXEvVlJSRFdqSUVLVVp1NHdYeUczVkRSLzhwYmc5aVJ3RVly?= =?utf-8?B?S1NVT3JXcURGcDh1ckFtbUVlYkNaMkdpenFiUFhGZ0RzdllBMTVuK0NkSUZW?= =?utf-8?B?RzNSQ3pmdU9yUjlPL3hsMDlGblRDa0YzUUZURmZWejk2YUxsY1NQdnlmVDM1?= =?utf-8?B?akZ0R0trWFQ0VFcvd0VUNzQxWks2R2VROHF1MWpuTjFKT1A3VlBNbjVPUU5D?= =?utf-8?B?QzEreHBYREo2ZEUwaml6YnIrbmNNZSttN3V0TzhQeG5JOUI1eTZWTVYyV3pk?= =?utf-8?B?TzJzRG9nd0R2bFFJRSsrZW9hcFlxOXIyMzkyUWNwZFZIeTR5VHVjcGNkVDFF?= =?utf-8?B?NnozbXR2a1hBN2tYTERxZjhXY1pHNzFWNmFyUGpocDFmYXFXNk1yQUFrMk9a?= =?utf-8?B?V0VTVklJSHlhWkV3dG5aYStBM0JySzJxT1MweHJ6VFB4Wmo1dE1BYWRZem1T?= =?utf-8?B?WitCaVVnZHNpTURjYmpNb2pTVzc5SXRyallCVzg0bVJjcTQxR25oaG55VDY3?= =?utf-8?B?QzFRS211TEFoOWg0Y3FCM2ZCSDdnTlpJRzFvMGFuUmI1djVHdVZNRTFBNmxQ?= =?utf-8?B?Sk95WERvZE5pbk1uemxpTHhpd2xvWVFLRVlPYmVFamJjaEdnU1ZvOUFXM00w?= =?utf-8?B?V2MyK1pRdlkrNndqb3FpUnA3TDB2L2t5dlIwblkrbE1mRXYzbXZzQnE4cTlq?= =?utf-8?B?WDZ3RDlQQXJWdDZLeHFsSFpWdEdTR25BV1BZNWg2N1RiaHQxUGIvQU5GVm9T?= =?utf-8?B?Tk9XUWtsZFZSZzJvUm11RkJhWlZFRVdKS2RVTGFYYnB5empLcFA5Tk1Gd2dp?= =?utf-8?B?ZUNValBPR3gydXA4T3V1bE9RQ1ltVlRYSUI1WkNORGc5c1FlT3ptOFoxSHF1?= =?utf-8?B?ejd6dzFibDNWK2lQdTJIUlVpUm9JUlF4MVZ5M0tiNW5McFFSTmg1eFFvWFF6?= =?utf-8?B?cnpIVDFMckR3RnVVd2RNd0FhSmcreEpObnF4dnNQRDVhODcvOUxta3c3VWlB?= =?utf-8?Q?L6+k=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?N21FOTZnWHV0TDFVS0FkekRlMUJMa0duekoyamJ0U241Qm1ZZFpSeDdqejVC?= =?utf-8?B?bnNwcTB2OWRyRTNDYjc4bUlMZFpoQi9FYXhBbTJ1NENnOXY0TjNZOUdtTkhU?= =?utf-8?B?QlFCTmsrWUJ2TStERWlYVE1aU1hwZVgySEdzZW1IVE1pY0xqMDZlU1RMdk0w?= =?utf-8?B?Tmo5WjljaEJMYWplNTVNdmo0bEprajBYVGg1bzhrd0dPM1YveU93THZqSzNH?= =?utf-8?B?MmppcjNRRG9nVmQzRFFUSVFqRmtEL3A3d0paSTBBZlFuR3JpckJoMm9yNlJN?= =?utf-8?B?TjJDb2UvTUtNQUJmNlQ2WVZoUUhodmFnb3dRc2JCWUNta09sR050VzJYaE02?= =?utf-8?B?L0RJdHlWdHJSTnhiNWd5NUlNekxZVDVqWWo1ZUZqRjdZL0xkOXVoUnZ1K3ZC?= =?utf-8?B?Y1BSRXJ1MzArWkgrM0h1M3hWbDhackYwZFVZellTOVRTYVVkSnNwZjNFSEZh?= =?utf-8?B?OXp2VzJPM1pGR3VyK2lSd3JPaEdNZnF5VnFmOWFSSlc0WnE3SE4vNGR1bnBY?= =?utf-8?B?d2lPbmJuQkoySkxaQkJZWjBCbW44Qjh3QU5DLzdkRG5PL1RkQzE1YVJCdEV5?= =?utf-8?B?YVZ4bHN1NGZBRjFHSmthNXdjYjB6Qmdid1h4Zmo4Q0U5TjFUelpqNjg4NlRF?= =?utf-8?B?cTNSUTBHbHVicEYwWktEYnNLSThrU2dYRCswa01GS0hNOW0vK09CVGV4dzlZ?= =?utf-8?B?VWkwanlMMU1KQkN3anBCYkVHNCtaUms5djFLdmNncE1qcG5QakNJNzVHUThO?= =?utf-8?B?Tm5RK1FFZXhuYXZOVzgzNCtobDZKeGxOUXJhVHhZdUZsMmRKejRXVVRxRDB5?= =?utf-8?B?RWZDSmtoZ2tabExrSXpwK1dBZmtML3J5SUthbU9UNUlFSTU2SnZQb0ErOXZE?= =?utf-8?B?d0VpNmZMSE5vaVg0bHI2TEk4dW03TnZyWG50Wm5xanExVmlSMW9ua3ZIZSs1?= =?utf-8?B?Q0NhOGVadXhTTkpmWUlEclpyUjg4SlZSRGVsMExrdmgvSGRRTGc3Tm9iRkFy?= =?utf-8?B?SkNZTW0ybWcwcG5nWENPMStRMENLWU1LQ2F5VkYyVVg1MEVsR2svR25MQ1cy?= =?utf-8?B?dHJpRVh4blZRTWlxQndYeFBGSXNiR2pRSjd4RDN0M0p2OWVKc05DY21jeG1t?= =?utf-8?B?NzJISVBDZGwwU0hzcFhrNEJuS01DZFMzVS9VSkNzdHRQb1FDaUJWZG4rbFBa?= =?utf-8?B?b3N6U09mY1Z0QzNJcDZuNGZUbmhLMHBDdmVxb01kRUxsTlFmQ3pCWUgrWjRj?= =?utf-8?B?U1NxeG5kT0xmRi9vVTVyNHdscmN3S2NTVzJXdjN0NmEzczAxdFJVYUcwRy9q?= =?utf-8?B?bkJxVEdhQ0IyVGVudlpwbFlSWjZRYWVJaGtoRFVhQnNBWnJaTW9YN3YzcWZB?= =?utf-8?B?RjhOWkRMcTlVWlBXWkV0Y0huT2hZdGxyQ2NwTXBuOXd4YmNsTkdJcGdXQlMw?= =?utf-8?B?QjdUdmUvMHlHc1lSSWZyMWNkZnFpQm1LNTYrOXhSWU1RSzgvTWpPSjN0TktQ?= =?utf-8?B?RGJ5dTZGNkFNUGJqa1Z0U0dOTnhjOUhBOGtMaEQ5RXNxK1phcFZTRWxDdnl6?= =?utf-8?B?Y0ZXcTlvRXNnMkNmcUhWTE9LaUw0TEN2SmRaMzNtNXgxWi9LaVlUaGVlMmdw?= =?utf-8?B?TzJ6NHF3ZXN6eTBHTEIvRjUzQXZla2ZNbFZvTGRxOEdiRGl3YWVoNENWbnht?= =?utf-8?B?K3FtanJkU3A0ZlZQZWJsTUxMVDAvRU1wZXpyWFN3N3Y0U3lYcW1RMlZIdHVz?= =?utf-8?B?VXhBRHRZWkViTTVZa0pjRXNidHZBTXZwNlRHdUxkdkJFOVFtNEdTZm55dzlP?= =?utf-8?B?ZnByZlJrVGxIMjlNeEN2QVlHNTgvQUJDS3NqNDdQYUdnK2JBYTJpVWR0RVkx?= =?utf-8?B?c1VOWHZmWUFzenpSanV1TGw0RmJ2SUVaemxzR2lpNjhJbG9Yd01hYXV6RFVv?= =?utf-8?B?NlhxcjVJeURNVVh4WEczU3hLL3grVTlyS2NlYm9DL3BOU1pMV2lSZ0NoTmxw?= =?utf-8?B?Z2ZGaFdTaEhpQXdJU2JpOVNVcEhKVFhueUM2b1VkcFVwSTVJeEp6WVlCYVhK?= =?utf-8?B?QzVNVG1CKzFqOXRIbURtSi91UlZSaE5HMVdzZVhVRzQrZVpFdmJ6OUQ1NVp4?= =?utf-8?B?OVovV01VbXhQU04zWTNoVEFLMFlrVDZOeHJjUlRieHRnenF2aHNCbzRHRk52?= =?utf-8?B?UE1yb1ZZR0RJbWNaa0plWkhOQnFhY2F6djZDWHdFNnJRdWxEUVVScjgvb1FV?= =?utf-8?B?SENuSE5SQ3F3ZEQ4cmpkQWttWVJ3UHBoajNyK3ZWakV3MTM4Z1hnZDNORDdL?= =?utf-8?B?MTlDaytncUZlbWhrK2lUc1JneGIzMkRaNExrdjZnMlIyaENVdmozdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a3630fc0-e33f-4181-57bb-08de59d75772 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 16:57:35.5473 (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: OWVb+Zy2N9wRB1OnqoWyNJpUf83cI7gIx6UErjUEeSGEcNgcGLpAUKTYVjb0TVQMhi87L5jZqHwOfJQ/pnokSA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR03MB7354 On Thu, Jan 22, 2026 at 09:40:01AM -0500, Jason Andryuk wrote: > On 2026-01-21 12:49, Roger Pau Monné wrote: > > I haven't tested it yet to see whether that's OK to do on PV, I would > > think PV and PVH would be the same here, since the setting of the > > xenstore target value is based in the return of > > XENMEM_current_reservation for both. > > On a system with 32GB and dom0=pvh dom0_mem=7G: > > [ 0.295201] xen:balloon: current_pages: 1835007 get_num_physpages 8220126 > xen_released_pages 6385120 > [ 0.295201] ------------[ cut here ]------------ > [ 0.295201] Released pages underflow current target > > 8220126 - 6385120 = 1835006 > > And also for PV: > > [ 1.406923] xen:balloon: current_pages: 1835008 get_num_physpages 8220127 > xen_released_pages 6385120 > [ 1.406928] ------------[ cut here ]------------ > [ 1.406931] Released pages underflow current target > > > So we don't want to subtract xen_released_pages for dom0. Is > xen_released_pages expected to be non-zero for a domU? Oh, yes. In fact I think the patch here is wrong for PV dom0, as it shouldn't subtract xen_released_pages from xen_start_info->nr_pages. I will need to send v2. > IIRC, for a domU, xl writes the xenstore nodes as the ~build time memory > value, which doesn't include video ram. Later QEMU populates the videoram, > which increases current reservation. Then the two values don't match when > the domU initializes the balloon values. Yeah, the modifications done to the physmap by QEMU skew the target, so what's in xenstore doesn't match what `XENMEM_current_reservation` returns. However is very hard to fix this. We could attempt to make the toolstack write the xenstore node based on the return of XENMEM_current_reservation once QEMU has started. Sadly a domU would have no way to know whether the xenstore value accounts for the QEMU consumed memory or not. We would need to introduce a new target xenstore node, which is equally messy. Thanks for the testing. Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:59:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:59:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211533.1523075 (Exim 4.92) (envelope-from ) id 1viy1K-0002RR-24; Thu, 22 Jan 2026 16:58:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211533.1523075; Thu, 22 Jan 2026 16:58:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viy1J-0002RK-Vm; Thu, 22 Jan 2026 16:58:57 +0000 Received: by outflank-mailman (input) for mailman id 1211533; Thu, 22 Jan 2026 16:58: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 1vixqi-0007Ij-4j for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:48:00 +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 194c7e37-f7b2-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 17:47:55 +0100 (CET) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-655af782859so2338396a12.2 for ; Thu, 22 Jan 2026 08:47:55 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b879513e951sm1686014966b.7.2026.01.22.08.47.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 08:47:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 194c7e37-f7b2-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769100474; x=1769705274; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=0wg7KIGfayug5C3vvvCUGP++rm9Fv8txuX7xpHEfh2s=; b=ZoiSw9nTLb0T4wBpp903Ds8wqM9o9Sm6Dh9J6DPgxS4HinulO1QXcmEMb4C9DuLpmM OagYuVHY3Bw79Y+iYCiqXVxHL+uJXw5KltzBwL0/6ajdr8O/4Om/E97LjTiXUCgGRJ8x Xrt9LOHfh0ZQTSp1SHWEJpDqtA5L46y38EGfxyn+HcU365obe1lUHxnh8yOj40Qoit/E PC7EeXrZYvBHVlwxvvHz6CFRsYxBPy3zgXtD/MjAz+jYAmfzaDjLB72Q+TVaJ2ekWyTH dWGrveeHMnqruGNGVXxvtoDmeHY8hgxNlijOpRaUOBN2oT9u1fGwpomrrKs/hZfP+my/ qiSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769100474; x=1769705274; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=0wg7KIGfayug5C3vvvCUGP++rm9Fv8txuX7xpHEfh2s=; b=MdquETWtRmvFtj/w1Lh07SHWTDKrLSvmPc1zdjts6ltXPTcdRJ9f4Dda+9zXnxwFpz l0+F0dpuBCKyzIq858Ict9rZT5yBSjaHmMGVzFwi54S1fC3zvIMl0nujFLYYL8q17+SR t2EDGkXMHs663EPq7RGBft91HlOjvjNxk7HfcrDKFBqDKNW8fZcbGvbz/SDz1fn6OjcP j+2IomucNPUR+BdKsM0RgNqDuO6CI3sWC5yl5VFM4IXT5owzIar3nZj1bkACO+DBVKBF 56SwDbbucCNRYYaV6RnqUVK8VTaTwXSiVA6bpbICrAov3nXPA4x915/C1XNqsWj1erFH RzOg== X-Gm-Message-State: AOJu0YyCEibiH7J3YuE90+ESyuMd/1Pwh2XkqBk0fJYHDFdcr3AOcjdY kCYr0h89zmMS/2gdMOj4CdJ0zBskIDgsp+RD5tvuVYJEEONSTl40S0GJNSIB5w== X-Gm-Gg: AZuq6aI7JuB/+qF93qa1HDoozSwJz+6PtQzW5xMpnb8OOjowY1a2MkPRsrX4BgVt1de Zjbt8stWPhktl/r+0ToCq6SotJVxvALsasyefzgxTOfQjqezUoUSJMNMo9hk2cz6OLJ9A2f8WPE BxeQta2NUe6AsAtsztzwSvlhahGEyZYaP8Zbqd2pcSzBXXL5vzJZb5xUcgS2fC9ZTWmvIwp9LW4 XQ8mHGhd4cxat2X2x2eHyvzjAmIa/ebEV0ZAjX/bNWnr6/5U+0D97k5X2+dyWHsnSoetDgWCu+r PdyXu7MxtPCqN8ydt3/k9EJfeKV1OaEY2C8n/ytON9/EZpZTMKA202VzHj98wLTy/O9biQBE2RY iQHQDW1jLip2wh4NJ+F3d2nJeaLflm3uOjFSM5q9KsyFgPL8RvYT/cha2+iE6KlZYsQ5bbIrqo8 rTQ3nBac3Jc5UvpBbLWPIAlYGuVSYHgGT2qnBDrS4YNdHRQqVIlFXjbA== X-Received: by 2002:a17:907:c07:b0:b88:4b1f:5b1f with SMTP id a640c23a62f3a-b884b1f64c2mr111863966b.38.1769100473895; Thu, 22 Jan 2026 08:47:53 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Romain Caritey Subject: [PATCH v2 12/16] xen/riscv: introduce sbi_set_timer() Date: Thu, 22 Jan 2026 17:47:27 +0100 Message-ID: <2fd4da2ad7c4af2241368edba739b24d0e976552.1769099885.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Introduce a function pointer for sbi_set_timer(), since different OpenSBI versions may implement the TIME extension with different extension IDs and/or function IDs. If the TIME extension is not available, fall back to the legacy timer mechanism. This is useful when Xen runs as a guest under another Xen, because the TIME extension is not currently virtualised and therefore will not appear as available. The sbi_set_timer() pointer will be used by reprogram_timer() to program Xen’s physical timer as without SSTC extension there is no any other option except SBI call to do that as only M-timer is available for us. Signed-off-by: Oleksii Kurochko --- Changes in v2: - Move up defintion of SBI_EXT_TIME_SET_TIMER and use the same padding as defintions around it. - Add an extra comment about stime_value granuality above declaration of sbi_set_timer function pointer. - Refactor implemetation of sbi_set_timer_v02(). - Provide fallback for sbi_set_timer_v01(). - Update the commit message. --- xen/arch/riscv/include/asm/sbi.h | 18 ++++++++++++++ xen/arch/riscv/sbi.c | 40 ++++++++++++++++++++++++++++++++ 2 files changed, 58 insertions(+) diff --git a/xen/arch/riscv/include/asm/sbi.h b/xen/arch/riscv/include/asm/sbi.h index 79f7ff5c5501..e0e31d7afa20 100644 --- a/xen/arch/riscv/include/asm/sbi.h +++ b/xen/arch/riscv/include/asm/sbi.h @@ -29,6 +29,10 @@ #define SBI_EXT_BASE 0x10 #define SBI_EXT_RFENCE 0x52464E43 +#define SBI_EXT_TIME 0x54494D45 + +/* SBI function IDs for TIME extension */ +#define SBI_EXT_TIME_SET_TIMER 0x0 /* SBI function IDs for BASE extension */ #define SBI_EXT_BASE_GET_SPEC_VERSION 0x0 @@ -134,6 +138,20 @@ int sbi_remote_hfence_gvma(const cpumask_t *cpu_mask, vaddr_t start, int sbi_remote_hfence_gvma_vmid(const cpumask_t *cpu_mask, vaddr_t start, size_t size, unsigned long vmid); +/* + * Programs the clock for next event after stime_value time. This function also + * clears the pending timer interrupt bit. + * If the supervisor wishes to clear the timer interrupt without scheduling the + * next timer event, it can either request a timer interrupt infinitely far + * into the future (i.e., (uint64_t)-1), or it can instead mask the timer + * interrupt by clearing sie.STIE CSR bit. + * The stime_value parameter represents absolute time measured in ticks. + * + * This SBI call returns 0 upon success or an implementation specific negative + * error code. + */ +extern int (*sbi_set_timer)(uint64_t stime_value); + /* * Initialize SBI library * diff --git a/xen/arch/riscv/sbi.c b/xen/arch/riscv/sbi.c index 425dce44c679..2c7757c8839f 100644 --- a/xen/arch/riscv/sbi.c +++ b/xen/arch/riscv/sbi.c @@ -249,6 +249,38 @@ static int (* __ro_after_init sbi_rfence)(unsigned long fid, unsigned long arg4, unsigned long arg5); +static int cf_check sbi_set_timer_v02(uint64_t stime_value) +{ + struct sbiret ret; + + ret = sbi_ecall(SBI_EXT_TIME, SBI_EXT_TIME_SET_TIMER, stime_value, +#ifdef CONFIG_RISCV_32 + stime_value >> 32, +#else + 0, +#endif + 0, 0, 0, 0); + + return sbi_err_map_xen_errno(ret.error); +} + +static int cf_check sbi_set_timer_v01(uint64_t stime_value) +{ + struct sbiret ret; + + ret = sbi_ecall(SBI_EXT_0_1_SET_TIMER, 0, stime_value, +#ifdef CONFIG_RISCV_32 + stime_value >> 32, +#else + 0, +#endif + 0, 0, 0, 0); + + return sbi_err_map_xen_errno(ret.error); +} + +int (* __ro_after_init sbi_set_timer)(uint64_t stime_value); + int sbi_remote_sfence_vma(const cpumask_t *cpu_mask, vaddr_t start, size_t size) { @@ -326,6 +358,14 @@ int __init sbi_init(void) sbi_rfence = sbi_rfence_v02; printk("SBI v0.2 RFENCE extension detected\n"); } + + if ( sbi_probe_extension(SBI_EXT_TIME) > 0 ) + { + sbi_set_timer = sbi_set_timer_v02; + printk("SBI v0.2 TIME extension detected\n"); + } + else + sbi_set_timer = sbi_set_timer_v01; } else panic("Ooops. SBI spec version 0.1 detected. Need to add support"); -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 16:59:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 16:59:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211542.1523085 (Exim 4.92) (envelope-from ) id 1viy1V-0002oU-9H; Thu, 22 Jan 2026 16:59:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211542.1523085; Thu, 22 Jan 2026 16:59: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 1viy1V-0002oL-6f; Thu, 22 Jan 2026 16:59:09 +0000 Received: by outflank-mailman (input) for mailman id 1211542; Thu, 22 Jan 2026 16:59:08 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vixqj-0007Id-NY for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:48:01 +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 1b2afd50-f7b2-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 17:47:58 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-b86ed375d37so142095166b.3 for ; Thu, 22 Jan 2026 08:47:58 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b879513e951sm1686014966b.7.2026.01.22.08.47.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 08:47:56 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1b2afd50-f7b2-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769100477; x=1769705277; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=dcpUeXukHvpe2V8ajAwhudISERtpAWc83oml7NTTtzQ=; b=FrOljl7VtmHeX3Mr3lRguhO6SiLEoduNjNLKWcrngyVMRLxijP6gQJuo7sRa2WTTqZ NVK49joXFKzOEIC4/xoYH0v4xrqXaxXRvtzDIM06Jno8gX7uAj9nV38GTOTgzKY9z3E1 Oioq2WrKh0sNPDCTbbMa066VkFYfXKtuUepf324XucmUHpI/B55aWu/Go/pj6FzJnUvJ sAr5zR166DCJVpUp2JYUS4e/LzSydgKkdvqYEFYL2GO2mRX80mr9eDAoZowjgDgfNXzx 6Gg19MS7vmz39f8njfdTRmVeCb9+6exp6crWUw5oIqjFUCMfukAFT5fc4p24O/zdUTjK szzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769100477; x=1769705277; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=dcpUeXukHvpe2V8ajAwhudISERtpAWc83oml7NTTtzQ=; b=ErE/rtaikJrJEzQsTa7I3FDtPADv4WjzETVrXv2TfpXNINizcw8Sqi0M7dSqE3vk1J gGi3bYb1GB5AyZJzeCK49TLa3zd1SIeoi0KS5L9CVKbaycZdOiaSY2GSO+ZV9aO4/ZCl XYF+wlTBkgpNPu71FEMY5Wug5+FFQTaWyC2oOtxA2ZDCjLToHuvJcu/QrBxT84ktOa4k yxa1ic9YEAbAOxiuubUeA1dv98Hd+ESNStAIi9EFS5klN/OrKS7FK/qR266hn1XP16+w Xv94KjyaFGyw2iHaxdKcbGmqxNKiE6m/8wJErE638V4lo6oILNd612Ce3X6nJZQ/fEWi v1hQ== X-Gm-Message-State: AOJu0YwehBmuUk10gpOlZzECWhn3EBL+OQZTdnyPY3BfuUj7u3safAV6 E5AMwyp/rwLnymzWsObdHA5pb9IlamSUe92VLKJlr6x1Vuxn3lfEEF8hAXHwmw== X-Gm-Gg: AZuq6aJ8J3uy0dySaEVXIlCIEkWXI2t5ozLanitVN6VZiaPbtYdh+8CX9Z8458YnRH6 hiOs3dwqLCh9+iq+5EnBLKVeEXv5oBk9P41Badx6MPKZJlja6QPEn5H170LqviWSjxaRfGlkRpl 1qFfa1XsND9kG3m3yhnQzxIGxI0sYOSipsmT9XMkc8c86PYqIdURMc+Cm23Vx4v1Fs+RzZD6C4Y 4PdstDK/Hi+D7/taqpBaog5dFMtfcypLeBI5+4lhw+vH40DbGJaM7F957Lh3aYUIpMenUMNpYch HPsPeYyma98H2M8O1CpQwEaNhhaHgOsq9rgjCp7tYncS1/qFNkbA5uZT+S6Ijc0MqEt7LGXHTBi 72ZcGZnNb/oRxB+nNs0DjiWhCQnirmThxwfSj+gwbhx0E3Gw9osMWDrZbgPFIfzh7URbUFCZy3+ Skuu3FZ3HPbAfhLMw4K580sJ3OQIRJBOAWzuoBaJPqtvBNSChEN07GJg== X-Received: by 2002:a17:907:3f8d:b0:b7a:2ba7:197e with SMTP id a640c23a62f3a-b8800449ffdmr703667866b.29.1769100477230; Thu, 22 Jan 2026 08:47:57 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Romain Caritey Subject: [PATCH v2 15/16] xen/riscv: init tasklet subsystem Date: Thu, 22 Jan 2026 17:47:30 +0100 Message-ID: <36c05146c82f20f7760ec7f1de9700a2f1c698d8.1769099885.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit As the tasklet subsystem is now initialized, it is necessary to implement sync_local_execstate(), since it is invoked when something calls tasklet_softirq_action(), which is registered in tasklet_subsys_init(). Signed-off-by: Oleksii Kurochko --- Changes in v2: - Update the commit message. - Move implementation of sync_vcpu_execstate() to separate commit as it doesn't connect to tasklet subsystem. --- xen/arch/riscv/domain.c | 5 +++++ xen/arch/riscv/setup.c | 3 +++ xen/arch/riscv/stubs.c | 5 ----- 3 files changed, 8 insertions(+), 5 deletions(-) diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 13ac384c4b76..1458902aff82 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -254,3 +254,8 @@ void vcpu_kick(struct vcpu *v) smp_send_event_check_mask(cpumask_of(v->processor)); } } + +void sync_local_execstate(void) +{ + /* Nothing to do -- no lazy switching */ +} diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c index 9b4835960d20..e8dbd55ce79e 100644 --- a/xen/arch/riscv/setup.c +++ b/xen/arch/riscv/setup.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include @@ -133,6 +134,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id, panic("Booting using ACPI isn't supported\n"); } + tasklet_subsys_init(); + init_IRQ(); riscv_fill_hwcap(); diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c index cb7546558b8e..c912d46f1e42 100644 --- a/xen/arch/riscv/stubs.c +++ b/xen/arch/riscv/stubs.c @@ -91,11 +91,6 @@ void continue_running(struct vcpu *same) BUG_ON("unimplemented"); } -void sync_local_execstate(void) -{ - BUG_ON("unimplemented"); -} - void sync_vcpu_execstate(struct vcpu *v) { BUG_ON("unimplemented"); -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 17:00:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 17:00:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211577.1523095 (Exim 4.92) (envelope-from ) id 1viy2X-0004kG-IM; Thu, 22 Jan 2026 17:00:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211577.1523095; Thu, 22 Jan 2026 17:00:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viy2X-0004k9-FO; Thu, 22 Jan 2026 17:00:13 +0000 Received: by outflank-mailman (input) for mailman id 1211577; Thu, 22 Jan 2026 17:00: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 1vixqn-0007Ij-52 for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 16:48:05 +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 1bd9100b-f7b2-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 17:47:59 +0100 (CET) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-b8842e5a2a1so115010166b.2 for ; Thu, 22 Jan 2026 08:47:59 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b879513e951sm1686014966b.7.2026.01.22.08.47.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 08:47:57 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1bd9100b-f7b2-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769100478; x=1769705278; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=KZA8ihisriROMO2vLm1yqQjETNpKnWgnKN9uanVzkRc=; b=aJ88qnAjcU9/TFsl0BVagsFiu/yKfXwVrWIV5Cc8TNUlkJPICwLSgHHKSk12fupVz4 zz1N5BKosEX3p01vjZaBvf7bJVWp0NZqEE75SOk7o5/otBl1XNlrME4nw5Ji+f8nSvH5 UJsuYGkdDVwnBVhLL0RQZO1uVNLhShwGapLZiqf5c4+2DThwnUVmxF+YSev1zvBXGkQy wQcDyGrhReFQ15WOxEeREYvS6IqrDWcd0rn0tZTPulnIX3wn5mE8kpiwis/b+gLb0E/S SzMjA2xNI3yabvvvREQEj5U/24S6mQKEsWHmZ3+pZGVr7efag8pGMPFVXOxaisSYL+qo nczg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769100478; x=1769705278; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=KZA8ihisriROMO2vLm1yqQjETNpKnWgnKN9uanVzkRc=; b=o0zQcqXvTt51qEL82S5Mh3EOn8x5/KuP6bx4qJptw/c2GnW31r2FAdjYsOJNJEY9ka cDghZfRsFdFT5TW4XolCO+Kg+41DdZb8H6nL56M057drRs9VB/Et7qcDfuczGTn//tcJ d2UDCQilJL/AOckZHAFPeOtDiSrYXyCKaOSflCL40nWsvv5CFr8ALu269QbSYNRduVrN fW/vwyjGneLdRNac5aN4Wo2g9woHr2uQl5IdZM8/Vpd77EOy85b1gH6++6Nt6H+tp5S/ 1S/ydyc8k7A93T0ylm2sBvonbqhRot6jV8KSQL+kHkOxqpjdC2LOe+0HPAdPzquGj/KN 7pSA== X-Gm-Message-State: AOJu0YwjnBUABx5VZLu883FougsdWlGcKnpidxEBARb9BpgGBXa6hZ3g 4ifUVZfG0rNUhSCgyprX8NE8lf5VU93pROg4UqGvnoEAcvulsIKDB69BMLcbDg== X-Gm-Gg: AZuq6aLNYu9ixBVRsPuspUkIASzQyM1dObG7HDVMrc7gofsq3Oe2Hde1ROmCz2uQUwm +9+RUaxLReUHYnv4FJa7AuabIJ+gBRJY6I4bpOgcJNgult6HK86QKzQFu0gAaXtlS0hEA8EZCf4 Dl0fcH7Pn8fTy7xNr6Lu18l4mxlxfygqmVb1Ii/6LCi0AMZPSPcnZqiojM/lZPcap6biF+SLndF vaOlSiBLT5KsfR79N87HEmLQVgVqDztPJQRpHRl8i1ivsK7XYtvCObPiCXEA7Zx5PtsCSzU5gPY Ma76zj4uO8M4z2Np7X3EvH0HLANfACyC45pfpXvfnSIDFpuZRyloYvGbRI0ZL64Of3K7EVeeqnZ shMQMGvgZSK0aCPbyp+xi4bF8jV/ypQuGNoKRfda4r1eyUaKT6RK0zH8wToKeIPffiPewniatd2 /8ga/N9N1diE24l5viwneK0k9bhWwAThA1C7X4M+/sMisAHmXqsLozNg== X-Received: by 2002:a17:907:84e:b0:b73:667e:bb29 with SMTP id a640c23a62f3a-b8792d3be61mr1668682466b.8.1769100478306; Thu, 22 Jan 2026 08:47:58 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Romain Caritey Subject: [PATCH v2 16/16] xen/riscv: implement sync_vcpu_execstate() Date: Thu, 22 Jan 2026 17:47:31 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The scheduler may call this function to force synchronization of given vCPU's state. Although RISC-V does not support lazy context switching, a full memory barrier is still required to order observation of the saved context correctly. Signed-off-by: Oleksii Kurochko --- Changes in v2: - New patch. --- xen/arch/riscv/domain.c | 18 ++++++++++++++++++ xen/arch/riscv/stubs.c | 5 ----- 2 files changed, 18 insertions(+), 5 deletions(-) diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 1458902aff82..48ba7584acaa 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -259,3 +259,21 @@ void sync_local_execstate(void) { /* Nothing to do -- no lazy switching */ } + +void sync_vcpu_execstate(struct vcpu *v) +{ + /* + * We don't support lazy switching. + * + * However the context may have been saved from a remote pCPU so we + * need a barrier to ensure it is observed before continuing. + * + * Per vcpu_context_saved(), the context can be observed when + * v->is_running is false (the caller should check it before calling + * this function). + * + * Note this is a full barrier to also prevent update of the context + * to happen before it was observed. + */ + smp_mb(); +} diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c index c912d46f1e42..26434166acc6 100644 --- a/xen/arch/riscv/stubs.c +++ b/xen/arch/riscv/stubs.c @@ -91,11 +91,6 @@ void continue_running(struct vcpu *same) BUG_ON("unimplemented"); } -void sync_vcpu_execstate(struct vcpu *v) -{ - BUG_ON("unimplemented"); -} - void startup_cpu_idle_loop(void) { BUG_ON("unimplemented"); -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 17:04:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 17:04:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211600.1523105 (Exim 4.92) (envelope-from ) id 1viy6K-0005V4-4b; Thu, 22 Jan 2026 17:04:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211600.1523105; Thu, 22 Jan 2026 17:04: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 1viy6K-0005Ux-0v; Thu, 22 Jan 2026 17:04:08 +0000 Received: by outflank-mailman (input) for mailman id 1211600; Thu, 22 Jan 2026 17:04: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 1viy6I-0005Up-FU for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 17:04:06 +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 59f9ff25-f7b4-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 18:04:03 +0100 (CET) Received: from BY3PR04CA0002.namprd04.prod.outlook.com (2603:10b6:a03:217::7) by CY5PR12MB6598.namprd12.prod.outlook.com (2603:10b6:930:42::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.8; Thu, 22 Jan 2026 17:03:55 +0000 Received: from BY1PEPF0001AE17.namprd04.prod.outlook.com (2603:10b6:a03:217:cafe::81) by BY3PR04CA0002.outlook.office365.com (2603:10b6:a03:217::7) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.11 via Frontend Transport; Thu, 22 Jan 2026 17:03:37 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BY1PEPF0001AE17.mail.protection.outlook.com (10.167.242.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Thu, 22 Jan 2026 17:03:51 +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; Thu, 22 Jan 2026 11:03:51 -0600 Received: from [172.23.120.160] (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, 22 Jan 2026 11:03:50 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 59f9ff25-f7b4-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ohvXfhrQC2VdVKxyVNAix/KsOmxd8/ZIwQkpU4pPaV7yXiSwa21rJOYD4RMP9Fm5DFsZ31C8FYb2+nnfNrKcoQquZzg+9OL6nJ9a7pUfWOOUmrimS0e9kCuI5YvjFnyyq6cTxMoGoQu7j4a+RYLlOAiUfvBeGljDKi58gYEQ5GjK0vNbr0iyWBY2XrPhFP+qucgYfetmxwWNPL3ivWU9Hdzj/z7qP0ZOYD4tASJSVJrxaUSNRq7nkfU6p2rMbweAJSI3QcuxxaOG/pVZBfZjFZ0awDkY0oBPuUTaDpxM254t1b17EumEq7cmk9/YdXOB4HmeieI9x5E53CitpaSUcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YXIK/3D4yTLUJgAeKxFe8bdxIid2/wGTCuYP5+LSRUk=; b=Fja7NWduJ2Kk8aAzF1ARFmM8F3p+Uif1lshVjAzzUzNZAXPzD7b0KUzJAADqAnofSWtkUIiIOzAV+sHHmYGHDmtfEKzbrjUQsy7yFOlabWXREfgqZJsv1OgQXemmik9sR6+yyLC2wYvcvfX0rUwUuZ1hOf30FhApFRVEsINKCp+NFENRaA8LS68RHBs3Ly32xyG9iJXnVA8INpicbr4+o7oAER3zwLVazO+Gt5b9yrh93nt4M4+BqpLtCBkVfK9KvQ7Xq4Axg10MYKIr6QotkxvyrtyFEALsUXAc/OfcdFQJRiUGF1Kfd61jTO50mDNe4x4CcSg9d8qoDngMxEOp8Q== 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=YXIK/3D4yTLUJgAeKxFe8bdxIid2/wGTCuYP5+LSRUk=; b=sJ/FHh4/whQrtbB5cfmYnbN6fOIcYhJnqBgk09+qbWLHiGEvWe6yf9owH304KOktfvVbxrhgEy7zCLF9142Bqet4vkj5SUcerPYiukj9xJRHFB6zMO4d+qjsAjvdetoUDQNgpPf740wcVWMQvkrri9LIRA1xQibzNeJq6nEwB9s= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <1357dda0-bb5d-4f59-a53c-d584099bf65c@amd.com> Date: Thu, 22 Jan 2026 12:03:47 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Partial revert "x86/xen: fix balloon target initialization for PVH dom0" To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= CC: , , James Dingwall , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko References: <20260120140648.25977-1-roger.pau@citrix.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: BY1PEPF0001AE17:EE_|CY5PR12MB6598:EE_ X-MS-Office365-Filtering-Correlation-Id: cb57eabf-221a-40ca-f1c1-08de59d837da X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700013; X-Microsoft-Antispam-Message-Info: =?utf-8?B?RnhTVW5LR0RheWpEb0M0UVA4TW1IckJxdzBLQ0k1aU9wVmJmdGJSVHdJZ0ww?= =?utf-8?B?b1p5WGN0aFVaclEwY2gxcDhTTDBkTEQrSFN6dEVzUWowdVdMOERjemJPNGxK?= =?utf-8?B?bkZyRCtkeTBicEdYeGRsZmJQTlVTdkp3b3pBMGFrUEdDWVV5MVJnMmx3eDZa?= =?utf-8?B?YXlOODNrWjdXNkFhQTI4dlNQM1AxTHMwaktCVzQxb0lVWkhnMzBWa09lSDF0?= =?utf-8?B?SmJlQlIrU2l6L1ZiTytya0tvb0J6ZG1QY1hjYXlmR1hSRG5ZMzBZNndsandi?= =?utf-8?B?dVFpbVNFTHNwbHZvcFh6eWxBTW9pQThSYnN5dExjSFZya01ZKzhuc1NFTEVh?= =?utf-8?B?ZHVZeTFhcjdCNDBibllnNm0vQUpvMUlKRmU0Zk5lYWs2NEtuaW4zKzkvSXVq?= =?utf-8?B?dnFZVk0wcitkQmwrZFpoL2lCcVp4TW5JTk1JN0Y3ZFJDbVFnWTduTGt6dW5O?= =?utf-8?B?NmpmUEYyNU5tTHVtMGNvVGtTOXJ3MzJWRDN1bDhoeGhUUUVleGVhcjhoWFVD?= =?utf-8?B?VlBsMkUxZWVVRVFMTi9TNFZTQWtaUXZkWWNaVGtXZUpsb3ZIRVE1dWZZbWhu?= =?utf-8?B?ekswWldDZ1lKYlc5czc5Y09MLzV0UGdUN1JKSmlTM3dLSFZsUEpDM1ZYdnVG?= =?utf-8?B?UmMrZDBhTTkrcjRoTlZsT3A3VVFCcTN6R0FJTGJwdmxhQjkvcHlGOWRXTXRM?= =?utf-8?B?cC9oVnNOaEgxM1ErdWZtOVBMa1ZzeTRkSTlNWkkySDF0SGhhT3oxQzFNTTIz?= =?utf-8?B?WVVvSGFIL3hFS3BtWHNPWCtQalZNZnhQUGE1Wm5mM200QkFPTy9IYmkrcUx3?= =?utf-8?B?QUdlYnFpb3RaOUxLMHZuTHRLbmxnQ1A4YUR3WDl4UDR1UWU0VG9JTVFEbmJy?= =?utf-8?B?bVU4U3VoTFFaUG5Td1IzSGtobU9ockZQZVNoNytpbXZmVldkV0FVK1ZFVHlu?= =?utf-8?B?cjZWS0pIR0JTa3I2dDBtY2d3YURNc0M2NGd3S21NSDFrRWNhRkRJOWRYbEFk?= =?utf-8?B?aW05WnNaa0V3Zzl6SHZ6LzJXeXROZCtYS3F4Q1BZaEZYOU80S0V5RWM0MHlx?= =?utf-8?B?K21YRWc5N09DS2ZkS3RSbUpDRnpIYURsS3J4MlNmRzh3ZHdmcVoxVjQ3Ry9r?= =?utf-8?B?Wmo3RCtpaklIN0F0ZDg3c0NabWZpd1pYYUp6Zzd2aU9TVllKb3FvUEtXRWdF?= =?utf-8?B?d2hJUjViMDVwMUFLdVBUTnJwUXkvek1xdEY4NnF6bFBsQUVxM0VFb3NOTGtY?= =?utf-8?B?QjA5S21zWWcvb0hmZ1U2bUpsa0ZCdzdVWkhiYWprYXA2dVY4TFRoV2hBTmVL?= =?utf-8?B?QVo5RE1DTXBQZTFyaWxRYzZmcDlUVHN4aHJyTitKb20wMjB3NXd2NHhETlhq?= =?utf-8?B?V1RmUmttVW9QVXN6MWV4OHFvOTZrZ3JBYi92YmF3d3JRVVh5RVp1R2FacE01?= =?utf-8?B?NDJSK3Flb1ZPemkyaU4vOUZGYzVXKzF6c3FVNU1zY1cwYUpvKzhLL1M0bmNl?= =?utf-8?B?bmg5eWVaSVZiTTRxMlNvdFJ0SzdkR1U0dGcrZW4zNnRsODNwMWR0ZU4wYnlD?= =?utf-8?B?Q2Ntb2pEZTRCMnFFWmtFakllL0tMZ2lGcWFTQkV3bU9Vc2t1eG1WOGJ6MDlj?= =?utf-8?B?cHJ5L1ExalpoTHN6Ti9BYWd3STlEQTZHL013N0Z4VGlTaDAweEF4VDdRdEFL?= =?utf-8?B?Y3NIaVBVdnBLeUtrUW5lU0swbGhnelFYT3RvS0dUSHYwNXdtdCtpWHdTbTRL?= =?utf-8?B?Z21Tb1NVMUJFTlRodzJxK3RNY2tOYm5iczdwSTF1dXlBZ0VWRUpoWTJTcUdt?= =?utf-8?B?cytjb1pZZzltT05hN0FMNmVFUjFtdi9MSm93cFVpUmcyOVdmazRFYlkrQnEw?= =?utf-8?B?U2k5alIrcTF3WUNPWldtZHJMa2VXeTFkdzR4OW5qY0pSRXJ1TlBlS28wZEh1?= =?utf-8?B?b0paK0JNenMrOTFIdmQ4clkzaHJpSzlsZnJ3RkVoNDlNZ1JQKzZTajM2UHly?= =?utf-8?B?VFk2WUVRY0hqSFNKc09QUVlCMkVlSW80VW44LzFqNjZQdE4rMGM1cFhKaVdE?= =?utf-8?B?TjlhZW5rWGhobG9ORGdEZ2hhbHZNeEorbUR1T2FUTEZTVjV0OHhBL1VPeU1a?= =?utf-8?B?ODh5enRsRnBkK2dUL2VCcmxuM0E3aE4yNnN4aTRqeHI5eDNDWkdEQ2dHTDEr?= =?utf-8?B?V2Y0SFUzb0lyQ25wUUpGOGZFMEhMT3ZmZlZoNUpyT0dUY2R6NUVoOVJVZStT?= =?utf-8?B?dmYydmpramdqMjNRTVVaOGRhTllBPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 17:03:51.7012 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cb57eabf-221a-40ca-f1c1-08de59d837da X-MS-Exchange-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: BY1PEPF0001AE17.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6598 On 2026-01-22 11:57, Roger Pau Monné wrote: > On Thu, Jan 22, 2026 at 09:40:01AM -0500, Jason Andryuk wrote: >> On 2026-01-21 12:49, Roger Pau Monné wrote: >>> I haven't tested it yet to see whether that's OK to do on PV, I would >>> think PV and PVH would be the same here, since the setting of the >>> xenstore target value is based in the return of >>> XENMEM_current_reservation for both. >> >> On a system with 32GB and dom0=pvh dom0_mem=7G: >> >> [ 0.295201] xen:balloon: current_pages: 1835007 get_num_physpages 8220126 >> xen_released_pages 6385120 >> [ 0.295201] ------------[ cut here ]------------ >> [ 0.295201] Released pages underflow current target >> >> 8220126 - 6385120 = 1835006 >> >> And also for PV: >> >> [ 1.406923] xen:balloon: current_pages: 1835008 get_num_physpages 8220127 >> xen_released_pages 6385120 >> [ 1.406928] ------------[ cut here ]------------ >> [ 1.406931] Released pages underflow current target >> >> >> So we don't want to subtract xen_released_pages for dom0. Is >> xen_released_pages expected to be non-zero for a domU? > > Oh, yes. In fact I think the patch here is wrong for PV dom0, as it > shouldn't subtract xen_released_pages from xen_start_info->nr_pages. > I will need to send v2. To be clear, the numbers and warning are from the follow on current_reservation patch. Regards, Jason From xen-devel-bounces@lists.xenproject.org Thu Jan 22 17:10:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 17:10:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211614.1523116 (Exim 4.92) (envelope-from ) id 1viyCZ-0007iw-Ou; Thu, 22 Jan 2026 17:10:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211614.1523116; Thu, 22 Jan 2026 17:10: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 1viyCZ-0007ip-M4; Thu, 22 Jan 2026 17:10:35 +0000 Received: by outflank-mailman (input) for mailman id 1211614; Thu, 22 Jan 2026 17: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 1viyCY-0007g1-DK for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 17:10:34 +0000 Received: from DM5PR21CU001.outbound.protection.outlook.com (mail-centralusazlp170110009.outbound.protection.outlook.com [2a01:111:f403:c111::9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 41db60fd-f7b5-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 18:10:32 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by PH0PR03MB6938.namprd03.prod.outlook.com (2603:10b6:510:16c::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Thu, 22 Jan 2026 17:10:26 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Thu, 22 Jan 2026 17:10: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: 41db60fd-f7b5-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=wrTglBN0V3x26TysFlW5UrgVj7/cdYg2SWF9SyronAotdhTFf1ylQPRrFGUl+0AIHPLQuf8xzJ6o6VtC0L0052DL1FDkXk363ygUpeSCHI4eI6FJPMnNlAg0XmT7q7Ledm7AldwfjIreIACUheruPh4OzNN39aV2eqiyicfhiKLbvaH2Xab1BtVjAcaj8hOMoZX08CCd+KWREWalT/PhJrU+B77CT9a2dnNRhBDuiMPBq8JkQuO5Wj+fhuJBfA/QKG07xWHwiYyhzSaLH+QEBu4LEx8qgzXkA6V98ESH6t+Xs2J9wkASP/FkYJKDxQBq/vCcTSOCotYj4rHbxXlSLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0SCiws27Drqk7YSgpE0wXkDEzb90rCNRLgQZh16v5MQ=; b=an7J050JXmrewKPrUwvUBtrL9FFEed2MSZeHekQEvpPu4BSPAmViD3Tp6250Uba2YnPaZR3KqbI91xrYrIi7tcju6TWqNbWYvQD2VE9CkpsYmBxzJ8FU3zJXysmZY3LQZdA12OsNIj1sbxi1+7uWMo7wMGl+xHaqMyuCf+dGjDboC9Gy0xqn34Kt4muXMA90Eu4aPfWjQfO4yIPVCrG+rY1YPDLGBQonhuwqmmzoAsbZfHjgngz7grItsm22pQzn6GuMot+ZOvaylXD5xBmnU2t9e2MERoLTonaP2Tq0vcljHlJT6dirGVIlB2OHVf8RRPCHw/EEiXH3eLnv5+qT6Q== 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=0SCiws27Drqk7YSgpE0wXkDEzb90rCNRLgQZh16v5MQ=; b=chkQl/ciuS2o9bOkFzNHWzCKcWm8HVBxQbkYG5bdR87UfGYif4mF7b2iKLVpGUhV0O76mSTvMydvqHRD1FIIaN2/76D86XLs5y6i5Su1SLnoV/557AH3iav7iqoLELRVCkismeXl+TlOTqiLntj0U5YsaruuyL5MdS8hCqvwBfo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <3421e525-fb04-4306-9320-4fa359c2ee28@citrix.com> Date: Thu, 22 Jan 2026 17:10:23 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Oleksii Kurochko , Community Manager , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk Subject: Re: [PATCH 0/4] x86: Drop cross-vendor support To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0136.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2c4::12) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PH0PR03MB6938:EE_ X-MS-Office365-Filtering-Correlation-Id: 7d9befca-3b60-4dc5-5143-08de59d92323 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?d1laTXZMN2UxM2pkeWF3R20vcWw1M1Y2L3lsS2F3Z3hObVlLZzljTG9VU3VM?= =?utf-8?B?dTFVZlVjNEtyLzhRVW5hOWNWaFVyWmRDQkZnMGt2TzR4eGplN0ExTC9LL1lC?= =?utf-8?B?STZNUjBaYzJiVGE1azdxQWdKL1o2VmdSOXdMclo5RS9PaEZpRHNxU21PYk9J?= =?utf-8?B?SXFZM20ydkcxMmVQdzk1NWt3Sm16LzVwTXA4RGFORHhPdlNuQ3ZRNW05NlRI?= =?utf-8?B?dzRlTzNnZC9URSthK1JsOXE0cGp6ZjJKWXF4Tjh0Y2hnTVdqOFgySmZyeGs1?= =?utf-8?B?QVY0VG1XNnZpM2NjMmZ4bzZoL0twMThtUU40V3k4cmVyNExYRy9HM21SUUUz?= =?utf-8?B?U3pMM3NsV3Q2UGVyaU5lZkVFcWs4V290RS81dHJ4OFl5Yk45UFFYWmtLc1dH?= =?utf-8?B?UzdKRzVVUUMwdUFuaDhLZURCWkNrSXVKTUVHZlBkNm5CMzhMNGo3anBpM2pk?= =?utf-8?B?aENpS0xpRDl6cUgrY3hvbUYrUTM2Y3BTSmgwOGN3NFlPR05LdHdmOTBxOC9o?= =?utf-8?B?cytGb3RVYkQ5UEJ2UlhWaXh2amdYc0pUb3hQOE9FUzIzMjZjbDlTcFJGazli?= =?utf-8?B?ZkxHY3JFUUxzd0gxbFgzZ2hVL1kzUjVMU2k0RW1kQWduSmNNS3J3c3hwblR4?= =?utf-8?B?T21nSEpPNlc0STBReE1yYzJCUk5mbFhmeUhVVk1rUWVKRDIrd0N4TE5vMkZB?= =?utf-8?B?WS81bGt2WWRwMWZoSUcrcE9ycDhHZjFCSmhyTzBaVU04M0RIc3NocHNTYUZH?= =?utf-8?B?YmhnZGxSTGNVY0tLYnN2Ykpla0RIV2ZqaXNiUFArVEt2citlcnFoTnFXcE1o?= =?utf-8?B?c0wrVnU4SWZBNHpnSExMYmsrRHRYV3VBaEtTaXNBYmRlSnBBbzZCZ1F2V2Y0?= =?utf-8?B?NlNkMXVJbnRDbGhRcStQa1pIN1RVbGdKRUdkUXZZQ1BUTkdvZlJCbG9KdE9S?= =?utf-8?B?bWsreFg0M1JHWEZIWjlVMVNSMkhzZm1GaGRnQmpqYy80UFozT2lWLy9QTnRS?= =?utf-8?B?dEJISVQyZGJwd20zWk5iU0w0Tzd4c2Z3SndYaWE4K1o1a2E1T1RRUW54ZStG?= =?utf-8?B?UWFCL2N3ZXQvZ1poai9TV0t3KytTZk5wNEZJdVRkNkZrWXJUTTM3VGVNNEpH?= =?utf-8?B?ZUtoUGcxdjZoYzl1NEtXM1dUNis3QjFYbVhUV2pFQkZNeEdYeno2M2tCRVUr?= =?utf-8?B?bUdHSk9pNERQd3E5N2trcHljUURqTFYvU3g1TnlZc2ZITCt3Y0FJME0rZndp?= =?utf-8?B?c01PeXdwSDRzYVhQaVRPeitNWjhLZ0w1U0R6UXdZVzlJSW1Od0g5WFdVdTU2?= =?utf-8?B?L3YyTmRHZ1pzdklaSERGTlUxQ1M0SDljWlNVa3IyMlcyU0N4MS95VDR4SWxF?= =?utf-8?B?NS91ZXdNc0pqaDVoMWxwNUl5MEJ5V0tFZlNKSlpMRWVPbVRBRXhrcVBVRzF0?= =?utf-8?B?VmNFUk1VYzJmZGRIeWt4ZGlmeXBVbFEydjVUY3ZSUzdlUzMwRmhWdUVHSDc5?= =?utf-8?B?eVkza3ExV2NablBLaEVIT3Z1b3JuQVBCL1U1TEdVL1RhUHViQzFJK3VJdWZX?= =?utf-8?B?S3lOQUhiNzgrcHM4S3FPc2Fid0dBd0hMWVB4Nm54ODVNRlVoR3dXYzEyVElw?= =?utf-8?B?M0gxTXVxY2J1WWFpVS9jQ2RNVDhiUTgyS2hTaS81UVg5eEFkRWdpb0FSVHBs?= =?utf-8?B?TmRORTRZeTBad0hCL2hlanI3V0dxVTdmbGh0WkZIcnhuUWplODZwMUVHRmk2?= =?utf-8?B?L1hNRlVkNGVFcjhoMk1ZVHY1SExLYlFjUk11V2ZzeHp4MGlreTlNTXpJUHFr?= =?utf-8?B?NzFjUkZDenhXWHpjQVFFUUxBclBkQnRiYjZjeFF2RnBncFFVeDNmWWJpZldT?= =?utf-8?B?bTZBVS93eVcxMllsdFhQZG9KRHNYbW0zTWdLSVdlM0RUZTlNcUpqNnMybWRY?= =?utf-8?B?TDFReVpETzlpRjlQck1keEx6NW1pZnZmVVd2MjdvTWROR05qZ3VCdDhiVUg4?= =?utf-8?B?cWlDdURZeVFYZ1Nnamp6WWQ4SE9BODNzdzdJVW1qTTF5bkVZV01VV1VuZFM5?= =?utf-8?B?MzhuV29MZnVtejYvUXJFYkl1RHJieTJwd2pFamloV1JaTzdieXEvdDNheUl4?= =?utf-8?Q?T4TY=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VFo2ZVpueklsN1h6Y2pwdTIvNlltZlNUZnlNTlpsWmtiTDRuNXFROU9KZDZz?= =?utf-8?B?Z2pxVmNDRGdSYXd5d3RNclJVSG1zL2tPWWJsVFF4Zzl3V2lDc2xRdkUyRDF5?= =?utf-8?B?NjJNYTlBc1hpU0tLaEpaLy9ZQUJ6VnkwVCs3YzAvRmsyQ2ZvTy9jR2kwenJw?= =?utf-8?B?Qjl2b3lxelZaOUhSRnBwbDE3Mk5oZzNiTWNvTDBsRTJYU080SkZWUk0zNVM0?= =?utf-8?B?Wi9mNW9ZN3h5cVdxT2ZuT3U3WWhyQ2luNDR1SWpsbm82S0JwUGcvekRMTTZE?= =?utf-8?B?dElkc1p3ZVF0OWV1dW5Za1FETk4xc2lha2tmTFdvYlNwNWZFOWtYQm9kRGxj?= =?utf-8?B?SVNhMTNhdDBKbVcxMWw2R2loUFUveGozMlZUVkF4bFJnRFhudkF4WGNNRmp4?= =?utf-8?B?a0RXMGFYLzdmcHJRM0F1K1dWRTNlQ1pJRW1tRzJxeTBsTzNyTzI5eXhyOC96?= =?utf-8?B?bU9uWFJDenZXU1dVTkRCL3p4NWdvWUlGOHV3cWFMakhaanNzT1lPRTVNR1ZR?= =?utf-8?B?NS9qTWRDQ0dYRXVWRlJ5ZjhYRHdkRHR3Y1pDRDhYai9uV0gwVHIzNkhmZjlh?= =?utf-8?B?NHRCUWtmSTJ5UEhKOWdzL0JaS2ZVNWx4YWIvRzA2c0YvQ29qZU9hV3dsRURQ?= =?utf-8?B?VTdVbVgyUzJmM0lxRjJXWWEwL0luTFRhY1o3YjFaZnFRc1JFM3hHL2xPbDB6?= =?utf-8?B?L2RldzAwUWNQcGloTjF0OE02eEdJeGsxRUdXbUVnU0R3WEdQMXF4RU9wVk1o?= =?utf-8?B?M1hHaUpKNm5jcXRLYmZBYU5Mc05WSk1sZHR4ZGZoaGppS0F5TSsrYnhLNDVu?= =?utf-8?B?UG03cE51R2dKOTJmWU9iYmRZOHNaZmxiN3R0M08xOTUvenF1U2xlS2g1RVZX?= =?utf-8?B?UWZxK2NtOGoxVjZSYVpEMERXck5FTVkrL3FPaHlOK282M3p4L1p0RkdMdkF6?= =?utf-8?B?NlgrQ21Ba0tvYTcyMnpZcXJSQ0F6ejQ4d0Yyd3lhZlRwejZyNDlrUGU1NHZP?= =?utf-8?B?NksvMFpOVHVLV2gyMzNqRDBmcHhFWFJzb1d5Vk5rTUFZK2RsZm1SZjNZVWhp?= =?utf-8?B?UGhiU2V4Y0xBQ3Uyb3VVMHlueTRkSUV4RnJ6RkdzcElVTUVqeWpIV3cvNE1w?= =?utf-8?B?WXI3UXBiaERtc1pFYmpuME92bEtiKysvOExyR3RZTUt0aFk3cDVUbDNqYTFa?= =?utf-8?B?aURaVmxsR2FtWVBxdkFaemJpWElQRUx1TldPY1ZKcGpvNFd6MW9mS1dZbFR2?= =?utf-8?B?dm1aQ0doNnZSMWFkcUN0V0hweU5ZZmp5V0RvRTJ3WFA1L20rRzlMZk8wY1gx?= =?utf-8?B?bldqYWc1czJ6Y3RBcGxnR2lrNzV3MnUvNy93eUNuUUFEZ3VCREdEWmlldFZ6?= =?utf-8?B?eGZHUUk1RzI4WHkvWVZob3p6c2dqbTdxbjRaT0tkWWw1Rk8vaTZDMmV6L252?= =?utf-8?B?SlRYa0NNV3N4YVR5ci9xT3BONTVUcXBuSnk4RDF2VDRGa05GQnFUbjVZd1Jp?= =?utf-8?B?aG5CRmZaRjRab3N6ZmFzbFFyTEh4NFJTSm9VOHlxTGsvSElrbGNGeUorczU2?= =?utf-8?B?bktKZzJWZlFhdmx1QzRXcnFNdjBLZ1Nsbmx0Zmxtd1dqRWwwRHFZQnJ4ODQ0?= =?utf-8?B?YXE1T09yN0xENWpkcHZuVUw1bHF6Yml5YllOQWdMVThRdzBVQ2o1c2RsN01s?= =?utf-8?B?Q2tnaTNUUWVaUXh0NUFldVJUZnVaOVRlYVlaNjZuYm4wSk9yTTNZc3VOaE1M?= =?utf-8?B?SWVjakovMDZKWFE4V1J0SDhhY3NkRW9tMHpHcUpJTytRWXAzZHlITUtBcDRN?= =?utf-8?B?aFk3T2V1T0I4QVdPVmgrWUM2R2tHTGd4VlQrcGpNUlZTL0c3Y3VHbkZpTzZS?= =?utf-8?B?YTRPSjR3bm1XTWlwdm5lV0l2OENRSU4rV201ZW5iMFFCK2VwTHI3c2IxQ3RR?= =?utf-8?B?bDR4Q25KVEJzczIrSHlLNUNSd2QrM2pLd3VIWFJlaGlYdGhrYnE3M21NMnor?= =?utf-8?B?WXBwOUZsUEw3VmFDQVFtZ3FkYkV5RGFvWmJFQUFUemcyelZxNVJ2WHJnYzE0?= =?utf-8?B?TlYzMVVnczFVRzUra2FlZFdpWWFKNWtwU1VQUlRFbm1CN0Vvd3l4UHk4aFFX?= =?utf-8?B?bmw3U0dJNVpucHN2emwwZTBncU81TXhRanFzdzhpbnY0VVkzY3NLRXJSSTNw?= =?utf-8?B?djUxNnRTbTNaQnVSVHlERnhZNkdjUHozRWlKM3ZrYzE4RkRNbUMxU3hMd3o4?= =?utf-8?B?YzkwL0FzSFVHbXdtZEVqNS84ZVhFblZLVldHaWpudzZ4bjY3QzZUTitRWFNr?= =?utf-8?B?VGl0bUExaUZic3J3VWo5bmUzTHpBUkQzS3cveUJvbGJvdENaYjNqUXgzVHBK?= =?utf-8?Q?sYGG4HmVoyazm52M=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7d9befca-3b60-4dc5-5143-08de59d92323 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 17:10:26.7690 (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: G/P4ou9nzBW6rQB6f7azKfwyRXlGwP51JaY+nhpAbJKf1U3Hj81weUs7X5DdAabE3w8rDx3Wp0zKHKteqCmNoLOuehCkpCYv4E3HnACDwSI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB6938 On 22/01/2026 4:49 pm, Alejandro Vallejo wrote: > Open question unrelated to the series: Does it make sense to conditionalise the > MSR handlers for non intercepted MSRs on HVM_FEP? I'm not quite sure what you're asking here. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Jan 22 17:13:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 17:13:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211626.1523126 (Exim 4.92) (envelope-from ) id 1viyFP-0008Tb-5t; Thu, 22 Jan 2026 17:13:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211626.1523126; Thu, 22 Jan 2026 17:13:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viyFP-0008TU-29; Thu, 22 Jan 2026 17:13:31 +0000 Received: by outflank-mailman (input) for mailman id 1211626; Thu, 22 Jan 2026 17:13:30 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viyFO-0008TO-0D for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 17:13:30 +0000 Received: from mail186-9.suw21.mandrillapp.com (mail186-9.suw21.mandrillapp.com [198.2.186.9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id aa33115a-f7b5-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 18:13:27 +0100 (CET) Received: from pmta10.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail186-9.suw21.mandrillapp.com (Mailchimp) with ESMTP id 4dxnhP5Y46zK5ybkq for ; Thu, 22 Jan 2026 17:13:25 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id b2c0c61efb054c5696f9501df7702039; Thu, 22 Jan 2026 17:13: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: aa33115a-f7b5-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1769102005; x=1769372005; bh=uz+MY3DtvcsrfvLcOLdKtowImdvCiK+vynqKmiZyT84=; 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=YsMBCDlXt8F02s/TRqHDCJz4DRcgixBaMA98TDNs4vRK87tGZYpjNJFSRYqz+wxtM /CZMXsxTydgZMAfkttpKFyh7AKr8Rton9BTp3+wTvGNF3A0t2cpCUQMyk9SXAWpo7Y B/EE3U3XU+jhMXq4tLE1oEAontjuKgGkwirTwZS79AXchaJMmpAqGuoGacBHChK17P jyeMfx6wW2g/ETb/1vwZZFJmiWwIzJ9f9sQUC52imA8pDIcBcQtq5MpKK0wDriRDl8 PYZVvTgoSygUrl1SHdjgfYi4Qj8cb1FXG+tSxLG/rtlJro9Sc2Wbg1WvHp5hELjUsx KJxSspKc2WTew== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1769102005; x=1769362505; i=teddy.astie@vates.tech; bh=uz+MY3DtvcsrfvLcOLdKtowImdvCiK+vynqKmiZyT84=; 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=vSknfBb12gVZjCnkogbFR0tmYnGq9LfBmp98z9lwupYTLU9W78Az+Hw46o8nFMqQm zdSG9YLS3VsPaxdgI+S28jB1wbgg7tL3Wv8lESYQHoTCYncpxtOjX4K2hWxGVxTDNG mVtVon53ZQZkkKGju4PNdRJPFg3eECvzMTcf1n3T7ywiMXQR6E8zcI1mMxzrX3VuJH OSASryr9igaDfpgG9gFU6l0DORUkljNNJrZNDJVPqCqh15+DQ4SxxgA0U6Ue0OZfuY 2xzdI++hjdYO5l60vr2mZcLRd4ufV1DHwdfgL6xiEZqbY+yOEq3KKAnBf3vQwRs4su 2oKKMRIWISUeQ== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=201/4]=20x86:=20Reject=20CPU=20policies=20with=20vendors=20other=20than=20the=20host's?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1769102004290 Message-Id: <5a96fb6d-ce8b-409e-9050-3499ac90eb65@vates.tech> To: "Alejandro Vallejo" , xen-devel@lists.xenproject.org Cc: "Oleksii Kurochko" , "Community Manager" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <20260122164943.20691-2-alejandro.garciavallejo@amd.com> In-Reply-To: <20260122164943.20691-2-alejandro.garciavallejo@amd.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.b2c0c61efb054c5696f9501df7702039?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260122:md Date: Thu, 22 Jan 2026 17:13:25 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 22/01/2026 =C3=A0 17:51, Alejandro Vallejo a =C3=A9crit=C2=A0: > While in principle it's possible to have a vendor virtualising another, > this is fairly tricky in practice and comes with the world's supply of > security issues. > > Reject any CPU policy with vendors not matching the host's. > > Signed-off-by: Alejandro Vallejo > --- > CHANGELOG.md | 4 ++++ > xen/lib/x86/policy.c | 3 ++- > 2 files changed, 6 insertions(+), 1 deletion(-) > > diff --git a/CHANGELOG.md b/CHANGELOG.md > index 18f3d10f20..eae2f961c7 100644 > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -22,6 +22,10 @@ The format is based on [Keep a Changelog](https://keep= achangelog.com/en/1.0.0/) > - Xenoprofile support. Oprofile themselves removed support for Xen = in 2014 > prior to the version 1.0 release, and there has been no developmen= t since > before then in Xen. > + - Cross-vendor support. Refuse to start domains whose CPU vendor dif= fers> + from the host so that security mitigations stay consistent. Cross-vendor > + setups have been unreliable and not practical since 2017 with the a= dvent of > + speculation security. > I don't really like the wording, it sounds like guest will suddenly stop to work for some reason. AFAIK, in the Xen Project only suspend/resume logic is going to be affected, and we probably want to reflect on that instead. > - Removed xenpm tool on non-x86 platforms as it doesn't actually provi= de > anything useful outside of x86. > diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c > index f033d22785..4c0c5386ea 100644 > --- a/xen/lib/x86/policy.c > +++ b/xen/lib/x86/policy.c > @@ -15,7 +15,8 @@ int x86_cpu_policies_are_compatible(const struct cpu_po= licy *host, > #define FAIL_MSR(m) \ > do { e.msr =3D (m); goto out; } while ( 0 ) > > - if ( guest->basic.max_leaf > host->basic.max_leaf ) > + if ( (guest->basic.max_leaf > host->basic.max_leaf) || > + (guest->x86_vendor !=3D host->x86_vendor) ) > FAIL_CPUID(0, NA); > > if ( guest->feat.max_subleaf > host->feat.max_subleaf ) -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Thu Jan 22 17:19:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 17:19:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211637.1523136 (Exim 4.92) (envelope-from ) id 1viyKg-0000uH-O9; Thu, 22 Jan 2026 17:18:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211637.1523136; Thu, 22 Jan 2026 17:18: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 1viyKg-0000uA-Kz; Thu, 22 Jan 2026 17:18:58 +0000 Received: by outflank-mailman (input) for mailman id 1211637; Thu, 22 Jan 2026 17:18: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 1viyKe-0000u4-Vz for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 17:18:56 +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 6cfd13ef-f7b6-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 18:18:54 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by MW5PR03MB6905.namprd03.prod.outlook.com (2603:10b6:303:1aa::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Thu, 22 Jan 2026 17:18:50 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 17:18: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: 6cfd13ef-f7b6-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=on1x4OYXdZeOfQrii8spj2vTE58rY39g1iIUC3f543Rt97xocYCyhfUtzRA94alUmBqtoJK770KDOzWpBPtqsHzk+fZiCAbwSoT+tQmcJjm1iMojK4wM0PqpfHgAT9sW4PwZ+jYXCxxiujWijq2Hsx/1OTvAzoCZupEucF1kvngRUu7oYagus5FC3FUkOz97BPG9j96yJfuBdprERzuN04yVv+naFGTxVsP5xuU0aQ0woDM6biJ1s7cNAovNlmnWqPgOI3/ivnOD3TO3718KoRhJADA4eP4EaG/e8jALQ8U50XKC0B4MiSJYorC4PzvBHLoB2wTOzBInhltyK0ADtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7E7COv+Wh1EVe34eonap1ehBQJL4ChnMDwNg1wlY5Do=; b=Gtj4VAW3jlSlrWO2Rb/M5Ms1XzSbHdjU34qqJswv9A/L2lCnqOM3ZmdRU3f+JCSS+f0eMKY/D5ORJf6XUNy71ZdJfX/9M15O31I3NCD1xXa3hsj1xd4Mu9znsQt/UuQBFz+LgBEsMO2WgMu6ExX9CdCgbNj8Mzq8smVR9pcO/Vjp+1g9sJWvHU6ZW1I5cOiSipU/OWYSJmJYpP2vjJBuvdY4JWjp/Zs3dAe1jyjE6dzci9+TYiDcyEhXNUylk84D1uAV+yyVClLINwM0u1pDBHPycDK3xpiBu0KjW753Z7/Xert/jxJ1TW7v2WiLgQpXQHvhovB0oQvGxJvWuf3Rzw== 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=7E7COv+Wh1EVe34eonap1ehBQJL4ChnMDwNg1wlY5Do=; b=kKBxqjQXjcfBo6SSczPRdYhnYet9Xk6jjs/HszjgPwWRO0oIjYraDJE7s//HUNC4DFUZtza4LBmNmbh07q8OU3RsUq3AFdIwdWotI1M6GaPiR0loe6g/37e+Op1l6nf6agyRRgq0NdLD3H1tS5kd7M8G44g73owiladRCe6jtvw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 22 Jan 2026 18:18:45 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= Cc: "xen-devel@lists.xenproject.org" , Jan Beulich , Andrew Cooper Subject: Re: MTRR init sequence in Xen Message-ID: References: <145af46c-eab5-4d0f-ba35-4ae646c0e4cd@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <145af46c-eab5-4d0f-ba35-4ae646c0e4cd@suse.com> X-ClientProxiedBy: PR3P189CA0070.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:b4::15) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|MW5PR03MB6905:EE_ X-MS-Office365-Filtering-Correlation-Id: 36be5ecd-92f2-460a-c426-08de59da4f6d 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?cHJrNXoxTFFFOUt0dDlnUkpta2lsaWQ5cmVIRDFNaXlDc3JsaGdBNk1FOFNa?= =?utf-8?B?REswcDQ5cmVyb1VHcUdGemNxdkhPRGUyRHhQYlE2T0pKa21GbElhMHNLdmpG?= =?utf-8?B?QUlmaHVEUEw0YkwyRWhSZVhOcGpqSDN5dDNHVEpVcWFwaDUvOHBzdGtJRWd0?= =?utf-8?B?dVdhVzE3UkcwU1RYMEQvOHViK1VqYllaeitzdzhRWGVieWxYV2x3d0Y1UU1M?= =?utf-8?B?UEhpYkE4cCtDclJKWjNNZVNHcW9LSjA1ZVRSK0p0UWFDTmMwRGEzY0pvQ0VM?= =?utf-8?B?STVwbUN6Ynh3ckhvdkQ4S2pZZU1yK1RiQ0U0c3p5anVyWk5CTTQ0WHB4eEhs?= =?utf-8?B?R0FVZ0dQS1N5OERaVlBNOWhUSndoTTNaU3FSRG1rVWt1bVE0eWRWb0RBYVhs?= =?utf-8?B?bkdKdDVZbUo5ZjhvRnBNblc5dDRaRXU0eVBPSG51LzA4dmJXZlVkZnVxVFhT?= =?utf-8?B?cHppQmo4cFNKTStyMnJPcFdReFVSMjdicGEzU003Zld4S2lMUWprSDNzMlNW?= =?utf-8?B?dllaSWxCekhqNGpOSlRsblE5a1RxczNjb2hhUlI0c3hJVytpS3FYdUdKVThy?= =?utf-8?B?N3FsaURPeno2UGlHT3JXN2NvMWE3U1RBOTViTzBQZWtLdzRtSTdXYzg4R0pl?= =?utf-8?B?QnRpcUFVbUI1dTlXS3R5RWhGb1I0QTdDdEd1REJBdUx6cjJBYk5UN0xmbE1H?= =?utf-8?B?ams5UWl6c25LY0dpYmVqZlVQa0ZEVFJXekZDa3VheGxzTHdENWd6cGZuQWMx?= =?utf-8?B?YU1mR3E3aHN3MWtWVldXUXlyWWpab01YeC9yblhObFo1bG9tWEUxY0lzRXE2?= =?utf-8?B?dVZ5TEY3clNwT3I1Uy9EZkVMM3U1WTViR0NsRFZGMTFSemhid3dWZXptT2lj?= =?utf-8?B?OGwwdFRTTFhlUzlDcWZUc0wyeThtSmNTQ1hFczJxd3hPTk0xYUc1ay9NZGtR?= =?utf-8?B?djE0TUdFOWUzNy9jREhIZG95MlZHUzVPdUl0Q0FUS1dNam96aGlIK0F2YmVm?= =?utf-8?B?YlcyTkR0UFB0MWNIMVQyeUNQOE95QnpCY2pJMHY5OTdWcmRrYjZ3U3dYNWtJ?= =?utf-8?B?SnFoWCs2Wlc1cEhEdzVEUnRqajFBdlFiY1lDVm9Wdk1oRjRhbzFGdy9QMUFU?= =?utf-8?B?MEdFQ3piSWdMK2E2RHJ5RUxWSklOVldyQ05uU0lDUnYvcWNsaWpFY2hxcXBs?= =?utf-8?B?UHI5ZmNpcDJSbnpWZDd0WkkraU9MOGlsdnROb2lTU09GSW4zOHRuVzdJWHdw?= =?utf-8?B?YSt6T1lUdFZNMlVHYVNSWXpOcHJsZUhEcTgzYm5nZWdzLzFvQW5RbUdZMzBB?= =?utf-8?B?T2RiaXZVdGFJSjVqRnpLU0xKbFcxWGg1N0tQRWgxODN2K1AzMTQ5dnVBOFNF?= =?utf-8?B?TCswRlV2NWNOTVI3SWZHZTZ0SkYva3lkbGo3T1BFT3g0c0R2Uk1wQWIyV2lG?= =?utf-8?B?WGlqclMwNkcxeDlPNTczNkRrMGtjL3d3YWNadUl3TUhCTlVNcXZqNnRLL29P?= =?utf-8?B?cE1jL3Uxd1B4Y3htUExheXpVTzliT3FXRjNYMlFURmtLbWhUWTFrS0JNRy9x?= =?utf-8?B?ZDQvMjZVM3ZpTk4xQzJVNFRLUDFBQjdReFRUSkFac05RemFhSzZHL3JZVjBk?= =?utf-8?B?NGNxa01ZT3BGYkE1OHZPWUIxUFlZSTgwVEdUWGRnSnZvRnNiSjArbVJUczNr?= =?utf-8?B?SkY0VmFvcXcvSURWZkNpMEtmWjB5cEE1Nkp5MzcvdnQxZGFEeFhGRlkwbHJr?= =?utf-8?B?dVpCRXFLOW5uRERHL0FZTHh5Tko0VXZDOHBpNDc5QWxHODYxQTFML2NNb3Rp?= =?utf-8?B?Ym1LZmV5ZWNhTHlFdWdBUWJpdnlVRkdNdzg5TnloV0pPdjYyQmFZM0ltL1A4?= =?utf-8?B?dUx5d052U2JuY0Q2WkhERGE5b1NkazRoYmpWZGt5OEZMWUZZYUMrNXk1cDhM?= =?utf-8?B?NGszUUpFYVdCT1lYaHhtdVA4VnZwL1A1bzVNOXBmV0MzblhsbThqODEyN21W?= =?utf-8?B?cFBadUtWaStJWU9abm9TS1JBZXhveFRSeEkwcEFaWkxvMUhuZjM5ekFheWVV?= =?utf-8?B?bVlaM2NrL0tHYmg2YVRXSHVDczhPRUZ0WEVmVlV3alFnSENoMVA3d2pOTVJH?= =?utf-8?Q?IxZo+nvhp7UOh4Ke4CQcbIGdL?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eEpvS0lrZ3Baejh4WGFyMTAzaXNPRWxCWDFMUGt5VWM3VVdaenNKVWlLWHFs?= =?utf-8?B?emYxZTM2djhKWGJLTUNJZkFqWk14aWlaNWJSU3JwUjIwa2QrdnpvRmpkNkI0?= =?utf-8?B?OXpkVndDc25GN1MvSlhzOTZ5Sm0yeFE2MmlsOGdtREh5dWJhYklCOUxQcDdI?= =?utf-8?B?dEtVdUdkL0tNRjMremZrdWpXcm81K045ZlA0cHJZdjZ2NUEweDN2YUx1emEw?= =?utf-8?B?WW9teGlubG9VUlVuTXlHQU5JeWtBZk5rcXJ1b0owNElNUHdVQWgySWtaMUVS?= =?utf-8?B?aVI0Yy9tOXN6V08yNzVVOUlpOVNhbldTQm9Ca2E3bDZrZFI1NVFnaTRlbGdU?= =?utf-8?B?U2R0KzlZRmJ1ekh6dVA2NURpbDNsdmNhYXpIS1VxWG9IQzJHMFV3aXl4UGdj?= =?utf-8?B?Wk9UTDNGY0F5bTBoZm5Uazl2N09qVGhDL0dXZXE5SVp5Nml0eUN1MVpiTVgw?= =?utf-8?B?NGRXMmRvRUFYR3lvb0V2dld2WURrZm1wK01VSTlxL0JUeUxoVy9Bd1lCdVRr?= =?utf-8?B?Ty9GYUQ2VDIvaGtJT0Z3UnlmS2tUYWorVjB6a3dicTVSZngyTEkrdU1yY2FK?= =?utf-8?B?SWIxSGxJU1liOXdVazRZNytqVjhsS3pLcTJjWHNwQnhLT1k5QWc4WmpDNzRZ?= =?utf-8?B?RTdvdFNJNHU0c2JReU53d204OGt2eHhxVCtYUFczZURtNGJGR2hKK0JKTXIv?= =?utf-8?B?OTdzVzF1WEVwUWNZQUM1R2NKbnpKZDQ3cy91NTE3UWE3Q1d6SEdaVHBydVVx?= =?utf-8?B?MjI0QUJrZE1qc3pKRjVnMUV2b05mNGwvVjhjbHVLWlBSdUYxeVNwR3dIM3ZI?= =?utf-8?B?bWVSRURkZ210cThnZ1lOVk80SzYwYkxVSGExTGcxUXZtcUxEM1BVQUVQM2Rt?= =?utf-8?B?Tkt3M2hXbWVPUjdwV2ljZ0V0bVkyMGRsQTFWZXdJY0NrV2JkQnRMWktLS3p5?= =?utf-8?B?Umx4MUV1VlBpOFpWb1FYanlsdWthQTh5SDdzd01hczBFVlRORkZlckJ0Qzgz?= =?utf-8?B?VFNLd1pBTlMwUXZTVzhyRzBsZXN4azZ3NE84b1ZqbGdiOVBaV3hqZW5EYWVq?= =?utf-8?B?aCswUzZUc0tWeFA3Uzd6U0s4RzkyK3RJL25Mdyt2bkRnSnNNOG9HVkpjNWk2?= =?utf-8?B?OEJ6ZVpmOUdEeldWUFYyeTE0ZmxJWGh6d2tvSVhURWxQcVpXeDAwVUp5N2RT?= =?utf-8?B?cE91dmttNnRaMm9yMzFVd2F1REVpaWV3czVjRStFOUtpNWdsVTBNdG1IN2ov?= =?utf-8?B?clhGMkJaNGE1MVlpemF5eWplWkpzYXBUUVJzN2dNY1Zja2RwRFVIc01jQk05?= =?utf-8?B?NlRFYm9pVitUamR0UytxUnQrdkUyY2d5cVgyRjlRUERtOWRnYnhwa2NFNEls?= =?utf-8?B?ZTYzNnNxcTgrSDFQVHVXMmNHTFdmM0RmcmduZnZtMHZwMk8rSldkVjBqOEND?= =?utf-8?B?M3pEMjNuMDdZRkhraFh5WkRDTWl5SXFnU3JpSk0yekJzKzRJYm1OZ29WMytE?= =?utf-8?B?NGszbURRVVlBaEpQNG02ZlUrRndocmxvVkxGUkFJZVZkYmZLN0FHRlpsL1Vw?= =?utf-8?B?VnF4aUdSWkEzYUszSE43S29uekRYUmVpc2wxZWhRVE1oMTNxNjA3SzhEQlha?= =?utf-8?B?UzY4U2Q2YjBWWjhrL3NDN0RPZDY0ay9mSklJRjZJRzhsMjRiOEZzeHZVQlVm?= =?utf-8?B?WUFjdTREdlRWc0xsZXhHQnozNEJNeVFIdytlbmYrVnMrYlh3MVhqZHdIbGR0?= =?utf-8?B?NklBbnR1VGpya0dFdlR1T2xyeW5qejBSa3Bhc01RdmQvVm81SU1iZkMxRXE2?= =?utf-8?B?eWF0RTNEWFhBaU1iSmJqQXY0RzQybVU3LzBJY1FEeDlvZS9YSXZnTTFLSkNq?= =?utf-8?B?cWU2R2VYRDY5cXREQXh1YzlGREJBWXlyOGMyZEx0RjIzT1hDL2VwY1oxaEh3?= =?utf-8?B?T1Q5Q3lnZW9nZjIzSTVTazRmVXNreWZtMkpWTTRWVUsvcHhzdmcyaVphajF5?= =?utf-8?B?bGdKMGtlSllIQTVyd1hIS0lQbGdWWnFuMXNldlRHUkRSMXhTTHdQWFh5OXRW?= =?utf-8?B?THM1M1hRT2J3UkkxZGpQWFJrdGs4a1JTbUlUSCtHWVZKY3FVaDd6YnBweFRG?= =?utf-8?B?UnJDZG1UREtmZHQ2UFR2SDBBblplV0NDVnFCOWI1MTNCQkpNaURMc0xmVUZw?= =?utf-8?B?UWdybG5FSzV6MWhLcTZBZ2hidVA5N0ppQ05tS2h2V3phWVkzb0tyeTlVVHVP?= =?utf-8?B?SW9BN3lmOG9nMUp4NHp1YW42OVpoNGtaamQ2ZkVla0NzeFh0ajlOb2xGTVlJ?= =?utf-8?B?TS9oRXhnQmI5OEhzRWNPakxZdnZRa0Z5cVVaeTg5akdFT0c0K3J2UT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 36be5ecd-92f2-460a-c426-08de59da4f6d X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 17:18:50.4595 (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: kvdUv/yzGhqjBhdTXOnXfN2INOSWC75xl8EneMbUtRzLy148s3WITQRxJ3Rs/JBpij8RrSlYfpv9qeKJ3P6KWw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR03MB6905 On Thu, Jan 22, 2026 at 04:56:24PM +0100, Jürgen Groß wrote: > Just as a heads up: a hardware partner of SUSE has seen hard lockups > of the Linux kernel during boot on a new machine. This machine has > 8 NUMA nodes and 960 CPUs. The hang occurs in roughly 1.5% of the boot > attempts in MTRR initialization of the APs. Do you know why you get hard lockups? Is some watchdog triggering on Linux? Otherwise I think it should just be slow, but ultimately succeed? > I have sent a small patch series to LKML which seems to fix the problem: > https://lore.kernel.org/lkml/20260121141106.755458-1-jgross@suse.com/ > > As Xen MTRR handling is taken from the Linux kernel, I guess the same > problem could happen in Xen, too. > > As the hang always occurred while waiting for the lock, which is > serializing the single CPUs doing MTRR initialization, my solution was > to eliminate the lock, allowing all APs to init MTRRs in parallel. > > Maybe we want to do the same in Xen. Hm, yes, I think Xen would be equally affected with regards to being contented on a lock while updating MTRRs. The MTRR initialization is deferred until all APs are up, and serialized on the set_atomicity_lock lock. Regards, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 22 17:21:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 17:21:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211649.1523146 (Exim 4.92) (envelope-from ) id 1viyMz-0002uw-Ao; Thu, 22 Jan 2026 17:21:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211649.1523146; Thu, 22 Jan 2026 17: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 1viyMz-0002up-6j; Thu, 22 Jan 2026 17:21:21 +0000 Received: by outflank-mailman (input) for mailman id 1211649; Thu, 22 Jan 2026 17:21: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 1viyMx-0002uj-Qv for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 17:21:19 +0000 Received: from SA9PR02CU001.outbound.protection.outlook.com (mail-southcentralusazlp170130001.outbound.protection.outlook.com [2a01:111:f403:c10c::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c3153709-f7b6-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 18:21:18 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MN6PR03MB7645.namprd03.prod.outlook.com (2603:10b6:208:4f3::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Thu, 22 Jan 2026 17:21:15 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Thu, 22 Jan 2026 17:21: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: c3153709-f7b6-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SAdlxUH5Mn2lknbYjSyuNB8Mfa2j3eTtYvoO5HiZIqTlFeL3wNeuEn8IAOZzE0dHt54JZLaUHHpao8tyh8yew1q94t54X57zOYmzK3ks4HhZn78O2eUegNfm8eq72qyIKNcyMMKR7gmA+CyWb46yxtBhMKVpzLWIRoxAkDspHQJwRsiiTGbWvrGhU/vDJxS6CQ7o+8NbuACi/+bX28I43YgKAxJ8LthFz09pzhBPlqoIN50aUOWsKeXlGglbZ9QYem/7FL+9288SUVTXLUm3opvmiOKpYW/jpQC+28qkF8qpqVuBnKc264MahS6FPBDyHlhUI1c0X2tf9dCMCU0vhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+rR1jB7FooJ7PNtsTybWfKk6BCZ5AbQ/5F44YqzQJME=; b=pcoQVAQ2Nuh+t1nPSqjGA3f0Wb2DxWaZdoaChfaIQpCy8/+NytrqxVTrQulzaZzG3y7XW8FQxWjIPuc8E4ZbF65Ptu5a6Fn7hCZVWJgKePu5jytK67yWW5/rKBfMas11dCD0j6qbQ76x0v7/RF9j+CN9D3sZLBg3SlhG9L+SpSJ2nAz8qXPhlw6/XXvhN109kaGZOJ9Z8eu1CaUeYjADHMAhfMuflUNp7LE7JgaIdBgbuCXfeTTHsjFnHWi347Zwdby/0hM/7ewggKkK4hB0v4oRy2wW8jSIaAslKHVGwcev4H86Ilc0lhHohlvZGMQSQXoMa8kkcDcjCxD/St13Nw== 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=+rR1jB7FooJ7PNtsTybWfKk6BCZ5AbQ/5F44YqzQJME=; b=zdhPH64TqMjnYH6EVXUmZW1u+Cqt6FJSPyZ7SQOcBgTNXXy8qWQ9J3RsenT4700AjwiG5FYR0n5c+RRauC7kIk+nqvG84YKSGtQUUicIhF1y0/GWE99DfOehNmhvBcuCc1a0/gg+KrZQ96E6FxImOkc5XliuRLYgfx/V7Ow1CZw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Thu, 22 Jan 2026 17:21:12 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper Subject: Re: MTRR init sequence in Xen To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , "xen-devel@lists.xenproject.org" , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <145af46c-eab5-4d0f-ba35-4ae646c0e4cd@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <145af46c-eab5-4d0f-ba35-4ae646c0e4cd@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0052.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2ac::15) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MN6PR03MB7645:EE_ X-MS-Office365-Filtering-Correlation-Id: ebede1df-5ba0-40e5-afb3-08de59daa615 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?RGVpNm9CREVZV21zeGFndWJ0QlNaNjl0S0dtRW02UVQ5S1h2bis2OWplWThW?= =?utf-8?B?RHZvQWdybEkwUG1WMlRzRzN1NUtORXNSSHhwNWhtbFp5clI1RmJPM1M0eVlo?= =?utf-8?B?MS9xRFpkamZSSUlFL1ZHalM4Y3JldjBtM0llRXEzLzNNcWRjRlpBaStyNCtJ?= =?utf-8?B?VFZVSjBzcUhUcXgxeUM1eStDbkp5ZzdVLytrM0hGRnEwdnR0eTZROVl0SjdG?= =?utf-8?B?bkR0TEt4WlNaMXFyaXQ0ZXpYU0U4dkFrRGh4aWVtdDl0ZVNFdmgwVjhNU1BN?= =?utf-8?B?RDZldFpHYy9YTkROMmloTE1sbVd3TGN5NjI2cEw5K0Vzb3U4eTZ2dE5nL3pE?= =?utf-8?B?SURkdlMxdVZmWmtIdDVDcnpVRGtZVC9IcXdQUTROcVNWZzduQmJ6dnkwVlB4?= =?utf-8?B?anJCenc4YzBmS1JXa21zai9LZ0M3ekpsQUlKVXpqR1lUem0vTW5hdDQ3dksv?= =?utf-8?B?UWV5YkhRUlBGM3gzK1gzdk1tUE5VeTRvSnNtWWJ1ajN0aEsyQ2xKSzVTRW1G?= =?utf-8?B?dklQT24yaU9iVGRpSGd3RFdwRkFZZk4vTC9iK0xtbnp4NVVyS25ZOWViekJk?= =?utf-8?B?RkNPMzJLZEIwM3pUeHJuYWhoNGJrRDJTSDNEUTFCcERDSS9KTlN5MVdwV2Jm?= =?utf-8?B?S21HdW5aTWJ5QXFITkNQcGlUSGFHRi9UQnB1VzBkZmNwSTZPcUtKQkg3ZDRi?= =?utf-8?B?eFk1OE5laDVKM3ZtSGFWWEhmb0pySms3ODhwLzdldTd5VDNsS25RNTNIV0hU?= =?utf-8?B?NC9MNW9FVTRoMWVhb0F3dDlXMXhBUjhXWmlTTDdBa0RudStNWlBRaWNweUwr?= =?utf-8?B?V2IxNFNJK0t2bnI3YktNVm1WSWs5VzZNK0ZFWjMrVDVteUx1RytybTdyNkVu?= =?utf-8?B?QmFuZjNsdzlkMHA1cG1ISUJiUytjYWhEU3IvTUFjdkczYis3dklzWGpDcEND?= =?utf-8?B?ajZyOFFSZnduVnhxVHdIeFRLdTZoZmdxSjRaMmJtenhiUW4wNVZYTXhTKzNw?= =?utf-8?B?NnVGNjVudDhlMXFNbTAzbnhmK1hobkZkZ0NyRVYwOEZSMHZFVVJLbk5GMXZx?= =?utf-8?B?MmRMd05hT25GaUVoY1BOSE9PSmc1Z2lyTnZxdDhray9hdHFSdFk5VlRDUlhr?= =?utf-8?B?R3E5OG10N1d0TzIzR29RQ3padWRRN3pKekh2NURadlVpcWIvS3lRM3U2bUQx?= =?utf-8?B?Um4yOThiaVFJeGhvVkxWUnlTWDdtNjdYV01VSHlSeUd0VGJsNTliUFNCVkRk?= =?utf-8?B?cVoyMTRvY3g2R2pkWEpkREloWWxPTUdkTmdUZmJ0NXAwckh6QnVTeTZHMUw0?= =?utf-8?B?NEhDSXlreW1nV1JncUVCSHZucWtJK0ZTNTFJNVViYkV2SEQ0RG0waTNBeEFF?= =?utf-8?B?ZFp5dExzSjRKaENpdUhVWHUxL2lXajUyYWVpL09wTHFNenQvSlNpNVRLL042?= =?utf-8?B?Yy9wUWwydGEvNm8yUjNkYklRU0tUMFBsMTk5dktPL2VhaXV4L2VManNab2Er?= =?utf-8?B?QXhPbTFjYXNyZkZHWS9iV0RxU1ZHZC9VSG5lSTBxTWJjUDRlQnlpOGIrNUds?= =?utf-8?B?UkU4YWd3N1Y3R2VCcFlLYUxwcDZrRTFBcGJ0K3FTUS82T3VVRUtSRFRTbFpS?= =?utf-8?B?bGNKVWpLZzFac25rU1V2ZVpUdW52cXdDekFEZDRqSmMzNVRkRWdrRWhxeW5u?= =?utf-8?B?NCtjRXhNaTRDWjhnUm5uU1dNajlsUUVNVm9xZlhDL1FSQStjaHhmemFwVW1w?= =?utf-8?B?NUpKT053KytwUU1zVjFTMkpmaUoyUERjZXJWWG1pOVBqdEFrQzg4SGFYOE9o?= =?utf-8?B?N0RPSnZOZTIxbzRZa1dpMmJMT3lVWTRET05oN3dYZkt2M0x1K2dCSkRHY2FH?= =?utf-8?B?Vko3a0l4R1A5YzNlU2xVZFdLMXB1Ylk5UFlkZ283eENSL29YQXZxMDRNelIw?= =?utf-8?B?MlkraGJHQVQxRzUvNnJzaC9wdnlSclNnemhsclh2TVNXY2NqZHAva1ZhbXpn?= =?utf-8?B?ZG8wcWxaQ1FrRGFrclZZb3RZYmhXYjVnTUtzN1laeFpGVGR6UWErZ3JRUnhR?= =?utf-8?B?Y3VsWEM2eEFOYml4RXhvNDZGcUtJL1BhSlZ0MnhTTDZXbHRoTzJUY1VwUnJZ?= =?utf-8?Q?/sY8=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dnpIRGt0TnQ4ZEZWVUk0NWpFT3o1NGsvbWhGQ2lPV2E4YllPYUl4bVZSNURG?= =?utf-8?B?UlBDd3A3aVVpQ3dRcE01eS95WTcvbTc3SUFjOVc0cDE3OEx0S0I5NFB5T2xQ?= =?utf-8?B?TytvcHdzcHZoZGs1WnhSMmNKR01mWUc3bVlxRXV5YjV0Uy94QUtDN3RDUTU4?= =?utf-8?B?UkNQbCtuNmYreEtnVmw5VzEyWCtURXRGU0ZDQm02M0dleUZmUk56dktxV2VP?= =?utf-8?B?REpnRThOQldFd3dZdmVFcnk2RUFHUkhDTUxpL1kxQ1ZTR3JpemF5M0FhcHZH?= =?utf-8?B?WXBJTmtFQzdwcDNVSUhjVnFRQ0hpTVpQdllKSWFrOE05MUQ5ejR6TEIxeUdL?= =?utf-8?B?eDZIa3NxQTNKRUh2YUZZb3N6Zy9JZWZRaGZxVHpFdTQ0U2ZUTFQxRllkSUQx?= =?utf-8?B?aWd5dGJYMkV6bkRKdkJjZjduSDFkZFgyT0NWTE9OclZnY3pKd3NzNDFLdVFo?= =?utf-8?B?dmVLcXZGNXNRK3NFVlhSd0tSTXllVFF4aVR0bnl3T1RpdWRYVFNoc1lmT0RX?= =?utf-8?B?YWpNRXNodkU3L2ExOXpnZTE3R0EzbWNMTlNMd3lBUER3b2VYU2xYVGlTRXIv?= =?utf-8?B?ZEw2VHFBT2tnT21vaVdIMUtoTFA1NGdiRzI5b1h3MmFIazZ4U21oWDBOVW1R?= =?utf-8?B?R3h0L0JkS3BPNkRMNHhGR3RJOXJWd0pIMVJ6cnFwTk5KL0lybU10WVZFc01F?= =?utf-8?B?d25raVJ2V25rRVR6dU45ZDBZK25XUnZScGZwTU5xcnZJRTFUVDV2V2hiUGpI?= =?utf-8?B?UjhNQThBRTRqOTlyV2FUNGx0ZmlybHNqbTU3d3JDbHVuK2VLK1NJczVmOENB?= =?utf-8?B?QWoyM1B5cXFuclB4OTg5V1hPQUsxbzRUMGdWaEZJbVNrdkd2cVFadWF3U0dP?= =?utf-8?B?dllRSEoxUk8zTnZMbXcrVXJ5MDZxVm5OODMzVXhOMUgxMnBJOEx0L0IrSEVM?= =?utf-8?B?cnl3TEx0c2M2ZUFRUWhNOXhEbXFKWVVqd1BkczVtd0k1ZWN1VVhGM01Jd2J5?= =?utf-8?B?Q1RUZEh0TE5mZVNIRkdhQjVwL1FPd2xRM0NoNm5kOHhCMHVyZzdaYzZIWGtK?= =?utf-8?B?UE84cjJ3QzV5bWN0V01mTFJ0YVlVV0YvdEZlZWVRN1JQZU5QVEJHK2xjWDdo?= =?utf-8?B?eE9HZVpRdHlGazNJVGRNZmFNMlFlMDVqQ2svTE5EM3puekg1THkvNmNsNGdU?= =?utf-8?B?Y3J3Y055QlhaclMrQVE5K3VGY1RGWWlKM3BxVnBwZktROCt6VkNaRWg0T0Nx?= =?utf-8?B?SHJ2Q0E0MGRjN21GdXYvQi8yU2Z6ZlNqL2V6Wlo0OTZJQ1hockhIMTJLOWNi?= =?utf-8?B?bDdMWkY4cTZyZlo3am9ySUhIT0lQbWtMRHVFMmIxZlRrVVFjUWp3cG5qanl0?= =?utf-8?B?VHlHZ3E5SWZGYndjZUpBcHk0NVg3SmowNXNBUmMzVmVmc2wzb1NyczlyTXBt?= =?utf-8?B?VjBEWTJ6UDdtU2ZDaHdTYmpZUlpEZHMvbElBbTNLMDZwdmxXTHhoejlEaGNj?= =?utf-8?B?SnZmckZIdWxMeDJjYlZpOE9BWVkvZGtlT2t1NVpFNE1IMHJPSVErTFFwSnBo?= =?utf-8?B?aE9ZUG5ZQ21GNnJmUUd4ZjY1dEcweURhbWtyL0ZSYU1ROTdnbXRuUnJ5UGZI?= =?utf-8?B?RU03Q2pYeGJMb0ZheE54dWthdnVaNW9EeHJXM1BNLzN5NlNjSHIwOGhtQ2cx?= =?utf-8?B?bXR1SnVjOC9ncVMvUXpySi9jeGN6OHBJZDQ2RjNEN0FoVTE5K3VtYmlvTGVp?= =?utf-8?B?b2o0ZmJHS2Jvbmx5eXVibGR3TklscGZGRWpNK0FGNVlMMTR6aVBIVXo4NXFy?= =?utf-8?B?c0k2QW1ORjhYZVZKQXJQTzl4cUtCRTlTWWhUd1g5cmxCcDJnQ2h1NjZDNnZy?= =?utf-8?B?SDUwN1JWcXlEOEs3OERPSWV1b2oyVlczWWNYZjdxUXpSRlBhLzVUaE8wYWJJ?= =?utf-8?B?U2xGallnR002SXducjFZRmJVQ0pYbmpWM1QwWkJVSnM3b0s3cDNNWUJIV0pS?= =?utf-8?B?T2pJdUtvdVFyenlFbnBjZUtLN3pCYisyb3lnMXJYR0E4Vm0vYXdvM204R3JP?= =?utf-8?B?TzJxQTlIdnpZMUQrd3cxODlGSDZKMXVObCtjS0RHdXpXQWx4NGorK2k4TkdF?= =?utf-8?B?OFIrSHZTVGJKM0JKZnpIUllRd3JTQ1ZJaTAzaVRPdjRmVGpjKzNLemdvZnhV?= =?utf-8?B?dHRYa05sa3l6Vkd3WmxXK1doN2t1WWtNS2VOU2dBNDNHM3d1UG1UbEFYdTVz?= =?utf-8?B?YVp1ZHpGT0hQamZOTEdEUUhVQXFqZjhzRU1xT002Qi9hSUZqeHQ5aXovNndZ?= =?utf-8?B?aXhTNXp1bXVlVXJVdk5ZLzNFYm0xUEV6QlZRMlEyM1JKSENkUDFHTUpaR0pP?= =?utf-8?Q?NyO3LfksC4ODbOrg=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ebede1df-5ba0-40e5-afb3-08de59daa615 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 17:21:15.8884 (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: KKOCKDBGpZIOB+BNdsq22Yi9u61ZTXBrHdh/O/CXHtB8Uu7E8aFurOw+mfT1WFfiSj+2vRFeVca5Vy3v/GJeDQXY9hIwfs1yXTZTbW+UtMQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR03MB7645 On 22/01/2026 3:56 pm, Jürgen Groß wrote: > Just as a heads up: a hardware partner of SUSE has seen hard lockups > of the Linux kernel during boot on a new machine. This machine has > 8 NUMA nodes and 960 CPUs. The hang occurs in roughly 1.5% of the boot > attempts in MTRR initialization of the APs. > > I have sent a small patch series to LKML which seems to fix the problem: > https://lore.kernel.org/lkml/20260121141106.755458-1-jgross@suse.com/ > > As Xen MTRR handling is taken from the Linux kernel, I guess the same > problem could happen in Xen, too. > > As the hang always occurred while waiting for the lock, which is > serializing the single CPUs doing MTRR initialization, my solution was > to eliminate the lock, allowing all APs to init MTRRs in parallel. > > Maybe we want to do the same in Xen. I suspect Xen might be insulated by the fact that we don't have parallel AP start (yet), so we don't have the whole system competing on the spinlock at once. Nevertheless, there's a lot of improvement available.  We still have a lot of pre-64bit logic that we haven't purged yet. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Jan 22 17:28:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 17:28:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211663.1523155 (Exim 4.92) (envelope-from ) id 1viyTd-0003ki-Un; Thu, 22 Jan 2026 17:28:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211663.1523155; Thu, 22 Jan 2026 17: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 1viyTd-0003kb-SE; Thu, 22 Jan 2026 17:28:13 +0000 Received: by outflank-mailman (input) for mailman id 1211663; Thu, 22 Jan 2026 17:28:12 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viyTc-0003kV-Qi for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 17:28:12 +0000 Received: from mail186-9.suw21.mandrillapp.com (mail186-9.suw21.mandrillapp.com [198.2.186.9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b8626e57-f7b7-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 18:28:10 +0100 (CET) Received: from pmta10.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail186-9.suw21.mandrillapp.com (Mailchimp) with ESMTP id 4dxp1N4Gl0zK5vjPv for ; Thu, 22 Jan 2026 17:28:08 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 8cd8f511eebb4c29940059645c0d1088; Thu, 22 Jan 2026 17:28: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: b8626e57-f7b7-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1769102888; x=1769372888; bh=2CJFtNoeEnYzJ4IdD/VPYcKwKjBorNmJNo2sQS6vEb4=; 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=U3OPOP6F/IikCUMKeHQAQG5eQjVeUN7jtWnXZP9bYJfZ70DWG9/2Mby2b1TkhySrz SNYAtyFiqwXeFzj7p8p2sLN+taVJIg1LhPQgIkkHL58Od3OkSLf5S1HTZyCvhZS9f0 TAVF5diLtCrmMwKULy+mhjnPayaB93b7w9neYtwlNPcvSrENPaLMNovd5DPoo6QiP5 EgTER/dKqKGRuLFIevKqjkbH/DTxLFIQu+Hs9XPHm3ZeE+5i4r8l0FNDQMptBnAYNZ DOnRUAkVHGTfkU7S63frsCnAQ1PuUasCkFxIgl6tsSgLmhWvf9k6xIJQchsma/pExa 54eFT49FLXhoQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1769102888; x=1769363388; i=teddy.astie@vates.tech; bh=2CJFtNoeEnYzJ4IdD/VPYcKwKjBorNmJNo2sQS6vEb4=; 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=XkHuV7vhjQlzcKDiF0/XFBJhMoVFwZM0Lv5QR4tcWo0A1uzdHXbxPzRMq99Tem+Mg 3WSh/E9GDmr7F2H3oF7mSEkcTu1oWi1Pl7g4340TdJ2cy/PQq4dl2qXAWCUQHF5xzu jwtPNrAm+qk9YTqsLynvZgfzUJvElYw+vLBrEnFoAOBMNiy7SMfZbpanfRnLT9Ltu3 u1ELC88ygWPFbuz+++E5YFOQbUyy9H7zAMUiT/qaEdLaeKkTklVFcIn9cMiNmRmiHR 6dAreAdj1sjo2a6H/fbEg9bVxol6NmmGqCkt8Sw3l7M+5IT/iIOuszuyf69NgXGjQD UmV0+PNLTNxPw== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=202/4]=20x86/hvm:=20Disable=20non-FEP=20cross-vendor=20handling=20in=20#UD=20handler?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1769102887179 Message-Id: To: "Alejandro Vallejo" , xen-devel@lists.xenproject.org Cc: "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Jason Andryuk" References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <20260122164943.20691-3-alejandro.garciavallejo@amd.com> In-Reply-To: <20260122164943.20691-3-alejandro.garciavallejo@amd.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.8cd8f511eebb4c29940059645c0d1088?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260122:md Date: Thu, 22 Jan 2026 17:28:08 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 22/01/2026 =C3=A0 17:52, Alejandro Vallejo a =C3=A9crit=C2=A0: > Remove cross-vendor support now that VMs can no longer have a different > vendor than the host, leaving FEP as the sole raison-d'=C3=AAtre for #UD > interception. > > Not a functional change. > > Signed-off-by: Alejandro Vallejo > --- > xen/arch/x86/hvm/hvm.c | 25 ++++--------------------- > xen/arch/x86/hvm/svm/svm.c | 4 ++-- > xen/arch/x86/hvm/vmx/vmx.c | 4 ++-- > 3 files changed, 8 insertions(+), 25 deletions(-) > > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c > index 4d37a93c57..611ff83a60 100644 > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -3832,28 +3832,13 @@ int hvm_descriptor_access_intercept(uint64_t exit= _info, > return X86EMUL_OKAY; > } > > -static bool cf_check is_cross_vendor( > - const struct x86_emulate_state *state, const struct x86_emulate_ctxt= *ctxt) > -{ > - switch ( ctxt->opcode ) > - { > - case X86EMUL_OPC(0x0f, 0x05): /* syscall */ > - case X86EMUL_OPC(0x0f, 0x34): /* sysenter */ > - case X86EMUL_OPC(0x0f, 0x35): /* sysexit */ > - return true; > - } > - > - return false; > -} > - > +#ifdef CONFIG_HVM_FEP I'm not sure it is wise to put it being ifdef given that we have it in support.h. Given that this function now assume we have FEP enabled (since it's only called in that case), I think we should rename it to reflect that, like "hvm_fep_intercept" and drop the non-FEP logic. > void hvm_ud_intercept(struct cpu_user_regs *regs) > { > struct vcpu *cur =3D current; > - bool should_emulate =3D > - cur->domain->arch.cpuid->x86_vendor !=3D boot_cpu_data.x86_vendo= r; > struct hvm_emulate_ctxt ctxt; > > - hvm_emulate_init_once(&ctxt, opt_hvm_fep ? NULL : is_cross_vendor, r= egs); > + hvm_emulate_init_once(&ctxt, NULL, regs); > > if ( opt_hvm_fep ) > { > @@ -3878,12 +3863,9 @@ void hvm_ud_intercept(struct cpu_user_regs *regs) > regs->rip =3D (uint32_t)regs->rip; > > add_taint(TAINT_HVM_FEP); > - > - should_emulate =3D true; > } > } > - > - if ( !should_emulate ) > + else > { > hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC); > return; > @@ -3903,6 +3885,7 @@ void hvm_ud_intercept(struct cpu_user_regs *regs) > break; > } > } > +#endif /* CONFIG_HVM_FEP */ > > enum hvm_intblk hvm_interrupt_blocked(struct vcpu *v, struct hvm_intack= intack) > { > diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c > index 18ba837738..0658ca990f 100644 > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -589,8 +589,7 @@ static void cf_check svm_cpuid_policy_changed(struct = vcpu *v) > const struct cpu_policy *cp =3D v->domain->arch.cpu_policy; > u32 bitmap =3D vmcb_get_exception_intercepts(vmcb); > > - if ( opt_hvm_fep || > - (v->domain->arch.cpuid->x86_vendor !=3D boot_cpu_data.x86_vendo= r) ) > + if ( opt_hvm_fep ) > bitmap |=3D (1U << X86_EXC_UD); > else > bitmap &=3D ~(1U << X86_EXC_UD); > @@ -2810,6 +2809,7 @@ void asmlinkage svm_vmexit_handler(void) > break; > > case VMEXIT_EXCEPTION_UD: > + BUG_ON(!IS_ENABLED(CONFIG_HVM_FEP)); > hvm_ud_intercept(regs); > break; > > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c > index 40e4c71244..34e988ee61 100644 > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -797,8 +797,7 @@ static void cf_check vmx_cpuid_policy_changed(struct = vcpu *v) > const struct cpu_policy *cp =3D v->domain->arch.cpu_policy; > int rc =3D 0; > > - if ( opt_hvm_fep || > - (v->domain->arch.cpuid->x86_vendor !=3D boot_cpu_data.x86_vendo= r) ) > + if ( opt_hvm_fep ) > v->arch.hvm.vmx.exception_bitmap |=3D (1U << X86_EXC_UD); > else > v->arch.hvm.vmx.exception_bitmap &=3D ~(1U << X86_EXC_UD); > @@ -4576,6 +4575,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_= regs *regs) > /* Already handled above. */ > break; > case X86_EXC_UD: > + BUG_ON(!IS_ENABLED(CONFIG_HVM_FEP)); > TRACE(TRC_HVM_TRAP, vector); > hvm_ud_intercept(regs); > break; -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Thu Jan 22 17:35:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 17:35:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211672.1523166 (Exim 4.92) (envelope-from ) id 1viya5-0005au-Jz; Thu, 22 Jan 2026 17:34:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211672.1523166; Thu, 22 Jan 2026 17: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 1viya5-0005an-GT; Thu, 22 Jan 2026 17:34:53 +0000 Received: by outflank-mailman (input) for mailman id 1211672; Thu, 22 Jan 2026 17:34: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 1viya3-0005ah-JL for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 17:34:51 +0000 Received: from mail137-14.atl71.mandrillapp.com (mail137-14.atl71.mandrillapp.com [198.2.137.14]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a639d2e1-f7b8-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 18:34:49 +0100 (CET) Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail137-14.atl71.mandrillapp.com (Mailchimp) with ESMTP id 4dxp932T4dz705dXs for ; Thu, 22 Jan 2026 17:34:47 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id c12c0e3f7df14035bdb50030d6959289; Thu, 22 Jan 2026 17:34: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: a639d2e1-f7b8-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1769103287; x=1769373287; bh=XDB3paIX0lxRE31VKOtSX6mrjON5bOkhtgKr0rNI1vw=; 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=AZxWepmkRwIFli7hbAQ77XxhRUjvlgiglyez8j0OtXjBOFh/xiz3YF58JxNJyVRBT syLVXr0z0aZEdIgFfbvvO/sDs2oQbU1IbQcJUl+V5KwyAE+f4rSCnTEjudZAaELM+t pKmiq4hc0gIuuI+iwonEFTNz8MkWkEJoJApqj+0KRXCTO8K+m5SQkfq8crppiYQwP7 RzG68WHnC6XdCqsaUR3UvM8TnrZ4Nslh2bmHWYAXZayCY95omuRp2ANK23cZEWQxhJ 9PnCE9svQsOLOCaLSN8KWQzcdQgPDy/CZbSZthwqURWV7J26qYLhUi6S6VuXfsRo4X zFI4CdGyQf1bg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1769103287; x=1769363787; i=teddy.astie@vates.tech; bh=XDB3paIX0lxRE31VKOtSX6mrjON5bOkhtgKr0rNI1vw=; 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=S7m8MhOsrdsTmNivJ0e7Do574QIEhq5r1UjNxmfQVgqq3Na6MdjvAjUOHWmOErv9h Ke2fkANd50H9abAeC3U5IEKkZcIBiZaGRy2WbZ3SE38F5AGIEEoOABm4oYVj30rkYJ GWmGjWv3j/+v51MWos/TcPTU4dDfGe+SNRnHEvep1BjE+TO1uUr7feJrx4YR5GZVWI mbS5XsKNnZMz49pLjE/t/MOJvxVpzUJ4vu3XtEIHBvr0+C31rgOoEMH7hW3xf9F5Fc bbMNbnocHesRu4p2M3Bho2ffGMvF1OgL6Dm+X/ybOECTnhJIkw30tA+E5Gs6+hcPh5 gK2Syhj2Ril1Q== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=203/4]=20x86/hvm:=20Remove=20cross-vendor=20checks=20from=20MSR=20handlers.?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1769103285334 Message-Id: <436fddc7-ca06-4028-9cfd-b57bb236112d@vates.tech> To: "Alejandro Vallejo" , xen-devel@lists.xenproject.org Cc: "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <20260122164943.20691-4-alejandro.garciavallejo@amd.com> In-Reply-To: <20260122164943.20691-4-alejandro.garciavallejo@amd.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.c12c0e3f7df14035bdb50030d6959289?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260122:md Date: Thu, 22 Jan 2026 17:34:47 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 22/01/2026 =C3=A0 17:51, Alejandro Vallejo a =C3=A9crit=C2=A0: > Not a functional change now that cross-vendor guests are not launchable. > > Signed-off-by: Alejandro Vallejo > --- > xen/arch/x86/msr.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c > index ad75a2e108..c9cc4f0692 100644 > --- a/xen/arch/x86/msr.c > +++ b/xen/arch/x86/msr.c > @@ -169,9 +169,9 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_= t *val) > break; > > case MSR_IA32_PLATFORM_ID: > - if ( !(cp->x86_vendor & X86_VENDOR_INTEL) || > - !(boot_cpu_data.x86_vendor & X86_VENDOR_INTEL) ) > + if ( cp->x86_vendor !=3D X86_VENDOR_INTEL ) > goto gp_fault; > + > rdmsrl(MSR_IA32_PLATFORM_ID, *val); > break; > > @@ -190,8 +190,6 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_= t *val) > * the guest. > */ > if ( !(cp->x86_vendor & (X86_VENDOR_INTEL | X86_VENDOR_AMD)) || > - !(boot_cpu_data.x86_vendor & > - (X86_VENDOR_INTEL | X86_VENDOR_AMD)) || > rdmsr_safe(MSR_AMD_PATCHLEVEL, val) ) > goto gp_fault; > break; Reviewed-by: Teddy Astie -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Thu Jan 22 17:37:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 17:37:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211682.1523176 (Exim 4.92) (envelope-from ) id 1viycC-00066f-Ua; Thu, 22 Jan 2026 17:37:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211682.1523176; Thu, 22 Jan 2026 17:37:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viycC-00066Y-RN; Thu, 22 Jan 2026 17:37:04 +0000 Received: by outflank-mailman (input) for mailman id 1211682; Thu, 22 Jan 2026 17:37:03 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viycB-00066L-70 for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 17:37:03 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f494576a-f7b8-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 18:37:01 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SA1PR03MB7055.namprd03.prod.outlook.com (2603:10b6:806:33b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Thu, 22 Jan 2026 17:36:57 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 17: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" X-Inumbo-ID: f494576a-f7b8-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=x2H1VdxzLOxD2V8yjta41z6vnmOg2TL8pTi5BwTzUi2jeZb3XSVnplytBIOit0wVf31+jLXKZ2QHoJtjST1MOKbDW9RS0JSfnj7/pcu8bBv/J6FMGx4iAKDS22koqQfCEDuIY/Ne33gj52gnG871mx/SeItgvKMezs97mhfPdRWm+Q0quSxJ1m7L3JpjJ4jAekJTFWju8Tw2r8aWh7F1ZvfmKqaRxL5wGCe2TB8efJyKOC5SLgYqhcWSWOpgwQ7/XtV3T68WxrV1jEjF6fDkx336C/8ynBicuckIGYEX8npvWL9k68B69K2jDGEwAIuXNfNHYk9Cd3qQjHhZ0rBXiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZlAC46lK72spREpnbCGNu31tzXPA7PAIzZjBPAfIdPU=; b=ms59JA4kZey91pz/X62lVeAmYvgb80sISvO25r/Ui1I2FtUPmFTWGqx7/v+TcnRQlta6j9WUzICXfvG/VXMcGELsd/K5VwSL5s/ML/R/4VGxfd6MFIu8LntnwYFfCAyHnT5RfcMwquxd2xUHlVbyVjzJfpiuOmuFtLfNnUSjwL6OLrpAmaUvEN5D7A4NqX5WfLyXP8Kzl9Zll7hUD5Oi2khtHkSlwCDP+USDlKYxnpIFem9ZB3RPh3Sce3PeINXC765/Ey6YMTrVuV0/nZM9x7EeVgA0bkQIKH3n6f3UrllJuXX3F5t0zDOV3z+3APpTzRyGwbTraE/8V0+Qmfn7MQ== 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=ZlAC46lK72spREpnbCGNu31tzXPA7PAIzZjBPAfIdPU=; b=uBm6yll42PqHmgWFxBTso/168Mv5pcmF2+sIUQvfaiCs7AhMPl7J+DC6JqUejraka3FhVDsE5fGGZZq4LWS+cZfKzSQZG3NbIIZ0EJ3erLk2deSdRPEcviWFgTHjFiTj9suDTKqJtGVjKqyYvOeqVpaLE5fihJEuRlEVRsDUe/I= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 22 Jan 2026 18:36:53 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= , "xen-devel@lists.xenproject.org" , Jan Beulich Subject: Re: MTRR init sequence in Xen Message-ID: References: <145af46c-eab5-4d0f-ba35-4ae646c0e4cd@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: PA7P264CA0465.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:398::20) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SA1PR03MB7055:EE_ X-MS-Office365-Filtering-Correlation-Id: 8fe8b2c7-eef4-4736-09b2-08de59dcd6f7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?cmpBaVl4RkowNmtWa3dDdlR0NGRsTFpUdTkxc3JLNWlPdyt4SjA5ZUs0NGtv?= =?utf-8?B?b3R5RXY0OUF0Zlk0VDNFY2FKbzRTWm1WVWxaREZmbXFwcUdjcE9ZLzhNWGZM?= =?utf-8?B?WUo0ZG94Y0c2eWRNYWFjYlhXWURQTkRyeWJobFlTcm14K01MQzl3VFVQOU5n?= =?utf-8?B?QXM1NGU4OFd4NUVTOHZtNCthQ1cvTGlhc1U1OFdDMHdoejR4YzZhU0dKTk9p?= =?utf-8?B?eE9oZS9rdTNLMjFxbVlQVTFoSTRqQStxSjlDTnpBa2Z4V0F0NEJLbjUzNmxl?= =?utf-8?B?bmd0SFBBRFdIU0F5SkFNd0xlTEdsQjRrMEtYS2N1eUE5WFEyWjlBQUxlYjE0?= =?utf-8?B?UFgvSTdZVWpCN2Yxd1MrdG5hSzRZU2pCQVdNejhoUWhjRGlFcmIwa2ZQb2pE?= =?utf-8?B?VlR6VGszdFpFZDAvTlFjQzMvQS9ZaWE1Wk54R2xYV3N5ZnNPaVphalJRS2RV?= =?utf-8?B?aEJ4SndNSGR0eDAyb1FFOW4zVkNwT1c2ZjNkM2FRaFlFb3k1NXUwNy84eWFK?= =?utf-8?B?cXlocWxsQTFxZFJNNmU1VVY3K2dFZ3lETVdYc2lNTWxQdkFmcXBvdEJmTkU2?= =?utf-8?B?OW1zSUFBNWMwK3hsV2JpeGprTmZRZzA1MWkyNzhLQ1h2dHBERVVHRlZmZnRE?= =?utf-8?B?SnFjQW4zczN5L0h5K3Y5c3phUE9UbFZYNWdBeG96enFuMWVSVlk5enFFcnRR?= =?utf-8?B?Y0l2QzVoMzlOYVVNS1lDRWRCZ3l6cWhGYmY0cVR3ZitOMUM2dzM1bC9hZEZk?= =?utf-8?B?eDExMlR0NFdHb0FHd1NZK1YxRTg3aGF4azVaeHY3NE1Pak9QcVgvTTRBdU1V?= =?utf-8?B?OWpJaXJSN3VkdElVZzhFRWNyQTI3YzM4VnJrRnJZa29LWnZUL1g1RUZwQk5s?= =?utf-8?B?b3J6Q1ZXVFhuQWhaY2l1clNtcGRaMlNQaEw2NWw0U2lvVTMzMDl4MjhiSmsx?= =?utf-8?B?QWV2SndnemZaMG1Ob1lMZ0E1dmQ4TUEzQndVNklCZFBZaTBMQ3VPTkRSd1FE?= =?utf-8?B?UmZOSUJNOGZkZ0NWdGx6NDAxQllsenNCUkVJT3BJSlkrTlhIcHZnL0tPcTNu?= =?utf-8?B?MlE5RGx4SDVucGRWNUxtR0RHSjVlVUZDc3dvMndDNW00Nzh6WHAwWEpWbTJn?= =?utf-8?B?ODZyaDBwQ2pUT2p1NFd2QVNNa09GMmNqQzMyT0E0YjE0VTBkNTBaZ0dsY2VE?= =?utf-8?B?bi81aW1GQW5FME01U0hRYi8xem9qT2FBeHBCUmRxVXFpUk9wcW90M1ROVHpk?= =?utf-8?B?amtnNWJ5Mis4U0t2SEJUSGx1ZENmMnl0U0puWDJBL2FrdFBJWFR2am10TlBS?= =?utf-8?B?MzR5cWxxTzFycVp5aGpnVlc0WEJUZHVJYktLRit5ODRJZ3FHT09vMlpBYkZZ?= =?utf-8?B?eHJEeEtGeFgzUVV2KzdkT1U2VDZ2NG5vdHJOSXVnbFhtVDA0RXNjRDdtbkRq?= =?utf-8?B?QmhxOTBzV2RzQjF3RlFYSmFOcHNKRWNrUm5LQUNaTFFnZ091SnlXRlZDVjJz?= =?utf-8?B?THk0MzNpTURKSGF0ek80eFplSUc3aklXYVdJUndzV1AwNUVaN3BLdGlmYXVJ?= =?utf-8?B?Rm13NTYwU0UxOGhzQmM3RnBnOGgzdXU5Zk5wemZWUHdPQzRkbDJGOHpiTTVv?= =?utf-8?B?L1lpMHpDWGJEUFZsOXpCbkgybW43aE5WcjJjMTVubzhFb3FRc1AvQzdhOUs1?= =?utf-8?B?dGhUOFNKM2libmxjM2xXaW9sbVU0K3BlMlU0TmtkNmlNUU1mQmJobjZ0MjRY?= =?utf-8?B?Y1NYaGdJSGUxY3gwTm54SWxKeEVpM1hzNXJJUWlFeis0d3N0cVROYzlxSE5D?= =?utf-8?B?anpiZmQyaTlMRURKd1pQc3YyWWZFL1R3bG5ZVzRRbXpNVEsrMnlZTVVzNFpP?= =?utf-8?B?Ynp1NTNFb3AxWHlXVElEQzJZd3pWOWp4OUk5Y24wQmZoZVhqVU8vVUxYem42?= =?utf-8?B?OUpuc2tBWWY2YTVpVU1XcTQwR1FOUDVKOTkyL3VEakpXc3JMTzNPVXBBcTFl?= =?utf-8?B?WjEwbW5FSnQyYkh4Tk1CQ2FsYmhhR0RBSER3NXdPenRmblFqZHd1dzdYaXRE?= =?utf-8?B?MXJVNVp5TTkzQTF1SjhnbGs3TjA0aFdWVlFvYjJNOGN6VFNtL2c0Wlk1Lzl2?= =?utf-8?Q?gq3mNAlvrgyHuHXJCIjoNsouC?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MndxV1RDdkR3eGFFeVA2dW9Nd0Y0WTFuQUNpV25pWEJrd1luc0FSaE1CNlBD?= =?utf-8?B?SXVrN0l5aDRBcGJMdkFWQ1MyZWR2SkhoQURvR1E1K3djRWdCRlRPby9aMXlC?= =?utf-8?B?V3QvUjdoM0syVHJrTkNGT2M4MDRPTWIxWEZaZTZtYjZldjFYbHRwcUJyVmxO?= =?utf-8?B?WTM0RE01UjUvL1BPa1BhY1ZjVUxObmVXNXJuSUhIRDNLN2VsaDZEM3JweHpO?= =?utf-8?B?NjhENWlpN3dSY1EzTm1ONUMrSTZKd1hmZmdlVnRTVmV5QmxqSG1ia2lDakJL?= =?utf-8?B?ck5CU3lVaGdudk5JYnFIa2ZETmFFR1Z5TDFlZkMrT1ltODBUNFB4Z2NVTElx?= =?utf-8?B?NEVHTG0xQVNyYjhIbW1ZTjFCWHhpWnRjSFVzNk56YlV0cVByMjg0bzRCUVRU?= =?utf-8?B?OE0rd29zUWozQXFJejRYMCtWeGhrVGdvNTI2bVl2NC91Z1V1cVZ6alFtVnFY?= =?utf-8?B?aVduM1l4V0xac1IrVjBOTkMxQS9SWU1NWWZBYTBZOHh3Y3QzREZNS0FtS2k3?= =?utf-8?B?QXI5L2VBQTc3Q0ZzZTBkSlBkbDFVNitNc1p5dWJzRGR0MzRRbmYwTCtZNUlm?= =?utf-8?B?YXNFT2d0b0tsa0FEQXdQQkkxVXRRWWM4VTVNTXB6QlJ1NDNLbTl3b2xwbmtk?= =?utf-8?B?eHdzbi8wWExNTlRqODA0SS9NUDZjT0dmaXI2SWxOK2hDRTBUSW11VHlZbG5U?= =?utf-8?B?czlRRVdNNUZ3bXV6dU1JUlVDbmp3T1U5T2dLUzgvUTFCVmIwYzBTTEJ5MTBI?= =?utf-8?B?RkMwZWhOcDVUNzM5RlEyRDNyMWZUQ0NEMzBCSzdzK2treld6dWdpMythZkdh?= =?utf-8?B?RW5FaHpzM1cxdmwySXFtaGZEVHk2MkE4UThnN21ZV1U0bXdIdi9BVzBxT1dN?= =?utf-8?B?a3JBWkRaUnFOUlZtajRNZllmV1FqdDdBUkg0N2R6d1lwL0NNNTF3ZlFvd3FS?= =?utf-8?B?UTRrcnVHNzNWUVpudGVSSUZ3aWhGYUJzZXdrdzZUWWpOZXhLakdXQkRJSDNI?= =?utf-8?B?Tnh1VUU3SG9aanc1amVma3Q4MGUrVUp0NE5lZ095Wi9kTTRzNUpoOVBRYmlD?= =?utf-8?B?TXhaK1dnNHk1dmhyb21DSkNDOUpiRHFub2o3eTNPMzRZdllPUmFQSXJnWE9M?= =?utf-8?B?VXpVeElUaWNqZUpVZ0tHbEpXVXpUWWRicEMwNnpnYnRoS08xKyt0YW5hdUFR?= =?utf-8?B?QStQVnRmQTRIQzdqQmtJUXc2cC9PUU4vRkJnVS9ORVN3eU9WQXU5b0srbkFs?= =?utf-8?B?d3d3WjZlS0xiTTJISVVDKy9CUE9qemFOUUFDWUs4TTFncUlEU0ZIMGNhSTE3?= =?utf-8?B?U0JreitOMzBGSnRHODZNV1dFV3paSGNvbk1WeW83aFM1dEI4UitXZXR2UHVF?= =?utf-8?B?cE5Fc1BXWkdiM092VkVtdlZUcFVFMUk4ak9DQllZYktZWjM3b0xOek9tMDBJ?= =?utf-8?B?K0ZueGNPd096VUZuSEFwZkduaDJ6TE1EcGV4TCtSTjZDQkk0Q2dvUGx0a2U5?= =?utf-8?B?ZVEvLzhuY2taZzMxeUZ3SStoQVpDUEkwZlBFSlgyQ0xqbXArRytZaGp2VzVV?= =?utf-8?B?bjhlZm5JVjNpN0hCeGJsT0laTE9HK0dYelJqeVl4WFFOQ0R2QXFCYmRxNEZu?= =?utf-8?B?My9kd3U5TE5RQXBqeTYxZ3RSRmxLSW11Q1ZGaFFtK3BKdCtvYmcyYkZhOVpJ?= =?utf-8?B?K2ZwYWdTVmR2S01tTkRhbm80RmhIL0VkWWFlSEQvRFl4VkNTcTZUTzFldDls?= =?utf-8?B?clBnR01naUlQdElzeE4rWWhkY0JzcSsxTVR6emRUajJUNHBDd0JadkZ0TzRT?= =?utf-8?B?QmlKZ1hGNFcwQ1ljU2RNempTK2JKMXZrR3h5NUE0WlAxY1FoZmUzZ1BaSjdz?= =?utf-8?B?ZFRVZTE1dUFSRFZPdklsZlZBYVJPVE0xV2JkWjIrNUlJOTg2a2c5Mm8rYWZL?= =?utf-8?B?aGQ3OHBSTmxvcXNYS1IrKzVxa2t6Y1N6bVFzV3VITzFLVkM2ZVFSUEJ0NlBi?= =?utf-8?B?VDB5WlZnNjR5R2l2ei84bmFOQXlZQXRxS3c5TERnN3dISGNvVldaY2JWd3NN?= =?utf-8?B?VlZxUVpNclR6ZkFWVThhR0hsc3ZuQnlkVUt6STdjNWkwdVdidldCU1AyZmhj?= =?utf-8?B?d1lvcloyeDdZcTY1Z0UvLzNCVlBkNkl1UzNxUWp2NDZvUlJRazBzbExyalND?= =?utf-8?B?SkRqdjhORGo3WWpEYVNmU1V3dFVKalVsVHFGNldGVUlENUh1UXAzeUwvWHpl?= =?utf-8?B?RnBJOFB6SEJWeUl0QWhYN2xQZy8xTkgxaGpBVmxTbG5pQ01sRTNZaXdCY3JN?= =?utf-8?B?cXRMcjJMNm5XOHozVHdLalFyc2l3Yk9pUDRvZE80TGQxYm9FVDd3Zz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8fe8b2c7-eef4-4736-09b2-08de59dcd6f7 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 17:36:56.9808 (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: cSEAfYmcyAiGV8Hbvtt2Lw8qEq871O6+oDt6nOw1RjJ+Jdc04dGfef/KyS1jhFLk+gXVebAwuV0jzMY9zvj76Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR03MB7055 On Thu, Jan 22, 2026 at 05:21:12PM +0000, Andrew Cooper wrote: > On 22/01/2026 3:56 pm, Jürgen Groß wrote: > > Just as a heads up: a hardware partner of SUSE has seen hard lockups > > of the Linux kernel during boot on a new machine. This machine has > > 8 NUMA nodes and 960 CPUs. The hang occurs in roughly 1.5% of the boot > > attempts in MTRR initialization of the APs. > > > > I have sent a small patch series to LKML which seems to fix the problem: > > https://lore.kernel.org/lkml/20260121141106.755458-1-jgross@suse.com/ > > > > As Xen MTRR handling is taken from the Linux kernel, I guess the same > > problem could happen in Xen, too. > > > > As the hang always occurred while waiting for the lock, which is > > serializing the single CPUs doing MTRR initialization, my solution was > > to eliminate the lock, allowing all APs to init MTRRs in parallel. > > > > Maybe we want to do the same in Xen. > > I suspect Xen might be insulated by the fact that we don't have parallel > AP start (yet), so we don't have the whole system competing on the > spinlock at once. Oh, I think I've misunderstood the issue. Linux is doing MTRR init in the AP startup path, and so if it takes too long Linux will report that the AP has failed to start. This is not an issue on Xen because MTRR initialization is deferred until all APs are up, and hence is not part of the timed AP start path. This optimization was done in: 0d22c8d92c6c x86: CPU synchronization while doing MTRR register update So even if we did parallel AP startup we won't likely be affected, because we would still defer the MTRR setup until all APs are up. Regards, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 22 17:40:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 17:40:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211701.1523187 (Exim 4.92) (envelope-from ) id 1viyf4-0007Kq-I7; Thu, 22 Jan 2026 17:40:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211701.1523187; Thu, 22 Jan 2026 17:40:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viyf4-0007KN-DF; Thu, 22 Jan 2026 17:40:02 +0000 Received: by outflank-mailman (input) for mailman id 1211701; Thu, 22 Jan 2026 17:40: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 1viyf2-0007E8-W8 for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 17:40:00 +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 5e6734b7-f7b9-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 18:39:58 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by PH0PR03MB6512.namprd03.prod.outlook.com (2603:10b6:510:be::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Thu, 22 Jan 2026 17:39:55 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 17:39: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: 5e6734b7-f7b9-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=aS2qglNtDpuVnA19PDpS1QLOa6lpx28TK34771zuVvuQFc/QNtIvmf28UapqByUIy53xCd/zaWbqUwfGIbUv29AfC1OCH1QjWrktoHhBaYYu2KqU7chknf/P2Y8lZQun/cdAVaxMSPUKq4r5yLVC0yGp/WC90abtunp/ivzPb/e5RFS6PaDnhRcRlZjf5AJ1zXRkupWm/fnz2WXOoqqog88CGpjXCLW88n5wDXoVKCCoX6ZnHEtfSeTTptqNRDhJOV8I5G/YWUx1nElocYhCXJdIBuaayS7kspMCtS7/HV4I26+cGs79/kmSd+gbydi7KMTQlTJDG3KhhMK1tiW+OQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EBwER9b45odcluja2CMRmJt8e2G3orBXFTuueEpDCBA=; b=Bj2un0MGnmlWscYij3khevmVxudZwx2Ay37d/mtXzL2hBMLHOkruklc/cFhbv8tFW4Edev9A7lPFb83rQSt9Rx2PYg4MOAuNM/rEFNQLAxHmCfFuelVSl/GnN5/Vty7Mp5VYmpTBYC3O53ixfg3GV9SMIvpqyl4e4N3ooJ94SnWUTZs9+mENjhS43WXep5Tq+92B+xpiBzReTiPk4/wrPCIWV9oyQrxML2zPTjYP5MVboszqjsHRyjGQg/NXOsOQMKlMupb50LjEA/ZfL29DfdnY21IZyiC1m58NnUgVssNwjspqRIIo3PJKVJHPzU+BWYVCvlvCzx3nwxHHvdS7Cg== 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=EBwER9b45odcluja2CMRmJt8e2G3orBXFTuueEpDCBA=; b=z5qUqD+seotZYVP285VGxU23uOg4+g0iPes/NT4rmmwArN+s6M8yjodRh6Hn3teTw1HVJA4zuEm39Oc9d1i8WTRRw6KromSg1lkhxkavL16N4+yaQrgLoytfq0VWDYgqJlSm/sgwOaCm2andAZsK9PksJPmQaVn8NoiguHBUB2Y= 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 , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v3 0/3] xen/mm: limit in-place scrubbing Date: Thu, 22 Jan 2026 18:38:54 +0100 Message-ID: <20260122173857.83860-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: PR3P189CA0010.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:52::15) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|PH0PR03MB6512:EE_ X-MS-Office365-Filtering-Correlation-Id: 88e94c30-da8d-4001-e808-08de59dd3f57 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?MG10VzdweXVuN0xiMTE5SnNFUi9CcmJTdTNDTElwRjlsMjJMWEt5cGF3bGpI?= =?utf-8?B?YVRIUWlMVkE1RnFoV1NtR0tOOUJZdWtJTmgvaElGYWtkSVU3ODVGODNTQ2Yx?= =?utf-8?B?ZUlwM2J2S2FJdWkvcUZpL1lsQjEzd3MrSXh2NGpJbWV0N2g1M3IrZk9xL0VP?= =?utf-8?B?NDRUbENFS0EyYmFVSHNvYlN4ZC9MMWZTa2d4NXNxVVdhcjBtUWV2SWF2NUtn?= =?utf-8?B?YjkyM0kzM2dNVUdxQ0RZS0I5ZVlmUGFKTkRFa3V0aXhaV1loR1NYRFhDMzd6?= =?utf-8?B?SWJKaVRtRHNZemdxUkszb05SVC9FTzNWT2Rod0lINzMxcFREbkNZZGlJeEUz?= =?utf-8?B?R2tjYXhMQlE5RWV6TXF6bFd0U0hUN3hjWm5wVEtBQlZNUUFLSHZhdmwvSkIw?= =?utf-8?B?a09CdWh2c0dqNm1HalhmcUtLS244Y2lYRHFsaTVtVmZRalQ1NkluVDBoNXo4?= =?utf-8?B?OFlyQkdESEgwdEVxdmlEcS84TzVqV08xdEpQcEMwWWVrakhBTlVJeEVaL0Iv?= =?utf-8?B?SmdRcGRXNWpQZCsyMVMwS25sSzB4Y3lXWmJ1SFc1MnJISDFDNDJxUHlCNld4?= =?utf-8?B?TDlHbXVJVmlnalFTRXprMkFKU2dpK3h2em0zTUdoUjNOdk53Snh2cEdaNisr?= =?utf-8?B?MVUycmdlSEhmSzZpS2tFTTFPazUybDlmalNrTDAyNFk5eXlsdm9PQkx5Zktk?= =?utf-8?B?UXRteWNKR1lLTUtnc1VpRkhSSkxha2JQbDFJYlNIYjU0WWljdTA5WWVMandG?= =?utf-8?B?U01KQ3VRRldJekdjMXUzUUZFbzU0L0lKTTdiOFh1cE5Pa0VVR3FMWUpmWENZ?= =?utf-8?B?R0JyNTBVVmRIZUx2OFVER1o0Z29pVURXODU1QWFER25ONVQrVEVkWlYvcGlh?= =?utf-8?B?K0JvRE1BS001N1V0ZEhrQUFNNjg0ZUxvQW5QSkU0Y0NBRG0xRXY5Ny85aTBO?= =?utf-8?B?bHk5UnYwWFRKM2RZYVZVL0taRXNQZWlCbEIwQjlJaE1ySWtNeWplSkszSGNY?= =?utf-8?B?MXR4WFFZUVJpTWxoeE5QQWFxTmRkTU9GREUxS0dydDd0V3ZQejA3aVpGeGU1?= =?utf-8?B?N2ZwSkxwZ0lpdXhrUHZYNGRSNzgxSTZOUmxJMG5rd0ptWU5hMFlJWEg5NENF?= =?utf-8?B?TDA1YXRJQXlEeG1ranc2cjFhTFJxMVV4SXcrOE92ZFlKbVByNGVvc2dtRkc5?= =?utf-8?B?bXNiZWJwOVU1VDZUMlZvVWRvZlhWYUFKQWdqemtGMzBhaEJIVnBmU0ZvVEpz?= =?utf-8?B?QjB1VXZTTFpObW1aSldHazladFl2L29Da0ZMSTViWmpxclJneHFFQXkxL1E4?= =?utf-8?B?L2o5RktuTnRpME8wNGR5N0F4b29uVjdvcmRDQWtVMk5MRVdJSzNXdUlIMGlx?= =?utf-8?B?Y28wR2Noa0ZFQjBhSy9ZRjlWMW9JeEhRRVNOaHNNbmFwMGtDL2N3Z0NGR05u?= =?utf-8?B?MFhvdHl0aGFQejNZamsrT3ZSaVR6KzJCUzBWaVhRU1Fma2JDUkVKbWZDdlVN?= =?utf-8?B?L3hSS3ZPcjU4TEVYbi9vZlFiZVB6UWxkSUtzZVFUVGpqbURKUFdvT0tvampp?= =?utf-8?B?ZEIyb2N6bkFPNlRQbWxSUGg1UzFjNmlZU0hIQWE1a1l4ODlsYmJNcTdGWVVi?= =?utf-8?B?TU91YXR0K0dZd04zWXJmWERuTGRLM2pBWHdVcXJVVXpxQ1UyYTU2MEVRM20x?= =?utf-8?B?b29qNllhbTRXdjVVZ0syaUNVZndZNTdhRzROa0hwbElHek1JMExDOEtCNVI2?= =?utf-8?B?b0oyY0lMTXR0K0UwejhlYVh1VHIvdjM3NnRiQjZDcmpJV1Yrb05BcGtwMlRa?= =?utf-8?B?cmVEVFlVMGxCSU5vTlVHTWlycHNIVFNqb3Vqa0FrM3BTdFZTYzFxc3Z6WFhQ?= =?utf-8?B?SDM5bUpXQUQvR1VOR3p5YnNtZ080N2hEUjRUUmpRaWlSaUNoYjZmN3U4dnFI?= =?utf-8?B?RTd4VHQwOU5YVVkrL3ViU2J4NXIwbEt5VG5SQTZOMFUwcXJ6a0pZU2paQUoz?= =?utf-8?B?T201QkRtUG1RdUtTUjNwZnl4aERiRDB5QXhCTHRKZDZ6ZHMzZWZkeG9RTGZi?= =?utf-8?B?UmpjcnppWFgvLysyT3BDeW15dDduaTYycnBKbmVDZ3YzT3E0QlgrWGo5bUlP?= =?utf-8?Q?enI8=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bUlGTEhYZjkzTGRPRzVqdVc2akVxTUg3TkZjUUNOajA5R0k2UkRFK21LZkVr?= =?utf-8?B?UThOelRRN0hPTUFMK2kxZVF3ZWovQkt6Z0txU3paRnYvVEo4cFJZaWR1djUw?= =?utf-8?B?MFFvWXJnSW55dkd1bk9qU09IblNrU0pFdTl2UnJMbUhDZWxqMEEyalU2Qlho?= =?utf-8?B?UkkvTm5weElQUkt0NnVDMW41bmpWUm9yVEVrY0wwN1RvR1ZuTzdkaXpFUnZH?= =?utf-8?B?aXpKQzhBNHA0ZnpoY1dVcURTYzArMWgvMnRpYy85c3pLMjBDQm1SUldhMTF4?= =?utf-8?B?YnpvVTlWT1ZZc2FEa3BUN29RYStJT1RhU1IySDBwbWZMNjIrd3BIanUycGZh?= =?utf-8?B?NVVWMFdTdnR3TWVrdFZuaHFvR1RhR0hZNmpaTkhWaERmNU5QYk9rODF6SjBS?= =?utf-8?B?WHkzbmM1NTIvS3A4UG9ERStkcEt4ZjJwRkNZVmVnWkNhNUVhakpyOERsOE9i?= =?utf-8?B?UlVyU1AwZHNIN01lNGxQeG1JWGxLS1hsTUFXT0NLKzJlM0h4NUhNYW5lc0FK?= =?utf-8?B?Y0dVOGJZWWRydXdhNStQWll4aFFXdUZBeTE0cjk4czRFMVFBL2ZrYVo5M1Np?= =?utf-8?B?YldjT0p6QzFVRG12Uzc1K1BuNjVkSDdhaGlPTUkxYmJEL25pUFNNT2NScXUv?= =?utf-8?B?bXlrS05UMUhnbmJvTEgxTkM3aXQ0N0JPb2Juc3JFZXhVYTZUOUZMRkxKMHdX?= =?utf-8?B?SXIrdkh5YUVLR2FkWFU5NFpzdG5lczRWVmhvYUR4OHJERWhMVVMyUEd4VVFO?= =?utf-8?B?NStFUEFwc1pRRGF3KzVxK293WHkwQmNQSUIyaktGSm52VklIVStSK3o5bDRv?= =?utf-8?B?WmRBc2NlUitqY0syOFg4dDlSeUZnUmFmYjFPZUVLWG1CRit3MURYSnMwM0NV?= =?utf-8?B?eFdNY0IxQmFBYmtobE5CcFJkS3d1TW5WdjE3TWptYUJ1NFVxeHNYRGZvcFRD?= =?utf-8?B?aytGL1NwcVR4Tk5aaGdIZjVhUUF6TmsrcG5TWFI2SC9VcUhyVlNRK2dEZTlW?= =?utf-8?B?OFFxOWFCTjJ2ajllL3J2aG9YNE9DdXV6NVJEMGpadWVZUDQ4cktucW11dmFu?= =?utf-8?B?Vm5Mamhma3ZjWUFIaHlYMldJWURBcG40dWhyN2htVUpVSUo5OGdwT2l3d09J?= =?utf-8?B?bTVyT1RzdmFkYklzTTloMUcwZWdReWd1ZlpMY3R2cDZaRE5uRE1IdDZZM3k5?= =?utf-8?B?Y1ZNeWFJb0NaSFNzK1F2ODZwMForcmxlUlI2aWE0cnZNTEdPRnFFY2U1UlVw?= =?utf-8?B?d2JWMjJXeUVLR0V5bzF1V3ZvWGxzbENkdnZUNE4zTi9UUmVsQmd1UG9RQ2FQ?= =?utf-8?B?TzZKY2l0aTlSL3VnSnZuVDlMQ2RuM1pZanY4L216Z1BOcklwekI1WTg2QXB2?= =?utf-8?B?NTNFbE92NXFpcVI5Z2tWbzFQdGh1SGJqeWNtY1N4MGM1TXFkekQzcGpHYUxS?= =?utf-8?B?MFJ5b3dnNk5YQkF2Q1diM1hmY0dWMmduL3R1MEMydU9Rc2VZOVVRMjhuV2pz?= =?utf-8?B?U08vdDVnNnY5cExUdElzSEdOaDhaMGY0bWR6bG1sOVVuSlRnai9kRnd0UDVZ?= =?utf-8?B?bC9seXdIWW5oN051L1V5bENJTUUva2J2S1c5eEUyNVpUUVNGMy9pRU9tS2NF?= =?utf-8?B?V0JNdG9FK1F5M2FFb3NxWE16eWpWYVc1aXhWaXJqT2xJTzhzU0V2ZTgrbk41?= =?utf-8?B?ZnFjYUlwbmRXN2xTWE5wNjhQNmhDQjN0NUVlUmJUcm5kRlJ1aVFEUDY0aVlD?= =?utf-8?B?cmZoUW94Y0FSZStDMTQyWlBBRW54alpqMDRFalpMdUNzWTdHbWdsZ0hxS3ln?= =?utf-8?B?blRvVVFsZFFheGNRU3VwcG94d0FSdmFKZlFmUU5wUGFZby9ZY1NuR0V1bGRU?= =?utf-8?B?NmxNY0lLNnhINXRiUExDV00zUUlTdWszWDlyK28yY2FsVHlSWVErbXdleUFH?= =?utf-8?B?RS9wbnVaQlRGaG1HMlhwczUxWWp5Z05KcFpZcFpFWkkzRlE5UDRLTlJFQjRo?= =?utf-8?B?T2ZqYUNiZ3kvMU41THQvd1VFQmJsZ1NKV1MwU2hHbmpYR2dqL1VUNFQwVjRB?= =?utf-8?B?K012TjFOVHJxZDdwWjRrcXdWVElHQWNjVTY2bHRYd3hsRGlYNGFWMVdkWEtj?= =?utf-8?B?RkFsTTVVNFhSZEJIbzMxT0FVWkJBeUtwSFpyYmtIRUpkU080b2xVREdFejFO?= =?utf-8?B?b0VBQzF4SENLL0MrTWYrdUhONG5JRXZiOTA5YkdReDUvVThxeis4Z25CQWZQ?= =?utf-8?B?cG9NVWVOVU1BWEVEdm9nMFRkTUpjWnphZ0NubkZhNDQ2blBhcnFmVEVJd2F6?= =?utf-8?B?T0FkS2I0UkxxSWFkaVpWS0hGMlFzMWNZcnh4OW9Dc1ZVeVlzL2hFdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 88e94c30-da8d-4001-e808-08de59dd3f57 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 17:39:51.9583 (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: DI5tTwnQK8bdaad7XdRjhNiJbf24/8uzCPyWbbsFgHffSHALIHYrWYuBqf5jrgIfyO4vSA6snxxDNMI6Ied48w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB6512 Hello, In XenServer we have seen the watchdog occasionally triggering during domain creation if 1GB pages are scrubbed in-place during physmap population. The following series attempt to mitigate this by adding preemption to page scrubbing in populate_physmap(). Also a new limit and command line option to signal the maximum allocation order when doing in-place scrubbing. This is set by default to CONFIG_PTDOM_MAX_ORDER. Thanks, Roger. Roger Pau Monne (3): xen/mm: enforce SCRUB_DEBUG checks for MEMF_no_scrub allocations xen/mm: allow deferred scrub of physmap populate allocated pages xen/mm: limit non-scrubbed allocations to a specific order docs/misc/xen-command-line.pandoc | 13 ++++ xen/common/domain.c | 28 +++++++++ xen/common/memory.c | 100 ++++++++++++++++++++++++++++-- xen/common/page_alloc.c | 30 +++++++-- xen/include/xen/mm.h | 14 +++++ xen/include/xen/sched.h | 5 ++ 6 files changed, 181 insertions(+), 9 deletions(-) -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 17:40:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 17:40:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211703.1523206 (Exim 4.92) (envelope-from ) id 1viyf7-0008NW-W1; Thu, 22 Jan 2026 17:40:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211703.1523206; Thu, 22 Jan 2026 17:40:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viyf7-0008Mq-SN; Thu, 22 Jan 2026 17:40:05 +0000 Received: by outflank-mailman (input) for mailman id 1211703; Thu, 22 Jan 2026 17: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 1viyf6-0007E8-KJ for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 17:40:04 +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 617fd2c6-f7b9-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 18:40:02 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by PH0PR03MB6512.namprd03.prod.outlook.com (2603:10b6:510:be::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Thu, 22 Jan 2026 17:39:59 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 17:39: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: 617fd2c6-f7b9-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HeWFhc52meRoRg1D2aLqUKqFwBeaEZXwnnwSy6Qvf4KrMuG6p51HP/svT/t7Z8M60+06A6fYrsVoCJ21elhu3ZFsh3MHbY5fKvIIxkgIanOsf9YU0fA2reDaUKW4/sa02QQ5DViMoN/8kh71HcvGEKiEYhhgxEJzwkx3fiDhzrw7uotbAcMh1KtC/JiGsYhbcce6Yf9ezbLg8uL6ZAMLx5Clb3Fig76szhj+Vap3XOfCY3wTwSDpTM5NvFvLBphTdqKMMiW51JkldLxGJ0KlMnYDp7ETfSRZX1dgyGpZ3MKJva5XZpHyVZHLJna5BYwsPMfUSw5+T00Ovb/N76/8RA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KhAxvSGLCPIxM89fs0EWPD/KIqiQa92YQBwQ5kHiAk8=; b=M3xsnY+9tZMWMxHcs7tbKfPP3TUgpcmaEfIaJhda8gInXVDIXywM5rArTLAiSLkb2VrmbEN7BDFeusEtAORlhxbz8ry4vcHaFP9KlJPQKjEXFgkl+VetDQJF/YJ165i32kvhWKgU0+jyvKmjHDfURFhLAeUkPzwvf7E5fiFVjWQ6JHHTYSUtxd63XAQozIpfGRk3lJXwW9iLgpzmPr2X6pxrjfUpHmCJ6KTBJAiwDZwVIntExZXYy1QSTSuHJsyyG2HlL1EqypTOm7yvPefWkhNYLrS0Dtf90EczQdYNRQzi/8XfwH1p1j2QuPzBAmiJOOZps1pDLSJLGt3n46lfSA== 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=KhAxvSGLCPIxM89fs0EWPD/KIqiQa92YQBwQ5kHiAk8=; b=H9oNFhcldJXRkZc6cmV8DDthiAnKSjd/r3wmwh/QUF+qicqrSa8q7Gqmif7pQDuMnapzzqfShubyiDBpxshookcbYTbV7MQJLtFrwW2P0m8cDddFvFkg2Ko+AtBKBhrVbNiBy4jaYM2Wnd+w7cqzGVnKW8kdcTMPGN3XG1d5cvA= 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 , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v3 2/3] xen/mm: allow deferred scrub of physmap populate allocated pages Date: Thu, 22 Jan 2026 18:38:56 +0100 Message-ID: <20260122173857.83860-3-roger.pau@citrix.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260122173857.83860-1-roger.pau@citrix.com> References: <20260122173857.83860-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MA4P292CA0006.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:2d::16) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|PH0PR03MB6512:EE_ X-MS-Office365-Filtering-Correlation-Id: 7217666c-9021-41ac-255a-08de59dd4377 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?UzJKZ0FySjQxMG5hVjhRd0JkMVpBNTRjbmRObWs4d1RaL3FKU1BVem9pY3E0?= =?utf-8?B?MzA4RmNtVnczM0xMUkFwWXJzWThZbS92cFQxMVRVVTl6cWdiaXUya0V1S0FC?= =?utf-8?B?OVQ5NDV3SW90c2RPUlJ0NWp3aWorZDBqeXZSSSs5UU83bXF6MWE1SWpNL1gz?= =?utf-8?B?UkFsQU1SZXVCNENUcTB4QWFoZVBjVDFVZGwxY1A5cGdrOUROYlJZckFWN0xh?= =?utf-8?B?czlzbEVqS0J6MDNuTjdIMDBsSWw3ZlpwQ1A2cmw1b05LcmtMbTcxWVRZMjNs?= =?utf-8?B?Tm5zeXFoM2tEd3RaeFVrMDRNVVR3SVJpaFBINExJNVllTW9vR0s2dzI1cXJu?= =?utf-8?B?UjhIaGhOOGp0ZG02amEzQ2pVeUtyWnZGcEpZMjRTQ0FNK3BlWllnYStnS0w0?= =?utf-8?B?K3l6d2IyY1RqMlMyTTlQSUtVVnNMaUpsQVNvU3U0UW9Qbko0WjJ5d09reUZG?= =?utf-8?B?S1ZqS2YrMWtDazd6WDRMdUU5L1hIT2tMLzBSZHRSM0pTSkg3WFVWeUJ5WVQw?= =?utf-8?B?TUl2SnJ5ajhHdVdWbGVQWjBwWTJlcWc1SHJNZU4zZE54amdTcEFjSHpScGJk?= =?utf-8?B?QW5xSW5ZRmdlNkNYZWxuYkV6dFR6amszcVZpb0ZJOEp5ajlkNzNGTkxTMmVl?= =?utf-8?B?clJ4NG9seUg1SVUyRzQzcEpnU1U3aUFaSmVTdlltT212a3pUdjd0dEk1em5h?= =?utf-8?B?KzlIZFJaK1dhUjV2cUtmS2dqSUtXeTVTVDdGRzJDMVlCaTBwdENaZ1VpN2Jl?= =?utf-8?B?QzFldVRrUnd5aUFYNmFTWFBrR01SenJmby9jUzFyMjVtZFZwQitZMHJYeTY3?= =?utf-8?B?WkxYeDhaWm1lTjJZUFBvTDBJUHFLOEFmalNWVExPUkJ6MXRCUm91Q3V0YWM1?= =?utf-8?B?djV1NjJhZ0hBbUdSbmJDbzY2YlFIbDY3anV3am1kNWE5cjYrYkd1T2hjdWw4?= =?utf-8?B?S0VaSjdLSTI1MHl0c3lyRFRQWUo0NHUxV0ZWOGpUOXovK1hhUEFQVVdrdUFB?= =?utf-8?B?eEMvcjAvREt1YUY0S3RhU3FOV3lDcUI5c002Q2NoaE15OUc3b3Nxc3NxRWJv?= =?utf-8?B?Y0EzWDRBa1lsM25VSFJXcXJmTFRXSVFsbklaVWVOekhnT2JXNFpOMGYyY3NI?= =?utf-8?B?UW5QK0dZUW1aa2VNNmhsTlBNN1I4TS91SmlFY1NrNy9mL21TdXJ5azk5STI4?= =?utf-8?B?QjBGcEFmVTBKM1J6Ym1jZFg2UHBQajVsU3JFQTZaU1lkVnlGbXNiSkZoak9s?= =?utf-8?B?dVRYenNRa2l3WkdFVWtkcVNEU1NvdlpqL0lBVHM3L2R4RUNnaDdKVUNQNURW?= =?utf-8?B?a1lPM3VoL2M2d21LaUJPa3B5NlJlbjJsb1JUUDhtZWpMUlZHMXJYeGNtYmQw?= =?utf-8?B?OXQ5V2p6Y1RKdXJ6Z2RUdTBoYS9aY3pHdWU3dU5kbkhhS3d4MDVvMjdnZyti?= =?utf-8?B?NENSaVFaT2lJeVFMdUFqRGNLeWdmWXI1ZjYwY0dxOENUZjNrekJJMHJwMlF6?= =?utf-8?B?UTBNNXpuMlF6VUcvV2xpMlZyem92aUFkVWI1VzJkNjNnTThiSFA4dG4wM1Uv?= =?utf-8?B?aVpta01BeDY4MHNUUUFnTkNSOU82UWliMVNvcE5kSTB1Lzd3V01YN2p4bktW?= =?utf-8?B?SVMwa3dwSVJtUm8yWW0wVE95dTNpOEVNekZlcVA2QlJBLytYNUJmMllOc3Jk?= =?utf-8?B?dTRnaXV3UEVLeloxelhhYi9rekdOdEt1N2xneG9YSllLczllamhDUEJtRlVK?= =?utf-8?B?Q3VFMlVRM3VsakFPOWY0bmd0aWttVlh3ZERMcTliYlA1NWpvQlk1dWh3Y1gv?= =?utf-8?B?M2x3dnM2ZWNHOFZLRnhOQ3BoUnJndCtaWExtMDFpRzdRMzFaY01oWWQyZmNv?= =?utf-8?B?V3NzS0V1cUEvYjM0RGlwV2RjUlRRRkRPVWs5MFlzMTVCdlBmODNKTll6d1Zw?= =?utf-8?B?ajB3a1lZa2JhZXFNcU9sNlNHQzVSVm1CVVRJV3BtWFp6aE9xVXF3WklpdWll?= =?utf-8?B?ck90Ri9HNE55RzV5MWM3WEFQQ1BjNnFacHhQR2JQNXdHTUVoQmJIYVAra01P?= =?utf-8?B?eXpFQy9uUzRlR3I5WnZmMmRTeXNaeEZqdS9WSThjdXVZbEY1bFNFcjljVmw2?= =?utf-8?Q?5GXc=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TlkrSElGUzBDMlBMZnJrb3VvcEpFcDZ0R0tDbHdrbFVleXFvNHdIV0V0UUZQ?= =?utf-8?B?Z1AwbXcxanZtTnM5QVFmVDJwS201c3BUSHo5aE5yN3Zud1FNeG1JbVdTbmhW?= =?utf-8?B?Vlp4Tmg4M3E4dnh0WUVBanI5Z0hDZFh4WjNkVTc4SUtZS0FpMU5sdHJnY1Zl?= =?utf-8?B?RUdjYWlVRFlPVTNHYlk2aXYxekFBQVIvaGkwVDhPeERFU0h4UVFvZG42b3VO?= =?utf-8?B?YTY4SU14eHN3ZkFRS0hHNmVhVUlCdVh6RkVHdUQ4dHB1QWo2bVAxMVptazFT?= =?utf-8?B?elVOcVNJUWZaRFc5SWRnb0xIU00vUVpZbVdQR01xdU1XcURJYWVJc20rK2dI?= =?utf-8?B?bDJ0RDVVVHpWQk11OEFhdGNXekp0QUo1OEtDTzFOMGJuWFdZeDduQld4cGdw?= =?utf-8?B?bzUyNlpBSWZlcFY0VzFIRlRiRlpqNjF1NVpVNEhzd1hBSXVkU1BBUkRVWHVn?= =?utf-8?B?ZktjZHRoUG8rU0VXSUN5QjJleFRkd241QWQ1Vm4rc0FoSWlJbXFZT0tZMjhM?= =?utf-8?B?YVM5TUFodDFORDN2WFJQeGtxVDBkbnZsbWZyOHVzOTlMWUh1cFNrOG9YazRI?= =?utf-8?B?L0JVc29sY1pTMzZsWFNHeWNZMGhXMG1JN0lmY3BGOVlwdDZHNTdWK3h0L2ZI?= =?utf-8?B?L3FqT3I4OUxKeWJoVzRXdFVLQzFmc040L3ppUjZ3Znp0Mi90R1FHUXNNUEo4?= =?utf-8?B?cHVsUDVTbEJ3d3I2eE4vQlhYWkdFMnlRMFRHMVpiRFJaK05mZHJSbzd3bGsy?= =?utf-8?B?RDNlelkxa2VHbHJwWHJJM1FPdzUra3hhT01IOFZtVWdxZWc4NUExU2ZTdHY1?= =?utf-8?B?bGJkYzRyeWlCQW9ZMmIySWR1TjlLd3VLSXZQNFhQd25jSmxyc1Rsd0FlNUJm?= =?utf-8?B?MFFyYndDMGhkMUZTZ202Yzl3MUhjSnhNdGQwNVZOSkFPZU1hLzlneDlVYUhT?= =?utf-8?B?UnhJYjFxMVF3b1dzWWc1SUIrZHRyd3NuZGhEVW5tQTFma1NXS1oyNnhMQk9n?= =?utf-8?B?L3NQUkhHZGFBM0NWUXJIZmFzcHIzTU93OU5UZm9RS1NRb0RaSlVoaXI4eUZr?= =?utf-8?B?aXVucXEwKzBvTUpCUTJZZXRORGU0RjlBb0VlcHVIbFo5Z3hzTVJrOUpRSm9G?= =?utf-8?B?d0dGaElscGIrbGoyajdjL2VwV2g4Y0ZqWHZaSTcyS2NzZmZEdnVZVk1GODBU?= =?utf-8?B?akUyUVR4ZE1IRnh6d2JveGdadWtYQUViN1JOcTZZL21tNE9sWXkzeWc3bFJC?= =?utf-8?B?bDl6QW1FNGNYZEtSeGIyMTFYZThBVWN1U3VTdi96SVBEaytCTHJ6Tmd1ZlJR?= =?utf-8?B?QUg3UEdaR09Wd3ZRYzMvUFpTbHJNblFJa084aGdXdkFCWFlLR2x4NjJwcW1K?= =?utf-8?B?MkVVVHg4Umdqc2g5cFV4aFhpQzNsZFdLZ3FhMVdmWlNDYmRHQmM4dFV6NnFu?= =?utf-8?B?dTdxTjJZeS95NGlBRzEwNTFBZmhCYUYwMndXbzZNTjZwMjhTazNoSVFGZ1hJ?= =?utf-8?B?U0JqV0VTQ0R0UFg3WDZsUmh5a3ZpK2hKMDcvL1VPVGVOckk0MHhyZHVFclBy?= =?utf-8?B?QXdaL1J0M2Z0Rm9aRmhHK0pRTmVCemY1RXlSYzVHTUtUZm1GenRNR0RkWDdt?= =?utf-8?B?OVF4RVNKdW84eEo2bk1PdGpGcHZjRkNnVExIaHVaWmtTQnE5aVduU3RhaDZk?= =?utf-8?B?VFI3T1E2emF3T0M3ZWJuV09YMEdYeXB3S1ZLNm14UzJTd1FYdXNhdzlVaDZV?= =?utf-8?B?LzBHVTRJNE5FY1hMWXkrL3YwUnR3NTdiRU1kdVREWkgydXpvQ2dYbGoxNUU4?= =?utf-8?B?NW0ycHJnYnlia3Q2QVRVZnpDcmQyMnBLTzB3WXRlK3FmcWFFTnpFSDZLdXNw?= =?utf-8?B?bzJyTHhkOGVMdHVlNFFxVnM5ZGRHT204ajRpclErczljNDd1U3NCQkZRbktV?= =?utf-8?B?SXVUU2k2VFIvOFJzQys0K2RNUDc5VDBnMU14T0hrbmVhNVF0NmFsTzFLMFZN?= =?utf-8?B?R1NpTE0zOFNrQnNxcUNRazQ0aFExM0dJenJiYlo0UGhSMDlsY1NHcTc4U1Vp?= =?utf-8?B?VmlWejNudGZmSk5XSDkvTFQyejBEVXNWVkhNT1dobDlGWmJKTXN6YW5JYWk2?= =?utf-8?B?MURWeTQ0S3RzVG81Rjl4ejdmMzdtS1pZZFZZajAyRkV4ZVpMRlNXZEQrRm5q?= =?utf-8?B?dGE2NUxQNlRUSUFqaWZBS1RmQVF5MjVkZmdHZW5MZ05zVTNNWXRweHdvbW9a?= =?utf-8?B?M1R1K1diL3IreExRT2pYSGUvUnlDRHM3VzlBRUoxL1pQMTI2cWhqQmYycHhB?= =?utf-8?B?aGtEVStTZmdZQWFSbDZOU1hLZWF5R0lWamE3MURwMUo0bWF4OE9zUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7217666c-9021-41ac-255a-08de59dd4377 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 17:39:58.9850 (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: pCrb7GgsG+1l3M3g+4jMEHgwGobH21h7H4rJY5/LNpprwj40d504pIEp0YGoj6Vp+uKD+e0sEsShvas9tYl/vA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB6512 Physmap population has the need to use pages as big as possible to reduce p2m shattering. However that triggers issues when big enough pages are not yet scrubbed, and so scrubbing must be done at allocation time. On some scenarios with added contention the watchdog can trigger: Watchdog timer detects that CPU55 is stuck! ----[ Xen-4.17.5-21 x86_64 debug=n Not tainted ]---- CPU: 55 RIP: e008:[] clear_page_sse2+0x1a/0x30 RFLAGS: 0000000000000202 CONTEXT: hypervisor (d0v12) [...] Xen call trace: [] R clear_page_sse2+0x1a/0x30 [] S clear_domain_page+0x11/0x20 [] S common/page_alloc.c#alloc_heap_pages+0x400/0x5a0 [] S alloc_domheap_pages+0x67/0x180 [] S common/memory.c#populate_physmap+0x22f/0x3b0 [] S do_memory_op+0x728/0x1970 Introduce a mechanism to preempt page scrubbing in populate_physmap(). It relies on stashing the dirty page in the domain struct temporarily to preempt to guest context, so the scrubbing can resume when the domain re-enters the hypercall. The added deferral mechanism will only be used for domain construction, and is designed to be used with a single threaded domain builder. If the toolstack makes concurrent calls to XENMEM_populate_physmap for the same target domain it will trash stashed pages, resulting in slow domain physmap population. Note a similar issue is present in increase reservation. However that hypercall is likely to only be used once the domain is already running and the known implementations use 4K pages. It will be deal with in a separate patch using a different approach, that will also take care of the allocation in populate_physmap() once the domain is running. Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed") Signed-off-by: Roger Pau Monné --- Changes since v2: - Introduce FREE_DOMHEAP_PAGE{,S}(). - Remove j local counter. - Free page pending scrub in domain_kill() also. - Remove BUG_ON(). - Reorder get_stashed_allocation() flow. - s/dirty/unscrubbed/ in a printk message. Changes since v1: - New in this version, different approach than v1. --- xen/common/domain.c | 28 ++++++++++++ xen/common/memory.c | 97 ++++++++++++++++++++++++++++++++++++++++- xen/common/page_alloc.c | 2 +- xen/include/xen/mm.h | 10 +++++ xen/include/xen/sched.h | 5 +++ 5 files changed, 140 insertions(+), 2 deletions(-) diff --git a/xen/common/domain.c b/xen/common/domain.c index 376351b528c9..bc739571fdd5 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -722,6 +722,13 @@ static void _domain_destroy(struct domain *d) XVFREE(d->console); + if ( d->pending_scrub ) + { + FREE_DOMHEAP_PAGES(d->pending_scrub, d->pending_scrub_order); + d->pending_scrub_order = 0; + d->pending_scrub_index = 0; + } + argo_destroy(d); rangeset_domain_destroy(d); @@ -1286,6 +1293,19 @@ int domain_kill(struct domain *d) rspin_barrier(&d->domain_lock); argo_destroy(d); vnuma_destroy(d->vnuma); + /* + * Attempt to free any pages pending scrub early. Toolstack can still + * trigger populate_physmap() operations at this point, and hence a + * final cleanup must be done in _domain_destroy(). + */ + rspin_lock(&d->page_alloc_lock); + if ( d->pending_scrub ) + { + FREE_DOMHEAP_PAGES(d->pending_scrub, d->pending_scrub_order); + d->pending_scrub_order = 0; + d->pending_scrub_index = 0; + } + rspin_unlock(&d->page_alloc_lock); domain_set_outstanding_pages(d, 0); /* fallthrough */ case DOMDYING_dying: @@ -1678,6 +1698,14 @@ int domain_unpause_by_systemcontroller(struct domain *d) */ if ( new == 0 && !d->creation_finished ) { + if ( d->pending_scrub ) + { + printk(XENLOG_ERR + "%pd: cannot be started with pending unscrubbed pages, destroying\n", + d); + domain_crash(d); + return -EBUSY; + } d->creation_finished = true; arch_domain_creation_finished(d); } diff --git a/xen/common/memory.c b/xen/common/memory.c index 10becf7c1f4c..db20da1bcaaa 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -159,6 +159,66 @@ static void increase_reservation(struct memop_args *a) a->nr_done = i; } +/* + * Temporary storage for a domain assigned page that's not been fully scrubbed. + * Stored pages must be domheap ones. + * + * The stashed page can be freed at any time by Xen, the caller must pass the + * order and NUMA node requirement to the fetch function to ensure the + * currently stashed page matches it's requirements. + */ +static void stash_allocation(struct domain *d, struct page_info *page, + unsigned int order, unsigned int scrub_index) +{ + rspin_lock(&d->page_alloc_lock); + + /* + * Drop any stashed allocation to accommodated the current one. This + * interface is designed to be used for single-threaded domain creation. + */ + if ( d->pending_scrub ) + free_domheap_pages(d->pending_scrub, d->pending_scrub_order); + + d->pending_scrub_index = scrub_index; + d->pending_scrub_order = order; + d->pending_scrub = page; + + rspin_unlock(&d->page_alloc_lock); +} + +static struct page_info *get_stashed_allocation(struct domain *d, + unsigned int order, + nodeid_t node, + unsigned int *scrub_index) +{ + struct page_info *page = NULL; + + rspin_lock(&d->page_alloc_lock); + + /* + * If there's a pending page to scrub check if it satisfies the current + * request. If it doesn't keep it stashed and return NULL. + */ + if ( d->pending_scrub && d->pending_scrub_order == order && + (node == NUMA_NO_NODE || node == page_to_nid(d->pending_scrub)) ) + { + page = d->pending_scrub; + *scrub_index = d->pending_scrub_index; + + /* + * The caller now owns the page, clear stashed information. Prevent + * concurrent usages of get_stashed_allocation() from returning the same + * page to different contexts. + */ + d->pending_scrub_index = 0; + d->pending_scrub_order = 0; + d->pending_scrub = NULL; + } + + rspin_unlock(&d->page_alloc_lock); + return page; +} + static void populate_physmap(struct memop_args *a) { struct page_info *page; @@ -275,7 +335,18 @@ static void populate_physmap(struct memop_args *a) } else { - page = alloc_domheap_pages(d, a->extent_order, a->memflags); + unsigned int scrub_start = 0; + nodeid_t node = + (a->memflags & MEMF_exact_node) ? MEMF_get_node(a->memflags) + : NUMA_NO_NODE; + + page = get_stashed_allocation(d, a->extent_order, node, + &scrub_start); + + if ( !page ) + page = alloc_domheap_pages(d, a->extent_order, + a->memflags | (d->creation_finished ? 0 + : MEMF_no_scrub)); if ( unlikely(!page) ) { @@ -286,6 +357,30 @@ static void populate_physmap(struct memop_args *a) goto out; } + if ( !d->creation_finished ) + { + unsigned int dirty_cnt = 0; + + /* Check if there's anything to scrub. */ + for ( j = scrub_start; j < (1U << a->extent_order); j++ ) + { + if ( !test_and_clear_bit(_PGC_need_scrub, + &page[j].count_info) ) + continue; + + scrub_one_page(&page[j], true); + + if ( (j + 1) != (1U << a->extent_order) && + !(++dirty_cnt & 0xff) && + hypercall_preempt_check() ) + { + a->preempted = 1; + stash_allocation(d, page, a->extent_order, ++j); + goto out; + } + } + } + if ( unlikely(a->memflags & MEMF_no_tlbflush) ) { for ( j = 0; j < (1U << a->extent_order); j++ ) diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index de1480316f05..c9e82fd7ab62 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -792,7 +792,7 @@ static void page_list_add_scrub(struct page_info *pg, unsigned int node, # define scrub_page_cold clear_page_cold #endif -static void scrub_one_page(const struct page_info *pg, bool cold) +void scrub_one_page(const struct page_info *pg, bool cold) { void *ptr; diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index 426362adb2f4..d80bfba6d393 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -145,6 +145,16 @@ unsigned long avail_node_heap_pages(unsigned int nodeid); #define alloc_domheap_page(d,f) (alloc_domheap_pages(d,0,f)) #define free_domheap_page(p) (free_domheap_pages(p,0)) +/* Free an allocation, and zero the pointer to it. */ +#define FREE_DOMHEAP_PAGES(p, o) do { \ + void *_ptr_ = (p); \ + (p) = NULL; \ + free_domheap_pages(_ptr_, o); \ +} while ( false ) +#define FREE_DOMHEAP_PAGE(p) FREE_DOMHEAP_PAGES(p, 0) + +void scrub_one_page(const struct page_info *pg, bool cold); + int online_page(mfn_t mfn, uint32_t *status); int offline_page(mfn_t mfn, int broken, uint32_t *status); int query_page_offline(mfn_t mfn, uint32_t *status); diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index 91d6a49daf16..735d5b76b411 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -661,6 +661,11 @@ struct domain /* Pointer to console settings; NULL for system domains. */ struct domain_console *console; + + /* Pointer to allocated domheap page that possibly needs scrubbing. */ + struct page_info *pending_scrub; + unsigned int pending_scrub_order; + unsigned int pending_scrub_index; } __aligned(PAGE_SIZE); static inline struct page_list_head *page_to_list( -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 17:40:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 17:40:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211702.1523196 (Exim 4.92) (envelope-from ) id 1viyf5-0007k0-Ng; Thu, 22 Jan 2026 17:40:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211702.1523196; Thu, 22 Jan 2026 17:40:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viyf5-0007jS-KX; Thu, 22 Jan 2026 17:40:03 +0000 Received: by outflank-mailman (input) for mailman id 1211702; Thu, 22 Jan 2026 17: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 1viyf4-0007E8-FC for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 17:40:02 +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 605d0bc0-f7b9-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 18:40:00 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by PH0PR03MB6512.namprd03.prod.outlook.com (2603:10b6:510:be::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Thu, 22 Jan 2026 17:39:55 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 17:39: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: 605d0bc0-f7b9-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=swhnMtp4mBd9MOYp/a39kPIOyNHhMCriNcKmjQdn1AEBOpuMqccq4/AQcdjG+m49tzcYUxdQ7ANuK+EcROEZhDsS/Xd/ZT+aikZ8/tqPiR/5S3YRZjDUtdCytIAt4/xKBNpsvweA5yoc4DdeJC7NPJ1424vZGxylLPZedAEb4FOXHJAb0lIGBvsB6K3Rdh6oO5Plcx2IaiDEwVJxYEgsxpnN6L7//vLOx82ONGjJOpb6Q8nZfztA07Ni4tmMlIxKg8bVhWJB5mpfqeOe2OKSDHKU1Vga36mVOiCKLbx1quMDHNXo4dJjFv5DVIfJARdd54KkNsE9jxyR+i0NZH5TRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DGFKVF0i2wWigbiwR7BNTdhzq53D/kNouGUmcPEvNic=; b=Upsp+ljRvQ+oAjL9NUGwha5e+cpVcgrqL4bocXjwjNoRJQa5HKXU+BL4jacOMT6dPeflLZ7zP7Sm3pJbrtekAQ0kzEEKZdR1qUDp3B4KOAWy7ZOJ3csMQh/jNciD14ZNW5NK7RDCPCL3XZQk8jRT9tB+QIb0WvGeBEjtqUeIM3IAN2Fc6XzfSko9/JjLQGJUVh6NDwAylz5h6/c0ekWJDktsHls740DGSGF6lK5W1NJhtIJKhlaKKhTLPdeEJvBX3FFtsjLyyN6IW3AOc0iGEdxE6sj30zTRnMTMG+dwEzki8M+iSHLdgYb6uGnokeAbGtzwj93p1cL6LGfQDCdaHg== 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=DGFKVF0i2wWigbiwR7BNTdhzq53D/kNouGUmcPEvNic=; b=NrAN2psc+kT5sVu+01xBLxbiraciIe5OffCTCWgL9aKzpHbsGdSWd9eABcyqWWrMXM40kV1VchrvGbhvJGa2RSZonRlEcw+EbDXO9hXYDl3KiEiCg5qrBLShlLfU2ZGWZGEo216o6EZZgjjxYEpQeNyPoYvs3DkpGr5U2FnWa08= 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 , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v3 1/3] xen/mm: enforce SCRUB_DEBUG checks for MEMF_no_scrub allocations Date: Thu, 22 Jan 2026 18:38:55 +0100 Message-ID: <20260122173857.83860-2-roger.pau@citrix.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260122173857.83860-1-roger.pau@citrix.com> References: <20260122173857.83860-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MA3P292CA0068.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:49::6) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|PH0PR03MB6512:EE_ X-MS-Office365-Filtering-Correlation-Id: 45b369b9-4ddd-47cd-dd81-08de59dd4180 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?OVBBaFphS1VJVGNDN1Q5VnBMOERiaHZVMUQ0aytJSHNwRDRPeStQTnBYZ0tm?= =?utf-8?B?eGpra0I4S2RXZXRLTmlrak1oSEdjVkVDN2lxUTkrSnRkWkpIK0ZOMWRMR3dT?= =?utf-8?B?QlcraGxhZ1hESlpsTGhZeWljTC9ReDNVRlRXT05zNGtJUzNpWVhvTHhTWVMv?= =?utf-8?B?ektodGQ1N0tlbEVBTFRaUGFVUllpTDBFNnErNGhOTnMxekEzcEZqSTNhZUFC?= =?utf-8?B?Q1Z3RUF0ckNCZTQvOXp0R3Q0dWI4RmNUQXdCcDFHT1JmcWhDdjZEaG1kUm5o?= =?utf-8?B?Q2VYTnVXMUIwS3ZuVVN2ck5Sa2tBaXBxZXpJb2lBSERkUTlKR1llL2VxR01o?= =?utf-8?B?SzZOdFF5N1dHejNrWllSRERZUExTM1E1dHJQblo3SEpYTzR0dW45ckRiOXVt?= =?utf-8?B?b1BkWDhDMmMrL1FFa3RBM1c4UU54eFEzL2hCbnhZYkM5cGJnREUybk5VYm1G?= =?utf-8?B?UmJkNk0rT0lFZ3l0enBaUnNrUGlMUkg0SSs4UHU5YjJmdjZ6SFhtQ3lBQnRK?= =?utf-8?B?dFd0WG1tWW04aFVvSEtTNW93SXBBWjFvNFNKWTByMndHZjdzdUkraDU5ejk1?= =?utf-8?B?ZWRKSmZyTHdKNHZ0Mnp2NExYYWFxbzYzUnVhMVFhSG92OW0zTllLZU9IcTkw?= =?utf-8?B?Q3JVZWlrQU9TeHMrRkJtYnZEY0d4SEpqTXRDNkNzU1o2MHdYRUJBdE5BemlU?= =?utf-8?B?NFkxWnVPcFoxUEErT0RmV1FRQkVEUnZ5MTlWeWw2aVkyNXRvMzdkaTVxMGVJ?= =?utf-8?B?ZXpQM2UxTm4zQWxOUnd2QUxhU3dFbDZnQkxhcnhRMGNoWU1LRGk3RjU1azdm?= =?utf-8?B?OEsvT3J2YmUxbU95bmxWWEQzeXFUbitwTzFpa2lQVzV5UUpxSVpoR1BCQ2Z4?= =?utf-8?B?T3BDSUpMV0h4ZGh6OGEyRVY0Q2NVemFZQStLY2ZIS1Y3aWRmYzZCWU13am5s?= =?utf-8?B?TEJrZjhsSzluOGs4d2EvMzNLUGd4Ykg0bC9YeHR4dEUwZUdtcjBRc3NPUHNZ?= =?utf-8?B?bVdVWEVnWTlkM3dJZ2VvaTUwK1NzYVVZc2ZlRDRyNVd4akN3dTB6RXh5RFl1?= =?utf-8?B?bmlwWGJEVngzNDNEWGpyZ0JqYklHU0owT21JR2tVVVZ1NEFPNEF0S2xaL3lQ?= =?utf-8?B?ZmNxSHZOYUZJL0U3NWZqam4vR01jUVB5V2dZOUZRL1c1UStMcFczQ0w1cWhj?= =?utf-8?B?T3BnYUIzNmJIZ0N2L0NGd0R2azlVb0RWNWlmdWtNb3lVbzhoTk52c3R2Z0Vm?= =?utf-8?B?UnVhaUdpblRNZlNLRG1rYmQybms4WS94S3lqalY5MHV0QVgrR3lpczdObGQ3?= =?utf-8?B?NnowemZ3SzVCTzZ4Vm8rUkp2M3ZhVGhrNzR6dk1YQlQzUE4zb3hUdGFyZ0sz?= =?utf-8?B?U01WanMyM09uc2V0bjlPeEgrRTdETDBjVXM0c1ZEMmpEUXQzdWNVcjdUazhr?= =?utf-8?B?MWNna3VEdFlaTWdJZWs1UmNYZ0ltbGNUK2l5OHNyVkpvT3BQaExiVnAyY0p0?= =?utf-8?B?NkdLeTJ0N2lKK0g1N0paa1lYbkhpSmEwVkQ5L1JyQll4Ny8xR3lMZW96WEtr?= =?utf-8?B?MDlOcFdNWnJRNEhRSkN4WHc5d2tndXh5bWEzNW5Cc3BGVW5GZVlNWElHU3Vh?= =?utf-8?B?aUQybzlPaFoxbEdES1ZkWjd6UDB5Z1NDa1V0OEJXYjN2QjZoSGlzQThxVzdY?= =?utf-8?B?aytwZ1FFbzcrZUwwQTNkSk9mTVFYcjA1OXphbmRrbWRHdmVTdTYxYTlHT3Fk?= =?utf-8?B?aDI3ZlFIb2V6amN5L0VFQ3ZsOHpVb3I0c0dsOENWeVltQmE4ODZwUUdEM21Y?= =?utf-8?B?anRGTi9VRjh3NGM2bGdQMVpnZVN2NUtoSHdWdW5waUtCUFpDL0RUcmVoR08z?= =?utf-8?B?SmJWcGNGV2JMZ2gxSHVoS1NBeGNDMnUrMW1TaDhDS1pTNGpSaVZVc2F5ZFA1?= =?utf-8?B?ZnorRkZxd1NxZXFmT0N1VndZaHl2QzhXM0pXNnczVXFyNlhSeFY5Tm9EV3Zm?= =?utf-8?B?cHc4K3RZY2VMN2RGcEFUQlZ1bjJyRExIdzhhN2lrR2MxZkpyQU56WnVHZG8z?= =?utf-8?B?QnhtaER0Z1RWVlF6Q1VVUDVZek02aW9uQ1I4Mm1tcTV1WnZkanR6dDBtQjZh?= =?utf-8?Q?T63E=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NTlSbXVpbUZka0cwWE1aVzhUdXhpbHhxQzVZZHF0SkFCOEhhV2FhNVR3Ni9E?= =?utf-8?B?aFFJenJDdnAwZlAzY3AxNUxENXovbTE4NVhlZEd6T2FuZE5QWjdtK0piUmll?= =?utf-8?B?UXFCaExHVy9uUVMyUWpiWnYxRGovODFnQkMvaCt3K2RRaWMwSGdGNnhTRndV?= =?utf-8?B?QkM1aWZLYnEzOGlwa2ZWZkVobHorNFZHSzNtdWExcVg2Y1o1aVBQU20zemJN?= =?utf-8?B?WlNOTzBmMGpObndwdkpmV1R6dmxGOElpYWd1ckNNT3Jod0FzZE1QOWFkVkR3?= =?utf-8?B?bWFnK1VGMUEvVVh0U0lzZVRQUnhwQ2xjUjhmdmo3cG1uemxvVlZxTWdJcTgy?= =?utf-8?B?QldFc3hudmk0NFZFY3A3U3RhVXYvVU1mL3VNT2ZlcXZyNURYb1dzbHFwVmlj?= =?utf-8?B?bnFWb2FVUUg1TWVTT2lXN1hQOEFEeGRZME4wUnpZSWpCdnVFREdVcGVRa1ZT?= =?utf-8?B?MUZZMk1TOVBSeWJwYkxDQ3hjWUxMbEVYS0FENHpyZUtUeWdYNzEzait1eGgz?= =?utf-8?B?ZDd3YVA5U01SRVlacVpEUStPNGdaQmt1RTB0Z1ZVRWIrNmo4RVlGOVBiakda?= =?utf-8?B?czgrMjFiRTBVa0dHQzZHeEpGZVVZSkpuTis0cVlFVHUybExyUi9Mam50TUVv?= =?utf-8?B?VzEwNHRJRUFvbzlhdzI1K3hkYWRkMkRoR3lkM0lvNXNoUXRMdDBNSlR4Q2pU?= =?utf-8?B?bzVEbVVxeDZKZ3JIY0paUS80T3Y1Zlk4WHBCYmk0SkdFVEVQMUpOTlYyTkdP?= =?utf-8?B?RFlPQ1E3Q2VYWWVQZDA3ZUVIL1Z2Zm9tSmJGZzkybHRuMUZ1cUtGTUxBWi83?= =?utf-8?B?UG84RFI0Z0xoLzZueVNRZEZ4U0RTWHJkVXhOS2lDdzdDZ09RVDNaK3NYSTNj?= =?utf-8?B?THpIMkZZYzljUVlnbkh0NXI5bkFTamk0VUFLam9IZlZSLzdsaFE2VWdNdVNC?= =?utf-8?B?MjQ3cHRGN3V1OE02bjF6dXozbkJweVQrcThaS2ZydERMaU5TVzBnWFFmblM2?= =?utf-8?B?Y2xtRlJ2SENjcDlOdWJyUENIY0RJT1R5R3FlS1JpY01NYzhLUllLMTh2akpE?= =?utf-8?B?ODlKemhBRFV1bGVmQlFEK2pIU21sQlRBWEJKZzZua2N3WStiVThsT3RudlUv?= =?utf-8?B?dTh5bWF3UFdmVlVKWENaNXFldFhxL0FkTDArTXpuQVlEZVlVKzVzUkVSekFO?= =?utf-8?B?TUhsNnEwOEo5N3ZrQXNJZ0FqaDNiY2NKajNWOXZMMmtpb3l5eW02VHRoZ2Q1?= =?utf-8?B?QnhJS2kzQVBva2JrSmdDMkEzWGNJb3Rqb0pFZmxseWpoSlpHd2RNS0g3VmtX?= =?utf-8?B?eWFJaUt6dkpDOUFrY3JNZUk2aWtVcUM2OWJuUU1jNHNYeEJBS2c3RGYwbjEx?= =?utf-8?B?bUxHNTZUUk5EbTVkZ00zODZudGNIZ3MxbUpzcCtJK2xMSElBMjFVN015SnA2?= =?utf-8?B?QmJ4b3ZxQytiT1ZPL1EzOFNGOXc1dDB3WHI0RzVOcm9YeGo0NlQ1UkVBam9X?= =?utf-8?B?eFpINGIxS3VpMHBFUExBUktwbnF2NWIyNFlpVndyT3FlTVRXbmc4b2VOb2Ny?= =?utf-8?B?V3liTHNNRGMyaFJNWDJ4T1E4ZkhOM1luSGJpSWpCZ3oxNjlEaDU0N3hnR3Z2?= =?utf-8?B?SjJhYmx6MmsvZlNDK3ova0c3SEhCeG1PNmxCNFdVREhvTmVtK0xGSmNrSDlP?= =?utf-8?B?cWh4enNsc2J4Z2VNeC95UHdRM3c4M1B0U2pwY0pjTWFSVjB6OThJRE9DM2NN?= =?utf-8?B?Uk9SWkFQd0pZblJDNE5tUUM0MlhPM1FCODdsRVh5WHA1UWVMNmc0aDIvOWll?= =?utf-8?B?OFJFTlVDMkZiRC9ZZEQvM2FEQ0FEbmJ3SjN4cFJIUmpTd0hzbzM1K2VxU3Jk?= =?utf-8?B?WktkVlZyOGpXVzI5SUZwY09ETmpUemd2czVzWW1KVmJRRXdzSTEzTk82QmJL?= =?utf-8?B?M3F6YmxodXM0M2prMGpxZ0M2dEpPL0hOR2crcmthc3BjL1RGQ3ZBMFhBWmhS?= =?utf-8?B?WUhDL3cyVDY1R0o5a3lySUZlakIzaTNacTh0V1pTMzZhejBlcW4wRytWTnZR?= =?utf-8?B?ZUE2VU1mWjR6Q0IrVkVWNlR3eGJ0RWVISm9qRktGOTB1RW5LNlZreEY5VWFn?= =?utf-8?B?Yms2YUxKV1NPSHRGSHE1WldLa2d0MnVOc05HcTVtTytxOXBXZGdmdVdLSDl5?= =?utf-8?B?Z1RkcFByeTBrWVEweTJHWE9wckNhb2d1alJFR29ZVllUSWp5dlR6VHFzSjVO?= =?utf-8?B?T3lYMGtCYmJGVzNSWTlsSEV0TFUvYW9tK2RLeWNmUk0rMkxRV014VUhtak5Z?= =?utf-8?B?M0VJMXVWYTBFZ0Z4eGNpekFpY0ZNblc0TWpKNUtQdndBTzVwNGhudz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 45b369b9-4ddd-47cd-dd81-08de59dd4180 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 17:39:55.5796 (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: IcdtF5OxMusp9lE9Kl32pvbM/XO1PBXCwMUJQnl5SsOt0XUCyCoLARd/DPyIMluFQmrdka9lWDV6icBZQNcdmQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB6512 The logic in alloc_heap_pages() only checks for scrubbing pattern correctness when the caller doesn't pass MEMF_no_scrub in memflags. However already scrubbed pages can be checked for correctness, regardless of the caller having requested MEMF_no_scrub. Relax the checking around the check_one_page() call, to allow for calls with MEMF_no_scrub to also check the correctness of pages marked as already scrubbed when allocated. This widens the checking of scrubbing correctness, so it would also check the scrubbing correctness of MEMF_no_scrub allocations. Signed-off-by: Roger Pau Monné --- After discussing with Jan I've deliberately omitted the tag: Fixes: 0c5f2f9cefac ("mm: Make sure pages are scrubbed") The intended approach might have been to ensure the caller of alloc_heap_pages() gets properly scrubbed pages, rather than asserting the internal state of free pages is as expected. --- xen/common/page_alloc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 2efc11ce095f..de1480316f05 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -1105,8 +1105,7 @@ static struct page_info *alloc_heap_pages( spin_unlock(&heap_lock); - if ( first_dirty != INVALID_DIRTY_IDX || - (scrub_debug && !(memflags & MEMF_no_scrub)) ) + if ( first_dirty != INVALID_DIRTY_IDX || scrub_debug ) { bool cold = d && d != current->domain; @@ -1119,7 +1118,7 @@ static struct page_info *alloc_heap_pages( dirty_cnt++; } - else if ( !(memflags & MEMF_no_scrub) ) + else check_one_page(&pg[i]); } -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 17:40:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 17:40:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211704.1523216 (Exim 4.92) (envelope-from ) id 1viyf9-0000LZ-E1; Thu, 22 Jan 2026 17:40:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211704.1523216; Thu, 22 Jan 2026 17: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 1viyf9-0000Kz-AC; Thu, 22 Jan 2026 17:40:07 +0000 Received: by outflank-mailman (input) for mailman id 1211704; Thu, 22 Jan 2026 17: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 1viyf8-0007E8-Jk for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 17:40:06 +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 62c47435-f7b9-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 18:40:04 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by PH0PR03MB6512.namprd03.prod.outlook.com (2603:10b6:510:be::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Thu, 22 Jan 2026 17:40:02 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 17:40: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: 62c47435-f7b9-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FhUc9aODWoES/NYxNFwNaiOSnzs89VmP4Ga0gQAan0OUUEd4DE//Z/dfytgLUudAfgpiZ++1QQFDCTkZKRjFN17TupSQJdv6Ply2Muo6Nz1+TfkSFkHYGVSFrR3fvW72pAXrX626b4I/F5X69G0mnpYWXIW15QoFchrZAcrcGrFnmP6o3xpvxafqYHjFmey4FKUlLkxfOHTQzcD7e4W+s7bTD4ADfUSb72S3YD8ZwYc8SwxxnpspznFl3RkWpRXAi4oZf6COfMcHDUVNvtc3cu25/DWH6Cx76yPfY2eMQzii4GP19Euc3+SdioiniZnug5k0QIpiljMBj972sQSqjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WREtdnV6qFOwxoPQs5fE9uNviKczFifP5pic1h0CCY8=; b=KouDaf2P6YdManB28W7xvZCDweiEmfuG1EJ3E5XxbJ7L1X7GftzzlX+iLWitoaGsxuR40RSJSYS1Zs+XTjFl7KLL0Vg+ZLd0BnH6zHkyXqkWj1r2kW8JcvmfGDYRtEWiNu0bB3hiNB7l7VuIuBrdA7Afq/M4PlBlquJ7+9yl+/8vmNHv9ZLdgJTMWl3R18gI9kpcwd3IjOFnGO0xV+BNSKzPHavqU76QBFQHxN6eRN8Iap7ilg49YSh0OzwqH77jX6EDhMw2WWWl90V0QlVsbRi1ilf+m/5N8sLYu/v3sgVk1hCwjni4m4BIUPodZrrA/r7y+dQjctpAzUIdxDAw8Q== 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=WREtdnV6qFOwxoPQs5fE9uNviKczFifP5pic1h0CCY8=; b=voScXZiZeU0SnzyYJAEbDFyltNNZ828VFV1dCBQ9IWvjTEvXvvbeqF5K4hUfHwHTx9EggzQKHtpHI51UWvQS8MCdgexM1wbL8RMQ8QxAd+WZWEpX4MPCYm4IfV0lpajOFXHzOj16ii7+VYSdZosFAf2mCVc1+dwzVjDpziCpJgs= 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 , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v3 3/3] xen/mm: limit non-scrubbed allocations to a specific order Date: Thu, 22 Jan 2026 18:38:57 +0100 Message-ID: <20260122173857.83860-4-roger.pau@citrix.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260122173857.83860-1-roger.pau@citrix.com> References: <20260122173857.83860-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MA2P292CA0028.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250::15) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|PH0PR03MB6512:EE_ X-MS-Office365-Filtering-Correlation-Id: 6f8a5df9-8792-4bbd-0503-08de59dd4588 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?blB0S0RlVmJZWWljZWR0VWRCY09iT0dCVVIydElKTjk2V0RZTGp3THI1dE9J?= =?utf-8?B?TUw3Vy9BdUZ3TUZldG96OWlEWGVYQ0RoUVp1Z0pFa2FEMHFKTkd4dzV3d0gx?= =?utf-8?B?Y05BMlJQa25OM1l2TXF3QnV4djE4RzNzUGQ0OUNtUnB6dzdYdDVsVXc3YytO?= =?utf-8?B?VGVMdEJqVm1PUWl0aWw1VDRvQnQrU1M3cmhNTTdLZ1FJbDVLbXk1YWNtaUZm?= =?utf-8?B?ZmxycWh6MjV4aHYyM20wWDljSkphOWdpaVVuTVlGRlV3cGFIYUVEOXNSeEJs?= =?utf-8?B?Zit6bXhRaGhLYWpPczh6UXl1L0xkZHhJOVh6RjNOd1FET3BDOE9POGRiWk43?= =?utf-8?B?cGxqU2k3MlBDb0s0TUhLVU5pZUdEeGMwMWVraWYrY3VHOWVaelpxS0Frb3ht?= =?utf-8?B?TmhsVkdUVDY1WUJGT1EvMVFJT3lEMFRtOXAvSThPb3g3S0dsYTZJbGR5enA2?= =?utf-8?B?Q1FrUmdzQ3VodU9zUTJDTG5lNmhaL1lJbDVBVkQyUU1JbWIrVnZlc0gvSTNM?= =?utf-8?B?WWI0blgxN3lWY0pWYVNxNDRMdnNjNzFCK2QyTE5nYkc0NWtkKy9HZmJmeDNq?= =?utf-8?B?aVI1aFBGMXByRHFIakU5SEJqZTZpR2VjNlVuL2xMRmpyVitVSTFjSGpXbndt?= =?utf-8?B?Umhpdk9ReDFEejRzQjdSKy9KVUdkWkdzRlprTVF6ZXA2QThJVm10eEZ4T1Ez?= =?utf-8?B?WnlZblgyMDdOZStHR1V2bmtFeVVRV3pUWUhMbzhRU3RiTFRzUW11b28yUFBX?= =?utf-8?B?OXNYLzEvbS9TMzhQaWhxWHpjcmtxdjBzR01yelB5eVR2b3RQTmlKR3VkQk1L?= =?utf-8?B?YTZYSnZwblc1bHVJalBmU2FTb3plTEprK2VTVmpBZlJrY2JQVW9mSCtreDZI?= =?utf-8?B?SHFNRERvNjBVZkZwT0xxR0pKQ0ZFanYzYTZ4N1BPQldSYnBQcGZtSFVKNGlk?= =?utf-8?B?RGM0MDZSKzZ2akNmbVhVdlQydnV4eFdDaDNtZlZMWkNjZFFSM3p3OEt6N24w?= =?utf-8?B?QTFNL0hBUUhHMjhpNGNaVDV0UlhMbWRITW15eXYyMDZLZmlxREhOcHFSTkJh?= =?utf-8?B?RTVLVUZGR0ovZXRBYndHUzhCbmtydHI0SDZTV2RRMk5HNmFVOFpacUlkYWJu?= =?utf-8?B?Ly9iTHE1Ykd6dFNFaXB6QWVTaHNTa24vZitBRm1EOElMdFNuMGYzMkt4WWMy?= =?utf-8?B?MHlJRC9CcCtJZ3ZPZ1R2ZllROFpmVHdBOFhOdnhINU9HZ0NYTlIvU24vcDh5?= =?utf-8?B?WG1XV1pCZnkwSGZzdHNxcHhlSzl3QVZGbk16bkRLQ1BpL0hGcXhsVUkwbDRS?= =?utf-8?B?ZzQ2Q3MzNmI3RENBZVVMSXVsbnQvY1luVVBRNDBzSUhIRFhnQWNtYks4bEhs?= =?utf-8?B?N3VYdmtXMkNaRndMdTBmaEhnTjNHcVNxMGRDQlFjM04vbDlRaS9TTmdtT01B?= =?utf-8?B?UXNXN0NOTUVmSnhXY3pzeU9OV0ZSMk5XUkdmNVFUTitzZlovQ0h3QWxzZk5V?= =?utf-8?B?NDRRblZlVEcyOGhPZVVyQVlVT2lJWlhjZitrSzlwbEhGRWtkenFzc0RMWWZN?= =?utf-8?B?MXFISEIwSC9kbGZORXowYngrRkVpSTNJWmtidFNaT2taSlU3T2VFL1MzdFUy?= =?utf-8?B?Zy9lUGVGR3JiUStuZlYraHRweWZzaWtUU0ZPN21pZnVSRGpRQWxTUWY5MkUv?= =?utf-8?B?KzBwUnRFQ0V2OEVMeWU1d3FHaXcvcEFJNW9NM0syakhWNHhEV0NEdVdnMitM?= =?utf-8?B?R2pBUDJtL2I1dCt0SGo4eU11UzRwVDJrUWl1OVlZQWQzYXVIcnVxZmhUSyt3?= =?utf-8?B?dlY1UjFnWENtYjJmYyt3TXBQREpKMDFEeGY3RWFSTHhBRXd5L3FXekt3MXlV?= =?utf-8?B?VzZQZkNKM2pxZlptWjB4YlNMdHIyWUJqZXZmZ3JpejF1R3BWUFdRUHdaZTI0?= =?utf-8?B?U3VPanVXazJDQk8yZ003bEZLYlNsVm1OdzJCWm94MWJjWHJHeWh0VWlmM3c5?= =?utf-8?B?RndaY0wva0lTVEJSSDRMOXNmL2JzMFM3blJCRzhzN3QrNVRBa3FXazgwekkx?= =?utf-8?B?UHdwdVhaNzZPTnYxcmJnRDY5Z1BxRjVZbWY0STAxK1VTVmMvbGJ4QW9oRTND?= =?utf-8?Q?Dr5o=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?STVxMWQ5Y0RnMjVVQVY3SVU4YlRobVZlemZiSUxkSythMmxzWVJ0Tk9QNDF5?= =?utf-8?B?cTRrU1NnRDRBRkdrT01pWTF3aVp3dWJwS05MU3VseVlrYkozcnUvdE1HTG5Y?= =?utf-8?B?ZzVmQ3hrSTdFUm9NT3JsZHBVeDI3NXZkLzFmN2JadC8wYnZCTFo3UzN1dUNE?= =?utf-8?B?SlM1SnRjc2lMQjg1dE5YdldsdjQ0SCswSVkvbThQRm1LZERpOTdRWkRja2JG?= =?utf-8?B?QXNxUVdrRi9qL2EvSzBEb3k3bXplMGNMT3F2TWNwLytid21rMUcrNVhBUDVC?= =?utf-8?B?UHRJTDdYdzMzdHZrdlVJZWlDSGhXdlh4M2hQZGNMTUJsT0VYZXlBUjl3eWQw?= =?utf-8?B?UWFxanMzYzNoK1NBUWdGMENKTEl4dkg3Y0JCU3E1TDhuQkhFUXNXVGlPNW5u?= =?utf-8?B?STFYWnNJVWRzcTI2MVExWlZ6d25iUUhTM0gyQklOaExCV2dtanZEVklmQmw5?= =?utf-8?B?bDVlY2dWNHp3aXRlaWYyUkFiTndoRHJ4RVFuT29QTUV4SWt4Y08rRGQxN0p2?= =?utf-8?B?YmpGbWRSZVdxUW9ERzhJbTZJZjJYR2xuUmdWRWZSdVdaTGFncUR2eWpJYkQ5?= =?utf-8?B?NUZWUERSRnJHWW1MZzFHRyt0eENHODYrOUc0ZHpqc2F0TWlaTHpWMHl6SEwy?= =?utf-8?B?UXVOMmxDQ3lqZWsvZ1hwaDcyWHd2bnNsemw4LytaMUphS3lCWEdWMWJ3cFlz?= =?utf-8?B?VWJ0ZXdPZDR3cWJmVFFlQ0w0Mk5rbGlUL2R0andlcG03cFlOczVVL3Ercjdy?= =?utf-8?B?Vzd5NWU1bWYvZWV4OUcxOFd6K010K3g0MWc5Rnc1MFZ6cmRLWnBGTUJQWEp1?= =?utf-8?B?bElyaDZJUytZSnRDSUwwcE1TYnNUNUdYNDNIamNZKzdCd1Z5UTBRTEh1bmVL?= =?utf-8?B?T0VjanhZN0hXczhmL25aaVlFK3BFRjZ3YnVUaW5BYU5JNzc0S3Z5ei9ESDk0?= =?utf-8?B?NFpvdC90bTdPS3JWRGh3bWpIeVJkeiswOERyQTZndkZwWjhPaXBXQjMxeFgr?= =?utf-8?B?Y0h4UkN1VTMvVWhmZXZRN1hvaGRSNUliZjRMMVpOWXMyV0pJUVJkM2FCcHpn?= =?utf-8?B?bm1wSGpSZXdScExMMVdUcXVOUDNMamtiNzFKMXltWTVMMnNjZTRYSkFlakEy?= =?utf-8?B?Uk94MFJTV0JOM3pXYkN2eHZzWXZubUJEamdoQklQR3ZvSGJ4N08reTNqVTBD?= =?utf-8?B?a0kxMm5iUlJMNExRVE5qUUsxUTJ1SEpBQ2c3MVluUWRHOXh2NzNQWXJYUm56?= =?utf-8?B?MGJCOHNHVFVPNDRRY2UrSGlIUXo4LytabHJCZVVISVZOZ25BTWt6Nm9SZW9D?= =?utf-8?B?MWZKY2d4NThDUEhtU3VKdjRuZ2NiSzkzeG5EUnB3QW5WeWZPMW9qNXZmdkNx?= =?utf-8?B?ZVhneU1KbkpzcENDOVRONWNIVXBsbmtFRTFXTVVPN21xYzRNQ2Y2NS81YUFV?= =?utf-8?B?REtjMXlPRFJzTmxrQTVGd1NRU3pmS0hzUWRlakxwRWQzbXJFajFhOTcyalRP?= =?utf-8?B?MU4xSlc2UklnZkVob2lLYmpFMTlscFNWTTFSRVhObGdMYjdXVnczRGp5V05F?= =?utf-8?B?RExadE02WXh6ZTZiSUxEeS9yWEpzbjdQZ1lUZEpaNFdHblZJMTF3bmhNaWRO?= =?utf-8?B?a0pFQUJBOVliK3hOTjJUS3ptOE1Zci9USVhueHhYS3N4NXNlMFVYd3BYQ2VS?= =?utf-8?B?WXcvTmY0L2F0ekJiK3NxVVVXb3ZCbUQwcGhiQjNnaWRGM1BNZUNxbXdFODFU?= =?utf-8?B?dC9RM0lrR2tVY0VsZ3BJbmlTczE0U1JBdlpJclU4cVNCMVp1bXQxbkRXbkYv?= =?utf-8?B?aUhVU0J1Z1NXWmRGRDIxR0tTcVlXU0p4TG5YWmRLaXRwRkFjOEZ5Z2lpemFJ?= =?utf-8?B?UngrMVY0N1lwUG9yN2lySis1Qng0R3pDRmowRHVQQVlPRWxYbE45S2N4TVBD?= =?utf-8?B?MCtqQXpQV3dDcTdkTzVNbUR4RVhrYUY4Tnc4UlZWVlQvWXR6OUxBeUkrWXda?= =?utf-8?B?ajgrR3I2WDZwRnRucVdaejRGdnozV1J3cGZ5OWZTVGFXS3l6UXE0U1lBUDVH?= =?utf-8?B?cXl5NFM0L1ZRWDg3NG1WRkpzZGV1S0xwWmFvNTRiVUVrRzBHRlo4RFNrWmVr?= =?utf-8?B?QU1OTlJaSWNzbGVzTURMQWNlRVIvak1VSkp3alkydGV6THRHNVl4aHpOa1dz?= =?utf-8?B?VnlFL0JKK2dnbkZRNUpobHUyMDJXTU9rNDBPQWdIZitmellFR0IzK0x3ZlQ1?= =?utf-8?B?YThRVjZWSEJqbTFpZDBwc3ZPYXF0NW5DNndxVU9nQmVSMXBrdTlrcUYycGwv?= =?utf-8?B?WlJIQlkyMFVKNTNscExzaFJiM1prWTAxbmxHYS9uTHZTeXpGbXJXQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6f8a5df9-8792-4bbd-0503-08de59dd4588 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 17:40:02.3987 (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: 36ip4px3w+FQjLLiTlWFs3Bqi1i3AgI/Cb/57SfRNBzCQTilMrLKIkQ09ujVd8nt09m/thIA+cOllKp6GxGJ8w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB6512 The current logic allows for up to 1G pages to be scrubbed in place, which can cause the watchdog to trigger in practice. Reduce the limit for in-place scrubbed allocations to a newly introduced define: CONFIG_DIRTY_MAX_ORDER. This currently defaults to CONFIG_PTDOM_MAX_ORDER on all architectures. Also introduce a command line option to set the value. Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed") Signed-off-by: Roger Pau Monné --- Changes since v2: - Move placement of the max-order-dirty option help. - Add note in memop-max-order about interactions. - Use CONFIG_PTDOM_MAX_ORDER as the default. Changes since v1: - Split from previous patch. - Introduce a command line option to set the limit. --- docs/misc/xen-command-line.pandoc | 13 +++++++++++++ xen/common/memory.c | 3 --- xen/common/page_alloc.c | 23 ++++++++++++++++++++++- xen/include/xen/mm.h | 4 ++++ 4 files changed, 39 insertions(+), 4 deletions(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 15f7a315a4b5..3577e491e379 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -1837,6 +1837,16 @@ presented as the number of bits needed to encode it. This must be at least one pending bit to be allocated. Defaults to 20 bits (to cover at most 1048576 interrupts). +### max-order-dirty +> `= ` + +Specify the maximum allocation order allowed when scrubbing allocated pages +in-place. The allocation is non-preemptive, and hence the value must be keep +low enough to avoid hogging the CPU for too long. + +Defaults to `CONFIG_DIRTY_MAX_ORDER` or if unset to `CONFIG_PTDOM_MAX_ORDER`. +Note those are internal per-architecture defines not available from Kconfig. + ### mce (x86) > `= ` @@ -1878,6 +1888,9 @@ requests issued by the various kinds of domains (in this order: ordinary DomU, control domain, hardware domain, and - when supported by the platform - DomU with pass-through device assigned). +Note orders here can be further limited by the value in `max-order-dirty` for +allocations requesting pages to be scrubbed in-place. + ### mmcfg (x86) > `= [,amd-fam10]` diff --git a/xen/common/memory.c b/xen/common/memory.c index db20da1bcaaa..cf63bd077d42 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -56,9 +56,6 @@ struct memop_args { #ifndef CONFIG_CTLDOM_MAX_ORDER #define CONFIG_CTLDOM_MAX_ORDER CONFIG_PAGEALLOC_MAX_ORDER #endif -#ifndef CONFIG_PTDOM_MAX_ORDER -#define CONFIG_PTDOM_MAX_ORDER CONFIG_HWDOM_MAX_ORDER -#endif static unsigned int __read_mostly domu_max_order = CONFIG_DOMU_MAX_ORDER; static unsigned int __read_mostly ctldom_max_order = CONFIG_CTLDOM_MAX_ORDER; diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index c9e82fd7ab62..d2d5e4762d59 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -267,6 +267,13 @@ static PAGE_LIST_HEAD(page_offlined_list); /* Broken page list, protected by heap_lock. */ static PAGE_LIST_HEAD(page_broken_list); +/* Maximum order allowed for allocations with MEMF_no_scrub. */ +#ifndef CONFIG_DIRTY_MAX_ORDER +# define CONFIG_DIRTY_MAX_ORDER CONFIG_PTDOM_MAX_ORDER +#endif +static unsigned int __ro_after_init dirty_max_order = CONFIG_DIRTY_MAX_ORDER; +integer_param("max-order-dirty", dirty_max_order); + /************************* * BOOT-TIME ALLOCATOR */ @@ -1008,7 +1015,13 @@ static struct page_info *alloc_heap_pages( pg = get_free_buddy(zone_lo, zone_hi, order, memflags, d); /* Try getting a dirty buddy if we couldn't get a clean one. */ - if ( !pg && !(memflags & MEMF_no_scrub) ) + if ( !pg && !(memflags & MEMF_no_scrub) && + /* + * Allow any order unscrubbed allocations during boot time, we + * compensate by processing softirqs in the scrubbing loop below once + * irqs are enabled. + */ + (order <= dirty_max_order || system_state < SYS_STATE_active) ) pg = get_free_buddy(zone_lo, zone_hi, order, memflags | MEMF_no_scrub, d); if ( !pg ) @@ -1117,6 +1130,14 @@ static struct page_info *alloc_heap_pages( scrub_one_page(&pg[i], cold); dirty_cnt++; + + /* + * Use SYS_STATE_smp_boot explicitly; ahead of that state + * interrupts are disabled. + */ + if ( system_state == SYS_STATE_smp_boot && + !(dirty_cnt & 0xff) ) + process_pending_softirqs(); } else check_one_page(&pg[i]); diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index d80bfba6d393..cf3796d4286d 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -232,6 +232,10 @@ struct npfec { #else #define MAX_ORDER 20 /* 2^20 contiguous pages */ #endif +#ifndef CONFIG_PTDOM_MAX_ORDER +# define CONFIG_PTDOM_MAX_ORDER CONFIG_HWDOM_MAX_ORDER +#endif + mfn_t acquire_reserved_page(struct domain *d, unsigned int memflags); /* Private domain structs for DOMID_XEN, DOMID_IO, etc. */ -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 22 17:42:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 17:42:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211736.1523225 (Exim 4.92) (envelope-from ) id 1viyhL-0001pC-Pl; Thu, 22 Jan 2026 17:42:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211736.1523225; Thu, 22 Jan 2026 17:42: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 1viyhL-0001p5-Mq; Thu, 22 Jan 2026 17:42:23 +0000 Received: by outflank-mailman (input) for mailman id 1211736; Thu, 22 Jan 2026 17:42: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 1viyhK-0001oz-Cb for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 17:42:22 +0000 Received: from CH4PR04CU002.outbound.protection.outlook.com (mail-northcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c105::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b2661509-f7b9-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 18:42:21 +0100 (CET) Received: from BL6PEPF00013DFB.NAMP222.PROD.OUTLOOK.COM (2603:10b6:22e:400:0:1001:0:1f) by DS2PR12MB9710.namprd12.prod.outlook.com (2603:10b6:8:276::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Thu, 22 Jan 2026 17:42:14 +0000 Received: from BL6PEPF00020E62.namprd04.prod.outlook.com (2a01:111:f403:f901::5) by BL6PEPF00013DFB.outlook.office365.com (2603:1036:903:4::4) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.11 via Frontend Transport; Thu, 22 Jan 2026 17:42:13 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF00020E62.mail.protection.outlook.com (10.167.249.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Thu, 22 Jan 2026 17:42: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, 22 Jan 2026 11:42:10 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b2661509-f7b9-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Lu+HKytEq1fBiNmPMvnlJt5JMHW36HWICqER9b1BCEysDjxBe2414u/UARVdRb5PNHXD96HLIg7UicvdgoBgQreGGKjlIjGb4pr+2a4J5MVWRsnBPsKad0fYzPHpvNs9tQ7WI2+E5HEZwri9f6VnaRL4HDKpaUen08osEMMX07/aceyJaT47PsQeFD9or9ltWZaC8c6K/GBmckWIrBXtCRXeDKke0+PQHOEywh5TECdQV8e/H6rhIiPLX3IGZisxrkAanebdKs4VyeQXQkq/+rnKjyUFAfnahGQ6Vb8hE5cDFqJpAkVLynL4Y/RHLSaxhF0Ii1PfsbEp84R/47K5Aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ViFD675q6zSwsunpxsz4IUcTHMny005zwVFrGu6zJYc=; b=dU5yfxxEysltmp+ghFcvZfdKRIYy+6e6CUyuhh/KgCaf6r4VhUxR3vI/yLs5NeD2vBE+A10tvgV05V1lDH+vuVorb6xE8eQmqV9429HL/Y1MJ80hoPncPweoEszsYl+5Jci0PM8FV2I/UYsDnV28qnGnyBeGMCgGiwBNSi4mGlmhMLTYx65lZOKkZqHG3+jim2gfYOVlKeXHb/ugG8XImHC8wO8okgd4+n0uamssRQ80jVKB49Cf+8d71LWHZ2yoMvolO9zJ1GvZ2CBnrqy3If/nz3lUTquFIzpIPcJbw0SNmrVu+NS327PfPqNR/TkIfAMKv8durf80yHCyPt65Og== 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=ViFD675q6zSwsunpxsz4IUcTHMny005zwVFrGu6zJYc=; b=C9JxFK3PdJ4d1H6D3TMdZd/Di0f5/4lYu2PQWA8m1yM+S8aq8AkyM0gxvKpk7IumhokoJBI5tYopCwSbYOUTNIXb0G2OOIY2HSCb4jVNTm9KIyCqDEBI3eCSfXLVhbU4gxoKU/3dTHjoNf65r5rPIfbj0AkJ9V3dD5vnJ97aMnM= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 22 Jan 2026 18:42:09 +0100 Message-ID: CC: Oleksii Kurochko , Community Manager , Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk Subject: Re: [PATCH 0/4] x86: Drop cross-vendor support From: Alejandro Vallejo To: Andrew Cooper , X-Mailer: aerc 0.20.1 References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <3421e525-fb04-4306-9320-4fa359c2ee28@citrix.com> In-Reply-To: <3421e525-fb04-4306-9320-4fa359c2ee28@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: BL6PEPF00020E62:EE_|DS2PR12MB9710:EE_ X-MS-Office365-Filtering-Correlation-Id: 419c1326-772e-4df4-27b5-08de59dd93e0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|36860700013|82310400026; X-Microsoft-Antispam-Message-Info: =?utf-8?B?a3JDYjlNb05QLythZ3hYRzNtcUJINXNBTVJJQ1p0dCtQQ3pwdjFRTzZZTDZh?= =?utf-8?B?NHlvUlptOGJ2c0twQ1gwTksrQXYwY1JNNTgxektXL0tWWTFJRm9FYVBnOUVo?= =?utf-8?B?Z0pIMHREOGZhWWJYRXJCMGl0ZUF1OW5kQ1pxQ0tUMzhPd09ZeVBUR0cvdGlC?= =?utf-8?B?WFkxTWp2amU3T1AvWU1pak5vNGJXLzdyZEIydlg2SkpWbGpCZUk0U2Uzem5S?= =?utf-8?B?cXVkYjdBZzZqYTdLVHJaM2hDNzM2L1FTcldMcFk1MjlSRHpiK1ljcStaKzYw?= =?utf-8?B?ZmdkeGxIN1QxTW9zNEs4K1VMR1NEcU9Qa2p3cE54VXpPcXd6OW9NNmpQcEN4?= =?utf-8?B?K1ljNTNnd0Q2TzZObWNRbElyL2pjdlZwd3R4eGtZcVhrS3pIM0tkcHF2VDJy?= =?utf-8?B?cFlrTm5DaEZTaVJGK05teExXR3pGeHRsZEY5ZUF5eHh6eHl4MFNDZllBT2ts?= =?utf-8?B?Y3VZSTByaHF5OFBoWkgzbFA5U2pFaUE5dUJMY0g4Kyt5dDA2MHNaSXBnc2hK?= =?utf-8?B?eFpQMHFrQW1HdE51V1I2eFI2Uk5EYzNYMkFXRDdYV0h4NXZuQXhha2FkRnJE?= =?utf-8?B?eUNVdEJtSE1icGZ6T3MxZjBmNzhQb1FmQ3J0VzNKV2Z4ZmhmL1dsMUxyVVVQ?= =?utf-8?B?U0p0Y1BRajlZODRXR0dTUmlZT0lBSzk2RVJkN3FIRDU3TDVzOEhVODhwd21r?= =?utf-8?B?T0NmYmFMS1pWUFk1SGYyT3RYTjl1clVzT3VKbEpXNzBRSWpVTG91N3A0Q3Na?= =?utf-8?B?S0FtVHZZUTZsYXJPMGJLT2U3Y3V4eW4waDlBQVJ2bEhJUS92WVZLVmN6a0Rq?= =?utf-8?B?K2FCaXVPZTZWSC9DRXJKTUJmaXF4aVpOa3NscElHTzk2cDZHWDhCM3FVRW4w?= =?utf-8?B?MHB1UUFlZ2dSWDV0RkdoMzhNRUlPY0VheUFlYklDUVlldjEyTm1CenRjOUQv?= =?utf-8?B?a2FrSGw4R3ZRT0EwaEw5cXRiVXNOdVY5S3RDWW5QM1A4N25ab3VrS3hjenA4?= =?utf-8?B?aEY5M3k4QkR1eVhSbW1ESXNkYzV4MitDTEQyTEdSU3lKemlYQUJPRGkyVGRE?= =?utf-8?B?dlR3alNYaWIzNkQ3Qm01bmNsdGl3ZGEvTWZsSkE4YnFOd3B1RUVwWjhYSUFz?= =?utf-8?B?NDd6bHJiUDQxVGhPcXNxbEk0aUl6VDNTWmZCblA0WHVaOUpKYnZjVDBSdFVj?= =?utf-8?B?M0VDWDNTTkZYMGVadnQya2FocE83dlR6V3Z3TlFjR1l3T1ozZnE0bUQ1dU9U?= =?utf-8?B?ZG92TWxoYnpYbnNHTFFqc3ozYVczZ1FBdVRyaEFqL3F5ZnprZDMrMWsvaW55?= =?utf-8?B?Y1k4cllGVnA3TGFOU3BSaVVCQ1JSdkR6YkFuQ1d5Tzh3YlhLdHc2SlhhR0lW?= =?utf-8?B?SmFvSnVMWS9vTUxpTWVRaVlCTGloaVBaenl3bThSdmprbjRMVFVPdDN5Z0E3?= =?utf-8?B?cXBLbEk3OWlYYTZ0am4zRXhLWlpodExJbDZrc3pOaVlYUXdvSzFvTkhmdUV1?= =?utf-8?B?UFVnUng5LyszNEp4akluREJJR2hBOXpGcTlvRGEzSEo4RnVKbDBEc2M4M0k3?= =?utf-8?B?UVFTb1AxL21VYURPT3FCcjhZa3B5amZRM1BTZHdWTTVmNm9jdlF0YjRGVFVu?= =?utf-8?B?UGhDMGpjZSsrbXFGY0ZxZ0lNUGk5a0k3MWc5dHNPUzJsemsvRkcyWjEvZEs4?= =?utf-8?B?Y1ZicVd3WHZyWDd4YTduZ1Z3ME5jL1ZoRXF0RGY3cXhpZGtXcVl3OW5VTldz?= =?utf-8?B?WWFaWTFONlBkZXRaSmY2emhTREEyUVlTY2k2ekVjMHFQNVNXYzZycGFhRmRv?= =?utf-8?B?NDNmZEV3TjkvdSthUnk4Z01wT2RIMS9YT2RJSjIvL2lvL2NYd2hsZStuSVJr?= =?utf-8?B?VFNEL0NpUmU4VzAwVDJmYlp0UUJKYldtSUpTbzhveis5RkZTcWFEclBXak5z?= =?utf-8?B?TFBYbTVudk13dlhqTzg4Z2g4enBIdURsN1czWjZrUkFDWW9BNTh3RzlJeHAr?= =?utf-8?B?TXBqNk1HN256eFhwRFAreTd2TUNzSU5FaUVuZjFTNCtiUDF3cG4rZC9CQm5m?= =?utf-8?B?RUFEcDh1L21pM1VnRFpMbEs0dVF5Rk1QT0FqVGErQk9PR3U0M3BuRFFLUm0z?= =?utf-8?B?Zys4OXJCbXdyQUgxZUI2Zjhad2Q3WnNYREowZU4xUkRWSlFaTW1PV0tGVmJq?= =?utf-8?B?b1IwQmorZVgzS2V0VnFTd2xHQ2o3L0NsK0lyQk9CcEZvV2tXMkdwVlBsMzNF?= =?utf-8?B?SzR2cXlJVlYrbXVIMDA5MkJidEZnPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(36860700013)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 17:42:13.6325 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 419c1326-772e-4df4-27b5-08de59dd93e0 X-MS-Exchange-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: BL6PEPF00020E62.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS2PR12MB9710 On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote: > On 22/01/2026 4:49 pm, Alejandro Vallejo wrote: >> Open question unrelated to the series: Does it make sense to conditional= ise the >> MSR handlers for non intercepted MSRs on HVM_FEP? > > I'm not quite sure what you're asking here. > > ~Andrew The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as f= ar as I can tell. The question I'm asking is whether there is another code pat= h that might invoke MSR handlers for non-intercepted MSRs. I can't see it, bu= t I'm not sure. If there isn't I'm considering (conditionally) getting rid of them. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Thu Jan 22 17:46:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 17:46:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211754.1523236 (Exim 4.92) (envelope-from ) id 1viylK-0002OP-A0; Thu, 22 Jan 2026 17:46:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211754.1523236; Thu, 22 Jan 2026 17:46: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 1viylK-0002OI-65; Thu, 22 Jan 2026 17:46:30 +0000 Received: by outflank-mailman (input) for mailman id 1211754; Thu, 22 Jan 2026 17:46: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 1viylI-0002OC-Le for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 17:46:28 +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 43bd1a0c-f7ba-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 18:46:27 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SA2PR03MB5852.namprd03.prod.outlook.com (2603:10b6:806:115::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.6; Thu, 22 Jan 2026 17:46:19 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.008; Thu, 22 Jan 2026 17:46: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: 43bd1a0c-f7ba-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=LLafgYG5oXeC7PU4+BD0Y/aZ+D0iH/v8qPrxrbkstrT7XQjKZDnya+edwMRcvlgXE2WPElYweJxxNfOft7tLhfer/oWfL2dWB6pT/sOktbuVelni6So8kjcLT6SnAoijvkprNZYjTbeIpPtAkgjrZrHA+bFmWbo2rszTz2yErdVzeVlLjcVa+gC21eTUCaAnVQYtBNGx68QbmN5AaPryWiNUf4odryPXsnk9GO5rxbaH/lVPoN5jofgkSVXT74pRYPp3D5ZVwUK2Fr7eoGTa/X3pv/UB5Ks0rl+ZsX8iimsDidzxxrj8Getu0Ld/B4vYACNWs7FsuQjX6XgDqE5dCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=umdk8Dz3+SgrY+A6+i/QveUMdiCuv1WF7xlrptnDDXw=; b=xL9m9qCbtwynyhcT/5U6WOieqkD9WNqqXkBF5CoDeAdJ7Tww1ZlvZDLlv74fM7Ux+ma2n39iId0Ieahq0NAjZT0YpFR/3jVAXQhsQvXXQvG7BemkO5f1wul5IgYFBHZcn4DJQbQ7nJvziPNFNE1s5eSxy6kIQCOh5Q0myRYuBfiCRsAVyjHkab7Lf9SiZ5C3STrKczSKHDszQUrXq/DBmiZWgrjU0aJNjnkJxvtK5aJKKUoSEEU7vCzJ1Di+E4ya0M9KE4G/EXkrzOQVy0QJD7eGI1uPBIHao7cUbKlXqODqMjfHrkbBe4L6RIz/bQEi8xnPxwq4DOXebiGaJiJqWQ== 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=umdk8Dz3+SgrY+A6+i/QveUMdiCuv1WF7xlrptnDDXw=; b=0sS6Wlu8TK/01XUBJZQLwCcjdRmlmh7URdHT+rO3Yd9NpJnlsryvJQ8BVVVmupxpWdOW2P+PNAzeHHBHO4g8BCCP081mO0UZu2oTROOfAR+O6fApUFg5J89yIS7bZq7wtFad+8SsfzIA2b11Hb2OJIftXttvlHj52tESVLQk7bE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 22 Jan 2026 18:46:15 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jason Andryuk Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, James Dingwall , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Subject: Re: [PATCH] Partial revert "x86/xen: fix balloon target initialization for PVH dom0" Message-ID: References: <20260120140648.25977-1-roger.pau@citrix.com> <1357dda0-bb5d-4f59-a53c-d584099bf65c@amd.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1357dda0-bb5d-4f59-a53c-d584099bf65c@amd.com> X-ClientProxiedBy: PA7P264CA0056.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:34a::8) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SA2PR03MB5852:EE_ X-MS-Office365-Filtering-Correlation-Id: 43be4f77-69fe-48a2-ceae-08de59de260e 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?V2RtNVJGUGF4NkpkVk00Nm5yRE1KeW81TW9GR1pXci90K0pRQ0VMTjBka3dy?= =?utf-8?B?eTZsTWNkcHZ4bFowN0dWeGRYYnRuc01lSm9VNldTQmFpclZvem94OHRlVFhW?= =?utf-8?B?aCtiZm1YNzU2RXBpWS9pU3dhUDFBV0xyWWxNRUtFSHUyL01DalpGWUtpNGEw?= =?utf-8?B?Yy9uRXFud1Z2dTNTQkRiN0xUSHZ6VExGc1pSMzlCSHg4bDN6czlSYjlWRktY?= =?utf-8?B?bktMc3ZjN2lrKzU5eUhDOVdSeFRZQWRmS0pYd204dzFMK2gzdWI1TllLUy9D?= =?utf-8?B?ZnRXL1prYW1vZkRJdVc3VWlFbmdnOW1SbWZNdUoxc2FSamt2N2NIbjhaVUhI?= =?utf-8?B?SE9GMlZjaG4vS2ZCSGMzT1plVXhEYlJXTkFLMVM2dlVlTm1VRUROQWlKVERD?= =?utf-8?B?Q2hmc2o1Tk55UzJLYVpGcFg5QmRIaFkxTk9jWUF5TUFwcmpzZXd4UCt6NG1Q?= =?utf-8?B?SU5MUTgvcDJvYTVJcEl6NmpHbXVBQmlkbis3UkE2cXR0UjFWaUpBZ2pNV3cy?= =?utf-8?B?Qmtab2MrdEIzbVJSNTJSbmZBYUd5OUR5SXd1Tmtyc1RabW8rZXI2bExLQ0Fy?= =?utf-8?B?cTJNSmJaMmRkQnczSDlHb3k0SXN6MVM4T1FZNkRJSFJYRXg0bGJqeXpQZkNH?= =?utf-8?B?em96cFFqdlFodkxSc3BydmVweTIySGsvcXkrM3Q3T0l6MnpKNTlMMjA5MFRr?= =?utf-8?B?TVJmMW94RnM3QlhWSmZUb0E3T2tydnZJZzdIU3U3UnJPUXpleGJFNEU3SU40?= =?utf-8?B?anIyYldmWHVBdHYxVmJVMmVMNEdiMlBoZ3hYbnhPLzI5NXV5U1FDaUYvWWgw?= =?utf-8?B?T1NuaWJ2aEFYZzZwd1NoMC9uWEFucE8xcURoZUREZGJBQ2RzU2NNVms4YUd3?= =?utf-8?B?S1FmUHZmSDhjL1hjLzgwZEVVMy9oSDRUVzcrczJ2eWwrV3cxaXQyZHcvMnlS?= =?utf-8?B?aG80aHJYWmhHNFhub2ltOTB4Z3NSeDVxWVE0dS9uRnVGZjhBYWJJbVNhUGhr?= =?utf-8?B?d3RqOVlUNG9IZURHdjNtSlorSFVzZ0F0MUVVSE1Kb3pkUEozaCs1TW5vcE40?= =?utf-8?B?LzR2dDN1eEZFVWc0Wnp3bFlmaVplYTRxbzlIeWgyaC9TSTdIYkh5OWNIK0JJ?= =?utf-8?B?dTVITGRxSG0vakJ1QkN0YU8yOEZKQ3Azbit6cFBIaXd4TDA2YkFEUzl2aXF4?= =?utf-8?B?NDdzek1OSG1wanBRQkJxWFhyaVBEMGdzM2lJVm9RODNOaGxNeXN3V094QXRE?= =?utf-8?B?cVp5R1VPaG5TQWcvSGY4Q2hxUjBuWVNoUTVUSVNCUUxhSFhMd1hXWDM1dnNl?= =?utf-8?B?bXVZNEdzUFZMYXRnRFp0aXF3TTY5bWlBVkJSbXpvUHZPSlQ1djRUWlVuS3Bz?= =?utf-8?B?OEhGaElDcGpacUYrUDArTE14N1h5SGk2TjBXcEFyNENaRkhpTXpSendpK3hs?= =?utf-8?B?ZXN6MXR3d0VxWk4wUk5OZVJCeFA2MVN2Sm5ndFJrbmowc1JQWlhBWUVCZXBu?= =?utf-8?B?UzgzUXlBWmYvWUdkcGlwWjdnaTJjM2xqTDMvZi8vcXBMbzRab1BvUk1KZnVN?= =?utf-8?B?ZjJxSytJUjZ0Z2pxaTZLRTVhRVJ2anRPT2dibHpROTFvVGdTVThMS0hHRGNH?= =?utf-8?B?SzJHNmJSTTlHRXd3bzh4QlVNSXBNQTdaWmpGWnVkNEhUZnVqTExiRXY5UjdY?= =?utf-8?B?K2ZlQUlpNmtMS3QrT0IxdXZVYVZ0NXJKM1VvUWdDUHpyN29Xb2orbFFxVmZG?= =?utf-8?B?TWZjaCtyWTVoT1Z5QXdwZEFhako2cCs5c1VlekpTaFJ6eFVZanYxZGV1Ukw2?= =?utf-8?B?OWpRSTdiOW8wcHpJNEpzY3lTZWxhSDN2SUZpN2l6QjFCMVplZlFDa3VSZ3Za?= =?utf-8?B?azQ2M3V6NkRrOUsyWUNxSVVvSGR6ODh5SnlQOEtYbGFQK2JOdkR1czU3VVcr?= =?utf-8?B?R0dsLzBHVkF1cWc1QW5qb1RPWWNRWFFqejdjUnJyUll1c2VVZ0xZRjZjK1lx?= =?utf-8?B?MnNucExJelVQTW94eVhuTDFkM2k5dTJqekQxME9ONEUyN1JQQm0vMXhsWjB0?= =?utf-8?B?VEFjQjFlcDFtb1Z5c2pITUt6K3kreFRoTXZnSHZGVjNWd0lWeVN2eUY3T0JE?= =?utf-8?Q?dH8Q=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZEZvejlqT1lwWkJSTjJnOUZYVWlRY2NlUWNjMXRCQTRhbERxcGViOWxndVlq?= =?utf-8?B?eTR1d0NTaUtPWDlsSnFWZG42bWpNLzF4YjExMUJmVityMzlzRGZ4cFh3TGdM?= =?utf-8?B?akxpc1N0MXdtWlVockdiNThpZ1BpOVdVRzMvb01SejJUMzNWNnA1ZkhGNWsx?= =?utf-8?B?VVg2MGY0eVdyVDJ4NjVFOWlxSW5xTTVOS0xxMVBuRm92QktEWU05SUgzRzNp?= =?utf-8?B?RXNWTi91UklVM1QvSDJyQjhrR1N6WVJCcEtrbHhDNGp0RjdDNVp1WGVTbWxh?= =?utf-8?B?aHc5T2h2bmp0VkxSVlFsZ1NyWDFiWVlzdEIvZ3d4azBRL2lJMjN5djlrRWdB?= =?utf-8?B?enZFYytzWkV2M0hDSmJPU1Z6UFNNcjlKTjFyTVpkNGZKcm9NOTFJMGp3a2Ro?= =?utf-8?B?VEVtNDBrTHlzMDZVc3h3cXdkanRRYURNSm1xaStVOEhuUVNxUnNoYlNxZXRZ?= =?utf-8?B?cVc2T3k5d3V2L1RuWDlJcVNEeUdtakRIbFAvTWdrWXRRblROcVNodmVRRnBP?= =?utf-8?B?dVh6bk9vNlFqaXRja0c0REtJVlBYWXB6dm5vSitNS0NGc21ZV0xhM0xvQmJD?= =?utf-8?B?RHVLQ3dSV3gvd0l4MzNVYkd3MlJaelVKK2dEWVlDWnFPRVp6dGdTbXRHckNv?= =?utf-8?B?VkI5ZGhFZUg4STQ4YXl6Y20xaXMwY0Z1OWZpalpCaG5wUjhoRE4ybTBUNkxG?= =?utf-8?B?SlBRa3RJdm0ySTg1SFVXamlxaTJ0WlFoVVd2NjJLMmdwcmpsVUJVb0F2UnZq?= =?utf-8?B?WS9oNkgyK3UvYm0zQ2xidno4OEM0RFRRcXpvZlZaU2wxeTkzWGpFZkhralU5?= =?utf-8?B?em9XYVN4Q3lBcTVzUnNzWmlXTVJROVhEbGo4cFlieWhqQWV1QUtjMUNDcmd1?= =?utf-8?B?SUNkM3VGbUc0ei8yeFBxSDNTUno1Z1dVSUtWSHZLd2YyL3Q4NUM2OXFKekRO?= =?utf-8?B?ZFJkN1YzNHhWUzllUjNlbGppd1A4UlBuOC9LMWJqV0QvZFFUdnI1S3o4ZWVM?= =?utf-8?B?aGtvRVk1Q2J5WnYvTG4yYnFiYm0zMW9oZE5rK3J0clgxbFUxc2JmUDRWOTQ3?= =?utf-8?B?SDVDS3Z3RnNHc1E3cmpQNXAxT1pUKy9wOGlFbDRra2RwdS9MMjdjQW12TWtP?= =?utf-8?B?djUwWjYvMEFPNGJWRFRET1BublRyRFBFeFlFRlRRYWYySG1tdWRYRDFkeHlK?= =?utf-8?B?ZFcxN3Z1TXM0UzVjeDl2Y2dmcXdob3Q4QkI5bW5PN1pWWklBcktoa01YL3lV?= =?utf-8?B?Tlg3TjcwelFsdkEybEFndGExaU9WZzVkRXlsVldLeUZuZWdIMVp5SU5VdW9N?= =?utf-8?B?ZVR1SDNGSEV2N1pEUlJjQnpmV2RSUnVoaEdkeXdES284Q05hWXlObnRLRGlF?= =?utf-8?B?UWM4VENtUSsyZXh1T0FPU0NQRlJtUlFTRThGNVAzbzJ4eVV3RWVPV0pra2JK?= =?utf-8?B?bmlZaTFEdVdKRkdCT0grR0NHV3Z2OFJ4ajR5bFcrZFFFeFRWWWExZk9CakhJ?= =?utf-8?B?dis4V3l0RmRsL1ZNUzhBZTBJTW5OS3BDL2Fmbm9tbHZCblNnSTNNSG1Hbk5Q?= =?utf-8?B?dVNCbWE0QmswL3JRVC8yN0RDdGpEVjZIUFA5MDNWejdPeW5UOTBkQ0VBVG9Y?= =?utf-8?B?QWJGTk0ycUxiR08veC83c1ZwZHp0ZWpkNXBhSGNCYWcyekhMTmQ2ZUQ5eEVZ?= =?utf-8?B?cm5oUGRXNmtYR1BKOE5UOWlPQjhpdkMzeVhyUnpacjNzS1RMN1h1S0dtYTJx?= =?utf-8?B?RlBOdklmdVlQUDZ2WER3R1NuMXdjVk92SnJZTHcycFVUY2FEUVJaQ0JiSk1u?= =?utf-8?B?QU02MFNvZ3lLZDNEaEF4VlR6dS9JemZPT1Q2VXJyYVREemgvK1ZPOXB4YzVQ?= =?utf-8?B?bWhpOHBrVVdHc2FMTElQOW1CT2d0QmNNck9UdXRKVW5pb0QzcEdmMWE5SnNW?= =?utf-8?B?YzB3TmwwWVpQTXV5Z25wSE56azJjay85SHU5ZkVsRVNtRkIyREt3QTlQUkpU?= =?utf-8?B?TVYrQlMxUFFkOVlIVDJkeTNuZDMvbllqYTVuR0VvOVFUMVJsMXlNTE5DdWVp?= =?utf-8?B?VXVMZlZSSkpodnVPbkFVSVJDNGRVNHZoSkVYdWFWTTJhRlY1bENVTDFxdmRM?= =?utf-8?B?V1JqVkNKN3p1U2hiK3F4eVU3bkpPYjN0eWVPMldZcnZRMzREWjRyOGpaeURK?= =?utf-8?B?RFpMU0ZOUGRIYVJneGlWTGkyZ1dSVWYvRjZ3Mzg1NHNzR0twR21RaXcrRWIv?= =?utf-8?B?cU13L0t2MWJLTk5sc0crNThtZElnalprY1FxMGQ2NUlKVHovMC9Yb1VTL2Fw?= =?utf-8?B?V005dDcyOXluSllLcTM5c2YrTDVGNDhHaEp3b2g2aUZjcWF5TnJzUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 43be4f77-69fe-48a2-ceae-08de59de260e X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 17:46:19.1522 (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: mkyFT+Fu5xnORI/47oCD/1fr4hYAWDSO0BEsTE73ieT+FGLEBycf/GC3SA+gKVvE4ouoW0z28hvd/k2Q6zRJ4w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR03MB5852 On Thu, Jan 22, 2026 at 12:03:47PM -0500, Jason Andryuk wrote: > On 2026-01-22 11:57, Roger Pau Monné wrote: > > On Thu, Jan 22, 2026 at 09:40:01AM -0500, Jason Andryuk wrote: > > > On 2026-01-21 12:49, Roger Pau Monné wrote: > > > > I haven't tested it yet to see whether that's OK to do on PV, I would > > > > think PV and PVH would be the same here, since the setting of the > > > > xenstore target value is based in the return of > > > > XENMEM_current_reservation for both. > > > > > > On a system with 32GB and dom0=pvh dom0_mem=7G: > > > > > > [ 0.295201] xen:balloon: current_pages: 1835007 get_num_physpages 8220126 > > > xen_released_pages 6385120 > > > [ 0.295201] ------------[ cut here ]------------ > > > [ 0.295201] Released pages underflow current target > > > > > > 8220126 - 6385120 = 1835006 > > > > > > And also for PV: > > > > > > [ 1.406923] xen:balloon: current_pages: 1835008 get_num_physpages 8220127 > > > xen_released_pages 6385120 > > > [ 1.406928] ------------[ cut here ]------------ > > > [ 1.406931] Released pages underflow current target > > > > > > > > > So we don't want to subtract xen_released_pages for dom0. Is > > > xen_released_pages expected to be non-zero for a domU? > > > > Oh, yes. In fact I think the patch here is wrong for PV dom0, as it > > shouldn't subtract xen_released_pages from xen_start_info->nr_pages. > > I will need to send v2. > > To be clear, the numbers and warning are from the follow on > current_reservation patch. Yes, but I think it's also bad to use xen_start_info->nr_pages - xen_released_pages (my current proposal). xen_released_pages had a different meaning on PV which I kind of stolen for the unpopulated alloc work. It was originally meant to signal pages that are freed during the boot process when it's not possible to relocate them; see xen_set_identity_and_release_chunk. Unpopulated alloc doesn't free the pages it uses, because they are already free to start with. I think I need to introduce a new counter that accounts for pages consumed by unpopulated alloc strictly, and not re-use the xen_released_pages counter. All this memory accounting is far more complex than it should be sadly. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 22 17:49:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 17:49:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211766.1523246 (Exim 4.92) (envelope-from ) id 1viyns-0003WM-Oz; Thu, 22 Jan 2026 17:49:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211766.1523246; Thu, 22 Jan 2026 17:49:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viyns-0003WF-LE; Thu, 22 Jan 2026 17:49:08 +0000 Received: by outflank-mailman (input) for mailman id 1211766; Thu, 22 Jan 2026 17: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 1viynq-0003W4-TI for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 17:49:06 +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 a3d07167-f7ba-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 18:49:04 +0100 (CET) Received: from CH2PR14CA0004.namprd14.prod.outlook.com (2603:10b6:610:60::14) by DS4PR12MB999075.namprd12.prod.outlook.com (2603:10b6:8:2fc::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Thu, 22 Jan 2026 17:48:58 +0000 Received: from CH3PEPF0000000C.namprd04.prod.outlook.com (2603:10b6:610:60:cafe::27) by CH2PR14CA0004.outlook.office365.com (2603:10b6:610:60::14) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.9 via Frontend Transport; Thu, 22 Jan 2026 17:48:44 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CH3PEPF0000000C.mail.protection.outlook.com (10.167.244.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Thu, 22 Jan 2026 17: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; Thu, 22 Jan 2026 11:48:55 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a3d07167-f7ba-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZuvQEgkPBmk2Ss897ar70x6C3/mHK+JsebCp93wHR5GHSEIUMC5PvCqsKYrLnmwaNRlFJcdA4ocUJ/wNaalEAwEpq/moVBBGXq/Tm6YfGAynArgXhw7qMeryR1ME9sX1PZdcO0P8/rq0EmZTBYk/aGNoj4B600Wd5YCDOaOJyQR2rL8fbEg3d0wS3gf9gCehev8mmFOXHoEQpgiqLF9fBPpFhzZQiqJcHUis9NtOOEyZscZqllgSciBIPEgIxbfivGIHUF0TAIHhpIxfOIw+kYsT2EYL/eKGnIrqLqksT6lRXgxvp9g9feiIAgZ4JuOJLUDaieLE41+CBpqBz2s/SQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=cRil9PbVBhOa83C92+M8SdCtBsJOkobYTmtGebdb9L0=; b=xVqur7GbdguKoubEk+Hz6XAcdCBinOIte3mkpFDPOMnH956L+4Yv2XuAqfuIrAWzhinZn5KjQ0frAKBf2HpAXCWg4R4S0pE0vVBzmKVYaMnPWVpwOwZ8Of3kmfKh1xkcyY6uB1nWqbet+UNmc70uOkmGu4hkykiWV+SwylcdGJSwrIU9+QpHe0Sr9q1ZboIW7OEj9OpVqGMxue1llqy3UziS0RmvNrgQto4iFTM243WpQhdgHVCoKxcaJ4wj0FRoe/GXJ9QG/pFkUnUGUA1BsINDeyo4qSpvYH4Z9yeaEK2jwXoSl12LQ5ZP2hWeMfM0GZXU/pRkX/qo2C192NPj4A== 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=cRil9PbVBhOa83C92+M8SdCtBsJOkobYTmtGebdb9L0=; b=W/BL9rXV1fVjUpZlzLimUg6eVSlPUByN5mi62UF6zf0tQv7fxKs/BtSHQD+R+MNV2EkgAkTwyOnjauysEbNnrF5rGGk5Pdg5biJ2ILm5m4H8Jkk7nPO4Qef1ggYgi4/F8qRG5OHq1+SVPqcUTiIGC7926Eq2+Qw6dPmNyTPxNzU= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 22 Jan 2026 18:48:53 +0100 Message-ID: Subject: Re: [PATCH v5 2/2] earlycpio: lib-ify earlycpio.c From: Alejandro Vallejo To: Nicola Vetrini , Andrew Cooper CC: Jan Beulich , Anthony PERARD , Michal Orzel , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , , Xen-devel X-Mailer: aerc 0.20.1 References: <20260121154757.44350-1-alejandro.garciavallejo@amd.com> <20260121154757.44350-3-alejandro.garciavallejo@amd.com> <5948da25-0b4d-48a5-983f-0fc9424774b3@suse.com> <947a4230-4a1e-4178-b7f0-ae5618f4303d@citrix.com> <02004b6ee5ddb57f4b834163a955d29b@bugseng.com> In-Reply-To: <02004b6ee5ddb57f4b834163a955d29b@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: CH3PEPF0000000C:EE_|DS4PR12MB999075:EE_ X-MS-Office365-Filtering-Correlation-Id: 32d6d7e4-42ef-4a9d-795f-08de59de84ae X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700013|1800799024|376014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?RTlaUWJvdUhxK01kb2NjMUdRTUJYRHFaL1lKVFpyRWVuVDBUK2EwbTROREU2?= =?utf-8?B?RmtoWWJLZ29SdW1KNXEyL2xvb29BaEZJTDdoOHEvYUlkbTVROGpUcUE2RDhx?= =?utf-8?B?MEJ3K1lKekZWYWp1WnhKMllkL09oc1NZcnVQNVgvUW5yb0dJcXoxaGdsT2lZ?= =?utf-8?B?Q0xhNE94UXQ5b2xjQjUrVjQ2U2k0ajNZVXV6b1c3MnU2dThXbjFBOFhrNUVN?= =?utf-8?B?dlBpQTlmdXlmM1p1ajlIai9ST3VFK2o3M0VzcTJZVGl1KzVtZXdLTWJrRzhC?= =?utf-8?B?KzRicjR6dzE0cmFLUEZnRHp0bEhvMWdVY2gvUUt2b1pteWg3aEM2bzB0N2pH?= =?utf-8?B?RExBT3lTS2hYMFZXVmlkRjl5SjdXMkJyWnpOYTJWVHg5cnJSWEt2WVRWKzAv?= =?utf-8?B?ZFdCaDJvVEFIWEJySDBsSGdOcnBlN0lXNjUyU3FiOGwxL0dqMDExeTRaeGN3?= =?utf-8?B?TEN4Z0JPYnFqUUJXSXQrT2Y0MmpaOUNzWFBlWTJLOWRJb3J4RndUSkplejJu?= =?utf-8?B?elNiSk9hb0RrT0loMm1EYTQrN2JHN0xhZDhYZGJVLy9yVFB1LzlOc3hPMjZN?= =?utf-8?B?UjRIYklTTGFoSUVnK1hNTHBSZjRTZVluZGhCT0MyQmYzMkpncnJqM08ydTZs?= =?utf-8?B?Q1BoTDhueTJjdmJyc0dQQmR5c1VzcVFhY0hOVER3cnA5N3NoUmhMOHBTc3A5?= =?utf-8?B?ZGQ1OVZvdVkybnUzWW45YzJpNEcvcDB0VzNUdkZpK25jcy9sSzl5enRNb2Jw?= =?utf-8?B?NWY5NVZKNU5nSUQ0TWlmek9TT3NieTQrNy9SVXJyRGRaOG9GeHhlM25iQmtq?= =?utf-8?B?K1ZpMUkrbytzQ2NwZENaa3dDNWp1RmdLWGljQmRuNWVLMi9QSUdVdGN2Y2JM?= =?utf-8?B?N1psQXJzaFZVbHVWU0xBU1dKcW54L2xJK3BmMlpwZngyR3laVWNUQkNOaGVB?= =?utf-8?B?dW8weFVVN2ZYNFlzT05vb3FxcEpGaXZBRjZHU2xqZC9hK3FVUkRBeUI1V3pi?= =?utf-8?B?L1pGQnpZbm1DN3VFeHNPNFdOTElwN1hWemlFQzdUUlpCblZ4NUJMSnM4WFVh?= =?utf-8?B?S2x0UVRPN3hTVUFNRWcxSXY5UGRMeHVRNklQQTA5RXk3TlIwN3pZQWNjQWt2?= =?utf-8?B?VHN0WjBBVklWS0xMcTNEVnlFaHVOd2NXYzgvcTNzSThIcnU0Q3czVkEwSFZj?= =?utf-8?B?Z0cydUNGUDBQQzV2c3N3Vzh2empjT0VocGJaSjVyZC8vNVNudGtQNUZZQjMw?= =?utf-8?B?MVYyNlhYbVZJWTRvNU51czlsSms4bDFFTStZV1FPeVBpVitrak9EdWFjL1U3?= =?utf-8?B?NGxwMTZhR21SNHVnUEM1ZURHc0d0ZEUveW0wSnM5b1dRbmZNUTU4dnExYUts?= =?utf-8?B?YVYzekY4Y3NDMjk4ZEpPOURBaVdWZjdIeCtOTjhHRG9kZEtvR3MyUkd0Rjhj?= =?utf-8?B?cDNVOHc0aEMrY2dIdEV1ZWxYUlN2WHJLRFpRb3BuQUdlU2tvNVA3MWZ1UXNJ?= =?utf-8?B?bitjVTliaW5EazVZbEJoZEp4dDl4dk90UXRPUHhHbHh4VnNLcTFVbHl4K1hs?= =?utf-8?B?S3pYL1Q5OVBaU3ByNXZKNDI4ZG5VTTdzWGg1S2oyclExYUQyd2NlaTR1TFg2?= =?utf-8?B?UEo2b0svR1FCTG5jSmJ1bVBxZ3Vvb0t3cWQ1a3pPZjR5TzRQaHJZcnp3bnYr?= =?utf-8?B?VVNqVGxTRDQ1QVpmYTBtR1dUZlZjZ01jQ3RsVFFLQmEvcytCckxSTHdmOVRJ?= =?utf-8?B?bWVqOWM5TTJQTGJwcjQ0cWp1cFQ2L0xYcHlUR1dueFNCQnBlc0J2QWpYRHIz?= =?utf-8?B?NEVoMEQ1bGtaWENzUnVKMDZSQUNzN3Q0NjZuMzVSR1FrZlJ4R2xYWStEcjRi?= =?utf-8?B?Y1RRbTY3ZDRINllRazMraGM3djF4WDZocHNUYURINW9zWkhKbGVpa1ZScEFU?= =?utf-8?B?REdxbTJaZTFMRmM1VHV1Ym1mZ0Z2SWtVNDFMM1hHcEphR2VnS2dnSXI4akdS?= =?utf-8?B?SXhjbm9WSFI3RzJTNjNUb2tLVFRkZU1Za2VENnRnQ1NoM0NBS2RjeFdyOU4x?= =?utf-8?B?NGp5RzRRWUNCbEpIaE9JZEhmYTE4ZE95bGY2VWZCRVQ3NEllc3hMSHMrV3BC?= =?utf-8?B?eVFXVzhxOWhXNk8wVVcvcnFzU3BoaGtnWU1TOTJDYWFCeGNxOWE4OTNzUExh?= =?utf-8?B?ZFlCV1JFenVyMkdicnVaRWh3Y0gvYTBPQ3U3WnJGL2MreUR2U0pZcjQ4RzJp?= =?utf-8?B?RnNKZHZiUGtpeVFKVEJZcnI4THFnPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700013)(1800799024)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 17:48:57.6271 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 32d6d7e4-42ef-4a9d-795f-08de59de84ae X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH3PEPF0000000C.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR12MB999075 On Thu Jan 22, 2026 at 3:18 PM CET, Nicola Vetrini wrote: > On 2026-01-22 13:50, Andrew Cooper wrote: >> On 22/01/2026 8:27 am, Jan Beulich wrote: >>> On 21.01.2026 16:47, Alejandro Vallejo wrote: >>>> --- a/docs/misra/exclude-list.json >>>> +++ b/docs/misra/exclude-list.json >>>> @@ -121,10 +121,6 @@ >>>> "rel_path": "common/bunzip2.c", >>>> "comment": "Imported from Linux, ignore for now" >>>> }, >>>> - { >>>> - "rel_path": "common/earlycpio.c", >>>> - "comment": "Imported from Linux, ignore for now" >>>> - }, >>>> { >>>> "rel_path": "common/gzip/*", >>>> "comment": "Imported from Linux, ignore for now" >>> Judging from Andrew's >>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2277362= 625 >>> this doesn't quite work. As I had expected, since the file is compiled >>> unconditionally now in its new location, some violations are now also >>> unconditionally reported. (Some, checked for at linking time only, may= =20 >>> not >>> be reported anymore for the *-amd analysis jobs.) >>=20 >> Yeah, in hindsight this seems obvious, given that we're compiling then >> discarding. >>=20 >> There are two options: >>=20 >> 1. Use an earlier form which adds the new location to the exclude list= =C2=A0 >> (Still needs to be in this patch for bisectibility.) >> 2. Fix up the violations first (only 6 in total) >>=20 >> Two of the violations look easy to fix, two need the deviation for=20 >> octal >> numbers, but two essentially-char violations look to be hard.=C2=A0 The= =20 >> logic >> is doing ASCII manipulation in what I would consider to be the >> appropriate/canonical way, but Eclair does not like the mixture of ints >> and character literals. >>=20 >> I dislike option 1, but as (contrary to my expectations) this is >> interfering with the *-amd build, I'll tolerate it. >>=20 > > I agree that Solution 1 is the easiest to implement. An alternative=20 > could be to fix the regressions for R7.1 and R20.7 (they're trivial)=20 > regardless and add casts to sidestep MISRA for R10.2. Easy as it is, and while I'd prefer to fix earlycpio.c, I just don't have time to do it now. The original incarnation of the patch I sent that moved = the exclusion would work here. That patch, followed by the lib move (as it was back then) ought to work fo= r the time being. I'm not in a hurry though so I'm happy for the move to wait unt= il someone finds the time to fix the errors. Whatever you prefer. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Thu Jan 22 17:52:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 17:52:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211777.1523256 (Exim 4.92) (envelope-from ) id 1viyrF-0004ze-5z; Thu, 22 Jan 2026 17:52:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211777.1523256; Thu, 22 Jan 2026 17:52:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viyrF-0004zX-31; Thu, 22 Jan 2026 17:52:37 +0000 Received: by outflank-mailman (input) for mailman id 1211777; Thu, 22 Jan 2026 17:52:36 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1viyrD-0004zR-SI for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 17:52:35 +0000 Received: from mail186-9.suw21.mandrillapp.com (mail186-9.suw21.mandrillapp.com [198.2.186.9]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 20ba887c-f7bb-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 18:52:33 +0100 (CET) Received: from pmta10.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail186-9.suw21.mandrillapp.com (Mailchimp) with ESMTP id 4dxpYW5KbzzK5vgYq for ; Thu, 22 Jan 2026 17:52:31 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 7089f4cc05dc4590a2b89501733fc802; Thu, 22 Jan 2026 17:52: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: 20ba887c-f7bb-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1769104351; x=1769374351; bh=jDz1kCRPSCjxFunO8fX8LckS3KZrAMoSwm9tsDuQVEI=; 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=lhY7tfovkwgz4u5hTr6ovJ/hX4O7o+6Vv9oM576jLowNw/5nyPzhU92oTGpOFKXsI yckXMUwMrtTxTNUViG8tXybh6EbKPl3YArrctEcevkDGEwslTEckEdQamK9NrN5PHa TnPU+lmRXYWihhJOig/QkQuCWkcXdZ77VL9KcCIwwn96x/zqOEeIVnUntzP+RJM0+x O5qBD9gipvDkMQ9yFe2E9zH1nBhG3Mu+sJSVpLsmz9Iq6M7N69vhIqeCyJ2SB2Q/Pu z/zhdKXrD+zWcRidgZLbPtlNu01/xvzMPwOie7VhgSovECDpaHweqECgqSZTHkZ+Xu ti2Os1PcicwiA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1769104351; x=1769364851; i=teddy.astie@vates.tech; bh=jDz1kCRPSCjxFunO8fX8LckS3KZrAMoSwm9tsDuQVEI=; 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=N2UnO3T+Mzyj7sM5bQoPo9ZXs5G8kZ9nQBsE9kgdrAO2YCkSspSODxbz3Q8p2p9d3 p8IE79xP3JgNKwTAx3aCJYsS68z7GIb1hXompHGiya5rIvht5Rkx2Eg5uqQqIGyuSR DkrUbWTKRgg+jXSs/8OYlljdq9W4w5MdQ+Eohb3GEVHU/se7TntFlwvhBx7K13seZ4 6pjVReKVBEnwJTMwYpN6NZQMyhAlvoMznLKiBLs3KHYNmVVogh0Y675cXgbr3p9l5M Xl2TYiQbcuMMdTjKMW/4o6EkybPrz8awXgg5Fhpwqo4/hG8kB7L9AiSb8VTCWGPWf/ X7fHTmmsTJhLQ== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=204/4]=20x86/svm:=20Drop=20emulation=20of=20Intel's=20SYSENTER=20behaviour?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1769104350376 Message-Id: <8b0eed14-e35c-46b4-b414-1f0309a27a60@vates.tech> To: "Alejandro Vallejo" , xen-devel@lists.xenproject.org Cc: "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Jason Andryuk" References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <20260122164943.20691-5-alejandro.garciavallejo@amd.com> In-Reply-To: <20260122164943.20691-5-alejandro.garciavallejo@amd.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.7089f4cc05dc4590a2b89501733fc802?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260122:md Date: Thu, 22 Jan 2026 17:52:31 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 22/01/2026 =C3=A0 17:51, Alejandro Vallejo a =C3=A9crit=C2=A0: > With cross-vendor support gone, it's no longer needed. > > Signed-off-by: Alejandro Vallejo > --- > xen/arch/x86/hvm/svm/svm.c | 42 +++++++++++------------- > xen/arch/x86/hvm/svm/vmcb.c | 3 ++ > xen/arch/x86/include/asm/hvm/svm-types.h | 10 ------ > 3 files changed, 22 insertions(+), 33 deletions(-) > > diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c > index 0658ca990f..e8f19dec04 100644 > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -401,10 +401,6 @@ static int svm_vmcb_save(struct vcpu *v, struct hvm_= hw_cpu *c) > { > struct vmcb_struct *vmcb =3D v->arch.hvm.svm.vmcb; > > - c->sysenter_cs =3D v->arch.hvm.svm.guest_sysenter_cs; > - c->sysenter_esp =3D v->arch.hvm.svm.guest_sysenter_esp; > - c->sysenter_eip =3D v->arch.hvm.svm.guest_sysenter_eip; > - > if ( vmcb->event_inj.v && > hvm_event_needs_reinjection(vmcb->event_inj.type, > vmcb->event_inj.vector) ) > @@ -468,11 +464,6 @@ static int svm_vmcb_restore(struct vcpu *v, struct h= vm_hw_cpu *c) > svm_update_guest_cr(v, 0, 0); > svm_update_guest_cr(v, 4, 0); > > - /* Load sysenter MSRs into both VMCB save area and VCPU fields. */ > - vmcb->sysenter_cs =3D v->arch.hvm.svm.guest_sysenter_cs =3D c->sysen= ter_cs; > - vmcb->sysenter_esp =3D v->arch.hvm.svm.guest_sysenter_esp =3D c->sys= enter_esp; > - vmcb->sysenter_eip =3D v->arch.hvm.svm.guest_sysenter_eip =3D c->sys= enter_eip; > - > if ( paging_mode_hap(v->domain) ) > { > vmcb_set_np(vmcb, true); > @@ -501,6 +492,9 @@ static void svm_save_cpu_state(struct vcpu *v, struct= hvm_hw_cpu *data) > { > struct vmcb_struct *vmcb =3D v->arch.hvm.svm.vmcb; > > + data->sysenter_cs =3D vmcb->sysenter_cs; > + data->sysenter_esp =3D vmcb->sysenter_esp; > + data->sysenter_eip =3D vmcb->sysenter_eip; > data->shadow_gs =3D vmcb->kerngsbase; > data->msr_lstar =3D vmcb->lstar; > data->msr_star =3D vmcb->star; > @@ -512,11 +506,14 @@ static void svm_load_cpu_state(struct vcpu *v, stru= ct hvm_hw_cpu *data) > { > struct vmcb_struct *vmcb =3D v->arch.hvm.svm.vmcb; > > - vmcb->kerngsbase =3D data->shadow_gs; > - vmcb->lstar =3D data->msr_lstar; > - vmcb->star =3D data->msr_star; > - vmcb->cstar =3D data->msr_cstar; > - vmcb->sfmask =3D data->msr_syscall_mask; > + vmcb->sysenter_cs =3D data->sysenter_cs; > + vmcb->sysenter_esp =3D data->sysenter_esp; > + vmcb->sysenter_eip =3D data->sysenter_eip; > + vmcb->kerngsbase =3D data->shadow_gs; > + vmcb->lstar =3D data->msr_lstar; > + vmcb->star =3D data->msr_star; > + vmcb->cstar =3D data->msr_cstar; > + vmcb->sfmask =3D data->msr_syscall_mask; > v->arch.hvm.guest_efer =3D data->msr_efer; > svm_update_guest_efer(v); > } I think we should merge svm_save_cpu_state/svm_vmcb_save into svm_save_vmcb_ctxt and similarly for svm_load_cpu_state/svm_vmcb_restore into svm_load_vmcb_ctxt to avoid having multiple functions as a part of the same logic. That could be done in a separate patch (or series). > @@ -1720,12 +1717,9 @@ static int cf_check svm_msr_read_intercept( > > switch ( msr ) > { > - /* > - * Sync not needed while the cross-vendor logic is in unilateral= effect. > case MSR_IA32_SYSENTER_CS: > case MSR_IA32_SYSENTER_ESP: > case MSR_IA32_SYSENTER_EIP: > - */ > case MSR_STAR: > case MSR_LSTAR: > case MSR_CSTAR: > @@ -1740,13 +1734,15 @@ static int cf_check svm_msr_read_intercept( > switch ( msr ) > { > case MSR_IA32_SYSENTER_CS: > - *msr_content =3D v->arch.hvm.svm.guest_sysenter_cs; > + *msr_content =3D vmcb->sysenter_cs; > break; > + > case MSR_IA32_SYSENTER_ESP: > - *msr_content =3D v->arch.hvm.svm.guest_sysenter_esp; > + *msr_content =3D vmcb->sysenter_esp; > break; > + > case MSR_IA32_SYSENTER_EIP: > - *msr_content =3D v->arch.hvm.svm.guest_sysenter_eip; > + *msr_content =3D vmcb->sysenter_eip; > break; > > case MSR_STAR: > @@ -1940,11 +1936,11 @@ static int cf_check svm_msr_write_intercept( > switch ( msr ) > { > case MSR_IA32_SYSENTER_ESP: > - vmcb->sysenter_esp =3D v->arch.hvm.svm.guest_sysenter_esp = =3D msr_content; > + vmcb->sysenter_esp =3D msr_content; > break; > > case MSR_IA32_SYSENTER_EIP: > - vmcb->sysenter_eip =3D v->arch.hvm.svm.guest_sysenter_eip = =3D msr_content; > + vmcb->sysenter_eip =3D msr_content; > break; > > case MSR_LSTAR: > @@ -1970,7 +1966,7 @@ static int cf_check svm_msr_write_intercept( > break; > > case MSR_IA32_SYSENTER_CS: > - vmcb->sysenter_cs =3D v->arch.hvm.svm.guest_sysenter_cs =3D msr_= content; > + vmcb->sysenter_cs =3D msr_content; > break; > > case MSR_STAR: > diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c > index e583ef8548..76fcaf15c2 100644 > --- a/xen/arch/x86/hvm/svm/vmcb.c > +++ b/xen/arch/x86/hvm/svm/vmcb.c > @@ -97,6 +97,9 @@ static int construct_vmcb(struct vcpu *v) > svm_disable_intercept_for_msr(v, MSR_LSTAR); > svm_disable_intercept_for_msr(v, MSR_STAR); > svm_disable_intercept_for_msr(v, MSR_SYSCALL_MASK); > + svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_CS); > + svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_EIP); > + svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_ESP); > > vmcb->_msrpm_base_pa =3D virt_to_maddr(svm->msrpm); > vmcb->_iopm_base_pa =3D __pa(v->domain->arch.hvm.io_bitmap); > diff --git a/xen/arch/x86/include/asm/hvm/svm-types.h b/xen/arch/x86/incl= ude/asm/hvm/svm-types.h > index 051b235d8f..aaee91b4b6 100644 > --- a/xen/arch/x86/include/asm/hvm/svm-types.h > +++ b/xen/arch/x86/include/asm/hvm/svm-types.h > @@ -27,16 +27,6 @@ struct svm_vcpu { > > /* VMCB has a cached instruction from #PF/#NPF Decode Assist? */ > uint8_t cached_insn_len; /* Zero if no cached instruction. */ > - > - /* > - * Upper four bytes are undefined in the VMCB, therefore we can't us= e the > - * fields in the VMCB. Write a 64bit value and then read a 64bit val= ue is > - * fine unless there's a VMRUN/VMEXIT in between which clears the up= per > - * four bytes. > - */ > - uint64_t guest_sysenter_cs; > - uint64_t guest_sysenter_esp; > - uint64_t guest_sysenter_eip; > }; > > struct nestedsvm { Reviewed-by: Teddy Astie -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Thu Jan 22 18:17:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 18:17:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211804.1523265 (Exim 4.92) (envelope-from ) id 1vizEg-0008VG-Vp; Thu, 22 Jan 2026 18:16:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211804.1523265; Thu, 22 Jan 2026 18:16:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vizEg-0008V9-TF; Thu, 22 Jan 2026 18:16:50 +0000 Received: by outflank-mailman (input) for mailman id 1211804; Thu, 22 Jan 2026 18:16: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 1vizEg-0008V3-4d for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 18:16:50 +0000 Received: from mail137-14.atl71.mandrillapp.com (mail137-14.atl71.mandrillapp.com [198.2.137.14]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 810eb9d4-f7be-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 19:16:43 +0100 (CET) Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail137-14.atl71.mandrillapp.com (Mailchimp) with ESMTP id 4dxq5Q17plz705dyx for ; Thu, 22 Jan 2026 18:16:42 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id ecdb8f901ab34e0a87328af724903adc; Thu, 22 Jan 2026 18:16: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: 810eb9d4-f7be-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1769105802; x=1769375802; bh=JoYuU3kUMVAPly9sxksBrdZ8lh3xNFymYZevUba/wUE=; 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=YeyXRfD+KpwEGi/ICOiElW1uQkB67mDZSVORMFJqEadZLfSg8GgqWKpOebJAkafOZ pQcshxbfUeTHBmWIiHvlz0urXq0iIilIci159PDQCjmTKrfcdRspwf0aegB3jSTlLi IlNnWgCIOufSOD4H0AXd4xVKotJDM4Bq5WcxXw891XsWZcTB8dKdZjndWA6Y4nad9v USiIZWqmwwCw4IoZPAEosI0t43SNXdK/9NBDnylWdGtd3vKNX1y0v9d0EvEi4h9Zei E1v7gxXMwalmfZY7rUpsa7Lno66nre7P1M6oKpd32IkLJ3IeN71agtfh9nrdntxLFb py6zpsLqIwbYA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1769105802; x=1769366302; i=teddy.astie@vates.tech; bh=JoYuU3kUMVAPly9sxksBrdZ8lh3xNFymYZevUba/wUE=; 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=mPDjMIR61UdDZNUzidRzPONVI9Dy+zPnQi3x9B5mj+WCgga0VA6ENeM3p1oTClV47 dVLMtM0NuG5xlxt3IIaqZ2CNcSSnlLPNVsOqQ/vZy+iGWLyErfTcfuZC0eIVeTq4ik T1t/Mitc686zr6S7dGBaCx9/rePxFpVh9eGg/rYBhwDiGWp271wIqVlqRBoKNEjzOA 8UrUHTE04J21zvUDsQUYODLSP2iIN0WEv1V5QqckaXxAQuZyyNQ6ZhkjH3fkQXeb+z 19C7RLHfHcSTWeKYWiJ3ZflrZGJk+Idntiws+TIciO0SAu6zO3gYcjQcFu3gha3bQH RnPn431S+8dEA== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=200/4]=20x86:=20Drop=20cross-vendor=20support?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1769105800692 Message-Id: <26c416ea-1c4b-464a-bcb9-d34f0600eaac@vates.tech> To: "Alejandro Vallejo" , "Andrew Cooper" , xen-devel@lists.xenproject.org Cc: "Oleksii Kurochko" , "Community Manager" , "Jan Beulich" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Jason Andryuk" References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <3421e525-fb04-4306-9320-4fa359c2ee28@citrix.com> In-Reply-To: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.ecdb8f901ab34e0a87328af724903adc?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260122:md Date: Thu, 22 Jan 2026 18:16:42 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 22/01/2026 =C3=A0 18:44, Alejandro Vallejo a =C3=A9crit=C2=A0: > On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote: >> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote: >>> Open question unrelated to the series: Does it make sense to conditiona= lise the >>> MSR handlers for non intercepted MSRs on HVM_FEP? >> >> I'm not quite sure what you're asking here. >> >> ~Andrew > > The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as= far > as I can tell. The question I'm asking is whether there is another code p= ath > that might invoke MSR handlers for non-intercepted MSRs. I can't see it, = but > I'm not sure. > > If there isn't I'm considering (conditionally) getting rid of them. > I think you can enter this path by making the guest execute directly or indirectly a rdmsr in a emulated path (there are some cases like certain cases of real mode or maybe vm introspection). I don't think that FEP is the only way to do that. > Cheers, > Alejandro > -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Thu Jan 22 18:19:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 18:19:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211812.1523276 (Exim 4.92) (envelope-from ) id 1vizHA-0000mv-At; Thu, 22 Jan 2026 18:19:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211812.1523276; Thu, 22 Jan 2026 18:19:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vizHA-0000mo-8G; Thu, 22 Jan 2026 18:19:24 +0000 Received: by outflank-mailman (input) for mailman id 1211812; Thu, 22 Jan 2026 18:19: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 1vizH9-0000mi-Hw for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 18:19:23 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id dec8b3bf-f7be-11f0-b15e-2bf370ae4941; Thu, 22 Jan 2026 19:19:21 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA1PR03MB6372.namprd03.prod.outlook.com (2603:10b6:806:1b7::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Thu, 22 Jan 2026 18:19:17 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Thu, 22 Jan 2026 18:19: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: dec8b3bf-f7be-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=v13M2o3Djim5y1tvys3+kvBGqmRD8niad0fvlJgsBeSBeNsxDeVQkf8wQBng++px4o7udDvqFbGCeT4ivrZ4H942/JwwydYpQ9A92Fu+RvBBXbyVjI5djOjGF9JX5VhW9sx87BvXQY5Ph4gqM4IHtkO46NWcz7GL8HzG54kR+C/tgC9V5rCKemz/LV55ruakn5GnjsLFMKZnYWZA/Fjl7dOtaeU0ULBuc/ZXOZWZhhmC5BvfnJDRmRywtk8G9J0lPF4EPoACSbQcCQPctUTY+zrGSC+JEcOBYPTTt1ug9cYu1yhqRdRhgk+ZxL5Qtog72A/RXrd2Zj3JoxHEN24BQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CxWeTEFuMzuKeWWjvbQ9SgcNKKg8lO+lVkE8QGD6n9w=; b=fmmNV9adyfCJlbNQXCPgkpt42SVDaetchZzH2kRs2AsDxGzNkSnjG7hKQmHEzZnvw+tjCl+vJenzgw2j6Rl+WbqY2L+T7uI3E5oKfitjmiuCl8j9CPJZT3qSvx8pY5m0jS60P8OTpFos+bUgKj1j34FRWqRum4aOSlyHbjwq++KgDz7AAYAnM3/7+n1SlRxjqlew/Q3tSLrKkWnXD+xJyAHaIR2TX1n/B1fGyTCFPw2+IXzNAJRmfZpz1c0PL/CjM8StxW72ZirpX/9TWUgy/GfNj2irQ1ZwrtqKxWizXoVJs2wW3gyeKhb/XgMnJHlKY3piJPbzYPwCz6tmoFpShA== 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=CxWeTEFuMzuKeWWjvbQ9SgcNKKg8lO+lVkE8QGD6n9w=; b=0AgqedBvVMCd6PbSNwepJwgFVrDzfJDHJPy4/nmv03NhQ/D2ZxUhKh8HiCdDizCei4lpJah+lKtR/g12kOne0x6ciyK56TW8MrJAYERcVuT+OQIvhITTxidy7iWQ884Jxf9MyqD6HKdD0tgmSGFfUlXbsGA9mmI0BuyHZMSFXJ4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <6d41d205-7318-45e4-a487-5e35e398d96a@citrix.com> Date: Thu, 22 Jan 2026 18:19:12 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Oleksii Kurochko , Community Manager , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk Subject: Re: [PATCH 0/4] x86: Drop cross-vendor support To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <3421e525-fb04-4306-9320-4fa359c2ee28@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0334.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a4::34) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA1PR03MB6372:EE_ X-MS-Office365-Filtering-Correlation-Id: 97394931-2c9e-4c7b-90c4-08de59e2c138 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?bzNodDZiQm8wOVFUZW1RZVBqQWZRakxndTl2QzhxYW5wNTlkR1RnTWphWFBZ?= =?utf-8?B?OWRrVkk0TjJLMGgzWEdRRmdjNnphdCtDVlQyTUpYOWpNd3ZORTNTbWJDNDRV?= =?utf-8?B?bGR6TzB1RXR6b0RYTDcxWmVRR2h0SGpnWkxoelNDaEU3bmRibTdaaEg1RXpT?= =?utf-8?B?SXRJbkg0b040Qnd2a08veWJJSlU4OXg4Q2RKRkRUalNCV2FsYXNmUnBvQ1Vi?= =?utf-8?B?L05sTE5MN3U2ZnQ1RDU2RE1pYmdvWW1qYWsyZTdhNHcrbk1yOXlETHZSSXVK?= =?utf-8?B?NDllVkFEK2ZUTjdoVjBuZUhIUkt6cDdrbm8xVUx3d0J3d3BQcDZoaEpQRnRO?= =?utf-8?B?ajQ1RzkzZDE0SEpQWnpOdXhxOUxkTGF4NVVoNDNsL0gvTEM3S1YvOE0vM25S?= =?utf-8?B?QUwwLzI1WkZtK0UwYWpBS1hGRVJ6cWRJTVdDMEVsVDd0RHRPbDFKcVB4ekJR?= =?utf-8?B?Sm9CaHNQVmR4VTBiRDBPc1R4TjFnVmdoQUxKODQ5V1lCTlQ3cy83VDB4dmlY?= =?utf-8?B?UjVaZDJoR2FSR1RkQ0ZzU0M4cHVKMzN0ZmRad0M3ajZ1NEF5ai80S0FwTVNj?= =?utf-8?B?MzA3UnNGbWVDa0QwYnN6QmIvMTIxT0k5QlR5UVVWUkdHRVNha1pXbi9oL3pS?= =?utf-8?B?Y3JKYU1pM0pmK3BjVGVQeFBMWEc3T1ArNE5YZDhIbEFIQ0xpc2pVUVFsRjQv?= =?utf-8?B?TTM4cEw2bWxBeXhDUTd3MStKM1FiSEdSZUZRZXBBTGo1THptWUlJMHRva1ZJ?= =?utf-8?B?Y0svdHp1Q0srVmxqZEdVam1NYVFvRkZ1OVhxdDV5QUoyYUdMOWlPNDFVWmJr?= =?utf-8?B?SDVjWElmcHNESDN6RkN6ZWllakt5WVpZL0FHbzNMcUZybVk2Ni9hN2xwclBV?= =?utf-8?B?dEZDYjYvNHUzSW45dW5Ya2ptV3lTZ0p6NUhFSWdVc3IyZWdVaSt0TUcySmY0?= =?utf-8?B?enFQY0hGbjQ0TzRPNW1NOVU4Y0V6UkNNMzNTODdxQzN4TDUxYmFjbTZEeTJY?= =?utf-8?B?Z2g3SmR1K0l4TFA1Y1hvTFlCSlVQOE80VXN1YTdYaW9JcmtkQXZHcXNYdXNk?= =?utf-8?B?TzNhR1IrNXRZNVllZjFJRDVLMjFzY1pKejVKVk01S21WSWZxSFRvTFJWOWtH?= =?utf-8?B?dzM4SnhyYXNnbmoxNFdGSkNoRzVpdmh1cVhnTlBteHR3MVYwMzNYY2c5azU1?= =?utf-8?B?ZUVnNk1GcWY0Y1Fic0tDTDZzYnZGYUJiak1mL0F3ZUZUeU05bHA5ZDhpMGti?= =?utf-8?B?RVZuVTljYlVuYmlDdUFkM3Vib3kwK2tUVUE4VXZVOTNNU0x1RnpOSzY3L2Ji?= =?utf-8?B?emNKaTEvSDl5czlocXhaZmlGWE1QWFI4Q05vRStMT2I1dGdZcHMrcjBpdU1E?= =?utf-8?B?UFVOVjZLckMzM1BQc1ExMndJSEdlYmE0ZGovU0VlRzN1WkFwckhxb2RQQVdE?= =?utf-8?B?cE9IcmJwZktlTkh0dHMzS3BoclA0VmdVNlNDYnp1ZXRDdTBRTldJaVlmVzkx?= =?utf-8?B?clUzemJnMy9iWnhWdlVYR2lIRUFLTHM5QmxTZzJWR254RStoSkowZzNHTGVk?= =?utf-8?B?V01rZXMxczk0VEJTQzFpN3N2UHN0VWZQQUd3Mll4Lzd3Y3YrcTk1VUUyYWVi?= =?utf-8?B?MjFteC9lUTJOOFl4dnpWS1NQRjhWN2RQWGwrT2dROTl5UU51ME9weW1MZXUw?= =?utf-8?B?ZXVQbmhNV3l5TjJyV21kUjczNjU0RlRjYzl1QUFIUXlhenRsaVpmdXk1Rzdl?= =?utf-8?B?bjgyWVJmcm1xMHUya3VhNWZFUEZFQm5DU0RQeG9BUWUwMDZaSGtnUjFpb0xZ?= =?utf-8?B?bXZtazhvWENGUVo4R25sd2Zqb2FYaStuVkg5dGtRRGlmTkdWdk5zWTBPaHF4?= =?utf-8?B?aUhZYXkrQ0N5cjdma1NDbkJTN2NOUGh5UmtjSEFrbjdxQTdtWDdKMWJvZ0JM?= =?utf-8?B?STFiUjJBQXQvdjRGYk1JbTBueWNxTDFEUGdwK0hYV0RCR3l3aWRGbnZIU1d1?= =?utf-8?B?NkVnS1dCcDA5MVNXSHF3QXRreDJ3eWNMdXk3clFPZUgzZlpPZmNmL0x2UzNG?= =?utf-8?B?WlpiZU85bk04SVFpTUZpUEJNTGVQYWZZQVZSUzNIVWpOTFN5czlaTURkUnZC?= =?utf-8?Q?NS84=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bTB0L3NLclR1bGgwbFJMKzNSM05pbTlMZnNaSFNWL1Y5aERFbGM0ZDhXZHpJ?= =?utf-8?B?YytPSFhLb0R5NlF2Wkp0VGRWTzdOVGE2ZEx5YjZLdnNHM1BNbWFCWmMyNDE3?= =?utf-8?B?OW9rM21mTklzL0MyemxvTjFtZ1FGMHFPM3dFcUMydHJRQnUrSFc3VXFkd1VH?= =?utf-8?B?L3dFTU1qZDMxOGZSdW5nWGFEaEVZS1YxQngzOVRHWXg1Y2NSMStNT0Vvc081?= =?utf-8?B?Snd2Szl5eVVzTHBES0hXRGlvdS9ibnFVbjVYMlNaaCtuWmdhQUg5MEx5dG0z?= =?utf-8?B?akY0MW8vWmk4dTcvbzFXc3dKRWgxWjBJYVp2Syt4aERCMWVPL3BSY0twSVZD?= =?utf-8?B?YVoxSWlPVUFORnVicUtqakVYVm1INnk2OTRhNXJ3NHpWb1daWk9oUk1XTm9o?= =?utf-8?B?WGNzMUJtdWxzVjdlaGpKeEdja3JVd1M1TWtjMzg3U3FBcjdpeDJPMnJxQzZF?= =?utf-8?B?TVg5UHUwQU8yS3lja1lkOWR2WlYyQjhLdUFCV1dXT0R5N09CeUNPUFNOYzhl?= =?utf-8?B?SVJaZFdicElsQlV4clllL1FCc3FFQVYwaSs4QVhGbG1YbkdoekV6SkNTbWE0?= =?utf-8?B?QVdmRkxxOTZDMHZ5UElQVEFEdXZoT1hsQVZOTmp0NTFOQnpWNitXeFU3NkJJ?= =?utf-8?B?Q25pOGRoaTdjZWlCWm5TMTYwZnh0N3N0TFFrOEdxZkpwakxEa1hiNzZwUlZx?= =?utf-8?B?NDdnaGRlK2UxdFhpM3hNNHhuc3ovUE4wRUpYZlV6ZE9kaUFuNEh1VFQxTDNj?= =?utf-8?B?SHNmMm9tOFNNcFByQUMzMTJ0MnZkZjNBUk5zV0NMRkdVOFdWS0JYZ253NFhx?= =?utf-8?B?d1Bmc0Z5VFl3RWlYcDh0djA1M25MVVRvT1JYcWkzcGFsNk5DbGxpbTB4SVVz?= =?utf-8?B?YWpIaGNHakNNVFA0Nmc3TlVDcWFQaVRENU4rcXFwb05ISy9iUkxkU3owQ0dj?= =?utf-8?B?WWNoQ2JIdWkwTVNMeEYrNmRGVGhDaWR1ZzRZS1JLVm9lMnNUdkNiU2ZaMmxk?= =?utf-8?B?THh6S0JtcGYwZjBSb3hvd1RyeUJDRkcybm5lVjdNSDloMjhIb3BFNkJFcFZy?= =?utf-8?B?d01OTUlmeS81RXJMbG84MDlRV0czWG5yclNGSzV1WUVCZ2FtamorRE5vVG8y?= =?utf-8?B?Mk5KRk0rUmtuY1E4QjlqZjFZK3FnUVZpRWxWS2czcnp1VGFHYUtmYk1SRjRZ?= =?utf-8?B?dU41bVhHVnJYRGFuaHZmcHFwWHNJUENJQUMvb3k1TENoOFVZbmJRTVlVK3h0?= =?utf-8?B?T21xMVV3YmlnbzVHbVpyMUZaWEt1YlVDajlPak1rVUVyc24xelVOTTlscXBY?= =?utf-8?B?ZjB0R0ZHRG1BTnVoTEswbmREbjUvVGk0YmlyOFVpc0lGclpWaUo2T2Y5RHUr?= =?utf-8?B?MFVtSXdHclVUbk1hRXloODlnbWxmZ3hNNUxVOXRvcVRmUWljNE4xSXlsYUgw?= =?utf-8?B?cDNoUGlNRldidnUvVWQ1aTJyWnZiYlhDZ2g4Zzl4ZjRVeklyd2FIS3ByY1R2?= =?utf-8?B?bFZPY050ZGwrNkhhVlBwbmkxN2p0OXNTeW5KSCtHRVBYOGlybG4zT2NId0dy?= =?utf-8?B?Mm9HU2M3T3lQWlRjOEJIK25qRDdLQ2x5QnJFRCswUjlyTFZ0WVNXOWxQK3Y1?= =?utf-8?B?cDlYU2E3ZGljT3U1OUJYTXdGcHd4ZTFVRmxmMG1IUS8xMk5iRlNkSG9xTmVE?= =?utf-8?B?dy9KN2E2eTRqdkdTSGJEb2FhQ3R3SkR4cVZBQ2JrYlZScUhId3d4ZjlkdUdN?= =?utf-8?B?MTZTT2FlcnMzWjFETzROUWV1ZS9nbU9VSVpPc3ZseHF4djhoVkwzOTFTekF6?= =?utf-8?B?MkRncWlZOGl1ZkhFZ1AyYytQOHRMSWE5UVlCLzAwRkUvclJIc2xsbGFEU0E0?= =?utf-8?B?ZUs1aWh2NG9VQm5KSVlXa3VuTmVIWW94OG9aOXRhTFRaU1d6OHRGcHZuVDRt?= =?utf-8?B?Z25UbnhuUXh1YXJZNXdCVmw4ZzUySEpTWTRaYzJINFZwazdaMWxiRTlQcmxw?= =?utf-8?B?d0MzR0luM0FDblpsaHZPWTY5L0pzWTRuRTR5eUwreCt0VUVEM2g5enFSV3py?= =?utf-8?B?MmZ0dVgxMnBtT3RqZ3YzZzc1QkxISzZxbUpQank5MDBCQUMwQ3pCaXZHUWs2?= =?utf-8?B?U2V5VkRvM2l5NkNKVWN6ZlQ4NkJuaU45MmQ1WVNMcjEyWVRNUUhJbTJNa0pU?= =?utf-8?B?cGFRQmJ0QVh6V3B0L1hRQUpnaXo0aDZreWVZcU5RVmUrU3dGMXEvZmt3NTFN?= =?utf-8?B?Mi9JMHJ3UGVHOEZNOVlPYVprRlVNR2tOY1g1NHNJaUpkWS93bUQ4c292M2pZ?= =?utf-8?B?SU1ZWW9FRjRLbWZaUnFmWWtYWTN1ZHdnbnovRFFSeVlKQ05nWk1Vdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 97394931-2c9e-4c7b-90c4-08de59e2c138 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2026 18:19:17.3155 (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: V0VsweVFNmxsZMVaLRu4NFAzdp6Cjw572Z/9+BepWZWZ7ZdIbp6x/143JdMbiw0+R6pwUuYG3qElql950/6vrWtq5VG7W6JAzIokNNfOL/A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR03MB6372 On 22/01/2026 5:42 pm, Alejandro Vallejo wrote: > On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote: >> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote: >>> Open question unrelated to the series: Does it make sense to conditionalise the >>> MSR handlers for non intercepted MSRs on HVM_FEP? >> I'm not quite sure what you're asking here. >> >> ~Andrew > The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as far > as I can tell. The question I'm asking is whether there is another code path > that might invoke MSR handlers for non-intercepted MSRs. I can't see it, but > I'm not sure. > > If there isn't I'm considering (conditionally) getting rid of them. Introspection can (and HVMI does) hook them.  Changes to LSTAR during runtime is usually an exploit in progress. Nested virt also makes it far more complicated to reason about "intercepted or not", given that there are multiple opinions merged together. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Jan 22 19:22:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 19:22:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211843.1523287 (Exim 4.92) (envelope-from ) id 1vj0Fq-0000js-RY; Thu, 22 Jan 2026 19:22:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211843.1523287; Thu, 22 Jan 2026 19:22:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vj0Fq-0000jl-MM; Thu, 22 Jan 2026 19:22:06 +0000 Received: by outflank-mailman (input) for mailman id 1211843; Thu, 22 Jan 2026 19: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 1vj0Fo-0000jf-V4 for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 19:22:05 +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 a121cbee-f7c7-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 20:22:02 +0100 (CET) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-b7cf4a975d2so184928066b.2 for ; Thu, 22 Jan 2026 11:22:02 -0800 (PST) Received: from ?IPV6:2a00:12d0:af5b:2f01:4042:c03:ce4d:a5a1? (2a00-12d0-af5b-2f01-4042-c03-ce4d-a5a1.ip.tng.de. [2a00:12d0:af5b:2f01:4042:c03:ce4d:a5a1]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b885b416ca5sm9483466b.25.2026.01.22.11.22.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 11:22:01 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a121cbee-f7c7-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769109722; x=1769714522; 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=nmPjBRhiPHTLitYdZuZ8tZAWa12nzlVHGonpdfvcEaE=; b=EcLFHx/t51ghyNVbD41ToGRFc5fDqDV+skszmjuuCUIpIqotYYq7UxuCoM3jD9S/XB 6ujnSGwBtHFCTjqO//cKo+nDfgrLyQ/Vu2oh4B7c6VLkFMGjZc1cEgOXvZMoVMLIpSPE FB5Of/aD4ppmTKIo20AJCbXwhCRLisLn7rIbQShqk1fkvTZrRWp2bVSYDlkSX5wRINbh juyejd8HwvDOIAgHex1oaqjs7K8PnB1Ex163Ov3/xXF1L133lozFlky3OnEZj7y4dyH+ L7qwsEfM+HWIv3DMxKEq/N8CmR7wM/kgmWyxPSDSFnZxjxkD8iDfw/zx5bIxKIxF6p1y PcAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769109722; x=1769714522; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nmPjBRhiPHTLitYdZuZ8tZAWa12nzlVHGonpdfvcEaE=; b=WChr/05XQiKHLpDo4qUCecrswnU7HNXl2ogCBXTjyzZOcd282KSVmUHZrIR6o+FTS6 LLwmrjeJqvlxm/+28Q97x7VG2GipG6EW9CfUyyP8a4KLYWFvZCTSnUDwTA7aS2MOvaxr qTXPw9ASi6e0ODPRE65+pwNmfBAdjaq4o08BHtB3kynjl08ijVst1c6Lv9Q5594c6/OR 36N//Sli1+Bfa/ktXRLtJgBBUyHwop1GIVNa3Bdf9IIauYzsAC2aYPA3IYqMw1N0DeKR 9aZJONtjinovjzKQk4DyUaQx2aFtASkwGqXKD84zmbgur7R0eAsHNB/7ksYnPpJ9Zszk iSKg== X-Gm-Message-State: AOJu0YyCIP/C2nKS17KkNZb3hZvwN1FrtoO2QoJDKohadRkKyN98D2+t hSni9B2E90AJf1stb+12w2m7fSbK0xWHYCJuTuFOOsFzH++ugHwxVmoEoT3SiokY0pIjCXpi+E7 MmeQEG8I= X-Gm-Gg: AZuq6aJOjmx8MdqlhX8jtcpbcjTqXTc/i9gJE9wZP34RcXMqh0ThFDSjdTcoOIarOou 8cS8xhFlRdY0ukouCVhCao7K9Y7WOk8kjPu7Q6l4XSNORKMyVZMzrC3IbZmGgDmcwvxKA3NrYpX oF7/0usg1D2D3WosGKL/TYwXHKry4A319i4p7Ka2rLx2n9RkX+BJalNaR9K9yMv1kbs1yHO/8EI IMNmHDaYdgnTKH91kNClRd5dH6PJJ0844TBAGUgMpYQBbmkdlhmEf6khkhvOSVTv4R7eE4yENlL 8xQ/9KqJsWucvv65OYO5g7mttE+4SxFusPe6ktlUvk6CpecEyBd+Ss7Lkq7o3AOJch0Ao8qWgF5 5/CKJ1t7rr66aQ8dpN20xoCMunvNsoxXYjR6G8EtliVG11SIKgwXOu7U1TSL7TOCvrqmlpeVAGy q9DFEuLPjACYe8RJX2ZH/65+jJDcxF4owBpSWiOHpwpINOjqPJVWuyCTKcGC40YgxjqT7UzJRft ym0BMlR9kElK9cSTpoISkf1YNmI31oClqMt2g== X-Received: by 2002:a17:907:26c6:b0:b87:117f:b6f0 with SMTP id a640c23a62f3a-b885ae0baa4mr23875666b.30.1769109721655; Thu, 22 Jan 2026 11:22:01 -0800 (PST) Message-ID: <4c8f31d3-4246-4c9b-bed4-0e060b3c5058@suse.com> Date: Thu, 22 Jan 2026 20:22:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: MTRR init sequence in Xen To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Jan Beulich , Andrew Cooper References: <145af46c-eab5-4d0f-ba35-4ae646c0e4cd@suse.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------53bgMz6Kb0942bM930M38kiV" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------53bgMz6Kb0942bM930M38kiV Content-Type: multipart/mixed; boundary="------------Cs0tu4503ulq3qQJC78SKmT4"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Jan Beulich , Andrew Cooper Message-ID: <4c8f31d3-4246-4c9b-bed4-0e060b3c5058@suse.com> Subject: Re: MTRR init sequence in Xen References: <145af46c-eab5-4d0f-ba35-4ae646c0e4cd@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= --------------Cs0tu4503ulq3qQJC78SKmT4 Content-Type: multipart/mixed; boundary="------------0K9eVabg3V5vBfhORpi7CSo1" --------------0K9eVabg3V5vBfhORpi7CSo1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjIuMDEuMjYgMTg6MTgsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIFRodSwg SmFuIDIyLCAyMDI2IGF0IDA0OjU2OjI0UE0gKzAxMDAsIErDvHJnZW4gR3Jvw58gd3JvdGU6 DQo+PiBKdXN0IGFzIGEgaGVhZHMgdXA6IGEgaGFyZHdhcmUgcGFydG5lciBvZiBTVVNFIGhh cyBzZWVuIGhhcmQgbG9ja3Vwcw0KPj4gb2YgdGhlIExpbnV4IGtlcm5lbCBkdXJpbmcgYm9v dCBvbiBhIG5ldyBtYWNoaW5lLiBUaGlzIG1hY2hpbmUgaGFzDQo+PiA4IE5VTUEgbm9kZXMg YW5kIDk2MCBDUFVzLiBUaGUgaGFuZyBvY2N1cnMgaW4gcm91Z2hseSAxLjUlIG9mIHRoZSBi b290DQo+PiBhdHRlbXB0cyBpbiBNVFJSIGluaXRpYWxpemF0aW9uIG9mIHRoZSBBUHMuDQo+ IA0KPiBEbyB5b3Uga25vdyB3aHkgeW91IGdldCBoYXJkIGxvY2t1cHM/ICBJcyBzb21lIHdh dGNoZG9nIHRyaWdnZXJpbmcgb24NCj4gTGludXg/ICBPdGhlcndpc2UgSSB0aGluayBpdCBz aG91bGQganVzdCBiZSBzbG93LCBidXQgdWx0aW1hdGVseQ0KPiBzdWNjZWVkPw0KDQpUaGUg Tk1JIHdhdGNoZG9nIHRyaWdnZXJlZC4NCg0KPiANCj4+IEkgaGF2ZSBzZW50IGEgc21hbGwg cGF0Y2ggc2VyaWVzIHRvIExLTUwgd2hpY2ggc2VlbXMgdG8gZml4IHRoZSBwcm9ibGVtOg0K Pj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcvbGttbC8yMDI2MDEyMTE0MTEwNi43NTU0NTgt MS1qZ3Jvc3NAc3VzZS5jb20vDQo+Pg0KPj4gQXMgWGVuIE1UUlIgaGFuZGxpbmcgaXMgdGFr ZW4gZnJvbSB0aGUgTGludXgga2VybmVsLCBJIGd1ZXNzIHRoZSBzYW1lDQo+PiBwcm9ibGVt IGNvdWxkIGhhcHBlbiBpbiBYZW4sIHRvby4NCj4+DQo+PiBBcyB0aGUgaGFuZyBhbHdheXMg b2NjdXJyZWQgd2hpbGUgd2FpdGluZyBmb3IgdGhlIGxvY2ssIHdoaWNoIGlzDQo+PiBzZXJp YWxpemluZyB0aGUgc2luZ2xlIENQVXMgZG9pbmcgTVRSUiBpbml0aWFsaXphdGlvbiwgbXkg c29sdXRpb24gd2FzDQo+PiB0byBlbGltaW5hdGUgdGhlIGxvY2ssIGFsbG93aW5nIGFsbCBB UHMgdG8gaW5pdCBNVFJScyBpbiBwYXJhbGxlbC4NCj4+DQo+PiBNYXliZSB3ZSB3YW50IHRv IGRvIHRoZSBzYW1lIGluIFhlbi4NCj4gDQo+IEhtLCB5ZXMsIEkgdGhpbmsgWGVuIHdvdWxk IGJlIGVxdWFsbHkgYWZmZWN0ZWQgd2l0aCByZWdhcmRzIHRvIGJlaW5nDQo+IGNvbnRlbnRl ZCBvbiBhIGxvY2sgd2hpbGUgdXBkYXRpbmcgTVRSUnMuICBUaGUgTVRSUiBpbml0aWFsaXph dGlvbiBpcw0KPiBkZWZlcnJlZCB1bnRpbCBhbGwgQVBzIGFyZSB1cCwgYW5kIHNlcmlhbGl6 ZWQgb24gdGhlDQo+IHNldF9hdG9taWNpdHlfbG9jayBsb2NrLg0KDQpSaWdodC4NCg0KDQpK dWVyZ2VuDQo= --------------0K9eVabg3V5vBfhORpi7CSo1 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----- --------------0K9eVabg3V5vBfhORpi7CSo1-- --------------Cs0tu4503ulq3qQJC78SKmT4-- --------------53bgMz6Kb0942bM930M38kiV 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/Ey8FAmlyeNgFAwAAAAAACgkQsN6d1ii/Ey9V lgf6A5f+36CGTR7rDGgBdDsLJpaNdFuGIpld5DpC09/JYKNot0oZvyTyrVLwYK8chtk+SZPatMAE 5+XRnuc4/sN5z67tCWFAw+rdYrgWIVxedVMnHZcsqumbUHtKFsBU/cQP6wn9bp6hMGXxnUmOyGSL UOc+1lSbvYFTDdN/shY7og7MGvd0uYqSZCx+Ggz+2Kc3UvY7T2AHrna8vErlAKW+yDjH7KpjOlN9 92zuM2uEXSrlIqawdTD3u7OmYlj6Ui6lrJgEn9N8gPtA/wfVsa15UrikEmAm8NNLBxb/9nZcrgMj ot7PCaIMO90mgOAZVSuNV2MDajUsnxnIrUnJASrrtA== =YD0W -----END PGP SIGNATURE----- --------------53bgMz6Kb0942bM930M38kiV-- From xen-devel-bounces@lists.xenproject.org Thu Jan 22 19:24:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 22 Jan 2026 19:24:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211850.1523296 (Exim 4.92) (envelope-from ) id 1vj0Hx-0001FV-5G; Thu, 22 Jan 2026 19:24:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211850.1523296; Thu, 22 Jan 2026 19:24:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vj0Hx-0001FO-18; Thu, 22 Jan 2026 19:24:17 +0000 Received: by outflank-mailman (input) for mailman id 1211850; Thu, 22 Jan 2026 19:24:15 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vj0Hv-0001FI-F4 for xen-devel@lists.xenproject.org; Thu, 22 Jan 2026 19:24:15 +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 ef1b09d9-f7c7-11f0-9ccf-f158ae23cfc8; Thu, 22 Jan 2026 20:24:13 +0100 (CET) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-b885a18f620so32650166b.3 for ; Thu, 22 Jan 2026 11:24:13 -0800 (PST) Received: from ?IPV6:2a00:12d0:af5b:2f01:4042:c03:ce4d:a5a1? (2a00-12d0-af5b-2f01-4042-c03-ce4d-a5a1.ip.tng.de. [2a00:12d0:af5b:2f01:4042:c03:ce4d:a5a1]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b885b8011dfsm7507866b.70.2026.01.22.11.24.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 11:24:12 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ef1b09d9-f7c7-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769109853; x=1769714653; 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=rgCDhTXuBJXwPqbF6FpQHo5ADFTyYqE2io4DiR+xhoA=; b=E7WgmfR1LVtVn2zijTvS5qa7LxgLWAAVB6+jY/1WfO0Ymhm4V8Tvw0TrPnuI1oDQmN GFBMeTB8TfGDbhKqvQuAo5KtR71HxinOipdottpwM+8eZDQ5Bev+fEgeiRznDC5A6V8d GPZH90XfGyIne2tGasbqVSKb61rAXzahUFsnf4+gsXO27rjHdgFGf3FD5P190+cU+B+Q 7zncPkXq1UsQcjU0uedd8leryknKjTSxbLopEkY6VoqLCFteaLDlGhcfp6TQ9ZV7Qvr2 KN2qEus84La4JhF1+xVVrYRnhr+YjnOK0PJYqwTEl/NXCx/IMmGlpNZH9CeZoght1hPq VKTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769109853; x=1769714653; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rgCDhTXuBJXwPqbF6FpQHo5ADFTyYqE2io4DiR+xhoA=; b=cREKNbmfFSduZrklXXKGu1w5Zo7oq24i/eZqBbf5jpUUTAMmKWwVUom1ljHeUkgy1l koac3jJ3KItozAjsOC4KmszhJY3QkCwzTmeIZyKv1E6BKZtA4V6UKP8ChFKy1ntGCkT2 S3zDBWINo85UZfKyWWWEPHPVz4NAmZw3SLZj7KOTxufzYKuipoRHMqEhrDccew4Ztscw NbIuvDKuS8XnwWLYJxuRTGHpdr6e5qrkMs6aVbcyTVJyYfaYgE+GwcOznWYD+PFdCnyZ 2/1m3SRr9Jxjd/4c4gqo/b3+yf9P9SLUmG8nErDrrzvRBqTG7Z6LpgxSmXza83Bu3V4u OmFw== X-Gm-Message-State: AOJu0Yx/ZdgZDKFzA+R6NsdTQwmnD6ipNjnWIhbOQkT3jti6B1ZxApZ1 rfbGfzoun/zL5mfu9NrBUe5YVdQx/sICQdOEHLHxpMifnc1ld6OPWV8+dux+QR8nKl4= X-Gm-Gg: AZuq6aLK7Zj6O6mLEM29NzJg9Tby6/XuPTEdzUNDjpbLzypZMuQO5mp38k21CU3q+qz GLIT/WGNX7uvtDSmkiO4Gv+F6k4ebcbNyR2gJH1ojW/E4/QAXFPD9lUaB6zv3qZMjXSBBOlcJVH ecCSElLo9lgQ8m3RLGpxXVmnf5AvVdmnktZqubsa1i7XEwvADNY5Ne2fdonLGqBZvVWNZitybac 1aC7HOq4mzOuvqRg8JWkmvK61i3MqeqmwYOWJ6HkhV18YI+K1CUQyKo8ZGy/WpFULniu373Cslv cuzF+ATQKR1BvpHP+SjwcxqeUSIGWFqjGz4pjpEdvxrRY/BHPlavU6xK+nBwqcKYGC9wi/3GtwL HEXWNn5+NVsuf+Lxu9FTYYYLj9Atd8yB+Wxzyf44cSPIJW00eVa/iDYNyjGfNAu/K1uekYeo7mR 5TdBOsgZqPt2gKWF0ejU0Yb7Dq9Czvqvku49siw6vC134bdcVJh9wD7pdx5QOVQb0/irNFgXyCw nqx1vE1gpa/uRqzSh16fEcXBY1r01lOiHtp3w== X-Received: by 2002:a17:907:a04:b0:b86:fed0:2b with SMTP id a640c23a62f3a-b885ae65c13mr20487966b.32.1769109852583; Thu, 22 Jan 2026 11:24:12 -0800 (PST) Message-ID: <64adf935-1fd8-4d3c-b9b2-cafb0e065463@suse.com> Date: Thu, 22 Jan 2026 20:24:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: MTRR init sequence in Xen To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Andrew Cooper Cc: "xen-devel@lists.xenproject.org" , Jan Beulich References: <145af46c-eab5-4d0f-ba35-4ae646c0e4cd@suse.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------vMnlJv4EU0t2zQDeEsgLY4Hz" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------vMnlJv4EU0t2zQDeEsgLY4Hz Content-Type: multipart/mixed; boundary="------------mecoxbJo3Xbbj27VngaKsd0Q"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Andrew Cooper Cc: "xen-devel@lists.xenproject.org" , Jan Beulich Message-ID: <64adf935-1fd8-4d3c-b9b2-cafb0e065463@suse.com> Subject: Re: MTRR init sequence in Xen References: <145af46c-eab5-4d0f-ba35-4ae646c0e4cd@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= --------------mecoxbJo3Xbbj27VngaKsd0Q Content-Type: multipart/mixed; boundary="------------54x8dgl1JYW9AZapAtv7Om0J" --------------54x8dgl1JYW9AZapAtv7Om0J Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjIuMDEuMjYgMTg6MzYsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIFRodSwg SmFuIDIyLCAyMDI2IGF0IDA1OjIxOjEyUE0gKzAwMDAsIEFuZHJldyBDb29wZXIgd3JvdGU6 DQo+PiBPbiAyMi8wMS8yMDI2IDM6NTYgcG0sIErDvHJnZW4gR3Jvw58gd3JvdGU6DQo+Pj4g SnVzdCBhcyBhIGhlYWRzIHVwOiBhIGhhcmR3YXJlIHBhcnRuZXIgb2YgU1VTRSBoYXMgc2Vl biBoYXJkIGxvY2t1cHMNCj4+PiBvZiB0aGUgTGludXgga2VybmVsIGR1cmluZyBib290IG9u IGEgbmV3IG1hY2hpbmUuIFRoaXMgbWFjaGluZSBoYXMNCj4+PiA4IE5VTUEgbm9kZXMgYW5k IDk2MCBDUFVzLiBUaGUgaGFuZyBvY2N1cnMgaW4gcm91Z2hseSAxLjUlIG9mIHRoZSBib290 DQo+Pj4gYXR0ZW1wdHMgaW4gTVRSUiBpbml0aWFsaXphdGlvbiBvZiB0aGUgQVBzLg0KPj4+ DQo+Pj4gSSBoYXZlIHNlbnQgYSBzbWFsbCBwYXRjaCBzZXJpZXMgdG8gTEtNTCB3aGljaCBz ZWVtcyB0byBmaXggdGhlIHByb2JsZW06DQo+Pj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcv bGttbC8yMDI2MDEyMTE0MTEwNi43NTU0NTgtMS1qZ3Jvc3NAc3VzZS5jb20vDQo+Pj4NCj4+ PiBBcyBYZW4gTVRSUiBoYW5kbGluZyBpcyB0YWtlbiBmcm9tIHRoZSBMaW51eCBrZXJuZWws IEkgZ3Vlc3MgdGhlIHNhbWUNCj4+PiBwcm9ibGVtIGNvdWxkIGhhcHBlbiBpbiBYZW4sIHRv by4NCj4+Pg0KPj4+IEFzIHRoZSBoYW5nIGFsd2F5cyBvY2N1cnJlZCB3aGlsZSB3YWl0aW5n IGZvciB0aGUgbG9jaywgd2hpY2ggaXMNCj4+PiBzZXJpYWxpemluZyB0aGUgc2luZ2xlIENQ VXMgZG9pbmcgTVRSUiBpbml0aWFsaXphdGlvbiwgbXkgc29sdXRpb24gd2FzDQo+Pj4gdG8g ZWxpbWluYXRlIHRoZSBsb2NrLCBhbGxvd2luZyBhbGwgQVBzIHRvIGluaXQgTVRSUnMgaW4g cGFyYWxsZWwuDQo+Pj4NCj4+PiBNYXliZSB3ZSB3YW50IHRvIGRvIHRoZSBzYW1lIGluIFhl bi4NCj4+DQo+PiBJIHN1c3BlY3QgWGVuIG1pZ2h0IGJlIGluc3VsYXRlZCBieSB0aGUgZmFj dCB0aGF0IHdlIGRvbid0IGhhdmUgcGFyYWxsZWwNCj4+IEFQIHN0YXJ0ICh5ZXQpLCBzbyB3 ZSBkb24ndCBoYXZlIHRoZSB3aG9sZSBzeXN0ZW0gY29tcGV0aW5nIG9uIHRoZQ0KPj4gc3Bp bmxvY2sgYXQgb25jZS4NCj4gDQo+IE9oLCBJIHRoaW5rIEkndmUgbWlzdW5kZXJzdG9vZCB0 aGUgaXNzdWUuICBMaW51eCBpcyBkb2luZyBNVFJSIGluaXQgaW4NCj4gdGhlIEFQIHN0YXJ0 dXAgcGF0aCwgYW5kIHNvIGlmIGl0IHRha2VzIHRvbyBsb25nIExpbnV4IHdpbGwgcmVwb3J0 DQo+IHRoYXQgdGhlIEFQIGhhcyBmYWlsZWQgdG8gc3RhcnQuDQoNCk5vLCBMaW51eCBpcyBk ZWZlcnJpbmcgdGhlIE1UUlJzIHVudGlsIGFsbCBBUHMgYXJlIHVwLCBqdXN0IGxpa2UgWGVu DQoob3IgWGVuIGRvZXMgaXQgbGlrZSBMaW51eCkuDQoNCj4gDQo+IFRoaXMgaXMgbm90IGFu IGlzc3VlIG9uIFhlbiBiZWNhdXNlIE1UUlIgaW5pdGlhbGl6YXRpb24gaXMgZGVmZXJyZWQN Cj4gdW50aWwgYWxsIEFQcyBhcmUgdXAsIGFuZCBoZW5jZSBpcyBub3QgcGFydCBvZiB0aGUg dGltZWQgQVAgc3RhcnQNCj4gcGF0aC4gIFRoaXMgb3B0aW1pemF0aW9uIHdhcyBkb25lIGlu Og0KPiANCj4gMGQyMmM4ZDkyYzZjIHg4NjogQ1BVIHN5bmNocm9uaXphdGlvbiB3aGlsZSBk b2luZyBNVFJSIHJlZ2lzdGVyIHVwZGF0ZQ0KPiANCj4gU28gZXZlbiBpZiB3ZSBkaWQgcGFy YWxsZWwgQVAgc3RhcnR1cCB3ZSB3b24ndCBsaWtlbHkgYmUgYWZmZWN0ZWQsDQo+IGJlY2F1 c2Ugd2Ugd291bGQgc3RpbGwgZGVmZXIgdGhlIE1UUlIgc2V0dXAgdW50aWwgYWxsIEFQcyBh cmUgdXAuDQoNCldlIHdpbGwgYmUgYWZmZWN0ZWQsIGFzIGl0cyB0aGUgZGVmZXJyZWQgTVRS UiBzZXR1cCB3aGljaCBpcyB0aGUNCnByb2JsZW0uDQoNCg0KSnVlcmdlbg0K --------------54x8dgl1JYW9AZapAtv7Om0J 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----- --------------54x8dgl1JYW9AZapAtv7Om0J-- --------------mecoxbJo3Xbbj27VngaKsd0Q-- --------------vMnlJv4EU0t2zQDeEsgLY4Hz 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/Ey8FAmlyeVsFAwAAAAAACgkQsN6d1ii/Ey/J agf+JoGEFI8S6N8ApcyRRMB/qw/6R0sJ6CioCy+nEEdp7GkFjx907NwEvcMYhpkkTpc8THMMH2Eg MNoPPK3unfrpTgM1J4/uKMWhqWhasaEOhwQ6CFt9Gk8mjK98JERAk90+oenPsjztw2+TxjQgk9pm JM/k1E6kUKIIuN/8Pux6xIM5u96hpb0tE2Hco9UF2QIV60I8T8m2aNZ21qBpGcbVA4+1d4P5Gdff yfY0NS1LteURYqrAhcQT6iatG5DusosR8a7yZ9RxwPjCb9JVV23TpLZRjJbXLhSh74UoYR3jaRE6 /DNOY6poLOQvQHwrdfyyojioOtELF4TrY+bI1IO9cg== =2D26 -----END PGP SIGNATURE----- --------------vMnlJv4EU0t2zQDeEsgLY4Hz-- From xen-devel-bounces@lists.xenproject.org Fri Jan 23 01:06:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 01:06:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211947.1523314 (Exim 4.92) (envelope-from ) id 1vj5ca-0006ej-51; Fri, 23 Jan 2026 01:05:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211947.1523314; Fri, 23 Jan 2026 01: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 1vj5ca-0006ec-1A; Fri, 23 Jan 2026 01:05:56 +0000 Received: by outflank-mailman (input) for mailman id 1211947; Fri, 23 Jan 2026 01:05:54 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vj5cY-0006eW-OT for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 01:05: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 a95fa04b-f7f7-11f0-9ccf-f158ae23cfc8; Fri, 23 Jan 2026 02:05:52 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 2366160018; Fri, 23 Jan 2026 01:05:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2601FC116C6; Fri, 23 Jan 2026 01:05: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: a95fa04b-f7f7-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769130350; bh=zPcvXu5VCYMukLaN255k/MTEnsytblLlj+oHAvHnX7g=; h=Date:From:To:cc:Subject:From; b=M/Uy3H5xmlCo2A2AatxcLgW32+urSgesqnZrfHkfUoNlgkifb0J9U+irBV2bdGFNc 1M4m6JL2wlr4kHsqpUbCrOFmk0N0GgnUmF4EdigJtcP16NhhTKtbDzBX9AkzaLdexn FtOp5EJkBG58CwhKj5xdGptsfE70yfT+K2/1CHtqTi43zh2quBrtw3JE3z1vTpe61F v5KttgBuIblqxzGTOAeoih2QP+GxriCI7a5Dgy/CnlgaOkCfAsIUa50qrYxZqa+ftY +QsRzTYdeP1LN3AWEufHQJboVja8hUC7AlpPNUh8a2I2ly7LUVSp9reGilLdEihqdV u04izACpRPkoA== Date: Thu, 22 Jan 2026 17:05:47 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: xen-devel@lists.xenproject.org cc: grygorii_strashko@epam.com, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Victor Lira , andrew.cooper3@citrix.com, jbeulich@suse.com, sstabellini@kernel.org Subject: [PATCH v7 0/2] xen: console_io for dom0less guests Message-ID: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Hi all, This short patch series enable the usage of console_io hypercalls for dom0less guests. Cheers, Stefano From xen-devel-bounces@lists.xenproject.org Fri Jan 23 01:06:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 01:06:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211958.1523324 (Exim 4.92) (envelope-from ) id 1vj5dY-00076b-Cv; Fri, 23 Jan 2026 01:06:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211958.1523324; Fri, 23 Jan 2026 01:06:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vj5dY-00076U-9T; Fri, 23 Jan 2026 01:06:56 +0000 Received: by outflank-mailman (input) for mailman id 1211958; Fri, 23 Jan 2026 01:06:55 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vj5dX-00076H-F4 for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 01:06:55 +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 cc4d5ea1-f7f7-11f0-9ccf-f158ae23cfc8; Fri, 23 Jan 2026 02:06:52 +0100 (CET) Received: from BYAPR05CA0086.namprd05.prod.outlook.com (2603:10b6:a03:e0::27) by LV3PR12MB9267.namprd12.prod.outlook.com (2603:10b6:408:211::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Fri, 23 Jan 2026 01:06:46 +0000 Received: from MWH0EPF000971E6.namprd02.prod.outlook.com (2603:10b6:a03:e0:cafe::cc) by BYAPR05CA0086.outlook.office365.com (2603:10b6:a03:e0::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Fri, 23 Jan 2026 01:06:45 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by MWH0EPF000971E6.mail.protection.outlook.com (10.167.243.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Fri, 23 Jan 2026 01:06: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; Thu, 22 Jan 2026 19:06:43 -0600 Received: from SATLEXMB04.amd.com (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Thu, 22 Jan 2026 19:06:42 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cc4d5ea1-f7f7-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DNOxh/uaxDBpwtuetcOrTGIvHgXg23LcFf90341QJIhORy6I6ZcWc2B5/oUV2jdOv3BROr0RnLfkNgU4bAtFqKvBJ4LsXo7dhd0da6cM/uJJzSeIfBoeK/uG0kSVOPtYPsOVAyD/BgSSs/dE9HD0UNI5VqESFQnavbGwJD7UEvqoVHD2HYn9iSkx98FLykxi2DaGrwFrhQGtm5Bb9dkjwZlDRJ7c1EJeQ7eVEXZl5TNO6GcI+lolLKCHubtWV7DeTNJXohZsnRiV9pNht2yQ+KlhfKS1f9xuvSfMJY+d3g+/3GbYgZtJcDlXONl30We2J51vlH+6u9QojuxhYq1prg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3AX/aTZxd4SbVNEt4XnbYZOE7wNw1QVzhOV83yoNCV8=; b=Hd+sFGzhvUy1yf0wIQs3T07sqf1Mpu55YyA6vinMxXgx7b07HQNgl4Xpq8pkWNbt5/H2mtvIa3NBD/7KfVW6u5rNoOcLv7UKYuuHkZYtwLDDkXMHBy1k+GbiCROzpaHXlPN+uSmfR65iQqCA3p2/IzkwMImR0nuXjvHf/aYFEbYrwXaWQlWJCFVllXDOk2ynJF3Xv41F01OHHRGZuzuJ+kD0gV8WGw6cC5gzC68DvNpbqV0Eh7mvlWK62ghhi++dJTR0+bLiqASZkGVGN3Cm/nx8/M32YhdIsW8FfgG15iAsqTzIJWrOVsFaaOpgwBgA9PtBD4MCN1tjOAUTk/oedg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3AX/aTZxd4SbVNEt4XnbYZOE7wNw1QVzhOV83yoNCV8=; b=IPnp/3NXjfw2bGpVM15tmiqBuNn7o5/BJB9efrGux5b8HXXzvJukQCk2vrvJriSOGmDCS6DPDND7O9VRIjngw0FsIM4FkBhPs6b24AsgJ2sdkpFZKdIIVCkQSkZkXuXzGtZ3REFz2/VJfQ6kQn67TZO6HCV5JRBOZYB81J5MgIg= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: Stefano Stabellini To: CC: , , , , , , , , , , Stefano Stabellini Subject: [PATCH v7 1/2] xen/console: handle multiple domains using console_io hypercalls Date: Thu, 22 Jan 2026 17:06:39 -0800 Message-ID: <20260123010640.1194863-1-stefano.stabellini@amd.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWH0EPF000971E6:EE_|LV3PR12MB9267:EE_ X-MS-Office365-Filtering-Correlation-Id: eb630b8e-f487-4693-d68e-08de5a1bace4 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?fq6eQpS2gueRpb98td84iqQUgLhJ8AhX8pM0ibUBYyCJ9JyjFRmV2q7bfVd1?= =?us-ascii?Q?d0WplTaXKyhYlsY8zaSQcXhy2cl5RWbFr6DTBK6gwESDiOIIHTYogRrg78Vm?= =?us-ascii?Q?+p7n0OBK/Q4BmRmmHO9kRiR3dMHplhVidbcCQMYN4/ePp7y0BWwzBqtA9ENP?= =?us-ascii?Q?WIXigdkQROMj+9mfFelrR6/Gb/XgS0N/RIFAAbmMIwL6fEZsOW1QMA3qOOuZ?= =?us-ascii?Q?Y1HADsTx2FKkYUmXssuMOVuLPrwq/UDw1AQ+60iGvGtI64XWJsjC+njnOnEb?= =?us-ascii?Q?emh6FaBWXV484Ieb0/sHWBuzoD3ThH3myiA1jLAtZ/NoJO0qR6n2f8e1hPH5?= =?us-ascii?Q?bSnBDbiwSuT3ngF2gFJRqQNvKoQ6zE+JDsQFjKb12ltT2w0J5C4cZMsMHSYw?= =?us-ascii?Q?q9Fd3P8uLGU1UM3rnGZG3AJN5h5ts6KDQZswNg9O/2c2bVe4+1lyt7LYKmm1?= =?us-ascii?Q?DA8vKClzoaje6njAzEHGKF1DqpgUBAIlo/1kmk2T2W5cpRG5pVVqz8cYKiEi?= =?us-ascii?Q?JdIZDAdPfU6fXSAcv9XXBHaLj6DUXqpKlKLdkxXXBPiaQVQxGTloVlxY5c4H?= =?us-ascii?Q?8UGJt8ORynnC0jAjc2uDnP5ys9BrGr/PuEvnG2cMnbMy/r7FANYSJsNpSu+q?= =?us-ascii?Q?unUbTQcaUb2vxgI0289BbDlEZZMXUyNoJCDH/TJ3mHXDO5+xULHm3Yj2fffu?= =?us-ascii?Q?Ozz2dFoq3TDf0UmTCR7mv3Y3u3mBlaVWmOknEZlInHb0+1xvl6sJoihikOv3?= =?us-ascii?Q?+0tTEFaDaP+M9BnKHZYlLcsfW8ra0RLptw9zuPpmXUQ/XJbMeXEmtb54sIy/?= =?us-ascii?Q?o7sy0w+TDwB4RHMJAh4NPeOb7+8KRLqr8uwBjGLCD1hakXoIF4ttw1NW+h5D?= =?us-ascii?Q?o2Bm/DVP7R5OAWxlrHx5yMFKxt4WJAf2BxWOz0A0eqdlhAFsFzLLbcerBje7?= =?us-ascii?Q?CZBGEmI8n1gnh0L2kF251Dc6hItKcQWNZz02CI7sU+NZzZEuR0HipmQ7UN3+?= =?us-ascii?Q?NVI28FIHdu5Y+SP+zdw5ItFdwV4fO3EXbDSLSIzhQ8W092PtKObhA40NDC6r?= =?us-ascii?Q?kVUKbVTNtQs3Dp+qB8GZ/21KNIXYalaEW+Qa18jvdS/xSTj4gbt+AIlUTAlb?= =?us-ascii?Q?cTReKnkbzNcEX8Po2cE55Snm5JoQotL6/siwOfhZoJhJzXb1FYvxC7zrghP6?= =?us-ascii?Q?hYWbP/NsVpHsfzu1Kkj040nv7/W9vQ9Ju4L9ZmTClslGRW0rYHaH0PIYLLYK?= =?us-ascii?Q?6xuKIKWm6QakinpdZN6cLmk+xEHfJHbk/z98nYDIGC3VEznl8U/ywIRIW4Jg?= =?us-ascii?Q?4o/iOU4DqU5YLoDpOPlm1NljQgg9A62R8eaXiblGRw+zvK6oWnWVwF/REY2i?= =?us-ascii?Q?gHl0Kq4uvvYTagxVdBsZb9pi28Gnj/KrUuXijwnDyYXlehgI/IR3tEhBSW7l?= =?us-ascii?Q?KAAeXxqD7k5pjN9huciCTCG/w3AZY4WgKpwAkJq6gY6rfT3NX4fP4Gd/soD6?= =?us-ascii?Q?+b7s+s0l0Ow6UbvTxZJ8Ej1decKp2LF9b4h8yq7R8V6FMrI7khNY/AAAKpHy?= =?us-ascii?Q?EAy0bEMY81v0KXgMC/IfuizTXV1FArjjVzY8sPOB9Ytinrhk39GtRpIMpWck?= =?us-ascii?Q?FAuW2rre9oW6GDGtdJR7y99ZFBYg/2EBfFkMc7yngAnzURGP401uKQOBp+kk?= =?us-ascii?Q?cvLKdA=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2026 01:06:44.3670 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: eb630b8e-f487-4693-d68e-08de5a1bace4 X-MS-Exchange-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: MWH0EPF000971E6.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9267 Allow multiple dom0less domains to use the console_io hypercalls to print to the console. Handle them in a similar way to vpl011: only the domain which has focus can read from the console. All domains can write to the console but the ones without focus have a prefix. In this case the prefix is applied by using guest_printk instead of printk or console_puts which is what the original code was already doing. When switching focus using Ctrl-AAA, discard any unread data in the input buffer. Input is read quickly and the user would be aware of it being slow or stuck as they use Ctrl-AAA to switch focus domain. In that situation, it is to be expected that the unread input is lost. The domain writes are buffered when the domain is not in focus. Push out the buffer after the domain enters focus on the first guest write. Locking updates: - Guard every mutation of serial_rx_cons/prod with console_lock and discard unread input under the lock when switching focus (including when returning to Xen) so that cross-domain reads can't see stale data - Require is_focus_domain() callers to hold console_lock, and take that lock around the entire CONSOLEIO_read loop, re-checking focus after each chunk so a focus change simply stops further copies without duplicating or leaking input - Hold cons->lock while flushing buffered writes in the focus path so the direct-write fast path does not race buffered guests or HVM debug output Signed-off-by: Stefano Stabellini --- Changes in v7: - move vpl011 hunk to new patch - updated commit message - add ASSERT - const pointer - more in-code comments - move spin_unlock earlier - code style --- xen/drivers/char/console.c | 75 +++++++++++++++++++++++++++++++++----- 1 file changed, 65 insertions(+), 10 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 2bdb4d5fb4..09354db2e0 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -540,6 +540,12 @@ void console_put_domain(struct domain *d) rcu_unlock_domain(d); } +static bool is_focus_domain(const struct domain *d) +{ + ASSERT(rspin_is_locked(&console_lock)); + return d != NULL && d->domain_id == console_rx - 1; +} + static void console_switch_input(void) { unsigned int next_rx = console_rx; @@ -555,8 +561,11 @@ static void console_switch_input(void) if ( next_rx++ >= max_console_rx ) { - console_rx = 0; printk("*** Serial input to Xen"); + nrspin_lock_irq(&console_lock); + console_rx = 0; + serial_rx_cons = serial_rx_prod; + nrspin_unlock_irq(&console_lock); break; } @@ -575,8 +584,12 @@ static void console_switch_input(void) rcu_unlock_domain(d); - console_rx = next_rx; printk("*** Serial input to DOM%u", domid); + nrspin_lock_irq(&console_lock); + console_rx = next_rx; + /* Don't let the next dom read the previous dom's unread data. */ + serial_rx_cons = serial_rx_prod; + nrspin_unlock_irq(&console_lock); break; } } @@ -605,8 +618,10 @@ static void __serial_rx(char c) * Deliver input to the hardware domain buffer, unless it is * already full. */ + nrspin_lock_irq(&console_lock); if ( (serial_rx_prod - serial_rx_cons) != SERIAL_RX_SIZE ) serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c; + nrspin_unlock_irq(&console_lock); /* * Always notify the hardware domain: prevents receive path from @@ -730,6 +745,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, unsigned int flags = opt_console_to_ring ? CONSOLE_ALL : CONSOLE_DEFAULT; struct domain *cd = current->domain; + struct domain_console *cons = cd->console; while ( count > 0 ) { @@ -742,17 +758,36 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, if ( copy_from_guest(kbuf, buffer, kcount) ) return -EFAULT; - if ( is_hardware_domain(cd) ) + /* + * Take both cons->lock and console_lock: + * - cons->lock protects cons->buf and cons->idx + * - console_lock protects console_send and is_focus_domain + * checks + * + * The order must be respected. guest_printk takes the + * console_lock so it is important that cons->lock is taken + * first. + */ + spin_lock(&cons->lock); + nrspin_lock_irq(&console_lock); + if ( is_focus_domain(cd) ) { + if ( cons->idx ) + { + console_send(cons->buf, cons->idx, flags); + cons->idx = 0; + } + spin_unlock(&cons->lock); + /* Use direct console output as it could be interactive */ - nrspin_lock_irq(&console_lock); console_send(kbuf, kcount, flags); nrspin_unlock_irq(&console_lock); } else { char *kin = kbuf, *kout = kbuf, c; - struct domain_console *cons = cd->console; + + nrspin_unlock_irq(&console_lock); /* Strip non-printable characters */ do @@ -765,7 +800,6 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, } while ( --kcount > 0 ); *kout = '\0'; - spin_lock(&cons->lock); kcount = kin - kbuf; if ( c != '\n' && (cons->idx + (kout - kbuf) < (ARRAY_SIZE(cons->buf) - 1)) ) @@ -815,6 +849,13 @@ long do_console_io( if ( count > INT_MAX ) break; + nrspin_lock_irq(&console_lock); + if ( !is_focus_domain(current->domain) ) + { + nrspin_unlock_irq(&console_lock); + return 0; + } + rc = 0; while ( (serial_rx_cons != serial_rx_prod) && (rc < count) ) { @@ -824,14 +865,28 @@ long do_console_io( len = SERIAL_RX_SIZE - idx; if ( (rc + len) > count ) len = count - rc; + nrspin_unlock_irq(&console_lock); if ( copy_to_guest_offset(buffer, rc, &serial_rx_ring[idx], len) ) - { - rc = -EFAULT; - break; - } + return -EFAULT; rc += len; + + /* + * First get console_lock again, then check is_focus_domain. + * It is possible that we switched focus domain during + * copy_to_guest_offset. In that case, serial_rx_cons and + * serial_rx_prod have been reset so it would be wrong to + * update serial_rx_cons here. Get out of the loop instead. + * + * rc is updated regardless to provide the correct return + * value to the VM as the data has been copied. + */ + nrspin_lock_irq(&console_lock); + if ( !is_focus_domain(current->domain) ) + break; + serial_rx_cons += len; } + nrspin_unlock_irq(&console_lock); break; default: rc = -ENOSYS; -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Fri Jan 23 01:07:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 01:07:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211964.1523334 (Exim 4.92) (envelope-from ) id 1vj5eI-0007hr-Ka; Fri, 23 Jan 2026 01:07:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211964.1523334; Fri, 23 Jan 2026 01:07:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vj5eI-0007hk-Hw; Fri, 23 Jan 2026 01:07:42 +0000 Received: by outflank-mailman (input) for mailman id 1211964; Fri, 23 Jan 2026 01:07: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 1vj5eH-0007hY-6n for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 01:07:41 +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 e8221ec7-f7f7-11f0-9ccf-f158ae23cfc8; Fri, 23 Jan 2026 02:07:38 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 7D19D43F80; Fri, 23 Jan 2026 01:07:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 07E1EC116C6; Fri, 23 Jan 2026 01:07: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: e8221ec7-f7f7-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769130456; bh=7d+sWZnVd4LXsBCIblWKUQW8c0ZBO6h3TKEuyH+jkb8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=dPR29/cayRoyXg1Tdak0G5lLHFnCLLVIJOuk9xsgLcXvzYQopA/ZRS2Pc/dPGAWq5 +ccn1cWbdmfBPdjbKmV3wWcHaNikrJi/9bUy2w4pzrDoXh5X58zQ8ab4EF0ci8/8uy q3hW7IzCsSCtlCRFdb8zeWJQv/Xz99EQ93qp3CNOw1QNMrFbNS76cLjs1addg+W9oS f5+N/PUEj8rNfwJW0aI8tndw7ELmeWlE58hRxykfw5BbquQlmjPYIYvrFhiPH5c4gi pC0oyVgwREea3vZ4cL+QZX74Mt8dkzz8dmGcqG3Iys5Y65qbWL1UxxOcnNukP+7HPO STBszoQQrc64w== Date: Thu, 22 Jan 2026 17:07:33 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Jan Beulich cc: Stefano Stabellini , grygorii_strashko@epam.com, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Victor Lira , andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH v6] xen/console: handle multiple domains using console_io hypercalls In-Reply-To: <912ff342-f5aa-44fa-8a91-43be4363776e@suse.com> Message-ID: References: <912ff342-f5aa-44fa-8a91-43be4363776e@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, 22 Jan 2026, Jan Beulich wrote: > On 22.01.2026 02:34, Stefano Stabellini wrote: > > Allow multiple dom0less domains to use the console_io hypercalls to > > print to the console. Handle them in a similar way to vpl011: only the > > domain which has focus can read from the console. All domains can write > > to the console but the ones without focus have a prefix. In this case > > the prefix is applied by using guest_printk instead of printk or > > console_puts which is what the original code was already doing. > > > > When switching focus using Ctrl-AAA, discard any unread data in the > > input buffer. Input is read quickly and the user would be aware of it > > being slow or stuck as they use Ctrl-AAA to switch focus domain. > > In that situation, it is to be expected that the unread input is lost. > > > > The domain writes are buffered when the domain is not in focus. Push out > > the buffer after the domain enters focus on the first guest write. > > > > Move the vpl011 check first so that if vpl011 is enabled, it will be > > used. In the future, the is_hardware_domain path might also be used by > > other predefined domains so it makes sense to prioritize vpl011 to > > retain the current behavior on ARM. > > As indicated elsewhere already, I think this wants moving out of here. > A question is going to be whether the consoled part then also wants > moving ahead (albeit I fear for now I don't really understand the need > for this movement, seeing that the is_hardware_domain() check there > remains as is). You are right that the is_hardware_domain() check is now wrong. The reason I didn't notice before is that I was testing on a branch with a more complete hyperlaunch implementation where the check was different. Without the vpl011 hunk the patch is not functional but the change can go into a separate patch. The separate patch also needs to do the following: - get rid of the is_hardware_domain() check - set input_allowed for dom0less guests to make use of console_io With this, everything works properly upstream now. > > Locking updates: > > > > - Guard every mutation of serial_rx_cons/prod with console_lock and > > discard unread input under the lock when switching focus (including when > > returning to Xen) so that cross-domain reads can't see stale data > > > > - Require is_focus_domain() callers to hold console_lock, and take that > > lock around the entire CONSOLEIO_read loop, re-checking focus after each > > chunk so a focus change simply stops further copies without duplicating > > or leaking input > > Shouldn't this then ... > > > - Hold cd->pbuf_lock while flushing buffered writes in the focus path > > so the direct-write fast path does not race buffered guests or HVM > > debug output > > (What's ->pbuf_lock again?) I updated the commit message. It is cons->lock. > > --- a/xen/drivers/char/console.c > > +++ b/xen/drivers/char/console.c > > @@ -540,6 +540,11 @@ void console_put_domain(struct domain *d) > > rcu_unlock_domain(d); > > } > > > > +static bool is_focus_domain(struct domain *d) > > +{ > > + return d != NULL && d->domain_id == console_rx - 1; > > +} > > ... be expressed in a comment here as well (or even an assertion)? > > Also please make the function parameter pointer-to-const. Yes and yes > > @@ -599,14 +611,25 @@ static void __serial_rx(char c) > > if ( !d ) > > return; > > > > +#ifdef CONFIG_SBSA_VUART_CONSOLE > > + /* Prioritize vpl011 if enabled for this domain */ > > + if ( d->arch.vpl011.base_addr ) > > + { > > + /* Deliver input to the emulated UART. */ > > + rc = vpl011_rx_char_xen(d, c); > > + } > > + else > > +#endif > > if ( is_hardware_domain(d) ) > > { > > /* > > * Deliver input to the hardware domain buffer, unless it is > > * already full. > > */ > > + nrspin_lock_irq(&console_lock); > > if ( (serial_rx_prod - serial_rx_cons) != SERIAL_RX_SIZE ) > > serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c; > > + nrspin_unlock_irq(&console_lock); > > Hmm, now that there's more context here: The comment looks to still be > correct as per the enclosing if(), but how does that fit with the purpose > of this patch? Isn't it part of the goal to allow input to non-hwdom as > well? I updated the comment (in the second patch). It should say focus domain now, instead of hardware domain. > > @@ -742,18 +761,25 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, > > if ( copy_from_guest(kbuf, buffer, kcount) ) > > return -EFAULT; > > > > - if ( is_hardware_domain(cd) ) > > + spin_lock(&cons->lock); > > + nrspin_lock_irq(&console_lock); > > This double lock (and the need for this specific order) might better be > commented upon, too. +1 > > + if ( is_focus_domain(cd) ) > > { > > + if ( cons->idx ) > > + { > > + console_send(cons->buf, cons->idx, flags); > > + cons->idx = 0; > > + } > > /* Use direct console output as it could be interactive */ > > - nrspin_lock_irq(&console_lock); > > console_send(kbuf, kcount, flags); > > nrspin_unlock_irq(&console_lock); > > + spin_unlock(&cons->lock); > > Why is it that this lock can be dropped only here? It's not needed anymore > past the if()'s body? Yes, you are technically correct, but it is easier to understand lock if they are always taken in order and released in the opposite order: A-B [...] B-A That said, I couldn't find anything wrong in this case with moving the cons->unlock just after the if, so I did as you suggested. > > } > > else > > { > > char *kin = kbuf, *kout = kbuf, c; > > - struct domain_console *cons = cd->console; > > > > + nrspin_unlock_irq(&console_lock); > > /* Strip non-printable characters */ > > Blank line between these? Yes > > @@ -824,14 +856,16 @@ long do_console_io( > > len = SERIAL_RX_SIZE - idx; > > if ( (rc + len) > count ) > > len = count - rc; > > + nrspin_unlock_irq(&console_lock); > > if ( copy_to_guest_offset(buffer, rc, &serial_rx_ring[idx], len) ) > > - { > > - rc = -EFAULT; > > - break; > > - } > > + return -EFAULT; > > rc += len; > > + nrspin_lock_irq(&console_lock); > > + if ( !is_focus_domain(current->domain) ) > > + break; > > serial_rx_cons += len; > > The placement of the check between both updates wants commenting upon, imo. > Another blank line or two would also help, I think. OK > > } > > + nrspin_unlock_irq(&console_lock); > > break; > > default: > > rc = -ENOSYS; > > Much better locking-wise here than in the earlier version. Thanks! Next version is here: https://marc.info/?l=xen-devel&m=176913312213329 From xen-devel-bounces@lists.xenproject.org Fri Jan 23 01:12:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 01:12:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211978.1523344 (Exim 4.92) (envelope-from ) id 1vj5iQ-0000ro-4c; Fri, 23 Jan 2026 01:11:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211978.1523344; Fri, 23 Jan 2026 01: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 1vj5iQ-0000rh-10; Fri, 23 Jan 2026 01:11:58 +0000 Received: by outflank-mailman (input) for mailman id 1211978; Fri, 23 Jan 2026 01:11: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 1vj5iO-0000rb-M1 for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 01:11:56 +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 80df01dc-f7f8-11f0-b15e-2bf370ae4941; Fri, 23 Jan 2026 02:11:55 +0100 (CET) Received: from BN9PR03CA0553.namprd03.prod.outlook.com (2603:10b6:408:138::18) by LV8PR12MB9407.namprd12.prod.outlook.com (2603:10b6:408:1f9::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Fri, 23 Jan 2026 01:11:48 +0000 Received: from BN3PEPF0000B370.namprd21.prod.outlook.com (2603:10b6:408:138:cafe::5) by BN9PR03CA0553.outlook.office365.com (2603:10b6:408:138::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.10 via Frontend Transport; Fri, 23 Jan 2026 01:11:44 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN3PEPF0000B370.mail.protection.outlook.com (10.167.243.167) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.0 via Frontend Transport; Fri, 23 Jan 2026 01:11:46 +0000 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.2562.17; Thu, 22 Jan 2026 19:06:45 -0600 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; Thu, 22 Jan 2026 19:06:45 -0600 Received: from SATLEXMB04.amd.com (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Thu, 22 Jan 2026 19:06:44 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 80df01dc-f7f8-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Zy06W+gITimFU1jT6KOAoMEdgEnZsi6uzA6gP1dvQ15kW6aSscNQsDffuxnIoqAz4FSOcCbotNF/oOmjw3EdH+Z7jPlKkWvIU7mABj1k+fnTpUHZ0Gw74o7hkNLIt4kOUiDhX+FMVmjrdR5WENNbEEYjR6FWTL5J6VMhi4WPRY5PuCFQ/RsZ+Z0UvRmmAKnnB3xtO2l/9NdtVQ+MUyh83tWWk1okP1H9N8EWk/l5mxWp2ABhaXpjstrwlBmurtY3S5PIiYoc8n+PpJGMq4iX1+HBg3BW/Rz0sOGvVqWoyIVX9dVKSe8n6IFAxQa7KMnU3BtZIhDuZEfFjoiT/BFw8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wtar+qZPCoP0IKYh9UDHTAiZjxPGrGIsKWHWOtMQ6Ro=; b=tzijfIN6P53ToVQVhflMeyiYp5g0I/VbKA5ZQ8vOj01/GHM/xWG4O6FDx6UENWfTWqCnpNE6kC9obHsRdSro9rJLwRRCvZwdS+Yz4b4Q/WENuguqw/jd48+adLVn/0lPfXCLhWjbY+Hzux0QL0VzhyN6+mw4oQfL7lEUbjGSdvgvZGnB+5ni7DjrBhDcsJGAOu7RERBGjMjZTReDqSOzTmDwEcsv9J5gmuhXd6H2RleNoOozrsJmZZK6M0c/tuwahCR7EW7LMVjXD3IkN7WuY3Pl5VhvG4KK05tFkgvqMu3rvdCzb3i5qrSVBOAGl9bHlh9aZmKAR6i2cjjqEenVRQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wtar+qZPCoP0IKYh9UDHTAiZjxPGrGIsKWHWOtMQ6Ro=; b=oB0Dd4Av6a+p6xhppglxkLjVXeMi4kgPWoqk7ckGS5MK9XqXjZJ9OJvu3956TD5DKPtzLOSplLwvSEvY4EZltS0FSiMbtr0YMlTn5uBpN87BjUyiZX/mD+xrI2l6o+iWjaDjWKiCHN/RGsGBmahMS8zgsAbIw8bSq175WA1xYog= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: Stefano Stabellini To: CC: , , , , , , , , , , Stefano Stabellini Subject: [PATCH v7 2/2] xen: enable dom0less guests to use console_io hypercalls Date: Thu, 22 Jan 2026 17:06:40 -0800 Message-ID: <20260123010640.1194863-2-stefano.stabellini@amd.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Received-SPF: None (SATLEXMB03.amd.com: stefano.stabellini@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF0000B370:EE_|LV8PR12MB9407:EE_ X-MS-Office365-Filtering-Correlation-Id: 45c5fafd-f0a0-4403-dd8e-08de5a1c6138 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?aE6fgB5PxvL+C+TubjIHQORNY2y+4mGW5gnO9BBpNeEceyGcphwNMkBs0F03?= =?us-ascii?Q?FP907P9sF3XAgCKYs26T0X9YmlEiXS9gj2qa6fGdhPxaiTZNkA/OrJ327kJK?= =?us-ascii?Q?OWkoQLeJ0mYfg+ddqNwfm3porr4TtHB/P0aZ620z4Qsd6B5TAIlNciK8GFND?= =?us-ascii?Q?Ku1O3drlH/Q7y3/0BL2l1HjQzwf6LRbEh28wKdzTATEmNwUqBf2S0vq1D47f?= =?us-ascii?Q?95oi5+UMIk7G5oNznqGQAgY7Yyoh7qr9nyNXI88Cvox/RF+OK7mVlXBmBpoJ?= =?us-ascii?Q?rIUeJAYX1sVTxufhoYECNsdWdn1AVeZIudJFhpckE+ihrYem+oZ+ia+8Px5U?= =?us-ascii?Q?25QuDWoyUVWyFqBIcR+1pYatVwCmrQAmK6MNT897HCpBJyHEdjyZj378e+fg?= =?us-ascii?Q?xxrJq+4vRU3sGdhSfItFHikM7O7Bb7E/nFig/HrmE3+kQteohS7Wp04+U5E8?= =?us-ascii?Q?NokSgqkpsSoGuRyu65lbK78lr7BV4s3pJX0ELuXONW7D8hJNGpf2b8miWMMB?= =?us-ascii?Q?LYk0fiC70m2VHz+pcSUWIo8Jj0eIovKqJGCtTucxJkAbuOImGOOK5JcznpLl?= =?us-ascii?Q?9boeIXmrbNHKwSr2o80d577Bg1TqTjoQdArNhBo7RnMvlqBtj/r1vmZuAfta?= =?us-ascii?Q?HNKJY6ueZmuAclmwIOc9sO4zS4Fq7m5zGbeyHgMh4ASxsOnf/h7rVvtjUmRS?= =?us-ascii?Q?/pr5zIXoqSULmAywb6ymsP+xSktEFozS2iXNH1zqBt7iz4bi9GHXXh5MW4of?= =?us-ascii?Q?UeZisw15aGaDmAMn6kRvjwpoRZ6XiDz/lusfmwfrJhxbUC5Fsc2CtzYkF+ck?= =?us-ascii?Q?E4yYCKuD3UlNrK2v1tNA97cyho8RoC7dMM0gKyr0NGmA5wt4oN/82evY66X/?= =?us-ascii?Q?/BD2qkBCrczE6wXcpXxQJIyjFU8ab0dJuczATqEI/HvSGftLwtcOcOBhrKJ7?= =?us-ascii?Q?37cVDcqPMUgrHyssEo0PDS8HZUahO+1eaKyh7uU1TWbwPVCiStR2d26y5aeW?= =?us-ascii?Q?9EamCJDQ6YlKF4AntMmQaLvjpeDCllWMOOzzjUyB/iDU82JcNIBLDb7jRpOk?= =?us-ascii?Q?6LFdj3f0g7MAWjBjM/1BYyD0Y652h+YcyYn06sR1Ss21Vq80BhC6nhk5K7HX?= =?us-ascii?Q?+kDIrbkaJp9dcOJPud4j82IH7JH1hzRdMCfbRHrVkOQiMvTvkGWAUsA5QH6W?= =?us-ascii?Q?4BR85Q+g3r4fsdYhM0gm8vkyLHyUng15PNuKX40GyKY/XRhFFxBs3PX/j2R+?= =?us-ascii?Q?feYM/7AA0D2hd+Dl52sQJK0IQ8g7qW02L2LdY1Puv4ddUiwpr7pZEj7F6Vxh?= =?us-ascii?Q?4DjmmWz83a6dIQyEfKyRV3bwmMN+a354gtFIYm05cX+I5amHSpqBc5XavO8P?= =?us-ascii?Q?s0DIdLAiETmt0wwNk11zB2yDfnQQ6EEHfBsNIAu464QZxof2gme1dxsDV0pP?= =?us-ascii?Q?Gke/svJ+dwqbL6jzN5u8e7n7Qf4XKXepHApMRKZt/GZUGq3lPWexNYJkGgl0?= =?us-ascii?Q?//IcnhJtZaznU7yu+1f0sX8m93odsA2y1LarLVen7IzQrFbkaskeS9QfawZV?= =?us-ascii?Q?qqI5NKLdxQ61LQ2vlurymTrmxKK+aosBwM2Ek08Hb/di0/+2ZS8bGZwJ7j2g?= =?us-ascii?Q?dWSaDC1sxlks063KpjbK2v8C5f9r4TRWMyAL2suRg+h2uv1Q2kb7mlHUeVM/?= =?us-ascii?Q?wWd6Hg=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2026 01:11:46.9496 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 45c5fafd-f0a0-4403-dd8e-08de5a1c6138 X-MS-Exchange-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: BN3PEPF0000B370.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR12MB9407 Enable dom0less guests on ARM to use console_io hypercalls: - set input_allow = true for dom0less domains - update the in-code comment in console.c - prioritize the VUART check to retain the same behavior as today Signed-off-by: Stefano Stabellini --- xen/common/device-tree/dom0less-build.c | 2 ++ xen/drivers/char/console.c | 17 ++++++++++------- 2 files changed, 12 insertions(+), 7 deletions(-) diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c index 840d14419d..cb7026fa7e 100644 --- a/xen/common/device-tree/dom0less-build.c +++ b/xen/common/device-tree/dom0less-build.c @@ -829,6 +829,8 @@ static int __init construct_domU(struct kernel_info *kinfo, rangeset_destroy(kinfo->xen_reg_assigned); + d->console->input_allowed = true; + return rc; } diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 09354db2e0..26de872b8d 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -612,10 +612,18 @@ static void __serial_rx(char c) if ( !d ) return; - if ( is_hardware_domain(d) ) +#ifdef CONFIG_SBSA_VUART_CONSOLE + /* Prioritize vpl011 if enabled for this domain */ + if ( d->arch.vpl011.base_addr ) + { + /* Deliver input to the emulated UART. */ + rc = vpl011_rx_char_xen(d, c); + } + else +#endif { /* - * Deliver input to the hardware domain buffer, unless it is + * Deliver input to the focus domain buffer, unless it is * already full. */ nrspin_lock_irq(&console_lock); @@ -629,11 +637,6 @@ static void __serial_rx(char c) */ send_global_virq(VIRQ_CONSOLE); } -#ifdef CONFIG_SBSA_VUART_CONSOLE - else - /* Deliver input to the emulated UART. */ - rc = vpl011_rx_char_xen(d, c); -#endif if ( consoled_is_enabled() ) /* Deliver input to the PV shim console. */ -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Fri Jan 23 01:34:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 01:34:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1211993.1523355 (Exim 4.92) (envelope-from ) id 1vj64V-0003xK-0A; Fri, 23 Jan 2026 01:34:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1211993.1523355; Fri, 23 Jan 2026 01: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 1vj64U-0003xD-Sb; Fri, 23 Jan 2026 01:34:46 +0000 Received: by outflank-mailman (input) for mailman id 1211993; Fri, 23 Jan 2026 01: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 1vj64T-0003x7-8J for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 01:34:45 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b0808ac5-f7fb-11f0-9ccf-f158ae23cfc8; Fri, 23 Jan 2026 02:34:42 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 21DC660018; Fri, 23 Jan 2026 01:34:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3FF65C116C6; Fri, 23 Jan 2026 01:34: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: b0808ac5-f7fb-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769132080; bh=LlvnuZHkkUZjU6oP7cNdF9crsDaCmlhOCHbPp+sdGsQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Ss2BXayqDqDF0pxpkCCBrvWUu9Ma+I3nCplVBLIDKUjVFSGeocXMlffF61A/mIzoT ma0RGQ4MnLyY//Z2iaSimdYhPv9S5g2nVx/fRJGdrHR/KCHpwBZjrrJbYstdo3+2p3 Uf8/E84uaWO851obducsG88rTiGdkUyFS9k5LfwplvaZHOWNmfzpLkPwdR37y19emX o8bMHpC3JYyVfA6TQB+AonY3g0vmBPlYpSabC3/Kf7SMonmrD7eqFQbB5yuh9eEoNt fbPglAt9jA42ksgL1SJYeGCRXYbTmO58HnZ9qnZtlcC/mMj2ybxpgvMCJXj/ScKqME BY/x6TJfY95MQ== Date: Thu, 22 Jan 2026 17:34:37 -0800 (PST) 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 2/5] xen: arm: smccc: add INVALID_PARAMETER error code In-Reply-To: <8b964d9b6a50053d8a2e485a672b0fd3bc2e0c7c.1769020872.git.oleksii_moisieiev@epam.com> Message-ID: References: <8b964d9b6a50053d8a2e485a672b0fd3bc2e0c7c.1769020872.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 Wed, 21 Jan 2026, Oleksii Moisieiev wrote: > According to the "7.1 Return Codes" section of DEN0028 [1] > INVALID_PARAMETER code (-3) is returned when one of the call > parameters has a non-supported value. > Adding this error code to the common smccc header file. > > [1]: https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6 > > Signed-off-by: Oleksii Moisieiev Acked-by: Stefano Stabellini > --- > > > > xen/arch/arm/include/asm/smccc.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/smccc.h > index 441b3ab65d..478444fb09 100644 > --- a/xen/arch/arm/include/asm/smccc.h > +++ b/xen/arch/arm/include/asm/smccc.h > @@ -381,6 +381,7 @@ void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs *args, > 0x3FFF) > > /* SMCCC error codes */ > +#define ARM_SMCCC_INVALID_PARAMETER (-3) > #define ARM_SMCCC_NOT_REQUIRED (-2) > #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION (-1) > #define ARM_SMCCC_NOT_SUPPORTED (-1) > -- > 2.34.1 > From xen-devel-bounces@lists.xenproject.org Fri Jan 23 01:51:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 01:51:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212006.1523364 (Exim 4.92) (envelope-from ) id 1vj6KV-0006wQ-8p; Fri, 23 Jan 2026 01:51:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212006.1523364; Fri, 23 Jan 2026 01:51:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vj6KV-0006wJ-62; Fri, 23 Jan 2026 01:51:19 +0000 Received: by outflank-mailman (input) for mailman id 1212006; Fri, 23 Jan 2026 01:51:17 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vj6KT-0006wD-Q0 for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 01:51:17 +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 004fc5e9-f7fe-11f0-b15e-2bf370ae4941; Fri, 23 Jan 2026 02:51:15 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 29D6F60018; Fri, 23 Jan 2026 01:51:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 49625C116C6; Fri, 23 Jan 2026 01:51: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: 004fc5e9-f7fe-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769133073; bh=C/qr2ONSioMJoUosNI2BrGrXz0PfXblpykunq/KpyJc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=huGnv4yEcvMScE5VioUgQDKtxySfADb4gc0dXPGKDAyv/SfqnHkS5UPGsRZWOo0/I fwUWdm6ryvnR6aG2JRs1IF05Kxv2BGm0D3ePLCNH+3iM0w7fDXaWfDVbQl/PSsNwpa 5xHzVvtSzPXHpoKgI7B2bh81Y5fv+fLy/mOQrlr/gRgFAMs5XUq4KCDDfw4J5xJl2b yQZl1LwGkNJzUVlnES7VF217/TxRfolOZx2AkCRis+cigRyFDh11uSGCBu+ept1hbZ 9ENkF/detfQmMh2+rBcr7AuUxTZHP/1rolk/1J9mYQISeMWEQXX1X0AT9eJ9rIcHD1 iuNvShUuybCiA== Date: Thu, 22 Jan 2026 17:51:11 -0800 (PST) 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 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver 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 Not a full review, but I found three issues plus some spurious changes On Wed, 21 Jan 2026, Oleksii Moisieiev wrote: > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc > index 15f7a315a4..268df3010b 100644 > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -789,7 +789,7 @@ Specify the bit width of the DMA heap. > cpuid-faulting=, msr-relaxed=, > pf-fixup= ] (x86) > > - = List of [ sve= ] (Arm64) > + = List of [ sve= ] (Arm) > > Controls for how dom0 is constructed on x86 systems. Spurious change > diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c > index e4407d6e3f..be0e6263ae 100644 > --- a/tools/libs/light/libxl_arm.c > +++ b/tools/libs/light/libxl_arm.c > @@ -240,6 +240,10 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc, > case LIBXL_ARM_SCI_TYPE_SCMI_SMC: > config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; > break; > + case LIBXL_ARM_SCI_TYPE_SCMI_SMC_MULTIAGENT: > + config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA; > + config->arch.arm_sci_agent_id = d_config->b_info.arch_arm.arm_sci.agent_id; > + break; > default: > LOG(ERROR, "Unknown ARM_SCI type %d", > d_config->b_info.arch_arm.arm_sci.type); > diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl > index 4a958f69f4..9bfbf09145 100644 > --- a/tools/libs/light/libxl_types.idl > +++ b/tools/libs/light/libxl_types.idl > @@ -554,11 +554,13 @@ libxl_sve_type = Enumeration("sve_type", [ > > libxl_arm_sci_type = Enumeration("arm_sci_type", [ > (0, "none"), > - (1, "scmi_smc") > + (1, "scmi_smc"), > + (2, "scmi_smc_multiagent") > ], init_val = "LIBXL_ARM_SCI_TYPE_NONE") > > libxl_arm_sci = Struct("arm_sci", [ > ("type", libxl_arm_sci_type), > + ("agent_id", uint8) > ]) > > libxl_rdm_reserve = Struct("rdm_reserve", [ > diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c > index 1cc41f1bff..0c389d25f9 100644 > --- a/tools/xl/xl_parse.c > +++ b/tools/xl/xl_parse.c > @@ -1306,6 +1306,18 @@ static int parse_arm_sci_config(XLU_Config *cfg, libxl_arm_sci *arm_sci, > } > } > > + if (MATCH_OPTION("agent_id", ptr, oparg)) { > + unsigned long val = parse_ulong(oparg); > + > + if (!val || val > 255) { > + fprintf(stderr, "An invalid ARM_SCI agent_id specified (%lu). Valid range [1..255]\n", > + val); > + ret = ERROR_INVAL; > + goto out; > + } > + arm_sci->agent_id = val; > + } > + > ptr = strtok(NULL, ","); > } > > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c > index 4181c10538..ddadc89148 100644 > --- a/xen/arch/arm/dom0less-build.c > +++ b/xen/arch/arm/dom0less-build.c > @@ -299,6 +299,17 @@ static int __init domu_dt_sci_parse(struct dt_device_node *node, > d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_NONE; > else if ( !strcmp(sci_type, "scmi_smc") ) > d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; > + else if ( !strcmp(sci_type, "scmi_smc_multiagent") ) > + { > + uint32_t agent_id = 0; > + > + if ( !dt_property_read_u32(node, "xen,sci-agent-id", &agent_id) || > + agent_id > UINT8_MAX ) > + return -EINVAL; > + > + d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA; > + d_cfg->arch.arm_sci_agent_id = agent_id; > + } > else > { > printk(XENLOG_ERR "xen,sci_type in not valid (%s) for domain %s\n", > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > index 986a456f17..0796561306 100644 > --- a/xen/arch/arm/domain_build.c > +++ b/xen/arch/arm/domain_build.c > @@ -86,6 +86,37 @@ int __init parse_arch_dom0_param(const char *s, const char *e) > return -EINVAL; > } > > +/* SCMI agent ID for dom0 obtained from xen,sci container */ > +#define SCMI_AGENT_ID_INVALID UINT8_MAX > + > +static uint8_t __init get_dom0_scmi_agent_id(void) > +{ > + const struct dt_device_node *config_node; > + u32 val; > + const struct dt_property *prop; > + > + config_node = dt_find_compatible_node(NULL, NULL, "xen,sci"); > + if ( !config_node ) > + return SCMI_AGENT_ID_INVALID; > + > + prop = dt_find_property(config_node, "xen,dom0-sci-agent-id", NULL); > + if ( !prop ) > + return SCMI_AGENT_ID_INVALID; > + > + if ( !dt_property_read_u32(config_node, "xen,dom0-sci-agent-id", &val) ) > + return SCMI_AGENT_ID_INVALID; > + > + if ( val >= SCMI_AGENT_ID_INVALID ) > + { > + printk(XENLOG_WARNING > + "Invalid xen,dom0-sci-agent-id=%u, SCMI disabled for Dom0\n", > + val); > + return SCMI_AGENT_ID_INVALID; > + } > + > + return val; > +} > + > /* Override macros from asm/page.h to make them work with mfn_t */ > #undef virt_to_mfn > #define virt_to_mfn(va) _mfn(__virt_to_mfn(va)) > @@ -509,7 +540,7 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo, > dt_property_name_is_equal(prop, "linux,uefi-mmap-start") || > dt_property_name_is_equal(prop, "linux,uefi-mmap-size") || > dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-size") || > - dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-ver")) > + dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-ver") ) > continue; Spurious change > +static int scmi_dt_assign_device(struct domain *d, > + struct dt_phandle_args *ac_spec) > +{ > + struct scmi_channel *agent_channel; > + uint32_t scmi_device_id = ac_spec->args[0]; > + int ret; > + > + if ( !d->arch.sci_data ) > + return 0; > + > + /* The access-controllers is specified for DT dev, but it's not a SCMI */ > + if ( ac_spec->np != scmi_data.dt_dev ) > + return 0; This comparison can erroneously fail when the pointers point to different copies of the same data > + agent_channel = d->arch.sci_data; > + > + spin_lock(&agent_channel->lock); > + > + ret = scmi_assign_device(agent_channel->agent_id, scmi_device_id, > + SCMI_BASE_DEVICE_ACCESS_ALLOW); > + if ( ret ) > + { > + printk(XENLOG_ERR > + "scmi: could not assign dev for %pd agent:%d dev_id:%u (%d)", > + d, agent_channel->agent_id, scmi_device_id, ret); > + } > + > + spin_unlock(&agent_channel->lock); > + return ret; > +} > + > +static int collect_agent_id(struct scmi_channel *agent_channel) > +{ > + int ret; > + scmi_msg_header_t hdr; > + struct scmi_msg_base_discover_agent_p2a da_rx; > + struct scmi_msg_base_discover_agent_a2p da_tx; > + > + ret = map_channel_memory(agent_channel); > + if ( ret ) > + return ret; > + > + hdr.id = SCMI_BASE_DISCOVER_AGENT; > + hdr.type = 0; > + hdr.protocol = SCMI_BASE_PROTOCOL; > + > + da_tx.agent_id = agent_channel->agent_id; > + > + ret = do_smc_xfer(agent_channel, &hdr, &da_tx, sizeof(da_tx), &da_rx, > + sizeof(da_rx)); > + if ( agent_channel->domain_id != DOMID_XEN ) > + unmap_channel_memory(agent_channel); > + if ( ret ) > + return ret; > + > + printk(XENLOG_DEBUG "id=0x%x name=%s\n", da_rx.agent_id, da_rx.name); > + agent_channel->agent_id = da_rx.agent_id; > + return 0; > +} > + > +static __init int collect_agents(struct dt_device_node *scmi_node) > +{ > + const struct dt_device_node *config_node; > + const __be32 *prop; > + uint32_t len; > + const __be32 *end; > + uint32_t cells_per_entry = 3; /* Default to 3 cells if property is absent. */ > + > + config_node = dt_find_compatible_node(NULL, NULL, "xen,sci"); > + if ( !config_node ) > + { > + printk(XENLOG_WARNING "scmi: xen,sci node not found, no agents to collect.\n"); > + return -ENOENT; > + } > + > + /* Check for the optional '#scmi-secondary-agents-cells' property. */ > + if ( dt_property_read_u32(config_node, "#scmi-secondary-agents-cells", > + &cells_per_entry) ) > + { > + if ( cells_per_entry != 2 && cells_per_entry != 3 ) > + { > + printk(XENLOG_ERR "scmi: Invalid #scmi-secondary-agents-cells value: %u\n", > + cells_per_entry); > + return -EINVAL; > + } > + } > + > + prop = dt_get_property(config_node, SCMI_SECONDARY_AGENTS, &len); > + if ( !prop ) > + { > + printk(XENLOG_ERR "scmi: No %s property found, no agents to collect.\n", > + SCMI_SECONDARY_AGENTS); > + return -EINVAL; > + } > + > + /* Validate that the property length is a multiple of the cell size. */ > + if ( len == 0 || len % (cells_per_entry * sizeof(uint32_t)) != 0 ) > + { > + printk(XENLOG_ERR "scmi: Invalid length of %s property: %u for %u cells per entry\n", > + SCMI_SECONDARY_AGENTS, len, cells_per_entry); > + return -EINVAL; > + } > + > + end = (const __be32 *)((const u8 *)prop + len); > + > + for ( ; prop < end; ) > + { > + uint32_t agent_id; > + uint32_t smc_id; > + uint32_t shmem_phandle; > + struct dt_device_node *node; > + u64 addr, size; > + int ret; > + struct scmi_channel *agent_channel; > + > + smc_id = be32_to_cpu(*prop++); > + shmem_phandle = be32_to_cpu(*prop++); > + > + if ( cells_per_entry == 3 ) > + agent_id = be32_to_cpu(*prop++); > + else > + agent_id = SCMI_BASE_AGENT_ID_OWN; > + > + node = dt_find_node_by_phandle(shmem_phandle); > + if ( !node ) > + { > + printk(XENLOG_ERR "scmi: Could not find shmem node for agent %u\n", > + agent_id); > + return -EINVAL; > + } > + > + ret = dt_device_get_address(node, 0, &addr, &size); > + if ( ret ) > + { > + printk(XENLOG_ERR > + "scmi: Could not read shmem address for agent %u: %d\n", > + agent_id, ret); > + return ret; > + } > + > + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) ) > + { > + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); > + return -EINVAL; > + } > + > + agent_channel = smc_create_channel(agent_id, smc_id, addr); > + if ( IS_ERR(agent_channel) ) > + { > + printk(XENLOG_ERR "scmi: Could not create channel for agent %u: %ld\n", > + agent_id, PTR_ERR(agent_channel)); > + return PTR_ERR(agent_channel); > + } > + > + if ( cells_per_entry == 2 ) > + { > + ret = collect_agent_id(agent_channel); > + if ( ret ) > + return ret; > + } > + > + printk(XENLOG_DEBUG "scmi: Agent %u SMC %X addr %lx\n", agent_channel->agent_id, > + smc_id, (unsigned long)addr); > + } > + > + return 0; > +} > + > +static int scmi_domain_init(struct domain *d, > + struct xen_domctl_createdomain *config) > +{ > + struct scmi_channel *channel; > + int ret; > + > + if ( !scmi_data.initialized ) > + return 0; > + > + /* > + * SCMI support is configured via: > + * - For dom0: xen,dom0-sci-agent-id property under the xen,sci container > + * - For dom0less: xen,sci-agent-id in the domain node > + * The config->arch.arm_sci_type and config->arch.arm_sci_agent_id > + * are already set by domain_build.c or dom0less-build.c > + */ > + > + if ( config->arch.arm_sci_type == XEN_DOMCTL_CONFIG_ARM_SCI_NONE ) > + return 0; > + > + channel = acquire_scmi_channel(d, config->arch.arm_sci_agent_id); > + if ( IS_ERR(channel) ) > + { > + printk(XENLOG_ERR > + "scmi: Failed to acquire SCMI channel for agent_id %u: %ld\n", > + config->arch.arm_sci_agent_id, PTR_ERR(channel)); > + return PTR_ERR(channel); > + } > + > + printk(XENLOG_INFO > + "scmi: Acquire channel id = 0x%x, domain_id = %d paddr = 0x%lx\n", > + channel->agent_id, channel->domain_id, channel->paddr); > + > + /* > + * Dom0 (if present) needs to have an access to the guest memory range > + * to satisfy iomem_access_permitted() check in XEN_DOMCTL_iomem_permission > + * domctl. > + */ > + if ( hardware_domain && !is_hardware_domain(d) ) > + { > + ret = iomem_permit_access(hardware_domain, paddr_to_pfn(channel->paddr), > + paddr_to_pfn(channel->paddr + PAGE_SIZE - 1)); > + if ( ret ) > + goto error; > + } > + > + d->arch.sci_data = channel; > + d->arch.sci_enabled = true; > + > + return 0; > + > +error: > + relinquish_scmi_channel(channel); > + return ret; > +} > + > +int scmi_domain_sanitise_config(struct xen_domctl_createdomain *config) > +{ > + if ( config->arch.arm_sci_type != XEN_DOMCTL_CONFIG_ARM_SCI_NONE && > + config->arch.arm_sci_type != XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA ) > + { > + dprintk(XENLOG_INFO, "scmi: Unsupported ARM_SCI type\n"); > + return -EINVAL; > + } > + > + return 0; > +} > + > +static int scmi_relinquish_resources(struct domain *d) > +{ > + int ret; > + struct scmi_channel *channel, *agent_channel; > + scmi_msg_header_t hdr; > + struct scmi_msg_base_reset_agent_cfg_a2p tx; > + > + if ( !d->arch.sci_data ) > + return 0; > + > + agent_channel = d->arch.sci_data; > + > + spin_lock(&agent_channel->lock); > + tx.agent_id = agent_channel->agent_id; > + spin_unlock(&agent_channel->lock); > + > + channel = get_channel_by_id(scmi_data.hyp_channel_agent_id); > + if ( !channel ) > + { > + printk(XENLOG_ERR > + "scmi: Unable to get Hypervisor scmi channel for domain %d\n", > + d->domain_id); > + return -EINVAL; > + } > + > + hdr.id = SCMI_BASE_RESET_AGENT_CONFIGURATION; > + hdr.type = 0; > + hdr.protocol = SCMI_BASE_PROTOCOL; > + > + tx.flags = 0; is this correct? > + ret = do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0); > + if ( ret == -EOPNOTSUPP ) > + return 0; > + > + return ret; > +} > + > +static void scmi_domain_destroy(struct domain *d) > +{ > + struct scmi_channel *channel; > + > + if ( !d->arch.sci_data ) > + return; > + > + channel = d->arch.sci_data; > + spin_lock(&channel->lock); > + > + relinquish_scmi_channel(channel); > + printk(XENLOG_DEBUG "scmi: Free domain %d\n", d->domain_id); > + > + d->arch.sci_data = NULL; > + d->arch.sci_enabled = false; > + > + spin_unlock(&channel->lock); > +} > + > +static bool scmi_handle_call(struct cpu_user_regs *regs) > +{ > + uint32_t fid = (uint32_t)get_user_reg(regs, 0); > + struct scmi_channel *agent_channel; > + struct domain *d = current->domain; > + struct arm_smccc_res resp; > + bool res = false; > + > + if ( !sci_domain_is_enabled(d) ) > + return false; > + > + agent_channel = d->arch.sci_data; > + spin_lock(&agent_channel->lock); > + > + if ( agent_channel->func_id != fid ) > + { > + res = false; > + goto unlock; > + } > + > + arm_smccc_1_1_smc(fid, > + get_user_reg(regs, 1), > + get_user_reg(regs, 2), > + get_user_reg(regs, 3), > + get_user_reg(regs, 4), > + get_user_reg(regs, 5), > + get_user_reg(regs, 6), > + get_user_reg(regs, 7), > + &resp); > + > + set_user_reg(regs, 0, resp.a0); > + set_user_reg(regs, 1, resp.a1); > + set_user_reg(regs, 2, resp.a2); > + set_user_reg(regs, 3, resp.a3); > + res = true; > +unlock: > + spin_unlock(&agent_channel->lock); > + > + return res; > +} > + > +static const struct sci_mediator_ops scmi_ops = { > + .domain_init = scmi_domain_init, > + .domain_destroy = scmi_domain_destroy, > + .relinquish_resources = scmi_relinquish_resources, > + .handle_call = scmi_handle_call, > + .dom0_dt_handle_node = scmi_dt_handle_node, > + .domain_sanitise_config = scmi_domain_sanitise_config, > + .assign_dt_device = scmi_dt_assign_device, > +}; > + > +static int __init scmi_check_smccc_ver(void) > +{ > + if ( smccc_ver < ARM_SMCCC_VERSION_1_1 ) > + { > + printk(XENLOG_WARNING > + "scmi: No SMCCC 1.1 support, SCMI calls forwarding disabled\n"); > + return -ENOSYS; > + } > + > + return 0; > +} > + > +static int __init scmi_dt_hyp_channel_read(struct dt_device_node *scmi_node, > + struct scmi_data *scmi_data, > + u64 *addr) > +{ > + int ret; > + u64 size; > + > + if ( !dt_property_read_u32(scmi_node, "arm,smc-id", &scmi_data->func_id) ) > + { > + printk(XENLOG_ERR "scmi: unable to read smc-id from DT\n"); > + return -ENOENT; > + } > + > + ret = scmi_dt_read_hyp_channel_addr(scmi_node, addr, &size); > + if ( IS_ERR_VALUE(ret) ) > + return -ENOENT; > + > + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) ) > + { > + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); > + return -EINVAL; > + } > + > + return 0; > +} > + > +static __init int scmi_probe(struct dt_device_node *scmi_node, const void *data) > +{ > + u64 addr; > + int ret; > + struct scmi_channel *channel; > + unsigned int n_agents; > + scmi_msg_header_t hdr; > + struct scmi_msg_base_attributes_p2a rx; > + > + ASSERT(scmi_node != NULL); > + > + /* > + * Only bind to the SCMI node provided by Xen under the xen,sci container > + * (e.g. /chosen/xen/xen_scmi_config/scmi). This avoids binding to firmware > + * SCMI nodes that belong to the host OSPM and keeps the mediator scoped to > + * Xen-provided configuration only. > + */ > + if ( !scmi_is_under_xen_sci(scmi_node) ) > + return -ENODEV; > + > + INIT_LIST_HEAD(&scmi_data.channel_list); > + spin_lock_init(&scmi_data.channel_list_lock); > + > + if ( !acpi_disabled ) > + { > + printk(XENLOG_WARNING "scmi: is not supported when using ACPI\n"); > + return -EINVAL; > + } > + > + ret = scmi_check_smccc_ver(); > + if ( ret ) > + return ret; > + > + ret = scmi_dt_hyp_channel_read(scmi_node, &scmi_data, &addr); > + if ( ret ) > + return ret; > + > + scmi_data.dt_dev = scmi_node; > + > + channel = smc_create_channel(SCMI_BASE_AGENT_ID_OWN, scmi_data.func_id, addr); > + if ( IS_ERR(channel) ) > + goto out; > + > + /* Mark as Xen management channel before collecting agent ID */ > + channel->domain_id = DOMID_XEN; > + > + /* Request agent id for Xen management channel */ > + ret = collect_agent_id(channel); > + if ( ret ) > + goto error; > + > + /* Save the agent id for Xen management channel */ > + scmi_data.hyp_channel_agent_id = channel->agent_id; > + > + hdr.id = SCMI_BASE_PROTOCOL_ATTIBUTES; > + hdr.type = 0; > + hdr.protocol = SCMI_BASE_PROTOCOL; > + > + ret = do_smc_xfer(channel, &hdr, NULL, 0, &rx, sizeof(rx)); > + if ( ret ) > + goto error; > + > + n_agents = SCMI_FIELD_GET(SCMI_BASE_ATTR_NUM_AGENT, rx.attributes); > + printk(XENLOG_DEBUG "scmi: Got agent count %d\n", n_agents); > + ret = collect_agents(scmi_node); > + if ( ret ) > + goto error; > + > + ret = sci_register(&scmi_ops); > + if ( ret ) > + { > + printk(XENLOG_ERR "SCMI: mediator already registered (ret = %d)\n", > + ret); > + return ret; > + } > + > + scmi_data.initialized = true; > + goto out; > + > +error: > + unmap_channel_memory(channel); This might cause the ASSERT at the beginning of unmap_channel_memory to trigger > + free_channel_list(); > +out: > + return ret; > +} > + > +static const struct dt_device_match scmi_smc_match[] __initconst = { > + DT_MATCH_COMPATIBLE("arm,scmi-smc"), > + { /* sentinel */ }, > +}; > + > +DT_DEVICE_START(scmi_smc_ma, "SCMI SMC MEDIATOR", DEVICE_FIRMWARE) > + .dt_match = scmi_smc_match, > + .init = scmi_probe, > +DT_DEVICE_END > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * tab-width: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h > index d30a288592..8f0f68544e 100644 > --- a/xen/include/public/arch-arm.h > +++ b/xen/include/public/arch-arm.h > @@ -329,6 +329,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); > > #define XEN_DOMCTL_CONFIG_ARM_SCI_NONE 0 > #define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC 1 > +#define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA 2 > > struct xen_arch_domainconfig { > /* IN/OUT */ > @@ -355,6 +356,8 @@ struct xen_arch_domainconfig { > uint32_t clock_frequency; > /* IN */ > uint8_t arm_sci_type; > + /* IN */ > + uint8_t arm_sci_agent_id; > }; > #endif /* __XEN__ || __XEN_TOOLS__ */ > > -- > 2.34.1 > From xen-devel-bounces@lists.xenproject.org Fri Jan 23 03:05:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 03:05:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212028.1523374 (Exim 4.92) (envelope-from ) id 1vj7Tc-0008AI-AS; Fri, 23 Jan 2026 03:04:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212028.1523374; Fri, 23 Jan 2026 03:04:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vj7Tc-0008AB-7O; Fri, 23 Jan 2026 03:04:48 +0000 Received: by outflank-mailman (input) for mailman id 1212028; Fri, 23 Jan 2026 03:04:46 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vj7TZ-0008A5-UT for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 03:04:46 +0000 Received: from out28-145.mail.aliyun.com (out28-145.mail.aliyun.com [115.124.28.145]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3eeeabe4-f808-11f0-b15e-2bf370ae4941; Fri, 23 Jan 2026 04:04:41 +0100 (CET) Received: from localhost(mailfrom:houwenlong.hwl@antgroup.com fp:SMTPD_---.gDSnk6b_1769137470 cluster:ay29) by smtp.aliyun-inc.com; Fri, 23 Jan 2026 11:04:30 +0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3eeeabe4-f808-11f0-b15e-2bf370ae4941 DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=antgroup.com; s=default; t=1769137474; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; bh=z7QKQEit5IiI9wEnKzSXeZlrU6DLi2VCu28yIrU4sWs=; b=iX7hzYSA93ykBxdaR2ZcKhMIMZbgTe9InBDBMrAojhu0FYPgcR4qGytnB22U2Njown7AM5yx+jAFNHv+bBb4SeRZIVD5UUJc8u6KwofagH6zVbzh2Jn9LlvDuQUOhAYyBilwJXs6GisFeZclz5Uyjwzyb/+rD82rrBGjzkzGuxw= Date: Fri, 23 Jan 2026 11:04:30 +0800 From: Hou Wenlong To: Borislav Petkov Cc: linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Boris Ostrovsky , Peter Zijlstra , "Rafael J. Wysocki" , K Prateek Nayak , Li Chen , Brian Gerst , Sohil Mehta , Tim Chen , Patryk Wlazlyn , Eric Dumazet , xen-devel@lists.xenproject.org Subject: Re: [PATCH 1/2] x86/smp: Move the static call update for 'smp_ops' into smp_prepare_boot_cpu() Message-ID: <20260123030430.GA75451@k08j02272.eu95sqa> References: <20260122142156.GEaXIyhNQeGvOR5yyu@fat_crate.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260122142156.GEaXIyhNQeGvOR5yyu@fat_crate.local> User-Agent: Mutt/1.5.21 (2010-09-15) On Thu, Jan 22, 2026 at 03:21:56PM +0100, Borislav Petkov wrote: > On Thu, Jan 22, 2026 at 10:15:43PM +0800, Hou Wenlong wrote: > > The commit 1f60230cdc63 ("x86/smp: Use static_call for > > arch_send_call_function_ipi()") changed to use a static call for > > arch_send_call_function_ipi(), which causes two problems: > > > > First, the KVM guest also changes 'smp_ops.send_call_func_ipi' when the > > PV sched yield feature is available. However, the missing > > static_call_update() breaks the PV sched yield feature. > > > > Additionally, xen_smp_init() is called before static_call_init() during > > the booting of the XENPV guest, which triggers a warning in > > __static_call_update(). > > > > To simplify, move the static call update for 'smp_ops' into > > smp_prepare_boot_cpu() to address these two problems together. > > > > Fixes: 1f60230cdc63 ("x86/smp: Use static_call for arch_send_call_function_ipi()") > > Signed-off-by: Hou Wenlong > > --- > > I'm not sure if the XEN part is okay or not. I think there should be no > > IPI before smp_prepare_boot_cpu(), and even if there is, it's okay for > > the KVM guest to use the native version before smp_prepare_boot_cpu(). > > All three commits zapped from tip:x86/core. > > We can try again once this is resolved. > Get it, thanks! > Thx. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette From xen-devel-bounces@lists.xenproject.org Fri Jan 23 09:09:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 09:09:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212076.1523383 (Exim 4.92) (envelope-from ) id 1vjDAX-0007ln-Q2; Fri, 23 Jan 2026 09:09:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212076.1523383; Fri, 23 Jan 2026 09:09: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 1vjDAX-0007lg-NA; Fri, 23 Jan 2026 09:09:29 +0000 Received: by outflank-mailman (input) for mailman id 1212076; Fri, 23 Jan 2026 09:09: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 1vjDAV-0007la-Rx for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 09:09:27 +0000 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [2a00:1450:4864:20::32d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3744f6a2-f83b-11f0-b15e-2bf370ae4941; Fri, 23 Jan 2026 10:09:26 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-47ee2715254so10673615e9.3 for ; Fri, 23 Jan 2026 01:09:26 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1c24f15sm5256725f8f.18.2026.01.23.01.09.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Jan 2026 01:09:25 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3744f6a2-f83b-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769159366; x=1769764166; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=s58SY+7x1BZaLsDJ3kgAt3pm4Ke7/V4OsvokX/cUX1o=; b=NiKkoFnwtFyIwgsCC8FROeCQKU+4Vhf6I0RYIlprDsCcmKs7PPwFwx3MkmN9ZBeF2f Xh118GrgysLShhJZuoeNzga9zZKpvXNG+Dc7SqeUU/9ImbY0V2Gh/ezxjFLw46ZCEgkE PSUdLpb8kcu5IyH3Oa3jzB0R5k+XLscj0IcnE0/u1KmyRyRjmJcWIRa/8wQKB2NiPhhB 1zPgzM/gyb+rPKEqnHiikoFuJep/f7nQz9k5OwUIsUVqMe2syahcA+yHOtg2yX8cY+j2 yprYxgk610870JI0KFnegGu+IPLBZNAlsTzJEiJBx/ECJsAOIKg1rM5B8ayXKYnxuzgR VOPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769159366; x=1769764166; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=s58SY+7x1BZaLsDJ3kgAt3pm4Ke7/V4OsvokX/cUX1o=; b=aHn98Il1sX3CwQOEYacvqp7EBuBI6hT0qYarCtCYgDW4nh+/sfXIYcUp94ocxsoLNV u8f2DjLEWS2ghQG0JteTYhEE5zJ0UW71zRALICPfprSqjibpadhGhwcE47KeCgKdmSrh D78oof4JMh5rtaQEL6CQsZKQfZ7d6+gz97PxoekTGWwX8x3bxi6o6bnHU/H2dbfUIv6X oGt+qxOEp74G6y5tfCZ9Ni0TVtn++lPf762tJcsrplSQUTgNWvPSq1E259GJlO+ZRCsl YqYPBfQ0JysUP8StM0v2mfR7SK00mqN4sxUom62XdGMZldw+AuO1uEVvs08Ze7u2m8L6 ciLA== X-Forwarded-Encrypted: i=1; AJvYcCVKurfXcM17vCcRe3KHDsjxw9Hz/UXY2/n+RWDyx2BSLPQX/L9xd78kJ8XbBQjrP/h8qx8558WZOlA=@lists.xenproject.org X-Gm-Message-State: AOJu0YxfBf84Y1imxmL6entb5PsRTxXB4rPOUEhvVYvutB+L/W+ydeNs SQSH6kfFTDc/CwS9kk1mUbjtg2WLKN0ulCQquYPnl9Hl0t+pTR4f28qT X-Gm-Gg: AZuq6aJj/u08nJeQNtC2Kl1fwUUQhJgtoW+I4a/3LrGZv4PI+E2Ksp/JXPXG1d+Uevy 9WK5qYejShdi/W8dNrJgQdTVcpG2GPYXvVQe+Aa6JGnl3SWB/PodmJTpODrPDms6IqZ89f75yUU soqTk4ICNeJRd5voB1EVf75xy0DMORrpiDPqnEJK1TITAkFa5WFyGX+/Mtko0c92Wbna0pO3/Ey CG1218I8khT6sYF0aWMrmpGxiZfgeQyii+AgzQ8l0U8QS/1kMvzjylZLwGPN6MPsqmMYdD1Zqs/ KppKrN741ww2GaQQyKA9rVUJq9u8/ZfNoZu4SWJbpZracZt+yVAdW10CuM9/26+Lygy/sv9eTVI 5/9AfVrcPrHlv17rj9/kypYKKN8A6/6/TSspuy5mBM8Nn0SYGfmZnk6MCg1NVKpx1ja3HHxN3OZ hSzQgYV34LHfHcfkb+IeoB1rcMUz4rC1Xw/6MpK1iOnFFDFP3MsE1TZyCaiVRVO5i1wlVxWosrl g== X-Received: by 2002:a05:600c:a18e:b0:480:3b4e:41ba with SMTP id 5b1f17b1804b1-4804f8235damr15437175e9.18.1769159365449; Fri, 23 Jan 2026 01:09:25 -0800 (PST) Message-ID: Date: Fri, 23 Jan 2026 10:09:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Oleksii Kurochko Subject: Re: [PATCH v2] xen/riscv: dump GPRS and CSRs on unexpected traps To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <843ba134-099c-49a1-8561-5e364b630bc8@suse.com> Content-Language: en-US In-Reply-To: <843ba134-099c-49a1-8561-5e364b630bc8@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/19/26 9:34 AM, Jan Beulich wrote: > On 16.01.2026 17:16, Oleksii Kurochko wrote: >> Provide more context on the exception state when an unexpected >> exception occurs by dumping various Supervisor, Virtual Supervisor >> and Hypervisor CSRs, and GPRs pertaining to the trap. >> >> Signed-off-by: Oleksii Kurochko >> --- >> Changes in v2 >> - Address coments about print_csr() macros and dump_csrs(). >> - Add dumping of GPRs pertaining to the trap. >> --- >> xen/arch/riscv/traps.c | 82 ++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 82 insertions(+) >> >> diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c >> index e9c967786312..4e0df698552f 100644 >> --- a/xen/arch/riscv/traps.c >> +++ b/xen/arch/riscv/traps.c >> @@ -17,6 +17,13 @@ >> #include >> #include >> >> +#define print_csr(csr) \ >> + printk("\t" #csr ": %016lx\n", csr_read(csr)); > This prints the CSR_ prefix of the internally used constants. Is this useful > (rather than extra clutter)? No, the prefix isn't really useful. It was printed so only because all CSRs registers defintions start on CSR_*. > Unlike for the GPRs this also prints the register > names in upper case. That may be fine, or may not be. I will follow then like it is written in RISC-V spec for consistency. > The values printed also > won't align, which may make reading more difficult. Do you expect the similar alignment like for GPRs? >> +#define print_gprs(regs, reg1, reg2) \ >> + printk("\t%-7s: %016lx %-7s: %016lx\n", \ >> + #reg1, (regs)->reg1, #reg2, (regs)->reg2) > Yes, two per line is certainly helpful. Why not also for some of the CSRs. It is less clear how it would be better to group them. I thought about CSR_STVEC: .... CSR_VSTVEC: .... CSR_STTATUS: ... CSR_VSSTATUS: .... So group them in S-mode mode register and VS-mode register. >> @@ -99,12 +106,87 @@ static const char *decode_cause(unsigned long cause) >> return decode_trap_cause(cause); >> } >> >> +static void dump_general_regs(const struct cpu_user_regs *regs) >> +{ >> + printk("\nDumping GPRs...\n"); > Register names alone will be meaningful enough? Be mindful of serial line > bandwidth as well as screen resolution. Agree, we could drop this print. (Then probably the same could be for Supervisor CSRs and Virtual Supervisor CSRs, etc as it is clear based on the name which one CSR it is) >> + print_gprs(regs, ra, sp); >> + print_gprs(regs, gp, tp); >> + print_gprs(regs, t0, t1); >> + print_gprs(regs, t2, s0); >> + print_gprs(regs, s1, a0); >> + print_gprs(regs, a1, a2); >> + print_gprs(regs, a3, a4); >> + print_gprs(regs, a5, a6); >> + print_gprs(regs, a7, s2); >> + print_gprs(regs, s3, s4); >> + print_gprs(regs, s5, s6); >> + print_gprs(regs, s7, s8); >> + print_gprs(regs, s9, s10); >> + print_gprs(regs, s11, t3); >> + print_gprs(regs, t4, t5); >> + print_gprs(regs, t6, sepc); >> + print_gprs(regs, sstatus, hstatus); > The last three aren't GPRs. Why would they be logged here? (All three also > being logged in dump_csrs() would further require some disambiguation in > the output, for people to not need to go look at the source code every > time.) Agree, that it would be better to print it with the CSRs. It was print here only as they are in the same structure with GPRs. >> +} >> + >> +static void dump_csrs(unsigned long cause) >> +{ >> + unsigned long hstatus; >> + >> + printk("\nDumping CSRs...\n"); >> + >> + printk("Supervisor CSRs\n"); >> + print_csr(CSR_STVEC); >> + print_csr(CSR_SATP); >> + print_csr(CSR_SEPC); >> + >> + hstatus = csr_read(CSR_HSTATUS); >> + >> + printk("\tCSR_STVAL: %016lx%s\n", csr_read(CSR_STVAL), >> + (hstatus & HSTATUS_GVA) ? ", (guest virtual address)" : ""); >> + >> + printk("\tCSR_SCAUSE: %016lx\n", cause); >> + printk("\t\tDescription: %s\n", decode_cause(cause)); >> + print_csr(CSR_SSTATUS); >> + >> + printk("\nVirtual Supervisor CSRs\n"); >> + print_csr(CSR_VSTVEC); >> + print_csr(CSR_VSATP); >> + print_csr(CSR_VSEPC); >> + print_csr(CSR_VSTVAL); >> + cause = csr_read(CSR_VSCAUSE); >> + printk("\tCSR_VSCAUSE: %016lx\n", cause); >> + printk("\t\tDescription: %s\n", decode_cause(cause)); >> + print_csr(CSR_VSSTATUS); > As before, imo justification is wanted (in the description) for logging > VS* values. It is hard to describe in general why they could be needed. The best I can come up is: Dump VS* CSRs to provide full guest exception context. When handling traps originating from VS-mode, host CSRs alone do not describe the fault; VSCAUSE, VSEPC, VSTVAL, and related state are required to diagnose guest crashes and hypervisor misconfiguration, and to correlate host-side handling with guest-visible exceptions. Does it good enough justification? ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Jan 23 09:25:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 09:25:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212087.1523393 (Exim 4.92) (envelope-from ) id 1vjDPS-0001zG-VF; Fri, 23 Jan 2026 09:24:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212087.1523393; Fri, 23 Jan 2026 09:24:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjDPS-0001z9-Sc; Fri, 23 Jan 2026 09:24:54 +0000 Received: by outflank-mailman (input) for mailman id 1212087; Fri, 23 Jan 2026 09:24: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 1vjDPR-0001z3-EV for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 09:24:53 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5c196205-f83d-11f0-9ccf-f158ae23cfc8; Fri, 23 Jan 2026 10:24:48 +0100 (CET) Received: from BY1PR03MB7875.namprd03.prod.outlook.com (2603:10b6:a03:5b1::10) by SJ0PR03MB7127.namprd03.prod.outlook.com (2603:10b6:a03:4e6::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Fri, 23 Jan 2026 09:24:43 +0000 Received: from BY1PR03MB7875.namprd03.prod.outlook.com ([fe80::2e3c:781a:5f98:7f19]) by BY1PR03MB7875.namprd03.prod.outlook.com ([fe80::2e3c:781a:5f98:7f19%5]) with mapi id 15.20.9542.008; Fri, 23 Jan 2026 09:24: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: 5c196205-f83d-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=YcxBNtmW7t3mn1NlRSzkJQz92X6xBIHWGkdf60GOpfj0+zW/YlXALtRYU49Oa5yqhde/6h8yGvTXG/P3TJj4QaV5WofhFltzT61XrADjFuJqKir3mBZvmV15xKiYEgWQSuXjyCcGMD6cEGWRA/eFH3a0OPJH6rCc+nJ4fBdOBRdFKniseDXxhRvhs7BpT0YDlFBXM6dsY06EbdUh94aridZy7pdmLd5sfZDnhhpYaFon2quiFwjFaGj0OHypCeFiOkjotFI4EgiqfYcAlUwnAHaFLSGNnrqt8jlNwZNW9yW2iRkLS4elZAsDXQoNAbhzPLRlcBlhsKnpt9Wqb1cMDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pmTpNVi3r6er9zMHlLRWeHxm8slqUa3wab6mLxwHHzc=; b=O9GIXRZWuNSff2qJnlxD+7WcMPNqc2F0mzeGkl4f96AUJGmZu4k1qWhKcMI31nF9hGKbL2W0etqCX/YtpPNLi1j7do5a6Wr4sibJqaO0H1Sasu4QRPSRuuMG7wjE/CEG7VMsaF3SjVJrl8WbHIR3pxGzMjUqwkdLUhVs0nqrtRb5TwSQ/19eiusqM/oAyRcWZyvs+SEBjXSkoiQKL/CtO6P/9FECAJW2vi38CQsP2UYGtQKQ282vuwOyVFlParbxr+dDhG7e5X/eP8hrv98d1KN6EaeffOJ1N+/H7RVOelf1iJntoTKiTJH0XcBFCKyJ002pKWm/dpfVrLgywavzFA== 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=pmTpNVi3r6er9zMHlLRWeHxm8slqUa3wab6mLxwHHzc=; b=FQOEidZKm5rsVU6598qOtq+FbjQ3XaKVttdiTsCEUzZ+Ajrxln+zuCBBP3iqEq887gIMFh7Jvh6+qIhscflSkaTn09+yuriaK+ICClRDx9LbYChmJi24M6ZV85f/anCQWb6fLGzhy1CeObiPvQVNOUJdt+Hg2dvmL5QZadAgVkA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Fri, 23 Jan 2026 10:24:38 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= Cc: Andrew Cooper , "xen-devel@lists.xenproject.org" , Jan Beulich Subject: Re: MTRR init sequence in Xen Message-ID: References: <145af46c-eab5-4d0f-ba35-4ae646c0e4cd@suse.com> <64adf935-1fd8-4d3c-b9b2-cafb0e065463@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <64adf935-1fd8-4d3c-b9b2-cafb0e065463@suse.com> X-ClientProxiedBy: MA3P292CA0060.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:49::19) To BY1PR03MB7875.namprd03.prod.outlook.com (2603:10b6:a03:5b1::10) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7875:EE_|SJ0PR03MB7127:EE_ X-MS-Office365-Filtering-Correlation-Id: 6abb09ed-c068-4726-391c-08de5a613dae 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?TW9EMzBZMU5Cc0hsL1l1R2Z2c1ZRZG9XdTJwWWZqV2N1TDFsTzJ2NGJPT1lZ?= =?utf-8?B?NEU0U2dXeHpGNGJ2RHQwYmN3RHlMUHZLSHdJaHlZNzBRaXlQUEk4cFpYS2Yv?= =?utf-8?B?RmVpWVhMM2NWRHVndXUvVnBSdGg4cmZiSzBBRTRsUXc5bDB5aWloK2lqNDQx?= =?utf-8?B?SHk4aWNvQXVrYURWR0VSRHJVOFp4Q0wwV2krNHM2Y0g5MUZkVFdnRXI0V1d1?= =?utf-8?B?UDhzOWRFTEhReDRZcW5kUWpBbS9jRWRyaHRlU1B3S292ejdqSmpJdXN5ZmFL?= =?utf-8?B?OThlVzJaWHpOMnRudE9BZU1hMTYzOWlYQlVOZEwyVE5ZZUNLYVAwWnRzUjd5?= =?utf-8?B?UStQM0diVVgydDhMZVAvME9jNm9jc2Y1b1RHZFY3TGZzQkpnSlUrS3pMbElI?= =?utf-8?B?TVBxVllENkxkdzZmV1V6YmVoWkNLcm9LMlU2Z0ZleWd6ZlgzWWhKTjdpWW1Z?= =?utf-8?B?Q3d4YWdqRm1DSCtZVWxpVDJvT3Q2dUNUbWx5bitmVzJmejhSdVlQY1l6NTli?= =?utf-8?B?N2ttQnJrd2pXL1NUWnlTbmM5amVUb1pZSFFITlhXTUJBY1h0WGVGODRGME5G?= =?utf-8?B?V3JVYTNVc0NjbUxDSGJvV1crRHp0TUpHSG4yZm53NENpMEw0N0wraithakpi?= =?utf-8?B?aCtaWTVCajk3NXlBWENQUVJyNU5JbHJqUjNqOE91VmYwQUJBVmo1T093OTVQ?= =?utf-8?B?cFZUMXBTVU4weERqdXREbHoxcGR3RlY0UkZEU1krMU1uWGpLL0tKRStPSWZI?= =?utf-8?B?dWxCNVdsV3M0d01tajhnL2lseUZpdG1qUUM1MlA5dnQ1QXlHNlp0aUw3Vkla?= =?utf-8?B?TEloTXFvOVBkRjhOb0tuQUxTNmtIM29xOXpZbncrTjY1Qi9LRVRPTG9iK1Fh?= =?utf-8?B?TC9GYkp2d2VlMk9sR2MvSGhJWFNOWTg3NjJtdXBicm1YZ2ZCdkZpeVpLM3JZ?= =?utf-8?B?M2pwYmI3eHhOdGJHMWhrVTI1WktMUWlqdjNMVGZ6NmMxT2VvUlBqVDN1c0Jt?= =?utf-8?B?T3E3c25TN2kxYUxOOXdFUjFJUFJwSEMyTDFWUlVqUGQzcUFMQmMvL0xrYmF5?= =?utf-8?B?akRuUUxXNys0RC9ZNjNUbDFqYjROOEJjNEVjOEF5QzRXblhMVVJhYWdCUENG?= =?utf-8?B?TkpzN1VXUzlhTk1UZFBBbUo5SVVqQXZ4Vm9ZU2Q3cXNWYUFUd1YrUU9hODlo?= =?utf-8?B?RHJDL2ZiSGxGcUt2NldCM3Q0NWJCZE5MSnV6dU5objZJRHlRMU04UDdCRXh4?= =?utf-8?B?UGRGUnJMUDRjRTBrNXBCTlA5L240YnNpK3lmaGtScG9zbjJYOGpMenZtY0lL?= =?utf-8?B?Mkx2UndCRWpaMEFsd0toem5QaFViM2VBMDVzbWwreXpNV2R4SWdsTjRPakFR?= =?utf-8?B?ZUg5VEdwOWY0Y0h6OW5nRnZoYWJ2NTZVbmp3RzZUcW1TdmRGeG9oZ0dHR3oz?= =?utf-8?B?Q2syZ2RzMGdTcW5uUlRuazdwdmVEdUdMU21hWlBoVm5ZdzdyRnNnT3FUblN4?= =?utf-8?B?cGUzdHd5eDJydHV2cnNVMTNsU3IrYmZZNTFtMjBZZmtrM3FMalMvOGp5QTVi?= =?utf-8?B?YjkzSzVDME1uOXE2MDRGWU1RWTU4OWNvWW1RVDBXR2tzb1VBN1FXWmExRDJE?= =?utf-8?B?cElNOEkvTG1GWEk2djZMUVMrc0F1TFdMVU03aHBPL3NuWFJ4c2pXKzFLR001?= =?utf-8?B?WTI0ZzAyaytralR4RlR1VElEMlBCVmZPWTE2cExxZVBKRlJvSnBMNmx2NDd0?= =?utf-8?B?MUhCQlFvVnJFSDhvT1cvNTJZUEdGY1VaU2pJckdkZ1pFVTRpZWtIbm9BOCtH?= =?utf-8?B?NENML3pvZXgrUU9vQWhtc1JzK0JjVFRUTXhSRHpPUEx4NHhlWU5wenUyMVFu?= =?utf-8?B?NFFiMDlPWDlWSWMyL2lwRU1ydnZ1QXZjZXJ0RlhXNnZSVVltSHg1Q3ltYWFa?= =?utf-8?B?WXJRdEVBRFMrZ1o3MWFway9JTFVOeXFKTDN5cldmdmc2NnlrdFVNSWt5VUFY?= =?utf-8?B?VEtLdnNYdnR1ZFNQbENkZXVydU5sWGRYMUVPRWV0ak9ORXhqVTIySmptRjdk?= =?utf-8?B?RERENXlVdm14d29kYS9kYjd4RXF0aFgrWEEzcFh1QnVoMGtQTHlHdHZhMmx0?= =?utf-8?Q?rqPOJBL7Rk4WzV+YVyaEn7iTA?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7875.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZzVQU1dZTWUvSXJYU3VjMzRacTBseTIyRlI0TFBlM1NXVXRsRVpDb081Y2Qz?= =?utf-8?B?d2JVVkdpSjJWYU5HalYyOHhBc01SYjkyKzRQaEJTYWgvYjlEckF6a2tQaW1n?= =?utf-8?B?a0RBTE9aWkxWRHQxNTNNYTVJU09TeCtHWVBaeThuRGQzcEdYNG1UekNESGpt?= =?utf-8?B?VlhXdWZSNFV4VW5QOTAxYkVmaG42YnZHTHZIbFhvQmlQUExGTzFvaTEyMGly?= =?utf-8?B?eHZtU2cvOE9vNEl5SWE3VWE0Y3U5bW11RktkRzZLR0xVZnpkOGF6ekdKRVk5?= =?utf-8?B?MWx3VkE1ZTRwNXhFd1FjZnRiVjB6YlV0cWNFTUo0K2s3WjFZZmk4bUpoME84?= =?utf-8?B?T0hYbVNJMU5tK0grb1pzaGtVWWpXOVFTY2xlTUZlRTcxK0FkSVFRazFlOHNp?= =?utf-8?B?YkdMck5DZkp1dGtJaU0ya3hQOWFodDVsSm5xVmpkdUdmaWpveE54ZHN1Nldl?= =?utf-8?B?M2YrUnhpTUdJS1daODdnK2xQM2xXZk80N3k1TGQwTzlac1hlSVpZbGIxZ2Yz?= =?utf-8?B?ODhUQU9oanl6WGdEOTdKYjRQUjdtb25wQmZuT0poSHpIbzdpMVB3NzhpYnhw?= =?utf-8?B?T1Y1RkpXMDArVnFqSzB0TlZXajhISzdyQlJLTU4zaks2Ym5MOU51M25VL2Vp?= =?utf-8?B?MlNENjVSUVB4VDdRZWlRakY3Tk5oQlBhOWUvNklIWVI1K0cxV1p3Wmw0MFJZ?= =?utf-8?B?UUd1QlR1ZTV2cm83b1U3QVdFNllZbVpONkVwYzRUUlBjdlUzNldNQll0MWd4?= =?utf-8?B?Q2NzeHFmUXpTYnYrMEdJWFB5MUdCNkdEVkNYbzh1UDc1NjFMV0VsandTZmda?= =?utf-8?B?WTlpRjdQaERwb0d6bjdmYkVVWFhnUkQ0eWhEOHU4WDU2d0tNS21UNS9uUEZi?= =?utf-8?B?T1Zma2Fza1dxUGQ1Y1FrQWFySXE1M0tOdDJRcS9NM1pxM0ZEZTlMNEFSWUln?= =?utf-8?B?YlB6OHdwRk1Qeis4WGVGcHpsbDFHTlZ0V25rMUpJWDVWVjM5WWV6VXdzRWU4?= =?utf-8?B?alZybXZ5UDg3NU1Ca3ZPdzZDbnlOMW9LTHVYdGhUVmtCcnVJa1JmeW0vVHJj?= =?utf-8?B?bnYxa2JrYjBnZDM5QmErS3lzMWM5blZjRlh5NGNadi9TVElnUEFKNkxwOWhC?= =?utf-8?B?dzhySG5GTk5jQmpLUVdXbVNXWWRmWjI2UmtzdERtcVpDcTd3UWF6OHc1cDY2?= =?utf-8?B?NHo5amsyejFHL0VYa1NmclgrMnVIQTdzM2xabXFTNmU5Mnk2QVVad3lCd0p5?= =?utf-8?B?NEl3SU1Rc2hoRFhYNGRNd2E5ZE9WTHBpbHJjaTVTN1dwb1hFSTVNd0RneTV0?= =?utf-8?B?bUk5OTM2eVdTbytpS3YwSW9MMjBteHZQQStpbTRWSjFnUXdhN2piZmpVcEhw?= =?utf-8?B?TFYvL2NHeWI4YmJzb1FqSUVIeEt6VGI0NGxobmplenV2b3NJOHpLdGNSQ3hC?= =?utf-8?B?aWxndnJGZkxTUFhKS1lkeHd5bi9VdEU1QnV4Zjd2U0pWTkwwL0ZBUmVQcWti?= =?utf-8?B?OEZyVFFNUVk2RjdUZFNpVU8waUN4enJVdzhIWXlUNGJPS2hnbitWWXBjeC9q?= =?utf-8?B?eGo1RlA3OTR0bzBUNmNnS1JiZzRaUitOeFZrRzVjN282bFhzcVhCN2VvbmlH?= =?utf-8?B?SHBrK1EzWlJvemUyRW9aVEhyL0xMQ25sRWhzUXdlTnMyUmFzYTBndlBwWTl4?= =?utf-8?B?SU9Wb1hNQW1OcGMwVmdBckJFRldBZWVzZ0xDTjZlUW80YW02REFZdUFBYTRL?= =?utf-8?B?MFJRM0FWYVUyVmpCSHQ2SmRuY2JaZERTMWJUa3VVeE1tTnQrckN4N1hla2VK?= =?utf-8?B?NktoUHE3bnRDNk1rb0h2UGZEM1JTaDJIL0hRY04vSlJJRyt6ODgzTFJVMWdz?= =?utf-8?B?SktxQTFzV0dSRyt2WkFlYVp3eXpId2RLZWZWVHhldEo3U0oyWHZvTHVPTG45?= =?utf-8?B?ei9hWmpwWk9ENFhlWVlTc2liU001K1o1TEtwS0V3SW9xSG5GT2o0ZzhQMHQz?= =?utf-8?B?NnVBS21jU0hGZmZRbGtTSzVxcU9YRDJMQThtbHhYMDZyM3JnWlFXOC9KcUIv?= =?utf-8?B?WEQyTDByaDF0dDlFU2VVM3RMSzRvam0vVi9FYjh2Z3plUERDZk83a1dFazlK?= =?utf-8?B?MFNYaGNYSHNyaUtkOWJMTkxzNjFPa0NZeE9ZcEJBNVF1a0xCTUZ4NEV6Rmlm?= =?utf-8?B?R1NvYm1ZSGd0NDVqbUl2OVN3YWt1OTNickQzY21lUUE2T25Yb3Vmb3dXQmU5?= =?utf-8?B?NTIzcEc2dUFxODVFYWdqa2gybGxraFVjR0RCenY0YUo1WEplUWlnSWY4T1lS?= =?utf-8?B?RTA2d3pxZTMzcyt6dE5yZ0NLL3hsbldZQlJ5ZjBpVGR5cnhvLy9kQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6abb09ed-c068-4726-391c-08de5a613dae X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7875.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2026 09:24:42.8952 (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: eZUD5vQZnu6fgko6MreMlTEA5ERBRCXCa0+C3eUbzoKyKEikiiiWkuVUsxGchiOAv6WhddUHEu6kTgpGXyCjTQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB7127 On Thu, Jan 22, 2026 at 08:24:11PM +0100, Jürgen Groß wrote: > On 22.01.26 18:36, Roger Pau Monné wrote: > > On Thu, Jan 22, 2026 at 05:21:12PM +0000, Andrew Cooper wrote: > > > On 22/01/2026 3:56 pm, Jürgen Groß wrote: > > > > Just as a heads up: a hardware partner of SUSE has seen hard lockups > > > > of the Linux kernel during boot on a new machine. This machine has > > > > 8 NUMA nodes and 960 CPUs. The hang occurs in roughly 1.5% of the boot > > > > attempts in MTRR initialization of the APs. > > > > > > > > I have sent a small patch series to LKML which seems to fix the problem: > > > > https://lore.kernel.org/lkml/20260121141106.755458-1-jgross@suse.com/ > > > > > > > > As Xen MTRR handling is taken from the Linux kernel, I guess the same > > > > problem could happen in Xen, too. > > > > > > > > As the hang always occurred while waiting for the lock, which is > > > > serializing the single CPUs doing MTRR initialization, my solution was > > > > to eliminate the lock, allowing all APs to init MTRRs in parallel. > > > > > > > > Maybe we want to do the same in Xen. > > > > > > I suspect Xen might be insulated by the fact that we don't have parallel > > > AP start (yet), so we don't have the whole system competing on the > > > spinlock at once. > > > > Oh, I think I've misunderstood the issue. Linux is doing MTRR init in > > the AP startup path, and so if it takes too long Linux will report > > that the AP has failed to start. > > No, Linux is deferring the MTRRs until all APs are up, just like Xen > (or Xen does it like Linux). > > > > > This is not an issue on Xen because MTRR initialization is deferred > > until all APs are up, and hence is not part of the timed AP start > > path. This optimization was done in: > > > > 0d22c8d92c6c x86: CPU synchronization while doing MTRR register update > > > > So even if we did parallel AP startup we won't likely be affected, > > because we would still defer the MTRR setup until all APs are up. > > We will be affected, as its the deferred MTRR setup which is the > problem. If it's the watchdog NMI then than won't be possible on Xen, as the watchdog is setup after the MTRR synchronization step. We should however fix it even if it's not a fatal issue on Xen. I assume the avoidance of locking will make a very noticeable performance difference in boot times. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Jan 23 09:39:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 09:39:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212095.1523403 (Exim 4.92) (envelope-from ) id 1vjDdv-0003mK-5Y; Fri, 23 Jan 2026 09:39:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212095.1523403; Fri, 23 Jan 2026 09:39:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjDdv-0003mD-2j; Fri, 23 Jan 2026 09:39:51 +0000 Received: by outflank-mailman (input) for mailman id 1212095; Fri, 23 Jan 2026 09: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 1vjDdt-0003m7-U8 for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 09:39:49 +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 750ce90a-f83f-11f0-b15e-2bf370ae4941; Fri, 23 Jan 2026 10:39:48 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-47ee4539adfso21379815e9.3 for ; Fri, 23 Jan 2026 01:39:48 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804f5ad4c1sm13564285e9.12.2026.01.23.01.39.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Jan 2026 01:39:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 750ce90a-f83f-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769161187; x=1769765987; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=14qnw9e2RNgm4SDgwK2PAZovv873Z+Z1se6MygmX4Vg=; b=MB67WgE53ypxS3tttU1ubFWRSy7EzSkr+tRyWz8NL4GisvbU9jP/M8+EXVoiSPC/ZR bxERpcoAoEhIvvT/CxMD8FX1AgOxSj8OTY7l4FI8/ZD5gdXvQ7/3EIkeL0FZAl8ZnoWy zp4VUFqzZ4TrZ7SdF/pqqrFVi3yvhXGPuwv91gAJ6qHIv2QpBZ1/l1dYfGyJNKTJscUI rR8LFmphQiI3EMlR2DH4NlJv7ZTr5/1e9Lbyp/BfPM/qnYZ30kfD3N0bDzZ0zGvRFvdc iiz6B/WZso6HIf0HnXatPL5srrqeKlvTG7F6jXe236wMCe0H3zmNNQOxBshFi2cOFEGa QGsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769161187; x=1769765987; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=14qnw9e2RNgm4SDgwK2PAZovv873Z+Z1se6MygmX4Vg=; b=MA0hvin2r0ZghPbjnWKx+x7kKFW7q1ijBPiBaNJAdeiQMp6hVIciyuJ1VlF8p92Ukv oq38pJ7tLahrhPY5m/zPF3y7D8rSRqk1d2NFXriOyb2oAglKNjnXebM060v+e2eyQWdF xOS9mlUFETTzkDWT6y0YHHvzFZ0/Pk/9TLQ/O/oQJSZNw8nIEEZsZCDCBpOjzDSZnafg U6Ws0nlJImx2ZaddZ6iw9RRtDPHvz8znzLnxp/TkXiGewUdee5OTMEbaZKtytQNJXflk rug4vPQs5SiVgrR/7l1W0KZVlrTcwyb+hgFdtwgRlmPr9+fR+PnJLFrBJg5d6RbrD1rR CRzg== X-Forwarded-Encrypted: i=1; AJvYcCUcyu8Cj1CGYrAYrw0DKBIdgcgdas7lGuRG/V1X836DUl5fpFyAqiym+sRRgGyhKZqix1E9P6ptKc8=@lists.xenproject.org X-Gm-Message-State: AOJu0YwdT0K+7sAgLovjFCyuC/zWgOXubCIw29LHYsrFyYQn04XGD18+ jIQ7uD4FDoiht1JIEh3zyWj8Y9LhAwrIHAmVx7c/2qvIrVT0rpkx8myjA2O/9NPgeg== X-Gm-Gg: AZuq6aI9iClt6OhFlSuM+BTjrEoRorP8OUEuPJ7AgBVyaGhCOwv4qi9AX7F9fvHpwpz PBrz48IaYYuVCI/QuJLWjHk2VDD3g6upEbD0DLzMlLnm47N3vcxS4QG0Ot0l+MX0IF2CW3/SGEt 0t6JJ7hlbbJrKbS5BGNmlTMAirDGf2w8Zixgt0euVU1ZqFFRxXh/3eFwR84gnaiW6tCBrrknBNC /+BSt2cyhGxbKBu6EMw5W0VHyqKBzrPyILdIispRu7WKs8600NHHDwi0e9oBMSjgczSZ2yi4zmu pqSWpOOcXFgDoRmWAE2bfyDxqGkxn4m6+BfWvt75fKyucH81PtbcEiNQn6qW4/D/S6j6sGHeUzZ 1wNtaa5S/XCkDBsddfLDbxr1NFZzRp6zbvoL7aVrkUrRoRduM9+Rc/+1amY3ru5WOIs3T10R77+ dtF06d5z8wAGdzQ5R0enxJP8oQ24mQUbUNA74AnecL7qcpQLPp1CyMn+aEr7rdydDMCyxc5rtwJ OM= X-Received: by 2002:a05:600c:608a:b0:477:6d96:b3e5 with SMTP id 5b1f17b1804b1-4804c947d6amr42700665e9.7.1769161186853; Fri, 23 Jan 2026 01:39:46 -0800 (PST) Message-ID: <5aafd748-96fb-444a-b297-96b5cca86b2d@suse.com> Date: Fri, 23 Jan 2026 10:39:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/riscv: dump GPRS and CSRs on unexpected traps To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <843ba134-099c-49a1-8561-5e364b630bc8@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23.01.2026 10:09, Oleksii Kurochko wrote: > On 1/19/26 9:34 AM, Jan Beulich wrote: >> On 16.01.2026 17:16, Oleksii Kurochko wrote: >>> Provide more context on the exception state when an unexpected >>> exception occurs by dumping various Supervisor, Virtual Supervisor >>> and Hypervisor CSRs, and GPRs pertaining to the trap. >>> >>> Signed-off-by: Oleksii Kurochko >>> --- >>> Changes in v2 >>> - Address coments about print_csr() macros and dump_csrs(). >>> - Add dumping of GPRs pertaining to the trap. >>> --- >>> xen/arch/riscv/traps.c | 82 ++++++++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 82 insertions(+) >>> >>> diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c >>> index e9c967786312..4e0df698552f 100644 >>> --- a/xen/arch/riscv/traps.c >>> +++ b/xen/arch/riscv/traps.c >>> @@ -17,6 +17,13 @@ >>> #include >>> #include >>> >>> +#define print_csr(csr) \ >>> + printk("\t" #csr ": %016lx\n", csr_read(csr)); >> This prints the CSR_ prefix of the internally used constants. Is this useful >> (rather than extra clutter)? > > No, the prefix isn't really useful. It was printed so only because all CSRs registers > defintions start on CSR_*. > >> Unlike for the GPRs this also prints the register >> names in upper case. That may be fine, or may not be. > > I will follow then like it is written in RISC-V spec for consistency. > > >> The values printed also >> won't align, which may make reading more difficult. > > Do you expect the similar alignment like for GPRs? "similar" is ambiguous here. I'd expect whatever alignment helps readability. >>> +#define print_gprs(regs, reg1, reg2) \ >>> + printk("\t%-7s: %016lx %-7s: %016lx\n", \ >>> + #reg1, (regs)->reg1, #reg2, (regs)->reg2) >> Yes, two per line is certainly helpful. Why not also for some of the CSRs. > > It is less clear how it would be better to group them. I thought about > CSR_STVEC: .... CSR_VSTVEC: .... > CSR_STTATUS: ... CSR_VSSTATUS: .... > > So group them in S-mode mode register and VS-mode register. That's an option. Don't know how this would end looking like all together. >>> @@ -99,12 +106,87 @@ static const char *decode_cause(unsigned long cause) >>> return decode_trap_cause(cause); >>> } >>> >>> +static void dump_general_regs(const struct cpu_user_regs *regs) >>> +{ >>> + printk("\nDumping GPRs...\n"); >> Register names alone will be meaningful enough? Be mindful of serial line >> bandwidth as well as screen resolution. > > Agree, we could drop this print. (Then probably the same could be for Supervisor CSRs > and Virtual Supervisor CSRs, etc as it is clear based on the name which one CSR it > is) Of course I also meant to cover the other, similar ones, yes. >>> + print_gprs(regs, ra, sp); >>> + print_gprs(regs, gp, tp); >>> + print_gprs(regs, t0, t1); >>> + print_gprs(regs, t2, s0); >>> + print_gprs(regs, s1, a0); >>> + print_gprs(regs, a1, a2); >>> + print_gprs(regs, a3, a4); >>> + print_gprs(regs, a5, a6); >>> + print_gprs(regs, a7, s2); >>> + print_gprs(regs, s3, s4); >>> + print_gprs(regs, s5, s6); >>> + print_gprs(regs, s7, s8); >>> + print_gprs(regs, s9, s10); >>> + print_gprs(regs, s11, t3); >>> + print_gprs(regs, t4, t5); >>> + print_gprs(regs, t6, sepc); >>> + print_gprs(regs, sstatus, hstatus); >> The last three aren't GPRs. Why would they be logged here? (All three also >> being logged in dump_csrs() would further require some disambiguation in >> the output, for people to not need to go look at the source code every >> time.) > > Agree, that it would be better to print it with the CSRs. It was print here > only as they are in the same structure with GPRs. > >>> +} >>> + >>> +static void dump_csrs(unsigned long cause) >>> +{ >>> + unsigned long hstatus; >>> + >>> + printk("\nDumping CSRs...\n"); >>> + >>> + printk("Supervisor CSRs\n"); >>> + print_csr(CSR_STVEC); >>> + print_csr(CSR_SATP); >>> + print_csr(CSR_SEPC); >>> + >>> + hstatus = csr_read(CSR_HSTATUS); >>> + >>> + printk("\tCSR_STVAL: %016lx%s\n", csr_read(CSR_STVAL), >>> + (hstatus & HSTATUS_GVA) ? ", (guest virtual address)" : ""); >>> + >>> + printk("\tCSR_SCAUSE: %016lx\n", cause); >>> + printk("\t\tDescription: %s\n", decode_cause(cause)); >>> + print_csr(CSR_SSTATUS); >>> + >>> + printk("\nVirtual Supervisor CSRs\n"); >>> + print_csr(CSR_VSTVEC); >>> + print_csr(CSR_VSATP); >>> + print_csr(CSR_VSEPC); >>> + print_csr(CSR_VSTVAL); >>> + cause = csr_read(CSR_VSCAUSE); >>> + printk("\tCSR_VSCAUSE: %016lx\n", cause); >>> + printk("\t\tDescription: %s\n", decode_cause(cause)); >>> + print_csr(CSR_VSSTATUS); >> As before, imo justification is wanted (in the description) for logging >> VS* values. > > It is hard to describe in general why they could be needed. The best I can > come up is: > Dump VS* CSRs to provide full guest exception context. When handling traps originating > from VS-mode, host CSRs alone do not describe the fault; VSCAUSE, VSEPC, VSTVAL, and > related state are required to diagnose guest crashes and hypervisor misconfiguration, > and to correlate host-side handling with guest-visible exceptions. > > Does it good enough justification? I think diagnosing guest crashes doesn't belong here. An unexpected trap is entirely different from a guest crash. Hypervisor misconfig I might buy, just that I don't (yet?) see the connection to the three particular registers you name in the suggested text. (As mentioned before, this may simply be because of my lack of a proper global picture of RISC-V.) Jan From xen-devel-bounces@lists.xenproject.org Fri Jan 23 10:36:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 10:36:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212120.1523413 (Exim 4.92) (envelope-from ) id 1vjEW3-0002gi-VV; Fri, 23 Jan 2026 10:35:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212120.1523413; Fri, 23 Jan 2026 10:35: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 1vjEW3-0002gb-Sw; Fri, 23 Jan 2026 10:35:47 +0000 Received: by outflank-mailman (input) for mailman id 1212120; Fri, 23 Jan 2026 10:35: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 1vjEW2-0002gV-9d for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 10:35:46 +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 44f42402-f847-11f0-b15e-2bf370ae4941; Fri, 23 Jan 2026 11:35:43 +0100 (CET) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-42fb2314eb0so1885000f8f.2 for ; Fri, 23 Jan 2026 02:35:43 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1f7ba0bsm6038824f8f.40.2026.01.23.02.35.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Jan 2026 02:35:42 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 44f42402-f847-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769164543; x=1769769343; 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=EKGT8Sb7X5XPLi87sEYq7V9AgDbQOIwjqK5jWWwuc2M=; b=RPDBwqHNkorPu67c7HtzE0p5j9NXR4Nr7DZpOvQ8+836V+J+gJHFzqjEKkCRSRVebV 0rDOpAzuYMkTRHBYKYHVPCBHUIBX12OgtosdrCpLtwbjKpp84k3K7gB6qFRVvD7i8qnF HFmy+ty+dzm+DGv2woNM+BQkeeXewP5aTNzt/CfcpzU1k0uU1Y+At+UpIC5k68p6UgFV S3ehsQM5nmXNR7S4NYLnzaTxdJVdiIWLLnGBGu0ic2/zchJIrjV2RoWAQWPrsd/03rH/ LgXlnZX5GWeorN7H2mTP1YCDA8EkCM0VdDVlRP19SfBiUOmLZH1s/2QrRsc4UKJEPPQX NqEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769164543; x=1769769343; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EKGT8Sb7X5XPLi87sEYq7V9AgDbQOIwjqK5jWWwuc2M=; b=KODBMq5u6JfXGojg063+z6ovEFbiF6jidohMn3HrNzoaaYA/asP9FtGbV/WJyEDxE3 7SoA1JtR+bRcWXUkYWXiukPfO/UTZkMczWwAp1mvp3VkcF+m6wguBWqxOep7fVJwzt27 UmAX4/HQUsoZhHyOXJ70O4oS8VtgQkg9X9HBwBefSNVMGqmaEE1giH1EBH1ZK9IIrr6w n9Vhe71vxstNd7IcTucVxubo7S0RcAXkoXyfDsmKgMSWg+n9kMwEEfgqXyUjw4/iEs/k 9OlOKO0/4dPAEsOxO1XqXfgdvH7WmRBMnoXgvrsRZjDJ4ivRP6dMaUSBBblS5htIhB7T Bfrg== X-Forwarded-Encrypted: i=1; AJvYcCV+9Nw1oddw2z2J+P40Mdqj+ADr0cm9ZnmnYBEurhdtW/0kD6eIuGC+hgUaVFgGY1nPLnAdVKFe5cg=@lists.xenproject.org X-Gm-Message-State: AOJu0YwOQcvFBG9gtfQ9DK+kLKWgShVmEaMkHA9TG4e5mbKXPja8DgwJ +FIegz9/AG5OzkXdm9AGmd0TfCPuSAvBzmO8LiJqQ7rwLtYmG3f/f0Lc X-Gm-Gg: AZuq6aIdqtEp4UgQvTLScpODudRDxeoRyonHas4j95gk+OknU+u4ZF1Qu/URZVmkeIk 6651Y5K48Au9bYB/5JYDbZkPkh7/Bu9Mp3qqGXYnRqjYx2QPZMC7Q+6SzIw3BA6KsdHBA6Vq8AY 5zN5xwd+prA5STa7pibjuF/kCL/6Y5DKNdYALTLGd8dZn/j9D3xd7Wj5OrMfuFnYSrifhyX9Jc4 CRR3gFvVLb6fJOQl+a9DSzZgztpai+Vc+UXl42WwHgl84sr6k+1ExEYWONCCDx+bu+ezKgZvCSs 05NbEDEpk3PWijOtn0+iRVMlMh8oG6SBlMka8UxpD7gXNXCBq8/Usyjn4+FTa8YYvTT5BaHAMSF SjvghGfOxyADjISbHicFKtryFYTcmsgOEU4g79haMSsDcdsi0ZgD2cntPUL9ELsjimS/wzCnD1T LSUP5Pip6FXfTUfsmampk8k1OJWmGFB9dm0hG8+VrQ90ZlXuzawLnzNEqjWTbY4w8= X-Received: by 2002:a05:6000:2303:b0:433:1d30:44c with SMTP id ffacd0b85a97d-435b1604a69mr4338334f8f.43.1769164542354; Fri, 23 Jan 2026 02:35:42 -0800 (PST) Message-ID: Date: Fri, 23 Jan 2026 11:35:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/riscv: dump GPRS and CSRs on unexpected traps To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <843ba134-099c-49a1-8561-5e364b630bc8@suse.com> <5aafd748-96fb-444a-b297-96b5cca86b2d@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <5aafd748-96fb-444a-b297-96b5cca86b2d@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/23/26 10:39 AM, Jan Beulich wrote: >>>> +} >>>> + >>>> +static void dump_csrs(unsigned long cause) >>>> +{ >>>> + unsigned long hstatus; >>>> + >>>> + printk("\nDumping CSRs...\n"); >>>> + >>>> + printk("Supervisor CSRs\n"); >>>> + print_csr(CSR_STVEC); >>>> + print_csr(CSR_SATP); >>>> + print_csr(CSR_SEPC); >>>> + >>>> + hstatus = csr_read(CSR_HSTATUS); >>>> + >>>> + printk("\tCSR_STVAL: %016lx%s\n", csr_read(CSR_STVAL), >>>> + (hstatus & HSTATUS_GVA) ? ", (guest virtual address)" : ""); >>>> + >>>> + printk("\tCSR_SCAUSE: %016lx\n", cause); >>>> + printk("\t\tDescription: %s\n", decode_cause(cause)); >>>> + print_csr(CSR_SSTATUS); >>>> + >>>> + printk("\nVirtual Supervisor CSRs\n"); >>>> + print_csr(CSR_VSTVEC); >>>> + print_csr(CSR_VSATP); >>>> + print_csr(CSR_VSEPC); >>>> + print_csr(CSR_VSTVAL); >>>> + cause = csr_read(CSR_VSCAUSE); >>>> + printk("\tCSR_VSCAUSE: %016lx\n", cause); >>>> + printk("\t\tDescription: %s\n", decode_cause(cause)); >>>> + print_csr(CSR_VSSTATUS); >>> As before, imo justification is wanted (in the description) for logging >>> VS* values. >> It is hard to describe in general why they could be needed. The best I can >> come up is: >> Dump VS* CSRs to provide full guest exception context. When handling traps originating >> from VS-mode, host CSRs alone do not describe the fault; VSCAUSE, VSEPC, VSTVAL, and >> related state are required to diagnose guest crashes and hypervisor misconfiguration, >> and to correlate host-side handling with guest-visible exceptions. >> >> Does it good enough justification? > I think diagnosing guest crashes doesn't belong here. An unexpected trap is > entirely different from a guest crash. Hypervisor misconfig I might buy, just > that I don't (yet?) see the connection to the three particular registers you > name in the suggested text. (As mentioned before, this may simply be because > of my lack of a proper global picture of RISC-V.) One of the options which could be stored in VSTVAL is a faulty instruction, so without checking VSEPC we could understand what is the instruction and check what is in HS-mode register to understand if enough permissions were given to VS-mode to use this instruction without trap to HS-mode. Considering that even if a source of trap is faulty instruction it doesn't guarantee that VSTVAL will contain this faulty instruction, so we should go to check VSEPC and then use objdump to understand what was faulty instruction. VSCAUSE could be useful for the case if for some reason guest doesn't dump VSCAUSE to its console, at least, we could get some extra information what was wrong during execution of faulty instruction. Also, there are a cases when from hypervisor some trap redirection to a guest happens and VSCAUSE is used for this purpose, VSTATUS and VSTVEC are used too, so it would be nice to check them too if such redirection leads to another trap because of incorrectly set VSCAUSE, VSTATUS and VSTVEC. I don't really see any reason to print VSATP, at least, at the moment. So I can drop it. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Jan 23 10:37:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 10:37:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212129.1523425 (Exim 4.92) (envelope-from ) id 1vjEXn-0003BH-CP; Fri, 23 Jan 2026 10:37:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212129.1523425; Fri, 23 Jan 2026 10:37: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 1vjEXn-0003BA-7l; Fri, 23 Jan 2026 10:37:35 +0000 Received: by outflank-mailman (input) for mailman id 1212129; Fri, 23 Jan 2026 10:37: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 1vjEXm-0003B4-To for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 10:37:34 +0000 Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [2a00:1450:4864:20::429]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8159f973-f847-11f0-9ccf-f158ae23cfc8; Fri, 23 Jan 2026 11:37:24 +0100 (CET) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-435a517be33so1270871f8f.0 for ; Fri, 23 Jan 2026 02:37:24 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1e7164dsm5712409f8f.23.2026.01.23.02.37.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Jan 2026 02:37:23 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8159f973-f847-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769164644; x=1769769444; 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=xxDB0Ao+8SsVgIyA2jfmZIaZYgtRGz93592jqfkqzck=; b=JnAcA+qn76Sr7MVwE1AIHuj8nNfy1BsL8HU4LxRSGtZt8wfYn1YAHb40MfTCt+Mjhn 8tDfXwcdIoeaqfLomRmeAFys616WW8jVmZBF2QrZXwGC+DdAye5AX3tAMwwSRR2QP39/ SEyleZWzUyzyu0kZunZc3GmuzI1EHt7SFm7DkRHvjxnIwPnbpj7wMWQtlMEt1MP/zZcC mvcJrORvSKjJ+Wkq9Bz7E0hAsmN/Fk/oDwVD9EvtgqO675jSGhZUGhYut7j+oOBkeI6t FYZgR/OssflceU4uNweI1SLQ01hNNDhrLpl6zOORgDCSAmCYH8fphuURYEAfdCwo6WEs e/4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769164644; x=1769769444; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xxDB0Ao+8SsVgIyA2jfmZIaZYgtRGz93592jqfkqzck=; b=dHbtjAcPIltrrpXLfejPMZzRybijq8f5lYsmJFYFGWp+1R6WNOP/18ZgmYJYQLhGg9 eZ1HXcX18AaWuk+gFUZ7eXZfHbEqJ9u3JT6U6wB5CRsI6lSxtwYXJ7mUUKwYHwaBz7Vl hYivckce+mz8cjCdMV4mkCON2uPf8GgJ/1XKz4n35HOIPmU1F5nGqWGXmykqCYx9mJ2/ 83KZPVGq6rUKy7pxcFmXGwKBQGMKlL1HH10raaJYAqfOzqm3ooIan3x3i5PEwxOEzIPe Kqy8siVOWsXIlKkGHPp5H24HVH26rZx7LQCP2i5C+wj8VSDLehn0n5AZeL8U9ubN60f2 UKwQ== X-Forwarded-Encrypted: i=1; AJvYcCVdoy5rXKYf2v7jDBuxUNqV+2I87Emckmm8eBJT4MmOYuOElwZ6XFWFBox0XiAXOt1lOeBlqcuhY1g=@lists.xenproject.org X-Gm-Message-State: AOJu0YyKXfrbIkhjk5cGaLWtMOXspnF3TyRMGm3DfIEgqnw/xfwKTrWK yz4VbVHYaqbpNb3xquTPJbybVu4bxr/C0q17qQ/z3GEPn5awqKcri4v/ X-Gm-Gg: AZuq6aLIyXeLHmgsQ8PgDX+GmXtE8+BMy3KKGBUTXe24sIcGiEUvwMCGxeuhdJoMHo/ ehX8pPeJVI99ugC+nqCemnZQ222pJkRdixfdtO0f9IK705BQBC7vFQxFyFXICaqJjUyD8/m2vLN pX/okK+QR5GGL8aGw6QaPPmls/dgFz9IWmZenkCbFFk8OQRO4NTi5PLm5rrzciFzn9UpN2apJ6z BERX8vwAM1CQi1EbKRuHcwGK5XKpQfVN/oA548IwWTjeNCN3/vtQP4ksaKblrtIMUOwmMQ4DNtE 7sJKGmRsB4y0o2/kv1jAODxNzekdN4nHL0Jfp4AUWiIH1fno5xYX+fs0QclWNEQsgfvy7Nb52jH ceHyGlKEJ6m8FyqA0Cuz9zfAMfECUQyeCLVpQrg/vVf1Ttl68iJBsMGcS9SFObLT1NSYY4OMyIn 64ImSR79/G7XGtmLr6nUB9AqiuOhXBXYfnxaFlpfIAhVpdNsqMvSnWz+weCNDy+7A= X-Received: by 2002:a05:6000:4313:b0:432:8504:b8a9 with SMTP id ffacd0b85a97d-435b1627fe9mr4813089f8f.62.1769164643931; Fri, 23 Jan 2026 02:37:23 -0800 (PST) Message-ID: Date: Fri, 23 Jan 2026 11:37:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] xen/riscv: dump GPRS and CSRs on unexpected traps To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <843ba134-099c-49a1-8561-5e364b630bc8@suse.com> <5aafd748-96fb-444a-b297-96b5cca86b2d@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <5aafd748-96fb-444a-b297-96b5cca86b2d@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/23/26 10:39 AM, Jan Beulich wrote: >>>> +} >>>> + >>>> +static void dump_csrs(unsigned long cause) >>>> +{ >>>> + unsigned long hstatus; >>>> + >>>> + printk("\nDumping CSRs...\n"); >>>> + >>>> + printk("Supervisor CSRs\n"); >>>> + print_csr(CSR_STVEC); >>>> + print_csr(CSR_SATP); >>>> + print_csr(CSR_SEPC); >>>> + >>>> + hstatus = csr_read(CSR_HSTATUS); >>>> + >>>> + printk("\tCSR_STVAL: %016lx%s\n", csr_read(CSR_STVAL), >>>> + (hstatus & HSTATUS_GVA) ? ", (guest virtual address)" : ""); >>>> + >>>> + printk("\tCSR_SCAUSE: %016lx\n", cause); >>>> + printk("\t\tDescription: %s\n", decode_cause(cause)); >>>> + print_csr(CSR_SSTATUS); >>>> + >>>> + printk("\nVirtual Supervisor CSRs\n"); >>>> + print_csr(CSR_VSTVEC); >>>> + print_csr(CSR_VSATP); >>>> + print_csr(CSR_VSEPC); >>>> + print_csr(CSR_VSTVAL); >>>> + cause = csr_read(CSR_VSCAUSE); >>>> + printk("\tCSR_VSCAUSE: %016lx\n", cause); >>>> + printk("\t\tDescription: %s\n", decode_cause(cause)); >>>> + print_csr(CSR_VSSTATUS); >>> As before, imo justification is wanted (in the description) for logging >>> VS* values. >> It is hard to describe in general why they could be needed. The best I can >> come up is: >> Dump VS* CSRs to provide full guest exception context. When handling traps originating >> from VS-mode, host CSRs alone do not describe the fault; VSCAUSE, VSEPC, VSTVAL, and >> related state are required to diagnose guest crashes and hypervisor misconfiguration, >> and to correlate host-side handling with guest-visible exceptions. >> >> Does it good enough justification? > I think diagnosing guest crashes doesn't belong here. An unexpected trap is > entirely different from a guest crash. Hypervisor misconfig I might buy, just > that I don't (yet?) see the connection to the three particular registers you > name in the suggested text. (As mentioned before, this may simply be because > of my lack of a proper global picture of RISC-V.) One of the options which could be stored in VSTVAL is a faulty instruction, so without checking VSEPC we could understand what is the instruction and check what is in HS-mode register to understand if enough permissions were given to VS-mode to use this instruction without trap to HS-mode. Considering that even if a source of trap is faulty instruction it doesn't guarantee that VSTVAL will contain this faulty instruction, so we should go to check VSEPC and then use objdump to understand what was faulty instruction. VSCAUSE could be useful for the case if for some reason guest doesn't dump VSCAUSE to its console, at least, we could get some extra information what was wrong during execution of faulty instruction. Also, there are a cases when from hypervisor some trap redirection to a guest happens and VSCAUSE is used for this purpose, VSTATUS and VSTVEC are used too, so it would be nice to check them too if such redirection leads to another trap because of incorrectly set VSCAUSE, VSTATUS and VSTVEC. I don't really see any reason to print VSATP, at least, at the moment. So I can drop it. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Fri Jan 23 10:57:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 10:57:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212143.1523435 (Exim 4.92) (envelope-from ) id 1vjEqW-0005tZ-Rw; Fri, 23 Jan 2026 10:56:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212143.1523435; Fri, 23 Jan 2026 10:56:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjEqW-0005tS-OE; Fri, 23 Jan 2026 10:56:56 +0000 Received: by outflank-mailman (input) for mailman id 1212143; Fri, 23 Jan 2026 10: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 1vjEqV-0005tM-3g for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 10:56:55 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 37aeb4bc-f84a-11f0-9ccf-f158ae23cfc8; Fri, 23 Jan 2026 11:56:49 +0100 (CET) Received: from BY3PR05CA0001.namprd05.prod.outlook.com (2603:10b6:a03:254::6) by PH0PR12MB8175.namprd12.prod.outlook.com (2603:10b6:510:291::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Fri, 23 Jan 2026 10:56:42 +0000 Received: from SJ1PEPF00002310.namprd03.prod.outlook.com (2603:10b6:a03:254:cafe::70) by BY3PR05CA0001.outlook.office365.com (2603:10b6:a03:254::6) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Fri, 23 Jan 2026 10:56:41 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by SJ1PEPF00002310.mail.protection.outlook.com (10.167.242.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Fri, 23 Jan 2026 10:56:41 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Fri, 23 Jan 2026 04:56:41 -0600 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; Fri, 23 Jan 2026 02:56:39 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 37aeb4bc-f84a-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iGNJalkrDVd9tEu9Z69eXIRSnGFBpsXmsq6vkTgd13Y97NfdDAHueItkwNevUNvN6opokBYBOmTBIqOieOMjlBotDQf/kyjL/NKFHaHTVj3bR9k0IGS0aSv7T3HgfE43Sw1W6RK5K8NZjhaVDTDkBbl27nPrBDYHOQploN7cBp/4VE4HSbud21TUIdeXqaCLrQsnU4CqwdfNVi8zwSxT98pte2V117c0t15HXSt6d4kM3HbXXt+x7V8ugX5WWeIjfu+rGl0dfwH052bDEov/n1jOz7uvyUSIB1w9Ci5XDtmIT7yjdjRmlu0t0MSSwS9rP2xqKA/lnXViHNekkwRemA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ETuBIzztLz+MRAMApCAKXauvUf3SmvHpsG4X1wDA1Jc=; b=Y7+MSsbR1LX3ElwhKEab8QL5FsrChyvCNbRHuOWNap51uYZzP6a2Py+4DDpmfWPfrNUhyLkNtpOIP6WUCk4jiIRSIVfr51lHjHj4BiCsl87+HbbOjajrLSDOaCuIDk6Vt4rV945BQHUALfU1bsnJ2sZluRc8s6CJUm34y36mZEbQuCSpdkm7id5jaKgnV+Lo+e4IQHCy9m2XL1btE0ucSll8Flx6BUgmJFXcVuWttllAO3Jt+Apcy7odNWiGw9AhN3dHJwdmZmDsGRGCSnPThlSMNEZ1dmGmLq1pcoxozYox+uMvsSYotsDH2vycTqx3/5rJrBRaPO9KrrP+uFxIpA== 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=ETuBIzztLz+MRAMApCAKXauvUf3SmvHpsG4X1wDA1Jc=; b=3Nnht5yYdTCy5PU+RqFrSYRwFuvMQLIGxAthUDcOc+aqoLWQS8ch0cN2Lg4gjCxUusyFpTEu51hdvVpIb6TOHNh1SPPVEK8j68fGQzJKt6HBe1MQuGyuFTVw++XhQFye5DVSMnoIq9hUsoSmjf609sy+sbm8MTOdrtMTVlLss9o= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <7024dd52-b209-4daa-94a4-8b966aed4499@amd.com> Date: Fri, 23 Jan 2026 11:56:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/2] xen: Allow lib-y targets to also be .init.o To: Jan Beulich , Alejandro Vallejo CC: Andrew Cooper , Anthony PERARD , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , References: <20260121154757.44350-1-alejandro.garciavallejo@amd.com> <20260121154757.44350-2-alejandro.garciavallejo@amd.com> <526ef477-0730-4e22-a82f-4c598ad78e0a@suse.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: SJ1PEPF00002310:EE_|PH0PR12MB8175:EE_ X-MS-Office365-Filtering-Correlation-Id: c5da4cec-7a1c-458f-bce5-08de5a6e1782 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?TU13WHFQMkEzSk9WdE9kcVdWYWtOWlAwRnNHSmNRSS9NY0hNQldDaXlFZHpC?= =?utf-8?B?N3F0aGpwcE9DakNpZDF4K2kzaTU0UDlxd0dkd0EwNVN5dWlsZmZtdElhM2NK?= =?utf-8?B?eTdTU0ZaeTVvZkRGQlp0VzlMSzY0NHc1djF4UWk3bzJnNnlrN3c4TW5HTFFW?= =?utf-8?B?Q2tSZVBheE92NFNLd3RSdUk0ajNFN1BNZVZFNWlBMWpGTDVRMmpTNW1XUWpy?= =?utf-8?B?a0QyTWYyZlR1TFMwazUrbjFRTkprblA3ay9DZHMxZVY3NFpIbHlsdnoxQ1BJ?= =?utf-8?B?NnlDSnAxZ1hoMDNSNkpCTkk1dnFPUGhQL0wwdzl6akVpazFuRUx5TUJHV29O?= =?utf-8?B?MHgxWVNraGppdTNNYlMyMU1LV3hDTWxlc3Z1d3o5R1VKVVU0TXdKM2JNZllC?= =?utf-8?B?RUdmb0JqLytVVzNlMCtHSldaNDNmQjBPaW1wVExYS3FWVktReUE0TUppUWdv?= =?utf-8?B?cksyMG9wc1pVaS9iUDY5QWVIZ3BBa1o5NmJBQzlCdkV5WVVQT1dmNEh1L2Vy?= =?utf-8?B?R1B4SW56aDBkbFFIdzdNZkRFVW1nN1I1SGRKM3hPdk92MGdUM2NsNW94eVp4?= =?utf-8?B?K1NLM04yZE93d1J6aGdrU1RGT0EvU2FnY1RsaFpWM09uYTBydXhvYzRqZmsr?= =?utf-8?B?VzVwOHVaMnZna0xydUd0Y2lQVEVWaGZXZjZaRDdFNFM4ZXpjRlZhRHpaNzkr?= =?utf-8?B?THFFa0pIWnZvT2k3azdUYStQRkw4ZWFEakVoejFnZXY4MGVOUEorTHNDaXBp?= =?utf-8?B?c2tIRmVBZFZ2emkwbDV6TFFHdXJrNVk2Qkg0WHp6blNTSHNMYlU3V0hpVm9w?= =?utf-8?B?YmwxNXdlL1p1anRtWVM2RW5QTFNFVGVNYUlIVTVoZk9iS0hKWTZsRzRXZTZP?= =?utf-8?B?RTVSai9NbXF1bXI5eWxueUh6U2ZPRW04ODN2NUFleHh2ZEZPZmhaY2V6L1FQ?= =?utf-8?B?VmZFV2JkRG8yK3Ftdnh3c25FRW1RK1ZnOHczbldIekZEYks2eEgrTUJEZmZn?= =?utf-8?B?ZUtUcVFRU2NMT0JUNUR2U21ZMjBqWnpBeE1yYVpZUWpKbGpmQ05WR0JhUmxO?= =?utf-8?B?U0U3RnVEdndXRG1RbnhvcE11OHFwejRTUHpRUmgwd3RsaWgxZFg3SVIzZFk0?= =?utf-8?B?T1BseS82ck1IN2c2RVhybzlPRTZBc2k1NzZUYkRibFhCdklkY2d1aEJiTTlu?= =?utf-8?B?d2EzcWY2ZUUxd09kOUNLQ0ZuQ0JSelhVL25MYjNMVVFzYkVkWm9tbkdYSnRy?= =?utf-8?B?UkhMQ3VobHU3L3NJa3pRaTcwbHlLd09uWW5yYURSZFJIMzVjU1R3YmErdHRk?= =?utf-8?B?TVlXUnJXNUl4M3dWQzdBRW00Nm9UdTNYaFh1VjMyTVMyYkFLcUtpMGJpY3pr?= =?utf-8?B?RiszVU1hYmN0SWZtWVpjdE9nOWlza2ttQ29MTnYraVBXREh2cXVra3hNVnJN?= =?utf-8?B?cmxpOGI2ckVRNjRlOGVHODNBS2hrZHQ3MHJ5RnduVUdDSmJRajZwSzErajZv?= =?utf-8?B?NDAyejVnbWNZMFhHU1Y5bEczNGVxY0Z1OEE4SHlGZ3FxYUIrQm13Snk4UmFO?= =?utf-8?B?R0JVejdzVlpWbitTL1R3TVJ5MDBlZVEzZE42Tm83MngwZG1XaUFrWWdlb3Y1?= =?utf-8?B?RkRiQXpveEdWY0FEUHRPQktnNHp4eW8yeDErMzQ5d1ZKbkU0N2R0TVpTUkFP?= =?utf-8?B?MitRZHZLSHYzUlJEOENSVDJsOVQrMFNIMjNjZXpPUW1aQnZhUHZNSGRXOUEv?= =?utf-8?B?elViOXRicE80ZU5SODNBaXF3S2gyRVBWZXpXdUxQeE83S21hUCtyemY4ajRQ?= =?utf-8?B?dkl0amR6ZWFyVmR1Zjd6M1laK0srT3VyK2tvNlo3ODgwWnRUS0lERHp3TFNE?= =?utf-8?B?SGJxSytHNExHK01NKzVyN0pqRGI4dHMydTl6aVNPalZkTmlqSjFCTzJDQmJD?= =?utf-8?B?d1U1dFRxTDBJeHVmWTl4TjBERkViVjFKekZCYTZGVDhQNW1obTFVbmNJb1Vy?= =?utf-8?B?d2FDS21KZ1ArdGR3UkdvKzAzNzIyMHhDNU42Vk1taStwZDNSMExUNnJDUy82?= =?utf-8?B?NDlMNE1VdFh0bURUQ0tQYmNLLzB0QnB0bmYrUjlPRUlQZUpEcXIyYUhyWGdR?= =?utf-8?B?eFBOakVyZjFUait2ZEFFVWk5U2pySi9QdFJsd3FtV05GZ1JaUEZvemdFckMv?= =?utf-8?B?anB4dGk2anNadWJDaGJHZ2ZFa05ibUw3amYxZlVoUFZaSDcxdzdHQjRzMG5I?= =?utf-8?B?RmFmTkxFdXlyN1JQNkh3dDZJanB3PT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700013)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2026 10:56:41.9695 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c5da4cec-7a1c-458f-bce5-08de5a6e1782 X-MS-Exchange-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: SJ1PEPF00002310.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB8175 On 22/01/2026 11:01, Jan Beulich wrote: > On 22.01.2026 10:49, Jan Beulich wrote: >> On 21.01.2026 16:47, Alejandro Vallejo wrote: >>> There's some assumptions as to which targets may be init-only. But >>> there's little reason to preclude libraries from being init-only. >>> >>> Signed-off-by: Alejandro Vallejo >>> Reviewed-by: Jan Beulich >> >> I can't tell (yet) what it is, but as per CI something's clearly wrong with this >> change. Both xilinx-smoke-dom0less-arm64-* and qemu-smoke-dom0*-debug* fail with >> it in place. qemu-smoke-dom0-arm64-gcc (no "debug") was fine, suggesting it may >> be an early assertion triggering. > > Or an early UBSAN failure. I think ... I did a test and it looks like the problem is division by zero in generic_muldiv64. At this point, time is not yet initialized on Arm, so cpu_khz is 0 in ticks_to_ns. (XEN) [000000005019d0ee] UBSAN: Undefined behaviour in lib/muldiv64.c:23:21 (XEN) [00000000501cfc11] division by zero (XEN) [0000000050211d11] Xen WARN at common/ubsan/ubsan.c:176 (XEN) [000000005023b3ec] ----[ Xen-4.22-unstable arm64 debug=y ubsan=y Not tainted ]---- (XEN) [0000000050afc964] Xen call trace: (XEN) [0000000050b0e4ec] [<00000a000032ab44>] ubsan.c#ubsan_epilogue+0x14/0xec (PC) (XEN) [0000000050b2f1c1] [<00000a000032b35c>] __ubsan_handle_divrem_overflow+0x114/0x1e4 (LR) (XEN) [0000000050b577dd] [<00000a000032b35c>] __ubsan_handle_divrem_overflow+0x114/0x1e4 (XEN) [0000000050b790fb] [<00000a00003eb9d0>] generic_muldiv64+0x7c/0xbc (XEN) [0000000050b94539] [<00000a00003bfb9c>] ticks_to_ns+0x24/0x2c (XEN) [0000000050bad89d] [<00000a00003bfc04>] get_s_time+0x34/0x54 (XEN) [0000000050bc731b] [<00000a000032dec8>] console.c#printk_start_of_line+0x2bc/0x374 (XEN) [0000000050be7987] [<00000a000032ef3c>] console.c#vprintk_common+0x454/0x484 (XEN) [0000000050c06033] [<00000a000032ef94>] vprintk+0x28/0x30 (XEN) [0000000050c1e4df] [<00000a000032eff8>] printk+0x5c/0x64 (XEN) [0000000050c3904b] [<00000a00005548f8>] end_boot_allocator+0x31c/0x548 (XEN) [0000000050c55a86] [<00000a0000585c58>] start_xen+0x150/0xe68 (XEN) [0000000050c70232] [<00000a00002001a4>] head.o#primary_switched+0x4/0x24 (XEN) [0000000050c8d2bf] ~Michal > >>> --- a/xen/Rules.mk >>> +++ b/xen/Rules.mk >>> @@ -130,9 +130,9 @@ endif >>> >>> targets += $(targets-for-builtin) >>> >>> -$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS-y += -DINIT_SECTIONS_ONLY >>> +$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)): CFLAGS-y += -DINIT_SECTIONS_ONLY >>> >>> -non-init-objects = $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(extra-y)) >>> +non-init-objects = $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)) > > ... this is the problem: You're _adding_ library files here which weren't there > before. Why $(lib-y) isn't here I don't really known, but as per the CI results > there must be a reason for this. > > Jan From xen-devel-bounces@lists.xenproject.org Fri Jan 23 11:30:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 11:30:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212167.1523453 (Exim 4.92) (envelope-from ) id 1vjFNM-0002gs-Io; Fri, 23 Jan 2026 11:30:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212167.1523453; Fri, 23 Jan 2026 11: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 1vjFNM-0002gl-G8; Fri, 23 Jan 2026 11:30:52 +0000 Received: by outflank-mailman (input) for mailman id 1212167; Fri, 23 Jan 2026 11:30: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 1vjFNL-0002gF-Cw for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 11:30:51 +0000 Received: from mail186-9.suw21.mandrillapp.com (mail186-9.suw21.mandrillapp.com [198.2.186.9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f6e44bbf-f84e-11f0-9ccf-f158ae23cfc8; Fri, 23 Jan 2026 12:30:48 +0100 (CET) Received: from pmta10.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail186-9.suw21.mandrillapp.com (Mailchimp) with ESMTP id 4dyG2b3xrqzK5vgs0 for ; Fri, 23 Jan 2026 11:30:47 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id b308e68c6caf4ee09e101bfa99c0b2fb; Fri, 23 Jan 2026 11:30: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: f6e44bbf-f84e-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1769167847; x=1769437847; bh=EtaiHdgsUpgJN+DDre9rKBu2dtw8GLJBaLQ9+Wfn8bo=; 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=UdFZ+BsAzAZwus3QWmJ4SFsnpukN8XYSw9m++rx1/ffPT3p0bU+/3UIstQ0+v+Ugw 0HevpFsonVgcBQNAVoCVB2a6LRX7JZArLOfCTrlTO7LwoToxnyz7BPim8bCFLSpKFZ SYYlmSQgH00bjf8hsSuirJkkv3tbT+J5F4EhdgJq+wxy9k+Glj7wIIPIBDtRCVQUbG J7YiC6h0mgzXdnIMsnaEYcoY+lpC3+9q2AzoyZVFw6cf85oV6BmBTs5TCESEzydUTa PWBhfS4gCnSQnVPJmRj77agO47ogk2WNjEerO8YaqQupGYdwwmrP1fK8zILvVutrD3 HMqHau16aG3nA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1769167847; x=1769428347; i=teddy.astie@vates.tech; bh=EtaiHdgsUpgJN+DDre9rKBu2dtw8GLJBaLQ9+Wfn8bo=; 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=zqHmPxns7041za8nBsoPLW+TggaRVSD9cTD0QgP5Odw7gF5X4EFXYDVZnz2aIO1ij kdQ090h91O0hHCecGikWJeqozUa/HWxAsr5m9rQF3FyQLsyYlEeF8IpfoX75nKCvDR 4b+vJ9/TH6EsOnlSMmgsyIeemIN23nuWty8fJHhBwLVXZoCTm2bySQa1w6Tse5cufI Yp9AG5yLQAnfE9Fqs2IX6793ivkRe1C/PqNkTSaX9Oz7tEUeiwLTFNmohdu3tDOO/F ikBnnn3Mk1hGB4m0KGvYfQVhX8FKhcBvrd2Mh9VoY0X/zVlGTis2IwXR21KLr+bote 2qaSi2WEEAIZA== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=20v2=2002/16]=20xen/riscv:=20implement=20arch=5Fvcpu=5F{create,destroy}()?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1769167845821 Message-Id: <4e2bf819-81f6-40f8-9bc3-c53aabf0967c@vates.tech> To: "Oleksii Kurochko" , xen-devel@lists.xenproject.org Cc: "Alistair Francis" , "Connor Davis" , "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Jan Beulich" , "Julien Grall" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" , "Romain Caritey" References: <08b582179ebc4241140000972d89209c84c90fa4.1769099885.git.oleksii.kurochko@gmail.com> In-Reply-To: <08b582179ebc4241140000972d89209c84c90fa4.1769099885.git.oleksii.kurochko@gmail.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.b308e68c6caf4ee09e101bfa99c0b2fb?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260123:md Date: Fri, 23 Jan 2026 11:30:47 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, Le 22/01/2026 =C3=A0 17:49, Oleksii Kurochko a =C3=A9crit=C2=A0: > Introduce architecture-specific functions to create and destroy VCPUs. > Note that arch_vcpu_create() currently returns -EOPNOTSUPP, as the virtua= l > timer and interrupt controller are not yet implemented. > > As part of this change, add continue_new_vcpu(), which will be used after > the first context_switch() of a new vCPU. Since this functionality is not > yet implemented, continue_new_vcpu() is currently provided as a stub. > > Update the STACK_SIZE definition and introduce STACK_ORDER (to align with > other architectures) for allocating the vCPU stack. > > Introduce struct cpu_info to store per-vCPU state that lives at the top > of the vCPU's stack. > > Signed-off-by: Oleksii Kurochko > --- > Changes in v2: > - Drop BUILD_BUG_ON() in arch_vcpu_create() as a check isn't very usefu= l. > - Use vzalloc() instead of alloc_xenheap_page() to use the larger domhe= ap to > allocate vCPU's stack. > - Drop printk() inside arch_vcpu_create() to not have potential big noi= se > in console as it could be that an amount of vCPUs is pretty big. > - Use XVFREE() instead of free_xenheap_pages() as vCPU's stack allocati= on > happens with a usage of vzalloc() now. > - Drop stack field as it is enough to have only cpu_info as stack point= er > could be calculated based on cpu_info. > - Drop cast when v.arch.cpu_info is inialized as it is not necessary > to have it. > - Drop memset() for arch.cpu_info() as it is enough to have vzalloc(). > --- > xen/arch/riscv/Makefile | 1 + > xen/arch/riscv/domain.c | 59 ++++++++++++++++++++++++++++ > xen/arch/riscv/include/asm/config.h | 3 +- > xen/arch/riscv/include/asm/current.h | 6 +++ > xen/arch/riscv/include/asm/domain.h | 2 + > xen/arch/riscv/stubs.c | 10 ----- > 6 files changed, 70 insertions(+), 11 deletions(-) > create mode 100644 xen/arch/riscv/domain.c > > diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile > index 87c1148b0010..8863d4b15605 100644 > --- a/xen/arch/riscv/Makefile > +++ b/xen/arch/riscv/Makefile > @@ -1,5 +1,6 @@ > obj-y +=3D aplic.o > obj-y +=3D cpufeature.o > +obj-y +=3D domain.o > obj-$(CONFIG_EARLY_PRINTK) +=3D early_printk.o > obj-y +=3D entry.o > obj-y +=3D imsic.o > diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c > new file mode 100644 > index 000000000000..9c546267881b > --- /dev/null > +++ b/xen/arch/riscv/domain.c > @@ -0,0 +1,59 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > + > +#include > +#include > +#include > +#include > + > +static void continue_new_vcpu(struct vcpu *prev) > +{ > + BUG_ON("unimplemented\n"); > +} > + > +static void __init __maybe_unused build_assertions(void) > +{ > + /* > + * Enforce the requirement documented in struct cpu_info that > + * guest_cpu_user_regs must be the first field. > + */ > + BUILD_BUG_ON(offsetof(struct cpu_info, guest_cpu_user_regs) !=3D 0); > +} > + > +int arch_vcpu_create(struct vcpu *v) > +{ > + int rc =3D 0; > + void *stack =3D vzalloc(STACK_SIZE); > + Are there alignment constraints for the stack ? > + if ( !stack ) > + return -ENOMEM; > + > + v->arch.cpu_info =3D stack + STACK_SIZE - sizeof(struct cpu_info); > + memset(v->arch.cpu_info, 0, sizeof(*v->arch.cpu_info)); > + Given that vzalloc ensures that the memory is cleared, you don't need to clear it another time. > + v->arch.xen_saved_context.sp =3D (register_t)v->arch.cpu_info; > + v->arch.xen_saved_context.ra =3D (register_t)continue_new_vcpu; > + You probably also want to set the first parameter of continue_new_vcpu (struct vcpu *prev), or otherwise I don't think we want the "prev" parameter in continue_new_vcpu if it's always going to be 0. IIRC continue_new_vcpu is only meant to bootstrap the new vCPU, not just perform a context switch to it. > + /* Idle VCPUs don't need the rest of this setup */ > + if ( is_idle_vcpu(v) ) > + return rc; > + > + /* > + * As the vtimer and interrupt controller (IC) are not yet implement= ed, > + * return an error. > + * > + * TODO: Drop this once the vtimer and IC are implemented. > + */ > + rc =3D -EOPNOTSUPP; > + goto fail; > + > + return rc; > + > + fail: > + arch_vcpu_destroy(v); > + return rc; > +} > + > +void arch_vcpu_destroy(struct vcpu *v) > +{ > + vfree((char *)v->arch.cpu_info + sizeof(struct cpu_info)); > +} That doesn't look correct, you want to vfree what was allocated as the bottom of stack, i.e v->arch.cpu_info + sizeof(struct cpu_info) - STACK_SIZE Or alternatively introduce bottom of stack as a additional vcpu_arch field. > diff --git a/xen/arch/riscv/include/asm/config.h b/xen/arch/riscv/include= /asm/config.h > index 1e08d3bf78be..86a95df018b5 100644 > --- a/xen/arch/riscv/include/asm/config.h > +++ b/xen/arch/riscv/include/asm/config.h > @@ -143,7 +143,8 @@ > > #define SMP_CACHE_BYTES (1 << 6) > > -#define STACK_SIZE PAGE_SIZE > +#define STACK_ORDER 3 > +#define STACK_SIZE (PAGE_SIZE << STACK_ORDER) > > #define IDENT_AREA_SIZE 64 > > diff --git a/xen/arch/riscv/include/asm/current.h b/xen/arch/riscv/includ= e/asm/current.h > index 0c3ea70c2ec8..58c9f1506b7c 100644 > --- a/xen/arch/riscv/include/asm/current.h > +++ b/xen/arch/riscv/include/asm/current.h > @@ -21,6 +21,12 @@ struct pcpu_info { > /* tp points to one of these */ > extern struct pcpu_info pcpu_info[NR_CPUS]; > > +/* Per-VCPU state that lives at the top of the stack */ > +struct cpu_info { > + /* This should be the first member. */ > + struct cpu_user_regs guest_cpu_user_regs; > +}; > + > #define set_processor_id(id) do { \ > tp->processor_id =3D (id); \ > } while (0) > diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include= /asm/domain.h > index 0d9b4c4b525e..ec7786c76199 100644 > --- a/xen/arch/riscv/include/asm/domain.h > +++ b/xen/arch/riscv/include/asm/domain.h > @@ -49,6 +49,8 @@ struct arch_vcpu > register_t ra; > } xen_saved_context; > > + struct cpu_info *cpu_info; > + > /* CSRs */ > register_t hedeleg; > register_t hideleg; > diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c > index 29bdb65afbdf..9e30a9a3b50b 100644 > --- a/xen/arch/riscv/stubs.c > +++ b/xen/arch/riscv/stubs.c > @@ -121,16 +121,6 @@ void dump_pageframe_info(struct domain *d) > BUG_ON("unimplemented"); > } > > -int arch_vcpu_create(struct vcpu *v) > -{ > - BUG_ON("unimplemented"); > -} > - > -void arch_vcpu_destroy(struct vcpu *v) > -{ > - BUG_ON("unimplemented"); > -} > - > void vcpu_switch_to_aarch64_mode(struct vcpu *v) > { > BUG_ON("unimplemented"); -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Fri Jan 23 11:30:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 11:30:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212166.1523444 (Exim 4.92) (envelope-from ) id 1vjFNH-0002SM-8t; Fri, 23 Jan 2026 11:30:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212166.1523444; Fri, 23 Jan 2026 11:30:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjFNH-0002SE-6I; Fri, 23 Jan 2026 11:30:47 +0000 Received: by outflank-mailman (input) for mailman id 1212166; Fri, 23 Jan 2026 11:30:46 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjFNG-0002S8-5e for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 11:30:46 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f3d77fae-f84e-11f0-b15e-2bf370ae4941; Fri, 23 Jan 2026 12:30:44 +0100 (CET) Received: from SA0PR11CA0069.namprd11.prod.outlook.com (2603:10b6:806:d2::14) by IA0PR12MB7579.namprd12.prod.outlook.com (2603:10b6:208:43c::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.12; Fri, 23 Jan 2026 11:30:37 +0000 Received: from SA2PEPF0000150B.namprd04.prod.outlook.com (2603:10b6:806:d2:cafe::a4) by SA0PR11CA0069.outlook.office365.com (2603:10b6:806:d2::14) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.10 via Frontend Transport; Fri, 23 Jan 2026 11:30:34 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SA2PEPF0000150B.mail.protection.outlook.com (10.167.242.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Fri, 23 Jan 2026 11:30:36 +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, 23 Jan 2026 05:30:35 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f3d77fae-f84e-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=a475LqwRHy64zRa0FR3ObDc5DT5sy5925/E+YJE/e8rUSj2NzF3GL671dku7ZQhnaJWUpDYwXMYe84fEt8CV4q1T0zUkRNhJdUXM8r5Y0j0pYI5tAco3r6PeXLYUmCkHhALQ0oosEoobl3ui58GtdY+zsEcoyNC3kMVSsxkgBTFjfbm/BK2bjlNmjATXaSfAAFPcATDMiHnWrhKnxl0VFrL1++HqJmpuETjAh6J4TKezX29G/GLtm47edF3pwzJKNSErSjLBBb7YjwM0rG4q2InJmzd0OzUZhM9JPysu3MBIMrNQ+k1kY7c1UmXfF2oj5JzJhKS4/cIWNfIpCVhvvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=All5rhqj5Rzs0kQTv90z7MbhvCo4QWprTk/QfjbAQbk=; b=xXT+nlkUxlt0Fw7JD0RxkrJhTPbqu38PVTVfBAhra6UPXCYqmMfxiYZH4gBQ8TElk4S+4xSi6blWoO1//wtR8NkKHEoTE3qcikRAgXAOvLAtwiW2zwJjPiRImwOVvvFgiEATXMPl3wscr8UF3yCPCP//DZb2sbbLDPKG6yMd4JuwZhMn5sIsOhDRi+kreDqshDmAai1OKG2IMFT82a0622mZc2kxOlqOVOt6WHaNNL/wCpz47wTSIDqQOPFigFtEI3gCD8EmXfv2Nl04IQE/jKBxWFlLNKr7+RAdk1SAY2k61uhic1aJXvbI+GzOJbvzW4EiwcrRGiRAjvES8Yld6Q== 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=All5rhqj5Rzs0kQTv90z7MbhvCo4QWprTk/QfjbAQbk=; b=VXfFO4KbWza5338jO1CidhmJKDXCq6ppt2bMrzOYIecGEcxOdoyM45X8r4fgfJpjTnEfreKGmYNxYJpFBq5dppaquL/X8LOh7U+kDNCzMTw7FT8mtRNRQh8RfbEp4K5u1YP4hk+kro/kQSSPOIPGYo76V9uAF2X0RI4Rl7FNeTo= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 23 Jan 2026 12:30:33 +0100 Message-ID: To: Teddy Astie , CC: Oleksii Kurochko , Community Manager , Jan Beulich , Andrew Cooper , =?utf-8?q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH 1/4] x86: Reject CPU policies with vendors other than the host's From: Alejandro Vallejo X-Mailer: aerc 0.20.1 References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <20260122164943.20691-2-alejandro.garciavallejo@amd.com> <5a96fb6d-ce8b-409e-9050-3499ac90eb65@vates.tech> In-Reply-To: <5a96fb6d-ce8b-409e-9050-3499ac90eb65@vates.tech> 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: SA2PEPF0000150B:EE_|IA0PR12MB7579:EE_ X-MS-Office365-Filtering-Correlation-Id: 5b64dd29-e36d-4575-b8a5-08de5a72d452 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|376014|1800799024|82310400026|13003099007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?YnFPbEZPQWdZL2FaSVVSelZCeGxremVGaS9aakRPd0pzR2VOZDlFQWVRTnhI?= =?utf-8?B?YnJwM1pUdHZwN3FYQzJtMTZJalZLcXZJaVYwa003czJiYWJIRzVyeFBzUHZ3?= =?utf-8?B?VXluV3Z3R24wcGJ4aGYxczdTYjhJZU4zRWhoNDlveDh1aHhEWDVHNmZrY3hK?= =?utf-8?B?NlBKUzVhSFhHTVYrS1pEWlJmdGx4Y3FJYWp1NnM3WTJiY2trZ1poajlWZGU1?= =?utf-8?B?L1NGQS83d2ZuU0p5WCtCMlZyZnlocFJVME9UNE0yUTdrSnFLaXJQM1JHeml4?= =?utf-8?B?SVVsdkVYb2V3c1JCS3kzWkU4WjFVeFFpYUVZMU1GV0dSRWFSYUtXWWVwWGFW?= =?utf-8?B?azB5NTZ0NmlORDhaUlF0cDU4UERYSm4xa1g3Y0dZTlh5TVcyRnZPMTV5US9u?= =?utf-8?B?VGhVSnphNEVJbHJjQ25JckxKandENW9IMkRTZkU0SktIb25YSzRJeFJOUldN?= =?utf-8?B?T3lNc0JiVzJRN3hHY3lTdklZMTlNcCtHNXpsazJwQ2hJSzhHcEVrUlhtb1Y1?= =?utf-8?B?WWlGTU4vWVFEb0VUaGc1SjVlUHpmSy8vYk0zcUJVVmZhNmZLa2VDTW9JMzlH?= =?utf-8?B?Z1o4RFo4cjRhaEJiS3dmYVo3NnZPdTRsK2NxNzhscHRLOXNxNTg1RjFqVTU4?= =?utf-8?B?bVRHZHlEc2pHazEvVWZmc2cxZTZpR0NaRkpLVGhYQ1ZmQjg0N25KcWc5cWpv?= =?utf-8?B?YU1MeFY0SzJQYk5uSitZMmFtaUNrRVRHbjN4SlBUS3Y5eU1YYk1qWXZZRDV4?= =?utf-8?B?Sk0xYmJkbXIxQ2JGaHMwVHZRRnlJTGp3U1pCZlRpcnJkaVB2OWx5RC9aVXg3?= =?utf-8?B?SUp2akJkNXpvSEY0LzFGRUFQa0dLcE0rN0s4blZpUHgyYVZzOEp2clIyUGdU?= =?utf-8?B?U1cxZDRheEFFejlWR3JEamNNOWR0a2NmdFFjNmFUQlB0ZFdVcXpXV1Boa2xa?= =?utf-8?B?Mk5xWkJlRkFaSktLL3VyQU5CMHlKRk9QclpBQjlQYVlnaWVpN2dBVXhzUVlB?= =?utf-8?B?RWwxa2orUTNlc2Z4TnBtMCtlUUtIUWNlNjZqdHR4ak1mRVRaVU1xV3lXS1Jl?= =?utf-8?B?VmFob3FsaTlCbDJzY0RoMU56cFhNWlU3RS9KRkd5YmhhaGFac255SmIyakFC?= =?utf-8?B?VmZCZWdxYmhsanR0czI4emk2b2dxd0J1em80aDlTb21hQldYYTZQbzRnOCtN?= =?utf-8?B?TmFqMGdjNS9VYkZNUUFkRCs1L3JtWkdML1BjclgvUE1nbWlWb2phL0FjMDI5?= =?utf-8?B?YTVSYUxoZXM4MHRLa2xtZ0o2TVgrTmhOUlJERnZtakQrVVRiWWxvYnZ6c3hI?= =?utf-8?B?WnFNS25FTklBQ3llUEZsZVRVcHNwY2MvOU8wamkzWW53dGFwb0dIaGhFNTFM?= =?utf-8?B?TkowQjZuZUg3a1F5S3hDdDVOcWs3V3FxQ0JocytFNVh0bFVzRk5yUUs5b2Y3?= =?utf-8?B?alpyOS84V0NzQ1JuMzg5dlR3dUN6cUhIeFAyTnRZblpNRVJCU0NlZ1g4VThT?= =?utf-8?B?TWFhMjVxSnlyVnZZRmdGWThJZUNMSHlvckpIQXJQT3VIeVVaUFZ1dXNJQW1U?= =?utf-8?B?NzZRRU1TYmNURm9vcVVDTVpic2gvS2duZVJtSGZ5c3BHR21PTmZ0QmZuaTNz?= =?utf-8?B?Q3NzVzhJemUxbG0zR3NITkFGVFp6aHI2TTFCV2VXVXZFSHBCRlk5cE9rMGpL?= =?utf-8?B?TUIxeVMxK0xpNzFCQjdGVW5EQkxNenJLaE5aeEgrVTNUUmtISnNGRHJiazR5?= =?utf-8?B?ZUU3MDBGMmVvbXlNbnpCblhtSE1mdUt3MTdxVUlnNG9nbCtyZ3c0OXFYZk1q?= =?utf-8?B?RlNwSTdMOXcrYnFrR3gzN3lwQnp1czdvelhDM2twaUUzSndXcC9Pem1JSVFC?= =?utf-8?B?VGI0dU5odEhvVzYvVEQ4dFFuUVJ0djdiaUY2dEkwYnphVXFZcjcxSG5HdlhC?= =?utf-8?B?aUxQQlB2enZFbFpQMWpBekxpVVRHSnJOZXBDNllzMWZUZUhNTzF0NHVJSWZR?= =?utf-8?B?T1VmRFlYNFJ4ZVVQekd2TmNrU3pjRHY4Mm44N0FjYkQvZ3B0cWdJdkY1RUly?= =?utf-8?B?QVJVQXVrTnA3aFZNSWJ6TjdhdExUUTkzNUZCTDBEZ1ROZGRyZ3MrM1gvWFBH?= =?utf-8?B?aHFEMXdDVmYyM1VaYWFqb1RvQU9BMCtpeHowZWVGZll5RG1SZnh1MVBHNUxO?= =?utf-8?B?Tmc9PQ==?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2026 11:30:36.7523 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5b64dd29-e36d-4575-b8a5-08de5a72d452 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SA2PEPF0000150B.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB7579 On Thu Jan 22, 2026 at 6:13 PM CET, Teddy Astie wrote: > Le 22/01/2026 =C3=A0 17:51, Alejandro Vallejo a =C3=A9crit=C2=A0: >> While in principle it's possible to have a vendor virtualising another, >> this is fairly tricky in practice and comes with the world's supply of >> security issues. >>=20 >> Reject any CPU policy with vendors not matching the host's. >> > Signed-off-by: Alejandro Vallejo >> --- >> CHANGELOG.md | 4 ++++ >> xen/lib/x86/policy.c | 3 ++- >> 2 files changed, 6 insertions(+), 1 deletion(-) >>=20 >> diff --git a/CHANGELOG.md b/CHANGELOG.md >> index 18f3d10f20..eae2f961c7 100644 >> --- a/CHANGELOG.md >> +++ b/CHANGELOG.md >> @@ -22,6 +22,10 @@ The format is based on [Keep a Changelog](https://kee= pachangelog.com/en/1.0.0/) >> - Xenoprofile support. Oprofile themselves removed support for Xen= in 2014 >> prior to the version 1.0 release, and there has been no developme= nt since >> before then in Xen. >> + - Cross-vendor support. Refuse to start domains whose CPU vendor di= ffers> + from the host so that security mitigations stay consistent.=20 > Cross-vendor ??? >> + setups have been unreliable and not practical since 2017 with the = advent of >> + speculation security. >> =20 > > I don't really like the wording, it sounds like guest will suddenly stop= =20 > to work for some reason. AFAIK, in the Xen Project only suspend/resume=20 > logic is going to be affected, and we probably want to reflect on that=20 > instead. You also won't be able to start a cross vendor VM, which you can do by manually picking the CPUID leaves in xl.cfg. Though you're right that for t= he overwhelming majority of affected users this would manifest as not being ab= le to restore a saved VM (or not being able to live-migrate, which is effectively= the same thing for this purpose). It's unlikely anyone abuses xl the way I described. I'll reword it differently to note the overwhelmingly most affected workflo= w. > >> - Removed xenpm tool on non-x86 platforms as it doesn't actually prov= ide >> anything useful outside of x86. >> diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c >> index f033d22785..4c0c5386ea 100644 >> --- a/xen/lib/x86/policy.c >> +++ b/xen/lib/x86/policy.c >> @@ -15,7 +15,8 @@ int x86_cpu_policies_are_compatible(const struct cpu_p= olicy *host, >> #define FAIL_MSR(m) \ >> do { e.msr =3D (m); goto out; } while ( 0 ) >> =20 >> - if ( guest->basic.max_leaf > host->basic.max_leaf ) >> + if ( (guest->basic.max_leaf > host->basic.max_leaf) || >> + (guest->x86_vendor !=3D host->x86_vendor) ) >> FAIL_CPUID(0, NA); >> =20 >> if ( guest->feat.max_subleaf > host->feat.max_subleaf ) > > > > -- > Teddy Astie | Vates XCP-ng Developer > > XCP-ng & Xen Orchestra - Vates solutions > > web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Fri Jan 23 11:38:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 11:38:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212189.1523463 (Exim 4.92) (envelope-from ) id 1vjFUW-0003kq-9r; Fri, 23 Jan 2026 11:38:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212189.1523463; Fri, 23 Jan 2026 11:38: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 1vjFUW-0003kj-6q; Fri, 23 Jan 2026 11:38:16 +0000 Received: by outflank-mailman (input) for mailman id 1212189; Fri, 23 Jan 2026 11:38:14 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjFUU-0003kG-OW for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 11:38:14 +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 f8db76cd-f84f-11f0-9ccf-f158ae23cfc8; Fri, 23 Jan 2026 12:38:01 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-42fb5810d39so1271436f8f.2 for ; Fri, 23 Jan 2026 03:38:01 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1e71562sm5822194f8f.21.2026.01.23.03.37.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Jan 2026 03:38:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f8db76cd-f84f-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769168280; x=1769773080; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=0lwrbFmSohjzihfQACN8j3xVvbNZg4GY2Lp3vK8Kj2g=; b=cOxEu9Z6LTDQpeX4bhxXzzeisPyc5ZkH454i/Gf1CRh454hVP6r4gd0sYqNB6vu/AS cBL7ClUVFNF13J2gOQ1aoKrfWPzxo36DwGpx9wGPis2iaJ9UV9pvuRb6UeuDujjZGNp/ cGJFTDuF2LG6x9m1gY2Fwe/UVrnfwZO7dFTZTMrnZAPXmY//kDlo5kXD6Z5Elc43j5J0 9S9xAngxJ5LpIcO7tglMQ8qYaX+ehYwzY7y23M3LgB6e8MfhSclaPRtqRmCEiE3BJEwe TOtQYqeGRRctuyWZ//QApNpk2+8cEdJjjW2TSECPj//2PsK1D9j11KNGHiCxXuM3WqvQ P20w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769168280; x=1769773080; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0lwrbFmSohjzihfQACN8j3xVvbNZg4GY2Lp3vK8Kj2g=; b=iLh5Uu1a30xEjPw+PAPILeAP65sszEuGZreg1QC9l6JQFJwFNXbfKcxbgjFtMRqRGy 9VQ7XdW0ei2GM5HMglCWutU7vIaGaR7arov/zCLJHraclRZDXrr83UEnlvyO4MpK2RLu A5wukFuLB/HZww0GNJKjqhJYI/eIeDAWEJvFiR57YvXKhahkuariOfQWgiV4AsQKlWsB cxGzKfeIgKzwNNnMeEZVy1OmV2zj2HMdOTGMZRujOw0M9J9WHFkwJ8rqxWDs9wVA4+AD hYQDf1xf0Q+DH/w9EAcMHQcKM0Jml/rIjRUFpufIR8N4iye2t0mChmuRE8i7qKe5K4Oh fTvQ== X-Forwarded-Encrypted: i=1; AJvYcCVwl736zoW8afaAY+87cJ46yWsAk+hfHfnyvKF5H3l8eWTjdZglxgI5OAlwoae2GASG+IYbuf0G+xI=@lists.xenproject.org X-Gm-Message-State: AOJu0YyyHPQOxWuOqKF5LJPiMApRilqGFtWD5Oc2ZHtmkxYasAdeqcqo AojgeznZAptF7vq5Xfs9is7Myw6xSTKIrMPlxRJwUsdCcQoXEuGa7x2WxkUeHovwVw== X-Gm-Gg: AZuq6aLBxwQvEI37lILxKfaVrinJpxWlbhAv67bhABHfdEedsDX9bPUmWX8SLaonRMH Y+piqQhwXmlBOXmGK94w45zr8GQmu4pclrOlQy6PzmafD2/VFKBi7Ekgy9fFZreVcBdOZ7tgQnT hjaffG/Rxb3SHvJ6UrfAHE6u4pmDkNRmPHgqq9v4G2doKXe2MhAAAvQ/pAsJz0CnDVCe2WqpcKO HPfLwvNAnJo1/AeOR/2REOw/RUkA+dkoxVN1dcYGQ8B/D76mrrm8Fuz+x5jf8XcIy15LfYdSYUA VMXX9ZF9U29NNLBZpZZQRMg7o959xwpmfqc0PI/xHLizC6FdhdQMiWtx5D3t/uKhNu9l8Oft2EM dxKwcHTO6gAtk3xMP/qiLBX2gwyFdgIuVW5Kc5bKhZxTxM2zIgJDiGf/D0cuwuilZuNk4g3GmgG 1tzhA7s7oUfSNU/J2be9mJc+GcNkpJxqrCsmnCIT547vT9WSI+c78jDDForAx/0haQLeT0TOWzl uc= X-Received: by 2002:a05:6000:26ca:b0:431:808:2d58 with SMTP id ffacd0b85a97d-435b161d35amr4589573f8f.51.1769168280479; Fri, 23 Jan 2026 03:38:00 -0800 (PST) Message-ID: Date: Fri, 23 Jan 2026 12:37:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/2] xen: Allow lib-y targets to also be .init.o To: "Orzel, Michal" Cc: Andrew Cooper , Anthony PERARD , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org, Alejandro Vallejo References: <20260121154757.44350-1-alejandro.garciavallejo@amd.com> <20260121154757.44350-2-alejandro.garciavallejo@amd.com> <526ef477-0730-4e22-a82f-4c598ad78e0a@suse.com> <7024dd52-b209-4daa-94a4-8b966aed4499@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: <7024dd52-b209-4daa-94a4-8b966aed4499@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23.01.2026 11:56, Orzel, Michal wrote: > On 22/01/2026 11:01, Jan Beulich wrote: >> On 22.01.2026 10:49, Jan Beulich wrote: >>> On 21.01.2026 16:47, Alejandro Vallejo wrote: >>>> There's some assumptions as to which targets may be init-only. But >>>> there's little reason to preclude libraries from being init-only. >>>> >>>> Signed-off-by: Alejandro Vallejo >>>> Reviewed-by: Jan Beulich >>> >>> I can't tell (yet) what it is, but as per CI something's clearly wrong with this >>> change. Both xilinx-smoke-dom0less-arm64-* and qemu-smoke-dom0*-debug* fail with >>> it in place. qemu-smoke-dom0-arm64-gcc (no "debug") was fine, suggesting it may >>> be an early assertion triggering. >> >> Or an early UBSAN failure. I think ... > I did a test and it looks like the problem is division by zero in > generic_muldiv64. At this point, time is not yet initialized on Arm, so cpu_khz > is 0 in ticks_to_ns. And division by 0 is otherwise benign on Arm64? (On x86 it raises an exception and hence would be a problem also without UBSAN.) Jan > (XEN) [000000005019d0ee] UBSAN: Undefined behaviour in lib/muldiv64.c:23:21 > (XEN) [00000000501cfc11] division by zero > (XEN) [0000000050211d11] Xen WARN at common/ubsan/ubsan.c:176 > (XEN) [000000005023b3ec] ----[ Xen-4.22-unstable arm64 debug=y ubsan=y Not > tainted ]---- > (XEN) [0000000050afc964] Xen call trace: > (XEN) [0000000050b0e4ec] [<00000a000032ab44>] > ubsan.c#ubsan_epilogue+0x14/0xec (PC) > (XEN) [0000000050b2f1c1] [<00000a000032b35c>] > __ubsan_handle_divrem_overflow+0x114/0x1e4 (LR) > (XEN) [0000000050b577dd] [<00000a000032b35c>] > __ubsan_handle_divrem_overflow+0x114/0x1e4 > (XEN) [0000000050b790fb] [<00000a00003eb9d0>] generic_muldiv64+0x7c/0xbc > (XEN) [0000000050b94539] [<00000a00003bfb9c>] ticks_to_ns+0x24/0x2c > (XEN) [0000000050bad89d] [<00000a00003bfc04>] get_s_time+0x34/0x54 > (XEN) [0000000050bc731b] [<00000a000032dec8>] > console.c#printk_start_of_line+0x2bc/0x374 > (XEN) [0000000050be7987] [<00000a000032ef3c>] > console.c#vprintk_common+0x454/0x484 > (XEN) [0000000050c06033] [<00000a000032ef94>] vprintk+0x28/0x30 > (XEN) [0000000050c1e4df] [<00000a000032eff8>] printk+0x5c/0x64 > (XEN) [0000000050c3904b] [<00000a00005548f8>] end_boot_allocator+0x31c/0x548 > (XEN) [0000000050c55a86] [<00000a0000585c58>] start_xen+0x150/0xe68 > (XEN) [0000000050c70232] [<00000a00002001a4>] head.o#primary_switched+0x4/0x24 > (XEN) [0000000050c8d2bf] > > ~Michal From xen-devel-bounces@lists.xenproject.org Fri Jan 23 11:39:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 11:39:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212201.1523475 (Exim 4.92) (envelope-from ) id 1vjFWA-0004H1-LG; Fri, 23 Jan 2026 11:39:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212201.1523475; Fri, 23 Jan 2026 11:39:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjFWA-0004Gu-Gf; Fri, 23 Jan 2026 11:39:58 +0000 Received: by outflank-mailman (input) for mailman id 1212201; Fri, 23 Jan 2026 11:39:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjFWA-0004GE-6T for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 11:39:58 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3d57d908-f850-11f0-b15e-2bf370ae4941; Fri, 23 Jan 2026 12:39:56 +0100 (CET) Received: from BY1P220CA0018.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:5c3::8) by DM6PR12MB4372.namprd12.prod.outlook.com (2603:10b6:5:2af::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.12; Fri, 23 Jan 2026 11:39:52 +0000 Received: from SJ1PEPF00001CE3.namprd05.prod.outlook.com (2603:10b6:a03:5c3:cafe::67) by BY1P220CA0018.outlook.office365.com (2603:10b6:a03:5c3::8) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.12 via Frontend Transport; Fri, 23 Jan 2026 11:40:04 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ1PEPF00001CE3.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.9564.3 via Frontend Transport; Fri, 23 Jan 2026 11:39:52 +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, 23 Jan 2026 05:39:50 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3d57d908-f850-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=sY7uaAt99DzK/Ie4XMp8vmCqaX7xdadvsir5Zzj1++fOEahbMW5jyAtDm8o3X5zfJvr2LH+MVDTygrYMP/+tX5iriZO/CINhbXVEug/uGrJ2b+UsHUqkTXZup07AAKntRRmwvQ+xOD/F2lZjSkcjFpjHYphZkVVHZiB+RjlL0bFkaUzFOacDukiLrIbuzQYtPBWFgZFnmJBAIrhr6P3kvxeWpuI0ELgY42aLYonUDR4u6Loz1ak1tSdlrc2BclVydeM5zJpZRciIA4rmMH75p6CaSo3hMdRA68QhUgiR+k11+Zi7HCOvc4DGJokwFCuq+HhgA0jsjHva14sAqnuG3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=e6jO046wvO/xOzULy9DTNDhxFdPpFVtoUf5/0Ft5rh0=; b=LTsEA3dAujXQENYNGUpqpZYiFa6AvpKp3c6fVh9MkBhLMdHIiKUmEStJH3EWxzodAr92l+GDxTDmV4MFxJtcu2iLxfuP+XEHiNekt307kevvv2vPPyxsN47yNfd/SN/c7Ewc7yzKnQ1rj0ns/IscnFt71pAxGoQNFcrkd2ry9A1YKeNXq4gUATuka9/NAjPu76JPwp0k6Qcu5TZZiziIB2DRKLmRjPPQG8WKc64Xru+ISlbvL/dKhvJo7DalY+8idPl3f9Ke/6JkVinl/WNFM70LexKQGhPFXfOmDnVmNoiyEz2RdnP2DFB92l9V3TlUJwCajOkzU69lqTzBYQobrQ== 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=e6jO046wvO/xOzULy9DTNDhxFdPpFVtoUf5/0Ft5rh0=; b=s1q99dvsEl9FibxuoTePjgOdwmWdBQ/8wuyGDCgkM9tJuyI0zejObfXQK8vbOEvGvqBMjZlNQu8Z+ioBnchU214ghbH+9bA107JrecGHEzBdfVho+L2tEM3L/kwZR+io5Eom3nzCfqGFqneF83ZfM3d0HU+HqWWybePs+4OfWlU= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 23 Jan 2026 12:39:49 +0100 Message-ID: CC: Oleksii Kurochko , Community Manager , Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk Subject: Re: [PATCH 0/4] x86: Drop cross-vendor support From: Alejandro Vallejo To: Andrew Cooper , X-Mailer: aerc 0.20.1 References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <3421e525-fb04-4306-9320-4fa359c2ee28@citrix.com> <6d41d205-7318-45e4-a487-5e35e398d96a@citrix.com> In-Reply-To: <6d41d205-7318-45e4-a487-5e35e398d96a@citrix.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: SJ1PEPF00001CE3:EE_|DM6PR12MB4372:EE_ X-MS-Office365-Filtering-Correlation-Id: e373d8ee-b2f6-4036-bd6b-08de5a741f79 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700013; X-Microsoft-Antispam-Message-Info: =?utf-8?B?NFBUcGk3aWhVVTlvY3ZHQXFhQysvTE8ydE13bnpXL1BXczhVNGVBNjR2ZnpV?= =?utf-8?B?aHZNQW4wQWFJT3VOUzV4Ryt1dFZxL1dOZDdmQUtEaklxZTUyR3hFN3pDQktr?= =?utf-8?B?WUV2TDNIWGRPKzZqZ3ZUbUdqbk1PdDkzNlRKNjUvYjAwRXBTUE84cFJKNTJU?= =?utf-8?B?cWc5V0R5dm9SVXlsdHRQWmdTdGltSzJsNGpFWmllY1ZOTFE3Q3N1UmNYNjRY?= =?utf-8?B?aG1pakk4d2E4YXp1dFI2dzFQSGlOdHAweXl5ek5pcThmOEFFSUtJd0dWMnRQ?= =?utf-8?B?SnVEMFZEM3FTZ1pvSEFIRXpDWEFyOGgyUnpKRGd4aDJ1dkdwUUVMMEQ3K1g4?= =?utf-8?B?Uk80KzRJU1Q5TDBYekZzL0tuazdIUEZRZVUremJKd3podnlvTXNsTk5id3Fa?= =?utf-8?B?UWx4eW1lMFcxVytDc1hNb0Vad3kzSjVlb3hJSVE2L3YvMlc5WmF1ejN5Q2cx?= =?utf-8?B?bjZhYkZzTjBLeUthekxkcld3MXp1djdDMHh6TjREWkRpZmw2dDl5QnBzc3JD?= =?utf-8?B?ZER5OXB2bUhjRVdQRkNESHpGRFlZb2x2NUJnSG1RTDN2T2FlZ1Njb2UrcTVW?= =?utf-8?B?d0VFYjRWWTNUTDdCZms4SXJnS1hqOFUrU2Z4WHZ4UDlwVVJYN3RCZUJBUktX?= =?utf-8?B?L2ZTakc5RWdFemJIZmpTM2diOVM3UlVkZDhDdHN3eHMvVVFGelFNU292UC9z?= =?utf-8?B?MXBOUzdkaURXMnBsNWpKQnpQaFNuS3NCaEVSZFM5UW5xeEtYKzdMMVlycmRs?= =?utf-8?B?cTlSY3VlNDVDWTRMMlo0a3U3YmR5WS83QWIzNTBjSVdsTXdrNngyRXpjc3pa?= =?utf-8?B?M2hXVGVKVVJKcGNpMXlZaldIUjhwRUMrNzh2U3NXUUQ5bW1qNlJXcU9HZXp6?= =?utf-8?B?VlhTV2JtTExBQ0FLTDF3b3hydFprY2FmR3pwWmowVmlwRUhNWi9oZ2xaY0gx?= =?utf-8?B?VVd0RURha1hoZExnVSs4NXE3ekY3WUJlQjJhOWZkT2RGdkRaL2hteVAwOXFh?= =?utf-8?B?U3NySENmaDBKenZPWGU2b1NScksyV2U5TFQ5WHhiWXR6NTBHMTJXZFNtdmdv?= =?utf-8?B?VXQveXFGQzMxTU54V0E1WlpkanNEZHMvaTRMZHNBQkgySG9wWktlZTFmdnpH?= =?utf-8?B?NUhnVzJWcExJQ1g5Sm8ydzM3UVRsOHZ5dkE1aFE4V1dLMzh5eDR4WmhJU1ll?= =?utf-8?B?NHNhMzExdUZOd1pCbEdQUG1mTklnQUJ5aWlRR2k5ZVJNZmV0OU1DeWZ5VEho?= =?utf-8?B?aTl0a3NsY2RNbWlBckkrZkgrdHVwUEpyTzY1VmNyZWsyTDk2OExVVzZvVEc5?= =?utf-8?B?YThTaXA0V2R3YTBpb1g2SnBWbXQyWk1yUnNGR0Q1Z0lXMmhUSFBLcUwybUg0?= =?utf-8?B?SWVlTG5oT0J5cmpWNmkzL2o4S3pndjBuWGVmTUFHWmtBMGo3TUdYRmdlUXE3?= =?utf-8?B?UldiZFllRnhvb3kvT1JNV2NiR01jdDN5T1lVNER2SkVFWEE4dEpUQlhZVmRH?= =?utf-8?B?V0l5UVhMcHV4ZzZnd0Z0WExGSmxTN1k0SWdhVFljWVVlanpaTEtUcWtZVkZw?= =?utf-8?B?WW5PSHBwQkJBT0FJRFRlS0FaT2NNSUxBNWpENWllY2dxRzlpM2hHTlNvTHFK?= =?utf-8?B?SzkraXV2a2VGeFJUeUM0NHRvNEwyWkJXTTJxU0M2QVMvYXRjc09hdkZyVGM0?= =?utf-8?B?WVV2NUs0MmxDVnhRY3Y0TytEOExPUHpHRktiM2tTekFpK040akY5U0dXcCty?= =?utf-8?B?OHlqSHpoRFc5djZMZ2FQMjVaREZUazV1aHpjMFUwTFBneEp4ZmNwWFdGbmhN?= =?utf-8?B?cjQ2cUFJSlJRS0dKQU8zVTYxb1BxbmxOOVFnWmJDVTc4bWlsU21uamJETGpv?= =?utf-8?B?Tm4xZ1ZoT3M5TjZkS3FXdmNUTGF2QVFEL1dCbXFEK1U0MlRxeWlyYTRwNWgv?= =?utf-8?B?cXNyWC9jaERQNVBTQjhtbFN6blVDTE95N3VORDV1SkJTa3o0ZWVrTUJYQTdL?= =?utf-8?B?K0V1YXMrMm8waUQ4TDg0akJiWDRTa3BsV0VDK1BkYXNQQ3JDcTF2RkxoY3F1?= =?utf-8?B?SG5wTmw1RDhtMG0wK3c3cUNMekczK3FTQ0V2RlcwL09CSDBJUVhqTlRPMDF2?= =?utf-8?B?Vm1Xc29HZHY0T3BTMU9FbVJCcldFWjJwMGlMUmFwOVJEY1BMcjJSK1hDRUdP?= =?utf-8?B?Q1pNcnlmRkIzQlFWU1dyRFkwM2dHc0U1Q1VLbEQ2S1FNRkF0WGFxUTFBcTNx?= =?utf-8?B?TGplcXl0aTFmVlhTN21WOG9vUUFBPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2026 11:39:52.2636 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e373d8ee-b2f6-4036-bd6b-08de5a741f79 X-MS-Exchange-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: SJ1PEPF00001CE3.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4372 On Thu Jan 22, 2026 at 7:19 PM CET, Andrew Cooper wrote: > On 22/01/2026 5:42 pm, Alejandro Vallejo wrote: >> On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote: >>> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote: >>>> Open question unrelated to the series: Does it make sense to condition= alise the >>>> MSR handlers for non intercepted MSRs on HVM_FEP? >>> I'm not quite sure what you're asking here. >>> >>> ~Andrew >> The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP a= s far >> as I can tell. The question I'm asking is whether there is another code = path >> that might invoke MSR handlers for non-intercepted MSRs. I can't see it,= but >> I'm not sure. >> >> If there isn't I'm considering (conditionally) getting rid of them. > > Introspection can (and HVMI does) hook them.=C2=A0 Changes to LSTAR durin= g > runtime is usually an exploit in progress. > > Nested virt also makes it far more complicated to reason about > "intercepted or not", given that there are multiple opinions merged > together. > > ~Andrew nSVM definitely would trigger those, ta. Conditionally removing nSVM is in our roadmap, and VMI is already gated on ALTP2M. I'll put this on the pile somewhere. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Fri Jan 23 12:10:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 12:10:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212223.1523484 (Exim 4.92) (envelope-from ) id 1vjFzj-00017K-0I; Fri, 23 Jan 2026 12:10:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212223.1523484; Fri, 23 Jan 2026 12: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 1vjFzi-00017D-T1; Fri, 23 Jan 2026 12:10:30 +0000 Received: by outflank-mailman (input) for mailman id 1212223; Fri, 23 Jan 2026 12:10: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 1vjFzh-000177-5m for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 12:10:29 +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 7bc95126-f854-11f0-b15e-2bf370ae4941; Fri, 23 Jan 2026 13:10:20 +0100 (CET) Received: from MN2PR01CA0066.prod.exchangelabs.com (2603:10b6:208:23f::35) by SA5PPFEC2853BA9.namprd12.prod.outlook.com (2603:10b6:80f:fc04::8e9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Fri, 23 Jan 2026 12:10:16 +0000 Received: from BL02EPF00021F6F.namprd02.prod.outlook.com (2603:10b6:208:23f:cafe::66) by MN2PR01CA0066.outlook.office365.com (2603:10b6:208:23f::35) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.10 via Frontend Transport; Fri, 23 Jan 2026 12:10:14 +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.9564.3 via Frontend Transport; Fri, 23 Jan 2026 12:10: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, 23 Jan 2026 06:10:14 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7bc95126-f854-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mMA3LrMzGvjn+GLtm5OT7Iii/iJD5aIg063qDy7Fpb3JM+yfSWd7VLJKGLQf9mjrrY99ebnM5e2/A38XrTBnbVHrYCxWZLtvL03sZgX3bgLwWoU21gpRDcbDvnbDXPHAbRk3mPN7YY+KS7bpEOTJatHM2HqJDrgy6072FsJ6uC3vsp3MBSBLnKkmexTII4XfezB2jVShPob/pU474C8GkRZjxB1qw3ETKV5kcIWiMn/A2HkC996nv7y5GpI1LAXhsVHxdyTeMBJsQ2DtJ+kH5VBLnYKpm0UVKfPxQn/X9n43tJH8RmpE18xRUodsMAJJaiqIhsQVTl3ttV03fozZGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rStHt3a2IjkI2MGQuSwJxr8R0DeCq4nsz0nSCRcDeA4=; b=pNW0A6Thb+h0oTiaSdJ0H8d8Yu0tuCd3xpQOWXfZLYlhEt/B90GTbgSD2JqgF+WwywR4GCsIK5sZ9tV3iXHfGaBme6ecU2q6TJ+devCyXhbpeE080UcCgkbDSnLHGu54DVzVxbNrEmFCHGrGYQo653e7R4AByKA29KPnTCfHMzyfKKpF7xGWNbfxQkRjoLGB7XVsN1eYdlNTKz9ezrSfyCbUSqBcN1MDa8yl9IwS5esn1iFAH6kq0wN0eshx6dvss6WUKjweHUVychgnJjpvjzSKiYpo2c1z1QHtFg3P/aaP+2ChXMmxby0ZM1XHC4vmTvn7SvRY8xs3npUOvioEWA== 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=rStHt3a2IjkI2MGQuSwJxr8R0DeCq4nsz0nSCRcDeA4=; b=iHT/rjTImi4wN1UTdrPnPeWDzf6roGt7Psl2qBS2F7lRKUzxxX2UbHYtDq8Uy0Oafaadz1nKrCcZBPFJ6Wv0YgY5cyssAxBivRNU0ROmWaxXJt0RaXF2KlhEDmSWdtJpAW3fjJmZcLRb6e2zHoKe88+P7pVf1jxXhPzWQT5NHUk= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 23 Jan 2026 13:10:13 +0100 Message-ID: CC: Oleksii Kurochko , Community Manager , Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk Subject: Re: [PATCH 0/4] x86: Drop cross-vendor support From: Alejandro Vallejo To: Teddy Astie , Andrew Cooper , X-Mailer: aerc 0.20.1 References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <3421e525-fb04-4306-9320-4fa359c2ee28@citrix.com> <26c416ea-1c4b-464a-bcb9-d34f0600eaac@vates.tech> In-Reply-To: <26c416ea-1c4b-464a-bcb9-d34f0600eaac@vates.tech> 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: BL02EPF00021F6F:EE_|SA5PPFEC2853BA9:EE_ X-MS-Office365-Filtering-Correlation-Id: 2bfffbcf-9c42-429a-fcb2-08de5a785e45 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?U1JDVmg0c21wREJpaWRwbmZpRjBCYVdScmdJTEZFZjdMQ0pseWlNWk5sQktQ?= =?utf-8?B?aHgyc09jQlVYbUdoMG9qVUt1b29EQTFNMUd6ejJTL3ZMQlFFZXozbGZVYU5O?= =?utf-8?B?VGtqQjFOZkNaRVRIUURaMmltYi9mR3hkVVJ3OWNzVDlMdWx4d3VVZkdyc1NF?= =?utf-8?B?SFVtcjIxZjE5c2d2aFZyOEZlOVRuUU1oc2FjYTVXSTVnWEYwRGZLOGVPcU8r?= =?utf-8?B?eXRXazFXR29Sa1ovZDlOUzB3djNCSUxibms1alBFRXdZQko0aXZUMm9aTDMr?= =?utf-8?B?UDN1TnJUZXNwS1RaQklKT1RaemEyRnU4bHpjV2hNaVlpTjQrRmdqS3FFR1lv?= =?utf-8?B?WXhUNFBKcEJKN3UzaGJkOFdibVllcGlaejR6VDVxOXJsKzF5YmU5b005dm9I?= =?utf-8?B?aUpVWHY5NUtGOEZ0TkNjVTU5OTU3QVZYajdMUnJacUl2WDVta1lkOUdBclJh?= =?utf-8?B?OGUzUWhRS1ZTNUFQeHZqSkx6akdLMVNXcG04NzV0N2M3dGdMeURtd0FyTTNr?= =?utf-8?B?TkpDWXdSQk5Oc3czVlVLSW93cU9JWGdrZ2RmTUdDREIwNU9sUXo5dFhYTnpX?= =?utf-8?B?cmFLbEtSL3NqMnVxakNtL1h4MVVhaUlOOStjamxBU0RuUWE2NmkzTnhvS0kz?= =?utf-8?B?a3UwTFZqRVhSY3JlVHFicDFkVnppQ2M3MkZLYUJySzZ3UE9zZXNiL2R4Q2lv?= =?utf-8?B?YThXMktkbEx1b0JUMWkxalhEcWpiazMvQzM2NzdrNlpMMFk5bnVnRDQxNzJz?= =?utf-8?B?dE5IcnlkcmxXSEJrY0JBYmVLVU5PNGFybHZ2TVV5clUwbCttYk4rRkhLM2xh?= =?utf-8?B?dHd3bXhlQnJwRjk3cFJpZFlFS2xKcERyTjgrc3Y5RTRxM2FJbHlOME5KLzZG?= =?utf-8?B?NkZlZEl5SmZHT2VEdi9uWVNmUFVFanJ2Zk5RakZaWUJiY21jUVpRZmh4QTlD?= =?utf-8?B?ZS9aeUNMNjI2NXhmeWI0ZWVPanBmRTY2WWZBZEQyMHdhOGE2UENXTm1pZERJ?= =?utf-8?B?YVhIaFh6YlpkZXhaOUdZQlkyR2krSUJMK0xiQk8vYzJYWEU0NGZiSTRRN29y?= =?utf-8?B?a0ZKNEdQVmpOM3BXQ1kxNFdXRkFwcEgwUzB2M2hhRGpYanhzOEpkZWFQZDRN?= =?utf-8?B?YnM3L2ZoYzM1cC9Idnlzd2FjbXhaZUlzRDVGQU5lUVZraXZ1VjVyZ1Z2eEQx?= =?utf-8?B?cmIwYVllcnVVQVNpekZ4WXdXSFp3RHpIN2hCaUtiWVVUZTQxR1VFN2d3ZEd2?= =?utf-8?B?NElvZUlPd1huYnZqN2VxV1NSQUtHZlpGNjhORWVsZ0tVOGd6QWtuelRtRWhn?= =?utf-8?B?b0NEQ2gydGVSNDRscWc1eDJBWWRyemlFcjZTQ2hZSkYxR0M3SlVwNXgxS2lD?= =?utf-8?B?MzFKTGpxYmc1anVrYjR3czJDTXkvS3ZvRUNqd0owRjNQOHdQdWl1Z3ZMRnhn?= =?utf-8?B?bmFPdDlhWk9TWE9YZDlnOTVSRldFNHF1NmFvOExTdDI1NWdrSUpZZ1RkS2l4?= =?utf-8?B?K0tIaGhSR0l3MTZZeFJWZm1rckVVMXdocWNQRHpjK1AvTTcyOVlZditkcVdj?= =?utf-8?B?MEtQRzAzUDVnTDhwNGtlSXNmc1l3TEdFOEJLUGhGRmRnbGJDUEJadFM4UGs3?= =?utf-8?B?UmJtRlV4ckpSMTNqSnpQdmJFQnV2a0gzR1BhZ0pGbzY5Mm5hbmw4UzNCZTR1?= =?utf-8?B?eDlUaXErRVpiZEVOSnoxdXJ1MktGck9TVU5kZitkNU1XejladWJZODcxUkV5?= =?utf-8?B?UFE0WkdaVFNUS3BTbXV3cnlPVGFhaXNyZVFNc3dvdGdQbFl4dE1CRmlLWXg5?= =?utf-8?B?OEM0UlVIalpHblJseG1VZGgwdnBOWm1DRndSUzdUV0szaDBKdTJhazRkTTNo?= =?utf-8?B?UTRUblJkaURIa3QxeUh4WGFJWFZBNEYvZm9tSnNJRi9lM2M0N0RFNDlFT1U3?= =?utf-8?B?RGt0djNlS2UyTHZQSVJhUVNpVURJN3REd0lnMFVYSDd4aHhJeWtZdmRYZXNI?= =?utf-8?B?T3RjOTBJNG1KM3FYQXVZVkViK1JpVkh5ZE1BMGpqL25xYklTeitoTEZ5Z2ZF?= =?utf-8?B?RlVEQ05McDc1MXVXRmwrdVlDVGl5bTk4MFREamFGVmRHR0Y1SERNczBROC9O?= =?utf-8?B?UmxXQkNUTzhXaVRLaVo4NENFTjA2SzlMeGNNc2FvUFJ5NTZBeU80TXV2M3M3?= =?utf-8?B?YUwrTzA3Y25SeC8xWlgrbjc3S1VKSUVIL2NCMXg2eGozdnZ4VmhWdWpqUkRh?= =?utf-8?B?aFJSOTNzakFFa3IrWC9XUHZJMk5nPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(1800799024)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2026 12:10:15.7037 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2bfffbcf-9c42-429a-fcb2-08de5a785e45 X-MS-Exchange-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: SA5PPFEC2853BA9 On Thu Jan 22, 2026 at 7:16 PM CET, Teddy Astie wrote: > Le 22/01/2026 =C3=A0 18:44, Alejandro Vallejo a =C3=A9crit=C2=A0: >> On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote: >>> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote: >>>> Open question unrelated to the series: Does it make sense to condition= alise the >>>> MSR handlers for non intercepted MSRs on HVM_FEP? >>> >>> I'm not quite sure what you're asking here. >>> >>> ~Andrew >>=20 >> The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP a= s far >> as I can tell. The question I'm asking is whether there is another code = path >> that might invoke MSR handlers for non-intercepted MSRs. I can't see it,= but >> I'm not sure. >>=20 >> If there isn't I'm considering (conditionally) getting rid of them. >>=20 > > I think you can enter this path by making the guest execute directly or= =20 > indirectly a rdmsr in a emulated path (there are some cases like certain= =20 > cases of real mode or maybe vm introspection). I don't think that FEP is= =20 > the only way to do that. For the emulation path, I think HVM_FEP is the only means to trigger it, as neither {rd,wr}msr access memory. VMI (as you mention) and nSVM (as Andrew = did) do make sense, but I don't see any others. I don't see how real mode could = cause anything (I'm fuzzy on VMX, but I _think_ instructions do execute, just in a weird paging-on mode akin to v8086). I'll munch on the idea I bit longer. If I can't come up with any other case= s I'll send something to remove that dead code for the cases in which it's tr= uly dead. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Fri Jan 23 12:28:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 12:28:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212239.1523493 (Exim 4.92) (envelope-from ) id 1vjGGw-0002y6-CJ; Fri, 23 Jan 2026 12:28:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212239.1523493; Fri, 23 Jan 2026 12:28: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 1vjGGw-0002xz-9g; Fri, 23 Jan 2026 12:28:18 +0000 Received: by outflank-mailman (input) for mailman id 1212239; Fri, 23 Jan 2026 12:28: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 1vjGGu-0002xr-Vx for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 12:28:16 +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 fc09b0b3-f856-11f0-9ccf-f158ae23cfc8; Fri, 23 Jan 2026 13:28:14 +0100 (CET) Received: from BY5PR16CA0016.namprd16.prod.outlook.com (2603:10b6:a03:1a0::29) by BN5PR12MB9509.namprd12.prod.outlook.com (2603:10b6:408:2a8::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Fri, 23 Jan 2026 12:28:09 +0000 Received: from MWH0EPF000971E3.namprd02.prod.outlook.com (2603:10b6:a03:1a0:cafe::50) by BY5PR16CA0016.outlook.office365.com (2603:10b6:a03:1a0::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.11 via Frontend Transport; Fri, 23 Jan 2026 12:28:08 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by MWH0EPF000971E3.mail.protection.outlook.com (10.167.243.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Fri, 23 Jan 2026 12:28:08 +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, 23 Jan 2026 06:28:06 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fc09b0b3-f856-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MTy1xXHBIRFOTSt7DdSGj2bfTQEfaRNDZZGP9JZDSCRCzlW1PQc/o2Iht3/Va6rLvQ/Qo95G0R8IyW+ro4zARk03a5pIaAL1d3O7ADrmDnOQQ1iOG6pv4as6e4iDrrSsWu5+3BbBISEs7NT3m0lbtiptgHC/Rnh3GdnG7vVR+obUVPShxVG/27faLwWUBQAJ0tQObsAzWXLj8E+XlOIM9QTjfsIUbpgzO5iJDiTuGFEjisDAXyFrPuZmcad4cmrk0a2G6QotaNeEZ7YfMIsguZj+BC48w94F7epyEZvQDv0giIGcsbHXcH3RKFpDH9OmI4fze4lCVUWpxPHIPuR4lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1iq5sflv63LWyrg4NiWJJtH93bDCkUumyWiTjyyQf5E=; b=uzWCIkfdpwDAdJ2g2O3tVevy//eVmPgjkqwecW2fqzdxt8E9YZqVVVsH0+cudEfKE3dlE/6DE5ZwgQteBDqWo+5IIGLz8jwkUwRuQtbJ4RnYdLadhjKW11rjuW0H4nRXRd5Ugxvtq+I9uYYcnTHQ95+4JkIZ561pQD++Q6lR3GJ9SYQ6UAtKERYI/HixBtHoPjigCxm0zyzr6U2d0HnNDIp3rIeiLJwfT3JESofrhzHwq+S/14XiVNYfH/D3zXybvGJVGgTPci+Ba2Z8qF0dctBs81ukKxlST+ojssTVRLpc8xDSiezpXQU2y1P+MM8K3xYQkemzPGqmidZK4Yj9cQ== 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=1iq5sflv63LWyrg4NiWJJtH93bDCkUumyWiTjyyQf5E=; b=Sdq1hI1w7EYFQD1oXQ/WfZqsGkKhIQkhrtEPNH44qgshE3NoDO/ewFkRTUfvnGFfHPmjAcrwYx78zJpHej8xUeOpWXJrFJEblMmbnwShbtw00CqD/7atVM/Mrd4k++lX8iX/C2us4YoHDI7t8o55/R/QgzaJB2NHgsB9U1vALYE= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 23 Jan 2026 13:28:05 +0100 Message-ID: CC: Jan Beulich , Andrew Cooper , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk Subject: Re: [PATCH 2/4] x86/hvm: Disable non-FEP cross-vendor handling in #UD handler From: Alejandro Vallejo To: Teddy Astie , X-Mailer: aerc 0.20.1 References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <20260122164943.20691-3-alejandro.garciavallejo@amd.com> In-Reply-To: X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWH0EPF000971E3:EE_|BN5PR12MB9509:EE_ X-MS-Office365-Filtering-Correlation-Id: f680a850-5da9-41ba-c847-08de5a7add84 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?a09SK3RVYTdkTjB5S1p4YnA3emYwbWU5eEMrRDE4cUYvMXdYcDFrbVpqbkdr?= =?utf-8?B?cFlWWkJFak81WkYzMnpiMTFLWDllTmFXd3c1aUI4emgxOUMwNDM2WFZHeUlz?= =?utf-8?B?QThKUmJVeVVVVHI0QktFblNYcFNFWUZaRDN2ejFyQ1VubFhhUVI5WFN1WjQ4?= =?utf-8?B?dGt2UytPMUJIeHkrM2NUaWRRMmYzNDRXYmlGaWM4YjAzendxRzM3dHJ4RFZJ?= =?utf-8?B?dEJuRUdVaFpTb2pQNWp1L3dlcWxTaDNzRlZ2d2x2Y09YOTdzYlRQNU1UUkxM?= =?utf-8?B?SnZabkpjYXp5Z2h5TFBZN1dGQWVISmRGWENWU2R5S2g5c0Ntb1N6NExpT2Q3?= =?utf-8?B?VTB1eGorblZ6Y1FZNUpUMmxBRTl1WCs4ZEpQZGgxTURHZ3c2OHhpeHNzOVBi?= =?utf-8?B?RFJXY1FXaDA3T1hBNVhaNi9wenNMeFRhNUVLazF0SnEwL3lOQVhVa0c3MWRz?= =?utf-8?B?clJuU0I2UjJKV08yaTNldVpOTFNTYW13QytUNGtBN2MvZHI2Z1BHWmpITENC?= =?utf-8?B?YmZXN3hDczdpQkJsTThSZFlOVE9FME5lMEQ2L3RyUjRGWVlGQlBPbG0vTW9V?= =?utf-8?B?aXp5MEZUa2tVOXF4YjV5bVNUUElIZ3FoT1VEZnFpNmtUdkxRZTRDeWpremtN?= =?utf-8?B?ekFTYlhnVFZON2VCbGdWbHQwMnM1L1NjdXZQVTloMFVlMVkxbmZWdEJuY00w?= =?utf-8?B?REdpUDJOckY3WXN6dzArU1dtWEJGWUZSSjFpbDNvek43OEFrNVFKR3FQd2Ex?= =?utf-8?B?TFZlSjhlenpDUS9ZT3dTZUxYc1gya1ZvSXN0eFdRQXJjSEttQzNjNVUvMzJ2?= =?utf-8?B?S2ZxNHppamYyUnMrM0R2ZnpiM1BWQmRPRHRmSFVncUhJS0o1MWdQTEd6WXR0?= =?utf-8?B?SFN2OTRxc21HcVBweGFkU1VrTy8xejlXUlZlWlBnMjk4NTROSXpwVHUwUCsy?= =?utf-8?B?Z09mcHR0clBYcjBxUHF0bVlXanIyRUVaOWgvVTFZdUUrblV3ZmFtdFpvNVBo?= =?utf-8?B?ZzM4K2JNQWh2VWhmODR0Wll1WVdRdCswOE9nRWFReTNSdVc5OVNvbHZ4S0xv?= =?utf-8?B?Z1RGUUdqQ0tqemI3M3M4K29uMjZhNlRRZmlveFN0NUN4cmJQZWpVcXIvQW0z?= =?utf-8?B?MHhhNHY0SW9rRUpFbkhOMnhQQVRzTjVwaERFK3pGejVsQ0JHSm1ZUTZON2N1?= =?utf-8?B?eWJad3ZrbEFVa1FHMFFST1NIMWR6Y3FPa0NwTUZQZytDdGNrTGdKZElEN3Jp?= =?utf-8?B?SnFMSXhjbkR0UEVKcE5XckRFZzIyTDZ6eC93QTczSjJHRE5sSGRVWS80NWhl?= =?utf-8?B?d0dGKzZMZ1RxR0NmYzVQWE1mTkczdFRpcUlDSzJGSWYvRHh2QTFaL25UWmhG?= =?utf-8?B?WVRCdTNRSjNMZ2FtRy8vN0w1azJHQk1pTGtOWUNza1BGdXlBWHlMVjBPVlQ1?= =?utf-8?B?RmorSDV2Y21WRE1Cd2lrMWxIMU5TV21sZ2NxVnJNTmJjV0Q3VjdxclBPdkJl?= =?utf-8?B?Nnl3akJWN0t3eXhWRjlITFNDdHdSRWcvVm9xR2t5VDRRN3JGYkloMGkycTgz?= =?utf-8?B?N0lWcnoxTmZBNTIwc1dFWlBBbjN6RkNWbVdIQzd6cVZQUFdIcEUzNnFkMlMw?= =?utf-8?B?WVJJZGRFTUt3UHo0QU00bnlIaWFUSnovZGhGSWxuUDJxdHo2RkhaK1pRbWdC?= =?utf-8?B?ZFVTUHIzUzBFRFpYL2ptWFc5Qk1OaUUxeEY1K2VtRVIwajQ1NGhOUG5oSVZX?= =?utf-8?B?dGZ4eW1MVE05WlRDL0gxamU4dE9iVjYzTFVXZno1VXQwQjhNaUp3VUJlSm5M?= =?utf-8?B?SFB3bFBMdzZYbTlCQ2dMa3lScVRPQ1M2cWlsMWVWNWtLaVI1anZWOXJBZ0w1?= =?utf-8?B?SDdaQmVZM0pZcE1UV3JObXNrY2FsTnhqbXdGOTBFeHkwd2VCMGsrRjV0S1BN?= =?utf-8?B?VXY4OUgyVm40RW43cXNwZ29GK1hkV0ZIeGxGTGdzTzJWN3NWdzRXT3krd201?= =?utf-8?B?STlnTStxN3hCOHRqY0l0VHpOQkpHMXRsNUZucWNqTldKU3ZYeTRFRGRhdzEx?= =?utf-8?B?eldDQUhoQ016b3gwbTIxNzR2bTZkek5xU3VHaDNXOWd6VVVUQ1Zua3VMUlUx?= =?utf-8?B?RWN2RHliYk5XdktHOUlUV2wwRi9SZGhGdm1kcWlxNHFhM0V0aGNQdFIxdkFl?= =?utf-8?B?Vmp4ZlZXL0I2VjJUTzVNMVBmaG1zdUVldGdPYWxCRWRjK0RCbDgyRVVRRGhn?= =?utf-8?B?ejNycllMZ08xN0lsV1NPbENpdGpRPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2026 12:28:08.1397 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f680a850-5da9-41ba-c847-08de5a7add84 X-MS-Exchange-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: MWH0EPF000971E3.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN5PR12MB9509 On Thu Jan 22, 2026 at 6:28 PM CET, Teddy Astie wrote: > Le 22/01/2026 =C3=A0 17:52, Alejandro Vallejo a =C3=A9crit=C2=A0: >> Remove cross-vendor support now that VMs can no longer have a different >> vendor than the host, leaving FEP as the sole raison-d'=C3=AAtre for #UD >> interception. >>=20 >> Not a functional change. >>=20 >> Signed-off-by: Alejandro Vallejo >> --- >> xen/arch/x86/hvm/hvm.c | 25 ++++--------------------- >> xen/arch/x86/hvm/svm/svm.c | 4 ++-- >> xen/arch/x86/hvm/vmx/vmx.c | 4 ++-- >> 3 files changed, 8 insertions(+), 25 deletions(-) >>=20 >> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c >> index 4d37a93c57..611ff83a60 100644 >> --- a/xen/arch/x86/hvm/hvm.c >> +++ b/xen/arch/x86/hvm/hvm.c >> @@ -3832,28 +3832,13 @@ int hvm_descriptor_access_intercept(uint64_t exi= t_info, >> return X86EMUL_OKAY; >> } >> =20 >> -static bool cf_check is_cross_vendor( >> - const struct x86_emulate_state *state, const struct x86_emulate_ctx= t *ctxt) >> -{ >> - switch ( ctxt->opcode ) >> - { >> - case X86EMUL_OPC(0x0f, 0x05): /* syscall */ >> - case X86EMUL_OPC(0x0f, 0x34): /* sysenter */ >> - case X86EMUL_OPC(0x0f, 0x35): /* sysexit */ >> - return true; >> - } >> - >> - return false; >> -} >> - >> +#ifdef CONFIG_HVM_FEP > > I'm not sure it is wise to put it being ifdef given that we have it in=20 > support.h. We already abuse code elision in this manner. See domain_soft_reset(). It's intentional, to avoid polluting the headers. You'll get a link error anyway (as opposed to a compile time error). > > Given that this function now assume we have FEP enabled (since it's only= =20 > called in that case), I think we should rename it to reflect that, like= =20 > "hvm_fep_intercept" and drop the non-FEP logic. I'm not a big fan of renaming the handler, because it'd force future change= s where #UD is invoked in more cases than HVM_FEP to rename it back. But yes to the removal of the non-FEP logic. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Fri Jan 23 12:33:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 12:33:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212248.1523503 (Exim 4.92) (envelope-from ) id 1vjGLs-0004Tw-UX; Fri, 23 Jan 2026 12:33:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212248.1523503; Fri, 23 Jan 2026 12:33:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjGLs-0004Tp-RU; Fri, 23 Jan 2026 12:33:24 +0000 Received: by outflank-mailman (input) for mailman id 1212248; Fri, 23 Jan 2026 12:33:22 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjGLq-0004Tj-Oq for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 12:33:22 +0000 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170100009.outbound.protection.outlook.com [2a01:111:f403:c107::9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b23277e4-f857-11f0-9ccf-f158ae23cfc8; Fri, 23 Jan 2026 13:33:19 +0100 (CET) Received: from BN9PR03CA0988.namprd03.prod.outlook.com (2603:10b6:408:109::33) by DM4PR12MB7504.namprd12.prod.outlook.com (2603:10b6:8:110::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Fri, 23 Jan 2026 12:33:10 +0000 Received: from BN1PEPF0000468B.namprd05.prod.outlook.com (2603:10b6:408:109:cafe::c) by BN9PR03CA0988.outlook.office365.com (2603:10b6:408:109::33) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.11 via Frontend Transport; Fri, 23 Jan 2026 12:32:47 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN1PEPF0000468B.mail.protection.outlook.com (10.167.243.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Fri, 23 Jan 2026 12:33:10 +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; Fri, 23 Jan 2026 06:32:37 -0600 Received: from localhost (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_256_GCM_SHA384) id 15.2.2562.17; Fri, 23 Jan 2026 04:31:19 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b23277e4-f857-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tRyF6qdQeUkf5GpW68R+cytkXfCzhRpPp/dG/dprXX4zSrs5BmPXnR4PzsQZuYuiPic9xyBJjRU/YR0nHtQqtyMyBa8YvtnCW4ROAiyvETDheNVx6RVC/f5sHMPvC28MfLtjAvZwWkPCUG8UfqpEd1xGOLApcNH9aINe7dSAoWeU0j19rDxab91qIo56JEoT3RvOwpeeEEi7orAWDh/kmU0xdrrVRQLrKcn4Oc+6fFvN0FDFSGI9zcdAhkQplveN7P/ZNe640SRCZ0R7hLGIzYZmtnkq8+TzIGSc8PZYWC9vImzHYJwooJaI+JW4VxmYm5B8rjXTrom6+o/qXUA44w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sOQxoYRUoqiBrgQ2Q+ai5d2Bt/hVMWmdjg6vA/KIxoU=; b=o3edaJaUwDbT4apBvzj915qtB+0vHdpzfXiK0mEs+lujJR74LuRgQ6n/a3SURf3AwLCGg+UAhrjxb+P0fo+vlDHzP7qjmS7cfIeSHeIQORHO+q6sBemq5z4o4pI5zL/ynSDaaLEmLluC4LhiKV4dY1zVQ6wU3WUlKLb9KwgiMyz2+tSNYMS5x4tNrbxKVLWnc90LXOGv7RhQMdwDKZOS6zFprBKzeIgPbqIP6hH4qLQhoryMShLOZ02iDhtM1MaUUfWIJ03ziHvipO2RRg0cquwpp/Y2SaLtzaRN+4+sp3dCK2kj6tTUF5ztHW0c4TgyGjVtM4txNpMZGluqAfgc/g== 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=sOQxoYRUoqiBrgQ2Q+ai5d2Bt/hVMWmdjg6vA/KIxoU=; b=Z/V6WmnTrW9fDkTUN7ElEVtSPtAAYlg+JIjYNrLOlENMPI/FO5SgqqBsBC5I9GSvLHOUVrZMHiskEmuqFVKV1FszU/Tr2Q6/5ilMu6oX4dyIlkjgyajat2twvKx8ZhfiG3Brr9sBClny5v9Vc+Cpw/j4FcX1KaFXImaB6UabJeM= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 23 Jan 2026 13:31:17 +0100 Message-ID: CC: Jan Beulich , Andrew Cooper , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk Subject: Re: [PATCH 4/4] x86/svm: Drop emulation of Intel's SYSENTER behaviour From: Alejandro Vallejo To: Teddy Astie , X-Mailer: aerc 0.20.1 References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <20260122164943.20691-5-alejandro.garciavallejo@amd.com> <8b0eed14-e35c-46b4-b414-1f0309a27a60@vates.tech> In-Reply-To: <8b0eed14-e35c-46b4-b414-1f0309a27a60@vates.tech> X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb09.amd.com (10.181.42.218) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1PEPF0000468B:EE_|DM4PR12MB7504:EE_ X-MS-Office365-Filtering-Correlation-Id: 7b6b7441-ab0e-4b13-7bc0-08de5a7b919f 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?NFdWQkNzSmg2engrYzNwOWJxQ2dLalBPbWtWeHJZc0Exdi9objNVMnE5T3Nj?= =?utf-8?B?ckNyUENjaFdUNlZVdnNqa21ZZ1VLZFpBa2dZN09yWnBrZDJSSEVveFVsV1k1?= =?utf-8?B?RkpoM2RPOEluM1JTWmJZY0NzTFYxbmc4UnA0dHpjV3hrN3dvQ0twRWJUZXJ1?= =?utf-8?B?ek45WnBtbXlCbFI4VkNNNk5lVE5yYXVMbHVYc0V2c3FhVnh4MGY2SDRneXl0?= =?utf-8?B?Yjh4czJQZGtncmgzbGl4U0FpT2tMNHN1SjREQXVXdGoxd1VFZkNTVkE2eC90?= =?utf-8?B?d3FrZ3YxeWF1U0JxSGJYbEdKRmFlTStYb1lVbTlLVmluTXFvUVNCbWszZXRy?= =?utf-8?B?Vm0wZUxkdmdjSzFiKzJ2QlRBM2pkQnZxT2oyNWRuUWJSZlZQL05lbjRyZ21U?= =?utf-8?B?QTRxRktVb3ZtSmxXWnNTck40RnBXL3YrVVVGZFMvNDFlVHozVUV2VWJHRUVw?= =?utf-8?B?YXVJZEhyK2RHdWErRmhyb0M0Ym5UOXlYRUYyL3IzMTZMd3NtKzRXNVlHVE55?= =?utf-8?B?OExLaTdqalFvSmNpYXBXMEdHVy9Zc1ZnVmlhV3drc2FrelBvYzlqd3Q1eHVt?= =?utf-8?B?bElscUZNRkFENDNaaHUvZzFBVDlXMnd3aGkveFA2aVJZNHIvZW9ZcEVHUkkr?= =?utf-8?B?eG93a3ErVVNldFpBRXhydnN6OGh5UzFRRHRSbldZblFwZVViSmU2ZzdoeVpn?= =?utf-8?B?Nys5QWVqTlFZMWpFOE0xZFNacXhRUlhTVkc5QTl2OElGWDRkdHVORDFIWWJ4?= =?utf-8?B?NS80SUJEb2twWXUreDh4UVNPRGJmbzUyOE8yR3ZqcU9YUytHR2I4UGI5T1FW?= =?utf-8?B?Q0ExdXJ4VmVxQUYwWVVxUXlNckZreDJrREIzOWlpUDNnK1l3RC9rYk5BVUhC?= =?utf-8?B?MHg0M0xpNUtKOElGMTFPUWVJakVTTDdUeHllbTkwc2ZlYnRwMmpKYkEwWWFW?= =?utf-8?B?NzUwMmViSERQeEVsZnZhdjE3T2NkWEwvc3hwckRici9ISWZReHVvOHpON25n?= =?utf-8?B?V3ZON2hEUmwxY1k1RFkxQ0syaWpOUzExU0JvYmJ1bFhmV1dZMzNCTHNmUVZt?= =?utf-8?B?eGRhTzFEdXZtbGl5ck96R0xuNTJuVkRWd2dpT1ovTUxTQkhvbHhXMkNVZVlB?= =?utf-8?B?RW93YThUZGNhZTZjTGtKNUZ3VE9UTHJTYlZBdGpTbkVvbHFKZ3BYV0puMTRx?= =?utf-8?B?akZDc0lKcTNhNW83TGMzSXJYaGs4VEJBdXBxckZrSVc4V2phb3B5bzJtQ2pX?= =?utf-8?B?YW44L01TV2p3RkhEaWVjMEJqVGpmNTE2M3dhZU03aGluT1hPTmxwRmluNU83?= =?utf-8?B?aWRTY3N4K08zUEtEay94U0FNVHA2djFrSkFFNkY2aGdDZ0JBUkxFY3k5S1dC?= =?utf-8?B?bzN5amxQSzBnbHdBaG55amxEeTgwcWF5QmNQVEV3ZVdNdVpDL2tDRDEyM1F1?= =?utf-8?B?eFpVNDdWditxbXAyUFJuUjV5d0w4Ym9Ud21KMks1a3VQcWdaeWxuRmtrbGhx?= =?utf-8?B?WE1KUnQ5OGExL1hNaXh2Y0lhZWNTdXFIWUNhMWFXN3k3MFgxc3N4dUgycnFG?= =?utf-8?B?RnF2YkhuOGJuRjNHeFBOV1VveEkrRFlrSFhpeUFMNldaL0VWTjhwaW0rcFhU?= =?utf-8?B?cE5ocEZFT0xPY1B5Z2hDSitqTkdLYUp4RWRBS3pDNWFEVlZGcSs3TVUweUd3?= =?utf-8?B?V2hFczRCK0NQdlRYQ1JZQnV1RjYwcGhHb1ZTYkR6WlA2enpPVU5FdkFjbWhv?= =?utf-8?B?dDVIcnVMNzhZYmxMWE5GZiswTGJpNWFoVEl6blc0WVRGYkF4cGI3UWsxWXl1?= =?utf-8?B?emRLckdWcUljM05obWI0L0VFVUE5Q0RrcVdkaHhXckIvdDBDdThWTzVFVkNZ?= =?utf-8?B?WTdSNVNJb1RUQTlXYTlxazZuZUY2dWcyM3VibjFUeTZjSzZYY2dYQzJnUW9l?= =?utf-8?B?Y0hkbzlqRnM4MHFNbS9WbFI3bHUvSjQyVmk2ZGtMNU5meHhnOENkTDNjN3dE?= =?utf-8?B?Z3Y5VDRoWFhINS9EbU1NOTZHRFdZdXFxRjNQSVczTTRVU3JoWlZPMXh6dGpQ?= =?utf-8?B?UmQyN2hpNFB5S0x4aTVnd0dhV0QrUG5IajVidHVNM0JMemJMUEhwSWhTQ2VZ?= =?utf-8?B?SFZaUXY0Vlp6Wm85WFU4Z2ZUQUtiSEdqMU9Nd1N5cWNxVWE3YlVYVElvKzlq?= =?utf-8?B?V0REbHc5RERGbEtVK3N6MDhCNk56UG5wMi9XWE85SHZpaVMzbEl3MmdSb1RY?= =?utf-8?B?dCtwRERBZXBsZGM3dlpVUUNLZ1dRPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2026 12:33:10.3235 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7b6b7441-ab0e-4b13-7bc0-08de5a7b919f X-MS-Exchange-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: BN1PEPF0000468B.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB7504 On Thu Jan 22, 2026 at 6:52 PM CET, Teddy Astie wrote: > Le 22/01/2026 =C3=A0 17:51, Alejandro Vallejo a =C3=A9crit=C2=A0: >> With cross-vendor support gone, it's no longer needed. >>=20 >> Signed-off-by: Alejandro Vallejo >> --- >> xen/arch/x86/hvm/svm/svm.c | 42 +++++++++++------------- >> xen/arch/x86/hvm/svm/vmcb.c | 3 ++ >> xen/arch/x86/include/asm/hvm/svm-types.h | 10 ------ >> 3 files changed, 22 insertions(+), 33 deletions(-) >>=20 >> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c >> index 0658ca990f..e8f19dec04 100644 >> --- a/xen/arch/x86/hvm/svm/svm.c >> +++ b/xen/arch/x86/hvm/svm/svm.c >> @@ -401,10 +401,6 @@ static int svm_vmcb_save(struct vcpu *v, struct hvm= _hw_cpu *c) >> { >> struct vmcb_struct *vmcb =3D v->arch.hvm.svm.vmcb; >> =20 >> - c->sysenter_cs =3D v->arch.hvm.svm.guest_sysenter_cs; >> - c->sysenter_esp =3D v->arch.hvm.svm.guest_sysenter_esp; >> - c->sysenter_eip =3D v->arch.hvm.svm.guest_sysenter_eip; >> - >> if ( vmcb->event_inj.v && >> hvm_event_needs_reinjection(vmcb->event_inj.type, >> vmcb->event_inj.vector) ) >> @@ -468,11 +464,6 @@ static int svm_vmcb_restore(struct vcpu *v, struct = hvm_hw_cpu *c) >> svm_update_guest_cr(v, 0, 0); >> svm_update_guest_cr(v, 4, 0); >> =20 >> - /* Load sysenter MSRs into both VMCB save area and VCPU fields. */ >> - vmcb->sysenter_cs =3D v->arch.hvm.svm.guest_sysenter_cs =3D c->syse= nter_cs; >> - vmcb->sysenter_esp =3D v->arch.hvm.svm.guest_sysenter_esp =3D c->sy= senter_esp; >> - vmcb->sysenter_eip =3D v->arch.hvm.svm.guest_sysenter_eip =3D c->sy= senter_eip; >> - >> if ( paging_mode_hap(v->domain) ) >> { >> vmcb_set_np(vmcb, true); >> @@ -501,6 +492,9 @@ static void svm_save_cpu_state(struct vcpu *v, struc= t hvm_hw_cpu *data) >> { >> struct vmcb_struct *vmcb =3D v->arch.hvm.svm.vmcb; >> =20 >> + data->sysenter_cs =3D vmcb->sysenter_cs; >> + data->sysenter_esp =3D vmcb->sysenter_esp; >> + data->sysenter_eip =3D vmcb->sysenter_eip; >> data->shadow_gs =3D vmcb->kerngsbase; >> data->msr_lstar =3D vmcb->lstar; >> data->msr_star =3D vmcb->star; >> @@ -512,11 +506,14 @@ static void svm_load_cpu_state(struct vcpu *v, str= uct hvm_hw_cpu *data) >> { >> struct vmcb_struct *vmcb =3D v->arch.hvm.svm.vmcb; >> =20 >> - vmcb->kerngsbase =3D data->shadow_gs; >> - vmcb->lstar =3D data->msr_lstar; >> - vmcb->star =3D data->msr_star; >> - vmcb->cstar =3D data->msr_cstar; >> - vmcb->sfmask =3D data->msr_syscall_mask; >> + vmcb->sysenter_cs =3D data->sysenter_cs; >> + vmcb->sysenter_esp =3D data->sysenter_esp; >> + vmcb->sysenter_eip =3D data->sysenter_eip; >> + vmcb->kerngsbase =3D data->shadow_gs; >> + vmcb->lstar =3D data->msr_lstar; >> + vmcb->star =3D data->msr_star; >> + vmcb->cstar =3D data->msr_cstar; >> + vmcb->sfmask =3D data->msr_syscall_mask; >> v->arch.hvm.guest_efer =3D data->msr_efer; >> svm_update_guest_efer(v); >> } > > I think we should merge svm_save_cpu_state/svm_vmcb_save into=20 > svm_save_vmcb_ctxt and similarly for svm_load_cpu_state/svm_vmcb_restore= =20 > into svm_load_vmcb_ctxt to avoid having multiple functions as a part of= =20 > the same logic. > > That could be done in a separate patch (or series). Maybe. I (subjectively) think it makes sense to keep separate the fields co= ming straight from the VMCB from those that have authoritative values elsewhere. Nothing precludes having that visual separation within a single function th= ough it's not like either is huge. I may append it as a patch at the tail. > >> @@ -1720,12 +1717,9 @@ static int cf_check svm_msr_read_intercept( >> =20 >> switch ( msr ) >> { >> - /* >> - * Sync not needed while the cross-vendor logic is in unilatera= l effect. >> case MSR_IA32_SYSENTER_CS: >> case MSR_IA32_SYSENTER_ESP: >> case MSR_IA32_SYSENTER_EIP: >> - */ >> case MSR_STAR: >> case MSR_LSTAR: >> case MSR_CSTAR: >> @@ -1740,13 +1734,15 @@ static int cf_check svm_msr_read_intercept( >> switch ( msr ) >> { >> case MSR_IA32_SYSENTER_CS: >> - *msr_content =3D v->arch.hvm.svm.guest_sysenter_cs; >> + *msr_content =3D vmcb->sysenter_cs; >> break; >> + >> case MSR_IA32_SYSENTER_ESP: >> - *msr_content =3D v->arch.hvm.svm.guest_sysenter_esp; >> + *msr_content =3D vmcb->sysenter_esp; >> break; >> + >> case MSR_IA32_SYSENTER_EIP: >> - *msr_content =3D v->arch.hvm.svm.guest_sysenter_eip; >> + *msr_content =3D vmcb->sysenter_eip; >> break; >> =20 >> case MSR_STAR: >> @@ -1940,11 +1936,11 @@ static int cf_check svm_msr_write_intercept( >> switch ( msr ) >> { >> case MSR_IA32_SYSENTER_ESP: >> - vmcb->sysenter_esp =3D v->arch.hvm.svm.guest_sysenter_esp = =3D msr_content; >> + vmcb->sysenter_esp =3D msr_content; >> break; >> =20 >> case MSR_IA32_SYSENTER_EIP: >> - vmcb->sysenter_eip =3D v->arch.hvm.svm.guest_sysenter_eip = =3D msr_content; >> + vmcb->sysenter_eip =3D msr_content; >> break; > >> =20 >> case MSR_LSTAR: >> @@ -1970,7 +1966,7 @@ static int cf_check svm_msr_write_intercept( >> break; >> =20 >> case MSR_IA32_SYSENTER_CS: >> - vmcb->sysenter_cs =3D v->arch.hvm.svm.guest_sysenter_cs =3D msr= _content; >> + vmcb->sysenter_cs =3D msr_content; >> break; >> =20 >> case MSR_STAR: >> diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c >> index e583ef8548..76fcaf15c2 100644 >> --- a/xen/arch/x86/hvm/svm/vmcb.c >> +++ b/xen/arch/x86/hvm/svm/vmcb.c >> @@ -97,6 +97,9 @@ static int construct_vmcb(struct vcpu *v) >> svm_disable_intercept_for_msr(v, MSR_LSTAR); >> svm_disable_intercept_for_msr(v, MSR_STAR); >> svm_disable_intercept_for_msr(v, MSR_SYSCALL_MASK); >> + svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_CS); >> + svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_EIP); >> + svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_ESP); >> =20 >> vmcb->_msrpm_base_pa =3D virt_to_maddr(svm->msrpm); >> vmcb->_iopm_base_pa =3D __pa(v->domain->arch.hvm.io_bitmap); >> diff --git a/xen/arch/x86/include/asm/hvm/svm-types.h b/xen/arch/x86/inc= lude/asm/hvm/svm-types.h >> index 051b235d8f..aaee91b4b6 100644 >> --- a/xen/arch/x86/include/asm/hvm/svm-types.h >> +++ b/xen/arch/x86/include/asm/hvm/svm-types.h >> @@ -27,16 +27,6 @@ struct svm_vcpu { >> =20 >> /* VMCB has a cached instruction from #PF/#NPF Decode Assist? */ >> uint8_t cached_insn_len; /* Zero if no cached instruction. */ >> - >> - /* >> - * Upper four bytes are undefined in the VMCB, therefore we can't u= se the >> - * fields in the VMCB. Write a 64bit value and then read a 64bit va= lue is >> - * fine unless there's a VMRUN/VMEXIT in between which clears the u= pper >> - * four bytes. >> - */ >> - uint64_t guest_sysenter_cs; >> - uint64_t guest_sysenter_esp; >> - uint64_t guest_sysenter_eip; >> }; >> =20 >> struct nestedsvm { > > Reviewed-by: Teddy Astie Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Fri Jan 23 12:54:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 12:54:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212266.1523514 (Exim 4.92) (envelope-from ) id 1vjGfX-0007MG-Im; Fri, 23 Jan 2026 12:53:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212266.1523514; Fri, 23 Jan 2026 12:53:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjGfX-0007M9-Fl; Fri, 23 Jan 2026 12:53:43 +0000 Received: by outflank-mailman (input) for mailman id 1212266; Fri, 23 Jan 2026 12:53: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 1vjGfW-0007M3-LK for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 12:53:42 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8968d4a8-f85a-11f0-9ccf-f158ae23cfc8; Fri, 23 Jan 2026 13:53:39 +0100 (CET) Received: from DS7PR03CA0022.namprd03.prod.outlook.com (2603:10b6:5:3b8::27) by DS2PR12MB9712.namprd12.prod.outlook.com (2603:10b6:8:275::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Fri, 23 Jan 2026 12:53:34 +0000 Received: from DS3PEPF0000C37B.namprd04.prod.outlook.com (2603:10b6:5:3b8:cafe::5e) by DS7PR03CA0022.outlook.office365.com (2603:10b6:5:3b8::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.9 via Frontend Transport; Fri, 23 Jan 2026 12:53:19 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by DS3PEPF0000C37B.mail.protection.outlook.com (10.167.23.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Fri, 23 Jan 2026 12:53:34 +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; Fri, 23 Jan 2026 06:53:34 -0600 Received: from [10.252.147.171] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Fri, 23 Jan 2026 06:53:32 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8968d4a8-f85a-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QJjmO2zqb46//thrPxx9RhcPZfo3Q3egXrTyaOGn3AsBJp3n0v07p35dORBhqBJc94Q7+vHkumJ49Es2imL8BcnR1U39ly/M+lIYaYAaVGHfw5HETeMV0c3v9ZA4ma+gIu5V2lpYL0ikLQTozDZ+ukKFzziayAwh5Xd7qbUoRxHSneINmHEPGZU8bDyG77BviS8azzMOKOEaW1jxpR/lv6gh4JLBUaZlNlueI/BXky2GQ+0oRfzEE7TT+Qdu7vkO6OMO5jdsP7FcCgnK6YdJ2SIjscMLmkwteQ8CRWDkAWtQgKsqSsHY9vNxe2MJxhcC9lOaviRRWndXg+KNnlDa5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SW35XvlIx+S/Jd949buxSvZ9DPei6U3vMT8XhIBiezQ=; b=BORGl8x81ccboXC7iGWSnqS5qOzeHvHSH8hiru33ElmPbJB6/pRFqmG9xQ4uCRAo00gvkLIfNspqPIglUPYZUNbwCBvBfkjjRYqHFoVET9t3HdseDq4IgfUZPbn3AOK19hJ0LYL7gHoD4YNUV4AEkIhSaxH8O3g94tgs8r83lrSBRMCDHLhzgtwk2ec+Me+DJxqAV6AgSx+ML1Z//+Be2i+wXeQr2JL8MxDpK3fNKZZQf+INb/vtNiSgBjs29x6ywfcb/1tYGdqCA9rv7leGKONqKVekD+TQxOY0SmnXwfxJNzjybMLurpk4uvCor0xtsQ1XXnuUVG2iGYU0j3oC4g== 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=SW35XvlIx+S/Jd949buxSvZ9DPei6U3vMT8XhIBiezQ=; b=Zjx4EvfekGV/6WyOw+OjCe9P8wPRC9/u1EMgPgUAd4qPBDyKdOlp0dicDbUDVuUnf/PJ4eBFZWcO508bzY7JB1EBGYAA8dwX2KSGZXzLbkpVHIIb3M5nR2uPdNp8s5lEoKpdi3o3seyJubeGhWe22frvYKibSypWG2Vv9bLwRc0= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <0e3e6d33-c0a9-44a4-a7f0-3456c9d8d77e@amd.com> Date: Fri, 23 Jan 2026 13:53:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/2] xen: Allow lib-y targets to also be .init.o To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , , Alejandro Vallejo References: <20260121154757.44350-1-alejandro.garciavallejo@amd.com> <20260121154757.44350-2-alejandro.garciavallejo@amd.com> <526ef477-0730-4e22-a82f-4c598ad78e0a@suse.com> <7024dd52-b209-4daa-94a4-8b966aed4499@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: DS3PEPF0000C37B:EE_|DS2PR12MB9712:EE_ X-MS-Office365-Filtering-Correlation-Id: fed8c37d-ceb0-4e75-c693-08de5a7e6b5d 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?T1dMaEdVMm9mSXdrd0hocGQ1R0FINFZNcWUwR1VoZ1I1UThUdnVqM3RZWUhN?= =?utf-8?B?M1lKei9ETVRQVk9kcWtydWgwejZSbTN4SDBMRERQZ2VkZmE2ZzZtSjlGdGRj?= =?utf-8?B?T09rSUNEd05KWmU3Rnl1RHVtbktlelliUU5NSkxKa0p2Qm0xTEdFR29WVmRp?= =?utf-8?B?L2FDTGhJbkVKV1JJQ014bGN2b0tldzdqYXhNdWNZd2x6UU9zdXBjelk5WnNG?= =?utf-8?B?ZDlQM1NFUlppSTZrc1Y4cnN3VHFONlcrR0pnaHJxOHozYUhTUURpWEVyamt5?= =?utf-8?B?RDFRQ0p4eGJzOUYrM2VUdjlFUlFGU2dmRUdJaEplWDBBSitYdlhZN3lVaEYx?= =?utf-8?B?NjFLclV5MlV5QSsxZlJJSU83MDVoUm9sblk3Q08wWTB5c3JkSzV2RGFZbjRz?= =?utf-8?B?OGRuMUk0OVRoTTJyS2VJSERyempLcm42WFdyck5WeGdTWkpuSkFueXJsWVFP?= =?utf-8?B?cGxJRmlUZDAvQlVFdVJzcUZpMlUyc0VRMElEV3dIOXZjMkQzTG1DU1gzZHFW?= =?utf-8?B?dkdqRWZSU0ZIbSsrdTN6UFBzV1JUSmJSbzExamZhYzJGWnVZdmhoQTJ6c3c1?= =?utf-8?B?c1crcU13R3B6SFMwa01yUHpSTkNlUVFWNjJCMVEvMHZiNkNOU0hXUC84djcv?= =?utf-8?B?d0F6SmluUjY5Zjh0dGRRSDY5NjNZTG8rTlpwa1E4Y0JFLzZudlhWUHlpRldK?= =?utf-8?B?cjFzVWpncWdTU0lpWktKQW1ZMXNocm5pYmh2QWxtc2lKTzNqbkM3NW9VcUNM?= =?utf-8?B?UDdXcVo0T0FHYWVsSGZ1L1hsTkkwZlluVlNoR3h0MUlKYlh5VGtpVGNMeWxj?= =?utf-8?B?aGV2Uld2VXJkNVc5Ti9aNEJiL2J2RDB2WVBsQnJNOXErMno5Y2o0RDMzcFJZ?= =?utf-8?B?dnFKZ1pzeS9EQlU2MHRzMzllYnlNZmZJZDdSaytkalhBdzVSMWYvMWI4V09v?= =?utf-8?B?SzNzQ0ZmWVlVM3IwbUhrMVc0QTlPdmorMkt5amVlbkVNMGpmUWxwbExISTVk?= =?utf-8?B?THA5cmsxczh2d0hEWlZBclNzYVNyVk1ya2IxRkpuUExkSlZ3ZVJ5THFveUhB?= =?utf-8?B?dTIvcUJpV2pBdngwWWpuVXBOY3VTNk5oWDZJTlJwemJ0WUpjNnJ2L3ZkQktm?= =?utf-8?B?eDhKUXVlUGY4L01GUTJpNUxwSWhsNVpjWGU5VzRTKzRhRjZUOEMxMDBxUHlB?= =?utf-8?B?blkzdXlYMzd3WGh6RWpnS1B5N3M1TlpxRy9xTVRkeEFaVVI2V3p1WlhQZGZL?= =?utf-8?B?S2pIUmx6WXZyMjd4dS9qQVZ6NFpsejQydWFENXJneWt1RFdlUGF3amxVQ3lO?= =?utf-8?B?VkdDOEJGVGtpYmhSZVlZRFJ6cGhRWXo2RVZLUklZWC9Sc2tQR2tBeDRLYnor?= =?utf-8?B?dXp0WGdyVFZSbVR4T3VjeW0wZmNQREcvNERsclNIL3Z1Ukp2YmdOaHlmZTRl?= =?utf-8?B?V2xuZUFHRU5SVGNYMnlBODVCME9wcysyaVVCckFZSkhxYlYvSzN1WHAzQXRm?= =?utf-8?B?aEVzZXcrYUdrdC85OEUvZFBmWG9ZSmhoVVNhclI0R1pybUxYcStwaGNrbkxB?= =?utf-8?B?MW5iQWMwTWx3aXRjQVk5SmZ3eVN2RHlvMGQ5WTdVenJOVlpEWWMwcVZpem95?= =?utf-8?B?aGI2Y3VnU05UbGtiNTZkU2JPY3V4OGt5RDd2WS9XWkx4Q2RHNmRnYmptb2hZ?= =?utf-8?B?MUxUMzZaMlJwTXVaSU55SnBualAxR2x2TzczOWF3aTVZSkFhVmsyOGFNenh0?= =?utf-8?B?V1JGYnFyeVRPSGdkaE9wZStTMFBGZjYvVVVRM3pmVmM5OVhjYWN2MzZIRlJD?= =?utf-8?B?WHZwbElRMHVtekcwZmlWUWYxV29sQmRIK3NmTUNDOVBnRHdld25EYlFTQ3NC?= =?utf-8?B?Ym1ob1EycTIvY1k3RHppNXNIMmlXd3NhT0JQNnA3ZnVKTFBVcHhVOHZkeGdm?= =?utf-8?B?K2h3M3RSRW44K3UwQTNyWjBLZVIwNG9ZL2VuUlUxSTNnZGljTGd5STRJQUI0?= =?utf-8?B?QStaYWNYQktMMCtpbS9nckQvREpsd09GaDlYWFZMcFQ3SDZ5SlpyZ0VmOWJ5?= =?utf-8?B?Q1FRcXE0TFNjNysxRVVOdkM3b3E1UTFadGNJRFFqcjE3aktGbWNkWk1GbnlJ?= =?utf-8?B?aFZ2SW42SXI0UVRnZ1F1VTFKYTRLQkxxSFNWZG9aYXltY2FObTBjNDlrUjZo?= =?utf-8?B?RUtpWHZXWWtOVkNmR1B0c2NlWVFpVVIxUWJENXlIbkdmMWN4b3lBendRdno0?= =?utf-8?B?b2VQREZhTGsvRmlzNHBDeWlVTnhnPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(1800799024)(36860700013)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2026 12:53:34.6390 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fed8c37d-ceb0-4e75-c693-08de5a7e6b5d X-MS-Exchange-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: DS3PEPF0000C37B.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS2PR12MB9712 On 23/01/2026 12:37, Jan Beulich wrote: > On 23.01.2026 11:56, Orzel, Michal wrote: >> On 22/01/2026 11:01, Jan Beulich wrote: >>> On 22.01.2026 10:49, Jan Beulich wrote: >>>> On 21.01.2026 16:47, Alejandro Vallejo wrote: >>>>> There's some assumptions as to which targets may be init-only. But >>>>> there's little reason to preclude libraries from being init-only. >>>>> >>>>> Signed-off-by: Alejandro Vallejo >>>>> Reviewed-by: Jan Beulich >>>> >>>> I can't tell (yet) what it is, but as per CI something's clearly wrong with this >>>> change. Both xilinx-smoke-dom0less-arm64-* and qemu-smoke-dom0*-debug* fail with >>>> it in place. qemu-smoke-dom0-arm64-gcc (no "debug") was fine, suggesting it may >>>> be an early assertion triggering. >>> >>> Or an early UBSAN failure. I think ... >> I did a test and it looks like the problem is division by zero in >> generic_muldiv64. At this point, time is not yet initialized on Arm, so cpu_khz >> is 0 in ticks_to_ns. > > And division by 0 is otherwise benign on Arm64? (On x86 it raises an exception > and hence would be a problem also without UBSAN.) >From the ARM ARM spec: "A division by zero results in a zero being written to the destination register, without any indication that the division by zero occurred." ~Michal From xen-devel-bounces@lists.xenproject.org Fri Jan 23 14:06:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 14:06:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212296.1523523 (Exim 4.92) (envelope-from ) id 1vjHnJ-0007bH-IZ; Fri, 23 Jan 2026 14:05:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212296.1523523; Fri, 23 Jan 2026 14:05:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjHnJ-0007bA-Fo; Fri, 23 Jan 2026 14:05:49 +0000 Received: by outflank-mailman (input) for mailman id 1212296; Fri, 23 Jan 2026 14:05: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 1vjHnI-0007b4-FS for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 14:05:48 +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 9d30e8f7-f864-11f0-b15e-2bf370ae4941; Fri, 23 Jan 2026 15:05:46 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-47ee301a06aso25989655e9.0 for ; Fri, 23 Jan 2026 06:05:46 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804d84588fsm60601255e9.2.2026.01.23.06.05.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Jan 2026 06:05:45 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9d30e8f7-f864-11f0-b15e-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769177146; x=1769781946; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Fwj9MUYMGKw0NGDt0d9VtkRjNnHxjHBhx+jYG4Q/qHc=; b=KjV2RLV9dDwLMR1pwR1yDl5jiKV8HVsMq0nS2fDTja9GkAXwc6+fPQTqVDK3wQeTPJ CeRIGCx71dQ6g+UnkKs+Iuj4jAjkP65lp4bx1zIfwTrEQUIyclU9SbYZRvDt6syyHTcF LcpaO1oO3vA0Dm13D64yp31jkb05Y1GFfy1cD969VaGvX7EQHtw9JPK2ZTT68LvAYQn+ QAlqhrQsVn/W0zK7HSm5V1A95G1Nf7FSyMKsoGXxxzQDyQF0ps4+ZluFKIbuD9LnvO1V oFt16Y05Z2ayMGxzWE5u0CkICWqMGVqDRnrIMOMFLpPS6h7fHPa+GKyNahO5H/WR0OR2 2upQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769177146; x=1769781946; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Fwj9MUYMGKw0NGDt0d9VtkRjNnHxjHBhx+jYG4Q/qHc=; b=h2AdNCFK2DFbXDfy2CIedRh+NM4ssauvYaRz61h8H01YQQaBlnBDY+bJ7H9vgQSrHa nxMHPxdvbXutWGPvTBMKXzAjyUk1qE/BRGeQkcoyVnDoH3/XD7pvy2vyLi6KTg87IOEM t9ENxuWz+rFpZZCvPbkN1+NKVBpGfZoHjgCBAXT8tJh22Y0m0LdzMHbr3VlzV6JaxURt hzR/mFlGHVx/KGzNeIf8dHEsE02ntLq4JJzLr6wK2/l/+aXV6Ht7X7zCM6WcQ+h++OLT ovuaLxccel/xbs3gUt/L4dei2DBmEY5CQLDDXYwlUbuxa/MK1jkaxv4nTjibcgHv/9mb j84g== X-Forwarded-Encrypted: i=1; AJvYcCXfUsyNuMnJQqtaP4BvCf3RHlVrCYHV32V88ipLpAg9xeiDpWYUzFo6FbIVon9BB0sT6by666DDOHU=@lists.xenproject.org X-Gm-Message-State: AOJu0YzVFdWoctLv11Km1S4knB8i7dcCtrj6aYQDx1wdZ1tofTfg/NDe jFZVpqjyESTfss8KVtU+xqMkD+a/j8xaeTm4dD6RWJNhnl+oy20D6saK4IN/f8VRCw== X-Gm-Gg: AZuq6aJ4LI+l4V2yM4+zeQYOcWFzKQoFxWtolP79os6tInbSuxLTb7va9x31paLPIda V+IMhdTUgWuphWOYJNUlL9EMLPxUR4rlXUT5cTALV4L8nCSvfC/JXVGDzpEyw/6bJsqbi63vgjE 0uUnUDiWPuCfaFPXoBQTWDXEYoI88X2N7UZ0Xu2WJ9wIkbI/Nid2MAh0aK1Nwt7t8t7RALBRvaS wwBnDhHXWkIyoaO+Rx9DdewqqZcu4llBwwf1D0Th98FaDWwBdFvEnB2x/rrvJwuD9SuKrTvm8Em GcTsEGg0FRYQLK2gjk3zW3TMWLJDrPaP3a6Y98BG3vLqstSwjvfaNNc8f4IJW2Nuk8dWIgYMGUu RWiS8+++KZcTSM8uGxEnbvH8RnOHJLq/gLCNuuVkdRe7llZLWGywTH0I/8YuO/GLEOFosqpHwkX tzhy1Rz3AGu4SqKvmAbQbpz4a+MNPNR1zHU9DTq5saMza+kc7vcGmyTy3UAQYKEl+6lz1HsjBLz v8= X-Received: by 2002:a05:600c:5494:b0:480:1e9e:f9d with SMTP id 5b1f17b1804b1-4804c94810fmr48857995e9.8.1769177146162; Fri, 23 Jan 2026 06:05:46 -0800 (PST) Message-ID: Date: Fri, 23 Jan 2026 15:05:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/4] x86: Drop cross-vendor support To: Alejandro Vallejo Cc: Oleksii Kurochko , Community Manager , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , Andrew Cooper , xen-devel@lists.xenproject.org References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <3421e525-fb04-4306-9320-4fa359c2ee28@citrix.com> <26c416ea-1c4b-464a-bcb9-d34f0600eaac@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 23.01.2026 13:10, Alejandro Vallejo wrote: > On Thu Jan 22, 2026 at 7:16 PM CET, Teddy Astie wrote: >> Le 22/01/2026 à 18:44, Alejandro Vallejo a écrit : >>> On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote: >>>> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote: >>>>> Open question unrelated to the series: Does it make sense to conditionalise the >>>>> MSR handlers for non intercepted MSRs on HVM_FEP? >>>> >>>> I'm not quite sure what you're asking here. >>>> >>>> ~Andrew >>> >>> The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as far >>> as I can tell. The question I'm asking is whether there is another code path >>> that might invoke MSR handlers for non-intercepted MSRs. I can't see it, but >>> I'm not sure. >>> >>> If there isn't I'm considering (conditionally) getting rid of them. >>> >> >> I think you can enter this path by making the guest execute directly or >> indirectly a rdmsr in a emulated path (there are some cases like certain >> cases of real mode or maybe vm introspection). I don't think that FEP is >> the only way to do that. > > For the emulation path, I think HVM_FEP is the only means to trigger it, as > neither {rd,wr}msr access memory. VMI (as you mention) and nSVM (as Andrew did) > do make sense, but I don't see any others. I don't see how real mode could cause > anything (I'm fuzzy on VMX, but I _think_ instructions do execute, just in > a weird paging-on mode akin to v8086). Iirc there's still the situation where for PAE shadow code tries to emulate up to 4 insns in a row, in the hope to find the other half of a full PTE update. Jan From xen-devel-bounces@lists.xenproject.org Fri Jan 23 15:31:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 15:31:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212342.1523534 (Exim 4.92) (envelope-from ) id 1vjJ8B-0001Lj-Fv; Fri, 23 Jan 2026 15:31:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212342.1523534; Fri, 23 Jan 2026 15:31: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 1vjJ8B-0001Lc-DE; Fri, 23 Jan 2026 15:31:27 +0000 Received: by outflank-mailman (input) for mailman id 1212342; Fri, 23 Jan 2026 15:31:26 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjJ8A-0001LW-8X for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 15:31:26 +0000 Received: from mail186-9.suw21.mandrillapp.com (mail186-9.suw21.mandrillapp.com [198.2.186.9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 909a0011-f870-11f0-9ccf-f158ae23cfc8; Fri, 23 Jan 2026 16:31:20 +0100 (CET) Received: from pmta10.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail186-9.suw21.mandrillapp.com (Mailchimp) with ESMTP id 4dyMN65nD0zK5vgrm for ; Fri, 23 Jan 2026 15:31:18 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id cc70a094c3b4485b8f5b1f6e8f640562; Fri, 23 Jan 2026 15:31: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: 909a0011-f870-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1769182278; x=1769452278; bh=y8MWct1FnbcLHNIpjurdfj44N0ACIWyyIUFMtDNd+LI=; 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=Yo3Uqhpsij97j1GB1hsb7au0ygm+X7/MEjo7As2x0VCNXHIPtf17ErtS45Saz2KVy cWNVmFnMTb3wyvR2aW4RyE9vlZlyJ36GS+YsSwwLA+YODxHZMH1yuUlvP41kGFCGPQ eci5/BiF2JS7QFPG0TEsmCeb1rEkFuUyr84aSlFGImN6C6jsRyJcsm/p2g4F9G9p+u Pij0YS/p6bXIbdV67oqXjp1Ex5Ol7lL6gyhMOOa7ZnxMTkpIShrqc+KM4N/HUdOEyh vYJ7qqooRpgpQwEeKXlmXjAbbSzQ2PncEe/CLKAp3Hp/Ki3fz1pj9mcQrxYYUG6kjQ vSNhlL+iZ/AUQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1769182278; x=1769442778; i=julian.vetter@vates.tech; bh=y8MWct1FnbcLHNIpjurdfj44N0ACIWyyIUFMtDNd+LI=; 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=yf+nloaFISyYa8gpRBgiPm9EilAwnwAx85FyZRuDrLM6izTMv8d9iMw09BFOIZHEK eXiIOJXC2M7nfurs0TwMEmYNfTV2sZYWDAZAQtXglitaDtdUOl1yc3L6kAhvbA+OCU Zrs1aGJ1sG4MW5GQBIvpckCsBQq2WeY3xdUykqw+qWZcxqDCWB1H9IVpR5OHgoSJ+y 6YWaB1yftVW4PSDlj36uaXhbY99HzK3GI0p4hq4khhYdam07yD6APB9uyd5xKrbFTP y3cT5oJkieWcv5d3W3GfYqVuQk/mbHD5NEhkB3HRRNSjAi+qcRoJHyLHlZg2PNMLeV ODUbcbDEZnqMw== From: "Julian Vetter" Subject: =?utf-8?Q?Re:=20[PATCH]=20xen:=20Move=20NX=20handling=20to=20a=20dedicated=20place?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1769182277546 Message-Id: <09d59ee2-92bb-41de-ad77-6b6c6bc44d6d@vates.tech> To: "Jan Beulich" , "Andrew Cooper" Cc: "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Daniel P . Smith" , "=?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?=" , xen-devel@lists.xenproject.org References: <20260115151658.3725784-1-julian.vetter@vates.tech> <69b511db-654d-46b3-aca3-3f37f30d3473@citrix.com> <335949fc-059e-477c-9b2b-ddcd2f144300@citrix.com> <4a38c2ae-dc60-4fed-b30e-81a02b657e92@vates.tech> <92c02d2f-ccc5-42ce-ba0c-076fdc75e1fe@citrix.com> In-Reply-To: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.cc70a094c3b4485b8f5b1f6e8f640562?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260123:md Date: Fri, 23 Jan 2026 15:31:18 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/22/26 15:11, Jan Beulich wrote: > On 22.01.2026 14:57, Andrew Cooper wrote: >> On 22/01/2026 1:48 pm, Julian Vetter wrote: >>> (XEN) Early fatal page fault at e008:ffff82d0403b38e0 >>> (cr2=3D0000000001100202, ec=3D0009) >>> (XEN) ----[ Xen-4.22-unstable x86_64 debug=3Dy Not tainted ]---- >>> (XEN) CPU: 0 >>> (XEN) RIP: e008:[] memcmp+0x20/0x46 >>> (XEN) RFLAGS: 0000000000010002 CONTEXT: hypervisor >>> (XEN) rax: 0000000000000000 rbx: 0000000001100000 rcx: 000000000000= 0000 >>> (XEN) rdx: 0000000000000004 rsi: ffff82d0404a0d23 rdi: 000000000110= 0202 >>> (XEN) rbp: ffff82d040497d88 rsp: ffff82d040497d78 r8: 000000000000= 0016 >>> (XEN) r9: ffff82d04061a180 r10: ffff82d04061a188 r11: 000000000000= 0010 >>> (XEN) r12: 0000000001100000 r13: 0000000000000001 r14: ffff82d0404d= 2b80 >>> (XEN) r15: ffff82d040462750 cr0: 0000000080050033 cr4: 000000000000= 00a0 >>> (XEN) cr3: 00000000b5d0e000 cr2: 0000000001100202 >>> (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 000000000000= 0000 >>> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 >>> (XEN) Xen code around (memcmp+0x20/0x46): >>> (XEN) 0f 1f 84 00 00 00 00 00 <0f> b6 04 0f 44 0f b6 04 0e 44 29 c0 75 >>> 13 48 83 >>> (XEN) Xen stack trace from rsp=3Dffff82d040497d78: >>> (XEN) ffff82d040483f79 0000000000696630 ffff82d040497db0 ffff82d0404= 83fd2 >>> (XEN) 0000000000696630 ffff82d040200000 0000000000000001 ffff82d0404= 97ef8 >>> (XEN) ffff82d04047c4ac 0000000000000000 0000000000000000 00000000000= 00000 >>> (XEN) ffff82d04062c6d8 0000000000000000 0000000000000000 00000000000= 00000 >>> (XEN) 0000000000000000 0000000000000000 0000000000000000 00000000000= 00000 >>> (XEN) 0000000000000000 0000000000140000 0000000000000000 00000000000= 00001 >>> (XEN) 0000000000000000 0000000000000000 ffff82d040497f08 ffff82d0404= d2b80 >>> (XEN) 0000000000000000 0000000000000000 0000000000000000 00000000000= 00000 >>> (XEN) 0000000000000000 0000000000000000 0000000000000000 00000000000= 00000 >>> (XEN) 0000000000000000 0000000800000000 000000010000006e 00000000000= 00003 >>> (XEN) 00000000000002f8 0000000000000000 0000000000000000 00000000000= 00000 >>> (XEN) 0000000099f30ba0 0000000099feeda7 0000000000000000 ffff82d0404= 97fff >>> (XEN) 00000000b9cf3920 ffff82d0402043e8 0000000000000000 00000000000= 00000 >>> (XEN) 0000000000000000 0000000000000000 0000000000000000 00000000000= 00000 >>> (XEN) 0000000000000000 0000000000000000 0000000000000000 00000000000= 00000 >>> (XEN) 0000000000000000 0000000000000000 0000000000000000 00000000000= 00000 >>> (XEN) 0000000000000000 0000000000000000 0000000000000000 00000000000= 00000 >>> (XEN) 0000000000000000 0000000000000000 0000000000000000 00000000000= 00000 >>> (XEN) 0000000000000000 0000e01000000000 0000000000000000 00000000000= 00000 >>> (XEN) 00000000000000a0 0000000000000000 0000000000000000 00000000000= 00000 >>> (XEN) Xen call trace: >>> (XEN) [] R memcmp+0x20/0x46 >>> (XEN) [] S arch/x86/bzimage.c#bzimage_check+0x2e/0= x73 >>> (XEN) [] F bzimage_headroom+0x14/0xa5 >>> (XEN) [] F __start_xen+0x908/0x2452 >>> (XEN) [] F __high_start+0xb8/0xc0 >>> (XEN) >>> (XEN) Pagetable walk from 0000000001100202: >>> (XEN) L4[0x000] =3D 00000000b5c9d063 ffffffffffffffff >>> (XEN) >>> (XEN) **************************************** >>> (XEN) Panic on CPU 0: >>> (XEN) FATAL TRAP: vec 14, #PF[0009] IN INTERRUPT CONTEXT >>> (XEN) **************************************** >> >> Huh, that means we have a bug in the pagewalk rendering.=C2=A0 It should= n't >> give up like that. > > Is it perhaps too early for mfn_valid() to return "true" for the page tab= le > page in question? Yes, this is indeed the problem. Thank you Jan. The mfn_valid() doesn't work yet, because max_page is set afterwards in __start_xen. Here is the actual translation: (XEN) Xen call trace: (XEN) [] R memcmp+0x20/0x46 (XEN) [] S arch/x86/bzimage.c#bzimage_check+0x2e/0x73 (XEN) [] F bzimage_headroom+0x14/0xa5 (XEN) [] F __start_xen+0x908/0x2452 (XEN) [] F __high_start+0xb8/0xc0 (XEN) (XEN) Pagetable walk from 0000000001100202: (XEN) Using simple walk without mfn_valid (XEN) Early pagetable walk from 0000000001100202 (cr3=3D00000000b5d0e000): (XEN) L4[0x000] =3D 00000000b5c9d063 (XEN) L3[0x000] =3D 00000000b5c99063 (XEN) L2[0x008] =3D 80000000000001e3 (2MB) And I also found the actual issue with the code, and why it fails in the first place. Somewhere before early_init_{intel,amd}, there is bzimage_headroom(bootstrap_map_bm(&bi->mods[0]), bi->mods[0].size), and the 'bootstrap_map_bm()' maps the new page with __PAGE_HYPERVISOR_RO, which has PAGE_NX. So, not sure how to work around this. > > Jan > -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Fri Jan 23 15:46:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 15:46:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212359.1523544 (Exim 4.92) (envelope-from ) id 1vjJMT-00034g-LQ; Fri, 23 Jan 2026 15:46:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212359.1523544; Fri, 23 Jan 2026 15:46: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 1vjJMT-00034Z-Hx; Fri, 23 Jan 2026 15:46:13 +0000 Received: by outflank-mailman (input) for mailman id 1212359; Fri, 23 Jan 2026 15:46:12 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjJMS-00034R-Lb for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 15:46:12 +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 9dc0d134-f872-11f0-9ccf-f158ae23cfc8; Fri, 23 Jan 2026 16:46:01 +0100 (CET) Received: from MN2PR20CA0022.namprd20.prod.outlook.com (2603:10b6:208:e8::35) by CY8PR12MB7732.namprd12.prod.outlook.com (2603:10b6:930:87::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Fri, 23 Jan 2026 15:45:50 +0000 Received: from BL6PEPF0001AB77.namprd02.prod.outlook.com (2603:10b6:208:e8:cafe::43) by MN2PR20CA0022.outlook.office365.com (2603:10b6:208:e8::35) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.11 via Frontend Transport; Fri, 23 Jan 2026 15:45:50 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF0001AB77.mail.protection.outlook.com (10.167.242.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Fri, 23 Jan 2026 15:45:49 +0000 Received: from localhost (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Fri, 23 Jan 2026 09:45:47 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9dc0d134-f872-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qr5YHswiZpGDA5xBQzDN8ufrOpLLhqwLjQrZJCgFi+mMhCjWt+zmN5TEre3S4a936jYe1wPQ84nLZ/KLgZNIue5tpT70XmRkbQQ9hoYLLVFOnIJVsVPpwzIeUAgGCXnwhcQUTxKqcWefYi1I0SO0xGy5MDSswoDdm7mklqkDVBNE3HK8eS812ra0eeWnebIOHOtILN/xNfdBUQiefcoJoVG/9vvzPJ+AV47MRxwIyEjeqRMS10gDMciY8OTnOasTTl0C5j0rwQfQymlfbFmqSfT0UVRVCZtdU7tI2sMk2px9w/Q9zddgYKRghfht2IYiUdkxMPGJQ1nXOtbQfY8Viw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=E2LZgz7RViTFQaAZafDex9Ohmlv4WcCjsBoF8X5oCxc=; b=uCiUQye0QHdiPUGZT5PzS3ad2jwyzULm2++HBzgi8+x5y3L5l99EtVIewfTS6R8lc5UINZnIhTIz1dF53W8IIVzQsu+IJgwJ7kLqamhwx0FXOzeSyU6Whzsd1pWZLqwtYABJvLHb/Z2TzY1bh7vX+pwTPl/LACJGiIAtQgMyXZMpNW+Pbu4G2XQ3rQX4P7Uvx4cPxQ8/kZ9MAw2JS8B777RgrgpuEvD/qM1AKZUVjbpMMgotpHcAJGdX6IWTzCwwnoP/TWzTFTwOiJd1oeYC5dAc9VHyo/8Incs7HKpP54bYW6ZEbnTLj1RKHcdgQ3WB0qqLCjOCFwpPOewl7KDWWQ== 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=E2LZgz7RViTFQaAZafDex9Ohmlv4WcCjsBoF8X5oCxc=; b=s/IlRmSxivbU/i1jlCidWu3M0LCBxThtgpSEppB1jnuik2RxcpqeUe3AmvpRqKZDOOd/BFHe15sIS90K0zrdS5DwdYoU/EN0xN9uciVktZPzzVG6o/HYyPFKLTsTsOpWlblkPhZZg4zUagTpjU1IvaXvUy4v6WBXMCaF/j75Vtk= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 23 Jan 2026 16:45:45 +0100 Message-ID: CC: Oleksii Kurochko , Community Manager , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , Andrew Cooper , Subject: Re: [PATCH 0/4] x86: Drop cross-vendor support From: Alejandro Vallejo To: Jan Beulich X-Mailer: aerc 0.20.1 References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <3421e525-fb04-4306-9320-4fa359c2ee28@citrix.com> <26c416ea-1c4b-464a-bcb9-d34f0600eaac@vates.tech> 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: BL6PEPF0001AB77:EE_|CY8PR12MB7732:EE_ X-MS-Office365-Filtering-Correlation-Id: 565a83ff-46f3-46bc-68bf-08de5a967b82 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|376014|36860700013|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?dy9hck12TmdxemVGbGE2TjA4N052eEM4OUtoblc5K0dXRFpGbjZiQWFXNWxj?= =?utf-8?B?OUJIL2l2TDRKTkVOdjNySnYzNnJMTDEvTFNMc1hwVDJkSmd5QnBFRzZsR3U5?= =?utf-8?B?QTJ6cXVvUWFlYlhzY3RXeWJCbGdLY09zUXFRSWdRTHdlWGVIOE5wTVNSZHZD?= =?utf-8?B?cnAxbm81UGZEZmZDaUtaL2tHdjZIRjZUVkVWZEpBSElaV2V2Ukp4Nm51NXgr?= =?utf-8?B?QTNaMFFFVXJCNU1rNk91UWM5RzFBcWM2R0trdlBKbVVjcGc0cmhFZVZJdksv?= =?utf-8?B?bkYzUDA2a1hxWDlNL2VTNU1pSFBGVlh3a0FpNmNzSUkvMXBudTRmQVVCUGds?= =?utf-8?B?RENQZVJYSVgvL3U0VFpKcjlhMWlDZzNQa0g3RVRSRTN4NkZhZjJick5tUGhC?= =?utf-8?B?eG55S3BCV3Q3dlRPT0dvK1dhenJIUmlpbzVFZ3FiOVJJclVaMUNCM3NVUzJq?= =?utf-8?B?YUtCa1FzUEtGeDlxa0tLNUg3aE5kRlBZQ0JGMUZpQitoWWxPUXFRVkRIU2ZE?= =?utf-8?B?NjZCSCtmcWNQMytTYW14MkFUSFB2d3FJNlpGUjBYLzRGVHhwemZhM0NmRnpT?= =?utf-8?B?NEZMOTh3RlBlVDUrTGZzZ1h0MU9FeU5qeFlROEhoVEwrVyttR2hvVzk1b1Q1?= =?utf-8?B?bVhXd2dlRi92Ny9TRStoNkYvRXpTT1RuUWRNdVgwN3Y2bmRodWRhL3dBNFlK?= =?utf-8?B?NlpVeEZHRG8vcktxKzVpL211V3V0ZHI0Wno1QnZxTUY3R0wzZjVjd2p1WGxW?= =?utf-8?B?YUxJcHlOWUFUdmI5SG1Yd0REZ1BCU3Z1clZHSUdsY3huczRnQkdVdHoyZmsy?= =?utf-8?B?aFJ0R0FnZjFXdXlJYmRrRnBoOFR6RlB1bmxzLy8xbkJOUnlkQVNiZ1hEZk4y?= =?utf-8?B?S3VCbWFDRnlPdDhXaE1BYUlqSHdVNWFwRTBZdzlaUkRzMnlUZ09kaGVMQTFq?= =?utf-8?B?NHJPWGRodUxpOGVBRXIzOWQzUXdZbVJoV1dJaEpTU215dkdaRHZSKzIvYTZz?= =?utf-8?B?NDF0UmZsbzZKclZNYVd6S0tCM0hBbDE1akYxUkRZREdWMmduZTJFdWdsNXZK?= =?utf-8?B?eWdUajJ6N0tlcmp3Y3Jvazc2U29scmJoaXpnVzgxbWdETi9LUjhKbzRVKzMz?= =?utf-8?B?eDhUV0o0c1k4WS9NbXMzK3lIOThHUTFyMzExRExLTFBleUlPVVdvNWtRbk9u?= =?utf-8?B?b2QrZ3M3azNidVBoYjhOa3BWNjZvenJJVVNxNDVpZy94ZWM3a0wvRlFidElK?= =?utf-8?B?MnRhVTd0RGdOQUQ3MUJsekxuRWQ5aWlZeDNDWlEyK2lGMUx4NVdZQWJQaTZZ?= =?utf-8?B?bytqakhLazV4RlZxeGpHSnlWSmNuSDI5YjV1ZUI3eVI0V1hKSHh1OW9sRUFX?= =?utf-8?B?SlRKNzJFNmlITmRXazZMVHpPK0RNcWtadzhraE9rcmhDRloyMFU1TURTR1Yz?= =?utf-8?B?b0R3WGJWYlpRbGR1aWNPWHUzVGRqcWRmZHUxckdVbmNtK1g3cDY4QnZDWHFa?= =?utf-8?B?ckViYkRobmc0V3d0YUdBMDM2S0pMYW1vS0RwdzNSdFB2VFl2ckNXNC9OQkJW?= =?utf-8?B?ektNZ0RmWDc0Y2lpc0N4V0ZOUDZXQ2tVVWRtdWVQTHdxRzd5aU4yQmh2aVF3?= =?utf-8?B?U1pOVklrVkgvTGZNQksvYndheThWQUlqaW1ZUXduSVlsdXRBNHN5QnpRZDJh?= =?utf-8?B?TVpTWDhKMFNLRU1EN1QxVUZrZGFDZlZTTkJBOTBRZlkxeWFhK1J3Vmw5NkUx?= =?utf-8?B?ZFBuOGw1WU9BVkNqWndDTE9FbSs4SDNIbzdJdTJ3U3B0akl1Y1Bhb1ZvTk83?= =?utf-8?B?bVhpQzBYVlZZNGNEemhnWTUwM2pmQUp1WHY3ZFRUamVYYVRzTi9iNnZPOHdS?= =?utf-8?B?cGM0eS9STXROMVlaVC9idDlEa0hUQVVrcERIeTJ4VXBKTVlPR0MrZVU1Smt3?= =?utf-8?B?clJVNnp5KzFKek9qRlQ2YjZwenZtQSticGpWRDRtK3FnTWpHb0EvcUZiRDBu?= =?utf-8?B?TlU4cTRiQ1hud0xaMUs3b2NDbnN1TWtZaGdxeVFPVHFVNkNVdnBMS05iUmk4?= =?utf-8?B?bWcvRXNCNTNzSlBxLzhuZU5ucFpBbS9QdHJmaDFJOW5NbzhFTVk3SFpaaWlr?= =?utf-8?B?VkdaeThGdERtQS9VRHlLblBXSU40aG00Mmt1U0tCZmozbTY4eW9xaExnSTdB?= =?utf-8?B?Rms3K2diTzg1enY0Nm5UdzA1bTkrWmZ1MW92by9PQ0VxYitiWFRtUXhZR21E?= =?utf-8?B?WXBLeFVrcVZmSFBMeHVxS1ZmUEJBPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(36860700013)(1800799024);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2026 15:45:49.6487 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 565a83ff-46f3-46bc-68bf-08de5a967b82 X-MS-Exchange-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: BL6PEPF0001AB77.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7732 On Fri Jan 23, 2026 at 3:05 PM CET, Jan Beulich wrote: > On 23.01.2026 13:10, Alejandro Vallejo wrote: >> On Thu Jan 22, 2026 at 7:16 PM CET, Teddy Astie wrote: >>> Le 22/01/2026 =C3=A0 18:44, Alejandro Vallejo a =C3=A9crit=C2=A0: >>>> On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote: >>>>> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote: >>>>>> Open question unrelated to the series: Does it make sense to conditi= onalise the >>>>>> MSR handlers for non intercepted MSRs on HVM_FEP? >>>>> >>>>> I'm not quite sure what you're asking here. >>>>> >>>>> ~Andrew >>>> >>>> The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP= as far >>>> as I can tell. The question I'm asking is whether there is another cod= e path >>>> that might invoke MSR handlers for non-intercepted MSRs. I can't see i= t, but >>>> I'm not sure. >>>> >>>> If there isn't I'm considering (conditionally) getting rid of them. >>>> >>> >>> I think you can enter this path by making the guest execute directly or= =20 >>> indirectly a rdmsr in a emulated path (there are some cases like certai= n=20 >>> cases of real mode or maybe vm introspection). I don't think that FEP i= s=20 >>> the only way to do that. >>=20 >> For the emulation path, I think HVM_FEP is the only means to trigger it,= as >> neither {rd,wr}msr access memory. VMI (as you mention) and nSVM (as Andr= ew did) >> do make sense, but I don't see any others. I don't see how real mode cou= ld cause >> anything (I'm fuzzy on VMX, but I _think_ instructions do execute, just = in >> a weird paging-on mode akin to v8086). > > Iirc there's still the situation where for PAE shadow code tries to emula= te up > to 4 insns in a row, in the hope to find the other half of a full PTE upd= ate. > > Jan That's a rather obscure optimisation, thanks for bringing it up. multi.c:sh_page_fault() is rather... opaque to just look at it and expect t= o find anything. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Fri Jan 23 16:29:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 16:29:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212388.1523555 (Exim 4.92) (envelope-from ) id 1vjK2E-0000Wl-O2; Fri, 23 Jan 2026 16:29:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212388.1523555; Fri, 23 Jan 2026 16:29:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjK2E-0000We-Jq; Fri, 23 Jan 2026 16:29:22 +0000 Received: by outflank-mailman (input) for mailman id 1212388; Fri, 23 Jan 2026 16:29:21 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjK2C-0000WW-RG for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 16:29:20 +0000 Received: from DM1PR04CU001.outbound.protection.outlook.com (mail-centralusazlp170100005.outbound.protection.outlook.com [2a01:111:f403:c111::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id aa5613ee-f878-11f0-b15e-2bf370ae4941; Fri, 23 Jan 2026 17:29:19 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BN9PR03MB6073.namprd03.prod.outlook.com (2603:10b6:408:136::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Fri, 23 Jan 2026 16:29:16 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Fri, 23 Jan 2026 16:29:16 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: aa5613ee-f878-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jtkr/L1ItME57x83BnfaXuziLuT8IJtnY/JD6NvEsFuM9fm/IOb/wwAMl5RxXY50g9V7yEQv4EEtTy1fvG23fo49NHcOz/zul6AP+tHIY+DnHSYaQUSQT1HFMf832VHn1CdexFFROqq2IR8Od4QHNeM5CATZNGM/l8tHaamT15AZlxn8++d2X55qC5hmGgyT9c0C2Z2BqyTFUmNjuBFRm6/LF2H4WDW1211C8c0HqePsVmMWdaghl8yE2Lv36a4wLXzIDpi8eI7zR1GbH6YS7uCJvkYFoKRVXUWyL+m+AyCqUjK2xzFpDUYhzwvN6zFHUcTu3jPYdrFwqH7J6zZ/+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=LEOtKeBGlUPLIMFURNRfGSxbS9QzFPGX1/pq2kd9dcE=; b=IVzP61+F1HxOxpWd08i08kuKZS3vniBzQ0tce6W7yUWj0bFCS2mmTgC0kg4mAtKWUv3Pl5R49jWmZkY/o36/hzWYoT+I3dD/hXKFD3ABvj2XB/9WhB/E7vtRlAZJKhC8B0EI1D2MsJT3FShEpX1RF/OF4r5sxzTlKbZDYDAMWq9ux+K9n02dQ/IjfVydGkxQWxy8Wm3NNb/aTQAn5wNMTKuvGPmVvt/x33sR6WDQ1YCE+KUmAy15G+jtL0hsnccgs7F85gA6ziwth4wOqWsJvFovvfFLYYRpbLrBh1bpMFVMvrJ3A949tgYq6oZ36qjItCl7VHhziCOnx/RlNtbg4w== 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=LEOtKeBGlUPLIMFURNRfGSxbS9QzFPGX1/pq2kd9dcE=; b=MPQw/Nv/eOrPKKIDkJ4zkQfa6Y7e1GKo7QlQkHZqZH4PQO/N90DNKQCCEgE0ghTJ0Mqzthit0sBaDAHPVpf+Lt1p3i4gwgBmdLhqo/2qjNTmKdkhcwXGoh669RNZcWINooWofG4wtGVmKwWqSfLpkt4EAGktesOG/exXS/ohBTU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Fri, 23 Jan 2026 16:29:12 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Oleksii Kurochko , Community Manager , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH 1/4] x86: Reject CPU policies with vendors other than the host's To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <20260122164943.20691-2-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260122164943.20691-2-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO3P123CA0031.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:388::10) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BN9PR03MB6073:EE_ X-MS-Office365-Filtering-Correlation-Id: 856dfb93-1f76-4b00-cc02-08de5a9c8ce7 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?UkVqU0dqbHNKZ1cvZ01BRzkwdzcyTlRzTm1sRlBGS3ZaMlNSVkdUNzNNZHY4?= =?utf-8?B?R01sZ2hpaFFZci8zODFwQXdDbUZvYzREQTlNSGJPQTF6ZlRRUjFnckYrdndL?= =?utf-8?B?ZlVKZys3Z1JyMk5UM3RvZEdtVGRvNzJIaHh4dmRWY2Y5RUpUWUF1NElLYmlR?= =?utf-8?B?N3hlSFVnT0t4cGNmZmk4ZTVuTDBDR0c1TDZiVHZKckM3Qk5aQkw2ZkVobDJ4?= =?utf-8?B?bVNvWFFOYjJVaEFJbDhWeTR6SUdmMlhyeG9IVEE4RzdMNzJQSldQOVM4M0dx?= =?utf-8?B?M0FZWmZHRWFSdzNLTVBHdndDZFByZzk1cklzRFZnM01JV2hxaC8vaXlsVzNP?= =?utf-8?B?Y3F5ck44bG5UQXI4dDFrSThwMWMzK3FvZXY1MEVLT1lTYytPVlFPWkh3T25n?= =?utf-8?B?WW9QZFd0VnNKcVpsY1ZFNDB6ZEo0K1ZCU2FKZU56OW1Ba0Vwbm9xeG9aN2Qr?= =?utf-8?B?OU9SL1NQK2c1dy9pK3hVbm5IbWV4cU5YQ3g2TWNkWUQreUI3MTUybnAvZS90?= =?utf-8?B?WExpTFFQTzBuKzVpd3RKVWlKVXZ6eVc3SEhpMXR0UWkzUWNsa2szVXgraW02?= =?utf-8?B?L056UE44V2RRejdHRWpTU2V2ZWNMODZONUpYK0t3d21JKzR6ZzVHb0QwajdH?= =?utf-8?B?azRndkI0NWlmeXRmbWx5aytxL0p5QWFPRTk3eE1EdFlYb1FkeFRsQjlqRkVD?= =?utf-8?B?bWV0WmtNTUpPQXRuWnJQRkpKVkNSZU9Wbkh1bDYwUDBSd0E3b1YzRk1xeHVD?= =?utf-8?B?MGVqWG92Q1p2S2RDdW9LaVNLdmp2TnF0dUZBTmthdTRpcjNyZ0crdlZyRWh0?= =?utf-8?B?VXdDbnhETU91TTJGaFdrZnVna1U3R0Z0WFpmY1lUNUNMbURHUnR5Y1JsTjgv?= =?utf-8?B?cWhYM01pRGFMajhMMmVUVHJzVnhMdTFWNzV1WWpacHBraHlrcVN4cGZWY08v?= =?utf-8?B?aEVvUWxPT2xRRldycnpKNnZoaWc3cFIwTGhtS01YUkV3Vkt1T2NJSkxSRzda?= =?utf-8?B?QnlBUlh6a3JrOTVHTk5pb0JyTWJMS0dhN1VRN3FhTEU0ayt6NERBT3g3dDIv?= =?utf-8?B?TUJNNjR0KzJoK0lUZGYxSnlHRnZPcXY4VDZTMjByOUNFaWlFV1BkV01SWEEx?= =?utf-8?B?ZmFQdnI3dHlmMzQ0UjkvYzhSZklpemlmZGt4UmZhdHByamk3UWdYdEV3ZWxU?= =?utf-8?B?NGNvQktNTkhZM0pVcnNXa204anhaZGJHeGNVUDlIOUVCQ1FjVUJXejJ4T3lp?= =?utf-8?B?aUhTZW5kcnIrakdBMnlqaFF3OERxcDlJSURSdmF5SnI3bUhna0JHVVdlYnlD?= =?utf-8?B?d0IvWHRQcUF2Z21lQmZsTW1XVmdDZlR0ODVGc1ZLTHJsWGdheThVNmdzMWZS?= =?utf-8?B?bGEzMG5ORkZRTFloQmdaOWY0V3E0aVZJdzhvNCt5L0xwNjd5SUU1RDJQNHMz?= =?utf-8?B?WjgybHFiSmJrN20xb1ltTmE4elJ1UlNjUUxVQ0pTWXRIY3hpZ1dXbDhxVS9Z?= =?utf-8?B?TW9tbnhDbzc4aWRRMndmNTM3MXlGMUlmYkU5QWh6RGViTWF6Wk1FUFJxVTcv?= =?utf-8?B?aWp1VlZ6RnVsSlNjYmFPUXlCQnl1cHk5MmZmQUx0NDNJWjlveklpaDYzRXBq?= =?utf-8?B?MU9TRUdDQmx1WlJqbmRvM3JUNndlVldFMGJVQmFienhwbVBmdmVrNVZDaDVm?= =?utf-8?B?YXB5U2N0UHBUZkhnbmdIb0ZyWDJJOUVIc3F1cDl2aVc2ZmZvNVVZaTNjSlY2?= =?utf-8?B?S3gyMEVrSjloakM4eU1ZblROcm1lU09wMzhzeDlUTVQwcjhYSDRuc2tmdVlU?= =?utf-8?B?bk1Mb2JhU3dESE1QU2JGVnlPRmYwNkpPcXlmYUpicTdGeCtMeVBkS2k2ZTAr?= =?utf-8?B?VUhhM2ZnY08xQTIxMy9ObVBFTGFMalRqQ1F4NjJPZW1qOGV1YnFxVlpnNFRi?= =?utf-8?B?eThtM2NCNjZvU2hnU1ZhejlPeXZVakVuTW9ZZFkyMEl2Z3lCWjgxcnNleU1o?= =?utf-8?B?a2tUODBydmpWYVc0K1ZCNlBlUXFuYkxZVVI2YW1rNXhianlNb2RtZzUzTGxU?= =?utf-8?Q?PejHFl?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TVlHOTlTYytZSWFmU1pNcmlnVTNsTVJ4NlpId2ttSjdEbjczZzQ2V3VxeWxz?= =?utf-8?B?ZWozTFYzWDBBS0FXRitwbHdlMGwwVTZBSUZHSXowcWhxb3FJQThTalI2VGli?= =?utf-8?B?UGpNc0VJelpRTXlIYVIzWVhuTmh0R0N3dmxtTU5zSFdHK09TRm9GekF2YzR0?= =?utf-8?B?Q2NNT2EzaU8wR3JXNXhyc2NqUklTQ051UjFWWXZlSGhYemNvREZIeWNlWk15?= =?utf-8?B?TXhHV2tLSjFxa2RpMEpISHlZQU9ZREl6KzByMEpncThQRUJwME53dHR4UFBi?= =?utf-8?B?U2ZNclNpRC9aazA3YXgyUWY1azNub3FJTTdrZXQ1YmVERnpKanc2OURVVlpQ?= =?utf-8?B?OWxhdmszUis2QUlNZmVJS016RTJlQ0laUVp4VWtPajAzMzlrWTB3RGc4bHY5?= =?utf-8?B?ekZoSmRwTk03aXRnSHo2eWlYRGJQUlRIN1hCSTZoNFRKTFFyOGxRVGFDcVBQ?= =?utf-8?B?ME1OUS9tV1BRTmlHbmJoNUhaU2NjWDZmQkxYbHJoMGR2czNRS2lWbDF5Wk9n?= =?utf-8?B?d1hFTVVUQytJRHh4RldFWE9SUmoyZWpUR2JpWHBSWDFSQkRJOUt1ZDRoWEY3?= =?utf-8?B?NXdSQmp4Uk1QWVNRcDJQRnhad3dnc1htcmt3ZysxSW5mVGVQQTZIYU9hREVp?= =?utf-8?B?QnQxdnRKWW84b1pNT1NVb0NGR0hMbGN5c3grMXA5eTZtU2xPZzhQd29pYVJY?= =?utf-8?B?TFFKNkN0VytXamtjdmJZVmJ5VU9qYmtMSm1ZOXVZaDRXcGc3VE5NdnQxcmRm?= =?utf-8?B?d2t0OTBvbkE1TVVPS3ZiQ3lCT0h0OU14SXVIaktRKzNQY29GVVh6SUhhZG4z?= =?utf-8?B?T3NoNHcwRlQxR24yTERyMmlVZ3pFcXNCcUE5K1dFZk1YellNckJOalV5Znp6?= =?utf-8?B?MkxZdkRYYm5NanIwdVRsV0NMcE4wREE1MTY4TmxXUU9Xdmxva0xPOXN3dTRX?= =?utf-8?B?VUNsWnlsK2ZIN0M2NGV0ajJnWTBiSWVnSWE2dkkwN01tZGlIVVNqbHFkV3JS?= =?utf-8?B?cS9DdDQ3bURCY1pnOGVpcWpHMU9henVGMFpJZlJPL2JwS0w1Vmc2NlRoZlI5?= =?utf-8?B?Skd1SW1EdVdJMS92SVRCbnBGeXEwakhYd1ZmZkFIZ0FlSlVNNUVYcEpLaTcy?= =?utf-8?B?dnFiUWltZTI5MVdxWjlKOEJ1d1JBRnZXcmdNanJhSjRxUkxmZnljbGIwSHNp?= =?utf-8?B?c3pMWXMvT0dmMHA2QnVON2pkeXl6QnFUQXBYUFRwUmJBekwrOXZ6NUErNXZj?= =?utf-8?B?cXQ4R2tVcnZPY3B0U04wY3gvTSt6QTkzVDg5ZEVtVnYvUFpGZGkvMEtFdDF5?= =?utf-8?B?UngySDBicFlURkZzR2N5ZzV4QXZLOGdBUFBNUVdTTk5yQ04xRzU2N1FsNmNG?= =?utf-8?B?N2k1V3B4SmNFWkRONHZEUlVFL2d1NU1tSmhTUHo3M1NOd0FqVTJsMERuKzFv?= =?utf-8?B?dDdkK0F0TTN5SmFWVlJ4ZGtOWFBxY1RPeUJobTBGTm04alRhcWp0WThLQWlI?= =?utf-8?B?MVo2RjM1MllacFpRYTkzRmxjeFplYk0zdzJkVy94NW4ydTd2QytBTkZQV0lz?= =?utf-8?B?WU5Fem13SWVxZ0NYczIyMTJyU3gzVDhKTVFLYUwya0o5VGo4RHRtV294UGZD?= =?utf-8?B?WVR1dmMyTGZDd2MyQlNxWGNWVWNEYUNjeVlUeit0T3RPMDhDMWUxNGkyZmNi?= =?utf-8?B?OWtFVmFpdDFMMmRndG14bzBnWS9xbzZ1eHp6ZlcyaVU2OFRrSEhGVnZ1Qk1q?= =?utf-8?B?NkJySXhBQzRzRGZ2T0gvQUEveFY0U3hEbUpXMlpBcWZ2NytJTlNXbXBPZXFp?= =?utf-8?B?eHVsTUpGVDByNkxMY3V5S2VvVG5HOGNtTE5HWFRyd0ZmNzE2Q0l0aEQzVzV5?= =?utf-8?B?cUNqNzVjdWpLZlJ5YkhDazBINkx0cTNOdURvQkcwV21hc2FOQVZhMnd3cEw1?= =?utf-8?B?ZzdwenNxM3c3S3VLZmVob1FPaEJmT0tjRjBrMG1HVEFibU83TDZPM2NXcThw?= =?utf-8?B?WXN2RGI0VFVMeHBmeDhkL1FXWnc5dHlnaDd3bVdQN0VaUmgrbDJHVjk5RGFV?= =?utf-8?B?YSt4QTZKMjFoSXFkTHByZHBpS3N6cE9rbndQRWs2d1l2Y1EwUnd1ZjRhdkpi?= =?utf-8?B?SEpOaVNaUGl0WXB3UWxhTVkvRTZvNVFVYnYwOW5vQmNCV1hhVjRRZ2dUUi9M?= =?utf-8?B?bFBLY3FpR3QyS0swT3VPdHVUajNLUVdpNUJ2KzlRUU1SRjB0RU1MQXFPbGd1?= =?utf-8?B?MVQ1SUdwVTAwb1dHUktyb08wdm9yd3JMczJBSm12c3dUTzJNR2s4ZlpJSW8z?= =?utf-8?B?NnZpazFMRjhyaGdtZnkrQkdhOFR4eWVWNjF4ZW1yaG00cU5Oeml2Y3hHWXlR?= =?utf-8?Q?MGmryDtQkE4ypzu8=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 856dfb93-1f76-4b00-cc02-08de5a9c8ce7 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2026 16:29:16.0225 (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: g1IeYuD9HgmdtouWuYtSkBEbz12ltGRWOJBZ5sBy1wjW4l9HqBQ+VeDK2vbVBl/YCoX5wpCttnsyDMGHvBgRO+6P/WNKAIc37xvDIskf6Bc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR03MB6073 On 22/01/2026 4:49 pm, Alejandro Vallejo wrote: > diff --git a/CHANGELOG.md b/CHANGELOG.md > index 18f3d10f20..eae2f961c7 100644 > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -22,6 +22,10 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) > - Xenoprofile support. Oprofile themselves removed support for Xen in 2014 > prior to the version 1.0 release, and there has been no development since > before then in Xen. > + - Cross-vendor support. Refuse to start domains whose CPU vendor differs > + from the host so that security mitigations stay consistent. Cross-vendor > + setups have been unreliable and not practical since 2017 with the advent of > + speculation security. This is going to want expanding upon, but there's a subtle change in patch 4 needing addressing first. > diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c > index f033d22785..4c0c5386ea 100644 > --- a/xen/lib/x86/policy.c > +++ b/xen/lib/x86/policy.c > @@ -15,7 +15,8 @@ int x86_cpu_policies_are_compatible(const struct cpu_policy *host, > #define FAIL_MSR(m) \ > do { e.msr = (m); goto out; } while ( 0 ) > > - if ( guest->basic.max_leaf > host->basic.max_leaf ) > + if ( (guest->basic.max_leaf > host->basic.max_leaf) || > + (guest->x86_vendor != host->x86_vendor) ) > FAIL_CPUID(0, NA);     if ( guest->x86_vendor     != host->x86_vendor ||          guest->basic.max_leaf >  host->basic.max_leaf ) please.  This function is going to get much much longer when we're done with it, and I'd like to try and keep the checks in the right cognitive order. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jan 23 18:09:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 18:09:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212449.1523564 (Exim 4.92) (envelope-from ) id 1vjLaV-00042U-Km; Fri, 23 Jan 2026 18:08:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212449.1523564; Fri, 23 Jan 2026 18: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 1vjLaV-00042N-Hu; Fri, 23 Jan 2026 18:08:51 +0000 Received: by outflank-mailman (input) for mailman id 1212449; Fri, 23 Jan 2026 18: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 1vjLaV-00042H-3O for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 18:08:51 +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 90b8318a-f886-11f0-b15e-2bf370ae4941; Fri, 23 Jan 2026 19:08:49 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BN9PR03MB5961.namprd03.prod.outlook.com (2603:10b6:408:132::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Fri, 23 Jan 2026 18:08:46 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Fri, 23 Jan 2026 18:08: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: 90b8318a-f886-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=G5uNOKRlpL1EkA0PUXWt/94jzcOJ3E0DqgIaHfjtHkUQJsriUjUIAKGPFCPyDxUWvTt3ydM12TEwnJdjCh4xwoU/XqSPza7i0B8bZO8S86vdfR+Ywj5wqgaBV9mJlH5I9VZVmmOpBF29b+8HNMsoOxouxTHew8NBIaLmsemj9w9bnIfIgDo2RuWn8l10eJAHbLmazMRWNuXw7Kyvbq/s6WenRnJMdvbQqv51CZWLSESuTSalJ+wZZoFuja7mgK8w08cbbkYtiTdOkdNzCsEnKhxm/dGz3ThuqYaJgE84O17P3kYYQ6WB1Bp+BZxNQFjX/6R/tPae/FVvMsD3a8lRaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=62NfDDEvfd1aVyeL4f97hlmw6DmXRzMdkbN/W+svQhY=; b=lIH4kUGbdykWdbvzv6x1FDUTRmY4ovOxHEXExSvnLRBJDMVruCc1OyZGGQ5UNTKCJDK4gitv8xCqcF3MjBHN8ng2Sh6Vz1pEV6YDSyctDfDt1ityfxjicmyB3e2uxTerXsQK9BxFA+8kAQ0iEF3JlDEtJHJMnKBBsJeufshEAt+8YU+m0NO4THRt5jU+s9LnVM/ZRjAE/xG6ejXD+7nQeQAGrPyTp1wmWK53j7Wqevnsj0vwF5evRa8586Xyu8f4bvc6SmMX/6yuwu5rXt46URGcmMRQNU80VzRnAMakMn05sGp2WeHbdw8K6b3cj+HEcDIg0XENQDMtjuGXvH0zMA== 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=62NfDDEvfd1aVyeL4f97hlmw6DmXRzMdkbN/W+svQhY=; b=If86Mp9nXZzWosBPeDDhC+m5ya/MjUV2hAvDvbkfrTWl4LGHOFtoBwki+BDX2tB3obPm9HDqqy22skf0zYGEnX7cnOzj29WdlJVxcuND1AveOPBBR8174elLCxP1Rd+o6Pdwa9+r7SAGglg/jEAY/748jSDSBrjIr37ong3x9qY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Fri, 23 Jan 2026 18:08:42 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk Subject: Re: [PATCH 4/4] x86/svm: Drop emulation of Intel's SYSENTER behaviour To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <20260122164943.20691-5-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260122164943.20691-5-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0116.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:c::32) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BN9PR03MB5961:EE_ X-MS-Office365-Filtering-Correlation-Id: ace5f243-a52a-4f0a-b1d5-08de5aaa7351 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?Wnl1NEx5WG1RZjloZkgxQVlrcC9ZMTJCZlFaNkE3M01XWjVWRmNrVVBmcWo1?= =?utf-8?B?ZnZzdWR4UWdtWmhTRHp2cDdlcjQ5cVAwdXZLanZUaUJqcWZpNnBQTXVJdm5r?= =?utf-8?B?YytVRTJRM0g0UUcydm0yVFFZNS93UzN3UjFwRGpRSUFMVVM4M2ZWQ1VCWExh?= =?utf-8?B?d1FnSlhHZXRMV3hHaDBTaTJxL1FxcXJxYWlUMDBMZm1zZnpVTE00eXg3Y2V6?= =?utf-8?B?YkhIUkJpL0ZEK1VKam0yTnNOMEdyWVRRZHhGSFNOVEpxdkhYQmpaWUxxOVZq?= =?utf-8?B?SDBGaHhENk80Q2lzUFp4LzNIM2Nad2JQR3VtOEdmU3J1RVZxdUphWjRBY21a?= =?utf-8?B?NVozVkVpS2Y5MDFvMjRjKzdzcmVYcGNPWENsUFZkRU1IQ1VwWnlxeC9mazR6?= =?utf-8?B?VFUwNkJBSFVGWTRBZXd1WC9LMmRrcUNFNVJ4cHUxcGVINVd2czdTQ1BFaVph?= =?utf-8?B?SFVOMVpoMXdBNkIxWTFlK1pnTjZNTk1lN1lHK2dPUUl1ZkYxcG9sVHgwUU9s?= =?utf-8?B?eVltWWNsdzJjWWVQQ0trdmNaRUJlM05QNmhwTzdIV0c4TDdMYVIrNW1BRGNZ?= =?utf-8?B?d1ZEbHJWTXhnQ2pCeFNmWHordU5BUGZ0b1p4bjM2Zm5WQitqY2gvdWZXT2FZ?= =?utf-8?B?WmkyTFhteWlzT1cxbkpyVEMrRzYydHlSdTlZUm9BTFZqUFZEbGVUN2RUYUlY?= =?utf-8?B?dE9id2NyUklMNkVWOTZmZ3pWV09oMFlyVXQyY1JoTkZrNTZudDVleVo3YXcx?= =?utf-8?B?NGtuaFQ3d3ZyUzE5OFk3RFcwbXZaY2svVjZaUWxzNFlUUkhjVDhwbERUNmt3?= =?utf-8?B?d2lWR1JEeDhwRFc5aXc3R0ovS2p3dU5OaEl2bFdWRGdvMnZQMG5EaUZvWWRQ?= =?utf-8?B?V0QzdG0vSWxRamt0K2J2am5SVXNlM3B6NVNOYzVjajQ4UXRiWW9nWlUvc1Qv?= =?utf-8?B?L3hlakdnUDJWdUE5OFo5WHJCVUsyL2V4U2hkaGcwRHhxTnlwcWYwS3c5YWJV?= =?utf-8?B?bE9MZnQxbDFFaFVDVlN4VS9Ga1lDbEVVT0ZDQm1CRjc4T3NnWEE0NE5KeXN2?= =?utf-8?B?VXNFaUUzSnYxWDJPei9UeWdmMmkwU3g1QlE0UzIxKzJKQ3B4dDhGdmkyWGRl?= =?utf-8?B?QkkyTzFTWVRVSWxSTHkrRVBuV3R2TVlZd3VyZ0dFd2hQVDVOdElFbG4xTUlw?= =?utf-8?B?ZUk4VWNEd2FYcGJFMGE0bFdxUU00cUY0RDRHWTJPNzBtQ0VMRlNXWkEwTHJr?= =?utf-8?B?Z25tM2VOSnB5VHJORUZvU3ZtOThEV2ZhbGhGVTByOW05YXFTUVpsU3Z5Uis1?= =?utf-8?B?SVBiNUJkenVmMFFoRENubDJoMEhqZ0l4QnpMTEF4SVJLVklEY0VFcEZnSzRO?= =?utf-8?B?WURnbDlCQitwWXd1NExoR0dETTN4VlBEbUZUSk1VaUZ1T0h2Q2ZMNEFOcEhI?= =?utf-8?B?RW1XUnhCUDh3dWpuOEluSXhQL3lSMEx2Wit5b1loT244MUtISU8wYy9yK2Iw?= =?utf-8?B?dVEwQkxMYmQzVkQvSjR2OStUOGVPMDQ1eXVOWWxjbWFPMk9OUmxJbFlvWTNB?= =?utf-8?B?Sk1FSDJJazFwUHpqYTFKaWd6djBsVnRYcTVpbE5JdWZUTDZwRFFlRWt6Z3c0?= =?utf-8?B?NS9XS0ZLRGVLNDBMZGNYMXhSbGtzcWlWazRNUDI0NTdFQ29tZnJOZDNDanND?= =?utf-8?B?bmdoWnAxdzJjeTFzZmd1Yy9BYlNycWlJb2kySUNlQVlnbHFqeUtXemJ4OFlo?= =?utf-8?B?Nm1WTnhFbjJYV3l5aGFhcWdrSGZBQjJRYlp0eWhNZXR5WnN2VjdyZktxV1Z6?= =?utf-8?B?UlBaZGppTlBRdEhWZ3hVc2c4a3BRelc5a2lPVEp4TXVPZTRSVzduNnlpdlBx?= =?utf-8?B?ZHlSdThZSXdBTUhUUldWTHo1OUo2VXdyR1lualdNbjNKVEhvVjM4cGtYam9N?= =?utf-8?B?Z09FdmZXSGJHNmlpODRuV1p5ZC9yWEtHT0NPMnFLaXJBK0Z2VzZGRURhS2Zv?= =?utf-8?B?dXc0bno1NzhIRzRKOFJkOVM1UlNIMU0vQ3hwTExnamtncnBLa0laYnAvZWlp?= =?utf-8?B?T2NSNHVCZ3NFVThXSndVWlpwNXQ2aXovZktHWGpCZGJ2SVhRWU5DUWJBTFk0?= =?utf-8?Q?dGrM=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YytxWDlLYmZicXpyM0U3OHJqV3QxRkJlR0NxTWFUejU0Uzc5UVFyZG0rYXlU?= =?utf-8?B?djJDcC9oMWg3WUxvOGxWOG5FUkZkVmxxK0hYemh4QzhFUlhMQVF0WktNL0Q1?= =?utf-8?B?QlNBWUhjLzBmL1dJTzYxenhqKzMrSmhtcU4wT1BYakxwbGhNWXQ2MnFyc3Jq?= =?utf-8?B?R3JLWGhPeWUzb0FIN0wrd05rcnJJK0RCdEhueG5mNjZNZ0hlNVo0SUdsTGRN?= =?utf-8?B?MjdJVVVlQzdmTzhPTTBRV2RyZ0RHZE01Z2xzeWFtYmYvUUhmL2dqNVVHMXly?= =?utf-8?B?Z1dvZHd5K0dHMUEza2hBQ0dSYlNRaHozdlVhYTAxUDZTTWdURktrTkgrdVFm?= =?utf-8?B?amdPSDd1MnpISlNHTjlzNUdGQ2FsVmlRSW5yanFoNnBjRW9kVytwYTl6WW56?= =?utf-8?B?Q09aa2VWamNaYmJJSUxkcGFIRmw5Vm9obDFMQTJKTFhmRkVjYWxVSjZONUYy?= =?utf-8?B?Z1YyeDhDdTE4eEgvNU5TQWU0SGZTdHVmR0hrYkZmc0VDRVdYQlZ1M000TmNh?= =?utf-8?B?VUZMMzNZRzh3VEM4YWFnN3UwWWRId2JzeTZVaXdKQ200bzFCS0sxY1BQSUwy?= =?utf-8?B?OE9QWlVxVDFPaXBhOHpMQ0dFQjhQdzg2UlRtblhmR0xub0JTcVVqKzdCWHBS?= =?utf-8?B?cU1ZeUhNQmIxcVMvTUZhMnNGOEoxbTl3OVFOZVR6NFhqWjEwZmgzYWh6dzRv?= =?utf-8?B?MG9iVGhGeUVKdWQvRGdteFV2Q3ZFY1pCTFRKcVZtaHdiNGIycldQdWdVZkVo?= =?utf-8?B?WlhTQjZCTzZXZ2h0YXdnUlZpb2hQd20vNTV3bURiS3FhVklmNitBd1phQmhM?= =?utf-8?B?aGM2ak42L2NQQ1VpRFV4dXB6aUxocmlLeW1XdFFwZ1dvOWtpR1NzaHlpVTcv?= =?utf-8?B?YU1xWWlWVnlJeGhBL1dCd21FZHNDSzRmQXFlZDZRZ1RNdmppTWx4bVpSQ3FR?= =?utf-8?B?RDNDcVJvRGhKaU5teDJDRnhnWm1QVkVrUHY5ZThFNkdOa2lDUVJPYWxPVXV4?= =?utf-8?B?NkUwOWR5NGdPZ01iTk1LZjlEeEZadGNHMjZvRVd2eHI3UXIwMjNwaDFsWFdn?= =?utf-8?B?YjBIdm0vYnZPV2psdFBUYnRaY0hTRll1SEVNMlJMRFBtZHg5aU5YMktuRklm?= =?utf-8?B?N2d1UWJJSmF4MEMxeEwwQk5Bd0NMVlNCUjFaS3dtK2pMT1FxeU10R3JnTms0?= =?utf-8?B?MWt1ZTEvSXNRZ1FIUkpMSW9VWk1tbmtaYjNIVmUrVkpjQUJaK0JjeTljRFAr?= =?utf-8?B?eU9nNnF6V2N4QUhxSmFMa1R3RGZIV3B3SHhlelFUaEFabUFMMmpEelIxTTRn?= =?utf-8?B?SUtQcy90QndYQ201dDk1L1hSUnk3RVZnbEtmZUpiZDNKYnZCMm9aSFdBTUZj?= =?utf-8?B?akdVbWI5WHgyMHJNV1g0ZmFNQlJRMG80bllXM29idE5vQmZuMkhTaFVQQ3Vk?= =?utf-8?B?b0sxTklzNm5velRkT3pKTVM0Qkx1Q3czVG5hbVdyKytmWkJrL2xzQTF3RWxr?= =?utf-8?B?RURxbmJpQnAxM2J0SzdDQnp5YVdlYUFyNnBWTWFwSW9weHJJbmxISE9kQ3ZJ?= =?utf-8?B?Skkwa0NpWnBSRUFmQXJZdkFFSitqbGFDVC9nT2EyWnkvVUthbllrNVdBVTQ4?= =?utf-8?B?dHE1VFYvN0ZRMG9kamdRR1o4UmZSV2x4ZXl0Q1BIclZwMkZqZXpOellzenFQ?= =?utf-8?B?VVF4ZTBKSzRHTks3WWF4RG56WVhvYUg4QjhJWGE3eVZrYlJTOVZaeEg5R3VS?= =?utf-8?B?YURZY3lTMnl6cm5WT3ZTWDM2YWxrWDBXbXRPSmN0YklXTEVKUEliUWdtajVO?= =?utf-8?B?SzYyR3IwcEhqeUh1Yk1OSHJhaWFZbWxQYllpc0QzMGZiMXN2MjkwU1pFcmow?= =?utf-8?B?V01SdUY0UWlkbC9QaVhzWVpWb0J0a0hnN0lEVmdXMzl0ckRpU3p6TGtiTVcx?= =?utf-8?B?bWNTSXFQcnY0eFVMVERVdTB1a3RrcFpRWGlNWWV4bk45dEpPeHJldzRRTVYx?= =?utf-8?B?bEN6U1hVSDBLNTE1LzRoTnRNSEJIVTVyOXZEcXdNNHQvc01YT2xFZk5uUXA0?= =?utf-8?B?d0hKTGMxTjRVUUF0Ny9tQnk4YXI2amZ4Z2RPWHVtdFVZWVNYZGtoZWJHZzRt?= =?utf-8?B?VmRTYlVVTU5NOXRUYmt1RDE0TWtLQTVYeUI1WEZBZk5sZUxFZWRVZ0luRktK?= =?utf-8?B?TVBCc2l6Uis0Uk5DUE0zeXQrSk0ra2VWV2xnZ1d3YU82TTZvSk53bERxeFZW?= =?utf-8?B?L1RzUG0yNzF3OUdTRHpkTnA0MVQxV1RPVWdLQzh4MzNVVkhEQlYyNERZQnM4?= =?utf-8?B?OERoNTl2R1FVK3lNQWxLYmp4aEJYcUs1alZPams5YXBiQmJJeDY1dz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ace5f243-a52a-4f0a-b1d5-08de5aaa7351 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2026 18:08:46.0727 (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: FlJBnvVOS+Tm1eiwjPF6rObdxtD5dCwSKUiElYBiMgetqlWIhrMzSjCWqnRAwHVpRddaberJ7sc21mb/C68AO+BNwt9JhUrninvdy/ixhGw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR03MB5961 On 22/01/2026 4:49 pm, Alejandro Vallejo wrote: > With cross-vendor support gone, it's no longer needed. > > Signed-off-by: Alejandro Vallejo You're not really dropping or altering the SYSENTER behaviour.  You're dropping the emulation of Intel's MSR behaviour on AMD systems. And this comes which a subtle change in behaviour that is relevant to point out. Notably, AMD prohibit the use of the SYSENTER and SYSEXIT instructions outside of Long mode, and they're behaviour for MSR_SEL_* still follows the 32bit model where the upper half is write-discard.  AMD CPUs really do only have 32 bits of storage for the 3 MSRs, and unlike Intel, did not extend it to 64 bits of storage to support Long Mode. Xen previously (and unconditionally, irrespective of same or cross vendor configuration) emulated Intel behaviour on AMD CPUs. I think this is even a latent bug; on hardware that supports vVM{LOAD,SAVE}, the intercept doesn't trigger anyway, and this whole emulation falls apart anyway. Something which is very much not obvious in the slightest is that the MSR Intercept bitmaps for VMs apply to the RDMSR/WRMSR instructions only, and not to implicit MSR accesses such as SWAPGS/LKGS/WR{FS,GS}BASE, etc. Anyway, I think it is necessary to note that VMs which were happening to store state in the high parts of the SEP MSRs will now lose this state.  It is an ABI change, but it's acceptable because there are almost certainly no VMs doing this, because it's not how real AMD CPUs behave. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jan 23 18:26:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 18:26:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212465.1523574 (Exim 4.92) (envelope-from ) id 1vjLrA-0006iu-0K; Fri, 23 Jan 2026 18:26:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212465.1523574; Fri, 23 Jan 2026 18:26:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjLr9-0006in-Tm; Fri, 23 Jan 2026 18:26:03 +0000 Received: by outflank-mailman (input) for mailman id 1212465; Fri, 23 Jan 2026 18:26: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 1vjLr8-0006ih-Il for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 18:26:02 +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 f63c2186-f888-11f0-9ccf-f158ae23cfc8; Fri, 23 Jan 2026 19:25:59 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CH0PR03MB5988.namprd03.prod.outlook.com (2603:10b6:610:e3::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Fri, 23 Jan 2026 18:25:54 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Fri, 23 Jan 2026 18:25: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: f63c2186-f888-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=s1H5l70A+M/ioRj0Bw45SyxwRx1BDm9okm689c9osNUWgs1hY+MKDPOAqO5dW5mGVAPToNo+y7fyqvYFiWeKRzMvsCkUL6CBYpV0b2sdKOL0nq8W8EZlp32KoSkkbmh0oVjkZ5Ekde+m1kISAg/otmnkUQM1m5TBmP3ephRtecDpeE/W/FawLwHzEgY+wIJlBpiNpK+6CUcpHnrAJyiUlqTa+hsWog+O0q0I29bZfINbRlENTTr87kpIs5spdYieuabhLkuCNj4yIhg2s9Qu/LLCM36f1sU+8l5xDcNoEDFtsZuH6Hm31A5rCo4DemyBZQqt9ww3QE3K7ekzv02IJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZLSEGJiWvqcs7gnsaOk3s6ZxapnLQNEoM2a+VgNoFf0=; b=NarvaF7wIFQD6hU86hcxe743/o9HhxHTb0Xg4Rq9fytvWFTHJfRQRkDTiROaQdu57zdlePXOZjSgQBw6MLQBjhXg8V5fblyMFVwDqSUs8d1xgm3BR/3TGa8G4v8+4C1ivEU2eQBjnQnvBRPPRmDu9ic+RaktbV/VihaPwUp8OFC7mAa6S43gsFhsmlj1qdavm1rxwG8mxKEDkCOufqGX+T77nMKVD+DZWZ9PD1WNzSQZ/xOc5Ir0+YVhx26FVMKHHGKCU+yKAbKtmYptBAOWOedASPlPM8v9Url81VhGxPBDMrU3AfxyVgAqyT5Z6r5YxJBjbLgDuzmXvGCBFFHIeQ== 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=ZLSEGJiWvqcs7gnsaOk3s6ZxapnLQNEoM2a+VgNoFf0=; b=tYXMpsTdswdSt+Axr+Vbw9JKtXWykJuOLNFQ+jCOWgHtyJK6tXhSDnOivQsLuG/VpvuGDMSbqy5EUcsT2fq4d5kuRwFTub1Ph61hLT7WJw9W/jMkGo7fFjCYNYJJvqouzpvcn2f9P6tFpthA8sr+RKcdIyofU1BsH48bb7fBt/E= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <4a883054-4b3d-4de4-9a56-8427ecfd623f@citrix.com> Date: Fri, 23 Jan 2026 18:25:50 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Oleksii Kurochko , Community Manager , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , xen-devel@lists.xenproject.org Subject: Re: [PATCH 0/4] x86: Drop cross-vendor support To: Alejandro Vallejo , Jan Beulich References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <3421e525-fb04-4306-9320-4fa359c2ee28@citrix.com> <26c416ea-1c4b-464a-bcb9-d34f0600eaac@vates.tech> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LNXP265CA0003.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5e::15) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CH0PR03MB5988:EE_ X-MS-Office365-Filtering-Correlation-Id: 8b870bae-8e42-4364-6ebf-08de5aacd801 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?WjI0Z3RhVjJoMHZhQTlmSkxIMkg5dGU4bnJ3Q01Ub3ZuTjB6VXZnNk01OEFo?= =?utf-8?B?ZVczYmt4TEZNVnZURmNlQk9QUThPS1lud01mcDBTckZkM1lEanFrMTFzM3gy?= =?utf-8?B?WlF5b3RWTVY4WEVCVzhFcXJPMUx2Z3ZsaUtnNnhTQUZWTGZCbWFiRGo5K0ZK?= =?utf-8?B?TGpsQWRReTQ5Q3p6OHVCSzI0cTQvNSt0OHZRZFNBajU2QWFyVWdYY0tXeUJL?= =?utf-8?B?NW1ZZ01pdGJ1WFlsbm52aDFSVlZjN1pkaHQzdDBsSFg4NEw3QW10eFlZSFpV?= =?utf-8?B?VG1SeFRrUllJM3pmRFNiUUpjRk5VVEdqMEdrNmdrMXNKQWp3amZmay9BekJh?= =?utf-8?B?ZVlTVnNlNVdUbVVWZjVFY2hUSFU1aTlaWmV0ZEZTVUhtNkwyRGxOTm1hTUF0?= =?utf-8?B?cXRDSXV6YU1HdWR2UUNQbUhlNk5XazQ3TEZxai9MZXBNQ1Zid0RzTVVGVjcx?= =?utf-8?B?SW9kMzFOekpZc3IxejZNa3lYL1NpdGF5dGZyaStLbWd6Z1Q2ci9LUGZLcGhH?= =?utf-8?B?N1V6djFhclVuN0RocXQ3amVSYXA3eVdsZ3A1RzhNdGxvTnJpZ1ErMzRBTDAv?= =?utf-8?B?SGJvZy9PMkZrOUZqemRUQzlYV3IraTFSQ0lLV0t4SWVwRWdYb0VOU09hajUv?= =?utf-8?B?OG9FNzU5NXI1TWgyUjZxOUZGWElnUFVsWmRDTW9HeTZMdjhFSFcvVWR1bzVY?= =?utf-8?B?Mmx4VU1CVnNtV2wwOFBIYTAxZk1wYmpldHNhOHVseGNyZ21wUmlCM2JOa3Jv?= =?utf-8?B?Vnp1NW5QSS9qSVFSWlRYUmlwQ3pXWE54eU16TnlQSWk3amFHRUplTjlFem1s?= =?utf-8?B?Z2pjMjIwVW9FT2pBVkNFNVNvUFVjNDJlakU2YUh3bldtanptVGEwbzNPT2Iw?= =?utf-8?B?aXdPbkUrRXdaRXVLeDIxRFdhTTU5SDJTbEM2RDlWTDlHVC9jOVpVeVlTMCsr?= =?utf-8?B?K1BNdUk5UHFzR1RldFVabmhWQnRFQjlFSURLSTFHVVhDenUraTR2RU11OEg2?= =?utf-8?B?eFVLaUF4eW0vNG9reURDcU1YcGR4bFg3RjI5Ym5CL2RBUFdoL2dvcFkyM2R0?= =?utf-8?B?b0grdU9aZ25jaFFMc2VTYW5pS2Z6c0txVGRlYU41akdBRUJYSjk2TllIbHJU?= =?utf-8?B?N2tRb2xkTVoyenYrdFRiR0xydFJUUDdtSzAzRmV0Rmp2a3RhZzFzVy9Sci9o?= =?utf-8?B?SjltTnc5eTAySlJnUCt5TnJqdUxyL29DNXRNUDJRUDhpZG5nQ0RPK0NCUnFk?= =?utf-8?B?R3ZjM3hySkhZNE10TkNBdHY2bVhmODRGK0hBN1JDMGF1Nk1xUGN2dnQ4UFMv?= =?utf-8?B?cS9XVGxRTEVjZUl6Tm9UM2xYRjRSTVJRNnRpQ0M5bno3dzVUTXdiWXlBQnlm?= =?utf-8?B?b1ZOVkQzaDNoZWZIc0xEQ3BxTk5HcFA1WW8xcnRUcTFkeSswQ0lXTnVRc3pa?= =?utf-8?B?VVNRMzYzakdKWTdvZVJNT3dRYjFjNkxuZFVncmlnc242MzcyaENLN1Rrd0FJ?= =?utf-8?B?UWttTzdNd3VuSCtPMmdIMm45SnNwQTg3djZVb0IxcVZ6K2VIclRwc1NWSjl3?= =?utf-8?B?RnliY2lPV05FUEsySG5WUi9ucmZEYkZnTm9VQ0dKVVF3L251ekJRdnFxTnhj?= =?utf-8?B?cTJST0pYWEJ5bkd4US9KcGpzaVNrSFp5TXUxVTIvN1g4Qi9Jc0pPdnd3ZVJz?= =?utf-8?B?Q3ZselFhYmJvNThyR0tiVGJsRFNqOUZUMzFMd0JBZ2pJSjNkRlRnMTQxNmVO?= =?utf-8?B?Q05ZazFsT2lOeDBjY1FIdnpHYXRvMUl5WW5ibWJ3TC94QThxZVVSa2p1bmhF?= =?utf-8?B?cmFsK1ArOE9HVzdJWTdObnpmUTAzR3VoOW42UlNMbXVnVEhXbjZWUzlCQjR2?= =?utf-8?B?NGh2ODZ0WWppZmNzZDNvZHlFcDM4OU0zbTBzbXlGSnNjTzBFeXloVE1SSmcw?= =?utf-8?B?R0dhSXRJWUdJa0hXbW9mdmlwaUtVaFVaUy95UkxINGtvYUliQW9GcHFUaEtU?= =?utf-8?B?UkVaSjljelk4ditpV1BIdVZWSHZoOVd0eDdnUWMzb3NMNmJnT3h1eGR5M1VG?= =?utf-8?B?dGJhR0NGUHlxNkhjbFlsZGF3RXZNUUNqTVFsaXJiWDNOZkVEdy8xeXUyMU53?= =?utf-8?Q?yQF0=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cGtGeElFNGUxRWQrN0lPNWtkV3NpQVdKaHNmakpEUGpZL3R6TDJvQTNJM0J3?= =?utf-8?B?eDhwK202RmlCdldTb0hZQmVicnJBVHVDdXhOdHZtNS9JOWtNUnF6eXZTdmI1?= =?utf-8?B?YnY0Sm1kZnRxdkZ3S2xiK1poYnVtTndyZXdFSHpqU0ZvN1o1ZWt3eE5mcnlK?= =?utf-8?B?ZGVaZnFEbmtlWWQ0S3Q0bGZHMTFhczlZOTF3MjAyNVgzSk9CVEgzTHFUc1lw?= =?utf-8?B?Q3JXVHc2WHZkckdlczl0TmtqT0hicm4wODdZY3J3OHRNMW5JeTdtbE5FQzdD?= =?utf-8?B?ai9iSUUxQkJ5V2t5anl3WHIwdXQzbngvTE5Yam1ZNmMrS2doWGE3OE1GZjE5?= =?utf-8?B?UkZ3a29QSTZBdCtGWlRzQkpLYWdrY1BzajJqSVFnMlIzMnNuclNsUTBkSXRT?= =?utf-8?B?VmhkYmk1dGJqQzNIYTBScGNWME1CY3FSaXI2K21uTjdPWlMwUHlNZk1IdWFM?= =?utf-8?B?NTFPMG9LYVcxdlQ1R09TL2VocXAvMVcyWXc2OU5kOG5lRkg4N3VtRHZ6czYy?= =?utf-8?B?VVdXSFdIMzBhcldsbFp2STRKcEMwM0hiVEhKZkNzeHAvUVUzVjlQLy8xUkRM?= =?utf-8?B?NWFGeDlYYlh5ZjFJdGNkMmVjd01qZTZubUJSWktYU1NYV0VVSDFWdGk0WmRD?= =?utf-8?B?cHMrSHV2bERjUHlKcmhqYlBEQWVsOGRsQURURWhzRXBWcWcvUC9hYmNQWGI2?= =?utf-8?B?ZnJDV0Z3ZGJwbjhuWGdoS2pmLyswcG52M1JhUHFLbVdnNW5BSEFuOU5rcjVs?= =?utf-8?B?cUhzSmt5bUE3U3I1UEJJY1lKU0VEMmtJUlZZWlJ0bmorU01TNEk0aEQ0RFI2?= =?utf-8?B?MjJJZWVsbElaVEtqY1A5amlQa3hOSmsraHNvRk80eHZraGVrTGhuRVpUYzZp?= =?utf-8?B?WEJXcEhmZUFTYjNCbDRjNkNML2VOaFhtd0VHVitZaTZKRDRLWDlmUjVoUGQx?= =?utf-8?B?cnZvYjBTUjFrVjNXWHJjWDhBWXkvSzc0WjJ1c2pjd1NLR0daUzl5SnJwakd4?= =?utf-8?B?OC81VFlWNGFtdEVnZndmZHAvbUM1MVVWd21sdllVZHpIWmx1eSsxT1lZcXJt?= =?utf-8?B?dWlxb2NwdlRTRXVKZUpGalBESDJ6Vm5GVG5hNnJvbnZuY3RKTFYrVU9CNjRG?= =?utf-8?B?SDMyTlhCdVp0UTNvdThwY0Z2bzJXU1Vnbk5sZFVXY3AwQ3MxVTFQWDJyaUpy?= =?utf-8?B?cGFuU0FqT3FWOEFJdFdGL0dWYnpvc2xVa1R1WHNhdWxqQjRpalRjVldidER0?= =?utf-8?B?TzkzVlJBNVc1bmd5RCtZYnJjVFUxZFVjbVJaelhURWgzNG94a1VlUmRldTJ1?= =?utf-8?B?ODNIeEQ0NXZlTTdWNXVWVWtYWFVkeFo0dmRDcm5jUU83WWxBenVDY09ybTVx?= =?utf-8?B?cWtkTjZ6elFKOGtCMmUvVkk0REwwLzNTN0xSWTFSNjB4eVZCM1RveHlBekdQ?= =?utf-8?B?TWEySHh2Y2ZjamdDMXRURmgzNUJNMlMwcTFkUUk2dWsrb09DcmU4VXFLOTgx?= =?utf-8?B?QTd4WmhkZG43QXFYNTIrV0NqOStzbWtVTnA1RXpTOVhpZXA3R2s1bXc1MFJu?= =?utf-8?B?bDJZc1ZRbWZMQVc4d3FldS83TFhKR3M2VVlMVTN2OCtnbkZXeDEzYlhpQ3Vx?= =?utf-8?B?b1YyZVYwcUxwUmVYQXNEM1BJblJMZ1ZrdnIwd3hmU2JaS2JzVzBNVFpaVnJ4?= =?utf-8?B?SVBpR3FVNGdOQTZmdE1lSFJBS3BYR2JieUpIZWgyTCszNUtRTHFIbm9xaHY2?= =?utf-8?B?UFFKcm1lS0I2S00wY1FiSEszcHZGelgxSWlJWmJzdHJ1TW9wRyt4cERHU1Vz?= =?utf-8?B?bExSNDNMT0dlbUJvejFYb1NSeEJiZk5ucnBvZVVydURTWHB6TVY0REtjeit6?= =?utf-8?B?dUptSU1nMWZrR2hLWEdES3hDS20vUzR6dkRDaGpKS2NRZkVTVS9ETWdZc3R2?= =?utf-8?B?QnkvRWVuSFNTZ25CWXFjbXdwcU9TZUFtVUpGcFdRR0E3STQzSkV3djd6REkw?= =?utf-8?B?WS9scFhkbXZNSjU5YzlnTXhQU1lFKzhjYWpiMzQwZXh4OVd5TEZLMTlXU0NU?= =?utf-8?B?aVF3WVdHWlpkRVhucHh3T0tELytlUFo1WWkxOVZnNk5RM1NUUTNCWDNVQlMx?= =?utf-8?B?WnAyYkw0OW02aC8rRE1SOXRqNUdlV1BzWGw2UUdNUmN1OXdUMVRhUWozcUt6?= =?utf-8?B?b3YzV0hpZnBQbzJOek1QRFJyZlZsUmFzUzBpZ1hwVzg3bGVFbTFwcjRlVjNr?= =?utf-8?B?R0UzOVhERjVGTTRzTVl5bW1uMUwyaHp2d3llODB1MTVYZmF6YTkvQU9RQmtm?= =?utf-8?B?UFNvYXZvV2xQMkpiTkFpa1FpYlk2OWxhdFdCcmtQMHpHK1Q1TVFpd1BCZWto?= =?utf-8?Q?vj2LyX+HMyVFOszQ=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8b870bae-8e42-4364-6ebf-08de5aacd801 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2026 18:25:53.9799 (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: 42uooxFd8yiTC6AGFHsVTw5wFYOYwAw7HwFE3mA75kzMVWG3g9mRzGJoTMnIUfSeZPt9gT1FhQSZUnYMgqN8uDkiv2zLelMSCpNoE3qIME0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR03MB5988 On 23/01/2026 3:45 pm, Alejandro Vallejo wrote: > On Fri Jan 23, 2026 at 3:05 PM CET, Jan Beulich wrote: >> On 23.01.2026 13:10, Alejandro Vallejo wrote: >>> On Thu Jan 22, 2026 at 7:16 PM CET, Teddy Astie wrote: >>>> Le 22/01/2026 à 18:44, Alejandro Vallejo a écrit : >>>>> On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote: >>>>>> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote: >>>>>>> Open question unrelated to the series: Does it make sense to conditionalise the >>>>>>> MSR handlers for non intercepted MSRs on HVM_FEP? >>>>>> I'm not quite sure what you're asking here. >>>>>> >>>>>> ~Andrew >>>>> The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as far >>>>> as I can tell. The question I'm asking is whether there is another code path >>>>> that might invoke MSR handlers for non-intercepted MSRs. I can't see it, but >>>>> I'm not sure. >>>>> >>>>> If there isn't I'm considering (conditionally) getting rid of them. >>>>> >>>> I think you can enter this path by making the guest execute directly or >>>> indirectly a rdmsr in a emulated path (there are some cases like certain >>>> cases of real mode or maybe vm introspection). I don't think that FEP is >>>> the only way to do that. >>> For the emulation path, I think HVM_FEP is the only means to trigger it, as >>> neither {rd,wr}msr access memory. VMI (as you mention) and nSVM (as Andrew did) >>> do make sense, but I don't see any others. I don't see how real mode could cause >>> anything (I'm fuzzy on VMX, but I _think_ instructions do execute, just in >>> a weird paging-on mode akin to v8086). >> Iirc there's still the situation where for PAE shadow code tries to emulate up >> to 4 insns in a row, in the hope to find the other half of a full PTE update. >> >> Jan > That's a rather obscure optimisation, thanks for bringing it up. > multi.c:sh_page_fault() is rather... opaque to just look at it and expect to > find anything. Shadow's hvm_shadow_emulator_ops doesn't fill in the MSR hooks, so should at least abort when encountering this case. But there are a lot of instructions which can fit in the restriction to simple read/write/cmpxchg. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jan 23 18:36:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 18:36:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212484.1523584 (Exim 4.92) (envelope-from ) id 1vjM0l-0008R2-Vj; Fri, 23 Jan 2026 18:35:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212484.1523584; Fri, 23 Jan 2026 18:35:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjM0l-0008Qv-SI; Fri, 23 Jan 2026 18:35:59 +0000 Received: by outflank-mailman (input) for mailman id 1212484; Fri, 23 Jan 2026 18:35: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 1vjM0k-0008Qe-Ve for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 18:35:58 +0000 Received: from DM1PR04CU001.outbound.protection.outlook.com (mail-centralusazlp170100005.outbound.protection.outlook.com [2a01:111:f403:c111::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5b763102-f88a-11f0-b15e-2bf370ae4941; Fri, 23 Jan 2026 19:35:58 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DM6PR03MB5274.namprd03.prod.outlook.com (2603:10b6:5:24b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Fri, 23 Jan 2026 18:35:55 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Fri, 23 Jan 2026 18:35: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: 5b763102-f88a-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Wyt3Q5snIfwoEd5RzsXePb4/PrVsUkrfjobKfBpw/nwLyYB7fthO/MUji41f5ZgU78NzxZx1NgDqjED8xMZCX7Rfj5gfjNmLm9tSAQb9vhHmijA516zGgKRLJ8MIX6Em1QS+ueW4WuNBOpEgOWzNhz1IH/txQMkUOVcAK857+W1t9ExakeYNN0DukA/OtxuC/lb3SJwuUa7d0xo5qQ3SkRlAONTHtXSkFDniQqkOSZLGFobgo56gvN33fmXPkqyIz50ziwRFIasJyYODn+m9nrbTVQ2qjTP/Z+qXMQg3n9qEau5+IGhFyFWwf+TcQSPhmAsfio2urv59ed070fTK1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UDYKtXRIwGDvhRwvbrWZX7feYB597Gsg6ZTvn4WzwH0=; b=yVm0u9eswUOo2LYYZBu06pA4sUNOelnwfKSoMA66kRJDwa/QYhxvRTaBIBHssVEt6uh33/YIIJaB1fCCREmqFhc9bqwMYNEykwS5h72BcDJUvgl/WGJ3qUvf4JbkxCaYAwni9rb9t7FkVfClJQ4hK1OvqJo/OXFBoXgkOEcAZCfibYHvesS87jBKnSChlfpendWe0mb5ExFsfDOH5bZRoBLQEOYPgxfTUzUYtYD73MPnilwUTBxLPsuGIwGb24Br7b+jaDXc9rNny+nci/eUJTjkvhZ9g9x1hfGO85O7ZenSwlfFLrCQSjMR+aI7vUI5MdkTeYRgwx5cO0nvVeq7Vg== 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=UDYKtXRIwGDvhRwvbrWZX7feYB597Gsg6ZTvn4WzwH0=; b=ohjsW8MWSZkb3uQWI9SYeslPyjDW7zFWPHLnn7hU7TGLBH1f6o54GO0/iLVEgfo1SFWKBXSylj+KLCBBx/8OCKhWmUK2DEpoG8CWlzXmlqAcAN3spCnpGkScA1GahsiMAHmKm/WyY6ZR697ezK18HNmeL3j8hHs3VP6LfwnXAPE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Fri, 23 Jan 2026 18:35:51 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH 3/4] x86/hvm: Remove cross-vendor checks from MSR handlers. To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <20260122164943.20691-4-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260122164943.20691-4-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0217.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:33a::14) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DM6PR03MB5274:EE_ X-MS-Office365-Filtering-Correlation-Id: 6e36dbf1-1223-4534-9522-08de5aae3e50 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?bytSdFdha2lEL21VMFlsYnJNZ3V0NmN0RmkxaUlyYytCVTVuaHJ0WU1tM3Bs?= =?utf-8?B?dStjWU56NDlwVlZLSG0rVVdnNEpoRnZ5UUVsU2cxbE9kRmJnclBmODErbUV2?= =?utf-8?B?UVN5Um5EZ1ZCcWZwZkZrdVpnNmtUU1dUYXlCUEo3bHBlVlQ4MUk5bkRXUms1?= =?utf-8?B?MlliY1hqRWVid0lUczVKZ3UwTElKOFJpMXpjc2gyMkNqQjd5RVB3cWFLQUZX?= =?utf-8?B?ODQwZEEzNG41NjU0Q2hQcHZZc2kydEd0V2NzT0NUbUxKeTRqMTR2aEF1Z2hW?= =?utf-8?B?aEpwcXRtTnBod3JxUHRmUE9KYUV3NVhBN3phOWZKYXhkSnU5UmU2TCsvcEta?= =?utf-8?B?cHMxc1lQOFlET09wWko4cUkxUXZFRWJabWx4MkVqSy9SZ1ozS3BkRURXbW5p?= =?utf-8?B?SElHRE8xUDlUMEh4VjJNK1loc3crZXgyUzhucGw4MWZTVy9WanRFdGlpV0l4?= =?utf-8?B?alIyNnpLRXhHamEwbUh6WnhSOXB5Q3ZuclpxQ2VwV2gxRlRNTWI5bjFLd2xG?= =?utf-8?B?L0p2YlBjU2RSY09ETGttb0duNU1jUTNleUFlM2VycGNuUjNuSEMrWWd6VkpW?= =?utf-8?B?cm82bjdOK3N1b1d4SFR2T3F4TUlQMmx4UlVrdElVbFdya1RZWEtlK3pOQW1P?= =?utf-8?B?SFpTMjA2RnYzSEZlOTVmanBtVTRDMml6U3YvN25lQjgyMVEwamsyNXZ2bWZN?= =?utf-8?B?anUyN0IycEwxcjBGVkZwRmFRVlRyZE1mSGZYL1NDNE56TVd5MndhN2lwR2tV?= =?utf-8?B?Q1U5UzlDTjFmRnc5Z0UvQkx2UTBkVkRETGpiY3pOWTdXN0c4T1ZmQVBJOS82?= =?utf-8?B?K2NMNkFPS2Jxb2d1V3lwbzhISTFzTGVTSGZLYkhrVFY4R2F3MkVYMkFXa3Iy?= =?utf-8?B?c0trRDlaaTJtMFNTT3ZLcENpTmQySkRHd0cra0J4Y0xac0VIaUlQU2FEdGF0?= =?utf-8?B?WDFYWlE4YVprV1VqN2J3cDlxWEhPcXNWaktSNnVEU3M0dldYQVNsYmtabEZx?= =?utf-8?B?azF1T0FaM2hsNFlNVTAxTlZnL0IzbUIzVDBLQWtORk4wV0FjZTgrSTR0UEll?= =?utf-8?B?OTZPMG1kN0EzbVJOUlllUzdERFY4cGRGZkk1NVc3Zk4zN0NlWitaa0NxMERB?= =?utf-8?B?akdtazJXcjBRemdWdjh2ZmVRUlBmNnpsNGhLWE5nM0tWdW5UaGh5UVRFbm8v?= =?utf-8?B?OHZWS01XTmFiRU43eFZoQlI0a2wwWG9PSkVsbWZ6REoreTkxcFdiR21VZWRx?= =?utf-8?B?YnFXRXFWaDR3c0pKMU9IcmE2RDJXczhYSW4rWURQcUVKRWdUL044cTBVVlBZ?= =?utf-8?B?UWVwaXFPai9OQmlRdzNhSTNUODAyak9JWFlmdllwdW55TDEzQjlsZWhyWEZU?= =?utf-8?B?U0d6a21wZjRtUXQ5ZkRVMUtxYnc0WnJBb0pNKzkrRVpzMjRiRG1SdWIyWEc1?= =?utf-8?B?OXJ0QUR3VVZoaEl3RWYyL0RndkgrQjdvWkZybTU4eERtZnh5a202TW9idjAz?= =?utf-8?B?dFByS0d1ZWZ1OVFwSlFjZU4zZlJBbUtSUFN5ZEw3YXN1R3E1V21FLzBiVWtL?= =?utf-8?B?bjF2RlJHZ09wY3V6c2MxSWJ1b0ZoT0huaTlub2FPODZ3b3NGVE9iNXZoZE45?= =?utf-8?B?SmJiTDgweWNyMlk5OERLcCtyTzZreGxLaEc3a05yMnJLNUNKZDJZbzVQempr?= =?utf-8?B?QzRzcFZIbjBOZjhpVkdPc3g1MHVjbTNFMGc0NWhDaDdhN1dUd25kdUQ5ZHRM?= =?utf-8?B?VVFFZ3JKUHdMWGo0cHNnTkF4S0NNdFl6UG42aXNIQWhlVklDb1ExbUFHMGNN?= =?utf-8?B?RTFPU0FtSTFHdEpQVHgxWHhEK1NBZnRtNkVCZlQrTnFQVXdOY01qalIrSHNH?= =?utf-8?B?b1lra2V6YzVBUWk5cXlKUzNvamhNNkxSWnpILzNOdkNPWG81T2Z3ajAza1F2?= =?utf-8?B?cU1YYmo1MWdVTi9oWDA0ZzJrZW1VR3VNOVRZVGlxdnRTckx4ajhhRi9yWkF6?= =?utf-8?B?dWg0czR6c0xGaHFGaGJ0R1dhVytZTEoweExDOUJHV1liYzZOYmRjTlM0NnNv?= =?utf-8?B?QUlnUTNBSjVKV3B1V3hDTzdWT0QwaHJLQ2FtYWx3S2oyU2dZelBCSkM2aUlZ?= =?utf-8?Q?NNcA=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dXpTc2duQ3EyY3lpV2JCcHdHZmNyT0szSFBPUFJtbDluV3UrZ1ZnSTZ6ckZs?= =?utf-8?B?Qks1WExqTHNqNGNaWlNJVGk1VWlvOGExV2ZHbzV1ZUF2WVZGd3lnZUlJY2NH?= =?utf-8?B?My9RaGk2OTFDRnJucXQxRnEvRDJxYk9EZ1UyK3hoSHoyK0hVbzBXU1p3T3Yw?= =?utf-8?B?d3JGaHVlbCsybGRlbWdQVGt5eWtrWWVHRFUwcjlaRFk3czAvTDlEaUNTL3Rp?= =?utf-8?B?Si9QdFB1cUZCRHdyMmp2VnA4YnFpL1ZBbmtzZnNGOXpJenJidGRXbTlJVHgy?= =?utf-8?B?YXhQR3RwUk1UY3VRUDNiZXZ2ekRkOEVRenRtc2M4eTh5WjJGblFvZHF6ZGY0?= =?utf-8?B?cyt2QjVqOGpJblRNMTdZUFpsUUFINktwaWRVS2VvT1l2V1lDM3dtSDY1cmdM?= =?utf-8?B?OHhNYmg4blBJT1NWYWR3VU5yMXBVdVNJWDFRSjBUT3k0Y0IvMlB1NE9mL2pM?= =?utf-8?B?d0FLZ09EbFBrQ0R2MUtyN21mM3JsbDNEOVFLK3oxdUtZT3I4V2dJODNBdllZ?= =?utf-8?B?R1crZmRZQ21KdTNRdmNCa0I1Tm1WRFpHdUN6S1AwbldLZVhBVUlGVEdiNldK?= =?utf-8?B?SEdBK05WQ2toOFNzMGVYNnVGRHFHOEJ5bG5nOE1sT3NQcDJhY3RwYzVvY09X?= =?utf-8?B?VXRzSVpaSlFydW9aRjRyVHJMcFA3WnVXejFLQ1YrZW5tMXViaCtZSDBlRnQw?= =?utf-8?B?RUJDZ2tLUFJzN1ZrUkdEcUI2WlMvTi9lc2NWd2dHbElPeGlQbmIzVTNSbDFF?= =?utf-8?B?YkI3dHdjdkdjVUswY2ErbEhEZ0d2YUduNVlMZGNtN3JzbVpqOXJDMjRoUnlr?= =?utf-8?B?ckx3R2llL1NaMnF0cEFZVm5LcGNSTkd0WUVFQnhEUTJZZjNZZlAveDBoaWND?= =?utf-8?B?VG14a3Z1QnRtTTZabTFLZzMxcE5YbjlXTnhWRVdGYnBOYTJkSXlsN0NHUDJE?= =?utf-8?B?UC9sOVhjWllOaWo5aHFYUUFrQ3RjZ1FjTWRwd2lPMFA0eWV3cTdBbk90V05o?= =?utf-8?B?RzZpemh5Ny90UFJPNkdNRzY5UTJYSUlHaktPYW9WcjMzUTdJbE9lUkJGbXlN?= =?utf-8?B?TXoxc2RuZU1STkJ5UHZiWmFWbXZvazlvbWFrYi9pVlpIMHd6UUE2UzYveGxo?= =?utf-8?B?RGsvcXovaU5LN3lrd1hNMXpmNG5tYUp0YmJBTUdIalFzRVd3Lyt1WHNOWE94?= =?utf-8?B?a3I2WEFYM0dOdlh0VCtZejBSQzdRT3RaVFVObGJhUkx3eUxEbDl6dTFkbnkz?= =?utf-8?B?bGZaZXY2cUZoQWhzVTRsREwxK0J5R2JTY2xvdnREbjNrMUtJaTFrU3hVZm5z?= =?utf-8?B?L1NQYTU0TUMxSTJvUi9GYTlYcWxZVmhqanl4bzArd2p1QUpXV1BNZ0NqYnRa?= =?utf-8?B?NFF2VCtwc3p1WlhKV1o5aEppakJxNEJnanJJRk5IZzJCV2FsTWJ4TmRVd1Nr?= =?utf-8?B?OFptaEVoMWxoMmN5bitGRjN6S3hRUHphdWg3NWdqQXhOOFo4WEM0dHJNWGU4?= =?utf-8?B?aFIwTnFWanZvVW5VNjNHcHE1UEcvcjdwOXNiWEFDeVd6VXFPamg2ODhtZnFD?= =?utf-8?B?eGJaS2I5T0VVVU1ab2VtVURlbkJsT0s0YkU4M2hMZnYzcGEzbzg4RWdhK2t5?= =?utf-8?B?RG4wb1FYbWZkWGZZL24vejJVWHRSbVVaV3BhUnc0cG1ycDdCQ255OC9qcDdX?= =?utf-8?B?K0JZcEdWQ0pJU3BwU0tEWVVXRDBVQmRSVDhON09jSk5CMDFlUG5zWWRNelQ2?= =?utf-8?B?NUdWMVo2Qmpnc0FNa2o0Y0xKUmo5TTlYZ3podTBJanNUYUt6bXdJSm1vVm9M?= =?utf-8?B?amJNbTk5R2dSTG5HVkRSL0pTWVQ0Ymc5TjdoMUp3UHpINFd4YWN2NHppRjVv?= =?utf-8?B?QzJMbXE4NlNSU2ZlOEhGS0FzakF1TGdodVgwdldFUGJyVWViMWJTSXBXbTJS?= =?utf-8?B?UjlXSXBRWFowWU0yalJrbG1OeTNiRjdOMXM5K01FUlE3WU56cnJLMmpPRnhU?= =?utf-8?B?QWlFWUZ2TmpqOTNXRzc3Nk11U29UbDFyWi9lNHZhY1pHM2V0ZUx1WVBPN3di?= =?utf-8?B?Y0x1Slp1VTl0aDE1S3hVTzVraFNUeTZVSGE5MEIrKzFHcEtKTkZqNDUxZmxY?= =?utf-8?B?dE9QLzlFZDZkY2V6ek1oTGU3dFBab3RWZFJySFhZR1BKUkNDMHZlTmJSMWkz?= =?utf-8?B?VWZsd3orQ0pORFJnK0hwbHNYdGFWRG8xeDZYN0EwQUxHc1ZBT3c4V2wrbDUx?= =?utf-8?B?SGxSRjM4M2hQeDl2b21BblpPYTVTS0tpSTVsMFcxTUI3am4vYlNUSWRpNkRK?= =?utf-8?B?aWdsSHE2YVBBd1ZVNWh5eEZKZTcrRWtUc2YzRXFVZE0ydVNJeE1Mdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6e36dbf1-1223-4534-9522-08de5aae3e50 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2026 18:35:55.1106 (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: ObpTuTnk3Wuo8Ki34e/x0tZGY/Ws9BCAvVSjKfiWd2bOjEEnzaH6rSbUr1HKHKYG71SAbRrkaVvZ5uPoMAZY1Cqi8P+97GMyzAq5teWo3PE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR03MB5274 On 22/01/2026 4:49 pm, Alejandro Vallejo wrote: > Not a functional change now that cross-vendor guests are not launchable. > > Signed-off-by: Alejandro Vallejo > --- > xen/arch/x86/msr.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c > index ad75a2e108..c9cc4f0692 100644 > --- a/xen/arch/x86/msr.c > +++ b/xen/arch/x86/msr.c > @@ -169,9 +169,9 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) > break; > > case MSR_IA32_PLATFORM_ID: > - if ( !(cp->x86_vendor & X86_VENDOR_INTEL) || > - !(boot_cpu_data.x86_vendor & X86_VENDOR_INTEL) ) > + if ( cp->x86_vendor != X86_VENDOR_INTEL ) > goto gp_fault; > + > rdmsrl(MSR_IA32_PLATFORM_ID, *val); > break; > > @@ -190,8 +190,6 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) > * the guest. > */ > if ( !(cp->x86_vendor & (X86_VENDOR_INTEL | X86_VENDOR_AMD)) || > - !(boot_cpu_data.x86_vendor & > - (X86_VENDOR_INTEL | X86_VENDOR_AMD)) || > rdmsr_safe(MSR_AMD_PATCHLEVEL, val) ) > goto gp_fault; > break; Hmm.  Thinking about it, this would probably be cleaner to get rid of the cp->x86_vendor field entirely, and retain the boot_cpu_data side. Additionally, this would fix a minor problem I'm having cleaning up the CPUID code for XSAVE fixes, and provide better cache locality. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jan 23 18:40:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 18:40:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212494.1523595 (Exim 4.92) (envelope-from ) id 1vjM57-0001dq-G4; Fri, 23 Jan 2026 18:40:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212494.1523595; Fri, 23 Jan 2026 18: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 1vjM57-0001dj-CB; Fri, 23 Jan 2026 18:40:29 +0000 Received: by outflank-mailman (input) for mailman id 1212494; Fri, 23 Jan 2026 18:40: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 1vjM55-0001dd-SW for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 18:40:28 +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 faac6575-f88a-11f0-b15e-2bf370ae4941; Fri, 23 Jan 2026 19:40:24 +0100 (CET) Received: from BY3PR04CA0009.namprd04.prod.outlook.com (2603:10b6:a03:217::14) 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.9542.11; Fri, 23 Jan 2026 18:40:18 +0000 Received: from CO1PEPF000066E7.namprd05.prod.outlook.com (2603:10b6:a03:217:cafe::7a) by BY3PR04CA0009.outlook.office365.com (2603:10b6:a03:217::14) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.10 via Frontend Transport; Fri, 23 Jan 2026 18:39:57 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by CO1PEPF000066E7.mail.protection.outlook.com (10.167.249.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Fri, 23 Jan 2026 18:40:15 +0000 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.2562.17; Fri, 23 Jan 2026 12:40:15 -0600 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, 23 Jan 2026 12:40:15 -0600 Received: from SATLEXMB04.amd.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, 23 Jan 2026 10:40:14 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: faac6575-f88a-11f0-b15e-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DU6EB6HeWP7XqGZOaivqghcL4mcHR36ybMthxOvqTuxBNry4DuJhQkVrnBFJIBjkFM1jcFDS9p+ZP+OOlBxOInC3CzCpZQGLNTGrl766x86jqPy44jcp63wmpazCsHFTg6jf2Hp2sxzKft47zderASbUGapz96pEA0kNIenn9nlPSGNN3c+x4X0VKRl7ForBlOy7npzA8mo7L4TPRlD04JxLJaumGqHWW+c2pIh0BUyVdbJCFaJO1clHLkuRXKaLDJoqkNjkupNYrrtTIlsy4L5AGI/hQP/9ZOiL5RH730FWheuwFhVfkJw9Gqp6grI5Azs4lx/stRBSAA2GxBlzcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1Zn1BH99uusiRfW0GGp2REfCR6pwTNQ4LVM1LBPTGp8=; b=SMSNWD/RK/JSA5/sjBW+O1cZJsN17R6i0f0lD9rxL+zsZLvreuMZRCyM9U/AL2R/4b430ZL6LJdnrfp5rSViVESbrjQ7K0lXw7RuIgBk4DacpC7nFe8s0Jz09L/kwkJ7SyuasKpXA2b+LXYKOydkXLs5jsFIUrZraeoiQcqnPAsu9rQWJoUseb1rBjXuQZFIX1rrQUrHqTGRAwRA30el1Cep0cPEHdJoyIlzcZfjousyRkIB4xr1RlhnDLkvNWVrBOdt88rhsRYRDUAe/7JjLQuhwWWXjUTe8VLwMQMOLejvieJwwiZJFKAFTcDrDwJ2HZY34IaF+cKYeGXIErTgtg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1Zn1BH99uusiRfW0GGp2REfCR6pwTNQ4LVM1LBPTGp8=; b=J2hlSOqIl3qSUyd+6J6TljNFao6fTqvohScuFdsIeEtCSjCwJEG19ugu/xBhV5ErgUDZNBehluUjgh4XHV+2vw0RpUdwRGmZFZXWHq+C6Cq3cxJRIRPLr7bJOoKM930PJPVsFjuitsTojt+Xuk/+l4tmbqfkRn6/RckKJuky9ic= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: Stefano Stabellini To: CC: , , Eric Van Hensbergen , Latchesar Ionkov , Dominique Martinet , Christian Schoenebeck , , Stefano Stabellini Subject: [PATCH] 9p/xen: protect xen_9pfs_front_free against concurrent calls Date: Fri, 23 Jan 2026 10:40:09 -0800 Message-ID: <20260123184009.1298536-1-stefano.stabellini@amd.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain 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: CO1PEPF000066E7:EE_|BN7PPF915F74166:EE_ X-MS-Office365-Filtering-Correlation-Id: f9084faa-dadf-4f10-4223-08de5aaed9d6 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?ztUw7kZYq+/lOjU78pewF8Ti+/GmhdAQCT+Y3shKDyza9tIfZmekNriNPvD4?= =?us-ascii?Q?pGIrKMWQezq6g5N1F8t5eq7eS15zONN7A7WsdHwmYZp8p1pcMBM9O2vNxtQ8?= =?us-ascii?Q?nU1qNRWwpQHsvlehOSm5Mgj89XYBDwTfTsXrwCiGqw4mHFROY+cbOp1+5CWm?= =?us-ascii?Q?E1t2PolShmZoV7KdzGoiiTpKzRFcXl5BH+h6Ch9XUgXpWlQb1//NGVGgq0ZK?= =?us-ascii?Q?jDTt/ZTLKq6vUChxo/twEgo7Z/hsw6yVuNYTJ/Uy+dNK1PZ65aXaO5ZZcLjw?= =?us-ascii?Q?K3w+mWn6rmSrXL49ZGytWiusPT8dtyYu5+roqvGSje6DBHTZPwWanViple/z?= =?us-ascii?Q?aM2C0+iN7ahSglGKPYfcF3CNNO8wUTj4fKlfNKbrJTBGf2STcQrAYwqx68FN?= =?us-ascii?Q?fhNeVLx2ZKxvUX8HMBbAMszMf26uhi9onRhq39cd7Jnr43sByNEsL886FPL5?= =?us-ascii?Q?zSaY+MrhSOMdQEPVjdm6S8xEE0Rh+DSZxGUHOw1noG/XbhzBJBEvamLVuY9Q?= =?us-ascii?Q?JdqAJe5tOpnaX8TSCYxxy6yL1hFIH1jTiArPRKt+81ytEQRBnmXC6IxzKBL6?= =?us-ascii?Q?yOGQMC9TrSasYelvsCqETS2JYfSXiBOogOpLOb2q4mPGAptn7Sj910MXk1u0?= =?us-ascii?Q?ONH92Kj/cAwiRcxcMFvlC/uhDDMieZ+wKV/2LxFPIp5xyOSZ62U6a0FxbVIN?= =?us-ascii?Q?DBaqjCsADp0gCLuJGrfOdSFis7j+m/sm9lYsoeD4Uxg4lsuadrSCNssNF8sM?= =?us-ascii?Q?Q0qo3El0YSyMmKO5V5JX1kdYKEt0c0kWTuDhLEmBI7FwzoG5MXd5AvEkbhtW?= =?us-ascii?Q?BaVUZKpd4JchGy5JguXXRAD4+Qwa7BZeJHh3mhtsLxtjyVzJ0HsSyc2ikdLn?= =?us-ascii?Q?pEmCIf/0JOl5MO6immT2mPYwS6o6HLow3NqxwnJXL/mukwozm0xCnI4CvyB6?= =?us-ascii?Q?tTztJUeW8qN2Q4RkhzHH1HdU9BV9V+VEtr5cXcjUt+nppdJ2wmna6X5xB5VT?= =?us-ascii?Q?0i/AB724amWLYHCFGbGBn54z0BilQwq/2u+NKN7xo+sYHRChKn58LNZbUg37?= =?us-ascii?Q?iLzfrJ4vDLvRmGKXqvtwsmAosynVMC2ig+dhumV9dG0Hf7JfxOUv0tO1+e1F?= =?us-ascii?Q?eKNxOn1kP7CXwcRauRqbJiFcqP1P0+GvvsIIGoS5TbqrDUmaIXRjIzNuw+FM?= =?us-ascii?Q?bpbuSGtX2JViOfMeru2l6kIBYsVFGL+kJAaIND4D9SY1f2YAFDvdbyFBpoNa?= =?us-ascii?Q?n9gWvzjf91l1TEFInZTqnK6LmXzRmcWRTgwR+6ArP1xvO87jtvSGnuzIkB8j?= =?us-ascii?Q?S2Koin28HdA/M/qKeZxJFppE8BvjXUchGEnI3he07Cxs7+BqGj9wRhNo0sB0?= =?us-ascii?Q?TZHWKUSR3ZV/uW20gWcLOQ+v/8PjX/mZNn6ZAIIQrKRrJQS0Vwv5nCDusvcC?= =?us-ascii?Q?H87zG7tcpS6G5jKcK+W3tXsX2/OI3pghG0nhF0bLIKjNN6mbk9ptbsMPJMn4?= =?us-ascii?Q?lAUhYQuXZvOn+16Y04FcsDMgTqbEVNfLlSiXsmMplRslMM6bBu8FrfYe84t4?= =?us-ascii?Q?z9I6Gp0jPTjnZqxfq9o9jIaVlQacpaIXCsn/7JhGffjuTyHs2aQ5el9spdSm?= =?us-ascii?Q?xTV994EpuMz85krGGAd14svjcrqUFmXlh0pIfg+Qqx91J40SjJxTibaxHI6Y?= =?us-ascii?Q?dJppJg=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2026 18:40:15.7961 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f9084faa-dadf-4f10-4223-08de5aaed9d6 X-MS-Exchange-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: CO1PEPF000066E7.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PPF915F74166 The xenwatch thread can race with other back-end change notifications and call xen_9pfs_front_free() twice, hitting the observed general protection fault due to a double-free. Guard the teardown path so only one caller can release the front-end state at a time, preventing the crash. This is a fix for the following double-free: [ 27.052347] Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [ 27.052357] CPU: 0 UID: 0 PID: 32 Comm: xenwatch Not tainted 6.18.0-02087-g51ab33fc0a8b-dirty #60 PREEMPT(none) [ 27.052363] RIP: e030:xen_9pfs_front_free+0x1d/0x150 [ 27.052368] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 41 55 41 54 55 48 89 fd 48 c7 c7 48 d0 92 85 53 e8 cb cb 05 00 48 8b 45 08 48 8b 55 00 <48> 3b 28 0f 85 f9 28 35 fe 48 3b 6a 08 0f 85 ef 28 35 fe 48 89 42 [ 27.052377] RSP: e02b:ffffc9004016fdd0 EFLAGS: 00010246 [ 27.052381] RAX: 6b6b6b6b6b6b6b6b RBX: ffff88800d66e400 RCX: 0000000000000000 [ 27.052385] RDX: 6b6b6b6b6b6b6b6b RSI: 0000000000000000 RDI: 0000000000000000 [ 27.052389] RBP: ffff88800a887040 R08: 0000000000000000 R09: 0000000000000000 [ 27.052393] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888009e46b68 [ 27.052397] R13: 0000000000000200 R14: 0000000000000000 R15: ffff88800a887040 [ 27.052404] FS: 0000000000000000(0000) GS:ffff88808ca57000(0000) knlGS:0000000000000000 [ 27.052408] CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 27.052412] CR2: 00007f9714004360 CR3: 0000000004834000 CR4: 0000000000050660 [ 27.052418] Call Trace: [ 27.052420] [ 27.052422] xen_9pfs_front_changed+0x5d5/0x720 [ 27.052426] ? xenbus_otherend_changed+0x72/0x140 [ 27.052430] ? __pfx_xenwatch_thread+0x10/0x10 [ 27.052434] xenwatch_thread+0x94/0x1c0 [ 27.052438] ? __pfx_autoremove_wake_function+0x10/0x10 [ 27.052442] kthread+0xf8/0x240 [ 27.052445] ? __pfx_kthread+0x10/0x10 [ 27.052449] ? __pfx_kthread+0x10/0x10 [ 27.052452] ret_from_fork+0x16b/0x1a0 [ 27.052456] ? __pfx_kthread+0x10/0x10 [ 27.052459] ret_from_fork_asm+0x1a/0x30 [ 27.052463] [ 27.052465] Modules linked in: [ 27.052471] ---[ end trace 0000000000000000 ]--- Signed-off-by: Stefano Stabellini --- net/9p/trans_xen.c | 41 +++++++++++++++++++++-------------------- 1 file changed, 21 insertions(+), 20 deletions(-) diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c index 280f686f60fbb..8809f3c06ec95 100644 --- a/net/9p/trans_xen.c +++ b/net/9p/trans_xen.c @@ -274,11 +274,7 @@ static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv) { int i, j; - write_lock(&xen_9pfs_lock); - list_del(&priv->list); - write_unlock(&xen_9pfs_lock); - - for (i = 0; i < XEN_9PFS_NUM_RINGS; i++) { + for (i = 0; priv->rings != NULL && i < XEN_9PFS_NUM_RINGS; i++) { struct xen_9pfs_dataring *ring = &priv->rings[i]; cancel_work_sync(&ring->work); @@ -310,9 +306,18 @@ static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv) static void xen_9pfs_front_remove(struct xenbus_device *dev) { - struct xen_9pfs_front_priv *priv = dev_get_drvdata(&dev->dev); + struct xen_9pfs_front_priv *priv; + write_lock(&xen_9pfs_lock); + priv = dev_get_drvdata(&dev->dev); + if (priv == NULL) { + write_unlock(&xen_9pfs_lock); + return; + } dev_set_drvdata(&dev->dev, NULL); + list_del_init(&priv->list); + write_unlock(&xen_9pfs_lock); + xen_9pfs_front_free(priv); } @@ -387,7 +392,7 @@ static int xen_9pfs_front_init(struct xenbus_device *dev) { int ret, i; struct xenbus_transaction xbt; - struct xen_9pfs_front_priv *priv = dev_get_drvdata(&dev->dev); + struct xen_9pfs_front_priv *priv; char *versions, *v; unsigned int max_rings, max_ring_order, len = 0; @@ -415,6 +420,10 @@ static int xen_9pfs_front_init(struct xenbus_device *dev) if (p9_xen_trans.maxsize > XEN_FLEX_RING_SIZE(max_ring_order)) p9_xen_trans.maxsize = XEN_FLEX_RING_SIZE(max_ring_order) / 2; + priv = kzalloc(sizeof(*priv), GFP_KERNEL); + if (!priv) + return -ENOMEM; + priv->dev = dev; priv->rings = kcalloc(XEN_9PFS_NUM_RINGS, sizeof(*priv->rings), GFP_KERNEL); if (!priv->rings) { @@ -473,6 +482,11 @@ static int xen_9pfs_front_init(struct xenbus_device *dev) goto error; } + write_lock(&xen_9pfs_lock); + dev_set_drvdata(&dev->dev, priv); + list_add_tail(&priv->list, &xen_9pfs_devs); + write_unlock(&xen_9pfs_lock); + xenbus_switch_state(dev, XenbusStateInitialised); return 0; @@ -487,19 +501,6 @@ static int xen_9pfs_front_init(struct xenbus_device *dev) static int xen_9pfs_front_probe(struct xenbus_device *dev, const struct xenbus_device_id *id) { - struct xen_9pfs_front_priv *priv = NULL; - - priv = kzalloc(sizeof(*priv), GFP_KERNEL); - if (!priv) - return -ENOMEM; - - priv->dev = dev; - dev_set_drvdata(&dev->dev, priv); - - write_lock(&xen_9pfs_lock); - list_add_tail(&priv->list, &xen_9pfs_devs); - write_unlock(&xen_9pfs_lock); - return 0; } -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Fri Jan 23 18:41:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 18:41:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212503.1523604 (Exim 4.92) (envelope-from ) id 1vjM5b-00024X-Mn; Fri, 23 Jan 2026 18:40:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212503.1523604; Fri, 23 Jan 2026 18:40:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjM5b-00024Q-Jj; Fri, 23 Jan 2026 18:40:59 +0000 Received: by outflank-mailman (input) for mailman id 1212503; Fri, 23 Jan 2026 18:40: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 1vjM5a-0001v9-3R for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 18:40:58 +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 0b1d0bab-f88b-11f0-9ccf-f158ae23cfc8; Fri, 23 Jan 2026 19:40:53 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BY5PR03MB5000.namprd03.prod.outlook.com (2603:10b6:a03:1ee::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Fri, 23 Jan 2026 18:40:47 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Fri, 23 Jan 2026 18:40: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: 0b1d0bab-f88b-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Uf4f1qZx9qNm4ZAu0cshiSmFJCQlX23NpZZFNI4Jc6PYnrVbqT/3q1oJzz/TO5G543AYaVGZLjfJ/SAbAia0s4CO2bRACPmOB8W/dLHmHsz6lunAx908KjFbN23RMff16xdW4dlxawXOkc0aA4EZQFyG/FbAm+n9/8jbPw8NrCCSK2dNIlphKFvDGlDpZat2NT/qokJewSY+NBh2Z2XvgtXL+h49pZ1YLF6MvC+gjqREjoOKI7Fr6ILQqWDa+31rJc+kfWMtCDiG/1yzvdCG8vD8J6Joal0+pOrEYI4pKEQqLs8lpPVLQMuRCMMM3nrf/BFPojTas5lDvEm4vRnqqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0fz4wPS5udrYlnYBDJTD1OiXCF+tx0Wx0BbqzQz+xd4=; b=laepI447sqaNfyn/vW9l1B8YHAk8LFFt78CmfJVZHI9qVPzseUJ5G22CpB8Zp6hA1PWiwkwJjCNptWW7uCTcawaANytjU3QQe/0LGeUXNiUhqYmN/Acrd7nAXTR8iZPDkPe08WDeb5bMPRzNcCkYcdw8dHqRHBJzfie2iHpSUvq6wPCq42OXUQ/9yGFPAj8RTaYgoNJH/Tfki0J/DT/sV0o9n9G2aLO+PhlaQJbPZbqiW7hu57skvf9Q/7ZqqJ8veGyq2eJchPPFy18U4LMre3ZyFvVL6EZXlFBdamvPqFD0/FwfxiazlRa8wYkdnya78NOrfivagIloDhaBRynHDQ== 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=0fz4wPS5udrYlnYBDJTD1OiXCF+tx0Wx0BbqzQz+xd4=; b=p8hAaxqSvb32JUFHsL7espaIRmYWpAGD+8wDeeuTchsWCAbLlq3O8b5gM2CLOImNzyjnxXvHkFXdj9xWBR4OabkmJSh22qB2LIO2bsWA78rcLjtEEKafL9PukeScDK0AOOj/QXwtmDgpltm8hQXmsDNCpmGU3NmjwJUkk78FEqY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Fri, 23 Jan 2026 18:40:43 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk Subject: Re: [PATCH 2/4] x86/hvm: Disable non-FEP cross-vendor handling in #UD handler To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <20260122164943.20691-3-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260122164943.20691-3-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0075.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:190::8) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BY5PR03MB5000:EE_ X-MS-Office365-Filtering-Correlation-Id: 2eababa8-628a-42f5-6b37-08de5aaeec3e 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?WWtvSno3VG94aGxYY1d5Wmt1cnlvaCtmSENBYnR2dEdrMjFtcjdtaWRkeStt?= =?utf-8?B?WmRuN1VYSytRUXVSN2h3Zlpndk8wbkJuRzhMM0tjVTd5NkE5UlNKck5kSkd4?= =?utf-8?B?OS93NnVwQmIvVGVGbTFLQk1YdU5QTkRaZm9sNXdNWjRCQjZ4NzJPK1FjSlpo?= =?utf-8?B?djJOZkRtN3YxSmptRXYxYWNPQUpnVVk3dlBSaTh5M1BoSFh0RFNZRjBKaUFa?= =?utf-8?B?bXJRM2w0U1JVcDhhVEszajJwa3NTMUdta1h3bXB5SE42aTNLcHN5VGtSVStj?= =?utf-8?B?TVIzUkliMGUzdE4xUEdDLzZtTmlaZjNNS05tdkQ5WlRRNk9WT0N3eE9mTWha?= =?utf-8?B?Q3I3Q29KQ2wyQU16NU9aMFNjN1JZaFlhSWlMVVJNc2tXZkUvMDB0RGMzQVBw?= =?utf-8?B?YzdvTys2TGtlK2hMb3g2bFV4VTJzY2RkRTYyRUZ0RWZPYitIME0vZS9UVUkx?= =?utf-8?B?QUFsbi8wR2x1Qlpxd2lLdlpYQkJGNWhkSmlyNGVLRTBEeU5RMVZ0YUNDRkdY?= =?utf-8?B?aVp1YXBsY214WGduWUVyVFRLeC9BLzhZRTRSbWZKbnFaVDRlbjRNWHlaZGti?= =?utf-8?B?dnZ3OGg0bXMrRG1YVXp1anYxZXBERFBNOHBiSU5pNkZENVoyQXEreWpYNUdj?= =?utf-8?B?MmYrS3F0ZWQyd1NaZWtaWUJ2RHl2enVIUEppdFc4T1lmS0xBTloyZ3E3aU9K?= =?utf-8?B?TEVWYkVjNEZFT09Nc05EWXR4aldVKzdYRVJ5UjFZNGhTVVQ1ZzlqRGU2WGFE?= =?utf-8?B?K0tiWVAwT3IzVHErVDAzUHozUitpQjM2eU1nUHMxR3VSKzh4a1lKV0EwTXl3?= =?utf-8?B?eEpyN0l0R1V1L202WVc3MEVoVGNRenB6SnpvbnNORVdTU1JSM25tVUN3T0dD?= =?utf-8?B?bEhFUUl3Y0VEcmdZbm5DSUlEaXVJUFJvcFF0bEZ2TGRzclJQc0kzL2t6N0Fu?= =?utf-8?B?VGFhT0t0aVp0MTJXbUNMbFM0TFRDS3hPeUI0aWdHYTVTQ0FoTW13OHJNdGxD?= =?utf-8?B?czQ4K0UwY0xQcDRYbkN0Ry9lT3JTdFJrUHNLR1FOeDhZMWFJK01yazJ4aEt5?= =?utf-8?B?cmwrTjd5RGg5LzZGNTBKcmgyc0NTYVNaQXR3M2syT2FFYlMxY3AvSmFOYUpI?= =?utf-8?B?K09uMXl6aFNZZTdoOWpSNE1VOThTRlpFMnRQMWUxUlhxM2pzR3hMSEgxRjIx?= =?utf-8?B?a0llMEw2aFRqUXJwMjRPZTdVckhzcVp0Q0FaSTJFVkR3eTlzMm93eXRld05y?= =?utf-8?B?aEJmS2VLRHoxUkk2N2pmT1l4WENENUN2Smx2QkYwT092RlZPWnc4T2EwSDRn?= =?utf-8?B?N01ZSEFBTERUaEhXUTZEZWVCek1IVkdOSGV5UDNlMFZDZitHMFBoSFdrbEZY?= =?utf-8?B?Z1N6Vzc3MkdTSUVoazlhNURtcWNPZXo1aVZYcmF3VWhmbG9xUnAyZjlzRHFV?= =?utf-8?B?QWllWWUxUnZvMVNBckhsNnNKYTRuc3ZOWjBHRHI4R0Juc1JNekludzhFMTVn?= =?utf-8?B?b0dxYVR5SGFZaTUzZ2QxM2IyZFZsRHJpcHhaSmdmTkxteW5LaWZod3JsUUMz?= =?utf-8?B?NkwvWU02SkcwZHFISFRvaEJENHpYMjJKU0lZSkF1Q1BPcG5OaXgrZ3RxRTZ4?= =?utf-8?B?cnhFWEgrVmJZRzlQRXRaYWFreTBVMlFiTE9Jbk5vaDBnTW1KMlptRExKRXU5?= =?utf-8?B?dHZDa29RZktCS0xHNXFZd28rVUV5bjdINUN3ZHluOElTcW1uZDBOb1BDOG1C?= =?utf-8?B?TzArY2x2ODIzUldMUEVHK3ZveHdMKzhvMkpFZklYWDhvS2RmbEduaDZqeDZM?= =?utf-8?B?TDJWWHRTYTdac1owNE1QeXlqVVlaRGNYcDVEeWJjMDZCRFhKeXdRWGdHMVRp?= =?utf-8?B?eEpSSUZDQ3ZlK2t2LzZLUUZyV1FaOWhmSVlvRXBQU0lXdUlqY2VrMUxPaGxz?= =?utf-8?B?ZXNxRVFzT2hTNGRsbGtrbW04bWUzc3JzUkV2blNjUCtlVURxZ1lkOFpzNGEx?= =?utf-8?B?Rk5TcnRReFBZOFIzTysyN1R3VTNUNlJFNE5YUnpDeHJ0TlJ2cVBxbFh1aDZ3?= =?utf-8?B?dHdPYkFvYVNMUkV2QTJ5bWowZzBrSGRJY1RRT09LVUJoZVNaWmFrZnRodWdv?= =?utf-8?Q?3B9k=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?a3l4YzBaQklUaXhFRG5UbVBWRFNIWjM5Qlg5ZmRBVDJnRkVhMFN3K1B4ZkVM?= =?utf-8?B?OE91T2tPZmsrZjAzRjBKd2EyNzVwMm5Na1hYVGRnejRLZTQzZkVoZkNuZ1ZX?= =?utf-8?B?dUoyNW4vdURsZDBDdTNEVFU5RXIrOC9zMXpSL3pqMDhzOVpPT3Y5eEFlT2xW?= =?utf-8?B?bE8xWWhya2NGcGJ2SElHTjZHcTIyT3hRclRabnM0NEplK253TzN6T3JmVC9i?= =?utf-8?B?VzRXbE1KVHN6TTNwOHl5bUxaZzJUTWRBbGE3ZndCVFh4Yk51TjgwOGxvNE4v?= =?utf-8?B?TzBYbHVjRE1WdjJFUW5TamdpVDIyYk53dGhEbVlrcUF2Zk9jTzdLR0lkQlEy?= =?utf-8?B?TWExcCtiUUtuaTJjM1hISThQNDk0RUx6ai9qTGNVVXAzWlVDUUlZM25QazZN?= =?utf-8?B?Tm15WGtjemtmV2pBRzlaVGpwSHN5eXdhZHJMeXUxaFdqSEdmMlhuZWNoU0hL?= =?utf-8?B?ek5HaWJ3RVludDZxamxQR0huVm9vMDQwV2lVQmE5ZFFqTHFMeDlIeUIvWDhO?= =?utf-8?B?UDJ2d3BPeUx0bVZ1ZGQxalpiTWZFRkVlWDBEZ3Z1di93UUVjeVRNZG01aC9Y?= =?utf-8?B?dHEzOFdpdHZOZVQ1Qm9OUXlad0dUdVh6UHQ2T2N1ZXIxMFowTm9xcHY4b0ky?= =?utf-8?B?dUFrVWdwZ1UxR3o2dUozY2RXSFJpdHhoQTlCN2FpbU9LQVBpZ0M0SWFCd2J5?= =?utf-8?B?T3VpZ25yS0ZVNGM0bVdmNFp4bTNlaVloY0dtenBUV3M2UUtESlVjV1FGYmUx?= =?utf-8?B?eHRqNHgzK0VSa2hwdlZ6Wng4Ynd0U08yY1cwMXRKSWpOMDZmZEVsSTFvemtu?= =?utf-8?B?VFlZRGo3UDBDWThOUC84WkpkaXozK1hUd0RWRmFHc21IY1FoNXRJWEVjUVRT?= =?utf-8?B?U2ZVTExjYjgrc05ScUpWU2FQQnFTTEdIWjNUUWNycG9ieVJ3ZnAxUWQ1M0JV?= =?utf-8?B?UkI4dHNWdlJ2ZEszQXlmY2hwUjhlZ2wyQW94UG9TOXpyYkJ5dE5uVjVDbHdq?= =?utf-8?B?MUN3dkFNbXluWUhsVXNscnZBRFBWUGJYWCs5bndnbW80dmlpSWthc1JXdjlV?= =?utf-8?B?S0hUWEdnckNqYlVYRCtETW9WYVE1Qml0OHZsL3RFb2UzMFBaMWh5SjZBdHRU?= =?utf-8?B?WEg3VDRvSmdyRitLUWlCTnRvMGdibnhSUzZrMTN3SEZuR3dwYXEvQTVCVWRZ?= =?utf-8?B?Wm9OT3dISFJFNVVpdkF6RUwwS2c0N2ZXRFpxR1JtQ1cwdG5PR2hWOHNZWGFI?= =?utf-8?B?VEpRcG8wb2RJYmRkNGwxTnA5a3RXMlgrWGllUHVsQ1pBUUlyejdJTDVKeHFB?= =?utf-8?B?N0l6Zjd4b3Z3ZVNSTURDNXduTURaQ2lDVXF4dVh1Qy8rdjEzdnBLRHlLTncr?= =?utf-8?B?b1c0ZGYyYm1zVExFQ1NtN2xReWsvNC9hUU1NeVpPOTdvTzlNUS9OVTlUU29w?= =?utf-8?B?N1BJcFlNTUk0WTI2K1paY2dBN2M5Zi9HQStnOXNuQXkrcU5SMDY5eTcrTEE0?= =?utf-8?B?SkNJSHNndTlpNUpabGs5a1pwUXJSa2dhQ1FpMm1YQUZmdXptUExDclRNRUxm?= =?utf-8?B?MDJ2eDNjNWdHUUtNYlhoYjBEWUtnWEJlUVE0aFR5c25NS1dWVVQvL1JjSmZL?= =?utf-8?B?RG9abEVjMkVib3VmRDlVVGJnQ1VuVU9lSjRocXhFWTFRTytoRXMyMVU4WTVn?= =?utf-8?B?SXpYQzNnVy9VaFhWeTFmcC95dXRiSm9wcEVEcWd1NzdKMmxYMWppSWYwS0p0?= =?utf-8?B?NDBXc28yaUZnVVBySmowZ2F0aFlaV0VwSmdTdnNYWW1KWWZVeElVdmpSa2VY?= =?utf-8?B?NkFrUE9lWVZseWRCYmQ5VUxXYjBIWXM5dWNzRTRuaWJ0TlNvNGR4V1Y5aHBT?= =?utf-8?B?OC9QNXVxV3liY1Y4aldVN1lDTGh6RGhVSkhYVXVReDJuV244WUJITTFIWSt5?= =?utf-8?B?dHk5Z2dycm9Ka0NEZ05CRG1hOVBDUisvbEtIYWtwcUJybjFpN25iVEg2YnhE?= =?utf-8?B?L2JzMGpFREJ0Zm5xZnhMZUFtNnF5dytTRzJmdVpTSGcxRzdJV0loeGZaK3F3?= =?utf-8?B?OStEQkxNVlFFa0V1azFhOU1oMk1mM3dhYWZ6dTJWejF4ZENzaW0wMXMyaEFl?= =?utf-8?B?RkxLS0puWEsyU1pJWUxpVWJ0WTVneVBVOUllS25MMWxGMHFMYTdKcTJLa2dG?= =?utf-8?B?N3FRS21jNDVmTFRXUzUyYVVjN0tQenkzNFh4anF4SjhHMTdGUkhScHNuaWw5?= =?utf-8?B?T29qQmZlZTBQN3ZETS9Xd05SVFpESnpQaXdEMWxaVmd2V1NRc2RpQ0ovaDR0?= =?utf-8?B?NTlSYnU3SThMSmhHTHQ0L1FqSnpoYjkrc1hCRU1PNGt6ZS9YL0hJQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2eababa8-628a-42f5-6b37-08de5aaeec3e X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2026 18:40:46.9147 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: F3buUlXEJCVLHCFmSt/d8rHZ/+vIbp1YweEINhujSH597olPR41uKSFgad9sKnswZlYBL8tRlCG4dA5Q9TBO1RwxZ1HcXU1W55iBXr+y05g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB5000 On 22/01/2026 4:49 pm, Alejandro Vallejo wrote: > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c > index 40e4c71244..34e988ee61 100644 > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -797,8 +797,7 @@ static void cf_check vmx_cpuid_policy_changed(struct vcpu *v) > const struct cpu_policy *cp = v->domain->arch.cpu_policy; > int rc = 0; > > - if ( opt_hvm_fep || > - (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) ) > + if ( opt_hvm_fep ) > v->arch.hvm.vmx.exception_bitmap |= (1U << X86_EXC_UD); > else > v->arch.hvm.vmx.exception_bitmap &= ~(1U << X86_EXC_UD); > @@ -4576,6 +4575,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_regs *regs) > /* Already handled above. */ > break; > case X86_EXC_UD: > + BUG_ON(!IS_ENABLED(CONFIG_HVM_FEP)); > TRACE(TRC_HVM_TRAP, vector); > hvm_ud_intercept(regs); > break; Again, nested virt makes this more complicated than to simply believe it doesn't happen. Also, more often than I'd like, I enable #UD interception for other reasons, and I'd prefer that that doesn't get any harder than it does right now. In an ideal world I'd have already upstreamed the logic to decompose double/triple faults... ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jan 23 19:25:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 19:25:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212534.1523613 (Exim 4.92) (envelope-from ) id 1vjMmi-0007bl-1R; Fri, 23 Jan 2026 19:25:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212534.1523613; Fri, 23 Jan 2026 19:25: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 1vjMmh-0007be-V5; Fri, 23 Jan 2026 19:25:31 +0000 Received: by outflank-mailman (input) for mailman id 1212534; Fri, 23 Jan 2026 19:25: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 1vjMmg-0007bY-Ss for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 19:25:31 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 441386c3-f891-11f0-9ccf-f158ae23cfc8; Fri, 23 Jan 2026 20:25:25 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS1PR03MB7870.namprd03.prod.outlook.com (2603:10b6:8:219::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Fri, 23 Jan 2026 19:25:22 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Fri, 23 Jan 2026 19:25: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: 441386c3-f891-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MpbOpOjAgvZD83KxZsQpVKma/Bpgu2hIv2Zc4vaANeaIgZCyu7nbJLRtTSNneCmczwap/QGpLXAGTtLShyDnkJkpYXilHddldINPN/q9r/MsWysn7lwwlKJsHVfcnkH3uKuR8+bjBtBL/7e2wZ8mNnPnYF7XKx42x5xIq/fvxwQJ28sNJdO7ZjDxH/yYpBFL2ecUtY3A6H1d6g1ZVdwWLQhGb8DxCHfvo72XXF9OUHp4Nia6Sw2nhnYJ2UvdT0w6Bxao7prLWcRIuxeLATWO5mPT5I+sQhZb5KAedMGVB9KT/gww6yubllxVkIQJ/Fr3pa9sWcCtbTSpuziIoHGRqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=f39J1f54d22jlbm1nTCNDm0QvEkLQLSb0okXJ4v3uEo=; b=xeEUW6Tg9bcHBWELZDdddsV3B9LTeVx+SM09PtLhinwIH+7lCQbKZTUn4LwbWueD6lKyx+cjJ7oYrkhMUgas2cQuYFcgWfZgktaMNVqZFyMlhz5Dy10Ue15E/QHzGtlqU931ikQmwOw40xS0FxjWOcvxzTpXLLvLsJ/N1Pqj83KeNw/4D2lut4kPORffnzd2TKAiW73Ox3QadIV+HlFMn8fqGJBWPIH2Ty4zkVdZd6nqOcO3810fCbtHr7GVqrtPF+XfH8P0WMa12Mbo+A+Qv0hi+FD6c8Q3J/EjwkBdgNY/4gaRHBQyAYbALzAPKdj22dpxu7/YbciBkbYDN+WqZw== 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=f39J1f54d22jlbm1nTCNDm0QvEkLQLSb0okXJ4v3uEo=; b=TPSR/lcyTALFIy2DghfkmKEJnUlIxok8tbgMZxmlglO4HVSswEwIGvmgwuZNQ5xblPL56EA3+0JQKSlFdnEbXxy3sYGtcaOHth6gCwqhzOMWjik2wP78sIR3N/kWvZMbxdWrtnA2K7n2La2lwyG2y0GR7xZpe+9TpY4Gz140F7k= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <4feba079-aae0-4732-bfb3-5be6c1269e2b@citrix.com> Date: Fri, 23 Jan 2026 19:25:18 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "Daniel P . Smith" , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , xen-devel@lists.xenproject.org Subject: Re: [PATCH] xen: Move NX handling to a dedicated place To: Julian Vetter , Jan Beulich References: <20260115151658.3725784-1-julian.vetter@vates.tech> <69b511db-654d-46b3-aca3-3f37f30d3473@citrix.com> <335949fc-059e-477c-9b2b-ddcd2f144300@citrix.com> <4a38c2ae-dc60-4fed-b30e-81a02b657e92@vates.tech> <92c02d2f-ccc5-42ce-ba0c-076fdc75e1fe@citrix.com> <09d59ee2-92bb-41de-ad77-6b6c6bc44d6d@vates.tech> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <09d59ee2-92bb-41de-ad77-6b6c6bc44d6d@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0553.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:33b::7) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS1PR03MB7870:EE_ X-MS-Office365-Filtering-Correlation-Id: 6cebecdc-a960-42c1-c7d3-08de5ab52720 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?NEZLWWd0dFZjV0tyaXV2VVBpZnVaRUo1Z2JuUExFQWt2eWxrcXgvZzdqWG1w?= =?utf-8?B?dmxINVRsVCtQQ0VPaXYyMVlqdFQxZDZzV3c3SDc2eURHNjZRbkZsK2xaeDFF?= =?utf-8?B?WFNZWkN3VmxjNU5PamtxR0tZQURSazNzVnVDOGtQMDFyTkRISHpMU3E5czlW?= =?utf-8?B?a1pVRThseVVnT1dmT0RDYXhCaStGMUVGcXNWTzF1SUJsU0VZVjZocUNFQURE?= =?utf-8?B?MG1GNGdZdHlxRUdYKy9JWUxmZ3lYR0p3SjVKYlhJai9aYTd2ZUxuWnVEdGlW?= =?utf-8?B?cW5zNzViZER0MURuck5wekIycGtEM1hmb2F6Z2VoSkpBSDFyeG42dGg2eWJB?= =?utf-8?B?d0xvQXNNb0VVbUQ0eWNaNGxXM1pyMXNRMG9ZZmpJR2ZMUTBweksyb1lDdHpQ?= =?utf-8?B?VzhPZ1pLdFVQanVWZUg1azIyTkp3MU5VQzN5UXZnU3BXeUNCTFlGTUtvZzND?= =?utf-8?B?NW9VYlFLakwrZ2Q5N29sY1czZHgxRnJ5WmNmclBKTXRyZ1dYazBldFVmcXFS?= =?utf-8?B?TUVlbzJyaVBBZUtxaVJSdG5KRnJCRDNNUW9kRSt5U3RQVFpCTUdoMCtZdjlG?= =?utf-8?B?ckpicjY5b2FEMEZVVFlyWkZlc2NPTGVZcEJjOEFPRllJSjR3TkppWmRpWFdp?= =?utf-8?B?aU0xRmZXamZRZGl2cGtuek5Xdko2RzVQeVBuTUNacTVMRUhDY2NlNnpMOEw0?= =?utf-8?B?ekdqWmhNdUNjTks5ZDhvSkI5MXp5VTh1T0Z5MnJhTm05bWhrQURvRFpjOWhZ?= =?utf-8?B?QlRob1ExZXQweThNUm5UOW1PRmZwZlR1blprdWZ2WldVS2t1OTNLdW1ORlRn?= =?utf-8?B?Nk1MWXlKV2R6WElqQVBTZlBJOWZGUWRQOFFIb3dpTE1zWFFsS0tNTVV1ZDAv?= =?utf-8?B?ZVV1by8xY09QNDNtdVNuYjJPRXFhcmRLV2wwWDVrSUo4REJpYW8vV2MzTXpm?= =?utf-8?B?UU0xVWlqNW0yY09kTWx2b2Z0ZUtHMkxyM0NFRDRzK0NsV2tYNzZwSnhHNkw5?= =?utf-8?B?SElDZFNsajNQaWhTekkyMDloWXpoMnhDcXZtYzFGaVZmV1BWMlRpZmp5OUw1?= =?utf-8?B?eXZpTVowQVgxd3pUU01pelhVSUtYcDhSVGE0YkNydVV0b0R2VFMrTFg2NTZ1?= =?utf-8?B?M2o2Myt6dXhLckh5eklrMXhVZDdPeVpSZ2FCaC93dDdtUFVJck1XaVl2QjJl?= =?utf-8?B?UzJVL2xJYmxyS00vcXVuSXFiK2g4dmFtZGZwcGFwd094eE4wbjFFeGxSeFlK?= =?utf-8?B?ZWNjWVdtWUJEUWNKcmJsdEdXUjVEZENkZ0pRbnpKVXQ5Tklia2FnVUg5YzZD?= =?utf-8?B?blRaVHRWM1FSYmNRMloya1RWaE1OVGFFQ2c1QUR3MjhVS0xtWXFwTkxBUFZv?= =?utf-8?B?eHhTbnBnOVJBWitNVDJ6cVhtVGRQZXBxSGZpbGt1eUJWMVRCajl3RGNqazVv?= =?utf-8?B?SW8yK0thamZxZlBhbkxNNXBtZEEwRDlnczVTbGJkWmZvZy96bzVydlpoKzFI?= =?utf-8?B?aG96WVl3d2tDc1FoaWJEWnJTdFQ0aGk3YVpXalJqVGgzNStmQjU5TkZ6RHlQ?= =?utf-8?B?d3Ara28yWk9WMzI4R1p3K2krVzhZMnBkaUhNVjlyNDBoQzl6cGNveHl0NW5T?= =?utf-8?B?S3hxV25jUlNjNStjeGRKR3B1S2ZWM2NFczVlNy9uRCtqUFlEQU1XK0N5WXpw?= =?utf-8?B?NEhkNjZNclhIVGwvOW1Lcm1SKzBWcEFqdWpqelIwdU9UcXRsNzdDODA3VkVr?= =?utf-8?B?Q3BWNEJMSHVIUEphYWduaFhud1o0cHkzaXNOTXFnNFVrUXlUOVNWNm9ORm0r?= =?utf-8?B?Z2NESFZxRm8wcjVpWmx0dytwMC9XaGxPeVZJcnFJclljR3EzSlFDckpNQmUx?= =?utf-8?B?T2hkYW1kUE1ZSDNqdTlaMk1SLzczdVMzTFgvTGRvZ0NaK1kyeFo0NXVuZGdu?= =?utf-8?B?UHN4eHhKNk5pR0RmWSs3V2N4em5KT3VLcDI2cXhmeExrRjVQQ0RQWVJWNGFX?= =?utf-8?B?cUFwZjVVVGJRQmhpVzd4WjNlaG16YXltZlRhNDFBRzZ6bU5YcmF1RFMyTnBu?= =?utf-8?B?Q3lwcGsxYnRockkwbGVEL1VOSU5nRFJYTEhIVDhFNmJJU3RWY1pOWjFvaHBN?= =?utf-8?Q?IilE=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QmFObzlwQVpwOEFqaTlnL3VkMEFDZTdvaEE2aTJIeHNOTTZRamV4VndkQkpi?= =?utf-8?B?dnlEQlQ1d2ZRcjIzbk52SS9qZG5mYXhaMVM5TXlpWWgzcmxWTCtzV0VENWlH?= =?utf-8?B?WjBaeU5uRHMxOVA5OTF6THRVdlB0NEJlaHRDcFVET1c2VnIwT1I3dUV0c3Ns?= =?utf-8?B?MTRHNUV0czdZV1VIZGRxNENwZERtUU9iVE5VV04vQWhHclg5S0VSbXROWi9R?= =?utf-8?B?RVlFRmJDdndHd2ZEUnUrWkhXNzJVNzJBRytjQTRDL2hwQlFHb1JvUFhLNnZO?= =?utf-8?B?Qk1mQ0JQV3hXbGZoUGcyVUFIbjZLRmxZblYvNi9KRWhuYXRQeS9WQVFRVndO?= =?utf-8?B?NXhwQkxzUDZSNFhqYWh5cEN0YjB6TXc3dWNhY0FhazJVNitLUm5XeVBwbzYr?= =?utf-8?B?RWgzS2RYb0ljU2tURGFVbGlMMlkyZWRmeXFKMVdjL3FoMFFhNDZwUTN1VkpB?= =?utf-8?B?cTlBVUZEbTVRRDBOclhieW9kWnd5TUx6T2Vlam5mRm1DVjU3dW1rb0NaZDlu?= =?utf-8?B?RERVelJqaUdQT01vak83S1c2STlrb0R4dTFHMmttekpZQnA4bzBjSndKUTdX?= =?utf-8?B?WGJxRCs4djBvWk9jcy9FSHBJOGN1VlB4bzBJcWNWVW1FU09tZVFSREp5VEt6?= =?utf-8?B?QzhxTHkxZjZBU0gxcTVRZmwvZDJhRENFaWczdnIwY0FuMkx1czVET1A5dVpr?= =?utf-8?B?Njlna0hsTU0waUE4dEQ3b0VWMXVUb0l2SVo2a1N6Z3VFVW12WTg4NjN2SEhN?= =?utf-8?B?d3puc3pTSktvWjRwc0lScHVrdWNkWGEyREtObHhKRjk1M3EvUUdNMFVqTE5k?= =?utf-8?B?VVpaMnBXdTAyTkdwZGRzZWQ4WTFiU3FrK1RXOTZBTHFVdEViYlhVVE9HaHRz?= =?utf-8?B?clE5UE1OdHBNZG1uWkFncXc3aUJKdmhOaEVhZW41Q3RHM3BOc0t1eStYUk5Z?= =?utf-8?B?bTFZcVVub25sZUo0S0JHaU82eTBmSzI0Sm1MT1QvUUFGeUtKRGFIQVFPaGNQ?= =?utf-8?B?ZmF1dm81TnNycXpGcnVYc0JZMmZ2NC9lcjFaVmJBQU85dlZlYTdHQ0Q1VXQr?= =?utf-8?B?aHB6Mnk3MC9tQlVxK1crZ3VHTWdHSjhCS1lUakJUTVJwUTd1Rk1DNGlnUWdY?= =?utf-8?B?bEtrcEh6RnhCNEw3Tk9JTE04MStqOXI0Z0R5NHNrSmpPWnpuN1JyRjhUTi9i?= =?utf-8?B?V1NobVFPVHZXME94dWNWOXFrci9qTmpUNXFUaGl6VzRJN28rV20yZDM4YnRz?= =?utf-8?B?VEUxWnpwL0dhdUc0ZkdLUXV4KzBmS0VxNGFkMEdFVVpTVnhLTWd0UXpyMXRV?= =?utf-8?B?WWN4a0JJcW4wN0J6SWtFWE5jQlZTYVQxVWcraVN4Z1EzcDBPTHBKTmVvUUFz?= =?utf-8?B?WE5lNWhjOFk4RkwvdTNETXRpcmxueUJsWWloeHV0c0FHMVljZFZUeXNJR2Fp?= =?utf-8?B?VUhTc1RqRnY4ODlYODFIdmVYbUhKM0tMSEVhTmtsc0tobGV5WXZsYUZYV2dJ?= =?utf-8?B?T0xwWVNMYWQzMXNObHVUN1JLTmhVajZBR1N6TldMbGMvTjlrd0tXdGZiVDA3?= =?utf-8?B?c0dYbXh2aGdYK3FOUVZkSnkzekxCcEp6MVR4anhKam5LVUVEczFtQ0VNbml1?= =?utf-8?B?ajdETVMyWWM1TS96VUgxTXFVK1h2OEx0Skc4ZVc4MkliSFlEeDhQempBSDNR?= =?utf-8?B?MXZaa3hYUWc5TlZKR3ZnOG90ejl6eEVLNVkzSVM2K2xTWnZNVlVyQlJZUVNH?= =?utf-8?B?bi85MjRrV01RQ0ZMWEJZWDhiTENMUDlKbDR4VDBnK2ZDSjBYc1BqN3gvZGdn?= =?utf-8?B?bjdLUnZwTWhvOWxoYTJqZDFWQUpuMzdOb2hRSjErSXZtSzd1VmdxeGlmNDJM?= =?utf-8?B?R2ZZeXI2cExBL09mNEtENUprOG1KN1loeGtycEhmYWxvSExtNllYcDVRakVP?= =?utf-8?B?UXZMeVRxMVpsU3N3OE5jSHkyV1N4L2tYeC9KS0J2TUM4WUpZRFBIcE90S0gx?= =?utf-8?B?Vzh1T3hHeW9OTGluemFFZGozbGs5djM3cDR0bjQ3SWF6dEFrSGZWRk5HVFE4?= =?utf-8?B?bE0wc29TU3FYMXVWVUJsVWNvSnU5SDNPa3hJTlo3R3BxOUNFdnNzSlZqd2lI?= =?utf-8?B?RThWSzkwV3FuYWkxU3dVSytqaWRhTEVrcmU4T3d5VGY0TWFUM0FMWGliaFI3?= =?utf-8?B?akNON2JCME9kUGhEK3VNcnN1TG8zRko2OXBEN01ZWGpFWkJDRUtIaE1mbE5H?= =?utf-8?B?c3BVYzdhVytPL0t3R3QzdFR4MGt0NVFvVmZISUZyaG45ZXVKdjJsUVVsTFB3?= =?utf-8?B?eEl2azR1L0dkRXR5a0tEaHIwVllyd3hhdnpGcDhtVzlSeGZaTUtXTFRmeHc3?= =?utf-8?Q?CKX4/g9dzAt75L8w=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6cebecdc-a960-42c1-c7d3-08de5ab52720 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2026 19:25:22.6170 (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: AM8W040CeCkMTAZG87WZMr3iqB+3sdhhU+w02p8TQlBtxM/V9HkMeF1yHxQ2KNYOSHPN+HGKe7yJ3hNDf3IVwdHCrZw/bbyel1QBoDF6K9M= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS1PR03MB7870 On 23/01/2026 3:31 pm, Julian Vetter wrote: > On 1/22/26 15:11, Jan Beulich wrote: >> On 22.01.2026 14:57, Andrew Cooper wrote: >>> On 22/01/2026 1:48 pm, Julian Vetter wrote: >>>> (XEN) Early fatal page fault at e008:ffff82d0403b38e0 >>>> (cr2=0000000001100202, ec=0009) >>>> (XEN) ----[ Xen-4.22-unstable x86_64 debug=y Not tainted ]---- >>>> (XEN) CPU: 0 >>>> (XEN) RIP: e008:[] memcmp+0x20/0x46 >>>> (XEN) RFLAGS: 0000000000010002 CONTEXT: hypervisor >>>> (XEN) rax: 0000000000000000 rbx: 0000000001100000 rcx: 0000000000000000 >>>> (XEN) rdx: 0000000000000004 rsi: ffff82d0404a0d23 rdi: 0000000001100202 >>>> (XEN) rbp: ffff82d040497d88 rsp: ffff82d040497d78 r8: 0000000000000016 >>>> (XEN) r9: ffff82d04061a180 r10: ffff82d04061a188 r11: 0000000000000010 >>>> (XEN) r12: 0000000001100000 r13: 0000000000000001 r14: ffff82d0404d2b80 >>>> (XEN) r15: ffff82d040462750 cr0: 0000000080050033 cr4: 00000000000000a0 >>>> (XEN) cr3: 00000000b5d0e000 cr2: 0000000001100202 >>>> (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000 >>>> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 >>>> (XEN) Xen code around (memcmp+0x20/0x46): >>>> (XEN) 0f 1f 84 00 00 00 00 00 <0f> b6 04 0f 44 0f b6 04 0e 44 29 c0 75 >>>> 13 48 83 >>>> (XEN) Xen stack trace from rsp=ffff82d040497d78: >>>> (XEN) ffff82d040483f79 0000000000696630 ffff82d040497db0 ffff82d040483fd2 >>>> (XEN) 0000000000696630 ffff82d040200000 0000000000000001 ffff82d040497ef8 >>>> (XEN) ffff82d04047c4ac 0000000000000000 0000000000000000 0000000000000000 >>>> (XEN) ffff82d04062c6d8 0000000000000000 0000000000000000 0000000000000000 >>>> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >>>> (XEN) 0000000000000000 0000000000140000 0000000000000000 0000000000000001 >>>> (XEN) 0000000000000000 0000000000000000 ffff82d040497f08 ffff82d0404d2b80 >>>> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >>>> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >>>> (XEN) 0000000000000000 0000000800000000 000000010000006e 0000000000000003 >>>> (XEN) 00000000000002f8 0000000000000000 0000000000000000 0000000000000000 >>>> (XEN) 0000000099f30ba0 0000000099feeda7 0000000000000000 ffff82d040497fff >>>> (XEN) 00000000b9cf3920 ffff82d0402043e8 0000000000000000 0000000000000000 >>>> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >>>> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >>>> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >>>> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >>>> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 >>>> (XEN) 0000000000000000 0000e01000000000 0000000000000000 0000000000000000 >>>> (XEN) 00000000000000a0 0000000000000000 0000000000000000 0000000000000000 >>>> (XEN) Xen call trace: >>>> (XEN) [] R memcmp+0x20/0x46 >>>> (XEN) [] S arch/x86/bzimage.c#bzimage_check+0x2e/0x73 >>>> (XEN) [] F bzimage_headroom+0x14/0xa5 >>>> (XEN) [] F __start_xen+0x908/0x2452 >>>> (XEN) [] F __high_start+0xb8/0xc0 >>>> (XEN) >>>> (XEN) Pagetable walk from 0000000001100202: >>>> (XEN) L4[0x000] = 00000000b5c9d063 ffffffffffffffff >>>> (XEN) >>>> (XEN) **************************************** >>>> (XEN) Panic on CPU 0: >>>> (XEN) FATAL TRAP: vec 14, #PF[0009] IN INTERRUPT CONTEXT >>>> (XEN) **************************************** >>> Huh, that means we have a bug in the pagewalk rendering.  It shouldn't >>> give up like that. >> Is it perhaps too early for mfn_valid() to return "true" for the page table >> page in question? > Yes, this is indeed the problem. Thank you Jan. The mfn_valid() doesn't > work yet, because max_page is set afterwards in __start_xen. Here is the > actual translation: > > (XEN) Xen call trace: > (XEN) [] R memcmp+0x20/0x46 > (XEN) [] S arch/x86/bzimage.c#bzimage_check+0x2e/0x73 > (XEN) [] F bzimage_headroom+0x14/0xa5 > (XEN) [] F __start_xen+0x908/0x2452 > (XEN) [] F __high_start+0xb8/0xc0 > (XEN) > (XEN) Pagetable walk from 0000000001100202: > (XEN) Using simple walk without mfn_valid > (XEN) Early pagetable walk from 0000000001100202 (cr3=00000000b5d0e000): > (XEN) L4[0x000] = 00000000b5c9d063 > (XEN) L3[0x000] = 00000000b5c99063 > (XEN) L2[0x008] = 80000000000001e3 (2MB) > > And I also found the actual issue with the code, and why it fails in the > first place. Somewhere before early_init_{intel,amd}, there is > bzimage_headroom(bootstrap_map_bm(&bi->mods[0]), bi->mods[0].size), and > the 'bootstrap_map_bm()' maps the new page with __PAGE_HYPERVISOR_RO, > which has PAGE_NX. So, not sure how to work around this. I'm working on a cleanup series to untangle the mess. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jan 23 22:25:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 22:25:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212585.1523625 (Exim 4.92) (envelope-from ) id 1vjPaC-0002j0-8g; Fri, 23 Jan 2026 22:24:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212585.1523625; Fri, 23 Jan 2026 22:24:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjPaC-0002it-4r; Fri, 23 Jan 2026 22:24:48 +0000 Received: by outflank-mailman (input) for mailman id 1212585; Fri, 23 Jan 2026 22:24:47 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjPaA-0002in-T9 for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 22:24:47 +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 4ffb92af-f8aa-11f0-9ccf-f158ae23cfc8; Fri, 23 Jan 2026 23:24:42 +0100 (CET) Received: from MW4PR03CA0291.namprd03.prod.outlook.com (2603:10b6:303:b5::26) by CH3PR12MB8878.namprd12.prod.outlook.com (2603:10b6:610:17e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Fri, 23 Jan 2026 22:24:35 +0000 Received: from MWH0EPF000989E8.namprd02.prod.outlook.com (2603:10b6:303:b5:cafe::12) by MW4PR03CA0291.outlook.office365.com (2603:10b6:303:b5::26) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.10 via Frontend Transport; Fri, 23 Jan 2026 22:24:10 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by MWH0EPF000989E8.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.9564.3 via Frontend Transport; Fri, 23 Jan 2026 22:24:34 +0000 Received: from Satlexmb09.amd.com (10.181.42.218) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Fri, 23 Jan 2026 16:24:34 -0600 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Fri, 23 Jan 2026 14:24:33 -0800 Received: from [172.29.134.248] (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, 23 Jan 2026 14:24:32 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4ffb92af-f8aa-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xpqGgvEzl3sjIy1DxzOMYiAt6cg3peEnlss+v/zyvI1knSs2NNM6VQyKJh0u8GTtnJJd03bsfK2LLfdmwyJAe6dYxhHH6rUh0FsetQlx6VryHoVWqlUan3g54J7grPzIXWLSvWfNZrcIUpgFiAKBqWvP9iQcwwE9+BBXJdPv2XK3NwcL1g+W6JvKoKupBbgYfvgvIBhdtI5UZgCW0sxbrn1Tf+JHbqsrWv8k0H4sjyfEdjbeP1sw1G+ZXmwdBCkVyhHz9RnSInQqQWM/nItJkZM5emuz9jz87MCjQh6TSrjxttTm1cpFNj0kfAPClJIVrq65RGmmJV/hQl5IhkgUVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ylhPBn0aGTmRvTfH0JHtAIj7AzMi3dvEcsyCPPWGOwk=; b=O5Lkv7WM7ddamwJgqfqKc/xaTFyDCwc9LZAtVbu2Bpo8cls3coo/wJ7G7pFAGqbXVG6+tOD3j4Bb8hCcWlIrXnnflYafREL7bKIEM5XeGfh1GlOeQMi465Vu2BL1KRleUwwK2Cppwesi2Wp2P8vldGatC8CPuQpr/Cyb/oD3llUgRFpTZtI2lHEAaXwq9otnppu7SqxQ952s9x7JoylmOyNouW9cdNTZSJ8XyJk3D/80RKRMv2O9R2/h2fzBQfAQfgDODs6vxz3Myt4QlqYPIR+GO3HSVBIs5X4aq85vGAVG19d5fuwV63F9tL7XR/zrvNBdoWm2f8VsLLID0CA3SQ== 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=ylhPBn0aGTmRvTfH0JHtAIj7AzMi3dvEcsyCPPWGOwk=; b=Fx6VnuKxiHq3VI1Jpc/tWG5Dkh5991EiJWYJXEnHtAjOY68BzOdb0kQA/F07FzRK6N6LQWmFcAxBo6vRwPY6aS2V5oDKd7CItcv79ZmTJLC/Tp9Kby52oO/nMOThYv3yh7xUsHQH1iX06pR/8NlHlpiqoncVC2CFaxQpnrml0sE= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: Fri, 23 Jan 2026 17:24:31 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/4] PCI: determine whether a device has extended config space 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: <58091dc1-7bda-4536-8200-2d0a5679d4d1@suse.com> Content-Language: en-US From: Stewart Hildebrand In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWH0EPF000989E8:EE_|CH3PR12MB8878:EE_ X-MS-Office365-Filtering-Correlation-Id: 48694834-d758-4c61-747c-08de5ace3018 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?ZHJRemZtSW9XMkQ1ZWVtdThVY1BIdHRvWVJEU2NZaEdQWEFvRSsxK1h4R2x0?= =?utf-8?B?bnpoR0dpUWhmVkpVNWhzRFJNZ0RzanlvNUdJa3JWWU0zWnJkMEtlN3loTTl4?= =?utf-8?B?U1FDY053NzlNUldoYXY3dFJJT0FuVVREbGh2ZHZ2UE9jamNvelBQenk4dUZq?= =?utf-8?B?L01BVTErY2R1ZC9aeVRybnVOWmF2OHJkM0pCQjcyaTVzbjduQU9tQmZtbEFQ?= =?utf-8?B?Y3M5U0ZTZ0QrbVl5WnlnSktJcjF4YTVjc1pxbysxeWhkS1ZWMlFSYTFDSTBv?= =?utf-8?B?WndSemJSVXFqYzBHcXVZbGQrT05LRTZMK1crY2JMRjJzMVBYL0I1cXFIbXdr?= =?utf-8?B?VldMUG0yTzZqbjVHYTNidGtJalpGV1R6TVdLcVNLMWFoNnIxVGxVNUlMTnB3?= =?utf-8?B?MlhycnI2UHJDNmVhUFhqSWxsZWsxVkZ4UnpnaERsWWFBRDJTaytGWXVyK0VU?= =?utf-8?B?Y1dvS21SNnplazZIZHdKaVF0RkZDSTlDNDQ0QmpVRTd6aWg2ZFprL3kxSUNO?= =?utf-8?B?bGhiMzZlbW9NS0c0cjdTUlFwbXJaWW1KYlBsdmx2RjhhVEdNdm9TeDRKQko3?= =?utf-8?B?dUJDL1J2bitoRm1tN1ZjSC9XRy9RVlRpVWxuaERTRFdRbmxhK3F0QWZ5SzF1?= =?utf-8?B?S0xYUjZlaENyc0xSdzczTHRrM2M5Wm1Qc25ocmV1MDMxNERiaExsTzBVRVJR?= =?utf-8?B?VHI2aUExc0RGeWVZMWk1dEo2SzFSWTB2d1VwOVFWcTBSRE5TUFgvQ1hkR2ll?= =?utf-8?B?amlGWTdhLzZKd1JhcDVoUVNMa1IxSXJMTjc5SHliejI1YWNPVjkxTm1aNExh?= =?utf-8?B?YVZiZkgxYStFYzdGaHNJNnVWSmdGdC9UR1BueXRsZVFxMm9YSE5oQ1hYZEJm?= =?utf-8?B?aTFXcEhxVFNIK05JY2t0eWNXc2FxdEVPa2pCRHhnKzZJbjhZaTlVa2UxWnAr?= =?utf-8?B?OUVHY3RDdHBER25NMG1POGR6TVgwOVhDa3FtS3VYQVY3cnc1V1pZQUkrZmpB?= =?utf-8?B?K1lSL2RBREZxWHZORXRNYzlpbUhvOTZqRkY3NnpsTTdEcmRFNUdDSVozeVFY?= =?utf-8?B?WXRIVkQzWUpIQ25FT0Y4ZGtKalJyaTBJeHFlZzVINmgvdHNERnVUTHRZelox?= =?utf-8?B?VU40TGtkd0Z2ZFRuaTdLRmQ1QUJQaGwrditiUkFPVldac1piSUFaK0pJdUU1?= =?utf-8?B?RUJibTMvcngxSjBGZlVqQ3VjUnhtNWZlRkFXUTBkenhRMVg5cDdGMnNvQVV1?= =?utf-8?B?OG1vUDhmYlF0V0thUUFLbktmZFpiM09Pc1JvaExMQVhHSGg4bCszUFV3clVS?= =?utf-8?B?enpEVVhQMHhnRTljNnB1cGVxZjd4d09DMU1UUnloT3Axdmg1SDJ4b0xnQXQ4?= =?utf-8?B?L1pmaFB5elkwMmxhYmZLYyt0OWd2bXZKUS80VGhqdTcyN3Qxall4V2VRTTJy?= =?utf-8?B?M09hbVVKQUVJRmsxWXozZmtGbXRNQjdJTHJwOHRSanR6eHFmcUoyY1M0NldQ?= =?utf-8?B?VWxnOTUxRko4VnNEanhvVVliSGFoTGFWZDlQL2UwQzMydmRJSmp6SGZQd0Zl?= =?utf-8?B?eDNxQkM3dndoWnJkcE9sUTF4NEtsSWdFT0dtMGUwbXNjMWVNWDRKb3BEdDBH?= =?utf-8?B?Q05xc1B4TFAycjExRmg2QVNCaXZrdVVpQUUvT2g3d3RGeERMbzMrNjY3aFgx?= =?utf-8?B?aVpXOE1KUHQyc3FqWnJZenI3RVRXZkNrUUtQV25IbEtHSEgzMzNZZktOQmdl?= =?utf-8?B?VVg5OVI0Z245QU85akhiVkZRYnRVM1JJSXp0emVzVWNkQk1lN21yZm5mMkp0?= =?utf-8?B?U1hlNzJMMmxnOFBCMi9IMkM2SEQrZlZHOE9OTk0wN1JFU0tnSUhvZ1M0emc3?= =?utf-8?B?R1lCSzhWNlNCVHozZ1JBQy9namNZaXhyZG1YSDNEQk1ybEpPM2ZFZGUzeWdU?= =?utf-8?B?S0lUeUhlcXFxTHJxdWlwTG1SVm16UEdGRkEzbGkxMlVScDg5ZkdRWEFmczdO?= =?utf-8?B?WXdJT25IR1kvOW9sT0IwZjFNQlcrd2lOS295TzRQOEg5bTBTL0tEY0xMUTFo?= =?utf-8?B?bkw3aHIzZXJQSmEzSTk5T05KZXFrZU9tZGpScldnQ1JxY3RsVTloWnZTYW50?= =?utf-8?B?WjYwZG9jcXNaSjNlNkdBM2x4QzRnS2xDWmxMVHVjMys2RDg1REgrSGlEa0dw?= =?utf-8?B?RG5NRGszSjBSNG9qU21qSlFDN2tLZFRuOFJzZ3haYW5LeVRTemRhK3VEN00v?= =?utf-8?B?Z1lacThGZjRWOVNxcWk2ZmcrQmdBPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2026 22:24:34.8530 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 48694834-d758-4c61-747c-08de5ace3018 X-MS-Exchange-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: MWH0EPF000989E8.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8878 On 1/19/26 09:46, Jan Beulich wrote: > Legacy PCI devices don't have any extended config space. Reading any part > thereof may return all ones or other arbitrary data, e.g. in some cases > base config space contents repeatedly. > > Logic follows Linux 6.19-rc's pci_cfg_space_size(), albeit leveraging our > determination of device type; in particular some comments are taken > verbatim from there. > > Signed-off-by: Jan Beulich Reviewed-by: Stewart Hildebrand > --- > Should we skip re-evaluation when pci_mmcfg_arch_enable() takes its early > exit path? I don't have a strong opinion here, though I'm leaning toward it's OK as is. > > The warning near the bottom of pci_check_extcfg() may be issued multiple > times for a single device now. Should we try to avoid that? If I'm reading Linux drivers/xen/pci.c correctly, my understanding is that dom0 will only invoke PHYSDEVOP_pci_mmcfg_reserved once per mmcfg segment, so in practice it's unlikely to spam. In other words, I think it's OK as is. > > Note that no vPCI adjustments are done here, but they're going to be > needed: Whatever requires extended capabilities will need re- > evaluating / newly establishing / tearing down in case an invocation of > PHYSDEVOP_pci_mmcfg_reserved alters global state. Agreed. The current patch is prerequisite for this work. Hm, perhaps we could create a gitlab ticket for it? From xen-devel-bounces@lists.xenproject.org Fri Jan 23 22:36:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 22:36:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212597.1523635 (Exim 4.92) (envelope-from ) id 1vjPl3-0004Mq-8a; Fri, 23 Jan 2026 22:36:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212597.1523635; Fri, 23 Jan 2026 22:36: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 1vjPl3-0004Mj-47; Fri, 23 Jan 2026 22:36:01 +0000 Received: by outflank-mailman (input) for mailman id 1212597; Fri, 23 Jan 2026 22:35: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 1vjPl1-0004Md-F1 for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 22:35:59 +0000 Received: from CH1PR05CU001.outbound.protection.outlook.com (mail-northcentralusazlp170100001.outbound.protection.outlook.com [2a01:111:f403:c105::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e23e5aab-f8ab-11f0-b15f-2bf370ae4941; Fri, 23 Jan 2026 23:35:57 +0100 (CET) Received: from PH5P220CA0001.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:34a::8) by DM3PR12MB9327.namprd12.prod.outlook.com (2603:10b6:0:42::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Fri, 23 Jan 2026 22:35:52 +0000 Received: from SA2PEPF000015C7.namprd03.prod.outlook.com (2603:10b6:510:34a:cafe::8) by PH5P220CA0001.outlook.office365.com (2603:10b6:510:34a::8) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.11 via Frontend Transport; Fri, 23 Jan 2026 22:36:08 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SA2PEPF000015C7.mail.protection.outlook.com (10.167.241.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Fri, 23 Jan 2026 22:35:51 +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; Fri, 23 Jan 2026 16:35:50 -0600 Received: from [172.26.188.28] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Fri, 23 Jan 2026 16:35:50 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e23e5aab-f8ab-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=e5fLhBonaVAK9O9IrI8jnorQ8wO5MYwkq5E5x06xvM7msH3jTMtI8hUNNyuBsqiuG7YMje/H43ZmCLT0lE9JFqEB+aTzxLSNeltzb7AXm+sbPtZpZfHwn+I8ws+roJjBBekjf5XRGnBQctkaMbbjVvLZlsBLkQOEC3XxJhXf1kdnL7OK1SZg/eLGVcy5f7N+YZfxkg6NDeFh4e+RqaKJJdqyPx+XPctnH+0dJsNx46P38zfTMqPt2sFlr4niKyaPZgX61ssrVGYDIdhms5uCo5MOTjUejkOJpKu6+vYsbXFSM1ppPR0Q4PqKPys7ipkjeOMqZQUITj2xabBhcYxfrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GgmufgnGgUDOr6k/GE5Xoz17xtg6jzpb8FjFlHU/IJ0=; b=Sm3xjO59nJETe31eY/x/I0gVgwfgvR87kYowU280h93ZR39IzWv49Q/0jTEexWa5/8rOiq7htrsYmdRHuOXpF2KVBYY4mKoOywcc+tMhZ7bVb/9fLee2qyBTKXPeKUXRACCHFUvATyFQokd1qssLZp5QJTLceBmbw+LyKtXDbG1H9u1PrMhDy6a+YJnqpFmzkiTTr378qUmvnBFSWIJ3t1drBth71g1iVEOs5Em1frBN84LfcYf1kJY+Hsz9qgPo/ra92BYaYbIaxB6vWKm53vdaYxclfWX97wYQ1vqYAuK5hptosgtMGfyVPQukY8vHKv9fHfJHC3WwpbyPmn/EcA== 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=GgmufgnGgUDOr6k/GE5Xoz17xtg6jzpb8FjFlHU/IJ0=; b=Keu5GSVoj93NktbF/93FeFRmX3NKGFT4dzjyAoFtxdx4K7n8aOnYozPkhSrb5/xHgNGF4C0mb9WsR/d2tw7qGIrydPxBI0qlKbSqkGbTclZ/dvAtSxIiqCJHhjiNykTK/0fzdNqprfOykIhjMfSDP7NEynoIJ1z8dUxSthk9Kqk= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <26ef0e68-efca-4b9a-a210-76b5426da130@amd.com> Date: Fri, 23 Jan 2026 17:35:49 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/5] cpufreq/hwp: move driver data into policy To: Jan Beulich , "xen-devel@lists.xenproject.org" CC: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <8441ada5-e2ed-4d79-822c-ecf1ce3c9484@suse.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <8441ada5-e2ed-4d79-822c-ecf1ce3c9484@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: SA2PEPF000015C7:EE_|DM3PR12MB9327:EE_ X-MS-Office365-Filtering-Correlation-Id: 2c80c7e4-5e57-4921-9bd8-08de5acfc337 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?RnBpN0xuZTlmOUtTREs4UElWMkxtK3pTMTBrVENJRWltaldMRjFmdnRtUUN4?= =?utf-8?B?dFhyTGJRT09kMnh5QldsMlRXZ0p2bkYyaWl2NFplN2M5RDZPK1FvLzJRdTRy?= =?utf-8?B?T2psaTlxcjVqSFd3bU9lWW0wcTQ3bmRsL1pvd3JKNERiNjJJczJHZVhjQ2Jt?= =?utf-8?B?cEpZWXpibWhycm13OWowNzFVNm1ka1VydnByVXRRMmlIVkUrS0pQVWFWbGJW?= =?utf-8?B?cXExMkxIbE8weVlwK2x1cUZWN2tvSlVxUExFSW9NR29OWkU3a0Y2cmdLbGVG?= =?utf-8?B?NVhSN1pWd1JPOVZuaVBGc284TktZc29lUk1KZTE5N0xsWkNEQzNEak1aT0lW?= =?utf-8?B?MWVCQkNKNmJMS21laklnNmJRZG1YSFBRVnNuWENidSszbEYyT2tPMG1lKzhP?= =?utf-8?B?Y3dYdnZoUVBGUS9SSWhXZE9vUHB4MFQyMlJ4SWdtYnhXR3VqTnFSaHNidEtI?= =?utf-8?B?TDNNZld3ZUhtcjFjQnhJcFp3Rm1uSXJ2TnNBNm16N2NFenVyb2pzUkIwTEk2?= =?utf-8?B?VDJtYjJnQzhGaHVpMW4relF2TGdiVjhObWFzd2ZVd0JVdTZZUHIxNE5xYUlq?= =?utf-8?B?SXZFZFRzMDZINThleVk3Yk1YQTZlbTFaMFRsTUdIbE15NXdxT2kwbHN6TWg2?= =?utf-8?B?SDZmTXVZWkI5RXRtZlp6OHFIUUsrekNOYjV6dTRxeXMvcFROWkgwdFlQdmdZ?= =?utf-8?B?WFRNeFpGTnR2aHBKMm5aZS9OM1YzVWtiU1F1a1hDRk81NEpZLzFtcHFlanFn?= =?utf-8?B?N1JSenBYbURqN1l6SHk1YkhxQXRTQVZiVExLUVpHYWpFVXJkM29BV3lMYXNZ?= =?utf-8?B?R2x0SHhULzI2WFhnUDNBd0FNd3RuVnhKUDJLWUJRWGROTHpzZXIrM0hEK1FK?= =?utf-8?B?VWE2NmNVaWVDQ0p6ZS96YmltYmQ5dThTVjlyam9xWlEzK29rclZVcm9HSzI0?= =?utf-8?B?TGl3K2wvdERzZDZmQkswYU1zMUYxWkwyZTZxaVR3Yk96YnFMZ2laN2lJYWhX?= =?utf-8?B?dmgwMTB6QmEyaFBhN1pJOTlMdDFVbmJucDRZV0NlM1oyRXJQSmtCK0kwOFpQ?= =?utf-8?B?L1paOTgrVVpvSGhadGJBU1FpOWJzMHI2TXgvMFVmN2liN0tLTzh1OEg4OHpY?= =?utf-8?B?cWdxc21QQVNFM0lvS2F1V2VNRE85T3MxZ3lhd0FqazJUWjVEU0VHM0dSZXdv?= =?utf-8?B?UWJtcitJdU85b3lyNEhTd1VZZUhJU3A0dWVDTXBvNTJKcjZyK3VteXZjZmV3?= =?utf-8?B?OFpxM0lwYnVheCtoRDdrVDlVRzNlNmRUSWhCQmdpZEk5amJabytoRHJyRk1C?= =?utf-8?B?SGk5YmhSK2Z5UXk4QnZ2NUpDd0xnVWNhWk5EQnFSU1g0eDJTdC82bVV1NldN?= =?utf-8?B?YjZudzZrakovYk9JL1NBTkR5c0pvSjRwR2s1dnErQVpZTFNTMmdJYSt3cVkw?= =?utf-8?B?bUlwdG5RUTN6dDNLQ1BHWndVVWZWck9SWGdOd1hKSlNZQTk2aC9pdmowY2xG?= =?utf-8?B?ZlZUaXRTc0tqakFFUFJ2Um1tU3B3RzVPTEszWmFvTGJ6VEZ5c0pWM0kweTFn?= =?utf-8?B?RkNGdEpTQjJaMHVjTEtWOVloT2g5bUdVTHRTK3NQVjBwUVpuR2RTRjV2WWdk?= =?utf-8?B?NzBYNzlSWXplL216TmhCY1pxMW1tYS9DQTU1QlgwNWNvOFFTU2lpN0I5RkNL?= =?utf-8?B?Z2IvTk1oTWV6OFdiTVREa1BFVmZNZkdLZ2NhdjhVNS95bnIzdGRSU1RxR2xM?= =?utf-8?B?QzRBVFprL1l4UFY1L2N0cjFNdUlKUDlPbVpRSGlBMjZyaXN6ZlFCUTJMbGpV?= =?utf-8?B?S2FKVlM2RDFDZzZHSk9hNEIxRzRXaW8yTXNVc0VVWS9WY3R0bnRXVmtwcDZP?= =?utf-8?B?NGFST3ZiQlJiSkkwbUtGNmt1UzRmSEZPRjlRdTdoQXh6VVlaNEFwMUZRd0JG?= =?utf-8?B?L0pOL2o5cXNHRm94MjBhTFVvUmRSOEZaSFFteXlNdXVXOEdpU08rOVNvZDkx?= =?utf-8?B?cGtEM1JYR2dzMWQyUUhQbUlrMzdheGdFY2Z6cFJ5TVRscG5tR3p0SHQ1d01O?= =?utf-8?B?ZDVqNDVxWWdZb2hMTC83YzZmL0dmZzIrNS95a0tXWU1kd2t5TTQrZFRSNjF4?= =?utf-8?B?Q2VkVDZaWXArOFlpQXVwa2FhMS9raU1XTmV1SWszY2tGS0U0eTZRMWswdWJV?= =?utf-8?B?S1pLUTNxWXBiWXF3dDBOWnJBdEg0MXZQSXU4VUwzaENiTFpvN1NJRHFnMXZ2?= =?utf-8?B?Uy9idU5WeS8rRjdMWlh2eWUzS0dRPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(1800799024)(82310400026)(36860700013)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2026 22:35:51.2501 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2c80c7e4-5e57-4921-9bd8-08de5acfc337 X-MS-Exchange-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: SA2PEPF000015C7.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR12MB9327 On 2026-01-22 04:42, Jan Beulich wrote: > Share space with the ACPI and powernow drivers, avoiding a separate > allocation for each CPU. Except for get_hwp_para() all use sites already > have the policy available, and this one function can simply be brought > closer to its sibling set_hwp_para(). Minor, but maybe 's/function/function's signature/'. The original phrasing made me think it was code movement. > > This then also eliminates the concern over hwp_cpufreq_cpu_init() being > called for all CPUs We expect hwp_cpufreq_cpu_init() to be called for each CPU, so I am confused by this statement. The data... >, or a CPU going offline that's recorded in> policy->cpu (which would result in accesses of per-CPU data of offline > CPUs). > > Signed-off-by: Jan Beulich > --- > hwp_cpufreq_target() still requires policy->cpu to be online, though. > > --- a/xen/arch/x86/acpi/cpufreq/hwp.c > +++ b/xen/arch/x86/acpi/cpufreq/hwp.c > -static DEFINE_PER_CPU_READ_MOSTLY(struct hwp_drv_data *, hwp_drv_data); ... here is tracked and filled per-CPU. Do we need cpufreq_add_cpu() to force hw_all = 1 for HWP (and maybe AMD-CPPC) to ensure that policy is allocated per-CPU? Are we implicitly relying on shared_type == CPUFREQ_SHARED_TYPE_HW to do that for us? The code here is okay, fwiw. Thanks, Jason From xen-devel-bounces@lists.xenproject.org Fri Jan 23 22:48:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 23 Jan 2026 22:48:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212610.1523644 (Exim 4.92) (envelope-from ) id 1vjPxR-0006F3-D6; Fri, 23 Jan 2026 22:48:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212610.1523644; Fri, 23 Jan 2026 22:48: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 1vjPxR-0006Ew-AT; Fri, 23 Jan 2026 22:48:49 +0000 Received: by outflank-mailman (input) for mailman id 1212610; Fri, 23 Jan 2026 22:48: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 1vjPxQ-0006E4-5H for xen-devel@lists.xenproject.org; Fri, 23 Jan 2026 22:48:48 +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 ac4d684c-f8ad-11f0-b15f-2bf370ae4941; Fri, 23 Jan 2026 23:48:46 +0100 (CET) Received: from SN7PR04CA0008.namprd04.prod.outlook.com (2603:10b6:806:f2::13) by MW4PR12MB7119.namprd12.prod.outlook.com (2603:10b6:303:220::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Fri, 23 Jan 2026 22:48:41 +0000 Received: from SA2PEPF00003F64.namprd04.prod.outlook.com (2603:10b6:806:f2:cafe::ca) by SN7PR04CA0008.outlook.office365.com (2603:10b6:806:f2::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.10 via Frontend Transport; Fri, 23 Jan 2026 22:48:16 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by SA2PEPF00003F64.mail.protection.outlook.com (10.167.248.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Fri, 23 Jan 2026 22:48:40 +0000 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.2562.17; Fri, 23 Jan 2026 16:48:40 -0600 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, 23 Jan 2026 16:48:39 -0600 Received: from [172.26.188.28] (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, 23 Jan 2026 14:48:39 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ac4d684c-f8ad-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xLZnwzI5/vS3iVjxpSS+CztygGl7aohWFoffmnxpUjetvL68TquAPiz+p+sDabZwSUcZrpaFstp8/9HCZiL3QD0DjVtYXPvXb7i7bFkih30nCnehFaVG00eoI2dw559VrG5qWyJyzEXL/hxPplkVemxC5WoTjOXCk1RuqGLciNGL8Vi3FW1YIllA7/YGdpv8f8itCT9LuSMF1hphq4B2cUdEhC3FA4q5pDpNnEMBepDf3JyURoIyG+6Il2TK9Tw+Oa0x0+I10AhEk15uwxDffxO6VZ8703mXGmX5QeN+7IXYrWStpVPWbyPZ/UO3LtKvBmtRywJnBH1Lbe1Ss5tJZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=h8G9XEEUnGfL50viJ1aN/Y+zx4YjlpJ49njkZ496xes=; b=Engh9nCKaeavcxO+/TdGenmQBZiz8iL5CtZgzUJwHGO92oLv5t61jpv+AeVYrbmngm7H7G9LA5XprvTu33f2X1MckPhlaLkiOP1zCYL5JJKKnmUfIHJo3lzj7bwh+8jTaXkj50NOFsChSydlJ1OdeB3kSaSYCCsjQPuh2BL5tTgvzqAb8iNcRgRRSvTXhW+Mx6MliIsHOFEw5qMzzztyR5CWUKZ/IQinrYMohi3rPddkIjBlmIOX4bsDwmwBHc8NYacGN4jkI0nrPpkdkwA8Gb8m6Pgj+vXd65iiuL9VeNwtH/mTzZLIy0im4JPv6hhCskTlWVspKkHYdXBz6h9OWQ== 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=h8G9XEEUnGfL50viJ1aN/Y+zx4YjlpJ49njkZ496xes=; b=h/bvATl80uuo1sv0+ZQ2MBnUuzYwXD0LMDuxwmMRlp0NAuidLvvrVGJJYFiqoDEbmUcLEbAWtMrtQczdsLU+Fh9iPLoCKBcTpUPrrHYIFaRnRldLKYJneGMR7HyGxsVq/CqYwUcg/lH7j5w5S/YwwYeqyhq5ThGBGS83IIK3M8Q= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <601a1280-6d06-4b12-a89f-9d205a36f4e4@amd.com> Date: Fri, 23 Jan 2026 17:48:38 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] cpufreq: eliminate cpufreq_drv_data[] To: Jan Beulich , "xen-devel@lists.xenproject.org" CC: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: Content-Language: en-US From: Jason Andryuk In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: None (SATLEXMB04.amd.com: jason.andryuk@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA2PEPF00003F64:EE_|MW4PR12MB7119:EE_ X-MS-Office365-Filtering-Correlation-Id: 03d80831-d984-4e2d-7876-08de5ad18dae 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?cmpoaVo5YUFBVEVMSDRsTEROd1Z5OEhtbFRSUHRHWTdYODFzbHVHcnhUenFx?= =?utf-8?B?Vkhkby9jZjRONzEra24rRzBjMFBtT1REQktyeEtvTDhLUUJLWUFob0gvT3lE?= =?utf-8?B?OVJDaTByYWp1WEF1dEQxNG5XTFhDU3hEdm05U2xBbjlVL0YzamE1UjNYMXEv?= =?utf-8?B?WlFGanB1ekt4enFsdjcvZVpkTFE2K3kzZlA0bCtoUjkwY0JHTzMyUDFpSmta?= =?utf-8?B?Y0xYRy9IbE9VMXNyZEQycFBDVUtmYTIxRFNXUlROTlNBdjlTbDc2elE5bmNv?= =?utf-8?B?THN4cEUzR1FBVXlBZ1NqcUUxeUxRdkZEMzJwSG9ITmpwVnN3Rm5lT0ZMOXl5?= =?utf-8?B?K1hhek9ibmoxZ2JRdC9adTQwU2V6UEdWMzZ4NGZReGZSdGlmVXpVLy90UDlW?= =?utf-8?B?bWwrdURweHNhYmpldHJMeExBSDN1SFY2S2dsdEF0ZUhFUGN0NGRiYlI3cUc3?= =?utf-8?B?ck0yVyttRTJVMWFTUHZLRUkySWgwakp4S1h0OFRxQVZ5em42QnJLVkJNVnMr?= =?utf-8?B?UzVuTmY1QStkSXRScGxMd2kyVzlXbUx3blBpeGI2dFU2OHQ3SjlyNlZYNmVK?= =?utf-8?B?YllYQ1lmN2dBNDVCdGdqcEFWWGdkTWpYTXdVajluS3BkRytFRzFNNnkrc0Ro?= =?utf-8?B?emd2blo2eFdpYWFCWklsWkpMUXIrVmtJK2U5Z1dKY3ZndDV1K3R5QlFQU0xq?= =?utf-8?B?eDJBeFd1eUpheXU5NDA0OUZYVXRmbDFaQkpxaEhLYnhBSC9nazBmSzRoT3pr?= =?utf-8?B?c3dNR0RJZDRuZHp5M0U2WEg2QXFFVU8vK0IzeWxXa1hscjViOXppM0FRNG5B?= =?utf-8?B?TnpIbGx4RjAwV29PTUoxUk9VeDNqaXp5dUIyc2ZTcG5WOGFEcGtZMHpSNFJl?= =?utf-8?B?aEtBL0VDbWlsTHFYajlDS05kR09Mb1kxZEh3RTVuVWZFSTlJQ3F6NTIwWmVl?= =?utf-8?B?Vk1jbUJpK29mUHozbzFGZTQrL2hEVC8vaFJ2VkdhYjRqeHAramJ6NnI3cS8r?= =?utf-8?B?cFN1dGwyVUlHajhIdjBUUDdVOGFVeTlSVkxWbmN5bmpGcWlwb2pBemZXa3Qw?= =?utf-8?B?NlErRXVSN1QzUEs0eDVRSUU5TC9KZVo4YXRyZGl6dTRwWVBBTEd4RTI2bGNF?= =?utf-8?B?MkNQanQ0RklqcHBMNTRvdWFGTWhESzI3NHFvYmZXQTJ1NFVmRDhKT25pV2Rt?= =?utf-8?B?Z1Y3TC9xZVNqUndnUHBoeDZiSHJWSU9GRHBkcUVxZmZCc0ZUVEdtd0c4TUl3?= =?utf-8?B?dFQ5U3g5MFBUT0VmalpYMjducURTZlkzNkswNkszSldWc2pOZ0I3OW9RdVhq?= =?utf-8?B?NVNjV2hxRGF5d2FHTTg5bFVTZUlvTG9LS2lTUVI1OEtKYko0N1ZYek8wZjVN?= =?utf-8?B?VWE2VHlEMnRGc1JEVUhWYi9HZXprK28zYVM4UUpGZkNwc0FuOTNqNzZwUng2?= =?utf-8?B?SzEwamFFb1JMYlVWSEhVbG1sTnR1MXNFQlM4R29GSlhObkFsMngvTzlqd3VJ?= =?utf-8?B?ak96YlhuLzRhMnNCeXhtT0V2b1dLZzJCQUtvZXRZN0R4Q08zeS9JZU1zaTNI?= =?utf-8?B?aExmVmw4Y2NNYTdSZERMYnBINTJTcmUwRlhuMTNQdkRoa09YN2lIVFZKTFhk?= =?utf-8?B?dEtIc0tzRytKOEJoUm9oUVJRZ05tTXFMRTJUT0FVZ1o0NXBEaGlIaGkwT3Vx?= =?utf-8?B?bkFaYVAzYTBPbXRLN2JtWlpiMlh0aDFWNHlCYTZXZGMranJnelpPRlBPL2Fr?= =?utf-8?B?Vkhrb3pndCtZdUFNMDN3Rmx3STc0ZkdtdFZERU9FMjNYZXBRd1VpdnBDL3FY?= =?utf-8?B?UXZBbUpab1JaNmtDV0Z3amNhVzY1WWRVazh5VlljTFlkUExKR2NHZzdiclJn?= =?utf-8?B?bVl4NTNQczlBMXp1WENqVGR5YnNONFBYa25tRDZNbGI2QmNZdzZlZGkwazB5?= =?utf-8?B?ZXZ6TGN6d1UzSGczMVhUek5rV3VVemxEN2VOcEswK2crRFl5eWtzbjd4NDVo?= =?utf-8?B?ZmNmbThiVlNvY2U0L3UvaVBQRmhveE9MYWhmRDU4a1E5b1pJRWsydEtPOU8y?= =?utf-8?B?WFg5TzJnMU4raTNtRVZwQ0wwSkE5blNmeVVpTG5PbDB4YmVYRldYNnRXb0xH?= =?utf-8?B?YVgzdGVBUHNkWXRja1FPUTNjbnRLQXlyYm1mYzA5WWNiWTZlUW03WnhqOWp5?= =?utf-8?B?dTZhK0dSbzN2bHRLL1MzZ1NraTlmS0VuZXNISnZWeWZkUi9TclMwcWlMb3RN?= =?utf-8?B?TXhSdGQ0azVwL0xBNHY0SlQ1ZnJBPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2026 22:48:40.4257 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 03d80831-d984-4e2d-7876-08de5ad18dae X-MS-Exchange-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: SA2PEPF00003F64.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7119 On 2026-01-22 04:42, Jan Beulich wrote: > Possibly many slots of it may be unused (all of them when the HWP or CPPC > drivers are in use), as it's always strictly associated with the CPU > recorded in a policy (irrespective of that CPU intermediately being taken > offline). It is shared by all CPUs sharing a policy. We could therefore > put the respective pointers in struct cpufreq_policy, but even that level > of indirection is pointless. Embed the driver data structure directly in > the policy one. > > Signed-off-by: Jan Beulich Reviewed-by: Jason Andryuk From xen-devel-bounces@lists.xenproject.org Sat Jan 24 00:31:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 24 Jan 2026 00:31:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212632.1523660 (Exim 4.92) (envelope-from ) id 1vjRYR-0002fD-QF; Sat, 24 Jan 2026 00:31:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212632.1523660; Sat, 24 Jan 2026 00:31:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjRYR-0002eZ-JX; Sat, 24 Jan 2026 00:31:07 +0000 Received: by outflank-mailman (input) for mailman id 1212632; Sat, 24 Jan 2026 00:31:06 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjRYQ-0002cv-2j for xen-devel@lists.xenproject.org; Sat, 24 Jan 2026 00:31:06 +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 f2cc79d0-f8bb-11f0-b15f-2bf370ae4941; Sat, 24 Jan 2026 01:30:57 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 1DE79600C4; Sat, 24 Jan 2026 00:30:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 582EDC4CEF1; Sat, 24 Jan 2026 00:30: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: f2cc79d0-f8bb-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769214655; bh=6+EID+jpqyS88jteoAReQSQgKzDQr2KnKDmHgoC7Ubs=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=MVQZh4qlCXnyf7aATJ4cNXAXTkRLZ5szBSXJwTICzetDXzh6n6/ri+HKexFqIJnfH +dtXx0id28ZkIW76KsiGlPn0zfJHjStDS49avTNpGsWhIcVox0Y06IRe7ci3tzwxSI 87sqvb9mVGEjEMPhhZdY9kJ/JqtoFB7YJLCGCwxv7wH9FivAFPmaWGVR/9OWVxwru+ LA8lAFcAdA0PLMwsmxTPoU19wdKt5rjGqiVLfNCob9vCDMjkpzCcVua6T6GoKMQ6fz NVqc19Tk2zZnefxruQ8ZIjE7vQOri/JYbSbMRLIGBusJyOwvoCbSMMlLQexiZ1kXIp Z2aK7aw8GVRKg== Date: Fri, 23 Jan 2026 16:30:52 -0800 (PST) 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 v1 2/4] scripts/config: drop modules support In-Reply-To: <20260116043458.730728-3-dmukhin@ford.com> Message-ID: References: <20260116043458.730728-1-dmukhin@ford.com> <20260116043458.730728-3-dmukhin@ford.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Thu, 15 Jan 2026, dmukhin@xen.org wrote: > From: Denis Mukhin > > Drop the --module (-m) and --module-after (-M) options, as Xen > does not support loadable modules, so options are not applicable. > > Signed-off-by: Denis Mukhin Reviewed-by: Stefano Stabellini > --- > xen/scripts/config | 11 ----------- > 1 file changed, 11 deletions(-) > > diff --git a/xen/scripts/config b/xen/scripts/config > index ea475c07de28..1050812aae8d 100755 > --- a/xen/scripts/config > +++ b/xen/scripts/config > @@ -18,7 +18,6 @@ $myname options command ... > commands: > --enable|-e option Enable option > --disable|-d option Disable option > - --module|-m option Turn option into a module > --set-str option string > Set option to "string" > --set-val option value > @@ -30,8 +29,6 @@ commands: > Enable option directly after other option > --disable-after|-D beforeopt option > Disable option directly after other option > - --module-after|-M beforeopt option > - Turn option into module directly after other option > --refresh Refresh the config using old settings > > commands can be repeated multiple times > @@ -177,10 +174,6 @@ while [ "$1" != "" ] ; do > set_var "${CONFIG_}$ARG" "# ${CONFIG_}$ARG is not set" > ;; > > - --module|-m) > - set_var "${CONFIG_}$ARG" "${CONFIG_}$ARG=m" > - ;; > - > --set-str) > # sed swallows one level of escaping, so we need double-escaping > set_var "${CONFIG_}$ARG" "${CONFIG_}$ARG=\"${1//\"/\\\\\"}\"" > @@ -220,10 +213,6 @@ while [ "$1" != "" ] ; do > set_var "${CONFIG_}$B" "# ${CONFIG_}$B is not set" "${CONFIG_}$A" > ;; > > - --module-after|-M) > - set_var "${CONFIG_}$B" "${CONFIG_}$B=m" "${CONFIG_}$A" > - ;; > - > --refresh) > yes "" | make oldconfig KCONFIG_CONFIG=$FN > ;; > -- > 2.52.0 > From xen-devel-bounces@lists.xenproject.org Sat Jan 24 00:31:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 24 Jan 2026 00:31:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212631.1523654 (Exim 4.92) (envelope-from ) id 1vjRYR-0002dD-GR; Sat, 24 Jan 2026 00:31:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212631.1523654; Sat, 24 Jan 2026 00:31:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjRYR-0002d6-Dl; Sat, 24 Jan 2026 00:31:07 +0000 Received: by outflank-mailman (input) for mailman id 1212631; Sat, 24 Jan 2026 00:31: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 1vjRYP-0002cu-Ob for xen-devel@lists.xenproject.org; Sat, 24 Jan 2026 00:31: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 eef91d1e-f8bb-11f0-9ccf-f158ae23cfc8; Sat, 24 Jan 2026 01:30:50 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 5527160053; Sat, 24 Jan 2026 00:30:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D0211C4CEF1; Sat, 24 Jan 2026 00:30:47 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: eef91d1e-f8bb-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769214649; bh=PHBz4o2pH81TiLt975csT9TFLJUN4sr7JtZ4Jwxagzg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Vpesb32EXCuito7D56ZR33K1S7szg7oxr1S0ZcEItY+COE1nOox1zdnMLRFIE/vxz RgcKWDss4Vlk0ovJhdMmMyOos210DZfGFP0AHzuHNSqAS4XVsYOl2sx+TIZMt2mfs3 7mFP0klqPL56nBV35C2OKPGjFqOR0lqcNCuy2mLQphRETTFdq+vb2FJJwUSiM5wFrP YbvCsUZmNsKNvvcYOc9pOLj/MD0tq3E00MRTlKs9ph9PQJP/Ro95I18fGGVcSSSFBF QnFujlcIxJarU8ULGg2n4YVzPlwOx/hL8yaWdzi4ZqynS0qb6Cg7IVNzQb7aeV1R36 U0LYZIPaS5Tyw== Date: Fri, 23 Jan 2026 16:30:46 -0800 (PST) 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 v1 1/4] scripts/config: import Kconfig manipulation tool from Linux In-Reply-To: <20260116043458.730728-2-dmukhin@ford.com> Message-ID: References: <20260116043458.730728-1-dmukhin@ford.com> <20260116043458.730728-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 Thu, 15 Jan 2026, dmukhin@xen.org wrote: > From: Denis Mukhin > > Manipulating Kconfig settings is often required when preparing a custom > Xen build using an external build system (e.g., a Yocto-based workflow). > > Import the Kconfig manipulation tool from the Linux kernel > (commit 0f61b1860cc3, Linux v6.19-rc5) to support this use case. > > Signed-off-by: Denis Mukhin Acked-by: Stefano Stabellini > --- > xen/scripts/config | 236 +++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 236 insertions(+) > create mode 100755 xen/scripts/config > > diff --git a/xen/scripts/config b/xen/scripts/config > new file mode 100755 > index 000000000000..ea475c07de28 > --- /dev/null > +++ b/xen/scripts/config > @@ -0,0 +1,236 @@ > +#!/usr/bin/env bash > +# SPDX-License-Identifier: GPL-2.0 > +# Manipulate options in a .config file from the command line > + > +myname=${0##*/} > + > +# If no prefix forced, use the default CONFIG_ > +CONFIG_="${CONFIG_-CONFIG_}" > + > +# We use an uncommon delimiter for sed substitutions > +SED_DELIM=$(echo -en "\001") > + > +usage() { > + cat >&2 < +Manipulate options in a .config file from the command line. > +Usage: > +$myname options command ... > +commands: > + --enable|-e option Enable option > + --disable|-d option Disable option > + --module|-m option Turn option into a module > + --set-str option string > + Set option to "string" > + --set-val option value > + Set option to value > + --undefine|-u option Undefine option > + --state|-s option Print state of option (n,y,m,undef) > + > + --enable-after|-E beforeopt option > + Enable option directly after other option > + --disable-after|-D beforeopt option > + Disable option directly after other option > + --module-after|-M beforeopt option > + Turn option into module directly after other option > + --refresh Refresh the config using old settings > + > + commands can be repeated multiple times > + > +options: > + --file config-file .config file to change (default .config) > + --keep-case|-k Keep next symbols' case (dont' upper-case it) > + > +$myname doesn't check the validity of the .config file. This is done at next > +make time. > + > +By default, $myname will upper-case the given symbol. Use --keep-case to keep > +the case of all following symbols unchanged. > + > +$myname uses 'CONFIG_' as the default symbol prefix. Set the environment > +variable CONFIG_ to the prefix to use. Eg.: CONFIG_="FOO_" $myname ... > +EOL > + exit 1 > +} > + > +checkarg() { > + ARG="$1" > + if [ "$ARG" = "" ] ; then > + usage > + fi > + case "$ARG" in > + ${CONFIG_}*) > + ARG="${ARG/${CONFIG_}/}" > + ;; > + esac > + if [ "$MUNGE_CASE" = "yes" ] ; then > + ARG="`echo $ARG | tr a-z A-Z`" > + fi > +} > + > +txt_append() { > + local anchor="$1" > + local insert="$2" > + local infile="$3" > + local tmpfile="$infile.swp" > + > + # sed append cmd: 'a\' + newline + text + newline > + cmd="$(printf "a\\%b$insert" "\n")" > + > + sed -e "/$anchor/$cmd" "$infile" >"$tmpfile" > + # replace original file with the edited one > + mv "$tmpfile" "$infile" > +} > + > +txt_subst() { > + local before="$1" > + local after="$2" > + local infile="$3" > + local tmpfile="$infile.swp" > + > + sed -e "s$SED_DELIM$before$SED_DELIM$after$SED_DELIM" "$infile" >"$tmpfile" > + # replace original file with the edited one > + mv "$tmpfile" "$infile" > +} > + > +txt_delete() { > + local text="$1" > + local infile="$2" > + local tmpfile="$infile.swp" > + > + sed -e "/$text/d" "$infile" >"$tmpfile" > + # replace original file with the edited one > + mv "$tmpfile" "$infile" > +} > + > +set_var() { > + local name=$1 new=$2 before=$3 > + > + name_re="^($name=|# $name is not set)" > + before_re="^($before=|# $before is not set)" > + if test -n "$before" && grep -Eq "$before_re" "$FN"; then > + txt_append "^$before=" "$new" "$FN" > + txt_append "^# $before is not set" "$new" "$FN" > + elif grep -Eq "$name_re" "$FN"; then > + txt_subst "^$name=.*" "$new" "$FN" > + txt_subst "^# $name is not set" "$new" "$FN" > + else > + echo "$new" >>"$FN" > + fi > +} > + > +undef_var() { > + local name=$1 > + > + txt_delete "^$name=" "$FN" > + txt_delete "^# $name is not set" "$FN" > +} > + > +FN=.config > +CMDS=() > +while [[ $# -gt 0 ]]; do > + if [ "$1" = "--file" ]; then > + if [ "$2" = "" ]; then > + usage > + fi > + FN="$2" > + shift 2 > + else > + CMDS+=("$1") > + shift > + fi > +done > + > +set -- "${CMDS[@]}" > +if [ "$1" = "" ] ; then > + usage > +fi > + > +MUNGE_CASE=yes > +while [ "$1" != "" ] ; do > + CMD="$1" > + shift > + case "$CMD" in > + --keep-case|-k) > + MUNGE_CASE=no > + continue > + ;; > + --refresh) > + ;; > + --*-after|-E|-D|-M) > + checkarg "$1" > + A=$ARG > + checkarg "$2" > + B=$ARG > + shift 2 > + ;; > + -*) > + checkarg "$1" > + shift > + ;; > + esac > + case "$CMD" in > + --enable|-e) > + set_var "${CONFIG_}$ARG" "${CONFIG_}$ARG=y" > + ;; > + > + --disable|-d) > + set_var "${CONFIG_}$ARG" "# ${CONFIG_}$ARG is not set" > + ;; > + > + --module|-m) > + set_var "${CONFIG_}$ARG" "${CONFIG_}$ARG=m" > + ;; > + > + --set-str) > + # sed swallows one level of escaping, so we need double-escaping > + set_var "${CONFIG_}$ARG" "${CONFIG_}$ARG=\"${1//\"/\\\\\"}\"" > + shift > + ;; > + > + --set-val) > + set_var "${CONFIG_}$ARG" "${CONFIG_}$ARG=$1" > + shift > + ;; > + --undefine|-u) > + undef_var "${CONFIG_}$ARG" > + ;; > + > + --state|-s) > + if grep -q "# ${CONFIG_}$ARG is not set" $FN ; then > + echo n > + else > + V="$(grep "^${CONFIG_}$ARG=" $FN)" > + if [ $? != 0 ] ; then > + echo undef > + else > + V="${V/#${CONFIG_}$ARG=/}" > + V="${V/#\"/}" > + V="${V/%\"/}" > + V="${V//\\\"/\"}" > + echo "${V}" > + fi > + fi > + ;; > + > + --enable-after|-E) > + set_var "${CONFIG_}$B" "${CONFIG_}$B=y" "${CONFIG_}$A" > + ;; > + > + --disable-after|-D) > + set_var "${CONFIG_}$B" "# ${CONFIG_}$B is not set" "${CONFIG_}$A" > + ;; > + > + --module-after|-M) > + set_var "${CONFIG_}$B" "${CONFIG_}$B=m" "${CONFIG_}$A" > + ;; > + > + --refresh) > + yes "" | make oldconfig KCONFIG_CONFIG=$FN > + ;; > + > + *) > + echo "bad command: $CMD" >&2 > + usage > + ;; > + esac > +done > -- > 2.52.0 > From xen-devel-bounces@lists.xenproject.org Sat Jan 24 00:31:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 24 Jan 2026 00:31:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212634.1523674 (Exim 4.92) (envelope-from ) id 1vjRYg-0003EA-0y; Sat, 24 Jan 2026 00:31:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212634.1523674; Sat, 24 Jan 2026 00: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 1vjRYf-0003Dz-Ts; Sat, 24 Jan 2026 00:31:21 +0000 Received: by outflank-mailman (input) for mailman id 1212634; Sat, 24 Jan 2026 00:31:20 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjRYe-0002cu-F8 for xen-devel@lists.xenproject.org; Sat, 24 Jan 2026 00:31: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 fef138d9-f8bb-11f0-9ccf-f158ae23cfc8; Sat, 24 Jan 2026 01:31:17 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 382D643494; Sat, 24 Jan 2026 00:31:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9550FC4CEF1; Sat, 24 Jan 2026 00:31: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: fef138d9-f8bb-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769214676; bh=eV+iTs5JAo2L8emmyYjwyqZdVboesjN+J4LDPH4qRnk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=rOkZraYXDAZqLHhYsEgtkM9g8o2JIGTQEZNRKs6KbhJBVbX49LN9QhlVAdJ0epMAR ehj5kgAYR8XltPrSStt746rP431Go6G7Mz6bo6qZWCYjM9jUeduHgec5xRyRkcc8b/ QpqR3PNuBAIfsKcAqmnNPneWf4rCgxvtDW5+0hq1BKWWJnIVIk5qzjbGn0ZdhZ7/GB O/G+7c9+NabpTG+NPbteDC8/Gl0rgmiJUM7jXLrqcKjMrVgcZZYrE1w4YeDbsLQaxY LB0SQeFhLM1u8dlPW5PHyZ2svxpwAuNQcZ0dtN/7u7gRD7pk5GRxFkg2+SK1eSgxDs E/KZ8qH4eGmXw== Date: Fri, 23 Jan 2026 16:31:13 -0800 (PST) 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 v1 3/4] scripts/config: add -y|-n flags In-Reply-To: <20260116043458.730728-4-dmukhin@ford.com> Message-ID: References: <20260116043458.730728-1-dmukhin@ford.com> <20260116043458.730728-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 Thu, 15 Jan 2026, dmukhin@xen.org wrote: > From: Denis Mukhin > > Add alias -y ("yes") to --enable and -n ("no") to --disable a Kconfig > option for better scripting experience. > > Signed-off-by: Denis Mukhin Reviewed-by: Stefano Stabellini > --- > xen/scripts/config | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/xen/scripts/config b/xen/scripts/config > index 1050812aae8d..1ede964320cf 100755 > --- a/xen/scripts/config > +++ b/xen/scripts/config > @@ -16,8 +16,8 @@ Manipulate options in a .config file from the command line. > Usage: > $myname options command ... > commands: > - --enable|-e option Enable option > - --disable|-d option Disable option > + --enable|-e|-y|--yes option Enable option > + --disable|-d|-n|--no option Disable option > --set-str option string > Set option to "string" > --set-val option value > @@ -166,11 +166,11 @@ while [ "$1" != "" ] ; do > ;; > esac > case "$CMD" in > - --enable|-e) > + --enable|-e|-y|--yes) > set_var "${CONFIG_}$ARG" "${CONFIG_}$ARG=y" > ;; > > - --disable|-d) > + --disable|-d|-n|--no) > set_var "${CONFIG_}$ARG" "# ${CONFIG_}$ARG is not set" > ;; > > -- > 2.52.0 > From xen-devel-bounces@lists.xenproject.org Sat Jan 24 00:32:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 24 Jan 2026 00:32:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212660.1523684 (Exim 4.92) (envelope-from ) id 1vjRZP-00040I-9P; Sat, 24 Jan 2026 00:32:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212660.1523684; Sat, 24 Jan 2026 00:32:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjRZP-00040B-6X; Sat, 24 Jan 2026 00:32:07 +0000 Received: by outflank-mailman (input) for mailman id 1212660; Sat, 24 Jan 2026 00:32:05 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjRZN-0002cv-KP for xen-devel@lists.xenproject.org; Sat, 24 Jan 2026 00:32:05 +0000 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1adce5e6-f8bc-11f0-b15f-2bf370ae4941; Sat, 24 Jan 2026 01:32:04 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 4E1DF44455; Sat, 24 Jan 2026 00:32:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EEB10C19421; Sat, 24 Jan 2026 00:32: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: 1adce5e6-f8bc-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769214723; bh=O//6IAT1yQB0wLqStf9C+ud2gbZNX1Mja19bz1ohzPU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=EOsLqlmTCewj6lWjSpMrVjzJeynDmyjc6amAxfy91UlJsYyxMuxQXbk1bZjehoIRQ XcjLaEbGnfy1LLUqkhpPjMQF8jGUEq02RDL1+fDsjSpX08oUbo2RB6kKfdTEdbRYhl JnOp/IcAZsuG0z+KXkrKVsQbhozm0xXkwnykxv3DG6c4bMRJO47aMrUWcQkcJkweUu yUTgoAZMeSxYKSVMQ4uviYRgj9q4NeLO4XaQ+CxMGqISw+wFnbTK/RUSRwCjPy2ywp 1AfYKl2SgMUUn8h9i3QQJs2i4Bwc3IpQw0EnBv2hvh6WFlgsgo03iQ6Ea4qAAKKqBE 57WZIM/bkGv5w== Date: Fri, 23 Jan 2026 16:32:00 -0800 (PST) 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 v1 4/4] scripts/config: hook to automation build script In-Reply-To: <20260116043458.730728-5-dmukhin@ford.com> Message-ID: References: <20260116043458.730728-1-dmukhin@ford.com> <20260116043458.730728-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 Thu, 15 Jan 2026, dmukhin@xen.org wrote: > From: Denis Mukhin > > Use the new .config manipulation tool to toggle CONFIG_DEBUG in the > Xen automation build script. > > Signed-off-by: Denis Mukhin > --- > automation/scripts/build | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/automation/scripts/build b/automation/scripts/build > index 7a81d229decd..ee1127c53dc5 100755 > --- a/automation/scripts/build > +++ b/automation/scripts/build > @@ -27,7 +27,7 @@ else > # Start off with arch's defconfig > make -C xen defconfig > > - echo "CONFIG_DEBUG=${debug}" >> xen/.config > + xen/scripts/config --file xen/.config -${debug} DEBUG I'd suggest to add: debug="${debug:-n}" before calling xen/scripts/config to avoid errors in case debug is not set I could make the change on commit if you are OK with it > if [[ -n "${EXTRA_XEN_CONFIG}" ]]; then > echo "${EXTRA_XEN_CONFIG}" >> xen/.config > -- > 2.52.0 > From xen-devel-bounces@lists.xenproject.org Sat Jan 24 00:59:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 24 Jan 2026 00:59:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212675.1523694 (Exim 4.92) (envelope-from ) id 1vjS0E-0007Je-CV; Sat, 24 Jan 2026 00:59:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212675.1523694; Sat, 24 Jan 2026 00:59: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 1vjS0E-0007JX-8z; Sat, 24 Jan 2026 00:59:50 +0000 Received: by outflank-mailman (input) for mailman id 1212675; Sat, 24 Jan 2026 00:59: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 1vjS0C-0007JR-PG for xen-devel@lists.xenproject.org; Sat, 24 Jan 2026 00:59: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 f4b2f4b1-f8bf-11f0-9ccf-f158ae23cfc8; Sat, 24 Jan 2026 01:59:38 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 09681600C4; Sat, 24 Jan 2026 00:59:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3785CC4CEF1; Sat, 24 Jan 2026 00:59: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: f4b2f4b1-f8bf-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769216376; bh=Z8+XmR/LBnoaml0EPPZ4/P2K9ONSHL1b8uYPC9VfypQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=pzPb7EXEufzG8ojGBEgG67G8TO6a46VFv6numzCx0mDvDYGdm7kOmfo+IwgYc+Pyv hJfn3XRf+jGtQWjIaiPBDrvyeDRsCWWaLILhuP9lMGJBbGg38RHSaU0xyUFrdmr3IT olAHSuthOLyXAhA9S9dD5VaLn+DGQ0a8P2XPqtQfL4jO51p+moH+n4uTDuDJ0ulJhQ /uzLOtvTD8mYBx7uUhrfnSncIsVs1ye6C4KcGOi4mD44R4gDbZl9j/B0fqDrir8Tgl UTHcb4H4YYwblxDLqiw21dntNzEC8d8HIOckqIf9qeG7KKNb1Kh32JROYfBTgOSfTE guJcqYg9D6CQw== Date: Fri, 23 Jan 2026 16:59:34 -0800 (PST) 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 v2 1/4] tests: fixup domid make fragment In-Reply-To: <20260111041145.553673-2-dmukhin@ford.com> Message-ID: References: <20260111041145.553673-1-dmukhin@ford.com> <20260111041145.553673-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 Sat, 10 Jan 2026, dmukhin@xen.org wrote: > From: Denis Mukhin > > There can be multiple test harnesses per one test target (e.g. harness.h > and harness2.h). Account for that by further parametrizing existing > emit-harness-nested-rule(). > > Add guard against HOSTCC != CC (similarly to how its done in PDX unit test). > > Account for multiple test targets in install and uninstall make targets. > > Introduce CFLAGS dedicated for find-next-bit.c only to avoid contaminating > global CFLAGS. > > Honor mocked hypervisor header over tools/include/xen symlinks. > > Finally, add some clarifications for the functions. > > Amends: 2d5065060710 ("xen/domain: unify domain ID allocation") > Signed-off-by: Denis Mukhin > --- > Changes since v1: > - updated commentaries > - added ability to select the harness header filename > - fixup for picking up mocked header files > --- > tools/tests/domid/Makefile | 63 ++++++++++++++++++++++++++------------ > 1 file changed, 44 insertions(+), 19 deletions(-) > > diff --git a/tools/tests/domid/Makefile b/tools/tests/domid/Makefile > index 753129029ed9..dd22a25b038a 100644 > --- a/tools/tests/domid/Makefile > +++ b/tools/tests/domid/Makefile > @@ -4,36 +4,55 @@ > # > # Copyright 2025 Ford Motor Company > > -XEN_ROOT=$(CURDIR)/../../.. > -include $(XEN_ROOT)/tools/Rules.mk > - > TESTS := test-domid > > +XEN_ROOT = $(CURDIR)/../../.. > +include $(XEN_ROOT)/tools/Rules.mk > + > define list-c-headers > $(shell sed -n \ > 's/^[ \t]*# *include[ \t]*[<"]\([^">]*\)[">].*/\1/p' $(1) 2>/dev/null) > endef > > -# NB: $1 cannot be a list > +# Generate mock environment by replicating header file hierarchy; > +# each header file will point to a harness header. > +# > +# $1 target > +# $2 list of test harnesses > define emit-harness-nested-rule > -$(1): $(CURDIR)/harness.h > - mkdir -p $$(@D); > - ln -sf $$< $$@; > +$(1): $(2) > + set -e; \ > + mkdir -p $$(@D); \ > + for i in $(2); do [ -e $$@ ] || ln -s $$$$i $$@; done Are you sure this is correct? Everything seems to be escaped too many times? Shouldn't this be: $(1): $(2) set -e; \ mkdir -p "$(@D)"; \ for i in $(2); do \ [ -e "$@" ] || ln -s "$$i" "$@"; \ done endef > endef > > +# Helper function to emit mocked hypervisor code dependencies. > +# > +# $1 Harness file name. > +# $2 Mocked hypervisor file name. > +# $3 List of dependencies to mock. > define emit-harness-rules > -$(foreach x,$(2),$(call emit-harness-nested-rule,$(CURDIR)/generated/$(x))) > -$(1:.c=.o): $(addprefix $(CURDIR)/generated/,$(2)) > +$(foreach x,$(3),$(call emit-harness-nested-rule,\ > + $(CURDIR)/generated/$(x),\ > + $(addprefix $(CURDIR)/,$(1)))) > +$(2:.c=.o): $(addprefix $(CURDIR)/generated/,$(3)) > endef > > define emit-harness-deps > -$(if $(strip $(2)),$(call emit-harness-rules,$1,$2),) > +$(if $(strip $(3)),$(call emit-harness-rules,$1,$2,$3),) > endef > > +# Emit dependencies for mocked hypervisor code. > +# > +# $1 Hypervisor file name. > +# $2 Hypervisor source path. > +# $3 Harness header file name (optional). > define vpath-with-harness-deps > vpath $(1) $(2) > -$(call emit-harness-deps,$(1),$(call list-c-headers,$(2)$(1))) > +$(call emit-harness-deps,$(or $(strip $(3)),harness.h),\ > + $(1),\ > + $(call list-c-headers,$(2)$(1))) > endef > > .PHONY: all > @@ -41,7 +60,11 @@ all: $(TESTS) > > .PHONY: run > run: $(TESTS) > +ifeq ($(CC),$(HOSTCC)) > set -e; $(foreach t,$(TESTS),./$(t);) > +else > + $(warning HOSTCC != CC, will not run test) > +endif > > .PHONY: clean > clean: > @@ -55,25 +78,27 @@ distclean: clean > .PHONY: install > install: all > $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)/tests > - $(INSTALL_PROG) test-domid $(DESTDIR)$(LIBEXEC)/tests > + set -e; $(foreach t,$(TESTS),$(INSTALL_PROG) $t $(DESTDIR)$(LIBEXEC)/tests;) > > .PHONY: uninstall > uninstall: > - $(RM) -- $(DESTDIR)$(LIBEXEC)/tests/test-domid > + set -e; $(foreach t,$(TESTS),$(RM) -- $(DESTDIR)$(LIBEXEC)/tests/$t;) > > CFLAGS += -D__XEN_TOOLS__ > + > # find-next-bit.c > -CFLAGS += '-DEXPORT_SYMBOL(x)=' \ > +CFLAGS-find-next-bit.c += '-DEXPORT_SYMBOL(x)=' \ > -Dfind_first_bit \ > -Dfind_first_zero_bit \ > -Dfind_next_bit \ > -Dfind_next_bit_le \ > -Dfind_next_zero_bit_le > -CFLAGS += $(APPEND_CFLAGS) > -CFLAGS += $(CFLAGS_xeninclude) > -CFLAGS += -I./generated/ > > -LDFLAGS += $(APPEND_LDFLAGS) APPEND_CFLAGS and APPEND_LDFLAGS are lost? > +find-next-bit.o: CFLAGS += $(CFLAGS-find-next-bit.c) > + > +# Honor mocked hypervisor header over tools/include/xen symlinks > +CFLAGS += -I$(CURDIR)/generated/ > +CFLAGS += $(CFLAGS_xeninclude) > > vpath find-next-bit.c $(XEN_ROOT)/xen/lib/ > > @@ -83,6 +108,6 @@ vpath find-next-bit.c $(XEN_ROOT)/xen/lib/ > $(eval $(call vpath-with-harness-deps,domid.c,$(XEN_ROOT)/xen/common/)) > > test-domid: domid.o find-next-bit.o test-domid.o > - $(CC) $^ -o $@ $(LDFLAGS) > + $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ My understanding is that $(LDFLAGS) should be last, e.g.: $(CC) $(CFLAGS) -o $@ $^ $(LDFLAGS) > -include $(DEPS_INCLUDE) > -- > 2.52.0 > From xen-devel-bounces@lists.xenproject.org Sat Jan 24 01:05:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 24 Jan 2026 01:05:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212684.1523703 (Exim 4.92) (envelope-from ) id 1vjS5p-00089d-Tr; Sat, 24 Jan 2026 01:05:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212684.1523703; Sat, 24 Jan 2026 01:05:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjS5p-00089W-RF; Sat, 24 Jan 2026 01:05:37 +0000 Received: by outflank-mailman (input) for mailman id 1212684; Sat, 24 Jan 2026 01:05: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 1vjS5o-00089Q-IH for xen-devel@lists.xenproject.org; Sat, 24 Jan 2026 01:05:36 +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 c89f5311-f8c0-11f0-b15f-2bf370ae4941; Sat, 24 Jan 2026 02:05:34 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 61AAB40286; Sat, 24 Jan 2026 01:05:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0CDC4C4CEF1; Sat, 24 Jan 2026 01:05: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: c89f5311-f8c0-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769216732; bh=yBhWOVTLNDqeuWNFpAhlfjEN4+02e6Kfi69pNVEw5OQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Ep5gOZe1/w4FDhhmm/1kC0qQmP5kgCjXyGr6DqXj5FpapsU3VUUt0HfCy2YlwLR1C LhsvI0X0dmkaKlFr5U5oPdQ57eU4fmVJPdIwHxoazIB3l0VZEuDiBY9/1tkAEzKIuo pJ1uO9h2O2ok7K9G+3CI5cqqKXBXagGiblyVeCZ7k2fDJOjBcXrvwd0urI2opkCEBI VSpIROnKHGBxMMe02NOMxj8CZIwPqN9dRI15gbvQlDQ84wGll8ElJuHj3uWnE3xKnK DvXkaoGvSwkaCNLhN1Rr3pWmDFUqQALu6nKysgxtexLQVEV3tHw0qV6aJqweMSZhQk N3NHh/npLFOKg== Date: Fri, 23 Jan 2026 17:05:29 -0800 (PST) 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 v2 2/4] tests: introduce common fragment for unit tests In-Reply-To: <20260111041145.553673-3-dmukhin@ford.com> Message-ID: References: <20260111041145.553673-1-dmukhin@ford.com> <20260111041145.553673-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 Sat, 10 Jan 2026, dmukhin@xen.org wrote: > From: Denis Mukhin > > Move test harness generation into a new shared make fragment so that > it can be reused by other unit tests. > > Signed-off-by: Denis Mukhin Reviewed-by: Stefano Stabellini > --- > Changes from v1: > - moved fragment to tools/tests/ > --- > tools/tests/Rules.mk | 91 ++++++++++++++++++++++++++++++++++++++ > tools/tests/domid/Makefile | 85 +---------------------------------- > 2 files changed, 92 insertions(+), 84 deletions(-) > create mode 100644 tools/tests/Rules.mk > > diff --git a/tools/tests/Rules.mk b/tools/tests/Rules.mk > new file mode 100644 > index 000000000000..daa9e69301e4 > --- /dev/null > +++ b/tools/tests/Rules.mk > @@ -0,0 +1,91 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +# > +# Common unit test fragment. > +# > +# Copyright 2025 Ford Motor Company > + > +include $(XEN_ROOT)/tools/Rules.mk > + > +define list-c-headers > +$(shell sed -n \ > + 's/^[ \t]*# *include[ \t]*[<"]\([^">]*\)[">].*/\1/p' $(1) 2>/dev/null) > +endef > + > +# Generate mock environment by replicating header file hierarchy; > +# each header file will point to a harness header. > +# > +# $1 target > +# $2 list of test harnesses > +define emit-harness-nested-rule > +$(1): $(2) > + set -e; \ > + mkdir -p $$(@D); \ > + for i in $(2); do [ -e $$@ ] || ln -s $$$$i $$@; done > + > +endef > + > +# Helper function to emit mocked hypervisor code dependencies. > +# > +# $1 Harness file name. > +# $2 Mocked hypervisor file name. > +# $3 List of dependencies to mock. > +define emit-harness-rules > +$(foreach x,$(3),$(call emit-harness-nested-rule,\ > + $(CURDIR)/generated/$(x),\ > + $(addprefix $(CURDIR)/,$(1)))) > +$(2:.c=.o): $(addprefix $(CURDIR)/generated/,$(3)) > +endef > + > +define emit-harness-deps > +$(if $(strip $(3)),$(call emit-harness-rules,$1,$2,$3),) > +endef > + > +# Emit dependencies for mocked hypervisor code. > +# > +# $1 Hypervisor file name. > +# $2 Hypervisor source path. > +# $3 Harness header file name (optional). > +define vpath-with-harness-deps > +vpath $(1) $(2) > +$(call emit-harness-deps,$(or $(strip $(3)),harness.h),\ > + $(1),\ > + $(call list-c-headers,$(2)$(1))) > +endef > + > +.PHONY: all > +all: $(TESTS) > + > +.PHONY: run > +run: $(TESTS) > +ifeq ($(CC),$(HOSTCC)) > + set -e; $(foreach t,$(TESTS),./$(t);) > +else > + $(warning HOSTCC != CC, will not run test) > +endif > + > +.PHONY: clean > +clean: > + $(RM) -r generated > + $(RM) -- *.o $(TESTS) $(DEPS_RM) > + > +.PHONY: distclean > +distclean: clean > + $(RM) -- *~ > + > +.PHONY: install > +install: all > + $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)/tests > + set -e; $(foreach t,$(TESTS),$(INSTALL_PROG) $t $(DESTDIR)$(LIBEXEC)/tests;) > + > +.PHONY: uninstall > +uninstall: > + set -e; $(foreach t,$(TESTS),$(RM) -- $(DESTDIR)$(LIBEXEC)/tests/$t;) > + > +CFLAGS += -D__XEN_TOOLS__ > +# Honor mocked hypervisor header over tools/include/xen symlinks > +CFLAGS += -I$(CURDIR)/generated/ > +CFLAGS += $(CFLAGS_xeninclude) > + > +ifeq ($(filter clean distclean,$(MAKECMDGOALS)),) > +-include $(DEPS_INCLUDE) > +endif > diff --git a/tools/tests/domid/Makefile b/tools/tests/domid/Makefile > index dd22a25b038a..2f8cc5380462 100644 > --- a/tools/tests/domid/Makefile > +++ b/tools/tests/domid/Makefile > @@ -7,84 +7,7 @@ > TESTS := test-domid > > XEN_ROOT = $(CURDIR)/../../.. > -include $(XEN_ROOT)/tools/Rules.mk > - > -define list-c-headers > -$(shell sed -n \ > - 's/^[ \t]*# *include[ \t]*[<"]\([^">]*\)[">].*/\1/p' $(1) 2>/dev/null) > -endef > - > -# Generate mock environment by replicating header file hierarchy; > -# each header file will point to a harness header. > -# > -# $1 target > -# $2 list of test harnesses > -define emit-harness-nested-rule > -$(1): $(2) > - set -e; \ > - mkdir -p $$(@D); \ > - for i in $(2); do [ -e $$@ ] || ln -s $$$$i $$@; done > - > -endef > - > -# Helper function to emit mocked hypervisor code dependencies. > -# > -# $1 Harness file name. > -# $2 Mocked hypervisor file name. > -# $3 List of dependencies to mock. > -define emit-harness-rules > -$(foreach x,$(3),$(call emit-harness-nested-rule,\ > - $(CURDIR)/generated/$(x),\ > - $(addprefix $(CURDIR)/,$(1)))) > -$(2:.c=.o): $(addprefix $(CURDIR)/generated/,$(3)) > -endef > - > -define emit-harness-deps > -$(if $(strip $(3)),$(call emit-harness-rules,$1,$2,$3),) > -endef > - > -# Emit dependencies for mocked hypervisor code. > -# > -# $1 Hypervisor file name. > -# $2 Hypervisor source path. > -# $3 Harness header file name (optional). > -define vpath-with-harness-deps > -vpath $(1) $(2) > -$(call emit-harness-deps,$(or $(strip $(3)),harness.h),\ > - $(1),\ > - $(call list-c-headers,$(2)$(1))) > -endef > - > -.PHONY: all > -all: $(TESTS) > - > -.PHONY: run > -run: $(TESTS) > -ifeq ($(CC),$(HOSTCC)) > - set -e; $(foreach t,$(TESTS),./$(t);) > -else > - $(warning HOSTCC != CC, will not run test) > -endif > - > -.PHONY: clean > -clean: > - $(RM) -r generated > - $(RM) -- *.o $(TESTS) $(DEPS_RM) > - > -.PHONY: distclean > -distclean: clean > - $(RM) -- *~ > - > -.PHONY: install > -install: all > - $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)/tests > - set -e; $(foreach t,$(TESTS),$(INSTALL_PROG) $t $(DESTDIR)$(LIBEXEC)/tests;) > - > -.PHONY: uninstall > -uninstall: > - set -e; $(foreach t,$(TESTS),$(RM) -- $(DESTDIR)$(LIBEXEC)/tests/$t;) > - > -CFLAGS += -D__XEN_TOOLS__ > +include $(XEN_ROOT)/tools/tests/Rules.mk > > # find-next-bit.c > CFLAGS-find-next-bit.c += '-DEXPORT_SYMBOL(x)=' \ > @@ -96,10 +19,6 @@ CFLAGS-find-next-bit.c += '-DEXPORT_SYMBOL(x)=' \ > > find-next-bit.o: CFLAGS += $(CFLAGS-find-next-bit.c) > > -# Honor mocked hypervisor header over tools/include/xen symlinks > -CFLAGS += -I$(CURDIR)/generated/ > -CFLAGS += $(CFLAGS_xeninclude) > - > vpath find-next-bit.c $(XEN_ROOT)/xen/lib/ > > # Point to the hypervisor code and generate test harness dependencies > @@ -109,5 +28,3 @@ $(eval $(call vpath-with-harness-deps,domid.c,$(XEN_ROOT)/xen/common/)) > > test-domid: domid.o find-next-bit.o test-domid.o > $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ > - > --include $(DEPS_INCLUDE) > -- > 2.52.0 > From xen-devel-bounces@lists.xenproject.org Sat Jan 24 01:09:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 24 Jan 2026 01:09:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212695.1523714 (Exim 4.92) (envelope-from ) id 1vjS9L-0000Ni-Dr; Sat, 24 Jan 2026 01:09:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212695.1523714; Sat, 24 Jan 2026 01:09:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjS9L-0000Nb-AD; Sat, 24 Jan 2026 01:09:15 +0000 Received: by outflank-mailman (input) for mailman id 1212695; Sat, 24 Jan 2026 01:09:14 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjS9J-0000NV-8a for xen-devel@lists.xenproject.org; Sat, 24 Jan 2026 01:09:14 +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 498f7523-f8c1-11f0-b15f-2bf370ae4941; Sat, 24 Jan 2026 02:09:10 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id B31F060053; Sat, 24 Jan 2026 01:09:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D4536C4CEF1; Sat, 24 Jan 2026 01:09:06 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 498f7523-f8c1-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769216948; bh=+3fi8RZctfjG3VqR4sC5cK3NwbwuhFLgun6TZwKtuKs=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=G9vX85SBbJpgY34xqSS5KEp4DIW7/8bXtDv4BYoaPIulSoxYe6YnwhNhbfgavyzkJ AdjVbAQ8EzwtxuwX7VjL90QbDrXVbj3wZYFxwpCbwHKSixPpFh+/gkmFRqL9HsUdQ4 P2fReKJC2qwdYeOdttn5f2lvnZvagx4NC73PVvceaFOVMj5PecKvc4iSeyCgO8Lzmc gJHVpt+8HfMEoyKHvLk2l9TTXRPGeMxu5mHeVEAMb1nJlQNC0mwx36t7QptstYhQHU RXbfzJg6rj0Rf/LJjqtBu/WQjtu0VNF9ItWZGFGSzVEhWLT5sDrzvde6g9qcqw8ZLY OKhXeuh+BOmaA== Date: Fri, 23 Jan 2026 17:09:05 -0800 (PST) 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 v2 3/4] tests: use unit test fragment in PDX test In-Reply-To: <20260111041145.553673-4-dmukhin@ford.com> Message-ID: References: <20260111041145.553673-1-dmukhin@ford.com> <20260111041145.553673-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 Sat, 10 Jan 2026, dmukhin@xen.org wrote: > From: Denis Mukhin > > Use the new make fragment to generate test harness code for the PDX unit test. > > Move earlier in xen/common/pdx.c to ensure harness.h is > included before triggering the #ifndef MAX_PFN_RANGES check when building a > unit test. > > Additionally, use real in harness.h instead of a locally > copied version. > > Update .gitignore to exclude generated test build-time dependencies. > > Not a functional change. > > Signed-off-by: Denis Mukhin > --- > Changes since v1: > - new patch > --- > tools/tests/pdx/.gitignore | 2 +- > tools/tests/pdx/Makefile | 55 +++++++++----------------------------- > tools/tests/pdx/harness.h | 2 +- > tools/tests/pdx/test-pdx.c | 2 -- > xen/common/pdx.c | 3 ++- > 5 files changed, 16 insertions(+), 48 deletions(-) > > diff --git a/tools/tests/pdx/.gitignore b/tools/tests/pdx/.gitignore > index 1202a531a7fd..1bf9c05985c4 100644 > --- a/tools/tests/pdx/.gitignore > +++ b/tools/tests/pdx/.gitignore > @@ -1,3 +1,3 @@ > -/pdx.h > +/generated > /test-pdx-mask > /test-pdx-offset > diff --git a/tools/tests/pdx/Makefile b/tools/tests/pdx/Makefile > index 3c431d7c7822..178b451cb611 100644 > --- a/tools/tests/pdx/Makefile > +++ b/tools/tests/pdx/Makefile > @@ -1,50 +1,19 @@ > -XEN_ROOT=$(CURDIR)/../../.. > -include $(XEN_ROOT)/tools/Rules.mk > +# SPDX-License-Identifier: GPL-2.0-only > +# > +# Unit tests for PDX (Page inDeX). > +# > > -TARGETS := test-pdx-mask test-pdx-offset > +TESTS := test-pdx-mask test-pdx-offset > > -.PHONY: all > -all: $(TARGETS) > +XEN_ROOT = $(CURDIR)/../../.. > > -.PHONY: run > -run: $(TARGETS) > -ifeq ($(CC),$(HOSTCC)) > - set -e; \ > - for test in $? ; do \ > - ./$$test ; \ > - done > -else > - $(warning HOSTCC != CC, will not run test) > -endif > +CFLAGS += -DCONFIG_PDX_MASK_COMPRESSION > > -.PHONY: clean > -clean: > - $(RM) -- *.o $(TARGETS) $(DEPS_RM) pdx.h > +include $(XEN_ROOT)/tools/tests/Rules.mk > > -.PHONY: distclean > -distclean: clean > - $(RM) -- *~ > +CFLAGS += -I $(XEN_ROOT)/xen/include/ > > -.PHONY: install > -install: all > - $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)/tests > - $(INSTALL_PROG) $(TARGETS) $(DESTDIR)$(LIBEXEC)/tests > +$(eval $(call vpath-with-harness-deps,pdx.c,$(XEN_ROOT)/xen/common/)) > > -.PHONY: uninstall > -uninstall: > - $(RM) -- $(patsubst %,$(DESTDIR)$(LIBEXEC)/tests/%,$(TARGETS)) > - > -pdx.h: $(XEN_ROOT)/xen/include/xen/pdx.h > - sed -e '/^#[[:space:]]*include/d' <$< >$@ > - > -CFLAGS += -D__XEN_TOOLS__ > -CFLAGS += $(APPEND_CFLAGS) > -CFLAGS += $(CFLAGS_xeninclude) > - > -test-pdx-mask: CFLAGS += -DCONFIG_PDX_MASK_COMPRESSION > -test-pdx-offset: CFLAGS += -DCONFIG_PDX_OFFSET_COMPRESSION The test with -DCONFIG_PDX_OFFSET_COMPRESSION is lost? > -test-pdx-%: test-pdx.c pdx.h > - $(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -o $@ $< $(APPEND_CFLAGS) > - > --include $(DEPS_INCLUDE) > +test-pdx-%: test-pdx.o pdx.o > + $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ > diff --git a/tools/tests/pdx/harness.h b/tools/tests/pdx/harness.h > index e49d6bcf92c2..4cdda931feb2 100644 > --- a/tools/tests/pdx/harness.h > +++ b/tools/tests/pdx/harness.h > @@ -84,7 +84,7 @@ typedef uint64_t paddr_t; > qsort(elem, nr, size, cmp); \ > }) > > -#include "pdx.h" > +#include > > #endif > > diff --git a/tools/tests/pdx/test-pdx.c b/tools/tests/pdx/test-pdx.c > index eefd54c76815..3633c231abaa 100644 > --- a/tools/tests/pdx/test-pdx.c > +++ b/tools/tests/pdx/test-pdx.c > @@ -7,8 +7,6 @@ > > #include "harness.h" > > -#include "../../xen/common/pdx.c" > - > struct range { > /* Ranges are defined as [start, end). */ > unsigned long start, end; > diff --git a/xen/common/pdx.c b/xen/common/pdx.c > index 7e070ff962e8..068a2098b41b 100644 > --- a/xen/common/pdx.c > +++ b/xen/common/pdx.c > @@ -15,11 +15,12 @@ > * along with this program; If not, see . > */ > > +#include > + > /* Trim content when built for the test harness. */ > #ifdef __XEN__ > #include > #include > -#include > #include > #include > #include > -- > 2.52.0 > From xen-devel-bounces@lists.xenproject.org Sat Jan 24 01:25:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 24 Jan 2026 01:25:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212711.1523723 (Exim 4.92) (envelope-from ) id 1vjSP0-0003Ef-Mc; Sat, 24 Jan 2026 01:25:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212711.1523723; Sat, 24 Jan 2026 01: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 1vjSP0-0003EY-K2; Sat, 24 Jan 2026 01:25:26 +0000 Received: by outflank-mailman (input) for mailman id 1212711; Sat, 24 Jan 2026 01: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 1vjSOz-0003ES-HR for xen-devel@lists.xenproject.org; Sat, 24 Jan 2026 01:25:25 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8d3c0eaf-f8c3-11f0-9ccf-f158ae23cfc8; Sat, 24 Jan 2026 02:25:22 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 48F51600C4; Sat, 24 Jan 2026 01:25:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 71981C4CEF1; Sat, 24 Jan 2026 01:25: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: 8d3c0eaf-f8c3-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769217920; bh=TrKj0NsuC20w0m/XeqNt6omGuZwPvdDUeFI54yIIHgk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=flBfALSmol73JdnauDdfi+lI5hltlNrJ+TznXLfQrL02Lj4OKBox7hCWAZ8WSEZog P4AJ9ce9fkFLdEnxcThAY1gSt6EOVicIUi0oyqQqXdQ+D7eF7H+N9jT73b7GQYwHZ6 WD1ED3uw0Ct3tp9BHdiUFILt9DqJ7KcnBPnZ8ycP92o+AceUd4s79pl+TleiisB8zE h1EloXVarivdgcK1jGSSS0IecVP4CNwD3uSQV93Rm+ICJKHN8Lybo3sPdaJiKsivC6 m8VpHt5+FVTEYbl5B9cF//QuDKpuLMT5xuYW/cGpQUqWVSm9HA+ElGrJPm43ZjvvTf q5AP2U88cYcsg== Date: Fri, 23 Jan 2026 17:25:18 -0800 (PST) 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 v2 4/4] tests: use unit test fragment in vPCI test In-Reply-To: <20260111041145.553673-5-dmukhin@ford.com> Message-ID: References: <20260111041145.553673-1-dmukhin@ford.com> <20260111041145.553673-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 Sat, 10 Jan 2026, dmukhin@xen.org wrote: > From: Denis Mukhin > > Use the new make fragment to generate test harness code for > the vPCI unit test. > > Add new prepare-harness target to tests/Rules.mk as an optional step for > setting up mocked environment for building a test. > > Fix hypervisor headers used to compile vpci.c against host environment > where necessary. > > Fixup emul.h by adding missing mocks to account for new unit test infra. > > Update .gitignore to exclude generated test build-time dependencies. > > Not a functional change. > > Signed-off-by: Denis Mukhin > --- > Changes since v1: > - new patch > --- > tools/tests/Rules.mk | 5 +++- > tools/tests/vpci/.gitignore | 2 ++ > tools/tests/vpci/Makefile | 52 ++++++++++++------------------------- > tools/tests/vpci/emul.h | 50 +++++++++++++---------------------- > tools/tests/vpci/main.c | 2 -- > xen/include/xen/irq.h | 2 ++ > xen/include/xen/list.h | 2 ++ > xen/include/xen/numa.h | 2 ++ > xen/include/xen/pci.h | 2 ++ > xen/include/xen/pfn.h | 2 ++ > xen/include/xen/spinlock.h | 2 ++ > xen/include/xen/types.h | 4 +++ > 12 files changed, 56 insertions(+), 71 deletions(-) > create mode 100644 tools/tests/vpci/.gitignore > > diff --git a/tools/tests/Rules.mk b/tools/tests/Rules.mk > index daa9e69301e4..26f3d00b5fb9 100644 > --- a/tools/tests/Rules.mk > +++ b/tools/tests/Rules.mk > @@ -11,13 +11,16 @@ $(shell sed -n \ > 's/^[ \t]*# *include[ \t]*[<"]\([^">]*\)[">].*/\1/p' $(1) 2>/dev/null) > endef > > +.PHONY: prepare-harness > +prepare-harness: > + > # Generate mock environment by replicating header file hierarchy; > # each header file will point to a harness header. > # > # $1 target > # $2 list of test harnesses > define emit-harness-nested-rule > -$(1): $(2) > +$(1): prepare-harness $(2) > set -e; \ > mkdir -p $$(@D); \ > for i in $(2); do [ -e $$@ ] || ln -s $$$$i $$@; done > diff --git a/tools/tests/vpci/.gitignore b/tools/tests/vpci/.gitignore > new file mode 100644 > index 000000000000..d66c2cd56be6 > --- /dev/null > +++ b/tools/tests/vpci/.gitignore > @@ -0,0 +1,2 @@ > +/generated > +test-vpci > diff --git a/tools/tests/vpci/Makefile b/tools/tests/vpci/Makefile > index 97359ff67f86..695a275675f8 100644 > --- a/tools/tests/vpci/Makefile > +++ b/tools/tests/vpci/Makefile > @@ -1,43 +1,23 @@ > -XEN_ROOT=$(CURDIR)/../../.. > -include $(XEN_ROOT)/tools/Rules.mk > +# SPDX-License-Identifier: GPL-2.0-only > +# > +# Unit tests for vPCI. > +# > > -TARGET := test_vpci > +TESTS := test-vpci > > -.PHONY: all > -all: $(TARGET) > +XEN_ROOT = $(CURDIR)/../../.. > +CFLAGS += -DCONFIG_HAS_VPCI > > -.PHONY: run > -run: $(TARGET) > -ifeq ($(CC),$(HOSTCC)) > - ./$(TARGET) > -else > - $(warning HOSTCC != CC, will not run test) > -endif > +include $(XEN_ROOT)/tools/tests/Rules.mk > > -$(TARGET): vpci.c vpci.h list.h main.c emul.h > - $(CC) $(CFLAGS_xeninclude) -g -o $@ vpci.c main.c > +# Do not mock xen/vpci.h header for the test > +prepare-harness: > + set -e; mkdir -p $(CURDIR)/generated/xen; \ > + ln -sf $(XEN_ROOT)/xen/include/xen/vpci.h $(CURDIR)/generated/xen > > -.PHONY: clean > -clean: > - rm -rf $(TARGET) *.o *~ vpci.h vpci.c list.h > +CFLAGS += -I $(XEN_ROOT)/xen/include/ > > -.PHONY: distclean > -distclean: clean > +$(eval $(call vpath-with-harness-deps,vpci.c,$(XEN_ROOT)/xen/drivers/vpci/,emul.h)) > > -.PHONY: install > -install: all > - $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)/tests > - $(INSTALL_PROG) $(TARGET) $(DESTDIR)$(LIBEXEC)/tests > - > -.PHONY: uninstall > -uninstall: > - $(RM) -- $(DESTDIR)$(LIBEXEC)/tests/$(TARGET) > - > -vpci.c: $(XEN_ROOT)/xen/drivers/vpci/vpci.c > - # Remove includes and add the test harness header > - sed -e '/#include/d' -e '1s/^/#include "emul.h"/' <$< >$@ > - > -list.h: $(XEN_ROOT)/xen/include/xen/list.h > -vpci.h: $(XEN_ROOT)/xen/include/xen/vpci.h > -list.h vpci.h: > - sed -e '/#include/d' <$< >$@ > +test-vpci: vpci.o main.o > + $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ > diff --git a/tools/tests/vpci/emul.h b/tools/tests/vpci/emul.h > index dd048cffbf9d..979e86e2692e 100644 > --- a/tools/tests/vpci/emul.h > +++ b/tools/tests/vpci/emul.h > @@ -34,8 +34,16 @@ > #define ASSERT(x) assert(x) > #define __must_check __attribute__((__warn_unused_result__)) > #define cf_check > +#define always_inline inline > > -#include "list.h" > +typedef int64_t s_time_t; > +typedef uint8_t nodeid_t; > +typedef uint8_t u8; > +typedef uint16_t u16; > +typedef uint32_t u32; > +typedef uint64_t u64; > + > +#include > > typedef bool rwlock_t; > > @@ -43,10 +51,6 @@ struct domain { > rwlock_t pci_lock; > }; > > -struct pci_dev { > - struct vpci *vpci; > -}; > - > struct vcpu > { > struct domain *domain; > @@ -57,35 +61,17 @@ extern const struct pci_dev test_pdev; > > typedef bool spinlock_t; > #define spin_lock_init(l) (*(l) = false) > -#define spin_lock(l) (*(l) = true) > -#define spin_unlock(l) (*(l) = false) > -#define read_lock(l) (*(l) = true) > -#define read_unlock(l) (*(l) = false) > -#define write_lock(l) (*(l) = true) > -#define write_unlock(l) (*(l) = false) > +#define spin_lock(l) (assert(!*(l)), *(l) = true) > +#define spin_unlock(l) (assert(*(l)), *(l) = false) > +#define read_lock(l) (assert(!*(l)), *(l) = true) > +#define read_unlock(l) (assert(*(l)), *(l) = false) > +#define write_lock(l) (assert(!*(l)), *(l) = true) > +#define write_unlock(l) (assert(*(l)), *(l) = false) > > -typedef union { > - uint32_t sbdf; > - struct { > - union { > - uint16_t bdf; > - struct { > - union { > - struct { > - uint8_t func : 3, > - dev : 5; > - }; > - uint8_t extfunc; > - }; > - uint8_t bus; > - }; > - }; > - uint16_t seg; > - }; > -} pci_sbdf_t; > +#define lock_evaluate_nospec(l) (l) > +#define block_lock_speculation() > > -#define CONFIG_HAS_VPCI > -#include "vpci.h" > +#include > > #define __hwdom_init > > diff --git a/tools/tests/vpci/main.c b/tools/tests/vpci/main.c > index 2ef8d4e03f1d..3753417e866d 100644 > --- a/tools/tests/vpci/main.c > +++ b/tools/tests/vpci/main.c > @@ -189,8 +189,6 @@ main(int argc, char **argv) > uint32_t r24 = 0; > uint8_t r28, r30; > struct mask_data r32; > - unsigned int i; > - int rc; > > INIT_LIST_HEAD(&vpci.handlers); > spin_lock_init(&vpci.lock); The patch looks OK but I recommend to split the xen headers changes into a separate patch > diff --git a/xen/include/xen/irq.h b/xen/include/xen/irq.h > index 6071b00f621e..f7fa1d0fa29b 100644 > --- a/xen/include/xen/irq.h > +++ b/xen/include/xen/irq.h > @@ -1,5 +1,6 @@ > #ifndef __XEN_IRQ_H__ > #define __XEN_IRQ_H__ > +#ifdef __XEN__ > > #include > #include > @@ -208,4 +209,5 @@ unsigned int arch_hwdom_irqs(const struct domain *d); > void arch_evtchn_bind_pirq(struct domain *d, int pirq); > #endif > > +#endif /* __XEN__ */ > #endif /* __XEN_IRQ_H__ */ > diff --git a/xen/include/xen/list.h b/xen/include/xen/list.h > index 98d8482daba1..06d2fa3aed15 100644 > --- a/xen/include/xen/list.h > +++ b/xen/include/xen/list.h > @@ -7,8 +7,10 @@ > #ifndef __XEN_LIST_H__ > #define __XEN_LIST_H__ > > +#ifdef __XEN__ > #include > #include > +#endif > > /* > * These are non-NULL pointers that will result in faults under normal > diff --git a/xen/include/xen/numa.h b/xen/include/xen/numa.h > index f6c1f27ca105..80d60fd49178 100644 > --- a/xen/include/xen/numa.h > +++ b/xen/include/xen/numa.h > @@ -1,5 +1,6 @@ > #ifndef _XEN_NUMA_H > #define _XEN_NUMA_H > +#ifdef __XEN__ > > #include > > @@ -152,4 +153,5 @@ static inline nodeid_t mfn_to_nid(mfn_t mfn) > > #define page_to_nid(pg) mfn_to_nid(page_to_mfn(pg)) > > +#endif /* __XEN__ */ > #endif /* _XEN_NUMA_H */ > diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h > index 130c2a8c1a65..f5965a68ae33 100644 > --- a/xen/include/xen/pci.h > +++ b/xen/include/xen/pci.h > @@ -14,7 +14,9 @@ > #include > #include > #include > +#ifdef __XEN__ > #include > +#endif There seem to be other Xen internal declarations in this header. I am not sure what the best policy should be: try to cover them all within the #ifdef __XEN__ even thought we don't really have a specific build test that needs it, or only fix the specific build issue in this patch. I am OK either way but I wanted to mention the possible choice in case others have an opinion. > /* > * The PCI interface treats multi-function devices as independent > diff --git a/xen/include/xen/pfn.h b/xen/include/xen/pfn.h > index 1ca9b095e0df..98ff669d7def 100644 > --- a/xen/include/xen/pfn.h > +++ b/xen/include/xen/pfn.h > @@ -1,7 +1,9 @@ > #ifndef __XEN_PFN_H__ > #define __XEN_PFN_H__ > > +#ifdef __XEN__ > #include > +#endif > > #define PFN_DOWN(x) ((x) >> PAGE_SHIFT) > #define PFN_UP(x) (((x) + PAGE_SIZE-1) >> PAGE_SHIFT) > diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h > index ca9d8c7ec0a1..ad5094c4eb92 100644 > --- a/xen/include/xen/spinlock.h > +++ b/xen/include/xen/spinlock.h > @@ -1,5 +1,6 @@ > #ifndef __SPINLOCK_H__ > #define __SPINLOCK_H__ > +#ifdef __XEN__ > > #include > #include > @@ -360,4 +361,5 @@ static always_inline void nrspin_lock_irq(rspinlock_t *l) > #define nrspin_unlock_irqrestore(l, f) _nrspin_unlock_irqrestore(l, f) > #define nrspin_unlock_irq(l) _nrspin_unlock_irq(l) > > +#endif /* __XEN__ */ > #endif /* __SPINLOCK_H__ */ > diff --git a/xen/include/xen/types.h b/xen/include/xen/types.h > index 73ddccbbd5dc..e5d702b48ac0 100644 > --- a/xen/include/xen/types.h > +++ b/xen/include/xen/types.h > @@ -4,6 +4,7 @@ > #include > #include > > +#ifdef __XEN__ > /* Linux inherited types which are being phased out */ > typedef uint8_t u8; > typedef uint16_t u16; > @@ -15,6 +16,7 @@ typedef uint64_t u64; > typedef __SIZE_TYPE__ size_t; > > typedef signed long ssize_t; > +#endif /* __XEN__ */ > > typedef __PTRDIFF_TYPE__ ptrdiff_t; > typedef __UINTPTR_TYPE__ uintptr_t; > @@ -33,6 +35,7 @@ typedef __UINTPTR_TYPE__ uintptr_t; > #define NULL ((void*)0) > #endif > > +#ifdef __XEN__ > #define INT8_MIN (-127-1) > #define INT16_MIN (-32767-1) > #define INT32_MIN (-2147483647-1) > @@ -52,6 +55,7 @@ typedef __UINTPTR_TYPE__ uintptr_t; > #define LONG_MAX ((long)(~0UL>>1)) > #define LONG_MIN (-LONG_MAX - 1) > #define ULONG_MAX (~0UL) > +#endif /* __XEN__ */ > > typedef uint16_t __le16; > typedef uint16_t __be16; > -- > 2.52.0 > From xen-devel-bounces@lists.xenproject.org Sat Jan 24 05:24:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 24 Jan 2026 05:24:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212745.1523734 (Exim 4.92) (envelope-from ) id 1vjW8I-0005m1-Rv; Sat, 24 Jan 2026 05:24:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212745.1523734; Sat, 24 Jan 2026 05:24:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjW8I-0005lt-M8; Sat, 24 Jan 2026 05:24:26 +0000 Received: by outflank-mailman (input) for mailman id 1212745; Sat, 24 Jan 2026 05:24:25 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjW8G-0005lW-L1 for xen-devel@lists.xenproject.org; Sat, 24 Jan 2026 05:24:25 +0000 Received: from submarine.notk.org (submarine.notk.org [62.210.214.84]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ed6efb0f-f8e4-11f0-9ccf-f158ae23cfc8; Sat, 24 Jan 2026 06:24:17 +0100 (CET) Received: from gaia.codewreck.org (localhost [127.0.0.1]) by submarine.notk.org (Postfix) with ESMTPS id 5D39B14C2D6; Sat, 24 Jan 2026 06:24:13 +0100 (CET) Received: from localhost (gaia.codewreck.org [local]) by gaia.codewreck.org (OpenSMTPD) with ESMTPA id cd0f7966; Sat, 24 Jan 2026 05: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: ed6efb0f-f8e4-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1769232255; 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=w1+vFOzs5lBmQ1GdxNYRJvUl5CszH3FRGvya+3o6tDY=; b=TSpDBR1hdYlbtwiEo8NvHQDpPR05y1xZ4dalVTYW/AGpyMsLvCCCErKyqpyAdMHiYXYXXa cEmVYEnZ0rRc++YgMB/ZZjpfLlFwfGJKzk9dCpKAPjNYyNfy889mX9ekoTN3DPbxk3l4jL HHPU1k1OB7XEgQ66EAoRww2duiCaOFklmAXzLZpeb1fP1vOH4xL1Kvvkbc2wZzdvrrqJD0 Mxui0OKMfYsO1zplb2b+5ekkhacBlQnviCTmO6fbOrUf+gcOJtlvIJM5l9c8nxhGngo3E7 0uoNwobo1HZldBx0l0uB6gGH3ymmsW85wQGqblzcx2ofrSmU4vlxGP2M42lfuA== Date: Sat, 24 Jan 2026 14:23:56 +0900 From: Dominique Martinet To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, jgross@suse.com, v9fs@lists.linux.dev, Eric Van Hensbergen , Latchesar Ionkov , Christian Schoenebeck , sstabellini@kernel.org Subject: Re: [PATCH] 9p/xen: protect xen_9pfs_front_free against concurrent calls Message-ID: References: <20260123184009.1298536-1-stefano.stabellini@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260123184009.1298536-1-stefano.stabellini@amd.com> Stefano Stabellini wrote on Fri, Jan 23, 2026 at 10:40:09AM -0800: > The xenwatch thread can race with other back-end change notifications > and call xen_9pfs_front_free() twice, hitting the observed general > protection fault due to a double-free. Guard the teardown path so only > one caller can release the front-end state at a time, preventing the > crash. Thank you, just a couple of nitpicks below > diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c > index 280f686f60fbb..8809f3c06ec95 100644 > --- a/net/9p/trans_xen.c > +++ b/net/9p/trans_xen.c > @@ -274,11 +274,7 @@ static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv) > { > int i, j; > > - write_lock(&xen_9pfs_lock); > - list_del(&priv->list); > - write_unlock(&xen_9pfs_lock); > - > - for (i = 0; i < XEN_9PFS_NUM_RINGS; i++) { > + for (i = 0; priv->rings != NULL && i < XEN_9PFS_NUM_RINGS; i++) { I don't understand this priv->rings != NULL check here; if it's guarding for front_free() called before front_init() then it doesn't need to be checked at every iteration, and if it can change in another thread I don't see why it would be safe. > struct xen_9pfs_dataring *ring = &priv->rings[i]; > > cancel_work_sync(&ring->work); > @@ -310,9 +306,18 @@ static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv) > > static void xen_9pfs_front_remove(struct xenbus_device *dev) > { > - struct xen_9pfs_front_priv *priv = dev_get_drvdata(&dev->dev); > + struct xen_9pfs_front_priv *priv; > > + write_lock(&xen_9pfs_lock); > + priv = dev_get_drvdata(&dev->dev); > + if (priv == NULL) { > + write_unlock(&xen_9pfs_lock); > + return; > + } > dev_set_drvdata(&dev->dev, NULL); > + list_del_init(&priv->list); There's nothing wrong with using the del_init() variant here, but it would imply someone else could still access it after the unlock here, which means to me they could still access it after priv is freed in xen_9pfs_front_free(). >From your commit message I think the priv == NULL check and dev_set_drvdata() under lock above is enough, can you confirm? > + write_unlock(&xen_9pfs_lock); > + > xen_9pfs_front_free(priv); > } > > @@ -387,7 +392,7 @@ static int xen_9pfs_front_init(struct xenbus_device *dev) > { > int ret, i; > struct xenbus_transaction xbt; > - struct xen_9pfs_front_priv *priv = dev_get_drvdata(&dev->dev); > + struct xen_9pfs_front_priv *priv; > char *versions, *v; > unsigned int max_rings, max_ring_order, len = 0; > > @@ -415,6 +420,10 @@ static int xen_9pfs_front_init(struct xenbus_device *dev) > if (p9_xen_trans.maxsize > XEN_FLEX_RING_SIZE(max_ring_order)) > p9_xen_trans.maxsize = XEN_FLEX_RING_SIZE(max_ring_order) / 2; > > + priv = kzalloc(sizeof(*priv), GFP_KERNEL); > + if (!priv) > + return -ENOMEM; > + priv->dev = dev; > priv->rings = kcalloc(XEN_9PFS_NUM_RINGS, sizeof(*priv->rings), > GFP_KERNEL); > if (!priv->rings) { > @@ -473,6 +482,11 @@ static int xen_9pfs_front_init(struct xenbus_device *dev) > goto error; > } > > + write_lock(&xen_9pfs_lock); > + dev_set_drvdata(&dev->dev, priv); Honest question: could xen_9pfs_front_init() also be called multiple times as well? (if so this should check for the previous drvdata and free the priv that was just built if it was non-null) Please ignore this if you think that can't happen, I really don't know. Thanks, -- Dominique Martinet | Asmadeus From xen-devel-bounces@lists.xenproject.org Sat Jan 24 13:23:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 24 Jan 2026 13:23:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1212836.1523744 (Exim 4.92) (envelope-from ) id 1vjdbc-0000sY-1n; Sat, 24 Jan 2026 13:23:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1212836.1523744; Sat, 24 Jan 2026 13:23:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjdbb-0000sP-Se; Sat, 24 Jan 2026 13:23:11 +0000 Received: by outflank-mailman (input) for mailman id 1212836; Sat, 24 Jan 2026 13:23: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 1vjdba-0000sI-AA for xen-devel@lists.xenproject.org; Sat, 24 Jan 2026 13:23:10 +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 d252ddd5-f927-11f0-9ccf-f158ae23cfc8; Sat, 24 Jan 2026 14:23:07 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BLAPR03MB5555.namprd03.prod.outlook.com (2603:10b6:208:29b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.14; Sat, 24 Jan 2026 13:23:02 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9520.011; Sat, 24 Jan 2026 13:23: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: d252ddd5-f927-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=yTbVLqCUWToosBicsZZ9wSNiIgdJPPvvZMSo4dznudoy0hJk2OS7pXkNT8WdBNB8aUCiYY6hBQdsJdy64Pv+CJxh4O3HHPJcT6wKe5UbSeiBp5KinpEC2Z5P/OTSkoHiiTvNZPHdTiTvqA/o8QyZNeQvWiKPq+9msG05qHE+CJTy5H+AaahANtBgl/aCoo8k68ytp8vMlALh6xPUOj1BAH0PW8eW0Y8yn81WIhhT+3OVrww3+lxuToZyD9pp8YSj7/coyE+OSWDrldOUmLCeczyPMtCXFP4gEpbM6YDlouZFE+RZH/vRt1rgVkA6FBHW08bQy6wAhkZ+iupLhC2Abg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/HVLmgfdtdtGuw125hCDS5O64oIRU4lHyZZwaBUw0ag=; b=uPeMdpyDOwVc6zzLB/SR9jE0+T5/Y1KlGQv7T9LGfzIBfSnLJ5aj2kQkRch+dAg42MJMZcmK0+dTZFt6hRO0OTxw+N+0veuE/+4xxMDeMyM9FQzps5ZV5IyUeCb3ikDkLM9arrtO4mfGdNJHbovY4VtTZqFmMlXDWkk099e4YJ32ZMnvrZQ79S9E4A+aiaqa5vG+r6DAtHs/vRBDp7a+f0bl5cyBz5D29qeNNEhiHH8IQQfngFpe5yN1gimIzL6CT8lfs8e7qf1Un8IrvM7DUp5twrcjLhIxJgOUArRI47ZulrP3iDdhTTsJ0b7lKJeQTZPdwXSOGztNsqHyPapXUw== 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=/HVLmgfdtdtGuw125hCDS5O64oIRU4lHyZZwaBUw0ag=; b=RcGwGLZ8BWiJWMgkidevZ8reRbcR+UzwUabjm/7kOsUc7VqXycVvZ1/Qy+uCfCwdUleVBbJcpKvFq4PaLhzBQrpUJNcsthAXckuW6Cd4PdkSRgdVxKIPNU0m5YzMCLCyFZGtVsgZcIOXFTj0IVrlRYCdCqJ0u+RsIbSk1sNneqQ= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <1a613a11-0c7f-47aa-a8d3-b090fff29a57@citrix.com> Date: Sat, 24 Jan 2026 13:22:59 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , xen-devel@lists.xenproject.org, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, dmukhin@ford.com Subject: Re: [PATCH v1 4/4] scripts/config: hook to automation build script To: Stefano Stabellini , dmukhin@xen.org References: <20260116043458.730728-1-dmukhin@ford.com> <20260116043458.730728-5-dmukhin@ford.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0457.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1aa::12) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BLAPR03MB5555:EE_ X-MS-Office365-Filtering-Correlation-Id: 2d796125-a629-4d8e-8857-08de5b4bb303 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?QkRRSU4waUU4YXRSVlB5dEtQSnJDZWtWZjNjUm11cmxrL0lIRjI2dXh3NHBH?= =?utf-8?B?ZTRadmtnQ1BsRnJzK05mV01pR0YrSWkzSE50b2VOUFQ4dE1BbjBiK2F6THVz?= =?utf-8?B?TGNaMlZIckVaanp1WkFvSGh4WUZHVDNIZkxjTzhhZ1NYMHFXOXM4SUpFcFRB?= =?utf-8?B?Z05KN1pOZ2dtU0F3TVlrR3VmRFRzV0NRVCt3L2NtKzNRdTRYd0pjQWxMNzVm?= =?utf-8?B?TjJ4a2R3azM4TTNVdzdXYXNEc0pvMGE3QW5neEdaQVJpTjc1VmdxM2NZb2o3?= =?utf-8?B?MXdDaU83RjVENjAvYndwN1hEL2NWS1BDQktIaHdPMnlVUDh2U0Q0WHBNOVIv?= =?utf-8?B?TzVYb3ppRnhZS3hhUEcxMG5VTDRSNmJGT2hBSWgyY1pIZk1udTFXT01Gcno0?= =?utf-8?B?UjZwVGFlVk5UVGtJRU03SUN2UkRGa2NJS2hzR3RPcXFnOGRwbXovb3Y5Q0NM?= =?utf-8?B?K2oyY204MFhjRDFoMklZNFYxT0xjdmdHdUNEclg3RXRpdjdxYm9Wb2xEcWcz?= =?utf-8?B?Y2xKTi9NaERjM05tdHcxMWxtd1BDTmVSbUl3aGtPa0J5Ym1rV1h0dTVzMXhp?= =?utf-8?B?OG9NZm9PQ21uTUdmU2k1M0NOWWJuNXRCMUJtTHhoY2RZU2t2b0tVUFJPbUI3?= =?utf-8?B?MXFIMDZMOWNWR0lsWDh6aXM4bkF1NGxZTk1rMDZxV3RRSmJMNWtVOE9IcFdY?= =?utf-8?B?QU4wbUQ4UXRqZTVFNDhGRFVYRVNxaFFySkRMRjc1QzF2UFBjQzdGRlVSNS9Y?= =?utf-8?B?UmtRTTViaERVWjFTMVRQWVJkVHlGY0NWVC9YSWNhOUNhY3ptRWdZR3pYcjFG?= =?utf-8?B?cTdxVnJ5TDNOMWZ2VTkwNzY3ZGM5QTEwK2M5T3FqVk1zV0NjREFGRXZOLzls?= =?utf-8?B?eWZ3T1BzaHV4eXpqNjJzSHc0TjBMNDRiWTN6WVMrVDVhTkxRdkhaRVhrTHZ4?= =?utf-8?B?cDVWTHhnb2dReDhNaE9GZU1aZEJzQmVZT2lKWnBVSzZxQVVUQlJVUE5YRFU0?= =?utf-8?B?Q04xelRvaFFQS0hXWm9HdkxUR0graU9DamQwcEhXUjZkdGdNUTlST0JLRFpo?= =?utf-8?B?TkpMTHQ1YVEreTBxREFNbGNaQ2Juc3plTWcyKzlRVjRQOTRCZ3gzbWpnSlV0?= =?utf-8?B?azZDM1lCWkZhRURkU3dmTjkyWTRYUlVBNllOc29yeWNOL0RwTy9QbTNwMEFr?= =?utf-8?B?UXVVVDd1dkcxZzdvemVTRHVCZVZmYVp4aFBIdDVqUW1pSkk2dkY2MjNjbCta?= =?utf-8?B?ZlZ3cXNOc2c4NHdxOXR5akx6ZDFObWZHVEZkWU9HQko4SndmMHpJN1psUXVF?= =?utf-8?B?Vnh0REdxSnJzZWlISFFyWGNqUGV6cVFGTjJFd3JTZ3M0YnBSaC9obGZYZTNy?= =?utf-8?B?Yjc0QysrOENoMjFDTzhqMHk2em5JYUpjamxZcnBlaTJoL1VYc3lCVVIxaFBa?= =?utf-8?B?M25YREU3TForRGVqbUsxVnBpcVJjOEdaUy9ZcXpQTUV5aTVTdSs2MkF4OU1W?= =?utf-8?B?UWtBaXFqNEVkakxpOU5oTWVVQlBqT3N5bHpwakdxRTJTV01IYWpMYVVIekc1?= =?utf-8?B?eG5EMFpKMkkxY1dWRlpHWHRMaFQydURlZWVyQWR6R3Vhei9WR1ZscXp4bTRk?= =?utf-8?B?eU9XWC8yZFl6TmVoSFpjTEV1d21RYmY4amZnc2F4UE9pUEJkL1BJNjJhVHZ0?= =?utf-8?B?cjJrTE9NcXhOaEs2RUkvUjRrMjdkbG1PYjBYR0hFYjh6aDRPcTFmdU02amxN?= =?utf-8?B?Y2ZwaXM2Tjh1MFVUZ0h4NEduRUZjK0hTbTNKN2xoMklsc2dXeXNWNnA2a2Zi?= =?utf-8?B?MjFzajYzNFc5Z3dMR1FZK25RMUZNc3NsVFFYZk9pSW5nUCs1c0hoekxGU0RI?= =?utf-8?B?ZEFGTmRONlZwT1VlWHQ0NFpCK0MwbFliQ3lvMUdVWGpOOFZJTEVoQno3dGZt?= =?utf-8?B?TnZnb21WY01ESFcza2ZNei9zS0lkelovV0k5SGtuejFUb0FTVGcrUVdNZGkz?= =?utf-8?B?MDNyWjRaeXhWTmVnVDFIUmNLS3BFcWs5cE9DMHBvTEJlVWowQThsTng3K0tB?= =?utf-8?B?cTlldG5XTFZkK3p4VmpVNThtSG16bTQyUG9LVytkMXIvN1BqQUxzSlFqOVA0?= =?utf-8?Q?ZwHQ=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UWFDVGFkb0dFWTE2c1dCd0Myb1gvWkJsanEvRFU0UUMvQkNGeWI1c1Z6NUlP?= =?utf-8?B?RmJGNlZHY1VSeG9BYmZOVGhhY0h3NW13SUU0eEg4bzlJTGJKWkhSRlErMm82?= =?utf-8?B?aHVFVU5PSjZBVWo5aGVhMHRmcjF2ZUJHOGJkS0tNSEd2VnZZeGVySjRvZ1Nx?= =?utf-8?B?Slh3Y1k5ZERVam5heFNlRzg2TW1wMHp4blErcEN0dWpzQ3oxREE4TzBqTDBZ?= =?utf-8?B?dVpkaFRGSGZKUE84dzZCd0JjN3dRelRPOGZGU0w1QWtlSExTQVJUa21sM2J4?= =?utf-8?B?Yi9kRkZxSUtFZUU3M0NVSEMzTnBtZlNYYjE2KzcrSysyM1k5RDdDcEJEM3RP?= =?utf-8?B?cTNMcyt5U0czSWFaYjBPbEN5YWsrRmdVenpta24xOEs0QnV4dDVFRWY0ZSs0?= =?utf-8?B?SDU5NWVmUnFyc1phTG5RZDdNampvR21pbjFtejZzOWVRSkxhQUlmU0VRTitF?= =?utf-8?B?dXRjajY4ZGtLVTM1SG51SlRWeUhzdzFzTWpPMUdMc2k0UkhHQW1aK3ZURkU2?= =?utf-8?B?TjdrbWhZVyt3eU5hKzl0dWs5aGsvY1BKWVRXWGVHaG5ldWFqZW4wYnFzNlF5?= =?utf-8?B?ZTVEcGJPY0NaazV6M1hjbFo0L3ZVNVc4MUp0a2RJTVJ2ZUlUcU9UT3dXTm0v?= =?utf-8?B?RUUxeHpmbmsxMTQrcnE0OFY0Rml0RklYWkpBcmNxR1VnWWN3VzNCUE5UZE1I?= =?utf-8?B?V0QzNmtEQ0dWWkJUdGx0TEJVSDJQWjhudzRjNjg0Qk9yZHhnYTYvOXR0bDRW?= =?utf-8?B?c2dpeGozWnkxUVIrdVgySFpWTFZDTTF4TUEwSUU3ZEdwVG9jNTU4bHkxUE9Y?= =?utf-8?B?RzFvNDRKU1hIR1U2MysrZFc5bXJEZXZoRE5xUnNiQ05rNTV2bW8vOGVTdHdi?= =?utf-8?B?enJmbW4yaGk4THZpMXBmbFRNSmdnUEdYSlJTVnI3N3JJa2MzcG9iZUNQRjl6?= =?utf-8?B?cUpzaTV5RlptaXBpWm92VUgzZWlnVEFVQ3p0a2Y4YkNFMlUxTWt1dkU1eTR3?= =?utf-8?B?REVaQXI1bTJ1aTB4Zzh4aHlhK2JEZU5KSUdBU1hrVWRURXNTWlMrSXl0MjV3?= =?utf-8?B?dktDMk9ORU1IWEFoWkNXNVVUMGI2RWZnODg5cDZqSHVMS1hqbFFYQ2o2Tnpu?= =?utf-8?B?WWdrVEVIQy8rUXpBUC9aSURiOXhHemcrUjF2RHpMM0dZWUJTenpma0tSOVRP?= =?utf-8?B?VkZSdmZVUUpEcUFVMElPOGw2bmtlYlRmb0phS2lWZUtxRExBTkExdzZkeWo5?= =?utf-8?B?aGdMenZhK1dIa0UxR0FBLzU4Qk1GN0lmOWQ0VzVTc3R2dmh4dHBDMTZoT0Vw?= =?utf-8?B?Ylo2SjloWFVDcUNtdHlSS216ZVAveVBVbVRtb1NHK3lUNDc1ak5mWUpVT2Jy?= =?utf-8?B?L1E3QitlTWM5UGpuMzUrVWZ4VVZPSjNDeWZVOHNtbGxmNGN6THpDTGFDTU15?= =?utf-8?B?L3ZtZWNXWnFRZWRnN3h0MC8vZjFnanp1V2pCUlpVVzhwWmpEYWZhNElwTkxq?= =?utf-8?B?RnVobTd1eHV6M3BuQkkrVWdVWDl5ampzSGswWHh4YVI2azZRQmJKcFdUckFo?= =?utf-8?B?OVhNejQzQ1NJWjZkQ3FyRzdiZFhxWERIdE4yM3cxY2xKT0V3Uy9zM0loZDRJ?= =?utf-8?B?Q01Ba2JUM3FTaGU5TTY2azhxLzF4cmVyN0lOc01NbnFVVktZUW91TVMyU2xB?= =?utf-8?B?OGowUzJPN2pKb3pPbFpBbUp0UkQ3bWlBN1lHUGdDbmh0cVFlTDV1Rm5CSkNN?= =?utf-8?B?VlcwU3RLWEpBK2g3dUhVZGo2MzRMd296M2xDOFZmNG5mb1B6K2s5U3k3QUJL?= =?utf-8?B?cFB6dUw0M2l0empYK0JVdklXdEc4Zm4xcXZiOTJQT3hib0RlU05uN3lyOTlO?= =?utf-8?B?TC9STzcvTDJkUDdQTHc5cGNRSkZiTThVc3puZlZKMG5Hcm5nMHdvLzd2azNG?= =?utf-8?B?bHd2YlZXLy91MmxZK2QvY0hWRzFPcHFWbXRDNWFuYnlPWWVRMkJpMUQ5M2t6?= =?utf-8?B?SEF3a1FYaDhnMGFuMFhycGkrYjBOaStjOHVZRkhCcEEwZGhubk5pOXorNGpF?= =?utf-8?B?VGxtMTVQUHVKS0EzR3dkL0pRVzBpMmNhWE1BRkUxMTBmeGh5Wkloc000QUFI?= =?utf-8?B?OFpJczR0QVZPdFNLY1UyVDNqS3NGMTRmbko5ajRrVW1wd3B6L0NRYXN6Rm9n?= =?utf-8?B?Z21nZ0tOWEFDM3NudVNqckhNcUVRVzFFL1B2b2RrVE1rdW04TWZyeEN3dytk?= =?utf-8?B?b05mQWUwb3REVWtJZzlWbkJZY1EzUkp3OGdaUHMvN2FNODNLT3JMRzl3N2pL?= =?utf-8?B?bWxGQ3FHVWNTTEswdkVwaFk5ZGphMUlQay9FV0hza0JxK3NUL3hidz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2d796125-a629-4d8e-8857-08de5b4bb303 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jan 2026 13:23:01.8858 (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: NLFwujCiT9MkXm66lEK73v5ZkllPpK9IDredRppqtgd0wznT/TGI3x7Eb1uheJIa1YldPk0yL/oxdj3li6o5ymDtDXawpnQqgujUHUyLrR0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR03MB5555 On 24/01/2026 12:32 am, Stefano Stabellini wrote: > On Thu, 15 Jan 2026, dmukhin@xen.org wrote: >> From: Denis Mukhin >> >> Use the new .config manipulation tool to toggle CONFIG_DEBUG in the >> Xen automation build script. >> >> Signed-off-by: Denis Mukhin >> --- >> automation/scripts/build | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/automation/scripts/build b/automation/scripts/build >> index 7a81d229decd..ee1127c53dc5 100755 >> --- a/automation/scripts/build >> +++ b/automation/scripts/build >> @@ -27,7 +27,7 @@ else >> # Start off with arch's defconfig >> make -C xen defconfig >> >> - echo "CONFIG_DEBUG=${debug}" >> xen/.config >> + xen/scripts/config --file xen/.config -${debug} DEBUG > I'd suggest to add: > > debug="${debug:-n}" > > before calling xen/scripts/config to avoid errors in case debug is not > set > > I could make the change on commit if you are OK with it $debug is always set in automation, which is why the script is written this way.  But being resilient might be better. >> if [[ -n "${EXTRA_XEN_CONFIG}" ]]; then >> echo "${EXTRA_XEN_CONFIG}" >> xen/.config This part of context is the same pattern, and wants a similar adjustment, although maybe the script wants a bulk adjustment mode.  This pattern is also repeated in the Eclair scripting too. ~Andrew From xen-devel-bounces@lists.xenproject.org Sat Jan 24 22:44:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 24 Jan 2026 22:44:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213014.1523754 (Exim 4.92) (envelope-from ) id 1vjmMY-00058l-2J; Sat, 24 Jan 2026 22:44:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213014.1523754; Sat, 24 Jan 2026 22:44: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 1vjmMX-00058d-TW; Sat, 24 Jan 2026 22:44:13 +0000 Received: by outflank-mailman (input) for mailman id 1213014; Sat, 24 Jan 2026 22: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 1vjmMW-00058X-JG for xen-devel@lists.xenproject.org; Sat, 24 Jan 2026 22:44:12 +0000 Received: from mail137-14.atl71.mandrillapp.com (mail137-14.atl71.mandrillapp.com [198.2.137.14]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 326671cd-f976-11f0-b15f-2bf370ae4941; Sat, 24 Jan 2026 23:44:10 +0100 (CET) Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail137-14.atl71.mandrillapp.com (Mailchimp) with ESMTP id 4dz8x44ckfz705bKY for ; Sat, 24 Jan 2026 22:44:08 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 22b6ef355cc64e5f95c652d1ed21de65; Sat, 24 Jan 2026 22:44: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: 326671cd-f976-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1769294648; x=1769564648; bh=4mQlw4NYHLnoMJjZf6lpMFq/9uu7VZMQDiPnuC7kldI=; 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=heyCuxPvz+HsQ+UajWs+CrVXVp2TAP4pa8dpzT1QMGE4HffuTrmB7iROumHd/vrfv tMxQwuRj4S8Id/BbIEXJ4aFeoylFc9hKJ7lcEbaNOHhzpEoQq5k51/qd4+Yk0UUNiF zCi4VMyLZ69m3hJ1v5JFYyWeUhXzShDXitr2qT6suraOJ94P1zL+zpbMAP3Tef3zYg mmScHi0TblUC+gz5Br0EXxBAdo9ejPge8mjyK0+qUYhOkr/xQdjnCE9PQACl2s1j71 8IobycMjk6wqyPP5RhXVIA1szL1N5fPYnMebjH4ZTniqLrI59fTyV1nDp941RZywsr WCPobtzkwexyA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1769294648; x=1769555148; i=teddy.astie@vates.tech; bh=4mQlw4NYHLnoMJjZf6lpMFq/9uu7VZMQDiPnuC7kldI=; 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=rjCUVZ0cappviWvvdRoS5tjhlv1QpJkBfRLmOl6AnfNNPM2eJZ5bIaQZxMNY1cqPE 5vP3v+G5Y9lcIRy1de3GbcatpQyHh84NSnX8dYXCVXyeY7M8MGujClviN8CX3/NjTy CQeNjb1RDE9r+KphZ2VBHtYIUrIBbIXWiAAtVCmkZORBPVo7daUA7KHNnjLPN8U3ZW shwmXF1XGrTEU7fyghDFv9pIMcFuFQDMc2RKoy0cIvkSdqW07l/xPa8DjXcN9c/r9V mlbe8sLakQRIpPN6xQldZraO2ozcQ8kQeaZX87t9UYSRcWlJ0Unv2bdNJKMMRKpjNT /mOXkJigau+fw== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=20v2=2003/16]=20xen/riscv:=20implement=20vcpu=5Fcsr=5Finit()?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1769294646609 Message-Id: <99289a63-b4be-42f8-974b-7445a6a479dc@vates.tech> To: "Oleksii Kurochko" , xen-devel@lists.xenproject.org Cc: "Alistair Francis" , "Connor Davis" , "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Jan Beulich" , "Julien Grall" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" , "Romain Caritey" References: <57ef3bcff854d4b50641641d300b3e8aa715c3c3.1769099885.git.oleksii.kurochko@gmail.com> In-Reply-To: <57ef3bcff854d4b50641641d300b3e8aa715c3c3.1769099885.git.oleksii.kurochko@gmail.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.22b6ef355cc64e5f95c652d1ed21de65?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260124:md Date: Sat, 24 Jan 2026 22:44:08 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 22/01/2026 =C3=A0 17:49, Oleksii Kurochko a =C3=A9crit=C2=A0: > Introduce vcpu_csr_init() to set up the initial hypervisor-visible CSR > state for a vCPU before it is first scheduled. To me, "hypervisor-visible CSR state" sounds like some state of the guest the hypervisor has view on. But to what I read, it's more hypervisor state CSRs regarding what to intercept and various virtualization behavior. > The function configures trap and interrupt delegation to VS-mode by > setting the appropriate bits in the hedeleg and hideleg registers, > initializes hstatus so that execution enters VS-mode when control is > passed to the guest, and restricts guest access to hardware performance > counters by initializing hcounteren, as unrestricted access would > require additional handling in Xen. > When the Smstateen and SSAIA extensions are available, access to AIA > CSRs and IMSIC guest interrupt files is enabled by setting the > corresponding bits in hstateen0, avoiding unnecessary traps into Xen > (note that SVSLCT(Supervisor Virtual Select) name is used intead of > CSRIND as OpenSBI uses such name and riscv_encoding.h is mostly based > on it). > If the Svpbmt extension is supported, the PBMTE bit is set in > henvcfg to allow its use for VS-stage address translation. Guest > access to the ENVCFG CSR is also enabled by setting ENVCFG bit in > hstateen0, as a guest may need to control certain characteristics of > the U-mode (VU-mode when V=3D1) execution environment. > > For CSRs that may contain read-only bits (e.g. hedeleg, hideleg, > hstateen0), the written value is re-read from hardware and cached in > vcpu->arch to avoid divergence between the software state and the actual > CSR contents. > AFAIU from RISC-V isa document, at least for some CSRs the read-only-0 bits are well-defined and means "can't be configured" due to not having a meaning (e.g hedeleg defines as read-only "Environment call from HS-mode" because guest can't be in a "actual" HS-mode). > As hstatus is not part of struct arch_vcpu (it already resides in > struct cpu_user_regs), introduce vcpu_guest_cpu_user_regs() to provide > a uniform way to access hstatus and other guest CPU user registers. > > This establishes a consistent and well-defined initial CSR state for > vCPUs prior to their first context switch. > > Signed-off-by: Oleksii Kurochko > --- > Changes in v2: > - As hstatus isn't a part of arch_vcpu structure (as it is already a pa= rt of > cpu_user_regs) introduce vcpu_guest_cpu_user_regs() to be able to acc= ess > hstatus and other CPU user regs. Sounds like hstatus wants to be splitted from guest_cpu_user_regs (which are supposed to be GPR ?). > - Sort hideleg bit setting by value. Drop a stray blank. > - Drop | when the first initialization of hcounteren and hennvcfg happe= n. > - Introduce HEDELEG_DEFAULT. Sort set bits by value and use BIT() macro= s > instead of open-coding it. > - Apply pattern csr_write() -> csr_read() for hedeleg and hideleg inste= ad > of direct bit setting in v->arch.h{i,e}deleg as it could be that for = some > reason some bits of hedeleg and hideleg are r/o. > The similar patter is used for hstateen0 as some of the bits could be= r/o. > - Add check that SSAIA is avaialable before setting of SMSTATEEN0_AIA | > SMSTATEEN0_IMSIC | SMSTATEEN0_SVSLCT bits. > - Drop local variables hstatus, hideleg and hedeleg as they aren't used > anymore. > --- > xen/arch/riscv/cpufeature.c | 1 + > xen/arch/riscv/domain.c | 73 +++++++++++++++++++++ > xen/arch/riscv/include/asm/cpufeature.h | 1 + > xen/arch/riscv/include/asm/current.h | 2 + > xen/arch/riscv/include/asm/riscv_encoding.h | 2 + > 5 files changed, 79 insertions(+) > > diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c > index 02b68aeaa49f..03e27b037be0 100644 > --- a/xen/arch/riscv/cpufeature.c > +++ b/xen/arch/riscv/cpufeature.c > @@ -137,6 +137,7 @@ const struct riscv_isa_ext_data __initconst riscv_isa= _ext[] =3D { > RISCV_ISA_EXT_DATA(zbb), > RISCV_ISA_EXT_DATA(zbs), > RISCV_ISA_EXT_DATA(smaia), > + RISCV_ISA_EXT_DATA(smstateen), > RISCV_ISA_EXT_DATA(ssaia), > RISCV_ISA_EXT_DATA(svade), > RISCV_ISA_EXT_DATA(svpbmt), > diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c > index 9c546267881b..3ae5fa3a8805 100644 > --- a/xen/arch/riscv/domain.c > +++ b/xen/arch/riscv/domain.c > @@ -5,6 +5,77 @@ > #include > #include > > +#include > +#include > +#include > + > +#define HEDELEG_DEFAULT (BIT(CAUSE_MISALIGNED_FETCH, U) | \ > + BIT(CAUSE_FETCH_ACCESS, U) | \ > + BIT(CAUSE_ILLEGAL_INSTRUCTION, U) | \ > + BIT(CAUSE_BREAKPOINT, U) | \ > + BIT(CAUSE_MISALIGNED_LOAD, U) | \ > + BIT(CAUSE_LOAD_ACCESS, U) | \ > + BIT(CAUSE_MISALIGNED_STORE, U) | \ > + BIT(CAUSE_STORE_ACCESS, U) | \ > + BIT(CAUSE_USER_ECALL, U) | \ > + BIT(CAUSE_FETCH_PAGE_FAULT, U) | \ > + BIT(CAUSE_LOAD_PAGE_FAULT, U) | \ > + BIT(CAUSE_STORE_PAGE_FAULT, U)) > + > +#define HIDELEG_DEFAULT (MIP_VSSIP | MIP_VSTIP | MIP_VSEIP) > + > +static void vcpu_csr_init(struct vcpu *v) > +{ > + register_t hstateen0; > + > + csr_write(CSR_HEDELEG, HEDELEG_DEFAULT); > + v->arch.hedeleg =3D csr_read(CSR_HEDELEG); > + > + vcpu_guest_cpu_user_regs(v)->hstatus =3D HSTATUS_SPV | HSTATUS_SPVP; > + > + csr_write(CSR_HIDELEG, HIDELEG_DEFAULT); > + v->arch.hideleg =3D csr_read(CSR_HIDELEG); > + To me, that feels odd to set machine CSR here. Especially if (I guess) that we would update them anyway during context switches. I think it would be better to have : - vcpu_csr_init -> sets initial state CSR in vcpu structure, doesn't touch machine CSR - context switching logic -> loads vcpu-specific machine CSR from vcpu structure We would have to make a context switch to enter the vcpu for the first time; but that's to be expected. With my proposal, we would also want to move the vcpu_csr_init() invocation to the place we initialize the vcpu_arch structure rather than the first time we schedule inside that vcpu. That would also allow to take account of per-domain configuration if we need to (e.g feature flags). > + /* > + * VS should access only the time counter directly. > + * Everything else should trap. > + */ > + v->arch.hcounteren =3D HCOUNTEREN_TM; > + > + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) ) > + { > + csr_write(CSR_HENVCFG, ENVCFG_PBMTE); > + v->arch.henvcfg =3D csr_read(CSR_HENVCFG); > + } > + > + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) > + { > + if (riscv_isa_extension_available(NULL, RISCV_ISA_EXT_ssaia)) > + /* > + * If the hypervisor extension is implemented, the same thre= e > + * bitsare defined also in hypervisor CSR hstateen0 but conc= ern > + * only the state potentially accessible to a virtual machin= e > + * executing in privilege modes VS and VU: > + * bit 60 CSRs siselect and sireg (really vsiselect and > + * vsireg) > + * bit 59 CSRs siph and sieh (RV32 only) and stopi (rea= lly > + * vsiph, vsieh, and vstopi) > + * bit 58 all state of IMSIC guest interrupt files, inc= luding > + * CSR stopei (really vstopei) > + * If one of these bits is zero in hstateen0, and the same b= it is > + * one in mstateen0, then an attempt to access the correspon= ding > + * state from VS or VU-mode raises a virtual instruction exc= eption. > + */ > + hstateen0 =3D SMSTATEEN0_AIA | SMSTATEEN0_IMSIC | SMSTATEEN0= _SVSLCT; > + > + /* Allow guest to access CSR_ENVCFG */ > + hstateen0 |=3D SMSTATEEN0_HSENVCFG; > + > + csr_write(CSR_HSTATEEN0, hstateen0); > + v->arch.hstateen0 =3D csr_read(CSR_HSTATEEN0); > + } > +} > + > static void continue_new_vcpu(struct vcpu *prev) > { > BUG_ON("unimplemented\n"); > @@ -33,6 +104,8 @@ int arch_vcpu_create(struct vcpu *v) > v->arch.xen_saved_context.sp =3D (register_t)v->arch.cpu_info; > v->arch.xen_saved_context.ra =3D (register_t)continue_new_vcpu; > > + vcpu_csr_init(v); > + > /* Idle VCPUs don't need the rest of this setup */ > if ( is_idle_vcpu(v) ) > return rc; > diff --git a/xen/arch/riscv/include/asm/cpufeature.h b/xen/arch/riscv/inc= lude/asm/cpufeature.h > index b69616038888..ef02a3e26d2c 100644 > --- a/xen/arch/riscv/include/asm/cpufeature.h > +++ b/xen/arch/riscv/include/asm/cpufeature.h > @@ -36,6 +36,7 @@ enum riscv_isa_ext_id { > RISCV_ISA_EXT_zbb, > RISCV_ISA_EXT_zbs, > RISCV_ISA_EXT_smaia, > + RISCV_ISA_EXT_smstateen, > RISCV_ISA_EXT_ssaia, > RISCV_ISA_EXT_svade, > RISCV_ISA_EXT_svpbmt, > diff --git a/xen/arch/riscv/include/asm/current.h b/xen/arch/riscv/includ= e/asm/current.h > index 58c9f1506b7c..5fbee8182caa 100644 > --- a/xen/arch/riscv/include/asm/current.h > +++ b/xen/arch/riscv/include/asm/current.h > @@ -48,6 +48,8 @@ DECLARE_PER_CPU(struct vcpu *, curr_vcpu); > #define get_cpu_current(cpu) per_cpu(curr_vcpu, cpu) > > #define guest_cpu_user_regs() ({ BUG_ON("unimplemented"); NULL; }) > +#define vcpu_guest_cpu_user_regs(vcpu) \ > + (&(vcpu)->arch.cpu_info->guest_cpu_user_regs) > > #define switch_stack_and_jump(stack, fn) do { \ > asm volatile ( \ > diff --git a/xen/arch/riscv/include/asm/riscv_encoding.h b/xen/arch/riscv= /include/asm/riscv_encoding.h > index 1f7e612366f8..dd15731a86fa 100644 > --- a/xen/arch/riscv/include/asm/riscv_encoding.h > +++ b/xen/arch/riscv/include/asm/riscv_encoding.h > @@ -228,6 +228,8 @@ > #define ENVCFG_CBIE_INV=09=09=09_UL(0x3) > #define ENVCFG_FIOM=09=09=09_UL(0x1) > > +#define HCOUNTEREN_TM BIT(1, U) > + > /* =3D=3D=3D=3D=3D User-level CSRs =3D=3D=3D=3D=3D */ > > /* User Trap Setup (N-extension) */ -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Sat Jan 24 23:13:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 24 Jan 2026 23:13:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213026.1523765 (Exim 4.92) (envelope-from ) id 1vjmol-0000Xf-4o; Sat, 24 Jan 2026 23:13:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213026.1523765; Sat, 24 Jan 2026 23:13:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjmol-0000XY-1I; Sat, 24 Jan 2026 23:13:23 +0000 Received: by outflank-mailman (input) for mailman id 1213026; Sat, 24 Jan 2026 23:13:21 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vjmoi-0000XS-VN for xen-devel@lists.xenproject.org; Sat, 24 Jan 2026 23:13:21 +0000 Received: from mail186-9.suw21.mandrillapp.com (mail186-9.suw21.mandrillapp.com [198.2.186.9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 418192cd-f97a-11f0-9ccf-f158ae23cfc8; Sun, 25 Jan 2026 00:13:13 +0100 (CET) Received: from pmta10.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail186-9.suw21.mandrillapp.com (Mailchimp) with ESMTP id 4dz9Zc0trwzK5vgvF for ; Sat, 24 Jan 2026 23:13:12 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id eddca7357d1d497c8c71b25ae0da9f21; Sat, 24 Jan 2026 23:13:12 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 418192cd-f97a-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1769296392; x=1769566392; bh=ireF3WvM8dkpMPE1sLDraNczGCHBvGRF4ghsfmTnaWw=; 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=Fc3s5goBSV52gPJQyqID/0fCej7HzXyNS9aIE6WfDFJ8RptU6bSICtCqhwtm/zF6n QEzy1Va3N4VH1VqLPvebR23974LuJfB4qDvS9kXenFl4EUZWGfDShMObsaropH/0mM c3F90AtKD2c8YyfncGnw7WuUWf1k2MG3WKTOG63D6d0RxOOEX6ine19qyt4/OwmDz8 NIPonL/3m+WEWZdgmPrgbIUHZPJsvpqYIZPRb/TRTUFE/wgo5k3GYJI6PsAcS4uZb5 6FYlQUebTkNLoNhlg5ylatbdZj+g5BqH8sGPv99u0MraD2zKT4RklB8jCYosZYQaqK 9GjHTCC4d5/pA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1769296392; x=1769556892; i=teddy.astie@vates.tech; bh=ireF3WvM8dkpMPE1sLDraNczGCHBvGRF4ghsfmTnaWw=; 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=aBZRzLmDNSuJ98mT3IEz4gtNewaBXLmZvoxnNK/hSFDQph+VN9IrKt90ZJESQuUB7 gKLpmxZs1ylPbBvPDEH4oseb4nbEpkNdIpyYPz3xsXwE8T3pCEcti+zlhOpQ6xtz7c CT8pKSWQx1LYQGowrfYHSbmIqC24sKdmnSKgDjSezapIHa4c64lSbT5/1Q45YxC6Cb 85SwtqWQrfgxZtbrj4h/O1HeLvqnv/aXaDioXwdRq/DUBEOVwUmE4rMeyvyzETQrM0 uSCUJynOKvY75CFQ5qFJIch0q2mUrhpfdePW5GGTOg3wunDaybIp3kcyqVTo2eVQX1 p3/7elLW1Rt9g== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=20v2=2013/16]=20xen/riscv:=20implement=20reprogram=5Ftimer()=20via=20SBI?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1769296390366 Message-Id: <1222e3c6-44c1-434b-974e-04851874c1ca@vates.tech> To: "Oleksii Kurochko" , xen-devel@lists.xenproject.org Cc: "Alistair Francis" , "Connor Davis" , "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Jan Beulich" , "Julien Grall" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Stefano Stabellini" , "Romain Caritey" References: <732635f43fb80daec332f78d4442b56bf5dfda98.1769099885.git.oleksii.kurochko@gmail.com> In-Reply-To: <732635f43fb80daec332f78d4442b56bf5dfda98.1769099885.git.oleksii.kurochko@gmail.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.eddca7357d1d497c8c71b25ae0da9f21?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260124:md Date: Sat, 24 Jan 2026 23:13:12 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 22/01/2026 =C3=A0 17:49, Oleksii Kurochko a =C3=A9crit=C2=A0: > Implement reprogram_timer() on RISC-V using the standard SBI timer call. > > The privileged architecture only defines machine-mode timer interrupts > (using mtime/mtimecmp). Therefore, timer services for S/HS/VS mode must > be provided by M-mode via SBI calls. SSTC (Supervisor-mode Timer Control) > is optional and is not supported on the boards available to me, so the > only viable approach today is to program the timer through SBI. > > reprogram_timer() enables/disables the supervisor timer interrupt and > programs the next timer deadline using sbi_set_timer(). If the SBI call > fails, the code panics, because sbi_set_timer() is expected to return > either 0 or -ENOSUPP (this has been stable from early OpenSBI versions to > the latest ones). The SBI spec does not define a standard negative error > code for this call, and without SSTC there is no alternative method to > program the timer, so the SBI timer call must be available. > > reprogram_timer() currently returns int for compatibility with the > existing prototype. While it might be cleaner to return bool, keeping the > existing signature avoids premature changes in case sbi_set_timer() ever > needs to return other values (based on which we could try to avoid > panic-ing) in the future. > > Signed-off-by: Oleksii Kurochko > --- > Changes in v2: > - Add TODO comment above sbi_set_timer() call. > - Update the commit message. > --- > xen/arch/riscv/stubs.c | 5 ----- > xen/arch/riscv/time.c | 43 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 43 insertions(+), 5 deletions(-) > > diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c > index 1f0add97b361..cb7546558b8e 100644 > --- a/xen/arch/riscv/stubs.c > +++ b/xen/arch/riscv/stubs.c > @@ -21,11 +21,6 @@ nodemask_t __read_mostly node_online_map =3D { { [0] = =3D 1UL } }; > > /* time.c */ > > -int reprogram_timer(s_time_t timeout) > -{ > - BUG_ON("unimplemented"); > -} > - > void send_timer_event(struct vcpu *v) > { > BUG_ON("unimplemented"); > diff --git a/xen/arch/riscv/time.c b/xen/arch/riscv/time.c > index 2c7af0a5d63b..f021ceab8ec4 100644 > --- a/xen/arch/riscv/time.c > +++ b/xen/arch/riscv/time.c > @@ -7,6 +7,9 @@ > #include > #include > > +#include > +#include > + > unsigned long __ro_after_init cpu_khz; /* CPU clock frequency in kHz. *= / > uint64_t __ro_after_init boot_clock_cycles; > > @@ -40,6 +43,46 @@ static void __init preinit_dt_xen_time(void) > cpu_khz =3D rate / 1000; > } > > +int reprogram_timer(s_time_t timeout) > +{ > + uint64_t deadline, now; > + int rc; > + > + if ( timeout =3D=3D 0 ) > + { > + /* Disable timers */ > + csr_clear(CSR_SIE, BIT(IRQ_S_TIMER, UL)); > + > + return 1; > + } Do disabling the timers interrupt actually stops the timer or just prevents Xen from receiving the timer interrupt ? If it doesn't "stop the timer", we probably would want to swap "enabling the timer interrupt" and "setting the timer through SBI" (to avoid potentially receiving a timer interrupt between these 2 operations). Though, it's unclear in SBI specification if the sbi_set_timer touches the timer interrupt masking or not (at least it does if you set a timer too far in the future). > + > + deadline =3D ns_to_ticks(timeout) + boot_clock_cycles; > + now =3D get_cycles(); > + if ( deadline <=3D now ) > + return 0; > + > + /* Enable timer */ > + csr_set(CSR_SIE, BIT(IRQ_S_TIMER, UL)); > + > + /* > + * TODO: When the SSTC extension is supported, it would be preferabl= e to > + * use the supervisor timer registers directly here for better > + * performance, since an SBI call and context switch would no = longer > + * be required. > + * > + * This would also reduce reliance on a specific SBI implement= ation. > + * For example, it is not ideal to panic() if sbi_set_timer() = returns > + * a non-zero value. Currently it can return 0 or -ENOSUPP, an= d > + * without SSTC we still need an implementation because only t= he > + * M-mode timer is available, and it can only be programmed in > + * M-mode. > + */ > + if ( (rc =3D sbi_set_timer(deadline)) ) > + panic("%s: timer wasn't set because: %d\n", __func__, rc); > +> + return 1; > +} > + > void __init preinit_xen_time(void) > { > if ( acpi_disabled ) -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Sun Jan 25 18:53:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 25 Jan 2026 18:53:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213178.1523774 (Exim 4.92) (envelope-from ) id 1vk5E4-0002LU-Na; Sun, 25 Jan 2026 18:52:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213178.1523774; Sun, 25 Jan 2026 18: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 1vk5E4-0002LM-Ia; Sun, 25 Jan 2026 18:52:44 +0000 Received: by outflank-mailman (input) for mailman id 1213178; Sun, 25 Jan 2026 18:52: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 1vk5E3-0002LG-AF for xen-devel@lists.xenproject.org; Sun, 25 Jan 2026 18:52:43 +0000 Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 04cd0967-fa1f-11f0-9ccf-f158ae23cfc8; Sun, 25 Jan 2026 19:52:39 +0100 (CET) Received: by mx.zohomail.com with SMTPS id 1769367152629127.78929580959903; Sun, 25 Jan 2026 10:52:32 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 04cd0967-fa1f-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; t=1769367155; cv=none; d=zohomail.com; s=zohoarc; b=cLxw9roBtPZ3ZDFulQP7UF/fixC+00no83BUU51snAMmP9sihWfWNJrPz6Vg6vCq5ZeeqigzwgfbW6qOsJ6ZCiMxgnrMxLQ7K/g8NPK19MLe2HTFlY/rAfXqNdeu5O9osjzTbqri32BKGoMbFSbm1dO4dWAg4qkBKrfFagM6u6g= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1769367155; 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=fpCDa+YmQ8klc3AsKbg4Y+UkSZywU76DhPfBguIqN5g=; b=RyQMlWyhr1f7JEGrNp84ecLVYQ7LeVmXc4MC8w24SkChCWx5UG76tAhvgUxBlaLX+8KRMhDl3o3BsIR9F8Q6HLvWjgaiY5ZjGrjEHowZAOonMRTU9jqzNAgzMuVba3YsP0USuC9tTKJ9PfL7/R97B3+PFY3v7/eEmmzMSOZPQ68= 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=1769367155; s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=fpCDa+YmQ8klc3AsKbg4Y+UkSZywU76DhPfBguIqN5g=; b=Oeb6yTqT6b1qdd96T3gu/nNr3wrMva6xIGvDvBuSDa9LUDDNZ2T2z5qwhvkoiAJy 6cgpcaf0dT2KZu2O/P1Vor13in0/q4IH6UmyIwULHTkUJS315qEtruTcmnHsXvgGyD8 YE5LSzCzTQrJt7K6gjj28Zi0shV2CbmHlF7hN5D8= Message-ID: <28556db6-1c04-4dcd-8e20-2c41d877d4bd@apertussolutions.com> Date: Sun, 25 Jan 2026 13:52:29 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Ping: [PATCH] flask: fix gcov build with gcc14+ To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" References: <875df90d-1d3a-416b-a958-3d3a31144f85@suse.com> <0e188989-9190-4f3b-9c45-f4e3d460daca@suse.com> Content-Language: en-US From: "Daniel P. Smith" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ZohoMailClient: External On 1/21/26 8:35 AM, Jan Beulich wrote: > On 21.01.2026 14:14, Daniel P. Smith wrote: >> Apologies, I've been on travel for the last two weeks and I wasn't comfortable acking this with just a read of the diff. The thing that bothers me that I want to understand better is why only after the else does it worry about null terminated. Additionally, stepping back, a casual reader of the code is going to wonder why only after some reads into the buffer does it need a null while others do not. > > I'm curious to know of an example or two which you refer to here, as ... The diff does not show the size of buf, and I was not going to assume the size. Had the explanation said something to the extent that when an array of size N is used as a buffer that is filled with N-1 (or less?) bytes under a conditional, gcc15 complains about the trailing bytes being uninitialized. Without the context about the buffer size, it was not clear to me from your explanation, or the link, as to why only under the else cases need setting the value on your last byte and not under the initial if. Now that I have better context, my initial concerns were not valid and am more comfortable providing the ack. Acked-by: Daniel P. Smith >> I think most people would find that as a red flag that an underlying issue is getting papers papered over. I will be back from travel this weekend and I will sit down and review with more context. >> >> V/r, >> DPS >> >> On January 19, 2026 8:50:02 AM CST, Jan Beulich wrote: >>> Daniel, >>> >>> On 08.01.2026 10:18, Jan Beulich wrote: >>>> Gcc's "threading" of conditionals can lead to undue warnings, as reported >>>> in e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116519 (no matter >>>> that the overall situation is different there). While my gcc15 complains >>>> ("buf[2] may be used uninitialized in this function") about only two of >>>> the three instances (not about the one in type_read()), adjust all three >>>> to be on the safe side. > > ... I've already extended the change to cover all three similar patterns, no > matter that only two triggered a warning. > > Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 26 01:43:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 01:43:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213253.1523784 (Exim 4.92) (envelope-from ) id 1vkBdQ-0007e6-JT; Mon, 26 Jan 2026 01:43:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213253.1523784; Mon, 26 Jan 2026 01: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 1vkBdQ-0007dy-EU; Mon, 26 Jan 2026 01:43:20 +0000 Received: by outflank-mailman (input) for mailman id 1213253; Mon, 26 Jan 2026 01:43: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 1vkBdP-0007dq-2y for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 01:43:19 +0000 Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [2607:f8b0:4864:20::f2f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 617a3e15-fa58-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 02:43:16 +0100 (CET) Received: by mail-qv1-xf2f.google.com with SMTP id 6a1803df08f44-88a26ce6619so55249876d6.3 for ; Sun, 25 Jan 2026 17:43:15 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 617a3e15-fa58-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; t=1769391794; cv=none; d=google.com; s=arc-20240605; b=lef6yUPyJp/RAGlSuUwSU8yHQfoYaappC8ZjrfIHhs6mcB+THer6+xGkmqDdWuPhpq 1oivQqUhqm3inmQCVWEryWnYOs0XV5B7lHv7dEGbwO6ISFhp/To5wfQuvgWM5I2MwOXT 4oY/S6NzJxKpl8ihgGzo9pERFSU8rRO9az8CX86kpiLBQPv+X7bNrO1ObiHwhXt2qLbg wLHXqokYZFkrqUEsiEJiSajShmG5vNlQxzVqcRoZ6Qqm5KfVfW1F+DOXyjDrwB5mcp/c SDVGeJbJYTaoOamlrOwNfzIUC06tNpQBKRzbacDMocEt/qWr0s7fZ1w9Km+8gGkXG7+S V8CA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=Td4QUCSFnNiGlIQcniNA/rp8ZfKnX5RqAxkcu4MfCJE=; fh=yO1yMD14bAceKbkyokr5DzCgIxCl0W9L3blG0KrUmA0=; b=NWJSo4t3X95lJLZbghy9rJRAdsnWlrCHbf0v5b40flJTOJVgVRirmUWoN+1pM0+UFE 08IGIqv5U+E7yCKHZB58rPuJ17iWQ2X4KZZq2dJbdJqsjmvlNod8jgGttBu0WfvesPk2 U7D/afqKYRphzHpXNwXF/YUjvxpLezzii9xmT3KWiLEIxpWZ18cB+kR4dAh1WzywXBrY M080mqQQiwQyfnY3g5QXJQ0I2kcP9r8PapoJydG/JZcvIwMKdiVdw+MB4sz5Y5zZm18v GFIeTBJFBqhIZQbN+hLrMHS9ASlV9V78DvCeFSbG2o0yeCsYjmpXOxfzC7bac9SuTi3i jRIw==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769391794; x=1769996594; 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=Td4QUCSFnNiGlIQcniNA/rp8ZfKnX5RqAxkcu4MfCJE=; b=Vds0J8qG6V17NrD7x6XVcnal6BXqopvyIxpoVEpeYW8Rg4blqPo8HqiWCO7F6ol/FH UGnBjanZ1DD/yu7Ml4yWCP/oWy78k/Tu2Ih/WxompBnULN5PnDnld2mG4j+xe8kHpCiZ sVnlKwvk87RAD+55YCbN3sgKR2PPZEQ+k3wooYQuR3TVphrq4ys47qoSDR3DaRysJBK7 7jE54JC73IUBgCCIO9vEsMkMTKRM/eYjbhQUyP3pU/EEZhbpAAtHcptfLAjNAcXSueyv ppp+5SpqAnFULp0ZAd6L4GXeTObZwnFzuU/VzLfric2BXdljPklZoeiDjkVyrMbMF7el ajdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769391794; x=1769996594; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Td4QUCSFnNiGlIQcniNA/rp8ZfKnX5RqAxkcu4MfCJE=; b=uujxiWzpHfcMeRcyHiZ1ndl5S0Pi9RTblu7kW5oqGwzGW3Frv7lDJ4ZsyGFOCmQXiL bTqL+08mZ7R7n80Xlf+d1FjfQdDHeqOFw+5FchaLXk2A6xt+uh4jhfBe5j1uJv2pt0Ih ehc5fSrvLmia/Y2OZbT+j5lGiKTlgqRml9gLU2OhoccpB5BU3rz7402/sqN2jIgaj6/g gk1P3y9rB9mcL93Tz9yLfSJl8qOiNubh29uXtvgRM34a/1zXG78QrWiU9SrLYj/tKeCj 3TIj5Gvc7GgpGyV0kvxK1Vge9DVrpKy3sTRnXdLJ9KuwnG4bW5RA7RYOYFlEOTmsbZrZ SuhQ== X-Forwarded-Encrypted: i=1; AJvYcCXIAroCdLLqbNHNwBsQt2/vZqQU4TdUK0F5027LCcW0M0jUu3nbY8o7fVTpd7p7xbspxdEqMX6bvOM=@lists.xenproject.org X-Gm-Message-State: AOJu0YzezgRogv4keMRncHN5Uvu9+iPlC9DqPtwbjOFxDxBEsNxOmaAG KnTsm2ICXYW5Dw8dAzBel+VmxQE9HrJ4+A8BeHnzNhnc7kTohuT9l6Cxl3qgZ8W2kvR3zOLCbZ3 fJWmm/cbQYh51QE/ATjaIUSNS78T4pesQUSe9 X-Gm-Gg: AZuq6aLnXgsquweLT4lXoA6CuDqj8s5Dxv16Vwwhy4uxkEs+43HEJgNgCjiSQYncqqv exjFghUFifHv3iupXB/eBoaEmxCNnXVSA9Oy6dAMKnHMTy7y6ePdqlmvxJoU3fAyGwhhWkWOkTa qWvy4JfCujMPF9NhYhtz5/uXtEdTvVbAOqsPTEg4aRJzZYgea+q25EDaMrLusnFI2KpkSnQF7JQ DlL/gutts2/T43oTlKNh7nDbehgKiGmGKEfmRAgiFTxaRJl3Gi9Zf6gkwP9FJAcA3zUT0o/7A== X-Received: by 2002:a05:6214:d85:b0:88a:4452:750b with SMTP id 6a1803df08f44-894b0792ademr38139946d6.60.1769391793952; Sun, 25 Jan 2026 17:43:13 -0800 (PST) MIME-Version: 1.0 References: <20251226225254.46197-1-21cnbao@gmail.com> <20251226225254.46197-2-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Mon, 26 Jan 2026 09:43:02 +0800 X-Gm-Features: AZwV_QjeDywrcz2eWqXN9SXa7QL5VefpgErEyUZbE549AGDu67lQKOvE9Fh-udU Message-ID: Subject: Re: [PATCH v2 1/8] arm64: Provide dcache_by_myline_op_nosync helper To: Will Deacon Cc: catalin.marinas@arm.com, m.szyprowski@samsung.com, robin.murphy@arm.com, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Leon Romanovsky , Ada Couprie Diaz , Ard Biesheuvel , Marc Zyngier , Anshuman Khandual , Ryan Roberts , Suren Baghdasaryan , Tangquan Zheng Content-Type: text/plain; charset="UTF-8" [...] > > */ > > - .macro dcache_by_myline_op op, domain, start, end, linesz, tmp, fixup > > + .macro raw_dcache_by_myline_op op, start, end, linesz, tmp, fixup > > sub \tmp, \linesz, #1 > > bic \start, \start, \tmp > > .Ldcache_op\@: > > @@ -402,14 +401,13 @@ alternative_endif > > add \start, \start, \linesz > > cmp \start, \end > > b.lo .Ldcache_op\@ > > - dsb \domain > > Naming nit, but I'd prefer this to be dcache_by_myline_op_nosync() for > consistency with the other macros that you're adding. The 'raw' prefix > is used by raw_dcache_line_size() to indicate that we're getting the > value from the underlying hardware register. Ok. thanks! > > > > > _cond_uaccess_extable .Ldcache_op\@, \fixup > > .endm > > > > /* > > * Macro to perform a data cache maintenance for the interval > > - * [start, end) > > + * [start, end) and wait for completion > > * > > * op: operation passed to dc instruction > > * domain: domain used in dsb instruction > > @@ -420,7 +418,23 @@ alternative_endif > > */ > > .macro dcache_by_line_op op, domain, start, end, tmp1, tmp2, fixup > > dcache_line_size \tmp1, \tmp2 > > - dcache_by_myline_op \op, \domain, \start, \end, \tmp1, \tmp2, \fixup > > + raw_dcache_by_myline_op \op, \start, \end, \tmp1, \tmp2, \fixup > > + dsb \domain > > + .endm > > This could just be dcache_by_line_op_nosync() + dsb. Ok. thanks! Best Regards Barry From xen-devel-bounces@lists.xenproject.org Mon Jan 26 07:08:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 07:08:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213308.1523794 (Exim 4.92) (envelope-from ) id 1vkGiA-0003qb-6S; Mon, 26 Jan 2026 07:08:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213308.1523794; Mon, 26 Jan 2026 07: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 1vkGiA-0003qU-2w; Mon, 26 Jan 2026 07:08:34 +0000 Received: by outflank-mailman (input) for mailman id 1213308; Mon, 26 Jan 2026 07:08: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 1vkGi8-0003qO-Th for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 07:08:33 +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 d1cab869-fa85-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 08:08:30 +0100 (CET) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-b8863db032dso430723866b.0 for ; Sun, 25 Jan 2026 23:08:30 -0800 (PST) Received: from ?IPV6:2a00:12d0:af5b:2f01:4042:c03:ce4d:a5a1? (2a00-12d0-af5b-2f01-4042-c03-ce4d-a5a1.ip.tng.de. [2a00:12d0:af5b:2f01:4042:c03:ce4d:a5a1]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b885b41801dsm602561966b.23.2026.01.25.23.08.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 25 Jan 2026 23:08:29 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d1cab869-fa85-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769411310; x=1770016110; darn=lists.xenproject.org; h=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=1cvBUL8mJ67LCy7rZqUyBxqcZLcMww9qmMfpv+ERFlA=; b=CqCQ/pTA15FO6fQF12YLca3K/Y+966+bN5P7sAOWDOwaip/NDjuAj4o1Uyj4u9FnyR cBNrfbNphIbkW/W+xn2/UyX0VIIm4S7OBkOyv+O8xrgKPtyXYDJSiEd9PysFDHeL/Sfb KyclRMZpgDAcHEXspD/iW6q0YC/IVo8SLRree3VmACRU7n94J8Zzg8eO2meTIxMGrN6q PiJpaYtn4HKjAO16qaHHUyoIbAawonhJXLxa0Hk7+rGcjfK4V8srHOIdBs8xJWTvBwn8 GaLfOQ9O7mHNesI7bDVXCVfZnx3fcM85s6KFWa9dySLgAeYPYfiC+U+mN8+I6zAsqP00 6oig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769411310; x=1770016110; h=in-reply-to:autocrypt:content-language:references:cc:to:from :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1cvBUL8mJ67LCy7rZqUyBxqcZLcMww9qmMfpv+ERFlA=; b=EPFbLgrg2kuoWdUBrwG0bqMDvf2+hGuy0l8v6LKrUiePwfWGk91IBmT/yqC9vW8UaP u4eGOJVUdct1jDGJOGa+UuzFSgYOJQmjO+wIg0dDV4qCEcNLENFHxu2uWsBrX5+V5IiR AtP9cmJaIgovv065s8eBThQvfZ1PIAeQqi1HSmi7Opi/1lK8AYQSbQz0gw1rp5mTm4fT 9j7D2oocWNKcHEAKCcnbvOpeeY3KrVKEdOFGq+aRo+MryKTSRfXQmmEq9REinuGlObPH ADuXFcKvljZUo0wUaHGc0RtDbomafQd0jVMAyR+yMtxp488jGo46LNjJRlLsL1I6OCYY edNw== X-Forwarded-Encrypted: i=1; AJvYcCV98ac5Okw14xt2pYjfAj+FlJEEJdsRaLgRHgYCm6tu/sxQuhNVWrKFDCpvK7638ZoXiAUwzwZ+UMI=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw+H/0drLlzLrEhbTNb5hSFqhSv66sVLO0dBEMtN5tvg2tdqK0c 8YppwTkWSDFCgKcmq7V1f0RrsPtBspxyBy6vw1ypBli77KDzk805HGKXTQfsxYK+qsc= X-Gm-Gg: AZuq6aKj5SO6U40EF5eT7E6BBoklTg/hEcq8Qiy+WQHcemeQfmd9Iajs99ONHeOH7oK VufXdUa9zQW5ukOw3TuENaS7qSUYINemWnvN/fmwdYi7OqS3KCAcJgl/MgvLiT1H2kkBGLuIgHr NmYDcIUPQbdzVDorGo+YDkRJ0ZAWntp/TzTr8WgXeNix7fx9uCK2dICHASsHCEiAKrsjKvdwvha H82E/TV2tdnoQO/ffcP5OGpEKAfwBvb3gfhHl9uLx3N+eqvhcerP9oIisc1wHx9vzg2Q6aH5hWv MxChoVoJ2zou6EeffHE8an/QJCGh8fo4l/JmOHZiCHI87UCLHU7WehLQwDUwgzqdIpeMXQfVJuv 4qlz201ZvvE1jGEGltoBmobAiwEgpHMey35PMjh1kSSThT8vm3EVnKJEy430Mgi4rPapZvXh5BH INiOrR0SGrhXTEsa3P1eEexlemD7fvG+itY6hBDPv1NpYBqrFH91c1sqqbpAupRWTHpPQN4hsb7 3x2wZcZgBoMpkpa0dFCL8h8Uwfc8L/IlSpDuw== X-Received: by 2002:a17:907:86a6:b0:b88:6e10:62c8 with SMTP id a640c23a62f3a-b8d2e8fe361mr238762466b.2.1769411309970; Sun, 25 Jan 2026 23:08:29 -0800 (PST) Message-ID: <261c3ced-7f40-4c2f-93da-0e020f9bcf3a@suse.com> Date: Mon, 26 Jan 2026 08:08:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/xenbus: better handle backend crash From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , linux-kernel@vger.kernel.org Cc: Stefano Stabellini , Oleksandr Tyshchenko , Peng Jiang , Qiu-ji Chen , Jason Andryuk , "moderated list:XEN HYPERVISOR INTERFACE" References: <20251102032105.772670-1-marmarek@invisiblethingslab.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="------------BaSJAF3NX8vc2gE09eXeuGtj" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------BaSJAF3NX8vc2gE09eXeuGtj Content-Type: multipart/mixed; boundary="------------zOdtnu6ITJ05QRU7ZV5wJ0LU"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , linux-kernel@vger.kernel.org Cc: Stefano Stabellini , Oleksandr Tyshchenko , Peng Jiang , Qiu-ji Chen , Jason Andryuk , "moderated list:XEN HYPERVISOR INTERFACE" Message-ID: <261c3ced-7f40-4c2f-93da-0e020f9bcf3a@suse.com> Subject: Re: [PATCH] xen/xenbus: better handle backend crash References: <20251102032105.772670-1-marmarek@invisiblethingslab.com> In-Reply-To: --------------zOdtnu6ITJ05QRU7ZV5wJ0LU Content-Type: multipart/mixed; boundary="------------b0M8FBGxmcq9wW7ymi9a03dK" --------------b0M8FBGxmcq9wW7ymi9a03dK Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTcuMTEuMjUgMTI6MDYsIErDvHJnZW4gR3Jvw58gd3JvdGU6DQo+IE9uIDAyLjExLjI1 IDA0OjIwLCBNYXJlayBNYXJjenlrb3dza2ktR8OzcmVja2kgd3JvdGU6DQo+PiBXaGVuIHRo ZSBiYWNrZW5kIGRvbWFpbiBjcmFzaGVzLCBjb29yZGluYXRlZCBkZXZpY2UgY2xlYW51cCBp cyBub3QNCj4+IHBvc3NpYmxlIChhcyBpdCBpbnZvbHZlcyB3YWl0aW5nIGZvciB0aGUgYmFj a2VuZCBzdGF0ZSBjaGFuZ2UpLiBJbiB0aGF0DQo+PiBjYXNlLCB0b29sc3RhY2sgZm9yY2Vm dWxseSByZW1vdmVzIGZyb250ZW5kIHhlbnN0b3JlIGVudHJpZXMuDQo+PiB4ZW5idXNfZGV2 X2NoYW5nZWQoKSBoYW5kbGVzIHRoaXMgY2FzZSwgYW5kIHRyaWdnZXJzIGRldmljZSBjbGVh bnVwLg0KPj4gSXQncyBwb3NzaWJsZSB0aGF0IHRvb2xzdGFjayBtYW5hZ2VzIHRvIGNvbm5l Y3QgbmV3IGRldmljZSBpbiB0aGF0DQo+PiBwbGFjZSwgYmVmb3JlIHhlbmJ1c19kZXZfY2hh bmdlZCgpIG5vdGljZXMgdGhlIG9sZCBvbmUgaXMgbWlzc2luZy4gSWYNCj4+IHRoYXQgaGFw cGVucywgbmV3IG9uZSB3b24ndCBiZSBwcm9iZWQgYW5kIHdpbGwgZm9yZXZlciByZW1haW4g aW4NCj4+IFhlbmJ1c1N0YXRlSW5pdGlhbGlzaW5nLg0KPj4NCj4+IEZpeCB0aGlzIGJ5IGNo ZWNraW5nIGJhY2tlbmQtaWQgYW5kIGlmIGl0IGNoYW5nZXMsIGNvbnNpZGVyIGl0DQo+PiB1 bnBsdWcrcGx1ZyBvcGVyYXRpb24uIEl0J3MgaW1wb3J0YW50IHRoYXQgY2xlYW51cCBvbiBz dWNoIHVucGx1Zw0KPj4gZG9lc24ndCBtb2RpZnkgeGVuc3RvcmUgZW50cmllcyAoZXNwZWNp YWxseSB0aGUgInN0YXRlIiBrZXkpIGFzIGl0DQo+PiBiZWxvbmcgdG8gdGhlIG5ldyBkZXZp Y2UgdG8gYmUgcHJvYmVkIC0gY2hhbmdpbmcgaXQgd291bGQgZGVyYWlsDQo+PiBlc3RhYmxp c2hpbmcgY29ubmVjdGlvbiB0byB0aGUgbmV3IGJhY2tlbmQgKG1vc3QgbGlrZWx5LCBjbG9z aW5nIHRoZQ0KPj4gZGV2aWNlIGJlZm9yZSBpdCB3YXMgZXZlbiBjb25uZWN0ZWQpLiBIYW5k bGUgdGhpcyBjYXNlIGJ5IHNldHRpbmcgbmV3DQo+PiB4ZW5idXNfZGV2aWNlLT52YW5pc2hl ZCBmbGFnIHRvIHRydWUsIGFuZCBjaGVjayBpdCBiZWZvcmUgY2hhbmdpbmcgc3RhdGUNCj4+ IGVudHJ5Lg0KPj4NCj4+IEFuZCBldmVuIGlmIHhlbmJ1c19kZXZfY2hhbmdlZCgpIGNvcnJl Y3RseSBkZXRlY3RzIHRoZSBkZXZpY2Ugd2FzDQo+PiBmb3JjZWZ1bGx5IHJlbW92ZWQsIHRo ZSBjbGVhbnVwIGhhbmRsaW5nIGlzIHN0aWxsIHJhY3kuIFNpbmNlIHRoaXMgd2hvbGUNCj4+ IGhhbmRsaW5nIGRvZXNuJ3QgaGFwcGVuZCBpbiBhIHNpbmdsZSB4ZW5zdG9yZSB0cmFuc2Fj dGlvbiwgaXQncyBwb3NzaWJsZQ0KPj4gdGhhdCB0b29sc3RhY2sgbWlnaHQgcHV0IGEgbmV3 IGRldmljZSB0aGVyZSBhbHJlYWR5LiBBdm9pZCByZS1jcmVhdGluZw0KPj4gdGhlIHN0YXRl IGtleSAod2hpY2ggaW4gdGhlIGNhc2Ugb2YgbG9vc2luZyB0aGUgcmFjZSB3b3VsZCBhY3R1 YWxseQ0KPj4gY2xvc2UgbmV3bHkgYXR0YWNoZWQgZGV2aWNlKS4NCj4+DQo+PiBUaGUgcHJv YmxlbSBkb2VzIG5vdCBhcHBseSB0byBmcm9udGVuZCBkb21haW4gY3Jhc2gsIGFzIHRoaXMg Y2FzZQ0KPj4gaW52b2x2ZXMgY29vcmRpbmF0ZWQgY2xlYW51cC4NCj4+DQo+PiBQcm9ibGVt IG9yaWdpbmFsbHkgcmVwb3J0ZWQgYXQNCj4+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hl bi1kZXZlbC9hT1p2aXZ5WjlZaFZXRExOQG1haWwtaXRsL1QvI3QsDQo+PiBpbmNsdWRpbmcg cmVwcm9kdWN0aW9uIHN0ZXBzLg0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6IE1hcmVrIE1hcmN6 eWtvd3NraS1Hw7NyZWNraSA8bWFybWFyZWtAaW52aXNpYmxldGhpbmdzbGFiLmNvbT4NCj4g DQo+IFNvcnJ5IEkgZGlkbid0IGdldCBlYXJsaWVyIHRvIHRoaXMuDQo+IA0KPiBNeSBtYWlu IHByb2JsZW0gd2l0aCB0aGlzIHBhdGNoIGlzIHRoYXQgaXQgaXMgYmFzaWNhbGx5IGp1c3Qg cGFwZXJpbmcgb3Zlcg0KPiBhIG1vcmUgZ2VuZXJhbCBwcm9ibGVtLg0KPiANCj4gWW91IGFy ZSBqdXN0IG1ha2luZyB0aGUgcHJvYmxlbSBtdWNoIG1vcmUgaW1wcm9iYWJsZSwgYnV0IG5v dCBpbXBvc3NpYmxlIHRvDQo+IG9jY3VyIGFnYWluLiBJbiBjYXNlIHRoZSBuZXcgZHJpdmVy IGRvbWFpbiBoYXMgdGhlIHNhbWUgZG9taWQgYXMgdGhlIG9sZCBvbmUNCj4geW91IGNhbiBz dGlsbCBoYXZlIHRoZSBzYW1lIHJhY2UuDQo+IA0KPiBUaGUgY2xlYW4gd2F5IHRvIGhhbmRs ZSB0aGF0IHdvdWxkIGJlIHRvIGFkZCBhIHVuaXF1ZSBJZCBpbiBYZW5zdG9yZSB0byBlYWNo DQo+IGRldmljZSBvbiB0aGUgYmFja2VuZCBzaWRlLCB3aGljaCBjYW4gYmUgdGVzdGVkIG9u IHRoZSBmcm9udGVuZCBzaWRlIHRvDQo+IG1hdGNoLiBJbiBjYXNlIGl0IGRvZXNuJ3QgbWF0 Y2gsIGFuIG9sZCBkZXZpY2Ugd2l0aCB0aGUgc2FtZSBraW5kIGFuZCBkZXZpZA0KPiBjYW4g YmUgY2xlYW5lZCB1cC4NCj4gDQo+IFRoZSB1bmlxdWUgSWQgd291bGQgb2J2aW91c2x5IG5l ZWQgdG8gYmUgc2V0IGJ5IHRoZSBYZW4gdG9vbHMgaW5zaWRlIHRoZQ0KPiB0cmFuc2FjdGlv biB3cml0aW5nIHRoZSBpbml0aWFsIGJhY2tlbmQgWGVuc3RvcmUgbm9kZXMsIGFzIGRvaW5n IHRoYXQgZnJvbQ0KPiB0aGUgYmFja2VuZCB3b3VsZCBhZGQgYW5vdGhlciBwb3RlbnRpYWwg YW1iaWd1aXR5IGJ5IHRoZSBkcml2ZXIgZG9tYWluDQo+IGNob29zaW5nIHRoZSBzYW1lIHVu aXF1ZSBpZCBhcyB0aGUgcHJldmlvdXMgb25lIGRpZC4NCj4gDQo+IFRoZSBxdWVzdGlvbiBp cyB3aGV0aGVyIHNvbWV0aGluZyBsaWtlIHlvdXIgcGF0Y2ggc2hvdWxkIGJlIHVzZWQgYXMg YQ0KPiBmYWxsYmFjayBpbiBjYXNlIHRoZXJlIGlzIG5vIHVuaXF1ZSBJZCBvbiB0aGUgYmFj a2VuZCBzaWRlIG9mIHRoZSBkZXZpY2UNCj4gZHVlIHRvIGEgdG9vIG9sZCBYZW4gdmVyc2lv bi4NCg0KSSB0aGluayBJIGhhdmUgZm91bmQgYSBzb2x1dGlvbiB3aGljaCBpcyBtdWNoIG1v cmUgc2ltcGxlLCBhcyBpdCBkb2Vzbid0DQpuZWVkIGFueSBjaGFuZ2Ugb2YgdGhlIHByb3Rv Y29sIG9yIGFueSBhZGRpdGlvbiBvZiBuZXcgaWRlbnRpZmllcnMuDQoNCldoZW4gY3JlYXRp bmcgYSBuZXcgUFYgZGV2aWNlLCBYZW4gdG9vbHMgd2lsbCBhbHdheXMgd3JpdGUgYWxsIGdl bmVyaWMNCmZyb250ZW5kLSBhbmQgYmFja2VuZC1ub2Rlcy4gVGhpcyBpbmNsdWRlcyB0aGUg ZnJvbnRlbmQgc3RhdGUsIHdoaWNoIGlzDQppbml0aWFsaXplZCBhcyBYZW5idXNTdGF0ZUlu aXRpYWxpc2luZy4NCg0KVGhlIExpbnV4IGtlcm5lbCdzIHhlbmJ1cyBkcml2ZXIgaXMgYWxy ZWFkeSBzdG9yaW5nIHRoZSBsYXN0IGtub3duIHN0YXRlDQpvZiBhIHhlbmJ1cyBkZXZpY2Ug aW4gc3RydWN0IHhlbmJ1c19kZXZpY2UuIFdoZW4gY2hhbmdpbmcgdGhlIHN0YXRlLCB0aGUN CnhlbmJ1cyBkcml2ZXIgaXMgZXZlbiByZWFkaW5nIHRoZSBzdGF0ZSBmcm9tIFhlbnN0b3Jl IChldmVuIGlmIG9ubHkgZm9yDQptYWtpbmcgc3VyZSB0aGUgcGF0aCBpcyBzdGlsbCBleGlz dGluZykuIFNvIGFsbCB3aGF0IGlzIG5lZWRlZCBpcyB0byBjaGVjaywNCndoZXRoZXIgdGhl IHJlYWQgY3VycmVudCBzdGF0ZSBpcyBtYXRjaGluZyB0aGUgbG9jYWxseSBzYXZlZCBzdGF0 ZS4gSWYgaXQNCmlzIG5vdCBtYXRjaGluZyBBTkQgdGhlIHJlYWQgc3RhdGUgaXMgWGVuYnVz U3RhdGVJbml0aWFsaXNpbmcsIHlvdSBjYW4gYmUNCnN1cmUgdGhhdCB0aGUgYmFja2VuZCBo YXMgYmVlbiByZXBsYWNlZC4NCg0KSGFuZGxpbmcgdGhpcyB3aWxsIG5lZWQgdG8gY2hlY2sg dGhlIHJldHVybiB2YWx1ZSBvZiB4ZW5idXNfc3dpdGNoX3N0YXRlKCkNCmluIGFsbCByZWxh dGVkIGRyaXZlcnMsIGJ1dCB0aGlzIGlzIGp1c3QgYSBtb3JlIG9yIGxlc3MgbWVjaGFuaWNh bCBjaGFuZ2UuDQoNCkknbGwgcHJlcGFyZSBhIHBhdGNoIHNlcmllcyBmb3IgdGhhdC4NCg0K DQpKdWVyZ2VuDQo= --------------b0M8FBGxmcq9wW7ymi9a03dK 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----- --------------b0M8FBGxmcq9wW7ymi9a03dK-- --------------zOdtnu6ITJ05QRU7ZV5wJ0LU-- --------------BaSJAF3NX8vc2gE09eXeuGtj 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/Ey8FAml3Eu0FAwAAAAAACgkQsN6d1ii/Ey/u IAf9FTyVT/+Kosby+4FY8mQX56pE9gwnUkqrzyJxeUlurtmxy8zE5EF1VgKeb8Mjng0fb2flVMv0 iyrdtITeDkxx8NWu6Ao3wXe9r/Hqt+bR+ZpHn313yR01fppWcKj0Wu25W2tWpBVKBg+9UMJpD229 VG/9pS572PuGJCOTEssFWnvzzrs91s1ZTwyKEa1OVRKnLK5RF2t9hQtUbHLmr/0wUHG1aIi+QFGz zcOjzO8pJ+Bd94y1mt6D0kxdrRzqQFYbhh4Kupm7ZrixId5IEk1OTny7e1AcvivV3N8DVsBZCV5S YMXIqSP/vjfDRt9lwj+EG8aUbAUfPVEyNRIK7kGCDw== =jKVc -----END PGP SIGNATURE----- --------------BaSJAF3NX8vc2gE09eXeuGtj-- From xen-devel-bounces@lists.xenproject.org Mon Jan 26 07:16:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 07:16:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213319.1523803 (Exim 4.92) (envelope-from ) id 1vkGpj-0005Ty-11; Mon, 26 Jan 2026 07:16:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213319.1523803; Mon, 26 Jan 2026 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 1vkGpi-0005Tr-UZ; Mon, 26 Jan 2026 07:16:22 +0000 Received: by outflank-mailman (input) for mailman id 1213319; Mon, 26 Jan 2026 07:16: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 1vkGph-0005Ti-Rn for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 07:16: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 e75349cc-fa86-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 08:16:17 +0100 (CET) Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by DM4PR12MB6543.namprd12.prod.outlook.com (2603:10b6:8:8c::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Mon, 26 Jan 2026 07:16:13 +0000 Received: from DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::6d8e:2499:8a0a:7eb2]) by DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::6d8e:2499:8a0a:7eb2%2]) with mapi id 15.20.9542.010; Mon, 26 Jan 2026 07:16: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: e75349cc-fa86-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Cl5QAU4Vf1ue79bGf/sa4OTH3JqUyGIj44N93G7hc1h6rOtUtbksqEivpQuMbOAawwwokaUwoXBJN2vXblZzLrtgCd5qTYeAzXHYwOj/nouSzNrsMv1uxhdtVDHJS/V6HJDmuKAxMLCAHj/PSAR2ATIPXyZ6dWIAU5zUys+rpoNvplO764x382KYd2JmuRLHNaA+M886yKmEvazJXYHwp1a92DPLY3u0iz+wrcit/ZwYCIrCNAC2Xex8jY5EVy7Qu6YjCW2Lr2lAzrwPzLJw8XhaXlmiFdip4p3+y69LuxrmoPvLHvlfrT0fbVJbf+LBJnCfUB66Rba1fSc1m7t+iA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qwgyqd+lH+cfCzFk+ov4iAD3iv/TFfNAbBtfRsbuSvM=; b=x+H0FbnLPafzbFtZ4sjaS8Q/9eccCVCBDIS0DoEz/QXrV0JrpLvwEC6bFADm2pVHHm6Kb+PaIpo3BUEq7P+l2qBXrKXjFj5y2It+rfaKIi0sKYyL1brjsUfUiuDfU2ehDNPqN3fr6iafeofa8UU8BD9cVLhkCN54P+NeyxE2XZe7JBUoQxGi+Pi/dGIbXuMugc9fJMBSrtb9g9D99kXy01YeMPgU+vHXzeq+gLQIngDpFiiCYGrVFoDP+MIbjQes7h3+EQqpqFBlSE06d2Fp/5NyVjxw4eJOE2uiys3tMe3GbWlUhaNQzoOw2cJPUsgK5dNbItAg73DqQPVbkCNE9w== 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=qwgyqd+lH+cfCzFk+ov4iAD3iv/TFfNAbBtfRsbuSvM=; b=gjd1oEk/plOB3QQpjuALiVuDmswDRB3buHGWMZxIB1OEWMUJmt/H2OWEyeLrJDmWJm9JjfHUu7g5tgBTdboxfFc0JaH8rBRrtfH6fbKjvGwhzPXT6I5HqFi5biemvriujYkiP5/2wF0/PQwVK5HDPlHV5mEPeUavNyjR4/8OMv4= From: "Penny, Zheng" To: Jan Beulich , "xen-devel@lists.xenproject.org" CC: Andrew Cooper , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Subject: RE: [PATCH 3/5] cpufreq/amd-cppc: move driver data into policy Thread-Topic: [PATCH 3/5] cpufreq/amd-cppc: move driver data into policy Thread-Index: AQHci4OE/XB6ICRJE06j5TZK0wfV/LVkD9kQ Date: Mon, 26 Jan 2026 07:16:12 +0000 Message-ID: References: <519e16df-150a-4336-95dc-b26b8332a884@suse.com> In-Reply-To: <519e16df-150a-4336-95dc-b26b8332a884@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=2026-01-26T07:15:33.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|DM4PR12MB6543:EE_ x-ms-office365-filtering-correlation-id: b390457d-b560-4ff6-ed69-08de5caac99a 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?TyswM2t6N3RZa2JNZmhWMjVJUm1hTzNoU3Bwd3BjVkFteHdSNDd3dWZYdmhX?= =?utf-8?B?djZyRWw4c25pM3JiMVdaZEdLWjMzZyt6eVdDM1c1bUhvU09vWUpsNWp1a3g0?= =?utf-8?B?UHc2dkFxTjZMUlFOYnVDZUlqbit4ZTN0bi9DQy9EbDBZQXIvQjdqQXE4NEJ5?= =?utf-8?B?NzRhczdPeVdDSThTdHllUXJ0ZFFLeG9yOVZpRGtoaGdSTU9SYWRzalFaNWJ4?= =?utf-8?B?cVNpUWpkN2lTelhCS1Q4YVgyUDhGOC9HQnZIWEQ4K0VWZ2dvazduaE90Y0xt?= =?utf-8?B?RU1rdmFEdVdaZ3Rjb0hlc1VianFRRlBJajhoL25tQ3duRXNOSkRueUw2OXht?= =?utf-8?B?eEMzV1ZvRWZrNklLRzFncUo2OTExSDBZelJ1bFdxczdwTWY0Ui9zRnR3MDFI?= =?utf-8?B?UThqUThXelNGeUhYRXdKTVgySjFDTWpleFhBR1BIUTEwcmNvKzFzK0ErcnMz?= =?utf-8?B?MVBuOFVUTFFiSDh2MTRnMDJVMUUvMFNDYXFncTM3U3cxQ3hpeUd3SmVRdUk5?= =?utf-8?B?U0s4YTQ5RFZaVnZWMjNjdkhpVFQ2Z2NqN0k3RWdtY3JWZ3dRYjZwMGVWSStX?= =?utf-8?B?aGFpQytNZEN6S3h4dzVRZXF4NXhxcU50VUZWRzJjeFhXMVlOWURiWTFaUkxo?= =?utf-8?B?M0VyZEhYUlNONGdmSVl2aWZWckdTQWRBRklDZCtkZzYwbTNXWFRRT052VWJ6?= =?utf-8?B?aU5HNmw3ZFM5d015UDFrZWNoaXNuSWlMYTJlTUcyQVZkc3dXcmJCYWExczRa?= =?utf-8?B?OEVyMzJMUW1veHVXRVVVc3dyUzZNRGRCNGpUWTNrOHArTzcvRUNlUEVBbVds?= =?utf-8?B?UVB3VTU2aWRzUGpmTWI4c0MyRUVNeHNnVENoQUg1bXo0U3RUSTVIeFFjT0FQ?= =?utf-8?B?dGtvU2JrakQxT1FML2ZTVU9VaWtHc2txMm1pejdHNWJDYXRhWWttZndLQi9x?= =?utf-8?B?RUErT3diKzliZ3YrTFpHMnBadzZsdVdTeHNNOHptSGFkWGppakl0WlFpcWhV?= =?utf-8?B?TzZ6dUw1d3ViT1NNTzlIWWhRTnlIelZzWUpSdllyTnU5d0NEeU8yR2lOS1BG?= =?utf-8?B?RHNxeTJPUFFkc3lTdFpJVmRpOVY2cW43Zk5DeVYvU01sbUk4bFcyRmJTVmhO?= =?utf-8?B?ZThEMHN1VDhHSXlLTGVBL2JLSXNMV0FxdjRHYXlHemErRDhueENiTmJpaEpB?= =?utf-8?B?UXdBM3VqY0p6dytNc1dLQUN6SDVhYk54ZjQyOC9rV1MrSFFsWDNkY1poVmd1?= =?utf-8?B?RjlqcVc0dDV6MGtUYjNvRW5OQ2ZkMmJYKzBieHE5L3Zjc2hGZUl6R2VkZVpk?= =?utf-8?B?WENhV0Q2UGxaL202UkRZbUoycWp3V0p2d0VtNk43YmR1YlFjY2UwNVNyUkNL?= =?utf-8?B?ZEYzWHhKQ0FlQlVZL3N5eXdXWEJrWXJ1V291VDVxQURzR05DQUtZbjd2aFEy?= =?utf-8?B?Z0Y2Mkc2dVhTT1JkK2FqemgvVDkwVXU1dld6R21YQUVBYTRxU09ESzJmRWk0?= =?utf-8?B?bmQ4N3BQejlGY0gxUzM2QWdmQTBrU1RVcDNIYXFSa2JYbUh6UVR3Z1lacWJG?= =?utf-8?B?cU9WZ2J3YlkzemNaZXZmS0p3NzFZQmw0b3U0Um8wSkxsYitWaTZ3YnBpYmYv?= =?utf-8?B?MjY3bkRqRWhtZGMzR0V5WmtHMW8ySTBaM0RMeVpQVGJNNS9aYWZMTVdHTkg2?= =?utf-8?B?cVNLU2gxYzdkbWxUajZScVRWUUMvdXhQQUFmM3BoRGlKTnR4czVtT1NQb3VD?= =?utf-8?B?Qnp4S1NCTGNwTjV5b3RmcVByeGxoZXIrTkVwZCtId2I0aFpBS2JCSG5uWkJI?= =?utf-8?B?TlRuT0JrNXgyWWdBTVh4Z0Zhc3psV3Q2M2I4akRxVTVJM3E0cVB2TjNwT0VV?= =?utf-8?B?Q2E0TlA1bGNQNU9ES1E5QXRtbUEvVHBSRlZ5cXdKM0Y3eVlNM0RkeFo3VktR?= =?utf-8?B?K0oxWWZTZldGUFdETVEycVl2NHVONnh4dXFzRkVueTdkM3pWOWNlZFRveVNl?= =?utf-8?B?MFFVUS9WeTRYTUJKN3orS2tObXZjekticHVkV2UzZ1R5VGhSTWk1TStNb3Zi?= =?utf-8?B?SUo3dHJSVC9GT0tFTUFzS0dPWEQxZ1pINE1xTlJXSURrOGNJbWhhalc5TlRW?= =?utf-8?B?THZYSDZsM3Y4cy9KRFk0VFpNbzMrbk9OUStRRXptaWhMSlpacGJMZE14bjN4?= =?utf-8?Q?dZI0L+9gDtlfpzvgvEXxKw8=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?YTVudlVOSjNoL3pKK2xqSkh4V254WEowSmppM1loT3c1VnNJbHJPSzAwUTBU?= =?utf-8?B?eXlPdU9WMEJxTGNNN3VLOWMwN3YrWHZwZ1Zac2Y0VGpVZzJXUDBTbkJVWkE5?= =?utf-8?B?Qm5jTkRObEs0cTRpMjBSUFhrUVVtbXFUWkVWcHNDK1M5eVhPZk56WGxnWWJv?= =?utf-8?B?U3ArZlI5NFpMenpoeG1iZU44K3M0NVJJampybzhoUWRhUWVhdnBGQzNkZ09M?= =?utf-8?B?QVNuVWJhZWYrQnpVZ2RsSVMrMkNFQldkTU1LVEZrRE01VHJkZVVMclplcFZI?= =?utf-8?B?bEVSZlNjRHlnUVM5c2FLNlYxWWRpSU5XOHk4cmpENk9pVXZtb2twaFJ0UVg2?= =?utf-8?B?aDVNMXJoZUJoQmFWaDMvOEJaTEU4RGFSZ01oak1XOHl5T0NsMWRoUWpDSGFz?= =?utf-8?B?cWJjOThlZy8zV3QrdVZzTTB5SWtaandFR1Z4S1JJanh0L0pOOHpRVys2RGNJ?= =?utf-8?B?MndkbE5wZi9MSXp4blRqSWJRRHhKZUFHTG5nenVuSUJRanltWFNnOXRIS25p?= =?utf-8?B?bzJFSWI2S291Y3k3OUMwWGtDL05BQ2dUakluRHVhdEc0QVNDYVhkT3ZZUGJl?= =?utf-8?B?bDdRbFRJRldqUEJ5Y3laamMxOFh0b0hJcHZ5L3ZXdFZJelVTNzJ3cFpKelV3?= =?utf-8?B?bm5uZmorNmFTWHhid1RlZWRsU1FqcUF6OEJSLyt3RWJ2Vm5mYUNycVVVaGJG?= =?utf-8?B?RzNwQ0d1aGNBeGtLY3VyMTVWUy92Smp1Y3R3WERMRGVmY0tsbHRQNHpQNU15?= =?utf-8?B?eWJnY0pyYjJJcGkvdzE4dEJjOHpvZ3l1QlBTWUVTSnhGcVdIbXR2Z3FMSm01?= =?utf-8?B?NjBjaUw3L2xSbDFnSnJraFBoL2k5UkJ2NjAxajcwejV4Q2E1ZitNc3FQUHQ4?= =?utf-8?B?c2oxeWpBZ1RCc05IcWllakpmOEVOMTV2THU5MTZKN2dnNHlCUytZREZzVVU2?= =?utf-8?B?a3ZQdFB5dzZjZFVjcDFDN3BBSVhoZmtlQUdHME1BcGVmbDJhYkZiMkpLbW51?= =?utf-8?B?STlzdGZHVDErWC9TWjAvempObk9jWE56Ly9STHAvMTFDdyt2eVQ1VmM4SjVH?= =?utf-8?B?K2VXUnlXR0VCSXVNbFdBWHB0ZU5TdUMxSE1ERHgyWXBVQzFWQ1FPYkJXc21Q?= =?utf-8?B?Y2d2V0k2TjBlWm1taUZpaEY4MVBVeU0yQzRrdGowTDlGUXRZcVpja0Nsd3ZY?= =?utf-8?B?WmxSMHJEYUg1blFVeGtZTEhva0FubGxJVzN3ZGkxdnM4VTNGZ043TnBkUW5J?= =?utf-8?B?MUhBdGxqMDZXNmxUblo4aCt2eXJSOWhZVkllQTdrMHBsVmtpVVY5SCtsVVVD?= =?utf-8?B?UlhHT3FCdVRCUC9rWEgwZFRqTHM1UUJuYkJ0SnNOc2IvZkJxNXhINFpKTnhY?= =?utf-8?B?Z3ZJZUVucWlXWFBYank0ZTM1NTRSN1Z1dGlsOE5oRW1KQ2w2SjNjLzAvQTVG?= =?utf-8?B?bDkzTDlRSHMrM1ZDd202bzhKNzVMZnRFV0dCMDVneUN3NWQrcHZGUERWY0ts?= =?utf-8?B?WFF4SDJJTWszWUNtWnRZcTZKaHNFNCs4aE5JUHpSWXFVM3NuVUdWQU1VMU5O?= =?utf-8?B?MHFUNitjUFFLL3F0Zk8rT25LTTlvUElyWHZmNi8yMGF4a0VkRXBEMVNiOXYx?= =?utf-8?B?dHJGZDJmZ3hvMmRGcW9RK00rV1RwU1ZpZm5QL3dvSUxGb1dUclVweEJRaVlK?= =?utf-8?B?aFBrcGRWY2hXTDFLRjR3QWRuNG9lanZnTklGSk0wU2x5MHdReS81SzhidXAv?= =?utf-8?B?OExpK2diRUwrOGJtR3g4a1JiQUpkcXNIQ3lVeDdFM0JSMTRVRmZiN2NWdmpj?= =?utf-8?B?bm1XSS9UU3lIcDZtbGlVWThuTzA3cXhQdWdpRDZaa0szQnBzOFVxS1k4R3Uz?= =?utf-8?B?TjRQNFBtNG9oamorQzM5REJ3RVRvWTk0UTNoRExvSkk4SmV1bWhOcEFldnpF?= =?utf-8?B?bG5rR3NsbnA3elowaHRveTBHU0tTdWtPdjJNbU41d3dtZFcrMmFWdVI4OTJH?= =?utf-8?B?cndrcnd2dk9CMXVMVWhVTDVmMWFwSTVHMEQ5cUx0cEJTS2hFVEtBYXArV2Ri?= =?utf-8?B?bXJKaThnMllubVdnVmNkNjJsQ3lzRWxuNHlkaVg2Q2Jnd2hMU3FybjM0dHg0?= =?utf-8?B?UmIwK0lQb0t1NHd1eS9ZUEFLVENNK28zaUk2K1hsMy90bTBBNnJ6aXFlblE3?= =?utf-8?B?ZVRVSEk4ejgrbDg0ekFqckl6M1VDeUhrejRRT1RsN1pYaDhCc3BOYkV5Y2U1?= =?utf-8?B?aVprZjNoVHRrZXhmdHNyb2JLbVU0VmFzdWEzTEp0M2lyd0gwbkZiYVl5dkJo?= =?utf-8?Q?CXibh/waA0C2REUnyT?= 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: b390457d-b560-4ff6-ed69-08de5caac99a X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2026 07:16:12.9368 (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: siPtAZj7TJpaZvfxfMUggqMkTa5g8y1YVgISGRRiVAZDfv4LagDcOhcsOaC1DQzCr6eVZWra1s9X6coHW7d74w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6543 W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1 bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDIyLCAy MDI2IDU6NDMgUE0NCj4gVG86IHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZw0KPiBDYzog QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT47IFJvZ2VyIFBhdSBNb25u w6kNCj4gPHJvZ2VyLnBhdUBjaXRyaXguY29tPjsgUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0Bh bWQuY29tPg0KPiBTdWJqZWN0OiBbUEFUQ0ggMy81XSBjcHVmcmVxL2FtZC1jcHBjOiBtb3ZlIGRy aXZlciBkYXRhIGludG8gcG9saWN5DQo+DQo+IFNoYXJlIHNwYWNlIHdpdGggdGhlIEFDUEksIHBv d2Vybm93LCBhbmQgSFdQIGRyaXZlcnMsIGF2b2lkaW5nIGEgc2VwYXJhdGUNCj4gYWxsb2NhdGlv biBmb3IgZWFjaCBDUFUuDQo+DQo+IFRoaXMgdGhlbiBhbHNvIHJlZHVjZXMgdGhlIGNvbmNlcm4g b3ZlciBhbWRfY3BwY19jcHVmcmVxX2NwdV9pbml0KCkgYmVpbmcgY2FsbGVkDQo+IGZvciBhbGwg Q1BVcywgb3IgYSBDUFUgZ29pbmcgb2ZmbGluZSB0aGF0J3MgcmVjb3JkZWQgaW4gcG9saWN5LT5j cHUgKHdoaWNoIHdvdWxkDQo+IHJlc3VsdCBpbiBhY2Nlc3NlcyBvZiBwZXItQ1BVIGRhdGEgb2Yg b2ZmbGluZSBDUFVzKS4NCj4NCj4gU2lnbmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNo QHN1c2UuY29tPg0KDQpSZXZpZXdlZC1ieTogUGVubnkgWmhlbmcgPHBlbm55LnpoZW5nQGFtZC5j b20+DQoNCk1hbnkgdGhhbmtzLA0KUGVubnkgWmhlbmcNCg== From xen-devel-bounces@lists.xenproject.org Mon Jan 26 07:19:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 07:19:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213328.1523814 (Exim 4.92) (envelope-from ) id 1vkGsp-00066b-Eg; Mon, 26 Jan 2026 07:19:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213328.1523814; Mon, 26 Jan 2026 07: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 1vkGsp-00066U-Bk; Mon, 26 Jan 2026 07:19:35 +0000 Received: by outflank-mailman (input) for mailman id 1213328; Mon, 26 Jan 2026 07:19: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 1vkGsn-00066O-QX for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 07:19:33 +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 5b3f4d07-fa87-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 08:19:31 +0100 (CET) Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by DM4PR12MB6543.namprd12.prod.outlook.com (2603:10b6:8:8c::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Mon, 26 Jan 2026 07:19:27 +0000 Received: from DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::6d8e:2499:8a0a:7eb2]) by DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::6d8e:2499:8a0a:7eb2%2]) with mapi id 15.20.9542.010; Mon, 26 Jan 2026 07:19: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: 5b3f4d07-fa87-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SvqCUKbhrnIjAswc2vyX6pq8B5GpmPCd67RiiiDo0oPaXXHpDDKPjZCcp+b8+Gz8eCAjDJgTgAvSJZV/GrhO3LBOeyC/UtD8hbdlvxsbpUxc2l4Nq+FRVH5eUUhU+3gb7dAU3CYRCocrJs5jPfAKZAcS+M05GHzbfto0Xy803gnMRo+3jgggnV4LNV7q9yml8x5XmDQLLzzEJmnmRTx3PcUFb8aR6TcSwikhk8qklWA0f8J255MCTPbgh67r3js44RZhrZ82vnF8/FbG8xWc6y9m9TBfjDDrMNvg1gH+4kBiQcQnlGtyNkIRFT5fmn45Wj7hMwvITG+arIbPzLSBOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mX1DOoMa5nFnV7X4GDFJEoJk5FTI55hORRJzUCWfSn8=; b=W76TTfdqDortc1DYE6Btny1HdsarpW9Uu3FYADKVMP4E+NJHkYEdhg/cHb3x2PeJBPYJTvP5TTEKXm0aOFO3RHSVGdyfDIW4Vqeg+CSDqCOAeKkkdzNVBr/Io6blTgAeCPYjH1dsjnmYDjfYoXchMRnOx4szyETrqv4HObMZ9trPCVt0c2vStsrbJxhsncQ23fDqLcAvA4CmjrpG8EJF8xjTvghVnmKvgzlXD5od1fjIcNIEUk6Q8aBUgsgcvMKwnOxiwxA/q0HazxFsgvQOmHfasrYBNhHt69U3AW7qGsaaW+22oW7RVkJIOKav2xXEZaxYiAgcFAg1HGlBiUO7MA== 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=mX1DOoMa5nFnV7X4GDFJEoJk5FTI55hORRJzUCWfSn8=; b=A+R3pac8bR+r3Ib0aCnIQNQ6G4xG9Ji5alUIuOEmTULSr42VPLiMcra+0okH7GeiBJ19LDSgsinIG+AWxyCLWxvDjFriy9tfq1CKQ6uZsX7nh02kw2kwajlaZ4tExVWJloZoBoRXQqyR/EBEeLJLDuy4xNaKXqmic1SxojCDobQ= From: "Penny, Zheng" To: Jan Beulich , "xen-devel@lists.xenproject.org" CC: Andrew Cooper , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Subject: RE: [PATCH 4/5] cpufreq/amd-cppc: move epp_init into driver data Thread-Topic: [PATCH 4/5] cpufreq/amd-cppc: move epp_init into driver data Thread-Index: AQHci4OVpTuwrEnBuEWXPpEzWRHqS7VkEONA Date: Mon, 26 Jan 2026 07:19:26 +0000 Message-ID: References: <18639925-4e8f-4d58-a850-291d7ac0e6da@suse.com> In-Reply-To: <18639925-4e8f-4d58-a850-291d7ac0e6da@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=2026-01-26T07:19:18.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM4PR12MB8451:EE_|DM4PR12MB6543:EE_ x-ms-office365-filtering-correlation-id: 04693ec1-4065-4356-853a-08de5cab3d4b 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?Qmx3OGZkWW1Ea2I5WG4vNk1nclp3YnZhb3RkTTRTVjduUHVObW1ITWN1NSta?= =?utf-8?B?K0c4d2MzYzA3K0pUZ25VZXVWbUVDUlIwNTRzdlNHY3F0UGtmdVRmbGdIcXVP?= =?utf-8?B?VmVlbEJxS2pNbEM2eHhTdXZwcHU5M0poUmhveXYzNnBRdE5BdXdQRytwRVdQ?= =?utf-8?B?RG0yTmt2U0t4d3hobTdta3cxaEltK2pqOUExSC9wM0wxL2ltODVVeWxZQTNP?= =?utf-8?B?K01EVkdKWkpYdDVJNzNWdUtWc1FNTHQ1cE45WnlpQkcrVjhxUEErUndBMmoy?= =?utf-8?B?K0Z5RGFnOE1aTHRwQkhzcGs4Z1UxSzl5NXRMOFpyT3Jnd21qTmUxLzBkS3Rl?= =?utf-8?B?MG1VZzVobW91Wi9qTVdCOEdmeGZVKzZEMDFDMjJXYlArTGJwUWpCT2VaZWs5?= =?utf-8?B?c2kzbXNLRUJHWFhtUUxsTXZsWVZLNTU4T09GTUVpcUIya3NLa0dKNzNPN1Jx?= =?utf-8?B?Tkp5cHdTMzd4ekVXcDlTWXNvOGxEUHRRWHBaVkRYQzdMYVl4bEtvNGUra1JZ?= =?utf-8?B?TWxSaEhrOXY4MnRKVGdSdlMxUEExSXhGZEUyZjBaeU1hU21POFQ4ZlJHdVUw?= =?utf-8?B?OHU4VjVtekhSMjNsZG1ZUjhMYmFQWFg1M0gvVFRuUERRUElLcjg3R2VJZTZx?= =?utf-8?B?aEEwb05SVWpYM1RydFRCTWZvckNSck5lcXZHdW84c3RIWWdhQjJ3cVdjaDVq?= =?utf-8?B?aEFiYm82ZU5UQUNaZnhJVUR6dTltZHh3SiszaWwzWllCb2NoSjk0OFYwY2Y5?= =?utf-8?B?ZUQzcW5ybVVlaW42ZVQwS1YwdkJyMnl5QVJnY0dLZW1qT3Q4TVFYVUxlMDlw?= =?utf-8?B?dkVJeDUxQkVlVDh6V2Q2QVdtcjRXdXY4SnhLODJ5L1JXNng1MHAvMHdlelh5?= =?utf-8?B?Tk1Ia0ZrZXUraWdBRXlEMzM2YXBLejNtTmxYc24vazJra1FuaEsxdDRMODJY?= =?utf-8?B?dnVOZ1VKUllJdUdUWHZVSUs4bHJKQ0g1eXJuVkJubGtYYnNMcmx4YkFwUTNo?= =?utf-8?B?OEhia1lDSldFMGtnNGNQMzYrZzUwVDRveS82WXQ0Um1RaWh5SHpVanRRY3h2?= =?utf-8?B?SmJudU1EQWR5NTFzeEwvaDlqZ2RndVdiSUpIQmxUZGMrZkM0SnFSL2hjcGZW?= =?utf-8?B?TW5GWmZzdlpMS0RZRDJYRHltU0dWaWhkKzFUeWZ5SXRBWE4zWk1IWE1XM0wx?= =?utf-8?B?bEwxZk1rY1FsWVRxdWxmbDZrNWdLSkNLSk1lT1IvN2xDakYxV3lHcHFaTG0v?= =?utf-8?B?TS9YOTc0TzRwajdMTFBEQkswTWdJZ0gxU29mT1BhRUxRN0E0aE9VV1IreUtQ?= =?utf-8?B?S1pWM1pOYllncGZHYktKZkhqVGM1WjZIaHFGaGFvTXBvV05SQ2lXcXkwNUk5?= =?utf-8?B?bTNiV29zNDlRZTkxRzF0RmMvV2tHQjJVTFljQ2s2UEN0WlRTTmtxL0pGM2tZ?= =?utf-8?B?Nm0vL1NOaGdwK3FQNWNLVXZkKy9VWHh4K0hMT1JFbWR5dm5tNTBqN2NYbXNU?= =?utf-8?B?ZW1jR0ZRS1ltTXFUNFlTNzQxOWtkdENiUklnYjQ2cU1YdjJGbEJGeDBFVndM?= =?utf-8?B?Ym1sUFNqZFgwTVpONjM4dFE1T0RJN3l3NEhyTlF3TmcwWmdOak9uR2xOOEJa?= =?utf-8?B?TUhQcm5zSjM5U2poVVNQZGZ5QnB1NlFPY3RuZkN6b1FkdEFDbUw0d0xERnZK?= =?utf-8?B?YVVuZzZyUmQzSm83MHZJeDNZS2lQSzI4Vm0rU2ljb1cxMlBLQlR6emFBOTlT?= =?utf-8?B?ejh2OERMVTJ0dmRtZ2N0Yk12WENuNXcyeGtPL2JOWXdONkFTODRBK1BVYVAx?= =?utf-8?B?cmpxRUlsczhSSUIwSmRRTVdnMnRUZUpndFVscjRJcXFuNUQyQU5ocUFpQWtL?= =?utf-8?B?L1B1QTBsWklFQ1ZKT0k1QXhNNUhMRWdFS3YrYUZLNlhHRHZsUVVQbkZ1Sjlh?= =?utf-8?B?SzlpaXBOOWN5QjhMV09MRGJObTBBaDEvNWUzMWlOaGJYN3BXVWpRYlFtME1Q?= =?utf-8?B?MXB2dmwyYXJoaWtsV1RnOHBReE1YeUJtL3RsUXp4bVlqbVFiWWlyV2hrNlVG?= =?utf-8?B?WlIxOUsyYURDeVZWbDlhZEVNTktiMmRCYjRNZlE1N2JqaWVqa3JGTDhTdFpF?= =?utf-8?B?ZENIakc3Yi8wVmlybmlaL0FkelBUbjN5TVRoaWFBSUo1dTczVE9NaEp5bXF6?= =?utf-8?Q?KEzJc71/otf3oW3H5zvXBZ0=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?cmF1Um10VG85RDFoeWNsODI5ajhMaGwrZlc2aDFhRGJIRnd5U2RYR1Z5RFVB?= =?utf-8?B?cDY2K293VFduVzFBNkkrK09WZjFPRHkzc1YwM3dUYVMwaGViRVVhTS93b3Yy?= =?utf-8?B?OHgrQk0rYkZJY3hiODRlK0pQWGZXS3FDWi9SRVpib3Npdis4MlIxekhGUStu?= =?utf-8?B?bDAxY3JIb2ZESGgvU0liS04wck41aXhYYXg1ai9yZk1lN1dCVnhTbjBmRll5?= =?utf-8?B?dVJCdkh0UGVmUEJPOTh6Lyt1cnZKZFlHUVBneGdyN1dPU0JQZVRhWlArUHJD?= =?utf-8?B?UXRlRWN6aVpGTEx3TlYrcEg2TkhGSVR1SDZjcGpEYzd0Y2hlOGNQcWFvbm1a?= =?utf-8?B?VVJSSzE0QlVtbzVvNkE4emNGNG9WTUhxUW9USmpLaHk1SWVKbFNtczI1ZmtE?= =?utf-8?B?dFJYVjlzeWw1eDV0aS95d01hNk4yTy9JUFdZbXArUkV6QmhiWHZqNkVVV1Bn?= =?utf-8?B?Y0dHM0Y3MWJuNXMvUWlBS0RwaWpiWGk4bzgyWCtkaWRXOVN0dzdJMytqOFdi?= =?utf-8?B?ZklEOXJwbmdRUG9OWEV0ZjZXa3lPVEo0YkZiWFBtclNyYy9KU0xGaXplNnE5?= =?utf-8?B?VTg4ZDdaSXhpVUpRbHp0ZXIyU2dJZkVGM0RUQnBGdkpiVG9NWncwNXpxdnls?= =?utf-8?B?cVJYL01qbWUrMmYzMk03SS9oczlpUVlNd25IOTN0NXZFN2VhOXJRQ09pOTBG?= =?utf-8?B?UW4zQ2FuL2dNYUQyR1A4WDNHbE9GdUtoYlZvL3lLUmt5cW5tMmxVQzc1NEdQ?= =?utf-8?B?b1lrdVpKNzJ2cWdORkpCOXVSMEh1STRMUHRIWXJ2KzNjTk1MS281VE1kU0F2?= =?utf-8?B?VWVvQTByUzZSTi9JTmlDZVgrUjQzUmlvdk1rYjVyejB4SS9uU280c3l2OU1X?= =?utf-8?B?SXZQZnQ0a1V0RzZGMHpISTRyS1kxaW5PdjliUXB1aGQzOXBxMXdicHIvK0tS?= =?utf-8?B?cXdhVG9nWTg2TUd3WVNrSGFyUkNWWE9vRjNpaFlReVkvY3o1cFN3SGFSSG05?= =?utf-8?B?M2E4WUN5NjVpWFpYTWgzajBnWDVnTERLL1JDL3NKVkM3aTYvK3BMbWlKQXhy?= =?utf-8?B?VHlzMjAyU2Mvc2wxQUNIc281SlZoMHhtbkNaYS8wZUppTkxFMU94MFZGczE5?= =?utf-8?B?RlhNZ1FDekhBQ3gzYzM2TWRLRXVEM2d1K1hLd2FWOFltSzFqRTlzZVFvUHlW?= =?utf-8?B?SXIrQU9vbk5FZ09BNG1rZmVtc21Sbm9naHc2N1pERGRMNzYvRnJxbnI0YXhs?= =?utf-8?B?NEQ0M3l1RkkzcVY0VEN3ektRUGpvc0tjendFU2J4eVpQY2xHQWdrOTJCakJh?= =?utf-8?B?Z09WQVNmY09EaFpYWUtwK2FVb1V3dmdwa0F0Nzc2TGFabm43cUdKekNpTm93?= =?utf-8?B?SENLZ1c3UFNYN2dYWnFLODBWd2RhSmRLMlJySGcwZk5ITHZTM0Q5ZGdyMFo0?= =?utf-8?B?TjYrbWUxR01tZE5BZGg0QmYvYVZnUHc2WFBCRmg5OHZBMDZUTkh4aTN3Mldh?= =?utf-8?B?Rk94eVI4UUY1VkFmZ1AvbzhNaElkK3pici9QYmFXNy90VnV2VHpjR2hOUTU5?= =?utf-8?B?N1oyL1ZYUWllRGNkY1E4VnU1QUtGREhsbjZCeWRIY0VmMFo5ZVAwYkt2c1U1?= =?utf-8?B?QnpVRjVpclk3d0F1MXdIdjlWWkphQUdRaFlJTUNDMGxaUzVKd2RienBiOWFy?= =?utf-8?B?cWZRMHhTbUVSQ2Q1R2wxcWtiZ2VFVFdnMkh4QXJqZURRV2NCMXY1VmxPeHhH?= =?utf-8?B?bC9KdXA3UUwyYXJlNGdoUmdkbjAxZTV4YmpYMjVyVWc1cEZrVXNrOTJsOTJQ?= =?utf-8?B?SERsQTNVZG4rblpPeW0vTXZpakdGWWU4OEwvb1BBSFBNbXBndURGSlg1YjFT?= =?utf-8?B?ODNyUGlWY28ranlVY0VpMFpPQVR3YkxWMk0yTHdaSEpnenVpTmwwMGNFTTdN?= =?utf-8?B?TTZ4NXN3UEp0cXZVVzRwbW1FMnN6US9ucUplYU9PeWdqOFdOT0pDNlcwa2cw?= =?utf-8?B?SUVUNU82UnVJTHJHNVJvcVpNajVtU2E5cU5wNUx0dFF5TC9YN3lXNGJXTlJk?= =?utf-8?B?RWR6QzdnSERhdWVEbTBwWTFGekQ4VStIZFZUVVFERk16a2EwUmpEZGd1RDNs?= =?utf-8?B?Vlo0WDJmNnc5MVBZSHBDeGxQMGNveUEwNzNoWjZzQWdGT0k1dk5sL3ZoSlBm?= =?utf-8?B?QkpSNzFvVlJCV0t2b3NTUWlnODVjVHl1V1E4eDhKcWkxR25jc2JhWWFEUmRz?= =?utf-8?B?allBL2V2ZW1IVUozYWRqTjdkQ3QyQnoxd2theGQwMW5Nb1hMb3JHRFBscGlV?= =?utf-8?Q?QdtgdbBvBTLNtmK0rM?= 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: 04693ec1-4065-4356-853a-08de5cab3d4b X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2026 07:19:27.0303 (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: tCXZ4rHBVBKo591+mccqUWD5BPyhOvhxvbsJTzG9ysSRVCsX65tO2IhJk9Hn/VJzNWVIdaFtgFogLyYZEI+YHA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6543 W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1 bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDIyLCAy MDI2IDU6NDMgUE0NCj4gVG86IHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZw0KPiBDYzog QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT47IFJvZ2VyIFBhdSBNb25u w6kNCj4gPHJvZ2VyLnBhdUBjaXRyaXguY29tPjsgUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0Bh bWQuY29tPg0KPiBTdWJqZWN0OiBbUEFUQ0ggNC81XSBjcHVmcmVxL2FtZC1jcHBjOiBtb3ZlIGVw cF9pbml0IGludG8gZHJpdmVyIGRhdGENCj4NCj4gTm8gcmVhc29uIGZvciBpdCB0byBiZSBhIHNl cGFyYXRlIHBlci1DUFUgaXRlbTsgaXQncyBjb25uZWN0ZWQgdG8gYSBzdHJ1Y3QNCj4gY3B1ZnJl cV9wb2xpY3kgaW5zdGFuY2UganVzdCBsaWtlIG90aGVyIGRyaXZlciBkYXRhLg0KPg0KPiBUaGlz IGZ1cnRoZXIgcmVkdWNlcyB0aGUgY29uY2VybiBvdmVyIGFtZF9jcHBjX2NwdWZyZXFfY3B1X2lu aXQoKSBiZWluZyBjYWxsZWQgZm9yDQo+IGFsbCBDUFVzLCBvciBhIENQVSBnb2luZyBvZmZsaW5l IHRoYXQncyByZWNvcmRlZCBpbiBwb2xpY3ktPmNwdSAod2hpY2ggd291bGQgcmVzdWx0DQo+IGlu IGFjY2Vzc2VzIG9mIHBlci1DUFUgZGF0YSBvZiBvZmZsaW5lIENQVXMpLg0KPg0KPiBTaWduZWQt b2ZmLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+DQoNClJldmlld2VkLWJ5 OiBQZW5ueSBaaGVuZyA8cGVubnkuemhlbmdAYW1kLmNvbT4NCg0KTWFueSB0aGFua3MsDQpQZW5u eSBaaGVuZw0K From xen-devel-bounces@lists.xenproject.org Mon Jan 26 07:24:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 07:24:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213337.1523824 (Exim 4.92) (envelope-from ) id 1vkGxI-0007cB-Uq; Mon, 26 Jan 2026 07:24:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213337.1523824; Mon, 26 Jan 2026 07:24:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkGxI-0007c4-RU; Mon, 26 Jan 2026 07:24:12 +0000 Received: by outflank-mailman (input) for mailman id 1213337; Mon, 26 Jan 2026 07: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 1vkGxI-0007by-FJ for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 07:24:12 +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 005e274b-fa88-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 08:24:09 +0100 (CET) Received: from DM4PR12MB8451.namprd12.prod.outlook.com (2603:10b6:8:182::7) by PH7PR12MB7257.namprd12.prod.outlook.com (2603:10b6:510:205::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Mon, 26 Jan 2026 07:24:03 +0000 Received: from DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::6d8e:2499:8a0a:7eb2]) by DM4PR12MB8451.namprd12.prod.outlook.com ([fe80::6d8e:2499:8a0a:7eb2%2]) with mapi id 15.20.9542.010; Mon, 26 Jan 2026 07:24: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: 005e274b-fa88-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=D8FTgbiCsQ/ySrqUyMbzkN3ujd/klgx4lZbZycLBSvSLmK1GnrzsvJ87KXB0aqhVQgF1/aPvfmZrRernYbW6m6fq07nT8IAmoG8kkxVALsVphjeAqpTQdue3I4d/wM25/6XUAc8mdO3sLRoamUvXB3SEbQGXi4lqniQvKmEj4WgZLXJAXPiYgPm8/vj2oEMIHnkuraPg+QCgtlN1taH/SUWyQ1T0hzWVbZ2jwcEEnM1P3RokTGqvdoJRO8AcAX/Uo1lWvjELWwD+69gNMKy9p+G25h8I7QKtUsot1Y7gkYvvHRaEHBc9OgvssfmUudwn/G2uQY8/n0Pz/UVi6o0hMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=M864oLTCS+GwUIlCTlKALeCfrneBHjM+6rKe1v7Z7O4=; b=gpBJF7w0N0FNvXGR/S8X8efGPvfTGXXPjSiKntxImDqA37uJIG0cn4g7iSSw+cPU4r35iOo+v4e6keHlz+woPNOnQwuV8rsrSGhIUPABZQ5g6MaDTKOgauejUC+pOHuDw1J0ROIPQ9CnccidjktCMRqkoeB8qGM5CZDhPW3LQ7IRS7gyu8R1DcBZ2pOpXO1SgYDXr/qJvrd+SYtsup5u16FDVjmy+mcHoc5hPQ1DagG34XWK6GVHF8puK/sn/hjjIz+R7Tnw+Fq+ZrbDGFB+Nnd42LXxVDwirzL745D1lY4v+qVVgM4yRn4JPQUgNeCkJpcqh2+SsCDEzDlhFTcQOQ== 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=M864oLTCS+GwUIlCTlKALeCfrneBHjM+6rKe1v7Z7O4=; b=oVe6Y+/tgmBuJ/Qb7xqaxOJHjorLyzDQmTHH+Cv2kAqKVIHtJdEEbAns2qQI2Fhyf5xpEyoKZgDwHdEnP+RpeKvkNjt0ahX3tA1Kd+w9LJ09YFxDFvMkI+vYcOZc+UTHZEMyJWaXgGLMpZFrmO09Ax0y6HKmE0RDTCX2iOUetsk= From: "Penny, Zheng" To: Jan Beulich , "xen-devel@lists.xenproject.org" CC: Andrew Cooper , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Subject: RE: [PATCH 5/5] cpufreq/amd-cppc: move pxfreq_mhz into driver data Thread-Topic: [PATCH 5/5] cpufreq/amd-cppc: move pxfreq_mhz into driver data Thread-Index: AQHci4Oip3RJ/Oi400aA3juf0wC21rVkEXpA Date: Mon, 26 Jan 2026 07:24:03 +0000 Message-ID: References: <715604a8-265b-4832-8001-1a2dbdc870bb@suse.com> In-Reply-To: <715604a8-265b-4832-8001-1a2dbdc870bb@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=2026-01-26T07:21: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_|PH7PR12MB7257:EE_ x-ms-office365-filtering-correlation-id: 3228fb88-6c2b-48dc-58bd-08de5cabe1ed 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?NlE3NDE0WnUvSTJoZ0ZjVEhTbEs5TEFkNFQ1RUYzcHBSRTBYNU9JaGs4K3Iy?= =?utf-8?B?bTN1QW4zbDFFdXJNaE0zdGZNVWNwTzdOL0JEanBqcmxPSWNCakd0Q0NDZ2pL?= =?utf-8?B?VWRnNEFyWlZlMURPSVV6ampqT2ZueTVwNGdjRjVnWWhNYWp5S2hRZU1YMnJZ?= =?utf-8?B?dS9xdUdZalkyQUVpa2Voa3g1eENqWWt5Z0ZXTWJpVHJiTFlhTit1K0M4S3ow?= =?utf-8?B?MnAzRTMzWWV2dm0vTW9ZQkRZcnc0dURuWTMyeUZkN1ppQ2tiQi9MSVJUeHVD?= =?utf-8?B?N1hSOU5tWkhMZi96ZHNKNWovQy82VWtuNFp5SDRna0w3VEozVnA1STlKMEJ1?= =?utf-8?B?VmpPTTh6TmFEL1NHeFExZlUrdWpJaFhGMWpRdHo5M3BjdnYrWkYvTVkvZm1n?= =?utf-8?B?ZitsQldDb3VIb0pUWCtLMGM4VjdvdW9mMWRWblZoV2NKV0I4UjdNMjJzM2hY?= =?utf-8?B?c3VMUFVuak9LZmMvc1pGeFlnbXBVTWJ1bEVjRkQ1eDZjSFNZWTFINVZYaEUz?= =?utf-8?B?eDBlbnNEcGlKbm1QaTRkdGJadldrdENVVURYYzE2QW5LQm1iaC9LSjgyZzZq?= =?utf-8?B?cFVmaUlVTmJzcmJEQkhqRVZHNzA2TFJTdVJUb29RS0gxOUx3ZnZQaDJJaWgv?= =?utf-8?B?clBUWU5tcDJ0M095OVZGYmh6d3B1amhPUFNVeHJ4dzJRMEhRb1hwUHJzTXZn?= =?utf-8?B?dWh2bHdFNm9pTkc1RUJpTGRWbWJoeHRTWXRNMWRYdVpxKy9yYk9NRlFqcWVG?= =?utf-8?B?NXB6WWNaTXh6RmdmQ0oyTmprSkFTWlkwZzNXL2NDZUQzZUpaYlRmYTZ5Ky94?= =?utf-8?B?MGlyTFowWHFYR2tyVmZ6ak53Z3o0RXJvOEl1WXZsVWQ3cjd3d29DZ0U0azdo?= =?utf-8?B?aXZ0c1NFbWNERXU2UzBYSGd4Vzl0elNWVlB5WlBQY0g4OUE5R3Q1UXlmcEZK?= =?utf-8?B?OUwrTDJVNGZSUEQ0VmxNNUhCSkMvTGJ3SGd4WjQ3eW9QVjNaa1ZnbXhyN3Jh?= =?utf-8?B?VFdIYytTaktUZnFFUU94czZkY0dMNDlHSGNWQXlwUGIrMFpVWkY3QytZY1VN?= =?utf-8?B?OFZOdlFOZ1B6UVRWQjkrc0ZnR3cvSmFFMnVJWnVHOTVFbjAzS3BoRGNBQmpB?= =?utf-8?B?RnlGRm1KcFB1RjJsLzNZVzFtTWpka1owejlSNytDLzVka0dlMlRBazI5WTJX?= =?utf-8?B?cysrT0RmZ1JZN1ZzUUtCWXZPTHNMbmtMcFJZbzFVMENjVWxPSzdTWkluWWMy?= =?utf-8?B?NktUNFFtUlJCeUpPUURzRUJCTWpWOCt6VWVndFlQbGlBem5YMVF5enZQWHZI?= =?utf-8?B?UFl0S25BTzNpQUx3KzRJWWNGcnE1WXNlNUEvQnBwWUl3UXBtWUQ5VmtPcGNp?= =?utf-8?B?OGpIZS9mdkY3Q0JHSldlN040NDA1Nis1Y2ZoaFhtR1c1aUl3MTlIMzR6SWpX?= =?utf-8?B?U3p3cElvZndKQzZmWHhDZUZhQitHdURCV21pN2pwb2RlQ1BsYmZOcnNaQ1RP?= =?utf-8?B?V2hOdm1naG11SnJ1SGpRU3ZKb3B4d1l2TTh2NWNleUMrWjlYb0lXOENRQ2Iy?= =?utf-8?B?azhrYmFmMnc0TW5wOGFkS05vcHpheHFuZnRYQ045UWRFZmgzZEFyYkx1azlp?= =?utf-8?B?S0twV1IzMUJTYUNjZFlzaXFiaGFHU1VOOXlQYk40a1Q0eEsxUWdvNmU5Rmd2?= =?utf-8?B?ZG9RU0MzQ2ZvcTNjR3JONEs1QjJWSnZPTjhnT09tS1lsZFFtcVk1Y2wralZl?= =?utf-8?B?emE5clBxSjk5QWhacldSRHM2b3p1N2JjZ1pIdThPbHJ0MG1vVC9zaE1iTGxY?= =?utf-8?B?YVE0bEh2cHBIYXpnWkdqQkVKR2FEY25Oa3hqeC9vNGdtdUdIKyt2QXo5N0ht?= =?utf-8?B?dWxhNDY1SHAxeFM1dGx4Rm9qUEFlNzBacit6TlV5V29rVmw5T2ZJNHVKbUtz?= =?utf-8?B?d1NkWWIrR1p3eFBibXpkQVBZTWJudjBqaDhKZ0xqZjJ4aXl6eCtieHdsdnE3?= =?utf-8?B?cVFManFXUytoODBxek5vZnRYS0ljS2ZrMExTbE9WdXRCYTJlbnRzKzhMdTRr?= =?utf-8?B?eHdJVi9aVGV4VjRCTGdPWC9wSlpZWE1vQzJlUFJJUHM4NlIzMG1Jdm5qT2hC?= =?utf-8?B?RVVtVjJTdGFIK3JWZ1k3bjU1ZXZBaDVKVkt3R3RyQW53cVY4QXlHT2tYTDdV?= =?utf-8?Q?6fY7li5sxDOGbHjiUySIGr4=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?cFEwOEhTdm1GL1RXM0VRdjIrNlVTa2JDU0M5ZjNUVlBlVzVGbzhBdlBXaWNt?= =?utf-8?B?T3I4ejd1dVk3MVVCMTQ0Z2pzZzVHTWQvSHZkOTJ4U3ZpRVRsUloxTnl0NmlM?= =?utf-8?B?aHJucnlnYkRUdDJOY2dtak9nbE1FOFZhNnNTWFdTYmdJckJIM2RDUGJrVmRt?= =?utf-8?B?eXIydTFnYktOaVNiZ0MyZm84dnFlUmplaUxJajNkMERrTitpU0c0K3dmQlY1?= =?utf-8?B?enpEZkNSOXhra3IydVpVTHBVK2lUSURVRjBKdjZqeXNheEdtaTI4SkxsUkNk?= =?utf-8?B?S1M4ZXhCZThjMjhDM25xWU5FbXAydUwxL1N5SGRmUkE4QmEvZUVRMXVsYXNK?= =?utf-8?B?dytmWFZLREdjcUt4SkxCbFRJbkV3eGcya2FuelJhYzlSYVl2MzVVYy8wcm8v?= =?utf-8?B?d0pPOVROZnplZThYTTNhek15RUtlRUZDMTFmdlpUUWhnc0xaR0hUQUlmaGlW?= =?utf-8?B?Q1ZQVGFMVUZFMmNidTFyZDZ4R05GcGhCYTBQbW5xcFhBNG1XZHFzQUlYRThq?= =?utf-8?B?aWdOZ3ZYek5FOXI1c0Q3K21LRDlaZ2NLdzJVQ0RLZFpEUzkwZTY3UFVXRDhv?= =?utf-8?B?UlRjc0YyZXZnYlExY2xLalFFWXBEaTQ0eElJd1NFK3lXU3ZtdS9malFBT0dO?= =?utf-8?B?OWFaRksyR0NVYjFHaGVIMEVpWTliU0lFUEVEZWk1ZmpVUXlaY2xzdjdyRzV1?= =?utf-8?B?anFGSStmaUZxanBReXk2Vitsb2w0VEU3a2ZEYXNFZm1HcFp5bkhNamtnbEpC?= =?utf-8?B?QWpDcldGV29WNjRpa0ozRllaR3pYSXVYNy9UUHA0MjhzRTJHbjR2V2hta0RO?= =?utf-8?B?UUVOWERtK1Qxc3F5bm5MVFVMWEZldnp3VCtjc0lDTjl3VG93azVUS1luVDRC?= =?utf-8?B?MkZ3c1c4Uzdab0hHaEZvMGt0NmRZRlB0RnJDaDJ4cEF6TkNaY2NUdlFja2FE?= =?utf-8?B?U2tnTTR1Q0JES1g3UlFuVVExS1VsblQxQzJ4M0hUMnIwS2tBankyRE9UKzdO?= =?utf-8?B?VVVZQ2JHQTVqaXMxTXpOOGo2Y0RNbklFNmRwU3ZGdEMwTzE4STUvcnR1d2hZ?= =?utf-8?B?bXJZL0tsYmpuSzlWZHFaL29mUENIRVVuNmlWeVExWmZzek1qUExBcnJLZ2c4?= =?utf-8?B?K0dYUUU0OHBmd3k4QXdaNEtzRWxUTjhLazhTcHRLcXBkV3pIYjdaZ1ZYQ25Z?= =?utf-8?B?WklTa2ZOTGhKS05WWlgwL0JJTmREZDRoOVFjYUc0ZnJPMzZTVDZuYzlld1E3?= =?utf-8?B?TXNFQ3VMV0gxM0FzYmVLWmJFSXRzSEtyY0lVMTJzZUdjWWRXdDJLM1hUT2dj?= =?utf-8?B?K0RpN0ZPRkw5c01HTDNVYXUwNkFPZVNHa1AxejBwU3dBeHJTS0QrVVZxNlc1?= =?utf-8?B?OE5pK2pBUjhOUVBnY1lRZmFtT2Y3QmFwaGpLRXVZYThOZStKTlhmeEdwakRq?= =?utf-8?B?eXd3T29oY3JuTXRKTHFUbXVpOXdaeUtsRHRTaXU1ZGpvbTJEYVdRMG5NWW0r?= =?utf-8?B?N0dIQXlpNkU1QVpoR0dHajR6WlNOUGs0V3RMRFBMZUlKMUc0ZGdNeDVVOFhI?= =?utf-8?B?V2tMZ1hzdHlWWk9QNnBBOFdYVmJ6ZTVnRVE4clFMYzhtTFhlOU91N2RUT3Av?= =?utf-8?B?TWJOMEpLdTMySVRmM3h1SGEwOFhCcWNLaEd1NEYrWEptUmN5ditKejl5WEpq?= =?utf-8?B?RGZ3VDRtSjdER0xKSHB1K2pGd0NNaDR0bXU5R0tpeFZ5aTRmK1hSWnEyTkdi?= =?utf-8?B?QTNDWFhRQURkNUJLUmU3SENhMlBURDhjUmx4bjhVdHcvYXdOTFlDbTUrakEw?= =?utf-8?B?UDlrMVFwUjljdUtxWkxhZE5Hd3k3RFY5Q2xBUEp2N0xKR2dVdTkzTjJIb3d6?= =?utf-8?B?dmZGdDhqditCRmRMcGFjRUovb2N3cTdKYTQxRXJkR2VEcEcra2NsSjhheDdQ?= =?utf-8?B?TGlXS3lLMjUrM2FqdGthM1JucWVUWmhEQ3NJcW9SWkN3cUNHcmNjQ21nblJB?= =?utf-8?B?Q1Q1bzBHVWVnT3lxTldCV2thTjlZZlZuU0NXdXhzUHBLcklkSHVzRmdudGNC?= =?utf-8?B?SURmeWt6ZHRzV1NDbEdFWjArWVhvdTN4dTB2TDNPU09manBidlMxU0U3WWwv?= =?utf-8?B?djlQMXNCQ0ZPZnpZZ0ExbzEvSTh4VVVCdm5iYkx1SERsMHN0dkhLUXRsbTBs?= =?utf-8?B?dUhzZ2VxKzJsbG1xZ3lMaUlJNURkQTFxVWg5YUl3S1htanpGUE1TeEFwVEll?= =?utf-8?B?N294REt0T1Y4OHFPSVlvZ2dIZWoxY3VUbW0yZ0dhWUwxeTYyeXFVcy8rY2pU?= =?utf-8?Q?9Ji5/mWaaej2BJxkXr?= 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: 3228fb88-6c2b-48dc-58bd-08de5cabe1ed X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2026 07:24:03.2147 (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: /0umq4MJ9ZEouN7TVjUc/KPCsUG6ERxDwSh+ZYMJrY1CH3ta0EBCFNIIIwfA8P3QQVhf9p+O5gKHVOauROXglw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7257 W1B1YmxpY10NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW4gQmV1 bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDIyLCAy MDI2IDU6NDQgUE0NCj4gVG86IHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZw0KPiBDYzog QW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT47IFJvZ2VyIFBhdSBNb25u w6kNCj4gPHJvZ2VyLnBhdUBjaXRyaXguY29tPjsgUGVubnksIFpoZW5nIDxwZW5ueS56aGVuZ0Bh bWQuY29tPg0KPiBTdWJqZWN0OiBbUEFUQ0ggNS81XSBjcHVmcmVxL2FtZC1jcHBjOiBtb3ZlIHB4 ZnJlcV9taHogaW50byBkcml2ZXIgZGF0YQ0KPg0KPiBObyByZWFzb24gZm9yIGl0IHRvIGJlIGEg c2VwYXJhdGUgcGVyLUNQVSBpdGVtOyBpdCdzIGNvbm5lY3RlZCB0byBhIHN0cnVjdA0KPiBjcHVm cmVxX3BvbGljeSBpbnN0YW5jZSBqdXN0IGxpa2Ugb3RoZXIgZHJpdmVyIGRhdGEuDQo+DQo+IFRo aXMgYWxzbyBlbGltaW5hdGVzIHRoZSBjb25jZXJuIG92ZXIgYW1kX2NwcGNfY3B1ZnJlcV9jcHVf aW5pdCgpIGJlaW5nIGNhbGxlZCBmb3INCj4gYWxsIENQVXMsIG9yIGEgQ1BVIGdvaW5nIG9mZmxp bmUgdGhhdCdzIHJlY29yZGVkIGluIHBvbGljeS0+Y3B1ICh3aGljaCB3b3VsZCByZXN1bHQNCj4g aW4gYWNjZXNzZXMgb2YgcGVyLUNQVSBkYXRhIG9mIG9mZmxpbmUgQ1BVcykuDQo+DQo+IFNpZ25l ZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4NCj4NCg0KUmV2aWV3ZWQt Ynk6IFBlbm55IFpoZW5nIDxwZW5ueS56aGVuZ0BhbWQuY29tPg0KDQpMYXRlciwgSSdsbCByZWJh c2UgeW91ciBjb21taXRzIGFuZCB0ZXN0IHRoZW0gYWxsIG9uIG15IGJvYXJkIGxvY2FsbHksIGFu ZCBjb21wbGVtZW50IHRoZSBUZXN0ZWQtYnk6LiBTaW5jZSBJIGd1ZXN0IHVwc3RyZWFtIGRvZXNu J3QgaGF2ZSBib2FyZHMgd2l0aCBhbWQtY3BwYyBlbmFibGVkIGluIEJJT1MNCg0KTWFueSB0aGFu a3MsDQpQZW5ueSBaaGVuZw0K From xen-devel-bounces@lists.xenproject.org Mon Jan 26 08:28:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 08:28:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213358.1523833 (Exim 4.92) (envelope-from ) id 1vkHxf-0007IH-RB; Mon, 26 Jan 2026 08:28:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213358.1523833; Mon, 26 Jan 2026 08:28:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkHxf-0007IA-Oc; Mon, 26 Jan 2026 08:28:39 +0000 Received: by outflank-mailman (input) for mailman id 1213358; Mon, 26 Jan 2026 08:28: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 1vkHxe-0007I2-K8 for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 08:28:38 +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 fe9e0721-fa90-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 09:28:30 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-47edd9024b1so34112925e9.3 for ; Mon, 26 Jan 2026 00:28:30 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804d627871sm97298755e9.6.2026.01.26.00.28.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 00:28:29 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fe9e0721-fa90-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769416110; x=1770020910; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=V15wYNdZD5B29GtwMU1U9MjH4gIvLmDGg6uEHIdYqRU=; b=Sf6k6kXhCOskssoR1yJEzWESi0273+mXfOSoVMFi99EWSxsinaSo398DRcf4F4ruvL XLaduhsbWJLQovWuxTv8F1N+ZL1JMXqlLukGyNJrAn1VVrCIH3H05qzQcU8oBcFuz982 Ua1dUtE1a5xLP42jvqJeMWAd31RqjBw1Pdja8ePehtwKoy5G5kNATLaHNp38jetA8Hw1 75c/NO9kA1/IWCnm5kTtJJBNIXj6aSAC9vduPQJMVT/xO+WnCx1kXYZbZha0cJBcCxu+ 3UvlWw+YbA896Pst7QbTNcMyl6M3R3nf3n9ykITlEOYNnSnMnvvvIhjL0BclEdllJ66/ aAPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769416110; x=1770020910; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=V15wYNdZD5B29GtwMU1U9MjH4gIvLmDGg6uEHIdYqRU=; b=ga8XepU9k6YA25xU9Qz2fMua2ru0wFt2U7PIUbVBXFfx1jw1npmSunmrN1mxOMJvpS wByqE9ww5H00zHf27uHczw2V83G0EcYSw6Xy0jRgz1nUXeWcr79yBfJo90GKXGRbDS9P Qi5paEBGMMBu41M1CgpVfItVTsqEgmhnSG+g7vnaLoWd4uabNmYA+EmFYg2iVliYGd0u 1KUku8CA14UzoYRw4+QxV2CGprpglCcNcqDJpOwwW9kY0oraZAS3WYVKHi3W/9YziH5L eML8UFRChryM4zJcE0br8PZ1c1D1aaE6Ibf8YzW/E7PZR3roo7fqgCmpUs1NLQJ6FCLj eUZw== X-Forwarded-Encrypted: i=1; AJvYcCX9gE8CynKBmjeHNXyjAdFI6pDPSDI52me1zaPGbcdGRiRrMG3AXH75zH+1OCA5NMhGyLUZNSK8Uu4=@lists.xenproject.org X-Gm-Message-State: AOJu0YyAeneby21Dhs9xshQZE5PYCNWgiTz9uV4t0D8kz5iYbGYrjKkq xWTbF9AqUaiw5dlXG19icY3NyiyoEyOYsO0b2siQHAYD+UXIPWmejkdMmb4APnB9WQ== X-Gm-Gg: AZuq6aIxJQ/6o5x7LS6ILphNACo2k20knPQWUPGhCJn7dwNXk4LmmZyOuV/VahWtaSf 2xq5rop0NBO8bznIAGEIk6jMKswCtcGQ3LeRGNHtlxgRVcUKrt/oIEpsJjQ8z0JJ2XJulPXwkrc ImMUXN2EBk6cBWg3KHeK14fumUntx9A+Ef/tVSY6N54ioBjptw0aPRr/usdfGV7WDvyeSm86aNp fWEXXlpE6y2WmTnxTmWpDydolAMbVOcwOuzk4inUScdCrh1yb/oJ/oEsBWsFDyP1mvpDXW/o2di uS/WcDrzp40CUEfK62FBjF3j+bIA4hfDBcynaHmmYXCZShqJ3KnQD1QaoJgtjrqsDCK/ns7ECKl L/V64//oqwCS7ByRc+VDW52Pye55nGJa+gn/HaiAWXq87PoIEVauAWmdTCxzTx1KOIrtsm8nlr5 auyrm8pL+ql+AZ2o0SCyGYGECw3fc8WeFycCpeHntEG9VmGu52JPVsmbnZHcbTzzBAGiizj0btV Sg= X-Received: by 2002:a05:600c:6291:b0:46e:37a7:48d1 with SMTP id 5b1f17b1804b1-48060a1398cmr29229695e9.34.1769416109764; Mon, 26 Jan 2026 00:28:29 -0800 (PST) Message-ID: Date: Mon, 26 Jan 2026 09:28:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 3/4] scripts/config: add -y|-n flags 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: <20260116043458.730728-1-dmukhin@ford.com> <20260116043458.730728-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: <20260116043458.730728-4-dmukhin@ford.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 16.01.2026 05:34, dmukhin@xen.org wrote: > From: Denis Mukhin > > Add alias -y ("yes") to --enable and -n ("no") to --disable a Kconfig > option for better scripting experience. > > Signed-off-by: Denis Mukhin Seeing this has been ack-ed as-is, I'd like to put on record that I don't think we should be adding extensions like this. If such is wanted and deemed generally useful, it can surely go to the Linux original first. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 26 08:36:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 08:36:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213367.1523843 (Exim 4.92) (envelope-from ) id 1vkI55-0000Qr-G6; Mon, 26 Jan 2026 08:36:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213367.1523843; Mon, 26 Jan 2026 08: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 1vkI55-0000Qk-Dd; Mon, 26 Jan 2026 08:36:19 +0000 Received: by outflank-mailman (input) for mailman id 1213367; Mon, 26 Jan 2026 08:36: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 1vkI53-0000Qe-Kd for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 08:36:17 +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 13b8b789-fa92-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 09:36:15 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-47ee301a06aso48649015e9.0 for ; Mon, 26 Jan 2026 00:36:15 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1e7156dsm29163703f8f.20.2026.01.26.00.36.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 00:36:14 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 13b8b789-fa92-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769416575; x=1770021375; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=ihiBLSLqAknhmu2ulqYkz+lh8oJuDITWiAx4INnpdlc=; b=eglHDApxGdp6dqdXVHPPDNz9L4XLW8LgRRYC5P8XcT+e9gfITrbE6PRtxl+at0I5Rj FJdfyi1LI+37mOjKreWwd6wKzcG6jTvrRtDx9O30XoqV4k/VoYAZVTuhuMWc7ezhjfd6 AiHc1xuMnwbFBQJ2fW/oIAELEloSoBqvom3k4uiVCqe6QkZLwkMNrBgD2edJPMkZMa+e rSkivUnsDeXaHicfAa0aa+t44B/34qG8K+/m9CUGujW2/1JFmyCe88vpc9fwL2NAfc0X uCmmTGAyWEuBgxnTsoWS4pCrseTn528x/jSnWngTYOar6qWBGtHq4/8BXn1vWxCROqhn OR9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769416575; x=1770021375; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ihiBLSLqAknhmu2ulqYkz+lh8oJuDITWiAx4INnpdlc=; b=UlMATTrGNgAwGyhimKFE83fmEdAVxm+0N0HHWwvKNTxYwbvGm0FTOKreEEF756yMgi GSS3mg7+6wRiIbOet2HaM/9pECbVdjd4NNl4XjRnGK9xsi+xW5GsSPgm3JACR7o9Ey+C 70vgv2wbgFWFFpfgyNHberj+pFEVDLFylEMKvtxuK3O0eEXsO8EIOScry3owTwqj+7Z/ k2/lKvMlqyhVOj/VNhJ9AQ6/EzEtHT1hGXKxLrzS/NClizzq7SLEDCJ6hyUFYnhDB6lu VY1lJ5a7/Ij3J558hNFtpZgeKyLU6E38sJ6OPakO8T/xOMBc2JDeBELxbaOheNMsiEvB 4RSA== X-Forwarded-Encrypted: i=1; AJvYcCWTf679/RG8CymJXusdxZ4qLnM4dLBnMpnY32hg4RjoGSx7pq19sOrzHdZzgNB2+nYB9xTxw0/6z6I=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz+5gC1nb5GsBLA4M4p9G21qHBgB+q8u2EzOuIV5JBBsFLdx3hZ eQ4pZvP+0ywcxzQ9SMeAQDMEw3g/Ky3GKO/v+GlW4Zdr6ZiN7gtR6Om3yn0ACNOOeQ== X-Gm-Gg: AZuq6aK4j60lK73YygH7y0iI2vEBrJSsoT6bTU7VohEAaQgJ7RTR9bPeW/0ul4z2st6 2OGBbPHei+pdWjvC48P2GNdbh5Xlx1cLSdakdKgBZyI0zG7UofdrOLkok+/ivblmsbY9pzLtq0n rpqC/r+NQCS+wO/tEvHdpg3JLPaNOdLRghxp9+oA1ZpBkWawgDUWOaGQOBh1Jc2xpOUuT6yRnY7 7HpfL2cyoE4s1OwFuVTGeuvSAW877jt0N1zWCRS0r6ot5IsaMEd7B2oq/egPB1HEicxNHOqiE48 TQppWIAY7fqRoW2o+6v93edtM+jUh/sjIyw0DUfgww91mQaWJcsBIi1O11OJ0aoXffgpuY81IKX eN6AjoLGaHA6LaaNiSaiCFArtB1nXRhPbaUMJw+ZIZ2v5nFix0l4ABBioa6GbFXusMjMxBx5CyE 6WopHisG4e0ZoykZuZCFkHCr0uISepCAMezbeNjbiQAXOQcKQLOjbw1VAaqkMNTjMl7G1rE9bm1 bo= X-Received: by 2002:a05:600c:64c4:b0:480:1e9e:f9d with SMTP id 5b1f17b1804b1-4805ce40062mr58383325e9.8.1769416574659; Mon, 26 Jan 2026 00:36:14 -0800 (PST) Message-ID: Date: Mon, 26 Jan 2026 09:36:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/16] xen/riscv: implement vcpu_csr_init() To: Teddy Astie , Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <57ef3bcff854d4b50641641d300b3e8aa715c3c3.1769099885.git.oleksii.kurochko@gmail.com> <99289a63-b4be-42f8-974b-7445a6a479dc@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: <99289a63-b4be-42f8-974b-7445a6a479dc@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 24.01.2026 23:44, Teddy Astie wrote: > Le 22/01/2026 à 17:49, Oleksii Kurochko a écrit : >> +static void vcpu_csr_init(struct vcpu *v) >> +{ >> + register_t hstateen0; >> + >> + csr_write(CSR_HEDELEG, HEDELEG_DEFAULT); >> + v->arch.hedeleg = csr_read(CSR_HEDELEG); >> + >> + vcpu_guest_cpu_user_regs(v)->hstatus = HSTATUS_SPV | HSTATUS_SPVP; >> + >> + csr_write(CSR_HIDELEG, HIDELEG_DEFAULT); >> + v->arch.hideleg = csr_read(CSR_HIDELEG); >> + > > To me, that feels odd to set machine CSR here. Especially if (I guess) > that we would update them anyway during context switches. > > I think it would be better to have : > - vcpu_csr_init -> sets initial state CSR in vcpu structure, doesn't > touch machine CSR > - context switching logic -> loads vcpu-specific machine CSR from vcpu > structure > > We would have to make a context switch to enter the vcpu for the first > time; but that's to be expected. > > With my proposal, we would also want to move the vcpu_csr_init() > invocation to the place we initialize the vcpu_arch structure rather > than the first time we schedule inside that vcpu. Aiui the writes were put here to be able to cope with r/o-zero bits. Yet indeed it can't be cone like this. While it may work for domains created during boot, these CSRs would be changed under the feet of a running vCPU when done this way for domain creation later at runtime. Instead, as I think I had also suggested earlier on, the r/o-zero-ness of bits in particular CSRs wants determining once during boot, and then that mask wants using when setting up vCPU-s. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 26 08:38:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 08:38:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213374.1523853 (Exim 4.92) (envelope-from ) id 1vkI7T-00013O-TU; Mon, 26 Jan 2026 08:38:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213374.1523853; Mon, 26 Jan 2026 08:38: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 1vkI7T-00013H-Qa; Mon, 26 Jan 2026 08:38:47 +0000 Received: by outflank-mailman (input) for mailman id 1213374; Mon, 26 Jan 2026 08:38: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 1vkI7T-00012Q-Cx for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 08:38:47 +0000 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [2a00:1450:4864:20::329]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6d24754c-fa92-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 09:38:45 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-48039fdc8aeso21919495e9.3 for ; Mon, 26 Jan 2026 00:38:45 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-480470bfe42sm333913985e9.9.2026.01.26.00.38.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 00:38:43 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6d24754c-fa92-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769416724; x=1770021524; 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=I9xBeL9XzcEfuWQDF1E1d36YREQglperVrzzXOMFOJI=; b=OEYYmAI0voxIRcscyCEgtAWKkEmxxsg9NvUBGa9NUvS4Y0xE2cIElyy8xS3zbtwpeJ XypOdNhRqnH87TeEThnp42SNP8OnL7oVMQLWVF5xeJJIW4rCwqt0t/6A90J8tvjZXN83 WKV6oxO5iuALgcnbD7xN0cfUKDON1swAM/8pSWkPwMuB8OVjWqxA7w6BTsoQ9rVi4zY6 yrD70EPbLeMoHY9SjX4R8ZDC8rEyJhLsotEbRTwenWYTt5I4W5RjjgKB4p2bkxyFKtto iVAxesRAHz8k7PHjbCECbL/7CXro7ceNPN+8qqgNmTZdO+iPrzKuSllpHyuJ8X5NcmqI RQFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769416724; x=1770021524; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=I9xBeL9XzcEfuWQDF1E1d36YREQglperVrzzXOMFOJI=; b=JuETOVq5CY6wUE9l9d+RvbCv7LBeJ+Kdxl3IjSdcfH1Kgc6s24cVakemI/CAxHybff dqH+7sYCL1fuuXKKZZEDNjx2D65vZ+Gw2YTxGCh77jIG/hgrD+LROCu2Z3PHYDmJaSf/ Ic7t+uA9VgARqil8YSf4gNyFIkTppFXmjVacYRvIRS/5CrhpIIG8sdQRhVH0P7gbl+31 d+hpGmVTFafIxeUM83ER9QdlOuFLs+M5BslsGpM7tHqBc2WTJ0Xwg3pSCT94t8qLS+JP X4BtikBwSiY0xP6sTTZCBxkWyGI8t34Wb1x3cTlDRiOYOlYOC9YTKiDeGlASmSZNxy4P 0ImQ== X-Gm-Message-State: AOJu0YwE9to9WDy9obur07LWbrhviOlbbqaOXhbG4hbNXwlMeyzkI0jA lpfzgXtARKxdTZ3Hs+Cl2X1CxKqSj0cbN+drgiMu5Xx7zSqKnQmN/LgKDhGqoA== X-Gm-Gg: AZuq6aJBULO7keytTZwgkWkiiFmOeiSQFAwbK3eKR2/rq+jrFud8HR4VPeUstGcRr4S B1t5mAUHGWilddNQmWByaesWcLv/HyQmjECTrbJpoXbaCYddzTF4wCRq2OuL4KjK/lDbANInWDp ihVlvIqsY4YN+oszzliD8/4+zyJenNsnWoH06cF7Pa+gCo/hJ7/TxEWB5bVOvM8LivcMfMUXQNZ vQ0ntySEQrJeqlGQs3Tkwr9nHHTLOqivVWwNK9K6jI6vMPvTeVkGigG0CCEFV6KHZm/V2qtcqaH sRkolv1NLCR282rAbPrcgIAuSMM0pbRDnroTDKbzkC/LyESs8beObEQETvD7aBi66wCwh9dvOeE mLZxWw/Gxu2iss8OCzpm5kuGTp9z3nNwznycFlhkLgEY3uoKgwCMJmRaRtVKdN/6zCBu0vHIOWb zh18TbSs5ufnqoAfJnFE3iPvxWRN/ZwGm91Ct5sp1RRnZoWA404aEVkemu+Mg/wR1/ X-Received: by 2002:a05:600c:6285:b0:47d:8479:78d5 with SMTP id 5b1f17b1804b1-4805ce3fcbfmr64525175e9.7.1769416724216; Mon, 26 Jan 2026 00:38:44 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v3] xen/riscv: dump GPRs and CSRs on unexpected traps Date: Mon, 26 Jan 2026 09:38:36 +0100 Message-ID: <0b57db49d40b336429dd4fd63faf18f6bb17ac1a.1769179393.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Provide additional context when an unexpected exception occurs by dumping the relevant Supervisor, Virtual Supervisor (VS), and Hypervisor CSRs, along with the general-purpose registers associated with the trap. Dumping VS-mode CSRs in addition to host CSRs is beneficial when analysing VS-mode traps. VSCAUSE, VSEPC, VSTVAL, and related VS state are required to properly diagnose unexpected guest traps and potential hypervisor misconfiguration. For example, on an illegal-instruction exception the hardware may record the faulting instruction in VSTVAL. If VSTVAL is zero, VSEPC should always be inspected, and can be used together with objdump to identify the faulting instruction. Dumping VSCAUSE is also useful when the guest does not report it, or when the hypervisor redirects a trap to the guest using VSCAUSE, VSTATUS, and VSTVEC, allowing verification that a subsequent trap is not caused by incorrect VS state. Signed-off-by: Oleksii Kurochko --- Changes in v3: - Refactor the code dumping of CSRs and GPRs: - Introduce new macros - Re-group some registers when values are displayed. - Print all registers name in lower case. - Drop unnessary "Dumping CSRs", "Dumping GSRs" as it is clear based on names. - Update the commit message: add justification of dumping of some VS* registers. - Drop printing of VSSATP as I don't know usecase for now where it could be needed. --- Changes in v2: - Address coments about print_csr() macros and dump_csrs(). - Add dumping of GPRs pertaining to the trap. --- xen/arch/riscv/traps.c | 69 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c index e9c967786312..7b9bcb97035f 100644 --- a/xen/arch/riscv/traps.c +++ b/xen/arch/riscv/traps.c @@ -99,12 +99,81 @@ static const char *decode_cause(unsigned long cause) return decode_trap_cause(cause); } +static void dump_general_regs(const struct cpu_user_regs *regs) +{ +#define GPR_LIST \ + X(regs, ra, " ") X(regs, sp, "\n") \ + X(regs, gp, " ") X(regs, tp, "\n") \ + X(regs, t0, " ") X(regs, t1, "\n") \ + X(regs, t2, " ") X(regs, s0, "\n") \ + X(regs, s1, " ") X(regs, a0, "\n") \ + X(regs, a1, " ") X(regs, a2, "\n") \ + X(regs, a3, " ") X(regs, a4, "\n") \ + X(regs, a5, " ") X(regs, a6, "\n") \ + X(regs, a7, " ") X(regs, s2, "\n") \ + X(regs, s3, " ") X(regs, s4, "\n") \ + X(regs, s5, " ") X(regs, s6, "\n") \ + X(regs, s7, " ") X(regs, s8, "\n") \ + X(regs, s9, " ") X(regs, s10, "\n") \ + X(regs, s11, " ") X(regs, t3, "\n") \ + X(regs, t4, " ") X(regs, t4, "\n") + +#define X(regs, name, delim) \ + printk("\t %-4s: %016lx" delim, #name, (regs)->name); + + GPR_LIST + +#undef X +#undef GPR_LIST +} + +static void dump_csrs(unsigned long cause) +{ +#define CSR_LIST \ + X(stvec, CSR_STVEC, " ") X(vstvec, CSR_VSTVEC, "\n") \ + X(sepc, CSR_SEPC, " ") X(vsepc, CSR_VSEPC, "\n") \ + X(stval, CSR_STVAL, " ") X(vstval, CSR_VSTVAL, "\n") \ + X(status, CSR_SSTATUS, " ") X(vsstatus, CSR_VSSTATUS, "\n") \ + X(satp, CSR_SATP, "\n") \ + X(scause, CSR_SCAUSE, " [%s]\n", \ + decode_cause(v)) \ + X(vscause, CSR_VSCAUSE, " [%s]\n\n", \ + decode_cause(v)) \ + X(hstatus, CSR_HSTATUS, " [%s%s%s%s%s%s ]\n", \ + (v & HSTATUS_VTSR) ? " VTSR" : "", \ + (v & HSTATUS_VTVM) ? " VTVM" : "", \ + (v & HSTATUS_HU) ? " HU" : "", \ + (v & HSTATUS_SPVP) ? " SPVP" : "", \ + (v & HSTATUS_SPV) ? " SPV" : "", \ + (v & HSTATUS_GVA) ? " GVA" : "") \ + X(hgatp, CSR_HGATP, "\n") \ + X(htval, CSR_HTVAL, "\n") \ + X(htinst, CSR_HTINST, "\n") \ + X(hedeleg, CSR_HEDELEG, "\n") \ + X(hideleg, CSR_HIDELEG, "\n") \ + X(hstateen0, CSR_HSTATEEN0, "\n\n") + +#define X(name, csr, fmt, ...) \ +do { \ + unsigned long v = csr_read(csr); \ + printk("\t %-10s: %016lx" fmt, #name, v, ##__VA_ARGS__); \ +} while (0); + + CSR_LIST + +#undef X +#undef CSR_LIST +} + static void do_unexpected_trap(const struct cpu_user_regs *regs) { unsigned long cause = csr_read(CSR_SCAUSE); printk("Unhandled exception: %s\n", decode_cause(cause)); + dump_csrs(cause); + dump_general_regs(regs); + die(); } -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 08:40:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 08:40:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213384.1523864 (Exim 4.92) (envelope-from ) id 1vkI9J-0002Wr-8x; Mon, 26 Jan 2026 08:40:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213384.1523864; Mon, 26 Jan 2026 08:40:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkI9J-0002Wk-5X; Mon, 26 Jan 2026 08:40:41 +0000 Received: by outflank-mailman (input) for mailman id 1213384; Mon, 26 Jan 2026 08:40: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 1vkI9I-0002WZ-Lo for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 08:40:40 +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 b08dd50b-fa92-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 09:40:38 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-47edd6111b4so48709505e9.1 for ; Mon, 26 Jan 2026 00:40:38 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804dbd9436sm96712695e9.18.2026.01.26.00.40.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 00:40:37 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b08dd50b-fa92-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769416838; x=1770021638; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=NVDW0egVHX3ycdRz6KjAxDpgLlZpCPZ/MyY8UU0Qh28=; b=ZKe2k8Ir7HR+c3vETk/HAM51GDMc+p9plKLf7mG+w18fd5pEeNwTD4Y2969nZfhk23 +2YKkX3CdvzCnw3Ziifz4KgyJ3N11jXYfWYE/NlNgcba+lfJlBGm8ahMYQPSiDuc5tEl IBqM9XqRRAie6QqK7DGdbiW61OGumK3gTY/Lp86wAM2xsXJz5cSTbWwrKMPlZxxxedzB XzVY55ulZ2d4yyWhERBcQHDIMMTxCftXkV54AqxEj3pMc5GciVMsxc4Bty6ka5MpWPTi PvWCL5W4VaOKetXanfr/l4qjIZOjfLTmkgF1uUlobvE1+yb7Gacf3C/IdgjaHJyGoQvC g/zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769416838; x=1770021638; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=NVDW0egVHX3ycdRz6KjAxDpgLlZpCPZ/MyY8UU0Qh28=; b=Eolq3MalymfEWRLC2kxzLd7eIZOpgrfmcywMtEzUckk2vGt4dMXLd7cKP9GUX0KHHG 2ih24N57XTev34Xnu0PLcBnAn3iUZuk+CZU2YVMkGHJe1/qKWND3oizriBl8Qnvq2Ihr Xlr/6rxkw4HB3Dt+1kpfw2aFDY6vNbSNsJgXJrBlOrbxPZ3t1z7evIO0AmfiX01Yw0WT 3WMf9v7wYWaz9hWJ8lpmifQpHbGEhz837zWeKye+kUFCXiOJQz9ysB5S/rPcq3DCQ/bl x1rV+v8bjO3KydTRD9I7aJcWs9xFtDMDL8byPsVuEK9F4zVLIpUXQZPJGRiIqNeCHXUt bb1Q== X-Forwarded-Encrypted: i=1; AJvYcCV5HUSnFXDxeL16Z70RcyBrWuhjjyn6t8nwM9vjWoqQi1QbGyw0Yc7b05e7MYX3nK4Tvh8w5nJor6o=@lists.xenproject.org X-Gm-Message-State: AOJu0YxFelQolDagHFAndXQ0v+4LC7xevaXmuPlYsQ70RMo8S6OZFUC0 snIABUsnkxOtLOUFe8SRZoOug95j41eAJudk6MwEVGkwPY9mgsNxMzkL93xDh1HKtA== X-Gm-Gg: AZuq6aJre0U5kDKTqWAY1MpCkznJdQGYJB/aNiCU68b4F8K1W1Ch6Y0xwjnVn+vu0rb lLo4nmHAKBLKwnLsTt4SFWHCybKOFXL8Ehow4zSR2ljyMeGXQUQe9+6OldOg8NKfxpWzUH2THs+ 8qwSp+l3gySm72P0MXHmwTENVAfiadEMQ1kOlmHOkC/0s9CwmNuP5VM6OiAomOoIRLXkASwP8MC 9Wtzs+dW3lqecPsbuYYR6c1j5EbbAoSAd8fBRshHfFK1Z5JSc0s207+i7ft8hm1xpDRp2Ck6hwz teHelu/SiERphYnHCLfp93LPChznxR1gw+jrcw4FZwwcwrn/5VNZg5U9uAgREjXI1gzz5QkwMnk e2UmK0cPSwnbMMigD8zHeaDOeIGkRJz98K3C/0NijwG0UCCRIx7IMfjhi+nhfgjY3yb1enTssE5 A0ffsYw0U9bxG4SkKrSF3NIcCtJV/R/6F79+rIC1vZ8rjwDEImQ2Oa1fGc4HTWY66aAloJRIYio jz7H9WynPY1Bg== X-Received: by 2002:a05:600c:a106:b0:477:c71:1fc1 with SMTP id 5b1f17b1804b1-4805e6fd919mr48125825e9.19.1769416837771; Mon, 26 Jan 2026 00:40:37 -0800 (PST) Message-ID: <95ae189f-5642-49a0-81df-d019b4a28c8f@suse.com> Date: Mon, 26 Jan 2026 09:40:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/4] x86/hvm: Remove cross-vendor checks from MSR handlers. To: Andrew Cooper , Alejandro Vallejo Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <20260122164943.20691-4-alejandro.garciavallejo@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 23.01.2026 19:35, Andrew Cooper wrote: > On 22/01/2026 4:49 pm, Alejandro Vallejo wrote: >> Not a functional change now that cross-vendor guests are not launchable. >> >> Signed-off-by: Alejandro Vallejo >> --- >> xen/arch/x86/msr.c | 6 ++---- >> 1 file changed, 2 insertions(+), 4 deletions(-) >> >> diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c >> index ad75a2e108..c9cc4f0692 100644 >> --- a/xen/arch/x86/msr.c >> +++ b/xen/arch/x86/msr.c >> @@ -169,9 +169,9 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) >> break; >> >> case MSR_IA32_PLATFORM_ID: >> - if ( !(cp->x86_vendor & X86_VENDOR_INTEL) || >> - !(boot_cpu_data.x86_vendor & X86_VENDOR_INTEL) ) >> + if ( cp->x86_vendor != X86_VENDOR_INTEL ) >> goto gp_fault; >> + >> rdmsrl(MSR_IA32_PLATFORM_ID, *val); >> break; >> >> @@ -190,8 +190,6 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) >> * the guest. >> */ >> if ( !(cp->x86_vendor & (X86_VENDOR_INTEL | X86_VENDOR_AMD)) || >> - !(boot_cpu_data.x86_vendor & >> - (X86_VENDOR_INTEL | X86_VENDOR_AMD)) || >> rdmsr_safe(MSR_AMD_PATCHLEVEL, val) ) >> goto gp_fault; >> break; > > Hmm.  Thinking about it, this would probably be cleaner to get rid of > the cp->x86_vendor field entirely, and retain the boot_cpu_data side. I was wondering of exactly this (particularly in the context here), so: +1. Jan > Additionally, this would fix a minor problem I'm having cleaning up the > CPUID code for XSAVE fixes, and provide better cache locality. > > ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jan 26 08:58:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 08:58:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213401.1523873 (Exim 4.92) (envelope-from ) id 1vkIQJ-0004WO-Oa; Mon, 26 Jan 2026 08:58:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213401.1523873; Mon, 26 Jan 2026 08: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 1vkIQJ-0004WH-Lr; Mon, 26 Jan 2026 08:58:15 +0000 Received: by outflank-mailman (input) for mailman id 1213401; Mon, 26 Jan 2026 08:58: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 1vkIQI-0004WB-Jw for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 08:58:14 +0000 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [2a00:1450:4864:20::342]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 248ddba5-fa95-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 09:58:12 +0100 (CET) Received: by mail-wm1-x342.google.com with SMTP id 5b1f17b1804b1-47f3b7ef761so30150975e9.0 for ; Mon, 26 Jan 2026 00:58:12 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804d8a5b2dsm278946605e9.9.2026.01.26.00.58.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 00:58:11 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 248ddba5-fa95-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769417891; x=1770022691; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=dRPe7PdyVz85WO6LjcrmpjwqGpEF32GvYnuIXwFCzOg=; b=hBD6ry2Fpz2SLNXpDbqzTxiK8N/UFy978qVmQQifr8jzQL2uljKlowZbSoY2JcA/MQ ndlsK6v/FelvUXSIkMGSVm24dmJgZcH/k0d7uaeIxEGovoaBRgGM9cv66Hm3DXwg7yLd GZ2eFUhGnog8eOD7ZFSvomRbuK/ZH5DQKTjITusDrZbqln8qkxpoF+L2kEWgTVGHDtwF 2FWPuBtX2vtNQvbPxRL3Ea48GkXCJBi2TST94t4uR8E0ollYvhonxsu8ge5MTsgRuD3m tDK7iRio2gOVThIWHLZUHhVWOgSQ5JaWyUqVtz9VWOc3CVI816HaZDfEI+O3gu+j4yCv AJCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769417891; x=1770022691; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=dRPe7PdyVz85WO6LjcrmpjwqGpEF32GvYnuIXwFCzOg=; b=Xziq+6cBRD7+Cw30eXW9j8SSJcOT2kuoJVozdN0oy1mH59h0hcRrGpiU3YBbpyisXI ECMpEdXt74vzX4LsBP2ib3c7uedooKivUwJLGOW8U1hxNHaSdFEvS/5GRzs/XcgoQJYv 5HI81dC7QuJSkgXTNzATiiQfW8qxWfLxNp/bxhFtjtzPyy4lfkKNNubu+F0r+MHkHbar o+EBZyT2e7cr+uzJbqhpjXATUhu9iZPNKBY6SwLWwaKzgB1zBq89UMa0GCeaMqGFFgO9 Dw6k8/TD6/D7S8KIlzyHW2LtmkLr3LJlsLDGt6gkmhwT8m/blvXE1Q7BzD3/GNzXwzYQ IKGg== X-Forwarded-Encrypted: i=1; AJvYcCV6oeLHkeEOF5mbF26tIIFut5rwTloCrpw+FMTeTm00JBqpEkEqAXbvywufx9nXFahKzgic2u1OTDs=@lists.xenproject.org X-Gm-Message-State: AOJu0YyioQ3IqwY1LMuOHyeEuNpRnoetks03twwVi7yt8uSAhp9m3f8D Tx9EhnqV3vJrIQoTkl4nx6DFszueeEi6E84BTyxSSysP1t4c9kAsGYiiRKOLsXqWMg== X-Gm-Gg: AZuq6aJiSgAGF6VPZr6KAZn9a0T1h8iZFoC5A4MqcpR+6O6eBgu2HmFdK0ppViczKMb CyLSed7FH1jjSkWx5T9T+9nkDIbVAGAyal5ZLIwQpQEGDFFesNn2MwhUHeW+cR4IxWhhJH2ndfj q4x1H4m8IWSSKovTFIBP8ihKheOpRWvYhSUAFGKJlSIefCbh9IsvoTkr8CohthlsTk8mbTKzBFa pb6FrPKBmZdO0WdukPr52kq9KG5sD5iDhabgdtcEjMlKf2FF9UFZ/m7Pz+gM3/0jSQ5knxyK6of AE9huuoDubzo5RzYOV1yEiECRD7imvNNa2NZzOlAJaaEqQ6qqiE3IiM+hH705Ryq4SWX5QxtWBk QAZevXrcndejTm+7lGM6PXC2i/7U0QrBIGDMIdECd+RHm7PxThhuuJCgNWr10vHaPM6sZeI1ABQ 5uEsESKFIfoSxzYOI9grxDy9hDv9a6nzk0T/H1vGASby0kwo2Tgmrg3jjhvNjlNcJQYAv1I/+T3 rU= X-Received: by 2002:a05:600c:8710:b0:477:7925:f7fb with SMTP id 5b1f17b1804b1-4805f65c091mr46488935e9.10.1769417891387; Mon, 26 Jan 2026 00:58:11 -0800 (PST) Message-ID: <553d1a7a-e465-413f-a60f-32455bbce621@suse.com> Date: Mon, 26 Jan 2026 09:58:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/4] PCI: determine whether a device has extended config space To: Stewart Hildebrand 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: <58091dc1-7bda-4536-8200-2d0a5679d4d1@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23.01.2026 23:24, Stewart Hildebrand wrote: > On 1/19/26 09:46, Jan Beulich wrote: >> Legacy PCI devices don't have any extended config space. Reading any part >> thereof may return all ones or other arbitrary data, e.g. in some cases >> base config space contents repeatedly. >> >> Logic follows Linux 6.19-rc's pci_cfg_space_size(), albeit leveraging our >> determination of device type; in particular some comments are taken >> verbatim from there. >> >> Signed-off-by: Jan Beulich > > Reviewed-by: Stewart Hildebrand Thanks, but see below (as that may change your take on it). >> --- >> Should we skip re-evaluation when pci_mmcfg_arch_enable() takes its early >> exit path? > > I don't have a strong opinion here, though I'm leaning toward it's OK as is. Maybe I need to add more context here. Not short-circuiting means that for a brief moment ->ext_cfg for a device can be wrong - between pci_check_extcfg() clearing it and then setting it again once all checks have passed. As long as only Dom0 is executing at that time, and assuming Dom0 actually issues the notification ahead of itself playing with individual devices covered by it, all is going to be fine. With hyperlaunch, however, DomU-s can't be told "not to fiddle" with devices they've been assigned. With the yet-to-be-written vPCI counterpart changes the window is actually going to get bigger for DomU-s using vPCI. For hyperlaunch this is going to be interesting anyway, on systems like the one you mentioned. First, without Dom0 / hwdom, how would we even learn we can use MCFG? And even with hwdom, how would we keep DomU-s from accessing the devices they were passed until ->ext_cfg has obtained its final state for them (and vPCI reached proper state, too)? >> The warning near the bottom of pci_check_extcfg() may be issued multiple >> times for a single device now. Should we try to avoid that? > > If I'm reading Linux drivers/xen/pci.c correctly, my understanding is that dom0 > will only invoke PHYSDEVOP_pci_mmcfg_reserved once per mmcfg segment, so in > practice it's unlikely to spam. In other words, I think it's OK as is. Yes, it ought to be no more than twice, but that's still one time more than strictly needed. Hence my (mild) concern. >> Note that no vPCI adjustments are done here, but they're going to be >> needed: Whatever requires extended capabilities will need re- >> evaluating / newly establishing / tearing down in case an invocation of >> PHYSDEVOP_pci_mmcfg_reserved alters global state. > > Agreed. The current patch is prerequisite for this work. Hm, perhaps we could > create a gitlab ticket for it? Personally I'm not a fan of gitlab tickets, and just in case no-one else gets to it I have this on my todo list already anyway. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 26 09:00:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 09:00:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213412.1523883 (Exim 4.92) (envelope-from ) id 1vkISd-000633-74; Mon, 26 Jan 2026 09:00:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213412.1523883; Mon, 26 Jan 2026 09: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 1vkISd-00062w-4X; Mon, 26 Jan 2026 09:00:39 +0000 Received: by outflank-mailman (input) for mailman id 1213412; Mon, 26 Jan 2026 09:00:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkISb-00062d-7s for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 09:00:37 +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 7a903946-fa95-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 10:00:36 +0100 (CET) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-b884ad1026cso659485166b.2 for ; Mon, 26 Jan 2026 01:00:36 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8867d4d290sm550394266b.34.2026.01.26.01.00.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 01:00:34 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7a903946-fa95-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769418036; x=1770022836; 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=qA1Handwt6LDPUKAb1WD9f9kKzCHf5X64UJ5ohR7i9o=; b=nF8FN861T6gfu8M7A7wXDi5adRAIAtLYKrDjLG/fBFPTfjLYSJnjHMmROXCi3c49TG tJ3wTkVAczcSZHggxc6HMbjBezPdtvfwKc0kiW0zR/xYdrx1wJzPjvbtx2FVS/TBv250 NfZiIH8VaS0dHSn2DnU16ayxtAQ9pWCfzIWhwxL3V/cpLFvYdVY+nfmShvR/zB/MWZxr Uem7bxVaDqRFGz9ARHZfZLEf+cLlObO/ClAo3sHCnpfDhnIpWcDjfFeMOOGQM9iyuPqc lO1LGeHYKxo1+b/KGJ4bNtsiDG3SzrUUfZ1H1TEIGuYXicFt+yfbJh/VmQAWM8uUZDAs Qq3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769418036; x=1770022836; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qA1Handwt6LDPUKAb1WD9f9kKzCHf5X64UJ5ohR7i9o=; b=l0c3/adNR52yWz+SjkzGgNGzZiGK87Jrn0wi9nNtYBX0a0aa/i0+nasq2g2CkWuRBQ Lsscin49SaBV+cpCxAvMLBxl5G+5n/CPm5giqyItcin4H2CnH1pufK56ZPMKq7dgvHED TdjhtHuTEUCL/8msvRnx0rrxjpQYN2053wlG9xqH8ylx6OLbZMi5Ov3cf+USOIiMZFiS t40UVuMjcy0pt0ZBVL114iaYYdCl9p3oJwxHkPJLZGzGyHXlO3seQa4qKjxkBRrGTxcr AcNE+YJKRXxY/IXlzKxhgyGSvMNFo1JZipJ1f2TvbzFz207Yc1062j1q8GdlPLIvG8pZ VUFQ== X-Forwarded-Encrypted: i=1; AJvYcCXK1xU6UxJ9yo9hKoIYdrZKKyr89v0MQLJNLlex0zoxMdJF0hvnwWQJAdXh3miaBarLTSzgb4iNzoc=@lists.xenproject.org X-Gm-Message-State: AOJu0YwjpsRzBkHkELIgAtKGEJvA82NnEP6n0rob9534HQsOn4pHRC+1 ttU+ZCSFbH+I9pTH5ofn1PrQiildxF6PCeUcFJzUYHUf/zx5vf+3w183 X-Gm-Gg: AZuq6aKhibrwbZapvellc867NIjATb9tBiyy685/pyyEyDDb+o4rpFd+YX0iH429Lr9 zWEFiJb7CSpDJT8m2lPRoz3szUTEFrDnXJB905JSRDwKFa1LBskwwSgJottT7pMVPOb4prCSn9m yxSPMJg43QHV0Nhiq78kirGc2XKOl1DDpkjrYHNkJw3xB356cKWAy/ed5pZ/FyN/Hsu8pLhrwNe jGnbR2jULDjU4WG4dToU3kEUgD4sz4bPYXwduDnFudfzr58o4rIrilMs7Eooc0g2NFhLdBLA6tG YKn0i14cklr09/SfXqj/L6rIjQ+PjdShdziqpnl83JD0Tz+xPqKgQecE/Uel9ri6ShpMHBow47+ lVQLSsJgMnKXdteqxGdfN1b1Cck7452XbHsw9e7/aXo4ED+Eb24REbTGg3QqdN/ilNEKLCR4/Nl LbeTQFIYSpr1PQTKn2QCPqI/JO4FYvTCVDw/ygCUqiHicXHTCf4zm/XPI47dOSIFQ= X-Received: by 2002:a17:907:9450:b0:b8a:f2de:e329 with SMTP id a640c23a62f3a-b8d20a1d7d6mr281616466b.25.1769418035107; Mon, 26 Jan 2026 01:00:35 -0800 (PST) Message-ID: <06ee98c0-ec69-4955-a070-b0f611c8152e@gmail.com> Date: Mon, 26 Jan 2026 10:00:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 02/16] xen/riscv: implement arch_vcpu_{create,destroy}() To: Teddy Astie , xen-devel@lists.xenproject.org Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey References: <08b582179ebc4241140000972d89209c84c90fa4.1769099885.git.oleksii.kurochko@gmail.com> <4e2bf819-81f6-40f8-9bc3-c53aabf0967c@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <4e2bf819-81f6-40f8-9bc3-c53aabf0967c@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hello Teddy, On 1/23/26 12:30 PM, Teddy Astie wrote: > Hello, > > Le 22/01/2026 à 17:49, Oleksii Kurochko a écrit : >> Introduce architecture-specific functions to create and destroy VCPUs. >> Note that arch_vcpu_create() currently returns -EOPNOTSUPP, as the virtual >> timer and interrupt controller are not yet implemented. >> >> As part of this change, add continue_new_vcpu(), which will be used after >> the first context_switch() of a new vCPU. Since this functionality is not >> yet implemented, continue_new_vcpu() is currently provided as a stub. >> >> Update the STACK_SIZE definition and introduce STACK_ORDER (to align with >> other architectures) for allocating the vCPU stack. >> >> Introduce struct cpu_info to store per-vCPU state that lives at the top >> of the vCPU's stack. >> >> Signed-off-by: Oleksii Kurochko >> --- >> Changes in v2: >> - Drop BUILD_BUG_ON() in arch_vcpu_create() as a check isn't very useful. >> - Use vzalloc() instead of alloc_xenheap_page() to use the larger domheap to >> allocate vCPU's stack. >> - Drop printk() inside arch_vcpu_create() to not have potential big noise >> in console as it could be that an amount of vCPUs is pretty big. >> - Use XVFREE() instead of free_xenheap_pages() as vCPU's stack allocation >> happens with a usage of vzalloc() now. >> - Drop stack field as it is enough to have only cpu_info as stack pointer >> could be calculated based on cpu_info. >> - Drop cast when v.arch.cpu_info is inialized as it is not necessary >> to have it. >> - Drop memset() for arch.cpu_info() as it is enough to have vzalloc(). >> --- >> xen/arch/riscv/Makefile | 1 + >> xen/arch/riscv/domain.c | 59 ++++++++++++++++++++++++++++ >> xen/arch/riscv/include/asm/config.h | 3 +- >> xen/arch/riscv/include/asm/current.h | 6 +++ >> xen/arch/riscv/include/asm/domain.h | 2 + >> xen/arch/riscv/stubs.c | 10 ----- >> 6 files changed, 70 insertions(+), 11 deletions(-) >> create mode 100644 xen/arch/riscv/domain.c >> >> diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile >> index 87c1148b0010..8863d4b15605 100644 >> --- a/xen/arch/riscv/Makefile >> +++ b/xen/arch/riscv/Makefile >> @@ -1,5 +1,6 @@ >> obj-y += aplic.o >> obj-y += cpufeature.o >> +obj-y += domain.o >> obj-$(CONFIG_EARLY_PRINTK) += early_printk.o >> obj-y += entry.o >> obj-y += imsic.o >> diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c >> new file mode 100644 >> index 000000000000..9c546267881b >> --- /dev/null >> +++ b/xen/arch/riscv/domain.c >> @@ -0,0 +1,59 @@ >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> + >> +#include >> +#include >> +#include >> +#include >> + >> +static void continue_new_vcpu(struct vcpu *prev) >> +{ >> + BUG_ON("unimplemented\n"); >> +} >> + >> +static void __init __maybe_unused build_assertions(void) >> +{ >> + /* >> + * Enforce the requirement documented in struct cpu_info that >> + * guest_cpu_user_regs must be the first field. >> + */ >> + BUILD_BUG_ON(offsetof(struct cpu_info, guest_cpu_user_regs) != 0); >> +} >> + >> +int arch_vcpu_create(struct vcpu *v) >> +{ >> + int rc = 0; >> + void *stack = vzalloc(STACK_SIZE); >> + > Are there alignment constraints for the stack ? vzalloc() allocates page-aligned memory as far as I can see: ... va = __vmap(mfn, 1, pages, 1, PAGE_HYPERVISOR, type); ... where 1 -> means align and what will lead that in vm_alloc(): ... start =(start +align)&~(align -1); ... > >> + if ( !stack ) >> + return -ENOMEM; >> + >> + v->arch.cpu_info = stack + STACK_SIZE - sizeof(struct cpu_info); >> + memset(v->arch.cpu_info, 0, sizeof(*v->arch.cpu_info)); >> + > Given that vzalloc ensures that the memory is cleared, you don't need to > clear it another time. Oh, right, missed to drop memset. > >> + v->arch.xen_saved_context.sp = (register_t)v->arch.cpu_info; >> + v->arch.xen_saved_context.ra = (register_t)continue_new_vcpu; >> + > You probably also want to set the first parameter of continue_new_vcpu > (struct vcpu *prev), or otherwise I don't think we want the "prev" > parameter in continue_new_vcpu if it's always going to be 0. It will be set by RISC-V ABI (prev will be stored in a0) when __context_switch() will be called in context_switch(): void context_switch(struct vcpu *prev, struct vcpu *next) { ASSERT(local_irq_is_enabled()); ASSERT(prev != next); ASSERT(!vcpu_cpu_dirty(next)); local_irq_disable(); set_current(next); prev = __context_switch(prev, next); schedule_tail(prev); } First call of the __context_switch() will lead to jump to continue_new_vcpu() function which will have a0=prev. > > IIRC continue_new_vcpu is only meant to bootstrap the new vCPU, not just > perform a context switch to it. > >> + /* Idle VCPUs don't need the rest of this setup */ >> + if ( is_idle_vcpu(v) ) >> + return rc; >> + >> + /* >> + * As the vtimer and interrupt controller (IC) are not yet implemented, >> + * return an error. >> + * >> + * TODO: Drop this once the vtimer and IC are implemented. >> + */ >> + rc = -EOPNOTSUPP; >> + goto fail; >> + >> + return rc; >> + >> + fail: >> + arch_vcpu_destroy(v); >> + return rc; >> +} >> + >> +void arch_vcpu_destroy(struct vcpu *v) >> +{ >> + vfree((char *)v->arch.cpu_info + sizeof(struct cpu_info)); >> +} > That doesn't look correct, you want to vfree what was allocated as the > bottom of stack, i.e > > v->arch.cpu_info + sizeof(struct cpu_info) - STACK_SIZE Agree formula should be correct, now it points to the end of the stack memory. > > Or alternatively introduce bottom of stack as a additional vcpu_arch field. There is not too much sense to have the separate field for that. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Jan 26 09:08:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 09:08:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213421.1523895 (Exim 4.92) (envelope-from ) id 1vkIZo-0006ke-UW; Mon, 26 Jan 2026 09:08:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213421.1523895; Mon, 26 Jan 2026 09: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 1vkIZo-0006kW-QH; Mon, 26 Jan 2026 09:08:04 +0000 Received: by outflank-mailman (input) for mailman id 1213421; Mon, 26 Jan 2026 09:08: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 1vkIZm-0006kO-SF for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 09:08:02 +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 83f4db08-fa96-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 10:08:01 +0100 (CET) Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-42fb6ce71c7so3998075f8f.1 for ; Mon, 26 Jan 2026 01:08:01 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1f7b41asm30484509f8f.39.2026.01.26.01.08.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 01:08:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 83f4db08-fa96-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769418481; x=1770023281; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=01X7aAj9lj3w/C21J0hY3i7tTWbXR2kW8qPUqn1C/OY=; b=VNPEMSPHwJFyKkfSef2rtzzuarksglkqJT34G6rdS/X55lyE5fhw/LB5l1whU9Ac9q phCTZK5bK/f5nK29Z6dOp/lypn81zmR6guffB3VnSR+Hk/GkaOt+o9i2N9YLO/nfnP3t GN36tNz/Gv/4sIylIWPWSkFHH1+VY66H4kvxDr/JVAyCS+q8D/Ae3l9wD8ht1ByaJAFs 0neX8dZhJ4rW6taHf+vEpKg76akId/9gkUcvjEpAhFfSBJLXyNx3cTpGOlQtnY48AKOw 3l1+XWs0bVfPk9jC2X3zgSFs0jlHTRoAk4zPpf5jUQpyevyoR+PtJOFC8kRhkYPHaTrg uqPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769418481; x=1770023281; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=01X7aAj9lj3w/C21J0hY3i7tTWbXR2kW8qPUqn1C/OY=; b=PVpQmpc1FB5czwGLE29+TwAYrX6RZdjICALuTlVJRLxJlHcrzcIIc/ZrpXaed7vTkm 5gfAuSpyS5Jjo7n6juwnDPkOBZy5YpFGKCJorkpw04Z6AHYx9cshHLouP7XEbtn4/KDW LtGNcZoiFKeCE0wC4byRvGK2IdmF+UmZRh6Y0NxTfTzd8yT+N5Me2mebl8soMrbTsYoM 8p3G09LhgXe4corrkRWaP79ZCNikwU+vqhFwg0tcIH7oxDG+OEENlo55ZV7iZonMaKKo 0BUmZlmBe3AqrQf6ALpmJPF411VNr3KYDdIrtyWDXufH+vIwSL+CpSPcDJ+DQfPrnnyO zjvw== X-Forwarded-Encrypted: i=1; AJvYcCXTxpFpjktRIzg42DnvwRN9/s2DfpIfAwQNqhpJnEG9vmQi2ARpTHDoMmuXPNonCg5UwBn92npYuDk=@lists.xenproject.org X-Gm-Message-State: AOJu0Yyn2EDj4qHZ7qabQkUUpAD8Ze8VghBiZl6AeASZbN9HwEvjPrEV bWFq2HPNwad1fpDh/Py8UvxIFDfwCCkP7NoqFzC1lwOPeLiwBUSRzcPft6e2F2flsw== X-Gm-Gg: AZuq6aKsC1lSv79aGdWOLuAwJWiMQ5Lk4AM2qOqaLO2cEYATA0FIxpP4oKQ/0vZf97s uv3SCs/vMisixE/xABIh2hHAFe9P0znbJO+vrNrCGxqlixlAKCS2AIU/Tcym1tL6/wG512ZH3Mp KcS63olNfhE+lsP4J5jfwVE/hgcaspEmav3Af+hu1HuKbpgljduqrWV51zDZzoh5ge9NjeA0YgH KcR8U7HsETqD96W8lP95N2jp7NF5ZukMw44c6mPUU3dvwG7N77+znArDIBSszFS8x9u2L4g/0NI x3t4+t4X9evmxXaDXN45/2aCsAUaO7TL/LZbxpC36zoCrXAGAVlW07xSrvSs/1RjQVN6ManRNtX rTagvV3IMn/s6kno6WusR6cHKilLrAov7Rw5EYzYoS4dLi30RLM6MK3anYX0QTDHHw8M2DYFYrr iVA7o/94kJ8LgBYp3QeqFP5cYBLI5x35Dyn6wSSSyfsI+c+9gxSTHteCXG9lM7NTNQlzxiK9eOs vQ= X-Received: by 2002:a05:6000:2285:b0:432:5bac:3915 with SMTP id ffacd0b85a97d-435ca193e3cmr6268131f8f.39.1769418480954; Mon, 26 Jan 2026 01:08:00 -0800 (PST) Message-ID: <8bad1a32-d59c-4dba-8c35-b28fcb16f39c@suse.com> Date: Mon, 26 Jan 2026 10:08:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/5] cpufreq/hwp: move driver data into policy To: Jason Andryuk Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" References: <8441ada5-e2ed-4d79-822c-ecf1ce3c9484@suse.com> <26ef0e68-efca-4b9a-a210-76b5426da130@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: <26ef0e68-efca-4b9a-a210-76b5426da130@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23.01.2026 23:35, Jason Andryuk wrote: > On 2026-01-22 04:42, Jan Beulich wrote: >> Share space with the ACPI and powernow drivers, avoiding a separate >> allocation for each CPU. Except for get_hwp_para() all use sites already >> have the policy available, and this one function can simply be brought >> closer to its sibling set_hwp_para(). > > Minor, but maybe 's/function/function's signature/'. The original > phrasing made me think it was code movement. I don't see an issue there, but I've adjusted as you asked for. >> This then also eliminates the concern over hwp_cpufreq_cpu_init() being >> called for all CPUs > > We expect hwp_cpufreq_cpu_init() to be called for each CPU, so I am > confused by this statement. The data... Well, "expect" is the problem. Recall my pointing out of the problem when having noticed the same pattern in the amd-cppc driver patches. My recollection from the discussion is that there's no formal statement of ... > >, or a CPU going offline that's recorded in> policy->cpu (which would > result in accesses of per-CPU data of offline >> CPUs). >> >> Signed-off-by: Jan Beulich >> --- >> hwp_cpufreq_target() still requires policy->cpu to be online, though. >> >> --- a/xen/arch/x86/acpi/cpufreq/hwp.c >> +++ b/xen/arch/x86/acpi/cpufreq/hwp.c > >> -static DEFINE_PER_CPU_READ_MOSTLY(struct hwp_drv_data *, hwp_drv_data); > > ... here is tracked and filled per-CPU. > > Do we need cpufreq_add_cpu() to force hw_all = 1 for HWP (and maybe > AMD-CPPC) to ensure that policy is allocated per-CPU? ... this being a correct thing to do, hence our code imo would better be resilient to it being different somewhere. > Are we implicitly relying on shared_type == CPUFREQ_SHARED_TYPE_HW to do > that for us? Right now we do, I believe, without - as said above - this being actually mandated by the spec. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 26 09:39:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 09:39:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213433.1523903 (Exim 4.92) (envelope-from ) id 1vkJ4M-0002Ta-7l; Mon, 26 Jan 2026 09:39:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213433.1523903; Mon, 26 Jan 2026 09:39:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkJ4M-0002TT-54; Mon, 26 Jan 2026 09:39:38 +0000 Received: by outflank-mailman (input) for mailman id 1213433; Mon, 26 Jan 2026 09:39:36 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkJ4K-0002TN-JR for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 09:39:36 +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 e79e43e5-fa9a-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 10:39:26 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-4801d1daf53so47074725e9.2 for ; Mon, 26 Jan 2026 01:39:26 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804d8a5b2dsm281554265e9.9.2026.01.26.01.39.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 01:39:25 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e79e43e5-fa9a-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769420366; x=1770025166; 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=ydSZiIt/GlLMYi1NrS1QCfMnBHYe/z17fCtuAwY3Xcs=; b=A2yi2NtWZzYVdWAWVQm92a0noNWV6iYbYgRrkmsCFHaTkACRqBCcXoLvz7v4OIIrAv Y7ShZT8+PblSjH7V3oJMqo0CkV9+pCxpXHuhbyBuF7ggdFZzKLCbCLQMHvmQ2RR3G+ua n18ruMovNZDB69hoEz8l8AYQLNP9vy+A3mHAod+PP9nVmZgJj7sB7uc5QCML1lZfNLVY U7DxwNycH4kD4vJmuopDc5TRSvux/vlKX231VEVFbJAwGvFs5+PoNTvlsvlAbNszNes7 3OYCA3M2eMoXrND7cB5Wur/JP20fvGyGGeMv4iQwEzkgTRTCMWjyJqEV4weOD/u5cbJT UKaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769420366; x=1770025166; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ydSZiIt/GlLMYi1NrS1QCfMnBHYe/z17fCtuAwY3Xcs=; b=SkMHt+NqVGGraWOUpojHG7cNDo43ms4GRlxD29r0+OYo4/GrOhTcJ0uV8CSmLoOs3a Wa5xS1RQ8XResbftYOz3Htg3pzZKWT579ngZeMwd58XzE3A7ZMJVba+E9a6Ddyd/8BGk PYmJkwmNOhgReDXXKin18q66rq3MMmxRxPBfF43Fv0WcTae6S0yM/dYtYR9xTIp5lVc8 yjDtp+VklA5nGdu5BH7Grxqq9g9r8WfZixMM65TjLQ93HvcEyoVDcee0oEPxKp6KjQch pilHO/+Eyw1fLNjrRwc7YCg15h7PbGxQNAuq6q3LIiegx+/d7yZ9OGBL0UR8yxG7fp1h 0tew== X-Forwarded-Encrypted: i=1; AJvYcCXgtD/iVvjMW825A1gTcoLGlsgFsf4Cd8ncdeq62GkM2IvjfvWk4ufxC4XWXnkXGjqFCJ7zUT81+no=@lists.xenproject.org X-Gm-Message-State: AOJu0Yylr/eqGFOowsz7ZwhXNijVKNOe9J7ByeueDXnePFiuTMrLEdNm 9YPAXrbRdiHgI0DC9iDekCBpZTauFUliJLv0f4VUw0Jw8Yxss1yZkVPb X-Gm-Gg: AZuq6aJX4jVS9yg9XX88HPX0ifeuBq5IieZIM0Zs3wq3UjpX+z6pt9lZeEdEBTlSwq3 JqiH8l7JnNRfHMPON1v65N5QNdWAZT+LzRutGtS728OxBz1kjaruiVdhbk3XB3R57JUHKvoZWCb AAURwsqAUp1h8EPPFwjwJesNx+rDDl7U4mmnfJXrkTQOCpz1rYMBfe8scg21SdSNOh5yHuTDLWL zXtsnP2T1Og3cWTrBEPV+fj92yIR/dAVqQ1IiKvBnQ4kt+nF9m9gX4BL1tlxs1RWYy0+UBEwK2A kLvbRiWQau4KDmwufMepnQEHIYxVxLBnZUjJbAx/g0o+eR652vHD3edewBh/3uxYzMgCfpmech0 P4qPIwoNX5PRZw5h7iQ9d5OER4zE9idCcW10oN4Fb56c9S/otRI7E9Q66fjxjfdxgnbxHi8Hpfl BzdqQtYQQwqbgV+4hAg+0lh83ispUBw27fwB7pS5oGV6Ck1wA4m/OlN2rI2ebrDQs= X-Received: by 2002:a05:600c:1d06:b0:47d:6140:3284 with SMTP id 5b1f17b1804b1-4805d06cd4fmr45401595e9.37.1769420365887; Mon, 26 Jan 2026 01:39:25 -0800 (PST) Message-ID: Date: Mon, 26 Jan 2026 10:39:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/16] xen/riscv: implement vcpu_csr_init() To: Teddy Astie , xen-devel@lists.xenproject.org Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey References: <57ef3bcff854d4b50641641d300b3e8aa715c3c3.1769099885.git.oleksii.kurochko@gmail.com> <99289a63-b4be-42f8-974b-7445a6a479dc@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <99289a63-b4be-42f8-974b-7445a6a479dc@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/24/26 11:44 PM, Teddy Astie wrote: > Le 22/01/2026 à 17:49, Oleksii Kurochko a écrit : >> Introduce vcpu_csr_init() to set up the initial hypervisor-visible CSR >> state for a vCPU before it is first scheduled. > To me, "hypervisor-visible CSR state" sounds like some state of the > guest the hypervisor has view on. But to what I read, it's more > hypervisor state CSRs regarding what to intercept and various > virtualization behavior. I'll rephrase then to: Introduce vcpu_csr_init() to initialise hypervisor CSRs that control vCPU execution and virtualization behaviour before the vCPU is first scheduled. > >> The function configures trap and interrupt delegation to VS-mode by >> setting the appropriate bits in the hedeleg and hideleg registers, >> initializes hstatus so that execution enters VS-mode when control is >> passed to the guest, and restricts guest access to hardware performance >> counters by initializing hcounteren, as unrestricted access would >> require additional handling in Xen. >> When the Smstateen and SSAIA extensions are available, access to AIA >> CSRs and IMSIC guest interrupt files is enabled by setting the >> corresponding bits in hstateen0, avoiding unnecessary traps into Xen >> (note that SVSLCT(Supervisor Virtual Select) name is used intead of >> CSRIND as OpenSBI uses such name and riscv_encoding.h is mostly based >> on it). >> If the Svpbmt extension is supported, the PBMTE bit is set in >> henvcfg to allow its use for VS-stage address translation. Guest >> access to the ENVCFG CSR is also enabled by setting ENVCFG bit in >> hstateen0, as a guest may need to control certain characteristics of >> the U-mode (VU-mode when V=1) execution environment. >> >> For CSRs that may contain read-only bits (e.g. hedeleg, hideleg, >> hstateen0), the written value is re-read from hardware and cached in >> vcpu->arch to avoid divergence between the software state and the actual >> CSR contents. >> > AFAIU from RISC-V isa document, at least for some CSRs the read-only-0 > bits are well-defined and means "can't be configured" due to not having > a meaning (e.g hedeleg defines as read-only "Environment call from > HS-mode" because guest can't be in a "actual" HS-mode). It was said about bits which hypervisor tries to set in the mentioned registers and IIRC all of them could be r/o-0 as, for example, M-mode can decide not to delegate them to HS-mode. > >> As hstatus is not part of struct arch_vcpu (it already resides in >> struct cpu_user_regs), introduce vcpu_guest_cpu_user_regs() to provide >> a uniform way to access hstatus and other guest CPU user registers. >> >> This establishes a consistent and well-defined initial CSR state for >> vCPUs prior to their first context switch. >> >> Signed-off-by: Oleksii Kurochko >> --- >> Changes in v2: >> - As hstatus isn't a part of arch_vcpu structure (as it is already a part of >> cpu_user_regs) introduce vcpu_guest_cpu_user_regs() to be able to access >> hstatus and other CPU user regs. > Sounds like hstatus wants to be splitted from guest_cpu_user_regs (which > are supposed to be GPR ?). Generally, agree. But hstatus want to be saved during a trap even before guest is started and considering that we already have the code which stores it in guest_cpu_user_regs structure and handle it during the trap, I've decided just to drop hstatus from arch_vcpu. > >> - Sort hideleg bit setting by value. Drop a stray blank. >> - Drop | when the first initialization of hcounteren and hennvcfg happen. >> - Introduce HEDELEG_DEFAULT. Sort set bits by value and use BIT() macros >> instead of open-coding it. >> - Apply pattern csr_write() -> csr_read() for hedeleg and hideleg instead >> of direct bit setting in v->arch.h{i,e}deleg as it could be that for some >> reason some bits of hedeleg and hideleg are r/o. >> The similar patter is used for hstateen0 as some of the bits could be r/o. >> - Add check that SSAIA is avaialable before setting of SMSTATEEN0_AIA | >> SMSTATEEN0_IMSIC | SMSTATEEN0_SVSLCT bits. >> - Drop local variables hstatus, hideleg and hedeleg as they aren't used >> anymore. >> --- >> xen/arch/riscv/cpufeature.c | 1 + >> xen/arch/riscv/domain.c | 73 +++++++++++++++++++++ >> xen/arch/riscv/include/asm/cpufeature.h | 1 + >> xen/arch/riscv/include/asm/current.h | 2 + >> xen/arch/riscv/include/asm/riscv_encoding.h | 2 + >> 5 files changed, 79 insertions(+) >> >> diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c >> index 02b68aeaa49f..03e27b037be0 100644 >> --- a/xen/arch/riscv/cpufeature.c >> +++ b/xen/arch/riscv/cpufeature.c >> @@ -137,6 +137,7 @@ const struct riscv_isa_ext_data __initconst riscv_isa_ext[] = { >> RISCV_ISA_EXT_DATA(zbb), >> RISCV_ISA_EXT_DATA(zbs), >> RISCV_ISA_EXT_DATA(smaia), >> + RISCV_ISA_EXT_DATA(smstateen), >> RISCV_ISA_EXT_DATA(ssaia), >> RISCV_ISA_EXT_DATA(svade), >> RISCV_ISA_EXT_DATA(svpbmt), >> diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c >> index 9c546267881b..3ae5fa3a8805 100644 >> --- a/xen/arch/riscv/domain.c >> +++ b/xen/arch/riscv/domain.c >> @@ -5,6 +5,77 @@ >> #include >> #include >> >> +#include >> +#include >> +#include >> + >> +#define HEDELEG_DEFAULT (BIT(CAUSE_MISALIGNED_FETCH, U) | \ >> + BIT(CAUSE_FETCH_ACCESS, U) | \ >> + BIT(CAUSE_ILLEGAL_INSTRUCTION, U) | \ >> + BIT(CAUSE_BREAKPOINT, U) | \ >> + BIT(CAUSE_MISALIGNED_LOAD, U) | \ >> + BIT(CAUSE_LOAD_ACCESS, U) | \ >> + BIT(CAUSE_MISALIGNED_STORE, U) | \ >> + BIT(CAUSE_STORE_ACCESS, U) | \ >> + BIT(CAUSE_USER_ECALL, U) | \ >> + BIT(CAUSE_FETCH_PAGE_FAULT, U) | \ >> + BIT(CAUSE_LOAD_PAGE_FAULT, U) | \ >> + BIT(CAUSE_STORE_PAGE_FAULT, U)) >> + >> +#define HIDELEG_DEFAULT (MIP_VSSIP | MIP_VSTIP | MIP_VSEIP) >> + >> +static void vcpu_csr_init(struct vcpu *v) >> +{ >> + register_t hstateen0; >> + >> + csr_write(CSR_HEDELEG, HEDELEG_DEFAULT); >> + v->arch.hedeleg = csr_read(CSR_HEDELEG); >> + >> + vcpu_guest_cpu_user_regs(v)->hstatus = HSTATUS_SPV | HSTATUS_SPVP; >> + >> + csr_write(CSR_HIDELEG, HIDELEG_DEFAULT); >> + v->arch.hideleg = csr_read(CSR_HIDELEG); >> + > To me, that feels odd to set machine CSR here. Especially if (I guess) > that we would update them anyway during context switches. Yes, they will be updated anyway. When this approach was initially suggested, I considered the case where some code might attempt to use these bits before the context-switch logic runs. In that situation, we could end up executing code that assumes the feature is available (because the bit is set in|v->arch.some_reg|), only to later discover that the corresponding CSR bit is read-only zero. > > I think it would be better to have : > - vcpu_csr_init -> sets initial state CSR in vcpu structure, doesn't > touch machine CSR > - context switching logic -> loads vcpu-specific machine CSR from vcpu > structure > > We would have to make a context switch to enter the vcpu for the first > time; but that's to be expected. > > With my proposal, we would also want to move the vcpu_csr_init() > invocation to the place we initialize the vcpu_arch structure rather > than the first time we schedule inside that vcpu. I think I may be misunderstanding something here. vcpu_csr_init() is now called from arch_vcpu_create(), which initialises architecture-specific arch_vcpu fields. Am I missing something? > > That would also allow to take account of per-domain configuration if we > need to (e.g feature flags). Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Jan 26 09:48:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 09:48:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213448.1523913 (Exim 4.92) (envelope-from ) id 1vkJCW-0004EQ-41; Mon, 26 Jan 2026 09:48:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213448.1523913; Mon, 26 Jan 2026 09:48: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 1vkJCW-0004EJ-13; Mon, 26 Jan 2026 09:48:04 +0000 Received: by outflank-mailman (input) for mailman id 1213448; Mon, 26 Jan 2026 09:48: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 1vkJCU-0004ED-8R for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 09:48:02 +0000 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [2a00:1450:4864:20::329]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 14a7a90f-fa9c-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 10:47:51 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-47ee76e8656so62928075e9.0 for ; Mon, 26 Jan 2026 01:47:51 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804d6160d2sm103200715e9.2.2026.01.26.01.47.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 01:47:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 14a7a90f-fa9c-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769420871; x=1770025671; 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=Xb3uG/R5vsjL2a359RoPR99kk2+Mo9/RkJpZ4UJlyzU=; b=Ruqyx2sVGwk0MfLM4yNN1/gPi2/SrRM1LKC+OjN8DkLfPyh/UCoqznL0A13x7g1K2b 1kq6rCH2n26oiDglJuZwjLwN39rvFVU0WkRwI8cF5qo4jcUUBjNhXk/myU2JXkPJPIyu YY5mCfeI7eSfZZKJ+XbMK/976WJDKKspGxeT5n5B2VuTDFXfro3RtH9GJvErZek99hlB doQhY0sSz0w0/ZGhGlAjk9HDop+8gRaPQy/fFMyRvZsyaR8bJkCg5+YUhzHH+6XjFKQt H3wFlOmBuXGrEmx/pkBGyko3DY1TX/O6rFrgQMNsKcWX3p2GYdzyy3R9EI3VZYo2ytOr m5gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769420871; x=1770025671; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Xb3uG/R5vsjL2a359RoPR99kk2+Mo9/RkJpZ4UJlyzU=; b=cFTmQvyceKI+RHWXwejLEkdQN/INqdzat6M9lL1umNYJav2Mo5BWbpQDDhrFgGvfVr m379UbtBpjKKpjUXJJey5CdaZKSeeNJ+LIpNmYOhV/g5Lz2xAZrNbtNs6zKNm7r+o9XR PbdKIG663e5FS8QvRVnFKfQs6XvayNovKO1k1teK4cCkthHrYT1z6fWbrb+HbvA4AfZu cSpUruepZ923pwjnLuAHxUz5GfZ8TydAbzlshD7xOMz1j3FeMBudGku4ZTmYNgBEADsq Y29b/CDA4yMa2MYXsHQOGGkWPwI38fje2uKoWVigpxtdOg/sl0wfeU9eHIJ3pQH9GP6H /2RA== X-Forwarded-Encrypted: i=1; AJvYcCVxPfxAxMVfMc9O8zNfqFByoeCsRlzaGBOTJLbj/sDTIJqrIb/rB8UoJjKY7c8cNpEUyCYsf1Z0G5c=@lists.xenproject.org X-Gm-Message-State: AOJu0YzO5H4mOPquq28hXo76C/15vYv/R/92A2HSOsHYnoWLYb08O5Gb m5UVKWyyEhw8okT70aRyxAVKoKqFC7st2BY4QuBAuw14ZVfrtOtIHavM X-Gm-Gg: AZuq6aJ27lksY0ULrDmtBYGDYltP0czNh2tepmRH2khRm4kvHPOY1YhqbY6+boglR0x c1rHmWh4AVES0C9gZJdSMuEe21jEVFM/aBvka5kP6AgskSN/pSDh/h3OVSvuAzj6vRzJ6HJd47v /6DTX/GKqIaRVcUVqqxpVmKvn21BmRvLNZY+84hChdtgAs5XH4Ohg7hsx6hJSkuY0TWxXLIscnp UW3ccs9Owut8ssoOcBqjJA/AoM/peiSrxPcmvYk14+eOOgTcJYp+YXg6AEYfhYChrwp29SGvVXg rV4A7BvXs0eeQKXgxCRClw0VLpj+IYViDcY6LcsDNapBowEiPgkSYdbp44MrOdYKMY9uheFbwhr BBYTm5/G01lHZ7gr0lZVWwc2jF8/cT8pRbxbEXa9fAmkjtu0L07kWZtNaVhTft9c1f04SMotMfw z00bgx3Yb0f3++kjDx35qie4ENRrzeJHM0hL3CGCYSI5tcHxrzt9awXz2nMPUFZ08= X-Received: by 2002:a05:600c:3f18:b0:477:7c7d:d9b2 with SMTP id 5b1f17b1804b1-4805d06ae8dmr63545045e9.32.1769420871012; Mon, 26 Jan 2026 01:47:51 -0800 (PST) Message-ID: Date: Mon, 26 Jan 2026 10:47:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/16] xen/riscv: implement vcpu_csr_init() To: Jan Beulich , Teddy Astie Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <57ef3bcff854d4b50641641d300b3e8aa715c3c3.1769099885.git.oleksii.kurochko@gmail.com> <99289a63-b4be-42f8-974b-7445a6a479dc@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/26/26 9:36 AM, Jan Beulich wrote: > On 24.01.2026 23:44, Teddy Astie wrote: >> Le 22/01/2026 à 17:49, Oleksii Kurochko a écrit : >>> +static void vcpu_csr_init(struct vcpu *v) >>> +{ >>> + register_t hstateen0; >>> + >>> + csr_write(CSR_HEDELEG, HEDELEG_DEFAULT); >>> + v->arch.hedeleg = csr_read(CSR_HEDELEG); >>> + >>> + vcpu_guest_cpu_user_regs(v)->hstatus = HSTATUS_SPV | HSTATUS_SPVP; >>> + >>> + csr_write(CSR_HIDELEG, HIDELEG_DEFAULT); >>> + v->arch.hideleg = csr_read(CSR_HIDELEG); >>> + >> To me, that feels odd to set machine CSR here. Especially if (I guess) >> that we would update them anyway during context switches. >> >> I think it would be better to have : >> - vcpu_csr_init -> sets initial state CSR in vcpu structure, doesn't >> touch machine CSR >> - context switching logic -> loads vcpu-specific machine CSR from vcpu >> structure >> >> We would have to make a context switch to enter the vcpu for the first >> time; but that's to be expected. >> >> With my proposal, we would also want to move the vcpu_csr_init() >> invocation to the place we initialize the vcpu_arch structure rather >> than the first time we schedule inside that vcpu. > Aiui the writes were put here to be able to cope with r/o-zero bits. Yet > indeed it can't be cone like this. While it may work for domains created > during boot, these CSRs would be changed under the feet of a running vCPU > when done this way for domain creation later at runtime. Why these CSRs would want to be changed when we have already running vCPU? Even they will be changed what is an issue, they will be sync-ed during context switch. > > Instead, as I think I had also suggested earlier on, the r/o-zero-ness of > bits in particular CSRs wants determining once during boot, and then that > mask wants using when setting up vCPU-s. Somewhere even before create_domUs() will be called? ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Jan 26 09:54:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 09:54:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213458.1523923 (Exim 4.92) (envelope-from ) id 1vkJId-0005mc-OD; Mon, 26 Jan 2026 09:54:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213458.1523923; Mon, 26 Jan 2026 09:54: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 1vkJId-0005mV-LT; Mon, 26 Jan 2026 09:54:23 +0000 Received: by outflank-mailman (input) for mailman id 1213458; Mon, 26 Jan 2026 09:54: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 1vkJIc-0005mP-66 for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 09:54:22 +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 fbb899da-fa9c-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 10:54:19 +0100 (CET) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-4359a16a400so3918005f8f.1 for ; Mon, 26 Jan 2026 01:54:19 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804d84ebb9sm235909645e9.4.2026.01.26.01.54.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 01:54:18 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fbb899da-fa9c-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769421259; x=1770026059; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Vqs3yXOIVelZMGZPOqu1S/alAIdQFNs2IhkLK3/smII=; b=MrVM3suS1JYeCTCUffqQN+lOqE0F+6f7SqQwzbFNmT2F3xWXnUHzcFHGi4/Eg6yjPV ZK0PjC0gy3T1fZJgwgBPhbzu+2ralWvIpkxpGRdODHfa2telJOdn5jTE7GLcch4AdRpi ioFx0ztAv2wZE6uGVEjHgvSfZskJPGy3qXSrEY3n2yqvp4CVPV70fHI3uyo2a/ZghlIy Vnk4X1QcL3dFHHkdADJBy1ZLXmPr2efYZEIONqmtlz3eNFBGIGuHDLIuUbvIBMrwheKo AhAi8qtAy9LDH1Z7ZQOk/sskaqMzBTkrCWstxiww+gJNVo9QfWMQwFrzeJcwTUgcfDUm wsmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769421259; x=1770026059; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Vqs3yXOIVelZMGZPOqu1S/alAIdQFNs2IhkLK3/smII=; b=viSryiwRIAR/qQaWwYn/jf2dTPbigIT0o72Y5S5DsWY1M9r7zUVL2rLEJaeQOqKM9Y dtZskvwNXwMgVo6ef2qxoGy7Cjk8HEJLiqL10bRtclotTBcB5ZDRlioa6Cca0wn/puli myh7bs/7kdrffwysASldql6H6OKzqzYb9vCWxx59P6f3tzGOShVt5SHdOpAWs1FzJfmW Czq5KTJhP7FkwZaZJxPSstDYjMlOpbTkpgQ1tnJsNzbZ3mg3JccgMOsMl1r3l7Tg+315 JJONry2b8O0Ki5WdvBwh9Z255Nc2+MmdfzZ2fn70bubF0KjtLz44Efdy1IaAIoiZjdhV O0GQ== X-Forwarded-Encrypted: i=1; AJvYcCUSQV3U7meABPB1FmjPbYgJTlR+ERVMfYBzKiDJswuiB8LmEK63oFezpB0MgjlK+p2O5ynRbbFRrYI=@lists.xenproject.org X-Gm-Message-State: AOJu0YzHn3CkPo+Upac6xoV1h2o92OGmlS2CVOLvd9rJHdLHGjY6egbK OTdC0WL5y6h00pnxyh8BhAmLrgA0OMI/nM3HejH7vFB6vjT/3P1oY/+GBi2aayYm7Q== X-Gm-Gg: AZuq6aIc+4VxkvQaw0N3xeE0kzUt1G55OK5mdNMibkqnCHp0DWD3gmRzxqvrMRoJ1CM oJWaRI3RogYxvoXrlilDGGSRHlHAMoPnESKLLcYoSK+ub3L7QgPBZAiKj4763LsNzwx45rHZttj 9oejwa3OCKZH4/Qoht2HNikIAusljoxL3oDJn6PieWNolxrbj801zOeUmgy6/ZLIrzZl5gdkzY/ QkOZObTYfUX21qW3JcYpbLgeZXCvxmrcaysZe+P96NbssxAd0wb/T+Y9/anxLxGBBFTTNqgbRNd pGFqLwJF+FCjNO/h4xiCudMDwbNIYyC/ZGrpty9UuHBsR6RTYSp7JBork2aqy2r6s31N3Ir0RLl xSL2212ltSP6SEpsmxbnVjcTFOrvYewrsiU5e5mMh86zMg46UQ3BeEtzwJ2B3AQTxndhqYyHSGz Duee4ezgeMT/Lv4mrmKYE6/vB7nFxQUcFc3eYD7xKSuNUx5TsHYJDmQ6SrHENnpesERlz4IabK2 H8= X-Received: by 2002:a05:600c:530e:b0:47e:de9c:92ec with SMTP id 5b1f17b1804b1-4805ce4e568mr63723705e9.14.1769421258814; Mon, 26 Jan 2026 01:54:18 -0800 (PST) Message-ID: <66c43a69-f534-471e-8cc9-f549f8ad4649@suse.com> Date: Mon, 26 Jan 2026 10:54:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 03/16] xen/riscv: implement vcpu_csr_init() To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org, Teddy Astie References: <57ef3bcff854d4b50641641d300b3e8aa715c3c3.1769099885.git.oleksii.kurochko@gmail.com> <99289a63-b4be-42f8-974b-7445a6a479dc@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 26.01.2026 10:47, Oleksii Kurochko wrote: > > On 1/26/26 9:36 AM, Jan Beulich wrote: >> On 24.01.2026 23:44, Teddy Astie wrote: >>> Le 22/01/2026 à 17:49, Oleksii Kurochko a écrit : >>>> +static void vcpu_csr_init(struct vcpu *v) >>>> +{ >>>> + register_t hstateen0; >>>> + >>>> + csr_write(CSR_HEDELEG, HEDELEG_DEFAULT); >>>> + v->arch.hedeleg = csr_read(CSR_HEDELEG); >>>> + >>>> + vcpu_guest_cpu_user_regs(v)->hstatus = HSTATUS_SPV | HSTATUS_SPVP; >>>> + >>>> + csr_write(CSR_HIDELEG, HIDELEG_DEFAULT); >>>> + v->arch.hideleg = csr_read(CSR_HIDELEG); >>>> + >>> To me, that feels odd to set machine CSR here. Especially if (I guess) >>> that we would update them anyway during context switches. >>> >>> I think it would be better to have : >>> - vcpu_csr_init -> sets initial state CSR in vcpu structure, doesn't >>> touch machine CSR >>> - context switching logic -> loads vcpu-specific machine CSR from vcpu >>> structure >>> >>> We would have to make a context switch to enter the vcpu for the first >>> time; but that's to be expected. >>> >>> With my proposal, we would also want to move the vcpu_csr_init() >>> invocation to the place we initialize the vcpu_arch structure rather >>> than the first time we schedule inside that vcpu. >> Aiui the writes were put here to be able to cope with r/o-zero bits. Yet >> indeed it can't be cone like this. While it may work for domains created >> during boot, these CSRs would be changed under the feet of a running vCPU >> when done this way for domain creation later at runtime. > > Why these CSRs would want to be changed when we have already running vCPU? > > Even they will be changed what is an issue, they will be sync-ed during > context switch. Which is too late (plus on ctxt-switch-out I assume they'll be synced from HW to internal structures). The problem here is that a vCPU, having invoked a hypercall resulting in a new vCPU (for another domain) to be created, will observe a change of some of the CSRs controlling its own behavior. >> Instead, as I think I had also suggested earlier on, the r/o-zero-ness of >> bits in particular CSRs wants determining once during boot, and then that >> mask wants using when setting up vCPU-s. > > Somewhere even before create_domUs() will be called? Yes, before any domains (and in particular vCPU-s) are created. The idle domain may be an exception here, and system domains (not having vCPU-s) may also be unaffected and hence not depend on particular ordering. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 26 10:08:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 10:08:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213467.1523934 (Exim 4.92) (envelope-from ) id 1vkJWB-0007nv-Rf; Mon, 26 Jan 2026 10:08:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213467.1523934; Mon, 26 Jan 2026 10:08:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkJWB-0007no-O7; Mon, 26 Jan 2026 10:08:23 +0000 Received: by outflank-mailman (input) for mailman id 1213467; Mon, 26 Jan 2026 10:08:22 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkJWA-0007ni-E4 for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 10:08:22 +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 efe121c2-fa9e-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 11:08:19 +0100 (CET) Received: from BYAPR06CA0044.namprd06.prod.outlook.com (2603:10b6:a03:14b::21) by PH7PR12MB9103.namprd12.prod.outlook.com (2603:10b6:510:2f5::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Mon, 26 Jan 2026 10:08:15 +0000 Received: from MWH0EPF000989E6.namprd02.prod.outlook.com (2603:10b6:a03:14b:cafe::19) by BYAPR06CA0044.outlook.office365.com (2603:10b6:a03:14b::21) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.15 via Frontend Transport; Mon, 26 Jan 2026 10:08:14 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by MWH0EPF000989E6.mail.protection.outlook.com (10.167.241.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Mon, 26 Jan 2026 10:08:14 +0000 Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 26 Jan 2026 04:08:14 -0600 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 26 Jan 2026 04:08:13 -0600 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; Mon, 26 Jan 2026 02:08:11 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: efe121c2-fa9e-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=y8VNmAKY6q/dhYudSog3OcjSwruFHp5yYQ0FnQ1MHL16nCpkMHMISBoPunbyDsIUXAL7Yt0St0cnWAMhNJ1XM7T5pV8mkhh5Cn5IOIcv/Hfvd9ZUfZAGkpQdQ0AWEq/ghZCuGWny2VvFBYnLpuBYoFiNhtu0Jrqj3wMjvsjla5jznYPF/Q5bw10MUnUhnHw5pXOzzWU1WA6JjFKV9vYrNJaSyYNeFadokBukuysbPg2dnKRo3HTaGsIibuMf7/985yQaCYw8+ubkFm73U8DOmcnTdogLdJ3guitNOPcmB6ybWieS5+mCJKXxOqOYY6CUZRVktOP53wcAwA/ySbOWBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QN9Krxqu+XkT4/VAup8tVuJ+lrhfh8HF6YERfgMjlvM=; b=YIc7g2Rpz96XNC09L7HmiJBpFG2Eewg+g6u499Ki0lN6OZK/Mjrnbv0qnDgJxGCKx0lc14Zt7kdURvW2dJloc97s03yZmegdJinT0y1T9FL11pS6xSKn5D1X/4qxrOnjZbrs9K+CZhYcXZzc7nrUhqEnCIGae++8QS5eGWu3pWqiE2wOpGMaBhiH+3mzmeNdjm95bWTI8IKe57wjKm1qSXto91pu94L/tEpaAzYVh/LlEu/p4djVqCzY9e1F4zhq2NtIM4mvYgO+8rGKDvxSMcatLQ8vQ24Cyn6qaMry1AnJTBrbfF6szDAxgx+RSDpsvL50AQdMiAmWS1rVw5NYwQ== 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=QN9Krxqu+XkT4/VAup8tVuJ+lrhfh8HF6YERfgMjlvM=; b=ab6dFA+30zWgQrIoBhffJ08DGUKhwolYVnOSs87HRNWE7BTzv4Sv9KjXHK5RTo3IBoG4VBqfS7pZ4UPqC8DgsB7cjKYw6HFFVdl0+jPopJZS8tDuzuEk+F3xQEf6tPH3NfQDKmNWGxg2oPuryQEzGCo0Xey2JaIFqlGis1RFdDc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 26 Jan 2026 11:08:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] kconfig: adjust NR_CPUS defaults 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?= , Oleksii Kurochko References: <1caed635-3d9b-47ed-b8fb-d6c391293059@suse.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <1caed635-3d9b-47ed-b8fb-d6c391293059@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWH0EPF000989E6:EE_|PH7PR12MB9103:EE_ X-MS-Office365-Filtering-Correlation-Id: e7704686-c1d6-45bf-d922-08de5cc2d1b4 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?dWhFREJPTEZaSjA1RmlkanRmLzg4SDdVR1BqTTVlSUFuNEkvd1BJMkJXM2I1?= =?utf-8?B?MklWTzM3Q0ZHL0tPZ2ZYbHRTR3VjcDdjbWl2OHlQUjNHY3JidTFRdWhNb2hO?= =?utf-8?B?ekMvQ3I0a1V6eTFybk50WTVFc2krVlRjc2FMUzNBWlBKa0pFYVJxTis4RXNi?= =?utf-8?B?R3ZYVFo2OUFQcmNGcU9aVnRhUEZOL1JaVURUQXQyUGdoUDJSN3ZNWVRUOW9K?= =?utf-8?B?bDVpaUdoM2ZtUXo1MmpFMVNIcHQ1WjRlQ0FVWDdpRkt6TERvZGhxMjdiU1Nl?= =?utf-8?B?YVoxUHJRWnZhY3c2S2YzVUZyQlNoV3pIK3BxTWJSS3hQRlRSb2VGVTNlMEtC?= =?utf-8?B?Z3lQOVdjQU9jTzZ1MWY0M1RWS0NOeVBGenJ2WnRVdWt4RFBpcFVGczRWa1B6?= =?utf-8?B?MzBCcStCOTROeFUzZHVxaFBUQmx3eW1saGxoUU9EVnlVMXVKY2Rqb3lEelFG?= =?utf-8?B?R0l5NkpJNmh0U25xL0IzTlZWL1Z6bzZaOU8vN0dEMmEwMDRkMFBNZk5OeTVS?= =?utf-8?B?NWVZb0d2T0RZRHltbVFETXVrcDU2aHRLNHJ2ZGtBd2NWczQreCtCb1gyVnoz?= =?utf-8?B?OFVIdlhUcnlMRVkvRVpxdEdhL1V6elFsU3N1dEVXREZYazBud2NEMGlna2Rr?= =?utf-8?B?QU0zNzdacWtiVGhURkJnRTZNS2IxMEpuM1MwMzNkNWdvRGw0NHE4U2lPN1U5?= =?utf-8?B?M1VRMitXcElBRWpJaTd6UXQ2UEgyeDV3azIxa2R2bjluTm1aREFHeXhEcHNX?= =?utf-8?B?S0ZlTXNMazNsMnR4R0lZaHhxUml2dWk5Uy83SnFrSXAvUDdidmZnTStML1RS?= =?utf-8?B?c2YzYzVBQnFVY0RWdk5oYWJqcDFhY1VxZWdTVml4UHl1eEk4Uk1WTk5QaGhj?= =?utf-8?B?RXJrUmJ3Q21HcGlmWHVoMi9lb3BLRWY4U3pwTzZlMkwrb1lMaVF1RGRBNnhm?= =?utf-8?B?aTU3QkVUemRIK0x0SWlpOGNNczhBVVcvbTFhZjhVSmxRN25YVDRST3NCRjFz?= =?utf-8?B?YmkxRFRrYmE3RVcrcm1aVGt2THh1QS9ZL3Rkbld5NXF5c2FhdTJyZkRTNmhR?= =?utf-8?B?NHM5emU4YW5oYmsxUFdIWVFDTk9qbXpvSW9HaEJGQ1R5ajJxUzhLenJPTEt6?= =?utf-8?B?S1k1RnhJNWh4WDhhU2haTVg5N3JDZXBsRVo3eFJvOHZRd09zekdUbHhSN3V1?= =?utf-8?B?U1A4NituWmpKNHJOcG9QaGNtUzRnaWhJVGU2bVBReDNFczZUSWR6eDFuS3FW?= =?utf-8?B?S0g1SmM5bWJTY01DMzdLUnBaSVlDVzA4alovQlVGci9UZ1VPRjZLZnUzRm5N?= =?utf-8?B?U1lvaWM0QU0wM3BLUXRUd2lRUVd0Y0NPVUl4Zm9hcEh6aFpOMkhjcXdGdWtB?= =?utf-8?B?d0JQdHp5dlBZT1RCU214azhpczNvY29SelZNdWtYUURqdVJYWG40NG1FOFEz?= =?utf-8?B?MHo3ZUd0UUt6K0hUTU50T2VrV09SbnorTGo5V2FwRlNuVTBUeUJJUURnNk85?= =?utf-8?B?RW5VMTd6WkRhU3U0dzZQSjhJRDUvL0hOQkV3NEVVbS82VllhVVQ2a2s3dHU4?= =?utf-8?B?SXIrcURDSEhrYm1rdWRyOS96Z1ZiMy9kYTZtMmxhMUhaWjhQTzhIMll3NVJ2?= =?utf-8?B?UDg2SlF2WFlJQXd0dmVrc0hSRzkrdTNqZ3BzTnJONElSa0hUWnh5SmdNMnhi?= =?utf-8?B?emN0cVdGNmZqZkpXaDhubDh4K3QrSGQ0aTZ6dFdFNFEydEFzZ3BUMVRjdzY3?= =?utf-8?B?ZzFlcWpxbkR6NnhtWC9ObzNqaTJKditzK1h6Mk1mc1dXWlVqVjVEdHBvckdV?= =?utf-8?B?eUk2WUxmS1A5azBDa2RpZ3VKZGxsQ1R5Y0F5OVF4UUppRnIrczA1K1FwWHYz?= =?utf-8?B?UFRxRjBhNHZEdFVzc0VQUXlNc0tTdXEyOFVTTWpRdTM0OE1RL3NqWldmRzJz?= =?utf-8?B?Zk55QS9Qem9xU3UwNUtabm1Ud09xbkttZVJZUzBGU3JtOGVzZDF0ek1kbXZ1?= =?utf-8?B?czY5TGUySnF5K0dNSHR2VFYvS2tTNWJNSG9QenhBaWVTeEFhN2VSQis1MU9s?= =?utf-8?B?d3VDd0srR2U3cEF2RmFaWHpvem5LbTJWQnBZMFhyYXY0TkFaTXQxN0JadG1B?= =?utf-8?B?VnMxa1loUlViN2pSeVlSZThxdSs5WDJPSzRpVUZURFBleXJuR0FSSTB5d3JI?= =?utf-8?B?ZmZhSmw5Q1h6SUZxWEs4dHJYWnpTYUkvbmNwSlFNaHMwdXdka2VmM0p2NFUv?= =?utf-8?B?eHRDa3ZWRVZVUllTWWJZNnUrcUV3PT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(82310400026)(36860700013)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2026 10:08:14.4047 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e7704686-c1d6-45bf-d922-08de5cc2d1b4 X-MS-Exchange-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: MWH0EPF000989E6.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB9103 On 14/01/2026 12:33, Jan Beulich wrote: > Discussion of a RISC-V change revealed that for PPC and RISC-V we don't > really set any default, but rather rely on internals of kconfig picking > the lowest of the permitted values in such a case. Let's make this > explicit, requiring architectures that mean to permit SMP by default to > explicitly record some sensible value here. > > Leverage the adjustment to the "1" case to simplify all subsequent ones. > > Signed-off-by: Jan Beulich Reviewed-by: Michal Orzel with one question... > --- > For not-yet-SMP-capable ports we might go even further and use > > range 1 1 if !X86 && (!ARM || MPU) > > at the top. Thoughts? (I've not done this right away as it is liable to > get unwieldy when we have a larger number of SMP-capable ports.) > > --- a/xen/arch/Kconfig > +++ b/xen/arch/Kconfig > @@ -9,11 +9,11 @@ config NR_CPUS > range 1 1 if ARM && MPU Why not simply && MPU given that MPU is an ARM specific option in our Kconfig. ~Michal > range 1 16383 > default "256" if X86 > - default "1" if ARM && MPU > - default "8" if ARM && RCAR3 > - default "4" if ARM && QEMU > - default "4" if ARM && MPSOC > - default "128" if ARM > + default "1" if !ARM || MPU > + default "8" if RCAR3 > + default "4" if QEMU > + default "4" if MPSOC > + default "128" > help > Controls the build-time size of various arrays and bitmaps > associated with multiple-cpu management. It is the upper bound of From xen-devel-bounces@lists.xenproject.org Mon Jan 26 10:09:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 10:09:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213476.1523944 (Exim 4.92) (envelope-from ) id 1vkJXb-0008Jg-4O; Mon, 26 Jan 2026 10:09:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213476.1523944; Mon, 26 Jan 2026 10: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 1vkJXb-0008JW-1S; Mon, 26 Jan 2026 10:09:51 +0000 Received: by outflank-mailman (input) for mailman id 1213476; Mon, 26 Jan 2026 10:09: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 1vkJXa-0008JQ-6H for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 10:09:50 +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 24ff8a24-fa9f-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 11:09:47 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-47ee0291921so36328665e9.3 for ; Mon, 26 Jan 2026 02:09:47 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1e7156dsm29809206f8f.20.2026.01.26.02.09.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 02:09:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 24ff8a24-fa9f-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769422187; x=1770026987; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=+tMxil3n/dDtqPLPd/LZ4u8X3d1Gfks7WP6WFRww7js=; b=RuDJAyuZJBiWRppFVhuRiy18kcw4jCeQvz5InSHhdlHh+XOKhza7NnZ3rm5jEOnEhE 0t+fJu1v4/oiFAIK1UKgmGCxWKUqDP4b4+F65IrYg1yP2y4CB8TtT2C4FYm3sLP1hSPh lhBtLI3LDjCL11f0R/auDQBMnTODFwFn9BVRYQjqGmiOnc1+zI7CJqc7pnwEbMTESL0c yFG48QTCeyqLPxj16Y2GWKoj/0m6CdfknPN29/kORxqMPEbvo4Qw02vk0H9zgivwsFZ6 1rPNErhdYc+qqo9ZrVM+Lxm+DajWfiZ1D5kojueF5DhNNPAabpJxTmOCKDCukZEjpIkY CzOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769422187; x=1770026987; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+tMxil3n/dDtqPLPd/LZ4u8X3d1Gfks7WP6WFRww7js=; b=ZA4us6rSdUeQe5XBY4lsK8LPtdjf4ZbrFP8hV1wKjFxBUrBi1dAGESewypfinDn2v5 1UBuhre8jJL2UgDRHYKohgQ4NT4Bdk0w0lfIHmGn8a07IDCJPouf8RjJbTsNA42+lXLH UIx+6olMEZMj+JStY9Mzw6EeQCg8sraCLZrz+/lTj8Yw7ss11OQ49jf/ggd3l+h4SfgV 9bMdU7jgDvu3y+cIZK5wE2/ynEu5waSv6vrSPn0JL3zOeF3y4XC0yiIHOWVhv7gofIYf gdlijjl4gVPVygRBBjUy3IZMcIxUKUPGdoPR+rinoH1ApY2HihK+adk+trX2C1gIb8b5 ghFA== X-Forwarded-Encrypted: i=1; AJvYcCUWkWnLZFY1vrKOiMu6S9I8/uey6QBvXZF2BNRuU7be/vmpoDhO7BLAOY5D9x0foiKBxrSerQyxN1k=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx8Wn2RNh30o5ZGmK6kLlwDva5VPRx1LOCrZmSX9s/4CnCOEImg ohV0ZhVL1l2bE5k0gzgGt/Oi2OnHJCwcbirbxx1rUp1SICpWzS2mflz20oBxaDX38g== X-Gm-Gg: AZuq6aK0jjs1I/vT3heS0nW2mH2GwWweb9ZBHjtJ4hKDnaCyrz2Q1wm52rrrMvlCZbU pB4j1uAaOKth61gR+8dtUqw42fighpzlUYcP/N1U+vEcAKf8JjRdSLamyIJ6aGmORsYXN3puWHd 0HvFFGfevmcR8XBhg4C1gtyiH7Z9M0uxrzQlxvQ8ZgtwnioWL4ziDb+g8W3Fleh9bfNpKNz9wrJ Ypoo/x6rGUGWC0D3xTwm0x6cRo6UJUgf6fwHOQFJdcPv5c29yY2wUaQK/OaoRpfAWJbZK90CSFR Hp1NdeAxBV2SdVeSo/PCI0CmPo+hLzOREfuW/TJYiyfnDgEj8HKZc7WeDHigcZup7MlYkx/rQS/ jGZIe7+cAiRGqnmxmoEKPmy81qY3lcjMI3qiPZzjjPETRjE/EqucxZIsp2Bcw1zjE5/tLnkEpQL P1BU3UHNyhRzXyl2rvVe+XMSB6daxAsRQM2AlLshcGdsGJIggfCPzAuZNsXel9 X-Received: by 2002:a05:600c:4f4b:b0:47e:e78a:c834 with SMTP id 5b1f17b1804b1-4805d06685fmr68581695e9.34.1769422186771; Mon, 26 Jan 2026 02:09:46 -0800 (PST) Message-ID: <9a68c272-1c76-4f1f-89ff-ff86d5181bcc@suse.com> Date: Mon, 26 Jan 2026 11:09:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] xen/riscv: dump GPRs and CSRs on unexpected traps To: Oleksii Kurochko Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <0b57db49d40b336429dd4fd63faf18f6bb17ac1a.1769179393.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: <0b57db49d40b336429dd4fd63faf18f6bb17ac1a.1769179393.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.01.2026 09:38, Oleksii Kurochko wrote: > --- a/xen/arch/riscv/traps.c > +++ b/xen/arch/riscv/traps.c > @@ -99,12 +99,81 @@ static const char *decode_cause(unsigned long cause) > return decode_trap_cause(cause); > } > > +static void dump_general_regs(const struct cpu_user_regs *regs) > +{ > +#define GPR_LIST \ > + X(regs, ra, " ") X(regs, sp, "\n") \ > + X(regs, gp, " ") X(regs, tp, "\n") \ > + X(regs, t0, " ") X(regs, t1, "\n") \ > + X(regs, t2, " ") X(regs, s0, "\n") \ > + X(regs, s1, " ") X(regs, a0, "\n") \ > + X(regs, a1, " ") X(regs, a2, "\n") \ > + X(regs, a3, " ") X(regs, a4, "\n") \ > + X(regs, a5, " ") X(regs, a6, "\n") \ > + X(regs, a7, " ") X(regs, s2, "\n") \ > + X(regs, s3, " ") X(regs, s4, "\n") \ > + X(regs, s5, " ") X(regs, s6, "\n") \ > + X(regs, s7, " ") X(regs, s8, "\n") \ > + X(regs, s9, " ") X(regs, s10, "\n") \ > + X(regs, s11, " ") X(regs, t3, "\n") \ > + X(regs, t4, " ") X(regs, t4, "\n") > + > +#define X(regs, name, delim) \ > + printk("\t %-4s: %016lx" delim, #name, (regs)->name); No semicolon here please; that should be supplied at the use sites of such a macro. As to the format string: If past the leading tab you want an extra padding blank, why not "\t%-5s ..."? Question however is why this deep indentation is wanted in the first place. I'd suggest to omit the tab in particular. > + GPR_LIST What use is this macro? All it does is hamper readability, by requiring the line-continuation backslashes in its definition. > +#undef X > +#undef GPR_LIST > +} > + > +static void dump_csrs(unsigned long cause) > +{ > +#define CSR_LIST \ > + X(stvec, CSR_STVEC, " ") X(vstvec, CSR_VSTVEC, "\n") \ > + X(sepc, CSR_SEPC, " ") X(vsepc, CSR_VSEPC, "\n") \ > + X(stval, CSR_STVAL, " ") X(vstval, CSR_VSTVAL, "\n") \ > + X(status, CSR_SSTATUS, " ") X(vsstatus, CSR_VSSTATUS, "\n") \ > + X(satp, CSR_SATP, "\n") \ > + X(scause, CSR_SCAUSE, " [%s]\n", \ > + decode_cause(v)) \ > + X(vscause, CSR_VSCAUSE, " [%s]\n\n", \ > + decode_cause(v)) \ Anything that can help save space (as indicated, output may go to a limited size screen) should imo be leveraged. IOW better no double newline here, nor ... > + X(hstatus, CSR_HSTATUS, " [%s%s%s%s%s%s ]\n", \ > + (v & HSTATUS_VTSR) ? " VTSR" : "", \ > + (v & HSTATUS_VTVM) ? " VTVM" : "", \ > + (v & HSTATUS_HU) ? " HU" : "", \ > + (v & HSTATUS_SPVP) ? " SPVP" : "", \ > + (v & HSTATUS_SPV) ? " SPV" : "", \ > + (v & HSTATUS_GVA) ? " GVA" : "") \ > + X(hgatp, CSR_HGATP, "\n") \ > + X(htval, CSR_HTVAL, "\n") \ > + X(htinst, CSR_HTINST, "\n") \ > + X(hedeleg, CSR_HEDELEG, "\n") \ > + X(hideleg, CSR_HIDELEG, "\n") \ > + X(hstateen0, CSR_HSTATEEN0, "\n\n") ... here. In this latter case it's questionable anyway, as apparently you have this here to separate from the GPRs being logged subsequently. Just that right here you don't know whether your caller actually means to do so. As to grouping: How about further putting hedeleg and hideleg on a single line? Maybe also htval and htinst? > +#define X(name, csr, fmt, ...) \ > +do { \ > + unsigned long v = csr_read(csr); \ > + printk("\t %-10s: %016lx" fmt, #name, v, ##__VA_ARGS__); \ > +} while (0); > + > + CSR_LIST Same remarks here as above. The issue is actually worse here, as CSR_LIST uses "v" which it isn't passed. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 26 10:13:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 10:13:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213489.1523953 (Exim 4.92) (envelope-from ) id 1vkJat-0001Se-M1; Mon, 26 Jan 2026 10:13:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213489.1523953; Mon, 26 Jan 2026 10: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 1vkJat-0001SX-JC; Mon, 26 Jan 2026 10:13:15 +0000 Received: by outflank-mailman (input) for mailman id 1213489; Mon, 26 Jan 2026 10: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 1vkJas-0001SR-G5 for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 10:13:14 +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 9ee917e3-fa9f-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 11:13:12 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-432d2c7a8b9so4254071f8f.2 for ; Mon, 26 Jan 2026 02:13:12 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1b6e2besm29035708f8f.0.2026.01.26.02.13.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 02:13:11 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9ee917e3-fa9f-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769422392; x=1770027192; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=b1BNmOoJ0FqwRiXxPXX1bFXKY/+NzSSE+35Bm6yGsoQ=; b=S3GmZ/Xj7i6X5P/jJVq+DL8xkUOd4dELsVTadyn6bckwnVMCcqi0QHqdZ8xMkwJXTK 1BqwRAVoby9EF9mvleff6dqZ8QhK0W/sijHVHMUvf2NIkyZJcDYzLtdR3IuTTqMQEKsH wyUK9qDQJDSeefJR5iLyTdv6k7VGToxYbG+7SsTQDZ7qiHtVEr75wSIE9B4v6zxXlHOb P8WPVBOE57jqSM7no6oslzXuNvyyKU0DER/CqTopAa3NHFl4twkbD5f2wzjSfMOyNdVx uXXYcefaW9sooTSMJtouDX0ZwRPt4bINrzVh9YuefNd1YxlZU40GjTG5eKNnjntoBXQy 12EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769422392; x=1770027192; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=b1BNmOoJ0FqwRiXxPXX1bFXKY/+NzSSE+35Bm6yGsoQ=; b=BqcSEmwqxGATDUsZEvr+biSXWkr/w9tIQuuG3lSBv7J3bDdSBMe4DDvQq+/cvnZ+BE 6SMDD1EOvcZhRnrdSrv9eft5Iwx0aGAC2t/sHVG5HxCM3TTqy1V1/VwOECJiHD4ZSmQj NojKTsh/K81YIMqcB12AI8DydQK379RZM4UvU7uadMBgEydS3DJAyQagYrQ6mA/MUKvK nJTzhXR+OOPNwqfUqhKlQxNx8MdUFrxGt3elRGi/H2Cmul2wbrvb+psSUPPVXDQIFW6E qYfh6KgOxRem9wAlLVSnXa7FQs+V1B2Gbh0lng3UodkxXFrZEMzRi5ln7M8pAO3Jz98W CFnA== X-Forwarded-Encrypted: i=1; AJvYcCU+R0ULplTWCXrFG6W2dNLiVEnqlu+6DpMaCy2s9gbZUmslWJFYTEtja3fcSa+fIl2bWOvCAFFLuWo=@lists.xenproject.org X-Gm-Message-State: AOJu0YxEZ0blgrYMWq6hZD9iyepqLrPd2/Wx7THI2LO6SN9KJ8lLfKqG QGWRHUHYRR9P9toV5NLudYOpc5Jp0sgquh6bTgV1gnP6G18ILifOtJaeHR36qD6frw== X-Gm-Gg: AZuq6aJjF7fvIOpoY7P33CRK5JfvaXawiojDKOCDJYumYI+7PncvhMq0F+3KW/Dtde0 AGV/eoeLRM8hms5JC4lJ31ck5U1f68RpN7TOBDTLcPgZdnY47bqN7hwlwvgcz1CX6XI2o7vXBkk ylR4RDvgZyJKWlpGMc68ubozmo8iIvJwjxnqgUPnKNeVxPKGjKkeF2iCYLyD2sLAiyt/2x8gk8W +Yk7gGAPVrX11ZAGRpvLL/db+xyyWYJ2f3s+OKAxXQWyysECHhXVEUgmGTR07svytgQ8naT54FM KnfCPWRrlwxVUSlfAjMyzINKRDiXP0XOCXy5OfSaWBlrbGdZ3SSzQGUF7SY9ae923iAXEyLyKQ8 o+6mwd5ejLJuhg2+jyiG/XKG0hJjxMRqYho99kQK6f5Y3hID1YxwQS1xXii3xGKtR9VdHTUPZgp 09Uy73iw5ciD5PMIj7ciChLxBEXVqFbq20kMVzMZtCjq7H4N/Ay+DrAMKcLrLcRsB8CGlgnYDXp 3Q= X-Received: by 2002:a05:6000:4008:b0:430:f5ed:83e3 with SMTP id ffacd0b85a97d-435ca123e42mr5980091f8f.6.1769422391594; Mon, 26 Jan 2026 02:13:11 -0800 (PST) Message-ID: <6f4901b7-3121-4dce-bdeb-da3644e719c3@suse.com> Date: Mon, 26 Jan 2026 11:13:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] kconfig: adjust NR_CPUS defaults To: "Orzel, Michal" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Oleksii Kurochko , "xen-devel@lists.xenproject.org" References: <1caed635-3d9b-47ed-b8fb-d6c391293059@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.01.2026 11:08, Orzel, Michal wrote: > On 14/01/2026 12:33, Jan Beulich wrote: >> Discussion of a RISC-V change revealed that for PPC and RISC-V we don't >> really set any default, but rather rely on internals of kconfig picking >> the lowest of the permitted values in such a case. Let's make this >> explicit, requiring architectures that mean to permit SMP by default to >> explicitly record some sensible value here. >> >> Leverage the adjustment to the "1" case to simplify all subsequent ones. >> >> Signed-off-by: Jan Beulich > Reviewed-by: Michal Orzel Thanks. > with one question... > >> --- >> For not-yet-SMP-capable ports we might go even further and use >> >> range 1 1 if !X86 && (!ARM || MPU) >> >> at the top. Thoughts? (I've not done this right away as it is liable to >> get unwieldy when we have a larger number of SMP-capable ports.) >> >> --- a/xen/arch/Kconfig >> +++ b/xen/arch/Kconfig >> @@ -9,11 +9,11 @@ config NR_CPUS >> range 1 1 if ARM && MPU > Why not simply && MPU given that MPU is an ARM specific option in our Kconfig. Good question, to be answered by whoever put this here. I guess the anticipation may have been that "MPU" might end up meaning something else on another arch, at some future point? Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 26 10:20:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 10:20:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213499.1523964 (Exim 4.92) (envelope-from ) id 1vkJi8-0003B1-Bb; Mon, 26 Jan 2026 10:20:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213499.1523964; Mon, 26 Jan 2026 10:20:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkJi8-0003Au-85; Mon, 26 Jan 2026 10:20:44 +0000 Received: by outflank-mailman (input) for mailman id 1213499; Mon, 26 Jan 2026 10:20:42 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkJi6-0003Ak-PG for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 10:20:42 +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 a9e9a0a1-faa0-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 11:20:40 +0100 (CET) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-b87f00ec06aso693736166b.1 for ; Mon, 26 Jan 2026 02:20:40 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b885b416ca5sm620546266b.25.2026.01.26.02.20.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 02:20:38 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a9e9a0a1-faa0-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769422840; x=1770027640; 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=R4DBoWlEruMs2pDNEz2OByAFQSF3ZJwQPnGJRCR4IRY=; b=PZUN3tuKE+YjHFASwXMa78FK53F6jKbKH/ilrWlWFwbwv5uxw4zJRqBZIfnudt5ymN MFZpngWMNxlCXijkiXg0zr4YAFUwXs9c7JrWCQcSpj7ylhm/zRzPXuLLla3fvUlEqhzd EztYGAF5gnWh45mkp+v4TMz3vJaE1Wk9tMSB3D8Ae6it8SR9xMHAQMxq/mI3zFUQ4JMs 1IQAIMF1qof9O0BN9cMyfY/VYjnvlcWvdENM37f9UwiDsGNnhKO0dFxjRtnXrFqHlO3f w0QfP2EVk+KjReYoJo5dPaY6jL43zBA52hq6fqs+ImgKAvsevDdhQxxtL6adSif+7WPi QfnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769422840; x=1770027640; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=R4DBoWlEruMs2pDNEz2OByAFQSF3ZJwQPnGJRCR4IRY=; b=IWxfeBD+ib5owNtsKnWnyw1WNHkQ061bZ6Il7oSTnO/lxyiMOQcNxOVDw/1ww7Tpm2 5WChLzUmz3153HtZy7tk2D69XyXvOGQ3vWiHt/qtaRqO4Tu+V3gA3ZKC8omcOGKBo4p/ Ym1mhqeu35ftOPlLL1BVK0BLiCUr0dLVtWS2U/QVzn1rEXB8c8vc37a/z6ftoppzGo9b vBgo7uTZEJG3GAcvRvgKs62bz1J7rrJJvdVqitAsyMKR3G2xId+7ZuyUhJpqWucxrUlw BK4+B1szDJvTzb1TgEpv0H+DC4K4qZS2n58SrYrPuGC7Bzctudvcl0A5vzQrKq7tagiI JX+Q== X-Forwarded-Encrypted: i=1; AJvYcCUYL1o4UiQzNRXoyQf/aWIQXTZcvpl+7l3OxbsOVOoqmxPddbHTjtH3DfPia0AnSl6VVGhyWV7lX34=@lists.xenproject.org X-Gm-Message-State: AOJu0YwioUcQJ7rysTPrxVzDTzMpJcSRUtexO4WAb0g+hOl/8cm+UmA/ d6A9JRbj37mhDsE9ULcwbTz/byjA2aoXrhvXl/OK7fpc2py13dqtYa+f X-Gm-Gg: AZuq6aIf37dTmAxzL0hYoLIChelG/B+KeHH5Vg5rygYNYw3cqOzEkKi/w8X4s9zsj4m h1fa4vFnzKpzIZEwh2Gy+ZPjYi0JlTQQu991hnvNPfU0Wu6HU+1822G1pcGEuuUpb+vMRJeg615 0SgLtktTR46UMZjaZEYPVf39+Vayb4nX0tsHK+vwZjGZ0YBR20ztFsm7JoWDbQMGaoOkSrw9sQJ uRe9O+qic/JQu9LQ6dfGpF5unBh9cogInrcHvXwd0fL26YNNbBFDSxAfB4cZXrMLEXrfL4dW6De 3SlOf3HtHgXskNX3lm55HX6Xjl9+/D9klT4yYmI8aOo8PfrYPAwFX53YNUDW01m55tiZ6gbucJf yRTwelpE2zKgSfTH/0rzkBFGScCIjzCvzWFfRT7uDCbsJrvh2WlGkJUBsVf5KgGkyrcrJuM8u1/ sX5XKE++I82b6pp2kjKxqCw7/U+o9VI3a6ORroygdTfkAz7k6kayj8vcAdV+VpXRo= X-Received: by 2002:a17:907:3e8d:b0:b87:fad:442f with SMTP id a640c23a62f3a-b8d2e85c9dcmr277672966b.42.1769422839236; Mon, 26 Jan 2026 02:20:39 -0800 (PST) Message-ID: <287efafc-b76c-456b-b22c-b4c3ed70e12f@gmail.com> Date: Mon, 26 Jan 2026 11:20:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 13/16] xen/riscv: implement reprogram_timer() via SBI To: Teddy Astie , xen-devel@lists.xenproject.org Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey References: <732635f43fb80daec332f78d4442b56bf5dfda98.1769099885.git.oleksii.kurochko@gmail.com> <1222e3c6-44c1-434b-974e-04851874c1ca@vates.tech> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <1222e3c6-44c1-434b-974e-04851874c1ca@vates.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/25/26 12:13 AM, Teddy Astie wrote: > Le 22/01/2026 à 17:49, Oleksii Kurochko a écrit : >> Implement reprogram_timer() on RISC-V using the standard SBI timer call. >> >> The privileged architecture only defines machine-mode timer interrupts >> (using mtime/mtimecmp). Therefore, timer services for S/HS/VS mode must >> be provided by M-mode via SBI calls. SSTC (Supervisor-mode Timer Control) >> is optional and is not supported on the boards available to me, so the >> only viable approach today is to program the timer through SBI. >> >> reprogram_timer() enables/disables the supervisor timer interrupt and >> programs the next timer deadline using sbi_set_timer(). If the SBI call >> fails, the code panics, because sbi_set_timer() is expected to return >> either 0 or -ENOSUPP (this has been stable from early OpenSBI versions to >> the latest ones). The SBI spec does not define a standard negative error >> code for this call, and without SSTC there is no alternative method to >> program the timer, so the SBI timer call must be available. >> >> reprogram_timer() currently returns int for compatibility with the >> existing prototype. While it might be cleaner to return bool, keeping the >> existing signature avoids premature changes in case sbi_set_timer() ever >> needs to return other values (based on which we could try to avoid >> panic-ing) in the future. >> >> Signed-off-by: Oleksii Kurochko >> --- >> Changes in v2: >> - Add TODO comment above sbi_set_timer() call. >> - Update the commit message. >> --- >> xen/arch/riscv/stubs.c | 5 ----- >> xen/arch/riscv/time.c | 43 ++++++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 43 insertions(+), 5 deletions(-) >> >> diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c >> index 1f0add97b361..cb7546558b8e 100644 >> --- a/xen/arch/riscv/stubs.c >> +++ b/xen/arch/riscv/stubs.c >> @@ -21,11 +21,6 @@ nodemask_t __read_mostly node_online_map = { { [0] = 1UL } }; >> >> /* time.c */ >> >> -int reprogram_timer(s_time_t timeout) >> -{ >> - BUG_ON("unimplemented"); >> -} >> - >> void send_timer_event(struct vcpu *v) >> { >> BUG_ON("unimplemented"); >> diff --git a/xen/arch/riscv/time.c b/xen/arch/riscv/time.c >> index 2c7af0a5d63b..f021ceab8ec4 100644 >> --- a/xen/arch/riscv/time.c >> +++ b/xen/arch/riscv/time.c >> @@ -7,6 +7,9 @@ >> #include >> #include >> >> +#include >> +#include >> + >> unsigned long __ro_after_init cpu_khz; /* CPU clock frequency in kHz. */ >> uint64_t __ro_after_init boot_clock_cycles; >> >> @@ -40,6 +43,46 @@ static void __init preinit_dt_xen_time(void) >> cpu_khz = rate / 1000; >> } >> >> +int reprogram_timer(s_time_t timeout) >> +{ >> + uint64_t deadline, now; >> + int rc; >> + >> + if ( timeout == 0 ) >> + { >> + /* Disable timers */ >> + csr_clear(CSR_SIE, BIT(IRQ_S_TIMER, UL)); >> + >> + return 1; >> + } > Do disabling the timers interrupt actually stops the timer or just > prevents Xen from receiving the timer interrupt ? According to OpenSBI spec: If the supervisor wishes to clear the timer interrupt without scheduling the next timer event, it can either request a timer interrupt infinitely far into the future (i.e., (uint64_t)-1), or it can instead mask the timer interrupt by clearing sie.STIE CSR bit. It seems like it never stops it even if to use OpenSBI call with -1 arguemnt. > > If it doesn't "stop the timer", we probably would want to swap "enabling > the timer interrupt" and "setting the timer through SBI" (to avoid > potentially receiving a timer interrupt between these 2 operations). > > Though, it's unclear in SBI specification if the sbi_set_timer touches > the timer interrupt masking or not (at least it does if you set a timer > too far in the future). Considering how it is implemented: void sbi_timer_event_start(u64 next_event) { ...     } else if (timer_dev && timer_dev->timer_event_start) {         timer_dev->timer_event_start(next_event);         csr_clear(CSR_MIP, MIP_STIP);     }     csr_set(CSR_MIE, MIP_MTIP); } It will clear timer pending bit even it was set before. So move this: + /* Enable timer */ + csr_set(CSR_SIE, BIT(IRQ_S_TIMER, UL)); after sbi_set_timer() should work. As an option we could just use sbi_set_timer(UINT64_MAX) instead of " csr_clear(CSR_SIE, BIT(IRQ_S_TIMER, UL));" to "stop" a timer. But first one option looks better for me. ~ Oleksii > >> + >> + deadline = ns_to_ticks(timeout) + boot_clock_cycles; >> + now = get_cycles(); >> + if ( deadline <= now ) >> + return 0; >> + >> + /* Enable timer */ >> + csr_set(CSR_SIE, BIT(IRQ_S_TIMER, UL)); >> + >> + /* >> + * TODO: When the SSTC extension is supported, it would be preferable to >> + * use the supervisor timer registers directly here for better >> + * performance, since an SBI call and context switch would no longer >> + * be required. >> + * >> + * This would also reduce reliance on a specific SBI implementation. >> + * For example, it is not ideal to panic() if sbi_set_timer() returns >> + * a non-zero value. Currently it can return 0 or -ENOSUPP, and >> + * without SSTC we still need an implementation because only the >> + * M-mode timer is available, and it can only be programmed in >> + * M-mode. >> + */ >> + if ( (rc = sbi_set_timer(deadline)) ) >> + panic("%s: timer wasn't set because: %d\n", __func__, rc); >> +> + return 1; >> +} >> + >> void __init preinit_xen_time(void) >> { >> if ( acpi_disabled ) > > > -- > Teddy Astie | Vates XCP-ng Developer > > XCP-ng & Xen Orchestra - Vates solutions > > web: https://vates.tech > > From xen-devel-bounces@lists.xenproject.org Mon Jan 26 10:24:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 10:24:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213508.1523974 (Exim 4.92) (envelope-from ) id 1vkJlG-0003iy-OQ; Mon, 26 Jan 2026 10:23:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213508.1523974; Mon, 26 Jan 2026 10: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 1vkJlG-0003ir-Kn; Mon, 26 Jan 2026 10:23:58 +0000 Received: by outflank-mailman (input) for mailman id 1213508; Mon, 26 Jan 2026 10: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 1vkJlF-0003il-BZ for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 10:23:57 +0000 Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [2a00:1450:4864:20::343]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1dfb5712-faa1-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 11:23:55 +0100 (CET) Received: by mail-wm1-x343.google.com with SMTP id 5b1f17b1804b1-4805ef35864so7146465e9.0 for ; Mon, 26 Jan 2026 02:23:55 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804d84ef51sm241617785e9.5.2026.01.26.02.23.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 02:23:54 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1dfb5712-faa1-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769423034; x=1770027834; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=nzT9ZRmEDSZvg1iOpRp9dAVEi69ZhoqPLIq6Na/jh1M=; b=HFQuDt1b7eWladdqiKJRyC55Dg4K0nrLLoW0m9olH3RqlvgDJJMiFaJ4TtoPEHANHo 05Kjr+hxd0hvgM+jLZ3nlIQE7zqdF5/m3M01KvIAtq+avs7eYrx7qxDeftm6mIRyhA8l 4dfenCvyR+F99ncTAgLfKW5Wqv4Ivn9vgmTHLOuHjg5STs3YOKV6RMA1Rg33rlxK7SSR Oe54ypVdWOgKtLaQ0SAzwkl+t0V5OCJfVaDDY27k4MJ5yw0z77wxz08RWtyBd2YpVTJW r8cyRjPrs0R3wBHHa7XogEgoO5a5EsGz0XmX5cq5lS+2BnbDDOTawxKY28OAOV9yENvT HWiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769423034; x=1770027834; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nzT9ZRmEDSZvg1iOpRp9dAVEi69ZhoqPLIq6Na/jh1M=; b=imJbGs3p8Bw4Fv1Y6Il+3qcf1bVNbkRvXcmW1AZNISa7nhPms8q5oQt0R6bEFPCKaW E6xY6oghUBHcRx1DVbR2wwqxGr+Rk0dxW0loab3Wiq5TrN3cq+umHAKK6cYKh7cyZtPL OT0NALwF7Jrre9cJd3l0gpnM6ye/JQqorLzl9O+8aHPvH6MyxfPXFOPGoReuzTeWuXno FkN6kLbKf0J7M0dwrLp3+Si33AWAhecFymUdqNLV5fgy8Aj/Weg6y2Gl6Y3xTHsOrYKn MLPNBDA6Dtz06Uz1QBBUSQAQDHdDl05BbFEtW7UlNnSYfeP73ODtEADnp8lbSjQZVD+C ZdEw== X-Gm-Message-State: AOJu0YwjQlXZ3yYbz2PQafSLg36NpoTyPZ8Z3nunuAU/bOAXd1JdBxFx VQMY4/y8tfdx6VvGCeD6Cd7RTWtEteahMt50wE0a22GgcZkZ02+0MwU2vZo2g7HQEA== X-Gm-Gg: AZuq6aJVqyk835XoxTWItyqFbcR4B/EUjDB3LTgbkyKI0DnOYgVncZwpwGUVqd0Vyit tBY1dW5q2LdCiw1EnxKMfFVTJMZ5KC1KcDWkp02CsCpjhm+ebDe8vKxIi4so336Z10PlLEAXWX0 q4s9iTwbHayv1jaG0XP7PDquI9RtXWHiblpYWq68gK4U4+kDY9UDCPohQjheREQUVGTCOaoGudT f9hFckIixMixutFGSg/+wdOywY66/CLAfcILPIpceyvHPzoQMlfSCvvkp7coc8V9O+x2BIx7sZ3 tFgUKyqPucteTBXaf5ZVtwqyGmE+z2U4TPKD2VV50Zt4aqL6+kNLVE0c15JP053UPW1JXvKDk8C 8Udo95wU+xLzpT5gkpUrC6e8lvsWysSe6qMrICb0giw9Y4pTmnmkGtW1C1tKQKlNbBuIUIIDW2G zaVXn60cnB5gULw1puiKPSwMpOQueYYoj8vS090KbXWRzqH8uPiRRx9pM3+BrK91wBOHtwtOmuF QGvrrfZYy9xhQ== X-Received: by 2002:a05:600c:a00f:b0:480:2521:4d92 with SMTP id 5b1f17b1804b1-4805cf6365bmr66239355e9.24.1769423034398; Mon, 26 Jan 2026 02:23:54 -0800 (PST) Message-ID: <07f73a20-ff40-4a76-aaf6-5a09774b1530@suse.com> Date: Mon, 26 Jan 2026 11:23:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] symbols: check table sizes don't change between linking passes 2 and 3 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: <7e550d03-13c3-4607-bfa5-1a4bd57ecef6@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 21.01.2026 18:38, Roger Pau Monné wrote: > On Tue, Dec 09, 2025 at 11:11:40AM +0100, Jan Beulich wrote: >> While sizes (and possibly positions) of the symbol table related symbols >> (and as a result other ones) are expected to change from linking pass 1 >> to pass 2, no such change should happen anymore from pass 2 to pass 3, or >> else the internally recorded symbol table wouldn't represent the ELF or >> PE/COFF ones. >> >> For comparing to be actually useful, i.e. most notably also covering the >> last of the arrays emitted, symbol sizes need establishing. Make use of >> the xen/linkage.h machinery to achieve that. >> >> Suggested-by: Roger Pau Monné >> Signed-off-by: Jan Beulich > > Acked-by: Roger Pau Monné Hmm, the Ubuntu builds (up to 20.04) still say no for xen.efi. One example: diff -u ./.xen.efi.1s.o.sym ./.xen.efi.2s.o.sym --- ./.xen.efi.1s.o.sym 2026-01-26 09:46:46.273317246 +0000 +++ ./.xen.efi.2s.o.sym 2026-01-26 09:46:46.276317175 +0000 @@ -7,13 +7,13 @@ 0000000000000000 l d .bss 0000000000000000 .bss 0000000000000000 l d .rodata 0000000000000000 .rodata 0000000000000000 l d .note.GNU-stack 0000000000000000 .note.GNU-stack -0000000000000000 g O .rodata 000000000000743c .hidden symbols_offsets -000000000000743c g O .rodata 0000000000000004 .hidden symbols_num_addrs -0000000000007440 g O .rodata 0000000000017f1e .hidden symbols_names -000000000001f360 g O .rodata 0000000000000078 .hidden symbols_markers -000000000001f3d8 g O .rodata 0000000000000443 .hidden symbols_token_table -000000000001f81c g O .rodata 0000000000000200 .hidden symbols_token_index -000000000001fa1c g O .rodata 0000000000000004 .hidden symbols_num_names -000000000001fa20 g O .rodata 000000000000e878 .hidden symbols_sorted_offsets +0000000000000000 g O .rodata 0000000000007438 .hidden symbols_offsets +0000000000007438 g O .rodata 0000000000000004 .hidden symbols_num_addrs +000000000000743c g O .rodata 0000000000017f13 .hidden symbols_names +000000000001f350 g O .rodata 0000000000000078 .hidden symbols_markers +000000000001f3c8 g O .rodata 0000000000000443 .hidden symbols_token_table +000000000001f80c g O .rodata 0000000000000200 .hidden symbols_token_index +000000000001fa0c g O .rodata 0000000000000004 .hidden symbols_num_names +000000000001fa10 g O .rodata 000000000000e870 .hidden symbols_sorted_offsets i.e. there looks to be a (proper) symbol disappearing in this case. Oh, wait - this is because "x86/EFI: correct symbol table generation with older GNU ld" still hasn't gone in (and can't without having an ack). Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 26 10:29:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 10:29:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213516.1523984 (Exim 4.92) (envelope-from ) id 1vkJqr-0004U1-AK; Mon, 26 Jan 2026 10:29:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213516.1523984; Mon, 26 Jan 2026 10: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 1vkJqr-0004Tu-7Y; Mon, 26 Jan 2026 10:29:45 +0000 Received: by outflank-mailman (input) for mailman id 1213516; Mon, 26 Jan 2026 10:29: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 1vkJqp-0004To-B2 for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 10:29:43 +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 ec28efb7-faa1-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 11:29:41 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by GV1PR03MB8454.eurprd03.prod.outlook.com (2603:10a6:150:59::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Mon, 26 Jan 2026 10:29:19 +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.9542.010; Mon, 26 Jan 2026 10:29: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: ec28efb7-faa1-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=slkPaQklSPR84VGBfJUoExRClUEea1iSlQCMXn76EgRIhE9gP3taSVJfUjHajM/+YmOPK6v62CnOJmuf9d98K3SA/d6nrwQYGE2vpQaR3cvEGkK7gdhPzJ5wOhuPGG1OrwAvJ/y0hTdlOdf9qawwIaLsHpct0cn3OIR1DIoN36eExhZSxsnYcnXRB1WYhXe31RUVh45W0ULzBe4nUAj7ME+YVmbPVNf4KeoqclnCDBOgqseXToa9naymu0GdyetrFEG7DXhpjmfBGIRm5VdIPU8rcwfUH/Tvu3ihAUAKJercMnJQu0SOquW1iI17MrDxp71ptRBkCQxAiYOUmNrXOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FOJQlmYftUpOLxBvJJzfYXA+AmoluQ/gJMUGEVHS6l4=; b=PUi+VrMAM8gYQEr2ljocQxM8G2/fzmfkdpySyHg17DDyTwusRUl6Ktd2orH1LOh2TewePKKqBzWxbv8ohUHPuQ03H51NoBNJkS2h07yuaohx7QbVSRP1o/sr88S51VKEvaIdGwxhfBRrio3fYGTAypPosUo6xlsbH1h1+i/59rw0093eRlFWrBEkPCDSAXiI35m/CmL1pJesG/3iM7BI+QdQKjMv7zpq5lhWOOsVmS4Z9WwbkjZg7dM7916GGhIqvFZiyB+ADJqgZNXVyhDo1x2K23KelIKEycdcOMMttlJmcKYAs++fOIfojMiZ3f2VKg8hpCcnKGjlLvfl3Sxrng== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FOJQlmYftUpOLxBvJJzfYXA+AmoluQ/gJMUGEVHS6l4=; b=uWkAlPddD0RkP0fa1Ge/E3VgiYt+LjdXvbWblK4dMSKas7DO/zs60qAZXy2fB2/Wsyb8KLUcrcEDziZCdiBu7/UZg+RU5IoPG0zMiGwulmZFImRb/R9dbcMpQ7vOmn6SmVGLznRFR2KYJ60Ig68Hpa/zgFYps9bgwk4g2KsxHAT8xsFFAAvFiaDl8jEVaYPrfyEJhRBJBwdrxeZA1wjHv/rkNKvRj9XBh8VsHu/mC627tDirQ8znsmCbA0BZ852Vs693GXGwUkALqK1XwpyoI7xi+MilcgrC4b6Z11PuBaUv43VNIe2w5ICBxfF2mOUjoCatPRfh6nfKGTtQ/UF59w== From: Oleksii Moisieiev To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v8 1/5] xen/domctl: chain SCI handling before IOMMU in assign_device domctl Thread-Topic: [PATCH v8 1/5] xen/domctl: chain SCI handling before IOMMU in assign_device domctl Thread-Index: AQHciwXk/uoXY0zPp0qUEySvGl6zVLVd0bMAgAZ1k4A= Date: Mon, 26 Jan 2026 10:29:18 +0000 Message-ID: <0df180b2-1e9b-4dfd-b2a9-cbe9b805d114@epam.com> References: <8482f823e945060d1a36469f14f94aa6251e3f71.1769020872.git.oleksii_moisieiev@epam.com> <114d2326-112b-41ea-8c32-12b785f8e7a0@suse.com> In-Reply-To: <114d2326-112b-41ea-8c32-12b785f8e7a0@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_|GV1PR03MB8454:EE_ x-ms-office365-filtering-correlation-id: 7ccee2f1-681e-44a7-2f50-08de5cc5c362 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?eHdPdk1jbWg2d2trZTlIaW5HSWU3WndpcTA5OGltbFh2d1JGT1N0Z3gvbTRn?= =?utf-8?B?Yk9wYXNSNGZyQml1d2ZvOE8vVTBvVVVPc0NVOURhcEJ3WmJBVnVGS1Urd0Zu?= =?utf-8?B?ZVQ1ZWJFakRGS0NOd1oxNmxIQ1B6WHgvWE1vSm51YWVLejlXckRGY1o4Q1dZ?= =?utf-8?B?bmhNUUZCQnJQZlgvQ0x4cktVRXRZcks2TytZOVdBNTUrdnkrd0RIeEMvT1Z6?= =?utf-8?B?NmRlU3JoNG1XOU1tSUgyZWJMSGJGcUx2MERaZGZ6amVrT000VGsrYjlQWGR0?= =?utf-8?B?WFJIZkovckNQemJPWWFFU1A3WHYrQ2F5bGZ3NkRMRDNkOGcxMXNDaEduSzdM?= =?utf-8?B?dkIyTDM1MC9zb0pnTmxNZ1dnaTh6R0c2TytaT1RXRncwZ0dZL01RK2JhdWdn?= =?utf-8?B?elJrd1JMaXNCL2piSXRvRXlQVVRtOFhaaDZBWjliYzhiMGRhZ2hJaTJ0Y2ll?= =?utf-8?B?S3hPSUVvRDUrbzJYL0U0M3hONHYxbkNseFVPRkxLaDJJM3UrWU1XMWdqbjZn?= =?utf-8?B?TU5EVU5iNWtGS2hRc0FrQ1NTWGNWS0toK1RFNndDeWlETlpzY0lVdVA2Tjd4?= =?utf-8?B?aldZQ0xVWHJlVWYvVTNhU0lqNUtuTkJQZ0YwYlRKU3NHK1ViRkg0VWtGVjRL?= =?utf-8?B?cDAzMzh5MEQwYnNFWXdKZmdnSmQ2TmErRWhlNkk4Z2NBa1FGOXJTb0JxS1RT?= =?utf-8?B?N04zTy8vK2ZKY1pSc050Syt6RHFzbldITHhmUnJ2Q1BibkFWazBuV2xTNHhL?= =?utf-8?B?cHFFakN2ODZIcXp1UCt5WnNqaVhOYURJKzhzMHNmbHlqQ0p4VDJjaFdSY0Jj?= =?utf-8?B?V043Q2xQZm83MjdjVmwwdnlSUFU2dXowaVNzUHJTcjA5ajhzNVFRK1QxZEVz?= =?utf-8?B?WWViY1NNemxaUElBa25LYUZHNVRTMVBhdmlKRlpUOUYvb3pLamhmdFY5SDY4?= =?utf-8?B?dG12eEZFZVE2OFNqRUJ2OU9XWHRRVUJqMVpaMTRKRzZYRHRPQVFVSC91UHdT?= =?utf-8?B?QjZmT1hmMWUwZUY1ZFplSWVsaDdOanpSOXkybFZMaGJRMmlUKzFRazd5M3dy?= =?utf-8?B?VEt1d011a2trNU5zZlV4RjZwOFJCcGI4ZEJUeUtvY1F4T01mSnpFbFA1UU1r?= =?utf-8?B?NEswc2pWbTRPWEc0MEtMYnhmZ3ZIZWZNRzlrR3RNM2NNVXNxNHY5dWx0OTAz?= =?utf-8?B?QjVDRUtJcUxXd21vakVsdkEvajRCNzAyNFc1RW9XdEhuUjFmZXl5RkFjNTZD?= =?utf-8?B?UERjc1dBK3k2ZWxsb1JXWjUxazdLdW5BNVJ3U2JET05iRTNhQjVmOHh1WWZ5?= =?utf-8?B?QWhCeEQ5WGFtTW9MWWZiV3FkNG9KcVNHOEYxYy9iTXdRNDZkSG1yaWQ1eHZz?= =?utf-8?B?bFp1UFhGdUgyUEIxdTBTdyswQmVpUGxSY2NRanVNTXdFU3pXRjJ0aGNEZ0RM?= =?utf-8?B?Nnc5WDNEVEp4QlVPUzB3dTEza1RCcm40MXdXOWxEbkhZUzkwS01KQ0ZYUnV0?= =?utf-8?B?VTQ4SWpYeHNTaDk4bGc1ekVJcGhqM3hoekkzek5scUlvYWdjU2Noc0JNVk16?= =?utf-8?B?eTZJWWFZTitVNjlUOEgxMEVpOXBjRlFFU09XTDNHeVVoRkk3L3JQa3VlcVZr?= =?utf-8?B?MDJsQkpiOTJ0MGp0ZExZZXAzMEVPMEswRGtXN3BzeVkxcVdwQkZ4aTFBMHNm?= =?utf-8?B?aVJiN1dZR2tIVDVUb2hsTmtaZ21Cc3ppN01pQ01GQjNmOFUzK3Zmcll3c29v?= =?utf-8?B?ejlEUjFwclRYc01pL3AxbDJFbytaUEllanBldmIvdTdFMVpub3FaVlVzeVVt?= =?utf-8?B?eUFiSWxpdUV5c2JONzh6YTIxNUlzUERGTStQOGtZdVFrTTBYZ2Erc09ZcjZM?= =?utf-8?B?WVFaelBBWVk0T2JuV1JKR2FnSnk5SlU4a2hlSWYwRW02Q1diQXdJSnpPeVhx?= =?utf-8?B?b3EzNXlkRzRBSGhubzFCOFZOb2k0MjExeEcySWZEb096dldvbVhwaWs4UnRu?= =?utf-8?B?NXZJYzlkQUdscmlUWjI4OWJJdUd2SnRLMHhnSlVqMGxGVlQwVUNTWmpMTWhm?= =?utf-8?B?cGlVZmJyTHVhYnNVd0IvTWNHTExjdlNQRzBmZURRelZjMmxCcFo0SS80cHpB?= =?utf-8?B?dXM2YTRIWkY3MWh6NkFmdlRnTFFZWVh6QTdmY3ZKZ1JteVRxanpSS3l0bUdI?= =?utf-8?Q?Oh5mctMgVGf0PvNbPqv2gFQ=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)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MTh3cE52aThicUJTeEFDVGFHY1ZYQThiMkswSWFyc3o2R2hLVDhxVUFidWJQ?= =?utf-8?B?aHZtWkVlY3dSSmJCcDFPR3lKQnlsWkNFT1NUVkxIMUlDNGdVeGZwMDF1Zjdk?= =?utf-8?B?RWE3ZUN0R04zdnJROVdKWjRhSlpUaWVoMDBTSThQQ1dzMDVWWVptSlVJNk50?= =?utf-8?B?Vng0ZTJPOFE5d3loU2h6QTJTTktYMW9ZSDdJa1NQVmNvQ3VEYitzQllRWmFM?= =?utf-8?B?WjFZb0EwT1dvdnp4bEJoaDRiVkpZQ3BOU1hQVE81b29ENytjRlFLRENxZTY1?= =?utf-8?B?T3NuYnlkOFZBWVZ4Z2w0MmNGWmIvRi9VaXg2d3ROWGpPcGR5UUF4QnRqelkr?= =?utf-8?B?TWpFdTZKQndzLzNnWCs3RStPcm9IVUN4K3VKSU9HbWRQeThWOW1ON21ucUhS?= =?utf-8?B?Y1lIRzhQZGVBbDdLV0xibWQxRVoxdENWc0oxS09FWklRM0I0MDdMMU9FMnZm?= =?utf-8?B?bWozbytiK1owcm80a1lYaGN4akZjeWlhbjQ1WWRCSjE0WTVEUFBlNnRjMWpk?= =?utf-8?B?cU81S2xSbHdMUEp2N3pyU3FCTnpQdjdXaFVNdEdlam5oZjNzQTVweCtCUUxS?= =?utf-8?B?VERvQWZXSVM5NzkzVFFzQzM5aHZyeXFtYXNHc3RmcjJkd2VEOUNZWVBvUVF4?= =?utf-8?B?cUZNdkVXVXl4UU5KSDFHOEE1V0RwWmg2bFVyaXNRMkd4QkFBZC9sRkhvOWpo?= =?utf-8?B?UXd1ald2ZSt6ZmNqVVZtckU0dUVJQ1VYbFpKc0UzMFFtT3RVK0lKd0FwSHZT?= =?utf-8?B?RTluNmcvYjJPa2pnNDk5VXAwNjA4bmN4d3ZTdm5YVzJ3cUdPdXQ0VWd6N25t?= =?utf-8?B?cUt3aThyOGZEdng0M2Nlbm5sTnVuL2V5T3g3SytsQ01weU50S0t1Z0ZaZTMx?= =?utf-8?B?OEthdVB3QWJYY1Z5NXBrSWZHSzFNcllnd1d5YW9jU0J5S1dmbnJiWWlPYVMy?= =?utf-8?B?SDB5dTBaczJaOThaQ2dKc2t0ZGtmNjEycWlMMzY5L1oyc1JHWGE5eE1Lb05Q?= =?utf-8?B?Skk1YWwyRHBTSkJBck5yY0QvRWhpcVdBdnovWEd0dUxacjlOdXIyMEtDNjBa?= =?utf-8?B?aFNNaGFWOVo1UXVaMC9SUDRydjhncEgyZkdCMExnZG5idHRUZXB1ZlNBNmF4?= =?utf-8?B?aUU0eG56dlhrTDFpWDJhZmpDMXN5UWVuL2dpTll2Y0dyTmJ1dG5pUzJqUHBn?= =?utf-8?B?V2RBMUZpNWIzaDV5aStGbDJ4cWhVN25Cb2xvc2hjSzhKYmwwcWJNWnhxZU9n?= =?utf-8?B?NFBJTFdmbmJ4NnIybmlQZmZucVlnbTZmdEpSS3FRN1ZLejB2S2xJQmErako2?= =?utf-8?B?eHhIWHRsSy9sNjJhZFhNU3J0ekFMem1lcGpiSFpxVmxLc0Y1NGEyK2poU0VD?= =?utf-8?B?ZHVHTE9RbGVPclB1NXFZVEUzRXMyMlhWZGZaOUV6NmhOdTJCTVRHS1h4a2li?= =?utf-8?B?L1I5NGFXKzhmZG9RMzNTeWYvaDZOL0FMRXRIbHFWV2dxT1FjeWhicmpNTXZh?= =?utf-8?B?dlJuTWwxLzNlSTkyQ0U3NzJUZXViTUc2N1dWaUJZVU9JOHJtM0dodVkrd0J4?= =?utf-8?B?bk1NaXd1eXFxTDJTd3kxVUc4OTkzUmRSVEJ4dHQzL3prVXZaVkJTcnh3bWIx?= =?utf-8?B?dk1aNjhueHBzUGNSeTJ0alR5dUdZMjArU3JrOGkzMmVac2dLakpJS0ZOODhm?= =?utf-8?B?RHo5QW4xVFFiNjR0b2Noby9xK04wUW1uOTlrRXN1ZWtCZ2U0OHJHaGIzbHp0?= =?utf-8?B?Q09xLzJBNjMyOHZNa1o1M3YybndKSjRGakhuY3RZbHNjVVlyQ1B0MndVTmNx?= =?utf-8?B?OW14OWxJMmpnSTA3QTJwOHJOY2JmR2JjcFdxNWswTUVBMG4zV3FTalpzeDFB?= =?utf-8?B?SGJiRkIvWExQZSt4VnhrWU5zSWJSdlpoeDVhdjdkSFlOQUE4cld2N1p1a1BZ?= =?utf-8?B?N2pTbHYrQU4vd0NVMTVYeDBoMkpoTVV4OFlXZjQxQXBKNE8vRFl6ODBkYkRs?= =?utf-8?B?cTNqenVHT3hQdjJJNHlGcnhySXVXSTdzWDY2QzNMY0VPRjcwSkNMUEg2eEdu?= =?utf-8?B?RzNUdjh5MXdrN2NzSVZXYWgxbGMzMHZRaHY1VjkybjJEUzdmdFByUHVYcXNK?= =?utf-8?B?TUV0R2pSWU8ySkxRRnQ5WDYwbFdHOGVMelNMN0pPNWxhc2haOVdqSHh0ZXF0?= =?utf-8?B?YkRHTTRnOXpIWXhvY0FmOWZ5eWVzMzBzSWVhd1VOSFNkSWZjaTlncTM2WG9V?= =?utf-8?B?YlJSQVdzS1pXSzZPQXcvejJxcUNzRHJxM2Z0VmxIZWRlSzdMTUdXb3dRQlFn?= =?utf-8?B?eis5bDNlTzBNMXpGUlJ1QnlsN2ZSem93U0dERnNGWkNzNnVuRUp3NFFkaWxK?= =?utf-8?Q?RZMkRWXrfK1BkkeE=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: PAVPR03MB8946.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7ccee2f1-681e-44a7-2f50-08de5cc5c362 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2026 10:29:18.9160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hL2kZh7EbLFKkmn/1SdMVmbKe+wI/Dv9cerD0mg/9LFf8EsVqRr0ypbDfCeBhBPD1GwQuX1vDsIQTy3B/mg28OBVXPQIGtO1wt9YhND22Zc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR03MB8454 SGkgSmFuLA0KVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzLg0KDQpPbiAyMi8wMS8yMDI2IDA5 OjUxLCBKYW4gQmV1bGljaCB3cm90ZToNCj4gT24gMjEuMDEuMjAyNiAxOTo0MywgT2xla3NpaSBN b2lzaWVpZXYgd3JvdGU6DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NpLmMNCj4+ ICsrKyBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY2kuYw0KPj4gQEAgLTEyNiw2ICsxMjYsNDEg QEAgaW50IHNjaV9hc3NpZ25fZHRfZGV2aWNlKHN0cnVjdCBkb21haW4gKmQsIHN0cnVjdCBkdF9k ZXZpY2Vfbm9kZSAqZGV2KQ0KPj4gICAgICAgcmV0dXJuIDA7DQo+PiAgIH0NCj4+ICAgDQo+PiAr aW50IHNjaV9kb19kb21jdGwoc3RydWN0IHhlbl9kb21jdGwgKmRvbWN0bCwgc3RydWN0IGRvbWFp biAqZCwNCj4+ICsgICAgICAgICAgICAgICAgICBYRU5fR1VFU1RfSEFORExFX1BBUkFNKHhlbl9k b21jdGxfdCkgdV9kb21jdGwpDQo+PiArew0KPj4gKyAgICBzdHJ1Y3QgZHRfZGV2aWNlX25vZGUg KmRldjsNCj4+ICsgICAgaW50IHJldCA9IDA7DQo+PiArDQo+PiArICAgIHN3aXRjaCAoIGRvbWN0 bC0+Y21kICkNCj4+ICsgICAgew0KPj4gKyAgICBjYXNlIFhFTl9ET01DVExfYXNzaWduX2Rldmlj ZToNCj4+ICsgICAgICAgIHJldCA9IC1FTlhJTzsNCj4+ICsgICAgICAgIGlmICggZG9tY3RsLT51 LmFzc2lnbl9kZXZpY2UuZGV2ICE9IFhFTl9ET01DVExfREVWX0RUICkNCj4+ICsgICAgICAgICAg ICBicmVhazsNCj4+ICsNCj4+ICsgICAgICAgIGlmICggIWN1cl9tZWRpYXRvciApDQo+PiArICAg ICAgICAgICAgYnJlYWs7DQo+PiArDQo+PiArICAgICAgICBpZiAoICFjdXJfbWVkaWF0b3ItPmFz c2lnbl9kdF9kZXZpY2UgKQ0KPj4gKyAgICAgICAgICAgIGJyZWFrOw0KPj4gKw0KPj4gKyAgICAg ICAgcmV0ID0gZHRfZmluZF9ub2RlX2J5X2dwYXRoKGRvbWN0bC0+dS5hc3NpZ25fZGV2aWNlLnUu ZHQucGF0aCwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkb21jdGwt PnUuYXNzaWduX2RldmljZS51LmR0LnNpemUsICZkZXYpOw0KPj4gKyAgICAgICAgaWYgKCByZXQg KQ0KPj4gKyAgICAgICAgICAgIHJldHVybiByZXQ7DQo+PiArDQo+PiArICAgICAgICByZXQgPSBz Y2lfYXNzaWduX2R0X2RldmljZShkLCBkZXYpOw0KPj4gKw0KPj4gKyAgICAgICAgYnJlYWs7DQo+ PiArICAgIGRlZmF1bHQ6DQo+IE5pdDogQmxhbmsgbGluZSBhYm92ZSBoZXJlIHBsZWFzZS4NCj4N Cj4+IEBAIC0yNzQsNyArMjc3LDcgQEAgc3RhdGljIGJvb2wgaXNfc3RhYmxlX2RvbWN0bCh1aW50 MzJfdCBjbWQpDQo+PiAgIA0KPj4gICBsb25nIGRvX2RvbWN0bChYRU5fR1VFU1RfSEFORExFX1BB UkFNKHhlbl9kb21jdGxfdCkgdV9kb21jdGwpDQo+PiAgIHsNCj4+IC0gICAgbG9uZyByZXQgPSAw Ow0KPj4gKyAgICBsb25nIHJldCA9IDAsIHJldDEgPSAwOw0KPiBUaGlzIGluaXRpYWxpemVyIGlz bid0IHJlYWxseSBuZWVkZWQsIHdpdGggLi4uDQo+DQo+PiBAQCAtODMzLDcgKzgzNiwyOCBAQCBs b25nIGRvX2RvbWN0bChYRU5fR1VFU1RfSEFORExFX1BBUkFNKHhlbl9kb21jdGxfdCkgdV9kb21j dGwpDQo+PiAgICAgICBjYXNlIFhFTl9ET01DVExfdGVzdF9hc3NpZ25fZGV2aWNlOg0KPj4gICAg ICAgY2FzZSBYRU5fRE9NQ1RMX2RlYXNzaWduX2RldmljZToNCj4+ICAgICAgIGNhc2UgWEVOX0RP TUNUTF9nZXRfZGV2aWNlX2dyb3VwOg0KPj4gKyAgICAgICAgLyoNCj4+ICsgICAgICAgICAqIENo YWluIFNDSSBEVCBoYW5kbGluZyBhaGVhZCBvZiB0aGUgSU9NTVUgcGF0aCBzbyBhbiBTQ0kgbWVk aWF0b3INCj4+ICsgICAgICAgICAqIGNhbiBhdXRob3Jpc2UgYWNjZXNzLWNvbnRyb2xsZWQgRFQg ZGV2aWNlcy4gVW5oYW5kbGVkIGNhc2VzIHJlcG9ydA0KPj4gKyAgICAgICAgICogLUVOWElPLCB3 aGljaCBpcyBpZ25vcmVkLg0KPj4gKyAgICAgICAgICovDQo+PiArICAgICAgICByZXQxID0gLUVO WElPOw0KPiAuLi4gdGhpcywgaXMgaXQ/IEluIGZhY3QsIHdoeSBub3QgdXNlIC1FTlhJTyBhcyBp bml0aWFsaXplcj8NCj4NCj4+ICsgICAgI2lmIElTX0VOQUJMRUQoQ09ORklHX0FSTV9TQ0kpDQo+ PiArICAgICAgICByZXQxID0gc2NpX2RvX2RvbWN0bChvcCwgZCwgdV9kb21jdGwpOw0KPj4gKyAg ICAjZW5kaWYNCj4gV2h5IHRoZSBpbmRlbnRhdGlvbiBvZiB0aGUgcHJlLXByb2Nlc3NvciBkaXJl Y3RpdmVzPyBBdCB0aGUgdmVyeSBsZWFzdCB0aGUgIy1lcw0KPiB3YW50IHRvIGJlIGluIHRoZSBm aXJzdCBjb2x1bW4sIGJ1dCBJIHNlZSBubyByZWFzb24gZm9yIHRoZSBpbmRlbnRhdGlvbiBhdCBh bGwuDQo+DQo+PiAgICAgICAgICAgcmV0ID0gaW9tbXVfZG9fZG9tY3RsKG9wLCBkLCB1X2RvbWN0 bCk7DQo+PiArICAgICAgICBpZiAoIHJldCA8IDAgKQ0KPj4gKyAgICAgICAgICAgIHJldHVybiBy ZXQ7DQo+IFlvdSBjYW4ndCBzaW1wbHkgcmV0dXJuIGhlcmUsIGFzIHdlIG1heSBiZSBob2xkaW5n IGFuIFJDVSBsb2NrIG9uIHRoZSBkb21haW4uDQo+DQo+PiArICAgICAgICAvKg0KPj4gKyAgICAg ICAgICogSWYgSU9NTVUgcHJvY2Vzc2luZyB3YXMgc3VjY2Vzc2Z1bCwgY2hlY2sgZm9yIFNDSSBw cm9jZXNzaW5nIHJldHVybg0KPj4gKyAgICAgICAgICogY29kZSBhbmQgaWYgaXQgZmFpbGVkIHRo ZW4gb3ZlcndyaXRlIHRoZSByZXR1cm4gY29kZSB0byBwcm9wYWdhdGUNCj4+ICsgICAgICAgICAq IFNDSSBmYWlsdXJlIGJhY2sgdG8gY2FsbGVyLg0KPj4gKyAgICAgICAgICovDQo+PiArICAgICAg ICBpZiAoIHJldDEgIT0gLUVOWElPICYmIHJldDEgPCAwICkNCj4+ICsgICAgICAgICAgICByZXQg PSByZXQxOw0KPiBTbyBpZiBJT01NVSBwcm9jZXNzaW5nIHdhcyBzdWNjZXNzZnVsIGFuZCBiZWNh dXNlIG9mIFNDSSB5b3UgcmV0dXJuIGFuIGVycm9yDQo+IGhlcmUsIHdoeSB3b3VsZCB0aGUgSU9N TVUgcGFydCBub3QgbmVlZCB1bmRvaW5nPyBPciB0byBhc2sgZGlmZmVyZW50bHksIGlmDQo+IFND SSBzYWlkICJubyIsIHdoeSBldmVuIHRyeSB0aGUgSU9NTVUgb3BlcmF0aW9uPw0KPg0KPiBKYW4N Ck15IGludGVudGlvbiB3YXMgdG8gcHJlc2VydmUgdGhlIG9yaWdpbmFsIGJlaGF2aW9yIGFzIG11 Y2ggYXMgcG9zc2libGUuDQpUaGlzIG1lYW5zIHRoYXQgaWYgdGhlIFNDSSBhc3NpZ24gb3BlcmF0 aW9uIHJldHVybnMgYW4gZXJyb3IsIHdlIHN0aWxsDQphdHRlbXB0IHRoZSBJT01NVSBhc3NpZ25t ZW50LCBidXQgZmlsdGVyIHRoZSByZXR1cm4gY29kZSBhbmQgdWx0aW1hdGVseQ0KcmV0dXJuIHRo ZSBTQ0kgZXJyb3IgaWYgdGhlIElPTU1VIGFzc2lnbm1lbnQgd2FzIHN1Y2Nlc3NmdWwuDQpIb3dl dmVyLCBpbiB0aGlzIHNjZW5hcmlvLCB3ZSB3b3VsZCBzdGlsbCByZXR1cm4gYW4gZXJyb3IgZnJv bQ0KdGhlIGRvbWN0bCBjYWxsLCB3aGljaCBjb3VsZCBsZWFkIHRvIHVuZXhwZWN0ZWQgcmVzdWx0 cy4NCg0KSSBhZ3JlZSB3aXRoIHlvdXIgcG9pbnQuDQoNCldpdGggeW91ciBzdWdnZXN0aW9uLCB0 aGUgY29kZSBiZWNvbWVzIG11Y2ggY2xlYW5lcjoNCg0KI2lmIElTX0VOQUJMRUQoQ09ORklHX0FS TV9TQ0kpDQogwqDCoMKgwqDCoMKgwqAgcmV0ID0gc2NpX2RvX2RvbWN0bChvcCwgZCwgdV9kb21j dGwpOw0KIMKgwqDCoMKgwqDCoMKgIGlmICggcmV0IDwgMCAmJiByZXQgIT0gLUVOWElPICkNCiDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIGJyZWFrOw0KI2VuZGlmDQoNCiDCoMKgwqDCoMKgwqDCoCBy ZXQgPSBpb21tdV9kb19kb21jdGwob3AsIGQsIHVfZG9tY3RsKTsNCiDCoMKgwqDCoMKgwqDCoCBi cmVhazsNCg0KV2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQgdGhpcyBhcHByb2FjaD8NCg0KT2xla3Np aQ== From xen-devel-bounces@lists.xenproject.org Mon Jan 26 10:32:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 10:32:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213531.1523993 (Exim 4.92) (envelope-from ) id 1vkJtA-00061G-O0; Mon, 26 Jan 2026 10:32:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213531.1523993; Mon, 26 Jan 2026 10:32: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 1vkJtA-000619-LE; Mon, 26 Jan 2026 10:32:08 +0000 Received: by outflank-mailman (input) for mailman id 1213531; Mon, 26 Jan 2026 10:32: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 1vkJt9-000613-FT for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 10:32: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 40c27301-faa2-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 11:32:06 +0100 (CET) Received: from BL1P223CA0018.NAMP223.PROD.OUTLOOK.COM (2603:10b6:208:2c4::23) by LV3PR12MB9166.namprd12.prod.outlook.com (2603:10b6:408:19c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.6; Mon, 26 Jan 2026 10:31:59 +0000 Received: from BL6PEPF0001AB4D.namprd04.prod.outlook.com (2603:10b6:208:2c4:cafe::a6) by BL1P223CA0018.outlook.office365.com (2603:10b6:208:2c4::23) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.16 via Frontend Transport; Mon, 26 Jan 2026 10:31:45 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF0001AB4D.mail.protection.outlook.com (10.167.242.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Mon, 26 Jan 2026 10:31:59 +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; Mon, 26 Jan 2026 04:31:59 -0600 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 26 Jan 2026 04:31:59 -0600 Received: from [10.252.147.171] (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, 26 Jan 2026 04:31:57 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 40c27301-faa2-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=dOUXqN5Z3OOElaVcMN60Bfnn8JsrgpDXRqYHvYqjsiD084LH0eJmxA8xAsX+cSwkeZ/n1YIxrq3qbF1Rjcprbjuk/OnPJHE4P5oBbeS2d4RW62KqvYx6cDcRnpgm4k9cu54QqJnHXwbA66864fiQCExEcZYJm2y6TAhqUz5mwyzeZ4BuY3Dyaq199bh+5LjUDDZ/7Us9paIzFnB+VLtb7Aw4EpRzIq/8Ts/L9WrEUjpCRLOLGD8sJhO4ILqPjvwT5ReDE1ogMppaGOzhpOuPJ7kwKEBzBlwwAXGhZrecNQwDilUaNRBkFKUQ1CxRN5R4G8NLRX/XqSgv7z+WLIbJBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9hax5IQVpzAukgGgzVYkk6unbzvHGMAyZVzacTxzeBA=; b=x5/BxbysGJZC4kYbuUxCU1i8HNK3En7UEBu0PGjHq4G9biywKZ+590663P17JWqjyK6S9YC9wxUxg3mwY0P+ya95sJYSNr08CJolQXVWveM30Vs7vQZ99YOgr9BaIUhkpMFdmBEj1k2VYQ4SOPfPdAa7JP26wz5a8fxNgI69Dk7yDLSz4lYmlXQXvxFdWCSwVmmaEz/elDNsswMrKnduUBHTyB8Hta525yCNF6c2I5MWVh122mLn0qWbHnUQWaA+iTGxhJys3X3fgQTVRFBPyzPLFUasswQpENPlkk9z4YJ4ueyZSpiCnzHfIfjE9IOUurN7P0Sfq5oEUEODNsZ0vQ== 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=9hax5IQVpzAukgGgzVYkk6unbzvHGMAyZVzacTxzeBA=; b=MGWj9trIBJsen1zFic334/8xiN3dwoSWYws2d/YNfn5WX4hyfJWKrNLPNPRSZEHz+SGUQfPrDXPp1DUJ2WHY4MRCcjEdvZK4irz1tImAPE5ZMInufTMsMhXFfzYiab4yT8AGo+mFowYuK7sHsd3NRT7NBO7gsL7G6LRX72mDMfw= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <2a4e34cd-dc68-45fb-9646-eb9a0d4929eb@amd.com> Date: Mon, 26 Jan 2026 11:31:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] kconfig: adjust NR_CPUS defaults To: Jan Beulich CC: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Oleksii Kurochko , "xen-devel@lists.xenproject.org" References: <1caed635-3d9b-47ed-b8fb-d6c391293059@suse.com> <6f4901b7-3121-4dce-bdeb-da3644e719c3@suse.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <6f4901b7-3121-4dce-bdeb-da3644e719c3@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB4D:EE_|LV3PR12MB9166:EE_ X-MS-Office365-Filtering-Correlation-Id: a698c4fa-b8ac-4e3b-97e4-08de5cc6233f 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?RG0vU2JEUVlQYUY3VEdVY1ZPVk9INzhiTFFXYjF5cEZISUlML2luNm0waGhH?= =?utf-8?B?Q29XSitYR09kT0VGZXZYTUFyVDlYVUs3ZFU3TTc4OURVVExiUXBFVmxqak1S?= =?utf-8?B?OWRhWnErbWJ6MEw0RTFwbVIwVENkQVNQalREYUwvMElkZ1dFY1h5Qlhab2Q1?= =?utf-8?B?Z3MrL0NKN3NNb2tyWFd5K0djY0E2WFEyeDVKYXloUitUOG5wYmlMbEh6WXZw?= =?utf-8?B?b0cwNlQ1dFY5MW40R2tOYmxua1FFd0FIK2RnVjBkNFJYTGFQRXJvNUI2QkZT?= =?utf-8?B?SE9UV1piSkxLRnVmMFlqYVNVZ2FnNDJ4UDkwUEZZQmhkRytXWE5mNTJEdzRN?= =?utf-8?B?KzVNdStGUXF1WFRWYVorTlpKdWNUbEtUUGQ5MFR4TVlzQTd1dDdvV1hRRUNY?= =?utf-8?B?UExsOTBvbkJYaEtHZlgwK2MrRHpNY3Y4azc2T21Cb1QvV1JHckRkV3BWWXZG?= =?utf-8?B?M29FS1pRUm9pZnB2c0NqZjVJWm1rUitsdkR5OXkyQllXR1VlRUFhb2d1NE1V?= =?utf-8?B?a0JLU2ZqMXg3WGlnSUhHNXYyTXpEZGYxM3A1T1RnWHI4ZzdQSi8zdW1FNnhR?= =?utf-8?B?TkxCQ0pacjNOVzJOZXZEMGh0NUhacWlGc2wwZmRFNkx1ZDRmM1JjbXpxRHRS?= =?utf-8?B?YU5nZVQvQ2xPMGJscWdEN3orL2JSeWI4R1kyQzN3aVRtWkNRbUd4bVpuM0kv?= =?utf-8?B?VnVuNTVhSHErWERWQkpvVTB1TG9ET3BKamZoNnJURnJVMTB2aDBJNGtMS2Jh?= =?utf-8?B?ZHVGeDNpd2ZFbm1WU0xWYTBKQU9HbUdIQWVUTk1aZjEwUitJTkd3UHJ6d3hZ?= =?utf-8?B?dUZXcXZHaFZickg0eWg2aUtFd0RMc0RvRlRMWUpGU29zcmJFTytOWUVVcE1u?= =?utf-8?B?SFR3OTdaTnh4cnFMR3l3bUViLzVXbE9nTFZDeE9XVC9mSDZSc213SnUwYVho?= =?utf-8?B?VWg0b2ptck5OTURsdG9uWS9lUjFQaEozQW9wbWFFMDZWcUdmK21sRUx5ZHk2?= =?utf-8?B?VmpKbEZHQkdlQ1E2cEZZc2FoZjRiays5ZHc2ZHZXRkZtaUZsUEVEZStvdjUv?= =?utf-8?B?Y2RPOTRGMFFwcy9tUGJaMXpKUHNFSDNvVE1vaXVuZHZUS0RXQlhqVkJMVllG?= =?utf-8?B?S3FVanV0ZXA3MWZ6bGdVVkl2WkJtVVNjOHFFYjZYUlhkb3BxMm5iVkFFdW5r?= =?utf-8?B?ajFYUXErUEZoNkVJNG9HbUt1QUN2SnRuSXR4dlpkSlIrVlBwZGJxaFVNeDNt?= =?utf-8?B?d2kwQlhiYjQzbGxMQ3ZnM2ZuMFl0TjRTZWwxa3F0OEtHZFpUSnJBQ0tEZkNq?= =?utf-8?B?cVdYZWx5dHVwU1ZDYjVkSFFZRTFpNW85ZVZXV3RXUlJxNWNSekdpYVRsak5Y?= =?utf-8?B?S0dJY1VQZjFnRWVNYm1kMEhlS1VCaENiTk9qL21HZHpWSE9pRWJvQlkrTVo3?= =?utf-8?B?MnFXZHl1Y1FuSkxoWGhQaVhXeDM1cXA0N09ySVVnblpxbmVXRVdaYjJ1b2xR?= =?utf-8?B?UUhSWXVUOUxxMm5oU2htaG1HYTlWeVUrSmREVnlMbGJPK1d4cjlKbEZBaEVa?= =?utf-8?B?d2o1c2tOYVBwTm5XRG5lRHd3RFE2dnczaFYvMVdjNk1FVyt6VlcvMnhkTkor?= =?utf-8?B?d0J4ZU9PMlZjQm13SWxuUlFicERFV09sUEF3MC9xaUhuUnNERHlEZHlTVUc1?= =?utf-8?B?UHI1Z2dDNkZOVzRjZWUxS3pjTmQrRDhUaDFGeUxjd1EwamZiZTVlL3NCWEJq?= =?utf-8?B?KzQwUXZ6SUlpTmdBWkR1Y3gwMEVORStkcmlNaHpkMGFMUk5Kc0JhWFhlWnZn?= =?utf-8?B?U1pwdnJlcVZEUGJBSnRHUUhFaUxNL1plSGNwc3RzanE5d3F6UmJQM3BqRUFj?= =?utf-8?B?WFBRWmNjY1BFaXVycGxXTUlZdm5aa2pxWGRHaWt5N0xTWUZWWkZwSHZ2cTJi?= =?utf-8?B?YnIxaWhaSllqMCtDR00yYlRZODlSOXZXTUp6NTl1em5Cb2FvUnpkUUUzeHVM?= =?utf-8?B?YUZ0bUFicVkyWWhFU0tZU1BIeGNkY1o2Q0lBWE01Y05CRFd4NFRNSE9kTzVW?= =?utf-8?B?ZUJtb0NvUHZwVVh3WjJVWWthQ1RINTI1dDlPRjRGL2dGT1MxNmRtRTZhN1FW?= =?utf-8?B?M0p2a3lSRzdzbnZ6MzZRVlhtdGRnVTdXMHJEbVlOYWo5a0ZYdStIWlFKS3Nt?= =?utf-8?B?WGxYQkNwWHQwRFRPT0hET3ZNYWEwejJkemtoeWZibW02YW9lNGtQY1o4OUY5?= =?utf-8?B?VU5mcC9VU2o5b0hqMDFMb2VZQmtBPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(376014)(36860700013)(82310400026)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2026 10:31:59.7369 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a698c4fa-b8ac-4e3b-97e4-08de5cc6233f X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BL6PEPF0001AB4D.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9166 On 26/01/2026 11:13, Jan Beulich wrote: > On 26.01.2026 11:08, Orzel, Michal wrote: >> On 14/01/2026 12:33, Jan Beulich wrote: >>> Discussion of a RISC-V change revealed that for PPC and RISC-V we don't >>> really set any default, but rather rely on internals of kconfig picking >>> the lowest of the permitted values in such a case. Let's make this >>> explicit, requiring architectures that mean to permit SMP by default to >>> explicitly record some sensible value here. >>> >>> Leverage the adjustment to the "1" case to simplify all subsequent ones. >>> >>> Signed-off-by: Jan Beulich >> Reviewed-by: Michal Orzel > > Thanks. > >> with one question... >> >>> --- >>> For not-yet-SMP-capable ports we might go even further and use >>> >>> range 1 1 if !X86 && (!ARM || MPU) >>> >>> at the top. Thoughts? (I've not done this right away as it is liable to >>> get unwieldy when we have a larger number of SMP-capable ports.) >>> >>> --- a/xen/arch/Kconfig >>> +++ b/xen/arch/Kconfig >>> @@ -9,11 +9,11 @@ config NR_CPUS >>> range 1 1 if ARM && MPU >> Why not simply && MPU given that MPU is an ARM specific option in our Kconfig. > > Good question, to be answered by whoever put this here. I guess the anticipation > may have been that "MPU" might end up meaning something else on another arch, at > some future point? Except for this specific case, there is no other use of MPU in non-arch Kconfig or code, so it's difficult to say. I would be more willing to tie it to Arm, so that we don't need ARM/CONFIG_ARM before MPU/CONFIG_MPU. ~Michal From xen-devel-bounces@lists.xenproject.org Mon Jan 26 10:37:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 10:37:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213544.1524004 (Exim 4.92) (envelope-from ) id 1vkJy7-0006aq-8o; Mon, 26 Jan 2026 10:37:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213544.1524004; Mon, 26 Jan 2026 10: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 1vkJy7-0006aj-5w; Mon, 26 Jan 2026 10:37:15 +0000 Received: by outflank-mailman (input) for mailman id 1213544; Mon, 26 Jan 2026 10: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 1vkJy6-0006ad-FC for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 10:37:14 +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 f9b82eb7-faa2-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 11:37:13 +0100 (CET) Received: by mail-wm1-x344.google.com with SMTP id 5b1f17b1804b1-47ee807a4c5so45663945e9.2 for ; Mon, 26 Jan 2026 02:37:13 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48047028928sm473885975e9.2.2026.01.26.02.37.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 02:37:12 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f9b82eb7-faa2-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769423832; x=1770028632; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=QH6werwhuDoxXqsVmmhfzJDuXAxDbm169BaFbVwsTPU=; b=cHpFoOI8ibVBWikSx6stH2sD1aDqkfsg9f5RNqbiOoxMn6YmI/XBmFMR1BvYJeibSe F6XB6n5odqQ/H+caF2cKiyieFX+gXq12dlGQ6PIGfkQSPk5ezRCIb0m+LHuBv6apihSB 9G+U5rxsPcCWXDF5ZrPuKRpcGM3BGGKRTDbcP5r09yFOCiv0P5+oUo5WWQEc9jfHDDSi 3X153ucEwk3t59mV/+KO8Z+nczropsY3vL0HuBUr/r+EwP3EGBqolZRMIFfdT5nOoMev mV0n1vLIuJw4jH5kssmpsA5lAZyhDKrSrXiM4oVQ6nmml/YUoso/GB/dVS4aXTEb5aJV lBLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769423832; x=1770028632; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=QH6werwhuDoxXqsVmmhfzJDuXAxDbm169BaFbVwsTPU=; b=HyZPbDhDSI4404ijkObe2NL84grjYN4OomhA2LQEFyiHEy8WTig5P/mYxTD845jw12 haodHNUoelW6MfTVSrZhx6cnViiFQmDuOqeaZFqh+edP7L9PXzYsO5SBc5bvOe2ExMhz sR6sSzUD+wYrcwgZlBy8DbE3zJL9EA4amBA4Mz9fQScHdxm8cBp22jdtsmqL5HmfuUNn f9biWHqS40YoxTYOEO/O9V/GoMuxXghB+UVEgUDVfv/VGauqpGsgnU9d0HDJJwO/tN63 84XkCHgusHUTUtQtcN/BOu0y4nX/Ngg0ZO6QhN2dmf651IrylFfyxENR6tUHXYdzRTIg g1YQ== X-Forwarded-Encrypted: i=1; AJvYcCVlHJd2NakK1p2T3ODsJSSf3VTKm0J743Z9oD7Kkx49ipAOOAbEUrz4fdqAGJR2YCD7QgfiHU7QoEc=@lists.xenproject.org X-Gm-Message-State: AOJu0YyqXFAJriFireS5ibi0uCMaUHl5kdnRCbgzeqKIKq2V1nM67R++ 0DQScbfIrRr5EFuA4/vmpZlxKZs4Eyuv29ez40zEf5qmCVV+Kf09eyO210XMpiXBtg== X-Gm-Gg: AZuq6aIrl1fzYvMNE70q6AHvdgaM3BLsQ+fUbuuJjNlZAetUac66HU0NWngu4755CuM LotcaWTd5ben7MLdf2+jSAojwRgXdUxV5h4tavg98ZVBVp1HKgVUDql7REM7a1FpjS7MkHbCjf+ 06fvF1CjEjMQeMeIQFzGkfhy5Zu0uficeqsZbEP4/adwBMOFID9FfmOz+GGy0d1wCcCQlfZk3JB j0RtKkhPQe3bO5rVb5hgyClqfzrpaJmWrwPlsfgjVcBQFeed664VaU1G/PjLWtnBE1HcdqScm96 BVjOVt9FM29bVtkjSVmyyw9eJ3t0uXtahTZ9hsJNT33LYFa5lMIm9h55fS+xNzUlQZviEP2nl9c quj2BmDMA2ARf+mO0mxY7szSGjf/lJqEPV/q4nT5XmGx1EShZ4R7/bX103xYQmD3EjAylTI+H6l EdwKuU7Tig3wz/cqPPMfGzSNnhuGAVZINhhzF7kwNq/WUPOzxH0yfe4HrtEvUcVxSWUNVNywyqz /U= X-Received: by 2002:a05:600d:640e:10b0:480:4a4f:c363 with SMTP id 5b1f17b1804b1-4805fa86191mr38226355e9.9.1769423832332; Mon, 26 Jan 2026 02:37:12 -0800 (PST) Message-ID: Date: Mon, 26 Jan 2026 11:37:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 1/5] xen/domctl: chain SCI handling before IOMMU in assign_device domctl To: Oleksii Moisieiev Cc: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" References: <8482f823e945060d1a36469f14f94aa6251e3f71.1769020872.git.oleksii_moisieiev@epam.com> <114d2326-112b-41ea-8c32-12b785f8e7a0@suse.com> <0df180b2-1e9b-4dfd-b2a9-cbe9b805d114@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: <0df180b2-1e9b-4dfd-b2a9-cbe9b805d114@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 26.01.2026 11:29, Oleksii Moisieiev wrote: > Hi Jan, > Thank you for your comments. > > On 22/01/2026 09:51, Jan Beulich wrote: >> On 21.01.2026 19:43, Oleksii Moisieiev wrote: >>> --- a/xen/arch/arm/firmware/sci.c >>> +++ b/xen/arch/arm/firmware/sci.c >>> @@ -126,6 +126,41 @@ int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev) >>> return 0; >>> } >>> >>> +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d, >>> + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) >>> +{ >>> + struct dt_device_node *dev; >>> + int ret = 0; >>> + >>> + switch ( domctl->cmd ) >>> + { >>> + case XEN_DOMCTL_assign_device: >>> + ret = -ENXIO; >>> + if ( domctl->u.assign_device.dev != XEN_DOMCTL_DEV_DT ) >>> + break; >>> + >>> + if ( !cur_mediator ) >>> + break; >>> + >>> + if ( !cur_mediator->assign_dt_device ) >>> + break; >>> + >>> + ret = dt_find_node_by_gpath(domctl->u.assign_device.u.dt.path, >>> + domctl->u.assign_device.u.dt.size, &dev); >>> + if ( ret ) >>> + return ret; >>> + >>> + ret = sci_assign_dt_device(d, dev); >>> + >>> + break; >>> + default: >> Nit: Blank line above here please. >> >>> @@ -274,7 +277,7 @@ static bool is_stable_domctl(uint32_t cmd) >>> >>> long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) >>> { >>> - long ret = 0; >>> + long ret = 0, ret1 = 0; >> This initializer isn't really needed, with ... >> >>> @@ -833,7 +836,28 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) >>> case XEN_DOMCTL_test_assign_device: >>> case XEN_DOMCTL_deassign_device: >>> case XEN_DOMCTL_get_device_group: >>> + /* >>> + * Chain SCI DT handling ahead of the IOMMU path so an SCI mediator >>> + * can authorise access-controlled DT devices. Unhandled cases report >>> + * -ENXIO, which is ignored. >>> + */ >>> + ret1 = -ENXIO; >> ... this, is it? In fact, why not use -ENXIO as initializer? >> >>> + #if IS_ENABLED(CONFIG_ARM_SCI) >>> + ret1 = sci_do_domctl(op, d, u_domctl); >>> + #endif >> Why the indentation of the pre-processor directives? At the very least the #-es >> want to be in the first column, but I see no reason for the indentation at all. >> >>> ret = iommu_do_domctl(op, d, u_domctl); >>> + if ( ret < 0 ) >>> + return ret; >> You can't simply return here, as we may be holding an RCU lock on the domain. >> >>> + /* >>> + * If IOMMU processing was successful, check for SCI processing return >>> + * code and if it failed then overwrite the return code to propagate >>> + * SCI failure back to caller. >>> + */ >>> + if ( ret1 != -ENXIO && ret1 < 0 ) >>> + ret = ret1; >> So if IOMMU processing was successful and because of SCI you return an error >> here, why would the IOMMU part not need undoing? Or to ask differently, if >> SCI said "no", why even try the IOMMU operation? >> >> Jan > My intention was to preserve the original behavior as much as possible. > This means that if the SCI assign operation returns an error, we still > attempt the IOMMU assignment, but filter the return code and ultimately > return the SCI error if the IOMMU assignment was successful. > However, in this scenario, we would still return an error from > the domctl call, which could lead to unexpected results. > > I agree with your point. > > With your suggestion, the code becomes much cleaner: > > #if IS_ENABLED(CONFIG_ARM_SCI) >         ret = sci_do_domctl(op, d, u_domctl); >         if ( ret < 0 && ret != -ENXIO ) >             break; > #endif > >         ret = iommu_do_domctl(op, d, u_domctl); >         break; > > What do you think about this approach? Yes. Just to double-check though: There's nothing that needs undoing after a successful sci_do_domctl() when the subsequent iommu_do_domctl() failed? One other remark: No IS_ENABLED() please in pre-processor directives. It wants to be #ifdef there. IS_ENABLED() is for use in if(). Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 26 10:44:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 10:44:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213552.1524014 (Exim 4.92) (envelope-from ) id 1vkK4o-0008Oz-Un; Mon, 26 Jan 2026 10:44:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213552.1524014; Mon, 26 Jan 2026 10:44:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkK4o-0008Os-Rq; Mon, 26 Jan 2026 10:44:10 +0000 Received: by outflank-mailman (input) for mailman id 1213552; Mon, 26 Jan 2026 10:44: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 1vkK4n-0008Om-9u for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 10:44:09 +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 eb96ea96-faa3-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 11:43:59 +0100 (CET) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-65813e3bdaaso7507674a12.1 for ; Mon, 26 Jan 2026 02:43:58 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6584b3e08a6sm4821910a12.6.2026.01.26.02.43.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 02:43:57 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: eb96ea96-faa3-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769424238; x=1770029038; 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=7lNXKcYdnQ1/qSUu8FaqbTuOxIFbGYXxJIUnr6BKoBU=; b=a8C88b6VY0+3iBZlaFCE8CjkzJ9YCCq6SONtRurkbarRr14bdkxbkKH5f2Q9pKO1pp Otl27i2S4RiqiwvcaE3Hrk/DDPAMsKmbiHyF92Ge/LGUSLYCFoE1XTF/U6g1EnehKKv3 tgRDRbWyK+swrYlz2nPHYSCPw91LI0J4rIBlZqUzTYeRiURF4bhSSJ7S42gPSgieedSD 7peoh2NX7BKmCYNCsIyQ47UfHLSSWDbfO/WhZHoJMwv1ObD05mvLjnDTqqR7vP8D/bFi pwtBvLiixM/5JY3Pck3OnY3AKWJXWSfkU+S1RAT1OTwdIJFu8xTzqi09M0D3BQBQ7svg a7nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769424238; x=1770029038; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7lNXKcYdnQ1/qSUu8FaqbTuOxIFbGYXxJIUnr6BKoBU=; b=ZPBGiWCRlP3mEF9U0VVerLgrPnQ134c0Ss/TLTi/yihVwc890wSHaku12zPtaO4Tja 5pX7t8FNbAG7ZATFuWvZCXhMMf56b7N5EGsC63AizcAzGU38jQwykS9uJfwads337UEX TVGHSkAxjB0jciGJWWe4WMVY6fHZvjjonISBT1B/rlLuWtfK/yt5yfQNljmANLafPeDD j82XJdZ6ba76CSX4zoQDR4yoVLN/A/HzoODWHN6wZdo8ls218LYuJtMjsSryjAIRONtX 1ebWqxc1w/MwjqP9M1MFvT8vE3pwNT212AiYUu+iv/wqHGhDHV8YIaie+0BDru4LSYRM 4/Mg== X-Forwarded-Encrypted: i=1; AJvYcCV3qEaMFjt065vmZim64jXP/0NxmEy6UTpJ2ef5pWtiPC5By5aDKXyHw6Y194W4hvuLr9F7kSMhU6o=@lists.xenproject.org X-Gm-Message-State: AOJu0YzUE6MVFaIcX+B3iB8C+QTcqZxW1R5Zs5qsIAmSPgMZCF/lXFnw xo3SVg2yq+juzgqf6trDqyoA6IstbLZw3jThG9XXTXDiLQqfobuoiBGN X-Gm-Gg: AZuq6aKXmxE9RMgMmn0ES93S6tWqxzl3ewQjoHjluvd2MX8yylqHOswcII9azS5IEKs 8EyMaIxJYTmSNWy8NY9ZvUtJy1Iee5TwsZ/zbxyqy6EtsYmMOr/4jU+zEXv1+ipmHFyXUfQolCE 0jYRCWXIs++1WfZkHw4pKlCfzrIae5TEiRWn27KN8Rj8ADEpd2HO9fzRA27OSIQQ7kc0MIc8gKi PyAHk0fzvChc+NupoZB1o+CLwwy1S7gIquMy0KyrEZ3d/yJ7rxjsiW8n6PeZju/oHTE9BemR6AA 2AiYuOPuPgU6yTVNYgVDQFEGjGPklpYTpI/bl1EA5ADr9ksIDAFYvszzbuwpup8yatJ3STZ5Wh5 F69+Swk39bkv8c75dg+w+jFTG4y1kLRQVcSRmIO5J5jNgxf4pHPliJOipb+tchPiSv57CrMxw67 ZDSjRggmTQqurbSAvw4DXGxlIIoSDfnOIg/fIXqllKzS1VKYTjZPAYeSYSqNonzV7bXLKXT8COL A== X-Received: by 2002:a05:6402:4306:b0:658:1224:3d5b with SMTP id 4fb4d7f45d1cf-658709c0267mr2987332a12.1.1769424237992; Mon, 26 Jan 2026 02:43:57 -0800 (PST) Message-ID: <5e3cd0da-d8d0-4232-9612-14ea70bd66e4@gmail.com> Date: Mon, 26 Jan 2026 11:43:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] xen/riscv: dump GPRs and CSRs on unexpected traps To: Jan Beulich Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <0b57db49d40b336429dd4fd63faf18f6bb17ac1a.1769179393.git.oleksii.kurochko@gmail.com> <9a68c272-1c76-4f1f-89ff-ff86d5181bcc@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <9a68c272-1c76-4f1f-89ff-ff86d5181bcc@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/26/26 11:09 AM, Jan Beulich wrote: > On 26.01.2026 09:38, Oleksii Kurochko wrote: >> --- a/xen/arch/riscv/traps.c >> +++ b/xen/arch/riscv/traps.c >> @@ -99,12 +99,81 @@ static const char *decode_cause(unsigned long cause) >> return decode_trap_cause(cause); >> } >> >> +static void dump_general_regs(const struct cpu_user_regs *regs) >> +{ >> +#define GPR_LIST \ >> + X(regs, ra, " ") X(regs, sp, "\n") \ >> + X(regs, gp, " ") X(regs, tp, "\n") \ >> + X(regs, t0, " ") X(regs, t1, "\n") \ >> + X(regs, t2, " ") X(regs, s0, "\n") \ >> + X(regs, s1, " ") X(regs, a0, "\n") \ >> + X(regs, a1, " ") X(regs, a2, "\n") \ >> + X(regs, a3, " ") X(regs, a4, "\n") \ >> + X(regs, a5, " ") X(regs, a6, "\n") \ >> + X(regs, a7, " ") X(regs, s2, "\n") \ >> + X(regs, s3, " ") X(regs, s4, "\n") \ >> + X(regs, s5, " ") X(regs, s6, "\n") \ >> + X(regs, s7, " ") X(regs, s8, "\n") \ >> + X(regs, s9, " ") X(regs, s10, "\n") \ >> + X(regs, s11, " ") X(regs, t3, "\n") \ >> + X(regs, t4, " ") X(regs, t4, "\n") >> + >> +#define X(regs, name, delim) \ >> + printk("\t %-4s: %016lx" delim, #name, (regs)->name); > No semicolon here please; that should be supplied at the use sites of > such a macro. I thought about this option, but decided it would be fine to do in this way as it is a local marco and isn't expected to be used anywhere else, so it will help to avoid a bunch of semicolons where X macro used now. Anyway, I am okay to rework that. > > As to the format string: If past the leading tab you want an extra > padding blank, why not "\t%-5s ..."? Question however is why this deep > indentation is wanted in the first place. I'd suggest to omit the tab > in particular. I will check how it will look, probably we could really just drop \t and use only "%-4s". > >> + GPR_LIST > What use is this macro? All it does is hamper readability, by requiring > the line-continuation backslashes in its definition. Agree, it doesn't really useful to have GPR_LIST. I will just leave X macro and open-coded what is now in GPR_LIST instead. > >> +#undef X >> +#undef GPR_LIST >> +} >> + >> +static void dump_csrs(unsigned long cause) >> +{ >> +#define CSR_LIST \ >> + X(stvec, CSR_STVEC, " ") X(vstvec, CSR_VSTVEC, "\n") \ >> + X(sepc, CSR_SEPC, " ") X(vsepc, CSR_VSEPC, "\n") \ >> + X(stval, CSR_STVAL, " ") X(vstval, CSR_VSTVAL, "\n") \ >> + X(status, CSR_SSTATUS, " ") X(vsstatus, CSR_VSSTATUS, "\n") \ >> + X(satp, CSR_SATP, "\n") \ >> + X(scause, CSR_SCAUSE, " [%s]\n", \ >> + decode_cause(v)) \ >> + X(vscause, CSR_VSCAUSE, " [%s]\n\n", \ >> + decode_cause(v)) \ > Anything that can help save space (as indicated, output may go to a limited size > screen) should imo be leveraged. IOW better no double newline here, nor ... For it could be useful visually separate group of hypervisor-related registers. > >> + X(hstatus, CSR_HSTATUS, " [%s%s%s%s%s%s ]\n", \ >> + (v & HSTATUS_VTSR) ? " VTSR" : "", \ >> + (v & HSTATUS_VTVM) ? " VTVM" : "", \ >> + (v & HSTATUS_HU) ? " HU" : "", \ >> + (v & HSTATUS_SPVP) ? " SPVP" : "", \ >> + (v & HSTATUS_SPV) ? " SPV" : "", \ >> + (v & HSTATUS_GVA) ? " GVA" : "") \ >> + X(hgatp, CSR_HGATP, "\n") \ >> + X(htval, CSR_HTVAL, "\n") \ >> + X(htinst, CSR_HTINST, "\n") \ >> + X(hedeleg, CSR_HEDELEG, "\n") \ >> + X(hideleg, CSR_HIDELEG, "\n") \ >> + X(hstateen0, CSR_HSTATEEN0, "\n\n") > ... here. In this latter case it's questionable anyway, as apparently you > have this here to separate from the GPRs being logged subsequently. Just > that right here you don't know whether your caller actually means to do > so. With this one, I agree that it is not the best one place for double newline. It was necessary to avoid printk("\n") before GPRs dumping. In general, I am fine with dropping the double newline and using a single newline, as this separation is probably only useful to me. > > As to grouping: How about further putting hedeleg and hideleg on a single > line? Maybe also htval and htinst? Good point. I will apply theses suggestions. > >> +#define X(name, csr, fmt, ...) \ >> +do { \ >> + unsigned long v = csr_read(csr); \ >> + printk("\t %-10s: %016lx" fmt, #name, v, ##__VA_ARGS__); \ >> +} while (0); >> + >> + CSR_LIST > Same remarks here as above. The issue is actually worse here, as CSR_LIST > uses "v" which it isn't passed. I will declare local variable v in dump_csrs() and use it. Considering that this macros is declared and used only inside this function I think I can not pass it to X macro. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Jan 26 10:47:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 10:47:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213567.1524024 (Exim 4.92) (envelope-from ) id 1vkK7o-0000ZE-F8; Mon, 26 Jan 2026 10:47:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213567.1524024; Mon, 26 Jan 2026 10:47:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkK7o-0000Z7-B4; Mon, 26 Jan 2026 10:47:16 +0000 Received: by outflank-mailman (input) for mailman id 1213567; Mon, 26 Jan 2026 10:47: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 1vkK7n-0000Yw-5s for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 10:47:15 +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 5f4c2f2e-faa4-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 11:47:13 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-47ee807a4c5so45764345e9.2 for ; Mon, 26 Jan 2026 02:47:13 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804d8bebfasm308650875e9.14.2026.01.26.02.47.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 02:47:11 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5f4c2f2e-faa4-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769424432; x=1770029232; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=tD4v2anhJcga48XigqYXAbpz+irs7hDzKUZljjovD8M=; b=adRm99MArSGajuwxZaZrLhCJvr3rxXBU/OMY0R3uAI2hvLSZt/dmM/UOk0w6AVkD1E uKx909NR/U+J5UnCh3vpEimpMCPTh71u1o/Qfr+yM62IKsIi/0Xo+r4w6DjsdxEngLe+ TII3E1b2lXiuLLdxnFI8WiJvcD9PQP+DNMFODKO2IdbWr1UgVEa0anm2bQkKYIHR5pve cI1Bl0l1jVTO6FjSNmGdA5jlpVWMjC5heGq0piSC2DKCPyt9DRE6ANSFsGkOCATs2tA1 +mqAoOc/fIqbMPLAIk/he+fKtPXHMVnp27IQ9vbsgV86+hZQHnp0F3oPTlxAf2ClDB8b fL3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769424432; x=1770029232; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=tD4v2anhJcga48XigqYXAbpz+irs7hDzKUZljjovD8M=; b=bt4JbRoMinmy6+c0sCpkBULtqt2RW+mKNXFEQ0S21kyzUxvhEy4UTqAGr5uiKilRr/ LVF3PebBXxwBMDw5PlA1lL3OkYln/5ZQcVlxXbBOi8ACrRhpAxWTaoj4PSruV9/LBqxS cr0ZZ0elY7V0dGMax4dN9Tp3RuKsjDsaNuilVSxxIwa6PR3D1u1vVn2QMXAM+qvk4f0k t8qbTfUdiaKchUkD7j4ajRkdyTxpdFxSnczGumdhyEohNANrr3gGuZ9zQ3qBau67nF91 rJbEvIcIh8SfWBD2rUr6eAGGXeZWG4uN5zMBeehcZZu3K1R54I0RKVbRxIMEhPx87Mw+ fnLw== X-Forwarded-Encrypted: i=1; AJvYcCWOLWLzOmuoE3ObAPmZRHSMUqfjuyy+nr9r7JUyeXXxpQXJaEneaInFjrLNifE2okDF5iLHY62q5SE=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz68+Z1GatVlpiYbZHSEuEDoaUN/Y0QKOOsjm0ze0tSq/VRndSQ 9JjmEsFVae7L5y+cjJGWEq8R7Dm68RIRkKtpPIsvAqGk8DnGW2mdcgyUEL33bSUCxQ== X-Gm-Gg: AZuq6aLEHt5YOMcgVMJtRTqvJMTCVbgXA8jQg75dqZA9W5PFg8JFgI1P0C5dlW82m9V 57xLlHKwao0T2yqND7n5QIqVWah8GGIfp9wrXGp99+nVw7d3ZR5SWyjK4aiDDcPClpuaWLwTVyb mHG967gTqOHtIHAVj/1pA7g3dTKH7+ZNcb+J7KQmE0I5yxEUQ+vYcb5xnte9FHrqQsmCHdrUfIa tBRJ6WbzyCmX7iS8wSecbgtGsCc6gN6FDwETSXlxVf+vgOb+RirUt2onL0lCW/L/6lh6QqHaSIK oJbrlSfMbzx0N8Qym6HFvk2TubKfR0lciVs/X04WqvDw88YJh/b8KljMr7DUFfnO957I4Qvs3Xs G60Cn/1QxGdlwi1LXFHpgUVZ2hLTyppW95P6aVqOyevux/3RdW6V4jslTOT+jez4UB+EMAQP5TB UfGVJKPJnmygnAzmFza3bevDIWad+qTwxjXLnLmSGjqf4giPaJ93AOapFtaXx89FbE7riqD5aAw QxT4GUEKZFmig== X-Received: by 2002:a05:600c:4f86:b0:475:dd89:acb with SMTP id 5b1f17b1804b1-4805cf6749bmr57091305e9.22.1769424432325; Mon, 26 Jan 2026 02:47:12 -0800 (PST) Message-ID: Date: Mon, 26 Jan 2026 11:47:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] xen/riscv: dump GPRs and CSRs on unexpected traps To: Oleksii Kurochko Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <0b57db49d40b336429dd4fd63faf18f6bb17ac1a.1769179393.git.oleksii.kurochko@gmail.com> <9a68c272-1c76-4f1f-89ff-ff86d5181bcc@suse.com> <5e3cd0da-d8d0-4232-9612-14ea70bd66e4@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: <5e3cd0da-d8d0-4232-9612-14ea70bd66e4@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.01.2026 11:43, Oleksii Kurochko wrote: > On 1/26/26 11:09 AM, Jan Beulich wrote: >> On 26.01.2026 09:38, Oleksii Kurochko wrote: >>> +#define X(name, csr, fmt, ...) \ >>> +do { \ >>> + unsigned long v = csr_read(csr); \ >>> + printk("\t %-10s: %016lx" fmt, #name, v, ##__VA_ARGS__); \ >>> +} while (0); >>> + >>> + CSR_LIST >> Same remarks here as above. The issue is actually worse here, as CSR_LIST >> uses "v" which it isn't passed. > > I will declare local variable v in dump_csrs() and use it. Considering that > this macros is declared and used only inside this function I think I can > not pass it to X macro. Yes, that should indeed be fine. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 26 11:14:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 11:14:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213578.1524035 (Exim 4.92) (envelope-from ) id 1vkKYI-0004zR-G5; Mon, 26 Jan 2026 11:14:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213578.1524035; Mon, 26 Jan 2026 11: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 1vkKYI-0004zK-CA; Mon, 26 Jan 2026 11:14:38 +0000 Received: by outflank-mailman (input) for mailman id 1213578; Mon, 26 Jan 2026 11: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 1vkKYH-0004zD-4x for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 11:14:37 +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 32257d86-faa8-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 12:14:35 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-47fedb7c68dso43842875e9.2 for ; Mon, 26 Jan 2026 03:14:35 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804d4f8417sm102275965e9.2.2026.01.26.03.14.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 03:14:34 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 32257d86-faa8-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769426075; x=1770030875; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=on4ZBGoNZjT6ZVd5JbLYn7EK6JWlqgQal6ewdA+Q0FM=; b=SvnwwaZ6DR1CyyI6FwqG4ZK6TD9IZY2qVZ/cZqq8FwsizmGuuZGlAb2KO/40QuYuWs diWfGIDUDFqRqLv8wcplIS3xoXBLZlAUm7733tnEZbFNu3/2QTJEbjXLF8IrPap9Ztub jlmxni9DFalQczzHmAGN4ouT9K29t6exb1gd4trYxXif6AOCqIqJM4cEP3ngzPxUaAbq 7iA95dhs+ZRDdyOzlQQYWUYanYHODeZ34UGPqwG5S36PEWZc1fQKXClTdkzDye7pQeWr vnNs2No+qwgFtGSZOOG336hfgLYDCR7GBMDrMM6aSjhMdazqPjjvITv2IKjy2dl/a/G2 xbVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769426075; x=1770030875; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=on4ZBGoNZjT6ZVd5JbLYn7EK6JWlqgQal6ewdA+Q0FM=; b=NR2TdgCX6RkqLWSMxiokrlSgVzC/ZgpcSXOPBOiwpdcJQ0iqPAenpMM3wIJumJGHR2 3J2NPHl4A52AEsysqssDm6BQWskOWTCwvLpV/aR7y+6kmBYEqSrqP1JjHL9rdmqVXzFD U2bT46N1DoZ0/q5yZBg9VRT0Tzx7Am4UE2q1KJOLeRFFCCPTMdreQj44NEJZZQZ4k5bt MgRKo9IDPFNaaiKlLOyfxwdGnyq77ebUQpT1COhEsqpmV0aEcigOHXSPvUxbBWG9RB/T vXMZiiOTkxRszgShrYd7o4MhQoY48HmcGi17Arkdl3Kf+qrx675OyG+d2wGddp+wEsVg Ygag== X-Forwarded-Encrypted: i=1; AJvYcCUa8bqilGezFk8BQ/wS4SNLzpCTSnsrcc2AF84XvJAYTZ7MQaoSnMRGYK8oBL7yP1fVHUaonxxizXk=@lists.xenproject.org X-Gm-Message-State: AOJu0YxDH9MztxNpaZHUpoX5Eg71uMthx0wCICDWUnnuOVZZdwqOiEan zJN4ElFORA6QVtwp7AsgMSyG/RK1jNwo0YUYy9YH+T8bm/XbDG+q2x9XH5jSG3fA0Q== X-Gm-Gg: AZuq6aLOT1y1/8sUB7rbmLhSHyohTtE5fyjK3RKE+/5i3Wgm+DOhKNYfyms1R0ttc8r WQJdJOhMtLDHJZMVIC5f7M0s+8vf10ThOO9xPyRPxBLVMSs/av44Ohsi5VorpUb8m+q6ZSfQtz8 2Igjn/49ePfymHy+CngA1OjzJqL4WHAE56cuizcyAlBM89Z8SeHI3QIeTRJFCY2YUroR1k6oxu2 rpMqHkANkFo/1MXksA1mkuwMAjHsel2+/Zk4rwIYWlBgd3PRlvYxRAIE2R72OcH1DIl+cVjlkIX ssONoVWzYFPOqotpGyuNOchKospjrPoGB8Dm75+ri6bcWTyhRua89p1RE9Fd5F9uONo/19RiyOA 6LYzPu6KmH2lXvnnOdARjjTQsOJlJ59ZlOdOUuaolLYO59uka/P5IY8MFt5mtE7ebalzhNVkq26 nEyMeH09M4Ig4wNxVUn21cD40cmnGmrBrNuNFLLJZAgXHIZQ12M04dkQqooeRil1y5XcM/9Hm3/ +0= X-Received: by 2002:a05:600c:35c4:b0:47e:e9c9:23bc with SMTP id 5b1f17b1804b1-4805cf673f5mr71005565e9.30.1769426074640; Mon, 26 Jan 2026 03:14:34 -0800 (PST) Message-ID: <69a64a89-af3f-47fe-8998-a3ff76e9484e@suse.com> Date: Mon, 26 Jan 2026 12:14:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/3] xen/mm: allow deferred scrub of physmap populate allocated pages To: Roger Pau Monne Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260122173857.83860-1-roger.pau@citrix.com> <20260122173857.83860-3-roger.pau@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260122173857.83860-3-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 22.01.2026 18:38, Roger Pau Monne wrote: > Physmap population has the need to use pages as big as possible to reduce > p2m shattering. However that triggers issues when big enough pages are not > yet scrubbed, and so scrubbing must be done at allocation time. On some > scenarios with added contention the watchdog can trigger: > > Watchdog timer detects that CPU55 is stuck! > ----[ Xen-4.17.5-21 x86_64 debug=n Not tainted ]---- > CPU: 55 > RIP: e008:[] clear_page_sse2+0x1a/0x30 > RFLAGS: 0000000000000202 CONTEXT: hypervisor (d0v12) > [...] > Xen call trace: > [] R clear_page_sse2+0x1a/0x30 > [] S clear_domain_page+0x11/0x20 > [] S common/page_alloc.c#alloc_heap_pages+0x400/0x5a0 > [] S alloc_domheap_pages+0x67/0x180 > [] S common/memory.c#populate_physmap+0x22f/0x3b0 > [] S do_memory_op+0x728/0x1970 > > Introduce a mechanism to preempt page scrubbing in populate_physmap(). It > relies on stashing the dirty page in the domain struct temporarily to > preempt to guest context, so the scrubbing can resume when the domain > re-enters the hypercall. The added deferral mechanism will only be used for > domain construction, and is designed to be used with a single threaded > domain builder. If the toolstack makes concurrent calls to > XENMEM_populate_physmap for the same target domain it will trash stashed > pages, resulting in slow domain physmap population. > > Note a similar issue is present in increase reservation. However that > hypercall is likely to only be used once the domain is already running and > the known implementations use 4K pages. It will be deal with in a separate > patch using a different approach, that will also take care of the > allocation in populate_physmap() once the domain is running. > > Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed") > Signed-off-by: Roger Pau Monné > --- > Changes since v2: > - Introduce FREE_DOMHEAP_PAGE{,S}(). > - Remove j local counter. > - Free page pending scrub in domain_kill() also. Yet still not right in domain_unpause_by_systemcontroller() as well. I.e. a toolstack action is still needed after the crash to make the memory usable again. If you made ... > @@ -1286,6 +1293,19 @@ int domain_kill(struct domain *d) > rspin_barrier(&d->domain_lock); > argo_destroy(d); > vnuma_destroy(d->vnuma); > + /* > + * Attempt to free any pages pending scrub early. Toolstack can still > + * trigger populate_physmap() operations at this point, and hence a > + * final cleanup must be done in _domain_destroy(). > + */ > + rspin_lock(&d->page_alloc_lock); > + if ( d->pending_scrub ) > + { > + FREE_DOMHEAP_PAGES(d->pending_scrub, d->pending_scrub_order); > + d->pending_scrub_order = 0; > + d->pending_scrub_index = 0; > + } > + rspin_unlock(&d->page_alloc_lock); ... this into a small helper function (usable even from _domain_destroy(), as locking being used doesn't matter there), it would have negligible footprint there. As to the comment, not being a native speaker it still feels to me as if moving "early" earlier (after "free") might help parsing of the 1st sentence. > --- a/xen/common/memory.c > +++ b/xen/common/memory.c > @@ -159,6 +159,66 @@ static void increase_reservation(struct memop_args *a) > a->nr_done = i; > } > > +/* > + * Temporary storage for a domain assigned page that's not been fully scrubbed. > + * Stored pages must be domheap ones. > + * > + * The stashed page can be freed at any time by Xen, the caller must pass the > + * order and NUMA node requirement to the fetch function to ensure the > + * currently stashed page matches it's requirements. > + */ > +static void stash_allocation(struct domain *d, struct page_info *page, > + unsigned int order, unsigned int scrub_index) > +{ > + rspin_lock(&d->page_alloc_lock); > + > + /* > + * Drop any stashed allocation to accommodated the current one. This > + * interface is designed to be used for single-threaded domain creation. > + */ > + if ( d->pending_scrub ) > + free_domheap_pages(d->pending_scrub, d->pending_scrub_order); Didn't you indicate you'd move the freeing ... > + d->pending_scrub_index = scrub_index; > + d->pending_scrub_order = order; > + d->pending_scrub = page; > + > + rspin_unlock(&d->page_alloc_lock); > +} > + > +static struct page_info *get_stashed_allocation(struct domain *d, > + unsigned int order, > + nodeid_t node, > + unsigned int *scrub_index) > +{ ... into this function? Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 26 11:21:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 11:21:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213589.1524044 (Exim 4.92) (envelope-from ) id 1vkKem-0006hZ-3U; Mon, 26 Jan 2026 11:21:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213589.1524044; Mon, 26 Jan 2026 11:21:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkKel-0006hS-W2; Mon, 26 Jan 2026 11:21:19 +0000 Received: by outflank-mailman (input) for mailman id 1213589; Mon, 26 Jan 2026 11:21: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 1vkKel-0006hM-H7 for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 11:21: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 21cc5a2e-faa9-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 12:21:17 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-47ee2715254so22268055e9.3 for ; Mon, 26 Jan 2026 03:21:17 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1f7474csm30252505f8f.37.2026.01.26.03.21.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 03:21:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 21cc5a2e-faa9-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769426477; x=1770031277; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=E43DcvrP5beWQgrbmajUhgvk0qNAxaHXNrsdJr5xH8U=; b=OQ6fUcUBJPApooxFwVfaaQzK76slc/u1+W8vBZve1gS9Lw6EfVi8iyK6a88Pe3vxxA VvTw6WoLHnOuSkEjyV0k/J1jOTye2Bzle+MI4WJPzeMHG4MJMovYRTLSuQ07xn/o3o1A fmfae01n4ETcUPbgt8ctM54fDsCA+/1rbZeFrQ9CgWicKOGVzAh5CHfeJhzi9/kzi1Ni 8j9f+onVXx2ZPy9Ov4HwV7t5Rl8bC8iwYh9kjkVxnchFltZcvErGMt38B6k4IAD7xf7B vlc4JGlccfT45PDWYMzJUpaxQSB6fNwBv/+V30E3hFHb2KLMPPd8fpNk8mEkB7Lq/pe2 BRiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769426477; x=1770031277; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=E43DcvrP5beWQgrbmajUhgvk0qNAxaHXNrsdJr5xH8U=; b=Jv/7vcIZeg4QWnsDb/ZGrqjKDvKoqJvdSdM2F5V4F1DnW35CMLhXL0zRzF6etA4YJ0 Waq7LwLN+mXoBkLr0v12Y3EiiFhurhbDQQzZ7bzW8EkYJmkkjivFda5SeHVbIzvi9ICo IppKkTH4bE3igHcwP6I4bau2wZSeBTCxE8ToWqh9b2wqJxyR772C/C2Mmo//fiU6VpQq asLmzg4VhHd3UkRRNWjwEVt7Rcqw2uI90l8Hoe/3yv+y8+Yy+OjYeLmqeybYEvb6uIsQ IbgNuagGalJQMUp64fL4mgxGc1oHYO8ws+IetbAHW2pWZ/5NHwpglB6RMIaquABLqHv4 Oy3Q== X-Forwarded-Encrypted: i=1; AJvYcCVLEwZ4M4sSjPD3Fz2hUO502UUqxGJXwEd+F9CfWSfg5k/xi2r2UXiUem8D1etTPBOHTye8ifHrmco=@lists.xenproject.org X-Gm-Message-State: AOJu0YyVVbZNUOdOWNQC4UkeuWONpCk62mmjx6NMsOSjvHk30ep5i8++ VX9ZDyBltn54yTL5CGaTYqYQ+J1/w51uyA1kWNe+UDtBoXDTIZiz90pjmmSDmNUjLQ== X-Gm-Gg: AZuq6aKSSOn2AF88EljGPEepmBjEwSspy5QuX43dS2CJuvlsi0ESriV5+YxYfdEySRm d9UyxUSH7TwpxULr9nuixLZ5ZHVOvynFd286m1gVIVd1mLqBxANd4zu+AAn5ZFEOdxTkgQuQOQc AMNlDXJYcdnDypc4FH0wVhzVQ5MUhlUZj2CVUMmW3x4aYY8APHQ7ZMjWUqHZqiiECRTuxmogqRK p8mZzOHxVESZmJ93MWkkCh6NYnl6f+UfUwQd0cqG3xLqYEGwuNZitRMKt131T5zeTNyLZ79MduA e6pk+LMAFwKzhvrjOCkoiXd24h3oNOBHjOa30Zq1M9j+MwG6vfSjW+audPKQF/pKi8TUDlCLpD6 lg6Ov0VJ3pTa4LuJdyBwzVN5iQa346b6/1UD1I7iTGpxmg0edkdGh7JA1xCvxZjkmq6d7arLcLL ta3irxahuvWA/NzLEpRqj8XwePlZvzUBLaJc/oGnOVivmnNDsgQvaFK67kumM42llSxLxDIG48c mo= X-Received: by 2002:a05:600c:6291:b0:480:20f1:7aa6 with SMTP id 5b1f17b1804b1-4805fa93271mr49848865e9.21.1769426476697; Mon, 26 Jan 2026 03:21:16 -0800 (PST) Message-ID: <0ff49a6b-67d3-4b2e-bf9f-4b752cfc24aa@suse.com> Date: Mon, 26 Jan 2026 12:21:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/3] xen/mm: limit non-scrubbed allocations to a specific order To: Roger Pau Monne Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260122173857.83860-1-roger.pau@citrix.com> <20260122173857.83860-4-roger.pau@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260122173857.83860-4-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 22.01.2026 18:38, Roger Pau Monne wrote: > The current logic allows for up to 1G pages to be scrubbed in place, which > can cause the watchdog to trigger in practice. Reduce the limit for > in-place scrubbed allocations to a newly introduced define: > CONFIG_DIRTY_MAX_ORDER. This currently defaults to CONFIG_PTDOM_MAX_ORDER > on all architectures. Also introduce a command line option to set the > value. > > Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed") > Signed-off-by: Roger Pau Monné Apart from a nit (see below) looks technically okay to me now. Still I have an uneasy feeling about introducing such a restriction, so I'm (still) hesitant to ack the change. > --- a/xen/common/page_alloc.c > +++ b/xen/common/page_alloc.c > @@ -267,6 +267,13 @@ static PAGE_LIST_HEAD(page_offlined_list); > /* Broken page list, protected by heap_lock. */ > static PAGE_LIST_HEAD(page_broken_list); > > +/* Maximum order allowed for allocations with MEMF_no_scrub. */ > +#ifndef CONFIG_DIRTY_MAX_ORDER > +# define CONFIG_DIRTY_MAX_ORDER CONFIG_PTDOM_MAX_ORDER > +#endif > +static unsigned int __ro_after_init dirty_max_order = CONFIG_DIRTY_MAX_ORDER; > +integer_param("max-order-dirty", dirty_max_order); The comment may want to mention "post-boot", to account for ... > @@ -1008,7 +1015,13 @@ static struct page_info *alloc_heap_pages( > > pg = get_free_buddy(zone_lo, zone_hi, order, memflags, d); > /* Try getting a dirty buddy if we couldn't get a clean one. */ > - if ( !pg && !(memflags & MEMF_no_scrub) ) > + if ( !pg && !(memflags & MEMF_no_scrub) && > + /* > + * Allow any order unscrubbed allocations during boot time, we > + * compensate by processing softirqs in the scrubbing loop below once > + * irqs are enabled. > + */ > + (order <= dirty_max_order || system_state < SYS_STATE_active) ) ... the system_state check here. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 26 11:22:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 11:22:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213598.1524054 (Exim 4.92) (envelope-from ) id 1vkKgJ-0007Cg-Bp; Mon, 26 Jan 2026 11:22:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213598.1524054; Mon, 26 Jan 2026 11:22:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkKgJ-0007CZ-9I; Mon, 26 Jan 2026 11:22:55 +0000 Received: by outflank-mailman (input) for mailman id 1213598; Mon, 26 Jan 2026 11:22:53 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkKgH-0007CR-Q4 for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 11:22:53 +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 59fb3b99-faa9-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 12:22:51 +0100 (CET) Received: from BY3PR04CA0027.namprd04.prod.outlook.com (2603:10b6:a03:217::32) by SA1PR12MB5671.namprd12.prod.outlook.com (2603:10b6:806:23b::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Mon, 26 Jan 2026 11:22:47 +0000 Received: from SJ1PEPF0000231E.namprd03.prod.outlook.com (2603:10b6:a03:217:cafe::c5) by BY3PR04CA0027.outlook.office365.com (2603:10b6:a03:217::32) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.16 via Frontend Transport; Mon, 26 Jan 2026 11:22:49 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ1PEPF0000231E.mail.protection.outlook.com (10.167.242.230) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Mon, 26 Jan 2026 11:22:46 +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; Mon, 26 Jan 2026 05:22:46 -0600 Received: from [10.252.147.171] (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, 26 Jan 2026 05:22:44 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 59fb3b99-faa9-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VvG0+nqCn/WtkUq0gQDOLSmDozpD+L5Vhiyzemda+cgqNsj4br+ZBkwcxPAlMVrVkhA9G8m3IwBkXrtE0iIYWqkFnAcju4Y5gGcLZy3MbGdtArnAAn+X3gfC/i5WFP3BuR/vxEHN5liFtRvngiMwyMkTiCLoHfidLDjnOvjrjsEdjPvEB+OiN+CnVXuWgRPQbrcw3udXanBgVQlH/oxsztma/4Wyyuh/LlFG5d6HUAJcglnpLxHzU+Tgw0nEzK8JzdnWW3Hp0AETS3Ew2wqldPNXzUVlM4h6+lFTfB5QIlxJgsOQdGMJN/RpPOjWy7dNPqCZO15yl/DdT6ELfsrCig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=m6qyioIvU9RUYXuwhlVte9ZxBF1MRC0yQ/DRbt2EtgE=; b=VqTzhuSEYHw1vQFt5VQkb0yMp9lb0AKFEK4iJ+qKHPISXA5WZ0TpP/+iCuP8XrIJdB4aN7L3T8S9TWcZIrSTLwpVDD/t5R5TLYZpfNEaUVmO5gLY7aR9R1+TJmco3TekA+L+pqlQ8Qdbw/wiunmCnZBQaKALp61YI6r74U1P+DxAv4uvtzp3tpyPetmtQMJHhIFq9zulN2CEhBfgyvgCG4pd0r2Aes9+Z0jJAYSeHH6g5TSDiY6kh2cbjU3BWPvMgbTotpYXUt52sgC9QtshEcAYTo00YKnLGu/ghqU3t5cDgAoDCA/7CyFF8jWvLlR8zYwDzp+8SQoIfTDSL4fjhw== 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=m6qyioIvU9RUYXuwhlVte9ZxBF1MRC0yQ/DRbt2EtgE=; b=Ed2Hqw48FdfTOOnBRQ3JGkBXVoD+8dO/jIZuHddTkcphdjB/ulE6hS7fPdw3CHascXl+WHcaFd5juH1FxPpzpENQ2kRj3ZMnSi2ES97gnOxf3T+R+JX7BiJ3aFxfPsav2GvOBzjMgp/EY1wcrhVJlGpw2sqcKaypcyX6N2vHNFY= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <216b8a31-a0c1-422b-b459-e831657bf07b@amd.com> Date: Mon, 26 Jan 2026 12:22:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] build/non-x86: fix symbol lookup in presence of build-id 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?= , Bertrand Marquis , Volodymyr Babchuk , Oleksii Kurochko , Timothy Pearson , Mykola Kvach References: 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: SJ1PEPF0000231E:EE_|SA1PR12MB5671:EE_ X-MS-Office365-Filtering-Correlation-Id: 3e10f221-3215-40e6-c84a-08de5ccd3b91 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026|7416014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?Y0JDekdTNy9nR1pVTzJjV2g2akovWldDa0lYVlQ1S3M0ZjdaQWNNakpkSnpL?= =?utf-8?B?bjZkaENaU0g1ZlZTQTZ6RHBtLyszbldCc3FNdUVMQTJod0dqaVVmWEtkUHlm?= =?utf-8?B?S1JWT3B2dkF2aTZPa1daZUdXbnROSlV0TmpZOHFjNVk3UXBnSHpHeTJFL1dq?= =?utf-8?B?S0hHTnpGTnlKUzR1UitrWWNUQjByR1NjR0RTWW1NK04yRG9ydERob2NySFM5?= =?utf-8?B?Y0hWbTZuMjFraTg3N25yeGwvdXJndzJCOEpXS0o5bmo0UEVvNmxRK3ZqQjQ2?= =?utf-8?B?SUdNZ29jOCtQUXE1TFZKbjc4c0wvYmJ3bnJVbUN6eUVUY0pxQXB0WWdteFNw?= =?utf-8?B?Nm5hK01RUHozSDBIV0k1NjZBdjdtUzdpeWZRbFYzODd0QzZYb1F1WnhnQ21K?= =?utf-8?B?RnBDMzQ3dTNwbW8vNVplSUZucVU4YisxSjVrWG95ZWxCOGRqdVUzOFFubmdM?= =?utf-8?B?U3JnUGF4NUdEQ2s5bW5JL2EvdXgwVExjOEpuYnYybzl5cEpGMnRneFNWYW9O?= =?utf-8?B?YWZTK0kyMXYxZmY1bmphb09ySnVRZ2tsdlpBNm1TQmVrc08zRmVMVnN5SGxs?= =?utf-8?B?SXhCdUo0ODJYcEtNWVFJK2djZnNnK055SW9Cck5Lc1IwNGFNQjRhQzlXVytN?= =?utf-8?B?V1Z0V2pKRXFYMUtqVUx6Si91VXo1T01hYmhiN0hIckxJc01XR3VjQWU0TUps?= =?utf-8?B?NC9IT0pXWHhOeEVGclZKSlgyUzU0ZlFCNTVkaWpwN1FLZ3ZXMnVUTWtYUGFG?= =?utf-8?B?ZnNjMWdWTjk0c096Y2RTc2diNUpKaC9QODJTNlJaRi8xVGV5RDZzT1U4WTVj?= =?utf-8?B?NG1LSUF0SmY1VmQ5aXVLK3NuRWNSWjdMeDd3K0VZY1lva1FlRVlJV1BVVUFB?= =?utf-8?B?NXY5UDhKSG5HZDRvOHgyNXJwVGR2WkVOYUxsNGNjS0pYYkdENTN5Wlk3MTBx?= =?utf-8?B?K2cvZFdtbk9hWjl2ZnFJaXo5cS9zempyTFU1cDRBdkJvRjNYbzVlenhaZFpW?= =?utf-8?B?VHNJdTZSY1M0dFRGZXJ0Y04yUlpFVURQZk5QNFBGaWlnZ2FmV1pJVCtyaDRp?= =?utf-8?B?NDZLd3ppYnlTY09vNWZoQkQwaTgzMkY4Z3ByMUVNbkhCT0p6OFdCZ2tFSTc5?= =?utf-8?B?bk1CaFFvWkV6YmdVdElobll1eGFXdlJzQ1drNW9sNDdPcU1OUmN5dUlTeDhO?= =?utf-8?B?TVNXSVovOHJjZVNwQ3NPT242cGIxdGVVSWdkL2k2MERyUy9uNzl0bDFmY3Nr?= =?utf-8?B?bEd6VHlYQnZpRFB2NU4wclp5aW15NWZvQkxHbUdzRlMzT0V4b2xkdlJ2amFn?= =?utf-8?B?Qjg4RzRtOWhJZ21maVJieCtDekFsMUJSSXVTelFLRFdTWFA4b2NOTUtTVU4y?= =?utf-8?B?bUduQVNEcy9xa2RmUnZsVGc4QWhZV21yR3hlL1lSYkVHWmZtV3UxWTh6UWg2?= =?utf-8?B?L3Q1RWl4MXJpOHRtLytkMDF4clRzYmttbFFrVjhESElHN3dON0hzRnlaL2Jl?= =?utf-8?B?TGtKNXU4L0ZraEJISUc5bUpMbHZlUkhGUW8zWVd3Y21MR2Z2akdSMWxUc3Zw?= =?utf-8?B?OFVVVDFTcExBQm1lWWg5amZtclFtY2pLSFU3KzNDdXlzYldoUm16R2ZPUTNY?= =?utf-8?B?ck9VY0JPTU5PaUFnUUlwU0FJMGU0TFkzSUgwTUlEU2Qrdmc4bFl3ZlJ6cWdL?= =?utf-8?B?WEdLdWkwRnZDMEg5b2o1cFRmUkNQd1drUWNqWUxqNXRiWWZUYmV3QkRTN0xO?= =?utf-8?B?NnAvNnI0UUNYeXpha2pXTi9IdVdGNDk0Z1ByOW5relR6NWJZNTRVMDdmVXZO?= =?utf-8?B?NWkzNnJIYjc2SlVKOHdNa21UM20zUzE2QWUrZU5KYjFwYW1QRk1Wb1lVVVFw?= =?utf-8?B?Y2NML3MzZDFDZklBb3V6NDRtTmYzKzhNNm1yNVIwdzR0QVV5bXgxRmM5Z2ty?= =?utf-8?B?MDdaK2tidFV2S09ZSmgwcGl0aEp2d1lqbzdpWlppeVQxM0pmNkM4Q0JSbVZk?= =?utf-8?B?M0Q1WDEwb1FPZy9DQkovNHZjdDdvVjRrQ0oreUhGTFMxUGRNM2pXM2NiMXlH?= =?utf-8?B?d3dTaE82dmE2RGxjM1JxSU9sK0d4akMzQXhkMEVhNGVzbWdPREhqcU9wUlNj?= =?utf-8?B?ZzZPZHc1YnJ1VWNFZGt1WU9zR0NkSjN2U2xyNjJiZnBNeURvYSt2SmtYOG90?= =?utf-8?B?ZDZNVThUaWZVWG9OU3Vxanc1czJUaC9acFdhQ29CUHpVc3dkOXFtMGUra2xo?= =?utf-8?B?ckFEVzl0bGZ3d29wVi9SVHlWQWNnPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026)(7416014)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2026 11:22:46.9817 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3e10f221-3215-40e6-c84a-08de5ccd3b91 X-MS-Exchange-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: SJ1PEPF0000231E.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB5671 On 16/01/2026 11:52, Jan Beulich wrote: > It's not clear why only x86 had $(build_id_linker) applied to all three > linking passes. Not doing so will alter symbol offsets between the 2nd > and 3rd passes for, potentially, all of the symbols at higher addresses > (intermediate alignment padding may mask this effect, though, so it will > look as if problems appeared randomly). > > Fixes: a353cab905af ("build_id: Provide ld-embedded build-ids") > Reported-by: Mykola Kvach > Signed-off-by: Jan Beulich Acked-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Mon Jan 26 11:32:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 11:32:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213612.1524065 (Exim 4.92) (envelope-from ) id 1vkKpi-0000f9-CY; Mon, 26 Jan 2026 11:32:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213612.1524065; Mon, 26 Jan 2026 11:32:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkKpi-0000f2-8s; Mon, 26 Jan 2026 11:32:38 +0000 Received: by outflank-mailman (input) for mailman id 1213612; Mon, 26 Jan 2026 11:32:36 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkKpg-0000eu-IU for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 11:32:36 +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 b4fdea1e-faaa-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 12:32:34 +0100 (CET) Received: from SJ0PR03CA0073.namprd03.prod.outlook.com (2603:10b6:a03:331::18) by CY3PR12MB9556.namprd12.prod.outlook.com (2603:10b6:930:10a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.16; Mon, 26 Jan 2026 11:32:29 +0000 Received: from SJ5PEPF000001D7.namprd05.prod.outlook.com (2603:10b6:a03:331:cafe::15) 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.9542.16 via Frontend Transport; Mon, 26 Jan 2026 11:32:32 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ5PEPF000001D7.mail.protection.outlook.com (10.167.242.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Mon, 26 Jan 2026 11:32:28 +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, 26 Jan 2026 05:32:27 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b4fdea1e-faaa-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IpfGH4R/5LvDHfCjJBGrHraACQiSkL5887w+V9H/iymVDrB7Hb2b1aeANTbhrdIAvRgKOkaNCXuq6zAPU+L5NAvg90O1Aqj1pMJT0RORVReAi5UB4krz6Wz2KAFHX3w+OVEfteZCW2y7qZM5zUJvky7Jd48FCZ+CoQ1OrJCJm/vADc3Dg2rjI82XCDqAgCdEv+HZALi7GcxmUThapCQ2ybfOOZ2Ymd/CngXfzsaZxDC7pxaEEWw2TCzRBwcFAdE3HEHYDGrwxV9fkn5GWwxkaNyPFIcOzecMM5v5FWx4/waXrmBVAwA01N5zQFarsk7dYvtDWiJHq0uW9rDUxi82BQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3WMYdXFpXMQhLLFRCp13w8dCirnyREJJcHw5TFRSLhM=; b=rKnORTah3hl+iKftXHvxPahMkK7hahpV11As+dR63kZFYejmXaS9QIAKxgDEmlSstvcCHrM6UP9Oj9s52ojX3Vrdje8g6e1UmICERLHvFJeV3q90LVRYxeuGWM4+HJOfWr2pwbqdO6Oe46ny88JKcoFoNNmz5Ud7Pi4+7+YuE0ueW3wC42Tvn5+lja7c87+Jbgda9hx1xwFS/WMsiEkiNZq0lKIDyfwpKyKoNHg9c1dSlu4xq+fzi4jGBwX9fv0iVW7BeEcs5wDaFVtGDMVdGixW5sJrp/XUHkFgSZX6mdOgMX2sdJmdf/k8U0WiLADsEXXPFqHAtDLVkAY657hrsQ== 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=3WMYdXFpXMQhLLFRCp13w8dCirnyREJJcHw5TFRSLhM=; b=2/sCPj0lWTyyUN9XJvUE5o/g4VO5zVcMpdRsl22P4bYeaZVqG7ZLdLWbBmHqayVu6ReQJaVOO2hAESaAOi4AIkUDHGEbhfZdHAUk2XlGnlwv4Nmc14g8MghuC6KGVXrXMD8BRMg/GFuWnKVqIMF0cqKPBEbNozrmDV0AsP9pIuo= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 26 Jan 2026 12:32:21 +0100 Message-ID: CC: Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH 3/4] x86/hvm: Remove cross-vendor checks from MSR handlers. From: Alejandro Vallejo To: Andrew Cooper , X-Mailer: aerc 0.20.1 References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <20260122164943.20691-4-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: SJ5PEPF000001D7:EE_|CY3PR12MB9556:EE_ X-MS-Office365-Filtering-Correlation-Id: 66c90775-d80d-4b9c-5ae0-08de5cce9669 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?R2ZWZmNOc2hQaXpNdnhJQ0pDOGN2ZGkyd0NoYmZXSmFTdERvZjNQeUlXYW9D?= =?utf-8?B?S25GdWgvcjYxbDI0ODViSUphejFVd290QUJqd0hDY3VwYzlFSjlGYk5Kek5W?= =?utf-8?B?eWdPUG9TMkJYOXNpRGNyRXoyNysvRDI4eDRQajYvckRrN25qb2lEWGNqNTB6?= =?utf-8?B?cDdCdGtnbXZLeVpDRm5PNU55UUpnelg2WUlWMHdFWVJua1lKME1NV3M0MnIy?= =?utf-8?B?ZXd6RGtMby9ib3VjODNZNHBqUTF2VXcwaXE4ZStaVHZodXlGU2szd1hZdWpB?= =?utf-8?B?U2ludWhrRWdqV0QzZjRPZFJnK3VaK3U2YzZxVkUvdi9qOUJ1Q0JxSVpDZm12?= =?utf-8?B?aENMVG5vdmw3dmk2dTQ4VVVBUVQvZWdZaGZRdlJSNE5Ua1Z1ZTNNc2lOMjc3?= =?utf-8?B?SHp3cEVSK1VVK09aZElQRkNlZW1rQjI2aThDMDhzNUNVek1MUjlXWHo5UlNH?= =?utf-8?B?Q25SUG9OQW84VEIxbG5pVkVoaFdxQjNDMjQ3YnlHY3dHUUhXT1NWY3FWVVZv?= =?utf-8?B?a0lNL2Z5YUJvQytLcUpKREdCQ1hONlJzcFNlVm05bUFLT0lPdG8yUDJGMzRq?= =?utf-8?B?VnZ2MXJmSG5jSUpMM2E0OFhuNTRta25YamNwRVFtbmRhSWd3bzB0U1ZuZ2gz?= =?utf-8?B?S0ZDT2N6UVdiakRnTUkvejlrbWllUzBNS2wvNUlqZUIreFI5cWlnM0R4Vjdt?= =?utf-8?B?aUJDd0FrTDYrK3FDb3ZtLytPQ2FxdDVncEhkdE5MR2xObkFnMXMyRk1iSE1W?= =?utf-8?B?ZFBTbDJmS0dkckJhQjRhNS9zbGE1RDRHbFhqQ3YwbEs4RjRRdUxab3p5V3ly?= =?utf-8?B?dW12Vk1XRFc2WkMvN3hqY0MzdzQwUStnVkp1UzdiUyt4dG9YblA0RWgrOHQ3?= =?utf-8?B?UWJpa0V0dVI2V2ErMzAwVnRjaXN1RWRhVTBGdE84SUlBdUZOZ3F2dXVCZk1a?= =?utf-8?B?cVdWQzBMcmZUelNaOXJkQUJqZzd4WmhEYWp0SDZycWdKS2ZuMERFRjZBZ2g5?= =?utf-8?B?WndCVXRDLy91bWdSSG94UHdtTkZZOGpoeko0UVZOcGw1V2R2VFR2dU9hUGtw?= =?utf-8?B?R01nRjY2c1l4cXpWdVJ6bzNobFRxS1h6aE1sYlNyYjBlbFh3L3ZmQ1FJaDB6?= =?utf-8?B?TmdQMDZ2VDc3WFFNV1dLWDl2SEU0czB2YjFGcUdWOVVRYTM3RFlXalhIR1Fp?= =?utf-8?B?UEYyejhGUmtsSXZIbTVzOThDS3d5bDAxUnRHS09uTWRzbVlBeGR1TzNsbCs1?= =?utf-8?B?R05SRlpWZ21Dc3o4elQwTGRqWHZUQmhDdUZnU0szZzVYbk1lV3N2dlFDZkhR?= =?utf-8?B?NmVpbWw2UmVtNThvcTlWbUo3ZnZMUHVoQkRoN2x3M3hPZmhFWXNzU2Vvblo3?= =?utf-8?B?STRpUGlwUy90aGlOY1lPUDhzMzJRTTRobExCMHFnT3A5ZU9FT1dVckFyVmww?= =?utf-8?B?cFpDcjJUR29WR3BucU5NbnV4akFvY3BOcjlvVGtOWHRiL0toakg4RDdFdVBx?= =?utf-8?B?QVlnODgzQUV6SHFEVmpXUGNacEJzLytsalN4cWtueklDMEI4bE80TGk1L1Za?= =?utf-8?B?Si9TM21aS3dyL05PREtuVUFIYkhjRnVzYkZtZjJuLzZocEQrWDd3d2VaZXd5?= =?utf-8?B?VmJOVlVzaXhwZGFydXdjNVZ1MEd1OWFBaWlUVERuT2RuVVlobHVUN0RiRUth?= =?utf-8?B?c0R1ZXlmRDMyYTcxdWJqV3ZHV0tRU2Rwa1R5TkZTZElreTNrWUh2ZWpmT3Bk?= =?utf-8?B?Vjh6MUdSam56TmxucFFFU2FuU0hqbThxM3MrK3EwYy94cVo1cHduV0dFdWt0?= =?utf-8?B?UktpWkRST0s0d09xY3ltRDZIVlhQdVUzUVBCTHNyWFlFMWJ2UklqUjM5b3lo?= =?utf-8?B?NkF1MHJNTW5KWndtYmxYTGRrT0dIbGViMWRMTTVFTjl2VkJPVVVlb29pdmVu?= =?utf-8?B?MTl5NmR6UTdVTCt6b2FBOWcybGNNVkJEd2tZSzExNXRtNldTaUJUNUwwLzcy?= =?utf-8?B?K1FLZ0pDNWFqSjdDRS9ZTW5pdVRiOHlEKzNlb3ZaWHVuWHAzb2ZXYWFXVXZO?= =?utf-8?B?VDdwdlk3aDBZci9Zc3BwRm55T3FDeExVNEJJTDNFYjVPZHlzcWR1aDRpS0NN?= =?utf-8?B?bzQzanVBRUlkZ2ZydHFJdklUY1RCZDJ6QkVnaEFFc1ZZY2RlUXAvdGNXQ1Zp?= =?utf-8?B?QWxSRmtmc09VR3lLOWFmY05paFJETVc2N283YWhvdVFyR0ozUkQ2MFhzRE5S?= =?utf-8?B?N1lraW5CY08zNDlrcE53Mmhldk9nPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(36860700013)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2026 11:32:28.8609 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 66c90775-d80d-4b9c-5ae0-08de5cce9669 X-MS-Exchange-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: SJ5PEPF000001D7.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY3PR12MB9556 On Fri Jan 23, 2026 at 7:35 PM CET, Andrew Cooper wrote: > On 22/01/2026 4:49 pm, Alejandro Vallejo wrote: >> Not a functional change now that cross-vendor guests are not launchable. >> >> Signed-off-by: Alejandro Vallejo >> --- >> xen/arch/x86/msr.c | 6 ++---- >> 1 file changed, 2 insertions(+), 4 deletions(-) >> >> diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c >> index ad75a2e108..c9cc4f0692 100644 >> --- a/xen/arch/x86/msr.c >> +++ b/xen/arch/x86/msr.c >> @@ -169,9 +169,9 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64= _t *val) >> break; >> =20 >> case MSR_IA32_PLATFORM_ID: >> - if ( !(cp->x86_vendor & X86_VENDOR_INTEL) || >> - !(boot_cpu_data.x86_vendor & X86_VENDOR_INTEL) ) >> + if ( cp->x86_vendor !=3D X86_VENDOR_INTEL ) >> goto gp_fault; >> + >> rdmsrl(MSR_IA32_PLATFORM_ID, *val); >> break; >> =20 >> @@ -190,8 +190,6 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64= _t *val) >> * the guest. >> */ >> if ( !(cp->x86_vendor & (X86_VENDOR_INTEL | X86_VENDOR_AMD)) || >> - !(boot_cpu_data.x86_vendor & >> - (X86_VENDOR_INTEL | X86_VENDOR_AMD)) || >> rdmsr_safe(MSR_AMD_PATCHLEVEL, val) ) >> goto gp_fault; >> break; > > Hmm.=C2=A0 Thinking about it, this would probably be cleaner to get rid o= f > the cp->x86_vendor field entirely, and retain the boot_cpu_data side. > > Additionally, this would fix a minor problem I'm having cleaning up the > CPUID code for XSAVE fixes, and provide better cache locality. > > ~Andrew I'll replace it on the new version for consistency. I don't mind. FYI, I'm planning to replace all occurences of this on a follow-up series w= ith a new cpu_vendor() helper (it's a simpler version evolved from the x86_vendor= _is() RFC I sent a while ago) to enhance DCE's ability to eliminate code. It is (= I hope) just a transient matter until all {x86_,}vendor field checks are repl= aced by cpu_vendor(). Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Mon Jan 26 11:41:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 11:41:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213621.1524074 (Exim 4.92) (envelope-from ) id 1vkKyV-0002Sv-5V; Mon, 26 Jan 2026 11:41:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213621.1524074; Mon, 26 Jan 2026 11: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 1vkKyV-0002So-2f; Mon, 26 Jan 2026 11:41:43 +0000 Received: by outflank-mailman (input) for mailman id 1213621; Mon, 26 Jan 2026 11:41:41 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkKyT-0002Si-Sx for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 11:41:41 +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 fae27bb2-faab-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 12:41:40 +0100 (CET) Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-42fed090e5fso2654393f8f.1 for ; Mon, 26 Jan 2026 03:41:40 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1c24b54sm30358393f8f.15.2026.01.26.03.41.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 03:41:39 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fae27bb2-faab-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769427700; x=1770032500; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=NzX6jEIUs9cmuvsE+hialT1oG1nBlxW7ukQptAIUJa0=; b=b0LdMKobJ58OHeO+s70dy2TJKox/TpOvrwtHPrYEBcvvf+bKg5Ud+/MVHiuZsvod0I fDUkbrZDtE9yt2fjvFBfChsHG2lSlA6QuP9tH9yybgabXIE2BTaCVuwRlwGwjF7AZfor cBkc9+XXEXxDJFWHaNyHDj0f9Alz8pz8009KiJltiXvDG+kvrBu440iatUkNevhlhRBY B+oB/VXmVujcDYUj551HUGJzg95Z+vk0oVcNIcUzjXJBKQKHmr3POO2Hw9lsJ31kFfah 4dcnFcgd88jKf5WNQYv67Yy3d6blvqbycrCoibHRb+9mJE1KaE1LhNaTJJ0i7vnID3ag Qj7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769427700; x=1770032500; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=NzX6jEIUs9cmuvsE+hialT1oG1nBlxW7ukQptAIUJa0=; b=fjtLaXLwYISTwq2XuEecr/ys92chzDWtXv5jazkzblzZm8rJV4x+1sB5zpmg+c8XBH X/8ExWrmf4eG75DvY4R7auFNXn0UR/NWFz0B6ANaTw++zKLAHddS5t+scIP/ZRzThvTy kQKB/upwVE3IvdLV/aOXGshc0OjvmAOVny62GfCuj6t6tiVFfh/WK3EuGAx9mxh1Fgsl Ty0D9ol4U8OGdgN2J0x3hfwLeiMLOwsb2TtOkPX7UtH1LqQypi6pC/8ap9M+31RCunPt 3LbRu8nnYY9ZAYJkUIEtetpBO8Xq3ZztjTH+9IWUQXu98XA5RfdmZ5f/LqYhHnE6QgzI czFg== X-Forwarded-Encrypted: i=1; AJvYcCVz3ObK6N7OKjFaqOOfL1CnTWDKTtb9nEgbD549u/1rIzdw1qT8jPWz1+uLGEMUiIM7THNbKhNsSt4=@lists.xenproject.org X-Gm-Message-State: AOJu0YzXylwYeoQ715EkXik8y1stDeLRGfb1da0bq4hE35DTWJ2lWXBi dzCncCN3HiJpj7aXm54FO16IH0NKYI9XoHqVq4xq+1j1c3bgMtnW+pLknDtTa1jK0g== X-Gm-Gg: AZuq6aIXrq+AgzPjBgChqbeKQ4oGZ3dUx26wjFvzf/1nz+8rBTTZ2WFLTfkBVI+/AlY FGwIDfccK5y+9DfA0FkZkeCB3r07kKoB1lwomUPIo848yLEgPR+/fLBmAhNtIwYqlkFNP9zi62y QYPI3FxYHHdIp6V5vj+IDeuPCBrxSD4xhRlbW+pzcX7CG2sYOR0iEJpcjSxw+vP1tsct1rIFiru YFhtgYCdxTSxF1DL5czy8o7/Jv9RSRuGnx+ROfZ8u6b7sFtcMaJKwOV/9R2uQlPlpSICv+M7i+h +xjanMy/QwRNwkb+Dt2lFlOB9lk8dPBlQv2Od21GjQKnTYNJIXMw9R8ZueVkpczy3Wp3OZHaiTE W/AzDzygDvpBjDkWsno4k5ZLy1+GG8XksTClm3yFg7Dt+k0MQkEJUCtLOXRhXoGUzTXQqN0Xnue Bwgaiqxn5R/irQq3r7FGJcXHS48MTDBXabFKkC6UtQLumFUDzveem+IC3zlGExlGGNSSXyh53zb dqDdmQLXwH6pw== X-Received: by 2002:a05:6000:2911:b0:3ec:db87:e5f4 with SMTP id ffacd0b85a97d-435ca122cd9mr6307716f8f.7.1769427699828; Mon, 26 Jan 2026 03:41:39 -0800 (PST) Message-ID: Date: Mon, 26 Jan 2026 12:41:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 01/16] xen/riscv: introduce struct arch_vcpu To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 22.01.2026 17:47, Oleksii Kurochko wrote: > --- a/xen/arch/riscv/include/asm/domain.h > +++ b/xen/arch/riscv/include/asm/domain.h > @@ -22,9 +22,62 @@ struct hvm_domain > struct arch_vcpu_io { > }; > > -struct arch_vcpu { > +struct arch_vcpu > +{ > struct vcpu_vmid vmid; > -}; > + > + /* > + * Callee saved registers for Xen's state deep in the callframe used to > + * switch from prev's stack to the next's stack during context switch. > + */ What is "deep in the callframe" intended to convey? I'm in particular wondering about ... > + struct > + { > + register_t s0; > + register_t s1; > + register_t s2; > + register_t s3; > + register_t s4; > + register_t s5; > + register_t s6; > + register_t s7; > + register_t s8; > + register_t s9; > + register_t s10; > + register_t s11; > + register_t sp; > + register_t gp; > + register_t ra; ... sp and ra, which presumably don't live anywhere "deep"? Also, what about tp? The 't' in there isn't the same as that in "t0", "t1", etc. > + } xen_saved_context; > + > + /* CSRs */ > + register_t hedeleg; > + register_t hideleg; > + register_t hvip; > + register_t hip; > + register_t hie; > + register_t hgeie; > + register_t henvcfg; > + register_t hcounteren; > + register_t htimedelta; > + register_t htval; > + register_t htinst; > + register_t hstateen0; > +#ifdef CONFIG_RISCV_32 > + register_t henvcfgh; > + register_t htimedeltah; > +#endif > + > + /* VCSRs */ Why the V? These are normal CSRs dedicated to VS use, aren't they? > + register_t vsstatus; > + register_t vsip; > + register_t vsie; > + register_t vstvec; > + register_t vsscratch; > + register_t vscause; > + register_t vstval; > + register_t vsatp; > + register_t vsepc; > +} __cacheline_aligned; I continue to question the presence of this attribute. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 26 11:43:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 11:43:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213631.1524083 (Exim 4.92) (envelope-from ) id 1vkL0O-0002yf-GD; Mon, 26 Jan 2026 11:43:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213631.1524083; Mon, 26 Jan 2026 11: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 1vkL0O-0002yY-DS; Mon, 26 Jan 2026 11:43:40 +0000 Received: by outflank-mailman (input) for mailman id 1213631; Mon, 26 Jan 2026 11:43:38 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkL0M-0002yN-Kn for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 11:43:38 +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 4062a77e-faac-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 12:43:37 +0100 (CET) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-b884ad1026cso688484166b.2 for ; Mon, 26 Jan 2026 03:43:37 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b886048e808sm605636566b.9.2026.01.26.03.43.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 03:43:35 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4062a77e-faac-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769427816; x=1770032616; 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=dg+tlIS5x3Bb6EkLB8EnYXAV8JB5eiuq9+HSsZDnooQ=; b=fJ5kTAjp+GTKwlGMuuH7OCXxBmI/4FtMmzdTZWX3CbYXrieglbCJQCLRElkfsvoZ0B bW1fgLd5RXIp1XP73wvAbZ09257LrDyfAtqilKn14ovlwwDEaKy7riqHfTrVEP/sMUrK j/Ti3vnPxwi/0SpkDMl/wUoe/AQkXAQHJKf+MzAVZ5JranOe5AwbMNXRsu7VQzPB40RW i2PUSIhI12URF7kcyLNuxGxwcMTY+JdgnK0dqVyo0hkajotOkryYECS7s08RJTIygMgt /907Q0hx5WEljG426Y73Ma5dQSYehAW5197IrSXwvopwDR0B0H3w15RNpyAVIBQtHYrN tLjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769427816; x=1770032616; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=dg+tlIS5x3Bb6EkLB8EnYXAV8JB5eiuq9+HSsZDnooQ=; b=prf7HSyai1wZA9gdWAv085LY5ZONz6EsZInL6i/rePXdG9ihT3ys42+MHVwtAjCFUU BOuIi5VZYxzqMxAEu6HnjsfnQfa3VbWOwdu3rq+xKXeBahFJU3DzzAEfWGUTfeuK2iEc ZP39CCT0gS9XTxNW1yaM2lusWbJhl8KSEo/2JfYopIKIYRiMALsqCte42R9yEF0ET9ZS q30i67w0Bcgcc2y79eikBkn6rIyuDQW1aQM/8ozkKp8aDwnB6ejNlNTAXpJm/2SPS5JN xAaUO/9e7PhZkOPMERkYjqgcPuk9H66SuJvjEudGCyzYm2BnJ4ZHEXPdFbCYFq7axdLh feXw== X-Gm-Message-State: AOJu0YzwsUH9nI7Bhz+b9jWn91KqAZ/t1Ab/K0vEcY0W/YZE+gbhBnsy mUy6hrvVkbCbiurr6w3tUVOpQQ9AIxXdJ/7T49HxRyQTU9HQmmS6B64oy5yatw== X-Gm-Gg: AZuq6aKskZTHofmYiymlv5a2F2wTPZ91do7Eza8TWsGDhvb4dINT5555+k9NE2GyikA 5fDrdqtyea1/aZlcV2qcFVo3X9GDTiGpTTEM9d7WYuwn7i9T6P1whZ+eTC0SKx5kbHfDnTyczYi kXOFNTUYqwjXUorbVmbm97oByTag2TX1gX+PNj3LMh9pV9fpC44CFWrMwVvczYN+DrwxpKo2snQ qhsSDdEymBTJ9P4Y+bZ6E4DHftqyw9xloqHLgED7oaAibmsVPPFDvyYTOLrEjyyXSCi6D5YeHt4 8U8SdP9f5ELFWAwgLgpvhTyRThidEId/28QpLF/f3iJaQTLjecup1riKb5VJdVhtWkQz295aNIq CEuBrNiOccUsGGYPndLMS3Uyu0AXLUXaWR76sjIt+XiWHMrkjipadzBcoYz4WUxm/h+EdJplZ7g +WRhAYwRSwWF7OZkxWXpRZBGgT/PLsrrvRJtpldkKNDt57l9U5jqwhcw== X-Received: by 2002:a17:906:c151:b0:b87:1d79:bef4 with SMTP id a640c23a62f3a-b8cfedfcaf5mr276192766b.9.1769427816036; Mon, 26 Jan 2026 03:43:36 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Romain Caritey Subject: [PATCH v4] xen/riscv: dump GPRs and CSRs on unexpected traps Date: Mon, 26 Jan 2026 12:43:25 +0100 Message-ID: <27ab0f8eb6fd6ecef1eeefa4a05e4fe1f43acbbe.1769427484.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Provide additional context when an unexpected exception occurs by dumping the relevant Supervisor, Virtual Supervisor (VS), and Hypervisor CSRs, along with the general-purpose registers associated with the trap. Dumping VS-mode CSRs in addition to host CSRs is beneficial when analysing VS-mode traps. VSCAUSE, VSEPC, VSTVAL, and related VS state are required to properly diagnose unexpected guest traps and potential hypervisor misconfiguration. For example, on an illegal-instruction exception the hardware may record the faulting instruction in VSTVAL. If VSTVAL is zero, VSEPC should always be inspected, and can be used together with objdump to identify the faulting instruction. Dumping VSCAUSE is also useful when the guest does not report it, or when the hypervisor redirects a trap to the guest using VSCAUSE, VSTATUS, and VSTVEC, allowing verification that a subsequent trap is not caused by incorrect VS state. Signed-off-by: Oleksii Kurochko --- Changes in v4: - Drop macros GPR_LIST and CSR_LIST. - Drop leading tab identation in printk() inside X macros. - Drop semicolon after printk in X macros. - Group print of htval and htinst, and HEDELEG and HIDELEG. - Put printing of hypervisor register first. - Add printing of missing GPRs: t5, t6, sepc. --- Changes in v3: - Refactor the code dumping of CSRs and GPRs: - Introduce new macros - Re-group some registers when values are displayed. - Print all registers name in lower case. - Drop unnessary "Dumping CSRs", "Dumping GSRs" as it is clear based on names. - Update the commit message: add justification of dumping of some VS* registers. - Drop printing of VSSATP as I don't know usecase for now where it could be needed. --- Changes in v2: - Address coments about print_csr() macros and dump_csrs(). - Add dumping of GPRs pertaining to the trap. --- xen/arch/riscv/traps.c | 58 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c index e9c967786312..da74f77ecc90 100644 --- a/xen/arch/riscv/traps.c +++ b/xen/arch/riscv/traps.c @@ -99,12 +99,70 @@ static const char *decode_cause(unsigned long cause) return decode_trap_cause(cause); } +static void dump_general_regs(const struct cpu_user_regs *regs) +{ +#define X(regs, name, delim) \ + printk("%-4s: %016lx" delim, #name, (regs)->name) + + X(regs, ra, " "); X(regs, sp, "\n"); + X(regs, gp, " "); X(regs, tp, "\n"); + X(regs, t0, " "); X(regs, t1, "\n"); + X(regs, t2, " "); X(regs, s0, "\n"); + X(regs, s1, " "); X(regs, a0, "\n"); + X(regs, a1, " "); X(regs, a2, "\n"); + X(regs, a3, " "); X(regs, a4, "\n"); + X(regs, a5, " "); X(regs, a6, "\n"); + X(regs, a7, " "); X(regs, s2, "\n"); + X(regs, s3, " "); X(regs, s4, "\n"); + X(regs, s5, " "); X(regs, s6, "\n"); + X(regs, s7, " "); X(regs, s8, "\n"); + X(regs, s9, " "); X(regs, s10, "\n"); + X(regs, s11, " "); X(regs, t3, "\n"); + X(regs, t4, " "); X(regs, t5, "\n"); + X(regs, t6, " "); X(regs, sepc, "\n"); + +#undef X +} + +static void dump_csrs(unsigned long cause) +{ +#define X(name, csr, fmt, ...) \ + v = csr_read(csr); \ + printk("%-10s: %016lx" fmt, #name, v, ##__VA_ARGS__) + + unsigned long v; + + X(htval, CSR_HTVAL, " "); X(htinst, CSR_HTINST, "\n"); + X(hedeleg, CSR_HEDELEG, " "); X(hideleg, CSR_HIDELEG, "\n"); + X(hstatus, CSR_HSTATUS, " [%s%s%s%s%s%s ]\n", + (v & HSTATUS_VTSR) ? " VTSR" : "", + (v & HSTATUS_VTVM) ? " VTVM" : "", + (v & HSTATUS_HU) ? " HU" : "", + (v & HSTATUS_SPVP) ? " SPVP" : "", + (v & HSTATUS_SPV) ? " SPV" : "", + (v & HSTATUS_GVA) ? " GVA" : ""); + X(hgatp, CSR_HGATP, "\n"); + X(hstateen0, CSR_HSTATEEN0, "\n"); + X(stvec, CSR_STVEC, " "); X(vstvec, CSR_VSTVEC, "\n"); + X(sepc, CSR_SEPC, " "); X(vsepc, CSR_VSEPC, "\n"); + X(stval, CSR_STVAL, " "); X(vstval, CSR_VSTVAL, "\n"); + X(status, CSR_SSTATUS, " "); X(vsstatus, CSR_VSSTATUS, "\n"); + X(satp, CSR_SATP, "\n"); + X(scause, CSR_SCAUSE, " [%s]\n", decode_cause(v)); + X(vscause, CSR_VSCAUSE, " [%s]\n", decode_cause(v)); + +#undef X +} + static void do_unexpected_trap(const struct cpu_user_regs *regs) { unsigned long cause = csr_read(CSR_SCAUSE); printk("Unhandled exception: %s\n", decode_cause(cause)); + dump_csrs(cause); + dump_general_regs(regs); + die(); } -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 11:47:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 11:47:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213642.1524093 (Exim 4.92) (envelope-from ) id 1vkL3y-0003Ys-UY; Mon, 26 Jan 2026 11:47:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213642.1524093; Mon, 26 Jan 2026 11: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 1vkL3y-0003Yl-Ru; Mon, 26 Jan 2026 11:47:22 +0000 Received: by outflank-mailman (input) for mailman id 1213642; Mon, 26 Jan 2026 11:47: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 1vkL3y-0003Yf-Eq for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 11:47:22 +0000 Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [2a00:1450:4864:20::435]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c5a6be27-faac-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 12:47:20 +0100 (CET) Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-42fb4eeb482so2973042f8f.0 for ; Mon, 26 Jan 2026 03:47:20 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1c30293sm30200691f8f.19.2026.01.26.03.47.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 03:47:19 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c5a6be27-faac-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769428040; x=1770032840; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=HTObMXn7wSRtyVd/M2UxW0yIkWZk2pIs1ewM2Lx12NI=; b=AMQZO0uBevw8RK7y5x/Zd3GWP98EMyK+kSiW92AZXWga0nTmabzVe80EH19vbG+T0k LxqDTKjHQRq3X5dRcxBs3eN/tTN5u2mgYbLKYxSAHenZ8CyUhL2bz3K+1+kasUqC8Mn0 T5+HxqGSGszEw4/7srOJeQoXoYBGNc96HTppDLpDV3r+aTCs2LpqvO+uo12DsPMQKECk FYDx744evPvTNglnxe3h96YV5c9cUDn11JLXyEzPZnCb+pt115CRw6BQ43kkmhZ+d1uq 9iOSvFcs2GY/rQywI8gkvzycPH/QPwD1kqFI4ZElfRZA5LSCx0mj21f8JAAEMM2nZTGm GUnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769428040; x=1770032840; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=HTObMXn7wSRtyVd/M2UxW0yIkWZk2pIs1ewM2Lx12NI=; b=CF/XhMKCuYaVJVSxzAt6lu3H/BWvIyMg1crUHv36pwRcdxLizYCcODZrJUJVwYcFTo PwvjNShIeTZjxSnxq6/vm2b+7sPX2YqdwsfV+NRYaIFCNVuPznL+64g39MqpcXX5zBvD qr6TMfO62W62eLoI2+QhxtwCpT1ePJAlVJmh/goMkUx058eeny1fg9LCVtp4MJQw12SE o79FkJFaSq1N/rSjaUh+I4Av0s+R7FxwjsAYDv5WCE/R+cNyxG0NbOhT+HN6MXczhs7g bnwJyGslhDD872IbiBVRzsV2QU+M9NZ3/1AD2XGOkEZAKDIViZqLWdWarrTGwywV5c+P 0rhQ== X-Forwarded-Encrypted: i=1; AJvYcCUOA2YnluZNisAyMQpgl2/6kSc9Ly8lqM8XZEGmNkxnvoVQOWIQFDmUBDYzVnPQhrhqkO86jjO+ZFw=@lists.xenproject.org X-Gm-Message-State: AOJu0Yximm4kadZE8tZwy9ZDxT7FjiRUiOtGcv0mWe7bLu3wSYVb9kmR cU37+oOnEMeIZ0ttPENcfoID8Cg/xRCkooF52wv2DhBQfD9vgBNUyLXwlqbtm6gs3g== X-Gm-Gg: AZuq6aK9M6YikB1mds6A17vcP84604E8QJP+TyEJk2lC6+TqJ7D3DlN/HkUSPBpX6IL 1nQkrXxUFkoKkinairIctINAH4wzrKAlmao2k6Wg4gjlSpTUiSYHyEHrg04A4wHFj3KDq4hTypS t3vDdEQg3X1NRR7BryE4AOZql0+XR8OKir4AwSnHPwnOMsN/Uou3tD955JIUaoVUouM/+09pb1D s+gbN1ge2i++PPmC3GIsdMQYkDRXoDpwl8qheBWjtMXrsPm9nzGY4WJBhUy6Rsqb8MVQYoYXw4p 7i0GAEVMLY8uo6eLHXi6vyWBw73q0xOO41pH8MbqwtHDDAvZtYJKtd8KgOkefT7dWPBCXsIOasb gDx9quG/YmcQ4pC7JJFwJigDzGQ5IlH6buRvgdop2sOY7V/BJdtfmZbEG1Cz1mb7Ow0nv+fq0Px nEzV64DAq8uXrGQ7H7VkvaiYbnguh/QSADyEG4K34JOQBbERZ3Iyn16+Pn7IDvhf7bS096e+dkc pwbx5+tNeDQVg== X-Received: by 2002:a05:6000:40cb:b0:432:4c01:db00 with SMTP id ffacd0b85a97d-435ca145762mr7288100f8f.27.1769428040062; Mon, 26 Jan 2026 03:47:20 -0800 (PST) Message-ID: Date: Mon, 26 Jan 2026 12:47:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 02/16] xen/riscv: implement arch_vcpu_{create,destroy}() To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , Teddy Astie , xen-devel@lists.xenproject.org References: <08b582179ebc4241140000972d89209c84c90fa4.1769099885.git.oleksii.kurochko@gmail.com> <4e2bf819-81f6-40f8-9bc3-c53aabf0967c@vates.tech> <06ee98c0-ec69-4955-a070-b0f611c8152e@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: <06ee98c0-ec69-4955-a070-b0f611c8152e@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 26.01.2026 10:00, Oleksii Kurochko wrote: > On 1/23/26 12:30 PM, Teddy Astie wrote: >> Le 22/01/2026 à 17:49, Oleksii Kurochko a écrit : >>> + v->arch.xen_saved_context.sp = (register_t)v->arch.cpu_info; >>> + v->arch.xen_saved_context.ra = (register_t)continue_new_vcpu; >>> + >> You probably also want to set the first parameter of continue_new_vcpu >> (struct vcpu *prev), or otherwise I don't think we want the "prev" >> parameter in continue_new_vcpu if it's always going to be 0. > > It will be set by RISC-V ABI (prev will be stored in a0) when __context_switch() > will be called in context_switch(): > void context_switch(struct vcpu *prev, struct vcpu *next) > { > ASSERT(local_irq_is_enabled()); > ASSERT(prev != next); > ASSERT(!vcpu_cpu_dirty(next)); > > local_irq_disable(); > > set_current(next); > > prev = __context_switch(prev, next); > > schedule_tail(prev); > } > First call of the __context_switch() will lead to jump to continue_new_vcpu() > function which will have a0=prev. Problem being that none of this code exists yet, and hence it's rather hard to see how things will eventually fit together. Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 26 11:58:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 11:58:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213655.1524103 (Exim 4.92) (envelope-from ) id 1vkLEq-0005YO-05; Mon, 26 Jan 2026 11:58:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213655.1524103; Mon, 26 Jan 2026 11:58:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkLEp-0005YH-TL; Mon, 26 Jan 2026 11:58:35 +0000 Received: by outflank-mailman (input) for mailman id 1213655; Mon, 26 Jan 2026 11:58: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 1vkLEo-0005Y5-Lr for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 11:58:34 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 54f571ca-faae-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 12:58:31 +0100 (CET) Received: from BN9PR03CA0695.namprd03.prod.outlook.com (2603:10b6:408:ef::10) 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.9542.16; Mon, 26 Jan 2026 11:58:25 +0000 Received: from BN1PEPF00004687.namprd05.prod.outlook.com (2603:10b6:408:ef:cafe::f8) by BN9PR03CA0695.outlook.office365.com (2603:10b6:408:ef::10) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.16 via Frontend Transport; Mon, 26 Jan 2026 11:58:31 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN1PEPF00004687.mail.protection.outlook.com (10.167.243.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Mon, 26 Jan 2026 11:58:24 +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, 26 Jan 2026 05:58:23 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 54f571ca-faae-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=yxZdf57qaaX3JPeBhS9RI5f6yDZIj0tYW/lD6juDGfcfQ+NwtxJGOqC4DPoNGuP2hKvGHPQ52eI1cK2XwWT+dpYLp03vEs9QhvkRtkWza4YnuT7eP2+AurjSUPm1DvnEMaJAVPPuXCC7jWLFB1DODTTGIM1sLrq0H8Le2WmDAqMCfOvqYIGuLF8H1fIC5lwsv7w+BEB1L4j4X3opuFhiO1SUI1SHl8ZXE9xpo38UCzs5Y9MknKHzForskMPgZ6kkqFY3UDcW/aWMtAIPKmSqm77wBTMef0DKGoH0DRhutddED50Y2X4A/w4hn9dRTjdUHIVqM0btyXpDLYefQoVR4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TUevsuTDbf9FYnKh0Wzu+PHkbCV5IiIcboPq0OF6msU=; b=VOna4eQqArOvF4//HgJ8Sl2pRfZki3iLUVUlWMfhc6JHNQuQn13wceKxzrG9nVbyP1pnFRIdlB0CWGm4DxmQMsgHR1C16q37FM1iqDQDLo5v3ekLmGlwe7VgwQivCTjjMl2Ti9tkFtYM7BdJVHAqQABc8rHCbUjzTHvhtAgqFj7H9r2NwPGcRZJDBDfBRFnmgSsE0f1v4wA22yzolyVLkmUcRllYxnm6iA+saoPFDKkkA6zU9AirHFRqxWvOGIPK0l/kucYeXC0CRr/EUaT2hINSO93YZpRRkzipOgKLax/kKN5D2XBTjTePIJGHPz22c3zz0Ld6oTVZSLeeweu2Lw== 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=TUevsuTDbf9FYnKh0Wzu+PHkbCV5IiIcboPq0OF6msU=; b=3UgHAjSHpzv1UaCnuMe2+SXmaApK5Els9tLyImbgIlu7B0SDPKMZFV7bCdedo8JyRbFTq9k/vrdqmHwMIrcP7ZKgrv3A3SeM2nibq/R2m0aWq8PdK+8GyLefn1En3cgQoB5zcIG57nOEDoE7wEaVtpkOO0hjjUVMucsgCWHZfjA= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 26 Jan 2026 12:58:21 +0100 Message-ID: CC: Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk Subject: Re: [PATCH 2/4] x86/hvm: Disable non-FEP cross-vendor handling in #UD handler From: Alejandro Vallejo To: Andrew Cooper , X-Mailer: aerc 0.20.1 References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <20260122164943.20691-3-alejandro.garciavallejo@amd.com> In-Reply-To: X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1PEPF00004687:EE_|BY5PR12MB4067:EE_ X-MS-Office365-Filtering-Correlation-Id: 9161785f-7a4d-473d-fe6f-08de5cd235ca X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|376014|1800799024|82310400026|18082099003; X-Microsoft-Antispam-Message-Info: =?utf-8?B?ZjBaTVByakw0QmNjNStmWU5DMmFFNUFuNXgzQlVHd0pMcFNPTHRML0YxSjBv?= =?utf-8?B?VEtWS3dpaVQ4SVRYeEVOdEZTT2RaSmY5MjJRNHlrVWs0ZmtzQ3NWZWJVZU13?= =?utf-8?B?RklXZTJNeHRHUkVZRlNidkljMGQ2eGw3Q3JyOEN1QjR4MDhSTjNRd1VyV1BX?= =?utf-8?B?aFJWUzdNaFJhVmdFWHhDRlhYT1pzUEhwbHd5bXU2WndKaHorOXdWZEU2NUk5?= =?utf-8?B?NXlmWU5PbjFMc1B2TTllRzlxM3kza3RYSXN2dXBOeEZuSytrNk5ZYUdrZFpy?= =?utf-8?B?VWRTY2NJTk1pZStPaWdIb3hhemp3ZlRaOUVxTEVuczlLZSt6aWVuaXdvZ2dI?= =?utf-8?B?YllENFFERjJFYTJSL2dzYzJ5MFEzWUVVakMrZUVJWVF5aGRWVzZaUXA5OUhs?= =?utf-8?B?U1ZIK2NseU1KQnNFTlczbVRvY1plZ0hMbE9xVjFMSzBkMEpSaXRiRyt0enZD?= =?utf-8?B?cHlPcTZrcDVhd2UzWXExV21nTVVvTGE4UFh1VlZOWkYxSGpuVTV6ZUNpWW1K?= =?utf-8?B?QWJXWFNxRThFL0tlYjVPYVAwNFZFMWUxS2RUYlhtbWlpTTZzS1JyTkNSNDdG?= =?utf-8?B?RkE3eFhWcytNZngvK3FqN3ZuaXVIZkd1SkxFbW1FTmV5UXpTRHJMRmlDeGt4?= =?utf-8?B?SFFmVlVlRWYwclBWaHF5SXJHcDJTN0owcDNkdnRlcGtJRm80d2hLZ1RvU0lS?= =?utf-8?B?R3BGL2xkYk1QZlNZMVlKN3RGaXV4WnpkOWRvTzVyWVR2UDhQbm1JcGFHSE1h?= =?utf-8?B?bTRtZ25uSVo0cjI4NmJHTGttcDh4Y1JjU0VuU0JuSHhteG5GRndFUHp5SUlv?= =?utf-8?B?N3IzcndSbXlJRE5YYlh0cUJ3Q0ZZa21qS3dvcFVWdWtRbVF6WWRITnpXZ002?= =?utf-8?B?MFBEMnp2WFVZSlE5NzdubWJRQUlNbkp5ZytmWnY5RWNiTXZKR1JXclk1aW4w?= =?utf-8?B?L0JRUlBBNFZyd2d4TUs3enBzMDJKTlZKaFNIY3UySC83RDhXSXZGSWFnR3lL?= =?utf-8?B?OWZjb3pSaUlFTmUvTVB0L3ZHdHYyVjZPT21YVHFhdXZNeUV0NXl4bTlHNFRF?= =?utf-8?B?dnJtYy9RNVdoSWc4bHIrK1BoWTNBbWkvcGRVaXpMd3pzemdIM2pSRVF4V2Ey?= =?utf-8?B?b0t1bnBTTkxScWNLNFROZEdjQ1d5b2ZxTWlFbEgxQ21rK0R2UzZJUWoxd0VL?= =?utf-8?B?S2VxeW02MUNjN3ppUStwbWFnYVBlVWtZWlViR0MzWTMyRWZ2WmUxbUFoNnBv?= =?utf-8?B?c0RMRURiL0ZrWWYrYXhtUVAwTHczYzdKNkcvdUNieExWQm9POVN4MngxMGd6?= =?utf-8?B?M3BWSFZwbWNrbkZSem01Q0pISDd0dlI3Z2Q4and6a3JuMjdabzRQSVZRSXk3?= =?utf-8?B?cStWVytEaitwSURidlN1N1F4RlZNenBrdlFZNGkzS3VRMnIwVStHT2RGTHVl?= =?utf-8?B?RllaZytjVWZSa3pJU3FaRVN5N0NCc2dNNkZRZ3BndlptUVlsaEVNWmFNRXZP?= =?utf-8?B?WDRZOVpvajF5WFRWRmpIdWJDOWZ6Tm1oTWtZM0hwYzI3SWZjUHFCU2w1MFBF?= =?utf-8?B?a0IvMkpXcjJSaXpNMXNxM00vOERuMTRJK3AyZ1QvOFNiMENkSjkwb0NXOHVq?= =?utf-8?B?YWtIL21hV0xOUzRJN01ET3ZXK2tLWXNzRUpqOHZxUmU0VWh4VVhEZ0FVS2U5?= =?utf-8?B?bEd1cXlwSVI2dVlxNm41MjJVUVZlVDVVcE5jUjAxMW05b05HNm9CUG9CZEJr?= =?utf-8?B?NG1KWDE4dmxGdVpFczlQZG41TVcrdFplekI5T0E3V05IUFRzUkl6bmFna2JZ?= =?utf-8?B?c0ZFblpzZkVOQm5ienp5V3ZtL3ZLOVI2OG82emErNFNGQVYwam1sekt0WEcz?= =?utf-8?B?d3FNbkgvbkVOcitBdHVkeVo0ckhETmxPQ0luU1l4d1hkamhHTUlnQWYyZXYy?= =?utf-8?B?d0JKYXJ4QUxSTmYwSmVETkFoS0FsRTVLSnhOczZ3eVNwdklNOG0zZkw0MHhh?= =?utf-8?B?aUhvbE5JakpvV0NiSno0NWdBUUwvUEUzcnRDOUhxTWZ6VHNpcWhvSVExZGtX?= =?utf-8?B?VWtZQUVxejZkRkJnSUZKU0JxYUhncm1pT05BMkQ3YnYwRnFtbkFSN1BVWDg4?= =?utf-8?B?Ky9WSTVtMFBQWm9wbzRYTHExMTVGQ0xUY3hlY0NldTdkZ1hXYm5RVW40b0dt?= =?utf-8?B?WmV2amVOUkt5REpuQ0hlVTc1ckx3R0gvRUdWNlVOSllFUFk0VzVSQnI2aGVV?= =?utf-8?B?dDJnODMwZHJrWHA5WUpFQ0JQR0RRPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(376014)(1800799024)(82310400026)(18082099003);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2026 11:58:24.8149 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9161785f-7a4d-473d-fe6f-08de5cd235ca X-MS-Exchange-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: BN1PEPF00004687.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4067 On Fri Jan 23, 2026 at 7:40 PM CET, Andrew Cooper wrote: > On 22/01/2026 4:49 pm, Alejandro Vallejo wrote: >> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c >> index 40e4c71244..34e988ee61 100644 >> --- a/xen/arch/x86/hvm/vmx/vmx.c >> +++ b/xen/arch/x86/hvm/vmx/vmx.c >> @@ -797,8 +797,7 @@ static void cf_check vmx_cpuid_policy_changed(struct= vcpu *v) >> const struct cpu_policy *cp =3D v->domain->arch.cpu_policy; >> int rc =3D 0; >> =20 >> - if ( opt_hvm_fep || >> - (v->domain->arch.cpuid->x86_vendor !=3D boot_cpu_data.x86_vend= or) ) >> + if ( opt_hvm_fep ) >> v->arch.hvm.vmx.exception_bitmap |=3D (1U << X86_EXC_UD); >> else >> v->arch.hvm.vmx.exception_bitmap &=3D ~(1U << X86_EXC_UD); >> @@ -4576,6 +4575,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user= _regs *regs) >> /* Already handled above. */ >> break; >> case X86_EXC_UD: >> + BUG_ON(!IS_ENABLED(CONFIG_HVM_FEP)); >> TRACE(TRC_HVM_TRAP, vector); >> hvm_ud_intercept(regs); >> break; > > Again, nested virt makes this more complicated than to simply believe it > doesn't happen. How so? nested vmexits go on a separate function (nvmx_n2_vmexit_handler())= , which is purposefully dispatched earlier. This switch is strictly for non-n= ested exits or it would be all sorts of wrong for other reasons. Either (non-nested) #UD does happen, in which case I want to know how. Or it doesn't, in which case we have dead code. Both cannot be simultaneously true. The #UD handler is (after the should_emulate fixup) just doing FEP an= d re-injecting otherwise. Whether there is an "otherwise" is relevant for the refactor and Teddy's rightful request. > > Also, more often than I'd like, I enable #UD interception for other > reasons, and I'd prefer that that doesn't get any harder than it does > right now. It's equally simple with hvm_fep=3D1 in the cmdline for an unmodified Xen (= to get the tracepoint). With a modified Xen it's a BUG_ON() removal, or runnin= g with HVM_FEP, which affects security but not performance (so it's ok for on= e-off tests). I could also conditionalise it to #ifndef CONFIG_DEBUG, as the overwhelming majority of the time you'll run your tests in debug mode. Do any of those options sound fine? Shipping a dead function to users/custo= mers because it's occasionally useful during development sounds like bad policy = to me. > > In an ideal world I'd have already upstreamed the logic to decompose > double/triple faults... Sorry, I'm afraid I don't follow what this ties in with. Is this why you fi= nd #UD interception helpful? Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Mon Jan 26 12:07:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 12:07:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213667.1524115 (Exim 4.92) (envelope-from ) id 1vkLNE-0007I6-T2; Mon, 26 Jan 2026 12:07:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213667.1524115; Mon, 26 Jan 2026 12:07:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkLNE-0007Hz-PR; Mon, 26 Jan 2026 12:07:16 +0000 Received: by outflank-mailman (input) for mailman id 1213667; Mon, 26 Jan 2026 12:07: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 1vkLND-0007Ho-36 for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 12:07:15 +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 8be1c392-faaf-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 13:07:12 +0100 (CET) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-65063a95558so6021834a12.0 for ; Mon, 26 Jan 2026 04:07:12 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6584b3e054fsm5114119a12.7.2026.01.26.04.07.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 04:07:10 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8be1c392-faaf-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769429232; x=1770034032; 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=d8wchK+W2lB7PEDYwYz5sSFFjyA2cgiCgvkMuw+nG2I=; b=WKoTGfp2SJs23kqi+voqDi7RRQnkkCLnUiI8w4Fp5s0LVPWszsbO+dFyJ+m1LnnhaD SapF9YXQWLRgiLHbO3oaH9m4R8qmP1seGBRePmNOfAZqT+k2ilE+ZU+AUUbeKqPIBnfp zXN9EwDxWbEEbDxgR439zX8hWhF9wWbGyGnWK7nV6jNNowjlwySo8uQq2j2eaVQSEcKI RfEMVe/CRL7ey0V9KIV2GoRKHXIE+lUrOOkckhf3tKa5+9QFGyQjoNQhXOUA6Scf+3fa I1dEVfC68wHiOOZdd2GYhB5K+3SNiVb6jbTIBPSDPnR0vxVBYJtdN2V/Lsrdgc/jFsWN 6yCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769429232; x=1770034032; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=d8wchK+W2lB7PEDYwYz5sSFFjyA2cgiCgvkMuw+nG2I=; b=QkeycGVhfnXekNTXRmSRk1JxZxU38/HWQNQbk89xJivP7Dsye85YerpPdYtDFzFkj6 1964sAAbg6vtMVrmhS2kAnKgSzih+XZlHcH+XbUo6979EGbLbO86oBH8GaV5p8aVQ43E 9+A2N4xYqlYCzWgIjuKN1GzkOrrO+h5KeNV73EGIOmEpe57+U4qmk/IIzKLTX6hOi4YG xFV/0QABLiC5swskikn7bbhql+ksBfA5HsrPInSWmEnaNgsL0gtKn/NMZ+JFAX2lpfMM OV3gmEKElIaxBHTNwpfgWDR7yZYKNr4r98J8DLRR9W/DwxvePqhpPVf8zBG38/wQkJGZ b2mQ== X-Forwarded-Encrypted: i=1; AJvYcCUlN/jBwDARRUX14CR0g0vsmTSNwcp3ejMHcB6+oXKd8PByvtY37+FX7K/x1GvaW6C7jbSbzaM0U1g=@lists.xenproject.org X-Gm-Message-State: AOJu0YyTvhFGO3Ox7koD2vt8Uv0zC/LVunWix8WQD6thayIXIEhUIUHZ okmPX1qJI2vvRelmG9qOtMWo47r9er8G4VpJj17e43GxKYH9lmQ03g+j X-Gm-Gg: AZuq6aLpYoJtSiKBzKlQgC0R1jD2tbd+gJf3xYrTNWmAOdmXs8vEsGBkW3eRGXkZQWN HJ4BFeefm0jOBmcAE9M/FfbVsmD5GAnqr3yBPsNY6cOEbPqAp26OPV3dRKd8SrbJ2ULayPsf1pp S4D0tYDTEwGZNblXNwLN3pmnpY92mWd958/7Y5MwZuh93VTlQ7h5jiat8gXUtgp2VqZAehUoVTH UIm5K932kDesAR3xlapUfROo8iUBP/NO4noRCkM5L15bvp0kcJZB22pnXfIWreS6ph1+UsjhgPf uYes9AY413YepeupSVNrkMDWphylTSyogJlO441SZ4GA+krSky0zS/dyNVfdoc6SuajncUqN5mV UdqxEg+v9vT1NElB6YWxjiMXfS/ofJqUVmbuvrjSxNYXle7GoismTUBMcwVI5Yf0krLFjNzDsKn Y3DRzD71zhNy19oP4Y09epxLFP+gm0pZxQnRJt/weDfoxuFaJaVfvC11kqTLlcCIg= X-Received: by 2002:a05:6402:3547:b0:658:1a41:13c with SMTP id 4fb4d7f45d1cf-6587068091dmr2498022a12.1.1769429231339; Mon, 26 Jan 2026 04:07:11 -0800 (PST) Message-ID: <72ea419e-c864-48f2-82a7-a4e0aaeb9551@gmail.com> Date: Mon, 26 Jan 2026 13:07:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 02/16] xen/riscv: implement arch_vcpu_{create,destroy}() To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , Teddy Astie , xen-devel@lists.xenproject.org References: <08b582179ebc4241140000972d89209c84c90fa4.1769099885.git.oleksii.kurochko@gmail.com> <4e2bf819-81f6-40f8-9bc3-c53aabf0967c@vates.tech> <06ee98c0-ec69-4955-a070-b0f611c8152e@gmail.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 1/26/26 12:47 PM, Jan Beulich wrote: > On 26.01.2026 10:00, Oleksii Kurochko wrote: >> On 1/23/26 12:30 PM, Teddy Astie wrote: >>> Le 22/01/2026 à 17:49, Oleksii Kurochko a écrit : >>>> + v->arch.xen_saved_context.sp = (register_t)v->arch.cpu_info; >>>> + v->arch.xen_saved_context.ra = (register_t)continue_new_vcpu; >>>> + >>> You probably also want to set the first parameter of continue_new_vcpu >>> (struct vcpu *prev), or otherwise I don't think we want the "prev" >>> parameter in continue_new_vcpu if it's always going to be 0. >> It will be set by RISC-V ABI (prev will be stored in a0) when __context_switch() >> will be called in context_switch(): >> void context_switch(struct vcpu *prev, struct vcpu *next) >> { >> ASSERT(local_irq_is_enabled()); >> ASSERT(prev != next); >> ASSERT(!vcpu_cpu_dirty(next)); >> >> local_irq_disable(); >> >> set_current(next); >> >> prev = __context_switch(prev, next); >> >> schedule_tail(prev); >> } >> First call of the __context_switch() will lead to jump to continue_new_vcpu() >> function which will have a0=prev. > Problem being that none of this code exists yet, and hence it's rather hard to > see how things will eventually fit together. I am trying to avoid a large patch series, and this needs to be introduced before we can implement context_switch(). At the moment, I'm trying to introduce everything that I need for dom0less domain creation and context_switch() isn't really needed at this stage and continue_to_new_vcpu() isn't really needed to be implemented at this stage as well as context_switch(). The best I can do at the moment is either to write a better commit message explaining how this will be used, or, specifically for continue_new_vcpu(), to avoid introducing it for now and not initialise the ra register until the remaining pieces are ready. But considering that I've already done in this way then better commit message(s) should work. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Jan 26 12:31:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 12:31:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213685.1524144 (Exim 4.92) (envelope-from ) id 1vkLk7-0003D4-Qg; Mon, 26 Jan 2026 12:30:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213685.1524144; Mon, 26 Jan 2026 12: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 1vkLk7-0003Cx-Nz; Mon, 26 Jan 2026 12:30:55 +0000 Received: by outflank-mailman (input) for mailman id 1213685; Mon, 26 Jan 2026 12: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 1vkLk6-0003Cr-1q for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 12:30:54 +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 d9f4e3b0-fab2-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 13:30:51 +0100 (CET) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-6505d3adc3aso5889066a12.1 for ; Mon, 26 Jan 2026 04:30:51 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b885b419642sm631794466b.28.2026.01.26.04.30.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 04:30:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d9f4e3b0-fab2-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769430651; x=1770035451; 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=EyildIuXxv/uG9YHlNUGiziuUzm2zMO0Buecs/Heoz8=; b=XXSmocMugVn8lPobBSD4PZmOmK3BUYeFyGPL5oZ32afYWL59ihbR7HDqspJVKJWXB7 a7igBr20k+zOr+U6RtDXnHQf7VTwVMhOSl01jr3JAu8L31u0jcjXZ3eN9ycBplSkOhuc 0xUmhVhsquTeZ57NleNSJFWwITIXiZ/ZfJL7sv2h1W3hZ7LJa5gx4RtYSc2KYt+3amGY rVPk+4KD2aMupBCLMZRh6KOa9GuNld1n6YV6XklCIC0HJHvk5rDCsUAI1/2ErKlvQWlq gpp7LT7W8an4e+6eNi6kyDYbvBzH5gDIJwxaXNOFZWal6zwwEPavPDwd6sRV5E0FWNGM Bxjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769430651; x=1770035451; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EyildIuXxv/uG9YHlNUGiziuUzm2zMO0Buecs/Heoz8=; b=YK+4fS3pL5aaEmKwX4Ue91Hae+IEJYSAcI7qpqDeHYo/NerikYxhw3P04AG3MoNhIp AH6nkKfAAJjnXRjS9qFboFBn1FgJK8cCkaNBkWRbx4YSOSUrZNWi3iev5R74ITMGxoE/ 9t122WWfTD5DCmkOKNMe73nAMjJKqafn6J/vE/n7yOj3QQ+NX0r2QSfHCPSMvbnAJM6r WIuxrftJUDotIV5VcHhf8pDERgOORa06NR5BrcD1dKcQlYhwCaQAw5erYePwsIh4YrCQ C8M8WmFZIoKNfG8/NSVw8vBLdKyMU37jiQkCG7ePnZc/YgYU1jxpd4V0Efu9IHMr/tG1 G/iA== X-Forwarded-Encrypted: i=1; AJvYcCX6jzl49e3Q6T8N35YRyw0tI/Tp2GkNrot/2Ft4+WhHUYGjr3Awf0bb/KF62n5U0QZsSNqC0RTVCWA=@lists.xenproject.org X-Gm-Message-State: AOJu0YxpJ1ckFS62VNIFLZUG3PJQeSat0cNLBTfYFHxytn1gYUby2skU gnovd14XYonlZGORMF1lwqvdoG1Dz+FE4LLi5VfwELrdRlmkpjMMAASy X-Gm-Gg: AZuq6aIwdUbs24BAMMPEKy+cjy3UUFh7USsqlxH+B7o7gXBD375S3RmpKMttKWBbChl ToG3dVqG5fqAJSlpeXU/vMPtGXspRWdBpLxRomCXHuDjtDn+CZRjh7WczXGNYjjCbHoAPDYBgiF Czx4NFcFwixCqSWlLfGLorSu4cqk0rkYG3ympPNFV00uTggdMMgvrTEUIjSS86BwQCBdYbQSC2L k3k2Zu/I+6K6jxND0L7QlHX4mCUZEUQrajAuBi7oIRdXMwUOuGe8T7wmgR9b8NwZ2ps1fH0EGuD 8gRlYy0LsErSnvvSQbwQ3YSpBTNgoBUY5sa3vJmF0LI1FOt+JgZI5FLCOhRAp1627lYTJNE9BAJ W/n3NFC5CwNFoWbo9EBZ+84oeGNP7U9aYaK8U6Pdo8Bys/ZhQm1KXqIkZ2GWqYHXzi9MlMJ1/mC RXTpM9WpPrFfeXF5uQtcMPffXQDT/yTguRi03h232BmnN5z31bLchqOFuG9H6rsWU= X-Received: by 2002:a17:906:c14c:b0:b76:8164:88b5 with SMTP id a640c23a62f3a-b8d2e841f12mr317774666b.46.1769430650926; Mon, 26 Jan 2026 04:30:50 -0800 (PST) Message-ID: <20f2bf2c-9b28-4a60-ad35-9640f5d3dfad@gmail.com> Date: Mon, 26 Jan 2026 13:30:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 01/16] xen/riscv: introduce struct arch_vcpu To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/26/26 12:41 PM, Jan Beulich wrote: > On 22.01.2026 17:47, Oleksii Kurochko wrote: >> --- a/xen/arch/riscv/include/asm/domain.h >> +++ b/xen/arch/riscv/include/asm/domain.h >> @@ -22,9 +22,62 @@ struct hvm_domain >> struct arch_vcpu_io { >> }; >> >> -struct arch_vcpu { >> +struct arch_vcpu >> +{ >> struct vcpu_vmid vmid; >> -}; >> + >> + /* >> + * Callee saved registers for Xen's state deep in the callframe used to >> + * switch from prev's stack to the next's stack during context switch. >> + */ > What is "deep in the callframe" intended to convey? I'm in particular wondering > about ... > >> + struct >> + { >> + register_t s0; >> + register_t s1; >> + register_t s2; >> + register_t s3; >> + register_t s4; >> + register_t s5; >> + register_t s6; >> + register_t s7; >> + register_t s8; >> + register_t s9; >> + register_t s10; >> + register_t s11; >> + register_t sp; >> + register_t gp; >> + register_t ra; > ... sp and ra, which presumably don't live anywhere "deep"? context_switch() is invoked relatively deep in the call stack, so the stack pointer in use when context_switch() executes can also be considered to be deep in the call frame. The same applies to RA: after the first __context_switch() call, RA will point to the next instruction within context_switch(). I can update the comment and drop the wording about being “deep in the call frame” to avoid confusion. In that case it would simply read: + /* + * Callee saved registers for Xen's state used to + * switch from prev's stack to the next's stack during context switch. + */ > > Also, what about tp? The 't' in there isn't the same as that in "t0", "t1", etc. tp stores pcpu_info[] and it isn't expected to be changed during (or between) function calls. In this structure we are dealing only with registers which should be saved according to RISC-V ABI convention: [1] https://riscv-non-isa.github.io/riscv-elf-psabi-doc/#_integer_register_convention The exception is for RA (as it is also used to jump to continue_to_new_vcpu() when vcpu is scheduled first time). During a review of the [1], I think that GP could be dropped as it shouldn't be preserved across calls. > >> + } xen_saved_context; >> + >> + /* CSRs */ >> + register_t hedeleg; >> + register_t hideleg; >> + register_t hvip; >> + register_t hip; >> + register_t hie; >> + register_t hgeie; >> + register_t henvcfg; >> + register_t hcounteren; >> + register_t htimedelta; >> + register_t htval; >> + register_t htinst; >> + register_t hstateen0; >> +#ifdef CONFIG_RISCV_32 >> + register_t henvcfgh; >> + register_t htimedeltah; >> +#endif >> + >> + /* VCSRs */ > Why the V? These are normal CSRs dedicated to VS use, aren't they? I meant VSCSRs, yes, it is normal CSRs dedicated to VS use. I'll drop the comment as from the name it is clear that VS-mode CSRs. > >> + register_t vsstatus; >> + register_t vsip; >> + register_t vsie; >> + register_t vstvec; >> + register_t vsscratch; >> + register_t vscause; >> + register_t vstval; >> + register_t vsatp; >> + register_t vsepc; >> +} __cacheline_aligned; > I continue to question the presence of this attribute. I will drop it until I could really measure that it boosts performance. At the moment, it is just an assumption. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Jan 26 12:53:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 12:53:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213697.1524153 (Exim 4.92) (envelope-from ) id 1vkM61-0006Ep-Hw; Mon, 26 Jan 2026 12:53:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213697.1524153; Mon, 26 Jan 2026 12: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 1vkM61-0006Ei-Ez; Mon, 26 Jan 2026 12:53:33 +0000 Received: by outflank-mailman (input) for mailman id 1213697; Mon, 26 Jan 2026 12:53:33 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkM60-0006Ec-V9 for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 12:53:32 +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 0434b4b0-fab6-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 13:53:31 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-47ee07570deso34381845e9.1 for ; Mon, 26 Jan 2026 04:53:31 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804d3ac45bsm105533585e9.0.2026.01.26.04.53.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 04:53:30 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0434b4b0-fab6-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769432010; x=1770036810; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=6dfNLf+Mng9Xxc2Z1v5rxAG2bJG15U5JQJu59tUp/Uk=; b=bnIC+FqFu3aBbKFW+VQVox4B4SLlPLVj3sNCW+CsgkiedVy34rN+4vGLPuvgZhgvag 5qaCBR2PV60EY80yvEV6+5uNflc1SPhoo62jfsi/gRSbKjj+yaFcy7P/DHVLzTFqg2Wm iEKLaWiN2jSq3NRWTsneUoBQ7s/4UPEXDrqyqqn2hjyBbNhlFtlWbrbJGZTOEo/kTYpw ewdNPztcL3rYwhVyvJW1rXRYiFwNo0SrzEdXndrHpPQKF4G11Mhv1hbimxffraYj1nha ol9Mijs/55IQjvndyynUWRv6nFUhBKLhtV6oXshHslFDUW3UtQiEk/hNLkdwWd7uevW4 9BPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769432010; x=1770036810; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6dfNLf+Mng9Xxc2Z1v5rxAG2bJG15U5JQJu59tUp/Uk=; b=SAPYevmBElYA7ocacdBuXEnNdN3oFFXaHGcjArZDaWL6Ad5D68k+Ckf94TBt7mStMv y2Tmqacu8ETv1Hg8NeRsuMSU2S2QFF09ufVnDMxCr7uv8YkjpVi2moikSOleV6kzVcgN DmjWRO1XZ4c0JceeNNai7mQ2R2NNYJqlcOq+cNAsEqMkPxsoQ7vgE1Q4AClC+oy8xvWd oqtaXvs1MxckuOUI9AXLBVZ+PcX4VmapQbjOYubmcieGDktBYVteCSQR9MfYLeLlaM9n Zu99EK7at1E5omZieyuDyc+CbX4XS8qPpDs7XtkupB+nhrJlXcx31vHhgz+ImoomuUgB gJcw== X-Forwarded-Encrypted: i=1; AJvYcCXxp+7iNcQIOrNjwbA8dHwrrfpzSoP/sYo7+6Po8t67jp1OjBnR5WmdXIjfGECXZfPBB5APmB7og5M=@lists.xenproject.org X-Gm-Message-State: AOJu0YyFJ57MpxxuetQkxlIe+AJcX2ZMG6Jgw/PSF0XMKdVLKfvj3QC0 ZvGvjm4vFg8JJEOWRQOomnB7buEKcGN8w060hV+6oya/MYK6u3QP4KAsnGVezW2G4Q== X-Gm-Gg: AZuq6aLnj2NW9pC7RpHvR7J3JrQMF5FS/kR5YG0q1YwFlEC0f0FfSm1KJPJgFP34hAn z4PSd2HH2t3qlyeNNnJU9Hn44///CDWXEzOld+xWUfTAvOB9iMqtrlmzAVEW+Vm6IMqRt+QlMRD C5k1JERA4ftrighiLp2rRBQw5d0zHGC5Y1NKFZ4G3Sn1tCzWdAv/rjUJQTQwB33NEpY20FrBhQW SHFIy5XA/q3xR0lt56Qd+4oeUiTNgxUSVJWyYyOafhxAJNX1vYrAawhJuX4w5FzpqziqYTq7hXl eaPN2ktvPBqNV4qG/6VqlKaGJi0Ll9XouQcS87RlG56Wyq/2O2u5/nxy5Xfo3owt3hLRPFW+3PY 6M9p6HqSbsZ+lswCpeWtcp+nWI5HBWsNqtlpIlU7rn8Xfumx8vOWOHzKV+Tnd5Ll1CvQhpmY70z pIJrTOlogydOgaJPYUji7zwZdbQBRc3CTcRmJjUCB3RFP9JSuG7V2ksNP3T/kHXuIWEu3HZocHU VMet1ufhRZNDw== X-Received: by 2002:a05:600c:470e:b0:459:db7b:988e with SMTP id 5b1f17b1804b1-4805ce3fc24mr67358625e9.13.1769432010519; Mon, 26 Jan 2026 04:53:30 -0800 (PST) Message-ID: <784293fc-f8f2-45da-b9dc-169fec5b9ddb@suse.com> Date: Mon, 26 Jan 2026 13:53:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 01/16] xen/riscv: introduce struct arch_vcpu To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <20f2bf2c-9b28-4a60-ad35-9640f5d3dfad@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: <20f2bf2c-9b28-4a60-ad35-9640f5d3dfad@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 26.01.2026 13:30, Oleksii Kurochko wrote: > On 1/26/26 12:41 PM, Jan Beulich wrote: >> On 22.01.2026 17:47, Oleksii Kurochko wrote: >>> --- a/xen/arch/riscv/include/asm/domain.h >>> +++ b/xen/arch/riscv/include/asm/domain.h >>> @@ -22,9 +22,62 @@ struct hvm_domain >>> struct arch_vcpu_io { >>> }; >>> >>> -struct arch_vcpu { >>> +struct arch_vcpu >>> +{ >>> struct vcpu_vmid vmid; >>> -}; >>> + >>> + /* >>> + * Callee saved registers for Xen's state deep in the callframe used to >>> + * switch from prev's stack to the next's stack during context switch. >>> + */ >> What is "deep in the callframe" intended to convey? I'm in particular wondering >> about ... >> >>> + struct >>> + { >>> + register_t s0; >>> + register_t s1; >>> + register_t s2; >>> + register_t s3; >>> + register_t s4; >>> + register_t s5; >>> + register_t s6; >>> + register_t s7; >>> + register_t s8; >>> + register_t s9; >>> + register_t s10; >>> + register_t s11; >>> + register_t sp; >>> + register_t gp; >>> + register_t ra; >> ... sp and ra, which presumably don't live anywhere "deep"? > > context_switch() is invoked relatively deep in the call stack, so the stack > pointer in use when context_switch() executes can also be considered to be > deep in the call frame. The same applies to RA: after the first > __context_switch() call, RA will point to the next instruction within > context_switch(). While writing, did you maybe notice that "deep" can have two entirely distinct meanings here? It could be "far from where the stack starts when we enter the hypervisor" or "far from present top of stack". > I can update the comment and drop the wording about being “deep in the call > frame” to avoid confusion. In that case it would simply read: > > + /* > + * Callee saved registers for Xen's state used to > + * switch from prev's stack to the next's stack during context switch. > + */ Yes please. >> Also, what about tp? The 't' in there isn't the same as that in "t0", "t1", etc. > > tp stores pcpu_info[] and it isn't expected to be changed during (or between) function > calls. Oh, right, I forgot about that aspect. However, the more that you reference ... > In this structure we are dealing only with registers which should be saved according > to RISC-V ABI convention: > [1] https://riscv-non-isa.github.io/riscv-elf-psabi-doc/#_integer_register_convention > The exception is for RA (as it is also used to jump to continue_to_new_vcpu() when vcpu is scheduled > first time). During a review of the [1], I think that GP could be dropped as it shouldn't > be preserved across calls. ... this - why would gp then need saving? That ought to be stable across Xen as well (or not be used at all)? Jan From xen-devel-bounces@lists.xenproject.org Mon Jan 26 13:35:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 13:35:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213711.1524183 (Exim 4.92) (envelope-from ) id 1vkMkc-0003Dh-Nd; Mon, 26 Jan 2026 13:35:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213711.1524183; Mon, 26 Jan 2026 13:35: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 1vkMkc-0003Da-KX; Mon, 26 Jan 2026 13:35:30 +0000 Received: by outflank-mailman (input) for mailman id 1213711; Mon, 26 Jan 2026 13:35: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 1vkMkb-0003DU-6V for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 13:35:29 +0000 Received: from out28-100.mail.aliyun.com (out28-100.mail.aliyun.com [115.124.28.100]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id dac7d4c8-fabb-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 14:35:21 +0100 (CET) Received: from localhost(mailfrom:houwenlong.hwl@antgroup.com fp:SMTPD_---.gGHqk0X_1769434515 cluster:ay29) by smtp.aliyun-inc.com; Mon, 26 Jan 2026 21:35:16 +0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dac7d4c8-fabb-11f0-b15f-2bf370ae4941 DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=antgroup.com; s=default; t=1769434518; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=EUFZPihEfz/fncyKdMh9AsZHIUnCljxK4T+gNK+kZwk=; b=gMwNPKSRoWPqvorcUyrIHEplhefn4xaX3686NBbqfptrokbf3WECTxggZ86GW2v1jn2GfbkOxRA2Fzcb7jSHpJM9dnpE0GNcsHyunGg40IO3qg6H3O6fjd9eyhbjoWqjT+Dz4irJkfBsmAH2tRVmiXk1G+aZ0ufu1OpmFKdqWNk= From: Hou Wenlong To: linux-kernel@vger.kernel.org Cc: Lai Jiangshan , Hou Wenlong , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Boris Ostrovsky , Ard Biesheuvel , Nathan Chancellor , Masahiro Yamada , Vitaly Kuznetsov , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , Brian Gerst , Josh Poimboeuf , Andrew Morton , Alexander Graf , Joel Granados , Thomas Huth , Uros Bizjak , Kiryl Shutsemau , Pawan Gupta , Guenter Roeck , "Xin Li (Intel)" , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , xen-devel@lists.xenproject.org Subject: [RFC PATCH 0/5] x86/boot: Allow to perform randomization for uncompressed kernel image Date: Mon, 26 Jan 2026 21:33:50 +0800 Message-Id: X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi all, This RFC patch series introduces relocatable uncompressed kernel image, which is allowed to perform kerenl image virtual address randomization in 64-bit booting entry instead of decompression phase. - Background Currently, kernel image virtual address randomization is only performed during the decompression phase. However, in certain scenarios, such as secure container environments (e.g., Kata Containers), to speed up the boot process, the system may boot directly from an uncompressed kernel image. In such cases, virtual address randomization cannot be executed. Although the security enhancement provided by KASLR is limited, there is still a potential demand to allow uncompressed kernel images to perform virtual address randomization (for example, future support for x86 PIE). - Approaches Currently, the x86 kernel uses static compilation, but it retains relocation information through the '--emit-relocs' option, which is then simplified into a relocation table using 'relocs' tool. To enable virtual address randomization for uncompressed kernel images, relocation information is required, and there are several possible approaches: 1) Who will perform the randomization: VMM: The VMM reads vmlinux.relocs after loading vmlinux to perform randomization. This would require additional modifications to the VMM, and vmlinux.relocs needs to be packaged when shipping. Kernel: The kernel performs randomization itself at the kernel entry point, requiring no modifications to the VMM. 2) relocation information format: vmlinux.relocs: It only contains the necessary relocation entries and is simplified, making it small enough. However, it is a format defined within the kernel that was previously used only internally and is not part of the ABI. rela.* sections: It is the standard ELF ABI, but it contains RIP-relative relocation entries, which are more common in kernel, causing the kernel image to be larger. - Implementation The final implementation of this plan extends the 'relocs' tool to allow the insertion of relocation information into a reserved section of the kernel (referencing the MIPS implementation). This enables the reading of that information and subsequent execution of relocations when booting directly from an uncompressed kernel. Currently, this implementation is only available for 64-bit and has been tested with both PVH entry booting and standard 64-bit Linux entry. And the default reserve size is 1MB for now, which is enough for defconfig. - TODO Clean up the decompression KASLR code to allow it to be shared with the booting phase. Thanks! Hou Wenlong (5): x86/relocs: Cleanup cmdline options x86/relocs: Insert relocations into input file x86: Allow to build relocatable uncompressed kernel binary x86/boot: Perform virtual address relocation in kernel entry x86/boot: Use '.data.relocs' section for performing relocations during decompression arch/x86/Kconfig | 20 ++++++ arch/x86/Makefile.postlink | 33 +++++++++ arch/x86/boot/compressed/Makefile | 6 +- arch/x86/boot/compressed/misc.c | 8 +++ arch/x86/boot/startup/Makefile | 1 + arch/x86/boot/startup/kaslr.c | 116 ++++++++++++++++++++++++++++++ arch/x86/include/asm/setup.h | 1 + arch/x86/kernel/head_64.S | 7 ++ arch/x86/kernel/vmlinux.lds.S | 20 ++++++ arch/x86/lib/cmdline.c | 6 ++ arch/x86/lib/kaslr.c | 5 ++ arch/x86/platform/pvh/head.S | 15 +++- arch/x86/tools/relocs.c | 64 ++++++++++++++--- arch/x86/tools/relocs.h | 15 ++-- arch/x86/tools/relocs_common.c | 24 ++++--- 15 files changed, 309 insertions(+), 32 deletions(-) create mode 100644 arch/x86/Makefile.postlink create mode 100644 arch/x86/boot/startup/kaslr.c -- 2.31.1 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 13:36:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 13:36:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213720.1524193 (Exim 4.92) (envelope-from ) id 1vkMlK-0003iB-4C; Mon, 26 Jan 2026 13:36:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213720.1524193; Mon, 26 Jan 2026 13: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 1vkMlK-0003i4-1A; Mon, 26 Jan 2026 13:36:14 +0000 Received: by outflank-mailman (input) for mailman id 1213720; Mon, 26 Jan 2026 13:36: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 1vkMlI-0003VU-GW for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 13:36:12 +0000 Received: from out28-52.mail.aliyun.com (out28-52.mail.aliyun.com [115.124.28.52]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f6e9401c-fabb-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 14:36:08 +0100 (CET) Received: from localhost(mailfrom:houwenlong.hwl@antgroup.com fp:SMTPD_---.gGID1nH_1769434562 cluster:ay29) by smtp.aliyun-inc.com; Mon, 26 Jan 2026 21:36:03 +0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f6e9401c-fabb-11f0-9ccf-f158ae23cfc8 DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=antgroup.com; s=default; t=1769434565; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=VyKxMTwvBHUzyW1uTW736L2GPVuIiSygzDpiTrPhWW8=; b=Iwk6WT3ax7dZYFr2LpsKXdh+MDYo1dBQLcy/P/FOeFykpsga67y6uySmOjRlnTDyxmC5lxmjJSk/2Od51rVv7fUPF2giChSQbtzJt+N+5JIjJ2zPy9rZ7s6aD0D94AWHj38LoqVTvtjXuabu+x5A7SK1gnAnPP6TJdlH2ci3P0c= From: Hou Wenlong To: linux-kernel@vger.kernel.org Cc: Lai Jiangshan , Hou Wenlong , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juergen Gross , Boris Ostrovsky , Ard Biesheuvel , Josh Poimboeuf , Nathan Chancellor , Andrew Morton , Alexander Graf , Joel Granados , Thomas Huth , Uros Bizjak , Brian Gerst , Kiryl Shutsemau , "Xin Li (Intel)" , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , xen-devel@lists.xenproject.org Subject: [RFC PATCH 4/5] x86/boot: Perform virtual address relocation in kernel entry Date: Mon, 26 Jan 2026 21:33:54 +0800 Message-Id: X-Mailer: git-send-email 2.31.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Perform virtual address relocation for the uncompressed kernel during booting, which is similar to the relocation during decompression. Signed-off-by: Hou Wenlong --- arch/x86/boot/startup/Makefile | 1 + arch/x86/boot/startup/kaslr.c | 116 +++++++++++++++++++++++++++++++++ arch/x86/include/asm/setup.h | 1 + arch/x86/kernel/head_64.S | 7 ++ arch/x86/lib/cmdline.c | 6 ++ arch/x86/lib/kaslr.c | 5 ++ arch/x86/platform/pvh/head.S | 15 ++++- 7 files changed, 148 insertions(+), 3 deletions(-) create mode 100644 arch/x86/boot/startup/kaslr.c diff --git a/arch/x86/boot/startup/Makefile b/arch/x86/boot/startup/Makefile index 5e499cfb29b5..eeaefa4e25fb 100644 --- a/arch/x86/boot/startup/Makefile +++ b/arch/x86/boot/startup/Makefile @@ -20,6 +20,7 @@ KCOV_INSTRUMENT := n obj-$(CONFIG_X86_64) += gdt_idt.o map_kernel.o obj-$(CONFIG_AMD_MEM_ENCRYPT) += sme.o sev-startup.o +obj-$(CONFIG_RELOCATABLE_UNCOMPRESSED_KERNEL) += kaslr.o pi-objs := $(patsubst %.o,$(obj)/%.o,$(obj-y)) lib-$(CONFIG_X86_64) += la57toggle.o diff --git a/arch/x86/boot/startup/kaslr.c b/arch/x86/boot/startup/kaslr.c new file mode 100644 index 000000000000..fb07c31e21b3 --- /dev/null +++ b/arch/x86/boot/startup/kaslr.c @@ -0,0 +1,116 @@ +// SPDX-License-Identifier: GPL-2.0 + +#include +#include + +/* A hack to avoid non-static declaration for kaslr_get_random_long(). */ +#define _ASM_KASLR_H_ +#include +#include +#include + +extern char __relocation_end[]; + +static struct boot_params *boot_params_ptr __initdata; + +static inline void debug_putstr(const char *str) +{ +} + +static inline bool has_cpuflag(int flag) +{ + u32 reg = 0; + u32 level = native_cpuid_eax(0x0); + + if (level >= 0x00000001) { + if (flag == X86_FEATURE_RDRAND) + reg = native_cpuid_edx(0x1); + else if (flag == X86_FEATURE_TSC) + reg = native_cpuid_ecx(0x1); + } + + return test_bit(flag & 31, (unsigned long *)®); +} + +static unsigned long __init rotate_xor(unsigned long hash, const void *area, + size_t size) +{ + size_t i; + unsigned long *ptr = (unsigned long *)area; + + for (i = 0; i < size / sizeof(hash); i++) { + /* Rotate by odd number of bits and XOR. */ + hash = (hash << ((sizeof(hash) * 8) - 7)) | (hash >> 7); + hash ^= ptr[i]; + } + + return hash; +} + +/* Attempt to create a simple but unpredictable starting entropy. */ +static unsigned long get_boot_seed(void) +{ + unsigned long hash = 0; + + hash = rotate_xor(hash, boot_params_ptr, sizeof(*boot_params_ptr)); + + return hash; +} + +#define KASLR_COMPRESSED_BOOT +#define KASLR_FUNC_PREFIX static __init +#include "../../lib/kaslr.c" + +/* A hack to avoid non-static declaration for cmdline_find_option_bool(). */ +#define _ASM_X86_CMDLINE_H +#undef CONFIG_CMDLINE_BOOL +#define builtin_cmdline NULL +#define CMDLINE_FUNC_PREFIX static __maybe_unused __init +#include "../../lib/cmdline.c" + +static unsigned long __init find_random_virt_addr(unsigned long minimum, + unsigned long image_size) +{ + unsigned long slots, random_addr; + + /* + * There are how many CONFIG_PHYSICAL_ALIGN-sized slots + * that can hold image_size within the range of minimum to + * KERNEL_IMAGE_SIZE? + */ + slots = 1 + (KERNEL_IMAGE_SIZE - minimum - image_size) / CONFIG_PHYSICAL_ALIGN; + + random_addr = kaslr_get_random_long("Virtual") % slots; + + return random_addr * CONFIG_PHYSICAL_ALIGN + minimum; +} + +void __init __relocate_kernel(unsigned long p2v_offset, struct boot_params *bp) +{ + int *reloc = (int *)rip_rel_ptr(__relocation_end); + unsigned long image_size = rip_rel_ptr(_end) - rip_rel_ptr(_text); + unsigned long ptr, virt_addr, delta; + unsigned long cmd_line_ptr; + + /* If relocation has occurred during decompression, simply skip it. */ + if (bp->hdr.loadflags & KASLR_FLAG) + return; + + cmd_line_ptr = bp->hdr.cmd_line_ptr | ((u64)bp->ext_cmd_line_ptr << 32); + if (cmdline_find_option_bool((char *)cmd_line_ptr, "nokaslr")) + return; + + boot_params_ptr = bp; + virt_addr = find_random_virt_addr(LOAD_PHYSICAL_ADDR, image_size); + delta = virt_addr - LOAD_PHYSICAL_ADDR; + + for (reloc--; *reloc; reloc--) { + ptr = (unsigned long)(*reloc + p2v_offset); + *(uint32_t *)ptr += delta; + } + + for (reloc--; *reloc; reloc--) { + ptr = (unsigned long)(*reloc + p2v_offset); + *(uint64_t *)ptr += delta; + } +} diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h index 914eb32581c7..86a715a255a5 100644 --- a/arch/x86/include/asm/setup.h +++ b/arch/x86/include/asm/setup.h @@ -56,6 +56,7 @@ extern void startup_64_load_idt(void *vc_handler); extern void __pi_startup_64_load_idt(void *vc_handler); extern void early_setup_idt(void); extern void __init do_early_exception(struct pt_regs *regs, int trapnr); +extern void __init __relocate_kernel(unsigned long p2v_offset, struct boot_params *bp); #ifdef CONFIG_X86_INTEL_MID extern void x86_intel_mid_early_setup(void); diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S index 21816b48537c..868d8fdd59df 100644 --- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -97,6 +97,13 @@ SYM_CODE_START_NOALIGN(startup_64) /* Sanitize CPU configuration */ call verify_cpu +#ifdef CONFIG_RELOCATABLE_UNCOMPRESSED_KERNEL + leaq common_startup_64(%rip), %rdi + subq .Lcommon_startup_64(%rip), %rdi + movq %r15, %rsi + call __pi___relocate_kernel +#endif + /* * Derive the kernel's physical-to-virtual offset from the physical and * virtual addresses of common_startup_64(). diff --git a/arch/x86/lib/cmdline.c b/arch/x86/lib/cmdline.c index c65cd5550454..07c4398b9e67 100644 --- a/arch/x86/lib/cmdline.c +++ b/arch/x86/lib/cmdline.c @@ -11,6 +11,10 @@ #include #include +#ifndef CMDLINE_FUNC_PREFIX +#define CMDLINE_FUNC_PREFIX +#endif + static inline int myisspace(u8 c) { return c <= ' '; /* Close enough approximation */ @@ -205,6 +209,7 @@ __cmdline_find_option(const char *cmdline, int max_cmdline_size, return len; } +CMDLINE_FUNC_PREFIX int cmdline_find_option_bool(const char *cmdline, const char *option) { int ret; @@ -219,6 +224,7 @@ int cmdline_find_option_bool(const char *cmdline, const char *option) return ret; } +CMDLINE_FUNC_PREFIX int cmdline_find_option(const char *cmdline, const char *option, char *buffer, int bufsize) { diff --git a/arch/x86/lib/kaslr.c b/arch/x86/lib/kaslr.c index 8c7cd115b484..711a19729e20 100644 --- a/arch/x86/lib/kaslr.c +++ b/arch/x86/lib/kaslr.c @@ -13,6 +13,10 @@ #include #include +#ifndef KASLR_FUNC_PREFIX +#define KASLR_FUNC_PREFIX +#endif + /* * When built for the regular kernel, several functions need to be stubbed out * or changed to their regular kernel equivalent. @@ -46,6 +50,7 @@ static inline u16 i8254(void) return timer; } +KASLR_FUNC_PREFIX unsigned long kaslr_get_random_long(const char *purpose) { #ifdef CONFIG_X86_64 diff --git a/arch/x86/platform/pvh/head.S b/arch/x86/platform/pvh/head.S index 344030c1a81d..94832930b0a2 100644 --- a/arch/x86/platform/pvh/head.S +++ b/arch/x86/platform/pvh/head.S @@ -103,6 +103,17 @@ SYM_CODE_START(pvh_start_xen) btsl $_EFER_LME, %eax wrmsr + /* + * Fill the identity mapping entries instead of preconstructing them, + * as later relocations in __relocation_kernel() would modify them and + * break the mapping if they are prefilled, due to the generation of + * relocation entries. + */ + leal rva(pvh_init_top_pgt)(%ebp), %edi + addl $(pvh_level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC), (%edi) + leal rva(pvh_level3_ident_pgt)(%ebp), %edi + addl $(pvh_level2_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC), (%edi) + /* * Reuse the non-relocatable symbol emitted for the ELF note to * subtract the build time physical address of pvh_start_xen() from @@ -254,7 +265,6 @@ SYM_DATA_END_LABEL(early_stack, SYM_L_LOCAL, early_stack_end) * startup_64 transitions to init_top_pgt. */ SYM_DATA_START_PAGE_ALIGNED(pvh_init_top_pgt) - .quad pvh_level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC .org pvh_init_top_pgt + L4_PAGE_OFFSET * 8, 0 .quad pvh_level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC .org pvh_init_top_pgt + L4_START_KERNEL * 8, 0 @@ -263,8 +273,7 @@ SYM_DATA_START_PAGE_ALIGNED(pvh_init_top_pgt) SYM_DATA_END(pvh_init_top_pgt) SYM_DATA_START_PAGE_ALIGNED(pvh_level3_ident_pgt) - .quad pvh_level2_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC - .fill 511, 8, 0 + .fill 512, 8, 0 SYM_DATA_END(pvh_level3_ident_pgt) SYM_DATA_START_PAGE_ALIGNED(pvh_level2_ident_pgt) /* -- 2.31.1 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 14:22:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 14:22:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213741.1524205 (Exim 4.92) (envelope-from ) id 1vkNUG-0001ZX-De; Mon, 26 Jan 2026 14:22:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213741.1524205; Mon, 26 Jan 2026 14: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 1vkNUG-0001ZQ-A0; Mon, 26 Jan 2026 14:22:40 +0000 Received: by outflank-mailman (input) for mailman id 1213741; Mon, 26 Jan 2026 14:22: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 1vkNUE-0001ZI-Pm for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 14:22:38 +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 75fdbb42-fac2-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 15:22:36 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-47ee3a63300so52139955e9.2 for ; Mon, 26 Jan 2026 06:22:36 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48047028928sm494765095e9.2.2026.01.26.06.22.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 06:22:34 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 75fdbb42-fac2-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769437355; x=1770042155; 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=xyLIdOBp6AU4BlIShM9uNytZkKTMXaNAPLGwGfwBgZ4=; b=hIaMND1LMflkQP1N2iKUEbsNzwrN5g/iWT++RE6Q0R5YXPv0mcbG1MCodDEypouNFp PoLMV17mH6n9+Sv4uGYh2mu/FaS3ylLydk0/ledryt6T5CLZCsyHrNVDAec/9lTsi9vd 3ONL0I5En1HgnKLGY1cKJJKHhyqaa9y7zFIVkqzUDioe6qn2jb/Xvx3WSW5T8Y+F5mXi anJWIF5emeezJu3jDyRzefLN6mXRBmcC6ycVIqXiHVekdPvt1b1O4IKkEL5VnnFURqS1 z+qnMl8RI2O+uV3uRMeM7vRNF8EhmvFVgeyCQolv3NWxSqLzgT6DvUE0wfziUBFn4rMU cR5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769437355; x=1770042155; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xyLIdOBp6AU4BlIShM9uNytZkKTMXaNAPLGwGfwBgZ4=; b=WKsiqmJnBca5NEqRUxKij95R5ULMH/HVhjfm7/zb5Ieoe0ej3CGRx8Uu6ukS5/phIL TaA37KDtSQRu5Z9r6CfNgcxbNi2xfxSRWlAFN0eieo0pMCHXIO5eeKbDXfNSGj3Z1IeW r6jH3/grhC8sYJExkNKGUhUaKiWAyIVw3H1oGMRqil0okiclhoP88ujBUlNEzyVs6cdh XBOo9adhTSsxky25At4DNZas+M4eMaNldk8pM904/rKa9X5/w7gXVTBFT71ZuFAsEVV1 GHkYVLGMus8l/fcNXR9uH8QH1VHCJDbYECbodIPQvPDtU9vhwZaNCD8z+Jb2fu9KhFN1 OEQg== X-Forwarded-Encrypted: i=1; AJvYcCXn9hVAd1wvjaLbu08XBEvwbVFBRzELXejYer5g61uE8OR8CrxpKyaktGNQr+HzeA7LKJyjYZAuiYo=@lists.xenproject.org X-Gm-Message-State: AOJu0YwA0FuEKw5ZDb0y3QnrzGuHS+dwN4K7UqWB3xHS6qwaRc8ThPjb iIEQ7gd3PvmP199UTZWkT1s10Isw80SyNyRvrpan+3XFDIBkvssE7tGm X-Gm-Gg: AZuq6aJB0sfaDCuQcEpsORTHJUwTW+z0uuYA4FP8LziPRMGQZcGqpcP1oPL2GUM6OAN t89LfIiYOEf20weeGpSd2SfXlc6HLlq6IpsZb1F/9s6R3MEhaLi3Kw/bBbJHJv/p2gSK3N5SrIH q36ddMVJvfuJR8hQ4Hru8/rk/o1QSOTrsidnb57Zijm7Q8Ua9Q52UQIpnY+FFQjrpCNEC8+mNNZ u3sOP5NKrTU8KvtdLXPUA1X+TaPi2gTSS0n0imHAjrupiGZWyNYyjW6ld7Ebl3w2hcP5L7a5Tfp d1uZruBpUp3qKkSmspcvqbPmwHpZmJRLfSrlFjDxXbAh5bRc8VfDVB4soyn2x4bMV/ByMWL91Sz KO9HHw0d9DKjBnVFatyLdZqvmQ+nYU5pzPuoELadDgKKA0sq2mwLhC7olKGlNAQhL2T4xbetz2M ibGQ3MG8NEHpNVckqm3g1PIi219k3TYIKyo2i5u9Ugm/ieW2UFlSkgcw/we6rDxXoFpwc= X-Received: by 2002:a05:600c:4f8e:b0:477:b642:9dc1 with SMTP id 5b1f17b1804b1-4805cf669d1mr66585265e9.20.1769437355209; Mon, 26 Jan 2026 06:22:35 -0800 (PST) Message-ID: <1a447de4-2083-40e0-9b6a-07df707100eb@gmail.com> Date: Mon, 26 Jan 2026 15:22:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 01/16] xen/riscv: introduce struct arch_vcpu To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <20f2bf2c-9b28-4a60-ad35-9640f5d3dfad@gmail.com> <784293fc-f8f2-45da-b9dc-169fec5b9ddb@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <784293fc-f8f2-45da-b9dc-169fec5b9ddb@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/26/26 1:53 PM, Jan Beulich wrote: > On 26.01.2026 13:30, Oleksii Kurochko wrote: >> On 1/26/26 12:41 PM, Jan Beulich wrote: >>> On 22.01.2026 17:47, Oleksii Kurochko wrote: >>>> --- a/xen/arch/riscv/include/asm/domain.h >>>> +++ b/xen/arch/riscv/include/asm/domain.h >>>> @@ -22,9 +22,62 @@ struct hvm_domain >>>> struct arch_vcpu_io { >>>> }; >>>> >>>> -struct arch_vcpu { >>>> +struct arch_vcpu >>>> +{ >>>> struct vcpu_vmid vmid; >>>> -}; >>>> + >>>> + /* >>>> + * Callee saved registers for Xen's state deep in the callframe used to >>>> + * switch from prev's stack to the next's stack during context switch. >>>> + */ >>> What is "deep in the callframe" intended to convey? I'm in particular wondering >>> about ... >>> >>>> + struct >>>> + { >>>> + register_t s0; >>>> + register_t s1; >>>> + register_t s2; >>>> + register_t s3; >>>> + register_t s4; >>>> + register_t s5; >>>> + register_t s6; >>>> + register_t s7; >>>> + register_t s8; >>>> + register_t s9; >>>> + register_t s10; >>>> + register_t s11; >>>> + register_t sp; >>>> + register_t gp; >>>> + register_t ra; >>> ... sp and ra, which presumably don't live anywhere "deep"? >> context_switch() is invoked relatively deep in the call stack, so the stack >> pointer in use when context_switch() executes can also be considered to be >> deep in the call frame. The same applies to RA: after the first >> __context_switch() call, RA will point to the next instruction within >> context_switch(). > While writing, did you maybe notice that "deep" can have two entirely distinct > meanings here? It could be "far from where the stack starts when we enter the > hypervisor" or "far from present top of stack". Yeah, but at time when I was writing the commit I thought only about one meaning "far from where the stack starts when we enter the hypervisor". > >> I can update the comment and drop the wording about being “deep in the call >> frame” to avoid confusion. In that case it would simply read: >> >> + /* >> + * Callee saved registers for Xen's state used to >> + * switch from prev's stack to the next's stack during context switch. >> + */ > Yes please. > >>> Also, what about tp? The 't' in there isn't the same as that in "t0", "t1", etc. >> tp stores pcpu_info[] and it isn't expected to be changed during (or between) function >> calls. > Oh, right, I forgot about that aspect. However, the more that you reference ... > >> In this structure we are dealing only with registers which should be saved according >> to RISC-V ABI convention: >> [1] https://riscv-non-isa.github.io/riscv-elf-psabi-doc/#_integer_register_convention >> The exception is for RA (as it is also used to jump to continue_to_new_vcpu() when vcpu is scheduled >> first time). During a review of the [1], I think that GP could be dropped as it shouldn't >> be preserved across calls. > ... this - why would gp then need saving? That ought to be stable across Xen as > well (or not be used at all)? Totally agree, that why I mentioned in reply that it could (it would be better if "must/should" were used) be dropped as it shouldn't be preserved across calls and as you also notice that it ought to be stable across Xen as well (or not be used at all). ~ Oleksii From xen-devel-bounces@lists.xenproject.org Mon Jan 26 14:31:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 14:31:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213752.1524214 (Exim 4.92) (envelope-from ) id 1vkNcm-0003Dq-6M; Mon, 26 Jan 2026 14:31:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213752.1524214; Mon, 26 Jan 2026 14:31:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkNcm-0003Dj-2t; Mon, 26 Jan 2026 14:31:28 +0000 Received: by outflank-mailman (input) for mailman id 1213752; Mon, 26 Jan 2026 14: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 1vkNcl-0003Dc-3Y for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 14:31:27 +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 b0e67d97-fac3-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 15:31:24 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by AM7PR03MB6452.eurprd03.prod.outlook.com (2603:10a6:20b:1c2::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Mon, 26 Jan 2026 14:31:02 +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.9542.010; Mon, 26 Jan 2026 14:31:02 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b0e67d97-fac3-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Oc9xzUZvDl+O3xQhyYCCWMGqUt/VRMthQmWlM7NzsIkrbrEj+9kr4DNjwJoSq5s/VaF4nNK1aIEe46qPkJJAh03UG6qwvKAgc8uKvoyVBHscGlbk6wJT6vJ2XIhewfa6ZZl8LSszUef/uYj6HRjqy7fyq6H3DcKacsdAnp6b34RdZVzF+BiIVGlphy7CesHXTOsOTaRVrHHKXIPMDcb/20h8tGM1mCBkD2FNTYmxqKG9n4aG490BrcuG92EILeziAhEiXRFQ2oxihDgcx27tYeoZX6HfVNBYK6YTJ9xk5u+Z7szYD5CPVM7LxYfRNooch33vVckgyfuc4tzgL5LXRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zneMmoVMj1X1i3l98nRNSZVy0dfs74YhMs6wew+SDrc=; b=FU0qACP68eJVTLxjREhh6dK/tZPQNVdrGi/xfPVCfot1F0lx6DDtlvbD2BUsJxwk49PmoO1v0pU5AirXCdChhmfeRZc5m8RZI3czh4BbiZpIYgDBUVmDULX761+qgTVc1YGhTVwuiIvnksi4i//Ic9yOhgztLJaP4LmIbyl94bVF9dBcfnpE9g4xMv4Dp4medDC2e03SBIggEvSqJpa1niqWD564zOcUC/+2ThxWpKGT5MfJSYd5InxYlchUlqM5/mtT/kF4GT6GnlJyCcpQsBHg4qMEP2+bMcbPKXXD0C9KMufV/1RIaC2ht1FjBok30cKf/EVvAjqsYMDChgfNoA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zneMmoVMj1X1i3l98nRNSZVy0dfs74YhMs6wew+SDrc=; b=LGj31zjY2DRpTkJOTGXMpQ8dxTPhVH/5HCNU5RYmIDehTU6qMnHS9UrmPSRRcEf54zG93kftqRcgfhUg1KT4kIyPHyRcnlXqXLPDy1fZx+WL6OiqwWRvYUnXFZ4NVKMOIjATAyxDEw2fGgYc/uvsIz7WXPNi0d+UjfxhSToJJyFqwEpaNPqmYqjVj/mpJJ7ncz1K6s/809/XqoRMckJc9RBSUsbZ7mJZgBRhYEz2S9wSQK1ruZcmaoFG12leiLundaPvKRPO9bz9NzpjCPVcWmVWVIEMgF+mje1G2pA96W/+3/4t3Uws+3lqiBHXk6Fbkubp6oNV9NB1BQWZi50Mqg== From: Oleksii Moisieiev To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v8 1/5] xen/domctl: chain SCI handling before IOMMU in assign_device domctl Thread-Topic: [PATCH v8 1/5] xen/domctl: chain SCI handling before IOMMU in assign_device domctl Thread-Index: AQHciwXk/uoXY0zPp0qUEySvGl6zVLVd0bMAgAZ1k4CAAAIlgIAAQWcA Date: Mon, 26 Jan 2026 14:31:01 +0000 Message-ID: References: <8482f823e945060d1a36469f14f94aa6251e3f71.1769020872.git.oleksii_moisieiev@epam.com> <114d2326-112b-41ea-8c32-12b785f8e7a0@suse.com> <0df180b2-1e9b-4dfd-b2a9-cbe9b805d114@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_|AM7PR03MB6452:EE_ x-ms-office365-filtering-correlation-id: e10fc720-2553-4f97-877f-08de5ce787d8 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|366016|38070700021; x-microsoft-antispam-message-info: =?utf-8?B?ZGV5US9YMitjQmxobWFzQ0lEQTVRcVFYMFJqNnJNWXhOZmFlditJYWJRT0lH?= =?utf-8?B?UnRlSU0rTGFNUWx4MldDU3NUMXl5VDZlNDJaSWFUZk4yYlkycU1vd3l2Rmlm?= =?utf-8?B?ZVRodk85SzN0UzNuR0NqK29GeWV4dVJKdnhWUTkwNFBVclJ2SjArbVBmWWhP?= =?utf-8?B?MTBycHliRVQ3OE5OK09pcmZIWDdCcVVwRlpJeUpXZzdGcUJQaUpQbGpyTFVq?= =?utf-8?B?Y3NqUHQ4c2xFdjJnWkRaZGRZWmN4QllrdjR1K2dseXhybXpqekFWZThIQVYx?= =?utf-8?B?aVErOXRYVnBTOUVBMEtJUGxsT01Kd1BBTnZWc2tUMDF2SU9DWklVSTRyc2ZO?= =?utf-8?B?WGlna1FIM0RndllDOXk5K0hQR05NaGpra3ByMS9EM2JnOThqOTRpcFdoejQx?= =?utf-8?B?cTdZNmpycTFtd25MemVsNHhVWWxvZ01ZRzRIMnJ3d2pCNll3ZTZPQndPYzVG?= =?utf-8?B?STVSRlNsZFplNW83TWNYZnJXTFJ1Qy83MjI3TThzVUpCYkoxK3lKcWtrRWJa?= =?utf-8?B?QkJ3OWFXSHQ2MEF6cFRIeFJMV3krV25ybHkvVlp2ZmJ1YWtwVjJIeThtMHNw?= =?utf-8?B?S3JNbXNHbWpickw5NTErNDhUSi9INkdWYjBBM29vWU8rRnJtSFdMTUlNZjFm?= =?utf-8?B?Z3o5TWlaaHVjNEJOdzBZVEw2a0E2ZU9odmNUS2ZFeEFabythdUZMSnpWU0oy?= =?utf-8?B?OGgxSytGMW9pTjBiVXk0UUt3RllQaGwzcm9qTURBamorZ3NHZWxZL3JaZ3hM?= =?utf-8?B?TndlUlM1aitwTWgzMDAvNjdGTlM1UU9Qb1dweG4wVU9BS0hQcXVVcEdXaUZT?= =?utf-8?B?d1RSMmx4SGVDWHRCMFhCcnNZTWlkeTFoK1ViWnplNWhUN0VvNlJvcmNFWTd5?= =?utf-8?B?ZTByLzdBeU9FRUgzbmZtMSs1OUx1QVZidjUwN095Qld4Z20zTlhBVGJXY2R3?= =?utf-8?B?TzdjdmpyMCtoVW5jdDd4STE3V2pQNmZ3U25nWWp5Kzc3UFA4a1lYUElvRWJz?= =?utf-8?B?UDRUQ2VKWkYrYTRyT3luekMzT2ZmdDBLSUtvNGtob25rdFRCdE1KL2M3UUJa?= =?utf-8?B?T2NDUkx2T3ZOL3pSblE0dlltc2NtOHl5RVBXeGljMnl0anpNNXlKYk54ajZw?= =?utf-8?B?UTc2U0ptcHl5Zk4yaWFZdm5pQ3hvVEZVeUZvazNlSll5REREVmdlbnZrVy9U?= =?utf-8?B?ZEVvTy94aVdVNHVjdFc0WDl4K0cxT1B2VEg3VmdJb2tqbzZ2Mm5xamVaWEJ0?= =?utf-8?B?SGRtRHNkOWFGOUZjTTY2WnFQU0ltQ2VpTEFNYmNqMTBDclFLWVFQZm50SUZi?= =?utf-8?B?TjJJYnZVTkFHQVVod3lQR2xmaG5kczF5RDJQaTFxczg5bEhrelRyWXNnM2hj?= =?utf-8?B?NXdiZGY1VXpTcjg0SFFSQXY4UW5NdXBoaGhVSHhSWkpFRlpSQkJHSVVvK3pt?= =?utf-8?B?dm9CRGJnR3hBN1NlbWhJaGhsbzdxeHdqNkUvZEZkN1V4anJyV1JDY1UrTFZs?= =?utf-8?B?NFVRUjNSUjNHdHNmSjRUb0pxbXB4Tzk3MkQrS0crNjR5VU5VTURNY0dvbEVj?= =?utf-8?B?aTJrWXVibkVGQnpoak1NOFdTZTQ3amxBV0twYmZ3cW1kL2ZmMDkwdXZEZjhK?= =?utf-8?B?RW51WjlKN2xlYzlOSEJUdTRXdE8vSlB0WFNwalRKNU1EOVZZMU5mZDl3a0Fu?= =?utf-8?B?SGxJUklyd2NRUklua3BJS3JQMllJWXZhcEdYNEtNNktKaCt5MHZlbzgzK29N?= =?utf-8?B?VlVEWGR4MTVzRGQ4OFVIejNJK2dyMGNJMTlDRWhFc3hndmlKZ0pNdXBXTEdW?= =?utf-8?B?OHBXTVljQkUyUjMxVUkxQ1NHcFhheklJayt1UXBkZ0s3Y2o5RXFyN1FFd2NN?= =?utf-8?B?QkdRWEpQdnZjMWNaSmcwajV4aVROaWw1Vm9tUXJEbERPSmxyYzJ3VklRdjND?= =?utf-8?B?STZnMXhNTnZLbHFTK1VudmJwbE1jaEI0Y01FbGlmUy80UGFIOFQ5NTA1YURk?= =?utf-8?B?VVR0aHlSczcrbDUvRmo1OXRvazlNc2hMWFQ0cGlKWitOSHQ2MWZyUmg4bVZt?= =?utf-8?B?NFRXOUVZbWxtN0RRUEE3V3JSZzYzc3hkdkFwZU4yVEFyOXR4VnR4Q2p5cURj?= =?utf-8?B?UFJnSmNtb0ZPUHdZclcwOHlvNmpEeTk3VHlXTnZnWGR3T3FPczhOZDBMQnNs?= =?utf-8?Q?8JSy/FGlsTbqdf29mBfZ75U=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dzZsNWhyaVh3UTJUWXBpSEtFeGdRLzYybE8yaWZRN3ZndkRDUnlJcGJHMmhD?= =?utf-8?B?WjhET3pkZmJaVU9ZM3FYVnI1Z2VLYzFuQkNVVURWTW5PQUlvbjEvSGJReEdq?= =?utf-8?B?ZmcwL01nK2cyc3A1a1Z3WkhTLzZMWkJhZUNna3Y4SVhGbWVkRzUrcFhxemU5?= =?utf-8?B?YVhxdURJanBtVEs1Q1k3Yzdna01SWUVxYnhvaDRydGZMZjNwTWt1QlJyNDlU?= =?utf-8?B?Y0w1VTllc3F2d2N1QVlqWkRUME5UamdUeGJ6cVI1dGE5Qm1HOXhRMWo3SDFo?= =?utf-8?B?QWduSmZ2RDN6ZUFLWHh1eXdld2Fxb1A1NzZzSDl6bnNKU2NnVGtha0tOTFFa?= =?utf-8?B?TVArRmlmUHZRTVZMdExTQkZJdktxMVN1N09CTlljK3NvUkpaNTJTbk9jcmNJ?= =?utf-8?B?Z0MxSHNxbnhvSUErekVWY25mSmxGenVjWGEyM09SYWxkMUg5T2N5MkVtaDlp?= =?utf-8?B?KzRPenJVZFBBc2QrdTRNeXVNeUNwU0hyNTVNNGZtYVFjenVwUWR4QXp1NFMr?= =?utf-8?B?R1pjL2ZGTGFYdm81N3ZhYkxHOXlTWUVPTmVRTGMybnNCelA4YXpWTjQ1SnlG?= =?utf-8?B?WXpndDU2dnNCZUpkUzg3MzdmcmlRSnBseU1EeldDemUwemdjQ1FFd1lmT21s?= =?utf-8?B?UW1uZmZ0cEtsdTcyQ3hoS3RqZ1hINXhUK3NvaEJ3NlFlSXYwYk5aK1ZXaWky?= =?utf-8?B?ZXlIdGU3VEpKY1puK2ZOZ3VXbFEwZ04zRVcrWXVoRHVGNnBndHhaanZiYXJj?= =?utf-8?B?WVg3bFVuaWNtMk02YzZ2cUR5R0lzUHhFL09LdlJETkV6UHZXMTFSK29Damhh?= =?utf-8?B?eUFYWkkzcmtVYUl3cnBNNTJOUFR4UEZ6N2tEcGdsUFZpTTlLejEraHh1RHRQ?= =?utf-8?B?WWpIK2JONjhHcDQ2eTBWdVhHNzloeHp5eW01Qy9sQ0E5d1hsbSt5c3hRNmRU?= =?utf-8?B?TkpML3BRUzZyWlZwS3k4TWcrblBnRER0eHphazlUa1ozL2N5SncwVENoUGFF?= =?utf-8?B?aGs3Q0tDNVF4cHNPUmZva2h4TEtOcVFIUFNyaWwvK1U1Rzd1SlNnRHBxZ1h1?= =?utf-8?B?UU9FSVU1K1RIalROb2Q2blYxbE9VU2lCSG1LT1hXZUo1cm9GMUJtQjhPZzZD?= =?utf-8?B?VzREc2htczE0M3UwUkdSNWtKRlBTOUF2MjRFemtuUUZYY0FTSHlhTTc5Vjlm?= =?utf-8?B?RVV5WHQ4VE41dVJvOXpiR0wvak5aSTlzRS9rS3JwdFNwcSs1S0JZcUJRbVA4?= =?utf-8?B?M3ZUcTgyUC9PY01NZEM1TkZIZUJCTDU1b05wNGZ4KzQwTEFiUml0eWFkOWlI?= =?utf-8?B?QlVzVjBRM3VSNGYrcHlhU3NuZ3BqR21qdGJoQ0JMWCtVUjhudzFQYkxESndy?= =?utf-8?B?a08rNVp3NVo4TjBCMnJHRjg3ODdaeDlzamkyU3NyTlVac3RMOVBxNXFuTjND?= =?utf-8?B?STN1QmpxdDhRajkvM3VEeWVZNzVsemIwTW9PbFFlOHVtckpUVmdWR29paFRs?= =?utf-8?B?NTQ2UjgxbWM1M1Y2MlI4d29tS25SMnFWQi9FaDgzMUpMb0ZUTzFYVEZFSDhk?= =?utf-8?B?UXlYa1oyZ0t1VnNrVCtvVmZuamxucmdxaFZYZXJRd1RSWGIrR0tEZnRYQ3BO?= =?utf-8?B?OGhCL2RUSkdaeW9XeVBOS3dNTEpuVW1wMlFVQ3ArLzlOTXhubko1UkU5bEJD?= =?utf-8?B?T29TNkl3eS9YOUZpaCtoVDZ0MzRNZzl0WmFnTVZKbUJUclUzWXR6WlU5dWlC?= =?utf-8?B?cm9RN2k4S1ViNFdTUll3ZllGQjVVQ1FyTGE5dXl6VWZtT01hMXQ2enoxbndu?= =?utf-8?B?cEk2dVlXSytJZUNwSGxUSGcvL0FiR2V1cEsyREtraU53NEFrZi9Sd3N0SVlu?= =?utf-8?B?TlZ6amsraTdnM2FNL3RoZ29TR0Q0S1FOdjJIaHlIcUFnK2hEUFdzWjNKeEox?= =?utf-8?B?eDBISTU3T3ZFZlFLODJPQTE4c1ZpNE9za3hqMks2QndYaWFIQmpZZXphZ2E5?= =?utf-8?B?MzhCMUlIeUdSYkpremxmd1F2NDQ3WUpkbklPZmtkUEl0eTNRSHdaVjZkdUNB?= =?utf-8?B?alZZaHhkaGFpck1hQXhiWHg3VUJvbHFFSFpSSVQ5OTY2aG9WZy96NFR1ZGFD?= =?utf-8?B?emhiQnBWT2lHSEFOZUdNMXJIM2lXU1k2c01HVW1XZ0VHWDl6UFE2b2hkY0xK?= =?utf-8?B?WnIwNWo2R0F3K0V1Q3JaMDkzaE9BYk9VQktwVkpBbFM1cTZocnF0eXgrVG5x?= =?utf-8?B?YllXU2FhK0dLTjIyT09mblZJQlIwYm9KY0RmWmREVXlsNzA0MDVScVNvSndr?= =?utf-8?B?VTFDNkdJN3dmMzhDU2QvSEZpUFlzTEx0T1ZLZGU1eXlZY3QrK0xycEM2NzFs?= =?utf-8?Q?pBza/ncPH2gANfMw=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <6AFB931449D59346BE9909FCE79CCB8C@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: e10fc720-2553-4f97-877f-08de5ce787d8 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2026 14:31:01.8919 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jQCvWs0h/mvlE/HHI6STOySLi4wPBbxzZVqiL7ivh6aMAWednhPRXQ8JoAgGxDrGK6Mn6CEdYkWxfJYkcU2s4B1h4t0qRKl3tY/m6+0D0ZE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR03MB6452 DQoNCk9uIDI2LzAxLzIwMjYgMTI6MzcsIEphbiBCZXVsaWNoIHdyb3RlOg0KPiBPbiAyNi4wMS4y MDI2IDExOjI5LCBPbGVrc2lpIE1vaXNpZWlldiB3cm90ZToNCj4+IEhpIEphbiwNCj4+IFRoYW5r IHlvdSBmb3IgeW91ciBjb21tZW50cy4NCj4+DQo+PiBPbiAyMi8wMS8yMDI2IDA5OjUxLCBKYW4g QmV1bGljaCB3cm90ZToNCj4+PiBPbiAyMS4wMS4yMDI2IDE5OjQzLCBPbGVrc2lpIE1vaXNpZWll diB3cm90ZToNCj4+Pj4gLS0tIGEveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjaS5jDQo+Pj4+ICsr KyBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY2kuYw0KPj4+PiBAQCAtMTI2LDYgKzEyNiw0MSBA QCBpbnQgc2NpX2Fzc2lnbl9kdF9kZXZpY2Uoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IGR0X2Rl dmljZV9ub2RlICpkZXYpDQo+Pj4+ICAgICAgICByZXR1cm4gMDsNCj4+Pj4gICAgfQ0KPj4+PiAg ICANCj4+Pj4gK2ludCBzY2lfZG9fZG9tY3RsKHN0cnVjdCB4ZW5fZG9tY3RsICpkb21jdGwsIHN0 cnVjdCBkb21haW4gKmQsDQo+Pj4+ICsgICAgICAgICAgICAgICAgICBYRU5fR1VFU1RfSEFORExF X1BBUkFNKHhlbl9kb21jdGxfdCkgdV9kb21jdGwpDQo+Pj4+ICt7DQo+Pj4+ICsgICAgc3RydWN0 IGR0X2RldmljZV9ub2RlICpkZXY7DQo+Pj4+ICsgICAgaW50IHJldCA9IDA7DQo+Pj4+ICsNCj4+ Pj4gKyAgICBzd2l0Y2ggKCBkb21jdGwtPmNtZCApDQo+Pj4+ICsgICAgew0KPj4+PiArICAgIGNh c2UgWEVOX0RPTUNUTF9hc3NpZ25fZGV2aWNlOg0KPj4+PiArICAgICAgICByZXQgPSAtRU5YSU87 DQo+Pj4+ICsgICAgICAgIGlmICggZG9tY3RsLT51LmFzc2lnbl9kZXZpY2UuZGV2ICE9IFhFTl9E T01DVExfREVWX0RUICkNCj4+Pj4gKyAgICAgICAgICAgIGJyZWFrOw0KPj4+PiArDQo+Pj4+ICsg ICAgICAgIGlmICggIWN1cl9tZWRpYXRvciApDQo+Pj4+ICsgICAgICAgICAgICBicmVhazsNCj4+ Pj4gKw0KPj4+PiArICAgICAgICBpZiAoICFjdXJfbWVkaWF0b3ItPmFzc2lnbl9kdF9kZXZpY2Ug KQ0KPj4+PiArICAgICAgICAgICAgYnJlYWs7DQo+Pj4+ICsNCj4+Pj4gKyAgICAgICAgcmV0ID0g ZHRfZmluZF9ub2RlX2J5X2dwYXRoKGRvbWN0bC0+dS5hc3NpZ25fZGV2aWNlLnUuZHQucGF0aCwN Cj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRvbWN0bC0+dS5hc3Np Z25fZGV2aWNlLnUuZHQuc2l6ZSwgJmRldik7DQo+Pj4+ICsgICAgICAgIGlmICggcmV0ICkNCj4+ Pj4gKyAgICAgICAgICAgIHJldHVybiByZXQ7DQo+Pj4+ICsNCj4+Pj4gKyAgICAgICAgcmV0ID0g c2NpX2Fzc2lnbl9kdF9kZXZpY2UoZCwgZGV2KTsNCj4+Pj4gKw0KPj4+PiArICAgICAgICBicmVh azsNCj4+Pj4gKyAgICBkZWZhdWx0Og0KPj4+IE5pdDogQmxhbmsgbGluZSBhYm92ZSBoZXJlIHBs ZWFzZS4NCj4+Pg0KPj4+PiBAQCAtMjc0LDcgKzI3Nyw3IEBAIHN0YXRpYyBib29sIGlzX3N0YWJs ZV9kb21jdGwodWludDMyX3QgY21kKQ0KPj4+PiAgICANCj4+Pj4gICAgbG9uZyBkb19kb21jdGwo WEVOX0dVRVNUX0hBTkRMRV9QQVJBTSh4ZW5fZG9tY3RsX3QpIHVfZG9tY3RsKQ0KPj4+PiAgICB7 DQo+Pj4+IC0gICAgbG9uZyByZXQgPSAwOw0KPj4+PiArICAgIGxvbmcgcmV0ID0gMCwgcmV0MSA9 IDA7DQo+Pj4gVGhpcyBpbml0aWFsaXplciBpc24ndCByZWFsbHkgbmVlZGVkLCB3aXRoIC4uLg0K Pj4+DQo+Pj4+IEBAIC04MzMsNyArODM2LDI4IEBAIGxvbmcgZG9fZG9tY3RsKFhFTl9HVUVTVF9I QU5ETEVfUEFSQU0oeGVuX2RvbWN0bF90KSB1X2RvbWN0bCkNCj4+Pj4gICAgICAgIGNhc2UgWEVO X0RPTUNUTF90ZXN0X2Fzc2lnbl9kZXZpY2U6DQo+Pj4+ICAgICAgICBjYXNlIFhFTl9ET01DVExf ZGVhc3NpZ25fZGV2aWNlOg0KPj4+PiAgICAgICAgY2FzZSBYRU5fRE9NQ1RMX2dldF9kZXZpY2Vf Z3JvdXA6DQo+Pj4+ICsgICAgICAgIC8qDQo+Pj4+ICsgICAgICAgICAqIENoYWluIFNDSSBEVCBo YW5kbGluZyBhaGVhZCBvZiB0aGUgSU9NTVUgcGF0aCBzbyBhbiBTQ0kgbWVkaWF0b3INCj4+Pj4g KyAgICAgICAgICogY2FuIGF1dGhvcmlzZSBhY2Nlc3MtY29udHJvbGxlZCBEVCBkZXZpY2VzLiBV bmhhbmRsZWQgY2FzZXMgcmVwb3J0DQo+Pj4+ICsgICAgICAgICAqIC1FTlhJTywgd2hpY2ggaXMg aWdub3JlZC4NCj4+Pj4gKyAgICAgICAgICovDQo+Pj4+ICsgICAgICAgIHJldDEgPSAtRU5YSU87 DQo+Pj4gLi4uIHRoaXMsIGlzIGl0PyBJbiBmYWN0LCB3aHkgbm90IHVzZSAtRU5YSU8gYXMgaW5p dGlhbGl6ZXI/DQo+Pj4NCj4+Pj4gKyAgICAjaWYgSVNfRU5BQkxFRChDT05GSUdfQVJNX1NDSSkN Cj4+Pj4gKyAgICAgICAgcmV0MSA9IHNjaV9kb19kb21jdGwob3AsIGQsIHVfZG9tY3RsKTsNCj4+ Pj4gKyAgICAjZW5kaWYNCj4+PiBXaHkgdGhlIGluZGVudGF0aW9uIG9mIHRoZSBwcmUtcHJvY2Vz c29yIGRpcmVjdGl2ZXM/IEF0IHRoZSB2ZXJ5IGxlYXN0IHRoZSAjLWVzDQo+Pj4gd2FudCB0byBi ZSBpbiB0aGUgZmlyc3QgY29sdW1uLCBidXQgSSBzZWUgbm8gcmVhc29uIGZvciB0aGUgaW5kZW50 YXRpb24gYXQgYWxsLg0KPj4+DQo+Pj4+ICAgICAgICAgICAgcmV0ID0gaW9tbXVfZG9fZG9tY3Rs KG9wLCBkLCB1X2RvbWN0bCk7DQo+Pj4+ICsgICAgICAgIGlmICggcmV0IDwgMCApDQo+Pj4+ICsg ICAgICAgICAgICByZXR1cm4gcmV0Ow0KPj4+IFlvdSBjYW4ndCBzaW1wbHkgcmV0dXJuIGhlcmUs IGFzIHdlIG1heSBiZSBob2xkaW5nIGFuIFJDVSBsb2NrIG9uIHRoZSBkb21haW4uDQo+Pj4NCj4+ Pj4gKyAgICAgICAgLyoNCj4+Pj4gKyAgICAgICAgICogSWYgSU9NTVUgcHJvY2Vzc2luZyB3YXMg c3VjY2Vzc2Z1bCwgY2hlY2sgZm9yIFNDSSBwcm9jZXNzaW5nIHJldHVybg0KPj4+PiArICAgICAg ICAgKiBjb2RlIGFuZCBpZiBpdCBmYWlsZWQgdGhlbiBvdmVyd3JpdGUgdGhlIHJldHVybiBjb2Rl IHRvIHByb3BhZ2F0ZQ0KPj4+PiArICAgICAgICAgKiBTQ0kgZmFpbHVyZSBiYWNrIHRvIGNhbGxl ci4NCj4+Pj4gKyAgICAgICAgICovDQo+Pj4+ICsgICAgICAgIGlmICggcmV0MSAhPSAtRU5YSU8g JiYgcmV0MSA8IDAgKQ0KPj4+PiArICAgICAgICAgICAgcmV0ID0gcmV0MTsNCj4+PiBTbyBpZiBJ T01NVSBwcm9jZXNzaW5nIHdhcyBzdWNjZXNzZnVsIGFuZCBiZWNhdXNlIG9mIFNDSSB5b3UgcmV0 dXJuIGFuIGVycm9yDQo+Pj4gaGVyZSwgd2h5IHdvdWxkIHRoZSBJT01NVSBwYXJ0IG5vdCBuZWVk IHVuZG9pbmc/IE9yIHRvIGFzayBkaWZmZXJlbnRseSwgaWYNCj4+PiBTQ0kgc2FpZCAibm8iLCB3 aHkgZXZlbiB0cnkgdGhlIElPTU1VIG9wZXJhdGlvbj8NCj4+Pg0KPj4+IEphbg0KPj4gTXkgaW50 ZW50aW9uIHdhcyB0byBwcmVzZXJ2ZSB0aGUgb3JpZ2luYWwgYmVoYXZpb3IgYXMgbXVjaCBhcyBw b3NzaWJsZS4NCj4+IFRoaXMgbWVhbnMgdGhhdCBpZiB0aGUgU0NJIGFzc2lnbiBvcGVyYXRpb24g cmV0dXJucyBhbiBlcnJvciwgd2Ugc3RpbGwNCj4+IGF0dGVtcHQgdGhlIElPTU1VIGFzc2lnbm1l bnQsIGJ1dCBmaWx0ZXIgdGhlIHJldHVybiBjb2RlIGFuZCB1bHRpbWF0ZWx5DQo+PiByZXR1cm4g dGhlIFNDSSBlcnJvciBpZiB0aGUgSU9NTVUgYXNzaWdubWVudCB3YXMgc3VjY2Vzc2Z1bC4NCj4+ IEhvd2V2ZXIsIGluIHRoaXMgc2NlbmFyaW8sIHdlIHdvdWxkIHN0aWxsIHJldHVybiBhbiBlcnJv ciBmcm9tDQo+PiB0aGUgZG9tY3RsIGNhbGwsIHdoaWNoIGNvdWxkIGxlYWQgdG8gdW5leHBlY3Rl ZCByZXN1bHRzLg0KPj4NCj4+IEkgYWdyZWUgd2l0aCB5b3VyIHBvaW50Lg0KPj4NCj4+IFdpdGgg eW91ciBzdWdnZXN0aW9uLCB0aGUgY29kZSBiZWNvbWVzIG11Y2ggY2xlYW5lcjoNCj4+DQo+PiAj aWYgSVNfRU5BQkxFRChDT05GSUdfQVJNX1NDSSkNCj4+ICAgwqDCoMKgwqDCoMKgwqAgcmV0ID0g c2NpX2RvX2RvbWN0bChvcCwgZCwgdV9kb21jdGwpOw0KPj4gICDCoMKgwqDCoMKgwqDCoCBpZiAo IHJldCA8IDAgJiYgcmV0ICE9IC1FTlhJTyApDQo+PiAgIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg YnJlYWs7DQo+PiAjZW5kaWYNCj4+DQo+PiAgIMKgwqDCoMKgwqDCoMKgIHJldCA9IGlvbW11X2Rv X2RvbWN0bChvcCwgZCwgdV9kb21jdGwpOw0KPj4gICDCoMKgwqDCoMKgwqDCoCBicmVhazsNCj4+ DQo+PiBXaGF0IGRvIHlvdSB0aGluayBhYm91dCB0aGlzIGFwcHJvYWNoPw0KPiBZZXMuIEp1c3Qg dG8gZG91YmxlLWNoZWNrIHRob3VnaDogVGhlcmUncyBub3RoaW5nIHRoYXQgbmVlZHMgdW5kb2lu ZyBhZnRlcg0KPiBhIHN1Y2Nlc3NmdWwgc2NpX2RvX2RvbWN0bCgpIHdoZW4gdGhlIHN1YnNlcXVl bnQgaW9tbXVfZG9fZG9tY3RsKCkgZmFpbGVkPw0KSnVzdCByZWNoZWNrZWQuIGZvciBtdWx0aWFn ZW50IChhcGFydCBmcm9tIHBhcmFtZXRlcnMgY2hlY2spIGlzIHNlbmRzIFNDTUkNCnJlcXVlc3Qg dG8gdGhlIGZpcm13YXJlLiBTbyBJIGRvbid0IHNlZSBhbnl0aGluZyB0aGF0IHNob3VsZCBiZSB1 bmRvbmUgDQppbiBjYXNlDQpvZiBlcnJvci4NCj4gT25lIG90aGVyIHJlbWFyazogTm8gSVNfRU5B QkxFRCgpIHBsZWFzZSBpbiBwcmUtcHJvY2Vzc29yIGRpcmVjdGl2ZXMuIEl0DQo+IHdhbnRzIHRv IGJlICNpZmRlZiB0aGVyZS4gSVNfRU5BQkxFRCgpIGlzIGZvciB1c2UgaW4gaWYoKS4NCldpbGwg Zml4Lg0KPiBKYW4NCg== From xen-devel-bounces@lists.xenproject.org Mon Jan 26 15:45:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 15:45:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213773.1524224 (Exim 4.92) (envelope-from ) id 1vkOm7-0003Rs-CO; Mon, 26 Jan 2026 15:45:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213773.1524224; Mon, 26 Jan 2026 15:45:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkOm7-0003Rl-9e; Mon, 26 Jan 2026 15:45:11 +0000 Received: by outflank-mailman (input) for mailman id 1213773; Mon, 26 Jan 2026 15:45: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 1vkOm5-0003Rd-L7 for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 15:45:09 +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 fd46d8c3-facd-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 16:45:07 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by PA1PR03MB11075.eurprd03.prod.outlook.com (2603:10a6:102:4fa::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Mon, 26 Jan 2026 15:44:47 +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.9542.010; Mon, 26 Jan 2026 15:44:47 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fd46d8c3-facd-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jJfDA42Qt3MrRHvpDMGr124X5niA+PQZrFXMuZOG5Mrx60OkJWp49Os7myysSz0Z1lfOea9YS63Vn682dzc43LGZVHpgZ+lpAOflf8Yu+tpfN4taviyUdNrKHFabh/Ii7a9du7xTawD1XiXPTJG41kwz2Vmsf6yCMxlAxXwDLLJ44I0wEcFtG9g8xHuSSNZO4oIfdKCsEyWOQebX8xprCx9/rMcnHVpBgQAIT1e4u/zN3sRlwgqlKrrG3p7yEotA6enKt3cH3jboVQxS3nJt2RmT4OY76dWUNdTcrUCEzKT18Ilh3IXELQvmK+2QxlgI2YMsFCVtgXb0j3vhxrN0VQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PoXLh2mEM1/UE4LMNt+FgOsbTgg+lu8qo4ByJag1Q6A=; b=oFWR7Yv4htlCkM6mDkdcmDw4jRRxZViyawUVhXuH3+dvlJ9wopYAvc79L4F0MVfm7CuOiDAIG9l/Ke9LyEaLYet7miOP/LfXVhD4+fdKfv+r50w2kcTfjL6dZjPbmho1/HS67ZYeGvybWjHnvat1SyrtKcK9+uNZusR+DNg788SRpXtbd6SmiNGjAOLEPU6QlJNDrhFUz62aJDiZzGm/yTAvzazJVidspCpYUOlzHRgatXKyqp5SK1ORJd38xy0AN79NSxBW2jzyn/3VQBPwAmC0RaHPnUFQ2MxinO9K6P74192KicL1nF4d+1oIWmsDk48Qt85930b0pN08zm1vIg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PoXLh2mEM1/UE4LMNt+FgOsbTgg+lu8qo4ByJag1Q6A=; b=jl3z/cf848pzl2daXHvz4A3xnZSkjVoznd6imOoTNgM1vUkyCKFR/ZR3KY87QOV4xEZEbnffqaZDEpA+a7GvLI5hinjc4A4Vh50NHTsc8SszyIHnaROVu721VL8U+LRQGHI2quijdvsqU38e+vKB3x7loMlC8VXS8aGGjyOysdJd9EspjevWiAnOs9JBLqB9Mv7/7Z4T4CrTkhZ3LcDg1MrSNpIGP15wfCElu4v47JUY6h/wPbitxGe1hWQ7lGdbwij5XAhsdfz2RuP6Wrg4bU/OiE15xynKgV2A+MOC0YCUsTwSmvNrKmo7/5TOlrTe/OkvCI5Z0FOxYXh6rmZCXQ== 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 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [PATCH v8 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHciwXlwgLiqFlETUSoWi6AzAQyorVe/3OAgAWf+wA= Date: Mon, 26 Jan 2026 15:44:47 +0000 Message-ID: <695431e2-bcbb-45ca-8276-a0a23f71c12e@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_|PA1PR03MB11075:EE_ x-ms-office365-filtering-correlation-id: 21c82ef6-d03b-4f4c-cb49-08de5cf1d57c x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|7416014|376014|38070700021; x-microsoft-antispam-message-info: =?utf-8?B?ZExNWE41d2w4ejFHbVo3ZHlvRVIwVzhkY2IvTGEyekFwN2RIaHhqbXBDNzJJ?= =?utf-8?B?Y2U2VU1wallETlhuYnZhNXZRSDdndWhEeFRsMXhaRERiTjFqUDNqaDJGaHVU?= =?utf-8?B?ZFNtREtBZ1BkdU5WTVQ0Qm12WVNER3NRWk1XQUluRHlnZE1PWVhqRDBuY2RM?= =?utf-8?B?M0N2UkxUYXZ5Lyt4OEN5SnVPL3V2aUxTR0loMlZCMVhhYUVoT2NtWXNmVloz?= =?utf-8?B?SFZXdFJ2aEdKbGVkb003UmNQa056bGcrZEpBM1FLN3JIeGV2THJETFdSZ3BW?= =?utf-8?B?cytLMm1Za2xDL3VYR1Y5c3IwK001ZHVXVHhDTmtKeEhobDk4bWhET3Vvb1pB?= =?utf-8?B?dEdpWlZkblM1N2FDS0U2ck1OMUZ3L3hLMmFwMW1FYThmRXJtOVZkQ0x0eG81?= =?utf-8?B?VlFSYk9OTnVBSnYveFFWay9WaG5SSHZqREpOQVo2c0xyRXAvZlFtZmVIWGUy?= =?utf-8?B?SjU5M2xsc01seDZCUWs4WUxiTHZrSFpFSFg5VUxNR3JvVGlYS0VLSFdsRHZS?= =?utf-8?B?SCtIUXBaTTNXZmxNTXRaVFZVb1pEbDc4UC8vdWZxelR0Wk5HN3ArNlF2Mitq?= =?utf-8?B?VytraW1CVm9IWWpwS2Z2cGdQbEpvRm5YclZ3RnRmMXRPelBvMTNsaTR2WTFq?= =?utf-8?B?R2lmeVFDd3E0Yk9ZTmFua0QwdUYxVEY5ZGtaU2ZGaWk4Q3lTcGx3MmtPZkVT?= =?utf-8?B?VEhEK2N5REJTNUl5NUdFdXZmcDhLM1BKaDVvSTFkMXBTaUJwVUc4amhNYVNl?= =?utf-8?B?ZUthdkRkWjhpNlBhTEJWZVdZdkRHeGFIM0VWVWlvNVVsYWVKY201UTRkbWxV?= =?utf-8?B?SzAyVHJnb1NpdFNLSUxaRG5PNlRMWFpTRjZ5Y2dOUmJYTE9QSG5ibm43a0Z4?= =?utf-8?B?bk14R0JDSmtYb0c3QXJtTnVrb25lMURjeHozVlEveThCK05xTmJiRThMVnNo?= =?utf-8?B?eFFPcWJPSnVUNjlQZ3lyY2k4MnlDN3d3Q2V0NFQ0V3hIb3FRVXlqWUFnY0Vh?= =?utf-8?B?cWJ0ZTFhbWovdVVuWUpsS0JHeXk3Mk1Fdm9CT0VaQ0NhczNMeGNYbU9TS29j?= =?utf-8?B?eHZJcVpBaklQc0JlS2VsamIza1VJWlp4RklWK1Fkb2J3YWRnNy83WTRoNUxk?= =?utf-8?B?SHRXNkM2NmhOWWFRTWhYUksxZ2NEV3kranBnV2h3c05qRVBCSEQ0RGViTmNJ?= =?utf-8?B?UjZpQXhWL1hUQ0JYWGNySXpJNWhFWkhINjNlL25xRUlSeFdNYmFzd1B1aytI?= =?utf-8?B?emJLU1JoZ2RIdmJhSTJ1d1hwUEIzWGJTYTd1NDk2bHFUZTUvUXNvbHcxVFhl?= =?utf-8?B?V2ROU2dQaXFZZnNQSTd0YUhZb0JhYmhDZVJHMXcveFo1aUVjemg3a1BGeEFN?= =?utf-8?B?NzdaY1ZkWE0wNFgwa0xsdXlxQVM0QkEwdG9yQTdCVkFOSk1VTFlNaU5jWmk2?= =?utf-8?B?RWt3Y3dRZHRab1c5MWhFZEpweDFrVitTSWgrZjNhNWNJS25LcTZueU5Hd2lH?= =?utf-8?B?bHF3WmVjQkx1WUMydmx6eFZHWTRjV0Y3UDhPejl2NVR5eDc0eUR4OGNKMTRO?= =?utf-8?B?WklocFY0NjdqczZOdmZEQVZha0tkdVpqVit3dnhpY2ZyVk1RODQ2NkJxZ3hk?= =?utf-8?B?emhTVFdBeDE1ZXBKZ3dnZ1UrUWx2cndSTGJia05FcGNOVURIQW9neHE2ZXFh?= =?utf-8?B?M1F6aWNVdnFCOGdTViszemltYUEvdmo4TnU1WnZBV2pnZW9PRUZLbmQyU1Ux?= =?utf-8?B?UzN1VUZaVytGZE03WkIvby9oL0pVamdjTnpCYjN3SndBaHZHSXlIRVBQVTMx?= =?utf-8?B?UGVzejlrVEV5R09sZkRpZlgwWFdHRHo5NEJ6NTZ4S25QQXpIcy80V1NFRkMw?= =?utf-8?B?OTRmaC9zV0tlQnUxSnIvcU1QWk9RbGJvWmNGWEVKS2lhSzgrb1FpZ0taV1M2?= =?utf-8?B?WE9IdHZtMGdSVWxrVG83bEdPdnJ2aW1tdVprZS9lNjZ2TmZlZEE2V05LMVRy?= =?utf-8?B?Z1BhcWxzOGlpUnpZTjdXMStCa0JmOHY4ejNPaTUxMUthalFlUkN1VjJVUmdV?= =?utf-8?B?MTZyQ0ZxYTRRRkZLTk9BWDl6eHZidkREMVF2cklxRVVDdkZmUnFUaUg5ZGIz?= =?utf-8?B?WHRVRXZEV0R2bG9ZM1V1bkpDelNTZHJ6Y3N6ZDlIY0lkUU5iR0NIV1hZSzJS?= =?utf-8?Q?jAGP/RhbGGXAdhpFFfPnjps=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8946.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(7416014)(376014)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?aUJBV0NmNTNGYmU3ZlhUbjZmeVdSaEFUMVptYjAwQzNrUzI2YktJVXQraTJX?= =?utf-8?B?YnlIemJ0bHlWdjJmK3MvVzlYOHI0MjljWk5FZi9CMHNGSEZ4dnVZWVlNTnJQ?= =?utf-8?B?SGpOQWZyZ1dVYTFkcHN0MUZKOW5ZZHROazA3SkR0cXhPYlMwOGdFUndvd0pt?= =?utf-8?B?Zy9hNTNjWTVVSWJMdm0vVHlmZ2ozVGxROGg1Ry91M21GNTZ2d2tZRHBxYkZx?= =?utf-8?B?ZDQyRWFvNW1SM1BpOUU0RFFTVUxEcC9HSE5YZW1FTkIrQmJNRG9oNFJwTkk3?= =?utf-8?B?MWxXSzNGMjNvUGdCVEtaVlR6V0JuYmdtMjVvS25jQTJudVRjejRFTW5kckhn?= =?utf-8?B?TDRhWW1iOVA3S2Q0SWpOZGc3dzFSUmY2N3FDRmVnajNjOWJBTkFlVXVmQ3FU?= =?utf-8?B?Q1JGMjZCNndyNXdXc2RqRVFtaVBMQWx6RFdybzFjRjFSc1FmNjUrTDdhRWov?= =?utf-8?B?NFdyUGtEZjBHdGFtd3dReVN5OWJUMW9xaFJRV1JaQkVPTEJjNEVQYXp4ZGYz?= =?utf-8?B?VFBWbW5xZHlOKytvNGpRQWlxbDRqZEczQS9yelU0dGhza2lCV1NoZjBGbHRS?= =?utf-8?B?dkNrYU9YY3QxUzNIblM3czBEdmRqQStKQW50cnNPdzE1VTVDekIyM2FpS2JU?= =?utf-8?B?cWNoSUppZ0JjdzVhMEtnMmJGbjQzTjNNR1N4RjMwZVE1WXlST3FHcE9paEtP?= =?utf-8?B?ck1NaW92Zm45N1N3NW40TytUVUFEWGlWUjAwRm5GalRteC9QSnRpaW0rVUt0?= =?utf-8?B?c3VMMnJmQm5KdElHK3VlNC9abUlIbkhoWUVlQm13SFk5eEtYMXJhbHRtdVQy?= =?utf-8?B?V3BXWkp1RmUreEtxTkF1TmEzK1BZSWNNVG10ZnJCeTdqYVJ3Mkx6OGVOMk1w?= =?utf-8?B?TGkzdlR2SDJOcUxLc2dFYStyaFVNeDBIdmxpMnloM2M1MEdRSmNmSEdTMVB3?= =?utf-8?B?cmdYMXd4QmVPd1NzNnJkM1VBSmZ1aDYycWF2NitTa2lUby8yUXJIN1plYm9N?= =?utf-8?B?RnlHanFWWmxIN1paNVNTSXdEcFpFQ0tKTnVoZFlVUll6YndodGt4UHh4RWc1?= =?utf-8?B?QW13STIrWDZLWXVCSFl6eEF2SzRURFc1OE1wTENNVmE0QjZyQ1RNcUMvWlRu?= =?utf-8?B?TXp2RmpTRCt5aU44SDgxSXVtck4wa0RSS0t4SnR4ODBsZ0ZJVzZvbFlGSklJ?= =?utf-8?B?dUJCZnZJT0hPSXJZOUlQdGh5QkhaRGFYZTlKV0ltdUZRcldSbW9iUGVRZmFV?= =?utf-8?B?UHU1aHBvRGtsajJmSm1iRHBDa1lYUi9zeDZWaXZNRGZ2blRINzYraE1OdE1C?= =?utf-8?B?blRtTEdjajU4TWJPNnhwOXFEWjduTnlDWlNoaVh5R0lpeWV5WTd6L3V1OVFp?= =?utf-8?B?dG1BTWN3QmtYL1JKc09oWDdKS1JqdG5NTUlKVmhObmRWcGxQQkpCZE5rV2k4?= =?utf-8?B?NVgvUkFFWWxBK1FvaXJHNGRUUlBwSHovRG1HcER3RkdWRjF3cXNYOE1LRGNR?= =?utf-8?B?NEJIZEV4M29SQVR4QkFpQXk3SDQrSGFwN3poQW1rWU15eGhqckc3a1QwRTdk?= =?utf-8?B?S2RGSFFYWnoweE5manY0MDhRcXpXOFRTUjdNUHErbm9BQzAvckxkYXhOS3hi?= =?utf-8?B?bW9kdGhqRHhBRFg3ZWwxTE92cmwzd0QyYTFvOVFOTVVoZEp5TmttbXc5Z05K?= =?utf-8?B?a2hUZzdZQVlWYzFVcWd6ZWJWZ2ZoSFN6UUdJRHBLWVp4V1hUUHM0akpYck13?= =?utf-8?B?aWV4eFVrdUdtVnJwY1pOWWk2MzU2dVJRK3FXZklKT1c2azR3aXoxL2VURSth?= =?utf-8?B?ejJTZGVUc2FPSkdjbUwybnlOd2xNLzNVTzdXUXcwVTBSeU1PREM1UUx0S09Z?= =?utf-8?B?a3RSdkZqMFZSWnFNRnVDMFc2d2EzcUJHY3J3WXQ0L3I5ZThUOGZ0SGVIYmVO?= =?utf-8?B?clpDT0hFZVhBNmNLU0hyVjgyQnhMbm5rY0lKSWVZdnpqdTJycEhVNmNuUmh5?= =?utf-8?B?M3NVUXZIR0tlNjhCekloUisxQjFlQWRsN3BjNEZRL0NRTmE3cDhoNGptekEz?= =?utf-8?B?NzhBSlZyUTFlUXJkbTh1REliUzhHc1d3cEoxSjg2dGZiVTkwOTZiUThIM0hs?= =?utf-8?B?UXhTaVgxTW91ZWkzcmhnRUlIcHFCL2FpaktaTUprTFNVZm1ESTl5REM0aUt2?= =?utf-8?B?LzcwQ3VER2pqbSs3ZzlOOWZqTVg5MVZma3BsNGkxNEd4NkwxOUpBTVg4WlFS?= =?utf-8?B?UHdSd3B2RGtTNVpoSGdscjVBTDl0SlJZd1g2RzZKcE9vZjhNUmJIdnYwcVZl?= =?utf-8?B?alBHdU50eE9LTjVvMk5nSTladGV6NlYvbXB5akxJcStVa0VOVTJPejdXN2xr?= =?utf-8?Q?1JsZVlM/bP3RwaOk=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <8E0D5CC964F9E240877F2FCCFEBD65EC@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: 21c82ef6-d03b-4f4c-cb49-08de5cf1d57c X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2026 15:44:47.1166 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1EhYNEeklVfqt+MzNk0Y8xbSE20y0zbeaElgpE++AOe/3V9ukia6OoCoAs7qlat8S+r6QhCKBdw2cyFR2BUDTEr0/HdXMgBlfcCbmLxGC+8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA1PR03MB11075 DQoNCk9uIDIzLzAxLzIwMjYgMDM6NTEsIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4gTm90 IGEgZnVsbCByZXZpZXcsIGJ1dCBJIGZvdW5kIHRocmVlIGlzc3VlcyBwbHVzIHNvbWUgc3B1cmlv dXMgY2hhbmdlcw0KPg0KPg0KPiBPbiBXZWQsIDIxIEphbiAyMDI2LCBPbGVrc2lpIE1vaXNpZWll diB3cm90ZToNCj4+IGRpZmYgLS1naXQgYS9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5wYW5k b2MgYi9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MNCj4+IGluZGV4IDE1ZjdhMzE1 YTQuLjI2OGRmMzAxMGIgMTAwNjQ0DQo+PiAtLS0gYS9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGlu ZS5wYW5kb2MNCj4+ICsrKyBiL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYw0KPj4g QEAgLTc4OSw3ICs3ODksNyBAQCBTcGVjaWZ5IHRoZSBiaXQgd2lkdGggb2YgdGhlIERNQSBoZWFw Lg0KPj4gICAgICAgICAgICAgICAgICAgY3B1aWQtZmF1bHRpbmc9PGJvb2w+LCBtc3ItcmVsYXhl ZD08Ym9vbD4sDQo+PiAgICAgICAgICAgICAgICAgICBwZi1maXh1cD08Ym9vbD4gXSAoeDg2KQ0K Pj4gICANCj4+IC0gICAgPSBMaXN0IG9mIFsgc3ZlPTxpbnRlZ2VyPiBdIChBcm02NCkNCj4+ICsg ICAgPSBMaXN0IG9mIFsgc3ZlPTxpbnRlZ2VyPiBdIChBcm0pDQo+PiAgIA0KPj4gICBDb250cm9s cyBmb3IgaG93IGRvbTAgaXMgY29uc3RydWN0ZWQgb24geDg2IHN5c3RlbXMuDQo+IFNwdXJpb3Vz IGNoYW5nZQ0KPg0KPg0KPj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfYXJt LmMgYi90b29scy9saWJzL2xpZ2h0L2xpYnhsX2FybS5jDQo+PiBpbmRleCBlNDQwN2Q2ZTNmLi5i ZTBlNjI2M2FlIDEwMDY0NA0KPj4gLS0tIGEvdG9vbHMvbGlicy9saWdodC9saWJ4bF9hcm0uYw0K Pj4gKysrIGIvdG9vbHMvbGlicy9saWdodC9saWJ4bF9hcm0uYw0KPj4gQEAgLTI0MCw2ICsyNDAs MTAgQEAgaW50IGxpYnhsX19hcmNoX2RvbWFpbl9wcmVwYXJlX2NvbmZpZyhsaWJ4bF9fZ2MgKmdj LA0KPj4gICAgICAgY2FzZSBMSUJYTF9BUk1fU0NJX1RZUEVfU0NNSV9TTUM6DQo+PiAgICAgICAg ICAgY29uZmlnLT5hcmNoLmFybV9zY2lfdHlwZSA9IFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lf U0NNSV9TTUM7DQo+PiAgICAgICAgICAgYnJlYWs7DQo+PiArICAgIGNhc2UgTElCWExfQVJNX1ND SV9UWVBFX1NDTUlfU01DX01VTFRJQUdFTlQ6DQo+PiArICAgICAgICBjb25maWctPmFyY2guYXJt X3NjaV90eXBlID0gWEVOX0RPTUNUTF9DT05GSUdfQVJNX1NDSV9TQ01JX1NNQ19NQTsNCj4+ICsg ICAgICAgIGNvbmZpZy0+YXJjaC5hcm1fc2NpX2FnZW50X2lkID0gZF9jb25maWctPmJfaW5mby5h cmNoX2FybS5hcm1fc2NpLmFnZW50X2lkOw0KPj4gKyAgICAgICAgYnJlYWs7DQo+PiAgICAgICBk ZWZhdWx0Og0KPj4gICAgICAgICAgIExPRyhFUlJPUiwgIlVua25vd24gQVJNX1NDSSB0eXBlICVk IiwNCj4+ICAgICAgICAgICAgICAgZF9jb25maWctPmJfaW5mby5hcmNoX2FybS5hcm1fc2NpLnR5 cGUpOw0KPj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnMvbGlnaHQvbGlieGxfdHlwZXMuaWRsIGIv dG9vbHMvbGlicy9saWdodC9saWJ4bF90eXBlcy5pZGwNCj4+IGluZGV4IDRhOTU4ZjY5ZjQuLjli ZmJmMDkxNDUgMTAwNjQ0DQo+PiAtLS0gYS90b29scy9saWJzL2xpZ2h0L2xpYnhsX3R5cGVzLmlk bA0KPj4gKysrIGIvdG9vbHMvbGlicy9saWdodC9saWJ4bF90eXBlcy5pZGwNCj4+IEBAIC01NTQs MTEgKzU1NCwxMyBAQCBsaWJ4bF9zdmVfdHlwZSA9IEVudW1lcmF0aW9uKCJzdmVfdHlwZSIsIFsN Cj4+ICAgDQo+PiAgIGxpYnhsX2FybV9zY2lfdHlwZSA9IEVudW1lcmF0aW9uKCJhcm1fc2NpX3R5 cGUiLCBbDQo+PiAgICAgICAoMCwgIm5vbmUiKSwNCj4+IC0gICAgKDEsICJzY21pX3NtYyIpDQo+ PiArICAgICgxLCAic2NtaV9zbWMiKSwNCj4+ICsgICAgKDIsICJzY21pX3NtY19tdWx0aWFnZW50 IikNCj4+ICAgICAgIF0sIGluaXRfdmFsID0gIkxJQlhMX0FSTV9TQ0lfVFlQRV9OT05FIikNCj4+ ICAgDQo+PiAgIGxpYnhsX2FybV9zY2kgPSBTdHJ1Y3QoImFybV9zY2kiLCBbDQo+PiAgICAgICAo InR5cGUiLCBsaWJ4bF9hcm1fc2NpX3R5cGUpLA0KPj4gKyAgICAoImFnZW50X2lkIiwgdWludDgp DQo+PiAgICAgICBdKQ0KPj4gICANCj4+ICAgbGlieGxfcmRtX3Jlc2VydmUgPSBTdHJ1Y3QoInJk bV9yZXNlcnZlIiwgWw0KPj4gZGlmZiAtLWdpdCBhL3Rvb2xzL3hsL3hsX3BhcnNlLmMgYi90b29s cy94bC94bF9wYXJzZS5jDQo+PiBpbmRleCAxY2M0MWYxYmZmLi4wYzM4OWQyNWY5IDEwMDY0NA0K Pj4gLS0tIGEvdG9vbHMveGwveGxfcGFyc2UuYw0KPj4gKysrIGIvdG9vbHMveGwveGxfcGFyc2Uu Yw0KPj4gQEAgLTEzMDYsNiArMTMwNiwxOCBAQCBzdGF0aWMgaW50IHBhcnNlX2FybV9zY2lfY29u ZmlnKFhMVV9Db25maWcgKmNmZywgbGlieGxfYXJtX3NjaSAqYXJtX3NjaSwNCj4+ICAgICAgICAg ICAgICAgfQ0KPj4gICAgICAgICAgIH0NCj4+ICAgDQo+PiArICAgICAgICBpZiAoTUFUQ0hfT1BU SU9OKCJhZ2VudF9pZCIsIHB0ciwgb3BhcmcpKSB7DQo+PiArICAgICAgICAgICAgdW5zaWduZWQg bG9uZyB2YWwgPSBwYXJzZV91bG9uZyhvcGFyZyk7DQo+PiArDQo+PiArICAgICAgICAgICAgaWYg KCF2YWwgfHwgdmFsID4gMjU1KSB7DQo+PiArICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJy LCAiQW4gaW52YWxpZCBBUk1fU0NJIGFnZW50X2lkIHNwZWNpZmllZCAoJWx1KS4gVmFsaWQgcmFu Z2UgWzEuLjI1NV1cbiIsDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgdmFsKTsNCj4+ICsg ICAgICAgICAgICAgICAgcmV0ID0gRVJST1JfSU5WQUw7DQo+PiArICAgICAgICAgICAgICAgIGdv dG8gb3V0Ow0KPj4gKyAgICAgICAgICAgIH0NCj4+ICsgICAgICAgICAgICBhcm1fc2NpLT5hZ2Vu dF9pZCA9IHZhbDsNCj4+ICsgICAgICAgIH0NCj4+ICsNCj4+ICAgICAgICAgICBwdHIgPSBzdHJ0 b2soTlVMTCwgIiwiKTsNCj4+ICAgICAgIH0NCj4+ICAgDQo+PiBkaWZmIC0tZ2l0IGEveGVuL2Fy Y2gvYXJtL2RvbTBsZXNzLWJ1aWxkLmMgYi94ZW4vYXJjaC9hcm0vZG9tMGxlc3MtYnVpbGQuYw0K Pj4gaW5kZXggNDE4MWMxMDUzOC4uZGRhZGM4OTE0OCAxMDA2NDQNCj4+IC0tLSBhL3hlbi9hcmNo L2FybS9kb20wbGVzcy1idWlsZC5jDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vZG9tMGxlc3MtYnVp bGQuYw0KPj4gQEAgLTI5OSw2ICsyOTksMTcgQEAgc3RhdGljIGludCBfX2luaXQgZG9tdV9kdF9z Y2lfcGFyc2Uoc3RydWN0IGR0X2RldmljZV9ub2RlICpub2RlLA0KPj4gICAgICAgICAgIGRfY2Zn LT5hcmNoLmFybV9zY2lfdHlwZSA9IFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lfTk9ORTsNCj4+ ICAgICAgIGVsc2UgaWYgKCAhc3RyY21wKHNjaV90eXBlLCAic2NtaV9zbWMiKSApDQo+PiAgICAg ICAgICAgZF9jZmctPmFyY2guYXJtX3NjaV90eXBlID0gWEVOX0RPTUNUTF9DT05GSUdfQVJNX1ND SV9TQ01JX1NNQzsNCj4+ICsgICAgZWxzZSBpZiAoICFzdHJjbXAoc2NpX3R5cGUsICJzY21pX3Nt Y19tdWx0aWFnZW50IikgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICB1aW50MzJfdCBhZ2VudF9p ZCA9IDA7DQo+PiArDQo+PiArICAgICAgICBpZiAoICFkdF9wcm9wZXJ0eV9yZWFkX3UzMihub2Rl LCAieGVuLHNjaS1hZ2VudC1pZCIsICZhZ2VudF9pZCkgfHwNCj4+ICsgICAgICAgICAgICAgYWdl bnRfaWQgPiBVSU5UOF9NQVggKQ0KPj4gKyAgICAgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4g Kw0KPj4gKyAgICAgICAgZF9jZmctPmFyY2guYXJtX3NjaV90eXBlID0gWEVOX0RPTUNUTF9DT05G SUdfQVJNX1NDSV9TQ01JX1NNQ19NQTsNCj4+ICsgICAgICAgIGRfY2ZnLT5hcmNoLmFybV9zY2lf YWdlbnRfaWQgPSBhZ2VudF9pZDsNCj4+ICsgICAgfQ0KPj4gICAgICAgZWxzZQ0KPj4gICAgICAg ew0KPj4gICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJ4ZW4sc2NpX3R5cGUgaW4gbm90IHZh bGlkICglcykgZm9yIGRvbWFpbiAlc1xuIiwNCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0v ZG9tYWluX2J1aWxkLmMgYi94ZW4vYXJjaC9hcm0vZG9tYWluX2J1aWxkLmMNCj4+IGluZGV4IDk4 NmE0NTZmMTcuLjA3OTY1NjEzMDYgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vZG9tYWlu X2J1aWxkLmMNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9kb21haW5fYnVpbGQuYw0KPj4gQEAgLTg2 LDYgKzg2LDM3IEBAIGludCBfX2luaXQgcGFyc2VfYXJjaF9kb20wX3BhcmFtKGNvbnN0IGNoYXIg KnMsIGNvbnN0IGNoYXIgKmUpDQo+PiAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICAgfQ0KPj4g ICANCj4+ICsvKiBTQ01JIGFnZW50IElEIGZvciBkb20wIG9idGFpbmVkIGZyb20geGVuLHNjaSBj b250YWluZXIgKi8NCj4+ICsjZGVmaW5lIFNDTUlfQUdFTlRfSURfSU5WQUxJRCBVSU5UOF9NQVgN Cj4+ICsNCj4+ICtzdGF0aWMgdWludDhfdCBfX2luaXQgZ2V0X2RvbTBfc2NtaV9hZ2VudF9pZCh2 b2lkKQ0KPj4gK3sNCj4+ICsgICAgY29uc3Qgc3RydWN0IGR0X2RldmljZV9ub2RlICpjb25maWdf bm9kZTsNCj4+ICsgICAgdTMyIHZhbDsNCj4+ICsgICAgY29uc3Qgc3RydWN0IGR0X3Byb3BlcnR5 ICpwcm9wOw0KPj4gKw0KPj4gKyAgICBjb25maWdfbm9kZSA9IGR0X2ZpbmRfY29tcGF0aWJsZV9u b2RlKE5VTEwsIE5VTEwsICJ4ZW4sc2NpIik7DQo+PiArICAgIGlmICggIWNvbmZpZ19ub2RlICkN Cj4+ICsgICAgICAgIHJldHVybiBTQ01JX0FHRU5UX0lEX0lOVkFMSUQ7DQo+PiArDQo+PiArICAg IHByb3AgPSBkdF9maW5kX3Byb3BlcnR5KGNvbmZpZ19ub2RlLCAieGVuLGRvbTAtc2NpLWFnZW50 LWlkIiwgTlVMTCk7DQo+PiArICAgIGlmICggIXByb3AgKQ0KPj4gKyAgICAgICAgcmV0dXJuIFND TUlfQUdFTlRfSURfSU5WQUxJRDsNCj4+ICsNCj4+ICsgICAgaWYgKCAhZHRfcHJvcGVydHlfcmVh ZF91MzIoY29uZmlnX25vZGUsICJ4ZW4sZG9tMC1zY2ktYWdlbnQtaWQiLCAmdmFsKSApDQo+PiAr ICAgICAgICByZXR1cm4gU0NNSV9BR0VOVF9JRF9JTlZBTElEOw0KPj4gKw0KPj4gKyAgICBpZiAo IHZhbCA+PSBTQ01JX0FHRU5UX0lEX0lOVkFMSUQgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICAg cHJpbnRrKFhFTkxPR19XQVJOSU5HDQo+PiArICAgICAgICAgICAgICJJbnZhbGlkIHhlbixkb20w LXNjaS1hZ2VudC1pZD0ldSwgU0NNSSBkaXNhYmxlZCBmb3IgRG9tMFxuIiwNCj4+ICsgICAgICAg ICAgICAgdmFsKTsNCj4+ICsgICAgICAgIHJldHVybiBTQ01JX0FHRU5UX0lEX0lOVkFMSUQ7DQo+ PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcmV0dXJuIHZhbDsNCj4+ICt9DQo+PiArDQo+PiAgIC8q IE92ZXJyaWRlIG1hY3JvcyBmcm9tIGFzbS9wYWdlLmggdG8gbWFrZSB0aGVtIHdvcmsgd2l0aCBt Zm5fdCAqLw0KPj4gICAjdW5kZWYgdmlydF90b19tZm4NCj4+ICAgI2RlZmluZSB2aXJ0X3RvX21m bih2YSkgX21mbihfX3ZpcnRfdG9fbWZuKHZhKSkNCj4+IEBAIC01MDksNyArNTQwLDcgQEAgc3Rh dGljIGludCBfX2luaXQgd3JpdGVfcHJvcGVydGllcyhzdHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3Qg a2VybmVsX2luZm8gKmtpbmZvLA0KPj4gICAgICAgICAgICAgICAgICAgIGR0X3Byb3BlcnR5X25h bWVfaXNfZXF1YWwocHJvcCwgImxpbnV4LHVlZmktbW1hcC1zdGFydCIpIHx8DQo+PiAgICAgICAg ICAgICAgICAgICAgZHRfcHJvcGVydHlfbmFtZV9pc19lcXVhbChwcm9wLCAibGludXgsdWVmaS1t bWFwLXNpemUiKSB8fA0KPj4gICAgICAgICAgICAgICAgICAgIGR0X3Byb3BlcnR5X25hbWVfaXNf ZXF1YWwocHJvcCwgImxpbnV4LHVlZmktbW1hcC1kZXNjLXNpemUiKSB8fA0KPj4gLSAgICAgICAg ICAgICAgICAgZHRfcHJvcGVydHlfbmFtZV9pc19lcXVhbChwcm9wLCAibGludXgsdWVmaS1tbWFw LWRlc2MtdmVyIikpDQo+PiArICAgICAgICAgICAgICAgICBkdF9wcm9wZXJ0eV9uYW1lX2lzX2Vx dWFsKHByb3AsICJsaW51eCx1ZWZpLW1tYXAtZGVzYy12ZXIiKSApDQo+PiAgICAgICAgICAgICAg ICAgICBjb250aW51ZTsNCj4gU3B1cmlvdXMgY2hhbmdlDQo+DQo+DQo+PiArc3RhdGljIGludCBz Y21pX2R0X2Fzc2lnbl9kZXZpY2Uoc3RydWN0IGRvbWFpbiAqZCwNCj4+ICsgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgZHRfcGhhbmRsZV9hcmdzICphY19zcGVjKQ0KPj4g K3sNCj4+ICsgICAgc3RydWN0IHNjbWlfY2hhbm5lbCAqYWdlbnRfY2hhbm5lbDsNCj4+ICsgICAg dWludDMyX3Qgc2NtaV9kZXZpY2VfaWQgPSBhY19zcGVjLT5hcmdzWzBdOw0KPj4gKyAgICBpbnQg cmV0Ow0KPj4gKw0KPj4gKyAgICBpZiAoICFkLT5hcmNoLnNjaV9kYXRhICkNCj4+ICsgICAgICAg IHJldHVybiAwOw0KPj4gKw0KPj4gKyAgICAvKiBUaGUgYWNjZXNzLWNvbnRyb2xsZXJzIGlzIHNw ZWNpZmllZCBmb3IgRFQgZGV2LCBidXQgaXQncyBub3QgYSBTQ01JICovDQo+PiArICAgIGlmICgg YWNfc3BlYy0+bnAgIT0gc2NtaV9kYXRhLmR0X2RldiApDQo+PiArICAgICAgICByZXR1cm4gMDsN Cj4gVGhpcyBjb21wYXJpc29uIGNhbiBlcnJvbmVvdXNseSBmYWlsIHdoZW4gdGhlIHBvaW50ZXJz IHBvaW50IHRvDQo+IGRpZmZlcmVudCBjb3BpZXMgb2YgdGhlIHNhbWUgZGF0YQ0KPg0KPg0KPj4g KyAgICBhZ2VudF9jaGFubmVsID0gZC0+YXJjaC5zY2lfZGF0YTsNCj4+ICsNCj4+ICsgICAgc3Bp bl9sb2NrKCZhZ2VudF9jaGFubmVsLT5sb2NrKTsNCj4+ICsNCj4+ICsgICAgcmV0ID0gc2NtaV9h c3NpZ25fZGV2aWNlKGFnZW50X2NoYW5uZWwtPmFnZW50X2lkLCBzY21pX2RldmljZV9pZCwNCj4+ ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNDTUlfQkFTRV9ERVZJQ0VfQUNDRVNTX0FM TE9XKTsNCj4+ICsgICAgaWYgKCByZXQgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBwcmludGso WEVOTE9HX0VSUg0KPj4gKyAgICAgICAgICAgICAgICJzY21pOiBjb3VsZCBub3QgYXNzaWduIGRl diBmb3IgJXBkIGFnZW50OiVkIGRldl9pZDoldSAoJWQpIiwNCj4+ICsgICAgICAgICAgICAgICBk LCBhZ2VudF9jaGFubmVsLT5hZ2VudF9pZCwgc2NtaV9kZXZpY2VfaWQsIHJldCk7DQo+PiArICAg IH0NCj4+ICsNCj4+ICsgICAgc3Bpbl91bmxvY2soJmFnZW50X2NoYW5uZWwtPmxvY2spOw0KPj4g KyAgICByZXR1cm4gcmV0Ow0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgaW50IGNvbGxlY3RfYWdl bnRfaWQoc3RydWN0IHNjbWlfY2hhbm5lbCAqYWdlbnRfY2hhbm5lbCkNCj4+ICt7DQo+PiArICAg IGludCByZXQ7DQo+PiArICAgIHNjbWlfbXNnX2hlYWRlcl90IGhkcjsNCj4+ICsgICAgc3RydWN0 IHNjbWlfbXNnX2Jhc2VfZGlzY292ZXJfYWdlbnRfcDJhIGRhX3J4Ow0KPj4gKyAgICBzdHJ1Y3Qg c2NtaV9tc2dfYmFzZV9kaXNjb3Zlcl9hZ2VudF9hMnAgZGFfdHg7DQo+PiArDQo+PiArICAgIHJl dCA9IG1hcF9jaGFubmVsX21lbW9yeShhZ2VudF9jaGFubmVsKTsNCj4+ICsgICAgaWYgKCByZXQg KQ0KPj4gKyAgICAgICAgcmV0dXJuIHJldDsNCj4+ICsNCj4+ICsgICAgaGRyLmlkID0gU0NNSV9C QVNFX0RJU0NPVkVSX0FHRU5UOw0KPj4gKyAgICBoZHIudHlwZSA9IDA7DQo+PiArICAgIGhkci5w cm90b2NvbCA9IFNDTUlfQkFTRV9QUk9UT0NPTDsNCj4+ICsNCj4+ICsgICAgZGFfdHguYWdlbnRf aWQgPSBhZ2VudF9jaGFubmVsLT5hZ2VudF9pZDsNCj4+ICsNCj4+ICsgICAgcmV0ID0gZG9fc21j X3hmZXIoYWdlbnRfY2hhbm5lbCwgJmhkciwgJmRhX3R4LCBzaXplb2YoZGFfdHgpLCAmZGFfcngs DQo+PiArICAgICAgICAgICAgICAgICAgICAgICAgc2l6ZW9mKGRhX3J4KSk7DQo+PiArICAgIGlm ICggYWdlbnRfY2hhbm5lbC0+ZG9tYWluX2lkICE9IERPTUlEX1hFTiApDQo+PiArICAgICAgICB1 bm1hcF9jaGFubmVsX21lbW9yeShhZ2VudF9jaGFubmVsKTsNCj4+ICsgICAgaWYgKCByZXQgKQ0K Pj4gKyAgICAgICAgcmV0dXJuIHJldDsNCj4+ICsNCj4+ICsgICAgcHJpbnRrKFhFTkxPR19ERUJV RyAiaWQ9MHgleCBuYW1lPSVzXG4iLCBkYV9yeC5hZ2VudF9pZCwgZGFfcngubmFtZSk7DQo+PiAr ICAgIGFnZW50X2NoYW5uZWwtPmFnZW50X2lkID0gZGFfcnguYWdlbnRfaWQ7DQo+PiArICAgIHJl dHVybiAwOw0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgX19pbml0IGludCBjb2xsZWN0X2FnZW50 cyhzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKnNjbWlfbm9kZSkNCj4+ICt7DQo+PiArICAgIGNvbnN0 IHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqY29uZmlnX25vZGU7DQo+PiArICAgIGNvbnN0IF9fYmUz MiAqcHJvcDsNCj4+ICsgICAgdWludDMyX3QgbGVuOw0KPj4gKyAgICBjb25zdCBfX2JlMzIgKmVu ZDsNCj4+ICsgICAgdWludDMyX3QgY2VsbHNfcGVyX2VudHJ5ID0gMzsgLyogRGVmYXVsdCB0byAz IGNlbGxzIGlmIHByb3BlcnR5IGlzIGFic2VudC4gKi8NCj4+ICsNCj4+ICsgICAgY29uZmlnX25v ZGUgPSBkdF9maW5kX2NvbXBhdGlibGVfbm9kZShOVUxMLCBOVUxMLCAieGVuLHNjaSIpOw0KPj4g KyAgICBpZiAoICFjb25maWdfbm9kZSApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHByaW50ayhY RU5MT0dfV0FSTklORyAic2NtaTogeGVuLHNjaSBub2RlIG5vdCBmb3VuZCwgbm8gYWdlbnRzIHRv IGNvbGxlY3QuXG4iKTsNCj4+ICsgICAgICAgIHJldHVybiAtRU5PRU5UOw0KPj4gKyAgICB9DQo+ PiArDQo+PiArICAgIC8qIENoZWNrIGZvciB0aGUgb3B0aW9uYWwgJyNzY21pLXNlY29uZGFyeS1h Z2VudHMtY2VsbHMnIHByb3BlcnR5LiAqLw0KPj4gKyAgICBpZiAoIGR0X3Byb3BlcnR5X3JlYWRf dTMyKGNvbmZpZ19ub2RlLCAiI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxscyIsDQo+PiArICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmNlbGxzX3Blcl9lbnRyeSkgKQ0KPj4gKyAgICB7 DQo+PiArICAgICAgICBpZiAoIGNlbGxzX3Blcl9lbnRyeSAhPSAyICYmIGNlbGxzX3Blcl9lbnRy eSAhPSAzICkNCj4+ICsgICAgICAgIHsNCj4+ICsgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VS UiAic2NtaTogSW52YWxpZCAjc2NtaS1zZWNvbmRhcnktYWdlbnRzLWNlbGxzIHZhbHVlOiAldVxu IiwNCj4+ICsgICAgICAgICAgICAgICAgICAgY2VsbHNfcGVyX2VudHJ5KTsNCj4+ICsgICAgICAg ICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsgICAgICAgIH0NCj4+ICsgICAgfQ0KPj4gKw0KPj4g KyAgICBwcm9wID0gZHRfZ2V0X3Byb3BlcnR5KGNvbmZpZ19ub2RlLCBTQ01JX1NFQ09OREFSWV9B R0VOVFMsICZsZW4pOw0KPj4gKyAgICBpZiAoICFwcm9wICkNCj4+ICsgICAgew0KPj4gKyAgICAg ICAgcHJpbnRrKFhFTkxPR19FUlIgInNjbWk6IE5vICVzIHByb3BlcnR5IGZvdW5kLCBubyBhZ2Vu dHMgdG8gY29sbGVjdC5cbiIsDQo+PiArICAgICAgICAgICAgICAgU0NNSV9TRUNPTkRBUllfQUdF TlRTKTsNCj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gKyAgICB9DQo+PiArDQo+PiAr ICAgIC8qIFZhbGlkYXRlIHRoYXQgdGhlIHByb3BlcnR5IGxlbmd0aCBpcyBhIG11bHRpcGxlIG9m IHRoZSBjZWxsIHNpemUuICovDQo+PiArICAgIGlmICggbGVuID09IDAgfHwgbGVuICUgKGNlbGxz X3Blcl9lbnRyeSAqIHNpemVvZih1aW50MzJfdCkpICE9IDAgKQ0KPj4gKyAgICB7DQo+PiArICAg ICAgICBwcmludGsoWEVOTE9HX0VSUiAic2NtaTogSW52YWxpZCBsZW5ndGggb2YgJXMgcHJvcGVy dHk6ICV1IGZvciAldSBjZWxscyBwZXIgZW50cnlcbiIsDQo+PiArICAgICAgICAgICAgICAgU0NN SV9TRUNPTkRBUllfQUdFTlRTLCBsZW4sIGNlbGxzX3Blcl9lbnRyeSk7DQo+PiArICAgICAgICBy ZXR1cm4gLUVJTlZBTDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBlbmQgPSAoY29uc3QgX19i ZTMyICopKChjb25zdCB1OCAqKXByb3AgKyBsZW4pOw0KPj4gKw0KPj4gKyAgICBmb3IgKCA7IHBy b3AgPCBlbmQ7ICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgdWludDMyX3QgYWdlbnRfaWQ7DQo+ PiArICAgICAgICB1aW50MzJfdCBzbWNfaWQ7DQo+PiArICAgICAgICB1aW50MzJfdCBzaG1lbV9w aGFuZGxlOw0KPj4gKyAgICAgICAgc3RydWN0IGR0X2RldmljZV9ub2RlICpub2RlOw0KPj4gKyAg ICAgICAgdTY0IGFkZHIsIHNpemU7DQo+PiArICAgICAgICBpbnQgcmV0Ow0KPj4gKyAgICAgICAg c3RydWN0IHNjbWlfY2hhbm5lbCAqYWdlbnRfY2hhbm5lbDsNCj4+ICsNCj4+ICsgICAgICAgIHNt Y19pZCA9IGJlMzJfdG9fY3B1KCpwcm9wKyspOw0KPj4gKyAgICAgICAgc2htZW1fcGhhbmRsZSA9 IGJlMzJfdG9fY3B1KCpwcm9wKyspOw0KPj4gKw0KPj4gKyAgICAgICAgaWYgKCBjZWxsc19wZXJf ZW50cnkgPT0gMyApDQo+PiArICAgICAgICAgICAgYWdlbnRfaWQgPSBiZTMyX3RvX2NwdSgqcHJv cCsrKTsNCj4+ICsgICAgICAgIGVsc2UNCj4+ICsgICAgICAgICAgICBhZ2VudF9pZCA9IFNDTUlf QkFTRV9BR0VOVF9JRF9PV047DQo+PiArDQo+PiArICAgICAgICBub2RlID0gZHRfZmluZF9ub2Rl X2J5X3BoYW5kbGUoc2htZW1fcGhhbmRsZSk7DQo+PiArICAgICAgICBpZiAoICFub2RlICkNCj4+ ICsgICAgICAgIHsNCj4+ICsgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAic2NtaTogQ291 bGQgbm90IGZpbmQgc2htZW0gbm9kZSBmb3IgYWdlbnQgJXVcbiIsDQo+PiArICAgICAgICAgICAg ICAgICAgIGFnZW50X2lkKTsNCj4+ICsgICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsg ICAgICAgIH0NCj4+ICsNCj4+ICsgICAgICAgIHJldCA9IGR0X2RldmljZV9nZXRfYWRkcmVzcyhu b2RlLCAwLCAmYWRkciwgJnNpemUpOw0KPj4gKyAgICAgICAgaWYgKCByZXQgKQ0KPj4gKyAgICAg ICAgew0KPj4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSDQo+PiArICAgICAgICAgICAg ICAgICAgICJzY21pOiBDb3VsZCBub3QgcmVhZCBzaG1lbSBhZGRyZXNzIGZvciBhZ2VudCAldTog JWRcbiIsDQo+PiArICAgICAgICAgICAgICAgICAgIGFnZW50X2lkLCByZXQpOw0KPj4gKyAgICAg ICAgICAgIHJldHVybiByZXQ7DQo+PiArICAgICAgICB9DQo+PiArDQo+PiArICAgICAgICBpZiAo ICFJU19BTElHTkVEKHNpemUsIFNDTUlfU0hNRU1fTUFQUEVEX1NJWkUpICkNCj4+ICsgICAgICAg IHsNCj4+ICsgICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAic2NtaTogc2htZW0gbWVtb3J5 IGlzIG5vdCBhbGlnbmVkXG4iKTsNCj4+ICsgICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ ICsgICAgICAgIH0NCj4+ICsNCj4+ICsgICAgICAgIGFnZW50X2NoYW5uZWwgPSBzbWNfY3JlYXRl X2NoYW5uZWwoYWdlbnRfaWQsIHNtY19pZCwgYWRkcik7DQo+PiArICAgICAgICBpZiAoIElTX0VS UihhZ2VudF9jaGFubmVsKSApDQo+PiArICAgICAgICB7DQo+PiArICAgICAgICAgICAgcHJpbnRr KFhFTkxPR19FUlIgInNjbWk6IENvdWxkIG5vdCBjcmVhdGUgY2hhbm5lbCBmb3IgYWdlbnQgJXU6 ICVsZFxuIiwNCj4+ICsgICAgICAgICAgICAgICAgICAgYWdlbnRfaWQsIFBUUl9FUlIoYWdlbnRf Y2hhbm5lbCkpOw0KPj4gKyAgICAgICAgICAgIHJldHVybiBQVFJfRVJSKGFnZW50X2NoYW5uZWwp Ow0KPj4gKyAgICAgICAgfQ0KPj4gKw0KPj4gKyAgICAgICAgaWYgKCBjZWxsc19wZXJfZW50cnkg PT0gMiApDQo+PiArICAgICAgICB7DQo+PiArICAgICAgICAgICAgcmV0ID0gY29sbGVjdF9hZ2Vu dF9pZChhZ2VudF9jaGFubmVsKTsNCj4+ICsgICAgICAgICAgICBpZiAoIHJldCApDQo+PiArICAg ICAgICAgICAgICAgIHJldHVybiByZXQ7DQo+PiArICAgICAgICB9DQo+PiArDQo+PiArICAgICAg ICBwcmludGsoWEVOTE9HX0RFQlVHICJzY21pOiBBZ2VudCAldSBTTUMgJVggYWRkciAlbHhcbiIs IGFnZW50X2NoYW5uZWwtPmFnZW50X2lkLA0KPj4gKyAgICAgICAgICAgICAgIHNtY19pZCwgKHVu c2lnbmVkIGxvbmcpYWRkcik7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcmV0dXJuIDA7DQo+ PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBpbnQgc2NtaV9kb21haW5faW5pdChzdHJ1Y3QgZG9tYWlu ICpkLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9j cmVhdGVkb21haW4gKmNvbmZpZykNCj4+ICt7DQo+PiArICAgIHN0cnVjdCBzY21pX2NoYW5uZWwg KmNoYW5uZWw7DQo+PiArICAgIGludCByZXQ7DQo+PiArDQo+PiArICAgIGlmICggIXNjbWlfZGF0 YS5pbml0aWFsaXplZCApDQo+PiArICAgICAgICByZXR1cm4gMDsNCj4+ICsNCj4+ICsgICAgLyoN Cj4+ICsgICAgICogU0NNSSBzdXBwb3J0IGlzIGNvbmZpZ3VyZWQgdmlhOg0KPj4gKyAgICAgKiAt IEZvciBkb20wOiB4ZW4sZG9tMC1zY2ktYWdlbnQtaWQgcHJvcGVydHkgdW5kZXIgdGhlIHhlbixz Y2kgY29udGFpbmVyDQo+PiArICAgICAqIC0gRm9yIGRvbTBsZXNzOiB4ZW4sc2NpLWFnZW50LWlk IGluIHRoZSBkb21haW4gbm9kZQ0KPj4gKyAgICAgKiBUaGUgY29uZmlnLT5hcmNoLmFybV9zY2lf dHlwZSBhbmQgY29uZmlnLT5hcmNoLmFybV9zY2lfYWdlbnRfaWQNCj4+ICsgICAgICogYXJlIGFs cmVhZHkgc2V0IGJ5IGRvbWFpbl9idWlsZC5jIG9yIGRvbTBsZXNzLWJ1aWxkLmMNCj4+ICsgICAg ICovDQo+PiArDQo+PiArICAgIGlmICggY29uZmlnLT5hcmNoLmFybV9zY2lfdHlwZSA9PSBYRU5f RE9NQ1RMX0NPTkZJR19BUk1fU0NJX05PTkUgKQ0KPj4gKyAgICAgICAgcmV0dXJuIDA7DQo+PiAr DQo+PiArICAgIGNoYW5uZWwgPSBhY3F1aXJlX3NjbWlfY2hhbm5lbChkLCBjb25maWctPmFyY2gu YXJtX3NjaV9hZ2VudF9pZCk7DQo+PiArICAgIGlmICggSVNfRVJSKGNoYW5uZWwpICkNCj4+ICsg ICAgew0KPj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlINCj4+ICsgICAgICAgICAgICAgICAi c2NtaTogRmFpbGVkIHRvIGFjcXVpcmUgU0NNSSBjaGFubmVsIGZvciBhZ2VudF9pZCAldTogJWxk XG4iLA0KPj4gKyAgICAgICAgICAgICAgIGNvbmZpZy0+YXJjaC5hcm1fc2NpX2FnZW50X2lkLCBQ VFJfRVJSKGNoYW5uZWwpKTsNCj4+ICsgICAgICAgIHJldHVybiBQVFJfRVJSKGNoYW5uZWwpOw0K Pj4gKyAgICB9DQo+PiArDQo+PiArICAgIHByaW50ayhYRU5MT0dfSU5GTw0KPj4gKyAgICAgICAg ICAgInNjbWk6IEFjcXVpcmUgY2hhbm5lbCBpZCA9IDB4JXgsIGRvbWFpbl9pZCA9ICVkIHBhZGRy ID0gMHglbHhcbiIsDQo+PiArICAgICAgICAgICBjaGFubmVsLT5hZ2VudF9pZCwgY2hhbm5lbC0+ ZG9tYWluX2lkLCBjaGFubmVsLT5wYWRkcik7DQo+PiArDQo+PiArICAgIC8qDQo+PiArICAgICAq IERvbTAgKGlmIHByZXNlbnQpIG5lZWRzIHRvIGhhdmUgYW4gYWNjZXNzIHRvIHRoZSBndWVzdCBt ZW1vcnkgcmFuZ2UNCj4+ICsgICAgICogdG8gc2F0aXNmeSBpb21lbV9hY2Nlc3NfcGVybWl0dGVk KCkgY2hlY2sgaW4gWEVOX0RPTUNUTF9pb21lbV9wZXJtaXNzaW9uDQo+PiArICAgICAqIGRvbWN0 bC4NCj4+ICsgICAgICovDQo+PiArICAgIGlmICggaGFyZHdhcmVfZG9tYWluICYmICFpc19oYXJk d2FyZV9kb21haW4oZCkgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICByZXQgPSBpb21lbV9wZXJt aXRfYWNjZXNzKGhhcmR3YXJlX2RvbWFpbiwgcGFkZHJfdG9fcGZuKGNoYW5uZWwtPnBhZGRyKSwN Cj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFkZHJfdG9fcGZuKGNoYW5u ZWwtPnBhZGRyICsgUEFHRV9TSVpFIC0gMSkpOw0KPj4gKyAgICAgICAgaWYgKCByZXQgKQ0KPj4g KyAgICAgICAgICAgIGdvdG8gZXJyb3I7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgZC0+YXJj aC5zY2lfZGF0YSA9IGNoYW5uZWw7DQo+PiArICAgIGQtPmFyY2guc2NpX2VuYWJsZWQgPSB0cnVl Ow0KPj4gKw0KPj4gKyAgICByZXR1cm4gMDsNCj4+ICsNCj4+ICtlcnJvcjoNCj4+ICsgICAgcmVs aW5xdWlzaF9zY21pX2NoYW5uZWwoY2hhbm5lbCk7DQo+PiArICAgIHJldHVybiByZXQ7DQo+PiAr fQ0KPj4gKw0KPj4gK2ludCBzY21pX2RvbWFpbl9zYW5pdGlzZV9jb25maWcoc3RydWN0IHhlbl9k b21jdGxfY3JlYXRlZG9tYWluICpjb25maWcpDQo+PiArew0KPj4gKyAgICBpZiAoIGNvbmZpZy0+ YXJjaC5hcm1fc2NpX3R5cGUgIT0gWEVOX0RPTUNUTF9DT05GSUdfQVJNX1NDSV9OT05FICYmDQo+ PiArICAgICAgICAgY29uZmlnLT5hcmNoLmFybV9zY2lfdHlwZSAhPSBYRU5fRE9NQ1RMX0NPTkZJ R19BUk1fU0NJX1NDTUlfU01DX01BICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgZHByaW50ayhY RU5MT0dfSU5GTywgInNjbWk6IFVuc3VwcG9ydGVkIEFSTV9TQ0kgdHlwZVxuIik7DQo+PiArICAg ICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICByZXR1cm4gMDsN Cj4+ICt9DQo+PiArDQo+PiArc3RhdGljIGludCBzY21pX3JlbGlucXVpc2hfcmVzb3VyY2VzKHN0 cnVjdCBkb21haW4gKmQpDQo+PiArew0KPj4gKyAgICBpbnQgcmV0Ow0KPj4gKyAgICBzdHJ1Y3Qg c2NtaV9jaGFubmVsICpjaGFubmVsLCAqYWdlbnRfY2hhbm5lbDsNCj4+ICsgICAgc2NtaV9tc2df aGVhZGVyX3QgaGRyOw0KPj4gKyAgICBzdHJ1Y3Qgc2NtaV9tc2dfYmFzZV9yZXNldF9hZ2VudF9j ZmdfYTJwIHR4Ow0KPj4gKw0KPj4gKyAgICBpZiAoICFkLT5hcmNoLnNjaV9kYXRhICkNCj4+ICsg ICAgICAgIHJldHVybiAwOw0KPj4gKw0KPj4gKyAgICBhZ2VudF9jaGFubmVsID0gZC0+YXJjaC5z Y2lfZGF0YTsNCj4+ICsNCj4+ICsgICAgc3Bpbl9sb2NrKCZhZ2VudF9jaGFubmVsLT5sb2NrKTsN Cj4+ICsgICAgdHguYWdlbnRfaWQgPSBhZ2VudF9jaGFubmVsLT5hZ2VudF9pZDsNCj4+ICsgICAg c3Bpbl91bmxvY2soJmFnZW50X2NoYW5uZWwtPmxvY2spOw0KPj4gKw0KPj4gKyAgICBjaGFubmVs ID0gZ2V0X2NoYW5uZWxfYnlfaWQoc2NtaV9kYXRhLmh5cF9jaGFubmVsX2FnZW50X2lkKTsNCj4+ ICsgICAgaWYgKCAhY2hhbm5lbCApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHByaW50ayhYRU5M T0dfRVJSDQo+PiArICAgICAgICAgICAgICAgInNjbWk6IFVuYWJsZSB0byBnZXQgSHlwZXJ2aXNv ciBzY21pIGNoYW5uZWwgZm9yIGRvbWFpbiAlZFxuIiwNCj4+ICsgICAgICAgICAgICAgICBkLT5k b21haW5faWQpOw0KPj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+PiArICAgIH0NCj4+ICsN Cj4+ICsgICAgaGRyLmlkID0gU0NNSV9CQVNFX1JFU0VUX0FHRU5UX0NPTkZJR1VSQVRJT047DQo+ PiArICAgIGhkci50eXBlID0gMDsNCj4+ICsgICAgaGRyLnByb3RvY29sID0gU0NNSV9CQVNFX1BS T1RPQ09MOw0KPj4gKw0KPj4gKyAgICB0eC5mbGFncyA9IDA7DQo+IGlzIHRoaXMgY29ycmVjdD8N Cj4NCj4NCj4+ICsgICAgcmV0ID0gZG9fc21jX3hmZXIoY2hhbm5lbCwgJmhkciwgJnR4LCBzaXpl b2YodHgpLCBOVUxMLCAwKTsNCj4+ICsgICAgaWYgKCByZXQgPT0gLUVPUE5PVFNVUFAgKQ0KPj4g KyAgICAgICAgcmV0dXJuIDA7DQo+PiArDQo+PiArICAgIHJldHVybiByZXQ7DQo+PiArfQ0KPj4g Kw0KPj4gK3N0YXRpYyB2b2lkIHNjbWlfZG9tYWluX2Rlc3Ryb3koc3RydWN0IGRvbWFpbiAqZCkN Cj4+ICt7DQo+PiArICAgIHN0cnVjdCBzY21pX2NoYW5uZWwgKmNoYW5uZWw7DQo+PiArDQo+PiAr ICAgIGlmICggIWQtPmFyY2guc2NpX2RhdGEgKQ0KPj4gKyAgICAgICAgcmV0dXJuOw0KPj4gKw0K Pj4gKyAgICBjaGFubmVsID0gZC0+YXJjaC5zY2lfZGF0YTsNCj4+ICsgICAgc3Bpbl9sb2NrKCZj aGFubmVsLT5sb2NrKTsNCj4+ICsNCj4+ICsgICAgcmVsaW5xdWlzaF9zY21pX2NoYW5uZWwoY2hh bm5lbCk7DQo+PiArICAgIHByaW50ayhYRU5MT0dfREVCVUcgInNjbWk6IEZyZWUgZG9tYWluICVk XG4iLCBkLT5kb21haW5faWQpOw0KPj4gKw0KPj4gKyAgICBkLT5hcmNoLnNjaV9kYXRhID0gTlVM TDsNCj4+ICsgICAgZC0+YXJjaC5zY2lfZW5hYmxlZCA9IGZhbHNlOw0KPj4gKw0KPj4gKyAgICBz cGluX3VubG9jaygmY2hhbm5lbC0+bG9jayk7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBib29s IHNjbWlfaGFuZGxlX2NhbGwoc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpDQo+PiArew0KPj4g KyAgICB1aW50MzJfdCBmaWQgPSAodWludDMyX3QpZ2V0X3VzZXJfcmVnKHJlZ3MsIDApOw0KPj4g KyAgICBzdHJ1Y3Qgc2NtaV9jaGFubmVsICphZ2VudF9jaGFubmVsOw0KPj4gKyAgICBzdHJ1Y3Qg ZG9tYWluICpkID0gY3VycmVudC0+ZG9tYWluOw0KPj4gKyAgICBzdHJ1Y3QgYXJtX3NtY2NjX3Jl cyByZXNwOw0KPj4gKyAgICBib29sIHJlcyA9IGZhbHNlOw0KPj4gKw0KPj4gKyAgICBpZiAoICFz Y2lfZG9tYWluX2lzX2VuYWJsZWQoZCkgKQ0KPj4gKyAgICAgICAgcmV0dXJuIGZhbHNlOw0KPj4g Kw0KPj4gKyAgICBhZ2VudF9jaGFubmVsID0gZC0+YXJjaC5zY2lfZGF0YTsNCj4+ICsgICAgc3Bp bl9sb2NrKCZhZ2VudF9jaGFubmVsLT5sb2NrKTsNCj4+ICsNCj4+ICsgICAgaWYgKCBhZ2VudF9j aGFubmVsLT5mdW5jX2lkICE9IGZpZCApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHJlcyA9IGZh bHNlOw0KPj4gKyAgICAgICAgZ290byB1bmxvY2s7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAg YXJtX3NtY2NjXzFfMV9zbWMoZmlkLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICBnZXRfdXNl cl9yZWcocmVncywgMSksDQo+PiArICAgICAgICAgICAgICAgICAgICAgIGdldF91c2VyX3JlZyhy ZWdzLCAyKSwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgZ2V0X3VzZXJfcmVnKHJlZ3MsIDMp LA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICBnZXRfdXNlcl9yZWcocmVncywgNCksDQo+PiAr ICAgICAgICAgICAgICAgICAgICAgIGdldF91c2VyX3JlZyhyZWdzLCA1KSwNCj4+ICsgICAgICAg ICAgICAgICAgICAgICAgZ2V0X3VzZXJfcmVnKHJlZ3MsIDYpLA0KPj4gKyAgICAgICAgICAgICAg ICAgICAgICBnZXRfdXNlcl9yZWcocmVncywgNyksDQo+PiArICAgICAgICAgICAgICAgICAgICAg ICZyZXNwKTsNCj4+ICsNCj4+ICsgICAgc2V0X3VzZXJfcmVnKHJlZ3MsIDAsIHJlc3AuYTApOw0K Pj4gKyAgICBzZXRfdXNlcl9yZWcocmVncywgMSwgcmVzcC5hMSk7DQo+PiArICAgIHNldF91c2Vy X3JlZyhyZWdzLCAyLCByZXNwLmEyKTsNCj4+ICsgICAgc2V0X3VzZXJfcmVnKHJlZ3MsIDMsIHJl c3AuYTMpOw0KPj4gKyAgICByZXMgPSB0cnVlOw0KPj4gK3VubG9jazoNCj4+ICsgICAgc3Bpbl91 bmxvY2soJmFnZW50X2NoYW5uZWwtPmxvY2spOw0KPj4gKw0KPj4gKyAgICByZXR1cm4gcmVzOw0K Pj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgY29uc3Qgc3RydWN0IHNjaV9tZWRpYXRvcl9vcHMgc2Nt aV9vcHMgPSB7DQo+PiArICAgIC5kb21haW5faW5pdCA9IHNjbWlfZG9tYWluX2luaXQsDQo+PiAr ICAgIC5kb21haW5fZGVzdHJveSA9IHNjbWlfZG9tYWluX2Rlc3Ryb3ksDQo+PiArICAgIC5yZWxp bnF1aXNoX3Jlc291cmNlcyA9IHNjbWlfcmVsaW5xdWlzaF9yZXNvdXJjZXMsDQo+PiArICAgIC5o YW5kbGVfY2FsbCA9IHNjbWlfaGFuZGxlX2NhbGwsDQo+PiArICAgIC5kb20wX2R0X2hhbmRsZV9u b2RlID0gc2NtaV9kdF9oYW5kbGVfbm9kZSwNCj4+ICsgICAgLmRvbWFpbl9zYW5pdGlzZV9jb25m aWcgPSBzY21pX2RvbWFpbl9zYW5pdGlzZV9jb25maWcsDQo+PiArICAgIC5hc3NpZ25fZHRfZGV2 aWNlID0gc2NtaV9kdF9hc3NpZ25fZGV2aWNlLA0KPj4gK307DQo+PiArDQo+PiArc3RhdGljIGlu dCBfX2luaXQgc2NtaV9jaGVja19zbWNjY192ZXIodm9pZCkNCj4+ICt7DQo+PiArICAgIGlmICgg c21jY2NfdmVyIDwgQVJNX1NNQ0NDX1ZFUlNJT05fMV8xICkNCj4+ICsgICAgew0KPj4gKyAgICAg ICAgcHJpbnRrKFhFTkxPR19XQVJOSU5HDQo+PiArICAgICAgICAgICAgICAgInNjbWk6IE5vIFNN Q0NDIDEuMSBzdXBwb3J0LCBTQ01JIGNhbGxzIGZvcndhcmRpbmcgZGlzYWJsZWRcbiIpOw0KPj4g KyAgICAgICAgcmV0dXJuIC1FTk9TWVM7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcmV0dXJu IDA7DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBpbnQgX19pbml0IHNjbWlfZHRfaHlwX2NoYW5u ZWxfcmVhZChzdHJ1Y3QgZHRfZGV2aWNlX25vZGUgKnNjbWlfbm9kZSwNCj4+ICsgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IHNjbWlfZGF0YSAqc2NtaV9k YXRhLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1NjQg KmFkZHIpDQo+PiArew0KPj4gKyAgICBpbnQgcmV0Ow0KPj4gKyAgICB1NjQgc2l6ZTsNCj4+ICsN Cj4+ICsgICAgaWYgKCAhZHRfcHJvcGVydHlfcmVhZF91MzIoc2NtaV9ub2RlLCAiYXJtLHNtYy1p ZCIsICZzY21pX2RhdGEtPmZ1bmNfaWQpICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJpbnRr KFhFTkxPR19FUlIgInNjbWk6IHVuYWJsZSB0byByZWFkIHNtYy1pZCBmcm9tIERUXG4iKTsNCj4+ ICsgICAgICAgIHJldHVybiAtRU5PRU5UOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIHJldCA9 IHNjbWlfZHRfcmVhZF9oeXBfY2hhbm5lbF9hZGRyKHNjbWlfbm9kZSwgYWRkciwgJnNpemUpOw0K Pj4gKyAgICBpZiAoIElTX0VSUl9WQUxVRShyZXQpICkNCj4+ICsgICAgICAgIHJldHVybiAtRU5P RU5UOw0KPj4gKw0KPj4gKyAgICBpZiAoICFJU19BTElHTkVEKHNpemUsIFNDTUlfU0hNRU1fTUFQ UEVEX1NJWkUpICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcHJpbnRrKFhFTkxPR19FUlIgInNj bWk6IHNobWVtIG1lbW9yeSBpcyBub3QgYWxpZ25lZFxuIik7DQo+PiArICAgICAgICByZXR1cm4g LUVJTlZBTDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICByZXR1cm4gMDsNCj4+ICt9DQo+PiAr DQo+PiArc3RhdGljIF9faW5pdCBpbnQgc2NtaV9wcm9iZShzdHJ1Y3QgZHRfZGV2aWNlX25vZGUg KnNjbWlfbm9kZSwgY29uc3Qgdm9pZCAqZGF0YSkNCj4+ICt7DQo+PiArICAgIHU2NCBhZGRyOw0K Pj4gKyAgICBpbnQgcmV0Ow0KPj4gKyAgICBzdHJ1Y3Qgc2NtaV9jaGFubmVsICpjaGFubmVsOw0K Pj4gKyAgICB1bnNpZ25lZCBpbnQgbl9hZ2VudHM7DQo+PiArICAgIHNjbWlfbXNnX2hlYWRlcl90 IGhkcjsNCj4+ICsgICAgc3RydWN0IHNjbWlfbXNnX2Jhc2VfYXR0cmlidXRlc19wMmEgcng7DQo+ PiArDQo+PiArICAgIEFTU0VSVChzY21pX25vZGUgIT0gTlVMTCk7DQo+PiArDQo+PiArICAgIC8q DQo+PiArICAgICAqIE9ubHkgYmluZCB0byB0aGUgU0NNSSBub2RlIHByb3ZpZGVkIGJ5IFhlbiB1 bmRlciB0aGUgeGVuLHNjaSBjb250YWluZXINCj4+ICsgICAgICogKGUuZy4gL2Nob3Nlbi94ZW4v eGVuX3NjbWlfY29uZmlnL3NjbWkpLiBUaGlzIGF2b2lkcyBiaW5kaW5nIHRvIGZpcm13YXJlDQo+ PiArICAgICAqIFNDTUkgbm9kZXMgdGhhdCBiZWxvbmcgdG8gdGhlIGhvc3QgT1NQTSBhbmQga2Vl cHMgdGhlIG1lZGlhdG9yIHNjb3BlZCB0bw0KPj4gKyAgICAgKiBYZW4tcHJvdmlkZWQgY29uZmln dXJhdGlvbiBvbmx5Lg0KPj4gKyAgICAgKi8NCj4+ICsgICAgaWYgKCAhc2NtaV9pc191bmRlcl94 ZW5fc2NpKHNjbWlfbm9kZSkgKQ0KPj4gKyAgICAgICAgcmV0dXJuIC1FTk9ERVY7DQo+PiArDQo+ PiArICAgIElOSVRfTElTVF9IRUFEKCZzY21pX2RhdGEuY2hhbm5lbF9saXN0KTsNCj4+ICsgICAg c3Bpbl9sb2NrX2luaXQoJnNjbWlfZGF0YS5jaGFubmVsX2xpc3RfbG9jayk7DQo+PiArDQo+PiAr ICAgIGlmICggIWFjcGlfZGlzYWJsZWQgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBwcmludGso WEVOTE9HX1dBUk5JTkcgInNjbWk6IGlzIG5vdCBzdXBwb3J0ZWQgd2hlbiB1c2luZyBBQ1BJXG4i KTsNCj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAg IHJldCA9IHNjbWlfY2hlY2tfc21jY2NfdmVyKCk7DQo+PiArICAgIGlmICggcmV0ICkNCj4+ICsg ICAgICAgIHJldHVybiByZXQ7DQo+PiArDQo+PiArICAgIHJldCA9IHNjbWlfZHRfaHlwX2NoYW5u ZWxfcmVhZChzY21pX25vZGUsICZzY21pX2RhdGEsICZhZGRyKTsNCj4+ICsgICAgaWYgKCByZXQg KQ0KPj4gKyAgICAgICAgcmV0dXJuIHJldDsNCj4+ICsNCj4+ICsgICAgc2NtaV9kYXRhLmR0X2Rl diA9IHNjbWlfbm9kZTsNCj4+ICsNCj4+ICsgICAgY2hhbm5lbCA9IHNtY19jcmVhdGVfY2hhbm5l bChTQ01JX0JBU0VfQUdFTlRfSURfT1dOLCBzY21pX2RhdGEuZnVuY19pZCwgYWRkcik7DQo+PiAr ICAgIGlmICggSVNfRVJSKGNoYW5uZWwpICkNCj4+ICsgICAgICAgIGdvdG8gb3V0Ow0KPj4gKw0K Pj4gKyAgICAvKiBNYXJrIGFzIFhlbiBtYW5hZ2VtZW50IGNoYW5uZWwgYmVmb3JlIGNvbGxlY3Rp bmcgYWdlbnQgSUQgKi8NCj4+ICsgICAgY2hhbm5lbC0+ZG9tYWluX2lkID0gRE9NSURfWEVOOw0K Pj4gKw0KPj4gKyAgICAvKiBSZXF1ZXN0IGFnZW50IGlkIGZvciBYZW4gbWFuYWdlbWVudCBjaGFu bmVsICAqLw0KPj4gKyAgICByZXQgPSBjb2xsZWN0X2FnZW50X2lkKGNoYW5uZWwpOw0KPj4gKyAg ICBpZiAoIHJldCApDQo+PiArICAgICAgICBnb3RvIGVycm9yOw0KPj4gKw0KPj4gKyAgICAvKiBT YXZlIHRoZSBhZ2VudCBpZCBmb3IgWGVuIG1hbmFnZW1lbnQgY2hhbm5lbCAqLw0KPj4gKyAgICBz Y21pX2RhdGEuaHlwX2NoYW5uZWxfYWdlbnRfaWQgPSBjaGFubmVsLT5hZ2VudF9pZDsNCj4+ICsN Cj4+ICsgICAgaGRyLmlkID0gU0NNSV9CQVNFX1BST1RPQ09MX0FUVElCVVRFUzsNCj4+ICsgICAg aGRyLnR5cGUgPSAwOw0KPj4gKyAgICBoZHIucHJvdG9jb2wgPSBTQ01JX0JBU0VfUFJPVE9DT0w7 DQo+PiArDQo+PiArICAgIHJldCA9IGRvX3NtY194ZmVyKGNoYW5uZWwsICZoZHIsIE5VTEwsIDAs ICZyeCwgc2l6ZW9mKHJ4KSk7DQo+PiArICAgIGlmICggcmV0ICkNCj4+ICsgICAgICAgIGdvdG8g ZXJyb3I7DQo+PiArDQo+PiArICAgIG5fYWdlbnRzID0gU0NNSV9GSUVMRF9HRVQoU0NNSV9CQVNF X0FUVFJfTlVNX0FHRU5ULCByeC5hdHRyaWJ1dGVzKTsNCj4+ICsgICAgcHJpbnRrKFhFTkxPR19E RUJVRyAic2NtaTogR290IGFnZW50IGNvdW50ICVkXG4iLCBuX2FnZW50cyk7DQo+PiArICAgIHJl dCA9IGNvbGxlY3RfYWdlbnRzKHNjbWlfbm9kZSk7DQo+PiArICAgIGlmICggcmV0ICkNCj4+ICsg ICAgICAgIGdvdG8gZXJyb3I7DQo+PiArDQo+PiArICAgIHJldCA9IHNjaV9yZWdpc3Rlcigmc2Nt aV9vcHMpOw0KPj4gKyAgICBpZiAoIHJldCApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHByaW50 ayhYRU5MT0dfRVJSICJTQ01JOiBtZWRpYXRvciBhbHJlYWR5IHJlZ2lzdGVyZWQgKHJldCA9ICVk KVxuIiwNCj4+ICsgICAgICAgICAgICAgICByZXQpOw0KPj4gKyAgICAgICAgcmV0dXJuIHJldDsN Cj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBzY21pX2RhdGEuaW5pdGlhbGl6ZWQgPSB0cnVlOw0K Pj4gKyAgICBnb3RvIG91dDsNCj4+ICsNCj4+ICtlcnJvcjoNCj4+ICsgICAgdW5tYXBfY2hhbm5l bF9tZW1vcnkoY2hhbm5lbCk7DQo+IFRoaXMgbWlnaHQgY2F1c2UgdGhlIEFTU0VSVCBhdCB0aGUg YmVnaW5uaW5nIG9mIHVubWFwX2NoYW5uZWxfbWVtb3J5IHRvDQo+IHRyaWdnZXINCj4NCj4NCkdy ZWF0IGZpbmRpbmcuLi4gRmlyc3QgYGdvdG8gZXJyb3JgIGNvdWxkIGJlIGNhbGxlZCBhZnRlciAN CmBjb2xsZWN0X2FnZW50X2lkYC4NClNvIGluIGNhc2UgaWYgd2UgcmVjZWl2ZSAtRU5PTUVNIGZy b20gYGlvcmVtYXBfbm9jYWNoZWAgaW5zaWRlIA0KYG1hcF9jaGFubmVsX21lbW9yeWANCkFTU0VS VCB3aWxsIGZpcmUuDQoNCkknbSBwbGFubmluZyB0byByZWZhY3RvciB0aGlzIGFzIGZvbGxvd3M6 DQoNCiDCoMKgwqAgc3RhdGljIHZvaWQgdW5tYXBfY2hhbm5lbF9tZW1vcnkoc3RydWN0IHNjbWlf Y2hhbm5lbCAqY2hhbm5lbCkNCiDCoMKgwqAgew0KIMKgwqDCoCDCoMKgwqAgQVNTRVJUKGNoYW5u ZWwpOw0KDQogwqDCoMKgIMKgwqDCoCBpZiAoICFjaGFubmVsLT5zaG1lbSApDQogwqDCoMKgwqDC oMKgwqAgwqDCoMKgIHJldHVybjsNCiDCoMKgwqAgwqDCoMKgIC4uLg0KIMKgwqDCoMKgIH0NCg0K VGhpcyB3aWxsIGNhdXNlIGZ1bmN0aW9uIHRvIHNraXAgaW91bm1hcCBpZiBzaG1lbSBpcyBOVUxM Ow0KV2hhdCBkbyB5b3UgdGhpbms/DQo+PiArICAgIGZyZWVfY2hhbm5lbF9saXN0KCk7DQo+PiAr b3V0Og0KPj4gKyAgICByZXR1cm4gcmV0Ow0KPj4gK30NCj4+ICsNCj4+ICtzdGF0aWMgY29uc3Qg c3RydWN0IGR0X2RldmljZV9tYXRjaCBzY21pX3NtY19tYXRjaFtdIF9faW5pdGNvbnN0ID0gew0K Pj4gKyAgICBEVF9NQVRDSF9DT01QQVRJQkxFKCJhcm0sc2NtaS1zbWMiKSwNCj4+ICsgICAgeyAv KiBzZW50aW5lbCAqLyB9LA0KPj4gK307DQo+PiArDQo+PiArRFRfREVWSUNFX1NUQVJUKHNjbWlf c21jX21hLCAiU0NNSSBTTUMgTUVESUFUT1IiLCBERVZJQ0VfRklSTVdBUkUpDQo+PiArICAgICAg ICAuZHRfbWF0Y2ggPSBzY21pX3NtY19tYXRjaCwNCj4+ICsgICAgICAgIC5pbml0ID0gc2NtaV9w cm9iZSwNCj4+ICtEVF9ERVZJQ0VfRU5EDQo+PiArDQo+PiArLyoNCj4+ICsgKiBMb2NhbCB2YXJp YWJsZXM6DQo+PiArICogbW9kZTogQw0KPj4gKyAqIGMtZmlsZS1zdHlsZTogIkJTRCINCj4+ICsg KiBjLWJhc2ljLW9mZnNldDogNA0KPj4gKyAqIHRhYi13aWR0aDogNA0KPj4gKyAqIGluZGVudC10 YWJzLW1vZGU6IG5pbA0KPj4gKyAqIEVuZDoNCj4+ICsgKi8NCj4+IGRpZmYgLS1naXQgYS94ZW4v aW5jbHVkZS9wdWJsaWMvYXJjaC1hcm0uaCBiL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLWFybS5o DQo+PiBpbmRleCBkMzBhMjg4NTkyLi44ZjBmNjg1NDRlIDEwMDY0NA0KPj4gLS0tIGEveGVuL2lu Y2x1ZGUvcHVibGljL2FyY2gtYXJtLmgNCj4+ICsrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNo LWFybS5oDQo+PiBAQCAtMzI5LDYgKzMyOSw3IEBAIERFRklORV9YRU5fR1VFU1RfSEFORExFKHZj cHVfZ3Vlc3RfY29udGV4dF90KTsNCj4+ICAgDQo+PiAgICNkZWZpbmUgWEVOX0RPTUNUTF9DT05G SUdfQVJNX1NDSV9OT05FICAgICAgMA0KPj4gICAjZGVmaW5lIFhFTl9ET01DVExfQ09ORklHX0FS TV9TQ0lfU0NNSV9TTUMgIDENCj4+ICsjZGVmaW5lIFhFTl9ET01DVExfQ09ORklHX0FSTV9TQ0lf U0NNSV9TTUNfTUEgIDINCj4+ICAgDQo+PiAgIHN0cnVjdCB4ZW5fYXJjaF9kb21haW5jb25maWcg ew0KPj4gICAgICAgLyogSU4vT1VUICovDQo+PiBAQCAtMzU1LDYgKzM1Niw4IEBAIHN0cnVjdCB4 ZW5fYXJjaF9kb21haW5jb25maWcgew0KPj4gICAgICAgdWludDMyX3QgY2xvY2tfZnJlcXVlbmN5 Ow0KPj4gICAgICAgLyogSU4gKi8NCj4+ICAgICAgIHVpbnQ4X3QgYXJtX3NjaV90eXBlOw0KPj4g KyAgICAvKiBJTiAqLw0KPj4gKyAgICB1aW50OF90IGFybV9zY2lfYWdlbnRfaWQ7DQo+PiAgIH07 DQo+PiAgICNlbmRpZiAvKiBfX1hFTl9fIHx8IF9fWEVOX1RPT0xTX18gKi8NCj4+ICAgDQo+PiAt LSANCj4+IDIuMzQuMQ0KPj4NCg== From xen-devel-bounces@lists.xenproject.org Mon Jan 26 15:51:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 15:51:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213787.1524233 (Exim 4.92) (envelope-from ) id 1vkOsR-00054m-4m; Mon, 26 Jan 2026 15:51:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213787.1524233; Mon, 26 Jan 2026 15: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 1vkOsR-00054f-1m; Mon, 26 Jan 2026 15:51:43 +0000 Received: by outflank-mailman (input) for mailman id 1213787; Mon, 26 Jan 2026 15:51: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 1vkOsP-00054Z-04 for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 15:51:41 +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 e61409c2-face-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 16:51:39 +0100 (CET) Received: from MN0PR05CA0010.namprd05.prod.outlook.com (2603:10b6:208:52c::19) by SJ2PR12MB7990.namprd12.prod.outlook.com (2603:10b6:a03:4c3::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Mon, 26 Jan 2026 15:51:33 +0000 Received: from MN1PEPF0000F0E1.namprd04.prod.outlook.com (2603:10b6:208:52c:cafe::15) by MN0PR05CA0010.outlook.office365.com (2603:10b6:208:52c::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.7 via Frontend Transport; Mon, 26 Jan 2026 15:51:19 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by MN1PEPF0000F0E1.mail.protection.outlook.com (10.167.242.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Mon, 26 Jan 2026 15:51:33 +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, 26 Jan 2026 09:51:33 -0600 Received: from [172.29.134.248] (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, 26 Jan 2026 09:51:30 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e61409c2-face-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Jv3BErBdXJoukMwxE8hZRx3wIgEwya8ZGSEVT4XU5JryAxznKWzpegDkGCh8LbsCuhslviFmtg0qTbdNfPKaW+pI5YG6KOTS6AVMk4SGv+mULJDozlQaqqqYPMUcm22QTimvN/ae8SMDCcCCalMB8Zcd0MCDQmPjnjSAnc87EaQCk+Rvc+j7Scl1Q5hsXD1GM31O8FX+ESZ9q00Ife+IQb5Cya7Zs95Ax/+3UIYTkxaxJWk4PeBXAPeIN5EMjMQ9aibvbkSWczKuoucDojEyTrykJZ8xv4Z/krZozFh3iFAC0RS2cNXyuoRGhOMRUdlU7VtN9aFRH0Pcjsqj9GkVoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xF3kGXb5vInHmjHIiUJVTuTrd+vq74gKzrDM85Nz2oE=; b=Z93E5KV8pktJXSUIvkZrpL/b3ss5Vxl4b8MVqpryWIP7fwUA/ewGMjcWuz7oDZtGmleAuAvJFHo3LgFvqmznukSl6U4/mqcFdHg1kLhigj/G01cVtr203wsrVL8s4HLYZ5l/JdIuJuTVESOS0xHX+pvxRuRBlkqVUTKv41ZuIXshWXJmehOf+gokfnrWBSDaL6XZXKw8CqEffcRp67r5puLC6WY61HPvI7FV6tCbtMr7Y4oYzRBHhbomi4/gtffTwaqLVg1tlxKYbFsisT865f4gFBA0GbCYYgbSa7BtlSqJgJe5vcu4ExptPPxAyl1PRBpJ4kpCTLC+vDoUjIxqbg== 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=xF3kGXb5vInHmjHIiUJVTuTrd+vq74gKzrDM85Nz2oE=; b=N9sWD7+YXFlU1FjeH7sGkdpkAViHobMEiuH56FWLjG84wEsy89488iFZRZMQTeIN9+1mq3ZoPsI2Q4atwzYJI/8Lvgcj4Ci67xGknnIfae81deacaqszWGy/oxLav/8euXAepLUXjEb4LVOc82tUJGWNCKKch8TpruV5csFD1YE= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <29dac091-5f9a-49a6-acee-96632a1ebf7c@amd.com> Date: Mon, 26 Jan 2026 10:51:29 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/4] PCI: don't look for ext-caps when there's no extended cfg space 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: <58091dc1-7bda-4536-8200-2d0a5679d4d1@suse.com> <133c1cb0-bdb6-4c9a-bea8-c50f42ce58d7@suse.com> Content-Language: en-US From: Stewart Hildebrand In-Reply-To: <133c1cb0-bdb6-4c9a-bea8-c50f42ce58d7@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN1PEPF0000F0E1:EE_|SJ2PR12MB7990:EE_ X-MS-Office365-Filtering-Correlation-Id: ab70d58b-d777-4af4-d337-08de5cf2c79f 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?OGpzK1ErUnRoNHdRaEJURUhFRXZaUC9ZZDUwVHFUY3N2dDVzTVVyYWZRaXRG?= =?utf-8?B?cDQ1M3dTcHc4bkVCdlpEYlNJWTcyamMzNEV1TU1kL1lKZHZYejc1RTdDWkla?= =?utf-8?B?U2c2eGhPTHNKR1UvQUs2WlA5alFpQWUrTW1qY0VPcHhkUi9GbWhLNElWL0xM?= =?utf-8?B?RGxWbml1T0luRm96ZXdzd0xBUGxqRzZDdFc5SEdzYlVMNnQ1OG1iMlJpZS8z?= =?utf-8?B?MmJ1RUMzL0VRUmF3OVFwdHQzWmJOeUNIQ0tGU1gvUEdxWFBNdFlwQVROTkZ4?= =?utf-8?B?R1JBZExCL2lyNXlsVkc4M1FxOEkzczR4cU9ldG0rbkQrK0wvVzBHQ3hCckxl?= =?utf-8?B?UWZtUkd3K0svWGZGZFlsZjcyMDFMMklyNzRVTjM3Vm5kVlJEWUlmV1h5N0xM?= =?utf-8?B?L2QxbzFUaHBUYnd3b1pZMjZmR3pOYU9pR1pVRUtkVFY3WHYrelQ4SE5vcG05?= =?utf-8?B?TngvamJsdmdQMG5ZRTZvV3MzM0NWOXhkMy9Za1ZuYUtQNm44NldRUVRSZU9w?= =?utf-8?B?d1ZwT2xGSXRoSVM3Sk9BTVh6aUhhUmpReDhwbTdUV0xIcWhmZExvNG93V01a?= =?utf-8?B?cUVrYUtTeXpjbjBXSnZTT1V0Q1kxK25DNm5VS0JnTytRQVZYYXA3M25JSjFn?= =?utf-8?B?QTdYd2pGbmMwN1FHV013cERQOS9aSE5jei9TZWx4OHBLRFRCV2w2MDBlYms4?= =?utf-8?B?bitXWWVIbi9RMUJyVEdOUTdxbVZjYkRza3NNM2xlNjRXbDBqY3M5VmhYZlVR?= =?utf-8?B?K21GL0ZCbUR3cmJGME50cEtEb29FT1lLVUMxZm9pUzFSSkpaL2tteGhzNkgr?= =?utf-8?B?bmI2VEpiajlxUnBVSE5yb2xoSGVpbjJkV2R3TVdSR3RpMmlGNnlnRG9xWEUv?= =?utf-8?B?aTJrQU5yZU9CZC9YMTRVcnVkd1hCbTBabUVZUnFrZkFmQmxleFo2VklyWC92?= =?utf-8?B?dkF4Skl3R1lhdVB1VFQ3TTJ1ZGVBZDd4VHNWZDlMVGFCRjNSMjdzYytGTGd2?= =?utf-8?B?dUsxZjZ4cEVOY0RrWUFBaHRTZ3NHdDhvcHg4MXgrQmwzK1ZkS25RQUV6K3E5?= =?utf-8?B?L0MrY3huZUcxaW5icmgwUFhCYjA3VUY1WlEzY2Y0VUE1aUdoWkNUeHpDVm5o?= =?utf-8?B?aTRSMjdhWW5QaWZ5d3Ztc3J4SkdiMEdnTG1xdjY2MFgzWHRkSWR5aDFnVm02?= =?utf-8?B?K3dkZjB3N3hQdEo1S3AwbzFmWFlWN2JzRHdMb3V2OGdpMVJVK2hCdE5GaFk5?= =?utf-8?B?WERwekFFT2pJTkpxdk41T1AzVSs5WVlqVEppaVhxVXNia0puYnpHTWo4ODho?= =?utf-8?B?dmRUbDZKTVFPZnV0ZWFmcXV2N1NUMFFRWUVHRkJhWkdQclJyNDJ1MktHd0l4?= =?utf-8?B?aWo1ZW1VejFMb2dFdGVCc2VjNjgxUXp4ZVdVVllwZHFTTzFGYndjNFRmbHN1?= =?utf-8?B?NVd6eUs1eW1mcjF5a1Z1U01za0VzZk5iM2FrYTFHd1RQSmE5YmNjeW9aa1Vw?= =?utf-8?B?RTlsSWY1SjRLeWxvZ1ZvMzRXcWtRZXF0eFMvZlY0Smdpd0RKVG9xd1dualF3?= =?utf-8?B?SURxeXJ3bisySm10RFBsdUVqVWZoSHc3SEJnOS9RcDVFM01PKzJRS1hWaUp2?= =?utf-8?B?QXhWVk9MRWNON2lOblVzQU53UmxrZWRPZkhTaEM1K0g1MFdQRnJPOEJDRy9x?= =?utf-8?B?bmQ2QVU4V1Q1azlsTnlKeFRudXl0UnUvL1AzWEZteFhOUWFTTHh3RGhCc09i?= =?utf-8?B?aVIzaWdzMDZmWTRjTUJ6Q0RjUjU5Z2lLVnhjNTJSemJiTEcwS0lHRVpkWlpr?= =?utf-8?B?cy9UT01CZ1FLeWVvRlJuOUMwdEpZcENiNitNSW9sZVpPcS9iUUZ2RUVVdnBh?= =?utf-8?B?SW5XOXN0bmRIbmlDYnE2MjBybmIrOTRkYkhqejVMQ1U4YTIrVFUyL01lMURq?= =?utf-8?B?NU8rY2ExRUxObS9zcUhyUGRLVHFtWWpzL05pRjV4cXVIM3hvQjhOUlpUVFYx?= =?utf-8?B?QmVodDliVEJmeW5TRUgwcUEvWnB2aUdOajNSdlBXUE8vYU8ySnpXaUt1eCsz?= =?utf-8?B?aUhBZXZzb3B4SERVR2c0bzBKRHhhZFRjYUZPKys2M2dQZVo2N0FWQjhQZHZp?= =?utf-8?B?c3RZUVlBcERGRGFqclAzd3dkYUNBZ3hkNllPWXIyNWFTcytCK2lGNDJSMEhi?= =?utf-8?B?TmFyWldsdjhKM3lLU1ErL3dLYjgwNkFoSytpeG43VzBIbDdSMzBIcC92aUZr?= =?utf-8?B?VGYrUkwvb2FvOUxkZkdoRzdWbWdRPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(376014)(36860700013)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2026 15:51:33.3734 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ab70d58b-d777-4af4-d337-08de5cf2c79f X-MS-Exchange-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: MN1PEPF0000F0E1.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB7990 On 1/19/26 09:47, Jan Beulich wrote: > Avoid interpreting as extended capabilities what may be about anything. In > doing so, vPCI then also won't mis-interpret data from beyond base config > space anymore. > > Fixes: 3b35911d709e ("Enable pci mmcfg and ATS for x86_64") > Fixes: a845b50c12f3 ("vpci/header: Emulate extended capability list for dom0") > Signed-off-by: Jan Beulich Reviewed-by: Stewart Hildebrand > --- > Because of the multiple prereq changes, despite the Fixes: tags I'm not > quite sure whether to backport this. (I'm leaning towards "no".) I'm also leaning towards no, given that the ->ext_cfg change has grown in complexity. From xen-devel-bounces@lists.xenproject.org Mon Jan 26 15:53:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 15:53:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213795.1524243 (Exim 4.92) (envelope-from ) id 1vkOth-0005ZL-EF; Mon, 26 Jan 2026 15:53:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213795.1524243; Mon, 26 Jan 2026 15: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 1vkOth-0005ZE-Bk; Mon, 26 Jan 2026 15:53:01 +0000 Received: by outflank-mailman (input) for mailman id 1213795; Mon, 26 Jan 2026 15:52: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 1vkOtf-0005Z6-SR for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 15:52: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 1582d105-facf-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 16:52:58 +0100 (CET) Received: from MN2PR03CA0009.namprd03.prod.outlook.com (2603:10b6:208:23a::14) by DS0PR12MB6655.namprd12.prod.outlook.com (2603:10b6:8:d0::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.14; Mon, 26 Jan 2026 15:52:53 +0000 Received: from MN1PEPF0000F0E3.namprd04.prod.outlook.com (2603:10b6:208:23a:cafe::e3) by MN2PR03CA0009.outlook.office365.com (2603:10b6:208:23a::14) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.14 via Frontend Transport; Mon, 26 Jan 2026 15:52:17 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by MN1PEPF0000F0E3.mail.protection.outlook.com (10.167.242.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Mon, 26 Jan 2026 15:52:51 +0000 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 26 Jan 2026 09:52:51 -0600 Received: from [172.29.134.248] (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, 26 Jan 2026 09:52:49 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1582d105-facf-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=OqZLgctYR+5Wo1j+QVxR7E6HO/jl2YY66+267y3UQLLodKWgG+SL7WsHs+DzW11k5T08P29DeCBnA06ayUGQjRi+1BnT2k1y1xlJ3y4W81sYsPf59/Ac8cdZlJD/X2paByg6C3ub+GMT5bcI9TIVkzE497jQCefBcjxqOnmD4MTgHb6LJ+bhgtsphs+mI6NmWXQefJEfV57DJ+VPypz7K8a1Ae8BY8mZaLnpUbyYw5LRItBrNuG1gnk4wNHnZftm+TJ7B4CcalxQBxOsZMieGUjAeVvJmT4yUrMeN+JmOPlvFVBDoSBEPUUQnmGnzr2i1htxZ1esGpihnk4QzqrthQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bDQTNnwCK6KgVxROBuRzsO3wGa3kVbvWTcDgtLnkClE=; b=oo1YG/yO3daT8foNbC/JGw+OwtiuOuETpgqFbF/SbSv7S/WP9clHgwWdgAtNfLh/G/coyUKqHVfnL0ZGvKfCkFfCsk+t8iPDJzDqb/IW7oz409TupRHjrXPYEZMLYvEalOwn9Qc8BqtxKREXsRGxXOV7LM1793+88BWh6fLsPPpJuXrLo9AvYoRpEhwO5Onx8p/m1cZg49XNgmjjlAedkfciRHC+3yiRMySjcMIZN5vdVfXbWGYv13B0ssX4YEGrVbagxHkuIBPTL4ump81qteVaT9Z8Y4H4erMUXq4/GSdaGAYTsiIdxNmFEEnOPh/1mzs5mfL0HouxAa9RF1ImPQ== 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=bDQTNnwCK6KgVxROBuRzsO3wGa3kVbvWTcDgtLnkClE=; b=zzk0xMj4U8KQbSM9g3Xn2Du6m323WdCx0yrmKmKBVYvtZqCtfOnlGMj1WYcSybV4YJxT6AGReubyobRcQDp4M22Tue7YBCBI9YFTRoSWj1/oL9ygA7iK11tDrUyWKZI6oPDkLoIqnLfiyceJuGy7ULpiH/9JD2Opa+Jlu8ZeY48= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <673d69ff-2859-4678-b90f-11fdc7a915f4@amd.com> Date: Mon, 26 Jan 2026 10:52:49 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/4] vPCI/DomU: really no ext-caps without extended config space To: Jan Beulich , "xen-devel@lists.xenproject.org" CC: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <58091dc1-7bda-4536-8200-2d0a5679d4d1@suse.com> <96e90685-3321-4884-8fe7-f083c25ba7ab@suse.com> Content-Language: en-US From: Stewart Hildebrand In-Reply-To: <96e90685-3321-4884-8fe7-f083c25ba7ab@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN1PEPF0000F0E3:EE_|DS0PR12MB6655:EE_ X-MS-Office365-Filtering-Correlation-Id: b594fb45-945c-4c1a-5bb8-08de5cf2f623 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?V1ZiTlp1SXY3NDl2TUdSRUNtRXgrTktmakhYczF2WWs0WEhVa3FtY0tJc0FT?= =?utf-8?B?RjBNOGlTTlNKNXhTQXA4d2J6Tkl3S0EyaS8wbWdncmpQSnNNZ01td1EvVFdi?= =?utf-8?B?UkJtSnJjdGpWOWpVZnlwNEw0OGM1akhsVUtCaFFmd2MwZytFNzBvRHpoQ01W?= =?utf-8?B?VHJvTHhGQ21vNnkrSVdvaTRrcU4rWVZJNzhMNUtqWnRKVkRiRlhHOXBOcFpM?= =?utf-8?B?V2tRdG12UEwwMlQ2WStpbWMreWpqU1FJWEJVU1BiV09ySjFzcFN3d1BVY0x1?= =?utf-8?B?ZDA2bXBtTUdMQlZDWFJFV2dWdzg1Uk4wQUFHVGxoNVZhUDZoUUs1NVA3L09t?= =?utf-8?B?RUljM2crN3laZmxHZzNGS293ZlNzbWdQZUdPZmgwUldraklTcEx3SEV4UjhK?= =?utf-8?B?N3JaNXRLanVYS0x5YSs2ZW9PVjVtb2hnVUpqbXFyT1hON0lxcmZnbit3aEVa?= =?utf-8?B?N2xmcWVGK0NwYllJVGJ4cXY4Y2xNUzZNOSt4U3BIYjBhZzIrN1J0UVM3SU40?= =?utf-8?B?a2ptT2pyWFhYbkt6eGlQN242V1pTMEVrUkhxTlNGM2JZQ2lNRVZTRmp2QXR4?= =?utf-8?B?T1ZnSXdlWm1CNFFjY3RWVm54Vjd5R0d6WEFublBqZ3BjSXg0YXpzUzR3NkxN?= =?utf-8?B?NkowTUlIdDlENVZYMnFDb0ZDZEgvSkxpejBLY3dGek5GRUZzWDhwRnZXUWcw?= =?utf-8?B?S1ltcUhZNWcwVmtmUktGSkNjVkZac1Vra2pveXNGL0xCZ3Q0cXhBd0dydUdO?= =?utf-8?B?blpIdnZvdld1QW80b0dzTWJUcUZvZGJidjFibzFkUzladms3QUhLbHhiVTdt?= =?utf-8?B?dVdSakp5eDQvNGg0T2U5RTl6eENDWVR3cVRIVXprWmUzeDRqUVEwOVJBMHRs?= =?utf-8?B?Z0cvTEdXLzNPR3lrSzNrUUNDVzhDY3hTektkNnZnZmZMdEwweDZiWCtPL0RY?= =?utf-8?B?dk80ak5wb1lJbXNSeStXRzlpMUladms1TzY2U3lhaVlmdTJTaEhtVjBXdDRm?= =?utf-8?B?R01pcDdoc25hSUxhbmwxMkd6VFpsTnJJWU1qdWVLdXdydmJ6K2V6R3JFUWJi?= =?utf-8?B?Wk5XTzFyN1JiZDNnVEtWYmxKekc2MW1kb0pEVThIM1kxK1M4YnBkaDZ2d0F1?= =?utf-8?B?RkoyQjRBNzFpbTBEbDF1cWZya2FCREdBWFpIVGxQTTBJeGJuTXE2VXhDa2tR?= =?utf-8?B?UlVHNnlFMjI2b1Z3VTVCYUFFNXRsQk1uV1pxTThDWXAvYVlQUzd0SVpLT0ZJ?= =?utf-8?B?dy9GWmJpY3B3bmZ1YVhFSkRLNG0weGhlSTZRcXVJRUlUZjhNVW1idGdXei9i?= =?utf-8?B?L1dBUDlIMjFMeWlMSnpma210ekdqeS9GL3p1UzVNSHRrSTdZT2tra0hJNWR2?= =?utf-8?B?RVBmQkZtREFNa0NPaUZ0dHF0RDJ0aEhLeEF6OG9LY2tJWUFHd2MyNTZMOWJ5?= =?utf-8?B?UmpYLzNXSExzeGlFMHV3aW1semRNaUVKam93YXhOcWJxTlZFRXFFY1lyaE1w?= =?utf-8?B?ekxIVGtoT3c0YVlJd2hiQnhaSDM2SmJLbDA0K2x3T2twR0h6eFFPRWRRUG1S?= =?utf-8?B?dnhUWXlOb2dBWkNiOGZmSXJMV1JXVU5yWHhFNHphajhjTGR2RzBWbU94SEly?= =?utf-8?B?S3J3bjRnVzJnaXFXTXVreE1zaDUybWFMT1ljM2VEVnl0cXlHcjJMc2FwR2pP?= =?utf-8?B?RVJiY0tValdIS0ZETmh0VTF6NGV2TDVzak9PQzArbkRJWktvMU9vR2ZIdURl?= =?utf-8?B?L2tmNm9XbGdTRGFIVlNQZjR0aEJtMDdjWm9Od2xFNU5VZ0dGVE16WTN4eHZS?= =?utf-8?B?NFVOOXBmaXFPSmRhdm1yenZzRndtYWpyTkpLcThETk1ONklvQ2Q1UWx6ZHFh?= =?utf-8?B?QVRFclk5Q0RhTHJZNUdibEFqMUl2SVM1Ump6Rmg1NjBKU0lOMi81YmlLZlpU?= =?utf-8?B?M0IvU3dxUVE3U3FON0x5aTg0bDNIbkw0MWVuRDBJNm1oRjhra0tubFQxcGlX?= =?utf-8?B?c0t4d1p3WGpvSncyYlZDK0gydGFETmNKMjMvZ3ZacG1mdlNZVnVaM2UxelNq?= =?utf-8?B?TS9yaEs3dm5MUjBYLzJndElCZkljWDk5d3RaMGxsSFV0ZGpURjJCTTQ1dEZn?= =?utf-8?B?Z25FYnB1ZEdDVmZYMmhwTVRGWGozbzVmVmlMdWxwV05kODk4UUpGQy84Sk9u?= =?utf-8?B?UmpybnJCQU1uS2FyaUZGTGhSV3JUM2FTb3hPUDZvNUdQMVhIb0FQano4ZFk1?= =?utf-8?B?Wm9FdklYV0dDS1k5U0dLY0t5QmdnPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2026 15:52:51.4109 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b594fb45-945c-4c1a-5bb8-08de5cf2f623 X-MS-Exchange-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: MN1PEPF0000F0E3.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6655 On 1/19/26 09:48, Jan Beulich wrote: > Whether to emulate accesses to the first 32 bits of extended config space > as read-as-zero or read-as-all-ones depends on whether a device actually > has extended config space. If it doesn't, read-as-zero isn't correct; not > getting this right may confuse functions like Linux 6.19-rc's > pci_ext_cfg_is_aliased(). > > Fixes: a845b50c12f3 ("vpci/header: Emulate extended capability list for dom0") > Signed-off-by: Jan Beulich Reviewed-by: Stewart Hildebrand From xen-devel-bounces@lists.xenproject.org Mon Jan 26 16:30:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 16:30:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213806.1524253 (Exim 4.92) (envelope-from ) id 1vkPUD-00030g-UE; Mon, 26 Jan 2026 16:30:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213806.1524253; Mon, 26 Jan 2026 16:30:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkPUD-00030Z-RX; Mon, 26 Jan 2026 16:30:45 +0000 Received: by outflank-mailman (input) for mailman id 1213806; Mon, 26 Jan 2026 16:30:45 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkPUD-00030P-Dh for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 16:30:45 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5b391012-fad4-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 17:30:43 +0100 (CET) Received: from BL1P222CA0022.NAMP222.PROD.OUTLOOK.COM (2603:10b6:208:2c7::27) by DS0PR12MB6416.namprd12.prod.outlook.com (2603:10b6:8:cb::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.16; Mon, 26 Jan 2026 16:30:30 +0000 Received: from BL6PEPF0001AB52.namprd02.prod.outlook.com (2603:10b6:208:2c7:cafe::e5) by BL1P222CA0022.outlook.office365.com (2603:10b6:208:2c7::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Mon, 26 Jan 2026 16:30:21 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF0001AB52.mail.protection.outlook.com (10.167.241.4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Mon, 26 Jan 2026 16:30:30 +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, 26 Jan 2026 10:30:27 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5b391012-fad4-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=wo+j8jhvG43Jix7zXiVzzj9jx/Lee0Mq5jM/lc9SvQ01JUHWmLhQUfx54ufKCjBm0XGjuKE8T2CCr0Gwv9P/Pv86UOUveOdVG6UJ/umDSnF4t7s5PpKiSOAUZwRS/xHbXWmroGgd7Z/UUzYKvA1RI7xMLPuzrfYIr48+gHEeUpLYK/Gzu5tYbU9QqDQ0ujgz67wW0zXEIjuZGiydqJjf2QS903hx32nez6bR7dFhNGa6LTsUcFGfy7pSsPwjhPDsbqFK++NFOB0gp7E4zz82UhMY8D64G8skq5ZhuCr2UjflnKViOKfWY4AOdqJ2gCVoO6zwH7j9jSDNQbS/EggUKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=00WL0zzqjSejKtA1awLrUpFxlkYuhaUrlCET7Cm5m2M=; b=c3HK97NiLj5WKTD8noruRMD0fj7LSK/lWXUjZHJI1PFthYNlMEZ9yhJjYlEwe90PQYO5U6dms+pmICQK6SNvt/JGHprZT+oopi+W29sI3jglhws7OcqAgzLQnahseqnUE5jBiC9GHW2/ns156jbIDs0qCDK5T738fO1jdDroysPmVhkCYh6pIHAOcDkzGtapmW2dnNaXuHeG/zkZTR2LOwnuW3hVXs1hoFNPoe/wYNL08Zmk8N1zanqkC+6rGpXcC8aJOzkveN6RMtLL9m/CYcuK9J9h0nSKuUPLmycdyMe/+Lnzxs3gKUp6j/RMGiF0j2hDfgcZEt2dzPBFOc8b5w== 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=00WL0zzqjSejKtA1awLrUpFxlkYuhaUrlCET7Cm5m2M=; b=KtRa+pQdpbwlPlV4WXz4wMDVxF+R2QxTPjrT8Ip5Cl1xFUNNM4iLw4y9rx6Jbpi+iFmH/ycQ2DovGlxeMFcuThli0/i06dzDWrKDVbt44quneIcC0cE/bniGSktlMmIFKTF/QzTX4WkfeiEMPomdkpt77N9X0wh82Ag6vFXO6Kc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 26 Jan 2026 17:30:25 +0100 Message-ID: CC: Jan Beulich , Andrew Cooper , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , "Daniel P . Smith" , =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?= , Xen-devel Subject: Re: [PATCH] xen: Move NX handling to a dedicated place From: Alejandro Vallejo To: Julian Vetter , X-Mailer: aerc 0.20.1 References: <20260115151658.3725784-1-julian.vetter@vates.tech> In-Reply-To: <20260115151658.3725784-1-julian.vetter@vates.tech> 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: BL6PEPF0001AB52:EE_|DS0PR12MB6416:EE_ X-MS-Office365-Filtering-Correlation-Id: a83ce993-2f6c-4e52-ae03-08de5cf83894 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|30052699003|82310400026|1800799024|36860700013|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?b2tlUHc5VXAzd2xLaCtiVmNxbHlTRmVnYllDZzdVVGZEdnJpcTVqcUpnUHRC?= =?utf-8?B?OFdGd3kvWE1PS2p2NCtzckVxc2oyNjVLaW4vV2VVVmRESWNNL2U3ZW5FYjZH?= =?utf-8?B?QTlHRm5Ca3M0bUJPVkJmMllrNDB5SjJqR0E4SDNCaFZFazVVdzArNGYwQlZl?= =?utf-8?B?R3g3STZreXZTSUtUUHdBSGJ0d09SNUV0Z09tVkVQa1czMmNicWgyRk5ORXVr?= =?utf-8?B?ZW9PbTJkM1ZHazFQaXlGQTg4ampieGlTME1rU2lRUmM5Q3k2YUsrM0sycjZm?= =?utf-8?B?MFl0amN3YjQwVU1SbTk1TEszVDBrZE1rd1dGaGFhRnJMa1VwZUZGRjYxWGlq?= =?utf-8?B?WFQyU25VMnk1a2I0clRGdUxyNzlITXQrcEYrUE5yd0tvSlovc052ZTZRUUNV?= =?utf-8?B?WEwwTmlOZVZKSys2U2JCcGNOc09pQnBMQVdKbk5jaVhGUjd3Vng3NTllZFkx?= =?utf-8?B?UlhuMzU5aW10dkp4YTNlMmJUNmJPK3ZNeHFhbVloSWZDczk3VDBGS09FUXdq?= =?utf-8?B?L3lRcGRDQ3VFWWlla2hqa1RnNk9kaURJNlE3c2pmYi9BSmFtSlU3bXFKWmtp?= =?utf-8?B?MEljU3lJbC85UFVnK3lNZG5DVTFKZmtHRnBZanNzbFk3SkRDM01lZVRlVE5w?= =?utf-8?B?dy9QWTJEZzN5dzNubENtRXo2RGFjejFCL2JFc0IvWlJ3a2FDMGVTZFpIdHVu?= =?utf-8?B?eGEyUXJUanRuVTBwTlk0Tm1OZjhNckh0ZGdTN3FvRFlLTDFBVkRLR1hDaXVI?= =?utf-8?B?WUpXcDBVUGpSUit0NGRTamZUeXFDS2RRRm9pelRxMkJRN2ZNV0hzT0N0YXlw?= =?utf-8?B?eUkzRW5qZStQVnpJaDN5a1AwME1uUXNtRkdodDhaUUt5OERBNFFIdGx0WXZz?= =?utf-8?B?NmxkcXRLR29lOVg2dXZldU5BL0RINTJReG9GSWExVkdWN0QzL0tUcVp5VlUx?= =?utf-8?B?UFZKbThpaGhmdXJhYlIrZXBlTnBiYzd0VW1QbUVoeHRZTmZDR2FHWmJOejVD?= =?utf-8?B?UjVmTVRDVXVkTTBaRkZyV0NpOWoyaitkTGVwSmEwQk9qS0lvQmU2a1FNblM1?= =?utf-8?B?MUt2QUJpY3I4RjFOVXNnT3l4SlRqQXJmNEx5L1JOQXNHMkszOGNNQ2g1T29P?= =?utf-8?B?a0o5UC9OTTkxb1Qvc0VMdDl0T0dpZFc1Q281djJidWhvWTVST1Bvd25WNUJk?= =?utf-8?B?OEhJakNsNnhpY0RJeXNHM0JibCtpc29MZTRESzJwZWFKWG9hWVRSL3BaQjA0?= =?utf-8?B?NTUrUnlKcWJsZ1hiRmdPeGRvZS9kQlVZZklueEF5dERaVmtPc05hNm56MFNZ?= =?utf-8?B?RnJFNGF5bDJNQ2dqUm04cEsvK2VVdTJjS2svQ0VrbjViMnYrbUhXMWpQZnRU?= =?utf-8?B?a1R5d0xMTVllTVJ6M2U1cTlDNGdJUGNlNUNCRXZxQjZnclpuTmJQR1ZubmhU?= =?utf-8?B?bVZnbytUOFQ2akRjbjhwajMranlJUHQ1RzBtY0prUUtoOVdGNklSdWZQYTRa?= =?utf-8?B?MTFvaTc0VC9MbGR2WUtlQWs2K1pZR2tCUGZCZkh1M2lSSXFjcDBvcEF4RWc2?= =?utf-8?B?c3hxZDh0bGdvZ1FSOElhelRYNHZPT0VFOTc4Z1EyYWluQnQ5bjUyUEJweFFX?= =?utf-8?B?UXMwVlhDa2psN3RXaDBzeEJSUmppOHhlYzBLcG9RTm41SWRPK1pFVVI5UHRI?= =?utf-8?B?S1RMS0R4YnRteWVPUWJ1Q0crT1R2Z2l6UmdHaWhza2I3MFNwbzZrSlYxNHpr?= =?utf-8?B?V2FXcElMZFpVWkJOd3hVdmIwMmMxWVZtRU84a0d0MjM3bFVMWlU4MDNTK2pw?= =?utf-8?B?MTEvajhKaElkVmp5SGV1R2VkTjI5SlM4K1NUMlNnQWsvT3ZEMTY4a3pRU0RE?= =?utf-8?B?eVNjSXBQMFd6OW16cjI1OHFFQkV4c0FPKzArZUUvTjcxUVdQbEZ0M2MwL3lN?= =?utf-8?B?NU1XYlZOZDloeUk1NmEzY01FeCt5N29KNVZadnJYSHVPUXd6d0Z3MkdpUEIy?= =?utf-8?B?bXJqSStKKzFnYnJGeUIxenZjTUxUN0htcTVSL09WWUE4WllvMXVuZzhKVHhW?= =?utf-8?B?MzhxUkhLRE1PTkcyTWN0NTRPcW9rWStMUDVZblV4NGdLOHBvaFp5TTY1Skxj?= =?utf-8?B?b2Ruc0FTRzAreHJKOVJ1ekZkVkVERTdjVFdIbkN2aFRJVFRFb3d4OU9JOWMv?= =?utf-8?B?a3V4K1ZpQXkvbThPdnIrN1IyUnI3L3l5ZEg2eTBtK1BnZVl4VkV4WWJ6MVZO?= =?utf-8?B?UTJPbDVTZldMV2J3MzM2UDZ3M0pRPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(30052699003)(82310400026)(1800799024)(36860700013)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2026 16:30:30.3657 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a83ce993-2f6c-4e52-ae03-08de5cf83894 X-MS-Exchange-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: BL6PEPF0001AB52.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6416 On Thu Jan 15, 2026 at 4:17 PM CET, Julian Vetter wrote: > Currently the CONFIG_REQUIRE_NX prevents booting XEN, if NX is disabled > in the BIOS. AMD doesn't have a software-accessible MSR to re-enable it, > so there is nothing we can do. The system is going to die anyway. But on > Intel NX might just be hidden via IA32_MISC_ENABLE.XD_DISABLE. But the > function to re-enable it is called after the check + panic in > efi_arch_cpu. So, this patch removes the early check and moves the > entire NX handling into a dedicated place. Let me prefix this with I haven't looked at the discussion at large. Howeve= r, I'm guessing the BIOS is merely hiding NX and not precluding its use (I don= 't think there's a way to do that). I also imagine it's not an AMD BIOS and ra= ther an OEM BIOS? If so, commit message and comments need to reflect that. Also, this might be a good time to reverse a mistake here on the polarity o= f this option. It should've been CONFIG_OPT_NX, where having the option set a= llows machines without NX to run and having it disabled mandates NX to be set. That makes the option strictly additive and compatible with allyesconfig. My .02, anyway Cheers, Alejandro > > Signed-off-by: Julian Vetter > --- > xen/arch/x86/boot/head.S | 56 -------------------------------- > xen/arch/x86/boot/trampoline.S | 5 ++- > xen/arch/x86/cpu/intel.c | 4 --- > xen/arch/x86/efi/efi-boot.h | 12 ------- > xen/arch/x86/include/asm/setup.h | 2 ++ > xen/arch/x86/setup.c | 46 ++++++++++++++++++++++++++ > 6 files changed, 50 insertions(+), 75 deletions(-) > > diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S > index 77bb7a9e21..7fb7fb1351 100644 > --- a/xen/arch/x86/boot/head.S > +++ b/xen/arch/x86/boot/head.S > @@ -133,7 +133,6 @@ multiboot2_header: > .Lbad_ldr_nbs: .asciz "ERR: Bootloader shutdown EFI x64 boot services!" > .Lbad_efi_msg: .asciz "ERR: EFI IA-32 platforms are not supported!" > .Lbag_alg_msg: .asciz "ERR: Xen must be loaded at a 2Mb boundary!" > -.Lno_nx_msg: .asciz "ERR: Not an NX-capable CPU!" > =20 > .section .init.data, "aw", @progbits > .subsection 1 /* Put data here after the page tables (in x86_64.= S). */ > @@ -165,11 +164,6 @@ early_error: /* Here to improve the disassembly. */ > .Lnot_aligned: > mov $sym_offs(.Lbag_alg_msg), %ecx > jmp .Lget_vtb > -#ifdef CONFIG_REQUIRE_NX > -.Lno_nx: > - mov $sym_offs(.Lno_nx_msg), %ecx > - jmp .Lget_vtb > -#endif > .Lmb2_no_bs: > /* > * Ditto. Additionally, here there is a chance that Xen was star= ted > @@ -547,56 +541,6 @@ trampoline_setup: > bt $cpufeat_bit(X86_FEATURE_LM),%edx > jnc .Lbad_cpu > =20 > - /* > - * Check for NX > - * - If Xen was compiled requiring it simply assert it's > - * supported. The trampoline already has the right constant. > - * - Otherwise, update the trampoline EFER mask accordingly. > - */ > - bt $cpufeat_bit(X86_FEATURE_NX), %edx > - jc .Lgot_nx > - > - /* > - * NX appears to be unsupported, but it might be hidden. > - * > - * The feature is part of the AMD64 spec, but the very first Int= el > - * 64bit CPUs lacked the feature, and thereafter there was a > - * firmware knob to disable the feature. Undo the disable if > - * possible. > - * > - * All 64bit Intel CPUs support this MSR. If virtualised, expect > - * the hypervisor to either emulate the MSR or give us NX. > - */ > - xor %eax, %eax > - cpuid > - cmp $X86_VENDOR_INTEL_EBX, %ebx > - jnz .Lno_nx > - cmp $X86_VENDOR_INTEL_EDX, %edx > - jnz .Lno_nx > - cmp $X86_VENDOR_INTEL_ECX, %ecx > - jnz .Lno_nx > - > - /* Clear the XD_DISABLE bit */ > - mov $MSR_IA32_MISC_ENABLE, %ecx > - rdmsr > - btr $2, %edx > - jnc .Lno_nx > - wrmsr > - orb $MSR_IA32_MISC_ENABLE_XD_DISABLE >> 32, 4 + sym_esi(tram= poline_misc_enable_off) > - > - /* Check again for NX */ > - mov $0x80000001, %eax > - cpuid > - bt $cpufeat_bit(X86_FEATURE_NX), %edx > - jnc .Lno_nx > - > -.Lgot_nx: > -#ifndef CONFIG_REQUIRE_NX > - /* Adjust EFER given that NX is present */ > - orb $EFER_NXE >> 8, 1 + sym_esi(trampoline_efer) > -.Lno_nx: > -#endif > - > /* Stash TSC to calculate a good approximation of time-since-boo= t */ > rdtsc > mov %eax, sym_esi(boot_tsc_stamp) > diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampolin= e.S > index a92e399fbe..8e8d50cbdf 100644 > --- a/xen/arch/x86/boot/trampoline.S > +++ b/xen/arch/x86/boot/trampoline.S > @@ -144,10 +144,9 @@ gdt_48: > GLOBAL(trampoline_misc_enable_off) > .quad 0 > =20 > -/* EFER OR-mask for boot paths. SCE conditional on PV support, NX added= when available. */ > +/* EFER OR-mask for boot paths. SCE conditional on PV support. */ > GLOBAL(trampoline_efer) > - .long EFER_LME | (EFER_SCE * IS_ENABLED(CONFIG_PV)) | \ > - (EFER_NXE * IS_ENABLED(CONFIG_REQUIRE_NX)) > + .long EFER_LME | (EFER_SCE * IS_ENABLED(CONFIG_PV)) > =20 > GLOBAL(trampoline_xen_phys_start) > .long 0 > diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c > index b76797cb9a..e8cf51e853 100644 > --- a/xen/arch/x86/cpu/intel.c > +++ b/xen/arch/x86/cpu/intel.c > @@ -351,10 +351,6 @@ static void cf_check early_init_intel(struct cpuinfo= _x86 *c) > if (c->x86 =3D=3D 15 && c->x86_cache_alignment =3D=3D 64) > c->x86_cache_alignment =3D 128; > =20 > - if (c =3D=3D &boot_cpu_data && > - bootsym(trampoline_misc_enable_off) & MSR_IA32_MISC_ENABLE_XD_DISAB= LE) > - printk(KERN_INFO "re-enabled NX (Execute Disable) protection\n"); > - > intel_unlock_cpuid_leaves(c); > =20 > /* CPUID workaround for Intel 0F33/0F34 CPU */ > diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h > index 0194720003..8dfd549f12 100644 > --- a/xen/arch/x86/efi/efi-boot.h > +++ b/xen/arch/x86/efi/efi-boot.h > @@ -748,18 +748,6 @@ static void __init efi_arch_cpu(void) > if ( (eax >> 16) =3D=3D 0x8000 && eax > 0x80000000U ) > { > caps[FEATURESET_e1d] =3D cpuid_edx(0x80000001U); > - > - /* > - * This check purposefully doesn't use cpu_has_nx because > - * cpu_has_nx bypasses the boot_cpu_data read if Xen was compile= d > - * with CONFIG_REQUIRE_NX > - */ > - if ( IS_ENABLED(CONFIG_REQUIRE_NX) && > - !boot_cpu_has(X86_FEATURE_NX) ) > - blexit(L"This build of Xen requires NX support"); > - > - if ( cpu_has_nx ) > - trampoline_efer |=3D EFER_NXE; > } > } > =20 > diff --git a/xen/arch/x86/include/asm/setup.h b/xen/arch/x86/include/asm/= setup.h > index b01e83a8ed..16f53725ca 100644 > --- a/xen/arch/x86/include/asm/setup.h > +++ b/xen/arch/x86/include/asm/setup.h > @@ -70,4 +70,6 @@ extern bool opt_dom0_msr_relaxed; > =20 > #define max_init_domid (0) > =20 > +void nx_init(void); > + > #endif > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c > index 27c63d1d97..608720b717 100644 > --- a/xen/arch/x86/setup.c > +++ b/xen/arch/x86/setup.c > @@ -1119,6 +1119,50 @@ static struct domain *__init create_dom0(struct bo= ot_info *bi) > return d; > } > =20 > +void __init nx_init(void) > +{ > + uint64_t misc_enable; > + uint32_t eax, ebx, ecx, edx; > + > + if ( !boot_cpu_has(X86_FEATURE_NX) ) > + { > + /* Intel: try to unhide NX by clearing XD_DISABLE */ > + cpuid(0, &eax, &ebx, &ecx, &edx); > + if ( ebx =3D=3D X86_VENDOR_INTEL_EBX && > + ecx =3D=3D X86_VENDOR_INTEL_ECX && > + edx =3D=3D X86_VENDOR_INTEL_EDX ) > + { > + rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable); > + if ( misc_enable & MSR_IA32_MISC_ENABLE_XD_DISABLE ) > + { > + misc_enable &=3D ~MSR_IA32_MISC_ENABLE_XD_DISABLE; > + wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable); > + > + /* Re-read CPUID after having cleared XD_DISABLE */ > + boot_cpu_data.x86_capability[FEATURESET_e1d] =3D cpuid_e= dx(0x80000001U); > + > + /* Adjust misc_enable_off for secondary startup and wake= up code */ > + bootsym(trampoline_misc_enable_off) |=3D MSR_IA32_MISC_E= NABLE_XD_DISABLE; > + printk(KERN_INFO "re-enabled NX (Execute Disable) protec= tion\n"); > + } > + } > + /* AMD: nothing we can do - NX must be enabled in BIOS */ > + } > + > + /* Enable EFER.NXE only if NX is available */ > + if ( boot_cpu_has(X86_FEATURE_NX) ) > + { > + if ( !(read_efer() & EFER_NXE) ) > + write_efer(read_efer() | EFER_NXE); > + > + /* Adjust trampoline_efer for secondary startup and wakeup code = */ > + bootsym(trampoline_efer) |=3D EFER_NXE; > + } > + > + if ( IS_ENABLED(CONFIG_REQUIRE_NX) && !boot_cpu_has(X86_FEATURE_NX) = ) > + panic("This build of Xen requires NX support\n"); > +} > + > /* How much of the directmap is prebuilt at compile time. */ > #define PREBUILT_MAP_LIMIT (1 << L2_PAGETABLE_SHIFT) > =20 > @@ -1159,6 +1203,8 @@ void asmlinkage __init noreturn __start_xen(void) > rdmsrl(MSR_EFER, this_cpu(efer)); > asm volatile ( "mov %%cr4,%0" : "=3Dr" (info->cr4) ); > =20 > + nx_init(); > + > /* Enable NMIs. Our loader (e.g. Tboot) may have left them disabled= . */ > enable_nmis(); > =20 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 17:54:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 17:54:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213839.1524367 (Exim 4.92) (envelope-from ) id 1vkQmo-0006YT-Fr; Mon, 26 Jan 2026 17:54:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213839.1524367; Mon, 26 Jan 2026 17: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 1vkQmn-0006Wp-UD; Mon, 26 Jan 2026 17:54:01 +0000 Received: by outflank-mailman (input) for mailman id 1213839; Mon, 26 Jan 2026 17:53: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 1vkQml-0004HX-RH for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 17:53:59 +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 fd21385e-fadf-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 18:53:58 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-4801c1ad878so53448725e9.1 for ; Mon, 26 Jan 2026 09:53:58 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c10dbasm3896455e9.15.2026.01.26.09.53.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 09:53:56 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fd21385e-fadf-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1769450037; x=1770054837; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=DXHoMP2m1S668fp9KXBejADon30ms3RX1/2RyOl2CwM=; b=WuQQ57ZEGI+gtoEiAaalhftBAy7Ivd9p3IShdzs65a0YwgV4vZwM939Fkw8IDDyDKx RZB6zbkUqc94dB1hcu77FZo0gwAvGLTB/i8QHCJzT/xtI4I4Ni6KgKY2YDHCGZgzwSC2 EkAjB8jFEu4dBHzgAzxYwmh0/n8jvbYr685o4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769450037; x=1770054837; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=DXHoMP2m1S668fp9KXBejADon30ms3RX1/2RyOl2CwM=; b=ZVekbiz02nGMJca2TRH2nUfX+YKVDe227yVCzdPORt4tCEgYJh/06LI9yO0HtWsGkr tgLqe7nWcDBWUxM+X1b6YCzI+8Qd4b7w1cGJ5j/bwYQNzMOgwcYQkZV6DHfqWYeV52ng 869jsfVaB5ekASlUxutib6Lo1hh+lywKFEYkzDRPpQqPmuc0cePsY3w/TOiXUmnT8twe dzwRUP9kTAZP9xdAVjaRcTSr/jwghZEAa7AUCdp1gl+NHr1pL64qRsmlhJSbl1KZcJC6 Om5VhtoRvbRzS4I4A/RMA/w5BcPZhs90IoAkhhZ5nQbv1TxXkKN8mCRRhabveUX8imTk UsFg== X-Gm-Message-State: AOJu0Yy0DuIZhwfurOMA1NDSzK5bpXwrOgJdBfUSgf1BO74M2YUugnwU cRyUyE9O7/8xuzUHEHAAXW+MC1DXnzWsN0xsoz2PnBdj4MD4hUk1MaO1F/gJdL7dBPr/6Z7aWjw GJ+xG X-Gm-Gg: AZuq6aLIvFLlUER7duZOKDm5woiEijXcWUEYCeYlftby026ryEg6W+jpMo9Ux2G90+k ZmT6lrRFVaXoe8rv3n6IRViq1N9NGu8QwUa1ir0z0B3KuDgMNfE5zwS2yc8WoCAfSi5k9fjK6IM GRm/Aory82vL1lIGR3Mt+2lkT2A6Z9x4xP+dlQnFvzK7JfhH/GI7f1rPn2KRje587+trjkIVHjh G0u0jlbkbH14jemr3z7vmjTpTzEs1bguXNnoUaMUBGajR3zUUVPo2n3YSYy5Mrh8U7FnHUghlfo anOUt8n07rgjpc45CY6QsL5ptKA5TPTX73MOXoOBXoJ8BxnzD5XV3bdMEO1cVtbGyfT4vFLuHxR 6Kw7nPQRAzV6fd9UiZhAWHYCv0Bt2rHAZuZ1C4hyt9tc+WjJF0skZ37IMLGWtsXzq8FZ85nrQkK 3rrEbb1QC0CflF/h/Pn+87hZQujZ6XQcYN5pGXizX822Tv8RT4TN2pHPuHtmDi7A== X-Received: by 2002:a05:600c:c4a5:b0:477:9cdb:e32e with SMTP id 5b1f17b1804b1-4805ce4e578mr91498405e9.9.1769450036624; Mon, 26 Jan 2026 09:53:56 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julian Vetter , Teddy Astie Subject: [PATCH 10/16] x86/amd: Always probe and configure the masking MSRs Date: Mon, 26 Jan 2026 17:53:39 +0000 Message-Id: <20260126175345.2078371-11-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260126175345.2078371-1-andrew.cooper3@citrix.com> References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This allows the infrastructure to reused for system-wide quirk/errata adjustments. Replace the call to ctxt_switch_levelling() with amd_ctxt_switch_masking() instead. The CPUID Faulting aspect is not interesting at this point in boot, and we want to explicitly propagate the masking MSR defaults into APs. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Julian Vetter CC: Teddy Astie --- xen/arch/x86/cpu/amd.c | 15 +++++++++++---- xen/arch/x86/cpu/cpu.h | 1 + xen/arch/x86/cpu/hygon.c | 2 +- 3 files changed, 13 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c index 36fea2e0a299..e8daf7415bb0 100644 --- a/xen/arch/x86/cpu/amd.c +++ b/xen/arch/x86/cpu/amd.c @@ -162,7 +162,7 @@ static void __init noinline probe_masking_msrs(void) * parameter of NULL is used to context switch to the default host state (by * the cpu bringup-code, crash path, etc). */ -static void cf_check amd_ctxt_switch_masking(const struct vcpu *next) +void cf_check amd_ctxt_switch_masking(const struct vcpu *next) { struct cpuidmasks *these_masks = &this_cpu(cpuidmasks); const struct domain *nextd = next ? next->domain : NULL; @@ -242,9 +242,12 @@ static void __init amd_init_levelling(void) boot_cpu_has(X86_FEATURE_CPUID_USER_DIS)) { expected_levelling_cap |= LCAP_faulting; levelling_caps |= LCAP_faulting; - return; } + /* + * Always probe for the MSRs too. We reuse the infrastruture for + * quirks/errata/etc during boot. + */ probe_masking_msrs(); if ((levelling_caps & LCAP_1cd) == LCAP_1cd) { @@ -299,7 +302,7 @@ static void __init amd_init_levelling(void) (uint32_t)cpuidmask_defaults._6c); } - if (levelling_caps) + if (levelling_caps && !(levelling_caps & LCAP_faulting)) ctxt_switch_masking = amd_ctxt_switch_masking; } @@ -1015,7 +1018,11 @@ static void cf_check init_amd(struct cpuinfo_x86 *c) u32 l, h; uint64_t value; - ctxt_switch_levelling(NULL); + /* + * Reuse amd_ctxt_switch_masking() explicitly. This propagates + * quirk/errata adjustments made duing early_init_amd() into the APs. + */ + amd_ctxt_switch_masking(NULL); amd_init_de_cfg(c); diff --git a/xen/arch/x86/cpu/cpu.h b/xen/arch/x86/cpu/cpu.h index d2d37d1d5eec..cd93e51755af 100644 --- a/xen/arch/x86/cpu/cpu.h +++ b/xen/arch/x86/cpu/cpu.h @@ -20,6 +20,7 @@ extern void detect_ht(struct cpuinfo_x86 *c); extern bool detect_extended_topology(struct cpuinfo_x86 *c); void cf_check early_init_amd(void); +void cf_check amd_ctxt_switch_masking(const struct vcpu *next); void amd_log_freq(const struct cpuinfo_x86 *c); void amd_init_de_cfg(const struct cpuinfo_x86 *c); void amd_init_lfence_dispatch(void); diff --git a/xen/arch/x86/cpu/hygon.c b/xen/arch/x86/cpu/hygon.c index bb1624882499..3a04efef5028 100644 --- a/xen/arch/x86/cpu/hygon.c +++ b/xen/arch/x86/cpu/hygon.c @@ -32,7 +32,7 @@ static void cf_check init_hygon(struct cpuinfo_x86 *c) { unsigned long long value; - ctxt_switch_levelling(NULL); + amd_ctxt_switch_masking(NULL); amd_init_de_cfg(c); -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 17:54:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 17:54:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213842.1524389 (Exim 4.92) (envelope-from ) id 1vkQmr-0007Dj-2m; Mon, 26 Jan 2026 17:54:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213842.1524389; Mon, 26 Jan 2026 17:54:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkQmq-0007BU-Lw; Mon, 26 Jan 2026 17:54:04 +0000 Received: by outflank-mailman (input) for mailman id 1213842; Mon, 26 Jan 2026 17:54: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 1vkQmn-0004HW-KA for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 17:54:01 +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 fe79a932-fadf-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 18:54:00 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-47ee937ecf2so40779595e9.0 for ; Mon, 26 Jan 2026 09:54:00 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c10dbasm3896455e9.15.2026.01.26.09.53.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 09:53:59 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fe79a932-fadf-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1769450039; x=1770054839; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=c1ONjoPKEWiY2hmWsIYX5khT8mAnFR/6SGFmL+oGZ7U=; b=k6N3qPTTsWg85Hzq1f4mG5dmYFyb9igbxl6SpLLIXkiQCs9KWqjUa/C7mJdrFwTHCM yCs+VTc4Mo6Ln0J7C6Vs+l6xJhFc9YSkJ+7bMYMUwaDMLplktd0SfUSGkYwrGDqRiaPQ Qq1+cJhF2pzD+YQkJ1hwHoHSuNG7HIGo08U9k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769450039; x=1770054839; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=c1ONjoPKEWiY2hmWsIYX5khT8mAnFR/6SGFmL+oGZ7U=; b=CdlBNAJL/JbURbn1qVHdAB/CL7vXbDvdJ/PBMMXIRRe7eh07NBJzZwr6r4rMri4/D+ VzwGlbnMLiKVjq6z+ehsZL8fxcKtcMJsCjHK1jD7XuNacGRHRset3H+xiiEhYzhSH+Jf Ejxso6l60Su8/T5hkDiSIa8qf1+TvFBkKkBV5wcRgsYG8x4Omk7n09cuoYhRu/OV0fYp LnMvhTVV0QimzYGa6+fTavRKLFoixTttPbDn4rrzRG6P//cHw6Y6H0b3UEWq8K4u6smc 21+g1GT6ScIJTB+w72D6/ArSsm8CY2Qkrf9iBlVjUgz95OY2yo5omk348Qa2euQfeDIO evOA== X-Gm-Message-State: AOJu0YwA3tgUSuuGJWKzD/Ac2LhngBGK9NYaETSq94bEGS67FhT+1N3+ oMklAFEI6xQvI9zGhynmThzgcI475vZRSF/DYmKYHT1d/D4jCfOYkGBK13M84zVXL5GH2boSNlg /aM8J X-Gm-Gg: AZuq6aIRqpuijwD0bf/qvENC9XdTyFB/ZE+Q0Ak3xo9K4GIAvOXcuXjMhLU6XHTmx4/ H0sRaHozAlvbo2zMB9Ba3F6SNU0jP4LZ3JPNiLm9yZW+WwmmxWXaujCcbebuUzB5L+/lsXBTdql UIsg4f16JVxKlFyrhSpzXLjMBW73J4JHp/XoqBEBfFcpmn8GbnOVgsbgLNxn+P8PyH5GIDf8F6H ri1zqEnTdCHshmZ1zjBfP1lSsEcA56F5EIQqbyc3gdMX8wyOgXs99QY/TACS/SDlejNbpcpp4EW ZxFwOqMd3VmwH+PwEAh47enK/vwR+6oc8ClvmFCBve5AaNejE6VC0rLPAdTyTmNXmQRwsOrGEwO li7jwlENQe/XoJPNwHJbEbpssP3pxI5LLcG54B+S1YOupc8R0Xr71NHTqjekurKa6V8Q7InVGn+ Y2J0V//OmqViNCZgGRdaF/rYzecXX2zHSf8jIcXLu3loVGtazGdK8zQhKhpz+1+T60m4W6wnPR X-Received: by 2002:a05:600c:5297:b0:477:a289:d854 with SMTP id 5b1f17b1804b1-4805cd2026amr94916305e9.5.1769450039455; Mon, 26 Jan 2026 09:53:59 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julian Vetter , Teddy Astie Subject: [PATCH 14/16] x86/cpu: Drop default_init() and default_cpu Date: Mon, 26 Jan 2026 17:53:43 +0000 Message-Id: <20260126175345.2078371-15-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260126175345.2078371-1-andrew.cooper3@citrix.com> References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit While the comment is reasonable, clearing SEP as the only action for an unknown CPU is useless. Drop the infrastructure. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Julian Vetter CC: Teddy Astie --- xen/arch/x86/cpu/common.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c index 7674cca1ba93..bab2193e9ba3 100644 --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -100,15 +100,6 @@ bool __init is_forced_cpu_cap(unsigned int cap) return test_bit(cap, forced_caps) || test_bit(cap, cleared_caps); } -static void cf_check default_init(struct cpuinfo_x86 * c) -{ - /* Not much we can do here... */ - __clear_bit(X86_FEATURE_SEP, c->x86_capability); -} - -static const struct cpu_dev __initconst_cf_clobber __used default_cpu = { - .c_init = default_init, -}; static struct cpu_dev __ro_after_init actual_cpu; static DEFINE_PER_CPU(uint64_t, msr_misc_features); @@ -375,7 +366,6 @@ void __init early_cpu_init(bool verbose) case X86_VENDOR_SHANGHAI: actual_cpu = shanghai_cpu_dev; break; case X86_VENDOR_HYGON: actual_cpu = hygon_cpu_dev; break; default: - actual_cpu = default_cpu; if (!verbose) break; printk(XENLOG_ERR -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 17:54:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 17:54:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213836.1524338 (Exim 4.92) (envelope-from ) id 1vkQml-0005s2-Fm; Mon, 26 Jan 2026 17:53:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213836.1524338; Mon, 26 Jan 2026 17:53:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkQml-0005rA-5h; Mon, 26 Jan 2026 17:53:59 +0000 Received: by outflank-mailman (input) for mailman id 1213836; Mon, 26 Jan 2026 17:53: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 1vkQmj-0004HW-JB for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 17:53:57 +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 fc8549ab-fadf-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 18:53:57 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-4801c1ad878so53448445e9.1 for ; Mon, 26 Jan 2026 09:53:56 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c10dbasm3896455e9.15.2026.01.26.09.53.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 09:53:54 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fc8549ab-fadf-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1769450036; x=1770054836; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=4exVf2X0kVUw9W5j5Fb4p8w+lR6Y5FhAJXo3jDL54Ow=; b=UhRHp86eF0EC73u2VLSGwCr7eoePloum4ZiSRD10EyofquKgO2wS/P4R3GFxVxuyhE WoAGSwFSuc6DaV4kHCvHFW6fWrB59HCS6PD2TNq6FuYGeEmc1osCPkYM3z16W3wYd8jj GCNdkjhLHJAUgNjkGmWiwLhLH1ytYjyIDA200= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769450036; x=1770054836; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=4exVf2X0kVUw9W5j5Fb4p8w+lR6Y5FhAJXo3jDL54Ow=; b=cn8RlU1leUmD+MEr2gmetJxJLhgmhOkmxm+YxC8JpfizrbuiitAhTjBICM/N4oSsJy o6NsTLrmHHrDoJ5k6PZaWo+0YHATkEgh4R/f5Qf3l0y+55EbjBtd83Wb/dP1sUcMTTpW toBFQSaZ1Qx2EBCKtpDhCDo1lbfKrI4ZCIZ3gOMdVD3MazsgZzXaUayefG0lkpYJebzb nIbtGRtjA/LInyzKrIWdW0By3AOQhSsx0ITiXV5xKdkcHwqcPQzgAqgxOGzLdb4/llql JhAhqCBTjj8a8pMXIW3dfwPHd52Cp6v/guK3zsSozEGYRuffiE01/SSlRdmkIP2mRZ0S w0Rw== X-Gm-Message-State: AOJu0YxqFwn7ROIyWyXIAMkmha+RU6Y+H5oXInIVdcFCI7E/78953WzU By5SU5GvOhLlSHKMtoHNIgo3CnlxKcFmvo9Onwbe5LL9B+r1Gphy8leNN4RQ9+KB+yxcUXdcnBa WzX7b X-Gm-Gg: AZuq6aInhqWeZ//LlgLqRh1Y2MTdOHWmhqJFUmYwTdr4UyVBkhkIV+q98vjm3yW/CAi wq10Xu61GKXI2DUV0cxDiWJl+CDs9kcsaGOZq6PduI+Sb/qNWjmGu8O4WqBRuF7LZmzVtJoXHrW ow48ESD6iv+npUfv7VfU8uKYvYKRAFX6ElMPZiVwcWzG6IGreltVLvtdXllgolmhzxgWHHxcPiA UyM4NtaDHhI0dSEDdjJs60qMjuauT2Cn7ESAag7aniU3p+SiCSstpLNNl0UWs1EkgDBecQQXMCg +vqTR6oOzUIaSlkvmqlLGfasu5DcQAmNCJieRUTctqrnmlh2TNpJ72uK3483pbIMHjjAU8pypY/ sbagUq48p1ROVy84CIR8JeCc3nXTeRnHeooMQ70ioe2bIwqK4Se2x9CoWOaUyUa//MdYIdPkq26 MEKH9Vu8Zod9bwHOhsZMffSIkDCkJMd20rSj7nMDLY85Z90gAZaNQDjNnnagOlgg== X-Received: by 2002:a05:600c:a085:b0:480:3230:6c9b with SMTP id 5b1f17b1804b1-4805ce3fd49mr85376395e9.7.1769450035141; Mon, 26 Jan 2026 09:53:55 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julian Vetter , Teddy Astie , Oleksii Kurochko , "Daniel P . Smith" Subject: [PATCH 08/16] xen/sysctl: Drop XEN_SYSCTL_get_cpu_levelling_caps Date: Mon, 26 Jan 2026 17:53:37 +0000 Message-Id: <20260126175345.2078371-9-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260126175345.2078371-1-andrew.cooper3@citrix.com> References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This hypercall is an addition of mine from commit 67528a3f0649 ("x86/cpu: Sysctl and common infrastructure for levelling context switching", 2016), but it never got wired into any toolstacks. In the meantime, how we handle CPUID for guests has evolved substantially. In order to reuse the AMD levelling infrasturcture for boot time quirks, levelling_caps is going to have to change. While it's probably safe to expose this difference, it's safer still to make it an internal detail. When re-plummbing the LCAP_* constants, turn them all into single bits. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Julian Vetter CC: Teddy Astie CC: Oleksii Kurochko CC: Daniel P. Smith --- CHANGELOG.md | 2 ++ tools/flask/policy/modules/dom0.te | 1 - tools/include/xenguest.h | 1 - tools/libs/guest/xg_cpuid_x86.c | 14 -------------- xen/arch/x86/include/asm/cpuid.h | 15 ++++++--------- xen/arch/x86/sysctl.c | 6 ------ xen/include/public/sysctl.h | 22 +--------------------- xen/xsm/flask/hooks.c | 4 ---- xen/xsm/flask/policy/access_vectors | 2 -- 9 files changed, 9 insertions(+), 58 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 18f3d10f20d2..425118bc9ae9 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -19,6 +19,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) - The cpuid_mask_* command line options for legacy CPUs. These were deprecated in Xen 4.7 and noted not to work correctly with AMD CPUs from 2011 onwards, nor work at all with Intel CPUs from 2012. + - The SYSCTL_get_cpu_levelling_caps sysctl. This is not known to have been + used by any toolstack. - Xenoprofile support. Oprofile themselves removed support for Xen in 2014 prior to the version 1.0 release, and there has been no development since before then in Xen. diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te index d30edf8be1fb..aae69041a966 100644 --- a/tools/flask/policy/modules/dom0.te +++ b/tools/flask/policy/modules/dom0.te @@ -43,7 +43,6 @@ allow dom0_t xen_t:xen2 { psr_alloc pmu_ctrl get_symbol - get_cpu_levelling_caps get_cpu_featureset livepatch_op coverage_op diff --git a/tools/include/xenguest.h b/tools/include/xenguest.h index 7c3b8b098352..2a277cb7cd61 100644 --- a/tools/include/xenguest.h +++ b/tools/include/xenguest.h @@ -822,7 +822,6 @@ int xc_cpu_policy_update_msrs(xc_interface *xch, xc_cpu_policy_t *policy, bool xc_cpu_policy_is_compatible(xc_interface *xch, xc_cpu_policy_t *host, xc_cpu_policy_t *guest); -int xc_get_cpu_levelling_caps(xc_interface *xch, uint32_t *caps); int xc_get_cpu_featureset(xc_interface *xch, uint32_t index, uint32_t *nr_features, uint32_t *featureset); diff --git a/tools/libs/guest/xg_cpuid_x86.c b/tools/libs/guest/xg_cpuid_x86.c index 263a9d4787b6..0db6d77cd801 100644 --- a/tools/libs/guest/xg_cpuid_x86.c +++ b/tools/libs/guest/xg_cpuid_x86.c @@ -36,20 +36,6 @@ enum { #define bitmaskof(idx) (1u << ((idx) & 31)) #define featureword_of(idx) ((idx) >> 5) -int xc_get_cpu_levelling_caps(xc_interface *xch, uint32_t *caps) -{ - struct xen_sysctl sysctl = {}; - int ret; - - sysctl.cmd = XEN_SYSCTL_get_cpu_levelling_caps; - ret = do_sysctl(xch, &sysctl); - - if ( !ret ) - *caps = sysctl.u.cpu_levelling_caps.caps; - - return ret; -} - int xc_get_cpu_featureset(xc_interface *xch, uint32_t index, uint32_t *nr_features, uint32_t *featureset) { diff --git a/xen/arch/x86/include/asm/cpuid.h b/xen/arch/x86/include/asm/cpuid.h index f1b9e37a42ca..c7ee1d54bc7e 100644 --- a/xen/arch/x86/include/asm/cpuid.h +++ b/xen/arch/x86/include/asm/cpuid.h @@ -15,15 +15,12 @@ extern const uint32_t known_features[FSCAPINTS]; * Expected levelling capabilities (given cpuid vendor/family information), * and levelling capabilities actually available (given MSR probing). */ -#define LCAP_faulting XEN_SYSCTL_CPU_LEVELCAP_faulting -#define LCAP_1cd (XEN_SYSCTL_CPU_LEVELCAP_ecx | \ - XEN_SYSCTL_CPU_LEVELCAP_edx) -#define LCAP_e1cd (XEN_SYSCTL_CPU_LEVELCAP_extd_ecx | \ - XEN_SYSCTL_CPU_LEVELCAP_extd_edx) -#define LCAP_Da1 XEN_SYSCTL_CPU_LEVELCAP_xsave_eax -#define LCAP_6c XEN_SYSCTL_CPU_LEVELCAP_thermal_ecx -#define LCAP_7ab0 (XEN_SYSCTL_CPU_LEVELCAP_l7s0_eax | \ - XEN_SYSCTL_CPU_LEVELCAP_l7s0_ebx) +#define LCAP_faulting (1U << 0) /* CPUID Faulting */ +#define LCAP_1cd (1U << 1) /* 0x00000001.ecx/edx */ +#define LCAP_e1cd (1U << 2) /* 0x80000001.ecx/edx */ +#define LCAP_Da1 (1U << 3) /* 0x0000000D:1.eax */ +#define LCAP_6c (1U << 4) /* 0x00000006.ecx */ +#define LCAP_7ab0 (1U << 5) /* 0x00000007:0.eax/ebx */ extern unsigned int expected_levelling_cap, levelling_caps; struct cpuidmasks diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c index 1b04947516bb..0fbbdd8b280d 100644 --- a/xen/arch/x86/sysctl.c +++ b/xen/arch/x86/sysctl.c @@ -289,12 +289,6 @@ long arch_do_sysctl( break; } - case XEN_SYSCTL_get_cpu_levelling_caps: - sysctl->u.cpu_levelling_caps.caps = levelling_caps; - if ( __copy_field_to_guest(u_sysctl, sysctl, u.cpu_levelling_caps.caps) ) - ret = -EFAULT; - break; - case XEN_SYSCTL_get_cpu_featureset: { static const struct cpu_policy *const policy_table[6] = { diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h index 66c9b65465cc..6b4ec5f7f765 100644 --- a/xen/include/public/sysctl.h +++ b/xen/include/public/sysctl.h @@ -932,25 +932,6 @@ struct xen_sysctl_psr_alloc { } u; }; -/* - * XEN_SYSCTL_get_cpu_levelling_caps (x86 specific) - * - * Return hardware capabilities concerning masking or faulting of the cpuid - * instruction for PV guests. - */ -struct xen_sysctl_cpu_levelling_caps { -#define XEN_SYSCTL_CPU_LEVELCAP_faulting (1UL << 0) /* CPUID faulting */ -#define XEN_SYSCTL_CPU_LEVELCAP_ecx (1UL << 1) /* 0x00000001.ecx */ -#define XEN_SYSCTL_CPU_LEVELCAP_edx (1UL << 2) /* 0x00000001.edx */ -#define XEN_SYSCTL_CPU_LEVELCAP_extd_ecx (1UL << 3) /* 0x80000001.ecx */ -#define XEN_SYSCTL_CPU_LEVELCAP_extd_edx (1UL << 4) /* 0x80000001.edx */ -#define XEN_SYSCTL_CPU_LEVELCAP_xsave_eax (1UL << 5) /* 0x0000000D:1.eax */ -#define XEN_SYSCTL_CPU_LEVELCAP_thermal_ecx (1UL << 6) /* 0x00000006.ecx */ -#define XEN_SYSCTL_CPU_LEVELCAP_l7s0_eax (1UL << 7) /* 0x00000007:0.eax */ -#define XEN_SYSCTL_CPU_LEVELCAP_l7s0_ebx (1UL << 8) /* 0x00000007:0.ebx */ - uint32_t caps; -}; - /* * XEN_SYSCTL_get_cpu_featureset (x86 specific) * @@ -1270,7 +1251,7 @@ struct xen_sysctl { #define XEN_SYSCTL_pcitopoinfo 22 #define XEN_SYSCTL_psr_alloc 23 /* #define XEN_SYSCTL_tmem_op 24 */ -#define XEN_SYSCTL_get_cpu_levelling_caps 25 +/* #define XEN_SYSCTL_get_cpu_levelling_caps 25 */ #define XEN_SYSCTL_get_cpu_featureset 26 #define XEN_SYSCTL_livepatch_op 27 /* #define XEN_SYSCTL_set_parameter 28 */ @@ -1300,7 +1281,6 @@ struct xen_sysctl { struct xen_sysctl_coverage_op coverage_op; struct xen_sysctl_psr_cmt_op psr_cmt_op; struct xen_sysctl_psr_alloc psr_alloc; - struct xen_sysctl_cpu_levelling_caps cpu_levelling_caps; struct xen_sysctl_cpu_featureset cpu_featureset; struct xen_sysctl_livepatch_op livepatch; #if defined(__i386__) || defined(__x86_64__) diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c index b250b2706535..28522dcbd271 100644 --- a/xen/xsm/flask/hooks.c +++ b/xen/xsm/flask/hooks.c @@ -884,10 +884,6 @@ static int cf_check flask_sysctl(int cmd) return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2, XEN2__PSR_ALLOC, NULL); - case XEN_SYSCTL_get_cpu_levelling_caps: - return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2, - XEN2__GET_CPU_LEVELLING_CAPS, NULL); - case XEN_SYSCTL_get_cpu_featureset: return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2, XEN2__GET_CPU_FEATURESET, NULL); diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors index ce907d50a45e..bbb9c117ec4a 100644 --- a/xen/xsm/flask/policy/access_vectors +++ b/xen/xsm/flask/policy/access_vectors @@ -87,8 +87,6 @@ class xen2 pmu_ctrl # PMU use (domains, including unprivileged ones, will be using this operation) pmu_use -# XEN_SYSCTL_get_cpu_levelling_caps - get_cpu_levelling_caps # XEN_SYSCTL_get_cpu_featureset get_cpu_featureset # XEN_SYSCTL_livepatch_op -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 17:54:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 17:54:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213835.1524333 (Exim 4.92) (envelope-from ) id 1vkQml-0005oh-1o; Mon, 26 Jan 2026 17:53:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213835.1524333; Mon, 26 Jan 2026 17:53:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkQmk-0005na-TJ; Mon, 26 Jan 2026 17:53:58 +0000 Received: by outflank-mailman (input) for mailman id 1213835; Mon, 26 Jan 2026 17:53: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 1vkQmj-0004HX-Ji for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 17:53:57 +0000 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [2a00:1450:4864:20::329]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id fbb7a6fe-fadf-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 18:53:55 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-4801eb2c0a5so47916475e9.3 for ; Mon, 26 Jan 2026 09:53:55 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c10dbasm3896455e9.15.2026.01.26.09.53.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 09:53:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fbb7a6fe-fadf-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1769450035; x=1770054835; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=+wd9T6LoaSruhHAOhpkCe8Gt28xOELGHhuvCSdvapew=; b=Us8fo0QRFyEldxIlsunrIgIR5nFIxed7o3TXza1Ty80L982vmxOA6dLxSgtNbNLpv5 i/YwqVGueNFMnxdpDY5O7rfTX62tln7fhHvLU54fh5qm4fTInJWiAEmGwI5pGgwcAHaF zjaNu47wwWWGt86EN/rEFB548h/6JNGWfc5h0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769450035; x=1770054835; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=+wd9T6LoaSruhHAOhpkCe8Gt28xOELGHhuvCSdvapew=; b=ihAVghvFLcYQnNOi6G+2ret7I4IdLEU0NwjAuIP4R67/5umZFgGd2LYAhnIgElxp7j 5nJ3iDssTdqjBumPCnhdx3hdFJIBATswD7WdTiSk4PC+CV6L0CE1VOQxO5TGBu/CZOzt WIWxjN05BgxK2IzKI9igttKaMnQ3FuTh2eoaemPfpkaDwb0+vRznVLFHuEjrc+2lHfo0 NtW30bvCeF7MtuvLG6zkVWZYNGBdGM7u5qu8na7wMgs1tRVx1pPhEAbto6j7HgogVn0f v5dOzPO2D6ZwaPGUnQzjZBv08mncGK+3i/OQtM6AVUieKrcsjWx/hIxVetLXmI5Ry2qm wy5g== X-Gm-Message-State: AOJu0Yx+wnOg1t6zlNHur4r0hIQaQmd5glCZlWBZ+Jb1n5QPej61ETf7 loweWQAu7i8Qg7RKb/O5WMaR2l4rNVk2lvUwyXO5B7Gu5TL8/ynDlIqiLBeKdqmcvZ064+L5wba 74hF6 X-Gm-Gg: AZuq6aKEe/SluhXSwPuJxVORUZY6RIc8f4kOrCFNF4LreG9hZD5F3wrOZxrAN30zX6I uux+ZNI6oU0K8alOKol8Yw7QcxteYJ43uhpY+D/Q+IGQVot9Fwm2nk3OswLPbpd97qGFrp5b+RF 0eTLv6+PiB/D+pZCpNPflYGXkwc3DyQamFHwuCwKPOF6udu0+sZIY2S0rUwTDOkS47G7AbgXln8 DVTT++EcfAYAldSEybAAb2+wIDfAZrATlmOPzcVLQMGFsvgfAnVhUiDC+vBTuexDQD1fhhH0sc0 YD2CkfIivDbByoFOA5HL4QksNMysxSY7q8KBtjznS8K6sAFMjWIN1qvxK2Qn5AICDPs6XBiEmEj Czp3LwZwleGZ/TQfRtkeZv8oP9vZx8KBDWwzkBLR2Wu5gbhgB+61ICyPWaAniJkJUuhe8Msq8Eq Eyy1EBtp4M+r1wE/d7f86z51/aaBfMKUL6oH6kItQRLswf7rvAUwrhTtrltvFuo7IBHZzFGBAf X-Received: by 2002:a05:600c:4684:b0:477:63b5:7148 with SMTP id 5b1f17b1804b1-4805cd40fc4mr89474625e9.6.1769450034271; Mon, 26 Jan 2026 09:53:54 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julian Vetter , Teddy Astie Subject: [PATCH 07/16] x86/cpu: Call the vendor early_init() hook in early_cpu_init() Date: Mon, 26 Jan 2026 17:53:36 +0000 Message-Id: <20260126175345.2078371-8-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260126175345.2078371-1-andrew.cooper3@citrix.com> References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ... which is in practice much earlier on boot. Currently, beyond basic vendor family and model information, the Intel hook needs the SELF_SNOOP CPUID bit which is collected by early_cpu_init() already. The AMD hook needs CPUID_USER_DIS, so the collection of leaf e21a needs to move too. (identify_cpu() has a second collection of this leaf, which remains.) In order to facilitate this, have early_cpu_init() calculate c->extended_cpuid_level in the usual way. No practical change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Julian Vetter CC: Teddy Astie --- xen/arch/x86/cpu/common.c | 35 +++++++++++++++++++---------------- 1 file changed, 19 insertions(+), 16 deletions(-) diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c index 39e64f3a5f88..d70f9cf87dc8 100644 --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -413,8 +413,12 @@ void __init early_cpu_init(bool verbose) } eax = cpuid_eax(0x80000000); - if ((eax >> 16) == 0x8000 && eax >= 0x80000008) { - ebx = eax >= 0x8000001f ? cpuid_ebx(0x8000001f) : 0; + if ((eax >> 16) == 0x8000) + c->extended_cpuid_level = eax; + + if (c->extended_cpuid_level >= 0x80000008) { + ebx = c->extended_cpuid_level >= 0x8000001f + ? cpuid_ebx(0x8000001f) : 0; eax = cpuid_eax(0x80000008); paddr_bits = eax & 0xff; @@ -433,6 +437,19 @@ void __init early_cpu_init(bool verbose) paddr_bits -= (ebx >> 6) & 0x3f; } + if (c->extended_cpuid_level >= 0x80000021) + c->x86_capability[FEATURESET_e21a] = cpuid_eax(0x80000021); + + /* + * Abuse 'verbose' to signal the first pass thought this function. + * + * Besides basic vendor, family and model information, the hooks need + * certain words of x86_capability[] already scanned, as they may take + * action to cause features to reappear. + */ + if (verbose && actual_cpu.c_early_init) + actual_cpu.c_early_init(); + if (!(c->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON))) park_offline_cpus = opt_mce; @@ -485,10 +502,6 @@ void identify_cpu(struct cpuinfo_x86 *c) c->x86_clflush_size = ((ebx >> 8) & 0xff) * 8; c->phys_proc_id = c->apicid; - /* - * Early init of Self Snoop support requires 0x1.edx, while there also - * set 0x1.ecx as the value is in context. - */ c->x86_capability[FEATURESET_1c] = ecx; c->x86_capability[FEATURESET_1d] = edx; @@ -496,16 +509,6 @@ void identify_cpu(struct cpuinfo_x86 *c) if ((eax >> 16) == 0x8000) c->extended_cpuid_level = eax; - /* - * These AMD-defined flags are out of place, but we need - * them early for the CPUID faulting probe code - */ - if (c->extended_cpuid_level >= 0x80000021) - c->x86_capability[FEATURESET_e21a] = cpuid_eax(0x80000021); - - if (c == &boot_cpu_data && actual_cpu.c_early_init) - alternative_vcall(actual_cpu.c_early_init); - /* AMD-defined flags: level 0x80000001 */ if (c->extended_cpuid_level >= 0x80000001) cpuid(0x80000001, &tmp, &tmp, -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 17:54:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 17:54:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213840.1524370 (Exim 4.92) (envelope-from ) id 1vkQmo-0006hr-S4; Mon, 26 Jan 2026 17:54:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213840.1524370; Mon, 26 Jan 2026 17: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 1vkQmo-0006f0-Fg; Mon, 26 Jan 2026 17:54:02 +0000 Received: by outflank-mailman (input) for mailman id 1213840; Mon, 26 Jan 2026 17:54: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 1vkQmm-0004HW-Jw for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 17:54:00 +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 fdb13772-fadf-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 18:53:59 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-4801d21c411so25259695e9.3 for ; Mon, 26 Jan 2026 09:53:58 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c10dbasm3896455e9.15.2026.01.26.09.53.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 09:53:57 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fdb13772-fadf-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1769450038; x=1770054838; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=vQsr194qP7u179I9/onbBLntD3BMN8iVc8+MjUid8Kk=; b=UeTu1bgLfMuHVfScFR4BoTAufg0+dynixuDGwoqQ83Ch4D9sYSg/MXDQpHhG7DxjdR jIjia8oTgYzxiZSMHvgdW4XBJB9VfjcbcBeMLFfT+Oy5fCh9p0OQm+VY21KQqXsVhGeZ WQAcoBoBFXjK/QnNKBBQdBH6c32p5Ezasv0gY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769450038; x=1770054838; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=vQsr194qP7u179I9/onbBLntD3BMN8iVc8+MjUid8Kk=; b=WuykrlqS3YFXsA/bh5ee92SLQRtA5ysvzs76bA7wzaf4W7yKFJsin9QCDePiUql6uL TaWulqY1+hrCoJyDT3HRnQoZ9PGRAOEaA610GUa0EZf9+Ro/dcD+BfHDf5F7oFkNEbef TDJdd8/ewpSJyDTpD/sDSdcN19DapXCGrRF1x/cNF+q0+6f1ez+OtP4vaMJ+8p3YgBOI gZ3zzFNyttvmdxH99+u1U2JsYkl/IzKsGwAS9vzelA3zu7zAValcjS4KEZN8HRcS8KXy e1K6ZvANIFfGIq+KG6hDl2aiEZ2nN7Tg0ti3djG4UJzpng7IVsADiqiF41LzAaZrkX02 XKgQ== X-Gm-Message-State: AOJu0Yyha93gNc1u1dNXohdZByIP5DrWNHyuaCwn3V+1/YxGZOP31QrV V1zwR9U8l+b27dtJXp8MRNa/XecQOhsiSqgK+4iZ/TU1BIpbEI9efpUlggOyt1FHgJzRAwAEUFl uGd5/ X-Gm-Gg: AZuq6aKSofk1fzTXpUSbTNSOm1u3Ddsk6BwztvWqd5r566YfsQnsLPuJwSKZ2XtKtyU Q5AsQobgOwgAy4jPJZhGSspgMKU+grteQtLEQwuHqGwVHEGsIRw+QBODrgmqhL3oLheDj8VEe4h qTh8/NY+gKebW2sHRyCkNWSniwp1Ij3bb3asylggb/zfiyk8I7cq9EkV7reVuUW869sd6bfLTNw qoj0HAySBnxBn3FnW8BZjOqB71YeGTDwznevIXjhZHvQtWWqrtRKRbuv2NbRvME+vyOLAOI1DZQ AAy1YIxRKRZ5JI7Y1nG/bfD2EjhrtlPZYjO5LrS33OqJYSyFAz53jG5d3YBISIQJShYqf+gZMXL 9DqcHU4QoKhgA9ezKRETOLnByxL2xoxEKGDzcO1jVczGIkkyiQ1FNU6WHzK40ro7U1SFSFInDx9 o4e4ZqBMXmhW0Kd/Z46skOtT9hE2qjNiPhvAWXkOXWrbUqS0YgvejiGPFEtIyJuq4whAnr0lTA X-Received: by 2002:a05:600c:528a:b0:480:4a8f:2d5c with SMTP id 5b1f17b1804b1-4805cf6c405mr81861005e9.29.1769450038094; Mon, 26 Jan 2026 09:53:58 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julian Vetter , Teddy Astie Subject: [PATCH 12/16] x86/amd: Probe for NX support and re-activate if possible Date: Mon, 26 Jan 2026 17:53:41 +0000 Message-Id: <20260126175345.2078371-13-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260126175345.2078371-1-andrew.cooper3@citrix.com> References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit An AMD Ryzen system has been found with a firmware option to disable NX. Like we do on Intel systems, try to detect and undo this stupidity. Link: https://xcp-ng.org/forum/post/80714 Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Julian Vetter CC: Teddy Astie Somewhat RFC. I don't particularly like the double handling of MSR_K8_EXT_FEATURE_MASK in this function, but I can't find any way of making the logic legible while trying to dedup the MSR accesses. --- xen/arch/x86/cpu/amd.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c index a14a12fb1d60..06646fc1af93 100644 --- a/xen/arch/x86/cpu/amd.c +++ b/xen/arch/x86/cpu/amd.c @@ -17,6 +17,7 @@ #include #include #include +#include #include "cpu.h" @@ -639,6 +640,40 @@ static void amd_early_adjust_cpuid_extd(void) printk(XENLOG_INFO "CPU: Re-enabling disabled Topology Extensions Support\n"); } } + + /* + * Probe for NX support if it appears to be unavailable. All 64-bit + * capable AMD CPUs support it, but some firmwares have an option to hide + * it in CPUID, apparently for "feature parity" with Intel platforms. + * + * Unlike Intel, there's no active indication that this has been done. A + * conversation with AMD suggests that if we can set EFER.NXE, then NX + * will work. Use this as a heuristic to probe for support, coping with + * the fact that a hypervisor might have really disabled and blocked NX, + * and not emulate the mask MSRs either. + */ + if ( !boot_cpu_has(X86_FEATURE_NX) ) + { + uint64_t *this_efer = &this_cpu(efer); + + if ( wrmsr_safe(MSR_EFER, *this_efer | EFER_NXE) == 0 ) + { + *this_efer |= EFER_NXE; + + if ( !rdmsr_safe(MSR_K8_EXT_FEATURE_MASK, &val) ) + { + val |= 1ULL << cpufeat_bit(X86_FEATURE_NX); + wrmsr_safe(MSR_K8_EXT_FEATURE_MASK, val); + val = rdmsr(MSR_K8_EXT_FEATURE_MASK); + if ( val & (1ULL << cpufeat_bit(X86_FEATURE_NX)) ) + { + __set_bit(X86_FEATURE_NX, c->x86_capability); + printk(XENLOG_INFO "re-enabled NX protection\n"); + bootsym(trampoline_efer) |= EFER_NXE; + } + } + } + } } void __init cf_check early_init_amd(void) -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 17:54:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 17:54:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213829.1524269 (Exim 4.92) (envelope-from ) id 1vkQmg-0004KO-Uu; Mon, 26 Jan 2026 17:53:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213829.1524269; Mon, 26 Jan 2026 17:53: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 1vkQmg-0004JZ-Rf; Mon, 26 Jan 2026 17:53:54 +0000 Received: by outflank-mailman (input) for mailman id 1213829; Mon, 26 Jan 2026 17:53: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 1vkQme-0004HX-VD for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 17:53:53 +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 f85dbad8-fadf-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 18:53:50 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-47ee07570deso36981765e9.1 for ; Mon, 26 Jan 2026 09:53:50 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c10dbasm3896455e9.15.2026.01.26.09.53.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 09:53:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f85dbad8-fadf-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1769450029; x=1770054829; 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=J8VDeI6bdSJ/iIx6zRivtSWpVfW+Hibh8P9MaDiN7nc=; b=Vso1FJiWysmX9CNsr/3mH5PkZ6ouqE4ttITR90AruxQEsmSMfEuVbIMXhcKvhrex0P m9LmMGQ1s2LzxOml885zXwFEVzz03MFZ0ALI97FBftEOIU6uYIkCP5WktA/x/n1TM1j5 ynVPg3QnZ8sVcU6wlEuAKL5Tlg4txOiKmhYbA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769450029; x=1770054829; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=J8VDeI6bdSJ/iIx6zRivtSWpVfW+Hibh8P9MaDiN7nc=; b=htKnKH14cTpbwLBvrou7RBEHe9G4tDdFVcTe1MlzbuvEmN1LEQ9q1KPPXkKe90EPSg 3iS5Fhbk8XqZ9VjlLS6we4Z2rENebVIWNGRv4idtOLVYKATXbt6pOJG/y+s9TC6f/D+F DUacryNoFXZ+ib2Ox/GZV+awgLUPqVrTDlMKqA4dckdNyd9QMw99GVCr6Nw0A/4q1+Ww uRPINZ+PzV9/9dfyZ2pcQlK1jPjGDa+u6qBuzC+jZQ68IMDwttu3uHdF5HPANl6qC0pU Rfv89dMQf9yx3ZOFpUNnCksk1r7McBo6TVzkmUz5rNZnbWJJUtKT5Syau9ibrQS4YOoZ GWHw== X-Gm-Message-State: AOJu0YynBsMizj5a/1OB5dXJH78Y88mA0M+FpBVY17ZeKgxKlfE8IWYZ pNkCCasx1ITv0yvJ6K5ykL5K1hfusYbeu12QP9VGcb8bpRsMKTdbCmS3c0Y0L1X2pwcHVDAa/Jj WtMOK X-Gm-Gg: AZuq6aJTDun3tVt+89HQ3KQDFbMMEZ944HmX0v4miY8gHWM3VuHy3BozPsd2fF1HO0W LBw0Zx599F2NYm4afSgFO5MqhnrDx3KRFAX0PeONUSWyK3LmKtiVyof8AHqwVfiopi0W7Wrlu8z +ad9zHk63T6KSfz/O7LQnMIKPKWAeH8wJ1d4b0UpxtnSmDrFIE5ETKYM9cbUvrTIkY97daj2L0c pw9e4hWbfFFt8MeNZnk0C0oqfOkWsbHV/PXxBNbjAKPOBbF+kMi7K5jxpDNrELir0icmINFL2/0 0Is7/XtPq3uhk3QPXpi75p98aVIKq9ZQvkXrPHYXEicdEoth967KyYoIsEvbeeJ/l3wQu9OdkiY IqZrrLb6sSG/GsXGJp7RMWfZWITq4b4qa94SvXJQ68gvo9gmGJpGOqtyhLhiZDopdtyJ9QG/vrD e/VbkK96FSfTPwBq4yIEozjkZf/Yk1HSWo2wM+O6MnqEZ+3vKuDw7K5525ZuvxzA== X-Received: by 2002:a05:600c:468f:b0:477:9b35:3e49 with SMTP id 5b1f17b1804b1-4805cd407d7mr83464515e9.3.1769450029219; Mon, 26 Jan 2026 09:53:49 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julian Vetter , Teddy Astie Subject: [PATCH 00/16] x86/cpu: Cleanup for NX adjustments Date: Mon, 26 Jan 2026 17:53:29 +0000 Message-Id: <20260126175345.2078371-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I was hoping this to be a patch or two, but it got out of hand... https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2287078891 https://gitlab.com/xen-project/hardware/xen-staging/-/commits/andrew/nx The branch has one extra patch to fake up the firmware settings being set to Gitlab CI, not included in this series. Julien: This ought to suitable to rebase your cleanup on to. In the end, I did the AMD adjustment mostly because I needed it to test the correctness of the prior cleanup. The final 4 patches are tangential cleanup which I've kept out of the prior work in case we wish to backport it. Everything prior is relevant to untangling, and mostly for the benefit of the AMD side. The early patches are hopefully non-controvertial. Later patches are a little more RFC, and in need of further testing. Andrew Cooper (16): x86/cpu: Fix boot time cache flushing x86/cpu: Drop cpuid_level adjustment from generic_identify() x86/intel: Drop the paddr_bits workaround for P4 Nocona/Prescott CPUs x86/cpu: Fold generic_identify() into its single caller x86/cpu: Move per-CPU actions out of the vendor early_init() hook x86/cpu: Rework the vendor early_init() hooks to be __init x86/cpu: Call the vendor early_init() hook in early_cpu_init() xen/sysctl: Drop XEN_SYSCTL_get_cpu_levelling_caps x86/intel: Always check MSR_MISC_ENABLE on all CPUs x86/amd: Always probe and configure the masking MSRs x86/amd: Fix re-activation of TopoExt on Fam15h CPUs x86/amd: Probe for NX support and re-activate if possible x86/cpu: Drop NOISY_CAPS x86/cpu: Drop default_init() and default_cpu x86/cpu: Clean up use of LCAP_* constants x86/cpuid: Drop the include of public/sysctl.h CHANGELOG.md | 2 + tools/flask/policy/modules/dom0.te | 1 - tools/include/xenguest.h | 1 - tools/libs/guest/xg_cpuid_x86.c | 14 --- xen/arch/x86/boot/head.S | 1 - xen/arch/x86/boot/trampoline.S | 29 +++--- xen/arch/x86/boot/wakeup.S | 27 +++--- xen/arch/x86/cpu/amd.c | 107 ++++++++++++++------ xen/arch/x86/cpu/common.c | 135 +++++++++++++------------- xen/arch/x86/cpu/cpu.h | 7 +- xen/arch/x86/cpu/hygon.c | 2 + xen/arch/x86/cpu/intel.c | 74 ++++---------- xen/arch/x86/domain.c | 10 +- xen/arch/x86/flushtlb.c | 19 ++-- xen/arch/x86/include/asm/cpuid.h | 17 ++-- xen/arch/x86/include/asm/hvm/hvm.h | 2 + xen/arch/x86/include/asm/hvm/vlapic.h | 2 + xen/arch/x86/include/asm/hvm/vpt.h | 2 + xen/arch/x86/include/asm/trampoline.h | 7 +- xen/arch/x86/sysctl.c | 6 -- xen/include/public/sysctl.h | 22 +---- xen/xsm/flask/hooks.c | 4 - xen/xsm/flask/policy/access_vectors | 2 - 23 files changed, 238 insertions(+), 255 deletions(-) -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 17:54:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 17:54:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213837.1524344 (Exim 4.92) (envelope-from ) id 1vkQmm-00062i-33; Mon, 26 Jan 2026 17:54:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213837.1524344; Mon, 26 Jan 2026 17:54:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkQml-00060p-Sx; Mon, 26 Jan 2026 17:53:59 +0000 Received: by outflank-mailman (input) for mailman id 1213837; Mon, 26 Jan 2026 17:53:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkQmk-0004HW-JI for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 17:53:58 +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 fca4bec7-fadf-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 18:53:57 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-4801c2fae63so38026495e9.2 for ; Mon, 26 Jan 2026 09:53:57 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c10dbasm3896455e9.15.2026.01.26.09.53.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 09:53:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fca4bec7-fadf-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1769450036; x=1770054836; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=RD+FwnuL4ppUz8uo27Is5O2Ip6Cil9yXt9VnPw3KiRc=; b=h7SiuRzmtZ9Vs7j62Bb6eY7ASK6ZT4/X1HAL7DNQrjbf7hWfeGATHcNHfIrVNUXzjr pysAKjj+SuyQu6K6sMM3/Ec3ZCTEgjeouWMa8uslrFS2KeCLxNfPx8vDZdU86MUp0OBH wQ8XuW0wbk7t0eLf/riqTHzZ/PB7Vb7wcWXMg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769450036; x=1770054836; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=RD+FwnuL4ppUz8uo27Is5O2Ip6Cil9yXt9VnPw3KiRc=; b=CwJZ1UQ+IOdC7/8eA1I/vjMLwY2PactN9dQgbbcnbiYU2ytzXp50NUh/gBmEjqTfna 0enRpuqLBKLu9+VtHzYQgCZvagqdEOuR2ztAe9nVEY0BCBqWCVGtuYHvxMpbI8icLdgW PXy9MguL7Jlzyg8Gjn+7a9d2vKSeh+R6rZ23Fqk1hX246go/71r6WY6XsPJdqStDG6NC y9dXIdLbLo9VJxEQ6OozUyAHK4KG8nFS8zRFQchcVBKgE+D908MiwlYrMaf2jAYeZPii NP811SS2Q6WeI8CeSyGtvSj4Ye/0658D8o7c/lNVfhzasoT8JGKbFQp/RSjgEnvdYLov +7bg== X-Gm-Message-State: AOJu0YzkiWi2q7X7Ng9kjeRW9BVnEcwpQBbm6vdUi3uJ3SHsZSeA+tYW VV8yKvTe5mSU61kqVVQG2YaZ9N39xhTirHIovqC/Swk5qeXZmC5oGTlZCLe53+ZaQmABbmxcFzL bI8A0 X-Gm-Gg: AZuq6aLzFdCcbAP85XxgZfBZMZhHuGOuj7/4k/EqxljhiTutOHBmobJMsl2o7VzTSwm sNaSwQuPf+dbnwYwAEV7BONXQFbk/GSPmmbLjArfEXWwe6j3MPQNjDACzIc8GMudN+//Y4+xSvX XdrmfMyUFYT6HCEqT7zr6MRZ0olwT2x/4VWxcz8kjaDvW/kkbOn2OQpJQkLLLi8WXHsaH5bWwt2 tAV3Wckv8HDvPZIq3CJLQWMVN8t+nrKTteHfgYjaC5TBvm8SdkCGardPc+Mr6m4V45wWNUL3GtS GGBm8YdS3Gx00sylXh7tYBg67Ul7+jVlo5MSEQb1DD1jn31EYVuwz8EfGH2ZpZD8Mh1GwkvmB2b YyfKUybEd0gslR0XIlVYfhGG75KoPR/lscCASQeCcy5i7XIPlsyx57N7gflQ3GFmflK33FwDEjs +KbARgCdrtP5EzmWuzm/whzSrrGF4FzM+yh9TK7mo5H7BWNXUZcpDg0vGKv9frDw== X-Received: by 2002:a05:600c:4fd6:b0:480:1d0b:2d15 with SMTP id 5b1f17b1804b1-4805cf63e02mr86010055e9.27.1769450035873; Mon, 26 Jan 2026 09:53:55 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julian Vetter , Teddy Astie Subject: [PATCH 09/16] x86/intel: Always check MSR_MISC_ENABLE on all CPUs Date: Mon, 26 Jan 2026 17:53:38 +0000 Message-Id: <20260126175345.2078371-10-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260126175345.2078371-1-andrew.cooper3@citrix.com> References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently, the BSP only leaves instructions for the APs to adjust MSR_MISC_ENABLE if the BSP is found to need adjustments. Particularly if XD_DISABLE is needed on an AP but not the BSP, the system will triple fault with no information provided to the user. Rework the BSP and trampoline logic to always read MISC_ENABLE, and clear CPUID_LIMIT and XD_DISABLE if either are set. Repurpose intel_unlock_cpuid_leaves() to be intel_check_misc_enable() and make it static in common.c. Replace trampoline_misc_enable_off with the smaller trampoline_check_misc_enable. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Julian Vetter CC: Teddy Astie This temporarily removes the printk() noting the reactivation of XD because the earlier BSP code has already done it, but that logic is about to be removed. --- xen/arch/x86/boot/head.S | 1 - xen/arch/x86/boot/trampoline.S | 29 ++++++++++-------- xen/arch/x86/boot/wakeup.S | 27 ++++++++++------- xen/arch/x86/cpu/common.c | 43 ++++++++++++++++++++++++++- xen/arch/x86/cpu/cpu.h | 2 -- xen/arch/x86/cpu/intel.c | 19 ------------ xen/arch/x86/include/asm/trampoline.h | 7 +++-- 7 files changed, 79 insertions(+), 49 deletions(-) diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S index 77bb7a9e2191..4022f8639478 100644 --- a/xen/arch/x86/boot/head.S +++ b/xen/arch/x86/boot/head.S @@ -582,7 +582,6 @@ trampoline_setup: btr $2, %edx jnc .Lno_nx wrmsr - orb $MSR_IA32_MISC_ENABLE_XD_DISABLE >> 32, 4 + sym_esi(trampoline_misc_enable_off) /* Check again for NX */ mov $0x80000001, %eax diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S index a92e399fbe0e..2b4552096fd7 100644 --- a/xen/arch/x86/boot/trampoline.S +++ b/xen/arch/x86/boot/trampoline.S @@ -77,17 +77,22 @@ trampoline_protmode_entry: mov %eax,%cr3 /* Adjust IA32_MISC_ENABLE if needed (for NX enabling below). */ - mov bootsym_rel(trampoline_misc_enable_off,4,%esi) - mov bootsym_rel(trampoline_misc_enable_off+4,4,%edi) - mov %esi,%eax - or %edi,%eax - jz 1f + cmpb $1, bootsym_rel(trampoline_check_misc_enable, 5) + jne 1f + mov $MSR_IA32_MISC_ENABLE,%ecx rdmsr - not %esi - not %edi - and %esi,%eax - and %edi,%edx + + xor %edi, %edi + btr $22 /* ilog2(MSR_IA32_MISC_ENABLE_LIMIT_CPUID) */, %eax + adc %edi, %edi + + btr $34 /* ilog2(MSR_IA32_MISC_ENABLE_XD_DISABLE) */ - 32, %edx + adc %edi, %edi + + /* No bits need clearing? Nothing to do */ + jz 1f + wrmsr 1: /* Set up PAT before enabling paging. */ @@ -141,9 +146,6 @@ gdt_48: .long trampoline_gdt + BOOT_PSEUDORM_DS + 2 - . .popsection -GLOBAL(trampoline_misc_enable_off) - .quad 0 - /* EFER OR-mask for boot paths. SCE conditional on PV support, NX added when available. */ GLOBAL(trampoline_efer) .long EFER_LME | (EFER_SCE * IS_ENABLED(CONFIG_PV)) | \ @@ -155,6 +157,9 @@ GLOBAL(trampoline_xen_phys_start) GLOBAL(trampoline_cpu_started) .byte 0 +GLOBAL(trampoline_check_misc_enable) + .byte 0 + LABEL(trampoline_perm_end, 0) /* From here on early boot only. */ diff --git a/xen/arch/x86/boot/wakeup.S b/xen/arch/x86/boot/wakeup.S index 654e97005ff4..aced8153bafa 100644 --- a/xen/arch/x86/boot/wakeup.S +++ b/xen/arch/x86/boot/wakeup.S @@ -126,18 +126,23 @@ wakeup_32: add bootsym_rel(trampoline_xen_phys_start,4,%eax) mov %eax,%cr3 - /* Reapply IA32_MISC_ENABLE modifications from early_init_intel(). */ - mov bootsym_rel(trampoline_misc_enable_off, 4, %esi) - mov bootsym_rel(trampoline_misc_enable_off + 4, 4, %edi) - mov %esi, %eax - or %edi, %eax - jz 1f - mov $MSR_IA32_MISC_ENABLE, %ecx + /* Adjust IA32_MISC_ENABLE if needed (for NX enabling below). */ + cmpb $1, bootsym_rel(trampoline_check_misc_enable, 5) + jne 1f + + mov $MSR_IA32_MISC_ENABLE,%ecx rdmsr - not %esi - not %edi - and %esi, %eax - and %edi, %edx + + xor %edi, %edi + btr $22 /* ilog2(MSR_IA32_MISC_ENABLE_LIMIT_CPUID) */, %eax + adc %edi, %edi + + btr $34 /* ilog2(MSR_IA32_MISC_ENABLE_XD_DISABLE) */ - 32, %edx + adc %edi, %edi + + /* No bits need clearing? Nothing to do */ + jz 1f + wrmsr 1: /* Set up PAT before enabling paging. */ diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c index d70f9cf87dc8..0249bb4bf2dc 100644 --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #include @@ -307,6 +308,46 @@ static inline u32 phys_pkg_id(u32 cpuid_apic, int index_msb) return _phys_pkg_id(get_apic_id(), index_msb); } +/* + * Disable restrictions in MSR_MISC_ENABLE. These are often available as + * firmware settings for backwards compatibility. Called prior to cpuid_level + * being acted upon, as it may need unlimiting. + */ +static void __init intel_check_misc_enable(struct cpuinfo_x86 *c) +{ + uint64_t misc_enable, disable = (MSR_IA32_MISC_ENABLE_LIMIT_CPUID | + MSR_IA32_MISC_ENABLE_XD_DISABLE); + + /* Instruct the trampoline to perform the same check too. */ + bootsym(trampoline_check_misc_enable) = true; + + misc_enable = rdmsr(MSR_IA32_MISC_ENABLE); + + if ( (misc_enable & disable) == 0 ) + return; /* Nothing to do */ + + wrmsr(MSR_IA32_MISC_ENABLE, misc_enable & ~disable); + + /* + * When the P4 Nocona introduced the Structured Cache information, it was + * discovered that WinNT crashed on encountering a CPUID Leaf 4. Intel + * worked around this by introducing an ability to limit the maximum + * reported leaf to 2 (PSN, leaf 3 had already been removed by this time). + */ + if ( misc_enable & MSR_IA32_MISC_ENABLE_LIMIT_CPUID ) + { + c->cpuid_level = cpuid_eax(0); + printk(XENLOG_INFO "revised cpuid level: %u\n", c->cpuid_level); + } + + /* + * When Intel added XD support originally, it was recommended to be off by + * default because of stability problems in WinXP SP2. + */ + if ( misc_enable & MSR_IA32_MISC_ENABLE_XD_DISABLE ) + printk(XENLOG_INFO "re-enabled NX (Execute Disable) protection\n"); +} + /* Do minimum CPU detection early. Fields really needed: vendor, cpuid_level, family, model, mask, cache alignment. The others are not touched to avoid unwanted side effects. @@ -327,7 +368,7 @@ void __init early_cpu_init(bool verbose) c->x86_vendor = x86_cpuid_lookup_vendor(ebx, ecx, edx); switch (c->x86_vendor) { - case X86_VENDOR_INTEL: intel_unlock_cpuid_leaves(c); + case X86_VENDOR_INTEL: intel_check_misc_enable(c); actual_cpu = intel_cpu_dev; break; case X86_VENDOR_AMD: actual_cpu = amd_cpu_dev; break; case X86_VENDOR_CENTAUR: actual_cpu = centaur_cpu_dev; break; diff --git a/xen/arch/x86/cpu/cpu.h b/xen/arch/x86/cpu/cpu.h index 0fc6370edb13..d2d37d1d5eec 100644 --- a/xen/arch/x86/cpu/cpu.h +++ b/xen/arch/x86/cpu/cpu.h @@ -27,6 +27,4 @@ void amd_init_ssbd(const struct cpuinfo_x86 *c); void amd_init_spectral_chicken(void); void detect_zen2_null_seg_behaviour(void); -void intel_unlock_cpuid_leaves(struct cpuinfo_x86 *c); - #endif /* X86_CPU_H */ diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c index 2aeeb2f5bf55..b1dd06d92f60 100644 --- a/xen/arch/x86/cpu/intel.c +++ b/xen/arch/x86/cpu/intel.c @@ -309,22 +309,6 @@ static void __init intel_init_levelling(void) ctxt_switch_masking = intel_ctxt_switch_masking; } -/* Unmask CPUID levels if masked. */ -void __init intel_unlock_cpuid_leaves(struct cpuinfo_x86 *c) -{ - uint64_t misc_enable, disable; - - rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable); - - disable = misc_enable & MSR_IA32_MISC_ENABLE_LIMIT_CPUID; - if (disable) { - wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable & ~disable); - bootsym(trampoline_misc_enable_off) |= disable; - c->cpuid_level = cpuid_eax(0); - printk(KERN_INFO "revised cpuid level: %u\n", c->cpuid_level); - } -} - /* * Errata BA80, AAK120, AAM108, AAO67, BD59, AAY54: Rapid Core C3/C6 Transition * May Cause Unpredictable System Behavior @@ -392,9 +376,6 @@ static void __init probe_mwait_errata(void) static void __init cf_check early_init_intel(void) { - if ( bootsym(trampoline_misc_enable_off) & MSR_IA32_MISC_ENABLE_XD_DISABLE ) - printk(KERN_INFO "re-enabled NX (Execute Disable) protection\n"); - check_memory_type_self_snoop_errata(); /* diff --git a/xen/arch/x86/include/asm/trampoline.h b/xen/arch/x86/include/asm/trampoline.h index deed2679d9d5..893bbe54f325 100644 --- a/xen/arch/x86/include/asm/trampoline.h +++ b/xen/arch/x86/include/asm/trampoline.h @@ -153,10 +153,11 @@ extern uint8_t trampoline_cpu_started; extern uint32_t trampoline_efer; /* - * When nonzero, clear the specified bits in MSR_MISC_ENABLE. This is - * necessary to clobber XD_DISABLE before trying to set MSR_EFER.NXE. + * Instruction from the BSP to APs that MSR_MISC_ENABLE is available and + * should be checked to remove limitations. This is necessary to clobber + * XD_DISABLE before trying to set MSR_EFER.NXE. */ -extern uint64_t trampoline_misc_enable_off; +extern bool trampoline_check_misc_enable; /* Quirks about video mode-setting on S3 resume. */ extern uint8_t video_flags; -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 17:54:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 17:54:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213843.1524398 (Exim 4.92) (envelope-from ) id 1vkQms-0007Sj-JT; Mon, 26 Jan 2026 17:54:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213843.1524398; Mon, 26 Jan 2026 17:54:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkQmr-0007OB-OR; Mon, 26 Jan 2026 17:54:05 +0000 Received: by outflank-mailman (input) for mailman id 1213843; Mon, 26 Jan 2026 17: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 1vkQmo-0004HW-KW for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 17:54:02 +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 fec40fdb-fadf-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 18:54:00 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-4805ef35864so11603905e9.0 for ; Mon, 26 Jan 2026 09:54:00 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c10dbasm3896455e9.15.2026.01.26.09.53.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 09:53:59 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fec40fdb-fadf-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1769450040; x=1770054840; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=oCtWZ5jsIOSUx1eQSxD4nCRKX4JQJ1b+ozb5fk5XF6E=; b=Hxh1cCQHWBqWBiwzUbkftqMBtcyLrl0t8N/iMtZQYEKDxP1e5biIgvFMoxCU6uu0R/ TiRYZzV9qOl1xEszYskDPdn4F0X8cDIdVbZi9VMcaeJZ4PNUjNdNOWOg42Vt5kM0XSG+ raSdmamK8Vv/XgnBpEwCPeenP7PuaL60CGRlM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769450040; x=1770054840; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=oCtWZ5jsIOSUx1eQSxD4nCRKX4JQJ1b+ozb5fk5XF6E=; b=a0IYXUnbTdaczKnhuzBZ+/vW2uJhSsw95UnDZ3MJ7aAcWgI99J9oHVZz/EJU7rGkCs 4o3OKRdn6X4EA/GrPwIY7exEHR8cCrhnCavTV45wKQOP098zF6KZqGmJet9ulOFNMRdB IVZP7EWQgvbpaWklpWSY143KNS6pooKHcdOKp1+f3myW0xUitgvUFEWkaed3WFaiQ7j2 hi+fxTaWHPz9e6xHGx2H8iAXfQIibaWk2loRcXIZKVqAvnXvp1nHm1soyv18LilokZfj hwnNBL+pJC7lGFeLzn1DC+L8x9heArEoGS93oPKXW1FYcfNIYvLJbbEoZM+sksI0yJZH RmiA== X-Gm-Message-State: AOJu0YyO7D2CfSk88BlTjTIajfKNNauREt71mQtNJvJDgQl6lhHxKedQ dN5TOVkBrrFgiOLc1N2zMO3/laMtLOZuAcjE1fKylU3z3h7BuPTDWptStspca37aYe7Qo11GknB Z4VAb X-Gm-Gg: AZuq6aK85J3u/zTw2d4XrPg9pMahaPUojx2hhWFpGgMMP1IDQjPdmKs7DKOjTSgFEwQ h9E9L5vWkdHgU1nDxY7NSXDw3DlZKdyaDxIo1r7Ztj/isOvcDUy2Ii2XDfQg9nNpDtSE7Wd43ma L4nypfBAM1DamRLDTq7WTDCbmpwF1DbmtuaXAOQkyaCaT5JTMCt/Bry8vgCq1iG6cEvRUQt7lYb CYvtUqGK2qiciY8t51gwdANkwi7uwkVEvLDGAeG5/GkqPjSDUgYESwiolbsMPcl/JXWnfqOaTsC 5k1JArskuWdVescYuRB2yLpXzQsUcZTHRtiH9n/BAqaRljYj9EEEfJ5eObbxITnzR4YGUJSVRQg qbnkg4SIiY038lFwrQ07KmvHNDUMlGPFr3720HaUKAuxUxIpILgoIhhnX5LBP+KpvrZkodycFMY 7KsljQOTEpoh3Q73EhK8HdNkcIz0qYa03saF5klaXCYEn+zuUVfahCe54hRzslcw== X-Received: by 2002:a05:600c:b96:b0:480:1e8f:d15f with SMTP id 5b1f17b1804b1-4805cd40a06mr82761325e9.2.1769450039908; Mon, 26 Jan 2026 09:53:59 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julian Vetter , Teddy Astie Subject: [PATCH 15/16] x86/cpu: Clean up use of LCAP_* constants Date: Mon, 26 Jan 2026 17:53:44 +0000 Message-Id: <20260126175345.2078371-16-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260126175345.2078371-1-andrew.cooper3@citrix.com> References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Now that the LCAP_* constants are single bits, we can simplify the expressions using them. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Julian Vetter CC: Teddy Astie --- xen/arch/x86/cpu/amd.c | 12 ++++++------ xen/arch/x86/domain.c | 10 +++++----- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c index 06646fc1af93..f259a2112a16 100644 --- a/xen/arch/x86/cpu/amd.c +++ b/xen/arch/x86/cpu/amd.c @@ -171,7 +171,7 @@ void cf_check amd_ctxt_switch_masking(const struct vcpu *next) (nextd && is_pv_domain(nextd) && nextd->arch.pv.cpuidmasks) ? nextd->arch.pv.cpuidmasks : &cpuidmask_defaults; - if ((levelling_caps & LCAP_1cd) == LCAP_1cd) { + if (levelling_caps & LCAP_1cd) { uint64_t val = masks->_1cd; /* @@ -192,7 +192,7 @@ void cf_check amd_ctxt_switch_masking(const struct vcpu *next) #define LAZY(cap, msr, field) \ ({ \ if (unlikely(these_masks->field != masks->field) && \ - ((levelling_caps & cap) == cap)) \ + (levelling_caps & cap)) \ { \ wrmsr_amd(msr, masks->field); \ these_masks->field = masks->field; \ @@ -251,7 +251,7 @@ static void __init amd_init_levelling(void) */ probe_masking_msrs(); - if ((levelling_caps & LCAP_1cd) == LCAP_1cd) { + if (levelling_caps & LCAP_1cd) { uint32_t ecx, edx, tmp; cpuid(0x00000001, &tmp, &tmp, &ecx, &edx); @@ -264,7 +264,7 @@ static void __init amd_init_levelling(void) cpuidmask_defaults._1cd = ((uint64_t)ecx << 32) | edx; } - if ((levelling_caps & LCAP_e1cd) == LCAP_e1cd) { + if (levelling_caps & LCAP_e1cd) { uint32_t ecx, edx, tmp; cpuid(0x80000001, &tmp, &tmp, &ecx, &edx); @@ -275,7 +275,7 @@ static void __init amd_init_levelling(void) cpuidmask_defaults.e1cd = ((uint64_t)ecx << 32) | edx; } - if ((levelling_caps & LCAP_7ab0) == LCAP_7ab0) { + if (levelling_caps & LCAP_7ab0) { uint32_t eax, ebx, tmp; cpuid(0x00000007, &eax, &ebx, &tmp, &tmp); @@ -283,7 +283,7 @@ static void __init amd_init_levelling(void) cpuidmask_defaults._7ab0 &= ((uint64_t)eax << 32) | ebx; } - if ((levelling_caps & LCAP_6c) == LCAP_6c) { + if (levelling_caps & LCAP_6c) { uint32_t ecx = cpuid_ecx(6); cpuidmask_defaults._6c &= (~0ULL << 32) | ecx; diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index c29a6b0decee..441f99e92088 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -303,7 +303,7 @@ void domain_cpu_policy_changed(struct domain *d) if ( is_pv_domain(d) ) { - if ( ((levelling_caps & LCAP_1cd) == LCAP_1cd) ) + if ( levelling_caps & LCAP_1cd ) { uint64_t mask = cpuidmask_defaults._1cd; uint32_t ecx = p->basic._1c; @@ -368,7 +368,7 @@ void domain_cpu_policy_changed(struct domain *d) d->arch.pv.cpuidmasks->_1cd = mask; } - if ( ((levelling_caps & LCAP_6c) == LCAP_6c) ) + if ( levelling_caps & LCAP_6c ) { uint64_t mask = cpuidmask_defaults._6c; @@ -378,7 +378,7 @@ void domain_cpu_policy_changed(struct domain *d) d->arch.pv.cpuidmasks->_6c = mask; } - if ( ((levelling_caps & LCAP_7ab0) == LCAP_7ab0) ) + if ( levelling_caps & LCAP_7ab0 ) { uint64_t mask = cpuidmask_defaults._7ab0; @@ -395,7 +395,7 @@ void domain_cpu_policy_changed(struct domain *d) d->arch.pv.cpuidmasks->_7ab0 = mask; } - if ( ((levelling_caps & LCAP_Da1) == LCAP_Da1) ) + if ( levelling_caps & LCAP_Da1 ) { uint64_t mask = cpuidmask_defaults.Da1; uint32_t eax = p->xstate.Da1; @@ -406,7 +406,7 @@ void domain_cpu_policy_changed(struct domain *d) d->arch.pv.cpuidmasks->Da1 = mask; } - if ( ((levelling_caps & LCAP_e1cd) == LCAP_e1cd) ) + if ( levelling_caps & LCAP_e1cd ) { uint64_t mask = cpuidmask_defaults.e1cd; uint32_t ecx = p->extd.e1c; -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 17:54:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 17:54:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213831.1524282 (Exim 4.92) (envelope-from ) id 1vkQmh-0004Xf-Ij; Mon, 26 Jan 2026 17:53:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213831.1524282; Mon, 26 Jan 2026 17:53:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkQmh-0004Tl-Bs; Mon, 26 Jan 2026 17:53:55 +0000 Received: by outflank-mailman (input) for mailman id 1213831; Mon, 26 Jan 2026 17:53:53 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkQmf-0004HW-Mq for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 17:53:53 +0000 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [2a00:1450:4864:20::32d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fa6536aa-fadf-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 18:53:53 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-47ee301a06aso55313495e9.0 for ; Mon, 26 Jan 2026 09:53:53 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c10dbasm3896455e9.15.2026.01.26.09.53.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 09:53:52 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fa6536aa-fadf-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1769450032; x=1770054832; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=SVFZKPX+rQ8GQmkwaOmVq1QfQ8v/dwJRo6+jPX9Dkm8=; b=P5S1xDUJCNyQG6IbahEYbDcJgsxRGwxBQ6SKXjhtDSpPesxnWhaY4T00BJQtND38Mk E5uDTW5eDbo2BNhmyD7EvTdGrOHHdrKLITE+3UAH8mGCAVOCxSp/K8Ncf8JrRE1mJQ/H r2hCebZoFt88ndlyphl/ZNjPYFrkMDpRPRF7M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769450032; x=1770054832; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=SVFZKPX+rQ8GQmkwaOmVq1QfQ8v/dwJRo6+jPX9Dkm8=; b=BOGTLRcph9WgxQqQk3o5MjcsVx8HIKWbdCOVfDf+0x50JkOr4CZuBO1LkLL+SfPz94 g3QG7yAFsfq992ShOd1AuVpjtxEJ6K7TT47ljFgDwnSfqTzGobYaOoTtjuIJ7sfSZG5b 8/he8eBfIYLeH9PjAGBSu8nnYz6op90cJ/A+QVrxf8xnYvwSw4EYPi0kzUSGrUChtkI6 ZPP5IvAeb2dBv5OtcIIIfiZXlZZpG70QUXr/rHqCPXh/3iXrvCjrMUGqI6SJIvqRfidX Jrly2E9hT5WDNRbLBKTYvmOZ1QErVv+jwn0yS0n9wxXPr7ZeQjsSxsBkd6ZB5jvzn4xr qOVw== X-Gm-Message-State: AOJu0Yw+QEvZy9w2bsrF4U/5vlXsAQE12I8p+Ln+FojK+E6oNJFsvWkK O37qipBNkCljwbpNlm26rJjWS3T+xZvXlTMLbWJj++ESSlS3OdHVJv9jtpVoTzFkHVa1+13K0w1 jR1Nq X-Gm-Gg: AZuq6aLImjM8Uae1dH94byu1ln6wTch/kOKuD+hR2ZK64fktNy7d3a3mXuxtzh2zJzE w1hc5ST+U0AzJfZse3VcAlAj+S3g3/ys2ZsyUTxoVe+d1TEqs97JN5NQUeiJDtPMOQxPiFJKhYf tcwh7Js2Pp5ezzNI+p4/zpXl56te1uWwAVWGtVvCerEa/BJewYNw+xc3GntnnyBTOXv2N6Fhrmt JNymRnmmj6wv4hR3GAztg/RushXEHYe4Rbjx6GpRfMT5Q3y/q+3AilHAfRX6wY5nb9h2VDLitS2 ALcHpgn4dBviFFUE2zkJTcXHQ6TlWo53BF1wuqtHxJGqymXtU08bK2G5UTeQJ9yJHVg1oHPmT8l MSxXWxlLDt9mSuqj7rSkhvTNpOrWUiKY5DDdFyi1u9L2WxvjWiXwlDOFlAkj4hYVLV9t9Xp+R69 z1x4g4fBa5Rb1FdfIQjPuYy4BW2EEJdYKRArk088Pood/KCoPp82Fv34YVrPtjfQ== X-Received: by 2002:a05:600c:35ce:b0:47d:3ead:7440 with SMTP id 5b1f17b1804b1-4805d06c428mr85483385e9.32.1769450032374; Mon, 26 Jan 2026 09:53:52 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julian Vetter , Teddy Astie Subject: [PATCH 05/16] x86/cpu: Move per-CPU actions out of the vendor early_init() hook Date: Mon, 26 Jan 2026 17:53:34 +0000 Message-Id: <20260126175345.2078371-6-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260126175345.2078371-1-andrew.cooper3@citrix.com> References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit cpu_dev.c_early_init() and .c_init() is a spilt we inherited from Linux. In Xen, these are called moments apart in identify_cpu(). The only logic between the two calls is filling part of c->x86_capability[] and collecting the the long model name. We are going to want to repurpose .c_early_init() somewhat, so move the logic wanting running on all CPUs to the .c_init() hook, which is only marginally later. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Julian Vetter CC: Teddy Astie --- xen/arch/x86/cpu/amd.c | 4 ++-- xen/arch/x86/cpu/hygon.c | 2 ++ xen/arch/x86/cpu/intel.c | 12 ++++++------ 3 files changed, 10 insertions(+), 8 deletions(-) diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c index fc496dc43e08..970cb42e9e0b 100644 --- a/xen/arch/x86/cpu/amd.c +++ b/xen/arch/x86/cpu/amd.c @@ -621,8 +621,6 @@ void cf_check early_init_amd(struct cpuinfo_x86 *c) { if (c == &boot_cpu_data) amd_init_levelling(); - - ctxt_switch_levelling(NULL); } void amd_log_freq(const struct cpuinfo_x86 *c) @@ -1018,6 +1016,8 @@ static void cf_check init_amd(struct cpuinfo_x86 *c) u32 l, h; uint64_t value; + ctxt_switch_levelling(NULL); + amd_init_de_cfg(c); if (c == &boot_cpu_data) diff --git a/xen/arch/x86/cpu/hygon.c b/xen/arch/x86/cpu/hygon.c index b99d83ed4d75..bb1624882499 100644 --- a/xen/arch/x86/cpu/hygon.c +++ b/xen/arch/x86/cpu/hygon.c @@ -32,6 +32,8 @@ static void cf_check init_hygon(struct cpuinfo_x86 *c) { unsigned long long value; + ctxt_switch_levelling(NULL); + amd_init_de_cfg(c); if (c == &boot_cpu_data) diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c index eec6ee763040..141dc2368143 100644 --- a/xen/arch/x86/cpu/intel.c +++ b/xen/arch/x86/cpu/intel.c @@ -327,10 +327,6 @@ void __init intel_unlock_cpuid_leaves(struct cpuinfo_x86 *c) static void cf_check early_init_intel(struct cpuinfo_x86 *c) { - /* Netburst reports 64 bytes clflush size, but does IO in 128 bytes */ - if (c->x86 == 15 && c->x86_cache_alignment == 64) - c->x86_cache_alignment = 128; - if (c == &boot_cpu_data && bootsym(trampoline_misc_enable_off) & MSR_IA32_MISC_ENABLE_XD_DISABLE) printk(KERN_INFO "re-enabled NX (Execute Disable) protection\n"); @@ -350,8 +346,6 @@ static void cf_check early_init_intel(struct cpuinfo_x86 *c) intel_init_levelling(); } - - ctxt_switch_levelling(NULL); } /* @@ -615,6 +609,12 @@ static void init_intel_perf(struct cpuinfo_x86 *c) static void cf_check init_intel(struct cpuinfo_x86 *c) { + /* Netburst reports 64 bytes clflush size, but does IO in 128 bytes */ + if (c->x86 == 15 && c->x86_cache_alignment == 64) + c->x86_cache_alignment = 128; + + ctxt_switch_levelling(NULL); + /* Detect the extended topology information if available */ detect_extended_topology(c); -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 17:54:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 17:54:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213832.1524293 (Exim 4.92) (envelope-from ) id 1vkQmi-0004lT-6R; Mon, 26 Jan 2026 17:53:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213832.1524293; Mon, 26 Jan 2026 17:53:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkQmh-0004iV-Ub; Mon, 26 Jan 2026 17:53:55 +0000 Received: by outflank-mailman (input) for mailman id 1213832; Mon, 26 Jan 2026 17:53: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 1vkQmg-0004HX-JQ for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 17:53:54 +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 f9452f2f-fadf-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 18:53:51 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-47ee3a63300so54601965e9.2 for ; Mon, 26 Jan 2026 09:53:51 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c10dbasm3896455e9.15.2026.01.26.09.53.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 09:53:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f9452f2f-fadf-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1769450031; x=1770054831; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=zyRXQCzMht59KNrjuruuDRnKF4fVxlGPuMfpmypUDsw=; b=P0MOH0fmzKdVPVOgODqc0ejXooP6WD/ethCQC5LKp6eElyFAZQ0UI/EKzSsDW/2+6z eX8f8+q+o2bE1yuUPPwJkM3sZaLHTMEnAq6YHHo/0vtwGbmEGgkDOXUVx3HXIHvLOoUX FthmN8rXvAoCUC2yFAlTG0ZYLNJihJIDfHJiw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769450031; x=1770054831; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=zyRXQCzMht59KNrjuruuDRnKF4fVxlGPuMfpmypUDsw=; b=aapvZCnwpqhsrkEz8YU7ZSX7HHehnD6B6owZ+QANk9MAgUZ9FXgfxuIujdSBB9ysHY xyiSVH91bF6E6sY1RXd/SeKONsZgrnfFdyrwz+pyqOwyLvOySx9sPWzj278lqfplStJ9 y4V5rwDz69ECh1u3nIt0Rr8feQ7JnS/MnDUsWaqj6CDtfyL5L+W1SXtKHRPa1ASGHgKx aLIQo53c47N8iQzrTA/uXYGqYI48h7GtdNnirJZfqKkClXCgwKz17mWliw7PcNe2+ePp xNkZ7ZUnNyT1WaMI/gEJTrkppRfLEH16JKI/L7pxqRCLBgs0LLc3CnCqTBNyC2fUqx+y bZBA== X-Gm-Message-State: AOJu0YxYVhYi6WAAY8Rbo1X1xVDMpZP+hFrgYtJusYf8ulpoQH22fbgU dW8uQq6gOfzEeEkUgaiBBpCmOlIOSv5GnLFMsGuaZjRQGCR5W+s9/NjVire6AkyscUr8gEhc0/s Ww18+ X-Gm-Gg: AZuq6aKnv7W1HkceKpc6d547aoEy/qjLwlPrhVuxfSU2mUbT9Hze1XZW1mgcofTOsYQ DTkyr0zcqqpyL7n6838JbfmBJTq6be5TX/P4w8Z/7VxwIeDl9TYNrBF8vZmCX0DgbL5rr/S5t+n XZPbhP87cs2J3t435g2TX4BsUGhAYDIVuFTmcX7LtIw0xDuoft/YAYdrMeFHJE6j441IFRusj6D J3pm3AFCVHvP4CrRlaFvpEMupyt8kvaI4+j+uggyJ36oIPvH4kuZ0hV1lslpWwKe/TjOCyFpEN8 OUpzEl7pnig79VhVGMpDapm7ZgxAuntyyLCHJet3e6W6v7xM7QoDCtK2H2lKsa7AgcAyJi1YC2h 8jqoGvCklMETZr8bmuLFNoWxa7ysPF+yI1PFWjgIy6QTR8WIU0RxRgfcYhxrA32c9DJpG48TudU GCJziuGsKJhw+efB4EGnCRZyTG0I/hXLE4rbfhftio7nBOP7PGB+DKKf7W5bZ4RmaAAzWxjWqr X-Received: by 2002:a05:600c:1e2a:b0:471:14b1:da13 with SMTP id 5b1f17b1804b1-4805ce4dec1mr81666095e9.14.1769450030839; Mon, 26 Jan 2026 09:53:50 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julian Vetter , Teddy Astie , Kevin Lampis Subject: [PATCH 03/16] x86/intel: Drop the paddr_bits workaround for P4 Nocona/Prescott CPUs Date: Mon, 26 Jan 2026 17:53:32 +0000 Message-Id: <20260126175345.2078371-4-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260126175345.2078371-1-andrew.cooper3@citrix.com> References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit These are 32bit CPUs only. 64bit support started with model 4 (Prescott-256). Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Julian Vetter CC: Teddy Astie CC: Kevin Lampis This ideally wants backporting to 4.20 along with the rest of the VFM cleanup in order to support DMR/NVL, which ends with removing the x86_ prefixed names. --- xen/arch/x86/cpu/intel.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c index d585161dd32f..eec6ee763040 100644 --- a/xen/arch/x86/cpu/intel.c +++ b/xen/arch/x86/cpu/intel.c @@ -335,11 +335,6 @@ static void cf_check early_init_intel(struct cpuinfo_x86 *c) bootsym(trampoline_misc_enable_off) & MSR_IA32_MISC_ENABLE_XD_DISABLE) printk(KERN_INFO "re-enabled NX (Execute Disable) protection\n"); - /* CPUID workaround for Intel 0F33/0F34 CPU */ - if (boot_cpu_data.x86 == 0xF && boot_cpu_data.x86_model == 3 && - (boot_cpu_data.x86_mask == 3 || boot_cpu_data.x86_mask == 4)) - paddr_bits = 36; - if (c == &boot_cpu_data) { uint64_t misc_enable; -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 17:54:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 17:54:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213838.1524361 (Exim 4.92) (envelope-from ) id 1vkQmn-0006SW-M3; Mon, 26 Jan 2026 17:54:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213838.1524361; Mon, 26 Jan 2026 17:54:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkQmn-0006RK-Aw; Mon, 26 Jan 2026 17:54:01 +0000 Received: by outflank-mailman (input) for mailman id 1213838; Mon, 26 Jan 2026 17:53: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 1vkQml-0004HW-Je for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 17:53:59 +0000 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [2a00:1450:4864:20::32c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fd1c4f0e-fadf-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 18:53:58 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-47f5c2283b6so36405185e9.1 for ; Mon, 26 Jan 2026 09:53:57 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c10dbasm3896455e9.15.2026.01.26.09.53.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 09:53:56 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fd1c4f0e-fadf-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1769450037; x=1770054837; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Try1cZQOOfQY5RdnyC25WW3N+d8l3jQHbsgtA/sxQ94=; b=HVQtNFLMzT3MI1HTrdXNhNxM93FlCY3vWD4OHRGyCzMPCOYLu+cNMZ9P5ZjMPS5pPx 9ALF4sC9wDw73TNafQkX8tIIrQlfMfsJ2tBR2qVl9PlPXYwQXl+Bp76BsuGt/W3bqpNq 3zKSw9xPArmfRDI2LYV0acQcZRtpf/3G8RUjg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769450037; x=1770054837; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Try1cZQOOfQY5RdnyC25WW3N+d8l3jQHbsgtA/sxQ94=; b=GFkc8i4eGlP+oCd+yYIGnTxABKTO7CKnAqJFcK9sko5Z+XxUXoBuy0K2uJrw9+Bc2w LxQmT01k+rzXlFj+DM3xIITXEyRwRy2Z2aVy7xv1rUaBChtIwFNwJUa6coXoXXf46A+J uZpKa/wTvH/+GbDA7O2mABdmV+imuE18xMwLHKbKetrilHEmCIOtvNcOXV6DxEs43TUg 5UUsC3c4VPOqeOsF44+k4ANAFX5tpx//e91vHWgE0l6Mm1FUsA+qQ/C8mq86N5yl5AdL U8zmoz+gj111sz/yfpKpDAqFyqGdi9YtAEo5zWsYIchwuvc3SZC8yDjyIt5lNMfYEUGE 2N5g== X-Gm-Message-State: AOJu0YwaMqzyQ1K1uYlBevcjeJpM+JgwHcQpOVmxKpqWZzvJoGMO0klj ghiQM4AdcoEz4sV2X/03BARN4qZ9wLLMKz+g8hdPeXwO0+p88dMXXMpYdupF9XEL5BCT6y7AwVB RCVW9 X-Gm-Gg: AZuq6aL25VX8sRYzQSuvtOCrR6bsdqqGC8+5ms5Z3GF+f5QCzkh65sN4mAbNU/qtNQj J+R4bUMB3mXXbhoZq7ele5129HZc95xXn2Om9gGINrI3xnKW2M4I9Yk0UMhsJq0QwB7gcZ+fsCl 5kN8i9JqFUzi7WvsRE+oErOghd1ygNvOnQiv4Nc5DuD9VgGGGOl22fygPKhwnTXuLWAU8NUKeYM ndnvL4kVnJ3rziyL8QcrDTKbatqRtRJL4i94dvJXacfakYYgt1xm5hRmE686VuFfVj55Ou1L042 RZG9peTrV73UD+1PNAmX3zss2ywNg9YCklneYOVDuHUP0qCB3giBpAD67ADY8x36w/3LFNFY8un GM+nA/O9UAnoggWkaypowhxkPnjsJ6RmoZ5fZE3SC7ahOIjejBRjjsb0V/4Nf7OkqL8g9xRW7Jf tJhdoL/ZTS1YkFNPczURjRHC7LisLNRrAtJMZj6juutvYIoD/XAJHCF9OGTZ3fKA== X-Received: by 2002:a05:600c:c087:b0:477:6374:6347 with SMTP id 5b1f17b1804b1-4805d95d3e1mr64802295e9.22.1769450037164; Mon, 26 Jan 2026 09:53:57 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julian Vetter , Teddy Astie Subject: [PATCH 11/16] x86/amd: Fix re-activation of TopoExt on Fam15h CPUs Date: Mon, 26 Jan 2026 17:53:40 +0000 Message-Id: <20260126175345.2078371-12-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260126175345.2078371-1-andrew.cooper3@citrix.com> References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit init_amd() tries to re-activate TOPOEXT on certain systems, but only after amd_init_levelling() has calculated the levelling defaults, meaning that the re-activation will be lost on the next context switch. Move the logic into early_init_amd() so it takes effect before calculating the levelling defaults. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Julian Vetter CC: Teddy Astie --- xen/arch/x86/cpu/amd.c | 40 ++++++++++++++++++++++++---------------- 1 file changed, 24 insertions(+), 16 deletions(-) diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c index e8daf7415bb0..a14a12fb1d60 100644 --- a/xen/arch/x86/cpu/amd.c +++ b/xen/arch/x86/cpu/amd.c @@ -620,9 +620,32 @@ void amd_process_freq(const struct cpuinfo_x86 *c, *low_mhz = amd_parse_freq(c->x86, lo); } +static void amd_early_adjust_cpuid_extd(void) +{ + struct cpuinfo_x86 *c = &boot_cpu_data; + uint64_t val; + + /* Re-enable TopologyExtensions if switched off by BIOS */ + if ( c->family == 0x15 && c->model >= 0x10 && c->model <= 0x1f && + !boot_cpu_has(X86_FEATURE_TOPOEXT) && + !rdmsr_safe(MSR_K8_EXT_FEATURE_MASK, &val) ) + { + val |= 1ULL << 54; + wrmsr_safe(MSR_K8_EXT_FEATURE_MASK, val); + val = rdmsr(MSR_K8_EXT_FEATURE_MASK); + if ( val & (1ULL << 54) ) + { + __set_bit(X86_FEATURE_TOPOEXT, c->x86_capability); + printk(XENLOG_INFO "CPU: Re-enabling disabled Topology Extensions Support\n"); + } + } +} + void __init cf_check early_init_amd(void) { - amd_init_levelling(); + amd_early_adjust_cpuid_extd(); + + amd_init_levelling(); /* Capture defaults after early CPUID adjustments */ } void amd_log_freq(const struct cpuinfo_x86 *c) @@ -1145,21 +1168,6 @@ static void cf_check init_amd(struct cpuinfo_x86 *c) } } - /* re-enable TopologyExtensions if switched off by BIOS */ - if ((c->x86 == 0x15) && - (c->x86_model >= 0x10) && (c->x86_model <= 0x1f) && - !cpu_has(c, X86_FEATURE_TOPOEXT) && - !rdmsr_safe(MSR_K8_EXT_FEATURE_MASK, &value)) { - value |= 1ULL << 54; - wrmsr_safe(MSR_K8_EXT_FEATURE_MASK, value); - rdmsrl(MSR_K8_EXT_FEATURE_MASK, value); - if (value & (1ULL << 54)) { - __set_bit(X86_FEATURE_TOPOEXT, c->x86_capability); - printk(KERN_INFO "CPU: Re-enabling disabled " - "Topology Extensions Support\n"); - } - } - /* * The way access filter has a performance penalty on some workloads. * Disable it on the affected CPUs. -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 17:54:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 17:54:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213841.1524381 (Exim 4.92) (envelope-from ) id 1vkQmp-0006sd-Lq; Mon, 26 Jan 2026 17:54:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213841.1524381; Mon, 26 Jan 2026 17:54:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkQmp-0006ps-7m; Mon, 26 Jan 2026 17:54:03 +0000 Received: by outflank-mailman (input) for mailman id 1213841; Mon, 26 Jan 2026 17:54: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 1vkQmn-0004HX-BR for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 17:54:01 +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 fe2434e2-fadf-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 18:53:59 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-47ee4539adfso52102525e9.3 for ; Mon, 26 Jan 2026 09:53:59 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c10dbasm3896455e9.15.2026.01.26.09.53.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 09:53:58 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fe2434e2-fadf-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1769450039; x=1770054839; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=l9ikuESfoJcCbCA9QaHk2aoC+EFlVlVQjy3heIMiHxU=; b=cALF6zl3kNzFlDLkSd9pc7xG6FPIyrwSQjRlfPgY9YCNz/m3JgEIPKtOI/Arw6+/lz YsXq7aqN4kPUQ97Oj8FGjFiRb1pedE6slgcFJViDAIiBcaRRhLn3kRMI0SuDWkksHfc6 kthTXxPMy2lB8dzi5cJFtLSHJOPXVF2JSzBZU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769450039; x=1770054839; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=l9ikuESfoJcCbCA9QaHk2aoC+EFlVlVQjy3heIMiHxU=; b=ox4gDOe691eSC/9QjUtzRf4B+Mt/7GplsKqWRceZKZZBT+MVPeEAWLQFMpUAS+r6Qk KGRTUbbOEmMP6g0JWEWN8M4t3SimmdlxP1jIMhnWF27Z6eBE2Qn8RbePhInTzWlnxX5y kZfmIrSsO+9x3MQHYHFb19cwBurNINfzoNIK4ZFHIpLvzHZqhbY5dSJzmjeePcc5VVL7 V4Io8ZJE7oNBSVbFMO0hyzStUBERmrNQ6JdNNCy9KXv9DGFTx6fuRobH1tWgwm7v6l2e 166OUhYzR0mdZLuSwGiFlDl37pz5arx/iGzzrwjyY15VhIJxqcSoDszjqZi6a6HGlT9i 4xXw== X-Gm-Message-State: AOJu0YxqRGbKiEPiPfP7JVVBKG3v5cqPW3yJVUlgHPs62JG+sd49zh/U zMflVpoFTSzFqjjP/ysdtunYlnb/zSTPSPh3nnV1HeV9f3sAEgw7viIA+RgqmqHMS5X//eivREw IK4aV X-Gm-Gg: AZuq6aJ69eRTkwFjxT6rGO6ShigR8OLot53Kggr0JYEaECGHnW4kSdzkvs+eg1lm/Fo lKWLhJLNPaoYwfNyoURQOGmqLAECq/xgDVBBC/OAmEQB+PuDLAkAAwkDRM5ffRvwoz4dgZJGG3r xSJcs3dXmubN3xrUlZ6NnhaCnQYRfz+5i9QrbQ5ornkBXh5eTJ+ADsDz++gGGvlaamb4kWDhuXY 9MDNK4ciN52SHSrm6RSPyGq64mPpHpjpRAVNWpzMUOqGbwKlWK/fo9JwP02NX7ghX2b/8ju9V3q Gns7BO1w6Bx8q9cNEr2tzaP7mh466YX1Ftwko0pjJuU2V6DulCHoQLp4wOI+QzOsNb5q8BhCIZ3 MRD3RL6PrlZrf6LngfBxdmHOzvNk7649tvtVAKhaIJHM7w8+HfOxF3sJqy3MWgpjbG75mJuNcSq 0RoXxM1SUFuACKVGd18rKMI4POuargEFNqpiPMtAdw1EWQU25uJ2R4dpXGHPaqXQ== X-Received: by 2002:a05:600c:528d:b0:477:54cd:200e with SMTP id 5b1f17b1804b1-4805ce3f893mr82672025e9.1.1769450038902; Mon, 26 Jan 2026 09:53:58 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julian Vetter , Teddy Astie Subject: [PATCH 13/16] x86/cpu: Drop NOISY_CAPS Date: Mon, 26 Jan 2026 17:53:42 +0000 Message-Id: <20260126175345.2078371-14-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260126175345.2078371-1-andrew.cooper3@citrix.com> References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit These were plausibly useful for debugging when there were 4 words in x86_capability[], but it's currently 22 words and growing. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Julian Vetter CC: Teddy Astie Even I can't read it in hex any more. --- xen/arch/x86/cpu/common.c | 14 -------------- 1 file changed, 14 deletions(-) diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c index 0249bb4bf2dc..7674cca1ba93 100644 --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -598,13 +598,6 @@ void identify_cpu(struct cpuinfo_x86 *c) c->x86_capability[FEATURESET_m10Ah] = val >> 32; } -#ifdef NOISY_CAPS - printk(KERN_DEBUG "CPU: After vendor identify, caps:"); - for (i = 0; i < NCAPINTS; i++) - printk(" %08x", c->x86_capability[i]); - printk("\n"); -#endif - /* * Vendor-specific initialization. In this section we * canonicalize the feature flags, meaning if there are @@ -641,13 +634,6 @@ void identify_cpu(struct cpuinfo_x86 *c) xstate_init(c); -#ifdef NOISY_CAPS - printk(KERN_DEBUG "CPU: After all inits, caps:"); - for (i = 0; i < NCAPINTS; i++) - printk(" %08x", c->x86_capability[i]); - printk("\n"); -#endif - /* * If RDRAND is available, make an attempt to check that it actually * (still) works. -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 17:54:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 17:54:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213833.1524300 (Exim 4.92) (envelope-from ) id 1vkQmi-0004qw-Hq; Mon, 26 Jan 2026 17:53:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213833.1524300; Mon, 26 Jan 2026 17:53:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkQmi-0004pK-8k; Mon, 26 Jan 2026 17:53:56 +0000 Received: by outflank-mailman (input) for mailman id 1213833; Mon, 26 Jan 2026 17:53: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 1vkQmh-0004HX-JX for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 17:53:55 +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 fa3b9054-fadf-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 18:53:53 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-4801c1ad878so53447625e9.1 for ; Mon, 26 Jan 2026 09:53:53 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c10dbasm3896455e9.15.2026.01.26.09.53.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 09:53:51 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fa3b9054-fadf-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1769450032; x=1770054832; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=wsIV3GSMS2OCjsSf5BdBf2D2nbqVVoqe/FAvijXoOlA=; b=Dimz2o6IP30qbChwn9FSVKkJRXwqn6l5pEezSjPIhlB0rsHPYWtsKC9ZQbDfxD2RKr kAlviDslBgwal05Fl+4aVoCnhQRJv6D55PVh/Rxt2cDA/flOO59Suu5fbLwHI1JpRi4O 21U8llMdBZrWHBRI4ROphIbJhhHRUCquR+uFo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769450032; x=1770054832; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=wsIV3GSMS2OCjsSf5BdBf2D2nbqVVoqe/FAvijXoOlA=; b=FxsPntkiUvKBqE+/2fWKst5GJYbeItDhTEAhMJoYODmqcC6GqrcXv9DyJ5GQD34dFX lUTRf1tT47c6m+5sBRhA9s9zf/QbL47DBXm3KUOSQ7IrGDccyUEGj6YxQ4x0AzRw9++u V25ictWw6Xb1NV7lgDka5qhRhvz0VsUksCoduPLAh8UAz2arR1Epp+1IwdLYXETD9I12 3acg1vTfS5TikGgH+jBfc0BnywRUIHpu9Lvu7Ohiu7tObn+2GPWLefzoNtknsf534EGC WQZoBxKe6q1FhHQGgvSaylZ75FXKLkbDqNcj+xM1WqCzAJ4d9hzUwiZR7hywEzSwmPOT KGeQ== X-Gm-Message-State: AOJu0YwK0/QhksK3FHwy0KBX3l4FG8Avgtska0sKWNAEn7FFf4TEDejl iQZ62507S1XEeWOQdgdVnYLuL3m2Z5Xlmg/JfE8idhZ/dn9uWRbhiraWwKwH6F9OMsd74S5Zx+F olb5y X-Gm-Gg: AZuq6aKr7K04PYbwrZJ9pnbunzAad3oWhlBZvathkl/wuxsh+AWOYku3mfnutgnwJyd Vp8CV59VQowAyYwdqy/HYz1uSdOwAj3Z75zG2M+u/AOpDiqIkTLZ0FvhJb5jE6oFnmD4Vbm/6qS 10oPhqUuDzt0vGZle7lPAtTHmjAYG9bowYfFO/dtFsUkhQs+Z+ynJneS/UKzVEXL5VPlRXHL05L ELQ/kSI+EAAl3nrtI7m9SXaK8u+Dfsxdt4ExPxHSupFbZIpODh/fWtO9VWaRMkJM49TxDQf0nvn Ie5Au6Afvi+VBAJ4UfssD8ZAhKyrra5UvJahPhPidjBoEQfJyCG1XFYuCtOfaqGWqYA6mYe7gXX a5BYwZHS8+n5TNk3B3Inj8ZZZ1Sd0gwV1AWIcXeYz/Oh+93yYc+fboG77gggHkmk0pQEKaukkGp nItEj7xfTFdy2a/O4tkNsHCr8ia4z68il065UfSElP4TDcDl0fM7JnJnSkPTW7Pw== X-Received: by 2002:a05:600c:b95:b0:477:58:7cf4 with SMTP id 5b1f17b1804b1-4805ce3fccamr78919025e9.4.1769450031770; Mon, 26 Jan 2026 09:53:51 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julian Vetter , Teddy Astie Subject: [PATCH 04/16] x86/cpu: Fold generic_identify() into its single caller Date: Mon, 26 Jan 2026 17:53:33 +0000 Message-Id: <20260126175345.2078371-5-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260126175345.2078371-1-andrew.cooper3@citrix.com> References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This makes the correctness of future changes more obvious. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Julian Vetter CC: Teddy Astie --- xen/arch/x86/cpu/common.c | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c index dda0d5d39c92..89b58e6182b9 100644 --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -455,10 +455,13 @@ void reset_cpuinfo(struct cpuinfo_x86 *c, bool keep_basic) CPU_DATA_INIT((*c)); } -static void generic_identify(struct cpuinfo_x86 *c) +void identify_cpu(struct cpuinfo_x86 *c) { uint64_t val; u32 eax, ebx, ecx, edx, tmp; + int i; + + reset_cpuinfo(c, false); /* Get vendor name */ cpuid(0, &c->cpuid_level, &ebx, &ecx, &edx); @@ -550,17 +553,6 @@ static void generic_identify(struct cpuinfo_x86 *c) c->x86_capability[FEATURESET_m10Al] = val; c->x86_capability[FEATURESET_m10Ah] = val >> 32; } -} - -/* - * This does the hard work of actually picking apart the CPU stuff... - */ -void identify_cpu(struct cpuinfo_x86 *c) -{ - int i; - - reset_cpuinfo(c, false); - generic_identify(c); #ifdef NOISY_CAPS printk(KERN_DEBUG "CPU: After vendor identify, caps:"); -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 17:54:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 17:54:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213830.1524277 (Exim 4.92) (envelope-from ) id 1vkQmh-0004RQ-AJ; Mon, 26 Jan 2026 17:53:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213830.1524277; Mon, 26 Jan 2026 17:53:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkQmh-0004Qj-3e; Mon, 26 Jan 2026 17:53:55 +0000 Received: by outflank-mailman (input) for mailman id 1213830; Mon, 26 Jan 2026 17:53: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 1vkQmf-0004HX-JH for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 17:53:53 +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 f95da1ba-fadf-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 18:53:51 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-47ee301a06aso55313185e9.0 for ; Mon, 26 Jan 2026 09:53:51 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c10dbasm3896455e9.15.2026.01.26.09.53.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 09:53:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f95da1ba-fadf-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1769450031; x=1770054831; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=FPbCiqCcqf0/NbE9zeJiJem+K34lkoRlbsFPYopIEac=; b=uKXW59LQ+j6pC//HqjWHvCbuP2qjKwXraAW7xOlMuOCZIJrrj3m3FEdcVN/3+o9YML BSRDecAih92Sf8W+IL0CHtXVK3sgxM69+eRPUn3wuIJM4r2nINEp+P8ez7dYUb9daqBz TYgXIPsXZyCbxYD+JkrJ9i+YCyjEKLgSx2RbU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769450031; x=1770054831; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=FPbCiqCcqf0/NbE9zeJiJem+K34lkoRlbsFPYopIEac=; b=Cqv2cQzygRi/xZdgCjteKk3385jSajPtRHYU+2mwrz1sYp/nzSYtPrrvx0CXhIEFet MgN7DDQjCXBzZmrn3tVvJpmwZjLPSMVTWstjyMDj2N5fr1F5vrEYLJo5a7P7HoJ2//BQ Fah1sLkza91nOUvs8v2K49Tl8Io/u9ebrY/8/awRaBPctC8JwWEhMRCn9WAWmYGktEMt 5T0Qn23mrpgdWIt+iW6kj3FFev2tSP0Q958cvbqdSNZ+ZF3e75aZl5LbIll9jkgn6B27 DCkML4t0CELVF++e65fyk3b9pTSILF4ftN40sgbbzaOOHiP63YQRbLrXp9Apc/6OU2Qq 6Z3Q== X-Gm-Message-State: AOJu0YwZ8tfzxiQ0uAaxY0qaN51Q3a+/Eq2Sg527MZu3T7lEMh6sAOfs +coc14dyxS7WxSVlzrvK095l1WwcRvKHauhVuzswCMkVsuNPHgVMMQR6flBtcc05UlmLraqJrBr urReF X-Gm-Gg: AZuq6aL3ohplvANNSvzSYoD8NdqTfJvrIw2RtPeonE+Z624sxeX7kIrHjQjCnpPd2v7 XUJgryDlnA0n+AuFj5leTYfCu2TBOVEowEgZrxkgCdUZP8j0boGQQEcrUJYLWh5gmjfTeOjaMpD p1EOgiAysmfZLxKRULWwPnW1XXwKkfQEAf4R4AK+yGvtybv6IrwZDyLgznYszTEvsQSEpz9uhZW wf2JEvUbywuqObmNx4zXBtmYBZ9yzwo74RHnwURUTzYQ41i6C5Gigluvyd0cy/pqkYXfI8JQ38x GdP/YbxseLeGndrVeASFYGehZponJgOpJChocO5iiMALq8d81merU2pOzYoLRtLk0+rbqzuc/on T/jZwxRhQPi9BrtWS5WBF3LnbkPfJGKz44IwRgF7hV0LRPkCK2ymAzFalde54zGHditCW34FI31 0mVBO4tF2YfV47VgSnGhxHujOkVBsBDOz4CePbwXE2o/0V5fRk/DZ/ZgQV3yq+rA== X-Received: by 2002:a05:600c:444c:b0:47e:e779:36e with SMTP id 5b1f17b1804b1-4805cf67274mr86300515e9.19.1769450030306; Mon, 26 Jan 2026 09:53:50 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julian Vetter , Teddy Astie Subject: [PATCH 02/16] x86/cpu: Drop cpuid_level adjustment from generic_identify() Date: Mon, 26 Jan 2026 17:53:31 +0000 Message-Id: <20260126175345.2078371-3-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260126175345.2078371-1-andrew.cooper3@citrix.com> References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit early_cpu_init() calls intel_unlock_cpuid_leaves(), which arranges for the boot trampoline to make the adjustment for all APs, meaning the call from early_init_intel() is a no-op. Drop it, allowing intel_unlock_cpuid_leaves() to become __init code. In turn, the adjustments in generic_identify() were a no-op too. Nothing in the c_early_init() hooks modifies the 1c/1d features, so their values in c->x86_capability[] are still good from just above. The ebx variable used to calculate c->x86_clflush_size is still good too, but move the logic earlier so it's more obviously correct. Fixes: fa4d026737a4 ("x86/Intel: unlock CPUID earlier for the BSP") Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Julian Vetter CC: Teddy Astie --- xen/arch/x86/cpu/common.c | 10 +--------- xen/arch/x86/cpu/intel.c | 4 +--- 2 files changed, 2 insertions(+), 12 deletions(-) diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c index f8c80db6eb1d..dda0d5d39c92 100644 --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -479,6 +479,7 @@ static void generic_identify(struct cpuinfo_x86 *c) cpuid(1, &eax, &ebx, &ecx, &edx); c->x86 = get_cpu_family(eax, &c->x86_model, &c->x86_mask); c->apicid = phys_pkg_id((ebx >> 24) & 0xFF, 0); + c->x86_clflush_size = ((ebx >> 8) & 0xff) * 8; c->phys_proc_id = c->apicid; /* @@ -502,15 +503,6 @@ static void generic_identify(struct cpuinfo_x86 *c) if (actual_cpu.c_early_init) alternative_vcall(actual_cpu.c_early_init, c); - /* c_early_init() may have adjusted cpuid levels/features. Reread. */ - c->cpuid_level = cpuid_eax(0); - cpuid(1, &eax, &ebx, - &c->x86_capability[FEATURESET_1c], - &c->x86_capability[FEATURESET_1d]); - - if ( cpu_has(c, X86_FEATURE_CLFLUSH) ) - c->x86_clflush_size = ((ebx >> 8) & 0xff) * 8; - /* AMD-defined flags: level 0x80000001 */ if (c->extended_cpuid_level >= 0x80000001) cpuid(0x80000001, &tmp, &tmp, diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c index 584588e406f2..d585161dd32f 100644 --- a/xen/arch/x86/cpu/intel.c +++ b/xen/arch/x86/cpu/intel.c @@ -310,7 +310,7 @@ static void __init noinline intel_init_levelling(void) } /* Unmask CPUID levels if masked. */ -void intel_unlock_cpuid_leaves(struct cpuinfo_x86 *c) +void __init intel_unlock_cpuid_leaves(struct cpuinfo_x86 *c) { uint64_t misc_enable, disable; @@ -335,8 +335,6 @@ static void cf_check early_init_intel(struct cpuinfo_x86 *c) bootsym(trampoline_misc_enable_off) & MSR_IA32_MISC_ENABLE_XD_DISABLE) printk(KERN_INFO "re-enabled NX (Execute Disable) protection\n"); - intel_unlock_cpuid_leaves(c); - /* CPUID workaround for Intel 0F33/0F34 CPU */ if (boot_cpu_data.x86 == 0xF && boot_cpu_data.x86_model == 3 && (boot_cpu_data.x86_mask == 3 || boot_cpu_data.x86_mask == 4)) -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 17:54:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 17:54:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213844.1524401 (Exim 4.92) (envelope-from ) id 1vkQmt-0007ZQ-1z; Mon, 26 Jan 2026 17:54:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213844.1524401; Mon, 26 Jan 2026 17:54:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkQms-0007Wm-GU; Mon, 26 Jan 2026 17:54:06 +0000 Received: by outflank-mailman (input) for mailman id 1213844; Mon, 26 Jan 2026 17:54: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 1vkQmp-0004HW-Ks for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 17:54:03 +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 ff44c60d-fadf-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 18:54:01 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-47ee9817a35so36683265e9.1 for ; Mon, 26 Jan 2026 09:54:01 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c10dbasm3896455e9.15.2026.01.26.09.54.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 09:54:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ff44c60d-fadf-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1769450041; x=1770054841; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=AM0AV4MNuYAd316Xwda7bgSZwEFUvVU+olFepXiLw+U=; b=NdKv04Phlgl8+qr4D8xRyxT6YieLWJuAXAXkzoeysG5z/fVBjJ8mkbQRR0UbZ1qpmb c1baY6rfChBrqO5zB3qMpHj+kr/7nsApgDRGTvcWw9XUl2AsE2YTEU76AGp35Ut/8U+f G0cmrqPklJajSZYsubPRVJXUNyHbfQwRWlIvw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769450041; x=1770054841; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=AM0AV4MNuYAd316Xwda7bgSZwEFUvVU+olFepXiLw+U=; b=f7CxMO1MFJJnSWwqB8qoI9rrnzfMa6CYbnKnLXn+gCfvgBaUiJhBsjYvj/RZvAwoeo dWyLP/RZpl/o8607qtbE4YxScsToJlHmMWywHZEryo2RYX1SdTTxoe3yzomESrtuW1E5 2OT1cs89kRKRwKYKfKsy2Bj1oyNtOUICo6fjtdoizxaNfupMtVZVeUSoua6l421BE/Cs MV2PY4gnhT1JC8u1uJmE4H+4B2YbOFipJy/yg9Ri25THbyGB6gwsfeQlnpkQB8PR562z VaY1tEhtt3Nqb/ufr3z/Ffb6kLGDbnZ+SbLGV6ueV/8C1A75Zh1gQ9rbVohlSXXSVhs/ vTrA== X-Gm-Message-State: AOJu0YxQeIo2GoOteneGq/RmJOg2R52f/ufMTm10re3Q9n9K9NylDA6z iNWfX6sMU50pGt1sco24xEDsXUOlO5N8hEJ0IOLbR2nZDhkc1vt825EOnRdpK7ZF58tFYmD8HEs wRcas X-Gm-Gg: AZuq6aL6hvXCSY8QncMB3AQ1c3kzsfnUZIUEzVeWgMXHxA/0PUcOKFAMuDJtxcEjjxJ V5ZdS//a0s8O2S2fwAlb6hi9o3rCx176vZRqnJwDAL8l1CZbFE9/zAGkUOzIq07DXtts4VIBKeT gS5sLL63Am69xJCM/bjK8qgJpgdj+aMkvrG2m6u0eD3SrwBxapPCRi+UXufGssfsg0raTclod20 3HoeqgYluLIRrmrAIfg9OKz1A/h+WF+8Y+4UoSSEic9ZS3I9O6HtjdtpoysDgFHpfB2wVOiwA7G FQHkiqqtwclQREA8XBuuyKd/7JlFfyAFAvm9xreK3AUY0I7oQttHN3m2KnPys/2+h15MBZN73pt jIhkhCjuAZaH4oMD7qGNyXDlM/wuVojhNlcT354DNZyYthpUZzeghlZZf2PVQYWHix+kp9+MH5N b++wl58JfnS7/wwVQHSxi6yJyoNin6oMJhOmIUPRqmhAKLeFyUteurIJBbjysVAw== X-Received: by 2002:a05:600c:358d:b0:47e:e61d:b8d2 with SMTP id 5b1f17b1804b1-4805d0645fcmr91718615e9.27.1769450040383; Mon, 26 Jan 2026 09:54:00 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julian Vetter , Teddy Astie Subject: [PATCH 16/16] x86/cpuid: Drop the include of public/sysctl.h Date: Mon, 26 Jan 2026 17:53:45 +0000 Message-Id: <20260126175345.2078371-17-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260126175345.2078371-1-andrew.cooper3@citrix.com> References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Following the removal of XEN_SYSCTL_get_cpu_levelling_caps, asm/cpuid.h doesn't need to include public/sysctl.h, but several other header files were picking up their includes transitively through asm/cpuid.h. Untangle them. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Julian Vetter CC: Teddy Astie --- xen/arch/x86/include/asm/cpuid.h | 2 -- xen/arch/x86/include/asm/hvm/hvm.h | 2 ++ xen/arch/x86/include/asm/hvm/vlapic.h | 2 ++ xen/arch/x86/include/asm/hvm/vpt.h | 2 ++ 4 files changed, 6 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/include/asm/cpuid.h b/xen/arch/x86/include/asm/cpuid.h index c7ee1d54bc7e..774cfdf86894 100644 --- a/xen/arch/x86/include/asm/cpuid.h +++ b/xen/arch/x86/include/asm/cpuid.h @@ -7,8 +7,6 @@ #include #include -#include - extern const uint32_t known_features[FSCAPINTS]; /* diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h index af042ae858af..ede685d030bd 100644 --- a/xen/arch/x86/include/asm/hvm/hvm.h +++ b/xen/arch/x86/include/asm/hvm/hvm.h @@ -19,6 +19,8 @@ #include struct pirq; /* needed by pi_update_irte */ +struct hvm_hw_cpu; +struct xen_domctl_createdomain; #ifdef CONFIG_HVM_FEP /* Permit use of the Forced Emulation Prefix in HVM guests */ diff --git a/xen/arch/x86/include/asm/hvm/vlapic.h b/xen/arch/x86/include/asm/hvm/vlapic.h index c38855119836..f442dec3d975 100644 --- a/xen/arch/x86/include/asm/hvm/vlapic.h +++ b/xen/arch/x86/include/asm/hvm/vlapic.h @@ -12,6 +12,8 @@ #include #include +#include + #define vcpu_vlapic(x) (&(x)->arch.hvm.vlapic) #define vlapic_vcpu(x) (container_of((x), struct vcpu, arch.hvm.vlapic)) #define const_vlapic_vcpu(x) (container_of((x), const struct vcpu, \ diff --git a/xen/arch/x86/include/asm/hvm/vpt.h b/xen/arch/x86/include/asm/hvm/vpt.h index 0b92b286252d..24f0918280cd 100644 --- a/xen/arch/x86/include/asm/hvm/vpt.h +++ b/xen/arch/x86/include/asm/hvm/vpt.h @@ -12,6 +12,8 @@ #include #include +#include + /* * Abstract layer of periodic time, one short time. */ -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 17:54:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 17:54:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213834.1524321 (Exim 4.92) (envelope-from ) id 1vkQmj-0005Rm-Qr; Mon, 26 Jan 2026 17:53:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213834.1524321; Mon, 26 Jan 2026 17:53:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkQmj-0005Pv-Ib; Mon, 26 Jan 2026 17:53:57 +0000 Received: by outflank-mailman (input) for mailman id 1213834; Mon, 26 Jan 2026 17:53: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 1vkQmi-0004HX-Ja for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 17:53:56 +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 fada5a50-fadf-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 18:53:54 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-47ff94b46afso41469725e9.1 for ; Mon, 26 Jan 2026 09:53:54 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c10dbasm3896455e9.15.2026.01.26.09.53.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 09:53:52 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fada5a50-fadf-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1769450033; x=1770054833; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=t6MpUKLCLKO3nERYaHJXRPiOdgAVGABSBDex8VMPnrc=; b=n+em5QK2h2wfDH+FC5a1Nfxh5YXfsF6upNPqqPXfCiculxY0HY7ZkJW5kfpOHNeecp QMv8RFxBCu4jcd6T14gt+5Oild1shHzTGBszYW28PWIsCLoI/VYtQ6USxIwMAq67I6Fb /5yOs6xmWOl8NGmban23vGZ0MmJBkcpEza7Xg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769450033; x=1770054833; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=t6MpUKLCLKO3nERYaHJXRPiOdgAVGABSBDex8VMPnrc=; b=HNG+/xsMCg8QCR2RWAZaFWEVUgCfQl1fApPfWJmOts31ld1pPfOL2Gvtr5U2diMV73 AjmkTrmXrJpC5PbGbqUzT1/HY5I1G0LdZykCC5Ae7YUN2eiy64Ks9rlBSaTSJXK0+Ko+ XrrGri50CWYSBurNZnMDDc05ZncQtu2qJaBPwtSpyXD6aKEi2JxRFyJif81uUqbapqzi 7foDANcv9ylKPT/ggFP1XZljpdab+xpCEfzPoIiKUPT7DAbhdvVZDz9d6kj85d6anFKC MbPmrLBDxVQZAUJpn/WwbtvdGZ+K5n5KTjezqMH5m+Cl13VF2WvlKweC+5fY6KUpn2Xq gSig== X-Gm-Message-State: AOJu0Yz1DLzH92NhP3FKYDmkhHr4TJ4VZPXrjM1dPbYggVWLQsoZ98XJ Y4JmkqnAjRPhodrld0AwPOckmQ8T/TDO9FFt7p+YadgIIM5i/Xm3h9gUW9OAQ2bQZB+BpPvCyE+ 8wJAu X-Gm-Gg: AZuq6aLwAEzn6DySUzm17FzeMdD09MPBlb1bBl3sKpOokZvr//yRUoOoEH+7bWdb/ah WPeI7igxPgQwY9q4sJPbuj9rbh8c721JFlj5a8czPEZqX+LxpYI8feSTtbr268raVkQ2bWBUA4y u960h5pasSnmBbHvDEXBT+IyMh8YS0wkwjAl7G2ZxRc1FoRajbFdu2o7SK/TXFbSirAQ+7dSxVg 9y8jJDKstidXfrUNrjfamW83LNwuKTgAsGmxIhtr8q5AAdQDp2e11/4LteKtWGNtOnUd/X+mdPf uhma9opxuiajaTxDXNjz2yB/GBK851lKBPxVWkccfGiMlSMlQrZyGYuY9KnUiAXi0j6gvlW+W6v 9N5pwyFT+EyhiORK26ajnYfXlJ6GojEoUjuwd2reFNBvEfFwNeBpfZE1Ojh+FGXKtUHVkGZ2sqh eqIwQ6m8KM7Y/RtA7M8TP+x8x9JiXVXIr52F3Ic4V7cHGF2jy/kI0o8HdwqHgyLQ== X-Received: by 2002:a05:600c:681b:b0:47b:deb9:163d with SMTP id 5b1f17b1804b1-4805dd41a1cmr77379775e9.7.1769450033429; Mon, 26 Jan 2026 09:53:53 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julian Vetter , Teddy Astie Subject: [PATCH 06/16] x86/cpu: Rework the vendor early_init() hooks to be __init Date: Mon, 26 Jan 2026 17:53:35 +0000 Message-Id: <20260126175345.2078371-7-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260126175345.2078371-1-andrew.cooper3@citrix.com> References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit All interior actions are now conditional on c == &boot_cpu_data, so rearrange it to the caller in identify_cpu() and drop the hook parameter. This allows early_init_$VENDOR() to become __init, which in turn allows $VENDOR_init_levelling() to cease being noinline. Reposition the early_init_intel() function simply to make diff legible. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Julian Vetter CC: Teddy Astie --- xen/arch/x86/cpu/amd.c | 7 +++---- xen/arch/x86/cpu/common.c | 4 ++-- xen/arch/x86/cpu/cpu.h | 4 ++-- xen/arch/x86/cpu/intel.c | 42 +++++++++++++++++---------------------- 4 files changed, 25 insertions(+), 32 deletions(-) diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c index 970cb42e9e0b..36fea2e0a299 100644 --- a/xen/arch/x86/cpu/amd.c +++ b/xen/arch/x86/cpu/amd.c @@ -224,7 +224,7 @@ static const typeof(ctxt_switch_masking) __initconst_cf_clobber __used csm = * avoid this, as the accidentally-advertised features will not actually * function. */ -static void __init noinline amd_init_levelling(void) +static void __init amd_init_levelling(void) { /* * If there's support for CpuidUserDis or CPUID faulting then @@ -617,10 +617,9 @@ void amd_process_freq(const struct cpuinfo_x86 *c, *low_mhz = amd_parse_freq(c->x86, lo); } -void cf_check early_init_amd(struct cpuinfo_x86 *c) +void __init cf_check early_init_amd(void) { - if (c == &boot_cpu_data) - amd_init_levelling(); + amd_init_levelling(); } void amd_log_freq(const struct cpuinfo_x86 *c) diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c index 89b58e6182b9..39e64f3a5f88 100644 --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -503,8 +503,8 @@ void identify_cpu(struct cpuinfo_x86 *c) if (c->extended_cpuid_level >= 0x80000021) c->x86_capability[FEATURESET_e21a] = cpuid_eax(0x80000021); - if (actual_cpu.c_early_init) - alternative_vcall(actual_cpu.c_early_init, c); + if (c == &boot_cpu_data && actual_cpu.c_early_init) + alternative_vcall(actual_cpu.c_early_init); /* AMD-defined flags: level 0x80000001 */ if (c->extended_cpuid_level >= 0x80000001) diff --git a/xen/arch/x86/cpu/cpu.h b/xen/arch/x86/cpu/cpu.h index bbede57ab00d..0fc6370edb13 100644 --- a/xen/arch/x86/cpu/cpu.h +++ b/xen/arch/x86/cpu/cpu.h @@ -4,7 +4,7 @@ #define X86_CPU_H struct cpu_dev { - void (*c_early_init)(struct cpuinfo_x86 *c); + void (*c_early_init)(void); void (*c_init)(struct cpuinfo_x86 * c); }; @@ -19,7 +19,7 @@ extern void display_cacheinfo(struct cpuinfo_x86 *c); extern void detect_ht(struct cpuinfo_x86 *c); extern bool detect_extended_topology(struct cpuinfo_x86 *c); -void cf_check early_init_amd(struct cpuinfo_x86 *c); +void cf_check early_init_amd(void); void amd_log_freq(const struct cpuinfo_x86 *c); void amd_init_de_cfg(const struct cpuinfo_x86 *c); void amd_init_lfence_dispatch(void); diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c index 141dc2368143..2aeeb2f5bf55 100644 --- a/xen/arch/x86/cpu/intel.c +++ b/xen/arch/x86/cpu/intel.c @@ -251,7 +251,7 @@ static const typeof(ctxt_switch_masking) __initconst_cf_clobber __used csm = intel_ctxt_switch_masking; #endif -static void __init noinline intel_init_levelling(void) +static void __init intel_init_levelling(void) { uint32_t eax, ecx, edx, tmp; @@ -325,29 +325,6 @@ void __init intel_unlock_cpuid_leaves(struct cpuinfo_x86 *c) } } -static void cf_check early_init_intel(struct cpuinfo_x86 *c) -{ - if (c == &boot_cpu_data && - bootsym(trampoline_misc_enable_off) & MSR_IA32_MISC_ENABLE_XD_DISABLE) - printk(KERN_INFO "re-enabled NX (Execute Disable) protection\n"); - - if (c == &boot_cpu_data) { - uint64_t misc_enable; - - check_memory_type_self_snoop_errata(); - - /* - * If fast string is not enabled in IA32_MISC_ENABLE for any reason, - * clear the enhanced fast string CPU capability. - */ - rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable); - if (!(misc_enable & MSR_IA32_MISC_ENABLE_FAST_STRING)) - setup_clear_cpu_cap(X86_FEATURE_ERMS); - - intel_init_levelling(); - } -} - /* * Errata BA80, AAK120, AAM108, AAO67, BD59, AAY54: Rapid Core C3/C6 Transition * May Cause Unpredictable System Behavior @@ -413,6 +390,23 @@ static void __init probe_mwait_errata(void) } } +static void __init cf_check early_init_intel(void) +{ + if ( bootsym(trampoline_misc_enable_off) & MSR_IA32_MISC_ENABLE_XD_DISABLE ) + printk(KERN_INFO "re-enabled NX (Execute Disable) protection\n"); + + check_memory_type_self_snoop_errata(); + + /* + * If fast string is not enabled in IA32_MISC_ENABLE for any reason, + * clear the enhanced fast string CPU capability. + */ + if ( !(rdmsr(MSR_IA32_MISC_ENABLE) & MSR_IA32_MISC_ENABLE_FAST_STRING) ) + setup_clear_cpu_cap(X86_FEATURE_ERMS); + + intel_init_levelling(); +} + /* * P4 Xeon errata 037 workaround. * Hardware prefetcher may cause stale data to be loaded into the cache. -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 17:54:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 17:54:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1213828.1524264 (Exim 4.92) (envelope-from ) id 1vkQmg-0004I4-P6; Mon, 26 Jan 2026 17:53:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1213828.1524264; Mon, 26 Jan 2026 17:53: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 1vkQmg-0004Hw-Kq; Mon, 26 Jan 2026 17:53:54 +0000 Received: by outflank-mailman (input) for mailman id 1213828; Mon, 26 Jan 2026 17:53:53 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkQme-0004HW-Uq for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 17:53:53 +0000 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [2a00:1450:4864:20::32d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f91711f2-fadf-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 18:53:51 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-47ee76e8656so70423015e9.0 for ; Mon, 26 Jan 2026 09:53:51 -0800 (PST) Received: from localhost.localdomain (host-92-26-102-188.as13285.net. [92.26.102.188]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c10dbasm3896455e9.15.2026.01.26.09.53.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 09:53:49 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f91711f2-fadf-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1769450030; x=1770054830; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=0xq1gxDlmDZY+78ggsqSHcLd3bC7dQoTKGaHnAMx1Ws=; b=PfisyyokdKc3ZaO2tC/0omKdYFa2G0kjAUIgx1c76VumZt1OxLX/OlOJiqmIS+QFbb 6GuJvf3NSkaLz8kJXkY1JJOq7+qGing23xT4/8X8dKeBopp1LkqSwS/XJwctE0QcjXDj gKa4I4Rge1582jpjC6VEywT6bqgxnW6zYjS2Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769450030; x=1770054830; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=0xq1gxDlmDZY+78ggsqSHcLd3bC7dQoTKGaHnAMx1Ws=; b=CDe30j+cAJ5ZhM9h/AwnmafSbCHPKDuyhW7LkF8+qSk25LMlGxwSdqxWpEK83TdNDu scpC5YMXYOmLIzns550sE0VRiiqqPeq9QQuZusxqZ0ciH5kxtWDznHjAB+VTUoNYxep3 KCPbEaA5QJ7UaQLdT+m/l1hZkAs91MehcGE1duUjwFijknjlYGgZCqkKWHFxTitw0Fdn kedq3itj7adE3NaocxfwIfhlocnmTvN76aIpqzaPSS5HA/M7BhTg+Q0cm3QzONocL86s 6JhmMeUT89DLqr6R6MOzOtuliGxbmTMymRYSbjV7o0rFKwnpjJTFJL3n69YREbkUGmg9 DAAw== X-Gm-Message-State: AOJu0YwtwcGsQwBf2IQyAesMrFxcKt1g+OP+M1HTJq8o5nUNZxS6Sx/m My2VoFEFSGLXvkbSKr7gFbPcgBjImNL8+of170bdvKvJUXsloYWUhU2ukgsgMaaTMWtCY5vzE9o ccgCF X-Gm-Gg: AZuq6aJoEWn49qyku+sHuOOok/XvSp+XzSvIHYWZ58Z6aXLIwQnChlYnrc6pYs6kfDM 2Np6sy4WT+lHGYOGNYzjIlMgQA30FEzlSTNRDI1rADQ/By13KxiP7F5inihMeydnA8daf5YKSJz SB5bW+4BSr0FD7Ck448BeruZKHaUxDcvb0muL6AxQ93UOjqaRdX3oo9ztrf3HyG32pxikH2ACcf uLkWd/bsigpUxTOUktkHJhsRR8GWyT+IRST/Q28ROnKJ5j5120qkhpkz1/YelvAZytX0tw7b2eV EkolpHzPs9r0Y2XKjpbsWAfp1jNK6q8yGE9DxgshsZjDm5xRNU0h1wBVWUhIMmpZ0TbfG6UJCKo Y3/0r1hlqWQM3ji1QOwL0ktK2cHYA5XMPZpbGC9cwPIOCjC55zq8I8sSXn4cT4yUYGGj+ehq/Z8 kVkNIgwb35tTLSUzSdkaPbpo/DiW3WtJyC6j5o3afy+GgxXrQdimAeTsMDakmgjQ== X-Received: by 2002:a05:600c:1993:b0:47e:e076:c7a2 with SMTP id 5b1f17b1804b1-4805ce4dd37mr88984935e9.15.1769450029713; Mon, 26 Jan 2026 09:53:49 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Julian Vetter , Teddy Astie Subject: [PATCH 01/16] x86/cpu: Fix boot time cache flushing Date: Mon, 26 Jan 2026 17:53:30 +0000 Message-Id: <20260126175345.2078371-2-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260126175345.2078371-1-andrew.cooper3@citrix.com> References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit All 64-bit CPUs have CLFLUSH. AMD introduced it in the K8, Intel in the P4 Willamette core prior to 64-bit support, and VIA/Centaur in the Isaiah. Furthermore, the reported cacheline size is 64 on all CPUs to date. Arguably changeset 19435c10abf7 ("x86: consolidate/enhance TLB flushing interface", 2007) should have initialised c->x86_clflush_size earlier, but even at the time of changeset 3330013e6739 ("VT-d / x86: re-arrange cache syncing", 2022), early_cpu_init() had CLFLUSH-parsing logic but simply failed to record the size. By removing get_cache_line_size() and assuming 16 bytes, the practical consequence for early IOMMU initialisation of SandyBridge era systems is to flush every cacheline 4 times (a pipeline stall too, as those CPUs could only have one flush in flight at a single time). Record c->x86_clflush_size in early_cpu_init(), and panic() if CLFLUSH isn't found. Drop the redundant initialisation of c->x86_cache_alignment. Remove the fallback to 16 bytes in cache_{flush,writeback}(), opting instead for an ASSERT() to confirm that the logic hasn't been re-arranged too early. Fixes: 3330013e6739 ("VT-d / x86: re-arrange cache syncing") Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Julian Vetter CC: Teddy Astie --- xen/arch/x86/cpu/common.c | 7 ++++--- xen/arch/x86/flushtlb.c | 19 +++++++------------ 2 files changed, 11 insertions(+), 15 deletions(-) diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c index ebe2baf8b98a..f8c80db6eb1d 100644 --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -319,8 +319,6 @@ void __init early_cpu_init(bool verbose) uint64_t val; u32 eax, ebx, ecx, edx; - c->x86_cache_alignment = 32; - /* Get vendor name */ cpuid(0x00000000, &c->cpuid_level, &ebx, &ecx, &edx); *(u32 *)&c->x86_vendor_id[0] = ebx; @@ -352,6 +350,7 @@ void __init early_cpu_init(bool verbose) if (edx & cpufeat_mask(X86_FEATURE_CLFLUSH)) { unsigned int size = ((ebx >> 8) & 0xff) * 8; + c->x86_clflush_size = size; c->x86_cache_alignment = size; /* @@ -380,7 +379,9 @@ void __init early_cpu_init(bool verbose) } else setup_clear_cpu_cap(X86_FEATURE_CLZERO); - } + } else + panic("CLFLUSH information not available\n"); + /* Leaf 0x1 capabilities filled in early for Xen. */ c->x86_capability[FEATURESET_1d] = edx; c->x86_capability[FEATURESET_1c] = ecx; diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c index 23721bb52c90..1f8877dcab23 100644 --- a/xen/arch/x86/flushtlb.c +++ b/xen/arch/x86/flushtlb.c @@ -234,8 +234,7 @@ unsigned int flush_area_local(const void *va, unsigned int flags) if ( (!(flags & (FLUSH_TLB|FLUSH_TLB_GLOBAL)) || (flags & FLUSH_VA_VALID)) && - c->x86_clflush_size && c->x86_cache_size && sz && - ((sz >> 10) < c->x86_cache_size) ) + c->x86_cache_size && sz && ((sz >> 10) < c->x86_cache_size) ) { if ( flags & FLUSH_CACHE_EVICT ) cache_flush(va, sz); @@ -264,13 +263,11 @@ unsigned int flush_area_local(const void *va, unsigned int flags) */ void cache_flush(const void *addr, unsigned int size) { - /* - * This function may be called before current_cpu_data is established. - * Hence a fallback is needed to prevent the loop below becoming infinite. - */ - unsigned int clflush_size = current_cpu_data.x86_clflush_size ?: 16; + unsigned int clflush_size = current_cpu_data.x86_clflush_size; const void *end = addr + size; + ASSERT(clflush_size); + alternative("", "mfence", X86_BUG_CLFLUSH_MFENCE); addr -= (unsigned long)addr & (clflush_size - 1); @@ -301,11 +298,9 @@ void cache_writeback(const void *addr, unsigned int size) if ( !boot_cpu_has(X86_FEATURE_CLWB) ) return cache_flush(addr, size); - /* - * This function may be called before current_cpu_data is established. - * Hence a fallback is needed to prevent the loop below becoming infinite. - */ - clflush_size = current_cpu_data.x86_clflush_size ?: 16; + clflush_size = current_cpu_data.x86_clflush_size; + ASSERT(clflush_size); + addr -= (unsigned long)addr & (clflush_size - 1); for ( ; addr < end; addr += clflush_size ) clwb(addr); -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 19:31:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 19:31:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214005.1524433 (Exim 4.92) (envelope-from ) id 1vkSIx-00016e-TO; Mon, 26 Jan 2026 19:31:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214005.1524433; Mon, 26 Jan 2026 19: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 1vkSIx-00016X-Qo; Mon, 26 Jan 2026 19:31:19 +0000 Received: by outflank-mailman (input) for mailman id 1214005; Mon, 26 Jan 2026 19: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 1vkSIv-00016R-Na for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 19:31:17 +0000 Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 93b1ae3f-faed-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 20:31:15 +0100 (CET) Received: from ehlo.thunderbird.net (c-76-133-66-138.hsd1.ca.comcast.net [76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 60QJUX0M3230378 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 26 Jan 2026 11:30:34 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 93b1ae3f-faed-11f0-b15f-2bf370ae4941 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 60QJUX0M3230378 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026012301; t=1769455836; bh=F8FFTbCNA0IjhSYw8p1wkH57XCUpK2L9SYc1+fWEBrQ=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=YqYTbZVJKC/Aw/m2Br3dv5p78b8CchhKHUqaJmxvV9P1lEj6jc6Qw3uSR8WFDmhSl gL98Fl8W2D/XHGdNGF5RyFUOtIdjWU5SAwNTbmi+JzElQeIb6xEayZNU6xYYoxFNbu WaGILQBpkwzRKeveYmOiEB3aBLnZQ2KvKijhAWTZIS+L9PnqmUm5eZrcce50ik3rp8 FbnKe9k3RY3h55u6l3zwOB+S6Ql3WYZeJEV4E9XYFTGlafTCPnFA8xJIPDnmE5bgB3 fM1OI2FeLoO9sVAtoi4qvcU5WLb/fRDW3qpJRKFGMWOsoTsvgRYmO8DUEltOB5Cag8 uMMTU4u5/7+SA== Date: Mon, 26 Jan 2026 11:30:28 -0800 From: "H. Peter Anvin" To: Hou Wenlong , linux-kernel@vger.kernel.org CC: Lai Jiangshan , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Juergen Gross , Boris Ostrovsky , Ard Biesheuvel , Nathan Chancellor , Masahiro Yamada , Vitaly Kuznetsov , =?ISO-8859-1?Q?Thomas_Wei=DFschuh?= , Brian Gerst , Josh Poimboeuf , Andrew Morton , Alexander Graf , Joel Granados , Thomas Huth , Uros Bizjak , Kiryl Shutsemau , Pawan Gupta , Guenter Roeck , "Xin Li (Intel)" , =?ISO-8859-1?Q?Ilpo_J=E4rvinen?= , xen-devel@lists.xenproject.org Subject: =?US-ASCII?Q?Re=3A_=5BRFC_PATCH_0/5=5D_x86/boot=3A_Allow_to_perfor?= =?US-ASCII?Q?m_randomization_for_uncompressed_kernel_image?= User-Agent: K-9 Mail for Android In-Reply-To: References: Message-ID: <7716B334-004D-4CBB-9237-E8AE5CE696CE@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On January 26, 2026 5:33:50 AM PST, Hou Wenlong wrote: >Hi all, > >This RFC patch series introduces relocatable uncompressed kernel image, >which is allowed to perform kerenl image virtual address randomization >in 64-bit booting entry instead of decompression phase=2E > >- Background > >Currently, kernel image virtual address randomization is only performed >during the decompression phase=2E However, in certain scenarios, such as >secure container environments (e=2Eg=2E, Kata Containers), to speed up th= e >boot process, the system may boot directly from an uncompressed kernel >image=2E In such cases, virtual address randomization cannot be executed= =2E >Although the security enhancement provided by KASLR is limited, there is >still a potential demand to allow uncompressed kernel images to perform >virtual address randomization (for example, future support for x86 PIE)= =2E > >- Approaches > >Currently, the x86 kernel uses static compilation, but it retains >relocation information through the '--emit-relocs' option, which is then >simplified into a relocation table using 'relocs' tool=2E To enable >virtual address randomization for uncompressed kernel images, relocation >information is required, and there are several possible approaches: > >1) Who will perform the randomization: > >VMM: The VMM reads vmlinux=2Erelocs after loading vmlinux to perform >randomization=2E This would require additional modifications to the VMM, >and vmlinux=2Erelocs needs to be packaged when shipping=2E > >Kernel: The kernel performs randomization itself at the kernel >entry point, requiring no modifications to the VMM=2E > >2) relocation information format: > >vmlinux=2Erelocs: It only contains the necessary relocation entries and i= s >simplified, making it small enough=2E However, it is a format defined >within the kernel that was previously used only internally and is not >part of the ABI=2E > >rela=2E* sections: It is the standard ELF ABI, but >it contains RIP-relative relocation entries, which are more common in >kernel, causing the kernel image to be larger=2E > >- Implementation > >The final implementation of this plan extends the 'relocs' tool to allow >the insertion of relocation information into a reserved section of the >kernel (referencing the MIPS implementation)=2E This enables the reading >of that information and subsequent execution of relocations when booting >directly from an uncompressed kernel=2E Currently, this implementation is >only available for 64-bit and has been tested with both PVH entry >booting and standard 64-bit Linux entry=2E And the default reserve size i= s >1MB for now, which is enough for defconfig=2E > >- TODO > >Clean up the decompression KASLR code to allow it to be shared with the >booting phase=2E > > >Thanks! > >Hou Wenlong (5): > x86/relocs: Cleanup cmdline options > x86/relocs: Insert relocations into input file > x86: Allow to build relocatable uncompressed kernel binary > x86/boot: Perform virtual address relocation in kernel entry > x86/boot: Use '=2Edata=2Erelocs' section for performing relocations dur= ing > decompression > > arch/x86/Kconfig | 20 ++++++ > arch/x86/Makefile=2Epostlink | 33 +++++++++ > arch/x86/boot/compressed/Makefile | 6 +- > arch/x86/boot/compressed/misc=2Ec | 8 +++ > arch/x86/boot/startup/Makefile | 1 + > arch/x86/boot/startup/kaslr=2Ec | 116 ++++++++++++++++++++++++++++++ > arch/x86/include/asm/setup=2Eh | 1 + > arch/x86/kernel/head_64=2ES | 7 ++ > arch/x86/kernel/vmlinux=2Elds=2ES | 20 ++++++ > arch/x86/lib/cmdline=2Ec | 6 ++ > arch/x86/lib/kaslr=2Ec | 5 ++ > arch/x86/platform/pvh/head=2ES | 15 +++- > arch/x86/tools/relocs=2Ec | 64 ++++++++++++++--- > arch/x86/tools/relocs=2Eh | 15 ++-- > arch/x86/tools/relocs_common=2Ec | 24 ++++--- > 15 files changed, 309 insertions(+), 32 deletions(-) > create mode 100644 arch/x86/Makefile=2Epostlink > create mode 100644 arch/x86/boot/startup/kaslr=2Ec > >-- >2=2E31=2E1 > Hi! At a very quick glance this seems like a very reasonable thing to me, but = since the intent is reduced boot latency (a very worthwhile goal!) do you p= erhaps have any measurements to show how much improvement we are talking ab= out? That would be really useful=2E=20 Thanks!=20 From xen-devel-bounces@lists.xenproject.org Mon Jan 26 19:49:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 19:49:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214017.1524444 (Exim 4.92) (envelope-from ) id 1vkSaZ-0002zt-G5; Mon, 26 Jan 2026 19:49:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214017.1524444; Mon, 26 Jan 2026 19: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 1vkSaZ-0002zm-D0; Mon, 26 Jan 2026 19:49:31 +0000 Received: by outflank-mailman (input) for mailman id 1214017; Mon, 26 Jan 2026 19: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 1vkSaY-0002zg-34 for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 19:49:30 +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 1e5f8ae2-faf0-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 20:49:26 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id D552660121; Mon, 26 Jan 2026 19:49:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EABF5C116C6; Mon, 26 Jan 2026 19:49: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: 1e5f8ae2-faf0-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769456964; bh=y4OL2InCJj7ANEKbgaAtXyG8coS1JKg/AsOVCQz4Tnc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=jr4hv14LaAgXe8G5ODoYO+o0t6UmwfE+D/ak+apZozamlh6GkB++RQ0QNWYhSWP/y icuJmf9V3qM8F/sLgz04jkFQ3RSlEEgAzjQ9s84ig0/3Ug6md8UnPkRhXojPFj5F8a l6vO4M/32i49qJ2tBoZLgp7voGgy7bwd0m5ZAuZt6VEl0KbStuwKM5H8itYd0SvAuW 8k9sjO4MoKNIfc4s4Jys5nUivWeN0z9xHxcLFFBr9q/SqVMPSLXMA9GXaO5mzFE4u8 tRMT7oGBfk3IzFSeqVg01tm+HsiE82/yVSH1UvRVmlWxai5wfE5YgOXgzSly0ev4XC 5FcPUwfUjyKFg== Date: Mon, 26 Jan 2026 11:49:22 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Oleksii Moisieiev cc: Stefano Stabellini , "xen-devel@lists.xenproject.org" , Andrew Cooper , Anthony PERARD , Bertrand Marquis , Jan Beulich , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Volodymyr Babchuk , Grygorii Strashko Subject: Re: [PATCH v8 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver In-Reply-To: <695431e2-bcbb-45ca-8276-a0a23f71c12e@epam.com> Message-ID: References: <695431e2-bcbb-45ca-8276-a0a23f71c12e@epam.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-301432995-1769456964=:7192" 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-301432995-1769456964=:7192 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Mon, 26 Jan 2026, Oleksii Moisieiev wrote: > On 23/01/2026 03:51, Stefano Stabellini wrote: > > Not a full review, but I found three issues plus some spurious changes > > > > > > On Wed, 21 Jan 2026, Oleksii Moisieiev wrote: > >> diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc > >> index 15f7a315a4..268df3010b 100644 > >> --- a/docs/misc/xen-command-line.pandoc > >> +++ b/docs/misc/xen-command-line.pandoc > >> @@ -789,7 +789,7 @@ Specify the bit width of the DMA heap. > >> cpuid-faulting=, msr-relaxed=, > >> pf-fixup= ] (x86) > >> > >> - = List of [ sve= ] (Arm64) > >> + = List of [ sve= ] (Arm) > >> > >> Controls for how dom0 is constructed on x86 systems. > > Spurious change > > > > > >> diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c > >> index e4407d6e3f..be0e6263ae 100644 > >> --- a/tools/libs/light/libxl_arm.c > >> +++ b/tools/libs/light/libxl_arm.c > >> @@ -240,6 +240,10 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc, > >> case LIBXL_ARM_SCI_TYPE_SCMI_SMC: > >> config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; > >> break; > >> + case LIBXL_ARM_SCI_TYPE_SCMI_SMC_MULTIAGENT: > >> + config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA; > >> + config->arch.arm_sci_agent_id = d_config->b_info.arch_arm.arm_sci.agent_id; > >> + break; > >> default: > >> LOG(ERROR, "Unknown ARM_SCI type %d", > >> d_config->b_info.arch_arm.arm_sci.type); > >> diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl > >> index 4a958f69f4..9bfbf09145 100644 > >> --- a/tools/libs/light/libxl_types.idl > >> +++ b/tools/libs/light/libxl_types.idl > >> @@ -554,11 +554,13 @@ libxl_sve_type = Enumeration("sve_type", [ > >> > >> libxl_arm_sci_type = Enumeration("arm_sci_type", [ > >> (0, "none"), > >> - (1, "scmi_smc") > >> + (1, "scmi_smc"), > >> + (2, "scmi_smc_multiagent") > >> ], init_val = "LIBXL_ARM_SCI_TYPE_NONE") > >> > >> libxl_arm_sci = Struct("arm_sci", [ > >> ("type", libxl_arm_sci_type), > >> + ("agent_id", uint8) > >> ]) > >> > >> libxl_rdm_reserve = Struct("rdm_reserve", [ > >> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c > >> index 1cc41f1bff..0c389d25f9 100644 > >> --- a/tools/xl/xl_parse.c > >> +++ b/tools/xl/xl_parse.c > >> @@ -1306,6 +1306,18 @@ static int parse_arm_sci_config(XLU_Config *cfg, libxl_arm_sci *arm_sci, > >> } > >> } > >> > >> + if (MATCH_OPTION("agent_id", ptr, oparg)) { > >> + unsigned long val = parse_ulong(oparg); > >> + > >> + if (!val || val > 255) { > >> + fprintf(stderr, "An invalid ARM_SCI agent_id specified (%lu). Valid range [1..255]\n", > >> + val); > >> + ret = ERROR_INVAL; > >> + goto out; > >> + } > >> + arm_sci->agent_id = val; > >> + } > >> + > >> ptr = strtok(NULL, ","); > >> } > >> > >> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c > >> index 4181c10538..ddadc89148 100644 > >> --- a/xen/arch/arm/dom0less-build.c > >> +++ b/xen/arch/arm/dom0less-build.c > >> @@ -299,6 +299,17 @@ static int __init domu_dt_sci_parse(struct dt_device_node *node, > >> d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_NONE; > >> else if ( !strcmp(sci_type, "scmi_smc") ) > >> d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; > >> + else if ( !strcmp(sci_type, "scmi_smc_multiagent") ) > >> + { > >> + uint32_t agent_id = 0; > >> + > >> + if ( !dt_property_read_u32(node, "xen,sci-agent-id", &agent_id) || > >> + agent_id > UINT8_MAX ) > >> + return -EINVAL; > >> + > >> + d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA; > >> + d_cfg->arch.arm_sci_agent_id = agent_id; > >> + } > >> else > >> { > >> printk(XENLOG_ERR "xen,sci_type in not valid (%s) for domain %s\n", > >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > >> index 986a456f17..0796561306 100644 > >> --- a/xen/arch/arm/domain_build.c > >> +++ b/xen/arch/arm/domain_build.c > >> @@ -86,6 +86,37 @@ int __init parse_arch_dom0_param(const char *s, const char *e) > >> return -EINVAL; > >> } > >> > >> +/* SCMI agent ID for dom0 obtained from xen,sci container */ > >> +#define SCMI_AGENT_ID_INVALID UINT8_MAX > >> + > >> +static uint8_t __init get_dom0_scmi_agent_id(void) > >> +{ > >> + const struct dt_device_node *config_node; > >> + u32 val; > >> + const struct dt_property *prop; > >> + > >> + config_node = dt_find_compatible_node(NULL, NULL, "xen,sci"); > >> + if ( !config_node ) > >> + return SCMI_AGENT_ID_INVALID; > >> + > >> + prop = dt_find_property(config_node, "xen,dom0-sci-agent-id", NULL); > >> + if ( !prop ) > >> + return SCMI_AGENT_ID_INVALID; > >> + > >> + if ( !dt_property_read_u32(config_node, "xen,dom0-sci-agent-id", &val) ) > >> + return SCMI_AGENT_ID_INVALID; > >> + > >> + if ( val >= SCMI_AGENT_ID_INVALID ) > >> + { > >> + printk(XENLOG_WARNING > >> + "Invalid xen,dom0-sci-agent-id=%u, SCMI disabled for Dom0\n", > >> + val); > >> + return SCMI_AGENT_ID_INVALID; > >> + } > >> + > >> + return val; > >> +} > >> + > >> /* Override macros from asm/page.h to make them work with mfn_t */ > >> #undef virt_to_mfn > >> #define virt_to_mfn(va) _mfn(__virt_to_mfn(va)) > >> @@ -509,7 +540,7 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo, > >> dt_property_name_is_equal(prop, "linux,uefi-mmap-start") || > >> dt_property_name_is_equal(prop, "linux,uefi-mmap-size") || > >> dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-size") || > >> - dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-ver")) > >> + dt_property_name_is_equal(prop, "linux,uefi-mmap-desc-ver") ) > >> continue; > > Spurious change > > > > > >> +static int scmi_dt_assign_device(struct domain *d, > >> + struct dt_phandle_args *ac_spec) > >> +{ > >> + struct scmi_channel *agent_channel; > >> + uint32_t scmi_device_id = ac_spec->args[0]; > >> + int ret; > >> + > >> + if ( !d->arch.sci_data ) > >> + return 0; > >> + > >> + /* The access-controllers is specified for DT dev, but it's not a SCMI */ > >> + if ( ac_spec->np != scmi_data.dt_dev ) > >> + return 0; > > This comparison can erroneously fail when the pointers point to > > different copies of the same data > > > > > >> + agent_channel = d->arch.sci_data; > >> + > >> + spin_lock(&agent_channel->lock); > >> + > >> + ret = scmi_assign_device(agent_channel->agent_id, scmi_device_id, > >> + SCMI_BASE_DEVICE_ACCESS_ALLOW); > >> + if ( ret ) > >> + { > >> + printk(XENLOG_ERR > >> + "scmi: could not assign dev for %pd agent:%d dev_id:%u (%d)", > >> + d, agent_channel->agent_id, scmi_device_id, ret); > >> + } > >> + > >> + spin_unlock(&agent_channel->lock); > >> + return ret; > >> +} > >> + > >> +static int collect_agent_id(struct scmi_channel *agent_channel) > >> +{ > >> + int ret; > >> + scmi_msg_header_t hdr; > >> + struct scmi_msg_base_discover_agent_p2a da_rx; > >> + struct scmi_msg_base_discover_agent_a2p da_tx; > >> + > >> + ret = map_channel_memory(agent_channel); > >> + if ( ret ) > >> + return ret; > >> + > >> + hdr.id = SCMI_BASE_DISCOVER_AGENT; > >> + hdr.type = 0; > >> + hdr.protocol = SCMI_BASE_PROTOCOL; > >> + > >> + da_tx.agent_id = agent_channel->agent_id; > >> + > >> + ret = do_smc_xfer(agent_channel, &hdr, &da_tx, sizeof(da_tx), &da_rx, > >> + sizeof(da_rx)); > >> + if ( agent_channel->domain_id != DOMID_XEN ) > >> + unmap_channel_memory(agent_channel); > >> + if ( ret ) > >> + return ret; > >> + > >> + printk(XENLOG_DEBUG "id=0x%x name=%s\n", da_rx.agent_id, da_rx.name); > >> + agent_channel->agent_id = da_rx.agent_id; > >> + return 0; > >> +} > >> + > >> +static __init int collect_agents(struct dt_device_node *scmi_node) > >> +{ > >> + const struct dt_device_node *config_node; > >> + const __be32 *prop; > >> + uint32_t len; > >> + const __be32 *end; > >> + uint32_t cells_per_entry = 3; /* Default to 3 cells if property is absent. */ > >> + > >> + config_node = dt_find_compatible_node(NULL, NULL, "xen,sci"); > >> + if ( !config_node ) > >> + { > >> + printk(XENLOG_WARNING "scmi: xen,sci node not found, no agents to collect.\n"); > >> + return -ENOENT; > >> + } > >> + > >> + /* Check for the optional '#scmi-secondary-agents-cells' property. */ > >> + if ( dt_property_read_u32(config_node, "#scmi-secondary-agents-cells", > >> + &cells_per_entry) ) > >> + { > >> + if ( cells_per_entry != 2 && cells_per_entry != 3 ) > >> + { > >> + printk(XENLOG_ERR "scmi: Invalid #scmi-secondary-agents-cells value: %u\n", > >> + cells_per_entry); > >> + return -EINVAL; > >> + } > >> + } > >> + > >> + prop = dt_get_property(config_node, SCMI_SECONDARY_AGENTS, &len); > >> + if ( !prop ) > >> + { > >> + printk(XENLOG_ERR "scmi: No %s property found, no agents to collect.\n", > >> + SCMI_SECONDARY_AGENTS); > >> + return -EINVAL; > >> + } > >> + > >> + /* Validate that the property length is a multiple of the cell size. */ > >> + if ( len == 0 || len % (cells_per_entry * sizeof(uint32_t)) != 0 ) > >> + { > >> + printk(XENLOG_ERR "scmi: Invalid length of %s property: %u for %u cells per entry\n", > >> + SCMI_SECONDARY_AGENTS, len, cells_per_entry); > >> + return -EINVAL; > >> + } > >> + > >> + end = (const __be32 *)((const u8 *)prop + len); > >> + > >> + for ( ; prop < end; ) > >> + { > >> + uint32_t agent_id; > >> + uint32_t smc_id; > >> + uint32_t shmem_phandle; > >> + struct dt_device_node *node; > >> + u64 addr, size; > >> + int ret; > >> + struct scmi_channel *agent_channel; > >> + > >> + smc_id = be32_to_cpu(*prop++); > >> + shmem_phandle = be32_to_cpu(*prop++); > >> + > >> + if ( cells_per_entry == 3 ) > >> + agent_id = be32_to_cpu(*prop++); > >> + else > >> + agent_id = SCMI_BASE_AGENT_ID_OWN; > >> + > >> + node = dt_find_node_by_phandle(shmem_phandle); > >> + if ( !node ) > >> + { > >> + printk(XENLOG_ERR "scmi: Could not find shmem node for agent %u\n", > >> + agent_id); > >> + return -EINVAL; > >> + } > >> + > >> + ret = dt_device_get_address(node, 0, &addr, &size); > >> + if ( ret ) > >> + { > >> + printk(XENLOG_ERR > >> + "scmi: Could not read shmem address for agent %u: %d\n", > >> + agent_id, ret); > >> + return ret; > >> + } > >> + > >> + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) ) > >> + { > >> + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); > >> + return -EINVAL; > >> + } > >> + > >> + agent_channel = smc_create_channel(agent_id, smc_id, addr); > >> + if ( IS_ERR(agent_channel) ) > >> + { > >> + printk(XENLOG_ERR "scmi: Could not create channel for agent %u: %ld\n", > >> + agent_id, PTR_ERR(agent_channel)); > >> + return PTR_ERR(agent_channel); > >> + } > >> + > >> + if ( cells_per_entry == 2 ) > >> + { > >> + ret = collect_agent_id(agent_channel); > >> + if ( ret ) > >> + return ret; > >> + } > >> + > >> + printk(XENLOG_DEBUG "scmi: Agent %u SMC %X addr %lx\n", agent_channel->agent_id, > >> + smc_id, (unsigned long)addr); > >> + } > >> + > >> + return 0; > >> +} > >> + > >> +static int scmi_domain_init(struct domain *d, > >> + struct xen_domctl_createdomain *config) > >> +{ > >> + struct scmi_channel *channel; > >> + int ret; > >> + > >> + if ( !scmi_data.initialized ) > >> + return 0; > >> + > >> + /* > >> + * SCMI support is configured via: > >> + * - For dom0: xen,dom0-sci-agent-id property under the xen,sci container > >> + * - For dom0less: xen,sci-agent-id in the domain node > >> + * The config->arch.arm_sci_type and config->arch.arm_sci_agent_id > >> + * are already set by domain_build.c or dom0less-build.c > >> + */ > >> + > >> + if ( config->arch.arm_sci_type == XEN_DOMCTL_CONFIG_ARM_SCI_NONE ) > >> + return 0; > >> + > >> + channel = acquire_scmi_channel(d, config->arch.arm_sci_agent_id); > >> + if ( IS_ERR(channel) ) > >> + { > >> + printk(XENLOG_ERR > >> + "scmi: Failed to acquire SCMI channel for agent_id %u: %ld\n", > >> + config->arch.arm_sci_agent_id, PTR_ERR(channel)); > >> + return PTR_ERR(channel); > >> + } > >> + > >> + printk(XENLOG_INFO > >> + "scmi: Acquire channel id = 0x%x, domain_id = %d paddr = 0x%lx\n", > >> + channel->agent_id, channel->domain_id, channel->paddr); > >> + > >> + /* > >> + * Dom0 (if present) needs to have an access to the guest memory range > >> + * to satisfy iomem_access_permitted() check in XEN_DOMCTL_iomem_permission > >> + * domctl. > >> + */ > >> + if ( hardware_domain && !is_hardware_domain(d) ) > >> + { > >> + ret = iomem_permit_access(hardware_domain, paddr_to_pfn(channel->paddr), > >> + paddr_to_pfn(channel->paddr + PAGE_SIZE - 1)); > >> + if ( ret ) > >> + goto error; > >> + } > >> + > >> + d->arch.sci_data = channel; > >> + d->arch.sci_enabled = true; > >> + > >> + return 0; > >> + > >> +error: > >> + relinquish_scmi_channel(channel); > >> + return ret; > >> +} > >> + > >> +int scmi_domain_sanitise_config(struct xen_domctl_createdomain *config) > >> +{ > >> + if ( config->arch.arm_sci_type != XEN_DOMCTL_CONFIG_ARM_SCI_NONE && > >> + config->arch.arm_sci_type != XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA ) > >> + { > >> + dprintk(XENLOG_INFO, "scmi: Unsupported ARM_SCI type\n"); > >> + return -EINVAL; > >> + } > >> + > >> + return 0; > >> +} > >> + > >> +static int scmi_relinquish_resources(struct domain *d) > >> +{ > >> + int ret; > >> + struct scmi_channel *channel, *agent_channel; > >> + scmi_msg_header_t hdr; > >> + struct scmi_msg_base_reset_agent_cfg_a2p tx; > >> + > >> + if ( !d->arch.sci_data ) > >> + return 0; > >> + > >> + agent_channel = d->arch.sci_data; > >> + > >> + spin_lock(&agent_channel->lock); > >> + tx.agent_id = agent_channel->agent_id; > >> + spin_unlock(&agent_channel->lock); > >> + > >> + channel = get_channel_by_id(scmi_data.hyp_channel_agent_id); > >> + if ( !channel ) > >> + { > >> + printk(XENLOG_ERR > >> + "scmi: Unable to get Hypervisor scmi channel for domain %d\n", > >> + d->domain_id); > >> + return -EINVAL; > >> + } > >> + > >> + hdr.id = SCMI_BASE_RESET_AGENT_CONFIGURATION; > >> + hdr.type = 0; > >> + hdr.protocol = SCMI_BASE_PROTOCOL; > >> + > >> + tx.flags = 0; > > is this correct? > > > > > >> + ret = do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0); > >> + if ( ret == -EOPNOTSUPP ) > >> + return 0; > >> + > >> + return ret; > >> +} > >> + > >> +static void scmi_domain_destroy(struct domain *d) > >> +{ > >> + struct scmi_channel *channel; > >> + > >> + if ( !d->arch.sci_data ) > >> + return; > >> + > >> + channel = d->arch.sci_data; > >> + spin_lock(&channel->lock); > >> + > >> + relinquish_scmi_channel(channel); > >> + printk(XENLOG_DEBUG "scmi: Free domain %d\n", d->domain_id); > >> + > >> + d->arch.sci_data = NULL; > >> + d->arch.sci_enabled = false; > >> + > >> + spin_unlock(&channel->lock); > >> +} > >> + > >> +static bool scmi_handle_call(struct cpu_user_regs *regs) > >> +{ > >> + uint32_t fid = (uint32_t)get_user_reg(regs, 0); > >> + struct scmi_channel *agent_channel; > >> + struct domain *d = current->domain; > >> + struct arm_smccc_res resp; > >> + bool res = false; > >> + > >> + if ( !sci_domain_is_enabled(d) ) > >> + return false; > >> + > >> + agent_channel = d->arch.sci_data; > >> + spin_lock(&agent_channel->lock); > >> + > >> + if ( agent_channel->func_id != fid ) > >> + { > >> + res = false; > >> + goto unlock; > >> + } > >> + > >> + arm_smccc_1_1_smc(fid, > >> + get_user_reg(regs, 1), > >> + get_user_reg(regs, 2), > >> + get_user_reg(regs, 3), > >> + get_user_reg(regs, 4), > >> + get_user_reg(regs, 5), > >> + get_user_reg(regs, 6), > >> + get_user_reg(regs, 7), > >> + &resp); > >> + > >> + set_user_reg(regs, 0, resp.a0); > >> + set_user_reg(regs, 1, resp.a1); > >> + set_user_reg(regs, 2, resp.a2); > >> + set_user_reg(regs, 3, resp.a3); > >> + res = true; > >> +unlock: > >> + spin_unlock(&agent_channel->lock); > >> + > >> + return res; > >> +} > >> + > >> +static const struct sci_mediator_ops scmi_ops = { > >> + .domain_init = scmi_domain_init, > >> + .domain_destroy = scmi_domain_destroy, > >> + .relinquish_resources = scmi_relinquish_resources, > >> + .handle_call = scmi_handle_call, > >> + .dom0_dt_handle_node = scmi_dt_handle_node, > >> + .domain_sanitise_config = scmi_domain_sanitise_config, > >> + .assign_dt_device = scmi_dt_assign_device, > >> +}; > >> + > >> +static int __init scmi_check_smccc_ver(void) > >> +{ > >> + if ( smccc_ver < ARM_SMCCC_VERSION_1_1 ) > >> + { > >> + printk(XENLOG_WARNING > >> + "scmi: No SMCCC 1.1 support, SCMI calls forwarding disabled\n"); > >> + return -ENOSYS; > >> + } > >> + > >> + return 0; > >> +} > >> + > >> +static int __init scmi_dt_hyp_channel_read(struct dt_device_node *scmi_node, > >> + struct scmi_data *scmi_data, > >> + u64 *addr) > >> +{ > >> + int ret; > >> + u64 size; > >> + > >> + if ( !dt_property_read_u32(scmi_node, "arm,smc-id", &scmi_data->func_id) ) > >> + { > >> + printk(XENLOG_ERR "scmi: unable to read smc-id from DT\n"); > >> + return -ENOENT; > >> + } > >> + > >> + ret = scmi_dt_read_hyp_channel_addr(scmi_node, addr, &size); > >> + if ( IS_ERR_VALUE(ret) ) > >> + return -ENOENT; > >> + > >> + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) ) > >> + { > >> + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); > >> + return -EINVAL; > >> + } > >> + > >> + return 0; > >> +} > >> + > >> +static __init int scmi_probe(struct dt_device_node *scmi_node, const void *data) > >> +{ > >> + u64 addr; > >> + int ret; > >> + struct scmi_channel *channel; > >> + unsigned int n_agents; > >> + scmi_msg_header_t hdr; > >> + struct scmi_msg_base_attributes_p2a rx; > >> + > >> + ASSERT(scmi_node != NULL); > >> + > >> + /* > >> + * Only bind to the SCMI node provided by Xen under the xen,sci container > >> + * (e.g. /chosen/xen/xen_scmi_config/scmi). This avoids binding to firmware > >> + * SCMI nodes that belong to the host OSPM and keeps the mediator scoped to > >> + * Xen-provided configuration only. > >> + */ > >> + if ( !scmi_is_under_xen_sci(scmi_node) ) > >> + return -ENODEV; > >> + > >> + INIT_LIST_HEAD(&scmi_data.channel_list); > >> + spin_lock_init(&scmi_data.channel_list_lock); > >> + > >> + if ( !acpi_disabled ) > >> + { > >> + printk(XENLOG_WARNING "scmi: is not supported when using ACPI\n"); > >> + return -EINVAL; > >> + } > >> + > >> + ret = scmi_check_smccc_ver(); > >> + if ( ret ) > >> + return ret; > >> + > >> + ret = scmi_dt_hyp_channel_read(scmi_node, &scmi_data, &addr); > >> + if ( ret ) > >> + return ret; > >> + > >> + scmi_data.dt_dev = scmi_node; > >> + > >> + channel = smc_create_channel(SCMI_BASE_AGENT_ID_OWN, scmi_data.func_id, addr); > >> + if ( IS_ERR(channel) ) > >> + goto out; > >> + > >> + /* Mark as Xen management channel before collecting agent ID */ > >> + channel->domain_id = DOMID_XEN; > >> + > >> + /* Request agent id for Xen management channel */ > >> + ret = collect_agent_id(channel); > >> + if ( ret ) > >> + goto error; > >> + > >> + /* Save the agent id for Xen management channel */ > >> + scmi_data.hyp_channel_agent_id = channel->agent_id; > >> + > >> + hdr.id = SCMI_BASE_PROTOCOL_ATTIBUTES; > >> + hdr.type = 0; > >> + hdr.protocol = SCMI_BASE_PROTOCOL; > >> + > >> + ret = do_smc_xfer(channel, &hdr, NULL, 0, &rx, sizeof(rx)); > >> + if ( ret ) > >> + goto error; > >> + > >> + n_agents = SCMI_FIELD_GET(SCMI_BASE_ATTR_NUM_AGENT, rx.attributes); > >> + printk(XENLOG_DEBUG "scmi: Got agent count %d\n", n_agents); > >> + ret = collect_agents(scmi_node); > >> + if ( ret ) > >> + goto error; > >> + > >> + ret = sci_register(&scmi_ops); > >> + if ( ret ) > >> + { > >> + printk(XENLOG_ERR "SCMI: mediator already registered (ret = %d)\n", > >> + ret); > >> + return ret; > >> + } > >> + > >> + scmi_data.initialized = true; > >> + goto out; > >> + > >> +error: > >> + unmap_channel_memory(channel); > > This might cause the ASSERT at the beginning of unmap_channel_memory to > > trigger > > > > > Great finding... First `goto error` could be called after > `collect_agent_id`. > So in case if we receive -ENOMEM from `ioremap_nocache` inside > `map_channel_memory` > ASSERT will fire. > > I'm planning to refactor this as follows: > >     static void unmap_channel_memory(struct scmi_channel *channel) >     { >         ASSERT(channel); > >         if ( !channel->shmem ) >             return; >         ... >      } > > This will cause function to skip iounmap if shmem is NULL; > What do you think? Yes that's better --8323329-301432995-1769456964=:7192-- From xen-devel-bounces@lists.xenproject.org Mon Jan 26 20:53:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 20:53:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214026.1524453 (Exim 4.92) (envelope-from ) id 1vkTa6-0002xx-QB; Mon, 26 Jan 2026 20:53:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214026.1524453; Mon, 26 Jan 2026 20: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 1vkTa6-0002xq-NL; Mon, 26 Jan 2026 20:53:06 +0000 Received: by outflank-mailman (input) for mailman id 1214026; Mon, 26 Jan 2026 20: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 1vkTa5-0002xU-GZ for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 20:53:05 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 00f65e0e-faf9-11f0-b15f-2bf370ae4941; Mon, 26 Jan 2026 21:53:02 +0100 (CET) Received: from MN2PR01CA0041.prod.exchangelabs.com (2603:10b6:208:23f::10) by PH0PR12MB7472.namprd12.prod.outlook.com (2603:10b6:510:1e9::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.14; Mon, 26 Jan 2026 20:52:57 +0000 Received: from BN3PEPF0000B06F.namprd21.prod.outlook.com (2603:10b6:208:23f:cafe::23) by MN2PR01CA0041.outlook.office365.com (2603:10b6:208:23f::10) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.15 via Frontend Transport; Mon, 26 Jan 2026 20:54:21 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN3PEPF0000B06F.mail.protection.outlook.com (10.167.243.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9587.0 via Frontend Transport; Mon, 26 Jan 2026 20:52:56 +0000 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.2562.17; Mon, 26 Jan 2026 14:52:56 -0600 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, 26 Jan 2026 14:52:56 -0600 Received: from [172.23.49.162] (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, 26 Jan 2026 12:52:55 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 00f65e0e-faf9-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DHtJ5x+LImKxqnnfw4NEozBRklfHhaevgrdAS7NLiSSHlSJLddMXqQVhVJEWoqFBPkRdXBbSsytGsCzwV6ye7e/lpFW7bWX4RbjMOpGxqD3Rf9odd1b2VzAztdz7MvwS7cEKupvj2M/MX8e9NfoYTuxLXALnJd0RiFKnSa5lI5sGGAhvlyGkiaf7XtD3zt8+3Fz7eqsoeVoE2/WgdA6snHu1yQx/3eOKJ7+Oq/RRZ8LNyjxvDXVNPYA1/4IAveWU9BnfrWdoEFTo6WQOXKVdPJBwO/9DphM4ajVtY+RGYBsJQz2M5VmtPRY8DuZwsJGdFc2pa7rK73sFIoWUPK3aPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7SGNS4TjEI76EVNKrBmF4O5g2Si1KJyHIqW2yyloj+A=; b=H7vKkhb15Va6k9Wnru6XPqM1LiRRyOAPn0mZ1+oAYF4fCm89vRsWR69qarI0Or0iRkEGfqVWxJTZaPzROF4s84iO1zsfGXfjBLc1f0QOPqtN4h+GEJtjbvdxYz2N3Gnp2SJep/o3ssSeC0gUT5wICZ7v6W+utxyg/Aw/7wzLfkbkWpgQ4p2C1n/0DOFiVrlHMviLhGcMXXbmasjHnnai8OCcvxOzYnMKnK8uOP6zzTiuUT50udlgSm2zRdNWlYBu9BA09cx0Q36hbzN8Kvu39bPzyKTGbntcqotlfqPiHUpyQPLOm9FstvgKyUFWFntoHDjE1uPmiOYe6IZ2SeJW9g== 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=7SGNS4TjEI76EVNKrBmF4O5g2Si1KJyHIqW2yyloj+A=; b=Yfq9GKK+90tvnbPUknUHekMAaGwltoPq4gZzGxDWXGIsZiaILoSBrth2vA8g9AFnyKyF5rffysPdNqyLShgnNZuGxXNcK7dBZ1pJlGPKWUJGChiQEx8e1aB4TPKvI+pzSv422uw8DPQDo7KaD0owjfbL2aHJhIS3aAMsopEP93I= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <3b9a40d3-ecd8-44cf-a310-620ed55abc68@amd.com> Date: Mon, 26 Jan 2026 15:17:33 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/5] cpufreq/hwp: move driver data into policy To: Jan Beulich CC: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" References: <8441ada5-e2ed-4d79-822c-ecf1ce3c9484@suse.com> <26ef0e68-efca-4b9a-a210-76b5426da130@amd.com> <8bad1a32-d59c-4dba-8c35-b28fcb16f39c@suse.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <8bad1a32-d59c-4dba-8c35-b28fcb16f39c@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: BN3PEPF0000B06F:EE_|PH0PR12MB7472:EE_ X-MS-Office365-Filtering-Correlation-Id: 3f2900dd-3284-433f-a76d-08de5d1ce249 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?bG9RQ25BeEh2MG5HU1FlbzhTejdvdE4yMytoTU9EMVk1ZTJLblVlRCtJNmw1?= =?utf-8?B?RjNxcTZmeFFMUE1pRno1YXZFNzBhODM0R0NXRS9ZTlVnYW54dVF1NFVpSkE1?= =?utf-8?B?SlBrN0p3c0tnTDhLcTJJdkhmRmgxZGpCQ2NtOE8vVDF6blNUNE5IYzVwQVVl?= =?utf-8?B?QWx0eVNocitKRTJwY1JsZk9FZzRQSDJrOHNZenV1bGNYZjdCK00xaHFtNXhN?= =?utf-8?B?S2xTS05NeUdFbGk2dVlqZDYyb0xxUGlRQ1NudG1lNzN0WGpQa0RTVjZ2TXZ0?= =?utf-8?B?UWkrNU9IWjZleVVYM1JZQjQwV2NjVFpNMENoeHg2WjZMc0hqVGpvc2hJSmFk?= =?utf-8?B?UG54OEFiZ1NGRFFKTkE0Yk9xVG5iem1ZOGJsWUZUbExhUXpxNTBwQmp4NEth?= =?utf-8?B?QXBSdDlOSEVaMm9SVDVnOGRVSENlcm1aRnRTdlQwb2w1Zjh1dVkwRDkxSXZu?= =?utf-8?B?RC9qMHpqY20xZkJScXN1a1FNeWJDdk85K0hrNUpHZFJ2S2w0dTZHMGI0UzFZ?= =?utf-8?B?c3FQQ1pPc0lISEJkbTlZcWsxdUhIZFlKN2JxbWRoY0JnUjk2OHd5Q1ErVTRa?= =?utf-8?B?cDN0UHJKUklxeUFLRW1TcFBHYXQybEdPNU5RSVNEMjB4aDY2SlhpQklWVnhu?= =?utf-8?B?RFE1bFhybVg3TFNHZGI5b0tGaUhCSlorbWRxSXM1WWVNOWxXcUxxNFM1SDVP?= =?utf-8?B?bE5TOGFsaXJGc1RUaUswRTkxcUJzWlV0NG1BdWs4SEF4ZWZWWTlxUjltT081?= =?utf-8?B?N3FRQXVSTUQ5ZEQxaHpCdDdKcE5KV2I3c0JsZFh2Q1dCYnNpTTRQOEI3aFNV?= =?utf-8?B?cXZUZWprTlFDT0xIZDFLeFNxZFBwYk1US1FWc091Rk9CcUNjUE1icHBzNFds?= =?utf-8?B?Mk1hNEVRdWFLNEErTFJtS0xCV0dTUXFuOURhNTZGWWp1VTFUS1d4d0N1bzVE?= =?utf-8?B?clY3QkY2bk5EcnJWSHE1VlNNbWcxSnYwOHR3UnptZnBOQ2srNXhNZ1YrU295?= =?utf-8?B?STJwbHVCdWFVZENkOWc0SHZNcnB3aTFsdlZJQ2RjVmlCK1RqOUsrUDNEYkVh?= =?utf-8?B?cVVvMnpTMXp6SEdxK2xqRnBjbGMybm9sbE9HR0lJMHY1RXQzVXFYNHlvNUtW?= =?utf-8?B?Wm85RTAwVzNGbmljaEpXRFdQUmRadktIMklVckd1R01odXBZRnVEU21wU0Fj?= =?utf-8?B?Q3R0WnpkZWppVnJUOE9Kd3N4TmVCWEd2bTdIc2x4bWdNYndYUlEzS3pZdWVj?= =?utf-8?B?OWR4QlRPcTl2VjJhcStUNWlkVDlQajZub21YZEFHL3dMemlEdko2dCs1VVpZ?= =?utf-8?B?eklCSTQ2bVl3d1dEclpOd0ZWeXBTUDlnZUZrOEg5aTk0N2F6d01HclhzeGVN?= =?utf-8?B?WGltMXE2a1FyVHJmRzJKcXU4bG56SStteXpod2h5Ykd5U01ZeWtFQ0hyeEhG?= =?utf-8?B?d0NaNUR4VDRXR2hwUyt1MmZWWGJiSWttRW9UQXlJY0pTSkE1S25raGlLS2RP?= =?utf-8?B?akh4azZEZXVEU014QnZTNzQydmg4RzV0Q1ZJS0dmWDRIRjRwaDZpNXM0SERX?= =?utf-8?B?R0NaYWFORmNjUWwrQitmbVlGbWpkZldhc0Q3OTh1eUxRdno1VDJwak9OdVRF?= =?utf-8?B?WGlieUZZc1cyWERuVTZZQ0ZoVldnYWh4MldHQUxkYWgza0ZwK2tRSFR5ZGJh?= =?utf-8?B?azhDelpOV0x0RExoU1NVdkRsTW9TUWJTT0FRZ2p5SFRlcHVNeng3ZHVKd0l1?= =?utf-8?B?djFkMDR4MnplUGhPNWRXZEpsYytJSlRPamZKTlZ0bDFtYUF2RTM5T1o2MExn?= =?utf-8?B?R1R6Tnc1T3NTc1ZvbXVFUFdRaTVVV0twejFiZ1lOSFE2SzBBNnFNWWhRWXhF?= =?utf-8?B?TnRpaFZtMkY5QnBDcDMrL3ZWWER2ZU1mbVFXV1JNT3o0UzZpRXJNTDkrSUFq?= =?utf-8?B?aTRJRktBei9VbDFMV1MwSUNpeWwyYWw0UTFJbm5lZHA5SVRKaXN3S1BlcldW?= =?utf-8?B?T2hQbzBpeXJCQSt0cEw0UTMzbW5ydldheWdGRlk5OU1xSkp5ZlAxYjZPMFFJ?= =?utf-8?B?UVBoaTl2aFdBMGN3K0ROYnhOc0pQU1BaTzdVaXBRU3NPbGFRMzNnNHpGOXpi?= =?utf-8?B?S1BMamdsQk81dWFIOURkQVRUcytlcUFBNnlYYld2WDhnMGpRZFpmNGpsamVo?= =?utf-8?Q?J4zwwEjnGpIfA0NC9JFt5j3Oxak7GX1di9Zg4LhSjJNM?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(36860700013)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2026 20:52:56.9712 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3f2900dd-3284-433f-a76d-08de5d1ce249 X-MS-Exchange-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: BN3PEPF0000B06F.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7472 On 2026-01-26 04:08, Jan Beulich wrote: > On 23.01.2026 23:35, Jason Andryuk wrote: >> On 2026-01-22 04:42, Jan Beulich wrote: >>> Share space with the ACPI and powernow drivers, avoiding a separate >>> allocation for each CPU. Except for get_hwp_para() all use sites already >>> have the policy available, and this one function can simply be brought >>> closer to its sibling set_hwp_para(). >> >> Minor, but maybe 's/function/function's signature/'. The original >> phrasing made me think it was code movement. > > I don't see an issue there, but I've adjusted as you asked for. Thank you. >>> This then also eliminates the concern over hwp_cpufreq_cpu_init() being >>> called for all CPUs >> >> We expect hwp_cpufreq_cpu_init() to be called for each CPU, so I am >> confused by this statement. The data... > > Well, "expect" is the problem. Recall my pointing out of the problem when > having noticed the same pattern in the amd-cppc driver patches. My > recollection from the discussion is that there's no formal statement of > ... > >> >, or a CPU going offline that's recorded in> policy->cpu (which would >> result in accesses of per-CPU data of offline >>> CPUs). >>> >>> Signed-off-by: Jan Beulich >>> --- >>> hwp_cpufreq_target() still requires policy->cpu to be online, though. >>> >>> --- a/xen/arch/x86/acpi/cpufreq/hwp.c >>> +++ b/xen/arch/x86/acpi/cpufreq/hwp.c >> >>> -static DEFINE_PER_CPU_READ_MOSTLY(struct hwp_drv_data *, hwp_drv_data); >> >> ... here is tracked and filled per-CPU. >> >> Do we need cpufreq_add_cpu() to force hw_all = 1 for HWP (and maybe >> AMD-CPPC) to ensure that policy is allocated per-CPU? > > ... this being a correct thing to do, hence our code imo would better be > resilient to it being different somewhere. > >> Are we implicitly relying on shared_type == CPUFREQ_SHARED_TYPE_HW to do >> that for us? > > Right now we do, I believe, without - as said above - this being actually > mandated by the spec. HWP doesn't need ACPI data. I wrote the driver according to the SDM, which is just MSRs. It's Xen that needs ACPI data to initialize and use cpufreq. Regardless of that, it looks like the checks for cpu_online() and performance_pminfo[] would constrain CPU accesses, so: Reviewed-by: Jason Andryuk Thanks, Jason From xen-devel-bounces@lists.xenproject.org Mon Jan 26 22:09:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 26 Jan 2026 22:09:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214040.1524463 (Exim 4.92) (envelope-from ) id 1vkUlh-0002ug-SF; Mon, 26 Jan 2026 22:09:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214040.1524463; Mon, 26 Jan 2026 22:09:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkUlh-0002uZ-PV; Mon, 26 Jan 2026 22:09:09 +0000 Received: by outflank-mailman (input) for mailman id 1214040; Mon, 26 Jan 2026 22:09: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 1vkUlg-0002uT-PF for xen-devel@lists.xenproject.org; Mon, 26 Jan 2026 22:09: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 a09832de-fb03-11f0-9ccf-f158ae23cfc8; Mon, 26 Jan 2026 23:09:05 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id D6CEA60051; Mon, 26 Jan 2026 22:09:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 61D07C116C6; Mon, 26 Jan 2026 22:09: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: a09832de-fb03-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769465343; bh=M8eWJRSt8kxftDMfHh6ZPyDaoVE69N/C4MO0jYVgopM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=t4HsPeqDeyxLusfZPoBEb+vG4PzaNoTAJiqnOD37aSTSoGrshePsHrECZ7/x6pXNr i/X2IEXL6snUPT27NlyLbrcQ93twU0cIucZlvkJjE5EroOFsEpsm9qgVNEqhPNOyr1 +OBfM0Lz5WFtEZAdyq54uWmCLKyjU7aNb5qFEMcMI3pw4C3YJEAfd56TCFOSta8+SI wUAAPOgvoVgAWiSz/FFCHaG8IO4JoUzhjEHBEH4PxKVkzOkPj4/ZKyuFyHL/P6GZFo ozjb8PwY+K8vei1z0tQcPj6b1CsP7hesjnft/83USwIBfeN8YvH0N2y8Pb561N1FQX k4fgaTQzBsspw== Date: Mon, 26 Jan 2026 14:09:01 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Dominique Martinet cc: Stefano Stabellini , xen-devel@lists.xenproject.org, jgross@suse.com, v9fs@lists.linux.dev, Eric Van Hensbergen , Latchesar Ionkov , Christian Schoenebeck , sstabellini@kernel.org Subject: Re: [PATCH] 9p/xen: protect xen_9pfs_front_free against concurrent calls In-Reply-To: Message-ID: References: <20260123184009.1298536-1-stefano.stabellini@amd.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Sat, 24 Jan 2026, Dominique Martinet wrote: > Stefano Stabellini wrote on Fri, Jan 23, 2026 at 10:40:09AM -0800: > > The xenwatch thread can race with other back-end change notifications > > and call xen_9pfs_front_free() twice, hitting the observed general > > protection fault due to a double-free. Guard the teardown path so only > > one caller can release the front-end state at a time, preventing the > > crash. > > Thank you, just a couple of nitpicks below > > > diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c > > index 280f686f60fbb..8809f3c06ec95 100644 > > --- a/net/9p/trans_xen.c > > +++ b/net/9p/trans_xen.c > > @@ -274,11 +274,7 @@ static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv) > > { > > int i, j; > > > > - write_lock(&xen_9pfs_lock); > > - list_del(&priv->list); > > - write_unlock(&xen_9pfs_lock); > > - > > - for (i = 0; i < XEN_9PFS_NUM_RINGS; i++) { > > + for (i = 0; priv->rings != NULL && i < XEN_9PFS_NUM_RINGS; i++) { > > > I don't understand this priv->rings != NULL check here; > if it's guarding for front_free() called before front_init() then it > doesn't need to be checked at every iteration, and if it can change in > another thread I don't see why it would be safe. xen_9pfs_front_free() can be reached from the error paths before any rings are allocated, so we need to handle a NULL priv->rings but it doesn't have to be checked at every iteration. I can move it before the for loop as you suggested. > > > struct xen_9pfs_dataring *ring = &priv->rings[i]; > > > > cancel_work_sync(&ring->work); > > @@ -310,9 +306,18 @@ static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv) > > > > static void xen_9pfs_front_remove(struct xenbus_device *dev) > > { > > - struct xen_9pfs_front_priv *priv = dev_get_drvdata(&dev->dev); > > + struct xen_9pfs_front_priv *priv; > > > > + write_lock(&xen_9pfs_lock); > > + priv = dev_get_drvdata(&dev->dev); > > + if (priv == NULL) { > > + write_unlock(&xen_9pfs_lock); > > + return; > > + } > > dev_set_drvdata(&dev->dev, NULL); > > + list_del_init(&priv->list); > > There's nothing wrong with using the del_init() variant here, but it > would imply someone else could still access it after the unlock here, > which means to me they could still access it after priv is freed in > xen_9pfs_front_free(). > >From your commit message I think the priv == NULL check and > dev_set_drvdata() under lock above is enough, can you confirm? Yes you are right. I can replace list_del_init with list_del if you think it is clearer. > > + write_unlock(&xen_9pfs_lock); > > + > > xen_9pfs_front_free(priv); > > } > > > > @@ -387,7 +392,7 @@ static int xen_9pfs_front_init(struct xenbus_device *dev) > > { > > int ret, i; > > struct xenbus_transaction xbt; > > - struct xen_9pfs_front_priv *priv = dev_get_drvdata(&dev->dev); > > + struct xen_9pfs_front_priv *priv; > > char *versions, *v; > > unsigned int max_rings, max_ring_order, len = 0; > > > > @@ -415,6 +420,10 @@ static int xen_9pfs_front_init(struct xenbus_device *dev) > > if (p9_xen_trans.maxsize > XEN_FLEX_RING_SIZE(max_ring_order)) > > p9_xen_trans.maxsize = XEN_FLEX_RING_SIZE(max_ring_order) / 2; > > > > + priv = kzalloc(sizeof(*priv), GFP_KERNEL); > > + if (!priv) > > + return -ENOMEM; > > + priv->dev = dev; > > priv->rings = kcalloc(XEN_9PFS_NUM_RINGS, sizeof(*priv->rings), > > GFP_KERNEL); > > if (!priv->rings) { > > @@ -473,6 +482,11 @@ static int xen_9pfs_front_init(struct xenbus_device *dev) > > goto error; > > } > > > > + write_lock(&xen_9pfs_lock); > > + dev_set_drvdata(&dev->dev, priv); > > Honest question: could xen_9pfs_front_init() also be called multiple > times as well? > (if so this should check for the previous drvdata and free the priv > that was just built if it was non-null) > > Please ignore this if you think that can't happen, I really don't > know. That should not be possible before freeing priv first: xen_9pfs_front_init is only called when the frontend is in the XenbusStateInitialising state (see xen_9pfs_front_changed). Once we store priv we immediately switch the state to XenbusStateInitialised, and there will be no more calls to xen_9pfs_front_init. If the backend forces a re-probe, xenbus invokes xen_9pfs_front_remove first, which frees priv. From xen-devel-bounces@lists.xenproject.org Tue Jan 27 04:13:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 04:13:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214071.1524474 (Exim 4.92) (envelope-from ) id 1vkaSL-0001r9-V4; Tue, 27 Jan 2026 04:13:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214071.1524474; Tue, 27 Jan 2026 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 1vkaSL-0001qx-Po; Tue, 27 Jan 2026 04:13:33 +0000 Received: by outflank-mailman (input) for mailman id 1214071; Tue, 27 Jan 2026 04: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 1vkaSK-0001qp-E7 for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 04:13:32 +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 864654f6-fb36-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 05:13:26 +0100 (CET) Received: from DS7PR05CA0079.namprd05.prod.outlook.com (2603:10b6:8:57::9) by CH3PR12MB9395.namprd12.prod.outlook.com (2603:10b6:610:1ce::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Tue, 27 Jan 2026 04:13:20 +0000 Received: from DS1PEPF00017093.namprd03.prod.outlook.com (2603:10b6:8:57:cafe::7a) by DS7PR05CA0079.outlook.office365.com (2603:10b6:8:57::9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.7 via Frontend Transport; Tue, 27 Jan 2026 04:13:16 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by DS1PEPF00017093.mail.protection.outlook.com (10.167.17.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Tue, 27 Jan 2026 04:13:20 +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; Mon, 26 Jan 2026 22:13:20 -0600 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Mon, 26 Jan 2026 22:13:19 -0600 Received: from [172.29.134.248] (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, 26 Jan 2026 22:13:18 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 864654f6-fb36-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Nh/XBHWqd+2EYWkVRa7euWOGO7HOmWnMIeV1ry6EFin7JDGoqQpVz8MGG9dXL8up0RXMhpo96BHGOiQOUUzlRQ/rCVe6DCNU7RuAZDeXqSYmUQ9HPHMLY2dB5+FALZodSPacTMZ7Ayqmmv+VdVvpvDnKkA1XNtG+zrAtJ1mX/GyllJZJOJMU/idzA9G5jUmlGFmRK521W+DpkDkieKiU8RREpcFxIOE4PlXD20wUVnLuOtCM+PAX71ar9aOfpCXSUWvuCcYvNgC9gcuZXyN0Wgbj9zH5JrZHCW9vLVdNKl/5iM/+PcCXwSv/tvE5TQVu7dvRn1Gx1D0YDMI8W+7xlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7ov61H8GFM6LGnpAsfu0E9lm8ujvcYFn91F3JOCrMpQ=; b=s5ys4yJ/aYZMLygnPR3M1fCT+Av5vz/d2F0C6UcTt1/hS22qH/dMyzpLgbk6uW7x/sSw8ohitSl/CnfbvRLq9whyIixlMLSPW53LqDD64H9h3/qPPhuOyPp2Ohq/jVY1xOXglrFpiiXj1u+D7jJJ7fFjDTXnykgd+IwlDFVi2f9r89HSExzUI6P0Atd3TtbFby/fsAPfqtsFenD4My/PCfzRH4AtoyV1NBuSBS6tkP/yaYTEgd+B3THYJISPRnRQdEGdkUHDm1pGS6Lerdtxddm39jRp+jkswWNKMyXkFTtVqYsNznX2/AdwKKy9N1rYlUtLja2yUjNmVXor4M6bjw== 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=7ov61H8GFM6LGnpAsfu0E9lm8ujvcYFn91F3JOCrMpQ=; b=dBBdnTRRU47FwcGhtccaGEMkMCCA9u55q9HIjoSJAIrHkdjLhGQ5XKjlNpxyw1eLl9BQOiOrLwF/RONiFqo5czzfy9LcRZO0yDl4SIVrgcIFog7x776pAQTytHg+ew/CktFiVtIHsXqgug20piPCAim04jnhO+TXNuhV0TlSKEI= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 26 Jan 2026 23:13:17 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/4] PCI: determine whether a device has extended config space To: Jan Beulich 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: <58091dc1-7bda-4536-8200-2d0a5679d4d1@suse.com> <553d1a7a-e465-413f-a60f-32455bbce621@suse.com> Content-Language: en-US From: Stewart Hildebrand In-Reply-To: <553d1a7a-e465-413f-a60f-32455bbce621@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS1PEPF00017093:EE_|CH3PR12MB9395:EE_ X-MS-Office365-Filtering-Correlation-Id: 8c2b62bf-e0fd-4daf-0f4a-08de5d5a67eb 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?ajZMMDUxZjRXVDgxQXZsdi95dGVnTERuL0RyMngzenBEeFVPOVRjZlFuSXpj?= =?utf-8?B?YlIzYm9ZWEZoWUdNcVNMaGtraUJ6UjJsQXRwT3g5SlNKdVVQOGFtR2xlNUlX?= =?utf-8?B?NlMrb1dXR1c1VXNDajlsRjlucFFheGlWTDU0MFJZYTdWQXJORVlVeXpFSHV3?= =?utf-8?B?Z2N6MXdBUXlKNGtCWkk4YSt5N0hrS1l2bDM0cFgzU2xuSmRuTUgxaEdlU3Z3?= =?utf-8?B?TEpuMjBjRnRGbFR1Mk5wa25qVzdyNW82T1VFRDIxelNxVWxTbFF2eExZd0h1?= =?utf-8?B?V1h1Sk5rWmlFZFpBTmd0czRzU2pXU0dJVVVIV3VVS0JtZFJpWU9SQ0VQS1Uy?= =?utf-8?B?aDZoY1NIaTkwVms1eXBBd296NEVOVG93S013aHErZHMyZkc5TDhLR0dpWnFr?= =?utf-8?B?ZFdudU14MWxjWFFMaUdORGZxNnZzRHo3Vk5tR1c5NHU0N0w1WGM1TmQ2aTdE?= =?utf-8?B?Szk1c29WcG54TFBMUjdUdm5jVXNPc0FCR3Y0TmpPcGIxaGdNckxYWlZNUzdN?= =?utf-8?B?a3V1U2dqdCtXcDQ3WndvSlhYZStYbUl1bUJ5Z0FDSE1zTTJHN1ZTSjNZT2hw?= =?utf-8?B?RXJrMFZWc0Z5aU5ZSlB4aHhDMGpsaGNYRGMvRkVmRUh6QnBOeW5GY2lqNlJC?= =?utf-8?B?dHBTcy9ud0F1NlJkdzdSeUtDamRpY1Y0dlBTVlNtWWlQbkR2RjVFR2ZpT1VJ?= =?utf-8?B?TnFKUkxvYm9YUUF1TC94UkFmTFlDMHJEa201VU16djljNUNFRndwR0xzbnAx?= =?utf-8?B?WENLcThiSC9NanZIR1pNbTYyVWJCNDJ1ejJFN0pOTFFuMU13VW9DZFZXVlJi?= =?utf-8?B?RlQ5UmdsaU9xZlF4Q2hKcFRsdDhud3ZXaWppV1hoeURMTlpmeDZLUjlRU2Z6?= =?utf-8?B?MU83cjFTWTRnWkxYNWdCeUpmSEdhZkNVNi9BQWNRemJyNHpFclBHeU1URnZW?= =?utf-8?B?bUNvLzlZeDBhM3B4MGY1Y1dVcGIyQW92Z1ZoYnVRamdMelQwNEo2aldpa2xG?= =?utf-8?B?TlhUUlcyRTkwS0k4SGJsazZUNjFveUd3SDdkbzBPSVBGdWFZRFVwU2lJaGo1?= =?utf-8?B?NkNZU094Mys2eDNWbHEwc0VNU09zcFN1bVY5QmJzU09OMGoyLzNtWTZhZ0hS?= =?utf-8?B?ZlR2THVOREZJRlplOHdxWWxBZmRqNWtZZjZNdm5Tb0U3VEZqTFRMZGxQV0VK?= =?utf-8?B?dlJQNmNlNmRyb1ZkR0RBVU9XS2ZLZjBhdEgwVkhMT2xxNFJjM25NNndzajRM?= =?utf-8?B?TGNCY0ttZ2xmN25CS2d4OEozME1PZ3NXbTY1RVhlc01MdThrZzlVR09CMzBI?= =?utf-8?B?UTgrQU5SKzNsNDFkalpuQk5FR3NaMXdzY0Uvbk5ZQkVFZk1qMkJMODFxSUJI?= =?utf-8?B?NjZMS25KdkFPK3d1WWdPWDAzTzRiRkU0cm90OG1uVzVvaktrMklOQVdGL1dE?= =?utf-8?B?VjlrNXVFTzhLaDBzRForUXNDdVNGOFBtRTkxRm1WYmJEQ01iQWRNNlpUMWg3?= =?utf-8?B?SzFmTnRpK25QaEkxUjJTVTA1ZDRaWWRTMkVKekkzYWwrakpYVGE4czFGV21J?= =?utf-8?B?WUtTVFlaajNMb204QnEwYkh2SmoyMUxoWDY1dEhRMHlUaEFuZ01sK2t3a2Zt?= =?utf-8?B?QXc4OTVNY1J3bUlLUlEzcElEUGhQR1VsRUNZbGNObXVNTXVPUGsvKzdzUkIv?= =?utf-8?B?cUhTOGlVQWtBcWNqYmJpN1BUVGNzbVRIdEFDcWFSdHdoY0tOa1ZJejhzV0Ir?= =?utf-8?B?d3Q3cmw4QTJGYjFrakxxM3Bva1JxLzRxOUxoelRiRzI0TmVScEtaTExZaW50?= =?utf-8?B?WlluMTVVeG8wVlVvdVpZWm1EejFoVlpvakxWbHNwYllwOVdQUFRQbElqcnZN?= =?utf-8?B?a0NIeUZFMFBRTDU2RHhScS9KL0x0b09TNU94VHJQTythOHBIY0xoNDBxQjdN?= =?utf-8?B?RGVNL3Zrb1o1RmpDUWVwVENld2FvWXREZ2wwYUlZbmx1SWlCK0lvYkhDYTNj?= =?utf-8?B?dlpYTXJ5cG5FU2pTZGFVWElGM2RtOWZxdHBZdTd2bWFwb291TmtCbW54dWtZ?= =?utf-8?B?UEVlbG9NbEo3bzhsUmptMUlwQ2dIcFNHclNNeXhUSUppQWN0Q0FqdXIvUFJq?= =?utf-8?B?S1pyb0pHMDlETy9FWGcrbkxJd1NUQ0t4U2I1Zm9UVi9FMFVYVjlOSFZ5R2k0?= =?utf-8?B?bVVvSkJqTlh1a3k4a2JEUmpWTUpxNDdNTFE1REpyMDJqK3hVQUNXWVhZWnpa?= =?utf-8?B?eEJvRy9NejNidmExcENrUm9iMVJRPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(82310400026)(36860700013)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 04:13:20.4298 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8c2b62bf-e0fd-4daf-0f4a-08de5d5a67eb X-MS-Exchange-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: DS1PEPF00017093.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB9395 On 1/26/26 03:58, Jan Beulich wrote: > On 23.01.2026 23:24, Stewart Hildebrand wrote: >> On 1/19/26 09:46, Jan Beulich wrote: >>> Legacy PCI devices don't have any extended config space. Reading any part >>> thereof may return all ones or other arbitrary data, e.g. in some cases >>> base config space contents repeatedly. >>> >>> Logic follows Linux 6.19-rc's pci_cfg_space_size(), albeit leveraging our >>> determination of device type; in particular some comments are taken >>> verbatim from there. >>> >>> Signed-off-by: Jan Beulich >> >> Reviewed-by: Stewart Hildebrand > > Thanks, but see below (as that may change your take on it). > >>> --- >>> Should we skip re-evaluation when pci_mmcfg_arch_enable() takes its early >>> exit path? >> >> I don't have a strong opinion here, though I'm leaning toward it's OK as is. > > Maybe I need to add more context here. Not short-circuiting means that for > a brief moment ->ext_cfg for a device can be wrong - between > pci_check_extcfg() clearing it and then setting it again once all checks > have passed. As long as only Dom0 is executing at that time, and assuming > Dom0 actually issues the notification ahead of itself playing with > individual devices covered by it, all is going to be fine. With > hyperlaunch, however, DomU-s can't be told "not to fiddle" with devices > they've been assigned. > > With the yet-to-be-written vPCI counterpart changes the window is actually > going to get bigger for DomU-s using vPCI. > > For hyperlaunch this is going to be interesting anyway, on systems like > the one you mentioned. First, without Dom0 / hwdom, how would we even > learn we can use MCFG? And even with hwdom, how would we keep DomU-s from > accessing the devices they were passed until ->ext_cfg has obtained its > final state for them (and vPCI reached proper state, too)? Ah, I see. Thanks for the additional context. First of all, to re-answer the original question, it still feels more of a nice-to-have optimization than a necessity since we don't have hyperlaunch PCI passthrough upstream yet. Of course, skipping re-evaluating ext_cfg would be a welcome change if you're up for it. An alternative approach might be to implement pci_check_extcfg() such that it only modifies ->ext_cfg if it needs to be changed, but again, I don't have an issue with it as is. With that said, what do you think if we took the stance that ->ext_cfg shouldn't be re-evaluated for a pdev while it's assigned to a domU with vPCI? I.e. we would return an error from the pci_mmcfg_reserved hypercall in this case. If I understand things correctly, conceptually speaking, from a system perspective, setting up mcfg is something that *should* be done at boot, not ad-hoc during runtime. In the hyperlaunch model that I'm envisioning, there will also be hardware/control domain separation, and we will want to limit the hardware domain's ability to interfere with other domains. So I'd consider disabling the mmcfg_reserved hypercall anyway in such a configuration. The assumption with this model is that we would not need rely on dom0 to enable mcfg the system/platform of choice. Longer term, if we really think we need to support hyperlaunch while relying on a dom0 to initialize mcfg, we could potentially delay assigning pdevs to hyperlaunch domUs until ->ext_cfg has been initialized and is not expected to change. This would imply implementing hotplug for PVH domUs (also needed for "xl pci-attach" with PVH domUs). I wrote some patches in an internal branch to expose an emulated bridge with pcie hotplug capability, laying some of the groundwork to support this, and I'll plan to eventually send this work upstream. In the scenario without a dom0, I don't have a good answer at the moment for how Xen would learn that mcfg could be used. From xen-devel-bounces@lists.xenproject.org Tue Jan 27 08:45:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 08:45:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214103.1524487 (Exim 4.92) (envelope-from ) id 1vkehR-0007wZ-HP; Tue, 27 Jan 2026 08:45:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214103.1524487; Tue, 27 Jan 2026 08:45:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkehR-0007wR-EC; Tue, 27 Jan 2026 08:45:25 +0000 Received: by outflank-mailman (input) for mailman id 1214103; Tue, 27 Jan 2026 08:45: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 1vkehQ-0007wL-4t for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 08:45:24 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 829e96db-fb5c-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 09:45:19 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-47ee807a4c5so56068155e9.2 for ; Tue, 27 Jan 2026 00:45:19 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066bee30dsm43677975e9.6.2026.01.27.00.45.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 00:45:18 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 829e96db-fb5c-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769503519; x=1770108319; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=j0lunYaDLihrnJO5eAtL6TCuk7qVk3WpMu49PZnkiLU=; b=KWaU/SUZJ3gyMyLJbDlMPAZbe/tTSdL9kg2YJRT9A3uvLPuDLtQXMha1E2MVROSjzo yasnhNovEe2qE1aX1vnm/SCLatyWnYcR6q+C4ZhKN2an3CAOyE6oN+99jlGwEO5C4H+b J/vQ9+ibadYyQ+68X+48mY5lQCscNPe3jC67SValdd+e8e18jf2YJF6abOgmQjHwFmZT gkXMGmvy0Q7ANLSzoH/qRThEhXMYHOiHKht0sYINjh6bSUnBF/Q4/KblDMyRahmmzmoC hjf8dWLWOrPMH5zCnRYag3ljMCtnGjzOUltLEkgAoMQvVolpG1ZPvPjArkzVZ2Y8UQ3J Xegg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769503519; x=1770108319; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=j0lunYaDLihrnJO5eAtL6TCuk7qVk3WpMu49PZnkiLU=; b=YsY0cAa6q6GGs5GfmN0kc4BEMoeYiq4MpriPVKh39XnHvDUQxvI0SDM6kMKzMpEHcE pymYhTSFbB/0X/QE5Jz/soIsr7TfNVHxaU8xHjh4sBlX4t5dgraEtTrwc9cj+4zaufeR PGrDBvET9iDX1ORewggIUgO/k81cw0op28p+XOXqXvK5QyvjQzdTisEgCTjsr7G1+GHJ Q1yazJ6kK/nNLSLcsBWQCuADx3x1CfYNlqzscPrEOvpnneqy0oMybGVEseDnUl03P1e7 bKE0ytzioXJtF9kn+J2TMPhwrcg6fUeVz+meHGkVFDgA9rZLom3jFdU+rcq5zvJoijnu rgJw== X-Forwarded-Encrypted: i=1; AJvYcCUd1i9/E+g69d7S+RZnUXbtjlsqdidViqSzeVy4gBoN8FazPNB0IjyLLkLE6azS43n+X/pxFm7pBgE=@lists.xenproject.org X-Gm-Message-State: AOJu0YxAS+lGu7MjaoIORQoZ09GZFl5JetQwb6xUe9gqY0BWyqo5Tci/ G7B5PAD2WVbtaOg61e6YaHiUHnwbHiuMf9m2AMJeua/GG+IkKf73iv8Y/xxySKbpig== X-Gm-Gg: AZuq6aK3KNpCRxHlMX35CGlus75WKNMvsxgrgFW8yTwIsmSIj+wIX5JyHJMYVjnKnHN tC3+nM+sipu7r0l3NPhqb2mTP1cTObAVkqEq0AYtT6B7O1OJYF9LAU/uc37GFcp7/BX+Vtgcfj6 Ae0VoWfc1r2abO32ZD6etalaIoWN+DzXQWsN4sboJ3YaSiiNXukzemD1Dn01CNf0ykoFCl27Wmg ZLerPJidF3ZJfdihvLiQq3XSBrwATcljOpmTT11J346tpmYY9GvRrGsOJWYTwVdh2/SVbCg/2Uj grIHID/zQpcJy1u/JQcjI9PKcQN2HoTZa8PVNiHYHhlG0oBaiS5A+3+IbkF3HEwq0uAXQ5i6MZY 5ndQ7r6ikM2VcjcZ/F+dG0Z+MEoxyesOrjIXEiT2WCjM2+fMQPRH4TmJtzssqrp5MtQcUE0Fi71 01pa1ZbRMDS8PTC82nELly6mDY02zL2Nunw5YUOUGKzzBqzHZHd5j2A3XTdCXZu5Lspc3tS68W1 ms= X-Received: by 2002:a05:600c:1992:b0:471:14f5:126f with SMTP id 5b1f17b1804b1-48069c74078mr11165435e9.33.1769503519088; Tue, 27 Jan 2026 00:45:19 -0800 (PST) Message-ID: Date: Tue, 27 Jan 2026 09:45:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/5] cpufreq/hwp: move driver data into policy To: Jason Andryuk Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" References: <8441ada5-e2ed-4d79-822c-ecf1ce3c9484@suse.com> <26ef0e68-efca-4b9a-a210-76b5426da130@amd.com> <8bad1a32-d59c-4dba-8c35-b28fcb16f39c@suse.com> <3b9a40d3-ecd8-44cf-a310-620ed55abc68@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: <3b9a40d3-ecd8-44cf-a310-620ed55abc68@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.01.2026 21:17, Jason Andryuk wrote: > On 2026-01-26 04:08, Jan Beulich wrote: >> On 23.01.2026 23:35, Jason Andryuk wrote: >>> On 2026-01-22 04:42, Jan Beulich wrote: >>>> --- a/xen/arch/x86/acpi/cpufreq/hwp.c >>>> +++ b/xen/arch/x86/acpi/cpufreq/hwp.c >>> >>>> -static DEFINE_PER_CPU_READ_MOSTLY(struct hwp_drv_data *, hwp_drv_data); >>> >>> ... here is tracked and filled per-CPU. >>> >>> Do we need cpufreq_add_cpu() to force hw_all = 1 for HWP (and maybe >>> AMD-CPPC) to ensure that policy is allocated per-CPU? >> >> ... this being a correct thing to do, hence our code imo would better be >> resilient to it being different somewhere. >> >>> Are we implicitly relying on shared_type == CPUFREQ_SHARED_TYPE_HW to do >>> that for us? >> >> Right now we do, I believe, without - as said above - this being actually >> mandated by the spec. > > HWP doesn't need ACPI data. I wrote the driver according to the SDM, > which is just MSRs. It's Xen that needs ACPI data to initialize and use > cpufreq. Maybe we should see about lifting that restriction then? Becoming independent of Dom0's xen-acpi-processor driver would be quite a meaningful gain, I suppose. See e.g. the thread rooted at https://lists.xen.org/archives/html/xen-devel/2025-12/msg01114.html. > Regardless of that, it looks like the checks for cpu_online() and > performance_pminfo[] would constrain CPU accesses, so: > > Reviewed-by: Jason Andryuk Thanks. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 09:01:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 09:01:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214114.1524497 (Exim 4.92) (envelope-from ) id 1vkewv-0002Gh-Oh; Tue, 27 Jan 2026 09:01:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214114.1524497; Tue, 27 Jan 2026 09:01:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkewv-0002Ga-Lh; Tue, 27 Jan 2026 09:01:25 +0000 Received: by outflank-mailman (input) for mailman id 1214114; Tue, 27 Jan 2026 09:01:24 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkewu-0002GU-Ir for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 09:01:24 +0000 Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [2a00:1450:4864:20::444]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c0d1305b-fb5e-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 10:01:23 +0100 (CET) Received: by mail-wr1-x444.google.com with SMTP id ffacd0b85a97d-430f2ee2f00so3152224f8f.3 for ; Tue, 27 Jan 2026 01:01:23 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1f745e6sm34601403f8f.33.2026.01.27.01.01.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 01:01:21 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c0d1305b-fb5e-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769504482; x=1770109282; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=XNZ/H729BLC/Vg4e1NTNI56tNXtO41Rq0IwnCM0Jqys=; b=MWTnjU5dCu6TC4cfTd+TSp6AjyXCwp8wmQUcnncQrJxvnNShWHEznXckOEnvGosq7N csk21kFXpDyD/u5o8ueLF2GD9iR+iy3Dtou3uif/qj1Y6mpZfyI4a6pz1AOxvGXq8o0m nlWwHwrBhIKwdN456uwdr+nsz1qjK52fUpycQoOLdhl45Yj7sVu92rTcgQ0ijdHdHI8N Yq3gcMcHJnKkT9iUa2TGuRaQC6zlnixsRXWSwWp+7/1+/wbrxlTwDCFtu8G5xORk6GD1 cQSPALYvUxl5Ur3Knahb7rLs4AXR+FJ9FT9ceavGRt5oIs4rr16scyZG1wJm3vFOMZRI 4bxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769504482; x=1770109282; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=XNZ/H729BLC/Vg4e1NTNI56tNXtO41Rq0IwnCM0Jqys=; b=IPdWCL6/y/DimHLuuG8KmSbznsZTfXwVvd+i4CIq6WAnmCRBIzDldcdmMyNidObgl3 K6JKY4FC+007EaBQveSh0KNYx2b4DvtIhxc9aucvJgQaSlwSZmRBoI4LIlzNq7zQL51f ZIvwpqWR/DuSUk4ThIQRvy373DrYnJryHaYuBkSXcjuh5zmlHrV10uHGwE0fGQfOZ1hj aCzbVzhywypRd78zMNQ5yey0AM8ZsovplQns+XC05zCKDQCwzyt1u5QASdU81+Sr8ShP 8xqvw4yzqalpppI9VFTdD2mv5g4A1OXaVwznyu7hjHes2Vtoqs6qS1QaxaPv8oXRSKFD alcQ== X-Forwarded-Encrypted: i=1; AJvYcCV6Pxc5czrjukSuj+2K8pgv3wtK3p02TFkDx0ptUF+PQZ7QZqY8JplInEjrQ7+T8naNrSMx4rqkzr4=@lists.xenproject.org X-Gm-Message-State: AOJu0YweOB/EGsIq7DCXoh7J3kqVoiKnUWbvJA9uansFt8Y+dgTxPBcJ uGDTAV04tpX1H2w5THUP3OaBo5Xiu0YVpSgnZiRRUuO09OWXRmemvedhPXvdIL5t8g== X-Gm-Gg: AZuq6aIt1cjg+eVdgCAZHZPsLgXHHtpCQWWjNlGb/QwRYrDuyYBghLGPsIRJL7F7AI+ Zh9QuTMtFhrgKsRSfMFGPld6SeVdNDejDNhp3U18P6y4bgtsmCrucMzNr9tvsKGJZrWCC3zgfsW oA90rA5ObRv5mIYmv7mZ1EcrRBUHgZ9yMd89GjuOMIaYcqeWw5BSztR8KYGobfmMsTBgk2rObma vr5dy3id6Zpw6TCoTRpxvKMexEEmnIMl8agrgFKcHOQNwm/L+Kz8KR3t6nKvQJOs/le2AIpbl8i 6kAhDjGaxzH+88gmp9YTNVts0z2HOL6vJI1ixZZyU9dZHK6UBIQCoFGJ3WaFDJC0C61d/OupiP6 LVS26x2qTvV8U0p3ar11Yoh/Em1TZsTAxp8cZawHuYLbcX5jf9xgyYWlqpTiAackqQZ5HsXRZ+r 0gwpxG6ZWBJvv5a+1rgZl2oNHX47EBjV0/QdMBchhyPiWmOYEn94J3xjH4CDMWp/KgOUhOdCzrQ xk= X-Received: by 2002:a05:6000:22c9:b0:431:8f8:7f24 with SMTP id ffacd0b85a97d-435dd0b8222mr1544977f8f.39.1769504482274; Tue, 27 Jan 2026 01:01:22 -0800 (PST) Message-ID: <25b25628-3f99-46b8-94f5-b9c78601fbe0@suse.com> Date: Tue, 27 Jan 2026 10:01:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/4] PCI: determine whether a device has extended config space To: Stewart Hildebrand 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: <58091dc1-7bda-4536-8200-2d0a5679d4d1@suse.com> <553d1a7a-e465-413f-a60f-32455bbce621@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 27.01.2026 05:13, Stewart Hildebrand wrote: > On 1/26/26 03:58, Jan Beulich wrote: >> On 23.01.2026 23:24, Stewart Hildebrand wrote: >>> On 1/19/26 09:46, Jan Beulich wrote: >>>> Legacy PCI devices don't have any extended config space. Reading any part >>>> thereof may return all ones or other arbitrary data, e.g. in some cases >>>> base config space contents repeatedly. >>>> >>>> Logic follows Linux 6.19-rc's pci_cfg_space_size(), albeit leveraging our >>>> determination of device type; in particular some comments are taken >>>> verbatim from there. >>>> >>>> Signed-off-by: Jan Beulich >>> >>> Reviewed-by: Stewart Hildebrand >> >> Thanks, but see below (as that may change your take on it). >> >>>> --- >>>> Should we skip re-evaluation when pci_mmcfg_arch_enable() takes its early >>>> exit path? >>> >>> I don't have a strong opinion here, though I'm leaning toward it's OK as is. >> >> Maybe I need to add more context here. Not short-circuiting means that for >> a brief moment ->ext_cfg for a device can be wrong - between >> pci_check_extcfg() clearing it and then setting it again once all checks >> have passed. As long as only Dom0 is executing at that time, and assuming >> Dom0 actually issues the notification ahead of itself playing with >> individual devices covered by it, all is going to be fine. With >> hyperlaunch, however, DomU-s can't be told "not to fiddle" with devices >> they've been assigned. >> >> With the yet-to-be-written vPCI counterpart changes the window is actually >> going to get bigger for DomU-s using vPCI. >> >> For hyperlaunch this is going to be interesting anyway, on systems like >> the one you mentioned. First, without Dom0 / hwdom, how would we even >> learn we can use MCFG? And even with hwdom, how would we keep DomU-s from >> accessing the devices they were passed until ->ext_cfg has obtained its >> final state for them (and vPCI reached proper state, too)? > Ah, I see. Thanks for the additional context. > > First of all, to re-answer the original question, it still feels more of a > nice-to-have optimization than a necessity since we don't have hyperlaunch PCI > passthrough upstream yet. My fear here is that an aspect like this one may easily be forgotten when later doing the actual hyperlaunch work, or when finally making PCI properly supported on Arm64 (where then dom0less would be equally affected, unless Arm has found a way to avoid the dependency on Dom0's ACPI AML parsing). > Of course, skipping re-evaluating ext_cfg would be a > welcome change if you're up for it. We can surely keep this as an incremental change to be made. I guess I want to give Roger a chance to comment before deciding whether to commit the patch here as-is. > An alternative approach might be to > implement pci_check_extcfg() such that it only modifies ->ext_cfg if it needs to > be changed, but again, I don't have an issue with it as is. That wouldn't help much imo, as there's then still a time window where what the field says is wrong relative to what we already have accounted for in our MCFG handling. > With that said, what do you think if we took the stance that ->ext_cfg shouldn't > be re-evaluated for a pdev while it's assigned to a domU with vPCI? I.e. we > would return an error from the pci_mmcfg_reserved hypercall in this case. I don't like this idea, as it's functionally limiting (if MCFG becomes available only later) or functionally wrong (if, for whatever reason, MCFG becomes unavailable later). In no event would I consider returning an error from that hypercall. If anything I'd see us ignore it. > If I understand things correctly, conceptually speaking, from a system > perspective, setting up mcfg is something that *should* be done at boot, not > ad-hoc during runtime. Yes, and that concept simply collides with hyperlaunch's plan to launch more than just Dom0 right at boot. Dom0 booting is part of the system booting, after all. > In the hyperlaunch model that I'm envisioning, there will > also be hardware/control domain separation, and we will want to limit the > hardware domain's ability to interfere with other domains. So I'd consider > disabling the mmcfg_reserved hypercall anyway in such a configuration. The > assumption with this model is that we would not need rely on dom0 to enable mcfg > the system/platform of choice. But you need to work with the hardware you've got. For customized systems it certainly is an option to arrange for firmware to suitably report what Xen needs to be independent of Dom0. But for general purpose systems this won't necessarily fly. > Longer term, if we really think we need to support hyperlaunch while relying on > a dom0 to initialize mcfg, we could potentially delay assigning pdevs to > hyperlaunch domUs until ->ext_cfg has been initialized and is not expected to > change. This would imply implementing hotplug for PVH domUs (also needed for > "xl pci-attach" with PVH domUs). I wrote some patches in an internal branch to > expose an emulated bridge with pcie hotplug capability, laying some of the > groundwork to support this, and I'll plan to eventually send this work upstream. Which isn't quite what I understand one of hyperlaunch's goals is (to have all domains be statically configured, and hence be in final, usable shape right when their booting completes). Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 09:15:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 09:15:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214125.1524508 (Exim 4.92) (envelope-from ) id 1vkf9x-00041q-0g; Tue, 27 Jan 2026 09:14:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214125.1524508; Tue, 27 Jan 2026 09:14:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkf9w-00041j-U6; Tue, 27 Jan 2026 09:14:52 +0000 Received: by outflank-mailman (input) for mailman id 1214125; Tue, 27 Jan 2026 09:14:51 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkf9v-00041d-C1 for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 09:14:51 +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 a1b0e417-fb60-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 10:14:49 +0100 (CET) Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-4359108fd24so3171714f8f.2 for ; Tue, 27 Jan 2026 01:14:49 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1e7156dsm37369101f8f.20.2026.01.27.01.14.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 01:14:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a1b0e417-fb60-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769505289; x=1770110089; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=70SkXzfz76UseVgNS1JovfLNpfYQLaRtH/QS4N6l5Z0=; b=Pw1X1wsGYDRcNcg9aBbdI55QYT9Hi/TzjSNkM8Xbk0AnN50MNpZyDg5iQdQpxPs95Y MTl3XGEGWCXQ0MLttPQ9FDMPj2rkri8d3LTnZlh4TJFDAR2CT6ItrmlB+dGP8kIQ9Dln 3S6vHWpn8D8dMEqjLU7vhWSf98U+C0wzQOBbJ1VEdpY14kdN+ReG2v2fQE+V3owDuSmS 75FsVgFuW9/2zEPcDrtBKrEbHt2tLohpz3juLMD4B2NUvQ4KkUo2BASawNnDGBS+T1HL bVUqSgqEtc770tfeQXatmkpMKeFXTz6zBh0IiYeyc5wAiBp4hbGwVKNjRzUC0nJvDzqO UHVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769505289; x=1770110089; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=70SkXzfz76UseVgNS1JovfLNpfYQLaRtH/QS4N6l5Z0=; b=KOjGQWsZMH0JXzlVmtrRhg6vSx+IAzgp8/PFhiAD10DwlLGei5NqiHlxKBNu8r0v31 9AatyBXPxsFBuhSEhAnZmaHOTWQJu+xxfOsMxSKcq/MAPzvOKtuZNluVBeVF3j4cl752 T9E1t4H6Qu2wjTQI4uft5mw8flemHi6vUWbQ8vc2aQsA3jvM8Hbm+cuJQjrL+zmK15Ow C7gueahVN/IAaU9FEpgG9lon0FQhhWvSh2gDK364Xo2dMyR1m6rmWQwcJ30ZgpTnD034 lwe70O5DJJG6ISeXVEDFwyvv3HQvRPniTI73xgwjxMx+C3ZZJZ2kdhKgGcxDHaoY1twX KAaw== X-Forwarded-Encrypted: i=1; AJvYcCXbgo3g1S02svwz4WFBOcVK7zXrkSuvvuF0s3N90v0alqAJpOgmm4iO0we6547s/tsfPtOg1CjPIoU=@lists.xenproject.org X-Gm-Message-State: AOJu0YzMwJ4iD/roLJYkaXzQC/yApzYbhKMzW5UKDm6ZY9dpuo2z42Ah 2Vnlow8Dr4DvL5JdXgDTqD348GW/hvju9dT/rwjIkb9sZ87HASw43mwZ+Bzlzamx9w== X-Gm-Gg: AZuq6aJedVCF/wJKYAnCkyVW8+83oLsL/xMReRDHr1amf+coIE1oXH0f6jZFEgkP6uS SqCLdEXgRXNEdH/NvA3sM+tLyiBB+2D1xvFJkUpP48OWEDoFT+cFl+49Tk1cZmYLxpGaagNyavJ L/mCaMDk2FEdUw0l0hLGZu+T+g6wgfBlV0Gcgn7VB3xLQ0ia4ySndOM7gEsqrd+mw6e/Mzq3CO8 iZesBgEKdOR3RVG7AgdB783y61gWYaSASmZMhYs+cogEASecqCSJ0wweSDHxChFdqNaISg2eE34 65L++f8Vy/Ixp54/KIHRyqrAxltK/vhtvVppdD3uJBSwKW0G/bT0mYxzuyE0b6UBuWIzdc4L2u0 NSQ9hZeTnEPpHoyV/InGERDqn5OumxTIkuyQp6V0E5GmrH7vHKEs24Q+IrvmdyEwR0LsamaVKcE kYFjtzy1cEXu1U7yzuxojFv3OUr5IX4cj+cjj3heKzpABhYXCDoXwkOoWJkLDzzN/DHs62qD8VU Sg= X-Received: by 2002:a05:6000:2906:b0:432:857d:e425 with SMTP id ffacd0b85a97d-435dd0a40a4mr1286361f8f.30.1769505289153; Tue, 27 Jan 2026 01:14:49 -0800 (PST) Message-ID: Date: Tue, 27 Jan 2026 10:14:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] xen/riscv: dump GPRs and CSRs on unexpected traps To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <27ab0f8eb6fd6ecef1eeefa4a05e4fe1f43acbbe.1769427484.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: <27ab0f8eb6fd6ecef1eeefa4a05e4fe1f43acbbe.1769427484.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.01.2026 12:43, Oleksii Kurochko wrote: > Provide additional context when an unexpected exception occurs by dumping > the relevant Supervisor, Virtual Supervisor (VS), and Hypervisor CSRs, > along with the general-purpose registers associated with the trap. > > Dumping VS-mode CSRs in addition to host CSRs is beneficial when analysing > VS-mode traps. VSCAUSE, VSEPC, VSTVAL, and related VS state are required to > properly diagnose unexpected guest traps and potential hypervisor > misconfiguration. > For example, on an illegal-instruction exception the hardware may record > the faulting instruction in VSTVAL. If VSTVAL is zero, VSEPC should always > be inspected, and can be used together with objdump to identify the > faulting instruction. Dumping VSCAUSE is also useful when the guest does > not report it, or when the hypervisor redirects a trap to the guest using > VSCAUSE, VSTATUS, and VSTVEC, allowing verification that a subsequent trap > is not caused by incorrect VS state. > > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich I still have a question though, which can be addressed incrementally. > --- a/xen/arch/riscv/traps.c > +++ b/xen/arch/riscv/traps.c > @@ -99,12 +99,70 @@ static const char *decode_cause(unsigned long cause) > return decode_trap_cause(cause); > } > > +static void dump_general_regs(const struct cpu_user_regs *regs) > +{ > +#define X(regs, name, delim) \ > + printk("%-4s: %016lx" delim, #name, (regs)->name) > + > + X(regs, ra, " "); X(regs, sp, "\n"); > + X(regs, gp, " "); X(regs, tp, "\n"); > + X(regs, t0, " "); X(regs, t1, "\n"); > + X(regs, t2, " "); X(regs, s0, "\n"); > + X(regs, s1, " "); X(regs, a0, "\n"); > + X(regs, a1, " "); X(regs, a2, "\n"); > + X(regs, a3, " "); X(regs, a4, "\n"); > + X(regs, a5, " "); X(regs, a6, "\n"); > + X(regs, a7, " "); X(regs, s2, "\n"); > + X(regs, s3, " "); X(regs, s4, "\n"); > + X(regs, s5, " "); X(regs, s6, "\n"); > + X(regs, s7, " "); X(regs, s8, "\n"); > + X(regs, s9, " "); X(regs, s10, "\n"); > + X(regs, s11, " "); X(regs, t3, "\n"); > + X(regs, t4, " "); X(regs, t5, "\n"); > + X(regs, t6, " "); X(regs, sepc, "\n"); Does this sepc value differ from ... > +static void dump_csrs(unsigned long cause) > +{ > +#define X(name, csr, fmt, ...) \ > + v = csr_read(csr); \ > + printk("%-10s: %016lx" fmt, #name, v, ##__VA_ARGS__) > + > + unsigned long v; > + > + X(htval, CSR_HTVAL, " "); X(htinst, CSR_HTINST, "\n"); > + X(hedeleg, CSR_HEDELEG, " "); X(hideleg, CSR_HIDELEG, "\n"); > + X(hstatus, CSR_HSTATUS, " [%s%s%s%s%s%s ]\n", > + (v & HSTATUS_VTSR) ? " VTSR" : "", > + (v & HSTATUS_VTVM) ? " VTVM" : "", > + (v & HSTATUS_HU) ? " HU" : "", > + (v & HSTATUS_SPVP) ? " SPVP" : "", > + (v & HSTATUS_SPV) ? " SPV" : "", > + (v & HSTATUS_GVA) ? " GVA" : ""); > + X(hgatp, CSR_HGATP, "\n"); > + X(hstateen0, CSR_HSTATEEN0, "\n"); > + X(stvec, CSR_STVEC, " "); X(vstvec, CSR_VSTVEC, "\n"); > + X(sepc, CSR_SEPC, " "); X(vsepc, CSR_VSEPC, "\n"); ... the one logged here? Nothing changes the register between entry into the hypervisor and coming here? Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 09:27:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 09:27:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214138.1524518 (Exim 4.92) (envelope-from ) id 1vkfMA-0005iE-2Z; Tue, 27 Jan 2026 09:27:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214138.1524518; Tue, 27 Jan 2026 09: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 1vkfM9-0005i7-VM; Tue, 27 Jan 2026 09:27:29 +0000 Received: by outflank-mailman (input) for mailman id 1214138; Tue, 27 Jan 2026 09: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 1vkfM8-0005i0-AM for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 09:27:28 +0000 Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [2a00:1450:4864:20::32b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5fa5610e-fb62-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 10:27:18 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-47ff94b46afso47227685e9.1 for ; Tue, 27 Jan 2026 01:27:17 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066be7413sm45475845e9.3.2026.01.27.01.27.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 01:27:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5fa5610e-fb62-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769506037; x=1770110837; 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=qi4qoQe9PFThzu1iJMn7cRw9wFsxLdvdJVCBSl7BNY8=; b=ajdh+Fu+immsiHeNumISjw4fM9RiC9CiezqMC0RRRR1fgr/LMWIlBy47D8bla/TwNO I8hn4DxgCXLSJfKtAzsn7QzDaHNutwb7DAJ2RvIzpZFb8f3FnfgijsjUukfD94hzSTpB PZj6KN5GQ+AeqlmsOI9WJHWYb0jNh7qBjiLe+zB3Wb39RCkfT9AafRSYWOioMHKOpVuq YRrTFERiBPX0BZNzoAXoK26FiFv0QEx/RbNUN5vkEw1sC41SwLnFVGtXjeBSB5CtOphv 3+/iNuQNPvmuRq00HKNAKIaqHaLe2COpzllf60+hiN075iQ/JPvCJ9U2c/tnhWmX4+0C ljjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769506037; x=1770110837; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=qi4qoQe9PFThzu1iJMn7cRw9wFsxLdvdJVCBSl7BNY8=; b=SCgabveZ5UqErRcWfDLIakdcKNzMH1w64JJLdLb65Mo9tKxyEd0OWuJnzLGDnDeRhc kOv7BnVMKaRXTs1P5l19jC+YIW+asQ3UzNFg9KxVCwaZqj4plkjBBdXmiU+sOyKylsMA Ep7Kt6kONxx7gM6azWE4t9HwikhU89YqEO35Lrt8OCEo1L8/v45XqO0EtxFjJGy0TzA1 xnOZ06wC93CGt+iu4Eh9kR0lMxv4U0+RUSm3wQT/1CVooa3VuxyoYZNZD+Hi6JHxkdZ8 wT/6h9EUCvGKzgFv5ggUqqk8ELC24TuJcbQcY5cRL3MKgrG3PAI4rIlnAKw/t8IhZwqK hJnA== X-Forwarded-Encrypted: i=1; AJvYcCXAj0U2lGwVZTZK/wi3ORqhccLT1joKR8HJA07Fp1HugmBnHx3dEzQBKdWzsRSpUihyGkgrqWH662Y=@lists.xenproject.org X-Gm-Message-State: AOJu0YyHUxLLaB3veaLoG10EE1AITaei4qUii9qq/z5jeZ8aOU2JcZCV 58GFamfsiLQFFw4oXx21GFEAoOHqNHv0CG1QpjLjoF6JiMNP05vfgLoZ1bf3dLuTSw== X-Gm-Gg: AZuq6aJluwBsFexC/fRxtniZXzvqmpPbwVBuD6azQCe34ML1GT54eI+at13bfVLvynv 7zV9aeER216dPToAJ75plYHjqKNF64iAfmhR4VK7q7wcraoRFGzZv+cKhZFqxCF6++89f4MSPvi gomnwQ1fnioPyHxNzBo0JnN5gADu5r0xPEdZ46RzrqWtNX7OtGTdphAGyR+2v2uEf88/izfPJgE XHAislCrEhNH8eFB001kms4eJ/h1GjnuRbfJCeRJFjOfkRW5nTuPd4j5mEjfaq7Hto2kt3m5fad 2O4Hol1psTvJ6e+t+E8+4nJVU9shlpba8WD8T6qxLCQRKzi/R9UOt2aT8Kgs8stO9FhDTTgs9dM mtczATisl2lKdNqR16CZuTLmRXmdunl2Cmx6sZRD8bn268Hjc/jyWZUHl+S182LKDiQE7+3dkvf AHwU7ljxLOpGnFpTGMM3Xupp2cuOYt15pagmew9A9GO25HWL6WSF8TVL1cbBRs2mm/0Ce3hq22G DA= X-Received: by 2002:a05:600c:3b1c:b0:47d:87ac:73ef with SMTP id 5b1f17b1804b1-48069e792a9mr11029365e9.13.1769506037315; Tue, 27 Jan 2026 01:27:17 -0800 (PST) Message-ID: Date: Tue, 27 Jan 2026 10:27:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] xen/riscv: dump GPRs and CSRs on unexpected traps From: Jan Beulich To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <27ab0f8eb6fd6ecef1eeefa4a05e4fe1f43acbbe.1769427484.git.oleksii.kurochko@gmail.com> Content-Language: en-US Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 27.01.2026 10:14, Jan Beulich wrote: > On 26.01.2026 12:43, Oleksii Kurochko wrote: >> Provide additional context when an unexpected exception occurs by dumping >> the relevant Supervisor, Virtual Supervisor (VS), and Hypervisor CSRs, >> along with the general-purpose registers associated with the trap. >> >> Dumping VS-mode CSRs in addition to host CSRs is beneficial when analysing >> VS-mode traps. VSCAUSE, VSEPC, VSTVAL, and related VS state are required to >> properly diagnose unexpected guest traps and potential hypervisor >> misconfiguration. >> For example, on an illegal-instruction exception the hardware may record >> the faulting instruction in VSTVAL. If VSTVAL is zero, VSEPC should always >> be inspected, and can be used together with objdump to identify the >> faulting instruction. Dumping VSCAUSE is also useful when the guest does >> not report it, or when the hypervisor redirects a trap to the guest using >> VSCAUSE, VSTATUS, and VSTVEC, allowing verification that a subsequent trap >> is not caused by incorrect VS state. >> >> Signed-off-by: Oleksii Kurochko > > Acked-by: Jan Beulich Hmm, wait, there's another anomaly: > I still have a question though, which can be addressed incrementally. > >> --- a/xen/arch/riscv/traps.c >> +++ b/xen/arch/riscv/traps.c >> @@ -99,12 +99,70 @@ static const char *decode_cause(unsigned long cause) >> return decode_trap_cause(cause); >> } >> >> +static void dump_general_regs(const struct cpu_user_regs *regs) >> +{ >> +#define X(regs, name, delim) \ >> + printk("%-4s: %016lx" delim, #name, (regs)->name) >> + >> + X(regs, ra, " "); X(regs, sp, "\n"); >> + X(regs, gp, " "); X(regs, tp, "\n"); >> + X(regs, t0, " "); X(regs, t1, "\n"); >> + X(regs, t2, " "); X(regs, s0, "\n"); >> + X(regs, s1, " "); X(regs, a0, "\n"); >> + X(regs, a1, " "); X(regs, a2, "\n"); >> + X(regs, a3, " "); X(regs, a4, "\n"); >> + X(regs, a5, " "); X(regs, a6, "\n"); >> + X(regs, a7, " "); X(regs, s2, "\n"); >> + X(regs, s3, " "); X(regs, s4, "\n"); >> + X(regs, s5, " "); X(regs, s6, "\n"); >> + X(regs, s7, " "); X(regs, s8, "\n"); >> + X(regs, s9, " "); X(regs, s10, "\n"); >> + X(regs, s11, " "); X(regs, t3, "\n"); >> + X(regs, t4, " "); X(regs, t5, "\n"); >> + X(regs, t6, " "); X(regs, sepc, "\n"); > > Does this sepc value differ from ... > >> +static void dump_csrs(unsigned long cause) What is this function parameter for? >> +{ >> +#define X(name, csr, fmt, ...) \ >> + v = csr_read(csr); \ >> + printk("%-10s: %016lx" fmt, #name, v, ##__VA_ARGS__) >> + >> + unsigned long v; >> + >> + X(htval, CSR_HTVAL, " "); X(htinst, CSR_HTINST, "\n"); >> + X(hedeleg, CSR_HEDELEG, " "); X(hideleg, CSR_HIDELEG, "\n"); >> + X(hstatus, CSR_HSTATUS, " [%s%s%s%s%s%s ]\n", >> + (v & HSTATUS_VTSR) ? " VTSR" : "", >> + (v & HSTATUS_VTVM) ? " VTVM" : "", >> + (v & HSTATUS_HU) ? " HU" : "", >> + (v & HSTATUS_SPVP) ? " SPVP" : "", >> + (v & HSTATUS_SPV) ? " SPV" : "", >> + (v & HSTATUS_GVA) ? " GVA" : ""); >> + X(hgatp, CSR_HGATP, "\n"); >> + X(hstateen0, CSR_HSTATEEN0, "\n"); >> + X(stvec, CSR_STVEC, " "); X(vstvec, CSR_VSTVEC, "\n"); >> + X(sepc, CSR_SEPC, " "); X(vsepc, CSR_VSEPC, "\n"); > > ... the one logged here? Nothing changes the register between entry > into the hypervisor and coming here? Down below here you have X(scause, CSR_SCAUSE, " [%s]\n", decode_cause(v)); which actually (largely) duplicates what do_unexpected_trap() has already logged. If dump_csrs() gained other uses, the dumping of scause likely is wanted, but then likely no scause value would be available to pass in? So maybe its dumping actually wants to be conditional (and the parameter wants to be a boolean)? Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 10:15:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 10:15:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214156.1524528 (Exim 4.92) (envelope-from ) id 1vkg66-0003R4-D4; Tue, 27 Jan 2026 10:14:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214156.1524528; Tue, 27 Jan 2026 10:14:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkg66-0003Qx-9x; Tue, 27 Jan 2026 10:14:58 +0000 Received: by outflank-mailman (input) for mailman id 1214156; Tue, 27 Jan 2026 10:14: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 1vkg65-0003Qn-GN for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 10:14:57 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 06373b51-fb69-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 11:14:54 +0100 (CET) Received: from BN0PR04CA0197.namprd04.prod.outlook.com (2603:10b6:408:e9::22) by MW6PR12MB8705.namprd12.prod.outlook.com (2603:10b6:303:24c::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Tue, 27 Jan 2026 10:14:48 +0000 Received: from BN3PEPF0000B06A.namprd21.prod.outlook.com (2603:10b6:408:e9:cafe::19) by BN0PR04CA0197.outlook.office365.com (2603:10b6:408:e9::22) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Tue, 27 Jan 2026 10:14:12 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN3PEPF0000B06A.mail.protection.outlook.com (10.167.243.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9587.0 via Frontend Transport; Tue, 27 Jan 2026 10:14:47 +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; Tue, 27 Jan 2026 04:14:47 -0600 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Tue, 27 Jan 2026 02:14:47 -0800 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, 27 Jan 2026 02:14:45 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 06373b51-fb69-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=b4oLx+KqwiW5o186j+fhOAOfIdKq/CgCR6v1oDdyqLvmgkKrfqvQhcFV4YRTc8Qp9tt3mwnW0SXhZeVxlZ3bcpjONFCvgp+BkfHI+vyHJc+i9VBJeLKUQGpWzUJ86vSfRPRkgrRrTyla0BbycdJCeDqVbWEV00HKNHZmSV59mz29mFYdWz25+mAAcclPzHc4c3GZcrzaxI5JJ1i1gYrVrLqt38wyL5BfCwY5GgwWpUVz3BT/jKu3zx/xYu/0oH9TWhLLQEmdobFTLkknyPtQ38Aw12b45rctQewSMtxin1ZMdo95j1aA6aB5ZQ5GkndBYNNnltiSZx6qpalpxmOn0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=P6G/ev7DfkxLhti4nY1GLMsJL47FkmJv6/RKrOUycog=; b=A0Un7WMbWawPEYx6YahUuDyJl44A6A0xHyG8f4XLR2hJPjJG/Zf1J9gjlVJVB06K3+t0ZaQlxsXxzuuLLq56Typ0W2cZGbmBhEFL2C2K50cd0aifrj4DNCLq3Alx2kzU9F/23Zpb8UVWMjEmoxIFQQ6CQEkmATPEOgEDQnlpn0ixAQ5bf2Ntzf+vhgpIBY2Yv8pLAA9TQ5hR+V3DVxyLsVTHjyaqNK2Wx6BHK96+iVxmC9dLd8OkZ9Jt4s1ko+SNK8Z1G7s8BnhKSXpwvVlzr/EyXjWryT5Y4SxvASYXyrGzPX37Dso9qbD+1b7ld9cIA2RbBnyevmlA6apKCFWolQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=arm.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P6G/ev7DfkxLhti4nY1GLMsJL47FkmJv6/RKrOUycog=; b=1tD/se3x/G6IOyEgjn32xMVk8+xsCUMA8BfyiCQIo63YoOKOo8gJ3Rl5wsaVOqHmMaGU7M0Z/32Us18iq5Wbw3I5EhIdUI65FeTNpU6u/owMB0U9PYo0JSDms1O3cHJ186fTTXiKNtPn/Mra4vp72Pc6/6O0mMvNffu4LLNoSx0= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <899a572a-1ba6-4bc6-806e-d049b4ac3ce3@amd.com> Date: Tue, 27 Jan 2026 11:14:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] arm/mpu: implement setup_virt_paging for MPU system To: Harry Ramsey , CC: , Penny Zheng , "Stefano Stabellini" , Julien Grall , "Bertrand Marquis" , Volodymyr Babchuk , Wei Chen , Hari Limaye References: <20260119105022.3616126-1-harry.ramsey@arm.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20260119105022.3616126-1-harry.ramsey@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF0000B06A:EE_|MW6PR12MB8705:EE_ X-MS-Office365-Filtering-Correlation-Id: 32f64e59-26e8-4ffc-ee1c-08de5d8ce666 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|1800799024|82310400026|376014|7416014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?KzBhRVFJS1A0MmRsVTRQZlBsVjFOZitza2U3dDBxSGhzdk1lZk1zZ1g4YzAr?= =?utf-8?B?SjJMeVEyMnMvdHVDWWpsQ0ppZHF2YU5jRENGa1pVcGptVmVQOUVRZzZLemhp?= =?utf-8?B?KzBHbzFPTXRqaHJqdjA1Z2RQWERvb3JQQ1VnTS9MZ21reGMvcEFOajdBUEI2?= =?utf-8?B?TmtBTGMrT1JDU1RrMmcvN2lpaXNRZURnbWlDRTRidjVFOWlzTzhheXFndVJJ?= =?utf-8?B?VzV4QUJnZ2lTMnZNTVJGUFFvOXJMV1BQSFovYUV6OUlwOWlwOERzOTM0QzE3?= =?utf-8?B?QVlwbHVyRFBQTW9CcVU4S094RklOUTBVU0VPVkdJYnlvSjRkRGFkMTQvMkIv?= =?utf-8?B?cHZMRWtqL0MwVG9zN0JKSW1GSk14UEw2SDdadzNMMkZDeVd5eWZKS1ZDU0pn?= =?utf-8?B?YytYZWtDYVdxU3RacHV2TEMwdEZzc0ljS3huYzN3YmJiUGdXN0ZSZGFjV0Jn?= =?utf-8?B?Y29jOFdEMWk3dElpcXBrNjFRcjY2bC9ad1VxOERyZUVFWXl3SE5BMFIrYmQ5?= =?utf-8?B?OWNpS1Bka2JOSFhpY3RHSVdrYUhYR1k0c1Q2Q3Fmb1VFQzZ6bG9pTVFYNXJC?= =?utf-8?B?dko3RklsZ3hwNXg2bzFoajdRWGxMaFVaUkQzamNKR0t3NXd0aVhmQk5FbFAx?= =?utf-8?B?bWk0c3JTVnlPQXE3alNWbjVjNis2SEZ3ZUJsM25CMG1ySW1xY1FQOXRkdlA5?= =?utf-8?B?VHJxWnl0d3QwQ0NPcWNvb2xqdklXdytNWE8xRUNYUlZPTnJHUUdVeDc1SXd5?= =?utf-8?B?bXYrSnAxSXd0QU9EdFJIcUxOeWhXNEJLNXVZZERydkphVGdwaWRqeGh1NE9r?= =?utf-8?B?Y0YwYnVYTkdpaWdDcjJYcXZ5RWJZYVJMVzRmUTJCemRiMFR6SHZTcGh1dW4w?= =?utf-8?B?OUhJbkQzRXJsVkRIeWFoOVFyRjl3aWZMeXJoU29MVDRnM2gyQm1DdWYvcmY4?= =?utf-8?B?WlJ2U3J0K21Nc2lib0ZNcU9WY2xLNGd3N3dvdzZnQlhEWEdQUGZ5enZLU0hP?= =?utf-8?B?bHp3UzlLNFY3N0xUTmhVYkFGWmxzWUI1YlJEQmpEVTJhZkMyL3A0Sm9ZQlhI?= =?utf-8?B?bk9RTkhNMTRnNGFCd2hSUi9vd3BTb1dRL3VIQmtRZ245aWdvTnNqVWZKVjVF?= =?utf-8?B?WG5nTVdsWTdzVHZWQmtsQ25xRWRrazNSd3NGcHhlZUtCbEJWaitZdjU5ZE1T?= =?utf-8?B?eHo3TTI5TzR2dVRxcEE1TThrU05ZbDNLaFpJQm9BbzJ3TXJMdVZYb1h1eWVP?= =?utf-8?B?N01yTmZncUF0c3VPc3c3RWl0U2I2VXhMcXV3d0NVNmk3VDNOQVJ2Wkk0cnht?= =?utf-8?B?TFpteUI1ZXpNMTRReFVCMFRURHhBQzFnLzV1blRLK3Zla01QUHRpMFlIWG1X?= =?utf-8?B?RjlLTFJzVnB6N2VSNTZWMUFibmRlWjQva3RIWDE1b0MyWU1ad3hYZFp0Y2lh?= =?utf-8?B?blIwZ2JXV2c0TUwydTdmcUhXbmxzZUJRQllXZ1kvd3lDZHBTTC9QUnRXR25s?= =?utf-8?B?WCtrd1h2VU53Tm5uYmVFVEhLSWM3NEtZNWtCWXREejY2Mk9MV0dWaHlQakM5?= =?utf-8?B?NDNHcFZkQURZM28wZlRiWGFraWVxSlpRZDh6NTRJWjdROU9XRDJ1cGJiWktj?= =?utf-8?B?UksyYXhtdUVXTmxUdXJGT0Q0dGJUMjRUK3J1S0tQdUo3RWpoR3VsSzZKUTls?= =?utf-8?B?VUxpTnpQQ3I4dWFENitETW96YXFRSnhyRDRHTkxPall6bXcraXRBTXpIT3Ns?= =?utf-8?B?L0RLZXJ6ckljMzVWQVZiVWF3REJRTmVqVWViaWtkRGgrdGlwSm9DMDlBSFhK?= =?utf-8?B?MEVKb1lmM0VkQ2txVTg5UjJIdjJxUmdSNTZwZ2JEaVFZUk8zRmlFcUJsUnNY?= =?utf-8?B?TTMvKzRBazdWY3Z2NWdiR2RuVzRoY2ZyUXhyZG5NVWRXY0pTR3AxYXVINlpp?= =?utf-8?B?R1NKN0NIbWJGU1FhalREaFp3UlhLQWxwcDY2M3ZYelc1aXhXVytTakhzczdR?= =?utf-8?B?SDd4bWJ6enU0bGd6ZTBmY3BHcndKMndUOWxYaW5TRHZxZDNnczB1dVV6YXV0?= =?utf-8?B?K3p4SjFFaVRWRFJiczlCcDMvYk5nTDRGT0U1ajdPTWxYR1NtL0ZRR1VVZ2Zv?= =?utf-8?B?VG1yd1BJYzdJVnpLYm4wVWtHZkpqT3NXK1M0RkJqbHN6MFJmdk9kOXVDai9V?= =?utf-8?B?TUp3b0kycjVJY0xCQ0pBQmdIS2FEYWVBNzBMaTNMTjJ2YWhMbGlXanE0L2d4?= =?utf-8?B?WmJJNkZhK0F1TG0rMXdKQzU0VVl3PT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014)(7416014)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 10:14:47.5067 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 32f64e59-26e8-4ffc-ee1c-08de5d8ce666 X-MS-Exchange-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: BN3PEPF0000B06A.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8705 On 19/01/2026 11:50, Harry Ramsey wrote: > From: Penny Zheng > > For MMU system, setup_virt_paging is used to configure stage 2 address > translation regime, like IPA bits, VMID allocator set up, etc. > Some could be inherited in MPU system, like VMID allocator set up, etc. The commit msg only mentions setup_virt_paging, so why do you implement other p2m functions in the same commit? I would split the patch in two for clarity and ease of review. I will focus on setup_virt_paging. > > For MPU system, we could have the following memory translation regime: > - PMSAv8-64 at both EL1/EL0 and EL2 > - VMSAv8-64 at EL1/EL0 and PMSAv8-64 at EL2 > The default option will be the second, unless the platform could not support, > which could be checked against MSA_frac bit in Memory Model Feature Register 0( > ID_AA64MMFR0_EL1). What's the reasoning behind it? Why do we prefer VMSA at EL1 rather than PMSA? AFAICT PMSA is a default and VMSA is optional, so logically PMSA should be preffered. We should also make it configurable I think, so that a user has a choice. > > Signed-off-by: Penny Zheng > Signed-off-by: Wei Chen > Signed-off-by: Luca Fancellu > Signed-off-by: Hari Limaye > Signed-off-by: Harry Ramsey > --- > xen/arch/arm/arm64/mpu/p2m.c | 90 +++++++++++++++++++++++- > xen/arch/arm/include/asm/arm32/mpu.h | 2 + > xen/arch/arm/include/asm/arm64/mpu.h | 2 + > xen/arch/arm/include/asm/arm64/sysregs.h | 5 ++ > xen/arch/arm/include/asm/cpufeature.h | 7 ++ > xen/arch/arm/include/asm/mpu.h | 7 +- > xen/arch/arm/include/asm/mpu/p2m.h | 12 ++++ > xen/arch/arm/include/asm/p2m.h | 5 ++ > xen/arch/arm/include/asm/processor.h | 13 ++++ > xen/arch/arm/mpu/p2m.c | 71 ++++++++++++++++++- > 10 files changed, 209 insertions(+), 5 deletions(-) > > diff --git a/xen/arch/arm/arm64/mpu/p2m.c b/xen/arch/arm/arm64/mpu/p2m.c > index b6d8b2777b..13b633d9fe 100644 > --- a/xen/arch/arm/arm64/mpu/p2m.c > +++ b/xen/arch/arm/arm64/mpu/p2m.c > @@ -2,11 +2,99 @@ > > #include > #include > +#include > #include > > void __init setup_virt_paging(void) > { > - BUG_ON("unimplemented"); > + uint64_t vtcr_el2 = 0, vstcr_el2 = 0; > + bool p2m_vmsa = true; > + > + /* PA size */ > + const unsigned int pa_range_info[] = { 32, 36, 40, 42, 44, 48, 52, 0, /* Invalid */ }; 80 chars exceeded. Do we still need 0 here to denote invalid value? > + > + /* > + * Restrict "p2m_ipa_bits" if needed. As P2M table is always configured > + * with IPA bits == PA bits, compare against "pabits". > + */ > + if ( pa_range_info[system_cpuinfo.mm64.pa_range] < p2m_ipa_bits ) > + p2m_ipa_bits = pa_range_info[system_cpuinfo.mm64.pa_range]; > + > + /* > + * Clear VTCR_EL2.NSA bit to configure non-secure stage 2 translation output > + * address space to access the Secure PA space. > + */ > + vtcr_el2 &= NSA_SEL2; This has no effect. > + > + /* > + * The MSA and MSA_frac fields in the ID_AA64MMFR0_EL1 register identify the > + * memory system configurations supported at EL1. In Armv8-R AArch64, the The spec mentions all translation regimes + specific configuration for EL1, so it's not EL1 only. > + * only permitted value for ID_AA64MMFR0_EL1.MSA is 0b1111. > + */ > + if ( system_cpuinfo.mm64.msa != MM64_MSA_PMSA_SUPPORT ) > + goto fault; > + > + /* Permitted values for ID_AA64MMFR0_EL1.MSA_frac are 0b0001 and 0b0010. */ > + if ( system_cpuinfo.mm64.msa_frac == MM64_MSA_FRAC_NONE_SUPPORT ) > + goto fault; > + > + /* > + * When ID_AA64MMFR0_EL1.MSA_frac is 0b0010 the stage 1 EL1&0 translation > + * regime supports both PMSAv8-64 and VMSAv8-64. > + */ > + if ( system_cpuinfo.mm64.msa_frac != MM64_MSA_FRAC_VMSA_SUPPORT ) > + { > + p2m_vmsa = false; > + warning_add("Be aware of that there is no support for VMSAv8-64 at EL1 on this platform\n"); I think we should make PMSA a default. If at all, a warning message could be made simpler e.g. "No support for VMSAv8-64 at EL1". Seeing a warning already means that user should be aware of sth and it's clear that the message is about this platform. > + } > + > + /* > + * If PE supports both PMSAv8-64 and VMSAv8-64 at EL1, then VTCR_EL2.MSA > + * determines the memory system architecture enabled at stage 1 of the > + * Secure EL1&0 translation regime. > + * > + * Normally, we set the initial VTCR_EL2.MSA value VMSAv8-64 support, > + * unless this platform only supports PMSAv8-64. > + */ > + if ( !p2m_vmsa ) > + vtcr_el2 &= VTCR_MSA_PMSA; > + else > + vtcr_el2 |= VTCR_MSA_VMSA; > + > + /* > + * cpuinfo sanitization makes sure we support 16bits VMID only if all cores > + * are supporting it. > + */ > + if ( system_cpuinfo.mm64.vmid_bits == MM64_VMID_16_BITS_SUPPORT ) > + max_vmid = MAX_VMID_16_BIT; > + > + /* Set the VS bit only if 16 bit VMID is supported. */ > + if ( MAX_VMID == MAX_VMID_16_BIT ) Instead of a macro, use max_vmid variable here > + vtcr_el2 |= VTCR_VS; > + > + p2m_vmid_allocator_init(); > + > + WRITE_SYSREG(vtcr_el2, VTCR_EL2); Where do we set NSA bit? > + > + /* > + * VSTCR_EL2.SA defines secure stage 2 translation output address space. > + * To make sure that all stage 2 translations for the Secure PA space access > + * the Secure PA space, we keep SA bit as 0. This says that we want to access secure PA space but not why. > + * > + * VSTCR_EL2.SC is NS check enable bit. To make sure that Stage 2 NS > + * configuration is checked against stage 1 NS configuration in EL1&0 > + * translation regime for the given address, and generates a fault if they > + * are different, we set SC bit 1. > + */ > + vstcr_el2 = 1 << VSTCR_EL2_RES1_SHIFT; Why are we setting the RES1 bit? > + vstcr_el2 &= VSTCR_EL2_SA; This has no effect because you initialized it to 0. > + vstcr_el2 |= VSTCR_EL2_SC; > + WRITE_SYSREG(vstcr_el2, VSTCR_EL2); > + > + return; > + > + fault: > + panic("Hardware with no PMSAv8-64 support in any translation regime\n"); > } > > /* > diff --git a/xen/arch/arm/include/asm/arm32/mpu.h b/xen/arch/arm/include/asm/arm32/mpu.h > index 2cf0f8cbac..d565230f84 100644 > --- a/xen/arch/arm/include/asm/arm32/mpu.h > +++ b/xen/arch/arm/include/asm/arm32/mpu.h > @@ -11,6 +11,8 @@ > */ > #define MPU_REGION_RES0 0x0 > > +#define VSCTLR_VMID_SHIFT 16 > + > /* Hypervisor Protection Region Base Address Register */ > typedef union { > struct { > diff --git a/xen/arch/arm/include/asm/arm64/mpu.h b/xen/arch/arm/include/asm/arm64/mpu.h > index 4f694190a8..8b86a03fee 100644 > --- a/xen/arch/arm/include/asm/arm64/mpu.h > +++ b/xen/arch/arm/include/asm/arm64/mpu.h > @@ -7,6 +7,8 @@ > > #define MPU_REGION_RES0 (0xFFFFULL << 48) > > +#define VSCTLR_VMID_SHIFT 48 > + > /* Protection Region Base Address Register */ > typedef union { > struct __packed { > diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h b/xen/arch/arm/include/asm/arm64/sysregs.h > index 19d409d3eb..4ed8ac0440 100644 > --- a/xen/arch/arm/include/asm/arm64/sysregs.h > +++ b/xen/arch/arm/include/asm/arm64/sysregs.h > @@ -462,6 +462,11 @@ > #define ZCR_ELx_LEN_SIZE 9 > #define ZCR_ELx_LEN_MASK 0x1ff > > +/* Virtualization Secure Translation Control Register */ > +#define VSTCR_EL2_RES1_SHIFT 31 > +#define VSTCR_EL2_SA ~(_AC(0x1,UL)<<30) > +#define VSTCR_EL2_SC (_AC(0x1,UL)<<20) > + > #ifdef CONFIG_MPU > /* > * The Armv8-R AArch64 architecture always executes code in Secure > diff --git a/xen/arch/arm/include/asm/cpufeature.h b/xen/arch/arm/include/asm/cpufeature.h > index 13353c8e1a..677cb2b96d 100644 > --- a/xen/arch/arm/include/asm/cpufeature.h > +++ b/xen/arch/arm/include/asm/cpufeature.h > @@ -248,6 +248,12 @@ struct cpuinfo_arm { > unsigned long tgranule_16K:4; > unsigned long tgranule_64K:4; > unsigned long tgranule_4K:4; > +#if !defined(CONFIG_MMU) Why not #ifdef CONFIG_MPU here and elsewhere? > + unsigned long __res:16; If there are multiple RES0 fields, we usually start from __res0 and iterate the number with each occurence of RES0. ~Michal From xen-devel-bounces@lists.xenproject.org Tue Jan 27 10:19:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 10:19:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214169.1524537 (Exim 4.92) (envelope-from ) id 1vkgAZ-000491-Vn; Tue, 27 Jan 2026 10:19:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214169.1524537; Tue, 27 Jan 2026 10: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 1vkgAZ-00048u-T2; Tue, 27 Jan 2026 10:19:35 +0000 Received: by outflank-mailman (input) for mailman id 1214169; Tue, 27 Jan 2026 10:19: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 1vkgAY-00048o-Ho for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 10:19:34 +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 ac6856ae-fb69-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 11:19:33 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-47edd6111b4so62621405e9.1 for ; Tue, 27 Jan 2026 02:19:33 -0800 (PST) Received: from localhost.localdomain (host-92-22-18-152.as13285.net. [92.22.18.152]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066bf93cesm50065445e9.9.2026.01.27.02.18.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Jan 2026 02:19:05 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ac6856ae-fb69-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1769509172; x=1770113972; 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=gV4rnnSv2OTm/CHA9k4TvRRTSI/H5TfWuxCUjH6P6lQ=; b=XrWrYP2f3c3Q2BoPYo0t4qeLJG8QlKGBnuGjcwxlqkxubk+WrYDjGIeaMvhE3bX5xs lWBEqv0qUI40X/T5Z9Lwk1t3jf4uqlipfzHLhORtru9N/BkuXaOU09YkjsRlUFvvkdlV Tk2VHg1JoRLaHqQh3IQAxd0ywPGt9OdPhmvL4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769509172; x=1770113972; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gV4rnnSv2OTm/CHA9k4TvRRTSI/H5TfWuxCUjH6P6lQ=; b=iSgF13D28Q1KJjBNTwo8oznET0Z/pIOsmSOT5/YllnLkEfKbhbYiKEfE3f05laO2FQ 4Sk5A9tFPU84DtYibnQhQb0dwkhyf+B8DSGIHhq6AoW10iuGThP4EziM8hmGsf/vp/lx 1vVEz3/b5J/Pn9GZD7wEAGVf8MUP7NZ0ZqVOfU2NzQV4foDmK2NFjtFIFS/zlAAo92Rw I4bGj+BJSBjT/zvek0v/P5x3Psy8G14iFZB+vk4fTT7y0XPl1bw8WCq4AmD2vOl9hZnj pc27cCKGvJwJg5wZ+fmJNfTIr3C6Qc+3rB21v+E0w43DPMnX+oHONeUa4apCZr9nHkgq xisw== X-Gm-Message-State: AOJu0YxtCEHXmNqKLVsAy50wEVv7Uej8U5vlBVCtRG/v8uEgnB42eEwN tctMfVr0dHHnqmLZakyWh3fDDnEqr4q49ab3wzMN9n/zYyXixEaihT3N7gE1bMxgVFGhukqggaU Ixv+L X-Gm-Gg: AZuq6aLwI5/OiNn5O+HHrb6fssZKrTHbdvqbSaf/EJ9mMpAg9MFuUnNFIc4GS1rXwZh Qp2Nc/7I7iZRXT+2h04EOa/BI9yJVSzcQZ97sPbX3cK1AmhlQF11kTwY7ns7z/+kBLVPAWiJkq3 0S5hcZbwZVpkjOgZHJyp1lWpVb1A1PpzrAIA+t7k92jcPgnFox2azwFZ3x/P+qbMkQsqCi9sBED JGGzki1LXQALooSMBW5ufbfSuudPyI2utqWfBll731TI3fyxt0OiRsltz/R/NFMHurNEU3tIaVS A1i2Vi8ANKAV4fZyM43qzORsbdG+Do/Q+NU0kXPXOXHAZIaJpBkPJhR8d1s90VCMMqYDItKrEue Gxfi3+S/zNcPUHf4eUEzvwLDieny2We/G0y+PBcV5vt2y49LewhybAG4wOXmfNrtpGhumZ+Kpdu ia3II2g6660oF+un5WLXw6ZYghJ/zgNHpq3ty9FdGm7q7MY9Z15p7HtmhcI2s= X-Received: by 2002:a05:600c:450b:b0:477:63b5:7148 with SMTP id 5b1f17b1804b1-48069c0fd5amr15861325e9.6.1769509172308; Tue, 27 Jan 2026 02:19:32 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis Subject: [PATCH] xen/treewide: More typeof() -> auto conversions Date: Tue, 27 Jan 2026 10:18:41 +0000 Message-Id: <20260127101841.2213758-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 All of these are simple cases of using typeof() to avoid multiple parameter evaluation. Using auto avoids multiple textural expansion also. 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: Volodymyr Babchuk CC: Bertrand Marquis There's an oddity with SMCCC. 4 or fewer args strictly use unsigned long for ouput types where 5 or more use a dynamic type. I've left it as-was, but it looks wrong. https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2287583251 --- xen/arch/arm/include/asm/smccc.h | 26 +++---- xen/arch/x86/include/asm/alternative-call.h | 84 ++++++++++----------- xen/common/bitops.c | 2 +- xen/include/xen/bitops.h | 4 +- xen/include/xen/nospec.h | 4 +- xen/include/xen/self-tests.h | 4 +- 6 files changed, 62 insertions(+), 62 deletions(-) diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/smccc.h index 441b3ab65dee..29f1128bc283 100644 --- a/xen/arch/arm/include/asm/smccc.h +++ b/xen/arch/arm/include/asm/smccc.h @@ -129,7 +129,7 @@ struct arm_smccc_res { register unsigned long r3 ASM_REG(3) #define __declare_arg_1(a0, a1, res) \ - typeof(a1) __a1 = (a1); \ + auto __a1 = (a1); \ struct arm_smccc_res *___res = (res); \ register unsigned long r0 ASM_REG(0) = (uint32_t)(a0); \ register unsigned long r1 ASM_REG(1) = __a1; \ @@ -137,8 +137,8 @@ struct arm_smccc_res { register unsigned long r3 ASM_REG(3) #define __declare_arg_2(a0, a1, a2, res) \ - typeof(a1) __a1 = (a1); \ - typeof(a2) __a2 = (a2); \ + auto __a1 = (a1); \ + auto __a2 = (a2); \ struct arm_smccc_res *___res = (res); \ register unsigned long r0 ASM_REG(0) = (uint32_t)(a0); \ register unsigned long r1 ASM_REG(1) = __a1; \ @@ -146,9 +146,9 @@ struct arm_smccc_res { register unsigned long r3 ASM_REG(3) #define __declare_arg_3(a0, a1, a2, a3, res) \ - typeof(a1) __a1 = (a1); \ - typeof(a2) __a2 = (a2); \ - typeof(a3) __a3 = (a3); \ + auto __a1 = (a1); \ + auto __a2 = (a2); \ + auto __a3 = (a3); \ struct arm_smccc_res *___res = (res); \ register unsigned long r0 ASM_REG(0) = (uint32_t)(a0); \ register unsigned long r1 ASM_REG(1) = __a1; \ @@ -156,24 +156,24 @@ struct arm_smccc_res { register unsigned long r3 ASM_REG(3) = __a3 #define __declare_arg_4(a0, a1, a2, a3, a4, res) \ - typeof(a4) __a4 = (a4); \ + auto __a4 = (a4); \ __declare_arg_3(a0, a1, a2, a3, res); \ register unsigned long r4 ASM_REG(4) = __a4 #define __declare_arg_5(a0, a1, a2, a3, a4, a5, res) \ - typeof(a5) __a5 = (a5); \ + auto __a5 = (a5); \ __declare_arg_4(a0, a1, a2, a3, a4, res); \ - register typeof(a5) r5 ASM_REG(5) = __a5 + register auto r5 ASM_REG(5) = __a5 #define __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res) \ - typeof(a6) __a6 = (a6); \ + auto __a6 = (a6); \ __declare_arg_5(a0, a1, a2, a3, a4, a5, res); \ - register typeof(a6) r6 ASM_REG(6) = __a6 + register auto r6 ASM_REG(6) = __a6 #define __declare_arg_7(a0, a1, a2, a3, a4, a5, a6, a7, res) \ - typeof(a7) __a7 = (a7); \ + auto __a7 = (a7); \ __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res); \ - register typeof(a7) r7 ASM_REG(7) = __a7 + register auto r7 ASM_REG(7) = __a7 #define ___declare_args(count, ...) __declare_arg_ ## count(__VA_ARGS__) #define __declare_args(count, ...) ___declare_args(count, __VA_ARGS__) diff --git a/xen/arch/x86/include/asm/alternative-call.h b/xen/arch/x86/include/asm/alternative-call.h index b22c10c32283..27024797f584 100644 --- a/xen/arch/x86/include/asm/alternative-call.h +++ b/xen/arch/x86/include/asm/alternative-call.h @@ -111,7 +111,7 @@ struct alt_call { }) #define alternative_vcall1(func, arg) ({ \ - typeof(arg) v1_ = (arg); \ + auto v1_ = (arg); \ ALT_CALL_ARG(v1_, 1); \ ALT_CALL_NO_ARG2; \ (void)sizeof(func(arg)); \ @@ -119,15 +119,15 @@ struct alt_call { }) #define alternative_call1(func, arg) ({ \ - typeof(arg) v1_ = (arg); \ + auto v1_ = (arg); \ ALT_CALL_ARG(v1_, 1); \ ALT_CALL_NO_ARG2; \ alternative_callN(1, typeof(func(arg)), func); \ }) #define alternative_vcall2(func, arg1, arg2) ({ \ - typeof(arg1) v1_ = (arg1); \ - typeof(arg2) v2_ = (arg2); \ + auto v1_ = (arg1); \ + auto v2_ = (arg2); \ ALT_CALL_ARG(v1_, 1); \ ALT_CALL_ARG(v2_, 2); \ ALT_CALL_NO_ARG3; \ @@ -136,8 +136,8 @@ struct alt_call { }) #define alternative_call2(func, arg1, arg2) ({ \ - typeof(arg1) v1_ = (arg1); \ - typeof(arg2) v2_ = (arg2); \ + auto v1_ = (arg1); \ + auto v2_ = (arg2); \ ALT_CALL_ARG(v1_, 1); \ ALT_CALL_ARG(v2_, 2); \ ALT_CALL_NO_ARG3; \ @@ -145,9 +145,9 @@ struct alt_call { }) #define alternative_vcall3(func, arg1, arg2, arg3) ({ \ - typeof(arg1) v1_ = (arg1); \ - typeof(arg2) v2_ = (arg2); \ - typeof(arg3) v3_ = (arg3); \ + auto v1_ = (arg1); \ + auto v2_ = (arg2); \ + auto v3_ = (arg3); \ ALT_CALL_ARG(v1_, 1); \ ALT_CALL_ARG(v2_, 2); \ ALT_CALL_ARG(v3_, 3); \ @@ -157,9 +157,9 @@ struct alt_call { }) #define alternative_call3(func, arg1, arg2, arg3) ({ \ - typeof(arg1) v1_ = (arg1); \ - typeof(arg2) v2_ = (arg2); \ - typeof(arg3) v3_ = (arg3); \ + auto v1_ = (arg1); \ + auto v2_ = (arg2); \ + auto v3_ = (arg3); \ ALT_CALL_ARG(v1_, 1); \ ALT_CALL_ARG(v2_, 2); \ ALT_CALL_ARG(v3_, 3); \ @@ -169,10 +169,10 @@ struct alt_call { }) #define alternative_vcall4(func, arg1, arg2, arg3, arg4) ({ \ - typeof(arg1) v1_ = (arg1); \ - typeof(arg2) v2_ = (arg2); \ - typeof(arg3) v3_ = (arg3); \ - typeof(arg4) v4_ = (arg4); \ + auto v1_ = (arg1); \ + auto v2_ = (arg2); \ + auto v3_ = (arg3); \ + auto v4_ = (arg4); \ ALT_CALL_ARG(v1_, 1); \ ALT_CALL_ARG(v2_, 2); \ ALT_CALL_ARG(v3_, 3); \ @@ -183,10 +183,10 @@ struct alt_call { }) #define alternative_call4(func, arg1, arg2, arg3, arg4) ({ \ - typeof(arg1) v1_ = (arg1); \ - typeof(arg2) v2_ = (arg2); \ - typeof(arg3) v3_ = (arg3); \ - typeof(arg4) v4_ = (arg4); \ + auto v1_ = (arg1); \ + auto v2_ = (arg2); \ + auto v3_ = (arg3); \ + auto v4_ = (arg4); \ ALT_CALL_ARG(v1_, 1); \ ALT_CALL_ARG(v2_, 2); \ ALT_CALL_ARG(v3_, 3); \ @@ -198,11 +198,11 @@ struct alt_call { }) #define alternative_vcall5(func, arg1, arg2, arg3, arg4, arg5) ({ \ - typeof(arg1) v1_ = (arg1); \ - typeof(arg2) v2_ = (arg2); \ - typeof(arg3) v3_ = (arg3); \ - typeof(arg4) v4_ = (arg4); \ - typeof(arg5) v5_ = (arg5); \ + auto v1_ = (arg1); \ + auto v2_ = (arg2); \ + auto v3_ = (arg3); \ + auto v4_ = (arg4); \ + auto v5_ = (arg5); \ ALT_CALL_ARG(v1_, 1); \ ALT_CALL_ARG(v2_, 2); \ ALT_CALL_ARG(v3_, 3); \ @@ -214,11 +214,11 @@ struct alt_call { }) #define alternative_call5(func, arg1, arg2, arg3, arg4, arg5) ({ \ - typeof(arg1) v1_ = (arg1); \ - typeof(arg2) v2_ = (arg2); \ - typeof(arg3) v3_ = (arg3); \ - typeof(arg4) v4_ = (arg4); \ - typeof(arg5) v5_ = (arg5); \ + auto v1_ = (arg1); \ + auto v2_ = (arg2); \ + auto v3_ = (arg3); \ + auto v4_ = (arg4); \ + auto v5_ = (arg5); \ ALT_CALL_ARG(v1_, 1); \ ALT_CALL_ARG(v2_, 2); \ ALT_CALL_ARG(v3_, 3); \ @@ -231,12 +231,12 @@ struct alt_call { }) #define alternative_vcall6(func, arg1, arg2, arg3, arg4, arg5, arg6) ({ \ - typeof(arg1) v1_ = (arg1); \ - typeof(arg2) v2_ = (arg2); \ - typeof(arg3) v3_ = (arg3); \ - typeof(arg4) v4_ = (arg4); \ - typeof(arg5) v5_ = (arg5); \ - typeof(arg6) v6_ = (arg6); \ + auto v1_ = (arg1); \ + auto v2_ = (arg2); \ + auto v3_ = (arg3); \ + auto v4_ = (arg4); \ + auto v5_ = (arg5); \ + auto v6_ = (arg6); \ ALT_CALL_ARG(v1_, 1); \ ALT_CALL_ARG(v2_, 2); \ ALT_CALL_ARG(v3_, 3); \ @@ -248,12 +248,12 @@ struct alt_call { }) #define alternative_call6(func, arg1, arg2, arg3, arg4, arg5, arg6) ({ \ - typeof(arg1) v1_ = (arg1); \ - typeof(arg2) v2_ = (arg2); \ - typeof(arg3) v3_ = (arg3); \ - typeof(arg4) v4_ = (arg4); \ - typeof(arg5) v5_ = (arg5); \ - typeof(arg6) v6_ = (arg6); \ + auto v1_ = (arg1); \ + auto v2_ = (arg2); \ + auto v3_ = (arg3); \ + auto v4_ = (arg4); \ + auto v5_ = (arg5); \ + auto v6_ = (arg6); \ ALT_CALL_ARG(v1_, 1); \ ALT_CALL_ARG(v2_, 2); \ ALT_CALL_ARG(v3_, 3); \ diff --git a/xen/common/bitops.c b/xen/common/bitops.c index e46ea1d3ecf8..859a4ca5c131 100644 --- a/xen/common/bitops.c +++ b/xen/common/bitops.c @@ -147,7 +147,7 @@ static void __init test_for_each_set_bit(void) * A copy of @val is taken internally. */ #define for_each_set_bit_reverse(iter, val) \ - for ( typeof(val) __v = (val); __v; __v = 0 ) \ + for ( auto __v = (val); __v; __v = 0 ) \ for ( unsigned int (iter); \ __v && ((iter) = fls_g(__v) - 1, true); \ __clear_bit(iter, &__v) ) diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h index a4d31ec02a7c..24882fb4822d 100644 --- a/xen/include/xen/bitops.h +++ b/xen/include/xen/bitops.h @@ -299,7 +299,7 @@ static always_inline attr_const unsigned int fls64(uint64_t x) * A copy of @val is taken internally. */ #define for_each_set_bit(iter, val) \ - for ( typeof(val) __v = (val); __v; __v = 0 ) \ + for ( auto __v = (val); __v; __v = 0 ) \ for ( unsigned int (iter); \ __v && ((iter) = ffs_g(__v) - 1, true); \ __v &= __v - 1 ) @@ -310,7 +310,7 @@ static always_inline attr_const unsigned int fls64(uint64_t x) */ #define multiple_bits_set(x) \ ({ \ - typeof(x) _v = (x); \ + auto _v = (x); \ (_v & (_v - 1)) != 0; \ }) diff --git a/xen/include/xen/nospec.h b/xen/include/xen/nospec.h index c8167a8a245c..0e474145b476 100644 --- a/xen/include/xen/nospec.h +++ b/xen/include/xen/nospec.h @@ -51,8 +51,8 @@ static inline unsigned long array_index_mask_nospec(unsigned long index, */ #define array_index_nospec(index, size) \ ({ \ - typeof(index) _i = (index); \ - typeof(size) _s = (size); \ + auto _i = (index); \ + auto _s = (size); \ unsigned long _mask = array_index_mask_nospec(_i, _s); \ \ BUILD_BUG_ON(sizeof(_i) > sizeof(long)); \ diff --git a/xen/include/xen/self-tests.h b/xen/include/xen/self-tests.h index c57cceb3b962..c4937e781f66 100644 --- a/xen/include/xen/self-tests.h +++ b/xen/include/xen/self-tests.h @@ -18,7 +18,7 @@ */ #define COMPILE_CHECK(fn, val, res) \ do { \ - typeof(fn(val)) real = fn(val); \ + auto real = fn(val); \ \ if ( !__builtin_constant_p(real) ) \ BUILD_ERROR("'" STR(fn(val)) "' not compile-time constant"); \ @@ -36,7 +36,7 @@ */ #define RUNTIME_CHECK(fn, val, res) \ do { \ - typeof(fn(val)) real = fn(HIDE(val)); \ + auto real = fn(HIDE(val)); \ \ if ( real != (res) ) \ panic("%s: %s(%s) expected %u, got %u\n", \ -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Tue Jan 27 10:21:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 10:21:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214179.1524548 (Exim 4.92) (envelope-from ) id 1vkgC8-0005Zz-9V; Tue, 27 Jan 2026 10:21:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214179.1524548; Tue, 27 Jan 2026 10:21: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 1vkgC8-0005Zs-6W; Tue, 27 Jan 2026 10:21:12 +0000 Received: by outflank-mailman (input) for mailman id 1214179; Tue, 27 Jan 2026 10:21: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 1vkgC7-0005Zm-0x for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 10:21:11 +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 e5390441-fb69-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 11:21:08 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-4801eb2c0a5so53726905e9.3 for ; Tue, 27 Jan 2026 02:21:08 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1c24a8asm36782834f8f.12.2026.01.27.02.21.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 02:21:07 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e5390441-fb69-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769509268; x=1770114068; 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=qvOM98ARq7BtgTvs6SHEfsNaOCEcKGRIgkInqDxK0Ks=; b=fgaXjonolvtKagkchKilWfZ75Yis23pRqp2V319961nzV1cnSkdovVH1bbBi97v3d5 EVNA/W8xuEDwU0g4eUeOIHAec9NUuNwSQJnfenWQ2OKtayaMcPa9ufdezcMu2WJESv5h V1kUcR2+jbCWtFzYBQdsL8TLrbQKh6YmpBrYJFJ2sBZFdJf2fSVCpxToXKeBvAOvq1ms YqC1itfTH6eA8s2j7BppSUPGPKVlxdAwipoGB9GxP9aZpxhWc0UO1f0U6vG7I4nPDJA8 Y7EwHK/acIWKKUDBMwTE8YcSI1MRsobDLHU8ayEIQCSpKpATCbDom9dWUKac8a0LiwLY 6EYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769509268; x=1770114068; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qvOM98ARq7BtgTvs6SHEfsNaOCEcKGRIgkInqDxK0Ks=; b=sQb62Kxv9KVNXcIrTraka4rGHx00DtZQE8a+fMJmW68eMqljFT+AkZA8Lm3v8CauM1 L6fYegn39/0ILloJvgWd7vB962l4fYCsPbDW/+tlddKHrT6RD48PH2kryjvQ1C/lL29Q ZVmgshg949ukf0ZKJn0f+77NtsAVBYOvXT7rq47F3yWSmVBFQkET+9wisSP1wUiJszVA F03T+t82rFxK7ksQ4wfOvPwWAvfj2NkIZJ8gqlq3Pm1daO4BS7ZYPXSrVh1Bu5tHQiwT 4i1TY+JHATEK/gyXkNLseyOGI1y0gOTKoWEbJGmsSLFOr+uCcTEoTXq79DTwpXfCqDmJ 4HgA== X-Gm-Message-State: AOJu0Yyp6WtAXt64UStZLJIu9hiKo0xqYdH1fvBbDdivCXvBEUhBtHoS RgzoRxUMJFwkd+QsuK7k93XkRIyksvXpqrNJTzhJgOJDkbSt2Hg9a6lRqWOIobHuPkX53SWX8Eh zKIE= X-Gm-Gg: AZuq6aK9/2yL4b5nTYRiimY7X7GDXsSbXtncjiXuibUSOvmRU91LnLYyhOfeASP4ewo O8DrYawy8blfVsUpu4gFhmVPYZ+n6BsyALlDbogtCS/vSxWbH0a/UzcUqTANcURblJOAYHH+XEJ mRMa5ClmOP8cE+I1awUXvRzY5gCX5LF/eXvacZcsp9y/s+4dEbX5wuaPKGLkUHDqkLz8m04sDAY o4oJuno8xWpDmRkPAqfHaNGhTxw0osWmLbkIXB7YiHZkrljpEzd3NDZhoybjphOYVL4rg40m7/Y x8sVBX+Ot0M4zg1dDERY+gGi6ozOAOqWwkJHxTuU8CevsDYTEEY/ek8ExOki3zGhHvViSLFpCbO a3rnZ4aXhltaLl9mLrkWZo7vf9fPYPBXbPNVytrhnkUiPbJaf3BUu9jAef3K71J+XSzHYRDyfuf 6ESx/ff/GEQ6jS99Fi9a7mgWpVOB0aIfFUU2moS8mrseMojRZZHpMYtdYoG2DcypUxLDicpQqTl H4= X-Received: by 2002:a05:600d:15a:20b0:47e:c562:a41f with SMTP id 5b1f17b1804b1-48069c55790mr11947965e9.18.1769509267792; Tue, 27 Jan 2026 02:21:07 -0800 (PST) Message-ID: <7987f1fc-5b5e-40c6-866e-ac332097c635@suse.com> Date: Tue, 27 Jan 2026 11:21:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH] x86emul: allow ->write_msr() to distinguish origins of writes Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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 Only explicit writes are subject to e.g. the checking of the MSR intercept bitmap, which extends to VM-event's hvm_monitor_msr(). Indicate, by way of a new boolean parameter, to the hook functions which variant it is. Fixes: 6eb43fcf8a0b ("x86emul: support SWAPGS") Reported-by: Andrew Cooper Signed-off-by: Jan Beulich --- Later, in particular for nested, ->read_msr() may need to gain a similar parameter. Prior to nested making use of it, the new parameter is effectively dead code with VM_EVENT=n. If we accepted Misra rule 2.2, something would likely need doing about this. I've suitably re-based "x86emul: misc additions" on top of this, but I don't think I'll re-post it just for that. --- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c +++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c @@ -569,7 +569,8 @@ static int fuzz_read_msr( static int fuzz_write_msr( unsigned int reg, uint64_t val, - struct x86_emulate_ctxt *ctxt) + struct x86_emulate_ctxt *ctxt, + bool explicit) { struct fuzz_state *s = ctxt->data; struct fuzz_corpus *c = s->corpus; --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -1705,7 +1705,8 @@ static int cf_check hvmemul_write_io_dis static int cf_check hvmemul_write_msr_discard( unsigned int reg, uint64_t val, - struct x86_emulate_ctxt *ctxt) + struct x86_emulate_ctxt *ctxt, + bool explicit) { return X86EMUL_OKAY; } @@ -2427,9 +2428,10 @@ static int cf_check hvmemul_read_msr( static int cf_check hvmemul_write_msr( unsigned int reg, uint64_t val, - struct x86_emulate_ctxt *ctxt) + struct x86_emulate_ctxt *ctxt, + bool explicit) { - int rc = hvm_msr_write_intercept(reg, val, true); + int rc = hvm_msr_write_intercept(reg, val, explicit); if ( rc == X86EMUL_EXCEPTION ) x86_emul_hw_exception(X86_EXC_GP, 0, ctxt); --- a/xen/arch/x86/pv/emul-priv-op.c +++ b/xen/arch/x86/pv/emul-priv-op.c @@ -1038,7 +1038,8 @@ static int cf_check read_msr( } static int cf_check write_msr( - unsigned int reg, uint64_t val, struct x86_emulate_ctxt *ctxt) + unsigned int reg, uint64_t val, struct x86_emulate_ctxt *ctxt, + bool explicit) { struct vcpu *curr = current; const struct domain *currd = curr->domain; --- a/xen/arch/x86/x86_emulate/0f01.c +++ b/xen/arch/x86/x86_emulate/0f01.c @@ -40,7 +40,7 @@ int x86emul_0f01(struct x86_emulate_stat fail_if(!ops->write_msr); rc = ops->write_msr(regs->ecx, ((uint64_t)regs->r(dx) << 32) | regs->eax, - ctxt); + ctxt, true); goto done; } generate_exception(X86_EXC_UD); @@ -194,7 +194,7 @@ int x86emul_0f01(struct x86_emulate_stat (rc = ops->read_msr(MSR_SHADOW_GS_BASE, &msr_val, ctxt)) != X86EMUL_OKAY || (rc = ops->write_msr(MSR_SHADOW_GS_BASE, sreg.base, - ctxt)) != X86EMUL_OKAY ) + ctxt, false)) != X86EMUL_OKAY ) goto done; sreg.base = msr_val; if ( (rc = ops->write_segment(x86_seg_gs, &sreg, @@ -202,7 +202,7 @@ int x86emul_0f01(struct x86_emulate_stat { /* Best effort unwind (i.e. no real error checking). */ if ( ops->write_msr(MSR_SHADOW_GS_BASE, msr_val, - ctxt) == X86EMUL_EXCEPTION ) + ctxt, false) == X86EMUL_EXCEPTION ) x86_emul_reset_event(ctxt); goto done; } --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -3814,7 +3814,7 @@ x86_emulate( fail_if(ops->write_msr == NULL); if ( (rc = ops->write_msr(_regs.ecx, ((uint64_t)_regs.r(dx) << 32) | _regs.eax, - ctxt)) != 0 ) + ctxt, true)) != 0 ) goto done; break; --- a/xen/arch/x86/x86_emulate/x86_emulate.h +++ b/xen/arch/x86/x86_emulate/x86_emulate.h @@ -470,13 +470,15 @@ struct x86_emulate_ops struct x86_emulate_ctxt *ctxt); /* - * write_dr: Write to model-specific register. - * @reg: [IN ] Register to write. + * write_msr: Write to model-specific register. + * @reg: [IN ] Register to write. + * @explicit: [IN ] Whether this is an explicit WRMSR or alike. */ int (*write_msr)( unsigned int reg, uint64_t val, - struct x86_emulate_ctxt *ctxt); + struct x86_emulate_ctxt *ctxt, + bool explicit); /* * cache_op: Write-back and/or invalidate cache contents. From xen-devel-bounces@lists.xenproject.org Tue Jan 27 10:23:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 10:23:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214195.1524562 (Exim 4.92) (envelope-from ) id 1vkgEn-0006Du-QE; Tue, 27 Jan 2026 10:23:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214195.1524562; Tue, 27 Jan 2026 10:23:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkgEn-0006Dn-NL; Tue, 27 Jan 2026 10:23:57 +0000 Received: by outflank-mailman (input) for mailman id 1214195; Tue, 27 Jan 2026 10:23: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 1vkgEm-0006Df-9h for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 10:23:56 +0000 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [2a00:1450:4864:20::336]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 480b1597-fb6a-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 11:23:54 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-47edffe5540so62432885e9.0 for ; Tue, 27 Jan 2026 02:23:54 -0800 (PST) Received: from localhost.localdomain (host-92-22-18-152.as13285.net. [92.22.18.152]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066bfb59asm48076315e9.7.2026.01.27.02.23.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Jan 2026 02:23:52 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 480b1597-fb6a-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1769509433; x=1770114233; 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=2EyqDzI0V7oMUtLHM/UiWRdLKUFBWys8yFg5YHHHO60=; b=tIGU5v9PP1i4Vxp0h/t+QIbhGSPGYboK7rs4aVu0U8XkcmJzuqV8Jj6ZP4Rkrn27De ZY5NLQS+dNxvzvRsXI8OJyQ9z7KDp23zCoxDp83UCLCc17OlqAQ9a1aifjgbYdMuGu4q hNsLy1ZV4N8954JUKKLBPrxf3uesE6gw15xiU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769509433; x=1770114233; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2EyqDzI0V7oMUtLHM/UiWRdLKUFBWys8yFg5YHHHO60=; b=JFJH5J8QU3MM9CYIU6Vw2Ydj+dAqghYhVISr1UR+W0tdmUYYkKitb4rzW31Zgqic9m QhsQfVbI5HSJYXvXOh8fxmou68oq5Z0AMl6JYoF1fFNtOO+4VHw5HOaKZoaMEE63WO3Q xDKtqKXKsfKKLnU7JIVKmYvFuzYevPkacJ+Qdy25dD+EXyakd4WmXw5bvRjSF/1bGwAy iwsm/8kW2nCpYsvIJ5LjxMEj5gorDggH82+FbC3SxY7xwwgUX7g78t7Aq2SZUUvdFHM4 k2wAan4KG2l7C0Hx7NYk7UuqoaYfp3ZKzv2eMSrGKY4l7zzQXoc7qLI+j8tN3OaoXQ01 AxLA== X-Gm-Message-State: AOJu0YxkyTyQRDyWZ/cru2fMi7LPlXYEU1HcUZU9jMVeiF+i+3ItDfK4 rKGz5OpHFTemeDGPTpF+gnaaSlhMVnehLrnDUfSgfEL1PL0Ni9nCqvy2dFWcJOCcr351ALDlJ0b yayWn X-Gm-Gg: AZuq6aJiTnQHKXZZDx9+pGXnLxa8vEEpL3JnWule6g2n6pEDwMhHJY12oP2zKfBatIc SnAvjMB30zWaSXLDUTq6j7xzuU3b21rZ6XaIvGOACqgYprgTfRdPKQerrP15Tw/rbLMX9iiy1C0 vUMwFZ0OeBFGP/3oB/t4G+vyquAZjKgUHtR0+wb9hoaY4Wr95SSmAXfAVN45bBmbn8koq7vu70p pVbRFBtgf9pRZQOn1qJrJ/g1/VyjDR1cgEgkmlz0QP1+VJPsemjx8yrMqXOuwWZW0Ah/TVMinZ1 v5N597SSQBxm3zcNIZyfcPWDMX4aPC8LzQfD4mBDa8gNpcuvRoQUZ1p2Spx/xFJ48b56XymDHDQ fcjzqKd+V3M2rjBYGZubUieSBpGFT14vfTtDz9mJHNExkGWY18HtgMd+OoNRfdkUt7MxJeKO8wQ nqG7A1mwRDp4yCYA0SgleW5AamWJzMst5Zn6WMU+igtDdyMMSFYp4WmVESOaY= X-Received: by 2002:a05:600c:450b:b0:477:76bf:e1fb with SMTP id 5b1f17b1804b1-48069c21c40mr17104315e9.16.1769509433340; Tue, 27 Jan 2026 02:23:53 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH] x86/cmpxchg: Add safety for bad sizes Date: Tue, 27 Jan 2026 10:23:51 +0000 Message-Id: <20260127102351.2215346-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 All other architectures helpers have safey against passing a bad size, but the x86 forms did not. For __xchg(), use DCE against a function which doesn't exist. For hvmemul_cmpxchg() this doesn't work as the size is a parameter rather than known at compile time. Use BUG() to detect runtime malfunctions. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné bloat-o-meter reports: Function old new delta hvmemul_cmpxchg 1116 1092 -24 which is surely down to the hidden __builtin_unreachable() causing some codepaths to be omitted. --- xen/arch/x86/include/asm/system.h | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/xen/arch/x86/include/asm/system.h b/xen/arch/x86/include/asm/system.h index 6c2800d8158d..1074786a9d23 100644 --- a/xen/arch/x86/include/asm/system.h +++ b/xen/arch/x86/include/asm/system.h @@ -36,6 +36,8 @@ static inline void clwb(const void *p) #include +extern unsigned long __bad_xchg_size(void); + /* * Note: no "lock" prefix even on SMP: xchg always implies lock anyway * Note 2: xchg has side effect, so that attribute volatile is necessary, @@ -66,6 +68,8 @@ static always_inline unsigned long __xchg( : [x] "+r" (x), [ptr] "+m" (*(volatile uint64_t *)ptr) :: "memory" ); break; + default: + __bad_xchg_size(); } return x; } @@ -106,6 +110,8 @@ static always_inline unsigned long __cmpxchg( : [new] "r" (new), "a" (old) : "memory" ); return prev; + default: + BUG(); } return old; } @@ -137,6 +143,8 @@ static always_inline unsigned long cmpxchg_local_( : "=a" (prev), [ptr] "+m" (*(uint64_t *)ptr) : [new] "r" (new), "a" (old) ); break; + default: + BUG(); } return prev; -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Tue Jan 27 10:38:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 10:38:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214204.1524571 (Exim 4.92) (envelope-from ) id 1vkgSG-00083J-V0; Tue, 27 Jan 2026 10:37:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214204.1524571; Tue, 27 Jan 2026 10: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 1vkgSG-00083C-SL; Tue, 27 Jan 2026 10:37:52 +0000 Received: by outflank-mailman (input) for mailman id 1214204; Tue, 27 Jan 2026 10:37: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 1vkgSG-000836-7y for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 10:37:52 +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 3a0ca0ff-fb6c-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 11:37:49 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-47fedb7c68dso55637735e9.2 for ; Tue, 27 Jan 2026 02:37:49 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804d3ac45bsm129359875e9.0.2026.01.27.02.37.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 02:37:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3a0ca0ff-fb6c-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769510269; x=1770115069; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=DCs8nzhL5+toIKmoyD+H4086OE2QwpIqGtymOs/bEew=; b=A4NhYoAr98/rHzdVAym5UXW13kTgzb8Apf3/yQ8jNOIyueXK5MieNc2Ba88Ik2Fxd3 28PsBGQEvhZBJE8JSTZgAoLGT6TDyCmt85JTH3aORXSBtlG7xiLWLaH38au2GDO3hWdO urzQMap2Q9OBNvNv1/sBXzkxzf99fjQdVHrOY/RCetgr9vKM/M/lGJkMKsCvpB0sDJOh vkgIyh011bG1ZM95tvazAq+JKYEBLimbbvCLPC7ztd4wxza8l3O/YF57r63YtcegAL1F 5Tfx03WLLOcpGetDaqGTmhEWE1hSGVCiqXHYb+8DXIUsWHOOrh2SnobVOmXWMaxid/a0 +41w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769510269; x=1770115069; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=DCs8nzhL5+toIKmoyD+H4086OE2QwpIqGtymOs/bEew=; b=Vu6v6e04W0RBUck3lhWKpVevtJwNvuQYuXvwUbK0qTXgp97IN+3uTslf7qTZabIJOy cdYUF/08EPHeROb/qVtBMcljO1TgxKn+HYLPLZJkQOKZgIYDqKMaTRpGHhpPuwf0f7Ic wLSSFTn+k7LzSQJpkxyk6u8jmAxAJpikKdT5KD3WjNAeDFGuKjQqlpehb7I2baQ6hJFw z/GB402oC66IIuJHkuNxO/XIPXorBkJgcANLHO7T5wYLmFptSc1QzJix2Qv575W058Ej TbuYiYI3fg6u5OrpfgyZDMZpOp++8BGxXNACwANmLczbnuARG2XnelB8VEN4njaWhPQM 8hYQ== X-Forwarded-Encrypted: i=1; AJvYcCVTSZT29U0tEep/o325uZRqSJO9/FlDayXDKfFulFPQdJpaekkfOzFELJiuLQAmW6rZ+0tjeIAQE18=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzwy2SYH5sClzW/05SYw2vtTMc2n7U2Q753DNBRbHgHQNMXm3UF lQVYuCxOXH+mSYMhnpWKf7Va11UTacLVpQ5pDy2kQlSStrmb6xIpVAsjgKsBH+4DVQ== X-Gm-Gg: AZuq6aKn94t8EUazkNeo5ho0Qh0sJ2suWm2SiyX46Q0nufFgaDhha7umAoNaP+mrPDF wMeZkjD+1MeP70Q0pquULwQiO/5D53oqEG/OS3HHMQa099EmWXGVNGvn5arjXFbdeZabUza1+u9 Mn6R3b02RmDrkuTSEExrb8R2TSLDQUoFYU6FMZ3s2T1viZDEOegjjs9CqMgP+ssRZ818I/4O7oB zqOD9SnK8frHtkswazI/EXaH/MhKiEp1NniBskRCPUcOqL4A+7dtI9fMzW4InnSM5ri5FyAiBOB klYQlVinFx5EmOnT9zk+LelxR2Rhv7vX/f7AdIT7DCsIiPBoi+fvUxMHqIWXtbg+VdtR++baBIi iIugCXnTlULsstqE6QZ8LmgOPV0KheAkZk83DA14xtpmap5qe+2xYIRDV489uB8deSai86KFD0/ gVpnaDHzFnc5fTuJ+baYjmTU8S2lnNJfdPqBCu87R53OQ4WP9veeHQKpzZAPs6yzeURJJ8inBfh 2E= X-Received: by 2002:a05:600c:608e:b0:480:1b1a:5526 with SMTP id 5b1f17b1804b1-48069c167d2mr18327175e9.16.1769510269195; Tue, 27 Jan 2026 02:37:49 -0800 (PST) Message-ID: <15978c88-5ea9-4159-951b-27c9fc004756@suse.com> Date: Tue, 27 Jan 2026 11:37:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 01/16] x86/cpu: Fix boot time cache flushing To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-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: <20260126175345.2078371-2-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.01.2026 18:53, Andrew Cooper wrote: > --- a/xen/arch/x86/cpu/common.c > +++ b/xen/arch/x86/cpu/common.c > @@ -319,8 +319,6 @@ void __init early_cpu_init(bool verbose) > uint64_t val; > u32 eax, ebx, ecx, edx; > > - c->x86_cache_alignment = 32; > - > /* Get vendor name */ > cpuid(0x00000000, &c->cpuid_level, &ebx, &ecx, &edx); > *(u32 *)&c->x86_vendor_id[0] = ebx; > @@ -352,6 +350,7 @@ void __init early_cpu_init(bool verbose) > if (edx & cpufeat_mask(X86_FEATURE_CLFLUSH)) { > unsigned int size = ((ebx >> 8) & 0xff) * 8; > > + c->x86_clflush_size = size; > c->x86_cache_alignment = size; With this change, can't the writing of the field in generic_identify() go away? CPU_DATA_INIT() in particular doesn't invalidate it. Perferably with that dropped (unless of course there is a reason not to): Reviewed-by: Jan Beulich Tangentially, "cpuid=no-clflush" didn't have any effect on any of this so far, and also isn't going to have with the changes you make. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 10:40:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 10:40:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214217.1524582 (Exim 4.92) (envelope-from ) id 1vkgUl-00017p-Ba; Tue, 27 Jan 2026 10:40:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214217.1524582; Tue, 27 Jan 2026 10:40: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 1vkgUl-00017i-8I; Tue, 27 Jan 2026 10:40:27 +0000 Received: by outflank-mailman (input) for mailman id 1214217; Tue, 27 Jan 2026 10:40: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 1vkgUk-00017c-Ck for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 10:40:26 +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 95ad7f77-fb6c-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 11:40:25 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by IA3PR03MB8406.namprd03.prod.outlook.com (2603:10b6:208:542::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Tue, 27 Jan 2026 10:40:22 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.010; Tue, 27 Jan 2026 10:40: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: 95ad7f77-fb6c-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=U9JAx/vsze2bFbi2jfCX1E0wLL/eHUCXfwEnd0n5e0bQKdJvBq0gAz+6zI3tLdARG7VhUNmI3AXlIAFCbCEZqKkOX6FVTPppLgB5zsksTrrbnfX21Xd7RAcPR7zLBWZj8I/piq5qALLOPPtZCrs+ysXMQuBNrclJiyBbu/HETGTsk+5Lx3H/fAHXUtfwUo3tKGKVEjdpC+zvx6jnRzJj3pEYODNM7xoHq7dSOdsox2dUiSa6v/mD2AsG7Re5BT5/AJIHzTNfpCycPFDUgZsTM9hX8DK4eQz6bS55O3gyaP9iQiXAlmu/A3rgGjzwAK+KdJDghshW1vxbS9JscKgCCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fZb43UkEFKzAf/y+8zfWgxfPyxcC3AZodvlckXgGG/M=; b=g4FL6iU4Vwl4KFq/icwgTkZ1zuFquw4Wmnd+xavKD6vA4zF/4E15LbC9AYcYCEFCqukzMvT9JdysB9/tivFJxHcC15ZYIQSnMBWRHlf/hUntS/RqQx6OEhdYm9BgFerYaP7wmVqiO/88m6PQjmwP1kJRB41m5Cmw6Rc6J3N33rhyr9fujMgRjxTGtyTVBtveoZzSoPppwsAM2bozFylQP47gBh+kuycbaZuz3G3OrmzLEV7M/ZO1R4TwRz9sxUxCuWSrPt54g+/aa4XgTUqro7T1EI0fVcX2Vu6UMxcTsU5SO2sXNk0FyXRBeEIuqpzqO0ijqkP4FavwXILq6UHoYw== 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=fZb43UkEFKzAf/y+8zfWgxfPyxcC3AZodvlckXgGG/M=; b=S2FNvWkBlCuciWjz4BpRJw/3lA1lEB1WkXj0IOy+15nO+o8P7svaH6DHoZCLS8tNAqMBgis3XCAZT0Gtv0spnCO0Ak2rPhVp9OWZZKMAds+AiZmgz5J7KcJPY7NvMuVNstH+YdTmtu442LSBAKsrHF6T4zG0iDy8HTf3+sTaLIc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Tue, 27 Jan 2026 11:40:17 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH v3 2/3] xen/mm: allow deferred scrub of physmap populate allocated pages Message-ID: References: <20260122173857.83860-1-roger.pau@citrix.com> <20260122173857.83860-3-roger.pau@citrix.com> <69a64a89-af3f-47fe-8998-a3ff76e9484e@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <69a64a89-af3f-47fe-8998-a3ff76e9484e@suse.com> X-ClientProxiedBy: MA3P292CA0010.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:2c::12) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|IA3PR03MB8406:EE_ X-MS-Office365-Filtering-Correlation-Id: 8aa83150-7bea-4a59-08c2-08de5d907815 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?dUlyMTlIQ2tlQWVyc1dscWE5R0VEeEhUQi9nN3RhS2VPeEZ5WHRBM0hxeUdt?= =?utf-8?B?V0NFblJjK29ZVlBqamkxWmZDMnFOMUZZOFdxWnBjUTd1MG5xbjl2YzFVY2h6?= =?utf-8?B?YitiQlpnOUZxbTdERXlmOUlkNmNUa3oxb1kyVmh2dUtDRzFBUDE4QjdLckZ1?= =?utf-8?B?UzE1TEpyZ3hRVlp5QjVuckQrWmR1dnJEd2UrbE1ONlVrL2p0ZmpPMkw5S2Rl?= =?utf-8?B?UUlETkZZbS8wdDBwYnNpVVNRc0EzcDRpTWdOb3FuN0NkS2FYeFlnc0FNM2RY?= =?utf-8?B?NkVLQm82Yk9vVElwMmVDUm1xMXF2b3ZybjNkS3pIOXRKNE8zY3AxN1EwR2JK?= =?utf-8?B?ZlNLRWpzbzVSTWtua0VnY1FnMVI1ZkRPOEhnSlVtMFFZK283ak5kZ0xsZGNE?= =?utf-8?B?RUVEREdob2p6aUFnbU9lbTRWOVZlQzQ3YW5LTVU0dU5RYUJGU0FjeWV1am1G?= =?utf-8?B?ZDhKZ0RteEVaaFRFcUgwdjdKN0d1ekZadENTQ1VvQXJUUDhqcmNyWWIySHJQ?= =?utf-8?B?KzZaQ0JaNDI1cFRqQjZsdDlheWhPb0NFMk0wNVVXVSt3blJERC9IOXRvWU94?= =?utf-8?B?NGdEL2lnZklkU21wNTQzaDI0UE55b0MycEpqT2tDMk5oR2E1YnREMld6ai9J?= =?utf-8?B?NDZ2Z3ZyY0J2OU1zMzI4WXp5SEZKaUg3dFk4QTFhTmhRS1djWnFXcmhoSHdG?= =?utf-8?B?cUxuWlkzeDlsYXI1V1ZORnpQT1hqUk9oeHVrdG9tZnBsci9iNmxjaHYwYm9p?= =?utf-8?B?c2tNR01TbTdKc2w4Rk5GNWc4N3RGSkM3Y0w1M04xNmg1SmxHRitHeG5XWit1?= =?utf-8?B?a0IyVVU2bDFtL3RYSnpaZkUrWGc5U1JheWt0ZVFkYzVLUURCdEVUZ2kySXVZ?= =?utf-8?B?YlIyMDYyZmR0WGpOM2UxUjUxUGlocm9KVXJpRzJNTFdFVDVzRmF4a1puY1Nl?= =?utf-8?B?VjFZWkdmdUpGcm5lNStRZ3dBQ0FFTDZyRkZVbEpaZHc4OHplUlRCN2tnN2RM?= =?utf-8?B?OTJoN09rN2NUUmQ0TVA1VWFldkxGMnU1TTR3azFLNVFWZ1RkaXhMT1F5bVFh?= =?utf-8?B?ZjBxUU9NSEJVYjA5SDFEbngrUk5DUXhONFRqUCt2OHA4Smw0RDJtaVBScWht?= =?utf-8?B?VUp2WktXdWNtYXY1cXVWbVNTMjhFdnUxRVZiVjh1RmFjaElUK0VXSCtnV1VF?= =?utf-8?B?YlBKUjk4SWFZQm9PODlrYTlaMzJjdko3U2dzcHRZWkU4MUx3Z3lKUXVjc3lL?= =?utf-8?B?RktjOFdJc0kyRkJFY2xLaGVQMEF3WDdMb3FDM3d1L3pmbUwzT21HTUFvaGNm?= =?utf-8?B?QitoYmdWQlpZbnBHUXFtK3lLS05pbGJDL1p5cXFhQmRuaEp3RXpOeE8vQlVT?= =?utf-8?B?ZXhDdUtuNzc0eFlTbi91MUxDK3phcXNDbms5QTFjVlg4cEEvK01MeWtXU2pl?= =?utf-8?B?NklYLzNZYUFvVUE2MHpnckNTdXFLZ09PQ1V4R0pjMlJQVytnWTlNRlhFajla?= =?utf-8?B?ZFZIOTZFRlUzZEZIU0NJVGx2MldrVTZsOWFkY1l4aDBHcnRGR1E5djdZa0xr?= =?utf-8?B?aVM4QkptdEFTdTM1SVd1dHR6R1krT3VQZmtVWnNHNk1ScFFUajdnTk9EQVZs?= =?utf-8?B?ckNqNk12cG9zMDExVGtMdTVFMUlBQnB5RE00Qzk3VHBCVzNqMXk0UmFCdWxX?= =?utf-8?B?a3l5alZ4OHVoWE85ZHpkRmFjU1VJQzk5a1R2VjFodFJ2d0hrcmVtRlVGcE53?= =?utf-8?B?SFU0Y3pOTXZYWldvcWlaVVRCVmRaL0xJWTNWaDYzbXVscXRYd0FYZnRtZ05W?= =?utf-8?B?K3dVM3JDbkIxcXAxQmlPa0dmR3FZQVdwUGlucEpVMjN5ejhFbkg5eVJMYWwv?= =?utf-8?B?eC96NytsaWdybXl3TWdGMWhRbDNNT0N6T3ErVERFVGRhVnF4THptTXlrcXE2?= =?utf-8?B?Q2p1cWNKZGxaZE5qVTNycmFsNFMrRE0xQ0lzeFZ5MVB2SWEyNHViM2lSRm9m?= =?utf-8?B?K0ZaT05OdXJoOE5lanpsS1kwQlU2S3I3ZkpVSFU3VlFqMG9vYUUrUmZqSkp0?= =?utf-8?B?Z1FlMnJTbEpteXVGQ09IUHZXTXVwazR1Q1NQbVNEYnZQaXljaVFCTUdFZ0pi?= =?utf-8?Q?iQIc=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?S1VZQTJ5WTA4d1J0RFZ4ckRPVzR6WnA5d1RHY2FHMjYvSEw0Qnc5V3daSEM1?= =?utf-8?B?YURhQ3g1WE5xU2lyMDl0RzArTmNxY29FRlFsaUo5QlJVMnc2Tk1sbUJHem5W?= =?utf-8?B?UDk1NDhrK2ljUGVldWpJUjNESk9PYld2RURaaTUwNGplM2p2a0JZOEI0aW9u?= =?utf-8?B?VFdHMXpVRWpsUnZ3K2kyNHNhc2MxVFJVZ0VMWkphQ2htbmMvT3NEYUxNRWQx?= =?utf-8?B?bjRwSU0wbWYvcy9HdmsvM2NnWmltcW0yaWcxaVBDbGUxTHBtWi82WlhudVpR?= =?utf-8?B?OVQ2enY1dlN1bHN6WTdDbjFPdmh4MFE2anBab083d2pEbnBRaUswZzk1TDVE?= =?utf-8?B?Zks2YUYrTTc5Q2JucWp2S0RsRTlnSngrOVBhUDNIMXFndUsraDJWQkcvZlJW?= =?utf-8?B?cmFtWkdJeEt6WDdKb3RHSDRyYTkzZ29TTXRMb3c3K2JKaXVFemo0VG40d3pH?= =?utf-8?B?Q3M3MlF3UTE5Z3pOQzQrYjhjL0cyN1FJMm1US3RvZGRxaDA4VHg3QzZMMVd2?= =?utf-8?B?N2FNendqMHR2L3NVWUIrbkFWY1I1VW5UYUU5N0twbzFoTklFTkZ0SVZocEs2?= =?utf-8?B?REwxdzNPUVN1Y0NTb1IvdFlLOHVCQXFNVDhOcDR4bEhlOWJ2ZjBSMXZVT1Rh?= =?utf-8?B?djVHOWtQTEpuVkFrNFFtcnFJT2RhUTErb3hMQWRNNXpQcWN5blRxTThtaHgy?= =?utf-8?B?THBzOVJGNWxkUy9OcmZOa3hPZjFFRjd2QWdzM2xmZ2oyUlprRzF4YzdGRkMv?= =?utf-8?B?MTZ5RDErSkNRTnlnY2JPblNmdm8vRnFkeXkrR2FqVDVVbk0zOHhMem9tbVJ0?= =?utf-8?B?VWtHbE1pRWM0OEFSZzYrZkMzR01IUFRsOWxpcm5GdG5HNXBocTFCQW9iMWZ6?= =?utf-8?B?MkkyOTVDckN3QVJ5TEJ1VXRkTW90NjdlWUQzL2ltN3FwZ1ZZWTlWdmo1UERT?= =?utf-8?B?Tnd2THI1TUN2dk1tb2Ywbkd3bzJrSFhORWJnWWFEZGhzRnRBVDVVaHlrNVN1?= =?utf-8?B?Q1NuNTl2OHd6TW9wSE9BMEpKK3llVHZGVzZXdWxkc3NuZERuUWQvNjU2NGNz?= =?utf-8?B?UzlCYlhzckoxbTJVdE5TN0llcHRoMk5ic3lzbmh6M0RidS9ZdGw4WElPMnY5?= =?utf-8?B?ZWxRV0l1Rlg1eE80VGgvY1REOXU3aE1vb0RGSXRJcHZpRmFNVnpwbWN4dzgx?= =?utf-8?B?RzZhc25lc3FZQ1U5Q08rd0xvdjJBaVV1OThDSDladFFkNUluVHBvdnA5MDB4?= =?utf-8?B?RWtjMDVDUlNuWE9zVmtBTWpyL3dOUjVZTXlud3cvQU9UUUpIQVZwVUtsZUl1?= =?utf-8?B?M0hIaFE3UDZ6UytybFpnNGhxaElOcFpON2V4ZkN5VWppcUR0WE1KVkJaR0U3?= =?utf-8?B?UFNXZnNPNUNjUk9wWjlNaXY0YXZBOENIdGVQV05UeUZTVXg1T1hkZWc0REc2?= =?utf-8?B?ZDNnMUZ3eDdxWUlNWU84aUIvKzhUa1ZyWk9Ca2ZScGU4RmRpQUhoMElFWHdv?= =?utf-8?B?b3h2TFl2cWZSTGIzRm53NU5rOXd5SGpQOEJiQkU5UmVpZXBkYzJNTXFZRUtC?= =?utf-8?B?L1NUL2ZTK24xeWtoYTJpbmhYSWczMWxsRUxRZy9CeHAzSTVIbzdaZWhySTZC?= =?utf-8?B?ZWViNHlIU2RnNEFkMnoyTWUzQmJNdkRvZnhjRHhINXYreEJBNEp2UjRzSmFM?= =?utf-8?B?d0RIT3JVSmQvNmZNYUF4MTh1dE12MUtCdzFJQ1VOakVyTk9kQkx4OWlSSVVC?= =?utf-8?B?dWdWanBLNktPT1U4aDN6OUdGTGdRdjJjMURHQ1BHUk5aeVk1YXZlUFRJTnpa?= =?utf-8?B?WDlGc0M0Y0N4SDAreDFNQmM1RGtQZi9EeVpQblArb3Vrd3pvTmlGbHNrdVhm?= =?utf-8?B?Kzg5QURTQ1VYRkVzWU9qS1RReVd1K0s0bVAvRWxpdU1mZTFFUUVFREk2dkt3?= =?utf-8?B?Wml6dnFjZTAwZVAyalFJSjhrdEx3eEVtSFBqc1NLUEs3VFVKZlRaTE1kRENn?= =?utf-8?B?ZnV4WGM3bnpkZGdRY2sxVGsrcnNDTzIzQUJ6QXpITktteHRHeC9UaXhvWXlz?= =?utf-8?B?UWxFcThDZ29RaUpyUGtrMnpCMFZqcXdzL1F2RWhRZ2NUTHp5V2dVeWpjUUtv?= =?utf-8?B?UEl5WDJ3S29POElLUVBtdFZrUHUxa3A0WHJGVTVEKzRMQ284UjVFUDQvdWMz?= =?utf-8?B?a1czTzY5UTJuOEEwYytkb25IVkdPSElUSHMwclJyU3BpOGZwaXBEbFk5WXNZ?= =?utf-8?B?U0wvM1lOZlFrOTViZUdzdm52c1RDaEdtVHJrbTg1RTI2STlMOFRINXIrY3lN?= =?utf-8?B?SEVPMEZ3aUplc25jQnUxU1kvMUNVV2lmNHlBMTR5QlNuYW5HdWZaUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8aa83150-7bea-4a59-08c2-08de5d907815 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 10:40:20.6955 (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: dQK/lD5cDhHTrjqEeRO+3GYIQ8dvq/tSlh92NGERJyMUHSj1DrUFGqrpbjJuZv1ejiV0Iz29HZvVUvAzqpbjXQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA3PR03MB8406 On Mon, Jan 26, 2026 at 12:14:35PM +0100, Jan Beulich wrote: > On 22.01.2026 18:38, Roger Pau Monne wrote: > > Physmap population has the need to use pages as big as possible to reduce > > p2m shattering. However that triggers issues when big enough pages are not > > yet scrubbed, and so scrubbing must be done at allocation time. On some > > scenarios with added contention the watchdog can trigger: > > > > Watchdog timer detects that CPU55 is stuck! > > ----[ Xen-4.17.5-21 x86_64 debug=n Not tainted ]---- > > CPU: 55 > > RIP: e008:[] clear_page_sse2+0x1a/0x30 > > RFLAGS: 0000000000000202 CONTEXT: hypervisor (d0v12) > > [...] > > Xen call trace: > > [] R clear_page_sse2+0x1a/0x30 > > [] S clear_domain_page+0x11/0x20 > > [] S common/page_alloc.c#alloc_heap_pages+0x400/0x5a0 > > [] S alloc_domheap_pages+0x67/0x180 > > [] S common/memory.c#populate_physmap+0x22f/0x3b0 > > [] S do_memory_op+0x728/0x1970 > > > > Introduce a mechanism to preempt page scrubbing in populate_physmap(). It > > relies on stashing the dirty page in the domain struct temporarily to > > preempt to guest context, so the scrubbing can resume when the domain > > re-enters the hypercall. The added deferral mechanism will only be used for > > domain construction, and is designed to be used with a single threaded > > domain builder. If the toolstack makes concurrent calls to > > XENMEM_populate_physmap for the same target domain it will trash stashed > > pages, resulting in slow domain physmap population. > > > > Note a similar issue is present in increase reservation. However that > > hypercall is likely to only be used once the domain is already running and > > the known implementations use 4K pages. It will be deal with in a separate > > patch using a different approach, that will also take care of the > > allocation in populate_physmap() once the domain is running. > > > > Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed") > > Signed-off-by: Roger Pau Monné > > --- > > Changes since v2: > > - Introduce FREE_DOMHEAP_PAGE{,S}(). > > - Remove j local counter. > > - Free page pending scrub in domain_kill() also. > > Yet still not right in domain_unpause_by_systemcontroller() as well. I.e. a > toolstack action is still needed after the crash to make the memory usable > again. If you made ... Oh, I've misread your previous reply and it seemed to me your preference was to do it in domain_kill(). > > @@ -1286,6 +1293,19 @@ int domain_kill(struct domain *d) > > rspin_barrier(&d->domain_lock); > > argo_destroy(d); > > vnuma_destroy(d->vnuma); > > + /* > > + * Attempt to free any pages pending scrub early. Toolstack can still > > + * trigger populate_physmap() operations at this point, and hence a > > + * final cleanup must be done in _domain_destroy(). > > + */ > > + rspin_lock(&d->page_alloc_lock); > > + if ( d->pending_scrub ) > > + { > > + FREE_DOMHEAP_PAGES(d->pending_scrub, d->pending_scrub_order); > > + d->pending_scrub_order = 0; > > + d->pending_scrub_index = 0; > > + } > > + rspin_unlock(&d->page_alloc_lock); > > ... this into a small helper function (usable even from _domain_destroy(), > as locking being used doesn't matter there), it would have negligible > footprint there. > > As to the comment, not being a native speaker it still feels to me as if > moving "early" earlier (after "free") might help parsing of the 1st sentence. I could also drop "early" completely from the sentence. I've moved the comment at the top of the newly introduced helper and reworded it as: /* * Called multiple times during domain destruction, to attempt to early free * any stashed pages to be scrubbed. The call from _domain_destroy() is done * when the toolstack can no longer stash any pages. */ Let me know if that's OK. > > --- a/xen/common/memory.c > > +++ b/xen/common/memory.c > > @@ -159,6 +159,66 @@ static void increase_reservation(struct memop_args *a) > > a->nr_done = i; > > } > > > > +/* > > + * Temporary storage for a domain assigned page that's not been fully scrubbed. > > + * Stored pages must be domheap ones. > > + * > > + * The stashed page can be freed at any time by Xen, the caller must pass the > > + * order and NUMA node requirement to the fetch function to ensure the > > + * currently stashed page matches it's requirements. > > + */ > > +static void stash_allocation(struct domain *d, struct page_info *page, > > + unsigned int order, unsigned int scrub_index) > > +{ > > + rspin_lock(&d->page_alloc_lock); > > + > > + /* > > + * Drop any stashed allocation to accommodated the current one. This > > + * interface is designed to be used for single-threaded domain creation. > > + */ > > + if ( d->pending_scrub ) > > + free_domheap_pages(d->pending_scrub, d->pending_scrub_order); > > Didn't you indicate you'd move the freeing ... > > > + d->pending_scrub_index = scrub_index; > > + d->pending_scrub_order = order; > > + d->pending_scrub = page; > > + > > + rspin_unlock(&d->page_alloc_lock); > > +} > > + > > +static struct page_info *get_stashed_allocation(struct domain *d, > > + unsigned int order, > > + nodeid_t node, > > + unsigned int *scrub_index) > > +{ > > ... into this function? I could add freeing to get_stashed_allocation(), but it seems pointless, because the freeing in stash_allocation() will have to stay to deal with concurrent callers. Even if a context frees the stashed page in get_stashed_allocation() there's no guarantee the field will still be free when stash_allocation() is called, as another concurrent thread might have stashed a page in the meantime. I think it's best to consistently do it only in stash_allocation(), as that's clearer. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jan 27 10:45:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 10:45:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214230.1524592 (Exim 4.92) (envelope-from ) id 1vkgZf-0001kK-WA; Tue, 27 Jan 2026 10:45:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214230.1524592; Tue, 27 Jan 2026 10:45:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkgZf-0001kD-TA; Tue, 27 Jan 2026 10:45:31 +0000 Received: by outflank-mailman (input) for mailman id 1214230; Tue, 27 Jan 2026 10:45:30 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkgZe-0001k7-Q2 for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 10:45:30 +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 4b6cdc94-fb6d-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 11:45:29 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SJ0PR03MB6566.namprd03.prod.outlook.com (2603:10b6:a03:38a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Tue, 27 Jan 2026 10:45:23 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.010; Tue, 27 Jan 2026 10:45: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: 4b6cdc94-fb6d-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=v/zTy49v5PPjgytlJX72FD8Bk5DO8PnqwIILnt3VdQdGtQL0ap5duwihJQm+T4ben9hgUgSoYO1qxA142T2bBRvEdITp1oCO+3T0wGch1zXh6Ha5frBDh6ZKmqnAPjxDwR60TYFR2O3gvR8m5ZvIbu5Raz3lH1C8QpyraJNzB0TowydYvUusNrLPu0S0BXovE1LnnssCYpqzjFPbuCWUi0ueu/b0f9sDS4yWnt4jwgjknwR+e3g/G/FmoJuHBqEdT22pY471OoZeStntWE1Aa/kHNPArTyIFPXXLAwZRQXRjnFvQdJo+2EyWWCUaQpUmmMoaIHQzhdCXfuemzEl2Jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+f62wvsoMJ+geg/xJsDNMTVEiiK0qgln2DAEwRPkCwk=; b=LpUsKEzvPDq6rTdvNWgVr16npvxYbI7QIZLIX6FlywSeHpJTfw87hPJWRBtdtGt4es8cvjWl/9DHqzcO1YrpURkbICJ2bJ4qz4mbXeoTgHdSDJMvMrJkhAo0Z9Bz50R9YqyQ1/2F4SnnhyfsdqkHXjo/+TTUI6Wntr7KcaMfqOfzI11Rn6scF+nTlN9PnhRifCwjYzt8S4DBtHwqW7xLOAhib0h/dv/RimvP6ulND3X+3REliUVlvjbHS5YlkLOg9eMjIDJzkbM1cp6UPgBTdBNn5ZUkzoNpN/uHz3NtJ0yy4BDFTviAE8aiYKaFJZQLijyKCimNxJ13n8TgImXBJw== 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=+f62wvsoMJ+geg/xJsDNMTVEiiK0qgln2DAEwRPkCwk=; b=heZ9nfg4D89NT5G5P8bcr0hDMOPGLtUFIqYFeU/ordSaBq8h3PUxBuFMU+V5zciCqiFZrnKGdNaI3otOo+2tFESXHyzXpXCrJ1XiGFimTb3Eu74esJz+9OpC9kr2jMG48550CFGzFzI+cVV7Db4FaOSW4Nr38fEZgHZ3RxR0WEU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Tue, 27 Jan 2026 11:45:20 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH v3 3/3] xen/mm: limit non-scrubbed allocations to a specific order Message-ID: References: <20260122173857.83860-1-roger.pau@citrix.com> <20260122173857.83860-4-roger.pau@citrix.com> <0ff49a6b-67d3-4b2e-bf9f-4b752cfc24aa@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0ff49a6b-67d3-4b2e-bf9f-4b752cfc24aa@suse.com> X-ClientProxiedBy: MA2P292CA0019.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250::17) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SJ0PR03MB6566:EE_ X-MS-Office365-Filtering-Correlation-Id: dd4656ee-c00b-417e-282d-08de5d912ca5 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?U0FJYlF3emVBTkwyMGplckIvVnJTWmZYaTQxUWZOa3YyNVVieXZqTWNLZnc4?= =?utf-8?B?cWtYZE95cm1NZXI3UWJPUmVEVVEzUGNnVm9UaXhVRUpoYy8rR0FVb3lreHNE?= =?utf-8?B?OEYrU05LYTV3WU5yeG12M1FvcUdyYnBOQXZTc1l4M0M2aEVwSlpHN2ZLdkN4?= =?utf-8?B?OGI5OFhsUjVTL0VFUWVyQk9yYnMrcnhWb2wzV0NFejJXdU10STdCSlNESjZq?= =?utf-8?B?ajc5RXJiUkJGNmpHT3RtRkFXU0xyV3JQVmtPY243dFR2RHRuM2hSSW5ab0wy?= =?utf-8?B?WGRkQWRBZXd2Rk85UFpvRlBTWnd0dngwZVZjMTZuWGpDR1FZVWtSWSsvanM4?= =?utf-8?B?UlR4QklPNlhobFFGWGpHZVRnajgxeUYvdUVZaXl4YzNBbW80UFBzSXZUUWhv?= =?utf-8?B?UEN1aEpPeS9TUHU2dGV4ZjJhMGVRRFd6dGIvTU9RZ1BDakJnMEtDSWV4eGdk?= =?utf-8?B?TzErZkh3MmxwZS9yWnJONDhOS2pVbElOYTlXdlE5Tm5oNzc1TEZVODZIT2px?= =?utf-8?B?UVVZM3J3bWtGUW5yaWdrL0hrY3htbTZEOFpOdzdkbTgzNmRHQ0xQQ3BxNldx?= =?utf-8?B?WER0WXBCWEs3Tnl0bXlEcnNLV0JtOUFDZWY4TnhJbitNZE1lVCtkd1Q3am5w?= =?utf-8?B?Q01QRW1mZGFzS2lvZ2hmTVFVL0lYejY4UkRCS2x3amU3VTMxNThjWTBFRld6?= =?utf-8?B?cW5rYTNhMndFNTRGV3BtckpRdkxzNFlUVnJMM3IrbEI3aVYvdW45eURERXlH?= =?utf-8?B?RFN2NlBVSVFDYUJIOEEySHMrakRud0lEaWdsUmtIeWg0aDV1a0FyaEQ2UXVE?= =?utf-8?B?cGVxYkM2OUlvc3gveXFtMlNsOGo2bjNzcW8xYSsvd1dIODdqZEt6dVVVOVQ3?= =?utf-8?B?RHJFRDJ6RmVPUjl5MXFxNGg1U2VYUExvNnlpTVdQaXRHTTJ5T2dCb0oweDhl?= =?utf-8?B?S0hDK3Ara0VmaWtYbUFFNHlxWTJadmVoZHdjZlZmVWszdXVBVWVXSGdTazdZ?= =?utf-8?B?eWxHTUMwNGxhSkMrOWNQSm44dzJaekMrOUZHcjd5U0VVeXBhOGEvajcxSU9h?= =?utf-8?B?aGNhUDVDYjBWVnhoQlo3UWU0STVkVVpucmZlVnZ0czVHd0F1ZEh6Qkk3UnBJ?= =?utf-8?B?eUZXR1llQ3M5RFo4bHFucnMyM2J2czBHV3EyckwvUnJuRzNZSEsxak1tenBn?= =?utf-8?B?VHFwenpFeEFYZ3V1WDNzMWwzV2VxcWV5eXorT0FhUURRWnhuZkZYc2p3cjB5?= =?utf-8?B?R21vZW12TXpDN1h2a0ZkQUVkNno0SUJoY1BLczFSOTg0bGhXSGVNMVVlb1B2?= =?utf-8?B?K3dUSURqNjFJdUZ1S1JxVmR5ME5Bckg2ZGpENVRNeWFHSGlvVUV6WDBjMHBZ?= =?utf-8?B?U1Z6Skt0ZWM4cW5HT3JMN3dKcUJISE5QaFpYcUQ0dThUZEc4TEV6WkFJMU1h?= =?utf-8?B?VSsyUHN2TXhZcU90S0VEdWIrcEhWazh5a0NMekFHZ2tMSWdzOUFZdmpVSW5j?= =?utf-8?B?Nzg0UzNleUZRL3YrZTREaUtKdnlFTzcvb0xtTno1b0ViOFhxNW1lRnlYNzhJ?= =?utf-8?B?ZCs3U0VObFFubzFza25pSFMreVhUM2RpaXVmb29WSmNhaEhVeUJyeXZrQVhT?= =?utf-8?B?cTRmQytOTk1hbDRhWjlYckl6N1V1a2VxeFdtTk4wd0tQWCt6blR4TzlWaEIw?= =?utf-8?B?b0lCV0dkdVo4N0UvajZWbG13bEdWbVhFVVZNcEt1S3ErYUhsU0w3WE02NjVk?= =?utf-8?B?eWhlMzYyRkRYZGZWODBrQk9tdC9WL0FYT0lhTVQyeURXbFEzS0U4eWNxUEZj?= =?utf-8?B?ZGZ2UWU5K2NIZkRFN0ZsOUoyNUY3MzZsd2dxT1llVXJobU9qeDZIZVFWWmp4?= =?utf-8?B?V3ppT1F1S1ByVWw2bVlOZHlXSzI5Wld5ODNWTkViODBQbjIvc3lUVVNaR0dR?= =?utf-8?B?T3hBeHVnckgraWo1V3A1S3krZUxKN1ZNMlpiUVRwNk1Wbk9ycXJCZXRaMEg4?= =?utf-8?B?cmJkeVBGYTJLVCtvWDFuTDRpWHk1bXVmemxQQU9xZktCdUk2MkVvYk1RQUt2?= =?utf-8?B?ekRUeDNieUJFRDFvMnFtd0MxTXJWMnowY1dRVjdBYTdrT0dTaTMyQmZhUURr?= =?utf-8?Q?Bt8E=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QitUNW8vVDJSYVN3dWMxM3pmVUlDYVhnYTg4amtHYjg0b1JjSENPWmdaRW9y?= =?utf-8?B?Q2ErbVBCMWJkcmwxeDZvbThLL0R3eGcwYU5SdTBZYUw1SHppNGc1VVR3eGZB?= =?utf-8?B?ZGtrTEw5WHc2QlhIUEJ3ckxydlBrdE80c2RDUG5xdDhUdmEwRmM2ZWl2WUli?= =?utf-8?B?WjFKeFdPd0pPM0pSSStlcUtwQzlnM09MWDVQRUdQbTR0QXhiTlJEK2NxaVdK?= =?utf-8?B?NEVKSnF5bzBHbGZuNGxwMFc3WjRIUVJFaS94SWNXSjhXUVZLc2RKYzF2MFJ3?= =?utf-8?B?WlgwM0xaQ2d1YmZORnhEZEpBMm81RHdYbUV5OE5haThOTjlpWnpBMmU1WEg3?= =?utf-8?B?cUN0R2wwdVQ1aGZGaElCeE5OQU1BQVFiWHR4UzBwd0tGRVB3TFJDanFEeExn?= =?utf-8?B?YjUwKzkvUnNHVHEwRXFLTmhtVExiakZtOE9wMVlDNUxaRy9hNlFuR3dlRUNy?= =?utf-8?B?NThxT3BwSWVUTmhQOU0zVkl1ejBxelVmN3NaMkdUaGVMMFlhN3FXbW1vN2RK?= =?utf-8?B?QXZXbGZTdVY4L1JqWmxSQmk4bFRpOXZoRXNWMTZwa0pWTHYzMDM2czR1b0M4?= =?utf-8?B?cGx1cyt5cnNaczVNOGIxVXkwUWlKV0NGT2swanBneGIrUGcxRmI0ejFUUG52?= =?utf-8?B?VXhQZ2ZUaVRnYkRCLzYwbkQ0SnJEOW83MmF5ZVlOWVkzVlFQUXBwQUpvRzl5?= =?utf-8?B?NHlkaHZJbkhRd2hYYzVOems3bm9QcTRkVDVrVU1UcTIrTHFWZXdpWEJZTVFS?= =?utf-8?B?ZjViNzI4dmdzR05na3Y5TUorRjU3V2dvdkl4T05YczBTbExwblJmcUxwSU5x?= =?utf-8?B?UUgxMkZUZmNLNkhJRElYdnNiMDZNSnUvb1l2c2FNYWNybDUzRWVXNUUySllF?= =?utf-8?B?RVEreS82MjlFdXc3TFlGNzMwT3k0RDVpbEJPVDF2U0Z3VDV2aExhODVNMFZ6?= =?utf-8?B?MUl2cjI5WVBsTEJPQTBPWk10TmVjUUczdExIVGlHQ2VESkJJQ3VobWxZR1Yv?= =?utf-8?B?UElLWWVLZkVJbCtrUWNxV1Fua2ZDYTZRV1hDK1RRK3hmYU1qS2VNZFhDSy9K?= =?utf-8?B?cGwxYk1XOEp0ZGtMMTVGTitMUGNJOTZIeVM1bTdzTU1qZUQxRnFpbXlCSDNM?= =?utf-8?B?SmFSVVFmR0Z4QU56ZzduUTJmRnlNQTlETER0UE0rSlhiYW5JSEFaeHltVWpY?= =?utf-8?B?SUEzZkpnV2REbVREdmpWU1c2VGVlTFBpTS9XWFFjNTNveG1RYkg3NWRXOEdG?= =?utf-8?B?aHBZUUpEWVo0eG9DZk5CZ1ZXRnlybmxKRWQraG45dTltNXhuZnRBci8rUWlY?= =?utf-8?B?NEl0T3lxTkl4WTFmc25qeFFBclRHaVhxRVJsM3lJZ3k0US9keVlSVVFhME9D?= =?utf-8?B?ZFJra2ltTjdoektlVGMwR3p4cE5uVUJlQUY5T0JmWnZrWDF6N1MvYUxZUTZM?= =?utf-8?B?WTJucE1uZHIvUEhRUy9Ka1Raa241UFF5VWFYR1dKS2s4Rk4wTExVK2JrbXhj?= =?utf-8?B?UVlvZTJZS2k5YUVrZTVLNXRDZURtSGUrSzk4ZFFvSjRUNlNvRFVYSkhFaE9i?= =?utf-8?B?SkNkN1BLeE01TEhsclAvWTVlUGlpZkM4QVZISFNsS0RRSEtkeHZOMWllbnNX?= =?utf-8?B?aFcyaEp5bGNyWm13KzFvRmpWTE1QUGR3bGJuMjRyMDVMWndGZjhsY0ZxM2d5?= =?utf-8?B?WmRJLzN5azFFUm1hSUhEZmw4eGZGTmdoTGNZS3M4TnliUEpidjBid1l5djFv?= =?utf-8?B?dktLMU1xRDh6T1k3bXlzZVozK1dlK0RkSHp2dFEvMEk3SUl4dVRqUXJUblNk?= =?utf-8?B?VFdXRTZOSnFXRmVKdzAyaFRpdTRKT1g0aUR4MFl1SGVFZ0VqVnNpUzhrQllw?= =?utf-8?B?amY0Qkc2aGFwN0s3b1pYVGVsRmludy9SdWlzWnJyeG54VDQ3dEdITlVlTVIv?= =?utf-8?B?WFFuNHFkcmpDVFVub0U5TGdQNHhNZ0ExL2orT1UyTVZKcCtiNXpFUE1HZWxW?= =?utf-8?B?WTkwSlYxaXJWdEp1bzRPNHVJRWxsTmJXQVNxT0xvcXZTeFhDV3dyNFNETXVa?= =?utf-8?B?ZFVJczJVL0lWeFlkOXNkUEtjRytxZGsxdjFvdGFZZ08xeXJUY21hWHBoa1pO?= =?utf-8?B?bXhOUmc1bFRmVXRETTQzYUUvRzR2OG9HWFo2Y2VjWmJZNEd4NUpmNC9TaTRN?= =?utf-8?B?MjIzTStKV0VHTUE5WnIzUll6Mys2R1U5MUNUdUF2Q1ZPazk4Tkw1QVJmbDJV?= =?utf-8?B?Y1ovMk5HcEJzSDdvZ085TjUzNXpFbGs2SldlRG83MGZjR2xnSjBZaWNKUnFX?= =?utf-8?B?Y1loV2xyVXNabTFvMDhvMlBHTWRZRVc4OW9XUzhqSUtCdTIxaUl2dz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: dd4656ee-c00b-417e-282d-08de5d912ca5 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 10:45:23.5967 (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: y1eQfmKrq7kl7+SydXZsOKlNLAb4LatFoznqtN/F/UgHrxO/JPTxMPu3V/s8iVC4ftEdlBz1VQbDGUywqH5XCg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB6566 On Mon, Jan 26, 2026 at 12:21:17PM +0100, Jan Beulich wrote: > On 22.01.2026 18:38, Roger Pau Monne wrote: > > The current logic allows for up to 1G pages to be scrubbed in place, which > > can cause the watchdog to trigger in practice. Reduce the limit for > > in-place scrubbed allocations to a newly introduced define: > > CONFIG_DIRTY_MAX_ORDER. This currently defaults to CONFIG_PTDOM_MAX_ORDER > > on all architectures. Also introduce a command line option to set the > > value. > > > > Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed") > > Signed-off-by: Roger Pau Monné > > Apart from a nit (see below) looks technically okay to me now. Still I have > an uneasy feeling about introducing such a restriction, so I'm (still) > hesitant to ack the change. OK, I understand that, and I'm not going to argue there's no risk. Overall, even if this commit is not fully correct, it's a step in the right direction IMO, we need to limit such allocations. And for callers that legitimately need bigger orders we will have to add preemptive scrubbing like we do for populate physmap. > > --- a/xen/common/page_alloc.c > > +++ b/xen/common/page_alloc.c > > @@ -267,6 +267,13 @@ static PAGE_LIST_HEAD(page_offlined_list); > > /* Broken page list, protected by heap_lock. */ > > static PAGE_LIST_HEAD(page_broken_list); > > > > +/* Maximum order allowed for allocations with MEMF_no_scrub. */ > > +#ifndef CONFIG_DIRTY_MAX_ORDER > > +# define CONFIG_DIRTY_MAX_ORDER CONFIG_PTDOM_MAX_ORDER > > +#endif > > +static unsigned int __ro_after_init dirty_max_order = CONFIG_DIRTY_MAX_ORDER; > > +integer_param("max-order-dirty", dirty_max_order); > > The comment may want to mention "post-boot", to account for ... > > > @@ -1008,7 +1015,13 @@ static struct page_info *alloc_heap_pages( > > > > pg = get_free_buddy(zone_lo, zone_hi, order, memflags, d); > > /* Try getting a dirty buddy if we couldn't get a clean one. */ > > - if ( !pg && !(memflags & MEMF_no_scrub) ) > > + if ( !pg && !(memflags & MEMF_no_scrub) && > > + /* > > + * Allow any order unscrubbed allocations during boot time, we > > + * compensate by processing softirqs in the scrubbing loop below once > > + * irqs are enabled. > > + */ > > + (order <= dirty_max_order || system_state < SYS_STATE_active) ) > > ... the system_state check here. Added. From xen-devel-bounces@lists.xenproject.org Tue Jan 27 11:06:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 11:06:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214247.1524622 (Exim 4.92) (envelope-from ) id 1vkgu5-0004pl-Oo; Tue, 27 Jan 2026 11:06:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214247.1524622; Tue, 27 Jan 2026 11:06:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkgu5-0004pe-Ln; Tue, 27 Jan 2026 11:06:37 +0000 Received: by outflank-mailman (input) for mailman id 1214247; Tue, 27 Jan 2026 11:06: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 1vkgu4-0004pY-MV for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 11:06: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 3e748113-fb70-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 12:06:35 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-4806bf39419so861365e9.1 for ; Tue, 27 Jan 2026 03:06:35 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1c30293sm37884201f8f.19.2026.01.27.03.06.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 03:06:34 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3e748113-fb70-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769511995; x=1770116795; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=26uRpTXGMxGsyYCxnznwvskxo7pssM7ff2WO+EhBO1I=; b=TFVzM9cGQgaM7S3uOZXihhMVVG/SJf4vbqrvGDo2s0vuujgaoXuJElBybpRUTpLFJt Z/7QwMDYZL3JmSqoex6em/HwENlTB8Dn4qN12vytdRIbIzYZZGGZzl12tg7tBGA2Bok6 ygAasgfSq58s89GnVBFmHZsJJ4asuEv4Q/tDD+NmTz+fIEb/qtGSkIZH5HU1HosnNdSI waMlA3ca/ddldkWG/X1Gy9B4BsOmZmGIset5bZEAfP1QeJ4v4DJOIUdSsJ216sLDyeMd ZqG7c6m89Wmh89/k7KcOWiTuTbzibKkw/C68Fd44QIhoqGnFHmayUyjHpSqmtjd8l3hl aU0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769511995; x=1770116795; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=26uRpTXGMxGsyYCxnznwvskxo7pssM7ff2WO+EhBO1I=; b=VXk3MTZkXMsWzILmTqknsk4wV67mGChKP0TlUVh3NoK56RTe1EQuIX1zEprF5mF8EJ y/Fcijp/ODASDDMvcC0ix9cfHf2f+kvJM43702IbDuqiJS1l5B0TRkVpt/9BLsSgxQK5 f2QTYd2foez2D2iWrn0kvfdo4fjth6eacvDTrg1eZHOq7DLguImX2GW3/RqJrKtVeNW4 CTXiNXcznQbUxLSgkJYoyQ/ttaKHSmD1dttfCtd3kkqhWdx3qlP4GB/DUffCiYMJvHcT bty0oxNrCKeOy+PGUaGp2XFzYk5JzkdPdJZ/0O4odrpNgy+bH7MzLJXHbjxYA6NhiL7o 1Apw== X-Forwarded-Encrypted: i=1; AJvYcCVL6eHBkeNGrEI2HykAF27wtsQMed3NXkmgiBMbNuit7UguAdZUrCeKoFrT8mR1SiAyPldDM6v4jbA=@lists.xenproject.org X-Gm-Message-State: AOJu0YzlosNvffhDxEa0Pc0HkoijRni6MjG7SjdcuHnhzzG1Jae8krQ6 Jfie7JfoLBzv1zd+nKwuqP+hQYArmgdyDqgU8hRz9QTB7j5j5gepYq5dQe+2iG488Q== X-Gm-Gg: AZuq6aKGyHK9xLly0ujaXq9cL7eYYkri1QtnHWuATPF9FYFLzvqn9npo1dHkhg6LV7Z GA4aOUgZ/fpjmLKFdvWEzDn1EMuS/9VowwICefWqoKMuRuEXzlx0bt9VU4Xcrc5OLkXuuZBS6ma foKIaTzie8L9GPECHHC2ByUbYMS8hrQAGN5xYyZwHaF28iB/uLxUt4gXqxXmGqCGg9PWdh+N0Mb +T8FP+w68vIRYiDWV6Rtthpry95b/cEsLmTTWACY3CgOeswFedDxdybgMJFeWBXuJdFJ25EFKPm gipNXzrwikk0v4rcRsT0mtWlEMqqgEFi26slcHOUzFLDHcrnyz3I8bt5Whsm/M+HYIoxG4zhzJM OsEgmuQn9TmCJZgIYdzYuGnfKz7Tq87pvatK7cxmrS5VKa63ivzJ6ePnMymd4gFOjBwm1LZOB36 fPR3kXPmFQOKIgaq9kobtVy5IS2iKbJQx8zVQQLeZ14X7joTT+RjbpISUO5yWn6QIFWkG33gf23 D4= X-Received: by 2002:a05:600c:21ce:b0:477:9a61:fd06 with SMTP id 5b1f17b1804b1-48069e33806mr11255815e9.8.1769511994505; Tue, 27 Jan 2026 03:06:34 -0800 (PST) Message-ID: Date: Tue, 27 Jan 2026 12:06:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/3] xen/mm: allow deferred scrub of physmap populate allocated pages To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260122173857.83860-1-roger.pau@citrix.com> <20260122173857.83860-3-roger.pau@citrix.com> <69a64a89-af3f-47fe-8998-a3ff76e9484e@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 27.01.2026 11:40, Roger Pau Monné wrote: > On Mon, Jan 26, 2026 at 12:14:35PM +0100, Jan Beulich wrote: >> On 22.01.2026 18:38, Roger Pau Monne wrote: >>> Physmap population has the need to use pages as big as possible to reduce >>> p2m shattering. However that triggers issues when big enough pages are not >>> yet scrubbed, and so scrubbing must be done at allocation time. On some >>> scenarios with added contention the watchdog can trigger: >>> >>> Watchdog timer detects that CPU55 is stuck! >>> ----[ Xen-4.17.5-21 x86_64 debug=n Not tainted ]---- >>> CPU: 55 >>> RIP: e008:[] clear_page_sse2+0x1a/0x30 >>> RFLAGS: 0000000000000202 CONTEXT: hypervisor (d0v12) >>> [...] >>> Xen call trace: >>> [] R clear_page_sse2+0x1a/0x30 >>> [] S clear_domain_page+0x11/0x20 >>> [] S common/page_alloc.c#alloc_heap_pages+0x400/0x5a0 >>> [] S alloc_domheap_pages+0x67/0x180 >>> [] S common/memory.c#populate_physmap+0x22f/0x3b0 >>> [] S do_memory_op+0x728/0x1970 >>> >>> Introduce a mechanism to preempt page scrubbing in populate_physmap(). It >>> relies on stashing the dirty page in the domain struct temporarily to >>> preempt to guest context, so the scrubbing can resume when the domain >>> re-enters the hypercall. The added deferral mechanism will only be used for >>> domain construction, and is designed to be used with a single threaded >>> domain builder. If the toolstack makes concurrent calls to >>> XENMEM_populate_physmap for the same target domain it will trash stashed >>> pages, resulting in slow domain physmap population. >>> >>> Note a similar issue is present in increase reservation. However that >>> hypercall is likely to only be used once the domain is already running and >>> the known implementations use 4K pages. It will be deal with in a separate >>> patch using a different approach, that will also take care of the >>> allocation in populate_physmap() once the domain is running. >>> >>> Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed") >>> Signed-off-by: Roger Pau Monné >>> --- >>> Changes since v2: >>> - Introduce FREE_DOMHEAP_PAGE{,S}(). >>> - Remove j local counter. >>> - Free page pending scrub in domain_kill() also. >> >> Yet still not right in domain_unpause_by_systemcontroller() as well. I.e. a >> toolstack action is still needed after the crash to make the memory usable >> again. If you made ... > > Oh, I've misread your previous reply and it seemed to me your > preference was to do it in domain_kill(). I meant to (possibly) have it kept there and be done yet earlier as well. >>> @@ -1286,6 +1293,19 @@ int domain_kill(struct domain *d) >>> rspin_barrier(&d->domain_lock); >>> argo_destroy(d); >>> vnuma_destroy(d->vnuma); >>> + /* >>> + * Attempt to free any pages pending scrub early. Toolstack can still >>> + * trigger populate_physmap() operations at this point, and hence a >>> + * final cleanup must be done in _domain_destroy(). >>> + */ >>> + rspin_lock(&d->page_alloc_lock); >>> + if ( d->pending_scrub ) >>> + { >>> + FREE_DOMHEAP_PAGES(d->pending_scrub, d->pending_scrub_order); >>> + d->pending_scrub_order = 0; >>> + d->pending_scrub_index = 0; >>> + } >>> + rspin_unlock(&d->page_alloc_lock); >> >> ... this into a small helper function (usable even from _domain_destroy(), >> as locking being used doesn't matter there), it would have negligible >> footprint there. >> >> As to the comment, not being a native speaker it still feels to me as if >> moving "early" earlier (after "free") might help parsing of the 1st sentence. > > I could also drop "early" completely from the sentence. I've moved > the comment at the top of the newly introduced helper and reworded it > as: > > /* > * Called multiple times during domain destruction, to attempt to early free > * any stashed pages to be scrubbed. The call from _domain_destroy() is done > * when the toolstack can no longer stash any pages. > */ > > Let me know if that's OK. Fine with me. >>> --- a/xen/common/memory.c >>> +++ b/xen/common/memory.c >>> @@ -159,6 +159,66 @@ static void increase_reservation(struct memop_args *a) >>> a->nr_done = i; >>> } >>> >>> +/* >>> + * Temporary storage for a domain assigned page that's not been fully scrubbed. >>> + * Stored pages must be domheap ones. >>> + * >>> + * The stashed page can be freed at any time by Xen, the caller must pass the >>> + * order and NUMA node requirement to the fetch function to ensure the >>> + * currently stashed page matches it's requirements. >>> + */ >>> +static void stash_allocation(struct domain *d, struct page_info *page, >>> + unsigned int order, unsigned int scrub_index) >>> +{ >>> + rspin_lock(&d->page_alloc_lock); >>> + >>> + /* >>> + * Drop any stashed allocation to accommodated the current one. This >>> + * interface is designed to be used for single-threaded domain creation. >>> + */ >>> + if ( d->pending_scrub ) >>> + free_domheap_pages(d->pending_scrub, d->pending_scrub_order); >> >> Didn't you indicate you'd move the freeing ... >> >>> + d->pending_scrub_index = scrub_index; >>> + d->pending_scrub_order = order; >>> + d->pending_scrub = page; >>> + >>> + rspin_unlock(&d->page_alloc_lock); >>> +} >>> + >>> +static struct page_info *get_stashed_allocation(struct domain *d, >>> + unsigned int order, >>> + nodeid_t node, >>> + unsigned int *scrub_index) >>> +{ >> >> ... into this function? > > I could add freeing to get_stashed_allocation(), but it seems > pointless, because the freeing in stash_allocation() will have to stay > to deal with concurrent callers. Even if a context frees the stashed > page in get_stashed_allocation() there's no guarantee the field will > still be free when stash_allocation() is called, as another concurrent > thread might have stashed a page in the meantime. Hmm, yes, yet still ... > I think it's best to consistently do it only in stash_allocation(), as > that's clearer. ... no, as (to me) "clearer" is only a secondary criteria here. What I'm worried of is potentially holding back a 1Gb page when the new request is, say, a 2Mb one, and then not having enough memory available just because of that detained huge page. In fact, if stash_allocation() finds the field re-populated despite get_stashed_allocation() having cleared it, it's not quite clear which of the two allocations should actually be undone. The other vCPU may be quicker in retrying, and to avoid ping-pong freeing the new (local) allocation rather than stashing it might possibly be better. Thoughts? Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 11:08:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 11:08:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214258.1524631 (Exim 4.92) (envelope-from ) id 1vkgvr-0005Ta-2Y; Tue, 27 Jan 2026 11:08:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214258.1524631; Tue, 27 Jan 2026 11:08:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkgvq-0005TT-W7; Tue, 27 Jan 2026 11:08:26 +0000 Received: by outflank-mailman (input) for mailman id 1214258; Tue, 27 Jan 2026 11:08:26 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkgvq-0005TI-IU for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 11:08:26 +0000 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170100009.outbound.protection.outlook.com [2a01:111:f403:c107::9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7f09cbb1-fb70-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 12:08:24 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS0PR03MB8176.namprd03.prod.outlook.com (2603:10b6:8:28f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Tue, 27 Jan 2026 11:08:21 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9542.015; Tue, 27 Jan 2026 11:08:21 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7f09cbb1-fb70-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=BnzBIH2w8SyNqEVFhAx3Bzq9FD3kjA5O+10g1y7X1Vg0f2qB5J5lgkX0KaHGxdrW5dtKq7rME7D5SgPHAygL+QNz2AK/LI/dt33sUFBYUWiXvjU7z64NVs3iWNbmspX7JvWaQ3L5t9kUwlVmj1+XKMfRv4AMHiRSL27S1j00YvdtxvTI2vE/VNiCBLj3VxfW/fe2NJh1Pmc7t8Baot3MLub/tDR6xY+Pl9ku0CYP3e5KHdvTBv319VkCyppadXkXDLgaE6UzqJkpu19VjzQQjDIRDKbTLkiT6XxbJZ1f2mePOxihcgR62gRYROe2TSbFXDU3jPQDnkzeWJRmlmiDnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zojH4Bsz+1Ec+v1l9BvN7ZFAPPUaYAhgqTdW0Rkk0Gs=; b=K3XVjGvnq9D3Tkm41zMWJUwKxyEMPxsk/m7k+obVMAd04rnih9SG3pHcbrnuQbzvXG4zF8Ag1SeInfqOAsRgLnhgV7NjAaoy9HSS6Mf2RFF4rh0Hql5ECTby1rATBMleD1+0WokQwVLVjh2zLyK7yTlHqZ8renrkl4cloSvmoOKxiRPJKu8Aysh9im5GVCqR1cdpPXmmtZ9Wz5npVj2F6J4rLCUGeWP0a/gg6h6sgajGXPS3PHodwbaZznFWzsbLJmzKxidKmtmWWzvRjlTCb2uk3U5Hrh09JOOeQga9XzR7cb5RbqLBfi2F+nQntC/b0Zzzv3oD5phtAMDUT94SXQ== 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=zojH4Bsz+1Ec+v1l9BvN7ZFAPPUaYAhgqTdW0Rkk0Gs=; b=0BJvWyntJIc5SwZy3kZzhmvGZA6lugRJPxP2FVN3GAargR5ut5cCbbeTfA3GmSjsAfMrYAM+xCEJRPB6g6QnerNQeKgmuGlSxt5KXHyH89TYmYscpPG8qQ2cx3aYaIsCWrgeq2+kBA3jzk5xcC1lsMM9kNs+Oexl4PFsCn59eRU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <3ded84f3-505e-40f1-b7d5-f136663af7cd@citrix.com> Date: Tue, 27 Jan 2026 11:08:17 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel Subject: Re: [PATCH 01/16] x86/cpu: Fix boot time cache flushing To: Jan Beulich References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-2-andrew.cooper3@citrix.com> <15978c88-5ea9-4159-951b-27c9fc004756@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <15978c88-5ea9-4159-951b-27c9fc004756@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0210.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:33a::13) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS0PR03MB8176:EE_ X-MS-Office365-Filtering-Correlation-Id: 1b67c43a-31df-4885-5368-08de5d94618b 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?SXBBRmIvUWh4OUgzZllNMkdXMWh0WC9TRzNLRjR6NVRjT2gyem1rM0FXL0JV?= =?utf-8?B?SUpKVEJjMHRQNEpHcHBseWJrOUZNYlBhVDBnNUhzYzM3cFFEeFpjU1ZHbzVX?= =?utf-8?B?L3VsQVdpck9vNDV3OFVEcHJNMzBzanpqYk1SYWRyaWpBem5MbmNjT0VKY2hI?= =?utf-8?B?aUc3c21iazFXbzVjcHhBblJQL3cyMjQrTWNOcHdvWkpKREtFWEtwelFkT25F?= =?utf-8?B?Vm5XZHJDVlZ2L3JKMVQwZTduandkUmxtbkxOWGMwRVFESi9IcHZVa0pRT0VD?= =?utf-8?B?SzVQUkJzaFFRaEMyTlZWdDVRdUJ5QXhkNllMc0MwSklwMktWVDNDc1Uzckxa?= =?utf-8?B?RGFLUjBGQVgyWEZHQ3dLdlZ4Q0pZY3EwaUcyS1p3UW1lTHBwSXcrcTNHYnU0?= =?utf-8?B?bExROFE1NzZiNjM3UFEydUswU1pBQUhud3hxMktBU0d5UXBtcEVmM1g4SkM4?= =?utf-8?B?cEE2Q3dCb2E1R01pYlZORG40WTRmbGc3SThOcWVDT0Y0ODhQMWwwSzBGU1Uw?= =?utf-8?B?Q0x4TE1KSWZBRXIrSG5NU2s2TTJyVHF3UFlRRHkzTXc5d0RUckpleklvamY0?= =?utf-8?B?VllGdnJnY21XYjFrWm9lSHByclJtYkVUamJGL0sveFk0Um1IZ2VKOFFzY0do?= =?utf-8?B?b0FXTkVwa2NEYnp0dDU3c01RaThPMm9hUnpkc0Z6NnJFaEkrK2VmWU1uOFR5?= =?utf-8?B?UDZLN2xQdzFxMmtVUkNJRHdIb1hEY05NVU1PM2xvSm9nc1dOZWFjNWNiU1g2?= =?utf-8?B?Ry9CK21OWHRSRFdiUmNFdW8wTDFkSUZvQXgrQU9HbU9HbzgyRUJFQkJxamhv?= =?utf-8?B?Y1NwMnhiM0Q3czFOVUdLb1J6bjZBL1ZoS2QwY2phZVJycjh5czk0Mlh4dUJO?= =?utf-8?B?RlNNa3hjMU5obUZjOEw1NUc0cGZ4d0ZGMTl5a0pjeWFjeDAwRkVLMXphK28v?= =?utf-8?B?UkJydlMwNktsYm9RUEI0dnMweVV2dHNidkZOcmhTdzNBc3MveU5rbkYrdmgv?= =?utf-8?B?c1QyY0tuUXlFQ3orYTRRcjB2akJqTTVlaW9vV05zNnZ1dlZGVzNIdkdHcWx1?= =?utf-8?B?R3ZoOGRJZGhidDg1MEl0R0pDK1Uza3RTdTNTQlQxVlM2SVJ6M0dWdWZ3a1lB?= =?utf-8?B?K1NuTk5WSGo5OHo0dHBoTUprcDF2aFBEUDd3TjlwSklRdzhGdSs0WFM0RUlQ?= =?utf-8?B?VUFzc3M2eFUyaW01Y0Zycll3dEdpRThkMGhHT0hqNVc0ckZLaGkvM01kS1Fh?= =?utf-8?B?TldHTjdFMFh6cTkvVENLSzBLWktLUldkcjlwakRkbllQbStobDdXYjlvdWFp?= =?utf-8?B?SkhEd0p4TC9FM2hWOGt5VnVSVHJlS0txQkppWG0rOUJqOS9NNDgwTnpRQm9D?= =?utf-8?B?YnZxZG5FZm8weVFMdzRreStyMzVxdjhWVjVlMWVpTFpEc2hhcUVkS3loZWp0?= =?utf-8?B?QUhNUzNJUWVYeElRcDdvYnJEL1UrY29hZzFIeUVrd3MrdkNRQUpYNml4NUdi?= =?utf-8?B?YTJCNlEvMDhFRTdtbm50WHBqUENrNTZocWs2TmVmK1hEVWRiZkpjNEJGMVgy?= =?utf-8?B?Q2dHMEVHWUI2ZGpxVU14ZmZ4QlEzaThzckpTcWR4VTBkSEtlTFBsZmhZY2x1?= =?utf-8?B?WmNtNys3cnBzNGg1STl6bUNoYzRlQmhYdTVaL0pZbDBMazdJTUxwb0Ewdmhk?= =?utf-8?B?TVgxYndjMnZ4TE1ETGIzWUNPVTIybGVVRmF4cm1VY0NlL3hRaU0rM2JSbVQy?= =?utf-8?B?Sk1MNDFoUjRMZTVKdmp2VXBaMjNtMzJhNGJNamNUTS8wbTBPN3h4eXVBV1A4?= =?utf-8?B?Mkg5TDRhM0UzUkxrbnVCRUxRRHIvT0liN25WckZqMlJGK3Y0K3R5SXBjRWNC?= =?utf-8?B?SXZFOTg3Vm1iQ0cyN1FpTXcrL1Bja2toZFVHaXR2Z3AyWmlVdlVxTmk4SjUz?= =?utf-8?B?N2k3QVYxcjdLTnBkL1NjbWZMamZxa0JtZW5VWm5TdmppUDZoa1ZoVk9OTlBE?= =?utf-8?B?YnlIRHZ4TzBRanc5M01KWXhIaHBhVHpVN1ZDQWpmMjBtQXMvU3UvWEJiVUd0?= =?utf-8?B?WmgrWkRyaEFhZHcxejQveHpKemRaa2RDU292b0lpc1RGSTVtMnNCeG8xbTNK?= =?utf-8?Q?tl7g=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cDZrQkhHNXI0Nmt4RkxuYnRJZmdhTEQ3dGoxM0lWTUlLMjJBQ1g4c281TFpo?= =?utf-8?B?am5DTEZDYy8vWEFQbGk2TVl1dzFSa2J5T3NKTzdDZ1Y0YnViV0tjamY4MHN3?= =?utf-8?B?dkZhVDlyTHMrYTJWZUtZR2tXTEM4bC9yOWtYWU1JeVhkQkVjUkFTWXZmdnQy?= =?utf-8?B?TTFjNWczQVRpcWw3akNnK0VWUVkwMVRLUVdxZm95dnNPalNCUU9YNW1keWNU?= =?utf-8?B?MnB1V0RDK2NlZ3ovZnRkQUNXN0RKNDAvWEJzbnFZcWdNU0t0ajJJWEkvS3B1?= =?utf-8?B?VXFUS1VoNXB2UmNwTmZSSUdLVlhWVkRLajVWWityZU9mSzRuVEl2b0ExU2lR?= =?utf-8?B?dmp2SEw2Mm5QUzVyRjdqM1h4ZUVWS1JQNUdLbyttcnd0RDlCemFwemhjNEEy?= =?utf-8?B?OFE1ZjNIMFNlTkZOZ29Cc01TN0RpcjRoNHpMMmdhMVJXanBUM1BzZGphS1JU?= =?utf-8?B?M1FpcUZkR2V0aW5uMENTNmFYSzBPSXV3WlJsRTRrUzFWWVFLdzFIRG9YWlpP?= =?utf-8?B?SEJvbHNyRVJZV2ZIWmRYeitaTlpFaWE1aFFNTVR1QTJVcmZFeVJmeUpxUUhB?= =?utf-8?B?UXBkY1JXcFFKK1VzS2VBL0hDVEZLUUQ0YjZ3bjFIdGhPZnZiS2FrWFNCQnp2?= =?utf-8?B?VmllSXk0NytnaXVNTHhvWGtpUjFHVTlsbnZlNFUzLzA5Nkk4aEdyZ0pCYVA0?= =?utf-8?B?ZkZLV1RJSW15K2xaYVQrU0E4ZXVGZzRyQllYakthaGdzZnFwYzllaG1OUU10?= =?utf-8?B?ZlRLcUgycllpSno5bXU3MFF5MSt2dkk3K3pDUXZNVEdNYnpnb3RUNWI0NWpt?= =?utf-8?B?ZjBUc3ZjOXB1bk84c21acktGc3dFdVQxeENqZWxRWkNpSjBFbjRGdzJwZWhX?= =?utf-8?B?NjQ2ZHQ3dVdGdXIzMmFES3M2TDE1elpGYWlPTlh0TnlCWTl1cGR1M21ybEJS?= =?utf-8?B?NkNsNEdrL0d6dGVnV0hjM3NRVFZtUkE1Uk9DYlZqekltek5ESW9seWw4cjVa?= =?utf-8?B?OWh3WmczSmdMMTcxSU9IR3ZnR3ZtNUhpT29nY3EvN3laVzFYWHA4R1FMQ0dJ?= =?utf-8?B?THlJQ0luR29qdHowUGlFUjBBUXp6WDZCNFNnMFJLWnh5SmZOQjJ6ZFZoN090?= =?utf-8?B?dHF1SitaM1EyQks4c0tDZ0g4MG9VRkJZUnEvTXRxcHpwUUY0aXZSNUpVSkFS?= =?utf-8?B?TGNCVkU1OHJBK2lWOHhJN2EveEs0T0d1WHZ4dEJoSVdCUzVXTUlrZjlpRmw4?= =?utf-8?B?ci9FMzR1MzJGVE53T1QwOEVPcGVJeEp2cW5NVjNFcjdCa2c4NGh1MmxYaFU2?= =?utf-8?B?ZUJzbGNVcGFoMHAxMjhtcDNhamNFbk1NMVh2OHNwQWhNZmVJaHNiZVpjSjZL?= =?utf-8?B?TElrQ1NCbzBBRWZnbnVUeHdUcmxFZzk5V1ZWbjFYdGdaM1BJM0VLUVBlSFpT?= =?utf-8?B?Wko5Q0NyMDh5dzRRR29iektyL2kxNUJ0NlR4ak5QUHZrNnpnRzJxelNvMUlT?= =?utf-8?B?S2p4WXkyVmR5ZjRoRytRaUUzeURxZkZTYy9vWXRRckJBNndyQ2NsVkw4UDll?= =?utf-8?B?K0Q1SVd6emN0U1JVNHFSSmxVZTVIZ25rbDBOd0M2T3VPeW03cDBRc2s5SHhF?= =?utf-8?B?VTF5NVkxczFFOHFLbUVlYTQxdDdMSHc4VjRYTkkycVN4dHVjRFNYWjVhRGFj?= =?utf-8?B?VzduSEd5UG9TK0Q5c2FuS1lsTjRhYXdrcmVaRENwM0U2b1VrMGpsSEpKTCt3?= =?utf-8?B?ZWgxYzBHNi9UQnluVGJvRDJaNHA5OEpTeDZyT3BhWmJua1J2SnNMekFFUnJM?= =?utf-8?B?ak9PdjRtU2ZZaFNma0dSRG9hSlFJRmFCcVArWWI0KzFpU3ZBUkFYajF1N1Fj?= =?utf-8?B?THZrdEY0RGM0TDFRNlRoUkFWdFR0Z214YVhyN2N2VHUwdkxndnN6RTh5UElz?= =?utf-8?B?T0pCMXI3d0J3bGFkaFg2alJIMG9ZamR4b0FMU1lSTkVzNzBXWGhtZk85ak9C?= =?utf-8?B?NGZMYXRSNE9pb2szRFZwS05wSCtLSlp2NEc1WGZQQmxqaHVOQVhJWE1XZG1T?= =?utf-8?B?QXgwT0ZPQU5CdFJ0MW1IU0syRURMcUlVQ25pWENFS2wzTHJqbVE3dTdEa1Nn?= =?utf-8?B?MFNtZnRJVnFacW5uYzRpZVJBNC9raVQxbGM2OTlybWJyeWFhRUtDVmNiWTl1?= =?utf-8?B?c3Jhck9NU0lscmhFSVdXemVqTC9FVkkxVUQ3YzN2QTJIQlhnVkxNZG81dlVl?= =?utf-8?B?NWdJelhpbzVXQU55c1ZTdlVGQ1BvSGlnYysrM2I5VXlXbFVFSUtocUpmZkIv?= =?utf-8?B?WTNocXV4QjhIbGJjTnFHVURtaWtJR25LWS80OEtrY0swSmxLUGFnZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1b67c43a-31df-4885-5368-08de5d94618b X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 11:08:21.2540 (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: c6jf5fHJuXK1/YlF06NJ7c8QkqwzUmF9Z3U49jaR8JrQmw9d30SRz4rSIsA0vrFGqGjfaPYq3G/U5Tmvw/8/CCBW32iCq0gSceJUrIQbZoM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB8176 On 27/01/2026 10:37 am, Jan Beulich wrote: > On 26.01.2026 18:53, Andrew Cooper wrote: >> --- a/xen/arch/x86/cpu/common.c >> +++ b/xen/arch/x86/cpu/common.c >> @@ -319,8 +319,6 @@ void __init early_cpu_init(bool verbose) >> uint64_t val; >> u32 eax, ebx, ecx, edx; >> >> - c->x86_cache_alignment = 32; >> - >> /* Get vendor name */ >> cpuid(0x00000000, &c->cpuid_level, &ebx, &ecx, &edx); >> *(u32 *)&c->x86_vendor_id[0] = ebx; >> @@ -352,6 +350,7 @@ void __init early_cpu_init(bool verbose) >> if (edx & cpufeat_mask(X86_FEATURE_CLFLUSH)) { >> unsigned int size = ((ebx >> 8) & 0xff) * 8; >> >> + c->x86_clflush_size = size; >> c->x86_cache_alignment = size; > With this change, can't the writing of the field in generic_identify() > go away? CPU_DATA_INIT() in particular doesn't invalidate it. No, it can't.  The value needs setting up on every AP, right now at least. > Perferably > with that dropped (unless of course there is a reason not to): > Reviewed-by: Jan Beulich Hopefully this is a good enough reason.  I know we agreed to make it a single global, but that's future work. > > Tangentially, "cpuid=no-clflush" didn't have any effect on any of this so > far, and also isn't going to have with the changes you make. The line immediately out of context above will applies the clear cap mask, so will cause cpuid=no-clflush to take effect. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 27 11:24:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 11:24:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214274.1524641 (Exim 4.92) (envelope-from ) id 1vkhAm-0008Kw-Bd; Tue, 27 Jan 2026 11:23:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214274.1524641; Tue, 27 Jan 2026 11:23:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkhAm-0008Kp-91; Tue, 27 Jan 2026 11:23:52 +0000 Received: by outflank-mailman (input) for mailman id 1214274; Tue, 27 Jan 2026 11:23: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 1vkhAl-0008Kj-9b for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 11:23:51 +0000 Received: from mail137-14.atl71.mandrillapp.com (mail137-14.atl71.mandrillapp.com [198.2.137.14]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a6613dc9-fb72-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 12:23:49 +0100 (CET) Received: from pmta07.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail137-14.atl71.mandrillapp.com (Mailchimp) with ESMTP id 4f0jhg4k57z705g77 for ; Tue, 27 Jan 2026 11:23:47 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 1500cc45b4a045e6b3cdf24bf6141ac0; Tue, 27 Jan 2026 11:23: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: a6613dc9-fb72-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1769513027; x=1769783027; bh=97vk7AvTfAXGbYHG1iUiB3T8K0vZMfEIat8TRC59kbE=; 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=PBb2ZjRryBnTtjti84AaTomCex+pDN14mAoeetTQgPAxb5HAs5QPcX30+6EIQFBES xd6IncQfo3VmIYHKiWzSY6PA+wuHMcGMWCN/2WhIpGdHYMnjg2E9ETQl9NsmWYf9d7 G1hELwEvlg1dhnrp8KPuokdZn068Gm4+NfMq30zJjttSW0WT9DyEyR32Sj+qk0XXx5 Vzu9fc4+OPY1CLwqjTbDx8i7/5VBkUkhj7b8hsA7UpASAc2Bu1A/R7+Og8V9+401bM ubkaPnd57u+3DwJ2g7bKI1iSVx8doNoZCbkE6+A4g8CWu+3oKDWQWMbyQaXPL7CA5n onmY3gPhKtQLw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1769513027; x=1769773527; i=teddy.astie@vates.tech; bh=97vk7AvTfAXGbYHG1iUiB3T8K0vZMfEIat8TRC59kbE=; 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=aP+QmXG33b2g1PhmGgl8r65/PZgbCHeRBVhlfMoLjo3sMYPoiPAn8kKe9USD8W31O pDUYvH//7k8A2/eGd/iZovDrnqL5MewDxPx8yw/JSyjGns4qUDGHeeZrjty+QOufo3 zkcGRDgRmJZnu4+bmCqK9J69UN4uXDb/wYqNagEfro7m2EE89aRoqVQXRDt2WG89hC 5o8uxTkv0c5oz+gHw6HY+DrlKYKN2BiuhjZVy0vGBrQJyVih4GxnR3PGvZBPkgtGAu I475gqKXe2BCJHftvpMoFtgiLGvOKOvO8sfRFNkeLPWPtxE4ytcsAIQjnfG7J1CWxC LHFWnLaNqW6VA== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=2000/16]=20x86/cpu:=20Cleanup=20for=20NX=20adjustments?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1769513026490 Message-Id: <92bff6a4-8fb0-4992-8305-8386f480de74@vates.tech> To: "Andrew Cooper" , Xen-devel Cc: "Jan Beulich" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Julian Vetter" References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> In-Reply-To: <20260126175345.2078371-1-andrew.cooper3@citrix.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.1500cc45b4a045e6b3cdf24bf6141ac0?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260127:md Date: Tue, 27 Jan 2026 11:23:47 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 26/01/2026 =C3=A0 18:56, Andrew Cooper a =C3=A9crit=C2=A0: > I was hoping this to be a patch or two, but it got out of hand... > > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/228707889= 1 > https://gitlab.com/xen-project/hardware/xen-staging/-/commits/andrew/nx > > The branch has one extra patch to fake up the firmware settings being set= to > Gitlab CI, not included in this series. > > Julien: This ought to suitable to rebase your cleanup on to. In the end,= I > did the AMD adjustment mostly because I needed it to test the correctness= of > the prior cleanup. > > The final 4 patches are tangential cleanup which I've kept out of the pri= or > work in case we wish to backport it. Everything prior is relevant to > untangling, and mostly for the benefit of the AMD side. > > The early patches are hopefully non-controvertial. Later patches are a l= ittle > more RFC, and in need of further testing. > > Andrew Cooper (16): > x86/cpu: Fix boot time cache flushing > x86/cpu: Drop cpuid_level adjustment from generic_identify() > x86/intel: Drop the paddr_bits workaround for P4 Nocona/Prescott CPUs > x86/cpu: Fold generic_identify() into its single caller > x86/cpu: Move per-CPU actions out of the vendor early_init() hook > x86/cpu: Rework the vendor early_init() hooks to be __init > x86/cpu: Call the vendor early_init() hook in early_cpu_init() > xen/sysctl: Drop XEN_SYSCTL_get_cpu_levelling_caps > x86/intel: Always check MSR_MISC_ENABLE on all CPUs > x86/amd: Always probe and configure the masking MSRs > x86/amd: Fix re-activation of TopoExt on Fam15h CPUs > x86/amd: Probe for NX support and re-activate if possible > x86/cpu: Drop NOISY_CAPS > x86/cpu: Drop default_init() and default_cpu > x86/cpu: Clean up use of LCAP_* constants > x86/cpuid: Drop the include of public/sysctl.h > > CHANGELOG.md | 2 + > tools/flask/policy/modules/dom0.te | 1 - > tools/include/xenguest.h | 1 - > tools/libs/guest/xg_cpuid_x86.c | 14 --- > xen/arch/x86/boot/head.S | 1 - > xen/arch/x86/boot/trampoline.S | 29 +++--- > xen/arch/x86/boot/wakeup.S | 27 +++--- > xen/arch/x86/cpu/amd.c | 107 ++++++++++++++------ > xen/arch/x86/cpu/common.c | 135 +++++++++++++------------- > xen/arch/x86/cpu/cpu.h | 7 +- > xen/arch/x86/cpu/hygon.c | 2 + > xen/arch/x86/cpu/intel.c | 74 ++++---------- > xen/arch/x86/domain.c | 10 +- > xen/arch/x86/flushtlb.c | 19 ++-- > xen/arch/x86/include/asm/cpuid.h | 17 ++-- > xen/arch/x86/include/asm/hvm/hvm.h | 2 + > xen/arch/x86/include/asm/hvm/vlapic.h | 2 + > xen/arch/x86/include/asm/hvm/vpt.h | 2 + > xen/arch/x86/include/asm/trampoline.h | 7 +- > xen/arch/x86/sysctl.c | 6 -- > xen/include/public/sysctl.h | 22 +---- > xen/xsm/flask/hooks.c | 4 - > xen/xsm/flask/policy/access_vectors | 2 - > 23 files changed, 238 insertions(+), 255 deletions(-) > Tested on a Intel machine with "DEP" disabled, and "Require NX support" disabled, I get a pagefault in hpet code > (XEN) Xen version 4.22-unstable (tsnake41@(none)) (gcc (Alpine 15.2.0) 15= .2.0) debug=3Dy Tue Jan 27 12:06:46 CET 2026 > (XEN) Latest ChangeSet: Mon Jan 26 17:53:45 2026 +0000 git:6491616ddd > (XEN) build-id: 035024497a4cadebf9e5a2ded61f63ac > (XEN) re-enabled NX (Execute Disable) protection > (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3 (raw= 000306c3) > (XEN) BSP microcode revision: 0x0000001a > (XEN) microcode: Bad data in container > (XEN) Microcode: Parse error -22 > (XEN) Bootloader: EFI > (XEN) Command line: dom0_mem=3D2G iommu=3Dverbose,debug console=3Dcom1 co= m1=3D115200,8n1 guest_loglvl=3Dall loglvl=3Dall > (XEN) Xen image load base address: 0xc3a00000 > (XEN) Video information: > (XEN) VGA is graphics mode 1920x1080, 32 bpp > (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds > (XEN) Disc information: > (XEN) Found 0 MBR signatures > (XEN) Found 1 EDD information structures > (XEN) EFI RAM map: > (XEN) [0000000000000000, 000000000004efff] (usable) > (XEN) [000000000004f000, 000000000004ffff] (reserved) > (XEN) [0000000000050000, 000000000009dfff] (usable) > (XEN) [000000000009e000, 000000000009ffff] (reserved) > (XEN) [0000000000100000, 00000000c60c3fff] (usable) > (XEN) [00000000c60c4000, 00000000c60cafff] (ACPI NVS) > (XEN) [00000000c60cb000, 00000000c650ffff] (usable) > (XEN) [00000000c6510000, 00000000c68c6fff] (reserved) > (XEN) [00000000c68c7000, 00000000d9867fff] (usable) > (XEN) [00000000d9868000, 00000000d98f1fff] (reserved) > (XEN) [00000000d98f2000, 00000000d991bfff] (ACPI data) > (XEN) [00000000d991c000, 00000000d9a06fff] (ACPI NVS) > (XEN) [00000000d9a07000, 00000000d9ffefff] (reserved) > (XEN) [00000000d9fff000, 00000000d9ffffff] (usable) > (XEN) [00000000dc000000, 00000000de1fffff] (reserved) > (XEN) [00000000f8000000, 00000000fbffffff] (reserved) > (XEN) [00000000fec00000, 00000000fec00fff] (reserved) > (XEN) [00000000fed00000, 00000000fed03fff] (reserved) > (XEN) [00000000fed1c000, 00000000fed1ffff] (reserved) > (XEN) [00000000fee00000, 00000000fee00fff] (reserved) > (XEN) [00000000ff000000, 00000000ffffffff] (reserved) > (XEN) [0000000100000000, 000000041fdfffff] (usable) > (XEN) ACPI: RSDP D9901298, 0024 (r2 HPQOEM) > (XEN) ACPI: XSDT D99012BC, 00B4 (r1 HPQOEM SLIC-BPC 20170509 AMI 1001= 3) > (XEN) ACPI: FACP D9910018, 010C (r5 HPQOEM SLIC-BPC 20170509 AMI 1001= 3) > (XEN) ACPI: DSDT D99021D0, DE46 (r2 HPQOEM SLIC-BPC 1 INTL 2009111= 2) > (XEN) ACPI: FACS D9A05080, 0040 > (XEN) ACPI: APIC D9910128, 0072 (r3 HPQOEM SLIC-BPC 20170509 AMI 1001= 3) > (XEN) ACPI: FPDT D99101A0, 0044 (r1 HPQOEM SLIC-BPC 20170509 AMI 1001= 3) > (XEN) ACPI: SSDT D99101E8, 0539 (r1 PmRef Cpu0Ist 3000 INTL 2012071= 1) > (XEN) ACPI: SSDT D9910728, 0AD8 (r1 PmRef CpuPm 3000 INTL 2012071= 1) > (XEN) ACPI: SSDT D9911200, 01C7 (r1 PmRef LakeTiny 3000 INTL 2012071= 1) > (XEN) ACPI: MCFG D99113C8, 003C (r1 HPQOEM SLIC-BPC 20170509 MSFT 9= 7) > (XEN) ACPI: HPET D9911408, 0038 (r1 HPQOEM SLIC-BPC 20170509 AMI. = 5) > (XEN) ACPI: SSDT D9911440, 036D (r1 SataRe SataTabl 1000 INTL 2012071= 1) > (XEN) ACPI: SSDT D99117B0, 348C (r1 SaSsdt SaSsdt 3000 INTL 2009111= 2) > (XEN) ACPI: SSDT D9914C40, 668F (r1 COMPAQ WMI 1 MSFT 300000= 1) > (XEN) ACPI: SLIC D991B2D0, 0176 (r1 HPQOEM SLIC-BPC 1 = 0) > (XEN) ACPI: MSDM D991B448, 0055 (r3 HPQOEM SLIC-BPC 20170509 HPQ 1001= 3) > (XEN) ACPI: ASF! D991B4A0, 00A5 (r32 INTEL HCG 1 TFSM F42= 40) > (XEN) ACPI: TCPA D991B548, 0032 (r2 APTIO4 NAPAASF 1 MSFT 100001= 3) > (XEN) ACPI: BGRT D991B580, 0038 (r0 HPQOEM SLIC-BPC 20170509 AMI 1001= 3) > (XEN) ACPI: DMAR D991B5B8, 00B8 (r1 INTEL HSW 1 INTL = 1) > (XEN) ACPI: WPBT D9901370, 0034 (r1 ABT-NT ABT-WPBT 1 ABTW 2012040= 2) > (XEN) System RAM: 16274MB (16664864kB) > (XEN) No NUMA configuration found > (XEN) Faking a node at 0000000000000000-000000041fe00000 > (XEN) Domain heap initialised > (XEN) SMBIOS 2.7 present. > (XEN) DMI 2.7 present. > (XEN) PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 3f > (XEN) PCI: MCFG area at f8000000 reserved in E820 > (XEN) PCI: Using MCFG for segment 0000 bus 00-3f > (XEN) [VT-D]Host address width 39 > (XEN) [VT-D]found ACPI_DMAR_DRHD: > (XEN) [VT-D] dmaru->address =3D fed90000 > (XEN) [VT-D]drhd->address =3D fed90000 iommu->reg =3D ffff82c000209000 > (XEN) [VT-D]cap =3D c0000020660462 ecap =3D f0101a > (XEN) [VT-D] endpoint: 0000:00:02.0 > (XEN) [VT-D]found ACPI_DMAR_DRHD: > (XEN) [VT-D] dmaru->address =3D fed91000 > (XEN) [VT-D]drhd->address =3D fed91000 iommu->reg =3D ffff82c00020b000 > (XEN) [VT-D]cap =3D d2008020660462 ecap =3D f010da > (XEN) [VT-D] IOAPIC: 0000:f0:1f.0 > (XEN) [VT-D] MSI HPET: 0000:f0:0f.0 > (XEN) [VT-D] flags: INCLUDE_ALL > (XEN) [VT-D]found ACPI_DMAR_RMRR: > (XEN) [VT-D] endpoint: 0000:00:1d.0 > (XEN) [VT-D] endpoint: 0000:00:1a.0 > (XEN) [VT-D] endpoint: 0000:00:14.0 > (XEN) [VT-D]drivers/passthrough/vtd/dmar.c:610: RMRR: [d9888000,d9894fff= ] > (XEN) [VT-D]found ACPI_DMAR_RMRR: > (XEN) [VT-D] endpoint: 0000:00:02.0 > (XEN) [VT-D]drivers/passthrough/vtd/dmar.c:610: RMRR: [dc000000,de1fffff= ] > (XEN) Using APIC driver default > (XEN) ACPI: PM-Timer IO Port: 0x408 (24 bits) > (XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0] > (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0] > (XEN) ACPI: 32/64X FACS address mismatch in FADT - d9a05080/0000000000000= 000, using 32 > (XEN) ACPI: wakeup_vec[d9a0508c], vec_size[20] > (XEN) ACPI: Local APIC address 0xfee00000 > (XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0]) > (XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23 > (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) > (XEN) ACPI: IRQ0 used by override. > (XEN) ACPI: IRQ2 used by override. > (XEN) ACPI: IRQ9 used by override. > (XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000 > (XEN) ACPI: BGRT: invalidating v1 image at 0xcbc74018 > (XEN) Using ACPI (MADT) for SMP configuration information > (XEN) SMP: Allowing 4 CPUs (0 hotplug CPUs) > (XEN) IRQ limits: 24 GSI, 808 MSI/MSI-X > (XEN) [VT-D]drivers/passthrough/vtd/qinval.c:520: QI: using 256-entry rin= g(s) > (XEN) Switched to APIC driver x2apic_mixed > (XEN) arch/x86/i8259.c:384: PIC aliasing mask: 1c > (XEN) CPU0: 800 ... 3400 MHz > (XEN) xstate: size: 0x340 and states: 0x7 > (XEN) arch/x86/cpu/mcheck/mce_intel.c:773: MCA Capability: firstbank 0, e= xtended MCE MSR 0, BCAST, CMCI > (XEN) CPU0: Intel machine check reporting enabled > (XEN) Speculative mitigation facilities: > (XEN) Hardware hints: > (XEN) Hardware features: > (XEN) Compiled-in support: INDIRECT_THUNK RETURN_THUNK SHADOW_PAGING HA= RDEN_ARRAY HARDEN_BRANCH HARDEN_GUEST_ACCESS HARDEN_LOCK > (XEN) Xen settings: BTI-Thunk: RETPOLINE, SPEC_CTRL: No, Other: BRANCH_= HARDEN > (XEN) L1TF: believed vulnerable, maxphysaddr L1D 46, CPUID 39, Safe add= ress 8000000000 > (XEN) Support for HVM VMs: RSB EAGER_FPU > (XEN) Support for PV VMs: EAGER_FPU > (XEN) XPTI (64-bit PV only): Dom0 enabled, DomU enabled (with PCID) > (XEN) PV L1TF shadowing: Dom0 disabled, DomU enabled > (XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2) > (XEN) Initializing Credit2 scheduler > (XEN) load_precision_shift: 18 > (XEN) load_window_shift: 30 > (XEN) underload_balance_tolerance: 0 > (XEN) overload_balance_tolerance: -3 > (XEN) runqueues arrangement: socket > (XEN) cap enforcement granularity: 10ms > (XEN) load tracking window length 1073741824 ns > (XEN) Using IDT event delivery > (XEN) arch/x86/time.c:495: PIT aliasing mask: 10 > (XEN) ----[ Xen-4.22-unstable x86_64 debug=3Dy Not tainted ]---- > (XEN) CPU: 0 > (XEN) RIP: e008:[] hpet_setup+0x6b/0x120 > (XEN) RFLAGS: 0000000000010082 CONTEXT: hypervisor > (XEN) rax: ffff82cffff3a000 rbx: 0000000000000000 rcx: 00000000000000= 0c > (XEN) rdx: ffff82fffffffffe rsi: 8000000000000000 rdi: ffff8300c421ff= f8 > (XEN) rbp: ffff82d04065fd28 rsp: ffff82d04065fd18 r8: 00000000000000= 46 > (XEN) r9: ffff82d04092e180 r10: ffff82d04092e188 r11: 00000000000000= 10 > (XEN) r12: ffff82d04069c0c0 r13: ffff82d040666530 r14: ffff82d04092f0= a8 > (XEN) r15: ffff82d04069c0d8 cr0: 000000008005003b cr4: 00000000001506= e0 > (XEN) cr3: 00000000c4222000 cr2: ffff82cffff3a000 > (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 00000000000000= 00 > (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 > (XEN) Xen code around (hpet_setup+0x6b/0x120): > (XEN) 00 a0 f3 ff cf 82 ff ff <8b> 10 84 d2 0f 84 80 00 00 00 a1 04 a0 f= 3 ff cf > (XEN) Xen stack trace from rsp=3Dffff82d04065fd18: > (XEN) ffff82d040666530 ffff82d04092f0a8 ffff82d04065fd48 ffff82d040649= 63a > (XEN) ffff82d040666530 ffff82d04092f0a8 ffff82d04065fd78 ffff82d040649= 7c9 > (XEN) 0000000000000010 ffff82d04069c0c0 ffff82d040666530 ffff82d04092f= 0a8 > (XEN) ffff82d04065fdb8 ffff82d040649fef 0000000000000000 ffff82d04092f= 1a0 > (XEN) ffff82d04092f1a0 ffff82d040808208 0000000000000002 ffff83041a9b8= 000 > (XEN) ffff82d04065ff00 ffff82d0406449d2 ffff82d04069b020 000000041a9c8= 000 > (XEN) ffff82d04069b050 0000000100000000 ffff82d04093ff08 0000000001102= 000 > (XEN) ffff82d040696014 ffff82d04069aff0 000000041dfe5400 0000000000100= 000 > (XEN) 0000000000000000 0000050000000000 ffffffff00000163 000000000041f= e00 > (XEN) 0000000000000019 0000000601000000 00000001ffffffff ffff82d04065f= f08 > (XEN) ffff82d04069b020 0000000000000000 0000000000000000 0000000000000= 000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000= 000 > (XEN) 0000000000000000 0000000000000000 0000000800000000 0000000100000= 06e > (XEN) 0000000000000003 00000000000002f8 ffff82d040927000 ffff82d040927= 000 > (XEN) ffffffffffffffff 0000000000000000 00000000cbcffe58 0000000000000= 000 > (XEN) 00000000c4068acb 00000000c29e2620 0000000000000000 0000000000000= 000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000= 000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000= 000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000= 000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000= 000 > (XEN) Xen call trace: > (XEN) [] R hpet_setup+0x6b/0x120 > (XEN) [] F arch/x86/time.#init_hpet+0x30/0x119 > (XEN) [] F arch/x86/time.#try_platform_timer+0x17/0x= 12b > (XEN) [] F early_time_init+0x1e7/0x2ec > (XEN) [] F __start_xen+0x1f2e/0x25b1 > (XEN) > (XEN) Pagetable walk from ffff82cffff3a000: > (XEN) L4[0x105] =3D 00000000c4221063 ffffffffffffffff > (XEN) L3[0x13f] =3D 00000000c421f063 ffffffffffffffff > (XEN) L2[0x1ff] =3D 00000000c432b063 ffffffffffffffff > (XEN) L1[0x13a] =3D 80000000fed00173 ffffffffffffffff > (XEN) > (XEN) **************************************** > (XEN) Panic on CPU 0: > (XEN) FATAL PAGE FAULT > (XEN) [error_code=3D0009] > (XEN) Faulting linear address: ffff82cffff3a000 > (XEN) **************************************** > (XEN) > (XEN) Reboot in five seconds... > (XEN) Resetting with ACPI MEMORY or I/O RESET_REG. With "require NX", I don't get anything on the serial console, and VGA gives a black screen after loading Xen. I'm not sure what's going on in this case. If "DEP" is enabled in firmware, there are no issues so far. Teddy -- | Vates XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Jan 27 11:35:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 11:35:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214283.1524651 (Exim 4.92) (envelope-from ) id 1vkhLq-0001dV-9a; Tue, 27 Jan 2026 11:35:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214283.1524651; Tue, 27 Jan 2026 11:35: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 1vkhLq-0001dO-6q; Tue, 27 Jan 2026 11:35:18 +0000 Received: by outflank-mailman (input) for mailman id 1214283; Tue, 27 Jan 2026 11:35: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 1vkhLo-0001dI-Sl for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 11:35:16 +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 3f18905d-fb74-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 12:35:14 +0100 (CET) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-42fb2314f52so3264054f8f.0 for ; Tue, 27 Jan 2026 03:35:14 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1b6e2besm37486363f8f.0.2026.01.27.03.35.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 03:35:13 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3f18905d-fb74-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769513714; x=1770118514; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=pWigye4U0/0vGD3dyHfCQyYFhV542tvoBDe1W7IDg5o=; b=VjQSq7dqvauchK4UWVq0yEwGR9aVNKLv1xilmq8gtNCHQZquKmVSpYkSwIxyv7E6IR iookmgFwEwtWUwSHbDl5NtlbtX+n9QjGSFy3BeAxWZtEtW+ZnKv5FQEqhyesvw/UUJ0J u1RhB9OiHHtCe/1ooh4nH9o1caYZNrfok0pb0aj/3vB5kJdado3N4cR6oez/Hnl7+JUt fBlgonoFVgBGT/q+hEhoW0iJWHHCe/BM/v26GOwWv0UARAc6EDmu38V/A+ek/tgjWIZ2 Y57a/s797FcAyfM93tBTyH/iuoPi6au12zdPT8+lGVhrgJd5ypo707xekreffRbN+AYI ALlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769513714; x=1770118514; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=pWigye4U0/0vGD3dyHfCQyYFhV542tvoBDe1W7IDg5o=; b=vKWUATWkzdVvUlF7z66eYCM2pzukDiLynOlbaFNN1/Eos+gjBrzssUO6oioSu13BdH 4c2hZwT3jeBMWr5rIobCnz4vqIEAZk9AbKoEVd4me3nTMr7ONyGvharts1y78l8F15G0 6AKJ/cyG58sUPfOG0pJdaAgqTKZ1mSQ6/qJjQA+7IgJWhx1v3HKb2TAlB+h/uqZmAlOM L1e3LaDEThgTZGBxbJIbii9Q4Il0oBqgTAqMS5jIg+a87ZX+Vr81s9nyV6T/bPcriyLK FwkD1b33VdNqyGjczmrKJrumTyMc5/Up/cIDkss9oCNiYlO3WV1BzRZM97BahWdf532l PQyQ== X-Forwarded-Encrypted: i=1; AJvYcCXxBRAqSappVk/QN+18Ck8ETPzLX+YZgytD3YXt+aQEp8kgl4GaK7B/N6zwOnhGNKfIpNM1OZt5Dd0=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz8+ZO1yKVgwNQpGVjuyGgHxlXIQxQhDHrPwTghQtsaZW7VvuOr ieO3Wh0NPnHJr6vx13xUy9TOy4rSZvaeYF8FWk3mxnttkqSP+wE2St0golH42dc2ZA== X-Gm-Gg: AZuq6aIAC6/reh5jWxZ/4Z1BzbILB1YZpATxNsRkbCiZCixYSwbVAJc3yCb/RwMaSmq H7CQxoOBkG5QuYcAaqV43vc4WeXch6eBe9x0b8AV9MIFf+MDLOVKqdAYhjAo2MGUDIpBnUGq34h hC1+iFpjfhhWF6+3WJgBjm5Drg/3w+bWjbtCCiABL/M4VUWI6qC2BLa6TBDXuFHd/ZFz+bwJR0/ Go22Xs2aEmaKp7gsMUx5jskRv6vLoC3fZ88bvMn9JyRL/qALEkeNB94aOtDDhk7yX3jkAsegvUN EsyJ8tcrQRKFEP2wsOQM2GR/3MorRtBUKSmLgH+lhZNxLGLS+YZn+swB5teunILwY7nz4YRPXju 9NKIFmIMqpTiQfBmurao4lAF6IJao51aWGyvcu0q9f5BPxUvtQ7ItYKe/eLdkGlz8+oZZMfVsq4 2bDBQrL+rOjUXb3aTBPBBuH8TEbSxppsisvNhOs32A7/D27+0/PVMdumvn+mmk8qGTgV0wfHkch qY= X-Received: by 2002:a05:6000:61e:b0:435:9ee1:f90d with SMTP id ffacd0b85a97d-435dd02e229mr2168600f8f.10.1769513713674; Tue, 27 Jan 2026 03:35:13 -0800 (PST) Message-ID: <52fe1a23-70bf-4282-a41a-7b153fd1f7c9@suse.com> Date: Tue, 27 Jan 2026 12:35:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 01/16] x86/cpu: Fix boot time cache flushing To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-2-andrew.cooper3@citrix.com> <15978c88-5ea9-4159-951b-27c9fc004756@suse.com> <3ded84f3-505e-40f1-b7d5-f136663af7cd@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: <3ded84f3-505e-40f1-b7d5-f136663af7cd@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 27.01.2026 12:08, Andrew Cooper wrote: > On 27/01/2026 10:37 am, Jan Beulich wrote: >> On 26.01.2026 18:53, Andrew Cooper wrote: >>> --- a/xen/arch/x86/cpu/common.c >>> +++ b/xen/arch/x86/cpu/common.c >>> @@ -319,8 +319,6 @@ void __init early_cpu_init(bool verbose) >>> uint64_t val; >>> u32 eax, ebx, ecx, edx; >>> >>> - c->x86_cache_alignment = 32; >>> - >>> /* Get vendor name */ >>> cpuid(0x00000000, &c->cpuid_level, &ebx, &ecx, &edx); >>> *(u32 *)&c->x86_vendor_id[0] = ebx; >>> @@ -352,6 +350,7 @@ void __init early_cpu_init(bool verbose) >>> if (edx & cpufeat_mask(X86_FEATURE_CLFLUSH)) { >>> unsigned int size = ((ebx >> 8) & 0xff) * 8; >>> >>> + c->x86_clflush_size = size; >>> c->x86_cache_alignment = size; >> With this change, can't the writing of the field in generic_identify() >> go away? CPU_DATA_INIT() in particular doesn't invalidate it. > > No, it can't.  The value needs setting up on every AP, right now at least. Are you sure? APs inherit part of the BSP's data (initialize_cpu_data()), and reset_cpuinfo() doesn't clear ->x86_clflush_size afaics. >> Tangentially, "cpuid=no-clflush" didn't have any effect on any of this so >> far, and also isn't going to have with the changes you make. > > The line immediately out of context above will applies the clear cap > mask, so will cause cpuid=no-clflush to take effect. This concerns me. With your change, "cpuid=no-clflush" will lead to an unconditional panic() then. Whereas previously, with cleared_caps[] being applied by identify_cpu() only after generic_identify() has already evaluated the CLFLUSH bit, there was no effect at all. I don't think this panic()ing is desirable, but as an absolute minimum this (drastic) change in behavior would want calling out in the description. Further, if the panic() was to stay, there's no point having cpu_has_clflush evaluate to anything other than constant true anymore. Again tangentially (and partly the reason why I overlooked that aspect originally): While early_cpu_init() respects cleared_caps[] for leaf 1, it doesn't for any of leaf 7's subleaves, nor for ARCH_CAPS. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 11:37:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 11:37:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214291.1524662 (Exim 4.92) (envelope-from ) id 1vkhOQ-0002EP-Ls; Tue, 27 Jan 2026 11:37:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214291.1524662; Tue, 27 Jan 2026 11: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 1vkhOQ-0002EI-J3; Tue, 27 Jan 2026 11:37:58 +0000 Received: by outflank-mailman (input) for mailman id 1214291; Tue, 27 Jan 2026 11:37:57 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkhOP-0002EC-GU for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 11:37:57 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9f4c8006-fb74-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 12:37:56 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CO1PR03MB5937.namprd03.prod.outlook.com (2603:10b6:303:6e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Tue, 27 Jan 2026 11:37:53 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9542.015; Tue, 27 Jan 2026 11:37: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: 9f4c8006-fb74-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mubmgtz88Mw7kT4RhNqW14kt4tnos65dl3a0CsgXXG1HWYJVyWKLHLLXEN+tEE6fDn74h4d6U87VOZAti9vizYRXPBuHzq3nonSQFG4r7rkX6GO0l/6WWuBcsNrNpHMd0iWMalnlxWD9Z6gqW4BG4paevryFQ8yRyYnfxfdlJHlb1Zp2bH+uFh7pHwnzc9bMyW15weIu3catLgSMOYQaeK0Ot3purjIdmdag3DlcRq++nSzixova3qD0slWUfgOg7arC5FZfoxPR2GXDjUtq8LQSZX+7D0uSqVbVKrSd5tnYLEZ69ts9u3v0Of+wQoJ3U2fvSb4goXzPSlMpkUhuUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8NFuY4wQwzadNaJ563PeByDTQIkjF147Fzxoc2wrBL4=; b=qL8qA/ND2gjcBYHmy/U8KqO2DdiKMayGxEOAh6swf/MGT/TXNWdEGZBRRJV1ET3JxkfFOP+aeJAzDtq7WbFRwLrMZlFJNpnTGeZTiYfRGsuVQybaO3JU6WubbBC02U1/iwoTF9+3CtHQRONW51y3ldFE9nKuh3mdEy++9sNrT2fhqmItsqOcEY/8mPCMndEaf5WPD05mYJZAKwNhlwSk0MbkLGg8uqsQonXFA42NkobVaCfWGc8DSRkBWyUxMAh+gJ/hKRMjl77dEoDnjzIIsbrEM0Ap9jY0YDflE6wf9SNMSbBtIPxkvH+dU0tlY13OHWH+CiuMGnboNohzqa7DYQ== 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=8NFuY4wQwzadNaJ563PeByDTQIkjF147Fzxoc2wrBL4=; b=TqZTtOhRa1dHhXSD4Z+Cdw0IGXbXf+u+YGvbfNO2QIHuoa1tHWfUvv2eGZge9opkBAZgNhs2ZOyCkSnZLN1tyx6f95aTS1O+8UAapsVVlKlVLjedY81brnlvkmOuDtXXJYAJm7kqILAx24FX4DNePSjILjAPFDg8UQDCnY9esuo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <658c0167-c3df-4acd-92f8-8c3f022ae453@citrix.com> Date: Tue, 27 Jan 2026 11:37:49 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter Subject: Re: [PATCH 00/16] x86/cpu: Cleanup for NX adjustments To: Teddy Astie , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <92bff6a4-8fb0-4992-8305-8386f480de74@vates.tech> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <92bff6a4-8fb0-4992-8305-8386f480de74@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0625.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:294::23) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CO1PR03MB5937:EE_ X-MS-Office365-Filtering-Correlation-Id: 0ff901c1-df3b-4dec-739c-08de5d98820b 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?U2VlMTZ1cFBHSnViTHdXRDFZZlRVT1hvemN0c3pwUHZncXdOb0lETFFQeFlX?= =?utf-8?B?TUVhTWVWaTg1L0szczhDZU5TdFlUV0FuUmhlUWFRNVJlS3hNcnlLN1U0blRS?= =?utf-8?B?RU9NV3RzRFBpcmZYdGFpTmFIcUVrZjh4alBrbXNXKzdzZVNtR1Z5dDBmQXpi?= =?utf-8?B?TDFUNFA5ZUZLZG5SeVZlNUVaNjhxa1E1NVkxNkRWbS83WGdqd1hTQ0VsbE5Q?= =?utf-8?B?c082S2tMV2JrWnp1eGxEMSsyZUlJZUZHcnhaM1dxVFl1eVIwazQyRFdqZlRx?= =?utf-8?B?WWdRYVZIMjdCTkQyWGs3ekRvdFY3ZW41elRpUnRFZmlZS0VDdjAyV1lzM3U5?= =?utf-8?B?Q0ZZSDJ5bmdCejFkZGlXekpsa3hwMmZJa3MvMG5RdXErVnRFWGI1ZWZjMWJZ?= =?utf-8?B?ajZhMWFmUVlVZFlSSlZwN2VDamxzMytjcllTK0svM2ZPOEw5MjBEREMrdU9z?= =?utf-8?B?VmQ3Z3lxUXVPMUFzNVRGOVFEZG8xVGprTHZ3ZERQazJCaVpDNnJhL3ZxSlVk?= =?utf-8?B?WUp6OHVWdEhyRm9hZXFjdzVmV1gvdmsrdjNaek91Qld0bVVJbHhVN1B6ajdj?= =?utf-8?B?MDExTFI4MDBvcFAzaWNwbytnUFI4S1RBNkxUSzl1dW1IcVBjSTYzdlBROFZr?= =?utf-8?B?eVlnVFhNWGZLSHp3VEtySFNMc0xSbW5VMEpUd0F3cy9uOUtFTEFDQ2REVzRa?= =?utf-8?B?SlgwUkx4K24zK1BlN00vR3NMZHROd1hyRHF6bTE2WjVpRVpncGFtRkViV0hU?= =?utf-8?B?MmdWbERtdmxwVmtNcE9GR2VmdFhpL21WVHUzeEdlZFRiaHlTemFUdlVucW5L?= =?utf-8?B?ZmZ0dkQ0ZFBZY1FGakFyV0JXVFhpREdjb2hkbFQzeFFaYW5BdVd6Sk11MWNW?= =?utf-8?B?SGluelZqdnplSWkrZU1RZ3RiTytNUGJQKzY2OXlOc2wzL2xLMnFjc2lLOWhs?= =?utf-8?B?UWJiSDhlSjVicXc2QzlzTUJSN3BPWnpYZW54aENzaHgzby9yUjFGd25uSnFm?= =?utf-8?B?WWpVcXg1cU92M3VWOEhDWnZWVktRdmtaSXp4QlFYc0wweDE2M0phOW11MnF2?= =?utf-8?B?eGxuUWJ1eUw2b1FXVmRnZE44R3hmOUoxSnZhTmtDRHJ3UUZlUFdaZjNpWHlL?= =?utf-8?B?M1dOOU9QelRqUGVML1NkVnhEeHNjVy9hc2R3dmVqaG9TMmFmSHQ0OHdob000?= =?utf-8?B?czdjTDdHNkxlQUNjYlV6K3FaMk9raThDMjJSemxMVk0wNWsyV0d2akZZdmhE?= =?utf-8?B?VkliOFJNdDhWSlZEYVQ0MTNJMk1NU0NDNlRpcllWQ2pvRXJGS1ErQVg0Rk00?= =?utf-8?B?MENoWGFBRW1FamFCNm4yK3YyL2RxR1l1eEdRZHdHNHhCRjNUTDZITWhXU1lo?= =?utf-8?B?M0wyYnlhclF1dGs1VTNjLzdEbHFjeXd4bHFvZnlxTk1VNzlUd0pTU1hqbHRR?= =?utf-8?B?b3M3aU9kbWN1UzIzWDFPSDFBUUg0dE0wWDZJb3VINXZBaEU0MWR5WDdZeXFX?= =?utf-8?B?TkJuaWNnbFFyV2FLV0o0bG9aZXE3ZnBUWFgyaDNkaXovNy8xeGx5cSs5Q2p1?= =?utf-8?B?OVdIRGhxRGM1Y2RoSUUrYkw2d1ZneDRKMXo3aFZPUmVUQUFRYVNYNVhJWDVE?= =?utf-8?B?ZW8vMEMyVkttU0E2V1VTM0JMWFMwSFgvOHRodDhTbndJdEE1VEMvSCthVTg2?= =?utf-8?B?ckNuK2k3YkRDVHJPQjRyTGs4cDAxMUNNMzJjYXFnTjcrcCs4YXd2S3hta3pk?= =?utf-8?B?SGJPTUF2SnJESnE2Y3h0YWRPMWJRTmJYaDZMN3VTdVg2dlBvcE5pSjNLY0E1?= =?utf-8?B?R2RFMjVPUDhYU2oyMytVdGZlSndnZ1NvN2oyOHNRVkRrMUI4bVVvMUtjWEpU?= =?utf-8?B?S3E0WXgrQWVXVTdEd0wxSXpUNENWSHk5TTV0MFB4azY5ZFBwdytpVXdmQk1j?= =?utf-8?B?SDZSSmdKWWdrYTVpTlB0Skk0Skxic2cvZjFWVnZ2ZCt6OC9RT1Y1SzFPNU9V?= =?utf-8?B?UEF3QUdCd2FjdXpDeHM2WFlCZVA3NXVTcFUrMWpHYnFsTG5qZDZtdTRWeFhv?= =?utf-8?B?MGpmOG5HdG1idXppU3B6YVo0MVQxWU5uajdwWFFWZW8zUW5OWEZxU205RTB5?= =?utf-8?Q?o7/A=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MFN2NXpZbkVLMmZQMUtJWTc1NGQwSWljWHJyUkx2U0dOem03UFlaUXUvcUM1?= =?utf-8?B?VWFnbkdqMk9HYXA4MWVKcVZCejlCUG5weEU0MndTR0VpQy9lSDVDbWlhS1Zk?= =?utf-8?B?NU5yUXlMZWNrWW9KaGx0a00wWEo1VE1ON3NCempMeDJXL2ZJQzlOd0V5UTBP?= =?utf-8?B?elNseFQxdENoczZJMDNTNFAyLzB5WFYzQWZaVG51Z3docnJ0U3JEK0dTa3Rm?= =?utf-8?B?cmZvY0xWbWxuU1Y0Smp4aU9RK3dnODdndlp6Skc2L2JmUzY2bVMxYUh4Z2xq?= =?utf-8?B?VlE3QTN5MElCM1RWbU5tUGJuck5IY1BJc2RkUlNkYXBKR25DYTdMOHBQN2hr?= =?utf-8?B?YU41NlkxREtqRUlOK0xaZjZRVVoyMUJXTWtoNklndUFOcEx3MkFBV0ZSTVV1?= =?utf-8?B?MGhOVDBWUlhkcFpGY2gxT3dGeFRua2dPdEpEZ3lyMndjZS9uVVg2SmVvckVr?= =?utf-8?B?azAvWm5WSk5YWlZua3RLQnUwSS9uelUzWlN4UExOZlJKSUFHVUhIQW5DMllO?= =?utf-8?B?NytzdmhyQmd4SzQ1NkZJSDlZUWR3WVpuSUljQWFZUU9yRE91ZFgxV3A5Ylha?= =?utf-8?B?VE1jNkJ1NThBRXdzcTZMV1VwNFVac2prVS9XTVkxSXBlUVJnOGExUjMydGVW?= =?utf-8?B?eUZ3NEw1MVV4d01aZWtTemdaL2I3ZlBha0UwS243ZDgrS3VvRlArYXdnZlZr?= =?utf-8?B?cWc2bmFUalIxRmlWMEZIN3dHT1libkFod2JnS3VoR3VNczl1aHVsaTZaUnow?= =?utf-8?B?cjNzcmNpU0ExUCtDRFJVUDJoVG9lbmJmL1BwYm1GSS9zejQreDVjdjFXcnFN?= =?utf-8?B?ZVFkc1p4eGtpTXVVdXFVUHZPRmtNd1owNlg5UHFtNTZ0TDlQR1RwTEJsRlNo?= =?utf-8?B?VkVqR0s4TXg4QzZHWGVyVXo4OVVlZE1yRzR6SFRtR2NqdzJZV3FIcktzR3dh?= =?utf-8?B?ZldtcW4vbFFtSjZubEZlVnUyRjF3ZURWWGQ3LzJWS250NzhsYlQ4aVNIQXla?= =?utf-8?B?dmR3QlFwYWhhOCtsSzVQVys2VVlIVWcwMGpid0w2MjJoWnZ0VmFqdnJPdG4v?= =?utf-8?B?V3FoeW5Ja3R1TS9VMkhGZ1h1a25GN3U2TXlZT1pLdko0czdKSG5KV2Q1b2xl?= =?utf-8?B?RTUxa3hTQ01YUFBSdkhLMTBJcm9hVStOZTJZOXp2SG5xa21wdkQzNFdjZGZS?= =?utf-8?B?VUFSNUlMSDF3Y2kyK3pDWDZXT29mczZGUlIxTzIyMDJwdGdOWjJPTGRhTlNS?= =?utf-8?B?cTBzN05neVZKR1gvRXZ0RldyYWRxWkVOcHAzS2JEWHR5Q21BUlRSNnVDN1BQ?= =?utf-8?B?YXlSd09EQ0xsNldiQXNuMG1NR1ZIZll6NmhnMmFEeDlmZS9IaWNEaXBnaE5T?= =?utf-8?B?dkxKT1l5dzdNTU9FWklWUElZVXVueHA3NlYxYTlxM2FLa1ZiWkJUM0hZTERY?= =?utf-8?B?L0p2YzRzZlRoY1V6VE5jRytvbW9RUVdoYXpqNmRQSER5czlQTTNrMEJSbW5m?= =?utf-8?B?R2FUQ2xWQk52Z0JFa2gzazhnY0tWYm5oQ0lTd1ZsZk16aFFMUDV5di9sVG92?= =?utf-8?B?dWorWnJMUmRHWmUydytudFZLWVJ6OFZ6V1BzL0x5Wk9TT2IzaUxqdVVRWGZU?= =?utf-8?B?SnM2T3BYNjE5VXFHQ3MwV0hVaEtMYThHdmsxMXVwWjQ2SzY3akswYzIwcFRU?= =?utf-8?B?MXVya0RaeHNrdXgrVXdXM0RidTlYYkFCRHMyeFpIN0xycVFDdGZPSCtsa054?= =?utf-8?B?RE04QmZMenFjRXNJSWJTcDdNQTBCZWlacXBSWmFsL0hEbFY0Vm1KQzk0L3hS?= =?utf-8?B?aXhiMkZlc0NjSW9TTHUxcWVHNXp0b0dXeGxTNUl2MldWTjZTVHdMK0tvZDc2?= =?utf-8?B?dzVTQ2crVjg5eG15V1M2UnJCOGM0UytJdjBRYXlCWUFIU1hqSFpJZ3lmYjdr?= =?utf-8?B?WWZLcU5yU1NSK1pBM3h2aG92QmJoKzdFYmlUTmFVSzJxVmt1WHVVaU1EcjhD?= =?utf-8?B?YWduNldQbmZ4d3owcXBrNThxVmNUa3pmU1VZaTM4Y0hUL3lNUzlSTnZ6dEdp?= =?utf-8?B?WjdicTJ1ZGdEeURxcW1MZktHODFtTTFLYm9rOTRvNUNXZGZnYWJaUTBGa3pr?= =?utf-8?B?cE12VERmZTU5a3V4UDFjemxKSW9GTW5mQk1EdjR2c0w1eXAyT1ZKU0hxRHJU?= =?utf-8?B?bUJtampvZDhndlVnY3dNcjFBbzd1ZnhSTGhZN3BDZ3MzZDR2NmhrMS9vdHdN?= =?utf-8?B?eHg4Mm5oNDdFRDhRZHllbDEwTVg0VCt6dkVTajRIZnkxZzBTWXVvWUtYYTk3?= =?utf-8?B?Vnc5ZUxRZ0tnMjVzOTlESzg4NFJsVEtPVGY2cTB1aGoxUkZPQkVTZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0ff901c1-df3b-4dec-739c-08de5d98820b X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 11:37:53.2910 (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: 1IzQ3xLKKMZQmJqe4NAxwZSQs0uoO5gl5nTeQ9UpEs2Qgj0dA0TX6KIAbvGVz5Kx3Fk5fd0C/oMCSixj4mf6vzdRjjyr0GDdpSUNSiigplY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB5937 On 27/01/2026 11:23 am, Teddy Astie wrote: > Le 26/01/2026 à 18:56, Andrew Cooper a écrit : >> I was hoping this to be a patch or two, but it got out of hand... >> >> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2287078891 >> https://gitlab.com/xen-project/hardware/xen-staging/-/commits/andrew/nx >> >> The branch has one extra patch to fake up the firmware settings being set to >> Gitlab CI, not included in this series. >> >> Julien: This ought to suitable to rebase your cleanup on to. In the end, I >> did the AMD adjustment mostly because I needed it to test the correctness of >> the prior cleanup. >> >> The final 4 patches are tangential cleanup which I've kept out of the prior >> work in case we wish to backport it. Everything prior is relevant to >> untangling, and mostly for the benefit of the AMD side. >> >> The early patches are hopefully non-controvertial. Later patches are a little >> more RFC, and in need of further testing. >> >> >> > Tested on a Intel machine with "DEP" disabled, and "Require NX support" > disabled, I get a pagefault in hpet code >From above: > Julien: This ought to suitable to rebase your cleanup on to. This is cleanup only.  I've not got the bugfixes for EFI boot yet, so the behaviour you see is still expected for now. Although, thinking about it, it might be better if I try to merge the two series, so everyone can test the end result. Thoughts? >> (XEN) Xen version 4.22-unstable (tsnake41@(none)) (gcc (Alpine 15.2.0) 15.2.0) debug=y Tue Jan 27 12:06:46 CET 2026 >> (XEN) Latest ChangeSet: Mon Jan 26 17:53:45 2026 +0000 git:6491616ddd >> (XEN) build-id: 035024497a4cadebf9e5a2ded61f63ac >> (XEN) re-enabled NX (Execute Disable) protection >> (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3 (raw 000306c3) >> (XEN) BSP microcode revision: 0x0000001a >> (XEN) microcode: Bad data in container >> (XEN) Microcode: Parse error -22 As a tangent, what's going on here? This is the first time I've seen the error outside of my own testing.  Is it a container you expect to be good, or some leftovers on a test machine? ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 27 12:01:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 12:01:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214319.1524758 (Exim 4.92) (envelope-from ) id 1vkhkh-0007ku-ML; Tue, 27 Jan 2026 12:00:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214319.1524758; Tue, 27 Jan 2026 12: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 1vkhkh-0007kD-Df; Tue, 27 Jan 2026 12:00:59 +0000 Received: by outflank-mailman (input) for mailman id 1214319; Tue, 27 Jan 2026 12:00:58 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkhkg-0006UG-EM for xen-devel@lists.xen.org; Tue, 27 Jan 2026 12:00:58 +0000 Received: from mail.xenproject.org (mail.xenproject.org [104.130.215.37]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d24a3a2c-fb77-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 13:00:50 +0100 (CET) Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vkhkT-006B0B-2X; Tue, 27 Jan 2026 12:00:45 +0000 Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.96) (envelope-from ) id 1vkhkT-004FQb-1J; Tue, 27 Jan 2026 12: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" X-Inumbo-ID: d24a3a2c-fb77-11f0-9ccf-f158ae23cfc8 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 478 v2 (CVE-2025-58151) - varstored: TOCTOU issues with mapped guest memory Message-Id: Date: Tue, 27 Jan 2026 12:00:45 +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-58151 / XSA-478 version 2 varstored: TOCTOU issues with mapped guest memory UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= varstored is a component of the Xapi toolstack handling UEFI Variables for a VM. It has a communication path with OVMF inside the VM involving mapping a buffer prepared by OVMF. Within varstored, there were insufficient compiler barriers, creating TOCTOU issues with data in the shared buffer. The exact vulnerable behaviour depends on the code generated by the compiler. In a build of varstored using default settings, the attacker can control an index used in a jump table. IMPACT ====== An attacker with kernel level access in a VM can escalate privilege via gaining code execution within varstored. VULNERABLE SYSTEMS ================== Only systems using the Xapi toolstack are potentially affected. Systems running all versions of varstored are potentially affected. x86 HVM guests which have been configured as UEFI VMs can leverage the vulnerability. x86 PV guests cannot leverage the vulnerability. A Xapi VM is configured for UEFI if the `HVM-boot-params` map contains `firmware=uefi`. e.g.: xe vm-param-list uuid=$UUID ... HVM-boot-params (MRW): firmware: uefi ... If `firmware` is set to `bios`, or is absent entirely (PV guests), then the guest cannot leverage the vulnerability. MITIGATION ========== There are no mitigations. CREDITS ======= This issue was discovered by Teddy Astie of Vates. RESOLUTION ========== Applying the attached patch resolves this issue. xsa478.patch varstored master $ sha256sum xsa478* 401679429e22e202fecf418c5100144ea0ee1cca3643f09960107cf3d88821db xsa478.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/4UyVfoK9kFAml4qMEMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZp94IAKAafDWRsyB3vmmHsGG2cF3I1LFKQMzhtogNUu/w 7QrhNwmyI9tdIhtlPk4JC75L1Em+kDXHh+vNkQF97QeKq2IyuEYt+q2ko6sV/RTF Ewv0BhJJIiJCfyI/x55dz+YANOwsSOo7bZrSy1l/VgUJOdVKK5L1VtcloD57ZX2D A4r/rfZbJwx/vJ+Zp8R+W0on7SWS6h4am6M0+7f2swiJ2MpoEUwhSgFMmigOcdUc xbUo/IKOiQVNX2A6j+J5tQT6JlrXC/K8bIUwe2oDKRPG1qSMYAr2lKZ4GvoflUra ckCA0k520KHw+ZfuHhQq/TzIFaLVDnr1kfChYdPSX0jXtb0= =B9ua -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa478.patch" Content-Disposition: attachment; filename="xsa478.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogW1BBVENIXSBGaXggVE9DVE9VIGlzc3VlcyB3aXRoIG1h cHBlZCBndWVzdCBtZW1vcnkKCm1lbWNweSgpIGNhbiBiZSBvcHRpbWlzZWQg YnkgdGhlIGNvbXBpbGVyLCBsZWFkaW5nIHRvIFRPQ1RPVSBidWdzIHdpdGgg ZGF0YSBpbgpndWVzdCBtZW1vcnkuICBXaXRob3V0IHRoZXNlIGJhcnJpZXJz LCBkaXNwYXRjaF9jb21tYW5kKCkgY29tcGlsZXMgaW4gYSB3YXkKd2hpY2gg aXMgdnVsbmVyYWJsZSB0byBjb2RlIGluamVjdGlvbi4KClRoaXMgaXMgWFNB LTQ3OCAvIENWRS0yMDI1LTU4MTUxCgpSZXBvcnRlZC1ieTogVGVkZHkgQXN0 aWUgPHRlZGR5LmFzdGllQHZhdGVzLnRlY2g+ClNpZ25lZC1vZmYtYnk6IEFu ZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+ClJldmll d2VkLWJ5OiBGcmVkaWFubyBaaWdsaW8gPGZyZWRpYW5vLnppZ2xpb0BjaXRy aXguY29tPgpSZXZpZXdlZC1ieTogUm9zcyBMYWdlcndhbGwgPHJvc3MubGFn ZXJ3YWxsQGNpdHJpeC5jb20+ClJldmlld2VkLWJ5OiBSb2dlciBQYXUgTW9u bsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KLS0tCiBpbmNsdWRlL3Nlcmlh bGl6ZS5oIHwgMTggKysrKysrKysrKysrKysrKysrCiAxIGZpbGUgY2hhbmdl ZCwgMTggaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL2luY2x1ZGUvc2Vy aWFsaXplLmggYi9pbmNsdWRlL3NlcmlhbGl6ZS5oCmluZGV4IDA0NDQxZWE4 YTM3Mi4uMTY2Nzg2OGZlYWI0IDEwMDY0NAotLS0gYS9pbmNsdWRlL3Nlcmlh bGl6ZS5oCisrKyBiL2luY2x1ZGUvc2VyaWFsaXplLmgKQEAgLTM1LDEyICsz NSwxNSBAQAogI2luY2x1ZGUgImVmaS5oIgogI2luY2x1ZGUgImhhbmRsZXIu aCIKIAorI2RlZmluZSBiYXJyaWVyKCkgYXNtIHZvbGF0aWxlICgiIiA6Ojog Im1lbW9yeSIpCisKIHN0YXRpYyBpbmxpbmUgZW51bSBjb21tYW5kX3QKIHVu c2VyaWFsaXplX2NvbW1hbmQodWludDhfdCAqKnB0cikKIHsKICAgICBVSU5U MzIgZGF0YTsKIAogICAgIG1lbWNweSgmZGF0YSwgKnB0ciwgc2l6ZW9mKGRh dGEpKTsKKyAgICBiYXJyaWVyKCk7CiAgICAgKnB0ciArPSBzaXplb2YgZGF0 YTsKIAogICAgIHJldHVybiAoZW51bSBjb21tYW5kX3QpZGF0YTsKQEAgLTUw LDkgKzUzLDExIEBAIHN0YXRpYyBpbmxpbmUgdm9pZAogc2VyaWFsaXplX2Rh dGEodWludDhfdCAqKnB0ciwgY29uc3QgdWludDhfdCAqZGF0YSwgVUlOVE4g ZGF0YV9sZW4pCiB7CiAgICAgbWVtY3B5KCpwdHIsICZkYXRhX2xlbiwgc2l6 ZW9mKGRhdGFfbGVuKSk7CisgICAgYmFycmllcigpOwogICAgICpwdHIgKz0g c2l6ZW9mIGRhdGFfbGVuOwogICAgIGlmIChkYXRhX2xlbikgewogICAgICAg ICBtZW1jcHkoKnB0ciwgZGF0YSwgZGF0YV9sZW4pOworICAgICAgICBiYXJy aWVyKCk7CiAgICAgICAgICpwdHIgKz0gZGF0YV9sZW47CiAgICAgfQogfQpA QCAtNjEsNiArNjYsNyBAQCBzdGF0aWMgaW5saW5lIHZvaWQKIHNlcmlhbGl6 ZV9yZXN1bHQodWludDhfdCAqKnB0ciwgRUZJX1NUQVRVUyBzdGF0dXMpCiB7 CiAgICAgbWVtY3B5KCpwdHIsICZzdGF0dXMsIHNpemVvZihzdGF0dXMpKTsK KyAgICBiYXJyaWVyKCk7CiAgICAgKnB0ciArPSBzaXplb2Ygc3RhdHVzOwog fQogCkBAIC02OCw2ICs3NCw3IEBAIHN0YXRpYyBpbmxpbmUgdm9pZAogc2Vy aWFsaXplX2d1aWQodWludDhfdCAqKnB0ciwgY29uc3QgRUZJX0dVSUQgKmd1 aWQpCiB7CiAgICAgbWVtY3B5KCpwdHIsIGd1aWQsIEdVSURfTEVOKTsKKyAg ICBiYXJyaWVyKCk7CiAgICAgKnB0ciArPSBHVUlEX0xFTjsKIH0KIApAQCAt NzUsNiArODIsNyBAQCBzdGF0aWMgaW5saW5lIHZvaWQKIHNlcmlhbGl6ZV90 aW1lc3RhbXAodWludDhfdCAqKnB0ciwgRUZJX1RJTUUgKnRpbWVzdGFtcCkK IHsKICAgICBtZW1jcHkoKnB0ciwgdGltZXN0YW1wLCBzaXplb2YoKnRpbWVz dGFtcCkpOworICAgIGJhcnJpZXIoKTsKICAgICAqcHRyICs9IHNpemVvZigq dGltZXN0YW1wKTsKIH0KIApAQCAtODIsNiArOTAsNyBAQCBzdGF0aWMgaW5s aW5lIHZvaWQKIHNlcmlhbGl6ZV91aW50bih1aW50OF90ICoqcHRyLCBVSU5U TiB2YXIpCiB7CiAgICAgbWVtY3B5KCpwdHIsICZ2YXIsIHNpemVvZih2YXIp KTsKKyAgICBiYXJyaWVyKCk7CiAgICAgKnB0ciArPSBzaXplb2YgdmFyOwog fQogCkBAIC04OSw2ICs5OCw3IEBAIHN0YXRpYyBpbmxpbmUgdm9pZAogc2Vy aWFsaXplX3VpbnQzMih1aW50OF90ICoqcHRyLCBVSU5UMzIgdmFyKQogewog ICAgIG1lbWNweSgqcHRyLCAmdmFyLCBzaXplb2YodmFyKSk7CisgICAgYmFy cmllcigpOwogICAgICpwdHIgKz0gc2l6ZW9mIHZhcjsKIH0KIApAQCAtOTYs NiArMTA2LDcgQEAgc3RhdGljIGlubGluZSB2b2lkCiBzZXJpYWxpemVfdWlu dDY0KHVpbnQ4X3QgKipwdHIsIFVJTlQ2NCB2YXIpCiB7CiAgICAgbWVtY3B5 KCpwdHIsICZ2YXIsIHNpemVvZih2YXIpKTsKKyAgICBiYXJyaWVyKCk7CiAg ICAgKnB0ciArPSBzaXplb2YgdmFyOwogfQogCkBAIC0xMDUsNiArMTE2LDcg QEAgdW5zZXJpYWxpemVfZGF0YSh1aW50OF90ICoqcHRyLCBVSU5UTiAqbGVu LCBVSU5UTiBsaW1pdCkKICAgICB1aW50OF90ICpkYXRhOwogCiAgICAgbWVt Y3B5KGxlbiwgKnB0ciwgc2l6ZW9mKCpsZW4pKTsKKyAgICBiYXJyaWVyKCk7 CiAgICAgKnB0ciArPSBzaXplb2YgKmxlbjsKIAogICAgIGlmICgqbGVuID4g bGltaXQgfHwgKmxlbiA9PSAwKQpAQCAtMTE1LDYgKzEyNyw3IEBAIHVuc2Vy aWFsaXplX2RhdGEodWludDhfdCAqKnB0ciwgVUlOVE4gKmxlbiwgVUlOVE4g bGltaXQpCiAgICAgICAgIHJldHVybiBOVUxMOwogCiAgICAgbWVtY3B5KGRh dGEsICpwdHIsICpsZW4pOworICAgIGJhcnJpZXIoKTsKICAgICAqcHRyICs9 ICpsZW47CiAKICAgICByZXR1cm4gZGF0YTsKQEAgLTEyNCw2ICsxMzcsNyBA QCBzdGF0aWMgaW5saW5lIHZvaWQKIHVuc2VyaWFsaXplX2RhdGFfaW5wbGFj ZSh1aW50OF90ICoqcHRyLCB1aW50OF90ICpidWYsIFVJTlROIGxlbikKIHsK ICAgICBtZW1jcHkoYnVmLCAqcHRyLCBsZW4pOworICAgIGJhcnJpZXIoKTsK ICAgICAqcHRyICs9IGxlbjsKIH0KIApAQCAtMTM3LDYgKzE1MSw3IEBAIHN0 YXRpYyBpbmxpbmUgdm9pZAogdW5zZXJpYWxpemVfdGltZXN0YW1wKHVpbnQ4 X3QgKipwdHIsIEVGSV9USU1FICp0aW1lc3RhbXApCiB7CiAgICAgbWVtY3B5 KHRpbWVzdGFtcCwgKnB0ciwgc2l6ZW9mKCp0aW1lc3RhbXApKTsKKyAgICBi YXJyaWVyKCk7CiAgICAgKnB0ciArPSBzaXplb2YoKnRpbWVzdGFtcCk7CiB9 CiAKQEAgLTE0Niw2ICsxNjEsNyBAQCB1bnNlcmlhbGl6ZV91aW50bih1aW50 OF90ICoqcHRyKQogICAgIFVJTlROIHJldDsKIAogICAgIG1lbWNweSgmcmV0 LCAqcHRyLCBzaXplb2YocmV0KSk7CisgICAgYmFycmllcigpOwogICAgICpw dHIgKz0gc2l6ZW9mIHJldDsKIAogICAgIHJldHVybiByZXQ7CkBAIC0xNTcs NiArMTczLDcgQEAgdW5zZXJpYWxpemVfYm9vbGVhbih1aW50OF90ICoqcHRy KQogICAgIEJPT0xFQU4gcmV0OwogCiAgICAgbWVtY3B5KCZyZXQsICpwdHIs IHNpemVvZihyZXQpKTsKKyAgICBiYXJyaWVyKCk7CiAgICAgKnB0ciArPSBz aXplb2YgcmV0OwogCiAgICAgcmV0dXJuIHJldDsKQEAgLTE2OCw2ICsxODUs NyBAQCB1bnNlcmlhbGl6ZV91aW50MzIodWludDhfdCAqKnB0cikKICAgICBV SU5UMzIgcmV0OwogCiAgICAgbWVtY3B5KCZyZXQsICpwdHIsIHNpemVvZihy ZXQpKTsKKyAgICBiYXJyaWVyKCk7CiAgICAgKnB0ciArPSBzaXplb2YgcmV0 OwogCiAgICAgcmV0dXJuIHJldDsKLS0gCjIuMzkuNQoK --=separator-- From xen-devel-bounces@lists.xenproject.org Tue Jan 27 12:01:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 12:01:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214320.1524774 (Exim 4.92) (envelope-from ) id 1vkhki-0008Gg-VI; Tue, 27 Jan 2026 12:01:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214320.1524774; Tue, 27 Jan 2026 12:01:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkhki-0008FY-Qb; Tue, 27 Jan 2026 12:01:00 +0000 Received: by outflank-mailman (input) for mailman id 1214320; Tue, 27 Jan 2026 12:00:59 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkhkh-0006UG-ES for xen-devel@lists.xen.org; Tue, 27 Jan 2026 12:00:59 +0000 Received: from mail.xenproject.org (mail.xenproject.org [104.130.215.37]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d39415e7-fb77-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 13:00:52 +0100 (CET) Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vkhkW-006B0V-31; Tue, 27 Jan 2026 12:00:48 +0000 Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.96) (envelope-from ) id 1vkhkW-004FRp-1q; Tue, 27 Jan 2026 12:00: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: d39415e7-fb77-11f0-9ccf-f158ae23cfc8 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 479 v2 (CVE-2026-23553) - x86: incomplete IBPB for vCPU isolation Message-Id: Date: Tue, 27 Jan 2026 12:00:48 +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-2026-23553 / XSA-479 version 2 x86: incomplete IBPB for vCPU isolation UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= In the context switch logic Xen attempts to skip an IBPB in the case of a vCPU returning to a CPU on which it was the previous vCPU to run. While safe for Xen's isolation between vCPUs, this prevents the guest kernel correctly isolating between tasks. Consider: 1) vCPU runs on CPU A, running task 1. 2) vCPU moves to CPU B, idle gets scheduled on A. Xen skips IBPB. 3) On CPU B, guest kernel switches from task 1 to 2, issuing IBPB. 4) vCPU moves back to CPU A. Xen skips IBPB again. Now, task 2 is running on CPU A with task 1's training still in the BTB. IMPACT ====== Guest processes may leverage information leaks to obtain information intended to be private to other entities in a guest. VULNERABLE SYSTEMS ================== Xen versions which had the XSA-254 fixes backported are vulnerable. Upstream, that is 4.6 and newer. Only x86 systems are vulnerable. Arm systems are not vulerable. Systems vulnerable to SRSO (see XSA-434) with default settings use IBPB-on-entry to protect against SRSO. This is a rather more aggressive form of flushing than only on context switch, and is believed to be sufficient to avoid the vulnerability. MITIGATION ========== Using "spec-ctrl=ibpb-entry=hvm,ibpb-entry=pv" on the Xen command line will activate the SRSO mitigation on non-SRSO-vulnerable hardware, but it is a large overhead. CREDITS ======= This issue was discovered by David Kaplan of AMD. RESOLUTION ========== Applying the attached patch 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. xsa479.patch xen-unstable - Xen 4.18.x $ sha256sum xsa479* 82369898d0287e69272d0d65fb0e6be5fd0106bda19cedb3c9f6e75688f6fb4b xsa479.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/4UyVfoK9kFAml4qMMMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ4TgIAIObkH7IN/btMzEbjNp2aknZ+u2hgP2zu1j00Fwa dyEi7Bug9X73vmgzLUWjHDCmvF3uoPl01KIjfh12v7s8dERKaTTxD1fGPOKliziA rdZQJSICVTnrNex15aLONHxkJI3oVwo2JAXChBx1a4Zx9k7M6+Kv7o9xYlnQh27N he3fmMrxWMCtTjngDgz7YhRonIYvA92wpRVCNklUulx9+oLHXllS8IKyf1rZvNr2 k2suwC82YG/wG6/vVUxZp45BTt45UC6YtengVRcyq70o9h8y6deSof0MoSuAewj7 05Z9kXac7pvGJTMTz2dUnHeRelaVU2Ps736vQSGgyJdIJ/c= =jCcD -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa479.patch" Content-Disposition: attachment; filename="xsa479.patch" Content-Transfer-Encoding: base64 RnJvbTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+ ClN1YmplY3Q6IHg4Ni9zcGVjLWN0cmw6IEZpeCBpbmNvbXBsZXRlIElCUEIg Zmx1c2hpbmcgZHVyaW5nIGNvbnRleHQgc3dpdGNoCgpUaGUgcHJldmlvdXMg bG9naWMgYXR0ZW1wdGVkIHRvIHNraXAgYW4gSUJQQiBpbiB0aGUgY2FzZSBv ZiB2Q1BVIHJldHVybmluZyB0bwphIENQVSBvbiB3aGljaCBpdCB3YXMgdGhl IHByZXZpb3VzIHZDUFUgdG8gcnVuLiAgV2hpbGUgc2FmZSBmb3IgWGVuJ3MK aXNvbGF0aW9uIGJldHdlZW4gdkNQVXMsIHRoaXMgcHJldmVudHMgdGhlIGd1 ZXN0IGtlcm5lbCBjb3JyZWN0bHkgaXNvbGF0aW9uCmJldHdlZW4gdGFza3Mu ICBDb25zaWRlcjoKCiAxKSB2Q1BVIHJ1bnMgb24gQ1BVIEEsIHJ1bm5pbmcg dGFzayAxLgogMikgdkNQVSBtb3ZlcyB0byBDUFUgQiwgaWRsZSBnZXRzIHNj aGVkdWxlZCBvbiBBLiAgWGVuIHNraXBzIElCUEIuCiAzKSBPbiBDUFUgQiwg Z3Vlc3Qga2VybmVsIHN3aXRjaGVzIGZyb20gdGFzayAxIHRvIDIsIGlzc3Vp bmcgSUJQQi4KIDQpIHZDUFUgbW92ZXMgYmFjayB0byBDUFUgQS4gIFhlbiBz a2lwcyBJQlBCIGFnYWluLgoKTm93LCB0YXNrIDIgaXMgcnVubmluZyBvbiBD UFUgQSB3aXRoIHRhc2sgMSdzIHRyYWluaW5nIHN0aWxsIGluIHRoZSBCVEIu CgpEbyB0aGUgZmx1c2ggdW5jb25kaXRpb25hbGx5IHdoZW4gc3dpdGNoaW5n IHRvIGEgdkNQVSBkaWZmZXJlbnQgdGhhbiB0aGUKaWRsZSBvbmUuICBOb3Rl IHRoZXJlJ3Mgbm8gbmVlZCB0byBleHBsaWNpdGx5IGdhdGUgdGhlIElCUEIg dG8gbmV4dCBkb21haW4KIT0gaWRsZSwgYXMgdGhlIGNvbnRleHQgd2hlcmUg dGhlIElCUEIgaXMgaXNzdWVkIGlzIHN1YmplY3QgdG8gdGhhdApjb25kaXRp b24gYWxyZWFkeSB1bmxlc3MgdGhlIHBDUFUgaXMgZ29pbmcgb2ZmbGluZSwg YXQgd2hpY2ggcG9pbnQgd2UgZG9uJ3QKcmVhbGx5IGNhcmUgdG8gaXNzdWUg YW4gZXh0cmEgSUJQQi4KCkFsc28gYWRkIGEgY29tbWVudCB3aXRoIHRoZSBy ZWFzb25pbmcgd2h5IHRoZSBJQlBCIG5lZWRzIHRvIGJlIGluCmNvbnRleHRf c3dpdGNoKCkgcmF0aGVyIHRoYW4gX19jb250ZXh0X3N3aXRjaCgpLgoKVGhp cyBpcyBYU0EtNDc5IC8gQ1ZFLTIwMjYtMjM1NTMuCgpGaXhlczogYTJlZDY0 M2VkNzgzICgieDg2L2N0eHQ6IElzc3VlIGEgc3BlY3VsYXRpb24gYmFycmll ciBiZXR3ZWVuIHZjcHUgY29udGV4dHMiKQpSZXBvcnRlZC1ieTogRGF2aWQg S2FwbGFuIDxkYXZpZC5rYXBsYW5AYW1kLmNvbT4KU2lnbmVkLW9mZi1ieTog Um9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+ClJldmll d2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+Ci0tLQog eGVuL2FyY2gveDg2L2RvbWFpbi5jIHwgMzYgKysrKysrKysrLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgOSBpbnNlcnRp b25zKCspLCAyNyBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS94ZW4vYXJj aC94ODYvZG9tYWluLmMgYi94ZW4vYXJjaC94ODYvZG9tYWluLmMKaW5kZXgg YzI5YTZiMGRlY2VlLi5jMWVkZWQzZWI2MDQgMTAwNjQ0Ci0tLSBhL3hlbi9h cmNoL3g4Ni9kb21haW4uYworKysgYi94ZW4vYXJjaC94ODYvZG9tYWluLmMK QEAgLTIxNzQsMzMgKzIxNzQsMTUgQEAgdm9pZCBjb250ZXh0X3N3aXRjaChz dHJ1Y3QgdmNwdSAqcHJldiwgc3RydWN0IHZjcHUgKm5leHQpCiAKICAgICAg ICAgY3R4dF9zd2l0Y2hfbGV2ZWxsaW5nKG5leHQpOwogCi0gICAgICAgIGlm ICggb3B0X2licGJfY3R4dF9zd2l0Y2ggJiYgIWlzX2lkbGVfZG9tYWluKG5l eHRkKSApCi0gICAgICAgIHsKLSAgICAgICAgICAgIHN0YXRpYyBERUZJTkVf UEVSX0NQVSh1bnNpZ25lZCBpbnQsIGxhc3QpOwotICAgICAgICAgICAgdW5z aWduZWQgaW50ICpsYXN0X2lkID0gJnRoaXNfY3B1KGxhc3QpOwotCi0gICAg ICAgICAgICAvKgotICAgICAgICAgICAgICogU3F1YXNoIHRoZSBkb21pZCBh bmQgdmNwdSBpZCB0b2dldGhlciBmb3IgY29tcGFyaXNvbgotICAgICAgICAg ICAgICogZWZmaWNpZW5jeS4gIFdlIGNvdWxkIGluIHByaW5jaXBsZSBzdGFz aCBhbmQgY29tcGFyZSB0aGUgc3RydWN0Ci0gICAgICAgICAgICAgKiB2Y3B1 IHBvaW50ZXIsIGJ1dCB0aGlzIHJpc2tzIGEgZmFsc2UgYWxpYXMgaWYgYSBk b21haW4gaGFzIGRpZWQKLSAgICAgICAgICAgICAqIGFuZCB0aGUgc2FtZSA0 ayBwYWdlIGdldHMgcmV1c2VkIGZvciBhIG5ldyB2Y3B1LgotICAgICAgICAg ICAgICovCi0gICAgICAgICAgICB1bnNpZ25lZCBpbnQgbmV4dF9pZCA9ICgo KHVuc2lnbmVkIGludCluZXh0ZC0+ZG9tYWluX2lkIDw8IDE2KSB8Ci0gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAodWludDE2X3QpbmV4 dC0+dmNwdV9pZCk7Ci0gICAgICAgICAgICBCVUlMRF9CVUdfT04oTUFYX1ZJ UlRfQ1BVUyA+IDB4ZmZmZik7Ci0KLSAgICAgICAgICAgIC8qCi0gICAgICAg ICAgICAgKiBXaGVuIHNjaGVkdWxpbmcgZnJvbSBhIHZjcHUsIHRvIGlkbGUs IGFuZCBiYWNrIHRvIHRoZSBzYW1lIHZjcHUKLSAgICAgICAgICAgICAqICh3 aGljaCBtaWdodCBiZSBjb21tb24gaW4gYSBsaWdodGx5IGxvYWRlZCBzeXN0 ZW0sIG9yIHdoZW4KLSAgICAgICAgICAgICAqIHVzaW5nIHZjcHUgcGlubmlu ZyksIHRoZXJlIGlzIG5vIG5lZWQgdG8gaXNzdWUgSUJQQiwgYXMgd2UgYXJl Ci0gICAgICAgICAgICAgKiByZXR1cm5pbmcgdG8gdGhlIHNhbWUgc2VjdXJp dHkgY29udGV4dC4KLSAgICAgICAgICAgICAqLwotICAgICAgICAgICAgaWYg KCAqbGFzdF9pZCAhPSBuZXh0X2lkICkKLSAgICAgICAgICAgIHsKLSAgICAg ICAgICAgICAgICBzcGVjX2N0cmxfbmV3X2d1ZXN0X2NvbnRleHQoKTsKLSAg ICAgICAgICAgICAgICAqbGFzdF9pZCA9IG5leHRfaWQ7Ci0gICAgICAgICAg ICB9Ci0gICAgICAgIH0KKyAgICAgICAgLyoKKyAgICAgICAgICogSXNzdWUg YW4gSUJQQiB3aGVuIHNjaGVkdWxpbmcgYSBkaWZmZXJlbnQgdkNQVSBpZiBy ZXF1aXJlZC4KKyAgICAgICAgICoKKyAgICAgICAgICogSUJQQiBjbGVhcnMg dGhlIFJTQi9SQVMvUkFQLCBidXQgdGhhdCdzIGZpbmUgYXMgd2UgbGVhdmUg dGhpcworICAgICAgICAgKiBmdW5jdGlvbiB2aWEgcmVzZXRfc3RhY2tfYW5k X2NhbGxfaW5kKCkgcmF0aGVyIHRoYW4gdmlhIGEgUkVUCisgICAgICAgICAq IGluc3RydWN0aW9uLgorICAgICAgICAgKi8KKyAgICAgICAgaWYgKCBvcHRf aWJwYl9jdHh0X3N3aXRjaCApCisgICAgICAgICAgICBzcGVjX2N0cmxfbmV3 X2d1ZXN0X2NvbnRleHQoKTsKIAogICAgICAgICAvKiBVcGRhdGUgdGhlIHRv cC1vZi1zdGFjayBibG9jayB3aXRoIHRoZSBuZXcgc3BlY3VsYXRpb24gc2V0 dGluZ3MuICovCiAgICAgICAgIGluZm8tPnNjZiA9Cg== --=separator-- From xen-devel-bounces@lists.xenproject.org Tue Jan 27 12:01:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 12:01:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214316.1524728 (Exim 4.92) (envelope-from ) id 1vkhkf-0007CD-Hr; Tue, 27 Jan 2026 12:00:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214316.1524728; Tue, 27 Jan 2026 12: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 1vkhkf-0007C5-Dw; Tue, 27 Jan 2026 12:00:57 +0000 Received: by outflank-mailman (input) for mailman id 1214316; Tue, 27 Jan 2026 12:00: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 1vkhkd-0006UG-Dp for xen-devel@lists.xen.org; Tue, 27 Jan 2026 12:00:55 +0000 Received: from mail.xenproject.org (mail.xenproject.org [104.130.215.37]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d038a54a-fb77-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 13:00:49 +0100 (CET) Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vkhkP-006Azr-0a; Tue, 27 Jan 2026 12:00:40 +0000 Received: from andrewcoop by xenbits.xenproject.org with local (Exim 4.96) (envelope-from ) id 1vkhkO-004FP2-2a; Tue, 27 Jan 2026 12:00: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: d038a54a-fb77-11f0-9ccf-f158ae23cfc8 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 477 v2 (CVE-2025-58150) - x86: buffer overrun with shadow paging + tracing Message-Id: Date: Tue, 27 Jan 2026 12:00:40 +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-58150 / XSA-477 version 2 x86: buffer overrun with shadow paging + tracing UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= Shadow mode tracing code uses a set of per-CPU variables to avoid cumbersome parameter passing. Some of these variables are written to with guest controlled data, of guest controllable size. That size can be larger than the variable, and bounding of the writes was missing. IMPACT ====== The exact effects depend on what's adjacent to the variables in question. The most likely effects are bogus trace data, but none of privilege escalation, information leaks, or Denial of Service (DoS) can be excluded without detailed analysis of the particular build of Xen. VULNERABLE SYSTEMS ================== Only x86 systems are vulnerable. Arm systems are not vulnerable. Only HVM guests running in shadow paging mode and with tracing enabled can leverage the vulnerability. MITIGATION ========== Running HVM guests in HAP mode only will avoid the vulnerability. Not enabling tracing will also avoid the vulnerability. Tracing is enabled by the "tbuf_size=" command line option, or by running tools like xentrace or xenbaked in Dom0. Note that on a running system stopping xentrace / xenbaked would disable tracing. For xentrace, however, this additionally requires that it wasn't started with the -x option. Stopping previously enabled tracing can of course only prevent future damage; prior damage may have occurred and may manifest only later. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. RESOLUTION ========== Applying the appropriate attached patch 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. xsa477.patch xen-unstable - Xen 4.19.x xsa477-4.18.patch Xen 4.18.x $ sha256sum xsa477* 025783441d7db846e717a1e48547b0db7a36fcc6af652b688524c684f0c3d2a7 xsa477.patch 194da830e15195873456b145a8df83af43aaae7a82fa6cb6852928d75c68909c xsa477-4.18.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/4UyVfoK9kFAml4qLYMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ+IkH/jgVtAAifglnIrxstdAUXMritwnXvcrIJaKjG7yj 8980GavdbttObFRL+d2XvPXAQLRWCbgMNgNFA9s/6EhH2cCMF9mmeYxxU9zqG9qi MQyfp1v/UpNrvD4hdHIXhohMELF6IdXQkrRvnB0hJwSPsDEzMZyofTOKppmSqSE1 tIdFXD1R845KTl9eG1lX4uwr2KhAjAgk4DrpIvxmtkiz3yF8kznjAGDSA7luKkTU XBSlBe9u/9Yg5cspQrh7tVQ0K+6wDR6f4bCq26P/VCDUjwRIzHDhdP+RzKaumLGn nTU0aAuIBlXYCa+8HB5c9vf/yLldKflYZ4Qmb3jGD4GYZrQ= =nlvD -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa477.patch" Content-Disposition: attachment; filename="xsa477.patch" Content-Transfer-Encoding: base64 RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0 OiB4ODYvc2hhZG93OiBkb24ndCBvdmVycnVuIHRyYWNlX2VtdWxfd3JpdGVf dmFsCgpHdWVzdHMgY2FuIGRvIHdpZGVyLXRoYW4tUFRFLXNpemUgd3JpdGVz IG9uIHBhZ2UgdGFibGVzLiBUaGUgdHJhY2luZwpoZWxwZXIgdmFyaWFibGUs IGhvd2V2ZXIsIG9ubHkgb2ZmZXJzIHNwYWNlIGZvciBhIHNpbmdsZSBQVEUg KGFuZCBpdCBpcwpiZWluZyBzd2l0Y2hlZCB0byB0aGUgbW9yZSBjb3JyZWN0 IHR5cGUgcmlnaHQgaGVyZSkuIFRoZXJlZm9yZSBib3VuZAppbmNvbWluZyB3 cml0ZSBzaXplcyB0byB0aGUgYW1vdW50IG9mIHNwYWNlIGF2YWlsYWJsZS4K ClRvIG5vdCBsZWF2ZSBkZWFkIGNvZGUgKHdoaWNoIGlzIGEgTWlzcmEgY29u Y2VybiksIGRyb3AgdGhlIG5vdyB1bnVzZWQKZ3Vlc3RfcGFfdCBhcyB3ZWxs LgoKQWxzbyBtb3ZlIGFuZCBhZGp1c3QgR1VFU1RfUFRFX1NJWkU6IERlcml2 ZSBpdCByYXRoZXIgdGhhbiB1c2luZyBoYXJkLQpjb2RlZCBudW1iZXJzLCBh bmQgcHV0IGl0IGluIHRoZSBzb2xlIHNvdXJjZSBmaWxlIHdoZXJlIGl0J3Mg YWN0dWFsbHkKbmVlZGVkLiBUaGlzIHRoZW4gYWxzbyBhZGRyZXNzZXMgYSBN aXNyYSBydWxlIDIwLjkgKCJBbGwgaWRlbnRpZmllcnMKdXNlZCBpbiB0aGUg Y29udHJvbGxpbmcgZXhwcmVzc2lvbiBvZiAjaWYgb3IgI2VsaWYgcHJlcHJv Y2Vzc2luZwpkaXJlY3RpdmVzIHNoYWxsIGJlICNkZWZpbmUnZCBiZWZvcmUg ZXZhbHVhdGlvbiIpIHZpb2xhdGlvbjoKR1VFU1RfUEFHSU5HX0xFVkVMUyBp cyAjZGVmaW5lJ2Qgb25seSBpbiBtdWx0aS5jLgoKVGhpcyBpcyBYU0EtNDc3 IC8gQ1ZFLTIwMjUtNTgxNTAuCgpGaXhlczogOWE4NmFjMWFhM2QyICgieGVu dHJhY2UgNS83OiBBZGRpdGlvbmFsIHRyYWNpbmcgZm9yIHRoZSBzaGFkb3cg Y29kZSIpClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBz dXNlLmNvbT4KUmV2aWV3ZWQtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5j b29wZXIzQGNpdHJpeC5jb20+CgotLS0gYS94ZW4vYXJjaC94ODYvbW0vc2hh ZG93L211bHRpLmMKKysrIGIveGVuL2FyY2gveDg2L21tL3NoYWRvdy9tdWx0 aS5jCkBAIC0xOTcwLDE1ICsxOTcwLDE1IEBAIHN0YXRpYyB2b2lkIHNoX3By ZWZldGNoKHN0cnVjdCB2Y3B1ICp2LAogCiAjaWYgR1VFU1RfUEFHSU5HX0xF VkVMUyA9PSA0CiB0eXBlZGVmIHU2NCBndWVzdF92YV90OwotdHlwZWRlZiB1 NjQgZ3Vlc3RfcGFfdDsKICNlbGlmIEdVRVNUX1BBR0lOR19MRVZFTFMgPT0g MwogdHlwZWRlZiB1MzIgZ3Vlc3RfdmFfdDsKLXR5cGVkZWYgdTY0IGd1ZXN0 X3BhX3Q7CiAjZWxzZQogdHlwZWRlZiB1MzIgZ3Vlc3RfdmFfdDsKLXR5cGVk ZWYgdTMyIGd1ZXN0X3BhX3Q7CiAjZW5kaWYKIAorLyogU2l6ZSAoaW4gYnl0 ZXMpIG9mIGEgZ3Vlc3QgUFRFICovCisjZGVmaW5lIEdVRVNUX1BURV9TSVpF IHNpemVvZihndWVzdF9sMWVfdCkKKwogLyogU2hhZG93IHRyYWNlIGV2ZW50 IHdpdGggR1VFU1RfUEFHSU5HX0xFVkVMUyBmb2xkZWQgaW50byB0aGUgZXZl bnQgZmllbGQuICovCiBzdGF0aWMgdm9pZCBzaF90cmFjZSh1aW50MzJfdCBl dmVudCwgdW5zaWduZWQgaW50IGV4dHJhLCBjb25zdCB2b2lkICpleHRyYV9k YXRhKQogewpAQCAtMjA0OCwxMSArMjA0OCwxNCBAQCBzdGF0aWMgdm9pZCBf X21heWJlX3VudXNlZCBzaF90cmFjZV9nZm5fCiBzdGF0aWMgREVGSU5FX1BF Ul9DUFUoZ3Vlc3RfdmFfdCx0cmFjZV9lbXVsYXRlX2luaXRpYWxfdmEpOwog c3RhdGljIERFRklORV9QRVJfQ1BVKGludCx0cmFjZV9leHRyYV9lbXVsYXRp b25fY291bnQpOwogI2VuZGlmCi1zdGF0aWMgREVGSU5FX1BFUl9DUFUoZ3Vl c3RfcGFfdCx0cmFjZV9lbXVsYXRlX3dyaXRlX3ZhbCk7CitzdGF0aWMgREVG SU5FX1BFUl9DUFUoZ3Vlc3RfbDFlX3QsIHRyYWNlX2VtdWxhdGVfd3JpdGVf dmFsKTsKIAogc3RhdGljIHZvaWQgY2ZfY2hlY2sgdHJhY2VfZW11bGF0ZV93 cml0ZV92YWwoCiAgICAgY29uc3Qgdm9pZCAqcHRyLCB1bnNpZ25lZCBsb25n IHZhZGRyLCBjb25zdCB2b2lkICpzcmMsIHVuc2lnbmVkIGludCBieXRlcykK IHsKKyAgICBpZiAoIGJ5dGVzID4gc2l6ZW9mKHRoaXNfY3B1KHRyYWNlX2Vt dWxhdGVfd3JpdGVfdmFsKSkgKQorICAgICAgICBieXRlcyA9IHNpemVvZih0 aGlzX2NwdSh0cmFjZV9lbXVsYXRlX3dyaXRlX3ZhbCkpOworCiAjaWYgR1VF U1RfUEFHSU5HX0xFVkVMUyA9PSAzCiAgICAgaWYgKCB2YWRkciA9PSB0aGlz X2NwdSh0cmFjZV9lbXVsYXRlX2luaXRpYWxfdmEpICkKICAgICAgICAgbWVt Y3B5KCZ0aGlzX2NwdSh0cmFjZV9lbXVsYXRlX3dyaXRlX3ZhbCksIHNyYywg Ynl0ZXMpOwpAQCAtMjA3NywxMyArMjA4MCwxNiBAQCBzdGF0aWMgaW5saW5l IHZvaWQgc2hfdHJhY2VfZW11bGF0ZShndWVzCiAgICAgICAgICAgICAvKgog ICAgICAgICAgICAgICogRm9yIEdVRVNUX1BBR0lOR19MRVZFTFM9MyAoUEFF IHBhZ2luZyksIGd1ZXN0X2wxZSBpcyA2NCB3aGlsZQogICAgICAgICAgICAg ICogZ3Vlc3RfdmEgaXMgMzIuICBQdXQgaXQgZmlyc3QgdG8gYXZvaWQgcGFk ZGluZy4KKyAgICAgICAgICAgICAqCisgICAgICAgICAgICAgKiBOb3RlOiAu d3JpdGVfdmFsIGlzIGFuIGFyYml0cmFyeSBzZXQgb2Ygd3JpdHRlbiBieXRl cywgcG9zc2libHkKKyAgICAgICAgICAgICAqIG1pc2FsaWduZWQgYW5kIHBv c3NpYmx5IHNwYW5uaW5nIHRoZSBuZXh0IGdsMWUuCiAgICAgICAgICAgICAg Ki8KICAgICAgICAgICAgIGd1ZXN0X2wxZV90IGdsMWUsIHdyaXRlX3ZhbDsK ICAgICAgICAgICAgIGd1ZXN0X3ZhX3QgdmE7CiAgICAgICAgICAgICB1aW50 MzJfdCBmbGFnczoyOSwgZW11bGF0aW9uX2NvdW50OjM7CiAgICAgICAgIH0g ZCA9IHsKICAgICAgICAgICAgIC5nbDFlICAgICAgICAgICAgPSBnbDFlLAot ICAgICAgICAgICAgLndyaXRlX3ZhbC5sMSAgICA9IHRoaXNfY3B1KHRyYWNl X2VtdWxhdGVfd3JpdGVfdmFsKSwKKyAgICAgICAgICAgIC53cml0ZV92YWwg ICAgICAgPSB0aGlzX2NwdSh0cmFjZV9lbXVsYXRlX3dyaXRlX3ZhbCksCiAg ICAgICAgICAgICAudmEgICAgICAgICAgICAgID0gdmEsCiAjaWYgR1VFU1Rf UEFHSU5HX0xFVkVMUyA9PSAzCiAgICAgICAgICAgICAuZW11bGF0aW9uX2Nv dW50ID0gdGhpc19jcHUodHJhY2VfZXh0cmFfZW11bGF0aW9uX2NvdW50KSwK QEAgLTI2NzIsNyArMjY3Nyw3IEBAIHN0YXRpYyBpbnQgY2ZfY2hlY2sgc2hf cGFnZV9mYXVsdCgKICAgICBwYWdpbmdfdW5sb2NrKGQpOwogICAgIHB1dF9n Zm4oZCwgZ2ZuX3goZ2ZuKSk7CiAKLSAgICB0aGlzX2NwdSh0cmFjZV9lbXVs YXRlX3dyaXRlX3ZhbCkgPSAwOworICAgIHRoaXNfY3B1KHRyYWNlX2VtdWxh dGVfd3JpdGVfdmFsKSA9IChndWVzdF9sMWVfdCl7fTsKIAogI2lmIFNIQURP V19PUFRJTUlaQVRJT05TICYgU0hPUFRfRkFTVF9FTVVMQVRJT04KICBlYXJs eV9lbXVsYXRpb246Ci0tLSBhL3hlbi9hcmNoL3g4Ni9tbS9zaGFkb3cvcHJp dmF0ZS5oCisrKyBiL3hlbi9hcmNoL3g4Ni9tbS9zaGFkb3cvcHJpdmF0ZS5o CkBAIC0xMjAsMTQgKzEyMCw2IEBAIGVudW0gewogICAgIFRSQ0VfU0ZMQUdf T09TX0ZJWFVQX0VWSUNULAogfTsKIAotCi0vKiBTaXplIChpbiBieXRlcykg b2YgYSBndWVzdCBQVEUgKi8KLSNpZiBHVUVTVF9QQUdJTkdfTEVWRUxTID49 IDMKLSMgZGVmaW5lIEdVRVNUX1BURV9TSVpFIDgKLSNlbHNlCi0jIGRlZmlu ZSBHVUVTVF9QVEVfU0laRSA0Ci0jZW5kaWYKLQogLyoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKgogICogQXVkaXRpbmcgcm91dGluZXMKICAq Lwo= --=separator Content-Type: application/octet-stream; name="xsa477-4.18.patch" Content-Disposition: attachment; filename="xsa477-4.18.patch" Content-Transfer-Encoding: base64 RnJvbTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgpTdWJqZWN0 OiB4ODYvc2hhZG93OiBkb24ndCBvdmVycnVuIHRyYWNlX2VtdWxfd3JpdGVf dmFsCgpHdWVzdHMgY2FuIGRvIHdpZGVyLXRoYW4tUFRFLXNpemUgd3JpdGVz IG9uIHBhZ2UgdGFibGVzLiBUaGUgdHJhY2luZwpoZWxwZXIgdmFyaWFibGUs IGhvd2V2ZXIsIG9ubHkgb2ZmZXJzIHNwYWNlIGZvciBhIHNpbmdsZSBQVEUg KGFuZCBpdCBpcwpiZWluZyBzd2l0Y2hlZCB0byB0aGUgbW9yZSBjb3JyZWN0 IHR5cGUgcmlnaHQgaGVyZSkuIFRoZXJlZm9yZSBib3VuZAppbmNvbWluZyB3 cml0ZSBzaXplcyB0byB0aGUgYW1vdW50IG9mIHNwYWNlIGF2YWlsYWJsZS4K ClRvIG5vdCBsZWF2ZSBkZWFkIGNvZGUgKHdoaWNoIGlzIGEgTWlzcmEgY29u Y2VybiksIGRyb3AgdGhlIG5vdyB1bnVzZWQKZ3Vlc3RfcGFfdCBhcyB3ZWxs LgoKQWxzbyBtb3ZlIGFuZCBhZGp1c3QgR1VFU1RfUFRFX1NJWkU6IERlcml2 ZSBpdCByYXRoZXIgdGhhbiB1c2luZyBoYXJkLQpjb2RlZCBudW1iZXJzLCBh bmQgcHV0IGl0IGluIHRoZSBzb2xlIHNvdXJjZSBmaWxlIHdoZXJlIGl0J3Mg YWN0dWFsbHkKbmVlZGVkLiBUaGlzIHRoZW4gYWxzbyBhZGRyZXNzZXMgYSBN aXNyYSBydWxlIDIwLjkgKCJBbGwgaWRlbnRpZmllcnMKdXNlZCBpbiB0aGUg Y29udHJvbGxpbmcgZXhwcmVzc2lvbiBvZiAjaWYgb3IgI2VsaWYgcHJlcHJv Y2Vzc2luZwpkaXJlY3RpdmVzIHNoYWxsIGJlICNkZWZpbmUnZCBiZWZvcmUg ZXZhbHVhdGlvbiIpIHZpb2xhdGlvbjoKR1VFU1RfUEFHSU5HX0xFVkVMUyBp cyAjZGVmaW5lJ2Qgb25seSBpbiBtdWx0aS5jLgoKVGhpcyBpcyBYU0EtNDc3 IC8gQ1ZFLTIwMjUtNTgxNTAuCgpGaXhlczogOWE4NmFjMWFhM2QyICgieGVu dHJhY2UgNS83OiBBZGRpdGlvbmFsIHRyYWNpbmcgZm9yIHRoZSBzaGFkb3cg Y29kZSIpClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBz dXNlLmNvbT4KUmV2aWV3ZWQtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5j b29wZXIzQGNpdHJpeC5jb20+CgotLS0gYS94ZW4vYXJjaC94ODYvbW0vc2hh ZG93L211bHRpLmMKKysrIGIveGVuL2FyY2gveDg2L21tL3NoYWRvdy9tdWx0 aS5jCkBAIC0xOTY1LDE1ICsxOTY1LDE1IEBAIHN0YXRpYyB2b2lkIHNoX3By ZWZldGNoKHN0cnVjdCB2Y3B1ICp2LAogCiAjaWYgR1VFU1RfUEFHSU5HX0xF VkVMUyA9PSA0CiB0eXBlZGVmIHU2NCBndWVzdF92YV90OwotdHlwZWRlZiB1 NjQgZ3Vlc3RfcGFfdDsKICNlbGlmIEdVRVNUX1BBR0lOR19MRVZFTFMgPT0g MwogdHlwZWRlZiB1MzIgZ3Vlc3RfdmFfdDsKLXR5cGVkZWYgdTY0IGd1ZXN0 X3BhX3Q7CiAjZWxzZQogdHlwZWRlZiB1MzIgZ3Vlc3RfdmFfdDsKLXR5cGVk ZWYgdTMyIGd1ZXN0X3BhX3Q7CiAjZW5kaWYKIAorLyogU2l6ZSAoaW4gYnl0 ZXMpIG9mIGEgZ3Vlc3QgUFRFICovCisjZGVmaW5lIEdVRVNUX1BURV9TSVpF IHNpemVvZihndWVzdF9sMWVfdCkKKwogc3RhdGljIGlubGluZSB2b2lkIHRy YWNlX3NoYWRvd19nZW4odTMyIGV2ZW50LCBndWVzdF92YV90IHZhKQogewog ICAgIGlmICggdGJfaW5pdF9kb25lICkKQEAgLTIwNjIsMTEgKzIwNjIsMTQg QEAgc3RhdGljIGlubGluZSB2b2lkIHRyYWNlX3NoYWRvd19lbXVsYXRlXwog c3RhdGljIERFRklORV9QRVJfQ1BVKGd1ZXN0X3ZhX3QsdHJhY2VfZW11bGF0 ZV9pbml0aWFsX3ZhKTsKIHN0YXRpYyBERUZJTkVfUEVSX0NQVShpbnQsdHJh Y2VfZXh0cmFfZW11bGF0aW9uX2NvdW50KTsKICNlbmRpZgotc3RhdGljIERF RklORV9QRVJfQ1BVKGd1ZXN0X3BhX3QsdHJhY2VfZW11bGF0ZV93cml0ZV92 YWwpOworc3RhdGljIERFRklORV9QRVJfQ1BVKGd1ZXN0X2wxZV90LCB0cmFj ZV9lbXVsYXRlX3dyaXRlX3ZhbCk7CiAKIHN0YXRpYyB2b2lkIGNmX2NoZWNr IHRyYWNlX2VtdWxhdGVfd3JpdGVfdmFsKAogICAgIGNvbnN0IHZvaWQgKnB0 ciwgdW5zaWduZWQgbG9uZyB2YWRkciwgY29uc3Qgdm9pZCAqc3JjLCB1bnNp Z25lZCBpbnQgYnl0ZXMpCiB7CisgICAgaWYgKCBieXRlcyA+IHNpemVvZih0 aGlzX2NwdSh0cmFjZV9lbXVsYXRlX3dyaXRlX3ZhbCkpICkKKyAgICAgICAg Ynl0ZXMgPSBzaXplb2YodGhpc19jcHUodHJhY2VfZW11bGF0ZV93cml0ZV92 YWwpKTsKKwogI2lmIEdVRVNUX1BBR0lOR19MRVZFTFMgPT0gMwogICAgIGlm ICggdmFkZHIgPT0gdGhpc19jcHUodHJhY2VfZW11bGF0ZV9pbml0aWFsX3Zh KSApCiAgICAgICAgIG1lbWNweSgmdGhpc19jcHUodHJhY2VfZW11bGF0ZV93 cml0ZV92YWwpLCBzcmMsIGJ5dGVzKTsKQEAgLTIwODgsOCArMjA5MSwxMyBA QCBzdGF0aWMgaW5saW5lIHZvaWQgdHJhY2Vfc2hhZG93X2VtdWxhdGUoCiAg ICAgaWYgKCB0Yl9pbml0X2RvbmUgKQogICAgIHsKICAgICAgICAgc3RydWN0 IF9fcGFja2VkIHsKLSAgICAgICAgICAgIC8qIGZvciBQQUUsIGd1ZXN0X2wx ZSBtYXkgYmUgNjQgd2hpbGUgZ3Vlc3RfdmEgbWF5IGJlIDMyOwotICAgICAg ICAgICAgICAgc28gcHV0IGl0IGZpcnN0IGZvciBhbGlnbm1lbnQgc2FrZS4g Ki8KKyAgICAgICAgICAgIC8qCisgICAgICAgICAgICAgKiBGb3IgR1VFU1Rf UEFHSU5HX0xFVkVMUz0zIChQQUUgcGFnaW5nKSwgZ3Vlc3RfbDFlIGlzIDY0 IHdoaWxlCisgICAgICAgICAgICAgKiBndWVzdF92YSBpcyAzMi4gIFB1dCBp dCBmaXJzdCB0byBhdm9pZCBwYWRkaW5nLgorICAgICAgICAgICAgICoKKyAg ICAgICAgICAgICAqIE5vdGU6IC53cml0ZV92YWwgaXMgYW4gYXJiaXRyYXJ5 IHNldCBvZiB3cml0dGVuIGJ5dGVzLCBwb3NzaWJseQorICAgICAgICAgICAg ICogbWlzYWxpZ25lZCBhbmQgcG9zc2libHkgc3Bhbm5pbmcgdGhlIG5leHQg Z2wxZS4KKyAgICAgICAgICAgICAqLwogICAgICAgICAgICAgZ3Vlc3RfbDFl X3QgZ2wxZSwgd3JpdGVfdmFsOwogICAgICAgICAgICAgZ3Vlc3RfdmFfdCB2 YTsKICAgICAgICAgICAgIHVpbnQzMl90IGZsYWdzOjI5LCBlbXVsYXRpb25f Y291bnQ6MzsKQEAgLTIwOTksNyArMjEwNyw3IEBAIHN0YXRpYyBpbmxpbmUg dm9pZCB0cmFjZV9zaGFkb3dfZW11bGF0ZSgKICAgICAgICAgZXZlbnQgPSBU UkNfU0hBRE9XX0VNVUxBVEUgfCAoKEdVRVNUX1BBR0lOR19MRVZFTFMtMik8 PDgpOwogCiAgICAgICAgIGQuZ2wxZSA9IGdsMWU7Ci0gICAgICAgIGQud3Jp dGVfdmFsLmwxID0gdGhpc19jcHUodHJhY2VfZW11bGF0ZV93cml0ZV92YWwp OworICAgICAgICBkLndyaXRlX3ZhbCA9IHRoaXNfY3B1KHRyYWNlX2VtdWxh dGVfd3JpdGVfdmFsKTsKICAgICAgICAgZC52YSA9IHZhOwogI2lmIEdVRVNU X1BBR0lOR19MRVZFTFMgPT0gMwogICAgICAgICBkLmVtdWxhdGlvbl9jb3Vu dCA9IHRoaXNfY3B1KHRyYWNlX2V4dHJhX2VtdWxhdGlvbl9jb3VudCk7CkBA IC0yNjgwLDcgKzI2ODgsNyBAQCBzdGF0aWMgaW50IGNmX2NoZWNrIHNoX3Bh Z2VfZmF1bHQoCiAgICAgcGFnaW5nX3VubG9jayhkKTsKICAgICBwdXRfZ2Zu KGQsIGdmbl94KGdmbikpOwogCi0gICAgdGhpc19jcHUodHJhY2VfZW11bGF0 ZV93cml0ZV92YWwpID0gMDsKKyAgICB0aGlzX2NwdSh0cmFjZV9lbXVsYXRl X3dyaXRlX3ZhbCkgPSAoZ3Vlc3RfbDFlX3Qpe307CiAKICNpZiBTSEFET1df T1BUSU1JWkFUSU9OUyAmIFNIT1BUX0ZBU1RfRU1VTEFUSU9OCiAgZWFybHlf ZW11bGF0aW9uOgotLS0gYS94ZW4vYXJjaC94ODYvbW0vc2hhZG93L3ByaXZh dGUuaAorKysgYi94ZW4vYXJjaC94ODYvbW0vc2hhZG93L3ByaXZhdGUuaApA QCAtMTIwLDE0ICsxMjAsNiBAQCBlbnVtIHsKICAgICBUUkNFX1NGTEFHX09P U19GSVhVUF9FVklDVCwKIH07CiAKLQotLyogU2l6ZSAoaW4gYnl0ZXMpIG9m IGEgZ3Vlc3QgUFRFICovCi0jaWYgR1VFU1RfUEFHSU5HX0xFVkVMUyA+PSAz Ci0jIGRlZmluZSBHVUVTVF9QVEVfU0laRSA4Ci0jZWxzZQotIyBkZWZpbmUg R1VFU1RfUFRFX1NJWkUgNAotI2VuZGlmCi0KIC8qKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioKICAqIEF1ZGl0aW5nIHJvdXRpbmVzCiAgKi8K --=separator-- From xen-devel-bounces@lists.xenproject.org Tue Jan 27 12:08:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 12:08:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214513.1524816 (Exim 4.92) (envelope-from ) id 1vkhru-00053I-73; Tue, 27 Jan 2026 12:08:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214513.1524816; Tue, 27 Jan 2026 12:08:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkhru-00053B-3V; Tue, 27 Jan 2026 12:08:26 +0000 Received: by outflank-mailman (input) for mailman id 1214513; Tue, 27 Jan 2026 12:08:25 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkhmx-0006UG-MF for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 12:03:20 +0000 Received: from out28-77.mail.aliyun.com (out28-77.mail.aliyun.com [115.124.28.77]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 26648e7d-fb78-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 13:03:15 +0100 (CET) Received: from localhost(mailfrom:houwenlong.hwl@antgroup.com fp:SMTPD_---.gHM653l_1769515387 cluster:ay29) by smtp.aliyun-inc.com; Tue, 27 Jan 2026 20:03:07 +0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 26648e7d-fb78-11f0-9ccf-f158ae23cfc8 DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=antgroup.com; s=default; t=1769515390; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; bh=sn8DXIXhfm3e8BqkD9qkMhWvqzUnAXhOWhEFAIyf3I8=; b=KWus0VZFPTe95TEOi8PqgJ21hzN4dBGiiujDKgJYxR4gnm76AuSdgHAhtdNhMYaLvR7nyAVp94ZxQPz04pBpbt0wktd838Phz+7XBVB9KdhI1hCQt5e/mspb7u9rANUEEjn4ba/Uzni1Gpbj+6Fx31VNeH3cfENM/outuzTrqpw= Date: Tue, 27 Jan 2026 20:03:07 +0800 From: Hou Wenlong To: "H. Peter Anvin" Cc: linux-kernel@vger.kernel.org, Lai Jiangshan , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Juergen Gross , Boris Ostrovsky , Ard Biesheuvel , Nathan Chancellor , Masahiro Yamada , Vitaly Kuznetsov , Thomas =?utf-8?B?V2Vp77+9c2NodWg=?= , Brian Gerst , Josh Poimboeuf , Andrew Morton , Alexander Graf , Joel Granados , Thomas Huth , Uros Bizjak , Kiryl Shutsemau , Pawan Gupta , Guenter Roeck , "Xin Li (Intel)" , Ilpo =?utf-8?Q?J=EF=BF=BDrvinen?= , xen-devel@lists.xenproject.org Subject: Re: [RFC PATCH 0/5] x86/boot: Allow to perform randomization for uncompressed kernel image Message-ID: <20260127120307.GA20714@k08j02272.eu95sqa> References: <7716B334-004D-4CBB-9237-E8AE5CE696CE@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7716B334-004D-4CBB-9237-E8AE5CE696CE@zytor.com> User-Agent: Mutt/1.5.21 (2010-09-15) On Mon, Jan 26, 2026 at 11:30:28AM -0800, H. Peter Anvin wrote: > On January 26, 2026 5:33:50 AM PST, Hou Wenlong wrote: > >Hi all, > > > >This RFC patch series introduces relocatable uncompressed kernel image, > >which is allowed to perform kerenl image virtual address randomization > >in 64-bit booting entry instead of decompression phase. > > > >- Background > > > >Currently, kernel image virtual address randomization is only performed > >during the decompression phase. However, in certain scenarios, such as > >secure container environments (e.g., Kata Containers), to speed up the > >boot process, the system may boot directly from an uncompressed kernel > >image. In such cases, virtual address randomization cannot be executed. > >Although the security enhancement provided by KASLR is limited, there is > >still a potential demand to allow uncompressed kernel images to perform > >virtual address randomization (for example, future support for x86 PIE). > > > >- Approaches > > > >Currently, the x86 kernel uses static compilation, but it retains > >relocation information through the '--emit-relocs' option, which is then > >simplified into a relocation table using 'relocs' tool. To enable > >virtual address randomization for uncompressed kernel images, relocation > >information is required, and there are several possible approaches: > > > >1) Who will perform the randomization: > > > >VMM: The VMM reads vmlinux.relocs after loading vmlinux to perform > >randomization. This would require additional modifications to the VMM, > >and vmlinux.relocs needs to be packaged when shipping. > > > >Kernel: The kernel performs randomization itself at the kernel > >entry point, requiring no modifications to the VMM. > > > >2) relocation information format: > > > >vmlinux.relocs: It only contains the necessary relocation entries and is > >simplified, making it small enough. However, it is a format defined > >within the kernel that was previously used only internally and is not > >part of the ABI. > > > >rela.* sections: It is the standard ELF ABI, but > >it contains RIP-relative relocation entries, which are more common in > >kernel, causing the kernel image to be larger. > > > >- Implementation > > > >The final implementation of this plan extends the 'relocs' tool to allow > >the insertion of relocation information into a reserved section of the > >kernel (referencing the MIPS implementation). This enables the reading > >of that information and subsequent execution of relocations when booting > >directly from an uncompressed kernel. Currently, this implementation is > >only available for 64-bit and has been tested with both PVH entry > >booting and standard 64-bit Linux entry. And the default reserve size is > >1MB for now, which is enough for defconfig. > > > >- TODO > > > >Clean up the decompression KASLR code to allow it to be shared with the > >booting phase. > > > > > >Thanks! > > > >Hou Wenlong (5): > > x86/relocs: Cleanup cmdline options > > x86/relocs: Insert relocations into input file > > x86: Allow to build relocatable uncompressed kernel binary > > x86/boot: Perform virtual address relocation in kernel entry > > x86/boot: Use '.data.relocs' section for performing relocations during > > decompression > > > > arch/x86/Kconfig | 20 ++++++ > > arch/x86/Makefile.postlink | 33 +++++++++ > > arch/x86/boot/compressed/Makefile | 6 +- > > arch/x86/boot/compressed/misc.c | 8 +++ > > arch/x86/boot/startup/Makefile | 1 + > > arch/x86/boot/startup/kaslr.c | 116 ++++++++++++++++++++++++++++++ > > arch/x86/include/asm/setup.h | 1 + > > arch/x86/kernel/head_64.S | 7 ++ > > arch/x86/kernel/vmlinux.lds.S | 20 ++++++ > > arch/x86/lib/cmdline.c | 6 ++ > > arch/x86/lib/kaslr.c | 5 ++ > > arch/x86/platform/pvh/head.S | 15 +++- > > arch/x86/tools/relocs.c | 64 ++++++++++++++--- > > arch/x86/tools/relocs.h | 15 ++-- > > arch/x86/tools/relocs_common.c | 24 ++++--- > > 15 files changed, 309 insertions(+), 32 deletions(-) > > create mode 100644 arch/x86/Makefile.postlink > > create mode 100644 arch/x86/boot/startup/kaslr.c > > > >-- > >2.31.1 > > > > Hi! > > At a very quick glance this seems like a very reasonable thing to me, but since the intent is reduced boot latency (a very worthwhile goal!) do you perhaps have any measurements to show how much improvement we are talking about? That would be really useful. > Hi! Uh, sorry that it may not meet your needs. In fact, it will slow down when booting directly from an uncompressed kernel. The improvement described in the patchset compares booting directly from vmlinux versus booting from bzImage when we want to enable KASLR for guests in MicroVM scenarios. There is a similar idea in [0], where KASLR randomization is implemented on the VMM side. Now we want to implement it directly in the guest kernel to reduce modifications to the VMMs. There are some measurements in [0]; however, the comparison is between vmlinux and bzImage. In my test environment, compared to the original direct kernel booting, it would add 2ms for my test configuration [1] based on the Kata Containers repository due to the self-relocation phase. Booting from bzImage does not affect the boot time, as it simply inserts 'vmlinux.relocs' into vmlinux, resulting in no change to the total size. The decompression time should also not be affected; I didn't notice any difference when measuring the decompression(). [0]: https://dl.acm.org/doi/epdf/10.1145/3492321.3519578 [1]: https://raw.githubusercontent.com/virt-pvm/misc/refs/heads/main/pvm-guest-6.12.33.config Thanks! > Thanks! From xen-devel-bounces@lists.xenproject.org Tue Jan 27 12:09:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 12:09:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214596.1524825 (Exim 4.92) (envelope-from ) id 1vkhtM-0005mw-Fh; Tue, 27 Jan 2026 12:09:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214596.1524825; Tue, 27 Jan 2026 12:09:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkhtM-0005mp-Ck; Tue, 27 Jan 2026 12:09:56 +0000 Received: by outflank-mailman (input) for mailman id 1214596; Tue, 27 Jan 2026 12:09: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 1vkhtL-0005mj-Aa for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 12:09:55 +0000 Received: from mail186-9.suw21.mandrillapp.com (mail186-9.suw21.mandrillapp.com [198.2.186.9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1568a657-fb79-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 13:09:52 +0100 (CET) Received: from pmta10.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail186-9.suw21.mandrillapp.com (Mailchimp) with ESMTP id 4f0kjp6wQ4zK5vlN1 for ; Tue, 27 Jan 2026 12:09:50 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 931d19afa0f34760894945371598942e; Tue, 27 Jan 2026 12:09: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: 1568a657-fb79-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1769515791; x=1769785791; bh=vua/fd8T1a6bAo2xrvrSMCfcHJPq1mx1BzNMWefyFZ0=; 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=wamqBZBet342RDWcin7LEUb/PavFim0Tpf5YiScdFM4UupY3C89XYvyFdbwWY6r0x EIHYQZ39YWlYbZsxTQgQjNZwrRy+rUhG/FtkozwwizlGpfbLab+GU/c0lYMzUNqz/f FPjlmJl68Hw5/7kHSwaXx6UqAJ/HjqDRI1ZJOlCXVFKGfvNHd/k0bY9SWCxdaclIxO g5XeJmKrDAMK/ir4tu6eL/QpdR9f/FUtCy6zW0IqkGTOgbAakUykncpsornRfWDjKJ NaRQLhNVEum1HWtYsWmE1S7tubgm4n7Nk/oDJgRLcPk8LXVyB1vKlbOC0gBst1vm3J RIiAwalW3xudQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1769515791; x=1769776291; i=teddy.astie@vates.tech; bh=vua/fd8T1a6bAo2xrvrSMCfcHJPq1mx1BzNMWefyFZ0=; 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=RPhRxMNfYBsiuOZik7fSLjBWhXQX1/P6/Iz88lv9sEnvnWnUN4xn2xvhrsnnhwWvU BALGYNamHltxuFRlEw+0bn0jP/AcWjRkLrNLJOJYF6tUzqpO3jbpglCRsaQtPnJ/NV zp+2YnnpndpwEJ/W5DgOL4Qkl3NsjRSkunrTbN3cmEFO081eE2nLvcahko4jea5MbD 4gGU0SzcpCQsLvZWNsYTSfUTloaVwU+fJhum87vCDxhQ8+LUaq+E57bRnhxWT3dJDf nfavImZRaAFhDI/Kr3rDDcUGIEAMxIjTn8KgmT3Su7ErJH9emo6QoDdJTErTa+eJJ6 /pRMKZnleQr0Q== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=2000/16]=20x86/cpu:=20Cleanup=20for=20NX=20adjustments?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1769515789933 Message-Id: To: "Andrew Cooper" , Xen-devel Cc: "Jan Beulich" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Julian Vetter" References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <92bff6a4-8fb0-4992-8305-8386f480de74@vates.tech> <658c0167-c3df-4acd-92f8-8c3f022ae453@citrix.com> In-Reply-To: <658c0167-c3df-4acd-92f8-8c3f022ae453@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.931d19afa0f34760894945371598942e?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260127:md Date: Tue, 27 Jan 2026 12:09:50 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 27/01/2026 =C3=A0 12:39, Andrew Cooper a =C3=A9crit=C2=A0: > On 27/01/2026 11:23 am, Teddy Astie wrote: >> Le 26/01/2026 =C3=A0 18:56, Andrew Cooper a =C3=A9crit=C2=A0: >>> I was hoping this to be a patch or two, but it got out of hand... >>> >>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2287078= 891 >>> https://gitlab.com/xen-project/hardware/xen-staging/-/commits/andrew/nx >>> >>> The branch has one extra patch to fake up the firmware settings being s= et to >>> Gitlab CI, not included in this series. >>> >>> Julien: This ought to suitable to rebase your cleanup on to. In the en= d, I >>> did the AMD adjustment mostly because I needed it to test the correctne= ss of >>> the prior cleanup. >>> >>> The final 4 patches are tangential cleanup which I've kept out of the p= rior >>> work in case we wish to backport it. Everything prior is relevant to >>> untangling, and mostly for the benefit of the AMD side. >>> >>> The early patches are hopefully non-controvertial. Later patches are a= little >>> more RFC, and in need of further testing. >>> >>> >>> >> Tested on a Intel machine with "DEP" disabled, and "Require NX support" >> disabled, I get a pagefault in hpet code > > From above: > >> Julien: This ought to suitable to rebase your cleanup on to. > > This is cleanup only.=C2=A0 I've not got the bugfixes for EFI boot yet, s= o > the behaviour you see is still expected for now. > > Although, thinking about it, it might be better if I try to merge the > two series, so everyone can test the end result. > > Thoughts? > +1 >>> (XEN) Xen version 4.22-unstable (tsnake41@(none)) (gcc (Alpine 15.2.0) = 15.2.0) debug=3Dy Tue Jan 27 12:06:46 CET 2026 >>> (XEN) Latest ChangeSet: Mon Jan 26 17:53:45 2026 +0000 git:6491616ddd >>> (XEN) build-id: 035024497a4cadebf9e5a2ded61f63ac >>> (XEN) re-enabled NX (Execute Disable) protection >>> (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3 (r= aw 000306c3) >>> (XEN) BSP microcode revision: 0x0000001a >>> (XEN) microcode: Bad data in container >>> (XEN) Microcode: Parse error -22 > > As a tangent, what's going on here? > > This is the first time I've seen the error outside of my own testing. > Is it a container you expect to be good, or some leftovers on a test > machine? > I'm trying to load a Intel ucode (taken from Alpine Linux intel-ucode package) using `ucode=3Dintel-ucode.img` in xen.cfg (UEFI direct boot). Many distros ship microcode in a single CPIO image with e.g "kernel/x86/microcode/GenuineIntel.bin" in it. > ~Andrew > -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Jan 27 12:30:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 12:30:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214608.1524835 (Exim 4.92) (envelope-from ) id 1vkiCd-0000HJ-VB; Tue, 27 Jan 2026 12:29:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214608.1524835; Tue, 27 Jan 2026 12: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 1vkiCd-0000HC-SU; Tue, 27 Jan 2026 12:29:51 +0000 Received: by outflank-mailman (input) for mailman id 1214608; Tue, 27 Jan 2026 12: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 1vkiCc-0000Df-6g for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 12:29:50 +0000 Received: from SN4PR0501CU005.outbound.protection.outlook.com (mail-southcentralusazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c10d::3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ddd4dce7-fb7b-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 13:29:48 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by PH8PR03MB7218.namprd03.prod.outlook.com (2603:10b6:510:25a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Tue, 27 Jan 2026 12:29:42 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9542.015; Tue, 27 Jan 2026 12: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: ddd4dce7-fb7b-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xYEzkae1r8C2d/f2cV+NgZ938icvnoNZnpHieWBx9vDIUAlQnpAMcOplF4aiEQa8qIZ6NpBDe6NkNYgN2g5sGgdHBdCIUCFiBZ/qRsgQL2F9KpmgNDGQbebip/CEpH/kgzEMlJhNF1BAyEneVrRpKg9nZGihld/8ooLJPRK5QCYzqXcmpoZxYU6V/oTWoE2+EVUnZg+SZtFcc9XD7KroypxhClw/Rq2JXnvgBSk5aMs+m95KnRjR40QcY1Poyuic5MTQjU2hoNtissjIgfVjmrA1dMxMr9N+Xb8rMhXdXmydUy6NoUd0NQJ4Dk9O84R/+gv5gaQvtSVoxXToeLXqzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xCqeW2PG1CNelc+bIOFyIOxjTQxwbgoeXzGtvuBIEdw=; b=ESJx1q5u3puiS8aBZE0Wu1R9OPUTHsDlcaHp5k0TXFLvxDii9Gad7l08+VylvbCOePGTbdtsrNSVhEQokhpCMF6d/Qf17NbYzuvvwWlcGgz2a/uUwmU5JaehOh9wn1neDWRHbGNS2MxFypCz6kOmSgQS3ibXcMRepl7zV1r1b7O0WiGfd28AWy16XGwhpmVK1nsDQbSAPwsvrq8w0LRqXQZXuVmQbhzpFjKqpMxQ5XTZKhKojNok05ZuLAOV8UmjTvAmeMTowXsv2ZyzlU7Tczq6fnN9SXgZIqiCNLFzOTUFe6dT6n4nAaPekEiqyNXe1sDqk7aweTcrdzpJr4+z+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=xCqeW2PG1CNelc+bIOFyIOxjTQxwbgoeXzGtvuBIEdw=; b=RD6hG0OG2L1KFShQPTTxNj5gb4rB4xuyY/SYnlNSLVGJSLycMhg8cY1SeO3HUgtCMmfvcELXcB8uN0MZK0FuasNi63pDA8bi6xB/I5FcjDj7fBrYKV85SiJBkpq4f5GglEVY2yycBaZIspJWsG6W8mqiqnNXE2JE4bxwGF3rmcA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <08d9aeaa-d503-4e75-863b-dee3b46c42a0@citrix.com> Date: Tue, 27 Jan 2026 12:29:37 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter Subject: Re: [PATCH 00/16] x86/cpu: Cleanup for NX adjustments To: Teddy Astie , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <92bff6a4-8fb0-4992-8305-8386f480de74@vates.tech> <658c0167-c3df-4acd-92f8-8c3f022ae453@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0697.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:37b::12) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PH8PR03MB7218:EE_ X-MS-Office365-Filtering-Correlation-Id: df9f1ca4-a57a-4fcd-6898-08de5d9fbea9 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?S1AxSU1EbHpPWWV0bUNyMWhCQmZnQ2dqTWhrN2VJZFJsSDRjK0dvU0d3LzZm?= =?utf-8?B?MTREak5Gd3JBV0hwTlI3NWZhenJBWW53TzJ4ZGVUbDBBb0FxbnMwMGViVEtQ?= =?utf-8?B?d0Y1ZGlYNkpMNDVaeGJMc2NyOTFiOVpDZ2FoNGthZTBZbnp6d2d5Zjc1RHgx?= =?utf-8?B?TDdXT3pFVUtSSEt2TDJQS3JMVmMveUxFeVhUMU9tUmVIalZPOGlUV1puWU1q?= =?utf-8?B?WElTRkFoRW95WkVTY3o4cGJnUTRTNUppQjRtMWVjbVh5b3VMUGVrbmJWaGNH?= =?utf-8?B?UkI3dG9QS2NmcGJOV0dxc21PNXlaVG05VEFTeUJJcG5TSnJtRzg3UDFmUEZQ?= =?utf-8?B?YlhqazVpN1V0ai8xRm5NVXk5QkdleW1uejBSQmZ6RzVxVVVyazhHczRITnhD?= =?utf-8?B?MkNwZDBEd0tiRnZqRWF0RnVMUGZBaXFIMmU5dFoyM0Zaeis5bWZTcXVhN0Zv?= =?utf-8?B?dXA5WGVVWEc3aTVUNnVHblUyTHo3NlBYWnFacGcvandTUXpTTGdWWE1jWDhq?= =?utf-8?B?aEFYZFdIZEcvMm5laWEvRnUzSlNURHRoNU8wK1VQZzVjUzRCSWdHV2N4bHRz?= =?utf-8?B?a2pzM2x6K1kzYmtNN2lScC9xa2x2b2NVaUk5NEhPNmU0Q0RGYjU1dzBzVVJr?= =?utf-8?B?WTJ2eVlCWWltTU5ydGJWWGtMV2hJeXFWSzIwck1lSHBldW8yQXRpQklBMEcv?= =?utf-8?B?dnRxWmhBZm0wNkxiU0lGTEtNbGhGUk5NUW5naGYzUDRkRlo1Z1JMdG5XQjFu?= =?utf-8?B?NU1FbHgrNDEvc2R1aVRvQWhkTnhPTWtLZFFXbEwvMStUM29YNXJaM0lWOUZU?= =?utf-8?B?d2s3d1BaSXFOSGVIRk53ZXRCSHE3d1JTazhxMVNGRVZLSW9XSHRSMkdMY1hG?= =?utf-8?B?K09ZVU51UEx1Sk90ai9EU1B1OFI2WFRrNkNlc2FvVk0wR084TWpwakpwODYz?= =?utf-8?B?Z3BCNkd2ajdlRFZhZ2l1ZVdJbWhCMUxWRlhzbTFQWE9ubE9pZFJic291RmZI?= =?utf-8?B?M3VIbXRSYVRPeS9NaVp6bWt4cXJUT09QbDdXL3JKS0NSKysyL29ObENtcjNn?= =?utf-8?B?UXdCaC9jdzRpcTlPaFNXQmJLVUlIY3RrTmgyWTB0WmJ4ZExmUkNML2FqKzFV?= =?utf-8?B?UlJYc1ZhS1BpYjZLV2s5T2tRZHlzY0k3dWNQWWh1R3NxK3Y1VkdFOElhSktx?= =?utf-8?B?M2VBUkhOMEI3M2dVd24zQ1NRNzhPWUNRNGt2Q3ZteksrZStqVFF4VzBidHk1?= =?utf-8?B?K2hrWVdGU0NmalZLUG9ib1UreHJ4STBMQkNXaENIZUpxTVJQRFFjWXVyKzY4?= =?utf-8?B?cStzV0ttdU02RllONmRwR3pOb2g5TlVTUHliNGorZ2pYZ1N3S0Rkc1NQNERw?= =?utf-8?B?bFRKNEcwRmh6bDVQbmhsNnprb3VUdEtLQlFPTk95M2VINkZLeEVJOTdaVU16?= =?utf-8?B?cUw2Rk81aVRPNUlQdkY3aHJtL1RkR3paME56L3o5RnlTVXNDWGhIOVE3eVVT?= =?utf-8?B?dU5hSGkxNjByK3FFeTFHbjdwcGk4T2JDMXpjSmtOM2NkYTNKOG9lKzQzdng5?= =?utf-8?B?N1l6cnB2ZVRrSW16bit4TWVib3NDZ203SU1yUGJWUDVRSmFXSmRvNW5PRGp2?= =?utf-8?B?Y09pMERTSmoranhvZHg0L080am1kaGplK0krOTFWaWsxM21SVVNVbFZ3bG1E?= =?utf-8?B?VVdEenZDM2FWa20zKzRYd1lxeW8zckh4MFlQUjhRZkI1dVljbGVWQkZCU0dI?= =?utf-8?B?MkdXRWdMbFQ3d2NsWU1kVkRJRE9MMXNzSWRPeU5yZHF1bzNLYUNYMGRhMFc1?= =?utf-8?B?R0hYd3NjR0tDdmtPdkdkTVV6SzlIY3piZXlnak9vcmVJTStORXpTRXQ4Tjhq?= =?utf-8?B?ckhLUTQ5TTZLNkYzT0FxZ1g5VlFlMUE2ZTBmMStQWmN2WWFaNFovZFI2eVR2?= =?utf-8?B?enVrQWZjL3AxdWdsZDlkTkVvMXhWMno1TkVHbUhpb3lnWTR0b3g4WURYN3Jy?= =?utf-8?B?Q1hQdjNSL2lJTEhpb1ljRVJtcVd2cGVhTXFRS2tScEYyS1FEWVhKcG13c2dF?= =?utf-8?B?b2F1Vm1IVWEzUXJXcXFaWnR3eGpzZGJkVDYxYStSN2ZSdEVUREhGR3FlNHJw?= =?utf-8?Q?flg4=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VTNuWWxiMkJiQzk3VWV5QzYxclEzbFkwYWtNNEJQcDByTXc1Q3pVcHE1ZlBQ?= =?utf-8?B?enM0WHdwNnRFVXEvS0pyVy8zeW42WHRDKzQ2MmhtZXZmd3ZvS1VCbTVXeG9K?= =?utf-8?B?ZEdxSGdCYXc1b3k5TDhVMWRHQ29iUXZjT2g2MlhrTzRtVUpTVUZXQVVENkxz?= =?utf-8?B?WUVtSmxOcnM0ZS8ySXVuYkFWU0lHbW5qYUU1b0cwcVh2WWsxOEZlNm9JMDNC?= =?utf-8?B?SWJBejVPTDU4SXNUY1FYaEFIcFFZbWZNQnpudDlibHFWVXBGNkpyWE5xTHcx?= =?utf-8?B?UkRmRW9iOVVMVzNMQU1ZL0xZWUUxSFVOMHI1LzZjelRaM2hYUm5xMElJODR5?= =?utf-8?B?ek42eFVlQWZ4cHh0YlRjcFBCbGJWaGkwc000KzJmNlhWWisrdHFhMXNuNTB0?= =?utf-8?B?dVNHNUhBWWRsOTRWWVBzR3I2MzJ6cUFidTRSVVF4T2lkb1ZpN0lmUlkzVWZ6?= =?utf-8?B?ZUlhNlhhZGtVb3NSbWorWmVpRXh5WW83OWF2K3VMcEs5ZVQ5SjdOdUwxMCtp?= =?utf-8?B?Y0taeFJFWS85dFJRREdhSTZ4ejNXckc5UlMwZnFnTUx4NktXdW5tZkl2c1Vp?= =?utf-8?B?bkhrMkFpZmsrOGJ2VVo2Q2MyYmJwQ0lzMEtwaUlOS1FrS1h4WHJXOFNkcDQ5?= =?utf-8?B?UVJBdnhQUXpZTFFCWVluT09VMGpsZHVTT09GZEVxS1VhMTRHSUpoMFEzMnRj?= =?utf-8?B?bkl0Qk4wQ1VuWTNQcklINXJEODlqc3Fyd3JVRXFMNnBFSXRpbzZOenNrdGw3?= =?utf-8?B?RUFIUkFYanNpbVlkMjF2bXdUN3pCVjFpTTdlcGJRTkpGbUtXZTJYRW5ReFBM?= =?utf-8?B?NGRXTVRtZktwM1hWSmVSTWJSMnZOYWZrWkd0NTEyck5ZMVZEOEJqWnBTZ1NF?= =?utf-8?B?dnNlR3IyTklOYURWd0hwbDJiQTBrZENOd1c4UlhpUGk4Nis2bjNTWTNRcWFW?= =?utf-8?B?VExNR2NVcjFhNTFvQUI4Tm9LMjcyRXZTTTAwNEk3MU1UTlpLbHJ2QXAxZGJS?= =?utf-8?B?aEtBd3FiK3k3WDcvQWU1QkROMHZUYW1tNmt0bGE3QTBpVTh6SGVkaTh3anVJ?= =?utf-8?B?RDdTN0pMU2puTEY3dWN5UWJOUEFnQ1VpOUtFTjQ5U3J3REdVbHR5Q0NNZmRJ?= =?utf-8?B?ZkQyd3VYZWdqUktMZ1dSMnJ3RCtNK0tXSVpvc2I5Q29KbFFTdWZoZ2pRMmtS?= =?utf-8?B?STdXZlFhZnVCRkdEUVUrUmJjZ3pYTUdmR1Z0OCtrTVgvdjYya1BnY25pdmRF?= =?utf-8?B?Sm4za0pFeFlCWURwTU16NUZ1QzExcWJqVExTcWtkWUFtL002YTRaWXBpQmxv?= =?utf-8?B?cTBhUFhSdThOZ2QyTmFmdWo3M2NyQlZyelhmTlBYY21TMjdoRWR2YkpXTm0z?= =?utf-8?B?SVVoUXVmdGxaUXRkVXpFa05JNG50WUVXV1B6bENrbGRxWHI0TktWd2VaZm5k?= =?utf-8?B?TDRmQjkwVTNlOFNxRGhyNlhkb3JyWFlXR1hrS0ZnUTQyRzI4TDVVb0F0Q2xG?= =?utf-8?B?eUM0S0FoQzBPa3hvbEhOaXR1R21lT3RSRVdoTEI3azdPU28wY0hVcmxNSTZM?= =?utf-8?B?YkxKQndYc1VNd1BPd3Z2Z1I2WGFQeWVBd3YxUWd0SkxUd3JxS3NWQnRoZWEv?= =?utf-8?B?VkI5UlJmRXYyNDVDWS9RUG4zVVJGYVpNYTRLR2RwQXlMSGd2L0lrRXlNdjJP?= =?utf-8?B?NEpJSkRNTHMxSnJXQ3RKR3ZWaUs3SkViV0FRd09nNTRrcm55cDhXK0p3YkJT?= =?utf-8?B?VUhTUHFyc0RBaVFmVWlWSjNVVXA0dkhadVQrbURlT29ENFNxTG02T3FNZ083?= =?utf-8?B?YjFRZElGeTh5ZmVmcHpCK2RLV1FZREtIS2cvRmpLME53Z3ZFcktJaDhQQTNM?= =?utf-8?B?ZlJaaTc3Yk1vVFR1RGsvRnMyS1BMYkY3dzlzbkJPQVZ4ek5SVXEzbzg3QVZS?= =?utf-8?B?WVBHaGpmMmE0Wi9ST21ZSVdNZ01seEV0MTNoRHROMEkwNTdDemNFTGxySnJB?= =?utf-8?B?RmVZbHJYUnFkWFJsM0lnRjlHUFliZ095TkY3YjlhT2ZVRXpCdWZwTUpXaTRr?= =?utf-8?B?U2lmV3ZsQ3dQODZGZ0F3bi8zRnVRdFNXbFE2ajBqT3RLTEMyVHdPdlM0UVNl?= =?utf-8?B?bDVxVG1FVGI4NE5Zd3RqbVdPaTM2aEx0UGRXM2dlTFRUbnFrR05WN29Ub2xi?= =?utf-8?B?U3ZkVEIyRVh0bng4cThUMHFEbm80UUwvWTUrMUpjdk1pVVU0SjFzbTNqd3Bl?= =?utf-8?B?cFcvaTVPekhINTgzcElxZlAyUTlNck4yWHhqeGJmTE03bjArMU96bFY1cjNE?= =?utf-8?B?djk1bWsrclh1RGxFaS9GQzJtTFlnRHJ4WmR1RmM0eU5PeFl5aHZUdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: df9f1ca4-a57a-4fcd-6898-08de5d9fbea9 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 12:29:41.3837 (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: nAIqyYbauJaouPf24TrhDIHRpJSUEAo3DCU6tYI7FMuIXhPxy/CQjcwUjkQz5rPvEwGOCwwnFUcmJ6WlTzaSf+j3wvWFApHNbLSGpucYYYA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR03MB7218 On 27/01/2026 12:09 pm, Teddy Astie wrote: > Le 27/01/2026 à 12:39, Andrew Cooper a écrit : >> On 27/01/2026 11:23 am, Teddy Astie wrote: >>> Le 26/01/2026 à 18:56, Andrew Cooper a écrit : >>>> I was hoping this to be a patch or two, but it got out of hand... >>>> >>>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2287078891 >>>> https://gitlab.com/xen-project/hardware/xen-staging/-/commits/andrew/nx >>>> >>>> The branch has one extra patch to fake up the firmware settings being set to >>>> Gitlab CI, not included in this series. >>>> >>>> Julien: This ought to suitable to rebase your cleanup on to. In the end, I >>>> did the AMD adjustment mostly because I needed it to test the correctness of >>>> the prior cleanup. >>>> >>>> The final 4 patches are tangential cleanup which I've kept out of the prior >>>> work in case we wish to backport it. Everything prior is relevant to >>>> untangling, and mostly for the benefit of the AMD side. >>>> >>>> The early patches are hopefully non-controvertial. Later patches are a little >>>> more RFC, and in need of further testing. >>>> >>>> >>>> >>> Tested on a Intel machine with "DEP" disabled, and "Require NX support" >>> disabled, I get a pagefault in hpet code >> From above: >> >>> Julien: This ought to suitable to rebase your cleanup on to. >> This is cleanup only.  I've not got the bugfixes for EFI boot yet, so >> the behaviour you see is still expected for now. >> >> Although, thinking about it, it might be better if I try to merge the >> two series, so everyone can test the end result. >> >> Thoughts? >> > +1 > >>>> (XEN) Xen version 4.22-unstable (tsnake41@(none)) (gcc (Alpine 15.2.0) 15.2.0) debug=y Tue Jan 27 12:06:46 CET 2026 >>>> (XEN) Latest ChangeSet: Mon Jan 26 17:53:45 2026 +0000 git:6491616ddd >>>> (XEN) build-id: 035024497a4cadebf9e5a2ded61f63ac >>>> (XEN) re-enabled NX (Execute Disable) protection >>>> (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3 (raw 000306c3) >>>> (XEN) BSP microcode revision: 0x0000001a >>>> (XEN) microcode: Bad data in container >>>> (XEN) Microcode: Parse error -22 >> As a tangent, what's going on here? >> >> This is the first time I've seen the error outside of my own testing. >> Is it a container you expect to be good, or some leftovers on a test >> machine? >> > I'm trying to load a Intel ucode (taken from Alpine Linux intel-ucode > package) using `ucode=intel-ucode.img` in xen.cfg (UEFI direct boot). > > Many distros ship microcode in a single CPIO image with e.g > "kernel/x86/microcode/GenuineIntel.bin" in it. Ah, that's a known thing that doesn't work and has never been addressed.  People have been complaining for years, but not on xen-devel. It's also the subject of a documentation fix that is still pending (and now needs yet another rebase).  https://lore.kernel.org/xen-devel/20251215153245.2675388-1-andrew.cooper3@citrix.com Now that the ucode boot module handling is clean, we can probably try both a CPIO and raw probe when given a fixed module. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 27 12:55:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 12:55:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214631.1524845 (Exim 4.92) (envelope-from ) id 1vkiav-0004cw-Sp; Tue, 27 Jan 2026 12:54:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214631.1524845; Tue, 27 Jan 2026 12:54: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 1vkiav-0004cp-Q3; Tue, 27 Jan 2026 12:54:57 +0000 Received: by outflank-mailman (input) for mailman id 1214631; Tue, 27 Jan 2026 12:54: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 1vkiav-0004cj-CY for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 12:54:57 +0000 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [2a00:1450:4864:20::333]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 609ca686-fb7f-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 13:54:55 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-48068ed1eccso6231725e9.2 for ; Tue, 27 Jan 2026 04:54:55 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066be7404sm64991775e9.1.2026.01.27.04.54.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 04:54:54 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 609ca686-fb7f-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769518494; x=1770123294; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=VjfiHNnrpGC8CDoMxoZHu7UqDDcLfDorH4rBeA6qkuA=; b=Ye/iiUkoejGW96Ivr2UwJ8YwHkcrquwM3EM0tnVQUQ81ZWdAqUo+Zb94otRcJgFR/y l5/IhRedIOmdCWmYGK/0r7y4vc2Fm+n8IEhouzkeKop/tJ6eR9wgzuDxodd2UUu21jNA /3qWZu0UscioD+Vx3wt+3zX7uQ8dLGjMA1kRK0MJ6kQeytWvIsN5YUqJx+y22VHRKvqz HZUGedajWGnZaHdbzm4xtQe03BVng2AxW6ejJ78ja9cSJyvmiCfBQHLhBKn48G0y2baf scxkbbiuq2SxQVraM42Dod6sO1XX03UkNI1eRxSET+3FMxnxodkHxVI4KwW7ITPE+6kD xI3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769518494; x=1770123294; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=VjfiHNnrpGC8CDoMxoZHu7UqDDcLfDorH4rBeA6qkuA=; b=V2bpPizU6ltFRgZavcNhhvMCy96TC/NC4NTP2+YbESWtnV0HeKRJA/8U63fU1f3hzh ey/LBaRQOA5EGplHjby1mXIeaJfI23TYHxmMtCyPsgHpiXFXVXYv578zSUf7P+gpZ9mK cUEvISxg4YpY0lgN156XJIqZMucWJW4JoUEiETPYBcxygsWqwonpEPp25O4d4t/3QE8M PDvy245TACzkNDiKu8A2Ra/kViPfhUh48hDIWApUpCpusxKoTrTDBLeIiqiltCuQfBme TyAjys78Ah2051xRcNM3TRIw5Ukz0q252Qzt5E6JIKVp41hK1u/6Bq7Hv/vYc9HtTKEY TNzw== X-Forwarded-Encrypted: i=1; AJvYcCX5kFJ+4g6LTnOCWm2MTidZBRBwPnfK3QyWbh9e5b+KiTfcYzy2tyrM6TMSXCr1pyA5wn4sUU6h5NQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YyXux/NSysqY2W2N8lwRzFngsPWuB+XlSHZxrIJ9sQ8IgIruLxu ucLTvP3Kev1BN6JxTCfkWK0P3aS732WHAsfsi2jx/OfrLiyv3rzkf7Prtk3qEtCrVw== X-Gm-Gg: AZuq6aKRbkcNBlS+H8tY/3LRFOIMXYnt8s3IWkNTjF1lgM1x+M7bx8zD43idez0XBxG BI6U4EDRKt3CyMscxxkuPCBVnFJlFTJY19yzHMhpg5YP5s0XOBuM+tNtgughamwsiLpVA3Z/n2C zuOTsRQny52AmSEaElk/2pYcsFoBHPYh60m0WATE6JMeb6WgQB7STTxpDV/ogaFZ06/Qcv1RDuN NN0cAcg8N9Q7Xoq7KgTDTmyiFjyUvkLJ5tZrxVgSk9VCZRqZzXFmgAVMYjDmcOQAlR+dlggN/7o wxwHWjOiTtxA1byK3eiC8xLGxt79feHDJP6di5bS91DPD4snknKpbFfXEvOGiXVP50b3yEEvJ76 Nbi+IS1e2G6o+ruWOLNKOAYMVc47cgGdJwyFYPgBmmWD9U0El7n7fjX00OQWvzWyMbEVfeUJMJ2 ObtgTxzhVXjBkVscN2Qc0/mfOY/QwEP2kVoVQ2JjKzo644b00uR1uLwEinHYjPYCqQ6d+TrFwqb Bc= X-Received: by 2002:a05:600c:4689:b0:477:c71:1fc1 with SMTP id 5b1f17b1804b1-48069c55610mr19414875e9.19.1769518494283; Tue, 27 Jan 2026 04:54:54 -0800 (PST) Message-ID: <98758ea8-8add-4879-a28c-bd8d6d898bba@suse.com> Date: Tue, 27 Jan 2026 13:54:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 00/16] x86/cpu: Cleanup for NX adjustments To: Andrew Cooper , Teddy Astie Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <92bff6a4-8fb0-4992-8305-8386f480de74@vates.tech> <658c0167-c3df-4acd-92f8-8c3f022ae453@citrix.com> <08d9aeaa-d503-4e75-863b-dee3b46c42a0@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: <08d9aeaa-d503-4e75-863b-dee3b46c42a0@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 27.01.2026 13:29, Andrew Cooper wrote: > On 27/01/2026 12:09 pm, Teddy Astie wrote: >> Le 27/01/2026 à 12:39, Andrew Cooper a écrit : >>> On 27/01/2026 11:23 am, Teddy Astie wrote: >>>> Le 26/01/2026 à 18:56, Andrew Cooper a écrit : >>>>> I was hoping this to be a patch or two, but it got out of hand... >>>>> >>>>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2287078891 >>>>> https://gitlab.com/xen-project/hardware/xen-staging/-/commits/andrew/nx >>>>> >>>>> The branch has one extra patch to fake up the firmware settings being set to >>>>> Gitlab CI, not included in this series. >>>>> >>>>> Julien: This ought to suitable to rebase your cleanup on to. In the end, I >>>>> did the AMD adjustment mostly because I needed it to test the correctness of >>>>> the prior cleanup. >>>>> >>>>> The final 4 patches are tangential cleanup which I've kept out of the prior >>>>> work in case we wish to backport it. Everything prior is relevant to >>>>> untangling, and mostly for the benefit of the AMD side. >>>>> >>>>> The early patches are hopefully non-controvertial. Later patches are a little >>>>> more RFC, and in need of further testing. >>>>> >>>>> >>>>> >>>> Tested on a Intel machine with "DEP" disabled, and "Require NX support" >>>> disabled, I get a pagefault in hpet code >>> From above: >>> >>>> Julien: This ought to suitable to rebase your cleanup on to. >>> This is cleanup only.  I've not got the bugfixes for EFI boot yet, so >>> the behaviour you see is still expected for now. >>> >>> Although, thinking about it, it might be better if I try to merge the >>> two series, so everyone can test the end result. >>> >>> Thoughts? >>> >> +1 >> >>>>> (XEN) Xen version 4.22-unstable (tsnake41@(none)) (gcc (Alpine 15.2.0) 15.2.0) debug=y Tue Jan 27 12:06:46 CET 2026 >>>>> (XEN) Latest ChangeSet: Mon Jan 26 17:53:45 2026 +0000 git:6491616ddd >>>>> (XEN) build-id: 035024497a4cadebf9e5a2ded61f63ac >>>>> (XEN) re-enabled NX (Execute Disable) protection >>>>> (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3 (raw 000306c3) >>>>> (XEN) BSP microcode revision: 0x0000001a >>>>> (XEN) microcode: Bad data in container >>>>> (XEN) Microcode: Parse error -22 >>> As a tangent, what's going on here? >>> >>> This is the first time I've seen the error outside of my own testing. >>> Is it a container you expect to be good, or some leftovers on a test >>> machine? >>> >> I'm trying to load a Intel ucode (taken from Alpine Linux intel-ucode >> package) using `ucode=intel-ucode.img` in xen.cfg (UEFI direct boot). >> >> Many distros ship microcode in a single CPIO image with e.g >> "kernel/x86/microcode/GenuineIntel.bin" in it. > > Ah, that's a known thing that doesn't work and has never been > addressed.  People have been complaining for years, but not on xen-devel. > > It's also the subject of a documentation fix that is still pending (and > now needs yet another rebase).  > https://lore.kernel.org/xen-devel/20251215153245.2675388-1-andrew.cooper3@citrix.com > > Now that the ucode boot module handling is clean, we can probably try > both a CPIO and raw probe when given a fixed module. What does "raw probe" here mean? "ucode=" with a proper ucode blob specified has always been working for me ... (In fact I don't think I ever really tried the "scan" approach.) Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 13:03:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 13:03:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214643.1524855 (Exim 4.92) (envelope-from ) id 1vkiia-0006G5-Jb; Tue, 27 Jan 2026 13:02:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214643.1524855; Tue, 27 Jan 2026 13:02:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkiia-0006Fy-GW; Tue, 27 Jan 2026 13:02:52 +0000 Received: by outflank-mailman (input) for mailman id 1214643; Tue, 27 Jan 2026 13:02:51 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkiiZ-0006Fs-Iu for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 13:02:51 +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 78d41f68-fb80-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 14:02:46 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS4PR03MB8472.namprd03.prod.outlook.com (2603:10b6:8:323::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Tue, 27 Jan 2026 13:02:42 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9542.015; Tue, 27 Jan 2026 13:02: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: 78d41f68-fb80-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iWbV+j0UDfV7SHApG9N9S72AByS2kN/2eP4+pbGtoQsJSHHs7WxaPoOFyyJuLslxZWG7khtTNKh/sct0vChkVQRMYH1tm56mDxJUqDaPS10QdtqsDA7/NJrodpUf1+m401E3mDG9apvr53i33NRHXyaZK3wsMnP1uxRu66Nh2R7IMOOtQxcOMAqmQZoHeLETQvONhUliMOCNp/hvSoApf3UjCKj1QUHHDkPxDsCHZG5PXe2tO3rWwhUfcYyTTEnC/7EtECZvw0aTtMJkZzyAtnOANCZnLcXlkxbd6JGk2R+BqZ79IcQGcOi+HXK7drN2+ixOW7FkP+PiHkcoI7uPsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yWpRMSqMIvsQAyuJ9UfcagbI/rBnw/ywlmAexI7elOQ=; b=lwDFPt0qg/z6c/vIJihyaBUc+9YmhN3iI6tn0bClKx8Zf12joH2dNrAKYYccQwlKX6m2k0sD0QZZRh8NoSytIequ1VrMj60C+cISHhjIgpuToyhcYsFfVBLT+bVqKLaHOqCCZMH3OXM6Y5vfXogX2n0ghUSfZm9ajgw9+YTl2RU1+z7FVzBQd/2JPAZ3LA6G24MnbTbwngRLGhcRMldLMh8evty3orzEUTE8yLFNuPcPtbS+d77LfYSlETfj+QSLjOkl4oFtYXf+BfNLGd60f7OSS71lAsyQZz33ODze3AiAlrQQcOB2rJz0fu7lCEzIayXqcNqCw1qNp2ZCf50Oew== 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=yWpRMSqMIvsQAyuJ9UfcagbI/rBnw/ywlmAexI7elOQ=; b=SYSOa8UdxQHvCpKpNsIHlBhCGC0go7QsJB0G85Cbm/W/Hzu/AL4GwXlPMX+g7CqXj+GfOJkcltAZvR6suOAnb751MQuuRBn/bJWQXnxs66iUU7ddaZOebEirDSddXH6tFWlqK18o2xAd1gkwZ0B1M7dGBVHuem5gy3h1nhmwvZs= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <4e084768-1fe2-491b-a029-a07d648071c1@citrix.com> Date: Tue, 27 Jan 2026 13:02:38 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Xen-devel Subject: Re: [PATCH 00/16] x86/cpu: Cleanup for NX adjustments To: Jan Beulich , Teddy Astie References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <92bff6a4-8fb0-4992-8305-8386f480de74@vates.tech> <658c0167-c3df-4acd-92f8-8c3f022ae453@citrix.com> <08d9aeaa-d503-4e75-863b-dee3b46c42a0@citrix.com> <98758ea8-8add-4879-a28c-bd8d6d898bba@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <98758ea8-8add-4879-a28c-bd8d6d898bba@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0645.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:296::16) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS4PR03MB8472:EE_ X-MS-Office365-Filtering-Correlation-Id: ddfbec4d-1717-4692-d4f2-08de5da45b4d 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?OUhUeVZrNTNobzhJajRKTldQLzI4MVphQTNNbDc0RTVvT0tEdFp3Y0x1TXUv?= =?utf-8?B?OWJQTnFkQUxoYXNRRnk4ajdKaWJWWjF5TWVmYTdLY2NvU2VNS2VMcWVqYnVu?= =?utf-8?B?TVJuRnFpam9jcDBQVzNwNGVKbEN1YWpvdkgyYjMxMkFHYjVTSjhLc0tqSVVO?= =?utf-8?B?a3JJeGFXblhaU2gzVUZsVXBsdmxmT0V4MGphK09ETGJRc0I2WGYrT2V4SGNq?= =?utf-8?B?WkYxYmRFR0RWVE1MVXlLaVJndStLMTc1K1c2aVRWNDFxVHhiM1hxa1hxckh4?= =?utf-8?B?UENlbGRJUVVRYjdRTUJKUy8zcXowclRrMC9yTHMwbXE1bFhDRDBDSEtWcWdq?= =?utf-8?B?QWhPREJwVGV0MVZEa2g5NGNaQ285RHR5WWE4azljWTBEUVh0Z1l5VnpnZzBw?= =?utf-8?B?QWs1alZwcEx2MTR6Nm8zRmt3OGEyRjlzaWkvYnVzUWU4L21jMVluU1RaQkI2?= =?utf-8?B?ekFEZ2trcXIzbHpldDcxZFdaK2hGRS80Vm96YTVWZHZuT0NhRzhyWE4wNXZz?= =?utf-8?B?VDduZzU0WXBRR0UzUTBzSTZZU1pHakFnTHVJWWRKZ0tvSkovMzBBSm5zb1hL?= =?utf-8?B?ald2c0dVcG5vOForMXBRVzZIdGxPd2RBODdYT2F6ZC9ydnJNSlVlNVFVdWUv?= =?utf-8?B?SzNqVkNkVXdjRzRHUDROK3AwUXBIY2FFL3Rhb1pwaUVZUjYrODB1LzdIeUNj?= =?utf-8?B?eUdrTU9hRVpFVUpzSEJtcmhtS1hkTks2V1M3YUVuTVFsOVYrZVNJK1FNMktL?= =?utf-8?B?QWg5ZnBKcXpWZzJrZXFSaGFSZ05ScFdIYlhKTlJmUWdUSWFCR3ZLVXpnSGYr?= =?utf-8?B?dzBYS1FuMnVpeHRLMG9GQ0ErdElLMnZZbDZhRUYrRDFvK3I1Yjh0RjUzQVZ5?= =?utf-8?B?RnhHQUhTZVBjQWtXNzIwUUhGQVFHb2xsRnRXL2h6SDFYelFUbDdZenNkbTZn?= =?utf-8?B?a0dzcEF6b0Y4TmZjYlBnRzBwOWp5cURPOU9JOTRtOVZ1MnlMQjhRS09KemE4?= =?utf-8?B?U0VuMk16a0lkYVdxZXZLSHc3Rkx4RGQ2UVJRamsrejJPbUdiWmkzRUNBV0RP?= =?utf-8?B?R3VpU3lFSFNxNUhaMDRheVpLNTZ6MG9palQ5RnRvZHlZTGlmWmNnV0lKaEV2?= =?utf-8?B?ZWEyMlM3Y1VpcjNlNm9YbW8xYW5pV3dGUUQrSVBPYldNb0ZxdUM4UWZ1bTY5?= =?utf-8?B?bFBiL3JMTElnTG1vSFZiWWxKSlNWeGgvdUE3cm9OeVYrVE5QMjJTdCswL1hQ?= =?utf-8?B?YVRYNklKU3RoT21Tby9YR1FNOUxydWttR3o2ZERQRlBQa2N4UTVnTTBGWW1t?= =?utf-8?B?Qm5WRm15NFRFVGZvcjFVNkF5L0MvQUdLYmsrNEVlemtxTGJuV2tJRVdFanRY?= =?utf-8?B?NnRta09ydXlBQkZXWUhLYXpiR3U0RmxDek8yWVpZN3ZPVTVyZ3g4QWU1eUxO?= =?utf-8?B?UDdWTm9mRlZyUkcrdG5oMnpVblFac3RiMmMvZ3hoVTJqWkhRK1ZuYjEvZ3Nz?= =?utf-8?B?bXRXVm9Qc0pDNTV4NUV5MjB0UnFWaUFjeTJ6cmxVcWNBdHV6Y004c093bFZx?= =?utf-8?B?Wmk3UUxZMW10WlowU0J0UTRlTzJaSHBpamN1M3EyWTh1TU5CR3pZWVdWYU0x?= =?utf-8?B?NEQwbzR1MFVNeDlIeko4MDB6WHBkWFJOOHd0UkZDb0hEVzNUMDgwRVEzYytU?= =?utf-8?B?ZE9USFFIL2JoejNyYUI3M3NaeWdXSTVSVHhPdHVyd3d3bWV6MXZkZ2J5TmZi?= =?utf-8?B?UEVuOTlHbzZJekFyNkZGNEtXazFJZ0haVk5qRXAzVHRYTURwTk5ETDJJZVdG?= =?utf-8?B?cjdnMzUzNXBWelMrb0lPRXJobW1IQVV6SjBhQUsvT3RKSkxNWDE0bW52VTZF?= =?utf-8?B?VFI4QUZHbXlNK3ZsR3ZiQnQzU3Z2MndWUmpVcW1uUWdKZ05vNVB2NDd4NkxQ?= =?utf-8?B?RHlOWHBWRE8yQWZZUGU2SlJSa1ROV045Q1ZjNGo2SlR1c3hzQTlIK1NEQVh2?= =?utf-8?B?YkFZU0hCeFVRRmlLZDhlMXJGWmx3TVp0d2VnN2NVTFVQcmhNMW9yaWVXN2cz?= =?utf-8?B?WVVTMEhLVndDTVNNYm5oRnhqQlo3d2daTWxybzcvSmc3YUg3Lzg2S2JuanUr?= =?utf-8?Q?eNxo=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dVY5Wk82R0U3MVBRSzZZTjN4MkpmYXRWalUzekxFSFdCVGxMQ3NIaW54TTB6?= =?utf-8?B?aDRDR1EzMjRsbndLVjRXZElrOFBCSS8ybTRSWW8yQldUUHdVQ3N1Q0RXRDRG?= =?utf-8?B?ZjJubE9WUlA0NmNrKzg4RWsxL1d6Mk1kSVVhSEFKZ3BXS3c4UzQ5MU9tdVlt?= =?utf-8?B?UHNTVCs0ckZ4WlBZQURKZllsenRDanVZeks2bW9yYzEwUEwrLzlQaE9DQldF?= =?utf-8?B?L3NaV0lpNFdEQ2hveVhuR2NUYzhmNDNCWUl0eldnRk1QOHp2d1hRdFZ3M0Vu?= =?utf-8?B?a21OSmV3TmlVZG9MQzZmY3dYMHRhcGNibzFlWkdvM2JiaEZNS3k5ZkVvbFEy?= =?utf-8?B?SGtQeGttR0ZoKzErWkdST1hTekZITUNZUmJiN0F3UjV3WTNNQy9ySUlqVHJ4?= =?utf-8?B?cEhvOWFia1o2MEh2Y0VHbTN4ZmZ2UmpZWE0vK0RLb2J1bTJMTmxvYklDZzVL?= =?utf-8?B?U2FFQmNueE0wL25vb2Q2TXA3aVhYMEFoR0gyaXlkZlgvUUtEeXBtQmxXU3Qw?= =?utf-8?B?cUQ5ZWxkeHF6dC9HR3NKaENibVR1TGFwdng3UThCS2J1WHJpaGxxcHgvT3U0?= =?utf-8?B?bittQms1U1NVR1dISHMySURuQmUxU0tEeGdPRUwyRmYwT250WjV0OFFWUnd2?= =?utf-8?B?OE1XT1FzQ3ppNHNVMFZOR2NPUVc1NWNaaThHaWlXbWRCZFU5dFV3L1NiTERT?= =?utf-8?B?OWwxR2JzM0lab1o5QnFEL0pXcThHckV3ZEhYeXRZSnhBWkZuQ2JvMVZkSFZY?= =?utf-8?B?SmJJNVVwZXFPc3hrMGpuYUdvNkVNeExKYVB3V0JoYzdmaGo0SUgvZWRxc29Z?= =?utf-8?B?aWg4YzRWWUV6WUhWN0huMFQvbWVkdFlUMUNoSnpJdm5kVi9TSGx1NFY4RHQ5?= =?utf-8?B?b3Y2SXJLYmx4a3R1M0JUclpVN3VjZmdLMStoZDJOVWF0eGVmVkwxR2xqUHZM?= =?utf-8?B?Y2lFVGpIRW5aSlZNQitzdGswZTVUdG5RVHVoaSttcHFvdjlwcWlRc3BoZVAz?= =?utf-8?B?T1loeUhHbGxyNFludEF5SlQ3S1ZoV3hjMzIyb29sRGQ5ei9sVUdwM0lmZC9z?= =?utf-8?B?c2NKN1Fpa21vaFNKL0dvM2d3YSsyNFBSTFFQMGFpTUZDNmN2UzVvMEVJRG1s?= =?utf-8?B?Z3Q1RzZFS3BvRDJXcDNMazB4bkh4YkdxYUVPT3U0R3NDRER4Y0pkR3FCOXNK?= =?utf-8?B?UDB4cDdGQUxGK1pDcHFLOFhBejB1aXAzS0lYZ2FISHdUTk1KUFZ4WlZ3MldD?= =?utf-8?B?TjlYTjBCcWtlbS9xakN5QW1FbytsZmRzV0VDUFcyOFp6bjZ2VFl3UWNxMjIr?= =?utf-8?B?cXVZUXZyZzF0azYzdHgvZlNmbFpIR3Y1dVNDamkzODJVaGRuYTFkUlp3U0ZE?= =?utf-8?B?UVBPT25NcWRxbFVtU1hGK25EMmNkZTVyWHFvTGN5bFdxUWdPSFBOdzQ2eGN0?= =?utf-8?B?Z3JSdW9SQm1YMmM2RFYwaS9ybGJwby9CT3dQTzdMekFkQjVwbW9ON2N2eFY1?= =?utf-8?B?eWtBZ0V4SnFEajk0dFo0T3hmTC9RbE1lM3RxdG84d29PcUxaUFIxK0NFTDdK?= =?utf-8?B?U3k3UTUvSFVCZnRjaE5yWFl4TTNWZTdPcGJSZ1VWT0FCVEltbDRTVVZadHhX?= =?utf-8?B?NDkrcGdvS3J2bnFZSjl3cm1WWWRDQUh4UHBpSGdoWDlST1l6a1dBblpBK3FC?= =?utf-8?B?T0U5TWJzMk5aZWU2Uk9qRUcwZGR4Ni9VL2hxUisydG5rUzF1UVFmYzFoZEdD?= =?utf-8?B?NVhwUkR4V0JHSDBEQ2pMbGdHeEJzaGFXSTJxejB5c1owaHJsb0pwM0x0VDkv?= =?utf-8?B?L3oyQ1o4N3pSVE1icWtNUUR6SWpvYkVYemwveXkwaEdrNzJZMkJ6T1JtSkhm?= =?utf-8?B?MU1Na08xSFU0a0tTNGczSVZrbHJFaFdKYXV2UUQrdDNkQ09JV0pGOTFTSHRh?= =?utf-8?B?UHppSHRtVjZXWUlWM1hjd2IxdkxPVDNiQ2Q0dXp6bHRDTHBUaGpySEFUVlNF?= =?utf-8?B?c0tTdFVsMFVkUkl5eGdzdG4yVnpvcEg4V0RQR0tPWXBidmwvYkdVcWExakc0?= =?utf-8?B?NEFZWnp2QSsxUkF2Tmpuc0ZraFhSUEJCY3BIV3hVZWIwRWQ3MnN1MEVaZTM2?= =?utf-8?B?dythZ0FySW00REZJSmlxKzlEMHR6ejUwek8rQ0ZtSnhaR3NzNTB1RXZnS0dw?= =?utf-8?B?Rkl1aHdlRmNTQXNldUJIRkRTOWJuS3N1L3JML2F4RWFFc3h4U0IzS2VMR2Ny?= =?utf-8?B?d1VQQ3NaaHNucXY0RDBHK3RyRldvVXBEOHhvbjM3UHhyelpXa2pHc3E1cTdq?= =?utf-8?B?SG5sd0c5bDNUQk4vKzdDR3g2V2ducFRRVjFLS0JPeExkM0lMQmVWQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ddfbec4d-1717-4692-d4f2-08de5da45b4d X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 13:02:42.1730 (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: 4I/pruGbDu1CLc+dZOvnAbBePLsBmk4bZMt3zAkBshwQLrcSCr8/AikpXsG9LdkHbyB8s/P5QaSeQ4UdFFNPAM4jpPZ+K3zx/kM9lzpjtEE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR03MB8472 On 27/01/2026 12:54 pm, Jan Beulich wrote: > On 27.01.2026 13:29, Andrew Cooper wrote: >> On 27/01/2026 12:09 pm, Teddy Astie wrote: >>> Le 27/01/2026 à 12:39, Andrew Cooper a écrit : >>>> On 27/01/2026 11:23 am, Teddy Astie wrote: >>>>> Le 26/01/2026 à 18:56, Andrew Cooper a écrit : >>>>>> I was hoping this to be a patch or two, but it got out of hand... >>>>>> >>>>>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2287078891 >>>>>> https://gitlab.com/xen-project/hardware/xen-staging/-/commits/andrew/nx >>>>>> >>>>>> The branch has one extra patch to fake up the firmware settings being set to >>>>>> Gitlab CI, not included in this series. >>>>>> >>>>>> Julien: This ought to suitable to rebase your cleanup on to. In the end, I >>>>>> did the AMD adjustment mostly because I needed it to test the correctness of >>>>>> the prior cleanup. >>>>>> >>>>>> The final 4 patches are tangential cleanup which I've kept out of the prior >>>>>> work in case we wish to backport it. Everything prior is relevant to >>>>>> untangling, and mostly for the benefit of the AMD side. >>>>>> >>>>>> The early patches are hopefully non-controvertial. Later patches are a little >>>>>> more RFC, and in need of further testing. >>>>>> >>>>>> >>>>>> >>>>> Tested on a Intel machine with "DEP" disabled, and "Require NX support" >>>>> disabled, I get a pagefault in hpet code >>>> From above: >>>> >>>>> Julien: This ought to suitable to rebase your cleanup on to. >>>> This is cleanup only.  I've not got the bugfixes for EFI boot yet, so >>>> the behaviour you see is still expected for now. >>>> >>>> Although, thinking about it, it might be better if I try to merge the >>>> two series, so everyone can test the end result. >>>> >>>> Thoughts? >>>> >>> +1 >>> >>>>>> (XEN) Xen version 4.22-unstable (tsnake41@(none)) (gcc (Alpine 15.2.0) 15.2.0) debug=y Tue Jan 27 12:06:46 CET 2026 >>>>>> (XEN) Latest ChangeSet: Mon Jan 26 17:53:45 2026 +0000 git:6491616ddd >>>>>> (XEN) build-id: 035024497a4cadebf9e5a2ded61f63ac >>>>>> (XEN) re-enabled NX (Execute Disable) protection >>>>>> (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3 (raw 000306c3) >>>>>> (XEN) BSP microcode revision: 0x0000001a >>>>>> (XEN) microcode: Bad data in container >>>>>> (XEN) Microcode: Parse error -22 >>>> As a tangent, what's going on here? >>>> >>>> This is the first time I've seen the error outside of my own testing. >>>> Is it a container you expect to be good, or some leftovers on a test >>>> machine? >>>> >>> I'm trying to load a Intel ucode (taken from Alpine Linux intel-ucode >>> package) using `ucode=intel-ucode.img` in xen.cfg (UEFI direct boot). >>> >>> Many distros ship microcode in a single CPIO image with e.g >>> "kernel/x86/microcode/GenuineIntel.bin" in it. >> Ah, that's a known thing that doesn't work and has never been >> addressed.  People have been complaining for years, but not on xen-devel. >> >> It's also the subject of a documentation fix that is still pending (and >> now needs yet another rebase).  >> https://lore.kernel.org/xen-devel/20251215153245.2675388-1-andrew.cooper3@citrix.com >> >> Now that the ucode boot module handling is clean, we can probably try >> both a CPIO and raw probe when given a fixed module. > What does "raw probe" here mean? "ucode=" with a proper ucode blob specified > has always been working for me ... (In fact I don't think I ever really tried > the "scan" approach.) This isn't (really) about scan. What both Arch (where I noticed this complaint first) and Alpine do is pass: ucode=CPIO(GenuineIntel.bin, AuthenticAMD.bin) as would otherwise be prepended to the initrd, and Xen rejects this because it's not a valid vendor blob. What I'm thinking of is something like this: diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c index 9e055b6f9805..82ddb5e9a6d2 100644 --- a/xen/arch/x86/cpu/microcode/core.c +++ b/xen/arch/x86/cpu/microcode/core.c @@ -847,6 +847,11 @@ static int __init early_microcode_load(struct boot_info *bi)                     idx, size);              return -ENODEV;          } + +        if ( is_cpio(data) && +             find_cpio_data(ucode_ops.cpio_path, data, size) ) +            ...; +          goto found;      }   where we'd accept both raw and CPIO-wrapped blobs any time we nominate an explicit module (whether via Grub, or implicitly via EFI). ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 27 13:14:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 13:14:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214664.1524886 (Exim 4.92) (envelope-from ) id 1vkiu2-0008LH-02; Tue, 27 Jan 2026 13:14:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214664.1524886; Tue, 27 Jan 2026 13:14: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 1vkiu1-0008LA-RE; Tue, 27 Jan 2026 13:14:41 +0000 Received: by outflank-mailman (input) for mailman id 1214664; Tue, 27 Jan 2026 13:14: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 1vkiu0-0008L1-7Z for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 13:14:40 +0000 Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [2a00:1450:4864:20::432]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2231d552-fb82-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 14:14:38 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-4327790c4e9so3665862f8f.2 for ; Tue, 27 Jan 2026 05:14:38 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1e7156dsm38662355f8f.20.2026.01.27.05.14.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 05:14:37 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2231d552-fb82-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769519678; x=1770124478; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=xDAArseA7Vjx9JvMf1vXBGecAWo4qLCwFtM/BqRgQkc=; b=IKYR/CBjQMPuAoLLZJVyz+rskbPm6sY0+eIvLyfW+XiA4OCA9JpFhw1+m9w1+2FOwp urvr4reCtWzfCCOQwcujb+cxLxgNUlMtykSlFbOp5jvDoJ1XTYipfHNGYxAbb0KOgfSt RF8GY/FGuaR8j5yQgCul6Ed+5+3xC4VKnwnea2oLR9hl94uLGZFGRJ6V0Lp6KWUSzk3Y swVCCorJ6BBmx642MvNkjswsBjJwMYsDCTRdMPTy23kIZNkfPitMmXKab3zdDvWLeIa+ l0vXFe7mx0QwCDaXRa+dwtSAvU3kj7u7ZwglbJNzkjyLYrYG0e5xa7qqy5c87PsIPJXJ CxtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769519678; x=1770124478; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xDAArseA7Vjx9JvMf1vXBGecAWo4qLCwFtM/BqRgQkc=; b=vfGnJshozQ+y3p0eVv/o8f8OjUGpSSSk/jpYincqOzsf9oWNLTuI3PoNGHUZ8fY9Ep xSRb8PsEFDVOZzHb/acM7JiuMdDt5fzxbRywEz8N2DWi6vssqYehZeRn+yjZ+M/0h1sW 2vKs5LOLBnpAbdRG0cHfmcYzemjRyTTM/01fJ2JMUUIpadrwPs8M+zdXu/crVA6ke2B3 0taYGKkU/zGOLKVKu7clgDbbIWfOZuUVhpm2mo2vhUP5DlupCeto6PXkYfnQIEzhJrmP D+Cf1ZknelrujUULUwkUFv0IlykViolTJLefXN++t+WpGYV1KsAbve1bgj9+p9Wp1Sgz f+RA== X-Forwarded-Encrypted: i=1; AJvYcCVKQ23o5PAmNyOxbyGTRKRAXuQkIo5Df+0MUMY1IYpfi7ya/pCssFcb+oNJ+IotqkSUcxnJB0CNqlU=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx+8vhbVdTRC6ZeKXX70UICZKiJJOCf+vnAZVIvkXdPGQZFiLUu SfE8ZI8GpHt/vBZEbsoKACW+EDGxfaVYUNWx5+lJ8uxWWCkxDzVsWWNF4MN9UMQEPg== X-Gm-Gg: AZuq6aJoJ38Tv5insZcq0BHftS7jzYTXR5xjFHiELTMkU7FML2X8geX9XZDCmpW9/FU 6qO/b69PRcVdnAqOO80oedNcSXLm9F/riXPZu1YyVeylRMuXZBxNX1qC21teWlG47Oo593wR632 iZf896bdMKRmJsakE8OYvkESGLbNmiQaaeZtBH97N7o2z1RUGYA9Ix6TMrZQ2UEuNyG/Gw9VncG K1L2Ycz/6mlbFzzoyfwkFuH2xS7rYH91EZIz2jL9nexXGKY57xkgZf5h3bqVRavHMR+bntGqX5F nOfqiJJLRXJLeNpgXHG9OrlqMP9uoNJ2QHdyrzO5XdwMmBLFUsVM6nOGlpKYLJMCcoe6+YvCjMc iilvzSU93MLaPnYsLPBl4myOwkFNx/73BqVnXM2lrI04CZSRsG+PC5byLrCHqKq6b6peU/74jJB Ta+kgVVta2qDMD+0y9kd4o0qB5JjO/XyDVd5HHOiA8CyHGgCi3ths99HxOmdbNqiE4tQcPfmHjr D4= X-Received: by 2002:a05:6000:2404:b0:435:9653:e154 with SMTP id ffacd0b85a97d-435dd074b2bmr2571803f8f.27.1769519678044; Tue, 27 Jan 2026 05:14:38 -0800 (PST) Message-ID: <668a0e95-733c-49ef-8e59-bdfc94ddc5e0@suse.com> Date: Tue, 27 Jan 2026 14:14:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 00/16] x86/cpu: Cleanup for NX adjustments To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Xen-devel , Teddy Astie References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <92bff6a4-8fb0-4992-8305-8386f480de74@vates.tech> <658c0167-c3df-4acd-92f8-8c3f022ae453@citrix.com> <08d9aeaa-d503-4e75-863b-dee3b46c42a0@citrix.com> <98758ea8-8add-4879-a28c-bd8d6d898bba@suse.com> <4e084768-1fe2-491b-a029-a07d648071c1@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: <4e084768-1fe2-491b-a029-a07d648071c1@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 27.01.2026 14:02, Andrew Cooper wrote: > On 27/01/2026 12:54 pm, Jan Beulich wrote: >> On 27.01.2026 13:29, Andrew Cooper wrote: >>> On 27/01/2026 12:09 pm, Teddy Astie wrote: >>>> Le 27/01/2026 à 12:39, Andrew Cooper a écrit : >>>>> On 27/01/2026 11:23 am, Teddy Astie wrote: >>>>>> Le 26/01/2026 à 18:56, Andrew Cooper a écrit : >>>>>>> I was hoping this to be a patch or two, but it got out of hand... >>>>>>> >>>>>>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2287078891 >>>>>>> https://gitlab.com/xen-project/hardware/xen-staging/-/commits/andrew/nx >>>>>>> >>>>>>> The branch has one extra patch to fake up the firmware settings being set to >>>>>>> Gitlab CI, not included in this series. >>>>>>> >>>>>>> Julien: This ought to suitable to rebase your cleanup on to. In the end, I >>>>>>> did the AMD adjustment mostly because I needed it to test the correctness of >>>>>>> the prior cleanup. >>>>>>> >>>>>>> The final 4 patches are tangential cleanup which I've kept out of the prior >>>>>>> work in case we wish to backport it. Everything prior is relevant to >>>>>>> untangling, and mostly for the benefit of the AMD side. >>>>>>> >>>>>>> The early patches are hopefully non-controvertial. Later patches are a little >>>>>>> more RFC, and in need of further testing. >>>>>>> >>>>>>> >>>>>>> >>>>>> Tested on a Intel machine with "DEP" disabled, and "Require NX support" >>>>>> disabled, I get a pagefault in hpet code >>>>> From above: >>>>> >>>>>> Julien: This ought to suitable to rebase your cleanup on to. >>>>> This is cleanup only.  I've not got the bugfixes for EFI boot yet, so >>>>> the behaviour you see is still expected for now. >>>>> >>>>> Although, thinking about it, it might be better if I try to merge the >>>>> two series, so everyone can test the end result. >>>>> >>>>> Thoughts? >>>>> >>>> +1 >>>> >>>>>>> (XEN) Xen version 4.22-unstable (tsnake41@(none)) (gcc (Alpine 15.2.0) 15.2.0) debug=y Tue Jan 27 12:06:46 CET 2026 >>>>>>> (XEN) Latest ChangeSet: Mon Jan 26 17:53:45 2026 +0000 git:6491616ddd >>>>>>> (XEN) build-id: 035024497a4cadebf9e5a2ded61f63ac >>>>>>> (XEN) re-enabled NX (Execute Disable) protection >>>>>>> (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3 (raw 000306c3) >>>>>>> (XEN) BSP microcode revision: 0x0000001a >>>>>>> (XEN) microcode: Bad data in container >>>>>>> (XEN) Microcode: Parse error -22 >>>>> As a tangent, what's going on here? >>>>> >>>>> This is the first time I've seen the error outside of my own testing. >>>>> Is it a container you expect to be good, or some leftovers on a test >>>>> machine? >>>>> >>>> I'm trying to load a Intel ucode (taken from Alpine Linux intel-ucode >>>> package) using `ucode=intel-ucode.img` in xen.cfg (UEFI direct boot). >>>> >>>> Many distros ship microcode in a single CPIO image with e.g >>>> "kernel/x86/microcode/GenuineIntel.bin" in it. >>> Ah, that's a known thing that doesn't work and has never been >>> addressed.  People have been complaining for years, but not on xen-devel. >>> >>> It's also the subject of a documentation fix that is still pending (and >>> now needs yet another rebase).  >>> https://lore.kernel.org/xen-devel/20251215153245.2675388-1-andrew.cooper3@citrix.com >>> >>> Now that the ucode boot module handling is clean, we can probably try >>> both a CPIO and raw probe when given a fixed module. >> What does "raw probe" here mean? "ucode=" with a proper ucode blob specified >> has always been working for me ... (In fact I don't think I ever really tried >> the "scan" approach.) > > This isn't (really) about scan. > > What both Arch (where I noticed this complaint first) and Alpine do is pass: > > ucode=CPIO(GenuineIntel.bin, AuthenticAMD.bin) > > as would otherwise be prepended to the initrd, and Xen rejects this > because it's not a valid vendor blob. > > What I'm thinking of is something like this: > > diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c > index 9e055b6f9805..82ddb5e9a6d2 100644 > --- a/xen/arch/x86/cpu/microcode/core.c > +++ b/xen/arch/x86/cpu/microcode/core.c > @@ -847,6 +847,11 @@ static int __init early_microcode_load(struct boot_info *bi) >                     idx, size); >              return -ENODEV; >          } > + > +        if ( is_cpio(data) && > +             find_cpio_data(ucode_ops.cpio_path, data, size) ) > +            ...; > + >          goto found; >      } > >   > > where we'd accept both raw and CPIO-wrapped blobs any time we nominate > an explicit module (whether via Grub, or implicitly via EFI). Ah, I see. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 13:20:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 13:20:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214678.1524896 (Exim 4.92) (envelope-from ) id 1vkizA-0000dZ-Lc; Tue, 27 Jan 2026 13:20:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214678.1524896; Tue, 27 Jan 2026 13: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 1vkizA-0000dS-Hh; Tue, 27 Jan 2026 13:20:00 +0000 Received: by outflank-mailman (input) for mailman id 1214678; Tue, 27 Jan 2026 13:19:59 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkiz9-0000dF-AC for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 13:19: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 df3737a4-fb82-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 14:19:56 +0100 (CET) Received: from BL1P223CA0027.NAMP223.PROD.OUTLOOK.COM (2603:10b6:208:2c4::32) by BN5PR12MB9538.namprd12.prod.outlook.com (2603:10b6:408:2ac::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Tue, 27 Jan 2026 13:19:51 +0000 Received: from BL6PEPF0001AB51.namprd04.prod.outlook.com (2603:10b6:208:2c4:cafe::57) by BL1P223CA0027.outlook.office365.com (2603:10b6:208:2c4::32) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.7 via Frontend Transport; Tue, 27 Jan 2026 13:19:50 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF0001AB51.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.9564.3 via Frontend Transport; Tue, 27 Jan 2026 13:19:49 +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, 27 Jan 2026 07:19:49 -0600 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; Tue, 27 Jan 2026 07:19:48 -0600 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, 27 Jan 2026 05:19:47 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: df3737a4-fb82-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=h/dcQR3xPNl2SQnY9cZtwcW8R6adoujrN2r2Xwa7CGL7s3f2qnULS9mEQXMSXMgvB30ytULevJVoHOdMNIyp7AMc91QEJrVCKogGE9FsyU2cgeILnmlgNrM/uIZCl15HfvamNIMU0W7NKV1gviEwX1uImZft5JktxiG6gZk+MOACe0D7dnQf68sE22BhUe2jg6v2/XQgBwzygYsgNuEf6rSF2gwPtGnPzrlKMqpcYBTF5FuKcR5aH0ypVct09jQ5D6NsZF9w0LOAkjdQbXGSGQufGwqabqxcMrtnxvlktpkeotd2bJN/DwUN/38aEU1EjaRXL2rrVJvm68U95lGSIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qaIsxxWRLcvfB20XUOxZMeT9cZZ9OS8RfHLzK351v44=; b=IwjOO92dT0svT1548kWoBuE1/bk6ynlZFMmsxEzQYE4n/YLemISGTIjwjj9rcnYOA9Z7LbaeMZk/OA282NsWNkX3O/mnn1jw2H/F04QgIcgyeB+reRv3LENnDK//afboZAAeqASO7Fyy9DKeeAsoxFSraXIgIr3TUngZa3IIYRY9/EDznFd7cUlNhtnG20Rfi009wU4Cy1rwtU9GxVrfN2AVcJ5TGFosquv/twCODuawSt5oy6xwN3NASl4WgwFDKmbWuQtYfk19AjfwePyF3BczrlKf95JFx9E9KpfCdBmwKkEqxJRWFfESlL/z5vXkB3KWyV8be5Ahyfg7nQktYA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qaIsxxWRLcvfB20XUOxZMeT9cZZ9OS8RfHLzK351v44=; b=bAtIC+BPQRHtwS4wdlqoPH/BVfJ4s/+fXMbHnMg1SbH+TN7wVA6j0+OVo9gvd/uL+X4v0xpuh0Du6CMwinxAs9K9YUEjrd/TLxghnc5zG2oqJMzslz1maHDOdwhmdKr7TbACQcw5VoukWELAzyeVhful8nODMXZD/qXe94h0OJo= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C From: Michal Orzel To: CC: Michal Orzel , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Jan Beulich Subject: [PATCH] xen/arm: Kconfig: Fix XEN_START_ADDRESS input prompt Date: Tue, 27 Jan 2026 14:19:22 +0100 Message-ID: <20260127131923.123294-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 (SATLEXMB04.amd.com: michal.orzel@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB51:EE_|BN5PR12MB9538:EE_ X-MS-Office365-Filtering-Correlation-Id: 12317d5c-b6df-4554-fa54-08de5da6bfb7 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?Igbo4Z4/TwxJamaiwfspGIN7r/POjUU9rAfO8JOpl8ApbDzY/bp57Hn8ThMX?= =?us-ascii?Q?KVijG08Mb8SmyDcujqJzXWmROSD2qzluM7C8WsQ8kvbvfGGt9HKbVgnlDUUO?= =?us-ascii?Q?gMw309ZVuVd4r4dk4rjJs+6u3uec1v1gW8kxOsjvGeu9TTES3tvRGrHTUdrQ?= =?us-ascii?Q?+HCRFeKU/3jRMeqg4hIZV/Dhfgchzar/ZAYUIeTzhFIHAYZJKYOtPlFM5Gc/?= =?us-ascii?Q?Cz5VI7OfG05wJLdr/1dRPE7BCOFnNat6lMptmIvfFnN54LiW79cJ1/CB2Gxc?= =?us-ascii?Q?OGwXQM3u/qDidig2RxtqvX6lb6tZFQcWrFyCNppqgB3HAu7KDF68/c2UfwpJ?= =?us-ascii?Q?PA3u2us+qXJTAP4VNRlMyjxndpkpU0bKst/A5ehfTSzyY2+lkpGvowAF/6EM?= =?us-ascii?Q?0Qx98AWlvYLYyeYdIIORJybIobirC9NGQBt5QztY0GhyJi4c83e7BOttdqtu?= =?us-ascii?Q?zlnNkM3E9fqWMueCQuGy+TXBy775sYXE4J6JRryc+BSeY9o/lpT9OEYYvBRr?= =?us-ascii?Q?hmwzZZ6sQtJiyjhaRirVWBfFEGkFcUymFkziwKteltRst8it6XxUfT89tmIy?= =?us-ascii?Q?MzE1Pr5hz55WGLZejU8l5ckS4/duo3GDZpwRQFeuJiR9yxxAE0iSpyRJCLqg?= =?us-ascii?Q?uJRrXyp8NRPmDOFT37fxCiTlpdag1kYhH+TkjGgRTIhWT4EtAdmG8y0j/TDB?= =?us-ascii?Q?XSeNKdIvC2yeSXRks6ddhWMEh6uj1KzH32tS4mn9nUCx/8Wm29WHNUWOvlcd?= =?us-ascii?Q?D4B1roAfHwugaGDhlJhrFbdnmB5fLk59kUvKoVc0Myci0D7OZxHZ+lwGIb9A?= =?us-ascii?Q?2VFjOO6GC+fFcfRvBTgJdhJ2dg+tQGhgpvLEsEOcRKxbSX6q8gsV4ZmCepK7?= =?us-ascii?Q?wVmjcMKU/1GrOM4BSIi++YDdnto3aZdKa34RkRztEsiBVUrLuapJCrp7MCCY?= =?us-ascii?Q?AGyTQVwiVjeHcNUR0lF+MLm/B7mKZ/epIxyDhzP7LJK/YnQyf593HHOrNBsO?= =?us-ascii?Q?5j+Y0DnNu4cl+ZQNliTuvqVshWZaIJg4+7wPt90qXHns7ldNC5eYIn1fip5/?= =?us-ascii?Q?4TyOC9G29Y0B+VtcvKDLO3ZEo5jpVXBiwIRDn8eZz4k8ubQrPm5Upku4bFHq?= =?us-ascii?Q?FtlteskNmDCDmzkmDGpH+eZxjYqpD/MnbAm/M6AXXy1w6qEUf1490imDdoaG?= =?us-ascii?Q?WyW/5ZgQ8kcS8ddfH0mDvvHJoMRNe1ODR7o3/EJzfJxWGK14seg0vQXVMoEt?= =?us-ascii?Q?+JnQCeoh064pr2j8EvhvuZ7JYLEVwHdynS1nTi4/4dywS14txdBH3Wk67XJX?= =?us-ascii?Q?MqXfKzltGB3iXaDNMaSqb6Qj/mJ5wXg6tsfHHnINGbUujx3V0nYuFO3wH9xp?= =?us-ascii?Q?1y5eXXaKPg0HoIos8CHCjtSR0BycvlSX2wYpaxjiOg5Y0zf/mCtJOojeUGy4?= =?us-ascii?Q?aMFedGNVBABEZueZ7SAHpd0BhpiqHTZpSGfIuEsHxmI8u5GK8ZqIqzZ3qK7N?= =?us-ascii?Q?sL9o6XKQlQWcDLOjNwLOy+SjRXfhGBV1qJ40iuw382SbvZ2GjaqeUGYojlhf?= =?us-ascii?Q?JGPylcJqv6rrPXXdiiQ4QcJ0Z35uL9LMKIZa7t4npldLpPntdlN2lJIbGYaU?= =?us-ascii?Q?emLnx2AevDUK7BIdASRzWIrLRPmU8hkqLmCzApfIF3k1w5iFrM/NPdkli1Sm?= =?us-ascii?Q?MMqndg=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 13:19:49.5201 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 12317d5c-b6df-4554-fa54-08de5da6bfb7 X-MS-Exchange-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: BL6PEPF0001AB51.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN5PR12MB9538 Remove the part about platform defined address which is not true. The help text is correct i.e. 0xFFFFFFFF is used as default value to indicate that user has not customized this address. Amends: d736b6eb451b ("xen/arm: mpu: Define Xen start address for MPU systems") Reported-by: Jan Beulich Signed-off-by: Michal Orzel --- xen/arch/arm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 442d353b4343..2f2b501fdac4 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -28,7 +28,7 @@ config ARCH_DEFCONFIG default "arch/arm/configs/arm64_defconfig" if ARM_64 config XEN_START_ADDRESS - hex "Xen start address: keep default to use platform defined address" + hex "Xen start address" default 0xFFFFFFFF depends on MPU help -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 27 13:21:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 13:21:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214691.1524905 (Exim 4.92) (envelope-from ) id 1vkj0C-00026A-1h; Tue, 27 Jan 2026 13:21:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214691.1524905; Tue, 27 Jan 2026 13:21:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkj0B-000263-UC; Tue, 27 Jan 2026 13:21:03 +0000 Received: by outflank-mailman (input) for mailman id 1214691; Tue, 27 Jan 2026 13:21:03 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkj0B-0001py-Aw for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 13:21:03 +0000 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [2a00:1450:4864:20::32d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 06bffb54-fb83-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 14:21:02 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-47fedb7c68dso57718935e9.2 for ; Tue, 27 Jan 2026 05:21:02 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066bf7ae8sm60785035e9.7.2026.01.27.05.21.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 05:21:01 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 06bffb54-fb83-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769520062; x=1770124862; 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=yjFGeKp1K4ttCYF68p8JwAWjBOoW26y1e6tNrvP69Hs=; b=UEvMFkW4jXIDAEIUK25u+5l7LSY8/y4GVTfgvQqvsbJh9CqhrpJ/WGfkUT03cEQXPC dwn38LXEdBBVL4QMYPBsbD2/mtL0P+uN2W8Gya6pvSJj9ZqTs03a6o1tp04jB1MgoZvh e7V8h9H/qMNY4BgKGjBP49+4V3ggZ4Qo76h+wW8VqrP2idMi5J0YKnb+sq7rjkrDmAOI rSGrQ5w8E53UlKaTznw2WLBVuYPaiiYl73pZvJgXJy1CyqrnK1Jz8eyPqX5BU/ELYkqk 4rjNOjuEXB/tQVPnB2M23GBgO55b6RfuhIAMCwzzNgcearzz+mKF7glxyVaHsli340NI Odpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769520062; x=1770124862; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yjFGeKp1K4ttCYF68p8JwAWjBOoW26y1e6tNrvP69Hs=; b=jNI4UPSNdY/92EAWrw7gPMQGIM9ZVTrmY/TfRmjgxw/BynOp32DEzYbBWe/fgKv0n+ odhAEAjj7dbknCwhjQq8AQirOAz644YCidh9hvB3+4TGzME6M4s3wJ31jndiImk2lCjF tqKqg8tixBy4Z8OWa8YQxbeOpgYXjD2vtFNSekcL30GnKJXTkov+JixNW8IjVqxn+eLt flmvxANrNx7U08RIj8gXjBQviFobUMIkEYEhU78mf3jLURFfYAfadfI0gEh4DlMqdkRI LNnOYRRQ+DdCgm85D0uHgChbi5RUnwHUS6+qZZ+P9p1I6K5PJTR2ih0mC1CYc0NjOjFC 9sXQ== X-Gm-Message-State: AOJu0YzKNBCJz6WTlQpIwmUxaYVIORLj6BIcti7Bu9p808M1rV2Yk0Df hY3whwUWFcF7nvuCqhT22Fl6R5RQQcP8dUpJNfAupxjkIg8p4lBT8x2Bk6y7upDCUHihtBWTutE XFWQ= X-Gm-Gg: AZuq6aL+JsvrLSF6iujqqTwzm/jfMxT3lGCebNkbYOSWE3WENKYj52WQoRpBFXc8VZj WI3oPVLRCx/IEVEkRcttFEeCeDv1lCPjpKZJBRBTpPf6lB97M6cCVLoorRxf79zCR8HNravaEr1 vvDvF4jEZVXlAyzreV8+LdtC2JHYyj0USelM36k+EjOaa+M0O244h+/zkvMM5CBqH6J6dOU8YrQ jK2o9eMSm3NWlDGL2zzAeqdrAEo5FyWrsJwc9oUocz+puJxFSjC1J6yyArV19ukAotzREi9aF9N vzi07weNJ8lN2fvwCq38zRmc1SmrJMQcKiDqs0yQJAalT8qrwX/Nx/1X417yGHKiVAvv6hSJM2N 3GJlusabczzeOfB9OlM6HtJv1K1QxTEtoqMXNr7hq7+JKSHR6ueAgQNT7KxBVHtFtMW2879BWH3 8mpdFxyFBY2Jir7j3re1Qj20K4uJKHPS6m05kCuIXhdmOJsp4T8XFDk8apohtWPnm6K1PGb9vYm Ck= X-Received: by 2002:a05:600c:4f82:b0:480:4d39:84b3 with SMTP id 5b1f17b1804b1-48069bfabe7mr23329285e9.6.1769520061553; Tue, 27 Jan 2026 05:21:01 -0800 (PST) Message-ID: <7982a813-0fda-447e-a0f1-c9357b85f264@suse.com> Date: Tue, 27 Jan 2026 14:20:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= From: Jan Beulich Subject: [PATCH] x86/shadow: suppress trace_emul_write_val hook when !TRACEBUFFER Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit The hook is never invoked in that case, and hence needlessly offers an extra valid indirect call target. With the hook suppressed, no consumer of the three local per-CPU variables exists either, so they're suppressed as well. Signed-off-by: Jan Beulich --- a/xen/arch/x86/include/asm/paging.h +++ b/xen/arch/x86/include/asm/paging.h @@ -90,10 +90,12 @@ struct shadow_paging_mode { int (*guess_wrmap )(struct vcpu *v, unsigned long vaddr, mfn_t gmfn); void (*pagetable_dying )(paddr_t gpa); +#ifdef CONFIG_TRACEBUFFER void (*trace_emul_write_val )(const void *ptr, unsigned long vaddr, const void *src, unsigned int bytes); #endif #endif +#endif /* For outsiders to tell what mode we're in */ unsigned int shadow_levels; }; --- a/xen/arch/x86/mm/shadow/hvm.c +++ b/xen/arch/x86/mm/shadow/hvm.c @@ -211,9 +211,11 @@ hvm_emulate_write(enum x86_segment seg, default: memcpy(ptr, p_data, bytes); break; } +#ifdef CONFIG_TRACEBUFFER if ( tb_init_done ) v->arch.paging.mode->shadow.trace_emul_write_val(ptr, addr, p_data, bytes); +#endif sh_emulate_unmap_dest(v, ptr, bytes, sh_ctxt); shadow_audit_tables(v); --- a/xen/arch/x86/mm/shadow/multi.c +++ b/xen/arch/x86/mm/shadow/multi.c @@ -2044,6 +2044,7 @@ static void __maybe_unused sh_trace_gfn_ } #ifdef CONFIG_HVM +#ifdef CONFIG_TRACEBUFFER #if GUEST_PAGING_LEVELS == 3 static DEFINE_PER_CPU(guest_va_t,trace_emulate_initial_va); static DEFINE_PER_CPU(int,trace_extra_emulation_count); @@ -2071,9 +2072,11 @@ static void cf_check trace_emulate_write memcpy(&this_cpu(trace_emulate_write_val), src, bytes); #endif } +#endif /* CONFIG_TRACEBUFFER */ static inline void sh_trace_emulate(guest_l1e_t gl1e, unsigned long va) { +#ifdef CONFIG_TRACEBUFFER if ( tb_init_done ) { struct __packed { @@ -2099,6 +2102,7 @@ static inline void sh_trace_emulate(gues sh_trace(TRC_SHADOW_EMULATE, sizeof(d), &d); } +#endif /* CONFIG_TRACEBUFFER */ } #endif /* CONFIG_HVM */ @@ -2678,7 +2682,9 @@ static int cf_check sh_page_fault( paging_unlock(d); put_gfn(d, gfn_x(gfn)); +#ifdef CONFIG_TRACEBUFFER this_cpu(trace_emulate_write_val) = (guest_l1e_t){}; +#endif #if SHADOW_OPTIMIZATIONS & SHOPT_FAST_EMULATION early_emulation: @@ -2794,7 +2800,10 @@ static int cf_check sh_page_fault( if ( r == X86EMUL_OKAY && !emul_ctxt.ctxt.retire.raw ) { int i, emulation_count=0; + +#ifdef CONFIG_TRACEBUFFER this_cpu(trace_emulate_initial_va) = va; +#endif for ( i = 0 ; i < 4 ; i++ ) { @@ -2830,7 +2839,10 @@ static int cf_check sh_page_fault( break; /* Don't emulate again if we failed! */ } } + +#ifdef CONFIG_TRACEBUFFER this_cpu(trace_extra_emulation_count)=emulation_count; +#endif } #endif /* PAE guest */ @@ -4130,7 +4142,9 @@ const struct paging_mode sh_paging_mode .shadow.guess_wrmap = sh_guess_wrmap, #endif .shadow.pagetable_dying = sh_pagetable_dying, +#ifdef CONFIG_TRACEBUFFER .shadow.trace_emul_write_val = trace_emulate_write_val, +#endif #endif /* CONFIG_HVM */ .shadow.shadow_levels = SHADOW_PAGING_LEVELS, }; From xen-devel-bounces@lists.xenproject.org Tue Jan 27 13:27:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 13:27:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214712.1524951 (Exim 4.92) (envelope-from ) id 1vkj6a-00034X-Vt; Tue, 27 Jan 2026 13:27:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214712.1524951; Tue, 27 Jan 2026 13:27:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkj6a-00034Q-T6; Tue, 27 Jan 2026 13:27:40 +0000 Received: by outflank-mailman (input) for mailman id 1214712; Tue, 27 Jan 2026 13:27:39 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkj6Z-00034K-3E for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 13:27:39 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ef8a6665-fb83-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 14:27:33 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BY5PR03MB5219.namprd03.prod.outlook.com (2603:10b6:a03:221::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Tue, 27 Jan 2026 13:27:28 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9542.015; Tue, 27 Jan 2026 13: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" X-Inumbo-ID: ef8a6665-fb83-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Y3zz+yb2deUigyXxVsBl0kV7IwFBIvmaFt7ulGiD2XdzXxkWoX5pki6L/uv9hFwvUQm+q/YwBrISpXX3CDeUmjtjAGKrLY/cSnqtfSDKzA9ACbgNG3dmt4jj4tzfJsrxMEhtTO852EPOuinghLnCiWGOg83j63nCHRX79FLAvZM6ri1EX/hUHPyf5sAfnW/7hsV1plnRET6VwI/Z1SeYQo6F7kgw17vMFO0Jl3sKQjT2h36i7dz9Ht75y5gmEzDTvOpgMU4CTxIB3u4+6wnGTPNaWjxNHp8MQg9hb2EUx0c177H1IiCk80FzQdoKuDW9LihzzJA9if67kIyzPvnoWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mzmbWFcOR0CUdgqSlkOltoVh8M1pgRE2X0Bloc+Ob/Y=; b=ixc747SylPexmVIkcl5+9gPb5RDS3E54hR1wqtBRDekfyTn6cVDXBFocLsvyW0/QW+LffGxUthNGKRb2wgHxqILRj+2tCyb2Ix9rcctgNE0JZgldEC+toTVSMuX29DdRkmPcZFpRLP6K/v3FhdeQhdhlN/T/6HqwpA0TkLxCTEsLRgF9UhOsZ+z2Fj8c3oPS2BytH+Jc9z2y1nXWfPz930acOfW7F2h/rADqQAUlUEtOXuELie5uYsR4TAoBB7287hctNwUq1JEugXJhilHG3RAAmuI4jS85X63mdZhu7kRM14TxPHrMzABl6Hp+lG4ByOEWfJ2/SGRLkkqBOWmE0A== 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=mzmbWFcOR0CUdgqSlkOltoVh8M1pgRE2X0Bloc+Ob/Y=; b=WwL3knM8Yu0cko/nBSlkkmnUUEdYUrGwWUpeQN+04gPeluOXcC1TS8bqbsxYR+4OI+lS+T5rVuBO2s/EDqJJXuOYO9gvmQq9zTAJrC/rAc1/Ix2FA0XwS363GjHHF+5iEOuSP6hm6xifqNsrYEMSzk7SOCDXGn6XSqEjgft9HdE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <48cca311-328e-46bf-b5e5-e22dd9264b84@citrix.com> Date: Tue, 27 Jan 2026 13:27:25 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] x86/shadow: suppress trace_emul_write_val hook when !TRACEBUFFER To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <7982a813-0fda-447e-a0f1-c9357b85f264@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <7982a813-0fda-447e-a0f1-c9357b85f264@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P302CA0021.GBRP302.PROD.OUTLOOK.COM (2603:10a6:600:2c1::12) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BY5PR03MB5219:EE_ X-MS-Office365-Filtering-Correlation-Id: 0f4d0993-bacf-45f2-8ded-08de5da7d10a 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?QUgwZC9rOW5PeVd5bW1uY25SOXNHSUxsMnZhVXdkTWUxM2I0VlRmLzRiZUpi?= =?utf-8?B?YlVwdXF6TytjWmlsZWw2WVc3bzRKblMxZUM5YXVCTVVMTkhrSFc1TkZSYTk4?= =?utf-8?B?ZHhxMWl3T01zY3h6b2RidTFuUlh5M0Q2Uy8xL0hQdzQ4emp5SitJWEJMVjU2?= =?utf-8?B?RlVXTlltNjhwSHNEVDRmMFp4eXVweU82TWJXT1M3Vkk3V0REM3hOeG5NN2U1?= =?utf-8?B?Y1dpSnR2REtTK0toblNaTE4yZXA2Z3BaQlo0cHA2eWFJdCs1c3FkbSsxSHNS?= =?utf-8?B?bkdMNUlBU01sZy9xMWppYTZCclZFWjNlaE9hUXd6U2lPV0ovRnBvQWpvTDdv?= =?utf-8?B?SzlNZlE4K2pLNXBJTWkxOXF1b25HRDFRWmpKUW1RUFhxYTRkRDJnbk1KdXNs?= =?utf-8?B?TW92N0FZTUR6ZGZQYXRGNDAxWlhSWDhnTHoxMEpUaGQraUNEMUlJaStRRks1?= =?utf-8?B?UE1RQ0g0TC9HcVVrNnY1UjUwdDRzUHBDZVFvbGxaU3RkckVnQ1poaC9pajJ2?= =?utf-8?B?ZisyUml6ZHBLZFBlbmtHRjJCcFlPbW9uNWtnSEZhZ0lzK1gycDNFR3dXbExY?= =?utf-8?B?NC9vZ2NNZDk0TjgxYyszNjYwcXdld0xMaWV6TGRVTGRKZUFSZXRqb2Uzd3ZB?= =?utf-8?B?M0xpaDB1N0g2RzNGR1Z1aUZGUEFPeWVsQW43M2J5cjJvbWxnNGRMOHRFZDdJ?= =?utf-8?B?MmpCWllIQ0JjOE1VOGh3WmhQSmZyYk1oQ2YvdlVNZ2xIc1JLQlBDY29SeWZ3?= =?utf-8?B?MUZSN1pjM2NqdFpBMGNHeXZpSGQ4TlZjcE5jcGR5cDFUNWM0TTRGL0J4ZmlY?= =?utf-8?B?YlpPQkNjL0RWaUVhM1ZZbWpOWXIvY3phMTJvdzZoUytnLzVpbGhWMy93VU9s?= =?utf-8?B?SG96L2hERVUwTitGSEpHbVhmeUZENG9yOEhCV2JXa0RnZEF3bnhyUTFNTCti?= =?utf-8?B?NjZkV2Q1Wmltc3UvM09Wc0V0dG9qZlZ4c3NuU0dDWFg3a2tpY1dBK1dEMHJ4?= =?utf-8?B?OWx6MGgyYTBUTW5aWThQSHNSUHpFL0IwZEg0dDRHM2tNWHNZMkM4NFFCY1ZL?= =?utf-8?B?T2R2N05ieTZUYytDa09pY2J3MER3L3Y2by93MWo0bEY4MXNlM3VHUXZSTXU4?= =?utf-8?B?a2xlWnVkQXc0a3JIWXVuNGlqMWtZY3lHckVkeUMwUDAvQmFBNTlFbHllWExH?= =?utf-8?B?VERBbGV1TkpldmF0VlJ4OEhUdkhZUW54VkZKZTVvazN0WVdPS1BybEY4TW53?= =?utf-8?B?QnNLSVFaelFkM0JDazZmQ3RGeUZSMFd1aWtWamt3bXRqVVB1WUV1L3gvR1d3?= =?utf-8?B?dXRvZmJYZGpJTTFYd0todlFzZ01FcTd0eUxabkZYNDUxNERVUWFabDdLRjdv?= =?utf-8?B?RWRSZHdCODhWcG1EaWtGcmlackNIUXRnYTRVYmtGMXRWUDczN0JlbVBTWVpm?= =?utf-8?B?dm5jRnR4MDFERzlMOTJJZWx6VEliOU1nSGVJaTJYb0xEcjZVOUQvb1BvamhJ?= =?utf-8?B?MzZVSGVxb1RLOUhpdEo3WnFhcC90c2JKNFU0RHJEbklUbUJoVGNBSEpMZ05J?= =?utf-8?B?Q0U2NHVsN2dtdDBsWDN3OWVFUEMzaTRaMmVuRG1XbXF5MnRoVEYzOGRkdFhp?= =?utf-8?B?OUJ6cmNyQkR0MDVpVDBSSjVFSlZsc2xHSmx0bUltSWY2NjU0NWJpeVBocWd2?= =?utf-8?B?OU9jbWl0cVVEN3NhNnZKZ3p0bDdlUHptOGcwYktGWW15OTcrSzBncUUxRkxk?= =?utf-8?B?MUhpNHh0VUJxVEFWaHBUbURTeVJHN1BTc3RSRHMvWHNET2dYbVdsU3ROVlZP?= =?utf-8?B?aXVqUXJQUldQUG8xSnZZRm05REU5R2xFWDFTZVBLMWN6QWovT25tT2tXQkdo?= =?utf-8?B?WHMyMW1VeGh4amk4NkFieEY0SDNDeDk4UTFIRWRNbUVvOHNBa0ZOVFhhdVo5?= =?utf-8?B?ZWpHRGIzYTJjV1ZpMHB6cTFMcXZ5NGlrajFlaFQ1WVp2Vk0rOUdVcEZydXpC?= =?utf-8?B?VVV6TDA5WUlSUU1hY2VySmZ4Q3YxMTlwZW83QlhsMUNNbU5jZEhiWVIwQXl0?= =?utf-8?B?anFWUmtJRmJ4bzQ1SVE2bml2dmR2TTdDekk5Rml2eFAyRFBrNEtnOStyR002?= =?utf-8?Q?yDzw=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Uy9WNnZacW1GelV0TTNvYnZ1VEdKbUpOSXZ5UU1qQTUwMHpLL2dDb2tPdUxz?= =?utf-8?B?WktBRDJPamRwUjhjR1NOQWp3bGJHdExrL1ZPK2duZlhETC9BbEN6c2ZvWEZ0?= =?utf-8?B?WnRwSVJrdzB1VzczT3RsMVVrSlZOMTJIc1JJU1c2aTUxMjc3MHZGRGZGeUFN?= =?utf-8?B?M25DcXRaSkduUXpVbXM5OUJiT3V0L3ZETVV3d3ZKNmdXSXlxQ1Q4RXAyWkJE?= =?utf-8?B?QmpVbnBYYVRXc1JqcGJJN042d1kydjVWZVFDYXpaWk96WUFlZE44T2VZcEta?= =?utf-8?B?aW1EaWxYMnlDSjdBbmhqWG14ZDNWN2VCUGVwUHgyQ3VrL29vQS9oYzNzL2hM?= =?utf-8?B?dWJoOHBqMUVEU1JJTVI2OTlpdDNmZFM1M0tXVXVzRndZRmp3Q21KYlJjSjFl?= =?utf-8?B?VnNIcXBIWkZSeFF6SEwrQkJxTGVJOFF3Qm1yeTZsdXQvbVc4SVZ1NGtuSCs1?= =?utf-8?B?S1ptV1V6UU5NNy9NUThaT1AzWkVHVHZKZnFtcUJQdmk3dEZRai9JYngxajFa?= =?utf-8?B?SDJ3QkxSZkptZ1N1WVl5L1luS0I0enV4LzdQbVkrekNLTThQMC91dkFwQnNL?= =?utf-8?B?dnI4M05hTFlHWjdpcHpHWlZBNGlwRWt3anA3ZVM2UzFaQ0dpU3NacG83QkJU?= =?utf-8?B?OGE5MVB1Njh0aktPRFlpUktvM0paRXQrOUdLVG9PM0JkZzE4QzVzcVdwdXhY?= =?utf-8?B?R29oOFB6Zi8vTGw3dGNvdUkrUTNtSHZ1a0tXemVKdDJvN3NWcnJrSXFsR1pW?= =?utf-8?B?ZUFYZnZvcDNGdVMwRm96Ykx0VjdLdHA0QnVtbGYyRTU2ZUV2MGMvdU1PVUNF?= =?utf-8?B?UnY2Z2xYa2prL29mSkM0aDV0U00vL25MTXJEWklka2VpU1RjVlM1VlMybDNC?= =?utf-8?B?cUFVQzBHRlVOTzN2VWdtZyttNDdJbDBMb0pPeERvUGRNelI2NU03THpkMTVX?= =?utf-8?B?U2xCZlptYTVpUE9iUUIxdEgxRTBhaU5lUlZHOTh3dWlHVGllMm1yOGpQWFVN?= =?utf-8?B?QzJzVFVDME84WnR0MDRURjFvN0dMcVBiTkxSWXRqeVRnVGtxY2l0MjhFckVh?= =?utf-8?B?TUtIK0J2dGZBcHRaQk96VGhqdWM2ejlUam9OVDRISGZkK1BORGtNWE5iMmUr?= =?utf-8?B?Q1pNMmJmUjR0N214V2w1TmVLNTFjTlhCMlY3SDRPRk9MdGdGUlhyT2VSNnY4?= =?utf-8?B?NjlSbGh3b3hQUjNQQlVyL0RYaUlqT1FETld5cm40NERhai90K1M3RWlFRm1t?= =?utf-8?B?bUE0T0FZNlVaZ0c2YnNodjZmMXZqSWllUmVFZ1hha3R2S0YxZm5pdjZPVDIz?= =?utf-8?B?WllMUWF3cHdHQUd0QnlOSW5qMjRtMjB4bXZXYitxZVdzclJsa3F1OVpHSEkv?= =?utf-8?B?VC8xZEN4NGpLZDB1aE9MZDJsQ0NnZ2JNcHdpcTlSS3dHbktkdVc3Uk9BYU45?= =?utf-8?B?UHYzWlA5V1czOVJpWFQ5UGQya0JOWU1ZWXdkUzFqL0F2bmFRZWRDYVovODVZ?= =?utf-8?B?b3doUVFhbitNVCtaMUx1Si9rZzI3RG9mL09uTzkvQjZ2SVozOGRNWEFldU45?= =?utf-8?B?b1IxcEQxOUF3eWE5Q2s2dzhjZTFaZE5xc3FFMndoY2c0L0dGdEE1WFhaNStr?= =?utf-8?B?Zmt1eTZxRTRickVpa0RYemh3Ym00NWtTelJJaFZDWngxS1U3UEVpYlVUMXBP?= =?utf-8?B?UTlraURtS2xVZHpjVVM2Yk5md1lvUTUveUJYUTdrN0YvSTA1K1hieGlsNjZG?= =?utf-8?B?KzVGd2dSNSt1eDdiMlQwTVRlVTdWWmdmNFFBOUFES0xvRWFlbWprOVRITVBJ?= =?utf-8?B?T3QwMjdTem8wN2JiTUc3dHpBdldTTzlLODRFOTRLdnZ6YWlEc1RCT2w1akJX?= =?utf-8?B?U0s2bDgxc3RQSjU1SEVGSlRaQkhXbHBHUVU5S0lMZ1RwYTlLVzdVTlMrelBX?= =?utf-8?B?L3FwR29FajZlV1VzaFUyN25KNWorQjk4akllVXpGc24zcHUrYlFvcHYwbmJL?= =?utf-8?B?L0xrejdsMHpGWnZYRjBMZE1TZ3hJWlRBL1l2UzJMZHRMNEEvN1NGeUNTYVJH?= =?utf-8?B?SU5vb2dJZDZsVm1DaEg0OXpSaTRxSE9sRzh5ZFlEUzc0aHd3Y2l1VmoxTStj?= =?utf-8?B?K2RGTnVRSmM1RkFWTGJlMVBQU21jUGpnWERFZmw3Ym5jYUw1ckVuQk1udDdN?= =?utf-8?B?N0oyV2ZvL05idnJjMTVld0V6cFFPeE1xcm1HUmRwNEZ5VjZJMHYzNHF6Rkxu?= =?utf-8?B?ZXJ6eXNwUlpTVUp2SHh2VHVWVDZ2NW1uRGxDTmsrSml6bFhwQ1J3WFBXSGNn?= =?utf-8?B?elpwdmdPOXBjSnlOWXhENE0zL0IxSDRxVWlRZTVScis1Y1FoR2xydz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0f4d0993-bacf-45f2-8ded-08de5da7d10a X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 13:27:28.2747 (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: MKmqSwJbZbuSZExe6Ll5sLOwt4pwJOjqADef+8pMsEKnOiZl3Us7xvjEk6xg40FOJdFTEQXfcJNkPuKPQspeKYdWgcwQt3+dyeUTR43u+Xo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB5219 On 27/01/2026 1:20 pm, Jan Beulich wrote: > The hook is never invoked in that case, and hence needlessly offers an > extra valid indirect call target. With the hook suppressed, no consumer > of the three local per-CPU variables exists either, so they're > suppressed as well. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/include/asm/paging.h > +++ b/xen/arch/x86/include/asm/paging.h > @@ -90,10 +90,12 @@ struct shadow_paging_mode { > int (*guess_wrmap )(struct vcpu *v, > unsigned long vaddr, mfn_t gmfn); > void (*pagetable_dying )(paddr_t gpa); > +#ifdef CONFIG_TRACEBUFFER > void (*trace_emul_write_val )(const void *ptr, unsigned long vaddr, > const void *src, unsigned int bytes); > #endif > #endif > +#endif Can we get some comments on these endifs, and ... > --- a/xen/arch/x86/mm/shadow/multi.c > +++ b/xen/arch/x86/mm/shadow/multi.c > @@ -4130,7 +4142,9 @@ const struct paging_mode sh_paging_mode > .shadow.guess_wrmap = sh_guess_wrmap, > #endif > .shadow.pagetable_dying = sh_pagetable_dying, > +#ifdef CONFIG_TRACEBUFFER > .shadow.trace_emul_write_val = trace_emulate_write_val, > +#endif > #endif /* CONFIG_HVM */ ... this one too. Otherwise, Reviewed-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Tue Jan 27 13:33:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 13:33:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214723.1524961 (Exim 4.92) (envelope-from ) id 1vkjCP-0004nt-L7; Tue, 27 Jan 2026 13:33:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214723.1524961; Tue, 27 Jan 2026 13:33:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkjCP-0004nm-IH; Tue, 27 Jan 2026 13:33:41 +0000 Received: by outflank-mailman (input) for mailman id 1214723; Tue, 27 Jan 2026 13:33: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 1vkjCO-0004ng-C4 for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 13:33:40 +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 c9a5e2a2-fb84-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 14:33:39 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-480142406b3so38694505e9.1 for ; Tue, 27 Jan 2026 05:33:38 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1c02c91sm37726638f8f.9.2026.01.27.05.33.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 05:33:37 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c9a5e2a2-fb84-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769520818; x=1770125618; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=GjcUmlSDOQtUbwhnK427cRrAc6C/S6nq3svnYB5Wr70=; b=FxEge/o9YMPNsvC1QY8d5wxGMnoE9NfAp3W1biv2RlffHzE6J0dJYJSHrMtIHH8xAb YnXkNQ0xbys9ts+gizgUeH5TEXGZ7H+cxuLd4BbOhCtCmx3GoH+4DThrbnz+ysDpbAHG jPHyeR03rpw24S688d3jNecd/XgUWHb/LMyUrbc4h8AAYqJh+/ZzQjgsLsoCWRyoZWZG ZpnKNyY5VsZF0GmHkOvqQ2csymoOGXQRCN5JscssPqTaZfurcvWTjF4yi3fMufeXL7gd xktQLnRFkoT5YA4xLeBHFNs+6FguBmdRtNnpVNnhJBURkkMIbb7rp2pfIyLqCw79BKRV 2ONA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769520818; x=1770125618; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=GjcUmlSDOQtUbwhnK427cRrAc6C/S6nq3svnYB5Wr70=; b=ARWhF5MOliXySkux+h1FE/L9SQjRduplgeTlxmcbW66W1sCXmWDUEolgV0ieacojo5 2xdD5vU+HBjenim661O3GB8zrrfXdI5/zDph+kEdw4ogUn2iQT/MBFQBbUwS3xJgZstv l4jQOUqDqs9QtwS7FwiInE0DmLpaPYB6or8KChn1oImaJerOa0924+4aVUJUMMVNGfMz uI9kps8jbrH8cdbmNdxOam7gi3/7snc4vvoektG6gOXhB+eUExR2xw6k6oyV6zSY09+f mAbMkgEqLMK8nweKX7bRVLEMkP/Hvq5pt+D8e7xaiF/vjtmM6wXENXaCZUh+GYO9Jrmo PpYg== X-Forwarded-Encrypted: i=1; AJvYcCWBt1VHEkVHO0HbfkyvkmnqgR0eWEJ5CW0pwyBtixtKVkx8Fm9iaRsins8fWoacJ0T+/NE9hszcqhw=@lists.xenproject.org X-Gm-Message-State: AOJu0YyGvZNQfo7fyQf5VcCafL85D3/ph0P9kVI3Qu+k3u+I3BWlvOXA +2hYV1qS/pjvGJ9REERs0W5aXdQVoqbFmzzKw3fzEbGdYyCqh5fqqbxpq8PdNH5Qdw== X-Gm-Gg: AZuq6aL1MJpuH/L4XhDvDJYoT0GfxqCXINNo7BxEhuX8wGgHu6YHiV24qOvlif22M6o UkJ7Q6tco8NsuORaGZNeiFnAzRHpcxl/SWIn2b8ctPj0pcjTf/DaQlDnQLb7/rn+XGId5hmnzqd HkAcmXn/DG8NqcrU6/bOg2pX93a978rBiR2EC+Z9Uv8w43Dhrrt7RJPCuB9ypR0w4Gmy6hZLo7J Etv0FdrUNhBG/GJWt8I/SMNG7j3YY4VBbPGT0FJ2HPj3X7eikyU33DEt7ChshRgnke3OdX5nNsX Bn4nxh7KcFBboQyYOuCXeIVI9igbjyiVrlImenOVjwRjuds48BbQgvz7cHREhiPx6yJfHTh6wuM SNmbyjw+6kxFnT8yP4JkcemVIUO753EhxLo7I/pP3xl0coo0isZOyQOLvKjEkC3Y+KdKujW958h O8qq8dOZo3EbXInfKwukzlkulUhTT3u/hHYPcn536IT3rMYH9F0e6fT7Q6qpwOLJE83wnaH0++n BxD3nkIAv22PA== X-Received: by 2002:a05:600c:3b03:b0:479:2a09:9262 with SMTP id 5b1f17b1804b1-48069c0dd99mr20828335e9.9.1769520818127; Tue, 27 Jan 2026 05:33:38 -0800 (PST) Message-ID: <11ca6b6c-50bd-49b0-b601-115b4eb2483f@suse.com> Date: Tue, 27 Jan 2026 14:33:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 02/16] x86/cpu: Drop cpuid_level adjustment from generic_identify() To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-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: <20260126175345.2078371-3-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.01.2026 18:53, Andrew Cooper wrote: > early_cpu_init() calls intel_unlock_cpuid_leaves(), which arranges for the > boot trampoline And, not to neglect, also the S3 wakeup entry point. > to make the adjustment for all APs, meaning the call from > early_init_intel() is a no-op. Drop it, allowing intel_unlock_cpuid_leaves() > to become __init code. > > In turn, the adjustments in generic_identify() were a no-op too. Nothing in > the c_early_init() hooks modifies the 1c/1d features, so their values in > c->x86_capability[] are still good from just above. > > The ebx variable used to calculate c->x86_clflush_size is still good too, but > move the logic earlier so it's more obviously correct. This part likely can be dropped when the pending adjustment to patch 1 is done. > Fixes: fa4d026737a4 ("x86/Intel: unlock CPUID earlier for the BSP") > Signed-off-by: Andrew Cooper Suitably adjusted: Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 13:35:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 13:35:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214731.1524971 (Exim 4.92) (envelope-from ) id 1vkjEN-0005KB-0u; Tue, 27 Jan 2026 13:35:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214731.1524971; Tue, 27 Jan 2026 13:35:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkjEM-0005K4-TL; Tue, 27 Jan 2026 13:35:42 +0000 Received: by outflank-mailman (input) for mailman id 1214731; Tue, 27 Jan 2026 13:35: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 1vkjEL-0005Jy-NR for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 13:35:41 +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 10f142f8-fb85-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 14:35:39 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BY5PR03MB5219.namprd03.prod.outlook.com (2603:10b6:a03:221::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Tue, 27 Jan 2026 13:35:35 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9542.015; Tue, 27 Jan 2026 13:35:35 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 10f142f8-fb85-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=EmqNm7IU6nj0IuoIZWC8J/CxcFw9ewN4iEyZK4D1xCKXBpr0XUxUiMMxt2TwKtSNrSlNtHEr+6Zs7gDkOq1yeGAKhg/pkBKsxbPkanXmP09QpufB+R+2hnIY+5XYjA0C3dr6ggH4qwWd+2A9PwugiPlOnjokYJBp0O5wcb3PqROrBbukZMzqDEQ+Wk85riOXP1Y118OQnsJlz9LNJTnq6KRiM+WdxxcLvhI0sYDe6zgikxJlnGRUyhKZ5hw8VRrzPbs2NcKbFukXHb9+S7rYmHqXS/59tDeX1UJ06aLLlsfE6l1dbZXVhs3Y7WfzJaciwYfnj6hHoXKTh7Q89jmNPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uYu0fLbMD46CRHBOk/DythtbDqFmMQu0j9bHWiw+JnY=; b=u2q0FbTR4O8bSBrNjro0aNgZowR+JL3odjlGA65Vzhn7J+rNqBzscSAa4BNcvjx0g7entvXobkcusjkdtzVObbu6WkSafRxusSH+fUc71z0Nch175AUAemK5+IVL0lhIfJpklAy3RT/Bdi394N/tid255gAAue7pbnp0zl351CrJqcIQlUnS6JokCnj/1b7ijAGpnIqtoQ1NqE9hny4lBBXzIM9GVxBLwXXUlBB775s6GGZDFA2/GqTTkHApKzPYh66xn6spf93ZZLIy6jzPhWeY//pTCal4yQgJrVnSEJq4drR3128GvmQauUxtRpdYj9dtdP2Akgxun3B5Xjtdzg== 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=uYu0fLbMD46CRHBOk/DythtbDqFmMQu0j9bHWiw+JnY=; b=veYtUSItoPKZrIPhAx9DJ9zUp1pWGtJGRnso1xKtjh2vI4W8M3VWpWgViIXpLX7msLFqHwZBLyiMXQHikPKOz3qrJp6PmIiUAE1Mwf3dZVRJFCGZHbbMdpKUEFSUSerPguMcyMj+lRGZWqgxsg/IQ+oPmkp0uWX0M3guFMSjYDo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Tue, 27 Jan 2026 13:35:32 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Kevin Lampis Subject: Re: [PATCH 03/16] x86/intel: Drop the paddr_bits workaround for P4 Nocona/Prescott CPUs To: Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-4-andrew.cooper3@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260126175345.2078371-4-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0444.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a9::17) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BY5PR03MB5219:EE_ X-MS-Office365-Filtering-Correlation-Id: 65a0a9f4-8acb-436d-b980-08de5da8f342 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?NjhlM3hENHF2NlFEZllWMk9uRGpYSk1zRlFsY0xCcGV2VTd6dGE4eWRIVkEx?= =?utf-8?B?RDRmc1MvbG5WRzJXVTFFUTZRdytsS2tSbURvYlpPdGtTQ25HMzVGcGRrOHEz?= =?utf-8?B?T0Nnbzg4ckcvZDZiUXJTM1hxd0dJU0s3RGY3dWZidVlUSjFKNmlycHkxa2lT?= =?utf-8?B?b0VKa2xLaDlvTW1qRFhHd05wYzg4bDY4eTVjd1Z2RUtremtRN3lObE1GTnBp?= =?utf-8?B?elRWWHdsUTZTcE9LR2gzU2I0Ulh5Qlh3Yzd2bDBZQzEyak9OWi9TOTRlUnlT?= =?utf-8?B?OG1BVWg3OGgxdDNTaTE2TE1iUjNNcUJiYmJHUUhHWXV1cjBFL3RCSWdRbzhF?= =?utf-8?B?T2RlTlhBNEN0SDBiYlBYWFFGNWZ2YnFrbTlsYnFWN1VPUWhBeEMxeHFMSGZk?= =?utf-8?B?ZlU3R1o0bUhHNy9VcmNESVFQdVhwS2RHMFEwTmR1blV4bk8xbkVJNUowL3RN?= =?utf-8?B?QVV3ZHYrOWhtYkZuaW5iRnFnUytGeU5zSTFPMXg0M3BDNkhvVzJCcjBYdDRZ?= =?utf-8?B?bytSbys1ZEg4eWs3anZJeFRLczI3NzVmZ3k2OXJUdVl1VGl2TWl3RTZxMkJ0?= =?utf-8?B?cnBRb0VIYm1aL0lRVThSL0FQMVI3bk1vanlyZUVmLzBVNGc5N1NhTTFFeW0v?= =?utf-8?B?TmQ0SWh4U3hnalJBdGo0R1crSDRYKy8rVTN4ZVJoU2hSNzhHY0xYTTd5ck1q?= =?utf-8?B?TzVnRzVyR3ZubHBuYXRBVVYwaEsyYjdmejExVmJJNDFpRzRtbnN6OUFzOHVO?= =?utf-8?B?VExScGJ4MUNaK1hFVmhDL2V5NEZIcDVrTjNYcW0zR2srOVNGOXFOR2RIOURq?= =?utf-8?B?VytMOGhZb25PZklObGpmQTZTUTFHS0p5MENxdjh3amN5TzE0ZFJQaWV3bm5G?= =?utf-8?B?am5MN2lGSmpoRVVmUytJL1d1QkdSOGF2amxNMSswQ1I2Y3BxSkpzZDJpSkh4?= =?utf-8?B?RFZTdDBMTlpZb09DVjRTNHVJQ2ZsS3h3WVR3aTJaK09CS2d4cGtHUlh2VGdK?= =?utf-8?B?Slhmc0k3UWVoaFBBVm0yUitzdUF4OWxJNWpUYms3ZCtKYk45RzhkbDd6b1F1?= =?utf-8?B?bCtvaTNiRWwrS0d3am85cS9xMWNTOTgrVHMrZVd1ZU8rQkYwUFA0WVRuWEZr?= =?utf-8?B?d1ZoK0h5WjZBTERGMkI0RGxzcGNWdzd5dk9lSUZZZWhocHFZbXVWRk1uaEY5?= =?utf-8?B?ZUNJUTl6Y1BvV0EyZ0dUSGlZUlUzZFpMa2ZKOHMvNWtlTjV4blVSTThPcUI2?= =?utf-8?B?QWlxQks0R1I0SHBTZjgrNS8wQmx6cTFXMHhFOG85OGRYSGFickdyeW1FN3F6?= =?utf-8?B?NnRaR3hRdDdDdVB6SHg1NldRSTFwY1ExVDdpMzN1bGVZSkdWWnNsaVVlTVhR?= =?utf-8?B?N0F5RnpudFNLOTRRNGpDT2xQKzB0RDFPVjJvbm1udklWN09qbWp5eERWK3Va?= =?utf-8?B?V0dyV1pYQ21EMnhNcmpSUTJSenAvcElYK1pWQTI4MWNUcmlVbVpOYTlDQWxw?= =?utf-8?B?TlVhZDBqZHU5OThzZzVSOVIxTDd6Y3ErT3ZWZlBpNFhlQVVsSDU0dnJqQ3Nx?= =?utf-8?B?R3lvdkh4TVR5bXlUTitNTDhKNFdTQzhLN2N1NVdRYlY5U2ZmZk5KMWJIZXlY?= =?utf-8?B?aXNHSlFvUFhBT2Z6US83aTRzQmJDMjRXencxcm5oQS90bnBiaCt6cFkyTUZy?= =?utf-8?B?eHMycm5UdnFYZGpORXNFRFJ2K1F4NmlYNUJiRWw2Z2J3cHJGcTU2T0k5RHNR?= =?utf-8?B?OXVIWndNVysramJxSHdScmYwRTJNc29mUkxsMU81LzdZOGhycTl2d2FyM0dH?= =?utf-8?B?ZkdsaDRUVWdOS1lOY0Mxc2h2cXJOZEpzL1NRSHlzTjJsQ1FxVXdkbmdacHd6?= =?utf-8?B?RFptYXUvaU5lRmtKL1l3WGFYTnlMejBTb213RW1YYitiaWxScUZPdkk1em50?= =?utf-8?B?S2EyWStyWkdtaXZQbFJUUVlIbHFxQ25WRGM4OVdJbFBzTUlNYkFhamRHeC9a?= =?utf-8?B?YXlObmRUd0ZDemsyRVFhejVNNm5zNlFxUmlCb3Facm5pMTZrcHJTOHRVNTY1?= =?utf-8?B?UmtXVzEyay9DejJTajhkb2Y0WlB2bUt4U3hsVVJYUURHd1BOdmNaaWtlaXV4?= =?utf-8?Q?oqOc=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WjFJS0RDZHd6d2Q3NDJsOFFmMTFibWJVOXFONUsxRDJlSDJ4VUdBdHRVTmps?= =?utf-8?B?Nk0xY0VqWTRyWlA2U0tXWXJWenJBOWlLdVloZEZ4bmlUa2NNOGc3OFdOdk91?= =?utf-8?B?dmhHY1BpL05YZlZWa2hhYjh4UVlWRkpRQ3lnMUwvenhVaDRJclk3ajIzRFJp?= =?utf-8?B?aHJSQThJT0EyZXFwby96amdwVWN5cW41NkhQMTU4OE9qc0JRc2pLTEwzVXNv?= =?utf-8?B?YWt4N2dRTmxJU0NLdktVeWs0NFpDNXBCTkJGUHJ3WW82aTZqQXBwRnRiaVZC?= =?utf-8?B?NU9raHdRYlBuWGFZdGJsajJ5Z0kxalRUOXdXckh5Ry9xdm1KUlJmRmR6amk1?= =?utf-8?B?TVU4ZHoxY2s5T3pkVXRoT1BCYVU4WUJPVXVINzdGUXROQzZPUSsvSVpDd2lJ?= =?utf-8?B?bFNZbEVWS09nN1ZGNHJFeGZ0dnFyNTI4Y203bnBGL1ZpVFhFSzdXZXp1cCtZ?= =?utf-8?B?ODVadTVQTFNjTDQ4OXZ4OXlQZWMyZ3lKdDVZejVzVFREeDR6clhmYXZYaWNS?= =?utf-8?B?YWF6aUs5TUVIOVZxMmV2VGdyWUtkMlJndzNxazJGcjRGeWJ5NjFnbm9tN2dV?= =?utf-8?B?d1hUdjJ6elBxL0U3OThDcWlVS21HSzJNRllaN0J2WFUyOHphVk9PTmE3KzNM?= =?utf-8?B?TEpUWjl1RFZJYVZqYWQ4KzVGa0gwTm1idndPTEZkeVFKVHZKY3crSjg3bURn?= =?utf-8?B?VkZ2SVFjdDlsaUlNaHE5RzhNN21uKzVweE1RTmk1RC9ydGhHSHpsV09ZS3Fk?= =?utf-8?B?d1NBUHh6SVlkWlNRYWpiTFpwZkRBd3FZamJITW45MHFqU2p4WncvOXRHY0My?= =?utf-8?B?VEM1MG9kd0ZJcVpDWG9Ub2crQ3BtaEJqTU9SWVM4T3dWS3N6ME52c3pVTEpB?= =?utf-8?B?bWYzQzF3YVR2QThJWW16SEx0cTRXL0w4QXY3UHpKbmpwSG1aUzhBQVRWNTNS?= =?utf-8?B?Y010cXMrekk1NmIxb3RZVmwrY2RlMU85QjJ1WllsYk1PTFNiUTBta1c5a1d6?= =?utf-8?B?cFZLa2JnUGV3dXh3NkdGRFRFVzJ5Y2N6TExXeE5zcFNLZDBkTXVKaUVnek9T?= =?utf-8?B?WDVVMHJyTVpaWVI3V1oyM2JxaFBSR3EyQnNtT3NMWlE2OExpZUd4eVYwRktZ?= =?utf-8?B?Q2xFZmZIUHBFcmFOSGcxL1djMzFITHlmdGRQQ1pkdlltL0tTR29SaTk5Nno3?= =?utf-8?B?RzBXVXd1NzlBUXVlQ0hGWEdSMStJM1pQWm9UN053S1A0ZElmeEpwOVJ6cFJm?= =?utf-8?B?aE9iSGt4aHNNeGY1V1RKcXF5R1JtY3ZUZldEejVqVDl6Q0VocFZhQVJWWlhF?= =?utf-8?B?L2RTMkRvaDJvZithajVCVm1QdThHN0tWMXViU1FPajkza2F6MVMwaVRaSnF0?= =?utf-8?B?bG9ZaXJlbjJ0c0piUGlUd1lEbEcwYUVpUW1QUXkzbForUUJZcG5yaXdkb2gr?= =?utf-8?B?Z1VNb29TUTVsVTlWZTZkNEM5MXJJYXQrSmM4RXFtTTdUS0wvL0VHNzZHbmRQ?= =?utf-8?B?dE80V01ZRGFGSFhOUS91N01mMkpaMm1NMUNXOFl5bVVnekpQR1k1eGROMVgx?= =?utf-8?B?aTljUk92Sk9ERDFlbG83czJabjlOTTRTd0JPbEo0NEpML0xsa3EzMDh5bzEz?= =?utf-8?B?MzFJSUl6TmJMY2VjVWhFa0RLdkdpZlZCZ3BHYWxBVHJ4SHd5bjhFd0oyTGFP?= =?utf-8?B?MWdXZ3dwRFRDblFqREtKU0FRL005b3N1ZVhhamlMbUo3VG5GNURTNW9YQmR5?= =?utf-8?B?MWprRUxaNmVkTVVoa0t6bDQ0bVRoZ2srMFdBQ3l6c2R2clhGalg5QWFMWFVC?= =?utf-8?B?OVRhRmUyK2V0MWZVZXdKVnVEWXg4R09UbnZRbTNvQ2JyaGFDYUl5VXBUdWdi?= =?utf-8?B?bDUxUkhES0ZuMXVZcUxYT1BsN0crWnZwcXB5VjU3WFlqQlVtWUY5QWxuYkht?= =?utf-8?B?THI1Rkxwa1h1ME1mUENRWFVPOGlGYVo0MXpDeUlJSkVMRG5QRVhFemVVa1Nz?= =?utf-8?B?YW5wUUpqbnRrWWdJTUdvZGRXbG1kd2h2RFFyMTF5a3BFZHRObXJGVWI3aGRn?= =?utf-8?B?NjhTZWZKM0orSVJnVXZ5YWsyQUJQbGJGZE9yelpkSmpMczdrQ2NrOVpHUUJH?= =?utf-8?B?enNzNk8xdm9sd0ZWUzQ1SjF0MkhKNHRWdlp4eVZLL0QyS0ZPZlBrQW16WXE5?= =?utf-8?B?UEU3bU9qN1FXenhDbGhMZHhaWHAyRUZkY2ZpalA3K2t4WXc4Mm0zWXkyTyto?= =?utf-8?B?WCtzTmJuc01NNTRYc0oveVJDMFpTWFV2SHBEY3pZR3M3bnJKS1ZyZ0ROQTVl?= =?utf-8?B?T0xham5pMUNJREJwcWQ3VXpFc3VxVE1sQS95aTN3OHc5UUdpYS9sdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 65a0a9f4-8acb-436d-b980-08de5da8f342 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 13:35:35.2263 (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: 8OrYH9Ruv0uO1IwC74Lx/ARmS0NEBkBaap3IURI1BEAgVOhAHqpNceZtlPBGds1RMS6duvrIaMJ73qiHixqUc9AISX8rLQWRKDfd+LH0XLY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB5219 On 26/01/2026 5:53 pm, Andrew Cooper wrote: > These are 32bit CPUs only. 64bit support started with model 4 (Prescott-256). It turns out that this isn't true.  These CPUs did have Long Mode. I'll need to rework this patch into a later one. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 27 13:40:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 13:40:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214743.1524981 (Exim 4.92) (envelope-from ) id 1vkjIb-0006gp-H6; Tue, 27 Jan 2026 13:40:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214743.1524981; Tue, 27 Jan 2026 13:40:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkjIb-0006gi-C3; Tue, 27 Jan 2026 13:40:05 +0000 Received: by outflank-mailman (input) for mailman id 1214743; Tue, 27 Jan 2026 13:40: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 1vkjIa-0005uz-Co for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 13:40:04 +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 af217a5e-fb85-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 14:40:03 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-4801d98cf39so43101185e9.1 for ; Tue, 27 Jan 2026 05:40:03 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066aaf235sm60512475e9.0.2026.01.27.05.40.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 05:40:02 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: af217a5e-fb85-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769521203; x=1770126003; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=7rRQNrlmIRxjdUw9lRfNy6SvIKx40L+3N/LeibmJRzc=; b=SsmqqnJ1KYUkCNCRBktKE8Q12lzilfMCu8gWyYLyL2TvgqgE92YrIt4WUsTB+nGxlA Yx0WItbaL6Y/tuigLQZUPPmqKcGbQ+qr2HArM53f3d+XMZoY7qezFX/gjYmXH1SfGltj mjXRRvDuNFCHMELB/7QjojeyM0BXfbeU1+bA0GS3wEAkmCCo9XTcACc4/75V2C3MDUac 0HKuVjz3cNEbwXkjz6kM6qBppYeelVluV9fQOvOKjrxy6wOASBrE9wnMfQljusWTzTrN 9tQjYoEWsFbZozIJQhq8WgBCkvGPQuzL85PZJFYUmGlJuTv09hIQm7Y0R81FQzNYOGfX lr+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769521203; x=1770126003; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7rRQNrlmIRxjdUw9lRfNy6SvIKx40L+3N/LeibmJRzc=; b=HBTpiSrX7is0ZQcvb7Rk0mM0EbI99MXBCYqsdC75RXWfOepxb3qYaZtZ+einsNNQDF Z0uQee8M8QPynGFF0H0TcwTpDmvl2YXLspiFBf1TwuqZz36jBxZNY7PqXm3V6mSGQjqB I+KaNm+aLuYEeDWCiumFBgPempZgtoK6Zl3DjuVl/08VUUMz9BJxGU1IcFk3r9zN9xeM 0HLpEkL73t+/debRJ0ls7d8+Nf2ajFZQim5xUw9qNboG1OfSNvrveVhNKkXjocd8LHl4 6e9E5Y4ZOjO5tLY4O34Mh+dQbMH3nJQZk7TFocokljKzsRKbKCsUF81H58x8zQ2GnAeh FRkQ== X-Forwarded-Encrypted: i=1; AJvYcCXP4ku5G+JcQn/XwVtPoe13gicBPiNAXC5viPt+Hur9eKJuO0IL5VM6uDsQn/BvEuIefdBmQcs8hqQ=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx0JlkKln2BE0ETiNShuiEBw573sVGnuFTvUGN8cSsaA6jWlTYj pWhSeMzVX5nLf9K0mi53x/wFca0RGwoCbfx7al0E6vNrR6OhSunIfbPhNuJyiCYHlA== X-Gm-Gg: AZuq6aIssvJKe+jxM3w2lQLWk1047rob3sVsV/tfhN+glJBT+VuawpO7qqZDmNiQf0I 9phVc1ZNk7n2YWAc98/cApX1TEaX+UiLEiIPNmSHOXPprMmtw7WoB3Lfgp9D1LyFwsBdB2xAdY/ GKEXLwgk02NWbJt2LbvdUtOWG81vVXdVJM6/fohRUXIAn5TtkllDQOj/1Fr5kfunsFLmSgJzvyu qivm9gxW28JPqqDSomGVipsikvN2o6zTziSj/vf82DExzktEu8sFropp22BLCnpH28fGWtaFMvJ aH3Tn/55SVXpX8aZtRXp03pRnMl+/nV6ZzJXC2ga+pREB/oj+koI8x6XdGwVs9o+5Vw6pEBFp58 DYhu6wx9BxOCyKzHrcsDUlXGetW39sZGTjSSCuwZQtM0RgTuRdHM2t7Q9pExalK6LK2JBY2C9yZ fd8kgM5MbFm4WD6PnvblmwtLPwRV+EjNLm2Qn6I6ih49CxJwd7c3ySJEf9MiabesMByQCIaFsLu SEzFZkgphCdyg== X-Received: by 2002:a05:600c:820d:b0:477:7b16:5f77 with SMTP id 5b1f17b1804b1-48069c3fa76mr23509255e9.3.1769521203141; Tue, 27 Jan 2026 05:40:03 -0800 (PST) Message-ID: Date: Tue, 27 Jan 2026 14:40:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/shadow: suppress trace_emul_write_val hook when !TRACEBUFFER To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , "xen-devel@lists.xenproject.org" References: <7982a813-0fda-447e-a0f1-c9357b85f264@suse.com> <48cca311-328e-46bf-b5e5-e22dd9264b84@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: <48cca311-328e-46bf-b5e5-e22dd9264b84@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 27.01.2026 14:27, Andrew Cooper wrote: > On 27/01/2026 1:20 pm, Jan Beulich wrote: >> The hook is never invoked in that case, and hence needlessly offers an >> extra valid indirect call target. With the hook suppressed, no consumer >> of the three local per-CPU variables exists either, so they're >> suppressed as well. >> >> Signed-off-by: Jan Beulich >> >> --- a/xen/arch/x86/include/asm/paging.h >> +++ b/xen/arch/x86/include/asm/paging.h >> @@ -90,10 +90,12 @@ struct shadow_paging_mode { >> int (*guess_wrmap )(struct vcpu *v, >> unsigned long vaddr, mfn_t gmfn); >> void (*pagetable_dying )(paddr_t gpa); >> +#ifdef CONFIG_TRACEBUFFER >> void (*trace_emul_write_val )(const void *ptr, unsigned long vaddr, >> const void *src, unsigned int bytes); >> #endif >> #endif >> +#endif > > Can we get some comments on these endifs, and ... I can touch the pre-existing ones here, but the new one spanning just two lines here and ... >> --- a/xen/arch/x86/mm/shadow/multi.c >> +++ b/xen/arch/x86/mm/shadow/multi.c >> @@ -4130,7 +4142,9 @@ const struct paging_mode sh_paging_mode >> .shadow.guess_wrmap = sh_guess_wrmap, >> #endif >> .shadow.pagetable_dying = sh_pagetable_dying, >> +#ifdef CONFIG_TRACEBUFFER >> .shadow.trace_emul_write_val = trace_emulate_write_val, >> +#endif >> #endif /* CONFIG_HVM */ > > ... this one too. ... one line here I didn't think would need comments? > Otherwise, Reviewed-by: Andrew Cooper Thanks. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 13:41:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 13:41:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214750.1524990 (Exim 4.92) (envelope-from ) id 1vkjJc-0007Ln-NY; Tue, 27 Jan 2026 13:41:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214750.1524990; Tue, 27 Jan 2026 13: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 1vkjJc-0007Lg-Ks; Tue, 27 Jan 2026 13:41:08 +0000 Received: by outflank-mailman (input) for mailman id 1214750; Tue, 27 Jan 2026 13: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 1vkjJb-000780-PH for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 13:41:07 +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 d38d457c-fb85-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 14:41:05 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS0PR03MB7655.namprd03.prod.outlook.com (2603:10b6:8:1f8::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Tue, 27 Jan 2026 13:41:01 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9542.015; Tue, 27 Jan 2026 13: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: d38d457c-fb85-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lM6Qin7izs7C1av7EMsuO9v5HuD31VnE9umJGftPcg9i0ojNZ7oVvw7yb1mVw7+/PhkGSnL6hw9VJPakE9a3z621lDxQ3etc5SU0i8PCN+4hJtf0tioEFekMol60OT29LvN71GSlZTfyMd/0ONtEjxp7sUxs8AnHb6qDuWWApWYasqsMlcKx+fuBvSrNXlKwGCMq8aX7cwrKXWCi7SZECLsvLB/w+bjXjjGOpaxXh83NR8HaMD5V/GWeczLzuPEKDGisYKPVOyVmL83j0MNS9W9/1jXkKdhErFtdezPP1VqnBHOj1mmf3dO6ud2wt/Ig8TKTxCuBvCZGxJ1xb8BBRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KaGYI9vUVbUl6w20gDTaN24Ga25f72VI737q9fQIulg=; b=uyFDyVZoxgmCTBmkQ8NODoGlRAYJikv9kBEUKjQ9rpHOht+iTkQbmCIwRDaBkBCkfbn7p3/mVmBn/d4h0w/EC14InKjM4KzBy9T23qUwZucmrSLI27ENpMuLkseBD4+HmLubnCzEktHTUWQd+MaPq9R5khJsSJeL5pa0Vk2so5dYIzLwWncix8ZP0udKrdCbl0ro7VV4vSSOfIz9CPzBJl3Xyp5CMR0xVUah2anoqBll4Z/CDkRjO+bk5QlPYdkOT1oBmVy9ePu7YUWdN3SfXuW873fKpsqpE1SgH+5CP9DturXE5MmxWoCcwJhYovs61pUBS16RJM11lesy37E27w== 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=KaGYI9vUVbUl6w20gDTaN24Ga25f72VI737q9fQIulg=; b=UDYTdJLUhxNPh1XfUPCXMDqTAlLo99NuEl9e907odJMZQ5NN51byR9/T0L+Rx2McEYF/bij4qw5T/TggYNfU0BzB82g/QfcxzuCnaZ3rgxuuYwu434yTUFqJpGC9ulJTVjsK51h0tQU/4dYlGm+mfpxGIWrN08W/xUSUIIHjuBo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Tue, 27 Jan 2026 13:40:58 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel Subject: Re: [PATCH v2] x86/ucode: Adjust parse_ucode() to match other list handling To: Jan Beulich References: <20251215153245.2675388-1-andrew.cooper3@citrix.com> <2a661e47-78f1-4569-9ed9-b4c3e62af646@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <2a661e47-78f1-4569-9ed9-b4c3e62af646@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LNXP265CA0035.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5c::23) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS0PR03MB7655:EE_ X-MS-Office365-Filtering-Correlation-Id: f9cfad9a-0952-413b-2936-08de5da9b5c5 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?OVlZRXpiT1JnOWpOMFB2OFJrTThRS0ZEQ0dWYWZMUjJsK3ZGY0N5a0VjbkZX?= =?utf-8?B?WXdnTEh1ZGN0OWpvUWc4Z1JnWEhBU3JwNTNIZGI5WG5iR3VxM3Z4aUVENlJa?= =?utf-8?B?dDRJYlpsekVEclF0dWR6Wkp6SGE5dkE2N0pSR3VkNHhoTDVZOXIwWnRCV251?= =?utf-8?B?MWQvS1BsRVZmUEJuelRXU09PN3V3QTJmNitvODBRZnFXY2ZsZmpJYUU1TktT?= =?utf-8?B?R0Z2RTVUMitlVlI4azFraG9HZVl5WXJBNWwxREJ1SVQxN3ZRd2kyZ05hSS9t?= =?utf-8?B?RnFXekErZ0g1N0xFajZGdjJLbXNDaVBZZEdmYTdqNEtBbXJDTDJ2UjFRakg5?= =?utf-8?B?K2IrUnV3NVNiQis2Z01YM3RVbjhpQ3lrTTRXcEdhbjlWa0VGLy9qb1pxSDM4?= =?utf-8?B?cVcySkN3NUQ1djMvY0FhRFl2Y0Y2RmFQZUh4QTBOc1gvS2w5Y0R5SzEwODJn?= =?utf-8?B?SG9XNCtCeHlVQXNoMHNzYlZjbnZyWk83U2svTTZwdnhaaWIwR2dTeCtvYkdm?= =?utf-8?B?NnJhbi9WWEZPWStZSlVFTWtzaW9Sd3ZXaFYxUWR1VWpGZDJOV1I3Z1BjN3FM?= =?utf-8?B?K3ZubzJkYlZ3VDIrMmMxbi9mQ1F5c3lEbmtyNE8zQ3FJQVhTUFB5UjB4MEpV?= =?utf-8?B?eTYwclM4c3NWc2p6a1JsRy90WmZpZ28vZHg0dUhrcjhUNUZZTlQ5cU8rZU5y?= =?utf-8?B?NU1PQmdmN2NiRW9ZUUF2SlhrY243QmxmRmMvS05SeVhzNjErOWhudHJkQ1Ew?= =?utf-8?B?SUdFanRoRTlmOVVWTmdLQXU3UUx1OGk5bGlQSWNXZVM1Qkd2cTRpY2xVMThF?= =?utf-8?B?YWNvaDJ6VDF2L2h3dzhuS2svbFdJZnRJTUs3cnpNU0lNZEtpeDVxcmJ3b21q?= =?utf-8?B?U201Tzg4NmJIdlV5S2p1N2F0SXorOFBGV0ZGM0xFVXdYRldHc1hDRkQ5OE5D?= =?utf-8?B?Vjh0aCtnYkNZQmRYV2lFbTJLQ1kraXRzVDRzMEZkVlB5ejBqUS82WFViQnpj?= =?utf-8?B?cGNaUGxFUEFVZ21OdUswcXhzOVYxN1M4cGR0N05JbHJYb3BZdk14NEFBaXlO?= =?utf-8?B?WDZQYytTQ3NQcHJ5R1NjK0s4L1B5dlR6Ly80dGYzaG0wMlAzMklPUHdFaWhh?= =?utf-8?B?MzNmcEZjYnZNSEJMUUdQNmNYa2JuclZnNjFzQjFwK3hPOStqVCsxVVk1UlIw?= =?utf-8?B?NEg5NEJEU2F4Ni8wUHBIcVMrMmdJM0M0WHY5UGg1L2hJYTJXZW4yaXh6Y3ZU?= =?utf-8?B?eGxJL3FxeDc0NXdmQ00vWCtLYjByYVh4SVV6aFU1S29xTmVjWVZrZmE2am5s?= =?utf-8?B?UWFJRG5taVJpSnhxS0VOb3hsaDFVaDN0em9CTHR0YnVvVnc2a2RVcEhhWFBr?= =?utf-8?B?Ynk1d0RNMXlpU0RpNnVRZ1gvTkxNSDdZb3QzR3B5NnE2VmVKclU1dzJhZG9V?= =?utf-8?B?QmQyZzJLNWpaa2VrbEg1dnk5eXlhNEhzNlRSNGhzY2V4eEludVpHSmtWS0Zx?= =?utf-8?B?c01TWWtFV0Zreks3VTREeUJCR25PVnNBZHNZcGVsMEdaczNYRDQrWjNyQU10?= =?utf-8?B?WThBWUV6cFcxMFdWeDNVQVJDaXJucEE4ZnF4a01yM0taWTVEcXUvTGxhbzFO?= =?utf-8?B?VWRMcU1MdHdDb2Z5QUVoUnRVVWhSa2xqMFNtbFFXWis1c041R2l2K1g5YW5E?= =?utf-8?B?a2I2NU11dHNPL1d4RUljaExsK0ZtaS9ST1pEWlhpWmMvemhQdWdkSnRnMjNQ?= =?utf-8?B?WW9oTEM3TnBJUTlFLzhlUVFpV2hQdkQvTWpOY0p0eXd3c3l2OC93Z1VrL2li?= =?utf-8?B?WktLUTVkd0F2dXBycGgvempLcHpLbW9qTEZmQ3JZNzlGcEFSTkxVZmsySTR1?= =?utf-8?B?amRIYTNMTWx0dFhERVZ2SjN3T3VxQ3BReWQxMkdNeFJ4M09KTVBERjA3MjJs?= =?utf-8?B?TnVVZTdqNlQ5Z2pxbzljRW1qZDBUWkpIa25hZU8xT2dCMUVmZldCK1VKSEsx?= =?utf-8?B?Yk9nUjVsSEF1ZTJOaFczNXVYdVdrUmNLd2UxS2djaFNFM0ljdjc3UHQzbVhp?= =?utf-8?B?WHlpeEw1dTQ3R3F2Q2dyZU9neVpRb25zc1VPL2t5SVhmZmdHYndtcmpNaEx6?= =?utf-8?Q?FpiI=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NkVFTmpQeEFmSHFibG5BMlpHcDdsQzZzSEtLOTlua2xWVVlnYjlVdFY3eUFr?= =?utf-8?B?eWhab0NLNTdkN0R0eUsrMU5JUFBzQzIxNGpKVWw5aGdGRjZvd2JPS3cySzU0?= =?utf-8?B?MUtpQUxlZVVDR2p3cmZYYWZzNU14Ni8zQzNoSzBpWnduekdtWW05Z3NvVENP?= =?utf-8?B?TlV2d1h0V0d2ZXpwTzgyeTdiQ3Y5TkliYWxCZGZwTjRSWDIvSTdwWml1Zldj?= =?utf-8?B?dWdEWWN5YjRXbnVPMkl6aldIYWZqTkFYSmUwdEIrTVUrOXZlS1Frb3Q2TUlT?= =?utf-8?B?Wm41SEpGN0J3V3lGelFWVWZXRHhDNWJVblM0VlA0aDYvZnpBc2p6L3RpNldV?= =?utf-8?B?dlN4M2Q5VWRPRHo3TnF4TUNmSEVUMmNQVkc2WDYzeStxWjJNMkwyL3A1emFY?= =?utf-8?B?cGdwMmd4ZmNWTzBZUUphU1Iwc0R5alVkZEZCdFlWWUd6dFFvWm5YdDJRVmhp?= =?utf-8?B?ZGF0LzNldnhpK1ZxTCt0cVlOd3VTTTFrdi9RWjhWVjd3Lzh0M2RXOHJ6WGRF?= =?utf-8?B?a21zQzBmcHNvTndVYmI4Z1lBU1pmUUNoUXhjZ3c2MElIVWIrbzEyQ0xVcmRD?= =?utf-8?B?QlZ3ZVloUUtKK3BDczNRaXE4U3c3YzBKME96aW9Qc0ptRHRvUmF6QVI2a2JF?= =?utf-8?B?MG5ubUV4VUZHNFdlblVaNDBKY2w0TENNQ0NuamRXU2FFWUdUWkIvZFNkNG1Z?= =?utf-8?B?aGtWVHk2aTVNNGVMamR0dDB2dFpUZ3owWWJPRkdtbng0Sk5QN0N1YXh4S0hw?= =?utf-8?B?N0l2NjY2QlVPbTgrVE05QWZBai9yam4rVnM1cHZzTW56MWFsWCtGUzhBTExL?= =?utf-8?B?Q3M2TnJ3SHlNY0hVL05DVHlXTDlwL3c1b0FNMWRxTVdSaTRXZnBWcXdqZDhH?= =?utf-8?B?NlI2c1Y4MldSakFpM1NGNHFjSGk0QTdXbTNCUXBDbUEvbGNheTRRVE4yUWRU?= =?utf-8?B?RGVYeGVaaHFBRDA2c1JkbE1iTkdIdy9qYTNyK3puZFhDVk5PZVhaZkZSdEg1?= =?utf-8?B?bGlvSmlMQm9QUU1INnltK1lubUR4cXovdTBhcEpWUklsS0xCQzFLQ09rK0Jt?= =?utf-8?B?Z3AxWXRSOVpudzY4K0Z0RVFIVHRZS2J4WmpDRmJZdjEvbXBVNkErdnVhTHNy?= =?utf-8?B?VVBVZjRvK3AvUSswUG0zaGhoaVZuZHVRMHJLekxybWRER200RmZkSW0xcEZ0?= =?utf-8?B?ZjE1RE9BWUpybXZZQnZIUG42MVFDZ1czMnJVVlNoWUk4SURuVzF1cTVSaVNl?= =?utf-8?B?SGR1VVZSM3pBd04wZTd6SzM3b1VlUTZ5VG1vRTc2K2hQV0N0czVkVENLZm1y?= =?utf-8?B?cXo5ZkpoeWZzR0VyQUlTTXBqSUl4QzRuUTc0SEdHRGdFV01jZ1VpWVBOZ3dW?= =?utf-8?B?VisyaHdlNDBNa3R1cUxYTTN2aU91cmlXUHF4bGVDYjlCT1I4Y3k4Q2tUTWZX?= =?utf-8?B?L2M3ckIvNytndEdlZ1cycHM5UmJWaXF6cTRYOGhYRW5nMWd6N3hOUVFURyt1?= =?utf-8?B?UTRXWWVFTXpXSGUra0FYNzV2eUxGTFZqU2hYYU0rOXQxSkR2aEpLQzJhUG8w?= =?utf-8?B?cWhLMFVkdWtLcXNMRHpsRU9RejRpV1M2OWdjM0JJU3V1S1grN2tPVUF0RnJp?= =?utf-8?B?bUU0ZFhONXB6U3cxa1FwVnJqMWFQZTVMWHpxMXN3M1RjOUVvelU5YUFjVitm?= =?utf-8?B?ZnZpdU1XeVh2ZzRxWHJucHRQb1FlenI0VTErOW9Kc2FiN253dVNSNHFSZU5h?= =?utf-8?B?T3NEZldEUG9JS3RNOW5KdEdSRXMzVCtqK1VEVDJFYkNtclU2L1NyWUFiZVRV?= =?utf-8?B?K0tnb0U3bTJVRjB5Q1FabXFwaStSZFpaQmxyb3M3Z1VxSkFZNmNtMkZJOS9x?= =?utf-8?B?RmZXN2U5TERPZmI5alVlcGF6N0NEUGVKcCs3eDV0cnZFUUQ4TUs3MlYzQ3JV?= =?utf-8?B?dkc2QWt6NXJVR0E2L0lBZzlSNHBCU3YxNkhEeWFyeFNTaHA4U0o1b0U3K2RZ?= =?utf-8?B?WTF3K0lJTlMzQWRHSGVjMDdKTFpjVzRkbzRQRkxodktFanVwR1ZYdVFaSTkz?= =?utf-8?B?T2VYUHpXdEU2N2tKaTlmMXp6bDdMVzRkSmRDYVp5V1JaRExpYmhjT3RpeFdm?= =?utf-8?B?elVkWGJmVTd1a2s2WmE4ZmRyR04xTzRpeUl3ekdHSjZXb0JoQ0JNdzhKOExD?= =?utf-8?B?R3pBblc1SmNFekszelRrRTJiVGVkT2JtS2tpV1J1Qm5PSnhTbmxKYkU4THN6?= =?utf-8?B?V203dGZDMS9vQ3o5YnNSaVNWbkxERG5RbHVpRk1PQUlCOXNmNGg2Z04vd2dh?= =?utf-8?B?bHEzSSswdVAwSTdKdjJzUmlKcEY4dVYvb0hTYzBzNWExbEVxU3Z5UT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: f9cfad9a-0952-413b-2936-08de5da9b5c5 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 13:41:01.4359 (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: Aw5yMtDM0+zhl292yCy/lwPzXJbTPppXHlA15EJ6asX6DzBhC4nnwn4bKE6OEDwIFa58RLQGPkzkh/aI64ieDz2+8JcX3dwt0aOSKAUgl/M= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB7655 On 16/12/2025 7:55 am, Jan Beulich wrote: > On 15.12.2025 18:08, Andrew Cooper wrote: >> On 15/12/2025 5:00 pm, Jan Beulich wrote: >>> On 15.12.2025 16:32, Andrew Cooper wrote: >>>> parse_ucode() is abnormal compared to similar parsing elsewhere in Xen. >>>> >>>> Invert the ucode_mod_forced check with respect to the "scan" and integer >>>> handling, so we can warn the user when we've elected to ignore the parameters, >>>> and yield -EINVAL for any unrecognised list element. >>>> >>>> Rewrite the ucode= command line docs for clarity. >>>> >>>> No practical change. >>>> >>>> Signed-off-by: Andrew Cooper >>> Acked-by: Jan Beulich >>> albeit I'm not quite happy with ... >>> >>>> --- a/docs/misc/xen-command-line.pandoc >>>> +++ b/docs/misc/xen-command-line.pandoc >>>> @@ -2752,34 +2752,52 @@ performance. >>>> Alternatively, selecting `tsx=1` will re-enable TSX at the users own risk. >>>> >>>> ### ucode >>>> -> `= List of [ | scan=, nmi=, digest-check= ]` >>>> +> `= List of [ , scan=, nmi=, digest-check= ]` >>> ... this change when ... >>> >>>> Applicability: x86 >>>> Default: `scan` is selectable via Kconfig, `nmi,digest-check` >>>> >>>> -Controls for CPU microcode loading. For early loading, this parameter can >>>> -specify how and where to find the microcode update blob. For late loading, >>>> -this parameter specifies if the update happens within a NMI handler. >>>> - >>>> -'integer' specifies the CPU microcode update blob module index. When positive, >>>> -this specifies the n-th module (in the GrUB entry, zero based) to be used >>>> -for updating CPU micrcode. When negative, counting starts at the end of >>>> -the modules in the GrUB entry (so with the blob commonly being last, >>>> -one could specify `ucode=-1`). Note that the value of zero is not valid >>>> -here (entry zero, i.e. the first module, is always the Dom0 kernel >>>> -image). Note further that use of this option has an unspecified effect >>>> -when used with xen.efi (there the concept of modules doesn't exist, and >>>> -the blob gets specified via the `ucode=` config file/section >>>> -entry; see [EFI configuration file description](efi.html)). >>>> - >>>> -'scan' instructs the hypervisor to scan the multiboot images for an cpio >>>> -image that contains microcode. Depending on the platform the blob with the >>>> -microcode in the cpio name space must be: >>>> - - on Intel: kernel/x86/microcode/GenuineIntel.bin >>>> - - on AMD : kernel/x86/microcode/AuthenticAMD.bin >>>> -When using xen.efi, the `ucode=` config file setting takes >>>> -precedence over `scan`. The default value for `scan` is set with >>>> -`CONFIG_UCODE_SCAN_DEFAULT`. >>>> +Controls for CPU microcode loading. >>>> + >>>> +In order to load microcode at boot, Xen needs to find a suitable update >>>> +amongst the modules provided by the bootloader. Two kinds of microcode update >>>> +are supported: >>>> + >>>> + 1. Raw microcode containers. The format of the container is CPU vendor >>>> + specific. >>>> + >>>> + 2. CPIO archive. This is Linux's preferred mechanism, and involves having >>>> + the raw containers expressed as files >>>> + (e.g. `kernel/x86/microcode/{GenuineIntel,AuthenticAMD}.bin`) in a CPIO >>>> + archive, typically prepended to the initrd. >>>> + >>>> +The `` and `scan=` options are mutually exclusive and select >>>> +between these two options. Further restrictions exist for booting xen.efi >>>> +(see below). >>> ... then you say verbally that the two are exclusive of one another. That's >>> what the | there was intended to indicate. IOW I would prefer that line to >>> be left alone, but I'm not intending to insist. >> You said that last time around, but it's still not how the parsing works. >> >> ucode=1,1,1,scan,scan,scan,2 is legal.  The latest takes priority and >> cancels prior selections. >> >> The reality is that | used in this context is meaningless when there's a >> comma separated loop around the whole thing. >> >> If you don't like "mutually exclusive", what else do you suggest? > I'm happy with mutually exclusive. What I said I don't like is the dropping > of the |, expressing the same "mutually exclusive" in a non-verbal way. Imo > those short forms aren't supposed to describe how parsing works, but how the > options are intended to be used. The documentation needs to describe how it is, not how one wants it to be. Anyway, this is long overdue (and needs another rebase over Alejandro's recent work), so I'm going to get it committed. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 27 13:51:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 13:51:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214764.1525000 (Exim 4.92) (envelope-from ) id 1vkjTe-0000oJ-Nz; Tue, 27 Jan 2026 13:51:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214764.1525000; Tue, 27 Jan 2026 13: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 1vkjTe-0000oC-L7; Tue, 27 Jan 2026 13:51:30 +0000 Received: by outflank-mailman (input) for mailman id 1214764; Tue, 27 Jan 2026 13: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 1vkjTd-0000o6-7E for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 13:51:29 +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 46dcd1cd-fb87-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 14:51:27 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-48069a48629so6832415e9.0 for ; Tue, 27 Jan 2026 05:51:27 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066bfb59asm57903085e9.7.2026.01.27.05.51.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 05:51:27 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 46dcd1cd-fb87-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769521887; x=1770126687; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=istqqe0rEvWv+HUvgB7VDvo1joVXj7+I9uV3orz/9A0=; b=gz3xsmiABxelRrtIU/+MHTPdWH3af4VWVx+udTD0FnMRd1yF304IAV4qq/+JZpkjZp 65hdDLTjMJcqzbm0gFD8irALAZaZ/it+zxpWfPJkma8cAzUqctwzJyo9lTIoPMUL5jgG SgifL8JVqEnwtHellkJ6GQDW+WilSZ2g5NuISOxMAOpeDkOoEVTq2BYWyiGKkXZFugge FOWtlD6x8ZNHbeFyOFc5tcJEjtLycSi70/9BQrfVJ9UBN3Ex58VnTezbwXEmjkco6OHY Fh4/a4hhjMy2Y7/7wRZNS3HiD0m5zvMtBuufWqlSLMDDGcm6e6dhNlF2v8qEvOdk5dGi EEbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769521887; x=1770126687; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=istqqe0rEvWv+HUvgB7VDvo1joVXj7+I9uV3orz/9A0=; b=EpjhckzoUI+eHffhSKuC+HCp1ksAfyUfyviHW8Zuf3I/GDdpBgwqkj/JyjxsFQIG3q YIR9OybGNEYTE6Oc2QgZCgRCYAguZfaaIO0pi3oQYLlm+QlhOqemhBiLVORz/ISbHBmv sAfYZ7uSY397ebnKHVmdtu0ErlUSg8ndaboFh+SbzJrgv1I/XfVp7yMlgczb0pPv529/ Hjwzi2M4qBDUrhzygqrXW41gXQFE742NxkXYfaJfUEUtTaDyGeNNsadYAqEO0H/KhuJH M+woWvcTpzHxSdXaddLsibvra68vUzNsfhr32g5sePANR5PA8MDnHeVP54QS323XzufB ETRQ== X-Forwarded-Encrypted: i=1; AJvYcCVV27tU8KV6uAFkvM4YfkOv+3mBoF0UqoSTnY6UJmrwMGugdE76EIsJGTpXe11SkWTtGhZjc++S42M=@lists.xenproject.org X-Gm-Message-State: AOJu0YwKsqaVMZcHszRPxXOThzU2rt+EpOvRwq7263Uf4ziv3cMVFFME o7iNNlsSiPrZ3q/lpW1Axghp/wdi+flhxFIB8wi8kxvpvv1jgaxKv40x73OOHf/kfA== X-Gm-Gg: AZuq6aKfui58eo4wquzv7MgFmqN6x8HkTJsui2+HXivvN3TKQqgK4sfkFliZ+J6uqBS z8+NeOfxAvDM+9foE8MX4f2zvdR0NXc9qzCwIEN//cYcNNTna5aymi+3eOAAYXNCclmt+uPyt+s syEkvemirmBb7R/APpsw8A0WmiCcCtwYoaE6vJuIHh5NMmeaRY6sl4Tu44zPg9tHcoN+W/qWnG1 8ziP+aVO6VQ+B+WFCVVtI62WX4Y9m3MvaNPxBCD1QLFYbXkoVtHITeFdG0z4bmSVJnbZ2mGE2yX mnBqVnxPL/gIqdTVWPXJcdx67xLB7m4K6X6kEVLXZdaxHofnzTbuTqa7HhOWLdssugDX5PfFPYm hjpkJKKlqxYoywQL/iHmF2lhgTv8R1zcUfQ0Vl61l4iatCv9bDSo6p3dk/FStZamK9CGmp2Up+2 vmdbBr6+9s1mPgeNWAU3JY1YdKIsLsmvh7OcAxcrwzxVlwkurdJ7bgnAM90kzGA5rnOsJmIjxke Js= X-Received: by 2002:a05:600c:3105:b0:480:3a72:5238 with SMTP id 5b1f17b1804b1-48069c6098bmr25741335e9.30.1769521887240; Tue, 27 Jan 2026 05:51:27 -0800 (PST) Message-ID: <73799a9d-9834-4019-90bf-caf91ad0069f@suse.com> Date: Tue, 27 Jan 2026 14:51:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 04/16] x86/cpu: Fold generic_identify() into its single caller To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-5-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260126175345.2078371-5-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.01.2026 18:53, Andrew Cooper wrote: > This makes the correctness of future changes more obvious. > > No functional change. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich Especially with the way the diff is presented, could I talk you into ... > --- a/xen/arch/x86/cpu/common.c > +++ b/xen/arch/x86/cpu/common.c > @@ -455,10 +455,13 @@ void reset_cpuinfo(struct cpuinfo_x86 *c, bool keep_basic) > CPU_DATA_INIT((*c)); > } > > -static void generic_identify(struct cpuinfo_x86 *c) > +void identify_cpu(struct cpuinfo_x86 *c) > { > uint64_t val; > u32 eax, ebx, ecx, edx, tmp; > + int i; ... taking the opportunity and make this unsigned int? Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 14:00:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 14:00:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214776.1525010 (Exim 4.92) (envelope-from ) id 1vkjbr-0001kb-Fc; Tue, 27 Jan 2026 13:59:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214776.1525010; Tue, 27 Jan 2026 13:59:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkjbr-0001kU-Ch; Tue, 27 Jan 2026 13:59:59 +0000 Received: by outflank-mailman (input) for mailman id 1214776; Tue, 27 Jan 2026 13:59: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 1vkjbp-0001kO-KV for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 13:59:57 +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 75f1d2a2-fb88-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 14:59:56 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-4801bc32725so44742805e9.0 for ; Tue, 27 Jan 2026 05:59:56 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1f744e2sm40473770f8f.31.2026.01.27.05.59.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 05:59:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 75f1d2a2-fb88-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769522396; x=1770127196; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=ECr5gIFOw6tKLOP8lUOxXmcWlWMzqPIaypmampr2ycI=; b=R2VKSP5McWz0VKC3343cegnEP8etEDoY4pBHRPowJ1FYxgqwN3rI7jZKWKekMvI9hG b8Nu/2IsOvIFk4DWSYMy3f63cWSSiSmq1izhQ0EvgV3wa8JSvCEm6exmSisoW6F/BRWm CQh/z7WiLtxvelX4CxpJD8aYtpowEIYhTOAuuQSI4IZ/xt5dlvOQ3fK/E1lWw7Ugr23b o44H/UB6aXhE7VY8kjyUGfhcG3s2MG7YvZkSw7CEYQe8u6qAoGrnhgCU+aBJJTLeR8w5 wWzcyFcHu4bNCTiKgKTznxHVtPx9xKE3BsWipWIQp6yf/Z96merHQpKkx5hCQUbhsVnr D+og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769522396; x=1770127196; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ECr5gIFOw6tKLOP8lUOxXmcWlWMzqPIaypmampr2ycI=; b=JiyyHabg4o0g9KtzG2JvadoUgGM1jqIYlHOODGJVdUL/Jd2pepPx1SELfbhgjTZy6E SS1arV+9SsEr0vpGqTX/pd+QvQLBU9K2yX72UsVUiy668iU3gt7KVTMwSBgcB/DI2/46 0F5q31HyhH1fjUpP/oIvVkW2S6RBhr9yFQ3DjYsY3tL3Nt2PZV+29WcsozZ3nR+oSsY7 BZGMBUsqE7xrhXhMtoAp1lbwdfXS61T3isHy8bvD+wrSuLaQgrPoaSE+paG41+XbENoI ldeaTpjhN9gIddYtP1klI51mnN+blNv/J+medIEvb6cpjzHYR0d4gZRB8TgCwAfg5qOB ujQg== X-Forwarded-Encrypted: i=1; AJvYcCWjo4YcXtySRZUyAwzW8E+dcJ+6idTy/ibo+3U3ouTk2EN14HgmpM7gGWMPu9iu2GsP8nB5hmCca/I=@lists.xenproject.org X-Gm-Message-State: AOJu0YzDjcNFHVCoIKibyKt75g+kLCJZaswYVcQ/wnWJhU2NQhJRbsVe xgXgZsKKRXU9XT56m5cMWHPaMRHHnH5Em+Q5VZjKlg75Rkj1rxKvkrlUkYHnsuZaTw== X-Gm-Gg: AZuq6aK6uH94hwwmLChABAPhQ5Zt/ygTuQxXny758cE9Zu7Vt2PH6Fg0azcqPS2/wRK EGZ3v7GmSWOHCMzIxgqkqe2u67djhrfFPBPooxp/VUxLD7VYBEMWNlrksidm7efw+/chGer/dmN w1pJCfkdW/wZTSXDz63vwNAkLHZk0ADWD0k2YTwQeUR8nfmHcwywMj1MpvSHVYHgKLFInECMsC2 N16rGvz6CEMl6zeDobi9juHv9RhpdJsrTj8s9f2Zkssb+EOzsPaz8gajrHLIL/Blb8tVibVuCO3 iRjYhllPy2zraeaTQMdHmjOKWVEMvbXbHZIGcr8ZhH41rOS1eVwA+AsD22iSOQcnm2D8FhZ5eEJ 3hXpTM/bEzZd/BF2X5AgvPLF4y21vQV/+eSEcSvah8XzBd3BqyNeGdpdzdrUrBjUpf33NGD6s4/ k3DscF9lcMZZSKmZZs1g0mJfbhjcmyVjrPtM0Ri+Kq0k84IL2IPnh30EAX59smofl/5IirlH3GF FQ= X-Received: by 2002:a05:600c:6092:b0:47d:586e:2fea with SMTP id 5b1f17b1804b1-48069c3a7abmr25541555e9.15.1769522395677; Tue, 27 Jan 2026 05:59:55 -0800 (PST) Message-ID: Date: Tue, 27 Jan 2026 14:59:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 05/16] x86/cpu: Move per-CPU actions out of the vendor early_init() hook To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-6-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260126175345.2078371-6-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.01.2026 18:53, Andrew Cooper wrote: > cpu_dev.c_early_init() and .c_init() is a spilt we inherited from Linux. > > In Xen, these are called moments apart in identify_cpu(). The only logic > between the two calls is filling part of c->x86_capability[] and collecting > the the long model name. > > We are going to want to repurpose .c_early_init() somewhat, so move the logic > wanting running on all CPUs to the .c_init() hook, which is only marginally > later. > > No functional change. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Tue Jan 27 14:01:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 14:01:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214783.1525021 (Exim 4.92) (envelope-from ) id 1vkjde-0003Ic-Rq; Tue, 27 Jan 2026 14:01:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214783.1525021; Tue, 27 Jan 2026 14: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 1vkjde-0003IV-Nx; Tue, 27 Jan 2026 14:01:50 +0000 Received: by outflank-mailman (input) for mailman id 1214783; Tue, 27 Jan 2026 14:01: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 1vkjdc-0003IG-M7 for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 14:01:48 +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 b7ef5d24-fb88-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 15:01:47 +0100 (CET) Received: from AS4P195CA0016.EURP195.PROD.OUTLOOK.COM (2603:10a6:20b:5d6::18) by PA6PR08MB10418.eurprd08.prod.outlook.com (2603:10a6:102:3d1::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Tue, 27 Jan 2026 14:01:42 +0000 Received: from AM4PEPF00027A69.eurprd04.prod.outlook.com (2603:10a6:20b:5d6:cafe::a0) by AS4P195CA0016.outlook.office365.com (2603:10a6:20b:5d6::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.7 via Frontend Transport; Tue, 27 Jan 2026 14:01:42 +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.9564.3 via Frontend Transport; Tue, 27 Jan 2026 14:01:42 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by PAWPR08MB11509.eurprd08.prod.outlook.com (2603:10a6:102:511::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Tue, 27 Jan 2026 14:00:39 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%4]) with mapi id 15.20.9542.010; Tue, 27 Jan 2026 14:00: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: b7ef5d24-fb88-11f0-b15f-2bf370ae4941 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=rWr2mCl+9LdaPa8uE+5ie+Pv2EacU1r41ERCRxkXMBRMHaBIvAvyvt68qh0+K5E4v6wzki78wQQMQpjDHLf0LI4Hc0/qPnISwBKBblRMVHQ24QTwyrUVYOu1LTxJ22+8Dp0zYBpu7TT2IHjOtFG4L2/c7K4A/fFweQWzEh5Mfr4CkQyUHrCy1tBYzu/35svz4YRWsxBJI9kWpveuB4cNKFUvriGM6L0N9cnH6ExnOqoSFXjNyDcEZFn9e80CFUcpKRm2P78gEfY1R8VRbyXJrq0PFRA0N0du1i7x4DO32tW+fjONVpIA1HV4o/SdxUwcqi2wPTeXU07Ud8NoKUgdNw== 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=weFona43iV+J1iIrlwI0PW5uaaDDpRv69765wIOH06Q=; b=o8u2CR8IkVv6v+B7Jg5vw9GRLZjVzSmMzUzuZUPaoqkFFIPiptK/oho4nG1/AzWSwChCis5zu9GrKivEjhhb1zbYELnOGdFOhShHbh4VYaejt3sFrGAEN3jbBDZZ7e0GlTdZWpDgLaFjg84GvUX9H8uA91TDUyFSwPmKqiLzyaL+h/s1n5CFL8g0jY4dQaWXG7svzpgoST+tykeGaQM2vXTGOmwZgUYM2rXAPxP+7/TI2KbXOMg+1S3Dc6nNIiEV1JJcYSgwCU1HOVnZhhzdKSfhyFLWpf0a+SI0AcsPy/cvWlmhTMop5Fbh3gj7l/3WYOogS1F3SsmiE4k2TCfoZQ== 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=weFona43iV+J1iIrlwI0PW5uaaDDpRv69765wIOH06Q=; b=EP9dGLBnytpNOdoTpsmYmG+O7iF8IVizXO8oLxnyQAJBKiztr+JcAzWmT4xnvWE99AQUzElqLx3jOfP/i76zWBd1CQ/EN+cHGDUlac3ARCnOIUEKqZVcug0xvjUD+KPOTuvM1p0St7Ug8fmdmjgns/ed+uc6LI7BQ6LN53Ngkaw= 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=fzTl+BcFy7lgwQGvzBI72CmTUsNv7UFsiPrvJwo08gNNWNb5mO8Zu+pei8rkNeh3QVw+O9jsnqnEDflIYpk6boJh+VAuat6QLf0AcKi0g6gmTAOfH2XTqJkXzSNGd7TR6y/8wxO9VF5v6xk+071Tg3BkU/7MwxpIM76dp8Sc3KsDYGShCt5uPNof6RPJweX5WrwPI1RlAGc4DRS2RTNi9cjlrhl5YIfUZD+9dh1djtfWpeD0I6ePFTCbkiBcV0Ur3I2Ed0+MlwgEcYoIjtGcEgDLVraxkwMmD0mvW7Zsn2UsqEatgL5Yi1hYK9uKNvR/QyCRX9vvSS63hS5Ejzs+xQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=weFona43iV+J1iIrlwI0PW5uaaDDpRv69765wIOH06Q=; b=lmCBwMhfk3IuUYwaY7NhIsV+ifSUjyNOlkkfJsdoNdXu7AXJX564gtNfjt8hJCNcgsQo5/mRBi6jZbC0x/byityB3rrRIcdxeZDLERvVTarDlhKEtdV6/tlC7UxvM9kVVTYbUKcOpYRqUIX5JbDSbsqsuo6KPzf6jlwyyQ4025D6PqN9UJHpzLbvNvKSdh6JQFSkiBAbHRq1EXHzVA2Rtv+J64TFcGTZSMq5tPg32hAcA1NRmZp8kgh9pPKyp5EnWf8jwMjP7RjixlTfUxBjaiMJzr6g9H00m7V2dYEkDDq7s7xGl2Yie/37Iuzn2juFsM3JSQNeyeEAp2LnsueXLQ== 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=weFona43iV+J1iIrlwI0PW5uaaDDpRv69765wIOH06Q=; b=EP9dGLBnytpNOdoTpsmYmG+O7iF8IVizXO8oLxnyQAJBKiztr+JcAzWmT4xnvWE99AQUzElqLx3jOfP/i76zWBd1CQ/EN+cHGDUlac3ARCnOIUEKqZVcug0xvjUD+KPOTuvM1p0St7Ug8fmdmjgns/ed+uc6LI7BQ6LN53Ngkaw= From: Bertrand Marquis To: Michal Orzel CC: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Jan Beulich Subject: Re: [PATCH] xen/arm: Kconfig: Fix XEN_START_ADDRESS input prompt Thread-Topic: [PATCH] xen/arm: Kconfig: Fix XEN_START_ADDRESS input prompt Thread-Index: AQHcj4+kgpoWJ67J0EutgEYhfeUIgrVmC3eA Date: Tue, 27 Jan 2026 14:00:39 +0000 Message-ID: References: <20260127131923.123294-1-michal.orzel@amd.com> In-Reply-To: <20260127131923.123294-1-michal.orzel@amd.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.300.41.1.7) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|PAWPR08MB11509:EE_|AM4PEPF00027A69:EE_|PA6PR08MB10418:EE_ X-MS-Office365-Filtering-Correlation-Id: ca202f3d-481c-4ecb-ba6b-08de5dac9982 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?EGmGgkeN82ivOwKVMuOZ/2s8icQDnyBfouTW3IsjhGNd1lMZYpunIWh2S3nW?= =?us-ascii?Q?HjV7zpvYMAC9LWYhumQbwBrb5E1dcorIBS5Gc1CAdv86noshYMt3/Zbgugt7?= =?us-ascii?Q?P+11E/Y9NSAnVBuXE4DpLJCW0vuWKDLptgjyW4hghE4Xu7e6p9QN2dRdSqtl?= =?us-ascii?Q?4JNtEbDdD+S5rxiPzz2t2tR4EPa1dDkC8xFQk6zL59waN7f3OneAW7kqx1C/?= =?us-ascii?Q?0I09T0aop+hXj+7gvJPH5w5UaJ3ojCUVzSufWlEW6aO29Nt+aNWGWscl3eU2?= =?us-ascii?Q?l4wIhiXhf3DhDM6sSRzcQ2Nikb6sFsvNYFA99hpFOSkgUuOy369L0gzjtA4k?= =?us-ascii?Q?u62DjhAG5qssjizWpwb32ywEqsG4Uv137pk2kHalOy/gsxfBAvEu8xHEKHQA?= =?us-ascii?Q?Izcj7rPCvL8nJYcQXprxldNiKGqy4EnsXDgeRy81bCqbxIYX1iT8z/p/r3mS?= =?us-ascii?Q?OyOwA0A/bstOIz46UkzQLqYIzhdn5zvynZ9ZtOIo/9C1SxclEHz4FnK8dTIy?= =?us-ascii?Q?poQpBKjVQWN2II/EtPpjL9qP2AOUqtAYm+cwRfcfhqLkXZYzr/cBqjTIFOmz?= =?us-ascii?Q?NGT8Li/DoemlmCP8zAqkObnkCVUvRK8XVMgPMj9b99fzPviQLMwvKYs6xLTz?= =?us-ascii?Q?UNIE4sX9vm+lSVy5XLAWqDl6Mk9x17c/cC0St0l16INgv2THm8w8wDEbdfcx?= =?us-ascii?Q?kn8ditD332U/thkXx0q8DaEWO1g6wMlv8oE6zA+Q/Q4V+M+ZSckpuk9BuVad?= =?us-ascii?Q?I3tBxnLRzzoKZrpYqh9KTguQppubZCNnaUeW5kfXu0hqHjSGVGIoSfLl+h2b?= =?us-ascii?Q?LfU1laT98IrrHCOlV7FrgkW5hAmrXV4O7qu+8G+tXQhKSgEbJUaabR6siNaK?= =?us-ascii?Q?tJ5hA7xsWOdojprZ8jSZcUxnYTrVG5toR1VrzXmEA/NWsEb3lERXZL+BwAIu?= =?us-ascii?Q?wc78z3GwvR+tOFy0qDwlehgJVZA2nsoC5GtXdFPUmjQIVW+6bW22/4qR1aON?= =?us-ascii?Q?OjY4C8mrCXNUvb8t1CSYkqTMy92rU9dr1GeF4+8JURiTyloOSspMr41ll3wm?= =?us-ascii?Q?7fzX7OlfgBxY1XuILHXIVJPy/vEHBBf/re5wxNOQJI3fkZBhEgOrFDx2l6Ho?= =?us-ascii?Q?EcGUyqgDDN4h0pJXRi80HOTNcao59gKh/i+pQL8i4+FAvkd8JPZD1q6MQAER?= =?us-ascii?Q?VahKi8nPSy8/X621jbtVziDmIVo2p2w/icIPti49uuPPST/OqKXqxis9oNFp?= =?us-ascii?Q?8O4i6bBXVrYBIwNHAoZwo7HnTyYnmD4DAHm5OwpcXTcf8fs+jZhCiUtwRkBl?= =?us-ascii?Q?KRnpbKvZgB3eQRrYnkL8xHE6ipJOFKIzmi8KIpkKCYQm4zYgiv+bF87mUaSK?= =?us-ascii?Q?SnUSmgL6z4F5AdsP/kEti+VW21e3x8lirJEKfE4rahNCue6lmcY0PMUWdMrM?= =?us-ascii?Q?StmRH3hxAfVmwjDA+/n2jxEnes42HpAulmJWzbDfHUFC3NBcp1GV+4QsNf/2?= =?us-ascii?Q?b3M1dvV04weykcr2V93Qq6yMEqTJD1arJ3EkX3Q1fodFeTE9h7oLItr6sv4C?= =?us-ascii?Q?yRF2o91/iLQEOQjTIJkYHnVE8cpZK1wZYLLrr5/khJuYsSQVqzg3d/frUlXk?= =?us-ascii?Q?6sNYK7THf4jMz9jBs//ZcdI=3D?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: <7688162A02CB6642BCC048C469E1D13E@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB11509 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM4PEPF00027A69.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: afc08645-b8dc-42a2-da14-08de5dac7424 X-Microsoft-Antispam: BCL:0;ARA:13230040|35042699022|36860700013|376014|1800799024|82310400026|14060799003|7053199007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?Ec9EDvclq9tuDFMDTCeqF/WerYv9mxDd+ReB2Lnrx/qR5nxH3btvPnda8xPX?= =?us-ascii?Q?HFEAYHpB6Pxcy8LegTa7uP5tY4rU8i7bb4RV4MRaxWfifAm95DaJ2q+kqWEH?= =?us-ascii?Q?ZyrFEmFMmLfG/VZvQgp9e3FfiUGHYwBGL9AKAJbpi/ErOHYTt2EsSYlFtmDA?= =?us-ascii?Q?SVeoVzJZHmChAqLsZJB2ITlKHZv/lme1OceSyq1VWUOzJJ/4t6GT1Rej0vGL?= =?us-ascii?Q?rz5hWDa3zYKdxnzDqZqAHPUwThaaeEP/hGnWzDe813EFXvn9ITVJvAyCQm2I?= =?us-ascii?Q?pYKRydwad3ziGaiEaPF/qrjgQhrbOaaygNFgcYmKqzqMSRS6/iXBVOZ/ZLNB?= =?us-ascii?Q?aApKiuOxZc4FiQUxI1ws+m2AX4ZSoYuhurGZaCLMkBwX3i/P1tzoa3rLp8V3?= =?us-ascii?Q?6CNFPLN7Ktoch/tD4oZE+6AXd/PhqDqbalRLLfrjj1ktwGt/KC45+O2JDAMw?= =?us-ascii?Q?WZUUEXq5D9GSa2+8cddeQbUDvs0QjOXR8OhGCt1FFfEp9enxmrHqpQUT/n5K?= =?us-ascii?Q?BK2ylbDU/klbKrdYVABS0kQQY6qKGDZZA4FIuI2lswwGTq8BOmkrSco3p84D?= =?us-ascii?Q?SSeDPHgm2DdHDRauUSfJGjbrF2ESEM+9pIB0aPjGuUszriXMavXuuWMEYYXs?= =?us-ascii?Q?YA3+kbkEcLmT3kmJUfYW3ymRUgKJPkIdIQssRXBjLRjj2Jm8Ds1pn7JMsGx3?= =?us-ascii?Q?YQHbX9pH56DiHnDpu6QVQTdWBtRha5c8txRGULGe5ZEg6uruA3XzVQtykO4o?= =?us-ascii?Q?c1161fxrt9oIIomrYsfpTPAh2lVB9RXxV+0EP2wz7xSCL8oAqvplbM6VwwxR?= =?us-ascii?Q?22Trq0DByeNukUdy1sxQDSYqd7jL8AXxqaDnUUzOltSm1/bw31fgypFDNovG?= =?us-ascii?Q?gAM1xPKEbJPll5V9959tT+t7ZuCCb6Zo8hqn/y7STZmYREU/Cls9ft0kpfuD?= =?us-ascii?Q?Vl86t9v8hcLCuskM4OtLXx0J8+mgeDiZoBKuAEE2zHHKyLbYRKimxDQ5Dtd1?= =?us-ascii?Q?FkugNaEfOEHENS0v26VlqrCJS+XqPnk7CbbzcBgScGsmjr0/q+QlGM0D+KSa?= =?us-ascii?Q?UIbBgvE3dvZ4I3rDhVMhiDII2RbDBU9v65R847V1T+KXZNJW0UmXnEcuZ/Eu?= =?us-ascii?Q?/Pz2wz/vvO+UAGF06aUlDMcc9CLr6Bu9HHgSC3KZSidyG6IMiQmC7tWjgdbW?= =?us-ascii?Q?UDFbphkxZYT8FIFnNodUYbbDf7rUlYdAAivMWKk9ewmIEVIPXB1rJwI7qWzU?= =?us-ascii?Q?RSc32UPcKnGhAP3Jb+e3CYnxKkhjkN2rTCOGd6pHBgas/Gyf9XdYqHiehs+1?= =?us-ascii?Q?bQzr6kIZmaKKz7lpT8uHvCBjexjpyO1Eg+WXZ7w63Gt2XcVLZrWUx2kcMeEK?= =?us-ascii?Q?32Efn+RN+FYH61r+X9lB4VxdCmhLM0J0VmN45m0nBukhxQ0c3EnZ8tWpZI1V?= =?us-ascii?Q?e7sFzSFB+s/KKqiDtbmzXTJ9UyLMoGvlOPPtYSIb681LlOmFnCGeCpJXiKfq?= =?us-ascii?Q?LcW53lMCpIsOZk+GG5usZ9XH0IkLlQDBPiYcbOiI8KonPjUb69h+4SXAeR9U?= =?us-ascii?Q?BFAiuORGUO7v7ZPyXXHfJZLVwgH6P6nK29NxEGnbsfKBgj1VsXIz4OESYBuI?= =?us-ascii?Q?PYwlR6ebRVUtZInI+1jiNSvTTeHkANsonZZtOJlqUJZVhGwPsSeh5OPRuHMG?= =?us-ascii?Q?7wNTew=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)(35042699022)(36860700013)(376014)(1800799024)(82310400026)(14060799003)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 14:01:42.3525 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ca202f3d-481c-4ecb-ba6b-08de5dac9982 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: PA6PR08MB10418 > On 27 Jan 2026, at 14:19, Michal Orzel wrote: >=20 > Remove the part about platform defined address which is not true. The > help text is correct i.e. 0xFFFFFFFF is used as default value to indicate > that user has not customized this address. >=20 > Amends: d736b6eb451b ("xen/arm: mpu: Define Xen start address for MPU sys= tems") > Reported-by: Jan Beulich > Signed-off-by: Michal Orzel Acked-by: Bertrand Marquis Cheers > --- > xen/arch/arm/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig > index 442d353b4343..2f2b501fdac4 100644 > --- a/xen/arch/arm/Kconfig > +++ b/xen/arch/arm/Kconfig > @@ -28,7 +28,7 @@ config ARCH_DEFCONFIG > default "arch/arm/configs/arm64_defconfig" if ARM_64 >=20 > config XEN_START_ADDRESS > - hex "Xen start address: keep default to use platform defined address" > + hex "Xen start address" > default 0xFFFFFFFF > depends on MPU > help > --=20 > 2.43.0 >=20 From xen-devel-bounces@lists.xenproject.org Tue Jan 27 14:02:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 14:02:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214789.1525030 (Exim 4.92) (envelope-from ) id 1vkjeF-0003j0-2b; Tue, 27 Jan 2026 14:02:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214789.1525030; Tue, 27 Jan 2026 14:02:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkjeE-0003it-WC; Tue, 27 Jan 2026 14:02:27 +0000 Received: by outflank-mailman (input) for mailman id 1214789; Tue, 27 Jan 2026 14:02:25 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkjeD-0003IG-T1 for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 14:02:25 +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 cea2a17a-fb88-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 15:02:25 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-47ee76e8656so83799405e9.0 for ; Tue, 27 Jan 2026 06:02:25 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804f5ad4c1sm124498335e9.12.2026.01.27.06.02.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 06:02:23 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cea2a17a-fb88-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769522544; x=1770127344; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=wdkgSk9yEOQzPLgkJHl7ghgyYgN3oMtlla+2s5yxm3M=; b=JoWsImr7eRwMuRJG6ZfSIstFoW2Ih7V5LEv+VU2hojKV4eGHypal8XcvO+qCRvUgSh bqSQg3y+jIIO1iA9Q8vu5FH3RvN9zLvD8eJi0PqTvM2Y7CRzztzet3ceibfKpAOu/12q 7VIhFlC5KF9/U1ObeQi1MQSNePUXk+kCI81Y6cIybpQ1FLMBWxYa+4OZk9A2BFarFXwC Dj4c/pG+RWrU1OvjarqtturZSeWkMiHFyuPQd26EcdGeIfuliABl6OELrrYbOcw/AmzN gcoC0q9DplEiHCMw8LupIprM+fwlD2nhbINQOhZDbUj5QJxE3zk5hR1eHJ0KvMemrfsp xxww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769522544; x=1770127344; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=wdkgSk9yEOQzPLgkJHl7ghgyYgN3oMtlla+2s5yxm3M=; b=vu410/SzN0xZqhVWI14Vtj8WZmUhTpclLQ8O6m5uN7bMilIRaseFZK2C05ZA3PUt1K Yj218u/Bg3p0R76qgHp/4pyHBafRMLxiKFfoFre8nGofFGY4udmbyp57C7LeB7WhXmzW ji/pOIiSmD/XJwBPrg9PpMRSmzxYwVoRgla+Pl8dzGMWNh1u9v2OLUm1hj+hBbBCPfWs g1Pe9w7BSmSQ4osiG1Le1+Q3vFI+tdB2nmDYrRraYEojTvY6Uc8NyPze/NxDzNxBSR5Q CUTDeZkq2O2lkxXwan9ZQiKBeZFPylTkTmyRcK3VwiZls0PNZ8UPv9MMzUIrecxMz2hQ v0qQ== X-Forwarded-Encrypted: i=1; AJvYcCV/c5WQtKz8oqVvkPX40i6p5xqXWRPfddlVS39YInsd885w3quwG8GpoI2XAU48ZGrcEDLkoLqHdpc=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx+4T+Zr/sOYJOjQVttRPTFiXvaSUyhaOxAuUbylGQlPdxvV0LI Y55OZFdJ10kkSFuHbshzp7SKmw22qTAALl7DrrHmRsjhrtWua9Df6m0d1/aw75SOuQ== X-Gm-Gg: AZuq6aI81xXoFKJtuFV+FA8860RrY6rp1zaMXyhF+m4mhjYnKnlmEmH8f2OKcTKZ2Vi 7xeoPdylIgksl8liyEg0c+3rcPZu4jx7qvK6T3hL563GanclSlsnlSyGDdvNX++TUGtleo6Jq0q cNDPv7xkrnR96YpLnR1yJakDG+rdwprm4bolOVlUE5692H4AMP5oA5DlM3KFrWQl2ArtsSftraE E/Y4WCR52zKcR7FII/8noUUP8etQz+4Us7GSTwnEzJYO9OhgBt/Us3+ika6TUw7u2xsfrW+EPH+ 72WUKLcBa/DAr3MMiF8kqm3LNHnUaAsRQTDQ5b+bies/dr5kA1nJCLfcTqMxLqC6UDra4sgUyXx zlaWkkSPS7gx0IOZ6tmYUhuNIbD2Hsiu9nqdwgTGyQ8ZStmppuYAd9WN3xPLQMhZ4pxf7ScFm/T Kzn4lcIbz21JUottruUcNliDYvq+bC+ryqEkngQbwUYO8MAA/gv/0P152VP2ejyeECznor93NHV 6Q= X-Received: by 2002:a05:600c:8b24:b0:477:5c58:3d42 with SMTP id 5b1f17b1804b1-48069c20e88mr27034135e9.10.1769522544447; Tue, 27 Jan 2026 06:02:24 -0800 (PST) Message-ID: Date: Tue, 27 Jan 2026 15:02:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 04/16] x86/cpu: Fold generic_identify() into its single caller To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-5-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260126175345.2078371-5-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.01.2026 18:53, Andrew Cooper wrote: > --- a/xen/arch/x86/cpu/common.c > +++ b/xen/arch/x86/cpu/common.c > @@ -455,10 +455,13 @@ void reset_cpuinfo(struct cpuinfo_x86 *c, bool keep_basic) > CPU_DATA_INIT((*c)); > } > > -static void generic_identify(struct cpuinfo_x86 *c) > +void identify_cpu(struct cpuinfo_x86 *c) > { > uint64_t val; > u32 eax, ebx, ecx, edx, tmp; > + int i; > + > + reset_cpuinfo(c, false); > > /* Get vendor name */ > cpuid(0, &c->cpuid_level, &ebx, &ecx, &edx); > @@ -550,17 +553,6 @@ static void generic_identify(struct cpuinfo_x86 *c) > c->x86_capability[FEATURESET_m10Al] = val; > c->x86_capability[FEATURESET_m10Ah] = val >> 32; > } > -} > - > -/* > - * This does the hard work of actually picking apart the CPU stuff... > - */ > -void identify_cpu(struct cpuinfo_x86 *c) > -{ > - int i; > - > - reset_cpuinfo(c, false); > - generic_identify(c); > > #ifdef NOISY_CAPS > printk(KERN_DEBUG "CPU: After vendor identify, caps:"); To aid reducing the gap between the calls of .c_early_init() and .c_init() (that the next patch's description talks about), wouldn't it make sense to also drop this NOISY_CAPS thingy right here? The log message saying "After vendor identify" isn't quite accurate anyway. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 14:04:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 14:04:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214805.1525041 (Exim 4.92) (envelope-from ) id 1vkjgV-0004TB-Gp; Tue, 27 Jan 2026 14:04:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214805.1525041; Tue, 27 Jan 2026 14:04:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkjgV-0004T4-E1; Tue, 27 Jan 2026 14:04:47 +0000 Received: by outflank-mailman (input) for mailman id 1214805; Tue, 27 Jan 2026 14:04:45 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkjgT-0004Sy-TR for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 14:04:45 +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 2150480f-fb89-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 15:04:44 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MW4PR03MB6966.namprd03.prod.outlook.com (2603:10b6:303:1a5::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Tue, 27 Jan 2026 14:04:38 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9542.015; Tue, 27 Jan 2026 14:04:38 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2150480f-fb89-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=eEkJXWCJsw2ss8GOVZlgUUmfBYKAJAwI41kR0ACPz9ftTapN43n0YNtLF0+BSr7GSSGhrJg4Ht9rWejY62gwaFGdZ5nVYW92rlQjs0JezJbgGrv8QKe+csTeTYQ9FWqWR13RxIQEX8SYeqYnmYGOC4bgI9GW1OvpxNsoa/3DZ/rgTUpKhEADs5yxO74HJ+w6WJvNBLOLvOxISMytfGi1l765LJuUUYPn46EwoxXuzPq7SzbqpfWGF7NF6Y6E+bg0GSVH2wuZR6dXGFi1ePrJNLndCJ6nFLVYZxSb3m6ugOWN8FgIrdMDTh+uaw0kJ3c6ZDM1rXKlGAv24TbL0JaAVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=O5uVsejvK52uyQj8vzA/mu0K23jA4iJO19U6rJZ955k=; b=F9h7UdStkKFYu6rpJiDIoBq00O5lMWKOnkwp4YAKWmw/Ae5iQccXTpIh6BrlULLL99A6RPAULBII9XNzq7AgxxarocPpDtVxjkyjldQz7vj5xbhwUcYX6Ge45S3jqsC96EwbPeHnYvP126Du6c5jQSm5qvWgaTA2Ed3jMMYEe4hl+rVkacUjAMX3QSwSBVKXQb6KqKnysUbMrnpqpteOaFz2nzlAMRWdsX7xxU11Kyz3cK4cZ4AuIv/kMD1P5Tq3iracqZzp3qaVz7zirHnOtS9F3JN5N5eRA/4EPL4v5iGlcF9m101wMYjTbcdLS6KPZpZQ+sWNjlXmhRBmxqkb3g== 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=O5uVsejvK52uyQj8vzA/mu0K23jA4iJO19U6rJZ955k=; b=jmdxu113L+x+HNBxePXTwN468Qsj/GMOOqGdVILFreQwt9wAbyACi6oKuwZCOVjErunygqDi5HvDV5SxhVwaKpDNU8rX5J25KYQP52wGtjdibezdsMNYQlkMORHcN5ZK4m3Z+00PY7OjIiUaPS3Z5D5Pm/p/vFFLeEZPDLRIWjY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <26e12738-a7bf-49d8-a7ba-a98e88399c77@citrix.com> Date: Tue, 27 Jan 2026 14:04:34 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel Subject: Re: [PATCH 04/16] x86/cpu: Fold generic_identify() into its single caller To: Jan Beulich References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-5-andrew.cooper3@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0115.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:192::12) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|MW4PR03MB6966:EE_ X-MS-Office365-Filtering-Correlation-Id: 28dbd58b-0aaa-484e-890d-08de5dad0218 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?dHJwRzh5dE4yV2NuVTBEaG5NVW5SZFBmRXVnQ0NnTWlHVDhoY1cwRU5CMmJI?= =?utf-8?B?OTNaQ1Q4NWI4bVFVdXNIYW1LOVpUQy81QXJISjhsR0VJSHRrTTl6dUxoclFF?= =?utf-8?B?a0ptSVZkMnFMRkZ2aE1Cc1NQMlFyOFdxUkJuT3kxTWFwUGlIMXhHS3I1TS9a?= =?utf-8?B?aXFpcC9QamI1MlhJY0JVZDlTdlc3ZUtnTDhrbUNrVjlKQWJWTTlEd1QvYy9u?= =?utf-8?B?VS9jbmExWklTODRORndPSnNyUzdpUzl3OVRnTkoyQ0J6eEI2R2hwcEVETlhM?= =?utf-8?B?dVYwNVVLUmo2Zllnc3lsVy9PdXByQXZmSFEvTktadDBmOW9KbzkvOW4yT1ZW?= =?utf-8?B?QUxGNWhXU1lhSGk4N0V4c1czRVZOeXI0RGlVaGZUazJhMnJSRmFvWkQxOVRa?= =?utf-8?B?Q3lIVVRnR09YbVZ6T0xBeG0wV2gxYW5zb1FuaDJHeVBjTzhPdzVCREpmWXFp?= =?utf-8?B?YmJ4aFlHNy8wZVIrcmE2OEV4Y3I2Y2RkSlNLdGwzeFc4Wk0rVkwwUlc5M2dk?= =?utf-8?B?YmptWWJPYmFnUitRbFpqSVR5Y0NITnA3NlJkQ0Zienp4S3VuSGdSVDBZNGNR?= =?utf-8?B?VkdnQStOTnJQOGhHdm0xdjZ6ZkJJK2hIQ2Z6dmFFeENoOFhERTQwZHJZKzA5?= =?utf-8?B?K01IR2xHZTBPZjRyb0dhcVhGNzdpQlVNeDZmTlFKTDVxQ3lsc2FkU1hVZ1VX?= =?utf-8?B?d1Z3QkVmRzJsZlkrSkdkMHJmZnNac2h5STBXcFYwU29ibWp5ZUp0cHcyU2Ja?= =?utf-8?B?Y0IxRWcrYW5KaEtTRXczSEdiYng0RDdMc2phUjc1U2tCOWtlWkMyWkQvaUpz?= =?utf-8?B?K3RFUlJPOFJZaDk5NU5wSmh3clYrYWlsSzNKRGhhdEl2ai9wWUM4T3JGbkti?= =?utf-8?B?a2JKdHdOUVZaUmY4endSWmNWWmlHN3RxcktLb1YvU3MvNEF5Ykl0QVp4SHA3?= =?utf-8?B?VE43UEVWR25XZW5WS01TMEE1dUlUU29TVnhRR1NJanhZSXNjUHdCc2NjU2tC?= =?utf-8?B?bnBQTkJTazB2MjRQYWQyeUF6TDEyVStnbHNTOXlUY1M3K0lTaXZEZ0RGbkJB?= =?utf-8?B?ZFAxeGYrUFJOVVZnbE85MU5SamE0SkRjczdIS1g0SHY2N2JQRmZXaGtLaFo3?= =?utf-8?B?Q1F4RVdHS2RjSHQ3SkJ6RjhycXA4aGVMTmhMaFNxVXBZYm5NcnQ3d3AvN3Nu?= =?utf-8?B?ZTgxM2RibHFTV3Z4NDRJdnZ3SWxjM3luSm5PZVhud3dZa0pWM3haNVovcm9R?= =?utf-8?B?eENNT2FOQ1d0VnVJSm0rRGVYMEpBODlSVWNmUUQ1cmdibldGM2ZGSXMzTzRJ?= =?utf-8?B?Qmo5bThQdWxYL0hjRjhRN1BLSjR1cTJXRExSSGFFczJvc3B4ZVkzMU9hcVRU?= =?utf-8?B?WjAvNU1QalplV0RUOW0vRm8rcXRZaDV1QUh3R0xheExFanRtSlhDY1hnN1JX?= =?utf-8?B?LzN3UG9ORzBoRXRjZkVpTG5jdkx0NFpmQitJVkM5Qi8vODlvdGRrT05jZG9G?= =?utf-8?B?eWRYVnBOVnRFaVFabzA2bG1Jc3Z4Q1ZNRGxjZ1dkVkNqQjhZTU0xUU40d2Ur?= =?utf-8?B?NGM4cm9YN1ZmZUMvdjVCQ0YyQzBJZDlob242OStBY0RnNStiejh2eXE3aVN0?= =?utf-8?B?QjBJUWxiTUNEekVKMlVweE9KT0hCZVZYa1hPbkpuZFFaUFRkM2lkRExoalNo?= =?utf-8?B?U1lsd2NzK3gxRENwYWpKQkhnNmJSY284OWYrMXVlazJzQWFFRG5uOUNxdk91?= =?utf-8?B?aTdnNHoyVGRla092UUg5cWZpUW1ScGxTM3pkeUV0QlJzQTl3aHYwdjVWNG53?= =?utf-8?B?WXZLTjVFbWJCa21IaS8wdDNBd2xpbnFNVlBUYlVXbG8yUys5aXN6ZURiZ3Ju?= =?utf-8?B?QSsyb2hvNDZnU0hoVFR1Q2hCTjFYekIrYkwzVHRQREJHT2NIdHJPaCtmcFZi?= =?utf-8?B?OHlYcXI3MkRURjFXME9wZWpFVmxNblJ3SUtmZDhFOUlSU1RyRnU2dWZvc05T?= =?utf-8?B?MjJNVi9qVWVLWWpiOFFnK2ZHWjZQMlNETnJqTVBKWHMvdW9xdlAwN2FtWE1p?= =?utf-8?B?Z0J2R0xtdW92dnFUMnNzbFNZN3NadWIxemlFeFZVQjNYbGMxbVJqbzJjUXdQ?= =?utf-8?Q?N3cw=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NlV0STE2djJ1c2EzWkFTWVdLTGU1UmVudVM3MXFSZ2djbnYvVlRmYjI2NlNQ?= =?utf-8?B?QmV3dVlTdFMwa1hwY3ltOXk2NWF6aXYxNkdFTGRuSHZ4MW9BVFJIRnZIOWlh?= =?utf-8?B?N3EyTGpzQVdqa2g1ODhXcmlKWWV0V1pjbHBkaGRFWEVVamhmVWtDcjNxdEhV?= =?utf-8?B?LzgyQ3RnbXBBSnJUUStMbHVBRnZkRmpkYmpTQXhyK1RTTVlYS1NHNklkWThu?= =?utf-8?B?aTU3cFNOOFhzcUF5TkU2RTFETHpVcXJsb3JOS0ZOSWZ0SGhpUnFWR2crT09G?= =?utf-8?B?cllNeWtlK0UyS1JCenBEQUcvQjFmTzJTUTJBaU5IYXZ3THRCSk9OdytIeHJr?= =?utf-8?B?RDVMVXNhSTdrTVBuUzJ0bm02UFA0dVFIS3MrZWhXa3pZSmd5OTJlSGlEZUgx?= =?utf-8?B?VVpQcnJnVHBpeGZqcnNGMWFGTDZJekxIZlN1YTA0RHZYbkhRVDBJcmw1d1cw?= =?utf-8?B?cWxJQXJ6Z1lyeWtmQ3VySXRNbUxUVUM3bnNkcUlTd2RaSHpzNG9TeUMrNmI2?= =?utf-8?B?a3pySElGekwxeXpqZ3NqRUR2djcrbkRWME12TDVKQ1pIZzFFcVV2cTlNNmV5?= =?utf-8?B?VzRPVEpsSTkzOC9jMGVSK01RRTNyTlpNUjhqR1hqaTg3eE1rd09raGZESWJj?= =?utf-8?B?N01Yb2FvdFR3NXBDcFZIUUJQam9rdmx4dlRyQW03ZDd4aEROaFpjTkh4Zk1x?= =?utf-8?B?WUp5Zi95UGM0OTJaVVp6YjlEU0RIY1IyNjM3amhBa1lVdXZ2YzZRcGVtZm5L?= =?utf-8?B?YlJqeE9lcHFVZ1oyT3lSd2IzWEZ6ell4QTlycFIxVVVHdXpVMlZFb0VCcGNC?= =?utf-8?B?YklBOTYrM3NyZHhUaGpNSk1Pbk5XZEdhbUdLd2tiNUIrN2pPTFRZOCtjTUlH?= =?utf-8?B?T09GVDRGbVdkeHBMRXdvTW53UFRaWnQ2NjFaVUZ2S1RqZVdubmUxelhjYlFW?= =?utf-8?B?UHR2UDFsMG9FdFJGaTN6UFMrdXN1UkI3cjA2cUIxUkMyUFRxSFpXNEdxLzBi?= =?utf-8?B?aHVNOVJ0WlBHK2xyWEM2bFl4d3NFM2ZxeXV3OC9DNUhuYWt1UlN5Mk93a1lk?= =?utf-8?B?end3N3B6M0hEUitaUkZpZ095b3E0WnJ2cjN0NDJSNG1mMjNKbkNGSzl6RmFs?= =?utf-8?B?SmIzSVVoQktlaVhETFlJM3puNVpldmhyMzY4N1VRVklvNkg0MEd5cjZjOFgv?= =?utf-8?B?RWhNbWJlMGxhZTZlQzVGcVRkZXpHdnJZazMvSGczQk4wOVlsMjk5bFhMQ2Z0?= =?utf-8?B?QmVnZUlPVzVlZGpMNHhaUEJpRUxPVVgrL2JiYVE3dlNteG9Vdk5QdzdVaUVu?= =?utf-8?B?bXcyUUVxWGdTNzdtUVg3WGVTZzYwYTZrVy9ubEpnZEJscHY3RWJiLzI5VjJ1?= =?utf-8?B?RHZiRzAzNDg4cTBDMjZRVnJZSnZiUWw5T3Z6WWxZNE5vazh4RzJYelVzUy80?= =?utf-8?B?a2dPS3ArQ0NLN0FiNU1reVoxVnpsL3d2RnRtalBNb2plOWQzSFgrQlBiU2w3?= =?utf-8?B?akJ1anEvMURQcFdtYXAyc3g1TWdMR1dSTUdxNk0vVTd5V0lpZzljOElCeE03?= =?utf-8?B?a3RaSEVJS1NjdU9HbVlYOUVJK0dRR2c4THBHaUxnQ09XNnp2Q2J0ZEYvZGFQ?= =?utf-8?B?SnFDaDBQRUJ3Zmxmb0NwZXY2YnNWbktQNG5oMGRGWmQwZlVXMFpRNUlIbHc4?= =?utf-8?B?dmVzMUpJcm5tY1pYcDUzRVNxUW8rQnZBNW9ZemdSZ2E1Y3V1Z3dNMloxQUlw?= =?utf-8?B?d2VGT2xKOHR1MVJCeW0zS2tXcXJyRWFUd1VIRitOMHlFS3ZxU0ZtK3BPdjVM?= =?utf-8?B?QVZMajA1R1dYRGJ6cjdpWmZzUUlBU1RvMFhiTnpZWUMzeHYwZVlBeklKTnh3?= =?utf-8?B?SFI1OUIyd2VuMVd6cEVMNEdiM2lKSmttR1pmL3RBMmluOWtzQWZvYzJNSkFK?= =?utf-8?B?RmlxZGNIWUxxaVR6RklxNUh4a3hqa0pVMHUvOEtERjg2bmJOZFRYUFdWcnJR?= =?utf-8?B?VWI5RE1PcmxyNzBQelpzM2J4RlNZM3VuVFBLaGJPN1BpcWRPVjJDOWE1TmtP?= =?utf-8?B?TzFCTzhTanZXTVRPUnFwRzFlNldPMzFxRWppTzZyanQyNW44ZUsrK0hPOHpE?= =?utf-8?B?S0hlNkd6VW5yM3VUQWIwR3N2V1BQLzdRNm5ReGc2V3lTa25Qbzdha3BpTWdl?= =?utf-8?B?TVdESVNZM01ma01CNk5ZWDFvbjdId3hMdDlHMVFKbDZDOUxGTlg2Zy91dVRF?= =?utf-8?B?RmxUa25kZVJLNkpvcjAwNVZJeklEdzRlcmtIZ21MamdIK0p6QkVUTVJjejZC?= =?utf-8?B?YlppVUxNTEtkdkU4Z2JPSWxMUzZzQUdSSXlQdDVnVHpzL0ltNzlBQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 28dbd58b-0aaa-484e-890d-08de5dad0218 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 14:04:38.0660 (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: kGhM3BM+pjXMfY4DZXInCaT0JgLa6cnRtQaPddL5bP7Ja+/oICzl+V16Qmm+zworkyXp4whGuxsJPH8lrunBDZcBA0xCmWX4kQ8B47F0MP8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR03MB6966 On 27/01/2026 2:02 pm, Jan Beulich wrote: > On 26.01.2026 18:53, Andrew Cooper wrote: >> --- a/xen/arch/x86/cpu/common.c >> +++ b/xen/arch/x86/cpu/common.c >> @@ -455,10 +455,13 @@ void reset_cpuinfo(struct cpuinfo_x86 *c, bool keep_basic) >> CPU_DATA_INIT((*c)); >> } >> >> -static void generic_identify(struct cpuinfo_x86 *c) >> +void identify_cpu(struct cpuinfo_x86 *c) >> { >> uint64_t val; >> u32 eax, ebx, ecx, edx, tmp; >> + int i; >> + >> + reset_cpuinfo(c, false); >> >> /* Get vendor name */ >> cpuid(0, &c->cpuid_level, &ebx, &ecx, &edx); >> @@ -550,17 +553,6 @@ static void generic_identify(struct cpuinfo_x86 *c) >> c->x86_capability[FEATURESET_m10Al] = val; >> c->x86_capability[FEATURESET_m10Ah] = val >> 32; >> } >> -} >> - >> -/* >> - * This does the hard work of actually picking apart the CPU stuff... >> - */ >> -void identify_cpu(struct cpuinfo_x86 *c) >> -{ >> - int i; >> - >> - reset_cpuinfo(c, false); >> - generic_identify(c); >> >> #ifdef NOISY_CAPS >> printk(KERN_DEBUG "CPU: After vendor identify, caps:"); > To aid reducing the gap between the calls of .c_early_init() and .c_init() > (that the next patch's description talks about), wouldn't it make sense to > also drop this NOISY_CAPS thingy right here? The log message saying "After > vendor identify" isn't quite accurate anyway. See patch 13. I put it later because it probably doesn't want backporting, and this might. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 27 14:06:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 14:06:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214814.1525051 (Exim 4.92) (envelope-from ) id 1vkjhk-0004wv-Pq; Tue, 27 Jan 2026 14:06:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214814.1525051; Tue, 27 Jan 2026 14: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 1vkjhk-0004wo-Mz; Tue, 27 Jan 2026 14:06:04 +0000 Received: by outflank-mailman (input) for mailman id 1214814; Tue, 27 Jan 2026 14: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 1vkjhj-0004wf-C3 for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 14:06:03 +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 5029afd6-fb89-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 15:06:02 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-47f3b7ef761so41560685e9.0 for ; Tue, 27 Jan 2026 06:06:02 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066beeaf9sm67002025e9.6.2026.01.27.06.06.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 06:06:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5029afd6-fb89-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769522762; x=1770127562; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=3MkI+kGAAt3Eic2/B2zed/7gnJSWVeLiwL2nZsE1uMw=; b=Lc9mHN+jDvHRAC+WznfELHifUZgJQVlh0AxACKOou2USu4Ow4XNSDmv8bIf/CvBtsO jop8N5YEYFNDbKdafMh7a2JRLTkaqmkuZO9rSHkdN79TiXGVM53qepiu9NJRjgAEc/h0 nN39UkL4ygutoi8DJMk2vWbtVF4wB+B5oii5OdZZBS9Jl6oj/nseaCfHM8a+zbeEIVvq AkoTfnD51uVvraWAHfDGkxENgycmXrAk93EjKTbstHNpQrR5iPTD0+7ibqxGGcuNcgjD GwB/R/hM1CRjimcZlnWyKn00Yo/b+p417dhtDlW4bbUO78WXspaOTEF8XyA1Osy74fhw nTFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769522762; x=1770127562; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3MkI+kGAAt3Eic2/B2zed/7gnJSWVeLiwL2nZsE1uMw=; b=QZBWO8qMwzfOSw4DL5wIHBQMtFMqAh2jj3vseK1QknMxQ2xduTGRRsSCHgzWxH60kI UGTcwCvAHDZ1fCDRFeqLnDWY+9ERYLxqfdL/BLs4o443UpryDVIN8nGVa+9j5IRW6VEq UYpVamkG5tj7hn85tLHu0xkw3zsy9O2F3FIcQIl5YHhou+J03qeN4m4J1082vJ5gRztt ChIdbPwcVQBZifCJko7dtjMUGe7pquUz/NUp9JCd4fAWeeHZ73dAVqhtLuMU1h6qQFvm 1wNCa3oupC/OXKTTNh3pmaLCjbLGe++8IZj98V6vbRwK0Tz5phIb7Mp82EudttsOHRL2 /VoQ== X-Forwarded-Encrypted: i=1; AJvYcCXItofrWjtL4YeTAYOMaSch1SvOmkVNcz9hC3nK4kkJSTud26GoN5KPwmQklNgd4zQk019HRjq2XS4=@lists.xenproject.org X-Gm-Message-State: AOJu0YwnsLcr+H3JEVUEWQgbP/F4XAj4dHl5X5lXm6UeqsB/PeHNuIoe 6UT96WIZ4jNJy7lFGWY1ayj3Vaa5sL3HNdpSJTjqefkzFwxj5dS7D0/xryaxpq91Hw== X-Gm-Gg: AZuq6aJxKoqyk5smzR0s4ye34/QrjnFZQCaXQlpGPx0SL1vnfUxINQwQxQt0O9lTxzi abLgoaIkrN8BfgksTU5Vg2OzVHrsx6M6+eIt0kF6QOiyZ58zZWUn4gd5BlglaFLAUB0kggUnpMU UUjsEut16W8uaKI3Iip4jyuSPjXn9+iawvX+XZxA3ZOc+CkAQW+FN04FfaKtJBbT/G5IY5/f9rd 6FGJDzE+dWvMVLxLIOkXJSgv2v81MpkNVM21mr6+7k32WyLMQDqPNV2dadQ1iYFUjQ0Us4sqUDS kEqK+FL96ZEcjfJvdEQl5kDyRhVSLBjXtrjKArZkr3QTpqImycaAj/7QVGDcmwEv+9+7mZMnJFa egxBTbZ9StRFJ7yj1Ox8pBzPHqmuCmC2VLe4Ycp0lxytJPbm8H3T5uh0Lrx2I9xxPFXbEBVKLJR wCMI6Bx3852VohLAukqlN2QaYpXlDMGNunpPG1lqSLZ/4JA9OvCMMlJ2bTIbfgbRNyVIi28yc10 6I= X-Received: by 2002:a05:600c:35cb:b0:471:700:f281 with SMTP id 5b1f17b1804b1-48069c7c492mr30353985e9.25.1769522761657; Tue, 27 Jan 2026 06:06:01 -0800 (PST) Message-ID: <810d31df-f69d-49ad-bb1a-ece5f3e75049@suse.com> Date: Tue, 27 Jan 2026 15:05:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 06/16] x86/cpu: Rework the vendor early_init() hooks to be __init To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-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: <20260126175345.2078371-7-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.01.2026 18:53, Andrew Cooper wrote: > --- a/xen/arch/x86/cpu/common.c > +++ b/xen/arch/x86/cpu/common.c > @@ -503,8 +503,8 @@ void identify_cpu(struct cpuinfo_x86 *c) > if (c->extended_cpuid_level >= 0x80000021) > c->x86_capability[FEATURESET_e21a] = cpuid_eax(0x80000021); > > - if (actual_cpu.c_early_init) > - alternative_vcall(actual_cpu.c_early_init, c); > + if (c == &boot_cpu_data && actual_cpu.c_early_init) > + alternative_vcall(actual_cpu.c_early_init); Using alternative_vcall() then doesn't make any sense anymore, does it? With it replaced by an ordinary call: Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 14:09:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 14:09:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214825.1525061 (Exim 4.92) (envelope-from ) id 1vkjkp-0005dx-6r; Tue, 27 Jan 2026 14:09:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214825.1525061; Tue, 27 Jan 2026 14:09:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkjkp-0005dq-37; Tue, 27 Jan 2026 14:09:15 +0000 Received: by outflank-mailman (input) for mailman id 1214825; Tue, 27 Jan 2026 14:09:14 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkjkn-0005dk-Vn for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 14:09:13 +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 c0f97f89-fb89-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 15:09:12 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CO1PR03MB7892.namprd03.prod.outlook.com (2603:10b6:303:272::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Tue, 27 Jan 2026 14:09:09 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9542.015; Tue, 27 Jan 2026 14:09: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: c0f97f89-fb89-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jKT2lYtKOUqOQ825r5OJrWQMXu5B73vQbnpLZSjCFMEPb0X/vafNurJd8S6kZJ4QWUfzrNmpPEP32g9bBeOtuKJ1OoIxfd56cj8elWL2lVZUA0eUXhY7ORXtdMBGTdGegb0esF4yLBT+zckkeoOKBUR+o+cBzjZzq0k20aGBsEhD1BBt0lIDPLeLkiwRoZGWbNAs/QE4J1GHjiT9PVwDkcwBLDGpVvuUJTVKRAsBwjCf3rmT0Yt5RqS1d2qqruy/MI6Sv+8AfUJuD7AAugpAQirPInqiwSmbWTPw6HuBlskPnaAoAD8K72jbhD/vnjZuVT7h79536CulXdElyswGyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KZ6YXstgqKr0MaI+J2nsW0kDl/JbWFaXcHrORCE6uFM=; b=iFDq/EJQS48j2tohzEoCzbYcx4KjxyOlYZetK5biSKwJ6NnhLe5371k/v/HPfyVn1xgecfGAjMEaUA9qhHhddwoeFrYOk5MiolVYrXiws2e+YGozhC2Z2nrgbjjRmZQfF7VKMwH2jEjPbMoyanlTpjkQUcx5ddlilqvvHPjIhtFoZ2lBpGznf86VqqNt6r7ffagbcXizLGcbQpFGmFD/KItHmlj2C1RTpPLBU30E+e6RJxVjAS+rPBboJuOQpT0bFsRirIOsDpozgEhOyK7GFG5b77BI0phRqDeKats70oJmyqA8Nwzn/kbiruZN2UD8QkFrnYhHEYUYLs71w/zfJA== 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=KZ6YXstgqKr0MaI+J2nsW0kDl/JbWFaXcHrORCE6uFM=; b=A0iQufw68mE9+wvWsZJ+81LlVgEtD6VzV524M8GK6+8Y8lzOsAs61fbzcerYNh9WLw5i1YgsVrY4LgpuahwoVk5lTA7k111PLX7UPJDc/RHd8s4583UOD0f0ykOe6JwUknvaV7ZHmzYofoGJyKNx6LgbET+Enzm3IfhJmrS7sgg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <15df4e48-1e96-465e-b845-a7b82b630a0b@citrix.com> Date: Tue, 27 Jan 2026 14:09:05 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel Subject: Re: [PATCH 06/16] x86/cpu: Rework the vendor early_init() hooks to be __init To: Jan Beulich References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-7-andrew.cooper3@citrix.com> <810d31df-f69d-49ad-bb1a-ece5f3e75049@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <810d31df-f69d-49ad-bb1a-ece5f3e75049@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0203.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a5::10) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CO1PR03MB7892:EE_ X-MS-Office365-Filtering-Correlation-Id: e44db18f-ec1c-40f2-4e61-08de5dada3c0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?cU1KOThkaU9MSk9JYmcvTFA2Zjl0SmgxTjdXNGlhRTVHTnlZWi9sVFUwMFNL?= =?utf-8?B?aDFpZ1dhMkprQll6Q0pyeUlVaVBTQ0s4bVBWT0F3Y1ZvU0tOQ3ljbEF4b1VB?= =?utf-8?B?WUxNaXdtYnVLVHpXc1cvQzU4c08vVk1FYU5GOWphUGl1bllOL3FrV1BMRmtk?= =?utf-8?B?TkpEYUNuWllWWHgrSXpOd0ZqU1RIRzAyKzR5NUNaWDhHMFhTYlhUdTUycGFS?= =?utf-8?B?ZUpWL3hHdTZxZUVHQjdWUnBZNm5zaVU0bDBJTVFiTGl1MVcxb0JpUjhnY2o4?= =?utf-8?B?V3EyNUg0dk55S0l4NitFL1JBTkFMSVZUWDlUY2wvZTVqVEYxczhFbWxJTzdi?= =?utf-8?B?L3dVejNUaUx5eTNIRXFBaHFJY3BpN3lOSmZQR203SjJSTktyT2ZzRkh1MjVD?= =?utf-8?B?MG5xMDFyOStMcXhLQUptLytkb1BQZ3FQTzgrYWlFM21ycitMNUIwZWFzRTVF?= =?utf-8?B?Zysvb1RldVRJK2d3dkdoTjIxRmJCa3k1clV5amJ1YnkrWU5xZSsyWWJuSVdZ?= =?utf-8?B?bDNwaWpaM0RndVoyN2dJUHY2SnVJd3IveTBTc04rdUFUUkNhY0YxZktNMnRU?= =?utf-8?B?RlJqRXdyVTdIZ1FXUjBwaldac21iYUdKL3M0bkZsa2lWTnhXM3poSXN3ZlEr?= =?utf-8?B?b1JXOWxLK0VzSXBNYVRpeFduL21WU2IyZ3RURXBRbnFJbVRuN3BBVU9MaU1u?= =?utf-8?B?MDRmcVNtVXgvbzJCM0hNaDEvd1FyT3YreC8xUW9oZXI4ajRlVkZ2NXVoWmtk?= =?utf-8?B?ZHlDYklYazl4eWtCZUZiMGorcmV6QXZPbFZZZTdtcmRGUFhRSXhxbGJwUUZ5?= =?utf-8?B?Z2xKaVdIOVJnR3lQdmR5SWVZNVcwTmx4L3gyTSs1SUFjS3JURmhFSnZSTTBV?= =?utf-8?B?ZklraWJ4NVVyTE1ETzJGeGtGSGExSDUzd2N1YWREakU3enFrQmQyWXRlU1Jm?= =?utf-8?B?RDBDaWdNaXNqdWttQTIyQXo5SW9DeVZRN2dib082M1JUR2U3VzRZOEpjOXFL?= =?utf-8?B?aTg2WFV2NXJHZUUwalh4TG1OQzgzaFVBZnY5dkVJL3lqSnJTbEZWNVlOTzNx?= =?utf-8?B?Mnd2YWtQZS9VOGtEUmVlRkMvaTMrSTI2Lyttbit0dXF6THdiWkE2alNaMlJT?= =?utf-8?B?bytnbnNRR2E0dGJWTmtzZ1RPMXMvUE9QN1FYUFFwTCtHVU84ajJKUjV3NWw0?= =?utf-8?B?VmtqSzFNM2M3MVh1WU5JZGJZbGhTNG9pMXZENlZmY2NVNTBkcHhqcWdIMWpm?= =?utf-8?B?bGdqZjBPYXJ3MkxoY0dCZytCMFRBUm05WjhZaVczb21qbzQwM1JDUXpDYU83?= =?utf-8?B?eHUyNzdJVGFlMkVrdFFrTTk5eURxVFZ6Zy8wWEhNMlFtMFlMb1p1Y1NYTGM5?= =?utf-8?B?R3cxdlVHYVRnWEZyakRxekJDUTVqU2p1b2ZTY0ZxRlk2dzVCdExqTzlpZUJq?= =?utf-8?B?c3cvM3JGWEowenNabWoxTDFiS3hSSy9va1RhaEw1bHkyUVhxYUFVMXpjdmFV?= =?utf-8?B?YjdWcTUrbGhvS09UNXZyYlBDK1MwZUlScFNJbWNwcXJIMFZzaUtsL0Vtc0Q3?= =?utf-8?B?YUlYazBaa25pN2YzSnVJNnpyVm9ZU24zV1VCSWhFRTM4SHBSZFAyYytZTnVz?= =?utf-8?B?TGsvdk5nVnlpL3lFZ2JHaTVPK0tUejh5V3BFTHA3S0ltZmxqdFpXdkZPbmtG?= =?utf-8?B?c1VMT3J2L0E1WE1ua3Q4ZXp1M1REYnEvNllVUDcrOEx1dEFNMXZmS0s4VnBV?= =?utf-8?B?SVR4ZkNCOXRXRTBOTGFjaUFoL1VBNm9RNWJuUnJCUjhadDRpQXhGcTh1UWRK?= =?utf-8?B?T0ZQV2R0WkNMN1gzaS9aNmRER1hoUUxucXRvN2RFbWo3ZzRhQjVIandnSk1n?= =?utf-8?B?UE0rbmIxUWVpaWFYUGRySEpab1JEbWpOUFA3NkJCblM2REZBNEVrWGh5S2x1?= =?utf-8?B?dUdQYnQvaXRWdCtlSDh3djVXazJHMnI2R3hrSzkxN1VuZlBKVGRwWHVneHNE?= =?utf-8?B?NVNrZTVkWUxYWC91US9jaHB1MDZ3ZXN5OVZwZ1g5T1M2S0lUUytvUkVsT3By?= =?utf-8?B?S25hTnZ1R05oNEozdmRJbk9VOUU5WVdRUTQ3R0piVW1lNXNSK1IvelEraUJ4?= =?utf-8?Q?VVEQ=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Z3ZYeWlEdVJ3K2EwNk1OVDlhZTVseGdqb25zangrbm5DU2F3MkpXMksrVTdm?= =?utf-8?B?L2pCTFVwQURwOXhRcDZSN3dDb0p4akg2S0FISjZxRFZyT2NFekJxcjBlQWVD?= =?utf-8?B?L3I0Z0VzSUgyQ0NpaVlkMnErTEgyTVFHbW54OVpQdnFwT1VTL2NsUHUvOXBL?= =?utf-8?B?b0FJaTZjcTIreHVia0pLeWhlNUZHS2dXL2hrYkMvV1hCYnR1eW42ZnBseS9F?= =?utf-8?B?dktmc3RkUldRVVU3aHAzTkk1RTZRNzBqejNwTU1Db0RneXgwNWxXTEs2SW1G?= =?utf-8?B?c2tBM2Z3MnF3ZDBGUXd2QXVOdERDZE5iL1l6bVBqRXRBK0tIdU52ZzR3Vk9O?= =?utf-8?B?SVI4U05sK1R6RHFuM3dsc2xFOTdCa1BxRTJIZjMrd3Q0SkpkSmZVYVdBeDZH?= =?utf-8?B?Sm9BcVN4eWZQNjRRMjdpcFFRZ3hXWTFrUGYzWTdhZUswdjhyaCszQWNqbVhq?= =?utf-8?B?TVMydU5HVCtmVlU1VllPRWdmV0NHdjEyM0NzcVd2UDJ5OWJFdWVjL1VtSjBO?= =?utf-8?B?clV0akgwNExqdUwzbTlsemltc2U3M0UxendvNTAxclM0UkhncXFtTmxrNldt?= =?utf-8?B?ejd0aUlVeS9IdWpHbGxTVUVUR0pUVDM4TVowOWFCYjdRV1ZrV0VYcmQ0R1BT?= =?utf-8?B?ZVpvTW53a2EyNG5mMU1xK2JPTzc3UHBZYjNITHVZY1ZzeTR5UlNyUFRkMWtB?= =?utf-8?B?dytKTDNvRjQraWMrYm51ZnpTOUU0UEJxOUxiblMzdUdEWmdkQU1VK0hra1VK?= =?utf-8?B?V0lRSkE4eTQ3ZEovbjBUQy9HbU8yQjREOXlCY3V0SFErWlV2UFZNMnNncTZq?= =?utf-8?B?OHA4dUk3Qy96TzUzb2JjR29aSlduVjRaRWNYOFlCcG1KbjZWVEtRdnFTSTRX?= =?utf-8?B?QWR5c0RrTzhZMWVxdEFrNFNtZEt6U0RJaE5yazI5Q21DcitDK1pjejJZN3pK?= =?utf-8?B?d3owN3RyY002SGU3eFNqVis3REMySndhRElxU0JTYkRuaWc0eHl4dzg3UDRE?= =?utf-8?B?UjBoUlIyTmRGbW5HL1grdHdrekxKZWlBend0cHBvNzNhQUVWaWpGZkp4ZWhh?= =?utf-8?B?RXF5MDZlYml3VEZYK1ZrQWoxYlFrVUJWZnFQMEtFSkdUZmo1anV4S2txOU5M?= =?utf-8?B?Z3FOSzNxREkzd1UxZ0hHYWlYeDlENXBGWTlEKzlOamdScG5GREo1VGVaTVN1?= =?utf-8?B?ZDJlVGo0dkZMSDRya0NyZUdSUnQybXdtR0pUYzF5NzVrWFJRcjJCSFNPK0xM?= =?utf-8?B?Ri9QZFR2bW5nUk0xK1JxSDFuN3dCLzBmVlVDUFlwOWZRQ3p6WitmY2xsM3Rl?= =?utf-8?B?ZDNtZ2Mva25Rb1ZRc3hVZ2dMbzhxWHBqQXJIeld4ai9lWVlldWNjZzhiWDVr?= =?utf-8?B?UGMxMkZXU1o0VGJHeDFxWFAwYThuMTFaUkNLQTdacDc4KzhwREdVaDlaQ0lN?= =?utf-8?B?MXpPUUw5R2R5L1o1QWRKK3hXUDNwdHkvYjQzVTc4S0lnNGsrVTV5ejMwc1pF?= =?utf-8?B?VXo4T3pxMmh1SjNjTWU0bFFYSG50RG1jVjZqVFY0emI1RGg2VFBjMmRzRU1E?= =?utf-8?B?VzMzREFFUHdtcHE3UXlkTDJTQlQ3UVR4YnlnclhtQ1RnWTZBcURRKzB4R25u?= =?utf-8?B?NzQ0WWdqbktIZEx5SG92MnFmR2RPVzByZEpiMGhCWm9LSjlza2w2a3M5Qlpr?= =?utf-8?B?YkJ2SW1uZ25wMmJYMTdjZmtBLzJwaFl2RktKZHM3dzkxMHZ4bzArdFBxQVkv?= =?utf-8?B?Z2hGY2JTaStoS3QyOHJnUyszVUxXbzdUNllUVXhOeWt4S1ZrbDVuWjl2Y29a?= =?utf-8?B?ZjhTekZqcjZCczltNnZlWWp3QlNZdkI2bnh6cDNNQmJ2WUtwVzB5RFFxL0xZ?= =?utf-8?B?dTBRQjh1OVJrUXFxTDI2WEIxaDJCQVQ3UktQeE1kRCtBRTdqNWsvdnJoYnFh?= =?utf-8?B?aVJoZjRQcERyM0tIWlgydExrYXN5ZzlEOGE5N2h1Zk1GQTEvWTQvY0N0NkM5?= =?utf-8?B?bFFINjdJa3NVRGc3RTg2bjB0NFRSWTZEbFY3My91NUdWTWErMmQwSXBNNzZU?= =?utf-8?B?YWIxTnZhWnBOYzN2S09LRzlJUm9zd1hoVVRvR3RwaGFCWFNjb1NiRFFrR3JT?= =?utf-8?B?eURiM0hxU1pSTHc2RXlkTFg2ZjdHa0ZwZ1Q3Mm43U0R2d0hLWmhibElVVmV4?= =?utf-8?B?YXY4SFRJOEFCcm45NGJoQTFJSjN5S2J1RDVlTzFuQUdwdTdqZ0l3QnE1T1hM?= =?utf-8?B?ekdxdTlFUkd5TjhKZEk5eE0weThtREwwREJtbWNpK3RNZWRJeEYvVXZMdTBG?= =?utf-8?B?NzVJTktuMXBuczVJVkJkU3BhOHRaMFBqcnNPby9IV1pHaC85K3l3Zz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: e44db18f-ec1c-40f2-4e61-08de5dada3c0 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 14:09:09.2767 (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: Skfwbim2HJRVngjMT8SET+wPGCdlxnD1+mk1fvy6WxGsl0fjtxbFeAuIvOZPFLtRMvJL7FUxcyEmV7gksJZLGptq+7YAq56LAlZZCG8cfug= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7892 On 27/01/2026 2:05 pm, Jan Beulich wrote: > On 26.01.2026 18:53, Andrew Cooper wrote: >> --- a/xen/arch/x86/cpu/common.c >> +++ b/xen/arch/x86/cpu/common.c >> @@ -503,8 +503,8 @@ void identify_cpu(struct cpuinfo_x86 *c) >> if (c->extended_cpuid_level >= 0x80000021) >> c->x86_capability[FEATURESET_e21a] = cpuid_eax(0x80000021); >> >> - if (actual_cpu.c_early_init) >> - alternative_vcall(actual_cpu.c_early_init, c); >> + if (c == &boot_cpu_data && actual_cpu.c_early_init) >> + alternative_vcall(actual_cpu.c_early_init); > Using alternative_vcall() then doesn't make any sense anymore, does it? It is still needed here, because this is .text and is a Spectre v1 into v2 gadget otherwise. I've dropped alternative_vcall() in patch 7 where it becomes safe to do so. ~Andrew > With it replaced by an ordinary call: > Reviewed-by: Jan Beulich > > Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 14:19:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 14:19:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214843.1525091 (Exim 4.92) (envelope-from ) id 1vkjv6-0007uM-EO; Tue, 27 Jan 2026 14:19:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214843.1525091; Tue, 27 Jan 2026 14: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 1vkjv6-0007uF-Aa; Tue, 27 Jan 2026 14:19:52 +0000 Received: by outflank-mailman (input) for mailman id 1214843; Tue, 27 Jan 2026 14:19: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 1vkjv5-0007u9-Tt for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 14:19:51 +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 3d03b60b-fb8b-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 15:19:49 +0100 (CET) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-430f3ef2d37so4965273f8f.3 for ; Tue, 27 Jan 2026 06:19:49 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1f742d6sm38053756f8f.30.2026.01.27.06.19.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 06:19:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3d03b60b-fb8b-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769523589; x=1770128389; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=3Be56xY6AweT2tQ3v4e+g8TRH9iHTqw9bP+MMcr92Ls=; b=ZdqZLDz231mdIWc8pWCzsxno7DeWLQhJIFofGeUBbNzVR5Bt4b5b9bxJa+7gzuTiHO NgJYfaX1A0nDsCQ7q/71+rAYQo31tOsABsEunAOJeS+Yi61Yw+IAaic448chB3LdqUMg 7xi/jn3w+v9En4IXtrO9BmcSi01LIIkVOw5va9rRE09jT3LUsge2GTJHzeYJmeA+F//e gf++GlDSPzoVwAMMZmbTKR2MkinFiB5iz6nu8glWuVBnnLZbEhF3O8/5kXrJzrbeymfu NyI6wIBAYWXOSvu5PXgeQ3lvkfQcB214tzzscmxhJs/lWmt+n63nVquWAXPYyiF7YFDp yrAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769523589; x=1770128389; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3Be56xY6AweT2tQ3v4e+g8TRH9iHTqw9bP+MMcr92Ls=; b=LjSSPrZwNli5ySDvJLFYnNViJlULrbI7J9Iql/uM4xOcOimK8icT8awRP7uMl5Vgtt JmJ6EJ+UshIO1b/w3+pxxCQKIfJ25wSEWDV1b2wH+xNT7/oe+TJs7j3U9Azxy8dq6nSy KtfSoDsKSWlVttYVsUx5hKwDnpP4CEfgPnXIMOEwiWVAscz8SKPHMr0EWZ6ciewVoBbR 5J8giwy5Y0Oq89e/6VPhZ7+ZSySvnVc/SU4OkKbDFlM98TY6GTv/fkPQdYf8LIvLtVHd FU1lLzEd0Ct49hHHeq95zGafpOj7tt48j9+2EYV/21KNMkI3Fa5B7fBQzUJ+6gIoSOPZ JsFQ== X-Forwarded-Encrypted: i=1; AJvYcCUb9a7NgMjyfvCyPkP64tkmLQ1mpE3AR9Mj35iooaiNGsSk9EZ5FXAz7wqie95B7/tG+Q3FhjYXepI=@lists.xenproject.org X-Gm-Message-State: AOJu0YyTr+iIANkNpHXjho3GdKNmLKUIt1STAFA/N5Ss2aidYpTFmQhe 6YpoaA6EEtzi9Ps32E6YS/TBab0PnkMHz883YVyOOxar6zG6WMcwksv2xOOT2L/CDg== X-Gm-Gg: AZuq6aKzGeAx1GEFjFwKB8T+wWPLEvbZ2rgM+EBJbWb8OxslZPmKoq97Efzcl7Z4gSP npXJ0McPGYNTKuY4BP3ZuQmGd5oWZe1FTD6DV4r9ZD9xk7A9n6XmatjRQlUcWC94kGvYc4pXz5t 3mCAsV4/9DGMB2FcJggjMovVSKcTvbsMBwp9BqphWD5W1fMgN0mBiFnK1dPk/AI9FQJcPcopHnZ sH5AJL1PoNe+Rk31NWclSVKQHORL38HubviZMwEowFuXlLQA/al+Qni3SxfL+LzRPpcC3fEE5jH v8mvqO2nyKdDfqkhYWwobg/CpI1wnVcnPaUEL+UuCXNRWhF5EHia/YKFbCK3RRiAOzTMGlynDoa lXRvdaGVN5T7+ELUj1b/F5Ft4d8SZhznx9bqj1CZeVenoXBOzks3A7ZPvVZ/9vkY4QC2rn6YaSr Z/QSk/x7liir6Y06qMaYsbzqCfcS8QmyMbPFHqHo5BZij7eX7YwBSLAR/hjr9AhjHqE0rBA0fqx Uc= X-Received: by 2002:a05:6000:2c0e:b0:430:fdc8:8bbf with SMTP id ffacd0b85a97d-435dd1d96f0mr2366965f8f.59.1769523588557; Tue, 27 Jan 2026 06:19:48 -0800 (PST) Message-ID: <82258f46-4a65-47b8-87f7-ce548f45a8ce@suse.com> Date: Tue, 27 Jan 2026 15:19:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 07/16] x86/cpu: Call the vendor early_init() hook in early_cpu_init() To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-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: <20260126175345.2078371-8-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.01.2026 18:53, Andrew Cooper wrote: > @@ -433,6 +437,19 @@ void __init early_cpu_init(bool verbose) > paddr_bits -= (ebx >> 6) & 0x3f; > } > > + if (c->extended_cpuid_level >= 0x80000021) > + c->x86_capability[FEATURESET_e21a] = cpuid_eax(0x80000021); > + > + /* > + * Abuse 'verbose' to signal the first pass thought this function. > + * > + * Besides basic vendor, family and model information, the hooks need > + * certain words of x86_capability[] already scanned, as they may take > + * action to cause features to reappear. > + */ > + if (verbose && actual_cpu.c_early_init) > + actual_cpu.c_early_init(); There's one slight issue with this tying to the "first pass" only: early_init_intel() right now calls check_memory_type_self_snoop_errata(), which in turn uses boot_cpu_has(X86_FEATURE_SS). The comment at the 2nd pass call site is /* Rescan CPUID/MSR features, which may have changed after a load. */ That, in principle, can affect any features, i.e. also SS. While for the particular feature it may be pretty unlikely that microcode might make it change, the mere fact that such a feature check is okay to do there may later lead to more such getting added, not realizing that ucode loads then may break things. At the same time I understand that everything else in the *_early_init() really doesn't want doing twice. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 14:21:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 14:21:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214852.1525101 (Exim 4.92) (envelope-from ) id 1vkjwN-0000uz-P5; Tue, 27 Jan 2026 14:21:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214852.1525101; Tue, 27 Jan 2026 14:21: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 1vkjwN-0000ur-LN; Tue, 27 Jan 2026 14:21:11 +0000 Received: by outflank-mailman (input) for mailman id 1214852; Tue, 27 Jan 2026 14:21: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 1vkjwM-0000uj-6D for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 14:21:10 +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 6c838455-fb8b-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 15:21:09 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-47ee76e8656so84099335e9.0 for ; Tue, 27 Jan 2026 06:21:09 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804dbd9436sm130016795e9.18.2026.01.27.06.21.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 06:21:08 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6c838455-fb8b-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769523668; x=1770128468; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=b2Itexq403PRKXPbe1ufhQQv/CiRry8YglRJ+BaEAwQ=; b=La2hh+ALEW6YDywXgCoMAxNBXTyqR09SMxiLFV/q3k+i+FY/eZ+D+vlhmHjL0e7696 s7A/eM2c2lJmx63w6igdOTIwuBxBhxXM+4HcovUB4HsrVFr7eplLLtMKJmdHyqY6+/NZ sxXSZalaYz6izzCdPDYh93WSBwcXEfPE/S7wOLhK3Yeyziw0/JEY5IB5GRjV/iGNR2ny EeJv6r/XnGgvqL8LRIMDa1xSe+DIKEj6zbjNgswKxhpDEuibe5N6Rx8VbHWMfMsKGVS+ RA1X6tVTiFrb5kVt1o1PTcLW/g3v0IwEqhm4unQi+vVUxU8g+8zSbUozahStWM/LY0aN ASew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769523668; x=1770128468; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=b2Itexq403PRKXPbe1ufhQQv/CiRry8YglRJ+BaEAwQ=; b=xN8lXFoeocAmIgGr9POOjG5As3f2wMJ4+84aAs+Syaq7DWPXeSkxUZ8K0saQ/ic91d 2Lkk2195RsQLYGwtPr9NSrQz7YeHbbgWljaI/ICyNpOaBthDuLVMNFMQ2HgEC/uPhfZv pgLxKT1pMUDoO6ILj1F8U93CNjaEvdHTzCngRn4BM3QCNxONMejJPEwdwH1EpRBld3pk LMlf3uDPIGoO/YZa40h1txBA+i5onUnAWLFYHG/T59qCgj7krgXRHQ71+OkxWuKQa1H/ ReKHyXBD5bDgzO6lTPetMmEVpaGN1puQNy7x/1G8om9EqGQRVTcSmUbcHw/CQgqJX/FX HsUg== X-Forwarded-Encrypted: i=1; AJvYcCUz8uI+OO398k5C9hu7qZ0lRfhCn8koStQCTX+A2rjPHudvdYjpd8ZUaVExVLKJS0mMDUZZoCug2RU=@lists.xenproject.org X-Gm-Message-State: AOJu0YxNEZIAlXrPOnsVneE4mrCEQVpwPy49gKFi/JmEZjnRKcuCoceG wSGTletrvbEqTpQs8bQOvoTxf6g1fw36clDeIaBVZCEwtH2yu6H0ccIglDuAWVKVv1COQmEi9Z+ EPv4= X-Gm-Gg: AZuq6aKa5buNsS8P2na11rCwAa4G1aWHxtDP9NyLwGBrczHHe/5BeOGPPrBnpxOVfbn Emi3oWgazCI+YMotAuHNxPPUSQ8BIeeHklztJQlZfN0euxffP3VMYx57SrQ1H8qabv49Ov3MhZS nv8UDtyJsgrr/rely+h5iRpD3qJ6vPWZvbvU7S12IK1sMUI1y3eL/SxsYXiFz0PS9ElXGUdd1vC CTIA9olkHo188dykQizIGhdwXqploScPyFUyil+msXtmARx4BPt7QHe3CfddBg+8VAgnOL5bC3b l0aZAWjsLBqACp+A7oWEMCcl4ntHj1zEZIsDZOr1pqP511ahPibsArDs8FSahXh0SAO7/HcNLKG fvADj0fWv0QzYGZlDeml+nbsNnjdNW7P5ykUoqY65Ea9caysORbfnTIx1C69JRN2mqrR+BlrNOy vMb7urBqBQVMd0wZhDE5z4kTqvYC7JlifpcS36zadJEAS2WfKAMu8RdafChjmXes+5wLSj6SCpW W8= X-Received: by 2002:a05:600c:8b24:b0:477:5c58:3d42 with SMTP id 5b1f17b1804b1-48069c20e88mr27866575e9.10.1769523668322; Tue, 27 Jan 2026 06:21:08 -0800 (PST) Message-ID: Date: Tue, 27 Jan 2026 15:21:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 13/16] x86/cpu: Drop NOISY_CAPS To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-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: <20260126175345.2078371-14-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.01.2026 18:53, Andrew Cooper wrote: > These were plausibly useful for debugging when there were 4 words in > x86_capability[], but it's currently 22 words and growing. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Tue Jan 27 14:28:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 14:28:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214862.1525110 (Exim 4.92) (envelope-from ) id 1vkk3M-00023p-Dm; Tue, 27 Jan 2026 14:28:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214862.1525110; Tue, 27 Jan 2026 14:28: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 1vkk3M-00023i-BA; Tue, 27 Jan 2026 14:28:24 +0000 Received: by outflank-mailman (input) for mailman id 1214862; Tue, 27 Jan 2026 14:28:23 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkk3L-00023c-BO for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 14:28:23 +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 6df395df-fb8c-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 15:28:20 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-47eddddcdcfso33805155e9.1 for ; Tue, 27 Jan 2026 06:28:20 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806b8f45d2sm7724655e9.4.2026.01.27.06.28.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 06:28:19 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6df395df-fb8c-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769524100; x=1770128900; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=tSvswRqtL0GXToKuIVZxB5Gk+Q1t8mtCBU7Pv8Vly78=; b=OHs9qPZc0iKMSw2mvOrc85KujDg0+E8fe6FGTlmTYsJzNLJW6qY6+PRP5Q9muUduvz XFB6Zxtq71o4bUT+ZaDKKcMWMXQutYd8BfcsK/OruEGsVFZuDIHUIhB94tTBXPNXZ41D yZPz5BRwzJWAAJxPSYGZfcdb/nyv77pb4VhOgzgs7kZH8e7i82p3nnJhQHOVgpdHIGai J8ZmMNg3NwzppSliWI/o/dB7wQy/u751CMCflnnzGty5YKggCMBgelZXoUaTSOE+K1qy v2z9XaSwAq/vx7uQrQozCPSq3GGTrOshRJpAfdHqi8spMElMH0f+LYgUmJljJAF5PfHc G+qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769524100; x=1770128900; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=tSvswRqtL0GXToKuIVZxB5Gk+Q1t8mtCBU7Pv8Vly78=; b=Oy3whGzKSWf+7qc/jWUA1CyzJO5SC+hSsNDx6TIJn33AZueM0CGkbR0Km9F+Nl/3cb vcy/VLxUMzrvwMitU+PWWWO7qls2Sd7HJc+nz2fp8ktRv7ByQ3blrXkqafxex7Knfr2D 2CgIiPkIjQd2WADYotJhy4YFXzVQ6TABZRAgjUCwVuX9/e9WeDrfZHpmYr49+t/TwvcL IJcbv1Y+NC6snw8EnV1TKQ6r605OGTpyQ+TcvxwmDyA58ZCrnPlVnxtpJZl18vR6iIji RWLssc0IFWhiODZ/KzfLS9i/l0WxkslbxCTXvp9OSy2CiFPpxExwBXNydKwuN+bUmMKb 9sxw== X-Forwarded-Encrypted: i=1; AJvYcCXjV3TbDfZhJeWYoPpB+Mftvj4RMZ74oyFwKQCGKYt6HoERlX/4+Q4MZ5UG1ihyB6zyLa0EIyov30Y=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx2tZWfjzhI597ZlDZ7xNsYNI7Lg5MqlfR83eTrH+kbLYe9Fnz9 C7ltKfKOJtFLsGJk5sSEfkMaP505VhPkhr/5VcZ3YfF2wGFFS5TGm29gMGQ0sCvh8Q== X-Gm-Gg: AZuq6aKHE34NCuWlZ1g9YS2Vvz3jspxPYX4X1g/CCSrdrkJyGR/y4ysNDssECg4fZAX C0VCtfWoy8aOm3EnpEdOn0fQLolARoOIGnZQe02xKWTzTpoeoJwYBLIgbOwhlDzBLtW6IcVHhod NHICIBts21dY3P5ecZ1wTL+o/p/DPD95o05T1Sq/O0ea3mwrckrwrcNY4W3ZRvI3VEjiFfd04El aT8fhZaQZ44zjxgvP2oBcErqTOttxi+Sf+l281iZnuxGEGFKgxODjBl7Fz9+3aQsANcbbTBAWuG bmKVyV7PGyv/TNRInyfpb5lPnjbDg37TFtJKDDTVIgqV+n3reJNVyx81lILfOCUq+2POsvXk71l oiFLkTZFnncVUoPeI0JIuhzwFwoPeNi55j9HkpZalxKs2q/pAYHgPC1veDO+vQswiWjF4T2sTdp 1Ldmuc+jApPe71dmhELuyeNL7OcdxRguydrmaCCNOJ5B40rV8f5Nm5XlLrZtvnntPU51YZ9zepZ 7M= X-Received: by 2002:a05:600c:a08c:b0:47a:975b:e3e6 with SMTP id 5b1f17b1804b1-48069c540camr24594825e9.18.1769524100199; Tue, 27 Jan 2026 06:28:20 -0800 (PST) Message-ID: Date: Tue, 27 Jan 2026 15:28:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 06/16] x86/cpu: Rework the vendor early_init() hooks to be __init To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-7-andrew.cooper3@citrix.com> <810d31df-f69d-49ad-bb1a-ece5f3e75049@suse.com> <15df4e48-1e96-465e-b845-a7b82b630a0b@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: <15df4e48-1e96-465e-b845-a7b82b630a0b@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 27.01.2026 15:09, Andrew Cooper wrote: > On 27/01/2026 2:05 pm, Jan Beulich wrote: >> On 26.01.2026 18:53, Andrew Cooper wrote: >>> --- a/xen/arch/x86/cpu/common.c >>> +++ b/xen/arch/x86/cpu/common.c >>> @@ -503,8 +503,8 @@ void identify_cpu(struct cpuinfo_x86 *c) >>> if (c->extended_cpuid_level >= 0x80000021) >>> c->x86_capability[FEATURESET_e21a] = cpuid_eax(0x80000021); >>> >>> - if (actual_cpu.c_early_init) >>> - alternative_vcall(actual_cpu.c_early_init, c); >>> + if (c == &boot_cpu_data && actual_cpu.c_early_init) >>> + alternative_vcall(actual_cpu.c_early_init); >> Using alternative_vcall() then doesn't make any sense anymore, does it? > > It is still needed here, because this is .text and is a Spectre v1 into > v2 gadget otherwise. Hmm, I may not fully understand this. Is this because after patching the direct call becomes unsuitable for such a use, especially after .init.text was unmapped? > I've dropped alternative_vcall() in patch 7 where it becomes safe to do so. Yes, I've meanwhile seen that. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 14:35:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 14:35:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214872.1525121 (Exim 4.92) (envelope-from ) id 1vkk9n-0003bT-1P; Tue, 27 Jan 2026 14:35:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214872.1525121; Tue, 27 Jan 2026 14:35:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkk9m-0003bM-V5; Tue, 27 Jan 2026 14:35:02 +0000 Received: by outflank-mailman (input) for mailman id 1214872; Tue, 27 Jan 2026 14: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 1vkk9l-0003bG-FQ for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 14:35: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 5b467e7c-fb8d-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 15:34:59 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-47ee07570deso44617475e9.1 for ; Tue, 27 Jan 2026 06:34:59 -0800 (PST) Received: from localhost.localdomain (host-92-22-18-152.as13285.net. [92.22.18.152]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804d5f422csm137571595e9.2.2026.01.27.06.34.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Jan 2026 06:34:57 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5b467e7c-fb8d-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1769524498; x=1770129298; 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=6jlsuAxDMybtaLr9AI1V7wQPqeY+1qN0TesPdnUkkpM=; b=eUOuFiRV66Fa237ACC5T5ULYmaWS0vzxTaEphSp8tpNuxn6mWZhUQ0aFN4f3pA5x5P NCqEBihaTEqrF/RcmJ0cGHqKkXsxxsMIq3XnQXXaAi12iV1pFdMBqKT/3WicVoqYgM9A dJhBHTgKhKq+fcnt/izhrz5dnto4QoTQFpsy8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769524498; x=1770129298; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6jlsuAxDMybtaLr9AI1V7wQPqeY+1qN0TesPdnUkkpM=; b=ddQsDsoHWs84FV8BLt/Fk8VgB/b98Psrlb3TF4NL4kfKFuo+cB6vuhC+BAftIZdsz7 xcGCH5JLfWDa05xwS+i3FUM4O59pTmlMUTQFrRWJmOPxsP2uYA9IZfYJqiTzgJ/1VWKv qhWpp1YeLoQdNwhvzA+c5yCHcvSKYAKntLL/NrBzdoKuKnvtyYQz33/1/b6ZqlUaktNZ 8RIwqJxRcXOUYGVmeSzZPgN/xtuQOfj9nQBOmlrVhEISey+/Fc2IlDmrAccpXx1BbqW3 fDoLS1SNy2MSG6NBkpJEZ7rfxjLXzPuOrDWwToajuCpVrKeBVnwvFhKMEAqaMeS46Je+ myGg== X-Gm-Message-State: AOJu0Ywmy/inSa6bNhLJBhHhz7n+QxOmik+6vdtwf35tINVeewv1iBhh sSpGuUZih5ZP4m9BxSXKw6Q6FDUldzCaPQw/akHcgcXaU/uRvJbTZD/S0/YQRMxTwew0SC07vwf g0wLe X-Gm-Gg: AZuq6aJBXXQueW3Ut4r7Wpydmiyg1b8amBjv95w/YmLT9FGCP8Eu6BAdeVRYmi+xrRa J5T48BPzuTMT4bEv52QQEQ3p4CBX5G1mlxb1wf+PlhLc55lnSzbA8co05Nt79w5JHqdoZFYtTt+ vepB4P5KWpoBHcSozpf0/fShsgap5XSf5ia64kL310SmldI9qgO1hcs/pwaBce12md9somyylD3 0zxHCuTJF19bQPSa+oLV797xLbqaUn3CoeP041+yGEWmhf6A/Lj/KJWzGAyYs+upo/ESptYBwiL cM8vk4wkgZlFC5PL5HaD+1u8X4gWuCbLevXTaqG31q/JJkBeSWiS4ltapny5G7uAQgJWSKDglns t+qDcnWALHyIXs7N08jcC0lWL8jLay1OFtT/QP6ZrKt9GO8DDK04WJGYZj2FS4Mi/QK7EowubOZ doTrcUNpCTFxntVOYmz8rxrOVI6fZNPi08jdFNA7r7ki+hCXBboL+daB6evVd9szHjlM+f7g== X-Received: by 2002:a05:600c:8b8b:b0:47e:e20e:bbb0 with SMTP id 5b1f17b1804b1-48069c2c15fmr27691825e9.6.1769524498191; Tue, 27 Jan 2026 06:34:58 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH] x86/ucode: Support discrete modules being CPIO archives Date: Tue, 27 Jan 2026 14:34:56 +0000 Message-Id: <20260127143456.2260369-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Teddy Astie RFC. The docs update are rather nasy, and will take longer than I have right now. --- xen/arch/x86/cpu/microcode/core.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c index 55baf7386400..1dbc3749e531 100644 --- a/xen/arch/x86/cpu/microcode/core.c +++ b/xen/arch/x86/cpu/microcode/core.c @@ -760,6 +760,7 @@ static int __init early_microcode_load(struct boot_info *bi) void *data = NULL; size_t size; struct microcode_patch *patch; + struct cpio_data cd; int idx = opt_mod_idx; int rc; @@ -776,7 +777,6 @@ static int __init early_microcode_load(struct boot_info *bi) for ( idx = 0; idx < bi->nr_modules; ++idx ) { const struct boot_module *bm = &bi->mods[idx]; - struct cpio_data cd; /* Search anything unclaimed or likely to be a CPIO archive. */ if ( bm->kind != BOOTMOD_UNKNOWN && bm->kind != BOOTMOD_RAMDISK ) @@ -844,6 +844,18 @@ static int __init early_microcode_load(struct boot_info *bi) idx, size); return -ENODEV; } + + /* + * If this blob appears to be a CPIO archive, try interpreting it as + * one. Otherwise treat it as a raw vendor blob. + */ + cd = find_cpio_data(ucode_ops.cpio_path, data, size); + if ( cd.data ) + { + data = cd.data; + size = cd.size; + } + goto found; } base-commit: 18e255253a5a326deff0ade386e36d7965164533 -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Tue Jan 27 14:46:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 14:46:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214883.1525130 (Exim 4.92) (envelope-from ) id 1vkkKV-0005ZD-Vd; Tue, 27 Jan 2026 14:46:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214883.1525130; Tue, 27 Jan 2026 14:46:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkkKV-0005Z6-T6; Tue, 27 Jan 2026 14:46:07 +0000 Received: by outflank-mailman (input) for mailman id 1214883; Tue, 27 Jan 2026 14:46: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 1vkkKU-0005Z0-Lf for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 14:46:06 +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 e8317336-fb8e-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 15:46:05 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA0PR03MB5545.namprd03.prod.outlook.com (2603:10b6:806:c0::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Tue, 27 Jan 2026 14:46:03 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9542.015; Tue, 27 Jan 2026 14:46: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: e8317336-fb8e-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nat0+8dlE8BEic7qToUg9+wYCPSPtwq26tZ/iJsx7kaGUBpaGcWyH8XQywazrH05UbiEJVWCw6Icyqnk5GKDImTE6t4JA8n3QQ6U5KTPioUXv0ame2xSWEBTNuEUyg86oIjETj4Gp/NBfnvG206heu/ikxZS6B9sruFUHIOGnlAASGkowIm9Gt0kLErEkEDD+S5s3uj7xaIJnjgOdSK8NFOsiIUBEIb4sbKzZOfQBZLXtqed7yEiHTUmDcJdGAMWgMP3RleQAGxK1kmpULw17joBEkPrJLs59hUJubr18xtRTMqFK92jYfyfuDIJ8sVDmqdxkt2Z+TesNFfcGb3a1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Yu8zaKn5GuS/3bthpExxlER8nFf8r8KahI6boM1p2CM=; b=w527hRSZZffJ3gsD5iWKizH6U/e1t84VcirTZ0sefTRCEso+DtiKhok5Sb/MfwhND2u5cOe2mhd4hGoJnq9GCKAqzMT4Z+eKU/0IoWOtlJp26gwSEAegbxvri1l+G1NmTrdj9+V4pZnv+Vu1djOTJ/D9KBOaQbJljhdCUDqh/QJBm5tj5NZwntauxVC7cOxc15ggSlqX01ZRfQ99WmY2tBxoIxvrAFVko3IcehEcWIXgp4B0qKM0bLFG7AOLgW2WQeDbQrsdzo4TzuOTBzI1dNcDDLO6qBmZQ8E44iSUIluafEuWmkFhL0q2BMtiNpJp87HENTNyvszFZKlWOCZ6EQ== 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=Yu8zaKn5GuS/3bthpExxlER8nFf8r8KahI6boM1p2CM=; b=ULH1LvDzZWzkotes2vYObaY0SOspcv3cMPWfBZ7JwCc3Ql4YlKvBPWzwSvaZMsUonbskhi9aapSqpaQlEctpgM5NlfGxMZTYqwX2YEsCsdURcnbS58HatGCd2M9wXSzKBpJHbcjTzR4tB2w/sxKwiVOhRWh7M8A6gvCs4i0z+5s= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Tue, 27 Jan 2026 14:45:59 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie Subject: Re: [PATCH 09/16] x86/intel: Always check MSR_MISC_ENABLE on all CPUs To: Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-10-andrew.cooper3@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260126175345.2078371-10-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P302CA0018.GBRP302.PROD.OUTLOOK.COM (2603:10a6:600:2c1::14) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA0PR03MB5545:EE_ X-MS-Office365-Filtering-Correlation-Id: 304ab24f-35bf-4a3b-51d3-08de5db2cb41 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?aUpGcjdJZEVTRXgzcXAyNGtHWDB6UkF0a3A5TGw4UnlIaklwL04yQ3p6ZEFO?= =?utf-8?B?WGZYQmNLQncvbkhwZHVhR3JXV0NDWmVaRmdMSCtCM1lHWkxQbGlPbnlyUmF2?= =?utf-8?B?c2RnZ0lvcWt3NlBPQ1dhSVd6WnJpNkloYi9TRXBLSkgzMjRjaWdWbUIyOVZa?= =?utf-8?B?eXJjNXJTS3NhVmhoTGdsdm81MWEvcnJoL2dRbHZBd1BZQU80L1JsVHd5TVRB?= =?utf-8?B?TFp4S2t0THpXbDArb2lWVjJDTFNTQ05kVUJrRVNhRFVXcGQ0aXdaUjhpY3c1?= =?utf-8?B?NktBRm1GUGlSRHdZa1YweHo4bmkrYXlER1dWVkkzTVZqM2JXbGlvYzBCR2R1?= =?utf-8?B?MjN2MFpxbUNRL2NWQlgwS20wNFljRnBGM0tXVjFNQTc3bnVlVTAwaXA2a083?= =?utf-8?B?QWJEZzAvUVhzRVlmTEd6Q2l3a3EzTEdoKzRFNEMvTTcrSkMrRTlMbFZHVncx?= =?utf-8?B?Zm4yUWFhTG1ER1I3OXFNcXB1MCtBOXpKV1NjazJibEZ4UkxYUW5sSExmcGR2?= =?utf-8?B?UEpXRTNqU0c1d3hqbG5wSHMvUXhvblNBZG1yMmZuZFVzaUJmaHQ2ZkVDcTQ3?= =?utf-8?B?dDlibUR3UnJ0TlAvK2RHT1FQcGZyTzdzdVNCM2xndkdrc0dhT3dRQ1RqWlZM?= =?utf-8?B?cjZjK3E1NTA1L2poSnFSL0dTejZ6dUgxeThzTEpvbGRLMGxBazhxYlRraXBO?= =?utf-8?B?ZEdqQXFabitIN3JtOG10V2JSYUdZbmE0b2I5OWNLY2VENDMzamtmTTJ5aENj?= =?utf-8?B?Z2dHdUd6OXdTcVREUng1OXAvUWZaZ2wzT1BKZTZpMWZ3cjBEeW53ZFlSVUE0?= =?utf-8?B?Zm5NTGRkR29ZWUkrb01rS0REdzl2c0dQUlFoeXlOcU1lellGRGNCS3U2c2tq?= =?utf-8?B?MlhuampqTGVIZ3FmbTI1SUhPbnBGUUNxMzliTUEwWUN0R0V5emNyYUs5UlJi?= =?utf-8?B?UmNxYnMzcG1ldk5PTjJQZGY3OTM5bE9mMmFJNkt0bEJKZEMweHF1d2dCaWFi?= =?utf-8?B?eEMzaGxuanJoZkhFb2NBcTZkaVMzRmxWSzd5SWpsQnhXSk42VlhOeXl6NHlp?= =?utf-8?B?VSt5clNOSVYwNCtEa0p0OCtIUEpsQ3dvVUdhaTYwS2ZWUUhYbUlhNW1tdzJC?= =?utf-8?B?d2pWNWdaWWdGMXBjZEM2SDN5YVdZS3liek9WN2hzTXNKQUZvQytOQUdla2pF?= =?utf-8?B?Vy9qbmVNc0o3WU1kV1pCSFhZRGpuVEFQRzFQSUJmdXBUYzhadWtWRWozc3RW?= =?utf-8?B?ZG9YL3JBWkdpcy9qYnFVbmJBa2JjbWIxdWtPSVlteWI1emMycEp4dC9GRzM4?= =?utf-8?B?bEpFazdQN3Z1VU9kN0RDek1ocFBmZlY0MWl6YjdhUS91ekpnZTNNRzJ2MGw2?= =?utf-8?B?Q3RBNSs3eXpITzh4V1hDWkhFZngxUmxhOTVYRVR5dGpwbWdZQkcwYVQrMUxi?= =?utf-8?B?UFBIbFJRTTBqRGp6bnJINDVuK1BvVVN3alNjbTlmZmk5TVQrK2tSQkFOM3FT?= =?utf-8?B?NG1RV1luTGU1Ynl1cGdPOWxKckZoeklkdSt1MXl3OUZXWlVBWU5oeG9mT2Mw?= =?utf-8?B?VzBtc0VMMEJIMjhnd3BRVkQxcmNhRnFPcXh0Q1ZzbVBQcTlmKzgrV254R2R1?= =?utf-8?B?OVduYVR4VE5CbXhERk54MFYwSHYzQkJ1eWZTdy9HdzNMZVdlSCtaSGZ2RGJM?= =?utf-8?B?TzdoL2xwLzRvKy9GSWozV3Ywd25JY2lzZ05TTVAzbXJ4VUlyRDhEb1NKSGJh?= =?utf-8?B?WU5jNHI2Lzc1YWY2OUpLUHJJSTQ5eFgxZUZnZzdSZHpvTmlyaTNUNXJTdHo4?= =?utf-8?B?Nk5MUjhiTTZIN3ZRRlZGdElJS1JMLzFZamhpQk9pQ0MxN05nU1JtcmJaOWM4?= =?utf-8?B?cHpFZHhrR0xIUi9qcmtVbTBheVJCNzQ0YmxLbFUrNzFLMDExT3lwV1NNRE9X?= =?utf-8?B?WmgxTGdXWWVuZVFrZWoxNFQzVzRxd3lQL3g5cVlEYTZDWGxqUXJ5Vi9YWEhW?= =?utf-8?B?WndjQS94RFFsdTh0TTVCTndYQmV0VDl5U0VzbHd4V0x4Q01ZK3FldUdJSUVX?= =?utf-8?B?d2VVMWxZdFRDTUIyTDF5VTdVSWpHUE1XQ2hRblk4R2ExeGtCZDRYbVplMkhP?= =?utf-8?Q?nQik=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Z1FtYS92NENmaFdhdlIrYy9UQWhmR0dwOW96cGtvbEJ2dUJZU2pZYUIzTjRm?= =?utf-8?B?UlhWQW5veis0RHFWZDRGWmNWdXA4TmJWa2JOOWJSUFpFOG9sWVFQWHdkazY5?= =?utf-8?B?WEpkQjV5MVRsRUQwU2NSeUFORjFRSDhGdVRuOXVlait0cWFveXZlVnU4SXUz?= =?utf-8?B?SFJ4N2RPSlkwZUZRMldrVHA2RDBGZWl1dFB4R0w3YldYOG84T05SaTNnQ2FW?= =?utf-8?B?YndibFBpWDJ2NDlPUXQ5YVZMbHgxNHIxcGJFUzhTQVdUVm0rOFVqaC9wS0hk?= =?utf-8?B?eEhOc2ZGeTA3QjdGZ0NFeDBHZmtEV1E2cTErR2ZlMTVTenhTb05iRkVmdnZI?= =?utf-8?B?bzc3ZVAvVkxWYjZRNU5Ld3NzZGJGeTYveUUrZFFCNlZsdTlSeUl3ZGRQRWFW?= =?utf-8?B?S1d6T3pjaWtXcUc5RnE1cEF5MG1FeHJScDNnNGp2WFRQM0xidlpucW5oRDAx?= =?utf-8?B?Y29HOWtjOGNYcm5yT1ptSDI1UlQ4QUQwMTRTOG5wWWd5a3RUUUdhMkhVazJx?= =?utf-8?B?cUtKK3FlZEdYS1JBQUdYQStnbEJoWWdqV2ZtYkZOd2RtOUg2UHZNOVp1clpx?= =?utf-8?B?TEk1eG45aEZUZjhoK1NhQ3VGM214NkFZNnNUeXp0VW42M3RiS0hUZG5XTTVJ?= =?utf-8?B?aDhjVnNqYkdGQ3JQczgwUWoyeWpJQ2N5RlV1ZDk1c01VaEc3OUh4SXpjMVli?= =?utf-8?B?U2ZUTHpOd1JKSXVsdUQwbXNnNDM5b2dPZGI0UmJCeUJZUmFjMC9oTDB5ZS9O?= =?utf-8?B?KzRhK3hOdU9RQlpMbEdncnR4UUlTY2gyVXoramVTeXU0ZWZrelJHT21vakh5?= =?utf-8?B?K09RS2pqSEZPWDJJMEtrL3BhTG0vbG1JMFhEbHJrd2hBMFRVUUo1VldRN1VP?= =?utf-8?B?UE9Xa2xRMzlESTg5cEZEb3ExSTJ1NmQ5UWRLbk8rRE4xK1hUZHNSektpK3RY?= =?utf-8?B?MG1CMkQ0QVdYMEp5S0VVMFVjcVVZeEF5Q0hKZTVvSHNta2ZVWWl4ay9TdDR4?= =?utf-8?B?NW93ZWFlMEZqTmRWMllLS0RGZWlUS1dvdFgwN1k3U3hNazBYaWxrdWpGeFln?= =?utf-8?B?ZnNWdnM1R3M0QTIzdXRzclJvQ2o3Ni9WNktDVGJQekp4OTcwN1lWK3htTzZV?= =?utf-8?B?UXJqRGFLZHpXdEtiS3JRbHBlMmQ1ODRiN2FhTlNLVy9OUUJ2U09URjVNdXc2?= =?utf-8?B?d3YrM3ZEZkJiYW9wbFRET1B0Z2tSdW43WEZNSi9Gb1JkN3ZwOGtVMXcyQVpy?= =?utf-8?B?alBacEZhZkdjODcvSmlQWjIrdzFRdE11a0tKeUZxT0dLUGEvcm5UV1ozeDJn?= =?utf-8?B?dUNHSHpjTVpCL2s2YkxsUzlTUjNsb0Y4VzVpeWdaczhWV1l4WGpVM2loQVUw?= =?utf-8?B?MWJJUVJldWw5VStnTGJ1cStGSGVDa0R6enMyS3dYMVBEa3V4REwzSThQRm5a?= =?utf-8?B?d0RCbldnMUxjMHNQWGI5QmUyenNtVkFLK2tvWXJ0SWQrU3ZMZ1Z4dzhrNXIz?= =?utf-8?B?eFNpa2RmOHBSbjdxbkZSNk1QbTJRME1ZeEMzcS9iSVdJMFFseVF6SGg1NllT?= =?utf-8?B?WFZDSDN6NGdzeU9SNVVYMGVEandJYUZYdWlyZ0V1bHlWSFZiOWxQNEdEclJE?= =?utf-8?B?N0pYTzduclpnVy9FU0l3ZXdHckUvUHlzMkhNSDFOOVpWVk5IazhnaXhsZmJp?= =?utf-8?B?VUpEa1BmVy83QmVvRWdaSmEvVE1kR3lXUy9mNHlheU1POE9icGpXcmFIb2NB?= =?utf-8?B?THVyaFlaR1RXV2l0NWZ3ZHZpYUxOWjN4UGkxVzFIdWxJS2RYTklMUUpQZ2Uy?= =?utf-8?B?M3BtQ3NzbHJxL3h0eVNKdGVwN0Vuc1MydFR3MGRYaVNVZC8rTElzejJ3Rzhr?= =?utf-8?B?NGVyVlFtYlNEd3hyaGhaZ2QxdFNFRlZKTytCYUlpR1lNZTA3ZmFSSDl2elIv?= =?utf-8?B?TEF4Wml0clFTYXF3MW92MWZCdVBPNGZHOE9jd0RYSDdtZEpEVWw1dkMxbFJq?= =?utf-8?B?NW5wWi9FVDBSMkNWcEQ2MDdiL1BHeS9KQ1ZXczRTc000dmxBbCtoU1hxY1do?= =?utf-8?B?RjFhZXpGTjQ1b2RnSDhPZmsxbkZMMHlpUGRmTHZUQ2V2VENydUxEY3V4dVJT?= =?utf-8?B?RWhsaHl2RldqQmx4TzFiaHllYXlGeWg0d1JmSGdpajhhWG5QNEtnd01BU2hL?= =?utf-8?B?Y0k1dTNyNlZGMVAxc0xNTmdzTk5XcStOUFE0b1RReDZ3dHdRSWc5RkxJbmVE?= =?utf-8?B?OEwwdzM0MHRhZzE4NXkzSXJtOGp6QVZ0TkNmT0w5blJFQmRhNnA3eXYxK2JY?= =?utf-8?B?YnVhRml2bGZqZ1A4QkVydldTVy92UHNNMXBta1o5YVlWMWpIS3NYZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 304ab24f-35bf-4a3b-51d3-08de5db2cb41 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 14:46:03.0409 (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: /gFooS/nU5xeCm4cKNL4RUyTlYHcvfdHW5uMRs96KzSr7SgSp9OU8/XXojWHlG1sYQktkPpsaiXdmvcsWknD4Nv2TBPpt2LXT1N5hqVA6bo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR03MB5545 On 26/01/2026 5:53 pm, Andrew Cooper wrote: > Currently, the BSP only leaves instructions for the APs to adjust > MSR_MISC_ENABLE if the BSP is found to need adjustments. Particularly if > XD_DISABLE is needed on an AP but not the BSP, the system will triple fault > with no information provided to the user. > > Rework the BSP and trampoline logic to always read MISC_ENABLE, and clear > CPUID_LIMIT and XD_DISABLE if either are set. > > Repurpose intel_unlock_cpuid_leaves() to be intel_check_misc_enable() and make > it static in common.c. Replace trampoline_misc_enable_off with the smaller > trampoline_check_misc_enable. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Roger Pau Monné > CC: Julian Vetter > CC: Teddy Astie > > This temporarily removes the printk() noting the reactivation of XD because > the earlier BSP code has already done it, but that logic is about to be > removed. Actually, I'd forgotten that this is still reachable, via xen.efi, and is the bug that kicked off all this work originally. Julien has requested that I try to integrate the two series together, which I'll do for v2. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 27 14:55:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 14:55:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214896.1525140 (Exim 4.92) (envelope-from ) id 1vkkT9-0007Ub-SB; Tue, 27 Jan 2026 14:55:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214896.1525140; Tue, 27 Jan 2026 14:55: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 1vkkT9-0007UU-Pc; Tue, 27 Jan 2026 14:55:03 +0000 Received: by outflank-mailman (input) for mailman id 1214896; Tue, 27 Jan 2026 14:55: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 1vkkT8-0007UO-KR for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 14:55:02 +0000 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [2a00:1450:4864:20::32c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 27c2e85b-fb90-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 15:55:01 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-4805ef35864so20529435e9.0 for ; Tue, 27 Jan 2026 06:55:01 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066be7413sm60496285e9.3.2026.01.27.06.54.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 06:55:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 27c2e85b-fb90-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769525700; x=1770130500; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=4SoXi/i02wz6rUdzNd3IZMG+Sq84Cytphi9dWkQBOYk=; b=WfDA4MHG1xgaP4nkLCuNglsenngwwRQuS7LiOCBNl1L/Sgg3bn1N2OSY4JFVTgjuC6 hG2K431vVEwWo0w8CALMxkDqgsn57XtLj6lzzZyniGJuGbacOYQwDINHk8+XJItayI7N ZElKC5qs6CQt1tIWkFqeZalt8ZiHcN2bTft/9BXogy2CsklKKaAM2/hWjmP7IXQIZQVe B8/O+2HJmF+ybzbUJJQHBa18ijDMsmmVd9nXbVnCs+G0Sof41QVraUkeldvTNRuVyRqA J6/n3oA3w6jcRjkK5haUMHZJVh/tnd3AtdzF7JOKoebAtbOLAQPRD3GyarW1QT2dp/oa x0dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769525700; x=1770130500; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4SoXi/i02wz6rUdzNd3IZMG+Sq84Cytphi9dWkQBOYk=; b=Ee23bhT840XbbtO6HU4WiTKh+JRoFOVoIFabZhINita73+vKpUBjpNUwnQx/CrYSFZ CGEMt8hNIzdjezQBzwT2iPivjzHnPvVE/Hh/ObzbgWmWuQiynER0n8fcT7E++RUMYFzf Eg+v2JE3+5HwhJBbHYrLouRnjrf5UzhFkypnFpkg5qcdGr7Sg7ZOUp0tmQQPmsjWTXT2 r9QAWd7AozjUPWn8JTiEgD3jsOshMK9kLH2tV/kWrSOfxSZsvNW4nc1CgjJ3KOHd/2LF r49ZfMqAu1GucNz613GLTDz7SUU1DH0uMurbekc8pgMT+8kHrOsgQCnM7+yib5yEJ6EH +Eog== X-Forwarded-Encrypted: i=1; AJvYcCXM7Q3CiF5xCwfm9J90MOdoQkJgg6H+v76ioNr7R4QHTa+yaC9h1w0mJ6rDjY5wP4lf7Dfi66hjmiw=@lists.xenproject.org X-Gm-Message-State: AOJu0YzwkorVogYR7uFXu3QHFgMi8/ArZxjI3HCL/DqelrBJvE9SchpO tOb6dikZ1FxIqc+dZxPVWIgZK0lxvLs7EUj/23FNBjkqIgTCIj1KA1+9E4VhAHGGmg== X-Gm-Gg: AZuq6aI7xx/8DmeHupe/QCebsYSWT3Jw+qRnxdYYSE30QdkpTcrzTNCd4UlfOVQrK3c 5g2h0XWs/QgGruE1HMlNyaykJ4fBAuqez0XMieGinMjz/K3xILLUfqN2qGCzUjWSSW5mn+b37Qa a6iClyXVELHbG8pTwijDZcY7yH71WLNnDaCtWKcU1Ug0DkEa/YGrwfEBk1KlxZ+NzwE/bGDcCb0 peqrqlblLVQbwszmeDeL3cZB7zjnqaF8uIqzsMlQOYX4LG2PMSEqa3COGiqm4WPxG/reKyZizBe m4ZMRe+Emfviw9MB+x79XCqJJcOe7EtXey08evzvD6BcNgPUnLHccwWTuEnYaNPCmSa2NvrRAGC iYdcn5/iSv7eNY48bILn9CCx9/OZJ5tD0VYAMaRAqsYGCzgkSC6EIjN49/ox93JOgQuS/Ap/BGG 49KauF8rqtTc/DBEK4XOs3byOfqWFASQytOSCIIue36WkUMzCk+iQMKnK68sPEIH4+KmFAxtfW/ dyps1Zy64O7SA== X-Received: by 2002:a05:600c:3b8e:b0:477:b642:9dc9 with SMTP id 5b1f17b1804b1-48069c54c3bmr27348805e9.28.1769525700589; Tue, 27 Jan 2026 06:55:00 -0800 (PST) Message-ID: <321c036b-0553-47d0-bb9f-31676a9151b8@suse.com> Date: Tue, 27 Jan 2026 15:54:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 08/16] xen/sysctl: Drop XEN_SYSCTL_get_cpu_levelling_caps To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Oleksii Kurochko , "Daniel P . Smith" , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-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: <20260126175345.2078371-9-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.01.2026 18:53, Andrew Cooper wrote: > This hypercall is an addition of mine from commit 67528a3f0649 ("x86/cpu: > Sysctl and common infrastructure for levelling context switching", 2016), but > it never got wired into any toolstacks. In the meantime, how we handle CPUID > for guests has evolved substantially. > > In order to reuse the AMD levelling infrasturcture for boot time quirks, > levelling_caps is going to have to change. While it's probably safe to expose > this difference, it's safer still to make it an internal detail. > > When re-plummbing the LCAP_* constants, turn them all into single bits. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich # hypervisor & ~xsm > --- a/xen/arch/x86/include/asm/cpuid.h > +++ b/xen/arch/x86/include/asm/cpuid.h >[...] > extern unsigned int expected_levelling_cap, levelling_caps; Observation while doing the review: Why are both _probe_mask_msr()'s 2nd parameters uint64_t, when the variables here are unsigned int? > @@ -1270,7 +1251,7 @@ struct xen_sysctl { > #define XEN_SYSCTL_pcitopoinfo 22 > #define XEN_SYSCTL_psr_alloc 23 > /* #define XEN_SYSCTL_tmem_op 24 */ > -#define XEN_SYSCTL_get_cpu_levelling_caps 25 > +/* #define XEN_SYSCTL_get_cpu_levelling_caps 25 */ I realize this it to match the earlier line, yet would you mind rather ... > #define XEN_SYSCTL_get_cpu_featureset 26 > #define XEN_SYSCTL_livepatch_op 27 > /* #define XEN_SYSCTL_set_parameter 28 */ ... following this style? (I wouldn't mind if you also touched the malformed tmem line at the same time.) Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 15:00:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 15:00:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214906.1525151 (Exim 4.92) (envelope-from ) id 1vkkYK-0000th-DR; Tue, 27 Jan 2026 15:00:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214906.1525151; Tue, 27 Jan 2026 15: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 1vkkYK-0000ta-Aq; Tue, 27 Jan 2026 15:00:24 +0000 Received: by outflank-mailman (input) for mailman id 1214906; Tue, 27 Jan 2026 15:00: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 1vkkYI-0000tU-Ql for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 15:00:22 +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 e6ac0dd5-fb90-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 16:00:21 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-435a517be33so3590304f8f.0 for ; Tue, 27 Jan 2026 07:00:21 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1c246ecsm39616864f8f.10.2026.01.27.07.00.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 07:00:20 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e6ac0dd5-fb90-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769526021; x=1770130821; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=tYVukq8gl1dL85MtXVVzwL12ylP53RilHPsP5KRj7vE=; b=MBfm4oCNvl3jDS7G0lvcTWHjfBYqAQ1V72NC7AId0KkDVcdbIHFqj98FiBy1ruVS3i NX8StK8KABwExH7e6ydlUbUE6Msb/RiXsT5Tl+fSjr/72NlzNKGhNz3XDLD3iVWQr59Y FtoXx3Yh0aBZRM7IE+bL56HLnB4AXXE1yWU6AI6QVPySLLop40LrE0OgTV8EnKtQCljw BT4+7474gXv39Aqye+weStKr+YvJZulkmlu6Awy5QOcXxr0PnN6y4kK1pdKmKvi5P63+ OZISJE2m3HGiHVIwisZ4ECGCR5Um9sefBiGwOrgNhWzWZkKMIQCoJGQcviLgWUcpU/n5 U4VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769526021; x=1770130821; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=tYVukq8gl1dL85MtXVVzwL12ylP53RilHPsP5KRj7vE=; b=RqaLAr8JG+pJDGZ0e+qMS9Hg4ZwDzUKjSDDH4BxpHdpzLE6gV0jSprOz0Yl28NG+HO ROWR4yfGhZ6BtvURrmuDOykxNbPOVYaXC2+rKWZPS3zPlB/bd12Z1DqzHJOHk85WDdcq R5zqy9FKwLMnT3sZQY3JJxGJ13ixiK/FYP8CaTjb4hdMMHCZb3CrvLsDmaiakuvkqxSp LoMdJeLol7954lzrrnAXJ8ScvbGQ+/43u1IjYz0+Nq99k9igpfZlZNQ/4RAYHJ4nliue BtX1sI5gJdGXIwUAUKX4TPSlx7rSiGvVOMw/K2gb2wWhxjd6JJQzkxEllmRbfYtV6jPR Hccw== X-Forwarded-Encrypted: i=1; AJvYcCW55IDjyQUdGTr4fkNdt9bnbRR2ZGHYSXZTaOuSrdZLusNNjjVemXBRCRsATjedT9g9jiSbo/DuYdk=@lists.xenproject.org X-Gm-Message-State: AOJu0YyCjPYD8kdu4wMt4dOfb12Ho+YXZ/MKO4eQC40Zhz1SOboom2Wr oyk/Aa4dWsCawgTL4VgFOGhhCbSXxanjnayHkz0+4uGrJ5ZDspWPRwAyeb2070QOrZRI9YSsQdI ycLM= X-Gm-Gg: AZuq6aKewxwpHDMoffu/ap4E2r0jXFQz7RTaGkOV8gZZQBb5E5DnGR4FalKulCkMFkH Qyw6AWFyrqgwrO0HRf2iYAU0A/N8QUt4IV1MbNZXMwZwpLgJQoooR83RPcpY9g7BE1b4EOqjMvp 6OFFZHSxcuzgWI3Lw3KtAl0az89TsJ7kMqtkJ1tllU8VQjEXDmxUC01FytybahzUZ5q7O7Jv1lp gcoDhD8kPGlVftGaQZSrqKHVKsLkH8P82CJXR/s/q1uy55Kg3AiQTjorWKeOe+xreLQoZv9Rbb1 QfvchNq2xE6Wy0FsUsSLYeF7dvoF1eb82eU2IbPDgaxXERmG9mqCTL2a9vvpDOylx6VsyfVlzaV Z0d4TSlAXmxu/tYK+flHyaPfHxL1gSFU7KWMrbJoGVJtiH2cYxkXp8Gxy833jCFQ8lYlVoEsPdl tzdU8MxTC19n50xBB00QFZcKNF6+9MiCax+2T8cg8fasygJ0TgqUUNmMd+tm28nkoQLyqkTVVJ7 FA= X-Received: by 2002:a05:6000:2483:b0:435:a0f5:c276 with SMTP id ffacd0b85a97d-435dd1d8617mr2777558f8f.61.1769526020659; Tue, 27 Jan 2026 07:00:20 -0800 (PST) Message-ID: <81ac55fb-6405-4b11-999d-fbdc4fd61759@suse.com> Date: Tue, 27 Jan 2026 16:00:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 15/16] x86/cpu: Clean up use of LCAP_* constants To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-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: <20260126175345.2078371-16-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.01.2026 18:53, Andrew Cooper wrote: > Now that the LCAP_* constants are single bits, we can simplify the expressions > using them. > > No functional change. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich I was meaning to ask in reply to patch 08, but luckily this time I remembered to peek ahead in the series. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 15:01:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 15:01:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214912.1525161 (Exim 4.92) (envelope-from ) id 1vkkZc-0001Ns-Mf; Tue, 27 Jan 2026 15:01:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214912.1525161; Tue, 27 Jan 2026 15: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 1vkkZc-0001Nl-Jm; Tue, 27 Jan 2026 15:01:44 +0000 Received: by outflank-mailman (input) for mailman id 1214912; Tue, 27 Jan 2026 15:01: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 1vkkZb-0001Na-Ia for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 15:01:43 +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 15c2bb29-fb91-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 16:01:41 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DS7PR03MB8268.namprd03.prod.outlook.com (2603:10b6:8:258::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Tue, 27 Jan 2026 15:01:38 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.010; Tue, 27 Jan 2026 15: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: 15c2bb29-fb91-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HqtO8tGU6epxoepP9KAVslnP48er0wagQxdjRE2nR/lpuTkB+TKHwsrkCxELZQp9K93fkVkV89qIdgG5xHIS/uj+JfH09cuUHZ8bOw3MMHsOgxX+CJh+qOXy2Sv+cMrnSI9gLwOhZGNg+Zmn0BwLxH3PRhUDw/YMXVH4r0O3o2pNui8xAZ3JddincBPB1yYU3CrWzu+RzcEUXISrHRR9Hn9lbHfZXCHaRju2s1sT3exWnVHM1AWjHPS1SllByYM+HQRo+yAo2TeBxcrOiVdWWdUiYb8QItHJhWq9lp3dHmlpvjZk+vKCDITN4ZfqYxjFzPw7HnS5dxRHR2aMJKLApg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Qd5XUNt+nBSU4TcB4/a4gwqgut4Yv7FK3qWhbMGtSSk=; b=cPTjQizChlpzcuvSByXZ516JgSvBgRMMK0jhq3Vy3c6UX7KZPV7xGW3bsHuHJr/mTXYrbOHZar47rjLlJTv/k1JSVqK+IzUCd4PeT1XrRIsG++ZvMdtf4BbIJZHQV0GKAgBka2V6hgxp4zvCLmN0YujfL07MDDD9P5nqFzHWm3rAfziUjqkhzyw5rSVSJRfAc+YH3PrZzcE5RTLOIomc08S0srNdvaCbyC0SW7+mA6TI49HAcO6GKmvGVYOBZA7cYIREV3zpNaY2tZLpo8l4EDW9dUD1Ndmy4/m1BxpDc4aF9EJxezMSJcZx1TEt10mIwVwhrTg5v9ZE6X/MiU6Frw== 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=Qd5XUNt+nBSU4TcB4/a4gwqgut4Yv7FK3qWhbMGtSSk=; b=bbbvjyI+3jUZ6XK3JBdDhKv8359G29ZsB0zw3rVPEvp7xYMsWq0V6MITK3ZJ+5JE17X4uevDPDP6T0GgRzKhR+e/MoOA5cGgE0RMwimxI8gW6aYljKHlwkKkEovBCj2UjQTniltwJBpG216GSWpIsOGC1+chbStdSrIT7d4ywGU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Tue, 27 Jan 2026 16:01:33 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH v3 2/3] xen/mm: allow deferred scrub of physmap populate allocated pages Message-ID: References: <20260122173857.83860-1-roger.pau@citrix.com> <20260122173857.83860-3-roger.pau@citrix.com> <69a64a89-af3f-47fe-8998-a3ff76e9484e@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: MR1P264CA0193.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:57::11) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DS7PR03MB8268:EE_ X-MS-Office365-Filtering-Correlation-Id: decdd4a1-6527-4e37-1e8e-08de5db4f8a6 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?b3NrQUttb1NIdmlqdGhTNGVpNG1PU2NJMmtocWZhd3AxenFlZnVYTlRWY3hF?= =?utf-8?B?bnUybDlmYXJ3Q0RDUTVpMnJmNHRSYXJ5WmpkVVgvUWhaMituaVdLS3JVaVdE?= =?utf-8?B?a3BWaVdkODVDa2tuU0dpMUFnbE5MYnJxVnlmZTVpZVVKOVp5dWFhY0NodmRK?= =?utf-8?B?MGtaQVVyZkFlUmZqVUg1eU5qM20rSDduVGJReitZZ25NNmE4cXc0TERGRXM5?= =?utf-8?B?d2hSd08yK3lnUmpDQTd4N3FTWkV5STBvQlRlUTJlNWw0WXdHNVhlSDVqdXBa?= =?utf-8?B?bUREd2xhRTNScDZiMzQvNDVocDA3THNxYmdWRjFQdFU3R3pVZE5CcGVBUTRO?= =?utf-8?B?Z2h2c3lNa0cyUUFzOWFaeGdsbmRJcDV5Q01YMVdzYmF1V3pNSjNrd3BxYUxJ?= =?utf-8?B?cnh2SGNzMjFERTZMUzcxQ2Y2T1I1MWUyOHl0dm9UampPTk9Ca1ZKUlY5YzFu?= =?utf-8?B?YU4xWmZLV2ROMGViN1BxWThhSVBXVkx0cmx5cmVlTmJqS081djVJZHBLWnoy?= =?utf-8?B?aTBKL2c1SEZzV0hsV3IwWWxyLzlMTENXNG5UUlFKVnBnMERLdUJnNEZhZlds?= =?utf-8?B?ZFNLRjAvTDFJMFM2bTJta3lIOFQ5UGlhdVFURnhHaWJEVEdoZkZySExmaXZX?= =?utf-8?B?RHUraENzNDdyNVVOTGxBcHVHbXlWQnAwWHIwQWtGV3ZNS1EyOUtkVlZYdVcr?= =?utf-8?B?dWFvL0tzY09yaHhMVzBHTjFNMndzMitTb3krcnQ0bWs0Z1E3d0VGQTN5Z1BX?= =?utf-8?B?bnAwQmMvY2VRWFcxMHphYVVLTGhValhsRGZJMjVTZ0dCWkx6RFJ5N2w2OE1M?= =?utf-8?B?bnR5cFl3WExmczRybUovLzZzVlYvcDd3STNsT1didGhhMFptKzBzSGFFbXh2?= =?utf-8?B?RU5sQzZiandhS0RvdndOaS9XeDF4VFhiQ1c3NHphRkhTd1BFMmx4cTlUVHF3?= =?utf-8?B?UUxCKy9CYS9JSE9WVjNGNnZYOTI3eE53RFZ1UEpqVGFPdDRFc1JRQkc1cXc1?= =?utf-8?B?b3hzU21hWjQvL0R4V0E3UUlyOHVBS2dtd1MxUDdTbEtTUGtvMW91bnhIc3NC?= =?utf-8?B?RG1wVTdGRy9rakV3N3lCM1VSSUVYOWhjR0g1ZDVZS2YwMFNOQmhsY3N0SFNX?= =?utf-8?B?WXhuUU1HYlAwd2UvRWRpNExRemhOZmtpM1ZKTDROSzBaQ215VVJqcDgyUjN1?= =?utf-8?B?S1A0NDJPc25RY3hxbjJENXhUemg0cjAzK29EMG9WTzNHcDZFNnNuSm1iTEFD?= =?utf-8?B?ay92cFR1eHRhU0RmUFJudGI5Y1hrZkFUdEtaa2dLR2RCRHVmeDk5T0xCcTZR?= =?utf-8?B?ZHEyRDVqeDlrQ3lzQzdYeFdkOHpsTUxqYTZFZGhHUXlzWEZQUkJDMXRQQzlq?= =?utf-8?B?c0F1WUJBTWpWMTh1MFhkWTI2YTJtVzFUNERmR0RPZHNuTU8rTDdVSzRrVlFX?= =?utf-8?B?Rkt6NXEwN3poQWxrSm4zVVNtZWU1ZGlNRDZJL3RNUktSRlJFM0o2TGF1elBh?= =?utf-8?B?UWU1UlovV1dyTnVtb0tlNDZhRXpoMk1iQ2VETnJ5ZUdJaWtPQWo3U1NCdFNi?= =?utf-8?B?TEZFd3hkbjRpYXZPckRnelg4WURSUnYvdE4wSi9uVmdIOVcxSkZKbnA0UTNJ?= =?utf-8?B?QUlGdklhdEVXRExJanUwdnBYRzRnZXFCNmF3d0d4YWhjRmx6MHpyNHdRdzJm?= =?utf-8?B?NnFnNWV4bC91L28xTUVFbnZXdlp3bnNIRStXQ2pRYmhCYzVzY0hFTDZQSUs2?= =?utf-8?B?TitYZU1NSkVXSitCYkNmam5hclc4MVdyeWM4NEZCdEZJTnpBejZobXdTTWhV?= =?utf-8?B?TTM0VERsYXVlM0d6K2ZrVUtQTmdZVUppSEdmR29pM3E2NUE0MENRRVJLbVAx?= =?utf-8?B?K1BGVEI1TytGUkRCdmg5OUZRNy8zeUx0eDJrRHFTR1A3NDhPVkI0VFZpTThN?= =?utf-8?B?Yjl6TVgrbUszMkl2emhVY0JMemtHRTE3dWRkNVl2UVA2VUJkT1o3ZXE5bWJD?= =?utf-8?B?U2ZPdXJCZHlBWFhWTGJUWlMrblZiMzliYThZZnNUVTlNNnFqell2WTBzcURT?= =?utf-8?B?QkIvNXpoQ2J2ZWRXL0FOVGpQQVhqK3h6SS9LcHp0bzF2NFFBb0NoTzlocVVj?= =?utf-8?Q?gHC8=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Q0NtNVl6U05TK215QmxpaDY3QnhVdkJSeWVnYU1PZTFNU29mUVZKZnZNVVI5?= =?utf-8?B?RmtPcHZvb3lCcm1kNUVOZVlCOXdsWjJBL1dWNjYvREJZYURmUkozUmZTbDZp?= =?utf-8?B?ZU5LZ1JjUEpkUHR4R0x0QXZMblVHbEFGT1oyV0dsZkEwMW9ETHljVFhobkRT?= =?utf-8?B?WDB5a1l0dHAvV2hzL2J3RUpWSkl4Wm9vWkFyQ25hQkpJdjlQQUttcitKaXA5?= =?utf-8?B?Rnh5V0hWMlF0S1pXZ1hRWGwvV05iRGVRYnFHclY5TCtubk44eTNjdWVmd05m?= =?utf-8?B?aXVLQTE1MW1tRWZ3OVgvUXpLSTFCMU1pa0lJNkVlUCtLWEJhNnBBQ0g1enND?= =?utf-8?B?TWgvQ1NOL0E1YjB4QmJkNktMbnBxNTNqemZtbDI0ejg2ekJkTHZubGJTOWR5?= =?utf-8?B?Zkw0YkRiT25WL1pKbWhjcktjL0JaQnV5R0lUSUtsck0yNWp6L1A3Y3M1QXFx?= =?utf-8?B?SG5kR3MrdnpqNmFlSmUvNUdzZHR4OW1iUDBYSElrbldrenI4VUhoUUN6MS9z?= =?utf-8?B?YXVEaDVwbmIrQ1FuZjFJbGpsMHZLaWRnUnExTWorL05vM2hPUXpDY3FDd2tv?= =?utf-8?B?QWl6VUo3bGw1L0Y3OTcwdnpqdmMvQmJTN0ZYOTluQWtEUS9hUkk2ZFB3Q3hS?= =?utf-8?B?TXU1TElvVjFmNzFScnFBZ3hnVHpIM3k3THA4cVFCcEZHRlZyTElaM3RwK0Mr?= =?utf-8?B?cHUvTVQ0YVRkeFVDSzdNQTlBbkNLUGx0dEhXTEl2QStRNytGZUs0T3p3Vnph?= =?utf-8?B?bHRPNE9hVFpNVm5KZVNBTjlSdUoyV3ZrTWQrczVIUzlhbytxdHovMjBWK2s0?= =?utf-8?B?STBsREJzdDllbnc5cFZ5SWtXdDRjQ21XMEd6dm9YY0JsM2dRa2dxNlNLSVZX?= =?utf-8?B?dmp3L0FGOHVONFRwWkRpN3BXTjBwOEJyejhSNEIrY2VEVmtYQnY1aUxTemlI?= =?utf-8?B?NXhRU1hKL0RJVVdBa0FmZEt6SDNuNk9YZ0tyMUNPY2JMUTdnV0gyTGVXQlov?= =?utf-8?B?YmdFb0k0ZDhRZ1pxNndzTFFoWTllSzh3V2l2YTU4MDV0QWxUZGhVY1dSRFlN?= =?utf-8?B?dS9UVS9Ld1g4TmZWN0gyQXpua3Rqa1BGWDZjbmEvYnpiOTgvNkZSaVFXbHRm?= =?utf-8?B?UnVJS0xrMUZIMjdIUTNyelRaSDBDcVhVM3k1ci9Lb0IwV1RReG4rQi9iNmlG?= =?utf-8?B?SnpnT0xDVURqK0JKclhGckJWbkd0NGs2d0JGSFF4Vy83bUttVjBuUHhkaE8v?= =?utf-8?B?WUw1ZW44YjVKOXdJYXlTLy9vVk1XSHlSL1ZoanQzekNIVlJaeThIbzFnbk84?= =?utf-8?B?TUIrN3VJNExUTS82T2NXWkNDQWozczVoaUp1WTRsN1FMMXg3cVpNS0NjRWhx?= =?utf-8?B?amQxZ0l6RlR5Vks0R096Z0wwdWZkbTVneUlaYVl6Nk90aXN3TUptVW1RbXRw?= =?utf-8?B?VVh6S3ZCdkQyVXBNZ0kxUlc0RlN5TW9scHl6RVlwMDdhYnBqTkozSFovUTJw?= =?utf-8?B?KzI4TEJyV1VEbUFXb3g3c1dkSkJwS051aktlalZtSERrNUVZS05aVWJhK1VS?= =?utf-8?B?a0czN1REeFQvL0htamZaNTlib0lFaWRTRXJ4bWZGS0FudVMrM09qRjR1VVly?= =?utf-8?B?VDMwb1ZCcWthMnNaT0w5WEtWcytzNXpnQUpWc3FzQW1wYzZtSDJKcnhsbllO?= =?utf-8?B?NDlWY1FvQTZmc2l0WEFTNWU2dlNJeTgzZ1RPd3R2SFMrRC9XT0FWbkVseU5y?= =?utf-8?B?ditxYWNSalc2OERBdHdUZWw2Qi9Ia25nck5YT3hWUmxRZzc2MVBSenlYRHFD?= =?utf-8?B?Nm01ekdKdWVMMXc0UnJrNTlXSHZzdmFMcEhQVEVIZlhlZjBtRWhYTnZDYXdZ?= =?utf-8?B?YnJmSDM4aURMeUpXMnZEb2hNSkh5UXIzOEtZQnFRRkRiNTlEQnFxRjFjblRm?= =?utf-8?B?QUh4ZFpuZzVWM0F6WnllRGo4L0l5SUNGTXR4THJidDFsSERwR2ZxeVBsWFZn?= =?utf-8?B?SUFTV0dwcXVoZVRzV1QvNitVUXRKOVZoUXlWTUVncmJjdFZWVTgwejl5RlNm?= =?utf-8?B?eXZqWEordEczMU1oNURPUlRFSGJvZ3lIbjNHb01yYlhkaWVQaE1McFQ5MzVn?= =?utf-8?B?RlFXaW40ZFNZbEszanhaKzZkMTdRMUlkdjQzaHg0ZUliZ0RaRHRwMktXTysz?= =?utf-8?B?UXdVb0lWaU1qbG1Ob0VGVXgxUWt2ZGFlZ25KbldKZThsYi9nUDRuZXFKb3dR?= =?utf-8?B?a3VZVnp6MU1oVFpvK0tKZXh0MVptUTJ3dXZHdGdaL1U5REUrVm9KRW9RZXk2?= =?utf-8?B?MGd1TXhtbmtmb01GWVVZbXFPWDN0VXNxdnVJZ3BTK1FCd0tjV1ZOdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: decdd4a1-6527-4e37-1e8e-08de5db4f8a6 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 15:01:38.2969 (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: iP04KGLvX4Wxg8MWgCM/C2wDGPG2YJZ7XJb0fP3J+IeNu1RIuVOmcICmKON9wWqkqWym+Ll2VihgZPl9DsFDPw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB8268 On Tue, Jan 27, 2026 at 12:06:32PM +0100, Jan Beulich wrote: > On 27.01.2026 11:40, Roger Pau Monné wrote: > > On Mon, Jan 26, 2026 at 12:14:35PM +0100, Jan Beulich wrote: > >> On 22.01.2026 18:38, Roger Pau Monne wrote: > >>> --- a/xen/common/memory.c > >>> +++ b/xen/common/memory.c > >>> @@ -159,6 +159,66 @@ static void increase_reservation(struct memop_args *a) > >>> a->nr_done = i; > >>> } > >>> > >>> +/* > >>> + * Temporary storage for a domain assigned page that's not been fully scrubbed. > >>> + * Stored pages must be domheap ones. > >>> + * > >>> + * The stashed page can be freed at any time by Xen, the caller must pass the > >>> + * order and NUMA node requirement to the fetch function to ensure the > >>> + * currently stashed page matches it's requirements. > >>> + */ > >>> +static void stash_allocation(struct domain *d, struct page_info *page, > >>> + unsigned int order, unsigned int scrub_index) > >>> +{ > >>> + rspin_lock(&d->page_alloc_lock); > >>> + > >>> + /* > >>> + * Drop any stashed allocation to accommodated the current one. This > >>> + * interface is designed to be used for single-threaded domain creation. > >>> + */ > >>> + if ( d->pending_scrub ) > >>> + free_domheap_pages(d->pending_scrub, d->pending_scrub_order); > >> > >> Didn't you indicate you'd move the freeing ... > >> > >>> + d->pending_scrub_index = scrub_index; > >>> + d->pending_scrub_order = order; > >>> + d->pending_scrub = page; > >>> + > >>> + rspin_unlock(&d->page_alloc_lock); > >>> +} > >>> + > >>> +static struct page_info *get_stashed_allocation(struct domain *d, > >>> + unsigned int order, > >>> + nodeid_t node, > >>> + unsigned int *scrub_index) > >>> +{ > >> > >> ... into this function? > > > > I could add freeing to get_stashed_allocation(), but it seems > > pointless, because the freeing in stash_allocation() will have to stay > > to deal with concurrent callers. Even if a context frees the stashed > > page in get_stashed_allocation() there's no guarantee the field will > > still be free when stash_allocation() is called, as another concurrent > > thread might have stashed a page in the meantime. > > Hmm, yes, yet still ... > > > I think it's best to consistently do it only in stash_allocation(), as > > that's clearer. > > ... no, as (to me) "clearer" is only a secondary criteria here. What I'm > worried of is potentially holding back a 1Gb page when the new request is, > say, a 2Mb one, and then not having enough memory available just because > of that detained huge page. If that's really the case then either the caller is using a broken toolstack that's making bogus populate physmap calls, or the caller is attempting to populate the physmap in parallel and hasn't properly checked whether there's enough free memory in the system. In the later case the physmap population would end up failing anyway. > In fact, if stash_allocation() finds the field re-populated despite > get_stashed_allocation() having cleared it, it's not quite clear which > of the two allocations should actually be undone. The other vCPU may be > quicker in retrying, and to avoid ping-pong freeing the new (local) > allocation rather than stashing it might possibly be better. Thoughts? TBH I didn't give it much thought, as in any case progression when attempting to populate the physmap in parallel will be far from optimal. If you prefer I can switch to the approach where the freeing of the stashed page is done in get_stashed_allocation() and stash_allocation() instead frees the current one if it find the field is already in use. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jan 27 15:18:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 15:18:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214930.1525170 (Exim 4.92) (envelope-from ) id 1vkkpw-0003OA-3B; Tue, 27 Jan 2026 15:18:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214930.1525170; Tue, 27 Jan 2026 15:18:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkkpw-0003O3-0N; Tue, 27 Jan 2026 15:18:36 +0000 Received: by outflank-mailman (input) for mailman id 1214930; Tue, 27 Jan 2026 15:18: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 1vkkpu-0003NU-F3 for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 15:18:34 +0000 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [2a00:1450:4864:20::62e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 71235b1e-fb93-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 16:18:32 +0100 (CET) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-b886fc047d5so685418866b.3 for ; Tue, 27 Jan 2026 07:18:32 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b885b419642sm815958166b.28.2026.01.27.07.18.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 07:18:31 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 71235b1e-fb93-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769527112; x=1770131912; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=KNigdRr74qq+jkaoZzcUK4eaKZQ83q+VeyOdY5hB6hY=; b=JO+ZfcWJQre9c5FcVEKpVJGUKOgWEffJYfcao4VtH7VuEMT38715f0Jqfhai96u+t5 CbXS2Hbo440OLYM4MSFXPfNGNGAEu6gXa4F80WuSMakEpKPrhds0jZXBs8/tCDctYDQL IXTm6ldqNLaFgNwXfjYWQwFMfw+h6YZA9MKW/JSOjLQ+lYspNTMGgvxd1qL36SE6Zcts vSXoZaEZKoBzfWg0UQ+/l2f0DF8c/2cmDK50ERny3JKBR8KVKVGylvHwMHRo1NyQwVMt aJ5VKYTLsMpDTd7AH+HmXxn1MKi0bB3Ro8dVJO7ie6wF218K0wji5DwIfedqMFRR1oIk VS8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769527112; x=1770131912; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=KNigdRr74qq+jkaoZzcUK4eaKZQ83q+VeyOdY5hB6hY=; b=kQrUUcqjcSD02qoqxC0kb5PDtU9UaZAztVGptg7uUhpqGxaHZlrpPR5Hmu+/uagrbi Q+tVi7Ts8xrH44ubx0qetc7ddCIieznM3ambXMvBddwi+O84Pzf4rkKQCG+aA5nHUJ5N j68MnLVAi36ubncNZaBe5kGz+72EpyJOh4JSYiETJvmGPJKbaKPKWbKWtmyTr5YJZHG9 I+h+aSdTr/6+phDRkJdH6ava2qJKNj+eXBfOu+glZYXDQ2PnnzRUI2cde1u14DrrCldk CaTvtEdbqB/yKVK9K7w4y2KHaq+fYFUIZHgzreKi7pNeE3qLIaqTEud2/+d7TNhPL6wD U0HA== X-Forwarded-Encrypted: i=1; AJvYcCUPEh65VYcDF/52+95IK5MxjxKwSvBtpHN5P2hkjGkRix0X8LimQguPUre9Uv+Nx2aonq9BWRX1CYs=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz+I2TSn+ebQMsN4ezR8Z4+XOLwWgWaw/sRDOvt/L6aY+Hthoie XhcqgeVGowADorAV00saL/48NovS22I0HPJHGPkwiLeX1ENAhaUAcaIX4oIKfRckiw== X-Gm-Gg: AZuq6aIlh8xwH2SbMK+/TDniVhPHff7vpbolU5AM52tXJV/QPNhAoaSKHRSlVCUYWbW dNkE0tAWY0sZ8imjDsD0iFvHpsekLMAuELg1gNIL+eLOncQvy8tDjXW+2I9NZDRXtyBE+2NpRhl pm2sI2/TbnLCxpJnXzGeCaMCLXdUdRgO6U7UAqiaKYpgb5AR2WBRS6Of1YUt/xysfF5BYpNUjwy To1Mk3nRmqtL4MNZi68JanPUtSC+U6tEq4avh6ms0e2/mBv1e59cz0AysgsbteZMf2g9HiM/Bwn X1/6Wfr5tewLkuL4T8c1Hnl9O4pzQP55Q6L5mJ0bdqNRMBa6AmoBxK4i5vvyegJ1v8Ao9OAAxpb JQErRvfMiMt+nq8lhpRNJ/9tsLVbuYUMs0URm0/duRKemzTGf6WjqY8jJU7jsvBhwFfK9rmTlea 15gCxJVy7zMyxx8bZ/k1kC0BD+AiFdLJVZLqY3i9ie/xH7ueitoV6vcNLR/K5+xWc0Kj68MuSII DEsM6q80kJoUg== X-Received: by 2002:a17:907:d22:b0:b8d:7c0f:5bfc with SMTP id a640c23a62f3a-b8dab4c7003mr158164466b.64.1769527112068; Tue, 27 Jan 2026 07:18:32 -0800 (PST) Message-ID: Date: Tue, 27 Jan 2026 16:18:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 09/16] x86/intel: Always check MSR_MISC_ENABLE on all CPUs To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-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: <20260126175345.2078371-10-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.01.2026 18:53, Andrew Cooper wrote: > Currently, the BSP only leaves instructions for the APs to adjust > MSR_MISC_ENABLE if the BSP is found to need adjustments. Particularly if > XD_DISABLE is needed on an AP but not the BSP, the system will triple fault > with no information provided to the user. > > Rework the BSP and trampoline logic to always read MISC_ENABLE, and clear > CPUID_LIMIT and XD_DISABLE if either are set. > > Repurpose intel_unlock_cpuid_leaves() to be intel_check_misc_enable() and make > it static in common.c. Being able to make it static is of course nice. But moving Intel-only code out of intel.c isn't. Personally I'd favor it staying in intel.c. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 15:21:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 15:21:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214941.1525180 (Exim 4.92) (envelope-from ) id 1vkksZ-0004t9-FV; Tue, 27 Jan 2026 15:21:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214941.1525180; Tue, 27 Jan 2026 15:21:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkksZ-0004t2-Cz; Tue, 27 Jan 2026 15:21:19 +0000 Received: by outflank-mailman (input) for mailman id 1214941; Tue, 27 Jan 2026 15:21: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 1vkksY-0004sw-Uy for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 15:21:18 +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 d2d30deb-fb93-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 16:21:17 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BY5PR03MB5155.namprd03.prod.outlook.com (2603:10b6:a03:218::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Tue, 27 Jan 2026 15:21:14 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9542.015; Tue, 27 Jan 2026 15:21: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: d2d30deb-fb93-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rWDvmlk2nhCd49yUH4QnlaEIyNDtWXYJqrhawT5zb82Hejq70sAYGbz/UskoWHfVX0aQhG8rFe2VQHUNo7fPSYRm7vWm0E1gz3BCVnb+gGc5buW5NgsIeWNiZo4gizH8Kp7bxFKwqIIc9KeUJ2wSDYhS09eWIKkJ5RIkeH6JlXDDtkDTUQUIxW6O8MMBMqPTKdrM56pahk/dt9SFCE1mn5GLOUrIhaOnabzKzKrgQiUn/1HQBjFRtSrgW3Ue95w4/RkKSWUYrJmj8FiedWbrOFfIRJo6N390Db9HVWF4o3m8S4dE7ip7aCjCfLPvY0rdBzNpkpNeDFpV6yBlVMgloA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KA25xpM37iGByW9ODy+xmsSdDAuqUKFkBJE4w3MW0Ns=; b=CFRiFg3kl5/mGWfb/yXNxgf078RnfO/2Q8PUYKYBA1hSlfvM2KlcvdLYeVRmiKDJozMs4QgTJc+hgJrGylQNVmjBWPvno2qhXx2J2kFeye8PmDX2PPK4tRk6uFAfhrGHxDqSErCHfEVCds1Dx8LiTHKokhqE2dERYttG2+gJK+TCksxePV1Ty0pOD+RlMmN7VoTZJkKPtHA5Ht3D/cakerh/4eRkAMg3EDnEzGQWhpEqsaKdNuSDQ3xyMg6or7wQU+aa7ZD2ryeO8eIx/jpk2rzXYbTTYQ+XaybAAEjtA35kh0s3RNqqBTvJ40agvAFIi+7Nr22ELO8yS6kuxkRlTw== 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=KA25xpM37iGByW9ODy+xmsSdDAuqUKFkBJE4w3MW0Ns=; b=DII6PjFAmKzSdNKtJ8InbY4ED3rIR+iMvHOwxyfUK+0+uV0y6FcBl190oPbnUWLp1Q/W9m3WFiPlhsplMqcyJhW1dGmX4t80cI+BYNoAfV7/94zudaC6zffwWRxayVY6Y0eKP86PIxrBnEk1W7zJn0wrSa/TpMYGPA7Fi2NEP74= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Tue, 27 Jan 2026 15:21:10 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel Subject: Re: [PATCH 09/16] x86/intel: Always check MSR_MISC_ENABLE on all CPUs To: Jan Beulich References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-10-andrew.cooper3@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0265.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:37c::17) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|BY5PR03MB5155:EE_ X-MS-Office365-Filtering-Correlation-Id: d6569e7f-25f5-4820-b8b8-08de5db7b574 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?V0tlVk85bTMzNVpDSnd0a1JGRzJKWkkxMDN0V2lKWUhEZVQ1Q0FmQkoxR2tp?= =?utf-8?B?SmJ6UW1heG44TmtPQmxZM2JuS2ducEtqclUwQkZQUWp2TXlhQjVUNndFNStU?= =?utf-8?B?dHg2WVZPTEtHZ0hzYngvMmM2a0JRWUIvSTB3bXpJbEhTVTZ1NDl4cHRLcE5S?= =?utf-8?B?MFEyS3U4aFhxMVgrbmF0N2wyMWJ2RllzYnZlRWNaL1hTWmlLWHBtQjQzV0s2?= =?utf-8?B?WGZmbUcxNCsrbmo2RkZ5SEk1cVM5Tk5wM1pjdzV5UzhBc3ZKNDA4cVN6cUZP?= =?utf-8?B?R29PbHpBa0svZkJUa2RwcGVlU2VaR0QrcTQ5c3N0Z2o1TEdrNTE2ZVFPUHh4?= =?utf-8?B?bmREZlRkOXhWUmdrQVJMS0FkSXhDUlhUV0pRem8rYndQeG1oZUtqL2JlZ3c2?= =?utf-8?B?aUQvM1BlVWpSM2VNZ2RTc0RxUm5rT2NPS2hpSHNNRS80clJUNkMzQnNuRzRv?= =?utf-8?B?MnRHV1F5TzRHZHgxVDNGQ0xBOUFtOW9pVldMc2srYnBGRzU3NTUxNXUzbVQx?= =?utf-8?B?OUxMcFVKeVh5SVo3WFJpQTloYWNEd2s3STUwSmt2Tmcxa3pqU3N1MVhOY0xB?= =?utf-8?B?dXY0ZG5vMVVtMTFYdjErMjJYdFlZZUhRRHdXMm8vY3VyMTZNa1FGK2lpSW1C?= =?utf-8?B?WHJVTzlRREtMdXNEMW5FMnlNaHlxMm91ZFpEdUFoSWNPTFZxcTcwTmpIaS9m?= =?utf-8?B?UUJ6dUhiSHU3MFNneEVsVTMraFQrL3l0Tkc2dzRiVHZCVVVlSk51cEpFdHRw?= =?utf-8?B?UUtMbmZ0aFJYcFJrVEJaWEdOTVZSanVuL0M1ZzFMOWQxN1drS2twRzc5dnNY?= =?utf-8?B?ZnpDS0ZlWDdJQjBUZHJGSE0yUjNKaG5FVGpUOVg5ZmQ2ckRGMWdoN3JNL2tq?= =?utf-8?B?UXBuYlF3TEZKTzZCSzVMcFc5dVVXWk9PNkxOSU45eEovSG9PenVLYUpLc1Nh?= =?utf-8?B?eTAxQklqQTRzMHVhaSs2UE9UMjNkazZhbkxOV3NQWGs3OUI3Um9Dd3QvTits?= =?utf-8?B?WTFITExkbHZ6WndMaGg0dEdhUHA5eWxvb2ZHaW43RXVFdkVzMHJITjdQOTNX?= =?utf-8?B?anlxcGlramxkUk5EZkFpNUkvbTF1bmQrOS9XT3VmYXlJVjhWS2N2Tndvc3RM?= =?utf-8?B?b292SkR1dXFUZUJaeWJvakVtemJieFVyN3VQdll2UHhWNGF6SWQxSGpObGJL?= =?utf-8?B?SnBESTNhL1RnRExVN0k4ak1NbFFQMU1WSnlTQ1lLeHhFYlBYQXhlbmJrTklj?= =?utf-8?B?aWhJMFd0Q2s5bFR2SzBhS1lFL21WK0RIYmg3TVpBcHVyREtnbFMxM1Q3djVQ?= =?utf-8?B?U2JablRPYnUweThFYmdzQ1FtSHptN1FHbjJIWnFicHhNTVZJUGZlZ2tqUkE3?= =?utf-8?B?Qm9YL0tsR25OeENINnN1SlRXY2tBcGtDQVZaaG1WUThqVEVlZjNGNjI2NDkz?= =?utf-8?B?L2VxNHFld1gxNDQvMlA1RU9GMWZIUUVLVWdkUmNIT1o0N3VKK1Z5KzFOQjUy?= =?utf-8?B?dm42L2pHTUNUeGtqOU5RQWdjb0RMZkpQbFVtdjNFSEFRVkNRZkJobll2YnIy?= =?utf-8?B?clRsN2dFZ1J6dXZwWDlMcnlEWHVvOFdHVFA5TUdZQ2JvUE1UQVo4K0FjSkN0?= =?utf-8?B?RDRmVlJYS2kyQWFRQlEvZDc1dEhzNjE0YUVBQ0Fsa0lJWmkxT2JmVzY0U0hK?= =?utf-8?B?MEZ1Y0dvZDMva0RiWlJIODdIUUZwbHluNlVqaHVxdmdGQm1COHNQSmVZN1B1?= =?utf-8?B?a3hib1phRGl2UyszMHZxMVhUalIzbjFBQnNaOUFaOVJEZ09Qdy9Udzg4TVpT?= =?utf-8?B?QWJjRVVNZHkzZkIySGFseDNhNExkZFJKelZXaExldG5LbjhaYU1tRm15Um41?= =?utf-8?B?b3Y4eWRobTJSNzFNb0tpYmJVY2JCMTRQOEVUZWVtVTg5ZGJPcTlqS0pMSDlO?= =?utf-8?B?T1FTVENrRXJicERsZWpSY1JFazNuTWRLZnVhWTVXL2gyUTBLcjRGZ1NrdXdu?= =?utf-8?B?RDVBS2V1dWxaN0VDN3VQTnlsRG1NZXhkeFBSMEFta3F3UHAyellIeVBCYUc4?= =?utf-8?B?WVRqd0d0TU90SmcrZHF6T1BRRVpCajBvN0RrNStiU0pIdVIvYzhJS2R4NVpU?= =?utf-8?Q?lwfA=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?b1UvTk5kdFo3Y1FyUnR0Q096Yi92NVprZ3o4aXVCU3NoaTVENXduYUpkZitC?= =?utf-8?B?cFdRN0t2WWFsSG1nOThUeUdTZVJDRFhmVGJEMVFXaDJyaUpaWFZpcnV1Tlow?= =?utf-8?B?NlBwTTQzcEQrYm9QRFRvN2x0dzIyMVJGRHdjU2ZLTlJmTE5XZkJiMGRxdi91?= =?utf-8?B?VU9UUFJpNEY3RHNPbFpUY1JVUHc0MUxERjFUQnd1S3RXNVByRHBSb0thTWZ0?= =?utf-8?B?Y0ltVG1yNmY3alk2MDcwaG9iem1nSjdTUHBkai9IUEdWUjlLdzhFbUYySVVm?= =?utf-8?B?NzVaNVlEZDV1aWRmYWRNRXk2RGpka1BuMjVaTE1JZGUzMkMzc0IwM1g3QUp3?= =?utf-8?B?cWVVUHNtdXRkUUZUZWhBamthYVNqZzFlRktsa0lveTBYZllDQWJqSGlKRWFJ?= =?utf-8?B?U3hJV1Z1VVpycjBXRk5VUkx2ZGVZdG9MRkxTRlF2WWtIMDZ1M29XNmFKdVFZ?= =?utf-8?B?V2g0UnBvU0xtUkM3SzZzTndNN2E5YW9NRFE2M2xyT0hmRWVZQzFvMGI1c2Ra?= =?utf-8?B?RHNVRjRHU1VEZ2RtdnJPbVdTZnFBTFgrLzUvRlJoUDMvRmNpeXYweHFHUDh3?= =?utf-8?B?dU9DRmh1SDQ4aVJkZDE0dWtsVmkrb2dqR1UrcTdvZGNoWVN0SElQTitCa3lS?= =?utf-8?B?RzhQZUpzMy84VXo3bk1jYkpJRW5xanhDQVl5dndqbCt5NFBqNGxXYmRnUWl1?= =?utf-8?B?MExlMnRUODFqV0piU1ZYQ044ZjBKSDc4djVzNlVpNDVnSjdPOVpLY2hPcXhL?= =?utf-8?B?K3AxQTJWQjZua0k4SkRNNVJwQWtYOVpKa1NpeEc3aGplTWVHUG00WXd4TlFu?= =?utf-8?B?UzZrMGdMQUd5Y3BYOHMrTUVNYktKOFJGRHJDdXpjdEpZZjBJemprOXE2czlB?= =?utf-8?B?N3hxcE1KdEtQT1hENjZxdisyMHFWeTkwMEVPVzNvZ0N2S2VGc1RIb1B4T3Vj?= =?utf-8?B?b2lDZUp0YTdMVHIvNDUzMVYvZDQxbHJnUVp4Y3g1RllsbnFsQW01VVFjN21R?= =?utf-8?B?R28xcU1pTVhwMXZzMTJUNnA2WEdrK3hZZ1ZaZHlXQythdE42Myt5M1dBVE9H?= =?utf-8?B?TmhKU3NvaE1qMEpaWTRXYWlwZFlBdW5OMzgzNkpMSnNjaE1ObmV5MWRYNFRY?= =?utf-8?B?dU0rZER4UlRoY2FDbjFBbWlDTk5CYjVNQ3VvRXdqekFURHJLZllQeXd4Ymx5?= =?utf-8?B?bUIrMFdUN2RVWmt1RzhJN3hGRmdad0swY3p1cTBmL1RGKzlmOGNJcVp0ZWRC?= =?utf-8?B?NnNZbHo4MjhmNVJEWTR4bUNnMkkrbk5KZmNJY2FZZGN2TExRaTBMdWFSREY0?= =?utf-8?B?Y2xnV25WNGdXaEsvN1JCTlFXQU5qNTEydmxFQVp1Z0hOQUV0K21sb29scEVH?= =?utf-8?B?dFM1ODhHVjJWWUNCN01WYURDWmt0bUovSk00bHNreVMzOTJHVWNKUzFLaS9H?= =?utf-8?B?YmJ0R3JzOFBJL0FMN2R3VVNwRGpXamJySWxCSW5ENjBKOEhRUkRSVi90OXZV?= =?utf-8?B?Rk42SElnalpBeThQMW4xMGtEM2pzalNnVEJQTFRIajcvT203ak9YaDFKNFpp?= =?utf-8?B?SDdqZGpUemJPY0VTOFhxQis4ZG53MHhrSU1zUWJZRUhNMk84bnowVEx6OTg2?= =?utf-8?B?ZXpxTk5zbGFVV09acGMrYnNSQ2I1UDFlUDJEVUVyYW8rNmxZQzFweWZSYlFp?= =?utf-8?B?cG10cjdLN05ZRjdOSExrTEFzdm9JWmhlQUNWT1lPSHZiNUVGK1plN1JlQWUr?= =?utf-8?B?a21XM1dUQ2tKSlBtcGhmZzJnMXBMMmxYVDVYd25VajlOSURublkwSU5jOWEr?= =?utf-8?B?QUNIai9MVU9MNVlxajlhcE5pQURHR2NBRW9vSjhUM0tHVVREei9LRE9PRjIy?= =?utf-8?B?U3J1N2xadDk5UE9WSy9ybng5WUlsWkFmQzFxUjFlMEdabTQrek1veWNqendK?= =?utf-8?B?dHZJbXJpTWt6b2xodW80UGUvQXU5a3Y1TngyQS9Vd0Q2RVBiSDFPQ2pkbFlP?= =?utf-8?B?YXpubSt5bGNNZ21JZWJhSHMveXoxK1lMLzhPK25MeVJ2QjNBMXlSVTFtZFEv?= =?utf-8?B?MWJvMzZ6VndTSFQvemNwNGplMU1rSW5qNGRYa20ydjVWQTFEVzJ5SUJPZnhX?= =?utf-8?B?UjEwYjhDcllwYlNqbWNUcVI4MENqY2VBQ1c0Uk96aS8vUTNaUWpsMytac2ti?= =?utf-8?B?OEVDdmJIOHRod0ZHeEV0V3pSWmZCVisvZk5kNFRVTGtNU0xRZi9UTjdISlFQ?= =?utf-8?B?ODc2M0Y1Mkh5dFQrM3Zoc1gxU2NNZ2U0ZnpVZElqNk1scjNGcm1iK2hVbmVr?= =?utf-8?B?WEJkNUsyT21OWGxTc0cveXBpUmRhSDI5RTVVdlh6VDdxRklYL2M3dz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: d6569e7f-25f5-4820-b8b8-08de5db7b574 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 15:21:13.9408 (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: HqSebTRHa/O9qepqd6a4zLkPHBJlP1e8kAnK6Qh5ZpzDtFBXfkn1s9pG/q97tx/EPpfFwopAcEwbtQRdEKA5AI9Znndx4d+0x1pQ/25DHlI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB5155 On 27/01/2026 3:18 pm, Jan Beulich wrote: > On 26.01.2026 18:53, Andrew Cooper wrote: >> Currently, the BSP only leaves instructions for the APs to adjust >> MSR_MISC_ENABLE if the BSP is found to need adjustments. Particularly if >> XD_DISABLE is needed on an AP but not the BSP, the system will triple fault >> with no information provided to the user. >> >> Rework the BSP and trampoline logic to always read MISC_ENABLE, and clear >> CPUID_LIMIT and XD_DISABLE if either are set. >> >> Repurpose intel_unlock_cpuid_leaves() to be intel_check_misc_enable() and make >> it static in common.c. > Being able to make it static is of course nice. But moving Intel-only code > out of intel.c isn't. Personally I'd favor it staying in intel.c. Alejandro's DCE work will cause this to be eliminated in !INTEL builds. It's slightly ugly, but it's less ugly than having 3 separate hooks. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 27 15:28:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 15:28:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214959.1525204 (Exim 4.92) (envelope-from ) id 1vkkzI-000644-FL; Tue, 27 Jan 2026 15:28:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214959.1525204; Tue, 27 Jan 2026 15:28: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 1vkkzI-00063x-BF; Tue, 27 Jan 2026 15:28:16 +0000 Received: by outflank-mailman (input) for mailman id 1214959; Tue, 27 Jan 2026 15:28: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 1vkkzH-00063o-7j for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 15:28:15 +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 c9f8b88d-fb94-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 16:28:11 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-48068ed1eccso7834125e9.2 for ; Tue, 27 Jan 2026 07:28:11 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1c02f71sm38847980f8f.6.2026.01.27.07.28.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 07:28:10 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c9f8b88d-fb94-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769527690; x=1770132490; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=NnJ5+1MsVwG+j0N54OBzgoK2GuKB33EihIj3f1iWkgM=; b=YxXJaNJor8YL8UebH1ojPIilhWBI/wjBTMYLD+YSvCTAMkKVJTjtivjqSQpIKA77lH 99ObToa/LskKRZHqa6JBkwzaNnZO0Z92I7sDowHoYcz/6i3+k2MU5RXIkbxTmEUgUmSV tmNUh42O6zZi7Rvat6Q7AeJa840gxiebeIi4CqBTO5QewDgxQcGJCTeJ+Lhj0rqQQrlh UXNcIk4LZYYI1NM6Tn2JR/LIZIOqmZgc5CPbiOsUZ0kzmrK3qm9hbghRaJtGcBft4RgY VHLM5T5HpqONd/ILGxHukknKv/c0kegyevCbitaeSLR9L7AVx+7XPEYe5mt+WTNhNVqM X72A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769527690; x=1770132490; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=NnJ5+1MsVwG+j0N54OBzgoK2GuKB33EihIj3f1iWkgM=; b=bMdjlHx7NR6W4oAVoBO0gOGY/6kCUePlPn71cHXaTvvIJN7tNguF2VGrdXziWJRI9/ EKP49pCZ/sIGjjfAWFXJfuj/OPAmzLagAehYUM2B8/wOwVEzIdndLPqIH4CwufQ5iM7Q dIYP87+4prMKeiPpBpxJ+mnHYosf1W7IKd4s9KbOIJS3zGKI1eV49VJDYAJKrbi3sdwi BkpPnS1okhSHomOyqAUydEmiIZPIPktgiIDlm8O84i+0X6hf4EaeTdi41RoFq+8hnrDH VIEKqqPe27IaO9ItAlyHXL/VNpadEw0pMvMnLqnz0/8YiRPQoT9/xxqhl1UDFbC1SHak u7SA== X-Forwarded-Encrypted: i=1; AJvYcCUR1/X8Xqcat+fRdFeRnkiervmuJAObww2EzWekYYk6zSf+gVLps1IstfIPsEnjnOgv5LdWcMa92Y0=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx4JzZ3yF1ogOhjqpR6kW13hRFJMBtYkVr07hchxqY8B8B7iySs p6KHEnjat+BleFWRo94Kk6vXCoOSNt4VWOgUrOvI9A4cT3npAs+WY86+5LbslyYAow== X-Gm-Gg: AZuq6aK1PdyecdTWDCCPl0HBU4WAL7Mc6vkz6RQ4zfcjptRKmrjdiA5wAZlZa5umu5D tTuW3u+SIrnZ6xd40SV/clRJLV0GZfZz5aed5b2O+2XT7w/QRh/koKvxZowh8hHTgeNAWshb3J/ Q5WTetmJ9nsinFtJAeyiVNJdRZkar0+CwP93O7R35chdcZk9MKACn8l3J/8Ei6nvDPM3oWBiSUy Ihx0ZQUpT2orW7qG+7KtHZAQsw4cjfhnGWe8ahfCxdgeXSnhGr5jAKZDYQ7XtqsM93NAz+Msyyu SJSoagKYOj6T6V1Oy3aL9jMD0VK2alv2Z6NW50RSiZiRJjWPxNGBzH3UslHwPerpM1fYRaoCa4E JcmiVKbV+RIQZMhUPhH9BZ7Oc88B+1/1dJ6U/A2EsqIPjJn9QilrM3XKRgJVJZQXxmbYujBHkIm lrYznqPf0uh7HnwykDYpo+I0L2onnQYbm5zP2msJchnlJesNXpu+Vm5XLR5h8JRIeolVtyCZIYh mtoijVQ1qZBmQ== X-Received: by 2002:a05:600c:458a:b0:46f:c55a:5a8d with SMTP id 5b1f17b1804b1-48069c0fdafmr27031075e9.4.1769527690534; Tue, 27 Jan 2026 07:28:10 -0800 (PST) Message-ID: <599b0534-9cbe-4836-8b9e-f43ad8609fa7@suse.com> Date: Tue, 27 Jan 2026 16:28:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 10/16] x86/amd: Always probe and configure the masking MSRs To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-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: <20260126175345.2078371-11-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.01.2026 18:53, Andrew Cooper wrote: > This allows the infrastructure to reused for system-wide quirk/errata > adjustments. > > Replace the call to ctxt_switch_levelling() with amd_ctxt_switch_masking() > instead. The CPUID Faulting aspect is not interesting at this point in boot, > and we want to explicitly propagate the masking MSR defaults into APs. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich with two comment nits: > --- a/xen/arch/x86/cpu/amd.c > +++ b/xen/arch/x86/cpu/amd.c > @@ -162,7 +162,7 @@ static void __init noinline probe_masking_msrs(void) > * parameter of NULL is used to context switch to the default host state (by > * the cpu bringup-code, crash path, etc). > */ > -static void cf_check amd_ctxt_switch_masking(const struct vcpu *next) > +void cf_check amd_ctxt_switch_masking(const struct vcpu *next) > { > struct cpuidmasks *these_masks = &this_cpu(cpuidmasks); > const struct domain *nextd = next ? next->domain : NULL; > @@ -242,9 +242,12 @@ static void __init amd_init_levelling(void) > boot_cpu_has(X86_FEATURE_CPUID_USER_DIS)) { > expected_levelling_cap |= LCAP_faulting; > levelling_caps |= LCAP_faulting; > - return; > } > > + /* > + * Always probe for the MSRs too. We reuse the infrastruture for > + * quirks/errata/etc during boot. > + */ > probe_masking_msrs(); This isn't just about boot, but also soft-onlining of CPUs and S3 resume. > @@ -1015,7 +1018,11 @@ static void cf_check init_amd(struct cpuinfo_x86 *c) > u32 l, h; > uint64_t value; > > - ctxt_switch_levelling(NULL); > + /* > + * Reuse amd_ctxt_switch_masking() explicitly. This propagates > + * quirk/errata adjustments made duing early_init_amd() into the APs. > + */ > + amd_ctxt_switch_masking(NULL); Have the same comment also ... > --- a/xen/arch/x86/cpu/hygon.c > +++ b/xen/arch/x86/cpu/hygon.c > @@ -32,7 +32,7 @@ static void cf_check init_hygon(struct cpuinfo_x86 *c) > { > unsigned long long value; > > - ctxt_switch_levelling(NULL); > + amd_ctxt_switch_masking(NULL); ... here? Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 15:39:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 15:39:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214975.1525225 (Exim 4.92) (envelope-from ) id 1vkl9d-0007zZ-Ec; Tue, 27 Jan 2026 15:38:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214975.1525225; Tue, 27 Jan 2026 15:38:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkl9d-0007zS-B8; Tue, 27 Jan 2026 15:38:57 +0000 Received: by outflank-mailman (input) for mailman id 1214975; Tue, 27 Jan 2026 15:38: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 1vkl9b-0007zM-Vy for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 15:38:55 +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 48e5ef88-fb96-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 16:38:53 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-47ee301a06aso66633275e9.0 for ; Tue, 27 Jan 2026 07:38:53 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804d3fda30sm138784495e9.1.2026.01.27.07.38.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 07:38:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 48e5ef88-fb96-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769528333; x=1770133133; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=MwJXR8XvquumI/9h72Dz525DVMDvJUaf5Fto9urwqvk=; b=ETY+k9lBFhfWv5SJ1Gk8k2aeVgPpizSoW7z7Ia920T/apqpeA+NJsgc2ckEs73tVPm J6k8GV0uU+udh627G76rTvL0qCEchXdaMYhhi6saS0F1+/rmxZUwb3+vh2Q4QMCLOb20 sKVhKnlSKR6pq37b/FpMwlMp9iOC/roO2NB2aXwj1gOp0nBe9NFdbGfze2wMMiOKe9JT dKSvUDY8YCJpj7BrD5DPNYnmNGHz+MiSMX5FjfyrUeYe6QQVICFvussy9YT8adQ039MN A8JK6eCcYsHZbLf1jo8+3mUez43tPK/ClbI409LQoMfX84Q440iFbpdddKhi6Dqz9gg5 xTVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769528333; x=1770133133; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=MwJXR8XvquumI/9h72Dz525DVMDvJUaf5Fto9urwqvk=; b=VkFtkmumAk0jiso976Rj6rD9Q9tdDHwPigMSuxUFxq1IxqprirQ1TIhyaKpyISsBjS vDlNjKwukTdevU4pF47OcFhlsyCVe9yppyZdaBIhZ/xepcxJBHRHURvbAa0OXsBxQUC5 0dA0ly0bnopeyuIp8SAZo01PKuNFfMwiBoppzr7AwUbDQSEQjsdlivl6wGRV+5pzvNAT akUtp/PdH7M10QETg5N04a217XGy7yaIM71UMzbikVKs+kG963so6kFDKIUX4Abzzp1i RY7tIoXspBEGEGZ8e3TsEds76LM2WP39tfyhP7O33H6iRPHGQ/4AeI6+Uy6AGOSsWM1K FQrA== X-Forwarded-Encrypted: i=1; AJvYcCVGaNRkSke0hbBJKWO/wsYj5K7dGnCtp2JLZo5k4tnQ5XUMPkx2zNKcnVAD5SQ3Jvbiw+XMfTKdwaw=@lists.xenproject.org X-Gm-Message-State: AOJu0YwXJyGrNOsd13eIKcpirj+J48GRpEx513MYefEGpaopNOBgSbfl JSfyeZcG6rJPqfOvQzx9n63LFEMflxABL6wtN8lhCcthnYpIdw8BnrLg8Wt36f48FA== X-Gm-Gg: AZuq6aLZuFwHZC6cuHDQ8+pdVTMCQcqabmN9Sui9OnCQIjkSb40vkS2vlBsUIyY3iq7 z3ttS4jtb8Cs36bqxhfrC42bNNWWXm5CUBRBSXcd1F+FPU+mxYOL+ymY3IJYRcbQq62yMc04RmM ndQQ3oPVxZeXaQGm+5E+JbHdsIBv8WKKbIDjD2OvO1ljTrpsBbgXQnVA/4YNj/BkS/ZAJfRlqhz qTJ1YJ9F1pnQVE4M/4Cmkx1dp4Qnv1RlzlvHPTTX6YLmUMU5owZlzrEmTWeUuCHPYiafXC9lEU/ SPG6L1cthmyJY6+D/5Rx/1/8tP9hF8vsl0Pp+PCXp9P1sjngH1oyM/TrXC8G8DnjopZ4KsPjXNG U+FSrkEeBFIQ0ZVS4ap/H1JnaKN/TfGt9Yjul02ahRoUEQrJd0bOZ243eR1zNVwDn5Gb3YYA4v3 RFpxxO0NL00ccN3z9HAIZr+SXIEPWMb6gKiFwQ3vw1/oEiC824kvHyaP8lMhUD7pMMnA7bNUt/k HU= X-Received: by 2002:a05:600d:8445:20b0:47d:3ffa:5f03 with SMTP id 5b1f17b1804b1-48069c54b8bmr23359115e9.21.1769528333264; Tue, 27 Jan 2026 07:38:53 -0800 (PST) Message-ID: <617d4ded-7da2-4075-82c6-7be61d151a41@suse.com> Date: Tue, 27 Jan 2026 16:38:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 11/16] x86/amd: Fix re-activation of TopoExt on Fam15h CPUs To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-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: <20260126175345.2078371-12-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.01.2026 18:53, Andrew Cooper wrote: > init_amd() tries to re-activate TOPOEXT on certain systems, but only after > amd_init_levelling() has calculated the levelling defaults, meaning that the > re-activation will be lost on the next context switch. > > Move the logic into early_init_amd() so it takes effect before calculating the > levelling defaults. > > Signed-off-by: Andrew Cooper I'm sorry, but as this is being moved and tidied some, I've got some remarks: > --- a/xen/arch/x86/cpu/amd.c > +++ b/xen/arch/x86/cpu/amd.c > @@ -620,9 +620,32 @@ void amd_process_freq(const struct cpuinfo_x86 *c, > *low_mhz = amd_parse_freq(c->x86, lo); > } > > +static void amd_early_adjust_cpuid_extd(void) __init? > +{ > + struct cpuinfo_x86 *c = &boot_cpu_data; > + uint64_t val; > + > + /* Re-enable TopologyExtensions if switched off by BIOS */ > + if ( c->family == 0x15 && c->model >= 0x10 && c->model <= 0x1f && If this is done by BIOSes, why would it be constrained to a certain model range of a certain family? > + !boot_cpu_has(X86_FEATURE_TOPOEXT) && > + !rdmsr_safe(MSR_K8_EXT_FEATURE_MASK, &val) ) > + { > + val |= 1ULL << 54; > + wrmsr_safe(MSR_K8_EXT_FEATURE_MASK, val); > + val = rdmsr(MSR_K8_EXT_FEATURE_MASK); > + if ( val & (1ULL << 54) ) > + { > + __set_bit(X86_FEATURE_TOPOEXT, c->x86_capability); This shouldn't be needed, as identify_cpu() will obtain the updated value anyway. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 15:44:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 15:44:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214988.1525235 (Exim 4.92) (envelope-from ) id 1vklEZ-000196-4G; Tue, 27 Jan 2026 15:44:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214988.1525235; Tue, 27 Jan 2026 15:44:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vklEZ-00018z-1U; Tue, 27 Jan 2026 15:44:03 +0000 Received: by outflank-mailman (input) for mailman id 1214988; Tue, 27 Jan 2026 15:44: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 1vklEX-00018t-In for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 15:44:01 +0000 Received: from mail.zytor.com (terminus.zytor.com [2607:7c80:54:3::136]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fe687e20-fb96-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 16:43:59 +0100 (CET) Received: from ehlo.thunderbird.net (c-76-133-66-138.hsd1.ca.comcast.net [76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 60RFhKjv3682492 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 27 Jan 2026 07:43:20 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fe687e20-fb96-11f0-b15f-2bf370ae4941 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 60RFhKjv3682492 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026012301; t=1769528602; bh=5qBENNuWOqGpe79fFGXK8jFG5DwPngcXBIqkvHrIX6w=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=RbS9+E7hGn142ybu+NiHBttsuc4cfbL+38yev9p//9S/bLLnfJfEOR1Cy3fwhwpyU qQtX8hdWqxiRQp20ZFVrtvA/x2QA3+SyQvS01WwxapJiBaHqlaCbgK2G+y+lzG9B5/ tMIUtToi12b7gQ8gMMH1NUnUzOCKOGa80jzXUyfP3MtL09G3CRFeLl01hJirMZKbBd pz3Q6mWmsa3YszhzbGQ4rQfHlcAfuzwMb7fWykXPbw4q8RKKSG/3+XId3DOXP+FM2Z 4UYnc31Kzm5ufdJtruWOiRb9ygoym7KavPFdUxiF0ag6/xNOlQgOIpUuW9jHQAUabo e6dLvMu9/nqLg== Date: Tue, 27 Jan 2026 07:43:14 -0800 From: "H. Peter Anvin" To: Hou Wenlong CC: linux-kernel@vger.kernel.org, Lai Jiangshan , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Juergen Gross , Boris Ostrovsky , Ard Biesheuvel , Nathan Chancellor , Masahiro Yamada , Vitaly Kuznetsov , =?UTF-8?Q?Thomas_Wei=EF=BF=BDschuh?= , Brian Gerst , Josh Poimboeuf , Andrew Morton , Alexander Graf , Joel Granados , Thomas Huth , Uros Bizjak , Kiryl Shutsemau , Pawan Gupta , Guenter Roeck , "Xin Li (Intel)" , =?UTF-8?Q?Ilpo_J=EF=BF=BDrvinen?= , xen-devel@lists.xenproject.org Subject: =?US-ASCII?Q?Re=3A_=5BRFC_PATCH_0/5=5D_x86/boot=3A_Allow_to_perfor?= =?US-ASCII?Q?m_randomization_for_uncompressed_kernel_image?= User-Agent: K-9 Mail for Android In-Reply-To: <20260127120307.GA20714@k08j02272.eu95sqa> References: <7716B334-004D-4CBB-9237-E8AE5CE696CE@zytor.com> <20260127120307.GA20714@k08j02272.eu95sqa> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On January 27, 2026 4:03:07 AM PST, Hou Wenlong wrote: >On Mon, Jan 26, 2026 at 11:30:28AM -0800, H=2E Peter Anvin wrote: >> On January 26, 2026 5:33:50 AM PST, Hou Wenlong wrote: >> >Hi all, >> > >> >This RFC patch series introduces relocatable uncompressed kernel image= , >> >which is allowed to perform kerenl image virtual address randomization >> >in 64-bit booting entry instead of decompression phase=2E >> > >> >- Background >> > >> >Currently, kernel image virtual address randomization is only performe= d >> >during the decompression phase=2E However, in certain scenarios, such = as >> >secure container environments (e=2Eg=2E, Kata Containers), to speed up= the >> >boot process, the system may boot directly from an uncompressed kernel >> >image=2E In such cases, virtual address randomization cannot be execut= ed=2E >> >Although the security enhancement provided by KASLR is limited, there = is >> >still a potential demand to allow uncompressed kernel images to perfor= m >> >virtual address randomization (for example, future support for x86 PIE= )=2E >> > >> >- Approaches >> > >> >Currently, the x86 kernel uses static compilation, but it retains >> >relocation information through the '--emit-relocs' option, which is th= en >> >simplified into a relocation table using 'relocs' tool=2E To enable >> >virtual address randomization for uncompressed kernel images, relocati= on >> >information is required, and there are several possible approaches: >> > >> >1) Who will perform the randomization: >> > >> >VMM: The VMM reads vmlinux=2Erelocs after loading vmlinux to perform >> >randomization=2E This would require additional modifications to the VM= M, >> >and vmlinux=2Erelocs needs to be packaged when shipping=2E >> > >> >Kernel: The kernel performs randomization itself at the kernel >> >entry point, requiring no modifications to the VMM=2E >> > >> >2) relocation information format: >> > >> >vmlinux=2Erelocs: It only contains the necessary relocation entries an= d is >> >simplified, making it small enough=2E However, it is a format defined >> >within the kernel that was previously used only internally and is not >> >part of the ABI=2E >> > >> >rela=2E* sections: It is the standard ELF ABI, but >> >it contains RIP-relative relocation entries, which are more common in >> >kernel, causing the kernel image to be larger=2E >> > >> >- Implementation >> > >> >The final implementation of this plan extends the 'relocs' tool to all= ow >> >the insertion of relocation information into a reserved section of the >> >kernel (referencing the MIPS implementation)=2E This enables the readi= ng >> >of that information and subsequent execution of relocations when booti= ng >> >directly from an uncompressed kernel=2E Currently, this implementation= is >> >only available for 64-bit and has been tested with both PVH entry >> >booting and standard 64-bit Linux entry=2E And the default reserve siz= e is >> >1MB for now, which is enough for defconfig=2E >> > >> >- TODO >> > >> >Clean up the decompression KASLR code to allow it to be shared with th= e >> >booting phase=2E >> > >> > >> >Thanks! >> > >> >Hou Wenlong (5): >> > x86/relocs: Cleanup cmdline options >> > x86/relocs: Insert relocations into input file >> > x86: Allow to build relocatable uncompressed kernel binary >> > x86/boot: Perform virtual address relocation in kernel entry >> > x86/boot: Use '=2Edata=2Erelocs' section for performing relocations = during >> > decompression >> > >> > arch/x86/Kconfig | 20 ++++++ >> > arch/x86/Makefile=2Epostlink | 33 +++++++++ >> > arch/x86/boot/compressed/Makefile | 6 +- >> > arch/x86/boot/compressed/misc=2Ec | 8 +++ >> > arch/x86/boot/startup/Makefile | 1 + >> > arch/x86/boot/startup/kaslr=2Ec | 116 +++++++++++++++++++++++++++= +++ >> > arch/x86/include/asm/setup=2Eh | 1 + >> > arch/x86/kernel/head_64=2ES | 7 ++ >> > arch/x86/kernel/vmlinux=2Elds=2ES | 20 ++++++ >> > arch/x86/lib/cmdline=2Ec | 6 ++ >> > arch/x86/lib/kaslr=2Ec | 5 ++ >> > arch/x86/platform/pvh/head=2ES | 15 +++- >> > arch/x86/tools/relocs=2Ec | 64 ++++++++++++++--- >> > arch/x86/tools/relocs=2Eh | 15 ++-- >> > arch/x86/tools/relocs_common=2Ec | 24 ++++--- >> > 15 files changed, 309 insertions(+), 32 deletions(-) >> > create mode 100644 arch/x86/Makefile=2Epostlink >> > create mode 100644 arch/x86/boot/startup/kaslr=2Ec >> > >> >-- >> >2=2E31=2E1 >> > >>=20 >> Hi! >>=20 >> At a very quick glance this seems like a very reasonable thing to me, b= ut since the intent is reduced boot latency (a very worthwhile goal!) do yo= u perhaps have any measurements to show how much improvement we are talking= about? That would be really useful=2E=20 >> >=20 >Hi! > >Uh, sorry that it may not meet your needs=2E In fact, it will slow down >when booting directly from an uncompressed kernel=2E The improvement >described in the patchset compares booting directly from vmlinux versus >booting from bzImage when we want to enable KASLR for guests in MicroVM >scenarios=2E There is a similar idea in [0], where KASLR randomization is >implemented on the VMM side=2E Now we want to implement it directly in th= e >guest kernel to reduce modifications to the VMMs=2E There are some >measurements in [0]; however, the comparison is between vmlinux and >bzImage=2E > >In my test environment, compared to the original direct kernel booting, >it would add 2ms for my test configuration [1] based on the Kata >Containers repository due to the self-relocation phase=2E Booting from >bzImage does not affect the boot time, as it simply inserts >'vmlinux=2Erelocs' into vmlinux, resulting in no change to the total size= =2E >The decompression time should also not be affected; I didn't notice any >difference when measuring the decompression()=2E > >[0]: https://dl=2Eacm=2Eorg/doi/epdf/10=2E1145/3492321=2E3519578 >[1]: https://raw=2Egithubusercontent=2Ecom/virt-pvm/misc/refs/heads/main/= pvm-guest-6=2E12=2E33=2Econfig > >Thanks! > >> Thanks!=20 Didn't you say that that was the reason for this? I'm confused now=2E From xen-devel-bounces@lists.xenproject.org Tue Jan 27 15:44:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 15:44:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1214995.1525245 (Exim 4.92) (envelope-from ) id 1vklFG-0001bU-Cs; Tue, 27 Jan 2026 15:44:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1214995.1525245; Tue, 27 Jan 2026 15: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 1vklFG-0001bN-9z; Tue, 27 Jan 2026 15:44:46 +0000 Received: by outflank-mailman (input) for mailman id 1214995; Tue, 27 Jan 2026 15:44:45 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vklFF-0001Ph-66 for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 15:44:45 +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 1958445d-fb97-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 16:44:43 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-48068127f00so7223705e9.3 for ; Tue, 27 Jan 2026 07:44:43 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1f74b15sm38612832f8f.35.2026.01.27.07.44.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 07:44:42 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1958445d-fb97-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769528683; x=1770133483; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=WjE2ojfQ+bQT7F9VzxjRPMNn4rFs09LKxqqw5uPGYC8=; b=Zk9a7Ty8jed2S5K0ckc0RiZnQeqQGyvl3jsEDhuj/fHmuDldndw/7jvnXyynQbJaFv vJYVQS0p+KZKM4+hOKvtJcTtTrRmNScbQmsh/8Kbj16q5jRyprvQYQF1mXkfmiAlL4Wt qnJjSyGGEY4vwo1HUIqZJPWMywYsNC+l1SpZy6JtA9F76c5t5Cuhi20tfsmOQenfVPJv Wa++JAfYQHoyYfiED3MENX4E2tBRVZS3CNoiOEWjVgkozJwtxEme3al4LVgt/9TYx3Sn RSgzN8HIDwuQnFqd4ZQZ0WE3cFVAnz4tqtFlw5J92lfOQvqsS/oiKNz4V5tiFEqiBw3w kmBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769528683; x=1770133483; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=WjE2ojfQ+bQT7F9VzxjRPMNn4rFs09LKxqqw5uPGYC8=; b=T0UaahzAolWgbw3hjodXt92kvZGc9VYyaEaR482ojinZ9w99IL4OIiRb4cgzYWeOLf 06+/EAKaeU1k0XLnqlVIadrJIWrXnJKtuMrqzRA7HuvQfsdT50v4uYrJrO8OFAOIFmcr Heh6LrEadCv71wJluGwTviUJpzHJrHTpX1XofubHNqJn6FxFVpBBvdjjT9dETA8htvrn W3G3T04vYePGOEmulDc7ugk4Z4iAvLxdNnCRr8FqTD+L8bVam8cpyeJKvljMXlsoPVcx /sMYjmtM5PbHxO0TgpzSHUnybV9U4W7HwGrhhMS46AT0dwaS8d6/Jk2ksAnCJr9XFVO7 W7uQ== X-Forwarded-Encrypted: i=1; AJvYcCV3XhMzmjlQhLFt0MvZ4ks2rAkScJpJu86oA9fnbasmHsZCcy9CDW3A6ncRH24QwM5ZuHAaDQOEBFY=@lists.xenproject.org X-Gm-Message-State: AOJu0YyMTolLkQnMyK1qeavkWJctGlVWX5dhmqHWCXvG/N7zVbwiiLiY vcv1obwWqzCTdUEKa9ZdjsgzY5WG9xur9iu55qD0JKBljGUmMFihLpjjCfgUQOhzCw== X-Gm-Gg: AZuq6aJEQd6AoVcRGrPpOugwhyQhvV/CizkTk9kcLco7GF89r++YJnrpaSR+qXqhWP4 xM5n6rjtZjvWFvTT+w3GeUpz1GYdkd91mq5rDVwP2NTNlmvAnPZTLNyOGmhfATAAqkfX/yB9BkQ +Oxri3ik+cMmYcdvU3fFg4fgMNl7pkawY3ticMaZ1PjZFmCBCmyK4Dh5cUzwVYjlETBVhwBmebU aRKzmGHXSWT4pQbh0l45+ZwQXxZK62B/2Y1MaSwQPTp3SULNIHwCgIGvl7/rtONNfAHBusBqknc DAp70CcxBO1fgcGmpAjosenmY7H2LBzsfMEWeCsxtCxgi/DfY5C/qyFRO1/KKzP4OqJaAGYAZEq mpILKaZTBMG0+P7rFKBGovBuyx2OBfutWSUsA3yWFNxjpL11UMc2mSxPHxCMeSMv1swvCRySjE9 qgUSYe7UKWQyDNeKmW5skiIBVjPXvQXi3lZjS2xIxdcpQV/VaPij3zwXVkUlpMlfApyFVQXjSsW jA= X-Received: by 2002:a05:600c:8117:b0:47f:b737:5ce0 with SMTP id 5b1f17b1804b1-48069c5a468mr28270365e9.23.1769528682728; Tue, 27 Jan 2026 07:44:42 -0800 (PST) Message-ID: <1c894d22-697f-4f96-90dc-4d0101fee7e4@suse.com> Date: Tue, 27 Jan 2026 16:44:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 12/16] x86/amd: Probe for NX support and re-activate if possible To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-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: <20260126175345.2078371-13-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 26.01.2026 18:53, Andrew Cooper wrote: > An AMD Ryzen system has been found with a firmware option to disable NX. Like > we do on Intel systems, try to detect and undo this stupidity. > > Link: https://xcp-ng.org/forum/post/80714 > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Roger Pau Monné > CC: Julian Vetter > CC: Teddy Astie > > Somewhat RFC. I don't particularly like the double handling of > MSR_K8_EXT_FEATURE_MASK in this function, but I can't find any way of making > the logic legible while trying to dedup the MSR accesses. Looks reasonable to me as is. If later someone has a neat idea for de-duplication, it can always be done incrementally. > @@ -639,6 +640,40 @@ static void amd_early_adjust_cpuid_extd(void) > printk(XENLOG_INFO "CPU: Re-enabling disabled Topology Extensions Support\n"); > } > } > + > + /* > + * Probe for NX support if it appears to be unavailable. All 64-bit > + * capable AMD CPUs support it, but some firmwares have an option to hide > + * it in CPUID, apparently for "feature parity" with Intel platforms. > + * > + * Unlike Intel, there's no active indication that this has been done. A > + * conversation with AMD suggests that if we can set EFER.NXE, then NX > + * will work. Use this as a heuristic to probe for support, coping with > + * the fact that a hypervisor might have really disabled and blocked NX, > + * and not emulate the mask MSRs either. > + */ > + if ( !boot_cpu_has(X86_FEATURE_NX) ) > + { > + uint64_t *this_efer = &this_cpu(efer); > + > + if ( wrmsr_safe(MSR_EFER, *this_efer | EFER_NXE) == 0 ) Would you mind using ! here, just like you do ... > + { > + *this_efer |= EFER_NXE; > + > + if ( !rdmsr_safe(MSR_K8_EXT_FEATURE_MASK, &val) ) ... here? > + { > + val |= 1ULL << cpufeat_bit(X86_FEATURE_NX); > + wrmsr_safe(MSR_K8_EXT_FEATURE_MASK, val); > + val = rdmsr(MSR_K8_EXT_FEATURE_MASK); > + if ( val & (1ULL << cpufeat_bit(X86_FEATURE_NX)) ) > + { > + __set_bit(X86_FEATURE_NX, c->x86_capability); Again this shouldn't be needed, as identify_cpu() takes care. Unless in this case it matters for the time in between? Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 15:46:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 15:46:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215003.1525255 (Exim 4.92) (envelope-from ) id 1vklHM-00029f-NV; Tue, 27 Jan 2026 15:46:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215003.1525255; Tue, 27 Jan 2026 15:46:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vklHM-00029Y-Kk; Tue, 27 Jan 2026 15:46:56 +0000 Received: by outflank-mailman (input) for mailman id 1215003; Tue, 27 Jan 2026 15:46:55 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vklHL-00029S-DE for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 15:46:55 +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 6753578b-fb97-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 16:46:54 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-47ee9817a35so46085175e9.1 for ; Tue, 27 Jan 2026 07:46:54 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806cddffc0sm1389375e9.5.2026.01.27.07.46.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 07:46:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6753578b-fb97-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769528814; x=1770133614; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=iTbCjvs2wDEsCHTImc0dEch9VLZ/c05EUGj1o2/zFs4=; b=O65WeHVHvk0XPbMOJKfBz7qzM4+CirTg2Vy4pyIcTOkd5oDuM1vW9HIXe4r1iGZQOm 9PX8gu5lTAzcFE6vzXdFeXP2sEWJoX/xx0dLEJsFSCfiKhsNK5DFQ/mv7NCFyYBhO2cv 3zb6ZiGqvBCNPTBf9C3EO/uj63xh7rMZ677DRceINrG/3nknHYYv/F81GXeVKC6KaXXG ZpYbdydQG8xFGlUdDAazoI7H4DRFFhTniIOry/V2xsTwJ4iqBYkCvspqWS5K245fXC/M NxNfNGjtUbZalKdhpEhrdB+szBZvFv2jrWwZifC7a+MFYj4xhzFxEGddHGeT6Zar26bv x2VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769528814; x=1770133614; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=iTbCjvs2wDEsCHTImc0dEch9VLZ/c05EUGj1o2/zFs4=; b=mFebzaLDGGiGZ1I11hAME4nk3YZ2tnPREyhVLjNcRZ45bQjBmvhjRO5f9CpMX4wLoJ JbR2rkWnvJIqRWo4lFiE3kN4g4MU16uOArCdXoDerx8aiIH6ctg894MMcf9WCIYU2Qsv qtqjN28NeQRW7dOaL1yj0q8XN9g7nKQjse7tSi+hN4o6M2tf528vdTpaBLwjaK2+yngT il9/pgNmuJYvFB9KLzq5Cn0SWHkKRD6lQZ2WzrWot2BChSp6rhx5if51rPqfeiIGcJm3 rv/rquQ26WEtFfWpF5Gks7GPID2jIBW3yDR7IcfrTjS4bArssLNDmoPHk1bRW2v7MbvQ xeBA== X-Forwarded-Encrypted: i=1; AJvYcCUqPtOkxzf/yyfrqOYY4sdlH7UWoqHwI4L7Mkf0CgTMcs6LRNKKHGVlahy+EsQxfkQIGMSLtYQR810=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxi0ULZBYIzPqdXsJXfn7zuf3yoYYp7nXBZEmy6CZiE6Si+zRCE iZQB9Z9uEUyOdQ9aoC/RKgHt80/z+sagjG3aw7xfxxH2eCyuVhE6z0uSAldAPTnqLg== X-Gm-Gg: AZuq6aJSdrMwdlY/bIwzuISKQxwFGPlHvJtUqdlmhCjR7BrXzeskz5Rjm3vVfhn5i4z 4QFuwLHTDMO1Nas8dPmae/iUNvT+ZQUY/2zccSLd/0G0dlTlc+IVYGBcEspORaW31GbdhOV1cgY EBsD455BWQ9L4K+Xj6bdz4FI4x0pN7rv/gOum8ea1RffnymKYp/b1hfOvxaZmXuKRyoQtnvtEzd ui+e9Tdts5NgEF1GShtjIn1JZNzGGOGk2oTkGYF+tkP9eQ0gjIf5uflztLiyZiyTwoDkUWvoQ6b MkvVJyxdc4rQHL8K6MUkVq6ZSYbubRP3H9spimtFW5FNqYlXPHQ+QJEETVLTbtihNIlj9yLJPXV 3CnTdsfuIAjk+S4LBZz2uFDNdLo7eRR0mhwEjcZFmOBwsLHBxzZskomQTTYNQpEd6mYBc26Yosi OEVVvFqLFgORPSXIa0NAT0E7BNSWFay1BgG5L1LaJ8rbJ0AuSCjm4avNls4UKEDUCem1YNcdEdG bo= X-Received: by 2002:a05:600c:3b96:b0:46e:4e6d:79f4 with SMTP id 5b1f17b1804b1-48069c353ffmr37100215e9.15.1769528813739; Tue, 27 Jan 2026 07:46:53 -0800 (PST) Message-ID: <8ca9d75b-2812-41a0-b62a-7b8e3260bf07@suse.com> Date: Tue, 27 Jan 2026 16:46:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 14/16] x86/cpu: Drop default_init() and default_cpu To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-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: <20260126175345.2078371-15-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.01.2026 18:53, Andrew Cooper wrote: > While the comment is reasonable, clearing SEP as the only action for an > unknown CPU is useless. Drop the infrastructure. Fair enough. > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 15:47:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 15:47:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215012.1525265 (Exim 4.92) (envelope-from ) id 1vklI5-0002o1-0R; Tue, 27 Jan 2026 15:47:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215012.1525265; Tue, 27 Jan 2026 15: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 1vklI4-0002nu-U1; Tue, 27 Jan 2026 15:47:40 +0000 Received: by outflank-mailman (input) for mailman id 1215012; Tue, 27 Jan 2026 15:47:40 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vklI4-0002nk-1r for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 15:47:40 +0000 Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [2a00:1450:4864:20::434]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8156af71-fb97-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 16:47:37 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-43596062728so4174162f8f.1 for ; Tue, 27 Jan 2026 07:47:37 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1c02f71sm38946625f8f.6.2026.01.27.07.47.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 07:47:36 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8156af71-fb97-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769528857; x=1770133657; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=BUnWsKKhYNy12giBBES73rO+qA/Mq2TTcqo9EdJpk+A=; b=UtsncFsPYPLCwcTrVQJEI/XVsqtURUh+uYjE81QGpJxzQIZH2Aua98g5d+rAs7jroM Vo4sHH1BagVmWo7KQmBsR3PIGVxoPpRCkoMEUPd7mcJqLPuAStM9MvxSEMSSHzXj1v9a bpmgYT4+evaYtrtbbhg7lo1627C6MhGqPOz1W44m6WklxZLBoehAqrgpcqDsiNK7fOVp zFrHehncfsGZiEXLLO3oz5aKbkq/S1hkIsf9FTRUBOUB9j27pFxkM4ugw1iHRV9VwXjr hK+BoQHkbTLJVA5AnN1Jty9SCskR56AHowoEmQ8YoU5jhLB5YB3RfzyxIv/t+SXAD7PA STzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769528857; x=1770133657; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=BUnWsKKhYNy12giBBES73rO+qA/Mq2TTcqo9EdJpk+A=; b=BHP+ikpd1oGBZLhyUZ7SR+msGyoyewlK58ujwYLUG63sStdKbWncEDLiuhfgTDGvb9 J8YoQCLGwLhGjdPV+DtQVgykZSnmDtvWXjdAYXX3hyZGy2xax0REAj3t5oYFgW5yD69n OLkiVguUTawMwl75EMaAEdYLmzz4o3FPrH9tN8Qr9Pj3YNpJ9MbW9G3euqPaADCoIbWl jpDYbBkEjhI4WoHoiL5xOfLz2UA70hVjd709jXxIi3fkcB7+AGAEyuRFaqvu18i/yCz7 tdIx0ZBep2KkKmCo70FHBR6mxcsl5ejQqBViu/v1FJTT98cNoawjSEOTHLEKJOume3gq 8XKQ== X-Forwarded-Encrypted: i=1; AJvYcCUO2LmPYIprYe3CJDvyianLP4nfydSrhGQwSRsa9kCzrHQkESsP0JHynnZeztphlWBzAia7GH1ZIX4=@lists.xenproject.org X-Gm-Message-State: AOJu0YwIEsb0ro+ua+mTSQWrMfZ/TeeHbEnd2Wy0RihkW+S4JHExKBvh UeeVqjylMMGIKkdT/dAHETRonbMRL9XOJep05B93Ezk+f0cgR3wA/IJ/OxvtjyXizA== X-Gm-Gg: AZuq6aIwnOeNPkVxW8ELu/kdg4qocToT1F1xpYKP9U93Buz5A2h+R4F5sJFZ6XSwcA0 cbkWSzDd8tkttQpj5qO04ifdlcg/isHrJDp1hh3AAsHvb0YVLDx+lkARGv9hx0ZrrHfIVFkTKzo tL5E5iAdAkIcn/gS7zHcSQsJJ16LI57op8l4Bi4fxqGUxLynKEoKwiDazM121Jzr3DcxOWrdcMQ 504U8FOpD8Bwiryk1GQoUQo/9r6h5Ega/RxFCZcu/g2e/79SkB5ohVS36cSys5hGHQ5909WTtSX D2kdbP+c+U1y73dZso6ItsiQLtUyJj2DcRnHpOrW4VJARyHPiFBrLGnkJzlsAKfLFk8WZScMveG f0fb34/ckzKBbtv4DRqpbZl8rLyFx97EKy01VhHOq3QFkNJQKIMm5q2WSssgrd7aGXMUTwAaTol i+jhPee6TmnfbO6TIvpxj8unSyB8EeeeF6Ucyr+nSGZFAxBXtSCVXBN0wLMn3LZneVqUXodcQor v786Q+78STPqA== X-Received: by 2002:a5d:5f45:0:b0:432:5b18:2cc3 with SMTP id ffacd0b85a97d-435dd0a7ab9mr3455569f8f.4.1769528857238; Tue, 27 Jan 2026 07:47:37 -0800 (PST) Message-ID: Date: Tue, 27 Jan 2026 16:47:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 16/16] x86/cpuid: Drop the include of public/sysctl.h To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-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: <20260126175345.2078371-17-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.01.2026 18:53, Andrew Cooper wrote: > Following the removal of XEN_SYSCTL_get_cpu_levelling_caps, asm/cpuid.h > doesn't need to include public/sysctl.h, but several other header files were > picking up their includes transitively through asm/cpuid.h. Untangle them. > > No functional change. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Tue Jan 27 15:49:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 15:49:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215024.1525274 (Exim 4.92) (envelope-from ) id 1vklJb-0003WP-DR; Tue, 27 Jan 2026 15:49:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215024.1525274; Tue, 27 Jan 2026 15: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 1vklJb-0003WI-Am; Tue, 27 Jan 2026 15:49:15 +0000 Received: by outflank-mailman (input) for mailman id 1215024; Tue, 27 Jan 2026 15:49: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 1vklJa-0003WA-9U for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 15:49:14 +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 b9bed607-fb97-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 16:49:12 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-4806bf39419so3150965e9.1 for ; Tue, 27 Jan 2026 07:49:12 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806cddffe9sm2756565e9.4.2026.01.27.07.49.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 07:49:11 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b9bed607-fb97-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769528952; x=1770133752; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=DjmZHlv3QHj/nQyTJTnkxKCd1txqbYrasXXX6umLMxA=; b=X1jQPrwFolg7EV4YMTawO+EciZaKGmMmYKgjhUeCc5nG3P5GjFw4gtJqg7uIXZVIs6 sEzf/ekh/Gp7+lP6z6ewsjU99X4q6j3r3CNuHs0stpaxdECFgOnGVbwt9ykNqi1z5WI4 HXct9/uXnURfeYBsCKjWNihpfRvrXh7k6JWf0lDR8Ka1Uc55+V/UCgvFRa/s49lMwDXy t/N2SMkoTR88dFyeOyetmL8Gk891YU7rJ7S3hSCA3PGh2AC97okTD6/Bdfu4knUeRh5o D/sFU/WivmuQ+Rf5DcWeb8sh6zsBl61fGiQmZraa6IgxbmAzlrB20QwA4pGOwHTZFpI4 hHCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769528952; x=1770133752; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=DjmZHlv3QHj/nQyTJTnkxKCd1txqbYrasXXX6umLMxA=; b=ee2Efnxr0ONwRa52QQyGNASjx2/7W8v1sVayAsZD2LQ1lKkz+5Y7NLa/LmyDXxfSc3 TxE6BC/YmEPg4EUlBfSD1nz/kB7F3y2beLJP/oxnXglpQjwqnPGfldKRcLmiZC4Pb+Vk aYzXPQdXVgDQ1cHyVejeyHTulFVSk/FGf8HuMCv8QFNkEDGu7NUZTO/4cxDnDTcp5MGg 7e4tw5aS/px9+tz7Cd2BgitIxzpogmctVwZkaUwoOIfp64SNQKYJwT9ap4hZo74guAis GmZoq3TF5/tuBI4myOk+5bfhtRcRopndE6y8yGvigkgu/1fTIFFvFBoCtFKsKUwiXMhn H49g== X-Forwarded-Encrypted: i=1; AJvYcCWKO4ZUwhjN4QBNdnfOvZm2yRX052jxi1SmIPGnmo5tF+xxKHqctFIk6xGQ4qvbcYE8szn1bt56fwY=@lists.xenproject.org X-Gm-Message-State: AOJu0YwZ1hOlzdyKVf3zNZsRoYoMXKxSESr+YMzfAQSta3AB9xkmSKiD OJ2dpVEpqxqcvhVxVKGENqFYtv61UIkahLO5KjvmHegSSvcVmFnMiYtFdS3JPRkZcA== X-Gm-Gg: AZuq6aJfzNPVHpj2EFxMPVWp1pn8FGZTTVvRsN0D0zPDyMJc+8G9XEqPKsvtqhqXTNB 9k+nsNp5Teptl/R83v976X4iegygxn/K8qM0n3x8IgeWlNTzrzG1JhGQI62uypMBjMO4MtOjsFT YKz6zpljqRKIJb9S/pG/wAFQVxvQL26jSFN1h3zXILWq5fZrAVJhI3wZbZpF0t0qIhdzhh1X8Yd bdRypxwsIAy5wy8y7h9qtJlDIbghSXggc3qaoQMXFj06u9CYk0MPTBKYpRhCAYqJYMBJAP+8cE3 9bP1rauCs1Ps6I/SLUohx8XoerUdgxRgoRvrTlIGG09ovuvZOkDbGqyMbPQV3vZflK2tgWt51xj iIRLnKXASNt+txjna1Vkp9nLnRuJl83UymiffjOeo6/qLn5391Fw64RSr/vOVfcHTpw3pgVTv4s ba/Ef04RZprF1aCUCloMdgqEKXNQLTaNJguMe4I13wGzAmKqlWCs1ajd4VAgO8h42FsaIbfAz1Q f4= X-Received: by 2002:a05:600c:4ab0:b0:471:793:e795 with SMTP id 5b1f17b1804b1-48069d46808mr17120035e9.0.1769528951851; Tue, 27 Jan 2026 07:49:11 -0800 (PST) Message-ID: Date: Tue, 27 Jan 2026 16:49:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/3] xen/mm: allow deferred scrub of physmap populate allocated pages To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260122173857.83860-1-roger.pau@citrix.com> <20260122173857.83860-3-roger.pau@citrix.com> <69a64a89-af3f-47fe-8998-a3ff76e9484e@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 27.01.2026 16:01, Roger Pau Monné wrote: > On Tue, Jan 27, 2026 at 12:06:32PM +0100, Jan Beulich wrote: >> On 27.01.2026 11:40, Roger Pau Monné wrote: >>> On Mon, Jan 26, 2026 at 12:14:35PM +0100, Jan Beulich wrote: >>>> On 22.01.2026 18:38, Roger Pau Monne wrote: >>>>> --- a/xen/common/memory.c >>>>> +++ b/xen/common/memory.c >>>>> @@ -159,6 +159,66 @@ static void increase_reservation(struct memop_args *a) >>>>> a->nr_done = i; >>>>> } >>>>> >>>>> +/* >>>>> + * Temporary storage for a domain assigned page that's not been fully scrubbed. >>>>> + * Stored pages must be domheap ones. >>>>> + * >>>>> + * The stashed page can be freed at any time by Xen, the caller must pass the >>>>> + * order and NUMA node requirement to the fetch function to ensure the >>>>> + * currently stashed page matches it's requirements. >>>>> + */ >>>>> +static void stash_allocation(struct domain *d, struct page_info *page, >>>>> + unsigned int order, unsigned int scrub_index) >>>>> +{ >>>>> + rspin_lock(&d->page_alloc_lock); >>>>> + >>>>> + /* >>>>> + * Drop any stashed allocation to accommodated the current one. This >>>>> + * interface is designed to be used for single-threaded domain creation. >>>>> + */ >>>>> + if ( d->pending_scrub ) >>>>> + free_domheap_pages(d->pending_scrub, d->pending_scrub_order); >>>> >>>> Didn't you indicate you'd move the freeing ... >>>> >>>>> + d->pending_scrub_index = scrub_index; >>>>> + d->pending_scrub_order = order; >>>>> + d->pending_scrub = page; >>>>> + >>>>> + rspin_unlock(&d->page_alloc_lock); >>>>> +} >>>>> + >>>>> +static struct page_info *get_stashed_allocation(struct domain *d, >>>>> + unsigned int order, >>>>> + nodeid_t node, >>>>> + unsigned int *scrub_index) >>>>> +{ >>>> >>>> ... into this function? >>> >>> I could add freeing to get_stashed_allocation(), but it seems >>> pointless, because the freeing in stash_allocation() will have to stay >>> to deal with concurrent callers. Even if a context frees the stashed >>> page in get_stashed_allocation() there's no guarantee the field will >>> still be free when stash_allocation() is called, as another concurrent >>> thread might have stashed a page in the meantime. >> >> Hmm, yes, yet still ... >> >>> I think it's best to consistently do it only in stash_allocation(), as >>> that's clearer. >> >> ... no, as (to me) "clearer" is only a secondary criteria here. What I'm >> worried of is potentially holding back a 1Gb page when the new request is, >> say, a 2Mb one, and then not having enough memory available just because >> of that detained huge page. > > If that's really the case then either the caller is using a broken > toolstack that's making bogus populate physmap calls, or the caller is > attempting to populate the physmap in parallel and hasn't properly > checked whether there's enough free memory in the system. In the > later case the physmap population would end up failing anyway. > >> In fact, if stash_allocation() finds the field re-populated despite >> get_stashed_allocation() having cleared it, it's not quite clear which >> of the two allocations should actually be undone. The other vCPU may be >> quicker in retrying, and to avoid ping-pong freeing the new (local) >> allocation rather than stashing it might possibly be better. Thoughts? > > TBH I didn't give it much thought, as in any case progression when > attempting to populate the physmap in parallel will be far from > optimal. If you prefer I can switch to the approach where the freeing > of the stashed page is done in get_stashed_allocation() and > stash_allocation() instead frees the current one if it find the field > is already in use. I'd prefer that, yes. Of course if others were to agree with your take ... Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 15:53:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 15:53:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215039.1525284 (Exim 4.92) (envelope-from ) id 1vklO3-00052q-Tw; Tue, 27 Jan 2026 15:53:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215039.1525284; Tue, 27 Jan 2026 15:53:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vklO3-00052j-RP; Tue, 27 Jan 2026 15:53:51 +0000 Received: by outflank-mailman (input) for mailman id 1215039; Tue, 27 Jan 2026 15:53: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 1vklO1-00052d-Uz for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 15:53:49 +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 5dd4609b-fb98-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 16:53:47 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4801bc32725so45708945e9.0 for ; Tue, 27 Jan 2026 07:53:47 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066aaf235sm66902195e9.0.2026.01.27.07.53.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 07:53:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5dd4609b-fb98-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769529227; x=1770134027; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=yy4TcRbI/GABuiyGc/RtiUpMaGZwNRoKB1+ggqxbCHg=; b=ILetlNCwm+numpjyNgfco8/ZA8ysjPZtm8hZnECS34JSuZXKhrzL3Emmv69JjW4yMA kBO/JjKdxaY/N+EaL+K2rJMjurWiJlcwK6gl6/NokeT7Tkt9KDLq0fu/N7PeQnYs98Bi bJRDHl1nX5/SkjzzGZZz/um59AE+NwhnKdcmyUPFVUYIEFwkrs4MzuFcThrgZz7V/m6v EDyPkx5T5UqazNJ9Z353N0jqzoRfWgpQIAge5Ax3tXbIkltAgjeisM1m892s0GuFUErK MHZGBMQsIPBuicV8+LPJ5yVvCsjn+KjuVKxTMIxg7r1eU25uqmlxSg4GZOB1tjclvf/Y 6EUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769529227; x=1770134027; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yy4TcRbI/GABuiyGc/RtiUpMaGZwNRoKB1+ggqxbCHg=; b=BgIy+05HQFB7qUooOyT9gvATVq57R7uH92sRpnTRUo3/tRU4OTpSOAnAQSMDRs6TGO WfWeuLz3nQw//E36L8PtLI9aYKHRuuNK443SfSEbp4k1GdoUNXPw0DVAK59eP5X5PYNU vlktyCDxnu71GriOipNoDVLfIiXiavooEb4AbTiVd4oZn9obqwoLIxluF2oEZx1C2gdo HL1aViBrD+18Bzzm49H78CJxLP51u4CuDmezxjMVKeQNjjNAYH76HeebJCOFuwdRhaIU LQGbZ8CdSc/l5yimekvYKLA5VlxbkK3dn6/VSPZcEiZuVdZ2JsuviSIBOFPkDodJHcRh R6gg== X-Forwarded-Encrypted: i=1; AJvYcCWSzGVw5jLN8xxfUcd6dBUIqBq1mdWnXdu/WNmtMMncpdrZXObKCEup0GczWw8qi4GMIGYt2OxrehE=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywnfi7t8fHhcmCAOev03BxaL7KvyntZpZQfTnNyTr3MICXfPSfS Yh8WcJn7k8kF2e2K6DYif6HAojZbt9PLTYaH99498RC7SQY5VCBdbXGxOvTDYdB81g== X-Gm-Gg: AZuq6aK8eFc20Ul+V0Um3ydYRCUP3xJxW1Ret6Ev1TGkeboF2nNydFgsD5Uv8RTDWo2 QH1Ar0bnY1w9xQvUCabbS5gUSxcpNYW2V8f9AmBx/gs6NHeDdVbbEB5b1MRRSduv/sChj53wWs7 95wQLSfzLTfM/4bgFyKNRm4CR7sPizN5iwQW+nkDrgskMOArxVd3SAmZLDSBSjuEPrYup1511lV /+E52QW7a5r4jOKhg6eEYs9SLgL9NTP0WKBNTNcwU5x+hcEfH1MJxMlfvLQWIDtAtorW3kJwjD2 QToE8rR3y/dNIGu6uZuf3SfJdQUfq3c456nM4gfqvnu/vIy4t5etZKIoS+EDYAxlk8kqPljZcpr rWXZlQVeebblDIKh0hv1SRY7whii67jrraHigi4KT1JjibjrMeOkIKu0wKNC3lRrPoHJCOWEkiB MftZdwE6cn9tQeUflfNQr+k2p/nvqTf5NXs3tQtPAPylaItffIXLq4PbihxqEqepTliNmNEiPJi QQtRFfjixjc/g== X-Received: by 2002:a05:600c:154c:b0:47e:e9bf:dd8a with SMTP id 5b1f17b1804b1-48069cb2fddmr28911695e9.37.1769529227201; Tue, 27 Jan 2026 07:53:47 -0800 (PST) Message-ID: <99440e40-e49b-4101-9074-0be74651d3f2@suse.com> Date: Tue, 27 Jan 2026 16:53:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/cmpxchg: Add safety for bad sizes To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260127102351.2215346-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: <20260127102351.2215346-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 27.01.2026 11:23, Andrew Cooper wrote: > @@ -66,6 +68,8 @@ static always_inline unsigned long __xchg( > : [x] "+r" (x), [ptr] "+m" (*(volatile uint64_t *)ptr) > :: "memory" ); > break; > + default: > + __bad_xchg_size(); What has come of the plans to emit an assembly error directive in such situations? Also for Misra's sake "break" will be wanted. > @@ -106,6 +110,8 @@ static always_inline unsigned long __cmpxchg( > : [new] "r" (new), "a" (old) > : "memory" ); > return prev; > + default: > + BUG(); > } > return old; > } > @@ -137,6 +143,8 @@ static always_inline unsigned long cmpxchg_local_( > : "=a" (prev), [ptr] "+m" (*(uint64_t *)ptr) > : [new] "r" (new), "a" (old) ); > break; > + default: > + BUG(); > } > > return prev; Hmm. If for some reason hvmemul_cmpxchg() ended up hitting either of these, we'd immediately have an XSA. Imo these want to be ASSERT_UNREACHABLE() with plausible recovery for release builds. Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 16:00:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 16:00:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215050.1525295 (Exim 4.92) (envelope-from ) id 1vklUe-0007Ss-J2; Tue, 27 Jan 2026 16:00:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215050.1525295; Tue, 27 Jan 2026 16: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 1vklUe-0007Sl-GG; Tue, 27 Jan 2026 16:00:40 +0000 Received: by outflank-mailman (input) for mailman id 1215050; Tue, 27 Jan 2026 16: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 1vklUd-0007Sf-Vq for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 16:00:39 +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 52755ef6-fb99-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 17:00:38 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-47ee76e8656so85685785e9.0 for ; Tue, 27 Jan 2026 08:00:38 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806ce4c3c6sm1099035e9.10.2026.01.27.08.00.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 08:00:37 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 52755ef6-fb99-11f0-b15f-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769529638; x=1770134438; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=GI6kJDuUgp3VEgDjX+Jq2NfFYB6eKRLZZ6CTc5DhEpE=; b=MXVhd3g6fZC4PpIM1p3qRRPAVG5IybOaODyvt5FmxlcJexc77x545OaJ8ncjR+Odwp G9ad9vFnNHuGbUW5FzobAoCSq43s28KYqFpACg7i7i41E82MEVPAZaLlwsdexIXs4uyB WPTvRmFryOFqaXfyRBJLlvnaQg76ASYPzNKKQeYmPwvgO86SlULgHgmbnI69VB4uVf20 9Vzad71bRKhmtaaBd0nIYdtASpLm8HDXXY7cmdiBwXHWiiIfqxDyVi5PhOn3hZVm8YuO HMmzTofW6IcXIzwAfnnG26qm770MIXS+IEJa0lq2eX9Y/dQO3vGGW76c5nctdWvJMlwW uYKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769529638; x=1770134438; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=GI6kJDuUgp3VEgDjX+Jq2NfFYB6eKRLZZ6CTc5DhEpE=; b=BcXVKYnWfFzf0AQLTODemuVy8P7cZhQC0t6xX5HQTeo1YQyJeSERd/DNmpFujk+NmN uhWkXGlgQIduCAEr6rMfD4GvunNss3POLyXKeLxTXkiFy/spPGFrpsGCc/eqBXo2+lEt 6/dXECDzJcIgMPL5FCZkBiBOgy+FR+e+YbHU4+KyNxRSLmR7SHMrYwEUutNrjL/h3xLo +tWcWYNjWetmFUhMw3Topvq56Uqq/YWMSktS1EvlBveMhIztupWW0UuoI9GbrYDaeGUw R1fDlFM5nqURoL4653hblT2gHt3JAigcOhl8gVQjARdWaeJnPv7WDs1PuFJ2R2yP6+SN TBYg== X-Forwarded-Encrypted: i=1; AJvYcCWBJP0svsah9VvKolXHMrNndm92o85AWA0tId9Eonr4QZe09rmnjefIzDw/EhCgQ22cEJnKNIJxw0I=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx5gzcoytKtrk3j1gYW65YcnMsERPEFSbX+BT809XsJIiC3whY8 q03El3Fzsy5ffpl0NNsOFUonhZIZqGUpQFExSGBQpFQEResdiLHy07WT9y4a4odUJw== X-Gm-Gg: AZuq6aKI4SKQqooZ3ndJ6+Ar5o6md9WhcTLg+c5i2BDV2zTU+TNUakOO5N3IPVc6OXX UpUfORu7VlaRuZqVoPcpuJ6ygCRoAdCt+bhey0CwAigN+aaYu1dlgCRWnteiiwUU+eD1M6t0wVP WREoKivmuZJMv4de0SFVJy5aYp39B9dZUYBML7uImLw/Rtd+LznzSQWrtqRxjqSu2c7H0P6ZLaY jSNdVdgm0A6WP8OE2V9tLo+cyzLhjg5tf/EkRcjaDRpvGTi8rt+vGYCZCNVpem/PIJynoF2FdEc VbnfbTEMdHyQuI2NImkInOE9leF8VyXZZ5h+J0drMf/nqLJ0z2mTckH+H8EOJ/PdeNI93fywQS4 9K8WIs8BjgOVhfIrlFvHwlZKSbCl0x6AcToN4x3ZA7P0Ul2lWwY6dEVZL68AoeOarAGLBKdVb5v cB+G/4ktZzKxGrnNM6jZ74xBJGZiVAJZS/63U7orFGWvRL3lm8O4sjAcjg5cgQIxL2LVjOjFd3k Js= X-Received: by 2002:a05:600c:1992:b0:477:79c7:8994 with SMTP id 5b1f17b1804b1-48069c789e8mr27507985e9.30.1769529637676; Tue, 27 Jan 2026 08:00:37 -0800 (PST) Message-ID: <261128f5-1528-4a45-bded-8d18d6682a56@suse.com> Date: Tue, 27 Jan 2026 17:00:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/ucode: Support discrete modules being CPIO archives To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel References: <20260127143456.2260369-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: <20260127143456.2260369-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 27.01.2026 15:34, Andrew Cooper wrote: > --- a/xen/arch/x86/cpu/microcode/core.c > +++ b/xen/arch/x86/cpu/microcode/core.c > @@ -760,6 +760,7 @@ static int __init early_microcode_load(struct boot_info *bi) > void *data = NULL; > size_t size; > struct microcode_patch *patch; > + struct cpio_data cd; > int idx = opt_mod_idx; > int rc; > > @@ -776,7 +777,6 @@ static int __init early_microcode_load(struct boot_info *bi) > for ( idx = 0; idx < bi->nr_modules; ++idx ) > { > const struct boot_module *bm = &bi->mods[idx]; > - struct cpio_data cd; > > /* Search anything unclaimed or likely to be a CPIO archive. */ > if ( bm->kind != BOOTMOD_UNKNOWN && bm->kind != BOOTMOD_RAMDISK ) > @@ -844,6 +844,18 @@ static int __init early_microcode_load(struct boot_info *bi) > idx, size); > return -ENODEV; > } > + > + /* > + * If this blob appears to be a CPIO archive, try interpreting it as > + * one. Otherwise treat it as a raw vendor blob. > + */ > + cd = find_cpio_data(ucode_ops.cpio_path, data, size); > + if ( cd.data ) > + { > + data = cd.data; > + size = cd.size; > + } > + > goto found; > } Doesn't microcode_init_cache() then need similar adjustment? Jan From xen-devel-bounces@lists.xenproject.org Tue Jan 27 16:08:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 16:08:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215059.1525304 (Exim 4.92) (envelope-from ) id 1vklc6-0008La-An; Tue, 27 Jan 2026 16:08:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215059.1525304; Tue, 27 Jan 2026 16:08:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vklc6-0008LT-84; Tue, 27 Jan 2026 16:08:22 +0000 Received: by outflank-mailman (input) for mailman id 1215059; Tue, 27 Jan 2026 16:08:20 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vklc4-0008LN-PX for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 16:08:20 +0000 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170100009.outbound.protection.outlook.com [2a01:111:f403:c107::9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 640da576-fb9a-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 17:08:18 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CH0PR03MB6065.namprd03.prod.outlook.com (2603:10b6:610:bc::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Tue, 27 Jan 2026 16:08:13 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9542.015; Tue, 27 Jan 2026 16:08:12 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 640da576-fb9a-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Ph3wXWf/Km5JyW4B9l2zB5nCk9yMMAA7kHh9VlTZZO3xLT0wa0AM/JrF+qI3aGW3t36w8ldPAR738w5Hk9N1eF6xvViNQy2JazJs+xEMPLzDgpR7coqWvmbrRvwX3dauBkV5L+vxO7zINLb/Ssb2dpqxkvim76LHS/e55FDX29xHLBJDSKPrxsc64BcHDtSgRgGbEnLeNIqhJTabZfa9tDJWwbn+11kkkjAPqvqhE/SxeVSOZTu6fQz5ZrXSm5tLVIhsIkPfTFllEc5P66lCJrrGgpBcFJ++GkdSUqlFQ+hgnI+z7auLdyifs9U/+s3UkyUOfugMba8bpdldnIhSag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=AIFjJ0+wSlEkcmh3lwvhi0bhBMLVdMgxBU+zPBmoIFo=; b=STjvprOuJMQTkCeKzcO5bUVxJrP+CdsQscjYXRtH+088B6G5VTufLlLgedH/ohORThBnhhkAjIqTyvX8EUQr2x6MHmjggx1eLIuc2GbOIyA6Qio9Gknvy3bwOuA7hYV26CsJ/miIlp3pgGjWlH0aGB0eblg7f8GnzVI5qTQkxA+ApJg+3RIcp/o35S4swksy4agfn3vWk+nWdHO4K5L67IH1Il9WRHG3WVFI4IjZ0Gs+2V3+idMD3SjifD8loiUGa4GWrqS9LNeWbUOiozPqbBj0rmAUC0TtzvIRX85DWr5jMSNi19PXM024Z/02mVXUtr7gmZER6cgdIOWfxTJP8Q== 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=AIFjJ0+wSlEkcmh3lwvhi0bhBMLVdMgxBU+zPBmoIFo=; b=nX4fdvhTrOSkHL5MQjsO7P7KPtu+3VyFbTEoGzMkCzvfppy4EN4BFjJ+oJOo/XLbZ/VGkpzmDhOBHbdgiAxfw/234csAFTnP/zpFV1Ljd+O4Cqad0sM+vhWLze/sxxdgP/UQINoAO/FrDgz5GoEkTiuDCTyCVmLhVcB3Wssjsvo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <639a282d-4b1c-47df-965f-1df8f38df170@citrix.com> Date: Tue, 27 Jan 2026 16:08:09 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Xen-devel Subject: Re: [PATCH] x86/ucode: Support discrete modules being CPIO archives To: Jan Beulich References: <20260127143456.2260369-1-andrew.cooper3@citrix.com> <261128f5-1528-4a45-bded-8d18d6682a56@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <261128f5-1528-4a45-bded-8d18d6682a56@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0497.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1ab::16) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|CH0PR03MB6065:EE_ X-MS-Office365-Filtering-Correlation-Id: 4fe42426-07c8-475f-7850-08de5dbe45b3 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?MGNpSElwQUZIYjE2OFZaRnZZcXNyOUxZWGhyNEl6aVpkUldYdUg5UlhnMERh?= =?utf-8?B?bXd5a1hPRGNqNWFsTk1CT3IrYzhhUlpqOW10RDBPRUJ2NXRsa2NPK0RqZkxJ?= =?utf-8?B?RHg0bHF5N1Fvb09QN1JReEwrdUV3UGZBcVlySmlYSEY0L2JHTTBXNVEzRytF?= =?utf-8?B?bjRSdElLYXhER0JnRlZlaWhBVjM0YTNrSEpMOVVETXpTb1U4T00rYWQxVW82?= =?utf-8?B?NjZnbFE4VzNwR2ZSbGE3MHdnM0FjWDBYYUh4RmlWVUIySFMzSmJvdEZVbk9h?= =?utf-8?B?R2prM2NoMUZTc3QvWU9CTkxGQUhOa1c4Z0JtRW9PUW5waGRab0VUbzlqbHY3?= =?utf-8?B?QW81bVNxYzdkQ0hkK01Nc2VZd2R4SGw0YS85Vk1lUHRaME4wUE1JR0Z6MG5G?= =?utf-8?B?em45eTZrSVpaNUwxN1IwcjR5TkYxVlRZMkpiMDZaNGFMSFh1VTBBaWxnUTJN?= =?utf-8?B?SEdKaFRvSFZjRXQwNG55NWYyTWtQTVpUYzJjcS9GT0VsRGpOYmtHSzJvUGR3?= =?utf-8?B?UnNBQXdlSlBlN3JZdmJ5VnJEbEwveHRnVlY0a2k2UkM5ZWtEaERRZUd6YTFY?= =?utf-8?B?QlE0Z0x3MXRlQzlXbmVjSVBUSWlJQW83bHRyWFhnMFRLb3ZtQjVkZk9RbDlO?= =?utf-8?B?aEZOZEduQXhtMkJqallDbUZzd20wYjQ2bjY1Mm5wOHczQmM3ektGVHF6NlVC?= =?utf-8?B?dXZodjN2dVp2SHptU2toNDRlS2N2Yi81TnQ1NTVRaFRoSkdLRTZ0VWhVVERM?= =?utf-8?B?Q1d6Mk5SNXdaQjJ6L2VvN0tGam10Uk9EeUpGYThSdG1sMGJObi9SSEY0Q00v?= =?utf-8?B?bTF5QnNNdXFWTm40Yk5TektKa2N5YWR0cmlheDl4eDV5UEVXaTdhSjRVbEE5?= =?utf-8?B?MTdmSjBxS2pxMUFDR0owT2FJSHphcDV2RjRLNlZIaWRid2h6L1lKYjFFZDc0?= =?utf-8?B?bkloa2RaZlVIck1mNkZCZHAvZXFjSm94dXlYRW9uYmNYS3VPeWFqQTgyUVdJ?= =?utf-8?B?STZ5cWE5bll4WHdZd3BpKzdob1BqeEdvbFZDQklhdDZaTE94OWJHK05OSzlS?= =?utf-8?B?S2dKNFlYU0wwWUU5QmF2ODJWUGtNazFaWkxSUFNnL2N1NG5aT2FrSXlGVW5O?= =?utf-8?B?NG1UemtkS1BzeU5kejdXc041SmZQVXpSTUZMVWxSSHRndFkxR2hZWkJFc0dr?= =?utf-8?B?bkw0eTBrNklkTzI2U3I3S1J1T0ZTdkRKRFoxMHVjVW54V3JZTWlVUDNpTUtD?= =?utf-8?B?di9JMlpqZWdQY3N4Z3ZtMHVkOXZVMVZpTUkyZm4zUmJ5VzhPQjI0c3FBazFO?= =?utf-8?B?NURMVk93UTZXeGd6bVdQOFNvSUtqajhFRjJlS0JHQVFVY0NwcGhVNC9CNXpQ?= =?utf-8?B?Qkd0RlQxZEdrdkJ3QXplZE8ySlFnbllTSVV3Nkc4ZTB2WkRENU1pQ2JXTjUz?= =?utf-8?B?NStIOXlXQzR6YVQ3dUdFcy9scjlEVzhmOXFPVlBjKzZ5KzluSTVSRHY3Z3ph?= =?utf-8?B?a1NXd2NVcURoNjNRS1V5NlBSMlZqY0x4MGY4cnlXTmlpN2daeVVyZFYzYW5N?= =?utf-8?B?T2Z0Vk1sT3lvcXM3QTdCaGtSblk5YkdLa3hZbEJGYThjWjFwbks1V2pEV2Nm?= =?utf-8?B?NUdhVWltSkFtc1pRVTJjZEpSOFdNMERSSWs1a2NEZ2JHNlFVaEhialJ5RUdm?= =?utf-8?B?WkcxR0FYMUV0dE03ZTAvcThtRlRXM243My9pQkc4QnUzYktoNXo2TmdSRm1S?= =?utf-8?B?RGhyRzlwUktUd1cwMHh1Q1lBTTQra3FONjRxY210YU91ZmtFYXFzQjhudGxH?= =?utf-8?B?SmlqZGN5NU1Jam9DWFpNYnJCQlYvdGZnUVRzRlJTNVgxMGV0QWZXcU9Cc2dW?= =?utf-8?B?NXJpZ2V1S2p0dEcwbjlrQ1FSK2ZJbzRPbWYyYUNFSFlMMWJDdmxsVGQ1eWcy?= =?utf-8?B?eVBqSmVCcWJuK2N4Y2JUTGFsZC94ZGFaRmZZaEVSQkNhdWpiY1V1REVuTVVh?= =?utf-8?B?THM5MnpOUmw1a25IUFZpTTJNTVBMdnJ5RDRqOGlLeWdTWWRnSlk5YTVLL2h4?= =?utf-8?B?VDE4VVNnTUZUZm9PaFdvWUhIdmFYUElJRXZ4bDBlVWsyZWhHRlpKWjA0eGRo?= =?utf-8?Q?LSng=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZVRIZ0Ezb1FnSld1WkEwczY5cmFlSmxJaW9XYU92MHlWS2loY0I2Q2hMS2Mz?= =?utf-8?B?dXFmRjJZOFM0K3h2VkJVRldIeHBSbnpRSEt1bXFHcnVtYXN4NDRwemxhWFls?= =?utf-8?B?bWNPYzhidE9MSC8xaDNEQWhyL0h1cjFidU9JdWJGRS93bjdja3J6LzRBam85?= =?utf-8?B?Qk1NeUpGZ29FOE5qTENoLzREbFBmdyt6ZUhnM25mZGZvRUI4UVFHVWJWZTN0?= =?utf-8?B?VjAvaDJWV092MlZyTlY2L2lsN0cyS25na0daU0x6bFpTa0pxT0NNaEdwYW9w?= =?utf-8?B?T3lrM2JrRkNBR2Uvc1hKVUJwbngrYXk2V3V3SW81VmJzTmJoTmtOMjlHNW54?= =?utf-8?B?eWlZTUtzMGRCTFhHcWsyb3l0S0hSYTZSOUVtUFFCVE82Nm8vcVIzSmNZS0Iz?= =?utf-8?B?VEczb2w3c3p2cXBQbWkwL2hNUTB5dEZMeXk1bVZZSjkya3ZKWlRPd29JMVJX?= =?utf-8?B?cEk0WWNZWnM3SERabGFFbFhrVjJpSlVzS0dSUWJwVnl0ZEpPQ01uVXlCQkpF?= =?utf-8?B?ZHFCdE5NZVYvdGpCWUFPeWxYOXlpT0JPa3draWtCeEdYbVViaDhWOFlUT0E2?= =?utf-8?B?YmM1d2tNWVVPcWdObG1FV3QvSHczcjBNaHRDaDkvN1dTWDhRb2J4K0EyL2ZG?= =?utf-8?B?Ky9zU0VpU0ZhTHhIRlhyVGZkYXZRQUdEWTI4QWI2ZXpiTzBmeXg3M2xodnBr?= =?utf-8?B?U1NCeXBLVmR0cWs2R29BaW9KU2F3L05PK01NbTZoTTBMYTBvU0gzay9TaHBt?= =?utf-8?B?cTljb2dMV0c2MmlISE5UbWRtT1FFY1pDeCsrdXFNditaUE5UM0pCVTd6cy9v?= =?utf-8?B?OGE2a0ZjVzdOVWJtamRrOUdXY25wK2Z2ZUJibjhtUXdpSGw5andlL0ZDcFFz?= =?utf-8?B?N1JkTWhIN0tKd010R0VPMXZNN1E2Z25lVEpIS0dybklOdVpWTVJhbkxIZWhy?= =?utf-8?B?Z3Qrc0dpdncwZjJxcko2bTB4ck1YT1NDTFlLQ1JuVklEM3JnSTlXcVNocm5n?= =?utf-8?B?YU1sYVp0VC9CcXhremFMWnJtUGUxMWJrZG5iZVptem5QM2JLOWI1RzZTaGUx?= =?utf-8?B?RDJnNTk0bmZPMTg3eUs1c1V2amlwbjc3U2UzMnJGdStxWmFjVC9uNS8wQk4r?= =?utf-8?B?TnVDM1dBd01NNWlCYVdCYkdDSTJqYkZzSWlCQkczZFFjQkJ1M3hDZGJoa0Zs?= =?utf-8?B?dzlNdmQvOUNOV3hOSzlSb3FHTWV0Z25DazhmN3dUNUFhbGlWOGRKVTIyRVNx?= =?utf-8?B?MUQ3dG9PZGNuYUxzZEdORHVZbG5xS2U2MlBOQnZWT1FMZko5OUIrTGhOM2lG?= =?utf-8?B?ZUtuaDhwRk5uaCsrQUNFTGMzcU9CYjJWZWMybFNoTUtWZUhDWlBpQTloNlZz?= =?utf-8?B?Z0dVVDY3bkZWejIwVktBZGk0bFZuUzZJbWdEbGNaeWlnN0pYV29wbHR3a21E?= =?utf-8?B?M2c2aERrZ1Nvek0zYU91UkRFcU9HZGJZVCtLeVdYRlJpaGVqR1lhM20wamdU?= =?utf-8?B?VHpZTDVJbXppei92bENIeEFybmRXRHQxQ1lEOGFNWDloaDZHMXUwTHBmTjZB?= =?utf-8?B?Q0RZTXVYa2VFTzlnRDd0NGdZVzJobUZiU2s5dmNTZTVzdngvQXZPN1VxSmJh?= =?utf-8?B?cjdEdW9FN3piQll6UHRLZFlaMzMwMlFOM21uNHpqbmh0Uks4cTBReXk1R2dS?= =?utf-8?B?R3ZBek5ON3I5RDdPdWhXOUpKeERVcG04YUZKMmczQjVneStKRkFjZ3lFWTZG?= =?utf-8?B?SFR1SHIrSUE1UVVGTzRvN0NSYStoTUM2enhvZW9MZUpXWU5LTHJYeXlaQk5D?= =?utf-8?B?V0MwSU82WGJzY21kTlplMGpHaVdLUGRNdjd3V2pMcWthdWE3dVk0QUgvYmJ2?= =?utf-8?B?NmQ5VHVzVElGUjJtODRNWFhQV1g4cGc4MWRMRlVQQTRHSmhUZGliNjVFWWM0?= =?utf-8?B?eEE1V0l0VzRDb2ltQW5ZTXFwNDZqK1F2THlCbHpnVnpDbXpkS1hMWDlxVGRu?= =?utf-8?B?Z3VhR3N0SmhDZWNEcm9rbkk0anR5RkdIWWR1NEgrTjBiSklPUnBHZTdZb0Mz?= =?utf-8?B?aEZWaFM1Mm1SRVk1OVFmWE9uWGZ5NTBrajVWUEkwZXlrOG5INkZVNUQxaE0x?= =?utf-8?B?NlZTSTRwSUM5UFgrdENva2d1T0dCVWZPUVFsUzNsQ05oKzdsZXltTGhVS28v?= =?utf-8?B?d2dYMXpyc0xBUDQzVE0xRHRzTkZCMmcrdTJvOXRvNll3N1NoN2tIb0JlY3pi?= =?utf-8?B?SWtzNkJQUFdtT0NvRVJFSXdMaDQzTFFUWnRoT0NaQ1BhNE9lT0ZkTUxLeTJM?= =?utf-8?B?dWdUZStjT0xsT0VRc1FmVkJvN1Fib1ViOXZUNlFDU25zNFE4U2xqUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4fe42426-07c8-475f-7850-08de5dbe45b3 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 16:08:12.8847 (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: s5mk8+I6DdcwMSAHqg/f6lqXHQSyfZblc0GLI002p+DTShOTAduNw1uHcVJSglHaI1AkaS77gUxRMZQ4Eslx32ctaOJn2Y10YzLfedeZ8uw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR03MB6065 On 27/01/2026 4:00 pm, Jan Beulich wrote: > On 27.01.2026 15:34, Andrew Cooper wrote: >> --- a/xen/arch/x86/cpu/microcode/core.c >> +++ b/xen/arch/x86/cpu/microcode/core.c >> @@ -760,6 +760,7 @@ static int __init early_microcode_load(struct boot_info *bi) >> void *data = NULL; >> size_t size; >> struct microcode_patch *patch; >> + struct cpio_data cd; >> int idx = opt_mod_idx; >> int rc; >> >> @@ -776,7 +777,6 @@ static int __init early_microcode_load(struct boot_info *bi) >> for ( idx = 0; idx < bi->nr_modules; ++idx ) >> { >> const struct boot_module *bm = &bi->mods[idx]; >> - struct cpio_data cd; >> >> /* Search anything unclaimed or likely to be a CPIO archive. */ >> if ( bm->kind != BOOTMOD_UNKNOWN && bm->kind != BOOTMOD_RAMDISK ) >> @@ -844,6 +844,18 @@ static int __init early_microcode_load(struct boot_info *bi) >> idx, size); >> return -ENODEV; >> } >> + >> + /* >> + * If this blob appears to be a CPIO archive, try interpreting it as >> + * one. Otherwise treat it as a raw vendor blob. >> + */ >> + cd = find_cpio_data(ucode_ops.cpio_path, data, size); >> + if ( cd.data ) >> + { >> + data = cd.data; >> + size = cd.size; >> + } >> + >> goto found; >> } > Doesn't microcode_init_cache() then need similar adjustment? Hmm, yes, but we can actually do that by setting opt_scan=1 here and no other change. microcode_init_cache() already has the explicit index to look at, so opt_scan really becomes an "is cpio" flag. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 27 16:46:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 16:46:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215075.1525327 (Exim 4.92) (envelope-from ) id 1vkmDD-0005U2-Aw; Tue, 27 Jan 2026 16:46:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215075.1525327; Tue, 27 Jan 2026 16:46:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkmDD-0005Tv-87; Tue, 27 Jan 2026 16:46:43 +0000 Received: by outflank-mailman (input) for mailman id 1215075; Tue, 27 Jan 2026 16:46:42 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkmDB-0005Tp-V7 for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 16:46:41 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bfb6a10b-fb9f-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 17:46:38 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id A93C04EE77F4; Tue, 27 Jan 2026 17:46:37 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bfb6a10b-fb9f-11f0-9ccf-f158ae23cfc8 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=1769532397; b=GZxDFUhNuh6/Tiff1Y8x+imUO6/fypfGEDJPkCLTHjKW/phEzP8slCjd/F1o1wyQ76KQ 2xJgPNd7Bsk7d6JNvgBNetKnfZSDirtLvSDhUJ2TSNWqL3p2TRsHFXsRlhwgdIRC9cq/L iUPVN/JJrEY4LVtEb49vmBHxCU5loDr5AfzCNXTEeevBxLudJJM8/Qxhmygfjc8Hc3mSz D6S1sVLDA6HdvnlIkRU41rBp0we81eAvVfM5XgtfGCYvfHJtzbmPaJywUdSuvkXOapJqc dWKRCVpIxLXaSrbuzm4NIOg6MgJfqWZsCxkC3LTFQU4ZI7z2Pa+yImfr69JiamXSG9hxK OFIa+fJuLUdqEwbERLv1qF8Dq7bMzSH3b34cCfue3pG8aeme4qP+XwESIPBEDIOqKdX5Y wxzqGYsdAPcRhCYx3zmbqRjWxDTCUxQjVi5fWJR8nL3UdYUC3jrj7mekYM2khueBbYpx0 xWT2/BP1qhCRGKFxYy8tPS8NIpcOwTzkTMAbjSDyEdfGKzNDRtL+VbVmNGza8+ueSkYJg /67MbSq4h8pvvCYjJLe/bWsgRuuXGjPCRxP3y97NchsZocOQ9YUKxu3/BdXo7KXZur/B6 xAfVx2wudMVUFmxnptMwsFd5HE6dM9RAAIAECNkj5w52u5HlJOZBuJG7Vd7BF6I= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1769532397; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=/FvdYw5XUALzymw0RBAmIm90Athdi8EyO3LpUk4DhmQ=; b=eVXX/9I95rDhfWI8Qx9NkbjzgSdb/VKfEym8IYSZG1VCDPqsRYsWN5xoTNFDN4zWfwa2 X5/HCjog9cA9ryuyGRASqLSmHUYmiJgpEv38SK98Q8sfnoJL3OHTHgzzjblGiNwuBJukm WWjrBBvMOSYsgZQod/cKcf4Cfp+bpafupjR/aectPP2lG4DtNjIxFEVZquzlIU5k/ekW3 XXINS9KHjM1DyXQZWlFNva+6FBmmBzhk6No8dV/EsHeswTl2/cSBzMjkGaS3BfFn/PevY 2eYT0PliHDq9GfMMzTZzzJ58ykUPFIYIFE1HFfb/UjCLtavJdEA1vgqVPU8VDzocYGkEc JGF7KBB38ONdPWa+VBe85ylRyFijdUnruEvS6VYvrxU1B4UqGncfkGcJeDDzTt4+Cslnc KhkuHDj72UjEkEWH/qmtGSwEzHSTKZzS9CY8+KlP8MyZfI92/kJ3FejSEACgrItzDdvCW ZMGIZZoA5sK/Z8yYLP+VgxcqIFCDwirhGYom2szp1sgsDq3gBs+UB7fF0bIGrfDdIrl6n QJKIR7afr+87/5wzcYMBXuu2ZieXh2Y9Fz6zKu5kJ1qJ1jHlNMEajYvFvMOUm3SJF0YWo Du9rBOXJWSRNBWAICF/e7h1qDtdx0JL9dmfOm7aKQAL9cS7vlFTXPsScaWAYq+o= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Tue, 27 Jan 2026 17:46:37 +0100 From: Nicola Vetrini To: Jan Beulich Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn?= =?UTF-8?Q?=C3=A9?= , Xen-devel Subject: Re: [PATCH] x86/cmpxchg: Add safety for bad sizes In-Reply-To: <99440e40-e49b-4101-9074-0be74651d3f2@suse.com> References: <20260127102351.2215346-1-andrew.cooper3@citrix.com> <99440e40-e49b-4101-9074-0be74651d3f2@suse.com> Message-ID: <4cc57348eb1d45f351f7091dc80991d3@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 2026-01-27 16:53, Jan Beulich wrote: > On 27.01.2026 11:23, Andrew Cooper wrote: >> @@ -66,6 +68,8 @@ static always_inline unsigned long __xchg( >> : [x] "+r" (x), [ptr] "+m" (*(volatile >> uint64_t *)ptr) >> :: "memory" ); >> break; >> + default: >> + __bad_xchg_size(); > > What has come of the plans to emit an assembly error directive in such > situations? > > Also for Misra's sake "break" will be wanted. Or mark the function noreturn for instance > >> @@ -106,6 +110,8 @@ static always_inline unsigned long __cmpxchg( >> : [new] "r" (new), "a" (old) >> : "memory" ); >> return prev; >> + default: >> + BUG(); >> } >> return old; >> } >> @@ -137,6 +143,8 @@ static always_inline unsigned long cmpxchg_local_( >> : "=a" (prev), [ptr] "+m" (*(uint64_t *)ptr) >> : [new] "r" (new), "a" (old) ); >> break; >> + default: >> + BUG(); >> } >> >> return prev; > > Hmm. If for some reason hvmemul_cmpxchg() ended up hitting either of > these, > we'd immediately have an XSA. Imo these want to be ASSERT_UNREACHABLE() > with plausible recovery for release builds. > > Jan -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253 From xen-devel-bounces@lists.xenproject.org Tue Jan 27 17:01:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 17:01:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215088.1525337 (Exim 4.92) (envelope-from ) id 1vkmRc-0008Il-Fa; Tue, 27 Jan 2026 17:01:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215088.1525337; Tue, 27 Jan 2026 17: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 1vkmRc-0008Ie-D0; Tue, 27 Jan 2026 17:01:36 +0000 Received: by outflank-mailman (input) for mailman id 1215088; Tue, 27 Jan 2026 17:01:34 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkmRa-0008IY-SO for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 17:01:34 +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 d3d421d1-fba1-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 18:01:31 +0100 (CET) Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-42fb4eeb482so4048664f8f.0 for ; Tue, 27 Jan 2026 09:01:31 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e10edfccsm108541f8f.17.2026.01.27.09.01.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 09:01:30 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d3d421d1-fba1-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769533290; x=1770138090; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=1JCsxWW78A37DUn0wWBZdLPK8yHg0Uo5kslgabp20d4=; b=GYXyLv7c5Sc5ij+7WiH/gzGV0VDqwR5ZVLL7rLshNfmcqoP/ffAA6y4bylJ5RToaHe 6eM1yIy2HQrE39rNtK4Z7nHb+zou9zPwifXUnFyElcTgHO1UuTYVeqxdR6R/60eR9yvY OksDZtfY6Z1x3M/rC85wPtBxK5xiMPDHSHSQY1On9oOL0XRmdUj7xCIhPDtesbCE9TEG Dm1AhOOi+TsNk1d8j/MHekgVUUcqEQpSjMO8jagNZOL22SuyT0NnR3+z2NIJUgw+fZas oXnkpYmvBxaKKfrH0RFE+V7uX46e8o7HPK+8xn31mVSb2dU1tRyzmszXGhVUvvxHoRUN 2SyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769533290; x=1770138090; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=1JCsxWW78A37DUn0wWBZdLPK8yHg0Uo5kslgabp20d4=; b=k0K4fy2YMY++4mSck9DEHdb3s86GDqoLjNIcP+/46meY5JXB9VZmIm+/kxejmLGMGx W2CW9pg6bj7+5VjX5hu81RUO75GbHHjcAtffDwFCpNX/ipTXU1Watk0oHdIV7KJZ/k6q ARAKSuryhopuO7a/7Vo6y1aqTgiacSvTR+/MoQdxEry3vvN3di4VOTWZ9v68FfeUoXDx jBmnMb3oO567zzEhOTdoMgu8BultA7+WHLW7KhfHpAO4GxjBtMfbnL4d63FOTium1qt+ nh6LOoXlw9Ke0rkaPt5SGJocPDepFPJMXtpQbmAntxw3akmj4C/X8o3CPo945Km53AZR Ml4A== X-Forwarded-Encrypted: i=1; AJvYcCWw78QAi3N45BD+ay8CRFM6pOqrMfjeN72NXl8+cM3ihyuci7zUOoGdhtcfqa/VE55cgP5fdLLFg4Y=@lists.xenproject.org X-Gm-Message-State: AOJu0YzSFsznfnExRzjVXO7fFqKCnFINgcC7K1jspTPdNaZWOaRi8MlQ dAx+n1ZTrtAtEq26p3JnJz5nRL8m32Iat55dl1cnEgBElcU3I1IrA5pM2bXJOkWz1g== X-Gm-Gg: AZuq6aINPFxqHYfg4oIbovJQuDo4t0vSOY5/PlKcpsdUcXGWIEfewPRbp7/R7aPHfj+ rP3UXZGRLqoyPRm49d5v5HxIDWn3tnHPXKgrx8pqNUMMzRBTCK+KO08Yx9gpPo3+iD8x5eyIiSv 5sWuNdXtanYM0LQNHbvhHXot8ESO4nZHuLnnRL6jp5Ivmxq2ZbHSl07c4+UUiaPdG4fM+eNR/0G tXvePhYe+7Rbn7a1MiubyofgYNrabWxaSlAacawc1h6S0MuAThwxZvhENwwBhDCCGdEYOul/D82 4zK7THFTH7wJXnK2I0ARkI2UT0g+S0gVp5HR4jNuD1waG165qDJc9o7ee1bDJh3KFxHWIFZM4TD jwdzNuymuaUybCePiOmp8kkOBYSEZV8Oa2rppC+ikXD6DyOmpqzP7EkgVa9ZZcLvOM1ug7MXPYU 1mP1VYbjCZ5hAQ6pR5mC2KfFluu/EjzmcrjUoayrJm6uSNsNpRr0FIY/BEu9/rchq8BosqVqViG IU= X-Received: by 2002:a05:6000:2209:b0:432:a9db:f99c with SMTP id ffacd0b85a97d-435dd0b68bfmr3604219f8f.31.1769533290524; Tue, 27 Jan 2026 09:01:30 -0800 (PST) Message-ID: <18aee854-2e08-4a45-9df7-1c622136afde@suse.com> Date: Tue, 27 Jan 2026 18:01:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/treewide: More typeof() -> auto conversions To: Andrew Cooper Cc: Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Xen-devel References: <20260127101841.2213758-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: <20260127101841.2213758-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 27.01.2026 11:18, Andrew Cooper wrote: > All of these are simple cases of using typeof() to avoid multiple parameter > evaluation. Using auto avoids multiple textural expansion also. > > No functional change. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Tue Jan 27 17:11:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 17:11:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215096.1525347 (Exim 4.92) (envelope-from ) id 1vkmap-0001dU-AT; Tue, 27 Jan 2026 17:11:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215096.1525347; Tue, 27 Jan 2026 17:11: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 1vkmap-0001dN-7T; Tue, 27 Jan 2026 17:11:07 +0000 Received: by outflank-mailman (input) for mailman id 1215096; Tue, 27 Jan 2026 17:11: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 1vkman-0001dF-Nw for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 17:11:05 +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 292be341-fba3-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 18:11:04 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DS0PR03MB7776.namprd03.prod.outlook.com (2603:10b6:8:1f8::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Tue, 27 Jan 2026 17:11:01 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9542.015; Tue, 27 Jan 2026 17:11: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: 292be341-fba3-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bF23f3ML7UJ1O0ljyYF5rJV5MAKxs15rPaytagg3X9c1EjYPPYK/9UkYitvB9XZg+IGPX5SsYzwLgVRcbQliYItYJEEpHr6ph4g4yaoF265y+YB/oNOYAvs9ero/esdna9hs5+pY2CuZBvLrvu64o729SlFdmSKRhWjj36T3pIKCQvz1NZuvimch+bi2TRnOe2Jeead+E45UIlHxRz+dM6dA9HJgdUAk/2csDIqa9TQsxSdjTwzU5uqHDaTGpabs/UN/fDKjgWLG8RA9x6mvADp72y4n8xxVZuvhKNEJids5iIHb6zzJ/ikyz15IH7gAa/y/CHddn9oT5T0yC/y9Jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=29EKGrTpStd6wnpmTvhslbg04JoVHcF9rqVLaHKnQ6g=; b=mDWjGdFCXN2yHP2VA+7xg7JuJf/cy9mjNow77j5zPj0ltRRhDU+8mqIl80OVIRYjHbfYNDJa4dfpWtKRK/0Ww+ss2E/i4rWXdyzl6bYH4ocSdXKIbe7+tnDJ/ZfeHPTeGE0dq3NfXJJXOBWllelXnIbF/rLgF9yJYe5HaWbSNUS+ZTLcpYjYEDCiyV/cEj0/L8TJuaLX9eeNRqw/E5d23xytgxK34cSeqHo0HoGKSQ6mSaQWaC91w7B466ObXJfu/pjV9PyCOwZN8wmrXfdFIXqI7Fm1lIA0/rozt2QvggyBvypXGPT5A5iqw5fyBy2b4ovYUlW5qd0p4QyeYPO5Mg== 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=29EKGrTpStd6wnpmTvhslbg04JoVHcF9rqVLaHKnQ6g=; b=oAsqAMJ96NZPfl691inRKsUAEIiv2azzk00kxnA5sCQmpV+NlW36QP3QXITPpGWZpNMmP6EBptrO6vj1aIySsSGXR9IF3Ume7h0HMu+3bGsB5rHokIcQ7oOYHeFYqx7Fx9BH1WcrZG73jbnzFoUY0WTgD24zP5xfcbgOjQYTLP0= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Tue, 27 Jan 2026 17:10:57 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Xen-devel Subject: Re: [PATCH] xen/treewide: More typeof() -> auto conversions To: Jan Beulich References: <20260127101841.2213758-1-andrew.cooper3@citrix.com> <18aee854-2e08-4a45-9df7-1c622136afde@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <18aee854-2e08-4a45-9df7-1c622136afde@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0035.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:151::22) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DS0PR03MB7776:EE_ X-MS-Office365-Filtering-Correlation-Id: bc942b22-9e86-4f94-2967-08de5dc70bce X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?TjJWUVByZ2huN2NPZ3MvRmJkQ1c3YWhnb0RtU3RUbitnS1VOTWh3T3NMQnB1?= =?utf-8?B?K0U1YkRJK21Dc0ZzV1Rja0NUVDEreU94VytLVUpGYlJtUVZtMW11aWJiM0Mw?= =?utf-8?B?RDJvVzdMWkx4UUEvZnpQQVkrZm1wcGw2M2JTb21PNEE3dkpTVDQ5VkNBa1BE?= =?utf-8?B?MDhiVWFZQkpzVmJEUTJ5ZUJsWTFlUEFnVG5CN0xEYnJja2FieXk4TE9jWU5T?= =?utf-8?B?RmJ0OFp0K055K0gvVHlYYVE2WWZNYnZINHVrMmhNdEpEV2ZBc1paeFNjTXpx?= =?utf-8?B?V05xbG1vQlgzT2ZQS0NaSWtLeWplbEN3V2w4R0hHMnEwTTZkNUxvZktidEVS?= =?utf-8?B?dUxxSWpSejZTeEZwZU1nMUFGWms5cE8zTkJsZ2FkcEs5cTdibXRPaGlCK2VH?= =?utf-8?B?SE55UWFFMzFBY2VOYmJJdzRxZVZUTFhyV3I4TEh2aTlVRHhRUW1GbUN4bHlE?= =?utf-8?B?QTJ6TExCWExTOS9rVEFKRHV6M0IvK3UrMExwRTZzMDIydnZUR2xScFZqMncr?= =?utf-8?B?d1dsSmF3KzJxbW55N3BzZXV6c0ZGcW9HRlJETk9yb2RuRWFPNis3YVRPYzRh?= =?utf-8?B?U01kY1VZcGZXanM2aS9DL0lDWGtyT1VhQWtIYW9BWmU1VnB3UUw2MVE1NEFw?= =?utf-8?B?bzQzSjdxQWN4VjZXRFVxWm1DMWRwakRGcC9tcTdBZFU5bUZqb21Wd1JjcjBx?= =?utf-8?B?TUJsQWZNZkV4MlZLWExUc1R0SWFtVWhyeFNQclo5bE5OZVRVZ2ZJRDh6MXVn?= =?utf-8?B?Vk5PSklZRDNDNjc5R2lxS2hsY2w3R0hMTE9kQmZVZlMxK2NPVGJoanQzQzNF?= =?utf-8?B?M2ZKTE1BZ0d3eVNUazZZQTMzV25nQ2R1LzlocUhkeGtMY2JpQU4xZ0JFMzRD?= =?utf-8?B?SzBxVkxHYUtvQ1ltQzc0VFJ2aEttdDlmekxWWVR1TWd0M2dsY1Y3K1BKNmtY?= =?utf-8?B?S3R0eGphdFBPM1NmbGtmOVZtdi9hSVh6bHF4dmN4cEcyc28wT0NueHV6ckc4?= =?utf-8?B?UmhlREZIWHZ5RExmOUVJa0d6aFIxTHZSWEVuZThnVDl4ZWlqeFpGUHQ5V3lw?= =?utf-8?B?dENuek5aZWV4SW1HQmdtY2gvd2V3M2pCS0I2U1lGenJlVllHT1UxWTNkVkdh?= =?utf-8?B?Q1htcy9za2kxbEkvZTE4dzBPbUdDdzl3LzZ0Umd5YVdlOUovbTZWTmxISTdu?= =?utf-8?B?MUpxeSswRHhnSzFWSGYrZ3B4V0lLK1RBR0czYU1aTkQ5RkxLeDdTVDNFWWFH?= =?utf-8?B?a0t5eG1weDdFQUpxMCtPSFZXYkQzeHhrWTc0NU40ZStpRERsZjRnTFp2bHUr?= =?utf-8?B?VGN0OGszcXlYdS80V0RQWkY4YTcwSkJ2eEc1VzFuUkdDejNHRWx5bFgzWmh3?= =?utf-8?B?eUV2WWExenpvU2ZZczNrTDBZTml2U0xaemJCUmVHYjFvVjYvMDYwRWdLeE0v?= =?utf-8?B?QVV3QXVjZEYzVjRoLzBaY3d5bThIbU1vcC9qYmgrSjhFN1o2SXNXMVNqc3Ev?= =?utf-8?B?WGtFR1NubUhxTGpmTXRKZGExNlpPRUozREpmd3FHbXA5M0lvdzNXenAxdFR6?= =?utf-8?B?KzJWMGQxbHJGK1ZwWWg1RVJTTUdEaWVYNGZ1U3JQYWVyVDVvMnRneGVuNUlw?= =?utf-8?B?WkZvUHY5VUlMOEM5WDRsekRvM2NwdkRsd1JrbGxhK2VRRHdFZWdSQlBCMjh3?= =?utf-8?B?eWt2WFlIOEJVOEl4aG9USkhieWNEZzVXMms3Qnk1bklQeUZtUTVsQ01ocndy?= =?utf-8?B?UGRsM014Zk1xZnV4SmVlbHBIN25wWHRSVjJ6OGVERWpFTVk4ODZMYzBLY3ky?= =?utf-8?B?aFJyaVZFNVFycTh4WXJ0Z3BEU3VvRGxxYnVlQ0hxOVdEd0tVS3pFcVlOa0Jp?= =?utf-8?B?QlpxL1U3ellBSDdnUTlSeTNEUjZsekpNSGk1RUw2Zi9leDZxV1RRTHlOOW96?= =?utf-8?B?eExPcm9aVVhCNmxNaGp2VXFndS9aeEp5Y1RkK2hiMGdZd0Z2SXFKa3RyWm5J?= =?utf-8?B?WlFDdlhjcW40V1ZBdU5TUkd6elh0ZmZhUGV4SC9kMmxISWV2WlFpL21nVU5v?= =?utf-8?B?WHE4cGVrZHVkVUpTbHV1cGFtVmQzTmF3UUpmVnJPS0I4ME04OUtNU0l1Qm1h?= =?utf-8?Q?ivx0=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YUVQVkNiMnJhdTlWQWlBZTloQlZROUNuQWlHNnJIanFFb1dUcyt1S2NxNTkw?= =?utf-8?B?dFA5dEh5MW1MVmk1bFUzREx2TEREb2piNUFCaEpxeXlJa3UxeGhKQmN2ek1u?= =?utf-8?B?ay9xU1laMzZsYkpqWlJWWm55RklGdHRpb0xMZjBCMUVlRUhOakwvSURxNVFJ?= =?utf-8?B?VHFlTWtWRDNDNEhxQlF1Wll5TnJ1SmVWUEpiNWM4b0d4dnNZSzhCVHF5S1Jo?= =?utf-8?B?Q0ZqRG1zdERicjJ6K3JYaFViZ2YzdHlWNFEzWDFJTllCbWQ2K2FUYW1vVzJT?= =?utf-8?B?NndHUGkzVnhOVDlYYnBwSEtjcTN5OW55bkY1MnFEc1NUNXJJRlNzSEh6R0N2?= =?utf-8?B?NWlBQmY1WDVwT2xXcFRxWDluVzlPMGkzYTk2QkVnb0s2NVBQRFlLa1orbHEy?= =?utf-8?B?d3QvTGNDN0ZqOFYvWDRkK0haZWJ1N3NoaTIxZFIwTUxyWmlDbWtIQzBCL3pi?= =?utf-8?B?b1lNNHZIelo2SHNMQTQzWnFZNTJZRmJ6akU4c1lWYkw0bzE3UTFnZGVBdHg5?= =?utf-8?B?bWhoanZ3bWNZVUNUa0tYNWoxV1FIK2wrS1hRamI0Uis5OFg4OGYySkpWRzhE?= =?utf-8?B?SmtYU1RMTEFJbVhzYWlKYkdQbDJCQnpBOENuVmRxVW43YU1OQzJqWkM5RGdN?= =?utf-8?B?VURMWTdiaHNWSTNjOElMNktqWFU5RytpZmVMckxvMWNXT0tnMVFTaGNoL01P?= =?utf-8?B?ekN6R0FxL0FtZERHSW9rbERuaWRPSHh4WFExT0tNd3RyNTFNbDR4K2ptaTYr?= =?utf-8?B?RG1mVlRuRU9RUEpJQ0t4NG9NRUZNTzNGZjd5WEVSQUtaY1RtM1dkNElDS2RM?= =?utf-8?B?MHFCdGFzb3AvclFMcFRycmsrU1d3TGJoMzQ3QTFQS2JmQjRvS3hJbW16VHVx?= =?utf-8?B?QTBMdlRTVHdXejdoZ1RuNng5NFNFVVk1L2poZGdhbU5lNU1jc2VVZGZhK2xE?= =?utf-8?B?aGZUSmFackZBeVNWNHpRd0xzOHhRRStVZVE0VERaenM0N2FqeGJhYTgvR0lZ?= =?utf-8?B?aDRjOFhCbXJIVjdyaXdTdWxDV0JZd1VxNTIyZGg5UmI3dTJaTEY0ZEpUS1Ev?= =?utf-8?B?ekdEOEJPS1Z1N1E2MFVVNkVVM0hnbkR0MnVNV3BVU0VkdXZzWlhjdk5HMDhG?= =?utf-8?B?bVdOd05FK2ZRUEtleWVOQXBDdWd3ZXpneFdwc2RUU01Kc3c4cktCejZPbFpn?= =?utf-8?B?eTZmMUpmWEFlelhyT05VSU1za0dRMGNxbmovMjllUWJxQmZNRzYrdTZVaE5x?= =?utf-8?B?ZFVScFZ0Umt6V295a0lwVHk4ZjdDSVFYR2VlRnZMbElXQnY5WEhDT0Zndk13?= =?utf-8?B?djR0N1g3a1Y5cGpHOUl4TGhNM2N1L0FSRUZEM3BYb28rMEhGdXQ4dkFTVkdH?= =?utf-8?B?TTJHL0J4eVlVZDM4b29KY01zRkZ2QjdsQ3NOdkh4MmRMR21IYTQ1N3Fna3ZN?= =?utf-8?B?b1hHN0Jvdmc4RE1Nc25qQVRZMGNCMjVQV2lZcDNrZlBKU3RVWmRKc05SK2dX?= =?utf-8?B?dEk0ejhGaUpaNmdmRGc3ME5HVkhTZWRaWTUyREJyVFY0NUpROGtLbFZOUklC?= =?utf-8?B?NHQvNE8wSEdjeUtKZDZlRkJYc3FjZTVpd2pCY2Fsb3U4dm9OSDhzdHRoRWZI?= =?utf-8?B?bHhXRDBqWXEzTERXM0Uxb050TldkR2daTVVNTENyT2F3czNwYitoNW9JVFpR?= =?utf-8?B?Sm5CaFFTaVNTaUE1am9EU0cyM1ZyWlBDb3ppVGdJeTM2TkZRRkthSnk0VXgw?= =?utf-8?B?dEIwVjR3UmlDVExOeWVFUVplQ3dLVGMwZ2VYRjFCNEk2aEFIRzJBZWVjNnE3?= =?utf-8?B?MmlwdFprSXBNS0FZekFrUGNxb2ZRRG9vcTBSL2xPSEsydlRFVFFpYmFJRTky?= =?utf-8?B?bVZqeHNSVnFjMzkwdVFEMzJBWW4xdlY1Y1JTeldtZ2dBQ0lNYkJobTZyVEpU?= =?utf-8?B?SnorOEFnNXM3dlRKL2UyNElManFvRkJQVTh1eEZMdXVrc0xJY1pMNVNQVW0x?= =?utf-8?B?T25ZYnFxZmU2SU1Ib05yS1ZxSm5nbEZYQVNsSFN0VU8xL1RlTnR0N0R5ejFC?= =?utf-8?B?bkticnJPWHNYazBOaEVXSXdlOTdzc1JzSnkzdGVzOERwWEdXak45TWhLS0d4?= =?utf-8?B?MFZ3NjdDYWhTbUJUVkNLaW84MEVDUnZ1ZjhZcDNrVjB0ZUxRNStTblNnRnBq?= =?utf-8?B?alBXbHhKOW00YkgzVlo4V2FMbTFNanJjSjJkUGc2dVYwL1JMWG52QytmOFlD?= =?utf-8?B?ckpPdnhCUitqd1hLckxiaFh2anJOTmlEMVpiL3I0UHZtOXUxbExXUnBacVQ1?= =?utf-8?B?Z0pJcXhhM2RXR3RtNnpMZTJvVi8wblJ3aEJtVmpKdjhITWJmcnp5dz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: bc942b22-9e86-4f94-2967-08de5dc70bce X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 17:11:01.2898 (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: yteQ4dKiKbK4Vcd0ur81h1YQMCVpmiEDvWc4TBGJKAoyShJYgDXp99jGyWIQcZir0WruTKj2vePnV1RO2wGR6EFcoPF7lNANCAbcumA9NiU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB7776 On 27/01/2026 5:01 pm, Jan Beulich wrote: > On 27.01.2026 11:18, Andrew Cooper wrote: >> All of these are simple cases of using typeof() to avoid multiple parameter >> evaluation. Using auto avoids multiple textural expansion also. >> >> No functional change. >> >> Signed-off-by: Andrew Cooper > Acked-by: Jan Beulich Thanks. While I've got people's attentions, there's a secondary pattern we use that's a bit less clear to convert.     typeof(a) *_ptr_a = &a; With auto, you're required to write this as:     auto _ptr_a = &a; rather than the more-nomal-looking:     auto *_ptr_a = &a; So far I've only found two examples, and I'm debating leaving them as are seeing as auto (in this form) is still a new concept to most. Thoughts? ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 27 17:51:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 17:51:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215120.1525381 (Exim 4.92) (envelope-from ) id 1vknDn-0007hi-F7; Tue, 27 Jan 2026 17:51:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215120.1525381; Tue, 27 Jan 2026 17:51:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vknDn-0007hb-Bq; Tue, 27 Jan 2026 17:51:23 +0000 Received: by outflank-mailman (input) for mailman id 1215120; Tue, 27 Jan 2026 17:51: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 1vknDm-0007hU-Bw for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 17:51:22 +0000 Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c8322f4c-fba8-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 18:51:19 +0100 (CET) Received: by mx.zohomail.com with SMTPS id 1769536265579732.5117684063396; Tue, 27 Jan 2026 09:51:05 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c8322f4c-fba8-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; t=1769536269; cv=none; d=zohomail.com; s=zohoarc; b=jUfwhqCOEGD87uKQvKdjlo6ohYo1+E2Ohh1nh7InUi7Q092banYqJNfrRAlCvZLLqP1lGNnT4AV0DYk/PoS96R499bGXXvtRFQCi1jyT4JKOBfzkN4vkRMH3FUxbOSbq9adBuiUjh9MmjpM+e+yA79LUrnQJiA6h/+l5i5cfqZ0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1769536269; 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=OrN+s/CeBkvY6OLF544byRKGHNDaX7CsVaNVPwnDGfc=; b=OJYlu4dNi/Ul8OKgjDVr0qAZ8Jjt3j6dcLR2C0h+VrNK0/4OB8t6qXo2nhx1wjku2T8axzavKMO0r2oKy3RUiMp1bPcT9TldAJAYsJQE2U7LkYoPgQvw1gJumAwKudonDe/q2/cyvrSp2jdktAp3CgoYPY7qs7qj8OS6iSxWt1I= 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=1769536269; s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=OrN+s/CeBkvY6OLF544byRKGHNDaX7CsVaNVPwnDGfc=; b=cF5/R/ccxnaHT1T+coJsTSP1WS8dTcoGsy7e1p9ZLCCL9JbHa0WFV/3baNqerSed DgSyO2pf3pRxligYTpq4EFTA9acvcDz2eApkQKfQnyCljcFpIU+8mdoQLnOPE3zY1c1 iNbs5UGO9NMNZSEvj32/57DRR0NQexFBNHKq9rgU= Message-ID: <41b1096f-e9f9-4e7f-a718-4cc9bce9b0a1@apertussolutions.com> Date: Tue, 27 Jan 2026 12:51:05 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 08/16] xen/sysctl: Drop XEN_SYSCTL_get_cpu_levelling_caps To: Andrew Cooper , Xen-devel Cc: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Oleksii Kurochko References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-9-andrew.cooper3@citrix.com> Content-Language: en-US From: "Daniel P. Smith" In-Reply-To: <20260126175345.2078371-9-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ZohoMailClient: External On 1/26/26 12:53 PM, Andrew Cooper wrote: > This hypercall is an addition of mine from commit 67528a3f0649 ("x86/cpu: > Sysctl and common infrastructure for levelling context switching", 2016), but > it never got wired into any toolstacks. In the meantime, how we handle CPUID > for guests has evolved substantially. > > In order to reuse the AMD levelling infrasturcture for boot time quirks, > levelling_caps is going to have to change. While it's probably safe to expose > this difference, it's safer still to make it an internal detail. > > When re-plummbing the LCAP_* constants, turn them all into single bits. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Roger Pau Monné > CC: Julian Vetter > CC: Teddy Astie > CC: Oleksii Kurochko > CC: Daniel P. Smith > --- > CHANGELOG.md | 2 ++ > tools/flask/policy/modules/dom0.te | 1 - > tools/include/xenguest.h | 1 - > tools/libs/guest/xg_cpuid_x86.c | 14 -------------- > xen/arch/x86/include/asm/cpuid.h | 15 ++++++--------- > xen/arch/x86/sysctl.c | 6 ------ > xen/include/public/sysctl.h | 22 +--------------------- > xen/xsm/flask/hooks.c | 4 ---- > xen/xsm/flask/policy/access_vectors | 2 -- > 9 files changed, 9 insertions(+), 58 deletions(-) > > diff --git a/CHANGELOG.md b/CHANGELOG.md > index 18f3d10f20d2..425118bc9ae9 100644 > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -19,6 +19,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) > - The cpuid_mask_* command line options for legacy CPUs. These were > deprecated in Xen 4.7 and noted not to work correctly with AMD CPUs from > 2011 onwards, nor work at all with Intel CPUs from 2012. > + - The SYSCTL_get_cpu_levelling_caps sysctl. This is not known to have been > + used by any toolstack. > - Xenoprofile support. Oprofile themselves removed support for Xen in 2014 > prior to the version 1.0 release, and there has been no development since > before then in Xen. > diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te > index d30edf8be1fb..aae69041a966 100644 > --- a/tools/flask/policy/modules/dom0.te > +++ b/tools/flask/policy/modules/dom0.te > @@ -43,7 +43,6 @@ allow dom0_t xen_t:xen2 { > psr_alloc > pmu_ctrl > get_symbol > - get_cpu_levelling_caps > get_cpu_featureset > livepatch_op > coverage_op > diff --git a/tools/include/xenguest.h b/tools/include/xenguest.h > index 7c3b8b098352..2a277cb7cd61 100644 > --- a/tools/include/xenguest.h > +++ b/tools/include/xenguest.h > @@ -822,7 +822,6 @@ int xc_cpu_policy_update_msrs(xc_interface *xch, xc_cpu_policy_t *policy, > bool xc_cpu_policy_is_compatible(xc_interface *xch, xc_cpu_policy_t *host, > xc_cpu_policy_t *guest); > > -int xc_get_cpu_levelling_caps(xc_interface *xch, uint32_t *caps); > int xc_get_cpu_featureset(xc_interface *xch, uint32_t index, > uint32_t *nr_features, uint32_t *featureset); > > diff --git a/tools/libs/guest/xg_cpuid_x86.c b/tools/libs/guest/xg_cpuid_x86.c > index 263a9d4787b6..0db6d77cd801 100644 > --- a/tools/libs/guest/xg_cpuid_x86.c > +++ b/tools/libs/guest/xg_cpuid_x86.c > @@ -36,20 +36,6 @@ enum { > #define bitmaskof(idx) (1u << ((idx) & 31)) > #define featureword_of(idx) ((idx) >> 5) > > -int xc_get_cpu_levelling_caps(xc_interface *xch, uint32_t *caps) > -{ > - struct xen_sysctl sysctl = {}; > - int ret; > - > - sysctl.cmd = XEN_SYSCTL_get_cpu_levelling_caps; > - ret = do_sysctl(xch, &sysctl); > - > - if ( !ret ) > - *caps = sysctl.u.cpu_levelling_caps.caps; > - > - return ret; > -} > - > int xc_get_cpu_featureset(xc_interface *xch, uint32_t index, > uint32_t *nr_features, uint32_t *featureset) > { > diff --git a/xen/arch/x86/include/asm/cpuid.h b/xen/arch/x86/include/asm/cpuid.h > index f1b9e37a42ca..c7ee1d54bc7e 100644 > --- a/xen/arch/x86/include/asm/cpuid.h > +++ b/xen/arch/x86/include/asm/cpuid.h > @@ -15,15 +15,12 @@ extern const uint32_t known_features[FSCAPINTS]; > * Expected levelling capabilities (given cpuid vendor/family information), > * and levelling capabilities actually available (given MSR probing). > */ > -#define LCAP_faulting XEN_SYSCTL_CPU_LEVELCAP_faulting > -#define LCAP_1cd (XEN_SYSCTL_CPU_LEVELCAP_ecx | \ > - XEN_SYSCTL_CPU_LEVELCAP_edx) > -#define LCAP_e1cd (XEN_SYSCTL_CPU_LEVELCAP_extd_ecx | \ > - XEN_SYSCTL_CPU_LEVELCAP_extd_edx) > -#define LCAP_Da1 XEN_SYSCTL_CPU_LEVELCAP_xsave_eax > -#define LCAP_6c XEN_SYSCTL_CPU_LEVELCAP_thermal_ecx > -#define LCAP_7ab0 (XEN_SYSCTL_CPU_LEVELCAP_l7s0_eax | \ > - XEN_SYSCTL_CPU_LEVELCAP_l7s0_ebx) > +#define LCAP_faulting (1U << 0) /* CPUID Faulting */ > +#define LCAP_1cd (1U << 1) /* 0x00000001.ecx/edx */ > +#define LCAP_e1cd (1U << 2) /* 0x80000001.ecx/edx */ > +#define LCAP_Da1 (1U << 3) /* 0x0000000D:1.eax */ > +#define LCAP_6c (1U << 4) /* 0x00000006.ecx */ > +#define LCAP_7ab0 (1U << 5) /* 0x00000007:0.eax/ebx */ > extern unsigned int expected_levelling_cap, levelling_caps; > > struct cpuidmasks > diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c > index 1b04947516bb..0fbbdd8b280d 100644 > --- a/xen/arch/x86/sysctl.c > +++ b/xen/arch/x86/sysctl.c > @@ -289,12 +289,6 @@ long arch_do_sysctl( > break; > } > > - case XEN_SYSCTL_get_cpu_levelling_caps: > - sysctl->u.cpu_levelling_caps.caps = levelling_caps; > - if ( __copy_field_to_guest(u_sysctl, sysctl, u.cpu_levelling_caps.caps) ) > - ret = -EFAULT; > - break; > - > case XEN_SYSCTL_get_cpu_featureset: > { > static const struct cpu_policy *const policy_table[6] = { > diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h > index 66c9b65465cc..6b4ec5f7f765 100644 > --- a/xen/include/public/sysctl.h > +++ b/xen/include/public/sysctl.h > @@ -932,25 +932,6 @@ struct xen_sysctl_psr_alloc { > } u; > }; > > -/* > - * XEN_SYSCTL_get_cpu_levelling_caps (x86 specific) > - * > - * Return hardware capabilities concerning masking or faulting of the cpuid > - * instruction for PV guests. > - */ > -struct xen_sysctl_cpu_levelling_caps { > -#define XEN_SYSCTL_CPU_LEVELCAP_faulting (1UL << 0) /* CPUID faulting */ > -#define XEN_SYSCTL_CPU_LEVELCAP_ecx (1UL << 1) /* 0x00000001.ecx */ > -#define XEN_SYSCTL_CPU_LEVELCAP_edx (1UL << 2) /* 0x00000001.edx */ > -#define XEN_SYSCTL_CPU_LEVELCAP_extd_ecx (1UL << 3) /* 0x80000001.ecx */ > -#define XEN_SYSCTL_CPU_LEVELCAP_extd_edx (1UL << 4) /* 0x80000001.edx */ > -#define XEN_SYSCTL_CPU_LEVELCAP_xsave_eax (1UL << 5) /* 0x0000000D:1.eax */ > -#define XEN_SYSCTL_CPU_LEVELCAP_thermal_ecx (1UL << 6) /* 0x00000006.ecx */ > -#define XEN_SYSCTL_CPU_LEVELCAP_l7s0_eax (1UL << 7) /* 0x00000007:0.eax */ > -#define XEN_SYSCTL_CPU_LEVELCAP_l7s0_ebx (1UL << 8) /* 0x00000007:0.ebx */ > - uint32_t caps; > -}; > - > /* > * XEN_SYSCTL_get_cpu_featureset (x86 specific) > * > @@ -1270,7 +1251,7 @@ struct xen_sysctl { > #define XEN_SYSCTL_pcitopoinfo 22 > #define XEN_SYSCTL_psr_alloc 23 > /* #define XEN_SYSCTL_tmem_op 24 */ > -#define XEN_SYSCTL_get_cpu_levelling_caps 25 > +/* #define XEN_SYSCTL_get_cpu_levelling_caps 25 */ > #define XEN_SYSCTL_get_cpu_featureset 26 > #define XEN_SYSCTL_livepatch_op 27 > /* #define XEN_SYSCTL_set_parameter 28 */ > @@ -1300,7 +1281,6 @@ struct xen_sysctl { > struct xen_sysctl_coverage_op coverage_op; > struct xen_sysctl_psr_cmt_op psr_cmt_op; > struct xen_sysctl_psr_alloc psr_alloc; > - struct xen_sysctl_cpu_levelling_caps cpu_levelling_caps; > struct xen_sysctl_cpu_featureset cpu_featureset; > struct xen_sysctl_livepatch_op livepatch; > #if defined(__i386__) || defined(__x86_64__) > diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c > index b250b2706535..28522dcbd271 100644 > --- a/xen/xsm/flask/hooks.c > +++ b/xen/xsm/flask/hooks.c > @@ -884,10 +884,6 @@ static int cf_check flask_sysctl(int cmd) > return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2, > XEN2__PSR_ALLOC, NULL); > > - case XEN_SYSCTL_get_cpu_levelling_caps: > - return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2, > - XEN2__GET_CPU_LEVELLING_CAPS, NULL); > - > case XEN_SYSCTL_get_cpu_featureset: > return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2, > XEN2__GET_CPU_FEATURESET, NULL); > diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors > index ce907d50a45e..bbb9c117ec4a 100644 > --- a/xen/xsm/flask/policy/access_vectors > +++ b/xen/xsm/flask/policy/access_vectors > @@ -87,8 +87,6 @@ class xen2 > pmu_ctrl > # PMU use (domains, including unprivileged ones, will be using this operation) > pmu_use > -# XEN_SYSCTL_get_cpu_levelling_caps > - get_cpu_levelling_caps > # XEN_SYSCTL_get_cpu_featureset > get_cpu_featureset > # XEN_SYSCTL_livepatch_op Acked-by: Daniel P. Smith From xen-devel-bounces@lists.xenproject.org Tue Jan 27 17:53:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 17:53:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215133.1525391 (Exim 4.92) (envelope-from ) id 1vknG4-0008JT-Vo; Tue, 27 Jan 2026 17:53:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215133.1525391; Tue, 27 Jan 2026 17:53: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 1vknG4-0008JL-Rr; Tue, 27 Jan 2026 17:53:44 +0000 Received: by outflank-mailman (input) for mailman id 1215133; Tue, 27 Jan 2026 17:53:44 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vknG3-0008JE-WA for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 17:53:43 +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 1daa6f61-fba9-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 18:53:41 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB5696.namprd03.prod.outlook.com (2603:10b6:a03:2d6::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.16; Tue, 27 Jan 2026 17:53:32 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9542.015; Tue, 27 Jan 2026 17:53:31 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1daa6f61-fba9-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iAgeT2gPbo5CWx88uyA5LorjdNpsvwfsvbKgAuhULWkMtRHYO8/0rOoin9kBI1iTecleQTWzO6d5gz9AgH0HQpRW+3rr09ZwOfPBWp0Nkfg6LH7XIt1TzZzWE8pn1DCb0F8d9PUXffLX32CbsK+m4Sjfp3Dlp1pceM5q2gB7Idwzh5JMUkbMKztrPjuBh9UR1I5huTAwDabqteJy8qYMdyh+PT5KkrF2xfaMmeB8K3cEU0Vl77UgimTZ2jS5hds9lb8N+M1tAOQX6DGosuDK4cseSHHvgAoeD9K1dxrTp74JG2CDcI6CkVUrswMG5QXRkEIcGVBIWrex5TNs4mVn1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bYMHXhUJojfWOSbbn361uS305nfUnjv+zdcUOQdX3Uw=; b=br+fPNBe+3aSGcPXnAYUGh56f0+xK7/4BITEF6wezrDuMLMF09QJrUt+tOui/J+uxk0u+LXYjde9frgdbndPP3ODZUmnIAf4ig/F7/WDH8GSa8miNuMZeUO28Jac3ed4opFW93PF3XmY9d1fyiYpk4zGItnbdt6rRu+OKqudBwFcD+2D3PgGqHEG0e7J6dENvSljpSfWHoneIrCzPUd9BM4dBVj3E37PYnqd4j5dRmCbyyb86zoerw96g5fmsB1CPjX55McbDM2BgQLGxqzm/9xGx9/Nrl9YQxxvb1zAqV8ztdZVeMY87tbY8xbVT6BasOQYvA/yS/qVD85l8hqDPw== 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=bYMHXhUJojfWOSbbn361uS305nfUnjv+zdcUOQdX3Uw=; b=SRrbC61pFYwnDYeT/lPsS9UG6YjQR94x/hNFJIEplxSASYoafYmeFBHAyfyBliH5JS66GyFRNZ1qTNgu9REnxEdEE1jMqwsvTaQ/Vp6ZmQBvGJp4D56ibDwpk3Yqsk/508q6dkkeP0ImZ5nnBhTRDM0r11KpFCoj/yrgbivPoWk= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <1fd00308-f072-44f1-936b-8668f4e9ad05@citrix.com> Date: Tue, 27 Jan 2026 17:53:26 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel Subject: Re: [PATCH 01/16] x86/cpu: Fix boot time cache flushing To: Jan Beulich References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-2-andrew.cooper3@citrix.com> <15978c88-5ea9-4159-951b-27c9fc004756@suse.com> <3ded84f3-505e-40f1-b7d5-f136663af7cd@citrix.com> <52fe1a23-70bf-4282-a41a-7b153fd1f7c9@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <52fe1a23-70bf-4282-a41a-7b153fd1f7c9@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO3P123CA0002.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:ba::7) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SJ0PR03MB5696:EE_ X-MS-Office365-Filtering-Correlation-Id: 5f16856b-55f6-4237-6496-08de5dccfc0f 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?RGZZRHZrOVkzekdWeGZ6TVQzK1gvb0dJOVY3ZE5yUFJPT2lEUFdKejZ2aWdn?= =?utf-8?B?eU1mazNEWHJoQzJxVXJWeXZORzJaWXdwZ25QUi9MZXpvODNTemlORG83djhs?= =?utf-8?B?c2RCMXJVK25taDcveGFmcVRnWDFkK1hROXM5bVBWSzdRZTN1Nzk2Zis2QnE0?= =?utf-8?B?S3dGaWVwSjFnTUpxWUgzMDlHeVU1OFpiOGlSVll2WVp0MjhTK0FGN0o3alhp?= =?utf-8?B?bks3ZDB3bmticXp4Z01TTlFKUXQ1OGZJK0VOdGlLYzh4T29VUjZod2FZeisw?= =?utf-8?B?M1E3ZkptamdHaDltNDRxNUhoQk9NUVowVlZ3cmJmMThrVEtxSHVGTUxCYTBB?= =?utf-8?B?SWZpUElLY1ZUY1owZTlWcm1rU1V6L3ExeVZVUlNwUXZzOGJFYll5TmkySThj?= =?utf-8?B?S1VlWXJhMmF6ZTZMWUdmcGlFdVhyMEsyQzZkc1lycnhycGpFbWdtdjRHMjRq?= =?utf-8?B?TU84UDJrOFlKRG5Wb3FuN1I4NzFJaUlod0c4aWJSclRHMndtUVBZVjFVS01y?= =?utf-8?B?ZTRkcmIrUWc0VEptcms2OU5oeHRCTW9xRDJ3K0N4aUl3bEhNZEJjaGxpcHdS?= =?utf-8?B?M1BXOTBaSWhXN096YVZjbkU1MytHNSt5NGQ3RG8rVDllMTVPTWhnM3NaRG1p?= =?utf-8?B?dGtEWEFtd0NSdUJyVDVwWVFGM0VkT1FadGs5VDlRQ3dkdXRUTlVFSGZtcjI0?= =?utf-8?B?YkVhZ0syUDIrRDA0aFdkTk5xRDlQVnBvN1pqeVFIOG9JSEtuUUFYb3ZQek1t?= =?utf-8?B?bUIwRHJlTDBDbmMxYXhWOHlJU2lnMEZVem0vOTVYSVhlWXdlSmN0SW9Uc2pB?= =?utf-8?B?SnFRQk80dUJJbWJlNmg1SnZjNmdPdlZwWnpPRFJVVUdNZXdHbEFINGd2aU04?= =?utf-8?B?eDZCMXhLMG5DY0hiY0xzNWVKV0RRdkxYMldxSklISzF6b3YrMTk4Qis5VHJv?= =?utf-8?B?Wk5YYkZKbzlIYWNONkk5UEczb1hRNmJ4dm1yWUpva0VYRm92TlRVYWVucWZu?= =?utf-8?B?SE5hYmJrQTdRS0JrYUlDV1Vrc3Ntai92VnA5QTg3TStrcXo4SFhibktvYVNj?= =?utf-8?B?NzZTc0dJK0lzNzlzZHJ2UUo3c3NJcVFsT1ZlWjVVanVCd2pweGFsRDdUbmU0?= =?utf-8?B?TjNKZ0poUXI0MmNjblpTcVVqMHAyaDdLVWpZcWhvNG5TNzlsTG9ac0pjb2hB?= =?utf-8?B?eGRFb3M2S0p2MXFKT0tISlBBZnI5bU5tL1ZmTENTSXBEZW82MlBoVElLREhX?= =?utf-8?B?S01Dc3ljMlZwVjdnamwrb3RWVEoxMDZLSVRBU0ZXVFgyN3dOdVhwZTdaTTg1?= =?utf-8?B?c2xqWHc4NnFnTldLQ29zcWJHVzhVTkw3UE52NVF2VFB3VXVlbEhEM3NFMEpw?= =?utf-8?B?NWcyYjB0Z0RsWllHYW5YWGIzekFkK0RHNXI2Y0xWbXpEVVIvTnhEVHhSTmp4?= =?utf-8?B?NXgvSjgraGd4cHlVUlJYbUkyR2k4L3UrUEd2ZDNWMjZ3MitDNjNXR1lSMFky?= =?utf-8?B?ZVljRmpieEFPQUpxdVloMnh1ajY4c2h0L3dTOUtjS0VoSjF0UjM2NFFPYUJk?= =?utf-8?B?WnBDWUc0Y3VlbGNhNHp4QkdHaTdJbC90V1FnM2MrT3loUldoMGZHd0ZGWFhm?= =?utf-8?B?QWd1aldlT2NRellCUCtpOUdFNm9BSFRlaHh5TzA4ejJiRWRvOVl2TXc1dDJL?= =?utf-8?B?L1lnNVEycGxMd0tsVVRsY2d5QWlyUVh3L21sY1gwYW5SaFY3Rkl3MUdUek9p?= =?utf-8?B?VkJGeDI4S1FsdHZucGlHeTFRNktSWmdRb25mNXluMWJOZlh2ME1tM2hONjV1?= =?utf-8?B?RTZ5SjkzM2crcmVFbVpmK3JiNkh4MnRDYjF5cU0zbndKTWR1a1JJZ0dzbFl2?= =?utf-8?B?OThCMm9rL1BVaGVtMmRUVmpOSkFOZW9YbmJtWEFFZGl1TkdacjVtOHBmNDBJ?= =?utf-8?B?UldQNEg2YzM5UjAxNndIVi9sWFBRUnM1QmVpT0RYUTdQUTl6MlYvZndGWU1r?= =?utf-8?B?TzJFSGFMY1QxajhkUDFyZVpmV1NxOXBXUXdyeXVaVllxVlZ5TWw2amVOZ2pz?= =?utf-8?B?Tm5xNVZtQXRpQWljZGFtSmpNcmc4WnZnZlRCTzR4cnhMR2sxRllxN0JCMlRD?= =?utf-8?Q?0SVM=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TlUzUUNQdElxbDVQUkxGT09RWEZqT0VSZXpCM1hibDhoVDRkSmU4M3BZVllX?= =?utf-8?B?T3RRVGlEb0VVVCs2aDVyNXVmbUxwajdoeUx2UEJVMzVMMGQ4dzYxU0x4ZnB4?= =?utf-8?B?MG9uRGpHcXhTOGNjcWVvME5JUVZCcDNaaHg0K0VUdkNuMlNCNWp4WWZldTlH?= =?utf-8?B?M2l2a1l5bmZPWnhMZDFndnF6Z2J5VEoweWZqWUR1S2NVVzBYY0V3dU5ucHlm?= =?utf-8?B?NDc3aHprR2pWYWNnckFTUjZMTTR3RDFDbjMvR2hDeUU5dGc0M2pMMXNhR2JL?= =?utf-8?B?TnJEZ0E3Z1FMTVAzNUxvL3p3VUJ1dWoxNS93ZmpOelVaSGVMZ0xvanp4cGVx?= =?utf-8?B?cmt3SWd6bXhEWC9QeU9Dc3dEQXhaQkxkN2dFUzBiTnpUUlFJM0tWUGZOa3Vk?= =?utf-8?B?aWVzMEZMU2piQ0NtNWRlVnFFZHp2dy94aHVxNUhCNGhZOEJoQXFKZFREVGtT?= =?utf-8?B?UEQ2TzcwdkI3UHNVMWFZV1pNbUl1YllqUHZvVTJKRmJaTWJuaDlwOExvZEZq?= =?utf-8?B?VmFBVzFEeEdNc3ptVlhDa2NMMW1nS1AzcXRiUHBVazdLS0UrbEFoV1BQbGt0?= =?utf-8?B?THRyN21BajRvanNHY0RiS2lWbGk5aHpWNHZqZVhwOVhEZHR3YVVzNW42UUk3?= =?utf-8?B?RlNKbnRZeDdIRXUvZUo5SXBKZVd2NWRvZFpnNFhleUIzSEtHTGllK1dSamZH?= =?utf-8?B?WDNUdmxwWVEwa0pCNUNpcUZldGhqbkZwbHh2ZUpDWVdtMml0bkZqcUo1SU4z?= =?utf-8?B?cTE1eVNtOUVWc3FoT2lpc2dvcFd2REdYSGgySUNxdXNJOTE5cUZnOEpvSHJO?= =?utf-8?B?a0NNYlI5MDhRYkNWL1ZxTDR1Qkt4dy84YU4wWHBmTUh2a2tBQVJLZXNiRE9i?= =?utf-8?B?d1BRS2NxNHZWRlg3YkRjYlJhc1prYXcvTXJGV1ZubFdTQWZnZlJ4YXJzbFJm?= =?utf-8?B?a0RXR0pNak5XRk5QUXVzQ2srZXBkUUVaYnpNaHpQQ3c5UmE4UG9wem1ISDhG?= =?utf-8?B?R1paNzR3dThuMWZXbjh6c1N5QU5zS2FuaHFhQS81T2RURlpzWURSQ2xPRkFt?= =?utf-8?B?aVFvenE2RDNla2p2akQyeU5qS093UlFucmtGUVVQb00xdmI4b2lUb2k5U0Fk?= =?utf-8?B?UG1zaTQ5OE5jRzVVUklLbm9GUFREcVdnV0ZGY2dDM1VFSXcvL1ovL0lCWmp6?= =?utf-8?B?VDI0TThZOGlRdkhBcDk1bmtNczhMRGg4ZGZHRXhYbk9FNzV4U1ZPR1BtZkRj?= =?utf-8?B?bi96QWl0MGU3a0VEQUxjM1ltNHhiWDRYRjJCejU2ZmJXMkRaazQ1Vmx0aU1Y?= =?utf-8?B?L1ZNTlplNlJuWXVIbTkrVlVFUDRYbTJXSXBGSWxlZ1ozMW1mNmlITzExc050?= =?utf-8?B?dDlLUk4rYndHQk1UZXpyY0NzUmhIcSthUnpsczJpRTFzNDZnUktwemRUQmVs?= =?utf-8?B?Ui9MMlJ2MFZWSWg4OU5rRUNsekUvVHQybTlncFZTeUhScGFpdDd1YWRvYVlI?= =?utf-8?B?aVB6dDF6VzdEMnNJT1Nka1ZKTDRHMkVnRkZkMVRvN3I3M2lEN2tNTlR4V2ZV?= =?utf-8?B?UTdrSzlLY3J0bmhWVjVHcENvakZmL2RzM2V1M2E5TG56cm9wR09tMk81OVk5?= =?utf-8?B?MlRQTGdSSDJ3OWV5VXdpTXorSS9FTjhFQ21ZV2ZzMkhGbzRVVVhDenV4Zksx?= =?utf-8?B?bjFlT1AwbVpMTUpZWUdSYUg3dGdkbWtDYzE2b3poUDgzR1YyekR3YlRFbGMx?= =?utf-8?B?d3BLMjhVN21wbDhvTDNpVDZ6QlJ2RnZVa3hLSUUxa2lUZzJwdStXNjkyVWw5?= =?utf-8?B?Vk5EN2ZXT0FZS2FFU2NqdXg5VDd6dHVQeFZaS2VHK09NNEdKMTIwZVU4Y3Ro?= =?utf-8?B?MkpaekNrbjNPY0ZMMzNXS1BzeU8ydVBXWk80c1ZtSStKSnZwNVIxbjIwRHdY?= =?utf-8?B?dUVLN2J5TDk4NGZiYU40Mm9Fd2dWcFF1UGd1YjFDUi9BQi9yeVhJODhLTlVK?= =?utf-8?B?U3NpWGRpTENqMjFKRXJrcXVhOVlSOHRWL090M1VudWQrbmxkaER5ZFd2cFN2?= =?utf-8?B?MjJpU1k0UDlIY01YYkVvc24xelU2aVBEN3pSTWdrNGJUVEFBU3hmeU1oeHVx?= =?utf-8?B?VWhBMDNXSHJaRjJUOXJTOHhYWlEvZkdGTGJSQXYzQUJzQjRuUGw3VDAyeC80?= =?utf-8?B?Tm9aMldheVp3UzVWelhXc041VSs3QWMzbDhsT1YwaEVkT0s3SGU4dGNrQ0dp?= =?utf-8?B?ZzJmam9xSHk2M1pqRWROOENTRzFJcGF3NVFmSUNkVUo5NXhseGgrRENQSkRO?= =?utf-8?B?NW9zcVRUWThrcjZtckUxYW9OTEhsZm5nSmtEV2x2Znkxd1NPS0xHdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5f16856b-55f6-4237-6496-08de5dccfc0f X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 17:53:31.7593 (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: cDStpKbU/TeJB7m8irhWBP4R9y//oMUfhkFaHS/VtCoDoDbVNhR45KahRr63VTjnjCzOTV+f30Dfa5dD8J3O5Hui4fS8I6G2ltkwc6HB+os= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5696 On 27/01/2026 11:35 am, Jan Beulich wrote: > On 27.01.2026 12:08, Andrew Cooper wrote: >> On 27/01/2026 10:37 am, Jan Beulich wrote: >>> On 26.01.2026 18:53, Andrew Cooper wrote: >>>> --- a/xen/arch/x86/cpu/common.c >>>> +++ b/xen/arch/x86/cpu/common.c >>>> @@ -319,8 +319,6 @@ void __init early_cpu_init(bool verbose) >>>> uint64_t val; >>>> u32 eax, ebx, ecx, edx; >>>> >>>> - c->x86_cache_alignment = 32; >>>> - >>>> /* Get vendor name */ >>>> cpuid(0x00000000, &c->cpuid_level, &ebx, &ecx, &edx); >>>> *(u32 *)&c->x86_vendor_id[0] = ebx; >>>> @@ -352,6 +350,7 @@ void __init early_cpu_init(bool verbose) >>>> if (edx & cpufeat_mask(X86_FEATURE_CLFLUSH)) { >>>> unsigned int size = ((ebx >> 8) & 0xff) * 8; >>>> >>>> + c->x86_clflush_size = size; >>>> c->x86_cache_alignment = size; >>> With this change, can't the writing of the field in generic_identify() >>> go away? CPU_DATA_INIT() in particular doesn't invalidate it. >> No, it can't.  The value needs setting up on every AP, right now at least. > Are you sure? APs inherit part of the BSP's data (initialize_cpu_data()), > and reset_cpuinfo() doesn't clear ->x86_clflush_size afaics. Every time I look at that, it gets more insane. For every CPU, initialize_cpu_data() clobbers boot_cpu_data, *then* copies the result into cpu_data[] array. This cannot possibly be correct.  Why on earth did I ack it? >>> Tangentially, "cpuid=no-clflush" didn't have any effect on any of this so >>> far, and also isn't going to have with the changes you make. >> The line immediately out of context above will applies the clear cap >> mask, so will cause cpuid=no-clflush to take effect. > This concerns me. With your change, "cpuid=no-clflush" will lead to an > unconditional panic() then. So will no-cmpxchg8b.  The only reason no-lm won't is because that's evaluated before parsing the cmdline. > Whereas previously, with cleared_caps[] being > applied by identify_cpu() only after generic_identify() has already > evaluated the CLFLUSH bit, there was no effect at all. That wasn't no effect.  The effect (upon request of an impossible thing) would be that part of Xen would have ignored the request and functioned, but another part of Xen would have propagated that to guests, which will probably have equally rude things to say. > I don't think this panic()ing is desirable, but as an absolute minimum this > (drastic) change in behavior would want calling out in the description. > > Further, if the panic() was to stay, there's no point having cpu_has_clflush > evaluate to anything other than constant true anymore. I'm not overly interested in users complaining about a panic() if they ask for an impossible thing.  Better that than the prior behaviour we had. Talking of other impossible things, cpuid=no-$foo does nothing for FPU/DE/PSE/PGE or MMX which are the features hard wired to 1 already, and with 0 users in the tree. Again, Xen will assume the safe thing, but pass the impossible request on to guests. > Again tangentially (and partly the reason why I overlooked that aspect > originally): While early_cpu_init() respects cleared_caps[] for leaf 1, it > doesn't for any of leaf 7's subleaves, nor for ARCH_CAPS. No idea.  I stopped doing archaeology on all the wrong-looking things I found, because there are just too many of them. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jan 27 18:24:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 18:24:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215146.1525402 (Exim 4.92) (envelope-from ) id 1vknjt-0004Rd-8c; Tue, 27 Jan 2026 18:24:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215146.1525402; Tue, 27 Jan 2026 18:24:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vknjt-0004RW-4l; Tue, 27 Jan 2026 18:24:33 +0000 Received: by outflank-mailman (input) for mailman id 1215146; Tue, 27 Jan 2026 18:24:32 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vknjr-0004RP-Rq for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 18:24:32 +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 68aa1d4c-fbad-11f0-9ccf-f158ae23cfc8; Tue, 27 Jan 2026 19:24:26 +0100 (CET) Received: from SJ0PR03CA0061.namprd03.prod.outlook.com (2603:10b6:a03:331::6) by SN7PR12MB8102.namprd12.prod.outlook.com (2603:10b6:806:359::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Tue, 27 Jan 2026 18:24:21 +0000 Received: from BY1PEPF0001AE16.namprd04.prod.outlook.com (2603:10b6:a03:331:cafe::21) by SJ0PR03CA0061.outlook.office365.com (2603:10b6:a03:331::6) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.16 via Frontend Transport; Tue, 27 Jan 2026 18:24:19 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BY1PEPF0001AE16.mail.protection.outlook.com (10.167.242.104) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Tue, 27 Jan 2026 18:24:19 +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, 27 Jan 2026 12:24:17 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 68aa1d4c-fbad-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AEUyAdg37CmUcARjLa3U14+XYvct/XIMbH+DwE4z8tGqQ8FvRw0Fe4MUHZoTsTQ+xzjDQ9GR7SvbHBJR3GeWy4Xxd0yJPrnxIq5AcoyVqWIRhJsEMjjJu9sG2z7rGAHIFiAYFdz9O8GCxg2I8xwfdV8SIHUq1rh0B28QmscM2QVZyWv1l5rmWpNf4DbMDD+v25BDNmQk8QtK9WhNxprDkkzvM1pBobi1MG4i0xVp08onwpmo5lejEDHvLrv4D4NOGg7PCdQLAnMedGOacy+iEQIAUlZ6nG+hULVdYMgFDatCBBU+4QdPgLKDt6ST/fM/+U08LrZtiBc17B8EjVtLrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IML5BFKvjfdck5Q0nv/+mI7U0qt095NbOXoMVGFN7dM=; b=GpQA4ldnhmnZX49GxZI30J9W0g1GTRZ/qEeUxL4Foec18cGNtZLewCZrnXlYhT2wPMaHkv5rtbOu1zXiA4XbFJQNHIMgLew2aNC80mv5NTjHei5os34y13pVx7mkb5pqxvdLp41eQld22IlItebots40RAzt4TFcJWMTwq6Fx5kVJSpcwu2lvBBBuz9fOECdzSDAKw5hdDYU0qOiLYuKJIPDVhTdAyzlTaxzTurYMeRMOQ0SBoo2yphdjc3dvQ55RTbr1ZsuzsH5BRoGZF6CeYfI9nn1wQcFBn5RlQaeu0ARAfevZ9Unv5DR32SBLdKKM4OmaCzz6FQ+SAAtmLmfBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IML5BFKvjfdck5Q0nv/+mI7U0qt095NbOXoMVGFN7dM=; b=w8anWturB9F97bjYufypLkLDqbXgl+yclulJyflY68y7vcGRYrVu97EyrwDQjHHcQo+jLuibrx7qTWzL5Mlgtdfiu6vZon6YmJwfmfCXp2UrgJHnmc9yDe26702ldYGXI9DjzK9wSg7iormWUIP+f/HBREBVmaX+9CeDTvZeOho= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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 , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [RFC PATCH] CODING_STYLE: Establish a policy with regards to copyright notices Date: Tue, 27 Jan 2026 19:24:01 +0100 Message-ID: <20260127182403.141459-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: BY1PEPF0001AE16:EE_|SN7PR12MB8102:EE_ X-MS-Office365-Filtering-Correlation-Id: cecabb38-6dae-4c7b-8e60-08de5dd149b4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014|13003099007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?/SgSgePDeHWcMJers+hznzLutC69jNnEpRtWu9FCYrxhk9ev61Ca/8t/l/5I?= =?us-ascii?Q?s6VkSBHNdNvFaggqXCmdqdPnEoEHp7yMqaMZYc+dcms4JdsofR2vnoerGwqc?= =?us-ascii?Q?GNaJg4N6lgP4K46M4XQH8q25zIiBH+YvKvz641RkUnhJt74ZygbIYkzzBIkP?= =?us-ascii?Q?tpqbGclXFCzgqhtcyRJHxwcYyMOnWpOsSY4MYZFBZypgUO524QsvIL4WLTn6?= =?us-ascii?Q?bDZgSaPOXH/zs3OM5Rzoo/aYK5x0VrJB2UXZDSAYTvpgspcrPBEtsYTTtaMx?= =?us-ascii?Q?MwewUw64Y8JSvgZ1ORx2esaZqhr2+tmINymnXHjwTNAmL+XkHvC5Gs1WQ0Ui?= =?us-ascii?Q?dC93a1+/9Rr47DCThD9gSYM/3m8B+Omp7x4Ik4banKlTALWuRg0xJQ1nIv0k?= =?us-ascii?Q?pMPyClKVx4HsU66b3MBQtWGXqeVRznguISCA8VFkWnRRLZIvTkve+j5zV4MZ?= =?us-ascii?Q?GE6JKWDcl2b79tbTTjAmzBCfOQUfZmsBmOOP8oNHeirRicBowag/8WsQtmDr?= =?us-ascii?Q?+/JMXAeHcR5Guv51BebnFKnwWp57xsf8zIFEBswtGZp6oRRCfbj9Ih1Ig+3t?= =?us-ascii?Q?8gcKQxjJGmZ6y3SR10gw+1x42ueF4cWbsvoMIESX1EXoDK378kAeCAOIqXrB?= =?us-ascii?Q?0AKqkADebotC23zunA+agibCxvfQjBvsGVQQcOzAF0AUifBOmjrTZ/Q1NR36?= =?us-ascii?Q?oMZv66FemkKjYNcFbiue/AKwPUgjc9CumCUM4bbJEWMUZAYBg5rd/8KNaNV6?= =?us-ascii?Q?eogfh1gfzifNMGebpNhbc6yFoVzFwHOGpPpl3EeJjytz1T248g162z4WGVrE?= =?us-ascii?Q?o7JuxR1DG6igKtbwnzbJrvCei+r0EZW1sRLpa57aFvXhYhiqzNze8Vv1oBTC?= =?us-ascii?Q?E8LmRH3jOVnPimdfS26lXQmWISUj4mRacr0GxyVV82WWdijIRyZauUA0M7sM?= =?us-ascii?Q?9FON1sYaWxgqEJiOQgvVhY7se2DVKRMPDRfbSPJuW+tIfdoX/WxUYxsq9sdy?= =?us-ascii?Q?3MHD+w3QaGwtzopgFRl9jK8dYRjhqiSMkN7c8EKeVKO/9xR62QKlUGFDCGop?= =?us-ascii?Q?f32gun+yLocGxaDF6i3Ov5dLVJAgQ4snTl1FPARwwNWm4v5EAi7eSPxfTzgi?= =?us-ascii?Q?JUzDp59Cx8R2gjPLM2EghMPj0HhCSU98t2c4M9gZJ1CLCAx0Lfa+R2hNm/6d?= =?us-ascii?Q?CfKiZJcLSD2YZQcwC76dTNmkm+9DA7MHzHeom1W8IMEYDvv+DTJbQtVyZGaL?= =?us-ascii?Q?lMPdWxQ8VUCfIHj2o9K+VQ/QAVOan0MjLcHPlRGR0boRxtcjnv+wJkfATFq7?= =?us-ascii?Q?abhLoTrs9n27oRobcd/QAY6758l8AXqhUPJDHWXeKSjo/t0w6gmz9LCH01Fv?= =?us-ascii?Q?DmagJMfWmUXWrrPF1zhraWCtJ/5hMNYch4Xhof7bYjhezaTwkHq0DSXDl9xu?= =?us-ascii?Q?yZHlvU//sk1jF7Dw2lS1VTez/YpK37d8k8KJINsVPkfGRR2fE5HclVbqY23P?= =?us-ascii?Q?t0ICHJH/FIjjFnDeAeSiT85K9C1KAtUuZA+MrflzjGhhKksO3jgJTcuN21nM?= =?us-ascii?Q?mV9KCg4PW6A2OPSzQL6M0s4kUhUohYFcgqyPh72payzF8gLGpdh9T+nAVvax?= =?us-ascii?Q?G5EMpPD8/lrc3QgdsLcnOsk=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 18:24:19.7963 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cecabb38-6dae-4c7b-8e60-08de5dd149b4 X-MS-Exchange-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: BY1PEPF0001AE16.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8102 This patch modifies CODING_STYLE to severely discourage use of copyright notices when their presence is not legally mandatory. Copyright notices are redundant on commit, misleading from the time the file receives contributions from anyone not represented by such notice, and actively harmful for attribution by the time the original code is long gone. They are plain wrong when added on code motion.... the list goes on. All attribution worth keeping is version-controlled through Signed-off-by, Co-authored and the like, DCO and the cumulative contents of git history. License banners have already been superseded by the contents of licenses/ and SPDX tags. Other FOSS projects have already moved away from explicit copyright notices where possible, and severely discourage their use when not. Apache and LLVM take active issue with copyrighted contributions and Chromium takes issues with copyrighted contributions not attributed to the project. Some Linux subsystem maintainers already frown upon copyright notices too, even if it hasn't reached the point of being a mandated requirement yet. Signed-off-by: Alejandro Vallejo --- The actual changes are almost verbatim from the LLVM guideline, but it's not exact. Wording can be adjusted as needed. I care about the core of the proposal. Saying "please, drop the notice" on contributions where it's clearly not a legal requirement, or have the contributor state that it is a legal requirement and why. For fairness sake for all contributors to the project. I'd prefer taking the Apache approach for new contributions, but I want some discussions to happen first. Thoughts? Relevant examples: - LLVM: They banned copyright notices, unless part of a vendored components. - Links: - https://llvm.org/docs/DeveloperPolicy.html#embedded-copyright-or-contributed-by-statements - Relevant quote: The LLVM project does not accept contributions that include in-source copyright notices except where such notices are part of a larger external project being added as a vendored dependency. - Apache: They banned optional copyright notices and relegated mandatory notices to a NOTICES file that also contains an Apache copyright notice. See links. - Links: - https://www.apache.org/legal/src-headers.html - https://infra.apache.org/licensing-howto.html#mod-notice - Relevant quote: If the source file is submitted with a copyright notice included in it, the copyright owner (or owner's agent) must either: * remove such notices, or * move them to the NOTICE file associated with each applicable project release, or * provide written permission for the ASF to make such removal or relocation of the notices. - btrfs: They are highly discouraged. - Links: - https://lore.kernel.org/20220909101521.GS32411@twin.jikos.cz/ - https://lwn.net/ml/linux-fsdevel/20221026074145.2be5ca09@gandalf.local.home/ - https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/index.php/Developer's_FAQ.html#Copyright_notices_in_files.2C_SPDX - https://lwn.net/Articles/912355/ - Relevant quote: Let's say it's OK for substantial amount of code. What if somebody moves existing code that he did not write to a new file and adds a copyright notice? We got stuck there, both sides have different answer. I see it at minimum as unfair to the original code authors if not completely wrong because it could appear as "stealing" ownership. There's more cases of other projects taking similar stances. --- CODING_STYLE | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/CODING_STYLE b/CODING_STYLE index aae5a47ac2..97f80245ed 100644 --- a/CODING_STYLE +++ b/CODING_STYLE @@ -24,6 +24,24 @@ license, e.g.: See LICENSES/ for a list of licenses and SPDX tags currently used. +Copyright notices +----------------- + +Copyright for the code in the Xen Project is held by the respective +contributors. Because you (or your company) retain ownership of the code you +contribute, you know it may only be used under the terms of the open source +license you contributed it under: the license for your contributions cannot be +changed in the future without your approval. + +The Xen Project does not accept contributions that include in-source copyright +notices except in the following cases: + * where a committed file already contains it. + * where a committed file is renamed. + * where such notices are on files from an external project being imported. + +The best way to track contributions is through revision control history. See DCO +under CONTRIBUTING for existing mechanisms of attribution. + MISRA C ------- base-commit: 02bbdda863697096b63e83c2c0a37aa167045476 -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Tue Jan 27 19:52:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 19:52:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215162.1525411 (Exim 4.92) (envelope-from ) id 1vkp6K-0007kL-VA; Tue, 27 Jan 2026 19:51:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215162.1525411; Tue, 27 Jan 2026 19:51: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 1vkp6K-0007kE-S6; Tue, 27 Jan 2026 19:51:48 +0000 Received: by outflank-mailman (input) for mailman id 1215162; Tue, 27 Jan 2026 19:51:47 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkp6J-0007k8-0Z for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 19:51:47 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vkp6I-006MYG-0P; Tue, 27 Jan 2026 19:51: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 1vkp6H-00532Z-1T; Tue, 27 Jan 2026 19:51: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=v+y7yzBEh5WO3EedzhjUvSPlIbaJvw1xDziXsNuvfF8=; b= 1nGQfPUxbsBrpUQl731IErQWULu0DxDQNONzZS4k4+uuwTDFR0j4/kj52Z2AiWzkgzT1iDVrPxBZP DFEBXzmLdem+iMQbE8KGVFQh3jZakhG2tRzHEETKIvFrEQ7Ij475GqMez9DoSOFpv0qT7L6khSVY5 0QlrZlfc9xYSk0Ep8=; From: dmukhin@xen.org Date: Tue, 27 Jan 2026 11:51:44 -0800 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 v1 4/4] scripts/config: hook to automation build script Message-ID: References: <20260116043458.730728-1-dmukhin@ford.com> <20260116043458.730728-5-dmukhin@ford.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Jan 23, 2026 at 04:32:00PM -0800, Stefano Stabellini wrote: > On Thu, 15 Jan 2026, dmukhin@xen.org wrote: > > From: Denis Mukhin > > > > Use the new .config manipulation tool to toggle CONFIG_DEBUG in the > > Xen automation build script. > > > > Signed-off-by: Denis Mukhin > > --- > > automation/scripts/build | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/automation/scripts/build b/automation/scripts/build > > index 7a81d229decd..ee1127c53dc5 100755 > > --- a/automation/scripts/build > > +++ b/automation/scripts/build > > @@ -27,7 +27,7 @@ else > > # Start off with arch's defconfig > > make -C xen defconfig > > > > - echo "CONFIG_DEBUG=${debug}" >> xen/.config > > + xen/scripts/config --file xen/.config -${debug} DEBUG > > I'd suggest to add: > > debug="${debug:-n}" > > before calling xen/scripts/config to avoid errors in case debug is not > set > > I could make the change on commit if you are OK with it Yes, will appreciate help! Thanks! > > > > if [[ -n "${EXTRA_XEN_CONFIG}" ]]; then > > echo "${EXTRA_XEN_CONFIG}" >> xen/.config > > -- > > 2.52.0 > > From xen-devel-bounces@lists.xenproject.org Tue Jan 27 19:59:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 27 Jan 2026 19:59:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215174.1525421 (Exim 4.92) (envelope-from ) id 1vkpDc-000067-Po; Tue, 27 Jan 2026 19:59:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215174.1525421; Tue, 27 Jan 2026 19:59:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkpDc-00005z-MB; Tue, 27 Jan 2026 19:59:20 +0000 Received: by outflank-mailman (input) for mailman id 1215174; Tue, 27 Jan 2026 19:59:19 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkpDb-00005s-Pq for xen-devel@lists.xenproject.org; Tue, 27 Jan 2026 19:59: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 a876cd56-fbba-11f0-b15f-2bf370ae4941; Tue, 27 Jan 2026 20:59:18 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by BY5PR03MB5201.namprd03.prod.outlook.com (2603:10b6:a03:221::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.16; Tue, 27 Jan 2026 19:59:13 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9542.010; Tue, 27 Jan 2026 19:59: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: a876cd56-fbba-11f0-b15f-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HPgitN+J89ZxNCClSikbMmQZtGCOyFU2QEOfXjzlKplE4tbv9ueIwWj/7dxA4/6d3mxEF4OeUfb1mEo6TnuxDydNMfCSRkhMvZLIsfzCyDTUqC/CPefLq2f9pVi2vL6KHhxxs5A5Xq79h6wV7S4g3ftaRpMeIp5eBsMRBabSm2vWIvOLrl+8/4rq0zFlbu6GWzl4+Gp/LqwFMSvi+bGH/BZA4qf0Xd+EC+E3x1ZDu48+BLv3AK2ATIeBKcuBZiAdJwEgCYRJbmswzPhBn9uGdyVRkzfzdN4pHbBH4iYMHjSUqA+szkLdwSNxKEgLnbGffO1rUcbdNmmN8oZqCwS+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=nKA6grd9TSUxXHygtYoERb3nj6kHD+OMdXE+Y4uPQgc=; b=DIicVlHFC27XiWCEkFafx/BKqBRbPOShV8HYL7NbpWPAIKP449Z3fC+etw11nfjnERTiIG9Zh3G8nVJniRBZuYutpZmp8WoxqqAW6mldrHdQVErOsx14yHME7UzHN+83KGgfkPuFxa6DHvcp+tRhgFPgMrKht/nerDz5/MqPWcpYCEdgZHMoS4MEYqlbKj53c6kw9MHX0hNCG4JW1rfkFiKlcW0q+qPQWuHrHJ0OU6E+pr0QMRl/LKSrtrLqsl9GwPOrPUspMaAXWolxEJBllC+JPBvcMENosogKULRhPI4iwwcIgB3cU/uOs0opRxsgLIrJrIeHaoSjdncdelOD0w== 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=nKA6grd9TSUxXHygtYoERb3nj6kHD+OMdXE+Y4uPQgc=; b=k68wHbRc+Vu4EHVYgzO3elisQVgh/LVxCWA1qvbySpydvXeYm/jafS5r6BBe6djXFWX/QpHnfM7oHmHTL7VF3HmmHzyRJkdyQ6SoIiK8H2CmFTwKNIUlVuG2cHYP9YPa22nkCvQoTAnT5oijxWgarFO7e131eCqcLedXiTfrRns= 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, Jens Axboe , Keith Busch , "Martin K. Petersen" , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Cc: Roger Pau Monne , Christoph Hellwig , Sagi Grimberg Subject: [PATCH] nvme-pci: fix parameter order in nvme_free_sgls() call Date: Tue, 27 Jan 2026 20:59:06 +0100 Message-ID: <20260127195907.34563-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: MR1P264CA0201.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:57::15) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|BY5PR03MB5201:EE_ X-MS-Office365-Filtering-Correlation-Id: 6d149d9d-85dc-48ac-8740-08de5dde8a99 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?SGxaZmRrU1dCRktLNkYxMUpJaWUrNXZyWDVFSWUxc2hZSTdDSENwWEtXSXha?= =?utf-8?B?RW16WWN3OGk1RXhXSUZydWtnYTlrNUNlakcyUWNybElPclY4WUpuc0VoeFI2?= =?utf-8?B?RUJuNStZeVJPcGlkSCtPS2htTktYQnd0d0s3OWNTUjFRZjdsYTV0cDBBOEZz?= =?utf-8?B?VWxzblJFZ2ZxNFFsbTU4dWgrYjFma2ZOaFJYT0czUEN0bGFKRXR0a0Z3dHgx?= =?utf-8?B?MlJRODJ1VFhwakthTWpsODc1RytjWXlwWElHM0JZZEhLVlo0SUdVUXJFbUNS?= =?utf-8?B?MmNweVc0Rkg5ejNJMTFiem5QK2ppblUrbmVLYlBlKyt6ZzdXNDF3ZHl0NzZV?= =?utf-8?B?V2dZSnpVTTJ1TU9FWXUzVHhicDRFczcwc2NzNjdLM3J4ZzJzNFMzMHlRL1NK?= =?utf-8?B?WnJiSE1Qb0dKRi9ZbUp1TDVadHFGTEIzbUM1NGN0MzJpb1F3SWtzWWh0b1BV?= =?utf-8?B?VUZRbExrcmpva0prNVM3UWNEakdGZlZUOVc1RmZvbDNPeG82MnFRbk50bk96?= =?utf-8?B?ZDU1QW0vdXZLODRRTS9KK2syQ3I5YUNGdzh3bHJLNG42bXkwY3BvQVB0b1VT?= =?utf-8?B?Tk5taVROei9FY2o3NEVQUGQrVk1zOHZUbDg3UUk2dm5tbDNWeXhBVzRoZ3g4?= =?utf-8?B?djEvL2Q5YUdFQU1YSVc3MU85TXdLWnplSjdDTWxxQ2o4ZkI0Ymw0RDV6QlVj?= =?utf-8?B?aXEvZi84WWYxdHZKWmNlbmNvcUJkUlBqRHlBNkVVamEyZWtRSzdvUEt1WFMz?= =?utf-8?B?STVTRmQwMGZNeEpHa2JNamQxYVN4OHAzTC94SXAxQmFvU09za0FrMjNNc25S?= =?utf-8?B?dmswTHVKWC9NVTdNREgvbnpMUjZTMG1GdEUyeDFOSm5OcDl4QjMvUmlsWHVG?= =?utf-8?B?R1NaUHMyWEpEODJ3NnZOVHllb1JWb2xRVEV6L1hnNUJqQkVXTFYvNGpIclVH?= =?utf-8?B?eVRtOHJ1VWR3ZEZrTU9GU1F3RzdkLzI3dHRicEc1ZThLUWs0UUZpa3FacExS?= =?utf-8?B?OWFxUXNiUmloQ09FdDZzSkNxM1pLZTJ3TEVnWnp6M3Jhb3B1a1FnRXBhR3VW?= =?utf-8?B?L3I5ZG8rWElyZVRYaUU4UHZhRklPdUg0dWhNYWFkVEkxS29EdEpzenIzeVNX?= =?utf-8?B?TDBDaDl2NDB5OXczcHJlWnpnWHhRSUp2Y1hFU0NpamVNZ3cxbDhxRTBLSDh2?= =?utf-8?B?ZzFkL1hOYUp0WS9pMy9vUStZQll3OXlQdXBsN3JWUjlES1FqQkpZRTY2NGFs?= =?utf-8?B?Vmo3am9DYzMwc2JtUUVxYXNZZy9ydEZneEVjQ3BEU05HRk5BSUpyMVJxWVNM?= =?utf-8?B?WGExQklUdEdnb09iaVVuTWZERWVLRXNvTklsNlFwaGhQa0tpaEd3bjdKcm9a?= =?utf-8?B?bDJ3R21BS3RiN2Nwd1ZIYjV1SzNyRDNuNGxhUjRQNmQ2RVBIcHl6R1VLQk9j?= =?utf-8?B?c0VoaXVXUGdqZHZMQ3JUa0NqRHR5bjNzWXBQa3NvTlc1OHpWekg5SmdNcU1C?= =?utf-8?B?bVJYa1dmVFRDQkt5ckwwY3YvV1ZRYnFmaUk3V0pHMzZKd2xNL0lZUFBRSG5h?= =?utf-8?B?eFp5Y0J5d0dFWHNiZFpXVFFsWHVaZlYzd0U5M2djWXkvMDhNYzR5VEtYOXFm?= =?utf-8?B?OWZkc1JFOWdvcjVFK0thSk1ScGZlUkNXNkc4N3J3Vm4velArWS9qeDhGbWtG?= =?utf-8?B?TzkvVTZaMEVzTzlmczlvU0pudXZMaytyRFJQQlpqQmhzQzlRczRnOEd5MmZU?= =?utf-8?B?NzBCUU1GUUFKQkRqYnVtNis1dEh3UldUMG1WYkxGb3hEY2wzT3VjNkU3TUxq?= =?utf-8?B?ejZJVmt3UGRldTFIL3hBRlFEeEZCbHU3ajdmeFdwS1RiZ3hIZloxalpBOGVM?= =?utf-8?B?ZTFzeEJQMGEyUlRZNUkxZG9CUjFRVFB3SmtFSUhjQzVSSnJZQXVYRHB2SCtR?= =?utf-8?B?UUVzZTAvSDYxSktDckI1Nld1MGdSeDRiTDhCajFrSUZKNjEwQW9IZTJteWxx?= =?utf-8?B?aDF4L29jZTJKWGwxRmxObHg1RW9JcS9nRmg3Zm1SYjkyM1FmUjhra1NkaStU?= =?utf-8?B?ak1UVXY4UldwTlVqak42R3pTaE43VjRXUGVJZithVktqQktmMk53UWlVcFNm?= =?utf-8?Q?ujF4=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dGdsWVczZDUwM1Jqa0ZWTHBPUmZXUEYybm5sRmdlNkp2QzFJQmhhSFZ2VVFi?= =?utf-8?B?a0FwYkU5UlB4Y1hCaGVDeHZmanRxNVVMMmxzNFkwdndwNks0YnNzRGVUb0d5?= =?utf-8?B?Mlh5dTRLNkxzd3Z2U3h1cCtIbDI3NVVmVEYxcXg3U281cU1BYlZlRGtuWENz?= =?utf-8?B?N2QxdnFrMnd1SjNCenJQS0RFTFZmNU1QOUJnV0pyOENHMU5oREhyb0NBTUVs?= =?utf-8?B?ZGd6RlliNlpvbW9jKzZsMmppQVVLRW5tMlFqa2d5TmRmcGN3bGFJcGNKS0d0?= =?utf-8?B?Y2k3alVRcHl2bG5Oa0tQckx3OE05MVZTdHV3VXNPV0NzYXZBK2ZvdWwwN0Fu?= =?utf-8?B?WkVjbDI5R3FxWVNmUnpkV3EveFRBUlhSMTBKWks3MGZML0Rxc3laZHgxMU1W?= =?utf-8?B?SXdiMHJUMDFtZHhDOEpvZXRNWksrMVQ4VnBtME1TR1RSS2xGZ1dkaHVtWlls?= =?utf-8?B?LzV1SE9RYzBWZTArejNNbEdYeGEzdmg5Vll4aHhvUEcwdUtvdU80UGh2M2pt?= =?utf-8?B?dXhUMWtvb0tDSjY0S3FIV1ZkZkphdDNuY0s2b3lmdXRRWnBzSm5aRUp5czNO?= =?utf-8?B?QU5PeDg0RTJnVDlLRzJSZ0p6QUhOTm4xNHVYN0lpRm1VV25CSjNXc0JQNzVU?= =?utf-8?B?SkxwYUp2aUhmZVJvVHJOdUhwYlgzV0ViRG56S1IzY0ZpaG05NXRvcmJwSTlh?= =?utf-8?B?N24yUkRrTitRM1FRUC9GejdSeEFtd3lwU2JSbERwNldId2c2cld0NDNNbklJ?= =?utf-8?B?UDVWdHNYTVRSS3pBWDZsSXM0bkRIZWhNZFllTWVUUG1PT29YaHgvaTllZUlr?= =?utf-8?B?a3NHVGovV2x1U243eUs2YzFEVUVlemVhUWZ1NlppUWdTY1FtZ1dPR3lqWlFz?= =?utf-8?B?L0kwNDV1VzdFanVwUTBNUndGY1VOby9ZWFhFenVPL1VjUVJzMFN0a29qVTBW?= =?utf-8?B?MFZBRHl2U1Q1cUtCNnV0cm9keDAzN0kyekp5WkR2SnlKTkowZzBHOUlIbTBX?= =?utf-8?B?MitONFB2a09aZTNoQ082eE9EcFNvL2lMM1dOMFlFN3FxNGhwV1QrSXl2aDJZ?= =?utf-8?B?QTN1NUlyekx6Z29hcmozZE9BV1piM1l2azUxRDFWWm1Ray9ZQXA4V24yQ1My?= =?utf-8?B?RklOV3ZOd2VOVDdZUWZ4VlpVaXVZWGF2NWNGb1BuM3kvcUQ0YUVBRjhGaStx?= =?utf-8?B?Y3dzVk40N0JkMjduL0QyKy9QeEliUUp5ZjJKMkNUVWNhTXZRUnJ5dzZ6Umlh?= =?utf-8?B?TDh5cm5BZzdlRmt6dTJKTW1STFlleGFQQ1k4azBzamFpMnBHZ1ZyTFlUNmFV?= =?utf-8?B?MWFkUTNiSzliTUQ2NHBWZmxuTmVDUW01dWh2Q1FRUjJpZDBuS0IyaENDb212?= =?utf-8?B?YmxxNlB3RkVLU3FKU0tkZ2VXSzV4RGdBQ2hKbllKSzRscFJpRzI3SnJjOUZZ?= =?utf-8?B?bnh5WWdBbCtpVklkcU9hVWdzMUZyQjNIRnkxdURRR3FISStXcy9OMTd3cHFn?= =?utf-8?B?bWZpL2hVK3U0Vms0UUR6aHQ4V2drQkhhcFlQWGplU0NhdlVOU2dLYllITDJk?= =?utf-8?B?U1Z3dWllZndnT0IyYmx6MVd4Lzl1RkxkK3c5YXl2VGcwTVV6OHhYYkNsa1Nh?= =?utf-8?B?VERkQVljZVllZmk2NERteUtFajVFcXpoZmNYbk1yUVJaVlplelBDR2M4b3Mx?= =?utf-8?B?blpkUmFLbGViSGpYcmpSeXlPb0hLSWt2RzhqRHVNR0d4SDZmbTNsdTFaV2la?= =?utf-8?B?dGk0cHJrU1lHNlNhSWs5N2ZCS3A1clIxVmpjTFlPMU4xR1JyUU5jVTJNRnoz?= =?utf-8?B?S3VOWndCa3JKS09GN3NpcmxxbnJJa3RteElFc0xsN2NLZEs0UlJoYkxPZGhm?= =?utf-8?B?emhabG04TVFPUWFHbW5HOFlzUFV2d2x2bFg4Rmh0bGhTdy8vRmdCV3VGanM0?= =?utf-8?B?aEI0dUtYR0IzajY0NkxYbHF4R1piZ1RzMUJ6RndhZ0E4OUVmbXZpbFBtU0JJ?= =?utf-8?B?eTB3RjlXMzM1MkdtSHVXTEZUVWxDWjBZdE41azNhZWovcFJZd0hCdk9BU2J4?= =?utf-8?B?S2N5cmttcnZOVGxUeXpaTlQ5elp5N1JKSkZ4WXR1dURHdTVYdjJkQ1Y4UnJt?= =?utf-8?B?dWpxOFNCSjZSK2lEL1djU1ZDWVVGOVEyMDNpb3IxckZyMm1BNjhtODhPQ2I4?= =?utf-8?B?bml5c3JJOTdJNytzNURQZXFQZmRFMkNFcmFGQTROcUhBcXFBU2p3OThOZ1l1?= =?utf-8?B?cjhYMlk4R1EwYVNPWm80VjZjc0dsOXArbUhVWm80RzBZUkl5QlY0dVhPMFBK?= =?utf-8?B?TjhMazlhbnNUUDUxUUdRN2xGUVhOcTFERGU1M29DQ2RBaDJCRnNLQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6d149d9d-85dc-48ac-8740-08de5dde8a99 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2026 19:59:12.8172 (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: DU7GSRHbA9f2Zh8k407/Dl1oo35XLP3FyiuO1r+gXwZ+3u08hRWvsIJft+fXieq7EVHa47bA6nMKFw7oLIv3Jw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB5201 The call to nvme_free_sgls() in nvme_unmap_data() has the sg_list and sge parameters swapped. This wasn't noticed by the compiler because both share the same type. On a Xen PV hardware domain, and possibly any other architectures that takes that path, this leads to corruption of the NVMe contents. Fixes: f0887e2a52d4 ("nvme-pci: create common sgl unmapping helper") Signed-off-by: Roger Pau Monné --- If possible it would be good for this to go in 6.19.0-rc8, as corruption of the root device as part of a kernel update is unexpected. Sadly 6.18 already contained this issue, and no-one noticed, so its impact is limited? --- drivers/nvme/host/pci.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index 0e4caeab739c..c8c5ed3eeac7 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -806,8 +806,8 @@ static void nvme_unmap_data(struct request *req) if (!blk_rq_dma_unmap(req, dma_dev, &iod->dma_state, iod->total_len, map)) { if (nvme_pci_cmd_use_sgl(&iod->cmd)) - nvme_free_sgls(req, iod->descriptors[0], - &iod->cmd.common.dptr.sgl, attrs); + nvme_free_sgls(req, &iod->cmd.common.dptr.sgl, + iod->descriptors[0], attrs); else nvme_free_prps(req, attrs); } -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 28 07:05:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 07:05:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215211.1525432 (Exim 4.92) (envelope-from ) id 1vkzbw-0007K7-Jf; Wed, 28 Jan 2026 07:05:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215211.1525432; Wed, 28 Jan 2026 07: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 1vkzbw-0007Jz-E2; Wed, 28 Jan 2026 07:05:08 +0000 Received: by outflank-mailman (input) for mailman id 1215211; Wed, 28 Jan 2026 07:05:06 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vkzbu-0007Jt-AF for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 07:05:06 +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 a76b66b9-fc17-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 08:04:57 +0100 (CET) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-42fbc305914so5531231f8f.0 for ; Tue, 27 Jan 2026 23:04:57 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e131cefdsm4398152f8f.23.2026.01.27.23.04.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 23:04:56 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a76b66b9-fc17-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769583897; x=1770188697; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=DCOA0pcXuTqhvPYRJURwjEtICvZ3j2AamSimEK0mdr4=; b=Sv7t3ttwwYv6gdI5Czhf56RCR1akzGOKYnQRghuXHO/Y9TUG2joA7LevJNpm1FpVgT BCAB61rmbtxLxJDF5DStA6cU0XtUVeq4XAtPBgl9qEwmDdcdy1Cp03epK+Dxnb2Dzjjs GAtiIboEC3di7a2W+SRF6dxVLrgRLTfS0OAqA5x52rbV1nLuxjZaxbULNlQhbGKybbQZ EavTUsLiiE1M6qrT+2RIskUv9GKseHM6sP1hIAqABNT18uM6vwYF2zDiRkcndal+482H p6ZaD9YzeG9TzTFSFs6uWwQuGKE5ciqyrK3zGDMamgURa6XJ01AI8hJcfMMehxBrRwaR Rzmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769583897; x=1770188697; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=DCOA0pcXuTqhvPYRJURwjEtICvZ3j2AamSimEK0mdr4=; b=SOzR108TpACuKwPOEnDOaCXx+ZhxKYjQ2w/9M3tUavf7m3e7Ljl/PI/iUixC8e0967 sr/n+6zn0WhG3DPg1D3tOJNkFgfDH1w4ZqmTv55QSdJ+DeXVM49h223zhzuz99FLYBEU R4nLDWhELBO+cd4VcftXr4EiZLJ10Oqp5uPGJTBP5eRUTujvDetoaTUCW+KDdWU/ZH/F XjD1jZ0E+tAWv80pVt6In4iEeZWZDOvJr3mP+1MWTdckxgX0/WHUKHxddevk9XvgxfzR iQceTSGd5J57HuwkhVPg15VQry1fPWe6mMMR4crA+qzZ+lumCrfqwkVAG18N6qKYzM1n 0bsg== X-Forwarded-Encrypted: i=1; AJvYcCWEP7g96F/Pv17yRpepUbWQJilRdKXLqyZtzHMAQRsMHwqXvhbtfFePsb+jTqeYfEHC/fV9rdudyj0=@lists.xenproject.org X-Gm-Message-State: AOJu0YxQD7S0py3d5yDGlnZ1JaGu5+wKbhqRsosITLpwvKoRCx9XDLjX 0tfgHFaMFKvmUNlNpAuPwbEUuMwKuJsdjSp+1KvEwDtC7+2nf965kRt+NqDNrti/dA== X-Gm-Gg: AZuq6aIC4SEd3d9PSg/SM0R9xe21WIgjZKJrAhFZTEkPCyzAVQbw9J393CPg+uGWrmt OsEexI85mut6E6FCHR1Tbcv7FSET8EebwG4F9xt7E2owjcNfaggFesBq0CmQNjt/u/lTVdR/xus +BnI+b4+7k+FZ2IjIsD5iFo/dhVWvvN2WCrThfi9BcvyNfgO1E6JmzK8bfZuX9LJU8QiLj+0vqM vF0i1XIajz5nDb4SjYhw7XjuuHJ2vNbqhSDrgyiamD3qLnEwsH4ull190IncsXCSNTORs/OhtSF SyPKZKHJ3jnOTrVYLs3XALNi+iE2t6SKdATsqGbsMSh90dWashp3Lbg5JrmuStcE77ACOvWXmZg GTPIEFz4tNHVhuo4AGgrCagQ1Wa+jO7oYyhDpMQEZHD0TRpJk3/VT6A2r8gm89FNIQfReajdmp5 7WQr9cUdzNWf4R4oz+xDqe9ugcnzzsIhu6baY/++gBnj6lqkMz9pYgkTxhHkBywio2JUvY9/Czr H0= X-Received: by 2002:a05:6000:2386:b0:435:a52e:7758 with SMTP id ffacd0b85a97d-435dd1d8c12mr5989126f8f.57.1769583896754; Tue, 27 Jan 2026 23:04:56 -0800 (PST) Message-ID: Date: Wed, 28 Jan 2026 08:04:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] CODING_STYLE: Establish a policy with regards to copyright notices To: Alejandro Vallejo Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260127182403.141459-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: <20260127182403.141459-1-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 27.01.2026 19:24, Alejandro Vallejo wrote: > This patch modifies CODING_STYLE to severely discourage use of copyright > notices when their presence is not legally mandatory. > > Copyright notices are redundant on commit, misleading from the time the file > receives contributions from anyone not represented by such notice, and actively > harmful for attribution by the time the original code is long gone. They are > plain wrong when added on code motion.... the list goes on. > > All attribution worth keeping is version-controlled through Signed-off-by, > Co-authored and the like, DCO and the cumulative contents of git history. > License banners have already been superseded by the contents of licenses/ and > SPDX tags. > > Other FOSS projects have already moved away from explicit copyright notices > where possible, and severely discourage their use when not. > > Apache and LLVM take active issue with copyrighted contributions and Chromium > takes issues with copyrighted contributions not attributed to the project. Some > Linux subsystem maintainers already frown upon copyright notices too, even if > it hasn't reached the point of being a mandated requirement yet. > > Signed-off-by: Alejandro Vallejo > --- > The actual changes are almost verbatim from the LLVM guideline, but it's not > exact. Wording can be adjusted as needed. I care about the core of the proposal. > Saying "please, drop the notice" on contributions where it's clearly not a > legal requirement, or have the contributor state that it is a legal requirement > and why. This "is a legal requirement" ... > --- a/CODING_STYLE > +++ b/CODING_STYLE > @@ -24,6 +24,24 @@ license, e.g.: > > See LICENSES/ for a list of licenses and SPDX tags currently used. > > +Copyright notices > +----------------- > + > +Copyright for the code in the Xen Project is held by the respective > +contributors. Because you (or your company) retain ownership of the code you > +contribute, you know it may only be used under the terms of the open source > +license you contributed it under: the license for your contributions cannot be > +changed in the future without your approval. > + > +The Xen Project does not accept contributions that include in-source copyright > +notices except in the following cases: > + * where a committed file already contains it. > + * where a committed file is renamed. > + * where such notices are on files from an external project being imported. ... may want (need?) reflecting as another bullet point here. The wording of the first bullet point also can be taken to mean that adding to such pre-existing notices is acceptable. This may not be the intention? Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 28 08:10:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 08:10:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215229.1525441 (Exim 4.92) (envelope-from ) id 1vl0dM-0007l4-DE; Wed, 28 Jan 2026 08:10:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215229.1525441; Wed, 28 Jan 2026 08: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 1vl0dM-0007kx-AD; Wed, 28 Jan 2026 08:10:40 +0000 Received: by outflank-mailman (input) for mailman id 1215229; Wed, 28 Jan 2026 08: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 1vl0dK-0007kp-QM for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 08:10:39 +0000 Received: from CH4PR04CU002.outbound.protection.outlook.com (mail-northcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c105::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d34f0428-fc20-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 09:10:37 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DM4PR03MB6095.namprd03.prod.outlook.com (2603:10b6:5:396::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Wed, 28 Jan 2026 08:10:33 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.006; Wed, 28 Jan 2026 08:10: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: d34f0428-fc20-11f0-b160-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tWbUk1IRZVl8VMdmg5e1l8bMIRq1tJlMnYHabOT127b1qtkthcqSd9COpXlTFmuyXBpS1iPjJ7FDGdIam3TCkAJNnYb3C/C59HFXIZ1TK+idU8zGhBnY+PiPIz7WyQz7PKxh+ZneBBij+dtRI/XpQJVJxI6otOR8+cFWWapqXSFTAy1hNVFIdSoRJb9pXjRWDSh1SIsiZJ68jxgdNbcqdKSGo4OdSInC05pKYL7y76ZqCwPkMGkwvkOsJiZWyNqylz4PRGt09d6JDzG+j9yFc7CdqjPTLd+iZB5gClDTl+NyGYzm7I+Nv1igpxQmQbTRSYBct9ZCAe/OzlOecFaAiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PyGjkinb1hyYGCkuldyZbiBsPLybp4MPqlOF3Z9+SZo=; b=XpaG7CGTkL4ZUJqN3/Fp2NKqXLGI3pYdBfKDUiCli0TFa1WtqN7eQ02y1wc3qz/o67oaWS7KU2oe+rBINv0FbweeeruhRyppFXmfn2614OdbHK3Kbimg6z2OPhqfftGCX/e83Idiltk2ON/zO4dP35ISYD6aJt8GXz41OGpOSqKlhIrVqpsDzD/Gf0k5PEOxbDpmGCAuyx92h9X4q3tZGF+uNF9BTxVSNDQCBQnaDnBAA99q4jCrwOwgCHxZR/lo9AWBVMo5t89jHoY7Ypp1H5Sa5/z47a1ncQmvfP+vlvp+Ghp9aknGhpV5J0ZHiorEh1cSKH9MADJpR2LK97au6Q== 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=PyGjkinb1hyYGCkuldyZbiBsPLybp4MPqlOF3Z9+SZo=; b=MYSuDICrFs3kR7kyeB++zOeqqFKc0+HXFTjAw+thq3pAjcNeXgY/DPdyqbPFjODGT2g+kslDf2tJ+E7JBK80kwFMLP17/ObF47HEswVZBOCC4SvK1qUVDe9O3QYAt1RNfVGwoNFTG8qRjmRsr8QWnbRXPQSAiwsEmk/enRwOCqU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 28 Jan 2026 09:10:29 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Alejandro Vallejo Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: Re: [RFC PATCH] CODING_STYLE: Establish a policy with regards to copyright notices Message-ID: References: <20260127182403.141459-1-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260127182403.141459-1-alejandro.garciavallejo@amd.com> X-ClientProxiedBy: MR1P264CA0141.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:51::15) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DM4PR03MB6095:EE_ X-MS-Office365-Filtering-Correlation-Id: a005c640-fd09-4db5-bcc1-08de5e44b5b3 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?OTdEV0JtdzBycGhDdStkMERURnorcWl5R0h5Zng0U2RRU3FENVRFWDlRdEph?= =?utf-8?B?QnpGM3F6VEduZmtEUzFHS3ZOT2g4VmJOTVlzR2UvUXJtYitXL05HZEs4SS9t?= =?utf-8?B?cGtIdm5xVUkvd05KeWlPYURmVE56YnFrZWhNaFdtUVBZdldzQUhvWjY3U1Jp?= =?utf-8?B?Vjk0bjFjQ0JFQkF5SU40a1JLMWs2d2kyc0dyWEdjOFFoeCthRFhSdDlPMzA1?= =?utf-8?B?ekhxaWFaYkhlSC9Bd2Jqc2tjREQ5VWFEVUFhcHJmVFZjTFl5MldaeWhlYmF6?= =?utf-8?B?akF5QjM1d0FrbU80V2U4TnpYb0JIZmloLzJBVk5RdXk2d3pXWVFNVWdpYS8r?= =?utf-8?B?NG5ma3hmREE4amVHcHhJOHhYWVhCVUNtQVY5L0VyelFTQUN2VXBKSWRxWWFo?= =?utf-8?B?bkpaRVV4RHJiQlpqcUQ2YjlWSEEyYmhZVGlMVm8za0I2eWlyNGlQbnpqdjNS?= =?utf-8?B?bDBMRU96U2EyUzBacHJpU1hBWkRiV2JhL0RjdzA3UVFyNkNSeWN1RW9QM01M?= =?utf-8?B?ak1pK2tmMUlON3BjVkFMWnRnWWxXWjNiOHk2Y2t5VDh2SkpNZFRLY3huWXJo?= =?utf-8?B?bThOVXU3ZlpHTUorUEJCWnVGbHRQN1B3V0RPbkM1a0hNVjNDY1NDcVBYK2JH?= =?utf-8?B?YXViaDdwcmh6Y3NCdDREVElhUUxXWUgweGluR3liaGR6OXZoZk5kVlhqc1lI?= =?utf-8?B?dWwwZGM0d1VZZHQvY3lNVjc1dS9ZdUZ5UGVZdkwxcW5GTWszc1VOUFc2VzRa?= =?utf-8?B?RUhVdHpMVXdiRmVDNUlKSzdDNlNWZlhOandXcGVrYTAvZ3NhZEdpR1c4ZFNo?= =?utf-8?B?KzFsdWk5b29SbWpleFM2Zzc5bzRtWGRPSzZyMkEzaFJidCszaHpCdTVOcUtI?= =?utf-8?B?dFo5K2lUaEFvUlAwekJKRm9uQnhTbjdtTWNzalQyOGJVeE12SFlRRFNzWmdQ?= =?utf-8?B?RVg2eGFUU1VhalQxdzZMejRjUTR6Vk8vcWxmNHF1UlZNczNwa2svYjQvUW9J?= =?utf-8?B?RWRVNHBlaHU1ZXhuaEFsU1dvdU04TmlnZTlwbFJUMEErQ0RjMDVxOHpNcW5j?= =?utf-8?B?cDNNSThLNk5KdkV4bXUwb1RWdS8wSTk2TndVbjlaWC85T1JxQXdOWXBKSVcx?= =?utf-8?B?THpUVFI5VXgvM1ZWV0d2K0xTNDU5VDNxZzR2YXVSSGdXWjVVWEtDekVJL3hp?= =?utf-8?B?WG16alhUNVJmaUVkUnJEY09IQ1h5VmNVaVRrQXg1Qnh3emk1b0ErVFB3NTFx?= =?utf-8?B?MGR0djAwUmlFaDF2YXB2OVFRV29tTDVvUzgxRm9BcVh3Y2ZtbGUrR0xYMzls?= =?utf-8?B?bkJoQVpXekhRQ2xDaTNwSzgya0FsSVEvVmF5V2QvM1o3ZWxmQ0tyL1NMRGF6?= =?utf-8?B?RTFQdGxnTXdqY2lILzJXbWwwRGdCZHdCKyt3bG5Qa3puT3VCR0lKRTQ4SUM5?= =?utf-8?B?NzJNZXpuSFA5aEFHdVA1aG1UTEhIRzRMNkd6dk9KQzc3RUgvdCtKWTB5SzRQ?= =?utf-8?B?Nzg4K3RGenVMOFNRTkNibkFHbHhkZTlIUWk2SVVleGR0d1F2dUdSVDRjdE5w?= =?utf-8?B?RG1SQXVGNUREQ3dPU24zYmlqR0ZIbWppNWFsN1JVcytKSkRTOWl6QTBYMEM1?= =?utf-8?B?YkY3WXZOUTZ0K3VnQmQxZ2xFQnA1aHdsL1NWS1M0LytKMTFDQTJIU2ZLSjFP?= =?utf-8?B?MS8yZDR1alpsZXZrN3hKeWVhdlZXYUUvSStnTUhKanA2VnlMZEg4QjdJRHBp?= =?utf-8?B?T1YxOWdhVDlVRUV2NCtSYTVFRHF4MEpPU0hjNDcyK2Y1WUZvMEhEWERTSUZo?= =?utf-8?B?dUlpSmdhOUZIa3RaYW9uR2ozSHdCcnZGWXA3ZGwyMU1INUZlMFhOTUM4QSth?= =?utf-8?B?TEh2MHc5a1BUVGxzUE9MK1R4OUdUYjFuZkpEWU5yZXFzRzFyYk5BaUVkK0Q2?= =?utf-8?B?dGtTb2owY1dGcytLMEcza2pqQVlYOGZleU9nQUJFbWdkQzJoSVJ2WVNNTmIv?= =?utf-8?B?RExaWnlwK2xDTzVNSHFVT2ptbU95a3UycGpGZWVWNkxoK1NpR3VxVEVZR1Qv?= =?utf-8?Q?9hi6QO?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UWc1N05veCtpQmhmSUFUTEYvOTRiQ0grc3oyNUlyMTMwdVJnVXh5Z0Y2TEJ1?= =?utf-8?B?bHRhUGRMT2t4bWc5alFYei9PbDk0cmlucU5LZExDZmQ5KzdXMmtaSE1kSnV1?= =?utf-8?B?VGZmZUNBK0lPd3BBUWIyQnpNWkQ5WEhUYlBGYVdrWmFFTFdIZndHVkJQNnRh?= =?utf-8?B?aXMrQUVtZUJKRTlXZG56eG9QNFliYnVNdVVBbzlLMzlJdlZTNXNjZWk0dElW?= =?utf-8?B?VU52VlRNVGIwRGxlUTA1QjJSK3hESmkwWW1NZWxtQ2ZkTWI4eDgwRkM1SktG?= =?utf-8?B?RTFDaW1RZkhqMndjTmYzOVBlaHF6OHBkSTMwb1BwdjU4MWs4ZTFJNmg0YVNE?= =?utf-8?B?U1h5UkUwem0zYXZTdndIZTNVMVY2OTJsTzJCNjVoOExLdEM3ZDJWRjBzOUFI?= =?utf-8?B?c1dZZHpObEJNRTVaQW4yY1hjcUpNblVPaExQTFc5aVVOdXRmciswNGtHT21r?= =?utf-8?B?Lzdab0xSdlNTaXJaT0pvNUFMclBXSHBmTWthR0t2bEJWTVU5N3N2ZW5CRG9J?= =?utf-8?B?akZ5a2N2VHYvN09hbnB3OTZ2dzhsd3pQRzdjTU1ZSGljQ2tXME40a00zV2pp?= =?utf-8?B?bU51V2pXMDFHYkpaN3c2YlpITzdLYmJHYzNOdVdQblQwRjVFWmhqR0NnOFhC?= =?utf-8?B?ejkrenlrN0pXb0krUjBCdmV4UmoxWGhmMHJ5ODlTZkhlUXV2WG1lQ1BEZlB0?= =?utf-8?B?NjVxVDk4REp2cTE1T0xabWZoVmhHQ3FyRk80QTBWTGw2U0w1V0UyaVBHeTQ3?= =?utf-8?B?ZFhlM1laN0p5NjVkWnBFTjhzSnd5eTZjRm9JU2x4aEpqcml0TjRWTlJ0by94?= =?utf-8?B?OXhiMGlXYVdqeVN3Q21QakNxcTZyRkRHZEF5TXVWRjFTRGwyTlZrcWhGby8w?= =?utf-8?B?NVhqNXd1SUtDbUcwQTJVeEQ4RmpRRXRkQUZUaFppUnpERExVZTJoNktMOTJj?= =?utf-8?B?S3Nkc3BVSHVETVJRWG5TN2hqS0IxMEd1bStJMUJJY0pUb09WMG9HQWR3T001?= =?utf-8?B?Q3ZNenhGdHJ0cGh5YTNOOS9RSldkV21WOTAvdTVuUndITUhTYnRwMVdjdE9k?= =?utf-8?B?SXd2Y2p5c2xMOVlHR3c5V29nTXdVUmcxZzJTOEhGNEtxeFROZ0NpcjFqd3JJ?= =?utf-8?B?K1psL1BLTVhOZFBFZmJxQ1ZoUDE4WHBQRG5yMjFIOXVqbkh0MG5YM0RMQjdQ?= =?utf-8?B?YjhGTjVwMXNGb1JJL1czWWl6eWpFYmNZOG1XOWUxVFRldHBzdk5BNFdSdnBL?= =?utf-8?B?VEtUUC9wWTNtYjZ4ckkyOHV1cTdJUzRYS2tRdDFkTSszdVh6M28yOTgremdD?= =?utf-8?B?T2lwak80ZkNYTlpkV2VJNmlnN1NmWFkybW9KWEFQeDQxb0dneU9nWlFUd1RO?= =?utf-8?B?SnlEekhBVXN5eGkwcDFma0JocnV3cG5LNHB2UGZFZmZkSXRtenF4eWk2czll?= =?utf-8?B?RTdUUmxST0Q1cCtabUg3VWtyMTYwM0xqZHp2R3BSdmZSOTJ6KzgxMTk1Z1h5?= =?utf-8?B?Z0NSdm5lS0ZmUjhLRWNCZFRxK3YxM2EyakFaNzhTdHpoQmNXcG9OeTY1MCtw?= =?utf-8?B?M2k2QWlDcG5PbTB6TTdKdDNlcjNCQnprSmx1YXFwbmpBU0xpb2RTWVJmVG9v?= =?utf-8?B?R1lRREp1VkdUVUprcVlSOGVzNkdSSG13djVBZzNFZnZDMTljZEdaeStEb1RX?= =?utf-8?B?aTRrTXRVRUpuNklFalBWMHB3MzFLTUl2eENLR1FJUWxvL0MxTkZGQnEvYUVW?= =?utf-8?B?QVRpaCs0cjg4c0FJRGlhUUk2VHQ1ckV1aEVrZmxodXAxZ2k1RDk3RnI1ajRh?= =?utf-8?B?M1Z1dFJBVU5tNTRxalBPbDJrTnF5UC9JZW1HdlFBeW9qb0hrOFpnZXowYVEy?= =?utf-8?B?eFROUTZvWjFSRWFmTllnOXJQcXFNMlRyNXpXejFVKzFyQXN0NStlb05HeVl5?= =?utf-8?B?VlJIUElORVNIZTRBY2owUHVVOHBRM20wUVIwa0RGbVBzQURtMm5jRDBLd3o5?= =?utf-8?B?Rk5LSXQyaHU0dzl0ZU5QZWtQQlVXVC82SDllUTFQbDFPaFNzR0FSSmdVaklX?= =?utf-8?B?cWFUdHhyeHJVZHNXOGphQ2RicWxDU3hqWnlGSTZWaUZMYVpNV1N4N2xIMUVh?= =?utf-8?B?NnlXR2JwTnJSUkVpNVNvVTlnM0xLSG10T3JoMUZPTnVwVUs5QWRtMDlBVG93?= =?utf-8?B?c0h1VEZhNWtTTTdiaXBFcXlyZE84UzFiM3pmZkdQTjYzWU5mYnljYm85cEVD?= =?utf-8?B?VUVjSHdIUW5GOE4zdWgvc3RuU216RitXYUU4TXUrUXozQ1gxMHdnRWgrUzgr?= =?utf-8?B?VDJoRGpIaUdwYXUxREQzSWVpeEluL3JHaGdLeGNXTWVuK0pEYjhFdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a005c640-fd09-4db5-bcc1-08de5e44b5b3 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 08:10:33.4988 (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: dvJKuwZjLUtLlQIjyX+7fi1PlJ3MsAIDoSCF1IZsbwCAdHBp04I8hNLbCf8hQ4aGGiCoJbQrEmqBSE2++XokoQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR03MB6095 On Tue, Jan 27, 2026 at 07:24:01PM +0100, Alejandro Vallejo wrote: > This patch modifies CODING_STYLE to severely discourage use of copyright > notices when their presence is not legally mandatory. > > Copyright notices are redundant on commit, misleading from the time the file > receives contributions from anyone not represented by such notice, and actively > harmful for attribution by the time the original code is long gone. They are > plain wrong when added on code motion.... the list goes on. > > All attribution worth keeping is version-controlled through Signed-off-by, > Co-authored and the like, DCO and the cumulative contents of git history. > License banners have already been superseded by the contents of licenses/ and > SPDX tags. > > Other FOSS projects have already moved away from explicit copyright notices > where possible, and severely discourage their use when not. > > Apache and LLVM take active issue with copyrighted contributions and Chromium > takes issues with copyrighted contributions not attributed to the project. Some > Linux subsystem maintainers already frown upon copyright notices too, even if > it hasn't reached the point of being a mandated requirement yet. > > Signed-off-by: Alejandro Vallejo > --- > The actual changes are almost verbatim from the LLVM guideline, but it's not > exact. Wording can be adjusted as needed. I care about the core of the proposal. > Saying "please, drop the notice" on contributions where it's clearly not a > legal requirement, or have the contributor state that it is a legal requirement > and why. For fairness sake for all contributors to the project. > > I'd prefer taking the Apache approach for new contributions, but I want > some discussions to happen first. > > Thoughts? > > Relevant examples: > > - LLVM: They banned copyright notices, unless part of a vendored > components. > - Links: > - https://llvm.org/docs/DeveloperPolicy.html#embedded-copyright-or-contributed-by-statements > - Relevant quote: > The LLVM project does not accept contributions that include > in-source copyright notices except where such notices are > part of a larger external project being added as a vendored > dependency. > > - Apache: They banned optional copyright notices and relegated > mandatory notices to a NOTICES file that also contains an > Apache copyright notice. See links. > - Links: > - https://www.apache.org/legal/src-headers.html > - https://infra.apache.org/licensing-howto.html#mod-notice > - Relevant quote: > If the source file is submitted with a copyright notice included > in it, the copyright owner (or owner's agent) must either: > * remove such notices, or > * move them to the NOTICE file associated with each applicable > project release, or > * provide written permission for the ASF to make such removal > or relocation of the notices. > > - btrfs: They are highly discouraged. > - Links: > - https://lore.kernel.org/20220909101521.GS32411@twin.jikos.cz/ > - https://lwn.net/ml/linux-fsdevel/20221026074145.2be5ca09@gandalf.local.home/ > - https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/index.php/Developer's_FAQ.html#Copyright_notices_in_files.2C_SPDX > - https://lwn.net/Articles/912355/ > - Relevant quote: > Let's say it's OK for substantial amount of code. What if somebody > moves existing code that he did not write to a new file and adds > a copyright notice? We got stuck there, both sides have different > answer. I see it at minimum as unfair to the original code authors > if not completely wrong because it could appear as "stealing" > ownership. > > There's more cases of other projects taking similar stances. > --- > CODING_STYLE | 18 ++++++++++++++++++ > 1 file changed, 18 insertions(+) > > diff --git a/CODING_STYLE b/CODING_STYLE > index aae5a47ac2..97f80245ed 100644 > --- a/CODING_STYLE > +++ b/CODING_STYLE > @@ -24,6 +24,24 @@ license, e.g.: > > See LICENSES/ for a list of licenses and SPDX tags currently used. > > +Copyright notices > +----------------- > + > +Copyright for the code in the Xen Project is held by the respective > +contributors. Because you (or your company) retain ownership of the code you > +contribute, you know it may only be used under the terms of the open source > +license you contributed it under: the license for your contributions cannot be > +changed in the future without your approval. The usage of such direct language here, by using you to refer to the reader / contributor, set a different tone from the rest of the document. Maybe something like: "Copyright for the code in the Xen Project is held by the respective contributors. The author of the code is the owner of it as stated in the DCO. The project cannot retroactively change the copyright of contributions, unless explicitly accepted by all authors of the code." > +The Xen Project does not accept contributions that include in-source copyright > +notices except in the following cases: > + * where a committed file already contains it. IMO we should also prevent expanding the existing list of copyright owners in the headers, and hence don't accept expanding the copyright notice of existing files in any way. I don't think contributors to Xen have been expanding those headers in a long time, but would be good to have it written down. > + * where a committed file is renamed. > + * where such notices are on files from an external project being imported. "where such notices are on files imported from an external project." Seems easier to read to me, but I'm not a native speaker. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 28 08:15:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 08:15:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215242.1525452 (Exim 4.92) (envelope-from ) id 1vl0hb-0008Ng-VP; Wed, 28 Jan 2026 08:15:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215242.1525452; Wed, 28 Jan 2026 08:15:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl0hb-0008NZ-Ri; Wed, 28 Jan 2026 08:15:03 +0000 Received: by outflank-mailman (input) for mailman id 1215242; Wed, 28 Jan 2026 08:15: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 1vl0ha-0008NT-9J for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 08:15:02 +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 6e8c8d28-fc21-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 09:14:56 +0100 (CET) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-432d2c7a8b9so6269877f8f.2 for ; Wed, 28 Jan 2026 00:14:56 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e10ee078sm5173360f8f.16.2026.01.28.00.14.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 00:14:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6e8c8d28-fc21-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769588096; x=1770192896; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=JLPssjh+92Qd8vVx/+o3HM7WxMrt9XMrfIVt8FGZzS0=; b=NW/N49nRf5sWSulsrmWL+DHJAUtfZkgEf2RSc+1eamIPXU76O2iQJYKJxFAmLvkpul jZ4HuTQ2WesDzQDov+k8QduoyIopp0P6ZS4TYs8H/sLNVQvDAq1ZgLmuwuAxRZRmSVEo I6VgOBxGerVApmQUO3FN2cuMFGvVsBb0sMx1ioIgxYl2rj6MyCPhCPKTfV14HKP8kZZx 811DfWX3r3tZ4BexURiVhlIVXpHQ8xWP7OooGvom9q+69T8nC9g9+aoLfdpf6UYZ4hxo KFD3O76+qW8+umMCSdvl1Sj32vCXljDqBdzUDjIrbeVmsSQvyG6LNBvZalJv0DgLrWsc /lmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769588096; x=1770192896; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=JLPssjh+92Qd8vVx/+o3HM7WxMrt9XMrfIVt8FGZzS0=; b=wzruKrf1jueczdv8w2MKaKYyDO4F/Yn4YUDKtQxEVWJRssHGUdQf0TfVtke8iPnHK5 9JOpFtrkQ4TZXJqO29TWCp0+Ej57muWeY6N14cHUgJRwEyd1QAjxhUwZzF7iVfRNAr1Z nRXB8I8vGGlRixAYDxYoJmnZsMsC1tzcXcou5oXhqsAum2WZvHwIhH3VoK2x393SpLmj ISTn8NV2wZs4Pbtm6J3sNIJXCmD7hsFOuCsgFF+bs/+eqFE7+PYjRBgEyd8WTakI+egh cYQY0avFknhmO4B7UEUwcaIVfVETuUGn/cbxI5RQX5e/ADOqobGfsgJ+qRR1+Gob3P+H 7gtg== X-Forwarded-Encrypted: i=1; AJvYcCVbyvPZgSF8IhjyNuYOMi+UFCzTXcR9YPnLMgDjeUkStqc6QoH6ikEhoOqr5gd4e+ffUrhJHJxc8T8=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzqn26AfhTp444XE2baJh/jrtMid/YRs1qU1IilibCGy/YXK+ir 93u6dmnROtNY2ZlAaIcOzbqo52/twgahkBc+BGPgbCHP8D0GE0A5WPEM5BtF31fjLQ== X-Gm-Gg: AZuq6aJeptPlh9CBQYYiK0Xx4xHc8ctguCEFWEtKmskDqpTqdDTO+p0Eh6qXG8hIKmq Vr1tWg9GAWFTCIJ++CVZZ3jVNQhvPYeZwFTeX/u+v018do/YOTRBqQU/sWXBIIlbcH+4kBVnlY6 /Z13yMs9UytqxhPn+LDUULQoNBo9ZME50x4zFmIXCgTeO9MWsJCHDMHhhUDK2N41DN+Tjmv/ui7 a9fdiN09mmX953URRy/o2l3j1oONnOGOxkgD3oEmagZZHtZ2Cw+d15LZNF2F+PjDw5LfR7VnTdb NnkD+nhmjpREKqOqQERF/PfV/J/HCJJlunHvhvZhrBf+eMdEcD/5tRvjvDB3sBNZ6Z/LTbWtwvW zzoAxxvoMunB9ZHA6BVRolWjEyUBaS1/OV2vfnMFfUJtto3Mg3b/0XL6uyFmnAlLTn8ib1zf9kN 1b0bwLHCKCjNivOhaAI4YrclnCiIQkGCxz62Sc1qvFksYtlwMR5aaG2nPBVcBrAtDUtIaJe1rqI vobmHHizjhTSg== X-Received: by 2002:a05:6000:1ac6:b0:435:9223:bfd6 with SMTP id ffacd0b85a97d-435dd06c55emr6160203f8f.25.1769588096277; Wed, 28 Jan 2026 00:14:56 -0800 (PST) Message-ID: <83d79978-b8fc-49a3-9016-df874a507bba@suse.com> Date: Wed, 28 Jan 2026 09:14:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/treewide: More typeof() -> auto conversions To: Andrew Cooper Cc: Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Xen-devel References: <20260127101841.2213758-1-andrew.cooper3@citrix.com> <18aee854-2e08-4a45-9df7-1c622136afde@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 27.01.2026 18:10, Andrew Cooper wrote: > On 27/01/2026 5:01 pm, Jan Beulich wrote: >> On 27.01.2026 11:18, Andrew Cooper wrote: >>> All of these are simple cases of using typeof() to avoid multiple parameter >>> evaluation. Using auto avoids multiple textural expansion also. >>> >>> No functional change. >>> >>> Signed-off-by: Andrew Cooper >> Acked-by: Jan Beulich > > Thanks. > > While I've got people's attentions, there's a secondary pattern we use > that's a bit less clear to convert. > >     typeof(a) *_ptr_a = &a; > > With auto, you're required to write this as: > >     auto _ptr_a = &a; > > rather than the more-nomal-looking: > >     auto *_ptr_a = &a; > > > So far I've only found two examples, and I'm debating leaving them as > are seeing as auto (in this form) is still a new concept to most. > > Thoughts? If already we're moving to the use of auto, I think such want converting as well. "auto" meaning "type of rhs", this necessarily implies absence of pointer-ness in the type. Really, is "auto *" actually a construct which could make sense in some specific situation? This and the rhs type are (seemingly) guaranteed to conflict. Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 28 08:40:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 08:40:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215250.1525461 (Exim 4.92) (envelope-from ) id 1vl162-0003uh-Qs; Wed, 28 Jan 2026 08:40:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215250.1525461; Wed, 28 Jan 2026 08: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 1vl162-0003ua-O7; Wed, 28 Jan 2026 08:40:18 +0000 Received: by outflank-mailman (input) for mailman id 1215250; Wed, 28 Jan 2026 08:40:17 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl161-0003uU-2u for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 08:40:17 +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 f73a1f46-fc24-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 09:40:14 +0100 (CET) Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-432d2c96215so5717979f8f.3 for ; Wed, 28 Jan 2026 00:40:14 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e10ee04csm5425804f8f.12.2026.01.28.00.40.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 00:40:13 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f73a1f46-fc24-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769589614; x=1770194414; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=mRD7W3YhsCrjwP4IUk3SDTMiVghSLWVZeUBIQVLccnc=; b=AE8tE7Zw6OGDtf/VgJMxG0gCp+768ZODvzrujWg0dNhb0jghH0057pIsa/9y8MH0jo Xae72qKEUfgSSXv4v1L13er5lv7RYV3n8VSOoFLD5d5xepTG1rhpuVyDZ2EDSGvwsmuM ACoN4pF1kHOuSdXONhJFQ1Va7f2PKj3r0CtjlSPWHo9V6sXYHjJJM5i4p794A2HAaLYs je/Z7LM/YyqnNJ52aW2/zXS3Ficzhjdn/R/VP90aOhSkpZzQ7NidMnQxkZJZ7LJkvkPg 4VdI9i+5WVHnjGVuQChzHtTazrEmM9U5hCGnj+mMbXQ8BNArtqjfWWGLZkoedJbK1Pio iygQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769589614; x=1770194414; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mRD7W3YhsCrjwP4IUk3SDTMiVghSLWVZeUBIQVLccnc=; b=bZgVPQHYeAl9WWk2zubWqEq3gT2ej8Bt4hyU3RM96ZmRfk5/EGX3xHwJ8KKVghmFtt jQVB0zVwHWUqt/VpeSOH1NTKsFirZ5u0NoSSpLOCGsCZViFfG29EkvpMsvKSKHKUKbT9 TUPZvCKZBfbgvh3HdTF5leCUJ/QShDxGOsF6c2VKFLoH4+3j5JS+dmegVNcmZwETSJ4I 6+D6fR0hovGaKHyKTLB3sy4sYOyxfzqcQTYJZn1VNcaMXdMVkDc57K6Qq0eEK9qI90AH TXBRxL0wa53pMtkfAVRQ+xGqkLXsS7zNmGm0QKZbqNq19OpOX2y/jKJ7QKvTO/3Qx7gj w+0Q== X-Forwarded-Encrypted: i=1; AJvYcCUJipvHNgVC9fA7Sxnv2Qumcvnbi6YH4ATxsneCb/n2eB8gOx4yolbphOICPNXst0/xOR5TG4MQQE8=@lists.xenproject.org X-Gm-Message-State: AOJu0YyfsKdtjNrnubFw9GlL12b+OgUMkymZqBorIXsUl/CWsGgwwUjX DQEs7K7f82whYg5FdzNZAwVaZDk9oaPeBj/1NZG+GePkSZBL9Y8BInq/3oRaom+obg== X-Gm-Gg: AZuq6aLl1Ww9MsD87hYVerlY0rjo1IBO39zLUpwGbjMXEqHFJ/q29TNVYlnZZvH1xWF 1CUqL5J1h0tMnEdzRKltbU/r5x1D3enpg4Pn/jlT6cNiOZ8EZSKyFbYYoaHu2mMkZTswMKilpK6 7CsYh3uu4w06kjtsC/5KrkO2XjKq0vBhaZKPHmXHdXplCBQ4Z5eOhpO6F4JbqLZXDobUQmo2VpY p4s9fJHyb4RXDB9kL94Wmr4mYSZWAMOTWwlMJxTlMgOYrcTRHH+JUtHG63Eh/fswbEPI3UFgO8o ywoaQkF602HvgW9c/PVYdv2jOOruyZffL4ZMQyVpnKWdR/pp0FP+EnnAEejgQ/m/50KEZuB61t3 kuihQRphe67jhCz4Yf5VHaxldSsT7bOxlaP3LpxBMUjsSvlBN9PvNYgL7B3PdWZOypNzAehB/5X nd+YT6Y3PzIY5gafYzm1Q+072xGRJ6XaHV9TvqHRKvB2onSsWvENL2nvNUL2XHXPGAZpsNRbmZA YI= X-Received: by 2002:a05:6000:428a:b0:435:91b6:f53 with SMTP id ffacd0b85a97d-435dd02450fmr5859204f8f.8.1769589614025; Wed, 28 Jan 2026 00:40:14 -0800 (PST) Message-ID: Date: Wed, 28 Jan 2026 09:40:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 01/16] x86/cpu: Fix boot time cache flushing To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Julian Vetter , Teddy Astie , Xen-devel References: <20260126175345.2078371-1-andrew.cooper3@citrix.com> <20260126175345.2078371-2-andrew.cooper3@citrix.com> <15978c88-5ea9-4159-951b-27c9fc004756@suse.com> <3ded84f3-505e-40f1-b7d5-f136663af7cd@citrix.com> <52fe1a23-70bf-4282-a41a-7b153fd1f7c9@suse.com> <1fd00308-f072-44f1-936b-8668f4e9ad05@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: <1fd00308-f072-44f1-936b-8668f4e9ad05@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 27.01.2026 18:53, Andrew Cooper wrote: > On 27/01/2026 11:35 am, Jan Beulich wrote: >> On 27.01.2026 12:08, Andrew Cooper wrote: >>> On 27/01/2026 10:37 am, Jan Beulich wrote: >>>> On 26.01.2026 18:53, Andrew Cooper wrote: >>>>> --- a/xen/arch/x86/cpu/common.c >>>>> +++ b/xen/arch/x86/cpu/common.c >>>>> @@ -319,8 +319,6 @@ void __init early_cpu_init(bool verbose) >>>>> uint64_t val; >>>>> u32 eax, ebx, ecx, edx; >>>>> >>>>> - c->x86_cache_alignment = 32; >>>>> - >>>>> /* Get vendor name */ >>>>> cpuid(0x00000000, &c->cpuid_level, &ebx, &ecx, &edx); >>>>> *(u32 *)&c->x86_vendor_id[0] = ebx; >>>>> @@ -352,6 +350,7 @@ void __init early_cpu_init(bool verbose) >>>>> if (edx & cpufeat_mask(X86_FEATURE_CLFLUSH)) { >>>>> unsigned int size = ((ebx >> 8) & 0xff) * 8; >>>>> >>>>> + c->x86_clflush_size = size; >>>>> c->x86_cache_alignment = size; >>>> With this change, can't the writing of the field in generic_identify() >>>> go away? CPU_DATA_INIT() in particular doesn't invalidate it. >>> No, it can't.  The value needs setting up on every AP, right now at least. >> Are you sure? APs inherit part of the BSP's data (initialize_cpu_data()), >> and reset_cpuinfo() doesn't clear ->x86_clflush_size afaics. > > Every time I look at that, it gets more insane. > > For every CPU, initialize_cpu_data() clobbers boot_cpu_data, *then* > copies the result into cpu_data[] array. > > This cannot possibly be correct.  Why on earth did I ack it? I wonder what you're looking at. My initialize_cpu_data() has struct cpuinfo_x86 c = boot_cpu_data; which means a copy is being made, the address of which is then handed to reset_cpuinfo(). >>>> Tangentially, "cpuid=no-clflush" didn't have any effect on any of this so >>>> far, and also isn't going to have with the changes you make. >>> The line immediately out of context above will applies the clear cap >>> mask, so will cause cpuid=no-clflush to take effect. >> This concerns me. With your change, "cpuid=no-clflush" will lead to an >> unconditional panic() then. > > So will no-cmpxchg8b. Which doesn't make the situation any better. (I think you mean no-cmpxchg16b though?) >> Whereas previously, with cleared_caps[] being >> applied by identify_cpu() only after generic_identify() has already >> evaluated the CLFLUSH bit, there was no effect at all. > > That wasn't no effect.  The effect (upon request of an impossible thing) > would be that part of Xen would have ignored the request and functioned, > but another part of Xen would have propagated that to guests, which will > probably have equally rude things to say. Well, I thought it was clear from context that I meant "no effect for Xen itself". As to guests - as long as they're properly checking CPUID bits and refrain from using insns which CPUID says aren't available, I don't see why they should get upset. When knowing one may run virtualized, the concept of "I know one feature (e.g. LM) implies another (e.g. CLFLUSH)" is flawed. Any combination of features can be surfaced, so long as true dependencies between them are respected. IOW I disagree with "cpuid=no-clflush" requesting an impossible thing. "cpuid=no-lm", otoh, does for a 64-bit target environment. >> I don't think this panic()ing is desirable, but as an absolute minimum this >> (drastic) change in behavior would want calling out in the description. >> >> Further, if the panic() was to stay, there's no point having cpu_has_clflush >> evaluate to anything other than constant true anymore. > > I'm not overly interested in users complaining about a panic() if they > ask for an impossible thing.  Better that than the prior behaviour we had. > > Talking of other impossible things, cpuid=no-$foo does nothing for > FPU/DE/PSE/PGE or MMX which are the features hard wired to 1 already, > and with 0 users in the tree. Indeed, and while there is that "Currently accepted:" section in the doc, I can't help thinking that even for the speculation control aspect that it explicitly names it has already gone stale. Yes, in the past we said we'd mean to not support use of arbitrary forms of this option, yet "Unless otherwise noted, options only have any effect in their negative form, to hide the named feature(s). Ignoring a feature using this mechanism will cause Xen not to use the feature, nor offer them as usable to guests." to me really says otherwise. Even if intended to be thus restricted, it would then feel rather odd that we implement support for an option with hundreds of sub-options, out of which only a handful are supposed to be possibly used. On concrete example where a presently not explicitly permitted form could be useful to people is "no-rdseed" on AMD hardware affected by one of the two known issues (patches sadly still only pending). This viable mitigation would be unsupported by your implied interpretation. Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 28 08:50:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 08:50:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215263.1525471 (Exim 4.92) (envelope-from ) id 1vl1FU-0005FS-Nr; Wed, 28 Jan 2026 08:50:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215263.1525471; Wed, 28 Jan 2026 08:50: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 1vl1FU-0005F4-K1; Wed, 28 Jan 2026 08:50:04 +0000 Received: by outflank-mailman (input) for mailman id 1215263; Wed, 28 Jan 2026 08:50: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 1vl1FT-0004vd-HQ for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 08:50:03 +0000 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 54ed9585-fc26-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 09:50:01 +0100 (CET) Received: by verein.lst.de (Postfix, from userid 2407) id CEA75227A8E; Wed, 28 Jan 2026 09:49:58 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 54ed9585-fc26-11f0-b160-2bf370ae4941 Date: Wed, 28 Jan 2026 09:49:58 +0100 From: Christoph Hellwig To: Roger Pau Monne Cc: xen-devel@lists.xenproject.org, Jens Axboe , Keith Busch , "Martin K. Petersen" , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Christoph Hellwig , Sagi Grimberg Subject: Re: [PATCH] nvme-pci: fix parameter order in nvme_free_sgls() call Message-ID: <20260128084958.GB9373@lst.de> References: <20260127195907.34563-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260127195907.34563-1-roger.pau@citrix.com> User-Agent: Mutt/1.5.17 (2007-11-01) On Tue, Jan 27, 2026 at 08:59:06PM +0100, Roger Pau Monne wrote: > The call to nvme_free_sgls() in nvme_unmap_data() has the sg_list and sge > parameters swapped. This wasn't noticed by the compiler because both share > the same type. On a Xen PV hardware domain, and possibly any other > architectures that takes that path, this leads to corruption of the NVMe > contents. > > Fixes: f0887e2a52d4 ("nvme-pci: create common sgl unmapping helper") > Signed-off-by: Roger Pau Monn > --- > If possible it would be good for this to go in 6.19.0-rc8, as corruption of > the root device as part of a kernel update is unexpected. Sadly 6.18 > already contained this issue, and no-one noticed, so its impact is limited? This only affects non-IOMMU paths with a non-noop dma_unmap_phys. So it is a very common setup, but very severe for those. Because of that we should get into 6.19-rc and -stable ASAP. The fix looks good: Reviewed-by: Christoph Hellwig but maybe we can reword the subject to sound less harmless, e.g.: nvme-pci: DMA unmap the correct regions in nvme_free_sgls ? From xen-devel-bounces@lists.xenproject.org Wed Jan 28 09:00:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 09:00:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215274.1525481 (Exim 4.92) (envelope-from ) id 1vl1P1-0006JH-Iz; Wed, 28 Jan 2026 08:59:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215274.1525481; Wed, 28 Jan 2026 08: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 1vl1P1-0006JA-G8; Wed, 28 Jan 2026 08:59:55 +0000 Received: by outflank-mailman (input) for mailman id 1215274; Wed, 28 Jan 2026 08: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 1vl1Oz-0006J4-KD for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 08:59:54 +0000 Received: from out28-148.mail.aliyun.com (out28-148.mail.aliyun.com [115.124.28.148]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b0469dcb-fc27-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 09:59:45 +0100 (CET) Received: from localhost(mailfrom:houwenlong.hwl@antgroup.com fp:SMTPD_---.gI0YX77_1769590781 cluster:ay29) by smtp.aliyun-inc.com; Wed, 28 Jan 2026 16:59:41 +0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b0469dcb-fc27-11f0-9ccf-f158ae23cfc8 DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=antgroup.com; s=default; t=1769590783; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; bh=TAk3SdDhStsGRPFOTP4EyAvEPIVH5OE9KkeGx4MAVEQ=; b=YS9lqz/Bq4l06gZ/AWDSU2nKfu3BhmLibm/fWiRgd8pkIup8nYfqytBf8j4jhYgIznettRXKvLs2iz7OZpPvKzM2krhCe9U/+7wttyY7VBUzQutJmf8oBAie4ITOlCubV0PncOai39NYNQP+IOz/yJ0jk3aZ+25ZS9Jo5xLhuL0= Date: Wed, 28 Jan 2026 16:59:41 +0800 From: Hou Wenlong To: "H. Peter Anvin" Cc: linux-kernel@vger.kernel.org, Lai Jiangshan , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Juergen Gross , Boris Ostrovsky , Ard Biesheuvel , Nathan Chancellor , Masahiro Yamada , Vitaly Kuznetsov , Thomas =?utf-8?B?V2Vp77+9c2NodWg=?= , Brian Gerst , Josh Poimboeuf , Andrew Morton , Alexander Graf , Joel Granados , Thomas Huth , Uros Bizjak , Kiryl Shutsemau , Pawan Gupta , Guenter Roeck , "Xin Li (Intel)" , Ilpo =?utf-8?Q?J=EF=BF=BDrvinen?= , xen-devel@lists.xenproject.org Subject: Re: [RFC PATCH 0/5] x86/boot: Allow to perform randomization for uncompressed kernel image Message-ID: <20260128085941.GA68023@k08j02272.eu95sqa> References: <7716B334-004D-4CBB-9237-E8AE5CE696CE@zytor.com> <20260127120307.GA20714@k08j02272.eu95sqa> MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) On Tue, Jan 27, 2026 at 07:43:14AM -0800, H. Peter Anvin wrote: > On January 27, 2026 4:03:07 AM PST, Hou Wenlong wrote: > >On Mon, Jan 26, 2026 at 11:30:28AM -0800, H. Peter Anvin wrote: > >> On January 26, 2026 5:33:50 AM PST, Hou Wenlong wrote: > >> >Hi all, > >> > > >> >This RFC patch series introduces relocatable uncompressed kernel image, > >> >which is allowed to perform kerenl image virtual address randomization > >> >in 64-bit booting entry instead of decompression phase. > >> > > >> >- Background > >> > > >> >Currently, kernel image virtual address randomization is only performed > >> >during the decompression phase. However, in certain scenarios, such as > >> >secure container environments (e.g., Kata Containers), to speed up the > >> >boot process, the system may boot directly from an uncompressed kernel > >> >image. In such cases, virtual address randomization cannot be executed. > >> >Although the security enhancement provided by KASLR is limited, there is > >> >still a potential demand to allow uncompressed kernel images to perform > >> >virtual address randomization (for example, future support for x86 PIE). > >> > > >> >- Approaches > >> > > >> >Currently, the x86 kernel uses static compilation, but it retains > >> >relocation information through the '--emit-relocs' option, which is then > >> >simplified into a relocation table using 'relocs' tool. To enable > >> >virtual address randomization for uncompressed kernel images, relocation > >> >information is required, and there are several possible approaches: > >> > > >> >1) Who will perform the randomization: > >> > > >> >VMM: The VMM reads vmlinux.relocs after loading vmlinux to perform > >> >randomization. This would require additional modifications to the VMM, > >> >and vmlinux.relocs needs to be packaged when shipping. > >> > > >> >Kernel: The kernel performs randomization itself at the kernel > >> >entry point, requiring no modifications to the VMM. > >> > > >> >2) relocation information format: > >> > > >> >vmlinux.relocs: It only contains the necessary relocation entries and is > >> >simplified, making it small enough. However, it is a format defined > >> >within the kernel that was previously used only internally and is not > >> >part of the ABI. > >> > > >> >rela.* sections: It is the standard ELF ABI, but > >> >it contains RIP-relative relocation entries, which are more common in > >> >kernel, causing the kernel image to be larger. > >> > > >> >- Implementation > >> > > >> >The final implementation of this plan extends the 'relocs' tool to allow > >> >the insertion of relocation information into a reserved section of the > >> >kernel (referencing the MIPS implementation). This enables the reading > >> >of that information and subsequent execution of relocations when booting > >> >directly from an uncompressed kernel. Currently, this implementation is > >> >only available for 64-bit and has been tested with both PVH entry > >> >booting and standard 64-bit Linux entry. And the default reserve size is > >> >1MB for now, which is enough for defconfig. > >> > > >> >- TODO > >> > > >> >Clean up the decompression KASLR code to allow it to be shared with the > >> >booting phase. > >> > > >> > > >> >Thanks! > >> > > >> >Hou Wenlong (5): > >> > x86/relocs: Cleanup cmdline options > >> > x86/relocs: Insert relocations into input file > >> > x86: Allow to build relocatable uncompressed kernel binary > >> > x86/boot: Perform virtual address relocation in kernel entry > >> > x86/boot: Use '.data.relocs' section for performing relocations during > >> > decompression > >> > > >> > arch/x86/Kconfig | 20 ++++++ > >> > arch/x86/Makefile.postlink | 33 +++++++++ > >> > arch/x86/boot/compressed/Makefile | 6 +- > >> > arch/x86/boot/compressed/misc.c | 8 +++ > >> > arch/x86/boot/startup/Makefile | 1 + > >> > arch/x86/boot/startup/kaslr.c | 116 ++++++++++++++++++++++++++++++ > >> > arch/x86/include/asm/setup.h | 1 + > >> > arch/x86/kernel/head_64.S | 7 ++ > >> > arch/x86/kernel/vmlinux.lds.S | 20 ++++++ > >> > arch/x86/lib/cmdline.c | 6 ++ > >> > arch/x86/lib/kaslr.c | 5 ++ > >> > arch/x86/platform/pvh/head.S | 15 +++- > >> > arch/x86/tools/relocs.c | 64 ++++++++++++++--- > >> > arch/x86/tools/relocs.h | 15 ++-- > >> > arch/x86/tools/relocs_common.c | 24 ++++--- > >> > 15 files changed, 309 insertions(+), 32 deletions(-) > >> > create mode 100644 arch/x86/Makefile.postlink > >> > create mode 100644 arch/x86/boot/startup/kaslr.c > >> > > >> >-- > >> >2.31.1 > >> > > >> > >> Hi! > >> > >> At a very quick glance this seems like a very reasonable thing to me, but since the intent is reduced boot latency (a very worthwhile goal!) do you perhaps have any measurements to show how much improvement we are talking about? That would be really useful. > >> > > > >Hi! > > > >Uh, sorry that it may not meet your needs. In fact, it will slow down > >when booting directly from an uncompressed kernel. The improvement > >described in the patchset compares booting directly from vmlinux versus > >booting from bzImage when we want to enable KASLR for guests in MicroVM > >scenarios. There is a similar idea in [0], where KASLR randomization is > >implemented on the VMM side. Now we want to implement it directly in the > >guest kernel to reduce modifications to the VMMs. There are some > >measurements in [0]; however, the comparison is between vmlinux and > >bzImage. > > > >In my test environment, compared to the original direct kernel booting, > >it would add 2ms for my test configuration [1] based on the Kata > >Containers repository due to the self-relocation phase. Booting from > >bzImage does not affect the boot time, as it simply inserts > >'vmlinux.relocs' into vmlinux, resulting in no change to the total size. > >The decompression time should also not be affected; I didn't notice any > >difference when measuring the decompression(). > > > >[0]: https://dl.acm.org/doi/epdf/10.1145/3492321.3519578 > >[1]: https://raw.githubusercontent.com/virt-pvm/misc/refs/heads/main/pvm-guest-6.12.33.config > > > >Thanks! > > > >> Thanks! > > Didn't you say that that was the reason for this? I'm confused now. Maybe my expression is not clear. :( Let me reorganize my thoughts. If you want to enable KASLR for the guest, this patch makes booting faster, as the guest is now booting from vmlinux instead of bzImage. However, if you dont need KASLR for the guest, you can continue booting from vmlinux, so the newly added relocation process may introduce a slight overhead (due to command line parsing), which is what I meant when I said it slows down the booting from vmlinux. I'm not sure if you need KASLR in your case. Thanks! From xen-devel-bounces@lists.xenproject.org Wed Jan 28 09:09:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 09:09:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215286.1525491 (Exim 4.92) (envelope-from ) id 1vl1YG-00085S-JT; Wed, 28 Jan 2026 09:09:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215286.1525491; Wed, 28 Jan 2026 09:09:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl1YG-00085L-Ff; Wed, 28 Jan 2026 09:09:28 +0000 Received: by outflank-mailman (input) for mailman id 1215286; Wed, 28 Jan 2026 09:09: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 1vl1YF-00085F-04 for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 09:09:27 +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 09f11b19-fc29-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 10:09:25 +0100 (CET) Received: from MN0P223CA0018.NAMP223.PROD.OUTLOOK.COM (2603:10b6:208:52b::35) by MN0PR12MB6222.namprd12.prod.outlook.com (2603:10b6:208:3c2::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.10; Wed, 28 Jan 2026 09:09:19 +0000 Received: from BL6PEPF0001AB4B.namprd04.prod.outlook.com (2603:10b6:208:52b:cafe::6d) by MN0P223CA0018.outlook.office365.com (2603:10b6:208:52b::35) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.8 via Frontend Transport; Wed, 28 Jan 2026 09:09:18 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF0001AB4B.mail.protection.outlook.com (10.167.242.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Wed, 28 Jan 2026 09:09:19 +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, 28 Jan 2026 03:09:19 -0600 Received: from localhost (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_256_GCM_SHA384) id 15.2.2562.17; Wed, 28 Jan 2026 01:09:18 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 09f11b19-fc29-11f0-b160-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=RjRHs47FsBBgXnGGC6FEzOMHBdG8PZEAIpEyEytQuMBbbTbDluhF5Ox2qbHo72oHIqtZtPnX9gP82/tuRgigwz5KUjII0bsdOuovLiNu5EIpgpbUU39/i5W1ESD4ODlj7fSI8n/mQI74eVm4Y9+KBD7CWh87vDsb6GhPq48RZcRHcDL8R+duH8+mIl1UkRxhQHzFbDQgIFMsxUXiBLh494slvL+XWdlaPxtFRPxL8DqzD27Imz8tloG+claLffP8ZL0Od3rBllHgvNObjfiTw0Db2SRZYfl47FYoAcILiBmW+UVmcWbTP4DwVASrsjigFI1ZDfghSWMqnx+I9eS01g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+nHptbgsDRWgez9degAsVCHy3Mam68+SQX5W1RzfTO0=; b=U7WWWc5Pghftsjo6kctjwFpGbGlhJm317nKRvfnHHJKwL0hlXWRLbVWVXZuiekYQEr7AKxixOTrB9bMUWwZBhcDCvJY/B7+o5FvOnirKMMGejhcoUolyBVINb/xTdStgnRnWvFGF8xTGqJ2KZXTvnBbZZLDk+pud6l+JntBPxBjxrGeet9/Q30Rqoxuk2fwPXkCNNPRPQ/t6kegSCjOlXchenYw5FWl7WL1HXB21+kIh5m+zPF7ibx1Jko8h08PE71EVZ1oDX/HA5l96YvVa3pZAlxKw1Iwpz6S7II06Sku67Sl3ojZl/CtEY7Zj2c5IIUDb+IdooiCRv4Dcir4GsQ== 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=+nHptbgsDRWgez9degAsVCHy3Mam68+SQX5W1RzfTO0=; b=R2XVCbsVraxD3DjO8Z5iavs7LX4+7yVSekjfLWkDHcuicnbEeBk/NTi6H+EoRqjXnBa147XE8SD3bpEXEVFMD70rjtCqXQsQ0WhzLgSftf9zwOsA5kpX1A2v6qegoc/U2wwWNym6AE0z5KjMJrnGvtQOYG/e+ZgPBx+7kX6V2lo= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 28 Jan 2026 10:09:16 +0100 Message-ID: CC: Andrew Cooper , Anthony PERARD , Michal Orzel , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Subject: Re: [RFC PATCH] CODING_STYLE: Establish a policy with regards to copyright notices From: Alejandro Vallejo To: Jan Beulich X-Mailer: aerc 0.20.1 References: <20260127182403.141459-1-alejandro.garciavallejo@amd.com> In-Reply-To: X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb07.amd.com (10.181.42.216) To satlexmb09.amd.com (10.181.42.218) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB4B:EE_|MN0PR12MB6222:EE_ X-MS-Office365-Filtering-Correlation-Id: c9506f9a-35a4-488b-4a56-08de5e4cebc9 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: =?utf-8?B?cDRNOVhSNTBVRHZoekZXbTIvRnVVancwRDdOMkRhbzBRNktvUjBmZWpHeXdh?= =?utf-8?B?YjAyK0Z0VTlnKzFZWEpZaGZVRWV6aWVCYWZxNkZzdDFXNERDR2FmbFVvRlRW?= =?utf-8?B?VVNKYmx5Uy9OaDRCK3d5d3VXcnRFZkV0Rjg0Qjg1WG1RQm1xRHFZa25PMVlm?= =?utf-8?B?bFpTQXV2R2ExOFFLR2hHOEg3cUN3ZXVzMjIzN1I2RDI4VUhGVC9va0dQSjg0?= =?utf-8?B?dkovNmpxdnFVYVFkOWowbDRTK0M1c2NPNHRTczNNSU9ya0VoRlNDTXdSTThT?= =?utf-8?B?b0NyWVVlVm1IRzZnMzFMQkFBY1JGZ2ZFTHB4akdtWC96YXV4T3drV0VxUStZ?= =?utf-8?B?ejJnN2NENVNQczdqdlp6ZkdrSTZqb2IwSnFPeWlwU0JMb2ZqUmlVcEZTWlBP?= =?utf-8?B?TjM2UkdmalE0cVZoUnRGWUQ1dW40SXdOZldzaGp5WnJjNFRiVzcwNlh0cTAr?= =?utf-8?B?WUVOdjNVSzFETStnaGQwYUx3c3ArZUVrdVhwa3JncTBCZC9TV2FoN2FQc3h4?= =?utf-8?B?R0tiRzZBV1hSUmtPTGlFK0svcHhucFErR1hra3ZuRUcyb1ludUVwbTM2Wk82?= =?utf-8?B?azdQN0tISk1ka3kvQUdDWG1WbTB0VWwzak85R2dsLzI4V1hrTHRzYWR0a3NK?= =?utf-8?B?VU9DZUIzSlVienVOTmtFd1FTQ2NoemRIeHlsZVNYUEJHWS95Vll3d0dmM3Qv?= =?utf-8?B?dDNiWlFDWU1jdUQrK3Y4RTl1TnlvUW5ieWNQL3c3UFhHcFpsUWIwZVR4bW54?= =?utf-8?B?NFRhUE15c0J4NWZScytEajN5NUdYSjIvUzIxYk1CSFFYMG5RR3loV01MTG91?= =?utf-8?B?cG5Za3pHR0tQcEdKeVhiQW9HL1FtSnNjWFdLNjcrSEZWQXhoblJSWUlGdHlK?= =?utf-8?B?N2JtblFuQ3p1bEF1eHpuaElXRTNHeG5PbE5ydGlJU2JlUFhRN1EyTjgveXUr?= =?utf-8?B?dU42UktBdkNkc0cwb0hOVFVaUlpjYnBaRlV1SWF0aGQ1Yk5pOFBsM1VOcWJG?= =?utf-8?B?U2JuQlVtTnpDUkNHaXhabm15TWUrb1l5Uk50ek9tZk9hOVp1UlFaMVIxaHBy?= =?utf-8?B?UlRYeko5dTBCZVNHVE1Kbzh2MzF1WXgyUXE1a3pickJxV1NHenU4TmFkb3Bm?= =?utf-8?B?SUF4Q0I2SUs5SUNSLytzVTEwSnY2bUEyelFXMU1lSDJ2RnpEYVVUVU0rOUx4?= =?utf-8?B?OHFPYkR1QU5ON1V6dUY2NjJnWmo5M0RjaE5zdE1ydGJPS0xSdmZoN3VFMmww?= =?utf-8?B?NGw5RnIxbUY3R0ZuWmlQOHBMcHV6SWJJNlFXSHAyc3RGMmFadmxNSFpzRlY1?= =?utf-8?B?RmFSdWFMMzNUVVk2dUlIMmJRZm00bTRrRmZPZnU5Y2h6UzhzVCtzRzhuQnB6?= =?utf-8?B?bS9WSVFQRUxrQVNDUmF2WkROQm80eWc2R0Iyc3k4SXZpdFhqWTZrZ3RNQ3VM?= =?utf-8?B?SytsTDIvN0pqLytuemNtMHk3WWN6TlBqOFY4dUg5bkJNejNFanBVbmF1cTda?= =?utf-8?B?WlBRTnNCbWsvem5pSTh6T1lJZDNLRUFCWHJUaDR6K1YwdGp5ckpYakgxbTJK?= =?utf-8?B?SzVJNi9kL2JxODBCR3I2Wk4zMzBvTnkrZFVmWmdkY2h0cCtabXVDeHludW1F?= =?utf-8?B?bDBNbEZnWGp3ZklXNTNDSmYzNXdvb2hWVGpUUFV1RitWa0NIZ2x6K0Jja3Fa?= =?utf-8?B?a2lwcUVCN1BoWE0rUWd0Mzg4SmhRcVplTEtucmpjTHQwbHFXamFHZ05UdHhH?= =?utf-8?B?M1BDRWgvUEs1VjZRV2RRUUlzQVFYQkJROHBYVnFMa2NRNGwyYTNGMXZSR1Er?= =?utf-8?B?Y1ZGOUpJV0xNNC9JV3Ntdnp3bGgvTTZDcDZYS29pSmM5b05MWWlqb0FoL01F?= =?utf-8?B?WlJQTlhwYW9sK1lmMFNqY0xlRDFGWnlMNWFRT3BTNmpCVlBOWUs0WnpPK3RI?= =?utf-8?B?dkt2Y25WK1YwQklQR0JzUml0N3FobDdaV1VDb1BNS2FTeGJWd1E3c3ZxNmFt?= =?utf-8?B?SFRmQVQvUXovOXZNdEVZSFQvcEFmM2xHUGVQVWF4dStaVTVRbUR2bHZwOTMz?= =?utf-8?B?NXFDMmYwYW5Pa2xtc3dmUU1GSGo5bUZzaG5mQUN3djNpU01ack0xdEd3cUxl?= =?utf-8?B?VDcyU2hUVWRsblZqTHRwbFlVME0yNWNHQ0hjTkdUYWNHbGloWitMUnkrSzI0?= =?utf-8?B?WXc9PQ==?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(82310400026)(376014)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 09:09:19.9183 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c9506f9a-35a4-488b-4a56-08de5e4cebc9 X-MS-Exchange-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: BL6PEPF0001AB4B.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6222 On Wed Jan 28, 2026 at 8:04 AM CET, Jan Beulich wrote: > On 27.01.2026 19:24, Alejandro Vallejo wrote: >> This patch modifies CODING_STYLE to severely discourage use of copyright >> notices when their presence is not legally mandatory. >>=20 >> Copyright notices are redundant on commit, misleading from the time the = file >> receives contributions from anyone not represented by such notice, and a= ctively >> harmful for attribution by the time the original code is long gone. They= are >> plain wrong when added on code motion.... the list goes on. >>=20 >> All attribution worth keeping is version-controlled through Signed-off-b= y, >> Co-authored and the like, DCO and the cumulative contents of git history= . >> License banners have already been superseded by the contents of licenses= / and >> SPDX tags. >>=20 >> Other FOSS projects have already moved away from explicit copyright noti= ces >> where possible, and severely discourage their use when not. >>=20 >> Apache and LLVM take active issue with copyrighted contributions and Chr= omium >> takes issues with copyrighted contributions not attributed to the projec= t. Some >> Linux subsystem maintainers already frown upon copyright notices too, ev= en if >> it hasn't reached the point of being a mandated requirement yet. >>=20 >> Signed-off-by: Alejandro Vallejo >> --- >> The actual changes are almost verbatim from the LLVM guideline, but it's= not >> exact. Wording can be adjusted as needed. I care about the core of the p= roposal. >> Saying "please, drop the notice" on contributions where it's clearly not= a >> legal requirement, or have the contributor state that it is a legal requ= irement >> and why. > > This "is a legal requirement" ... > >> --- a/CODING_STYLE >> +++ b/CODING_STYLE >> @@ -24,6 +24,24 @@ license, e.g.: >> =20 >> See LICENSES/ for a list of licenses and SPDX tags currently used. >> =20 >> +Copyright notices >> +----------------- >> + >> +Copyright for the code in the Xen Project is held by the respective >> +contributors. Because you (or your company) retain ownership of the cod= e you >> +contribute, you know it may only be used under the terms of the open so= urce >> +license you contributed it under: the license for your contributions ca= nnot be >> +changed in the future without your approval. >> + >> +The Xen Project does not accept contributions that include in-source co= pyright >> +notices except in the following cases: >> + * where a committed file already contains it. >> + * where a committed file is renamed. >> + * where such notices are on files from an external project being impo= rted. > > ... may want (need?) reflecting as another bullet point here. Hmmm. Yes, that would make sense. > > The wording of the first bullet point also can be taken to mean that addi= ng to > such pre-existing notices is acceptable. This may not be the intention? Good point. That was very definitely not my intention. The refinement also applies to the second bullet point, so I can add it as = a separate paragraph stating existing notices are to never be modified and on= ly removed with the express consent of the current holder(s). ------------------ Do you have a take for/against moving all existing notices to a separate NO= TICES file (a-la Apache). The existing file for them (in httpd) looks like this, = so they took the liberty to rewording the banners to be more digestible in sin= gle file inclusion. Apache HTTP Server Copyright 2026 The Apache Software Foundation. This product includes software developed at The Apache Software Foundation (https://www.apache.org/). Portions of this software were developed at the National Center for Supercomputing Applications (NCSA) at the University of Illinois at Urbana-Champaign. This software contains code derived from the RSA Data Security Inc. MD5 Message-Digest Algorithm, including various modifications by Spyglass Inc., Carnegie Mellon University, and Bell Communications Research, Inc (Bellcore). This software contains code derived from the PCRE library pcreposix.c source code, written by Philip Hazel, Copyright 1997-2004 by the University of Cambridge, England. It'd blur the scope of existing holders, but code moves and so do their contributions. Keeping a banner on a file after a refactor is just misattribution. ------------------ In short. There's 1 question in 2 forms I'd like to have an answer to from = a core maintainers. Would you be willing to ack a change along these lines? 1. to a Copyright Notice policy within CODING_STYLE. 2. to the relegation of existing notices to a NOTICES file in the style o= f Apache. Apache in particular mandates the file not be touched unless absolutely required for legal reasons. (1) can be done without (2) if (2) proves to be "risky" in whatever legal w= ay it could possibly be risky. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Wed Jan 28 09:10:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 09:10:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215293.1525500 (Exim 4.92) (envelope-from ) id 1vl1Z3-00014P-R1; Wed, 28 Jan 2026 09:10:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215293.1525500; Wed, 28 Jan 2026 09:10:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl1Z3-00014I-Nx; Wed, 28 Jan 2026 09:10:17 +0000 Received: by outflank-mailman (input) for mailman id 1215293; Wed, 28 Jan 2026 09:10: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 1vl1Z2-000146-9m for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 09:10:16 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 27f3e346-fc29-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 10:10:15 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DS0PR03MB7558.namprd03.prod.outlook.com (2603:10b6:8:203::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Wed, 28 Jan 2026 09:10:12 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.006; Wed, 28 Jan 2026 09:10:12 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 27f3e346-fc29-11f0-b160-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Sx+bpLx5cOKDyvMJ6R067Tth54Y7hHhph2h2IbBXose66yflkB8ePVXjqv33r53d1H5oUKMdjLAA9bZUHNPg3F/34/SckwgwiAKiXatA8YxxSYj0IZv0X8b6jeKBuZpEGWItHRmXvT9AB/J25YgARF7GK+NCFTANe6LUsgtvO8eb5tJ/cVi+wF+v+LK3LA783LwdaeOL+NdtxtuwDKFEv9uaffTR4OKcaV49q4hc8JDtujUwDx6pqX4u8wIgTSUjoFuaRgvUydGRYrR9XdOUx+UfpSmMpGmUV7eHql2wyFCKgIwWoJYnJz3/MvU5De5SAkfcTOAGPPmk4FAVktHxQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=54vf6Bq93w0LFu6OqkxOXei4nsBbddB8cIhtbTU/yF8=; b=TcXm0zz68xG0JH/oqT7OQ8N5ozVTJSQjmDa3X9V/DqAZ7xRN0EwpCVfMMEOBIMpggLkb7TkNMtPOL8AQsqR5CXP6IT38R1Glg/v01gQttsm8OPlGV8q/m+MLGRvsEtwal+mDJ6GgEVdUo9Anfbk0zeMej2lA4ZYPbY978XutEy4UtgYF1XxdlZutmStve7Hh0aL1d/qPFNF5u0wePInmeMO0oSxqKcr1DSkSbUex1ga/KTH6pLB454FCFkZlwF243Osb/NB9ks6PKXypY8MG+Zx2wHLY7BqT753q7gT1GrA0QkewlNOlOM8pj/HpostBW9O3is9zNxO215femLq99g== 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=54vf6Bq93w0LFu6OqkxOXei4nsBbddB8cIhtbTU/yF8=; b=ZDulOWa47JyNp6lX/BLBW0wniS2JD/E3uRakX7XAIw4Y5GjkD5vkKwghZLuJHBGDiiJxCFXmZDZ8Oosr8Xc8nWnVMafve/JMr9TA+08wsSPHbBHWKqhqsqRhv6LHPPCONmMNlS+jc6DrYfpsWyhAgWvOq+L7S0bsDDD2j94KPhI= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 28 Jan 2026 10:10:08 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Christoph Hellwig Cc: xen-devel@lists.xenproject.org, Jens Axboe , Keith Busch , "Martin K. Petersen" , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Sagi Grimberg Subject: Re: [PATCH] nvme-pci: fix parameter order in nvme_free_sgls() call Message-ID: References: <20260127195907.34563-1-roger.pau@citrix.com> <20260128084958.GB9373@lst.de> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260128084958.GB9373@lst.de> X-ClientProxiedBy: MA3P292CA0035.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:46::14) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DS0PR03MB7558:EE_ X-MS-Office365-Filtering-Correlation-Id: b9ee5224-fd74-4439-9f8f-08de5e4d0abe 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?Q29kZ2x1SW0yb2FKSHduZVJxZEtLMkNWY2hNOGttTkFUSzR3dXlsNEZCSWZ0?= =?utf-8?B?MzZwVUFrMVlhR0p2NWR6MENxZW5hdEtuWW9iNncxK0JUaTRrY2diSFM3ZGhi?= =?utf-8?B?UkNwSDRYa2xJeStyTGtzb2d5bG9KOXZqSzVRbGZ0RjdhbkhEVStXbW90MFRj?= =?utf-8?B?SXRaT2o4b0Nka3VobFlmUit0cG16RTFmaklkekQ2bERyNnFiUXhYeFNzWlZV?= =?utf-8?B?Tit4eUV6amUvdzk3NHZuVTB3Q3NkZWlKcFNkVVFtVFg2ZDNnbVJ5eVR4SW9J?= =?utf-8?B?OU4xcFJhQVV4YlhESWtJdWhJekxtU2kvaVJkOVJHcjVkbUNVS0E3QVV0dWtE?= =?utf-8?B?UzFWTzNjRngwWWhEZlNodHZGTjFSYXB2SUNSbjlVeE4xZnNvM0E3M2x1SlVl?= =?utf-8?B?cEJoTXNGUzBvMmg0d0dPWU5NWkpJOE9SeVRuYnpEak40bm5vVUoyZnlHTzBG?= =?utf-8?B?akFEbVNGYkc2WXVPUldZUlpDa2swRUZLYlRvVlNWVUh5YjVSOUdhMkRVaE9s?= =?utf-8?B?eGVaWHNrS1h0TTBOR3RSYzJDdVBIdStLQldZUjUxbzgzNy9zTGp6OFR4ZThh?= =?utf-8?B?b0Mrc1ZOU2c2My9ya0RacDdIa0lkSW5NcWtmeTlLM0FIYUhMSHVsSFgzYjM1?= =?utf-8?B?QW1leXFqNk1mTTdtOWdHUWlFcGpqTE5DQURlaFlPaEZyd0lQNUh5a05jbjZy?= =?utf-8?B?TFYvTlRhWjJoWHl6eDRmTC8zOE1vOC9LSzJPdkdxWVRGYnBhZHJXaTcxVk9I?= =?utf-8?B?b245VE5kbmJIc3ZPWFUxWVVqdy9tQWZLM3JEVXFoWmR6MXVpUThMVVpRVlV5?= =?utf-8?B?eEp0WkFoNzdrK2NnNTVrOUVnUWFxYmlpZVUxR1R3VmRqa3hmMXAzNHRrS1BW?= =?utf-8?B?ZE9PRko3Rml6WjRsM2x5cFNqREl0aWJNbjJzMTZzMHJ0Y25NUCtNSWlCS2hH?= =?utf-8?B?aUhUd0QwNnRFL2diSjRnTmFzaldPQVMwVFNSSmhiUWgrYXR1dUIxNG1icThG?= =?utf-8?B?c0ZCWDhDVFlTYzIxYThBZDc0ZGZLbThJdWU3QWw0RUZXbjErMTBBYW50R0VP?= =?utf-8?B?cnNycXlwZkN4UFJCcjlnRHFVL1ZsQ2ltTFZUNEx5QnN6R21PSi9DRjA5dTBG?= =?utf-8?B?c1prOFVrbFFmelkrOVdFYXVNMWUxQWVuK1FkYXhrNExGOG1jSmRKR0svVzly?= =?utf-8?B?K1BOc1VDTVZ4Y3lpWVRPRkZ0VTY2S2dmNTFBUnZ4VGlSVUFLYzYxT2NNdisy?= =?utf-8?B?b3pKRnV6eFUwdWh4THZ4L2pFSHdubWhjL09ldzQ3RTdMY2I0YVZYVVpLQ3ZB?= =?utf-8?B?TGJSL1k4WitKdE5laGFCVENFZUdITnBBNDYzRmlWNmtEY2h6bHNzcFlHa3ZV?= =?utf-8?B?UzZwYmlNQ21DTUZnNDk2Y1hEUmZXeXpmd25Za2pNNHh1RnRqNlYxRGl3SGdp?= =?utf-8?B?c1RDWjdVaHZrZnR1ME5pWE05UVNyWHlMUGZGcDlkWXJuY3N5QXRFR2E4QzF3?= =?utf-8?B?eXZBN2hqait6WUFkWEZ3YjJWRUh4dE5veG45aGIwV0x4WThuVnhoMWovNWJY?= =?utf-8?B?NWdSbkJtb3dPWUJ6NFlYNXh2MlREZVYyK1JtZWVjVG00NXFmL1pSNUpjMVhQ?= =?utf-8?B?MzA2UVFURlMveXN4cDI0Rlh0QjlGMmV5Y1hBbXYvYnVZRlh2RnNESDg3d1hu?= =?utf-8?B?MmpsZDdVWkEvOVo3aVh5QkVYWVlUYVhiKzkvNWFsVit2QVhjemZvRTBVV1Z0?= =?utf-8?B?Zk51aHlEMUxmQ3NDNVBxd3BmQnZ2TWNDQzNIWFdZTTRZNFltRWJJNldxY3hI?= =?utf-8?B?WE82MGRMTS9lVDYwYnoyL1cxbG01ZytwN1p3UGx2M25ZWUVhS2N5NWpQMFZT?= =?utf-8?B?K2I3c3ZkL21LNk9nYzhNd09aSHVjUkdDemhtM0lFZUpVdEI4cVIwVElWKzM0?= =?utf-8?B?Nmw1TnFQaGZzc2Q5Q3JvZGxRTWdWYVQzV0E2c1JhTEdnQy9Gc2lIRllLaEJn?= =?utf-8?B?REZ2dTFsaWpPTGpITVFycU5ib1VlUnIvN09hczArTkJlUVJ4bkIrMGJ3OHAz?= =?utf-8?B?djRCc1F5SzR6djEwcXRURVZqNGExSU40UTdOSEFTVnJiTzB2Q2I1cG5ka3VE?= =?utf-8?Q?RZNc=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TGFYaFFzblEwcnk1cHpmWUU1Ymo4Vnh6ZzZuQVQ0VGRxellGUEJIZXovcU9q?= =?utf-8?B?OGd4MjJVY1hIam5TMWR6eWUrQllOUS9obmxMRmRSYlNtdGRmZGNLQ0NuZG9L?= =?utf-8?B?MG5hV3Bwc3QxRFU2aVJvN2VKZWVtN2EwR1VFaVV0S1lPUmdscHN5b0IwUlJX?= =?utf-8?B?WEJ5TkM5eVB1UmxZZ3AxbUdpeXJ5K2tOQ1Z5S2JtVHBYNVR4Ly9BcXQ0TVc3?= =?utf-8?B?OUNTbnZsU1BWYXZPL1BoWVhqZ3Z4NmtMZUJ2OCtKL0JydTBiSkNSdEtLUXNM?= =?utf-8?B?UkdLQWRlRXhGWEpXeFJrMzBWRDlqTm40SkR6UmdFSmpNdXVxWnBoMjhEMS9K?= =?utf-8?B?U2VuSkZqdzVXcXloMVhoREIwRVFySmd4REY5Sm1ZbDlYWWYwemx5bzlsOXgx?= =?utf-8?B?M1hSbnR2TzVMRzNmZVFVdFJxZXNWZTY0RmpkOFdRdVYyMWxrNHBjOElBOUJx?= =?utf-8?B?b2M3aUQ0eHlzNytuazhoVWdKYTBVTkt5eC9wRmNzNHA3QU5MUEhwR1NSWklF?= =?utf-8?B?OEtsZkZhem9PNVc1Q1lhaFpvbGV4VnRUYTFXeUpXbjR3TWhhV0wwVlVNS0Jy?= =?utf-8?B?UGw2eVEvYjkrbGtQN0FjVTdyRDFpZHRMUXVOS05aRDRxSnB5L2orcjZaTUQw?= =?utf-8?B?cTVWejJ3d2Q5S3lRVXlzSVNyZmhBVzcwTzVMODZZMXVMVnFhQzgxQlNWekRP?= =?utf-8?B?ZmlaY3U2UGxpV1o3S2kwM2RNWnk0ZStlOEFVRWdJK3c1czhDOUJMaldaVGJh?= =?utf-8?B?ME8rWnl4MUlON2IxcWpSWlFPZlQzRnBUbW43TnhUSTZIc0YzdDNTWjFLNHNW?= =?utf-8?B?ck1oTnd4YmJ0eThiZDF5a0hSUS9BWEJQaUxqVjJWb2ErSGZ5U1pNU0dRS2Zh?= =?utf-8?B?OXBVclU5dElJQXVpc0puT2NpM3B3a0hPRUl2RjFXZlFxd25TNUxPRUJrUTJD?= =?utf-8?B?ODBta09aQk1sWFZDKzQrT3ZzcWQwSzVSY3c3ZnI1UzFSdG9JdDJaZGVadU5p?= =?utf-8?B?M1RRSitLaTFJK2NsaDJuTlh1MFdETW84S3ZWbSt6SlhHQUI0UTZITVNobkJR?= =?utf-8?B?ZkVrblN6aEZNUk05aWtTUFVlZ3RxNDZIa2VyS3EraWpFUGJmWlI2QUVLSlJr?= =?utf-8?B?ekZTOVZOaVFReHdMVWxKYzV5R1FRcjFUSVkraDN4akVNTVNoM2YvYkhCbWFi?= =?utf-8?B?SWpJcDlLZ05IVGZ3RXcrS3JHaTFQU3lUVkVUelVEWGRhWkJBcmpBNVljWXRt?= =?utf-8?B?REgzT2tEYmxENmw4NFFSb0lmbVB4aEI3ZXpYWGtJM1VTN2JuU1ZpYmQxL0h4?= =?utf-8?B?Z1NXcGVJNlg3T1pUSWpWVGtQYlhRZUJOY2lheTFMbkRhTU1UK1hLZGZPSCtk?= =?utf-8?B?anFJOWFSNEFlQVNYQmdrM0dVVTNjMFhWQVpySG40Qk1ZUGRjVzV1UHRWbEFR?= =?utf-8?B?aGxEdU0xZldnd2xwTU9WbG1aRCsyNlJudVdwWDZ3SXF2OFF2bUdyNC9yL015?= =?utf-8?B?SDBKS0hkWU9mYVRsalFQN1RoamdzQVQrVGF6cURvbnBsWUY2R1ZPZHc2TUF2?= =?utf-8?B?OEFZb0ZjSEt1WWJaTVpDVDNvN3FPbjN3d1psOXpndFR3My9pOEEyY2FIb1BK?= =?utf-8?B?TU1DUXo0eW9UcE5CZDU2SWh4VDdkNTgrcUthSWdpNkVhVzFVZnEwdFo0SS9l?= =?utf-8?B?OEpVSDlRRlhaL1JFRi9yQ0IvSGZDSUFVK0lBcmdRLy80c29EYTJXZWpkWFFY?= =?utf-8?B?clhVWjBmSWFEYzRIamo1UnVaSDcrQkJYV2FLaHVmaXJDY3dXYU9oeUJSeG42?= =?utf-8?B?V0VwMHFwK0k1RWpuNFpIWXIrUzgxb3VOb3BLMjYybXFPY3d2bDArd3dwYkVX?= =?utf-8?B?SUdncWJWMEkvSXVQM2owTm9xa2U5d1dveVNWMTBJejhOeUVoWWM3eUlzMFgz?= =?utf-8?B?U0tkTXNqUVl5emJ2RGdQTEdIZWxtbFNKOVFEQUJpUFFrajZHRFNpR0I0VFB4?= =?utf-8?B?R3pHSmEvWFFieXBlQXNFNTN2NWl4cW8yWTN6SjFzTW5Hbk0rSGpWSnREallX?= =?utf-8?B?Tmh4RzFNemRRWXpYOXpkZ0NEb2EzbTNVUDR3VE51S2UrMXJaZStTdDhwTUcv?= =?utf-8?B?NE1GNHA3QVQyMFdDelJHTHVmNGFTVkVvRkNCVGFzTkxVNUx4OHY3eHdNekVQ?= =?utf-8?B?UEdYSnBLbk1hUVZ0ZjdORGV0UHlhWEtaZDdvRWYvTDdYN0cyWVVQbUxVdXBJ?= =?utf-8?B?RjJ0d05yamcrTEpHWE5FS3JvbXR3U3ZUWEtVV1pBV25PdXZtSlR6NmJJK04w?= =?utf-8?B?RzFFRVgxSkFwS2xsZkZOc0tpM2ZIWW0ydmJzUFVaemZUUTNDM0dmUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b9ee5224-fd74-4439-9f8f-08de5e4d0abe X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 09:10:12.1095 (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: JVgh4dCfdkMoNHc53BfK6np+aaoScEL6cElEF/M8cp2IUHVbmfr1HSaQAvD59JgRMtWYH72VMPdi37KSqIs40A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB7558 On Wed, Jan 28, 2026 at 09:49:58AM +0100, Christoph Hellwig wrote: > On Tue, Jan 27, 2026 at 08:59:06PM +0100, Roger Pau Monne wrote: > > The call to nvme_free_sgls() in nvme_unmap_data() has the sg_list and sge > > parameters swapped. This wasn't noticed by the compiler because both share > > the same type. On a Xen PV hardware domain, and possibly any other > > architectures that takes that path, this leads to corruption of the NVMe > > contents. > > > > Fixes: f0887e2a52d4 ("nvme-pci: create common sgl unmapping helper") > > Signed-off-by: Roger Pau Monné > > --- > > If possible it would be good for this to go in 6.19.0-rc8, as corruption of > > the root device as part of a kernel update is unexpected. Sadly 6.18 > > already contained this issue, and no-one noticed, so its impact is limited? > > This only affects non-IOMMU paths with a non-noop dma_unmap_phys. > So it is a very common setup, but very severe for those. Because of Do you mean a "not very common setup"? Otherwise I can't parse the sentence. > that we should get into 6.19-rc and -stable ASAP. > > The fix looks good: > > Reviewed-by: Christoph Hellwig Thanks. > but maybe we can reword the subject to sound less harmless, e.g.: > > nvme-pci: DMA unmap the correct regions in nvme_free_sgls Fine with me. I think I was more focused on describing the logical change rather that the actual effect of it. Can you adjust it when picking up? Regards, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 28 09:18:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 09:18:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215306.1525512 (Exim 4.92) (envelope-from ) id 1vl1gu-0001pX-KY; Wed, 28 Jan 2026 09:18:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215306.1525512; Wed, 28 Jan 2026 09:18:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl1gu-0001pQ-GJ; Wed, 28 Jan 2026 09:18:24 +0000 Received: by outflank-mailman (input) for mailman id 1215306; Wed, 28 Jan 2026 09:18:23 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl1gt-0001pK-BE for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 09:18:23 +0000 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170100009.outbound.protection.outlook.com [2a01:111:f403:c107::9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 48f3f6d3-fc2a-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 10:18:20 +0100 (CET) Received: from PH7P220CA0047.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:32b::6) by SA1PR12MB7269.namprd12.prod.outlook.com (2603:10b6:806:2be::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.16; Wed, 28 Jan 2026 09:18:13 +0000 Received: from SN1PEPF0002BA4F.namprd03.prod.outlook.com (2603:10b6:510:32b:cafe::df) by PH7P220CA0047.outlook.office365.com (2603:10b6:510:32b::6) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.8 via Frontend Transport; Wed, 28 Jan 2026 09:18:12 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SN1PEPF0002BA4F.mail.protection.outlook.com (10.167.242.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Wed, 28 Jan 2026 09:18:12 +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, 28 Jan 2026 03:18:09 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 48f3f6d3-fc2a-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vg0ejhCWpUyiNltvTPcSEnZ0Zh7uRbpMv/2l1+rro7gXjiwvDNoyQbtyeKQcEk3zCANvgzxHLFXx16JD4TNfHIwX5BIhczQiE61vqZGgXg4Y7krxHQcf+bIijtP6nngKzijD83LM5wVVzQtZ5DqAdk3KGmQRsf8KnjSFEb8TWXnyPRnGHm2dBPFk1QMcAfuDwzgxgpqxJx3ZKqP1mdn/faTJz5tR+otT2PIBcIO12z9k3mloYNy7hXvYohBS/GIGCH7qSQyxGBT5pvjnEI5cZpd1s9C4ZJBrSCaISqhZSvvuPlEg4XHdEBEeksXguImjoYJ0wXrWhxfjDdegCe/58A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vWZVMK3R4Wim4A9uV1L1iUBS1DPXx4MwCMiLvSRu8D4=; b=JfuIQoH7GDs7FL3CrWqRLCO6XgiOEiI9ShA7AssvniZ7bvLh3at0e3CmtYmzPHG41REISvC/EQet1xxImN0SWNX4kbPQBT5DQiugao8LDHWaV5yR+MK1NUAFq3txWRj2GNB/P47l2RG2s86BBJPdPCB1VW/4Mv7gJ3Xdx6d5d4bF2hamQ/qachg41i9y1COGXUYj7EMfwY4H+4J4Xhz3Ws3r4+m9deN6vqR6LaetcCUWRo0KGChI5Pk3u5xv/+dkWJW6VZUIpbzwshKudLSke/sXTmBFkJl43f3kniunhjZyBMHl/z4O6T7pKnOkxzJ9jYlOf8ln05XCjE9ygvKQyg== 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=vWZVMK3R4Wim4A9uV1L1iUBS1DPXx4MwCMiLvSRu8D4=; b=s17YANnR2hfnI4JtnHoqNYldpXCF1yph53tY4zOKVtqsBRDu0EqR9tEGVD9Izcf0wTk+Z+aeb7Png23uJlWw0IprIBh8i6i0J7l8yK7prxUB4/TD5WsGva32XwnwiYsc5Jb+ziBZd4JeNJHUJvuOCUBi5oMHaZyMEugt12ggBeQ= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 28 Jan 2026 10:18:03 +0100 Message-ID: CC: , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , Stefano Stabellini Subject: Re: [RFC PATCH] CODING_STYLE: Establish a policy with regards to copyright notices From: Alejandro Vallejo To: =?utf-8?q?Roger_Pau_Monn=C3=A9?= X-Mailer: aerc 0.20.1 References: <20260127182403.141459-1-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: SN1PEPF0002BA4F:EE_|SA1PR12MB7269:EE_ X-MS-Office365-Filtering-Correlation-Id: f69489f6-5968-4606-6aaf-08de5e4e2969 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700013|376014|13003099007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?Y3ViK01heTN1d2RDNWx0WkRCeVZXTitoOG5jUmdCMmVlRk9rTjF2QXFzNUJw?= =?utf-8?B?c1Z5T2syNExqcXJZU0tGOWgzTFpuVVBLTjBSNmtYV3B0bjh3bWlCSFo2WStG?= =?utf-8?B?dHlhMUl6U21DZ3k4UGpaSGNtZXA1VURoWFdveVNSKzllNDc5dWFNVTZldWhB?= =?utf-8?B?eVFBNkYvQ2ZOMEp1Tkx1SEIzaTlQdmdLbnIvMTJRaExWeXFjbmJaZFlkU0d3?= =?utf-8?B?c0JCeG5sMGZxUmtwUWx6Z0hhSmtqUkp2YzBhVk8ybzExTUJvZFRoNVNVVlBB?= =?utf-8?B?ekZhN3ZIcS8wblhoWmdOUzgzYUlrR0ZpNVlXcld5L3RUUk90NzlXd2tBc0ZI?= =?utf-8?B?SnU4Z1ZwQmMxdFgxcVord3dUcTFlTC9DSWVFNXZoREdubTNpa2V6TzlCNFJ3?= =?utf-8?B?dEozM09lRnFiUTZBbzlmOTV2QTFBWk41b3gzZ1dVNHpiVHN6UHAzNkJlbkNC?= =?utf-8?B?TG1zR1F0T0NiRTBnam82djU0aFl1SkMzZ0RBM2hpZERqYUduck1RcENWZXdw?= =?utf-8?B?eGMwZXNKZEx4Nzg5NHJyMFNrUFZqZkFEeVZIRm8xMHFaTE1iN25aVzc4MEhD?= =?utf-8?B?ZmJHVVlKVHBsd2oxRVF6UVBWbzl1N3lydHV6UUltWE1zbGxrMWVaL2NQZFF6?= =?utf-8?B?R2M3RE8wNkhtdzVQMDlta1pRWEFZeWxxdVM5RlQ1Q2JNRC9JbENzR3NaR05V?= =?utf-8?B?RVRFRFVraEtlbkQ4NUc3b1cyaWRtYkJSNjBDbER3M2NBRER4dnBJbVpETG1C?= =?utf-8?B?VVJiYzl6WGZubUhHeWhYQTg0NzJlZjhFRllBenVub005Wnk1ekk3UXU5UmRl?= =?utf-8?B?dFdQWUw1ak5iRkpkMnV4VFRERWgwU21wL1lWbWJieGhNUGZ5TEljSVdjZnY0?= =?utf-8?B?QjZ1T3lGRUtUVmN4aXd3OUVXUjJuT01jS2twTGEwdWhuaHl6QVEzWUpOdVlF?= =?utf-8?B?djhLK09vWVpaUkpSRU1wZUtiWWZtUWhVeWpPSFFIODg5aGVnckdJLzlxZG9t?= =?utf-8?B?YzYrTlZ4R25wMXZtS3dqb3J3RzExby9VUU5WczJGZ0hCek9QUDE1Wnc4SlFG?= =?utf-8?B?d1ZocUk0SWQ0dDJXaWFBNXVFWllScFhRbzBpM0txYXFDamI5MnZrRzhsNWNv?= =?utf-8?B?dk5kRFJSUml6by92WGhXTWI0UVZNMThldmZpbGdOUDR1aENkeEJNckR5NFlP?= =?utf-8?B?ZG91cDI2dUZ6VW5uUHF3eXhhSHEyN0F6YzdZa2J1WEhrTlArUnNPQnRXZmJP?= =?utf-8?B?UXVQcGRKTWh6SEZya2dKZDh6R2tXSXJJamt3TCtKVzlraVE5R0ZyZnY4cE5X?= =?utf-8?B?MEJSTjkxa2NyZXFQek50MGkzMkg4SUV3eTlaekRveVF4Q2xDRndhNlc3TEFE?= =?utf-8?B?UDVNaHk3ZFFvWGlFZTZLTzlEbWdoSkdCODl5U0pMOGNyRGRyYTRVS1hPT3lO?= =?utf-8?B?UGdGTVNkd0hkUnBIS3Z4R2lMQVd6ZVNEdXFRWXdhZVNidFB4c2lSMWdmT0JZ?= =?utf-8?B?ZkN4UFVSWGp2MmRiU3FpdTFTOVNFTHMvcFMxUE9LQWZuTnV2cmNra0VZVC94?= =?utf-8?B?SjBUMS9rNTRwS3RFRW94dWg3bmEzV09CbWEwc1lkTlhvdzJQcysxZERTV0ht?= =?utf-8?B?TysvTHZ5dWRVY2tjMGN4RmpPTW9OaXJWQUZJSXJONnJWbUV4L2xRMkUzTXRo?= =?utf-8?B?NUY2ajkzWW1EV1B4S3NKS09ONmx0WFZnem4wd1NmWXpKM1k0UXBRRGg0d1N4?= =?utf-8?B?cFhrWWptWnkydVI4L0NtdW91Z2VuL1J1Y0pHWEJoUWN0ZjNPaVVqa3REMm1H?= =?utf-8?B?T0d3Mml3YkhlOHp3M0lSRzNYdHQrN3V2Nmg3RGtXcHA4VFVtWXdlREZTKyt3?= =?utf-8?B?WWVoL0hzTTFWRTR3L21ZbnhWMjRSRzdxYWpEMHdYU2tzSnh6d0k1TTZFWncv?= =?utf-8?B?MGd1end0dnN1TE02cTRqeEVVRUpKRXkwbmx1WU9PM3d0aWg2T0ZONWZQbHVR?= =?utf-8?B?WDVRbnk1WVdXcTdoOGN1SVV5ejdRZW44aDBZUDBFQW1yRDllSE84OUZST1JH?= =?utf-8?B?TURnczlURDNVMUNBUFd4V2dEYjFGQmRoZE91MkdBcTdNODc4blZZc1pnVm4z?= =?utf-8?B?c3ZoZmxlZnBqYUdJWUtkcnd3RHk5Z09QTS84cXdCL3lpUGFkN2tqekJXNFBU?= =?utf-8?Q?QL3Kxj8EV5A/Af3AYrRBIRE=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(36860700013)(376014)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 09:18:12.7624 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f69489f6-5968-4606-6aaf-08de5e4e2969 X-MS-Exchange-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: SN1PEPF0002BA4F.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB7269 Hi, On Wed Jan 28, 2026 at 9:10 AM CET, Roger Pau Monn=C3=A9 wrote: > On Tue, Jan 27, 2026 at 07:24:01PM +0100, Alejandro Vallejo wrote: >> This patch modifies CODING_STYLE to severely discourage use of copyright >> notices when their presence is not legally mandatory. >>=20 >> Copyright notices are redundant on commit, misleading from the time the = file >> receives contributions from anyone not represented by such notice, and a= ctively >> harmful for attribution by the time the original code is long gone. They= are >> plain wrong when added on code motion.... the list goes on. >>=20 >> All attribution worth keeping is version-controlled through Signed-off-b= y, >> Co-authored and the like, DCO and the cumulative contents of git history= . >> License banners have already been superseded by the contents of licenses= / and >> SPDX tags. >>=20 >> Other FOSS projects have already moved away from explicit copyright noti= ces >> where possible, and severely discourage their use when not. >>=20 >> Apache and LLVM take active issue with copyrighted contributions and Chr= omium >> takes issues with copyrighted contributions not attributed to the projec= t. Some >> Linux subsystem maintainers already frown upon copyright notices too, ev= en if >> it hasn't reached the point of being a mandated requirement yet. >>=20 >> Signed-off-by: Alejandro Vallejo >> --- >> The actual changes are almost verbatim from the LLVM guideline, but it's= not >> exact. Wording can be adjusted as needed. I care about the core of the p= roposal. >> Saying "please, drop the notice" on contributions where it's clearly not= a >> legal requirement, or have the contributor state that it is a legal requ= irement >> and why. For fairness sake for all contributors to the project. >>=20 >> I'd prefer taking the Apache approach for new contributions, but I want >> some discussions to happen first. >>=20 >> Thoughts? >>=20 >> Relevant examples: >>=20 >> - LLVM: They banned copyright notices, unless part of a vendored >> components. >> - Links: >> - https://llvm.org/docs/DeveloperPolicy.html#embedded-copyright-or= -contributed-by-statements >> - Relevant quote: >> The LLVM project does not accept contributions that include >> in-source copyright notices except where such notices are >> part of a larger external project being added as a vendored >> dependency. >>=20 >> - Apache: They banned optional copyright notices and relegated >> mandatory notices to a NOTICES file that also contains an >> Apache copyright notice. See links. >> - Links: >> - https://www.apache.org/legal/src-headers.html >> - https://infra.apache.org/licensing-howto.html#mod-notice >> - Relevant quote: >> If the source file is submitted with a copyright notice included >> in it, the copyright owner (or owner's agent) must either: >> * remove such notices, or >> * move them to the NOTICE file associated with each applicable >> project release, or >> * provide written permission for the ASF to make such removal >> or relocation of the notices. >>=20 >> - btrfs: They are highly discouraged. >> - Links: >> - https://lore.kernel.org/20220909101521.GS32411@twin.jikos.cz/ >> - https://lwn.net/ml/linux-fsdevel/20221026074145.2be5ca09@gandalf= .local.home/ >> - https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/index.p= hp/Developer's_FAQ.html#Copyright_notices_in_files.2C_SPDX >> - https://lwn.net/Articles/912355/ >> - Relevant quote: >> Let's say it's OK for substantial amount of code. What if somebody >> moves existing code that he did not write to a new file and adds >> a copyright notice? We got stuck there, both sides have different >> answer. I see it at minimum as unfair to the original code authors >> if not completely wrong because it could appear as "stealing" >> ownership. >>=20 >> There's more cases of other projects taking similar stances. >> --- >> CODING_STYLE | 18 ++++++++++++++++++ >> 1 file changed, 18 insertions(+) >>=20 >> diff --git a/CODING_STYLE b/CODING_STYLE >> index aae5a47ac2..97f80245ed 100644 >> --- a/CODING_STYLE >> +++ b/CODING_STYLE >> @@ -24,6 +24,24 @@ license, e.g.: >> =20 >> See LICENSES/ for a list of licenses and SPDX tags currently used. >> =20 >> +Copyright notices >> +----------------- >> + >> +Copyright for the code in the Xen Project is held by the respective >> +contributors. Because you (or your company) retain ownership of the cod= e you >> +contribute, you know it may only be used under the terms of the open so= urce >> +license you contributed it under: the license for your contributions ca= nnot be >> +changed in the future without your approval. > > The usage of such direct language here, by using you to refer to the > reader / contributor, set a different tone from the rest of the > document. Maybe something like: > > "Copyright for the code in the Xen Project is held by the respective > contributors. The author of the code is the owner of it as stated in > the DCO. The project cannot retroactively change the copyright of > contributions, unless explicitly accepted by all authors of the > code." Ack for the tone. The particulars of the wording might need tweaking even i= n this version to constraint the scope of "contribution", "the code", and so = on. But yes, the difference in tone is a direct consequence of the paragraph be= ing a semi-verbatim copy of the LLVM policy. My intention was less about consiste= ncy with the existing style guide and more about bringing the point accross. > >> +The Xen Project does not accept contributions that include in-source co= pyright >> +notices except in the following cases: >> + * where a committed file already contains it. > > IMO we should also prevent expanding the existing list of copyright > owners in the headers, and hence don't accept expanding the copyright > notice of existing files in any way. I don't think contributors to > Xen have been expanding those headers in a long time, but would be > good to have it written down. Jan made the same appreciation. I agree. > >> + * where a committed file is renamed. >> + * where such notices are on files from an external project being impo= rted. > > "where such notices are on files imported from an external project." > > Seems easier to read to me, but I'm not a native speaker. I agree too. ----------------- I have the same question for you I asked Jan elsewhere. There's 1 question in 2 forms I'd like to have an answer to from a core maintainers. Would you be willing to ack a change along these lines? 1. to a Copyright Notice policy within CODING_STYLE. 2. to the relegation of existing notices to a NOTICES file in the style o= f Apache. Apache in particular mandates the file not be touched unless absolutely required for legal reasons. (1) can be done without (2) if (2) proves to be "risky" in whatever legal w= ay it could possibly be risky. This is httpd's NOTICES file as of today. Apache HTTP Server Copyright 2026 The Apache Software Foundation. This product includes software developed at The Apache Software Foundation (https://www.apache.org/). Portions of this software were developed at the National Center for Supercomputing Applications (NCSA) at the University of Illinois at Urbana-Champaign. This software contains code derived from the RSA Data Security Inc. MD5 Message-Digest Algorithm, including various modifications by Spyglass Inc., Carnegie Mellon University, and Bell Communications Research, Inc (Bellcore). This software contains code derived from the PCRE library pcreposix.c source code, written by Philip Hazel, Copyright 1997-2004 by the University of Cambridge, England. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Wed Jan 28 09:41:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 09:41:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215321.1525521 (Exim 4.92) (envelope-from ) id 1vl232-0005qK-Ef; Wed, 28 Jan 2026 09:41:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215321.1525521; Wed, 28 Jan 2026 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 1vl232-0005qD-C7; Wed, 28 Jan 2026 09:41:16 +0000 Received: by outflank-mailman (input) for mailman id 1215321; Wed, 28 Jan 2026 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 1vl231-0005q5-2M for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 09:41:15 +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 7b9164c7-fc2d-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 10:41:13 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by CO1PR03MB7794.namprd03.prod.outlook.com (2603:10b6:303:275::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Wed, 28 Jan 2026 09:41:09 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.006; Wed, 28 Jan 2026 09:41: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: 7b9164c7-fc2d-11f0-b160-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TPftC9qgS1cSGnEXPlR9q5LWc5KRNx218CYv2N02WlxRFI7U58xJL1t8Oc5xINLEyBbIgMmwrb8Dpr3ZOsB9TgKLUlkZ3yHSk1r7zq1KMBKBMaXbFRyfyBs4rQwuK1ISnK11J+eehioHJ76BKkNjiyijx0JZ2RzvUrUvl2Q+4fDvBROHsVzZkGzdxjxUYXr2Jw97KdeGtixRcmX9mrlP1utiLntfWubFcGzUDJU9Ofd/DaA2yCI1uOm5SzXir1ouTiiVj6H/ERok1dUIm1WTKcL1q75/JmsLjaSxuZKhezQWUkyJHKj2H9h5lUcSOKTtZZ7IhNlem/79n7rQHZ02/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qhhRkBIRWleugWgVZyHf5eP9T4PMo6oyFl/6iT22GaY=; b=E3rt4hVr2LnpH411qW0RFF27k1mpp+mi9dDCZ3p99ryniDdYHcrSRZNGaGQ5gIKj9IJjajAXZ+dopvCjYnIdsG61qY2w5O15Ceh9alKHO97mYVWzB8mpAx7cfD7LRl5Jt14aPtxlnCCWZnUqyp4CrsVhVfgk9AUJJyiVpH4mUcyHX1sOpG0eZPMWh400/cvT02zpIRqlUskz9zBj5CchowXU10p+PSD1jCH3UB/qLtnuWqf9NpjrgpezYpNSzPwOTK/CjSY9vAuFJ+9738MR1KCO4INrxMuMkJoyx/dL7IiIkkLWK6oOcWqfBt2ERBff3C/qqurP9Vj2C86wryMFng== 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=qhhRkBIRWleugWgVZyHf5eP9T4PMo6oyFl/6iT22GaY=; b=HvNGk2fT9YpxnQ01ReOF3rJqdt1CGccoahPgVq1/JlIYHEpBlpui2Yk4G3XMVOWkTJasCj1xuwffNtV8JW3FJKQf5F/v8SHKB2cQAWbfOkGViR7bxLBdGPZSTkNdsn9qfzhpNX1pSeltkZYpoalbAAvmzeBe2v0IwJ5xmtf6B88= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 28 Jan 2026 10:41:06 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Alejandro Vallejo Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: Re: [RFC PATCH] CODING_STYLE: Establish a policy with regards to copyright notices Message-ID: References: <20260127182403.141459-1-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: MR1P264CA0086.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:3f::31) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|CO1PR03MB7794:EE_ X-MS-Office365-Filtering-Correlation-Id: ba0592ce-db0d-423f-783b-08de5e515dff X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?OERsZTJGSWx6Qi9uV296aGZHNHFzSFZCb2NFYVpIVG9JQVd5Nk1RMlZwWUNL?= =?utf-8?B?TkphRk02dThRMldsNitKVmFNVWIzeklwZC9rQ1l4MG5Xc3lRVnRWQjY3blhY?= =?utf-8?B?dllKb3RGeW5jSXVVYktTWktKRDdqWjI2b3dWcndNWXdiL085dmJIMURocDF3?= =?utf-8?B?bVpHRkkvb2tJbWRaaTBoVGg2RVhJbVdNRnBKVnIxV0psRC9qd2RlL2FtUitW?= =?utf-8?B?SDBzRnkwR210aG0vOTdjV1BDR0xTRXZDZWdySlB4MjBrUUU0Z1lYNmNXdGNP?= =?utf-8?B?UzhBU0NmQlNTMDcySGtXWmg3RTNxTnc5QXFPeHIrRXdXNVhsTjZhSTRqK0ZB?= =?utf-8?B?RHBzK0tYbFRYV3M5dEVaeldDL21lU21nOU5qSkVJN3RLK0tjYmltWU1rZ3lk?= =?utf-8?B?R2hiMldKNVVETityUVJ4MTNUbG5EK2h2UE1maVBsTFRpaWNKVVZ4bnJUQWg1?= =?utf-8?B?NWdWeS9iZEVGbnVXeWtBTmw3QjBXK3loelRHSVFPN0V2Q0liMmp6UzlMTEZ1?= =?utf-8?B?MGJpTTY0cFEzZ0tJYjZJQldhREZDYU5UTVFNV1A5eHo5cUhVMjRpNjVSRmRs?= =?utf-8?B?QmR4eDVHTElZVk85VVozUVhOdnFwL21yVGtqODlxSTErSHRYd0cvSm05eFZJ?= =?utf-8?B?ZnFtT2F6MVV1Rlp3bTJpR1lpTGU3aVBBTUtLc3Z4elJMRTM5My9tUHFxMkRR?= =?utf-8?B?OGM2T2ZJbEZvY2hyVWVkQ1hoRWJJZmo5UWIya3c5UTRzL1FDb2E2Y3BLSHNj?= =?utf-8?B?ellRVzhHMVlqK0xwclRYNVc0UjBlSksyL3dUT2JRcXBCMlkrZWhsRXdOV0ZJ?= =?utf-8?B?VEI0S09JN1pJNVpWOE9sQ09TdGRZRUVFYndpcHBBUGFIc3JXdG10MldPaUVz?= =?utf-8?B?djRlTHBVc2c2SzRCTGZscDRoYkFOcUswQXpCNlB1cS8xK0F1Z0JpMDVybUll?= =?utf-8?B?VTNFZ3pUbnVpWTFickJVWlVrN3JjcUd2c3h4VGU3S2FRdDNqTnRVM3R1VGJ3?= =?utf-8?B?SFZWc0xveFM5SEc5YU5kUVp2TmRhbG5iVExPbDhQdCtmSGJlbzhJakpaT3Iw?= =?utf-8?B?U2xqb05ScFQ0ZGtHMTZJN0VOSU41c0EyT2tTcmxwZkpTbXdINENIK1dNNUZt?= =?utf-8?B?T3RhTnpGN0xJSTZYeExmOEdFbm1RWEI2aWEycFY0Q0t6dW1DRFVuMS9Ocnha?= =?utf-8?B?bHNHMldDSzMyUWxmOVFEYWdoK25kUFJML3hkTHBsVUZncVlmWDRIL1JrZWhq?= =?utf-8?B?QUNwU0VGbnVTMHNyWDFvSjNXSkRoMUI4bHFpempMd2I3K203anIzODIvaXBR?= =?utf-8?B?M2JSTTRuaXFlR3pGUWgvc0pDT2RuSG9sZStBWEFUWFkzV2JNWEtSSXlKUW5x?= =?utf-8?B?eDV5cmxka2tsUFBRZHJ3WDV3Sm8yQ3orZHJxaGdRS0Q1SXZRMis5M0RZN3F2?= =?utf-8?B?ZHoxZlBsQkY1Z2pwa2hSWjFXbFVkWW4zalNhZDBQVU1TbnNTTHZXS1BPVG9q?= =?utf-8?B?THZGVjY3ZGtvQ3hrZk5JMVBveEplcklabnZvN0l3YkhOZXVvSDAxZ1EwNkMx?= =?utf-8?B?N0htdnVqcmZvSHp4aXFQWjN5bTdiejNXbUxrQ081TU1haGpIdDZOWVczZmEr?= =?utf-8?B?cldGSnBWVlN4a2RLMzcrTHcvRjd1UVJCOHJ2bkwrZHB3QktTcVV4OTVVREdK?= =?utf-8?B?RFRITUlPWitKN0hQR2RBYmtvQlpJcCtmcmFJbUJuUHJwVjQza0VzdWJkL0pY?= =?utf-8?B?bDg5U2JKb3NFQURlR1doNHZhdnA1NklqeHJ5VEFXWjFRZ1R0UTFXY3FkQVVJ?= =?utf-8?B?ZFpkYyt5ZG5IWTNNaFN4T1VaTlA0YjRUQncvMVZ6SnBraHJDQzRxemt5T0U2?= =?utf-8?B?eXZHUHBOcGIwQkwyeTY1QW5jWTJGOHpiRFAxRHJWdUNMa0F1SmRWWVBGT09F?= =?utf-8?B?U2V2NkN4MDFHSE9ad3pFRjZyS0xJNUZJcDRCSzhIbjAwb3dSd1YzODMvZ2hh?= =?utf-8?B?K255c0dyWUZSaCt3YXdlTUpPOVVqNGl3KzV5eVJ1N0k1dDZNdHVPWlF2SWE4?= =?utf-8?Q?q07XzU?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UUYvZ1Zhay85b0UzTHF4WkhIeEdXWndNNWM4SmlHSzhMaUx1NGQzY05ESkhE?= =?utf-8?B?am5Ccis0cGVxNmRwMlJpbFJvbUVUd1RpdFFsM3NkVFQ2bE1qRWZ5QmRqUWVw?= =?utf-8?B?UWIvZ2xCTDZjQ2gzYW9Jb3lBL1U0bGpiZDJTWkErMzI4LzRwYzk0M3hyVFVp?= =?utf-8?B?QU1XaWtycndpb1NWRHZuVXI2eXRHWm43M2ZTRmxQdFlBNVdmMFBMaW0wTVNS?= =?utf-8?B?RlRwaFRRbDBySGdJWnpiQ2VZYS9hRFk0cS9KZHBvdTlQOTRTa3c1YXF0UnJH?= =?utf-8?B?YlFlZVR4WWlDa2w4VlR5eUZhaWNlQUxxYlFkY3ZES3dRRmdad2xMWmk2TUg1?= =?utf-8?B?OGgwakdFdmx1V2hCTFprN1YvbFYvTGQyVjQ5ZURyTWliclJ6RGJtNzJ6Mjlk?= =?utf-8?B?NzdCemd1KzE2Z05SaENJdG1Pa3pXb2FNb1FJemllRnZucTZ3ajE4Ylh2aDhi?= =?utf-8?B?WEpMMUIzVzhUcHpvOThWV0xWaVJ1Wjlqa2NPV3lRY2F1Yy8zUjhEYzZJYUp1?= =?utf-8?B?TWxET1dvclcwWEFkNkhpdEludFZTZzExeU1iejY2VzNYNWFxdExpUUI0WjdW?= =?utf-8?B?QVdmWDVyeHB1eUNWdHVnRHpHS2U3UU40elM3TGI4TVo3MFJWUW82QW84Ky96?= =?utf-8?B?aGxOYllnd1llemlyKzZiaEMxVDh2R1lpUW9VOFNPMmczelE0QlV6MDRjNlJL?= =?utf-8?B?VkhsK0RvZlYzaVVKNkhxS0gwcU5kYWp3bUs4TEFYWHk3Y3I4c2dML1ZrdWd2?= =?utf-8?B?Vmk2Zmd0K0pVeVNYN1VER2k5VXU5NVFTOEcvemIrM2M0T1gra3RCM0ZvZEg2?= =?utf-8?B?enZETWdVTmZTVUFoc2FkcTZSNVJaZ3dhUDBNUTl0dEJKTDlSUUlaNWtlMXhN?= =?utf-8?B?ZCtlaDJOeVpRQ1BNSGVoNVR5UFhVSmYrRjNhNUE5TDBhVTQzdmxEajQrMzdF?= =?utf-8?B?dWo3TzNhTW9lTGJjakx2UmtabGhHUjcrK0x0Rm9wam9QdUxEbnJhWEN5VnVY?= =?utf-8?B?TVlnOHFGSmF6SVIvTFpHRXlhdWRGWjFrWkN1YzNzb28zMkdpa2c2MU1Jc1JT?= =?utf-8?B?VmlWNTVnVS8xb1NmVG1uVzhQZW1GQkNKNDZCeE5yTXB5NXE1WjRNVWVBZTN2?= =?utf-8?B?NzdJK1dxM2h5RjNQMHVpNkFYU21UVmhSWVhTOWlPYXAxaU5keUN1SEx2T2RB?= =?utf-8?B?YnpKMXhIZmNQZitObUp6ZUs1NFdweEZ1TndhUVBQaEQyQ3NZWE1XV3B2dUEw?= =?utf-8?B?dW9vdkpzelVIY3QraDhUVXFLSlcrZFRDSEllQnM4dnBYeGxMWXliaFpCdW5q?= =?utf-8?B?bDNGdnZtVklnTVZLZXp6QjcvMGlNWHh1eWtUcXNTT3luaDYvTDhWaVV5YVhz?= =?utf-8?B?Y1RBV1lSN01SYkdZaitUaFVIamlKWk40bjNJNEFEMkpzM2VlZ1FaR0hhQzFw?= =?utf-8?B?TG83UTlUSExuVVZ4amVVcitEVFN2blpiRUMwWmpGcU15enRVbXhQbmhiNHNy?= =?utf-8?B?QnVXc0dwd1ZHSlE5bHlnNkJCOENvZGJYSm8xQUlHVW9HY0xzNm54eStrN3VC?= =?utf-8?B?elNXQW0vaXdEUEhvRDdGb1NqbWx3UmtDczRwVW1OWkRkNDM1TUdjTm8va2Q1?= =?utf-8?B?M1FwV29Nc2ZwSUc5UUFIV1Z4NjYrYVdHOGNtWEwxUHVUMkNKQldTbk5CKzVO?= =?utf-8?B?Lzd6aE9sNkI1amFaQ0E5di9wUEtEVm1FVTIwYTR5U2c0bHZYcll4cEFBbCtw?= =?utf-8?B?L0JLeE9OYkh4T0Q0L2JzM2N0MktTL0dRZXhLRlB1MnF6S0k4bHZldU5oV2Nk?= =?utf-8?B?dzAvQXdaYXVYbERjOHdQWlEyczBadThxQ2ZXNDdmaGxKZTBEL1hZTXZPUGFz?= =?utf-8?B?WGxsaVB5UGNPb25peFRVL0ZSd2t2dGJpMVVmMVpiYWpxc3NkSHJqZGpGUzdr?= =?utf-8?B?d3RINE5ZbXh0NlFnTmJtanF1OTNkaFQ5V1ZFLytNZHFIbktCMmtqdmVIQS9G?= =?utf-8?B?L1QvRmhIUGdTcWx6dVBsQUNKTUR3aXJTdlVJZnZXOUxmSG5ud09rSFgrSmta?= =?utf-8?B?aFozNk9iM1Bza2c0S1BqeXQ5U3pSQ3hCZHhmQkI0aG93QVZxVGlReVN2R0g3?= =?utf-8?B?dzlieUppcU9GSXVOTE02RjM4TWJQN3loNC9nRkVVNnVxOG1DRG9maWFVNG5P?= =?utf-8?B?L0F0RTEzQlpZQWRocW9NWmVETnZ4eHhDQnlDV2plbGlKaytnQVZRaFlQL21P?= =?utf-8?B?NkFmcGdzWndwa3JaTU83MHdYeXQrKytScm1ScUcxTEFnbEhqY3ZQZ3p1RUZV?= =?utf-8?B?SkIycXNRbXNRYVNkOWxmTFhLWEN0b1dJVDVIcXFBUGYycXNvQ3dVQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ba0592ce-db0d-423f-783b-08de5e515dff X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 09:41:09.8651 (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: 2XHkIPWvR25oIFEyo0Yyd8TBEo8O4pFfnPnTvJwicX7MKENxyXXkooA6AMoAoXNnu5sd4+62tRtkB7jWidXTRA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7794 On Wed, Jan 28, 2026 at 10:18:03AM +0100, Alejandro Vallejo wrote: > Hi, > > On Wed Jan 28, 2026 at 9:10 AM CET, Roger Pau Monné wrote: > > On Tue, Jan 27, 2026 at 07:24:01PM +0100, Alejandro Vallejo wrote: > >> This patch modifies CODING_STYLE to severely discourage use of copyright > >> notices when their presence is not legally mandatory. > >> > >> Copyright notices are redundant on commit, misleading from the time the file > >> receives contributions from anyone not represented by such notice, and actively > >> harmful for attribution by the time the original code is long gone. They are > >> plain wrong when added on code motion.... the list goes on. > >> > >> All attribution worth keeping is version-controlled through Signed-off-by, > >> Co-authored and the like, DCO and the cumulative contents of git history. > >> License banners have already been superseded by the contents of licenses/ and > >> SPDX tags. > >> > >> Other FOSS projects have already moved away from explicit copyright notices > >> where possible, and severely discourage their use when not. > >> > >> Apache and LLVM take active issue with copyrighted contributions and Chromium > >> takes issues with copyrighted contributions not attributed to the project. Some > >> Linux subsystem maintainers already frown upon copyright notices too, even if > >> it hasn't reached the point of being a mandated requirement yet. > >> > >> Signed-off-by: Alejandro Vallejo > >> --- > >> The actual changes are almost verbatim from the LLVM guideline, but it's not > >> exact. Wording can be adjusted as needed. I care about the core of the proposal. > >> Saying "please, drop the notice" on contributions where it's clearly not a > >> legal requirement, or have the contributor state that it is a legal requirement > >> and why. For fairness sake for all contributors to the project. > >> > >> I'd prefer taking the Apache approach for new contributions, but I want > >> some discussions to happen first. > >> > >> Thoughts? > >> > >> Relevant examples: > >> > >> - LLVM: They banned copyright notices, unless part of a vendored > >> components. > >> - Links: > >> - https://llvm.org/docs/DeveloperPolicy.html#embedded-copyright-or-contributed-by-statements > >> - Relevant quote: > >> The LLVM project does not accept contributions that include > >> in-source copyright notices except where such notices are > >> part of a larger external project being added as a vendored > >> dependency. > >> > >> - Apache: They banned optional copyright notices and relegated > >> mandatory notices to a NOTICES file that also contains an > >> Apache copyright notice. See links. > >> - Links: > >> - https://www.apache.org/legal/src-headers.html > >> - https://infra.apache.org/licensing-howto.html#mod-notice > >> - Relevant quote: > >> If the source file is submitted with a copyright notice included > >> in it, the copyright owner (or owner's agent) must either: > >> * remove such notices, or > >> * move them to the NOTICE file associated with each applicable > >> project release, or > >> * provide written permission for the ASF to make such removal > >> or relocation of the notices. > >> > >> - btrfs: They are highly discouraged. > >> - Links: > >> - https://lore.kernel.org/20220909101521.GS32411@twin.jikos.cz/ > >> - https://lwn.net/ml/linux-fsdevel/20221026074145.2be5ca09@gandalf.local.home/ > >> - https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/index.php/Developer's_FAQ.html#Copyright_notices_in_files.2C_SPDX > >> - https://lwn.net/Articles/912355/ > >> - Relevant quote: > >> Let's say it's OK for substantial amount of code. What if somebody > >> moves existing code that he did not write to a new file and adds > >> a copyright notice? We got stuck there, both sides have different > >> answer. I see it at minimum as unfair to the original code authors > >> if not completely wrong because it could appear as "stealing" > >> ownership. > >> > >> There's more cases of other projects taking similar stances. > >> --- > >> CODING_STYLE | 18 ++++++++++++++++++ > >> 1 file changed, 18 insertions(+) > >> > >> diff --git a/CODING_STYLE b/CODING_STYLE > >> index aae5a47ac2..97f80245ed 100644 > >> --- a/CODING_STYLE > >> +++ b/CODING_STYLE > >> @@ -24,6 +24,24 @@ license, e.g.: > >> > >> See LICENSES/ for a list of licenses and SPDX tags currently used. > >> > >> +Copyright notices > >> +----------------- > >> + > >> +Copyright for the code in the Xen Project is held by the respective > >> +contributors. Because you (or your company) retain ownership of the code you > >> +contribute, you know it may only be used under the terms of the open source > >> +license you contributed it under: the license for your contributions cannot be > >> +changed in the future without your approval. > > > > The usage of such direct language here, by using you to refer to the > > reader / contributor, set a different tone from the rest of the > > document. Maybe something like: > > > > "Copyright for the code in the Xen Project is held by the respective > > contributors. The author of the code is the owner of it as stated in > > the DCO. The project cannot retroactively change the copyright of > > contributions, unless explicitly accepted by all authors of the > > code." > > Ack for the tone. The particulars of the wording might need tweaking even in > this version to constraint the scope of "contribution", "the code", and so on. Yeah, it probably needs even more integration to make sure the terms used match the rest of the document. I didn't take much care into that, as I was writing this in the email reply and didn't have much context. > ----------------- > > I have the same question for you I asked Jan elsewhere. > > There's 1 question in 2 forms I'd like to have an answer to from a core > maintainers. > > Would you be willing to ack a change along these lines? > 1. to a Copyright Notice policy within CODING_STYLE. I'm fine with that. > 2. to the relegation of existing notices to a NOTICES file in the style of > Apache. Apache in particular mandates the file not be touched unless > absolutely required for legal reasons. Hm, that might be more complicated. I am however not a lawyer, don't expect the rants below to have any kind of legal base. What about the public headers in xen/include/public? I don't think we can just remove the copyright notices from those files and place them in a top level NOTICES file. Then OSes would copy the headers without the NOTICES file and end up effectively dropping the original copyright notices. Also, what about people importing files from Xen into different projects (apart from the public headers)? If we remove the copyright notices the imported files won't have them either, and people is not simply going to pickup the top level Xen NOTICES and import it into their project? How does Apache deal with people importing their code into separate projects, do they mandate the NOTICES file to also be included as part of any code import? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 28 10:17:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 10:17:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215331.1525531 (Exim 4.92) (envelope-from ) id 1vl2bZ-0001d1-06; Wed, 28 Jan 2026 10:16:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215331.1525531; Wed, 28 Jan 2026 10: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 1vl2bY-0001cu-TP; Wed, 28 Jan 2026 10:16:56 +0000 Received: by outflank-mailman (input) for mailman id 1215331; Wed, 28 Jan 2026 10: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 1vl2bW-0001co-Qx for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 10:16:55 +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 744406e4-fc32-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 11:16:48 +0100 (CET) Received: from SJ0PR05CA0176.namprd05.prod.outlook.com (2603:10b6:a03:339::31) by MN0PR12MB6199.namprd12.prod.outlook.com (2603:10b6:208:3c4::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Wed, 28 Jan 2026 10:16:43 +0000 Received: from CO1PEPF000066EA.namprd05.prod.outlook.com (2603:10b6:a03:339:cafe::3e) by SJ0PR05CA0176.outlook.office365.com (2603:10b6:a03:339::31) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.7 via Frontend Transport; Wed, 28 Jan 2026 10:16:42 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CO1PEPF000066EA.mail.protection.outlook.com (10.167.249.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Wed, 28 Jan 2026 10:16:42 +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, 28 Jan 2026 04:16:41 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 744406e4-fc32-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=siTh32O+ymmgLHmFfh2sPeasv744KN/WV0OLFnhh/gNJYB8oNvfQJIVbc5R9nAWrtUaf9JOryh+be+3R28DVHY843nZlO/by1xcXWgHtCeTZw9Fbcg2CU8k0fITWCTzIXoxJwyN5tTgdyxQfFO2LEwYhxN6HRAaZLwIOhWZdY9XbcM2APcMsG9yrU1muwp1NBXEI9xtktKZLzv4wqCx4UKRWIh7Kv0G3ZeI9sSAcWahlAkQNnkuiogATarmPX8/B4GGliRlAh/e3txXYYMFYtUrQUBBRbjM2hRf64LpNXPySVXjelrCVYOCmQAZwDk3/Oty3rtMdJ+o8MFaUi4bpWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1gzkbZR8TehbvHCJBfTvg+HQ3r9bLRvvateAZHS9M/4=; b=T6qut/if1BKg7GJvRi3jgJgckDuJnCLA7noj7BgLB1OcDEk3864X6y0Pu3LdzV6++XIca+IFUtLULqFXRaO9Dawwtt2KQ/h0LYMnDyhQXT5axylUhuLmAorw8ZdiMLBjfwx+83dGlx5APMYrSjBrnONeCTcVU5Iyrib99SBKZuS3dZOAqtd5gR/lWuQmGfBqpCrPjvvq224yTaGsjkjE7NS/43XAvdvi9EBvlCBrBtBEcuFs1LjgV2V7zQ+ozFD4ACrGxNUNT5I17eBmfE9I2mI3YTvBxgD+xRjxyNPh6Z5sQrCcI0vW0O9tuCgJb4bKdndk4MC6prNMiYJg0b6LqQ== 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=1gzkbZR8TehbvHCJBfTvg+HQ3r9bLRvvateAZHS9M/4=; b=P+h8d8gshpEAhu6W+1m90e46VVvpEQj+xgWaOJdhK1B3jlJPIUg0yZTBNBzCIbSXr4D23mjARuyIxwfUEC3RwgrcrtytAx0IpdnRe8tHtjHPQ1qOii0yfk+nXl10As7NFcAjgrnov5TcsbGqwPR4BMa92s4J1g9xjuDS1zu8OI0= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 28 Jan 2026 11:16:39 +0100 Message-ID: CC: , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , Stefano Stabellini Subject: Re: [RFC PATCH] CODING_STYLE: Establish a policy with regards to copyright notices From: Alejandro Vallejo To: =?utf-8?q?Roger_Pau_Monn=C3=A9?= X-Mailer: aerc 0.20.1 References: <20260127182403.141459-1-alejandro.garciavallejo@amd.com> In-Reply-To: X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PEPF000066EA:EE_|MN0PR12MB6199:EE_ X-MS-Office365-Filtering-Correlation-Id: 2632b302-1eab-48a4-3507-08de5e565580 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|376014|36860700013|13003099007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?TlhZZjJjS2dwTzJaOEVnb1FKc2s2TTliMEVMOXJMeDJCcEFVSFNEYjN3YWFG?= =?utf-8?B?NjJQME1uN1Y0Y0huY0dlczlNcm1La0N5Ni96NUN0VUZHR2ZJclBSNkhDWjI5?= =?utf-8?B?R25NNnlsMUh5bFVJY1lvamtwTjkvY09EWHpYcW9LWHo4eDhTeDRoS050UHBt?= =?utf-8?B?N3lLbmRZWHl2RmQvSHZUNDBzSzE0OVlkZGJmbExQWW5ucG1reG9hRG8rVXBC?= =?utf-8?B?N0dTdjFaRzdHRTlVdlhTaDNhc1RGZUNDVktyRXhzYmFLRmlKeGxnNlpDUmdS?= =?utf-8?B?eldtdlZEVytNQkhVWEQ2STl5MDFpOFFFeGZhSDJMZ3pqTkRDNFhkdG9BZmZq?= =?utf-8?B?aUltTWJIUFNZK1NUZFB4R3htQitIemF2eXdrSTRFSk93dXNvRnJualRQdDND?= =?utf-8?B?eDNiZ2pjMkxOMHBGZ2xDRFNZTzY4SFNxT0dUdTBvWW5OdmNPb09EYTN5aDNo?= =?utf-8?B?MzdNVENEalJjUTZLcGxEdkpHYzZvQWJIbitjY3FwWFRyWk5jbUJqdnZxS3VQ?= =?utf-8?B?cGJ3Mkdlb0MzOTd3OU1mNWMrQVVjK0pRbzFzajgvT2RQUEg3R1lwcXArRi9S?= =?utf-8?B?SjVraWxpelplSXpJNzhQT2UrTDlMTmtQRk55V1U2SnphL0xncnFHbGdXWUdR?= =?utf-8?B?Wmh4NXNLbDIrUGIyR0l0Y3pYTGJ3emgvMzVGSGQ3U01zNDNxVktEZnNxQk9n?= =?utf-8?B?TytyS3Y4Q0l6K2UwekFrQU1rczhXMXRzZytBa1lOTUVYSjVqUWp1Y0JWQXJy?= =?utf-8?B?Q3E4bkx5MDM5UStYUzFHTjhkL1NIazhQbWZrMlhlZUt1T1J6VkFNRjEyN0Qw?= =?utf-8?B?RkNoQ0Z6SkFSdUdYRjJNbCtjNlorUjFaRkhpRzVsWThmTVZKNUFYK2tIWHYv?= =?utf-8?B?NmZxV0cwNXJSMGo5dHhGbVp3eGhyd2ttQy9qY3BVa1BkbitELzhsTXZDQnRK?= =?utf-8?B?SW1makVkVEhFZkZwTUdOUi9OQXd2aGNlQ2VkMlFIU3JyeFZibGh4RXBiYlQ4?= =?utf-8?B?eUlzcHBQUkdlQWtFTm9tYzZVWWxMWk1HYXl4RVlrVlI5Wkp5UC9nYWtIbGRt?= =?utf-8?B?WWVmUncvTE1pZENFa2RnS052R0o3TXdkdnFuZTZub2RvWDIyUFZ1U2QzT1dR?= =?utf-8?B?M001ZlNVclFwSFIxaUxKOTA1UVd1SVE4TFAwODhoMTNHSHUxRUlpRGhLRFZ0?= =?utf-8?B?RFdrNTVDb1RTTDZCREtkcW5VbzJvVGJBdUI0VVB4eC9TY2pQbEFnWERiV01T?= =?utf-8?B?VCs1S0xiWm1GY1JCWDZyT0xrV1RieHIrQXE5SFhqZGNCZm9IZ1lQT0YzdGRR?= =?utf-8?B?MHVrekgrNWo1ZE54RE9aSVlQby9oTjJheFR0c0pjZXVKR1FJRkFkQmVhYUJO?= =?utf-8?B?NnJMQzUxcXhMRkJsS1dlRU42bzFydVo3ODdaTmtKWFR6K2tsZ2d2OWNCZllU?= =?utf-8?B?Ky8zcjR1ZkVtN21OZk5IaGFDKzFxSHFZdHJnMWtiaTdpVGw5bzgyWUlUc2Nz?= =?utf-8?B?TEk0TVY4TnlrTHVIaGlPR0xTWmtrWnU3YTNpOStvRHV0RjBIMmVWS1VLYW9t?= =?utf-8?B?VEJibDFFTHMzV0hYWmMreEczQlVFNDZZRjlHZEhCUVRDejhlb1MrY0dXUzRF?= =?utf-8?B?Ly9OcVdsMDZTQ1BGMFQ4bEY5REpDdVZ1QzRQc0g5U0I2TU92eHp4M0gxd0tv?= =?utf-8?B?NDgvdTJqZDhBSUdYbGRvVmpiOUhQNXJ1S1dYZlprTmpHWHp1TEwxMmE0YWZs?= =?utf-8?B?d21IUTJqdUhIamxWL0QzdEZKQ1h4TVhlbk5WeXNRdDhYSzRBQnJOY3llVk1w?= =?utf-8?B?Y2VSdGtoTzFKUEVPSjRKRFhZWXZhWDhVM2pFU05UdWdBd3FralZOaUMraktY?= =?utf-8?B?T2pzdXMwN3FPVi9RVEpsM3BDQjc5bDBlL2UrOXBWbExyUHkxTUxqbWErTlE2?= =?utf-8?B?WW1jdWw2ZmpWZUcrbkJHd2pZcUVZdUtwREFVbHJKRVdJOURKczZyb0hkS1RN?= =?utf-8?B?S2Jqams5RkY3a3hLVmgva1JLZUkrVlFBNUhQNW5KYnMvMXhQM2xiZmtVN0pn?= =?utf-8?B?Sk1FcHRDVVI2UldZOXdwUmZBemlWKytGeHNManEvbWd2aDBIZ1A4QitzN3hq?= =?utf-8?B?ZjBSL2pqOStMdkM1SUNaTFpYU0RPZm03L1UrK3poQXRBTE1acmtZNkQwTmhN?= =?utf-8?Q?pDeCCt8aiVUTKZs42F74TOc=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(1800799024)(376014)(36860700013)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 10:16:42.7077 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2632b302-1eab-48a4-3507-08de5e565580 X-MS-Exchange-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: CO1PEPF000066EA.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6199 On Wed Jan 28, 2026 at 10:41 AM CET, Roger Pau Monn=C3=A9 wrote: > On Wed, Jan 28, 2026 at 10:18:03AM +0100, Alejandro Vallejo wrote: >> Hi, >>=20 >> On Wed Jan 28, 2026 at 9:10 AM CET, Roger Pau Monn=C3=A9 wrote: >> > On Tue, Jan 27, 2026 at 07:24:01PM +0100, Alejandro Vallejo wrote: >> >> This patch modifies CODING_STYLE to severely discourage use of copyri= ght >> >> notices when their presence is not legally mandatory. >> >>=20 >> >> Copyright notices are redundant on commit, misleading from the time t= he file >> >> receives contributions from anyone not represented by such notice, an= d actively >> >> harmful for attribution by the time the original code is long gone. T= hey are >> >> plain wrong when added on code motion.... the list goes on. >> >>=20 >> >> All attribution worth keeping is version-controlled through Signed-of= f-by, >> >> Co-authored and the like, DCO and the cumulative contents of git hist= ory. >> >> License banners have already been superseded by the contents of licen= ses/ and >> >> SPDX tags. >> >>=20 >> >> Other FOSS projects have already moved away from explicit copyright n= otices >> >> where possible, and severely discourage their use when not. >> >>=20 >> >> Apache and LLVM take active issue with copyrighted contributions and = Chromium >> >> takes issues with copyrighted contributions not attributed to the pro= ject. Some >> >> Linux subsystem maintainers already frown upon copyright notices too,= even if >> >> it hasn't reached the point of being a mandated requirement yet. >> >>=20 >> >> Signed-off-by: Alejandro Vallejo >> >> --- >> >> The actual changes are almost verbatim from the LLVM guideline, but i= t's not >> >> exact. Wording can be adjusted as needed. I care about the core of th= e proposal. >> >> Saying "please, drop the notice" on contributions where it's clearly = not a >> >> legal requirement, or have the contributor state that it is a legal r= equirement >> >> and why. For fairness sake for all contributors to the project. >> >>=20 >> >> I'd prefer taking the Apache approach for new contributions, but I wa= nt >> >> some discussions to happen first. >> >>=20 >> >> Thoughts? >> >>=20 >> >> Relevant examples: >> >>=20 >> >> - LLVM: They banned copyright notices, unless part of a vendored >> >> components. >> >> - Links: >> >> - https://llvm.org/docs/DeveloperPolicy.html#embedded-copyright= -or-contributed-by-statements >> >> - Relevant quote: >> >> The LLVM project does not accept contributions that include >> >> in-source copyright notices except where such notices are >> >> part of a larger external project being added as a vendored >> >> dependency. >> >>=20 >> >> - Apache: They banned optional copyright notices and relegated >> >> mandatory notices to a NOTICES file that also contains an >> >> Apache copyright notice. See links. >> >> - Links: >> >> - https://www.apache.org/legal/src-headers.html >> >> - https://infra.apache.org/licensing-howto.html#mod-notice >> >> - Relevant quote: >> >> If the source file is submitted with a copyright notice inclu= ded >> >> in it, the copyright owner (or owner's agent) must either: >> >> * remove such notices, or >> >> * move them to the NOTICE file associated with each applica= ble >> >> project release, or >> >> * provide written permission for the ASF to make such remov= al >> >> or relocation of the notices. >> >>=20 >> >> - btrfs: They are highly discouraged. >> >> - Links: >> >> - https://lore.kernel.org/20220909101521.GS32411@twin.jikos.cz/ >> >> - https://lwn.net/ml/linux-fsdevel/20221026074145.2be5ca09@gand= alf.local.home/ >> >> - https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/inde= x.php/Developer's_FAQ.html#Copyright_notices_in_files.2C_SPDX >> >> - https://lwn.net/Articles/912355/ >> >> - Relevant quote: >> >> Let's say it's OK for substantial amount of code. What if someb= ody >> >> moves existing code that he did not write to a new file and add= s >> >> a copyright notice? We got stuck there, both sides have differe= nt >> >> answer. I see it at minimum as unfair to the original code auth= ors >> >> if not completely wrong because it could appear as "stealing" >> >> ownership. >> >>=20 >> >> There's more cases of other projects taking similar stances. >> >> --- >> >> CODING_STYLE | 18 ++++++++++++++++++ >> >> 1 file changed, 18 insertions(+) >> >>=20 >> >> diff --git a/CODING_STYLE b/CODING_STYLE >> >> index aae5a47ac2..97f80245ed 100644 >> >> --- a/CODING_STYLE >> >> +++ b/CODING_STYLE >> >> @@ -24,6 +24,24 @@ license, e.g.: >> >> =20 >> >> See LICENSES/ for a list of licenses and SPDX tags currently used. >> >> =20 >> >> +Copyright notices >> >> +----------------- >> >> + >> >> +Copyright for the code in the Xen Project is held by the respective >> >> +contributors. Because you (or your company) retain ownership of the = code you >> >> +contribute, you know it may only be used under the terms of the open= source >> >> +license you contributed it under: the license for your contributions= cannot be >> >> +changed in the future without your approval. >> > >> > The usage of such direct language here, by using you to refer to the >> > reader / contributor, set a different tone from the rest of the >> > document. Maybe something like: >> > >> > "Copyright for the code in the Xen Project is held by the respective >> > contributors. The author of the code is the owner of it as stated in >> > the DCO. The project cannot retroactively change the copyright of >> > contributions, unless explicitly accepted by all authors of the >> > code." >>=20 >> Ack for the tone. The particulars of the wording might need tweaking eve= n in >> this version to constraint the scope of "contribution", "the code", and = so on. > > Yeah, it probably needs even more integration to make sure the terms > used match the rest of the document. I didn't take much care into > that, as I was writing this in the email reply and didn't have much > context. > >> ----------------- >>=20 >> I have the same question for you I asked Jan elsewhere. >>=20 >> There's 1 question in 2 forms I'd like to have an answer to from a core >> maintainers. >>=20 >> Would you be willing to ack a change along these lines? >> 1. to a Copyright Notice policy within CODING_STYLE. > > I'm fine with that. > >> 2. to the relegation of existing notices to a NOTICES file in the styl= e of >> Apache. Apache in particular mandates the file not be touched unles= s >> absolutely required for legal reasons. > > Hm, that might be more complicated. I am however not a lawyer, don't > expect the rants below to have any kind of legal base. Neither am I, for the public record. > > What about the public headers in xen/include/public? I don't think we > can just remove the copyright notices from those files and place them > in a top level NOTICES file. Then OSes would copy the headers > without the NOTICES file and end up effectively dropping the original > copyright notices. > > Also, what about people importing files from Xen into different > projects (apart from the public headers)? If we remove the copyright > notices the imported files won't have them either, and people is not > simply going to pickup the top level Xen NOTICES and import it into > their project? > > How does Apache deal with people importing their code into separate > projects, do they mandate the NOTICES file to also be included as part > of any code import? They do. It's part of the Apache license. See point 4.d: https://www.apache.org/licenses/LICENSE-2.0 This would require some sort of ammendment to xen/COPYING. OTOH, to avoid being a PITA to Linux and others by changing how we do thing= s it'd be sensible to keep the existing headers on everything under xen/inclu= de/ public/ for being-a-good-citizen reasons. Anyone actively copying an internal file (say, msi.c) would thus be forced = to also copy NOTICES, but that's a heck of a lot rarer and not much to ask. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Wed Jan 28 10:28:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 10:28:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215344.1525540 (Exim 4.92) (envelope-from ) id 1vl2me-0003US-3Z; Wed, 28 Jan 2026 10:28:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215344.1525540; Wed, 28 Jan 2026 10:28: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 1vl2me-0003UL-11; Wed, 28 Jan 2026 10:28:24 +0000 Received: by outflank-mailman (input) for mailman id 1215344; Wed, 28 Jan 2026 10:28: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 1vl2mc-0003UF-Fh for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 10:28:22 +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 10f7e82f-fc34-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 11:28:20 +0100 (CET) Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-43284ed32a0so3962255f8f.3 for ; Wed, 28 Jan 2026 02:28:20 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e1353ac2sm6226895f8f.38.2026.01.28.02.28.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 02:28:19 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 10f7e82f-fc34-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769596100; x=1770200900; 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=o6wFVRpPscyB9+c8KRg4316MWvHqo0AwSXFaSjSoKG4=; b=Gd54N1TeMEolGE71gEZ9f+jq/+M+OwMpPCvpOLNwzmLlkiSEzKGkcjP2qcEByG52Ao 5LlHX9kf/8zIMNWgQY831aTVv9dIgx1rm6RGU2WjO+uWfiN4sDDMQ0U3UZPt8RAVNAEG hd47Mwyzq2FVCXb64eDXaqbm/u+xIUeudS0sSdnAuLS6y3TZdPs92HzQB4Rdnj3drKC3 2HJktj95UqnASWAsuMu4lJPDL33tUIe6+EyA7yWGd5FIxPJtjCPULFxAJpyO2Y/WzVhm YJsJMeTL1iZ2x1pCm9WLxbBt6ia03nX8+RFKtajDRO82x+qsZRejtuW5iSXecu2tvoce u/mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769596100; x=1770200900; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=o6wFVRpPscyB9+c8KRg4316MWvHqo0AwSXFaSjSoKG4=; b=V3SLR4ICPbi83/FMUZ2oXbEKNsfZFlDXe/ghadPCk1+fogyyRMuwNEFjw71Hwh/PlZ u3wU/Kd4C5WpzFXSLGUWcLhjVrc0RMq6KzT5NN7jPTOzyPm389/QHsdDD1cF72emXWRF qjuc5TcXMbF3YYFi98F63qg1apienAwmFuZP51opNOmZ/wp8J+3zLQG35cVbH5X1cIHJ +F8Mj9VyDyy4nstKPn9Wl9iAY2ctnzpHgdxcfc6FM8uHPCm4t9r22xVq9CUb3b/05ERi xp5QQsyNz1l0ZuZ0xY15YtzA8uonQmt2waMeGw8gYOCCSWRZEw56h8aeIkMItED5I9Pl VmMQ== X-Forwarded-Encrypted: i=1; AJvYcCW1FRv9jPlxtFBa6zfgT9JlEqf/hq9enxBWaBSf6T7Kh51Tsp4Mbv1F9I0FvgVQuortgIrDEXalBJw=@lists.xenproject.org X-Gm-Message-State: AOJu0YzQqIWPH50gWHkNcxKPDoX3Wz/uIEhd9OvkKzf6kOA5FaojvR+H nGJCqq9tuv13PguDvbDXqkCUkNnX3qBJl4efMz7Zdi08a4lXjdzkGRB6 X-Gm-Gg: AZuq6aI+JbltYM0s1WigfzVTEb/G82ThiXAbRYM1KsbDNmTLQZ6xCdABjOCINlijaXo nFE8CMrbSOc0rkcQJ7K88pCCez1ZzYuHkxFV0EsHlL7tcQZpklmu10Co/qz6xJZfMxobopCHi9B BBCLhjTUTfrBJSUyOQ1JImygAWMvdvDnQfCd9wMJO+nkDjag73q1tLY7eZgtXHOO3EuEdeGmScY Rz1CID3OnQn5yTEhwJvb5iwJHqNU7MVqeqVn6dNk8HhWRjHPhfLeYUiJl67LeEFcKN7FfDq758A pWx310OrrnSwx0VqH+g9JjUnIDH4DFsLULA2M8qqLzgLOtXd33K+dd6wzOflQasSvzEXzX4Oy/h Xg0lPNJ1TI6WQrcDUhWJ2urYhKaJCLBwe6ExFQ8vw2su9LcupISPuQ9ud9clNSlP4ctr0jNAHkz i3lvht3OK7Q1NtLL0c4WR5fF5m0WS53CfrXvYiCsHLjlP0kHu8ucWOIPjfHtKFHoM= X-Received: by 2002:a05:6000:4023:b0:431:a33:d87c with SMTP id ffacd0b85a97d-435dd02da7dmr7337199f8f.11.1769596099484; Wed, 28 Jan 2026 02:28:19 -0800 (PST) Message-ID: Date: Wed, 28 Jan 2026 11:28:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] xen/riscv: dump GPRs and CSRs on unexpected traps To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <27ab0f8eb6fd6ecef1eeefa4a05e4fe1f43acbbe.1769427484.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/27/26 10:14 AM, Jan Beulich wrote: > On 26.01.2026 12:43, Oleksii Kurochko wrote: >> Provide additional context when an unexpected exception occurs by dumping >> the relevant Supervisor, Virtual Supervisor (VS), and Hypervisor CSRs, >> along with the general-purpose registers associated with the trap. >> >> Dumping VS-mode CSRs in addition to host CSRs is beneficial when analysing >> VS-mode traps. VSCAUSE, VSEPC, VSTVAL, and related VS state are required to >> properly diagnose unexpected guest traps and potential hypervisor >> misconfiguration. >> For example, on an illegal-instruction exception the hardware may record >> the faulting instruction in VSTVAL. If VSTVAL is zero, VSEPC should always >> be inspected, and can be used together with objdump to identify the >> faulting instruction. Dumping VSCAUSE is also useful when the guest does >> not report it, or when the hypervisor redirects a trap to the guest using >> VSCAUSE, VSTATUS, and VSTVEC, allowing verification that a subsequent trap >> is not caused by incorrect VS state. >> >> Signed-off-by: Oleksii Kurochko > Acked-by: Jan Beulich > > I still have a question though, which can be addressed incrementally. > >> --- a/xen/arch/riscv/traps.c >> +++ b/xen/arch/riscv/traps.c >> @@ -99,12 +99,70 @@ static const char *decode_cause(unsigned long cause) >> return decode_trap_cause(cause); >> } >> >> +static void dump_general_regs(const struct cpu_user_regs *regs) >> +{ >> +#define X(regs, name, delim) \ >> + printk("%-4s: %016lx" delim, #name, (regs)->name) >> + >> + X(regs, ra, " "); X(regs, sp, "\n"); >> + X(regs, gp, " "); X(regs, tp, "\n"); >> + X(regs, t0, " "); X(regs, t1, "\n"); >> + X(regs, t2, " "); X(regs, s0, "\n"); >> + X(regs, s1, " "); X(regs, a0, "\n"); >> + X(regs, a1, " "); X(regs, a2, "\n"); >> + X(regs, a3, " "); X(regs, a4, "\n"); >> + X(regs, a5, " "); X(regs, a6, "\n"); >> + X(regs, a7, " "); X(regs, s2, "\n"); >> + X(regs, s3, " "); X(regs, s4, "\n"); >> + X(regs, s5, " "); X(regs, s6, "\n"); >> + X(regs, s7, " "); X(regs, s8, "\n"); >> + X(regs, s9, " "); X(regs, s10, "\n"); >> + X(regs, s11, " "); X(regs, t3, "\n"); >> + X(regs, t4, " "); X(regs, t5, "\n"); >> + X(regs, t6, " "); X(regs, sepc, "\n"); > Does this sepc value differ from ... > >> +static void dump_csrs(unsigned long cause) >> +{ >> +#define X(name, csr, fmt, ...) \ >> + v = csr_read(csr); \ >> + printk("%-10s: %016lx" fmt, #name, v, ##__VA_ARGS__) >> + >> + unsigned long v; >> + >> + X(htval, CSR_HTVAL, " "); X(htinst, CSR_HTINST, "\n"); >> + X(hedeleg, CSR_HEDELEG, " "); X(hideleg, CSR_HIDELEG, "\n"); >> + X(hstatus, CSR_HSTATUS, " [%s%s%s%s%s%s ]\n", >> + (v & HSTATUS_VTSR) ? " VTSR" : "", >> + (v & HSTATUS_VTVM) ? " VTVM" : "", >> + (v & HSTATUS_HU) ? " HU" : "", >> + (v & HSTATUS_SPVP) ? " SPVP" : "", >> + (v & HSTATUS_SPV) ? " SPV" : "", >> + (v & HSTATUS_GVA) ? " GVA" : ""); >> + X(hgatp, CSR_HGATP, "\n"); >> + X(hstateen0, CSR_HSTATEEN0, "\n"); >> + X(stvec, CSR_STVEC, " "); X(vstvec, CSR_VSTVEC, "\n"); >> + X(sepc, CSR_SEPC, " "); X(vsepc, CSR_VSEPC, "\n"); > ... the one logged here? Nothing changes the register between entry > into the hypervisor and coming here? You are right, the value will be the same. Lets drop printing of SEPC from GPRS and leave only the printing of SEPC in dump_csrs(). ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Jan 28 10:31:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 10:31:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215352.1525550 (Exim 4.92) (envelope-from ) id 1vl2po-0004zS-HA; Wed, 28 Jan 2026 10:31:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215352.1525550; Wed, 28 Jan 2026 10: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 1vl2po-0004zL-E7; Wed, 28 Jan 2026 10:31:40 +0000 Received: by outflank-mailman (input) for mailman id 1215352; Wed, 28 Jan 2026 10: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 1vl2pn-0004zF-Qh for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 10:31:39 +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 849aca90-fc34-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 11:31:34 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by PH7PR03MB6971.namprd03.prod.outlook.com (2603:10b6:510:12e::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Wed, 28 Jan 2026 10:31:30 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.006; Wed, 28 Jan 2026 10:31: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: 849aca90-fc34-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=hRejn8p3mcbJ0EEjmdEV0T1tQnRLq+QExxy/aci13OkCh+MN7dc/N2aKZS2QOLCn9lhTndoBefWLaudyDjq6t1oKldHC11Sk5Ao/DNjtyzXwvSpMPKYIoP7x9pEXe8P+zPaM+Oq8tPJoha+D1gSRRsyzHIi6ti44R+iJyZl3MxrS4LL5OMgTKXrgJKlLr50Bqn92iZ6C6+HbDUEJWb3WjBHsiYJlf3rPTYx4OFi4wqJrJODOnCG6sgQUw5hD88pgYmZjKjZ+IET9j2NyIo0WmGNO2dp9sj/elnYFEvVfIhvvr6NCgWnXfvBDncEvZc2CdiQ9iGDeZQ0JhpxcavnwNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pQBTXLz/b3hK4vODRGQJoS4ez4gWttWrXtaYtuOrxI0=; b=LWUiiEFfftCahSmHYpG+ZuI29ya5WYaGagUXNCkJ5Bkvvpd5Mp6X9m+EGwjpxBSqJdLAusk5T9cIQ20tDmvF1vlublnk1/45mZD56xMC6/zym6aa5VrmE+hR0JjCav1l1kuyF2mqpaME6RJZo2scJJ43yqbMM1tUa03ihpVJwfGBfqU5ctJwU/siKl8Z+uchUyIzaA6ftNi7hHaPvDinTnrlZS381vJQtOgCrYr5+amok8fIg5EvUPgCbCuiPjcEldhJI7LesToBKJSF/sR49i8jxTVLaB6ucH3aX6wt2NwIImf9Y0B6nd0fP5gECf0gxzu9tefroschlJt/3Y5xAA== 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=pQBTXLz/b3hK4vODRGQJoS4ez4gWttWrXtaYtuOrxI0=; b=eTvk8zAPq8LaAl24TcCnLTr+7YWy6UszyWHIPjbBYQG+jHw1/XpbpYsWE0EM3v7rRtw8hV/vuKcYN+ZcxMOwkJj8XxnALS3d/BFDD9zs1bm3xwOPDWw3TFtX+5RJVldeI3dcbcuDnN7uPL6AkVXAo1m3byGOALQt5ZMeqRbKoc0= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 28 Jan 2026 11:31:26 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Alejandro Vallejo Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: Re: [RFC PATCH] CODING_STYLE: Establish a policy with regards to copyright notices Message-ID: References: <20260127182403.141459-1-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: MR1P264CA0031.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:2f::18) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|PH7PR03MB6971:EE_ X-MS-Office365-Filtering-Correlation-Id: cb1ff30d-edb3-463e-8ec9-08de5e586656 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?ZVFTNlk1U2FWNUwyVjhLSHdWbGZQYTRZV2ZBNmxTejJIN25UU0FwTHJOMWRB?= =?utf-8?B?MUsxc29qK2UrQzQrSUpDN0tVSlRrci9ibEFWVlFjZko5MnVXUVZ1UnoyOE9m?= =?utf-8?B?ZDZCSTZ4Snp4RU52OGVIa3YzaHFaTC9ZWDlWUVd1RVFJb0gwM0ZibmRuckwr?= =?utf-8?B?cGVRZGh5bndUTnNkdzBaZzZJQ1ZGZUJ4Wll4UkFLelRCUHNQdHhYaWJVWkhR?= =?utf-8?B?UU5iaVFKK0pvQmpZT2dMOXVBVnZ6SVZORmpBS3hhSFgwNTVIMjB5OWkyY0N3?= =?utf-8?B?NS9FK1d6bHIwNzZjWXl3Q2o4Y2lOMVpSZUNJVmpmQmJVbXR2YlZrcjJRODRV?= =?utf-8?B?L2dyMy9FU3ZzdFJKOVk0Tm1udWNhSjFaM1pwUThtOEZjbUp6QkdVd0F1ay9l?= =?utf-8?B?N0ZJRTZleEJqVDhvTTRzR0tEekVBS1l2UHJqdGlLOEVOdVZWKzl1M3FPV2R6?= =?utf-8?B?UHNleVBlV1UxT1dmdmExZ25USHZKWWtCWTdzeEx4ai9GMTV6SVZHMkx4ZmlS?= =?utf-8?B?Slg0QVFTUldsZW0rTzlJZWlzcStqOGxnS0IrT09TOVJlU1BOWTRneTVMTVpt?= =?utf-8?B?aitJQjQ0aG9ORXJuZkJ4VHhkUDVxazExWXM1QStUc3dlUFVqdzhua2EvU2I1?= =?utf-8?B?RnQzbzhDcENYS1lERnZNVndlRWUzY21CdGhralR5RGk1aXpHb0lqZTdiMCtv?= =?utf-8?B?NzdKMmtud29oNVIyWkM5eitXMnF6dUhoSXdlcjF3cDBMWmRvRjBSUzA2V04z?= =?utf-8?B?MnU3YlMvd0VxK3VXZXU2WE5SWXpxZ3k1UHM4UDhtM3BOdFNTNlFMMnVSTXZS?= =?utf-8?B?bVZmMjJ1a3hnNGVIckxKWUVTWkhBMzhCY3BMWnNnVnN0aEJQL1JhdFBzZ3Ry?= =?utf-8?B?Nml6T1hWaFFMTCtuL3p3RWVWNDBneHhYZXNzRFBFWndrT0JlRFk0U3VqK2du?= =?utf-8?B?M3dPVW5QS254SkJrell5ajZsTjZYaU5STEtIMUcrdzk0OVE4UVJpeS8rc09o?= =?utf-8?B?dWdlMkxRTmQyZVNiTDZHSnZ2UUtHbmNqek03VmdPZkZNTHdyRXNFMnBQTDNT?= =?utf-8?B?djZGTjVHZmI0SzNpVDdxdnBCS0lGNUNuYWtPU0RsczVndEV3Z3ZRbDdoQWpx?= =?utf-8?B?OE1wWk4xcTc1YWR2aFQxdm4zaytLMVlFTVlUcUdUS1ZHQjVva2FZRExIZndW?= =?utf-8?B?Ly9rMGIxRFdqdEFjNDFqczExRTg2dnM0TjdIbTUvVlN2VjRPZUNrMVJwRU51?= =?utf-8?B?VXRXbml0eGRUa2xqT3A0WEhCUTFMSWZEK0RGTmFvOTVDTzBrMURGVHFVeThW?= =?utf-8?B?N1RBSnI5bmVXMGt1YzJsK3JJOVA5RFAzd1pUajVDQ0Fvbm9mOFZnSjhHTEhP?= =?utf-8?B?NHJnMklLblozZWlXK3cxY243OE9LeUJLcjl4aFZiTng1RHpBSE9oYldhdXM3?= =?utf-8?B?Q1Ztd1hzRm5DNlAxYXFYd0RtM1JKQjlsQXQyTmtZZ0w0cmE4VWh2RjN0c3NV?= =?utf-8?B?VTlleXR3NWdIbG1jTDduQ21wb0EvbnM4RzhjWkpkaXBEQlBiRktDaUQ2cldV?= =?utf-8?B?ZEdHNlErQkFrc1NJd1JsQ3dFMTEyR01TZHhTV0tyV0s3ZzdGcU50SlFvZkpF?= =?utf-8?B?T09aYzRJNFBmaVJ5ODhORGhWUjl3OGhKRGRLZmNxUWRobEFiZzQwT3FNNEZq?= =?utf-8?B?OFNwdHlwVFIremVRZjhHZDNhMW4xcERheE9LTWZxbU16L21UbVZKdzMrV1My?= =?utf-8?B?TGNnS3N4QmNBUnJNRHF6UGxMalBmdFFxTFU3b3EzWDMxd1hCeWR0cXkvMHBI?= =?utf-8?B?OWVJNGRKb0luMGZCaWNTOTU2UnhPcmV2NjNxVkpLdHoxTU5ST3dDMzFuTWpG?= =?utf-8?B?aHBSMEZLMzgvV0M4OUtRRnV3YkFqamxPd1diaTFzalRUNSs5aDg3TTl2Uk52?= =?utf-8?B?b09rREtPWWNENFplTk9EREN2WUlxdmtpdXFZSHB4ZGVsVUpBWnBhd2R1UWI0?= =?utf-8?B?TWlRWlhIWlFZWEp3ZjhkM3VpcFVjVVlKTUw3UXVCak9NU1B5aWc1T1dhMHAv?= =?utf-8?Q?zmfDXr?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?R0Y3dnJkeTJndWhzd2VEeUkvSDM2YWNoMVZtWEhFNkR0N3BoaEtUOFgvTTRr?= =?utf-8?B?TmFLVm8wdXZHMUhjRFFpMDJaalFxUmg4RjUxZ0ZHTVhuZVdOQytoWDdOdUxx?= =?utf-8?B?VmlQZlAzVWZiWit3SktyNWxaejEzdnoxcXRoR3pOY3lqTndqMGVEYWJqM0dk?= =?utf-8?B?eGFFZmJKb1ZDMzN6Qys4SnVKMjRBVXRlQmkvVnF2UE5GSVJ6ZXpyU0JHK3RT?= =?utf-8?B?OVlpMDdIYjkzYzBIY3IrZk9SUE1VM0pRZStEaTQrWEtNaGw3ZW9OQzFZRGp1?= =?utf-8?B?UCtPU1JKVmpqZDhHYlhHejI0N2tDc3loYTBESDdVcmY0cHExVDRRL2h5Qzky?= =?utf-8?B?WWprUHFTS1BxV0I3Vmt3NjJFYW5TZ2dKNmh3cnVjanBWb1VzZjBRanRTdEw0?= =?utf-8?B?bm9OSXZkNXRxeko4VTh5RVlGdU5jaWIvTWpjQVZzRlFhQmxJQXNrNDFRT2Ux?= =?utf-8?B?TFo3L09hTndzM1ZZM25rMjYrNkJVUmJDWDAzbVpYbkV1WHZma2VNb1JkNGV3?= =?utf-8?B?WHp4cUR4Slg0WmFhUktCNzcvSzdLWTR2dDJwdlF3U0sxTk1CelBjekxmNzda?= =?utf-8?B?RmZQVjI4VDhQOGZ3VzFIc1JHL0wxMGV1MnFDeDU3cFhsS1RFK1dVNVZHd0lH?= =?utf-8?B?aWpIOHNxbGhGKzNzUm8vb0dWL0dvektqazl5REVoL0ZQa3VBV2tubTNia0Ev?= =?utf-8?B?TFIveEQ5cnZPb2F5OWxvbExqSWRhQks2NGhpa25wRlVwM0ZIdmpFR0JhMlJM?= =?utf-8?B?SjJ0Nk5UUWtFcTUzQlRKUDduZThUeDFvMmVXK3JzRjRaUXIzUVB5VkhXNXd2?= =?utf-8?B?T0ljQWlLQUd2SkQxbW1VaDI1ZWlQSXBGMHE3bDV4NmoyQnZEclY5Z1B2OGJ4?= =?utf-8?B?SHB1T1lYOC9PR09ueEpSWWhYSkFlTU9UcmRiVUVnNDk2ZHhwKzhDN2ZlSEN1?= =?utf-8?B?U1dzQ2pGVnBJUGo5L1dHbmhwdUQvSFR3Zkw4WW5GY29ySDMxT3kvaVo3eTk2?= =?utf-8?B?S3p2a29LRlN6Ny9qcm1aRVVjSlRTbHI3UkhUWHlWV2hqRy8vdWl4NjRIbnBT?= =?utf-8?B?MHN0bVVEZnVMd2JFMmtSTVFuYmxxY1hRcnhVbWNzcVU0cEt3aGxOMGdLeGYw?= =?utf-8?B?REpwRlVpNGtzYXpXV2VyRkpHcTNuTFQvWjJtT21NdmFOUURSUDJuanMwa3Fo?= =?utf-8?B?MTVUN2NtWEUvRVpOVEFaNmMzUWxQVWdSTE5ROFYxRDNNMit1dTBabm9SVWwx?= =?utf-8?B?ci9mR1pFSVFxb0tuMWtuaXpzMXV2bkJ6SnpBK2lra3ljNEFVTVozSFpHM1B2?= =?utf-8?B?Y0RBQWF2aE82Wld6OHRROHZCUDZGMVU0TXFHR1BHRklXMUxnVjhjaFdPNVY2?= =?utf-8?B?VFg0ZEVIalg1QzFHOS9xa3dpZEFMeFlSU3hqcEx6QnVpNW5QYXJ6eEJHZ3ho?= =?utf-8?B?QnI4N0VHbS9Nd2pIMkxQVkF5TzdLVkhMYkdwb0tWN0EwUWZ2NmdjeGV1SzFK?= =?utf-8?B?ZEdzOEVibUJreUM0cnNpaEdTV1NtMzM5MEdrREZ6UEpHZy9HRDdTb1o4QzRm?= =?utf-8?B?SHlGdjlaa3FBL0xMN2x3QWh0Rkp5WDFVSXlPSFBUaGxORlNSQ3JOV3JMc3hH?= =?utf-8?B?a3B0NE1vWlNHd3RTbnNDaWxXWFpWcU1ycXpIcDZzN1pHRVYyYWxJWGhrYk1n?= =?utf-8?B?WmRQY1RNRlY5aGJYbysrUzJkY1A3NW1SNTlYcnVkMXJqamNNWjN1djBRQmVW?= =?utf-8?B?VUdWQ09mUG9LRzVPdzE5ZzQwTU1YcHNDQlBCaHNJWGh4eHhNUVFVazJ2akQ4?= =?utf-8?B?VjNhTmJiRVNGMXVENWcweERxekNhTTg0K09jczRWWXQzRFB2bnpBVm0zOXhz?= =?utf-8?B?ZzdEQmFuQzE1MXI2NVdrTXFneGQ2d2laUjNBaVVNeGJmMmY1Y09BbEYxc256?= =?utf-8?B?Njg1ajY1NUlJWkJiMXdyUVlLZ1ZlYU5tcDVlOVhaNjNicUhJUGpISk14VDBM?= =?utf-8?B?b2tpL0FqdzZHamlWQkMzQThhTENSdWtvcVNkSU8xNnJ1QmV1cnQwbUxSZmVo?= =?utf-8?B?d1YzSkkreUJ2RjJTTlVLdDhVMG5lYnVtN1Fid0JDMjc1Rys4R1NGU1dkSmox?= =?utf-8?B?OURmV0l5R1MrUkJWaFM4MS9vbngyS0xWUFFucng5RDRMN2JNcm1GWi9heFYw?= =?utf-8?B?MlUvUkdTOU9ud1BqYXdVNUVBYmRSbjBkM3NlSGdSTTBDa3hvM2c5TnJSU1Jx?= =?utf-8?B?L0I5NU43V09aRmFMNm8yb2FzenVKMldSbjdNVWVNVXdUaUlrWmRDRE5FMHpr?= =?utf-8?B?dHgxaXd3NW1TN1RwQ2JMc0lLRVpFeFRMQlVXZTErVWFoaU1Hc1pXZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: cb1ff30d-edb3-463e-8ec9-08de5e586656 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 10:31:30.2208 (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: el6+7VjP/y9g526FjkxpQ6KPDueT+d8uYh0+O3vvdINyArYuopdrVSlYMpT+wG4DJwCgmLKJdf2oPccljSnDgg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR03MB6971 On Wed, Jan 28, 2026 at 11:16:39AM +0100, Alejandro Vallejo wrote: > On Wed Jan 28, 2026 at 10:41 AM CET, Roger Pau Monné wrote: > > On Wed, Jan 28, 2026 at 10:18:03AM +0100, Alejandro Vallejo wrote: > >> Hi, > >> > >> On Wed Jan 28, 2026 at 9:10 AM CET, Roger Pau Monné wrote: > >> > On Tue, Jan 27, 2026 at 07:24:01PM +0100, Alejandro Vallejo wrote: > >> >> This patch modifies CODING_STYLE to severely discourage use of copyright > >> >> notices when their presence is not legally mandatory. > >> >> > >> >> Copyright notices are redundant on commit, misleading from the time the file > >> >> receives contributions from anyone not represented by such notice, and actively > >> >> harmful for attribution by the time the original code is long gone. They are > >> >> plain wrong when added on code motion.... the list goes on. > >> >> > >> >> All attribution worth keeping is version-controlled through Signed-off-by, > >> >> Co-authored and the like, DCO and the cumulative contents of git history. > >> >> License banners have already been superseded by the contents of licenses/ and > >> >> SPDX tags. > >> >> > >> >> Other FOSS projects have already moved away from explicit copyright notices > >> >> where possible, and severely discourage their use when not. > >> >> > >> >> Apache and LLVM take active issue with copyrighted contributions and Chromium > >> >> takes issues with copyrighted contributions not attributed to the project. Some > >> >> Linux subsystem maintainers already frown upon copyright notices too, even if > >> >> it hasn't reached the point of being a mandated requirement yet. > >> >> > >> >> Signed-off-by: Alejandro Vallejo > >> >> --- > >> >> The actual changes are almost verbatim from the LLVM guideline, but it's not > >> >> exact. Wording can be adjusted as needed. I care about the core of the proposal. > >> >> Saying "please, drop the notice" on contributions where it's clearly not a > >> >> legal requirement, or have the contributor state that it is a legal requirement > >> >> and why. For fairness sake for all contributors to the project. > >> >> > >> >> I'd prefer taking the Apache approach for new contributions, but I want > >> >> some discussions to happen first. > >> >> > >> >> Thoughts? > >> >> > >> >> Relevant examples: > >> >> > >> >> - LLVM: They banned copyright notices, unless part of a vendored > >> >> components. > >> >> - Links: > >> >> - https://llvm.org/docs/DeveloperPolicy.html#embedded-copyright-or-contributed-by-statements > >> >> - Relevant quote: > >> >> The LLVM project does not accept contributions that include > >> >> in-source copyright notices except where such notices are > >> >> part of a larger external project being added as a vendored > >> >> dependency. > >> >> > >> >> - Apache: They banned optional copyright notices and relegated > >> >> mandatory notices to a NOTICES file that also contains an > >> >> Apache copyright notice. See links. > >> >> - Links: > >> >> - https://www.apache.org/legal/src-headers.html > >> >> - https://infra.apache.org/licensing-howto.html#mod-notice > >> >> - Relevant quote: > >> >> If the source file is submitted with a copyright notice included > >> >> in it, the copyright owner (or owner's agent) must either: > >> >> * remove such notices, or > >> >> * move them to the NOTICE file associated with each applicable > >> >> project release, or > >> >> * provide written permission for the ASF to make such removal > >> >> or relocation of the notices. > >> >> > >> >> - btrfs: They are highly discouraged. > >> >> - Links: > >> >> - https://lore.kernel.org/20220909101521.GS32411@twin.jikos.cz/ > >> >> - https://lwn.net/ml/linux-fsdevel/20221026074145.2be5ca09@gandalf.local.home/ > >> >> - https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/index.php/Developer's_FAQ.html#Copyright_notices_in_files.2C_SPDX > >> >> - https://lwn.net/Articles/912355/ > >> >> - Relevant quote: > >> >> Let's say it's OK for substantial amount of code. What if somebody > >> >> moves existing code that he did not write to a new file and adds > >> >> a copyright notice? We got stuck there, both sides have different > >> >> answer. I see it at minimum as unfair to the original code authors > >> >> if not completely wrong because it could appear as "stealing" > >> >> ownership. > >> >> > >> >> There's more cases of other projects taking similar stances. > >> >> --- > >> >> CODING_STYLE | 18 ++++++++++++++++++ > >> >> 1 file changed, 18 insertions(+) > >> >> > >> >> diff --git a/CODING_STYLE b/CODING_STYLE > >> >> index aae5a47ac2..97f80245ed 100644 > >> >> --- a/CODING_STYLE > >> >> +++ b/CODING_STYLE > >> >> @@ -24,6 +24,24 @@ license, e.g.: > >> >> > >> >> See LICENSES/ for a list of licenses and SPDX tags currently used. > >> >> > >> >> +Copyright notices > >> >> +----------------- > >> >> + > >> >> +Copyright for the code in the Xen Project is held by the respective > >> >> +contributors. Because you (or your company) retain ownership of the code you > >> >> +contribute, you know it may only be used under the terms of the open source > >> >> +license you contributed it under: the license for your contributions cannot be > >> >> +changed in the future without your approval. > >> > > >> > The usage of such direct language here, by using you to refer to the > >> > reader / contributor, set a different tone from the rest of the > >> > document. Maybe something like: > >> > > >> > "Copyright for the code in the Xen Project is held by the respective > >> > contributors. The author of the code is the owner of it as stated in > >> > the DCO. The project cannot retroactively change the copyright of > >> > contributions, unless explicitly accepted by all authors of the > >> > code." > >> > >> Ack for the tone. The particulars of the wording might need tweaking even in > >> this version to constraint the scope of "contribution", "the code", and so on. > > > > Yeah, it probably needs even more integration to make sure the terms > > used match the rest of the document. I didn't take much care into > > that, as I was writing this in the email reply and didn't have much > > context. > > > >> ----------------- > >> > >> I have the same question for you I asked Jan elsewhere. > >> > >> There's 1 question in 2 forms I'd like to have an answer to from a core > >> maintainers. > >> > >> Would you be willing to ack a change along these lines? > >> 1. to a Copyright Notice policy within CODING_STYLE. > > > > I'm fine with that. > > > >> 2. to the relegation of existing notices to a NOTICES file in the style of > >> Apache. Apache in particular mandates the file not be touched unless > >> absolutely required for legal reasons. > > > > Hm, that might be more complicated. I am however not a lawyer, don't > > expect the rants below to have any kind of legal base. > > Neither am I, for the public record. > > > > > What about the public headers in xen/include/public? I don't think we > > can just remove the copyright notices from those files and place them > > in a top level NOTICES file. Then OSes would copy the headers > > without the NOTICES file and end up effectively dropping the original > > copyright notices. > > > > Also, what about people importing files from Xen into different > > projects (apart from the public headers)? If we remove the copyright > > notices the imported files won't have them either, and people is not > > simply going to pickup the top level Xen NOTICES and import it into > > their project? > > > > How does Apache deal with people importing their code into separate > > projects, do they mandate the NOTICES file to also be included as part > > of any code import? > > They do. It's part of the Apache license. See point 4.d: > > https://www.apache.org/licenses/LICENSE-2.0 > > This would require some sort of ammendment to xen/COPYING. > > OTOH, to avoid being a PITA to Linux and others by changing how we do things > it'd be sensible to keep the existing headers on everything under xen/include/ > public/ for being-a-good-citizen reasons. > > Anyone actively copying an internal file (say, msi.c) would thus be forced to > also copy NOTICES, but that's a heck of a lot rarer and not much to ask. Possibly a very dummy question, but won't our NOTICES file be fairly big and complex? If we have to move every single variation of the different copyright headers we currently have in the tree. We have GPL-2 only, >= GPL-2, MIT, LGPL, BSD... Each with a possibly different set of copyright owners. Also, would we need to somehow reference which notices go with which files in the tree? Otherwise we would effectively loose tracking of the specific copyright owners of each file I fear. Figuring those out would need to be done by going back to the last commit before the copyright notices were removed. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 28 10:35:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 10:35:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215365.1525561 (Exim 4.92) (envelope-from ) id 1vl2t4-0005XU-VM; Wed, 28 Jan 2026 10:35:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215365.1525561; Wed, 28 Jan 2026 10: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 1vl2t4-0005XN-SK; Wed, 28 Jan 2026 10:35:02 +0000 Received: by outflank-mailman (input) for mailman id 1215365; Wed, 28 Jan 2026 10: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 1vl2t3-0005XH-IC for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 10:35:01 +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 ff322505-fc34-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 11:35:00 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-4359108fd24so3990999f8f.2 for ; Wed, 28 Jan 2026 02:35:00 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e10ee057sm6773824f8f.15.2026.01.28.02.34.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 02:34:58 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ff322505-fc34-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769596499; x=1770201299; 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=X6p4KLNtrIoQOZgguwVAKGNaQYwTU5U2QKElDIc3N6E=; b=TvlLnF6Sj3+Iw564eLVe+elc9n/5b6hX9Vt62qnAN0WtPVR+8XY1xOJ/GjJ8zcZWRI 23JjLHEOrw6GugsjshBChEIF3ZwT9eVGRKoTsLkOXFD8qJ6xEkUAPFmENwwpMc661McG I/X5xflFKmKFS3EkREW4EHwnZNaAFZvklxf50o0DjZTc6PkvdiZNZw4KfoHsb46JwPGu GxgLPWqfjKH68ypp+dGzJ7WDRNMYEBLH5xrS9w5Q4k2pEQkyRUjYgtmz7ekfweZTpENc o/yW2u7R0jm318eLWoCaZDVNhoBYpMCNrOouZrKH/J8syXHd1JGLGbSVpfYCORXOaeHf dSiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769596499; x=1770201299; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=X6p4KLNtrIoQOZgguwVAKGNaQYwTU5U2QKElDIc3N6E=; b=aPLzqHm7SlCb8kTF+piAi2sGs1hmE8FrR+yyuxaixHkFRi6JO+pejIpHToh6kH/A1T 3mXrSBgaihomtJSiGFpSmXdJYGqcMWESdBL/B6dbUdq/hSbOFrnDvwkqxtxdX4oydh6p pY8xUgqtqMlLOunfnobRP++71uKgJ6pvvTqulB1RQgWEdN82SxoJk3mIRNOan1sdykRM K44Smb7Z5iPZ0Eeg/gKM6Rfchqirv3TjSHOej5bsQeYL424LtDa/y52B37u+StGhikmU Jk2FNuvuh+yBRa3ycz3r0TrB3Fhadx4T3ivRx8huucv5RWBwos3ayZTVO9bAq2DOsVGv 6h3Q== X-Forwarded-Encrypted: i=1; AJvYcCWjggS8cIGWl6HIDC9V90FjRw+DfRtQydWYD9VvjkhnbvKoWDZdMfv4iXTZ3vPZTZBEWJqcRU25yHc=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz/Wnahe5TcMqfUBH5ui/WVcg8gs6/3persHQcNA0Bcs6L6fdse tx/P1LOFqPLDt0aCEuz586hW2KcZWOqpdEK9I1FUZY2OLMkjur6M1SuW X-Gm-Gg: AZuq6aKZWKwdCLTBt4hTrvm1ZX7PQY6ou3CS1q1hgi9VOdOTaBx+0sVrET1ArWW46dn 6v8boawKzGQ0v4FFSKM7NMDRIjMfSWm4p5isT4eaT8gLu9//JlEmEvRvMLRVGUUk6fbG34Py07+ 8WkQ7dz110JZ9fXvGuQHWnbl8aViU9HNsV4lb4NoqLZyTefUK5ZKTeh/i9q8ZttrstzlrUTBCVx LhXdR7o9H5KT0Jm8IfkywNmwfXlfQkEN/t1JelwubYntrhDK867hd/vava2lSu94srtQ5q1oRWp 4YPgsfbMUkwujgXPLX9dN5MbLksBGKppY5ZPdEm0XYxrMoLiDVUX+aNZ1ZVeOzMxohPEYZnP5Dn /gzrTChgxjcDq1pmb3hKOlTGuxymCOgRTKX10Qt00USthfIjmyAzSnF6r8sEY2wBdWhI6VQKkX5 dJXRODycj8We+/rkKkn+deqLGiVouWhg9N0wOhyo9u1QztbAawXfEgr7UjQ4Tj4rk= X-Received: by 2002:a05:6000:4022:b0:435:9ce0:f93c with SMTP id ffacd0b85a97d-435dd1c7ab4mr7793448f8f.62.1769596499163; Wed, 28 Jan 2026 02:34:59 -0800 (PST) Message-ID: Date: Wed, 28 Jan 2026 11:34:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] xen/riscv: dump GPRs and CSRs on unexpected traps To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <27ab0f8eb6fd6ecef1eeefa4a05e4fe1f43acbbe.1769427484.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/27/26 10:27 AM, Jan Beulich wrote: > On 27.01.2026 10:14, Jan Beulich wrote: >> On 26.01.2026 12:43, Oleksii Kurochko wrote: >>> Provide additional context when an unexpected exception occurs by dumping >>> the relevant Supervisor, Virtual Supervisor (VS), and Hypervisor CSRs, >>> along with the general-purpose registers associated with the trap. >>> >>> Dumping VS-mode CSRs in addition to host CSRs is beneficial when analysing >>> VS-mode traps. VSCAUSE, VSEPC, VSTVAL, and related VS state are required to >>> properly diagnose unexpected guest traps and potential hypervisor >>> misconfiguration. >>> For example, on an illegal-instruction exception the hardware may record >>> the faulting instruction in VSTVAL. If VSTVAL is zero, VSEPC should always >>> be inspected, and can be used together with objdump to identify the >>> faulting instruction. Dumping VSCAUSE is also useful when the guest does >>> not report it, or when the hypervisor redirects a trap to the guest using >>> VSCAUSE, VSTATUS, and VSTVEC, allowing verification that a subsequent trap >>> is not caused by incorrect VS state. >>> >>> Signed-off-by: Oleksii Kurochko >> Acked-by: Jan Beulich > Hmm, wait, there's another anomaly: > >> I still have a question though, which can be addressed incrementally. >> >>> --- a/xen/arch/riscv/traps.c >>> +++ b/xen/arch/riscv/traps.c >>> @@ -99,12 +99,70 @@ static const char *decode_cause(unsigned long cause) >>> return decode_trap_cause(cause); >>> } >>> >>> +static void dump_general_regs(const struct cpu_user_regs *regs) >>> +{ >>> +#define X(regs, name, delim) \ >>> + printk("%-4s: %016lx" delim, #name, (regs)->name) >>> + >>> + X(regs, ra, " "); X(regs, sp, "\n"); >>> + X(regs, gp, " "); X(regs, tp, "\n"); >>> + X(regs, t0, " "); X(regs, t1, "\n"); >>> + X(regs, t2, " "); X(regs, s0, "\n"); >>> + X(regs, s1, " "); X(regs, a0, "\n"); >>> + X(regs, a1, " "); X(regs, a2, "\n"); >>> + X(regs, a3, " "); X(regs, a4, "\n"); >>> + X(regs, a5, " "); X(regs, a6, "\n"); >>> + X(regs, a7, " "); X(regs, s2, "\n"); >>> + X(regs, s3, " "); X(regs, s4, "\n"); >>> + X(regs, s5, " "); X(regs, s6, "\n"); >>> + X(regs, s7, " "); X(regs, s8, "\n"); >>> + X(regs, s9, " "); X(regs, s10, "\n"); >>> + X(regs, s11, " "); X(regs, t3, "\n"); >>> + X(regs, t4, " "); X(regs, t5, "\n"); >>> + X(regs, t6, " "); X(regs, sepc, "\n"); >> Does this sepc value differ from ... >> >>> +static void dump_csrs(unsigned long cause) > What is this function parameter for? > >>> +{ >>> +#define X(name, csr, fmt, ...) \ >>> + v = csr_read(csr); \ >>> + printk("%-10s: %016lx" fmt, #name, v, ##__VA_ARGS__) >>> + >>> + unsigned long v; >>> + >>> + X(htval, CSR_HTVAL, " "); X(htinst, CSR_HTINST, "\n"); >>> + X(hedeleg, CSR_HEDELEG, " "); X(hideleg, CSR_HIDELEG, "\n"); >>> + X(hstatus, CSR_HSTATUS, " [%s%s%s%s%s%s ]\n", >>> + (v & HSTATUS_VTSR) ? " VTSR" : "", >>> + (v & HSTATUS_VTVM) ? " VTVM" : "", >>> + (v & HSTATUS_HU) ? " HU" : "", >>> + (v & HSTATUS_SPVP) ? " SPVP" : "", >>> + (v & HSTATUS_SPV) ? " SPV" : "", >>> + (v & HSTATUS_GVA) ? " GVA" : ""); >>> + X(hgatp, CSR_HGATP, "\n"); >>> + X(hstateen0, CSR_HSTATEEN0, "\n"); >>> + X(stvec, CSR_STVEC, " "); X(vstvec, CSR_VSTVEC, "\n"); >>> + X(sepc, CSR_SEPC, " "); X(vsepc, CSR_VSEPC, "\n"); >> ... the one logged here? Nothing changes the register between entry >> into the hypervisor and coming here? > Down below here you have > > X(scause, CSR_SCAUSE, " [%s]\n", decode_cause(v)); > > which actually (largely) duplicates what do_unexpected_trap() has already > logged. Missed that, then it would be better to remove this duplication and leave only printing of CSR_SCAUSE in dump_csrs(). > If dump_csrs() gained other uses, the dumping of scause likely is > wanted, but then likely no scause value would be available to pass in? So > maybe its dumping actually wants to be conditional (and the parameter > wants to be a boolean)? Good point. Honestly speaking, I don't know if it will be any other usages except this one. But to keep things generic I think it is good idea to add conditional dumping of scause. I will update the patch and send new version. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Jan 28 10:45:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 10:45:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215381.1525571 (Exim 4.92) (envelope-from ) id 1vl33P-0007LY-Va; Wed, 28 Jan 2026 10:45:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215381.1525571; Wed, 28 Jan 2026 10:45: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 1vl33P-0007LR-Sj; Wed, 28 Jan 2026 10:45:43 +0000 Received: by outflank-mailman (input) for mailman id 1215381; Wed, 28 Jan 2026 10: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 1vl33O-0007LL-9r for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 10:45:42 +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 76ec1e57-fc36-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 11:45:30 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-432d28870ddso3593649f8f.3 for ; Wed, 28 Jan 2026 02:45:30 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e131ce70sm6141440f8f.27.2026.01.28.02.45.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 02:45:29 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 76ec1e57-fc36-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769597130; x=1770201930; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=W3tiy3ex+9fe2AdesqmsEFYrWFq4W4hy7sYh60ga0Ro=; b=UKgcWiu2we/zzKunRKnjjmfQ0bNRE+1ZFMD13eZ51FXzSIpGdThLcn/MnGMl5SohHk uLmiir5ngU/EAGJkwa02Spgn5Bjit7Jc/3wEAfR1nEB30x3XaCYVhkn8dYgDlqkSKFS/ Nva2RzCKjl7068OLjFezW5upGSkrS/2OZLxzIQlFDQx3KaM76VWbtYrhOKhulHkNH3Y9 YawmDQyLjc/1PaWhti7Ig1nAw67C94z/XhD6lfOThMAp5w1vsFPO3Pto8vrLJ43HdPOm j9j6naRAvIWhelUuDvziL4W3A4JuTC0qr7RtUPFKimvaV+ZVl1J858lGq+0YnP+XRihR iCGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769597130; x=1770201930; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=W3tiy3ex+9fe2AdesqmsEFYrWFq4W4hy7sYh60ga0Ro=; b=pxVFBZt9Hk5rZQX0+C4Y6rBe5f/0NCSTO6U5OlK6FD0v96ss7edG2HxtzaxbEn9p+A ESakWOvWYwRD6Op5BsIqlSnuksx/eNr9xMMAvHjnJFQgZ9kIBzkihxEEM9/weGwGp+lC PfyFKMC3nysBB5OqeQc7osgHJGvyQVGa/5ONmBkD9c6WnOWCWru8PkTHav16mFMr2Yn8 yQ2XSVRWMJhYg7uY9LC4pk4KM46zhl2JwidJRX8qsghM1mZte/LmfmB5sVT/uxxRXLHN znZBjOxvU3FaG7ZyQGwhA+M68n8zBa7/owG27SNheXWwkffKN8E8/PAxSlTi0RTdwuv1 P7Ng== X-Forwarded-Encrypted: i=1; AJvYcCW07SOgR2JL+IX33Wiag+O7zISCbCXoDEhsjfV3HbO5PpKUezVCu0YopD4fo3fZ/HnMb1OqZaZZb6M=@lists.xenproject.org X-Gm-Message-State: AOJu0YyLgwhrwxXPOwj1Qecu/nQtNG98rstI5Or/uEbvewDZ9VsyAw1d zvr7bvth3buY0M/QXo78zcJaybh9y4HLZHDC57OpuZtqol+6enS7g4qch8jG6mVx0g== X-Gm-Gg: AZuq6aKZUrZDOjHOovad7F1o7zvFKlBKO71pkvGNHDqYkAfByM1V4XfRfq4dFmj3mIG WVqChW4KPjKwf84k+XNcQaTawsUt/1hMSpBwCDl6/9uZTJtn93JkMOshN7IDgXB8GblKi38KyZ4 iAYn9g84vmUNd2ZapGxKMJb8J3SvjtWJGCPLHh1rUT7BZ2zpGxzS3F62VACkm1bg9RXo1Uozxd8 Kt980mdhUNAhx9jn4IgM7OaaYSoeDpypeK2LRz3JZkcHbhpOxMfqSySp+k1EoD5BGewxUSnkKsi YU2o8jO4doo+gbthXv033rV6Ir+DZGda9nmj0LvHyEp7JGi1nmKRzkmYiWiL9HfiP+R4cmlAyQ1 9D8u5be+dgpf4GDdE4JTaEB79Lkw70YtIQKub8v7yt8bVEWOPEEgADHEN7NLIPfnK94B/mHFRYa 5k7JfU4s1iWyUa84c8BtGoKp+xguQTu+JNRkQCNnLQm1U7fcc3kC3iqShJM0QMjX4sI++9mfZpS fY= X-Received: by 2002:a05:6000:2511:b0:430:fdc8:8be3 with SMTP id ffacd0b85a97d-435dd0a34c9mr7495184f8f.29.1769597129751; Wed, 28 Jan 2026 02:45:29 -0800 (PST) Message-ID: Date: Wed, 28 Jan 2026 11:45:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] CODING_STYLE: Establish a policy with regards to copyright notices To: Alejandro Vallejo Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260127182403.141459-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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.01.2026 10:09, Alejandro Vallejo wrote: > The refinement also applies to the second bullet point, so I can add it as a > separate paragraph stating existing notices are to never be modified and only > removed with the express consent of the current holder(s). That's interesting, as it may be getting increasingly difficult in practice. Often you can't get hold of the holder(s), to the degree that - as we're all growing older - at some point they may not be there at all anymore. Yet if not having such notices is going to be a goal of the project, retaining some indefinitely can't be the intention either. > Do you have a take for/against moving all existing notices to a separate NOTICES > file (a-la Apache). The existing file for them (in httpd) looks like this, so > they took the liberty to rewording the banners to be more digestible in single > file inclusion. > > Apache HTTP Server > Copyright 2026 The Apache Software Foundation. > > This product includes software developed at > The Apache Software Foundation (https://www.apache.org/). > > Portions of this software were developed at the National Center > for Supercomputing Applications (NCSA) at the University of > Illinois at Urbana-Champaign. > > This software contains code derived from the RSA Data Security > Inc. MD5 Message-Digest Algorithm, including various > modifications by Spyglass Inc., Carnegie Mellon University, and > Bell Communications Research, Inc (Bellcore). > > This software contains code derived from the PCRE library pcreposix.c > source code, written by Philip Hazel, Copyright 1997-2004 > by the University of Cambridge, England. > > It'd blur the scope of existing holders, but code moves and so do their > contributions. Keeping a banner on a file after a refactor is just > misattribution. > > ------------------ > > In short. There's 1 question in 2 forms I'd like to have an answer to from a > core maintainers. > > Would you be willing to ack a change along these lines? > 1. to a Copyright Notice policy within CODING_STYLE. Likely, once we've agreed on suitable wording. > 2. to the relegation of existing notices to a NOTICES file in the style of > Apache. Apache in particular mandates the file not be touched unless > absolutely required for legal reasons. Very unlikely. While likely I wouldn't veto it, I don't like such moving around of things. If we want to get them out of the source files, they should be dropped altogether. Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 28 11:01:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 11:01:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215396.1525581 (Exim 4.92) (envelope-from ) id 1vl3IU-0001j8-8Z; Wed, 28 Jan 2026 11:01:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215396.1525581; Wed, 28 Jan 2026 11:01:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl3IU-0001j1-4t; Wed, 28 Jan 2026 11:01:18 +0000 Received: by outflank-mailman (input) for mailman id 1215396; Wed, 28 Jan 2026 11:01:17 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl3IT-0001iv-5W for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 11:01:17 +0000 Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [2a00:1450:4864:20::42a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a9c94224-fc38-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 12:01:14 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-435a517be33so4152076f8f.0 for ; Wed, 28 Jan 2026 03:01:14 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e10e474csm6171944f8f.2.2026.01.28.03.01.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 03:01:13 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a9c94224-fc38-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769598074; x=1770202874; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from:subject:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=JweL1F0U7KTd9nbph4Cw6CSfliimKtGM5nSq2DSPIvY=; b=dbC3QVWkDUpxKa35jQtGQB1wTsrExr6rQxOv1yQZqcHMBaH7zSNVP4N9oC3GO5z7AE BMSG01MEYRsrS9FWXZtsI1WSoXYBK9ztT+QcheHJQp6SUfXVmPsWgTh/H0dRzFeRS6W7 +F/ZmuhVg0kjDLzOnTtvuSXZniD9XfbENdVkoXRdlQUla5RNZKMLxIYSqsfIJ5Sb+/Ei NpHDOjJ+fGiqF9ddg193JSPPSjez62wjJckTTxrEgbRZulKNeE/zljgOp3lq4OLTRYEE 3SNCde7TcfF/Vb2bNCaCAlN4cYLDKZNuTwaStKw5Bj2lELnzGF+2SrvD/DvzH8c+Sra+ Bf5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769598074; x=1770202874; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from:subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=JweL1F0U7KTd9nbph4Cw6CSfliimKtGM5nSq2DSPIvY=; b=vxodBZJw+JgwTAliaEM6Uf7LyN/SBPKqdErHUfsAnkEUzA/SVPh4Q8+4Jzs2Ra/uzI D4O0XyCFKrJdlrHtv2QRErdzRPnXNMwFs6ZECRDdbeMQPseVxYco2WbyPpUZ/567JBIp CD1ueC9vYQuylguMXVukx8AZlBHkNLN8wil4Uk/1ZynhCHoGBrCkE344nnXcDPc1ip3U QQwaoWqA1MJ47yQscy5MYf9bqeV+/2BEcSQn3EpVh2deUj2MF02yXQFb5EQG2xzqkElb i+VHtIRVlwkQzAg/KfMY6G/rxrPOrpQQIgEF+CSA1ZDu4lv6Ibi5wYzrOIUWnZAi6AzD USYw== X-Forwarded-Encrypted: i=1; AJvYcCW+lbBmwgTHMuR7k5TXzxjIhza+FT0fQ7Cia8GQQmveVJssu1gkm1ABb98YAQ348/ptdCVLLV3CCMI=@lists.xenproject.org X-Gm-Message-State: AOJu0YwAyravzS2CgmgPj1SOpkn/WwpoIWyf8hr5KlZ8TMy0btyiwQg5 WNLVHE2vonaFvBAsmmqIU0LTNPd9SItmmbl84viD9rpD46hD6gULjynrz2rlXg== X-Gm-Gg: AZuq6aI9pyz0Oi/oFBbLEtt6nVqjk2TYNiRkiVHhLmvy8b2t3AzMhQS6OIohGEMeE8T H/8E/5/sDMo/GBplPFU+VIt20ObdvUi9NSf5YoLRacR9CaNSheERTW++VMCSbjT3mtv7qWJWPla cSnp8IZvMvi2XcqJ6hqKG2K44rc4iUuZQEVsCn9WRwUGW+fBYdKfsTWVd/qkJYf8TnbkRXnToWk 7OFU5QK/l5Zxlbx+tOMkcxz7u+edS2tHLanhYH0bj04T8OfUDV6icAQiTTaGFmL7KEVNbfq31zb ladLx9FJt5vp00zJZrhxpCU8/d1ElhPRU/zT2rW5kb9lrKDjqxFQjDkNkKBR459jbTcTnQLFLWX pmd7A2jofZb58YPGWVk4mnJ/fYZ3in37artwX4KBfxROlOdv2WV3ARCEu2t+DWAqvuneI4m9kHo zSZuJDNRxsmVP/V81YoxCJaOSAqhDkSmx1elwILU3ptJW9khqDEowm5NHreYTL8P4= X-Received: by 2002:a5d:5d13:0:b0:435:aaba:b8db with SMTP id ffacd0b85a97d-435dd0701b7mr6357523f8f.21.1769598073788; Wed, 28 Jan 2026 03:01:13 -0800 (PST) Message-ID: <88edf7a2-c5f1-41fd-9ceb-8cc0c345b7e6@gmail.com> Date: Wed, 28 Jan 2026 12:01:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] xen/riscv: dump GPRs and CSRs on unexpected traps From: Oleksii Kurochko To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <27ab0f8eb6fd6ecef1eeefa4a05e4fe1f43acbbe.1769427484.git.oleksii.kurochko@gmail.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/28/26 11:34 AM, Oleksii Kurochko wrote: > > On 1/27/26 10:27 AM, Jan Beulich wrote: >> On 27.01.2026 10:14, Jan Beulich wrote: >>> On 26.01.2026 12:43, Oleksii Kurochko wrote: >>>> Provide additional context when an unexpected exception occurs by >>>> dumping >>>> the relevant Supervisor, Virtual Supervisor (VS), and Hypervisor CSRs, >>>> along with the general-purpose registers associated with the trap. >>>> >>>> Dumping VS-mode CSRs in addition to host CSRs is beneficial when >>>> analysing >>>> VS-mode traps. VSCAUSE, VSEPC, VSTVAL, and related VS state are >>>> required to >>>> properly diagnose unexpected guest traps and potential hypervisor >>>> misconfiguration. >>>> For example, on an illegal-instruction exception the hardware may >>>> record >>>> the faulting instruction in VSTVAL. If VSTVAL is zero, VSEPC should >>>> always >>>> be inspected, and can be used together with objdump to identify the >>>> faulting instruction. Dumping VSCAUSE is also useful when the guest >>>> does >>>> not report it, or when the hypervisor redirects a trap to the guest >>>> using >>>> VSCAUSE, VSTATUS, and VSTVEC, allowing verification that a >>>> subsequent trap >>>> is not caused by incorrect VS state. >>>> >>>> Signed-off-by: Oleksii Kurochko >>> Acked-by: Jan Beulich >> Hmm, wait, there's another anomaly: >> >>> I still have a question though, which can be addressed incrementally. >>> >>>> --- a/xen/arch/riscv/traps.c >>>> +++ b/xen/arch/riscv/traps.c >>>> @@ -99,12 +99,70 @@ static const char *decode_cause(unsigned long >>>> cause) >>>>       return decode_trap_cause(cause); >>>>   } >>>>   +static void dump_general_regs(const struct cpu_user_regs *regs) >>>> +{ >>>> +#define X(regs, name, delim) \ >>>> +    printk("%-4s: %016lx" delim, #name, (regs)->name) >>>> + >>>> +    X(regs, ra, " "); X(regs, sp, "\n"); >>>> +    X(regs, gp, " "); X(regs, tp, "\n"); >>>> +    X(regs, t0, " "); X(regs, t1, "\n"); >>>> +    X(regs, t2, " "); X(regs, s0, "\n"); >>>> +    X(regs, s1, " "); X(regs, a0, "\n"); >>>> +    X(regs, a1, " "); X(regs, a2, "\n"); >>>> +    X(regs, a3, " "); X(regs, a4, "\n"); >>>> +    X(regs, a5, " "); X(regs, a6, "\n"); >>>> +    X(regs, a7, " "); X(regs, s2, "\n"); >>>> +    X(regs, s3, " "); X(regs, s4, "\n"); >>>> +    X(regs, s5, " "); X(regs, s6, "\n"); >>>> +    X(regs, s7, " "); X(regs, s8, "\n"); >>>> +    X(regs, s9, " "); X(regs, s10, "\n"); >>>> +    X(regs, s11, " "); X(regs, t3, "\n"); >>>> +    X(regs, t4, " "); X(regs, t5, "\n"); >>>> +    X(regs, t6, " "); X(regs, sepc, "\n"); >>> Does this sepc value differ from ... >>> >>>> +static void dump_csrs(unsigned long cause) >> What is this function parameter for? >> >>>> +{ >>>> +#define X(name, csr, fmt, ...) \ >>>> +    v = csr_read(csr); \ >>>> +    printk("%-10s: %016lx" fmt, #name, v, ##__VA_ARGS__) >>>> + >>>> +    unsigned long v; >>>> + >>>> +    X(htval, CSR_HTVAL, " ");  X(htinst, CSR_HTINST, "\n"); >>>> +    X(hedeleg, CSR_HEDELEG, " "); X(hideleg, CSR_HIDELEG, "\n"); >>>> +    X(hstatus, CSR_HSTATUS, " [%s%s%s%s%s%s ]\n", >>>> +      (v & HSTATUS_VTSR) ? " VTSR" : "", >>>> +      (v & HSTATUS_VTVM) ? " VTVM" : "", >>>> +      (v & HSTATUS_HU)   ? " HU"   : "", >>>> +      (v & HSTATUS_SPVP) ? " SPVP" : "", >>>> +      (v & HSTATUS_SPV)  ? " SPV"  : "", >>>> +      (v & HSTATUS_GVA)  ? " GVA"  : ""); >>>> +    X(hgatp, CSR_HGATP, "\n"); >>>> +    X(hstateen0, CSR_HSTATEEN0, "\n"); >>>> +    X(stvec, CSR_STVEC, " "); X(vstvec, CSR_VSTVEC, "\n"); >>>> +    X(sepc, CSR_SEPC, " "); X(vsepc, CSR_VSEPC, "\n"); >>> ... the one logged here? Nothing changes the register between entry >>> into the hypervisor and coming here? >> Down below here you have >> >>      X(scause, CSR_SCAUSE, " [%s]\n", decode_cause(v)); >> >> which actually (largely) duplicates what do_unexpected_trap() has >> already >> logged. > > Missed that, then it would be better to remove this duplication and leave > only printing of CSR_SCAUSE in dump_csrs(). > >>   If dump_csrs() gained other uses, the dumping of scause likely is >> wanted, but then likely no scause value would be available to pass >> in? So >> maybe its dumping actually wants to be conditional (and the parameter >> wants to be a boolean)? > > Good point. Honestly speaking, I don't know if it will be any other > usages > except this one. But to keep things generic I think it is good idea to > add conditional dumping of scause. As an alternative, we could simply remove the dump_csrs() argument and always print SCAUSE. When running in hypervisor mode, SCAUSE should contain the reason for the trap. Even it is lets say just hypercall and not something faulty, it will contain "Environment call from S-mode" what looks okay to be printed. I tend to prefer this approach slightly. What do you think? ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Jan 28 11:05:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 11:05:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215406.1525590 (Exim 4.92) (envelope-from ) id 1vl3MT-0002HI-Mw; Wed, 28 Jan 2026 11:05:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215406.1525590; Wed, 28 Jan 2026 11:05:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl3MT-0002HB-KM; Wed, 28 Jan 2026 11:05:25 +0000 Received: by outflank-mailman (input) for mailman id 1215406; Wed, 28 Jan 2026 11:05:24 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl3MS-0002H5-7W for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 11:05:24 +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 3b51d612-fc39-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 12:05:19 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DS0PR03MB7226.namprd03.prod.outlook.com (2603:10b6:8:124::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Wed, 28 Jan 2026 11:05:15 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.006; Wed, 28 Jan 2026 11:05: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: 3b51d612-fc39-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=BJwEwPl6aeNXCyXLnS5uC0EHzQRmo9FBjmkKVqkO1AHxZfYkErKwj+qszLB9y6GaxKG45ohfKzUjDkX1ymg5ie9+J1BMMFIo/SuKRqToOW10tJltkHjPhNO2h0EpGBt5vm6mWxcuoN6/2iqd7EcmiMjFKIKf53J8OOu1e7miPj7JHmMex9x7FLgckFRHrX8x/whsEnsoH8jz07Y+fdwF/p+8cdDFjoNlPnW7OOIVwJ/tXsWuo+OSUDSZ36nXCf45wDWN3dcyGN/euYUb+lNabdoEe2MvXh+7+WmIcut12VWJ2z69yqBZ/+oUrPMpsR+uGVSxW+RmMrfpwpEqJ00vvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aNRNTDhSJ/Z5mN7bx1YPGYYKFU8XdjmwmtfOvBT5Eo0=; b=mC5LBK+d77hB40bDnRSVVGir4VtoKlhb7mpnj4Gv4EW+5DVXUydrdxdwhteS16Xw2VgYvy6sgfv0ZNar12pq9JsiHO33AXA+5MpPjM5uumuMiRQj1BrH/V5HTez7CxEq86wanmLaFSxNubDNcS+GrSCTPEdAxJ20CjzAdIMzUDFsiJSwKWsmX1X8bRAYfTrZ9QKmuPDsVVGC/uMhqGs6MRj2SfYn1jJ+rs+nFYcgD7AYrEpJxzvPTwGoiY9au1CCbS61wvZ8hijGcFK11Yao2x8W4cPZhxNyW72F7lcQUXmmHdFb1lyrko8GFo1wHxbOrJ6NmcN3b2loN9OBT4Gqxw== 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=aNRNTDhSJ/Z5mN7bx1YPGYYKFU8XdjmwmtfOvBT5Eo0=; b=y1H4wDScxpL6xZX09V+0dskUBEqaVTVAtYvXoUOLW0IjzF6oJ8DTfBhyslN1LiUiYg6DvdFuek2ibOnLuqDT0/3r3N0bn+EvQPQbo0b/aOAUoWvd08wA5miUxhLQCOU019DgK90IxVojfNoMaXPYR56STHdxiZ4jbjp6DIneidk= 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, linux-kernel@vger.kernel.org Cc: Roger Pau Monne Subject: [PATCH 0/2] xen/balloon: fix balloon driver initial target Date: Wed, 28 Jan 2026 12:05:07 +0100 Message-ID: <20260128110510.46425-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: MR1P264CA0183.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:58::17) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DS0PR03MB7226:EE_ X-MS-Office365-Filtering-Correlation-Id: e5244a43-e8cb-436a-cd61-08de5e5d1d42 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?NE9jK0oyaXArWjRsNkw3eTk0MElwVzZtYjY1L2ZmZ2dKLzNJTHk1T2h3WTlC?= =?utf-8?B?REpVQ0ROTllBMGhrRVYrcHJ2UjAveE9PVWxNV3Y4ZDNDb2F0YTNoTXlNaUhF?= =?utf-8?B?NlI3U2tqbmtNQnJ2R3BpUXRjNEw3K1ZudFJ1NzBvVGZaMzlLd25RU2FYUUlK?= =?utf-8?B?RlMrZW95TVVwakRvdzNaRjZFOFZFakpBaHJOOFN1OWlvQzVLU1ZMVXlHVktH?= =?utf-8?B?bjVzSENOcG1zdEd5TU1lSThHVXh2VWFZaUYvRFhZSWRnOGR5b1d4Qmg2MkRE?= =?utf-8?B?dVgxbjJpZkZ1cytueER3UzlINnlSWm1kbXV3Qk5CdXZ5dGZ3WXhKVzVaSXZJ?= =?utf-8?B?MklwOFVFZHpjWEJYQ0pPa3FCL0I0OE5NZXR0ZS90SDBTUU5kcjd5MzlDSW44?= =?utf-8?B?d0ZzMzluN2xrOW4zbjlEZDNjYkRpaFNWTUJFYmdEZXFPMGRyZFUrcjg4VnZ1?= =?utf-8?B?M1BpSis2ZjBoNVdrOVlQeFFYRXh6bkowYnc2cnZ1ZU5aVDc1ZERRK2tZVDQy?= =?utf-8?B?RGJwbkFReElYTWZ2cTBBbFhhZDZhaUM3UVdsYkNYTCtMMU1wOGdhNHRBK3JU?= =?utf-8?B?UWtlZUdUTzdWMUJWOFhSc2xXcjkvRTRmMytMNjkwVXJxY3IvS3owRjNxbDRB?= =?utf-8?B?ODdybDVpcEJ3OVVvSDhoY0ZUZ05LeHFqOVBKcHJndGhCRjJDSjBxeDduWFZt?= =?utf-8?B?UE1OczR1RDl2dzFJRGZjZ3dzVTlKbU0xUmhOUkJrR3JRc0tadTl2VlpWakJ0?= =?utf-8?B?elFqKzhWT2FjWmVyNmZBV0RiRHQrOCt1K0wzTHB4bURGRlJtZUIzaHJpRHpD?= =?utf-8?B?NUxONE52aU9qVk9kLzhzaHRxdGhqMUV6bGxBUTVkbWZjUkkrR0g0VXpXWFJv?= =?utf-8?B?akQwT1RibGdLRWRaNm5VTzRBSCtLQXZ4Yks5N0ttclN3emN1Y05ObkRCYy8w?= =?utf-8?B?bndzOTVqZUJHaE5DM0I1OS9KZFFlaHlTYm5VNnpYQzRTZUFIUE5XSSs1cFpv?= =?utf-8?B?MEJEclpsckIrekFOQVcyRXk0Y1pkNHJ0Uk9KQUtOdDNrRm9RQlhwZ2VOdlp2?= =?utf-8?B?R0NCNHl2N0pGVW5Jb1BKT05EQWtPa3FIcHNQNXRoWWZBczBQWm5iS2c0NUpD?= =?utf-8?B?bVZ1ZUQvV2p5aFZOQUdML3NsUE5UQ1BmVmR0OTA2SUp4cjdvYUV3b1VUOVZq?= =?utf-8?B?dzl5TXk1TERpWEF0ZHd6bmladEE3VUlHbllYbHVzT3pMbUcvOGZ3TjNBM1U5?= =?utf-8?B?aStOUmVCbGN5NUNBbHNtaTZnZWdwNFBKTUhMTi96VEVtK3BQUjRSL0dLVUNC?= =?utf-8?B?WUFSMVBxMjlxczhpL3g3VnVYVnBVbkovRjExTkl6NThCNkZ5anRpek41NjFP?= =?utf-8?B?T0RBZEhOVWV2QVJ6dzVLKzhCOU9uR2pHT0pXT1BnMTloYzFObUlPK0s2ZzNY?= =?utf-8?B?VzdDWXhUQ25WZzM1US9PcXN5TkNBdXV4L3kyMjB6ODZZVVhKd2t5RzZ0MVZr?= =?utf-8?B?T28veXFadFA0Lzg1VDNVMW0rSmNsbTYvQmtPVSthQzZmQThpak1PRFFQcDFE?= =?utf-8?B?U0FnREd4Wmg2akZQS3Q5OXM2cVg2ci9VRndlNCs4dkdBNkx1alpYY3lHdEUv?= =?utf-8?B?c2JIMzVQeDRXV0hhekJyempxSWJQaDlHYW0xRElmYis2MTFZUytNcDZTKzJE?= =?utf-8?B?TjZjUVN6Y2t4WjU4QXBVa04vbjZObk42L29rVmJHRWtmR3o4OFM4MkdBcXdo?= =?utf-8?B?WGllejlwRnRhcmZQakxhZFQzSktZNkxZZHZnZW5NTFllVEZQOUFBWVV0M3FI?= =?utf-8?B?MlROTW1UNGlubGdUUnN5bnZ2TkhibE03U1gvYW1md2V3Vll0N0YxQXRuZXk5?= =?utf-8?B?NFZVU3NJT3ZBb2RwZWliOGRTODcyUmVLeUNKbzEvYzYyNUw1cFVNbm1qWU5H?= =?utf-8?B?TGtoQi9zQ0tqeEF3Tm55eFlaYk5qcG5FV0R1UFRZak84SmxxeXBoZitBRlFw?= =?utf-8?B?MFZMMEQxUlg5WFFleGlwa2VGLzk3ekdncjRIR2kvMmVxMldQQno4MDEwMzJw?= =?utf-8?B?aWVrU0JCT3VmOWd2Q2oybEl1b3h0UWlEclBhd1BEMFU1WVRtL3FSdmhNY1Rm?= =?utf-8?Q?RRVk=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WFJGT284Z2xtSTAwT1p2eXNQUms3Rjh0bURsZ3B0NVNpRXFUT0tldlErczdN?= =?utf-8?B?YmxmaFIzR2RrVGR1L0FKSmZzYU5IV1N0dUxzWUszVFkvNXEzOTFpaXB0TFBQ?= =?utf-8?B?ZUw4MnV3cEtmRk1qMmdPT08yUTJHNWQ5RTN2bVNXbWR6N29QYXdzckVuekVR?= =?utf-8?B?RmgrZ0xIU1FMT1pJZWNCRisvYWEvSUR3cjlRREwwaW5Zc08wNk96eVlaOWhV?= =?utf-8?B?T0trTVRhc0RmWlZWcitpL1U0WnI3blVpWnhYZWlJRlJBbS9iUnJxb2RRUUxZ?= =?utf-8?B?MUdWd3VDQmFvbEJ4Z0xMdlJrNGoxTDVrRHh6YnJlYU5YZGtFM2h1NFVHQ1ly?= =?utf-8?B?cm5ubmQ4Sk9KSFVmbzNnUVBNZDl1SkxGeWJuMVlQV2hJK1h1dm12Qks5eHdR?= =?utf-8?B?NnVSS0l6ZXZrYmE2VGlaYjR3SjBYUFFuMVFDMUw1R0NvYXQrejZHZktPVG9n?= =?utf-8?B?MklRNlNVOHdxWDhzZForS0pER29ORDl6aVplNi9KM0laMWZaQ0NIZXdBMERY?= =?utf-8?B?OTZSb05hVm1Jd1VWSk9vTXR1SXpjWTMvTk9wSWxwZC9zOVo0QmdqMk16V2t4?= =?utf-8?B?ajBsNkRaZHFNM0xwTFNwL2I3RG16c0d6V2wwWWZQOUtMMHZGRmlSdVN1UVEx?= =?utf-8?B?aW9VdFpQeVZNRVVFSXU2eW5ZNVZ6MWg0RDRVQUtyOFpHYTBzUGthczE5cnh1?= =?utf-8?B?Sk9SVUVmK0pQc1Q4UVM1czlIYmtjb2ZpT0ZHeW5NQVNUMmpuRS9FUm8vRE00?= =?utf-8?B?UzdMRnkxcUdoWWVzVlZ2elFxTUI5bktVSklsejJnaFJsOE1nWFIzSkxzd1RW?= =?utf-8?B?alZ6dExFeWY4VFV1d3hZdlhFVkp2WnRXQmVDazNnOHFiOUtpRnlaK29oVXFE?= =?utf-8?B?ckJ0NXlnbmlwK2kyaG9CeDdWMTUrSjgwaVZiL3pPUWUwUTdHcTFvNnU2T0ZU?= =?utf-8?B?RnpWNHZiUGxnd2tsMU4xR1lteEZSZlVKR3ZYcWNUdWc0QTZJL3U0SHJZSm1v?= =?utf-8?B?dmtjVFkvcHVPdlpaRDc1ZjJTSWEzeWpaRGozZEJ0U0p1MzlRaUNRUDJLWFN6?= =?utf-8?B?aTJ3aDZ4c3lLTUhUK0tNWUFYZG1CYSthL3RpVm9oTXBUaU94NmQ2L1BOakda?= =?utf-8?B?NUJaTDhFQS90UUtmZ3FrZloxcnJ5dWVlN0FydkJFY29nKzd4anpQaVB6STQ1?= =?utf-8?B?a2dFZk5sSGVJYVpET3VkNGhaczdzZm9vTjI5TjZRTmRROWRhNDh6YUFGUFk0?= =?utf-8?B?d283SXR1MVRDcjhrcXoxL0FJYVhlaWpHcUJRd3RJcGtKYzdUV05XbTB0UHQv?= =?utf-8?B?akhzbUhhbjlJSmRsb2xlRnZSQ2lRbkVrenZuNFlpNWE1RGpIM2lqZ3BLaU5S?= =?utf-8?B?NkhYRm9IU0MwQU9zZGdFS0JJaW80Vm9TTys4NHRQWFN6M0g2NzFIb2RyU0Vt?= =?utf-8?B?c2NtVmw0dnZCaFZEdk82UWQrTHRwUVhEQnBISUJSRittVnNza1dWUXFuemNL?= =?utf-8?B?em1RbVRvTkN5MlRvR2ZPM2dodm9QZ0RxbVI1TU1rNWdsemtLT2RVUEhXazhx?= =?utf-8?B?ZGZTNm1LRkVQN0FTUEtYRllKRWtvT1dIejNuVTZyUjVlenJhN1pVd3NjZWNG?= =?utf-8?B?cGtOQktZNE9LQnkvc2dDRFhvT0ZtMkgyQUdKMTRVRC9rSllDeW5xRkJ3Rit6?= =?utf-8?B?eTduMmQ5b3ZJRmhleTErdEV0R3d2QjcrY2xrRFc3SUh0VGdjVEhPRmQ4ZE1M?= =?utf-8?B?elh1U2IranFDL244ak1YdVhrbDhobkR6YkJwVTgzM21XdTY2cnhseUlKdDJy?= =?utf-8?B?N0l0eTYydDZWVUtOdmdRaC92NE02UW84a2J0QTd6VDU5MGptOU1kMHpHNzlY?= =?utf-8?B?QWFPSXhQVFJlQWc4bllIYzUwVG5ESTd5V3IwT0t2dzU5bHpqTjJkSGNpOFEx?= =?utf-8?B?Zk5JVEN4ekRKeGFQUlk3bVptYVpxWWRkbmpzVUxadlllQ0JJZFQ5S1BhVUF5?= =?utf-8?B?eVF2VHNYM21MVUc4OTgwVmxTSytUSnU4YTAxMkJFZ1Ixejl0Q05hMWptNmk4?= =?utf-8?B?dHMvZlAwcXlIWjlnNFRoMTg1SjZ6dnQwTGZyNXRDZEpUYVRmTjhzaEtxYS9Z?= =?utf-8?B?UXhzZEtReDM2a3RJK2F0VFdZcjJtVGxXMzJCQWRidXZxREphaW9BeGVyUGN4?= =?utf-8?B?SWxIUDZUSzZUSzZiTnZGTTRSdEthUFEyek92Z1JrS1dhSE5qY0FMYmlNaFpC?= =?utf-8?B?UEI4MkJ4MFlUMDBtd2pxSjNIQzFrTWk1OVlYUWRDSXRjV3h3M0pHRXdXMjBm?= =?utf-8?B?c2pUSGdqait2VUxwQ3BHRm42eisraG9OSHJTdWQxa1lWSU1wUW42QT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: e5244a43-e8cb-436a-cd61-08de5e5d1d42 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 11:05:15.1363 (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: unTCsNUaPPgM5IcMr+s1ZBRL3sqkAN8eQR4jT3e9Fz5KVvssI40B8SaBwlOr6gnjkqp/LldZjJ6DqLAnrGeKlg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB7226 Hello, The fist patch is a bugfix to revert to the previous way of setting the balloon memory target for PV domains. The new way is off by ~97 pages on domUs, because page at PFN 0 and the ISA range are ignored by Linux, but populated from Xen's perspective. Second patch aims to improve the initial memory target used by dom0. With this new approach the target set by the balloon driver matches exactly the target Xen by the toolstack when late-initializing it. Thanks, Roger. Roger Pau Monne (2): Partial revert "x86/xen: fix balloon target initialization for PVH dom0" xen/balloon: improve accuracy of initial balloon target for dom0 arch/x86/xen/enlighten.c | 2 +- drivers/xen/balloon.c | 26 ++++++++++++++++++++++---- drivers/xen/unpopulated-alloc.c | 3 +++ include/xen/xen.h | 2 ++ 4 files changed, 28 insertions(+), 5 deletions(-) -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 28 11:05:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 11:05:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215407.1525601 (Exim 4.92) (envelope-from ) id 1vl3MV-0002V4-4X; Wed, 28 Jan 2026 11:05:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215407.1525601; Wed, 28 Jan 2026 11:05:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl3MU-0002Uv-W7; Wed, 28 Jan 2026 11:05:26 +0000 Received: by outflank-mailman (input) for mailman id 1215407; Wed, 28 Jan 2026 11:05: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 1vl3MT-0002H5-Of for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 11:05:25 +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 3e6f1715-fc39-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 12:05:24 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DS0PR03MB7226.namprd03.prod.outlook.com (2603:10b6:8:124::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Wed, 28 Jan 2026 11:05:19 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.006; Wed, 28 Jan 2026 11:05: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: 3e6f1715-fc39-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=L1wm07pkd8OvyrWSPVbAMBEOc4AAWae7EyFc77DXkPfTvsrtMBDt9N/8Fn7qo7IMzZR/RokkLW+Z0zYN0tQ0/N2Tur0wXWMZPblowRiDy6vi2P/84XvaV3IhRAdfKHkmfnVlYxpqeYuGo1qA1JvNEoecPKbtagCzUl0ctvPqKIVfhjJWC/e+fGvu3YNDFTzTQCxb1gMZwaDN6qvtZVPICHiWnYj71NlV0M4aSYzivgpN6mS2VmEH9fr04lupepeB8KIK43qmk7ECuSdEiTmp7mfJr78DPOPI1oLL0tzeznP1Z7n+oO0HHzRhkLYkrPzLmOC9sZUBWO39WXid5s8cOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lwEXH8Rbp648Hl7Vcy1v985tUSIx+/75NB144wvPfV8=; b=PZk8dFwI80au+t0ps89ZIpC+UPPSHvSOHp4EUo/swPjBMF/ao0u/1vNqtzHiRq0Y6PbFhgqUv39RthgAi53ApqHAVlNPvszbcFAhOK26L0qZyynMOwd6fchyWU0MIrwnxf/dHzUz6BAaVRBgnWecu3hk94jx6IOkQ0LHBRSPvEHzv2EmCequ9ZE218ZbomuxNRAWQIVDAdQRuLZIXamvyxO5Va+TiCeIQON1HDwM4Bu7jY1AapqZJwBq4xCMBm11gsHM8kTwzxGZqLSzapq7kw0r5fOj/6oxM2Z7m8aH6os8QhRBhS2Kkbq4yMOoonaCvs8DSyRFDkcfq0M/uJnefw== 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=lwEXH8Rbp648Hl7Vcy1v985tUSIx+/75NB144wvPfV8=; b=obXDicteBkNv/L3vUqkNDaPOZ3TKi3Y4dGDBU3HOSGmbtmXvakokN6GIoIIur0R0WJg57h32PN15Q+C64263F5srBcNHDMoE0fy/Gr+I0NhkZpDwqMyfiW0fpWX45OSdhl7rq7awZsIqwXM/IVfgRPAs8r+2e6wsvrpYN0b5ND4= 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, linux-kernel@vger.kernel.org, Juergen Gross , Roger Pau Monne Cc: James Dingwall , Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Stefano Stabellini , Oleksandr Tyshchenko Subject: [PATCH 1/2] Partial revert "x86/xen: fix balloon target initialization for PVH dom0" Date: Wed, 28 Jan 2026 12:05:08 +0100 Message-ID: <20260128110510.46425-2-roger.pau@citrix.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260128110510.46425-1-roger.pau@citrix.com> References: <20260128110510.46425-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MR1P264CA0211.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:56::13) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DS0PR03MB7226:EE_ X-MS-Office365-Filtering-Correlation-Id: bf2bf0b4-ed07-4beb-9574-08de5e5d1fd8 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?a0pacGc3WktNVzVnMFgySDFrampoSnlRb05BMkZCWllBYitaZERqZ0hWdytT?= =?utf-8?B?Mmh4ZnVZeWNRblU0RGxKT2ozRDUxL2NzZUdyRll3NHEyOEdkM0JiWmdRenUr?= =?utf-8?B?aVk2eFJtdEZrS1pIS3lLZnlrRUZTNURlZkkrZExTRE8vQXVmSzZiR045bDRx?= =?utf-8?B?ZG5yUkZndWdPWm9RM1paRmdET05pMVlRbTJvekxQNTcwNzhJMUlrOHl6V29m?= =?utf-8?B?eHV4a2tGVU01N3BHNXYrV0ZWZTIrS3JmbWdaMFI1bkovRjJGbFpJaFdmMlFx?= =?utf-8?B?QlJSZHpHaDFmcm9yZnBmKzFKY3ZOT243Rm5jVDh2M044MlNiaSt4Q3lidVg0?= =?utf-8?B?MFhnelFKSHpDQm1xRysvOEJ6VzNzdTFFQ3VkNmJISWRNSWdzTzI1NHBaWEVB?= =?utf-8?B?U0IzTVVPNy9BNU5aN3JhQ3JpODVBYlViSE1LY1BIZWlFNDlScThLZVlxbm5W?= =?utf-8?B?bFJRVWRxSEpsbEs5L1BmM2h6a3FtZkN0UlJvT1dxREVydjIyaVRhRVNQNHFk?= =?utf-8?B?YXF0ems4eHBCWklsQVkyenA0clpBcDBUMHl6SGlIQmQ0aU5jcWQ1Nm5QaENm?= =?utf-8?B?VVF6d1RscG1PenlvcHRZL2JQWWRESWNmc1R3SFBHR1JBNWlVaklnRmVISjZa?= =?utf-8?B?T05vM0tZSjFWVEJSME1BQTF5TW9VcDRsakllcFJjOHRML1NMc2lPeWVKaFJK?= =?utf-8?B?ZWZISjYyNVdXOGpqYUordUYwNTN0dlZjTFNsdENBQU5teTJiamNyVXZtMXlx?= =?utf-8?B?TC9JcGx4RHhSU29WRXVVMkZKYTVGck9kS2l0OFBRR1ltM1Z4VzM2Q3JFVVh2?= =?utf-8?B?UVF2N3pZdUJpNFJqdFVscCs1eTdMcTJGcGh2aEt5TXFqTHBSbjBKMStVc29U?= =?utf-8?B?RG9NU3dPcUhLWUhyRE5CMjFVV09uSkNLVFZEVm9UT0JjTWcyclFaQTRCYWlP?= =?utf-8?B?MDRNaEhSWGd4UEdYdm15NVJaRGlvemVNaW04ekliV0IwWGZkVUY0d1BIV0ps?= =?utf-8?B?UlRaYjZMZTlXVnRRZGloU2xJRkl4cTdIMWZXSnlpcTdURTRVL1RoYTEyRThF?= =?utf-8?B?SGNvQkNqT2NtS2F2N2Z1MUJVamh4M1RHdzFBVzY4cmlycHl6azl3Tmh3dGY3?= =?utf-8?B?SlhINUJkL0lqcUdWOU51enhnZUtqaENDd1hOOFNSa2pNZjNXaVNFcTBHQzMx?= =?utf-8?B?dk9jbHk2L0I0Q3FibXg1bEsxemhYZDU1N1lnOGRTUlBjbFpPM09VdlpQWUxi?= =?utf-8?B?UWMzT2J4dWZuNUM4SnNrd0xySXFBbEZOYWI2bk9rVjdWMHUrNXpJQXpKazE1?= =?utf-8?B?MG9YYVZVMW15T1g5NzhZa3pMdGdJcTBYc0QrQklzYWs5eXlLcG91dVV6M1I3?= =?utf-8?B?ZmNlb0JJdGhGWGtTTldPRmIveHVVZTFqOGcwQi9SV1hnbU1OTGFWelp0MFd5?= =?utf-8?B?Uml6QjNFYkdHeHJ3U0h0QWVqSEpMTkswRHFLV1lkNGxVamVsYVV1Nkh5UUhn?= =?utf-8?B?TElOb3ErRUxBMnREOW5naDJySlVjNW9VS2t3VmtaTXdTOTNIUlFablA3bGVz?= =?utf-8?B?OXdBRnJNYS9aeXNwTVkzcVRRSnJYbHNRd0RkTUtoNEF0VzRaNzBId2lHblAz?= =?utf-8?B?WXR6VFkxb2pobFN2WHBPeTUyT1NEQnlDVXMzT1ZubHBkOWdxRFJqSzVGZmVZ?= =?utf-8?B?QUo3elpWQ2Z4Y1NPNXR2V0F1VkdCSi9iZklFVUZwdzVqaFRDSGJtWTJ0a2k5?= =?utf-8?B?Sno2NUhaK3J3VTlPTysrN0Z0alF3b0dLOHhVT0VHVTcybFIwbUV2Z0tjZ2dx?= =?utf-8?B?U3NvaThFZlVBZ2JDSGJtSmNSTlN3bzhrWlUwN052Y0pobkY3RG9jck1PREE2?= =?utf-8?B?M3pvYkt2T1JoL0kyemZqQlJwdGh1UUJJVm1vSm14OXRTaEhzNlZuUVgzcTk3?= =?utf-8?B?VWVsdThZUmc0akFpZVdGOCtBZHhBZTZLRGZzMzdvdnFvQlBDRXM0NHpTYW44?= =?utf-8?B?b1NZb2JCMzREckV0K3h4aE1abHF2dTNMQldvQUY2ekNKQThFWVU4Mlp6SHA3?= =?utf-8?B?VmVrR3JzajVtRlFuR1pjclJEd1hUVDJsNjl3eDhGZmJyV3A2QjQzcU5yZXh4?= =?utf-8?Q?+SuU=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(7416014)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NDZqMktrblJsdmtCRGxIUWorOXVtV1poRWJhY1VaV0VhY2tWK2F6VkV2MlRh?= =?utf-8?B?Zk5ZQld5OUhaait0WDR4a2tFdHdVbGVZY0ZhaloyQzJzTFdQNXE4aUg3cy9V?= =?utf-8?B?R0tGQWZsOEIxblRJNlpaZ3pHQlYrQ2w2bE00MFhIaGlqZjJObDlOcTlHdVdL?= =?utf-8?B?RWJpLzlxS3U0cW5jU1lWb2VCTnJvL0VnWmRHeTNSZ3pHcmlHMFRkc3pweE1Z?= =?utf-8?B?eU02amhvRitGZmFNWXBSV1htbnY3dmd1S2UvRGpLeTR2M0g1K05qZXY3VnZi?= =?utf-8?B?VUdEYzIxVWhkS1ovN2pJdDYrZWR6MFViSUlROVhWb2JtOWFzazE2TDBQbzJ4?= =?utf-8?B?R2lSM3locVUzOWwwU3BPcm9WVHhUL0VUZXdpNXlQVDJKY0NtMXhmamZFTXZ6?= =?utf-8?B?RkdsaFpvUWxDaTFEM1Z1Q2J2UHl4SnRBMmhhSG9rQzNwUHlZYUhTcTdaVllZ?= =?utf-8?B?S0tMaGFGNVpZUjZJRzNIYzlCRHBoczNpbXdmS3ZOQmVPcmtPOWpBRXJUR2hm?= =?utf-8?B?d2FQU0JyQ0s3YzBDMHpWUVBjalVzRFlIUUNyem9JdStodVNUcVZUQnlIZ3A4?= =?utf-8?B?SFNOZFJkSURnVGFCWk5lbHI4Q0RoSVprUHE4VjBmWUNmMDlYVGxnUnlmOFV6?= =?utf-8?B?WVU3SEtYRlE0d2FTam03dVVhUmFtYnY4eDl5NVd4TmpKTXoxckFybER3UEUy?= =?utf-8?B?Q0F4RytQNkhrczlpa2hxVzBIZTROWGZXTVRrakI4L0xOUjJQb3JLZVJSWEwv?= =?utf-8?B?TU53R2RaMEI3SzdaZjFqWUJaTjdLa2drNExsYWxySGF0aWdhaEhuK0R3ZVdD?= =?utf-8?B?VEZhZml5T0FWaDJBVGNXU3RhSFpYUHJaQUN3NENTcHRkdDM4RnFacGZUYVRP?= =?utf-8?B?eTFTdy9HZWtlRlRJVzMwVGdic0RZblhCd0VGWURYMFBUYm00cTlJYitUYjZX?= =?utf-8?B?cC8vTjlYekcyZkhGYm8xajIybEQ2VysyUThDVEl0dGF5cDJzRTVtaGpJU0NB?= =?utf-8?B?NDg1MkNCb3B2WFQ5c1JFVm5sVjg3T1h4alJ4NVhsWEJNQXhmUS92N0paY05U?= =?utf-8?B?ZEN1K1pzdzI2YnI3S3BOZ002NTdrYjhPVlBjMFhTa2s1SjNKclFYNVdwMlIx?= =?utf-8?B?SGtTOCtuNXA2MTNqaktISk9BK0pKTkRES042dHhLaWdoaVM1cDRtaUNHS1Bv?= =?utf-8?B?UFJJc1p4UHl0dFpLR0lZdVJCRmgvckxnSWpiQTg5eE5LUG8xVDFBTUdMU2FX?= =?utf-8?B?azN6dTRmd1pGbXc3SU01ZG1MeVFZZWhFci9uaTlOdFlZL2JOVmRUN09qNE5H?= =?utf-8?B?WVdGUU01enhlczM2aFpCMjNBZlhWZnVoSDUxaTFsaXd6K1NLY24vNStWa0dj?= =?utf-8?B?SHEvWGJhWmNTTFh0amFaYVZQWW1oL0hnaEhEL0FSQys1Y2lmMXc4WTB5RzBM?= =?utf-8?B?MVplR3NMcUlqM1VzUmpXT1R4amZtanZQSTNpalBtTkl3WDVpbmhoVVcreTZW?= =?utf-8?B?Zjc1S1VqZzJkZkZDcnphc01INjhVL1BwbmJOMEtGM0xrVExabEJvcmZwR28v?= =?utf-8?B?S2NCMnd2cU5QZ1NqcU9yL1dMQVM4MzViVWQ5d1A0UjhvQ1NzckVPcFE4OElT?= =?utf-8?B?UmRxMDQrWHJLUTZUVnlmSGxISTJ4MEdmaWJUekx2L254a3BZR2hvWURERXdl?= =?utf-8?B?cjJrVVQvcmRac2YrWVlwc3ZGbG0rdU9ZSXd0cUJnRkFQdVlqb05UMk5DbWFH?= =?utf-8?B?Zk5YMkdjTjNjQy93YzF5aUlhWXhsSWx3ZjZNYlFQMkJIN1FzQ3Awb2c4aXV5?= =?utf-8?B?ZjBzUExkejJ6ZGIvbmMxY2xXd1RycFd5dkJJNjdTV0Q5ZlM1ak03SlorclJE?= =?utf-8?B?K3UzSlU2cmdiU1dLQWIrRUZNSlhDM1UvaDhSQ29FcE12enhSR3AyVUpVS2Zz?= =?utf-8?B?TmRoUzd0WXMrYkYvejBjeXN2S2FucnFGL1FoNWhLZ0pPcUNxc3FhMVJha3d2?= =?utf-8?B?L3BlZUdvbjl1ZVJsUlNrVVcyVzdXLyt5VUtaK2hRaHFobDQ3cnRDNWZSU290?= =?utf-8?B?Um5zTy9sUDBUSm14dE1pUkJ3M3ByWDNSOWFzNFI4Qko0RWlFeDdFU3I4cTdm?= =?utf-8?B?WmtYQzZlRCtXOVI3RVRvM3VBQjRSd1RSOUowK0JWdjZMYlREZm9mSGNDdVVl?= =?utf-8?B?cm5IcVAvanpIbXRmV3VFUXBqNEQwRXMrQU1wRHBMSlBSSmdTN0lGVkg4VDgr?= =?utf-8?B?U3BqUFJCSFR5Vk9vOVRDRDNvLzFPVEhzOTdha2hCMXNKcjhzMDNmUStpUjlk?= =?utf-8?B?VVNWMllWZ1l5RXVpRGtjMGtOMlg0czdNMVI0dVVnSHVQVDd3R1dlZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: bf2bf0b4-ed07-4beb-9574-08de5e5d1fd8 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 11:05:19.4042 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 335836de-42ef-43a2-b145-348c2ee9ca5b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: rlrAql39KKVV6jcmDJOO6WS+A5SYjB9G3lx2XfmXMVs+eZx63fk4UQlPIEeAmKOJm51+w3cU5V8vBp7oIl5H+A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB7226 This partially reverts commit 87af633689ce16ddb166c80f32b120e50b1295de so the current memory target for PV guests is still fetched from start_info->nr_pages, which matches exactly what the toolstack sets the initial memory target to. Using get_num_physpages() is possible on PV also, but needs adjusting to take into account the ISA hole and the PFN at 0 not considered usable memory despite being populated, and hence would need extra adjustments. Instead of carrying those extra adjustments switch back to the previous code. That leaves Linux with a difference in how current memory target is obtained for HVM vs PV, but that's better than adding extra logic just for PV. However if switching to start_info->nr_pages for PV domains we need to differentiate between released pages (freed back to the hypervisor) as opposed to pages in the physmap which are not populated to start with. Introduce a new xen_unpopulated_pages to account for papges that have never been populated, and hence in the PV case don't need subtracting. Fixes: 87af633689ce ("x86/xen: fix balloon target initialization for PVH dom0") Reported-by: James Dingwall Signed-off-by: Roger Pau Monné --- arch/x86/xen/enlighten.c | 2 +- drivers/xen/balloon.c | 19 +++++++++++++++---- drivers/xen/unpopulated-alloc.c | 3 +++ include/xen/xen.h | 2 ++ 4 files changed, 21 insertions(+), 5 deletions(-) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 53282dc7d5ac..23b91bf9b663 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -470,7 +470,7 @@ int __init arch_xen_unpopulated_init(struct resource **res) * driver to know how much of the physmap is unpopulated and * set an accurate initial memory target. */ - xen_released_pages += xen_extra_mem[i].n_pfns; + xen_unpopulated_pages += xen_extra_mem[i].n_pfns; /* Zero so region is not also added to the balloon driver. */ xen_extra_mem[i].n_pfns = 0; } diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 49c3f9926394..8c44a25a7d2b 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -724,6 +724,7 @@ static int __init balloon_add_regions(void) static int __init balloon_init(void) { struct task_struct *task; + unsigned long current_pages; int rc; if (!xen_domain()) @@ -731,12 +732,18 @@ static int __init balloon_init(void) pr_info("Initialising balloon driver\n"); - if (xen_released_pages >= get_num_physpages()) { - WARN(1, "Released pages underflow current target"); - return -ERANGE; + if (xen_pv_domain()) { + if (xen_released_pages >= xen_start_info->nr_pages) + goto underflow; + current_pages = min(xen_start_info->nr_pages - + xen_released_pages, max_pfn); + } else { + if (xen_unpopulated_pages >= get_num_physpages()) + goto underflow; + current_pages = get_num_physpages() - xen_unpopulated_pages; } - balloon_stats.current_pages = get_num_physpages() - xen_released_pages; + balloon_stats.current_pages = current_pages; balloon_stats.target_pages = balloon_stats.current_pages; balloon_stats.balloon_low = 0; balloon_stats.balloon_high = 0; @@ -767,6 +774,10 @@ static int __init balloon_init(void) xen_balloon_init(); return 0; + + underflow: + WARN(1, "Released pages underflow current target"); + return -ERANGE; } subsys_initcall(balloon_init); diff --git a/drivers/xen/unpopulated-alloc.c b/drivers/xen/unpopulated-alloc.c index d6fc2aefe264..1dc0b495c8e5 100644 --- a/drivers/xen/unpopulated-alloc.c +++ b/drivers/xen/unpopulated-alloc.c @@ -18,6 +18,9 @@ static unsigned int list_count; static struct resource *target_resource; +/* Pages to subtract from the memory count when setting balloon target. */ +unsigned long xen_unpopulated_pages __initdata; + /* * If arch is not happy with system "iomem_resource" being used for * the region allocation it can provide it's own view by creating specific diff --git a/include/xen/xen.h b/include/xen/xen.h index 61854e3f2837..f280c5dcf923 100644 --- a/include/xen/xen.h +++ b/include/xen/xen.h @@ -69,11 +69,13 @@ extern u64 xen_saved_max_mem_size; #endif #ifdef CONFIG_XEN_UNPOPULATED_ALLOC +extern unsigned long xen_unpopulated_pages; int xen_alloc_unpopulated_pages(unsigned int nr_pages, struct page **pages); void xen_free_unpopulated_pages(unsigned int nr_pages, struct page **pages); #include int arch_xen_unpopulated_init(struct resource **res); #else +#define xen_unpopulated_pages 0UL #include static inline int xen_alloc_unpopulated_pages(unsigned int nr_pages, struct page **pages) -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 28 11:05:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 11:05:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215408.1525610 (Exim 4.92) (envelope-from ) id 1vl3MX-0002km-Be; Wed, 28 Jan 2026 11:05:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215408.1525610; Wed, 28 Jan 2026 11:05:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl3MX-0002kf-8Q; Wed, 28 Jan 2026 11:05:29 +0000 Received: by outflank-mailman (input) for mailman id 1215408; Wed, 28 Jan 2026 11:05: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 1vl3MV-0002H5-Jb for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 11:05:27 +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 3f906b49-fc39-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 12:05:26 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DS0PR03MB7226.namprd03.prod.outlook.com (2603:10b6:8:124::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Wed, 28 Jan 2026 11:05:23 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.006; Wed, 28 Jan 2026 11:05: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: 3f906b49-fc39-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=yYG83KAQ4n5w6HBGVGYMmZaudddUqSOQFczsESZZzi+n3rnj3Nn7lFWnDA778lp2nZlOB0RkHWGGcP1FzdTfbQhAugv4DhfemKzTrPMyCQgVc3+X8Cn74Qt1oFk/GoVDHDRTnuSKcoC8hjkENTOf5SBOcVkXLMXTKCTLwPX+mxHkUfBqRA37cJpy7yecf/gZ2MEtMNfufY2Vc8wem88jgjxtBFvxnxObqzfP5AOtsozcNUKjjAikX2NLOYXRP1CxUo/RIt19OIDeIClyxnOmMnVBDU7EHbz4l64hcisygpQGTr6+Y1/FrJHK2G6MqlHQBeJx8jrmMUC/hsmBe8WtCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6+NJhugKUI8XfeUu5jC3/2LyubMrallgBTyM0xeCUkQ=; b=PXxUUSWdtiwiXBzti1iaioM+RFMGX8tJwDtqH6mGsd2p7pKacb1xBmyi/OoJmykkAOxSjU19knfZpY4B2NFSw9NB3wSyURk2zh9YXrPcvB9gM7WUdYWwtBWtYrUiSctCov2GPjZyLiOrMOKa1skkVPh0d60Dg9u/mQ7nXi2vEVurnZTzZPSoXLo/24Xw74fX8+kzCq0IoNmGN5NYf2Rv52ghX7VQcd/h56Z3HNOviRkkZucYWVNy/MGoAll7XEea+UwjL0pBqcep51NWU6vV55FnOdbUuMXGNH6MdX3MydNSP0HjC6rsapVvcW8rp3HJIy+rixCLMsdscSLoVuwbqw== 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=6+NJhugKUI8XfeUu5jC3/2LyubMrallgBTyM0xeCUkQ=; b=y46yoeKhfAaisexDmL0CNQaiXfRfR19HdBy9OiKH8btMUYHyybHEPsYC5AbMq4piNFyf+Cv3OzHaeYCu6x5b3dIrLGoqHB/SBzxBy+76Hxvhvqh8mY2qtt9y+SkdxDGBxlWiQU3ePL5y926/s2IN0pGr98mOck1BRkqB/PdgVKc= 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, linux-kernel@vger.kernel.org Cc: Roger Pau Monne , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Subject: [PATCH 2/2] xen/balloon: improve accuracy of initial balloon target for dom0 Date: Wed, 28 Jan 2026 12:05:09 +0100 Message-ID: <20260128110510.46425-3-roger.pau@citrix.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260128110510.46425-1-roger.pau@citrix.com> References: <20260128110510.46425-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MR1P264CA0065.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:3e::24) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DS0PR03MB7226:EE_ X-MS-Office365-Filtering-Correlation-Id: ab2d79c9-0f5a-4400-861d-08de5e5d2267 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?dGo0OEtqSUd1cU9xeTc2MkhxUFVYdzAwRFRrYjRSTk9GamRUQS96SWxVbnlt?= =?utf-8?B?UjRpVk4wckg2WSs4R01OLyt4STJiY1RDdWxDODRRcUxOZFpiVHdEQWRGUHJ6?= =?utf-8?B?K1FiWTc3SnE0UCtPdXpDMHpiWVd6d0lhc1VjNHh1b0FubnAycDJmQU5GM3JW?= =?utf-8?B?TDJWemV0NmhWYThNUzE0SnhJUW1WTEVuWDYrOFN5NFlxK2VPNnhueGsrNnFw?= =?utf-8?B?VUoyeHdhbjZDYy9HMWgrUW94RkZFakViVnA2R2NXQXlOYnY4YUQ5Vm5KeVNR?= =?utf-8?B?cnJmK0NqT0VlYkJpSmNvYWVLV0pkYzlTeXVkbU1DY0YvMWxNUktlbXI4elJi?= =?utf-8?B?WTl2dXdDYkhQUG5wT1V0RCtRVkxjc2Y1WjZTazJNNDkzenk5dDhxTW5JT0V4?= =?utf-8?B?UklDT2VBVFByZVZzcExSZ0oxK0JFU2ZFTXZEU2ZnRm92OStQOGVuWHBrMk5i?= =?utf-8?B?TE1PTG8wWjg5emZYQWJaVzJFZStpbkZtK1pWWlU5SHFENzdLMUt0cTQzUmtP?= =?utf-8?B?cjVydzFOcWlPRWM2QlRWVWlrOUdhT0crd21wVGExTWtIVmFoK08xMEZyTmFm?= =?utf-8?B?cXBweDNFdFJEcDRWU1Erd05KaDFHemdmZHpHSURhVVZpSTlYMlFQbGZ3UEEr?= =?utf-8?B?RWRheENJV2tLWVlnZDBrdGM5Rjhxem9kaHNpYzQ5T09Kb3FJK1JQcEIvMFVI?= =?utf-8?B?ZE5WYkQrWVlRaXFsbFNmbFpuZm5LZDlrMU9kOWR6T0Y3ZGZPT2NsZHpzd3BK?= =?utf-8?B?OFk2dUxIQWdCMHQvK2plMXdYYkM1NTd5YnhNUm5wUkdCcU9maUJ4bnZKR1dL?= =?utf-8?B?TnlWUXdHOFRwaG82SHZpZEVoRkt3ZExpTVZpVVJsOW1Gd1huRWlHY2lqVE9G?= =?utf-8?B?TjBReUNWUFpjZU9TQ1dSREVNcXlsYzVIVGVrMFVocFc3M0VCNWM1TGJyMG1X?= =?utf-8?B?WmFnMzMveUd1OGJKcnhtem9BK0dhb3NDakpTcXBCeEVYbE4rRGpHOFZGRzRR?= =?utf-8?B?T1dqb1l5bE5VVVl3SDllRFQxVTdjTWN1Q3c0YktsVitwbkVnRGJBTHFCbGhQ?= =?utf-8?B?R2RGOGxJL3paZEM3K0VGdzNPQVRiSHV0MUxmTUZXYS9UVkYvazVIZ2RqcVds?= =?utf-8?B?aXE0TzdQRlU1VElZZFU0R2UxcURNaUxPOFI3TVM4ajdOaDZhblZkNERLUkFR?= =?utf-8?B?QVhpWUIwY016dXhrU3hNMllLb2xoWDVIZFhiazN6eU4wRkpTMjc0OGFZalUx?= =?utf-8?B?T2VDSHNOUjdhQ2JnMW1VU0h5dW80Lzd0cE4xOUc3d0RhMW1FdHRuOWZxK2Vu?= =?utf-8?B?YUppY1dEaUhWWGJZNnFjNmJTTi83di8yTmQ3VXppdDZBeFZsK3ExMGE1WVJq?= =?utf-8?B?cGVTZEU1cWtxWVI0VkZsZFhrd0Y3QjdDWTQwcThMdG1LQXRxQ1Y4dlZ2eGtl?= =?utf-8?B?M0Q5d3gxYTZ5UmR2NHpwTGdUek44ZzdYa2VESlJ5T0dYYWpqUG1CVXF1YWZ4?= =?utf-8?B?cXJkdzc0T2NnRkQvbHgxYWlpTE0xRVl0TVc3bmpVUm5TVUZLQ3pyUnFDSW9r?= =?utf-8?B?a0hQaHREdkxHdnZ6Nm9oYkxmTjlONzBuUDBwcDlKaTNOaXZwOUdIZVBnS0hn?= =?utf-8?B?V05Id2ZlbHowbW9mbHhlODdvTkkwYVJhSTFqNjRNWkNlZzJiZWt0RkptcW83?= =?utf-8?B?M1RQS2ZwbFk1aWgyUDdhRWFrdFhTVW5Vdm1va3I5UXJmR3c1NFJQK0g2Nmdp?= =?utf-8?B?VlE1bFNzMUg2b2tJQ3p2bEhWRGxudDVNRHdXb0R0ZlF5a044aEg1R0Q0NnR2?= =?utf-8?B?WWxjR3dlQlhIdm0rc1NMQmwycENvVVdnZ1Q5dnJaV29heGxqRjl5bmRYU3gz?= =?utf-8?B?YmlGSXFXTFNTTStFdDhtK055b0E2N3JxQ25jRExxWll0RWxEeEh6OUN1Wlov?= =?utf-8?B?akJXWEIvbTVTT3FnNlFza1AvR0hpTXZyZHZDRjJlMi9SOWhvRVhUa3Q5UFQr?= =?utf-8?B?MkZEZ0UraUNnK2ZEQVBZVGY3cDd5RXR1RFgraksyR1k5MU9qQ0UwL0lsUmtu?= =?utf-8?B?SVh3emhrTFcxQWswMnNzOFZsWkhUckN0ZW5jMFJRbnA1T291eFNtNjBReEFv?= =?utf-8?Q?s9yo=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?U2dPNEtCR3VvMHhOa0JSL0pKN2xuWGEyUnFZZ29DT28vTU9zbjlsbnN4WWJT?= =?utf-8?B?Qk9WdmN1QmtuTGlRUkxibGF2K1VEdFhpRnJVZW1hZUlpdTVpZVZDdmZOUGRZ?= =?utf-8?B?MFJUWmV2OFlDMjVhMHZCVmVGdUVoT3JyY0d0aE1pRnRaSDR0UEhrWmZHOTRt?= =?utf-8?B?eHlLQWxQYW85bXBBdnAzRml3aUxzenhxUXA5K0I4bzJJbVVPS1NYMWhodGRB?= =?utf-8?B?WVZoSHozaHNKK3lUbjZBVEwvUXF6Z085TTlvQlYyTVJpMHpVeWNEeUNEREdE?= =?utf-8?B?OFRZZEt4QU5ZZUpvdkNLMmFzNllYQVgwVWJUNFI4dTdPS1RHVXNKdHpxRmlk?= =?utf-8?B?N0I0R1pnWnIrQVBMWk5raW5hZGZTL2Q0QjV4bnFOYlFVdVdrQnE2b3podDZy?= =?utf-8?B?TnBpSmt4b0g5NWlJOUxycFRQbXlRSXpKRkN1akYvTmZ2YU1qTGRXYlhWS0Vy?= =?utf-8?B?VDBzUlZMWWJ6MTZuMHdXT2JiVkp6dC84UkRIUkhhVTQ3Z3ZVT2Y4TWFNZmh6?= =?utf-8?B?bU5XVFhwT2M2TFR2czltQmpMUjEySTRXcStwNWdUeVc4TXQxY09tUEd3T2Rv?= =?utf-8?B?MTVlRXBjOXB5cExrc1YrUGE0S1dBaDF3Z2I1YjNqbkI2bFpHTWxQdXV6TllV?= =?utf-8?B?cGVhTFdCUFY0ck9ybjAwb1lWak4reHNEZ1RsWGFTNHFLSFhkbFRVYkRkcG42?= =?utf-8?B?cHJlQUVTK0NmQ1l4bWR6eDhJUVRrejNjYTVHYzc1cXRHY0hkOE9JZUhWWVFn?= =?utf-8?B?M2gwenFEOURGZktWMFdnb2tMRDlueEx3TzRwUjNJbHUrd0RhZjJmb0ZFbDN5?= =?utf-8?B?MFdpTDZRQW05aFprOGdjRlI4UnFFaFMyb1dQS0haMzBqNTdCbFozU05DelpI?= =?utf-8?B?dEFoMWtYY2o2cVUwWnIwNklGOFBrR1h4RWErL3lvYm03TVZoUm15MEJQdkdw?= =?utf-8?B?TGIxUGNnZ21SSVhUVlJ3KzVhQVRPU2paeDVWM0ZOZE1oTFFvNlVtSWwyOEgz?= =?utf-8?B?RC9ZVVgwUWptMi9ZYzFiK3ROVWVWY3dxUmc1QmRpcEFreUl3RjVOdnppZVpP?= =?utf-8?B?MXlBNkRTN3ZmSGVpay83YUVOUFhuTUZUdU1DZzdGbEQwTGd6SE5JVnBZUWhR?= =?utf-8?B?c3IzYWFpTWJsbVEyQWhNV1R4M0QvbW9IR0NvNnFBS3BxMjB5aUV6d1VOTnMw?= =?utf-8?B?bWFMTkhlTk96ZDhYNFRjSW1rR21vZUZTWC9lQTBKb3dOOC9ORjlPYTFxNzEz?= =?utf-8?B?VTZablZKL0t0VFRMckNpcW9haS92SXh0UTdld3l1V1NnTFRYS3Bpdm0rU0wx?= =?utf-8?B?Ykg2TGg2WDNVQlF2SE5rOFhUclRseHhoRTdhYnRsMHMrWk9nS2h1VlIwQ21U?= =?utf-8?B?ZC93Um9WTnl6T1BYOEM1UjA0My82bHJWaXJEN29TU3F0ZVBXK2F1ZFE4aG9G?= =?utf-8?B?T3poVnNlcnBDSW9RZms4UVRES2lxUHdTSlc2TEJkMHEyUy9PN1RsOVQwcGhB?= =?utf-8?B?ajhSNW9mSWhlZlVtOERHMk5RKzU0dmw2eC9DUlFxYWo0QmU1cWY3VXVrbUdH?= =?utf-8?B?QjloQjBWUlNtRTVaNCtxWisrZDRzdnVYc3lvTjI5UDBLUXVRVGgreUlENGxC?= =?utf-8?B?QXNPRnFSbGlOcTNpWnd0bVN4QnExL0V6VGtnTW1HL3JHY0VQMldCRjlBOXZ2?= =?utf-8?B?cHgydk43UlllUVJpMEdJYU1GNjQ2NWV5ZHhhM3NRL1lpT0NrN3JyQVZ2WUhI?= =?utf-8?B?eUZxY1F1alBpYnFkV2lUSlU1d3lYYndLWEdtWlFNUGtXT0dRcmRjUWQ3Skph?= =?utf-8?B?eXZXVmVpZ1J6c3hsTGlRTU1QekdSbEQxSWRpOHhERnY4NnhnaUloY1NVamlW?= =?utf-8?B?WUhVRUtQc3RGWE8rQUJSMHNFVGFMNVNoM3ZBK2N0eXZ4RGdxVWczUi9abGpv?= =?utf-8?B?dnYybW5jdnJhSzlOMkdTcCtrQjFOKzdINHF5eUt4TmtURVJkb2FxUTZKMHRX?= =?utf-8?B?bWh2bXA3WEpFWVR6cmF5Skx2eGNXZXg5ODdnZmtxSTJFc2c1NGNCU2c4RzEr?= =?utf-8?B?bjNEZEkyWEdVaTMyQVVNYk1wYkJ1d2lHd3lqOWE5Y3dhTTlSTUVzNytSM1A2?= =?utf-8?B?MXRyeUpNSEMzOWU2M0ZUWVRuQ2N0Y1NjOGRaMHZSa2l4U3FPNUxCN3A3cGlN?= =?utf-8?B?ZDBOZFpZbGpWMTdHQ0d4RXgzZGJnT2hJSEkzcnBnUVJvZ3Y3L1UrTmdkNlRn?= =?utf-8?B?OTYzUC8vYjIxa0FPTUxvUE8wNG1RZ1dlQUtaTi95TmZIVUJVdXpBQXFuaVlw?= =?utf-8?B?VndqLzR2ZjJLNnFiQWZ0V3pVMW1rU05IT0hSZUR1SWQ2N3hRVm1FZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ab2d79c9-0f5a-4400-861d-08de5e5d2267 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 11:05:23.7191 (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: 153ALN6uSgsvk03gWLweub8CWXXFa5sXvFXRyS3uKeG4UNKMWhHmjAEisoSaWb0MQFXCPqTkaZwbqQaIyr1YcQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB7226 The dom0 balloon target set by the toolstack is the value returned by XENMEM_current_reservation. Do the same in the kernel balloon driver and set the current allocation to the value returned by XENMEM_current_reservation. On my test system this causes the kernel balloon driver target to exactly match the value set by the toolstack in xenstore. Note this approach can be used by both PV and PVH dom0s, as the toolstack always uses XENMEM_current_reservation to set the initial target regardless of the dom0 type. Signed-off-by: Roger Pau Monné --- drivers/xen/balloon.c | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-) diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 8c44a25a7d2b..9b6531eb28b6 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -724,7 +724,8 @@ static int __init balloon_add_regions(void) static int __init balloon_init(void) { struct task_struct *task; - unsigned long current_pages; + long current_pages = 0; + domid_t domid = DOMID_SELF; int rc; if (!xen_domain()) @@ -732,15 +733,21 @@ static int __init balloon_init(void) pr_info("Initialising balloon driver\n"); - if (xen_pv_domain()) { - if (xen_released_pages >= xen_start_info->nr_pages) - goto underflow; - current_pages = min(xen_start_info->nr_pages - - xen_released_pages, max_pfn); - } else { - if (xen_unpopulated_pages >= get_num_physpages()) - goto underflow; - current_pages = get_num_physpages() - xen_unpopulated_pages; + if (xen_initial_domain()) + current_pages = HYPERVISOR_memory_op(XENMEM_current_reservation, + &domid); + if (current_pages <= 0) { + if (xen_pv_domain()) { + if (xen_released_pages >= xen_start_info->nr_pages) + goto underflow; + current_pages = min(xen_start_info->nr_pages - + xen_released_pages, max_pfn); + } else { + if (xen_unpopulated_pages >= get_num_physpages()) + goto underflow; + current_pages = get_num_physpages() - + xen_unpopulated_pages; + } } balloon_stats.current_pages = current_pages; -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 28 11:08:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 11:08:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215438.1525621 (Exim 4.92) (envelope-from ) id 1vl3PS-00042c-O0; Wed, 28 Jan 2026 11:08:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215438.1525621; Wed, 28 Jan 2026 11:08: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 1vl3PS-00042V-L0; Wed, 28 Jan 2026 11:08:30 +0000 Received: by outflank-mailman (input) for mailman id 1215438; Wed, 28 Jan 2026 11:08: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 1vl3PR-00042P-GP for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 11:08:29 +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 ab49ce9b-fc39-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 12:08:28 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-47d59da3d81so5458065e9.0 for ; Wed, 28 Jan 2026 03:08:26 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806cd8fadfsm53093775e9.0.2026.01.28.03.08.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 03:08:25 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ab49ce9b-fc39-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769598506; x=1770203306; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=jAQ2dnI8nmsKW/dAWZNNe+uUDArlPeX7JBvIpoxYpTw=; b=fc49AZDJEWgJhp9rzFnHZm7uJJlDjzyNHMv0aPrynEpp0VgvQ6CcEMLfIQKdv8GgtC K2XEtE3rA1unVu3OH3Y4d/YvFYQuGIiVAc0L6Cr3X9Hu93LEGuGx+F49tEX723Xedita 87vbLa8qjb9yYOJijLeot7HtIfJLfY8Nh/QLmsdsFDznO04fHyuV/gW/qJMrkuo5HUka eP0Vgh+MkJrpjO6IKLDoMFulO4u1nulGwHuxlihhiHWJ9wlqIp7L3J7vSMg4qGx3tc+H yzYeZFVj8IwkrjD3feJSU41VHfXTWOZIRqXkCW6gG118pXKZqdbtSeOHTMdp/WSRiUTg a0CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769598506; x=1770203306; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=jAQ2dnI8nmsKW/dAWZNNe+uUDArlPeX7JBvIpoxYpTw=; b=Vp4werzdu1Dt/pxQ8GSM7C1z5sDvqnlFb/jKmZuGB3D7wHILqMSRdBwwvZPhFPS2LU CbSFdQBErcOA1KYx4jKvgG/a97SZ3GsSuMK4iB5sQIq7AsdCZcvYUaJEZi4Ub1kiZtxf VPwfFxIVVtva72hdlBBXTtvw5QsXmdkaZQZ3Bf6J7Iy0t46R1ax7f9bwh2lbXe6NeC4Z ZD2pvRO9EUAYwOql8WHwangytdRjXAbGOC8sViQ1SKrB6JMacWUYMB1RG4J2zwPnBEFN 2d53qvVIwLe3PV6Ol9uN1phLxH8Erf0y9UnFasdQPKr86QPTzjRlN2C/LU+uj6bBTrFe 4Ccg== X-Forwarded-Encrypted: i=1; AJvYcCWmujUUyahNVuHSLcmsPFZapt66NVjpwJWKFAYMFvmekqYup2Yyk8Ht/dB8+1K0sZ9VrQd2wKC0hGY=@lists.xenproject.org X-Gm-Message-State: AOJu0YxOKQxq0kS98MomhbAY+omQBle1qzpxrPUabBFfC6WcUFnk9pPX ZzXKtFjVmPMb8rQJP1yAjYYzgC/0ZS7Vz4fOOeTFq7a8FEhHAls3PeDq4NcELZ+dtQ== X-Gm-Gg: AZuq6aLI1lllEnF7NkTPupD/mNttgLsUsLY5mhzvZnIsZ1TYvJOSwmdYH8E8xvLAyWS YNlcHplITlo05avz4uy7u98DYdzh2IfcM1pFVlEUeJaCt2ClHhyUVudv2xseUBM0VccYrsU/fk6 UzCzUO4EKUGFmJmzdwGT1pMfOLX8AYiPXV1rYAw6R6fHIXcf70u2E4bbKK/m/6A8Riq7NRFtqpx MuUA9Iz1uQi9DpJZlSahHrZZ/HQXWSAshY/oQ4tnrnhSoQqEFbRfPk3Bt8hOzHO2iP0iEEAbx4l iEuS2Li2hbyIJ4UhF/GRZgPXP8kJ62IlCDJ/DdL3/YIj8oiTl75aEX7s7kvyQHO2WIvNNYW3zut I/B76emCfiKeQ6rNGMIvgODxq0VjoTyCOkft+g9tHEvxMIDMZ7IT2+DIryhldo69TueECElcIdc KoxPkWqBpojLV7L9JEAOUOicGOoplKOUtl1ro3eKyGFmuLx525v1xOilCbEJVOKhqpW9UFRwx/P M8= X-Received: by 2002:a05:600c:8011:b0:480:4a90:1afd with SMTP id 5b1f17b1804b1-48069d44770mr48762545e9.0.1769598506045; Wed, 28 Jan 2026 03:08:26 -0800 (PST) Message-ID: <132efa57-bd11-47b9-b3c8-0c09589f70b2@suse.com> Date: Wed, 28 Jan 2026 12:08:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] xen/riscv: dump GPRs and CSRs on unexpected traps To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <27ab0f8eb6fd6ecef1eeefa4a05e4fe1f43acbbe.1769427484.git.oleksii.kurochko@gmail.com> <88edf7a2-c5f1-41fd-9ceb-8cc0c345b7e6@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: <88edf7a2-c5f1-41fd-9ceb-8cc0c345b7e6@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 28.01.2026 12:01, Oleksii Kurochko wrote: > > On 1/28/26 11:34 AM, Oleksii Kurochko wrote: >> >> On 1/27/26 10:27 AM, Jan Beulich wrote: >>> On 27.01.2026 10:14, Jan Beulich wrote: >>>> On 26.01.2026 12:43, Oleksii Kurochko wrote: >>>>> Provide additional context when an unexpected exception occurs by >>>>> dumping >>>>> the relevant Supervisor, Virtual Supervisor (VS), and Hypervisor CSRs, >>>>> along with the general-purpose registers associated with the trap. >>>>> >>>>> Dumping VS-mode CSRs in addition to host CSRs is beneficial when >>>>> analysing >>>>> VS-mode traps. VSCAUSE, VSEPC, VSTVAL, and related VS state are >>>>> required to >>>>> properly diagnose unexpected guest traps and potential hypervisor >>>>> misconfiguration. >>>>> For example, on an illegal-instruction exception the hardware may >>>>> record >>>>> the faulting instruction in VSTVAL. If VSTVAL is zero, VSEPC should >>>>> always >>>>> be inspected, and can be used together with objdump to identify the >>>>> faulting instruction. Dumping VSCAUSE is also useful when the guest >>>>> does >>>>> not report it, or when the hypervisor redirects a trap to the guest >>>>> using >>>>> VSCAUSE, VSTATUS, and VSTVEC, allowing verification that a >>>>> subsequent trap >>>>> is not caused by incorrect VS state. >>>>> >>>>> Signed-off-by: Oleksii Kurochko >>>> Acked-by: Jan Beulich >>> Hmm, wait, there's another anomaly: >>> >>>> I still have a question though, which can be addressed incrementally. >>>> >>>>> --- a/xen/arch/riscv/traps.c >>>>> +++ b/xen/arch/riscv/traps.c >>>>> @@ -99,12 +99,70 @@ static const char *decode_cause(unsigned long >>>>> cause) >>>>>       return decode_trap_cause(cause); >>>>>   } >>>>>   +static void dump_general_regs(const struct cpu_user_regs *regs) >>>>> +{ >>>>> +#define X(regs, name, delim) \ >>>>> +    printk("%-4s: %016lx" delim, #name, (regs)->name) >>>>> + >>>>> +    X(regs, ra, " "); X(regs, sp, "\n"); >>>>> +    X(regs, gp, " "); X(regs, tp, "\n"); >>>>> +    X(regs, t0, " "); X(regs, t1, "\n"); >>>>> +    X(regs, t2, " "); X(regs, s0, "\n"); >>>>> +    X(regs, s1, " "); X(regs, a0, "\n"); >>>>> +    X(regs, a1, " "); X(regs, a2, "\n"); >>>>> +    X(regs, a3, " "); X(regs, a4, "\n"); >>>>> +    X(regs, a5, " "); X(regs, a6, "\n"); >>>>> +    X(regs, a7, " "); X(regs, s2, "\n"); >>>>> +    X(regs, s3, " "); X(regs, s4, "\n"); >>>>> +    X(regs, s5, " "); X(regs, s6, "\n"); >>>>> +    X(regs, s7, " "); X(regs, s8, "\n"); >>>>> +    X(regs, s9, " "); X(regs, s10, "\n"); >>>>> +    X(regs, s11, " "); X(regs, t3, "\n"); >>>>> +    X(regs, t4, " "); X(regs, t5, "\n"); >>>>> +    X(regs, t6, " "); X(regs, sepc, "\n"); >>>> Does this sepc value differ from ... >>>> >>>>> +static void dump_csrs(unsigned long cause) >>> What is this function parameter for? >>> >>>>> +{ >>>>> +#define X(name, csr, fmt, ...) \ >>>>> +    v = csr_read(csr); \ >>>>> +    printk("%-10s: %016lx" fmt, #name, v, ##__VA_ARGS__) >>>>> + >>>>> +    unsigned long v; >>>>> + >>>>> +    X(htval, CSR_HTVAL, " ");  X(htinst, CSR_HTINST, "\n"); >>>>> +    X(hedeleg, CSR_HEDELEG, " "); X(hideleg, CSR_HIDELEG, "\n"); >>>>> +    X(hstatus, CSR_HSTATUS, " [%s%s%s%s%s%s ]\n", >>>>> +      (v & HSTATUS_VTSR) ? " VTSR" : "", >>>>> +      (v & HSTATUS_VTVM) ? " VTVM" : "", >>>>> +      (v & HSTATUS_HU)   ? " HU"   : "", >>>>> +      (v & HSTATUS_SPVP) ? " SPVP" : "", >>>>> +      (v & HSTATUS_SPV)  ? " SPV"  : "", >>>>> +      (v & HSTATUS_GVA)  ? " GVA"  : ""); >>>>> +    X(hgatp, CSR_HGATP, "\n"); >>>>> +    X(hstateen0, CSR_HSTATEEN0, "\n"); >>>>> +    X(stvec, CSR_STVEC, " "); X(vstvec, CSR_VSTVEC, "\n"); >>>>> +    X(sepc, CSR_SEPC, " "); X(vsepc, CSR_VSEPC, "\n"); >>>> ... the one logged here? Nothing changes the register between entry >>>> into the hypervisor and coming here? >>> Down below here you have >>> >>>      X(scause, CSR_SCAUSE, " [%s]\n", decode_cause(v)); >>> >>> which actually (largely) duplicates what do_unexpected_trap() has >>> already >>> logged. >> >> Missed that, then it would be better to remove this duplication and leave >> only printing of CSR_SCAUSE in dump_csrs(). >> >>>   If dump_csrs() gained other uses, the dumping of scause likely is >>> wanted, but then likely no scause value would be available to pass >>> in? So >>> maybe its dumping actually wants to be conditional (and the parameter >>> wants to be a boolean)? >> >> Good point. Honestly speaking, I don't know if it will be any other >> usages >> except this one. But to keep things generic I think it is good idea to >> add conditional dumping of scause. > > As an alternative, we could simply remove the dump_csrs() argument and always > print SCAUSE. When running in hypervisor mode, SCAUSE should contain the reason > for the trap. Even it is lets say just hypercall and not something faulty, it > will contain "Environment call from S-mode" what looks okay to be printed. > > I tend to prefer this approach slightly. What do you think? It means that it'll be logged twice for an unexpected trap. As said, I can only recommend to limit the volume of the output in such situations, as sometimes all people may be able to get you is screenshots. Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 28 11:13:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 11:13:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215455.1525631 (Exim 4.92) (envelope-from ) id 1vl3UB-0005dB-CZ; Wed, 28 Jan 2026 11:13:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215455.1525631; Wed, 28 Jan 2026 11:13:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl3UB-0005d4-9Y; Wed, 28 Jan 2026 11:13:23 +0000 Received: by outflank-mailman (input) for mailman id 1215455; Wed, 28 Jan 2026 11:13:21 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl3U9-0005cy-Mf for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 11:13:21 +0000 Received: from CH1PR05CU001.outbound.protection.outlook.com (mail-northcentralusazlp170100001.outbound.protection.outlook.com [2a01:111:f403:c105::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 565b3d35-fc3a-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 12:13:16 +0100 (CET) Received: from PH7P220CA0153.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:33b::15) by CY1PR12MB9557.namprd12.prod.outlook.com (2603:10b6:930:fe::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Wed, 28 Jan 2026 11:13:08 +0000 Received: from SN1PEPF00036F42.namprd05.prod.outlook.com (2603:10b6:510:33b:cafe::3f) by PH7P220CA0153.outlook.office365.com (2603:10b6:510:33b::15) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.8 via Frontend Transport; Wed, 28 Jan 2026 11:13:09 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SN1PEPF00036F42.mail.protection.outlook.com (10.167.248.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Wed, 28 Jan 2026 11:13:08 +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, 28 Jan 2026 05:13:05 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 565b3d35-fc3a-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=W61zSwf8DSbazCfu9NMjY52bF5oB/zNx9VN5GbhjH0z5ULTHgm/qqNyQbMr/xAGd/6mzewyoZNrFunpoxMG1BDyLvTZrHZdjUijevA9El8ZrLPcZ/bTGI1tnnZ6cGFTyUfCR5fwrNpmKWcjx2C4roM4C4HKOptVjnGwyVKRGR2rETMrH/k4CjTyX7kLbVZHWlje4sOaVoT+wyw8SMRZmPpK97lZFtGAKYL7Sje6VoODNp+ExL1HDrO6FGjOdsua6rSog1vrJroqqcMEAP5gmvJGQuhdGDXmxngLKCk/uprhFxhLI/sqodXkd9sHl1if2pSLqfpgtHmqQH2Ebm7vMCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eEcL3V16C6/Sgcab/8hRP1Une+UWDuwQ72flmdToY/c=; b=UeN6eO/RXD8PaToGX+bfCabR39VdRXJ6TIWmv6cnP+tTnJ4j3sC68+ZqYUnSkP6qxV2lSVZ1aB47q1WIRevoh+EC0oIHfta+gs5Cqx7lNV6/MLVtqJbqwZK8eEfKSbML77uBHZiHZmi0ixZAtHVurL9VSkI5IbfGa3h9T8xnT5Wftr2/pS4dUg9HG4An4zfeqxFaBYNZgOfmnwVG68HmXzJDTuGLrp7oGqaXkW1Hz001H2UWuq7L8ZnsufeS02CA/AbPVIZVUbienHJQce1sEcmMrguD7GrZPKwofmoiRQ7iqAT4OseOMe8ZEq+qktZtxYFRJg5G15dk3iLi4LSOQA== 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=eEcL3V16C6/Sgcab/8hRP1Une+UWDuwQ72flmdToY/c=; b=PnlLpwyWlrazHtnuecs6r8iLwjSZ3oUP8jZJOdSuq7tFDKvKmQ/Hvj7xUDqzlUnYpq9UYcyeyIp37fbHhcc7iA5S/4C1TasNN72sQgue8AsAGyJ1sE1ZdFvOzwbrcLMIoMffnpens2+UGvUbQnRIb0NJ4MDGG7V6+0UdPBIRg+c= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 28 Jan 2026 12:13:03 +0100 Message-ID: CC: , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , Stefano Stabellini Subject: Re: [RFC PATCH] CODING_STYLE: Establish a policy with regards to copyright notices From: Alejandro Vallejo To: =?utf-8?q?Roger_Pau_Monn=C3=A9?= X-Mailer: aerc 0.20.1 References: <20260127182403.141459-1-alejandro.garciavallejo@amd.com> In-Reply-To: X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PEPF00036F42:EE_|CY1PR12MB9557:EE_ X-MS-Office365-Filtering-Correlation-Id: d3cbad06-a8ba-4b49-f689-08de5e5e37b1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026|13003099007|7142099003; X-Microsoft-Antispam-Message-Info: =?utf-8?B?aG5wL2hucy95Z2IxNzR3ZGY3OFFaYUJjWVM2R0Yxcnh6Z3NJak43dW9qY1Ex?= =?utf-8?B?eWs0ZE1OenN4NGRQUXppd2lVU3FWOEtZblpuNXprRXdpWmxldXkxUEpHcWVm?= =?utf-8?B?VGFlR00rb0d3eWY2VlpuN1g0VzZqS1Vhb0ZhSHY1c1FzeU8vVFQ3R3RDYitW?= =?utf-8?B?NDNwTzFxVlJWbDJXQ3lTUm9SL2pzUHRjMk1DSGg2RkFaTkpLQlFTNGYrNVRX?= =?utf-8?B?M3RTK2NaYUhEcXJUejB3TkViVk45N3BLcy8xM3RzWGhQbXpkQ040UFFCZUxS?= =?utf-8?B?S05BaVljY0wyemkwcDB6N0FjMFpWcGVEMUFGREtSK3Z2Zk43VHZLVWpZWms2?= =?utf-8?B?VGZuYVluS1U4RXFWdlhBOWtNTHpyYjNXWDl0MnZNNkU2eS9rV3Y0TkFLNHF5?= =?utf-8?B?dFpMK0xiOWhpeTVObGZFeURQUXVSQnllMnRBZHlGT0sxb3dGUkNIbDJqT3Z5?= =?utf-8?B?emlMMXVUZFpMeVlBZXZUNFd5OGZ3UTgrK1lobTVla2JLbFliZUF4dTBWblRp?= =?utf-8?B?YnV3RWtiSTVxRmpsUUVYMnJ1ai9tQkdnUDBrN0pqSzNpUlJ2Nkd6aktuQ3Jy?= =?utf-8?B?ZlJsMHpURnZlbnR5ZnBaQTJKV0FFV0Q3ZDdwYzZBanFhMWFXcThTanVYeUls?= =?utf-8?B?TGdvdHlEK0IxZ1ZIcFhJcll6dDdTMGs4TEh3eUVqeUluelNLbXdQbDlMbVdZ?= =?utf-8?B?WDUzcThTV0kraFNFaUtYSTdiUmdSS0FiMkpreVJPSmZuSWhyQjFsVVJDZWJX?= =?utf-8?B?U0xOQVhITEI0L2g0YzRsY2hKVENsTnlnK1gzbzlHenFPSUtqMFhWODNHTE54?= =?utf-8?B?bUw3UVJ5bzhsbWtVeHlTcC9RNW1yaXdzU0R0RVVkaUlHbENvS002RThVSkpG?= =?utf-8?B?UDkxbHFVWDA3SWxZaVV3ZTBiZHVPYzBLd1NMbWhYOU8vN3FDdjVXWTVDdHpK?= =?utf-8?B?R2lmc3N3Q0VPODRQNWQ4M0hINjVWSjEyVWVmZjhSL1l3Y3dseFNWbUNhMWJ6?= =?utf-8?B?Y1VPcGNGV2dsL1NrZnQvbG50QUk1bEd0UjF5WW02NURvRTdSTGdJUk1kRnd2?= =?utf-8?B?eUM4K0FTM1lLdzRRN3l2bzlKeXYzdDkxZVdvN205cUZwWG9oeWNCYXdVanZn?= =?utf-8?B?OXd3ejhsQWJDbm51Qk1PQ0dzUHU1RmIyT0hUT1RkWkhKV1oxbGp0Y0U1OVVr?= =?utf-8?B?emQ4NDNQZVhVOXNWV3dKT2pjQzR0MGM4VG5lVkxRR2FRaStGTVY0VmlNSWdn?= =?utf-8?B?UnpnMjFsdlZKTWxUVGZ1c3N0aGpMUUh0ZmF4WG9sUEQwOWlBU1FjOTJ3aWFn?= =?utf-8?B?QS9YTm9JOUxxS1ptb0cvdjVDYUdwY0RhTUtpMWlXb1g5cDl3TXhEbE4rM1VL?= =?utf-8?B?YzJZdWRHaUR2OFdTNU1ld1hjT0dyWVJKRjNITVRRU0lER1YrNlJhUG9Ibldy?= =?utf-8?B?bit3TDB5M2U3ZzdoNEk1Z1UrcGp6S0VLZWo4NHZpS0VPNmI5UGpINEpiNmxs?= =?utf-8?B?L2FhZEdRd01TakhFWENZRTNVclFtN2hiREhnWUNxdW93UFA3cDR1QWNkaUxQ?= =?utf-8?B?blFZaUxQeFhuai96Z25GaEFRMXl0dC9CWG1HZVovNzl1TE9rVzZVWlR3L3Y1?= =?utf-8?B?RmRycDF3dW5aeEVpTVZ0WDl3ekhZNnZGUlI2NXlsYS80ZDN2NW83ellkTm9j?= =?utf-8?B?bkdGWEt1NDd5VENiVlBJS1RKN21zZXVwbkM3VlFxTWxMVnpWQWdFNUxKckVS?= =?utf-8?B?QkdjL05jSzluM2dTTVRnWU9MM0ZNTkJ5ZG1RRk5vd0lXMUhxMFFhRG9hbFo5?= =?utf-8?B?THo3bGhkR2xCVFgvcWFjT1BEdWtZTDVPZVJmb3dMZ0ljVXJoUGo3RGF4Z1V4?= =?utf-8?B?QWtQZk8za0ZoTGtoemNEUUJLUVBNRHMvSkI5clNyS1NTN0hUbEI1SXBFOEl1?= =?utf-8?B?OEVuWGl4bDNxbkFNR0VRczEvQUZob0F3MlVMVFc0R2hHZTE2RTBBa1Q2c0Fs?= =?utf-8?B?TndQZ2J3ZmtUc2pLUkhhZjB6Q1lFYk91TWpRK2M4eWU2QTBleHZuMTh0cnpj?= =?utf-8?B?VGxBY1g2L05iUkNwNWNKa2taODFUWnM5ZWJQdFRkcEx2MEJRdGJYcDgrSDR4?= =?utf-8?B?QWEycmRKNGQ2a3RaSTdZR2dSTmZQZVRXQ0VEdU9qZStXN0VCQnpFQkdHZ3Ew?= =?utf-8?Q?XqPdk1HFKsnlsSlaVohGjW0=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026)(13003099007)(7142099003);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 11:13:08.7209 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d3cbad06-a8ba-4b49-f689-08de5e5e37b1 X-MS-Exchange-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: SN1PEPF00036F42.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR12MB9557 On Wed Jan 28, 2026 at 11:31 AM CET, Roger Pau Monn=C3=A9 wrote: > On Wed, Jan 28, 2026 at 11:16:39AM +0100, Alejandro Vallejo wrote: >> On Wed Jan 28, 2026 at 10:41 AM CET, Roger Pau Monn=C3=A9 wrote: >> > On Wed, Jan 28, 2026 at 10:18:03AM +0100, Alejandro Vallejo wrote: >> >> Hi, >> >>=20 >> >> On Wed Jan 28, 2026 at 9:10 AM CET, Roger Pau Monn=C3=A9 wrote: >> >> > On Tue, Jan 27, 2026 at 07:24:01PM +0100, Alejandro Vallejo wrote: >> >> >> This patch modifies CODING_STYLE to severely discourage use of cop= yright >> >> >> notices when their presence is not legally mandatory. >> >> >>=20 >> >> >> Copyright notices are redundant on commit, misleading from the tim= e the file >> >> >> receives contributions from anyone not represented by such notice,= and actively >> >> >> harmful for attribution by the time the original code is long gone= . They are >> >> >> plain wrong when added on code motion.... the list goes on. >> >> >>=20 >> >> >> All attribution worth keeping is version-controlled through Signed= -off-by, >> >> >> Co-authored and the like, DCO and the cumulative contents of git h= istory. >> >> >> License banners have already been superseded by the contents of li= censes/ and >> >> >> SPDX tags. >> >> >>=20 >> >> >> Other FOSS projects have already moved away from explicit copyrigh= t notices >> >> >> where possible, and severely discourage their use when not. >> >> >>=20 >> >> >> Apache and LLVM take active issue with copyrighted contributions a= nd Chromium >> >> >> takes issues with copyrighted contributions not attributed to the = project. Some >> >> >> Linux subsystem maintainers already frown upon copyright notices t= oo, even if >> >> >> it hasn't reached the point of being a mandated requirement yet. >> >> >>=20 >> >> >> Signed-off-by: Alejandro Vallejo >> >> >> --- >> >> >> The actual changes are almost verbatim from the LLVM guideline, bu= t it's not >> >> >> exact. Wording can be adjusted as needed. I care about the core of= the proposal. >> >> >> Saying "please, drop the notice" on contributions where it's clear= ly not a >> >> >> legal requirement, or have the contributor state that it is a lega= l requirement >> >> >> and why. For fairness sake for all contributors to the project. >> >> >>=20 >> >> >> I'd prefer taking the Apache approach for new contributions, but I= want >> >> >> some discussions to happen first. >> >> >>=20 >> >> >> Thoughts? >> >> >>=20 >> >> >> Relevant examples: >> >> >>=20 >> >> >> - LLVM: They banned copyright notices, unless part of a vendored >> >> >> components. >> >> >> - Links: >> >> >> - https://llvm.org/docs/DeveloperPolicy.html#embedded-copyri= ght-or-contributed-by-statements >> >> >> - Relevant quote: >> >> >> The LLVM project does not accept contributions that includ= e >> >> >> in-source copyright notices except where such notices are >> >> >> part of a larger external project being added as a vendore= d >> >> >> dependency. >> >> >>=20 >> >> >> - Apache: They banned optional copyright notices and relegated >> >> >> mandatory notices to a NOTICES file that also contains= an >> >> >> Apache copyright notice. See links. >> >> >> - Links: >> >> >> - https://www.apache.org/legal/src-headers.html >> >> >> - https://infra.apache.org/licensing-howto.html#mod-notice >> >> >> - Relevant quote: >> >> >> If the source file is submitted with a copyright notice in= cluded >> >> >> in it, the copyright owner (or owner's agent) must either: >> >> >> * remove such notices, or >> >> >> * move them to the NOTICE file associated with each appl= icable >> >> >> project release, or >> >> >> * provide written permission for the ASF to make such re= moval >> >> >> or relocation of the notices. >> >> >>=20 >> >> >> - btrfs: They are highly discouraged. >> >> >> - Links: >> >> >> - https://lore.kernel.org/20220909101521.GS32411@twin.jikos.= cz/ >> >> >> - https://lwn.net/ml/linux-fsdevel/20221026074145.2be5ca09@g= andalf.local.home/ >> >> >> - https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/i= ndex.php/Developer's_FAQ.html#Copyright_notices_in_files.2C_SPDX >> >> >> - https://lwn.net/Articles/912355/ >> >> >> - Relevant quote: >> >> >> Let's say it's OK for substantial amount of code. What if so= mebody >> >> >> moves existing code that he did not write to a new file and = adds >> >> >> a copyright notice? We got stuck there, both sides have diff= erent >> >> >> answer. I see it at minimum as unfair to the original code a= uthors >> >> >> if not completely wrong because it could appear as "stealing= " >> >> >> ownership. >> >> >>=20 >> >> >> There's more cases of other projects taking similar stances. >> >> >> --- >> >> >> CODING_STYLE | 18 ++++++++++++++++++ >> >> >> 1 file changed, 18 insertions(+) >> >> >>=20 >> >> >> diff --git a/CODING_STYLE b/CODING_STYLE >> >> >> index aae5a47ac2..97f80245ed 100644 >> >> >> --- a/CODING_STYLE >> >> >> +++ b/CODING_STYLE >> >> >> @@ -24,6 +24,24 @@ license, e.g.: >> >> >> =20 >> >> >> See LICENSES/ for a list of licenses and SPDX tags currently used= . >> >> >> =20 >> >> >> +Copyright notices >> >> >> +----------------- >> >> >> + >> >> >> +Copyright for the code in the Xen Project is held by the respecti= ve >> >> >> +contributors. Because you (or your company) retain ownership of t= he code you >> >> >> +contribute, you know it may only be used under the terms of the o= pen source >> >> >> +license you contributed it under: the license for your contributi= ons cannot be >> >> >> +changed in the future without your approval. >> >> > >> >> > The usage of such direct language here, by using you to refer to th= e >> >> > reader / contributor, set a different tone from the rest of the >> >> > document. Maybe something like: >> >> > >> >> > "Copyright for the code in the Xen Project is held by the respectiv= e >> >> > contributors. The author of the code is the owner of it as stated = in >> >> > the DCO. The project cannot retroactively change the copyright of >> >> > contributions, unless explicitly accepted by all authors of the >> >> > code." >> >>=20 >> >> Ack for the tone. The particulars of the wording might need tweaking = even in >> >> this version to constraint the scope of "contribution", "the code", a= nd so on. >> > >> > Yeah, it probably needs even more integration to make sure the terms >> > used match the rest of the document. I didn't take much care into >> > that, as I was writing this in the email reply and didn't have much >> > context. >> > >> >> ----------------- >> >>=20 >> >> I have the same question for you I asked Jan elsewhere. >> >>=20 >> >> There's 1 question in 2 forms I'd like to have an answer to from a co= re >> >> maintainers. >> >>=20 >> >> Would you be willing to ack a change along these lines? >> >> 1. to a Copyright Notice policy within CODING_STYLE. >> > >> > I'm fine with that. >> > >> >> 2. to the relegation of existing notices to a NOTICES file in the s= tyle of >> >> Apache. Apache in particular mandates the file not be touched un= less >> >> absolutely required for legal reasons. >> > >> > Hm, that might be more complicated. I am however not a lawyer, don't >> > expect the rants below to have any kind of legal base. >>=20 >> Neither am I, for the public record. >>=20 >> > >> > What about the public headers in xen/include/public? I don't think we >> > can just remove the copyright notices from those files and place them >> > in a top level NOTICES file. Then OSes would copy the headers >> > without the NOTICES file and end up effectively dropping the original >> > copyright notices. >> > >> > Also, what about people importing files from Xen into different >> > projects (apart from the public headers)? If we remove the copyright >> > notices the imported files won't have them either, and people is not >> > simply going to pickup the top level Xen NOTICES and import it into >> > their project? >> > >> > How does Apache deal with people importing their code into separate >> > projects, do they mandate the NOTICES file to also be included as part >> > of any code import? >>=20 >> They do. It's part of the Apache license. See point 4.d: >>=20 >> https://www.apache.org/licenses/LICENSE-2.0 >>=20 >> This would require some sort of ammendment to xen/COPYING. >>=20 >> OTOH, to avoid being a PITA to Linux and others by changing how we do th= ings >> it'd be sensible to keep the existing headers on everything under xen/in= clude/ >> public/ for being-a-good-citizen reasons. >>=20 >> Anyone actively copying an internal file (say, msi.c) would thus be forc= ed to >> also copy NOTICES, but that's a heck of a lot rarer and not much to ask. > > Possibly a very dummy question, but won't our NOTICES file be fairly > big and complex? If we have to move every single variation of the > different copyright headers we currently have in the tree. We have > GPL-2 only, >=3D GPL-2, MIT, LGPL, BSD... Each with a possibly different > set of copyright owners. Any licenses still around as banners we neither need nor want to keep. That= 's what SPDX tags are for, and why we have them collected under licenses/. Irrespective of the copyright amalgamation, licensing is still per file, wi= th each file having an SPDX line. But yes, every copyright owner would need a "row". Unless we can contact th= em and ask for permission for removal. > > Also, would we need to somehow reference which notices go with which > files in the tree? Otherwise we would effectively loose tracking of > the specific copyright owners of each file I fear. Figuring those out > would need to be done by going back to the last commit before the > copyright notices were removed. I don't think so. Apache definitely doesn't do that. They might reference w= hich file was imported, but that's the extent of it. At most, I'd consider file+hash-at-its-commit so it doesn't need updating a= nd it reflects accurately the contribution at hand. Conversely, when code moves around and files evaporate so do copyright noti= ces even though the copyrighted contribution is still around. It's not the file that's copyrighted, but it's contents. In any case, the first thing to do is to prevent MORE coming in. This can b= e a discussion for later when the set of existing notices is more or less fix= ed, possibly alongside another RFC with how a NOTICE file might look like. It m= ay very well be too unwieldy, as you suggest, and this discussion be moot. I'll wait a bit for more answers before sending a non-RFC more carefully wr= itten version of this. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Wed Jan 28 11:14:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 11:14:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215465.1525641 (Exim 4.92) (envelope-from ) id 1vl3VQ-00069c-MA; Wed, 28 Jan 2026 11:14:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215465.1525641; Wed, 28 Jan 2026 11:14:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl3VQ-00069V-JJ; Wed, 28 Jan 2026 11:14:40 +0000 Received: by outflank-mailman (input) for mailman id 1215465; Wed, 28 Jan 2026 11:14: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 1vl3VP-00069J-DA for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 11:14:39 +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 879c3a1e-fc3a-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 12:14:37 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by LV4PR03MB8188.namprd03.prod.outlook.com (2603:10b6:408:2d8::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Wed, 28 Jan 2026 11:14:34 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.006; Wed, 28 Jan 2026 11:14: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: 879c3a1e-fc3a-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Bx24+zPFj3InlBkd2mcCHAULJmGEcrJwygNKM6XwvHA3UiBJCPr1W13aGZx1L7qpEadOexYu5t9wd4lPKYE+vYr+fUg0mAFpuMz8u37RbVO6We1JCWTWMB7eZTdLWKKnxOEreTjvgRrJoR7WkwHknxFxtjRkjm34DKbwO+rwxghOhuzLTSY3498A5CaIMKrw0Ox644Pu9udwGo4C0mjlsQRE20Xb5JCy2f/rNy3E1GFuLk1KufP5tWwN0iuYv01QGjIiJVxs6AN+cXLC3Fvuozu6Uxbf8ebzsYroJlMPtj92UIDefopqilo8+wY1tD8pqsl+FITl2lxJaQDCc/S2rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eUQ6H63oXfjU5OU+v6AEd+oY85vTZo7mT+SDAiGQkuE=; b=PRTAKmP9gsbmbhXOgtkp8VfHZalMuvP0icqmXJPTcw6ulaem4dzwtrmtPQCVSgvMfJGGB7BcLtSuUkTemWKsn18Ofz9jGKDMv4pIGaLq18WZIb+mSeafvwwxBGUICNeCIV/quBZNVpMKwCQeb0g72DZxHd8+p+OzyOclfBzId/DpxJ6dNUNCH2S8V+f2yr111PZuS/hlvYUj9kJeaYgDLVyBO/f9pbCTLiUqDZujracmV7ROjONvEx9+z1aYVq2PMggJkVtdPU+g3m3iZWxsVhtmH765/93WvxxHcWBJ9UkiYfB36+sKqdCATEVg7Ep1eFyDT35FLcp/HnwD9qIPkw== 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=eUQ6H63oXfjU5OU+v6AEd+oY85vTZo7mT+SDAiGQkuE=; b=IM2x1ji3rZp+mEHBsZobZPEPugMw3YAmbuMb3oYgu3hB6SsvMEdcgCkelqZCU2BHkM63iaMRowlNmFf3aacedtYXdbXRejIAe+qfgPTXRxuH45GivBGkcdxmB6pgbJca6VwoQJwjVjW57Cm7IyZM1cpqvxSe719uQ4fSuE7C8a0= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 28 Jan 2026 12:14:31 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Anthony PERARD , Juergen Gross , Stefano Stabellini Subject: Re: (auto-)ballooning issue Message-ID: References: Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: MA3P292CA0006.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:2c::14) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|LV4PR03MB8188:EE_ X-MS-Office365-Filtering-Correlation-Id: 5de19304-362c-4e55-abc7-08de5e5e6a58 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?VkRMOG50Y1U5L2hncnliYlpKR0dJNXpnT0sycEZ1NmhXdExhM2QwdmZjRHJk?= =?utf-8?B?VG4rWGszMWh5dHZWd0lqZENZNzAvN0ZjQVJ3VmtVSDVESUFGMVFXWC9sYU90?= =?utf-8?B?L0NqOVEzVnZiN2ZCVlN0MnVucnFpbnlCK3ZuSGxIQ1Y4SXo4QlVmeGpTbnNZ?= =?utf-8?B?Rmc0QmF0K2o3cllldTg4K3hjTmxmcEdRY2J2OHJpT0R3Nmt4WnBHMEUwZCs0?= =?utf-8?B?dDE5bWZFNHJzSmF1NDFEa1UvR1hMVVhWN0FjTXorTEZ6UktCd0trRk9ydmNC?= =?utf-8?B?bDN0Mm1La1gyNDdWT09xUlBiUkJ5MjNXc3prYkxNdi9PRXcvYnpveXZIR0Rp?= =?utf-8?B?UXRUY0xneHpjSE0xL0pHL0FLRG1oNFhLQmE1UXRHSjZEd2U0Q0FndmJDdWU1?= =?utf-8?B?VC83L09jV0ptSHJzMldOWHFNSmNtKzRnQm1mUW5wdGFsWTRQdDhUWWpDUjM5?= =?utf-8?B?VkxoNi9idmNSdHdzRHd5RnQwZ3N6alEra1NxNDNtWUowNFlqRUluQ1lBSnlD?= =?utf-8?B?VE5Tdy8vc01yTFUxUjlWM3JIeHNoY3IyMFRlaHVLTDc4eGhpZzR1YkltNGk5?= =?utf-8?B?bU05enVHNTZRR3A3Q2lVUTBaajdLVjlvYWVQaHZzRDZXaFlnUXAvMzkyMXhh?= =?utf-8?B?YVI1d0tuU1gxRWpycHhtNGpTTk11dDM4T0ZKMjNlb3NpOWRFSnBSL1Rlazhp?= =?utf-8?B?SElWNnE3VVZoYUpwM3NvenRKeVRmSmh0TkQ3ODQ3eDBRUHRNb0RpK3RTM1Yx?= =?utf-8?B?aWtEc0k2VmVWK0d3U1RhRHFrZ2NzN0l3Y0xCYzUrc1pNcTNpdkhrMHoxMFlC?= =?utf-8?B?V2VvOFNQSG14QmJ3MGZyN2tEUWtEbFN5aDA3czFyZFkrMXlpeWZxREVKY05y?= =?utf-8?B?aWxoWEZsY2J5aHcvbFZpand6bXVEYlhIYlAyL2pjbnRYSlpxb0tCKytDenhG?= =?utf-8?B?eXpDR0gzSTR5VnNtaXM0KytvWG9mbVhscHkveElMeWZwTERrYW44T1gvaVc5?= =?utf-8?B?bU5zTjRJYnhnZXlrOUUzNU90UFZNTGd3L1FJTDV3VFg0YzBnS2NpVWJ4S3pP?= =?utf-8?B?K2xQQ01VL3J0bXROYzJNYURsNW5leUN5Ylg5U2VxclNqU1Z4Y3d0US95UzRk?= =?utf-8?B?SVZld3pudDFseTJVWnBzbVUwMkxxanhFcG05MUZHRGNOckFNVjdOTkV5bVNF?= =?utf-8?B?NHBEV01aVk1KU3FpcnFpYXFON2JVaStRNlhrSmMvNldtVk9yNWVpajlqYjAr?= =?utf-8?B?QXAwUUw4ME5HODVuckh2SG9sdHhTTlRlZ3JqUkNLaGhUWnR0a3gzTDdzQmJj?= =?utf-8?B?THcrSHNBK2tSNGNZek1kOU04TUFucXRTWDBycWl3VkhrNmdwbHgxd1MvVXEw?= =?utf-8?B?eE9TVWVDOUh1bVdwT2hLYlJhUk12K2VRTkJRcm1sYXlFTG9MQWNRVWcxQjlH?= =?utf-8?B?U2IyczQrYkdpODVlR1g5ZmYrMmQ2ZGZiTkp0dzlWYUlmeDhXK0w2aWhDV292?= =?utf-8?B?QWZpREZMSmNiTEZZMXRUWEliMEwwWU5hRk8yV29HblFoY01jbm02ZE9LUGVI?= =?utf-8?B?QjVhdVJJVnhVZ2RWcGpURzV0ZzMvb2N3bnFtQmYzOU84MGZDeUUweFVaZHYx?= =?utf-8?B?YU9jdDUvbnE1emtlc0JMc050T0pnSnQwRzFEY05oUGMvQnRmb0lCT0JtQnh5?= =?utf-8?B?ZWFxT3FZZ0UvdXZOb2txb1NDZFRsdlMraitZNmRjK1lZRld5TXAwWmI0UG81?= =?utf-8?B?TzVuZ1pETVk4OHpocXhYQnpuMU1qWXErbksveWRmL1pPcXR0OGFoQU9TQUpV?= =?utf-8?B?NHFBaitMOFROVkVhRncxSnMxcG5jbWpGNlhBWDhkY09XbVNmWmhrRWV0RXpD?= =?utf-8?B?bHRGdUxXdlhHQXlSaGozRmdLK3ZXOGpyN3ptOVJoTmwyMEFGNTlTczN0MGM3?= =?utf-8?B?Yk44VlJPQ09yL1kwUE9FYWN1bi9BVUI5K3hrVjhRYnVTbkJYUk1COXhnck9G?= =?utf-8?B?d3VCdnVsV2RVWUtWS2dQVGdjZTQ2ZVBPZUVtOXc0NFJGVkFESWQxeVprQ2xY?= =?utf-8?B?RDhYV3JRYk0yOWlFbnpld2xVNGN2a0dHMlNaVEt4Wm9xaWNyNmVvMEcyZ3Fo?= =?utf-8?Q?8rrk=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NExiSUlUUXJTT0l5UFhWa1g5OEVhMFhiNDJycnVzVmJuZjRmbVhETEZBQXVz?= =?utf-8?B?d0MydTcxYUhSdHR0UVk3UE8zR0FkTTVhQjNweHUvOXlXczFMYmRCMDBkTFVD?= =?utf-8?B?a1VuVHhHL1NRWWdpWjZQa3BmVllSTW5zY05pVHNkdGJLdGVFNmNGK2dHTlZD?= =?utf-8?B?eWxKUmVEMHd0R1lsekVXQlUrcFc0NmtDWEt5UjRmUEl3cTViS2U5TFd1SUZS?= =?utf-8?B?K3ZQT3ZvTGVYTU1GMkR4MURiUFo2Ymkxd0JSaDZVTWJZeEd2WGw5YmQ1RGI0?= =?utf-8?B?VzlsejNscFhsUlg1NGE2TDJTd2lQR3B4RGt3ZmZoeHcreGtWbEJFMEJweFpM?= =?utf-8?B?US9jSStZYU5UbUFFZkgrQjgvYXN6T2FySFc0Ny9ubXpGemFPd3VDankzclhS?= =?utf-8?B?bE1HbFBNcTk1OExGbG12ZEgwUU1Bc2pqTUFqeDFBN2tRckxGdXY5NU55OGdk?= =?utf-8?B?V0FpRml3VWJBSWd4cFZ4aFltMFZ0OEFSZktZVkZac2UwVURNSkNHV1JMTHhM?= =?utf-8?B?T0wxNGtXVHdZUzh1TkhkTFNhamZCQWNyTmp4cENFTEF6UTh0K0ZoSzcvNnB1?= =?utf-8?B?bGN4QUJWMFUyVVJHZHR1N1RxdnRsQ2NMTHF0MUhxbk5JT0x1ZFNhNGNRVS9W?= =?utf-8?B?anFOSkwzVEdtTldVcXVURkgxUVhTWWNHaEhRYk4rZ09mT1RQdCtpd3F6eHZ4?= =?utf-8?B?bjZmaDRzQU1ZYVYvSmd5MDhBandRcWZVcW1WUzBvZzgzQVNyM0d4RkVMKzZZ?= =?utf-8?B?MFA5SFdQbENoYk40bU9CTXYzZnhBWGR4Tk94TVZEL2NwSGdyTWtPVjFlVEZh?= =?utf-8?B?S0czdDMxTGM4WSt3VXBQOEJYODdzTmZyTGxDZFdVQWNvWURmanVWU0x0anVy?= =?utf-8?B?STBOZHhRZTJqWmRzQ1hBbmtqVUplR3FVckRmWG9VRVlDUUFVajlzbWNKTDZD?= =?utf-8?B?QUxJcTZHZUZMdnIrYVRNSkxSdjk1LzdNUDd2a0hsUzJyY3FNMWJLV2lhdXUv?= =?utf-8?B?Ymt4cFowc0M2aUxZSm9xRXFscERmTmloc3RhcHpBZ2RUNTZkN2cwME5iQ01o?= =?utf-8?B?cEViTmVrUURVWEVyTysrUUFHWndwM0Z4NTFwbUFzUzJweVNWT2VGbDZSdjBE?= =?utf-8?B?aDd4MnNFbG9lRHFLUlhmNUZOdzhrMkhSOE5FMUl2RXd0WHIxTDJXb0JEVmZw?= =?utf-8?B?bkpOUW8rYUpkOWM1TVppWS9LdUR1QWtVNDlSOWl5YzBsQWl0aEMwNjA0Zkdt?= =?utf-8?B?bGtWYjRNZ3NveXUxVWpmcGVER1diWXI3S1JBVUJla1RQcGxTMTF4WnRvOE54?= =?utf-8?B?NUdvVHh5TmJEQUVpVkRROFMvdlZHUkRaRm1vQlR1N2QrYjV5VDJUMVlGYlBi?= =?utf-8?B?US92eU1keis2RTRlR3hJU0tXTXhJV1RpNnMzZ0l1bndiNWF4aUVMdkpZMk1h?= =?utf-8?B?UFlvOFlCYVVsYXdpNm9hV2VyVGFqU2NIbWhLcmZYTWNEYWxvUTJ0QmIvVjhJ?= =?utf-8?B?QnRXTXRibTNXT0hlL2ZoVTdob3B4eHY3a3AxUGtJRHZiOW9SZ29UZWRSQkF4?= =?utf-8?B?aC8yNEUvK2JwaVVvdHAxQ042VHRJc3VzM0c4TktrQnhYZGY0dDdrZTNDV0Jj?= =?utf-8?B?M0l1WnEzRS9CRU9RcTJXM0llaWUxOGdDQlBQNmZKdkEyci82dDdkZVpjNDJz?= =?utf-8?B?RjU0U1dWMlNQR05ubS9hNXE3dEVQdU5YdkgwSXlwWk4zL0w2MnJKZm1peGdQ?= =?utf-8?B?dW0vVmtzTExFNG5vVE10SWRWSUR1VTZaV2owZ3pzWE5HbEluWW9GbFdQZDg2?= =?utf-8?B?a2hwcVU5MjM1OVdyZXJZRWlIRm5WamVaT1J1V0UvREtib0RySTZVNlZWM25H?= =?utf-8?B?MmdqbXA1UVg5MTQzYm9SK2ZVN25hWFVFdkc1dUlrelhVdGlJcUpXd25ZUGZi?= =?utf-8?B?d1lKMXFKOVQxLzBISWc5eEt0TzRhcVlpNXJoNWlWZDZHWFVUazJTNFBCclVF?= =?utf-8?B?OHZVUkRzZng5TnpYRnpTVmNKd2h5UVliR21BTnVkU01KNk9UbW12Q0FUbWJV?= =?utf-8?B?Z1UyeXlBRmhEWENrM1JYbVZaemhkVUc5WVRXbk5Dc0gvV3ZVSnVJYTY2Y01p?= =?utf-8?B?a0k5OU9HOW4xazBHa0xSYWM3SGJGVG5KTDBSanZscnVvY1JjS091SUFFdjRE?= =?utf-8?B?L2FZalh3Q2h6WVJJWFZZR0pmL0VidmRPYXIrTXhoc0RvVlJidU0zS1RZRU5p?= =?utf-8?B?Sk0wQjkvbWZLd3pqZy9PRWpmV0ZtOGwxRUtHaWhOaURiN01zUGxkZ1p5UkZT?= =?utf-8?B?aGxtYTYrTnl2cnRrWjBBMnY5UUlBbUdyUVhTWFFWY0hqY3Y3WEIwUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5de19304-362c-4e55-abc7-08de5e5e6a58 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 11:14:33.9124 (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: QhuETDSqSYppmCo0tU8RYGi+upQNf3cAJjghnVwgyMQyMjVEDVACLm3T4LsOFpBGaznDP3fr7c+DkNw63hiqvg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV4PR03MB8188 On Tue, Aug 26, 2025 at 05:28:29PM +0200, Jan Beulich wrote: > Hello, > > the other day I observed a strange issue with XTF's selftest failing to > have its VMs created, when running all flavors in a group. (Other tests > look to be similarly affected, it's just the selftest that I run most > frequently.) Originally I suspected a PVH-specific issue, but the > problem surfacing only there is because with PVH Dom0 I have less free > memory left after boot than with PV Dom0. Beyond that, both > configurations use the same hypervisor, with built-in DOM0_MEM="-255M". > > The issue looks to be further affected (but not caused) by domain > cleanup being quite a bit slower under PVH Dom0, compared to PV. I.e. > by the time the 2nd test is started, memory from the 1st one still > wasn't completely freed. The result is that randomly one of the latter > (batched) tests fails at domain creation ("failed to free memory for > the domain"). > > xl's freemem() calls libxl_set_memory_target() followed by > libxl_wait_for_memory_target(). The latter function expects the domain > to balloon down enough for its ->tot_pages (in the hypervisor) to be > at or below the previously set target. However, already immediately > after boot "xl list -l" and "xs ls /" show target values which are 1 > page below the hypervisor's record. With libxl_set_memory_target() > requesting relative adjustment, the Dom0 kernel will balloon out the > requested number of pages, but ->tot_pages going down by as many pages > isn't enough to please libxl_wait_for_memory_target(). > > I'm not even close to having an opinion as to where the problem is: It > could be that the kernel's balloon driver is off by a page. I'm more > inclined though to think that it is entirely unrealistic to expect the > kernel's balloon driver and Xen to have an exactly matching view of > the memory owned by the domain. Yet then it is simply invalid to > compare values taken from Xenstore against values taken from Xen. While > problematic for absolute requests, for relative ones it should be > possible apply the decrement to the source later used to compare > against while waiting. Little late, sorry. I think: xen/balloon: improve accuracy of initial balloon target for dom0 https://lore.kernel.org/xen-devel/20260128110510.46425-3-roger.pau@citrix.com/ Might improve the situation here, as it should make the dom0 initial balloon target match what the toolstack expects, and then (auto-)ballooning targets should also be accurate w.r.t. the memory freed by dom0. Regards, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 28 11:14:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 11:14:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215466.1525652 (Exim 4.92) (envelope-from ) id 1vl3VW-0006PL-1u; Wed, 28 Jan 2026 11:14:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215466.1525652; Wed, 28 Jan 2026 11:14:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl3VV-0006PE-U5; Wed, 28 Jan 2026 11:14:45 +0000 Received: by outflank-mailman (input) for mailman id 1215466; Wed, 28 Jan 2026 11:14: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 1vl3VU-00069J-Hn for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 11:14:44 +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 8a9409e6-fc3a-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 12:14:42 +0100 (CET) Received: from BN0PR04CA0011.namprd04.prod.outlook.com (2603:10b6:408:ee::16) by DM6PR12MB4330.namprd12.prod.outlook.com (2603:10b6:5:21d::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.16; Wed, 28 Jan 2026 11:14:35 +0000 Received: from BN1PEPF00004682.namprd03.prod.outlook.com (2603:10b6:408:ee:cafe::8a) by BN0PR04CA0011.outlook.office365.com (2603:10b6:408:ee::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.7 via Frontend Transport; Wed, 28 Jan 2026 11:14:32 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN1PEPF00004682.mail.protection.outlook.com (10.167.243.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Wed, 28 Jan 2026 11:14: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; Wed, 28 Jan 2026 05:14:31 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8a9409e6-fc3a-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=eh1wdTRv+p7bqlN7cbGK7V1mOQscwOiLwNoDA10MZSkhqb7S2zCrVuq4aMvjRD2AbbRAk1D6KXcuzxXa8LfmqQ6RbymippEevWU3Znaq83FyWcYN56tTby+109F2H0o15b2CtJSmkBgj8ey2AmZS+wdbxByByNI8ELjbd6LWgpxydr7rYbgwnJ5lHpDsUYenkHI3RwATmhhF1xLmRaQ0C6mlmERpeQ8794WAo5+g3cRoxTjf737zf3VKA1SrCcXznPaiF+EORwBNy1TYbEg3gIvCby58y/ETpIqFld/7CRy3LPmY8tiCDxSZpSxQ408oBh1ttQ3hleJ6et6nUiXbBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Nmdln9IfYbE3xS7x6S1pNzejttN4bY3xIazqICmNh3g=; b=rBqZblKK3UZLvZ9g3ggq1yW7qbrCgYm+bYc+Ep0pl4nUHxi/ogBhsBwU2AhGqTT/CeJ/J4FyR0Up9zeSyfMAwPHv/wI9/6+3pGMIEUlsiSJTRrdru8CZEHPYsoU7C6LmTCV5IczLhJXcRrGXWMxwnMvgFqqqFbnuGZGLNKCLbIlkLw69hoV8jzAUAt8u52wAEpU7v9DvKFIGwMgt7BkWFB+CVyaZWQwuwrJGAdU6cQSljc1Ji35adC9+JyKQ1NgiHPY1tAsIQumM1hAf/vTGXfAWG1KG4IYr1m1B2yqDsvXbRbp0CxDn8/coaUjcXFIbtvh3R117yYq0WN8fnYhaIA== 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=Nmdln9IfYbE3xS7x6S1pNzejttN4bY3xIazqICmNh3g=; b=J96MmjEE9oaaVflqckcLFSbIF9acLigZ6bK9u89986QasB2Us8OhLj649Wt7KK+MF7MImgLmqTZkfDUHQczjAlSSFsXT3QeW+aGEx3SYPcyIJy6u1u3QAeKoCoHSG+UEm+LwyM+1llx4ur6Ie2xTYoxLi9q+YjLWeJwXeblMLao= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 28 Jan 2026 12:14:28 +0100 Message-ID: CC: Andrew Cooper , Anthony PERARD , Michal Orzel , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Subject: Re: [RFC PATCH] CODING_STYLE: Establish a policy with regards to copyright notices From: Alejandro Vallejo To: Jan Beulich X-Mailer: aerc 0.20.1 References: <20260127182403.141459-1-alejandro.garciavallejo@amd.com> In-Reply-To: X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1PEPF00004682:EE_|DM6PR12MB4330:EE_ X-MS-Office365-Filtering-Correlation-Id: 6382b589-2115-48e6-9d6f-08de5e5e6ae7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|1800799024|376014|82310400026|13003099007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?UU1WRGoybUtSbnJxVXJ3dVlsRlZ5Zis2UFJ5Y2dNZTRDWWZDcVZBWDZoL3Rw?= =?utf-8?B?S2pqUDhockhLVkVFR25GeS9rZTZNbUdMaTlUVzduUHdNRjdRMUJnaE02cU1T?= =?utf-8?B?a0l0bW9yc1c5SDgwa3BvM0VSZVY0cWZ4aVZYMzZQdWRuUjRsNTJXbXRPeXZv?= =?utf-8?B?dS94RXg3WFNIRndtZVFoc0pqSXR2T2F1eXNQVnlkejZ0K2VnYWl0Z3dPb2Fh?= =?utf-8?B?MHNHcWlVaS9WVXJ1Vk42UUY4Zjd1R0x4NXhBcHFRUGQ5c0pJTVhuUlhkMFlC?= =?utf-8?B?Mmd4Qjg2ODk2RmxSekhQKzFna0c3c3p1emdSUHBVN0VtWHJuVytXTjllNXpW?= =?utf-8?B?eTQ0Z0xJdlRSdmJXSkJyODlqaTZPRmNJRGRkZ0g5WGViL1RuaGk1TUhKVTRt?= =?utf-8?B?anJVYXFEOWN4VEcxUUZ1WmhRT1pTNEJSZjRrNklyekZBV25aWDdnbnVheHRl?= =?utf-8?B?ZVdBMVlTdUdiSE50bTB0U2kraUltckwwc1pOWDlYQ2xrMjQwUVBSalY3b0VJ?= =?utf-8?B?TFFJMEh1Y1FDQlIyeDcra3ZuY3NSYzR1eHkydHNHdndlcjcyNkZ5NWVxU29y?= =?utf-8?B?REl5ZXhLS3B4RU5JRWRSVUlUYnl2bGdUcjREb0JNRVBKYUpCaHVMTlF1d0RS?= =?utf-8?B?ZUJhak9mQXk1a3d0ZEZFWXYwaFpLY2swOFh5d3VoOGJwTXVNSTYvZkQ4TE1S?= =?utf-8?B?aDMzU1ArenBaTDM1b0lHTU5QK2UzNlhuMCtVZ3JNOFBtazkwaUhkendRZXdz?= =?utf-8?B?bGo2TjNEK1dYejVCYllwdEdtT2hwUG9za1NuS0xkT1JQK2VmZzJRK0FtN0hB?= =?utf-8?B?L0c2eks4dFZCcUZoQmhRSG44T2FYaTl6em00VSsvSW5aTEFWaVk0RTViVFQ2?= =?utf-8?B?T2FqYkIwOFBGdldZUlhEaktSV1RoVDRuYUdoaVQ3TzhlVGlWVzRES3FwUWpi?= =?utf-8?B?aW9qL0QyS0QwcUVqRGZ4amY5ek9BSmFKeUZxazV0V2c5Nm1SYjJMYW1UbEdV?= =?utf-8?B?dFdtODFLQzJEcmd4OUNzVW1Rc1VNandCVHNURWVhTUZialU2bk84cS9uWWNq?= =?utf-8?B?MHlpQWw3WTA2aVhPY2N3VFVaQlZLU25keFFCMXpYMkdTSDlmaHJHalJHeUlF?= =?utf-8?B?UHQwU283ZkpPNlFmZlZ2VGFPUlpHdUJydmFPa3BVTWxHN05nS3NJTlk2enFP?= =?utf-8?B?dmtPeDdMUnQ2bDU1Q2M5VGhueWhYVGpKMjR6byttUUs4SWJSbDNMN0NLYUZC?= =?utf-8?B?NFVFWDFBTlJsODk0cmhjc2xya1ZTZWlJbkhoa3FmTTNnbXh6UHNTZFJ5V3VS?= =?utf-8?B?QXk3MWNqbkNKMThBakhkWHkvOGUweEV1THJPU1AyRURKd2hQV1FvTEZzMWha?= =?utf-8?B?eWR2ME95bmpjeUV5SDBpV1lySFhuYjExSHQ1UnlIV3dIdUxZdGtnV0VOSDd6?= =?utf-8?B?bGpXWk9HR0k4c2pNLzJDQWFCRXVSeU5SbnpmMVhMa2Zhc055TjA4UVZ2N0xR?= =?utf-8?B?TjIvOFBUUENiZlV3QWJzY3dUK0M1REp5SytEV0JiNGw3NXJldUVuRVJSS3hD?= =?utf-8?B?eWtwaldLNTNZYkVjei9ja2t2RnU3bU9LWlp2OGx3d3lMai9zK2JFTHFrWmVp?= =?utf-8?B?TmFEZHBJRU5CQ1hiTTVKdXVaQ0xKSlFjYVNTeE5ZT29KNm80THhoRmJLN0tI?= =?utf-8?B?eFJjWkZ6RUdRZmt2cXM2bjBkOE5CTEgraXhucmdYWFN0UTgxSzNvcjhDWEZk?= =?utf-8?B?bVUrcDloV2hNVGJVaE81RjRCcHdmdTgwODNEZ1dWblN5MWY1aDF0UGdDcXF1?= =?utf-8?B?UkVFRjRpK1ZHcFRoREs3NUhIUjdzTTdjOHhzdWkzTWxHRjFrMkxacUovd0Rn?= =?utf-8?B?Uk0rQzdlZzVtSXd1ejJud1p6bGM2dmtVNXFjMFpjL0p4cW45Q0F0NFNLSmFY?= =?utf-8?B?bkFzR3NzeFlRZGY5RVN3cWZNcjFxcHhlcUlGK1htYUhmOEFxUFNNbFdXSVRM?= =?utf-8?B?bVdaY0tCR2ZHejhWY0FGZWdUQWVFL2FHbk83TnVZcUt0VTlDc1UwSHJ6ZXdW?= =?utf-8?B?SGRydExQRytQeUxwMDVNMWpiNGxKSnMzOTJCTjZIQU1Sd3QzZTVDUE9ic1JP?= =?utf-8?B?NGQ4QmUwL0hIM2pIVVYvQmgxM3BFbzFlVjUwMWdWN0NUOE9pOEVxYW1LaVMy?= =?utf-8?B?dWc9PQ==?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(1800799024)(376014)(82310400026)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 11:14:34.6211 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6382b589-2115-48e6-9d6f-08de5e5e6ae7 X-MS-Exchange-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: BN1PEPF00004682.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4330 On Wed Jan 28, 2026 at 11:45 AM CET, Jan Beulich wrote: > On 28.01.2026 10:09, Alejandro Vallejo wrote: >> The refinement also applies to the second bullet point, so I can add it = as a >> separate paragraph stating existing notices are to never be modified and= only >> removed with the express consent of the current holder(s). > > That's interesting, as it may be getting increasingly difficult in practi= ce. > Often you can't get hold of the holder(s), to the degree that - as we're = all > growing older - at some point they may not be there at all anymore. Yet i= f > not having such notices is going to be a goal of the project, retaining s= ome > indefinitely can't be the intention either. > >> Do you have a take for/against moving all existing notices to a separate= NOTICES >> file (a-la Apache). The existing file for them (in httpd) looks like thi= s, so >> they took the liberty to rewording the banners to be more digestible in = single >> file inclusion. >>=20 >> Apache HTTP Server >> Copyright 2026 The Apache Software Foundation. >>=20 >> This product includes software developed at >> The Apache Software Foundation (https://www.apache.org/). >>=20 >> Portions of this software were developed at the National Center >> for Supercomputing Applications (NCSA) at the University of >> Illinois at Urbana-Champaign. >>=20 >> This software contains code derived from the RSA Data Security >> Inc. MD5 Message-Digest Algorithm, including various >> modifications by Spyglass Inc., Carnegie Mellon University, and >> Bell Communications Research, Inc (Bellcore). >>=20 >> This software contains code derived from the PCRE library pcreposix.c >> source code, written by Philip Hazel, Copyright 1997-2004 >> by the University of Cambridge, England. >>=20 >> It'd blur the scope of existing holders, but code moves and so do their >> contributions. Keeping a banner on a file after a refactor is just >> misattribution. >>=20 >> ------------------ >>=20 >> In short. There's 1 question in 2 forms I'd like to have an answer to fr= om a >> core maintainers. >>=20 >> Would you be willing to ack a change along these lines? >> 1. to a Copyright Notice policy within CODING_STYLE. > > Likely, once we've agreed on suitable wording. > >> 2. to the relegation of existing notices to a NOTICES file in the styl= e of >> Apache. Apache in particular mandates the file not be touched unles= s >> absolutely required for legal reasons. > > Very unlikely. While likely I wouldn't veto it, I don't like such moving = around > of things. If we want to get them out of the source files, they should be > dropped altogether. Ack to both, thanks for the input! Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Wed Jan 28 11:22:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 11:22:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215488.1525661 (Exim 4.92) (envelope-from ) id 1vl3dD-0008Vx-Os; Wed, 28 Jan 2026 11:22:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215488.1525661; Wed, 28 Jan 2026 11:22: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 1vl3dD-0008Vq-MC; Wed, 28 Jan 2026 11:22:43 +0000 Received: by outflank-mailman (input) for mailman id 1215488; Wed, 28 Jan 2026 11:22: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 1vl3dC-0008Vk-Rb for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 11:22:42 +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 a12f2768-fc3b-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 12:22:29 +0100 (CET) Received: by mail-qk1-x732.google.com with SMTP id af79cd13be357-8c7199e7f79so7950585a.0 for ; Wed, 28 Jan 2026 03:22:29 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8c711d2cdbbsm159115885a.28.2026.01.28.03.22.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 03:22:27 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a12f2768-fc3b-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769599348; x=1770204148; 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=PTmGB00vk7/kp+zIH4DKz/eDu1tVIye+prcQ+wtOs/w=; b=NCy30xB25WWyG7nj89w3EvCHW3V/R8xipLnPgcVinkU+VHh9AndlHd27B3FDSsCzk9 pOYy7S+x6vBETfuhJfgkS4Cll4FsQEzayI2neE3HkeBIE5sx8iH0u9si3ctRl2kYdITp n7lke0ZjwPGnOq7B/NjkkiDWKcSYacBjbDIC6xLxEtsXMWoR6FlzFhAQ0742ZVzNt1jO P4otzCgCMotQ+Awrc6v90ywhMlaSx8PZLIogFelmmvIWpN4YHSnrwheayq3RAKmHWDT9 UBqvtpnnWwmr3YYK4eyw00piz4HTYFBipGhVoOzjsyLI3O2MDvhXwdNCctBv+sPmxjnu FNyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769599348; x=1770204148; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PTmGB00vk7/kp+zIH4DKz/eDu1tVIye+prcQ+wtOs/w=; b=L6oLO9YfBgpPwPsxneEDXez9BwRBqL0HRYLGzhtnb7PbhwFrvWskIqcS50dbzXWUKm rZywvTTCYMv/XCj3+0omjdjOjNFGt4RZ3d44djy8Zzx6NC3ke2ZTDyFIswxydcqHuQcQ trC8lPlVcfALSfBFOpftRCBZUnaSlULA2BgAUfGLsIGFyttjt1bOi7z247kf7TqqXGHW HE/f+iMRGqorgZtgq40AomgB0MU18A5JHy9baOTlwRsnqnKIFjI8Ia6gB1dfxqUVPQjy AaAjPvTED2kBkkN37d5Xs+GTEnIHc+327lpxYyZyZ74KW+/JgsaX6YLdX3BnnW5Fv1nK c9EA== X-Forwarded-Encrypted: i=1; AJvYcCUIUILANFIbPNWwtqLhaHyxQKPNdKEoH6B1dUNB9x29gXNAhcrRl6u97MftMZsowPe7pRvVSBT8RbY=@lists.xenproject.org X-Gm-Message-State: AOJu0YwSaW+AgLUWsLF7H/lmIkUDRdEr7wzKnx6OgzLAdZK5tFXz77ty lIIe7oxT4Az5YljcicYobUUfYy5OKu8VDd4/0cTaDmnVHWf879T8yFbL X-Gm-Gg: AZuq6aIY20HRESYrvojgsfJLbGtqqT09j4vxL7UI+WRIb8WovcSMQz4h2aG0on1XPyK o1cstG9qBCrOgf/nex4lRZ1pxm8Yj3lvJ70YExqwzhMqGsqar+wwEVIpdON9dYS8s5YC+fWWb1x Fz7U/LKMAAgNQu/0PWfdnuptkNlCu6iW1NWByrcypIFgo3LMbGkXcnPJvK4Fi1SUvDoZyBl96Dm hFF0UzhP5m0QG9PqdQ8iQOkN6gIMQLG02VMaBlbiwtyNlt5vbtYdus/2X/iMzDtYagRRDKr1sWf 1qleKyAXxt6TcR2JYriUAJO9rfwDoF5kbE1fgcXAaGU/ENZaRvmZ2EeNOcHgo8aYpdHZVWNLDzu rlNQozw+CCLwSvDfuzzOJnSYFNhbp/QerkB4WAmuU5JfMGCU9GM51prL+AniolurPnaklMUWT7G 9fr7YheeKZ9UfPqGdXrG/8EeacZKtUhnuxr3To/OvPK2ymxWfa0eT3PA7WofXcn7A= X-Received: by 2002:a05:620a:7103:b0:8b2:ed02:21ea with SMTP id af79cd13be357-8c70b90fee5mr590373385a.67.1769599347874; Wed, 28 Jan 2026 03:22:27 -0800 (PST) Message-ID: <8ec02eba-3271-45ce-8157-0d444ed9da62@gmail.com> Date: Wed, 28 Jan 2026 12:22:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] xen/riscv: dump GPRs and CSRs on unexpected traps To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <27ab0f8eb6fd6ecef1eeefa4a05e4fe1f43acbbe.1769427484.git.oleksii.kurochko@gmail.com> <88edf7a2-c5f1-41fd-9ceb-8cc0c345b7e6@gmail.com> <132efa57-bd11-47b9-b3c8-0c09589f70b2@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <132efa57-bd11-47b9-b3c8-0c09589f70b2@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/28/26 12:08 PM, Jan Beulich wrote: > On 28.01.2026 12:01, Oleksii Kurochko wrote: >> On 1/28/26 11:34 AM, Oleksii Kurochko wrote: >>> On 1/27/26 10:27 AM, Jan Beulich wrote: >>>> On 27.01.2026 10:14, Jan Beulich wrote: >>>>> On 26.01.2026 12:43, Oleksii Kurochko wrote: >>>>>> Provide additional context when an unexpected exception occurs by >>>>>> dumping >>>>>> the relevant Supervisor, Virtual Supervisor (VS), and Hypervisor CSRs, >>>>>> along with the general-purpose registers associated with the trap. >>>>>> >>>>>> Dumping VS-mode CSRs in addition to host CSRs is beneficial when >>>>>> analysing >>>>>> VS-mode traps. VSCAUSE, VSEPC, VSTVAL, and related VS state are >>>>>> required to >>>>>> properly diagnose unexpected guest traps and potential hypervisor >>>>>> misconfiguration. >>>>>> For example, on an illegal-instruction exception the hardware may >>>>>> record >>>>>> the faulting instruction in VSTVAL. If VSTVAL is zero, VSEPC should >>>>>> always >>>>>> be inspected, and can be used together with objdump to identify the >>>>>> faulting instruction. Dumping VSCAUSE is also useful when the guest >>>>>> does >>>>>> not report it, or when the hypervisor redirects a trap to the guest >>>>>> using >>>>>> VSCAUSE, VSTATUS, and VSTVEC, allowing verification that a >>>>>> subsequent trap >>>>>> is not caused by incorrect VS state. >>>>>> >>>>>> Signed-off-by: Oleksii Kurochko >>>>> Acked-by: Jan Beulich >>>> Hmm, wait, there's another anomaly: >>>> >>>>> I still have a question though, which can be addressed incrementally. >>>>> >>>>>> --- a/xen/arch/riscv/traps.c >>>>>> +++ b/xen/arch/riscv/traps.c >>>>>> @@ -99,12 +99,70 @@ static const char *decode_cause(unsigned long >>>>>> cause) >>>>>>       return decode_trap_cause(cause); >>>>>>   } >>>>>>   +static void dump_general_regs(const struct cpu_user_regs *regs) >>>>>> +{ >>>>>> +#define X(regs, name, delim) \ >>>>>> +    printk("%-4s: %016lx" delim, #name, (regs)->name) >>>>>> + >>>>>> +    X(regs, ra, " "); X(regs, sp, "\n"); >>>>>> +    X(regs, gp, " "); X(regs, tp, "\n"); >>>>>> +    X(regs, t0, " "); X(regs, t1, "\n"); >>>>>> +    X(regs, t2, " "); X(regs, s0, "\n"); >>>>>> +    X(regs, s1, " "); X(regs, a0, "\n"); >>>>>> +    X(regs, a1, " "); X(regs, a2, "\n"); >>>>>> +    X(regs, a3, " "); X(regs, a4, "\n"); >>>>>> +    X(regs, a5, " "); X(regs, a6, "\n"); >>>>>> +    X(regs, a7, " "); X(regs, s2, "\n"); >>>>>> +    X(regs, s3, " "); X(regs, s4, "\n"); >>>>>> +    X(regs, s5, " "); X(regs, s6, "\n"); >>>>>> +    X(regs, s7, " "); X(regs, s8, "\n"); >>>>>> +    X(regs, s9, " "); X(regs, s10, "\n"); >>>>>> +    X(regs, s11, " "); X(regs, t3, "\n"); >>>>>> +    X(regs, t4, " "); X(regs, t5, "\n"); >>>>>> +    X(regs, t6, " "); X(regs, sepc, "\n"); >>>>> Does this sepc value differ from ... >>>>> >>>>>> +static void dump_csrs(unsigned long cause) >>>> What is this function parameter for? >>>> >>>>>> +{ >>>>>> +#define X(name, csr, fmt, ...) \ >>>>>> +    v = csr_read(csr); \ >>>>>> +    printk("%-10s: %016lx" fmt, #name, v, ##__VA_ARGS__) >>>>>> + >>>>>> +    unsigned long v; >>>>>> + >>>>>> +    X(htval, CSR_HTVAL, " ");  X(htinst, CSR_HTINST, "\n"); >>>>>> +    X(hedeleg, CSR_HEDELEG, " "); X(hideleg, CSR_HIDELEG, "\n"); >>>>>> +    X(hstatus, CSR_HSTATUS, " [%s%s%s%s%s%s ]\n", >>>>>> +      (v & HSTATUS_VTSR) ? " VTSR" : "", >>>>>> +      (v & HSTATUS_VTVM) ? " VTVM" : "", >>>>>> +      (v & HSTATUS_HU)   ? " HU"   : "", >>>>>> +      (v & HSTATUS_SPVP) ? " SPVP" : "", >>>>>> +      (v & HSTATUS_SPV)  ? " SPV"  : "", >>>>>> +      (v & HSTATUS_GVA)  ? " GVA"  : ""); >>>>>> +    X(hgatp, CSR_HGATP, "\n"); >>>>>> +    X(hstateen0, CSR_HSTATEEN0, "\n"); >>>>>> +    X(stvec, CSR_STVEC, " "); X(vstvec, CSR_VSTVEC, "\n"); >>>>>> +    X(sepc, CSR_SEPC, " "); X(vsepc, CSR_VSEPC, "\n"); >>>>> ... the one logged here? Nothing changes the register between entry >>>>> into the hypervisor and coming here? >>>> Down below here you have >>>> >>>>      X(scause, CSR_SCAUSE, " [%s]\n", decode_cause(v)); >>>> >>>> which actually (largely) duplicates what do_unexpected_trap() has >>>> already >>>> logged. >>> Missed that, then it would be better to remove this duplication and leave >>> only printing of CSR_SCAUSE in dump_csrs(). >>> >>>>   If dump_csrs() gained other uses, the dumping of scause likely is >>>> wanted, but then likely no scause value would be available to pass >>>> in? So >>>> maybe its dumping actually wants to be conditional (and the parameter >>>> wants to be a boolean)? >>> Good point. Honestly speaking, I don't know if it will be any other >>> usages >>> except this one. But to keep things generic I think it is good idea to >>> add conditional dumping of scause. >> As an alternative, we could simply remove the dump_csrs() argument and always >> print SCAUSE. When running in hypervisor mode, SCAUSE should contain the reason >> for the trap. Even it is lets say just hypercall and not something faulty, it >> will contain "Environment call from S-mode" what looks okay to be printed. >> >> I tend to prefer this approach slightly. What do you think? > It means that it'll be logged twice for an unexpected trap. As said, I can > only recommend to limit the volume of the output in such situations, as > sometimes all people may be able to get you is screenshots. It will be logged once, basically, mu suggestion is: -static void dump_csrs(unsigned long cause) +static void dump_csrs(void) { #define X(name, csr, fmt, ...) \ v = csr_read(csr); \ @@ -156,11 +156,7 @@ static void dump_csrs(unsigned long cause) static void do_unexpected_trap(const struct cpu_user_regs *regs) { - unsigned long cause = csr_read(CSR_SCAUSE); - - printk("Unhandled exception: %s\n", decode_cause(cause)); - - dump_csrs(cause); + dump_csrs(); dump_general_regs(regs); ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Jan 28 11:27:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 11:27:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215498.1525670 (Exim 4.92) (envelope-from ) id 1vl3hx-0000nG-9P; Wed, 28 Jan 2026 11:27:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215498.1525670; Wed, 28 Jan 2026 11: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 1vl3hx-0000n9-6Y; Wed, 28 Jan 2026 11:27:37 +0000 Received: by outflank-mailman (input) for mailman id 1215498; Wed, 28 Jan 2026 11: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 1vl3hv-0000n3-Pz for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 11:27:35 +0000 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [2a00:1450:4864:20::32c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4fd4df47-fc3c-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 12:27:21 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-47edd9024b1so56131315e9.3 for ; Wed, 28 Jan 2026 03:27:21 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806d98c8desm45854915e9.3.2026.01.28.03.27.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 03:27:20 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4fd4df47-fc3c-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769599641; x=1770204441; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=ZVpOSUXzCiwxMHX5M5St66mv0ViHigMh18IDOvqmHVI=; b=FIROVEFnhtT6NwgiYIL7cWgZtnJzGewy0qGyY1uLxoLQI/DWgQtgZ1+f7aIQk/pbhH lKV/KpuXAXYm8XVPvvuI/Asnr2OPjRqf/2DUq9fd8LqQQWb3HmS17o6kg6Rj5dzlC2G/ RBTfuO1NsJyqmtZriJvpsk7ck99nyN27IvYlCo29gXK2H/Yg70rJfeLlStwdtyS1XOno iZXLfCiB6pqY+hCg5T5iTGIuEHq0z/7XdSUuVhljAJ30tuKryQjWiwapGmZAbsz+gE6P MoF3ueoYe2ly9VVX7425e09Qyc/aOxnYn8Fhb8XC+v341+WXoNh6pGv6jvIT/w/El6bR 5Bdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769599641; x=1770204441; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ZVpOSUXzCiwxMHX5M5St66mv0ViHigMh18IDOvqmHVI=; b=aLcZuBCTMksQFp3GCswMb/2Rc9pHNHyrqXsSi5EWJMLG5im0hzT7UCOUrphziG/pSp F2/K6Lv74imZv4Ctjj/8ufnbfOJI21rfOmy9NO5n1EwdlIelfUnC1ZDVZiboe2XjHMrw u3TndaukQaA3+d1YXytMZ65qVCN0WhYIUYHa9d8XAmhnO7VSy2r1SJTL50vKvvUI6mIo iXGoF44jEs1/i4qVjGIcLpST099BMMoBgMRIw1KGhkWtf5eJaghcuN+X0FxOykiKnMpe AeLfI5kF1XUS+Yx3m1owmzssoXYTF9QpdjdPH23tJABfLvmSF8G2+ivw+FiaojhEZGBY MmDw== X-Forwarded-Encrypted: i=1; AJvYcCXvgpGUO0+Pnc/wioeZERX2J72YvaYp4oA7t3EwEUgfRVoiI8pFoKIHsl9zYEdsR0Pvzs/dPt7au1c=@lists.xenproject.org X-Gm-Message-State: AOJu0YwSGrdh8pQ0i6o2LHWVTmqxCT84d97t3d8MewObSmLRYSY+I0mW AJYWz7zSgX2pMe/h2Vf4cR8voRUAUtkdRE/lz656rL3Ny8jZiX12oovldP8bClnunQ== X-Gm-Gg: AZuq6aL9DOGY2dnXVIg1tqd+NyOmC/zenSmTq1dSG94MRxCJrD1grv7A0G8gIOrcDNs gRs737R1oy2muEzrmyBm+8uwLkobHMnK005s5n8Kdb0uwz7+r4eeDJnc6rVp5XbIQuN2kjPw313 edw/oD8n9/LVEIFVruDx7YYV8EWS3YmjSDulLkTttvbZHgaM1TW4MvBF1RDP1OIXjxvgLu2pEJ7 24o9OhiS0yglcMY96FRAMCMcbGGacjUzXtkxU3J/YwPtexemlrWaXlzejgtWCWcxMXTStiz1/5y etp2XuvaFdXAZeOcCqmoy9nemQ8BvGWB/rhLX8eVpkOkJ7Wq4r/E1NDY9uB5gW6zFfQPUP3gwoa YpEDgevxayv4o+OxyuKm8IaEfrLYEDyoVC4bj35de2BjS4XS984zkR6vgH5baNtsmZBRY0zdKl1 kxZbVrcHDigeDQK67bun2S+xiuu54W+zpptACM56I/DbDEBg3u91hhn8NdfYrj32WNkGCTlM6mf Bw= X-Received: by 2002:a05:600c:4689:b0:480:6941:d38b with SMTP id 5b1f17b1804b1-48069c92bd8mr61871195e9.30.1769599641029; Wed, 28 Jan 2026 03:27:21 -0800 (PST) Message-ID: <46b4e715-3b4d-457e-885c-2c3b4d9e5165@suse.com> Date: Wed, 28 Jan 2026 12:27:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] xen/riscv: dump GPRs and CSRs on unexpected traps To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <27ab0f8eb6fd6ecef1eeefa4a05e4fe1f43acbbe.1769427484.git.oleksii.kurochko@gmail.com> <88edf7a2-c5f1-41fd-9ceb-8cc0c345b7e6@gmail.com> <132efa57-bd11-47b9-b3c8-0c09589f70b2@suse.com> <8ec02eba-3271-45ce-8157-0d444ed9da62@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: <8ec02eba-3271-45ce-8157-0d444ed9da62@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 28.01.2026 12:22, Oleksii Kurochko wrote: > > On 1/28/26 12:08 PM, Jan Beulich wrote: >> On 28.01.2026 12:01, Oleksii Kurochko wrote: >>> On 1/28/26 11:34 AM, Oleksii Kurochko wrote: >>>> On 1/27/26 10:27 AM, Jan Beulich wrote: >>>>> On 27.01.2026 10:14, Jan Beulich wrote: >>>>>> On 26.01.2026 12:43, Oleksii Kurochko wrote: >>>>>>> Provide additional context when an unexpected exception occurs by >>>>>>> dumping >>>>>>> the relevant Supervisor, Virtual Supervisor (VS), and Hypervisor CSRs, >>>>>>> along with the general-purpose registers associated with the trap. >>>>>>> >>>>>>> Dumping VS-mode CSRs in addition to host CSRs is beneficial when >>>>>>> analysing >>>>>>> VS-mode traps. VSCAUSE, VSEPC, VSTVAL, and related VS state are >>>>>>> required to >>>>>>> properly diagnose unexpected guest traps and potential hypervisor >>>>>>> misconfiguration. >>>>>>> For example, on an illegal-instruction exception the hardware may >>>>>>> record >>>>>>> the faulting instruction in VSTVAL. If VSTVAL is zero, VSEPC should >>>>>>> always >>>>>>> be inspected, and can be used together with objdump to identify the >>>>>>> faulting instruction. Dumping VSCAUSE is also useful when the guest >>>>>>> does >>>>>>> not report it, or when the hypervisor redirects a trap to the guest >>>>>>> using >>>>>>> VSCAUSE, VSTATUS, and VSTVEC, allowing verification that a >>>>>>> subsequent trap >>>>>>> is not caused by incorrect VS state. >>>>>>> >>>>>>> Signed-off-by: Oleksii Kurochko >>>>>> Acked-by: Jan Beulich >>>>> Hmm, wait, there's another anomaly: >>>>> >>>>>> I still have a question though, which can be addressed incrementally. >>>>>> >>>>>>> --- a/xen/arch/riscv/traps.c >>>>>>> +++ b/xen/arch/riscv/traps.c >>>>>>> @@ -99,12 +99,70 @@ static const char *decode_cause(unsigned long >>>>>>> cause) >>>>>>>       return decode_trap_cause(cause); >>>>>>>   } >>>>>>>   +static void dump_general_regs(const struct cpu_user_regs *regs) >>>>>>> +{ >>>>>>> +#define X(regs, name, delim) \ >>>>>>> +    printk("%-4s: %016lx" delim, #name, (regs)->name) >>>>>>> + >>>>>>> +    X(regs, ra, " "); X(regs, sp, "\n"); >>>>>>> +    X(regs, gp, " "); X(regs, tp, "\n"); >>>>>>> +    X(regs, t0, " "); X(regs, t1, "\n"); >>>>>>> +    X(regs, t2, " "); X(regs, s0, "\n"); >>>>>>> +    X(regs, s1, " "); X(regs, a0, "\n"); >>>>>>> +    X(regs, a1, " "); X(regs, a2, "\n"); >>>>>>> +    X(regs, a3, " "); X(regs, a4, "\n"); >>>>>>> +    X(regs, a5, " "); X(regs, a6, "\n"); >>>>>>> +    X(regs, a7, " "); X(regs, s2, "\n"); >>>>>>> +    X(regs, s3, " "); X(regs, s4, "\n"); >>>>>>> +    X(regs, s5, " "); X(regs, s6, "\n"); >>>>>>> +    X(regs, s7, " "); X(regs, s8, "\n"); >>>>>>> +    X(regs, s9, " "); X(regs, s10, "\n"); >>>>>>> +    X(regs, s11, " "); X(regs, t3, "\n"); >>>>>>> +    X(regs, t4, " "); X(regs, t5, "\n"); >>>>>>> +    X(regs, t6, " "); X(regs, sepc, "\n"); >>>>>> Does this sepc value differ from ... >>>>>> >>>>>>> +static void dump_csrs(unsigned long cause) >>>>> What is this function parameter for? >>>>> >>>>>>> +{ >>>>>>> +#define X(name, csr, fmt, ...) \ >>>>>>> +    v = csr_read(csr); \ >>>>>>> +    printk("%-10s: %016lx" fmt, #name, v, ##__VA_ARGS__) >>>>>>> + >>>>>>> +    unsigned long v; >>>>>>> + >>>>>>> +    X(htval, CSR_HTVAL, " ");  X(htinst, CSR_HTINST, "\n"); >>>>>>> +    X(hedeleg, CSR_HEDELEG, " "); X(hideleg, CSR_HIDELEG, "\n"); >>>>>>> +    X(hstatus, CSR_HSTATUS, " [%s%s%s%s%s%s ]\n", >>>>>>> +      (v & HSTATUS_VTSR) ? " VTSR" : "", >>>>>>> +      (v & HSTATUS_VTVM) ? " VTVM" : "", >>>>>>> +      (v & HSTATUS_HU)   ? " HU"   : "", >>>>>>> +      (v & HSTATUS_SPVP) ? " SPVP" : "", >>>>>>> +      (v & HSTATUS_SPV)  ? " SPV"  : "", >>>>>>> +      (v & HSTATUS_GVA)  ? " GVA"  : ""); >>>>>>> +    X(hgatp, CSR_HGATP, "\n"); >>>>>>> +    X(hstateen0, CSR_HSTATEEN0, "\n"); >>>>>>> +    X(stvec, CSR_STVEC, " "); X(vstvec, CSR_VSTVEC, "\n"); >>>>>>> +    X(sepc, CSR_SEPC, " "); X(vsepc, CSR_VSEPC, "\n"); >>>>>> ... the one logged here? Nothing changes the register between entry >>>>>> into the hypervisor and coming here? >>>>> Down below here you have >>>>> >>>>>      X(scause, CSR_SCAUSE, " [%s]\n", decode_cause(v)); >>>>> >>>>> which actually (largely) duplicates what do_unexpected_trap() has >>>>> already >>>>> logged. >>>> Missed that, then it would be better to remove this duplication and leave >>>> only printing of CSR_SCAUSE in dump_csrs(). >>>> >>>>>   If dump_csrs() gained other uses, the dumping of scause likely is >>>>> wanted, but then likely no scause value would be available to pass >>>>> in? So >>>>> maybe its dumping actually wants to be conditional (and the parameter >>>>> wants to be a boolean)? >>>> Good point. Honestly speaking, I don't know if it will be any other >>>> usages >>>> except this one. But to keep things generic I think it is good idea to >>>> add conditional dumping of scause. >>> As an alternative, we could simply remove the dump_csrs() argument and always >>> print SCAUSE. When running in hypervisor mode, SCAUSE should contain the reason >>> for the trap. Even it is lets say just hypercall and not something faulty, it >>> will contain "Environment call from S-mode" what looks okay to be printed. >>> >>> I tend to prefer this approach slightly. What do you think? >> It means that it'll be logged twice for an unexpected trap. As said, I can >> only recommend to limit the volume of the output in such situations, as >> sometimes all people may be able to get you is screenshots. > > It will be logged once, basically, mu suggestion is: > > -static void dump_csrs(unsigned long cause) > +static void dump_csrs(void) > { > #define X(name, csr, fmt, ...) \ > v = csr_read(csr); \ > @@ -156,11 +156,7 @@ static void dump_csrs(unsigned long cause) > > static void do_unexpected_trap(const struct cpu_user_regs *regs) > { > - unsigned long cause = csr_read(CSR_SCAUSE); > - > - printk("Unhandled exception: %s\n", decode_cause(cause)); > - > - dump_csrs(cause); > + dump_csrs(); > dump_general_regs(regs); And the fact that it was an unhandled exception then isn't logged explicitly anymore? Perhaps dump_csrs() then should have a const char * parameter, which here you would pass "Unhandled exception" for. Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 28 11:31:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 11:31:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215511.1525680 (Exim 4.92) (envelope-from ) id 1vl3lU-0002Qh-R0; Wed, 28 Jan 2026 11:31:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215511.1525680; Wed, 28 Jan 2026 11: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 1vl3lU-0002Qa-OP; Wed, 28 Jan 2026 11:31:16 +0000 Received: by outflank-mailman (input) for mailman id 1215511; Wed, 28 Jan 2026 11:31:16 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl3lU-0002QL-9T for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 11:31:16 +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 db01480a-fc3c-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 12:31:15 +0100 (CET) Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-6580dbdb41eso9568977a12.0 for ; Wed, 28 Jan 2026 03:31:15 -0800 (PST) Received: from ?IPV6:2a00:12d0:af5b:2f01:4042:c03:ce4d:a5a1? (2a00-12d0-af5b-2f01-4042-c03-ce4d-a5a1.ip.tng.de. [2a00:12d0:af5b:2f01:4042:c03:ce4d:a5a1]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8dbffb7263sm110619066b.28.2026.01.28.03.31.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 03:31:14 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: db01480a-fc3c-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769599875; x=1770204675; 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=znczj6Y3gseHlfGskrjL6lmLOkTck5hmV/v0qvXsQP8=; b=BY0Jxw5sSxbuQ6BFSvXMS/9QYGa4/6gT/VnGcsRkP3z9lqVVz7VZWT85O+VN2c6XWY QP55F2j7YlLvYnrQWqpuVRxAZAk0ZYpoyRQIclfBy8nKIu85HvWuZYerl6TwDU4cTNZ0 4HntHPBe91OZconFyYVb6tUJhyJurwRHL7yxs/FSZfWAludG+BsZaFGdEZmcnONofBhB QirzN2Lf1eIPO3qlY6yI9iAIfNSO4WWl66EgazEyEvcvCGkW75ABObNDvGFLNi2u3veu QsMl1rAHY2/eCDNh5hnWrYTEB0QqNbDO74NwgjEqbrtcRze9vdWxKsO7NnAPdEMG1srb Yvsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769599875; x=1770204675; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=znczj6Y3gseHlfGskrjL6lmLOkTck5hmV/v0qvXsQP8=; b=D3PAEU4u82K1BpStxDUwSh1vGW5nu5S4P3zObr20bHnS89P8mrMQjDJ7wh3kOe8PEW 51RH2vuuO31xeStQ0CYdmPzDO8hR7bKV5y51wc3T+fODXlcsPSI36kz9ugnxE7kW4vT9 ljkh3SHbpzBQK1/mmBJhd8A7lbqvM2w/sIJ3wMX2147ti2MBbLQVSrNHMxHYImoJIpMk yDaD5nckGfbK43d1Ld6kUdx6L+GZzSCYcnisWgw+WiKmAMzBTjDykNyBnMNu03okof9u Ucqnjjrx44zI1mNKZyUc2tO0H9vQTIxB4wXJynhYNLoe+fJKvql4k1lY6TxfInorZ7QI Td/g== X-Forwarded-Encrypted: i=1; AJvYcCUOKSPtocJPkn5fPSKSicY+qzEeG2QOTiiaNcR5HiUIieH2a4dT+o3SP+DnuNe/eg9z+9aP+2Kgbh0=@lists.xenproject.org X-Gm-Message-State: AOJu0YwL6zctBIbEZYnNZOYTjtncYWXlJ6YwLcg4DxsqhZQvjW2F87FH UBbM6RBeAeOUSFd6UHqwzNTEzSy9kYsOYalVX9LGdkqXJcNJO38uWvevjrvFoqvFdiA= X-Gm-Gg: AZuq6aIIZvkl0UnK4qvBDkeMfCE5PorXUPeve8tV9dP2Z258VRvE2GqdN2Q61YFmdlk DwFAngNkLOSqJnuzg4ZJva+0Aj24VZ3rS02GU83KKX4EvvIOrsG31FKDCxRqkMTwYe1W0mjtLCF c4aYQIkfvcNW0xMcQzkmM7mliOCwGeOw+4Ihqdtoi+3ZiUFJOokHTXsA9xV88gkCHCLOHd/MynQ BJ6IXEe6bEL5pwDcleHYW/eb4xv6WgmA6hmOMDwaDFHgyp6RzehQwPxIlxkpThbg5IEspZpDv2H WqrbHTKYszCdMUKnDznBRxrZvqoaMTbh/VXVLIlpytkDUKyojYBlItPIFZI9tXlXbB9EUMl2mij 7Giy4YFcMYXAh5//At7eWuscH7jrIRm/U5WwvWjCivtlSATNsu+EXg8QUpF8AXfSSG9HzM7iaEc l1k80cqyRzi8NHQGAJp5pD7JWfBj8D5atHylwAgyouPu81hDgG654wf6qdq9vbrDlg4GfnW1jpM 2c236NZVxPAJaOMnzL0Wuv+flYe1nj5IbFRpA== X-Received: by 2002:a17:907:7f8f:b0:b8a:8537:e399 with SMTP id a640c23a62f3a-b8dab45deffmr351003066b.48.1769599874432; Wed, 28 Jan 2026 03:31:14 -0800 (PST) Message-ID: <596b08db-dc0e-4d42-ac17-570ca6e06bca@suse.com> Date: Wed, 28 Jan 2026 12:31:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] xen/balloon: improve accuracy of initial balloon target for dom0 To: Roger Pau Monne , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Cc: Stefano Stabellini , Oleksandr Tyshchenko References: <20260128110510.46425-1-roger.pau@citrix.com> <20260128110510.46425-3-roger.pau@citrix.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20260128110510.46425-3-roger.pau@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Qamlj3oqA4Q6UeDj2NstIo3L" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Qamlj3oqA4Q6UeDj2NstIo3L Content-Type: multipart/mixed; boundary="------------4G5xfRCGlq20KnRkzKR9kuec"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Roger Pau Monne , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Cc: Stefano Stabellini , Oleksandr Tyshchenko Message-ID: <596b08db-dc0e-4d42-ac17-570ca6e06bca@suse.com> Subject: Re: [PATCH 2/2] xen/balloon: improve accuracy of initial balloon target for dom0 References: <20260128110510.46425-1-roger.pau@citrix.com> <20260128110510.46425-3-roger.pau@citrix.com> In-Reply-To: <20260128110510.46425-3-roger.pau@citrix.com> --------------4G5xfRCGlq20KnRkzKR9kuec Content-Type: multipart/mixed; boundary="------------mxlF8SS0BMLPqEDxR4mHA0bY" --------------mxlF8SS0BMLPqEDxR4mHA0bY Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjguMDEuMjYgMTI6MDUsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToNCj4gVGhlIGRvbTAg YmFsbG9vbiB0YXJnZXQgc2V0IGJ5IHRoZSB0b29sc3RhY2sgaXMgdGhlIHZhbHVlIHJldHVy bmVkIGJ5DQo+IFhFTk1FTV9jdXJyZW50X3Jlc2VydmF0aW9uLiAgRG8gdGhlIHNhbWUgaW4g dGhlIGtlcm5lbCBiYWxsb29uIGRyaXZlciBhbmQNCj4gc2V0IHRoZSBjdXJyZW50IGFsbG9j YXRpb24gdG8gdGhlIHZhbHVlIHJldHVybmVkIGJ5DQo+IFhFTk1FTV9jdXJyZW50X3Jlc2Vy dmF0aW9uLiAgT24gbXkgdGVzdCBzeXN0ZW0gdGhpcyBjYXVzZXMgdGhlIGtlcm5lbA0KPiBi YWxsb29uIGRyaXZlciB0YXJnZXQgdG8gZXhhY3RseSBtYXRjaCB0aGUgdmFsdWUgc2V0IGJ5 IHRoZSB0b29sc3RhY2sgaW4NCj4geGVuc3RvcmUuDQo+IA0KPiBOb3RlIHRoaXMgYXBwcm9h Y2ggY2FuIGJlIHVzZWQgYnkgYm90aCBQViBhbmQgUFZIIGRvbTBzLCBhcyB0aGUgdG9vbHN0 YWNrDQo+IGFsd2F5cyB1c2VzIFhFTk1FTV9jdXJyZW50X3Jlc2VydmF0aW9uIHRvIHNldCB0 aGUgaW5pdGlhbCB0YXJnZXQgcmVnYXJkbGVzcw0KPiBvZiB0aGUgZG9tMCB0eXBlLg0KPiAN Cj4gU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5j b20+DQo+IC0tLQ0KPiAgIGRyaXZlcnMveGVuL2JhbGxvb24uYyB8IDI3ICsrKysrKysrKysr KysrKysrLS0tLS0tLS0tLQ0KPiAgIDEgZmlsZSBjaGFuZ2VkLCAxNyBpbnNlcnRpb25zKCsp LCAxMCBkZWxldGlvbnMoLSkNCj4gDQo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi9iYWxs b29uLmMgYi9kcml2ZXJzL3hlbi9iYWxsb29uLmMNCj4gaW5kZXggOGM0NGEyNWE3ZDJiLi45 YjY1MzFlYjI4YjYgMTAwNjQ0DQo+IC0tLSBhL2RyaXZlcnMveGVuL2JhbGxvb24uYw0KPiAr KysgYi9kcml2ZXJzL3hlbi9iYWxsb29uLmMNCj4gQEAgLTcyNCw3ICs3MjQsOCBAQCBzdGF0 aWMgaW50IF9faW5pdCBiYWxsb29uX2FkZF9yZWdpb25zKHZvaWQpDQo+ICAgc3RhdGljIGlu dCBfX2luaXQgYmFsbG9vbl9pbml0KHZvaWQpDQo+ICAgew0KPiAgIAlzdHJ1Y3QgdGFza19z dHJ1Y3QgKnRhc2s7DQo+IC0JdW5zaWduZWQgbG9uZyBjdXJyZW50X3BhZ2VzOw0KPiArCWxv bmcgY3VycmVudF9wYWdlcyA9IDA7DQo+ICsJZG9taWRfdCBkb21pZCA9IERPTUlEX1NFTEY7 DQo+ICAgCWludCByYzsNCj4gICANCj4gICAJaWYgKCF4ZW5fZG9tYWluKCkpDQo+IEBAIC03 MzIsMTUgKzczMywyMSBAQCBzdGF0aWMgaW50IF9faW5pdCBiYWxsb29uX2luaXQodm9pZCkN Cj4gICANCj4gICAJcHJfaW5mbygiSW5pdGlhbGlzaW5nIGJhbGxvb24gZHJpdmVyXG4iKTsN Cj4gICANCj4gLQlpZiAoeGVuX3B2X2RvbWFpbigpKSB7DQo+IC0JCWlmICh4ZW5fcmVsZWFz ZWRfcGFnZXMgPj0geGVuX3N0YXJ0X2luZm8tPm5yX3BhZ2VzKQ0KPiAtCQkJZ290byB1bmRl cmZsb3c7DQo+IC0JCWN1cnJlbnRfcGFnZXMgPSBtaW4oeGVuX3N0YXJ0X2luZm8tPm5yX3Bh Z2VzIC0NCj4gLQkJICAgICAgICAgICAgICAgICAgICB4ZW5fcmVsZWFzZWRfcGFnZXMsIG1h eF9wZm4pOw0KPiAtCX0gZWxzZSB7DQo+IC0JCWlmICh4ZW5fdW5wb3B1bGF0ZWRfcGFnZXMg Pj0gZ2V0X251bV9waHlzcGFnZXMoKSkNCj4gLQkJCWdvdG8gdW5kZXJmbG93Ow0KPiAtCQlj dXJyZW50X3BhZ2VzID0gZ2V0X251bV9waHlzcGFnZXMoKSAtIHhlbl91bnBvcHVsYXRlZF9w YWdlczsNCj4gKwlpZiAoeGVuX2luaXRpYWxfZG9tYWluKCkpDQo+ICsJCWN1cnJlbnRfcGFn ZXMgPSBIWVBFUlZJU09SX21lbW9yeV9vcChYRU5NRU1fY3VycmVudF9yZXNlcnZhdGlvbiwN Cj4gKwkJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZkb21pZCk7DQoN CklzIHRoZXJlIGFueSBzcGVjaWZpYyByZWFzb24gd2h5IHRoaXMgc2hvdWxkIGJlIGxpbWl0 ZWQgdG8gZG9tMD8NCg0KSSBfdGhpbmtfIHRoaXMgc2hvdWxkIHdvcmsgZm9yIG90aGVyIGRv bWFpbnMsIHRvby4NCg0KDQpKdWVyZ2VuDQoNCj4gKwlpZiAoY3VycmVudF9wYWdlcyA8PSAw KSB7DQo+ICsJCWlmICh4ZW5fcHZfZG9tYWluKCkpIHsNCj4gKwkJCWlmICh4ZW5fcmVsZWFz ZWRfcGFnZXMgPj0geGVuX3N0YXJ0X2luZm8tPm5yX3BhZ2VzKQ0KPiArCQkJCWdvdG8gdW5k ZXJmbG93Ow0KPiArCQkJY3VycmVudF9wYWdlcyA9IG1pbih4ZW5fc3RhcnRfaW5mby0+bnJf cGFnZXMgLQ0KPiArCQkJICAgICAgICAgICAgICAgICAgICB4ZW5fcmVsZWFzZWRfcGFnZXMs IG1heF9wZm4pOw0KPiArCQl9IGVsc2Ugew0KPiArCQkJaWYgKHhlbl91bnBvcHVsYXRlZF9w YWdlcyA+PSBnZXRfbnVtX3BoeXNwYWdlcygpKQ0KPiArCQkJCWdvdG8gdW5kZXJmbG93Ow0K PiArCQkJY3VycmVudF9wYWdlcyA9IGdldF9udW1fcGh5c3BhZ2VzKCkgLQ0KPiArCQkJICAg ICAgICAgICAgICAgIHhlbl91bnBvcHVsYXRlZF9wYWdlczsNCj4gKwkJfQ0KPiAgIAl9DQo+ ICAgDQo+ICAgCWJhbGxvb25fc3RhdHMuY3VycmVudF9wYWdlcyA9IGN1cnJlbnRfcGFnZXM7 DQoNCg== --------------mxlF8SS0BMLPqEDxR4mHA0bY 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----- --------------mxlF8SS0BMLPqEDxR4mHA0bY-- --------------4G5xfRCGlq20KnRkzKR9kuec-- --------------Qamlj3oqA4Q6UeDj2NstIo3L 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/Ey8FAml584EFAwAAAAAACgkQsN6d1ii/Ey+u VQf8DcxU7MvP+EMKFuONGIpGphsN92z6CKiv1P1T71aWYzJhArSZdxvSZ7L+dSQrrlkJh71U0yAc tOXDn+C1wybBexE80+QYf4WPiCewa/g/+JYBFFaCjUgntO6FWwzp3xNKbkByCmBPhcLginKYINjh WiID2XjwEG+apJ6/7Eeew8IRYxHjmRmUy65gWpwQPfTViPDs5jIhnusc77wlqa4J/oB4kdOn6b36 RMFq/PZFB8g0JzlwFYbX8BaFrcEgVnR+3VjIIDVzSeFx2WqE/k6bfGyxdvJhF9N2FGoNyyqSadJV 3XpcnRTmAnHbUq4Ts4LMkJHZ5ErKV909v9b3YYDK2A== =/QoD -----END PGP SIGNATURE----- --------------Qamlj3oqA4Q6UeDj2NstIo3L-- From xen-devel-bounces@lists.xenproject.org Wed Jan 28 11:32:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 11:32:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215518.1525690 (Exim 4.92) (envelope-from ) id 1vl3mg-00031C-3q; Wed, 28 Jan 2026 11:32:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215518.1525690; Wed, 28 Jan 2026 11:32:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl3mg-000315-0y; Wed, 28 Jan 2026 11:32:30 +0000 Received: by outflank-mailman (input) for mailman id 1215518; Wed, 28 Jan 2026 11:32:29 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl3mf-00030r-Ej for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 11:32:29 +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 03b9aebf-fc3d-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 12:32:24 +0100 (CET) Received: from DS7PR03CA0214.namprd03.prod.outlook.com (2603:10b6:5:3ba::9) by PH7PR12MB5808.namprd12.prod.outlook.com (2603:10b6:510:1d4::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.8; Wed, 28 Jan 2026 11:32:18 +0000 Received: from DS2PEPF00003446.namprd04.prod.outlook.com (2603:10b6:5:3ba:cafe::e0) by DS7PR03CA0214.outlook.office365.com (2603:10b6:5:3ba::9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.7 via Frontend Transport; Wed, 28 Jan 2026 11:32:17 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by DS2PEPF00003446.mail.protection.outlook.com (10.167.17.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Wed, 28 Jan 2026 11:32:17 +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, 28 Jan 2026 05:32:15 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 03b9aebf-fc3d-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IazrqRPnNhEHjQYVXtO3ZgB20uAWJKZXyoPnFmsVQ1veUgGNBU1PHn9zFURHFyATI/sZepTat9OI8YJRBSCgZI7jR7C/aMx4kRIucGWdD8Fp2tXnooxKodob7ORcsd6k6nK8lAlrEXVB25LZZNUI5F137Fzg2eLTN1/sWu7Nlu+ZSRYdJSnK+v55wEKavOVDIaVdK6SYUpe8nsKJuSqvYUyIOBzJyDPv0xy8JYTjWlwZTLnouOWqAYIgNkrAd3aJHk7ADm5HPOpyb2PXLZkXr2QyR2PSLOcUKc+HGSV7PVqGXXMBW0/lK/aaPouBACLrgevdgtZQKAeyGFekdxYQxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XXCltb02AeNfG5VaFE9sO7ywtk99X6xghevsjpTHKOo=; b=krrMHKeSDE2xqOADr47lYhFCp+6MUh2UewH0wuhbN5F3zGowBl9zycIrYMBuHWVCnBJY/QLinLOAqBs+UqhfAYHHuqHrki322PRiOmSJAfFKme0F3HXvsriIniqe0AUrLZ37TDsq3E36zzMMfrCOTQ0NV3oY6RaVY2DyB7MvyiJjyoBnbvlF+cJHmKAc0wN00udelY/brjN5GipqVEBUm73RoROOSWkKI/ccjnmascHD9gPl2KEZp76v8C/cuKEUFVDlI+sOROhdeMCGPO8lGVjrgBjfSTzURfwukGMYOcnvq0YGhV1YyBK8VRkgQVt3zBxb4O3hddH9TUcWglbY3A== 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=XXCltb02AeNfG5VaFE9sO7ywtk99X6xghevsjpTHKOo=; b=wLbJ7mH9Bz2bR27wqtEGopBq8OUQZZ094RsiDyHNuEOcbMD8DM0QvdkduQBnGtbT7+Awbw60+4VOEvqDvb0KXEC+IOVZG/MpxCBenVelIZA1VtAk3lNpCq4kgd79kK2C2yWXpmIzIQqufcGEOPnJ1N+MlytDBCa0h5yR+GosSH8= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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, 28 Jan 2026 12:32:13 +0100 Message-ID: CC: Andrew Cooper , Anthony PERARD , Michal Orzel , "Julien Grall" , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Subject: Re: [RFC PATCH] CODING_STYLE: Establish a policy with regards to copyright notices From: Alejandro Vallejo To: Jan Beulich X-Mailer: aerc 0.20.1 References: <20260127182403.141459-1-alejandro.garciavallejo@amd.com> In-Reply-To: X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS2PEPF00003446:EE_|PH7PR12MB5808:EE_ X-MS-Office365-Filtering-Correlation-Id: a1df70dd-06de-41f6-3cf1-08de5e60e49d 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?TEoxTXVxUVJQYTIxSnplM1NBM3BmazhrQ01YYURxNGNINE5BTjRHeWV1dm5T?= =?utf-8?B?a001T0Njc0IwZGVyRXJ1bHh6b2JHbytKVnp5ZGpVNlU3L2lZVGtaZ3IyNHY3?= =?utf-8?B?TG9tMjIrekRPTkJXMS9vTWpuclZTdEJQNUswamJZa1Y4eXU5V3dNM1JwNm1H?= =?utf-8?B?amdtQUVRY1BOU3U1SUJqL3JDWk02MmpyVnBTY05sWVY4YTBldE10SS9uMW5K?= =?utf-8?B?Z3NHOS9Ec2VpdmJuTmtiNzRJZTFVN09Vd2lYSU9ma2tneVpQNGlnQ294QWww?= =?utf-8?B?Wkdvc2pnRjJRR1ZMZlozNktISERXdzdPLzBVc29ScGV0dElKeklIcGxnWmNz?= =?utf-8?B?MVErTDVnWEJPdmdIcHZjUXBhVnZnNnlKbWlhOXc2RUJjRDJHTng3K0cxdjZG?= =?utf-8?B?V2FveTVWdEdhMUxNWFJablFaM01DblB6ODd4bkxBdUNNTTd5aVNmMmh0d3Fz?= =?utf-8?B?T3BkUE1nWlhQaTBnMklVcmMzK25haDNlYzRGVDA3a0UzaWdMWHdTUHBiV3F5?= =?utf-8?B?WW5aK1BjY1lwNGlqNGdrcU1lLzJYVW1FaWlxclVmRlU3RXJTcHVKVTBIWjJy?= =?utf-8?B?MUdhb1dzSFdtVmxjK2hRRUFjaUZZcWpidGJ1YmNxSjlVZHFXb3NzemoyRGkz?= =?utf-8?B?Y2pSWHg1ZVFjQXRJdXZNcmZjdnp1TWFGSTJ6ajVvZjRUQTZHR2trelZrMVVR?= =?utf-8?B?eWx6RGd4VlRNMEFhL3crSVlBTHZUYXNHT1dNcU5PenczelA3d1pIM3pFYTJD?= =?utf-8?B?VW54VExQL0VEM0hBRWtteDdJYTJsL2xNM2RFZ2dFSXZ5eWsrVTFTTm1WSWFs?= =?utf-8?B?cjRMVWlpRnNaUkhIRGd5VnFsSlhPOHR6a2c5aU9UK2t6RWtPTmdZSTVKemJF?= =?utf-8?B?aXFGY2ovS2xhOE1iRHlLTHk1N3ZYUXRVSlhTT1JTVWJRWW0wZGFCdnlDWUV6?= =?utf-8?B?eXZjSEduUENKUjc3eTMwOGRyRDF3RytIdE5CcjE0SzMzT0hqUzA3aGFFTE1j?= =?utf-8?B?Z1NibHJEWDlwTzBTREJMV3EzbUJleDd1d0hpbXNPV1JmM3RWUVBZeDIxRy9N?= =?utf-8?B?NVRzRE84VTl4NHV3cm1XN1ZKdGlkTWRrSHZDay9Vdk5zc3R1U0FteVd2cjFx?= =?utf-8?B?VFY4eXFWUnZJOXBLQ2RQdWFvNzBnYTRtZEtkaGF2UTRrYklERW9QR01ud1RO?= =?utf-8?B?NGo5YjRyMUtCSmN6RCsvY2k0R3dqTWpWenYwbTMxZlBKRDFocEJIdzhGai9l?= =?utf-8?B?cXRrSS9Rbk80NG1tNGJJdmhoblhIM2pEQjlweExvdHVjZG9renpabGM5Zlk1?= =?utf-8?B?QUdXc3N2MWV6Z3YwaUt3ZUhnYTRGMVZUOGV1dDFrellpbWlsdktjbmF2SU9X?= =?utf-8?B?RGNwL3ZndmFvb3pqOWlDV1liYmx6VHlUaTVyYVBDSVhIa0ZEOURMdmdrdEpl?= =?utf-8?B?c0xZdmt6UHdBMlQ4MmN6RG5JY05ZV0lKVmZKTlhXM2pjZDJOUVRBL082VTJ4?= =?utf-8?B?YjZISXRUdzQ2ME9CNlU1WDFDc2ZsK0R1K1hnNjhMbENMSitDZi9SZVUwTTJj?= =?utf-8?B?SW15SWhuZ3drOFZzaStxRlJxU3lpbmdGaEs0Rm5OTnlWZ2VVSTJCVjkyOEtj?= =?utf-8?B?SFpUMHFGa1l6THQyY2pwQnR2WjhiOWgwTmdnNVpWa21YZ0lBanZkZGc2Y3BL?= =?utf-8?B?cC9yY0RKSFRybUorMnJXRFRGbUEyeWJ0K095RDgyZmpVbVB0Y0RXZi9lMTNi?= =?utf-8?B?ZGJxWG9hd0E4dURwVWF6eUJncjZoeGcreVp2Q3FSeEFyak1wd210SHh3c3Zx?= =?utf-8?B?T0x0eGVyNDlHQkp1ZHFlM0p4cnh1YXBhRERPRnlXUU5vTGJIaHRsVnRZeHAz?= =?utf-8?B?Q1gzblBtVC9uRWlidE1ERWFyUksvdWl3UzhFbFZNdlA1MitxQU96REZpMEpC?= =?utf-8?B?Qis2VGhEdUZkd2hUVmlGYk9keGxvbisyTUw2S3hWOElsYTRRWFNWWGFYNHVT?= =?utf-8?B?aDRaWkhWY2MzZWNtclNKOThMUEZHSWZkMTgxNWtyODdZamF1ZzBjdGxsRnJD?= =?utf-8?B?VlZOVDRBL05PNktmVFkzcGdwdlNVWVE0UE5jcEFRV0ZtblEvUGlEdGtYYThw?= =?utf-8?B?d2E3ZTkzY0x0dHlJUzc0M1RZbFYya3JhUTV5VUREZDcxUzlWM1hjb21jRlV0?= =?utf-8?B?LzZIQ21FK01ITEpxRGd6ZVBDZ1gyQUJrT0JZb1Q4VGUyR3BOSFRscGtWTEVE?= =?utf-8?B?YVRId2tBLzFBYzlrTXRuTUkwNmxRPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(376014)(36860700013);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 11:32:17.8042 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a1df70dd-06de-41f6-3cf1-08de5e60e49d X-MS-Exchange-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: DS2PEPF00003446.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5808 On Wed Jan 28, 2026 at 11:45 AM CET, Jan Beulich wrote: > On 28.01.2026 10:09, Alejandro Vallejo wrote: >> The refinement also applies to the second bullet point, so I can add it = as a >> separate paragraph stating existing notices are to never be modified and= only >> removed with the express consent of the current holder(s). > > That's interesting, as it may be getting increasingly difficult in practi= ce. > Often you can't get hold of the holder(s), to the degree that - as we're = all > growing older - at some point they may not be there at all anymore. Yet i= f > not having such notices is going to be a goal of the project, retaining s= ome > indefinitely can't be the intention either. Sorry, I missed this part. Many things are unavoidable non-intentions, I'm afraid. A file might have a notice indefinitely, but that doesn't mean the = project _must_ keep that file indefinitely. I'd definitely prefer to drop them all. Alas, I don't feel confident enough= you (nor anyone) can legally commit such changes without the holders' approval. Unless we were to base the rationale on "the notice is already in git histo= ry" or some such. At that point it becomes mandatory to ship the full git tree = as part of a release, which is incompatible with tarball releases. This might affect downstreams more than upstream, but it's a consideration nonetheless= . It is true that having some already in, with new ones severely restricted creates asymmetry with prior contributions, but I argue this asymmetry alre= ady exists with banners present for some original contributors, when folks (e.g= : you) have been heavily modifying those files for well over 10y and not adde= d their name. And if everyone were to add their name we'd have to scroll hund= reds of lines on each file before seeing the first #include. TL;DR: Yes, some banners are bound to stay unless files were fully rewritte= n, if anything because their current holder(s) can refuse to have them rem= oved or not be available at all. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Wed Jan 28 11:36:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 11:36:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215529.1525701 (Exim 4.92) (envelope-from ) id 1vl3q3-0003d0-IV; Wed, 28 Jan 2026 11:35:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215529.1525701; Wed, 28 Jan 2026 11: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 1vl3q3-0003ct-Ft; Wed, 28 Jan 2026 11:35:59 +0000 Received: by outflank-mailman (input) for mailman id 1215529; Wed, 28 Jan 2026 11: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 1vl3q2-0003ch-F6 for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 11:35:58 +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 826cd964-fc3d-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 12:35:56 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-4806f80cac9so3151595e9.1 for ; Wed, 28 Jan 2026 03:35:56 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066be7404sm133664015e9.1.2026.01.28.03.35.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 03:35:54 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 826cd964-fc3d-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769600155; x=1770204955; 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=N8tNrxP8xRikWkij5OzIf+VcucA/6eXFBSGrNAudmoc=; b=dBtIW9RtokETdYi/0ZUDR3kgT6XD9XPacOOvVaA7Cz2WGA+1bki7M1a5s1xcwNIy53 Fvdnjq4AuHWF89myut03NMoq32jDRxkNrnnnZ8UWf8+AI5i5ibf6sOObXokT++Yf/Wwk tgLhHbDUIORElyAOAePNJNRNZGCsp6dqhGXmWdpScfAqYAgVeNQdFX7QYhryZjYyt6GA BVLa3RQ06hls0/4r9DmfqceJfmxVk+RgtacqF2mwziIkczUepmWJnIPWtqrCDQuXw/Cq +rWw96pUn5vVwWzIrsx4xtErpdSxXFAhmYVGve8DJjuxPAoltH6jZ7hvIM0QHkLv08Yu RjsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769600155; x=1770204955; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=N8tNrxP8xRikWkij5OzIf+VcucA/6eXFBSGrNAudmoc=; b=GEJLZsZvWVaTXiMpHd9hrmxw4trDoj0NQMvz5yBySepsUzTj8zsocegpSoCoJCO4l/ FyFV1vW/yyUkphNIHRahU87iEBsoPhUFKOEhM5vUymXiJZaj4RcdjABrwA2L0mu85iXw U/XejqW+qStHSHmTQpYB4fcM3GR95OydEGGsJOEvW/gFrAj+BJeTtbDzvmzAYL1CqLod wkR4baJ9m8BvFSo24ADNv1OSjNLvAs9/E+h0dO/5c6FJUOJmDO6pdamarhpJK6S3MY19 ES4HLf7w+L9h+SvxrFG3UiX+ptjKXbYqnxzVleGFWXjwQS0PrbP3PSLoeC1ou8ZgmlNG 2jrQ== X-Forwarded-Encrypted: i=1; AJvYcCX5xEOF11EZFevgt+MdEpqATLl5I5knpL+sJAnkVmRrVADNw7aiEBSXvgqYr5TdMG31Ly6QMjKOA/g=@lists.xenproject.org X-Gm-Message-State: AOJu0YzEdu9hwLiRe/v3UH7kc6FtNx6EwDjYGcViY1Ha0rJqW6sV5Pfo sIonkiXtifzinkleoBZQX9uIuBjhOLvGEG+pVEyyDkDcFmBS5+fUnNkW X-Gm-Gg: AZuq6aKDWC5AuslwPKkTFWdEp8MV5dMTnGnWGmjdyHfI8aKKzWcaqa+K0zJZghINUz1 ruQpcse0TaMZWsx1madLyobHGNdolFimpV4Ng0fLGGcqrxaJ5LOqNwVFiQ9ZKhRy+P5Gdm9+nYH jzogJM+pmZDhS9+jX7+bsfYHTxikzPg+ExwjHifOLBnV1578Z1LslfT4z+WnrfwVrWu288PYvnR SCvI/84QAwg4dImmeYf+9Ar9piwIBweARFy1MY4kplQ6Wt0vriKeRkYOKVlcHTlI1/n6mVHDX9b 2ua/drOzjGOwRmDPSUmKAh5HW35Et6yqVbA8FjhGz0AHz36Qk011RKTDI6N9c6BdXv5c4cdSFRS N5pMspGSTnKlzj4oYyGtX60vDAqbqGffrB/8VLQJx8QBifAVd6E+ZDfsan5KXMAUSWs+xv16SV/ UMCo+G3jvx+efydcggSpId4iKXHRWR1gx4WYrBML5w5XS4jLqzTdnjIBa1vR1HRzs= X-Received: by 2002:a05:600c:3b1a:b0:45d:dc85:c009 with SMTP id 5b1f17b1804b1-48069c4a171mr57248995e9.10.1769600155385; Wed, 28 Jan 2026 03:35:55 -0800 (PST) Message-ID: Date: Wed, 28 Jan 2026 12:35:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] xen/riscv: dump GPRs and CSRs on unexpected traps To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <27ab0f8eb6fd6ecef1eeefa4a05e4fe1f43acbbe.1769427484.git.oleksii.kurochko@gmail.com> <88edf7a2-c5f1-41fd-9ceb-8cc0c345b7e6@gmail.com> <132efa57-bd11-47b9-b3c8-0c09589f70b2@suse.com> <8ec02eba-3271-45ce-8157-0d444ed9da62@gmail.com> <46b4e715-3b4d-457e-885c-2c3b4d9e5165@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <46b4e715-3b4d-457e-885c-2c3b4d9e5165@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/28/26 12:27 PM, Jan Beulich wrote: > On 28.01.2026 12:22, Oleksii Kurochko wrote: >> On 1/28/26 12:08 PM, Jan Beulich wrote: >>> On 28.01.2026 12:01, Oleksii Kurochko wrote: >>>> On 1/28/26 11:34 AM, Oleksii Kurochko wrote: >>>>> On 1/27/26 10:27 AM, Jan Beulich wrote: >>>>>> On 27.01.2026 10:14, Jan Beulich wrote: >>>>>>> On 26.01.2026 12:43, Oleksii Kurochko wrote: >>>>>>>> Provide additional context when an unexpected exception occurs by >>>>>>>> dumping >>>>>>>> the relevant Supervisor, Virtual Supervisor (VS), and Hypervisor CSRs, >>>>>>>> along with the general-purpose registers associated with the trap. >>>>>>>> >>>>>>>> Dumping VS-mode CSRs in addition to host CSRs is beneficial when >>>>>>>> analysing >>>>>>>> VS-mode traps. VSCAUSE, VSEPC, VSTVAL, and related VS state are >>>>>>>> required to >>>>>>>> properly diagnose unexpected guest traps and potential hypervisor >>>>>>>> misconfiguration. >>>>>>>> For example, on an illegal-instruction exception the hardware may >>>>>>>> record >>>>>>>> the faulting instruction in VSTVAL. If VSTVAL is zero, VSEPC should >>>>>>>> always >>>>>>>> be inspected, and can be used together with objdump to identify the >>>>>>>> faulting instruction. Dumping VSCAUSE is also useful when the guest >>>>>>>> does >>>>>>>> not report it, or when the hypervisor redirects a trap to the guest >>>>>>>> using >>>>>>>> VSCAUSE, VSTATUS, and VSTVEC, allowing verification that a >>>>>>>> subsequent trap >>>>>>>> is not caused by incorrect VS state. >>>>>>>> >>>>>>>> Signed-off-by: Oleksii Kurochko >>>>>>> Acked-by: Jan Beulich >>>>>> Hmm, wait, there's another anomaly: >>>>>> >>>>>>> I still have a question though, which can be addressed incrementally. >>>>>>> >>>>>>>> --- a/xen/arch/riscv/traps.c >>>>>>>> +++ b/xen/arch/riscv/traps.c >>>>>>>> @@ -99,12 +99,70 @@ static const char *decode_cause(unsigned long >>>>>>>> cause) >>>>>>>>       return decode_trap_cause(cause); >>>>>>>>   } >>>>>>>>   +static void dump_general_regs(const struct cpu_user_regs *regs) >>>>>>>> +{ >>>>>>>> +#define X(regs, name, delim) \ >>>>>>>> +    printk("%-4s: %016lx" delim, #name, (regs)->name) >>>>>>>> + >>>>>>>> +    X(regs, ra, " "); X(regs, sp, "\n"); >>>>>>>> +    X(regs, gp, " "); X(regs, tp, "\n"); >>>>>>>> +    X(regs, t0, " "); X(regs, t1, "\n"); >>>>>>>> +    X(regs, t2, " "); X(regs, s0, "\n"); >>>>>>>> +    X(regs, s1, " "); X(regs, a0, "\n"); >>>>>>>> +    X(regs, a1, " "); X(regs, a2, "\n"); >>>>>>>> +    X(regs, a3, " "); X(regs, a4, "\n"); >>>>>>>> +    X(regs, a5, " "); X(regs, a6, "\n"); >>>>>>>> +    X(regs, a7, " "); X(regs, s2, "\n"); >>>>>>>> +    X(regs, s3, " "); X(regs, s4, "\n"); >>>>>>>> +    X(regs, s5, " "); X(regs, s6, "\n"); >>>>>>>> +    X(regs, s7, " "); X(regs, s8, "\n"); >>>>>>>> +    X(regs, s9, " "); X(regs, s10, "\n"); >>>>>>>> +    X(regs, s11, " "); X(regs, t3, "\n"); >>>>>>>> +    X(regs, t4, " "); X(regs, t5, "\n"); >>>>>>>> +    X(regs, t6, " "); X(regs, sepc, "\n"); >>>>>>> Does this sepc value differ from ... >>>>>>> >>>>>>>> +static void dump_csrs(unsigned long cause) >>>>>> What is this function parameter for? >>>>>> >>>>>>>> +{ >>>>>>>> +#define X(name, csr, fmt, ...) \ >>>>>>>> +    v = csr_read(csr); \ >>>>>>>> +    printk("%-10s: %016lx" fmt, #name, v, ##__VA_ARGS__) >>>>>>>> + >>>>>>>> +    unsigned long v; >>>>>>>> + >>>>>>>> +    X(htval, CSR_HTVAL, " ");  X(htinst, CSR_HTINST, "\n"); >>>>>>>> +    X(hedeleg, CSR_HEDELEG, " "); X(hideleg, CSR_HIDELEG, "\n"); >>>>>>>> +    X(hstatus, CSR_HSTATUS, " [%s%s%s%s%s%s ]\n", >>>>>>>> +      (v & HSTATUS_VTSR) ? " VTSR" : "", >>>>>>>> +      (v & HSTATUS_VTVM) ? " VTVM" : "", >>>>>>>> +      (v & HSTATUS_HU)   ? " HU"   : "", >>>>>>>> +      (v & HSTATUS_SPVP) ? " SPVP" : "", >>>>>>>> +      (v & HSTATUS_SPV)  ? " SPV"  : "", >>>>>>>> +      (v & HSTATUS_GVA)  ? " GVA"  : ""); >>>>>>>> +    X(hgatp, CSR_HGATP, "\n"); >>>>>>>> +    X(hstateen0, CSR_HSTATEEN0, "\n"); >>>>>>>> +    X(stvec, CSR_STVEC, " "); X(vstvec, CSR_VSTVEC, "\n"); >>>>>>>> +    X(sepc, CSR_SEPC, " "); X(vsepc, CSR_VSEPC, "\n"); >>>>>>> ... the one logged here? Nothing changes the register between entry >>>>>>> into the hypervisor and coming here? >>>>>> Down below here you have >>>>>> >>>>>>      X(scause, CSR_SCAUSE, " [%s]\n", decode_cause(v)); >>>>>> >>>>>> which actually (largely) duplicates what do_unexpected_trap() has >>>>>> already >>>>>> logged. >>>>> Missed that, then it would be better to remove this duplication and leave >>>>> only printing of CSR_SCAUSE in dump_csrs(). >>>>> >>>>>>   If dump_csrs() gained other uses, the dumping of scause likely is >>>>>> wanted, but then likely no scause value would be available to pass >>>>>> in? So >>>>>> maybe its dumping actually wants to be conditional (and the parameter >>>>>> wants to be a boolean)? >>>>> Good point. Honestly speaking, I don't know if it will be any other >>>>> usages >>>>> except this one. But to keep things generic I think it is good idea to >>>>> add conditional dumping of scause. >>>> As an alternative, we could simply remove the dump_csrs() argument and always >>>> print SCAUSE. When running in hypervisor mode, SCAUSE should contain the reason >>>> for the trap. Even it is lets say just hypercall and not something faulty, it >>>> will contain "Environment call from S-mode" what looks okay to be printed. >>>> >>>> I tend to prefer this approach slightly. What do you think? >>> It means that it'll be logged twice for an unexpected trap. As said, I can >>> only recommend to limit the volume of the output in such situations, as >>> sometimes all people may be able to get you is screenshots. >> It will be logged once, basically, mu suggestion is: >> >> -static void dump_csrs(unsigned long cause) >> +static void dump_csrs(void) >> { >> #define X(name, csr, fmt, ...) \ >> v = csr_read(csr); \ >> @@ -156,11 +156,7 @@ static void dump_csrs(unsigned long cause) >> >> static void do_unexpected_trap(const struct cpu_user_regs *regs) >> { >> - unsigned long cause = csr_read(CSR_SCAUSE); >> - >> - printk("Unhandled exception: %s\n", decode_cause(cause)); >> - >> - dump_csrs(cause); >> + dump_csrs(); >> dump_general_regs(regs); > And the fact that it was an unhandled exception then isn't logged explicitly > anymore? Perhaps dump_csrs() then should have a const char * parameter, which > here you would pass "Unhandled exception" for. Yes, it will be lost, I thought it would be enough to see SCAUSE, but agree it would a little bit more convenient to have message: "Unhandled exception". ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Jan 28 11:54:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 11:54:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215547.1525712 (Exim 4.92) (envelope-from ) id 1vl488-0006vN-3i; Wed, 28 Jan 2026 11:54:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215547.1525712; Wed, 28 Jan 2026 11:54: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 1vl487-0006vG-W8; Wed, 28 Jan 2026 11:54:39 +0000 Received: by outflank-mailman (input) for mailman id 1215547; Wed, 28 Jan 2026 11:54: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 1vl486-0006ul-Li for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 11:54:38 +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 1bb0951e-fc40-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 12:54:33 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by BL1PR03MB6007.namprd03.prod.outlook.com (2603:10b6:208:31a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Wed, 28 Jan 2026 11:54:29 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.006; Wed, 28 Jan 2026 11: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: 1bb0951e-fc40-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=cZPWpCRtaX/EfAGKbPWZmCNsU2vhh6oyVHiFe333nNBAXO/ae0udbJji7fXyYmHORkuQexTu82G70Z08xEvCUGrb3yFlSph2aR/ymT5dYt9i88a2OwB0KQPfa0nQdT39gioCPUUZP4OJErN1N413VN10Cfc/EdsgYonhvIxU9JYjJST1PIbehxp14iT4d709tZODDFNfexYvx3aUJdWtFuh6gbgGsNMjEeDUxerDpiRqgQMfv42iTaozla++Ihzdl91cOyYFuTfb2DFQBfIKCLTFd3AxJ1r6jDRHi021xQRDcX60xDfyY9P2ZnYPO3ULDuP0fyoUeoUWoJ51/AU+7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=g34bGOa3m840N64Ln1MeYtZ3Vit5X0stVySF50CdSH4=; b=POvTSOukIPyU1QqxwvfCckvzmqhF8sb5dWHGLgZiT1MughdWqv0mt5OQyRZu7Jiki+MYb2A/8B1uBNLKLSa0Y5ioxpPi0DCpoI8DKbLSaDDHqdctR3J/Pk9UcPXcQildEjATr+iT8YMP9xEInSAOHIkXqmLS8f3gSF1Rfa7IX/VbWEZTL5OrC6ViDm3CfseufCnk4EEvXbuyPZau8u+G0VL//Z7pjvswhMeePWEjjf8/UTEBaEA1fDaN9JjopxTyfTmj4zQQpp3rYppaBf01yWpvXLqTQdp5KDe0I+jzes9PasCvr25NsLpfHBx4HVcjhP3GmN2sCuMWwdE5gtci9w== 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=g34bGOa3m840N64Ln1MeYtZ3Vit5X0stVySF50CdSH4=; b=xFxTm3ubqPyyzI6bU/dby9IozstYParbvRfUQZgIAKaj8WKSigGTksIRn/TsFFLO5rLStKmSdwwo0nnShUl8sxn8O/vDfmHeK6eOWql04IcuvPDNVd5+IMN3e/gTUJTVwqLGpsCXoZMN0Nr5cE5x8pUOGcUyLqIl00YnXQpARHQ= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 28 Jan 2026 12:54:25 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, Stefano Stabellini , Oleksandr Tyshchenko Subject: Re: [PATCH 2/2] xen/balloon: improve accuracy of initial balloon target for dom0 Message-ID: References: <20260128110510.46425-1-roger.pau@citrix.com> <20260128110510.46425-3-roger.pau@citrix.com> <596b08db-dc0e-4d42-ac17-570ca6e06bca@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <596b08db-dc0e-4d42-ac17-570ca6e06bca@suse.com> X-ClientProxiedBy: MR1P264CA0013.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:2e::18) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|BL1PR03MB6007:EE_ X-MS-Office365-Filtering-Correlation-Id: a07e9891-d182-42a4-1d1f-08de5e63fe57 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?VTRmU2NXZjUwc0V3NzRpa291VTF0ZmFhVTJTMUQ1QkxrTGk5Smk0SldEVkJ2?= =?utf-8?B?ekF5R1cvWTIwemdwSm9aTlUyajYrQ3RUZVZsOHdaYkRDL3FTdko5V3FQRGdO?= =?utf-8?B?QTlTSHNRRGVoL3pIT2dPKzhjeGFCVUU1MjB5L2N5bno1ZlVxSEFrSS9wMUsr?= =?utf-8?B?QVYvYm9EWkM2WTAwMDArNWdnajJrODl5cm5Mb2p0azI1bVVnTmVTNmxxRWdQ?= =?utf-8?B?QisxNCt5RTZYU0VuSFpXWFZHcUJFdlljTjFsNzREa0JBNnp6S3hLVWVDVVVs?= =?utf-8?B?OU9vUTBRY2s2Q3hCQTlvY1lhT1RJM0VmN3NLeUZnM1RNMTlYNHcxclhQRXhx?= =?utf-8?B?VFllaGt3ME8wQzZtR2Y0OFBFSHVoQVFCV0xsUkxBRCs0SjNoVnBtMmlHdTJF?= =?utf-8?B?RXgrS0V1ZW5iSzZSSmtqNjBsbENudHN4eEFMRHlzNzlkUjFuMDNSNDJiclN2?= =?utf-8?B?YVNIOEV5eklrTXFUdEltbi9zcWZSZ3R4bWx0QU1EU0lMVjFMMnZmblZhOUpv?= =?utf-8?B?bjE5R3Fwa3JHdWRzY1BaSnFrNTUwbXQ0NW0vQm1ic0JCV3FWSnF4R1dHOS9T?= =?utf-8?B?RTFvREpEYi9zWm1DV2svdW42eUFMdisxeG5ycUgybjIrdEdEbm1waUxneXNJ?= =?utf-8?B?Nkg5SjBjQUZVR2hETE90TmtPbGtRU3JnR0VRbUFZLy9MTlpWMDJYMk1hKzRr?= =?utf-8?B?bXFtODBiaFhCUEhkWXkrUU96UVBaZk1Wc2FucURPMVpTSnl2VG1aRk1LTDJv?= =?utf-8?B?aHQ1cHcxUThvZHhQdDNmZmlSYjNpekxreHgvVlZXaDJXNnFaeW5pc2w0Um01?= =?utf-8?B?ait0WWVNVThNTjdQTHV0V3ZJNU43ekxReThtZ0lwbDRjQllYbXVoWXlKaERj?= =?utf-8?B?SVlVQ3hMazRISmFnL2dnMWVpbi9MVU1ncU13TlJCancyOVB2SFZLbXQ2b05T?= =?utf-8?B?amJBVkExUjRQdjNQMXJkUHIyVEo3cThHRXZlUXJQRG1tcFZXclBlbC81TkNY?= =?utf-8?B?M2xjUTdMVmxSR3laT3hRUjMxWEhzVllmTy9aRWpFTkQya2M2ZTVWS3oxVU1y?= =?utf-8?B?KzV2OHE0N3FHS2s1NFJnMldYdU9RZG5aYm9IYitTYkhjU0VRUDBKZFNVU3Av?= =?utf-8?B?YTdxZGE0RmFQZmdsMk9wbGJhdzl4YnF0MDE2ZGsyMjlPdG9scjVHRXB6TXJQ?= =?utf-8?B?TFZady94ZFpWQ1J4SExvV3VYV2Z4VGtCb01vV2FYN282QXVRcTZodnJ1MjZM?= =?utf-8?B?Yy9uMjI3TFh5U1lQN0hIVGJGZEMzZHZNQ3ZhTFMvQUNOT1JXSThlS1luLzhn?= =?utf-8?B?Z2g4VTdKY3krZG1uQ3BUUFpienMyTTg5cFVHdmVocTVsckJVS2ZJeENtSWF6?= =?utf-8?B?NG9nZmFUR1dXcUtIM3UzdUdtR0N1SmxpNHB3dHM5T2FMMW90TzNxdWJHMlgy?= =?utf-8?B?SUdDY0E5cGVrNjdVbm9Ga0E3ZzNvTk1zQVl3V1BxaWpkMlc2blNKMXpQUGI3?= =?utf-8?B?YzlrVm9QNFNVdC9maXFlVzNoc2hqclhxeTIrK05jU211Q1JSbEZ3d2FaNVlQ?= =?utf-8?B?TUVjczRkNWFKTnZITENEaTBzSTB5Z1hMWXVYT1ZTb1hSZnB6L1VtemN3WGxC?= =?utf-8?B?QW1UdXhIN1RYT3RGMmFPdEhPc1RBMGJHVXZCaDlEOG5hYnI2Nk5lV0tkWS9C?= =?utf-8?B?UW54YWJLZ0pJSEFqaCtrd1dnT3psR3pxMDM4N1hYVm1aakNwVlpPdk9NaWtj?= =?utf-8?B?UjVZVVZDdTVnejJYZXNNYnQ3SGVGM3dYcGJ1Uk1wQ25UQW01YU5xbUo2RG9z?= =?utf-8?B?dExWMGxGZHFRbm1KVE9zS05FVnR3d2VzcldqbEViQS9GcFFBaDljZzZ3ekF1?= =?utf-8?B?MnM4TFYzWVB2VHpNMTVWT0orY0RBTEdqYlp4djIvcVNkc2tGYitTYWlFK2FK?= =?utf-8?B?bkZsd2lNNmZxd0VnSFVia00yTHlLK3hYWUY2WHhBTG15Umw2M1ErMWo5Qm5z?= =?utf-8?B?ajdKeEc5NlFDMmlMRzl5eTI0eUVzc2FqdDFVUVN0L1NYNHVDUmNZdnljeVgx?= =?utf-8?B?VFFsNVJYUDdBWkV5djdJUnhwbDl5Y2l1RHByMHZtZmd0a2drRUV6WE40Z1BP?= =?utf-8?Q?MzDc=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VTFxZFpGUSt5bG1UQlNSaGtBQUEyTHpWZ01OYjJwT0FIdzM0MnQzNkoxSlZH?= =?utf-8?B?bnM1ZFovOFpCQlN0NEx5M2cvK0FuSnpibEZvVnpVNEpDdFhuMFdjUW5iSXc0?= =?utf-8?B?UkFtTXdPaUY1QzhPdkpoM1FVK2RoOGlxM3pMcHF3WnVLUnN3UWNTZ3ZSK3dD?= =?utf-8?B?Q2Nrc2Vza1NURktkbnBMRllDS0RwV2dpZnhVQU4zbWJ5eERacmp2dlJ1Mm4z?= =?utf-8?B?UmlVOEdRUDZid1lEbjBSL0wrOUpNQi8wTGpKbjhEM2syUHRWZkswckYzcU9G?= =?utf-8?B?WUFOb3lkRWMrUzRHMUIvYWFkZHY2ZFBmZWRPaUFucnNqZEhKM1l4ME44Ym5R?= =?utf-8?B?VjlxbDF1NUVwaERwT1YxZzdXNVprY3BuaUtuVWV3SUE1SmRWTW1udnZqK1JS?= =?utf-8?B?RjNST3N0bGhiczI1cDRxYitESE1XNmM5QmdzRk9jdVM2ZjczcjdmK3BjUlFz?= =?utf-8?B?WFZsVFhVM1dEdjRWVjBVMGpOVU03TGRKTGZFNEROanZIWG1ESUhpcE5yQjkz?= =?utf-8?B?N2NYSmxnN0ZFZmE4S3dIYklTVXZuL1dtUlZKdVBudE5ESnl1SmRrbWFMZVcy?= =?utf-8?B?dysvaWxEUmZBVHFKOVptQ0huTWc5a2t5b0I2MWI3NGgxNDNpREpqNnFKRGds?= =?utf-8?B?L2ZkdkpZMFZpZCtxUVhubS9HOGlpbVlHRERvT3AwbFoydXBJRGFob0dGQlkx?= =?utf-8?B?UUZ6RVJBYitjNkU0MVB2bFhIejlZR3M1bkFlUS9uQTlrTlp1R01NaGc3dzVl?= =?utf-8?B?cmZ6L0gzbzEwTkdNbkZXdHkrRzVYb0paUFhaVDlCakRqSUJHZGJHUllaTGI5?= =?utf-8?B?aGtpOEplRXhKTExGVkRxZi80cTM0RWJXdVdLY2lpdGo5a3o5R1gzRG5nc1Q1?= =?utf-8?B?Vk51aEMzZHhlakFRUUpVMkFDdFJlTmI3QUhobm9FU2V3bzMvb2xkampPVEZ6?= =?utf-8?B?VHhOSW41TTJKYlpPQi9KN3hDZzB5anQ5ZGJ2cGliSVRDZ2xZcFFqR2VGMisv?= =?utf-8?B?UzhMNzFhN3R4cFhZMWdwK2VLK3R6WXY0SzhrRXg4TU95d0l1cElHbDlFdzh1?= =?utf-8?B?Mnhpc0k0Z1BEbmtQd3ZqWWVXc3Z5bnIwOWxaRHJIMW41NTYrWE9kQ1gzVGo1?= =?utf-8?B?VFRKalBWUmdCNm1rbEJxNnBiN1ZsNUxCanNXU2wvTEYvUzZGakpEZTRsZm9v?= =?utf-8?B?bnN0WFI2bmIrUEkya3E5Kzk2b1dkd1A2WStzcXpCeTgzNnVhMUFrT01PWEdN?= =?utf-8?B?emhpYVF5YWxjTnd6N2xubUE1ekN2M0lpdDhYdEJ6OVZxRCsyTjc1NEpzemkz?= =?utf-8?B?bWRKbzJ6S0lieWVSamExWEptdi9MTkJwQkhBLytORTZzYkhiYzJjR2tPMVZJ?= =?utf-8?B?ZmxBUEl0RHM5dkdaeTZ6OWRBTzBhclJUNjRiMDdlRUxoL2NSeVBsR2E2Z2tX?= =?utf-8?B?aW94OEI2c0JJSHhub1d2ekdoZXk4NFBMWXJ3d2ExU2JyckFpZXRlN1RQakEz?= =?utf-8?B?UlpSMnlDQVJJYmhwTEVHOHh6d2VCbWx6Q1M4MW5mWEI5QW96MDJzbDRNOCtU?= =?utf-8?B?NWNualQ4K3I0ZE5DYUo3OVJ5cGNWck9XYnlzK0tBNjNkOEhKMU9DTnR1VGh2?= =?utf-8?B?d3lTRVo0TzQxUFp4c2FVcGpVSWpBTVNpQ2FFSkQ5dkJUQzdUYWJSMG1tM3RE?= =?utf-8?B?cFRoNU5ESkxtTWsyMVJNY010cTRRRGhrdno1WkJiSWlqTHY2aWZlL05BckFo?= =?utf-8?B?MHBwMjJ2dkFBYm4xQzBSY1hpWmRTdWVKUnNzSlV6NzZyZ1R5WTZmTXZ0WThM?= =?utf-8?B?bTdBMmpzYUZPKzZJMzd3MDhhWFJKdkZyTUJPWW54U2lDOUE4QVUvd2sxSjZ1?= =?utf-8?B?OTlKZDZQYmpOZktIUC9haG8vZTBhclo0N1d3c0JVazNzSk45Q0NHS3FpMUVJ?= =?utf-8?B?TWl1bDBjL29sOHFxaGpOQ1B2dnBWenByTkNvS1hCSGF6Y1ppeXVaOWQyaHF4?= =?utf-8?B?a3lFYTM1SkRLRHF0cDMyL1hEYlFPVDEzQlFkUnplMkVhRFE2bktRZWNKTmpC?= =?utf-8?B?aDFMZVRQTjZnVUpzZWJQK0lIcldmdGM3NlVtSktYVUUrTGxWd3pWOTRMK1M3?= =?utf-8?B?T3kwT0FvQ0tWdHpxZGp1elBZUzA2UDc2aEYzZzVsOHRjNGhvVXhXQklBaXA0?= =?utf-8?B?SXowR05ZU2cwYmliR2Q4V01nVDBIZzd0UzNabjNFci9vdTh6aUREaktGcnZo?= =?utf-8?B?THJFZkVmRDZWZnRtYWZXeGNyL1RvZE5BeGs2Mk5qVEZCdGtSdHE2U2F3T1Fa?= =?utf-8?B?SkNUeW5BbUhacUtEUkg2WWdnZEp1SnZOZW1KdzFKUTFOb1lzTW9kdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a07e9891-d182-42a4-1d1f-08de5e63fe57 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 11:54:29.7056 (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: QcAEecQKEIVSKPXgc78jCQbT81q0zaBY7eKkL6ph1jm045+/4nrd94uBq8o204mv4YpFIXk6GvrARXSYAbRWnw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR03MB6007 On Wed, Jan 28, 2026 at 12:31:13PM +0100, Jürgen Groß wrote: > On 28.01.26 12:05, Roger Pau Monne wrote: > > The dom0 balloon target set by the toolstack is the value returned by > > XENMEM_current_reservation. Do the same in the kernel balloon driver and > > set the current allocation to the value returned by > > XENMEM_current_reservation. On my test system this causes the kernel > > balloon driver target to exactly match the value set by the toolstack in > > xenstore. > > > > Note this approach can be used by both PV and PVH dom0s, as the toolstack > > always uses XENMEM_current_reservation to set the initial target regardless > > of the dom0 type. > > > > Signed-off-by: Roger Pau Monné > > --- > > drivers/xen/balloon.c | 27 +++++++++++++++++---------- > > 1 file changed, 17 insertions(+), 10 deletions(-) > > > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c > > index 8c44a25a7d2b..9b6531eb28b6 100644 > > --- a/drivers/xen/balloon.c > > +++ b/drivers/xen/balloon.c > > @@ -724,7 +724,8 @@ static int __init balloon_add_regions(void) > > static int __init balloon_init(void) > > { > > struct task_struct *task; > > - unsigned long current_pages; > > + long current_pages = 0; > > + domid_t domid = DOMID_SELF; > > int rc; > > if (!xen_domain()) > > @@ -732,15 +733,21 @@ static int __init balloon_init(void) > > pr_info("Initialising balloon driver\n"); > > - if (xen_pv_domain()) { > > - if (xen_released_pages >= xen_start_info->nr_pages) > > - goto underflow; > > - current_pages = min(xen_start_info->nr_pages - > > - xen_released_pages, max_pfn); > > - } else { > > - if (xen_unpopulated_pages >= get_num_physpages()) > > - goto underflow; > > - current_pages = get_num_physpages() - xen_unpopulated_pages; > > + if (xen_initial_domain()) > > + current_pages = HYPERVISOR_memory_op(XENMEM_current_reservation, > > + &domid); > > Is there any specific reason why this should be limited to dom0? > > I _think_ this should work for other domains, too. Sadly it doesn't, I've already tested. The value returned by XENMEM_current_reservation on PV guests is slightly different than what's in xen_start_info->nr_pages, which exactly what the toolstack writes in xenstore. I assume there's some other stuff that's accounted for in d->tot_pages, but don't really know what I'm afraid. And in the HVM/PVH case using XENMEM_current_reservation for domUs would also take into account the Video memory, which skews the target. This is the best I could do I'm afraid, at the expense of having so many different way to fetch the information. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 28 12:03:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 12:03:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215574.1525731 (Exim 4.92) (envelope-from ) id 1vl4H3-0000jn-Cq; Wed, 28 Jan 2026 12:03:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215574.1525731; Wed, 28 Jan 2026 12:03:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl4H3-0000jg-9o; Wed, 28 Jan 2026 12:03:53 +0000 Received: by outflank-mailman (input) for mailman id 1215574; Wed, 28 Jan 2026 12:03: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 1vl4H2-0000VQ-MW for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 12:03:52 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 690e71cc-fc41-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 13:03:52 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by LV3PR03MB7357.namprd03.prod.outlook.com (2603:10b6:408:195::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Wed, 28 Jan 2026 12:03:48 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.006; Wed, 28 Jan 2026 12:03: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: 690e71cc-fc41-11f0-b160-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=weSqEPKlzUVex2kMgRj3aGweRzcmUB1WaXAH2SdpR4iqro8Ih7SSz26YGj0IsmDD1kmbwem/2BqYMZELwONNz2Bk5w0x365ymynsyMwg8cOO4/OAhT7WIqXiKvGMjtmuQ9sokJ0dQhLQRqz6qOEHlS20ulo81sNVv2U4yhKkU3J6Z04vYyl9hEm29j+zq4XLCXry9mGZJ+2NMk9wohKXftGTewYdPrSb0P5m6Pin3MmeapQuC2AHIvMqwyxjvzbqH4vOv/Rtn9pNWVV4F8XH7G7QG3wxCUJRTjkiDVcczkafWUxWm1sGDeS5Z3rQ371XPftnxaLopYpqfKNF+4mXJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DGFKVF0i2wWigbiwR7BNTdhzq53D/kNouGUmcPEvNic=; b=uDmppB3y6Pb5eqg77P7eYtO72Q4sTTs0Mwc93CD3I85Q/YNzSlwoEj+JfJeSbTPqTyGRqHujqOeF/oEe4zY4HAN1aN9EZHh77sjgVlr3++zJ6KIxTIqFabaEO+Koze2FwHKfBvONgVHG21I/1VLHg3beOoE3AA3VhGsKu/U9S91sYZaTUetqec6+i1YPsS9YuM/7pyaP4yWoK5JUnZ7uGzVKM0DUXEVay4FZYhsMFLfzWD4vkJ22vZHCOw8YD/cRLRtb69sLk160OM27FGIrYk1GG3dhz6DUTauNrLwByOioohmuxNmogwIaOPGcKEA64ikmlSfZqAfLNxD+fjpslA== 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=DGFKVF0i2wWigbiwR7BNTdhzq53D/kNouGUmcPEvNic=; b=OpBCIn1htQkOWlM2gHkr6c09DS+/XvIF2QMRr6Vj1OY5gfKav8NhyL7z9C6LM1tLFWixK//xmkZC4oWAferJeFeSTkEEzXkLGyH0Pb9pKkRxh2nE99gWC0GrhS1SMvXed1X72Pg4m37LWouT11QS8HRGi9PSgnms7SFF08xzW2c= 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 , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v4 1/3] xen/mm: enforce SCRUB_DEBUG checks for MEMF_no_scrub allocations Date: Wed, 28 Jan 2026 13:03:37 +0100 Message-ID: <20260128120339.47373-2-roger.pau@citrix.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260128120339.47373-1-roger.pau@citrix.com> References: <20260128120339.47373-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MR2P264CA0182.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501::21) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|LV3PR03MB7357:EE_ X-MS-Office365-Filtering-Correlation-Id: 588aec5d-2056-440e-b27e-08de5e654b0e 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?bnYwc2pEOUlJMXVObVJFRWRmSXdXOGhra2NwOWpGamxMTXVkOUdyck5JTExz?= =?utf-8?B?cWxsSzZRQ0ZYUE9adDRaZTZETG9lazZPTkdaVE1HVnFXRndqRUtlMDBteFFZ?= =?utf-8?B?WTRibDFGT05nMEdEak1LWVNGaDBlZzJKRkZjamVuVis4OWl4WFZoYnRybzd4?= =?utf-8?B?Z3NZVnNaY0h2ZkVWbklTK0ZnQ1dMNUsyUk53T3c2S2xFRHA2bUxsV04zMVZ2?= =?utf-8?B?WEJUa1lBV3JZR25LazZTS0VYdWxJRjN5L3hGOS9LODJTUHE5QmwzcldSQ3lR?= =?utf-8?B?ZGg2cEl6bVdHNi9wSGk5MlNvU2tkbzdDZWM0OTArdHQxMFhLNnp3andRR0xR?= =?utf-8?B?T0Z1OTNhWStFRm5TNzJRTFpNZ0lhbktNS2N1RGp2SXJXd2FDSW9yTktTakxt?= =?utf-8?B?M0M4Y1loc1pEZGpUUzZSNjFYNFVWL1FvUVhVaU9Pb2ZuQXdRaHlUSm42YkM4?= =?utf-8?B?ajBJelowYXp2cms3SExsSFZId3hqVDZiZStBTnlicmNvMjVqWFhMc21jbG51?= =?utf-8?B?UVFXRFMyaHhERkFZY0lyQng4cE9URm02NWw0aDhoaCszOFhjNFBxNjd6YVhm?= =?utf-8?B?NWtHUmlzSW1uRzY1OVNONjNWTzBzdmM4akFKL0dnb3VaMUpyRnNiRC80VXdE?= =?utf-8?B?TzdLaUh6bk14Mm5LMzIvc3lkZU05eHppc2tGSVN6NWI5c0g1WjBPOG16TWE1?= =?utf-8?B?djFvNDNkMXpvL1V4MWVxTXFTclplQXBEZE9VbWwxd1hoQnFna05tZTJrdWNl?= =?utf-8?B?VXRNdmpwZUZpSGtKRFJCdlVyTHhWY29aaEllY09lNlZhYUlobEpOSGE1UXlC?= =?utf-8?B?QW5SN1hFblk0bmZya2lxQm5hSEQ0WVN1SytFMU53SUlWL3p1MGRiVm9JWWtW?= =?utf-8?B?Ym9LQWdwL3pLbW1Wd1h2TDlrTzFYRElHKzE5TEJtSThVSlIyOEh6WEM2YllM?= =?utf-8?B?SlBHM2IwK3VUMTExNUZNMTk1WmZwRWx4R2dLVFRJbERscTVNK0syc3dzS1Mv?= =?utf-8?B?NWNJYkNIZXNqcGZyQm5yNHRYZitpZnpZN1o5S3hGRnlTKzNhTmYxYzVxN1pm?= =?utf-8?B?V3lNb1F3VkREUjBWWDR1ekRmQW5yYkZBRVRIMUtuYmtkZlNmeGtJaWI2Um1p?= =?utf-8?B?eElhVmdIeVFld2VyM0VVVG5CWkU3RVNXSVBKU05DYWo4K21oUGQyMkt0U01n?= =?utf-8?B?TjFNSE4yODJxc2IzNHREeWF5R0VoUXRjSS8rUzgxYW42YWQzSCtUZUtLOTFC?= =?utf-8?B?Wk5VcmFWRFVFSmVnU290djY0RmxCQlF1OTEvU3FQSDI1MlVnNnNHSCt2a0dF?= =?utf-8?B?SjRVMWxnNW4rVzJFbm9QSjEyMUVzSW5hMENHL1pLQzFDb0VTb0NPSzJvazhp?= =?utf-8?B?ZCs0QzlMV3dlamx2bXdVM1NWVkpJZ0txSHc0d1ZGQXA2UEpPSW9lZzhqemlZ?= =?utf-8?B?MVhFc2Y1MXpZbFdkTFVBLzlQU0svb21DcFR2ZGpJS0I5N3RncXJLNFN6eHV0?= =?utf-8?B?aFUrS1lsWlhUb09QZ2RadGpUa2ZWbkROdHJ2cDlHNFNBQkE3ZjBmeTlOMDFI?= =?utf-8?B?S2tsblROdkdtSG9qWmptNitrTlZhVjlWNlFyRWR4VGYrckpHNmd6T2J0UEx6?= =?utf-8?B?WTBDNThjU0UzRzB5Zm9Ud1pWUDdhK0VoclJxMXFJZEZFb1JrS3VhaGZNaTBo?= =?utf-8?B?SjM3dTF6T0V6YkJiSUliUlkvZGpJTTRMVzZsYWtiUWVZRVFjYy9COFpSNEt4?= =?utf-8?B?TjA3ZUFrRlZaWlZZQ1FndUtVaVNockNsalVWbXJFTDNmb3hQOTYxM29ONmtO?= =?utf-8?B?UVB6YlJPOW5NdFFyM0pwV1RZajZUbWpPbFAzWittUEdnT3ltQ2M5YStJd0cr?= =?utf-8?B?bTdGL0hTdWFWVHB3UVk3Wld3MCtEMGtjc2pGWjI2L1R3dGs2TnVQdFVMOHdH?= =?utf-8?B?MU85UUZYQkFvK09helJ0TEVaU1FiNDllbG03aUQ4RE1Vekp6c21XQ2cxR0dz?= =?utf-8?B?SGc4dHFSelExUitFVml2T1I5N3ZuM0Q0TCtVNWYyQ3hxNnpFM3ZCeDVwVXk1?= =?utf-8?B?MVJtUThBT3hWdDhNZGMxMDlCbmxpSU9PUDBDS3hTdktneTVXY290eGFiVU50?= =?utf-8?Q?D+2w=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QjlETmgrRUJtbGlZRVdJOVovczJ5Rng0WFBxL1RRYlB2UytLNVV2eWNYTzlB?= =?utf-8?B?K1JwWWF0OEowMDF4VFJ1OHJSRloyM1lRQitVQXpKcGxHR2JVeU5JbmZlNFJq?= =?utf-8?B?VXloejBRSjdkT2d4S1NPRUpRcG1tRDNmK0R4ZHQyTThpMk5RYjVJd1Q0OFBu?= =?utf-8?B?K1FYNmtLODdLcExEM09QcU96WUdmSTlza1Juck5mZDNsTXhMNlViMFRSckVz?= =?utf-8?B?bnc0SUhLNWlFVG5QNWY5R1hPVHMvZVFLWTJJQWNwclRqaHRIRjJqU21Tcksy?= =?utf-8?B?citMQkl3QTgvRVRXbmdqVHlsL1ZYQ3F5WTBCUnJ1TG9HM0lSaTFGZ3J6d2FG?= =?utf-8?B?bjUyRFZkQWljVE5uZG1LSE1hTFZ5bEdXdWIyTi8xdGtkUGZkYW1rOWpGV2Ni?= =?utf-8?B?bE1GRGEvam43L3FlZ1hSR0RyVklvcW9JODRZdHRsQlNqeHJrUGxzb0kxWHZo?= =?utf-8?B?Q05samVncngxalVaSWhRQ2xwRFFqazYvS0ZDcExoTjVQWlFCdjU5Z2RMMFd6?= =?utf-8?B?bTY4NlgxQ1BFclhySCtCOVdDS1crTENHbGpHZTRsb3NOQVVQeVlPQVNEYkli?= =?utf-8?B?OS92dS94MHIyRHlOQnVyMUlmY2dlWmN6dStsaWRRK2JPczV3M3lVUFk3dklO?= =?utf-8?B?REs5ZDBFRTE5WVZ1YVNGaW1zaDVSMVordy9QcjBJK1ByOFpTbDZ5WFdBcHU5?= =?utf-8?B?T1pNTjBIR1laMWlsenFsNnNJUWt6N2NGRmY2MlJYNnF5djdrbGpmc0NKREsz?= =?utf-8?B?a2hQN2pUUE9reWt5TDQ0bCs1WDNyZmU2TXl5MTdkbDBVQm1LaGZoeXUrWC9r?= =?utf-8?B?K0RCMTZVSENxMjNVVzFHby94MHBicDM4bVRleG5UVWp3M1dadHVYWEoyaW1p?= =?utf-8?B?bGltWmFIZlBTUjNkWXpBaEpUbzhuakNBWmZhNWRIVCtiaTA1Ti9HWDQ2a09N?= =?utf-8?B?aDBEVjJrU0ZJMjdqOVk3ZnlSNksvY0ZmZ3FPSlFHdWUwSDNzQzJhVDdCL2Mv?= =?utf-8?B?bllyd3VRVFlJM3lWTms3em9SVGZxdElxaEFlWXJLWlowRzdRckY1cWkrcnVQ?= =?utf-8?B?bURvalVtcFBxRjBmcGRYQlpYdEVMZHlEYTFEUEhBSzAxVGpWTERsSlYrdVBz?= =?utf-8?B?Ym0wcVVmTXI3VTdLdTdDMVpHbVFnSm5ObE56cloxTkViZTlnQjRKUWpvQmRz?= =?utf-8?B?emdiWlpYS08zdGN4aG1wLzhUZHo3aThKeGJZOFBtTGx4SjRMZmFoOXUxR0xv?= =?utf-8?B?L0xDdEFHM2xkeUk0TlhiUldyNmFxSmU2TmdVQTQweE85QnViS3A1dyt4ODM1?= =?utf-8?B?NHNCQjVsQy80R29LbDFmSkRHNXhtcU1WVEJCVmIyTGtFSG1EVHRhNnpZNzE4?= =?utf-8?B?bHBGNkNhNkY2ZS9pUlFzMjdQY0FKYS9wRDQ0UVZaWXkxTyswdnQyQUNiTW4w?= =?utf-8?B?cjJ3SWdML0E0SjRDdUZZQnhaOXFhZ2UzUGY5ZHg2RzUvaUFGWWVYbis0VmpB?= =?utf-8?B?dmJnZzVUbzdnS3VSRmlqQmVYM0h1RXB1cFZDU0xTb3J2RFNaUmkxTFpvTmpP?= =?utf-8?B?WFVhV2dKTDNuVGNMUXZGZXAvTHJacTdBdUdKck5oQUJxcWpsVjhuSmg5L1V3?= =?utf-8?B?SlFtd3NMMzB3TXNDdTN3WDJxVmRhUGx6NU5WMncwazJGcjZXUmNRb0o0RzRh?= =?utf-8?B?ZHY3QUsrazBybXVVQm5pNW5ZM2U5OHEyNFN6bzEyYUFuSFl6VDV4a2ljSXJI?= =?utf-8?B?NTdpVG1BNkhnNG9ySWxHamprK21Fc1lVOWpTMEFUU1V6bFgzb3pEWEQ2bnFk?= =?utf-8?B?dzhOUzBtQUxveXJIaHFzdjc3NEZSUW00ekkwTmlIcXFvRDg3M2crOUhISlR5?= =?utf-8?B?dmQ2cGRMYnFTZUNXZUQ1OTNRdFBHZHlIUkhQaDJNWjE5NjNwdkM2REF2dkJ6?= =?utf-8?B?T1pEdUhMOU50RWlpeDRObEtNSzUyNFhiVDNweG1zdWVYRkxqVi9uSllJMGpL?= =?utf-8?B?SVllQWNEdmR0Y1pwb0xXREhXa0FsTEZSdnc2MFVwRmhRS3k2WmVLdHhsNkIz?= =?utf-8?B?T0lUa0E4MjlrTk5CMVdzWURkdmp5MUg3QkNwWG5Xd1pjZjVBWFpkSW96TDd1?= =?utf-8?B?N1J4OWxYSVJaTEZ6dWlZSHVySmtZM1RpM2FUMnJwNnh3VDhMVzN1b1VmLzJt?= =?utf-8?B?aWNNeEJBWEsrOGluNTQvK1RpUEg4dVFTY01oSDAwZ1FoQXFqcytBQXplaTFX?= =?utf-8?B?YUVoRVZSMEU0ZDRRS3ZtbEQ0OS8zSHZCU05qUHpGSzRSQVlLTUZ0Sng5Q0Ev?= =?utf-8?B?eXBGUjc1aEtqRVVOdkMyNEliRFFHR3BQNXkwME5kaEZGNlVqZEMwdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 588aec5d-2056-440e-b27e-08de5e654b0e X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 12:03:47.8910 (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: szKkvejoB2NCDS7dB27iT1TAJRnOFO44EF+wIvwJCrzQrSYRGDo+Yv+oCT1NtkdXNgJAmJkTjovr+MNRZchNww== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7357 The logic in alloc_heap_pages() only checks for scrubbing pattern correctness when the caller doesn't pass MEMF_no_scrub in memflags. However already scrubbed pages can be checked for correctness, regardless of the caller having requested MEMF_no_scrub. Relax the checking around the check_one_page() call, to allow for calls with MEMF_no_scrub to also check the correctness of pages marked as already scrubbed when allocated. This widens the checking of scrubbing correctness, so it would also check the scrubbing correctness of MEMF_no_scrub allocations. Signed-off-by: Roger Pau Monné --- After discussing with Jan I've deliberately omitted the tag: Fixes: 0c5f2f9cefac ("mm: Make sure pages are scrubbed") The intended approach might have been to ensure the caller of alloc_heap_pages() gets properly scrubbed pages, rather than asserting the internal state of free pages is as expected. --- xen/common/page_alloc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 2efc11ce095f..de1480316f05 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -1105,8 +1105,7 @@ static struct page_info *alloc_heap_pages( spin_unlock(&heap_lock); - if ( first_dirty != INVALID_DIRTY_IDX || - (scrub_debug && !(memflags & MEMF_no_scrub)) ) + if ( first_dirty != INVALID_DIRTY_IDX || scrub_debug ) { bool cold = d && d != current->domain; @@ -1119,7 +1118,7 @@ static struct page_info *alloc_heap_pages( dirty_cnt++; } - else if ( !(memflags & MEMF_no_scrub) ) + else check_one_page(&pg[i]); } -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 28 12:03:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 12:03:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215573.1525720 (Exim 4.92) (envelope-from ) id 1vl4H0-0000Vd-6T; Wed, 28 Jan 2026 12:03:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215573.1525720; Wed, 28 Jan 2026 12:03: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 1vl4H0-0000VW-3k; Wed, 28 Jan 2026 12:03:50 +0000 Received: by outflank-mailman (input) for mailman id 1215573; Wed, 28 Jan 2026 12:03: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 1vl4Gz-0000VQ-7G for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 12:03:49 +0000 Received: from DM1PR04CU001.outbound.protection.outlook.com (mail-centralusazlp170100005.outbound.protection.outlook.com [2a01:111:f403:c111::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6688429f-fc41-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 13:03:48 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by LV3PR03MB7357.namprd03.prod.outlook.com (2603:10b6:408:195::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Wed, 28 Jan 2026 12:03:44 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.006; Wed, 28 Jan 2026 12:03: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: 6688429f-fc41-11f0-b160-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=cwfjTNw5oiEP538dN7OsG4dLxvWx7xR+UbQ4vBewMQei5PPrrCxrit526ftUIquR3tJ1D1MJnnH+E7Pd5M3WsHDxOV4sVwR4uOf+knb5yj9CK3ofOMveHAbFbFaQy8Uhc8k2DSlGwsXKeGZ65CurH4eAdGLhB2bNUlL4gX+JcKgjXcL8LbarAKK0ghV2o8mxbhopbp9D4RFjIIfrlX3q2ul9TXZ3xvcaBvECSvlSpycMp9+KzEKH5m9YlS864nLCxsMf5DNwC3+qzPYMuIvOT+wqwuX1iwaOnD3eFbgIHh98+iqpnsmT7Dc+1zl1cxoaIMeW+WfHQdpEaV2JFYr0+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=AASb60VUGh7C4L8MvrD+m88IZPP9u1JUX4R81RrzRjg=; b=g2adKCzHZuOtThy6SSvtcZEvfBFI1BO7+maitdpBG//bAI9RFsrVaA3DtBCEghw2oL1InoQ3b4NPhqk5wRzeDJc6EJJdiIFTxHsf6rHsgBPuJ6LmJX/CAGQcc0ASntRxs7C+GwWHIY3lAS+qKhaRIoD6gJnTyI9LYzWDUWwGOsUK4T6Yd78YLPbPFL71R5iyXXh3wJPKusq9GB7uiUZwKZZEWHxUrAa1ZGB4uwb5ovJa1MmQPnJt/Lz6ZOxvwGe3xIonutMmwPvIWFrOcAXiIVOkzzEGnj7A+4c/scvbpQ3vu6hMFj6C9lWYTWDhiWFbplG6fj33fgT0mqgWK8KEqw== 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=AASb60VUGh7C4L8MvrD+m88IZPP9u1JUX4R81RrzRjg=; b=L7zbdrvDZupXnTLe6gMU95E8+bAcSoOE2DKJv4IMecI4x2DMlsNwnPnLOzhldojaKb8QYPi/Q85dtgFkmDBaqEWWVjSz8wuWaQldRRTSY1tilCfjRmqTPW58M2YLFa/LHPc8gxc9BCsU52iTHuN8cyxWW6HcA9RPsL386q6JasE= 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 , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v4 0/3] xen/mm: limit in-place scrubbing Date: Wed, 28 Jan 2026 13:03:36 +0100 Message-ID: <20260128120339.47373-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: MR1P264CA0143.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:51::22) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|LV3PR03MB7357:EE_ X-MS-Office365-Filtering-Correlation-Id: be5e2de0-3952-4915-6196-08de5e6548e2 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?NXVwY0ZqRHA2M0o1MTlldVlGQ0NtalJ3K29aeEJGbllhM2pkTzYxMklpY3Nv?= =?utf-8?B?NUFaMzhMUk5zRGFkdlZCVHdvNG5vTms1N3pmRi9IZHpqdm4xZDZ2eUU0TzhT?= =?utf-8?B?bUZHSFRPU2JpZUtvRkhueTRaUFpjWklwVEg1UUxpUlljZTI3VytrMnR4ck1T?= =?utf-8?B?S0pqMmhXVUVEdi8xdnpVeE44SlZTTjhLdTBDVnYyaHdJb1VjNjN2OUxmb1pl?= =?utf-8?B?RGVrdWtOMDRBSkgreGgxUHBRYm5GcnB6ZWN3YzJxOEd3N3EyaUk3OWQ3UDN1?= =?utf-8?B?TUV0TCtKcDVuNmRpQ2xxRGVpMWpqNUF1REViM21oRGthYmI0QS9hZkk4OTBu?= =?utf-8?B?MHg2NmRiek12R213Y05ZL1k1MzlwNFNtejgrYVBralFwOU1BUDM1SDNHYWwr?= =?utf-8?B?MFpweDJxNXRONy95K1VVZlV0YWMwZ2RuWHozR2tiV0FIN3ZBK2FYNXF3MkxI?= =?utf-8?B?Q3k1ZjVweGtFZVR3bkI4OCt3M2Npd3VaVXd5VG5vb2h4dVUzeVJoQ3ZZUDRw?= =?utf-8?B?bE5zM1JtZTdHaGtIOUptNzQ4ZFhJWTJCalZEMElrdmRzVDJHQlYybm9DVzZW?= =?utf-8?B?MUg4eWc3dlhRTFpQdmh3bWJnbndDaS9rQlF2bzZzZDBPcklKa0E5MENmWDZI?= =?utf-8?B?ZnA1WkJvVEo5YXRiWEUxNTJob2JRcEt1dytNNkJ2YlR4TFJBTlNXUitvVkR6?= =?utf-8?B?b1Zya3pESzhUR3IwdUxTTE56akhsdTJqbnBMTzdsZFU3azRUWVdyV3hKZWFs?= =?utf-8?B?UTY2L3NxTFJpbm5NbmZkQ2NrSU00d3huN2xaVkd4SGlBRndpYnMvTXkxUnMv?= =?utf-8?B?bHBWZWp2bkt4d3IxY3YyNW1POTRadjhMeFRDWm1JTVZZeVpoVDU3MUNyOStk?= =?utf-8?B?bi8ydGpWMEFzMXhVUmRyUFFxK3lzSjd5R3dZUDNYajdwZXFGOHl4WXZweVMx?= =?utf-8?B?MHRYOTNQRlhibHhsOFUrV2wyNEhlZE9jL0VxL1A4RnVRTUJNTjAraUZCODF5?= =?utf-8?B?d05RQTgyNU9qQituOGJxWk9oVGExeEUzTlVUaXNKeEhjTElSQllTVmVCbXdh?= =?utf-8?B?d3N3bU5NTGtGOW9VUVVQWnlsaUloZ3BhMys4R3kvQVg5aTNsbWNMZFllcTky?= =?utf-8?B?b2lqYkloM3hDMjZLWStkdDQrQU14cmZQV0crcjZWR2xWZ0hMdTBuRkFiTmYy?= =?utf-8?B?cjMrNGY5ckhRbEE1eHd5QVVsWFBlZ1U3WTU0MlBWZXhCemVXMXkrTVhKRlEx?= =?utf-8?B?V1pRZ3ZQQW9LS1J5eFlsSThWbzVsZjQvdEpqV0hxZzFDZjJ3bytaTnRqRytq?= =?utf-8?B?TkIzYkpIbnJBb1RRM0tjQVdwYmtRdDUvUmpWM1dnREc1d2E5ZmVFU005ZXFH?= =?utf-8?B?cEJvSWR6czk1WHl3akpEQ2VydG5Gb0RwemZBN0hDRFQxZEhlK1Zra1J4a1Bu?= =?utf-8?B?MWVqS25NN3U1azI5L054RGVMTG9LcDBNQTQ5WW1GUXlqdDBrTmtNTTBkL016?= =?utf-8?B?OEdoMTJ1aEFYZ2xMampJcUFNNDJ1VWhQWkExRFU1YWwvOWduNWNndk5pblNN?= =?utf-8?B?bkthT0kzUmtHd3piekt1WGFYOTMvcUVnN0RXMkRhc1FaQTdpT1JDcmFFa29C?= =?utf-8?B?WGhDL2c5T3RLL2Q5Vm1YSmJvYnhid1lwSDZFclVOWXRHMDBDY1JraWJjNkdR?= =?utf-8?B?OXYxRWV5aXQ0Tk9LRnVIQ0xqWlNPRGMvSFl2YTVuRWhhb0lnRU8wMytLTjZv?= =?utf-8?B?ZVBGQzNZYTREWG1WQjNKVzJpbFB3b25tNVUyVUV6RFZzNGpLemVlWkh2Wm4r?= =?utf-8?B?RE9WUmU3cUNKUGcxQTJPY0svUGtRNlhBd1k4VG9QTTIvbkYyei9LNWtBdzNx?= =?utf-8?B?MVlvN3pyZzNCelg3WERzU3V3U0RPcDZNc2RMeE5jN2l1YjBjQnExY1ZZMXlj?= =?utf-8?B?UU84MWw1TWdzdUFGMmZudTljN1dGSzBQL05lM1Z1NXlMei9nRE9USUpvR2RX?= =?utf-8?B?ZG1OL1JSUnFsQ0h0amZUd3RpWXpYbFlJMXVSTmJOVU1RV3dwbGdkZVZHRmNk?= =?utf-8?B?eFVjbzRBV1dpSlk0MXhGd2RsZFJjTUU1Y08wa0plSGpZdktTV2wwVWtBc2xm?= =?utf-8?Q?M1aU=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZDlhRy9aTkdhaitXMEhDNnBQaTZrYml3Qlh6ZS9UK0p3Q3FheDQwM1hQRVhV?= =?utf-8?B?cGdlZTNQRDk4OU9CdGxNeXVsQWloQ0NpazRGa2wyL3hDS0Y3eEhBZC9BcVV4?= =?utf-8?B?MGVKaktJODdrZXlscFI5bnpmbTh4REl2TkF5bU1NcHZBbzhxbHpnUG5Obldm?= =?utf-8?B?YjJaNTgxYmI4VkJGaFg5dGJQNk9VTUdzTiticU5LUmI2MzNJNXRtNHFRVGlK?= =?utf-8?B?NGVnRGVEMG9WTEd2blo3OXVqdllNUE9lNTdRbzR3KzZHeGV5aVlpL0JlVnhW?= =?utf-8?B?QzFxVXBLVXVhcll0U21kY05NNTh3Z0t4ZkMwaXE2VVNRb3doMWhMb2hzUXNT?= =?utf-8?B?YkRLWC9YZ1FtRCtoL0h2SGV0cGlNcDdWenZZeGhhSkp4T2MvR29WMW5iRUd3?= =?utf-8?B?eFpHREZNdDZtbDE4WHlHbFoyOWpqclpGZnVpb0hYZDVOUUhZTjByU2FqdE5F?= =?utf-8?B?VE5EdWhCWXBnOFlzcDNXNW1ON0dhZXIxNkdxY1A4UHBhUlVsaGs1WG9IL1oy?= =?utf-8?B?Zk10S2hQRlJtOEVxZ24yVzZQc25NTFdYcTArQk93cE02VkFONlBqN085MUJw?= =?utf-8?B?MWdxc3luTUhUZTUrbzAvVDJzSVVLM1k3S1YxR3BmaldVUXJSNnVEWmYwdFhY?= =?utf-8?B?RUlaVlJoMklma1lXTlVWU1RxTnRQSCsxRFpoYmlpM2c4QTV2bzgyYjQvUlhS?= =?utf-8?B?YUl1b1pBdVlESnFPZFdwbmVaS0xHWUNPTEFlNGpiM2daRG96MDJFTUhSTnRv?= =?utf-8?B?b0s0OThLd1N2Y0VGK3JQcENDNW1vL0h3TUQyQnl0VHQ0ZnV4eHEvY3VoVzZm?= =?utf-8?B?UXc1YXJJVmVxNktxU29iWUMvSW8vY3VLUjVFVFRzQzlyL3B3QkQ5UXRqMEp2?= =?utf-8?B?ZFl3U205dXk2eC9rT1BqdElqRDRUcE54UHRRcjJNbkUxWTdaRFdmbHlUT01i?= =?utf-8?B?ZjVtNWF6YVhzRWZsVVo2U3BMSlVhNGRBRmtVVURoT3dkSVJMbkhwcUxZOGU2?= =?utf-8?B?TSt3K2JKMzN2MFFDTjhaSEhjNjlLWnRGMEprcWI5eXlMVHh5bHdmVDgwMGI3?= =?utf-8?B?djROTGFkS25Nd2NzTWhBU2tGNllMRWZUQTNZSE4xN0hFM2xmQ0U3TEJ6TGJB?= =?utf-8?B?REFpclA1cy95VUdQbmtWQXkzbGVMVlF4NXgzV0VrcXhTU1NlekxaTFVXUmZh?= =?utf-8?B?VFRwRWl2dGxEc1hXQ0QyOUFlNUtEb0JJM0hEN2wrQkorcm9uTDdvK1BUQjI3?= =?utf-8?B?Umx5a1hVM2xjTS9tQTNpZUFTSEpCdUFDeFJiUDVwYXhIOFVUbGZLMXZsNG56?= =?utf-8?B?Q21TM3F1R1VUb0N3cVFUSGU1bnNHTFRoS3BBcVlTcW1yRkRjOURVelVhL004?= =?utf-8?B?V01JeWRNM3Z5QVpVM0x3blVLUlZPaDFvWTdRTktoL1VsYk41THR4SktJaGhP?= =?utf-8?B?T3RveVdEVE5rY1d0ZGpHdjhkSmZQVEpYSURhVkpTM3ZNNXY0MkhlTUVwajBH?= =?utf-8?B?VW1Vd3lKL2JJT0tvMTA4eFA3NU93S0VJUmdnN3dwNUIzNXRLbC9MUnRPTzdB?= =?utf-8?B?UVJYRW9kcjIxa1hYNGpDaUhNRmFTK2EzS2VNeTJhR00xOFRndi9Cc25rbG82?= =?utf-8?B?UkhGbFBvY2t3eC94Y0hVMjNLcXNlSjkrSCtYaTlyQVU1aXhPYWVlZXV4OGVv?= =?utf-8?B?VUJYT2Q5Q1gyU2hwUmtkSnpWNGZ3UnBoWE1ZK1RjTFJZS3BrQzg2SlBtUEI2?= =?utf-8?B?ZUNic2VFUUlCMXpNRlBxUUZ0Q0ZMcDNySGR4dEZybDJ6b08yRTNPQXZqcDlL?= =?utf-8?B?REZDZjlRZ09TZFpyTGxPejNHb01lWUVxODIxaG5mTzk0eHVENElFYlNRMUhs?= =?utf-8?B?elR5K1UxenpQZXRpV0M1WG5hNTRsNy82c0wvemJ4M0pLa1NUTThEZEpiZTYx?= =?utf-8?B?amI5V2dSdkliYUUycGtSMUQ5TXNucXgvenhEcVlNK1ZlM0ZsUHQrd0YrTXk5?= =?utf-8?B?WnFkR2h1cUNNcG92UVNRM3g1YkdKWjdHb2lpRXA5L0kxd3MvMDNoRUF3SEZ6?= =?utf-8?B?cnZWM3FFak5yQmdsbVIwS2dCT0FyN2xyZGxHWkF5c0RHZFhDNUovM3Q1Q0Jo?= =?utf-8?B?a3lrQ2w0cEQ3ZXhqVnd1ekV0Z2RSR29KTy96YTg3ZEpvU2ZlV053SnZHZWsy?= =?utf-8?B?dHB6bC9wM2pLbFZqQlNNSGc3OW1KSVovajNzODJ5OTBremdDaDZvTHRMcEN2?= =?utf-8?B?aTVmd3JWY2xOdnhxLzJOU2pKNVB3Q2Z6cCt5czVLOTlDQWx3djlDVTVtVG1Y?= =?utf-8?B?eEVmMk5nck1XWWNwUmZRN3JPOGR6eGp4K0lHdk85ZUw2NmJkTHRPdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: be5e2de0-3952-4915-6196-08de5e6548e2 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 12:03:44.1926 (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: aCmkDQOh7sv90VXHdmIqK+k+Phh3qs4X7mVKMJuKpiiRpQDXSq624vn3OYZ+NmnBGAf3xzESA2bO8Sqay6sAEQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7357 Hello, In XenServer we have seen the watchdog occasionally triggering during domain creation if 1GB pages are scrubbed in-place during physmap population. The following series attempt to mitigate this by adding preemption to page scrubbing in populate_physmap(). Also a new limit and command line option to signal the maximum allocation order when doing in-place scrubbing. This is set by default to CONFIG_PTDOM_MAX_ORDER. Thanks, Roger. Roger Pau Monne (3): xen/mm: enforce SCRUB_DEBUG checks for MEMF_no_scrub allocations xen/mm: allow deferred scrub of physmap populate allocated pages xen/mm: limit non-scrubbed allocations to a specific order docs/misc/xen-command-line.pandoc | 13 ++++ xen/common/domain.c | 30 +++++++++ xen/common/memory.c | 104 ++++++++++++++++++++++++++++-- xen/common/page_alloc.c | 30 +++++++-- xen/include/xen/mm.h | 14 ++++ xen/include/xen/sched.h | 5 ++ 6 files changed, 187 insertions(+), 9 deletions(-) -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 28 12:04:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 12:04:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215577.1525740 (Exim 4.92) (envelope-from ) id 1vl4HC-00014n-Jb; Wed, 28 Jan 2026 12:04:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215577.1525740; Wed, 28 Jan 2026 12: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 1vl4HC-00014g-GW; Wed, 28 Jan 2026 12:04:02 +0000 Received: by outflank-mailman (input) for mailman id 1215577; Wed, 28 Jan 2026 12:04:01 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl4HB-00011L-M4 for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 12:04:01 +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 6cac35b1-fc41-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 13:03:58 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by LV3PR03MB7357.namprd03.prod.outlook.com (2603:10b6:408:195::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Wed, 28 Jan 2026 12:03:52 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.006; Wed, 28 Jan 2026 12: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: 6cac35b1-fc41-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jAFy+t+PNZo1dvnwPddImr8g4zPnTipURwwo3gjzmDPnWV7Awp6CcN6feNnReIA8pzdn/6c3btQDS+Wi7LwoHh8LRQNlXnPzuxa+lx1krCYzlKQsYy8lo0Zc7LeuukN/1tqWIFjgLLpznnKMdMEO15z8vUERvAUbBjV1s1wBI9YvzHNpIejSliEVudQdgYKi+geBcUCeZoWGTAmZ37T9a1NhK1qVUlM4BONMZGISiRczQb4lNY+hKYHEH0vNSmTvxEGbE1m7fiSs0xgjrtFXZRuZzMW6rj1PSIMi5weGVZXrwlrqwFFG4zGeSuzfHzO8hqhZD6uaTKDWOz7dPzVmtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0T5V+kHkdL8FvGWYql4pNaSReTvMoCHjT2QNsPOM0n4=; b=yfe3LLiNUrAo+fNNqjFfsElo263Cm1cICg69G0Ych3eDuaaR/tASQzq2cNKeF5MOqGXjh4hkAMbf+Twp+3PUm4jNNtLjx/Q9HPhBDw2JQ7IW89n1iU8rlNYlzZgaVcH+0aqPaqjhogsoD8ncUIc6wRGbZXxMWUOGN4xsJHCPsUVthL7GW81SVQZcMsLsZxkApoULnRScXhNWgcIt8KENxjoSDPQDBNes0UIEfpOefU5NkJaTKUfJdEaz8nYFHiBtQ5xMBobhtUUeBqvD7ZaD2kipBSIpSRuXcIRQwyPE6O2/uqb3rTNilpOxDPNZi8GjdWwo5QdgDMGlTpHzvS+qGA== 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=0T5V+kHkdL8FvGWYql4pNaSReTvMoCHjT2QNsPOM0n4=; b=rvzVEp2flsZDlvYcJiL+luUyP+hohxglWh8F8rVln9a/62xifuHOAkcQtShiK6vyR09WejcRJoG0L6f4w3jy79C/muGdQYrHNXqjazHt6f0iyfeZSa/g0YzMzM/e9b7rgRo4+iXxgxRfSSgI7dQsbY7VtGMPqOy2dsMU9FUC0Kk= 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 , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v4 2/3] xen/mm: allow deferred scrub of physmap populate allocated pages Date: Wed, 28 Jan 2026 13:03:38 +0100 Message-ID: <20260128120339.47373-3-roger.pau@citrix.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260128120339.47373-1-roger.pau@citrix.com> References: <20260128120339.47373-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MR1P264CA0007.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:2e::12) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|LV3PR03MB7357:EE_ X-MS-Office365-Filtering-Correlation-Id: 277c2970-bc93-4deb-cf95-08de5e654d3e 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?bG9oVkZlTFQrTDhTMy9mbG1kNW90UCszZXFWSEJEdTVxRng0RWcxdCtuYnU4?= =?utf-8?B?bmVReldYZlFvYnU4b3o1dmd4bThNU2VkVUFYYVpuUkRhUXlRRlhaMjErYzV1?= =?utf-8?B?dDREajcyYWlyeVFsTFJCSWVReDQxU3hNczQzRGJjQWFQZmsxdkZ6VGg3c0Q2?= =?utf-8?B?Q2tNZWsybWZnRkRvdzVUWU1aUmJVWUh6MUhyV3dxZEhWMjlpck9jYmMrZ256?= =?utf-8?B?ZjFVZmFjdnVEa3pDNGcyOTlVck1INXNnelhhRFRBZzZYZTNmN0FVSUM4UHdO?= =?utf-8?B?SU1pQURUTmtKZWNVODg1T01FUkhhQ3NoYTRKdkdQRTFNN1J1b1hzbUpodXlS?= =?utf-8?B?ZkkxT2NtTFczZTJ5RnlEcUpEdkd2UnIzQ1hlVDFVeGVsbmhvVTRUbkMzRUNy?= =?utf-8?B?aFIrNGxZUUJ3TnVMUC9BR1YxWTViNWd0QlJkZ0krZ2hRakJ6MGNDKzBWNFk1?= =?utf-8?B?TEZBQWYvZUZZeXZPWks2bDhqRFJXZ0pnaG95NnlBY3hxR25mSVBBN3VCYWZl?= =?utf-8?B?Z2JlSlJIcWpWNUIrQ29IcDRmbGhya0IyblpqbG53eEFEYmx2d1VvM01LTjM1?= =?utf-8?B?ZHJZQmFQai9HbjBLcEhMOEZxWWZROTVjRVk3MkFUcVM5N2lUY2NEZktJdG5o?= =?utf-8?B?Slh5QW9JZ1R2RjJ0UGg0d284L1dMbzZiczdLSUEwQ2VwQnlsWS9ENHhBV2Nq?= =?utf-8?B?MG45Z2NiMDU0ZkV0SGphY1ZaSUI3SyttdTNsbU4vR3lsV2VoZVp0UmJ5QUxJ?= =?utf-8?B?ZUNxaFJJbmgwZjgxekZxMFhvVkpuUUtka3pKTGN5QUtBZVQ2N1VqQVpEYzVF?= =?utf-8?B?aXhVTEN1NzE1dHVuVy9wQjVJazdmb1hMQ2RHOEp3YzhHWTJMOXVjaE5DRkpK?= =?utf-8?B?Tk10d25lazNVNGtkTUd4RDBJUW9idkdScTE0NEd4N0hnZThzMzcrQklSU2N6?= =?utf-8?B?Y3RYS2VRdnJ3MzFhU1laK0M3S1JkUmxWVFNaRHA1dDNlZ0J2WmxlSFpMdFQr?= =?utf-8?B?dHN4R29SUmFpN0FadkNycHRnb0o5cytNVnJmZDFzdjhXL05DOWtOV0tFeGlw?= =?utf-8?B?TGVMSEF2dE1pWWVQR0s0L0p5eTVlZG44VkdONnFSdVBhVGk4NlFBd1VZa0xE?= =?utf-8?B?UjNaYW5CT0ZrYU0ySkNTS0F1M1ZVRXN0bzJ2UFRTNmpKeVVTR1hkay8wQWZT?= =?utf-8?B?LzJjTlpaVExBWnh5NXdDZEl2aEwzdU9UelJYZUh3WWFHVlZWYnJCcE95Sm9a?= =?utf-8?B?UFlFcUNlenVSRG11WHFWSXJrWFVUdk5rZm1uVnBjNFRCemFQbGYzL3cwMy9a?= =?utf-8?B?MlpGeFQ5cWlWSDQrUEM2WmpxS3JsbVgrUXUyMkRxS0FqeEQ2K2ZJbHV1U0s4?= =?utf-8?B?S2RZazdRTlJPUUN0RlliWmsveCtqc1BmdzdEWEIvRDZPa0lOVng2QmFHall5?= =?utf-8?B?d3JzUzBjak5Hb1c2RmhuZGdLbXVpNmpEdER3NFpKZisxYW82M3ZYNmVyOEc2?= =?utf-8?B?UE5QN3JLcm5qQzRBUDhXUnczb2tRcjhKK0hxQm1mK2ZxTTBPOUg4dVJuVThs?= =?utf-8?B?NEh3VWNRNEpHSTlZUVRnbWhlYmlSTmlBUTVOQ2s2TmlTb2VYVjBjNTJ2WlI0?= =?utf-8?B?MG9QWU05Smw3QlRRblloRHZ5SHJ3WldScmNqOHBHK3pHK0dIMDR4VkFDUitl?= =?utf-8?B?WEhEYWp3bWdvNjJLNGhQWWZiWWNIa2VDKzVMczBXQTQzcnZlUTlyUHo5R0pa?= =?utf-8?B?SGFDWkhwWUgvWXA2MXltUlE2UnYxWGh6L0JoSGh6RXlHSklxM04vcXJ0SDlo?= =?utf-8?B?R3JUL3hpeHlsWHNvaFB2U3U3RjJIeVljNGRqc1VweEFPNHMwMjcwV3R6RkJU?= =?utf-8?B?SklQcUl0aC9Gcnl4Sk1jWU9IQm1lUExZa0RYWWZtd2dOWkpRb1V2dG9ZVnJX?= =?utf-8?B?aENMZ244RlBwdXJJM1dCWE5mQW14MkFoa3ZhZUYwTElTT0Uyd0paVk5lUGVJ?= =?utf-8?B?Y0VSbkhjdnJCLzZ5aWkvb3VTUVR3d2thL2QxR3R3NjZXdjhSZTh0SkpTNXVi?= =?utf-8?B?Qklla3l4SmVUZVQyTWtMK2xyeXc3dWh4WVhkTGhGNVVUNzgvZVpvaTZ4aGlZ?= =?utf-8?Q?Tjss=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aVVtRy81Qi80MDNYTTh2azhwMHRUa0UxMjk2YlNWdWRnTXdHZmRCR0xyYTBH?= =?utf-8?B?V0FTaGp1ZGhaaHcrdmIrY0xLNGV4SUtkTThwVUpNMUxKbFl6NnNtcU1QMDE3?= =?utf-8?B?cEtIVVhRSlBQTVIwakd2Zmt3UHRDWGNXRlY3ZFJJMUhKZ1pXMFdDdmY1TFQ1?= =?utf-8?B?eXB6UVBwRDBMTUpOcktpUndMS2NxNmQ0UFE4VXNIa0FuSzFiYU1JVGhjRUVP?= =?utf-8?B?OVVpUVhIZ3I1elhWMWFIYzEzb3BiWnlDR2hSN2krMU1DYlBQZTIvNUZhelJu?= =?utf-8?B?dUFHVjArNXhoNVdJZWM1ZXFYdUk0dzFuZTdpZ25FbldUbzg0enI4VlROYWRX?= =?utf-8?B?cUx6ZWowSzZpRkd1dk5EdEUvZkVqc0dlaENJd0dhU3VSTHF4cDdkQWdwdVBZ?= =?utf-8?B?SytUQ3BtN2UzNmp2WDY4Y3NabmVpS3pTcUNHTUd2WTFyNG5FQUhpalUxVlVG?= =?utf-8?B?ZW5SNTBXMWw5VHZnRHdzWlpsZk5EMlB6Ui91RmxSczd6Mkd6WnRTalJXNm5j?= =?utf-8?B?ZjJQWERGaXJkR2xra2MzVkxMMDg5STdkUXRlZG96N2tyRFNoNnh6TkJOUjFq?= =?utf-8?B?emp1ejNZOEhTamFFcmRsWkdCdW45WEhWeEo2VVNENVJOWXJ1ZndxQjFvcjFr?= =?utf-8?B?Q3dDbjZOQ1NmSHRjNjBBS01sb1B0OGlKbkRVcm1DY05XY3FreVc0L2RTTEF0?= =?utf-8?B?dkhLcmVWcm5OTG0xdy9sSjBSRjU4QlVVZ1pqVkNmWVFURGs4KzV4RUc5S0hL?= =?utf-8?B?N0JDNyt2bkpheDJrMmNQeUo4V2RtOEN6R055Y0g1SjRYejlDTlhNK3dBQlF0?= =?utf-8?B?Yk53b3gvU1JVMnpqYm1NWDNueFFvR3RlUncydjR2QkVrNTVLM1NGbWVhNVR4?= =?utf-8?B?d05ScUF1dU9KZHpHQS8vWjdnRFVPQTN2UEJSWmQ2Ykd3OTR0NTUrYVVmbExo?= =?utf-8?B?YTRHN3d1NUMzOHJQa2hkeitTVXpmeDdNdFh1aWt6ZFIrMExLRWdKNGRiWE45?= =?utf-8?B?NVkvUmdTeE16bmhkRUU1aVB6bC9HNVVTSmplcG9KWDJYS3k3YndLWXU0T1Iy?= =?utf-8?B?NzQrTkZnOVdpSk9iU1NGNVd5aElEN3BwYVNVVWZqL0NubzBSK2xvakdQdDlk?= =?utf-8?B?T04vY25tNENvSjZDRTR0MU00VlVLRlFGTElsQlF4d1g4M25XUFZCYXFONlNn?= =?utf-8?B?aXhOclVjWjJDWlpSUG1rekNLZEQxVVJsTjIvUGd5clQyamprZ3pkRFkwT2ho?= =?utf-8?B?U1ozUzlVT1daQlIrdXBqY1hJb1UzQzJiKzJKTi93MmJUbkFWS3ZialhrdlFw?= =?utf-8?B?MHFGNkZmRjlLQTdQRmgwOGZ1NURmdksxTTlBSjRhanBRZnlEQmIwei9MK0dU?= =?utf-8?B?U2M5Kzh3VVhGT2JLV3g0U3pCYW9OTmoxVFNyZmt4MFIvdlhodnlNQ2cvbGxS?= =?utf-8?B?ZjVId3dQM0JGcUNyV2tCenkwQWFDTHRhV2lWKzV6RXM3b1ZDZndySXR0VFhn?= =?utf-8?B?OER5Mjd2UDNEbmZBUjFOeVJLNXl0aFczNWhEUm51ZWRkdXFuckZZMGN4Sitj?= =?utf-8?B?N0RPOHc3QzluanBUMFE3dHlSdVRWeVI0L3lHVVJKcWNnN2tLd2xsTG8vZmtY?= =?utf-8?B?UTFFM3BPV0xpNVhCb1VmTFh4ZXZFT3pzTm5aVUdBM0VyK3RDZmVzOUtkRlBt?= =?utf-8?B?Qk1Mc3RlNzVydFRtOU1hRFIxQTBtSjJWTXlESHNBT1lXKy8wZzdZS2VYTkg0?= =?utf-8?B?OGN6dElOWjNBMmIwNVBYWkhES05KSDhZeVY0UGZMTXA5UnV6djEzS0U0UFND?= =?utf-8?B?SDF2NWNnNkhoUkR5WkdvZHRJd1QrcG5HTnlEeEx3aVNVWDdhcUZGWW1sV2tV?= =?utf-8?B?a0xDOGpYbjF1aGFLUTQzTnorYjhMMWdhTHlhelVvb0tXcTRvNmIxL1NBZCt5?= =?utf-8?B?YmYwM3RDbGt6TUkrYWpZS1hOSWdHQzE3NnFIZVZ6OHg1WGFxWHQzZHVNQzBF?= =?utf-8?B?OUlhcFBRWm90UXZwaytvZTg1WE5OL0N1S2FTajZld0tkd3hUdGJ2U3Q2TnFs?= =?utf-8?B?dE5sQ3VrcThPVzlJYVVWRll2UmxWME9ld1UwZlZxZ0NubnhkWElpRjhNak9U?= =?utf-8?B?MXA3T1hQZkVaMTNVd2pONXJ6bVJhclZ6NE9jNjRlWnNGM1RLeU5TQXdTbjBH?= =?utf-8?B?UFlNby9KRFZ4WUQrMnlWbk5za0gwZ3lGMVVCbWExUVZaRjd4WEpFQzVJczVO?= =?utf-8?B?SWZvbEQrdkNZUzB5MHBJaS8xTVIzMjZURTVVeS9qZGJqckcrVlYzYjh6SDFG?= =?utf-8?B?dnNPYVJrNUk5R1NYMm1VN1hLMlVJcm0yMFYzTHBzdVRCZVRPcWhFdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 277c2970-bc93-4deb-cf95-08de5e654d3e X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 12:03:51.6139 (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: DGESvEn2p0A/cTdmoXSe5IfUm+Oj7b68y5yJ+xUlWu5RLrJXztBttnJwM05jQEMVLBsX4noIi0yd0Gh8tnH8TA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7357 Physmap population has the need to use pages as big as possible to reduce p2m shattering. However that triggers issues when big enough pages are not yet scrubbed, and so scrubbing must be done at allocation time. On some scenarios with added contention the watchdog can trigger: Watchdog timer detects that CPU55 is stuck! ----[ Xen-4.17.5-21 x86_64 debug=n Not tainted ]---- CPU: 55 RIP: e008:[] clear_page_sse2+0x1a/0x30 RFLAGS: 0000000000000202 CONTEXT: hypervisor (d0v12) [...] Xen call trace: [] R clear_page_sse2+0x1a/0x30 [] S clear_domain_page+0x11/0x20 [] S common/page_alloc.c#alloc_heap_pages+0x400/0x5a0 [] S alloc_domheap_pages+0x67/0x180 [] S common/memory.c#populate_physmap+0x22f/0x3b0 [] S do_memory_op+0x728/0x1970 Introduce a mechanism to preempt page scrubbing in populate_physmap(). It relies on stashing the dirty page in the domain struct temporarily to preempt to guest context, so the scrubbing can resume when the domain re-enters the hypercall. The added deferral mechanism will only be used for domain construction, and is designed to be used with a single threaded domain builder. If the toolstack makes concurrent calls to XENMEM_populate_physmap for the same target domain it will trash stashed pages, resulting in slow domain physmap population. Note a similar issue is present in increase reservation. However that hypercall is likely to only be used once the domain is already running and the known implementations use 4K pages. It will be deal with in a separate patch using a different approach, that will also take care of the allocation in populate_physmap() once the domain is running. Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed") Signed-off-by: Roger Pau Monné --- Changes since v3: - Introduce helper to free stashed pages. - Attempt to free stashed pages from domain_unpause_by_systemcontroller() also. - Free stashed page in get_stashed_allocation() if it doesn't match the requested parameters. Changes since v2: - Introduce FREE_DOMHEAP_PAGE{,S}(). - Remove j local counter. - Free page pending scrub in domain_kill() also. - Remove BUG_ON(). - Reorder get_stashed_allocation() flow. - s/dirty/unscrubbed/ in a printk message. Changes since v1: - New in this version, different approach than v1. --- xen/common/domain.c | 30 ++++++++++++ xen/common/memory.c | 101 +++++++++++++++++++++++++++++++++++++++- xen/common/page_alloc.c | 2 +- xen/include/xen/mm.h | 10 ++++ xen/include/xen/sched.h | 5 ++ 5 files changed, 146 insertions(+), 2 deletions(-) diff --git a/xen/common/domain.c b/xen/common/domain.c index 376351b528c9..123202f2c025 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -710,6 +710,23 @@ static int domain_teardown(struct domain *d) return 0; } +/* + * Called multiple times during domain destruction, to attempt to early free + * any stashed pages to be scrubbed. The call from _domain_destroy() is done + * when the toolstack can no longer stash any pages. + */ +static void domain_free_pending_scrub(struct domain *d) +{ + rspin_lock(&d->page_alloc_lock); + if ( d->pending_scrub ) + { + FREE_DOMHEAP_PAGES(d->pending_scrub, d->pending_scrub_order); + d->pending_scrub_order = 0; + d->pending_scrub_index = 0; + } + rspin_unlock(&d->page_alloc_lock); +} + /* * Destroy a domain once all references to it have been dropped. Used either * from the RCU path, or from the domain_create() error path before the domain @@ -722,6 +739,8 @@ static void _domain_destroy(struct domain *d) XVFREE(d->console); + domain_free_pending_scrub(d); + argo_destroy(d); rangeset_domain_destroy(d); @@ -1286,6 +1305,8 @@ int domain_kill(struct domain *d) rspin_barrier(&d->domain_lock); argo_destroy(d); vnuma_destroy(d->vnuma); + domain_free_pending_scrub(d); + rspin_unlock(&d->page_alloc_lock); domain_set_outstanding_pages(d, 0); /* fallthrough */ case DOMDYING_dying: @@ -1678,6 +1699,15 @@ int domain_unpause_by_systemcontroller(struct domain *d) */ if ( new == 0 && !d->creation_finished ) { + if ( d->pending_scrub ) + { + printk(XENLOG_ERR + "%pd: cannot be started with pending unscrubbed pages, destroying\n", + d); + domain_crash(d); + domain_free_pending_scrub(d); + return -EBUSY; + } d->creation_finished = true; arch_domain_creation_finished(d); } diff --git a/xen/common/memory.c b/xen/common/memory.c index 10becf7c1f4c..1c48e99a6ab2 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -159,6 +159,70 @@ static void increase_reservation(struct memop_args *a) a->nr_done = i; } +/* + * Temporary storage for a domain assigned page that's not been fully scrubbed. + * Stored pages must be domheap ones. + * + * The stashed page can be freed at any time by Xen, the caller must pass the + * order and NUMA node requirement to the fetch function to ensure the + * currently stashed page matches it's requirements. + */ +static void stash_allocation(struct domain *d, struct page_info *page, + unsigned int order, unsigned int scrub_index) +{ + rspin_lock(&d->page_alloc_lock); + + /* + * Drop the passed page in preference for the already stashed one. This + * interface is designed to be used for single-threaded domain creation. + */ + if ( d->pending_scrub ) + free_domheap_pages(page, order); + else + { + d->pending_scrub_index = scrub_index; + d->pending_scrub_order = order; + d->pending_scrub = page; + } + + rspin_unlock(&d->page_alloc_lock); +} + +static struct page_info *get_stashed_allocation(struct domain *d, + unsigned int order, + nodeid_t node, + unsigned int *scrub_index) +{ + struct page_info *page = NULL; + + rspin_lock(&d->page_alloc_lock); + + /* + * If there's a pending page to scrub check if it satisfies the current + * request. If it doesn't free it and return NULL. + */ + if ( d->pending_scrub && d->pending_scrub_order == order && + (node == NUMA_NO_NODE || node == page_to_nid(d->pending_scrub)) ) + { + page = d->pending_scrub; + *scrub_index = d->pending_scrub_index; + } + else + free_domheap_pages(d->pending_scrub, d->pending_scrub_order); + + /* + * The caller now owns the page or it has been freed, clear stashed + * information. Prevent concurrent usages of get_stashed_allocation() + * from returning the same page to different contexts. + */ + d->pending_scrub_index = 0; + d->pending_scrub_order = 0; + d->pending_scrub = NULL; + + rspin_unlock(&d->page_alloc_lock); + return page; +} + static void populate_physmap(struct memop_args *a) { struct page_info *page; @@ -275,7 +339,18 @@ static void populate_physmap(struct memop_args *a) } else { - page = alloc_domheap_pages(d, a->extent_order, a->memflags); + unsigned int scrub_start = 0; + nodeid_t node = + (a->memflags & MEMF_exact_node) ? MEMF_get_node(a->memflags) + : NUMA_NO_NODE; + + page = get_stashed_allocation(d, a->extent_order, node, + &scrub_start); + + if ( !page ) + page = alloc_domheap_pages(d, a->extent_order, + a->memflags | (d->creation_finished ? 0 + : MEMF_no_scrub)); if ( unlikely(!page) ) { @@ -286,6 +361,30 @@ static void populate_physmap(struct memop_args *a) goto out; } + if ( !d->creation_finished ) + { + unsigned int dirty_cnt = 0; + + /* Check if there's anything to scrub. */ + for ( j = scrub_start; j < (1U << a->extent_order); j++ ) + { + if ( !test_and_clear_bit(_PGC_need_scrub, + &page[j].count_info) ) + continue; + + scrub_one_page(&page[j], true); + + if ( (j + 1) != (1U << a->extent_order) && + !(++dirty_cnt & 0xff) && + hypercall_preempt_check() ) + { + a->preempted = 1; + stash_allocation(d, page, a->extent_order, ++j); + goto out; + } + } + } + if ( unlikely(a->memflags & MEMF_no_tlbflush) ) { for ( j = 0; j < (1U << a->extent_order); j++ ) diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index de1480316f05..c9e82fd7ab62 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -792,7 +792,7 @@ static void page_list_add_scrub(struct page_info *pg, unsigned int node, # define scrub_page_cold clear_page_cold #endif -static void scrub_one_page(const struct page_info *pg, bool cold) +void scrub_one_page(const struct page_info *pg, bool cold) { void *ptr; diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index 426362adb2f4..d80bfba6d393 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -145,6 +145,16 @@ unsigned long avail_node_heap_pages(unsigned int nodeid); #define alloc_domheap_page(d,f) (alloc_domheap_pages(d,0,f)) #define free_domheap_page(p) (free_domheap_pages(p,0)) +/* Free an allocation, and zero the pointer to it. */ +#define FREE_DOMHEAP_PAGES(p, o) do { \ + void *_ptr_ = (p); \ + (p) = NULL; \ + free_domheap_pages(_ptr_, o); \ +} while ( false ) +#define FREE_DOMHEAP_PAGE(p) FREE_DOMHEAP_PAGES(p, 0) + +void scrub_one_page(const struct page_info *pg, bool cold); + int online_page(mfn_t mfn, uint32_t *status); int offline_page(mfn_t mfn, int broken, uint32_t *status); int query_page_offline(mfn_t mfn, uint32_t *status); diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index 91d6a49daf16..735d5b76b411 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -661,6 +661,11 @@ struct domain /* Pointer to console settings; NULL for system domains. */ struct domain_console *console; + + /* Pointer to allocated domheap page that possibly needs scrubbing. */ + struct page_info *pending_scrub; + unsigned int pending_scrub_order; + unsigned int pending_scrub_index; } __aligned(PAGE_SIZE); static inline struct page_list_head *page_to_list( -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 28 12:04:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 12:04:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215582.1525751 (Exim 4.92) (envelope-from ) id 1vl4HF-0001O3-Us; Wed, 28 Jan 2026 12:04:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215582.1525751; Wed, 28 Jan 2026 12:04:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl4HF-0001Np-RZ; Wed, 28 Jan 2026 12:04:05 +0000 Received: by outflank-mailman (input) for mailman id 1215582; Wed, 28 Jan 2026 12:04:04 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl4HE-00011L-Md for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 12:04:04 +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 6ec8a4de-fc41-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 13:04:01 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by LV3PR03MB7357.namprd03.prod.outlook.com (2603:10b6:408:195::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Wed, 28 Jan 2026 12:03:56 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.006; Wed, 28 Jan 2026 12:03: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: 6ec8a4de-fc41-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=NuD1AF4zBk93psEIiAhYb8aleWD5vDeD3N8ZzPcim+g7OiZI7X8bal7VPWvmuztISHHVomdmw36adjSnYLiBqv735/3+cdGhUFGg15IAmuEr1UnZusYOIREc61oiGLaMtJyVU9V0w3kQybIXIMNFFXwFH6c8kSk3/ZCtIh0PTZ9A1osv/0VOQCPvBFExIym6U9xGrPrD8D6culBPrKIW8g+5cqfA11QwIijovc04gRJ5/Can4U2qlkwe3ZnosppQf675NTt+0lU+2pBGSHOSVsBfVGJ1vWGUHXxTTd6gIcdd2NrcsR/SifDv36ZACGAxPLtSkhkwMpZuWX/lM6fTbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6r2flN1GhCLglXiQh0ydKea2Gg7WUY65D/KjaJqBONQ=; b=AoTt6fq3c4L2Al5YvDqsMyffoRO0ngwlsE5RmTJmQQM3yXQqonwsJT9kxS37J7dPc5sKbAs1lhfYrhkh2P6w4rgmT/hUtt7370Jw0VAdrO9UN/h6IWZxcfjBzChdyvB3xNTlfkJLhud0P0mj+SsOoojKaSchQyGjkQnzgNH7HKM3MSKaUtndJmFg5EszddCqH+luWjICdOgOI5xuQxAupbmM21mceHS5mnaV5CqLp1yHnJ6nSlNsJ4zI6cNUpArh0dMKb3DgnuvwC2b2PMVzbXwEFi7FxbgcNsVfXkBbD5SWFPhLXqQCd1gNHMXInpElW2jyLnodYwukjuT4r6Ufqg== 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=6r2flN1GhCLglXiQh0ydKea2Gg7WUY65D/KjaJqBONQ=; b=Hv9zyjM46d1uk2yzLDbGPO1FCCmnrmDDNqV4NV1nMMx2tKhxWYYCYEdLRk1dhCnRr/oo7Z2QpHHM2wCFzKX5IDKT+EXC38j3wM30yF8zwKw+CDKdOzWywuO+zAaacewVo12AkX0VpoKNgnH1L94w3mbUOR8c2rGdUXKvAMHXFpM= 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 , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v4 3/3] xen/mm: limit non-scrubbed allocations to a specific order Date: Wed, 28 Jan 2026 13:03:39 +0100 Message-ID: <20260128120339.47373-4-roger.pau@citrix.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260128120339.47373-1-roger.pau@citrix.com> References: <20260128120339.47373-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MA3P292CA0046.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:48::16) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|LV3PR03MB7357:EE_ X-MS-Office365-Filtering-Correlation-Id: 19c02c47-8eef-4548-a08f-08de5e654f61 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?MHRzR2RySFZycWlLNWV6eVE2OTZLWEdUamFXL2NRazJ0aGMvT1JldVBYWExY?= =?utf-8?B?eDVKYWJxeERZakJFbTBsLys2azdEUWlPYW5NL0RJSWNUYXBUM2N6aDQ4cm9x?= =?utf-8?B?bmc3bGhqQy9leHBPK2xMY0g1bEdmOXZTNUZwVDQxQ3lpQ2NKa1NDSjZvSVd1?= =?utf-8?B?VDNPWWNvRE5FTmlGRm40aGUxamo2K1FuVnJsUmE0TjhOQzJWeTExelNJUEx3?= =?utf-8?B?MjMzU2pNYjlUK1IvSWdkbGwvajViMUtnc2xYYjVhNlZzTWd3QTk3cTNubVY3?= =?utf-8?B?b08vUTE2b0EybmpTekVNb1IzMUxzaDY3MHliaWlLMU1veGpqbjdoYUUzQ0N6?= =?utf-8?B?NGV6UjgxM2ZXR0ZkQWFhTURkTlRzZW85OUovbmdNZzc1cG1Ba3lpM1R2OUZu?= =?utf-8?B?STNUR1JNcFVQeHZuZG4xYzdIbXA0YzE2dkNqWktTNm1oT1hMQkhOdDVZVTNi?= =?utf-8?B?OFlMdFkrZi8zVVNTRjhKUXY0NE9OeFZOT3oyai9hdGFTMVNPSUpWMlZ6b04v?= =?utf-8?B?YmVLVVFUbDBnUkpKM1BnRXhqTHBXZWpKc3RZL25icExEMkN1WEVEUnI4T3R6?= =?utf-8?B?REhiQVpqZUg4U0RoZm5jK3Z5TDMyRlI0bkZ1ZVM5MUVQKzNCdTdRZEx1U0NL?= =?utf-8?B?R0dGWjgxR1BtWHRGMEp3Kzg2ZThrTEVreWhLSHNzMTIyN1ROYWpDc3Uwd1BP?= =?utf-8?B?NjlSUHcyR0NqSFV6a3VFbG1zRS93a3JIRStnYlJIdGJaS09oY09xUldMVkVC?= =?utf-8?B?ZlRGNnpXdHJWL01hZXBEb3JSNUtWZHhqeXhKdzBkSFJjS1Q2UEdwY0lYVitI?= =?utf-8?B?Sy9ZMzYzcUFGeGZGYnhHQlQyVDZ3V25hSFJkWW9XZ2E2MDYxNU9OTDdybUww?= =?utf-8?B?QXJINmdaaVUwbEkwalN3Z2JzMWs1ZWM1SVY4dGpFZktWU3BjODVwdlJzY251?= =?utf-8?B?UWM0TTlNem9pMFdaYkJOUnBxV1gxZzhhTmZwUCtNbk9zWm9YWTZacENyK0R6?= =?utf-8?B?R1o4cml2L2R2UXFrMTRpZFRKRU1OeUs5VEcvZ0t0QUVuZUJTTXo3VURmRjZX?= =?utf-8?B?dXpPemZwM2RWWWUxT1hXRTdvY3RrTUd1d1I2KzBQekZaVjFUQXM1d0NUOXp4?= =?utf-8?B?STlGejRMbDFjWEszWmlFbEUwdGJNYno0dlROWUQxZXN5a2NTdG52eEFiMmx4?= =?utf-8?B?TVVzeTk2bzRXNE93clpSanZVbUFKWHdScnhjWVBnWkd1QmVBclZpVFMzcXFi?= =?utf-8?B?MkZLMXl2bG95dmhvVHBjOVRIRzBQTWRDaFlQV1gwTGo2Y2JvMXczK3VBcFMy?= =?utf-8?B?UTJJUG5KQlRNdjg5TmhRN1lRdTVxZ2hxdlNZY1FYd0hVVHk1R05TZjZuNGVK?= =?utf-8?B?cUhQQzdvS08vQ0tjRkZQYlJtZUhUaUJGbEtjWlgwZTJibEhIVlZiRnhtMk1W?= =?utf-8?B?eGhpcnU3aXQvdDRaQkpaMUc4aGdqeHFOdlV4cThGZGRNYTNlTHU4UkVjaURr?= =?utf-8?B?YVpSdk8vdmU3dFlhNHpQcGRlVVdjZ0lQL3VGL0NlWkV1bGtSYWtuZkhEeld2?= =?utf-8?B?NXlVOU9ocnNGOWVMa0p4QklrNUFLUVAwSVRRYmd0RGQ5N2dNRHU1Z1l1ZzI2?= =?utf-8?B?ZHM4TGhvMGlBZDcwL3ROVWlaOVJORzZOcnhDMXhrYmtvd205a0owdDV1SDJo?= =?utf-8?B?NG9URkdNQ2MrK3JGVjFWVjlTdzNyNGxKQTU2Tk54ME9qU1hHVlRXUSsxZDZz?= =?utf-8?B?MkI1OUVXcWpMVU42L01jTXhib2plbnNqcG1lQ3k0WnJaQU1vQ1ltZklrV21v?= =?utf-8?B?cFNXUUk1VUYwMXpMK0J0Y0JtYkdjeFV2SXZaUUJoOFhxR3g0QVNGR256bC9r?= =?utf-8?B?SkRScjUzN2t1dmpQQTY5dEl2aVVpNXZzWDd4TitYdmdWRTBWeVc1U0RGaHRv?= =?utf-8?B?eUw5T0Eyb1ExZFl2Tmx2Um5OZ3hPTTZpVnFMVFFveWNNSG9DYnlBbkwyYnBt?= =?utf-8?B?ZTduVGVNT25JM2xES1pNQWovamxRbzcvWFFGTTFRRzIrek5RaWNZSjR2Z2M5?= =?utf-8?B?QU42LzRnMGR2aWVhWVNpSFVTeFFGWkcvdlpBYk5yMTk2c2VmLyt6Q2FFT0FY?= =?utf-8?Q?ExoY=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?T3FpQlBZU0lDRzg3OUVQbTRhR0pTckIvakw0MWYwc3lEdm5JSFdNcW1kZUZU?= =?utf-8?B?Z094UElhREtTbjdEUnNHcVh5QmRRT3p6OXRDYXBzU0s4WVoyZDNzWVFZU2pM?= =?utf-8?B?NyswanNEOHgrek9kS0dwWXlHbUpUWlRKQVRKZnF4MnRMRjVSa0FqNVdQTkFC?= =?utf-8?B?eVU1S0d0TzczVXJyQU1PNDVWa1Z5MFBwc1NvSXF0N2MzbjdZYUdwVTJEaHhE?= =?utf-8?B?WFpwRE5MejZXS09FN2dSZjFNV2F1SHZqRC9QVldHRUpKRmxBS3FFeVNhY1py?= =?utf-8?B?eGlJaVNDS2Z4cFdwcGExSExOUWtwQmNnZWRkSVBtY2cvZmhXbFMxcWdicTdJ?= =?utf-8?B?RkU0SFk2MWJ3Y0NBNVYvZUQzZGp2eEZVZnJ1bUNqajhiVGV2Q3B6aTZuaWgx?= =?utf-8?B?RkpUVXMreXR4Vkwyek9MTDJOelh6STlqb0R2RGVQajJ3NEtUZFZ4SXFIL1Rk?= =?utf-8?B?T3QwN2lTUUtPNFFTaS9lY2hYdGtPNXJkditJN3NYSkkzZDRuc2pMelJQM3hZ?= =?utf-8?B?YXpxak51ZHRnTmJiQXZnekFkakhCYU01YjlzSlZadFZoNlEveVZOZUV1WGg5?= =?utf-8?B?Q2NBOU4vVnpQRWtZZE44ZkJxR1Z5bkpJd0NGUzFMQU9Oa3U0Yy9raFJtY2l1?= =?utf-8?B?aEhpcVZCUWwwb0FjRGJsVm5HRFB5TUowYi8wVStUNlJaRlhYb1duVng3QkxP?= =?utf-8?B?YWVDMjJsYWZZUFVkeEpVTk9YQi9DeFVZNm1XZUdRQjBERE1CQ1l0VzBUS2N5?= =?utf-8?B?YzJFbFJoY1NybzRDMVh6Tm1Pb3BuWUxQb2R2NXJqMjMzSmZvaEZtMzI2MnNM?= =?utf-8?B?cTQ1aHdQWmxoVUcrNmszTWMzejl0SG45SkFQSlpuK003T2hXTFROZ256VzlY?= =?utf-8?B?U3dlYmZWZzBpc0MySnBNRU0xdU1xdmt1Kzg5YlR5bU9DaFVpUml4RUFGL3B3?= =?utf-8?B?ZkJkZEYvOWNiUEtkMmFGZEU3aWx0Rkt3bWdaNjEyWk9Na2twNDhROUZ0Vkwz?= =?utf-8?B?RmtsaERuUHgvSE05cDdoREExTTVBK0d2WHkweVRHWmVRMWtwT1k4YlZOVEcv?= =?utf-8?B?dE1xTnl3Uy9BV0FrMFBLUExrTEhnbmJiOXJic3B2ZWRHU0hESFFZbmEwSko0?= =?utf-8?B?UDJDUTl1cU5sZ0gzdVdrZTY1KzVocGhQdEg3WWRNZ3VxZVA1VHplaXVVMUdL?= =?utf-8?B?UFRFN0xZM3BpalppbXFKM3FRKzhXNk4yYnN2S014MDdObjZ0K3dSTU9YRzRX?= =?utf-8?B?bHJZckxQSVVEY1YzM1FSSW1VZVVkaElWeDhqZ0dzOUE1VGMxSlJiSllZaHN6?= =?utf-8?B?ai9BcmdzZ2NoYS9MVmtKNUNBYmZIZjQvSVRBUjNDUkY3VjNlazdWc2t0SzdC?= =?utf-8?B?bGNhT2s4MDhjUGhTbDBHdVhDUi9GRVpGcExEZ1UyMEZHSW04Q2N1VFZTYjkv?= =?utf-8?B?dUdQRi9FSVBtWUZwWk5lUUtLMy9VUFRic2JmV3FGZHZpTms3YnFLZ2pRRHZk?= =?utf-8?B?WWFFakoxN2ExeDVucEtISW9PKzJPZ3E0elV4WU92bXVlTWliQ2NyYzNtSkJj?= =?utf-8?B?L2w3TE9DV29acHg4Z0pkakQ4dElvdXRTYldreEE0c0FES3JRS2cxRVZjd3pw?= =?utf-8?B?cmhnNURpRmQ2M2p1ZGUrMHQraVBlbHNEL3ZaUzcvKzljU3NReThvc2dyTFFt?= =?utf-8?B?MWtaZ2UyWjZBdUlqUmFCQWhCS3dqMzVXWFU0OVpuWkw1VHNFU2RVa3BuMUJ3?= =?utf-8?B?d20xWjQ1d1hER3phd010MVArcm9SRHJxZm93UnRrNnZjODNpR2FUUG9IUVEx?= =?utf-8?B?K0xtcWVNWHJuNmQ4a29udUpYM0xRY3h4b1dwRFBtbzlmekpBbldSK3ZwOE5w?= =?utf-8?B?L0ZyRng0dXY5dWZSUXQxektUc3YvcmxpaUtCMUpZNHh4U2huQnUxS0JYbHlu?= =?utf-8?B?OTJ3NGxBR2phZEdQelFnYzRjbFJnZmkwWUJDaVVNYzFDanNsUUJWSnludkJG?= =?utf-8?B?TXJxYTZPSDI4NSsxYUxVSG9tZnFuL2Z6QmVOM3R4bndxMUUzSnArQWxPWnI2?= =?utf-8?B?N0NqOFRqTWJMaDQzT2RwcUNHb1NzejVkZUlZOWRxY3lQRmVtc0JveUgzNDNN?= =?utf-8?B?UGI5Q0pCSGwxa2lBSytRRFNieHZrUEpVK3VzR25lSlFxRTYyZEVLWHdnTHFO?= =?utf-8?B?YXc1Y0NKdUxnbnJ1bENPVHpBN3kxVGVlb0g4cXBnYnpvUDZ5cUw3bjVxWndQ?= =?utf-8?B?QURQbHk4YUhXYlhMaG5jK3hZRjVleFFYWjdTTkI4L0dEU3hvVWQwc2Vzd1dG?= =?utf-8?B?a3Z0d1lOWEI2WjBEWDZTVzJMb2tnV281YTI4NlR0UFE3Q01jRTRBdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 19c02c47-8eef-4548-a08f-08de5e654f61 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 12:03:55.1887 (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: qGkWu6HVxiVgg6TDUSGmLhFcJRxOkWQGdrOCLayF5nebZB+VILLilV461fV9LSXJmBPi+mN10XnJMVCSeuJE4w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7357 The current logic allows for up to 1G pages to be scrubbed in place, which can cause the watchdog to trigger in practice. Reduce the limit for in-place scrubbed allocations to a newly introduced define: CONFIG_DIRTY_MAX_ORDER. This currently defaults to CONFIG_PTDOM_MAX_ORDER on all architectures. Also introduce a command line option to set the value. Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed") Signed-off-by: Roger Pau Monné --- Changes since v3: - Note the order limitation is only post-boot. Changes since v2: - Move placement of the max-order-dirty option help. - Add note in memop-max-order about interactions. - Use CONFIG_PTDOM_MAX_ORDER as the default. Changes since v1: - Split from previous patch. - Introduce a command line option to set the limit. --- docs/misc/xen-command-line.pandoc | 13 +++++++++++++ xen/common/memory.c | 3 --- xen/common/page_alloc.c | 23 ++++++++++++++++++++++- xen/include/xen/mm.h | 4 ++++ 4 files changed, 39 insertions(+), 4 deletions(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 15f7a315a4b5..3577e491e379 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -1837,6 +1837,16 @@ presented as the number of bits needed to encode it. This must be at least one pending bit to be allocated. Defaults to 20 bits (to cover at most 1048576 interrupts). +### max-order-dirty +> `= ` + +Specify the maximum allocation order allowed when scrubbing allocated pages +in-place. The allocation is non-preemptive, and hence the value must be keep +low enough to avoid hogging the CPU for too long. + +Defaults to `CONFIG_DIRTY_MAX_ORDER` or if unset to `CONFIG_PTDOM_MAX_ORDER`. +Note those are internal per-architecture defines not available from Kconfig. + ### mce (x86) > `= ` @@ -1878,6 +1888,9 @@ requests issued by the various kinds of domains (in this order: ordinary DomU, control domain, hardware domain, and - when supported by the platform - DomU with pass-through device assigned). +Note orders here can be further limited by the value in `max-order-dirty` for +allocations requesting pages to be scrubbed in-place. + ### mmcfg (x86) > `= [,amd-fam10]` diff --git a/xen/common/memory.c b/xen/common/memory.c index 1c48e99a6ab2..a840bab87b34 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -56,9 +56,6 @@ struct memop_args { #ifndef CONFIG_CTLDOM_MAX_ORDER #define CONFIG_CTLDOM_MAX_ORDER CONFIG_PAGEALLOC_MAX_ORDER #endif -#ifndef CONFIG_PTDOM_MAX_ORDER -#define CONFIG_PTDOM_MAX_ORDER CONFIG_HWDOM_MAX_ORDER -#endif static unsigned int __read_mostly domu_max_order = CONFIG_DOMU_MAX_ORDER; static unsigned int __read_mostly ctldom_max_order = CONFIG_CTLDOM_MAX_ORDER; diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index c9e82fd7ab62..fd6cf92daf51 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -267,6 +267,13 @@ static PAGE_LIST_HEAD(page_offlined_list); /* Broken page list, protected by heap_lock. */ static PAGE_LIST_HEAD(page_broken_list); +/* Maximum order allowed for post-boot allocations with MEMF_no_scrub. */ +#ifndef CONFIG_DIRTY_MAX_ORDER +# define CONFIG_DIRTY_MAX_ORDER CONFIG_PTDOM_MAX_ORDER +#endif +static unsigned int __ro_after_init dirty_max_order = CONFIG_DIRTY_MAX_ORDER; +integer_param("max-order-dirty", dirty_max_order); + /************************* * BOOT-TIME ALLOCATOR */ @@ -1008,7 +1015,13 @@ static struct page_info *alloc_heap_pages( pg = get_free_buddy(zone_lo, zone_hi, order, memflags, d); /* Try getting a dirty buddy if we couldn't get a clean one. */ - if ( !pg && !(memflags & MEMF_no_scrub) ) + if ( !pg && !(memflags & MEMF_no_scrub) && + /* + * Allow any order unscrubbed allocations during boot time, we + * compensate by processing softirqs in the scrubbing loop below once + * irqs are enabled. + */ + (order <= dirty_max_order || system_state < SYS_STATE_active) ) pg = get_free_buddy(zone_lo, zone_hi, order, memflags | MEMF_no_scrub, d); if ( !pg ) @@ -1117,6 +1130,14 @@ static struct page_info *alloc_heap_pages( scrub_one_page(&pg[i], cold); dirty_cnt++; + + /* + * Use SYS_STATE_smp_boot explicitly; ahead of that state + * interrupts are disabled. + */ + if ( system_state == SYS_STATE_smp_boot && + !(dirty_cnt & 0xff) ) + process_pending_softirqs(); } else check_one_page(&pg[i]); diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index d80bfba6d393..cf3796d4286d 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -232,6 +232,10 @@ struct npfec { #else #define MAX_ORDER 20 /* 2^20 contiguous pages */ #endif +#ifndef CONFIG_PTDOM_MAX_ORDER +# define CONFIG_PTDOM_MAX_ORDER CONFIG_HWDOM_MAX_ORDER +#endif + mfn_t acquire_reserved_page(struct domain *d, unsigned int memflags); /* Private domain structs for DOMID_XEN, DOMID_IO, etc. */ -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 28 12:39:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 12:39:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215623.1525761 (Exim 4.92) (envelope-from ) id 1vl4oy-0006ZA-FA; Wed, 28 Jan 2026 12:38:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215623.1525761; Wed, 28 Jan 2026 12: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 1vl4oy-0006Z3-Br; Wed, 28 Jan 2026 12:38:56 +0000 Received: by outflank-mailman (input) for mailman id 1215623; Wed, 28 Jan 2026 12:38: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 1vl4ow-0006Yx-Ez for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 12:38:54 +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 49bfb2d3-fc46-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 13:38:47 +0100 (CET) Received: from BN9P222CA0005.NAMP222.PROD.OUTLOOK.COM (2603:10b6:408:10c::10) by SJ1PR12MB6316.namprd12.prod.outlook.com (2603:10b6:a03:455::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Wed, 28 Jan 2026 12:38:40 +0000 Received: from BN1PEPF00004688.namprd05.prod.outlook.com (2603:10b6:408:10c:cafe::79) by BN9P222CA0005.outlook.office365.com (2603:10b6:408:10c::10) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.8 via Frontend Transport; Wed, 28 Jan 2026 12:38:38 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN1PEPF00004688.mail.protection.outlook.com (10.167.243.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Wed, 28 Jan 2026 12:38:39 +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, 28 Jan 2026 06:38:37 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 49bfb2d3-fc46-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=wilsxGdxVzlE4GkH8j3qQmuHxbKDTTAAGK7yhrQkIXtm/HCgE/sNYUunmNQakgBBMMQW2qNYzgBy8Uf9HrfrsACw8746B81vRVTxV6DeALNzW8o5G5vzgcxw6vs6O1IALzb5khjSiK6cfPnoekR49ypIiQ1S0hI4A0b5xVTBP+E+TzTJhvjKUt7f9A5I43Dp/RLYPt5TQbmM0xYueFMA9guQl++Jd3PSlnRt9tMHMimWTEgoXEgcngn3JScn3zaHmFWPSyb2s9hCGzBHaUO90/hiPYAhQY2DS8XFweEXOzdUav1QtnS3ZMnNGttQOWDIHMWCB+Hc6RNf+jrbevBNMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YYgszTUoITTBF5Lcaekyh/Egk6dXZ+86YDrnZLCaIB8=; b=c8ZHHdxPhguL+qREg1tLV/ChP+60Mko8dgoAcGVUndRTqC7iNJOHchG9JRddIXLbH+f1swW7B5qt9Wy4FgJ3y7CVenr9ex0/tFUJy3m5jpoIUkdw/jRmRku327Tz35cBSK/ZX9NdCdVOMIwGW/IwSjFmmsEUcBcrWFB2lshmGD5miACMv+/7bx2kSVE8OlQ0KpdJmLDqNjMZA5Ugvq5qu5VD0DAsZhxCuFH0zVgFbEqLvx/mQc9qLcwsjlcLDQ5HMYHvBYRnevOOE7eH3qq2TUZtTIPgeXNijdOwYc3VWpjETip7Rnqmh3rAnmWRF3RjIMXdmFHePLwf/46b4BoWFA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=temperror (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=temperror action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YYgszTUoITTBF5Lcaekyh/Egk6dXZ+86YDrnZLCaIB8=; b=gcg4RHafzxuv1i5JzGYs8Zr7QNdk4e+tGODnc+C6HJGPj+bgAawDuLZ2rkOOnwR9wJdNRqT6wMiwyPqPwbk+jWfoohz5cBiy0M31ZHklkTZsPOA79+/gMnr+4cuev+vWtdFzvz1b/1mdQOfpiZ0uwj79vRaBgBFc+/v7VjV9riU= X-MS-Exchange-Authentication-Results: spf=temperror (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=temperror action=none header.from=amd.com; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of amd.com: DNS Timeout) MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Wed, 28 Jan 2026 13:38:34 +0100 Message-ID: CC: Jan Beulich , Andrew Cooper , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk Subject: Re: [PATCH 2/4] x86/hvm: Disable non-FEP cross-vendor handling in #UD handler From: Alejandro Vallejo To: Alejandro Vallejo , X-Mailer: aerc 0.20.1 References: <20260122164943.20691-1-alejandro.garciavallejo@amd.com> <20260122164943.20691-3-alejandro.garciavallejo@amd.com> In-Reply-To: <20260122164943.20691-3-alejandro.garciavallejo@amd.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: BN1PEPF00004688:EE_|SJ1PR12MB6316:EE_ X-MS-Office365-Filtering-Correlation-Id: c4e0ee40-666d-49c9-655e-08de5e6a29db 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?a08rNklIQlVjQ1k1SUhQREpFTVNobDB0RmZJL0lMcEJnNFZTRExVc3dKak9v?= =?utf-8?B?WWVyc3JqcmJXOXBHbWEwVVlBWUFSV3FzN2tCdTdudmpNWThwRTNhQ1JPc1Ew?= =?utf-8?B?eWtkYWJtc09WTnRsYmlkZ1EzcEg3ci9qV0RBT1RWbEpoU0txbDNNRm5aWjlm?= =?utf-8?B?T3d1TlR5OWRzNXA3WjJvSmt6YUFGSGRiWnFJR2tDZEYvSTE2ZnJxekNiWGVE?= =?utf-8?B?NDJxYzlCSENlb2hod0YyR0d2TE5YdFdmKzNZMXlsQ3dwcE5jMFlaYm1mVFcv?= =?utf-8?B?cGVZdlNEak1zK2g1cjRqM0d0ZHJqT0graFRURjEwY2JzOGNLeEY0bWF1bjhz?= =?utf-8?B?UnhiZTJwSmhseU5abmV6cEVyclVCZWtWVmI2bFpPR21WNGM3ZGJrMmYyV1VI?= =?utf-8?B?K2tuQys5NDZMelFpMXB6ZkJ6UWxHR3p0OTFpendlbFk1akRQY1dzaHp6VzJy?= =?utf-8?B?dE56cllTYTJESWNRSWtYVXVLdTZEODE3VE9iTWZlbnU2emorMjcrK3RGd296?= =?utf-8?B?dTVzYXNwb1g3ZnhVamR6a0tDZW5Xc200UlpLSVhuZzhBTkNmdnVUY2lheHlv?= =?utf-8?B?SUtWZjlrTElrbUI0V2VzMlRwR3VKU1Bzb1ZsdmFuQzUxR2k2SnhQRTRhNUMx?= =?utf-8?B?aEpLMXlQM0VicjBhZUF5dFUyZXdqNjlDWC9HelZLMzVtWXdGWEl1ejZFTW82?= =?utf-8?B?bWFHVUlkNEd2REU3b2luSVdIU1FzWVZNYjBFaDJKT2tKTGpLTXNvQm1RWDZq?= =?utf-8?B?M2NLS1dYVHJpWFJySjJrUzhHTVllQS8yL2N4dzhjZ0RSYVFEb2FCTWNMY2ky?= =?utf-8?B?aFJLM1JYMjRYWmtReWxuak8yVFJ3SVlUWW9Bc2xkT2RTRDV3SDFTaUwxSE42?= =?utf-8?B?Nk1XQm9NVCtOb0J1SUFkWXlZMXV1cE1DVXN1cHRIWHhlTEpMa01RR0xqZHp0?= =?utf-8?B?TGtqZ0J5ajdMZkt1U3VVMXI3UXdGMUJUbHBDVjVmUG5FenBBWW0zSXJ5NGRX?= =?utf-8?B?V2paa0ZTRnFESWFKaUJpZ05QU3Y4S3VVOTFxOUFJd1VEMjNUcTRoTWZReXFR?= =?utf-8?B?MFNsalQzcTJwby84cFRpbERVcEdlS2UrZ2hyZDVLS1RCajZVUm44NEhzem56?= =?utf-8?B?NjlxWTR1Q2Npckg5TFlGbjk4YjZHbDFveWh3VHVROFlPbU1qK0l3dGdqNS8r?= =?utf-8?B?VVB1MjRoTmt5cjNPdnZPaTVobFFBM2NrYWhqR0lObGtGUEd4SjZCTjBwVmxS?= =?utf-8?B?djBNTkVBQlpGcjVtSXZGV0VQNU1CYUExYjFuVG05elhOalVXZ3F3bWNoSGJy?= =?utf-8?B?d3JBa0ZiVGVBRklrZklJWGVjUUxKUkhMM1RLSmdtRklXcFFkRFRKckF3a0tP?= =?utf-8?B?eHhnVTJ3RHMrU3pFb0ZySzNXMVZCMTJRbGRKOHFHSHNKcUxUUzVQL0lWM3NU?= =?utf-8?B?bFE0SURlaSs2V2gxWVlVVVUrazdlNXdDcmF2aktFSmJwaGRWOHVrRnJzMEJY?= =?utf-8?B?S0JEN0FXanhTK3YrWTV5aTdTRVFzSzFkTm1TMXNjY3RzbFB6OG12dU1uSjIv?= =?utf-8?B?Yzg2ZG9oV1pIT0FSdkYvdUpSUll3cnZtZVRGaWtTZE9hUXYwWjltYkNaSnVq?= =?utf-8?B?ZWxnZ3dyeER3YXlJVUw3ai9wR2dLR2RDTWlQeDFvN3liYUxTMUw2WUZ4ZXlx?= =?utf-8?B?c1YrUDNQaU9hT3krQWZLNGd4SmNnbmtaa0NWUmxXSUpSclhUd0tieDlGSU1M?= =?utf-8?B?ckorcnpITE1kS2VTRkJLbC8vSU9QdW9yWG9HdlJZR0E2aXIyNjdSUDkzbVZW?= =?utf-8?B?TStibHFOTHN3WVp1eDFWR1VTK3luRm9XQXk1STYvM3M3dll1ampVWkN2ZHEx?= =?utf-8?B?QmtoTkx5VDVGZ2tNRzNjQlNPcWdQTzQrQWZjUUoxaERtMWJPNjZ2emdJYVBi?= =?utf-8?B?WE8wUFhMM05yR0VUV2YwbDhKTFNmOU0zTEVCMDRxZlV5L3FHOXI2dUZ0Vytp?= =?utf-8?B?aE5TQVpmWjJGYzFzNkJscFRvcGpEWnRqM0pWT080NEhEL1hXdlFVRU1MR3Vn?= =?utf-8?B?dmZYMENoNkkweHlCeUttUk9NaXE3eGo2c2hFVURZZzhKWVRJNlFSb25XV1BO?= =?utf-8?B?by8vaFltaGJ4SklXK1dKbHRYV3BKZEN2RDNTV1YyL3ZaenA3WTV3WU0xY3Yy?= =?utf-8?B?Q3QrcUZYWm81L0tkSDNtdVBVRTFJSEs3OHB2V2VyL2g1VkVkZjhzYklpWG9q?= =?utf-8?B?K00wTW1ZaDNFNEJwbG9TeVFzcDl3PT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 12:38:39.4401 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c4e0ee40-666d-49c9-655e-08de5e6a29db X-MS-Exchange-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: BN1PEPF00004688.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6316 On Thu Jan 22, 2026 at 5:49 PM CET, Alejandro Vallejo wrote: > Remove cross-vendor support now that VMs can no longer have a different > vendor than the host, leaving FEP as the sole raison-d'=C3=AAtre for #UD > interception. > > Not a functional change. > > Signed-off-by: Alejandro Vallejo > --- > xen/arch/x86/hvm/hvm.c | 25 ++++--------------------- > xen/arch/x86/hvm/svm/svm.c | 4 ++-- > xen/arch/x86/hvm/vmx/vmx.c | 4 ++-- > 3 files changed, 8 insertions(+), 25 deletions(-) > > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c > index 4d37a93c57..611ff83a60 100644 > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -3832,28 +3832,13 @@ int hvm_descriptor_access_intercept(uint64_t exit= _info, > return X86EMUL_OKAY; > } > =20 > -static bool cf_check is_cross_vendor( > - const struct x86_emulate_state *state, const struct x86_emulate_ctxt= *ctxt) > -{ > - switch ( ctxt->opcode ) > - { > - case X86EMUL_OPC(0x0f, 0x05): /* syscall */ > - case X86EMUL_OPC(0x0f, 0x34): /* sysenter */ > - case X86EMUL_OPC(0x0f, 0x35): /* sysexit */ > - return true; > - } > - > - return false; > -} > - > +#ifdef CONFIG_HVM_FEP > void hvm_ud_intercept(struct cpu_user_regs *regs) > { > struct vcpu *cur =3D current; > - bool should_emulate =3D > - cur->domain->arch.cpuid->x86_vendor !=3D boot_cpu_data.x86_vendo= r; > struct hvm_emulate_ctxt ctxt; > =20 > - hvm_emulate_init_once(&ctxt, opt_hvm_fep ? NULL : is_cross_vendor, r= egs); > + hvm_emulate_init_once(&ctxt, NULL, regs); > =20 > if ( opt_hvm_fep ) > { > @@ -3878,12 +3863,9 @@ void hvm_ud_intercept(struct cpu_user_regs *regs) > regs->rip =3D (uint32_t)regs->rip; > =20 > add_taint(TAINT_HVM_FEP); > - > - should_emulate =3D true; > } > } > - > - if ( !should_emulate ) > + else review to self. This is buggy. It allows instruction emulation when HVM_FEP= is enabled, but the FEP is absent in the particular instruction that caused th= e exception. #UD should be re-injected when the instruction doesn't have the prefix. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Wed Jan 28 12:44:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 12:44:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215633.1525770 (Exim 4.92) (envelope-from ) id 1vl4uV-00084w-1L; Wed, 28 Jan 2026 12:44:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215633.1525770; Wed, 28 Jan 2026 12: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 1vl4uU-00084p-V0; Wed, 28 Jan 2026 12:44:38 +0000 Received: by outflank-mailman (input) for mailman id 1215633; Wed, 28 Jan 2026 12:44: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 1vl4uU-00084j-3U for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 12:44:38 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 17c0ef29-fc47-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 13:44:32 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DM4PR03MB6062.namprd03.prod.outlook.com (2603:10b6:5:391::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.11; Wed, 28 Jan 2026 12:44:30 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%4]) with mapi id 15.20.9542.015; Wed, 28 Jan 2026 12:44: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: 17c0ef29-fc47-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=i8f5KRMAnGJGY4DqXlF5BLnB75aGsfjruYDKz15XncKAaxC1UaRY9wL/W9PW4k+EbB9q8/a1445EWjpEuq+1JaSqH8hfhkHK3zWx4vepFzqScvnTSfaHl8ZcGvCXaKOGCFpZLcobutVhqH6BEwB+B6JEDR4lB68cs/QubblYTI29CsKgEDF84rVEd62lwDUG0xtRJ++b55zGRbkZnTd5Zy8je95OnQHwDuDLyIgOpKTZzvmiKwT/y0VgAC+siGPnzMzwdb85Jn9mJrr5kU3w7YZ4TB1jSM6JqUW04VGGya6vGorDcv5hdS1fwfTiUfOcklncTQ+R8Xz4x5wbYK/KCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7Ac4kfezQV6i+ENth2s7TXdBqSDAW/p+vB0il98s9/M=; b=Ni8zb9srP9071yVcnFJz9aoh+hPf/SnEZUaRauQaJEBBhFxGUw/AO0P+Tt3QfS8AmvWQXQ5SlSAUsfAY2Ybbe1o2L+J/o3hqXCTRsfXCj8GVLcOUmIFwtga+cBHSQ++nYX5xpOk1YjHU8j+g6EIYWwAkYTahuOrssjJOW5prNRqp8tctcrbeCLgH1bItUvYdK5Yxz14QgH9C6/3ae4jjw5/TVlFo6AL7VXMVQGa53xBH09RUenB/PkGeQ8M5ZunnO5QIfQx0yDlm2nAiCb+Sc8exVPMmaWTipD8aQ2nC01PJdvbXu5SG3sK5hLR4Aq1Sbmtv8yPGi+yJL+EU/LSVkQ== 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=7Ac4kfezQV6i+ENth2s7TXdBqSDAW/p+vB0il98s9/M=; b=HzxOldowgPd/xNTbQ7fxqaidVDXacZ3HhBkQNY7euxNMGAjhtbbcqp2rZ/d+VyrVlhM9ODctSJ/0g/AViv14vtUVHmgsYtIz9+6iTAhR8XMgOfyxh0g38Wc4kJtiwoKYjyCJjoisyr+hrF3xNohy7pZOiEZYKYUHytqvch+SLzM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Wed, 28 Jan 2026 12:44:26 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: Re: [PATCH v4 2/3] xen/mm: allow deferred scrub of physmap populate allocated pages To: Roger Pau Monne , xen-devel@lists.xenproject.org References: <20260128120339.47373-1-roger.pau@citrix.com> <20260128120339.47373-3-roger.pau@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260128120339.47373-3-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P302CA0020.GBRP302.PROD.OUTLOOK.COM (2603:10a6:600:2c1::9) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|DM4PR03MB6062:EE_ X-MS-Office365-Filtering-Correlation-Id: 99a629ba-d981-43aa-c83e-08de5e6afac6 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?Q1FqMnkxVDF6WmtndXFPUXMxME9ZUTQ3ekFsZXlYMWxSWjZLTVlLT0p6MFhi?= =?utf-8?B?SXNpZGFPYVV6SUF4OEZuVFdVRHFYdVRqSVROVHR0MVlFNFdDanZnS2djQ1Nm?= =?utf-8?B?M1pxRE12UndJc1B1dDd5a1MvNDZmNVVGVlZEaXdpRGVrdzYzRkh1eWlUQkFr?= =?utf-8?B?NnNNbGVQV1pCTTVlVlh2VXZ4TFFPWHNRYXU4cWIxSnJlMVhpUUlrUitJRWRF?= =?utf-8?B?R1BLd0ZUVHNTRjZPQUJ2RTJlN1JDaDA3STdGOEt1VFZXR0d1QTJlNVF1VW9P?= =?utf-8?B?UU1vNGRGU3RmTWhDbE9teGp6eTB2SUNvVkVDaUxlb2J5N0ExeFFBdjd5dkJp?= =?utf-8?B?L2tFYkRmSjN6WDQyNDdrS2MwMEIzMVh4UzJlVy9LV1E3TFZDbjkvcHYxMXBx?= =?utf-8?B?eHhzd3F3WnAwQ0xkZkxKbW1ERys1bGY4TzliT3BTdkZjMVl4K0VwdHU2KzlS?= =?utf-8?B?SW11VFlsS1BnQTlkbGluYTVaKzRUYVBmQ2JLR3BHaTljd01KYjVwNloyWjBH?= =?utf-8?B?NW9DRnVmRGYxOGdTdVYvTUlac3drTzQ0QjBsM3ZOWWYxblBvM2hSVk1MSWRz?= =?utf-8?B?UUJHRUF3MW5HOTFrWm5Zam1uZnNxY2xRQ0tpSkZPaTdrQ1VzcDNvd01JQmly?= =?utf-8?B?VjgwS2ZpQ0xPbmtUa0dHU0FIeStHUHJiNExQaWNGOTdNbmthVkhBV3Z0K3po?= =?utf-8?B?T1M5a2pGSHBtN1pqcGdpUE9aY1VTOFNhK1IrZUVaQzF2RUJVUEl1WmxqZS84?= =?utf-8?B?ZnNkMkNjanRkZU9IQkRWY0k4MU42TVY3M3JjamRmaHBhK3YxUWt2Qi9Qb1M5?= =?utf-8?B?K0hQanZtNGNaQy9FK2k5VWh5UUM5UmVpME5SUUEveXdWMmM4SzZhenNNNEo0?= =?utf-8?B?K2M1dllaYi9ta2hSMHh3Z3gwelFLRnhEL0IwY3IzT0FyaHBnSFgxUW1US3ZZ?= =?utf-8?B?RTdxZER1THVFanNHWCs2Y3VxV2VFM212ekNVU2lyRm9TYlhTS2RtT1oxMUNp?= =?utf-8?B?T2VQeExWbXgvbEY5Zy9xbFpGeDF4VTJlcEFJQmtudi9NVkE4NkVSaVREZHAv?= =?utf-8?B?TFo3clFPRGkvS1NvMmpvK3kycXlob0xOZW5paWplUHJIREZtRnN0M2duM3J6?= =?utf-8?B?K0sxWkJlTyt2R3ZYTWVUZmp1U2RYamhKMUNLQzczRHVtYnR5aUU2TjdJU0Ux?= =?utf-8?B?S1NiUkI1MU5SaFJXeGp4L016WFh0anBUK0Joa1Q3TGNiWWh3Qk1rWHRWbzhk?= =?utf-8?B?TkdnaWY5dWpVaUNvalRERWRyaWJOV0lsUHBCNWI2RnhWQmxjb1QxM01tcy9y?= =?utf-8?B?eVk2TXFnNjNtbnZEUktPaFBBTHlGZWF0amFucEFWdjB2ZG8xeitzZDZ5bFZj?= =?utf-8?B?VEI5WjFpQlQ0RUM0K3h6b05uZXNZaTVPeVlQTXc3WkQ5L0JZZUZKVkpsZkVv?= =?utf-8?B?SmVmV2d0dngvakZoNGtNclM0ZzArdW9lVmErUUl1cFV5NUdXVlBlZGdIdGdu?= =?utf-8?B?bWM3OHFld3lDb0IyVWdjL0dNdnQ2N2lac3dweU10Y0p3THJYVjNpOUV4UkM1?= =?utf-8?B?OWFORFNHRU40WFRRZC8ydnByckZLNFIvTTV6MUZNeFZMY01xVmF2eXMwZ2Fk?= =?utf-8?B?U0JxM215YzVDTzh6eWNMbUtwenhqOStGK0ZOaGFqeSsyMFBPTW9zbmdBMm1t?= =?utf-8?B?aGxMUURqS1loZGJmYmF1Z2NSYllzZjFrTXdnQ0pVS2lLY21JcHByTm9oQm4y?= =?utf-8?B?dTZzVVAzdGFaejJ2dU5jYndsWFphL2hhbDRyMmRxZmlqclVhZTF6QzZrY24w?= =?utf-8?B?VDRydnQrSGE5NGcvNXowMm9TSnJ0K3JPNXd1RkV2cnd4U3ZERk9UT1Z3Nnlj?= =?utf-8?B?cEJLUVhDZTNrMGVzaTlNd0lkRGpPbUFYM08rZjZTdHBWMHNxdU1qQjlyMW5Y?= =?utf-8?B?Q04rajl6TE9TNU1HNktTQ1pXY2RNU0haZkgwVEhjMFA1cFJOL0dUMXA4akxF?= =?utf-8?B?TjV3VG41d2NLVWFPWG5NUEEzN0ZJMnp1L2tPa3ArZTh1eUtKUGo2RFI5b1Za?= =?utf-8?B?bGlQelVSc2haVDZ2MURLTHl5SGdIRkRMZnM2YW5CNnRaS2M2Vm4rbjJ0RHlr?= =?utf-8?Q?hqHs=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SVhGN0huRXhlUEN5a2pUaFhRTmFXTjdNWlFOUTNRbFhIUjEyUFREZ2ZVYTZv?= =?utf-8?B?ZkJIOVB3ek1oMFlUODJiV0xzb1cyRVVKdGpvOUxiTHRVS2toT3F2djVENSti?= =?utf-8?B?NDhzejJTNWlCaVBpNklLcWNLWmtaWUJ5d0U2b0tEcVJTUFlrMHNRTU1uczh5?= =?utf-8?B?SjVxOUFnck9oNHNiQlFOdGFkYm1xK2JWYy9Hdm9jNTRGRkdzZEZoS05iaHdI?= =?utf-8?B?b216eDNDeVh3WUhSZTRPNmNKaFlIUC81cWFtc0tjZW4vdEY4L05MRnQwZm1k?= =?utf-8?B?eEJtKzRwNlJkOG81QmhyWHVic1QrUldVeVpnYUJINlZOdkc3UGtIYlhZYzZZ?= =?utf-8?B?YUtveFhyallYTG13RytQbHBGRFQ4UWZIQ08rellRNmd2eFg3d0ZtQ2Y1OFdo?= =?utf-8?B?L3FIY0RiK1VkNElzcGxRQjN5VHNVeTZKSzhaV1V5SnpzYnJTWit5aVF6OVRp?= =?utf-8?B?ZnhVY05jQytqUnErSXU5b2M1N0Rlb2JBc3hQazNwdG1pbDBVU3E3NFU1Qk9k?= =?utf-8?B?T0xqbVN6NjF4VCtqdnZHWmExUG9vVm5mVkJZWHdpaFM0bW1BRG1UeTVmYXow?= =?utf-8?B?NlFJZ2dpL2FIZnZmUlR0MWxJcnp4MGhDQituZFZlSml5ZHhPZ2d1djJEZ21X?= =?utf-8?B?ZTl2RzYrZkJLeW1NNVUzL2YyMXVGMzVoOVg0Vy9tNWQzTGNVSlJ1TlB0V3Zo?= =?utf-8?B?b29VMnN3UlUvdUlYSzJYYVpLeWZFL2tuQ3JTdEJOK3htb0QrMGhnblQ3WVZL?= =?utf-8?B?Sm9tYlY2OWxaYWR4RWlsR2Z5Y0RaUHNLOFdzUTZtWVZUUmplYVFmbDRzQ0tO?= =?utf-8?B?NHJPalV0WGNYMmNjZnorYlYwZ3BZSmFIdzZNTnZxT2lnRVpROGorY2xuR1dX?= =?utf-8?B?Y245c09rcmZVNlppbWRCdU5BVDFMWk03Wm9QU3djTVFqSDhORnB1WkRnUEFT?= =?utf-8?B?RHR0Y1Z5S092QWxyWXV4TEgzSXlJVmJtMlg5NjUwUTFGWWExWXMydCtzdTR5?= =?utf-8?B?QzdUNWF6amFiYiswTnVOM2hOUVpobVZhUUpvdWhqN2VwS2JmOVl2Q0NJeVlr?= =?utf-8?B?ZVBGRWcveGFVMWlmM0tlYkNTRDRDVHlURkdQVEdSU1lEcFJ3TzJPZU5KdXVH?= =?utf-8?B?NjRLUVZ5bjk3dHZLZS9RdS80Wnd6T0FYbXlyRHJtZHlKTDlVWndxQW9iYlFC?= =?utf-8?B?a3UyTW1DcW9sbGRUS0VTSG1kRTJMRTNxTmRoS1VDQjVCTnpscXpkdlZ6aGtI?= =?utf-8?B?YmRVMEt1V2JvWmh6UUlQT1NFS1pYSGE3LzNDS1VLZWJvRnJ5OXpzbzl6MDM1?= =?utf-8?B?bnkwVHFGL1d0QTZDSGZ2cmEzcXRRenJYdng2OUErd2hxOHJaZFdmSzBuK1ZD?= =?utf-8?B?K1pobEN0Y3FTV1YyTTR4NTdHcHlESWN6MjRFQ3RqKzZWelZYdWRES0JjeHVo?= =?utf-8?B?bGRPTHZ0ZkVEaWpRMjhucElvdjRpaVdTRjhhNng5ZnY4c3kwSnozTXNtZndm?= =?utf-8?B?T0p1dE84Y2Jka0ZlVE5PbFNtOHo0Z3I2Qk9ua29GUTNGdjJ2WTR6YVBaeFNH?= =?utf-8?B?OGNtOENQdEJnQW5kcVU5YXZQN21jSlRtNW9VcFFsNTIvSG1sL08xRHl3aXJJ?= =?utf-8?B?dWViVDFIaWJ0K001dlB4dWVRckg3LzQwRElBKytNalBLdGhHMXJlWnpUZk54?= =?utf-8?B?b3pYdWoyTGE5bTFQNFBhTVhSRi9HYVUwMENGQVJXSHNKaGdUdVZsMmNNdmRB?= =?utf-8?B?WE40TnlNZDZobFFESkVPK1R3NHNqVDZnSVo2TW9DT2RPbkY0bVlCeTJQRm1B?= =?utf-8?B?V0trNjg5by9FUmgreUdLNmZYSHk2S0pESVJUT3dPTDA5aUdqTWNsak96cG5M?= =?utf-8?B?L3RGeVZ3NEVEZWoxa3BCSVBCVDU1UTh5M2ZYUVhYNTl6R3hla0tBZlMwcTJQ?= =?utf-8?B?dTZwWjhNVUtlSGR3d29YOUJ3bmRyemZlaitDcHdaL2ZKdmJZeUg3T1R5YXFO?= =?utf-8?B?STlZNFdFM2Y2VTZ0SWN3eExkRFpBcThyUk85UTZodzlhUHhmbEZ6NXFDY1Fh?= =?utf-8?B?blprVGcyeW5SR2RkOUN0Mk5KTGJJS09pakFmNVB1b01pWEhKSk9rMzNoeWU3?= =?utf-8?B?VW9lMDQ2MDltaXJVa0I1OXBETU5rM3JjeU4yREhYS3VDU2JiaENyQ3VWelMy?= =?utf-8?B?cCtrWmtJUXdpNHpNRFMwNnJ6LzZYS2ppYytqNXhDamxxSFZUbXZSK2ZwWDV0?= =?utf-8?B?dkFxQ3pmWDZMOEtycTNKS2tNeTd1RTdYYktoSTM2VGlQaEh1cysxckJibWdD?= =?utf-8?B?RUlNUE9VeHZmenNWTmE3Yk8vd2s5c3VpZTU4NDY2QlpBMW9LM2laUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 99a629ba-d981-43aa-c83e-08de5e6afac6 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 12:44:30.1796 (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: VYV/68a8A7y+RYQLV1mq6dmwPGXz3KB6ndYvTSVkVBbeTMu16LKcRLvJ82F026NMpMCnJg6GLE36YAiVYuqSN28ERZswMi6PbCeMqebH3iE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR03MB6062 On 28/01/2026 12:03 pm, Roger Pau Monne wrote: > diff --git a/xen/common/domain.c b/xen/common/domain.c > index 376351b528c9..123202f2c025 100644 > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -710,6 +710,23 @@ static int domain_teardown(struct domain *d) > return 0; > } > > +/* > + * Called multiple times during domain destruction, to attempt to early free > + * any stashed pages to be scrubbed. The call from _domain_destroy() is done > + * when the toolstack can no longer stash any pages. > + */ > +static void domain_free_pending_scrub(struct domain *d) > +{ > + rspin_lock(&d->page_alloc_lock); > + if ( d->pending_scrub ) > + { > + FREE_DOMHEAP_PAGES(d->pending_scrub, d->pending_scrub_order); > + d->pending_scrub_order = 0; > + d->pending_scrub_index = 0; > + } > + rspin_unlock(&d->page_alloc_lock); > +} > + > /* > * Destroy a domain once all references to it have been dropped. Used either > * from the RCU path, or from the domain_create() error path before the domain > @@ -722,6 +739,8 @@ static void _domain_destroy(struct domain *d) > > XVFREE(d->console); > > + domain_free_pending_scrub(d); > + > argo_destroy(d); > > rangeset_domain_destroy(d); > @@ -1286,6 +1305,8 @@ int domain_kill(struct domain *d) > rspin_barrier(&d->domain_lock); > argo_destroy(d); > vnuma_destroy(d->vnuma); > + domain_free_pending_scrub(d); > + rspin_unlock(&d->page_alloc_lock); This is a double unlock, isn't it? The freeing wants to be in domain_kill() (ish), or _domain_destroy() but not both. In this case we can't have anything using pending scrubbing until the domain is the domlist (i.e. can be the target of other hypercalls), so this wants to be in domain_relinquish_resources()  (rather than domain_kill() which we're trying to empty). In principle we could assert that it's already NULL in _domain_destroy() which might help catch an error if it gets set early but the domain destroyed before getting into the domlist, but that seems like a rather slim case. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jan 28 12:54:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 12:54:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215649.1525781 (Exim 4.92) (envelope-from ) id 1vl53a-0001Qz-VL; Wed, 28 Jan 2026 12:54:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215649.1525781; Wed, 28 Jan 2026 12: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 1vl53a-0001Qs-Sd; Wed, 28 Jan 2026 12:54:02 +0000 Received: by outflank-mailman (input) for mailman id 1215649; Wed, 28 Jan 2026 12:54: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 1vl53Z-0001P1-5m for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 12:54:01 +0000 Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [2a00:1450:4864:20::434]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6a68ea07-fc48-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 13:54:00 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-4359a16a400so6090543f8f.1 for ; Wed, 28 Jan 2026 04:54:00 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e10ee057sm7647392f8f.15.2026.01.28.04.53.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Jan 2026 04:53:58 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6a68ea07-fc48-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769604839; x=1770209639; 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=pxnMsEq8qw7T+oqrKwi95udvWlS0pld5Lx9vUqLRgf0=; b=TRxqwU/DaoBTDJJsnTij4/Rz11v0vufOhnXNcATfmykTHtnnAqwazyDJq5w7ola2l/ O6c5f78VBMYqQ9uJ+AruHhpSsbdSlUY2GghCr93Qd9W8itHX0F3yrgvPwVmmiI3f7i65 naZvDcH2A4V0UDffNy93maOGWQfRo0pFLKS5QkW4ZTGKBU9n0XCY/M9tvhuioaFYcaQx x7m8LbzUUomxSUdfA3TmUcY8sRn6lA9YSXdOHqNkNWjnq8x0jwXzXXEDOt6/404uBmHy 6FxxlteTUTBEau3VoMWyS2oat/3k2TUoRNcMKk3jdx5pPaxcDvXZIK0ko15wIVwqvEZZ U0tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769604839; x=1770209639; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=pxnMsEq8qw7T+oqrKwi95udvWlS0pld5Lx9vUqLRgf0=; b=QCEMdEyTKbs/6JQzyG4t5PvOwTCGn9aRe+dKDt4+1DR4Lc4dFA37ILRLKuo2g+UW0+ hMmd+RJL+JJ+beTEePAiG0G7e+S4L9EHknEZT9fiAYlODA6vrN7UaF/AAPYOHqOIRNY8 qreoRh0A7II/VNuAlcYfEpU0YTstz3HL+FQRsP+e2W+2yiLeSyKGXm2OUroOoG5xBmYO bqXvHIcvugOq2b2B2sweJXAbIU8FqwpO8OwnFW9u6I7IHJ2S6/yz20W9WZ38J5f8oo9u E8/NM7w3rYADoEkgEl/cqXURXYTVrCC02IBmt1oac1pxggG5s75gNzfVMECgSPj5BXUK cJFA== X-Gm-Message-State: AOJu0YxJb9aRUikH/rBHKClVCpa3+VVfQeJSCkBMOelQGpYStjlha6yT aY3n9MaDT7LSqG7QPEHmUyooK8zSrfoKnFx39nS0/asHOZX3LRGPJ7zSYivGQA== X-Gm-Gg: AZuq6aKbBpmweRUY6XKuTwWjav3oV0Tz18Vqvh3D/SH3TZT/d1kHbksUo8uh59b+FaV 98XVExdWR28rfrk0nycxQKhgAyyLIxLhXXr9GDDeLs+JW9v12HBGmLPH/0e5XmmAcDnElU3AfUs dbdjshqsRtaGGCQYzKAyvIpP5knEOuwz3tJg7ONTSbBDLK32gw1k0rn06hYTjOyQy1bNft5PH3u 0TMB9iG6Vbomb4nPaYZEYjeJGPS2KMKXQ9emZeT5/x9BNruh/bpoihVFTZ13rV66qJdANv1xOev lm2wl0s2BXmd9ib494hqhl0BsDhYIaphEsYBpxkP6bpUHF81ithdi+UiNQY8ucZBNlr1UdTMbnG +XQtU9UwclucT8pIADM24ukocHCWOa0NNH6nC4kBgTkm53lmx5RNA7p6G5GnEifUcDr3CnhczWF YmHfK9KfgRXf1Z+2+gH8Mzl4thzCV8gc8hNo9m5oDRBjOU3YOSediKyg== X-Received: by 2002:a05:6000:1843:b0:432:c0e8:4a33 with SMTP id ffacd0b85a97d-435dd073639mr7289844f8f.22.1769604839270; Wed, 28 Jan 2026 04:53:59 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v5] xen/riscv: dump GPRs and CSRs on unexpected traps Date: Wed, 28 Jan 2026 13:53:48 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Provide additional context when an unexpected exception occurs by dumping the relevant Supervisor, Virtual Supervisor (VS), and Hypervisor CSRs, along with the general-purpose registers associated with the trap. Dumping VS-mode CSRs in addition to host CSRs is beneficial when analysing VS-mode traps. VSCAUSE, VSEPC, VSTVAL, and related VS state are required to properly diagnose unexpected guest traps and potential hypervisor misconfiguration. For example, on an illegal-instruction exception the hardware may record the faulting instruction in VSTVAL. If VSTVAL is zero, VSEPC should always be inspected, and can be used together with objdump to identify the faulting instruction. Dumping VSCAUSE is also useful when the guest does not report it, or when the hypervisor redirects a trap to the guest using VSCAUSE, VSTATUS, and VSTVEC, allowing verification that a subsequent trap is not caused by incorrect VS state. Signed-off-by: Oleksii Kurochko --- CI tests: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/2291514286 --- Changes in v5: - Drop duplication in do_unexpected_trap() as dump_csrs() prints the similar message. - Drop twice loggong of SEPC. - Drop scause argument and add ctx string argument for dump_scrs() to print a context where dump_csrs() was called. --- Changes in v4: - Drop macros GPR_LIST and CSR_LIST. - Drop leading tab identation in printk() inside X macros. - Drop semicolon after printk in X macros. - Group print of htval and htinst, and HEDELEG and HIDELEG. - Put printing of hypervisor register first. - Add printing of missing GPRs: t5, t6, sepc. --- Changes in v3: - Refactor the code dumping of CSRs and GPRs: - Introduce new macros - Re-group some registers when values are displayed. - Print all registers name in lower case. - Drop unnessary "Dumping CSRs", "Dumping GSRs" as it is clear based on names. - Update the commit message: add justification of dumping of some VS* registers. - Drop printing of VSSATP as I don't know usecase for now where it could be needed. --- Changes in v2: - Address coments about print_csr() macros and dump_csrs(). - Add dumping of GPRs pertaining to the trap. --- xen/arch/riscv/traps.c | 60 +++++++++++++++++++++++++++++++++++++++--- 1 file changed, 57 insertions(+), 3 deletions(-) diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c index e9c967786312..b72e6ef7eb35 100644 --- a/xen/arch/riscv/traps.c +++ b/xen/arch/riscv/traps.c @@ -99,11 +99,65 @@ static const char *decode_cause(unsigned long cause) return decode_trap_cause(cause); } -static void do_unexpected_trap(const struct cpu_user_regs *regs) +static void dump_general_regs(const struct cpu_user_regs *regs) { - unsigned long cause = csr_read(CSR_SCAUSE); +#define X(regs, name, delim) \ + printk("%-4s: %016lx" delim, #name, (regs)->name) + + X(regs, ra, " "); X(regs, sp, "\n"); + X(regs, gp, " "); X(regs, tp, "\n"); + X(regs, t0, " "); X(regs, t1, "\n"); + X(regs, t2, " "); X(regs, s0, "\n"); + X(regs, s1, " "); X(regs, a0, "\n"); + X(regs, a1, " "); X(regs, a2, "\n"); + X(regs, a3, " "); X(regs, a4, "\n"); + X(regs, a5, " "); X(regs, a6, "\n"); + X(regs, a7, " "); X(regs, s2, "\n"); + X(regs, s3, " "); X(regs, s4, "\n"); + X(regs, s5, " "); X(regs, s6, "\n"); + X(regs, s7, " "); X(regs, s8, "\n"); + X(regs, s9, " "); X(regs, s10, "\n"); + X(regs, s11, " "); X(regs, t3, "\n"); + X(regs, t4, " "); X(regs, t5, "\n"); + X(regs, t6, " "); + +#undef X +} + +static void dump_csrs(const char *ctx) +{ +#define X(name, csr, fmt, ...) \ + v = csr_read(csr); \ + printk("%-10s: %016lx" fmt, #name, v, ##__VA_ARGS__) + + unsigned long v; + + X(htval, CSR_HTVAL, " "); X(htinst, CSR_HTINST, "\n"); + X(hedeleg, CSR_HEDELEG, " "); X(hideleg, CSR_HIDELEG, "\n"); + X(hstatus, CSR_HSTATUS, " [%s%s%s%s%s%s ]\n", + (v & HSTATUS_VTSR) ? " VTSR" : "", + (v & HSTATUS_VTVM) ? " VTVM" : "", + (v & HSTATUS_HU) ? " HU" : "", + (v & HSTATUS_SPVP) ? " SPVP" : "", + (v & HSTATUS_SPV) ? " SPV" : "", + (v & HSTATUS_GVA) ? " GVA" : ""); + X(hgatp, CSR_HGATP, "\n"); + X(hstateen0, CSR_HSTATEEN0, "\n"); + X(stvec, CSR_STVEC, " "); X(vstvec, CSR_VSTVEC, "\n"); + X(sepc, CSR_SEPC, " "); X(vsepc, CSR_VSEPC, "\n"); + X(stval, CSR_STVAL, " "); X(vstval, CSR_VSTVAL, "\n"); + X(status, CSR_SSTATUS, " "); X(vsstatus, CSR_VSSTATUS, "\n"); + X(satp, CSR_SATP, "\n"); + X(scause, CSR_SCAUSE, " %s[%s]\n", ctx, decode_cause(v)); + X(vscause, CSR_VSCAUSE, " [%s]\n", decode_cause(v)); + +#undef X +} - printk("Unhandled exception: %s\n", decode_cause(cause)); +static void do_unexpected_trap(const struct cpu_user_regs *regs) +{ + dump_csrs("Unhandled exception"); + dump_general_regs(regs); die(); } -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Wed Jan 28 12:55:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 12:55:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215657.1525792 (Exim 4.92) (envelope-from ) id 1vl55B-0001vZ-Aq; Wed, 28 Jan 2026 12:55:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215657.1525792; Wed, 28 Jan 2026 12: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 1vl55B-0001vS-6A; Wed, 28 Jan 2026 12:55:41 +0000 Received: by outflank-mailman (input) for mailman id 1215657; Wed, 28 Jan 2026 12: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 1vl55A-0001vK-69 for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 12:55:40 +0000 Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [2a00:1450:4864:20::429]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a0f1f4e4-fc48-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 13:55:31 +0100 (CET) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-4327790c4e9so4458443f8f.2 for ; Wed, 28 Jan 2026 04:55:31 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e1354205sm6995055f8f.41.2026.01.28.04.55.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 04:55:30 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a0f1f4e4-fc48-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769604931; x=1770209731; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=h74UoF0SijPHnORtEHxcuIiFSQ9TsSqqGD9YLiB94jM=; b=M+ye61hsOg3jR8dH1JbzuRxrj3PTPpQpmJSoAwJiq9ZorhgFaSAKMX+OUyoc7jsCyw 7nY4bEiVA/Q+/rn8Lwq2pIJAuIye/cffwbU+rzzRdww4brddomvTxFj4wblvwyWrozvA S5lZPEGKZ7u8Z+wo39TXvULWkNbExkvLMuOjXGI5BnKXHLzwlCl7NFRuhDPb6BeH6LQe 3zHRNbnxpEdZhS+y2y1lf/w8kTWyO76UNfSgkQTWiFSRzdsgeOiXKGmT0C+ZkBsHUSoC NoOXL5MpC4S7d3j/MBMfXJ9R0lG9aAVmWDv76/norotVis728rEKTO7NFFkH6hwttJRe S+/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769604931; x=1770209731; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=h74UoF0SijPHnORtEHxcuIiFSQ9TsSqqGD9YLiB94jM=; b=RLnKCyxsH2ChHXOQQtvha1A0OpN8E4Q/nBetvPxvMIuxUruXDHrdQoq3c5fSPGC2is zzkPBIm8l5vs2MkZsdtVt1plsoGhloCkFiTg4qSyFar8Cv2G88YKn0geZMO0SjUVuPUc jBjIHa/6sNQ1p7XDMdWtGAnIIam4J3D0rTx+IhuAGvM/jaVEqEFiPRTe1N2SLOkCTkpJ DOBa8jP0jyFEVYEICJHyLDwKbgWx2sg9ybdwYLVe2aQfntu2xS0vxGu2TjeEZJxTa5of g1Fg19VCyn01n1+YZuhXOkxdC89+usqMozs+nrlMUEhptOrGEvRzDjKeufPDXYgoGx0y HySQ== X-Forwarded-Encrypted: i=1; AJvYcCUWoUemjsR/KKeCSsA1uOJFFqwmLS0xI2WQt5ytY2tiLjp1USSc1FquaLu0BJ8qg5v4+hW149jAOTE=@lists.xenproject.org X-Gm-Message-State: AOJu0YyW/CTvH6pCrG3qeZdkvJG5oovjvyvarq+/al992/7W0qjiyurK N7f8/x4ttUV2UotDF5T8x3vJDDsWUQvFOEaDz1p2ZGqXFXHjz+SR1vsSh2RYm5J3HA== X-Gm-Gg: AZuq6aJw/RXXn7z8I5bZRHvZr8uXl//zJ/8mfNbYJP+1zm7sxyCw6d+mBpdPEVE8qoV sYJCIHDraay3i5b8fpLrNqqUztxSuTHXTfmRvN0LboMROX1LFR3nlkA9ZWv/ET9TPflepJqtwbH mHUbj7r9JWB9HxEzx9Kop2T9B7v+XwxVB9lCXYeaohjLEZ0Fl3ErZvRwGMRtpfd7a2cuO3+4By6 b/1IOHFiV0U/i5MO+QTPRVySXdfT8dw+TlH7K4sxd0yXaAKgyW3m4iwqJDUPhwSueE6RMyAYCiJ 2/IeOGHzDgiklwqCCoCtn50ZFRGx1Hv6CXItr2oqOtXILTRXWpq0cdAMJGyDzLcMUZ0T/IL3+BE LQWM8FS1O9Nn2++V6EHfnlWqPmg11FrG9glEeRz3qezPknleQLL7lk2j5wmB8IAAMPk7lS7BA1X EJYYPhGslEVEZTeDwBxT9BrLVw+tRSI6hPfr9JLugwsZoRWsSvNV57Rbg46ODO1BT7yqLLLAQu2 YI= X-Received: by 2002:a05:6000:40cd:b0:435:91b8:e01b with SMTP id ffacd0b85a97d-435dd1cd103mr7866643f8f.45.1769604931153; Wed, 28 Jan 2026 04:55:31 -0800 (PST) Message-ID: Date: Wed, 28 Jan 2026 13:55:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 1/2] xen/console: handle multiple domains using console_io hypercalls To: Stefano Stabellini Cc: grygorii_strashko@epam.com, anthony.perard@vates.tech, michal.orzel@amd.com, julien@xen.org, roger.pau@citrix.com, jason.andryuk@amd.com, victorm.lira@amd.com, andrew.cooper3@citrix.com, sstabellini@kernel.org, xen-devel@lists.xenproject.org, Daniel Smith References: <20260123010640.1194863-1-stefano.stabellini@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260123010640.1194863-1-stefano.stabellini@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23.01.2026 02:06, Stefano Stabellini wrote: > @@ -555,8 +561,11 @@ static void console_switch_input(void) > > if ( next_rx++ >= max_console_rx ) > { > - console_rx = 0; > printk("*** Serial input to Xen"); > + nrspin_lock_irq(&console_lock); > + console_rx = 0; > + serial_rx_cons = serial_rx_prod; > + nrspin_unlock_irq(&console_lock); > break; > } > > @@ -575,8 +584,12 @@ static void console_switch_input(void) > > rcu_unlock_domain(d); > > - console_rx = next_rx; > printk("*** Serial input to DOM%u", domid); > + nrspin_lock_irq(&console_lock); > + console_rx = next_rx; > + /* Don't let the next dom read the previous dom's unread data. */ > + serial_rx_cons = serial_rx_prod; > + nrspin_unlock_irq(&console_lock); > break; > } As in both cases you're also moving console_rx updates into the locked region, what about readers of the variable, first and foremost console_get_domain()? Else why the movement? Also I think that the printk()s would better be last, indicating the completion of the switching. > @@ -605,8 +618,10 @@ static void __serial_rx(char c) > * Deliver input to the hardware domain buffer, unless it is > * already full. > */ This comment goes stale with the buffer being used for whichever is the focus domain in do_console_io(). > + nrspin_lock_irq(&console_lock); > if ( (serial_rx_prod - serial_rx_cons) != SERIAL_RX_SIZE ) > serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c; > + nrspin_unlock_irq(&console_lock); I don't think you can unconditionally enable interrupts here, as this may be running in the context of an IRQ handler. > @@ -742,17 +758,36 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, > if ( copy_from_guest(kbuf, buffer, kcount) ) > return -EFAULT; > > - if ( is_hardware_domain(cd) ) > + /* > + * Take both cons->lock and console_lock: > + * - cons->lock protects cons->buf and cons->idx > + * - console_lock protects console_send and is_focus_domain > + * checks > + * > + * The order must be respected. guest_printk takes the > + * console_lock so it is important that cons->lock is taken > + * first. > + */ > + spin_lock(&cons->lock); > + nrspin_lock_irq(&console_lock); > + if ( is_focus_domain(cd) ) Why would any of the domains possibly being permitted to be "focus" suddenly gain direct access here? Full access in do_console_io() is still prevented by the XSM check there, afaict. Cc-ing Daniel, as it's not quite clear to me whether to introduce another XSM check here, whether to check ->is_console directly, or yet something else. > { > + if ( cons->idx ) > + { > + console_send(cons->buf, cons->idx, flags); > + cons->idx = 0; > + } > + spin_unlock(&cons->lock); > + > /* Use direct console output as it could be interactive */ > - nrspin_lock_irq(&console_lock); > console_send(kbuf, kcount, flags); > nrspin_unlock_irq(&console_lock); > } > else > { > char *kin = kbuf, *kout = kbuf, c; > - struct domain_console *cons = cd->console; > + > + nrspin_unlock_irq(&console_lock); > > /* Strip non-printable characters */ > do > @@ -765,7 +800,6 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, > } while ( --kcount > 0 ); > > *kout = '\0'; > - spin_lock(&cons->lock); > kcount = kin - kbuf; > if ( c != '\n' && > (cons->idx + (kout - kbuf) < (ARRAY_SIZE(cons->buf) - 1)) ) > @@ -815,6 +849,13 @@ long do_console_io( > if ( count > INT_MAX ) > break; > > + nrspin_lock_irq(&console_lock); > + if ( !is_focus_domain(current->domain) ) > + { > + nrspin_unlock_irq(&console_lock); > + return 0; > + } To avoid the extra unlock-and-return, how about simply setting "count" to 0, leveraging ... > rc = 0; > while ( (serial_rx_cons != serial_rx_prod) && (rc < count) ) ... the rhs check here? > @@ -824,14 +865,28 @@ long do_console_io( > len = SERIAL_RX_SIZE - idx; > if ( (rc + len) > count ) > len = count - rc; > + nrspin_unlock_irq(&console_lock); This can be moved up a few lines, as none of the local variable manipulations needs guarding. > if ( copy_to_guest_offset(buffer, rc, &serial_rx_ring[idx], len) ) > - { > - rc = -EFAULT; > - break; > - } > + return -EFAULT; > rc += len; > + > + /* > + * First get console_lock again, then check is_focus_domain. > + * It is possible that we switched focus domain during > + * copy_to_guest_offset. In that case, serial_rx_cons and Please can you append () to the function name, to identify it as a function, as opposed to ... > + * serial_rx_prod have been reset so it would be wrong to > + * update serial_rx_cons here. Get out of the loop instead. ... the two variables referenced here? Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 28 13:33:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 13:33:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215683.1525802 (Exim 4.92) (envelope-from ) id 1vl5ft-0007ai-53; Wed, 28 Jan 2026 13:33:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215683.1525802; Wed, 28 Jan 2026 13: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 1vl5ft-0007aa-0l; Wed, 28 Jan 2026 13:33:37 +0000 Received: by outflank-mailman (input) for mailman id 1215683; Wed, 28 Jan 2026 13:33: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 1vl5fr-0007aU-1N for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 13:33:35 +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 ee33d83a-fc4d-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 14:33:29 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SJ0PR03MB5520.namprd03.prod.outlook.com (2603:10b6:a03:282::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.8; Wed, 28 Jan 2026 13:33:26 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.006; Wed, 28 Jan 2026 13: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" X-Inumbo-ID: ee33d83a-fc4d-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AOuaqmxMSqV4M8pnYuukAS0C3gyazbqJouyKKrKM0JAXul3ocjMJyPuXG4K9nzLOyWcFdauiZhGPA5/fELMEu4OD1W9uaC0lu57FtpUUsT0el/Le61D1XHSh9fikPn4HWxmy1mO9EWqbJ+BA/NdOqcd1v6dqCaLdXX2pt0PMfrW3JVIo6EbE0aPiqKv9tWyIvsHB1rNJRrQaQa6qOlNgKCIipkFly80K6Z6jq6ZCjE5ypADXsF8wvce/Y6IXAp7VKIBsmvVO8jAgwTCV7Sx0uqttkejtfOKsptauae30X9eqn/zYhyDS0UGBQKi2NpLbamvwrZ+MYKrvBdTTWkxDLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6Ygq6H/0KAv8iQEjAFOVh5VN1R5UL+Jzjwf0+0SIwmE=; b=c9SLD1oaY8cosvDLAXSak1n5ghj2LztOcub+rGdKuf10jaPx7cDz75FGAa3D+Y5DYPzathVrVccgwOVPphuQj6uqZbOlWcb+Rg0NJKZcfVmz/HG2jP4AlXgzmA7qWIO79LKlBvDGANB4u6wPWMTf6rkPtBPjoycYr+Rqt26V+MNSVe+pzi5ARG3J8g9sjUhG/AjOEMHK471TbdNn3bj1Nij4WrPaqD5OWddl9LBh2n+jKA1ViIwCHN+mH3oqAO3dix4N4I7TPOoigYeyzc0MIYPgHFw9E4sIK0WNU5mhKjqhPFNpJEpqptz/GmJOyojidhQWSRq+oBcrwo/ZeV2LyA== 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=6Ygq6H/0KAv8iQEjAFOVh5VN1R5UL+Jzjwf0+0SIwmE=; b=FnTnAb9awzp7JqFK9izxZfBdK3IFF9sBespcTizIX/IxjU7n9Go8YzFcqgKFK06wbsg4vvaYxzpNJTNeh6FDJOL2hnc3rMil0yEuWZwF2Ou+nxCO/wAURn3iLHE60aPo3VjWVu2o9fpem6iXxAdTv/5UFOdYMHR96SC6djtLip4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 28 Jan 2026 14:33:16 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Cc: xen-devel@lists.xenproject.org, Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: Re: [PATCH v4 2/3] xen/mm: allow deferred scrub of physmap populate allocated pages Message-ID: References: <20260128120339.47373-1-roger.pau@citrix.com> <20260128120339.47373-3-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: MR1P264CA0057.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:3e::12) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SJ0PR03MB5520:EE_ X-MS-Office365-Filtering-Correlation-Id: 0551c1cb-8d7e-4fa0-5499-08de5e71d0db 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?b1M3WFRqQWZuVzhTdnhUblFqUU9GRTRaTVdkZE82Qk5hVmE4Z2kwek1pN3lK?= =?utf-8?B?b2VOODl6bWorVTJGNGlUQ0Z1WStxMEp5TzEyVEwvQUxoWXZVRzU3UFJNcnhC?= =?utf-8?B?TFBJT2lMY0lod2pTdW1yT0dpMElqVEVFd2tScnNQNUdTWUhMMGlRT0pPbVNz?= =?utf-8?B?R0tXaUlwTHExaFlTYWd4UjFpZVl0MW9RZlhaV3UzYXhEa3ZKdXJzTHpRcTZr?= =?utf-8?B?S25wRXJFRjRYRzBhZ0pJVDB4U3k3UW9jRm9RYUhHUzU2bW1XM1ZCck00R05p?= =?utf-8?B?MHhydm9WSEU5ZElFcDVaWWZtRnEwSFY2V2FhNjZHbnpQVFBwb25MUlQ3cWd1?= =?utf-8?B?SXByOXNDQ1JlUDIrUGZ0bkhJSkkwOXRpR3RVR2Q2SzJudUlYRUU4NzVOZ2xw?= =?utf-8?B?c0ljbWZHTjBHdFUxYlRDYjIyWUJQTXNFWHFrakFHYVRpVmRwaEpUT1NjbE5k?= =?utf-8?B?cGhhSWt4KzlBSGg1bHlRcFhmWEwrdDRycjJvVytVbU5EK1JxY3dRN29SVnR0?= =?utf-8?B?NzZJeFFsSldFVGVuNGZQZXh4N1F1a01xQ3BWekNwNDNZRjJyNllSSWdOck1h?= =?utf-8?B?aEJZVFVKZmFuVWZOdkl6QWcxS3hJOERZQVZPTHNjZG9OdVpIOElSalhQckox?= =?utf-8?B?ZjlGLzBTbzkydEdSQXJnNDgrOE45aHVwajhHTUduNm1HdWFQRWQrK2t2S0dD?= =?utf-8?B?T3I1NjZUZ2ppSkdPSzZkWVM3UEoraDdsMkNKeUhiRkhReHJleFZEL3dvcUlq?= =?utf-8?B?M1lONFFPbTlhTXBnc0Q1Vm5hcENaRVIxeERKcm1NczZsMDBzYWFYSjMxQndO?= =?utf-8?B?Z2twT0pQTnJQVUtXYWt1Q29ZdWw0UmVwOVg1Qk9MaXc4bmh5TTQvaWVKNVN3?= =?utf-8?B?SDVocUo4OHlWRVZIZE1HZjl6d25DL3RvMjUwSGN4bUI5K1hyclFUakk0cEcz?= =?utf-8?B?SHNLTlBjaG1YcUNIUkhzR0RtVndCeEtPSUp4QTVZSFdqYlo0RmliSFkrUzVN?= =?utf-8?B?SFVLdzBuOGZGd2M2bE9qTXF1SEcvOU52Z3dER1NDb1dhbHFnaEhNaW01SlFv?= =?utf-8?B?dWdCWTBOUzczbDE1Y1o3QWpMMzN4eDk5dHp6d0oxbjBRaFFtSTA5Qkg1bDJW?= =?utf-8?B?QVpJZnBNUmZzdkNvN1RTbzR0WHI5bzVOcjE5Z2FrMmc3c1RJd09hd3Vjc0Y1?= =?utf-8?B?aW5ZYmJpc2FNem9xT29CZEYwNDI0cm5GUHNUQ3NJWEh0Um9PY2Z3MlI2WGJM?= =?utf-8?B?NUdOK0hMZFdGclpvSHVGN1BYVEhhMGpGbURnSG9vYXZhaUN4WWVocDNSQ3Z1?= =?utf-8?B?ZjAycnpWalJLRlB0QUtoLzF1MDhNUlNXeUlMeGs5ZmJRZncybUlnSzIxa0VY?= =?utf-8?B?dEdkc3h1M3BOc3k1ZS90R1BtaWh1S2tCYTVkQ0krRzBQSFpYaEx1WnJGSmsy?= =?utf-8?B?WnlZcjVuajF6NzZoL3FFdlNRYTFoZGkzdlliOUQzSGUyT01LTFh1ZXJsWGsv?= =?utf-8?B?d3BTdUhTVmEvRWIyQXllSmY1cmRjUDZXYSs0TVlaRDgrc2dPSUhZenNJQUty?= =?utf-8?B?SFFlT095UU9KWmlPbVNhY3pvbzB3SWxTdTF4RDdpL2V0bUFEQ0FnVnliL3Vs?= =?utf-8?B?c2tmZHZxdnEvclJLUzJYZkphSHFVUTNRMDc0bEcvTHYya3o0QzhMbEtUbllH?= =?utf-8?B?eTVhNjd3M1poNFczbW9VY1l3N3A0TE9mMXlVdUFFWnRoY2FiWjhOMHBiS2Fy?= =?utf-8?B?dEtmYmlxRE5hak5obmZNQzdjSmxLTjBUcXJnVHVSZzk2b3RIbXRORXMxYjlJ?= =?utf-8?B?VFMxUFkzRUM1a3JhY25mMGdwYWEybjF5bFVCNnk0dG5HbytXVjNjUjcwVXBG?= =?utf-8?B?aWdpSzVZSC9sVmlhR3VLOGE3YVEvV0N1SUZsOUlWaFJsa3BIK0wxR1BIdTFI?= =?utf-8?B?MElTWHdUUnRHOTNxOElzdk5kQllPTTJlTm1OSFIzcDc5K01paEY3ODllVi9w?= =?utf-8?B?QnY2a2Q5bUZqejNQd0ZvN2VuQVdHVGVKbmtWSTZLbkFGd1cwaTFrSmdLMjEv?= =?utf-8?B?R2loQ3hhZWVDbVlLZHYrbGlUVkFtOXdVUVlGQ1ErcWxEZTUxa2JZNDhGM2xD?= =?utf-8?Q?1PNI=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?K0hEU291aXo5UzNnd1VyUmlYZlE1TVhSd3ZHbGx3Z1dCN0pXaDN2NG91WGR0?= =?utf-8?B?Z05keEF1S0ZublprQ2FhSXdLaGtWWUswbXZIcnBOWHpvQkhtbWxMeWhITzVG?= =?utf-8?B?bG5kVDBHUTFKbWg5azR6T3NjZnR6VGRBekJDbUYrY0dtcXdiTW4vQTZQMVY5?= =?utf-8?B?eTRMZXlVbFdvNFEwckw3TW1RUkZrVjVJb2pkemVkakpaVllheUVtWE5QUk1G?= =?utf-8?B?c3ArWFUyR2xPVitJZlJXSmVQODlLbnNVbEEzZldvYjRyd0tNTHg0dEtBcVp1?= =?utf-8?B?MlNaek16MStNU3hnMlRZTEVoV2xacFAxdTBVTkpUMXRXa3VWcU5CdWlEbzU3?= =?utf-8?B?c3JvTGttM3NqTS8xN3liR0ZQYzVXRTdKZXAwN1Nkd3hQMGJPU0o2NjlKZmJU?= =?utf-8?B?SEUvcVJJVDBvL3F6SXlhbDRzMjBuMnQxMFk3UmZsOGJ0bE9KN1p1cnFIYS94?= =?utf-8?B?L29LM05jSXFvRGZaaEJvMHh1TW1qc1RFbTZsTGFubkJ4Rk42NmVYa1lmMUZl?= =?utf-8?B?cDA0bWQxaFNLbFNOTkk5aW1LUnRiL3FOQnBycEpYVk0rRUxTeVdIN2tlbkF1?= =?utf-8?B?S1FzV3FQRkRnZmdmSUVUQjFJcEFMMzBLYjZEVC9WeGEvNWYzOEYveUU2MXkr?= =?utf-8?B?cDd0dHBMZ2pObmcwN0h4aDJtUzgwMTRpY25OVk11ZnZTVWtYVnJjeHdlVUVM?= =?utf-8?B?WDlxTWRRc1k5NzFhVEFBWmVJOXRHZmZodkNFSVNxaVBjT2NkZ0FIOHFNV3pQ?= =?utf-8?B?cWZCVlpVWDZjanMweEQ0aHRLdUFzYXBRWHY5ZTBLY2tYbUh4V1pEQVdGNllh?= =?utf-8?B?SFZ0SjJ1MzZ4eVpKVlJZSXhFb1JSV3ZxYi9yVW9FbEt4SDlrN2kyQnpSQnZY?= =?utf-8?B?ZzM0TkpZdXNhaS94TENXdUhTNXlQM1JOblVwVjVyTldzU0ltZU5Td3kzeXRY?= =?utf-8?B?SmgwemZISWhIOGU4SXlJQmNwL0s4MlJKY3FxaHRJS09zemZRd2tidlJ6WlRT?= =?utf-8?B?bStGTjQ2anMxVStTMmtxSEJjR3VjeHNYTzJDSHc1ZkpJRE50V3V2dlhpdGZq?= =?utf-8?B?Q1FnUTg0Q25vRThCcDNmZ2dEVDhybGdsencyQWpKdXVLUjFmaEJCUExLbWNM?= =?utf-8?B?ZjNzUDVrUmtHL3lZMkFadUZySU42MHRtZlAxaEY2eWNmYVNkNHVUdCt2K2oz?= =?utf-8?B?eDkybTlIaEs1aUxkOEhOeEVaZDdvdi80N2dqaThuOGt1TlpNVXRvUFRSejRT?= =?utf-8?B?b1lWU2IwdURCMHJDVWlOVVRrWkp6MGw4SFowZzFnSFVuaEtkb0NxWENtWDAy?= =?utf-8?B?d1lZSS9ReFdsajVDL3ZIWmdNeHN1bnBFN0dTVnpXczdEbkVGMElIanhEenVR?= =?utf-8?B?cGZ4ZTZ0WnYxSmhNZDVpNFdMUjVrUUhEQkpCVG1vcmM5U1IvcVdza0t3UnU5?= =?utf-8?B?aFhWOUpFcUswbU02WmJtUnNwY0VJb1RZbUh4TitoS01IMXhWRU5iR0l5ZzBQ?= =?utf-8?B?R21hMDlCMXV6UTBKZEZ0ZUJiemlxUlQ0c01CNXAxME5YdDdNVzRheDd5UU41?= =?utf-8?B?Q3k0VUQ2UzVYSHR4U01xdnF6bFhNcXFKV0kwRXgvNHFDNW1iSkM4RTdBWGx1?= =?utf-8?B?eEJnT2Q1TmIvZmRLdkJ0eGZ1VEdScGl1YkVwV2t1M1VyRnBaelNxcEJoN0ZL?= =?utf-8?B?OVFFNHJpNGJ2aEM4WEhvN293Q3dxM3hKbUpWTG5Gd3NNcWt4T3lHdmZDaTZp?= =?utf-8?B?Zm5TTS9WdG56dE9LS3BybC9lZkM0SlZlbHhHcC8xVDdrRVI1Ri9HOW5lbENS?= =?utf-8?B?bC80ZmI5QXkyV1JROTU4OUZXeXJOdzFiL0JJSEFYcVFOQ2ZXQ1FpV2tZT1hj?= =?utf-8?B?M050UzBHYXdqU2RtdXZ2ME1TMlBuZSthUk5YaHpBakgxaTduZnl4RzQ1YlVk?= =?utf-8?B?U3MwWFF0dVFyanZvSDRKUHpNM0F6MUJrUFBoWVN6YzQyMGxvbmNkN3E2V0da?= =?utf-8?B?Zk85MGdhMm1vMDdRRVBMd2ZVVFFRMy9uRGJ3QVFGNzcxS3NjNFJYdGN0UjVt?= =?utf-8?B?MHJQbnR0bUFWVzlSOWxWWUo4cGtNWFdNeGxhK0svdW5adXBZRXV5Z2x5Rmx2?= =?utf-8?B?eXBPa2U3WmJVVVZCV1pDdWRPZkdiNzVIbGNnMHdya0RUMlg5RlppVnZRYTFP?= =?utf-8?B?WmRmOExDVThSeFF1NE9XQVViSmVsblVMaWE0cWZBSmJRYmxqZDgvMUNieHFk?= =?utf-8?B?SlJJNHczNmhPUm56eWJkM0lwOERHbFZXeWZkN2tHcFFDYWYydGt5aUpET3Jj?= =?utf-8?B?SkNKd200YUZHZmFha3V3aEN0cTNCSzhuUnpkS0UwUStTZTV6anVkZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0551c1cb-8d7e-4fa0-5499-08de5e71d0db X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 13:33:26.4317 (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: NXmLzDze2Kp9CGCB1wIDzIHD3EZXzBobYRfoB9b25eXcIQWGcDUpP/xON+h0LFCOcpnfb2cbhq9N83bgZlXHXA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5520 On Wed, Jan 28, 2026 at 12:44:26PM +0000, Andrew Cooper wrote: > On 28/01/2026 12:03 pm, Roger Pau Monne wrote: > > diff --git a/xen/common/domain.c b/xen/common/domain.c > > index 376351b528c9..123202f2c025 100644 > > --- a/xen/common/domain.c > > +++ b/xen/common/domain.c > > @@ -710,6 +710,23 @@ static int domain_teardown(struct domain *d) > > return 0; > > } > > > > +/* > > + * Called multiple times during domain destruction, to attempt to early free > > + * any stashed pages to be scrubbed. The call from _domain_destroy() is done > > + * when the toolstack can no longer stash any pages. > > + */ > > +static void domain_free_pending_scrub(struct domain *d) > > +{ > > + rspin_lock(&d->page_alloc_lock); > > + if ( d->pending_scrub ) > > + { > > + FREE_DOMHEAP_PAGES(d->pending_scrub, d->pending_scrub_order); > > + d->pending_scrub_order = 0; > > + d->pending_scrub_index = 0; > > + } > > + rspin_unlock(&d->page_alloc_lock); > > +} > > + > > /* > > * Destroy a domain once all references to it have been dropped. Used either > > * from the RCU path, or from the domain_create() error path before the domain > > @@ -722,6 +739,8 @@ static void _domain_destroy(struct domain *d) > > > > XVFREE(d->console); > > > > + domain_free_pending_scrub(d); > > + > > argo_destroy(d); > > > > rangeset_domain_destroy(d); > > @@ -1286,6 +1305,8 @@ int domain_kill(struct domain *d) > > rspin_barrier(&d->domain_lock); > > argo_destroy(d); > > vnuma_destroy(d->vnuma); > > + domain_free_pending_scrub(d); > > + rspin_unlock(&d->page_alloc_lock); > > This is a double unlock, isn't it? Bah, this was a leftover from the previous version, sorry. > > The freeing wants to be in domain_kill() (ish), or _domain_destroy() but > not both. Jan specifically asked for the cleanup to be in both. _domain_destroy() is the must have one, as that's done once the domain is unhooked from the domain list and hence can no longer be the target of populate physmap hypercalls. Jan asked for the domain_kill() instance to attempt to free the pending page as early as possible. > In this case we can't have anything using pending scrubbing until the > domain is the domlist (i.e. can be the target of other hypercalls), so > this wants to be in domain_relinquish_resources()  (rather than > domain_kill() which we're trying to empty). domain_relinquish_resources() is arch-specific, while the pending_scrub stuff is common with all arches. It seemed better placed in domain_kill() because that's generic code shared by all arches. I could place it in domain_teardown() instead if that's better than domain_kill(). > In principle we could assert that it's already NULL in _domain_destroy() > which might help catch an error if it gets set early but the domain > destroyed before getting into the domlist, but that seems like a rather > slim case. Given my understanding of the logic in the XENMEM_ hypercalls, I think toolstack can still target domains in the process of being destroyed, at which point we need to keep a final cleanup instance _domain_destroy(), or otherwise adjust XENMEM_populate_physmap hypercall (and others?) so they can't target dying domains. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 28 14:23:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 14:23:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215707.1525823 (Exim 4.92) (envelope-from ) id 1vl6Rj-0005az-Rk; Wed, 28 Jan 2026 14:23:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215707.1525823; Wed, 28 Jan 2026 14:23:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl6Rj-0005as-Os; Wed, 28 Jan 2026 14:23:03 +0000 Received: by outflank-mailman (input) for mailman id 1215707; Wed, 28 Jan 2026 14:23: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 1vl6Ri-0005aL-KY for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 14:23:02 +0000 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d8dac13a-fc54-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 15:23:00 +0100 (CET) Received: by verein.lst.de (Postfix, from userid 2407) id B7173227AAC; Wed, 28 Jan 2026 15:22:55 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d8dac13a-fc54-11f0-9ccf-f158ae23cfc8 Date: Wed, 28 Jan 2026 15:22:55 +0100 From: Christoph Hellwig To: Roger Pau =?iso-8859-1?Q?Monn=E9?= Cc: Christoph Hellwig , xen-devel@lists.xenproject.org, Jens Axboe , Keith Busch , "Martin K. Petersen" , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Sagi Grimberg Subject: Re: [PATCH] nvme-pci: fix parameter order in nvme_free_sgls() call Message-ID: <20260128142255.GA3210@lst.de> References: <20260127195907.34563-1-roger.pau@citrix.com> <20260128084958.GB9373@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) On Wed, Jan 28, 2026 at 10:10:08AM +0100, Roger Pau Monn wrote: > > > the root device as part of a kernel update is unexpected. Sadly 6.18 > > > already contained this issue, and no-one noticed, so its impact is limited? > > > > This only affects non-IOMMU paths with a non-noop dma_unmap_phys. > > So it is a very common setup, but very severe for those. Because of > > Do you mean a "not very common setup"? Otherwise I can't parse the > sentence. Yes, sorry. From xen-devel-bounces@lists.xenproject.org Wed Jan 28 14:27:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 14:27:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215717.1525833 (Exim 4.92) (envelope-from ) id 1vl6Vu-0006AS-Au; Wed, 28 Jan 2026 14:27:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215717.1525833; Wed, 28 Jan 2026 14:27:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl6Vu-0006AL-7m; Wed, 28 Jan 2026 14:27:22 +0000 Received: by outflank-mailman (input) for mailman id 1215717; Wed, 28 Jan 2026 14:27: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 1vl6Vs-000694-N3 for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 14:27:20 +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 71250511-fc55-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 15:27:15 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by PH0PR03MB6955.namprd03.prod.outlook.com (2603:10b6:510:172::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Wed, 28 Jan 2026 14:27:09 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.006; Wed, 28 Jan 2026 14:27: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: 71250511-fc55-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HTD3nKxNQaDNC8mbfuFe25rdWPLme94FrViiCMNS9u+rgXIcNxafbtkmazadDd6d40BCTYyCQoa/nq/1Q+dn6Fe9t4HdT/RCHBvOtguG/n5FGiWYdDGDFMSdJacTaZb/9KIQBJQoGnt/n8+QwOm7YTaGP6yp+6fmqcYKgUXHkOGwqT1CbYN0AKLOZe2bCA4AGN/QVQ3xjZxXOgtzMh3Ji+I8d7nWPX5Zm71LwtKq66WnX8KfFc+cZI/nrCBTkU4y7tqNupl5ZJSZ2A99U9tau8N0zWmdMKleWk6RUQAMrGIQIswhkwmmrI37fxJRW5hwYddScR84EeJ1D2Yav7nfmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=u78nobaCvUCArTFwsKt7etI6MU4zht5CUARIhXzl3Uw=; b=H3x4z6AaA65ME+XF1PcGRScQYT1QYIMYmtCRm2XflhmaX0DRk5BG4VKP2MeOny7ROXHDUMWLRgDOs4P3MRarTHbaPy+P0kFyCNSdUoV4xUW3/VmZ10QSF8RxXJCZpaJKKxZTXoEqTpYqqspg737GxssgTdTXa3cdBnMPyXy/mpVZ/0mAf2RUkIfcAXJLmxofi/onI6Svt6Y72mI2OREoNyZgrYO67LPvAXkCRakcVPikw4cAilMwnHwMllVIv8lgzNg460zNUpiXjHzgT5Fbhkp8b8bVrSjFub08ZkrYp5geKb9mRTkVj6igHNvyAS174ks2jm9n+RBLTz9Ij/QdiA== 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=u78nobaCvUCArTFwsKt7etI6MU4zht5CUARIhXzl3Uw=; b=z4BXqckWC9ExBqaZkxdqmBL55F+33+sUKIfUW9Jfe95swb5D2G1F7R6xvoxvgUlN4CfmhtvwpJOCJCl6M9tWbYnGeVw9yXV+tuSDnf3G4W5QI4CT1EEcE7EGT8XRiWQgKcY9sJa0BIRfmIUkxGEN1DS827O649Q0mm2x0Hpn1BQ= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 28 Jan 2026 15:27:04 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , Stewart Hildebrand Subject: Re: [PATCH v2 1/4] PCI: handle PCI->PCIe bridges as well in alloc_pdev() Message-ID: References: <58091dc1-7bda-4536-8200-2d0a5679d4d1@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: PR1P264CA0135.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:2ce::19) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|PH0PR03MB6955:EE_ X-MS-Office365-Filtering-Correlation-Id: 55d2fdd3-e7f9-4e5b-34f1-08de5e795185 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?LzcxUy9DWnNqY09uNFE5TFA5YnVMUTdIek4zV1dWek0rcldUeGIzTGlOVHhB?= =?utf-8?B?Rnp0Mm84NWp1enpCekFxelgzZXArRHBNRFZrblNMdU12aDIwR1AwajFLZm93?= =?utf-8?B?ZExHUWUrMHhWYmhHT2EzWEF4R2l0TTRMMU5mVU5kSmZhVEdYTkw1T09ydUt0?= =?utf-8?B?dXRXYUIxaCtkdWppZmx1aUcxM016VytNWVhoN0lKL2NqV00xUGQwV2laYUJC?= =?utf-8?B?YzB3RlpWcU5UNm1YbldXaW1kM2cxN0NQTjlGN1ozN3hJWjhVaW13WE4zWE9t?= =?utf-8?B?MjRLWC9lbHFXaUIyQ1RMK2NzT2VESnA0dHQ0dlAxaWNMTFpwTm4xTGg5Nk84?= =?utf-8?B?czROU3FVRWY5LzNpbTN0UVZFRCtvSmNaT0RXOVJUbEJFYnVzMkNPQW1BRVJ0?= =?utf-8?B?cHBzSEFqNDhnUGFRUUZVWXBreXVjeVlIOWhFTGxmTjN4VkcxNE14a2N5all0?= =?utf-8?B?Q01nekx6N2Q1WElsWEVwejYrRkk1ZisvVmN4emVoTnNON1Myb1pkdmVmaTNV?= =?utf-8?B?YnBGRFp2QVZYMlJYT0Vwcmx2OXgwM1QyejNESXFjeEptNlVGVURPVTR4LytW?= =?utf-8?B?NDRDTVBqYmFRcVBQNyt2NVFxYlJlSzBxWHpnT1VzS3d2Q0RDU3BKWXEzR1Rl?= =?utf-8?B?SWI4MFdzR055OGJrSlUzdSttdHluRXhHUElCTEFtb0w4ZHlBd2c5Y1FlcDhX?= =?utf-8?B?VndhRUNnWW15Z0kvS0ltWVRZOTY5WXJrRXpNSnhJTmdEVXRFenJCWXdBK2FJ?= =?utf-8?B?b3RkNU1XWW9kY1BzWkxRckU0VlFwWnI0WHBTNjVZTkFZdlpiL1o5QytwVjRQ?= =?utf-8?B?c01QcSt2eWtOdElZR0tJUTIvWE5RUmo0eHc1YjR1L094WDRSQ0ZHaFNjWXdz?= =?utf-8?B?VEppOW82RnA0UFNiSjhQYXlTUklCMmVHcWNTYTBRQllkdVNLUmo3REZWdlVk?= =?utf-8?B?L0Y2ekxiSWsvekpneDZTMFVSSmtyaERvTENxd1NaMG9iUXNyRk1HWTVieFdO?= =?utf-8?B?dkc2T3p3MXh5ZU1uOGU5aTZpbEk3amNUSWl5VGsxWXhtVVNhQVJ5UVh2VHR5?= =?utf-8?B?a2lNR1NvZ3J2K1hGQ0doTDdJTDBZRFkrbkx2WmtaL0Y5UklYOHBEdHBuS0ZD?= =?utf-8?B?c0hzakVyUDFoUkNVcXlrT2tpd0hCRjBlbTJNOHhjNzVDUDlTNW5JRy8zUUUx?= =?utf-8?B?UThVd1E3TTlUbG1mcGdQUnB5Snh3UTNvU2U3UWxya2pPQ0crRS9BMG9tSHdO?= =?utf-8?B?WFZGWWk4cS9ORXlNZkdOeTArNTZWaWVCdGRVbno4SXlHNks5aExWTUhPMjRM?= =?utf-8?B?dnVNcG5xVnByR2FyMVQ1S1p3TUlPVS91eEFUYzJHM0I0cEc0ZnVvSmFoaWhM?= =?utf-8?B?TzYrbkkzRVIvT0ZaUUJGelErZkpWZ2xMZEdlMjdld2prUVNSb1NwVHhlV08r?= =?utf-8?B?aUZKSUd0ZEJEOHVyZzdWZ2h0VWxaNyszbENvSkNDb09VM2g5RndWdTd5eUtB?= =?utf-8?B?MEp6ZXR4K3Y5NDR5SXJYOWFTVmdLRVl1RXVTVmpISWo3Yk81QXQvSDFwV0hi?= =?utf-8?B?ekJwdE91VncydnU2SFRVSFZqWnFFaDhjbVJ6VHhRMmlrckZCblhOVjdSRjBN?= =?utf-8?B?UTBBakRRRWE2U1VtZGRRdDhhM3NGVDJtZ2VRLzVXUlBOOEVQVTA5SFM0amY2?= =?utf-8?B?TWYvYlordWNEV21sY0kyUVhoUU9rZXZuVnhnSlFuRVBrSkNSRlVGSG91SXZn?= =?utf-8?B?dnltQjNMck9LWTczUldVNGJPNVlMQkZyUitUUTVkUVhTMnhNUmFXeG5KcmVR?= =?utf-8?B?N1M4TUY3bTFNTERaTU8vU0VDSUk4RU9HOGdjUytZcXpCWTEyc3JsdGtqeHNm?= =?utf-8?B?OXN0aXVIOSsraU41ck5yMFhNTzJXZmEydWh4YzdwVTZXeG1GbDhCV2hVckY1?= =?utf-8?B?SlU5Z1RZNFI0cDNidVJ4Rnd4a2k0VkxIVVBOYnhNSkdTcThWNGxTNG1ER012?= =?utf-8?B?ZFdidFQxVXlMNS9pREtSb1hjR3diNFQrZ1MwSXg4RllTbHY5eE1BV0JpT2hh?= =?utf-8?B?MUhOQ3ErWTYyREtvc2JGdHE0TjBKTklCUEtmVnJEdUtRVExleXRvanFhcXR5?= =?utf-8?Q?Ise4=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VWx5LzlYN1Z2bUc1VWdzd2k2eXhPUlFnYmpKYXM0Y2VQbWlZVFZQYlJZbzJp?= =?utf-8?B?aUt4VFd6TTFvNW5oa09EU1MvMXlmOHVaUjJpQ0JTSFB3K3VqQjE1THJwZnJL?= =?utf-8?B?ZnIrbnMzTEFJOFdiQmxrWUJqQVFzZFNBWHB6Y09oR29GNDdId3hlTmFVZGlU?= =?utf-8?B?VWNZbFNiMjBzSkhPVHdwM0xqQnljZ3lHNEVjdmpXTHVTOG9sYk1MVHlvVVN2?= =?utf-8?B?YVI1L01WY0YvSnFTK2RNQmREbFJnT0FEN2cvSVp5bUVzK2txbGJvMjhob1Bx?= =?utf-8?B?Uk5TZDNudVhWbVQvYmlkdExXTjNwdVJBTlM2bnorTHp5dHNDbFJWV3E5SkN1?= =?utf-8?B?K0pFbk1ROEs4akZYN2JZbG1XU2pITE5XSHpuUUxIM3Rjc1pZQkpsV3MxOTc5?= =?utf-8?B?Q3czQWZjY1MwZzVDVnp5eG9mb3B2OGZMMXkySVBBMUhnN0dRV1lHM0hwU0pI?= =?utf-8?B?bGlHbFhSWXNKNytTMW13bTJCT0wyckFmdlNqUjFrMEdLK29DeklDYmRUR2FR?= =?utf-8?B?NXV1V3B5YWtEakQyWVJ5Y1BXajZweGJGbkttNFZLZndmMDJhbUNDL0hHS2VH?= =?utf-8?B?ZE9UNEsrQitLVlZpRnBWQWpLaXlTUUtvT04yMkJrK21pTHEzR0VmWnIzT2JN?= =?utf-8?B?aUtTeXJtU2RPQkowNkU0VnQ1amFyZ3k4aDJIWGRBRTg5ZytNUk1oWnh3cGtF?= =?utf-8?B?a0JKMkF4eUNoL2lQYnJ4SHA3WFRCaVBHRXRWaHhoa09lanZxRFRKcXdaUGZs?= =?utf-8?B?cVgrLzV5TVI1emRacVZXUnAyaHE0SmlYWWdaSm9oYmFwakxkQU5iVmhtV3dQ?= =?utf-8?B?T1pKME1hNjlUR0RaRmIxTGozdjVyR0M5V1d1K0V5d1RnUU9Sd1EzbTl5SUht?= =?utf-8?B?MEs0bmZGUDVDc3VSNXNwNkx0bEpGSi9Gb2JwN01Edjh2QkpQVFFmR0crbldK?= =?utf-8?B?aXh2TkhxdWk4cUpJYUVDNUVnRjdBdkU4azd5NjN5d2NONXJZdTNXK1Rud1pj?= =?utf-8?B?a2MwVmZjVFJOTzc3ZE1SVTdUNk4vOVUzY25UcU92TTRFdzU3RFNjaTd1N2xK?= =?utf-8?B?c3dIWEFicDh0OWpYWjhyQlBPaDVsb1NGMmJsektGSmNnVUVCU2JaS3NPWlBx?= =?utf-8?B?d1FRNGg2NWRjNVNUbWp5U2FaRjMvL3d5a2hOQjBXSnF4YlQzeUY5bjdVOUJ1?= =?utf-8?B?K21vNlVLbnBDbVZpelA1TC83SWxYS0UwK0hyMHFhbEhHRDVsVEJUSDJ0cXpn?= =?utf-8?B?QStldDl6akE3RVFMTFdtNUhlRWRHQWtCTDhIRnlZU25yb0RJbXRha0xWcDRs?= =?utf-8?B?V0IvRHlpY2tvZk1WNTJBcy9RZnQyUXhVd0xxVytLMWJSTDFldFBEdVBMaGRP?= =?utf-8?B?b0FJaWNkQ2VpRzErOFBwUmtzSmFnVXJET0RxeUp1aWFSNUtwbzhCTUt2S2xt?= =?utf-8?B?cXdJUi8rYUZnYXNUVStneXJQU2FFNXJLZllIK3JxL3RVcysydHVMaTA1eDN6?= =?utf-8?B?MDZjL0IzMG53V2lLNFlTUnB2VWdhcWd5WEZaWnppdHF4K09PbXBtbWhsWHlN?= =?utf-8?B?bVFjNlg0M1l1eUlGZS8xUlZSY2o1WXBxN1NyZitCeHJJdGppc0VMbGVSa1JZ?= =?utf-8?B?Q0FLL1Y0NFBPOERQaTRSbXhwc0VLRkQ2RkhTUGtUUEk1SXZSam92WGMrRXNv?= =?utf-8?B?TEdlWnRCZFBESGQrWksxYnd0VnRjNTNUVGlQUS9LWGV0NGZ3cm52djZLM3ZH?= =?utf-8?B?NjMwbk0vQkJSeFlKTFU2MFVTUEo2NEdpK1hXU3ZhanRaajhrZEhpYmM4YU1o?= =?utf-8?B?OVZKODlON3BiWnc4UVhrUS9rZXdWM3hxVEE1bVJNU0RoNmZzVnEvcXVLSTBj?= =?utf-8?B?dW5hVHNtd2ZSQzk2eEZFa2oxR0NGZjQwL29KTUNoTFRZeDZmOW9TQzJxck9l?= =?utf-8?B?cmRSV1U5Rjc4Y3dkYk5jVWdYRlJnK2JtRzRmZFNWWjZma0FuT3RWSnIyTkYz?= =?utf-8?B?N2lnOUNXQ1JOcnExZ1lFK05CaWNTeUhzVGhhQmQ1RUE2NFh5dVJRRjk0MlRm?= =?utf-8?B?NzE1YUJZdWFsTFM4cTZ6b0hoUEJiS21LNFAwWFdETkY4RFJWTk5GQUU1dkJN?= =?utf-8?B?b3F2RVlWblN5bjNvcEl1eVZJdUlHUFdSQjcxaUhyNFVTZG12Z3NTeTlsVVc4?= =?utf-8?B?T0FHTzVHWisrK3Rid1dKTlNJamJyN3Vaczd2YlhoWVlOZlBFbExMQU1qa1RE?= =?utf-8?B?MFI1ZFdpUjBydGFjNGprRlZ0V0RKTjhaNnRvRjRMaHNkYkwxejErQld1akxm?= =?utf-8?B?MmhUWWxYMyttTUhCV1pub1p1UTIxaTIrNjZlVFFHS3RhVEZ1bHpjUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 55d2fdd3-e7f9-4e5b-34f1-08de5e795185 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 14:27:08.6719 (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: 1/iJO9JEMSWsUxZNJIVTLXpLyryTGIostKYogQP3+vm50KD8jCvFcH9U3eHFbooep0VHXWBOfIMjPgR5vnVPeg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB6955 On Mon, Jan 19, 2026 at 03:46:31PM +0100, Jan Beulich wrote: > It's not clear why the enumerator was omitted, as these clearly shouldn't > take the "default" path (issuing a warning). Handle them the same as > legacy and PCIe->PCI bridges. > > Fixes: e7e08d86ad2f ("IOMMU/PCI: consolidate pdev_type() and cache its result for a given device") > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 28 14:34:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 14:34:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215728.1525843 (Exim 4.92) (envelope-from ) id 1vl6cc-0007nX-0R; Wed, 28 Jan 2026 14:34:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215728.1525843; Wed, 28 Jan 2026 14:34:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl6cb-0007nQ-TU; Wed, 28 Jan 2026 14:34:17 +0000 Received: by outflank-mailman (input) for mailman id 1215728; Wed, 28 Jan 2026 14:34:16 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl6ca-0007nI-AL for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 14:34:16 +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 6b09e602-fc56-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 15:34:14 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-47f5c2283b6so52314275e9.1 for ; Wed, 28 Jan 2026 06:34:14 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806ce56068sm62756515e9.13.2026.01.28.06.34.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 06:34:13 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6b09e602-fc56-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769610854; x=1770215654; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=vJtFY15q/E6HHORO3vH6tPMr9mWbNmRTiMhrsT2h7m8=; b=KjdA2zD1MxVa/B0uSEcEQgmj+dM5ytiu29RYkzTp/V0EEwoNEs9mAlj1RASgX78z17 nRL3mhoscHoD8JeAC3ZXDM8T9ypjBweWgQxnyJ32/6IsjBL/WmKWZdI2mQaqXVgXrRvP cFKHxbAOkiQfZgdYBIW01CbrOlxapCbL7oS2+fNCzD4iylRqvnvg018WETAzwFAQPB+R UpDdiVWAZLBYBljAYRWXKi3cQe3MExhMi4ZmDDxRG79Na1EDtjkGJgrdECgkXBTwXF+S MJyq9X8eOTdkcz5IO4Uv2b7WOoxkIL1VDjpm4ny44PL0Emi/OaxttBdhRvD376FtZb07 +low== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769610854; x=1770215654; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vJtFY15q/E6HHORO3vH6tPMr9mWbNmRTiMhrsT2h7m8=; b=Dmv12Qx8BU0KgHKcuOAkTPpvjmSq9LTHeSCW+OqsC3D295b+e/4zz6pupUAc9NoeHG KYGksWTAKYtIZEnf4P/rtrGrhnC19fF5iFQeHN05Gh54FVp87w5JleTsAeXfr+sImeoM axGbVdqClgCwcv3GPapogdwT/wP4BYDGuqi6EMgG2UxpoLeAJWdvTlCAaK4fdue7Nu3k iTZYGgpM0y7PjTdSe3GWKBnyFred5U/cEGCg5FgDldKIGWIKUkrK4hlcUArbLG2EPkaz hLS+iul+feEXlHdh39Zh+Bo8OFLfaKd0AaEkApZgLO0fjOf4MCJTmm6fqNZdDM7DBB0V rOdw== X-Gm-Message-State: AOJu0YyX4XcB5D4Krg9AAyucJ1iwp/FEUZ/8/6O7e8uSof+WQmvot4kz fTdSd3ueIZusRICeRJZh/Dm6tgBy8rzo9Dl8WspVoFMJeFonIk63+vEce8KwrwEwCg== X-Gm-Gg: AZuq6aJZwQSaVCQsALFBPlYckh5XGHLWP3ZWR0L3LY4pJXTCfMA7ShuMKgnc+SJcv74 nA14mt1qRaSohrK57x26kqG6vIzv5RZZKZWId3lZtBpuma6TqWfKFT50TQ3g8XQS4th2DU8ZiFF 4JUUdFWtlguio/5N/+6bhr7Sj6epBtDzkEGsD2lltB/ik/3nGZEGkyPU82f45pc1M23d302KYSO uyfyFRG2Ic5ZA+SgXRqVpXVAy2BPWrvDZrHGo8SCTltF8rIKpAR3UDdXgNChtqxyCNmWlKYXwiR WF8MGaaTnPRI5QeRTJwBetXE7A2sCN2U3G1iPxmRkN2SBeRXMXdUIBtUzlHLcMhrwnQ8JV9hAub 5bEhqao3Y77UbGEAYvyd4XZrrStYSaiMOz+QdLrKE0mssWzn5CVrcVVTLSzbGr8AlqMZNm2D75+ HVIRbPgcbM7Acjb+LjGKSw+gF65gdlDmFIuPbNYAO8ojelNX1TPiqxFJm/9kVu3sLZbLfkI3vkc xs= X-Received: by 2002:a05:600c:1e0d:b0:480:4a90:1af2 with SMTP id 5b1f17b1804b1-48069c86e2amr81416625e9.35.1769610853855; Wed, 28 Jan 2026 06:34:13 -0800 (PST) Message-ID: <163e1fed-8a06-4078-aaff-8f0ad0ce6601@suse.com> Date: Wed, 28 Jan 2026 15:34:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/3] xen/mm: allow deferred scrub of physmap populate allocated pages To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , Andrew Cooper References: <20260128120339.47373-1-roger.pau@citrix.com> <20260128120339.47373-3-roger.pau@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 28.01.2026 14:33, Roger Pau Monné wrote: > On Wed, Jan 28, 2026 at 12:44:26PM +0000, Andrew Cooper wrote: >> In principle we could assert that it's already NULL in _domain_destroy() >> which might help catch an error if it gets set early but the domain >> destroyed before getting into the domlist, but that seems like a rather >> slim case. > > Given my understanding of the logic in the XENMEM_ hypercalls, I think > toolstack can still target domains in the process of being destroyed, > at which point we need to keep a final cleanup instance > _domain_destroy(), or otherwise adjust XENMEM_populate_physmap > hypercall (and others?) so they can't target dying domains. Considering that these requests will fail for dying domains because of the check in assign_pages(), it may indeed make sense to have another earlier check for the purposes here. Otoh doing this early may not buy us very much, as the domain may become "dying" immediately after the check. Whereas switching stash_allocation()'s if() to if ( d->pending_scrub || d->is_dying ) looks like it might do. Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 28 14:35:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 14:35:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215735.1525853 (Exim 4.92) (envelope-from ) id 1vl6dv-0008It-95; Wed, 28 Jan 2026 14:35:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215735.1525853; Wed, 28 Jan 2026 14:35:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl6dv-0008Im-6G; Wed, 28 Jan 2026 14:35:39 +0000 Received: by outflank-mailman (input) for mailman id 1215735; Wed, 28 Jan 2026 14:35:38 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl6du-0008Ic-Cg for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 14:35:38 +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 9afc01ca-fc56-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 15:35:36 +0100 (CET) Received: from DM6PR07CA0132.namprd07.prod.outlook.com (2603:10b6:5:330::25) by LV2PR12MB5965.namprd12.prod.outlook.com (2603:10b6:408:172::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.8; Wed, 28 Jan 2026 14:35:22 +0000 Received: from DS2PEPF00003447.namprd04.prod.outlook.com (2603:10b6:5:330:cafe::c8) by DM6PR07CA0132.outlook.office365.com (2603:10b6:5:330::25) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.8 via Frontend Transport; Wed, 28 Jan 2026 14:35:14 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by DS2PEPF00003447.mail.protection.outlook.com (10.167.17.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Wed, 28 Jan 2026 14:35:22 +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; Wed, 28 Jan 2026 08:35:22 -0600 Received: from [172.23.49.162] (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, 28 Jan 2026 08:35:21 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9afc01ca-fc56-11f0-b160-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jxA/2Xii0HEaj18jv2jcXYbcsSf+MC4DYE/NjR9cojO+w7AlJdDjHctH4aNRY1rkp/pttBCAyoea8Td9loM5zxg87CLPE1i3hQK/uTiSUH/knRfZ5gn37C1aKEFxG8teDgjYBzp9Td5+DylCMdyUJgN7uVdJ77YddhjcsbrQLgitc7vT3V2EKH/rYB4WL+k+XND2beee0UPnkBM2QXilRi+JNEie7kdNMAw5AQUuhEbiqkoFtz5NzTMMF03m2h1qVh0p6AIIGI3MN1Sg4Ns5ht4a0J5b8WumAnMd0N5iucx4Qk25NjW/L6bODv/xo2yf2QZRU85pdk/uucIgA/rIXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NHu8Cz4NJZCZKEg8BY5ysWNTXUrzN9kwI/SmKpiBfws=; b=lqlnUk9NBeQqw3Id4YkXMLTBpvJ+KRRxQmR8PAKEEdTEQIHHTzmVe+MQtJ8u6N/UrcgpI6IeTHSwE8EJ3QaQzebFBGfxumirQcym8NXFZ3NWlYI/1HQrCNfniPhAKaLJVD6YvkU6w0IHNbTrvZjyisi+YD0v+G4e7iXHeehnCBdt46CYmgkCjS5TVVbY1GkinUndOiuweo3uLCT0Ca/tBAjtDT3YMjj3xCnZRuhmoAJ931htYj/XyMEVDwrfiBXwPO1cdIUESCxN+x+1MKQUh9VwyE2lOxHE+B1x6HwFVf1vLOxFqTqnjaRSnIRNqfRU4JoYB4Qt+DIvs83yLixGOQ== 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=NHu8Cz4NJZCZKEg8BY5ysWNTXUrzN9kwI/SmKpiBfws=; b=xReESmj4mSpNy9hl7BZEZNhV99hgjq5mcBcH5hI7HzYeVRX28IbhN4Oj/OricbBjgkgt74Kn8gLHQYheTvdQlPq4eEXQIOA5Iu6f4jtKZaeoNZiEgNiehUmfX7dqDDWCwOEeu2baI73ajcyDT5gZt8NzqKk+6jlYCHQ3jXvLFL0= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Message-ID: Date: Wed, 28 Jan 2026 09:35:48 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jason Andryuk Subject: Re: [PATCH v9] common: honor CONFIG_CC_SPLIT_SECTIONS also for assembly functions To: Jan Beulich , "xen-devel@lists.xenproject.org" CC: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Bertrand Marquis , Volodymyr Babchuk , Oleksii Kurochko References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS2PEPF00003447:EE_|LV2PR12MB5965:EE_ X-MS-Office365-Filtering-Correlation-Id: b1c93adc-c0b4-4694-6918-08de5e7a77dd X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|376014|7416014|36860700013|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?L1kzVFo3UERlN3VvOWhvb09SYkJMUjl2bWRJcjcyMHc5QUF0Y2N3S2trSG9m?= =?utf-8?B?di9YM0lJenZQa2hlUjFHM2xFQzVnakV1dkdnY2FmQlZsenFSWVZGcE8zaW4y?= =?utf-8?B?YzA5UDVWTjZmOWp2aU9kNENabElHY1ZwSzNhVTdJcHlyRDl4ZHZ3eWRmdjZ4?= =?utf-8?B?VkdIYStyekN6ckt6a05TTnNDeW1Rc1p1bmxCTDMzZ3ZTTlduYTlSSXdwVytu?= =?utf-8?B?bERDM1g5UnFOUmdFNEhkMjY1ZVJwTXo3ZWFreUI3WlpicnJNS0lENW1mMWE0?= =?utf-8?B?RnlDWnR3aktzQWQzZUJGbHJmTUN2bXMya0dtZjIzVktIeVBYdUJjZkNXbXJj?= =?utf-8?B?NjZYcU1JYXl5M0Fqam50eFd4OEtDTmZsWmtuY1lQVUsxWWJYcHl5SFdQS3RR?= =?utf-8?B?Z0F6eTd3eEJSSENzSllSU28yRnE2RXhsblJrN2hCWmYrczI0ZG5tL1dVZ0hH?= =?utf-8?B?UWs4ZC9Od0t3cStOak1UWDhNUG1SY3dZNFdlTlg3eXlnMDRhQmpvU3V2Uk1l?= =?utf-8?B?bTBQcFdNbE9iTEh1Nm56L1BJSU94QXRnSHJYVmxTVkpjeUxIZEZEYm9nYm1S?= =?utf-8?B?R0ljZlY0b0NZTWdlWUFKRHFwN1pkQ0NSU0k2NWo4Z2d1RWt4OTBCZzQ1YXBD?= =?utf-8?B?L2FiaHp3Z0toRzhZanEzTy90aWE0bk8xcUVXRklaUjVzQ2Y0NUM3Z2x3ZGho?= =?utf-8?B?bjVkL1JqSENlMmQ0Z2NZRXJoU09FcVdVdzMwUXVqWUVpbGVST3cxbmYwNjcv?= =?utf-8?B?M0FOVmE1RWJsRXp4Z2hiZGRpOUQ4bDR3bDg5ZEtPTUdQNHNUUHlVdERHUUdY?= =?utf-8?B?SldpUEEvU25XS3RVY3NPOUJUUi9FcmhqeUs5RVBLdGpoRk5rUnVnUWV5anlF?= =?utf-8?B?WFZnYnNZaFFRQnpqdHIrTlNkZjFPWU5MYWJWcGM3RU85WE40VzBBU2g0QWw3?= =?utf-8?B?bDJ2UVdYRXBSdU04NStCci9QS3d3RHU5dUg1dTNVTS8zaUIzdUh1eXd0Umpu?= =?utf-8?B?OEtZRit4QVlqRU0wRDlOVjVRMGxZWk9VRXYxNDZ4U1VDV0QrbHZVQjRoR3Vy?= =?utf-8?B?YmszQUNzTm9RYTVwK0RKcVArWW1OemV5cFpvWWI4eG9DTVFVVExMdlgvK1Iv?= =?utf-8?B?VUp1K0FPUVVoUTRmR0FPUVc1d0ZjYUpnRmh6bVJuQnFwMFcwZ05pcitrVkVq?= =?utf-8?B?QkdEeGd2NjVjY252R0VkUXpvdkZiWkhHUFA2L1p0bnRSaUY5d3ZCaTUveWhZ?= =?utf-8?B?WVN3dE9EN0RUSVVFZGw5czRxNU1tMWVNMXVlNHBWRG9NQVJ6dFQ2dktPcmxx?= =?utf-8?B?ekdQdGtkb3EwZjY5aXB4R2tneG8yYjdvWHp0OFdUdVJKNkZzK1BJSzZ0OWRw?= =?utf-8?B?Y0IrbnFmaDB4OUFHSGdaZkRDSG5Hc24wT0lJOE1qaXVUZFJWcmp1aC9RZ2NK?= =?utf-8?B?M2VKK0JPaVVTenB2dWdqNHIzdW1VcnlIbzVpc0ZZV0RmUU9nWkhXMVFhaFI0?= =?utf-8?B?a0x2b2JCZVZiTkF3K1REeEppUWxYTHZsaWF1Z3VlS0R4bm9PNDZJUmdwdEpQ?= =?utf-8?B?dk9aelpFSHJENmpKUFNna0ZhaDZxUDJrd0RYS2h3bXRnbW4zQ05LNjRMRlhV?= =?utf-8?B?S2g3ak5sVnpHQmNYRVNZWjUwTjNnUG9sbEVpbW8veEUwSHV0K0pzeFNsSDZy?= =?utf-8?B?QTd0L0NyR2l0YlozY3VVNkxiU2tHR0pseHlLOHE1U3cvcC9oSk54SytlNzZl?= =?utf-8?B?aW9nNGtVOFhvejlZTm5mZEZEUEYwRFNKNE5GWThCNEVaK2hEaGFsMVhHYk5Y?= =?utf-8?B?K2Jjb25TdGlMb0ZMUDc4RWtxbU9zckc1YTZjSTQyM1lZaHBRNHdZd091TjBa?= =?utf-8?B?SFRwNnBTUmpzenZBWCtVVVdqZmRuaTlOT2VoOHFYVTV5Wk1NSjBHME80c014?= =?utf-8?B?a2d5WnFYaG55ZnBTU2g1Q1Z5VG1PM2c1eCtWSzlUZGo1cHlqMit3R2RhdnhQ?= =?utf-8?B?bE9XUjdFbStuY2JPK3hERFNENE93YWtjcUpsVTkzekNLT0EvZEg0UUNyVnJY?= =?utf-8?B?ZmFSNUFYeXROcldCU2xlcjNaVGxLbmdVdi8za3NWcHNrMm5taG1yNFd3emp5?= =?utf-8?B?bERTVVFrZURJdHBFTXdoSEJSN2wvRUtOakxzbG9BdU1ZOHlDVlJPN2NQQzFn?= =?utf-8?B?aVdhSW1YemhpVmFEbFBneVFCR1NkSC9RWmExM203RHdXVlNaU0hrOUo3K1k2?= =?utf-8?B?QStzVHZzVjA2MFRaODlraExhNHRRPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(376014)(7416014)(36860700013)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 14:35:22.2318 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b1c93adc-c0b4-4694-6918-08de5e7a77dd X-MS-Exchange-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: DS2PEPF00003447.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR12MB5965 On 2025-04-01 06:58, Jan Beulich wrote: > Leverage the new infrastructure in xen/linkage.h to also switch to per- > function sections (when configured), deriving the specific name from the > "base" section in use at the time FUNC() is invoked. > > Signed-off-by: Jan Beulich > Tested-by: Luca Fancellu # arm Reviewed-by: Jason Andryuk Though I have two suggestions below. > --- > TBD: Since we use .subsection in UNLIKELY_START(), a perhaps not really > wanted side effect of this change is that respective out-of-line > code now moves much closer to its original (invoking) code. > > TBD: Of course something with the same overall effect, but less > impactful might do in Config.mk. E.g. $(filter-out -D%,$(3)) > instead of $(firstword (3)). In fact Roger wants the detection to > be in Kconfig, for LIVEPATCH to depend on it. Yet the whole > underlying discussion there imo would first need settling (and > therefore reviving). > > Note that we'd need to split DATA() in order to separate r/w, r/o, and > BSS contributions. Further splitting might be needed to also support > more advanced attributes (e.g. merge), hence why this isn't done right > here. Sadly while a new section's name can be derived from the presently > in use, its attributes cannot be. Perhaps the only thing we can do is > give DATA() a 2nd mandatory parameter. Then again I guess most data > definitions could be moved to C anyway. > --- > v9: Move Arm32 SYM_PUSH_SECTION() overrides here. > v7: Override SYM_PUSH_SECTION() in arch/x86/indirect-thunk.S. Re-base, > notably to deal with fallout from fba250ae604e ("xen/arm64: head: > Add missing code symbol annotations"). > v6: Deal with x86'es entry_PF() and entry_int82() falling through to the > next "function". Re-base. > v5: Re-base over changes earlier in the series. > v4: Re-base. > v2: Make detection properly fail on old gas (by adjusting > cc-option-add-closure). > > --- a/Config.mk > +++ b/Config.mk > @@ -102,7 +102,7 @@ cc-option = $(shell if $(1) $(2:-Wno-%=- > # Usage: $(call cc-option-add CFLAGS,CC,-march=winchip-c6) Maybe expand to illustrate extra flags will also be passed (-DHAVE_AS_SECTNAME_SUBST)? > cc-option-add = $(eval $(call cc-option-add-closure,$(1),$(2),$(3))) > define cc-option-add-closure > - ifneq ($$(call cc-option,$$($(2)),$(3),n),n) > + ifneq ($$(call cc-option,$$($(2)),$(firstword $(3)),n),n) > $(1) += $(3) > endif > endef > --- a/xen/arch/arm/arm32/head.S > +++ b/xen/arch/arm/arm32/head.S > @@ -48,6 +48,13 @@ > > .section .text.header, "ax", %progbits > .arm > +/* > + * Code below wants to all live in the section established above. Annotations > + * from xen/linkage.h therefore may not switch sections (honoring > + * CONFIG_CC_SPLIT_SECTIONS). Override the respective macro. > + */ > +#undef SYM_PUSH_SECTION > +#define SYM_PUSH_SECTION(name, attr) I put this through CI and it passed as-is, so it doesn't need to change. However, included in a different branch with some --gc-sections experiments, I needed to add SYM_PUSH_SECTION re-definitions like above to: xen/arch/ppc/ppc64/head.S or ppc failed the linker script ASSERT(_stext_exceptions == EXCEPTION_VECTORS_START); And these: xen/arch/riscv/riscv64/head.S xen/arch/arm/arm64/mmu/head.S riscv and arm64 built, but hung when booting in CI tests. There are also these: xen/arch/arm/arm32/mpu/head.S xen/arch/arm/arm64/mpu/head.S They aren't built or tested in CI, FWICT. And they are not in alternate sections. Maybe an ARM person can chime in on those. Thanks, Jason From xen-devel-bounces@lists.xenproject.org Wed Jan 28 14:46:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 14:46:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215753.1525874 (Exim 4.92) (envelope-from ) id 1vl6oA-0001pE-DI; Wed, 28 Jan 2026 14:46:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215753.1525874; Wed, 28 Jan 2026 14: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 1vl6oA-0001p7-AT; Wed, 28 Jan 2026 14:46:14 +0000 Received: by outflank-mailman (input) for mailman id 1215753; Wed, 28 Jan 2026 14: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 1vl6o9-0001p1-IY for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 14:46:13 +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 142de2bf-fc58-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 15:46:07 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-4806f3fc50bso7883245e9.0 for ; Wed, 28 Jan 2026 06:46:07 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806d98c8desm54904405e9.3.2026.01.28.06.46.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 06:46:06 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 142de2bf-fc58-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769611567; x=1770216367; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=02O0egTgYP70cAGC5owFrGcbqetPBwc4uQPJC4dN1K8=; b=c1Lmyr2hIS5hg7+6GoSFYm3eQsq1zkOpQukmAP/0CwvCZpElEoUakE+sovyqDg/uHm 6W/0/JBFrkDV/CgzOLq84Az+sfCAtaLUxTFKg+vmm0aBbTFDX8CMRcnZ7hbfEGS6jiLV PDS/RdD6JntwdSR4RPzXNtrh9RqGYTpQT8UqKNlmt/TyP/YQFA1eEB37HWpiiiERTq4T /FTjRpUxghbwCTvJxhmZQe7tXpcEWI9lvhd1qRHNAn2fY0CNZ9/N4ikxXxPUvQw9mGtR PeaKu9vW/QuDDZtrAkDRc2DvMvLIBkSPGUxh77V52Scq567fwMfhuScpUcQ7nsV+j+7r ++3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769611567; x=1770216367; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=02O0egTgYP70cAGC5owFrGcbqetPBwc4uQPJC4dN1K8=; b=HNvjFY/XP05CZ0cJbsw7zC1IO6p/WCYPENkwz2fsDmTyPaGxt5Nk5Tbyv5CaAGBUuj ScPfWEvPPmeouPtQDuARBPZ4Z9oYhbw08RYHQ1zKHo/djbUnF3Oo9jt69U1i0cIBt+aN ssUZpCcZk4nXxs9C0DB8KyCrQ2csgFwYaH1yyBHZOJrxYYPm3xtDLs7x15RP2VkNhoDD pnA0/b4uTGAtyErwA5K2f9xledkSRVrtmdgitcDmuixOMM5FYoCkSiJCyE7r8+mjPOiP LEJlh+MDq4z2QP29dGNZkdUh43uvhn5l4y9NPHw2+kKUHEuJzu7nn6r3gd8jx4vgz4n5 MFyQ== X-Forwarded-Encrypted: i=1; AJvYcCWxFl39p9JVA7ZKJfP42na8dPIEwQ3huPqNzIBuHhqdAbuYzKBvqayqh9VwchBWpHfk28sIqdMda5Q=@lists.xenproject.org X-Gm-Message-State: AOJu0YwMBrSfbb8jUH6DBOSGvQNk1q7wQoPs7HfWSi2nPC+DUB4WO1Zc MENnnRSn23mLCIG+dAsvAXmPit9oVF2vfzWVnvoxc10NGXyEYEoEOSSEwuwZUpjC4Q== X-Gm-Gg: AZuq6aLaYWBUZ3HfAkcyB1iFNusswMRvIbkNabSvxq7bpEvAPMQfXCbfJCakgWz30wr Uts88/efFEOBzAEAsivp708GD7vCiP7wkk+zas2gLkL7vB5Xvtq15XMECQKoUhlku7Samomc4zE /wTpoZiZ8GfBPyRBxb5uaEr7eot+dRMgvtjfqH5W4+LzA+cf7IRDO87NiiFJ0IYOL/vSrcRW/2O 5sjcpqyl9+VqGz8v7CS9xcaPU/jVeFnFTfPfGn59PU5z81nzp7RxFoqBvw8u4dxb8RlzjJwS7fj 5EhCvkmkAhEkAtkKMvY5UZeAn0hQNwzmPscUexfBxOKrwl0vf6wYw7tahnjFOSn64OW3OkCJgDX ftnEUSbz4Mdl1Z/AhdAy+ZT3WUlWV6um9VP+inQbfrP+MQwNrTShuBGkqk37U+opzuUYgypD6jo sVRl0FH2l0aTb4Sf1KWPnrtj/s8aoUWN8i/Ezz63XEcRjbQia1XeyBqGvM7aUM0pNXy1DOfwOLz 7A= X-Received: by 2002:a05:600c:450b:b0:480:1e9e:f9d with SMTP id 5b1f17b1804b1-48069c0e151mr61674515e9.8.1769611566980; Wed, 28 Jan 2026 06:46:06 -0800 (PST) Message-ID: <6d7b74b6-1bab-427d-aa14-321f4761d9a0@suse.com> Date: Wed, 28 Jan 2026 15:46:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/3] xen/mm: allow deferred scrub of physmap populate allocated pages To: Roger Pau Monne Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260128120339.47373-1-roger.pau@citrix.com> <20260128120339.47373-3-roger.pau@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260128120339.47373-3-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.01.2026 13:03, Roger Pau Monne wrote: > @@ -275,7 +339,18 @@ static void populate_physmap(struct memop_args *a) > } > else > { > - page = alloc_domheap_pages(d, a->extent_order, a->memflags); > + unsigned int scrub_start = 0; > + nodeid_t node = > + (a->memflags & MEMF_exact_node) ? MEMF_get_node(a->memflags) > + : NUMA_NO_NODE; > + > + page = get_stashed_allocation(d, a->extent_order, node, > + &scrub_start); > + > + if ( !page ) > + page = alloc_domheap_pages(d, a->extent_order, > + a->memflags | (d->creation_finished ? 0 > + : MEMF_no_scrub)); I fear there's a more basic issue here that so far we didn't pay attention to: alloc_domheap_pages() is what invokes assign_page(), which in turn resets ->count_info for each of the pages. This reset includes setting PGC_allocated, which ... > @@ -286,6 +361,30 @@ static void populate_physmap(struct memop_args *a) > goto out; > } > > + if ( !d->creation_finished ) > + { > + unsigned int dirty_cnt = 0; > + > + /* Check if there's anything to scrub. */ > + for ( j = scrub_start; j < (1U << a->extent_order); j++ ) > + { > + if ( !test_and_clear_bit(_PGC_need_scrub, > + &page[j].count_info) ) > + continue; ... means we will now scrub every page in the block, not just those which weren't scrubbed yet, and we end up clearing PGC_allocated. All because of PGC_need_scrub aliasing PGC_allocated. I wonder how this didn't end up screwing any testing you surely will have done. Or maybe I'm completely off here? Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 28 14:59:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 14:59:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215767.1525885 (Exim 4.92) (envelope-from ) id 1vl70k-0003nU-AL; Wed, 28 Jan 2026 14:59:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215767.1525885; Wed, 28 Jan 2026 14:59:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl70k-0003nN-7k; Wed, 28 Jan 2026 14:59:14 +0000 Received: by outflank-mailman (input) for mailman id 1215767; Wed, 28 Jan 2026 14:59: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 1vl70i-0003nH-VH for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 14:59:12 +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 e5e8c312-fc59-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 15:59:09 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 0AED460007; Wed, 28 Jan 2026 14:59:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5B0F7C4CEF1; Wed, 28 Jan 2026 14:59:07 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e5e8c312-fc59-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769612347; bh=gVOMR1V4hcjeaNYFYShKh4GCAi/n0lKjKVqv/7s0UjE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=sXYgIgZQFpF4OaS2aeeh29HK5PXhUS6cCC9vxUcDunyQ/KZJL1RMIixiElusW8/Kl n8yNYfLEWh3H2unOQH0bXnc2ismKxpNUUc/iuT+e0D+B9ICQZXheGbr82f4ptADSq2 YySOlRXCrqmnZmk+XLeLNngwD2SzJ0EcRF0zJRdAnJ1KweUqNV4K6x6NxkXEriFBo2 lm/Jci15Jfsesy2hvdnmb2GaVxY+aevqf1Ju60+/Lljv/kK1m1S7QatgzDuzE97nz7 dYfVD1djkmQ02JPD8eY9zRwymtgNAF0S0BhzJnWoolIaH11Tz+9+0TfJDV45zzjKpN yz1jZaDr2UILQ== Date: Wed, 28 Jan 2026 07:59:05 -0700 From: Keith Busch To: Roger Pau Monne Cc: xen-devel@lists.xenproject.org, Jens Axboe , "Martin K. Petersen" , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Christoph Hellwig , Sagi Grimberg Subject: Re: [PATCH] nvme-pci: fix parameter order in nvme_free_sgls() call Message-ID: References: <20260127195907.34563-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260127195907.34563-1-roger.pau@citrix.com> On Tue, Jan 27, 2026 at 08:59:06PM +0100, Roger Pau Monne wrote: > The call to nvme_free_sgls() in nvme_unmap_data() has the sg_list and sge > parameters swapped. This wasn't noticed by the compiler because both share > the same type. On a Xen PV hardware domain, and possibly any other > architectures that takes that path, this leads to corruption of the NVMe > contents. Thanks, applied to nvme-6.19 with updated subject. From xen-devel-bounces@lists.xenproject.org Wed Jan 28 15:07:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 15:07:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215777.1525894 (Exim 4.92) (envelope-from ) id 1vl789-0005Nl-VI; Wed, 28 Jan 2026 15:06:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215777.1525894; Wed, 28 Jan 2026 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 1vl789-0005Ne-Sk; Wed, 28 Jan 2026 15:06:53 +0000 Received: by outflank-mailman (input) for mailman id 1215777; Wed, 28 Jan 2026 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 1vl788-0005NY-D6 for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 15:06:52 +0000 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [2a00:1450:4864:20::342]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f94c4a2c-fc5a-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 16:06:51 +0100 (CET) Received: by mail-wm1-x342.google.com with SMTP id 5b1f17b1804b1-480706554beso6946575e9.1 for ; Wed, 28 Jan 2026 07:06:51 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806e2d1d64sm1467845e9.13.2026.01.28.07.06.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 07:06:49 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f94c4a2c-fc5a-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769612810; x=1770217610; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=jG4sfr+1ldP4fYlgJBRDbUJDlToChRYazDXEqzEqij4=; b=StTQ7lap6Ypr5nc0p2l2FP/1lw/E0LfslZj+88kZPMdlDT+1x+RsQv66rUUVaWmDe4 LUi/lY0gHUgDmj+aXnlUa8IyPmDaw97WWhEQriaJniE4xxa1VUsY6r2vE+AYhX5RfSyS HjMwv8U8/1cPzeXQH9mVKU6nZL5TEJ1SAOZZS0f1N3Y/ihaRD4VTCAXAnpV176omXi7r 9vT3daLWHhXEWdYXv/wCIqB9AnR4u5EQzaXjOteYqotaKfP9AlHmRkY14/6ItPvlLBbC 8phB0FZo00EOpc/XS6r4eysTCG4Op7DA0teMIZeh0ZTSAimwyYnHfE+hY0tpRvadpKs3 mWzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769612810; x=1770217610; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=jG4sfr+1ldP4fYlgJBRDbUJDlToChRYazDXEqzEqij4=; b=okqdPTwjpLyO/MkTiJdHfyITdMNs+UFyfV/SR8arHRA6+dXtqAuuMV/EX3aV41LuGH bBlcCl2zb2ljsO59MIyytfDmofcJfng0pf9wTE3ZI6ETNA6h29Rhm43NBORuU8SDyNgK sM232l71QTHbhOmuwwrDF38fuS225EkdPs4TmGuhloUktBwKdnXTWZo5nSs1WeO83l84 InoqbWQlh4Utlx+njXJLn5zByc/QLJAooHg/jbwiJqQmHDcNYoSmacEcOfuLWLhm2iwn NEPvlVobIQSzYmU02OUwsTad6WH8eeMdn+/atjO4VpssozCj2PpE7joDa0tTMPGjZrLk 8tRQ== X-Forwarded-Encrypted: i=1; AJvYcCUGHwAMoa9UYUvSEU90M+g+kllFaCJ/he7PVz/IS/Xa8Szt8Dl/rVUMM4hh3DbtKTix/YKaoKc0PrA=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx1n8nSTLVZgbXw1EejKThFrxG+gTzITWWLvNbKYYilpVhUQC7a FoQyB20yUUTe41qQJouJZcIxJcFNIB927kJQ13qckmAPk+pmXR2m7EVstRz/GtYj5g== X-Gm-Gg: AZuq6aJ1VXvA+TqZohk3VkvvPBz3g6fuGOHIjTwgXPASVQVY6EIoLnzAy3nMgIfNNEZ cQhoXTv5SY1t5h8pPF2qrhw5mG3mLkMJxuZGXIlKrFPBfMoM0NwNtw2vhoQONpoRfD8hJ07gGi3 QVyWuKIbEhvLaOnzeolE49yOf+ZnJF6vcBfLfqTvI+7HlMnTkpS/mLdhgLKctcOHdN87nZiqE8D U30XTL/4d772is21ufpOaBQfgE0k2cdsZlS6+JkFl4W2W8ZNiJEQCg78vSurOd98E+RbvnXI9Ws dIShQc0QV96hVbTKweF2aF+/tYdlgQDxKUg/ueb7hG++0U/p5FoFED0oJ7IqzuE7mbmCY8h2IOf F0AqQEkDPEWw1NgfMwxGU16B3N41e/os7uJeRy9BIAU0bQxdBDCsk66XIcoVkyvF+yt1eCi4vhZ mrJVs0z8Y1LHVjGU/ZdGL8qEFORqsa5/BFNNd1T9lDiuaRTYuZYA411ZqJJL/cNmo9ngRWBt8fG rP3hkhLII3aqw== X-Received: by 2002:a05:600c:350b:b0:477:9976:9e1a with SMTP id 5b1f17b1804b1-48069c0def9mr72664325e9.6.1769612810163; Wed, 28 Jan 2026 07:06:50 -0800 (PST) Message-ID: <0e919562-0e13-4f3c-b09b-156a0822eb53@suse.com> Date: Wed, 28 Jan 2026 16:06:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9] common: honor CONFIG_CC_SPLIT_SECTIONS also for assembly functions To: Jason Andryuk Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Bertrand Marquis , Volodymyr Babchuk , Oleksii Kurochko , "xen-devel@lists.xenproject.org" References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.01.2026 15:35, Jason Andryuk wrote: > On 2025-04-01 06:58, Jan Beulich wrote: >> Leverage the new infrastructure in xen/linkage.h to also switch to per- >> function sections (when configured), deriving the specific name from the >> "base" section in use at the time FUNC() is invoked. >> >> Signed-off-by: Jan Beulich >> Tested-by: Luca Fancellu # arm > > Reviewed-by: Jason Andryuk Thanks, but ... > Though I have two suggestions below. ... at least the latter really needs addressing. >> --- a/Config.mk >> +++ b/Config.mk >> @@ -102,7 +102,7 @@ cc-option = $(shell if $(1) $(2:-Wno-%=- >> # Usage: $(call cc-option-add CFLAGS,CC,-march=winchip-c6) > > Maybe expand to illustrate extra flags will also be passed > (-DHAVE_AS_SECTNAME_SUBST)? I'm not sure here, but I can certainly add another example. >> --- a/xen/arch/arm/arm32/head.S >> +++ b/xen/arch/arm/arm32/head.S >> @@ -48,6 +48,13 @@ >> >> .section .text.header, "ax", %progbits >> .arm >> +/* >> + * Code below wants to all live in the section established above. Annotations >> + * from xen/linkage.h therefore may not switch sections (honoring >> + * CONFIG_CC_SPLIT_SECTIONS). Override the respective macro. >> + */ >> +#undef SYM_PUSH_SECTION >> +#define SYM_PUSH_SECTION(name, attr) > > I put this through CI and it passed as-is, so it doesn't need to change. > However, included in a different branch with some --gc-sections > experiments, I needed to add SYM_PUSH_SECTION re-definitions like above to: > > xen/arch/ppc/ppc64/head.S > > or ppc failed the linker script > ASSERT(_stext_exceptions == EXCEPTION_VECTORS_START); Yes, and exceptions-asm.S as well, to keep the code in .text.exceptions. > And these: > > xen/arch/riscv/riscv64/head.S > xen/arch/arm/arm64/mmu/head.S > > riscv and arm64 built, but hung when booting in CI tests. > > There are also these: > xen/arch/arm/arm32/mpu/head.S > xen/arch/arm/arm64/mpu/head.S Yeah, I need to re-scan the tree for all .section directives in *.S files. This is getting out of hand, I fear, so rather than putting such overrides in perhaps dozens of places I shall try to think of some less intrusive approach. I further think I need another prereq change. Right now e.g. PPC64's .text.exceptions would collide with the code generated for a hypothetical function named exceptions(). I don't like Linux'es .text..* etc very much, but unless I can think of anything better we may need to follow that model. Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 28 15:12:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 15:12:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215786.1525905 (Exim 4.92) (envelope-from ) id 1vl7Dh-00074S-FY; Wed, 28 Jan 2026 15:12:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215786.1525905; Wed, 28 Jan 2026 15:12:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl7Dh-00074L-CY; Wed, 28 Jan 2026 15:12:37 +0000 Received: by outflank-mailman (input) for mailman id 1215786; Wed, 28 Jan 2026 15:12:35 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl7Df-00074E-RQ for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 15:12:35 +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 c5e2d4df-fc5b-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 16:12:34 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-47ee2715254so36737225e9.3 for ; Wed, 28 Jan 2026 07:12:34 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806ce56490sm65364435e9.12.2026.01.28.07.12.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 07:12:33 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c5e2d4df-fc5b-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769613154; x=1770217954; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Gqk/3qhGKK2Wg6hpidOyJwFjnch4eVq5JiUVPloTqZc=; b=Zy0KJYui1NcmuqvTE9dsiWOU3EVK6TbdRoNqSBE31E0A478g4dfCk8pIzYKD4RAzCJ xwt/Pxs2/xDyTiqHNERTkC/N79gdDfKea2QWqLlwO1pPCugXNqkyFku/F65pbherzNZe EmPmyhaFUXwtQw1y3U8Cfak+DyHX0Aea/4oJ/aX1+28wfi4wnI6cdANeQk3IixXnSwos sOwoeMb/tXldyuU2XdN/em59TOpJ0PVLXCxRCOl2w3rwdE2gTpOKFIjvr8tm8jMaji+I kv8BDT9oy9J9izIjUyVjCP4KIvi6j9EHpcw5PUxd3NNhSNIFyCyNL0/r+o/YEdi6Eh2z phKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769613154; x=1770217954; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Gqk/3qhGKK2Wg6hpidOyJwFjnch4eVq5JiUVPloTqZc=; b=heWoWRhfXUv4L+AMni9/zy1NjMBE79L2WZjlPl0aISuKu0t3sw9HfDc71GkZ4LOrFm nMKawVqz+5rbRup5hQ0/1TNoLxaF51o6fFGVN3tSzwoBTXDLhRHtd0IFHknJXv6H3FDR fq+88hxFTgwX8TbB4J9aC8KngoWWb1Wx8ZhXM4jqgPMbsiSx0CMFQ1v6UjbKnu4c4b7V RGh8eMzn5vH1Ay4OJZULV8r76/sUGINGGIG6Dc3fp5kr2uRYRMwc4rtz017U3Dhor2yh nV1qPzPXa9DL1JzEYQjb7WIrkdNl8IlKRXqXNcY+iL2KIRCFc83Oy2d640FfDF9AMZEY aRoQ== X-Forwarded-Encrypted: i=1; AJvYcCWTY7mKN8eU2b0O2vYWOqeaEoVXULHr7SZC4qhlDXEP5P43+QUVmAZOMtUNJTK7FMmc3JHdY77zuiU=@lists.xenproject.org X-Gm-Message-State: AOJu0YwUpFhNYRI/beJopCbuHL5xUzMDP8E55bzrpafyHCZwlxQ+HVTU l+TckPPsAW+DTheM0p/M2zdWzMX/4zgg+FPdlVj44x7VJ59a4DxKwThdZD0qYbbIKw== X-Gm-Gg: AZuq6aLZOHZQ4842FO2RfqQ6mFF5WnbQAE6Axo8H1e5oKr+h6MCGm0BHBHZDs2g5XiH Monrzp8bmqqKODRAP0e6M+0NM6CRS2YOf02lA5e8NKB1nSiFL5QtpzOXGlOW9pE9F8PnKw5QrMf K+LjTSAFfGQl970stLOUmMmezWQFNOjpEYEPYUuac+nTPj2WqM/KjDgB/BIFVMW5RPsxDY1glXE FZgN6b4QETdROhgJIqizMkPcdY1eKH2htSeK+3BdNqCTg9M2yr4qejgzcQX3ccrB/Faf7e5S+RZ KFFEZE2+dET4f7g2p9LdY0030hRFZLdNABIZi2XZeWSLPkHn0b7ZnF+xo9C4N/1gCYBHshikRAr 5XAMc15fuW2pjVP3F91dfHZXvGrw59gNzM55chitLEjopHCGCcfaWmWweONiYZdKDx61J0ryph2 iUfWLWe7+/oXcHqiNicP9DlfdHU5M1A9952Bl0bcyc0AeAFVMVxSfrWBTllbmt3Gx5A48/3geQ4 Os= X-Received: by 2002:a05:600c:a08c:b0:480:1c53:208b with SMTP id 5b1f17b1804b1-48069c9bbb9mr63070515e9.36.1769613153677; Wed, 28 Jan 2026 07:12:33 -0800 (PST) Message-ID: <91c71a0c-4345-4fae-912b-ae7c9d2160e7@suse.com> Date: Wed, 28 Jan 2026 16:12:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 2/2] xen: enable dom0less guests to use console_io hypercalls To: Stefano Stabellini Cc: grygorii_strashko@epam.com, anthony.perard@vates.tech, michal.orzel@amd.com, julien@xen.org, roger.pau@citrix.com, jason.andryuk@amd.com, victorm.lira@amd.com, andrew.cooper3@citrix.com, sstabellini@kernel.org, xen-devel@lists.xenproject.org References: <20260123010640.1194863-2-stefano.stabellini@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260123010640.1194863-2-stefano.stabellini@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23.01.2026 02:06, Stefano Stabellini wrote: > --- a/xen/common/device-tree/dom0less-build.c > +++ b/xen/common/device-tree/dom0less-build.c > @@ -829,6 +829,8 @@ static int __init construct_domU(struct kernel_info *kinfo, > > rangeset_destroy(kinfo->xen_reg_assigned); > > + d->console->input_allowed = true; Why for all of the domains? Shouldn't this be a per-domain setting? > --- a/xen/drivers/char/console.c > +++ b/xen/drivers/char/console.c > @@ -612,10 +612,18 @@ static void __serial_rx(char c) > if ( !d ) > return; > > - if ( is_hardware_domain(d) ) This check is fully lost; shouldn't it be replaced by ... > +#ifdef CONFIG_SBSA_VUART_CONSOLE > + /* Prioritize vpl011 if enabled for this domain */ > + if ( d->arch.vpl011.base_addr ) > + { > + /* Deliver input to the emulated UART. */ > + rc = vpl011_rx_char_xen(d, c); > + } > + else > +#endif ... if ( d->input_allowed ) the latest here (not sure about the vpl011 intentions in this regard)? > { > /* > - * Deliver input to the hardware domain buffer, unless it is > + * Deliver input to the focus domain buffer, unless it is > * already full. > */ As said there, imo this change belongs in the earlier patch. Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 28 15:17:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 15:17:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215796.1525915 (Exim 4.92) (envelope-from ) id 1vl7Ia-0007hI-1Y; Wed, 28 Jan 2026 15:17:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215796.1525915; Wed, 28 Jan 2026 15: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 1vl7IZ-0007hB-Ua; Wed, 28 Jan 2026 15:17:39 +0000 Received: by outflank-mailman (input) for mailman id 1215796; Wed, 28 Jan 2026 15: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 1vl7IX-0007fI-Ur for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 15:17:37 +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 7a0c7b7d-fc5c-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 16:17:36 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-42fbc305882so4314700f8f.0 for ; Wed, 28 Jan 2026 07:17:36 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e10ee04csm7886115f8f.12.2026.01.28.07.17.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 07:17:33 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7a0c7b7d-fc5c-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769613456; x=1770218256; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=JniLaYBMgd4Sp05rWxfdwmRCwqM9Fb0uwk+/GezMf/s=; b=dMZ7dfXeaKPewNriBMiUgdVBKvg2I7Thu6qKc3eyAXh7t4tyJQ7zXDuzp0DZX/PjRO J8Rrv1PWV4T/sUlpCuk3J8UT0FOhLsAHsptuzmY7VsdVpPMojvPXlK6gQFxAU3SjQGc+ lJFTOwk8app/JaNljz/Fefq+6Gyt5rbsMEJGLTBdECVqddh8kZDelPTjV2aZpXZtoYu9 qiIngHvqZsfNA4PcPMt4C6eBOjzzKQXhkqByTGo9lCtbi/XeSEOHr0J57prRtPrubAkv CXC3UsKCOZMH+nWCTpaPe/LmPuOuq+O/mHCFImL3WDdz3MKCPH3OpqStEYhgmiXC3Yj/ YV/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769613456; x=1770218256; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=JniLaYBMgd4Sp05rWxfdwmRCwqM9Fb0uwk+/GezMf/s=; b=dR3x4Ti5/g60XREOozaGSJYANchCRMB2S40vRgD238B9qUW2P7QSxHwiv6ugSOMexV h8Q2kIcC3knAzA2jeLVBpe7vYMD3MfR47JkV7BljNDGnhAECiUmOLnSL0DnnOTPTfEV/ v27TN//HSOEfJJ6/P6hkRqAKf3xHSQY1meR0BffAecdZiQoHT5A3QNZ0L917Sg3sNUwp fhvzM94p1zasPFrgbesmti7J/RDijw0Z764Q2Tl0qmc9JcXRot6MKNq5FlS1n1vPHLCB WFMeBa4XAYghtGwztN7WOxFGy/DEgd5FyWAlHN+HzR3POZd4z4v1/aQbk0vtJyXGreGi bjZw== X-Forwarded-Encrypted: i=1; AJvYcCWnVDDOeP4MC4ULKprHra+FLq19BZELOMDRXqIlQi74rMk95i1W9cRE7NArfInvaBzJ8G08EYIQgic=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzo6Vo6EMYNACwFFCq2Hm8PmJo60PwAtREIGcwNfSvDqh94/LeK qQ7BFOqy3tqZI3YNcJbtVskl49OZd75JUn7eWA00/CiqrvB5L7xF7ghURJyTEoyzyA== X-Gm-Gg: AZuq6aIffpWNElHVDW2+tjO8sSY6Ii278AXm/I1J78DuZulJw/8uSh6auQfKggw1QbF nrL0lJ93vJ6w3CbTMPy2G9a6RdSaeTh1eNxmyLShFd56Ma6Eo8h2bZl3O72YBfqpOWyja3umYkK 5vllhbDUZhyc2MAkrHRxzjxMxLJN37VVEUCkxtp8h1leFutSw1nFnZIgbP4WPb9FvxZ0O8G4RDn DOyzvlsBCDx9LtfC/qRkfdvEENvoLcfKBEvbxfVb7xZFadrD3x5SAd2XBV9RsaZneE5aI31YBDW B02IVxvG8sCQ/KYNZnwhKbFrdbVwTF+hCTi+nksjZq8Mgfk7TGeDdfsO5XQ6U5xoOmVbx/omiwy +znDQPwAx1Krp2BeyWnWE2qOpmAOV2l5t7Beh53Pdfh1GWv3dTKP6heOVrreQDJd3KWotbJeGDO 6ZNrnSou98QsMBZZ5/AR3y9O8DEbprzIlexiCwHtq28a//IXZgaVG9mqGe7wjPg9PFSxksxwJ/m B8= X-Received: by 2002:a05:6000:2c0c:b0:42b:3806:2ba0 with SMTP id ffacd0b85a97d-435dd02dc43mr6544255f8f.2.1769613455769; Wed, 28 Jan 2026 07:17:35 -0800 (PST) Message-ID: Date: Wed, 28 Jan 2026 16:17:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5] xen/riscv: dump GPRs and CSRs on unexpected traps To: Oleksii Kurochko Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.01.2026 13:53, Oleksii Kurochko wrote: > --- a/xen/arch/riscv/traps.c > +++ b/xen/arch/riscv/traps.c > @@ -99,11 +99,65 @@ static const char *decode_cause(unsigned long cause) > return decode_trap_cause(cause); > } > > -static void do_unexpected_trap(const struct cpu_user_regs *regs) > +static void dump_general_regs(const struct cpu_user_regs *regs) > { > - unsigned long cause = csr_read(CSR_SCAUSE); > +#define X(regs, name, delim) \ > + printk("%-4s: %016lx" delim, #name, (regs)->name) > + > + X(regs, ra, " "); X(regs, sp, "\n"); > + X(regs, gp, " "); X(regs, tp, "\n"); > + X(regs, t0, " "); X(regs, t1, "\n"); > + X(regs, t2, " "); X(regs, s0, "\n"); > + X(regs, s1, " "); X(regs, a0, "\n"); > + X(regs, a1, " "); X(regs, a2, "\n"); > + X(regs, a3, " "); X(regs, a4, "\n"); > + X(regs, a5, " "); X(regs, a6, "\n"); > + X(regs, a7, " "); X(regs, s2, "\n"); > + X(regs, s3, " "); X(regs, s4, "\n"); > + X(regs, s5, " "); X(regs, s6, "\n"); > + X(regs, s7, " "); X(regs, s8, "\n"); > + X(regs, s9, " "); X(regs, s10, "\n"); > + X(regs, s11, " "); X(regs, t3, "\n"); > + X(regs, t4, " "); X(regs, t5, "\n"); > + X(regs, t6, " "); DYM "\n" here? > +#undef X > +} > + > +static void dump_csrs(const char *ctx) > +{ > +#define X(name, csr, fmt, ...) \ > + v = csr_read(csr); \ > + printk("%-10s: %016lx" fmt, #name, v, ##__VA_ARGS__) > + > + unsigned long v; > + > + X(htval, CSR_HTVAL, " "); X(htinst, CSR_HTINST, "\n"); > + X(hedeleg, CSR_HEDELEG, " "); X(hideleg, CSR_HIDELEG, "\n"); > + X(hstatus, CSR_HSTATUS, " [%s%s%s%s%s%s ]\n", > + (v & HSTATUS_VTSR) ? " VTSR" : "", > + (v & HSTATUS_VTVM) ? " VTVM" : "", > + (v & HSTATUS_HU) ? " HU" : "", > + (v & HSTATUS_SPVP) ? " SPVP" : "", > + (v & HSTATUS_SPV) ? " SPV" : "", > + (v & HSTATUS_GVA) ? " GVA" : ""); > + X(hgatp, CSR_HGATP, "\n"); > + X(hstateen0, CSR_HSTATEEN0, "\n"); > + X(stvec, CSR_STVEC, " "); X(vstvec, CSR_VSTVEC, "\n"); > + X(sepc, CSR_SEPC, " "); X(vsepc, CSR_VSEPC, "\n"); > + X(stval, CSR_STVAL, " "); X(vstval, CSR_VSTVAL, "\n"); > + X(status, CSR_SSTATUS, " "); X(vsstatus, CSR_VSSTATUS, "\n"); > + X(satp, CSR_SATP, "\n"); > + X(scause, CSR_SCAUSE, " %s[%s]\n", ctx, decode_cause(v)); For it, in particular the "ctx" string, to stand out, perhaps this wants moving first in the function? With the adjustments (happy to carry out while committing, so long as you agree): Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Wed Jan 28 15:18:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 15:18:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215805.1525924 (Exim 4.92) (envelope-from ) id 1vl7JD-0008JX-C3; Wed, 28 Jan 2026 15:18:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215805.1525924; Wed, 28 Jan 2026 15:18:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl7JD-0008JQ-99; Wed, 28 Jan 2026 15:18:19 +0000 Received: by outflank-mailman (input) for mailman id 1215805; Wed, 28 Jan 2026 15:18: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 1vl7JC-0007fI-98 for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 15:18:18 +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 927511d1-fc5c-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 16:18:17 +0100 (CET) Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-b8870ac4c4eso808454766b.2 for ; Wed, 28 Jan 2026 07:18:17 -0800 (PST) Received: from ?IPV6:2a00:12d0:af5b:2f01:4042:c03:ce4d:a5a1? (2a00-12d0-af5b-2f01-4042-c03-ce4d-a5a1.ip.tng.de. [2a00:12d0:af5b:2f01:4042:c03:ce4d:a5a1]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8dbf1c0126sm143139466b.47.2026.01.28.07.18.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 07:18:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 927511d1-fc5c-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769613497; x=1770218297; 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=LMi5ALsUyW1EGCWergb8OiiCgbqPDCjwCZ672QxStwg=; b=ct16FQVUAFtadf0LdyUzSxA/j5qXhEljg23pM21iDiyycqDe/nvkw1c4UiTfM1WDgc WLNZcz8Qg/sV7/84QlhmV80wI5jVcHVp4KriDA/Z6N3BpiZcw0JkVuvUlSp7NHeL6ScB q5ZI4q7nK8XfzQQehjxJA/FOidefrPLOYLwVMFkmtbPE5cPc3mVX5T63c0Nj250/Pknp 3/x5leJ8Us0ZbBkQDqSPaNcgvY6nJaduDfRGhBG/fbJaq1OpZPAFmd00+BH1dJyTI9rw EscAqiOw9iJG+dNWLHkxT0qUHtJWE5g8j64otnFVvSTEQn5GL/BtDGJLqJrCEWCjxAKT Pgjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769613497; x=1770218297; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LMi5ALsUyW1EGCWergb8OiiCgbqPDCjwCZ672QxStwg=; b=r6aULrdKrgINmztbK6/wainm5UbZm4Ao6JxAbu3Pfk7gampVZ/s/f8fbHDv3NjY4oH LYQgnyORu2UXx2MNmi0emTXI20TiJV2tzs+KL3rwoPmvAX5sGwEkQL1kYe72KRMEL3Qr zlsvhC7etff9WkYNsfdPnQVEZSj8BEEtLha87XoxKETTkSEyUUEN/HjI1dYFtbZtaGpw 9tlHkB8SuYjZ3DiWtEoFuIBZXIsfWyd3de2ozcjK3efmY5y+2Osi0F//V46KLBIUh69O U67Uc7bWaUNEO+v7kTHs7VB3TKSFtHR2aJuHkc6zMB8wwd+QXskG3VjvE+Jz+xSmlmn1 0BSg== X-Gm-Message-State: AOJu0Ywj0jWNuAumu8mUrrzbknllyEql67IQVpvHg8HzRsztw+fveMAO CTSVXgUBi6j+E/W9OaGQUgelJx4JDt2eZocKXcnsSijRFkshZIOziMpKnJmfwTUWpTo= X-Gm-Gg: AZuq6aLqboRzsKEZfcNOTbwt2YCYMtz1cZjaSnsgnBRypGCDA0UVkRwhWWmzRxz+AO3 da2tuDqKCnB/oPmFkfiDQrwQ8hH+UgbDKHLvtaZDwuhbsBF9M5A5cS/7MvdvDd8oPfjiH5TLmmu E0GATu/yxSDY/LZRm7ylZiPAQggA6Iwhrrzjr/Fd99wkpUBdil7FBlwR9Bt7R7J9m7D/ts2r2eM 9MatFuuntxmzCHqXTpW0KoQXMfkUm0y2uRmYTWGL/fsiGHeQij/tvuUzPiMUt2ChnfyfcPmNhCA Q/GwD8yDDCleJZsbt99kwTkh/Q0q4URgEe8OYNZFsPeUrPSHofE96n+GVsToWRUXs/wWpHePA7n k7qhrzj9pnJ+K0GyZNOrOit+RchhEPHlDI9xId8TdJAT8SWe5keQzeHoe0tFCPRtvplBvR1l0+T xIzcNukFWUQgEO9MKiGErhxQ5CToRjTqGzbJFHRDkD+bM2so8bIYJ3ltILnfq7k/KKWAmgqcQTm EVH0ZFW+gi+xkSoPqvO5XIb5CSBPBflUO/ebA== X-Received: by 2002:a17:907:6e8a:b0:b88:5e4c:f837 with SMTP id a640c23a62f3a-b8dab429573mr368998966b.64.1769613496767; Wed, 28 Jan 2026 07:18:16 -0800 (PST) Message-ID: Date: Wed, 28 Jan 2026 16:18:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] xen/balloon: improve accuracy of initial balloon target for dom0 To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, Stefano Stabellini , Oleksandr Tyshchenko References: <20260128110510.46425-1-roger.pau@citrix.com> <20260128110510.46425-3-roger.pau@citrix.com> <596b08db-dc0e-4d42-ac17-570ca6e06bca@suse.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------MRnTJroy7w7wZdq10hsfw0r7" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------MRnTJroy7w7wZdq10hsfw0r7 Content-Type: multipart/mixed; boundary="------------YW4fPjHBHisnI07JsE40lX4P"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, Stefano Stabellini , Oleksandr Tyshchenko Message-ID: Subject: Re: [PATCH 2/2] xen/balloon: improve accuracy of initial balloon target for dom0 References: <20260128110510.46425-1-roger.pau@citrix.com> <20260128110510.46425-3-roger.pau@citrix.com> <596b08db-dc0e-4d42-ac17-570ca6e06bca@suse.com> In-Reply-To: --------------YW4fPjHBHisnI07JsE40lX4P Content-Type: multipart/mixed; boundary="------------IhatcEYAm5eeLfF4NTv0oIRc" --------------IhatcEYAm5eeLfF4NTv0oIRc Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjguMDEuMjYgMTI6NTQsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6DQo+IE9uIFdlZCwg SmFuIDI4LCAyMDI2IGF0IDEyOjMxOjEzUE0gKzAxMDAsIErDvHJnZW4gR3Jvw58gd3JvdGU6 DQo+PiBPbiAyOC4wMS4yNiAxMjowNSwgUm9nZXIgUGF1IE1vbm5lIHdyb3RlOg0KPj4+IFRo ZSBkb20wIGJhbGxvb24gdGFyZ2V0IHNldCBieSB0aGUgdG9vbHN0YWNrIGlzIHRoZSB2YWx1 ZSByZXR1cm5lZCBieQ0KPj4+IFhFTk1FTV9jdXJyZW50X3Jlc2VydmF0aW9uLiAgRG8gdGhl IHNhbWUgaW4gdGhlIGtlcm5lbCBiYWxsb29uIGRyaXZlciBhbmQNCj4+PiBzZXQgdGhlIGN1 cnJlbnQgYWxsb2NhdGlvbiB0byB0aGUgdmFsdWUgcmV0dXJuZWQgYnkNCj4+PiBYRU5NRU1f Y3VycmVudF9yZXNlcnZhdGlvbi4gIE9uIG15IHRlc3Qgc3lzdGVtIHRoaXMgY2F1c2VzIHRo ZSBrZXJuZWwNCj4+PiBiYWxsb29uIGRyaXZlciB0YXJnZXQgdG8gZXhhY3RseSBtYXRjaCB0 aGUgdmFsdWUgc2V0IGJ5IHRoZSB0b29sc3RhY2sgaW4NCj4+PiB4ZW5zdG9yZS4NCj4+Pg0K Pj4+IE5vdGUgdGhpcyBhcHByb2FjaCBjYW4gYmUgdXNlZCBieSBib3RoIFBWIGFuZCBQVkgg ZG9tMHMsIGFzIHRoZSB0b29sc3RhY2sNCj4+PiBhbHdheXMgdXNlcyBYRU5NRU1fY3VycmVu dF9yZXNlcnZhdGlvbiB0byBzZXQgdGhlIGluaXRpYWwgdGFyZ2V0IHJlZ2FyZGxlc3MNCj4+ PiBvZiB0aGUgZG9tMCB0eXBlLg0KPj4+DQo+Pj4gU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1 IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+DQo+Pj4gLS0tDQo+Pj4gICAgZHJpdmVy cy94ZW4vYmFsbG9vbi5jIHwgMjcgKysrKysrKysrKysrKysrKystLS0tLS0tLS0tDQo+Pj4g ICAgMSBmaWxlIGNoYW5nZWQsIDE3IGluc2VydGlvbnMoKyksIDEwIGRlbGV0aW9ucygtKQ0K Pj4+DQo+Pj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL2JhbGxvb24uYyBiL2RyaXZlcnMv eGVuL2JhbGxvb24uYw0KPj4+IGluZGV4IDhjNDRhMjVhN2QyYi4uOWI2NTMxZWIyOGI2IDEw MDY0NA0KPj4+IC0tLSBhL2RyaXZlcnMveGVuL2JhbGxvb24uYw0KPj4+ICsrKyBiL2RyaXZl cnMveGVuL2JhbGxvb24uYw0KPj4+IEBAIC03MjQsNyArNzI0LDggQEAgc3RhdGljIGludCBf X2luaXQgYmFsbG9vbl9hZGRfcmVnaW9ucyh2b2lkKQ0KPj4+ICAgIHN0YXRpYyBpbnQgX19p bml0IGJhbGxvb25faW5pdCh2b2lkKQ0KPj4+ICAgIHsNCj4+PiAgICAJc3RydWN0IHRhc2tf c3RydWN0ICp0YXNrOw0KPj4+IC0JdW5zaWduZWQgbG9uZyBjdXJyZW50X3BhZ2VzOw0KPj4+ ICsJbG9uZyBjdXJyZW50X3BhZ2VzID0gMDsNCj4+PiArCWRvbWlkX3QgZG9taWQgPSBET01J RF9TRUxGOw0KPj4+ICAgIAlpbnQgcmM7DQo+Pj4gICAgCWlmICgheGVuX2RvbWFpbigpKQ0K Pj4+IEBAIC03MzIsMTUgKzczMywyMSBAQCBzdGF0aWMgaW50IF9faW5pdCBiYWxsb29uX2lu aXQodm9pZCkNCj4+PiAgICAJcHJfaW5mbygiSW5pdGlhbGlzaW5nIGJhbGxvb24gZHJpdmVy XG4iKTsNCj4+PiAtCWlmICh4ZW5fcHZfZG9tYWluKCkpIHsNCj4+PiAtCQlpZiAoeGVuX3Jl bGVhc2VkX3BhZ2VzID49IHhlbl9zdGFydF9pbmZvLT5ucl9wYWdlcykNCj4+PiAtCQkJZ290 byB1bmRlcmZsb3c7DQo+Pj4gLQkJY3VycmVudF9wYWdlcyA9IG1pbih4ZW5fc3RhcnRfaW5m by0+bnJfcGFnZXMgLQ0KPj4+IC0JCSAgICAgICAgICAgICAgICAgICAgeGVuX3JlbGVhc2Vk X3BhZ2VzLCBtYXhfcGZuKTsNCj4+PiAtCX0gZWxzZSB7DQo+Pj4gLQkJaWYgKHhlbl91bnBv cHVsYXRlZF9wYWdlcyA+PSBnZXRfbnVtX3BoeXNwYWdlcygpKQ0KPj4+IC0JCQlnb3RvIHVu ZGVyZmxvdzsNCj4+PiAtCQljdXJyZW50X3BhZ2VzID0gZ2V0X251bV9waHlzcGFnZXMoKSAt IHhlbl91bnBvcHVsYXRlZF9wYWdlczsNCj4+PiArCWlmICh4ZW5faW5pdGlhbF9kb21haW4o KSkNCj4+PiArCQljdXJyZW50X3BhZ2VzID0gSFlQRVJWSVNPUl9tZW1vcnlfb3AoWEVOTUVN X2N1cnJlbnRfcmVzZXJ2YXRpb24sDQo+Pj4gKwkJICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICZkb21pZCk7DQo+Pg0KPj4gSXMgdGhlcmUgYW55IHNwZWNpZmljIHJl YXNvbiB3aHkgdGhpcyBzaG91bGQgYmUgbGltaXRlZCB0byBkb20wPw0KPj4NCj4+IEkgX3Ro aW5rXyB0aGlzIHNob3VsZCB3b3JrIGZvciBvdGhlciBkb21haW5zLCB0b28uDQo+IA0KPiBT YWRseSBpdCBkb2Vzbid0LCBJJ3ZlIGFscmVhZHkgdGVzdGVkLiAgVGhlIHZhbHVlIHJldHVy bmVkIGJ5DQo+IFhFTk1FTV9jdXJyZW50X3Jlc2VydmF0aW9uIG9uIFBWIGd1ZXN0cyBpcyBz bGlnaHRseSBkaWZmZXJlbnQgdGhhbg0KPiB3aGF0J3MgaW4geGVuX3N0YXJ0X2luZm8tPm5y X3BhZ2VzLCB3aGljaCBleGFjdGx5IHdoYXQgdGhlIHRvb2xzdGFjaw0KPiB3cml0ZXMgaW4g eGVuc3RvcmUuICBJIGFzc3VtZSB0aGVyZSdzIHNvbWUgb3RoZXIgc3R1ZmYgdGhhdCdzDQo+ IGFjY291bnRlZCBmb3IgaW4gZC0+dG90X3BhZ2VzLCBidXQgZG9uJ3QgcmVhbGx5IGtub3cg d2hhdCBJJ20gYWZyYWlkLg0KPiANCj4gQW5kIGluIHRoZSBIVk0vUFZIIGNhc2UgdXNpbmcg WEVOTUVNX2N1cnJlbnRfcmVzZXJ2YXRpb24gZm9yIGRvbVVzDQo+IHdvdWxkIGFsc28gdGFr ZSBpbnRvIGFjY291bnQgdGhlIFZpZGVvIG1lbW9yeSwgd2hpY2ggc2tld3MgdGhlIHRhcmdl dC4NCj4gDQo+IFRoaXMgaXMgdGhlIGJlc3QgSSBjb3VsZCBkbyBJJ20gYWZyYWlkLCBhdCB0 aGUgZXhwZW5zZSBvZiBoYXZpbmcgc28NCj4gbWFueSBkaWZmZXJlbnQgd2F5IHRvIGZldGNo IHRoZSBpbmZvcm1hdGlvbi4NCg0KTWVoLCB0b28gYmFkLg0KDQpGb3Igbm93IEkgdGhpbmsg d2UgbmVlZCB0byBsaXZlIHdpdGggdGhhdC4gQnV0IGZvciB0aGUgZnV0dXJlIEknZCBsaWtl IHRvDQpzdWdnZXN0IHRvIGFkZCBhIG5ldyBYZW5zdG9yZSBub2RlIG1lbW9yeS9yZXNlcnZh dGlvbi1kaWZmIGNvbnRhaW5pbmcgdGhlDQpkaWZmZXJlbmNlIGJldHdlZW4gWEVOTUVNX2N1 cnJlbnRfcmVzZXJ2YXRpb24gb3V0cHV0IGFuZCB0aGUgdG9vbHMnIHZpZXcNCm9mIHRoZSBk b21haW4ncyBtZW1vcnkgc2l6ZS4NCg0KVGhlIGJhbGxvb24gZHJpdmVyIGNvdWxkIHJlYWQg dGhhdCBub2RlIGluIGJhbGxvb25faW5pdCgpIGFuZCB1c2UNClhFTk1FTV9jdXJyZW50X3Jl c2VydmF0aW9uIGluIGNhc2UgdGhlIG5vZGUgaXMgZm91bmQuDQoNCg0KSnVlcmdlbg0K --------------IhatcEYAm5eeLfF4NTv0oIRc 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----- --------------IhatcEYAm5eeLfF4NTv0oIRc-- --------------YW4fPjHBHisnI07JsE40lX4P-- --------------MRnTJroy7w7wZdq10hsfw0r7 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/Ey8FAml6KLgFAwAAAAAACgkQsN6d1ii/Ey+Z 4gf+MlSsIuQV3dofZFV2/Fs6dzfB5nI0PFTBYe/gfdtxeQuKbN3QpMEemhGkis15quWXBJGP+On2 B0ec7n/JLMn8il7t3fSrUyj1/QVzo/WPdMtj2gtGRDpsf7AVygRKHKVOtBvPomLWqNOIXwoo4g7G W9/HpP90Pef5RGAEtOVhHJDPUl4pskh/uWlHV3sZr6P5ez/XKMS7w8cD8Oju1OBziJOA7xVgBH0A q8JjEkobWXRik7cugaRzitlGptI3eirf1b3hMPIA7YpeoVJ3QzKX27q3dbm/GTUMOoguq9ptLZek aYF2GgKJvvu292FEpzO2fN1jiGG5UrlT/f4GaBERPQ== =evqH -----END PGP SIGNATURE----- --------------MRnTJroy7w7wZdq10hsfw0r7-- From xen-devel-bounces@lists.xenproject.org Wed Jan 28 15:23:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 15:23:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215820.1525935 (Exim 4.92) (envelope-from ) id 1vl7OB-0001UH-TU; Wed, 28 Jan 2026 15:23:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215820.1525935; Wed, 28 Jan 2026 15: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 1vl7OB-0001UA-Qr; Wed, 28 Jan 2026 15:23:27 +0000 Received: by outflank-mailman (input) for mailman id 1215820; Wed, 28 Jan 2026 15:23: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 1vl7OA-0001U4-Jk for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 15:23:26 +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 49d55a91-fc5d-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 16:23:25 +0100 (CET) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-b8863db032dso899511466b.0 for ; Wed, 28 Jan 2026 07:23:25 -0800 (PST) Received: from ?IPV6:2a00:12d0:af5b:2f01:4042:c03:ce4d:a5a1? (2a00-12d0-af5b-2f01-4042-c03-ce4d-a5a1.ip.tng.de. [2a00:12d0:af5b:2f01:4042:c03:ce4d:a5a1]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8dbf2ed584sm138381266b.61.2026.01.28.07.23.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 07:23:24 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 49d55a91-fc5d-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769613804; x=1770218604; 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=xw8n1cO3pRZlLCxZTMCxZCBc8pIvFNjgqUOhrVncBHA=; b=GTKJ0GyVFE4wPeq3EbssfQnq01Tja/etQqrKswrAeTEpZAJiIlH9txJM3WwJq8VUIn DJRHSI1+oSluTsqLvZHEQwiOSvgVtMBwHjAmOlzTjZme+NuqnJr8bYhxks3JaFVaMNot /5acOwCMVOc6CqY7FtfDaV4KQZXQDiINTpxHJU2t9eSqmIGsCxtwh8L5+mKhY5iAO9dO c/l0m/+vZiaAYEJyI9R6W+oHshlv6CRvHomhBqQUbXzvh5Usa/KxB/vwmxskQptn6RC2 J9WLgNVVJTl4OM2ZPwQz7ZOV7v7RNCzPmMxzSoH8xsTa/4rawXS2kJJIRW7YTfG8Cssp ooiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769613804; x=1770218604; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xw8n1cO3pRZlLCxZTMCxZCBc8pIvFNjgqUOhrVncBHA=; b=rtbNi52Ej7LrovisUQyeuAn8YchnOWMyttjq+08x6To+/iosZUGqtmNo9ufyXycJ1n ik0SlDejNg5woTYqyZ/JKdLAB0d/UdsRiZKEVTlbEN3p/O1AsSv95TCjyfW0UkH0I+JW ax3q5WbhWhO5ZoA73VWMnZrb2nDkWM3mw5oVMXzw6Dyf8TPqH2EPyMllMqrfIHQUkVAl 4tRYuefLRIUq96ZH+jNqpcFU2kUEOXjFX9/XFy5ELimYG8boTUGdc61gYVjwq9G9MmtM EwYGkZxedrTLcLTnbcvqd5GM1wykyBjuW3IIaKq7NbcUi0rUy+mg3ylKog0VuU4oMMX5 PO5g== X-Forwarded-Encrypted: i=1; AJvYcCW95bf6rBXAp/QtCRPMK3wvzNGqFtx+1eyQwDKL8plY/eyA8LELiCTHPAo3KW3Wi/qC2b6sWIM5O4w=@lists.xenproject.org X-Gm-Message-State: AOJu0YxS4pvyPlKKRckmyJKqd0HDiuNrlK7FvoKHo+zGYfA+WdN/WvX+ DT2UWmD1I1WJg7PpuA/pX0FiKDclBBGhT5DL7gFyJjj+pnXAP2hd+3dywS6xw+6+TaM= X-Gm-Gg: AZuq6aITIhdMAE9UR6zOAPs99Ewt2aIkEnLXGkf3Ytse8aWAEH4hqX+APwGqEK8ylcK yFzzXm9StHlZQA0ZVIQ5wU3c1OKOLFdPv3uajpLK1szhBqGMIvnzS35JDKIJDcRdJlOV54p5snt UEzkgr9YbUMHNaTqMeLdLJ1lsrEpwCnqXgtFr6IL4NK1n4b+N05KNW64U0l48Cf4utzHFvFOm/Q 1Jid5YyZRwKxeBQXyt3w7V+8ZQCGH0hKWuPcB2PNFTzSTXz3YsfB2nURNvxJ9tb9c10NRVXTsUI 67ogW8O11jUBtLY5Ybrww7L78veVCG7kOBjjaxnX7lb8CZF1sQCeDCCyRzcvx+5V6DEwxR9+E6b UZkjb1xPiLUr+45kVmC/cv6anGPWyNQzlyMhRD2HndPK0MpUmwe3pX0kIlMBN2yiH1okcI9D4rj wh90IlDbQ58LQ5wS9dMVbjNmnbtM/MbiRVzC2GI60ltpWRmiCROu1SPAQJKJThB1ql4Gav4uFuG F1zVXIrim3k/5aiCHs8u1V6mftA8M0pF44PLg== X-Received: by 2002:a17:907:1c27:b0:b88:6542:86a0 with SMTP id a640c23a62f3a-b8dab39a855mr445835466b.54.1769613804398; Wed, 28 Jan 2026 07:23:24 -0800 (PST) Message-ID: <4b519e14-57fb-45be-a8b1-2c69c80cdcc4@suse.com> Date: Wed, 28 Jan 2026 16:23:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] Partial revert "x86/xen: fix balloon target initialization for PVH dom0" To: Roger Pau Monne , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Cc: James Dingwall , Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Stefano Stabellini , Oleksandr Tyshchenko References: <20260128110510.46425-1-roger.pau@citrix.com> <20260128110510.46425-2-roger.pau@citrix.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20260128110510.46425-2-roger.pau@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------49EsFbi001iLCSUqolznmAQH" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------49EsFbi001iLCSUqolznmAQH Content-Type: multipart/mixed; boundary="------------wMWfCqCxuKJMZMNt5UteTRd7"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Roger Pau Monne , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Cc: James Dingwall , Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Stefano Stabellini , Oleksandr Tyshchenko Message-ID: <4b519e14-57fb-45be-a8b1-2c69c80cdcc4@suse.com> Subject: Re: [PATCH 1/2] Partial revert "x86/xen: fix balloon target initialization for PVH dom0" References: <20260128110510.46425-1-roger.pau@citrix.com> <20260128110510.46425-2-roger.pau@citrix.com> In-Reply-To: <20260128110510.46425-2-roger.pau@citrix.com> --------------wMWfCqCxuKJMZMNt5UteTRd7 Content-Type: multipart/mixed; boundary="------------bMoZR76GhMUM0C60DiwAmRzr" --------------bMoZR76GhMUM0C60DiwAmRzr Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjguMDEuMjYgMTI6MDUsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToNCj4gVGhpcyBwYXJ0 aWFsbHkgcmV2ZXJ0cyBjb21taXQgODdhZjYzMzY4OWNlMTZkZGIxNjZjODBmMzJiMTIwZTUw YjEyOTVkZSBzbw0KPiB0aGUgY3VycmVudCBtZW1vcnkgdGFyZ2V0IGZvciBQViBndWVzdHMg aXMgc3RpbGwgZmV0Y2hlZCBmcm9tDQo+IHN0YXJ0X2luZm8tPm5yX3BhZ2VzLCB3aGljaCBt YXRjaGVzIGV4YWN0bHkgd2hhdCB0aGUgdG9vbHN0YWNrIHNldHMgdGhlDQo+IGluaXRpYWwg bWVtb3J5IHRhcmdldCB0by4NCj4gDQo+IFVzaW5nIGdldF9udW1fcGh5c3BhZ2VzKCkgaXMg cG9zc2libGUgb24gUFYgYWxzbywgYnV0IG5lZWRzIGFkanVzdGluZyB0bw0KPiB0YWtlIGlu dG8gYWNjb3VudCB0aGUgSVNBIGhvbGUgYW5kIHRoZSBQRk4gYXQgMCBub3QgY29uc2lkZXJl ZCB1c2FibGUNCj4gbWVtb3J5IGRlc3BpdGUgYmVpbmcgcG9wdWxhdGVkLCBhbmQgaGVuY2Ug d291bGQgbmVlZCBleHRyYSBhZGp1c3RtZW50cy4NCj4gSW5zdGVhZCBvZiBjYXJyeWluZyB0 aG9zZSBleHRyYSBhZGp1c3RtZW50cyBzd2l0Y2ggYmFjayB0byB0aGUgcHJldmlvdXMNCj4g Y29kZS4gIFRoYXQgbGVhdmVzIExpbnV4IHdpdGggYSBkaWZmZXJlbmNlIGluIGhvdyBjdXJy ZW50IG1lbW9yeSB0YXJnZXQgaXMNCj4gb2J0YWluZWQgZm9yIEhWTSB2cyBQViwgYnV0IHRo YXQncyBiZXR0ZXIgdGhhbiBhZGRpbmcgZXh0cmEgbG9naWMganVzdCBmb3INCj4gUFYuDQo+ IA0KPiBIb3dldmVyIGlmIHN3aXRjaGluZyB0byBzdGFydF9pbmZvLT5ucl9wYWdlcyBmb3Ig UFYgZG9tYWlucyB3ZSBuZWVkIHRvDQo+IGRpZmZlcmVudGlhdGUgYmV0d2VlbiByZWxlYXNl ZCBwYWdlcyAoZnJlZWQgYmFjayB0byB0aGUgaHlwZXJ2aXNvcikgYXMNCj4gb3Bwb3NlZCB0 byBwYWdlcyBpbiB0aGUgcGh5c21hcCB3aGljaCBhcmUgbm90IHBvcHVsYXRlZCB0byBzdGFy dCB3aXRoLg0KPiBJbnRyb2R1Y2UgYSBuZXcgeGVuX3VucG9wdWxhdGVkX3BhZ2VzIHRvIGFj Y291bnQgZm9yIHBhcGdlcyB0aGF0IGhhdmUNCj4gbmV2ZXIgYmVlbiBwb3B1bGF0ZWQsIGFu ZCBoZW5jZSBpbiB0aGUgUFYgY2FzZSBkb24ndCBuZWVkIHN1YnRyYWN0aW5nLg0KPiANCj4g Rml4ZXM6IDg3YWY2MzM2ODljZSAoIng4Ni94ZW46IGZpeCBiYWxsb29uIHRhcmdldCBpbml0 aWFsaXphdGlvbiBmb3IgUFZIIGRvbTAiKQ0KPiBSZXBvcnRlZC1ieTogSmFtZXMgRGluZ3dh bGwgPGphbWVzQGRpbmd3YWxsLm1lLnVrPg0KPiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUg TW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4NCg0KUmV2aWV3ZWQtYnk6IEp1ZXJnZW4g R3Jvc3MgPGpncm9zc0BzdXNlLmNvbT4NCg0KDQpKdWVyZ2VuDQo= --------------bMoZR76GhMUM0C60DiwAmRzr 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----- --------------bMoZR76GhMUM0C60DiwAmRzr-- --------------wMWfCqCxuKJMZMNt5UteTRd7-- --------------49EsFbi001iLCSUqolznmAQH 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/Ey8FAml6KesFAwAAAAAACgkQsN6d1ii/Ey8J RQgAnrk+e6Iq8ZPvE5im5BGkF2relqURxqoRgQCq+/OKE1wJ9mYYDRke/CDH9mSy3jZs2hS4vb+y ewBfYcYrlRN0O2zcewZD5Ul0pKugWNS51PT3ITwbRV2QiJzFW6eLPhPxod3MUtNpBG3vST2STqoy s43BDJ6T8erz8EP6DprvRnYP71T6vLaoJd/Kx+wxT4pxG7w9NasoowYMYgC+PkUa/lYgRvjguFJ6 cDQ8www8lG2J+b8w2XY+0w7oMzbOwI3Ajyuw9UuGH8huyZk1WwZzLXllVFzLeqpAOWDYm/aPZ4kY grytGYG8n5K8PzI2cgYIqXFfKtBBFYvIG6uIwWXLDg== =ZJhN -----END PGP SIGNATURE----- --------------49EsFbi001iLCSUqolznmAQH-- From xen-devel-bounces@lists.xenproject.org Wed Jan 28 15:24:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 15:24:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215830.1525945 (Exim 4.92) (envelope-from ) id 1vl7Ok-0001yt-8X; Wed, 28 Jan 2026 15:24:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215830.1525945; Wed, 28 Jan 2026 15: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 1vl7Ok-0001yh-5P; Wed, 28 Jan 2026 15:24:02 +0000 Received: by outflank-mailman (input) for mailman id 1215830; Wed, 28 Jan 2026 15:24:01 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl7Oj-0001U4-0U for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 15:24:01 +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 5ecb8afb-fc5d-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 16:24:00 +0100 (CET) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-b883787268fso1091712566b.3 for ; Wed, 28 Jan 2026 07:24:00 -0800 (PST) Received: from ?IPV6:2a00:12d0:af5b:2f01:4042:c03:ce4d:a5a1? (2a00-12d0-af5b-2f01-4042-c03-ce4d-a5a1.ip.tng.de. [2a00:12d0:af5b:2f01:4042:c03:ce4d:a5a1]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8dbf184e5dsm140514066b.43.2026.01.28.07.23.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 07:23:59 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5ecb8afb-fc5d-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769613840; x=1770218640; 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=iJXtJX3rf4c+Lnh7iULjxbkDmhdgdy/uWHLPN+e2hvY=; b=crwIg1OK7es97KQJ/6jhi0Z6R4W6Ma+amwBXwlxlq2dhoMlyGPXey1EWYw6qGvdmpM cu4bPb+h4sDwVkNJHybZ41QWO1mZvIccgEgr2f0Gf+O8pDVgjBJL0cRbhzXJux0SymLp IFLP4kYP00ZcxpNemNtpVLucEcQ0g0k9bkgBXxTyYa2536xi27ejs91vZuYzHs24fnuO iXRF77C/dzUlo8cMTZSSDXIktCLmkVcTQ8hykhjwTOmv7isJuL/RaqnC9+I87A0FRulA 5yq/Ex4aEx7Okf3YD/lcpAgTEHgWGutxJC6eoAo1MEUByFRgDlwPrKbgXEOdQIYFVwRF XkBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769613840; x=1770218640; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=iJXtJX3rf4c+Lnh7iULjxbkDmhdgdy/uWHLPN+e2hvY=; b=hnbiAFzqjiZ9isxCZRSlq3WMM1aN5RtEJXVA5Sq/SbrwyoN8c1ORD/TSssGd+8RRg3 cx6EaoE/AfXXsh+m16C+vr4mlf7g5iNou3C5eK1U76sEhqBAeP8f0Gh8mcRfwY8sqidU bjQoVgNJtad7h2egmAJUYlEwnuzGqQkMB5Q2CCeeTmxDBzldn2nqP2WatQ+X++ooJRMh dEOIpkz4Zzq9nlxh4aL7Wbd9TUZJMShsVX/zv4Fn4vWo5jyFYWYbyI1l7QXcVXPd1cuM wH02hd648GNuIi5PKLL+MByjXjgcgAs9CEpVkvtKpAEhX45pJF/Ibx5JsHmXoHiw+W5V 6Xpw== X-Forwarded-Encrypted: i=1; AJvYcCV/jNH7gGE2b7KahSlvWs/GW1xNkFAx8oJnHJfAPcv/POafW6M4IwqMU6w3yGgC9CTRRuE4rwXdqcg=@lists.xenproject.org X-Gm-Message-State: AOJu0YyPeTGLRuJjbNI30nE8HluuNw2auwBCNO4PYdKgXQFqfJzkgyAy tRZe5AI6V7sXIIdB9uqKcRxT7N0YDgP9RDYvWLMfDgqDnl64nt1Y87bFR0TTxKQK4bE= X-Gm-Gg: AZuq6aKZwu9EcheJxGAFrQncMdVK4IgQoSYwDmB8J3HyBKmEbDNR9IN6OOlO8MdgKh8 oO4ZBxWpu+ePnn/HfuxEob974lqeSbiRceM3OflYIi4b4RxHJ5mot/7Gb06xLv6Ddnkbbp+qKM2 uzwWlb94xwK0mfPm+0nh77EK3K76Ly+86jbStyC0t1swPXm8tF3I6b0THN2ScsxkIXx1vCSegkd NTismus37qzB42L+ArnDNoz4cvsG1CFrZfeJfGslsKWwfGAjZ+z7gMEc1sz2XwhWETj/ZIG8Xh+ hGdWt33CcbGdb6vMErjbTpCCX8I0gjRISNFWYmuvHsBxnWZGEMeicIgt7WhTAxl6eKzzPHRRSyK TlBAVPIezoBqUmNGuNOsU0yC6aneqD7N+iRpCoapDt2QkaslY6xnXy3aUSgFeLJNdsC9w19LbBT LiXZonQmzvMj9/uEJ06YWbJKuvX4U8gtpw8MOGBe6eKg2v7M+QmVVwzzz0Q8cX7cuq15E76yhO6 NhtKMeMaJ72KhVxkU7bDUI+vfBMZjSlNDanSA== X-Received: by 2002:a17:906:ee8c:b0:b8d:9d60:d591 with SMTP id a640c23a62f3a-b8dab37d75fmr436073266b.46.1769613839639; Wed, 28 Jan 2026 07:23:59 -0800 (PST) Message-ID: <7c05accc-91b7-45cf-b470-d8e134f2c99c@suse.com> Date: Wed, 28 Jan 2026 16:23:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] xen/balloon: improve accuracy of initial balloon target for dom0 To: Roger Pau Monne , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Cc: Stefano Stabellini , Oleksandr Tyshchenko References: <20260128110510.46425-1-roger.pau@citrix.com> <20260128110510.46425-3-roger.pau@citrix.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Autocrypt: addr=jgross@suse.com; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw== In-Reply-To: <20260128110510.46425-3-roger.pau@citrix.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------CI6UjaK7JgqygaxTat1t8RdG" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------CI6UjaK7JgqygaxTat1t8RdG Content-Type: multipart/mixed; boundary="------------yVlsGI4j6R0aVz9NU0LV8ycf"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Roger Pau Monne , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Cc: Stefano Stabellini , Oleksandr Tyshchenko Message-ID: <7c05accc-91b7-45cf-b470-d8e134f2c99c@suse.com> Subject: Re: [PATCH 2/2] xen/balloon: improve accuracy of initial balloon target for dom0 References: <20260128110510.46425-1-roger.pau@citrix.com> <20260128110510.46425-3-roger.pau@citrix.com> In-Reply-To: <20260128110510.46425-3-roger.pau@citrix.com> --------------yVlsGI4j6R0aVz9NU0LV8ycf Content-Type: multipart/mixed; boundary="------------CVK1EZwURNtcAL1UnuOQ0P8B" --------------CVK1EZwURNtcAL1UnuOQ0P8B Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjguMDEuMjYgMTI6MDUsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToNCj4gVGhlIGRvbTAg YmFsbG9vbiB0YXJnZXQgc2V0IGJ5IHRoZSB0b29sc3RhY2sgaXMgdGhlIHZhbHVlIHJldHVy bmVkIGJ5DQo+IFhFTk1FTV9jdXJyZW50X3Jlc2VydmF0aW9uLiAgRG8gdGhlIHNhbWUgaW4g dGhlIGtlcm5lbCBiYWxsb29uIGRyaXZlciBhbmQNCj4gc2V0IHRoZSBjdXJyZW50IGFsbG9j YXRpb24gdG8gdGhlIHZhbHVlIHJldHVybmVkIGJ5DQo+IFhFTk1FTV9jdXJyZW50X3Jlc2Vy dmF0aW9uLiAgT24gbXkgdGVzdCBzeXN0ZW0gdGhpcyBjYXVzZXMgdGhlIGtlcm5lbA0KPiBi YWxsb29uIGRyaXZlciB0YXJnZXQgdG8gZXhhY3RseSBtYXRjaCB0aGUgdmFsdWUgc2V0IGJ5 IHRoZSB0b29sc3RhY2sgaW4NCj4geGVuc3RvcmUuDQo+IA0KPiBOb3RlIHRoaXMgYXBwcm9h Y2ggY2FuIGJlIHVzZWQgYnkgYm90aCBQViBhbmQgUFZIIGRvbTBzLCBhcyB0aGUgdG9vbHN0 YWNrDQo+IGFsd2F5cyB1c2VzIFhFTk1FTV9jdXJyZW50X3Jlc2VydmF0aW9uIHRvIHNldCB0 aGUgaW5pdGlhbCB0YXJnZXQgcmVnYXJkbGVzcw0KPiBvZiB0aGUgZG9tMCB0eXBlLg0KPiAN Cj4gU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5j b20+DQoNClJldmlld2VkLWJ5OiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQoN Cg0KSnVlcmdlbg0K --------------CVK1EZwURNtcAL1UnuOQ0P8B 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----- --------------CVK1EZwURNtcAL1UnuOQ0P8B-- --------------yVlsGI4j6R0aVz9NU0LV8ycf-- --------------CI6UjaK7JgqygaxTat1t8RdG 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/Ey8FAml6Kg8FAwAAAAAACgkQsN6d1ii/Ey8l wwf+IGEu9R+nYG1/mZ+AccvgftL0SHWpiACf42nCnQRRCxJ2ZXFyV/LCQlcKojt2d0b+w9BEMhWX Nedo0ufwbtimWozY3ycdO81orJayQtJ5jxvcBHkuicJp8BN6Tzg4Q2nlkr4lO0szCJc6tuIU6Fss +Vbsrtai4QUtFbn5yZq+mIiQeyBCKQ1GWwyBEmNzWoczwZV4Gseqlf21wvNF9Q5iPTtNW+p4OLfo seGlNT3fbkQYFwzyCG5ceQjqG71owGMs1s+vslCKC9jXHdGd50++Z3bE2n5EC5zzn8WOfbojTZ5a o5Aco+twhAROtVcetspz7R516KIAZc9QwXOa9qtErw== =7CzO -----END PGP SIGNATURE----- --------------CI6UjaK7JgqygaxTat1t8RdG-- From xen-devel-bounces@lists.xenproject.org Wed Jan 28 15:28:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 15:28:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215844.1525954 (Exim 4.92) (envelope-from ) id 1vl7TB-0002rL-PW; Wed, 28 Jan 2026 15:28:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215844.1525954; Wed, 28 Jan 2026 15:28:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl7TB-0002rE-MW; Wed, 28 Jan 2026 15:28:37 +0000 Received: by outflank-mailman (input) for mailman id 1215844; Wed, 28 Jan 2026 15: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 1vl7TA-0002r8-0P for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 15:28:36 +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 0225b2fc-fc5e-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 16:28:34 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-47fedb7c68dso71738255e9.2 for ; Wed, 28 Jan 2026 07:28:34 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806d2585c7sm5132205e9.0.2026.01.28.07.28.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 07:28:32 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0225b2fc-fc5e-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769614114; x=1770218914; 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=QJiCCndpxa6ouT+7PHOSAAeS88/5FL9y7dxzhap/E4c=; b=WiY355F80AqEntlFwMtfEtibymuAK2Oh1TxB7UcDTIYLOnEfkVprClhgxfnKturnT3 xhWo9CmWCI6CDjyaT+920pEUJ67blNif5QVap3hgFlWUkDHY2nfAgVurwy6nGjMdJRTH Xp3GCrbUs/NVkZuFFiQEPCaYwWg4TsDDa/zgonnHAULQbckmVJM98UoYl0wQHvQDGYi2 zVsTAMf/aml8e6BlEbLYYyJmaBi/DBaIqn3fgXqVEUYqV4HuShJjQdKDvEehIiGLl2FY MRgSmkN0dR4l9OcMQFouqFfwgo3glIBh5dEqL2aK7/rtKfZd59jAxzCaiuhPEgSsRh38 m5Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769614114; x=1770218914; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=QJiCCndpxa6ouT+7PHOSAAeS88/5FL9y7dxzhap/E4c=; b=VphrM6WYMuKWLeCXkFQEZ0xKCyp1rhW28TsgXYgJNxkY0vcA2/PAkgvJMat8FZunMz 8VHOCcy0AiDMi5I2hUQ2rAcOdMhT4WMZ+4+Q1nFRPzLDoboMxr/rkzM85gnSIxP0l5bL OhdQUj+jKRul9mZDRO1FynxngFgOjFgBCqrDiP+YvYf433UEFjSLhQ+IB2jtgmwxEWrx uUl0IGeFxEmWd9d3+dTFrvxSgEaS+zBsp25WqObTrtvtGFTwgxAiHgxlWw9B4vAwKClS HFUSpNL08uBjK7GXgbGCbplPtW0ZOz2lOxhBf/563rujrcnkxY5TAe9Fub6lgt8ig5Yr Pn9g== X-Gm-Message-State: AOJu0Yw9cTr2BaOsrMQphTjf34cOhXAkwLTKyWyzUvOgcPB2gXL6tX/C MPtmtaW932aQGRM64BirgGyguV47V7Kj7kdMxDSUEbCMJ8qNsR0WnthcIqn7iSajCA== X-Gm-Gg: AZuq6aLCwT4r3BuJfmtl0q4UvXmIb4rY7aEybCDp1ZhV7Obkt9F+4knrsJ+CODdUEw0 ltKZtNH4ORfXDIQPhJteuG2j1llzhPKu/AvTWC/n10zth+W+kUadvZJXL4SsRkvk40ia9q/3+F0 waYsANB3pCWxxM+sORCU0VCF9h81kM/NFn40oA6C8oBbOcxe7DiFd/i/H6XfnBckbsN97NRjuqk 6CzGP2r4gBh8YsjvDSSkY1yo+h2GkLTXS8XbEn6DwmH3HXQkDU4QzfWwPq6A1ge+hL05oeOHYEJ 2/UGD2nV+WnSGutO1xZ0+fx1iXMxBQv0NYax+MHnfwqrgoDxCqNFeBntwgI9MWKPqxuvvrpNzVn z8308akDnO++yR3qbupmOlLgYu7HEJ+9mcyEA59QuI/HAVWgVjkkbfJ8usNUb+Sa+bODy7yr4xK mLf9/OJwvDwM5dq6UVApbsnY75cyOU7rtFAXtWRQtCUdvk43g5y0kpg9/7Wx/tYZmWUC5Oam6Zg HI= X-Received: by 2002:a05:600c:4e8b:b0:480:4a4f:c366 with SMTP id 5b1f17b1804b1-48069c486e6mr63034295e9.20.1769614113694; Wed, 28 Jan 2026 07:28:33 -0800 (PST) Message-ID: <9a0db632-adc1-4ab1-8905-b73f337cda39@suse.com> Date: Wed, 28 Jan 2026 16:28:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Ping: [PATCH] x86/EFI: correct symbol table generation with older GNU ld From: Jan Beulich To: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Marek Marczykowski , Daniel Smith Cc: "xen-devel@lists.xenproject.org" References: <27f291a3-6546-4834-a9cd-22a4636b152e@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: <27f291a3-6546-4834-a9cd-22a4636b152e@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 21.01.2026 11:05, Jan Beulich wrote: > See the extensive code comment. This isn't really nice, but unless I'm > overlooking something there doesn't look to be a way to have the linker > strip individual symbols while doing its work. > > Fixes: bf6501a62e80 ("x86-64: EFI boot code") > Reported-by: Roger Pau Monné > Signed-off-by: Jan Beulich This is, afaict, the only left piece which prevents "symbols: check table sizes don't change between linking passes 2 and 3" from going in. May I therefore ask for an ack or comments to move this forward? Thanks, Jan > --- > Should we try to somehow avoid the introduction of the two symbols when > using new enough ld, i.e. relocs-dummy.o not needing linking in? > > --- a/xen/arch/x86/xen.lds.S > +++ b/xen/arch/x86/xen.lds.S > @@ -339,6 +339,24 @@ SECTIONS > *(.reloc) > __base_relocs_end = .; > } > + > + /* > + * When efi/relocs-dummy.o is linked into the first-pass binary, the two > + * symbols supplied by it (for ./Makefile to use) may appear in the symbol > + * table (newer linkers strip them, for not being properly representable). > + * No such symbols would appear during subsequent passes. At least some of > + * those older ld versions emit VIRT_START as absolute, but ALT_START as if > + * it was part of .text. The symbols tool generating our own symbol table > + * would hence not ignore it when passed --all-symbols, leading to the 2nd > + * pass binary having one more symbol than the final (3rd pass) one. > + * > + * Arrange for both (just in case) symbols to always be there, and to always > + * be absolute (zero). > + */ > + PROVIDE(VIRT_START = 0); > + PROVIDE(ALT_START = 0); > + VIRT_START &= 0; > + ALT_START &= 0; > #elif defined(XEN_BUILD_EFI) > /* > * Due to the way EFI support is currently implemented, these two symbols From xen-devel-bounces@lists.xenproject.org Wed Jan 28 15:50:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 15:50:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215863.1525964 (Exim 4.92) (envelope-from ) id 1vl7nm-0005yP-Db; Wed, 28 Jan 2026 15:49:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215863.1525964; Wed, 28 Jan 2026 15:49:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl7nm-0005yI-A9; Wed, 28 Jan 2026 15:49:54 +0000 Received: by outflank-mailman (input) for mailman id 1215863; Wed, 28 Jan 2026 15:49: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 1vl7nl-0005yC-1z for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 15:49:53 +0000 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [2a00:1450:4864:20::336]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fb86ef58-fc60-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 16:49:51 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-4801eb2c0a5so67859115e9.3 for ; Wed, 28 Jan 2026 07:49:51 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e131ce58sm7693821f8f.20.2026.01.28.07.49.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 07:49:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fb86ef58-fc60-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769615391; x=1770220191; 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=4acLcQyeBBYunHIzgAqhUJQOZRSSVeSsjrl5szfzrZg=; b=iyc0t/6VdfbkLhqL8Z09ZbmQs+8IR2CLDB8mfgMYD4RvBXPinDUQbfHle06eZqE1XL KgGYggJvxDL27VlqqNvD5ytHgh1aTz0CwZq5QuiXknqC52DNOFr483k0xd76vDfG7v1j A2zQwQxRILqkjPasopI/t0coFfaBhuSWJKdR2JQNiiH9mYZ73wvie2Mz9hkphS52yuF7 /CK11qKUalegO5CCkRLPsVOUeaAIt9DGCCzILyksYlaYlEw7XNYr5KwQWl1emj/gqymX ANk9hqSXv4ODE1yIpIoey8ZZoXGPLF4gAqMSvY2FDK33JPvBWIo6FdGq+NF0FRP6MNnd QSLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769615391; x=1770220191; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4acLcQyeBBYunHIzgAqhUJQOZRSSVeSsjrl5szfzrZg=; b=AdJ+qvbxsOif45jV1Tv/ggOaQohlXABp12Qqyf2D+6QD8PoFBEQuq7VpQ6Q5PqF0BG ZctkZ3cK0Cvldtdhl4iVT+jcgJ7dZa99tgTKpmhE6xgRxSLi4TsZdVm9F31YGQXHpGRE OhKLgO0QXoRzNcgn0ubvzm6ouE7jbg0Y1EpAQEg1XPpmzqkpiGjPsmeXRu4DxS1meJ5P M0CV6Buk6ksWz9T5ykrohGu1nwJwvn9rlaISkPM7JWyPfioDu1kKib7qwOhkOzBK7Wvr dSqWMLWYlB8xttNPjySclqVIEzZmuEGeCBS3R1iM/lOCTptMxxzYyGBnIM3Lnr6E0OHx Kdfg== X-Forwarded-Encrypted: i=1; AJvYcCXFjdc7UIzF/euKCfQOVmNzKVkcvEePQu5H7b1mcvD+7gL+4c1mdkBCl7BXJZ0PDom//CNdE0BivLY=@lists.xenproject.org X-Gm-Message-State: AOJu0YxVclNceM+bZAf1j7wJkjVgygEzO+yI39FjMXKYduOKY5xwnM1K r0LF87SnJgHYrNTbKi79JP5EoBaKdfRqHVi2FB+Qdz6Dfbsu350oUfum X-Gm-Gg: AZuq6aJzgtjKlE/L5R8wQWGWoEeqr1y+6DzhwY+zGhFYiO4S1NqvtySYayysSJGH793 lnDZHZEBEfIY9E40D3u6oZv9kpBQemPuxtrBZ5tTHzhqDG6AxFl/eNT/GL2vKhvhL9IRIjvlx56 dxePIyKVsOaaThUS+bUBn0dWcVmek+ptaO/qn2r0o80Ancp1UbDPPV8JFO2Pr4xgak3lqQHbgP3 hlRw+INltWrT0QUPLGEiCJlRjLmxo60+RNq310/9RMBqe6ogLP+UXZFgrVntypsml0CPJfWyAdK FR+Rb08uXf4M1W9xE7Un5gncFYyhHArrokgSKwU9flprZJwNKyRjMFvSEVm3ZKfJyKIC49jm4N7 45tcV+LqcWlWlMzEuJUDs11BjlHUL7B3q7mzDIcHqVVjZfTge9+8z+BAeZ6+Az7bB9Gy813IZeg OHImQyvo+ZrGvypxPd3CjvI+UGFDtHj/nCEJLmq7PxlVdTv/Zz9amXSt/jHkKlBfA= X-Received: by 2002:a05:600c:458a:b0:46f:c55a:5a8d with SMTP id 5b1f17b1804b1-48069c0fdafmr65782685e9.4.1769615390914; Wed, 28 Jan 2026 07:49:50 -0800 (PST) Message-ID: <85332b14-60c5-46da-9d3b-ddf2e34f9a59@gmail.com> Date: Wed, 28 Jan 2026 16:49:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5] xen/riscv: dump GPRs and CSRs on unexpected traps To: Jan Beulich Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/28/26 4:17 PM, Jan Beulich wrote: > On 28.01.2026 13:53, Oleksii Kurochko wrote: >> --- a/xen/arch/riscv/traps.c >> +++ b/xen/arch/riscv/traps.c >> @@ -99,11 +99,65 @@ static const char *decode_cause(unsigned long cause) >> return decode_trap_cause(cause); >> } >> >> -static void do_unexpected_trap(const struct cpu_user_regs *regs) >> +static void dump_general_regs(const struct cpu_user_regs *regs) >> { >> - unsigned long cause = csr_read(CSR_SCAUSE); >> +#define X(regs, name, delim) \ >> + printk("%-4s: %016lx" delim, #name, (regs)->name) >> + >> + X(regs, ra, " "); X(regs, sp, "\n"); >> + X(regs, gp, " "); X(regs, tp, "\n"); >> + X(regs, t0, " "); X(regs, t1, "\n"); >> + X(regs, t2, " "); X(regs, s0, "\n"); >> + X(regs, s1, " "); X(regs, a0, "\n"); >> + X(regs, a1, " "); X(regs, a2, "\n"); >> + X(regs, a3, " "); X(regs, a4, "\n"); >> + X(regs, a5, " "); X(regs, a6, "\n"); >> + X(regs, a7, " "); X(regs, s2, "\n"); >> + X(regs, s3, " "); X(regs, s4, "\n"); >> + X(regs, s5, " "); X(regs, s6, "\n"); >> + X(regs, s7, " "); X(regs, s8, "\n"); >> + X(regs, s9, " "); X(regs, s10, "\n"); >> + X(regs, s11, " "); X(regs, t3, "\n"); >> + X(regs, t4, " "); X(regs, t5, "\n"); >> + X(regs, t6, " "); > DYM "\n" here? Oh, right, it should be "\n". > >> +#undef X >> +} >> + >> +static void dump_csrs(const char *ctx) >> +{ >> +#define X(name, csr, fmt, ...) \ >> + v = csr_read(csr); \ >> + printk("%-10s: %016lx" fmt, #name, v, ##__VA_ARGS__) >> + >> + unsigned long v; >> + >> + X(htval, CSR_HTVAL, " "); X(htinst, CSR_HTINST, "\n"); >> + X(hedeleg, CSR_HEDELEG, " "); X(hideleg, CSR_HIDELEG, "\n"); >> + X(hstatus, CSR_HSTATUS, " [%s%s%s%s%s%s ]\n", >> + (v & HSTATUS_VTSR) ? " VTSR" : "", >> + (v & HSTATUS_VTVM) ? " VTVM" : "", >> + (v & HSTATUS_HU) ? " HU" : "", >> + (v & HSTATUS_SPVP) ? " SPVP" : "", >> + (v & HSTATUS_SPV) ? " SPV" : "", >> + (v & HSTATUS_GVA) ? " GVA" : ""); >> + X(hgatp, CSR_HGATP, "\n"); >> + X(hstateen0, CSR_HSTATEEN0, "\n"); >> + X(stvec, CSR_STVEC, " "); X(vstvec, CSR_VSTVEC, "\n"); >> + X(sepc, CSR_SEPC, " "); X(vsepc, CSR_VSEPC, "\n"); >> + X(stval, CSR_STVAL, " "); X(vstval, CSR_VSTVAL, "\n"); >> + X(status, CSR_SSTATUS, " "); X(vsstatus, CSR_VSSTATUS, "\n"); >> + X(satp, CSR_SATP, "\n"); >> + X(scause, CSR_SCAUSE, " %s[%s]\n", ctx, decode_cause(v)); > For it, in particular the "ctx" string, to stand out, perhaps this wants moving > first in the function? I would be grateful for this. > > With the adjustments (happy to carry out while committing, so long as you agree): > Acked-by: Jan Beulich Thanks a lot. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Jan 28 17:49:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 17:49:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215917.1525975 (Exim 4.92) (envelope-from ) id 1vl9fW-00048N-Iq; Wed, 28 Jan 2026 17:49:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215917.1525975; Wed, 28 Jan 2026 17:49:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vl9fW-00048F-Dt; Wed, 28 Jan 2026 17:49:30 +0000 Received: by outflank-mailman (input) for mailman id 1215917; Wed, 28 Jan 2026 17: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 1vl9fV-000489-Ei for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 17:49:29 +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 b072bdc8-fc71-11f0-b160-2bf370ae4941; Wed, 28 Jan 2026 18:49:28 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SJ0PR03MB6488.namprd03.prod.outlook.com (2603:10b6:a03:397::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Wed, 28 Jan 2026 17:49:24 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.006; Wed, 28 Jan 2026 17:49: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: b072bdc8-fc71-11f0-b160-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MDaIBalq5F81qjjQMz+p/f1P+6/cqauDt3IH10InZXCb6anO8WSFhGBV9v6YYSCaZOblaSJRjjpyTXhuil/J5dhj2pQXxXRDGv2ZXpYEV688+n9pTaGTm+wkKL+Lfp6JFY3Q3m4srBueo/zetv23nujE5zGWG8XTlbJrV5NhmzB8kCO1PT/0BNRHYr5oCqxpaDLRWpBgQOXoyD4J0AY1pjC94hTZ+61Brpi7YlEC0+GebnkEV2f5zm13FCra14ZO3mFSK1y9RMdjcBkvuSy0Pi1tn2D/ENgLKBeXXtEjT3AiWNbmZqHWeP9krpNlAvqVUsHWFeAV29imiL7wQ1qovg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XpKW9dbfwCCxuO08czMMhuq8JZ763hOj6WAxtJmoQWE=; b=tVUATuH+yukG/XCFDJMbpcQXAtEOOkLgh5Fs7kZIpstygH3k1cOpmwOATaY+JrFjU/AUXccLIKfykr6ycaarngFLqq/4uWwa6LN3hmPlAJh7CySC/gSGJvIedOGlR3np6DY3/aD0cRdLaeAwmJBbJNuhBzR5H3j4whTqmUAZyXU4Mz4xs6ymZ0t7dRvIUyRUXWYpzgqrC5Uyh7LBXw7YW3IzN5JSQ+0ZWEwL52QZ7fdQWA0PnvzuVJ5RrIDF6e0BD3UZHuzQjdTXUNHFHQt1rOabwDYsQianYDO/96/eptPhaid9CovCO+/n1EkcgVDtMUm82lm3QaHSJ++0zR/GMw== 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=XpKW9dbfwCCxuO08czMMhuq8JZ763hOj6WAxtJmoQWE=; b=EtM/kxbGwI3V8GJS+icBbXrZtmHwfwqiX8uJ1vMHMpVyCLAF9fFBkxd9h096uebwUbpufXcnE1qJ9H5cJTubg9ekT6mWEbwIX5ZX9NKiRgKXKI3JAx5nUp7XzGU1m8P/11kvQNxZ2NK3XFBTYjiypzTUNVHfffQ9okO9Z4Rq1fU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 28 Jan 2026 18:49:20 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , Stewart Hildebrand Subject: Re: [PATCH v2 2/4] PCI: determine whether a device has extended config space Message-ID: References: <58091dc1-7bda-4536-8200-2d0a5679d4d1@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: PA7P264CA0319.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:395::19) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SJ0PR03MB6488:EE_ X-MS-Office365-Filtering-Correlation-Id: 118537f1-1c4d-4371-68c8-08de5e9592be 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?OFNDMnlCaFdmelgvdjJwQlZqSmJDS0lqSGVuRzFoUjFxdloydDRzY0NPV3h1?= =?utf-8?B?NmI0bFhuM1lSeHVrTGZsVWVpTGRzcmV5SHFmdVgxSjh6MXZZZEdHU1FhNTcw?= =?utf-8?B?emdiaWR1RlkwbUtUNnBIemhYcmUzWkFIcWJYcllPTHk3anYwWkJITms0cDdk?= =?utf-8?B?MUhtWCszNUZqaGR6blBsT2dpcXRCTmlsWldYS2xMN2lGdjJrT2doUHo0OUN6?= =?utf-8?B?QXE1RXA3dzJscFQwQ2IrdmcybC94OW1MVFRRdTFweUZWVzFSdGNobkZ5eUZo?= =?utf-8?B?NEJhcWtYWWtrUThCOTNLSTQyL2E4MnVLamdROVQyU0VPdkgyUjhWT3l1TUEy?= =?utf-8?B?SlRqZzB6UFE0MkZqdVoza01sWjFXanlCc1dySHlZLy9pbGI4bHZQdmswWjl0?= =?utf-8?B?SEJHMlZ4T3BRbEVXcndiTnpJUWRKdWtaSjB2ZEZ6OC9INVJQM1lDbmg0dkZF?= =?utf-8?B?dFBPaG96czdQby9KYUk0YzBJN1VjTllVK3RWVit5NktqT3NTRE85bmxPRTZU?= =?utf-8?B?c2FTNUtVNE84OXNBd0lFWDRacFU0L2dJZ2NTVjRHOUVpZldNMm1jVU5lQnFa?= =?utf-8?B?SldiK3Ayc3A2MUd4OWJXUlVPMjNiU3VoZlE4eUNTWUZWWThJQndyWEdxcVpu?= =?utf-8?B?RmY2M2d4SytxUkVzcVdmWTJDd2x5L2FGTXlkY0ZjemtSOFU4NHlCNFArWVdU?= =?utf-8?B?L1U0cGZmV0o5OGRydTN4dHB1QmhqdThGOVEwWHUvbC9ObFl4d29PQUNEbXQ4?= =?utf-8?B?bnJZeldOY2FBSi9nWnZrOExmSXhuSnFtTUVXQVdIRmx1VDNvWGxPQTVTaUhH?= =?utf-8?B?OVFHVS9SOGxteTI4QjIrZDBPSytJZ2o5RlNFdk4wdGtWeXlFL0dSZGtpaS9B?= =?utf-8?B?akJxY3I4UzZhQ1NzMURQTGc2RmhXbzJ3R2hKNHpoVG5hdzFFanNtbE5IZWo4?= =?utf-8?B?Qmt6OUVXT1d5cXd1cCtHVXdiVG5ROVloOWVhVkhPZndnMlRKLzVCTitzSWo2?= =?utf-8?B?MmFETHhFak1tdmNNdGkweEYwYU9pTlA3OTFad0ptNVV4OGpqbitQcmV0U0Iy?= =?utf-8?B?SHhHRFJSU0oyZDBUZEhoOHBOYnNEWENVRW1VQVpxaTBsR085RHNyN2JnWnNm?= =?utf-8?B?QmlCbGdkTG9QUDhQQmc1NjhSdU9qeElOZ2hFcTEzeldlYTgwRFdxRUs1dHov?= =?utf-8?B?cU9KU3ZYMDFsSTc1RVJ4ckduZEl5dXVUZFZyY2h0OE1TdDNFb1pPTmIrV3h0?= =?utf-8?B?clJIMkFMUmN3MUZMclNMeDFlN2x2Z3hTSjJOYXNFVVU1TlJrREhNbjJ5b1hO?= =?utf-8?B?VGdaQXJOT05QdjJLNktZZnBZNXhVYjBSMHdBOEhDZUtVQnoxQ1REdnl2YTFS?= =?utf-8?B?SWJ4VHpkRndPbHVnWkNWUE9Yc25tblJPcW1qLzhWTGR2VVVUOERLTnVVOHpW?= =?utf-8?B?RkZtRWU0S29tMFhJM2hYMmIxcjRRZjZvaXVoSmVZL0FZVkdOTC9kWCs5aDBP?= =?utf-8?B?S1dDMG5tTk5lMHlpM3MzVVF2ZVJBLzJYMC9DT3J5aUpUSlhZSjNyT3lsKzlr?= =?utf-8?B?T1NMbVRUWVpNNGNWNitEZ2J6UXFkN2xDOFZpTnJrbXN6emRhSEVsM0tJWDZ1?= =?utf-8?B?QWh3YW5zRzhIeXlzRXdHQWtReG1xNmpVRlAvRjVhN3ZFaUtPS3RoMHoyRkVl?= =?utf-8?B?Um5nTklUbWtIU1BJRjlDM0FJUUF2bUk2RktFZGRqc25jakxuZXlLaFVIN251?= =?utf-8?B?ejhwS3dUc1h5SHU1Vlk2bFF0RVk3b3I3dXdCdUx1VXppMWVpa1BkMUdNUzZs?= =?utf-8?B?Skg5UEh2NUZHWDVtcEc0cVIrcWNORU5NMVY4eFZKYm5pWDNQSGE4a2ZtcVRv?= =?utf-8?B?WU5SNzdjRnVzOWJwVExqcUxyZmQ2R0IwU3hIL1cveTVJSnhXV3NzRElBdkVG?= =?utf-8?B?SUdvcWNsV1hCZTdHOCtTb3Q5cUpGUm5lOUt0QjRkZ25GTG9yL1RCYXpFcVc3?= =?utf-8?B?K24wd0cyakRlcXpWcjRDU09pY0VOMytGQ0VsQmZiZFpFUUFrRXA5V0xFd3Jj?= =?utf-8?B?Z2pZS1ZneWxGTlhNOGNyR1JBZ2EvVGQyUkZvUXJubkloTXdlVTVYNGsya0JI?= =?utf-8?Q?SUfY=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UGl2Qk9qY3puRUlENFFDM1ZzRWpZclJJd0lVYlhTakFSNmtobjVXNzcycmVp?= =?utf-8?B?VlArdUxjT0pzb3hoVGVocnJtNHMzajhCbzZWMEJjYUFtK1dhVEFoZE1WajBH?= =?utf-8?B?VTJpckFVRUFKZzdXNVlrb3Y1ZjVBZWV2ZmdJRXVSdWU1bjc4YzBhN0E2S1o5?= =?utf-8?B?NnBCMU9ZV0JTUllZNWp3MUN0N01yeEhCOXNndXVqZ29USjkyenZWVnMwaTM2?= =?utf-8?B?RW1wWjFmYTZ4eWl0Q2hvMzhNLzFFRVB4b3JPMzBVYW1hK2YzSW1ZUkx2LzlC?= =?utf-8?B?bGw5V0k4WDZ6dkNxTVNoSFA2SEhNV2tFZklzbDZqcUZ2NTgvV0ZhamFneldE?= =?utf-8?B?dnhFMGlFNW9rRHRvWno4S3BrSHYvNUlCNHkwZUkvV2Q4Y2RiQzNEcGVpcGVh?= =?utf-8?B?NEt5Sm9jWGZ6ZVA3VHc5c3Q1RmZFM003b3RDM3ROSHJhNmFTbGdOTlJKc1JV?= =?utf-8?B?TG5za0xadlBWbnJFWTFuL2s5MFVMVUxia3pEaXNSczZ2bDJ6QXJlUFpsK3pO?= =?utf-8?B?Q1RoUTRvemhscG1OQVFkbysvVTkvVzNYdTliYnFOWG5ZMjFkN2xST1JuYlRw?= =?utf-8?B?eHIrRG1UV0ZXa0VOZW84bS9icVJ0N0VXM3ZSMnZabXExWGk3SEVONS8ySFZr?= =?utf-8?B?di9vTllvTlFlQURhMDlWUEtHeE9ucjB5emE1YXp5SU12MlhOd2FWSGhwWkFP?= =?utf-8?B?dys0Rys1S0J4citsTkJ6L1h6dEJNOWloNWNibXBaQ2dpTXVObEFQMG5FMzds?= =?utf-8?B?b25JTDZCQTdnOGw5WlFzQW5Pd2RQUkUrT3ZZa2lQMEhIU3dTWTduVEhXMTFi?= =?utf-8?B?U3p1ZEZLa0g1eHNQS1NBNGl2RXBta3pTajhwRHozVDhQdGZzVnUyeE1EYXZT?= =?utf-8?B?SDRyTnpseXFqVElycGFZZlJIZGFLcm1UWmc2aEcrTHNVVllGdTR2Z1RPQWYv?= =?utf-8?B?TER6S2VvQktUazR1SjVmaDRUdFBKZDY5bWJqUU43cnpUc05ETnBwaURqQzZN?= =?utf-8?B?bGRWcHNaMUZqNXJ3c0RSNmo4MnhpakpKTzFiRVpOQmtyT0tucVo1VDIyNVdI?= =?utf-8?B?VTZUMDM3ZFVmakt3Z290N0N5QlN6RzZGTkErRS9lek5jUFZVcVkrRUZIaCtl?= =?utf-8?B?YjdqQWRKTVBoNWpEbkZ3azVJZE1hU3lWYms4MFlnVG1ydmRnTDlxUi9JZG5u?= =?utf-8?B?UFJmOURGZ291OGd1Qm5Zanc1c2xBQW5Xc1hmcTFVSDVvUXJqR2lKUUV6OC9G?= =?utf-8?B?M25BaklLc3VRV1VUbmJjNE44dmV5SnhHZWZ0TG0zK2xoSENuemZCTjJBWlp2?= =?utf-8?B?U2UwZHdaRU1pcTdKUXFqOVBOMnh3MW1HQ2JtaU1ORU45TkNWMjhJdFZBbnZS?= =?utf-8?B?WGd5VWZxYmNlNml3NWJ2VFVYM0dtVEhDOXBOUHBva2VHNmczRGdJdlFpK1d2?= =?utf-8?B?b0M5ZEd2UG1DZldRWWtwMm1CSXM0Y1dxWGU5RDZ5akJnbFpMc29nWnVRdU5w?= =?utf-8?B?OUFTVnQ2YlBzQ0xTZkZIREFHU3V3UnRuQUFDMktzOUdPaU5Mcm9OT0ZmUUhK?= =?utf-8?B?SG5DRU9VWndrQStFTVhmY0ZFblBaUE5nRUdNVWpOWjF2cFU3elNkR3RZSTE2?= =?utf-8?B?cmhlRGNiSW56Rm4xVlAzR2ZFeDFaY2ptb1p1SzdRNldsNGZEdEgrdkgxTWhR?= =?utf-8?B?MjZLcU1Tam55TXJ6R2JYVkNpcWtWQUp4dlVsMU5xQk83dUhlbXl3VEtQM3l5?= =?utf-8?B?NXhNakRLQ1gyNXRSaU5ab2hTTmtkQkk0SVRCMVlFdm45ZlQvOVg3WmdIYVN4?= =?utf-8?B?cDU4bXlEQndrU2JFbkYycU5BRlVXUGx5bXpEbmVxT2VwRllsajlVR1BLTCtz?= =?utf-8?B?YjFEZ2VVQW5hcHBPUXY0amIvM09iZDJkZDQzMnByUklkU3BsekVVS29YVzQr?= =?utf-8?B?WlNXbXMxaWNUK0huMjNrR05HcElqeEN4aURyaXZxTmZtd2xkL1VKYTFRWkRj?= =?utf-8?B?cTMrcWg2dUN4ekliTzBDWGk2a2s1bzgzVk8vRXBGMW5jcUNWT2hWUURldFBz?= =?utf-8?B?M3VkTWxjWmVmR1dJTk5LaTdJNEJjYWduTzBqenN0bXE0U3FIU2xyZjlTYjJE?= =?utf-8?B?Q2JwdEh2VnM0UFFkbFVYU21FRkdYN0tJZVlVWG1lSGp2Z1RYTEtEcm5TbmRV?= =?utf-8?B?QVR5ekEwQXVpWU9UU0pFWVRqenZiNVVRUWkydGlacjdmYWgzT0k1K0t5Mzcz?= =?utf-8?B?NlBqM3NZdTNpMUZBNFpxbXhRMnVibUtObVdjSU9xN1VkZ2FiV1paZkhNYTN5?= =?utf-8?B?aVJ5NDBlZ0hPZWFhbFZVQ0tldkhiL2hHZno2WkF4T0tpWmdxVkd2dz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 118537f1-1c4d-4371-68c8-08de5e9592be X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 17:49:24.0465 (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: 5FzvzbZrRSmAM1iVNgkGnCrQ9q0XbBOGV7YE7pG26on1AvAI6hnOXMxebu4p18cbozX1ktbFYtolS6mPG7DVjw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB6488 On Mon, Jan 19, 2026 at 03:46:55PM +0100, Jan Beulich wrote: > Legacy PCI devices don't have any extended config space. Reading any part > thereof may return all ones or other arbitrary data, e.g. in some cases > base config space contents repeatedly. > > Logic follows Linux 6.19-rc's pci_cfg_space_size(), albeit leveraging our > determination of device type; in particular some comments are taken > verbatim from there. > > Signed-off-by: Jan Beulich > --- > Should we skip re-evaluation when pci_mmcfg_arch_enable() takes its early > exit path? Possibly - we expect no change in that case. However it would need to propagate some extra information into the callers. I could see that as a followup optimization. > The warning near the bottom of pci_check_extcfg() may be issued multiple > times for a single device now. Should we try to avoid that? Yeah, I've made some comments about that below. Not sure how common those broken bridges are, the comment just mentions two specific models. Adding yet another boolean to track that is cumbersome, and what we would like to do is mark the bridge as broken, instead of every device behind it. > Note that no vPCI adjustments are done here, but they're going to be > needed: Whatever requires extended capabilities will need re- > evaluating / newly establishing / tearing down in case an invocation of > PHYSDEVOP_pci_mmcfg_reserved alters global state. Hm, you probably want to do something similar to re-scanning the capability list, but avoid tearing down and re-setting the vPCI header logic to prevent unneeded p2m manipulations. We have no easy way to preempt this rescanning from the context of a PHYSDEVOP_pci_mmcfg_reserved call. > Linux also has CONFIG_PCI_QUIRKS, allowing to compile out the slightly > risky code (as reads may in principle have side effects). Should we gain > such, too? I would be fine with just a command line to disable the newly added behavior in case it causes issues. > --- > v2: Major re-work to also check upon PHYSDEVOP_pci_mmcfg_reserved > invocation. > > --- a/xen/arch/x86/physdev.c > +++ b/xen/arch/x86/physdev.c > @@ -22,6 +22,8 @@ int physdev_map_pirq(struct domain *d, i > struct msi_info *msi); > int physdev_unmap_pirq(struct domain *d, int pirq); > > +int cf_check physdev_check_pci_extcfg(struct pci_dev *pdev, void *arg); I'm not sure why you need the forward declaration here, the function (in this patch) is just used after it's already defined. > + > #include "x86_64/mmconfig.h" > > #ifndef COMPAT > @@ -160,6 +162,17 @@ int physdev_unmap_pirq(struct domain *d, > > return ret; > } > + > +int cf_check physdev_check_pci_extcfg(struct pci_dev *pdev, void *arg) You can make this static I think? > +{ > + const struct physdev_pci_mmcfg_reserved *info = arg; > + > + ASSERT(pdev->seg == info->segment); > + if ( pdev->bus >= info->start_bus && pdev->bus <= info->end_bus ) > + pci_check_extcfg(pdev); > + > + return 0; > +} > #endif /* COMPAT */ > > ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) > @@ -511,6 +524,11 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H > > ret = pci_mmcfg_reserved(info.address, info.segment, > info.start_bus, info.end_bus, info.flags); > + > + if ( !ret ) > + ret = pci_segment_iterate(info.segment, physdev_check_pci_extcfg, > + &info); > + > if ( !ret && has_vpci(currd) && (info.flags & XEN_PCI_MMCFG_RESERVED) ) > { > /* > --- a/xen/drivers/passthrough/pci.c > +++ b/xen/drivers/passthrough/pci.c > @@ -422,6 +422,9 @@ static struct pci_dev *alloc_pdev(struct > } > > apply_quirks(pdev); > + > + pci_check_extcfg(pdev); > + > check_pdev(pdev); > > return pdev; > @@ -718,6 +721,11 @@ int pci_add_device(u16 seg, u8 bus, u8 d > > list_add(&pdev->vf_list, &pf_pdev->vf_list); > } > + > + if ( !pdev->ext_cfg ) > + printk(XENLOG_WARNING > + "%pp: VF without extended config space?\n", > + &pdev->sbdf); You possibly also want to check that the PF (pf_pdev in this context I think) also has ext_cfg == true. > } > } > > @@ -1041,6 +1049,75 @@ enum pdev_type pdev_type(u16 seg, u8 bus > return pos ? DEV_TYPE_PCIe_ENDPOINT : DEV_TYPE_PCI; > } > > +void pci_check_extcfg(struct pci_dev *pdev) > +{ > + unsigned int pos, sig; > + > + pdev->ext_cfg = false; I think I would prefer if the ext_cfg field is only modified once Xen know the correct value to put there. It would also be nice to detect cases where the device has pdev->ext_cfg == true but a new scan makes it switch to false. Which would signal something has likely gone very wrong, and we should print a warning. > + > + switch ( pdev->type ) > + { > + case DEV_TYPE_PCIe_ENDPOINT: > + case DEV_TYPE_PCIe_BRIDGE: > + case DEV_TYPE_PCI_HOST_BRIDGE: > + case DEV_TYPE_PCIe2PCI_BRIDGE: > + case DEV_TYPE_PCI2PCIe_BRIDGE: > + break; > + > + case DEV_TYPE_LEGACY_PCI_BRIDGE: > + case DEV_TYPE_PCI: > + pos = pci_find_cap_offset(pdev->sbdf, PCI_CAP_ID_PCIX); > + if ( !pos || > + !(pci_conf_read32(pdev->sbdf, pos + PCI_X_STATUS) & > + (PCI_X_STATUS_266MHZ | PCI_X_STATUS_533MHZ)) ) > + return; > + break; > + > + default: > + return; > + } > + > + /* > + * Regular PCI devices have 256 bytes, but PCI-X 2 and PCI Express devices > + * have 4096 bytes. Even if the device is capable, that doesn't mean we > + * can access it. Maybe we don't have a way to generate extended config > + * space accesses, or the device is behind a reverse Express bridge. So > + * we try reading the dword at PCI_CFG_SPACE_SIZE which must either be 0 > + * or a valid extended capability header. > + */ > + if ( pci_conf_read32(pdev->sbdf, PCI_CFG_SPACE_SIZE) == 0xffffffffU ) > + return; > + > + /* > + * PCI Express to PCI/PCI-X Bridge Specification, rev 1.0, 4.1.4 says that > + * when forwarding a type1 configuration request the bridge must check > + * that the extended register address field is zero. The bridge is not > + * permitted to forward the transactions and must handle it as an > + * Unsupported Request. Some bridges do not follow this rule and simply > + * drop the extended register bits, resulting in the standard config space > + * being aliased, every 256 bytes across the entire configuration space. > + * Test for this condition by comparing the first dword of each potential > + * alias to the vendor/device ID. > + * Known offenders: > + * ASM1083/1085 PCIe-to-PCI Reversible Bridge (1b21:1080, rev 01 & 03) > + * AMD/ATI SBx00 PCI to PCI Bridge (1002:4384, rev 40) > + */ > + sig = pci_conf_read32(pdev->sbdf, PCI_VENDOR_ID); > + for ( pos = PCI_CFG_SPACE_SIZE; > + pos < PCI_CFG_SPACE_EXP_SIZE; pos += PCI_CFG_SPACE_SIZE ) > + if ( pci_conf_read32(pdev->sbdf, pos) != sig ) > + break; > + > + if ( pos >= PCI_CFG_SPACE_EXP_SIZE ) > + { > + printk(XENLOG_WARNING "%pp: extended config space aliases base one\n", > + &pdev->sbdf); Hm, I think this shouldn't be very common as it seems limited to a short list of bridges. However every device under such bridge would be affected and repeatedly print the message. I wonder whether we should make this XENLOG_DEBUG instead, there isn't much the user can do to fix it. More a rant than a request though. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 28 19:07:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 19:07:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215947.1525985 (Exim 4.92) (envelope-from ) id 1vlAsT-0005M4-R2; Wed, 28 Jan 2026 19:06:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215947.1525985; Wed, 28 Jan 2026 19:06: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 1vlAsT-0005Lx-OG; Wed, 28 Jan 2026 19:06:57 +0000 Received: by outflank-mailman (input) for mailman id 1215947; Wed, 28 Jan 2026 19: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 1vlAsS-0005Lr-Ii for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 19:06:56 +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 79ea2eaf-fc7c-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 20:06:41 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by PH0PR03MB6367.namprd03.prod.outlook.com (2603:10b6:510:a9::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Wed, 28 Jan 2026 19:06:37 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.006; Wed, 28 Jan 2026 19: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: 79ea2eaf-fc7c-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ahL5/JMhe/u0moxpjoJTraJqVSi+k2NK0ZLZea07gzpkoU8suzvyd7XD3k9GeZybloY3CM+TukMEuBlYUQO+LiZNocK6nVKiG5P1kush424GUQ6lAUF5+BLRRhebubfVCzdrxmV7xvfQiR5kLmURYAEs/EVmKCPEe+04VydUmG3LH9TzEDECdJxeXj1q7zUqrzqJzleyGiRaB30MpayonXKlIbP8xqrVl66H2ypxgURNpXjkMAsa4kiR1s1d4U+sm8+f5+tJg8pSTNcF7GhDhzdSNVp0UlYJ36M7gxmTMy5mX4UPp2HbRoOrWgEhXl3FLoejA/mBQpncw8LrBhFpUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uoeTR8czM06YUkBHxd75Edi46eWfXm2/ps5tFJAOOnE=; b=Z2dL/s2QzMQ+CjxEE4k0mmm4tTW9M3SJyBGhdx86PSW/KfdU7NL638FtV0RbwyXjPUMAA1GT4TI+jSnmNbKw2natCKetWflRHxflvJjqFlo1MgUYW88R/bJ4BTRXKZFL9aaK8iUGXRU/bO3wo+HsxDdVu/h9g2WKs2IHfpzD/ME6jBBbnbkA9dE4kzaTGi0EYRNmGrvY5pyu6JoMF6RvGQoTYuPnQlvp3BmGARI9lHUX2gHBoA2u0i4yL4TIS6UdpmXBNL6xoL7BvtrMhselsbQOZ+DWYmNmmxwlhVBrG7hAv4UnRw3eqGK+pvydF0HEnbMX65nS2iHb1GE+4KUZIw== 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=uoeTR8czM06YUkBHxd75Edi46eWfXm2/ps5tFJAOOnE=; b=b0xL7xgd2NXZB/abSUNs3FpEcjY7XXVPd41sozEimluA5wgU8q1LlTdWkqFhBBpORnYTNxET3lrTGSXJ+rW6jbJTEn6DbmjVpOtG6SF/KiNnHk1efqmwbosWMyOnW7z+etQPRQsveOJqSiKJvtCZJF+FvzGe/7uDtuPHfitzE0A= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 28 Jan 2026 20:06:34 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH v4 2/3] xen/mm: allow deferred scrub of physmap populate allocated pages Message-ID: References: <20260128120339.47373-1-roger.pau@citrix.com> <20260128120339.47373-3-roger.pau@citrix.com> <6d7b74b6-1bab-427d-aa14-321f4761d9a0@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6d7b74b6-1bab-427d-aa14-321f4761d9a0@suse.com> X-ClientProxiedBy: MR1P264CA0211.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:56::13) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|PH0PR03MB6367:EE_ X-MS-Office365-Filtering-Correlation-Id: f6dbe9ec-4537-4c93-8bfc-08de5ea05c94 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?ZkZlSVhZd0o2UXAxQlNRcVRJRHpuRkhoVjhKWVJweVZpWDgxdXFvVzNySTFH?= =?utf-8?B?Vm1HL3JlaDcxTWZNckx1L3FPc3VHZ2FScGJCeDUwWGl5UlNqbUNaUTRhaG5m?= =?utf-8?B?cFRlM0FwTGF1SXNHeklVK0lwWDloR2dKNktQTFBnNy90VWVzYXFzMmQ3REIv?= =?utf-8?B?TmJhMWJrQUxOYzMyZGpYRGF0aTlqSWZqYmVKRk8yakRZR0JnUE52TkZIVkZq?= =?utf-8?B?ZVRwRUdYM2tLQmY5c1psVW1uWGhScDRZR3pLUmhueVdsT2RXL0s0N3d5cEll?= =?utf-8?B?aWloTmhSQ3VTUXRWUGk0QkdZUUZGY0F3RnpQZUx1aHFZVVdzT0pnbEdILyt3?= =?utf-8?B?bWgyTDJ6VCtFOXZMM0Y1Rnp3ZDdHZTJNalArdk5BNXdUZXBOQlROSWxkamRy?= =?utf-8?B?c0Y1WDVETmw0UnZkZ0EzNjFYYXU3NU1aR3pBVVBEdU5rQkdTVTNVMzZUcVAz?= =?utf-8?B?NFo3bUUyNFlkbzhaNXVHVmNLNGNTWHlORmNsbmdaRmRiNGtqaXBmYjdQeStk?= =?utf-8?B?bmtPenl2ZklsdGJqWUswUVZ3eVVvSERDTDAxcXVidlhVbUp1N3BaVnZybTEx?= =?utf-8?B?MDhmVktkUEF2b3hZb2dUNEdqUkpEeDVFVm1NcVI2VmUxVGpqdXcxb1hRSFlF?= =?utf-8?B?QnowT3JsS2tpMjVXejJCOXU3WDF6YlArSU9HWk9LckFJcGNrRmlweUZnQjNT?= =?utf-8?B?ZHpSU0RrM2NuZ2R2K04zb3dRZXhkaUNQVmErVVZnWnpWZWJ3R29rVlJCQUc3?= =?utf-8?B?ZGpBelhDK0oxS0pJZGtteVlDa2dJRzJvRHI2WlRvMjBTeUdQYk5PelR2NkUv?= =?utf-8?B?dy96U2Y3NENwUWtSU2xpZGU1U3plcWtJdTV1SDd2emxSbkl1eEZwclgzeVZr?= =?utf-8?B?ZURrbzVhV2dKODhOcGFnZnBDRG1KTUlJK056dStpQWVvT2E4MFp1WWxtdlE4?= =?utf-8?B?djdGQVVWQTZFU083UkhBcEVmbm9yN0dCL2xwSm1UYWpRY2JMOW04M1l1NjEv?= =?utf-8?B?VmRwUnFkWXhqT1pkM1JPNHVJcmNSeWZzcVZmWEVvRm1uNllzRzV3Q1VkVlA1?= =?utf-8?B?WFByR04xRnpZNTBLTTNqUmE3Wm9XZXdocVIyS1g2Ym9wOVJMQ1lwY0FXNGxH?= =?utf-8?B?SURlZ0ZhZ2Uxc0pvVkh1d3J5TVhHMkxMSUVpcmdvczBxdDljMFJnSFo1TGUv?= =?utf-8?B?aDFqalhjUWFzUmNSTUtMZWtJdXE1VC9NcWNBM21VOWtCQjVBNDJRdEZVNmty?= =?utf-8?B?anRXWUlsSHJvY0plNVpEdFg0VW44VWcyemVoSWhveEVPUDJ1c01wT1dHTnQx?= =?utf-8?B?ZENxUWZpdjd3VFhWTFJpWUd3YWw4M2kvZTUvbUthN3E1TkNPcEYrM2NzVlRT?= =?utf-8?B?QlZxeHFhazVxK2xPRjA0dUx3MkRpTFFwM1hRZktrKzJTck01R3pPazIzNGRR?= =?utf-8?B?dHdxN1RQUUo0ck5IU3ZhbmpQU2pzTWxITERISlVJSEg5bDNIeFUxeUpCZjZ5?= =?utf-8?B?TFdTa3pPUnc1M2lQUGRDK2JPaHJOdHd0OW16anQwZm1CN0JiNStTSUgyMEhm?= =?utf-8?B?S21XL0Zkem91UzliWjlseEJEb1ZibytFU2tCeVpnV1JhaUhsSmtOc0d0SmZn?= =?utf-8?B?Z0czRlBSbUFWeHJ3Q3ZyRVF5NjFtQnR3U3EvaDFmckhvVE9CQ0RFYkxIZzFI?= =?utf-8?B?bHBDNFE2MksyMlh5NXRMZmhraEg4S0JvcWFiNXBXdHNYaVRUckRXS0FacU05?= =?utf-8?B?MDJyMEFUUkRkOTFUK2RqVlE3djlFNU82Z0Fnb3Y1Yk4vUWJGZlF1QlNTZDNE?= =?utf-8?B?NnBCRmQrVW85Nm05eW9CaE1NZ0pEQnk0OTFMY2pYV0lzQ0xUNVBUWlFsdkRB?= =?utf-8?B?dEpWZkdiNStWUzBQQ3lDTjRQRXo5S1EzOGp4MmFlOXp6ZGFRZUFicVVxMkJp?= =?utf-8?B?QTRZMGpBakVldkFQYVZrR0d4TytJckZwZVNLa1JIdDFoZ2NDWXNDQTl0SFdM?= =?utf-8?B?eUphUTFGS0RyLzBQMTJQcVlWUkxUdUl4SUErSXE0RlRWT1ZPUWs3OG12N0Yv?= =?utf-8?B?MEVyZUlxTWIvanJ4MjJ0NXNyVm9DWXhiOW5IQ1EyaTNJTGEra0RJTXgvcWF4?= =?utf-8?Q?B7Cc=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SFo3WEpoeEFNcUVzTnRmK2sweVZVTVJBQ0xYRDhQRlJDY1dndzFIN2l1WDhG?= =?utf-8?B?Qm9JaVNHSHY1KzBEOUdZMFNjQ1c4cGVnZHFZdmNXVXBqb0o2aW04TUU2ejJD?= =?utf-8?B?V083bllGUldUYzlKTndBUTlETy8rMTE3QVduODl2NTNYdU9ZQ1d6ZklEWDVQ?= =?utf-8?B?d0pJYkprSG5QbEx6QXBvSmdCNlg5Rys0Nk5FcE5QbnJtR1Z3TmFvS0RJVkF6?= =?utf-8?B?NGtVN1IzYjJJVFdFanBpN2tGS1Z1aCtLY29wZWZaM1pwUXhNYlpodlNkSlYx?= =?utf-8?B?VTNjVllIZmJWRG0xemc3QkJMOHZEeWZrcVdwZ3M4OUxmM2U2SWdTazNBMENj?= =?utf-8?B?RHFVZnN6RTd3T25tYytURmZPNE90b05pTHhUaTNRbkpUL082Q1dKak95STRz?= =?utf-8?B?L3Q1SkNRdXBiTDc2QWhRbFd1am5FNTZSa3o5QkNuVHY1V2ZmRUd4dHUyT0VS?= =?utf-8?B?Ly9xODVuZ0Q2MWttRTRIYnpWTHYxUWc0NEQzblBqZmJ4Uk1aY1V1UTZWcUJN?= =?utf-8?B?TUMyeWw0QWJLQThMNUNaMjV6SXNRand5ZUhubEZNVVBWRFVxc0dHTEt6NnNj?= =?utf-8?B?b2g0aWl0TCtzRTVWbXlEbldnMEhpOGVnSE43cFBoTHdObUtKd2pqUllNSWlN?= =?utf-8?B?RnIrT1JWMjNkanNHTVBielY4RkIrakhralRyaWZ1OUtYZWlOM2lLUElHVERP?= =?utf-8?B?YmVYeUhSWUVmL0wrWjlxOUFYWTBTKzJnZjNUYjZNVWpKcXVVWnU5dVEvOGlG?= =?utf-8?B?eXpFSm41VWZ1azhEeGpxd1FMcW5ZNzMyS2VPbGwxSXppajRrRzJGWDNFZyti?= =?utf-8?B?VWtwUXA5cnRiQTBsV0dRcVdzUHNhNjQwZGNhbm9ndklOYU0wRmE1MkVIREtN?= =?utf-8?B?UEtib3N0Tm0wRXlabzJ4WGtTTUhqbzBYUis5dURsR2NubTJIT3owSXg2VUMx?= =?utf-8?B?L1dpWmxPbHZOYVBZbDFtTHRBZkRqRndXbkZvWGI3YmQ1MlpWZWpqc2h2QUda?= =?utf-8?B?NDNFWnUrTTVwdzhkTzVUdDNWSCtwMVltcFY4YzZ1ajB4Y0xEdWVnd1hlTlE3?= =?utf-8?B?cGQ1cHQ0UmoxNUhKWFFtWUM5dERUeXlIL0JZQnVvQkFEYk1WWHVrRmoySHpM?= =?utf-8?B?MzhHNXRERXE3bDQwdVhDWHQ0OUdPU200TGJkMHcyOS9LRm8yelhuMGZMNGt0?= =?utf-8?B?dWl1TGVCcE1mQWlWeE8weEhaM2hiNy9zbThYOURUWkptUE5hMSsyRkZ5dTJS?= =?utf-8?B?aFFMRXpWVUEyU1RpK0ZuWUhOZ2RoL1VDR01SUmRTQWl4a05rT3JYWGlQbEhs?= =?utf-8?B?T0NxRVRMNHFDdk1DTGRWOXdvTzBtY1hjWFJLdHYzWjdVV0FQb1BzdDJidm0r?= =?utf-8?B?UzFZRzd2Rlpvd2E2VXRiSFNLNGppQ0I0RUYyN3k5SE1YQ1pHQit4a0x6Z3Ja?= =?utf-8?B?OXlvNnRROXIwL1RrVEI4ZWdaQUFPNVlRWnU0Y1hZL0puMTFZVmhRVDJ6WjJv?= =?utf-8?B?eVBuRHRWVnZidFhzSGtrWTFsSW1KbUhjSWlaZjZrcmFKeDhzMmtFWXNQV2xl?= =?utf-8?B?WmU0QUZ2RkFhNTNxK2NwYTZVQ0hKV2xRVnpFalRWLzNKN1BWWG0vZWRMdU5R?= =?utf-8?B?NlMrTE1GQm5RMlB6T3RybThqcWhLV29BYzl2bjFsdFN1djZpVFhZOTBoSC9W?= =?utf-8?B?TGg5eDllLyswOEtWRkR2VEhvOWF4YkNLNDVKclVrMEUzT0Z3aW9RVW5Dd2I5?= =?utf-8?B?SXVTT0NBSlV4aWl5MzdmZjQ1aDloNzEvOXlRM3ROYUdmdUxiekd1eVpITUI0?= =?utf-8?B?Yi93Mm5CTlA1NDRzeEZQaXhzWUF0ZzlVR0hUUmNTbm9xbUZ6S2hwQ1h5RDkw?= =?utf-8?B?UEpUaXZ4RnMvQW9meEgyNjhGK3E2akQ1NTVwZmhSR2dHWmhjZmJ6cHlDbzFT?= =?utf-8?B?c28raktwVlpDdUhsd0lqVWlIbWY0VGYzODhvZjUrMkg5aEVvSGNWem5ocUsz?= =?utf-8?B?UGV0SzJQUFBmbW0xdncrcXAyQ0o2ZG5YNVB1VmRtUXd6aTRnUFdnWWtha1Bv?= =?utf-8?B?Vmp0UUduRFN4UDJpNkVUdHRYcHJSNklla1lweTlxd0tsdFMvMEZ2Wld5NFlo?= =?utf-8?B?NWVEL2hFVHlvcFJzZjY4MEtnd3VUVlp6TkMxbTE2UVRUOStHeWxiWGhLMys5?= =?utf-8?B?bWp0Rko1cGgwdk9xTlRCQWlMeGxJUDBPTmlmUnliZzdReEN1MGwxY3N4K3lU?= =?utf-8?B?RUFML1hnNEJyL1I3WWNTSWluNmcyMG1tZUErU2ltUzJkSWRSVi9DOVpSWENq?= =?utf-8?B?UTBOTXFUMEE3K1FKbGp6QnVvajdwandESHZsTVQzWDQrUklIb3FpQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: f6dbe9ec-4537-4c93-8bfc-08de5ea05c94 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2026 19:06:37.5745 (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: iou4d4Q5pWp8wXTdtlmglaSrFsJVX3G9zl8+BsUK4nnfMDvwqzyLQgVrCr+q0wNOQq4p30sDlPjIXfkfx2cVrA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB6367 On Wed, Jan 28, 2026 at 03:46:04PM +0100, Jan Beulich wrote: > On 28.01.2026 13:03, Roger Pau Monne wrote: > > @@ -275,7 +339,18 @@ static void populate_physmap(struct memop_args *a) > > } > > else > > { > > - page = alloc_domheap_pages(d, a->extent_order, a->memflags); > > + unsigned int scrub_start = 0; > > + nodeid_t node = > > + (a->memflags & MEMF_exact_node) ? MEMF_get_node(a->memflags) > > + : NUMA_NO_NODE; > > + > > + page = get_stashed_allocation(d, a->extent_order, node, > > + &scrub_start); > > + > > + if ( !page ) > > + page = alloc_domheap_pages(d, a->extent_order, > > + a->memflags | (d->creation_finished ? 0 > > + : MEMF_no_scrub)); > > I fear there's a more basic issue here that so far we didn't pay attention to: > alloc_domheap_pages() is what invokes assign_page(), which in turn resets > ->count_info for each of the pages. This reset includes setting PGC_allocated, > which ... > > > @@ -286,6 +361,30 @@ static void populate_physmap(struct memop_args *a) > > goto out; > > } > > > > + if ( !d->creation_finished ) > > + { > > + unsigned int dirty_cnt = 0; > > + > > + /* Check if there's anything to scrub. */ > > + for ( j = scrub_start; j < (1U << a->extent_order); j++ ) > > + { > > + if ( !test_and_clear_bit(_PGC_need_scrub, > > + &page[j].count_info) ) > > + continue; > > ... means we will now scrub every page in the block, not just those which weren't > scrubbed yet, and we end up clearing PGC_allocated. All because of PGC_need_scrub > aliasing PGC_allocated. I wonder how this didn't end up screwing any testing you > surely will have done. Or maybe I'm completely off here? Thanks for spotting this! No, I didn't see any issues. I don't see any check for PGC_allocated in free_domheap_pages(), which could explain the lack of failures? I will have to allocate with MEMF_no_owner and then do the assign_pages() call from populate_physmap() after the scrubbing is done. Maybe that would work. Memory allocated using MEMF_no_owner still consumes the claim pool if a domain parameter is passed to alloc_heap_pages(). Roger. From xen-devel-bounces@lists.xenproject.org Wed Jan 28 21:50:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 21:50:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215984.1525994 (Exim 4.92) (envelope-from ) id 1vlDQU-00085w-QI; Wed, 28 Jan 2026 21:50:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215984.1525994; Wed, 28 Jan 2026 21: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 1vlDQU-00085p-Nd; Wed, 28 Jan 2026 21:50:14 +0000 Received: by outflank-mailman (input) for mailman id 1215984; Wed, 28 Jan 2026 21:50:14 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlDQU-00085j-F6 for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 21:50:14 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vlDQP-0084hH-2i; Wed, 28 Jan 2026 21:50:09 +0000 Received: from [2a02:8012:3a1:0:2517:2769:8ea2:3b28] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vlDQP-006SEr-0s; Wed, 28 Jan 2026 21:50: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:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=Bsk0ZDM69YZO3I61sWSAnNnyY/rgvcUD62fIs1uKveE=; b=rlIJYf4AJQQXrzRL4wEkvppdvZ 8yqp3h+5rR3OKgc0JFrlJc9U8MIJ1F3+lP4SQjFpGemPoKSwJU5/rVxhWanUbgQ++Y7qUkEFPUbL/ 3wYCPYcsZeiVDHGDE0qih/PWkDNey5Rx9xfNYRy05N3bR1vPPRokEwjxPP5SZ2uksf/M=; Message-ID: Date: Wed, 28 Jan 2026 21:50:07 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 00/12] xen/arm: ffa: FF-A v1.2 support Content-Language: en-GB To: Bertrand Marquis , Michal Orzel Cc: "jens.wiklander@linaro.org" , Volodymyr Babchuk , Stefano Stabellini , "xen-devel@lists.xenproject.org" References: <2FA52A4C-98F2-4066-8BE7-36F37093FCD6@arm.com> From: Julien Grall In-Reply-To: <2FA52A4C-98F2-4066-8BE7-36F37093FCD6@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Bertrand, On 08/01/2026 07:59, Bertrand Marquis wrote: > Gentle ping: This serie has been fully reviewed by Jens and would need a maintainer ack or review. As we discussed during the last Arm maintainer call, as you maintain TEE with Volodymyr, you technically only need a reviewed-by from someone from the community with suitable stature to review. I think in this case, you meet all the requirements with Jen's acked-by. So I will commit the series as-is. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Jan 28 21:57:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 21:57:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1215994.1526004 (Exim 4.92) (envelope-from ) id 1vlDXC-0000EQ-EV; Wed, 28 Jan 2026 21:57:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1215994.1526004; Wed, 28 Jan 2026 21: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 1vlDXC-0000EA-Bx; Wed, 28 Jan 2026 21:57:10 +0000 Received: by outflank-mailman (input) for mailman id 1215994; Wed, 28 Jan 2026 21:57:09 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlDXB-0000E4-RR for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 21:57:09 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vlDXA-0084oG-2J; Wed, 28 Jan 2026 21:57:08 +0000 Received: from [2a02:8012:3a1:0:2517:2769:8ea2:3b28] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vlDXA-006Sga-07; Wed, 28 Jan 2026 21:57: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=mI461cVXawa2nwdZipyyAU3NwrqZhkFsQBf35LG8M+I=; b=UeScH7pUfQ2t34Rwd5Df3iHL2s 7ovNmwELMir1InQVLZktZQ8YjobErF4ZRdGV/h0B4RQOh1lqSOIOehp+tdVMbpEUESfcWT3SnmfoU j6JtPfNCdMlmxH4YYw2Himh38AlPUQ4peRtOju334T+tzIEdFCgo19lEgF0eSz5Oj9UI=; Message-ID: <9740163b-5f0f-45b6-8d2f-df4b4756e272@xen.org> Date: Wed, 28 Jan 2026 21:57:06 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/arm: Kconfig: Fix XEN_START_ADDRESS input prompt Content-Language: en-GB To: Bertrand Marquis , Michal Orzel Cc: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Volodymyr Babchuk , Jan Beulich References: <20260127131923.123294-1-michal.orzel@amd.com> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, On 27/01/2026 14:00, Bertrand Marquis wrote: > > >> On 27 Jan 2026, at 14:19, Michal Orzel wrote: >> >> Remove the part about platform defined address which is not true. The >> help text is correct i.e. 0xFFFFFFFF is used as default value to indicate >> that user has not customized this address. >> >> Amends: d736b6eb451b ("xen/arm: mpu: Define Xen start address for MPU systems") >> Reported-by: Jan Beulich >> Signed-off-by: Michal Orzel > > Acked-by: Bertrand Marquis I have queued the patch for staging. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Jan 28 22:07:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 28 Jan 2026 22:07:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216004.1526014 (Exim 4.92) (envelope-from ) id 1vlDgu-0001uF-BD; Wed, 28 Jan 2026 22:07:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216004.1526014; Wed, 28 Jan 2026 22:07: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 1vlDgu-0001u8-8A; Wed, 28 Jan 2026 22:07:12 +0000 Received: by outflank-mailman (input) for mailman id 1216004; Wed, 28 Jan 2026 22:07: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 1vlDgt-0001tx-0E for xen-devel@lists.xenproject.org; Wed, 28 Jan 2026 22:07: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 afd85fd1-fc95-11f0-9ccf-f158ae23cfc8; Wed, 28 Jan 2026 23:07:08 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 5A0126001A; Wed, 28 Jan 2026 22:07:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E5D1FC4CEF1; Wed, 28 Jan 2026 22:07: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: afd85fd1-fc95-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769638027; bh=YGsOYJdydoUe71PjMAXiotEPugEwkr/DpoU7elN+plU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=hbcQhHWkaE5ktDti0LKw95eZw2U27IW/uTrOOKKw3l5PqCw1p0Z8pUmdEZznwaejp dTubQraYUQKqZe28xyBKGTZY3YUIlTnY3wAsTXa0/PsXV6HokwtPmE4KR9Tr1kQ+9W gNe2wOKu8wtB6uvq0Ua9+L1OqNd2EPaLDFsxddl2GR3Au3NPuwO135hQBOWNJWkVbj intaCQ1g8AU+F5sNSmv6VFFJLR/Hq47KWGYjPQz3Gk1Pdd7AfOpqHpQDB2N+C+omHh C9UU6DO4xt1BWqLaY8oqoB0WYuS8fsMZqr57qQe5PMIHWsnEc4sBVtxltof3Cr0stX jYaCaDMhIOFQg== Date: Wed, 28 Jan 2026 14:07:04 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Alejandro Vallejo cc: Jan Beulich , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [RFC PATCH] CODING_STYLE: Establish a policy with regards to copyright notices In-Reply-To: Message-ID: References: <20260127182403.141459-1-alejandro.garciavallejo@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, 28 Jan 2026, Alejandro Vallejo wrote: > On Wed Jan 28, 2026 at 11:45 AM CET, Jan Beulich wrote: > > On 28.01.2026 10:09, Alejandro Vallejo wrote: > >> The refinement also applies to the second bullet point, so I can add it as a > >> separate paragraph stating existing notices are to never be modified and only > >> removed with the express consent of the current holder(s). > > > > That's interesting, as it may be getting increasingly difficult in practice. > > Often you can't get hold of the holder(s), to the degree that - as we're all > > growing older - at some point they may not be there at all anymore. Yet if > > not having such notices is going to be a goal of the project, retaining some > > indefinitely can't be the intention either. > > Sorry, I missed this part. Many things are unavoidable non-intentions, I'm > afraid. A file might have a notice indefinitely, but that doesn't mean the project > _must_ keep that file indefinitely. > > I'd definitely prefer to drop them all. Alas, I don't feel confident enough you > (nor anyone) can legally commit such changes without the holders' approval. > Unless we were to base the rationale on "the notice is already in git history" > or some such. At that point it becomes mandatory to ship the full git tree as > part of a release, which is incompatible with tarball releases. This might > affect downstreams more than upstream, but it's a consideration nonetheless. > > It is true that having some already in, with new ones severely restricted > creates asymmetry with prior contributions, but I argue this asymmetry already > exists with banners present for some original contributors, when folks (e.g: > you) have been heavily modifying those files for well over 10y and not added > their name. And if everyone were to add their name we'd have to scroll hundreds > of lines on each file before seeing the first #include. >From an engineering perspective I understand the intention of this patch and I myself suggested something similar a while back. However, I later found out that legal systems differ across countries, and copyright law does not function in exactly the same way in the US, UK and the EU. For example, it is not a good idea to remove copyright notices or discourage their use because they carry legal significance in certain jurisdictions, particularly in Europe. Given this, I think we should leave things as they are. Let me clarify what I mean by "copyright notice". For instance, the following: * Copyright (C) 2000 - 2007, R. Byron Moore * All rights reserved. On the other hand, the boilerplate such as: * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT etc. etc. can be removed and replaced with the SPDX tag. There is no controversy there. The SPDX tag refers to the licenses under LICENSES which contain exactly the same text. From xen-devel-bounces@lists.xenproject.org Thu Jan 29 02:43:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 02:43:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216038.1526035 (Exim 4.92) (envelope-from ) id 1vlHzp-0000NN-NR; Thu, 29 Jan 2026 02:43:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216038.1526035; Thu, 29 Jan 2026 02:43:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlHzp-0000NG-Kc; Thu, 29 Jan 2026 02:43:01 +0000 Received: by outflank-mailman (input) for mailman id 1216038; Thu, 29 Jan 2026 02:43: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 1vlHzo-0000MZ-JG for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 02:43:00 +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 37e59ce8-fcbc-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 03:42:58 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 44C9740EBB; Thu, 29 Jan 2026 02:42:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C7EDC4CEF1; Thu, 29 Jan 2026 02:42: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: 37e59ce8-fcbc-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769654576; bh=28fwAAp2CHTkhFezCiscILlUGMMq7vQ+iKzESuFOE/s=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=noq9VVgmwjstN4rHhZv8DRQUIxCqxvSEwjEOkqklMG9ihfDuz72kEa9N8v1O3bV9a ASDrx6aSmaOz3IiPLAmSBhwocWdAKUiPqK+2NWAVS577orTBeM95M2wSvr8rvMicr2 LE4Sj49NgZvQpM/BOr5k3ZZvMI0Iy8gKPywIJ40tXqAL6prF9iOM5sO1K+CqEBTBdi QrWnPte/uZS9wEnFUO8O+RC7vqa5bgyB8WU75Jp1mTY9jYBM8he65ItTdv6MVxlbmO 5xuMqmcji8kGsXCtUj3x9Us+ctMfuJlFtckdKLkhEqkRZZL7KFW+IZbviY9m/twp7E EQEwURKAJ3fOw== Date: Wed, 28 Jan 2026 18:42:53 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Jan Beulich cc: Stefano Stabellini , grygorii_strashko@epam.com, anthony.perard@vates.tech, michal.orzel@amd.com, julien@xen.org, roger.pau@citrix.com, jason.andryuk@amd.com, victorm.lira@amd.com, andrew.cooper3@citrix.com, sstabellini@kernel.org, xen-devel@lists.xenproject.org, Daniel Smith Subject: Re: [PATCH v7 1/2] xen/console: handle multiple domains using console_io hypercalls In-Reply-To: Message-ID: References: <20260123010640.1194863-1-stefano.stabellini@amd.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Wed, 28 Jan 2026, Jan Beulich wrote: > On 23.01.2026 02:06, Stefano Stabellini wrote: > > @@ -555,8 +561,11 @@ static void console_switch_input(void) > > > > if ( next_rx++ >= max_console_rx ) > > { > > - console_rx = 0; > > printk("*** Serial input to Xen"); > > + nrspin_lock_irq(&console_lock); > > + console_rx = 0; > > + serial_rx_cons = serial_rx_prod; > > + nrspin_unlock_irq(&console_lock); > > break; > > } > > > > @@ -575,8 +584,12 @@ static void console_switch_input(void) > > > > rcu_unlock_domain(d); > > > > - console_rx = next_rx; > > printk("*** Serial input to DOM%u", domid); > > + nrspin_lock_irq(&console_lock); > > + console_rx = next_rx; > > + /* Don't let the next dom read the previous dom's unread data. */ > > + serial_rx_cons = serial_rx_prod; > > + nrspin_unlock_irq(&console_lock); > > break; > > } > > As in both cases you're also moving console_rx updates into the locked > region, what about readers of the variable, first and foremost > console_get_domain()? Else why the movement? You're right. I've added locking in console_get_domain() to read console_rx under console_lock into a local variable, ensuring consistency with the now-locked writes. > Also I think that the printk()s would better be last, indicating the > completion of the switching. OK > > @@ -605,8 +618,10 @@ static void __serial_rx(char c) > > * Deliver input to the hardware domain buffer, unless it is > > * already full. > > */ > > This comment goes stale with the buffer being used for whichever is the > focus domain in do_console_io(). > > > + nrspin_lock_irq(&console_lock); > > if ( (serial_rx_prod - serial_rx_cons) != SERIAL_RX_SIZE ) > > serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c; > > + nrspin_unlock_irq(&console_lock); > > I don't think you can unconditionally enable interrupts here, as this may > be running in the context of an IRQ handler. Good catch! I've changed __serial_rx() to use nrspin_lock_irqsave()/ nrspin_unlock_irqrestore() instead of nrspin_lock_irq()/nrspin_unlock_irq(). > > @@ -742,17 +758,36 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, > > if ( copy_from_guest(kbuf, buffer, kcount) ) > > return -EFAULT; > > > > - if ( is_hardware_domain(cd) ) > > + /* > > + * Take both cons->lock and console_lock: > > + * - cons->lock protects cons->buf and cons->idx > > + * - console_lock protects console_send and is_focus_domain > > + * checks > > + * > > + * The order must be respected. guest_printk takes the > > + * console_lock so it is important that cons->lock is taken > > + * first. > > + */ > > + spin_lock(&cons->lock); > > + nrspin_lock_irq(&console_lock); > > + if ( is_focus_domain(cd) ) > > Why would any of the domains possibly being permitted to be "focus" suddenly > gain direct access here? Full access in do_console_io() is still prevented by > the XSM check there, afaict. Cc-ing Daniel, as it's not quite clear to me > whether to introduce another XSM check here, whether to check ->is_console > directly, or yet something else. The XSM check still happens first in do_console_io() via xsm_console_io(XSM_OTHER, current->domain, cmd), which validates that the domain has permission to use console_io hypercalls. The focus check is an additional restriction that only allows reading when the domain has focus: it doesn't grant new permissions. Dom0less domains with input_allowed = true are already permitted by XSM policy to use console_io; the focus mechanism just ensures only one domain can read input at a time (similar to vpl011 behavior). Additionally, this is also allowed for dom0less domains which are quite special and manually configured at boot by the user. There are no arbitrary unknown dom0less domains that can be started later. > > { > > + if ( cons->idx ) > > + { > > + console_send(cons->buf, cons->idx, flags); > > + cons->idx = 0; > > + } > > + spin_unlock(&cons->lock); > > + > > /* Use direct console output as it could be interactive */ > > - nrspin_lock_irq(&console_lock); > > console_send(kbuf, kcount, flags); > > nrspin_unlock_irq(&console_lock); > > } > > else > > { > > char *kin = kbuf, *kout = kbuf, c; > > - struct domain_console *cons = cd->console; > > + > > + nrspin_unlock_irq(&console_lock); > > > > /* Strip non-printable characters */ > > do > > @@ -765,7 +800,6 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, > > } while ( --kcount > 0 ); > > > > *kout = '\0'; > > - spin_lock(&cons->lock); > > kcount = kin - kbuf; > > if ( c != '\n' && > > (cons->idx + (kout - kbuf) < (ARRAY_SIZE(cons->buf) - 1)) ) > > @@ -815,6 +849,13 @@ long do_console_io( > > if ( count > INT_MAX ) > > break; > > > > + nrspin_lock_irq(&console_lock); > > + if ( !is_focus_domain(current->domain) ) > > + { > > + nrspin_unlock_irq(&console_lock); > > + return 0; > > + } > > To avoid the extra unlock-and-return, how about simply setting "count" to 0, > leveraging ... Good idea. > > rc = 0; > > while ( (serial_rx_cons != serial_rx_prod) && (rc < count) ) > > ... the rhs check here? > > > @@ -824,14 +865,28 @@ long do_console_io( > > len = SERIAL_RX_SIZE - idx; > > if ( (rc + len) > count ) > > len = count - rc; > > + nrspin_unlock_irq(&console_lock); > > This can be moved up a few lines, as none of the local variable manipulations > needs guarding. OK > > if ( copy_to_guest_offset(buffer, rc, &serial_rx_ring[idx], len) ) > > - { > > - rc = -EFAULT; > > - break; > > - } > > + return -EFAULT; > > rc += len; > > + > > + /* > > + * First get console_lock again, then check is_focus_domain. > > + * It is possible that we switched focus domain during > > + * copy_to_guest_offset. In that case, serial_rx_cons and > > Please can you append () to the function name, to identify it as a function, > as opposed to ... > > > + * serial_rx_prod have been reset so it would be wrong to > > + * update serial_rx_cons here. Get out of the loop instead. > > ... the two variables referenced here? Done From xen-devel-bounces@lists.xenproject.org Thu Jan 29 02:43:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 02:43:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216037.1526025 (Exim 4.92) (envelope-from ) id 1vlHzj-00008L-FA; Thu, 29 Jan 2026 02:42:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216037.1526025; Thu, 29 Jan 2026 02:42:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlHzj-00007t-9k; Thu, 29 Jan 2026 02:42:55 +0000 Received: by outflank-mailman (input) for mailman id 1216037; Thu, 29 Jan 2026 02:42:54 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlHzi-00007n-D9 for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 02:42:54 +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 33f2eaeb-fcbc-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 03:42:51 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 9430D60054; Thu, 29 Jan 2026 02:42:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D0D17C4CEF1; Thu, 29 Jan 2026 02:42: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: 33f2eaeb-fcbc-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769654569; bh=WAi5BgVh2BpUxZlRop1qIplkxyvXAXUqVblVJqIdQG4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=fGV42+wECr9y3+gljw7cdJUVmhk4RV8U+AvFZ6XsX4PRuKme8UkpwAi2j427gzwzv 8T617g3jac9qaqYODhvWWV+uJussAdlN/1oT2rl146ff29hkBKaySVxbG8ihGqfGmd HqvVqVmJCByq2t3K4m6Aqqzp5oVmHdZwHxMbK004cw65pNJq7rtZauHp1zSm+BVVGf MOLXzz97Pny7XWb4EF4x8GyL7YMdUbGGLSkBiVIeWWD7y4+YOSuM93w3PFTLasYmo4 /DSNS/ysi7qpEHTLj/1O4bHu+Qi68Aey5ODiD+4E3q0S/qIA2qL8uG+OG/dTg/cKYs +clwIVmQPSgQA== Date: Wed, 28 Jan 2026 18:42:45 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Jan Beulich cc: Stefano Stabellini , grygorii_strashko@epam.com, anthony.perard@vates.tech, michal.orzel@amd.com, julien@xen.org, roger.pau@citrix.com, jason.andryuk@amd.com, victorm.lira@amd.com, andrew.cooper3@citrix.com, sstabellini@kernel.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v7 2/2] xen: enable dom0less guests to use console_io hypercalls In-Reply-To: <91c71a0c-4345-4fae-912b-ae7c9d2160e7@suse.com> Message-ID: References: <20260123010640.1194863-2-stefano.stabellini@amd.com> <91c71a0c-4345-4fae-912b-ae7c9d2160e7@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, 28 Jan 2026, Jan Beulich wrote: > On 23.01.2026 02:06, Stefano Stabellini wrote: > > --- a/xen/common/device-tree/dom0less-build.c > > +++ b/xen/common/device-tree/dom0less-build.c > > @@ -829,6 +829,8 @@ static int __init construct_domU(struct kernel_info *kinfo, > > > > rangeset_destroy(kinfo->xen_reg_assigned); > > > > + d->console->input_allowed = true; > > Why for all of the domains? Shouldn't this be a per-domain setting? For all dom0less domains. No, I don't think it should be a per-domain setting. If you are running dom0less you only have two options: this one, or vuart and both of them work the same way and require input_allowed = true. > > --- a/xen/drivers/char/console.c > > +++ b/xen/drivers/char/console.c > > @@ -612,10 +612,18 @@ static void __serial_rx(char c) > > if ( !d ) > > return; > > > > - if ( is_hardware_domain(d) ) > > This check is fully lost; shouldn't it be replaced by ... > > > +#ifdef CONFIG_SBSA_VUART_CONSOLE > > + /* Prioritize vpl011 if enabled for this domain */ > > + if ( d->arch.vpl011.base_addr ) > > + { > > + /* Deliver input to the emulated UART. */ > > + rc = vpl011_rx_char_xen(d, c); > > + } > > + else > > +#endif > > ... > > if ( d->input_allowed ) > > the latest here (not sure about the vpl011 intentions in this regard)? No because vuart has already input_allowed > > { > > /* > > - * Deliver input to the hardware domain buffer, unless it is > > + * Deliver input to the focus domain buffer, unless it is > > * already full. > > */ > > As said there, imo this change belongs in the earlier patch. I can move them there From xen-devel-bounces@lists.xenproject.org Thu Jan 29 02:46:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 02:46:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216059.1526045 (Exim 4.92) (envelope-from ) id 1vlI38-0001FF-63; Thu, 29 Jan 2026 02:46:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216059.1526045; Thu, 29 Jan 2026 02:46:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlI38-0001F8-3A; Thu, 29 Jan 2026 02:46:26 +0000 Received: by outflank-mailman (input) for mailman id 1216059; Thu, 29 Jan 2026 02:46:24 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlI36-0001F2-9q for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 02:46: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 b1b36600-fcbc-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 03:46:22 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 259B26001A; Thu, 29 Jan 2026 02:46:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6734AC4CEF1; Thu, 29 Jan 2026 02:46: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: b1b36600-fcbc-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769654780; bh=Dc5kNbxwbRhIoRgfSkMzcV9NzijyyZX2PX+kv9hY7xg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=sLWpr83+Mp4JltWazzYFSU6tXRwPhAZO6YVN2Dz0Sm0llbTjlpgNrwJCArV691rb/ Ge0xV5ZGf6EQIHKCOqDGO9O2tTV+8H90X+xaYL5NMXozW7vYgVtQYQW+W7mmMdKgNF CsK41PUryLKAkk/1fk+8ADE4ZPZ8vaWff81VGa9Dv4U+YLGiUiYzSFwvusKRoZb6Go 9Dwz908IaQKQ9hcwsm59Ap25D2P9Vo9VHUVmGhoKwGXrz0712NJOrm4blWLXjw4QtU mdmfYOvl14diln9GIXxcfMey7DiMmNaCWiuDzBjEcrn6QlUGvuhPv9d3RwUH72HhUq 5vqJRP50HzIaQ== Date: Wed, 28 Jan 2026 18:46:17 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Stefano Stabellini cc: Jan Beulich , Stefano Stabellini , grygorii_strashko@epam.com, anthony.perard@vates.tech, michal.orzel@amd.com, julien@xen.org, roger.pau@citrix.com, jason.andryuk@amd.com, victorm.lira@amd.com, andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH v7 2/2] xen: enable dom0less guests to use console_io hypercalls In-Reply-To: Message-ID: References: <20260123010640.1194863-2-stefano.stabellini@amd.com> <91c71a0c-4345-4fae-912b-ae7c9d2160e7@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, 28 Jan 2026, Stefano Stabellini wrote: > On Wed, 28 Jan 2026, Jan Beulich wrote: > > On 23.01.2026 02:06, Stefano Stabellini wrote: > > > --- a/xen/common/device-tree/dom0less-build.c > > > +++ b/xen/common/device-tree/dom0less-build.c > > > @@ -829,6 +829,8 @@ static int __init construct_domU(struct kernel_info *kinfo, > > > > > > rangeset_destroy(kinfo->xen_reg_assigned); > > > > > > + d->console->input_allowed = true; > > > > Why for all of the domains? Shouldn't this be a per-domain setting? > > For all dom0less domains. No, I don't think it should be a per-domain > setting. If you are running dom0less you only have two options: this > one, or vuart and both of them work the same way and require > input_allowed = true. > > > > > --- a/xen/drivers/char/console.c > > > +++ b/xen/drivers/char/console.c > > > @@ -612,10 +612,18 @@ static void __serial_rx(char c) > > > if ( !d ) > > > return; > > > > > > - if ( is_hardware_domain(d) ) > > > > This check is fully lost; shouldn't it be replaced by ... > > > > > +#ifdef CONFIG_SBSA_VUART_CONSOLE > > > + /* Prioritize vpl011 if enabled for this domain */ > > > + if ( d->arch.vpl011.base_addr ) > > > + { > > > + /* Deliver input to the emulated UART. */ > > > + rc = vpl011_rx_char_xen(d, c); > > > + } > > > + else > > > +#endif > > > > ... > > > > if ( d->input_allowed ) > > > > the latest here (not sure about the vpl011 intentions in this regard)? > > No because vuart has already input_allowed Sorry, let me rephrase this. You are right we need a d->input_allowed check. The check is already done as part of d = console_get_domain(); if ( !d ) return; From xen-devel-bounces@lists.xenproject.org Thu Jan 29 07:02:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 07:02:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216084.1526055 (Exim 4.92) (envelope-from ) id 1vlM38-0006z6-25; Thu, 29 Jan 2026 07:02:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216084.1526055; Thu, 29 Jan 2026 07: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 1vlM37-0006yz-Ut; Thu, 29 Jan 2026 07:02:41 +0000 Received: by outflank-mailman (input) for mailman id 1216084; Thu, 29 Jan 2026 07:02:40 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlM36-0006yt-5u for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 07:02:40 +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 7ea5c737-fce0-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 08:02:37 +0100 (CET) Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-b884a84e655so98550166b.0 for ; Wed, 28 Jan 2026 23:02:37 -0800 (PST) Received: from ?IPV6:2a00:12d0:af5b:2f01:4042:c03:ce4d:a5a1? (2a00-12d0-af5b-2f01-4042-c03-ce4d-a5a1.ip.tng.de. [2a00:12d0:af5b:2f01:4042:c03:ce4d:a5a1]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8dbf2f1f55sm221633566b.70.2026.01.28.23.02.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 23:02:36 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7ea5c737-fce0-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769670157; x=1770274957; darn=lists.xenproject.org; h=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=2pYMpIaow5fZzBY2eDrtafEkUG081NDESZLp50lH9Vs=; b=J5zRwc2FKzwGZxVmIRv1hzC2WkwJVZe5P+5uwbPnJvMHIQdgz0mpUtFJeYCX0X9rej q8EJehEt/Y5oQcXC4i26STYG6BzXleWaGPBJPphCymN24SB2UgSDsjHMAf0E7qqqwg+Z zBQMvUdIVNvW69GXgd/u8nYu2MhNOTm7qqruKlwJ93uxkdholMG6TjH1oF7OFoGQ5MNK s72Dh90nWbBWbZgHTvS2ysHLs0bSoiHSINR8uA5OBUxY1nRHVMzllCEy0KgV/1IjpV5a 3pcASpvwSna/fXSLEuDEO2uLShz6SpYLPQ6gUWoIYd+C1MZzD8ZAAHpisVGjVCaQ44G4 RR5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769670157; x=1770274957; h=in-reply-to:autocrypt:content-language:references:cc:to:from :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2pYMpIaow5fZzBY2eDrtafEkUG081NDESZLp50lH9Vs=; b=na0iDDExHjEKW/MAl9+cmyf/p8qkMuahvtj7NvsOYp0Rl6IoCICvPp13b5GMkRR2A9 SkYkxVzAg9EWhCpG53VNVj4tvm+ifjrumCbGE2EhG0LA4DmVbkVF/2rF8wv7O4GkwRy5 eWcB74opq9OTP9wZduELCfjgjIoUo/R8KN3Lq8+qwYPr1oMLZGTG/8iBeEh3RHEt1qth kRpPAIw1ZI2km4UW5QRwYG2TxmlJ09kBN5Xlr/Kac28vaef+3Evoe/VAzfRMj41hx1Zy WjrGA6N85hM/gBVvKVgQ86OeZoftQ4HmZhDYtKzDVzIS3nbD6RgaBweVs5vpH38nKzaJ 4MQw== X-Forwarded-Encrypted: i=1; AJvYcCX2+CQ3JQs6LMjn3e57zhOxU1CBLQ5Z0SqUbK2DqZuYM4XBp3rFCcW/bNlzKi176IkI4qQb8M656EI=@lists.xenproject.org X-Gm-Message-State: AOJu0YwHY5YSmm95692MPEslyXInUhcEL9lByaxwl5pjSe5owLffdwOU /GU1PZ6nv3SiJQ9M3pins7Gi84QxFFp0asr5MtrE300aieRv76NOM1pO0YbF8KOVRJU= X-Gm-Gg: AZuq6aKNUfdJzQhIxPtOB6fWx7Q/x9lP23XSQZQ0a6VoS2nkglV50bVJjRsyDGxKlX+ nXx/rpEkJv+M/C9NmI8b83I9Kf0puGYi2A6fBPfEjVymDC5JZBvLizDLaC4fR4I6qCTHau3TczL jllMjmu+j9DO3igQKKtKCRxXgoeREvlsDgo7LigvbDOxqVXPsTvZPIfl47FJUiZu1s81lmofGd5 vEssUluzU/5awF8JzU4e7Yr3SVbsCJzCYfhDMaoTaljPOvkQ3yFopV5fKRHe5fOFWcO73ypB5BJ ESiPwt5ZqVtDqshujvPuBBc1jgZfAkjh5DZO91J9ZLctiXX2hL+pi8NG3GfuoFy7TOq+EVRiUyB 02T6Unh95VdwJzS0UfIBwYUhrLDcckS0FJcQVc7IPLzwg3zl+pMbBpFYDM6vkP1DOmVrzgdHc3e L2qdLUjOUrPJZ9rsVGihID/mxBHcy2i2QJsu1g1ooeSzwDnhA1VdRTzvop+GWdAaf6wemmEOKxq thwEUjXQKujOFmS3CrNY1U16D64NVTkhJs07g== X-Received: by 2002:a17:907:6d19:b0:b87:34e3:a79e with SMTP id a640c23a62f3a-b8dab2bfaeamr552771466b.12.1769670156887; Wed, 28 Jan 2026 23:02:36 -0800 (PST) Message-ID: Date: Thu, 29 Jan 2026 08:02:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/xenbus: better handle backend crash From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , linux-kernel@vger.kernel.org Cc: Stefano Stabellini , Oleksandr Tyshchenko , Peng Jiang , Qiu-ji Chen , Jason Andryuk , "moderated list:XEN HYPERVISOR INTERFACE" References: <20251102032105.772670-1-marmarek@invisiblethingslab.com> <261c3ced-7f40-4c2f-93da-0e020f9bcf3a@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: <261c3ced-7f40-4c2f-93da-0e020f9bcf3a@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------kEB9N9B3dVD3DUQAKW7WZdOy" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------kEB9N9B3dVD3DUQAKW7WZdOy Content-Type: multipart/mixed; boundary="------------PhLWTsoxQzJZG6MEoRpp76NV"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , linux-kernel@vger.kernel.org Cc: Stefano Stabellini , Oleksandr Tyshchenko , Peng Jiang , Qiu-ji Chen , Jason Andryuk , "moderated list:XEN HYPERVISOR INTERFACE" Message-ID: Subject: Re: [PATCH] xen/xenbus: better handle backend crash References: <20251102032105.772670-1-marmarek@invisiblethingslab.com> <261c3ced-7f40-4c2f-93da-0e020f9bcf3a@suse.com> In-Reply-To: <261c3ced-7f40-4c2f-93da-0e020f9bcf3a@suse.com> --------------PhLWTsoxQzJZG6MEoRpp76NV Content-Type: multipart/mixed; boundary="------------EGatcTEGiFLvn2bUqq64Vaus" --------------EGatcTEGiFLvn2bUqq64Vaus Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjYuMDEuMjYgMDg6MDgsIErDvHJnZW4gR3Jvw58gd3JvdGU6DQo+IE9uIDE3LjExLjI1 IDEyOjA2LCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0KPj4gT24gMDIuMTEuMjUgMDQ6MjAsIE1h cmVrIE1hcmN6eWtvd3NraS1Hw7NyZWNraSB3cm90ZToNCj4+PiBXaGVuIHRoZSBiYWNrZW5k IGRvbWFpbiBjcmFzaGVzLCBjb29yZGluYXRlZCBkZXZpY2UgY2xlYW51cCBpcyBub3QNCj4+ PiBwb3NzaWJsZSAoYXMgaXQgaW52b2x2ZXMgd2FpdGluZyBmb3IgdGhlIGJhY2tlbmQgc3Rh dGUgY2hhbmdlKS4gSW4gdGhhdA0KPj4+IGNhc2UsIHRvb2xzdGFjayBmb3JjZWZ1bGx5IHJl bW92ZXMgZnJvbnRlbmQgeGVuc3RvcmUgZW50cmllcy4NCj4+PiB4ZW5idXNfZGV2X2NoYW5n ZWQoKSBoYW5kbGVzIHRoaXMgY2FzZSwgYW5kIHRyaWdnZXJzIGRldmljZSBjbGVhbnVwLg0K Pj4+IEl0J3MgcG9zc2libGUgdGhhdCB0b29sc3RhY2sgbWFuYWdlcyB0byBjb25uZWN0IG5l dyBkZXZpY2UgaW4gdGhhdA0KPj4+IHBsYWNlLCBiZWZvcmUgeGVuYnVzX2Rldl9jaGFuZ2Vk KCkgbm90aWNlcyB0aGUgb2xkIG9uZSBpcyBtaXNzaW5nLiBJZg0KPj4+IHRoYXQgaGFwcGVu cywgbmV3IG9uZSB3b24ndCBiZSBwcm9iZWQgYW5kIHdpbGwgZm9yZXZlciByZW1haW4gaW4N Cj4+PiBYZW5idXNTdGF0ZUluaXRpYWxpc2luZy4NCj4+Pg0KPj4+IEZpeCB0aGlzIGJ5IGNo ZWNraW5nIGJhY2tlbmQtaWQgYW5kIGlmIGl0IGNoYW5nZXMsIGNvbnNpZGVyIGl0DQo+Pj4g dW5wbHVnK3BsdWcgb3BlcmF0aW9uLiBJdCdzIGltcG9ydGFudCB0aGF0IGNsZWFudXAgb24g c3VjaCB1bnBsdWcNCj4+PiBkb2Vzbid0IG1vZGlmeSB4ZW5zdG9yZSBlbnRyaWVzIChlc3Bl Y2lhbGx5IHRoZSAic3RhdGUiIGtleSkgYXMgaXQNCj4+PiBiZWxvbmcgdG8gdGhlIG5ldyBk ZXZpY2UgdG8gYmUgcHJvYmVkIC0gY2hhbmdpbmcgaXQgd291bGQgZGVyYWlsDQo+Pj4gZXN0 YWJsaXNoaW5nIGNvbm5lY3Rpb24gdG8gdGhlIG5ldyBiYWNrZW5kIChtb3N0IGxpa2VseSwg Y2xvc2luZyB0aGUNCj4+PiBkZXZpY2UgYmVmb3JlIGl0IHdhcyBldmVuIGNvbm5lY3RlZCku IEhhbmRsZSB0aGlzIGNhc2UgYnkgc2V0dGluZyBuZXcNCj4+PiB4ZW5idXNfZGV2aWNlLT52 YW5pc2hlZCBmbGFnIHRvIHRydWUsIGFuZCBjaGVjayBpdCBiZWZvcmUgY2hhbmdpbmcgc3Rh dGUNCj4+PiBlbnRyeS4NCj4+Pg0KPj4+IEFuZCBldmVuIGlmIHhlbmJ1c19kZXZfY2hhbmdl ZCgpIGNvcnJlY3RseSBkZXRlY3RzIHRoZSBkZXZpY2Ugd2FzDQo+Pj4gZm9yY2VmdWxseSBy ZW1vdmVkLCB0aGUgY2xlYW51cCBoYW5kbGluZyBpcyBzdGlsbCByYWN5LiBTaW5jZSB0aGlz IHdob2xlDQo+Pj4gaGFuZGxpbmcgZG9lc24ndCBoYXBwZW5kIGluIGEgc2luZ2xlIHhlbnN0 b3JlIHRyYW5zYWN0aW9uLCBpdCdzIHBvc3NpYmxlDQo+Pj4gdGhhdCB0b29sc3RhY2sgbWln aHQgcHV0IGEgbmV3IGRldmljZSB0aGVyZSBhbHJlYWR5LiBBdm9pZCByZS1jcmVhdGluZw0K Pj4+IHRoZSBzdGF0ZSBrZXkgKHdoaWNoIGluIHRoZSBjYXNlIG9mIGxvb3NpbmcgdGhlIHJh Y2Ugd291bGQgYWN0dWFsbHkNCj4+PiBjbG9zZSBuZXdseSBhdHRhY2hlZCBkZXZpY2UpLg0K Pj4+DQo+Pj4gVGhlIHByb2JsZW0gZG9lcyBub3QgYXBwbHkgdG8gZnJvbnRlbmQgZG9tYWlu IGNyYXNoLCBhcyB0aGlzIGNhc2UNCj4+PiBpbnZvbHZlcyBjb29yZGluYXRlZCBjbGVhbnVw Lg0KPj4+DQo+Pj4gUHJvYmxlbSBvcmlnaW5hbGx5IHJlcG9ydGVkIGF0DQo+Pj4gaHR0cHM6 Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsL2FPWnZpdnlaOVloVldETE5AbWFpbC1pdGwv VC8jdCwNCj4+PiBpbmNsdWRpbmcgcmVwcm9kdWN0aW9uIHN0ZXBzLg0KPj4+DQo+Pj4gU2ln bmVkLW9mZi1ieTogTWFyZWsgTWFyY3p5a293c2tpLUfDs3JlY2tpIDxtYXJtYXJla0BpbnZp c2libGV0aGluZ3NsYWIuY29tPg0KPj4NCj4+IFNvcnJ5IEkgZGlkbid0IGdldCBlYXJsaWVy IHRvIHRoaXMuDQo+Pg0KPj4gTXkgbWFpbiBwcm9ibGVtIHdpdGggdGhpcyBwYXRjaCBpcyB0 aGF0IGl0IGlzIGJhc2ljYWxseSBqdXN0IHBhcGVyaW5nIG92ZXINCj4+IGEgbW9yZSBnZW5l cmFsIHByb2JsZW0uDQo+Pg0KPj4gWW91IGFyZSBqdXN0IG1ha2luZyB0aGUgcHJvYmxlbSBt dWNoIG1vcmUgaW1wcm9iYWJsZSwgYnV0IG5vdCBpbXBvc3NpYmxlIHRvDQo+PiBvY2N1ciBh Z2Fpbi4gSW4gY2FzZSB0aGUgbmV3IGRyaXZlciBkb21haW4gaGFzIHRoZSBzYW1lIGRvbWlk IGFzIHRoZSBvbGQgb25lDQo+PiB5b3UgY2FuIHN0aWxsIGhhdmUgdGhlIHNhbWUgcmFjZS4N Cj4+DQo+PiBUaGUgY2xlYW4gd2F5IHRvIGhhbmRsZSB0aGF0IHdvdWxkIGJlIHRvIGFkZCBh IHVuaXF1ZSBJZCBpbiBYZW5zdG9yZSB0byBlYWNoDQo+PiBkZXZpY2Ugb24gdGhlIGJhY2tl bmQgc2lkZSwgd2hpY2ggY2FuIGJlIHRlc3RlZCBvbiB0aGUgZnJvbnRlbmQgc2lkZSB0bw0K Pj4gbWF0Y2guIEluIGNhc2UgaXQgZG9lc24ndCBtYXRjaCwgYW4gb2xkIGRldmljZSB3aXRo IHRoZSBzYW1lIGtpbmQgYW5kIGRldmlkDQo+PiBjYW4gYmUgY2xlYW5lZCB1cC4NCj4+DQo+ PiBUaGUgdW5pcXVlIElkIHdvdWxkIG9idmlvdXNseSBuZWVkIHRvIGJlIHNldCBieSB0aGUg WGVuIHRvb2xzIGluc2lkZSB0aGUNCj4+IHRyYW5zYWN0aW9uIHdyaXRpbmcgdGhlIGluaXRp YWwgYmFja2VuZCBYZW5zdG9yZSBub2RlcywgYXMgZG9pbmcgdGhhdCBmcm9tDQo+PiB0aGUg YmFja2VuZCB3b3VsZCBhZGQgYW5vdGhlciBwb3RlbnRpYWwgYW1iaWd1aXR5IGJ5IHRoZSBk cml2ZXIgZG9tYWluDQo+PiBjaG9vc2luZyB0aGUgc2FtZSB1bmlxdWUgaWQgYXMgdGhlIHBy ZXZpb3VzIG9uZSBkaWQuDQo+Pg0KPj4gVGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgc29tZXRo aW5nIGxpa2UgeW91ciBwYXRjaCBzaG91bGQgYmUgdXNlZCBhcyBhDQo+PiBmYWxsYmFjayBp biBjYXNlIHRoZXJlIGlzIG5vIHVuaXF1ZSBJZCBvbiB0aGUgYmFja2VuZCBzaWRlIG9mIHRo ZSBkZXZpY2UNCj4+IGR1ZSB0byBhIHRvbyBvbGQgWGVuIHZlcnNpb24uDQo+IA0KPiBJIHRo aW5rIEkgaGF2ZSBmb3VuZCBhIHNvbHV0aW9uIHdoaWNoIGlzIG11Y2ggbW9yZSBzaW1wbGUs IGFzIGl0IGRvZXNuJ3QNCj4gbmVlZCBhbnkgY2hhbmdlIG9mIHRoZSBwcm90b2NvbCBvciBh bnkgYWRkaXRpb24gb2YgbmV3IGlkZW50aWZpZXJzLg0KPiANCj4gV2hlbiBjcmVhdGluZyBh IG5ldyBQViBkZXZpY2UsIFhlbiB0b29scyB3aWxsIGFsd2F5cyB3cml0ZSBhbGwgZ2VuZXJp Yw0KPiBmcm9udGVuZC0gYW5kIGJhY2tlbmQtbm9kZXMuIFRoaXMgaW5jbHVkZXMgdGhlIGZy b250ZW5kIHN0YXRlLCB3aGljaCBpcw0KPiBpbml0aWFsaXplZCBhcyBYZW5idXNTdGF0ZUlu aXRpYWxpc2luZy4NCj4gDQo+IFRoZSBMaW51eCBrZXJuZWwncyB4ZW5idXMgZHJpdmVyIGlz IGFscmVhZHkgc3RvcmluZyB0aGUgbGFzdCBrbm93biBzdGF0ZQ0KPiBvZiBhIHhlbmJ1cyBk ZXZpY2UgaW4gc3RydWN0IHhlbmJ1c19kZXZpY2UuIFdoZW4gY2hhbmdpbmcgdGhlIHN0YXRl LCB0aGUNCj4geGVuYnVzIGRyaXZlciBpcyBldmVuIHJlYWRpbmcgdGhlIHN0YXRlIGZyb20g WGVuc3RvcmUgKGV2ZW4gaWYgb25seSBmb3INCj4gbWFraW5nIHN1cmUgdGhlIHBhdGggaXMg c3RpbGwgZXhpc3RpbmcpLiBTbyBhbGwgd2hhdCBpcyBuZWVkZWQgaXMgdG8gY2hlY2ssDQo+ IHdoZXRoZXIgdGhlIHJlYWQgY3VycmVudCBzdGF0ZSBpcyBtYXRjaGluZyB0aGUgbG9jYWxs eSBzYXZlZCBzdGF0ZS4gSWYgaXQNCj4gaXMgbm90IG1hdGNoaW5nIEFORCB0aGUgcmVhZCBz dGF0ZSBpcyBYZW5idXNTdGF0ZUluaXRpYWxpc2luZywgeW91IGNhbiBiZQ0KPiBzdXJlIHRo YXQgdGhlIGJhY2tlbmQgaGFzIGJlZW4gcmVwbGFjZWQuDQo+IA0KPiBIYW5kbGluZyB0aGlz IHdpbGwgbmVlZCB0byBjaGVjayB0aGUgcmV0dXJuIHZhbHVlIG9mIHhlbmJ1c19zd2l0Y2hf c3RhdGUoKQ0KPiBpbiBhbGwgcmVsYXRlZCBkcml2ZXJzLCBidXQgdGhpcyBpcyBqdXN0IGEg bW9yZSBvciBsZXNzIG1lY2hhbmljYWwgY2hhbmdlLg0KPiANCj4gSSdsbCBwcmVwYXJlIGEg cGF0Y2ggc2VyaWVzIGZvciB0aGF0Lg0KDQpJbiB0aGUgZW5kIHRoZSByZXN1bHQgaXMgbW9y ZSBsaWtlIHlvdXIgcGF0Y2gsIGF2b2lkaW5nIHRoZSBuZWVkIHRvIG1vZGlmeQ0KYWxsIGRy aXZlcnMuDQoNCkkganVzdCBhZGRlZCBteSBpZGVhIHRvIHlvdXIgcGF0Y2ggYW5kIG1vZGlm aWVkIHNvbWUgb2YgeW91ciBjb2RlIHRvIGJlIG1vcmUNCnNpbXBsZS4gSSBfdGhpbmtfIEkg aGF2ZSBjb3ZlcmVkIGFsbCBwb3NzaWJsZSBzY2VuYXJpb3Mgbm93LCByZXN1bHRpbmcgaW4N CnRoZSBuZWVkIHRvIGtlZXAgdGhlIGJhY2tlbmQgaWQgY2hlY2sgaW4gY2FzZSB0aGUgYmFj a2VuZCBkaWVkIGR1cmluZyB0aGUNCmVhcmx5IGluaXQgcGhhc2Ugb2YgdGhlIGRldmljZS4N Cg0KQ291bGQgeW91IHBsZWFzZSB2ZXJpZnkgdGhlIGF0dGFjaGVkIHBhdGNoIGlzIHdvcmtp bmcgZm9yIHlvdT8NCg0KDQpKdWVyZ2VuDQo= --------------EGatcTEGiFLvn2bUqq64Vaus Content-Type: text/x-patch; charset=UTF-8; name="0001-xen-xenbus-better-handle-backend-crash.patch" Content-Disposition: attachment; filename="0001-xen-xenbus-better-handle-backend-crash.patch" Content-Transfer-Encoding: base64 RnJvbSAzYTdhODI1NzYxMzE0MWVkYjAzODMzYzVkMjc3YjE0ZWUyODY5N2RjIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+ CkRhdGU6IE1vbiwgMjYgSmFuIDIwMjYgMDg6NDU6MTcgKzAxMDAKU3ViamVjdDogW1BBVENI XSB4ZW4veGVuYnVzOiBiZXR0ZXIgaGFuZGxlIGJhY2tlbmQgY3Jhc2gKTUlNRS1WZXJzaW9u OiAxLjAKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PVVURi04CkNvbnRlbnQt VHJhbnNmZXItRW5jb2Rpbmc6IDhiaXQKCldoZW4gdGhlIGJhY2tlbmQgZG9tYWluIGNyYXNo ZXMsIGNvb3JkaW5hdGVkIGRldmljZSBjbGVhbnVwIGlzIG5vdApwb3NzaWJsZSAoYXMgaXQg aW52b2x2ZXMgd2FpdGluZyBmb3IgdGhlIGJhY2tlbmQgc3RhdGUgY2hhbmdlKS4gSW4gdGhh dApjYXNlLCB0b29sc3RhY2sgZm9yY2VmdWxseSByZW1vdmVzIGZyb250ZW5kIHhlbnN0b3Jl IGVudHJpZXMuCnhlbmJ1c19kZXZfY2hhbmdlZCgpIGhhbmRsZXMgdGhpcyBjYXNlLCBhbmQg dHJpZ2dlcnMgZGV2aWNlIGNsZWFudXAuCkl0J3MgcG9zc2libGUgdGhhdCB0b29sc3RhY2sg bWFuYWdlcyB0byBjb25uZWN0IG5ldyBkZXZpY2UgaW4gdGhhdApwbGFjZSwgYmVmb3JlIHhl bmJ1c19kZXZfY2hhbmdlZCgpIG5vdGljZXMgdGhlIG9sZCBvbmUgaXMgbWlzc2luZy4gSWYK dGhhdCBoYXBwZW5zLCBuZXcgb25lIHdvbid0IGJlIHByb2JlZCBhbmQgd2lsbCBmb3JldmVy IHJlbWFpbiBpbgpYZW5idXNTdGF0ZUluaXRpYWxpc2luZy4KCkZpeCB0aGlzIGJ5IGNoZWNr aW5nIHRoZSBmcm9udGVuZCdzIHN0YXRlIGluIFhlbnN0b3JlLiBJbiBjYXNlIGl0IGhhcwpi ZWVuIHJlc2V0IHRvIFhlbmJ1c1N0YXRlSW5pdGlhbGlzaW5nIGJ5IFhlbiB0b29scywgY29u c2lkZXIgdGhpcwpiZWluZyB0aGUgcmVzdWx0IG9mIGFuIHVucGx1ZytwbHVnIG9wZXJhdGlv bi4KCkl0J3MgaW1wb3J0YW50IHRoYXQgY2xlYW51cCBvbiBzdWNoIHVucGx1ZyBkb2Vzbid0 IG1vZGlmeSBYZW5zdG9yZQplbnRyaWVzIChlc3BlY2lhbGx5IHRoZSAic3RhdGUiIGtleSkg YXMgaXQgYmVsb25nIHRvIHRoZSBuZXcgZGV2aWNlCnRvIGJlIHByb2JlZCAtIGNoYW5naW5n IGl0IHdvdWxkIGRlcmFpbCBlc3RhYmxpc2hpbmcgY29ubmVjdGlvbiB0byB0aGUKbmV3IGJh Y2tlbmQgKG1vc3QgbGlrZWx5LCBjbG9zaW5nIHRoZSBkZXZpY2UgYmVmb3JlIGl0IHdhcyBl dmVuCmNvbm5lY3RlZCkuIEhhbmRsZSB0aGlzIGNhc2UgYnkgc2V0dGluZyBuZXcgeGVuYnVz X2RldmljZS0+dmFuaXNoZWQKZmxhZyB0byB0cnVlLCBhbmQgY2hlY2sgaXQgYmVmb3JlIGNo YW5naW5nIHN0YXRlIGVudHJ5LgoKQW5kIGV2ZW4gaWYgeGVuYnVzX2Rldl9jaGFuZ2VkKCkg Y29ycmVjdGx5IGRldGVjdHMgdGhlIGRldmljZSB3YXMKZm9yY2VmdWxseSByZW1vdmVkLCB0 aGUgY2xlYW51cCBoYW5kbGluZyBpcyBzdGlsbCByYWN5LiBTaW5jZSB0aGlzIHdob2xlCmhh bmRsaW5nIGRvZXNuJ3QgaGFwcGVuZWQgaW4gYSBzaW5nbGUgWGVuc3RvcmUgdHJhbnNhY3Rp b24sIGl0J3MgcG9zc2libGUKdGhhdCB0b29sc3RhY2sgbWlnaHQgcHV0IGEgbmV3IGRldmlj ZSB0aGVyZSBhbHJlYWR5LiBBdm9pZCByZS1jcmVhdGluZwp0aGUgc3RhdGUga2V5ICh3aGlj aCBpbiB0aGUgY2FzZSBvZiBsb29zaW5nIHRoZSByYWNlIHdvdWxkIGFjdHVhbGx5CmNsb3Nl IG5ld2x5IGF0dGFjaGVkIGRldmljZSkuCgpUaGUgcHJvYmxlbSBkb2VzIG5vdCBhcHBseSB0 byBmcm9udGVuZCBkb21haW4gY3Jhc2gsIGFzIHRoaXMgY2FzZQppbnZvbHZlcyBjb29yZGlu YXRlZCBjbGVhbnVwLgoKUHJvYmxlbSBvcmlnaW5hbGx5IHJlcG9ydGVkIGF0Cmh0dHBzOi8v bG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC9hT1p2aXZ5WjlZaFZXRExOQG1haWwtaXRsL1Qv I3QsCmluY2x1ZGluZyByZXByb2R1Y3Rpb24gc3RlcHMuCgpCYXNlZC1vbi1wYXRjaC1ieTog TWFyZWsgTWFyY3p5a293c2tpLUfDs3JlY2tpIDxtYXJtYXJla0BpbnZpc2libGV0aGluZ3Ns YWIuY29tPgpTaWduZWQtb2ZmLWJ5OiBKdWVyZ2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+ Ci0tLQogZHJpdmVycy94ZW4veGVuYnVzL3hlbmJ1c19jbGllbnQuYyB8ICA5ICsrKysrKy0t CiBkcml2ZXJzL3hlbi94ZW5idXMveGVuYnVzX3Byb2JlLmMgIHwgMzQgKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrCiBpbmNsdWRlL3hlbi94ZW5idXMuaCAgICAgICAgICAgICAg IHwgIDEgKwogMyBmaWxlcyBjaGFuZ2VkLCA0MiBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9u cygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL3hlbmJ1cy94ZW5idXNfY2xpZW50LmMg Yi9kcml2ZXJzL3hlbi94ZW5idXMveGVuYnVzX2NsaWVudC5jCmluZGV4IDJkYzg3NGZiNTUw Ni4uMGQ5OWExZjYwZGY0IDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi94ZW5idXMveGVuYnVz X2NsaWVudC5jCisrKyBiL2RyaXZlcnMveGVuL3hlbmJ1cy94ZW5idXNfY2xpZW50LmMKQEAg LTIyNiw4ICsyMjYsOSBAQCBfX3hlbmJ1c19zd2l0Y2hfc3RhdGUoc3RydWN0IHhlbmJ1c19k ZXZpY2UgKmRldiwKIAlzdHJ1Y3QgeGVuYnVzX3RyYW5zYWN0aW9uIHhidDsKIAlpbnQgY3Vy cmVudF9zdGF0ZTsKIAlpbnQgZXJyLCBhYm9ydDsKKwlib29sIHZhbmlzaGVkID0gZmFsc2U7 CiAKLQlpZiAoc3RhdGUgPT0gZGV2LT5zdGF0ZSkKKwlpZiAoc3RhdGUgPT0gZGV2LT5zdGF0 ZSB8fCBkZXYtPnZhbmlzaGVkKQogCQlyZXR1cm4gMDsKIAogYWdhaW46CkBAIC0yNDIsNiAr MjQzLDEwIEBAIF9feGVuYnVzX3N3aXRjaF9zdGF0ZShzdHJ1Y3QgeGVuYnVzX2RldmljZSAq ZGV2LAogCWVyciA9IHhlbmJ1c19zY2FuZih4YnQsIGRldi0+bm9kZW5hbWUsICJzdGF0ZSIs ICIlZCIsICZjdXJyZW50X3N0YXRlKTsKIAlpZiAoZXJyICE9IDEpCiAJCWdvdG8gYWJvcnQ7 CisJaWYgKGN1cnJlbnRfc3RhdGUgIT0gZGV2LT5zdGF0ZSAmJiBjdXJyZW50X3N0YXRlID09 IFhlbmJ1c1N0YXRlSW5pdGlhbGlzaW5nKSB7CisJCXZhbmlzaGVkID0gdHJ1ZTsKKwkJZ290 byBhYm9ydDsKKwl9CiAKIAllcnIgPSB4ZW5idXNfcHJpbnRmKHhidCwgZGV2LT5ub2RlbmFt ZSwgInN0YXRlIiwgIiVkIiwgc3RhdGUpOwogCWlmIChlcnIpIHsKQEAgLTI1Niw3ICsyNjEs NyBAQCBfX3hlbmJ1c19zd2l0Y2hfc3RhdGUoc3RydWN0IHhlbmJ1c19kZXZpY2UgKmRldiwK IAkJaWYgKGVyciA9PSAtRUFHQUlOICYmICFhYm9ydCkKIAkJCWdvdG8gYWdhaW47CiAJCXhl bmJ1c19zd2l0Y2hfZmF0YWwoZGV2LCBkZXB0aCwgZXJyLCAiZW5kaW5nIHRyYW5zYWN0aW9u Iik7Ci0JfSBlbHNlCisJfSBlbHNlIGlmICghdmFuaXNoZWQpCiAJCWRldi0+c3RhdGUgPSBz dGF0ZTsKIAogCXJldHVybiAwOwpkaWZmIC0tZ2l0IGEvZHJpdmVycy94ZW4veGVuYnVzL3hl bmJ1c19wcm9iZS5jIGIvZHJpdmVycy94ZW4veGVuYnVzL3hlbmJ1c19wcm9iZS5jCmluZGV4 IDg2ZmU2ZTc3OTA1Ni4uZmNkNTlhMjEwOWMzIDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi94 ZW5idXMveGVuYnVzX3Byb2JlLmMKKysrIGIvZHJpdmVycy94ZW4veGVuYnVzL3hlbmJ1c19w cm9iZS5jCkBAIC00NDQsNiArNDQ0LDkgQEAgc3RhdGljIHZvaWQgeGVuYnVzX2NsZWFudXBf ZGV2aWNlcyhjb25zdCBjaGFyICpwYXRoLCBzdHJ1Y3QgYnVzX3R5cGUgKmJ1cykKIAkJaW5m by5kZXYgPSBOVUxMOwogCQlidXNfZm9yX2VhY2hfZGV2KGJ1cywgTlVMTCwgJmluZm8sIGNs ZWFudXBfZGV2KTsKIAkJaWYgKGluZm8uZGV2KSB7CisJCQlkZXZfd2FybigmaW5mby5kZXYt PmRldiwKKwkJCQkgImRldmljZSBmb3JjZWZ1bGx5IHJlbW92ZWQgZnJvbSB4ZW5zdG9yZVxu Iik7CisJCQlpbmZvLmRldi0+dmFuaXNoZWQgPSB0cnVlOwogCQkJZGV2aWNlX3VucmVnaXN0 ZXIoJmluZm8uZGV2LT5kZXYpOwogCQkJcHV0X2RldmljZSgmaW5mby5kZXYtPmRldik7CiAJ CX0KQEAgLTY1OSw2ICs2NjIsMzcgQEAgdm9pZCB4ZW5idXNfZGV2X2NoYW5nZWQoY29uc3Qg Y2hhciAqbm9kZSwgc3RydWN0IHhlbl9idXNfdHlwZSAqYnVzKQogCQlyZXR1cm47CiAKIAlk ZXYgPSB4ZW5idXNfZGV2aWNlX2ZpbmQocm9vdCwgJmJ1cy0+YnVzKTsKKwkvKgorCSAqIEJh Y2tlbmQgZG9tYWluIGNyYXNoIHJlc3VsdHMgaW4gbm90IGNvb3JkaW5hdGVkIGZyb250ZW5k IHJlbW92YWwsCisJICogd2l0aG91dCBnb2luZyB0aHJvdWdoIFhlbmJ1c1N0YXRlQ2xvc2lu Zy4gSWYgdGhpcyBpcyBhIG5ldyBpbnN0YW5jZQorCSAqIG9mIHRoZSBzYW1lIGRldmljZSBY ZW4gdG9vbHMgd2lsbCBoYXZlIHJlc2V0IHRoZSBzdGF0ZSB0bworCSAqIFhlbmJ1c1N0YXRl SW5pdGlhbGl6aW5nLgorCSAqIEl0IG1pZ2h0IGJlIHRoYXQgdGhlIGJhY2tlbmQgY3Jhc2hl ZCBlYXJseSBkdXJpbmcgdGhlIGluaXQgcGhhc2Ugb2YKKwkgKiBkZXZpY2Ugc2V0dXAsIGlu IHdoaWNoIGNhc2UgdGhlIGtub3duIHN0YXRlIHdvdWxkIGhhdmUgYmVlbgorCSAqIFhlbmJ1 c1N0YXRlSW5pdGlhbGl6aW5nLiBTbyB0ZXN0IHRoZSBiYWNrZW5kIGRvbWlkIHRvIG1hdGNo IHRoZQorCSAqIHNhdmVkIG9uZS4gSW4gY2FzZSB0aGUgbmV3IGJhY2tlbmQgaGFwcGVucyB0 byBoYXZlIHRoZSBzYW1lIGRvbWlkIGFzCisJICogdGhlIG9sZCBvbmUsIHdlIGNhbiBqdXN0 IGNhcnJ5IG9uLCBhcyB0aGVyZSBpcyBubyBpbmNvbnNpc3RlbmN5CisJICogcmVzdWx0aW5n IGluIHRoaXMgY2FzZS4KKwkgKi8KKwlpZiAoZGV2ICYmICFzdHJjbXAoYnVzLT5yb290LCAi ZGV2aWNlIikpIHsKKwkJZW51bSB4ZW5idXNfc3RhdGUgc3RhdGUgPSB4ZW5idXNfcmVhZF9k cml2ZXJfc3RhdGUoZGV2LT5ub2RlbmFtZSk7CisJCXVuc2lnbmVkIGludCBiYWNrZW5kID0g eGVuYnVzX3JlYWRfdW5zaWduZWQocm9vdCwgImJhY2tlbmQtaWQiLAorCQkJCQkJCSAgICBk ZXYtPm90aGVyZW5kX2lkKTsKKworCQlpZiAoc3RhdGUgPT0gWGVuYnVzU3RhdGVJbml0aWFs aXNpbmcgJiYKKwkJICAgIChzdGF0ZSAhPSBkZXYtPnN0YXRlIHx8IGJhY2tlbmQgIT0gZGV2 LT5vdGhlcmVuZF9pZCkpIHsKKwkJCS8qCisJCQkgKiBTdGF0ZSBoYXMgYmVlbiByZXNldCwg YXNzdW1lIHRoZSBvbGQgb25lIHZhbmlzaGVkCisJCQkgKiBhbmQgbmV3IG9uZSBuZWVkcyB0 byBiZSBwcm9iZWQuCisJCQkgKi8KKwkJCWRldl93YXJuKCZkZXYtPmRldiwKKwkJCQkgInN0 YXRlIHJlc2V0IG9jY3VycmVkLCByZWNvbm5lY3RpbmdcbiIpOworCQkJZGV2LT52YW5pc2hl ZCA9IHRydWU7CisJCQlkZXZpY2VfdW5yZWdpc3RlcigmZGV2LT5kZXYpOworCQkJcHV0X2Rl dmljZSgmZGV2LT5kZXYpOworCQkJZGV2ID0gTlVMTDsKKwkJfQorCX0KIAlpZiAoIWRldikK IAkJeGVuYnVzX3Byb2JlX25vZGUoYnVzLCB0eXBlLCByb290KTsKIAllbHNlCmRpZmYgLS1n aXQgYS9pbmNsdWRlL3hlbi94ZW5idXMuaCBiL2luY2x1ZGUveGVuL3hlbmJ1cy5oCmluZGV4 IGM5NGNhZjg1MmFlYS4uMDY0Y2I2ZGI1ZTlmIDEwMDY0NAotLS0gYS9pbmNsdWRlL3hlbi94 ZW5idXMuaAorKysgYi9pbmNsdWRlL3hlbi94ZW5idXMuaApAQCAtODAsNiArODAsNyBAQCBz dHJ1Y3QgeGVuYnVzX2RldmljZSB7CiAJY29uc3QgY2hhciAqZGV2aWNldHlwZTsKIAljb25z dCBjaGFyICpub2RlbmFtZTsKIAljb25zdCBjaGFyICpvdGhlcmVuZDsKKwlib29sIHZhbmlz aGVkOwogCWludCBvdGhlcmVuZF9pZDsKIAlzdHJ1Y3QgeGVuYnVzX3dhdGNoIG90aGVyZW5k X3dhdGNoOwogCXN0cnVjdCBkZXZpY2UgZGV2OwotLSAKMi41Mi4wCgo= --------------EGatcTEGiFLvn2bUqq64Vaus 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----- --------------EGatcTEGiFLvn2bUqq64Vaus-- --------------PhLWTsoxQzJZG6MEoRpp76NV-- --------------kEB9N9B3dVD3DUQAKW7WZdOy 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/Ey8FAml7BgsFAwAAAAAACgkQsN6d1ii/Ey82 XQf5Adw27gxaJExKEuD1bzphbbeNSqO9KfRve6DXvwJmFIbZxAqwA9U3arfNmkuVBUGxNcv6BPi9 vBwSG2S/FwqZi56wzRJugMn8I/b8DG8IEPg0TsYOyhJ83mrw69tk9ny5MK6oH3Y8SHVVgm/jKbpi +BNMN83f60OEHyq7QKbg6l2/zkAQigFKOSTXXzrKdsvnNb5Qf7v+a9uTsER65F9h9xfIfR+v0Nrw SVu8/TjDdlYEjvarkDTMq2a3HkRP3cAY6QtEkGOM4YT6gWB3LMa/S8IaIe8eXSyO5F0mIeKWKa1G Q5RaBia0QicJCYaChheUUwTjbW4XEoc/qMvDEABsJw== =+KZb -----END PGP SIGNATURE----- --------------kEB9N9B3dVD3DUQAKW7WZdOy-- From xen-devel-bounces@lists.xenproject.org Thu Jan 29 07:32:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 07:32:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216098.1526064 (Exim 4.92) (envelope-from ) id 1vlMVm-0002b7-9e; Thu, 29 Jan 2026 07:32:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216098.1526064; Thu, 29 Jan 2026 07:32:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlMVm-0002b0-73; Thu, 29 Jan 2026 07:32:18 +0000 Received: by outflank-mailman (input) for mailman id 1216098; Thu, 29 Jan 2026 07:32:17 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlMVl-0002au-64 for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 07:32:17 +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 a0eca153-fce4-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 08:32:14 +0100 (CET) Received: from AM0P190CA0008.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:190::18) by AM8PR08MB6452.eurprd08.prod.outlook.com (2603:10a6:20b:360::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.10; Thu, 29 Jan 2026 07:32:10 +0000 Received: from AM3PEPF0000A795.eurprd04.prod.outlook.com (2603:10a6:208:190:cafe::a3) by AM0P190CA0008.outlook.office365.com (2603:10a6:208:190::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.8 via Frontend Transport; Thu, 29 Jan 2026 07:32:00 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by AM3PEPF0000A795.mail.protection.outlook.com (10.167.16.100) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Thu, 29 Jan 2026 07:32:08 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by AS8PR08MB6598.eurprd08.prod.outlook.com (2603:10a6:20b:336::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Thu, 29 Jan 2026 07:31:05 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%4]) with mapi id 15.20.9542.010; Thu, 29 Jan 2026 07:31: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: a0eca153-fce4-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=bRPUg4UxuwTh0R0IVX/4JfarMX71Q+XV9QcC50F6T32+0uedeUefhHaCnLGBDDIAeBs2ipXVqEMf9qQJhQK3Uo7MTJj1xEaT5WcfKaMIf5c/SAeoE/aZ1Slvses9Zxf6HaTF0LMYO4recztlpVtd/tfwT+t5vp2q7j9byOz2hWZarD1i3pym129NEsRoomfbaUnDRlBEn3s/dNgW2msPqfs4luRbuLX3Bj5jjol5iCCx8jCP/BEWRX9Qu2QPX+CzyicdehRLScORosBNtxIJiYEaYLiQW5NPvknqpv3zyfRMM6NbCsz6eeARx/F7g2OPiWqW3GWYJtqwE4k+HV1TSQ== 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=UEjypzYN82bqcXiGPDnC3sJ0xL7gs0zz/Rwhq0tsCo8=; b=NLyptnpFYrQFQHT+1lCoJeQEomiLxiMWVxtrIP2dhI1QqI7VlkYCQMz3TQR7bDHwdPET/08T0GdSVozb7O4HuNCFYsOnNgmCBfyhdGg/IGCjBofZGIS/ew5r7FnONEt5naco+ZmxeTIa4TzDTQCwZnogC7h8s7kOPbfl54yyDtScOgjHwQ67FM1PPjhE0LWhr0BfTGW2K+cJlBxtoyohdarYuw19nZfxJfB7oaJEQ8K4qtyWZj8zW6pdEhaEcr8BUuFEYaf8Tt2mbJARXXB5nJHR9bW4asLarx7UWUCcIqWbrzf3KFvrKeMIOdhm8/al8sB3Q3kiTvkt5NiWypnSTA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=xen.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=UEjypzYN82bqcXiGPDnC3sJ0xL7gs0zz/Rwhq0tsCo8=; b=VC0rJvrB0+lhjGt2vWyQNkJWU+ErpRAYph+49QEePdNqUpIHSHHnAKgtYFYL/S9yORiCWTYWHqaIl3E0CicH93hOWGw7oLBb82sbld62uPCg/8Bqotfa4iiCsE7CtnrBgUKOGAjtzfgjFjMn5pNrqjGkiAyPqrWuVZn/W5W2bPI= 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=kuOfDJZzIOVTMZzOaAqgx52OfRmR9SggYcXsX6G9pbe9NiHzUH/iVyYy5zp99FdElmg+2CxLlh8YKEN01pZJNZK3SkaDLuotz8j1kA0cbZAXnDdRy2JOLGxCRI6JAgSznDBBmq5e60G7GyLlFM2ysbNH7+Mi2V70A2Qg+z3fjoqs3Kx1G7Pyi6SRx89sR17NNY3bpC5a1PmXPK15572dh5oQiQ4GrT601kzWdtCrNZuA0oqu2a7shqeCSp3uawPQRkWXVXRdtN8N1rpSD8sL52ViEn5UFgMdCyCK7+yVw9uTd7rSyvMmrnw2yBpFe6ClwSN8ceZubI6JZ+SxymIIJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UEjypzYN82bqcXiGPDnC3sJ0xL7gs0zz/Rwhq0tsCo8=; b=EDXpCjsfVQGPNnbGSYumikJru24trggMxaNClDYxHbxv9ohL3o/iSsrp7vJRBRcR8MB+k5R2Ii8dCIu6LvQtUIxJBBtfB3XDRrHZvoBM3qakjFcAgcBFBRPqzLoaxZa9fBP/f6x15NeLbMphpKrjtflNA7mXS2+SJarI9l60DAI/UFxe7cbIasp8/Q16v5dMvO43wRFPaGSbvPfYYUf8+LR78xqTgxyrart7LULhQ/ggmD0/BzK8jYZUsR8prVJHKPIOMokeZ571PjdUrdpfOvHCitz69iWEEqZhCHk0IdYsnsB9k4CM1CK2uv9gHNufl3hX6EpjVKBrxwo6zc4cwQ== 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=UEjypzYN82bqcXiGPDnC3sJ0xL7gs0zz/Rwhq0tsCo8=; b=VC0rJvrB0+lhjGt2vWyQNkJWU+ErpRAYph+49QEePdNqUpIHSHHnAKgtYFYL/S9yORiCWTYWHqaIl3E0CicH93hOWGw7oLBb82sbld62uPCg/8Bqotfa4iiCsE7CtnrBgUKOGAjtzfgjFjMn5pNrqjGkiAyPqrWuVZn/W5W2bPI= From: Bertrand Marquis To: Julien Grall CC: Michal Orzel , "jens.wiklander@linaro.org" , Volodymyr Babchuk , Stefano Stabellini , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v2 00/12] xen/arm: ffa: FF-A v1.2 support Thread-Topic: [PATCH v2 00/12] xen/arm: ffa: FF-A v1.2 support Thread-Index: AQHcbdIZ54xp46f98kibMufFF0ZVibVIDZyAgCBW4YCAAKJHgA== Date: Thu, 29 Jan 2026 07:31:05 +0000 Message-ID: References: <2FA52A4C-98F2-4066-8BE7-36F37093FCD6@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.300.41.1.7) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|AS8PR08MB6598:EE_|AM3PEPF0000A795:EE_|AM8PR08MB6452:EE_ X-MS-Office365-Filtering-Correlation-Id: 3c3dc66f-7248-4078-74c7-08de5f08828a x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|366016|376014|1800799024|10070799003|38070700021; X-Microsoft-Antispam-Message-Info-Original: =?us-ascii?Q?ONWKFmx64vGFQrt+YkqvWufo9RLdgZEkv4LuK/iabvEr+lIswOXldHv4uwXI?= =?us-ascii?Q?1P+QSjKYN1ktQnpLllYPDgRbs8JlAlgZ3wrGWC2beOL5L/PdxUAdR6lV3ceY?= =?us-ascii?Q?Cz7kYzQ2f3pbbOIqaS1kljrRtRSGUNhsWceYXynkrVO1/GjUKdTH6hXVBHhL?= =?us-ascii?Q?HLXkGx6beUvkJ8gahSbMXTgogos56YLXEf555m+tseP6Vea+CnW0fxp5RHWE?= =?us-ascii?Q?7QC/Gwj/LioT5sJb9fzmhprDTlUinfV/COagvS6EOVfrnUvgZFqsPmRKe8Kj?= =?us-ascii?Q?rnbtw4AH4x83DnCZCkiFXX14P645HxVXjzMJ4J13qPCG81zVuhjiOoPR/csd?= =?us-ascii?Q?DLruCgpglKdzOU628dTNzAXNPuRhLJJZJf47TGtMMKsII+Ob3E+YHz/zqHdM?= =?us-ascii?Q?S+sLFnz65j4Y211sDSeD9lqHOm7EArzduJOxU+cgpXLTsJuJxnvVcYotF6N4?= =?us-ascii?Q?iU0kp3slvsx18mAH7SHbxQ9W0IuNdcm0GxdHResaZPR6HzyaQ2WX3KaDwObO?= =?us-ascii?Q?uDZ5cQoYtL6PJx9nMXHBxsIhyaQEQMdq5sS+E6btw7imn2GRGByBQuPf+VcB?= =?us-ascii?Q?NF38qxTZmPhZQnh9mV5OwYonOFgeKsQoB40KX210OdVMhH49c/ytUAOosU6m?= =?us-ascii?Q?Dqt7rO9TNGrxn6hF7/NXSbVAK3bxzVq9BLVkvR21NXQF8/50YfC8prINY7xG?= =?us-ascii?Q?6uhe2PirFg1xc4ynFXCXdCacbisJjzeYdGHTBJVCUufOuwW3hvOQxvX7aXPC?= =?us-ascii?Q?aZwumi/afr5gLFVuD2BeKvEI+p+toYOPze0fDtogdJFUaFue0EH7/Wkln2I3?= =?us-ascii?Q?uNMrzxf5sv3qWCsSrhkTLxSsfeGb8OuF1zZjgtvUjZcZ84c4StYS/UhZC7ff?= =?us-ascii?Q?9MNtTQ3+ab+XoLUeLZiT9ASacJio7981sm67sYeGviW7CCG0Iu2BhuU71yQx?= =?us-ascii?Q?rdX7Jm36ZShA75gfag28yH+3dJN2cPpQU5dsaeUj7lPZpGS2Z57IF7nkPLKx?= =?us-ascii?Q?sMjALwIPuZjstWZH+skqHbKRAbfNDwSN4D0ImZUBuZxqfNqgidlYl2mUUkA9?= =?us-ascii?Q?RZLs0qIdMYh7+G9LIAeF3gWbJFEILeXn+SBFknFQhZbc++GqqkxNAVSYT3Ps?= =?us-ascii?Q?l85VNKJHtknP4byatOWKJnf8nLmw1CVq7VomVpS5Ue3DikTOw7D833IeKa0I?= =?us-ascii?Q?EqIQ9B6WZpfTvGxBfSSBoi+WulBVXHtnVbsd8xe5w4JHCt0c1Epji4AQ4qmp?= =?us-ascii?Q?F4VzPfL4YBQ6e8Cbts5iSRN9L+1VbpqcgFZBjl3vpZs1+Wk10G/rDaTDp0DF?= =?us-ascii?Q?zTxEmyezIQBj2mxdlVA0ZF8kYqjHDvF6OBCcNW4XmMpyCLY0mnUBXgq+5QZc?= =?us-ascii?Q?/lC6aNiHyk4+zY68rlimiyHI70NFFK/Z8fkJ3l+JPnJugqDtTYd1ulFyVKeA?= =?us-ascii?Q?Bvl4UnLCWbGQ0FkmIOdLJ+lEWxlRGx3WlElHT2jaOmucRKYqIiDpyIKrIYUz?= =?us-ascii?Q?I2U16pta8aMQU18lO451m1WaIu76XmQJTBJcMnt+/9lxJ61mxLGq339Y/EzQ?= =?us-ascii?Q?ci9uc99tywqP5yab9q1XsuAaLofk4I8FA/EzwVxMHZnvfDJgsUhgu15MgCQh?= =?us-ascii?Q?PHDqp9iLOIfv9OkJBRLaGjg=3D?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR08MB5593.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(10070799003)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-ID: <7EC78C2FEF00974C920FAB450D77B68B@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB6598 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM3PEPF0000A795.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: aed099eb-4cd2-4d90-f7d5-08de5f085ce5 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|35042699022|376014|1800799024|82310400026|14060799003|7053199007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?aCEwl9aaqlTWetoZkAzzM+bLljrHOkisJJCNL4Zdf+lO0Ao80ybCiMo0kM1X?= =?us-ascii?Q?FnfFxtPZ1s8sChVTpQ1n6ca9YSbQxSnF9FcGAm+ttV9dPM8lG3aiEonnHYUN?= =?us-ascii?Q?rIG7q1tUHYzfskaZu2rptXrrnr/DsAd87mBJGoKrqdstkM6GKny8Fdpfx1TP?= =?us-ascii?Q?ammfnkF9h+VYQAQcb/FjzZk+Esu7zIGAl1SZgFJ+wNO/V2ZlDcyTzUkhtRzz?= =?us-ascii?Q?qvYuhAA9cwZHi+bo91jVtf8H/akJ/cilIvqx3JAZcMQrSjr77MjPjoyKVGLl?= =?us-ascii?Q?ihIKDJrIoFljptetF+Tca+XNxzec9y2Jr6Dlx5yYC9S0S+kWMgtHgaI7K9E2?= =?us-ascii?Q?jNvtVNmlk6zwKKNNIFPrdog74Ge4BMDuJlSK6+OaY40f9UiTT2jnx0SC4Lvr?= =?us-ascii?Q?v4gL8rRypfstk41vD2cr04b0pzfSEkPjxHx3/qNjvn2WVrrwxJ7i4yJ7Gyre?= =?us-ascii?Q?Oe7GHpi/iZmFmiqrpb44XVfdPoryyi/uz+ickGobmR7GiF0jczFAjQy+ALKk?= =?us-ascii?Q?19mVhdFTs8aoHvbBWRN5fbLK4TLt4+uSIM12LXqFuD+M3ihILkTkIDvVUaCt?= =?us-ascii?Q?h6C+OWoKjOpZqC77sS4SbMgxImVQNx9nmQ+g0L7QQbNH08Al/kf5w9isef6o?= =?us-ascii?Q?DPOxHrMpaTeqQXRs/kncE/MPoGomuXv7e7ETLDSaK/lqX6zb1H3XWw6lOaKh?= =?us-ascii?Q?qBaRREcidat2Hlv3rKiM5wLm973SOIpn247U6HiXcQr74Vqa7aF3aUVeZuMx?= =?us-ascii?Q?3XZkLiYSs00dNxZ4HSojbzVrp0B3HPWp/MIfHB5GuC0s3LtluvjHG3SGi66a?= =?us-ascii?Q?wQEBb5gSuUi2qKqqTSXsPuELQhbzjJtplaGHSkwbTKTA5UoC/oGYVwy+pH4C?= =?us-ascii?Q?KuPSddOrIGcaVDeacNMoxlG4Zw+lpslD/hSWHD3a91R8699Rcee2D+r+7A6w?= =?us-ascii?Q?kmhGq46lkom5HWgVWmkRL0RnuUA0rlRkdrnhCiXxebVhMWwO8Toov0MIcVcl?= =?us-ascii?Q?xM7IGtXiNzMZc9VbfO4cUM438ANA7miO2VtQPIBm56GJ4E16ox3CjjlXWnCv?= =?us-ascii?Q?AkEn39TkoSMj8XsEPOJFL30hLaKd65QO1mMeMbE0H3lPiHpJNkkgkdYtO4e/?= =?us-ascii?Q?5UhD4mZmHL0PPB7iCBKG0u6ClCDppQQjVtZl2Zy4i98/xWAljzbx0jd/E3le?= =?us-ascii?Q?Mg6nzs/YyrT4IQoYVPUzxyNg+xz6+H3wLCk8XYCNbSKFeyvyOpEx8n69xN51?= =?us-ascii?Q?7WIlr7E/LhtkcQBdaQaQXH14bH0Gn2cJDna6cKBtnjX9vXUY9cjU/R7X13qt?= =?us-ascii?Q?qh9XGxqXKnvm3YnooNiBNnbkr5uPmlV9vWf0awPhyTf8jSKGDqRI0HkINAfU?= =?us-ascii?Q?rROPFO/1NB5ytkGrJ1rl140BolGitWkbT+6BaanV5+m6Z0oPMT+5o/ASlIKZ?= =?us-ascii?Q?iYA481Y5xqFwftbcYZzCsQoVrfFx+WUVbcTnCG6Pw6FINWDg7ElNZPd98oq0?= =?us-ascii?Q?g4fyceKOsq1S3PJqq3GzGMiCpzO3EH0Qo+KQj83vh+j6TUsNRGr/MwxTt0gS?= =?us-ascii?Q?4ZBTr4Tq9CxrEPEW0/sDTrxKO3IZyt9pAfis+weSDzSMFiyXXjGKBH318uJv?= =?us-ascii?Q?2vwNf9cOtAE4CVe9O3WDba//FcOIlZMrrki4/tu/zYheejsvY3Fd2oEVqPaF?= =?us-ascii?Q?x1UfSA=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)(36860700013)(35042699022)(376014)(1800799024)(82310400026)(14060799003)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2026 07:32:08.6733 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3c3dc66f-7248-4078-74c7-08de5f08828a 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: AM3PEPF0000A795.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB6452 Hi Julien, > On 28 Jan 2026, at 22:50, Julien Grall wrote: >=20 > Hi Bertrand, >=20 > On 08/01/2026 07:59, Bertrand Marquis wrote: >> Gentle ping: This serie has been fully reviewed by Jens and would need a= maintainer ack or review. >=20 > As we discussed during the last Arm maintainer call, as you maintain TEE = with Volodymyr, you technically only need a reviewed-by from someone from t= he community with suitable stature to review. >=20 > I think in this case, you meet all the requirements with Jen's acked-by. = So I will commit the series as-is. Thanks a lot. Would it make sense to add Jens as reviewer for tee ? He is involved and knowledgeable in both ffa and optee implementation. @Jens: Would you be ok with that ? Cheers Bertrand From xen-devel-bounces@lists.xenproject.org Thu Jan 29 07:37:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 07:37:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216108.1526075 (Exim 4.92) (envelope-from ) id 1vlMaT-00039Y-Qz; Thu, 29 Jan 2026 07:37:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216108.1526075; Thu, 29 Jan 2026 07:37:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlMaT-00039R-OE; Thu, 29 Jan 2026 07:37:09 +0000 Received: by outflank-mailman (input) for mailman id 1216108; Thu, 29 Jan 2026 07:37: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 1vlMaR-00039L-Sr for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 07:37:08 +0000 Received: from submarine.notk.org (submarine.notk.org [62.210.214.84]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4ede1266-fce5-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 08:37:05 +0100 (CET) Received: from gaia.codewreck.org (localhost [127.0.0.1]) by submarine.notk.org (Postfix) with ESMTPS id 3CEA914C2D6; Thu, 29 Jan 2026 08:36:56 +0100 (CET) Received: from localhost (gaia.codewreck.org [local]) by gaia.codewreck.org (OpenSMTPD) with ESMTPA id d3792bec; Thu, 29 Jan 2026 07:36:55 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4ede1266-fce5-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1769672219; 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=pQDqB+mpzOzpDLWettESVpWi4zTuQoKZ83rJ5PXlXsE=; b=Utfzl1e36A2wZv76F17RVhsSsXY0plzYVCueTuT85WwlXMo1A38GOI7w8DmPKUgsaSjKLY 28kUw9EOU1a7YYghh+r3TM9fBC9H/6y8hiA0QFzI8vWSTFunw8BsAJj7liML7O8AKuimDm IbGyQKd+g0qg7xNLiGdA+9hR43thY5644oMToIvD+kV4qTqWXU3TPHzp35/HebnU5aaL9q NoyKrZjsOYhLZIrtCWCmhAYJx+QOQ9E6GQKL86rZwsGsu/kFpPbptpWBw8lB0kW5YACTew VgjRwkmTHrfUE3s9f/ndkr+YkoahiOK5WRpl56T1bfBo7pXfQDA3EWG2R4lFmQ== Date: Thu, 29 Jan 2026 16:36:40 +0900 From: Dominique Martinet To: Stefano Stabellini Cc: Stefano Stabellini , xen-devel@lists.xenproject.org, jgross@suse.com, v9fs@lists.linux.dev, Eric Van Hensbergen , Latchesar Ionkov , Christian Schoenebeck Subject: Re: [PATCH] 9p/xen: protect xen_9pfs_front_free against concurrent calls Message-ID: References: <20260123184009.1298536-1-stefano.stabellini@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Stefano Stabellini wrote on Mon, Jan 26, 2026 at 02:09:01PM -0800: > > I don't understand this priv->rings != NULL check here; > > if it's guarding for front_free() called before front_init() then it > > doesn't need to be checked at every iteration, and if it can change in > > another thread I don't see why it would be safe. > > xen_9pfs_front_free() can be reached from the error paths before any > rings are allocated, so we need to handle a NULL priv->rings but it > doesn't have to be checked at every iteration. I can move it before the > for loop as you suggested. Yes, please move it above the loop > > > @@ -310,9 +306,18 @@ static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv) > > > > > > static void xen_9pfs_front_remove(struct xenbus_device *dev) > > > { > > > - struct xen_9pfs_front_priv *priv = dev_get_drvdata(&dev->dev); > > > + struct xen_9pfs_front_priv *priv; > > > > > > + write_lock(&xen_9pfs_lock); > > > + priv = dev_get_drvdata(&dev->dev); > > > + if (priv == NULL) { > > > + write_unlock(&xen_9pfs_lock); > > > + return; > > > + } > > > dev_set_drvdata(&dev->dev, NULL); > > > + list_del_init(&priv->list); > > > > There's nothing wrong with using the del_init() variant here, but it > > would imply someone else could still access it after the unlock here, > > which means to me they could still access it after priv is freed in > > xen_9pfs_front_free(). > > >From your commit message I think the priv == NULL check and > > dev_set_drvdata() under lock above is enough, can you confirm? > > Yes you are right. I can replace list_del_init with list_del if you > think it is clearer. Since you'll send a v2 for the loop check, might as well do this as well if you don't mind. > > > @@ -473,6 +482,11 @@ static int xen_9pfs_front_init(struct xenbus_device *dev) > > > goto error; > > > } > > > > > > + write_lock(&xen_9pfs_lock); > > > + dev_set_drvdata(&dev->dev, priv); > > > > Honest question: could xen_9pfs_front_init() also be called multiple > > times as well? > > (if so this should check for the previous drvdata and free the priv > > that was just built if it was non-null) > > > > Please ignore this if you think that can't happen, I really don't > > know. > > That should not be possible before freeing priv first: > xen_9pfs_front_init is only called when the frontend is in the > XenbusStateInitialising state (see xen_9pfs_front_changed). Once we > store priv we immediately switch the state to XenbusStateInitialised, > and there will be no more calls to xen_9pfs_front_init. If the backend > forces a re-probe, xenbus invokes xen_9pfs_front_remove first, which > frees priv. Ok, this makes sense to me. I don't have any setup to test xen so trusting you here, but this looks sane enough so will apply v2 when you send it -- Dominique Martinet | Asmadeus From xen-devel-bounces@lists.xenproject.org Thu Jan 29 07:53:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 07:53:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216118.1526085 (Exim 4.92) (envelope-from ) id 1vlMq0-0005xl-3c; Thu, 29 Jan 2026 07:53:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216118.1526085; Thu, 29 Jan 2026 07:53:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlMq0-0005xe-0U; Thu, 29 Jan 2026 07:53:12 +0000 Received: by outflank-mailman (input) for mailman id 1216118; Thu, 29 Jan 2026 07:53:11 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlMpz-0005xW-3B for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 07:53:11 +0000 Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [2a00:1450:4864:20::430]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8d2db3aa-fce7-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 08:53:08 +0100 (CET) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-43596062728so1040054f8f.1 for ; Wed, 28 Jan 2026 23:53:08 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806ce4c3c6sm113214785e9.10.2026.01.28.23.53.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 23:53:07 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8d2db3aa-fce7-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769673187; x=1770277987; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=vzVRxjp+KgK45VmAjNvmwskHCy+VcHU0ccYFsRmd2uE=; b=K3OW9y+20KX2R8E/FRl9bL4ICSE00BBwMLzhEHpLbGyKT31Kk6dPTvnbuVkolbsoWc VTLaREJ5qF+AXq01zJ+uMCfBldfnPwtCbEFObUgdydd3hgX6wo4sHu200sNhBKh0lP+g tHtGJKXht/OHyIMoMn+lmR2uuY79YP57FnCCnd7dNUiZ9aLhWSzB84zaHa2qq1Ps3Qwt Yi9WClo2VIpDLll+SUT531omoMhhdqL3MLQoT+opDayQwjNblWGFG/oWKngNQL+/NkVQ DHX4mRYV53e9qrp1gr3Eq5kbzQUuucZHyKT+qQy7aQC4getQ285VeyCcRbLTZrNvmvf+ tRew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769673187; x=1770277987; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vzVRxjp+KgK45VmAjNvmwskHCy+VcHU0ccYFsRmd2uE=; b=ipz/6Ai/oGa/0VNF7CBiLE6rKFrDx8VIyuIO/iazPxWHlOkhPCFHOugmT9OyCmMVih fnPV+GrskMF+ZH/b7atQyD4t82iwZ0C3w8QDZZMTouYEub+pvAQR7nbSQ9SsfA2NY2AE 9RiWliHInM0oz1drp7lQnTGoEPDqHy6nvN33EDjt4W72xlDwlfpfnyagh9+U7axEYPqF Zi3SLUi8xvuppAZLqQEpu5hCtrWweQCMJeC4z8TfSXp2YgEDog8Ux6Jp+alZz4131cJQ g7aB5ZaT50IfjsopDIuZGs15NfdrSKQyDhuEZte+jsAXeh2gtkutmJXe9mFxygwPkMxY knZg== X-Forwarded-Encrypted: i=1; AJvYcCUdBlyq+bwbTqIgTK9ks2WATvOdXuOBBgsDQRRWxHJMqvp6a8mPL6vK9sDw41eY94VqWzakJ+UGguY=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw5wK1Y55WW77xyeYg5g3ndrun2f5xfdxPXGPRs3QDUUlplrgs0 Y/hLxvWDHLUP2k0N9+mEyP6DVgocmUxWbnb4B9jdNaPvHAvFzdLlcsNtSfFDkWxyjA== X-Gm-Gg: AZuq6aJ1vmHy19s91nFJb5RMleXYpSNllFzuHAyfRsaHaXdNpXBYlKO16WhTcaDal3a uGL4vA7HNBogY0GhApJqX486sk+SgTJ+wVPYcfDjyxJX5pJZwul57HDoc9wRymZEre+bQGT+fGI xzQ5JfqnmW5i2nJ5fg63Vizm+CijWiWtA/k2SUEjOVlznxAsVPdHwB63Mciu01vbNdi5MIyZwX2 HgboCQbkafj4jdp/JW+m178BDSyZQDjUHJ3A33QiVpoiyLNNk94V9WFtX5Gu6i9/DEt2avDHxOv cWMaylGyA3Mbr2g6hQmUkL3sOgHw9rw5ENbKL4rXtnem2cUQouaYAZR3vOo6D1uVqr67Nofb3ET 552DcmHTHl7O1L+8hslyOzeJQkXy3kHTMGKsu6N/IC4cJ+kGAzd/CXrX9b1zLVtQAd3tmp0BLML 3e4J4HnK6RTB5OYc5Yc9m/reKWvyha+3Ew0c6pa8FGfvIkA9Ce2WG9Q5v6ZCr+wR3ljEwgVzcq7 Vw= X-Received: by 2002:a5d:5d86:0:b0:432:c03e:a78e with SMTP id ffacd0b85a97d-435ea220d54mr2822786f8f.27.1769673187495; Wed, 28 Jan 2026 23:53:07 -0800 (PST) Message-ID: <9d3d4a0f-5ff0-4a90-b624-fc99b23efbf7@suse.com> Date: Thu, 29 Jan 2026 08:53:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/3] xen/mm: allow deferred scrub of physmap populate allocated pages To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260128120339.47373-1-roger.pau@citrix.com> <20260128120339.47373-3-roger.pau@citrix.com> <6d7b74b6-1bab-427d-aa14-321f4761d9a0@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 28.01.2026 20:06, Roger Pau Monné wrote: > On Wed, Jan 28, 2026 at 03:46:04PM +0100, Jan Beulich wrote: >> On 28.01.2026 13:03, Roger Pau Monne wrote: >>> @@ -275,7 +339,18 @@ static void populate_physmap(struct memop_args *a) >>> } >>> else >>> { >>> - page = alloc_domheap_pages(d, a->extent_order, a->memflags); >>> + unsigned int scrub_start = 0; >>> + nodeid_t node = >>> + (a->memflags & MEMF_exact_node) ? MEMF_get_node(a->memflags) >>> + : NUMA_NO_NODE; >>> + >>> + page = get_stashed_allocation(d, a->extent_order, node, >>> + &scrub_start); >>> + >>> + if ( !page ) >>> + page = alloc_domheap_pages(d, a->extent_order, >>> + a->memflags | (d->creation_finished ? 0 >>> + : MEMF_no_scrub)); >> >> I fear there's a more basic issue here that so far we didn't pay attention to: >> alloc_domheap_pages() is what invokes assign_page(), which in turn resets >> ->count_info for each of the pages. This reset includes setting PGC_allocated, >> which ... >> >>> @@ -286,6 +361,30 @@ static void populate_physmap(struct memop_args *a) >>> goto out; >>> } >>> >>> + if ( !d->creation_finished ) >>> + { >>> + unsigned int dirty_cnt = 0; >>> + >>> + /* Check if there's anything to scrub. */ >>> + for ( j = scrub_start; j < (1U << a->extent_order); j++ ) >>> + { >>> + if ( !test_and_clear_bit(_PGC_need_scrub, >>> + &page[j].count_info) ) >>> + continue; >> >> ... means we will now scrub every page in the block, not just those which weren't >> scrubbed yet, and we end up clearing PGC_allocated. All because of PGC_need_scrub >> aliasing PGC_allocated. I wonder how this didn't end up screwing any testing you >> surely will have done. Or maybe I'm completely off here? > > Thanks for spotting this! No, I didn't see any issues. I don't see > any check for PGC_allocated in free_domheap_pages(), which could > explain the lack of failures? Maybe. PGC_allocated consumes a page ref, so I would have expected accounting issues. > I will have to allocate with MEMF_no_owner and then do the > assign_pages() call from populate_physmap() after the scrubbing is > done. Maybe that would work. Memory allocated using MEMF_no_owner > still consumes the claim pool if a domain parameter is passed to > alloc_heap_pages(). Technically this looks like it might work, but it's feeling as if this was getting increasingly fragile. I'm also not quite sure whether MEMF_no_owner allocations should consume claimed pages. Imo there are arguments both in favor and against such behavior. We may want to explore the alternative of un-aliasing the two PGC_*. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 29 08:15:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 08:15:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216137.1526094 (Exim 4.92) (envelope-from ) id 1vlNBj-0001Ca-3X; Thu, 29 Jan 2026 08:15:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216137.1526094; Thu, 29 Jan 2026 08:15:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlNBj-0001CT-0w; Thu, 29 Jan 2026 08:15:39 +0000 Received: by outflank-mailman (input) for mailman id 1216137; Thu, 29 Jan 2026 08:15:37 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlNBh-0001CN-Jj for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 08:15:37 +0000 Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [2a00:1450:4864:20::443]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id af350f41-fcea-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 09:15:34 +0100 (CET) Received: by mail-wr1-x443.google.com with SMTP id ffacd0b85a97d-432d2c7dd52so571329f8f.2 for ; Thu, 29 Jan 2026 00:15:34 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e131ce70sm13016105f8f.27.2026.01.29.00.15.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 00:15:32 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: af350f41-fcea-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769674533; x=1770279333; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=g7n14DybuDZFk1lYIVthCzYJ147OpqhxxgWowMwjFnc=; b=QA2XBTYPCR4V9xGyfV4pXZK7ABQ/ynjjCdwkbqSsz3dCPz2JyFmaVI7RTJnf+fhxsm P+xwoXsapFXhM5NipJMpbruOqOnCoS8B6aVRpa6+srYI1i2B2IJKm9AKTfqge4n5qFTX 5IakEwL4hJ8hUIywZd4rdirw12E7hIkBwqnuuq3/FnuhUT7IwNHqtjnADwpN8J6YucG7 5U5ezh4wCv9qboVRW+vF9eaLlMBY9eC8IOti1Cu+uz1S+exzPKQy248lCPAHTCb9axLb Ftmjy0KxVbsX70Mb/VbgXm/ai8mtMMfWN1pWSUeU1vRnvrMG+dkBYCwLixW1knrC3lPK ym2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769674533; x=1770279333; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=g7n14DybuDZFk1lYIVthCzYJ147OpqhxxgWowMwjFnc=; b=aOkbzqn3iHQCMB9PnU+yRyF/Kgbi2M46bhi133d/3uUEOluV+2idbt50nAVxrBZwL0 X5QTwJrdgZTYi8vc0IyqGw5mfOZSxR4vH0s6fJd7k155Nq5a6FNY48iGzeuAjSqzUgGY ERUmHANUq54sUeQdr2DqCkpckvFIcd1JzTjV6YnlYvMbmTPWsWhEs/+48C1EYFJdt5Ay toeQcw1ZALk3BQG+FBIr3wdjr6/OjHi896B8ICr386fRzcsUYfxZPcdJlbdmmm98bTUl C9+VzprV7pUGjNhYF/rycJgKPpMhU6OZoOFNvGR5hg3Ak/sXj0LWtLMLoZdYsFJ7gyJf nFwQ== X-Gm-Message-State: AOJu0Yyzaz0HX1O6Er3+SLmVhv2cKnPxC/mgQ7uruCvs/Uw1A/hkpbmE Kv5BLARpK4xViUaAVKre4m6nH+/xGHzMCk9cR4y1l7ObnapQ90Ou/0RTvmIEnkgu8g== X-Gm-Gg: AZuq6aIfmzkRZxb0SaLDvWsvug4rRZKklNB2V4GP4LyLXcFhQP92yowK2VK2Joewx03 8S/3EbLJOKaXeAF9AE/0DEyvN9HVS1H/QfQyEWaNdP5FXwKB8lB7PmME1Quw6cHjIV+zUhXPjy/ 7ez9+peK8sXRcRrecruknqLWGQ1XYeyNw5N5QbCAdF3WKTduC5ADLE6gjmDJUqlzQ+arF+VOZso 73kqy3ZinBTokUW2KiFuUsJnTDQek9IHrJVSIib21V3MAXi8WTGjvqq+uZpZqprIjRoab+xdlUn hBogOlKXQwJ5G6AOqiQCi+OPDrrQVLtIn8vDxE1wxagsBQTP6IObcmff9JtWiDd9VbKjn7PUyvB ETClcq7pvqLL+xZFswNXkGPnNTeQOyR949DBC9OQP2GKFarv95wAHrWJKy3dhxGw1R27l6PBooh uCj5MXdkygINZdeHmtQh0dIPvq+s5cZVMRuLvLKufhll6hshOqofr/729L8l0vMc3LyLcn5TFZj +8= X-Received: by 2002:a05:6000:2906:b0:430:feb3:f5ae with SMTP id ffacd0b85a97d-435dd1d8c28mr10494543f8f.55.1769674533167; Thu, 29 Jan 2026 00:15:33 -0800 (PST) Message-ID: <2d5e017f-1675-4753-9494-2b664c4ca7fa@suse.com> Date: Thu, 29 Jan 2026 09:15:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/4] PCI: determine whether a device has extended config space 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 , Stewart Hildebrand References: <58091dc1-7bda-4536-8200-2d0a5679d4d1@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 28.01.2026 18:49, Roger Pau Monné wrote: > On Mon, Jan 19, 2026 at 03:46:55PM +0100, Jan Beulich wrote: >> Legacy PCI devices don't have any extended config space. Reading any part >> thereof may return all ones or other arbitrary data, e.g. in some cases >> base config space contents repeatedly. >> >> Logic follows Linux 6.19-rc's pci_cfg_space_size(), albeit leveraging our >> determination of device type; in particular some comments are taken >> verbatim from there. >> >> Signed-off-by: Jan Beulich >> --- >> Should we skip re-evaluation when pci_mmcfg_arch_enable() takes its early >> exit path? > > Possibly - we expect no change in that case. However it would need > to propagate some extra information into the callers. I could see > that as a followup optimization. Okay, with Stewart also saying so I'll make this a follow-on then. >> Note that no vPCI adjustments are done here, but they're going to be >> needed: Whatever requires extended capabilities will need re- >> evaluating / newly establishing / tearing down in case an invocation of >> PHYSDEVOP_pci_mmcfg_reserved alters global state. > > Hm, you probably want to do something similar to re-scanning the > capability list, but avoid tearing down and re-setting the vPCI header > logic to prevent unneeded p2m manipulations. We have no easy way to > preempt this rescanning from the context of a > PHYSDEVOP_pci_mmcfg_reserved call. Yes, definitely only re-evaluation of extended capabilities. Note, however, that once we expose more of them, there might be a knock-on effects on the P2M. >> Linux also has CONFIG_PCI_QUIRKS, allowing to compile out the slightly >> risky code (as reads may in principle have side effects). Should we gain >> such, too? > > I would be fine with just a command line to disable the newly added > behavior in case it causes issues. Can do. Will need to get creative as to the name of such an option. >> --- a/xen/arch/x86/physdev.c >> +++ b/xen/arch/x86/physdev.c >> @@ -22,6 +22,8 @@ int physdev_map_pirq(struct domain *d, i >> struct msi_info *msi); >> int physdev_unmap_pirq(struct domain *d, int pirq); >> >> +int cf_check physdev_check_pci_extcfg(struct pci_dev *pdev, void *arg); > > I'm not sure why you need the forward declaration here, the function > (in this patch) is just used after it's already defined. Well, this is needed for the same reason that the two decls just above are: The file is also used for the COMPAT variant of the hypercall, and hence the declaration needs to be visible there, while ... >> @@ -160,6 +162,17 @@ int physdev_unmap_pirq(struct domain *d, >> >> return ret; >> } >> + >> +int cf_check physdev_check_pci_extcfg(struct pci_dev *pdev, void *arg) > > You can make this static I think? ... the definition doesn't need building a 2nd time (which hence also can't be static). >> @@ -718,6 +721,11 @@ int pci_add_device(u16 seg, u8 bus, u8 d >> >> list_add(&pdev->vf_list, &pf_pdev->vf_list); >> } >> + >> + if ( !pdev->ext_cfg ) >> + printk(XENLOG_WARNING >> + "%pp: VF without extended config space?\n", >> + &pdev->sbdf); > > You possibly also want to check that the PF (pf_pdev in this context I > think) also has ext_cfg == true. I don't think so. No extended config space on a PF means no PF in that sense in the first place, for then there not being any SR-IOV capability. >> @@ -1041,6 +1049,75 @@ enum pdev_type pdev_type(u16 seg, u8 bus >> return pos ? DEV_TYPE_PCIe_ENDPOINT : DEV_TYPE_PCI; >> } >> >> +void pci_check_extcfg(struct pci_dev *pdev) >> +{ >> + unsigned int pos, sig; >> + >> + pdev->ext_cfg = false; > > I think I would prefer if the ext_cfg field is only modified once Xen > know the correct value to put there. Well, my main point of doing it this way is that the code ends up being a little easier to follow. Especially without the optimization talked about near the top, there inevitably will be a window in time where what the field says is wrong. With the optimization there'll be two main cases: - MCFG becoming newly available: The field starts out false in this case, i.e. the write above is a no-op. - MCFG disappearing (largely hypothetical, I think): The field may start out true in this case, but will go false unless we have another access mechanism for extended config space. It then can as well be set to false as early as possible. > It would also be nice to detect > cases where the device has pdev->ext_cfg == true but a new scan makes > it switch to false. Which would signal something has likely gone very > wrong, and we should print a warning. Why "very wrong"? If Dom0 tells us that MCFG shouldn't be used, there's nothing "very wrong" with that. It's simply what firmware / ACPI are telling us. >> + /* >> + * PCI Express to PCI/PCI-X Bridge Specification, rev 1.0, 4.1.4 says that >> + * when forwarding a type1 configuration request the bridge must check >> + * that the extended register address field is zero. The bridge is not >> + * permitted to forward the transactions and must handle it as an >> + * Unsupported Request. Some bridges do not follow this rule and simply >> + * drop the extended register bits, resulting in the standard config space >> + * being aliased, every 256 bytes across the entire configuration space. >> + * Test for this condition by comparing the first dword of each potential >> + * alias to the vendor/device ID. >> + * Known offenders: >> + * ASM1083/1085 PCIe-to-PCI Reversible Bridge (1b21:1080, rev 01 & 03) >> + * AMD/ATI SBx00 PCI to PCI Bridge (1002:4384, rev 40) >> + */ >> + sig = pci_conf_read32(pdev->sbdf, PCI_VENDOR_ID); >> + for ( pos = PCI_CFG_SPACE_SIZE; >> + pos < PCI_CFG_SPACE_EXP_SIZE; pos += PCI_CFG_SPACE_SIZE ) >> + if ( pci_conf_read32(pdev->sbdf, pos) != sig ) >> + break; >> + >> + if ( pos >= PCI_CFG_SPACE_EXP_SIZE ) >> + { >> + printk(XENLOG_WARNING "%pp: extended config space aliases base one\n", >> + &pdev->sbdf); > > Hm, I think this shouldn't be very common as it seems limited to a > short list of bridges. However every device under such bridge would > be affected and repeatedly print the message. I wonder whether we > should make this XENLOG_DEBUG instead, there isn't much the user can > do to fix it. More a rant than a request though. XENLOG_DEBUG feels too weak for indicating a potential problem with a device. I also don't see us marking bridges to limit the verbosity here, as the issue may or may not be due to a bridge in between. Imo we can defer thinking about limiting verbosity here until we see reports of this actually getting overly verbose. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 29 08:25:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 08:25:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216152.1526104 (Exim 4.92) (envelope-from ) id 1vlNKj-0002wV-U1; Thu, 29 Jan 2026 08:24:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216152.1526104; Thu, 29 Jan 2026 08:24:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlNKj-0002wO-RN; Thu, 29 Jan 2026 08:24:57 +0000 Received: by outflank-mailman (input) for mailman id 1216152; Thu, 29 Jan 2026 08:24: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 1vlNKj-0002vn-B4 for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 08:24:57 +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 fe5d614a-fceb-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 09:24:56 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-430f3ef2d37so568093f8f.3 for ; Thu, 29 Jan 2026 00:24:56 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e132303fsm12584702f8f.36.2026.01.29.00.24.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 00:24:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fe5d614a-fceb-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769675096; x=1770279896; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=s4DyzCok7BdHy5pEqU9S+8pEdv71c6muAcIG7r8DN4U=; b=Mi+G4KIoEdcX1n+yFFezdBNVhH6kDSr1cliizq1ukxLnfrGEElJ+4Mm3jZjD+v4dtk 3b/RnAk0ZtTJz2VotM4uabEfq6rGk5whGLrL6kzQzoJhhwiCz+dw8Ak36QKyI6bXs44e WUfSWwO9MKCnyvzAwJo5P8Y3TP3u2aTNK/pps+WX+4CKh87rXGun2NFPlmFiP3R3B04z 5LXrPOUNob48eVOXcHPnLSMk4vfW6thnvY3z8b8ISFeZJbf9kCOVuj7X0Ku8s/9DdMUe ApyNZ7uWbCPRSpggR3qa7NnV+A1BJXaNhEtc9XsjjBdUSLn9zKqWiJa7yz6vseHTNsnU qfAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769675096; x=1770279896; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=s4DyzCok7BdHy5pEqU9S+8pEdv71c6muAcIG7r8DN4U=; b=oRMowSRni0lVMoHfEzM60ckrA6zahznQXdn7hm/Ocw+LENtRuvZRkrtF0Y9BWW1LS0 tnBE9STVx3w4RMAKw/+7JEmoIp1cvPaMY5eT5YCTVUIJQ1d9owTEM6kuySgy2zCw1uV5 NhFOOf1eUsn+o7lasoNTWtBRgJ8K4tR1cxDXQpExb0G8M45ekiM1NZ9aiz9T9AVbRvNf Vs5S8bfgsGutL95+RgOVZ+zdwBZGnqOq9S336IHrKedS541839q9ldI7evfdZqLTUa/2 Kun/bM/MGPn1U89SW6Z33A9Qprimuz0sR4krj0JploufWvHW301N8FBom5s620Y/6KIE vYOg== X-Forwarded-Encrypted: i=1; AJvYcCXHmJXDEOlYP7wNRJn2JyIiDf6YA1wPKlivXx8IGK4UhQ4zdpq4P43Em802CI19PZVgAEmm29cCHuY=@lists.xenproject.org X-Gm-Message-State: AOJu0YwGs8DcYbPiDLfdg9i6ru7fZB/YjDJb4GBH7bO/wJPtFNsvv5iI AhC/KolHF/BFJqLUnQuUWIfE512KeJ8CJywWdndbvEmXQKPF/2WPAqHr9J+cFC5c1Q== X-Gm-Gg: AZuq6aLcsPWgiOIcUWTC2ccXOFTMqW6px8MPeVCse3/q5mdd7WuA6YIA38Q0x1LCgJA 090zfwh15Z3BnelM6gQsbFPuiddNioUwDCY/OQ7Fr+8JO7wbjTfht8GL+LjXjEU9/tq+JQV9QgJ FXteC5u1LovCKIreVHZllK4fD+OAbzhyS1krYv2CnzidwkQRTqYWyTSiIYy5yrIsam0DZPzx5u/ 9l/RhkHQeiZ2SjLHWgzo9lMWZrmmSe+T8sM//LWjHFPFw/6Q+87rcnp3ug8DLNwn0R/mkR/hxSj 66gA0HuLt/2C7kRV6Ov7O6VQj4uCO1dfEypq7EHyj+2lplDaN/T8Ms6+akQupP1RJMPH/bL0J5E q2rWjh2ce6JcjX8TPSxFMfwntFD3v/+Q3b+w8lOqkIPc7HN+LeZ/YCYRbwKov7tKt9gjeH9194t FQ2ypf2Glhwa2Vp26RmtO6/iDzefSps+KWjrUWUfAfZ3Ov6TEaPsQQDeq+rNuhaNYorwvU39BzN iY= X-Received: by 2002:a05:6000:184e:b0:431:907:f324 with SMTP id ffacd0b85a97d-435dd1da001mr10835018f8f.61.1769675095883; Thu, 29 Jan 2026 00:24:55 -0800 (PST) Message-ID: <2044f927-6d9f-4c7f-9e47-6e4c6dbb2fcd@suse.com> Date: Thu, 29 Jan 2026 09:24:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 1/2] xen/console: handle multiple domains using console_io hypercalls To: Stefano Stabellini Cc: Stefano Stabellini , grygorii_strashko@epam.com, anthony.perard@vates.tech, michal.orzel@amd.com, julien@xen.org, roger.pau@citrix.com, jason.andryuk@amd.com, victorm.lira@amd.com, andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org, Daniel Smith References: <20260123010640.1194863-1-stefano.stabellini@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.01.2026 03:42, Stefano Stabellini wrote: > On Wed, 28 Jan 2026, Jan Beulich wrote: >> On 23.01.2026 02:06, Stefano Stabellini wrote: >>> @@ -742,17 +758,36 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, >>> if ( copy_from_guest(kbuf, buffer, kcount) ) >>> return -EFAULT; >>> >>> - if ( is_hardware_domain(cd) ) >>> + /* >>> + * Take both cons->lock and console_lock: >>> + * - cons->lock protects cons->buf and cons->idx >>> + * - console_lock protects console_send and is_focus_domain >>> + * checks >>> + * >>> + * The order must be respected. guest_printk takes the >>> + * console_lock so it is important that cons->lock is taken >>> + * first. >>> + */ >>> + spin_lock(&cons->lock); >>> + nrspin_lock_irq(&console_lock); >>> + if ( is_focus_domain(cd) ) >> >> Why would any of the domains possibly being permitted to be "focus" suddenly >> gain direct access here? Full access in do_console_io() is still prevented by >> the XSM check there, afaict. Cc-ing Daniel, as it's not quite clear to me >> whether to introduce another XSM check here, whether to check ->is_console >> directly, or yet something else. > > The XSM check still happens first in do_console_io() via > xsm_console_io(XSM_OTHER, current->domain, cmd), which validates that > the domain has permission to use console_io hypercalls. The focus check > is an additional restriction that only allows reading when the domain > has focus: it doesn't grant new permissions. Dom0less domains with > input_allowed = true are already permitted by XSM policy to use > console_io; Are they? I don't see any XSM or Flask code checking that flag. What the dummy xsm_console_io() checks is ->is_console. However, what indeed I didn't pay attention to when writing the original comment is that guest_console_write() has only a single caller, do_console_io(). So there's no concern in this regard here as long as no new caller appears. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 29 08:37:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 08:37:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216160.1526115 (Exim 4.92) (envelope-from ) id 1vlNWg-0004fo-Tp; Thu, 29 Jan 2026 08:37:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216160.1526115; Thu, 29 Jan 2026 08: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 1vlNWg-0004fh-R5; Thu, 29 Jan 2026 08:37:18 +0000 Received: by outflank-mailman (input) for mailman id 1216160; Thu, 29 Jan 2026 08: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 1vlNWf-0004fb-Ey for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 08:37:17 +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 af80f317-fced-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 09:37:03 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-4805ef35864so5201465e9.0 for ; Thu, 29 Jan 2026 00:37:03 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c40e04sm180192905e9.13.2026.01.29.00.37.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 00:37:02 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: af80f317-fced-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769675822; x=1770280622; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=3Rdxq4eZQ3TL4NfBjYo2hXdXYnnWKoWGHKhH4Ncw/3g=; b=Auc3KWnQ5VbBEF48in2em5mEt5Nv23+vJETKniqmCwEUSskhBRbotimnUyXis6RZvy +dHPCDhHoWm+eHWxExOt0kff+jb06b7CTrw01HYCdefCmIas+QfqTJAnDJT7rC/cP9mU gzq6DLaqMx2FPveuTC/eN9Hqc2/rbUox3t7HMTxI8QJulmosiYemxQnW5rmaAnu3IWYg D7A2nea2a/x/h8MbK0V2dJ85oQ/rFd8JZFSBplCWQZYwJBM0VCUPbZNqyms1XzCOhrJp lDKsXbYUwqP2P6U7hAmYepuFPs3X+QztIaD/aQguIsNY0JoiT616xvhDDD2A5sE1WtAU aSHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769675822; x=1770280622; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3Rdxq4eZQ3TL4NfBjYo2hXdXYnnWKoWGHKhH4Ncw/3g=; b=ZJb9nVrxq89Gg9AKrzHg53R2Lxq3yCXtWoFbFhNQPiEmDOB+NDv5BBOwuA1IM7/NNC EL6vBZAV4oly2tlJs9iMOq2x2nBoVkwl//U2tIStI0NsE5VAnEmx5IgJOQeBBfD2o/iR +qlxxGMmLFxvJqpN/kY2KS3Xmh39Msbb077nP1Q9XWfbdli+RIA5dATYExVicam9cbXd W1WL9D49N6rVxfSai/XjOOl1tUHINbtsQyBne9C1so/WNW1n3dwusj5eDaqGJpGlPXbB zycLWY14qIFkJo/wvYN5yuOre1zP2LQPzN9Da0ypiHlzmk0tMZR8mdRL47DsNUCW+Nfc IchA== X-Forwarded-Encrypted: i=1; AJvYcCULMSKYXWg2u9uE1c5lnHT3zBfENSV/0zObWUwoukJrw9HH0qE751+ge6mGWNAQjBwSqLdpUXUCv+U=@lists.xenproject.org X-Gm-Message-State: AOJu0YzBjPhVIL1QnpQrAijYAWDlW8Qyg0fSPmG2uBPdtEk3LD3QxDOj 31/xiZiawEhmsu2OstCP5ur50a2Od2Gi26ucO+8Ku9VMncioCHBONzkVY3rlA8RO5g== X-Gm-Gg: AZuq6aJkqKF4uniZQRTx2HXFULjJKqrU9Li11U8raDSjuXlzAyZMQ3ee0k8wPfiChWn 8R/pFagXz5hKvFEGuTeo93Jwj38+gviSju4Wjaye0HSHXxK4ine3fsW8fxg7/iGJAkbjclqb4GG Geb7FAwzBS5xDHLBPrcHlfuoBUvmTnqi2/hMRxuYeIfCa+9tIKQptUfBYaRGBFJGDRIP0qhUZKD Qh9wD8uGAA/VGeP1kC+LynW2X1r/r31k6oUKJIUNCuMQXZ3sgGG7LDI2en771Ezd9F9mTVrpPHM +jiPUI93PXpfV6Vb+lH27wz0uhcFCCSVPWVBwkfbTy0YMdzeyO3SwC2Zifo1LDkpGdhMI67J3D5 loGtsUWUaFO192aJWCgslflZ2G5B/W2qHtltrntz3GMntj/KSD8/8LJ0ci3U4W1vzAnXgIa2SZQ HW2sX/4XVoSc8nlifwpFPJg0e70CLXKikExDEBoeFeXLwdYyPi3XMKXDZhNW7c3lk3GbpNA5ZDE Yw= X-Received: by 2002:a05:600c:8b2b:b0:479:3a86:dc1e with SMTP id 5b1f17b1804b1-48069c73ce1mr99344375e9.36.1769675822480; Thu, 29 Jan 2026 00:37:02 -0800 (PST) Message-ID: <72d36ddb-22c7-4b32-af8a-f4920b75ca7c@suse.com> Date: Thu, 29 Jan 2026 09:36:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 2/2] xen: enable dom0less guests to use console_io hypercalls To: Stefano Stabellini Cc: Stefano Stabellini , grygorii_strashko@epam.com, anthony.perard@vates.tech, michal.orzel@amd.com, julien@xen.org, roger.pau@citrix.com, jason.andryuk@amd.com, victorm.lira@amd.com, andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org References: <20260123010640.1194863-2-stefano.stabellini@amd.com> <91c71a0c-4345-4fae-912b-ae7c9d2160e7@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 29.01.2026 03:46, Stefano Stabellini wrote: > On Wed, 28 Jan 2026, Stefano Stabellini wrote: >> On Wed, 28 Jan 2026, Jan Beulich wrote: >>>> --- a/xen/drivers/char/console.c >>>> +++ b/xen/drivers/char/console.c >>>> @@ -612,10 +612,18 @@ static void __serial_rx(char c) >>>> if ( !d ) >>>> return; >>>> >>>> - if ( is_hardware_domain(d) ) >>> >>> This check is fully lost; shouldn't it be replaced by ... >>> >>>> +#ifdef CONFIG_SBSA_VUART_CONSOLE >>>> + /* Prioritize vpl011 if enabled for this domain */ >>>> + if ( d->arch.vpl011.base_addr ) >>>> + { >>>> + /* Deliver input to the emulated UART. */ >>>> + rc = vpl011_rx_char_xen(d, c); >>>> + } >>>> + else >>>> +#endif >>> >>> ... >>> >>> if ( d->input_allowed ) >>> >>> the latest here (not sure about the vpl011 intentions in this regard)? >> >> No because vuart has already input_allowed > > Sorry, let me rephrase this. You are right we need a d->input_allowed > check. The check is already done as part of > > d = console_get_domain(); > if ( !d ) > return; Can this be said explicitly in the description then? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 29 08:43:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 08:43:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216174.1526125 (Exim 4.92) (envelope-from ) id 1vlNcO-0006Oi-LA; Thu, 29 Jan 2026 08:43:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216174.1526125; Thu, 29 Jan 2026 08: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 1vlNcO-0006Ob-I4; Thu, 29 Jan 2026 08:43:12 +0000 Received: by outflank-mailman (input) for mailman id 1216174; Thu, 29 Jan 2026 08: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 1vlNcN-0006OT-NG for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 08:43:11 +0000 Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [2001:4860:4864:20::32]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8989087b-fcee-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 09:43:09 +0100 (CET) Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-40946982a78so235558fac.2 for ; Thu, 29 Jan 2026 00:43:09 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8989087b-fcee-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; t=1769676188; cv=none; d=google.com; s=arc-20240605; b=cMFWoXrJDS2CNwp5EA5kNkdJNekApYbJTTmoB82t39F9RJizM3s8LHBGOnEgM4NQqD 7iGf1AucKCwm41UJYwtBJcV6xNxka9pXvywEwROAp5sLvMUjddWvhi9Z0L0zpNaL6hnU iYW0zhSUlqOoSMrnBG+pupPsbHDdJWgWXgIKySh+8yuX8fgw3V4fXew+/YZr8Pxc6nmc in99g8fVf3B2p8cXFqrNpVti+rajIfv5G0v5u0zaDUEYLEQA7dp0wfHu38lCavyoiT03 SjrCW9Ss8mz/Rea0W0OCIGFqaTKEl0JavcAgegTnSdSh/M/CX8V7BlAOT1Ip9MIOmEPW 6EIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=M3uWjpmWviHmnFZdjM+gTchFY+hZt8MHu2e3DILA69I=; fh=/PvZ6BBwHiTCZtYFNv4HT6ydfeS0G1NxgPsIWUuewIw=; b=XAB/fQzdS0n9CRg42PmtAQpc10KIqscsSez0vw8UYizvg90OW/bJKLI/MwpFsSMIba yv3IM1HMbKDbJ0ot+EPFXqL/jgWcgOmHL92x1es/BTVUMco2Mo2/srHSoztm+oHr6vJ7 tTj4YaQO8UgSSe1dS0GejFkxy50ExG3dPvEBAHQdJrjaoJWslaODZthOgTS/NBirvgIh NdLs0dK7MSM2i5DlgSP3uRNqcf0ODn0YBDn/QHhP6W01x4I5GGeEOyoqcqclCfWrFIJ/ B4MqrMIEBq484HY+WrElETtu/hsHs4QCLcVY9YI0WsIXBqYZ0RPp9aPpjfh1/sQHChwA 83Wg==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1769676188; x=1770280988; 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=M3uWjpmWviHmnFZdjM+gTchFY+hZt8MHu2e3DILA69I=; b=gR77DwUcPRIR7M6JfBqc1ep8OvqDPXq9qOZmCfLPx5kS6dR2X5G3xlcU88431OnuJL r+KOkdWNyBdQ1laBVFshPxdMfwrPWNI5UBPShOsYP86t/x4Ym4Hy/K3PaVoMIMk1yd3b 6Ptwlm4dZ5y5fIGJAJoHsYOmQ9XgjAicUNtEv3wF2sgujn39at3T/JyJ3bm5F4Yon2Zg QTkgJlXApWqS01zU68eTXB4TJt0F7euNKnXLerv3TExkeUVaL0KK9MKu6gFqoZyOgRtv fqchD30zA/LOW5WgSmdLajHZSNHBghWxmUxWx7gv1dmDIey6++hsOVjqaDha0FOH+W8c sRMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769676188; x=1770280988; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=M3uWjpmWviHmnFZdjM+gTchFY+hZt8MHu2e3DILA69I=; b=EA8lf2Tgci1dS79KgRFJjl7QHW1C/r8CNqMc3tkYyXWcrT/sidPMncFtJuU8Y4nV7a PxJ0dypRZFNTR/aK+TAVkvr0FJQ9myf0sXGpjv0/glF7XDP8sPoQLY8sMbBF9HKua5UP JgShKngDEig6oBVgSJEs9XP7xBTfHx76bK5jF+IlFIMCkGmEOQJIN9YdRaxBLXSqB3Xg DWKioOkMh1zOBZFFsq2vE/L7JBd7ZWUp77BChQgkUCV8N/yVcZJuuOqVpalVI0iZdk0h n9YhgNzlZkC7LTROv0x3a6wdxeswv8jYeXxdp5WfqPEwd3/qR3tGiLPhbWmddvH08gZ8 Hj8w== X-Forwarded-Encrypted: i=1; AJvYcCUSdrSiQBWM9Mm8HqNDqq++HjNRF4ZNLWd0jmdu1mHa5sOa69Zd985oFOpcYdPDKKfxpOyWSFwo3ps=@lists.xenproject.org X-Gm-Message-State: AOJu0Yyh6eeRDIUJ4svut341DZ1K2vF94IYowdne+3HXYxdZg5BfaLIs a5zIEMiV+GhIG9zmAhY1NoXksk8FOtff27E49jDAIAS9DSb/jwFBHMOreSVeQwxdDcp/pyF3xIH fViz7ueH2d9A3KTp9dT1GPfNpdWLz9v9AbHTpJRnG6A== X-Gm-Gg: AZuq6aLF9D4lV0NF9+wck4iv2bx8ZsbST2H6unDQvy9FG0Qoe2u/bRGX/UVN9kwb+Wj A5zkuOZGqilhD1FSFJLLdKwoJbIij7eNPMmmmBtGom4HdRW7GIVL38TyDPkNtYa7ZLdz/FG5A/F B9LjcbeP60wI1BHdCsyDPqnGP21dMGxsqPltKkNF01zCKylHJmtnRS0n+f8BgUVNBoe3UqXSGcO dAtbNEW1ixIsKK8KVzuroxN4dgKN4XAXKgDpXEheR6W8Ep1qPQrUbqE2WTlh1gzIBxWK3s6YIbX Twanx0LjZ6b606pCvTBLHKx2eQ== X-Received: by 2002:a4a:c81a:0:b0:662:f4cb:208f with SMTP id 006d021491bc7-662f4cb24c0mr3217225eaf.51.1769676188173; Thu, 29 Jan 2026 00:43:08 -0800 (PST) MIME-Version: 1.0 References: <2FA52A4C-98F2-4066-8BE7-36F37093FCD6@arm.com> In-Reply-To: From: Jens Wiklander Date: Thu, 29 Jan 2026 09:42:55 +0100 X-Gm-Features: AZwV_QgXaD-KsuWPs2CnkAc9JR6pzp7WDtV8M0FieG2beZ9mwGUx0w937rQVi60 Message-ID: Subject: Re: [PATCH v2 00/12] xen/arm: ffa: FF-A v1.2 support To: Bertrand Marquis Cc: Julien Grall , Michal Orzel , Volodymyr Babchuk , Stefano Stabellini , "xen-devel@lists.xenproject.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, On Thu, Jan 29, 2026 at 8:32=E2=80=AFAM Bertrand Marquis wrote: > > Hi Julien, > > > On 28 Jan 2026, at 22:50, Julien Grall wrote: > > > > Hi Bertrand, > > > > On 08/01/2026 07:59, Bertrand Marquis wrote: > >> Gentle ping: This serie has been fully reviewed by Jens and would need= a maintainer ack or review. > > > > As we discussed during the last Arm maintainer call, as you maintain TE= E with Volodymyr, you technically only need a reviewed-by from someone from= the community with suitable stature to review. > > > > I think in this case, you meet all the requirements with Jen's acked-by= . So I will commit the series as-is. > > Thanks a lot. > > Would it make sense to add Jens as reviewer for tee ? > He is involved and knowledgeable in both ffa and optee implementation. > > @Jens: Would you be ok with that ? Yes, that's OK. Cheers, Jens From xen-devel-bounces@lists.xenproject.org Thu Jan 29 08:49:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 08:49:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216187.1526134 (Exim 4.92) (envelope-from ) id 1vlNhv-00079k-70; Thu, 29 Jan 2026 08:48:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216187.1526134; Thu, 29 Jan 2026 08:48:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlNhv-00079d-4K; Thu, 29 Jan 2026 08:48:55 +0000 Received: by outflank-mailman (input) for mailman id 1216187; Thu, 29 Jan 2026 08:48: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 1vlNht-00079V-8Y for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 08:48: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 55b713f3-fcef-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 09:48:51 +0100 (CET) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-432d28870ddso437150f8f.3 for ; Thu, 29 Jan 2026 00:48:51 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e131cfd4sm12409640f8f.25.2026.01.29.00.48.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 00:48:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 55b713f3-fcef-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769676531; x=1770281331; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=PsDKW892hOb4OjgjJsW//dAdzjDmXoxVZn1OMzlSw14=; b=I4pDVCs8UFEWQfwPOTGcaDDj4fam+GvUet0b1c1A0D703OEprqHKMciKkQhALIIbtS 78Ci8QQN+QeSL9cx3NFcLjKAM6ivM3E247WQTR3M7ERHcaYtM6JWP+koKaAngAzE2ENF ezfLiojKiCAAtEy1zvXMAoLWPkewKHJz4xS+gOzBJhWfnGB4z37gwPK/u/yGibsE19Hg nw5sPwkbPty1TMW8OaEEZqpF2evPEufJNJ072IgAqTbzOmvKNspF54eQUyEjA2sCJ0IW 3YNQ4aIepAuEE/jiVERLP7XUPkNKCTBLl2wbGyte0vtB2AkYhnDdVlY+/S/HvYyuc2nt lrIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769676531; x=1770281331; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=PsDKW892hOb4OjgjJsW//dAdzjDmXoxVZn1OMzlSw14=; b=oPXEuJhGwDU1Ghk315ky23ULiIl09LrVNcHfauJXGQSkgeGJMOZGoejEqXg+1Scigh /kP0aTsJxDOnvqd8If4eV+vNctf/d7NXciJYqCnefvLqT1gtWWK7U75XiT+qCWtVeF6H mbum1Wvlnbfohv49N8XsolYj32gXOQcDcTrsLdZw2A15VxzXb7b/O5A7+ktU6hovMTpd 25DF0/VNXzx0pkdcKXlTKiTfkgFNYi/xZYTgubWYThk7huseBgicLRLt/VwZGDGud/4a nd7nwsYYnOPV3yNEAM3spdByeiGwtS7fUBp0BzFESwJrTldFQ4W/wwAGWJQ/u2rzOA3W wKwQ== X-Forwarded-Encrypted: i=1; AJvYcCW8ESr2WmT1qCIutm7QpTrnJsBu9w1jLK0UUHmFW+dZIVoofvWQ3JNNKTITDuPHiok+aZfQgq5BKlQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YzDDc0oMiO6VJdlmL1KDNgZXdKc94APVVBOKm/2zpN6D9fwTAoZ X2xoVOi7qaBhd2Agtvu72aiIIGLcVe9MmjUUL0nxoWQxx4S5u5D/fy79T9mWhgKSAw== X-Gm-Gg: AZuq6aLOYTMvlvPQ1EhU17zdgSdiCAzIMdDvqqG2Ht2GHdHurxl1S7MlnAkxc/4PV4g dmIORtZdF6yrco9IAo+GPyy2uJbxWyCnahw0iR7xRDyyOSMaRhZRgfWC/Z8WlfD5UdklwCzV0ec O+oI3xQhvDgTQ9iqCpMZKTXv0D5IhJBx8aybs93p+XCtdnRwEGK2LHgQPrrvL9HRTGZHnBrK2o0 Dq/eKjU4Wq3WgjxYMf+hKzjZlwiFia+JfWE6n0CINvFHmIT5K/kcPHwmneIUMQC8r+FOkW4tCNk ZCmqKmyZvb3m5LrPUhWxK7sH3oOXW3FLhMR/mztyDmC1rRz/Yyk9pPPGHInk+LcDm7feKCOLrzs 2rQ4JBIVBRfI2xMlTIse+RDvOq6rUcm22UfzfAho3fQZNioQXAo4Y/2kWE1Jd+Vz8qQF9PpnHPo hDGJiecO73CefARY/epEjPRmJhSbxDdAFhy29Bh/M44AOrCiy2hFIzNQFWXw9R1IzKKVB/JkdHp 6Y= X-Received: by 2002:a05:6000:2082:b0:435:729b:c390 with SMTP id ffacd0b85a97d-435dd0b2a61mr11383323f8f.47.1769676530878; Thu, 29 Jan 2026 00:48:50 -0800 (PST) Message-ID: <2ff79945-f972-49ae-b50a-a7bbff9d4aa9@suse.com> Date: Thu, 29 Jan 2026 09:48:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 06/16] xen/time: move ticks<->ns helpers to common code To: Oleksii Kurochko Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alistair Francis , Connor Davis , Romain Caritey , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 22.01.2026 17:47, Oleksii Kurochko wrote: > ticks_to_ns() and ns_to_ticks() are not architecture-specific, so provide a > common implementation that is more resilient to overflow than the historical > Arm version. This is not a practical issue for Arm, as the latest ARM ARM > that timer frequency should be fixed at 1 GHz and older platforms used much > lower rates, which is shy of 32-bit overflow. As the helpers are declared > as static inline, they should not affect x86, which does not use them. > > On Arm, these helpers were historically implemented as out-of-line functions > because the counter frequency was originally defined as static and unavailable > to headers [1]. Later changes [2] removed this restriction, but the helpers > remained unchanged. Now they can be implemented as static inline without any > issues. > > Centralising the helpers avoids duplication and removes subtle differences > between architectures while keeping the implementation simple. > > Drop redundant includes where already pulls it in. > > No functional change is intended. > > [1] ddee56dc2994 arm: driver for the generic timer for ARMv7 > [2] 096578b4e489 xen: move XEN_SYSCTL_physinfo, XEN_SYSCTL_numainfo and > XEN_SYSCTL_topologyinfo to common code > > Signed-off-by: Oleksii Kurochko > Suggested-by: Jan Beulich Nit: Flip the two (chronological order). Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Jan 29 08:53:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 08:53:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216198.1526145 (Exim 4.92) (envelope-from ) id 1vlNmJ-0000Ck-OB; Thu, 29 Jan 2026 08:53:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216198.1526145; Thu, 29 Jan 2026 08:53: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 1vlNmJ-0000Cd-KD; Thu, 29 Jan 2026 08:53:27 +0000 Received: by outflank-mailman (input) for mailman id 1216198; Thu, 29 Jan 2026 08:53: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 1vlNmI-0000CX-Bu for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 08:53:26 +0000 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170100009.outbound.protection.outlook.com [2a01:111:f403:c107::9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f7a3c5ce-fcef-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 09:53:24 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SJ0PR03MB5822.namprd03.prod.outlook.com (2603:10b6:a03:2ae::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.16; Thu, 29 Jan 2026 08:53:20 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.008; Thu, 29 Jan 2026 08:53:20 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f7a3c5ce-fcef-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MHkMccuimlrRAkH2WhJXaxkdnrhlo/pHh858Egor4S1UF+E61FTstuciqsxgODwZU3jFf1/wF6nM0NfK8QSwqn8B3owZWAfz2BaqDAsk3WBcLLukWoZJ9Iq/GXry530cswv55f2r0FFq8dHUGyPe8/RAG85cvIt4QLhrrdPAbLtFMkhMK0WMuZIf2BumECBXDqM0fOkzW1dU8QdEzc6SY4dmOfLWd3CSw7oVIT5x65pTDsBNIf9VZVjXabUpB83wHHePN5cbaRssbJ7meGU7GvKgvC7tgilAcM30YyqpqnXiqRZG2w1bn5gpmMQR+990uZbSwT13wCR5WuH6onAElw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VdArQUDMnd4BCxiGxc/1w0KBlr3WP/1p/ZdFMe0E4YY=; b=vdqh0mLiU3kGq1/7jjtdqKiKJSmIhGDsIEHNDttZCh87gsGjp4bbBbJ+oV5/DjMutYQxYTj3torfGw2Uovwu54ElO6CVVHnoaQ9vIIXTfzDonbHmHuJa8u8aHJXuM0ZggybCBO8n0geZ8lpRlYfJIrKXxTt7CUcPQmUSL6M+CyrBLKIp2Z7GM1lZb0Osa+O3nwmu0Cfd2KA0kE7isvh1gpW8P6KRJPjae/icqP7kTp+FbzaBuTKqzptonf4hh6CKPUgOMM9TsKqk2BAsSWcONXCx7bvyKq5Vtr9sIury8l+ye2Mptrz4EpGGdWfVBufu8g4kbLGv88lumP5urbYv2A== 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=VdArQUDMnd4BCxiGxc/1w0KBlr3WP/1p/ZdFMe0E4YY=; b=q2EDYHo53bCEjbP+/VKpYLiAFUZ7QPJ9jNJYSARyq6dZJmOfAqoeJosfKxpsJlOzHavoWy+uDz9FdAd35iNQaLJKDMENZqMcJyfUXmy/itx8HKlklQVrS7r9yT2Sv/2rBY54Gobe7vzsD3RTDcAekPm93gL4eXJUW3LHNZzI/zw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 29 Jan 2026 09:53:16 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , Stewart Hildebrand Subject: Re: [PATCH v2 3/4] PCI: don't look for ext-caps when there's no extended cfg space Message-ID: References: <58091dc1-7bda-4536-8200-2d0a5679d4d1@suse.com> <133c1cb0-bdb6-4c9a-bea8-c50f42ce58d7@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <133c1cb0-bdb6-4c9a-bea8-c50f42ce58d7@suse.com> X-ClientProxiedBy: MR1P264CA0120.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:50::12) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SJ0PR03MB5822:EE_ X-MS-Office365-Filtering-Correlation-Id: 6acaf9b1-aeb1-4df7-650d-08de5f13da41 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?YXFpSXVkMGg3ak8zbDJsOXE0RHpxQ1RJcmNOdzh2eGNuZndnSHVqVVRlaDUr?= =?utf-8?B?c1V6L1Q1V1pWNG1FeUZpQkxFTjRWbVBiMUZ3NGZtUGhySG9hUW9ySDRWZCsx?= =?utf-8?B?N2l4cDBtTElNbklPMExwcXZQOEtpUno5d2N0WGJlNis3U3l1VDhzT0cyeXBI?= =?utf-8?B?bzJTRHhSUU4vVDh0R25CY25hdVgzYmtmNStBUGFpQlFlZ1JPamVobTM4UWdz?= =?utf-8?B?bkZheVFEZEZYU2ljZkg1WHhkYThyWThYY2hpd1hHNE83b2Z2Wk5IbE1XTk5n?= =?utf-8?B?MTV3OGdXYi9TYlZPMDhQOTIvY1BWcjRzNWpHQVFJdHVCaGlCeXFjSWlJYnNW?= =?utf-8?B?cnVqT3AyTmtKdHRwZjIxZHJ0Q1NRV0tWQUhNTW9wT0hpSkRzVFA5MjZrQlZU?= =?utf-8?B?dkMwL3lBQXJNYmNkVjJEZndrZWxpWGlIbEZpeVRIWHhyV1JVM1g0ZjhOZHNX?= =?utf-8?B?bnNRaTNBSnkxSzNIVVpMMTU3Z0F1dC94T3UrdnRWWmpLUnRpVGpUMm85QzFL?= =?utf-8?B?dWFIbXkzeUZjRWpVY293NVVQY0VUUExYWnMwWHgzbU1FUGFBdmR1dXJhTUVn?= =?utf-8?B?L1NPdHl5dCsycU1LM1FBbkRlcFBzbjYvUnFuRnRNNkc3UEQrRE1KaG5zVFRT?= =?utf-8?B?L3ZydFFKNHFnSjRsQWJyZ0VpRjJSL3ErV1BwTks1WVZ2ZG4xYWJGTUg4bXpa?= =?utf-8?B?MlJVM3BIckRyUmZuZ2hLZERtMWFoa1JVQnAyTFJwQTNVUUg5Zktxb3B0eFk0?= =?utf-8?B?VVBvajVKam1HWVhOeFVVL0xXMEhuS0VXNnVwTkdqVFVrRWROQ2N1L0RGZFk5?= =?utf-8?B?UERHMlE2ZkY1ODRlWmppSjM0bDMrNGNpclUwZkdNVHdhVTFjMVoySXRlOGhr?= =?utf-8?B?WE11TmZsNnBUUlZJb1k5Uk9haHI2dzV1d1lJMHFPcWI4TFBDTnZXVDVjTXB4?= =?utf-8?B?bjkwdlkzKzg2bHc0MTB4c3VMWkZtR0M4UDRZWW54dGc1Z29udEJCQUJWRE1I?= =?utf-8?B?d2ZuUnRYaE4rZmx2YXdmWWxjV3NoK3Y5M3liVXBIM0RXNUswbC9lNXY3TVJz?= =?utf-8?B?bElnMFdZTkJ0dzNoWFdjM3NrbFJOaXROcTZxMTUyTllBT3B4UXBIczBxelFa?= =?utf-8?B?Z3g3dGtoYnVqNW5oc3hiM2lVMmlsa1FTZVQxWEFNNnhmNlF4M1ZlbkxMTVJ2?= =?utf-8?B?NHVLQk1UUkM1MnlSb1VIOFF1bUNZTmpPeHhmdmVsRWUxekl0VEt6U3d4VWUr?= =?utf-8?B?RDJ0Q1JySHRNU1YrNzhwZ0tvSGZNQWFwNHpRZDdmTk10eUMvZjByWEFiQThu?= =?utf-8?B?Z3ZlUnNJQlFqVm1EZ2xvLzMzdTBQZjF2RU5JclFvRW9WYkhVeC9sc3VUOUVX?= =?utf-8?B?bEEybXE1MmNTZnhRWTQ3eG9kTU9STFFnNUpwQzdNSnZkaUd1cEpGd09WMVhh?= =?utf-8?B?Ym5tWHNoSVVRYmZBMy9heDJZbVlXVmUvaVl4Qks0amxBdjlNeklzWlY2R05l?= =?utf-8?B?TmVuNTI1Sk1HbmRwVjAvcU1vUlhNMGMyWjlKUW9jYUxjK1FEenZvbWJrekhy?= =?utf-8?B?bHk0cHl5RFVYUGxyNEJieDhYOUcvdXAvazU4NDZ5Z21URXlscGQycmdMZUNz?= =?utf-8?B?YUZleXlCVnBjU1hON29ZaFlHQkFHaVlhOUZkV1NIRHZTVDJqa3UxZndVZ1hh?= =?utf-8?B?a0JUcDlYNktQOVJERUw0MWkrSlR3d01vTDdZbmJtYTdjTzllVC9yWk9uM2Jz?= =?utf-8?B?YU5sbWVXWUJUQXRWSVZ0OWx3NlczT2h5UlFaWWdQWExUWFYrVHRaSGxEcDNR?= =?utf-8?B?RmJSc00vbVM1SGpHUk03N1U2ZDZkSmN2Nk5ENDBvQnkyenRHaUFmVWplRG02?= =?utf-8?B?a2h1bkFEWm5JNHlwUlFQMkFwNCtrWFZTOThBandwaDcvUGV6Z1JmVURQQUhM?= =?utf-8?B?UEJsSjVJbHd1Y1AyL1EzZkF4OGM3ZnMyNWxMU2lNbi9oMGdCWms1UUFaaTlo?= =?utf-8?B?bm9xRm11a1RxQTNVci82cUJNNExsUnBtSGZTbC9lTUd2MDVpODhGRXI1UlVK?= =?utf-8?B?S3JiYXNMZFpSWGVCQ29LNS9MWXNsa2Z6bmJxdHdWbm03WitHWmk1eE1qN2lt?= =?utf-8?Q?E0Hg=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eUFacVBlZHNlRVBqSndLMVJvT2lOVU9NaWdxajNDZVQyVjJseGZ6U0MrT1Yv?= =?utf-8?B?Y1Q4R1Mrc3g2eUw4SEc0cjNEbmY4ZHBudmtaMmtMdnppaEo2cWxuKzlDUlF0?= =?utf-8?B?aGdJQ0x3cmd4T2ViZ1BzU2ZYeFhKeWdUQ05RWEVjTlhFZnNwclVFZTVJQkkz?= =?utf-8?B?NExTTjZtOHNDbWcrZkh0allxdVFXZTZPVFFIVnZFcDAzNUVvMHdtVmt1Ykl3?= =?utf-8?B?dmN6UW5QbWE2bTJkVnZSR014YTk3Q2R0K29MdnNXZlRiZ3RYcEJHYVoyUDhZ?= =?utf-8?B?R3pSemRza1JuYWlQbW9PaGZSVlZkVU05Vlp1QWxUczNiUVA0Q2EvakVrOTMz?= =?utf-8?B?VS9HcU45Z1JIajVJaDF1M0FOQUV1bytTOXQyb0JYSEdET0NaQXYrOFRyTW9u?= =?utf-8?B?S3o3OUJyc21nVFJpdFVRaWppbUluc1gvc2JyMVRhNmxDc1MwT0RjSVdKZFNO?= =?utf-8?B?R2V0RllPazdkMkQvZUxObTRXUlZYUGdzWVlCUVl1a3dQdG5KaUlhYVVFTFJk?= =?utf-8?B?NlVHTjMxQVVSV0YvRVVQcVpCeE5pQVFuT0xkWmNvelhxSUdWMjZkcGQxNThH?= =?utf-8?B?aW1tN0NLRnJvSmNGR0lWaFZFOURCbTJ5YkNlVC84V2VxWFYyVkZ5NlAwSGtU?= =?utf-8?B?N0M2SmhCZm1XeSs3VlFPWWpQQVlBTWt2RU0vVXlkcHBGSWhwTjZOWk05dGdl?= =?utf-8?B?YWtVdlp1RXFoSU1MQWVlc05IT0dtNjczSmVkZXoza0Q5QnJzbXc5Z3V3VThk?= =?utf-8?B?RVBrUlphM2s1MklFa3lrNEpLYnZRODRRMWdJbS9zN29XNHNTOEJOaWJVV2k4?= =?utf-8?B?ZXVJVnFMUVpoRE1HTGVBR2ZpU3QrT0hpS2UxOWJKK1pEejVYZXhUQVRVODJh?= =?utf-8?B?eDZId0Y2SzNNZkFxeWkwb3hIQUI2azg2eGlzQkVQenpCMDNTbkVWT21CRytQ?= =?utf-8?B?T2dNaUp0ektySURIOFE5cExMTlhxS1ppelVvWEJPR2I2N01pL3lZdU4zRkhS?= =?utf-8?B?L0h5U0JaUzRRTUxCalNzRTVyUVJ5TDV3MmxJcy9PZjFJYnZlVWJiZ3FLbGxP?= =?utf-8?B?V2tENFR1UjlMK1RhbWhqSVJJaitvV0VUMVU1U2VJWjFOQVBrTEpQQ2hzZlpD?= =?utf-8?B?Z053akhEaG5tM2VNRks0eXIweEtWQVpVMDBHUyt1NlFPVzFCTXpIQkhpS1Qy?= =?utf-8?B?TkZWMVZhRG1EaUN2dDVmZmR2cG9TUENSd3EzbmtVTmVJN2x3S2d1dHpwblZH?= =?utf-8?B?TjV5a0lyY1pSOGhYWG9nc0poQUhENEdiYkNWR2w0aHVkOTBFdUlTUU9aWEdJ?= =?utf-8?B?anVqYm9HaGdZOXptTzY5d2g0VzQrek1JU050dlBiRzlSN25OVE5IeU92c1JH?= =?utf-8?B?U0JuQzE3UUNvZWNvcFlia05YQVVnOUFESmlxRXorK1EwRkk3SGljS1BRV0Nj?= =?utf-8?B?YXV4TVpLQWJXQTFoUldTUFNpb1dvYnhXR2tURDJLN2Y2M2ExdnBOVTFSMDRt?= =?utf-8?B?OXJweVRJWXNOVVJhZ3B5SFRuSXVma21XQ0J6QWc0MUEwNURBamVyVzZ3dzBh?= =?utf-8?B?d0FuSi9zQy8rQmx6dmVFTURsQ3lIZlkyNFhDeVZUTDBlRFR6MmJoWDdRdDMv?= =?utf-8?B?Z3UxNWZPN0xxNzBZSHp6SERueU9yM1dTSVRrd2pteDR4RmJBNnpBMC9OOVVK?= =?utf-8?B?WmE0bXFnL1d3SlJaT0w0M1k0Q0tyamdZOTM1RVBDY3V3Z2VJOVRFdHdxMFpS?= =?utf-8?B?MkxGU2RGblZxcGVJdEhUM0xwWUJwdTJ3WG9MWDJvdXhGbFdyRU9QeHBGdjNl?= =?utf-8?B?MzkxeHFuVWdMVnQvNDhBc2g5NE5pd3JyQ0xJL0FqRVczejZFQzhNaU1kRVBB?= =?utf-8?B?U0tCVkN5cjBySGRsdWdPZTJsTFRmR0J0c3JjaW1LY2Zzemx0UUI0RjFKYU1X?= =?utf-8?B?TFA4dEFLUEhhZHlkOEFYZ2U1MDBFZFpaMDBLbTRDQzFvQ2k5bDl2RWg1VjdR?= =?utf-8?B?RmFnMlc5U3RMUHcvM0dwU0FhOTA1QWhuUHM1djdGd2hEbzlsUElacXVTTmV0?= =?utf-8?B?ZkJvaDYwRTVGNy9xRm5tMG0wU1JZZEUrSVo0cnlESTVDZ2xJY1VpclNSbjR6?= =?utf-8?B?TmNleUY0em82Sm4yYllzcFJVT0NPWnBLZXhTSk9qeThPdUE4My83VmhrKzZK?= =?utf-8?B?RnhUMXcvWFBhcVpPYTBtNW9BM0FDcFJyK214ZW5CcDJKRWF2RHh1ME5aOEhB?= =?utf-8?B?SFZmOFNwRnFrTlhFajQ3WUUyWE5XVko4TXg5ZEYvd1dNSXJEL0EzQ21rNFJY?= =?utf-8?B?OGpuVjZHRGRnQ1RqdFJ6OXhaVElKTjh1NW1wNUw5YnJaQ3NsM0d5UT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6acaf9b1-aeb1-4df7-650d-08de5f13da41 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2026 08:53:20.5183 (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: RtbIYA62R9TA12PpgHFBXCQkxsf/HKdP+2KwN2N2NANPsxzWqrHFwYpsmn4vTJiMQpr1nFFh5+cSsmeJNe61YQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5822 On Mon, Jan 19, 2026 at 03:47:29PM +0100, Jan Beulich wrote: > Avoid interpreting as extended capabilities what may be about anything. In > doing so, vPCI then also won't mis-interpret data from beyond base config > space anymore. > > Fixes: 3b35911d709e ("Enable pci mmcfg and ATS for x86_64") > Fixes: a845b50c12f3 ("vpci/header: Emulate extended capability list for dom0") > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné > --- > Because of the multiple prereq changes, despite the Fixes: tags I'm not > quite sure whether to backport this. (I'm leaning towards "no".) I won't backport, prereq changes are too intrusive. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 29 09:20:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 09:20:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216207.1526155 (Exim 4.92) (envelope-from ) id 1vlOC7-0004It-ON; Thu, 29 Jan 2026 09:20:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216207.1526155; Thu, 29 Jan 2026 09:20:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlOC7-0004Im-KY; Thu, 29 Jan 2026 09:20:07 +0000 Received: by outflank-mailman (input) for mailman id 1216207; Thu, 29 Jan 2026 09:20:06 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlOC6-000424-F1 for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 09:20:06 +0000 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170100009.outbound.protection.outlook.com [2a01:111:f403:c107::9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ae4f087d-fcf3-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 10:19:59 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SA2PR03MB5900.namprd03.prod.outlook.com (2603:10b6:806:11a::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Thu, 29 Jan 2026 09:19:56 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.008; Thu, 29 Jan 2026 09:19: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: ae4f087d-fcf3-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rHbdT3uxoQLhuqBipXQAS1VXMYdrb5vcrFPXzsIZ+XCjKlbTzvBWteqAwcf7DibQ/tWXXvD4cGS7HmPjoLuyHWq1DfNXpmsXhLETW/aqgOlEwTx0EItWljk63FV4eNmGCefTYYPW+X4ckvlkQcko0ynxJWrsyFwrj2rWZoew6TIcqz8hhCOGVvPh3btszy6t/uRkJ8WN7R3LKcuM9ZHNS5bd2UIMNbuwLzuzgQ/Z4QnU7VvZE6rR4yEdLfyU25ukuCu0lu0LPttoIgLirvGKAAR8xsWqZh+h3GHDGWdNQ0M8DhCNCvcebIcJycoZnqIfcnCa0MrZ46ILVwJSTL8g2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Kuq4aZiaC0t9DHvOVIS3UuCmeuJl50jBYc3g9swdMco=; b=d56MwXJnWkT0cJou8y7es2+j7SUDauC+PBovqYGA8pOaiG+A6g82qgWROfpBOSo4y52fSuenjU4JHvoNJjRCUZ6wk+IDdi6jr2zLzzAM6rRo/+vdydbNBju8IOzZIj67LY3w5Bc5Tl06z0I6/46aJVCylpIDmr5/HwU++bpad8vYJU+OnS71ORzUclCcM2Zqawi6ve45QvcRoUWtuGNvQFjPeqtqSvm9xoKo8VwRFHYc1mcA7wEmgDiuAJtf67YIb77Zh9/2YXFVTilAEwiE4sXKUvsQ1VslHUSjtxySvEOMX8VJ8OT2nDXbcS5sfMkZtkkVUIeociN0mRVZrE8+XA== 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=Kuq4aZiaC0t9DHvOVIS3UuCmeuJl50jBYc3g9swdMco=; b=aPcFWUMg1AOeN/voo3DVjeXuc4nq+8d4wSaqYUdgCdkitRyuUISXmTX/FsFDH8T9S3B05JIqQtIrm0IfCG7cNssZgWOSWNL3JKHkmcxlXOPPjGeolBy+yd2MclA6C0LD/V5bBKHRoPxDFlh5CZMTvsppGJ4bIjBCw0sf/U6TS+0= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 29 Jan 2026 10:19:52 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand Subject: Re: [PATCH v2 4/4] vPCI/DomU: really no ext-caps without extended config space Message-ID: References: <58091dc1-7bda-4536-8200-2d0a5679d4d1@suse.com> <96e90685-3321-4884-8fe7-f083c25ba7ab@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <96e90685-3321-4884-8fe7-f083c25ba7ab@suse.com> X-ClientProxiedBy: MR1P264CA0185.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:58::14) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SA2PR03MB5900:EE_ X-MS-Office365-Filtering-Correlation-Id: 074fbde0-ccdf-41bc-fdfb-08de5f17913d 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?cWpvUTFteDkxUWhnVjF6enFURWJtYlpCOTZaWWRHU3VYQVFVY1N5TlJWUU9J?= =?utf-8?B?VWxoTFI4V3h6TExFNVNkeFlYRyt2dVBnWnBUaGpDQzZWT2dORDFGcGhsTXc4?= =?utf-8?B?VFNWWWJDQkt1aW1SQk16dGdzTkZCdVFGOEVYTFlqQWFaUTF2RE84WkExb0NQ?= =?utf-8?B?ZVU5M3JjQ3Z0ZlpNUDdNblZ5RHNvMXFKcG1TZGRZb29LRThlSEVkckpPdHpJ?= =?utf-8?B?VTBDSGdSYkx4RW9yenBZbkpCMDM2eFBhMjlIZ0ZUVUxCdnRlTlV5eXFvYkVr?= =?utf-8?B?M1YxSUhvMGcxTWZMRG0zdGd2bFBnOWhtU0N0STRMY0cvNDZoRlIyZ1B0WG45?= =?utf-8?B?Vk5nTlVkajljVW1yd0FDRmcrME5MenlTZjEyUGxCdTA0cGlKV0hxclR0VDJ2?= =?utf-8?B?aWhxWVNTTmlNSGpCL0hJeVpkVDhrcGZpMmorcjliUERaeDdDeUVIalpDc3Mx?= =?utf-8?B?S3JuV3pqa3pXMGo4RmVzMnJBbTRGakFKbDB2VEorK0Q4Z282SHkwWm1iRzNC?= =?utf-8?B?Znp0bTBpMzdJQi9XNG00czFBTUUwSm1hWW5qT21Bc1dHQTRGaHhSS0J0SDBv?= =?utf-8?B?eHpDQ1JGK1BkQ2JZNWxlWDJ0czdKNWpuMmRoTElxOEdIZU80T1VEMXIyR1ds?= =?utf-8?B?aDdjdWRkZWxGT3UyWGx6NUZoNzN6WUtuaDVaL0pENWhVQ2hrakdMemMwZENR?= =?utf-8?B?Q2lnOThVVmFSRE41cU5maVJYdGUzaHcweEJGU1BvNVFkMXBNb0Q1N21aWktH?= =?utf-8?B?UmxvMzJhdURlbU9YWXpOSGlHNjZ6aGFGSHdhWndMYzZ4ZnBHWUNSd3BjYXF0?= =?utf-8?B?UkpDVkM0MU9MZ1l3Tm5Gbk5hK3lEend4ZDRkZVdmMldpUVQ0N0llU1FZbG84?= =?utf-8?B?VUxWUTgxTDZFU0hhMUxNZFM4ZTg1VmdDRTFOdnZJcFA0ZTdEVHRqQVNNUG1p?= =?utf-8?B?MTc5RWxPTFNvTGlMb1lhVEhvSHQ0VDE1VElXWEFSZnpZV3FpZUk0TjF2VG9i?= =?utf-8?B?MGc3czlpc0U5TDQ1VkpmR3NRTmt0UkJGUSs0czUxR0xRa0pVSzB5bDhucXkw?= =?utf-8?B?d3JibTEyUHVBemxaQ1M0RkV3ZnJxdG1HZmljcko4MVNJZStZY3pWbnU3TUgy?= =?utf-8?B?aVUrREFGTXRYTTUxdlJBazBQMjNTdkdCNUF3VzJvSTNFZlFSSjdWVnhab3Bx?= =?utf-8?B?d2tOcEM0WHN0QjFpTjBmTjBlMHZMQkhZbi9aM3dwMWJFYnFpaUhWWlBPcTBs?= =?utf-8?B?OGxEd0RGTmJsZlMxdWV4eGhCU0NvUFlBTHpVMXhFcGFsZUNhZkJaNVFjc2U5?= =?utf-8?B?VnhhdjV6NmlXczA3SUN1QksxUnA1a3RBNTU4dy9QQU9PZWt0QUpKU285R0pO?= =?utf-8?B?dnpwdU1nK2RFa21Xd3d2UGZRUHUvRXlaeHo3aDhRRG9jUlNRdERZd1hhemNp?= =?utf-8?B?ODdwdzNPSlFYMHRGUjBnbTVyYnpiRVkxYjFxbUJvWTMrVlJTQVJNNFFjdXAr?= =?utf-8?B?czRXRUhWeStIbGFidlhYTzRDWHV2WHNkQUE1d0pIUWJEV1BVWmdWbm11SUty?= =?utf-8?B?MkNNc01sZWlreEQ2bmJvYXRiZTBwWFhGemRwYVU3aDNvY05OUTNEaDhrcTc5?= =?utf-8?B?emRnMXd5TmIwN3p5WG0rN0RvOFV1VHZabjByZnQyRjhxRldFQjNsbkMyNnFz?= =?utf-8?B?Uk5wQkRoZVJGMlMrQVZoUWFPOEdFZjBVdnJvN2ZZdmM0Y0gyY1NYUElZZjll?= =?utf-8?B?WTFXYVhCam5Iblk2OHpwY1V4ekMrRlhrV0JGcVV4UFBHR0tkRFd4RUpaUW8r?= =?utf-8?B?THdrMkUyZWxab2o1eXM1SVd4ZXhWM3cyekJsT3V6TTRMdU4xa3o1alEwLzNa?= =?utf-8?B?OFN5a1BRZHV5UDBVN29TRW4rYTdWbE40eE84N3h3a0h0RmZYSzFwelhYcVpp?= =?utf-8?B?T0ZPOXBDeTc2V3lBd2NJL09BbHNTQ0UwYUIvVmJBdVd4WWRrWGxIRm42VEF2?= =?utf-8?B?dXdCTHFVUEFRNVdFQzEzcjlWNjl5RmdtWEhjN2czVFJzQ25MbmV3c0NiWHBZ?= =?utf-8?B?V1B5YjJRZ3dnY1FJRGE2RzhWZzM5RU42eXZhMSs1a29Zbk8zTE1PRHRHVUh5?= =?utf-8?Q?n12c=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aCtyM0YxdkZDZFpqQkI1WlJmNmUrVzNiRW5QV0tTSFRnZHROY3lLWmJ1aGRT?= =?utf-8?B?amxiclVPWjM1UWFJd095Sktta2pvSmh6Y3A0V21WQit5SjlGSEdZZ1g0YVZ2?= =?utf-8?B?bUdKWjl6bVRjeUNHNHo5OTlSNTVyMU8zVDkyc2YrOXRmYmZBSWhLZHBBSTZl?= =?utf-8?B?Y1Nmb3hYWTZYU3F2MDhYanIwd3RkK2E4VWVQTzRJbGNFSjk4SDE5UVl2U2l4?= =?utf-8?B?bTEyVW5YdkVjNVVtaUdKK01pODNyR3dEOHR2K3Y4TStrTHpIVzE3Rit0M1FN?= =?utf-8?B?VGxXNXVYMkhnaFNVTTRXNG9GbHpFaHJhMk1OSXZCbTEwYldjMTMvMDhEV3g3?= =?utf-8?B?dFhTSzRsdlBveWZsdmFudE1lMXkwdHEralU2ckd1cEpPWVdSQ1J6MjdxZVFE?= =?utf-8?B?QkFNbFY1Uk9ZZ0o1dHQ2OE5weGs2UDRLeGlJSnVuR2JkRjBrZkc3UkVwMWdC?= =?utf-8?B?cDAvWWM0MitvTUlxN1gwK29EQ0xBbUt1QzVqb3d2ZCsvcS9rME4zWjFuYVov?= =?utf-8?B?NSt4cU1BbVZ1UlBWZWdhREJUbzRuai91Vy94M2V4blNJUUFPbFByb25nLzlR?= =?utf-8?B?TVAxeWpTUXF3ZnZmUnBBNUNtRS9lRTVSdnBGaU1hUThQYUNVb3RCM2VOWllZ?= =?utf-8?B?MnJHUVFyM2JucTdRZ05kU24wYTJxekFXd3ZYMFZCQ2VIZGRiSHFFblhzRjgr?= =?utf-8?B?OUF3WFVTZUJiTWdyTm5WU05ERXFkY2svdlA0ay9NcGovbTNzTlRFYStsemZa?= =?utf-8?B?UVhrdzlZTERuQ0Z4VHJjSzhkS0tBM2llb2NvTHgzdThHdTNUSklJWEI4SEg5?= =?utf-8?B?Tm80R2hTYm1heHV6Q011Q3BRUWFqUmlOTDRSZWxWTmFwTlpNem1CRnZrQ0VR?= =?utf-8?B?dGFyWUxKekJqQTlNWDkrbEFpWlFRMlZhelVndjZOQ3VYQnMvRmMxNloreGlx?= =?utf-8?B?UHZCdUg0aFR0L01rMFVLRW5XcVRaNzUyTTdnRmViVTM3aTcrbTJDaDBHMUI2?= =?utf-8?B?ZjJJcUhtWC9iTDNzOTdLMXZ4WjJtT04xeEwxVXZVY2dUejRFM3N4SHF5SE1T?= =?utf-8?B?cXdHVnkxQ1prK2JRLzVJNy9mSVZWM1FBMjhaYzR4bndHcWxUY1VGcy9BY29Z?= =?utf-8?B?Q2p3eXJwdFZGRnJBL3pCbkVhdVlYM1BiK1pZcDhicDB6VExUeTBnOENHUExw?= =?utf-8?B?OHJqVUZRczNYWXJnVGRnM1BFUFhuVnZPWjk4ZFpaY2o4NEZPRnMxYndIZXVX?= =?utf-8?B?bmFFTEtyRE5FLzIvb1hIYzNVRUE5bWQ0dmp0WHM4ZlM5YmZ6Y0xEcS9obmxD?= =?utf-8?B?UFNVeXBnK0dVOVNjbS8zSDJEZ0lqb2dPSGNzNUtOY1FKcHVaM0kybU5KbGtH?= =?utf-8?B?YmZwOGhkU0czdlp1R0tZbG4xUFhvdHZqRWJFTnNaVHl5ZGd6TVZFaDgweGVh?= =?utf-8?B?d3IxSUVRNENKaVJZa0xpaityQ1l1N2R0WjNpYTlEU2RzMWgxZHluZ3M3bXNF?= =?utf-8?B?U1BXRFBMRHZyaWpLcnRhTjNpYnUyQTFiYmszNDNPSWRjdDNveG41Q2ZWMHNu?= =?utf-8?B?SEp3OEJNcVNrRGJLTFNwYm1YL2F5NWIvczU2YWJBb2g3T2hjREpvUlA2VWg3?= =?utf-8?B?QTNScno5dUlrd1pSYWRja2JWbDhoK0xnYS9VcDMzU0NPOC9OMW9Cb29iNCtG?= =?utf-8?B?VkZ1U21yWlE2alZ0V2czcnBQZW1YNTZ1ZXNsME9Fb1RrV0IxVnJqSElkOVBk?= =?utf-8?B?RUs3RWhDTmpqb21vUXdYVitRZXlvdCtaZEdnLzVEZCszbVY5MDVDQ3hoOTY4?= =?utf-8?B?a0Z6TlVBZnVLOTBCb0szb2VBMkxZam4yV1Fab3c3TCtvUVQwRG1LWXlUSHJJ?= =?utf-8?B?WjNXYVdwL2grQnZYSHZUVlE5K3hlRFI1YmlteWNDNml4RUd3bXhIR1VOOWVZ?= =?utf-8?B?VUwxTFNWNVQyZGNmeEZzNWI3ZjFuYmpLWHRqaEQ4MUZQZ05BVjJ5b1U4eFQr?= =?utf-8?B?L1hxczExeE8yazhIYlFja010d0NteVdIK1Z5dFgwQzc3NXVmdmYrSW5tTFlx?= =?utf-8?B?bGl0TStPY1A3aDNqVGxyeUJDK0FRV095aWZOeVMyWFJLUlJlOWVkc1I5N2ZV?= =?utf-8?B?N2ZsMldZMnhsNjN4T3Uva3kyamFPWm5FK1JoOUVhbnFRNEdKVW9OT0ppTVBL?= =?utf-8?B?a0FDSzUwUjM1YllTTy9pTzF5VDg3NzYwc1lLbHJTRTNOekM2SituL3MyZE1Q?= =?utf-8?B?S3dtQXU1V0lEaWk2dFJUMERMdmpBeU5TVVpnMWczODY3WEY5Y2Z4Y1JvRloz?= =?utf-8?B?YXYwY1c4NEswYVJvRmZjYktJYnpsMWIwNTBDN3F5TjYyWXkyckVIQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 074fbde0-ccdf-41bc-fdfb-08de5f17913d X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2026 09:19:55.9904 (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: vQQC3I7LKJXtVmyFD6hMMSMngis9odsUVTFn0NtJkbLZdJ1XumwqUdTp2qpcNyoiC1ias5ndIc5FUP/EoKRDBg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR03MB5900 On Mon, Jan 19, 2026 at 03:48:01PM +0100, Jan Beulich wrote: > Whether to emulate accesses to the first 32 bits of extended config space > as read-as-zero or read-as-all-ones depends on whether a device actually > has extended config space. If it doesn't, read-as-zero isn't correct; not > getting this right may confuse functions like Linux 6.19-rc's > pci_ext_cfg_is_aliased(). > > Fixes: a845b50c12f3 ("vpci/header: Emulate extended capability list for dom0") > Signed-off-by: Jan Beulich > > --- a/xen/drivers/vpci/header.c > +++ b/xen/drivers/vpci/header.c > @@ -830,9 +830,14 @@ static int vpci_init_ext_capability_list > unsigned int pos = PCI_CFG_SPACE_SIZE; > > if ( !is_hardware_domain(pdev->domain) ) > + { > + if ( !pdev->ext_cfg ) > + return 0; Don't you want to possibly put this as a top-level check, so if there's no extended config space we avoid doing the PCI_CFG_SPACE_SIZE read for dom0 also? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 29 10:08:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 10:08:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216226.1526164 (Exim 4.92) (envelope-from ) id 1vlOwv-0001Jh-9Z; Thu, 29 Jan 2026 10:08:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216226.1526164; Thu, 29 Jan 2026 10: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 1vlOwv-0001Ja-6Y; Thu, 29 Jan 2026 10:08:29 +0000 Received: by outflank-mailman (input) for mailman id 1216226; Thu, 29 Jan 2026 10:08: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 1vlOwu-0001JU-28 for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 10:08:28 +0000 Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [2a00:1450:4864:20::431]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7356dd5f-fcfa-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 11:08:25 +0100 (CET) Received: by mail-wr1-x431.google.com with SMTP id ffacd0b85a97d-432da746749so542795f8f.0 for ; Thu, 29 Jan 2026 02:08:25 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e135422csm13731802f8f.40.2026.01.29.02.08.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 02:08:24 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7356dd5f-fcfa-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769681305; x=1770286105; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=aFTTiD59NBy3aFazyOutc0ksXRirFfJCu85Xhvjw/Vw=; b=OyFXK/1USokC7I99QCLvsPbShaAVxyj2r2WVKA+mEbrw7xm1aWeHVAJTD05Gwma9lE EOssl2zCOql2cQ1BDjRTlBNmBefRnxxM7j/xCamFqp6bjGDEyR+E2DDdzE5u1JsHRwZH 0fpn12ZJH7i2OXEQAAkxpU/4zLkLAzig5rp2/5jUWuBqZKF7HjKK0ZIBMoAMjKsTZwaL tm5kGg1Nr8mWuqTugA5A5GR2iNzRrIFLTbhSevrf6JHw5KiU2b2dqU2sHLXEqzpr8W2s wCCVDXgoGgMy1FnbLWU2uqVuJgXcHQcFL2kZZ9STskqGmrk0WpXzzETl4dMqGvugGFab QrDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769681305; x=1770286105; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=aFTTiD59NBy3aFazyOutc0ksXRirFfJCu85Xhvjw/Vw=; b=EUg8Iq06BLyqQOwkYTKgLnhns5yGV//zvrNM6eOqsVLokrnWqcEg6Ey28glEQrb+xV 9LEmzus0ZxNvutwvsZpuRnVF0Q+i1P6vlsUb5VvY0TUDsjYjZb0P8uLdx99wsXxP3GfY Mi6nRfBZjbhhewbHB+AhtBVJraD6r0DpEVPaICwlfbzxZ65LPSXqtuCEWyJeA0fupxu6 BlPb8mSA837VnnDL9+kjvsEUoG3SNRUuieZqeX7pXgWo/exSjyay0oC/oYQLKMDHxEzp 1hpoUw00WFeGhWMxbNEQCjTrVmSDPrzz400BRcW8wZjB7G8EyKc8CsEPueFyhr7tiqP1 0rtQ== X-Gm-Message-State: AOJu0YxSs+dAMwdtzf36QchN89OwcecG9YltfA39dD66rijCeFLAX3u9 MmMDml1+9OVXrM7CCowlKq6yTymdSrqNwF3DgxnCrFzojXFXh7QGq3412RzKpmkOCg== X-Gm-Gg: AZuq6aLWBG7qijnzfOyxPHtz6+KjDNF+h0pVgJ/uAkDk/tzNP52S+kKpMDJnD7NniOr 5QVvqFpVBPARs/Xw7fgTes6KLaqdtSQwuN4IcvkOC3UJtkmERjBsLgf1gcbH/z6U3ToUp2N3T+Y vNLuBJg+FLxrWY2xfsPHnELxlpsySwQfmG2LkJU0DmL/KD9THRoMvH/tp0EF5rqVcT9n/+WjKJ6 8LRvfTl2pN7XukpKjPZjH+QWAbMtcJyqVSRxE9suiVRw6plx60uGEXWYfqFpuYOb+kE+nCwJYur ep10VbqrFoSIYFcIZggFAYyh3R691a7Z4XXoNB642c0prOvzhn6hLtjuJdeZoEiHtHHcgg+Qcnt D02bqnetqBxF7wQw0xU0mw6nRxGT8oWDQet24mmzgBXwMr41eGjX/zujFX88fEjCKjJrhSjjx1s eQeGkBIQyJd/Kh/Dr0Dii+MQPJm+Q3c8Elw4OuFHuV/IxWFvHpwBPj+TPBtBQq3qYahVFzcxdaw 8uwGx7CvzJDEQ== X-Received: by 2002:a5d:5d0a:0:b0:435:94c1:3713 with SMTP id ffacd0b85a97d-435dd0a39b1mr11715799f8f.37.1769681305111; Thu, 29 Jan 2026 02:08:25 -0800 (PST) Message-ID: Date: Thu, 29 Jan 2026 11:08:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/4] vPCI/DomU: really no ext-caps without extended config space To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand References: <58091dc1-7bda-4536-8200-2d0a5679d4d1@suse.com> <96e90685-3321-4884-8fe7-f083c25ba7ab@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.01.2026 10:19, Roger Pau Monné wrote: > On Mon, Jan 19, 2026 at 03:48:01PM +0100, Jan Beulich wrote: >> --- a/xen/drivers/vpci/header.c >> +++ b/xen/drivers/vpci/header.c >> @@ -830,9 +830,14 @@ static int vpci_init_ext_capability_list >> unsigned int pos = PCI_CFG_SPACE_SIZE; >> >> if ( !is_hardware_domain(pdev->domain) ) >> + { >> + if ( !pdev->ext_cfg ) >> + return 0; > > Don't you want to possibly put this as a top-level check, so if > there's no extended config space we avoid doing the PCI_CFG_SPACE_SIZE > read for dom0 also? Hmm, yes, didn't think about that. That'll mean dropping the "if ( pos != PCI_CFG_SPACE_SIZE )" from the body of the "if ( header == 0xffffffffU )" then, i.e. the printk() there becoming unconditional. It may also mean dropping "DomU" from the subject. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 29 10:34:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 10:34:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216246.1526175 (Exim 4.92) (envelope-from ) id 1vlPLU-0005CS-4f; Thu, 29 Jan 2026 10:33:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216246.1526175; Thu, 29 Jan 2026 10:33:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlPLU-0005CL-24; Thu, 29 Jan 2026 10:33:52 +0000 Received: by outflank-mailman (input) for mailman id 1216246; Thu, 29 Jan 2026 10:33:50 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlPLS-0005CF-4K for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 10:33:50 +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 fe624af4-fcfd-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 11:33:48 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by MW4PR03MB6620.namprd03.prod.outlook.com (2603:10b6:303:12b::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Thu, 29 Jan 2026 10:33:44 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.008; Thu, 29 Jan 2026 10:33: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: fe624af4-fcfd-11f0-b160-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AHLHKwEkUWz9DKzc3s9SuLuo/EdHe9d4mBTin8kL8YTDTbwnVlT2mNQOA/ysza5ukYh6nmTRnkO1gkrZBQQh31VqgBJwDOCOIBlRisW59ysaXJGLLV7pdiaPQ2EgbeGlP5Kdw0M14WioZr7i7uIzTg/Y2Y+m1j8qWR3GAJImghpN40C0gasq7DsIdgsbklHc44UdKZdRDLyGd8D+mxfTGFkFn16GyevesOnzchDuvPvi0Wi0ANFAog5I6Nkd0iDat000aCy0y5n4ZtnCL5yI83/BtZPpu7CoK3bjkq+lmx79H55CN9rBq4tSKXIMLxg1/zn/3aCPiFugYPYwyNb+jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fjXyFMGyI1iMKVmPwb92hIK3NfqNBt9EutwiA3lqK3w=; b=t7Rftw5MLruXwPBjEAPNAiMoz24uDUr0Sj6Tzp11HGEizDDBDlOnyPWZ6sm0XKtyMyJi0EETlMD4rC0I4BGJ2KkEI/oPAPmtgiCdd0wu2nC/5pEJKIzJDYo8AyXWGmJq508TdVxn/Be8rWt/a7zXIUr27tRhO7+AXK6OE8t9V+I0vxCrY+m6NXtUPzc3UDLrFxMWXt5Ri5fhI/HBsZMceFqQ29qQKpxlukVGZSl36i3vabsTZeBIIC7l6XVv8JqFkGkU6L+4VAbtA99pYDJRS3X9w6up2UvCtVcIccGAiXzQu9R5XciK+aN2wmRqjr5UlgWrOXF3Z3AoJNwnIkdXMA== 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=fjXyFMGyI1iMKVmPwb92hIK3NfqNBt9EutwiA3lqK3w=; b=L0gyPlfEoUY6TXwZ/2QwOkL53OxAqFun9gh50Z9vpLtVZgS9oBELJmgYGqJe7my+bZ1DOxqb4/6MIEP/NTYGqtixhP+wad7/brYvG5G6V+++d4jhiGkN4Z6G+ZnUHLpsW0cMAMaaNyr/BdAvFNteLr6uwDLiY2oZdiRSTS3St1E= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 29 Jan 2026 11:33:40 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , Stewart Hildebrand Subject: Re: [PATCH v2 2/4] PCI: determine whether a device has extended config space Message-ID: References: <58091dc1-7bda-4536-8200-2d0a5679d4d1@suse.com> <2d5e017f-1675-4753-9494-2b664c4ca7fa@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2d5e017f-1675-4753-9494-2b664c4ca7fa@suse.com> X-ClientProxiedBy: MA4P292CA0001.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:2d::20) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|MW4PR03MB6620:EE_ X-MS-Office365-Filtering-Correlation-Id: 14d7c943-5a6e-4123-6fa5-08de5f21e064 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?R2F5OFlKNDZuOGtrMTlHa2g5ZDE0SmN2a28wV3dsZXhnUmJoVmx0V216c1Nm?= =?utf-8?B?cFVTOVdhRVdJWk5iRFBEZHdnZ2l1RTVXTFB2UFlwVzgwY1VobjBEMEtMOFpM?= =?utf-8?B?amR6VVd4c0M2TDdiNXBQbTRta0xYU21QVURnTnViVXRvL3V4c3ZtMzlIWmg1?= =?utf-8?B?UEZ2YzNqc0pIYWxNTFBjcXRGU2ZjeG5ocEpONEQ0cnFCT1Nwc1FJVHhzTyt2?= =?utf-8?B?YjJ2TWJnaEVRS3RwQTVvRS9vYmNOTHpvVXRnZjFFaXVhSk9IekhNaHpSajhO?= =?utf-8?B?eUJGUWtJWEx1Q2ZBUVF3Vm12TEZNZk9hSXR3L1A1YTB6eVlpVUtDMjBDUS9j?= =?utf-8?B?Z0tVNVFZSDJ4TmpEYnY2emNLajlGSE44c1VqME5nd1hsYjArdExVNEsyWWpI?= =?utf-8?B?UEg1RFQ0ZU1CUnB6UHo2L2Q4OXRxbUVmb0xTYUYrR3g4NWc1d253U21oMno3?= =?utf-8?B?NWQ1WFBveElBVkVCMFU3aXQzclF2WTNqOVI4MnF3Y1hPNzNnR29DODU3Q2I0?= =?utf-8?B?dUdadU9GTlVYeGhPeHRyaEtRTUp3ckV0RHBPcGFmcDI5OHVHRk9qV05zblE4?= =?utf-8?B?TFRYcmI5OElPcjdHdUUwenBEUDVPeU1DTk9ySGRuS1lFd2pWSk1MSnY4Zm85?= =?utf-8?B?S0ptUGg4MWlDK1c2d0tsL2dQOU5JMlNEMGZ5VjJYNnZpRTMxU1dGU0c0OFdJ?= =?utf-8?B?Tm85STVnL0REOGF4QlJUSzk1OUxhOHRxb05kZ3hKVTgvTWU2dWFzVUtPS3Jq?= =?utf-8?B?SDk5YThnODk0MXJNMGJpcVM4K21yWGY0N3BmU21NTFZVbWZka1VPTllZR2N3?= =?utf-8?B?WU9HMnIrc1FPaXBpSUVTWVFUVy8zTER0WGVYUE1ReFh6ZnUveGY2RDNsN2NZ?= =?utf-8?B?Uk13RkdXUWlWVU1YM2NFbFNNM0M2TUVQYmxvWTU1TGNLaURmVGkyM1ZvRndq?= =?utf-8?B?RHFaV2U3RlprOU1RWjNFQVZjTzVhRkFDc2U5MHBFQjdWeXFTbXRlZ0hkWFhz?= =?utf-8?B?T2dMd2I3cG1TclBiMFVuYzZ0T0xhbHlMb0d5dTBtaUFXeUFJa0xOWGRSSTRm?= =?utf-8?B?QXVaVEMxZyttbm9pOWZ0bEJ5WkFWaUszTC9RZFlYNzVMejBmblI2S3d1cGVN?= =?utf-8?B?aHNreU9iVElKR3EyaWZMOWQvYUdBOTFQTW1MT0pUZTVoeGQzMXpLWk9SZTFv?= =?utf-8?B?azc5ZllHWTN1b1puS2lraE5tSlNCOHpOakd0cGh4LzdISlJ6ZXEyRndJWUxp?= =?utf-8?B?NXdqVVRQeDROdHhVL0kzekhYalNudTIyZFZjaGtsZEg5a0FsL29BckRkZ2lJ?= =?utf-8?B?WXBnWVVnRUxMMW53NHZITmkxMWtHbFVaUWo3cTFRbGNiNGt2VzVPY2cvRzJQ?= =?utf-8?B?YWljTlFlc0c2TUZNb3MxL1BkNjdqcTVib1NCaUFjYXNpR3d2ZTExRGN2cUNJ?= =?utf-8?B?ajVCdHdwcVk0NTRwNUxhRnV6SXQzbzJZQkN3SldYRmI4eXhJWnEvNmEzWFR4?= =?utf-8?B?RTNGSTdOT1FJS0JvZzZmcDBkajArOVJvbFNlYlRyTStvcGltRmJnMENCZzZp?= =?utf-8?B?bkxnY3QzbzRXM0dNZTB0YUVHcjJOZ3VTQis2VkpJVkk5N0NLZVpxYWhMc2V4?= =?utf-8?B?cWZjSUxkeE5WeVlwN1NWbFJpVElJVE53OGZJcU9YbFB5RW95RXE3dmlGUmFX?= =?utf-8?B?V3hrZjdaOUFKM1BpRFFpRC9sZGUydHdLbnlzRXJwZ0ZBem4wQWxacVhFblFl?= =?utf-8?B?a2JXZS81TFZoNW9PVkNoYmxNd0RsRVR0S2ptWnBtWE1PN3oyYVRocFkrUkZz?= =?utf-8?B?b0hZdWNSK2hFd0gxcEVxaDF3RUtBYmE0TUFRSHJoWEczUWd3bHhPY2E4MzRG?= =?utf-8?B?Z3BieGtGWEJiSkVTWE04b3JmQWRMckVLblhJN1V3dFYyeklnelFaKzJYcSt5?= =?utf-8?B?OTY1TlMvYnA1WUxFWHdUR1hWMS9kdVMwY2piTDByQ1lKU1ptOXJTZkZ3T1Jz?= =?utf-8?B?cURpcVN4VG1SdVliUndQQnpmZnJiUzlCRTVySTlsdm5SMmg2QjMrdXdwSFpD?= =?utf-8?B?KzRSa2JacDhONWNid0pRRGNCNTFUQnhOSVB4dVhsUndrNlVvQ2VwU0VFeWp1?= =?utf-8?Q?vjNU=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aksrRVZ5eHZMbGEvYWJaTnNrQ3ZMMzBKUGxob3o1VE1GRjdOSW5tRGEyUGxD?= =?utf-8?B?VTVWb0RDOGR4SE9sZGp3elV6cVZQRVJoSE1qTGFBSlNlbGQ0M1JaZkx4dmFh?= =?utf-8?B?d25sRVhkL3hvenJuaU1XYXBmcGJoQndMeW12UmNnRzlkNC9zK2FTaW5jd2tD?= =?utf-8?B?TEVLY1RuaEpaeHZUbWZRaGovdnk0OHpDVThtUTRhU2g1MHJPNm1vbWs5M2pw?= =?utf-8?B?dmpNVHJSdnJhbnJXRlUvN1QyYlBUNlJnTVQyYnorejRycGNYSGF2SnQyNmlK?= =?utf-8?B?Z2xRSVRVN1FHbXN4RFlEMlpiNllpT3lJY1ZJMEpWMUFzQ0tVVWJVTWNNOHBN?= =?utf-8?B?S09uSlg1NVNiMmxZZHd2V0ZDTFBLZWRaYjYxZWdMWG5PSTVld3oyblVJTVFT?= =?utf-8?B?RkNnbVNaRjBYREwwZXdKNGNITG9RdlZQcCtPMDhuem9xSGZxaktGU1RaZ2F3?= =?utf-8?B?VFJocHhJeE0rNHo3c25PcWMzZDVHWVpSMTBIWGx1c3QxTHlFeUthbWtJdlFU?= =?utf-8?B?dEdyK3JKVDROcmJZMlV4dTI5b0U5N1JueUZqdXdEeWYxUlJLa0FEUXlqSmI0?= =?utf-8?B?TVFJS3pvMHc0a2pCcFlzbFU0dzdqQUlGeHlJLzJyMXUwMjA5cFJZMHBPVGhK?= =?utf-8?B?ZCtBOFdjVWFTTTNTUVlPNUtDdURkRlFjOFVhdVNscmVrRktmNzJLZzJNSmw5?= =?utf-8?B?VjFqSjE0MmIwemdoQlpqejV2WDQ0Tnc0Z0wrV0orRVZ5YndIdmMwa2xUc0Zp?= =?utf-8?B?WmJWbllzeDdoQXBpQXFsM0lCN0dSWTA3c2ZiRnl1d3pGb3pKa0JiZWRvcnZs?= =?utf-8?B?WlFNUVAyd2hkbzFKNHJwVlpBUUVVYVBrTWRaVnBiMWR0L0xhd09ld0hRb2hR?= =?utf-8?B?YWJzSnBnVmVUZHdTNWNVUnlwL3ViL0NGekxwcW9KOEE1ZFFlczcycnNXQ2cr?= =?utf-8?B?V3hGYTA4Vm9yVnhEam81cE9FUXBhbUdqcW9lY2NqQkxkWCtZV1hVTEt1b21t?= =?utf-8?B?Vy8vYmpIaVFVOWZzMjVKTjB2bWJnWDRyeTF3dEltWDRFakN6bEMxSzFXbDFL?= =?utf-8?B?WXJkK0ZtTGNxR1grOFA4WTFOMlk2YU5sdVRsOUg1b3ZhVFJmbldUSHg0MG5n?= =?utf-8?B?RzlMN0k2R0VOVWNpaEluSktxR3puSFZnYkpyUWdDQ1FHSlRvWHdvSm9sYWNw?= =?utf-8?B?dm94elZyTW9SdCt1QjJ2YnFYdC9VZnRQN0twSkdmRTc3dmNSYytLWTJGQ1Rv?= =?utf-8?B?MUxvVGwxOC80OU9Lakw2cHR5WWJreUp2Qzl6RGVCMjlUU21sK0h4UFVHTDVB?= =?utf-8?B?WVhkVk5YSWdJbVh2b3JmbFEzMDdqODRza1FQZTY3YW84L1JqcllhYkVjY0Z0?= =?utf-8?B?NEllQWF0TXgwd251em5HUnllOGdrRHVlMEwrSEVleGxObmg3SFQyZ0U2dkFm?= =?utf-8?B?K2g2azBQT3pmUzYzcmhHVENuZmxLNmhWY0R2K0prQVBTcU1jcTdtUzhGMFZ0?= =?utf-8?B?T3FQMllCNzJBeCt0eE1LYTAvZHpDb29Zdm1XQ0VndTNWWm1JYUUvYloyWHF6?= =?utf-8?B?cHh2VDlRemNIQ20ydzkrUnJBaHhBclhsbi9abnVleHlIbjIxSEowUVJHc01l?= =?utf-8?B?bHlLWVZzYnlDWjY2Q09sdnY0Z2UxUi9xTmJ1bUtJTzF5VHBJS0tPVks1cHJE?= =?utf-8?B?SUtiNmhuTXVnb0t1RlovQk1TTGp0blVxSG5jWURzN2diM2JqWCtGaUFwOURl?= =?utf-8?B?U0FRRVRIMlZQeU5CSStqdnQ1Tmx4bTRlaDUzWFAzT3hBdXB1WmtnUHg1Z0RW?= =?utf-8?B?YS9OVkgvMDhlZlgzVVdPZXZZbTV6YnVpNGZHViszdCtyYmxObk00MmlEMHZM?= =?utf-8?B?S3NwTmpLM2ErSEI3WFNsTEJFU09rMlkyWTdSUDlqeTd3RWZvcFJ2d2lhanFu?= =?utf-8?B?dmNnOGpnL0pKek9xMkhQckE4d2ZnYzNmYlFneUJybWErM1lsOTRqYTN0MlhV?= =?utf-8?B?eTBQZTRwaFVPeitMbUEwdGI4a3puZ0hza3NNUFNmWlo4VGEwcmRpNWlOaFJZ?= =?utf-8?B?Z1NvSkhIOXVjVm5HbklYdllUem5GUmd2MkJaZFUxS1V0YnN2b1dQTExtendI?= =?utf-8?B?dXJ6L280RFFmU2E1djg5aTdVNEd1eFFac2twT20rTmY2QjE2NDQ2cVBLZmd0?= =?utf-8?B?aVRvZlZOd09DM1JYeWV0M1o3WU1mUXZsS2N1MEtmSXh3dy9qWnFJTVJ0eExs?= =?utf-8?B?RTQ4Y1krT215RW1uMGhwSjR3MFVzVG1CR0YvdTRUd29XL0xqa1E2Z2JETXBn?= =?utf-8?B?UG1hdEpzK3NkOFVMMFJkVDJBdFB1SFNWZmxRaUxxbXRzbVREQmVIUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 14d7c943-5a6e-4123-6fa5-08de5f21e064 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2026 10:33:43.8748 (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: pQBTsgpnHhSSvrUsWqGdEvEF8oKh3LKJrl+E1HVERON+dyaWoB/pcFro6Dw5DRWnpGDzH/L7DC7lsPfLyxuNQg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR03MB6620 On Thu, Jan 29, 2026 at 09:15:30AM +0100, Jan Beulich wrote: > On 28.01.2026 18:49, Roger Pau Monné wrote: > > On Mon, Jan 19, 2026 at 03:46:55PM +0100, Jan Beulich wrote: > >> Legacy PCI devices don't have any extended config space. Reading any part > >> thereof may return all ones or other arbitrary data, e.g. in some cases > >> base config space contents repeatedly. > >> > >> Logic follows Linux 6.19-rc's pci_cfg_space_size(), albeit leveraging our > >> determination of device type; in particular some comments are taken > >> verbatim from there. > >> > >> Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné > >> --- > >> Should we skip re-evaluation when pci_mmcfg_arch_enable() takes its early > >> exit path? > > > > Possibly - we expect no change in that case. However it would need > > to propagate some extra information into the callers. I could see > > that as a followup optimization. > > Okay, with Stewart also saying so I'll make this a follow-on then. > > >> Note that no vPCI adjustments are done here, but they're going to be > >> needed: Whatever requires extended capabilities will need re- > >> evaluating / newly establishing / tearing down in case an invocation of > >> PHYSDEVOP_pci_mmcfg_reserved alters global state. > > > > Hm, you probably want to do something similar to re-scanning the > > capability list, but avoid tearing down and re-setting the vPCI header > > logic to prevent unneeded p2m manipulations. We have no easy way to > > preempt this rescanning from the context of a > > PHYSDEVOP_pci_mmcfg_reserved call. > > Yes, definitely only re-evaluation of extended capabilities. Note, however, > that once we expose more of them, there might be a knock-on effects on the > P2M. Preemption in that case will be complicated, as we would have to defer p2m operations from multiple devices in the context of an hypercall. I guess we will cross that bridge when we get there. > >> Linux also has CONFIG_PCI_QUIRKS, allowing to compile out the slightly > >> risky code (as reads may in principle have side effects). Should we gain > >> such, too? > > > > I would be fine with just a command line to disable the newly added > > behavior in case it causes issues. > > Can do. Will need to get creative as to the name of such an option. pci=check-ext-cfg=? Kind of a mouthful. > >> --- a/xen/arch/x86/physdev.c > >> +++ b/xen/arch/x86/physdev.c > >> @@ -22,6 +22,8 @@ int physdev_map_pirq(struct domain *d, i > >> struct msi_info *msi); > >> int physdev_unmap_pirq(struct domain *d, int pirq); > >> > >> +int cf_check physdev_check_pci_extcfg(struct pci_dev *pdev, void *arg); > > > > I'm not sure why you need the forward declaration here, the function > > (in this patch) is just used after it's already defined. > > Well, this is needed for the same reason that the two decls just above are: > The file is also used for the COMPAT variant of the hypercall, and hence > the declaration needs to be visible there, while ... > > >> @@ -160,6 +162,17 @@ int physdev_unmap_pirq(struct domain *d, > >> > >> return ret; > >> } > >> + > >> +int cf_check physdev_check_pci_extcfg(struct pci_dev *pdev, void *arg) > > > > You can make this static I think? > > ... the definition doesn't need building a 2nd time (which hence also > can't be static). Oh, I see. > >> @@ -718,6 +721,11 @@ int pci_add_device(u16 seg, u8 bus, u8 d > >> > >> list_add(&pdev->vf_list, &pf_pdev->vf_list); > >> } > >> + > >> + if ( !pdev->ext_cfg ) > >> + printk(XENLOG_WARNING > >> + "%pp: VF without extended config space?\n", > >> + &pdev->sbdf); > > > > You possibly also want to check that the PF (pf_pdev in this context I > > think) also has ext_cfg == true. > > I don't think so. No extended config space on a PF means no PF in that sense > in the first place, for then there not being any SR-IOV capability. Right, but won't it be possible for Xen to not be aware of the ECAM region for that device, yet the hardware domain somehow managed to enable SR-IOV it and request to register a VF? I'm not saying it's common, but it might be a useful sanity check. > >> @@ -1041,6 +1049,75 @@ enum pdev_type pdev_type(u16 seg, u8 bus > >> return pos ? DEV_TYPE_PCIe_ENDPOINT : DEV_TYPE_PCI; > >> } > >> > >> +void pci_check_extcfg(struct pci_dev *pdev) > >> +{ > >> + unsigned int pos, sig; > >> + > >> + pdev->ext_cfg = false; > > > > I think I would prefer if the ext_cfg field is only modified once Xen > > know the correct value to put there. > > Well, my main point of doing it this way is that the code ends up being a > little easier to follow. Especially without the optimization talked about > near the top, there inevitably will be a window in time where what the > field says is wrong. With the optimization there'll be two main cases: > - MCFG becoming newly available: The field starts out false in this case, > i.e. the write above is a no-op. > - MCFG disappearing (largely hypothetical, I think): The field may start > out true in this case, but will go false unless we have another access > mechanism for extended config space. It then can as well be set to > false as early as possible. Yes, with the optimization to not re-parse existing MMCFGs there's no transient windows where the filed is wrongly set. I also think the registering of MMCFG ares with Xen should be done ahead of the OS attempting to access the config space, and hence it's not possible for there to be in-flight accesses that could see transient invalid pdev->ext_cfg values. > > It would also be nice to detect > > cases where the device has pdev->ext_cfg == true but a new scan makes > > it switch to false. Which would signal something has likely gone very > > wrong, and we should print a warning. > > Why "very wrong"? If Dom0 tells us that MCFG shouldn't be used, there's > nothing "very wrong" with that. It's simply what firmware / ACPI are > telling us. There's also a message printed by `pci_mmcfg_arch_disable()` when the MMCFG is disabled, so likely we don't need a message printed by each device. > >> + /* > >> + * PCI Express to PCI/PCI-X Bridge Specification, rev 1.0, 4.1.4 says that > >> + * when forwarding a type1 configuration request the bridge must check > >> + * that the extended register address field is zero. The bridge is not > >> + * permitted to forward the transactions and must handle it as an > >> + * Unsupported Request. Some bridges do not follow this rule and simply > >> + * drop the extended register bits, resulting in the standard config space > >> + * being aliased, every 256 bytes across the entire configuration space. > >> + * Test for this condition by comparing the first dword of each potential > >> + * alias to the vendor/device ID. > >> + * Known offenders: > >> + * ASM1083/1085 PCIe-to-PCI Reversible Bridge (1b21:1080, rev 01 & 03) > >> + * AMD/ATI SBx00 PCI to PCI Bridge (1002:4384, rev 40) > >> + */ > >> + sig = pci_conf_read32(pdev->sbdf, PCI_VENDOR_ID); > >> + for ( pos = PCI_CFG_SPACE_SIZE; > >> + pos < PCI_CFG_SPACE_EXP_SIZE; pos += PCI_CFG_SPACE_SIZE ) > >> + if ( pci_conf_read32(pdev->sbdf, pos) != sig ) > >> + break; > >> + > >> + if ( pos >= PCI_CFG_SPACE_EXP_SIZE ) > >> + { > >> + printk(XENLOG_WARNING "%pp: extended config space aliases base one\n", > >> + &pdev->sbdf); > > > > Hm, I think this shouldn't be very common as it seems limited to a > > short list of bridges. However every device under such bridge would > > be affected and repeatedly print the message. I wonder whether we > > should make this XENLOG_DEBUG instead, there isn't much the user can > > do to fix it. More a rant than a request though. > > XENLOG_DEBUG feels too weak for indicating a potential problem with a device. > I also don't see us marking bridges to limit the verbosity here, as the > issue may or may not be due to a bridge in between. Imo we can defer thinking > about limiting verbosity here until we see reports of this actually getting > overly verbose. OK, let's try with the current level then. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 29 10:51:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 10:51:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216261.1526184 (Exim 4.92) (envelope-from ) id 1vlPcL-00081C-Fq; Thu, 29 Jan 2026 10:51:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216261.1526184; Thu, 29 Jan 2026 10: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 1vlPcL-000815-DG; Thu, 29 Jan 2026 10:51:17 +0000 Received: by outflank-mailman (input) for mailman id 1216261; Thu, 29 Jan 2026 10:51: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 1vlPcK-00080o-1Q for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 10:51:16 +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 6d6e6a05-fd00-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 11:51:13 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by PH7PR03MB7221.namprd03.prod.outlook.com (2603:10b6:510:240::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Thu, 29 Jan 2026 10:51:10 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.008; Thu, 29 Jan 2026 10: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: 6d6e6a05-fd00-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=k+JHizkAw9AIuKp/GWerpciJxJGWRnzsCtznX6cjSxp+N+YUGhkMtpIBBIMyJ992IRgerSiyj9WmKQgTvBUjjzgtmLT+mMY75GCZT18Vf95ZhGaHrBgrX7vBUTWn3r9QwiRyp87R1MGWfOKEsjJpyGpeRhYRy+k0jrRL1I8P1DJF1CPgXnqhT0cET5Fgt7/DeO8zZK1hP7u1pMzjzxl0KzaGKELYcYv/3P6yWPKnYb0Q37W/IPTCitklA3qqdyTKNvJzWnM9yRXBR+Wz3nUEbSyxw4JEBh1RliOxxZ7E2/XuSbubGHIaUFqTHnGyrBuRNVL8ioEL7jgSaqpE3oo81Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UO/E02JirUS5JmHhGw9XAwa7apOL8OVyB2EcQjRhBPc=; b=GTgqOc8WkrQjlkbaY0xcbsEOoTK1Lt07TrZ9LxYRaigeKch8/F4wMmHyvRKM7hCSRexqpcFIIhqFicQM3moS0M2a8+PK3Uz0C9X9CLSMI0pD2ETXSsHGmzz82EbxgqakzuF8lZ1UKXJqeKE/jrEGSmTRs02CHTCePB3zUuQ3h7Oq9EhYoi9E6OxtSr2kfLQpcUapwcnGKli2RjS2k5+GJwfIx5BdxNDcwJP9iPlJgDYnB2WPRcDzl9QxtX46O9YJ+TI4I2jWwduCIh3UF0YRTu9kql1YRzBXBiNTfl/CkwPCxVGg5Ugxfnhm3enHotFBgHoN41WEZtVtSpRyC7vWXQ== 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=UO/E02JirUS5JmHhGw9XAwa7apOL8OVyB2EcQjRhBPc=; b=WlZtSwDkO82cLynS6IDOiTgXNQWgsGqtbeMys8n4GHIh44dz/OwZkDP3UUa34OHMiluRX6+feT5kWdwLO4WztSkYIuX4WHJIRNITXBl0Aehn8i+lkHcqL8tYWAmnFIE9f4e8IKP/0zgxDWq9QVMKb9gaYvxgd23VHr3g89Bwcj8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 29 Jan 2026 11:51:06 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand Subject: Re: [PATCH v2 4/4] vPCI/DomU: really no ext-caps without extended config space Message-ID: References: <58091dc1-7bda-4536-8200-2d0a5679d4d1@suse.com> <96e90685-3321-4884-8fe7-f083c25ba7ab@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: PA7P264CA0189.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:376::6) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|PH7PR03MB7221:EE_ X-MS-Office365-Filtering-Correlation-Id: 51fbe325-d9b5-462e-1447-08de5f244fe0 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?bXFBZVV5Q2pFODRxdURidXBuODZvVGtPYzZ1RERBU2ZwVlFZbjROd1ZLL1lU?= =?utf-8?B?NUcxaXkyWmxra1Z2d3M4SGJWQTR0ZFVDdmVvekFTajBDaVRsS2NJU2g5RHRt?= =?utf-8?B?TmQ4TXBWa0ZEMU8xZnUyL3JXU1U4QVRUT3paUDZTVHQrMkFyZ2RoR0N5dGhr?= =?utf-8?B?SUVzVUl4QlRxY3oyby9va2Vzby9xckd3VzV1aDNoVXJxQVdwN1pzdkg5VUQy?= =?utf-8?B?bFJPSHNXMlFqSjY0YjF3cEczTzhzRmh3UGtQMW5UVEVXM1RSN1hOUjRnWVhN?= =?utf-8?B?aXBhOGF0bTE4N3doYmoyTW9GS0JkTzRSM3FwTTVMcnJhTlVCb011QnFSbG9m?= =?utf-8?B?Z3h5UUxEWEUzU3V1RlBMMmRXUXc4TVQ2Yk1aWmtneFVrNnpvY01RbitNRzdm?= =?utf-8?B?NTRoRVRiVThENS9kWm5Fazhad0Exc21jRjJaazQ4MDBpWmFJem1xZHlKcHBx?= =?utf-8?B?eWhUWDdaSzhFRGlOeXJ0aXg4ZHFvdERYTjBXZ0haNWxlVVFkellEbnZkSjRD?= =?utf-8?B?RU1GbExNbm0rZHlHd3NJSmVPNUQ3V1BpS3lpMTMwYWN2cW83emxEUldwcWpC?= =?utf-8?B?RnZmKzRPTHJnZjR2ZnowZjl3eWlpUUVhWE9IT3Flcy9UYU05c0ZXOEo5ZTFn?= =?utf-8?B?YmFwVjhaUVZGa0pnVWMrVHRrR0VhRWZIZkhrUkxrWWh1aENJWmlGanErMGE1?= =?utf-8?B?TTN2OW9JejllbHIzRzN4aDhxR2UxZGpYVUEwUTlOdFpXclJ6VmdPWlIwUGN6?= =?utf-8?B?Qmh6Mm0yUmlwaHl2QUYzNlBnN0ZISWl3bFhzdGNQUUFnMEZsYWNSaGVKYXZS?= =?utf-8?B?YS9GR0taTVM0dlAxdzluRFk0UysvaTFtMGxIUlNUSSs2L2VNcDVsakwxSEl0?= =?utf-8?B?eEdnYVNlZnlmRFhxNjB6MzM1WnlSNXE3R2dOQ0RVRkVKcjA2TlJTaGROYTFD?= =?utf-8?B?eWxoa2JqZ1g0ZXc3YWM1VGp0UG5hTHk3Nk9xb09Ld2RkeWxuazJYYmlPRFBm?= =?utf-8?B?YUQyNWxueGtZaHNCckJUSTNESEdmUlU5U2VWclh3RHEzRjBjYW15Q2diSmVF?= =?utf-8?B?aER0cnd4N01aUVlmcHNoMGh4eUFnb2IwQ2tCakxtTEFlOFRUKzhFbGpobzNT?= =?utf-8?B?aE85Wmc2UU1nNlhkTit5L3VjZElPeldNT2VLeCtITEtlejJvcFlBV2lDSlNp?= =?utf-8?B?YkdseFZyVi9ZSmtiVnUwdDBhYVAvQVBIbS9Za2FBQzhzTFhKcTF6cXRweU1R?= =?utf-8?B?OEJodEpkeEtoRjdTa00vaTVaWTM4ZXk2RUw3a3BCdmt3L0gzOWNFMHpEMTJX?= =?utf-8?B?cXN2ckNDNmhMZDRROUVMVVJLazRvdlZRaUVVUTZWbXR2eTVjL0RwYzNZWTlh?= =?utf-8?B?Tk13VjhsREtobGk0bWkybTFsQzlLakNxRS9ITDJ1dGE1ckdkbVVwNVJVU0Zy?= =?utf-8?B?WVhVVVBleURnSFl2NjcxRHpoanQ4YmFRMTZjT3oxSElPY0FiYmpaTnEzczdF?= =?utf-8?B?MXk3TXE0aWZBVGNEbVhMRmtSTks5VHV2eWs5enV0NU9zTXFSMmhHQjlha0tu?= =?utf-8?B?OTZ3bHY2QmpDZTYzNXhkOHcxbENhblpIdjBnbTNsR0pJSERVejdMSlBMcHhV?= =?utf-8?B?anJrVElPK2tXcG1naGxqcE8rTGRNNWNmbkQra1hMbDVCZmJaMk1XSmtlL1pR?= =?utf-8?B?anpzUmQ2V2lid2xyMWNQd09MZEFiRWtjMldmQjc5Y2RUbkFYd3FMZGFTeXFs?= =?utf-8?B?ZFJlUCtvd0xveVZCcDUwakFsSHAwSEwwNFpoRUdMMStCNmxJR01Zanc2bTFT?= =?utf-8?B?M0g3OHBPMWVhcnJpNVNERmczaWhnS0hjWnNFQ2FiWFNLYmJ0aUV4WDAxa0pU?= =?utf-8?B?Wk1FK2N3Z2dDVFNEOENvcG9XNnZLNm5qMkhNZnZvZmphYTRxMGZJMVNpaDlB?= =?utf-8?B?aStEY25KZVE0dnloSml3dVZydmxkQU8vRGtjYmR5TE03SDdndWU3MjVBWm1R?= =?utf-8?B?SlVDcGV1OEJsNnV0anBiN1BseTRybDVnd0tPSnRMRVdjV3AwTDlWbXFOKy9x?= =?utf-8?B?MHE4MEpRb0F1K2VMQS9OdmYrbDd4dUE5dzNkWU83QWVTdkhOYmk4bjUxOThB?= =?utf-8?Q?DBE0=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?S2V5RjhIeGc1aVlQUm9WVGNodlF3bUtyWmxjNTQ0OHpmcC9VMHZROWxDUkRB?= =?utf-8?B?R21ZNFhRR0JqMlEydERBcWhYcXMva1h2bWdlc2ZPZ1lHR2FGRFVFKysvWjJt?= =?utf-8?B?Y0xoQ2h5MEhDbk9JdWxZdnFENHJuZGdFZDlPbXl0ZjZwZ2lzeTlaSzhEUXNi?= =?utf-8?B?dFN6bjRjNCtOWHhveGJyeG9vOHZOMEFRckh5N1J0QmFET3U5WlpPN0ZVOUZT?= =?utf-8?B?clh5b2ZnT0RoQUFnM3h6VTlzeFo3MGY5RFpGd1RCWjZSWmRnckxndHliOHhS?= =?utf-8?B?SW9aS0p5NU91dFptYWtLS3lSaVo1VFdIU2REbDZNTnNIMGlXT3IzV3ZDY0Qx?= =?utf-8?B?MWhGRGxpSmdtb3FNVHorTVBZdUZkVC9XckRmVEdzallxdDBEVlI3emNuRnM1?= =?utf-8?B?WWpqSlBrQld5R2NJR1luNmlwZ3NtbUxjczdZVnBnL2NWZlEzSU9tZVhkNXFN?= =?utf-8?B?NUdsWnBqVWFQZVBjTkU2NmM2eWJUK0NxMVpZK0pwem1JeGRpNnk2b2JFQ0dS?= =?utf-8?B?WVkrN0NCcVR6QUZjN202c1J0K0sxUjFEVFJEelppaXpVeDVqazh0UVY1UzVk?= =?utf-8?B?QS9Sd3BQSjBYR1YxeGswemRWT3JKQ21ZU3pjb1hBaGRJWTNRblJwS0hRTVVE?= =?utf-8?B?TWFZcWRqVGQrN3YrOXpvRTRzRDRMRHNaTWY4ZzkvOXFJTFJNRzcxZFhMUjQ5?= =?utf-8?B?Ti9TaHl5RTR4TVFBaTRtN3MxaUQzZlNJak1sL1ZHeGV0UU43d3NGbHRreXlo?= =?utf-8?B?dGxpTW05MldkdUQzLzJ6UWZpelVEa2diTFloL1p0WjFaaXZwMjk1a0NxSXJ2?= =?utf-8?B?SzI3RXgzSVdiTFV6blJndEpCZWpzK3JpdW1tcHRKR2NmZ2pjWmVUSWxoZGwr?= =?utf-8?B?Q3ZQUkhkTEd2NHoyRFl2cnNCVVpjcmZ1YndTZWV2dzlxcHJHNlJ0aTNDcU1n?= =?utf-8?B?VDJuT3hzaFRORC8vdG9Xb2paQm5BOWo0QmdiOFZmT3ZXU0hGUlRGdnppVVYy?= =?utf-8?B?djdseGVONUVnYkdvWkxlekwrYnNPSHByQ2p3UWcvWG9FMVZ1YlpublpLeUU5?= =?utf-8?B?WGlEQ0U2ZGpSbTNnS2lUVWh4dHBlanNhL2dmWlVqS1Z5bHVIMGQ4Ty95RUR5?= =?utf-8?B?VGg5a3ZMcGNIcUExRWVIMWdtSVZ5VVJ0ZTZxNVlzTGJZTEVaSEFMQ3ZvOFpO?= =?utf-8?B?azE0Mys5WkF6ZGpBeWpLa3BETThDTFg2M0FlVk1vMUNpL2lKYVJEOHcyQUVr?= =?utf-8?B?VUZiQTJqOTJVbzZKblo2V3E1dlZMU201MzVUSitpMnhvUE5wSVIxbnZGRVJP?= =?utf-8?B?aExzcTMwOXFEaTRyaUdVeGFBVU5iVUlBUVd4Yzk5QzdzYys0aXU4WXhQTFg4?= =?utf-8?B?cTIvYURRdVN0UzFCS3B6dGMvVnV0NWhyRjdQdEptM0J1UWhXdDh2MExSSTB1?= =?utf-8?B?NEplekNlcFVJZ2QxWDk1ams0ZVgwbGxLN3poYlB5NVdjY2ZKOCtQNGgrREFK?= =?utf-8?B?ZG9tdUJxTzNXTTkzMnhIV2JZbmR2bWtHT05hL1gwUS9KTDJSN3V4Y0kwZFJT?= =?utf-8?B?OGcwKzFEUVlEWWgzRzBOZytWTWUzb3FMaUlKcVRZWnVDcXErYW8xOU90S1lG?= =?utf-8?B?ZDNvMFQrejUvNHFRbElIRmg5WnFicEM4ckljeXRYOFJmcDQzb2VtemRteVQ0?= =?utf-8?B?aEg1MjV6UjN5ZVFucUNwY1N0ajVpaCtTMUdsZUxlRWVzVjFoWEVsaFhFZUdO?= =?utf-8?B?MjZQKzNCYVd6ZTJIZUlrNFJ5RnJ4eDI4TEhIZDU0bWZkSGFUaFh2UXZualZ5?= =?utf-8?B?L3lKdnVqWlB0d1Y1YVVaUE0wbFJPVm5qOU9GQXV0QkcvQ3VSRURQcS9vbWxy?= =?utf-8?B?MVN5c3NzZXRNR3JEcXNwQk5BZUhROTcvc2RaWnNGVHYvUDNEeGpmNVpFKzhX?= =?utf-8?B?K3lGbERwc2gvZUxkdVRhaHpKZllRdDlIbjZEL01mZnU2VlhYNWgvMTRtUUU1?= =?utf-8?B?M0Y2aW1HOTM1T2orc3ByZlF4UmpZU0NUVGdTcGU4TE9wQW9PMlh3S0hmMEJV?= =?utf-8?B?aHJiOVZKTXE2cjVSVkY4cnRnN2dDdU5aeDZjUWZpbjJlMHp5M0ZyK1B4TXRa?= =?utf-8?B?TmgrcG5RSzhnUzgwamRJbWRQZkxLU1RIdUJWeTVoUXVseFNpcVd4ZXBtbVhS?= =?utf-8?B?SERmcWlyQ2wzU2VaeW8xUzdnTkFYMlpORnR6Y3l6Ykp0bENPSmg1NS84OWd1?= =?utf-8?B?KzNBbStVVXVrSU43OGhndFRsZ1oyYnNPcTU3ZElnZU03bVFZYWVLNnNWSnZI?= =?utf-8?B?U3ExblllMmlEdGRvNVp5b1NveHoxYmRsUTFSNCt3ZjNYa1Zmb0ZYQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 51fbe325-d9b5-462e-1447-08de5f244fe0 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2026 10:51:09.7902 (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: ipf8kSVPGfiQU9Cqj1ZxKdBoOLi+P8ci8JgSua54gDNzlQglLaoxIiLibKYEXVxo8bb/HYznagvd0KwAx1oNDQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR03MB7221 On Thu, Jan 29, 2026 at 11:08:22AM +0100, Jan Beulich wrote: > On 29.01.2026 10:19, Roger Pau Monné wrote: > > On Mon, Jan 19, 2026 at 03:48:01PM +0100, Jan Beulich wrote: > >> --- a/xen/drivers/vpci/header.c > >> +++ b/xen/drivers/vpci/header.c > >> @@ -830,9 +830,14 @@ static int vpci_init_ext_capability_list > >> unsigned int pos = PCI_CFG_SPACE_SIZE; > >> > >> if ( !is_hardware_domain(pdev->domain) ) > >> + { > >> + if ( !pdev->ext_cfg ) > >> + return 0; > > > > Don't you want to possibly put this as a top-level check, so if > > there's no extended config space we avoid doing the PCI_CFG_SPACE_SIZE > > read for dom0 also? > > Hmm, yes, didn't think about that. That'll mean dropping the > "if ( pos != PCI_CFG_SPACE_SIZE )" from the body of the > "if ( header == 0xffffffffU )" then, i.e. the printk() there becoming > unconditional. It may also mean dropping "DomU" from the subject. I've also wondered whether we want to short-circuit vpci_{read,write} accesses if the device doesn't have extended cfg, for domUs to be on the safe side. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 29 10:53:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 10:53:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216274.1526195 (Exim 4.92) (envelope-from ) id 1vlPdz-00008J-SE; Thu, 29 Jan 2026 10:52:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216274.1526195; Thu, 29 Jan 2026 10:52:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlPdz-000089-PN; Thu, 29 Jan 2026 10:52:59 +0000 Received: by outflank-mailman (input) for mailman id 1216274; Thu, 29 Jan 2026 10:52:58 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlPdy-00007y-8g for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 10:52:58 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ab08b23b-fd00-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 11:52:56 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DS0PR03MB8319.namprd03.prod.outlook.com (2603:10b6:8:297::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.12; Thu, 29 Jan 2026 10:52:53 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.008; Thu, 29 Jan 2026 10:52: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: ab08b23b-fd00-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=dnjRUA08pKrPG0QsbHQn1Gy5dbymAdpy9eO8ree8T4+Xvy5uk46rbb2NWsoSvc7DcBOUAvRyTWEavk7m2jw775Mm5edle+mC/dtw6pIcNW8sqXkWQCeWi56NWXbrmO6mS/5X0YVr+KITx0FLbmB8eHGFwaS8T9opd8jFIslFzEZMJ8P6t2PDZ65ev5fmYpngQoeuHYQRdUY91Y4l9vM16yjZ/DAqmTvTxd7WM/t4T/ikNWD0sAjpZKx3yYJ5XmldxIWb0AYHUpvttf4JDl9DdK7GofZjdgV/uhVTh1+/gYAvXP+TNNYCqjbjmJXCEC+mOxRWRxtAD0KEeU4HD99LtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2hgqdeqKcVvh9KCWygOPUP0xc+0JkV8lV4SQ9b0lPlE=; b=KlO3mwskS6v6iRuhzjKLnOat6WYfKX+zLFODTXxvMsV0hnr3S6SQOyb7Ai3D7q2wHVAnuc9CKkYmgkN7xIEC+l5Nr+Q6hCyYB5JPJ9zEOWv8U5OklDee29EoMWbskjuMe/WTb1Cf5fhn35yE3+es8vB4k5HKT5q9goTAPvp+/4EFhwCL4wdZu4+LJPTm5Z2Y+nR4Vh7WellJK/tNHK5dqGTrv8lrs+M7pyr2tK6fgYDCD074sbFXXqKe4Bi4eDmz7UlX9p/g+s+HiWNnjrQIL2MmHU9WidScsLJPhb0sEVeWj46aWSNMfE2VK0PRG1uidXnd6YA5hJD0IOXJr1bLUg== 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=2hgqdeqKcVvh9KCWygOPUP0xc+0JkV8lV4SQ9b0lPlE=; b=U93D5ovFU2/YMV+2d5F0t8JjdurvjG3RqOhQcf5ZBZH6xvXMD7PTvBDkXTd2JK5WV3JNWiPMKANelc6j9s4D5x+MYLW98Et+z0+tdStiSfVP/qeq2kHTOhuUJbCOa1Yi1mF7crdFfQSQshL52rwOl6x2HaGDef7C0z11FMqomuc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 29 Jan 2026 11:52:48 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [PATCH v4 2/3] xen/mm: allow deferred scrub of physmap populate allocated pages Message-ID: References: <20260128120339.47373-1-roger.pau@citrix.com> <20260128120339.47373-3-roger.pau@citrix.com> <6d7b74b6-1bab-427d-aa14-321f4761d9a0@suse.com> <9d3d4a0f-5ff0-4a90-b624-fc99b23efbf7@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9d3d4a0f-5ff0-4a90-b624-fc99b23efbf7@suse.com> X-ClientProxiedBy: PR1P264CA0184.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:344::12) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DS0PR03MB8319:EE_ X-MS-Office365-Filtering-Correlation-Id: 7e074fad-64b5-4a5c-1312-08de5f248d3b 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?R1Jha1FKK3EvTlE3d1pFSFdXUXp4eU16VjVzVHgwNjNXc2N2ZkxIYktrM0o4?= =?utf-8?B?UVYxZ0pjK29ROWVJdXpKMnhDUThONzZmaW9EOUh4SEoxemY2U0dRYmVSOFM3?= =?utf-8?B?Z2tNVE9INkp1UDJ6TmQ4TDR3SzlNdE9jSHZxYXBLWkREYnl6Wmdxb2hzTDUv?= =?utf-8?B?UEdzRlhWTU5EeVRiRy92eUlxSjU3ejBORGhGRHlnYU5xMVdrOHVxSkFVVGtW?= =?utf-8?B?akFPUkZIMHVuRllQcXc0ZHZWMVBweVlXbDNaNy9pbWRXUGxvYWdkaExvZHVI?= =?utf-8?B?eGpra3BlMWJiMFhQMlhiNjNXc2UvY2dXTGFrNkxETmFmWGhQMjlWVlhtWTRH?= =?utf-8?B?RmZ6M0F4Vk14Z0trVFVKTVlyZy9MN1ArNk9wMUh3bGJweHFCdVhQUjdYZHNX?= =?utf-8?B?bWpHajAyT1BGMTY2eEJGQytYcG1RYWh3dS83dHNYRm5yOU1HMU43bjRnMkQv?= =?utf-8?B?akdyWlZTNGNsZS84QVR4VDh1amNjekpidVpubFIvL05IZUE2Zk43ZVFqTWRO?= =?utf-8?B?UDRzbUtWallKeTBkREdEWjZ1NndWSzdPUUxMdFVnTXNYN0l4NkFZN3pkR3BD?= =?utf-8?B?UWhFdjcvME4yeTVmTFBRY3dyS1dQblNEU0x4MWR1eHdydHlNdWVScVNyZzda?= =?utf-8?B?UFg2cG1zcDQ2dUFpa2Q3NTBoYnowYzc2Z21pV0RGeVFwNjl2YVRzbVVPbXR1?= =?utf-8?B?UVdvTXNZSHF5aERIbDJrVWRveUhIalZsOG41cXFhREIwVjhHQ09EUHdtb2tD?= =?utf-8?B?R2J6b2NsOEIyczZPUHVBUmZCWEFxNUN2YlZscWt4d1VRRDI4dUNvN3BOakN3?= =?utf-8?B?N1Jhd2NSQXpJL2ZuK095cDM2VTBKSzNMMnFjem9pQ05SR2RNYjlDb0JhZHR2?= =?utf-8?B?RDdtRTlNTHlGaEpVL1hvMzJpaWJnVmpoSFQwdy93L3UwaE1pVWF1d0k2R3hD?= =?utf-8?B?R2pKaWJqOTRvcjlBODFhVWxvbmJLcVE2WlU4K29hVXZ4d09EdmFWdXlKTmNp?= =?utf-8?B?bTZNY1hlQzhqQlM5TUxwdk5YY1RNQXZSNGwyTmVwd0NvOUtScG1NUGt4enpM?= =?utf-8?B?M01aM3dYeXNta1JWTi94dUtCZGh2eE1tMGgvZWJ6Y2c2YkIva3dKQWQzR3R0?= =?utf-8?B?YjNBb2hiU3luMnQ2OXVGaG5GcjQwTGtQZlNrcTM4WVJCQ3pLZHdnMGRabWtE?= =?utf-8?B?Y0JxWG5WUWI5bjdJNE03akFQa0JCTFVHZFAvV0JoSnpOS213OUZHWDJlSWdS?= =?utf-8?B?dXE3ZFZYTVhXbTZVRkxRT3c3WkhpWi92Q0xVREtESkMwcEh5UnZSSzhBN2px?= =?utf-8?B?bEQzQko1UHljcFFyR29qaEVRdHdnMlNEbDVvVklVN2grZitCaVdJdWNLUGVj?= =?utf-8?B?UjlkN1B0QzNlTUxKaGpBTEMvN01KUmxYYVhlZlZqWjA4aTVQYm95RVFOdVJv?= =?utf-8?B?Vi9NUDlhN2RtcDF5ZTlEQkFzMTcvYlpabnZzTDBpN294T0JzMzV0cHFkNXlB?= =?utf-8?B?eVB5RnlBLzVDSVJxM29ROGErNkNXUHp2bjNpc2s1SXlCeDEralFYZkxROWpH?= =?utf-8?B?TWtMbGVXQzNsU3MxaXZrdXExeDYvYXExUGxxVzVQUUtOSU9rN2NRT2xqcXZP?= =?utf-8?B?ZnZKc1FkV2F5NFlUeXE3TmRmSGwvRG1oWkZPdkZWT2dNMXk1RzNXYXJpSTF4?= =?utf-8?B?ckZTZ2F6d1MwaFZQTkJCYmUxNnY0VC91MUtUMzM2S2wrVEVBTUNOcURzM2NC?= =?utf-8?B?cUxLYVFBVmNiYjlyeTFhVFJJcjRSU0ova2FiK1BVc3lITGpsM1Z1b1l5Szcy?= =?utf-8?B?dDRxb1FVSFhXeDI4TzVTV2t1UG9nZnpIcVVoNEoxS1FtRXVVdDJyZ1k1ZnRz?= =?utf-8?B?cTlaMzV6YXd4NHFrUzFjSEs4YUppOVI1YVJSa2VUK0ZETE83ZjhiNDJGVGVt?= =?utf-8?B?NmxYa3ArMmJwMk9UdXFwRUY1VnFPMTB0RXc5ZE5za3RkakxvUkZyMFpGc0E1?= =?utf-8?B?em9DQXR2QVhBNzErd3VUT2xUOG1janFPM3FrckNrVXdWaXpwV3FWbi9TWHpv?= =?utf-8?B?aGo4M0kyd3B3b2wxQU00SnhYWms5Vmp1UnhDaWlvYTcrTnkyMUpmQkF3N1V0?= =?utf-8?Q?KIQU=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MU04djRLNER5SERic2VLWlowMzJYZjNzaHdHOUY4NERid0djeGhvcXAwRmZF?= =?utf-8?B?cnBQS2RzWHFlMDg1S3JNdVRtc0xmdzF5emp0QzJRdXl5K2p6bDhpNHpCSzVB?= =?utf-8?B?WDJ1NDIwT0lFRHY1Z3NJd3VibE9oeGR4MWpRZzlTWWljeDNWQWVCdytVMEpk?= =?utf-8?B?aHZYdTJMSmhpaEh3RXgvZXAzdE5PajFjNnBkV1JUNU5CM2wzUHdHK3FDWXNS?= =?utf-8?B?RzlCc1BHQVJ0SU9MRU1zelhwdDNsNDVGQjMvQnFtQUVjdkgycFNWS3RFSTNX?= =?utf-8?B?NUpzcWo4VUZPWkJBWi96cUh2ZFJtN0pkWldjK2l5VHRlbXlrdC91dG9va21D?= =?utf-8?B?ZEEzb0E2dVZMRGlyN0JMU2h4eVZZM09KTDMwWWhvWUNNRnVDTkR4VTIvTDUx?= =?utf-8?B?Q2VhOWVSL0xjVFVVRUppbUNpN2U0TDdHTEZmRVRidmVvWm5sZjUrR2lyMitl?= =?utf-8?B?bWw1Zlppdmx2ZVk1Ymcvcjl6TjVjVkdPRHpnbnN1U1VLWEJUbktCejlXWG9h?= =?utf-8?B?c3VhTkF4VWk2SHVmTlFaUzIwLzNEMEJDeDV0aW5qVW5ObzdhZnlyR3ZxVUs2?= =?utf-8?B?ZDBTT3pzYWJ1c3RaVmU1Vi9wcEh4ZjFvUkx5NkQwM3VSTGlJWmpZRnJ5Z21V?= =?utf-8?B?QXZWWjVablNGWkVwbWJLVlNuK0Z6S2V0bm0vYWJoZ3JPZzlZZXZ2TUQxVlpw?= =?utf-8?B?WE9uRVo2ekU5WCtCbHhqTWd0RFY0M01aYnRLblR6dTRiWHY4TWROU2NyY1pH?= =?utf-8?B?T1k0VnR4b0YzVlM5bWdNdmV5Zndqenp4UVJpMlJ5MWNvU2pET05zajZXMnY4?= =?utf-8?B?NDVjSGI0ZjRMYzRzTGdTdzNWcWRhUGkvdk51Wnp4bHVzSlN4SnBYcDNGTjg1?= =?utf-8?B?emhkOTIrOHlsRlZtM2VjcHc2OWdpM2N5SUQyeTJQaVBaUXVtR1RJK2dOa3cz?= =?utf-8?B?YWVhTzZ0aC85d3ZEMy9HR0tTZTNQTitHbGRKUHZWSm9kbUJIcXFSemh0RGFK?= =?utf-8?B?UVA3QVpVbFJSZ2dpcy9yVVFFajhKVU00UjJNR3RsOTRaZkFrVmxtK05HRHk5?= =?utf-8?B?M0tQT1oxWVZjNkNVL1hFNmQ5cld3Zklob0VaaCtKemZpQUxoMXNTNkhEWHF1?= =?utf-8?B?RHorWjdKMDcrR0xENHZMRHh5amVLa1N4SmMrK3RkQjZoWjd3dG5LMEw0TEVk?= =?utf-8?B?ZVlwUHZGNitQQWlCdWVEMEc4L3hNVUpzQXhnYU9jK2o1MHNpb05KeEtSNzJG?= =?utf-8?B?SzduVStrMXV2WEdzb1FTMHViMHhEYzk3a3Y3amdEYk5ncURkQ09uTUk2aFZL?= =?utf-8?B?U2NlMURzai9GYXBaUUVtc0o1MjBMQnEyMENaRERvUU51Ty9BQVpmK2YxZnJi?= =?utf-8?B?Y1RPc0xxTGJEQi9Jclo5Nks1c3FhdTNuRE0yd1piS0UyVFp2RXhvUUQ1NTVr?= =?utf-8?B?NXBxdkE2dzd0ZWlPeklpMUh3a3F1TU9sYWtaTWhzMys3ZzRCNU4vaDJQWGI3?= =?utf-8?B?YlB0aTdCcko2dzNhOTNsTS96L0xwWmorMUExb0tQVS9RamdHOG1FQU5VaXc5?= =?utf-8?B?dSt3Ty9NeklXS1B1TVZmd3VIdzVyY3JERGNDeDNVbWI0Vjdtem5VL051WjRw?= =?utf-8?B?VDNaYXE3K3R6MW1BUXB1aGZOd0JsUXJabm9VUHYvVWhhNE81clJhcGVJVXor?= =?utf-8?B?MG1lVEtUcU51blo5SEswOWZCZGc5bUxCc2lTWGxGbkJEM29tZDRBQ0NoVUhL?= =?utf-8?B?N0tsSGJua1YvaVVmdEFlWFhrbnBpWmsvUUkrYytwQ0l2TjZSUlozUjBiSUNH?= =?utf-8?B?dHJtZlFOQ1ZlVTlDdkhWQ2RvNEsyUVZHZmJKM3FuN3dxaStoV01LY1lIM2hV?= =?utf-8?B?M2NFd1FpVUt2b2RDREVEYlNUa3pyYkwyaElmTWpnSGxwb2FjckxsQzQvLzRs?= =?utf-8?B?UUJsazZEbDZVeWhkeVg0bDVVdjhSbWF1MWMzVmx1ZVprT2s4Y1ZBcW9ZR2s0?= =?utf-8?B?OFJOWDl5Z2ZlMUo5UXZVOVpJcTRSRG44amtWR1pSb1NqRnFJa1VlRkErSy9B?= =?utf-8?B?blFRU3ZhVkloWUU1Szd6UnR0Njg0ZDZPYjYzUU92Uk5NU2p2bkZZM1lJR1h1?= =?utf-8?B?NDI1RFJJQndwSWdOd09vazVOamVhNTIrL0JJclpIV1JhZGhyNHp3SHN6aDdW?= =?utf-8?B?RS9QMFlRTzdZS2w5N2VyTlRyNnozUGo1NmtEaGFSZ3VPbHBTc3FIdUxjZHpu?= =?utf-8?B?aWpBZDF6QTd0SE1DS3dMK3UvRk5QNzlJY3R6c1ZFRURJbS9uaFJ6VUY1U3hX?= =?utf-8?B?dzhtZTVpQWU2WkdPb1E3S2FyUXBPd3c3UVhLNksyVlU0dUhvYzNEdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7e074fad-64b5-4a5c-1312-08de5f248d3b X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2026 10:52:52.8100 (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: ee9jDs++JoRcirk0+HhJFRcJRuGmltgDPDHJ/fxBjnfQaft3EJ7g6ubFcyA9HZN8ByurKDylakgPwBBGbY0hkA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR03MB8319 On Thu, Jan 29, 2026 at 08:53:05AM +0100, Jan Beulich wrote: > On 28.01.2026 20:06, Roger Pau Monné wrote: > > On Wed, Jan 28, 2026 at 03:46:04PM +0100, Jan Beulich wrote: > >> On 28.01.2026 13:03, Roger Pau Monne wrote: > >>> @@ -275,7 +339,18 @@ static void populate_physmap(struct memop_args *a) > >>> } > >>> else > >>> { > >>> - page = alloc_domheap_pages(d, a->extent_order, a->memflags); > >>> + unsigned int scrub_start = 0; > >>> + nodeid_t node = > >>> + (a->memflags & MEMF_exact_node) ? MEMF_get_node(a->memflags) > >>> + : NUMA_NO_NODE; > >>> + > >>> + page = get_stashed_allocation(d, a->extent_order, node, > >>> + &scrub_start); > >>> + > >>> + if ( !page ) > >>> + page = alloc_domheap_pages(d, a->extent_order, > >>> + a->memflags | (d->creation_finished ? 0 > >>> + : MEMF_no_scrub)); > >> > >> I fear there's a more basic issue here that so far we didn't pay attention to: > >> alloc_domheap_pages() is what invokes assign_page(), which in turn resets > >> ->count_info for each of the pages. This reset includes setting PGC_allocated, > >> which ... > >> > >>> @@ -286,6 +361,30 @@ static void populate_physmap(struct memop_args *a) > >>> goto out; > >>> } > >>> > >>> + if ( !d->creation_finished ) > >>> + { > >>> + unsigned int dirty_cnt = 0; > >>> + > >>> + /* Check if there's anything to scrub. */ > >>> + for ( j = scrub_start; j < (1U << a->extent_order); j++ ) > >>> + { > >>> + if ( !test_and_clear_bit(_PGC_need_scrub, > >>> + &page[j].count_info) ) > >>> + continue; > >> > >> ... means we will now scrub every page in the block, not just those which weren't > >> scrubbed yet, and we end up clearing PGC_allocated. All because of PGC_need_scrub > >> aliasing PGC_allocated. I wonder how this didn't end up screwing any testing you > >> surely will have done. Or maybe I'm completely off here? > > > > Thanks for spotting this! No, I didn't see any issues. I don't see > > any check for PGC_allocated in free_domheap_pages(), which could > > explain the lack of failures? > > Maybe. PGC_allocated consumes a page ref, so I would have expected accounting > issues. > > > I will have to allocate with MEMF_no_owner and then do the > > assign_pages() call from populate_physmap() after the scrubbing is > > done. Maybe that would work. Memory allocated using MEMF_no_owner > > still consumes the claim pool if a domain parameter is passed to > > alloc_heap_pages(). > > Technically this looks like it might work, but it's feeling as if this was > getting increasingly fragile. I'm also not quite sure whether MEMF_no_owner > allocations should consume claimed pages. Imo there are arguments both in > favor and against such behavior. > > We may want to explore the alternative of un-aliasing the two PGC_*. I expected the PGC_ bits would be all consumed, but I see there's a range that are still empty, so it might indeed be easier to remove the alias. Let me give that a try. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 29 11:29:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 11:29:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216288.1526205 (Exim 4.92) (envelope-from ) id 1vlQDc-0004fG-Fd; Thu, 29 Jan 2026 11:29:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216288.1526205; Thu, 29 Jan 2026 11:29:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlQDc-0004f9-CU; Thu, 29 Jan 2026 11:29:48 +0000 Received: by outflank-mailman (input) for mailman id 1216288; Thu, 29 Jan 2026 11:29: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 1vlQDb-0004eb-HF for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 11:29:47 +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 cfafb916-fd05-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 12:29:46 +0100 (CET) Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-59b7c2614f7so800373e87.3 for ; Thu, 29 Jan 2026 03:29:45 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cfafb916-fd05-11f0-b160-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; t=1769686184; cv=none; d=google.com; s=arc-20240605; b=EYF3qke2S/kTl41PFgRyPtTC8howcoyRTUnOe5yRGvYe9D8R0reqlzMJS9LQ89g82S nYwvaAtYyAgQEh59IS1ElniLrZ7eoLO3JgMgcIksOZKg3NQ0bBFFYJhSw6BI3MyZig9y BuqexAKIOfQQt/UCYUW//GiJM1ejXwJy+vNU+qfsanXpXnhODkrTGI9NvSY5xTxiEZp2 y8cZ2LrPKppZm4hRhKyQJ0alPk/t1pXNOSP7ipnGfrK0+6ogMuwYs5BAv2r+L447381b osEY78ktt/FuB9UK1+dZc3Gp4Xei6nl34N/OBK63P6IUsFtHY86whJBzUstZyrOoy+0u 5hvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=7ypZjUe8MnGLUz+5PA3E/bqEPtrbXT3gUW2pEGL1awI=; fh=6Yp745r9geSuA1DCXNlATJA3FpDPscZxI67TajJvjq8=; b=MEfrvKqXGggXgfCnwLSEXnN/619YnNb8goOischhogzg6cv+2qrJzJEf9KuJ215lK9 m26j5SpujqDuSErMln7PG6fzjgSm3Dc21Zx5pK/fjLutceQGd3o442Noo/Iq3tTjb9SC OnMT8bpVq0SQOzsx+2k6MYHWzZe6CvzY/1YKMCl3Blg5HkbWjoBY3HNe8zs6f/9JfcNJ Z0pBXrPHZ1BAYgWqdf4HvOPnA6rAE4uGgdL/n70SZHaUYPiaShP0lV5VyGWz35RDMsFb lLPzmkReOzVjdwWZ5xn/pKMSHPeRttT5atGYmZBpk7TnXy3dYH12mVZDK+bLtBcMgor8 DzSQ==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769686184; x=1770290984; 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=7ypZjUe8MnGLUz+5PA3E/bqEPtrbXT3gUW2pEGL1awI=; b=kTicKLKAEJrYbVhlmwcxKaeFAto89RH6+4wRwQZNcc37iekNDg0ySjiTPyYIB2/HpI 8axCXAbynHUDAcCpFNjRgnSQwXnr6RsNGUBHlIpDI4n/Q+VvDYoDcKV2+ZETPmsbPhh/ 8uAAuXxDDaHP+9FLh4RlqSwpk8jkkQT1MAPTRC9ON1WunaMY5FSB1xmE1wJsRl9vthqS fG9M+EpHS8K2zTJ87V0ymDL/1t3UPWo/g4wAIXU0KdVhobq2j77/YV8B48zEvAmFn6c8 WK7qKpWmPBByoYDhcbXFSMWadNi8U9yMcuoXoc3NpYVAz23zkgRHSrY9yE6RlPJb87Pf u9PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769686184; x=1770290984; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=7ypZjUe8MnGLUz+5PA3E/bqEPtrbXT3gUW2pEGL1awI=; b=Da9x5KFaE5OcqE/8yXO2ZAObBDJDUi6tXIzguqkgj8C/qjGD18vZtx1O73zuRzhdGm JKcyGTyBdQPVLZKveXdt6wW28A5XPYPjDinnKr1E0xSEhiNUi4L+hlTT7bEDhypyiaS4 DXO/Cp8bgMfnrDiLCv6zns0E4QFK2GIP6C2TEBYGXM8HTMFg1BG/6JRD+zjuZoJ+MEtM u1m+0PaGqfR2m7U9buGdSGueP+ad/7NowOXnAsIX+EsxjiEuEUytAOgJMnYCOPvSJ6gj ySZGpE1ajfGfwSypMiy0XgnOk+kgNKZoiQoEsGFPXErihjnG6buPFyZfTSg4CnJbwf7m 9qiQ== X-Gm-Message-State: AOJu0Yy4457gCMh6BE8i/2xgOIVZp0mzNIxlr8LI/r4ucogyYVaB8Sz8 nThhworVxr3x1pOKExpA7s63EN/3lF/zz/UD1PHwKsreoUMQdb5HFEDyl6CMi61vnsuPImVL30U R1TDZoNcrZqDcDWXeHoM7T+JvQ2nMPjY= X-Gm-Gg: AZuq6aJNHq+rsIah9GtAiMej+nOtkI43RCdW8xlARFnvbrSJYVy4cnvK76E0/6q0Oux JulcOCC9jgHW3dshHuFL963eQozdVEm+/loVy2DT4J7li9MUNH0ZDq0sH3UJ7y2RahXPrKDi+Ft aVVIvF10N3ztNO4vca/18S+HXCOvNqRJi5Gd9kRlZH5PSKkdtMCYN+/+kHqB7XHiM50y0YrRqEH 5SfM3wIRJze7Odcudbdp8SD4xrp9RQhmT51Xxgu6BANMA5GjMSaVdD/M0Mr/qkZ82v87A== X-Received: by 2002:a05:6512:3f0d:b0:59b:b3fd:ea24 with SMTP id 2adb3069b0e04-59e04030a09mr3801362e87.44.1769686184198; Thu, 29 Jan 2026 03:29:44 -0800 (PST) MIME-Version: 1.0 References: <436a0405a9482dadce7f7cdb1e9721ee461f26a7.1768219676.git.mykola_kvach@epam.com> In-Reply-To: From: Mykola Kvach Date: Thu, 29 Jan 2026 13:29:32 +0200 X-Gm-Features: AZwV_Qh7JX39bholpi_J8mkD3OIcxepOaxLGO9o3_XhZCyh6pcmYDIoYz0wX8Yc Message-ID: Subject: Re: [PATCH] xen/arm: ignore spurious interrupts from virtual timer 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 Mon, Jan 12, 2026 at 4:04=E2=80=AFPM Julien Grall wrote= : > > Hi, > > On 12/01/2026 12:50, Mykola Kvach wrote: > > From: Mykola Kvach > > > > If a spurious virtual timer interrupt occurs (i.e. the interrupt fires > > but CNTV_CTL_EL0 does not report it as pending), Xen masks the virtual > > timer and injects the vtimer IRQ into the guest. For Linux guests, the > > timer interrupt is unmasked only after programming a new CVAL value fro= m > > the timer interrupt handler. When the interrupt is not reported as > > pending, the handler can skip that programming step, leaving the timer > > masked and stalling the affected CPU. > > I guess this is happening if Linux is trying to modify CVAL with the > local interrupt masked? CVAL/TVAL programming in Linux is indeed done with local IRQs disabled. The virtual timer IRQ handler runs in hardirq context with local IRQs disabled. However, the failure here is not "Linux modifies CVAL while IRQs are masked". The problematic case is that Xen injects a vtimer IRQ while the architectural state already says it is *not pending* (CNTV_CTL_EL0 has ISTATUS=3D0, and CNTV_TVAL_EL0 is positive). In my Xen trace the injection happens with ctl=3D0x1 and cntv_tval=3D0xf320, yet Xen still injects vIRQ 2= 7. When Linux receives such an injected interrupt, it reads ISTATUS=3D0 and treats it as spurious, so it skips the normal re-arm path that would program a new CVAL and leave the timer enabled. If Xen masked the vtimer output before injection, it can remain masked, and the CPU stops getting timer events. So local IRQ masking is expected in Linux; the root cause is injecting when ISTATUS is already 0. To add more data points, here is a partial log from the stuck case. In my instrumentation: - "snap ... index 0" is from leave_hypervisor_to_guest (Xen->guest) - "snap ... index 1" is from enter_hypervisor_from_guest (guest->Xen) We do a normal timer expiry/injection path (vtimer: virt timer expired, then vgic_inject_irq), return to the guest (snap index 0), and later re-enter Xen (snap index 1). The issue is that on a subsequent entry from the guest, Xen hits vtimer_interrupt with CNTV_CTL_EL0=3D0x1 and CNTV_TVAL_EL0 positive, but still injects vIRQ 27: [513559989049] CPU1: snap: vcpu d1v0 index 0 now 513559988779 seq 4008771 pcpu 1 time ctl 1 cval 542163190853 cntvct 542159034528 [513559989679] CPU1: [1] b0a0020200000202 [513559989964] CPU1: [513559995049] CPU1: snap: vcpu d1v0 index 1 now 513559994374 seq 4008771 pcpu 1 time ctl 1 cval 542159103072 cntvct 542159040944 [513559999009] CPU1: virt_timer_save: vcpu d1v0 ctl=3D0x1 cval=3D0x7e3b336460 cntvct=3D0x7e3b328200 [513559999519] CPU1: virt_timer_save: setting timer for vcpu d1v0 513560053249 513559999459 [513560054630] CPU1: vtimer: virt timer expired for vcpu d1v0 ctl 0 cval 542159103072 cntvct 542159104512 [513560055185] CPU1: vgic_inject_irq: vcpu d1v0 virq 27 [513560056100] CPU1: VCPU unblock d1v0 pause 1 poll_evtchn 0 [513560057105] CPU1: VCPU wake d1v0 [513560058710] CPU1: virt_timer_restore: vcpu d1v0 ctl=3D0x3 cval=3D0x7e3b336460 CPU 1 status 1 expires=3D513560053249 now 513560058650 cntvct=3D0x7e3b337b00 [513560061050] CPU1: snap: vcpu d1v0 index 0 now 513560060795 seq 4008772 pcpu 1 time ctl 7 cval 542159103072 cntvct 542159111344 [513560061755] CPU1: [0] 50a000000000001b [513560062025] CPU1: [513560067785] CPU1: snap: vcpu d1v0 index 1 now 513560067185 seq 4008772 pcpu 1 time ctl 1 cval 542159180688 cntvct 542159118528 [513560068415] CPU1: [513560070215] CPU1: WFI blocking d1v0 [513560072180] CPU1: virt_timer_save: vcpu d1v0 ctl=3D0x1 cval=3D0x7e3b349390 cntvct=3D0x7e3b33b2e0 [513560072690] CPU1: virt_timer_save: setting timer for vcpu d1v0 513560126014 513560072630 [513560127275] CPU1: vtimer: virt timer expired for vcpu d1v0 ctl 0 cval 542159180688 cntvct 542159181984 [513560128250] CPU1: vgic_inject_irq: vcpu d1v0 virq 27 [513560132015] CPU1: virt_timer_restore: vcpu d1v0 ctl=3D0x3 cval=3D0x7e3b349390 CPU 1 status 1 expires=3D513560126014 now 513560131955 cntvct=3D0x7e3b34ac70 [513560134340] CPU1: snap: vcpu d1v0 index 0 now 513560134070 seq 4008773 pcpu 1 time ctl 7 cval 542159180688 cntvct 542159189504 [513560135045] CPU1: [0] 50a000000000001b [513560135345] CPU1: [513560140940] CPU1: vtimer_interrupt: vcpu d1v0 ctl=3D0x1 cval cache=3D0x7e3b349390 cval reg 0x7e3b35c4b0 cntvct=3D0x7e3b34d180 cntv_tval=3D0xf320 LR0=3D0x10a000000000001b LR1=3D0 LR2=3D0 LR3=3D0 [513560142230] CPU1: vgic_inject_irq: vcpu d1v0 virq 27 [513560143595] CPU1: vgic_raise_guest_irq: vcpu d1v0 virq 27 lr 0 [513560144540] CPU1: VCPU unblock d1v0 pause 0 poll_evtchn 0 [513560146175] CPU1: snap: vcpu d1v0 index 1 now 513560145740 seq 4008773 pcpu 1 time ctl 3 cval 542159258800 cntvct 542159202128 [513560146820] CPU1: [0] 50a000000000001b [513560147090] CPU1: [513560148875] CPU1: WFI blocking d1v0 [513560149310] CPU1: VCPU unblock d1v0 pause 1 poll_evtchn 0 [513560150885] CPU1: VCPU wake d1v0 [513560152370] CPU1: snap: vcpu d1v0 index 0 now 513560152115 seq 4008774 pcpu 1 time ctl 3 cval 542159258800 cntvct 542159208736 [513560153060] CPU1: [0] 50a000000000001b [513560153360] CPU1: [513560157080] CPU1: snap: vcpu d1v0 index 1 now 513560156435 seq 4008774 pcpu 1 time ctl 3 cval 542159258800 cntvct 542159213760 The same line also shows that CNTV_CVAL_EL0 already differs from Xen's cached value: cval cache=3D0x7e3b349390, cval reg=3D0x7e3b35c4b0 So the injection is not aligned with the current CVAL/ISTATUS state. This matches Linux treating the interrupt as spurious (ISTATUS=3D0) and skipping the normal re-arm path, which can leave the vtimer output masked and the CPU without further timer events. This is why the fix is at the injection boundary: if CNTV_CTL_EL0 indicates ISTATUS=3D0, Xen should not mask and inject the vtimer IRQ. > > > > > This patch mirrors the Linux arm generic timer handler: if the interrup= t > > fires but the pending bit is not set, treat it as spurious and ignore i= t. > > Have you considered fixing properly our virtual timer emulation? I know > this requires more code, but at least we are not adding more > non-compliant code which requires patching the Guest OS. > > IIRC there was a series from Stewart to solve it and it was in pretty > good shape at the time it was posted. > I don=E2=80=99t think this patch adds more non-compliant behavior or requires any guest patching. Quite the opposite: it prevents Xen from delivering a virtual timer interrupt when the architectural state says it is not pending (CNTV_CTL_EL0.ISTATUS=3D0 / CNTV_TVAL_EL0 > 0). The current behavior (mask + inject in that situation) is what produces the spurious interrupt in the guest and can leave the timer output masked. So the intent is a minimal, self-contained Xen-side bug fix at the injection boundary: If ISTATUS=3D=3D0, there is no vtimer interrupt to deliver, so we should not mask and inject one. This does not rely on guest spurious handling; it avoids creating the spurious condition in the first place. Also, could you please share the subject/Message-ID or a link to the series you have in mind, so I can make sure I=E2=80=99m looking at the righ= t one? > > > > This issue is reproducible under heavy load on the R-Car X5H board > > (Cortex-A720AE r0p0). > > Signed-off-by: Mykola Kvach > > --- > > xen/arch/arm/include/asm/perfc_defn.h | 7 ++++--- > > xen/arch/arm/time.c | 11 ++++++++++- > > 2 files changed, 14 insertions(+), 4 deletions(-) > > > > diff --git a/xen/arch/arm/include/asm/perfc_defn.h b/xen/arch/arm/inclu= de/asm/perfc_defn.h > > index effd25b69e..f83989d95a 100644 > > --- a/xen/arch/arm/include/asm/perfc_defn.h > > +++ b/xen/arch/arm/include/asm/perfc_defn.h > > @@ -69,9 +69,10 @@ PERFCOUNTER(ppis, "#PPIs") > > PERFCOUNTER(spis, "#SPIs") > > PERFCOUNTER(guest_irqs, "#GUEST-IRQS") > > > > -PERFCOUNTER(hyp_timer_irqs, "Hypervisor timer interrupts") > > -PERFCOUNTER(virt_timer_irqs, "Virtual timer interrupts") > > -PERFCOUNTER(maintenance_irqs, "Maintenance interrupts") > > +PERFCOUNTER(hyp_timer_irqs, "Hypervisor timer interrupts") > > +PERFCOUNTER(virt_timer_irqs, "Virtual timer interrupts") > > +PERFCOUNTER(virt_timer_spurious_irqs, "Virtual timer spurious interr= upts") > > +PERFCOUNTER(maintenance_irqs, "Maintenance interrupts") > > > > PERFCOUNTER(atomics_guest, "atomics: guest access") > > PERFCOUNTER(atomics_guest_paused, "atomics: guest paused") > > diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c > > index cc3fcf47b6..d18d6568bb 100644 > > --- a/xen/arch/arm/time.c > > +++ b/xen/arch/arm/time.c > > @@ -258,6 +258,8 @@ static void htimer_interrupt(int irq, void *dev_id) > > > > static void vtimer_interrupt(int irq, void *dev_id) > > { > > + register_t ctl; > > + > > /* > > * Edge-triggered interrupts can be used for the virtual timer. E= ven > > * if the timer output signal is masked in the context switch, th= e > > @@ -271,9 +273,16 @@ static void vtimer_interrupt(int irq, void *dev_id= ) > > if ( unlikely(is_idle_vcpu(current)) ) > > return; > > > > + ctl =3D READ_SYSREG(CNTV_CTL_EL0); > > + if ( unlikely(!(ctl & CNTx_CTL_PENDING)) ) > > For the others, the Armv8 specification names this field ISTATUS. > Regardless what I wrote above, the change look alright. Before I ack, > can you confirm whether you checked other OSes (I am thinking at least > Zephyr) will also ignore spurious interrupt? Regarding other OSes: I haven't reproduced this with Zephyr domain yet, but I did take a look at Zephyr's Arm generic timer IRQ handling. At first glance it follows the usual pattern, and I don't immediately see anything that would break if a spurious vtimer IRQ was/wasn't delivered. That said, to be confident I will run a small domU test where I artificially inject spurious vtimer interrupts into the guest (i.e. deliver the IRQ while CNTV_CTL_EL0.ISTATUS is 0) and verify that Zephyr does not get stuck and continues to re-arm the timer correctly. I'll report the results in a follow-up. Best regards, Mykola > > Cheers, > > -- > Julien Grall > From xen-devel-bounces@lists.xenproject.org Thu Jan 29 11:31:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 11:31:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216299.1526215 (Exim 4.92) (envelope-from ) id 1vlQFR-0006A0-Vt; Thu, 29 Jan 2026 11:31:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216299.1526215; Thu, 29 Jan 2026 11:31: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 1vlQFR-00069t-Ss; Thu, 29 Jan 2026 11:31:41 +0000 Received: by outflank-mailman (input) for mailman id 1216299; Thu, 29 Jan 2026 11:31: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 1vlQFQ-00069n-GN for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 11:31:40 +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 133f9b07-fd06-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 12:31:38 +0100 (CET) Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-383122fbc9bso7362431fa.1 for ; Thu, 29 Jan 2026 03:31:38 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 133f9b07-fd06-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; t=1769686298; cv=none; d=google.com; s=arc-20240605; b=EZM/6yvT63B5XT0r8ODKJksN9P7ecpWgCLoWYoUutZ9gpo+Z6NpF9Qcv6vfyIWrxdP FLGZnqEFb4LXVf+ytq6q+lK30HcBAs0CbqlvCixGrLrh5M1ySH0k/a9VqAyhHc6kc9rs gWFt4MQndwru6C+UAKDvVyST3pXjainTR1g3BOxNUH0WdZaYF8JxZQifWFerSQCGgY/X 6XT4SiBtV6uALIJI0JG7TN2HRhwnBMYYUQKy2GgTMy1Tc4qISCUStfMGnforQW1YlC7L 696fHkZLbaQ19nD41HevHqtmwIgMcsuN+QPZl8VRfGnyOa5gc/B9RvPt6FX6czIYzA2z dWTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=qB9JPqRk50DTcZH64YAxcbOSLeP8QgQD98CMoYjRSH4=; fh=XPwOTaEPrdk2pN2RgjfihMkJ4NQu8t1nAUIywJrC5RY=; b=e55DzTHg24dLgs6++G3b1mxcT5ArxX3C6VqY7jQWphhc/8VrKl0gCYxVG8umk/jt74 8W3s8WZ49HomLeYOLMIoSAciOTcgi1M6r4zVtsSo16LdFOGPlvcPy61CuSJWB8PgOYAU WoMDQpmEUTf7V0Sqm9tVPn1clBAgEaPTZ5JOxhISFX78Luwyloybaw7D6OyV8FppY1rS XDGTXw1HRuIJBZQEDIUrmlXMxpBFjRdNjh20Skd6Ayizl3vYXbzSmvJeBdyLgEhTsbMB vChOP/FQn8yGOJIHdTFXZYpwWFAwduM5fHfYGgoVyqtXzIgKFmy2c3V1nYV6JSuxio61 8q4A==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769686298; x=1770291098; 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=qB9JPqRk50DTcZH64YAxcbOSLeP8QgQD98CMoYjRSH4=; b=XDU+oh7PP49vKVCQIshnvWCUjrsBJOB8WsTgeA7SMgP4Sqo89JN83HDBn4UsszJA/D /8An4KhxT9PfkBE2yETQOT3wwhliNpFFCK5NWJA6KWnNBI9MAO7BpKtPoUWZ9PX0Szi1 Aaob55NSQbOhdYU+reZwFeRDsWX5h8/E5wfWnb5LYnd6z4h4B4zoJd07LnrlbO5uF7ZH 1yHBW3GMqrhPKcdgICcN4yumwLC3GBw3vVJe4kP9GpL3tJwbamqmnKrF5wxDKXA38bzG E/ixnTpnTZiN8XSBoVwZoCAUwUlaIocHPfJ5DXW7a8ZROMo2M2RghcATh1KPUKZnJIkr UE8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769686298; x=1770291098; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=qB9JPqRk50DTcZH64YAxcbOSLeP8QgQD98CMoYjRSH4=; b=vhTalWSEjlSRdHpiE8w37jscUhy1djhEW/7YTn5yanaclxsCCp/w13/LZ75E4+mwrt C0CuqixGSDKCtKxxDe2q/mVsKJ1f8990gaGbQiviNC6XgHk7IgfaRUmgIwqETphr1Nel tce7ed+TjaLkKU5e0y8ExCEunUYt/HVQlTSy73XjoMFCnR6ybwyBTcanHYJh3C9p632l 96RpZM2gEJwS8/HJEETamqICwXxkO9BZd2brWl5KMmo6nonFw8gEuc5K8cX7kUEx1KB6 GHTcVzgSgDlrmvmXLdmr/xOEjDfLgPimobS8d+yB1ZRaFT3s6NhEyc7FF2/H5nyN70ui FSYw== X-Gm-Message-State: AOJu0YzjI/uqV/B9oP9XRamy588uT8yF3ARlTkD/Ko856t1vi1at4YS7 IB0H9xS1AFFTLYgzuf5qZ6n5KLsaSDtvJNIkeGuSLjaslvKhRbDHuwSwQge0rUstFXEt/UqgA17 33Gp9zVG9OJ0O0aGVnm++5GKYBja7e0w= X-Gm-Gg: AZuq6aJPabluRir5tPHwFceIiWqOHN1/a4M9RYs63wnM4t9+922OymjCvhIlEfuCRWJ hKI4dTxoSNjvVvyFMI3h5dUJErUkhwcmOCNvwbtsa5ikr8Wx/1P4lGQi9TtP3vYVCSDb3x9r2qy cj5vFUvDspfcAG5T/cmbrnFckaVnYaiImfsU18Fv30enNUyW2tdcFo9lKbgxEYmk4w+92mavUF3 m7KncVSa9ZyLObTd/Ukcd/OY6QVKGoOnqHvenIZidv0CiZzpCsuO+sCy15JBe9ynVUpOiPWyQZQ eeQr X-Received: by 2002:a05:6512:1393:b0:59b:7c2b:4440 with SMTP id 2adb3069b0e04-59e0413b297mr3327102e87.53.1769686297500; Thu, 29 Jan 2026 03:31:37 -0800 (PST) MIME-Version: 1.0 References: <806731b5-6c56-4274-98f1-120530cfe398@amd.com> In-Reply-To: <806731b5-6c56-4274-98f1-120530cfe398@amd.com> From: Mykola Kvach Date: Thu, 29 Jan 2026 13:30:00 +0200 X-Gm-Features: AZwV_QjCq70XFQkE8IMqdsVwexUv0tKKaqQ3p8A10J0RKqfO1y46Yqzl6CysOvo Message-ID: Subject: Re: [PATCH v16 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests To: "Orzel, Michal" Cc: xen-devel@lists.xenproject.org, Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Michal, Thanks for the review -- I think there are two separate concerns here (domain state vs. ARM-specific resume context), and it=E2=80=99s easy to co= nflate them. On Thu, Jan 15, 2026 at 11:03=E2=80=AFAM Orzel, Michal wrote: > > > > On 12/12/2025 14:18, Mykola Kvach wrote: > > 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 ca= ll > > (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 syste= m > > in hwdom_shutdown() via domain_shutdown > > - Require all secondary VCPUs of the calling domain to be offline befor= e > > 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 restorat= ion > > steps required by the platform. arch_domain_resume() stays int to propa= gate > > errno-style detail into common logging; preserving the integer keeps th= e > > reason visible and leaves room for future arch-specific failures or ric= her > > handling. > > > > 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 > > --- > > Changes in V16: > > - Refactor error handling in domain_resume: move logging to generic cod= e, > > use explicit return code checking. > > - Make context clearing conditional on success in arch_domain_resume. > > - The 'int' return type is retained for arch_domain_resume for consiste= ncy > > with other arch hooks and to allow for specific negative error codes. > > --- > > xen/arch/arm/domain.c | 39 +++++++++ > > xen/arch/arm/include/asm/domain.h | 2 + > > xen/arch/arm/include/asm/perfc_defn.h | 1 + > > xen/arch/arm/include/asm/psci.h | 2 + > > xen/arch/arm/include/asm/suspend.h | 27 ++++++ > > xen/arch/arm/include/asm/vpsci.h | 5 +- > > xen/arch/arm/vpsci.c | 116 +++++++++++++++++++++----- > > xen/common/domain.c | 10 +++ > > xen/include/xen/suspend.h | 25 ++++++ > > 9 files changed, 205 insertions(+), 22 deletions(-) > > create mode 100644 xen/arch/arm/include/asm/suspend.h > > create mode 100644 xen/include/xen/suspend.h > > > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > > index 47973f99d9..f903e7d4f0 100644 > > --- a/xen/arch/arm/domain.c > > +++ b/xen/arch/arm/domain.c > > @@ -12,6 +12,8 @@ > > #include > > #include > > > > +#include > > + > > #include > > #include > > #include > > @@ -24,10 +26,12 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > #include > > +#include > > #include > > > > #include "vpci.h" > > @@ -851,6 +855,41 @@ void arch_domain_creation_finished(struct domain *= d) > > p2m_domain_creation_finished(d); > > } > > > > +int arch_domain_resume(struct domain *d) > > +{ > > + int rc; > > + struct resume_info *ctx =3D &d->arch.resume_ctx; > > + > > + if ( !d->is_shutting_down || d->shutdown_code !=3D SHUTDOWN_suspen= d ) > How does this check and returning -EINVAL correspond to... The if ( !d->is_shutting_down || d->shutdown_code !=3D SHUTDOWN_suspend ) guard is meant to validate the domain state for the DOMCTL resumedomain entry point (i.e. reject an xl resume on a domain that isn=E2=80=99t in the "suspend shutdown" state). Suspend requests issued via SCHEDOP_shutdown / SCHEDOP_remote_shutdown with reason SUSPEND still put the domain into is_shutting_down=3D1 and shutdown_code=3DSHUTDOWN_suspend, so they do pass this state check. What the comment below was trying to say is different: those hypercall paths don=E2=80=99t go through vPSCI SYSTEM_SUSPEND, so they don=E2=80=99t = populate the Arm-specific resume context (notably wake_cpu). In that case ctx->wake_cpu remains NULL and the Arm arch_domain_resume() returns early. > > > + { > > + dprintk(XENLOG_WARNING, > > + "%pd: Invalid domain state for resume: is_shutting_dow= n=3D%u, shutdown_code=3D%u\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 comment? This patch assumes that we can now resume successfully (i.e= . this > function returns 0 and common domain_resume can continue) only if the shu= tdown > was with SCHEDOP_shutdown. Anything else will infinitely keep the vCPUS p= aused. Separately (and this is why I=E2=80=99m hesitant to make domain_resume() "suspend-only"): domain_resume() is also used by the soft-reset flow. Today soft-reset is effectively x86-only (gated by HAS_SOFT_RESET), but the core plumbing is in common code and is intentionally generic -- the soft-reset calling chain ends up using domain_resume() as a generic helper. If domain_resume() itself starts rejecting anything other than SHUTDOWN_suspend, it would also be a future trap if/when someone enables HAS_SOFT_RESET on Arm. > > Other than that, the patch looks good. > > ~Michal > Best regards, Mykola From xen-devel-bounces@lists.xenproject.org Thu Jan 29 11:36:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 11:36:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216314.1526233 (Exim 4.92) (envelope-from ) id 1vlQJr-0006pI-Ke; Thu, 29 Jan 2026 11:36:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216314.1526233; Thu, 29 Jan 2026 11:36: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 1vlQJr-0006pB-F9; Thu, 29 Jan 2026 11:36:15 +0000 Received: by outflank-mailman (input) for mailman id 1216314; Thu, 29 Jan 2026 11:36: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 1vlQJq-0006p5-Gm for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 11:36:14 +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 b6af0962-fd06-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 12:36:12 +0100 (CET) Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-42fb6ce71c7so844355f8f.1 for ; Thu, 29 Jan 2026 03:36:12 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e131cf16sm14828342f8f.22.2026.01.29.03.36.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 03:36:11 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b6af0962-fd06-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769686572; x=1770291372; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=nuj794ShzjiwHINyLt/hygEwzI7bgxPdXtXs1zE2QFY=; b=WtCLGh14vSEPY9wNgtpqXH3u3LCz/Uv1M+pROapasavOhAKN+qvQ5odjEaxd0YyRPH iGNR6at2uUEkatU5Ru60vluGptTamTyyOB4WDHzBhjP8mPhkqQXnG5/lBNjLlsn1p9iW Hj/hIEPdrsoUroO3TW3qomv/+dEQfl/0wjxq4aNrxp9ZQEELb4DgjMjO7QVONHWTaElk /MUNRF6hIubvCJs5VHKi2hc4MCQVmp/DDL4uLuDN/92XlnF9ncwshQzAd+j6kGXOky2L ZJ/z7ymeqd9QakUNC9+8SLxW8x/TwB9vU09k3Rqz+zvFCfOqjzJfrGnXA1eHoXL/WlV2 sU5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769686572; x=1770291372; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nuj794ShzjiwHINyLt/hygEwzI7bgxPdXtXs1zE2QFY=; b=I5mytzWkS08qnLsfJjqWvGn3fg9oh+W7Rik109gh3PhZ2vP5R5pjUUtKLtAcmIFNH+ V0kZt+XFg08llRxV59uaGQ5Wef2HLNxl5VM/Q3oeM1DIHCv6BgBZNAx8khL/e5FsVnyR jiPaHbL+Q8XEcgmmaCngG+HQhVhhPA5CgInV1EafEhIpwOhy7IYJkjRgoDEOmqRackNV KGjqitWWLP0CjZ7wZ5f1sGYVf0bt6ATDiqFIKXKE4U+5E2wfMgISJOsLvQU12xY4o2/h uShAKT8sb6U/Vf5KPKR176namhGiK6I7PP32MDu0Vucp9uZfQum9Gl9B3P/FGavMnZWg LbFg== X-Gm-Message-State: AOJu0Yx0+WHb4/cBnwamRY/MG1lVK6RtA9XjOP+oMw5LSx2gzzqhxPEJ ZGRFfKbB4fhKh3BCVwhyFpo4sdfS9JeTS83/f259PZOdRdnMeSHuvjBTwtC3bf2yV0bQB8Ln+BV xj/c= X-Gm-Gg: AZuq6aJdSSh6ZAxpqWoKiPYlxNAZQRmpwn5/yhDtD3e1mVYnmyHW9SYR6Kg3aM3aAgQ CS66wFYW2FmQhfTz4ScJBLZJaN5+beWm14qB9XMyGIDP0dR9oqPnbY7BcBYEySyhu7NOIj0xg4n mQxXayOrlBUb6JSN84G8cf71axLSdDsnFXGNPieKVkkZqw+2olAje27SgfSkYoDnA1N4v1C0MTI m6V4M2p831trf9vK5Q1CnV3o3zru8bF5Ix2VxHXEigc4hT9KUMOqNqIx7l3D9q4dFDvzzVmd2Re ys25Ashjjs9YHGulDUZDOZlFXXLKHNbV5QgB3lTnRLNu9YYRgZOoJVzXfAUBc0rwXkkAS5fHnNL nbONnPh3Q0DO35YJKSU3eXPbjVI69YPVOZ5ypYjVsNzUiY+3Lhp69PzglVIZZMR6pkWZiTQdrsX MxKI7hMsOu5He+yGLlIJp7ND4EqMmh8nVF8dsYrTymwSH/NqwD42hJlZ839wH6n7jA1No9H1dD2 /Y= X-Received: by 2002:a05:6000:2c01:b0:435:95fb:a0f2 with SMTP id ffacd0b85a97d-435dd1bc76cmr12560474f8f.46.1769686572074; Thu, 29 Jan 2026 03:36:12 -0800 (PST) Message-ID: <0b46ca9f-bac9-4868-8229-067ec98ad7c8@suse.com> Date: Thu, 29 Jan 2026 12:36:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/4] vPCI/DomU: really no ext-caps without extended config space To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand References: <58091dc1-7bda-4536-8200-2d0a5679d4d1@suse.com> <96e90685-3321-4884-8fe7-f083c25ba7ab@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.01.2026 11:51, Roger Pau Monné wrote: > On Thu, Jan 29, 2026 at 11:08:22AM +0100, Jan Beulich wrote: >> On 29.01.2026 10:19, Roger Pau Monné wrote: >>> On Mon, Jan 19, 2026 at 03:48:01PM +0100, Jan Beulich wrote: >>>> --- a/xen/drivers/vpci/header.c >>>> +++ b/xen/drivers/vpci/header.c >>>> @@ -830,9 +830,14 @@ static int vpci_init_ext_capability_list >>>> unsigned int pos = PCI_CFG_SPACE_SIZE; >>>> >>>> if ( !is_hardware_domain(pdev->domain) ) >>>> + { >>>> + if ( !pdev->ext_cfg ) >>>> + return 0; >>> >>> Don't you want to possibly put this as a top-level check, so if >>> there's no extended config space we avoid doing the PCI_CFG_SPACE_SIZE >>> read for dom0 also? >> >> Hmm, yes, didn't think about that. That'll mean dropping the >> "if ( pos != PCI_CFG_SPACE_SIZE )" from the body of the >> "if ( header == 0xffffffffU )" then, i.e. the printk() there becoming >> unconditional. It may also mean dropping "DomU" from the subject. > > I've also wondered whether we want to short-circuit vpci_{read,write} > accesses if the device doesn't have extended cfg, for domUs to be on > the safe side. May make sense, yes. I don't think I'll add anything along these lines to this series, though. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 29 11:44:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 11:44:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216328.1526242 (Exim 4.92) (envelope-from ) id 1vlQRH-00007x-8e; Thu, 29 Jan 2026 11:43:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216328.1526242; Thu, 29 Jan 2026 11:43:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlQRH-00007q-5Z; Thu, 29 Jan 2026 11:43:55 +0000 Received: by outflank-mailman (input) for mailman id 1216328; Thu, 29 Jan 2026 11:43:53 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlQRF-00007k-Ir for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 11:43:53 +0000 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [2a00:1450:4864:20::342]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c8185886-fd07-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 12:43:51 +0100 (CET) Received: by mail-wm1-x342.google.com with SMTP id 5b1f17b1804b1-47d59da3d81so14201705e9.0 for ; Thu, 29 Jan 2026 03:43:51 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e1322eefsm14056334f8f.30.2026.01.29.03.43.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 03:43:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c8185886-fd07-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769687031; x=1770291831; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=WDwMz6MaCgFyose2e3pvmTf0pX4P6lxe59RscuoGPe8=; b=GJRXyzFfQ8MNZXOkWBBx0QSKWm++J6AeY2fYZQL7hEBXsXoPNdv4GpLEa+0RxSpB7b Wg1TnOLJOPhjl0NFGG3CFvILbG79tG2TuBtquhfDjWsFAPlM0Hwjd4A3gC6CBZf9Ekv3 ka7tdyIBjSqecnBnS8VP1iH6PMfW7+KVRWCNIeOGSosVL9AeOY721sJa2TdHaocMFWmn 1MsOLu5TLgrjW8x0lJrTxF99WJM3sOAQ2EKBQqwTS5Pvp7vJofBGcacpfGsUWgyrJygJ pOJWKeB7qvFXyWwQPPj0lttPpk31QpGUsZ2OLQJ8quFQdVCiX/EVEx7+k+Mfp9oZ7iqO DPDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769687031; x=1770291831; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=WDwMz6MaCgFyose2e3pvmTf0pX4P6lxe59RscuoGPe8=; b=DNe/dS3TGjnolRX33hUMEYnxgPt6qBwB7hQpR0MkbG1/bvxS8/4/jPpdMecZFeL+hg BjoYnUX9AY+w3/UMI0NEP3OmcYJiUejYiH/j40Qfbxq/H/u1uRjQ/WiXlvbMM6vU6SjI 1meRyhbepIBDzOBck37msryzM0JNFTh6BUIgrxz0Ol00QKdKNRO9jQdmtYVCJSBqAJz7 Trs2NoiWOpEzHxv+TRIjR+WOwMbYzStzrPVJTdsEyL/TRp1fn6YkgBPZ6IlDJIYwRzHp r+WaAeA2T0ULpYCxXE03aWKgldxYsoHH58ThaYN2zWvOSWDUWxBdDysuNrgfgqxfj2Cu MamQ== X-Gm-Message-State: AOJu0YzNYcNrQJGJMIohcmEyJfkawX0wcQBi8bDHD79Ab6vjOE3/GluU hzhtabXUbhih0EmO3Zbbhs5nRSZqbDj8L5pAmWV/X58L4S14IwAxKr6vrwA3YewF7w== X-Gm-Gg: AZuq6aKDOCMHDUyDHhxd/J5A3Xo/kRLzdluz/9GBcXSC7MAifH2s6IvMULtH3FyvReK HszXHl3J522ZWRDhSPvDnHXcYa9Uo7DECuzgI04INUy/7l9kvZZpgXfMixuiGDbui70P4Gn8cYs qKlSRKelGVpceIU0gvB/Qzgar9e+l6Jy+YlWCbrjj++3HvCdm6MVm0F/XwLC2Zz0W0bT9J92wN8 LIAE4OgqTrst65Bv0ys5sNZYtovKdooyXAg5ljCV4ZGPcZy48GDttQFWocbVlQIKwemaIGMS6Fs PeauTpZduzliFmGRaG5QoVVuOn6eIv+uGfBFMM1/riIFutDHneADRLXx8P8bfWNkAKn4xpcPRUD YRPmXGfG3alKaeAFiIvE1enMytQkxABokanbRdv/DOCb7IH58bsKMazRMGrxOielrdV4sgSMw7f zqBUcT6B4BQnkgfHAHiMGrtL+vRqG6xEWl1irwML02GFxPpNTJb3y4GlDucQ2BCE4GFXZnD1uck uoG9m79MHHnew== X-Received: by 2002:a05:600c:47d5:b0:480:63c1:3ac7 with SMTP id 5b1f17b1804b1-48082874614mr23477805e9.2.1769687030703; Thu, 29 Jan 2026 03:43:50 -0800 (PST) Message-ID: Date: Thu, 29 Jan 2026 12:43:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/4] PCI: determine whether a device has extended config space 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 , Stewart Hildebrand References: <58091dc1-7bda-4536-8200-2d0a5679d4d1@suse.com> <2d5e017f-1675-4753-9494-2b664c4ca7fa@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.01.2026 11:33, Roger Pau Monné wrote: > On Thu, Jan 29, 2026 at 09:15:30AM +0100, Jan Beulich wrote: >> On 28.01.2026 18:49, Roger Pau Monné wrote: >>> On Mon, Jan 19, 2026 at 03:46:55PM +0100, Jan Beulich wrote: >>>> Legacy PCI devices don't have any extended config space. Reading any part >>>> thereof may return all ones or other arbitrary data, e.g. in some cases >>>> base config space contents repeatedly. >>>> >>>> Logic follows Linux 6.19-rc's pci_cfg_space_size(), albeit leveraging our >>>> determination of device type; in particular some comments are taken >>>> verbatim from there. >>>> >>>> Signed-off-by: Jan Beulich > > Acked-by: Roger Pau Monné Thanks. There'll be a v3 though in any event, to add the command line option that you asked for. I'll take the liberty to retain the ack (whereas I've dropped Stewart's R-b). >>>> Linux also has CONFIG_PCI_QUIRKS, allowing to compile out the slightly >>>> risky code (as reads may in principle have side effects). Should we gain >>>> such, too? >>> >>> I would be fine with just a command line to disable the newly added >>> behavior in case it causes issues. >> >> Can do. Will need to get creative as to the name of such an option. > > pci=check-ext-cfg=? Kind of a mouthful. As we already have "pci=", I've added a "pci=no-quirks" sub-option there. >>>> @@ -718,6 +721,11 @@ int pci_add_device(u16 seg, u8 bus, u8 d >>>> >>>> list_add(&pdev->vf_list, &pf_pdev->vf_list); >>>> } >>>> + >>>> + if ( !pdev->ext_cfg ) >>>> + printk(XENLOG_WARNING >>>> + "%pp: VF without extended config space?\n", >>>> + &pdev->sbdf); >>> >>> You possibly also want to check that the PF (pf_pdev in this context I >>> think) also has ext_cfg == true. >> >> I don't think so. No extended config space on a PF means no PF in that sense >> in the first place, for then there not being any SR-IOV capability. > > Right, but won't it be possible for Xen to not be aware of the > ECAM region for that device, yet the hardware domain somehow managed > to enable SR-IOV it and request to register a VF? Then we're screwed elsewhere, when we try to read the SR-IOV capability ourselves. >>>> @@ -1041,6 +1049,75 @@ enum pdev_type pdev_type(u16 seg, u8 bus >>>> return pos ? DEV_TYPE_PCIe_ENDPOINT : DEV_TYPE_PCI; >>>> } >>>> >>>> +void pci_check_extcfg(struct pci_dev *pdev) >>>> +{ >>>> + unsigned int pos, sig; >>>> + >>>> + pdev->ext_cfg = false; >>> >>> I think I would prefer if the ext_cfg field is only modified once Xen >>> know the correct value to put there. >> >> Well, my main point of doing it this way is that the code ends up being a >> little easier to follow. Especially without the optimization talked about >> near the top, there inevitably will be a window in time where what the >> field says is wrong. With the optimization there'll be two main cases: >> - MCFG becoming newly available: The field starts out false in this case, >> i.e. the write above is a no-op. >> - MCFG disappearing (largely hypothetical, I think): The field may start >> out true in this case, but will go false unless we have another access >> mechanism for extended config space. It then can as well be set to >> false as early as possible. > > Yes, with the optimization to not re-parse existing MMCFGs there's no > transient windows where the filed is wrongly set. When there's no change. When there is a change, there'll still be such a window. Unavoidably, though. > I also think the registering of MMCFG ares with Xen should be done > ahead of the OS attempting to access the config space, and hence it's > not possible for there to be in-flight accesses that could see > transient invalid pdev->ext_cfg values. Yes, for Dom0 alone all should be fine. My worry here is with dom0less and Hyperlaunch. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 29 13:06:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 13:06:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216412.1526361 (Exim 4.92) (envelope-from ) id 1vlRij-0002b4-RD; Thu, 29 Jan 2026 13:06:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216412.1526361; Thu, 29 Jan 2026 13:06:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlRij-0002ax-NY; Thu, 29 Jan 2026 13:06:01 +0000 Received: by outflank-mailman (input) for mailman id 1216412; Thu, 29 Jan 2026 13:06: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 1vlRii-0002ar-8H for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 13:06:00 +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 409c2d7f-fd13-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 14:05:58 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-47ff94b46afso8560335e9.1 for ; Thu, 29 Jan 2026 05:05:58 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c428basm205808615e9.12.2026.01.29.05.05.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 05:05:57 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 409c2d7f-fd13-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769691957; x=1770296757; 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=a3i8WqonQMKs9H/sjTYiUDanR10Xxf6OwmqHHveUfvg=; b=O1nZbU+m+d0UHxd9dqnlwlGMajwb1PD/9YGDPAiSPB+lNpREWRO3awTmO8CUL8XL/k x7irybHZl5PuFbdyGQQZUE9lzSwDWKjx3Sdv9AdN+C8E/ZLrB041QBVfPjS9uSUj8F4Z Gaz2sGc+nhtk229OE6N4uiDSSEYbtftD7BV0NpB/gDz1jVA06vyHQI11aslARBI0QBoL Mvv1OFeRxJiBCOisLd+2pSHAscliec2FvhZYqwR0deApL5zg7OucBBO4HENLEjpAG7pX YFDseJg2WbNhY7APT7tevZhnm4eeVG/QOhwvbFGkTy6klQJg7p3WwGLo1Al7N8Uy6s17 XHGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769691957; x=1770296757; h=content-transfer-encoding:autocrypt:content-language:cc:to:subject :from:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=a3i8WqonQMKs9H/sjTYiUDanR10Xxf6OwmqHHveUfvg=; b=N9ydEdClbHJYlT/Fvd2nnERoBfMhsdeVr++iJZ+FZ/TlyqA2yKTDA08ipVUakOuT20 424257EtxvZ25phE1bVBAwcGk8FrepXpCdQNyhbSx+HaUKVNMVgdG5V7UlYtJkT/OHfR RKQLpMfzA531lcPFFZguvLL7MakRF9z7uv5CopfWWD6JCcaI6/QtC/JHI/BfB8H5G/Yv 36uBvJgPJsh/xR/oDSnIVL/cW/oDZ6BmtxNJqkb4W8IZ0HMsISavMGKQQ7ylqDl8kr6o HE58UlFCXzL+cgdAKxpTc5LeLoP6pWeZ5pd3s/7cvhP25ednCqEeXAioSiR2HQlCCHZ8 6R0g== X-Gm-Message-State: AOJu0Yw/Q4h4GKCNAensY1m1IzqaNVjCszDl4hjiHi2NUUhyoeu20rAG 9UQrA21uJKUNkTPOMf0v0a0kkgiaNMqMsRRk7FFaBs82u/ZSm0ckRzuXQ/JBKhKuL5x//gi+QU4 Ime8= X-Gm-Gg: AZuq6aL+Z7Td9Uho1ACPE63UXM+AO1ET/t1OQkAZKTYSYT/YySeJmHenhdX9FV+kb36 sMcd5jdKCKdRdjl2kP1s9MpAIbeHbTxJE2AuPsOXtAwWnJbreg7NVMAgNdEfpjvLfpkYGeeU0La 34UBoEc8CpCuo8QuI5SHa5soT2enz3P5V8maCOdKH4x4B4jSClo0OmKY2OyGLr70SsnqbItqzjr PHu/tG3O/+k3WiSm2Kixrrs+qNZ3lKbVPQGgtJSk5TkTiuZQGil3dZBJusi4O1Sc84v87xg9lkk 9lul7n/bTrQNvwg2FAg0QapOhVo2Rw8FtdL9GfWRAcKftENo702LT8EGfZhur1ig+7izyc7Ru+x 4GgTwgIAJKpkiXlBLI2+slWKc0dMSBE78XCZMmIfN2G2PXNVGyMidwQu983LVgPK46qfpKXHDKE Lee8TErhPyh1V4R89gZz0AV3eGql4lIoTc++En4bnZy9P4E1pOUzvJ/tj8MuWCnN5BcfmRThdi3 2+4pK58aRflDA== X-Received: by 2002:a05:600c:3143:b0:47e:e2b8:66e6 with SMTP id 5b1f17b1804b1-480829b1c51mr41191065e9.14.1769691957349; Thu, 29 Jan 2026 05:05:57 -0800 (PST) Message-ID: Date: Thu, 29 Jan 2026 14:05:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jan Beulich Subject: [PATCH v3 0/6] (v)PCI: extended capability handling 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?= , Stewart Hildebrand Content-Language: en-US Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This is a follow-on to 'vPCI: avoid bogus "overlap in extended cap list" warnings', addressing further issues noted there. v3: Three new patches and some other re-work. See individual patches. 1: PCI: handle PCI->PCIe bridges as well in free_pdev() 2: PCI: determine whether a device has extended config space 3: PCI: don't look for ext-caps when there's no extended cfg space 4: vPCI/DomU: really no ext-caps without extended config space 5: x86/PCI: avoid re-evaluation of extended config space accessibility 6: vPCI: re-init extended-capability lists when MMCFG availability changed Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 29 13:08:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 13:08:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216418.1526370 (Exim 4.92) (envelope-from ) id 1vlRkk-00038v-4N; Thu, 29 Jan 2026 13:08:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216418.1526370; Thu, 29 Jan 2026 13: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 1vlRkk-00038o-1l; Thu, 29 Jan 2026 13:08:06 +0000 Received: by outflank-mailman (input) for mailman id 1216418; Thu, 29 Jan 2026 13:08:04 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlRki-00038i-7g for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 13:08:04 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8a81f3b4-fd13-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 14:08:02 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-48068ed1eccso9000395e9.2 for ; Thu, 29 Jan 2026 05:08:02 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-481a5d6e186sm3722095e9.9.2026.01.29.05.08.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 05:08:01 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8a81f3b4-fd13-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769692081; x=1770296881; 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=ft06fTllGkPgCR7qdGHfeQmVyf+2wXDHmiMWPlYjxps=; b=E8h1b8AhdwNeBSRG7J3UT9shsu/GrVn266wo4jYPeWgqQXpZyoA1iv2xq/nGNuC9Bc K86HnV0xVs7MOz6XIXsVhxD4AUqH87ATB0GLVUtUm74qKc7w06BM/yeeeRsdT+zCO3eB e+1V6n9TUcMiqHM5+Km2jK3F8UHnUkQ1MWccsXpxTYi3+h8LjwP+lT1XNqan7M13SM53 jFrFNKDHWdKjQb7oO7yt7E58xuIAShWSBHcbFdHF8GM3PI0oyGVy8PoOMTSnsu7L6pyI GdyNgNi2toREXeZiiZQCWw03CNV0qH+H+cRsOM9qerWifA1l31xpscV32ODqb7NM/lLZ 6dcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769692081; x=1770296881; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ft06fTllGkPgCR7qdGHfeQmVyf+2wXDHmiMWPlYjxps=; b=K3yylhTkVTEEx+1XZhfedD+YDnPWpbvYzBhQFnbfYVLbHpaOr1qQDvrLmmUvJl+fqV 2XHJnqbi+rAEs6raHZAgPdq1Dr22zu8pgls7jah2o6oRJ/nZhMRhvdufidCcQkt6EGZp heH2bYAFZMK0lfWfRZXraFg2VrgWBL6mTtU/827UIXmSsvCI5bObPRRa9PhDY4OC96RP adPnSBDQ/YPFnsSBIkczgS3qUxNyn12HYSWWToCxBDEBEMf+B7OaIFMwG3iv9d8KF/XC 2bauGoZ0XXcpgKdRnd/hEmejy+WJVePrw7r9EkAY6gRKwO+PCVIDGW0Bw9mOMdsJYQHg +ESA== X-Gm-Message-State: AOJu0YzIifHTOA/96NoIX+WIsgijjl2Te+8jtbBN3jSQZ//YDvuyQ/cs 66KonbNMWBV9wQLxSus5Cze9ilfqAmnBQyIlk4WM5dHsigFEHMVhZNzAz9CDhnOpmf0odm9KqqL KIDE= X-Gm-Gg: AZuq6aKZ/I49eY8Ynf3YJCDzD27zXccS/7AykvRzDmhtqFC7zeqTTl/pUfLkAa6g1mB FSZOHLsw1KqWK3TtbFLl44T8b7f2ZSfZi4K6JxfO+jx/cUgGAsDq9+D1ibrasF7HktJ8sIdwxc7 1pjR5PpkjLzURSSfOj2aLUfoJQm84s5BZgmWPPEFUHOiHMcjE1dgOY6IPALlbJ/xfL4E586KdoK hT+WUhL9WL6pWfkk8sZVGHl8z0zQhMdveftChMi1cqeTA7+7aB2oqHWBij+KWFzxWqbJCkHkV+M X4Qet3XbRGo0zQjKHRolvFQlCZSrWYlmRWpPYlLbYJVPVUR8nrRPY45d51/TVkQmYVUYV4u0qk3 ydjmeWZAQl508G2eK9R8c/1OLA2xDprXdUcJ2+OMqUq0K6bEnPQkpsDx/yfkA4g6rHt9Q3FEHmg pXjmYOh6RWaHS9kyagGIt7F1QSDUkdyseI0S5ofTbKVfn7eq+74S2dJoV/Gc5SXXpdLgMoSbonu ek= X-Received: by 2002:a05:600c:871a:b0:477:93f7:bbc5 with SMTP id 5b1f17b1804b1-4806c00c0aemr101803605e9.10.1769692081362; Thu, 29 Jan 2026 05:08:01 -0800 (PST) Message-ID: Date: Thu, 29 Jan 2026 14:07:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v3 1/6] PCI: handle PCI->PCIe bridges as well in free_pdev() From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand 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 Don't know how I managed to overlook the freeing side when adding the case to alloc_pdev(). Fixes: cd2b9f0b1986 ("PCI: handle PCI->PCIe bridges as well in alloc_pdev()") Signed-off-by: Jan Beulich --- v3: New. --- Noticed due to the original patch still applying cleanly, just with an offset of a few dozen lines. --- a/xen/drivers/passthrough/pci.c +++ b/xen/drivers/passthrough/pci.c @@ -436,6 +436,7 @@ static void free_pdev(struct pci_seg *ps unsigned long flags; case DEV_TYPE_PCIe2PCI_BRIDGE: + case DEV_TYPE_PCI2PCIe_BRIDGE: case DEV_TYPE_LEGACY_PCI_BRIDGE: sec_bus = pci_conf_read8(pdev->sbdf, PCI_SECONDARY_BUS); sub_bus = pci_conf_read8(pdev->sbdf, PCI_SUBORDINATE_BUS); From xen-devel-bounces@lists.xenproject.org Thu Jan 29 13:08:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 13:08:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216428.1526381 (Exim 4.92) (envelope-from ) id 1vlRlB-0003Xa-Bg; Thu, 29 Jan 2026 13:08:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216428.1526381; Thu, 29 Jan 2026 13: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 1vlRlB-0003XT-93; Thu, 29 Jan 2026 13:08:33 +0000 Received: by outflank-mailman (input) for mailman id 1216428; Thu, 29 Jan 2026 13:08: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 1vlRlA-0003Nf-91 for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 13:08:32 +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 9bdfc517-fd13-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 14:08:31 +0100 (CET) Received: by mail-wr1-x442.google.com with SMTP id ffacd0b85a97d-42fb2314eb0so866782f8f.2 for ; Thu, 29 Jan 2026 05:08:31 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e1354205sm14915758f8f.41.2026.01.29.05.08.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 05:08:30 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9bdfc517-fd13-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769692111; x=1770296911; 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=L+psAJ7UCo75ato/kJWZ5qYPGZM3zv9DbaC1Tdx5QNA=; b=V0jsGFMnuwZkB7sn5El70nZs43+R9TQuk0iaBLOWnWB/aE7f38HoR5c+zfjRhahsE/ CNAozeGQaivKCN032ATAZbbrFbufe8vi+zt+UDnDcqz4z1Sf5IjSe2YFAvEG+tInMRx6 lgtHfBy1OSaS4IjWAxpbRxxzaOYAmqC6uceuAZgGz32VkbXsnV/hM3sXicrzcxkG8zn1 +SIVzVjRLJC08B5kNisc6gNjhnrvh8utPHGHs2YOgEUPJH3VoynVtuz3cZdFiv+RNKnt gF9KY4MbG7hDvMi/4fTZSYD2fFf9XhpHHi7fujltXA7JF+QfxYAJxMNYocHOf1hVZNNR 3JPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769692111; x=1770296911; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=L+psAJ7UCo75ato/kJWZ5qYPGZM3zv9DbaC1Tdx5QNA=; b=Z3DvvryfzFi1I3X02nRb++zTOxHHWKcDPcYb0GcPdstEqSO2orP0Lk43+/gXejzX8r fx0McabrtgsQ4LiPS62WBWMFwZzNAMP2TEpDFRv2iA0bU9n2saOJNUL62CbXIHMY25c4 CMZK+RrpU9BRgjVZROCiCqBVkqzTv4MUQQpQJIWGUHHXjOg33Cf2yvaBuGRh8ZC8Tqyn eoAn/9zYRYhnX87zANlljsL5N7rQYbiR452muydfpdZLu350QDGqIe/AO/Jnti2QsIcl kGSsH8AoS76EBwbeilnbim92Dd403gNQtLQKvpKdvyXGS+Ae1+hkZZINmxx/bUpmC6Pg bkhQ== X-Gm-Message-State: AOJu0YztukGSP8Ziya12Ka01znc4dIeeXg/Qvd9jDiOKbNQu+S4P1zzr i9sfB+s+8bIalL9iyOTSShCATUuHAC4pkl619XZcC9FdQLV2PzgzjHMhjpIadu7ZRPu3Tf4Bzyj 7Ii4nkw== X-Gm-Gg: AZuq6aJZkR+8rFukM/CqyZpOXGRF8F+AdxBsrqzs1HTw7DSmlg9R5xmFqr0sWfMyA6W ROCf5MRA3boahCjqAe32y2PvhLNU1J3zvNt/Z51TyfCBTMlYz+bLuFxMypuE6dllIe+AB0oHnF7 s+LFM1Dhru9ORIE3rq0IVGv0nSG1PafcQ66j8cUyBSvBF7Rm4+lhHRW+djH1ciNsAt4mBgloamO iwD5dEvSRFNyANeYDnBKIg3T6s/iKeJ+q9RWfBOl0FS6sWTvxGZzXaZOunrcbswG1VQ3EsT3MSO K6JS+7wVu1+suTSTBtdGcgM3rLvSceblq/jUiSlTFcYSw7JJGNPK1H1ZBOrSHBxZeqck+3/lF10 e1zA/lbW06lfwVvnI6Sbe6Dq5vnMl1jq5A9e7WzBpkckUVN0w6U+zarWxrtX8TyFaK0u0E9hgT3 LQLGdSExDSnM1uiK2ZO8PtwyJ/OuQV8jh3TUrfGrW3k2oDkRwrILZmllHVGTaMbMATx773swn0A 9Y= X-Received: by 2002:a05:6000:1786:b0:433:42d1:f71f with SMTP id ffacd0b85a97d-435dd1c1d59mr13079823f8f.38.1769692110530; Thu, 29 Jan 2026 05:08:30 -0800 (PST) Message-ID: <99d45a27-ce67-4f10-9883-dba96f055285@suse.com> Date: Thu, 29 Jan 2026 14:08:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v3 2/6] PCI: determine whether a device has extended config space From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand 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: 8bit Legacy PCI devices don't have any extended config space. Reading any part thereof may return all ones or other arbitrary data, e.g. in some cases base config space contents repeatedly. Logic follows Linux 6.19-rc's pci_cfg_space_size(), albeit leveraging our determination of device type; in particular some comments are taken verbatim from there. Like with Linux'es CONFIG_PCI_QUIRKS, only the alias detection logic is covered by the new "pci=no-quirks". The singular access at PCI_CFG_SPACE_SIZE is left unconditional. Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné --- The warning near the bottom of pci_check_extcfg() may be issued multiple times for a single device now. Should we try to avoid that? Note that no vPCI adjustments are done here, but they're going to be needed: Whatever requires extended capabilities will need re- evaluating / newly establishing / tearing down in case an invocation of PHYSDEVOP_pci_mmcfg_reserved alters global state. --- v3: Add command line (sub-)option. v2: Major re-work to also check upon PHYSDEVOP_pci_mmcfg_reserved invocation. --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -2009,12 +2009,21 @@ Only effective if CONFIG_PARTIAL_EMULATI behavior.** ### pci - = List of [ serr=, perr= ] + = List of [ serr=, perr=, quirks= ] + +* `serr` and `perr` Default: Signaling left as set by firmware. -Override the firmware settings, and explicitly enable or disable the -signalling of PCI System and Parity errors. + Override the firmware settings, and explicitly enable or disable the + signalling of PCI System and Parity errors. + +* `quirks` + + Default: `on` + + In its negative form, allows to suppress certain quirk workarounds, in case + they cause issues. ### pci-phantom > `=[:]:,` --- a/xen/arch/x86/physdev.c +++ b/xen/arch/x86/physdev.c @@ -22,6 +22,8 @@ int physdev_map_pirq(struct domain *d, i struct msi_info *msi); int physdev_unmap_pirq(struct domain *d, int pirq); +int cf_check physdev_check_pci_extcfg(struct pci_dev *pdev, void *arg); + #include "x86_64/mmconfig.h" #ifndef COMPAT @@ -160,6 +162,17 @@ int physdev_unmap_pirq(struct domain *d, return ret; } + +int cf_check physdev_check_pci_extcfg(struct pci_dev *pdev, void *arg) +{ + const struct physdev_pci_mmcfg_reserved *info = arg; + + ASSERT(pdev->seg == info->segment); + if ( pdev->bus >= info->start_bus && pdev->bus <= info->end_bus ) + pci_check_extcfg(pdev); + + return 0; +} #endif /* COMPAT */ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) @@ -511,6 +524,11 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H ret = pci_mmcfg_reserved(info.address, info.segment, info.start_bus, info.end_bus, info.flags); + + if ( !ret ) + ret = pci_segment_iterate(info.segment, physdev_check_pci_extcfg, + &info); + if ( !ret && has_vpci(currd) && (info.flags & XEN_PCI_MMCFG_RESERVED) ) { /* --- a/xen/drivers/passthrough/pci.c +++ b/xen/drivers/passthrough/pci.c @@ -183,6 +183,7 @@ custom_param("pci-phantom", parse_phanto static u16 __read_mostly command_mask; static u16 __read_mostly bridge_ctl_mask; +static bool __ro_after_init opt_pci_quirks = true; static int __init cf_check parse_pci_param(const char *s) { @@ -207,6 +208,8 @@ static int __init cf_check parse_pci_par cmd_mask = PCI_COMMAND_PARITY; brctl_mask = PCI_BRIDGE_CTL_PARITY; } + else if ( (val = parse_boolean("quirks", s, ss)) >= 0 ) + opt_pci_quirks = val; else rc = -EINVAL; @@ -422,6 +425,9 @@ static struct pci_dev *alloc_pdev(struct } apply_quirks(pdev); + + pci_check_extcfg(pdev); + check_pdev(pdev); return pdev; @@ -719,6 +725,11 @@ int pci_add_device(u16 seg, u8 bus, u8 d list_add(&pdev->vf_list, &pf_pdev->vf_list); } + + if ( !pdev->ext_cfg ) + printk(XENLOG_WARNING + "%pp: VF without extended config space?\n", + &pdev->sbdf); } } @@ -1042,6 +1053,79 @@ enum pdev_type pdev_type(u16 seg, u8 bus return pos ? DEV_TYPE_PCIe_ENDPOINT : DEV_TYPE_PCI; } +void pci_check_extcfg(struct pci_dev *pdev) +{ + unsigned int pos; + + pdev->ext_cfg = false; + + switch ( pdev->type ) + { + case DEV_TYPE_PCIe_ENDPOINT: + case DEV_TYPE_PCIe_BRIDGE: + case DEV_TYPE_PCI_HOST_BRIDGE: + case DEV_TYPE_PCIe2PCI_BRIDGE: + case DEV_TYPE_PCI2PCIe_BRIDGE: + break; + + case DEV_TYPE_LEGACY_PCI_BRIDGE: + case DEV_TYPE_PCI: + pos = pci_find_cap_offset(pdev->sbdf, PCI_CAP_ID_PCIX); + if ( !pos || + !(pci_conf_read32(pdev->sbdf, pos + PCI_X_STATUS) & + (PCI_X_STATUS_266MHZ | PCI_X_STATUS_533MHZ)) ) + return; + break; + + default: + return; + } + + /* + * Regular PCI devices have 256 bytes, but PCI-X 2 and PCI Express devices + * have 4096 bytes. Even if the device is capable, that doesn't mean we + * can access it. Maybe we don't have a way to generate extended config + * space accesses, or the device is behind a reverse Express bridge. So + * we try reading the dword at PCI_CFG_SPACE_SIZE which must either be 0 + * or a valid extended capability header. + */ + if ( pci_conf_read32(pdev->sbdf, PCI_CFG_SPACE_SIZE) == 0xffffffffU ) + return; + + if ( opt_pci_quirks ) + { + /* + * PCI Express to PCI/PCI-X Bridge Specification, rev 1.0, 4.1.4 says + * that when forwarding a type1 configuration request the bridge must + * check that the extended register address field is zero. The bridge + * is not permitted to forward the transactions and must handle it as + * an Unsupported Request. Some bridges do not follow this rule and + * simply drop the extended register bits, resulting in the standard + * config space being aliased, every 256 bytes across the entire + * configuration space. Test for this condition by comparing the first + * dword of each potential alias to the vendor/device ID. + * Known offenders: + * ASM1083/1085 PCIe-to-PCI Reversible Bridge (1b21:1080, rev 01 & 03) + * AMD/ATI SBx00 PCI to PCI Bridge (1002:4384, rev 40) + */ + unsigned int sig = pci_conf_read32(pdev->sbdf, PCI_VENDOR_ID); + + for ( pos = PCI_CFG_SPACE_SIZE; + pos < PCI_CFG_SPACE_EXP_SIZE; pos += PCI_CFG_SPACE_SIZE ) + if ( pci_conf_read32(pdev->sbdf, pos) != sig ) + break; + + if ( pos >= PCI_CFG_SPACE_EXP_SIZE ) + { + printk(XENLOG_WARNING "%pp: extended config space aliases base one\n", + &pdev->sbdf); + return; + } + } + + pdev->ext_cfg = true; +} + /* * find the upstream PCIe-to-PCI/PCIX bridge or PCI legacy bridge * return 0: the device is integrated PCI device or PCIe @@ -1842,6 +1926,29 @@ int pci_iterate_devices(int (*handler)(s return pci_segments_iterate(iterate_all, &iter) ?: iter.rc; } +/* Iterate a single PCI segment, with locking but without preemption. */ +int pci_segment_iterate(unsigned int segment, + int (*handler)(struct pci_dev *pdev, void *arg), + void *arg) +{ + struct pci_seg *seg = get_pseg(segment); + struct segment_iter iter = { + .handler = handler, + .arg = arg, + }; + + if ( !seg ) + return -ENODEV; + + pcidevs_lock(); + + iter.rc = iterate_all(seg, &iter) ?: iter.rc; + + pcidevs_unlock(); + + return iter.rc; +} + /* * Local variables: * mode: C --- a/xen/include/xen/pci.h +++ b/xen/include/xen/pci.h @@ -126,6 +126,9 @@ struct pci_dev { nodeid_t node; /* NUMA node */ + /* Whether the device has (accessible) extended config space. */ + bool ext_cfg; + /* Device to be quarantined, don't automatically re-assign to dom0 */ bool quarantine; @@ -242,6 +245,11 @@ void pci_check_disable_device(u16 seg, u int pci_iterate_devices(int (*handler)(struct pci_dev *pdev, void *arg), void *arg); +/* Iterate a single PCI segment, with locking but without preemption. */ +int pci_segment_iterate(unsigned int segment, + int (*handler)(struct pci_dev *pdev, void *arg), + void *arg); + uint8_t pci_conf_read8(pci_sbdf_t sbdf, unsigned int reg); uint16_t pci_conf_read16(pci_sbdf_t sbdf, unsigned int reg); uint32_t pci_conf_read32(pci_sbdf_t sbdf, unsigned int reg); @@ -260,6 +268,7 @@ unsigned int pci_find_next_cap_ttl(pci_s unsigned int *ttl); unsigned int pci_find_next_cap(pci_sbdf_t sbdf, unsigned int pos, unsigned int cap); +void pci_check_extcfg(struct pci_dev *pdev); unsigned int pci_find_ext_capability(const struct pci_dev *pdev, unsigned int cap); unsigned int pci_find_next_ext_capability(const struct pci_dev *pdev, From xen-devel-bounces@lists.xenproject.org Thu Jan 29 13:08:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 13:08:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216439.1526392 (Exim 4.92) (envelope-from ) id 1vlRlZ-00043z-LY; Thu, 29 Jan 2026 13:08:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216439.1526392; Thu, 29 Jan 2026 13:08:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlRlZ-00043s-GY; Thu, 29 Jan 2026 13:08:57 +0000 Received: by outflank-mailman (input) for mailman id 1216439; Thu, 29 Jan 2026 13:08: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 1vlRlY-00038i-Mo for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 13:08:56 +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 aa3ecf93-fd13-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 14:08:55 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-48039fdc8aeso5725355e9.3 for ; Thu, 29 Jan 2026 05:08:55 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066bee687sm293711645e9.5.2026.01.29.05.08.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 05:08:54 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: aa3ecf93-fd13-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769692135; x=1770296935; 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=q7HeAt5kQvtbrf8+RdQ3a+ODredpYahprDWyAOhDj04=; b=SJRbApp+YKZyNb8nkAVx1JycJG3WI1/g0uJAIjhVi64nBX1IwFhuZquCKVwcrRZqXY mZXO4n5uBVoE5CrJtLuOp6H2nF2TySty6BPqPr2CGKIruZdXsJ5sc5/q8Cdv07LeUbyC 46o5D+jNoF9JeWdVUnoQRYcCP4Afwx5H+Y5VTq+BGaaTEQMmFYZgzRinRIP4cpzTj2SI J6D6kbfh1Z7I56eFnLQxJxsWlStTdAnAF2xKwHEPoKfDbQv1NIuaCkOGxYSguZFh2CwK D7ttA5rnT80SfUJJBz9f7maZJYGoEYkLzmjzamM95h5upaegeYvsx0FHRYM2jfoDzLL5 KZJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769692135; x=1770296935; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=q7HeAt5kQvtbrf8+RdQ3a+ODredpYahprDWyAOhDj04=; b=jSbGfjULW1flnIMxZ8o++KVRGRLviCdXeM/tj1G5il8vhbCSDyeOyhsHf19rKmQJWR VtJWShqVd9XXJUBiL9ogPa5tmtdY/NF4/awBFukNa2RRZDlfDwZ+Nshr+DYQBd6/X65t wYlUiSjb0X5Y1NRqVGcO+/c0uVirE3lXi1xB2GmcrbGHESGiEtWbboG/JEFIBSpDVzpR haoq7632lfbfe5aDXcDNi033SVqtwxO0sAHm8IW9CTfnK2XZTmaoB2cjVUVVC3wgeeT3 hl6c9QBhDbxKP9alfAppls7bdaMDUuesxN1WudjBtupf6ItQA4hYr1Ms79yZ6B3CTppl /NXw== X-Gm-Message-State: AOJu0YxlBRPcw+RWFnuc2fuAUspY7+agIaeVtahKb0Ffuc9WT4KsEB1m VpP1r5yFGngM860ojlf65g1VG6DkugelYZAx9fgBX442cOzvRQ30dQg6iCNiYQYK5joHRekizOt KP6c= X-Gm-Gg: AZuq6aLZqPJRNy/L1hQJISngsWDx2oPxo6SCmnLJr+VABrQDzxEDxMN5Pgke71+QFnQ HvmM5BfhS1/MRebiUW0lgS/131m+YfNXbCLSWgqY+S6tSHTSgOGp/BTJJUvlhLsNsWoL7ZmHUwJ I7iSMJhgSds/aGyyBxOnusb0aKxwAFniFCwLlGPN0Do+fg5SqxocAyDaWiUA6NBeddxZbg0Hmnm hsZXV+bwDPwtNbFChDP9V1iZ83N25i8azrXbayx6VAS9ykTFM+VFu3uLgJlNUQ14JW2Xo8x7op3 173Cp0wpUU/dtu6qzSemxlbA20I6SUwuTWRkc7nVPL/myJieh467DJqrfqEr/AbjM6ozdkLTnaK 65JAsXyr5pcASwAaFEUkBTGOYDn9MfdtHHrFtj1o7s1FEjTptkpeSvlZSg2TxdfvIPVkbkc/9AQ cfpzJGNdG3Xe4voZCIBfwH+fXMED38XHqRBY58uX7I48v+3ZAw2ltq9OUL0DqPKeVnTVzwPWWlc is= X-Received: by 2002:a05:600c:8b22:b0:47e:e61d:b8d2 with SMTP id 5b1f17b1804b1-48069c7c4d7mr112909255e9.27.1769692134608; Thu, 29 Jan 2026 05:08:54 -0800 (PST) Message-ID: <47c2fe41-c8c0-4c86-b3c7-8c7f96e59f1f@suse.com> Date: Thu, 29 Jan 2026 14:08:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v3 3/6] PCI: don't look for ext-caps when there's no extended cfg space From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand 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: 8bit Avoid interpreting as extended capabilities what may be about anything. In doing so, vPCI then also won't mis-interpret data from beyond base config space anymore. Fixes: 3b35911d709e ("Enable pci mmcfg and ATS for x86_64") Fixes: a845b50c12f3 ("vpci/header: Emulate extended capability list for dom0") Signed-off-by: Jan Beulich Reviewed-by: Stewart Hildebrand Acked-by: Roger Pau Monné --- Because of the multiple prereq changes, despite the Fixes: tags I'm not quite sure whether to backport this. (I'm leaning towards "no".) --- a/xen/drivers/pci/pci.c +++ b/xen/drivers/pci/pci.c @@ -113,6 +113,12 @@ unsigned int pci_find_next_ext_capabilit int ttl = 480; /* 3840 bytes, minimum 8 bytes per capability */ unsigned int pos = max(start, PCI_CFG_SPACE_SIZE + 0U); + if ( !pdev->ext_cfg ) + { + ASSERT(!start); + return 0; + } + header = pci_conf_read32(pdev->sbdf, pos); /* From xen-devel-bounces@lists.xenproject.org Thu Jan 29 13:10:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 13:10:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216448.1526401 (Exim 4.92) (envelope-from ) id 1vlRmh-0005XT-0H; Thu, 29 Jan 2026 13:10:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216448.1526401; Thu, 29 Jan 2026 13:10:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlRmg-0005XM-Tb; Thu, 29 Jan 2026 13:10:06 +0000 Received: by outflank-mailman (input) for mailman id 1216448; Thu, 29 Jan 2026 13:10: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 1vlRmf-0005LI-I4 for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 13:10:05 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d32ce607-fd13-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 14:10:03 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-4801ea9bafdso4120375e9.3 for ; Thu, 29 Jan 2026 05:10:04 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066bfb59asm183476535e9.7.2026.01.29.05.10.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 05:10:03 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d32ce607-fd13-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769692203; x=1770297003; 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=gmIbWuEiblilxseM1vB5o3yWlIHmhzxF+tqb0Hhe36U=; b=PHDbP831jtwSknvsWqhq8keOFejbal+hFI6rKbYBaTKE2T2ZRNORE4b0oQrSwfG2yt ygtL+5fUg5DHHvLKPEwH2jXuUFtM+oSNUio/nLKUjrnjH5D+1VNV9YmcvIoP+wzRX9xE yQM6NOLeww1GLY2BCzHr0NXvkO7ypUXCCNUxos+ZnRY86ACPAa4XuHNNjE6da1gzsm2g MxbVutwHJ0u5D0/liNUdYSaxa1+2cU6Z78yfdo2nH3tc81SFE461keBJjxGUQL7oInE8 +Kqo4y0exBvyhtxycTpr3827yfkkz/HCJOB3XfspU0G/Tj4Ek/hbZ3/YpyIKH7PvW6Qf P6IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769692203; x=1770297003; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gmIbWuEiblilxseM1vB5o3yWlIHmhzxF+tqb0Hhe36U=; b=tU1EA+QY0Gi+kW9wB22WBfBwBXZJJ7afEnpUbv1HLOWe1gIN7Q2HKfivtnXABw88Qg A04VS0UGVIlZ85U0oeA0joVsLcjYpnED02QETS1fpzxz6KeQhzG1PuUUEJEF1MX+Fw9M z4PXQbqPbjrVMkCdU93GC2vCKZQx/yrgiSKBqnvaVHGZQ8lhdPgjYKezzTo/rJE5BLfP Xbr8rnZJeqAndUoNDGHshPKhzGb92yfLOVH0EKyB9wQpOK6DIW6E6XBCkG8GR6Uq4sew vF+tHD+aNaOZBYZl/WvKNRuYBifhhgunPtLAsJ8KfmkUIpXq7kSq9vd4LaH3kb0fSjad yVzw== X-Gm-Message-State: AOJu0YzfwSyUMsa7hKyOSPLjBxBPLoUzjoRBdEXYDHDlMgtX4pMrp4i0 5+Gh22SOLE93NHl42y1GKcJHHy6nXbfIWdGkAnvk9hAybjRK7DWt5IK27t5WcW+ZSWbFHA7Zin7 S7ls= X-Gm-Gg: AZuq6aJ+upLtuEM/X85C1ZtKSTCDkXSlRIrficNRCuKmdWCUow5V1/MqWL+uDiwZj/h oF1zTUf86YjD9ymHSID0WA2XJ/z4irdT/RujbJKn9jX2rB9qDjErpv8nSvRPKUN+QSSHNYPSk3T mr1c14Uc5wUKFATMZ21vpTYl79Kaag0I6o/9R24FsIBmjWO6X1+DFXGOFIp8oIliky++Uw6I/qG 6E5ZPXS15iQ+mGRU/efykQ+9+8m+36CQABxXV8zulH+QGQIvGKQUdXFw+ycUdoBX8YXucSDSclg c4MKvBArE9tDX1wccFvp4I5bcloOytJCkCF407zlDra5MEMunBic/3we1T2kn4Y43b4ti2dzwJQ AIP6diV2gRIR/eCGiQedbokFA+L2Trrm1opBelhKIJ8ppoyRPGhMmXeF1NFPnXc5pCg64ORxF45 ibMcfWKenKTcNsR88nspq/IcktBnERC0jS7O7fZWug3vf/RPKpVA9ZaadiTX+IAJj/nBhGkL2HL o0= X-Received: by 2002:a05:600c:4e8b:b0:480:4a4f:c366 with SMTP id 5b1f17b1804b1-48069c486e6mr97299665e9.20.1769692203387; Thu, 29 Jan 2026 05:10:03 -0800 (PST) Message-ID: Date: Thu, 29 Jan 2026 14:10:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v3 5/6] x86/PCI: avoid re-evaluation of extended config space accessibility From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand 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 When, during boot, we have already correctly determined availability of the MMCFG access method for a given bus range, there's then no need to invoke pci_check_extcfg() again for every of the devices. This in particular avoids ->ext_cfg to transiently indicate the wrong state. Switch to using Xen style on lines being touched and immediately adjacent ones. Signed-off-by: Jan Beulich --- v3: New. --- a/xen/arch/x86/physdev.c +++ b/xen/arch/x86/physdev.c @@ -528,6 +528,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H if ( !ret ) ret = pci_segment_iterate(info.segment, physdev_check_pci_extcfg, &info); + else if ( ret > 0 ) /* Indication of "no change". */ + ret = 0; if ( !ret && has_vpci(currd) && (info.flags & XEN_PCI_MMCFG_RESERVED) ) { --- a/xen/arch/x86/x86_64/mmconfig.h +++ b/xen/arch/x86/x86_64/mmconfig.h @@ -74,6 +74,6 @@ int pci_mmcfg_reserved(uint64_t address, unsigned int flags); int pci_mmcfg_arch_init(void); int pci_mmcfg_arch_enable(unsigned int idx); -void pci_mmcfg_arch_disable(unsigned int idx); +int pci_mmcfg_arch_disable(unsigned int idx); #endif /* X86_64_MMCONFIG_H */ --- a/xen/arch/x86/x86_64/mmconfig-shared.c +++ b/xen/arch/x86/x86_64/mmconfig-shared.c @@ -388,8 +388,9 @@ static bool __init pci_mmcfg_reject_brok (unsigned int)cfg->start_bus_number, (unsigned int)cfg->end_bus_number); - if (!is_mmconf_reserved(addr, size, i, cfg) || - pci_mmcfg_arch_enable(i)) { + if ( !is_mmconf_reserved(addr, size, i, cfg) || + pci_mmcfg_arch_enable(i) < 0 ) + { pci_mmcfg_arch_disable(i); valid = 0; } @@ -417,8 +418,8 @@ void __init acpi_mmcfg_init(void) unsigned int i; pci_mmcfg_arch_init(); - for (i = 0; i < pci_mmcfg_config_num; ++i) - if (pci_mmcfg_arch_enable(i)) + for ( i = 0; i < pci_mmcfg_config_num; ++i ) + if ( pci_mmcfg_arch_enable(i) < 0 ) valid = 0; } else { acpi_table_parse(ACPI_SIG_MCFG, acpi_parse_mcfg); @@ -458,10 +459,11 @@ int pci_mmcfg_reserved(uint64_t address, segment, start_bus, end_bus, address, cfg->address); return -EIO; } - if (flags & XEN_PCI_MMCFG_RESERVED) + + if ( flags & XEN_PCI_MMCFG_RESERVED ) return pci_mmcfg_arch_enable(i); - pci_mmcfg_arch_disable(i); - return 0; + + return pci_mmcfg_arch_disable(i); } } --- a/xen/arch/x86/x86_64/mmconfig_64.c +++ b/xen/arch/x86/x86_64/mmconfig_64.c @@ -138,8 +138,9 @@ int pci_mmcfg_arch_enable(unsigned int i const typeof(pci_mmcfg_config[0]) *cfg = pci_mmcfg_virt[idx].cfg; unsigned long start_mfn, end_mfn; - if (pci_mmcfg_virt[idx].virt) - return 0; + if ( pci_mmcfg_virt[idx].virt ) + return 1; + pci_mmcfg_virt[idx].virt = mcfg_ioremap(cfg, idx, PAGE_HYPERVISOR_UC); if (!pci_mmcfg_virt[idx].virt) { printk(KERN_ERR "PCI: Cannot map MCFG aperture for segment %04x\n", @@ -160,10 +161,13 @@ int pci_mmcfg_arch_enable(unsigned int i return 0; } -void pci_mmcfg_arch_disable(unsigned int idx) +int pci_mmcfg_arch_disable(unsigned int idx) { const typeof(pci_mmcfg_config[0]) *cfg = pci_mmcfg_virt[idx].cfg; + if ( !pci_mmcfg_virt[idx].virt ) + return 1; + pci_mmcfg_virt[idx].virt = NULL; /* * Don't use destroy_xen_mappings() here, or make sure that at least @@ -173,6 +177,8 @@ void pci_mmcfg_arch_disable(unsigned int mcfg_ioremap(cfg, idx, 0); printk(KERN_WARNING "PCI: Not using MCFG for segment %04x bus %02x-%02x\n", cfg->pci_segment, cfg->start_bus_number, cfg->end_bus_number); + + return 0; } bool pci_mmcfg_decode(unsigned long mfn, unsigned int *seg, unsigned int *bdf) From xen-devel-bounces@lists.xenproject.org Thu Jan 29 13:17:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 13:17:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216466.1526411 (Exim 4.92) (envelope-from ) id 1vlRtq-0006OD-K4; Thu, 29 Jan 2026 13:17:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216466.1526411; Thu, 29 Jan 2026 13:17: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 1vlRtq-0006O6-GS; Thu, 29 Jan 2026 13:17:30 +0000 Received: by outflank-mailman (input) for mailman id 1216466; Thu, 29 Jan 2026 13:17: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 1vlRnE-00038i-DI for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 13:10:40 +0000 Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [2a00:1450:4864:20::433]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e7478094-fd13-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 14:10:37 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-42fbc305914so946701f8f.0 for ; Thu, 29 Jan 2026 05:10:37 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e132303fsm14536283f8f.36.2026.01.29.05.10.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 05:10:36 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e7478094-fd13-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769692237; x=1770297037; 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=Tv0OvyCcYzBuokmRIqcrOcEo5thGITFjrVvRj+Q4tm4=; b=NlAg3sw3HbqeIbmpm19W2MZRsveJaTpDi0QEbhUVd3ViSsXbuO7qqg4aSqFbL7Yqg9 GzQb6sSb6eX2/rr2Jh+g1/tlCRtr3z8pNvNud4snS1SDyQk5844cryHGON7YuU3h8VgS 8dYTtqfiwk+I/muEGVhRL1TwwlXeckuebtbFMg2iTcVcfoECRoaAbAA6O++zj2GonDqu ekCMm9XlIMroOUyHkztkXMyovBbciU55yMGdkTHNHb1RdQpuPvTeb6V0g5e5snrQhJli oCOohy/5sUHUdIs08jaAGhuu1N31lFuyovwDlg6SSq/mfUhUxh6w+omtQGQlMB+592AO hpww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769692237; x=1770297037; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Tv0OvyCcYzBuokmRIqcrOcEo5thGITFjrVvRj+Q4tm4=; b=bP/W+/REAJIPU7TEUOi7k1Bqtr5WX5zYMcCujeC7FpOcHMqdgxaeYFwxhMZ4WiIK5q aF0y4EFIpf0Qq1+6kFiE/XevueMiMOd+dtL1jeLyOywv6MAw1/3fxVDy5+FWA2b6ap+e 6KIRoIj12cfauIJT/oz2xQir/CblbOO8wNBAmeFn7IBIBDbnmxC0xCL5dJMaP4KRgqVx QThJzLP9x0KIHcvpyKOMeOx+5izJWuhY/sBsaju3Q+JhdmfAhEcW7gDTZBL5XlCEod3h qpwmAh2BiYaHDWdMTMrzH2/+NyZrPbkWZitxFG0ERtgVqLsez5uTBHwBMangYqlfEn65 RaWg== X-Gm-Message-State: AOJu0Yw6CbEbzS3BB0CLAvWU7n6ZtvieE4S8wQ++5/Zjnil+71/SLn/E dOQwb45kHkWR6+y012wSK5jbkMsv2rOn+19PISw6lN0uQvIzur4c8xG9UAxMZiUQyh7b8AeWR57 DAWM= X-Gm-Gg: AZuq6aJ2cSpTVP+SFs5xHu6wOCMsoQX3bz1WI+0bRCdOrveGf0shfzI3qMgRSFfP6/I sKSA3EJStAs5i2zD7SLn1LOwTSCU7TcVz3pMaSICKrSs6Tt9zDbtl7JWqNEqRfGRgO8Ce96P9eu pbc4JTXSdbSSd5EZOjDT8qFwUUauwOU+ZseNT8cX45hqjxH+NKesADz/xeWLZHp5Rkrh0oPQcWe io/bRfF8KQU3iGMaI2jTJhno23tbQ+MDUN6kXya3JR6WCVh9NTjj1qy9m8Ztp9WnGs/VYv2JoZN cpQ7lw3T5RPdr345ussDCGoVffK0LF+lOW8CmalZyhRxVArY2AULS1cv63vu5aWJexYB9hbBauX kXGF25waL8hIdMEBhqSKouSw8RdqXYlQnhohXfgMNc+h6c8ZDmrG0f521tEnPVMcQBEQULggdxu CDd2Bo3Ol8H0vggM8JOtsS51I9Qatf3ayECYpIfxpibtsOxE/aEDcLbf66TfvQEWzNWWO/dIHSp Pn0DJUM6cgStQ== X-Received: by 2002:a05:6000:2082:b0:435:a9c9:159 with SMTP id ffacd0b85a97d-435dd05aba3mr12142676f8f.18.1769692237050; Thu, 29 Jan 2026 05:10:37 -0800 (PST) Message-ID: Date: Thu, 29 Jan 2026 14:10:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v3 6/6] vPCI: re-init extended-capability lists when MMCFG availability changed From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand 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 When Dom0 informs up about MMCFG usability, this may change whether extended capabilities are available (accessible) for devices. Zap what might be on record, and re-initialize the list. No synchronization is added for the case where devices may already be in use. That'll need sorting when (a) DomU support was added and (b) DomU-s may run already while Dom0 / hwdom still boots (dom0less, Hyperlaunch). Signed-off-by: Jan Beulich --- vpci_reinit_ext_capability_list()'s return value isn't checked, as it doesn't feel quite right to fail the hypercall because of this. At the same time it also doesn't feel quite right to have the function return "void". Thoughts? --- v3: New. --- a/xen/arch/x86/physdev.c +++ b/xen/arch/x86/physdev.c @@ -8,6 +8,8 @@ #include #include #include +#include + #include #include #include @@ -169,7 +171,10 @@ int cf_check physdev_check_pci_extcfg(st ASSERT(pdev->seg == info->segment); if ( pdev->bus >= info->start_bus && pdev->bus <= info->end_bus ) + { pci_check_extcfg(pdev); + vpci_reinit_ext_capability_list(pdev); + } return 0; } --- a/xen/drivers/vpci/header.c +++ b/xen/drivers/vpci/header.c @@ -869,6 +869,18 @@ static int vpci_init_ext_capability_list return 0; } +int vpci_reinit_ext_capability_list(const struct pci_dev *pdev) +{ + if ( !pdev->vpci ) + return 0; + + if ( vpci_remove_registers(pdev->vpci, PCI_CFG_SPACE_SIZE, + PCI_CFG_SPACE_EXP_SIZE - PCI_CFG_SPACE_SIZE) ) + ASSERT_UNREACHABLE(); + + return vpci_init_ext_capability_list(pdev); +} + int vpci_init_header(struct pci_dev *pdev) { uint16_t cmd; --- a/xen/include/xen/vpci.h +++ b/xen/include/xen/vpci.h @@ -45,6 +45,7 @@ typedef struct { REGISTER_VPCI_CAPABILITY(PCI_EXT_CAP_ID_##name, name, finit, fclean, true) int __must_check vpci_init_header(struct pci_dev *pdev); +int vpci_reinit_ext_capability_list(const struct pci_dev *pdev); /* Assign vPCI to device by adding handlers. */ int __must_check vpci_assign_device(struct pci_dev *pdev); @@ -300,6 +301,11 @@ bool vpci_ecam_read(pci_sbdf_t sbdf, uns #else /* !CONFIG_HAS_VPCI */ struct vpci_vcpu {}; +static inline int vpci_reinit_ext_capability_list(const struct pci_dev *pdev) +{ + return 0; +} + static inline int vpci_assign_device(struct pci_dev *pdev) { return 0; From xen-devel-bounces@lists.xenproject.org Thu Jan 29 13:17:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 13:17:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216468.1526421 (Exim 4.92) (envelope-from ) id 1vlRtu-0006gE-QT; Thu, 29 Jan 2026 13:17:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216468.1526421; Thu, 29 Jan 2026 13:17:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlRtu-0006g0-MK; Thu, 29 Jan 2026 13:17:34 +0000 Received: by outflank-mailman (input) for mailman id 1216468; Thu, 29 Jan 2026 13:17: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 1vlRm8-00038i-7Y for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 13:09:32 +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 bf433566-fd13-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 14:09:30 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-4806cc07ce7so8666835e9.1 for ; Thu, 29 Jan 2026 05:09:30 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-481a5d4b5ecsm4080235e9.2.2026.01.29.05.09.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 05:09:29 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bf433566-fd13-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769692170; x=1770296970; 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=K7IkmbOcHe05WP2EwO1MxrERnpyx6lY4fuz+tGdEjyM=; b=TSM6LIAgtYMAVj+7QVxEfHVxAiYpj28bBpEMKAO3kSoz0hrp0iujaxE/Cezj7c0pUF KcAh20VPNKHRPqJzo979qIfsDJ0QTJIBQeinA/rTq/ZtpqZpmlsz5BeRekQcdHPcHXH7 4jn19Xx2UkLICeAJPizH/ilaOewx+rDjBaCgLTnhwTOACKFhrTPn7M6xD1GLNou5mUqZ mew5vM/3LDVpw4ZLBiKdL8gbX5WFXJ5ve0Ayvx8/e8KFirKudk1W0RraYBLfxnskLD+a 0BRvEindFLWXPIivVrA1JNFW7s+8vnm4Tfvh1wLoHQxzyEkjFw7IfwfCjGz7dnEJU4C1 epyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769692170; x=1770296970; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=K7IkmbOcHe05WP2EwO1MxrERnpyx6lY4fuz+tGdEjyM=; b=aO84B064M6+JOPyTZfmjndgv4WCHNgDl+ZHg28zOvU+x2nLnxwtoRe+3OIm5o3KQFu aFTAgAzbOOTPquC0iqYCmKhxw039mW7WFxUJNsNftqufBBWotlfuKZ8UEe/OiRQoVcHr Kgw9/diX0vAVKRopwTZ0N/eTmeGrGdLT9ZI2H1AFWWSarwJPWh2WrOs7g2RhLBG5woXS HBOKD0cw/4YMFrZfM2c16L2E+1KOabWMX7lp/mFVZo/bjhmCE4oHw2jLUy1hquGt+10T 13mwp++7haoWrhPOSkcK41VD7d0g3h+xuDi8H7GTSavWulDsjdOE52X9FxrnIy9mQGzQ QWww== X-Gm-Message-State: AOJu0YxYzQHVbN/yg/0eL9BNBPUckkRuQF93quX/Fjcwpk45i3O8X1GB yftTslBUneCokr/M5MJ3DYDNWfcKyaUui7YIJd4tUdqH87U6AhYUzmErKGxo7J3I+MtBV7J6++L GfAw= X-Gm-Gg: AZuq6aLAPBD1B0/bErmgIjZrfD0sMF0O3A2LmRgfYW/0ehLawD0UZngOdMJwFqywDOQ Oku3aplHOYA9Wrx4exPeoMinw8iIJk0Pp6/Im1+ZoIQpwv3PyW9wGmNF/but8EKHxCLYzoX22Y+ GzW4CNG0SQSykZFpGBlVwtD9mX1x/bObiOjRzUOx/wqmybCS4lEVqNhegsydSca0QGtGYML+q/s hJpMw98FRnQqY+bkP6gNKsHZHfDmd/sH0FKk96UmWGieyhdXkuJHdY+2TmjtRYaSbYqJM8WwCA0 g9fLU9rBB38qmwZ3VKpgas+tQbhV/YQEitZSUqVhHxW+TW6lT76NE0RlPKV7BIMHl5WTDlGYo5J NYDEZ797cqmy1mM9ZCigkD9igXS5Ow8dHf8OotjJemiki2NG6FkB+faJWDbONLB3pqF7JKewQZA 2v+UYtIxJbOMhwElm4MuflhJbNfg8A2Q+jjRoZz6L8/TFHwnty91iRObSuNC96LhF7wlz1uL5xq yo= X-Received: by 2002:a05:600c:4689:b0:477:9574:d641 with SMTP id 5b1f17b1804b1-48069c5bd29mr121741155e9.22.1769692169912; Thu, 29 Jan 2026 05:09:29 -0800 (PST) Message-ID: Date: Thu, 29 Jan 2026 14:09:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH v3 4/6] vPCI: really no ext-caps without extended config space From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand 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 For DomU-s, whether to emulate accesses to the first 32 bits of extended config space as read-as-zero or read-as-all-ones depends on whether a device actually has extended config space. If it doesn't, read-as-zero isn't correct; not getting this right may confuse functions like Linux 6.19-rc's pci_ext_cfg_is_aliased(). For Dom0 this then simply allows dropping a later conditional. Fixes: a845b50c12f3 ("vpci/header: Emulate extended capability list for dom0") Signed-off-by: Jan Beulich --- v3: Move code condition to top-level function scope. Eliminate a later conditional in exchange. --- a/xen/drivers/vpci/header.c +++ b/xen/drivers/vpci/header.c @@ -829,6 +829,9 @@ static int vpci_init_ext_capability_list { unsigned int pos = PCI_CFG_SPACE_SIZE; + if ( !pdev->ext_cfg ) + return 0; + if ( !is_hardware_domain(pdev->domain) ) /* Extended capabilities read as zero, write ignore for DomU */ return vpci_add_register(pdev->vpci, vpci_read_val, NULL, @@ -841,10 +844,9 @@ static int vpci_init_ext_capability_list if ( header == 0xffffffffU ) { - if ( pos != PCI_CFG_SPACE_SIZE ) - printk(XENLOG_WARNING - "%pd %pp: broken extended cap list, offset %#x\n", - pdev->domain, &pdev->sbdf, pos); + printk(XENLOG_WARNING + "%pd %pp: broken extended cap list, offset %#x\n", + pdev->domain, &pdev->sbdf, pos); return 0; } From xen-devel-bounces@lists.xenproject.org Thu Jan 29 13:49:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 13:49:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216501.1526431 (Exim 4.92) (envelope-from ) id 1vlSOd-0002w9-2e; Thu, 29 Jan 2026 13:49:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216501.1526431; Thu, 29 Jan 2026 13:49: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 1vlSOc-0002w2-WB; Thu, 29 Jan 2026 13:49:18 +0000 Received: by outflank-mailman (input) for mailman id 1216501; Thu, 29 Jan 2026 13:49:16 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlSOa-0002vp-Qy for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 13:49:16 +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 4be88eb7-fd19-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 14:49:15 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SA2PR03MB5916.namprd03.prod.outlook.com (2603:10b6:806:115::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.5; Thu, 29 Jan 2026 13:49:11 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.008; Thu, 29 Jan 2026 13:49: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: 4be88eb7-fd19-11f0-b160-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=hcOm18oYUpeX60g4FxydTReMOdfwUWjQrPkGxZGU6UQhtZM6CeidKICQG6mhMvCLWFic5qJqwBTNu4eh8haWi48rVJMUHSkP43b8su11Y3XQsldOWZ9sAHittp0/JBZAGO5Ffz5cOxhVsXCDbhFHWWhrSKt+nyTXop+EW+hDuirGjz4Vy5NZoFiczKLOJZVLsYJapSk/aA7Ne+a9GH9MJexlYB1R0OrnHWq6EPf1LNUyLsXOfQ0GGGs+G9ypEm8Kr1htIEciNT8uy99bvdBFZHtaj9H3m2Q3AxgzSF+KNSDxVpeRDVrQX+5xqynjRJgJCwqjUZYHgvOIvgs0/w1/6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GXG2L140Q6a+1NIVBeXowomtFmmyhFvIktezcSn5/wk=; b=avDTsJINVul4jK+POk8Z4/2GyGa/ubv8FzgvLvhq1F5EzJ7v+B6gxzwCcbdKV//oIhIJ6U6BIFfMy+XlYIC6EWugqbdIwzkBwdpz+zwdQrk9SzRpl9KaR66R2BumSup0vtXAxN9r3llnZVlR+fO1tDWX85UZPwQgARUJ+KMMU809wmGaf9OLCp60HDTeB20DyZ4eB94EGyIdpqOkyP2sb5rxlShdx4peXY2LzMjef+QJ3VUIHKzohGLCDHJ3PAgFRG/i9NN5x8wSIw8PZEuq3WLtrC9L4uB1MHPMH+i7XbwI6I2VIFRC/Ni90+2gka760TEnELerfZeJcbdsqeZ29Q== 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=GXG2L140Q6a+1NIVBeXowomtFmmyhFvIktezcSn5/wk=; b=aBt7Y3banqPnL07GUiUcg6RLWjPV4biHaKOFY/D1vmI8JZEdpc/fX9BksXmL2qr9mhJHAuL8jdiT0BafPyU5ylWdMTHZMX4Dc16iQAnqrvPbfl7cxIaRMdQmBhZcO6XD/63Xuh8HxnEuUWru3S/iriBiFx1o7n4/eqf01mZQ1vo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 29 Jan 2026 14:49:08 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , Stewart Hildebrand Subject: Re: [PATCH v3 1/6] PCI: handle PCI->PCIe bridges as well in free_pdev() Message-ID: References: Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: MA2P292CA0024.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250::6) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SA2PR03MB5916:EE_ X-MS-Office365-Filtering-Correlation-Id: 589f8a78-73f9-49ba-20a5-08de5f3d2e8f 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?YlZHMnNjQ3FsY3BsOHp2ZkJmMHdSVDJuSnNZNi9KOU85VUR1UTlreUVCb3ha?= =?utf-8?B?VThIS3lOWFc4N1FYRk9MSVhDSGN6YWw3bXNOSkxRZTh1MVQrYmVURHMvQis5?= =?utf-8?B?eFZEQmdtQWxvVzhLditXSkhPaXlzc3d4ZHJoMm9OWmpGOEQxOFFQNzdDNHR6?= =?utf-8?B?TTQrQjNzNGRNbkhVMVltWXdULzBTSVo2QklXU1o1VlZXbDJRejcxYWxhZTNt?= =?utf-8?B?VGxBTDFFZFBsT2hhMDJxVjZXZGpuUm9KbXdISjdaQ2xOcDNlUVp3OEtDODZq?= =?utf-8?B?dUJ1NytxZlg3ZXQzb3FTVENEcGlnVmRLVThLc3RreXpvaUVxaHBESDZOU2Nx?= =?utf-8?B?bjd2blZGZjN5ejZHSElnMldia0NPWkdhbDNhVFQ4TWlHSm5Bd2tVclFLQnJZ?= =?utf-8?B?R1JMalNaa08zVDl6L1JxRWJmRmhmSFBmc1UwMndlYXpVUnJ4akZtNmlxSUNh?= =?utf-8?B?eVh5dzNsOGNEcWJOSm5VWWNGU0FLd2s2TWtmVE9DVDhNcWRhc2lHRDR1TTJk?= =?utf-8?B?RHljTFhIdWlqTTM1VUdyUGd6aVFseXNMZHg3Rk5OejB3V2MvaVFQZXFMQjZ6?= =?utf-8?B?elloMktHekJUSEtKeU1PWUtoa3NtRDhTRnh5RU5QYzJEL1d0dDQrZFFFd3dV?= =?utf-8?B?eVpuSG1PSUI2eU1GL2llblRpdlgvNytXQkhoQll5K0ZCeVlwbm11eUh1S1FX?= =?utf-8?B?c1ZnaXI5ZmFlNjRSN3d6a1U5dUxQeFpDcWtQOHc5V3VTTlRGNTNWZmloUEVw?= =?utf-8?B?VTYxZzdTUU1qOHRqaWh5OVgxNHo5dE16RlBYaDNDeVlocUpPV3Y2NHl4WGhp?= =?utf-8?B?aG1Fckt1SVk4bTJHb1RqODNQL1ZLNUtQTVJqUzJ5T2dJdUUvQWNxZFd5U0Fv?= =?utf-8?B?SkxhM1YwUkRvbjVMQjFFRjhaTGZ4SlBCWHJuMHhLdGhNWVAvR05nSTBQaWhM?= =?utf-8?B?bThMZEprd0lCaXFUNmF3bUVmZGtUWUhBeHJmNzJPTFdab09qekYzMW1iS0xD?= =?utf-8?B?SFpMS1JtVFppb24ramF2TlNSNk1EQ0JuUnZkUVFJQzZGeWhFS3UxT25EZEY5?= =?utf-8?B?WlRNZ0F0NmloOGRUSXRZVkFlY2lhZE1uand1SWNCWnR4YzdnSmFJWTYxbHFr?= =?utf-8?B?ano0OHJWL1J0QVhraTRtQVorQW9EbEhTNzBMMkd2bFN4aDBaaVA2cTVsN1Iw?= =?utf-8?B?c3h5cnFpK2Q3a05XVXJIbG82dnNZQ1JJWU1SK2lXYkxwZlpoRzlacnlyRjZn?= =?utf-8?B?Uyttc2Fyajd3dEhiQytHa0RWMnBpQjBaYWpqeE9qMW14WWRJd1ZMaXJUS3ZV?= =?utf-8?B?WTZJRzlMOFNsM1lCSHB1aDBvbmZYVHMrSFY0ZzdoaDhWZXNoeHErL3RzakVi?= =?utf-8?B?eWVlZGhFZDFzS0pRZ2hORmJnSG55WTFsd2thSTlFYWxPVHpFVFd4aWh5blk0?= =?utf-8?B?TitmbDVhTmpTMllKRkNmT2tFSHJRcm5HM0ZYOVQzeWhwSENvTHlsSHNVMHlD?= =?utf-8?B?YXczem11ekhEa2RvakVNNndiWGRyNUdmS0prcTZyT3FmT1BVRGtOeDBwd3hL?= =?utf-8?B?TjNCdE5zcXBWa2NpeW1QZmxITlp4Tnh6bVBBb1krZ3dYalp5WDExMWw3RjlW?= =?utf-8?B?bUFNZWdQcjY3ZzczY2MyaFNFek5OZGRXZjlaM0VEaGxsN0JvSUtyUytIdmdH?= =?utf-8?B?dVJuSDJrT2IyMlQrbGNYUzFKSEwzaXFjeHo2Q1BFdkM1NlBiZ2IrL2xKR05D?= =?utf-8?B?ckFGUG84ZUJMdTFoQ2lBeHdWbWZ3MiswSWtlMm1iY3dwc0c2WUU3amhmRFQ1?= =?utf-8?B?clp3RVFWZXY4TEx2ejZoQmpYaW9DMmM5N3FzVkJWdEU1bUhaOXgraWVCT05z?= =?utf-8?B?enJVNzV0VnVxQkFxaXY3Q1hyZE5KUnVReUZIY3ZvV2JSK09uZVhQc2dUSFp3?= =?utf-8?B?WjErR1d3TVFUekU0N05HOWJSb2JFem5RdVRkQm5OK3M2M1plcjZ1YXlNQmo4?= =?utf-8?B?S25ib3BkbkFCNGhtTnExT3JrWVU5ZkpqakFxUzNKbWd5SnRvSFBIOFZnaURS?= =?utf-8?B?ZzhmTmp3cmFlck1QbVUwSk0xRWJvUUhiUUdUTng1QzlGeTk0R05BNjVlWUYv?= =?utf-8?Q?iMwE=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Slk4RHJXNTVmUDFPclB5SXQvK0wrbVZhWkxmZHNycEpTazI3MHBjaVJDVG5n?= =?utf-8?B?dmxaNUpodmZhZHBHa1dmVWgxS0d1bjFkdW8yaUMweS9oWWQxUFRBMXZHaU5V?= =?utf-8?B?Unh1Rzl1SkFScXZtRUZzUlVpTXBZYkM4cFhhL21HZTdDWHNSaW9aOVN3N3JZ?= =?utf-8?B?NXRoY09EVVgzTFdVZE56N3B5S3AzajNzaUxFY0VIZXMzdHhPUGZVVXlYVjd1?= =?utf-8?B?UnB6U1h3cXBDN0xlYk1rdEUrYjBVaFovYVEzV3piRmJqc2tQZUg1bGRRUjFu?= =?utf-8?B?dEJ6RFNKeGIvaWF2dldwWHpzUDdiWmdjUWUrcjdkdGozblJOV2ozYlpHWlVT?= =?utf-8?B?NzBiR2lzdm1USmZ1Z0Qzc3ppWE81aWd6cjNuWlVtQVIxeFl3RHlBUnhaY3F0?= =?utf-8?B?bkoyRWk0MHEzSElOUXVTNVp6aC9Za29qaVUwNlJ6TUZBTERsNEh4dHUzMTZ6?= =?utf-8?B?MWM1OENtRzBwT092THF1T2JyWDg1S2tqbG9jYWw3ZEl4dUdPTnpzZWc0YkZX?= =?utf-8?B?eVk3a01yWFdOa1J5blNUSDdkNDd3d0NwaGdzcXdhbWN3aXdQZGplYnROdjdF?= =?utf-8?B?bE5zTFdKM0NUV2hCQ2FHWHF5U3o3anVadzAyZjFSaXdqTktvM0ErR1RpTkhM?= =?utf-8?B?SmxGQVR0UElIWVhuTnpxZ3pwV0hMMEp1Vmw1QlZCVlVvV3pGVEVZSS83UFg0?= =?utf-8?B?MG4xNm5FWXc3Wks0a1JRNkhtbGhaZ00rUWVudDkyL2lYV244NVB0U25lWmEv?= =?utf-8?B?YUQrQWFIOGJHeW1NZzU1aXZwd3V5VDRzL0piRlVhWkFrS2dDQ1dJSGRhUURk?= =?utf-8?B?OHZ2aDdkWHh0amQ0NlNFVHo4Q0pINEpmOVZuUFlRa3J2VVpIOHNzVklsaG1I?= =?utf-8?B?ZlQ0djF2NXQ1Z2RYNmFPMmxpbHdDMCs4M0QxYlJSZXZaakxyRFF6cm5tRXV1?= =?utf-8?B?c3RwS0s2R2EvK002NTlNdWgzV2xMZCtDUWdxK2hDMml5NWs4dVhEem9ndkxQ?= =?utf-8?B?Si92TU1sRGZjdTBySFcrQ28zWXdMdUhQbEk0Z29sWERPVXJKSkhXZFJUSExD?= =?utf-8?B?a09kMUFuTkp4U1d2T3hkdmhsYjdDU25hUkRDZ3JYUVJGUGt4Vzl0MitXaE5M?= =?utf-8?B?eml2ODFHTzV6UUkvaGhuWFpyOUZISVVvVWJwWEFlTEY0dC9vbU1lL2crQVpB?= =?utf-8?B?NEZNTVNTMlp3ZXpVbUNrTkozelg3U3B5dTlXb3E0UVQyLzhKVllPTjBVUmJy?= =?utf-8?B?a0VzOGpsekNQT1Q4M3pPZm1Tb3BXTHRkSUZhRUNtT0dPb0YydnZHVHloMmVK?= =?utf-8?B?dWN6cDBzWWJreU5ncmFwd3hsRnZqWmI3cDRzZlBzSXdnUXA5QVNlZzkzYnhI?= =?utf-8?B?R0lnRjRaNW50T0FIbjNFbTRyWVVDTENLSTJ5MmJvVDRJcjltUE1iWE1USGFx?= =?utf-8?B?eXZtZWJVQXkrOTZHQ3JRRFVjMXAydGc0UXovVnpTcWM4YUZXbUY4U1l4cmpT?= =?utf-8?B?cnhGUWZzdGwwbzMwUnpObFhua3RYTm5kY1Y0Q0sxUFVlQ0VlcUliWUpCbDhl?= =?utf-8?B?VkJxTXpUUmdTdnRKWTVGYmhvS284UkZuV3lZZkovL0wyMmZPOUVQbGRQQ1A5?= =?utf-8?B?dmhjQ0IySnBRUUZmS3M2anYxbW9Jb2hsN3JwSlVkWEYyeUFVRjcvbk56K0RJ?= =?utf-8?B?dUx4Z21FcWYzYTNOS3F4QjVBVlFVekVOV1M3T25uZ0M3OWpreVh6YS9oTzdF?= =?utf-8?B?NzQ1aEdHSk5lSTF0Z3YzTmN1OWRieWJpZ0RwRkZ3RC94Qk5pVUNzYlVjZkNK?= =?utf-8?B?M0ltVkZ1bUpYbUJqQS9NQnhydHdTQjJka2RxMklvYUJyY0RKSVNNa1VKVUFV?= =?utf-8?B?b3lxc0lZWmo4dnNvMWtKZnBtb1BUZjAvUjhNdHhRS3Frc0ZzajVaYkV1Kzkw?= =?utf-8?B?L1J4NkhiTStqRzlvblYzMjg0dTc0NlcvdmZycTBrdGZGK0ZWcEJBRXNQdGpD?= =?utf-8?B?NGFrRGdieWNMYWFTRUd2SUVMU2dPM05QRWxwUU9IYnM5NllwampDeDV0L3E1?= =?utf-8?B?SUxCMklCenpZemVGcW50QnFyQ2ROdWRnWG95dnZnY3VlTWZ1K1ZwVVBYWVJZ?= =?utf-8?B?b2twcHcwTXhnMkpMMTlxTzIyNk5DYnp2NW5iNjlWcjRzaTBiQ0Vld041ckVR?= =?utf-8?B?cDR3UGVkSFZUZUUyN3RTWlhObzVJcTZOS05EMXJNa3RKVG13aDhJd2JkaStP?= =?utf-8?B?YkgxUE83MWJkbXVkSktEbWpnaUpoMzk1Sk1ucEduT1F6ZEZGRWFYMGNJQ1VU?= =?utf-8?B?Nk5MVWJ5Mkgyb2FTK0JacWNqWHJOT2o3dXNJd0hFcS91dElnVnB1dz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 589f8a78-73f9-49ba-20a5-08de5f3d2e8f X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2026 13:49:11.3118 (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: t3plFnqphfD57IcW1sefI8QuaquvhRuA6lGm+nwPkKNqGtEGYiIPOX7zc1HIimxhvnD6s1H2hiB2BYZylGxHqQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR03MB5916 On Thu, Jan 29, 2026 at 02:07:58PM +0100, Jan Beulich wrote: > Don't know how I managed to overlook the freeing side when adding the case > to alloc_pdev(). > > Fixes: cd2b9f0b1986 ("PCI: handle PCI->PCIe bridges as well in alloc_pdev()") > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 29 13:58:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 13:58:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216513.1526440 (Exim 4.92) (envelope-from ) id 1vlSXj-0004fE-0h; Thu, 29 Jan 2026 13:58:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216513.1526440; Thu, 29 Jan 2026 13:58:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlSXi-0004f7-UE; Thu, 29 Jan 2026 13:58:42 +0000 Received: by outflank-mailman (input) for mailman id 1216513; Thu, 29 Jan 2026 13:58:41 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlSXh-0004f1-Kx for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 13:58:41 +0000 Received: from mail134-16.atl141.mandrillapp.com (mail134-16.atl141.mandrillapp.com [198.2.134.16]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9c175314-fd1a-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 14:58:38 +0100 (CET) Received: from pmta10.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail134-16.atl141.mandrillapp.com (Mailchimp) with ESMTP id 4f212N6ZPbzB5pPZY for ; Thu, 29 Jan 2026 13:58:36 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 95a7ad1aa6614e6c9fd97afbcb7e6816; Thu, 29 Jan 2026 13:58: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: 9c175314-fd1a-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1769695116; x=1769965116; bh=nZZKxilMtRL3J+I70azAXAYJ51FgiO9wKoPvoCmQgzM=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=LfiUGTwAIHVsF8yxzGgPcU+x1lpqo6Mz0U0vnHc727Yy6qzd+iUJ+lMy0o08UQc0J TdcrxZjkgjSu3pXkiPzWP5EVnNZYdLqStZ9NpIUqJ2AbWcjEroVL6EyQz66da0oUZx 2m7kzgEQ+tjiwTp+CeRyKjuc5/3OPRNoKlFa67is29gZmEvsfJTcZPfUtxzMSrQCID 0OSKEzfMZ/yXQBCo8WRYtLZvDM50rzQgubl8S/siNGe4VRaW0KAwRY839NcdRJw9Pb bX7hljYiDYNWs6KEuQTjJQFrozh0IwteVvUBKJ1auAzOBev1t3YqQ3UxGpQtjpgv+B tpgeGf478bzhA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1769695116; x=1769955616; i=teddy.astie@vates.tech; bh=nZZKxilMtRL3J+I70azAXAYJ51FgiO9wKoPvoCmQgzM=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=J0YvPz2fJIW33V5eKM2AK/4b6ldJFPl+eDxk6tSF1w8ygaDZo48N1+I/etNNBIPjl bIWObLyDc6qZSu8cDC+/HaM8CD+ikMW08fnRluX3Smq5CncJYRuqUa+lbLt8AuiCoE spIr3vUXBgbytZEYvY5VGeF50d+fI5h2qWrnpJ+ldu/d7BNTgG2lx/W6bMNNWihaSj he0y37vEyCfeikWg11VnsAs1M758RgbM01DvBfKRMsFj0eWUf9P4zKcggmcByQsPmT 2TOOr+myjGXghBN+kSPwWOJzBQiZK6JAOaOI6ZXIVQFK0BGMYrnzNJgE2T4XEzz1mY JjeGmNirx8WXA== From: "Teddy Astie" Subject: =?utf-8?Q?[PATCH]=20x86:=20Always=20display=20CPU=20vendor=20string?= X-Mailer: git-send-email 2.52.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1769695115816 To: xen-devel@lists.xenproject.org Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" Message-Id: <8b50a689e549fd174d6c34dadc5df5c65711c615.1769694285.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.95a7ad1aa6614e6c9fd97afbcb7e6816?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260129:md Date: Thu, 29 Jan 2026 13:58:36 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit While we may not want all the other CPU informations. We likely want to keep the CPU string as it's more practical than trying to decode it from the family/model/stepping combination. Amends: 35d60c59af28 ("Increase default console ring allocation size and reduce default verbosity") Signed-off-by: Teddy Astie --- It would be preferable it such message could be written sooner, e.g right after the family/model/stepping one of early_cpu_init() instead of at the beginning of smp_prepare_cpus(). xen/arch/x86/cpu/common.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c index ebe2baf8b9..831da72cd8 100644 --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -819,9 +819,6 @@ void print_cpu_info(unsigned int cpu) const struct cpuinfo_x86 *c = cpu_data + cpu; const char *vendor = NULL; - if (!opt_cpu_info) - return; - printk("CPU%u: ", cpu); vendor = x86_cpuid_vendor_to_str(c->x86_vendor); -- 2.52.0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Thu Jan 29 14:04:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 14:04:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216526.1526450 (Exim 4.92) (envelope-from ) id 1vlSdJ-0006IB-J0; Thu, 29 Jan 2026 14:04:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216526.1526450; Thu, 29 Jan 2026 14:04: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 1vlSdJ-0006I4-GI; Thu, 29 Jan 2026 14:04:29 +0000 Received: by outflank-mailman (input) for mailman id 1216526; Thu, 29 Jan 2026 14:04: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 1vlSdI-0006Hy-Ha for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 14:04:28 +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 6ba8a590-fd1b-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 15:04:26 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-47d6a1f08bbso4768895e9.2 for ; Thu, 29 Jan 2026 06:04:26 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c37420sm213763255e9.9.2026.01.29.06.04.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 06:04:25 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6ba8a590-fd1b-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769695465; x=1770300265; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=B91HArv1IgJYvUyitHLIbVfLiiwcZ0lg3FwGqPuA+nE=; b=L9YDQJZRWog7hdriUEJdQ8kbPfhBwGRUpN3vyaO3phjGo16e6sgNdXNrLdaRMhFWdN xIArb+qfhOmVAXNiKEdmJJxo4azvkksbxCjLqAXN2BUruxAoaI1wA0VM4O3d/C8fX0d8 q3yE4sPqS/AoNecIOJrNryjINVngx500oZCnr0ZIx85BNJSNev8uI5Che1Gq1sofxjaV v4R30AO8eLYxr5OEe9IN/XflODNok0nRos9jktJ3cXWzgmj9RdOtu+Dl0/dZ3g0XsZfb 6sF51OGaJUnOTuMBntOQSw96lDf5QxcQfmWtMMPTC5ADbj7xy1LAlAH4qXtoJe6Q0L19 rmpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769695465; x=1770300265; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=B91HArv1IgJYvUyitHLIbVfLiiwcZ0lg3FwGqPuA+nE=; b=Fugw/9JDS3MD81sI+K1fbOzeM8VQIZaBIdXZ1LHiKL542bW/nO9a8SqE16qk+BkAOK phcoUAOY80RE3F72UTEOh+4BI61wsGS8WlR25Ovlto+GsYBJg46fXlZalBL2hZzZunCS ewLemYPFtFPIAgBVghSY8ORQtTUq9qJ8AXXZVwBfCJwwMIQ5xGqff26ntSJR27wi7swc HEfh0BKoZ+lq+AfBxSPBc+gqGPf1YA1FH8GRMJT0L2XbbR3UnmjQ91cgDyTqfJ1UH69O w3+Qc8EqF86txQWYc2HjdKHpco7Nh20GiuuzRI3Jdk2IzkDOaDAJwgWpI8LOXjF2CcZ8 kVEg== X-Forwarded-Encrypted: i=1; AJvYcCWofvKyMvgqRW6JGRpiGKEpIkCw20IFunE+NRlCLSqgtF8GhJApvr3RFBtMm8iqxSxgirE95bY+a/I=@lists.xenproject.org X-Gm-Message-State: AOJu0YxMVWImjQtyIt+drCCjNNye0ccLucCRENtYetlsi+4Sdfv+viRb hxMtWHFlutK0jNSZp3zhmg4GDtk7TNHezgzU//dLCglQu5cuRo5nm8DEDQmdmHB2Sg== X-Gm-Gg: AZuq6aIfXXsNpPI+4OjqE+2DpzvuA1L4o3KmOICpQckQwmSeD+ACkTzWJW1JVd7gH6E UC1XXBPmgqOgt3Yqqzr/XJG1XlIhlQMLm6Bbpk9rTHFuEUTi/2HxDas03VDrGO0z2Re9+ODm3Ek CCM9kedpBRRbr1zCCcKszoyO2EoNL63vMncrRryGtCFlmb3JSxocT7M/gESjcZ9+5b0C/lklpw/ 458MQ5BzhZTxb/p9+eRHXhYVha9odnlOoD8eST7BRbu6vpNzbeyZXGil93Dq2f1m837p4HiyItd VpVVUOCZgPWJ0CmWH+02SDfQe7byyU2FPIISMrJQz1G6NJzfiYM0v8JXlDwGrWLKmaI5/v0kk+x yH427XlPYFDZFVc8sk4j6Xb0Bwn30xRikSSiWOSyp2taqceTq/KC6lv95VTqHIaIt0Tu8JNDr8t yn1Os7Le82pUxg1X5wkgyjv52EaH2xcO6LCrkJWW7nIOYDzwMp6yxBAD0VNiEnbhaephpynoh9R vM= X-Received: by 2002:a05:600c:4e94:b0:480:4b5d:9ec with SMTP id 5b1f17b1804b1-48069cafa29mr122844385e9.33.1769695465600; Thu, 29 Jan 2026 06:04:25 -0800 (PST) Message-ID: <87181edd-fc9d-4221-827c-97abc7aaca65@suse.com> Date: Thu, 29 Jan 2026 15:04:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86: Always display CPU vendor string To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <8b50a689e549fd174d6c34dadc5df5c65711c615.1769694285.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: <8b50a689e549fd174d6c34dadc5df5c65711c615.1769694285.git.teddy.astie@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.01.2026 14:58, Teddy Astie wrote: > While we may not want all the other CPU informations. We likely > want to keep the CPU string as it's more practical than trying to > decode it from the family/model/stepping combination. Yet why would we want it logged several hundred times by default, on a big enough system? IOW ... > --- a/xen/arch/x86/cpu/common.c > +++ b/xen/arch/x86/cpu/common.c > @@ -819,9 +819,6 @@ void print_cpu_info(unsigned int cpu) > const struct cpuinfo_x86 *c = cpu_data + cpu; > const char *vendor = NULL; > > - if (!opt_cpu_info) > - return; ... this conditional doesn't want removing, but amending. E.g. if (!opt_cpu_info && system_state >= SYS_STATE_smp_boot) return; Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 29 14:09:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 14:09:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216534.1526461 (Exim 4.92) (envelope-from ) id 1vlShx-00070V-4P; Thu, 29 Jan 2026 14:09:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216534.1526461; Thu, 29 Jan 2026 14: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 1vlShx-00070O-0m; Thu, 29 Jan 2026 14:09:17 +0000 Received: by outflank-mailman (input) for mailman id 1216534; Thu, 29 Jan 2026 14:09:16 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlShw-00070I-7B for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 14:09:16 +0000 Received: from CH4PR04CU002.outbound.protection.outlook.com (mail-northcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c105::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 174e3bc6-fd1c-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 15:09:15 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DS4PR03MB8397.namprd03.prod.outlook.com (2603:10b6:8:328::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Thu, 29 Jan 2026 14:09:11 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.008; Thu, 29 Jan 2026 14: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: 174e3bc6-fd1c-11f0-b160-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=V5yI8+R0QkpGksdr10x6SYtT3s72vD2QbFFoJe4JuwgRo/09a7ImpAo530kBUvG9WlxyCPmf+xpQ/qbv4FkmBs70jOoufrEAxIkSAbk+1Ua4LbMC/FGhTLyu6g4sj+wVCmIoSCOljOPQ0wITQMnYKKQuk0oHKOwKAIldStf9ktNZG33YWkIozdl7bjjlHXPQ2rnXXKMBuqwbVwHtaRnFkgeAnyujcLhAwuNNAvnGvaHIZ26xZrFqvfqSFDhJwVFzVOQCzIxUuK9aA7MSfgQRrzyO5MPC5MLTJ82iPyR0IsMqP+ZPozwiaRVQZWn2AYUEtdc0Av7TdDrCVbkRLJ1Zqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OfVWljgzAYBjnRL93HAlyxWwSWTevIJlRtOtVLjUZXQ=; b=aDobC4pyRBHbJUEYtA0x4VWynZO1aUFvjLvX6Nhs7u4UpGagxXz5UVB7ge+n4+wJL3J40pQrI1EU4+81ZJy2zhxquZvnd2t9DW8UGHy5qytoVtrFD8GnY3euaurgUeO85KZCPLd7Z4QKcBe3hNoqdbk+AZgWPbsxoG6LWj2BY6lAMFRRycCDeSa5ogxiD07kMddELrqX/vfGyct+Jx8+a5HCD4Q3XFrAZfMwQQBqO5+kUnl8aOcfB0gMn4AlHBa86UH8E3jbx1xFlnRlMS8WCa/vKmCkxwBRu7d5vYNr0jx+8wdf6Ov0fe0C8dyYFV3vDasmbJZaWveptWi+kMC1vQ== 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=OfVWljgzAYBjnRL93HAlyxWwSWTevIJlRtOtVLjUZXQ=; b=Apk/HbGEIRYOz8w2q/alHiQzda+H1FQoMck7Il+ogQQ97+RfrSU3FpGZILlK481mLZaYTLo5Sl/EzszPGTaeI2y3C/R763yOrqQRtnCOQQzx2VluF5Tl0NWYgdBThKs+/VVYGWWdRiB2l3qkD2BZqblw7zIO1X3nbustTuqdHH4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 29 Jan 2026 15:09:08 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , Stewart Hildebrand Subject: Re: [PATCH v3 2/6] PCI: determine whether a device has extended config space Message-ID: References: <99d45a27-ce67-4f10-9883-dba96f055285@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <99d45a27-ce67-4f10-9883-dba96f055285@suse.com> X-ClientProxiedBy: MA3P292CA0072.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:49::17) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DS4PR03MB8397:EE_ X-MS-Office365-Filtering-Correlation-Id: 480ee646-11d8-46b7-4896-08de5f3ff9e5 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?ODhpUnpTZ2VtVnk5M3NqQlBHbDg2ZWlsalo5MEdNZlZqczViL1ZQbHphTGVS?= =?utf-8?B?c0w0OHlRN0VzOUcvQ3hIU0tIOGRLYjZXQjk1NCs0QlFBVkRHQkRialROZGFu?= =?utf-8?B?S05HOXZEbkNsblZUK2JNVC9RV1dTVjdwK0dtWXFVYUxUNU9CTnR6Z2R2OTRp?= =?utf-8?B?V05KV1FYQWdNa1JhSkcxeERxMW9lc296VVNVczN5d1FTM0ZsTFJ1WVcrRzNK?= =?utf-8?B?MUpQUXpVUFNhc0lzaU5kMUxwVXNnci9mbHJUU2VSL1NlNVloTDdRZ1Y0YVFn?= =?utf-8?B?QUhneGczTUZFeDZPVlFSL2dWVlZCazVyZFRnUHBiNFMzR01RbjdYUmFkRjBW?= =?utf-8?B?SXJtTlR5bHZYV0xnaDh4NnVIQVFSRzl2YjlDKzBYKzZvT2hIMllZalFsSXpD?= =?utf-8?B?eklyQklKK0FQRTd1eFJZYTlUeW84QStrZStmbVlaMDY3N2FvMjlHSUx1RU9k?= =?utf-8?B?TEFhWU5KdGJQb0F1UmtsK0JEdGRBaXRtY0plL09GVDV3dkp5UUVhTVRSVWtT?= =?utf-8?B?bnFmZWtCSWd0VHVFTTdKaWhGMWJOc2JRUkIvQncwcVVGdDQzcjVWVGRlUW52?= =?utf-8?B?N2podVd1RmRQRGcrUnZhVVc0bVk2cTk2azhDTTVlQzA3RVNVTFl2Z0YxbVZS?= =?utf-8?B?bjhJTEV6amlYL3B0TkRWMks5TkczRjFuaU0wdXB1dDZrZ1FINkd0NWFpK2Uy?= =?utf-8?B?YXJ4Unp1U0xaaVJXdmZVaEN6ZXZvSmt4bzRod0M3U0p4SXA5NFZjblUvL1hT?= =?utf-8?B?dXhWUHE2YSsrZUZuOS9PQ0pjemF3eVhqOHcvTk5UYWxieWExVG1KWVUrem1R?= =?utf-8?B?TElhWHdmZzVFUUlDbEhPdkN4eGRTSTdXWW4wdVlZNEswSUlqMmoxcy9oVitS?= =?utf-8?B?SC9qRmFNd2xQcWM1cXVwR3I1WldGQTc1Uk8yaGhvS2tEVlNGUTBBZUVXS082?= =?utf-8?B?ZHZhZ2syRGlPNkJTdkUrSmdLRTFvM3JuNmJjWTFzSktWd2tqQjJsRXhyVlI4?= =?utf-8?B?K253endGaFlZeHovM2g4U1pnb0g3emdhS2VDQjBMRklpVFkzOElMV25ZRkoz?= =?utf-8?B?MzJTdVVmcmVQR3JGN2xUQ0tmVEpGREhRcndlZWo3WDNwOExubThVYjIzMWlJ?= =?utf-8?B?LzVUSmxjeS9hU2xyMUJhRVpuQ1ZtTkF4OGtFQ2dOYVJNQmd6dm54QjJNM2NE?= =?utf-8?B?RzdXM1FjcTZxNERIZTNia09ZNDFDczVxblg1RTNiS3JjLytnakowTUxGei8x?= =?utf-8?B?WGZheXNRVWRvNkQvMS80aElPQ2dUWFdGaGw5SVExczNyaFpMc3FEN09QcU04?= =?utf-8?B?L0t6Rk1qNW5jVE42TTY5OWEyTzZjQ2RWcUhPWVF6RU9TUGdqNjdTRW1sVkE4?= =?utf-8?B?cjZSL2Z6OXBjSUVvZWlmN1JUd0dESUlPMHdoVEY1WUY3L1NvcmFBV29RQTk1?= =?utf-8?B?UVpqSDB2OWkwRUdObUZCcjJVbnkwQy8waFM4V29kSkVJaGd5Y2dzUnBqN1l4?= =?utf-8?B?R1N6bzlvZjlpVlFCTFhkZS9kRVJmRkR3OEwzbTh2RlFQVnlmMGlkVzhqbmRS?= =?utf-8?B?UVFjZDNENHl0QTIxVi9KOWpHTVlrMlZQSnVWYnczdHhJNURGd01ORHF4bklr?= =?utf-8?B?dHlIbVpSeDVBdFBzTHUrQTdPYko0ODNIVVBjRUU2TmsrSWZJaDdsN1VkYnQw?= =?utf-8?B?T2tJdCszd1k0TmRzeXFDb3pnZjYxTE95Wk1WeFd3bUtoajBDaG1jT08vY2w0?= =?utf-8?B?M1FBVHovVDFWbTRnVXU4U3FMWFNaM3UxMU82QkhMcno2YStlZmNEcUxkakVC?= =?utf-8?B?d05aMmdUZlI3V09wSWFzRHlDeldld21mWDk5eE9oak40QXN0VXNVNWpVbFI4?= =?utf-8?B?N2FjSGhlSTBPaGxPZnMwTnpoSUJ5R0hhRXlkblIxSGVCUHc2WklIWUNta0Vp?= =?utf-8?B?VDZyUVRUOTBlSnBWbkVUYWVuRjBsSDBydndJZVMvYzhDQ25jdGVYc0xYZG1E?= =?utf-8?B?dEFCRWk2RWdPSE9DZFFXNzdhM05Qby8zYmdJc0N0UFNoS014TTVZT2paMTRN?= =?utf-8?B?bTFrWE85d0tQMmJjVllqdTVMWjM5NDVPUDRqS2hBb0MyV2RQZGNSSHpjMllK?= =?utf-8?Q?jvMo=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RkUzaTV3bm5aRFV0SDM4VHZ5UDN0Q1dQSTNXbnpMLzlSMk1CMWNqblEvRS9m?= =?utf-8?B?dDQxb0M2ejRVSlh1RWtyK2dPamE3QlJWUnB1R1FzaWYyYm8xeEdBVGxkemlO?= =?utf-8?B?SW1yZHp6bXJRZGNNTHFvWWV1dW05OHpMd0QxbXNobW5HakR2SmNSbnYwcmxT?= =?utf-8?B?VXM4eDlJSkVTbEw2RjBvME5SaFlIUThaTGlWU1dqVWpib2xSOGVFOGZDd1lG?= =?utf-8?B?Wm16cHZaUHRUK1pLRVlvRTF3N0pMeDBjU3dVNkxhSHk4aUt0NHQyY0VSUzJr?= =?utf-8?B?YS9ZM1NhWUNHdno1U3htTC9pUDFvam5JNTl3Q1luT0s4SU1ocWhJMUJkd0RE?= =?utf-8?B?a1VyT1J0UXp0MmpEM3hkVmdWRVlpems2SHRvaHR5WG1nUEVJM1pVM3lxZUtX?= =?utf-8?B?VjE3SFAzaS9XN2xxTTVCYmtNaWh3UUFjejRjMlRWUkxncmFrdElZWndoWUxw?= =?utf-8?B?QkZ4WnJ5RGE0VTBJZHMwTFQ0T3IxR1p2VFVxNEFlWUxqWDFsQXdrZVplODRO?= =?utf-8?B?Zmh1QUFzbXlEMEtKZWlreEJJR1RKNy9PbFBJSVlrSlNkUzkxQk5HandhWm5v?= =?utf-8?B?QlFPUld4Rk5ML0k2L1craitZOVhrblRGOXp6Nk5SYkphRmZnME9sVy82T1Bz?= =?utf-8?B?VjJqalNaZ2RLYzdpQ05JYjFmcVdaUEZBczR3QWRPMUNLTkl0U1l6QkZmc2ZN?= =?utf-8?B?NXUyNjk0Y1NSM1hZd1NLUkU2WENmUFZML05tOXltYVJrM0ZpUDlzNjlacUk1?= =?utf-8?B?dzFGUk5hUmw4UUhiNy9KeUZINndTVEdoRzFsYXdCTXQvNldUOXYvQWFOUWJL?= =?utf-8?B?SW9YRmhib3RRbVh2Q0RFT1FYQzNVbXNFYmhNbU5MUTJXM0JiRDhFVzIzNTl3?= =?utf-8?B?ZFpVYVIwRTA2L1Vkd3BJUDhyRnRCeXNOOWlJMzdVcW9GUHdueVZHN05Wam1G?= =?utf-8?B?S0ZqTFVFQXF6ZTFBSmdsUzF4S1hHV3N0L0xtUEpHWE5scnlQY0F2L2E2MjZv?= =?utf-8?B?ZDVIMGJBYTE0cHpObXJEVGhmdWlGYkszckZEQVZzKzVDNUd6V0pSTGZ3eXl4?= =?utf-8?B?UGtVT1ArK3BHWThHUCs0WGI4S2YzUTZ0T0ZIbzRYaVJLTy9YbklGS1hVUVhF?= =?utf-8?B?N0pkN3hVdklpYjFmOGpLSFFLWWZTdnJnUnM2OGVWVVNNRXhYWUZFUWZoK2c2?= =?utf-8?B?d3hOMjRTYU9VUytmMEFDRUx0cUhJL29RU2FrNERqV2k2QXFXNE45Mk1mNW9L?= =?utf-8?B?dmdlUHFSK0NxeTNFR1kvdDIzU3dOWEdCN2FNTFUxVDZSQVJ6emhPMTFxQkxT?= =?utf-8?B?UzBmUXhha1JOOStoSTkvRFlWZkJqNE9iZllsQURGbjhIamFCdTNmLzNUZjc4?= =?utf-8?B?THBJMkIySHRpanE1ZllUZ1RqbjV0SHNEdjFyVTBNRE04dXFCa0M2SlZWTHlF?= =?utf-8?B?ZXAxRzZmby9HRDJkckU2Rk5OOFZuYys4b0o4U3dOVGs3ME52cXJxdGthSzND?= =?utf-8?B?eW11dXJrbU9TYXdDVk9aWVJoZVNTVnhsWWJ4UE8xdmM4OTNnKzZYQi9BRTJu?= =?utf-8?B?WXFvU1MwTThBNmtMNDdadHBoRFdtMk5xWVVScE96NnNYZGk2Z2syMXUrSGdW?= =?utf-8?B?NGJZMDMrUmxVOHNIRGh4b0hna2kvNGFJTVpwdnFqTHhaTkpVQnJQb2c3V3BJ?= =?utf-8?B?aUtsNDVSenF1MEZMK2ZlYm13eG05SktIbzVzQ0x3b1laSXJvRzJFNjlvTHQv?= =?utf-8?B?cWUzU0pINS9lZnkrVkdhM0lRUEFmOUtxc3dCN2N1dTU2YWhxU2lTbjMrNTcr?= =?utf-8?B?OGFjb2hjZCsrY3RoOFJZZVRNa29zVmdQWVV6cTlYWGo2amhzQlg0QnRGUEFL?= =?utf-8?B?Lzkza3ZseGV6S3V0MVVXN0NOeVkwNDRFUktlQWJCd3FhZlkvdTR3QUw1VXdF?= =?utf-8?B?b1VibHdhZkN4azErK1RscFZuNlZFeGZ5MnJKbjg2c1R1NzBXU0xrdFVCMUsw?= =?utf-8?B?N1lMQWs1UkpWc2llNG8xNFpLd3N4VTMxdXRUdER3azFRUjJ4NXJoYkRUTHZ5?= =?utf-8?B?dGhzOFozY3M4WG11d0tJUUcvRVlidUhXOER0SFNxOEIyZGhzSEZXcTJKeFBX?= =?utf-8?B?dEtmU2xWUm5wN1FxVStnME9nT1pkMWtpNmYzaUdIYXBsWkpzWUl3VTUzT2tS?= =?utf-8?B?emxRT3I2RkU1N1dWMEdCR1J0ZW1Dck9uVDF6YnA4WFZyN0JJUmw2eXZ3d0dl?= =?utf-8?B?VVA1Y0tScFVkTmgzcVdmenFRT2dENkl1a29aTmlZbzJHdnpiT2lHTVQzNFAv?= =?utf-8?B?N1I5VkpPemV4S2ZhaGRFVU9YYXRTNFVERGl0VjN4QmxCekhkMUdvZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 480ee646-11d8-46b7-4896-08de5f3ff9e5 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2026 14:09:11.5448 (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: wP/fPlE+DUONiwi+PgUPm2DyuUTnCZRqdiDUSFmF00v+OFMJpiFqH7eYn8Q3TiggBkfMInF/NWqEWKjP77I50w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR03MB8397 On Thu, Jan 29, 2026 at 02:08:27PM +0100, Jan Beulich wrote: > Legacy PCI devices don't have any extended config space. Reading any part > thereof may return all ones or other arbitrary data, e.g. in some cases > base config space contents repeatedly. > > Logic follows Linux 6.19-rc's pci_cfg_space_size(), albeit leveraging our > determination of device type; in particular some comments are taken > verbatim from there. Like with Linux'es CONFIG_PCI_QUIRKS, only the alias > detection logic is covered by the new "pci=no-quirks". The singular access > at PCI_CFG_SPACE_SIZE is left unconditional. > > Signed-off-by: Jan Beulich > Acked-by: Roger Pau Monné > --- > The warning near the bottom of pci_check_extcfg() may be issued multiple > times for a single device now. Should we try to avoid that? > > Note that no vPCI adjustments are done here, but they're going to be > needed: Whatever requires extended capabilities will need re- > evaluating / newly establishing / tearing down in case an invocation of > PHYSDEVOP_pci_mmcfg_reserved alters global state. > --- > v3: Add command line (sub-)option. > v2: Major re-work to also check upon PHYSDEVOP_pci_mmcfg_reserved > invocation. > > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -2009,12 +2009,21 @@ Only effective if CONFIG_PARTIAL_EMULATI > behavior.** > > ### pci > - = List of [ serr=, perr= ] > + = List of [ serr=, perr=, quirks= ] > + > +* `serr` and `perr` > > Default: Signaling left as set by firmware. > > -Override the firmware settings, and explicitly enable or disable the > -signalling of PCI System and Parity errors. > + Override the firmware settings, and explicitly enable or disable the > + signalling of PCI System and Parity errors. > + > +* `quirks` > + > + Default: `on` > + > + In its negative form, allows to suppress certain quirk workarounds, in case > + they cause issues. Not that I oppose to this, but I've assumed that you would introduce an option to fallback to the previous behavior where Xen would just assume extended space to be accessible. I'm fine with this, just assumed it would be a proper fallback to the previous behavior (which doesn't make much sense as it's partially bogus when used with vPCI). Regards, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 29 14:14:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 14:14:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216545.1526470 (Exim 4.92) (envelope-from ) id 1vlSma-0008Vv-L0; Thu, 29 Jan 2026 14:14:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216545.1526470; Thu, 29 Jan 2026 14:14:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlSma-0008Vo-Hw; Thu, 29 Jan 2026 14:14:04 +0000 Received: by outflank-mailman (input) for mailman id 1216545; Thu, 29 Jan 2026 14:14: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 1vlSmZ-0008Tl-Eo for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 14:14:03 +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 c05e0597-fd1c-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 15:13:58 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by PH0PR03MB6541.namprd03.prod.outlook.com (2603:10b6:510:ba::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.16; Thu, 29 Jan 2026 14:13:53 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.008; Thu, 29 Jan 2026 14:13: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: c05e0597-fd1c-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vlRTtnW9iEwlVtBe1+KLnnb1kK4fWOPM7kh+353MqROwGkASVnIw10a53y/gGyGQoODMh+FkjohgnKKfCkDac3zZHxBCdTlIkm3zxrzli+5n0NQxZ2bR+YpQa6xzfkukxD6gGbFoBwsN9PRr1Ppi3Lt+go7PRIXb00ug3P4ajkVtXZ5VQVjZaz2SdgQqcqknr/hATvRrbCUrrMWao8Qxmaz+oSP0NMzA4jEo/VK0tADJlbSpVcNog3TtsERzmSZVub57hJ0mAeaaMMzfuoSUVJjoMDnAozhqecw+boI0sYAAzERBtRhIVn0gjkcLxU6AQzPtXa9Roe4xGe16xbgCXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=y10wekK9zkyAtRMtkqQVbrQmf01sAz6zb5Z4qr9KuTk=; b=TQeVZgfJIqtZxg7attFV7/NC1mtXL/m4xWO4YnUrGnwve1Yz8FAMzOO+Puh1llZwM9aZ1xmMUTh1d8ONzJw2npdfxG7FxR2Z2bPB0zRu9nOg1Q4PTxJDFowcFEHEHOtuNtXk1d7+6UARyLIQSKjixzGnEkTENdLow+9+LSA4MtBXvnWbXXDinhY1UfPF+xn4tR8bTytZYU0qpzHFsrxHHKaCzzIzoZCVOZumfzmMSgivbXZatQ961ai41eN1IroU2t0zIIW/jeGlAL/0XrT/+l3/RDSShdiqnuyp3I7Mj2kxUzvL8Oj2RCMbJ4iA4VamsvrOBGDzeQ6LwVRstog9AA== 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=y10wekK9zkyAtRMtkqQVbrQmf01sAz6zb5Z4qr9KuTk=; b=HuaP7j0xROUebzLy+E/ZahccN2PfndM1bFMVJoCbdQMBzvMVFRUV5npOv3Uk/yqCrOlqGBvfSn2eS6OSOvg2RLy4n5B6xW1YXFj9Nj1M0qDO7qvq3rpArmDkSQqfXs7sS1Hkoaq4kqGy2KGkiwSHVgzUsrvzUYgVqbiSHp1IQRo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 29 Jan 2026 15:13:50 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand Subject: Re: [PATCH v3 4/6] vPCI: really no ext-caps without extended config space Message-ID: References: Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: MA3P292CA0019.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:47::9) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|PH0PR03MB6541:EE_ X-MS-Office365-Filtering-Correlation-Id: a2e2549d-fe8d-4aae-ac52-08de5f40a1cf 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?RkRVbVA0TVhlM0o4djQwRHlabkplUEpFcU9tN0ZiWWU3aDF2MDBaQWkyWHY1?= =?utf-8?B?alBXUFJwV1VvemdJMHBTT3JPdjZQeXFtcC9rMUM2d2x4MXVhSUhyYjFaWEVm?= =?utf-8?B?VXk2MXlGdHRSR0tzVWpuUkZVSVJVMG1iRFdkNXlFYzRqUnd3UUFwMUFIdVRL?= =?utf-8?B?TC8rU3QwSW81TTdDaS9KYmw5OGRiVmF0RzBBaWtXbDBwZ0gvMHJ3WlZ6Tmd3?= =?utf-8?B?RmIyaFZCWVZ5QUtmeXFXd3pQaHdIL2NZWVdsTXZPcEtSS2FHbHJ3UU00VnRY?= =?utf-8?B?cVN1K2NtbDI1YU9QNEQyVjRxSHNLQlUyMnNIbnJLVTF4NXVSYm9DQlhCdDVo?= =?utf-8?B?WmVpM2MvSE00dGRNZHhrQzAzZVRhaWxZak5YVUV6dnZoaTJRbGxCQ2FvcEdX?= =?utf-8?B?NC9Ec3VrMWt6U2tGZUlwc1hXc1RCbXZPVEs1WG1PSThMUWF0ODhtLzREOWho?= =?utf-8?B?QkdZeVFpYkh0ek9sNXcrNnEzSHNKRENCdko4RDkyYUJuK3hrWkN2NG42VWVM?= =?utf-8?B?S3JnbFZpODJaeithR3hSdDFRcUIxUlpmM0tDNjFqb1FoanMrN29UdEJ0aWJD?= =?utf-8?B?NVdXMkFzaFFYbzUyNDFiVzE5bkZjTG5hN2VqUzd4cHIzcEFGMVN6R1h6RUpv?= =?utf-8?B?ZFFmVTJ5cFdpbXRkdTlDOXJmdTc3V3pyazVPTkFhNXFQeks5ZmF5NEtkTXZG?= =?utf-8?B?V0V0dnkyNUF6dnVic2NhVitid0dFSU9zbzk5amcrZ05YaUhZREN3WDF0Yi85?= =?utf-8?B?OTFCTDZDNEJJS0JkNk02YlpheHFCUXRDbzJSVGkrSzVXdExUcWhjUTYrVzZD?= =?utf-8?B?b1NVNUZGTHcwcWw2UmZpcHBBVENLbzd5aDBGRGFUU3Y3VXZlOXc3anM2dXV3?= =?utf-8?B?SkVaSTFvR2hRMUJZSmdxdTRtclhZVGE2OXVVMm5ZRnIrM0ZiZTJDdFVmVmxh?= =?utf-8?B?NmJjMlJMdkViQzRNL0FWU1RxWmFKUDdYRXBBb1hnQks2cytIcUpqc1M2ZXBs?= =?utf-8?B?S0wrcTdnZG9RRjZ0aUdQTFROU29NakwwVWxuYlpxcGxiYVR2OENJQmZqRjF3?= =?utf-8?B?Rm5PMnVMbThZdUJTbTUxMFUrTkp3bEgvMFBrSUtvSEVOeTVrNUt6K1hQR3Nw?= =?utf-8?B?YmhnRTZucUp2Z25tU1VGSDNvTW9tU2VYS3ZveThGQllTUlpsYng2Qmx0S3hi?= =?utf-8?B?Tjc3aG1VbWNDL3E5KzlOVlNVMzl6dVdJZnIvSmxiRVVjQUpiY0Z2Q3JqVjFu?= =?utf-8?B?YnNXbU9odDRrZmN6c3BYWURnVG1DUXpVMzk1L0YyMGg0NGgyeWZDMkZZZTNS?= =?utf-8?B?SjdlaXM1SkVPc3ZUNnlpbUlRaXBVVVJSSytvRkVGWE9VQ2tEYW00OXgxODc4?= =?utf-8?B?Z3orb1NvRnprbHUvQkE2bU85YU5QcVJxUS9pNjdSdTI1ekVJUUlvcUlPNTFD?= =?utf-8?B?QXBWN3kreFZkUWRJb3NPOHgyYi9jN3hISzNPNTlyeVN5b0o1QnB1MHFmWTdQ?= =?utf-8?B?aDM4MmE1dWtOWk1sNXFPS2hLMXdkNGhuaXhkdHd3bUIzSnJaWFo3cThQb2o1?= =?utf-8?B?MGF5R2JtUmJSUFhMcVpkM1NSZ1R6KzcwQkcwT21BTFBaZWNxenBUN2JtYmI0?= =?utf-8?B?Mk80dG9UWlNPRmVMekRHeXdQQTRYNTV6YndFajhDTGZmS1dmNVFNbTk2WjJC?= =?utf-8?B?a1A4Y1FmWE5nQXhPRWVhUWd5TWZ1N1Q3SmNBK0w2UkxESlVFUG9Lc01hSUhH?= =?utf-8?B?eVlMeFhWb0Mvc09QMHFJVWFkUGxZTWE4b2hyNWxxMm4xVUR2ZzZmKzJaL2s5?= =?utf-8?B?LzQvTGFSajQ4TmpHdGl6cm5uUy9LQ2xpTWlzY3NER0p6bUt4cnpHUkJzcVlM?= =?utf-8?B?ZmQwUFQwQ3Z3SXdIOXR5WTVTTG45UGgreGVEdGhyUkdDL1R6NkFOQXVWdGFw?= =?utf-8?B?OHlXLzkrMmxGSDJuVHNVREV0bVRLYlkwakUzY0JNMmdJdDZjTXMrQzNuTlRv?= =?utf-8?B?a2FacXdtR3o4UzdRMFRXa1VEVjl2WTVTVlNTcWV1RmluSklIRUtic3NoMG1W?= =?utf-8?B?dmxwVWxyaHRwMm1EZlljcjFiZXZONm16V1B0emtNeGFrQVlTMWdZM0YwaXJW?= =?utf-8?Q?vcQ0=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dmVnN09lLzRPSkI2UHNzN2FWL3l2ZCtzc2w0dTZHNk51RzUyK3ZhVU9vQWVS?= =?utf-8?B?cDh6VnJqeHlnTGE3V2U2TlNKNWxNcEdhc2duSDlGejIzSE5UTHNrUUYzSjJu?= =?utf-8?B?anRiT2RDeE5jVnBaRndGRUJVbzJNMUp6c2NsUDczTWI0MEpYa0FQRUtKWXlZ?= =?utf-8?B?bEQ5d2FUUEtzNlNtTUEvT1B0SGtZaEtLemk2YXFGRkRsMmZSWE9VazZ4QXlx?= =?utf-8?B?dkg2TlVndHYvVk04U0dRMWN6M0U4dW95bEJwankzbUgxcTUxVTR6eGFqYjFD?= =?utf-8?B?cElOWTVDc2x4QTBWNFJVbjl3cTdVWmdnNnlVYVp1MWswOFB3TlNId0w4TzBy?= =?utf-8?B?TnlOc0d3dS9pL0hqd3VSRzF5eW0rdjF1dEdGZUZrZ0QxM1A3U2toVGdaZkxE?= =?utf-8?B?YXNxVWJ4TkUyUVFjY241aE92WHM0cjkydDBzQ05DQ3doVUY0Q09ldE9vbHVl?= =?utf-8?B?a0xMTjczUWt2NU96amt6RXFuSUE5TjZmVXM1Y0dKSEdNbGZBZU5HS0dUdlZK?= =?utf-8?B?bE9obUIxd21TNVM4QmFPSlBBVXVESFRNY2xqRjA2NEhocXdNY3ROV3hnZnFF?= =?utf-8?B?WmN2RWtCU1orYXVBNFMzN2JkTXFJSEEzRWZNdXAvYUl4a0pNdThBV0J1RjV6?= =?utf-8?B?Wmtoait2Z3FzVzJaYkdOcUhaTjJyQ0FvWFhPR1dXUHd6T0dwQnN0b1RxaGRB?= =?utf-8?B?VGk1OU1lVDVVakE5VHhXL0k3OHVZMTRFTWFyYnlnU2N0Qlg0N2l1dXJUbG5W?= =?utf-8?B?d1k1YVg1aXNub1lERnNNZmpqenhkM2RzUW5EeTdEcUxBcnZDQ0Y0ZlRIVWtO?= =?utf-8?B?czBPck1lZVFUTmNBbFAzWDVNTzEyL3hNdXh5RFlpZmZkOGxCS1crdXdVZzV6?= =?utf-8?B?Ui9ycWhkRVJ5Q1pJcTRWRW5sZ0U4R0lOcEQ1QWI1bWdSVE1rYzVveC9oalk0?= =?utf-8?B?L0IvdWhrZ0xGVENmVW9oMDFaVzY4eGVNeDI4bDFWeGxVQ0JIbVIwUUFxdEJp?= =?utf-8?B?RVcveGFQZmNxNFlNZUdwUnF5MVhNNjUyUUsxcHJMbVA5ZU5iN0lHbyt3eTZO?= =?utf-8?B?ZmJJeHNTU3BiOTFlMDNmL002Sk1wcG9PSlF3azR3MG5iRjlzOFY4QlFiZWZE?= =?utf-8?B?b1o2UXRDQWd2bDh1UG1sd0pjZnNOYSsyWWFzSmlONjRDMlNMRVBXYUtJbnE0?= =?utf-8?B?UlhuaDQxWWxxZTBOQ28ySzRNK0dkbDQ3V3dIZnhhSDBqV200ZGw5OEFvU1JM?= =?utf-8?B?a21vS3o3T2h5QktRK3ZpcmRxaUJHcUlOTnpHaDl1QUIwRi9mM1RlVDZvUVRr?= =?utf-8?B?S2NrazUzU3pySTY2cTlzc2RrK3dHUk9Tck1MTjFpSWhQaXVuZWhZempQZGpC?= =?utf-8?B?b21sUWxJQjRWUkx0WlpGRUdBM0l5Y0QyZ1AyNk5mL0RWdytmMjArdUZRZG5i?= =?utf-8?B?SXA2MzJCZnNrU3BhbzREOTN2OWhrd3FYNzQrc21abmpJZHY1STNLdlBnVlo1?= =?utf-8?B?S2NRMXRJZm0xaWlFUlp6SlBqU0VNQ1dEM0N5ZFRYbEh3cXVCdzFpdXExZUw2?= =?utf-8?B?UnBhU2tTLzVJYTJ2eE9JMVpSUHpIaFJMbmkrcWprQ0duS2ltcFQrY2NFYThs?= =?utf-8?B?bWVCaUZCWUpRc09obDd0Y2F4RjBOeVQ1UFl2eFlZUXcvMFV6ZWNkQUJTLzNG?= =?utf-8?B?UHpaK0dmOXR0VUlxRU9tM1NGK2Fnd2NmYlRndlVTYzg3QkQ4WkpIMEZoWENS?= =?utf-8?B?UTZJVlZqVlZyRWh5WmVZMmIwNlpaSlM2RGFYZ2FhOUZQYU9KeFpJc1BqSDFl?= =?utf-8?B?VVJkVXlSOUZOSjFHV2hGeDBZLzNTdjFNS0YwNWhIcEo1YWQ4SFVLTy9ldUlI?= =?utf-8?B?R3A2ZXZvclQveTdzN0FaMmwrelBuU2tIVXZtbmN6d3ZQTmlGRFo1Z1RLMy9G?= =?utf-8?B?V2oxZW16K2lVS3RNRkVzZ3RRYzhtVDRsdU9sTXR6aVFFeTFLV2g2aEdxUEtO?= =?utf-8?B?YU9zaFYzRkN4OE82RnlCQjBRRWdyczZnVTNMbytMbVQ5ZjdjMitEUy9idDdK?= =?utf-8?B?dG1kNmVXLzRnVGtjMHlVNlhuUGhpbEIwMHduQTl0Z0p0Uk5jd1o3d3hoWEdl?= =?utf-8?B?UjlGV3F0bHdHWnFzUzVXN3IzUEpzaWZlc0dZd1RqZDZDMEVNcXVwOFZrVHBh?= =?utf-8?B?TW54VzEyTGlLNWFmV3hLQTBUV0c0SHU2dkNTNnZ0QXM4QnIyVWJKZkVqcnB6?= =?utf-8?B?VUJIdUVsYUhrRTc3N05zOFVVdmVBL3lReDM2Z2FSRmg1N3BRbjMvS0txN2t1?= =?utf-8?B?ckZOUHpNbmVleU0vS1ZmeXZMSm9na29jdGNXTVZ1M0YvQUxGaVVyUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a2e2549d-fe8d-4aae-ac52-08de5f40a1cf X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2026 14:13:53.1439 (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: 7iYrr35wwzb9LWSaqA1PhlqDDkTW8vdWAVC2w6vZisGQXV9oBe0FnN9iAhh+hc8DQVL3j+1XaPD5/gEmucZ64g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB6541 On Thu, Jan 29, 2026 at 02:09:27PM +0100, Jan Beulich wrote: > For DomU-s, whether to emulate accesses to the first 32 bits of extended > config space as read-as-zero or read-as-all-ones depends on whether a > device actually has extended config space. If it doesn't, read-as-zero > isn't correct; not getting this right may confuse functions like Linux > 6.19-rc's pci_ext_cfg_is_aliased(). > > For Dom0 this then simply allows dropping a later conditional. > > Fixes: a845b50c12f3 ("vpci/header: Emulate extended capability list for dom0") > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 29 14:17:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 14:17:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216559.1526481 (Exim 4.92) (envelope-from ) id 1vlSpY-0000fK-4v; Thu, 29 Jan 2026 14:17:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216559.1526481; Thu, 29 Jan 2026 14: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 1vlSpY-0000fD-1Y; Thu, 29 Jan 2026 14:17:08 +0000 Received: by outflank-mailman (input) for mailman id 1216559; Thu, 29 Jan 2026 14:17:06 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlSpV-0000f7-SD for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 14:17: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 2f16c8c6-fd1d-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 15:17:03 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by VI1PR03MB10078.eurprd03.prod.outlook.com (2603:10a6:800:1ca::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Thu, 29 Jan 2026 14:16:55 +0000 Received: from PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.9564.008; Thu, 29 Jan 2026 14:16:55 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2f16c8c6-fd1d-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=BQeIYo0HpcmXtgYzVD0dXlLQRYA5imUdsEfAGQCiquiKoYVssJ1EJx+fiZObzmd9vSEJy6Q++ZO+Pg/1ZBSKl+tsukH6bBqF+EMnFMmTw1yb0ogzeTPX1iWilDSA27NKmT0g+EP3Ql92M3j1qRHg0p9nP57GfaFJ7ee6He2mg3kxaxFFdVOk4FoUL808cQRokjwoHdEK9Pxom83nbRJcQKmCgVDSL+dQysxIh+cQPKRcyqDH6+UAxvFwOF46vBhi+pMIktKP0pkgUOz3mfHqLh2K60fGbyKAR5jtVHT7rCsqTw/ErPAko4nX0r5iP6YNIDxAPxmMlPRYdgtWh+288g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ibKaJmnmVsKkCLLiwRUvv6w33HYLnTMURDRsiOZQ5ic=; b=ZyU9AthvX59qCeDD8OUrSCFk9+P4v/ZqrLOm5TPGtJfTXM13NxjPXjXq4PXeYrlNsHWZiD4Zi2+cZro4pA9VUS71CXMuut/p2XVMKmib9/xVnwLYt4TvSOwr+1wQ9UftosLovyYK1tTroLd4noXrn4N/mr43YYl1W/+STUn4dHR5zl/2gsEwUV5iLmIlJ/OFE78d83jIczY9Lls8E9FQwVKlg4w7b2t+XSqazLee+VttjLNk2JOp4RrV3YrEKqlp63XjXs1/EUA1RHaOAejYkufkKmnH4Ez4RHerkO8ySlDG48CQjt1OPdm5+5izNfrSDS/IouPOKlx3C92y28gqnQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ibKaJmnmVsKkCLLiwRUvv6w33HYLnTMURDRsiOZQ5ic=; b=Qa3SWFKfKoWKS2PzD9HUwkHqFtiIuQ8Y3nDYcrZGRh5HfmrRf/+GA7nAuTxdQafPi4LajVD+7RlIwNky1d+yUq8ThkrIvh1VSMMEENLflO1MMGmPSViQGNSI6Z0Wqv6AWi5gilGdhbfNNDxZncjfWHqM5Ij4Vv70ZquEy0gOf7RRuf13nbSO5jQYr39CGGvS3rzrR6CE0/o3hpHZSbN+ZJvuvEUEpjW/JBc1LNo+OgKE/UO4Oijk4OEHHh++7dWa4JERqcnW4iboaAwPbYJipN6tXoTd4n8kgZeWh5a/po5EcgAhv2/jfJHUxkd8QTJNJSP+57Yt/6WMiFzxJWFZhA== 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/5] lib/arm: Add I/O memory copy helpers Thread-Topic: [PATCH v9 3/5] lib/arm: Add I/O memory copy helpers Thread-Index: AQHckSnrjR8vkz+RAkaYhf4MP0G0mA== Date: Thu, 29 Jan 2026 14:16: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_|VI1PR03MB10078:EE_ x-ms-office365-filtering-correlation-id: 9886b90f-f9a8-423b-a641-08de5f410e68 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?bZsip0kioMtZoAqzNqHfKxUTF8VIv042ENscfHpfi1U7jSFomrS1ISwLd3?= =?iso-8859-1?Q?MXML5AbHhYaxSu9jt7XKxxwpdcsiEeQSmCqj8NRxZQ4BWz/i95VRGZY712?= =?iso-8859-1?Q?4ZBO6k1Xb2vYD/dnOViQSo1pDX2vTCHDaJ7+KoeWmxHCW+AMLbc5zeKNBM?= =?iso-8859-1?Q?vPPqaZ6nY+vwlYUU4IOklqrZMdFf/jfveDTbbcjsJl6X++j/buuwdWvfQI?= =?iso-8859-1?Q?UxSpOpHrOF9Y6/HB7q5Z6sJykG2Fs++u8aiG6PjWC+lXkXt9zTCbGlt8fX?= =?iso-8859-1?Q?AqBhXDBLdPP3+JwzGZFrPn6EX4slkEfCY7ctirm6V9O+OlcA5SDVCZW45n?= =?iso-8859-1?Q?bqNlguO46HeEoITRpi1KikN7PCItwRSk4dbmUcSwJZr5OQ+9AX4jLPeIhE?= =?iso-8859-1?Q?rHyaaRCHg/en6aByRwzEJd3Q7Ujs3zbReO+NtKnlH9cNkOOXTgjS5wNWij?= =?iso-8859-1?Q?YEaOU/Slh6kZDWNDrNZ7lhC58ULt5L1exwEiA9fnagLLuhKaqb7ddRwtmx?= =?iso-8859-1?Q?rex92hl01MQmFPZHVYpTCUVQarAicr43Ysfxrf1p05SjBPEiLduS7y32ig?= =?iso-8859-1?Q?ji1rFO6CdtIuicumqXi7FXPxFeIpx6POR6Y1cjtQk34l2sQItBClZgmDO9?= =?iso-8859-1?Q?oCklKwKNONCR5MwQxFv64spz3VJEpXBA3DQXJw/tNPIfHW6al2uNmIUDP+?= =?iso-8859-1?Q?OVUTLafZWZZ7SgoS1XseswHdav1ZLxXL+cMDSSoe1tBYu7oaYwVu6kz/re?= =?iso-8859-1?Q?nMukYQEy1IItp8DoLmoMLZ+mpImVzohn27oBw20/WklOk2WhYKD85anP7f?= =?iso-8859-1?Q?p4ij0Byrw9L1eHk2Va/HX+4QahPxN3CHT38qEKCYovcyDGA/rH+d/q7t+M?= =?iso-8859-1?Q?aJG5DrRucIcQiJtbQrZf3braRuSIEouS2oG3dp9Nx9nb34LbxrPAT4xwS9?= =?iso-8859-1?Q?o0TGwn33oNUENtuXGxWHCFsWnHSNmmYFVegZObTty4r/OeuLThMrsFT2Wg?= =?iso-8859-1?Q?vTOfsA+1onu7WImHkPsnsXmYQsGL2AWokq75X6U6MQxfhojkN+URZ6GpEm?= =?iso-8859-1?Q?KAEfOHWOpusfTqalp4f8JTVOE/5qxr0MdUhm3g5AqOTyBep61RqE7KIBBI?= =?iso-8859-1?Q?w6jn1TmzOHTvqDUNV5xwrTgS1bGGL92IPi+79JFsAfncqyrXLpB8pEExvl?= =?iso-8859-1?Q?Xl9AtZfNwAwRQskL6DUDY3IClsjbpLa/1iEr4pVZSThpaT+Tpk6J4UuJvV?= =?iso-8859-1?Q?mhzWkuVSkN7hezb6p92TQBPXLoHDPxAzvfijWUhl5a9NI7rLOpCpBsF4hG?= =?iso-8859-1?Q?vQhyOpSFNDSQ/pLnB7v7W6u8l0oJix9X0xvuUYM9WTTz7tbYbB9xu2RVp0?= =?iso-8859-1?Q?dtVpGL5gvKmXSHen5Sol7kXPa4WUWgbY1eyStc6o8/kKYmlrdinOeHS+69?= =?iso-8859-1?Q?riqC9Kexs68YqXneUJIjh0V0hjioRurI+YbTwI+UP2tkZRLlwb4ljEFWd/?= =?iso-8859-1?Q?pbJ4HsINzrUYOBwscRXxQHL9kZrUCYxcFgf50KyyjR6cYetojL+wDov96Y?= =?iso-8859-1?Q?giPNkrXrd1UCCP85a2fI0k2GjdHQwE2SDhp9b76cjE4JLawrGDMF2HhsSc?= =?iso-8859-1?Q?1irm/M7hAv/Dt538Sj7R73HijOc7mbKu2FZcAxVM6t9qJ5O7U5irDZo2cw?= =?iso-8859-1?Q?rKpc4giIzooWBlVOTgY=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)(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?zxb6TRv95WUUJCJquFhSJHEzn4MRvnndBWcGPn2SU3TqDp3yxc1pt1hpKB?= =?iso-8859-1?Q?BahcX07j5x18NUdEH5e/koR3Na60VuN4eIEUXJ55QK2yuaphBuHfjS3shz?= =?iso-8859-1?Q?xR2a4gXOMI4E6LynFGDXvGJJY+0XLdhHMz9YUlX/Iis8tXKBdGcksCHKbU?= =?iso-8859-1?Q?H9M5sjZYU5phQwqfzouv5ItxUIVZq4zD6VBGfdfSbBsMxvTtxk/4ubjXRB?= =?iso-8859-1?Q?6eTqe84cJGw0EXvYYWeOqU/KtnfYye8H7d2FDG4z5G3w8RnqaZ5LqlLo4t?= =?iso-8859-1?Q?fT/J6XJBjrMAfLtHoMkNcNxWf7s6EiH2IyDbd+9sqT1SHI6W1bjmVdhycd?= =?iso-8859-1?Q?KbblFHUenkRnWMdLoW+1IrMSER8QjOQE6k1Ppa7IXv+tn6isxNkSJGeZtB?= =?iso-8859-1?Q?TMExO0kVAsaHzHxtU6D8bfreW3XyBDs6pqa7OiKZ9PYh4hoa+IsLsaEenf?= =?iso-8859-1?Q?Cvpo1Xe7kugoy7US9p8iK6TfUn1m27nvXn/9k/12J35m7kADEx5W06pfUi?= =?iso-8859-1?Q?WQ4JI4ALbMxEOKJoqRGYiXJMoeX06RPzx3GS3jB0lJEo9rYHpgwLxk9huS?= =?iso-8859-1?Q?KIkP+8p21PYNMmOUb16b7Gu0mIF1tf90Z43jPQsYPOf5N+KHw67MPvtT8i?= =?iso-8859-1?Q?KE2Q9uqThHFO/7Aw3jq9cii52Q8Qt1yZV9uQOXPpPE8eLPosnP4rMrBvL9?= =?iso-8859-1?Q?P860HyXVsg/4t1o+d1rK3TFUoFjS6v2X3vslAmc9y6sYr1bg/KFY8D2oYd?= =?iso-8859-1?Q?fxqYA/z3FsyWHRVNhHjT11FoPFqDlX5mofyYElc1j5j4LQhdEMA+GxsYma?= =?iso-8859-1?Q?gZznuXjH/bzseK+GcUD+iOpmc0TiBopnV5aMb/myruvL+N099GWzxddsUy?= =?iso-8859-1?Q?58tDeoHjk3AZl/87ke6flyui+PQaGTxDvTYUFq3bi7dMRb5wKOLqJWzA3/?= =?iso-8859-1?Q?4Qp4I1J20ftXP+78wIxwqE9KqmpSe0iTfR6H2L0+1sDe/aVkm9pJqLarUN?= =?iso-8859-1?Q?p7owHPsb+SOMw479B/drlT0F4DMOlhsKy/TB+/PoqJdUPecYYtmkln83jN?= =?iso-8859-1?Q?t93fBJI2x1QOHao7eypmFHQk9czhKcfCxpr14wvjyTmrI276jwZhU/qTm+?= =?iso-8859-1?Q?AqEJ5n8Tf5TJHgAm5BOuyP2RTOxQfCf4QDHTMGbXEZQaqWiRljmsAPqCXX?= =?iso-8859-1?Q?Ezoc1d2Cf4cTs6m/5sGOM3n/txVMqMeQWLEgt2oO4LSrx5M55aJ72g26OV?= =?iso-8859-1?Q?EaXsB7obS1+DkcznlDv8UfNVg351rOHlGWPvdJhLDQaesfRBaki5Ue+Xiq?= =?iso-8859-1?Q?iwE800CIYjVaG+UYEHpeN8gG6NGVn5vxGoo5zjN9nugal/nQaz4OyoTatA?= =?iso-8859-1?Q?EGciozw0+PLYufX/qceACLR4XuLZa+kglV8dH/4WlBq2NL+Z8pXaCSyviY?= =?iso-8859-1?Q?VYZk4u+Ps6bhQ1+BNbPnTGtzreQsEiQB+GhYFBn8x8OqmALtx6RGsSO9uw?= =?iso-8859-1?Q?uBcPVNuqFJuQwjQ+sppR1i56Y32A5eI/C+GfMYjSj3zPHEaaZqd1NLHIXd?= =?iso-8859-1?Q?zTpVV9pK6bS9EgWuoqf3uWXdSsS6ym0qP8A+ab2xAXTJKSbks41Xup7S4y?= =?iso-8859-1?Q?inET58jWEBUvbHD1mPFM9pgbPxbD1IlX9qBzpgGPKUMf/2nk+0RkNRPUhG?= =?iso-8859-1?Q?RTXNzeG7vzayvb6P4x8IhWBV0zBbyEhxo7oHzvj9IwZW4g7El8ZAacX9FI?= =?iso-8859-1?Q?/ZRHgc+XKwSpNNQ9LfQHSdETj4M7oXZ0csblPeKCSvGRXzPRQzxqiZZH4+?= =?iso-8859-1?Q?W5cUWcblxbU50OADGiuqEUghWm+/Kgw=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: 9886b90f-f9a8-423b-a641-08de5f410e68 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2026 14:16:55.1260 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DaEC6+0FsO3E7IJYQrYriTeAVJSeXBAYGDYZrQA2X2dWBa21cR6ulLdyrDSGNA7jzz35keNCrGOeqeEH+MP+6carC/MRlrCrx+PLor/28EE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB10078 Introduce memcpy_fromio() and memcpy_toio() helpers to copy between regular memory and MMIO space on Arm. The generic prototypes live in io.h so other architectures can provide their own implementations. These helpers handle alignment safely by using ordered byte accesses for any leading/trailing unaligned bytes and ordered 32-bit accesses for the aligned bulk transfer. Using the ordered `readb/readl` and `writeb/writel` accessors avoids unintended endianness conversion while respecting device ordering requirements on ARM32/ARM64 hardware that may not support 64-bit MMIO atomically. The interface lives in the generic header so other architectures can provide their own implementations (as macros or functions). The ARM implementation is placed under `arch/arm/lib/` (mirroring the x86 reference layout) and is split into separate compilation units added via the architecture-specific lib Makefile. Signed-off-by: Oleksii Moisieiev --- Changes in v9: - reword commit description to refer to memcpy_fromio and memcpy_toio - ordering obj-y in Makefile - rename ALL_LIBS to ARCH_LIBS - drop io.h and move definitions to the common header, fix comments to be arch neutral - update comments for memcpy_{from/to}io implementation Changes in v8: - switched to ordered accessors to address the ordering and barrier concerns. - updated the documentation to match the implementation and explicitly state the supported access sizes and granularity. - rename memcpy_* implementation files to memcpu-* to follow naming convension - fix indentation to match Xen style - fix intendation to match Xen style - move memcpy-{from/to}io to more convenient library place Changes in v7: - x86 guidance: removed the speculative note; header now just says each arch supplies its own implementation or macro. - name spacing: dropped the double-underscore; the helpers are now memcpy_fromio / memcpy_toio. The header also explicitly allows an arch to define these as macros before including it. - updated io.c to keep 32-bit transfers safe on arm32 - moved to __raw_read*/__raw_write* accessors to avoid endianness conversio= n. - split the helpers into separate compilation units Changes in v6: - sorted objs in Makefile alhabetically - added newline at the end of Makefile - used uint{N}_t intead of u{N} - add comment about why 32 bit IO operations were used - updated cast opertaions to avoid dropping constness which is wrong - move function definitions to generic place so the could be reused by other arch - add SPDX tag to io.c Changes in v5: - move memcpy_toio/fromio to the generic place xen/arch/arm/Makefile | 1 + xen/arch/arm/arch.mk | 1 + xen/arch/arm/lib/Makefile | 2 ++ xen/arch/arm/lib/memcpy-fromio.c | 56 ++++++++++++++++++++++++++++++++ xen/arch/arm/lib/memcpy-toio.c | 56 ++++++++++++++++++++++++++++++++ xen/include/xen/io.h | 10 ++++++ 6 files changed, 126 insertions(+) create mode 100644 xen/arch/arm/lib/Makefile create mode 100644 xen/arch/arm/lib/memcpy-fromio.c create mode 100644 xen/arch/arm/lib/memcpy-toio.c diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile index 7494a0f926..5b8e170e01 100644 --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -8,6 +8,7 @@ ifneq ($(CONFIG_NO_PLAT),y) obj-y +=3D platforms/ endif obj-y +=3D firmware/ +obj-y +=3D lib/ obj-$(CONFIG_TEE) +=3D tee/ obj-$(CONFIG_HAS_VPCI) +=3D vpci.o =20 diff --git a/xen/arch/arm/arch.mk b/xen/arch/arm/arch.mk index dea8dbd18a..009bb22c45 100644 --- a/xen/arch/arm/arch.mk +++ b/xen/arch/arm/arch.mk @@ -2,6 +2,7 @@ # arm-specific definitions =20 ARCH_LIBS-y +=3D arch/arm/$(ARCH)/lib/lib.a +ARCH_LIBS-y +=3D arch/arm/lib/lib.a =20 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS)) $(call cc-option-add,CFLAGS,CC,-Wnested-externs) diff --git a/xen/arch/arm/lib/Makefile b/xen/arch/arm/lib/Makefile new file mode 100644 index 0000000000..07a0d9186c --- /dev/null +++ b/xen/arch/arm/lib/Makefile @@ -0,0 +1,2 @@ +lib-y +=3D memcpy-fromio.o +lib-y +=3D memcpy-toio.o diff --git a/xen/arch/arm/lib/memcpy-fromio.c b/xen/arch/arm/lib/memcpy-fro= mio.c new file mode 100644 index 0000000000..1b13cf5ff8 --- /dev/null +++ b/xen/arch/arm/lib/memcpy-fromio.c @@ -0,0 +1,56 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#include + +#include + +/* + * Arm implementation notes / limitations: + * - Uses ordered 8-bit for leading/trailing unaligned bytes and ordered + * 32-bit accesses for the aligned bulk; no wider accesses are issued. + * - Only suitable for devices that tolerate 8-bit and 32-bit accesses; + * do not use with devices requiring strictly 16-bit or 64-bit accesses. + * - MMIO must be mapped with appropriate device attributes to preserve + * ordering; no extra barriers beyond the ordered accessors are added. + * - If source or destination is misaligned, leading bytes are copied + * byte-by-byte until both sides are 32-bit aligned, then bulk copy uses + * 32-bit accesses. + */ + +void memcpy_fromio(void *to, const volatile void __iomem *from, + size_t count) +{ + while ( count && (!IS_ALIGNED((unsigned long)from, 4) || + !IS_ALIGNED((unsigned long)to, 4)) ) + { + *(uint8_t *)to =3D readb(from); + from++; + to++; + count--; + } + + while ( count >=3D 4 ) + { + *(uint32_t *)to =3D readl(from); + from +=3D 4; + to +=3D 4; + count -=3D 4; + } + + while ( count ) + { + *(uint8_t *)to =3D readb(from); + from++; + to++; + count--; + } +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 8 + * tab-width: 8 + * indent-tabs-mode: t + * End: + */ diff --git a/xen/arch/arm/lib/memcpy-toio.c b/xen/arch/arm/lib/memcpy-toio.= c new file mode 100644 index 0000000000..2554ac3efc --- /dev/null +++ b/xen/arch/arm/lib/memcpy-toio.c @@ -0,0 +1,56 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#include + +#include + +/* + * Arm implementation notes / limitations: + * - Uses ordered 8-bit for leading/trailing unaligned bytes and ordered + * 32-bit accesses for the aligned bulk; no wider accesses are issued. + * - Only suitable for devices that tolerate 8-bit and 32-bit accesses; + * do not use with devices requiring strictly 16-bit or 64-bit accesses. + * - MMIO must be mapped with appropriate device attributes to preserve + * ordering; no extra barriers beyond the ordered accessors are added. + * - If source or destination is misaligned, leading bytes are copied + * byte-by-byte until both sides are 32-bit aligned, then bulk copy uses + * 32-bit accesses. + */ + +void memcpy_toio(volatile void __iomem *to, const void *from, + size_t count) +{ + while ( count && (!IS_ALIGNED((unsigned long)to, 4) || + !IS_ALIGNED((unsigned long)from, 4)) ) + { + writeb(*(const uint8_t *)from, to); + from++; + to++; + count--; + } + + while ( count >=3D 4 ) + { + writel(*(const uint32_t *)from, to); + from +=3D 4; + to +=3D 4; + count -=3D 4; + } + + while ( count ) + { + writeb(*(const uint8_t *)from, to); + from++; + to++; + count--; + } +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 8 + * tab-width: 8 + * indent-tabs-mode: t + * End: + */ diff --git a/xen/include/xen/io.h b/xen/include/xen/io.h index 164a20c5d7..1bb164b6ef 100644 --- a/xen/include/xen/io.h +++ b/xen/include/xen/io.h @@ -67,4 +67,14 @@ static inline bool write_mmio(volatile void __iomem *mem= , unsigned long data, return true; } =20 +/* + * Copy between regular memory and MMIO space. Implementations are + * architecture-specific and must use appropriate MMIO accessors for + * their memory and I/O models. + */ +void memcpy_fromio(void *to, const volatile void __iomem *from, + size_t count); +void memcpy_toio(volatile void __iomem *to, const void *from, + size_t count); + #endif /* XEN_IO_H */ --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Jan 29 14:17:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 14:17:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216560.1526491 (Exim 4.92) (envelope-from ) id 1vlSpf-0000uW-C6; Thu, 29 Jan 2026 14:17:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216560.1526491; Thu, 29 Jan 2026 14:17: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 1vlSpf-0000uP-96; Thu, 29 Jan 2026 14:17:15 +0000 Received: by outflank-mailman (input) for mailman id 1216560; Thu, 29 Jan 2026 14:17: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 1vlSpe-0000f7-7g for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 14:17: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 2c29b40e-fd1d-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 15:16:58 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by VI1PR03MB10078.eurprd03.prod.outlook.com (2603:10a6:800:1ca::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Thu, 29 Jan 2026 14:16: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%4]) with mapi id 15.20.9564.008; Thu, 29 Jan 2026 14:16: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: 2c29b40e-fd1d-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=k/+oA24rAnNN3LVmjEZgScB+N4fXqKKUzOfG/tjc76f98i8K8beA0+xmOuelyNFiooF7lrnfESmghrseSteKQXv2Zj8dzCr4zNLKHiaOYgkIy5mvgcrgAYSO0DqQ1GK49tBe3T+MvoCh5tHDnKm40A/PbYHvPhNkmIUuKsubCnsNelRR8RmRxQjVyD5UWePiVLbbZTCbyQMUrnAJYy96OksW4U8Xm59SWP/wLdbUm8qG+U5MPo7jgOKcbjUXWQzNXIv8QVL66ythNoRUfhY2UIVbYD0DIczbQN8euqt5xuV7yoK6mTGurHZF9V+m80X54KNpH1xML7DETT5u+jiqXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=75F7LBZs/9A/ecjgSuQlaiwP8pV0QmiImg6+C8Z/ZQo=; b=pgARHeEYjTcAncE2fVnq+mWTLUkdJXgNTJE3om+HMEzBMIx5Gqb3eLWhbJoeKpZovz5Fg72HYf+aB7VA64KHihKfua7kTKh2NG7eveP0w1turdNQmSrh5hzxM+B86c2ZAyNjLJNNrEVOI6PfRG6s59D2jSlXxooj5pI6dkANypmrkVHzb/viaKZUaPzdIc3af9P6YYmNAlaTAvKokjoCmu3YRse1FgKGpZ2sWRmyxjHmlPi6q31Vi0AdsMakG9wm45owCtzPQ/ROeel4N40B8Lc4SHI6WFVXtJIvbJe6bUIqs9PpjOjTlFpXAPazxcKWyzJ7c4jkwAFV/I34o86tSw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=75F7LBZs/9A/ecjgSuQlaiwP8pV0QmiImg6+C8Z/ZQo=; b=UsG1XF5D0tao4vR/TqgDNb0hQlrYzzUGo2e7ltGp2zEtLvP4jaUA8Grwu9pCtl4y4I2EmBeQzNKKM0Ky0YLrwszvv1T8ETzUniuxYtvWIDl5fVJ7oA5BgprDQOBuTOfk/sem8EDckcgI2t/DyU300MnkPUpnMl8ZvbGkgo4aG1VOf8Bu/ugZKtQ47Y1iGP0gpms5hEdncXftbMwsTR9HL/8u8U1MQvjN8n+i3tN2yHIFWJCM3LEwJBk0d0nZhLjs++wW3Kmut9A3KxGTwBiZpsoGjN74ZA+d9n58YAbD0iS4B/Eqn3HmfGP7aEfcHZPwt0S2JBaEYaaHypUHTebGWg== 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 , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v9 1/5] xen/domctl: chain SCI handling before IOMMU in assign_device domctl Thread-Topic: [PATCH v9 1/5] xen/domctl: chain SCI handling before IOMMU in assign_device domctl Thread-Index: AQHckSnr8YaBhevnIkKApayON29DqQ== Date: Thu, 29 Jan 2026 14:16:54 +0000 Message-ID: <69d32e2440b2ef194b4893e5dd29c2dd9d216a90.1769696107.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_|VI1PR03MB10078:EE_ x-ms-office365-filtering-correlation-id: e68d8cb4-2673-47f7-3339-08de5f410e03 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: =?utf-8?B?SEQrVGRnUnh3SEZ0QWV3V1lTZlNGaitWZTVoNVFPKzBHcVIrc2FkcTJPY1NK?= =?utf-8?B?R0xUbzVmQWlmREN3M1BiVkdHL2E4V1BmY3Z2QlRyUmdiQnRXa0NmM2VGWlVS?= =?utf-8?B?UnJiRGpZZnVYUXNFbSsxeGZ0cjBHb0JvWFpYcHNrUTBZTlNEMy9CVmlGaDlp?= =?utf-8?B?aXRGOU1oVUhUL1M5a055VVZsMEVQYllnR044SWZLWHRVeStsNGtDVnJNQWVo?= =?utf-8?B?VFJkNlppMDlaK2JRTkh5OXhQZkc0RVF2czJsSWVReFhwMkxLZGdrVkdQQnVU?= =?utf-8?B?dEtIemdqOFFpSVhwZ3VMeGJielJHaHUzYjJJTjhmdnVJNnlLbEFaSDJxL0FF?= =?utf-8?B?Ti80UkdzS3F2cVhnUktwYUZVWkllbnliSmlGeFQvZ2ZqUmlGVXdDZWY4MjJL?= =?utf-8?B?d0ZIVnI4Z2gzZVBjTFFKSmRjbjZDdnpSek5EMHl3UWVWQlZRbUNxMFlsSFRX?= =?utf-8?B?bjVJcEhvUkw0aUJyVEN6ZW4yS0N6Tm9yOS9BRzhxQWdCT056dUx5VFFWNUxj?= =?utf-8?B?Wll5SUFSTU8xaENyNENON1p2SnBsRkd2ams1TGp5ejJwWUhuWGhhenN0cTZW?= =?utf-8?B?aTVPaFU1NUtOc05RNTJwNlZqM1NUbDhwcUVjQThvWVUxMjVrUWQ3NERzT3ps?= =?utf-8?B?RUZCZFA1cjNHald5VmtlZkt3K1ZOM0cxa3ljdE9WZy9obmF5ZGMwUzdNTDFC?= =?utf-8?B?cnhOVmUxcjBzME54RTI3VUZhWGQxcE04ODAxMUNaczBqeTNKSGR6RlhzUytF?= =?utf-8?B?QVFRNi9EZndLd0JXSjR3RmpyN1p2QnBZUEY3M3RCZTV2dlJDaEduOXRzNEFv?= =?utf-8?B?V2tTSW1Mem9SWjdEaGVXNXdnc0dMZ1pJNTM5SGt4T0VDZ0JNRUI1c1FzL1E3?= =?utf-8?B?Yy9DNjNyOGtMYmErZVozeWwxcnk0UzBJLzh0SlNDa1Vvd1E4OHZ4Zk10bVpW?= =?utf-8?B?RkUyUEZXajZNN1JaazgwNHF6OFk5bG9oMGNiQVNVVlNvY1gweHpWYUNQa0Fs?= =?utf-8?B?Nmh0N3FyMUhVV3FEdDI4K2xZT1NDYWpxV1VFdUkrSGtEL2tRUjNRNXVQKzhm?= =?utf-8?B?QlJDV3lkMHVMRSsvNjhIaVVic3ZpbHZ3NmVVU2pleUt5VEFFSTE1UVN2Y3lq?= =?utf-8?B?dVFFSjNnS1JWVm9VTUNWTVRnQ1hRNHA5WHYveG9tVE4yVkJKdXZaNFA3cnAx?= =?utf-8?B?eXcvUjl0bzFFeGRvcDh3WjFPYWFvZjB2ZTY2cmZOSEQzRllRRU05b0tEemx2?= =?utf-8?B?TTFENWEvNXZORkdEWDhwRDFnYStqcVUwc3R1WDRGY1ZkQ25RZ1ZINUlqVDdm?= =?utf-8?B?R09ZWTNXWnp5L0tGa0dueWdlZDludmc0TmZkNzkvN0pEWmJOL0FvMkMrU053?= =?utf-8?B?Nk03ZU9aOTFKdHFXa2tkWjFaYmJGNVQxMmtRM2p1c2UyR3ZwQ3lzamFWVEtH?= =?utf-8?B?ZXZFR2JDVVBGZENRR0dCZ3loMWpaSFBUYWFldDFrRVZIY1h6S2JTRjBYQm1S?= =?utf-8?B?S3U4SlZNbWYzWFJkRnV1ZTVXZzUxL3RieERyYnpFN2YvVXRubmNZUk5sNUZR?= =?utf-8?B?WU0wM3Z6UHBuZ3hRSkIrVUpGelZpYWs1VGp2SUczWjZOdzdHTDB6Mks5amxO?= =?utf-8?B?eTE5RFBFYzBhWkpKVUROczJDd1NITnJ4WklVdGEzTC9CQTFUenlldHJ4OEtS?= =?utf-8?B?dkVDaVhwM3UrM3dYY3RDaVFYNEZ6MnE1WmR4TjQ4RDVLdUVia0pkb3hHeXRH?= =?utf-8?B?Y1pvWnZJOGRjMkVoVTRvajJvZklVNUYxMVM1aEVFdHZPVkdmYTdBU3lxemNI?= =?utf-8?B?ZTg5NVh1YXZNMHFvbVJ0SFEyNU5IM29XV0lqTE45L2ZsYUd1b1NkcnUvQ3Vj?= =?utf-8?B?U0dySTRxUmZGS1JBaytSSG9SVWhaN0M2SlRkR2lya0s2aWNJWm9sR05ReDlv?= =?utf-8?B?NExVb1RvZXZma0Rqd2JhUG9CN3NkL3N2SlQ2Nll6NGtQc3VPd2VhaWN3OVhv?= =?utf-8?B?UWJnZFJrUFBTV3F0NUZXenZDYlJVK1owM1FxRFBibmc2UGFxaUQyTFNMTjli?= =?utf-8?B?ZVZqRVNVMmM0blpSMjBDaUJWby9xMWRtWDNkazhWY1BmYndIOGx1Z1BHNFU1?= =?utf-8?B?U3JFeEcyZFVqUWEyc2NuUjROMitWV2xqTGN1SkdjU0lBMTljK3ZabkN6bk5E?= =?utf-8?Q?Jdbxx8pXyrhhAANvDYOu/Ig=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)(376014)(7416014)(1800799024)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Rm5Id2lscjNidm1vQlU3VWJRWEZrN1c5Nmt2eEpwRldQNDBuYjRwaW9mME55?= =?utf-8?B?L0FWcjJCWUxuYTlqSU9WYUtWelVXZTZPNkM0ZnVhSUJ2dHgyb0ZjOGN3Sk9S?= =?utf-8?B?RCthQStJT0U0eUFXTVp5KzVkMVRSOEJ2VytDTWh3b0tpbFlyMVUrK0hzdHhR?= =?utf-8?B?ZE5lUFB4MUpZQTF5aVBzTGg0VmhYTU9SQm9jdkx2a2RhbCtqQVNDemt4Z2F4?= =?utf-8?B?NE5vTlJKbjM0Y3M5dHM2S01mOUlqckNlSVIyd21YZzFFR3dGUk44LzdGNkdQ?= =?utf-8?B?aGxrMVg2YWV4SEZmaVRWS2pIRnVLR0gxWklXQUN4eFQ4ckdYQm9CRDROMTlW?= =?utf-8?B?UlBpUERsT3R6aTl1MnQzSzVsZWJwRFpmeGNaZklKZE9wWENhdTY3cVkrN1BP?= =?utf-8?B?c3BGNXhIZHU2RmxZd1NhajVWMVA1UDNGcFdCelpRRkE1L3dEQld4b0FEWE91?= =?utf-8?B?bzZZcUVoL1VFaHl4YjBtVjdEbkczYUpROUdRMkVCVVQ2MzFOd2JXWjFENGh3?= =?utf-8?B?K3lYUWZibWRlMk9FV052V0lZcEhiQmcyZWtsQXRBTkdqbGhXbE5BNm94QzlP?= =?utf-8?B?MkNmN2RmQTVDUkw1SHJ1NlZ4Qjc5NytGVlYxVW9pbUg5U1Z3bnZoMlE1cU02?= =?utf-8?B?UDFXSGlPTkQ3cUJHM3hWSHBiK3ljMzZocTAvSzZScFVqVzNnNUhuWnpjMXl3?= =?utf-8?B?anlxakNtV0FkNGhLYVhSWWw3WDhVOWRqc2lXQUgrUTNCYzA3UnpqNFF0VWg5?= =?utf-8?B?T1NNR0pReWZ5NFczYVNGM3Z1aXhQVW11QXFGMGRzOEM2TndWbVR2RXlPUDBi?= =?utf-8?B?d3RKK2pQWTRBSEhCYVFOR1JmWkc3NVJBN3Q0OUlpVDVhVFdtQWZPL1V3V2c2?= =?utf-8?B?UnNxTVlrRGovUGQ1L3BYcFVyUzcwdVVFWVRpdGxjNHVEZFNBcGlYeUs5WktV?= =?utf-8?B?Y0svTm1RbE1XdGxZMWFydndoR3RwR1JZdXRwdkJGYlI0MDhYa211azMwZkNq?= =?utf-8?B?cHJ0ZEJHckdyd01PRTBrYzRQaTZMUnMyWDVueVhkd1gxZVZ6RFNwSUxkbVJ3?= =?utf-8?B?ZHI3NHhxbHgzK2NicDMxbWV3RUw5eXJZaDFxUVdQRVRQRS82V3ZXQ2tvOTlS?= =?utf-8?B?TllrY2drU2pvT3gyODdTaXBsSmNxUExpY0pTYytGdXJ6QmdVUzk2alg2Qm8y?= =?utf-8?B?MFU4VkgzNnZaSWdSMVkyL1ROYUQ4TWZyeU5JTjVjT3dNYkF0Um5tRFRXbG5a?= =?utf-8?B?M3lEbTRJZGNmTWlHQWo4enY5cFZ5S2RyeW1kd2dEVkFwYnhBSXhpeGpiakdR?= =?utf-8?B?bkplWVBpSVdYM2pOYndkUWxmYm1uZU5TekhrVWpaR1JUWkVEUkpDckpxVXFw?= =?utf-8?B?YXh2djRiYnU3REc4RStkUzlyby93VzJvQWtncmtjS3RDbWtZTTBwY2p3VGlm?= =?utf-8?B?KzVYQ1VXZHlNaHJieGJQT01vMVZGZWlha3pDd3RHRHU5Y2lOZGNneGsyMUNw?= =?utf-8?B?ZmFBQUUyK3Ayak1oOUZoSk5mQ0gwZVppT1dlMDgxeTYvb01Qa3ByT2drRmlR?= =?utf-8?B?MWk0amllLzhYa0ZHdnl6TjJZaDN4MWtpU2pqb3FFcnRLbFU3K0tYbzU2VUNN?= =?utf-8?B?R05GWjJVNWtQUlRKQ3lBSHFueTlmb3FkemNycHNSR1JXNzUzWEhDUVMxR2pr?= =?utf-8?B?WGVMWXVxZGU3eW96bjlYanF1M2crSXdQck0wRnl5RGs2d1FXWkp6c2dZd2I3?= =?utf-8?B?R2drMlR0Z3lFZ0YwMUxod0hvUExwQkFjeGJ5K2dUZWdHeXd0b256V2pXL0FP?= =?utf-8?B?akFMVVRZSGFnQWtCSWx4Z1ZDNWJnVjBhcGZWckExWmNpNkNadGNZNUlySDkr?= =?utf-8?B?TzEvQks2UkdrQXhPalVPY0ZEVGRIbXdhOXhTZlB6V2QxQnF6L0UvcXVUWlQy?= =?utf-8?B?TE5YRnpvdDZjQU5oT3d1aUNBcGxianp1VXFVSkR3YnJrdW1BTEVLUDUyK0J3?= =?utf-8?B?a0NCWEplWHdzRVBFR0FyWG9WM2xxTWNWQjRjUTNhN0VkSW43QkFwK1hhdzEr?= =?utf-8?B?c1ltNGN4S1BIa1FWakJycDU2QVMxMFBwemI0ZG9lamUrL2pyRE1EeXF1UkZJ?= =?utf-8?B?cnVHeEpsSlltZ0EzTGJPbENrQ0RBYjVrRW1PdWhOblJXUDkwbmxCVmVlM2J6?= =?utf-8?B?c3p1ejNnaGwwQm9NSVcvVlBEMDFsQk9QeHIzL0dBbEF0SU5GMk1US0Y3UHNW?= =?utf-8?B?Vld2WkdTaFJPMXVISnNpR3NHSnRMYzNxbzVqTm03d1Y1cmxBK1VBRDIxcHd0?= =?utf-8?B?QVdtSTlSckFhNERpMktwYnJjbTd3NlBRVy9kQVdOWnVGOCsxSUdHVllDeCtG?= =?utf-8?Q?8xeSEk0LHXbkieqk=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <8CA1116734CEC7429F2A6F422342FE64@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: e68d8cb4-2673-47f7-3339-08de5f410e03 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2026 14:16:54.4945 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ytCzkhsK01vkiCMs+rrIzYIr0QiE72KXR7DT1xRuNb7RIW6Pzq6xTSAUzRYzQrhhSVyvDgC7GqSrDH9oh+Xk9OccjasQSij3RXbX6yw7b18= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB10078 RnJvbTogR3J5Z29yaWkgU3RyYXNoa28gPGdyeWdvcmlpX3N0cmFzaGtvQGVwYW0uY29tPg0KDQpB ZGQgY2hhaW5lZCBoYW5kbGluZyBvZiBhc3NpZ25lZCBEVCBkZXZpY2VzIHRvIHN1cHBvcnQgYWNj ZXNzLWNvbnRyb2xsZXINCmZ1bmN0aW9uYWxpdHkgdGhyb3VnaCBTQ0kgZnJhbWV3b3JrLCBzbyBh IERUIGRldmljZSBhc3NpZ24gcmVxdWVzdCBjYW4gYmUNCnBhc3NlZCB0byBmaXJtd2FyZSBmb3Ig cHJvY2Vzc2luZyBhbmQgZW5hYmxpbmcgVk0gYWNjZXNzIHRvIHRoZSByZXF1ZXN0ZWQNCmRldmlj ZSAoZm9yIGV4YW1wbGUsIGRldmljZSBwb3dlciBtYW5hZ2VtZW50IHRocm91Z2ggU0NNSSkuDQoN ClRoZSBTQ0kgYWNjZXNzLWNvbnRyb2xsZXIgRFQgZGV2aWNlIHByb2Nlc3NpbmcgaXMgY2FsbGVk IGJlZm9yZSB0aGUgSU9NTVUNCnBhdGguIEl0IHJ1bnMgZm9yIGFueSBEVC1kZXNjcmliZWQgZGV2 aWNlIChwcm90ZWN0ZWQgb3Igbm90LCBhbmQgZXZlbiB3aGVuDQp0aGUgSU9NTVUgaXMgZGlzYWJs ZWQpLiBUaGUgSU9NTVUgcGF0aCByZW1haW5zIHVuY2hhbmdlZCBmb3IgUENJIGRldmljZXM7DQpv bmx5IHRoZSBEVCBwYXRoIGlzIHJlbGF4ZWQgdG8gcGVybWl0IG5vbi1JT01NVSBkZXZpY2VzLg0K DQpUaGlzIGxldHMgeGwuY2ZnOiJkdGRldiIgbGlzdCBib3RoIElPTU1VLXByb3RlY3RlZCBhbmQg bm9uLXByb3RlY3RlZCBEVA0KZGV2aWNlczoNCg0KZHRkZXYgPSBbDQogICAgIi9zb2MvdmlkZW9A ZTZlZjAwMDAiLCA8LSBJT01NVSBwcm90ZWN0ZWQgZGV2aWNlDQogICAgIi9zb2MvaTJjQGU2NTA4 MDAwIiwgPC0gbm90IElPTU1VIHByb3RlY3RlZCBkZXZpY2UNCl0NCg0KVGhlIGNoYW5nZSBpcyBk b25lIGluIHR3byBwYXJ0czoNCjEpIGNhbGwgc2NpX2RvX2RvbWN0bCgpIGluIGRvX2RvbWN0bCgp IGJlZm9yZSBJT01NVSBwcm9jZXNzaW5nLiBJZg0Kc2NpX2RvX2RvbWN0bCgpIHJlcG9ydHMgYW4g ZXJyb3Igb3RoZXIgdGhhbiAtRU5YSU8sIHRyZWF0IGl0IGFzDQphdXRob3JpdGF0aXZlIGFuZCBz a2lwIHRoZSBJT01NVSBwYXRoLiBBIHJldHVybiBvZiAtRU5YSU8gaW5kaWNhdGVzDQp0aGF0IFND SSBkaWQgbm90IGhhbmRsZSB0aGUgcmVxdWVzdCBhbmQgaXMgaWdub3JlZCwgYWxsb3dpbmcgdGhl DQpleGlzdGluZyBJT01NVSBoYW5kbGluZyB0byBydW4gdW5jaGFuZ2VkOw0KMikgdXBkYXRlIGlv bW11X2RvX2R0X2RvbWN0bCgpIHRvIGNoZWNrIGZvciBkdF9kZXZpY2VfaXNfcHJvdGVjdGVkKCkg YW5kDQpub3QgZmFpbCBpZiBEVCBkZXZpY2UgaXMgbm90IHByb3RlY3RlZCBieSBJT01NVS4gaW9t bXVfZG9fcGNpX2RvbWN0bA0KZG9lc24ndCBuZWVkIHRvIGJlIHVwZGF0ZWQgYmVjYXVzZSBpb21t dV9kb19kb21jdGwgZmlyc3QgdHJpZXMNCmlvbW11X2RvX3BjaV9kb21jdGwgKHdoZW4gQ09ORklH X0hBU19QQ0kpIGFuZCBmYWxscyBiYWNrIHRvDQppb21tdV9kb19kdF9kb21jdGwgb25seSBpZiBQ Q0kgcmV0dXJucyAtRU5PREVWLg0KDQpUaGUgbmV3IGR0X2RldmljZV9pc19wcm90ZWN0ZWQoKSBi eXBhc3MgaW4gaW9tbXVfZG9fZHRfZG9tY3RsIG9ubHkNCmFwcGxpZXMgdG8gRFQtZGVzY3JpYmVk IGRldmljZXM7IFNDSSBwYXJhbWV0ZXJzIGFyZSBjYXJyaWVkIHZpYSBEVA0Kbm9kZXMuIFBDSSBk ZXZpY2VzIGhhbmRsZWQgYnkgaW9tbXVfZG9fcGNpX2RvbWN0bCBkbyBub3QgY2FycnkgRFQvU0NJ DQptZXRhZGF0YSBpbiB0aGlzIHBhdGgsIHNvIHRoZXJlIGlzIG5vIG5vdGlvbiBvZiDigJxTQ0kg cGFyYW1ldGVycyBvbiBhDQpub24tSU9NTVUtcHJvdGVjdGVkIFBDSSBkZXZpY2XigJ0gZm9yIGl0 IHRvIGludGVycHJldCBvciB0byBza2lwLiBUaGUgUENJDQpwYXRoIHNob3VsZCBjb250aW51ZSB0 byByZXBvcnQgZXJyb3JzIGlmIGFzc2lnbm1lbnQgY2Fubm90IGJlIHBlcmZvcm1lZA0KYnkgdGhl IElPTU1VIGxheWVyLiBTbyB3ZSBzaG91bGQgbGVhdmUgaW9tbXVfZG9fcGNpX2RvbWN0bCB1bmNo YW5nZWQ7IHRoZQ0KU0NJL0RULXNwZWNpZmljIHJlbGF4YXRpb25zIGJlbG9uZyBvbmx5IGluIHRo ZSBEVCBwYXRoLiBBbHNvIFNDSSBoYW5kbGluZw0Kb25seSBleGlzdHMgd2hlbiBEVCBpcyBwcmVz ZW50Lg0KDQpTaWduZWQtb2ZmLWJ5OiBHcnlnb3JpaSBTdHJhc2hrbyA8Z3J5Z29yaWlfc3RyYXNo a29AZXBhbS5jb20+DQpTaWduZWQtb2ZmLWJ5OiBPbGVrc2lpIE1vaXNpZWlldiA8b2xla3NpaV9t b2lzaWVpZXZAZXBhbS5jb20+DQotLS0NCg0KQ2hhbmdlcyBpbiB2OToNCi0gdHJlYXQgU0NJIGFz IGEgZ2F0ZSBmb3IgWEVOX0RPTUNUTF8qYXNzaWduX2RldmljZTogYWJvcnQgYmVmb3JlDQpJT01N VSBpZiBzY2lfZG9fZG9tY3RsKCkgcmV0dXJucyBhbiBlcnJvciBvdGhlciB0aGFuIC1FTlhJTywg aW5zdGVhZA0Kb2YgdHJ5aW5nIHRvIHByb3BhZ2F0ZSBTQ0kgZXJyb3JzIGFmdGVyIGEgc3VjY2Vz c2Z1bCBJT01NVQ0Kb3BlcmF0aW9uLiBUaGlzIGF2b2lkcyBwYXJ0aWFsIHN1Y2Nlc3MgYW5kIHRo ZSBuZWVkIGZvciBJT01NVSByb2xsYmFjay4NCi0gcmVtb3ZlIGVhcmx5IHJldHVybiBmcm9tIGRv X2RvbWN0bCgpIGluIHRoZSBhc3NpZ25fZGV2aWNlDQpwYXRoIHRvIGtlZXAgUkNVIGhhbmRsaW5n IGludGFjdC4NCi0gY2hhbmdlIElTX0VOQUJMRUQoKikgdG8gI2lmZGVmIGluIHNjaV9kb19kb21j dGwgcXVhcmQNCg0KQ2hhbmdlcyBpbiB2ODoNCi0gY2hlY2sgZm9yIENPTkZJR19BUk1fU0NJIHRv IGJlIGViYWJsZWQgaW5zdGVhZCBvZiBDT01GSUdfQVJNIGJlZm9yZQ0KY2FsbGluZyBzY2lfZG9f ZG9tY3RsDQotIHJld29yayBzY2lfZG9fZG9tY3RsIGNhbGwgdG8gYXZvaWQgZXh0cmEgY2hlY2tz LCBpbXByb3ZlZCBlcnJvcg0KaGFuZGxpbmcuDQotIGRvIG5vdCBwcm9wYWdhdGUgcmV0MSBpZiBz Y2lfZG9fZG9tY3RsIHJldHVybmVkIHBvc2l0aXZlIHJldA0KLSB1cGRhdGVkIGNvbW1lbnQgaW4g ZG9tY3RsLmMgY29kZQ0KDQpDaGFuZ2VzIGluIHY3Og0KLSB1cGRhdGUgZG9tY3RsIHRvIGJ1aWxk IG9uIGJvdGggQXJtIGFuZCB4ODYgcGxhdGZvcm1zDQotIG1vdmUgcmV0MSBkZWNsYXJhdGlvbiB0 byB0aGUgdG9wIG9mIHRoZSBmdW5jdGlvbiBhcyByZXF1aXJlZCBieSBjb2RlDQpzdHlsZQ0KDQpD aGFuZ2VzIGluIHY2Og0KLSBjaGFuZ2UgaW9tbXVfZG9fZG9tY3RsIGFuZCBzY2lfZG9fZG9tY3Rs IGNvbW1hbmQgb3JkZXIgYW5kDQpjYWxsIHNjaV9kb19kb21jdGwgZmlyc3Qgd2hpY2ggd2lsbCBw cm9kdWNlIGNsZWFuZXIgY29kZSBwYXRoLg0KQWxzbyBkcm9wcGVkIGNoYW5naW5nIHJldHVybiBj b2RlIHdoZW4gaW9tbXUgd2FzIGRpc2FibGVkIGluDQppb21tdV9kb19kb21jdGwuDQoNCkNoYW5n ZXMgaW4gdjU6DQotIHJldHVybiAtRUlOVkFMIGlmIG1lZGlhdG9yIHdpdGhvdXQgYXNzaWduX2R0 X2RldmljZSB3YXMgcHJvdmlkZWQNCi0gaW52ZXJ0IHJldHVybiBjb2RlIGNoZWNrIGZvciBpb21t dV9kb19kb21jdGwgaW4NClhFTl9ET01DVExfYXNzaWduX2RldmljZSBkb21jdGwgcHJvY2Vzc2lu ZyB0byBtYWtlIGNsZWFuZXIgY29kZQ0KLSBjaGFuZ2UgLUVOT1RTVVBQIGVycm9yIGNvZGUgdG8g LUVOWElPIGluIHNjaV9kb19kb21jdGwNCi0gaGFuZGxlIC1FTlhJTyByZXR1cm4gY29tZGUgb2Yg aW9tbXVfZG9fZG9tY3RsDQotIGxlYXZlICFkdF9kZXZpY2VfaXNfcHJvdGVjdGVkIGNoZWNrIGlu IGlvbW11X2RvX2R0X2RvbWN0bCB0byBtYWtlDQpjb2RlIHdvcmsgdGhlIHNhbWUgd2F5IGl0J3Mg ZG9uZSBpbiAiaGFuZGxlX2RldmljZSIgY2FsbCB3aGlsZQ0KY3JlYXRpbmcgaHdkb20oZG9tMCkg YW5kICJoYW5kbGVfcGFzc3Rocm91Z2hfcHJvcCIgY2FsbCBmb3IgZG9tMGxlc3MNCmNyZWF0aW9u DQotIGRyb3AgcmV0dXJuIGNoZWNrIGZyb20gc2NpX2Fzc2lnbl9kdF9kZXZpY2UgY2FsbCBhcyBu b3QgbmVlZGVkDQotIGRvIG5vdCByZXR1cm4gRUlOVkFMIHdoZW4gYWRkaWduX2R0X2RldmljZSBp cyBub3Qgc2V0LiBUaGF0IGlzDQpiZWNhdXNlIHRoaXMgY2FsbGJhY2sgaXMgb3B0aW9uYWwgYW5k IG5vdCBpbXBsZW1lbnRlZCBpbiBzaW5nbGUtYWdlbnQgZHJpdmVyDQoNCiB4ZW4vYXJjaC9hcm0v ZmlybXdhcmUvc2NpLmMgICAgICAgICAgICAgfCAzNiArKysrKysrKysrKysrKysrKysrKysrKysr DQogeGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2Zpcm13YXJlL3NjaS5oIHwgMTQgKysrKysrKysr Kw0KIHhlbi9jb21tb24vZG9tY3RsLmMgICAgICAgICAgICAgICAgICAgICB8IDE1ICsrKysrKysr KysrDQogeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvZGV2aWNlX3RyZWUuYyAgIHwgIDYgKysrKysN CiA0IGZpbGVzIGNoYW5nZWQsIDcxIGluc2VydGlvbnMoKykNCg0KZGlmZiAtLWdpdCBhL3hlbi9h cmNoL2FybS9maXJtd2FyZS9zY2kuYyBiL3hlbi9hcmNoL2FybS9maXJtd2FyZS9zY2kuYw0KaW5k ZXggYWE5M2NkYTdmMC4uYTZjNjQ3YTA5ZCAxMDA2NDQNCi0tLSBhL3hlbi9hcmNoL2FybS9maXJt d2FyZS9zY2kuYw0KKysrIGIveGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjaS5jDQpAQCAtMTI2LDYg KzEyNiw0MiBAQCBpbnQgc2NpX2Fzc2lnbl9kdF9kZXZpY2Uoc3RydWN0IGRvbWFpbiAqZCwgc3Ry dWN0IGR0X2RldmljZV9ub2RlICpkZXYpDQogICAgIHJldHVybiAwOw0KIH0NCiANCitpbnQgc2Np X2RvX2RvbWN0bChzdHJ1Y3QgeGVuX2RvbWN0bCAqZG9tY3RsLCBzdHJ1Y3QgZG9tYWluICpkLA0K KyAgICAgICAgICAgICAgICAgIFhFTl9HVUVTVF9IQU5ETEVfUEFSQU0oeGVuX2RvbWN0bF90KSB1 X2RvbWN0bCkNCit7DQorICAgIHN0cnVjdCBkdF9kZXZpY2Vfbm9kZSAqZGV2Ow0KKyAgICBpbnQg cmV0ID0gMDsNCisNCisgICAgc3dpdGNoICggZG9tY3RsLT5jbWQgKQ0KKyAgICB7DQorICAgIGNh c2UgWEVOX0RPTUNUTF9hc3NpZ25fZGV2aWNlOg0KKyAgICAgICAgcmV0ID0gLUVOWElPOw0KKyAg ICAgICAgaWYgKCBkb21jdGwtPnUuYXNzaWduX2RldmljZS5kZXYgIT0gWEVOX0RPTUNUTF9ERVZf RFQgKQ0KKyAgICAgICAgICAgIGJyZWFrOw0KKw0KKyAgICAgICAgaWYgKCAhY3VyX21lZGlhdG9y ICkNCisgICAgICAgICAgICBicmVhazsNCisNCisgICAgICAgIGlmICggIWN1cl9tZWRpYXRvci0+ YXNzaWduX2R0X2RldmljZSApDQorICAgICAgICAgICAgYnJlYWs7DQorDQorICAgICAgICByZXQg PSBkdF9maW5kX25vZGVfYnlfZ3BhdGgoZG9tY3RsLT51LmFzc2lnbl9kZXZpY2UudS5kdC5wYXRo LA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRvbWN0bC0+dS5hc3NpZ25f ZGV2aWNlLnUuZHQuc2l6ZSwgJmRldik7DQorICAgICAgICBpZiAoIHJldCApDQorICAgICAgICAg ICAgcmV0dXJuIHJldDsNCisNCisgICAgICAgIHJldCA9IHNjaV9hc3NpZ25fZHRfZGV2aWNlKGQs IGRldik7DQorDQorICAgICAgICBicmVhazsNCisNCisgICAgZGVmYXVsdDoNCisgICAgICAgIC8q IGRvIG5vdCBmYWlsIGhlcmUgYXMgY2FsbCBpcyBjaGFpbmVkIHdpdGggaW9tbXUgaGFuZGxpbmcg Ki8NCisgICAgICAgIGJyZWFrOw0KKyAgICB9DQorDQorICAgIHJldHVybiByZXQ7DQorfQ0KKw0K IHN0YXRpYyBpbnQgX19pbml0IHNjaV9pbml0KHZvaWQpDQogew0KICAgICBzdHJ1Y3QgZHRfZGV2 aWNlX25vZGUgKm5wOw0KZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9maXJt d2FyZS9zY2kuaCBiL3hlbi9hcmNoL2FybS9pbmNsdWRlL2FzbS9maXJtd2FyZS9zY2kuaA0KaW5k ZXggMzUwMDIxNmJjMi4uYTJkMzE0ZTYyNyAxMDA2NDQNCi0tLSBhL3hlbi9hcmNoL2FybS9pbmNs dWRlL2FzbS9maXJtd2FyZS9zY2kuaA0KKysrIGIveGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2Zp cm13YXJlL3NjaS5oDQpAQCAtMTQ2LDYgKzE0NiwxNCBAQCBpbnQgc2NpX2R0X2ZpbmFsaXplKHN0 cnVjdCBkb21haW4gKmQsIHZvaWQgKmZkdCk7DQogICogY29udHJvbCIgZnVuY3Rpb25hbGl0eS4N CiAgKi8NCiBpbnQgc2NpX2Fzc2lnbl9kdF9kZXZpY2Uoc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0 IGR0X2RldmljZV9ub2RlICpkZXYpOw0KKw0KKy8qDQorICogU0NJIGRvbWN0bCBoYW5kbGVyDQor ICoNCisgKiBPbmx5IFhFTl9ET01DVExfYXNzaWduX2RldmljZSBpcyBoYW5kbGVkIGZvciBub3cu DQorICovDQoraW50IHNjaV9kb19kb21jdGwoc3RydWN0IHhlbl9kb21jdGwgKmRvbWN0bCwgc3Ry dWN0IGRvbWFpbiAqZCwNCisgICAgICAgICAgICAgICAgICBYRU5fR1VFU1RfSEFORExFX1BBUkFN KHhlbl9kb21jdGxfdCkgdV9kb21jdGwpOw0KICNlbHNlDQogDQogc3RhdGljIGlubGluZSBib29s IHNjaV9kb21haW5faXNfZW5hYmxlZChzdHJ1Y3QgZG9tYWluICpkKQ0KQEAgLTE5NSw2ICsyMDMs MTIgQEAgc3RhdGljIGlubGluZSBpbnQgc2NpX2Fzc2lnbl9kdF9kZXZpY2Uoc3RydWN0IGRvbWFp biAqZCwNCiAgICAgcmV0dXJuIDA7DQogfQ0KIA0KK3N0YXRpYyBpbmxpbmUgaW50IHNjaV9kb19k b21jdGwoc3RydWN0IHhlbl9kb21jdGwgKmRvbWN0bCwgc3RydWN0IGRvbWFpbiAqZCwNCisgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFhFTl9HVUVTVF9IQU5ETEVfUEFSQU0oeGVuX2Rv bWN0bF90KSB1X2RvbWN0bCkNCit7DQorICAgIHJldHVybiAwOw0KK30NCisNCiAjZW5kaWYgLyog Q09ORklHX0FSTV9TQ0kgKi8NCiANCiAjZW5kaWYgLyogX19BU01fQVJNX1NDSV9IICovDQpkaWZm IC0tZ2l0IGEveGVuL2NvbW1vbi9kb21jdGwuYyBiL3hlbi9jb21tb24vZG9tY3RsLmMNCmluZGV4 IDI5YTc3MjZkMzIuLmIzZDEzODExODIgMTAwNjQ0DQotLS0gYS94ZW4vY29tbW9uL2RvbWN0bC5j DQorKysgYi94ZW4vY29tbW9uL2RvbWN0bC5jDQpAQCAtMjksNiArMjksOSBAQA0KICNpbmNsdWRl IDx4ZW4veHZtYWxsb2MuaD4NCiANCiAjaW5jbHVkZSA8YXNtL2N1cnJlbnQuaD4NCisjaWZkZWYg Q09ORklHX0FSTQ0KKyNpbmNsdWRlIDxhc20vZmlybXdhcmUvc2NpLmg+DQorI2VuZGlmDQogI2lu Y2x1ZGUgPGFzbS9pcnEuaD4NCiAjaW5jbHVkZSA8YXNtL3BhZ2UuaD4NCiAjaW5jbHVkZSA8YXNt L3AybS5oPg0KQEAgLTgzMyw2ICs4MzYsMTggQEAgbG9uZyBkb19kb21jdGwoWEVOX0dVRVNUX0hB TkRMRV9QQVJBTSh4ZW5fZG9tY3RsX3QpIHVfZG9tY3RsKQ0KICAgICBjYXNlIFhFTl9ET01DVExf dGVzdF9hc3NpZ25fZGV2aWNlOg0KICAgICBjYXNlIFhFTl9ET01DVExfZGVhc3NpZ25fZGV2aWNl Og0KICAgICBjYXNlIFhFTl9ET01DVExfZ2V0X2RldmljZV9ncm91cDoNCisgICAgICAgIC8qDQor ICAgICAgICAgKiBDaGFpbiBTQ0kgRFQgaGFuZGxpbmcgYWhlYWQgb2YgdGhlIElPTU1VIHBhdGgg c28gYW4gU0NJIG1lZGlhdG9yDQorICAgICAgICAgKiBjYW4gYXV0aG9yaXNlIGFjY2Vzcy1jb250 cm9sbGVkIERUIGRldmljZXMuIFVuaGFuZGxlZCBjYXNlcyByZXBvcnQNCisgICAgICAgICAqIC1F TlhJTywgd2hpY2ggaXMgaWdub3JlZC4gQW55IG90aGVyIFNDSSBlcnJvciBhYm9ydHMgYmVmb3Jl IHRoZQ0KKyAgICAgICAgICogSU9NTVUgcGF0aCBydW5zLg0KKyAgICAgICAgICovDQorI2lmZGVm IENPTkZJR19BUk1fU0NJDQorICAgICAgICByZXQgPSBzY2lfZG9fZG9tY3RsKG9wLCBkLCB1X2Rv bWN0bCk7DQorICAgICAgICBpZiAoIHJldCA8IDAgJiYgcmV0ICE9IC1FTlhJTyApDQorICAgICAg ICAgICAgYnJlYWs7DQorI2VuZGlmDQorDQogICAgICAgICByZXQgPSBpb21tdV9kb19kb21jdGwo b3AsIGQsIHVfZG9tY3RsKTsNCiAgICAgICAgIGJyZWFrOw0KIA0KZGlmZiAtLWdpdCBhL3hlbi9k cml2ZXJzL3Bhc3N0aHJvdWdoL2RldmljZV90cmVlLmMgYi94ZW4vZHJpdmVycy9wYXNzdGhyb3Vn aC9kZXZpY2VfdHJlZS5jDQppbmRleCBmNTg1MGEyNjA3Li4yOWE0NGRjNzczIDEwMDY0NA0KLS0t IGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvZGV2aWNlX3RyZWUuYw0KKysrIGIveGVuL2RyaXZl cnMvcGFzc3Rocm91Z2gvZGV2aWNlX3RyZWUuYw0KQEAgLTM3OSw2ICszNzksMTIgQEAgaW50IGlv bW11X2RvX2R0X2RvbWN0bChzdHJ1Y3QgeGVuX2RvbWN0bCAqZG9tY3RsLCBzdHJ1Y3QgZG9tYWlu ICpkLA0KICAgICAgICAgICAgIGJyZWFrOw0KICAgICAgICAgfQ0KIA0KKyAgICAgICAgaWYgKCAh ZHRfZGV2aWNlX2lzX3Byb3RlY3RlZChkZXYpICkNCisgICAgICAgIHsNCisgICAgICAgICAgICBy ZXQgPSAwOw0KKyAgICAgICAgICAgIGJyZWFrOw0KKyAgICAgICAgfQ0KKw0KICAgICAgICAgcmV0 ID0gaW9tbXVfYXNzaWduX2R0X2RldmljZShkLCBkZXYpOw0KIA0KICAgICAgICAgaWYgKCByZXQg KQ0KLS0gDQoyLjM0LjENCg== From xen-devel-bounces@lists.xenproject.org Thu Jan 29 14:17:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 14:17:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216561.1526501 (Exim 4.92) (envelope-from ) id 1vlSpi-0001An-Mg; Thu, 29 Jan 2026 14:17:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216561.1526501; Thu, 29 Jan 2026 14:17: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 1vlSpi-0001Ag-JG; Thu, 29 Jan 2026 14:17:18 +0000 Received: by outflank-mailman (input) for mailman id 1216561; Thu, 29 Jan 2026 14:17: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 1vlSpg-0000f7-ST for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 14:17:17 +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 35f4e909-fd1d-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 15:17:15 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by VI1PR03MB10078.eurprd03.prod.outlook.com (2603:10a6:800:1ca::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Thu, 29 Jan 2026 14:16: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%4]) with mapi id 15.20.9564.008; Thu, 29 Jan 2026 14:16: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: 35f4e909-fd1d-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nZYoMO2F0yT+5CsXGBsgiRM6R2RCh5PSrfqTVHaAy3CCzo967E4cLOGxmPtfcrtsIOYnkRq3K9c0tw8ZCjwN1OSK5b9UynU2ODyGYJBVmRtPQ02MtYu9tPwnrTlaR7iRFVCA1MQX2n6ZejiyHYrIxpnNm4Uw0Lme3ufEdgYSv+cXsc0UMFVNIlUc0ehqecC1/1d5HxqbdoydPwWi6VMWApK6zaMoTrPpU3OuD0q4ZjDAWrwrmcpIp/t2yie4K4mQKSArF8gJkMNCxupK+hZ19/9CX8DgATkxsq1Ri5mcBec/XRmuWHFetmSz3ifpSoRXhQJl6EH/awiPkFQ1bFC90A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HCnir6FyTl0MkOim348aozUpTkSAKo42qTUCO8vYPh8=; b=fcp5p7YhcoYQuE9MYWbDi4RvPM8TdkLxEIF0JjfaAsVqE3WDz5nRzyWK7QZvd+65p66N9/ie9OdmgD7k1dapmO7KupG/3QYy3seALnjWZZrxOYdsC7k+DM6RdrePFEVUDgtf7VEJDad2BjhqDyYD9lzNdMYb+b55Hw69IpOwwM90q47OShMx8F+emZpZeuKGauyue1aEIRJOYqbAVOU7BIm9H6AmIUAatJMPADFjN7xCEkXNZ47lnT3UWOWrAHvaRLO7bH9RNgrK/pyYZsRK4ddK4lfPZj4YmYt8WQ8eJuTIVukrMMPo2rZwf/u//830wr2IE35tG7hwZa3h+8CPNA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HCnir6FyTl0MkOim348aozUpTkSAKo42qTUCO8vYPh8=; b=X+XP3D9lNQBXHwt8sIOcnmEsS2lI4I/Ngcph9FH+tGPhvcCUKa6BAbmMD7ZwiWyPWcdaG7B8ptLZt5c/kT5E55wfAOttzvWUwLKY7VFW05cZLz/Iy+oNTUP+lz3m9+DwcBpTkpaJNPXLW/ouijWkG10s7W/U/u2fVXrzZu3xLwtdCkqQvnsnYmnVJF2meSGpS+NLtE5xv0oCfSg5JNFwqPWH/oxPQHqfoSHXxd/uRzSee3Jfyad5T+kF/Ar2p3BOh/WALnsp0vMWXTA0JgZN7U6gb2Jxcx5rE1AYJ0vhFz2EH8iL5fx694Ji8OAG+w4DdourcnHmkHKhgtdqXK1/mQ== 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 , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko Subject: [PATCH v9 0/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent support Thread-Topic: [PATCH v9 0/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent support Thread-Index: AQHckSnr+uGnkqf6KkOE37UMTCCmCQ== Date: Thu, 29 Jan 2026 14:16:54 +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_|VI1PR03MB10078:EE_ x-ms-office365-filtering-correlation-id: 1ecba2d6-eced-40a5-25e4-08de5f410db7 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: =?utf-8?B?T1BTeXBLTkROdWlIRmN2M2dBa0lhRzlST280ZjJsS09tampjd0xmeDczUHVI?= =?utf-8?B?YXJGSndKbGVYaTV4WkE1SnRiN0NXdkJmNVpqcko5QlhnTFhKYWFMZmFWNi94?= =?utf-8?B?QWVLT290SUF4NGFZcldlUzhoSXR1RnRPUjFObWxzb2tkZDhGcExqR2pVMHgw?= =?utf-8?B?WmMxWWZxUVF5a042aHlURTNvYUNlemhGeUVudStNTDN0NGtwSXRHMHBUWFB4?= =?utf-8?B?Vmh1bDRmODBFNzRhMmVHZVNHcFVGazRlQUk3a2pKUHBIUkl3bFRiZERsZ2th?= =?utf-8?B?YlMxMGViZ1RNS0thb0x4aFZKZFlwSHpJMjB0ejJjOVNZWmVFdHpzSHZqZUtn?= =?utf-8?B?OFZIdHF4NGZyd3FoSlJzQXlva250dEJEY2IxdXhaYkZPbHNTU2JTckdRZlh1?= =?utf-8?B?dWhxT1dNbTQ4Z1AvMUVOMGZqSWRpVnhBb0FucTdPRHBiM1ZwMUZVMG1mWFlS?= =?utf-8?B?bnN3UjdRZTZaOW9aZStSWlRMNVpCeUJleTdMMFU4YkIrVmR2V0VtR2hReDBD?= =?utf-8?B?WktTeEE0WFkxWkdYd0xxQWlxTGdMU2prK0lNVVRua2d5c3JocTB4NHZxWDhm?= =?utf-8?B?eDFPV0xhSWM4Y0lpbHl6ZFZ1ckNPNmw1TUdtdDZHSG5nQzlmMERqb1RMUVBJ?= =?utf-8?B?VmRuRW9CS2xIL0xkUUI3NmM2STl0c3RLdjFtSzhhcEhsNno0OGxlNjE0YndW?= =?utf-8?B?Tnl6UnJvQWh1WlM1UWhWNkhyUVduQmVCK05xbzcrRG9POXZsbk5zY01GdzRh?= =?utf-8?B?SUF4YXFGRERQWExzUkliZWloNktVbm40UzF2WXBxUmpoTElkYy9KRUVub2FR?= =?utf-8?B?NHFyUTBqUGNaQU5NRlFENTNjSVBhT0Z1Nld0MHJnM2FIRGczNjF2K2tOMzY4?= =?utf-8?B?L2Jtdi9SNXhGSGN5R0ZiZXg4OXlLcVJEN281azR2NkQzVnRxKzJ6YXFBSVY4?= =?utf-8?B?MUdlWitBSzAxU3M0S3ZLU0dpcWF6SjJQK0pyeElzUk9MMGRPRXlGRXQ5STM1?= =?utf-8?B?bFNGLzVkMXk1b2hWNGxUVXFoVDJYeFpLLzdnYVFGQk9Jakx1NmY0RTEwQldM?= =?utf-8?B?M1lYNlYrUUtnY01HTk94V01yTVlhRjBXYTlwUWhjdkpabW1hOFVVSUt0TXVV?= =?utf-8?B?SnVRbmhSdjlLWTg2TkVvdzNkTW45K3IrekJlZ0dkMlpwV2NvMHJqd3BoUlZw?= =?utf-8?B?Z0plUk9nbHpBS3FSUkFSNGxiRkhkVThKdU1MTS9lY1ZzSkR2TkhrVEVXbjRz?= =?utf-8?B?K2luOUtvc0ZtSitPcHFLMGlsRTVaeTM5Tm1NamJPcVA4UTNHelRWeGhqSHZP?= =?utf-8?B?THQycnk1djhNNlJlYmw0ZnBZM3JaVjV6TWdQcWZUWWFNcFpuajNlcjJRV0tt?= =?utf-8?B?UG9icCtPUEtmWnRxc0JrRDVkVlc1aUFVbXJtbzlYZWx5MmpmY3JCeG03V0Ru?= =?utf-8?B?MXl4NndnMXJWZmE4aWtJOUE0MUtBWnZLcU9aUlVRZVhHbC9FWjBBZW1mVUZX?= =?utf-8?B?czdobzloNmwvL2tDblJwbWhpODRSYTAxa05MVVVnZGZkQURhVEFxRFdPVEVj?= =?utf-8?B?bWZzL09nREk0VjBYOUVob0hyUWxNWEVvOFlwT3kzMFU4TmFUNkxtRzhleDlE?= =?utf-8?B?NmhER2FJelBrcTR6R0lvMjl1Z2QvRkh6aWdTWmR1WjNuS1NURFdrcnlZN0cw?= =?utf-8?B?RXRrWnpFYzd4S3kzTVNCbXZ6TEJ2OHlkak1BUG9nejU2VlpXWTd5YmdmOEVi?= =?utf-8?B?VmVuanpaOGpiZnRGdTI0UnM1dUw4ZFg2andWSXBTWVpQc21mU3N1b2tPWTVL?= =?utf-8?B?MzdmeUoyMVBUekZQbmpOZHBON01XUUJnTDBlajJXc01IUnlPWTZ0R0tkaG9G?= =?utf-8?B?QWk0TXJ2bHdMQ1YrSEFaSjh5WHRuYldvemdBaDRrVUdpdHoyZEtaZWlTSzFi?= =?utf-8?B?dyt4QVBiOUtveGtZTUIyYmZGYTFoa3FqbVpsR1VrMWd1d0l6aklpU0s2WFNX?= =?utf-8?B?djN6T2tVbWpubFZEVkpPUjRtWmw3UTZJYmtYUy9xS2Z5bG0wb2VlWDNhYTQ3?= =?utf-8?B?eEo3dzUxaDd2ZFFyZ0RHcitFazJXd2Y1Rk15dTRFTWw2bFhKRzFoVk1DQ2tI?= =?utf-8?B?bHgvTHR4dm42OFlEQjZUUk4vK0t1ZlpObDNiMzZtTlBmUjJYeHo3TXFQV0ZR?= =?utf-8?Q?VHxNK2h21sKLaQ4gDb6LaKY=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)(376014)(7416014)(1800799024)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eXJnRW5LOGVYcGhyMEc1S3JqWUJTV2EzdnBuNnA5bnVwVjVmVzZ6d2UraHlX?= =?utf-8?B?bEs3ZnlyYUVUaW95emdhL1dxMnpDbkRiMmlzUTFsZ1FvWG5GWlFLaW83YW81?= =?utf-8?B?S202dzFRc0djV3VIaDlGNFlKc0Q1cXY2SkpiUzFBWi8zUzhVcGxWdXdQK3ZI?= =?utf-8?B?SDFRRWZpdTJVN3RSb1JpcnJuMXNuUUIyUE1SbDRyTC91MHJVSVZsOTVBdmtn?= =?utf-8?B?ME82bnExWUQxa0U0cWVabzVjM242bXVldEljMW9Kcis5V1NtakNyd1VZUm1v?= =?utf-8?B?WnIzbURyV3Z1MFRCakIxYjBlUlBwd2YxTnA3bHBMOFB1aVlxSXpQN0tUbVFh?= =?utf-8?B?WW1uODZSU3RDMVZtdWlBbDZvZVlaRmhXdlhsRlorc3RpR08zb1h5ODlaQkxT?= =?utf-8?B?NkxHQ2R1aThwbzYvODd5L0NmalVoanlWU3ZFR043c090NWI0NjFkL0QyU3BK?= =?utf-8?B?MVlaWW55WmgrMk5mZGpoSWJyK3hmVHNkMDhISFp5UnhoTlVoWlJpdzVZNk5H?= =?utf-8?B?UGZTd3JsV0dEbTZhMUxTeGhJS1VIL3ZIekZXdE11YTRpOVVkM0lqK0x6Yi9k?= =?utf-8?B?K3pVanBWOWFGRmtFbGR3amZyZk90bWFqVkpITThLQUlIMDFpbGhvNVBtNENa?= =?utf-8?B?aUt3RWZwb0EzRUhGcjVPbnhHVWNwamgxM21UM1JUekNpUFFSdkVpa3kyWG9E?= =?utf-8?B?dHp1bHJRblFGV0syang0ODZUWmFsNm9aNVpqdFUrNGg0STFoV0VFVDBqQU5l?= =?utf-8?B?UU1hQXFZQ1RCbUljTXE3Sk1PWTRFMWs3b1Z0Yy9yNm5EWTNISjIxNDlxWkdO?= =?utf-8?B?d2RITEtkTmV3SnhORW1MeUdZcGtjdHVNaGNzSVI1c3hwSmhUV3c3UWhEK1Zw?= =?utf-8?B?azUyNFFvbWYwWkNDMEROV0h5MElXbkV5T3hFTktJU3NSNDU2MWVoVmtWMDFi?= =?utf-8?B?MUgyUjY1VVZTaEtYeDdvR1krRkxBQzB6dGNHMnIrU2VNZGlhdkZ6NUgrWnVB?= =?utf-8?B?RnIxaUJUODZRdFpZM3BwNFp0ejNFNW1sNnJQcTBma2YyOWpkbDAwdXNFYUpF?= =?utf-8?B?UDRLZms2dTRyZTJ3YkYrOWM4OEhpZlQxNzRSZGNNaEszbnp0RkhnNFlVUm1S?= =?utf-8?B?Ukh5ZkxTbXBzQ1g0NC9KMTl4cUtZTlFjWE40bFUwY2pjMFo4bWhoNU5YSXFK?= =?utf-8?B?cUpaOUhNS1B3N0ViZXBOUnRDdzVFbm1mOG11alF2WmVVMFI2aFdweFhick92?= =?utf-8?B?cHpNcWNQY1BIak5vMERCSUZySlBNcnlRc1V2cHlvSHdBMDdIN2Z0RmRxeE5Y?= =?utf-8?B?UHM2NlRxQlNQQWVlYXZ6WDhsM1E1NFZnU0JXbzZrR2tiYjY4YU02RkRNWmNQ?= =?utf-8?B?NzFUQThNZHc4MU5abTUzZHExMUt6VFRVUUhyR1Q1QVhqUGtKTnhleEMyZWYx?= =?utf-8?B?TnJRMURIdG5ydGY0RUErc3ZRYXBmVmZndW9tR01BV2I0RDR0QmNDZ0phcmxz?= =?utf-8?B?VGJ6SUhFLzl0RStvNWpYVUtpNUowR0N2M0x2ZFFmWGowcnNtQ3NNUmsxRklC?= =?utf-8?B?RDBxQmhHQWpOVkpMc0NQY3RJbUF1ZmNuWnI5UGpadjJyMCsyWjMyWnNFSmJE?= =?utf-8?B?MXAyS3ErNW93TzBiNERyMWxYajF4L08yWm1hMkw3WXQ5RU1zL3pZOExFZllN?= =?utf-8?B?STF6MFcxZjh4ckoxS0JvRmJSTkxOSjlFTEp0L3NpdHhaejZKSlRMclpHeEVN?= =?utf-8?B?SEQrQVJPMVczMStjdUJFT2RHYVRUV0EwQnU2NXV0OWpMZVV0akJWT09mK2tk?= =?utf-8?B?dFB2bThhbFRub2MvamJybXZSejl2MkhTeCt0aE83Z0dtVy9zS2taeEpjblNL?= =?utf-8?B?ZjgzcDRjeXZ5d0E4LzcrdUVhVzVYOWEwZXdQYkZLWjVIUUdsVGVoa0RDOGJp?= =?utf-8?B?ZEk4WmlMWmlGckN2VXYyaTVoMEZQY2ZKWW1VcTg5T3dKUDBiS21oc0VFMk01?= =?utf-8?B?citXSi9SdEtJbEx3dzdPS2M3Vk5lWVJrZVN1d0gwK3hyV3lxdDZDT3grc2FC?= =?utf-8?B?ZmFHUW5kdTg0VWhNcUtFZWZyREpvdEVaUnpkMS90TEk2Z2I4UUZQSTVTTUhE?= =?utf-8?B?aUhwVzNRV1VpYWMwTDQzdjE2RjF2SFA5VEJtRFhkbG04RU9PUWdGTGtKUXlz?= =?utf-8?B?cEFsdWR3Q2FNdGhDZEpZR0xraU5hODNnT1FTeHlseGFFNnNPMjN4ZUpPbVFk?= =?utf-8?B?WncwT1dQU3pMTjhMTE1OYjl0d1BoTGgrMmh4cUw5Rm82MnVKZmFRdTBKemps?= =?utf-8?B?T2Z3OG5SZC9HUVozMlZQQUFscy9BOXFubjlFSFN4cW5TOENjSEhwYXRSRTda?= =?utf-8?Q?Q/50C4DclLtLagcY=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: PAVPR03MB8946.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1ecba2d6-eced-40a5-25e4-08de5f410db7 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2026 14:16:54.0780 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JUqdjHUKqvLxJh//28Hmmnq3B4tnLfSHo2GIWQWw03jSSDyiKBbGJlkGbamyWSNL/6SS1yN1h2zGzwT7o0bxskTkEicHOaXibZ0s/vNh8XE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB10078 SW5yb2R1Y2luZyBwYXRjaCBzZXJpZXMgd2hpY2ggaW5jbHVkZXMgaW1wbGVtZW50YXRpb24gb2Yg dGhlIFNDSSBTQ01JDQpTTUMgbXVsdGktYWdlbnQgc3VwcG9ydC4NClRoaXMgcGF0Y2ggc2VyaWVz IGZvbGxvd3MgUkZDIHY1IFszXSBzZXJpZXMgd2hpY2ggd2FzIGludHJvZHVjaW5nIGJvdGgNClND TUkgc2luZ2xlLWFnZW50IGFuZCBtdWx0aS1hZ2VudCBzdXBwb3J0LiBBZnRlciB0aGUgZGlzY3Vz c2lvbiBpdCB3YXMNCmRlY2lkZWQgdG8gc3BsaXQgZmVhdHVyZXMgYW5kIHVwc3RyZWFtIHNpbmdl LWFnZW50IHN1cHBvcnQgZmlyc3QuIFRoaXMNCmZlYXR1cmUgaXMgbWVyZ2VkIGZvciBub3cgdG8g djQuMjEtcmMyLg0KSSdtIHN0YXJ0aW5nIHRoaXMgcGF0Y2ggc2VyaWVzIGZyb20gdjYgdG8gc2F2 ZSB0aGUgZGlzY3Vzc2lvbiBoaXN0b3J5DQphbmQgZG9uJ3QgYnJlYWsgY2hhbmdlcyBsb2cuDQoN ClBhdGNoIC0geGVuL2RvbWN0bDogZXh0ZW5kIFhFTl9ET01DVExfYXNzaWduX2RldmljZSB0byBo YW5kbGUgbm90DQpvbmx5IGlvbW11DQotIGFkZCBjaGFpbmdlZCBoYW5kbGluZyBvZiBhc3NpZ25l ZCBEVCBkZXZpY2VzIHRvIHN1cHBvcnQNCmFjY2Vzcy1jb250cm9sbGVyIGZ1bmN0aW9uYWxpdHkg dGhyb3VnaCBTQ0kgZnJhbWV3b3JrLg0KQ2hhbmdlIHdhcyBkb25lIGluIHR3byBwYXJ0czoNCiAt IGNhbGwgdG8gc2NpX2RvX2RvbWN0bCgpIHRvIGRvX2RvbWN0bCgpDQogLSB1cGRhdGUgaW9tbXVf ZG9fZHRfZG9tY3RsKCkgdG8gY2hlY2sgZm9yIGR0X2RldmljZV9pc19wcm90ZWN0ZWQoKQ0KIGFu ZCBub3QgZmFpbCBpZiBEVCBkZXZpY2UgaXMgbm90IHByb3RlY3RlZCBieSBJT01NVQ0KDQpQYXRj aCAtIHhlbi9hcm06IHNjbWk6IGludHJvZHVjZSBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJp dmVyDQotIGFkZCBYZW4tc3BlY2lmaWMgU0NNSSBjb250YWluZXIgY29tcGF0aWJsZSBgeGVuLHNj aWANCiAgdW5kZXIgYC9jaG9zZW4veGVuYDsgWGVuIGJpbmRzIG9ubHkgdG8gdGhlIGBhcm0sc2Nt aS1zbWNgIGluc2lkZSBpdCBhbmQNCiAgaWdub3JlcyBvdGhlciBTQ01JIG5vZGVzIChlLmcuIHVu ZGVyIGAvZmlybXdhcmVgKS4NCi0gYWRkIGBzY21pLXNlY29uZGFyeS1hZ2VudHNgIGFuZCBgI3Nj bWktc2Vjb25kYXJ5LWFnZW50cy1jZWxsc2AgdG8gZGVzY3JpYmUNCiAgZnVuY19pZC9zaG1lbS8o b3B0aW9uYWwgYWdlbnRfaWQpIHR1cGxlcyBmb3Igc2Vjb25kYXJ5IGFnZW50cy4NCi0gZWFjaCBn dWVzdCB1c2luZyBTQ01JIHN1cHBsaWVzIGl0cyBhZ2VudF9pZCAoZG9tMCB2aWENCiAgYHhlbSxk b20wLXNjaS1hZ2VudC1pZD1gIHBhcmFtZXRlciBpbiB4ZW4sc2NpIGNvbXBhdGlibGUgbm9kZSwN CiAgdG9vbHN0YWNrIHZpYSBgYXJtX3NjaSA9ICJ0eXBlPXNjbWlfc21jX211bHRpYWdlbnQsYWdl bnRfaWQ9Li4uImAsIGRvbTBsZXNzDQogIHZpYSBgeGVuLHNjaV90eXBlYCArIGB4ZW4sc2NpLWFn ZW50LWlkYCBpbiBgeGVuLGRvbWFpbmApLg0KLSBmYWN0b3Igb3V0IFNDTUkgZ2VuZXJpYyBkZWZp bml0aW9ucyBhbmQgc2htZW0gY29kZS4NCi0gcGFzc3Rocm91Z2ggY29uZmlndXJhdGlvbiBmb3Ig U0NNSSBndWVzdHMgbWlycm9ycyBvdGhlciBIVyBwYXNzdGhyb3VnaC4NCg0KUGF0Y2ggLSBkb2Nz OiBhcm06IGFkZCBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJpdmVyIGRvY3MNCi0gZG9jdW1l bnQgdGhlIFhlbiBTQ01JIGNvbnRhaW5lciB1bmRlciBgL2Nob3Nlbi94ZW4veGVuX3NjbWlfY29u ZmlnYCBhbmQgdGhlDQogIG1lZGlhdG9y4oCZcyBiaW5kaW5nIHJ1bGVzOyB1cGRhdGUgZXhhbXBs ZXMgYWNjb3JkaW5nbHkuDQoNCkFsbCBYZW4tc3BlY2lmaWMgU0NNSSBjb25maWd1cmF0aW9uIG5v dyBsaXZlcyB1bmRlciBgL2Nob3Nlbi9gDQp0byBrZWVwIGhvc3QgRFQgY2hhbmdlcyBpc29sYXRl ZCB3aGlsZSBsZWF2aW5nIHRoZSBob3N0IGAvZmlybXdhcmUvc2NtaWANCnVudG91Y2hlZCBmb3Ig RG9tMCBjb25zdW1wdGlvbi4NCg0KQ29kZSBjYW4gYmUgZm91bmQgYXQ6DQpodHRwczovL2dpdGh1 Yi5jb20vb2xla3NpaW1vaXNpZWlldi94ZW4vdHJlZS9zY21pX21hX3Vwc3RydjYNCg0KWzFdIFJG QyB2MjoNCmh0dHA6Ly9wYXRjaHdvcmsua2VybmVsLm9yZy9wcm9qZWN0L3hlbi1kZXZlbC9jb3Zl ci9jb3Zlci4xNjQ0MzQxNjM1LmdpdC5vbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbS8NClsyXSBS RkMgdjM6DQpodHRwczovL3BhdGNod29yay5rZXJuZWwub3JnL3Byb2plY3QveGVuLWRldmVsL3Bh dGNoLzIwMjUwMzExMTExNjE4LjE4NTA5MjctMS1ncnlnb3JpaV9zdHJhc2hrb0BlcGFtLmNvbQ0K WzNdIFJGQyB2NToNCmh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC9jb3Zlci4xNzUz MTg0NDg3LmdpdC5vbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbS8NCls0XSBTQ01JIHNpbmdsZS1h Z2VudDoNCmh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC9jb3Zlci4xNzU2OTk1NTk1 LmdpdC5vbGVrc2lpX21vaXNpZWlldkBlcGFtLmNvbS8NClNDTUkgc3BlYzoNCmh0dHBzOi8vZGV2 ZWxvcGVyLmFybS5jb20vZG9jdW1lbnRhdGlvbi9kZW4wMDU2L2UvP2xhbmc9ZW4NCg0KU0NNSSBi aW5kaW5nczoNCmh0dHBzOi8vd2ViLmdpdC5rZXJuZWwub3JnL3B1Yi9zY20vbGludXgva2VybmVs L2dpdC90b3J2YWxkcy9saW51eC5naXQvdHJlZS9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmlu ZGluZ3MvZmlybXdhcmUvYXJtLHNjbWkueWFtbA0KaHR0cHM6Ly93ZWIuZ2l0Lmtlcm5lbC5vcmcv cHViL3NjbS9saW51eC9rZXJuZWwvZ2l0L3RvcnZhbGRzL2xpbnV4LmdpdC90cmVlL0RvY3VtZW50 YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9hY2Nlc3MtY29udHJvbGxlcnMvYWNjZXNzLWNvbnRy b2xsZXJzLnlhbWwNCg0KUmVmZXJlbmNlIEVMMyBGVzoNClJQSTU6IGh0dHBzOi8vZ2l0aHViLmNv bS94ZW4tdHJvb3BzL2FybS10cnVzdGVkLWZpcm13YXJlL2NvbW1pdHMvcnBpNV9kZXYvDQpSZW5l c2FzIHY0aDoNCmh0dHBzOi8vZ2l0aHViLmNvbS9HcnlnaXJpaVMvYXJtLXRydXN0ZWQtZmlybXdh cmUvY29tbWl0cy9yY2FyX2dlbjRfdjIuN192NHgtc2NtaV91cGQvDQoNCmJhc2UtY29tbWl0OiBk YmU2MGYyNDRjIChVcGRhdGUgWGVuIHRvIDQuMjEsIDIwMjUtMDItMjEpDQoNCkNoYW5nZXMgaW4g djk6DQotIHRyZWF0IFNDSSBhcyBhIGdhdGUgZm9yIFhFTl9ET01DVExfKmFzc2lnbl9kZXZpY2U6 IGFib3J0IGJlZm9yZQ0KSU9NTVUgaWYgc2NpX2RvX2RvbWN0bCgpIHJldHVybnMgYW4gZXJyb3Ig b3RoZXIgdGhhbiAtRU5YSU8sIGluc3RlYWQNCm9mIHRyeWluZyB0byBwcm9wYWdhdGUgU0NJIGVy cm9ycyBhZnRlciBhIHN1Y2Nlc3NmdWwgSU9NTVUNCm9wZXJhdGlvbi4gVGhpcyBhdm9pZHMgcGFy dGlhbCBzdWNjZXNzIGFuZCB0aGUgbmVlZCBmb3IgSU9NTVUgcm9sbGJhY2suDQotIHJlbW92ZSBl YXJseSByZXR1cm4gZnJvbSBkb19kb21jdGwoKSBpbiB0aGUgYXNzaWduX2RldmljZQ0KcGF0aCB0 byBrZWVwIFJDVSBoYW5kbGluZyBpbnRhY3QuDQotIGNoYW5nZSBJU19FTkFCTEVEKCopIHRvICNp ZmRlZiBpbiBzY2lfZG9fZG9tY3RsIHF1YXJkDQotIHJld29yZCBjb21taXQgZGVzY3JpcHRpb24g dG8gcmVmZXIgdG8gbWVtY3B5X2Zyb21pbyBhbmQgbWVtY3B5X3RvaW8NCi0gb3JkZXJpbmcgb2Jq LXkgaW4gTWFrZWZpbGUNCi0gcmVuYW1lIEFMTF9MSUJTIHRvIEFSQ0hfTElCUw0KLSBkcm9wIGlv LmggYW5kIG1vdmUgZGVmaW5pdGlvbnMgdG8gdGhlIGNvbW1vbiBoZWFkZXIsIGZpeCBjb21tZW50 cyB0bw0KYmUgYXJjaCBuZXV0cmFsDQotIHVwZGF0ZSBjb21tZW50cyBmb3IgbWVtY3B5X3tmcm9t L3RvfWlvIGltcGxlbWVudGF0aW9uDQotIHNvcnQgYW5kIHJlZmFjdG9yIE1BSU5UQUlORVJTIGVu dGllcw0KLSByZW1vdmUgU3B1cmlvdXMgY2hhbmdlcw0KLSBhZGQgZXh0cmEgY2hlY2sgdG8gYXZv aWQgQVNTRVJUIHdoZW4gY2FsbGluZyB1bm1hcF9jaGFubmVsX21lbW9yeQ0KZnJvbSBhc3NpZ24g ZGV2aWNlIG1ldGhvZA0KLSBzZXQgY29ycmVjdCB0eCBmbGFnIHRvIFNDTUlfQkFTRV9BR0VOVF9Q RVJNSVNTSU9OU19SRVNFVCB3aGVuDQpmcmVlaW5nIHJlc291cmNlcy4gRmxhZyBzaG91bGQgYmUg c2V0IHRvIDEgYWNjb3JkaW5nIHRvIHRoZQ0Kc2VjdGlvbiA0LjIuMi4xMiBbMF0uDQotIGZpeCBk dCBub2RlIGNvcG1hcmluZw0KLSBtb3ZlZCBjaGFubmVsLT5zaG1lbSBjaGVjayBmcm9tIEFTU0VS VCBpbiB1bm1hcF9tZW1vcnlfY2hhbm5lbCB0bw0KImlmIiBzdGF0ZW1lbnQuIFRoaXMgd2lsbCBw cmV2ZW50IGZpcmluZyBBU1NFUlQgaWYNCnVubWFwX2NoYW5uZWxfbWVtb3J5IHdhcyBjYWxsZWQg dHdpY2Ugb24gdGhlIHNhbWUgY2hhbm5lbC4NCg0KQ2hhbmdlcyBpbiB2ODoNCi0gY2hlY2sgZm9y IENPTkZJR19BUk1fU0NJIHRvIGJlIGViYWJsZWQgaW5zdGVhZCBvZiBDT01GSUdfQVJNIGJlZm9y ZQ0KY2FsbGluZyBzY2lfZG9fZG9tY3RsDQotIHJld29yayBzY2lfZG9fZG9tY3RsIGNhbGwgdG8g YXZvaWQgZXh0cmEgY2hlY2tzLCBpbXByb3ZlZCBlcnJvcg0KaGFuZGxpbmcuDQotIGRvIG5vdCBw cm9wYWdhdGUgcmV0MSBpZiBzY2lfZG9fZG9tY3RsIHJldHVybmVkIHBvc2l0aXZlIHJldA0KLSB1 cGRhdGVkIGNvbW1lbnQgaW4gZG9tY3RsLmMgY29kZQ0KLSBzd2l0Y2hlZCB0byBvcmRlcmVkIGFj Y2Vzc29ycyB0byBhZGRyZXNzIHRoZSBvcmRlcmluZyBhbmQgYmFycmllcg0KY29uY2VybnMuDQot IHVwZGF0ZWQgdGhlIGRvY3VtZW50YXRpb24gdG8gbWF0Y2ggdGhlIGltcGxlbWVudGF0aW9uIGFu ZCBleHBsaWNpdGx5DQpzdGF0ZSB0aGUgc3VwcG9ydGVkIGFjY2VzcyBzaXplcyBhbmQgZ3JhbnVs YXJpdHkuDQotIHJlbmFtZSBtZW1jcHlfKiBpbXBsZW1lbnRhdGlvbiBmaWxlcyB0byBtZW1jcHUt KiB0byBmb2xsb3cgbmFtaW5nDQpjb252ZW5zaW9uDQotIGZpeCBpbmRlbnRhdGlvbiB0byBtYXRj aCBYZW4gc3R5bGUNCi0gZml4IGludGVuZGF0aW9uIHRvIG1hdGNoIFhlbiBzdHlsZQ0KLSBtb3Zl IG1lbWNweS17ZnJvbS90b31pbyB0byBtb3JlIGNvbnZlbmllbnQgbGlicmFyeSBwbGFjZQ0KLSB1 cGRhdGUgeGVuX3NjbWkgZnVuY19pZCBpbiBjb21taXQgZGVzY3JpcHRpb24NCi0gdXBkYXRlZCBk b2N1bWVudGF0aW9uIHdpdGggdGhlIG5ldyBEVCBmb3JtYXQNCi0gdXBkYXRlZCBvcHRfZG9tMF9z Y21pX2FnZW50X2lkIHNldHRpbmcgdG8gYXZvaWQgaXQgdG8gYmUgZXF1YWwNClNDTUlfQUdFTlRf SURfSU5WQUxJRC4NCi0gY2hhbmdlZCBTQ01JX0FHRU5UX0lEX0lOVkFMSUQgZnJvbSAweGZmIHRv IFVJTlQ4X01BWCB3aGljaCBtYWtlcw0KY29kZSBtb3JlIGNsZWFyIHNob3dpbmcgdGhhdCBVSU5U OF9NQVggaXMgdGhlYXRlZCBsaWtlIGludmFsaWQNCmFnZW50X2lkIGFuZCBjb3VsZG4ndCBiZSB1 c2VkLiBBbHNvIGV4Y2x1ZGVkIFNDTUlfQUdFTlRfSURfSU5WQUxJRA0KZnJvbSBhY2NlcHRhYmxl IHZhbHVlIHJhbmdlDQotIHJlbW92ZSBvdXRkYXRlZCB4ZW4sY29uZmlnIHByb3BlcnR5IGlnbm9y ZSwgYWRkZWQgeGVuLHNjaSBjb21wYXRpYmxlDQp0byBza2lwX21hdGNoZXMgaW4gaGFuZGxlX25v ZGUNCi0gYWRkIGRvY3VtZW50YXRpb24gZm9yIHByZS1leGlzdGluZyBzY21pLXNtYy1wYXNzdGhy b3VnaCBjb21tYW5kIGxpbmUNCm9wdGlvbiBpbiBhbHBoYWJldGljYWxseSBjb3JyZWN0IGxvY2F0 aW9uIChpbiAncycgc2VjdGlvbikNCi0gYWRkIG5vdGUgdG8gY29tbWl0IGRlc2NyaXB0aW9uIGFi b3V0IGRvY3VtZW50YXRpb24gZm9yIHByZXZpb3VzbHkNCnVuZG9jdW1lbnRlZCBzY21pLXNtYy1w YXNzdGhyb3VnaA0KLSBGaXggU01DIElEcyBpbiBEVCBleGFtcGxlcyAoWGVuIG1hbmFnZW1lbnQg dXNlcyAweDgyMDAwMDAzLCBEb20wIHVzZXMgMHg4MjAwMDAwMikNCi0gQWRkIGV4cGxpY2l0IG5v dGUgZXhwbGFpbmluZyB3aHkgRG9tMCBhbmQgWGVuIGNoYW5uZWxzIGRvIG5vdCBjb25mbGljdA0K LSBEb2N1bWVudCBkb20wbGVzcyBtdWx0aS1hZ2VudCBjb25maWd1cmF0aW9uIGV4YW1wbGUgKHhl bixzY2lfdHlwZSAvIHhlbixzY2ktYWdlbnQtaWQpDQotIEFkZCBzY21pX3hlbiBub2RlIHRvIGFn ZW50LWRpc2NvdmVyeSBleGFtcGxlIHdpdGggI3NjbWktc2Vjb25kYXJ5LWFnZW50cy1jZWxscyA9 IDINCi0gRHJvcCBkb20wPXNjaS1hZ2VudC1pZCBjb21tYW5kIGxpbmUgaGFuZGxpbmc7IERvbTAg U0NNSSBpcyBub3cgZW5hYmxlZCB2aWENCiAgeGVuLGRvbTAtc2NpLWFnZW50LWlkIGluIHRoZSB4 ZW4sc2NpIERUIGNvbnRhaW5lcg0KLSBSZWZyZXNoIGRvY3MgYW5kIGV4YW1wbGVzIHRvIG1lbnRp b24gdGhlIERUIHByb3BlcnR5IGluc3RlYWQgb2YgdGhlIGNtZGxpbmUgb3B0aW9uDQotIHVwZGF0 ZSBkb2N1bWVudGF0aW9uIHRvIG1hdGNoIHRoZSBsYXN0IERUIGZvcm1hdA0KLSBmaXhlZCBSU1Q6 ICIuLi4gY29kZS1ibG9jazo6IGR0cyIgLT4gIi4uIGNvZGUtYmxvY2s6OiBkdHMiDQotIHVwZGF0 ZSBkb2N1bWVudGF0aW9uIHdpdGggZG9tMGxlc3MgY29uZmlndXJhdGlvbiBleGFtcGxlDQotIHVw ZGF0ZSBkb2N1bWVudGF0aW9uIHdpdGggbmV3IHBhcmFtIHhlbixkb20wLXNjaS1hZ2VudC1pZA0K aW5zdGVhZCBvZiB0aGUgY29tbWFuZCBsaW5lIHBhcmFtZXRlcg0KDQpDaGFuZ2VzIGluIHY3Og0K LSB1cGRhdGUgZG9tY3RsIHRvIGJ1aWxkIG9uIGJvdGggQXJtIGFuZCB4ODYgcGxhdGZvcm1zDQot IG1vdmUgcmV0MSBkZWNsYXJhdGlvbiB0byB0aGUgdG9wIG9mIHRoZSBmdW5jdGlvbiBhcyByZXF1 aXJlZCBieSBjb2RlDQpzdHlsZQ0KLSB4ODYgZ3VpZGFuY2U6IHJlbW92ZWQgdGhlIHNwZWN1bGF0 aXZlIG5vdGU7IGhlYWRlciBub3cganVzdCBzYXlzDQogIGVhY2ggYXJjaCBzdXBwbGllcyBpdHMg b3duIGltcGxlbWVudGF0aW9uIG9yIG1hY3JvLg0KLSBuYW1lIHNwYWNpbmc6IGRyb3BwZWQgdGhl IGRvdWJsZS11bmRlcnNjb3JlOyB0aGUgaGVscGVycyBhcmUgbm93DQogIG1lbWNweV9mcm9taW8g LyBtZW1jcHlfdG9pby4gVGhlIGhlYWRlciBhbHNvIGV4cGxpY2l0bHkgYWxsb3dzIGFuDQogIGFy Y2ggdG8gZGVmaW5lIHRoZXNlIGFzIG1hY3JvcyBiZWZvcmUgaW5jbHVkaW5nIGl0Lg0KLSB1cGRh dGVkIGlvLmMgdG8ga2VlcCAzMi1iaXQgdHJhbnNmZXJzIHNhZmUgb24gYXJtMzINCi0gbW92ZWQg dG8gX19yYXdfcmVhZCovX19yYXdfd3JpdGUqIGFjY2Vzc29ycyB0byBhdm9pZCBlbmRpYW5uZXNz IGNvbnZlcnNpb24uDQotIHNwbGl0IHRoZSBoZWxwZXJzIGludG8gc2VwYXJhdGUgY29tcGlsYXRp b24gdW5pdHMNCi0gcmV3b3JrIHNjbWkgbm9kZXMgZm9yIHhlbiB0byBtYXRjaCBvbiBjb21wYXRp YmxlIHN0cmluZyBpbnN0ZWFkIG9mDQp0aGUgZGlyZWN0IHBhdGgNCi0gdXBkYXRlIGRvY3VtZW50 YXRpb24gaW4gc2VjdGlvbiBvZiB0aGUgeGVuX3NjbWkgY29uZmlndXJhdGlvbiB3aGljaA0KaXMg bWF0Y2hlZCBieSAieGVuLHNjaSIgY29tcGF0aWJsZSBpbnN0ZWFkIG9mIHRoZSBkaXJlY3QgcGF0 aC4NCg0KQ2hhbmdlcyBpbiB2NjoNCi0gY2hhbmdlIGlvbW11X2RvX2RvbWN0bCBhbmQgc2NpX2Rv X2RvbWN0bCBjb21tYW5kIG9yZGVyIGFuZA0KY2FsbCBzY2lfZG9fZG9tY3RsIGZpcnN0IHdoaWNo IHdpbGwgcHJvZHVjZSBjbGVhbmVyIGNvZGUgcGF0aC4NCkFsc28gZHJvcHBlZCBjaGFuZ2luZyBy ZXR1cm4gY29kZSB3aGVuIGlvbW11IHdhcyBkaXNhYmxlZCBpbg0KaW9tbXVfZG9fZG9tY3RsLg0K LSBzb3J0ZWQgb2JqcyBpbiBNYWtlZmlsZSBhbGhhYmV0aWNhbGx5DQotIGFkZGVkIG5ld2xpbmUg YXQgdGhlIGVuZCBvZiBNYWtlZmlsZQ0KLSB1c2VkIHVpbnR7Tn1fdCBpbnRlYWQgb2YgdXtOfQ0K LSBhZGQgY29tbWVudCBhYm91dCB3aHkgMzIgYml0IElPIG9wZXJhdGlvbnMgd2VyZSB1c2VkDQot IHVwZGF0ZWQgY2FzdCBvcGVydGFpb25zIHRvIGF2b2lkIGRyb3BwaW5nIGNvbnN0bmVzcyB3aGlj aCBpcyB3cm9uZw0KLSBtb3ZlIGZ1bmN0aW9uIGRlZmluaXRpb25zIHRvIGdlbmVyaWMgcGxhY2Ug c28gdGhlIGNvdWxkIGJlIHJldXNlZCBieQ0Kb3RoZXIgYXJjaA0KLSBhZGQgU1BEWCB0YWcgdG8g aW8uYw0KLSB1cGRhdGVkIHNjbWktc2htZW0gdG8gdXNlIGlvLmggZnJvbSBnZW5lcmljIGxvY2F0 aW9uDQotIHVwZGF0ZSBzY21pX2FnZW50X2lkIHBhcmFtZXRlciB0byBiZSBwcm92aWRlZCBpbnNp ZGUgZG9tMD0gcGFyYW1ldGVyDQpsaXN0IGFuZCBoYXZlIHRoZSBmb2xsb3dpbmcgZm9ybWF0ICJk b20wPXNjaS1hZ2VudC1pZD0wIg0KVGhpcyBjaGFuZ2Ugd2FzIGRvbmUgYXMgYSByZXNwb25zZSBm b3IgU3RlZmFubyBjb21tZW50IGFuZA0KcmVxdWlyZXMgYSBsb3Qgb2YgY29kZSBjaGFuZ2VzLCBi dXQgcHJvZHVjZXMgbXVjaCBjbGVhbmVyIHNvbHV0aW9uDQp0aGF0J3Mgd2h5IEkndmUgYWRkZWQg aXQgdG8gdGhlIGNvZGUuDQotIGZpeCBmaWxlIGNvbW1lbnRzIGFuZCByZXR1cm4gY29kZXMNCi0g Zml4IGxlbmdodCBjaGVja3MgaW4gc2htZW1fe2dldCxwdXR9X21lc3NhZ2UgdG8gdXNlIG9mZnNl dG9mDQotIHJlbW92ZSBsZW4gbWVtYmVyIGZyb20gc2NtaV9jaGFubmVsIHN0cnVjdHVyZSBhcyBp dCBpcyBub3QgdXNlZA0KLSBzZXQgc2NtaS1zZWNvbmRhcnktYWdlbnRzIHByb3BlcnR5IHRvIGJl IG1hbmRhdG9yeSBzaW5jZSBpZiBubw0Kc2Vjb25kYXJ5IGFnZW50cyB3ZXJlIHByb3ZpZGVkIHRo ZW4gdGhlcmUgaXMgbm8gc2VuY2UgdG8gZW5hYmxlIHNjbWkNCndoZW4gbm8gc2Vjb25kYXJ5IGFn ZW50cyBhcmUgcG9wdWxhdGVkIHRvIHRoZSBEb21haW5zDQotIHVwZGF0ZSBkb2N1bWVudGF0aW9u IGluIGJvb3RpbmcudHh0LCBhZGRlZCB4ZW5fc2NtaSBub2RlIHRvIHRoZQ0KZXhhbXBsZQ0KLSBh ZGp1c3QgZC0+YXJjaC5zY2lfZW5hYmxlZCB2YWx1ZSBpbiBzY21pX2RvbWFpbl9kZXN0cm95DQot IGZpeCBsb2NrIG1hbmFnZW1lbnQgaW4gc21jX2NyZWF0ZV9jaGFubmVsIGNhbGwNCi0gYXZvaWQg ZXh0cmEgbWFwX2NoYW5uZWxfbWVtb3J5IGNvbW1hbmQgZm9yIFhlbiBtYW5hZ2VtZW50IGNoYW5u ZWwNCmJlY2F1c2UgY29sbGVjdF9hZ2VudF9pZCBjYWxsIHVubWFwcyBtZW1vcnkgaWYgRE9NSURf WEVOIGlzIG5vdA0Kc2V0LiBTbyBmb3IgWGVuIG1hbmFnZW1lbnQgY2hhbm5lbCB3ZSBjYW4gaW5p dCBkb21haW5faWQgYWQgRE9NSURfWEVODQpiZWZvcmUgY2FsbGluZyBjb2xsZWN0X2FnZW50X2lk IHNvIG1lbW9yeSBzaG91bGRuJ3QgYmUgdW5tYXBwZWQuDQotIHJlbW92ZSBhbGwgSFZDIG1lbnRp b25zIGZyb20gdGhlIG11bHRpLWFnZW50IGRvYw0KLSB1cGRhdGUgc2NpLWFnZW50LWlkIHBhcmFt ZXRlciBkZXNjcmlwdGlvbiBpbiB0aGUgZG9jdW1lbnRhdGlvbg0KLSBhZGQgbWlzc2luZyBTaWdu LW9mDQotIG1pbm9yIGZpeGVzIGFjcm9zcyB0aGUgZG9jdW1lbnQNCg0KQ2hhbmdlcyBpbiB2NToN Ci0gcmV0dXJuIC1FSU5WQUwgaWYgbWVkaWF0b3Igd2l0aG91dCBhc3NpZ25fZHRfZGV2aWNlIHdh cyBwcm92aWRlZA0KLSBpbnZlcnQgcmV0dXJuIGNvZGUgY2hlY2sgZm9yIGlvbW11X2RvX2RvbWN0 bCBpbg0KWEVOX0RPTUNUTF9hc3NpZ25fZGV2aWNlIGRvbWN0bCBwcm9jZXNzaW5nIHRvIG1ha2Ug Y2xlYW5lciBjb2RlDQotIGNoYW5nZSAtRU5PVFNVUFAgZXJyb3IgY29kZSB0byAtRU5YSU8gaW4g c2NpX2RvX2RvbWN0bA0KLSBoYW5kbGUgLUVOWElPIHJldHVybiBjb21kZSBvZiBpb21tdV9kb19k b21jdGwNCi0gbGVhdmUgIWR0X2RldmljZV9pc19wcm90ZWN0ZWQgY2hlY2sgaW4gaW9tbXVfZG9f ZHRfZG9tY3RsIHRvIG1ha2UNCmNvZGUgd29yayB0aGUgc2FtZSB3YXkgaXQncyBkb25lIGluICJo YW5kbGVfZGV2aWNlIiBjYWxsIHdoaWxlDQpjcmVhdGluZyBod2RvbShkb20wKSBhbmQgImhhbmRs ZV9wYXNzdGhyb3VnaF9wcm9wIiBjYWxsIGZvciBkb20wbGVzcw0KY3JlYXRpb24NCi0gZHJvcCBy ZXR1cm4gY2hlY2sgZnJvbSBzY2lfYXNzaWduX2R0X2RldmljZSBjYWxsIGFzIG5vdCBuZWVkZWQN Ci0gZG8gbm90IHJldHVybiBFSU5WQUwgd2hlbiBhZGRpZ25fZHRfZGV2aWNlIGlzIG5vdCBzZXQu IFRoYXQgaXMNCmJlY2F1c2UgdGhpcyBjYWxsYmFjayBpcyBvcHRpb25hbCBhbmQgbm90IGltcGxl bWVudGVkIGluIHNpbmdsZS1hZ2VudCBkcml2ZXINCi0gbW92ZSBtZW1jcHlfdG9pby9mcm9taW8g dG8gdGhlIGdlbmVyaWMgcGxhY2UNCi0gZml4IGRldmljZS10cmVlIGV4YW1wbGUgZm9ybWF0IGlu IGJvb3RpbmcudHh0LCBhZGRlZCAiOyIgYWZ0ZXIgIn0iLg0KLSB1cGRhdGUgZGVmaW5lIGluIHNj bWktcHJvdG8uaA0KLSB1cGRhdGUgZGVmaW5lIGluIHNjbWktc2htZW0uaCBmaWxlDQotIHNjbWlf YXNzaWduX2RldmljZSAtIGRvIG5vdCBpZ25vcmUgLUVPUE5PVFNVUFAgcmV0dXJuDQpjb2RlIG9m IHRoZSBkb19zbWNfeGZlcg0KLSByZW1vdmUgb3ZlcndyaXRpbmcgYWdlbnRfY2hhbm5lbC0+YWdl bnRfaWQgYWZ0ZXINClNDTUlfQkFTRV9ESVNDT1ZFUl9BR0VOVCBjYWxsDQotIGFkZCBtdWx0aS1h Z2VudCBmaWxlcyB0byB0aGUgTUFJTlRBSU5FUlMNCi0gYWRkIFNDTUkgbXVsdGktYWdlbnQgZGVz Y3JpcHRpb24gdG8gdGhlIFNVUFBPUlQubWQNCi0gaGFuZGxlIEFSTV9TTUNDQ19JTlZBTElEX1BB UkFNRVRFUiByZXR1cm4gY29kZSBhbmQgcmV0dXJuIC1FSU5WQUwNCmZvciBzbWMgY2FsbA0KLSB1 cGRhdGVkIGNvbGxlY3RfYWdlbnRzIGZ1bmN0aW9uLiBTZXQgYWdlbnRfaWQgcGFyYW1ldGVyIGFz IG9wdGlvbmFsDQppbiBzY21pLXNlY29uZGFyeS1hZ2VudHMgZGV2aWNlLXRyZWUgcHJvcGVydHkN Ci0gaW50cm9kdWNlICIjc2NtaS1zZWNvbmRhcnktYWdlbnRzLWNlbGxzIiBwYXJhbWV0ZXIgdG8g c2V0IGlmDQphZ2VudF9pZCB3YXMgcHJvdmlkZWQNCi0gcmVhbm1lIHhlbixzY21pLXNlY29uZGFy eS1hZ2VudHMgcHJvcGVydHkgdG8gc2NtaS1zZWNvbmRhcnktYWdlbnRzDQotIG1vdmUgbWVtY3B1 X3RvaW8vZnJvbWlvIGZvciB0aGUgZ2VuZXJpYyBwbGFjZQ0KLSB1cGRhdGUgWGVuIHRvIGdldCBt YW5hZ2VtZW50IGNoYW5uZWwgZnJvbSAvY2hvc2VuL3hlbixjb25maWcgbm9kZQ0KLSBnZXQgaHlw ZXJ2aXNvciBjaGFubm5lbCBmcm9tIG5vZGUgaW5zdGVhZCBvZiB1c2luZyBoYXJkY29kZWQNCi0g dXBkYXRlIGhhbmRsaW5nIHNjbWkgYW5kIHNobWVtIG5vZGVzIGZvciB0aGUgZG9tYWluDQotIFNl dCBtdWx0aS1hZ2VudCBkcml2ZXIgdG8gc3VwcG9ydCBvbmx5IEFybTY0DQotIHJld29yayBtdWx0 aS1hZ2VudCBkcml2ZXIgdG8gbGVhdmUgSG9zdCBEZXZpY2UtdHJlZSB1bm1vZGlmaWVkDQoNCkNo YW5nZXMgaW4gdjQ6DQotIHRvb2xzdGFjayBjb21tZW50cyBmcm9tIEFudGhvbnkgUEVSQVJEDQot IGFkZGVkIGRvbTBsZXNzIHN1cHBvcnQNCi0gYWRkZWQgZG9jIGZvciAieGVuLHNjbWktc2Vjb25k YXJ5LWFnZW50cyINCg0KR3J5Z29yaWkgU3RyYXNoa28gKDIpOg0KICB4ZW4vZG9tY3RsOiBjaGFp biBTQ0kgaGFuZGxpbmcgYmVmb3JlIElPTU1VIGluIGFzc2lnbl9kZXZpY2UgZG9tY3RsDQogIGRv Y3M6IGFybTogYWRkIFNDSSBTQ01JIFNNQyBtdWx0aS1hZ2VudCBkcml2ZXIgZG9jcw0KDQpPbGVr c2lpIE1vaXNpZWlldiAoMyk6DQogIHhlbjogYXJtOiBzbWNjYzogYWRkIElOVkFMSURfUEFSQU1F VEVSIGVycm9yIGNvZGUNCiAgbGliL2FybTogQWRkIEkvTyBtZW1vcnkgY29weSBoZWxwZXJzDQog IHhlbi9hcm06IHNjbWk6IGludHJvZHVjZSBTQ0kgU0NNSSBTTUMgbXVsdGktYWdlbnQgZHJpdmVy DQoNCiBNQUlOVEFJTkVSUyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDEg Kw0KIFNVUFBPUlQubWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAxMSAr DQogLi4uL2FybS9maXJtd2FyZS9hcm0tc2NtaS5yc3QgICAgICAgICAgICAgICAgIHwgNDIwICsr KysrKysrKw0KIGRvY3MvbWFuL3hsLmNmZy41LnBvZC5pbiAgICAgICAgICAgICAgICAgICAgICB8 ICAxMyArDQogZG9jcy9taXNjL2FybS9kZXZpY2UtdHJlZS9ib290aW5nLnR4dCAgICAgICAgIHwg MTk2ICsrKysrDQogdG9vbHMvbGlicy9saWdodC9saWJ4bF9hcm0uYyAgICAgICAgICAgICAgICAg IHwgICA0ICsNCiB0b29scy9saWJzL2xpZ2h0L2xpYnhsX3R5cGVzLmlkbCAgICAgICAgICAgICAg fCAgIDQgKy0NCiB0b29scy94bC94bF9wYXJzZS5jICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgMTIgKw0KIHhlbi9hcmNoL2FybS9NYWtlZmlsZSAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgMSArDQogeGVuL2FyY2gvYXJtL2FyY2gubWsgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAxICsNCiB4ZW4vYXJjaC9hcm0vZG9tMGxlc3MtYnVpbGQuYyAgICAgICAgICAgICAgICAgfCAg MTEgKw0KIHhlbi9hcmNoL2FybS9kb21haW5fYnVpbGQuYyAgICAgICAgICAgICAgICAgICB8ICAz OSArDQogeGVuL2FyY2gvYXJtL2Zpcm13YXJlL0tjb25maWcgICAgICAgICAgICAgICAgIHwgIDEy ICsNCiB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvTWFrZWZpbGUgICAgICAgICAgICAgICAgfCAgIDEg Kw0KIHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY2kuYyAgICAgICAgICAgICAgICAgICB8ICAzNiAr DQogeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktcHJvdG8uaCAgICAgICAgICAgIHwgMTY0ICsr KysNCiB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zaG1lbS5jICAgICAgICAgICAgfCAxMTUg KysrDQogeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc2htZW0uaCAgICAgICAgICAgIHwgIDQ1 ICsNCiB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1zbWMtbXVsdGlhZ2VudC5jICAgfCA4MTgg KysrKysrKysrKysrKysrKysrDQogeGVuL2FyY2gvYXJtL2luY2x1ZGUvYXNtL2Zpcm13YXJlL3Nj aS5oICAgICAgIHwgIDE0ICsNCiB4ZW4vYXJjaC9hcm0vaW5jbHVkZS9hc20vc21jY2MuaCAgICAg ICAgICAgICAgfCAgIDEgKw0KIHhlbi9hcmNoL2FybS9saWIvTWFrZWZpbGUgICAgICAgICAgICAg ICAgICAgICB8ICAgMiArDQogeGVuL2FyY2gvYXJtL2xpYi9tZW1jcHktZnJvbWlvLmMgICAgICAg ICAgICAgIHwgIDU2ICsrDQogeGVuL2FyY2gvYXJtL2xpYi9tZW1jcHktdG9pby5jICAgICAgICAg ICAgICAgIHwgIDU2ICsrDQogeGVuL2NvbW1vbi9kb21jdGwuYyAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgIDE1ICsNCiB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9kZXZpY2VfdHJlZS5jICAg ICAgICAgfCAgIDYgKw0KIHhlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLWFybS5oICAgICAgICAgICAg ICAgICB8ICAgMyArDQogeGVuL2luY2x1ZGUveGVuL2lvLmggICAgICAgICAgICAgICAgICAgICAg ICAgIHwgIDEwICsNCiAyOCBmaWxlcyBjaGFuZ2VkLCAyMDY2IGluc2VydGlvbnMoKyksIDEgZGVs ZXRpb24oLSkNCiBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWkt cHJvdG8uaA0KIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vYXJjaC9hcm0vZmlybXdhcmUvc2NtaS1z aG1lbS5jDQogY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9hcmNoL2FybS9maXJtd2FyZS9zY21pLXNo bWVtLmgNCiBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvYXJtL2Zpcm13YXJlL3NjbWktc21j LW11bHRpYWdlbnQuYw0KIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vYXJjaC9hcm0vbGliL01ha2Vm aWxlDQogY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9hcmNoL2FybS9saWIvbWVtY3B5LWZyb21pby5j DQogY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9hcmNoL2FybS9saWIvbWVtY3B5LXRvaW8uYw0KDQot LSANCjIuMzQuMQ0K From xen-devel-bounces@lists.xenproject.org Thu Jan 29 14:17:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 14:17:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216562.1526511 (Exim 4.92) (envelope-from ) id 1vlSpk-0001RI-2B; Thu, 29 Jan 2026 14:17:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216562.1526511; Thu, 29 Jan 2026 14:17:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlSpj-0001R9-TY; Thu, 29 Jan 2026 14:17:19 +0000 Received: by outflank-mailman (input) for mailman id 1216562; Thu, 29 Jan 2026 14:17: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 1vlSpi-0000f7-N6 for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 14:17: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 37103eeb-fd1d-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 15:17:16 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by VI1PR03MB10078.eurprd03.prod.outlook.com (2603:10a6:800:1ca::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Thu, 29 Jan 2026 14:16:56 +0000 Received: from PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.9564.008; Thu, 29 Jan 2026 14:16:56 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 37103eeb-fd1d-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JLW3hEndAjgRR4mVZBIoBes0v++OpWiPizmO2itTKVlAJJp3nhunok5A8pHoXoOWStz/WEbcHrgNXdnBskJzAhs8MoLkT8BdJedXIOuYMJrady8rK+UAwE6jx3GRhRdGdmvjBd+FVfBR7GjMWgfYVNEjhPwFd7zsW4rMCbO+vyo8I1+fpaLBrmLgbk2Y/Tzuqm5onEoTFni87MXXmrzOWLckQAm1InxkZiZZp0NflVv7XxYfqUOBJ/k3nEUmdEiYl4rcAsUdYftOlDTTeIpKpO9T7+LnrDlV4i8lEMPmtSJBUAxMwLO4kN0xkAbZUYFnJL39N1oXBfEFNubuQYlGeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ocv5dp9bHKEMUmwI+O1ki9LavAsE9xhcL6nc5aUA6FQ=; b=gSIKA0qho2XYg4LFvJpAU/wob42tF94JZqm++wNoAJZrEncjcFNPs2ROA7buy+2SlpEegDXwvQQlcw7X8n0AIRfCGSmP3vpMr8TR4MHcAIq/xVWgCDvyWlorfVax7uc9bInpelXGInnMImsCKPl0J1rWA7jLaPCIwBW1ymNVPMTnt84IFiV2yrPAkqMDv4CYUZwj3cmXp6lapN0wCfOaIwAicVd1M4+7YNtzXGRDrr09/bsQQgUASkH1O0I9LiEQ3gpG/F/j2cYfbmRiQhp7fCeenfYxJI3WHJF3Bd9r8/HFeMY/bBOL/3v1VdiaVFpMjXh3+vsy51/9EVV3xqx8qQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ocv5dp9bHKEMUmwI+O1ki9LavAsE9xhcL6nc5aUA6FQ=; b=VkMBxUT+U5B8vLgzFkjwkRsvj5ROKLC0XrqFaQrzwtI0IDfNDEifY99l8wUz4tOGFD8SY+U4de1c0YgfJkKXn/6BNHF4RVEx4fx87hI2Rlf+i0S1xa3Uo3oxL5yBtYekG7ZRdA91BDjWRvDW3hE7Bzmg24bqea1vzNjcvywzJOgYZp1oI1edm59Ev3adD2ECo4I9UfeLoX6lc14BKge7WxrC13XFlGI/jaWk9tAwa6dXxwSh90ftBMf6CiPZu+fP/JQD0QAAkAIMenu+YlEVnyhgCBqE9PNPqmyL+c3kJX5AWcnXOSMZFxMQ708htlm5U5+4+TNoshUwRU5G4p57Ow== 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 5/5] docs: arm: add SCI SCMI SMC multi-agent driver docs Thread-Topic: [PATCH v9 5/5] docs: arm: add SCI SCMI SMC multi-agent driver docs Thread-Index: AQHckSnsbahe07agPEOZ4RxpOySFFg== Date: Thu, 29 Jan 2026 14:16:55 +0000 Message-ID: <9a95d21c212013b8e76f20a0248e94108512c94f.1769696107.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_|VI1PR03MB10078:EE_ x-ms-office365-filtering-correlation-id: 818f935b-38e4-43df-4689-08de5f410ed6 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?JbUxKZwSdrnFkpQN1HIVAM3ll1/tPYzKvzS3A3gpuoix6upvZa32/PISGw?= =?iso-8859-1?Q?UtdnNNBBp41bJb/yC6O9SVK0mx2JGZj6uIYQCTWuyK9+sxYizcrqP+owWz?= =?iso-8859-1?Q?kBoNZwFjidz/veZIna/y4k7i3U0JByAtPqD4UqNL7cCE4l4B/PSwArYu8e?= =?iso-8859-1?Q?YS/fa5h7RDC3WUrpX05755+Am9HMDGL8N9a2JUkqzHR/uGH037+0Z9RfzV?= =?iso-8859-1?Q?cJohOOx51u7jWnqmTkuuLqsCF0iM9sM1vPdVKonlym21+4iJutV4GhT8sv?= =?iso-8859-1?Q?oWsfxlE1k24n7RrfBdBzq3DONrKcXZz4BfulPH9sM1PxobO0svfr+ZxlfG?= =?iso-8859-1?Q?oDWbh8MzzGAm82JtofzWnb0h7M/E6cGOkYt+hlatKYIKKRG7/qtramjmCQ?= =?iso-8859-1?Q?/FHqO2vq9AwcVKMHNCnjtZsCa10IUAXTOVQdCq2fKIOJoR0NGKh03vhkCY?= =?iso-8859-1?Q?iGhbQe/1Gr6OQ5nZXhBS6cu+InuYIilh5rkYIUAlcSWwCgxMzSUrFipe70?= =?iso-8859-1?Q?sDOt9dEWpWoZ3jP++GXo4tsI539i4tbtMvae8xG9aMxoZAFhyFxm5+eiB9?= =?iso-8859-1?Q?LFO6rCyNdR1mkGFQ1fquMO9sOWUPSktRnkViKaVvtUYRjHenKC7KPcGBTM?= =?iso-8859-1?Q?XzM2+XJTlcclnc2XsocH8pzZk1f3YxF3wOfc/GQUv5tGrq0KlIXWxl6wCe?= =?iso-8859-1?Q?y9uOP4mDOtdA848JjFe3CcRkfnN6v2BT+c8j9DogRDqoBT2stuXZDG2pLT?= =?iso-8859-1?Q?0ipbN1n0/7WHsPMzw0UCg1dnzM34NY2l60P6UAuBB2SEVEs+Nl8PiWWBPA?= =?iso-8859-1?Q?Nk0lAls8PkorEVHMstA2lrKxdb5NK3Ln0AqVcsMAPa32TI9vwWgVltfiGa?= =?iso-8859-1?Q?Xg/KDeqzDzuFVHDY1LMnQaUbW1IMJ8jIwt2vLWD0lqGaWgj0O+gHIDHNrb?= =?iso-8859-1?Q?GxTg6GX/VKeWgI7jXGTlBwwOaRCM7DzH1DWoDNJlkM3eeGaoptQtfYS457?= =?iso-8859-1?Q?Tk3Lc5qhAwpJW1xiiPbWmLvlSFdYc3Ahy/J8ejuL4rU5dHohrKjYzGOqpZ?= =?iso-8859-1?Q?R5iT3F8alsh8o23rC9zIS/lFz2j11C03s3EZJZiYfHCLGTgUQ70AXLc1Lb?= =?iso-8859-1?Q?WgpfNNNEmmZOvx1tVVDsNVNs+JB+F0HSr9dVSuKy4rJVKFWRjfSTiIL0ps?= =?iso-8859-1?Q?zCAEXt/dt3so+BPR1Aqslr0KgeyJfau2HyQCLObCGAzM74W+OkcL+9PB5b?= =?iso-8859-1?Q?Qnzk209Ep1VZvRXX35nTlWiW2FwWH7yQEucHUeB/D14gyD7klDmridGS/Z?= =?iso-8859-1?Q?MMULbLXJeZ9zHUErtPq/4s0cg+iNe4klcj7pp5805fcaQ4PFFeTaWsJk86?= =?iso-8859-1?Q?K7E6qDXOVbHdYId7KAodGT2bKIlce90pwPfEzC95hjwwykXLilcIRx/7aq?= =?iso-8859-1?Q?GB7P7kghfpQ1GUDnAutWr3zYsqNr0waO0h5td7jhn6RDpQ3i4D4TdRQgNx?= =?iso-8859-1?Q?fnk4C2zQL8NU4FtmBdIk4gypMlI+zwkyWbOerqnH0XNfrG6fq/iP61KHZn?= =?iso-8859-1?Q?ofSI41lh+rh2oeolS+WHdpfVywlHSVWWDTrG6fOcwFPYC+8zl/eoshGCa5?= =?iso-8859-1?Q?71bRZ6LaoAX1+M7L7cRpVOsYiNh44NhvHMeBQlxM21IhEkFdexLIO+0h0y?= =?iso-8859-1?Q?J/7Rn/afOpFKsAQgWf4=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)(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?T5dXy/wb8SLLFoD9HFvbl5UE7VjZQETCnKR5MyxintoKzynRgSzdWMcmkI?= =?iso-8859-1?Q?VTGiTpptzMI1LOyBJpx7W1R3PXBIqIR33TbrSLPMvmjN5i5+laqr73YaYe?= =?iso-8859-1?Q?qFfetcYSgriJ7mg06R0qi2VlRTYR8lT5pijRXn+EDa6aS9MSYUWLctWYYf?= =?iso-8859-1?Q?Jczj0LQ2hZcdlZ51wu5/GW+j+Rk9Kn90ToQOZkvYRfwsCGx0giTY1646Dk?= =?iso-8859-1?Q?FgoIyWxmdqq0bYuJWSjBGfvkWu4Ya/jXqNNwynZ6Ec2rMTghqnpTyMGeb6?= =?iso-8859-1?Q?4r1RN0v9WEEgkRFcaqVzkif4Ij5phmQ/hzd5ioGv/pgtMsc5r493vLxoge?= =?iso-8859-1?Q?koagt6o0jFqlrj/3o6MFnyhFprqK6RamIMlAJvFKGkSWT+apdd9VV5vgYf?= =?iso-8859-1?Q?2TXtC4DiAmeHC+lOG9wPjgys9ZnlLFW+57hYLESSF2FWGgobvQtFt005Xs?= =?iso-8859-1?Q?aGOs2/PB4st9mQmg7SsQ5pgyebdx67gakXFWU1i8OepmDrxHmB0755fJ3v?= =?iso-8859-1?Q?o/6wqWpRJx9zx9czajBMGcsFdkcvCg8TCDvVGtfjLp9CqaWPdDw7v/emKO?= =?iso-8859-1?Q?dGMUqA5jyEln+xf4O5MD3LRTtn7ns+B98Sil92L7EKPL82CFENDZyoF96z?= =?iso-8859-1?Q?VxnqOFg6DY5402RALSF0eeEb1CbJu+wHtbBdpEAqGIxOD6ajS4RbFUegje?= =?iso-8859-1?Q?QaiKfzpin4V6c96iG7UT6gB/nN46yf69uQ1Jsf48ThfrVrMdsNFcJ7zLzK?= =?iso-8859-1?Q?/TZ+fn3Y+rai50sKbMVm8DX6DSCgfB5wr+RQCqIZrSPBebY5otcfwf54vo?= =?iso-8859-1?Q?nRqCmP7RCYi4wMoQZK+XrE2t0cdE/ms2A6LVFc/QrQLlhs5OhomFLTgpaz?= =?iso-8859-1?Q?57779uZzZon9/WR7i3yFG+WtmjnfmCxvG9ZtG2otKTXNGeGtkxEdtwNlV7?= =?iso-8859-1?Q?TOxm9uxdFEJtcCYkt1L/aIemzthuh1A935Bu4PM/8sJD0lO6HoQnDVYhq0?= =?iso-8859-1?Q?XrlFXZqPy/a7mjc/HzEbBDiMpMbV6baBnhXPvKJcG9eHSLotD5I6qnC+2f?= =?iso-8859-1?Q?gIMdllULw7h1odbntcF/2W2WYXNnLHmKgYEY3J0G9Uo0T4QALjBx7R/a+O?= =?iso-8859-1?Q?5LLMI1V+X1cV/UgM+N8DNZIJJL1+GCCg5qwmWEFV2c20wovMLS0fOLy3vH?= =?iso-8859-1?Q?qYBETwHi8Wuc6KbxENAxwDzfD7xp0yc57I/+DP6Z4aMAvPg+Bjh5q8/iM9?= =?iso-8859-1?Q?q9EDQI4D+6p/0CKIX5IUKLrXa4ZcnKXcetK5CkXclGCrD/rUJiGJR40Pn7?= =?iso-8859-1?Q?hXcIzKienl5HuzDkVbxYVGQxnNp8iMPb2FvE7hx3zECgUjsbTwLQRlZEKQ?= =?iso-8859-1?Q?pEVLXj5VkzPjPulbZawBunpRCGIjkq4GfSIowfcV1K5jXnDHpItx8asnpb?= =?iso-8859-1?Q?sdFNWY3SUx674pAz9WjqCALox9YEFmMQMCRfwoJy3kWNwlshLeoryjHgCT?= =?iso-8859-1?Q?ps9lbm10e1I6Qbk9Bfg7aFUSnd+uJwaEbmnC7SyFLIBYAuV7vEyZM0Cgph?= =?iso-8859-1?Q?dJ7j3YMjtkOzv4nMmQXkPL5Ipkf/cA605EN0jIaAVhG2x/kgYHfNdi2AHP?= =?iso-8859-1?Q?WE0KUokwfHvWZD9Wy0xItHAwb23TAk4705/W7z4J5FyvDsYXW50QhidcTk?= =?iso-8859-1?Q?yuPcCPdcNvSFgVv1x8fMLfEocZQT3M4y6eJtB+ya1NmOT2TGH4z3IJlCcY?= =?iso-8859-1?Q?jVnyITx1gsgAzDZ4jwRjoAyUr8UNYrgZ6rWaXX2pFgZ9oGodcPI8WdTgyL?= =?iso-8859-1?Q?GXd7kzLhvJM2D6ss00Lvk5IxpYPsQFY=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: 818f935b-38e4-43df-4689-08de5f410ed6 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2026 14:16:55.9029 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7GEQILK5o/SS7YWSwk1X/LcMlAvfiSyiSn5j9DYXBpQwyMJOFPlKP5zSq0zIkxRol6kF9Ay11F3b81uAyf6I2EwxpC0zfZFi/JnsVtG+WS0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB10078 From: Grygorii Strashko Add SCI SCMI SMC multi-agent driver documentation. It includes a detailed description of the SCMI multi-agent driver. This document explains the driver's functionality, configuration, and the compilation process. The Xen SCMI multi-agent driver is designed to provide SCMI access to system resources from different domains. Signed-off-by: Grygorii Strashko Signed-off-by: Oleksii Moisieiev --- (no changes since v8) Changes in v8: - update documentation to match the last DT format - fixed RST: "... code-block:: dts" -> ".. code-block:: dts" - update documentation with dom0less configuration example - update documentation with new param xen,dom0-sci-agent-id instead of the command line parameter Changes in v7: - update documentation in section of the xen_scmi configuration which is matched by "xen,sci" compatible instead of the direct path. Changes in v6: - remove all HVC mentions from the multi-agent doc - update sci-agent-id parameter description in the documentation - add missing Sign-of - minor fixes across the document Changes in v5: - rework multi-agent driver to leave Host Device-tree unmodified .../arm/firmware/arm-scmi.rst | 420 ++++++++++++++++++ 1 file changed, 420 insertions(+) diff --git a/docs/hypervisor-guide/arm/firmware/arm-scmi.rst b/docs/hypervi= sor-guide/arm/firmware/arm-scmi.rst index d9698f4e4b..2497a870f3 100644 --- a/docs/hypervisor-guide/arm/firmware/arm-scmi.rst +++ b/docs/hypervisor-guide/arm/firmware/arm-scmi.rst @@ -36,6 +36,8 @@ The below sections describe SCMI support options availabl= e for Xen. =20 | [1] `Arm SCMI `= _ | [2] `System Control and Management Interface (SCMI) bindings `_ +| [3] `Generic Domain Access Controllers bindings `_ + =20 Simple SCMI over SMC calls forwarding driver (EL3) ------------------------------------------------------ @@ -189,3 +191,421 @@ except explicitly enabling SCMI with "arm_sci" xl.cfg= option. -> xen,reg =3D <0x0 0x47ff0000 0x0 0x1000 0x0 0x22001000>; -> xen,force-assign-without-iommu; }; + +SCMI SMC multi-agent driver (EL3) +------------------------------------- + +The SCMI SMC multi-agent driver enables support for ARM EL3 Trusted Firmwa= re-A (TF-A) which +provides SCMI interface with multi-agent support, as shown below. + +:: + + +-----------------------------------------+ + | | + | EL3 TF-A SCMI | + +-------+--+-------+--+-------+--+-------++ + |shmem1 | |shmem0 | |shmem2 | |shmemX | + +-----+-+ +---+---+ +--+----+ +---+---+ + smc-id1 | | | | + agent1 | | | | + +-----v--------+---------+-----------+----+ + | | | | | + | | | | | + +--------------+---------+-----------+----+ + smc-id0 | smc-id2| smc-idX| + agent0 | agent2 | agentX | + | | | + +----v---+ +--v-----+ +--v-----+ + | | | | | | + | Dom0 | | Dom1 | | DomX | + | | | | | | + | | | | | | + +--------+ +--------+ +--------+ + +The EL3 SCMI multi-agent firmware is expected to provide SCMI SMC shared-m= emory transport +for every Agent in the system. The SCMI Agent transport channel defined by= pair: + +- smc-id: SMC function id used for Doorbell +- shmem: shared memory for messages transfer, **Xen page aligned**. + Shared memory is mapped with the following flags: MT_DEVICE_nGnRE and _P= AGE_DEVICE, indicating that this + memory is mapped as device memory. + +The following SCMI Agents are expected to be defined by SCMI FW to enable = SCMI multi-agent functionality +under Xen: + +- Xen management agent: trusted agents that accesses to the Base Protocol = commands to configure + agent specific permissions +- OSPM VM agents: non-trusted agent, one for each Guest domain which is a= llowed direct HW access. + At least one OSPM VM agent has to be provided by FW if HW is handled onl= y by Dom0 or Driver Domain. + +The EL3 SCMI FW is expected to implement following Base protocol messages: + +- BASE_DISCOVER_AGENT (optional if agent_id was provided) +- BASE_RESET_AGENT_CONFIGURATION (optional) +- BASE_SET_DEVICE_PERMISSIONS (optional) + +The number of supported SCMI agents and their transport specifications are= SCMI FW implementation +specific. + +Compiling with multi-agent support +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To build with the SCMI SMC multi-agent driver support, enable Kconfig opti= on: + +:: + + CONFIG_SCMI_SMC_MA + + +Driver functionality +^^^^^^^^^^^^^^^^^^^^ + +The SCI SCMI SMC multi-agent driver implements following functionality: + +- The driver is initialized from the Xen SCMI container ``xen_scmi_config`= ` + under ``/chosen/xen`` (for example ``/chosen/xen/xen_scmi_config/scmi``)= . + Only one SCMI interface is supported. The SCMI configuration must live u= nder + the Xen SCMI container ``xen,sci`` beneath ``/chosen``. + The Xen SCMI mediator will bind only to the "arm,scmi-smc" node that is = a child of + this "xen,sci" container; any other "arm,scmi-smc" nodes (for example un= der + "/firmware") are ignored to avoid stealing the host's SCMI OSPM instance= . + +.. code-block:: dts + + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; <--- Xen management agent smc-id + #address-cells =3D < 1>; + #size-cells =3D < 0>; + #access-controller-cells =3D < 1>; + shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem + }; + +.. note:: + This layout keeps the Host DT unchanged for Dom0 and baremetal Linux by + using func_id 0x82000002 / shmem 0x47ff0000 for Dom0, while Xen uses a + separate privileged channel func_id 0x82000003 / shmem 0x47ff1000. EL3 + firmware enforces permissions per agent_id, so there is no conflict bet= ween + Dom0 and Xen channels. + +- The driver obtains Xen specific SCMI Agent's configuration from the Host= DT, probes Agents and + builds SCMI Agents list. The Agents configuration is taken from "scmi-se= condary-agents" + property where first item is "arm,smc-id", second - "arm,scmi-shmem" pha= ndle and third is + optional "agent_id": + +.. code-block:: dts + + chosen { + ranges; <--- set default ranges so address can be translated when pa= rsing scmi_shm node + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; <--- set default ranges so address can be translated whe= n parsing scmi_shm node + scmi-secondary-agents =3D < + 0x82000002 &scmi_shm_0 0 + 0x82000004 &scmi_shm_2 2 + 0x82000005 &scmi_shm_3 3 + 0x82000006 &scmi_shm_4 4>; + #scmi-secondary-agents-cells =3D <3>; <--- optional, default 3 + xen,dom0-sci-agent-id =3D <0>; /* Dom0 agent ID */ + + scmi_shm_0 : sram@47ff0000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff0000 0x0 0x1000>; + }; + + scmi_shm_2: sram@47ff2000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff2000 0x0 0x1000>; + }; + scmi_shm_3: sram@47ff3000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff3000 0x0 0x1000>; + }; + scmi_shm_4: sram@47ff4000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff4000 0x0 0x1000>; + }; + + // Xen SCMI management channel + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; <--- Xen management agent smc-i= d + #address-cells =3D < 1>; + #size-cells =3D < 0>; + #access-controller-cells =3D < 1>; + shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem + }; + }; + }; + }; + + /{ + // Host SCMI OSPM channel - provided to the Dom0 as is if SCMI ena= bled for it + scmi_shm: sram@47ff0000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff0000 0x0 0x1000>; + }; + + firmware { + scmi: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000002>; <--- Host OSPM agent smc-id + #address-cells =3D < 1>; + #size-cells =3D < 0>; + shmem =3D <&scmi_shm>; <--- Host OSPM agent shmem + + protocol@X{ + }; + }; + }; + }; + + This approach allows defining multiple SCMI Agents by adding Xen-specifi= c properties under + the ``/chosen`` node to the Host Device Tree, leaving the main part unch= anged. The Host DT + SCMI channel will be passed to Dom0. + + The Xen management agent is described as a ``scmi_xen`` node under the `= `xen,sci`` compatible node, + which is used by Xen to control other SCMI Agents in the system. + + All secondary agents' configurations are provided in the ``scmi-secondar= y-agents`` property with + an optional ``agent_id`` field. + + The ``agent_id`` from the ``scmi-secondary-agents`` property is used to = identify the agent in the + system and can be omitted by setting ``#scmi-secondary-agents-cells =3D = <2>``, so the Secondary + Agents configuration will look like this: + +.. code-block:: dts + + chosen { + xen { + xen_scmi_config { + compatible =3D "xen,sci"; + scmi-secondary-agents =3D < + 0x82000002 &scmi_shm_0 + 0x82000004 &scmi_shm_2 + 0x82000005 &scmi_shm_3 + 0x82000006 &scmi_shm_4>; + #scmi-secondary-agents-cells =3D <2>; + }; + }; + } + + In this case, Xen will use the ``SCMI_BASE_DISCOVER_AGENT`` call to disc= over the ``agent_id`` + for each secondary agent. Providing the ``agent_id`` in the ``scmi-secon= dary-agents`` property + allows skipping the discovery call, which is useful when the secondary a= gent's shared memory is + not accessible by Xen or when boot time is important because it allows s= kipping the agent + discovery procedure. + +.. note:: + + Note that Xen is the only one entry in the system which need to know a= bout SCMI multi-agent support. + +- The driver implements the SCI subsystem interface required for configuri= ng and enabling SCMI + functionality for Dom0/hwdom and Guest domains. To enable SCMI functiona= lity for guest domain + it has to be configured with unique supported SCMI Agent_id and use corr= esponding SCMI SMC + shared-memory transport ``[smc-id, shmem]`` defined for this SCMI Agent_= id. + +- Once Xen domain is configured it can communicate with EL3 SCMI FW: + + - zero-copy, the guest domain puts/gets SCMI message in/from shmem; + - the guest triggers SMC exception with agent "smc-id" (doorbell); + - the Xen driver catches exception, do checks and synchronously forwards= it to EL3 FW. + +- the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen manag= ement agent channel on + domain destroy event. This allows to reset resources used by domain and = so implement use-case + like domain reboot. + + +Configure SCMI for Dom0 +^^^^^^^^^^^^^^^^^^^^^^^ +Set the Dom0 SCMI agent ID in the device tree using the Xen SCMI container= under ``/chosen``. +Add ``xen,dom0-sci-agent-id`` to the ``xen,sci`` node. If the property is = absent, SCMI stays +disabled for Dom0 and the SCMI nodes are removed from Dom0 DT. + +.. code-block:: dts + + chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + xen,dom0-sci-agent-id =3D <0>; /* Dom0 agent ID */ + /* scmi-secondary-agents and scmi_xen as shown above */ + }; + }; + }; + +Xen utilizes the Host DT ``/firmware/scmi`` node to configure the Dom0 SCM= I agent, leaving the +rest of the Host DT unchanged except for the Xen-specific properties under= ``/chosen``. If the +``/firmware/scmi`` node is missing or disabled, the Dom0 SCMI agent will n= ot be configured. + +.. note:: + + The ``xen,dom0-sci-agent-id`` value must match the ``func_id`` and ``shm= em`` pairing provided by + the EL3 firmware for Dom0 (for example in the ``/firmware/scmi`` node). + +Configure SCMI for for guest domain with toolstack +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* In domain's xl.cfg file add **"arm_sci"** option as below + +:: + + arm_sci =3D "type=3Dscmi_smc_multiagent,agent_id=3D2" + +* In domain's xl.cfg file enable access to the "arm,scmi-shmem" which shou= ld correspond + assigned "agent_id" for the domain, for example: + +:: + + iomem =3D [ + "47ff2,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. + The "arm,smc-id" should correspond assigned agent_id for the domain: + +.. 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"; + arm,smc-id =3D <0x82000004>; <--- smc-id for agent_id= =3D2 + shmem =3D <&scmi_shm_0>; + ... + } + } + } + +**Device specific access control** + +The XEN SCMI SMC multi-agent driver performs "access-controller" provider = function in case +EL3 SCMI FW implements SCMI "4.2.1.1 Device specific access control" and p= rovides the +BASE_SET_DEVICE_PERMISSIONS command to configure the devices that an agent= s have access to. +The Host DT SCMI node should have "#access-controller-cells=3D<1>" propert= y and DT devices should +be bound to the SCMI node using Access Controllers bindings [3]. + +For example: + +.. code-block:: dts + + &i2c1 { + access-controllers =3D <&scmi 0>; + }; + +Use domain's xl.cfg file **"dtdev"** property to assign SCMI devices from = toolstack to the guest: + +:: + + dtdev =3D [ + "/soc/i2c@e6508000", + ] + +.. note:: + + xl.cfg:"dtdev" need contain all nodes which are under SCMI management = (not only those which are + behind IOMMU) and passed-through to the guest domain. + +Configure SCMI for predefined domains (dom0less) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* add "xen,sci_type" and "xen,sci-agent-id" properties for required DomU (= "xen,domain") node + +:: + + xen,sci_type=3D"scmi_smc_multiagent" + xen,sci-agent-id=3D2 + +* add scmi nodes to the Driver domain partial device tree the same way as = above (toolstack case) and + enable access to the "arm,scmi-shmem" according to the dom0less document= ation. For example: + +.. code-block:: dts + + 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; + }; + +* For SCMI device access control configure pass-through devices in the gue= st partial DT according to + the dom0less documentation and ensure that devices SCMI management has "= xen,path" property set: + +Example (dom0less, multi-agent): + +.. code-block:: dts + + chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + + /* Xen management channel shared memory */ + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + + scmi_shm_domu: sram@47ff2000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff2000 0x0 0x1000>; + }; + + scmi-secondary-agents =3D < + 0x82000004 &scmi_shm_domu 2>; + #scmi-secondary-agents-cells =3D <3>; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; + #address-cells =3D <1>; + #size-cells =3D <0>; + #access-controller-cells =3D <1>; + shmem =3D <&scmi_shm_1>; + }; + }; + }; + + xen,domain@1 { + compatible =3D "xen,domain"; + xen,sci_type =3D "scmi_smc_multiagent"; + xen,sci-agent-id =3D <2>; + /* other domain properties here */ + }; + }; + +.. code-block:: dts + + i2c@e6508000 { + ... + reg =3D <0x00 0xe6508000 0x00 0x1000>; + -> xen,path =3D "/soc/i2c@e6508000" + -> xen,reg =3D <0x0 0xe6508000 0x0 0x1000 0x0 0xe6508000>; + -> xen,force-assign-without-iommu; + }; --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Jan 29 14:17:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 14:17:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216563.1526521 (Exim 4.92) (envelope-from ) id 1vlSpm-0001ih-8t; Thu, 29 Jan 2026 14:17:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216563.1526521; Thu, 29 Jan 2026 14:17: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 1vlSpm-0001iU-5U; Thu, 29 Jan 2026 14:17:22 +0000 Received: by outflank-mailman (input) for mailman id 1216563; Thu, 29 Jan 2026 14:17: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 1vlSpk-0000f7-Sd for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 14:17: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 384e11f4-fd1d-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 15:17:19 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by VI1PR03MB10078.eurprd03.prod.outlook.com (2603:10a6:800:1ca::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Thu, 29 Jan 2026 14:16: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%4]) with mapi id 15.20.9564.008; Thu, 29 Jan 2026 14:16: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: 384e11f4-fd1d-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IJOLARJpayihsKsUXpI/JmsQeb5IaTpViX288NfF3Sv1MOh3XT2WnyXNOLTcm2o3Tpda/tQnpPow0ufIrwhMXhiY1lkLNJL+ejIp5Qvz8AN6vEO3j0rSM+90W/ZBnBkBgqyIm5f9xvSoiOg1+lcef5sT+Gesq6RJoU9fZtl9G47IvmkX7nr1sYlzXxJyybCkbwmAFL1F4G8rLyH14F3FOkFNdbLDDSYSw/LreoyhDzwvjiOk9rEXUTpwfpBqQ2NQkJnkN7JQxJY4OPWFWZPxCR+j1a34+TUobu7tbalci65u9TSTcOEBuPC80ubc3w/eRfSbSjBzOXxvwbO1p1gLlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7Nk1CN+j4B/Mq/rCvZP0747CGWDJEwdX0Pe1Pu44Qbs=; b=y0qbVyVi/NADXLFvHT8nTB6wevQCkSH4H8Aa6/vw4gPU6/ouPM1MLDONm5g1By+XSp4+ByHWy7y8fXR6RNRtsFzHLL/tBnK/y8cetdJ/9oD2IfAWB7LexGdE90eNMij9ZG47pExiPnnSJV08W2nQdTJXiVZYjXAW4WcycT1CewE58cfenzsyAviVqyIBasEmzn6avffkW3Q13q6sLafVDDzbIOHVRymafaViwjV5vUJhA3sWFAvyiD2AWqPkNCiH1M0tTtbeChhy27xEAcO2poqSpmZboS6+i7PKPcTqYNiXPPovhHepYTsTenfZ9PgbnCSTA/MdqU7Ifd2mRYez0w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7Nk1CN+j4B/Mq/rCvZP0747CGWDJEwdX0Pe1Pu44Qbs=; b=UQGQfo3RfMP+/lYnjUNENoHoCcq6tttHEjZbSTdhRMlZeNkCgwpKr3NfhBeyJMNeNfsaeEgwIK+h9x6naiCHXQnvG0uuBvQJ/LkHfu1KEOtGJqRynOl6doEH0U5XG1O7EzyDCjEKTIQ5aeKqrr6sgdl4gI07q0cqxueIYCItiMfZHopq1zk4Yg9uL/KjhCQkOU99Vp9vtJAqwzC9/LeToypRUgJ9qVyZ8/A25hQKbzdNkaPmX79YjxpQmi4ow/4/pyjKx+wIv7a10xQ7xH5YMWjU59ImNG08ychKa/+sl8dlHinUbpXcwIOIfgFEZBxgxRO133N04EfO17rpL2RfCQ== 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/5] xen: arm: smccc: add INVALID_PARAMETER error code Thread-Topic: [PATCH v9 2/5] xen: arm: smccc: add INVALID_PARAMETER error code Thread-Index: AQHckSnrwskB9T/f0k+nAMu3X/hdCA== Date: Thu, 29 Jan 2026 14:16:54 +0000 Message-ID: <366a3a85e89e868a12e261ea0ae07aca661d0ab6.1769696107.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_|VI1PR03MB10078:EE_ x-ms-office365-filtering-correlation-id: 0eb11185-380d-45e5-6d71-08de5f410e2a 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?70RzBF0IgbuTK8XVueyyXxDI3b11wWXwq1hMSr5ADH/xjVOI5fjAEy4Uyz?= =?iso-8859-1?Q?2D9YNo21hpmf8JTxImhMq7hOCjyx4qtoizXh88CL/Y5I6/VL+04qg/Sq8P?= =?iso-8859-1?Q?daRY5dkQlY7lJBiynXxpszeJYI4ShvTZe+1guh5af3kqb8i8w3SbpoXsVV?= =?iso-8859-1?Q?8x8tYvsG2ennvnVtwhqMFfYFVo9gx+/q76zRsRiYq85lH+yJvoyqfKH7iU?= =?iso-8859-1?Q?5FrhwjlUrh8AknhFM6H4s+nn00fYY7JO5QJcYNEWBQE4zdgeKROl3dngOy?= =?iso-8859-1?Q?ObmV1VEJzsfoRkcOBw7jbWm5y/gJfgHoebHw8m+NXI04xzi7YOOex+X1rV?= =?iso-8859-1?Q?7q7C7tzanOFHVlim4AS+kuJ3+mDM07x1hOPLrBML6Rj5DMETSQacVJMrG7?= =?iso-8859-1?Q?5Dn7pV3LqSMcyz8oYNOVOUvwERCtIkchFddpFMt4jPT0nYmbGkJfeHClVX?= =?iso-8859-1?Q?ocktBar9259NzbZ63mwKjiY6FGJ13VmEsL152Nn8YQXFBsJrRuDW5bW+sU?= =?iso-8859-1?Q?Pw6ZL1oUbd4Gm6xKQkbBd//aQjfD2Dz51xlTs7NNRTpia7X6ynhDNKLtB0?= =?iso-8859-1?Q?0uOGDlOEXa+IL76KsWfNcIl2LSjmdFfyKVyLam4QFfAjD1cikssTyvvbvB?= =?iso-8859-1?Q?1Aey5sWCvujT3+ZpcbA7hG41RjicHC/AjDtKjxC4cdQ7UD0aT30LR1yOK6?= =?iso-8859-1?Q?lqsqhtkdLY95VwpPBSXAzdg0izNeNIN03bDNgUS4fJTiJrnQlkmu8ZvfuX?= =?iso-8859-1?Q?PbDOKImw3QXYAHILWkQXFmdiKlX6qmjDpxHAyfDxlSlygRTEkMx48zo6fB?= =?iso-8859-1?Q?7NJNu2LncxeKeRh1VGfG2OmpXZ8W/ob5nX9/nAxo0XtQ7dzlTiPN1AE3qF?= =?iso-8859-1?Q?2TQzCiIZH+BRQu+CgtUewAJDCYt3h33HBf7nor5OwsBLeSmjnDBtYUdMA4?= =?iso-8859-1?Q?w9m+Gz4pqcG8mxIP8zB8E4fSuEMrcnzWudYd7wWClTU6hVw2VNo4iKKqFk?= =?iso-8859-1?Q?xBusxZj56HrJNdKMf4Ur1DQryzdqJRAjs/nqPLw85G5ARohL1GNZP1oYQX?= =?iso-8859-1?Q?BeCYXuMyFkC5/UtzaoEC8LyWp6EZVjfLChR4ud5jt7TZVJa3R42pVqvH8y?= =?iso-8859-1?Q?/5x1Wayi/xG8EIvO+K599lWSxE/UG/wDn09Y1Rw8DbCH2mwowTNPFA9d7f?= =?iso-8859-1?Q?zJsZTGMCc0XLUK+CF1Br6Q8cbFRn3gJB0co5Qg0XlDL5JfGAZTg5BR6q6p?= =?iso-8859-1?Q?5GndbzZ5TiJ5tODg27G4K+e7/VkCRa7MOoG8vtPEh8JRwfcrOTD0x8cQkT?= =?iso-8859-1?Q?pNDyvcvEfMlsVExyLEmRgQH0RSSQoAaUhyV1azCBtGWVxvOcjTIhVqkIFC?= =?iso-8859-1?Q?xem+IXF2n/KRMfmqIv2AnnKaP1Wuu37NgMV+Fwxtcg3BKodH+u06G4JSOW?= =?iso-8859-1?Q?UOjExTWTQ0qKpTxkrK8zTyJIvBdelC2a7Ymr5mWpdmT1nvPp6xJ5vGt8Cw?= =?iso-8859-1?Q?FQ7MVWhD5b9L9T27JB+hVKbMd87bzUVYUv2WlES4ATeBZd20ykY6xtVn+E?= =?iso-8859-1?Q?gnXeic0keK5WyrkkKzuTGJpC2ZAAEEV2IQINUhyZy7l41Nw9/16Qqs9tPl?= =?iso-8859-1?Q?p2swJaJir7pMzL+VZPew0zHAviskhN276tcAMGndaDCCEZ5VJ/Bpl/DvE3?= =?iso-8859-1?Q?H3ekLZoYrdE12UDmoM4=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)(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?+2lhQWQJx7zeudOhV2GMyOXRB8jOmaJXETfJkIhiwfWFwWdeXpvh3NyXCh?= =?iso-8859-1?Q?Yex1SG95S0itf+pYXl8nmCqtW/Vk5bKPUG8wTD+9PYG5O+Gv2meCane1dS?= =?iso-8859-1?Q?OrKWPMLT2ldFyQgFKkxvRTLW/jm1rLRVP0M5N7IAaua2dLCBwkqks0bSWf?= =?iso-8859-1?Q?j6yDkg4LcnsWVawP4M2g/OIPUnddLleW/qQ0l6LIyiHSTZXr45xEyr2Mvc?= =?iso-8859-1?Q?r61Eg8u0nBl2EtDE0RTeVUQv6I7TfVrK+bM5+8hWpJeLo8RvHs4cEYbgRL?= =?iso-8859-1?Q?9OzIuMZ2A80gXko7pHrErK6pcfafrGV/jQlkbCwe5mSCIpKTKeUmJkTmGx?= =?iso-8859-1?Q?ohIYHGRCeOn60o4oeDgDW//qTjt0mKSCNexP4MlIwZUdC6MhUMI/jF/xaJ?= =?iso-8859-1?Q?KYaFqGE7uqF94BHVGJpi808JHD03ojWlbuFmklgqI1y//TXQgb8bT7BuZI?= =?iso-8859-1?Q?LAOQ84zYHUhD14HSRnkTLLkzseuIFpHfa72WmukzBYimX678zHhVO5haId?= =?iso-8859-1?Q?wx+fGpG/qTsTTTlMoziy//qbbnXNvli3kteSSAQFgK95h0kYGVP6e6l4Nr?= =?iso-8859-1?Q?8Dz09ZjmZiRai/F4JZ5CE23ptOSquJechWtMFsf4oGzGaw0ReTbD3rcx5j?= =?iso-8859-1?Q?ALjHopgxLwqoMC0nPzwNCDe/SRJyb9puQ10UC3vY/e9nswKBDb2/JoZ5Ki?= =?iso-8859-1?Q?AMoXDv+gpOIV7zpvsxjJVKoXHcWWkD5M5zEThcJuoyThYTfxqQ9Mh6imVm?= =?iso-8859-1?Q?I5jnpsg/LavI3lLJH95WbtHZI1vQFlvK0d7b317/4mdyrTsTwNd60VEuH/?= =?iso-8859-1?Q?v7HmBEN/u+1UePlPImGWhQ+/id1xKijwDOazNz5lwIdm2qnNViwfxaDiTe?= =?iso-8859-1?Q?Q4zOEc4GekwaBHXo99f41XURZ4mp/4hSjiAhjDWbdNgjLeu8O1e2y4CKkG?= =?iso-8859-1?Q?iAauN3S+lZRNn1pHWBrKehrq7v/XSmC7CLZEcnn9W8VJEKfs+y/ZhxTXM+?= =?iso-8859-1?Q?BuRjGfPE9M/RG36Fx6VoOIiCWx4CLvMcVIa66ekY6e3nlxICfg6IUcpRTO?= =?iso-8859-1?Q?0e68vvzoUk6hoCdF7vbXxb3aPACJAgxoIXZOPm+r1imsAGN5qoXQzv7KOJ?= =?iso-8859-1?Q?vffqQSblKlyMgksIDPmIK9UpI7wunyqLptSJSjCnahk/alz6kVsFFRqpC2?= =?iso-8859-1?Q?CHJxoVndr+qT5AlgsvFhMywJRWrLhsZ7J7P47o4dPUDSU6HJgOQSxGusCd?= =?iso-8859-1?Q?4yh+5Z8jVl/7o2PHmsvxrs6942ShYiyCm0XE362H7ItUojLzVQRZQ6RgCA?= =?iso-8859-1?Q?4otMeYA1Z52KzRgSIQUB7oa4owgw0a3qXcIfRo3EOx7Nu6NKGWkEftaggQ?= =?iso-8859-1?Q?3nGZEL/FJE1FVkTOv87AoRifkb/B3SsVoLQms3Z7HJLvDKIjH6dUfRN/BO?= =?iso-8859-1?Q?13WM+hq9FagtXyT5IP6cY0wT9xsz5sL0cfmAFks+juogI8WQX5+Dlskv1w?= =?iso-8859-1?Q?JzOqREpgHPrV7Z0ApEdCeRV8AXdczLY7dvFwWDq48UsueH4Ocno3ZVdN6n?= =?iso-8859-1?Q?oujNbfthWL0JZqIFFuUJcY4lMTySleK6OxS33mtOX63Pdp9JdjAG/vZi3j?= =?iso-8859-1?Q?T4TgtrUi0NQ6zkn1ioXOmpj8d1uwG+uhn8wFHT1ZkXTtJ8pUFPgK+04ud+?= =?iso-8859-1?Q?tN4ceO1UY1C5GBFB2HwzxVdmCzcY+bUtnhsavm2n03nTPIc/b+diToD8lR?= =?iso-8859-1?Q?0Z9wl1NoSmw5EIrZDyCKEEIFEC0tEvZp/T1LqZ7RjY7gBDcY66QFItn8tS?= =?iso-8859-1?Q?nhXzbLz0DddAQjErzc3356goXh4mscc=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: 0eb11185-380d-45e5-6d71-08de5f410e2a X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2026 14:16:54.7616 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eXyTHCcPWD7VH6VKkGSeBSreu6RGXqtZMSLlGbKRiGD+gCQYLmdeM1xRrI3wNaHAFgV52M/X1xmT6Hqo6YujpvqM5Iq/Yt2RDr+8Dxs7nLA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB10078 According to the "7.1 Return Codes" section of DEN0028 [1] INVALID_PARAMETER code (-3) is returned when one of the call parameters has a non-supported value. Adding this error code to the common smccc header file. [1]: https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6 Signed-off-by: Oleksii Moisieiev --- xen/arch/arm/include/asm/smccc.h | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/sm= ccc.h index 441b3ab65d..478444fb09 100644 --- a/xen/arch/arm/include/asm/smccc.h +++ b/xen/arch/arm/include/asm/smccc.h @@ -381,6 +381,7 @@ void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs = *args, 0x3FFF) =20 /* SMCCC error codes */ +#define ARM_SMCCC_INVALID_PARAMETER (-3) #define ARM_SMCCC_NOT_REQUIRED (-2) #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION (-1) #define ARM_SMCCC_NOT_SUPPORTED (-1) --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Jan 29 14:17:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 14:17:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216567.1526531 (Exim 4.92) (envelope-from ) id 1vlSpo-00021A-O7; Thu, 29 Jan 2026 14:17:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216567.1526531; Thu, 29 Jan 2026 14: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 1vlSpo-00020w-Ka; Thu, 29 Jan 2026 14:17:24 +0000 Received: by outflank-mailman (input) for mailman id 1216567; Thu, 29 Jan 2026 14: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 1vlSpn-0000f7-8p for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 14:17:23 +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 397206bb-fd1d-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 15:17:20 +0100 (CET) Received: from PAVPR03MB8946.eurprd03.prod.outlook.com (2603:10a6:102:32e::21) by VI1PR03MB10078.eurprd03.prod.outlook.com (2603:10a6:800:1ca::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Thu, 29 Jan 2026 14:16:55 +0000 Received: from PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc]) by PAVPR03MB8946.eurprd03.prod.outlook.com ([fe80::f12d:7394:bbe3:dfc%4]) with mapi id 15.20.9564.008; Thu, 29 Jan 2026 14:16:55 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 397206bb-fd1d-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VunVgkEvrIq+U2fX1VBPt6AMSvBwDAV1sCm+eJ3bG/wZkxWmbcKGuMMGELpzN4voOJLx3GGZWlDu9DwW7yFh2DYPMrLzztQVsA9fxDxfNMknUzzPNWGsOSJrUDItLGsyvy0L6cNDg861OjWDUz1w2RdMv/J83PmzuUZfw8jrdjBFjiXJ8gJ2a6pnxvoqasZuS8O8gYhy3zmFD79owjWQU8LejwI5jw05AkYq8ewkFjsv3Oc+bM0FwohmoMMWAVxXTIJwymqrjf0bTnyfo0RkdvEBOPE3lmaJLRrWv0TH8ysvK+MgQ9VuzUgjUkdwkJTky+JFIm41NkuPeeFvpOjq3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=AJTslo0xgIyAVB/EXNqK9tipAhtRx4Tt0xxzCRX5TAQ=; b=dRnp7DfzvjKS1sdUN+Ef3gJeKCOpGjETfYkZUNeFVbd3b8DRpKbUh3cx0MoavytxwYAiJ0qY9hCKdjpJPvVva003QkMsojsgAEwGnKyEVA7jF0UcxXKvpEE4mqxZCfEbiRwCT+DQwtCekSjDTQLfOkZmtlrAzKf0UbhrDk075U5T7wsQIH8J7PR4+buAbzwWr94FaaxEBjk+UZN71Qz4BV2jI+58ea6nII+VYAkECYiKiBQPaTiWLQa0T9iv2bOeEvdSNFySQVu6j2PLCnY5B/Eo2KUw/RoSpJVyvRjojNar6+RAbmxi5LaPxCLcHjY0bM++3jai18G6aMb5E19yPQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AJTslo0xgIyAVB/EXNqK9tipAhtRx4Tt0xxzCRX5TAQ=; b=uVjeV6ib0W9YkTTqyyS/bNIqDCEDgffA7e9rAGn96H0XiOa6PTN2UIXyd6OmuLRfl+udIpVvzMScRvJ35LSMzH797trwymDkLQwJAqrGotHEediEcq09PHZ6kYbhKx9Pk2FuVsSzjJv/F9oTi7FXVEP1QBw2gooAvlk7toZxHioZxRoBYgNRoJNcKIPT7ssyRZ4jrjJ+4SIW2RSD36qphH6bKxr0hpTnCmSlNvqk1KF1sOD9eioQCC3qOU8DcHz526mURScsargzM3MzKYY1kft+Yx/PHQ6MlQgtoioJVWl6r7ACprSzreoNJZGB9wm47PHsT7ePVTnr4GBW82Eq8w== 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/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Topic: [PATCH v9 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Thread-Index: AQHckSnscogayWOoV0WYwtG2zZFEPg== Date: Thu, 29 Jan 2026 14:16:55 +0000 Message-ID: <3a5ff98b9c46c393e856c2e9a645b2cb1509d5c4.1769696107.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_|VI1PR03MB10078:EE_ x-ms-office365-filtering-correlation-id: 37366e22-1551-478a-c7a5-08de5f410ea0 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?nwXgl47sOyfNudHlHF2/H5OnrTO9siReTxW2/z43Qr20i6fZBkAMhHKUdq?= =?iso-8859-1?Q?8SzBdcVQfgKERfMDF5wLuGXwMVoqFKanCFie1xY2PHCXI3z5NulcX8hS/o?= =?iso-8859-1?Q?ZDw9t0FfjxN8+HBWWMXxf1Em2H5VuW1JLbXxAONUZbql91+1YY9X4yGWov?= =?iso-8859-1?Q?vN5DxbaWDryeqra1wU09l4rFSYPH2ofIffNa6EIxjnsHOMMnnT6y5Iy2Gt?= =?iso-8859-1?Q?U7HrDr4vcJ6KC/gkpoWqzplPTUQbkzRRAaRumBQFIVZR0aaTbVGKzZKfiP?= =?iso-8859-1?Q?1R6QIBMRxr15bhpGANL4CC5Gat3PI3M8nvguenpFRBipa5jlBBr9zYgHtI?= =?iso-8859-1?Q?5Zd0g6LzOTc1cjvd7CLT1hq0ZT/t8YbJ0geKPUmfSPI4fxzA9rLDyQPd0Y?= =?iso-8859-1?Q?fL2JJKkDp/b142HzbwNurtMU4GJPycbD1jlvbkFHDBYRe3MEZ3nO3JJtWG?= =?iso-8859-1?Q?BUTfEOLeMtDXbzfK2+U8yxBYRExx/RkV9e0co0u9GFKv4jLZUd1GGOPCfU?= =?iso-8859-1?Q?isGajWqPauv9zIWK1ztW1zRXVnxsLDQqfaphzt00Mkk8cnKq5QBO0i1bjy?= =?iso-8859-1?Q?YPnRhiTprhPOye5UR3nHDk1/6Iv10t1Sddils23Ezp4DGmfGMMazqhjgre?= =?iso-8859-1?Q?t4ojuTYOEE4hRwIbhv7S4pdGut3zPw3weScLdJSw/iKJk9z0QDK4DfIOlh?= =?iso-8859-1?Q?dzgkOklx/jPCHXXBbpXX/2sDxopVc9YTOTp/eFlSa5vy6UHrrKxoWmyOOF?= =?iso-8859-1?Q?sgQZV3F5XUtRoqYKUAWzPl9qXF94YV6zgBEkwZYxz40r+AYgfd9YBK5byH?= =?iso-8859-1?Q?2pd0tkZi3vdVzCuDMBSGxatIiLTL6fzpt13C7fnt8pwH66U8Sp7dBQ5pqy?= =?iso-8859-1?Q?YZLvn0tAay+y7AFnuga9vCAU/iMgydqr3MxVsd3KyOE2TJKVxUH2EMTarX?= =?iso-8859-1?Q?ulIMEjULrsPxnuA5EcdrvAoouU04tVPZbMYUdJ97a8PgjEaiG3FrXfbGC4?= =?iso-8859-1?Q?RBJsEJq2vwwjN43zVsWZSQ50gI1StdLdbBkCkbchJU0lzUCypC0fmSQ0z3?= =?iso-8859-1?Q?XNCOBUfftWoMQ0JTYDEPiHNaApAOjuGVdzRkHGnipRxJNBT+Lu2W5Y7eXe?= =?iso-8859-1?Q?eZChfWiMQFCH2z9K+OSf4piAb6IFcorfcax88/b1YOpcVSNX4e1s5/uHY/?= =?iso-8859-1?Q?v+NY5bUb9++/zlZPswRMdIG1CsdWh3PXql74fBX8tHPtouOQXDfSvk8Q6M?= =?iso-8859-1?Q?KdShX23wblMGDEjcZIAhg8skTFOtM00CzcvngDnRlMMueGtQchML5QFhh9?= =?iso-8859-1?Q?v/Y9Th1OAlgVMoWh5GUS1ZFhfpZOELBlGW/c7YK7b3Msg3bhthf02zhf2a?= =?iso-8859-1?Q?rTbEBtFx/46/4WnWomt0IP++h5Te/YF/B/0D+0uLlIhgOhW3/cxC6ssldm?= =?iso-8859-1?Q?I2HFV3dxABdu97PDJwXeVWvxijs0t0C04A1pws/Ggrg4fd32JlZHiS0oHU?= =?iso-8859-1?Q?8dJ62RGF/UVy0r7+WrprZNpkj9gcjbFiiIC/9XBxZmc4Mp8qkeI36T3RZ3?= =?iso-8859-1?Q?OU/vvZFhO4tzByJD6LMPGILZov2CYSkc2MY2eqhV4H0ObiyMSRugbdt/2F?= =?iso-8859-1?Q?I2qQCKweH4GXdUHr5aa2lmmehQjhgCxN+I45qqq5r8HoqJxUXQ7pQlKjHA?= =?iso-8859-1?Q?D5mPQkTgYP8tkp10rBk=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)(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?WARnp5S1EWXuRwUvG39nAdM7eF9BP5/p6cU+syBAVrHAjHF3hhp6OgylH8?= =?iso-8859-1?Q?bJeQuBu3r4z2Qz0uxvE0bbnoNbw1aJsUuxqotRJcpU8wtwnB2NguuUKy9+?= =?iso-8859-1?Q?q808wFiX+nFjyEkCEwR9c/aRojd5cW0ohEDK9ZJNaZda8BuHMeXEI5SgeC?= =?iso-8859-1?Q?IewLgRcgIQI6FmQ9pu5JgwmiQS3ulmFhbFqYVZNUkHow5H9hxn4I8lq/uS?= =?iso-8859-1?Q?ZRdw3kIqGYE7YfbPq1lRQr1YCPccY1Y+aFBIIIIbp2V2v3D2lzfoKtBfgR?= =?iso-8859-1?Q?jFWcdfUu/kiwSRr8S3X6ME8YpUGJokkYZ0jF1p00E9+qlL+tKf5f9X7lAK?= =?iso-8859-1?Q?NA5Zq1poTTLrGDkHCL2qNiSCH1sYOJTAX+ppAEi0KEIqU/sYx6ksp4ZLJD?= =?iso-8859-1?Q?WGBYbO8SzFS7Z7susg7SFn+mWpwQnlu86Aucvlp/u9GdIOyG/PCu/JhW5p?= =?iso-8859-1?Q?4j4K00LSdSloxBdqckygNKabkjhI9pVqrvvPRO8RD9Hb54ufbQM02ia9Uh?= =?iso-8859-1?Q?8IfPgIavfz7AAHyEkq/rIQRaquaVRdIuc1OZoXPNcvwdaT6vu+eCetslgM?= =?iso-8859-1?Q?BVnHFlconOH7Kel4UPg5w+TSjS/DaCFZuNCHBmkdLNPg2n6g/1CMfaP6FV?= =?iso-8859-1?Q?pbD2MQmWoR+g+kuYy0mJ2OjTspOAOAJGk2rBbRfeRZHlJY5BlgTr44MiAL?= =?iso-8859-1?Q?xG2iiUE2EwG/wxpoeEgN1flxUVubpR4+VhoovwEyCS8oNB34aecaQdtgj6?= =?iso-8859-1?Q?MymY0m0oap5mdP/S+c5nP4BR2yg69mqPk64ob4wVCEeCtGzuxS/oJeLZQe?= =?iso-8859-1?Q?nc9CY8fWPH11sMFChOpOjOLmlUYQhETrqWKRHjVLgwq2P9iu5n1fqYlUEh?= =?iso-8859-1?Q?K7c/4Z+IQsFEtNyGfFRv5zJZB0NrQYVCMVrEO2XCI/fEaBNWUmEwsLnk1/?= =?iso-8859-1?Q?BoSK1K8SwtLWKQ4lZfDAGEWGXMygPiD1ZqLaLy7tRWCPEHyy379CzrHMxi?= =?iso-8859-1?Q?RvUfn51nAAjFG9S2hHJvHIqvjVHYiFSrlKzjUyRONXvRggM+f52wjLvzsW?= =?iso-8859-1?Q?R/F0JYGV0eayfLHyrPycLeEWMtnbcP7Q0+X5eYIxWer1G8y5KLlp6hzL2R?= =?iso-8859-1?Q?Vhf/jHOnf4NI97T5SW+hmedivbbMZJWDWAzdKfjfFXmuED3Daxu396V3Sn?= =?iso-8859-1?Q?ItKnfN7UC1JVz387qSEjVxthtdb6eQsO1k1vHMSRb0q5W/slWUsm3L5UlB?= =?iso-8859-1?Q?IoDt3x1fmRFsPKrbxDd39tm4bhXy362E4um38P7CrngKEM9QJespFfwiNh?= =?iso-8859-1?Q?UneV4QILana7S+akFsTRlufuDIMk74nugEE0l7BVABdIRb/rPZR23Mrvoe?= =?iso-8859-1?Q?h2W7VfIBspx7dSOjMVcfFpKYCkNW6UI2gE99ddPPZxXQBI6LZZoRHu7hNO?= =?iso-8859-1?Q?BhlA6ESDCDrgZh9jLDOgHIWvSqywrCcVdbsdrxHDaPgeLZ35hHNwYs2cnP?= =?iso-8859-1?Q?gXH1HlWyr9HAXIMHsRnMf5pl9T2TXiEspeElgemue336vuOrnSKOU3ZuDs?= =?iso-8859-1?Q?gJt567dU9voIkioWbVV1PzpB+G9p0OhdVLxyMfvVJWJBGAyldS6Qgop6DP?= =?iso-8859-1?Q?U5mZRWLHsgCn5D12Vf8n+JDvJAgM1iCH+2GIqot1txLb1PcWFwXCGqBm/j?= =?iso-8859-1?Q?IJkmjeAiKVSCoewOXqM9MNxScdyQMOdI3lVWlAxAbY2uxbBa+Se1ZFaF5b?= =?iso-8859-1?Q?Azx2BNXWI26Hd7Wvf5tC/w81feLxcrEXdpcu/feCYQZWVC3GS2H76fmgSf?= =?iso-8859-1?Q?khqy5CG4wQNEkdHk0hQHZHEaGKTn3Ig=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: 37366e22-1551-478a-c7a5-08de5f410ea0 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2026 14:16:55.5707 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4V3+sewoYmfxMpx3kz29MqplF/6faCpI/mIVDSco56mZrE+2weiOB+nVFt2j0uzlUYJ1Ib3RqTOh3HyiuiqcGzKGTWwVYNkT4w/9Gs7ln2I= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB10078 This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-A (TF-A) which provides SCMI interface with multi-agent support, as shown below. +-----------------------------------------+ | | | EL3 TF-A SCMI | +-------+--+-------+--+-------+--+-------++ |shmem1 | |shmem0 | |shmem2 | |shmemX | +-----+-+ +---+---+ +--+----+ +---+---+ smc-id1 | | | | agent1 | | | | +-----v--------+---------+-----------+----+ | | | | | | | | | | +--------------+---------+-----------+----+ smc-id0 | smc-id2| smc-idX| agent0 | agent2 | agentX | | | | +----v---+ +--v-----+ +--v-----+ | | | | | | | Dom0 | | Dom1 | | DomX | | | | | | | | | | | | | +--------+ +--------+ +--------+ The EL3 SCMI multi-agent firmware is expected to provide SCMI SMC shared memory transport for every Agent in the system. The SCMI Agent transport channel defined by pair: - smc-id: SMC id used for Doorbell - shmem: shared memory for messages transfer, Xen page aligned. Shared memort is mapped with the following flags: MT_DEVICE_nGnRE. The follwoing SCMI Agents are expected to be defined by SCMI FW to enable S= CMI multi-agent functionality under Xen: - Xen management agent: trusted agents that accesses to the Base Protocol commands to configure agent specific permissions - OSPM VM agents: non-trusted agent, one for each Guest domain which is allowed direct HW access. At least one OSPM VM agent has to be provided by FW if HW is handled only by Dom0 or Driver Domain. The EL3 SCMI FW is expected to implement following Base protocol messages: - BASE_DISCOVER_AGENT (optional if agent_id was provided) - BASE_RESET_AGENT_CONFIGURATION (optional) - BASE_SET_DEVICE_PERMISSIONS (optional) The SCI SCMI SMC multi-agent driver implements following functionality: - The driver is initialized from the Xen SCMI container ``xen_scmi_config`` (compatible ``xen,sci``) placed under ``/chosen/xen``. Only the ``arm,scmi-smc`` node that is a child of this container will bind to Xen; other SCMI nodes (for example under ``/firmware``) are ignored to avoid stealing the host OSPM instance. scmi_shm_1: sram@47ff1000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff1000 0x0 0x1000>; }; scmi_xen: scmi { compatible =3D "arm,scmi-smc"; arm,smc-id =3D <0x82000003>; <--- Xen management agent smc-id #address-cells =3D < 1>; #size-cells =3D < 0>; #access-controller-cells =3D < 1>; shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem }; - The driver obtains Xen specific SCMI Agent's configuration from the Host DT, probes Agents and builds SCMI Agents list. The Agents configuration is taken from "scmi-secondary-agents" property where first item is "arm,smc-id", second - "arm,scmi-shmem" phandle and third is optional "agent_id": / { chosen { xen { ranges; xen_scmi_config { compatible =3D "xen,sci"; #address-cells =3D <2>; #size-cells =3D <2>; ranges; scmi_shm_0: sram@47ff0000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff0000 0x0 0x1000>; }; /* Xen SCMI management channel */ scmi_shm_1: sram@47ff1000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff1000 0x0 0x1000>; }; scmi_shm_2: sram@47ff2000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff2000 0x0 0x1000>; }; scmi_shm_3: sram@47ff3000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff3000 0x0 0x1000>; }; scmi-secondary-agents =3D < 0x82000002 &scmi_shm_0 0 0x82000004 &scmi_shm_2 2 0x82000005 &scmi_shm_3 3>; <--- func_id, shmem, agent_id #scmi-secondary-agents-cells =3D <3>; xen,dom0-sci-agent-id =3D <0>; scmi_xen: scmi { compatible =3D "arm,scmi-smc"; arm,smc-id =3D <0x82000003>; <--- Xen management agent func_id #address-cells =3D <1>; #size-cells =3D <0>; #access-controller-cells =3D <1>; shmem =3D <&scmi_shm_1>; <--- Xen management agent shmem }; }; }; }; }; / { /* * Host SCMI OSPM channel - provided to the Dom0 as is if SCMI * enabled for it, ignored by Xen multi-agent mediator */ scmi_shm: sram@47ff0000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x47ff0000 0x0 0x1000>; }; firmware { scmi: scmi { compatible =3D "arm,scmi-smc"; arm,smc-id =3D <0x82000002>; <--- Host OSPM agent smc-id #address-cells =3D < 1>; #size-cells =3D < 0>; shmem =3D <&scmi_shm>; <--- Host OSPM agent shmem protocol@X{ }; }; }; }; This approach allows defining multiple SCMI Agents by adding Xen-specific properties under the ``/chosen`` node to the Host Device Tree, leaving the main part unchanged. The Host DT SCMI channel will be passed to Dom0. The Xen management agent is described as a ``scmi_xen`` node under the ``xen,sci`` comaptible node, which is used by Xen to control other SCMI Agents in the system. All secondary agents' configurations are provided in the ``scmi-secondary-agents`` property with an optional ``agent_id`` field. The ``agent_id`` from the ``scmi-secondary-agents`` property is used to identify the agent in the system and can be omitted by setting ``#scmi-secondary-agents-cells =3D <2>``, so the Secondary Agents configuration will look like this: / { chosen { xen { xen_scmi_config { compatible =3D "xen,sci"; #address-cells =3D <2>; #size-cells =3D <2>; ranges; /* Shared memory nodes as defined earlier */ scmi-secondary-agents =3D < 0x82000003 &scmi_shm_0 0x82000004 &scmi_shm_2 0x82000005 &scmi_shm_3 0x82000006 &scmi_shm_4>; #scmi-secondary-agents-cells =3D <2>; }; }; }; } In this case, Xen will use the ``SCMI_BASE_DISCOVER_AGENT`` call to discover the ``agent_id`` for each secondary agent. Providing the ``agent_id`` in the ``scmi-secondary-agents`` property allows skipping the discovery call, which is useful when the secondary agent's shared memory is not accessible by Xen or when boot time is important because it allows skipping the agent discovery procedure. Note that Xen is the only one entry in the system which need to know about SCMI multi-agent support. SMC ID Configuration and SCMI Connection Compatibility: The configuration allows the same device tree to work for both baremetal Linux and Linux Dom0. This is achieved because: - Baremetal Linux uses: func_id 0x82000002, scmi-shmem 0x47ff0000 - Dom0 Linux uses: func_id 0x82000002, scmi-shmem 0x47ff0000 - Xen management uses: func_id 0x82000003, scmi-shmem 0x47ff1000 This works because the privileged SCMI connection in EL3 firmware is not tied exclusively to func_id 0x82000002. The EL3 firmware supports multiple SCMI agents with different SMC IDs and shared memory regions. Each agent (Dom0 via 0x82000002, Xen via 0x82000003, other domains via additional func_ids) has an independent communication channel to the firmware. The key distinction is that Xen's management channel (0x82000003) is used for privileged operations like agent configuration and device permissions (BASE_SET_DEVICE_PERMISSIONS, BASE_RESET_AGENT_CONFIGURATION), while Dom0's channel (0x82000002) is used for standard SCMI protocol operations (power, clock, sensor management, etc.). The firmware enforces different permission levels for each agent based on their agent_id, not the SMC ID. Therefore, there is no conflict: Linux Dom0 retains its standard SCMI connection for hardware management, while Xen uses its separate privileged channel for mediating access between multiple domains. - It implements the SCI subsystem interface required for configuring and enabling SCMI functionality for Dom0/hwdom and Guest domains. To enable SCMI functionality for domain it has to be configured with unique supported SCMI Agent_id and use corresponding SCMI SMC shared memory transport [smc-id, shmem] defined for this SCMI Agent_id. - Once Xen domain is configured it can communicate with EL3 SCMI FW: -- zero-copy, the guest domain puts SCMI message in shmem; -- the guest triggers SMC exception with smc-id (doorbell); -- the Xen driver catches exception, do checks and synchronously forwards it to EL3 FW. - the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen management agent channel on domain destroy event. This allows to reset resources used by domain and so implement use-case like domain reboot. Dom0 Enable SCMI SMC: - set xen,dom0-sci-agent-id=3D under the xen,sci container in the Host DT. If the property is absent, SCMI is disabled for Dom0 and all SCMI nodes are removed from the Dom0 DT. The driver updates the Dom0 DT SCMI node "arm,smc-id" value and fixes up the shmem node according to the assigned agent_id. - pass dom0=3Dsci-agent-id=3D in Xen command line. if not provid= ed SCMI will be disabled for Dom0 and all SCMI nodes removed from Dom0 DT. The driver updates Dom0 DT SCMI node "arm,smc-id" value and fix up shmem node according to assigned agent_id. Guest domains enable SCMI SMC: - xl.cfg: add configuration option as below arm_sci =3D "type=3Dscmi_smc_multiagent,agent_id=3D2" - xl.cfg: enable access to the "arm,scmi-shmem" which should correspond assigned agent_id for the domain, for example: iomem =3D [ "47ff2,1@22001", ] - DT: add SCMI nodes to the Driver domain partial device tree as in the below example. The "arm,smc-id" should correspond assigned agent_id for the domain: passthrough { scmi_shm_0: sram@22001000 { compatible =3D "arm,scmi-shmem"; reg =3D <0x0 0x22001000 0x0 0x1000>; }; firmware { compatible =3D "simple-bus"; scmi: scmi { compatible =3D "arm,scmi-smc"; arm,smc-id =3D <0x82000004>; shmem =3D <&scmi_shm_0>; ... } } } SCMI "4.2.1.1 Device specific access control" The XEN SCI SCMI SMC multi-agent driver performs "access-controller" provider function in case EL3 SCMI FW implements SCMI "4.2.1.1 Device specific access control" and provides the BASE_SET_DEVICE_PERMISSIONS command to configure the devices that an agents have access to. The DT SCMI node should "#access-controller-cells=3D<1>" property and DT devices should be bound to the Xen SCMI. &i2c1 { access-controllers =3D <&scmi 0>; }; The Dom0 and dom0less domains DT devices will be processed automatically through sci_assign_dt_device() call, but to assign SCMI devices from toolstack the xl.cfg:"dtdev" property shall be used: dtdev =3D [ "/soc/i2c@e6508000", ] xl.cfg:dtdev will contain all nodes which are under SCMI management (not only those which are behind IOMMU). Additionally, this patch adds documentation for the pre-existing scmi-smc-passthrough command line option, which was previously undocumented. [0] https://developer.arm.com/documentation/den0056 [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/= tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml [2] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/= tree/Documentation/devicetree/bindings/access-controllers/access-controller= s.yaml Signed-off-by: Grygorii Strashko Signed-off-by: Oleksii Moisieiev --- Changes in v9: - sort and refactor MAINTAINERS enties - remove Spurious changes - add extra check to avoid ASSERT when calling unmap_channel_memory from assign device method - set correct tx flag to SCMI_BASE_AGENT_PERMISSIONS_RESET when freeing resources. Flag should be set to 1 according to the section 4.2.2.12 [0]. - fix dt node copmaring - moved channel->shmem check from ASSERT in unmap_memory_channel to "if" statement. This will prevent firing ASSERT if unmap_channel_memory was called twice on the same channel. Changes in v8: - update xen_scmi func_id in commit description - updated documentation with the new DT format - updated opt_dom0_scmi_agent_id setting to avoid it to be equal SCMI_AGENT_ID_INVALID. - changed SCMI_AGENT_ID_INVALID from 0xff to UINT8_MAX which makes code more clear showing that UINT8_MAX is theated like invalid agent_id and couldn't be used. Also excluded SCMI_AGENT_ID_INVALID from acceptable value range - remove outdated xen,config property ignore, added xen,sci compatible to skip_matches in handle_node - add documentation for pre-existing scmi-smc-passthrough command line option in alphabetically correct location (in 's' section) - add note to commit description about documentation for previously undocumented scmi-smc-passthrough - Fix SMC IDs in DT examples (Xen management uses 0x82000003, Dom0 uses 0x8= 2000002) - Add explicit note explaining why Dom0 and Xen channels do not conflict - Document dom0less multi-agent configuration example (xen,sci_type / xen,s= ci-agent-id) - Add scmi_xen node to agent-discovery example with #scmi-secondary-agents-= cells =3D 2 - Drop dom0=3Dsci-agent-id command line handling; Dom0 SCMI is now enabled = via xen,dom0-sci-agent-id in the xen,sci DT container - Refresh docs and examples to mention the DT property instead of the cmdli= ne option Changes in v7: - rework scmi nodes for xen to match on compatible string instead of the direct path Changes in v6: - updated scmi-shmem to use io.h from generic location - update scmi_agent_id parameter to be provided inside dom0=3D parameter list and have the following format "dom0=3Dsci-agent-id=3D0" This change was done as a response for Stefano comment and requires a lot of code changes, but produces much cleaner solution that's why I've added it to the code. - fix file comments and return codes - fix lenght checks in shmem_{get,put}_message to use offsetof - remove len member from scmi_channel structure as it is not used - set scmi-secondary-agents property to be mandatory since if no secondary agents were provided then there is no sence to enable scmi when no secondary agents are populated to the Domains - update documentation in booting.txt, added xen_scmi node to the example - adjust d->arch.sci_enabled value in scmi_domain_destroy - fix lock management in smc_create_channel call - avoid extra map_channel_memory command for Xen management channel because collect_agent_id call unmaps memory if DOMID_XEN is not set. So for Xen management channel we can init domain_id ad DOMID_XEN before calling collect_agent_id so memory shouldn't be unmapped. Changes in v5: - fix device-tree example format in booting.txt, added ";" after "}". - update define in scmi-proto.h - update define in scmi-shmem.h file - scmi_assign_device - do not ignore -EOPNOTSUPP return code of the do_smc_xfer - remove overwriting agent_channel->agent_id after SCMI_BASE_DISCOVER_AGENT call - add multi-agent files to the MAINTAINERS - add SCMI multi-agent description to the SUPPORT.md - handle ARM_SMCCC_INVALID_PARAMETER return code and return -EINVAL for smc call - updated collect_agents function. Set agent_id parameter as optional in scmi-secondary-agents device-tree property - introduce "#scmi-secondary-agents-cells" parameter to set if agent_id was provided - reanme xen,scmi-secondary-agents property to scmi-secondary-agents - move memcpu_toio/fromio for the generic place - update Xen to get management channel from /chosen/xen,config node - get hypervisor channnel from node instead of using hardcoded - update handling scmi and shmem nodes for the domain - Set multi-agent driver to support only Arm64 Changes in v4: - toolstack comments from Anthony PERARD - added dom0less support - added doc for "xen,scmi-secondary-agents" MAINTAINERS | 1 + SUPPORT.md | 11 + docs/man/xl.cfg.5.pod.in | 13 + docs/misc/arm/device-tree/booting.txt | 196 +++++ tools/libs/light/libxl_arm.c | 4 + tools/libs/light/libxl_types.idl | 4 +- tools/xl/xl_parse.c | 12 + xen/arch/arm/dom0less-build.c | 11 + xen/arch/arm/domain_build.c | 39 + xen/arch/arm/firmware/Kconfig | 12 + xen/arch/arm/firmware/Makefile | 1 + xen/arch/arm/firmware/scmi-proto.h | 164 ++++ xen/arch/arm/firmware/scmi-shmem.c | 115 +++ xen/arch/arm/firmware/scmi-shmem.h | 45 ++ xen/arch/arm/firmware/scmi-smc-multiagent.c | 818 ++++++++++++++++++++ xen/include/public/arch-arm.h | 3 + 16 files changed, 1448 insertions(+), 1 deletion(-) create mode 100644 xen/arch/arm/firmware/scmi-proto.h create mode 100644 xen/arch/arm/firmware/scmi-shmem.c create mode 100644 xen/arch/arm/firmware/scmi-shmem.h create mode 100644 xen/arch/arm/firmware/scmi-smc-multiagent.c diff --git a/MAINTAINERS b/MAINTAINERS index bf00be928c..3f82a07070 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -529,6 +529,7 @@ SCI MEDIATORS R: Oleksii Moisieiev S: Supported F: xen/arch/arm/firmware/sci.c +F: xen/arch/arm/firmware/scmi-*.[ch] F: xen/arch/arm/include/asm/firmware/sci.h =20 SEABIOS UPSTREAM diff --git a/SUPPORT.md b/SUPPORT.md index d441bccf37..03e3985da2 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -956,6 +956,17 @@ by hwdom. Some platforms use SCMI for access to system= -level resources. =20 Status: Supported =20 +### Arm: SCMI SMC multi-agent support + +Enable support for the multi-agent configuration of the EL3 Firmware, whic= h +allows Xen to provide an SCMI interface to the Domains. +Xen manages access permissions to the HW resources and provides an SCMI in= terface +to the Domains. Each Domain is represented as a separate Agent, which can +communicate with EL3 Firmware using a dedicated shared memory region, and +notifications are passed through by Xen. + + Status, ARM64: Tech Preview + ### ARM: Guest PSCI support =20 Emulated PSCI interface exposed to guests. We support all mandatory diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in index 27c455210b..6943ae29ad 100644 --- a/docs/man/xl.cfg.5.pod.in +++ b/docs/man/xl.cfg.5.pod.in @@ -3156,8 +3156,21 @@ single SCMI OSPM agent support. Should be used together with B Xen command line option. =20 +=3Ditem B + +Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI ov= er +SMC calls forwarding from domain to the EL3 firmware (like Trusted Firmwar= e-A) +with a multi SCMI OSPM agent support. The SCMI B should be +specified for the guest. + =3Dback =20 +=3Ditem B + +Specifies a non-zero ARM SCI agent id for the guest. This option is mandat= ory +if the SCMI SMC support is enabled for the guest. The agent ids of domains +existing on a single host must be unique and in the range [1..255]. + =3Dback =20 =3Dback diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-t= ree/booting.txt index 977b428608..6b88dae347 100644 --- a/docs/misc/arm/device-tree/booting.txt +++ b/docs/misc/arm/device-tree/booting.txt @@ -322,6 +322,20 @@ with the following properties: Should be used together with scmi-smc-passthrough Xen command line option. =20 + - "scmi_smc_multiagent" + + Enables ARM SCMI SMC multi-agent support for the guest by enabling SCM= I over + SMC calls forwarding from domain to the EL3 firmware (like ARM + Trusted Firmware-A) with a multi SCMI OSPM agent support. + The SCMI agent_id should be specified for the guest with "xen,sci-agen= t-id" + property. + +- "xen,sci-agent-id" + + Specifies ARM SCMI agent id for the guest. This option is mandatory if= the + SCMI SMC "scmi_smc_multiagent" support is enabled for the guest. The a= gent ids + of guest must be unique and in the range [0..255]. + Under the "xen,domain" compatible node, one or more sub-nodes are present for the DomU kernel and ramdisk. =20 @@ -824,3 +838,185 @@ The automatically allocated static shared memory will= get mapped at 0x80000000 in DomU1 guest physical address space, and at 0x90000000 in Dom= U2 guest physical address space. DomU1 is explicitly defined as the owner dom= ain, and DomU2 is the borrower domain. + +SCMI SMC multi-agent support +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D + +For enabling the ARM SCMI SMC multi-agent support (enabled by CONFIG_SCMI_= SMC_MA) +the Xen specific SCMI Agent's configuration shall be provided in the Host = DT +according to the SCMI compliant EL3 Firmware specification with ARM SMC/HV= C +transport. The SCMI configuration must live under the Xen SCMI container +"xen,sci" beneath "/chosen" (for example "/chosen/xen/xen_scmi_config/scmi= "). The +Xen SCMI mediator will bind only to the "arm,scmi-smc" node that is a chil= d of +this "xen,sci" container; any other "arm,scmi-smc" nodes (for example unde= r +"/firmware") are ignored to avoid stealing the host's SCMI OSPM instance. + +- scmi-secondary-agents + + Defines a set of SCMI agents configuration supported by SCMI EL3 FW an= d + available for Xen. Each Agent defined as triple consisting of: + SMC/HVC function_id assigned for the agent transport ("arm,smc-id"), + phandle to SCMI SHM assigned for the agent transport ("arm,scmi-shmem"= ), + SCMI agent_id (optional) if not set - Xen will determine Agent ID for + each provided channel using BASE_DISCOVER_AGENT message. + +- xen,dom0-sci-agent-id + + Optional. Specifies the Dom0/hwdom SCMI agent_id inside the ``xen,sci`= ` + container. When provided, Dom0 will be configured for SCMI multi-agent + support; when omitted, SCMI remains disabled for Dom0. The value must + match the ``func_id`` and shmem pairing that EL3 firmware exposes for + Dom0 (for example via ``/firmware/scmi``). + +As an example: + +/ { + chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + + scmi_shm_0: sram@47ff0000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff0000 0x0 0x1000>; + }; + + /* Xen SCMI management channel */ + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + + scmi_shm_2: sram@47ff2000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff2000 0x0 0x1000>; + }; + + scmi_shm_3: sram@47ff3000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff3000 0x0 0x1000>; + }; + + xen,dom0-sci-agent-id =3D <0>; <--- dom0 agent id + scmi-secondary-agents =3D < + 0x82000002 &scmi_shm_0 0 + 0x82000004 &scmi_shm_2 2 + 0x82000005 &scmi_shm_3 3>; <--- func_id, shmem, agent_= id + #scmi-secondary-agents-cells =3D <3>; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; <--- Xen management agent= func_id + #address-cells =3D <1>; + #size-cells =3D <0>; + #access-controller-cells =3D <1>; + shmem =3D <&scmi_shm_1>; <--- Xen management agent shm= em + }; + }; + }; + }; +}; + +Note: This example keeps the Host DT unchanged for Dom0 and baremetal Linu= x +by using func_id 0x82000002 / shmem 0x47ff0000 for Dom0, while Xen uses a +separate privileged channel func_id 0x82000003 / shmem 0x47ff1000. EL3 +firmware enforces permissions per agent_id, so there is no conflict betwee= n +Dom0 and Xen channels. + +- #scmi-secondary-agents-cells + + Defines whether Agent_id is set in the "scmi-secondary-agents" propert= y. + Possible values are: 2, 3. + When set to 3 (the default), expect agent_id to be present in the seco= ndary + agents list. + When set to 2, agent_id will be discovered for each channel using + BASE_DISCOVER_AGENT message. + + +Example: + +/ { + chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + + /* Shared memory nodes as in the previous example */ + + scmi-secondary-agents =3D < + 0x82000002 &scmi_shm_0 + 0x82000004 &scmi_shm_2 + 0x82000005 &scmi_shm_3 + 0x82000006 &scmi_shm_4>; + #scmi-secondary-agents-cells =3D <2>; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; <--- Xen management agent= func_id + #address-cells =3D <1>; + #size-cells =3D <0>; + #access-controller-cells =3D <1>; + shmem =3D <&scmi_shm_1>; <--- Xen management agent shm= em + }; + }; + }; + }; +}; + +Dom0less example (multi-agent) +------------------------------- + +Below is a minimal dom0less configuration showing how to enable SCMI SMC +multi-agent for a pre-defined guest domain using xen,sci_type and +xen,sci-agent-id, together with the Xen SCMI container: + +chosen { + xen { + ranges; + xen_scmi_config { + compatible =3D "xen,sci"; + #address-cells =3D <2>; + #size-cells =3D <2>; + ranges; + + /* Xen management channel shared memory */ + scmi_shm_1: sram@47ff1000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff1000 0x0 0x1000>; + }; + + scmi_shm_domu: sram@47ff2000 { + compatible =3D "arm,scmi-shmem"; + reg =3D <0x0 0x47ff2000 0x0 0x1000>; + }; + + scmi-secondary-agents =3D < + 0x82000004 &scmi_shm_domu 2>; + #scmi-secondary-agents-cells =3D <3>; + + scmi_xen: scmi { + compatible =3D "arm,scmi-smc"; + arm,smc-id =3D <0x82000003>; + #address-cells =3D <1>; + #size-cells =3D <0>; + #access-controller-cells =3D <1>; + shmem =3D <&scmi_shm_1>; + }; + }; + }; + + xen,domain@1 { + compatible =3D "xen,domain"; + xen,sci_type =3D "scmi_smc_multiagent"; + xen,sci-agent-id =3D <2>; + /* Additional domain properties (memory, cpus, kernels, etc.) */ + }; +}; diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c index e4407d6e3f..be0e6263ae 100644 --- a/tools/libs/light/libxl_arm.c +++ b/tools/libs/light/libxl_arm.c @@ -240,6 +240,10 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc, case LIBXL_ARM_SCI_TYPE_SCMI_SMC: config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; break; + case LIBXL_ARM_SCI_TYPE_SCMI_SMC_MULTIAGENT: + config->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_M= A; + config->arch.arm_sci_agent_id =3D d_config->b_info.arch_arm.arm_sc= i.agent_id; + break; default: LOG(ERROR, "Unknown ARM_SCI type %d", d_config->b_info.arch_arm.arm_sci.type); diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_type= s.idl index 4a958f69f4..9bfbf09145 100644 --- a/tools/libs/light/libxl_types.idl +++ b/tools/libs/light/libxl_types.idl @@ -554,11 +554,13 @@ libxl_sve_type =3D Enumeration("sve_type", [ =20 libxl_arm_sci_type =3D Enumeration("arm_sci_type", [ (0, "none"), - (1, "scmi_smc") + (1, "scmi_smc"), + (2, "scmi_smc_multiagent") ], init_val =3D "LIBXL_ARM_SCI_TYPE_NONE") =20 libxl_arm_sci =3D Struct("arm_sci", [ ("type", libxl_arm_sci_type), + ("agent_id", uint8) ]) =20 libxl_rdm_reserve =3D Struct("rdm_reserve", [ diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c index 1cc41f1bff..0c389d25f9 100644 --- a/tools/xl/xl_parse.c +++ b/tools/xl/xl_parse.c @@ -1306,6 +1306,18 @@ static int parse_arm_sci_config(XLU_Config *cfg, lib= xl_arm_sci *arm_sci, } } =20 + if (MATCH_OPTION("agent_id", ptr, oparg)) { + unsigned long val =3D parse_ulong(oparg); + + if (!val || val > 255) { + fprintf(stderr, "An invalid ARM_SCI agent_id specified (%l= u). Valid range [1..255]\n", + val); + ret =3D ERROR_INVAL; + goto out; + } + arm_sci->agent_id =3D val; + } + ptr =3D strtok(NULL, ","); } =20 diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c index 4181c10538..ddadc89148 100644 --- a/xen/arch/arm/dom0less-build.c +++ b/xen/arch/arm/dom0less-build.c @@ -299,6 +299,17 @@ static int __init domu_dt_sci_parse(struct dt_device_n= ode *node, d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE; else if ( !strcmp(sci_type, "scmi_smc") ) d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; + else if ( !strcmp(sci_type, "scmi_smc_multiagent") ) + { + uint32_t agent_id =3D 0; + + if ( !dt_property_read_u32(node, "xen,sci-agent-id", &agent_id) || + agent_id > UINT8_MAX ) + return -EINVAL; + + d_cfg->arch.arm_sci_type =3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA= ; + d_cfg->arch.arm_sci_agent_id =3D agent_id; + } else { printk(XENLOG_ERR "xen,sci_type in not valid (%s) for domain %s\n"= , diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 986a456f17..c09f50040e 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -86,6 +86,37 @@ int __init parse_arch_dom0_param(const char *s, const ch= ar *e) return -EINVAL; } =20 +/* SCMI agent ID for dom0 obtained from xen,sci container */ +#define SCMI_AGENT_ID_INVALID UINT8_MAX + +static uint8_t __init get_dom0_scmi_agent_id(void) +{ + const struct dt_device_node *config_node; + u32 val; + const struct dt_property *prop; + + config_node =3D dt_find_compatible_node(NULL, NULL, "xen,sci"); + if ( !config_node ) + return SCMI_AGENT_ID_INVALID; + + prop =3D dt_find_property(config_node, "xen,dom0-sci-agent-id", NULL); + if ( !prop ) + return SCMI_AGENT_ID_INVALID; + + if ( !dt_property_read_u32(config_node, "xen,dom0-sci-agent-id", &val)= ) + return SCMI_AGENT_ID_INVALID; + + if ( val >=3D SCMI_AGENT_ID_INVALID ) + { + printk(XENLOG_WARNING + "Invalid xen,dom0-sci-agent-id=3D%u, SCMI disabled for Dom0\n= ", + val); + return SCMI_AGENT_ID_INVALID; + } + + return val; +} + /* Override macros from asm/page.h to make them work with mfn_t */ #undef virt_to_mfn #define virt_to_mfn(va) _mfn(__virt_to_mfn(va)) @@ -1459,6 +1490,7 @@ static int __init handle_node(struct domain *d, struc= t kernel_info *kinfo, DT_MATCH_TYPE("memory"), /* The memory mapped timer is not supported by Xen. */ DT_MATCH_COMPATIBLE("arm,armv7-timer-mem"), + DT_MATCH_COMPATIBLE("xen,sci"), { /* sentinel */ }, }; static const struct dt_device_match timer_matches[] __initconst =3D @@ -1947,6 +1979,13 @@ void __init create_dom0(void) dom0_cfg.arch.tee_type =3D tee_get_type(); dom0_cfg.max_vcpus =3D dom0_max_vcpus(); =20 + /* Set up SCMI agent ID if provided in the xen,sci container */ + dom0_cfg.arch.arm_sci_agent_id =3D get_dom0_scmi_agent_id(); + dom0_cfg.arch.arm_sci_type =3D (dom0_cfg.arch.arm_sci_agent_id !=3D + SCMI_AGENT_ID_INVALID) ? + XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA : + XEN_DOMCTL_CONFIG_ARM_SCI_NONE; + if ( iommu_enabled ) dom0_cfg.flags |=3D XEN_DOMCTL_CDF_iommu; =20 diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig index 5c5f0880c4..972cd9b173 100644 --- a/xen/arch/arm/firmware/Kconfig +++ b/xen/arch/arm/firmware/Kconfig @@ -29,6 +29,18 @@ config SCMI_SMC driver domain. Use with EL3 firmware which supports only single SCMI OSPM agent. =20 +config SCMI_SMC_MA + bool "Enable ARM SCMI SMC multi-agent driver" + depends on ARM_64 + select ARM_SCI + help + Enables SCMI SMC/HVC multi-agent in XEN to pass SCMI requests from Doma= ins + to EL3 firmware (TF-A) which supports multi-agent feature. + This feature allows to enable SCMI per Domain using unique SCMI agent_i= d, + so Domain is identified by EL3 firmware as an SCMI Agent and can access + allowed platform resources through dedicated SMC/HVC Shared memory base= d + transport. + endchoice =20 endmenu diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefil= e index 71bdefc24a..37927e690e 100644 --- a/xen/arch/arm/firmware/Makefile +++ b/xen/arch/arm/firmware/Makefile @@ -1,2 +1,3 @@ obj-$(CONFIG_ARM_SCI) +=3D sci.o obj-$(CONFIG_SCMI_SMC) +=3D scmi-smc.o +obj-$(CONFIG_SCMI_SMC_MA) +=3D scmi-shmem.o scmi-smc-multiagent.o diff --git a/xen/arch/arm/firmware/scmi-proto.h b/xen/arch/arm/firmware/scm= i-proto.h new file mode 100644 index 0000000000..49f63cfc0a --- /dev/null +++ b/xen/arch/arm/firmware/scmi-proto.h @@ -0,0 +1,164 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Arm System Control and Management Interface definitions + * Version 3.0 (DEN0056C) + * + * Copyright (c) 2025 EPAM Systems + */ + +#ifndef ARM_FIRMWARE_SCMI_PROTO_H_ +#define ARM_FIRMWARE_SCMI_PROTO_H_ + +#include + +#define SCMI_SHORT_NAME_MAX_SIZE 16 + +/* SCMI status codes. See section 4.1.4 */ +#define SCMI_SUCCESS 0 +#define SCMI_NOT_SUPPORTED (-1) +#define SCMI_INVALID_PARAMETERS (-2) +#define SCMI_DENIED (-3) +#define SCMI_NOT_FOUND (-4) +#define SCMI_OUT_OF_RANGE (-5) +#define SCMI_BUSY (-6) +#define SCMI_COMMS_ERROR (-7) +#define SCMI_GENERIC_ERROR (-8) +#define SCMI_HARDWARE_ERROR (-9) +#define SCMI_PROTOCOL_ERROR (-10) + +/* Protocol IDs */ +#define SCMI_BASE_PROTOCOL 0x10 + +/* Base protocol message IDs */ +#define SCMI_BASE_PROTOCOL_VERSION 0x0 +#define SCMI_BASE_PROTOCOL_ATTIBUTES 0x1 +#define SCMI_BASE_PROTOCOL_MESSAGE_ATTRIBUTES 0x2 +#define SCMI_BASE_DISCOVER_AGENT 0x7 +#define SCMI_BASE_SET_DEVICE_PERMISSIONS 0x9 +#define SCMI_BASE_RESET_AGENT_CONFIGURATION 0xB + +typedef struct scmi_msg_header { + uint8_t id; + uint8_t type; + uint8_t protocol; + uint32_t status; +} scmi_msg_header_t; + +/* Table 2 Message header format */ +#define SCMI_HDR_ID GENMASK(7, 0) +#define SCMI_HDR_TYPE GENMASK(9, 8) +#define SCMI_HDR_PROTO GENMASK(17, 10) + +#define SCMI_FIELD_GET(_mask, _reg) = \ + ((typeof(_mask))(((_reg) & (_mask)) >> (ffs64(_mask) - 1))) +#define SCMI_FIELD_PREP(_mask, _val) = \ + (((typeof(_mask))(_val) << (ffs64(_mask) - 1)) & (_mask)) + +static inline uint32_t pack_scmi_header(scmi_msg_header_t *hdr) +{ + return SCMI_FIELD_PREP(SCMI_HDR_ID, hdr->id) | + SCMI_FIELD_PREP(SCMI_HDR_TYPE, hdr->type) | + SCMI_FIELD_PREP(SCMI_HDR_PROTO, hdr->protocol); +} + +static inline void unpack_scmi_header(uint32_t msg_hdr, scmi_msg_header_t = *hdr) +{ + hdr->id =3D SCMI_FIELD_GET(SCMI_HDR_ID, msg_hdr); + hdr->type =3D SCMI_FIELD_GET(SCMI_HDR_TYPE, msg_hdr); + hdr->protocol =3D SCMI_FIELD_GET(SCMI_HDR_PROTO, msg_hdr); +} + +static inline int scmi_to_xen_errno(int scmi_status) +{ + if ( scmi_status =3D=3D SCMI_SUCCESS ) + return 0; + + switch ( scmi_status ) + { + case SCMI_NOT_SUPPORTED: + return -EOPNOTSUPP; + case SCMI_INVALID_PARAMETERS: + return -EINVAL; + case SCMI_DENIED: + return -EACCES; + case SCMI_NOT_FOUND: + return -ENOENT; + case SCMI_OUT_OF_RANGE: + return -ERANGE; + case SCMI_BUSY: + return -EBUSY; + case SCMI_COMMS_ERROR: + return -ENOTCONN; + case SCMI_GENERIC_ERROR: + return -EIO; + case SCMI_HARDWARE_ERROR: + return -ENXIO; + case SCMI_PROTOCOL_ERROR: + return -EBADMSG; + default: + return -EINVAL; + } +} + +/* PROTOCOL_VERSION */ +#define SCMI_VERSION_MINOR GENMASK(15, 0) +#define SCMI_VERSION_MAJOR GENMASK(31, 16) + +struct scmi_msg_prot_version_p2a { + uint32_t version; +} __packed; + +/* BASE PROTOCOL_ATTRIBUTES */ +#define SCMI_BASE_ATTR_NUM_PROTO GENMASK(7, 0) +#define SCMI_BASE_ATTR_NUM_AGENT GENMASK(15, 8) + +struct scmi_msg_base_attributes_p2a { + uint32_t attributes; +} __packed; + +/* + * BASE_DISCOVER_AGENT + */ +#define SCMI_BASE_AGENT_ID_OWN 0xFFFFFFFF + +struct scmi_msg_base_discover_agent_a2p { + uint32_t agent_id; +} __packed; + +struct scmi_msg_base_discover_agent_p2a { + uint32_t agent_id; + char name[SCMI_SHORT_NAME_MAX_SIZE]; +} __packed; + +/* + * BASE_SET_DEVICE_PERMISSIONS + */ +#define SCMI_BASE_DEVICE_ACCESS_ALLOW BIT(0, UL) + +struct scmi_msg_base_set_device_permissions_a2p { + uint32_t agent_id; + uint32_t device_id; + uint32_t flags; +} __packed; + +/* + * BASE_RESET_AGENT_CONFIGURATION + */ +#define SCMI_BASE_AGENT_PERMISSIONS_RESET BIT(0, UL) + +struct scmi_msg_base_reset_agent_cfg_a2p { + uint32_t agent_id; + uint32_t flags; +} __packed; + +#endif /* ARM_FIRMWARE_SCMI_PROTO_H_ */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/firmware/scmi-shmem.c b/xen/arch/arm/firmware/scm= i-shmem.c new file mode 100644 index 0000000000..6683e62544 --- /dev/null +++ b/xen/arch/arm/firmware/scmi-shmem.c @@ -0,0 +1,115 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * SMC/HVC shmem transport implementation used by + * SCI SCMI multi-agent driver. + * + * Oleksii Moisieiev + * Copyright (c) 2025 EPAM Systems + */ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include +#include +#include + +#include "scmi-proto.h" +#include "scmi-shmem.h" + +static inline int +shmem_channel_is_free(const volatile struct scmi_shared_mem __iomem *shmem= ) +{ + return (readl(&shmem->channel_status) & + SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE) ? 0 : -EBUSY; +} + +int shmem_put_message(volatile struct scmi_shared_mem __iomem *shmem, + scmi_msg_header_t *hdr, void *data, int len) +{ + int ret; + + if ( (len + offsetof(struct scmi_shared_mem, msg_payload)) > + SCMI_SHMEM_MAPPED_SIZE ) + { + printk(XENLOG_ERR "scmi: Wrong size of smc message. Data is invali= d\n"); + return -EINVAL; + } + + ret =3D shmem_channel_is_free(shmem); + if ( ret ) + return ret; + + writel_relaxed(0x0, &shmem->channel_status); + /* Writing 0x0 right now, but "shmem"_FLAG_INTR_ENABLED can be set */ + writel_relaxed(0x0, &shmem->flags); + writel_relaxed(sizeof(shmem->msg_header) + len, &shmem->length); + writel(pack_scmi_header(hdr), &shmem->msg_header); + + if ( len > 0 && data ) + memcpy_toio(shmem->msg_payload, data, len); + + return 0; +} + +int shmem_get_response(const volatile struct scmi_shared_mem __iomem *shme= m, + scmi_msg_header_t *hdr, void *data, int len) +{ + int recv_len; + int ret; + int pad =3D sizeof(hdr->status); + + if ( len >=3D SCMI_SHMEM_MAPPED_SIZE - + offsetof(struct scmi_shared_mem, msg_payload) ) + { + printk(XENLOG_ERR + "scmi: Wrong size of input smc message. Data may be invalid= \n"); + return -EINVAL; + } + + ret =3D shmem_channel_is_free(shmem); + if ( ret ) + return ret; + + recv_len =3D readl(&shmem->length) - sizeof(shmem->msg_header); + + if ( recv_len < 0 ) + { + printk(XENLOG_ERR + "scmi: Wrong size of smc message. Data may be invalid\n"); + return -EINVAL; + } + + unpack_scmi_header(readl(&shmem->msg_header), hdr); + + hdr->status =3D readl(&shmem->msg_payload); + recv_len =3D recv_len > pad ? recv_len - pad : 0; + + ret =3D scmi_to_xen_errno(hdr->status); + if ( ret ) + { + printk(XENLOG_DEBUG "scmi: Error received: %d\n", ret); + return ret; + } + + if ( recv_len > len ) + { + printk(XENLOG_ERR + "scmi: Not enough buffer for message %d, expecting %d\n", + recv_len, len); + return -EINVAL; + } + + if ( recv_len > 0 ) + memcpy_fromio(data, shmem->msg_payload + pad, recv_len); + + return 0; +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/firmware/scmi-shmem.h b/xen/arch/arm/firmware/scm= i-shmem.h new file mode 100644 index 0000000000..7313cb6b26 --- /dev/null +++ b/xen/arch/arm/firmware/scmi-shmem.h @@ -0,0 +1,45 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Arm System Control and Management Interface definitions + * Version 3.0 (DEN0056C) + * Shared Memory based Transport + * + * Copyright (c) 2024 EPAM Systems + */ + +#ifndef ARM_FIRMWARE_SCMI_SHMEM_H_ +#define ARM_FIRMWARE_SCMI_SHMEM_H_ + +#include + +#define SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE BIT(0, UL) +#define SCMI_SHMEM_CHAN_STAT_CHANNEL_ERROR BIT(1, UL) + +struct scmi_shared_mem { + uint32_t reserved; + uint32_t channel_status; + uint32_t reserved1[2]; + uint32_t flags; + uint32_t length; + uint32_t msg_header; + uint8_t msg_payload[]; +}; + +#define SCMI_SHMEM_MAPPED_SIZE PAGE_SIZE + +int shmem_put_message(volatile struct scmi_shared_mem __iomem *shmem, + scmi_msg_header_t *hdr, void *data, int len); + +int shmem_get_response(const volatile struct scmi_shared_mem __iomem *shme= m, + scmi_msg_header_t *hdr, void *data, int len); +#endif /* ARM_FIRMWARE_SCMI_SHMEM_H_ */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/arm/firmware/scmi-smc-multiagent.c b/xen/arch/arm/fir= mware/scmi-smc-multiagent.c new file mode 100644 index 0000000000..339c45f285 --- /dev/null +++ b/xen/arch/arm/firmware/scmi-smc-multiagent.c @@ -0,0 +1,818 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * SCI SCMI multi-agent driver, using SMC/HVC shmem as transport. + * + * Oleksii Moisieiev + * Copyright (c) 2025 EPAM Systems + */ + +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include "scmi-proto.h" +#include "scmi-shmem.h" + +#define SCMI_SECONDARY_AGENTS "scmi-secondary-agents" + +struct scmi_channel { + uint32_t agent_id; + uint32_t func_id; + domid_t domain_id; + uint64_t paddr; + struct scmi_shared_mem __iomem *shmem; + spinlock_t lock; + struct list_head list; +}; + +struct scmi_data { + struct list_head channel_list; + spinlock_t channel_list_lock; + uint32_t func_id; + bool initialized; + uint32_t shmem_phandle; + uint32_t hyp_channel_agent_id; + struct dt_device_node *dt_dev; +}; + +static struct scmi_data scmi_data; + +static bool scmi_is_under_xen_sci(const struct dt_device_node *node) +{ + const struct dt_device_node *p; + + for ( p =3D node->parent; p; p =3D p->parent ) + if ( dt_device_is_compatible(p, "xen,sci") ) + return true; + + return false; +} + +static int send_smc_message(struct scmi_channel *chan_info, + scmi_msg_header_t *hdr, void *data, int len) +{ + struct arm_smccc_res resp; + int ret; + + ret =3D shmem_put_message(chan_info->shmem, hdr, data, len); + if ( ret ) + return ret; + + arm_smccc_1_1_smc(chan_info->func_id, 0, 0, 0, 0, 0, 0, 0, &resp); + + if ( resp.a0 =3D=3D ARM_SMCCC_INVALID_PARAMETER ) + return -EINVAL; + + if ( resp.a0 ) + return -EOPNOTSUPP; + + return 0; +} + +static int do_smc_xfer(struct scmi_channel *chan_info, scmi_msg_header_t *= hdr, + void *tx_data, int tx_size, void *rx_data, int rx_s= ize) +{ + int ret =3D 0; + + ASSERT(chan_info && chan_info->shmem); + + if ( !hdr ) + return -EINVAL; + + spin_lock(&chan_info->lock); + + printk(XENLOG_DEBUG + "scmi: agent_id =3D %d msg_id =3D %x type =3D %d, proto =3D %x\= n", + chan_info->agent_id, hdr->id, hdr->type, hdr->protocol); + + ret =3D send_smc_message(chan_info, hdr, tx_data, tx_size); + if ( ret ) + goto clean; + + ret =3D shmem_get_response(chan_info->shmem, hdr, rx_data, rx_size); + +clean: + printk(XENLOG_DEBUG + "scmi: get smc response agent_id =3D %d msg_id =3D %x proto =3D= %x res=3D%d\n", + chan_info->agent_id, hdr->id, hdr->protocol, ret); + + spin_unlock(&chan_info->lock); + + return ret; +} + +static struct scmi_channel *get_channel_by_id(uint32_t agent_id) +{ + struct scmi_channel *curr; + bool found =3D false; + + spin_lock(&scmi_data.channel_list_lock); + list_for_each_entry(curr, &scmi_data.channel_list, list) + { + if ( curr->agent_id =3D=3D agent_id ) + { + found =3D true; + break; + } + } + + spin_unlock(&scmi_data.channel_list_lock); + if ( found ) + return curr; + + return NULL; +} + +static struct scmi_channel *acquire_scmi_channel(struct domain *d, + uint32_t agent_id) +{ + struct scmi_channel *curr; + struct scmi_channel *ret =3D ERR_PTR(-ENOENT); + + spin_lock(&scmi_data.channel_list_lock); + list_for_each_entry(curr, &scmi_data.channel_list, list) + { + if ( curr->agent_id =3D=3D agent_id ) + { + if ( curr->domain_id !=3D DOMID_INVALID ) + { + ret =3D ERR_PTR(-EEXIST); + break; + } + + curr->domain_id =3D d->domain_id; + ret =3D curr; + break; + } + } + + spin_unlock(&scmi_data.channel_list_lock); + + return ret; +} + +static void relinquish_scmi_channel(struct scmi_channel *channel) +{ + ASSERT(channel !=3D NULL); + + spin_lock(&scmi_data.channel_list_lock); + channel->domain_id =3D DOMID_INVALID; + spin_unlock(&scmi_data.channel_list_lock); +} + +static int map_channel_memory(struct scmi_channel *channel) +{ + ASSERT(channel && channel->paddr); + channel->shmem =3D ioremap_nocache(channel->paddr, SCMI_SHMEM_MAPPED_S= IZE); + if ( !channel->shmem ) + return -ENOMEM; + + channel->shmem->channel_status =3D SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE; + printk(XENLOG_DEBUG "scmi: Got shmem %lx after vmap %p\n", channel->pa= ddr, + channel->shmem); + + return 0; +} + +static void unmap_channel_memory(struct scmi_channel *channel) +{ + ASSERT(channel); + + if ( !channel->shmem ) + return; + + iounmap(channel->shmem); + channel->shmem =3D NULL; +} + +static struct scmi_channel *smc_create_channel(uint32_t agent_id, + uint32_t func_id, uint64_t = addr) +{ + struct scmi_channel *channel, *curr; + + spin_lock(&scmi_data.channel_list_lock); + + /* Check if channel already exists while holding the lock */ + list_for_each_entry(curr, &scmi_data.channel_list, list) + { + if ( curr->agent_id =3D=3D agent_id ) + { + spin_unlock(&scmi_data.channel_list_lock); + return ERR_PTR(-EEXIST); + } + } + + channel =3D xmalloc(struct scmi_channel); + if ( !channel ) + { + spin_unlock(&scmi_data.channel_list_lock); + return ERR_PTR(-ENOMEM); + } + + spin_lock_init(&channel->lock); + channel->agent_id =3D agent_id; + channel->func_id =3D func_id; + channel->domain_id =3D DOMID_INVALID; + channel->shmem =3D NULL; + channel->paddr =3D addr; + list_add_tail(&channel->list, &scmi_data.channel_list); + + spin_unlock(&scmi_data.channel_list_lock); + return channel; +} + +static void free_channel_list(void) +{ + struct scmi_channel *curr, *_curr; + + list_for_each_entry_safe(curr, _curr, &scmi_data.channel_list, list) + { + list_del(&curr->list); + xfree(curr); + } +} + +static int __init +scmi_dt_read_hyp_channel_addr(struct dt_device_node *scmi_node, u64 *addr, + u64 *size) +{ + struct dt_device_node *shmem_node; + const __be32 *prop; + + prop =3D dt_get_property(scmi_node, "shmem", NULL); + if ( !prop ) + return -EINVAL; + + shmem_node =3D dt_find_node_by_phandle(be32_to_cpu(*prop)); + if ( IS_ERR_OR_NULL(shmem_node) ) + { + printk(XENLOG_ERR + "scmi: Device tree error, can't parse reserved memory %ld\n= ", + PTR_ERR(shmem_node)); + return PTR_ERR(shmem_node); + } + + return dt_device_get_address(shmem_node, 0, addr, size); +} + +/* + * Handle Dom0 SCMI specific DT nodes + * + * Make a decision on copying SCMI specific nodes into Dom0 device tree. + * For SCMI multi-agent case: + * - shmem nodes will not be copied and generated instead if SCMI + * is enabled for Dom0 + * - scmi node will be copied if SCMI is enabled for Dom0 + */ +static bool scmi_dt_handle_node(struct domain *d, struct dt_device_node *n= ode) +{ + 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 */ }, + }; + + if ( !scmi_data.initialized ) + return false; + + /* 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; + } + + /* drop scmi if not enabled */ + if ( dt_match_node(scmi_matches, node) && !sci_domain_is_enabled(d) ) + { + dt_dprintk(" Skip scmi node\n"); + return true; + } + + return false; +} + +static int scmi_assign_device(uint32_t agent_id, uint32_t device_id, + uint32_t flags) +{ + struct scmi_msg_base_set_device_permissions_a2p tx; + struct scmi_channel *channel; + scmi_msg_header_t hdr; + + channel =3D get_channel_by_id(scmi_data.hyp_channel_agent_id); + if ( !channel ) + return -EINVAL; + + hdr.id =3D SCMI_BASE_SET_DEVICE_PERMISSIONS; + hdr.type =3D 0; + hdr.protocol =3D SCMI_BASE_PROTOCOL; + + tx.agent_id =3D agent_id; + tx.device_id =3D device_id; + tx.flags =3D flags; + + return do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0); +} + +static int scmi_dt_assign_device(struct domain *d, + struct dt_phandle_args *ac_spec) +{ + struct scmi_channel *agent_channel; + uint32_t scmi_device_id =3D ac_spec->args[0]; + int ret; + + if ( !d->arch.sci_data ) + return 0; + + /* The access-controllers is specified for DT dev, but it's not a SCMI= */ + if ( !scmi_data.dt_dev || + !dt_node_path_is_equal(ac_spec->np, scmi_data.dt_dev->full_name) = ) + return 0; + + agent_channel =3D d->arch.sci_data; + + spin_lock(&agent_channel->lock); + + ret =3D scmi_assign_device(agent_channel->agent_id, scmi_device_id, + SCMI_BASE_DEVICE_ACCESS_ALLOW); + if ( ret ) + { + printk(XENLOG_ERR + "scmi: could not assign dev for %pd agent:%d dev_id:%u (%d)= ", + d, agent_channel->agent_id, scmi_device_id, ret); + } + + spin_unlock(&agent_channel->lock); + return ret; +} + +static int collect_agent_id(struct scmi_channel *agent_channel) +{ + int ret; + scmi_msg_header_t hdr; + struct scmi_msg_base_discover_agent_p2a da_rx; + struct scmi_msg_base_discover_agent_a2p da_tx; + + ret =3D map_channel_memory(agent_channel); + if ( ret ) + return ret; + + hdr.id =3D SCMI_BASE_DISCOVER_AGENT; + hdr.type =3D 0; + hdr.protocol =3D SCMI_BASE_PROTOCOL; + + da_tx.agent_id =3D agent_channel->agent_id; + + ret =3D do_smc_xfer(agent_channel, &hdr, &da_tx, sizeof(da_tx), &da_rx= , + sizeof(da_rx)); + if ( agent_channel->domain_id !=3D DOMID_XEN ) + unmap_channel_memory(agent_channel); + if ( ret ) + return ret; + + printk(XENLOG_DEBUG "id=3D0x%x name=3D%s\n", da_rx.agent_id, da_rx.nam= e); + agent_channel->agent_id =3D da_rx.agent_id; + return 0; +} + +static __init int collect_agents(struct dt_device_node *scmi_node) +{ + const struct dt_device_node *config_node; + const __be32 *prop; + uint32_t len; + const __be32 *end; + uint32_t cells_per_entry =3D 3; /* Default to 3 cells if property is a= bsent. */ + + config_node =3D dt_find_compatible_node(NULL, NULL, "xen,sci"); + if ( !config_node ) + { + printk(XENLOG_WARNING "scmi: xen,sci node not found, no agents to = collect.\n"); + return -ENOENT; + } + + /* Check for the optional '#scmi-secondary-agents-cells' property. */ + if ( dt_property_read_u32(config_node, "#scmi-secondary-agents-cells", + &cells_per_entry) ) + { + if ( cells_per_entry !=3D 2 && cells_per_entry !=3D 3 ) + { + printk(XENLOG_ERR "scmi: Invalid #scmi-secondary-agents-cells = value: %u\n", + cells_per_entry); + return -EINVAL; + } + } + + prop =3D dt_get_property(config_node, SCMI_SECONDARY_AGENTS, &len); + if ( !prop ) + { + printk(XENLOG_ERR "scmi: No %s property found, no agents to collec= t.\n", + SCMI_SECONDARY_AGENTS); + return -EINVAL; + } + + /* Validate that the property length is a multiple of the cell size. *= / + if ( len =3D=3D 0 || len % (cells_per_entry * sizeof(uint32_t)) !=3D 0= ) + { + printk(XENLOG_ERR "scmi: Invalid length of %s property: %u for %u = cells per entry\n", + SCMI_SECONDARY_AGENTS, len, cells_per_entry); + return -EINVAL; + } + + end =3D (const __be32 *)((const u8 *)prop + len); + + for ( ; prop < end; ) + { + uint32_t agent_id; + uint32_t smc_id; + uint32_t shmem_phandle; + struct dt_device_node *node; + u64 addr, size; + int ret; + struct scmi_channel *agent_channel; + + smc_id =3D be32_to_cpu(*prop++); + shmem_phandle =3D be32_to_cpu(*prop++); + + if ( cells_per_entry =3D=3D 3 ) + agent_id =3D be32_to_cpu(*prop++); + else + agent_id =3D SCMI_BASE_AGENT_ID_OWN; + + node =3D dt_find_node_by_phandle(shmem_phandle); + if ( !node ) + { + printk(XENLOG_ERR "scmi: Could not find shmem node for agent %= u\n", + agent_id); + return -EINVAL; + } + + ret =3D dt_device_get_address(node, 0, &addr, &size); + if ( ret ) + { + printk(XENLOG_ERR + "scmi: Could not read shmem address for agent %u: %d\n"= , + agent_id, ret); + return ret; + } + + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) ) + { + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); + return -EINVAL; + } + + agent_channel =3D smc_create_channel(agent_id, smc_id, addr); + if ( IS_ERR(agent_channel) ) + { + printk(XENLOG_ERR "scmi: Could not create channel for agent %u= : %ld\n", + agent_id, PTR_ERR(agent_channel)); + return PTR_ERR(agent_channel); + } + + if ( cells_per_entry =3D=3D 2 ) + { + ret =3D collect_agent_id(agent_channel); + if ( ret ) + return ret; + } + + printk(XENLOG_DEBUG "scmi: Agent %u SMC %X addr %lx\n", agent_chan= nel->agent_id, + smc_id, (unsigned long)addr); + } + + return 0; +} + +static int scmi_domain_init(struct domain *d, + struct xen_domctl_createdomain *config) +{ + struct scmi_channel *channel; + int ret; + + if ( !scmi_data.initialized ) + return 0; + + /* + * SCMI support is configured via: + * - For dom0: xen,dom0-sci-agent-id property under the xen,sci contai= ner + * - For dom0less: xen,sci-agent-id in the domain node + * The config->arch.arm_sci_type and config->arch.arm_sci_agent_id + * are already set by domain_build.c or dom0less-build.c + */ + + if ( config->arch.arm_sci_type =3D=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE ) + return 0; + + channel =3D acquire_scmi_channel(d, config->arch.arm_sci_agent_id); + if ( IS_ERR(channel) ) + { + printk(XENLOG_ERR + "scmi: Failed to acquire SCMI channel for agent_id %u: %ld\= n", + config->arch.arm_sci_agent_id, PTR_ERR(channel)); + return PTR_ERR(channel); + } + + printk(XENLOG_INFO + "scmi: Acquire channel id =3D 0x%x, domain_id =3D %d paddr =3D = 0x%lx\n", + channel->agent_id, channel->domain_id, channel->paddr); + + /* + * Dom0 (if present) needs to have an access to the guest memory range + * to satisfy iomem_access_permitted() check in XEN_DOMCTL_iomem_permi= ssion + * domctl. + */ + if ( hardware_domain && !is_hardware_domain(d) ) + { + ret =3D iomem_permit_access(hardware_domain, paddr_to_pfn(channel-= >paddr), + paddr_to_pfn(channel->paddr + PAGE_SIZE = - 1)); + if ( ret ) + goto error; + } + + d->arch.sci_data =3D channel; + d->arch.sci_enabled =3D true; + + return 0; + +error: + relinquish_scmi_channel(channel); + return ret; +} + +int scmi_domain_sanitise_config(struct xen_domctl_createdomain *config) +{ + if ( config->arch.arm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_NONE && + config->arch.arm_sci_type !=3D XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC= _MA ) + { + dprintk(XENLOG_INFO, "scmi: Unsupported ARM_SCI type\n"); + return -EINVAL; + } + + return 0; +} + +static int scmi_relinquish_resources(struct domain *d) +{ + int ret; + struct scmi_channel *channel, *agent_channel; + scmi_msg_header_t hdr; + struct scmi_msg_base_reset_agent_cfg_a2p tx; + + if ( !d->arch.sci_data ) + return 0; + + agent_channel =3D d->arch.sci_data; + + spin_lock(&agent_channel->lock); + tx.agent_id =3D agent_channel->agent_id; + spin_unlock(&agent_channel->lock); + + channel =3D get_channel_by_id(scmi_data.hyp_channel_agent_id); + if ( !channel ) + { + printk(XENLOG_ERR + "scmi: Unable to get Hypervisor scmi channel for domain %d\= n", + d->domain_id); + return -EINVAL; + } + + hdr.id =3D SCMI_BASE_RESET_AGENT_CONFIGURATION; + hdr.type =3D 0; + hdr.protocol =3D SCMI_BASE_PROTOCOL; + + tx.flags =3D SCMI_BASE_AGENT_PERMISSIONS_RESET; + + ret =3D do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0); + if ( ret =3D=3D -EOPNOTSUPP ) + return 0; + + return ret; +} + +static void scmi_domain_destroy(struct domain *d) +{ + struct scmi_channel *channel; + + if ( !d->arch.sci_data ) + return; + + channel =3D d->arch.sci_data; + spin_lock(&channel->lock); + + relinquish_scmi_channel(channel); + printk(XENLOG_DEBUG "scmi: Free domain %d\n", d->domain_id); + + d->arch.sci_data =3D NULL; + d->arch.sci_enabled =3D false; + + spin_unlock(&channel->lock); +} + +static bool scmi_handle_call(struct cpu_user_regs *regs) +{ + uint32_t fid =3D (uint32_t)get_user_reg(regs, 0); + struct scmi_channel *agent_channel; + struct domain *d =3D current->domain; + struct arm_smccc_res resp; + bool res =3D false; + + if ( !sci_domain_is_enabled(d) ) + return false; + + agent_channel =3D d->arch.sci_data; + spin_lock(&agent_channel->lock); + + if ( agent_channel->func_id !=3D fid ) + { + res =3D false; + goto unlock; + } + + arm_smccc_1_1_smc(fid, + get_user_reg(regs, 1), + get_user_reg(regs, 2), + get_user_reg(regs, 3), + get_user_reg(regs, 4), + get_user_reg(regs, 5), + get_user_reg(regs, 6), + get_user_reg(regs, 7), + &resp); + + set_user_reg(regs, 0, resp.a0); + set_user_reg(regs, 1, resp.a1); + set_user_reg(regs, 2, resp.a2); + set_user_reg(regs, 3, resp.a3); + res =3D true; +unlock: + spin_unlock(&agent_channel->lock); + + return res; +} + +static const struct sci_mediator_ops scmi_ops =3D { + .domain_init =3D scmi_domain_init, + .domain_destroy =3D scmi_domain_destroy, + .relinquish_resources =3D scmi_relinquish_resources, + .handle_call =3D scmi_handle_call, + .dom0_dt_handle_node =3D scmi_dt_handle_node, + .domain_sanitise_config =3D scmi_domain_sanitise_config, + .assign_dt_device =3D scmi_dt_assign_device, +}; + +static int __init scmi_check_smccc_ver(void) +{ + if ( smccc_ver < ARM_SMCCC_VERSION_1_1 ) + { + printk(XENLOG_WARNING + "scmi: No SMCCC 1.1 support, SCMI calls forwarding disabled= \n"); + return -ENOSYS; + } + + return 0; +} + +static int __init scmi_dt_hyp_channel_read(struct dt_device_node *scmi_nod= e, + struct scmi_data *scmi_data, + u64 *addr) +{ + int ret; + u64 size; + + if ( !dt_property_read_u32(scmi_node, "arm,smc-id", &scmi_data->func_i= d) ) + { + printk(XENLOG_ERR "scmi: unable to read smc-id from DT\n"); + return -ENOENT; + } + + ret =3D scmi_dt_read_hyp_channel_addr(scmi_node, addr, &size); + if ( IS_ERR_VALUE(ret) ) + return -ENOENT; + + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) ) + { + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); + return -EINVAL; + } + + return 0; +} + +static __init int scmi_probe(struct dt_device_node *scmi_node, const void = *data) +{ + u64 addr; + int ret; + struct scmi_channel *channel; + unsigned int n_agents; + scmi_msg_header_t hdr; + struct scmi_msg_base_attributes_p2a rx; + + ASSERT(scmi_node !=3D NULL); + + /* + * Only bind to the SCMI node provided by Xen under the xen,sci contai= ner + * (e.g. /chosen/xen/xen_scmi_config/scmi). This avoids binding to fir= mware + * SCMI nodes that belong to the host OSPM and keeps the mediator scop= ed to + * Xen-provided configuration only. + */ + if ( !scmi_is_under_xen_sci(scmi_node) ) + return -ENODEV; + + INIT_LIST_HEAD(&scmi_data.channel_list); + spin_lock_init(&scmi_data.channel_list_lock); + + if ( !acpi_disabled ) + { + printk(XENLOG_WARNING "scmi: is not supported when using ACPI\n"); + return -EINVAL; + } + + ret =3D scmi_check_smccc_ver(); + if ( ret ) + return ret; + + ret =3D scmi_dt_hyp_channel_read(scmi_node, &scmi_data, &addr); + if ( ret ) + return ret; + + scmi_data.dt_dev =3D scmi_node; + + channel =3D smc_create_channel(SCMI_BASE_AGENT_ID_OWN, scmi_data.func_= id, addr); + if ( IS_ERR(channel) ) + goto out; + + /* Mark as Xen management channel before collecting agent ID */ + channel->domain_id =3D DOMID_XEN; + + /* Request agent id for Xen management channel */ + ret =3D collect_agent_id(channel); + if ( ret ) + goto error; + + /* Save the agent id for Xen management channel */ + scmi_data.hyp_channel_agent_id =3D channel->agent_id; + + hdr.id =3D SCMI_BASE_PROTOCOL_ATTIBUTES; + hdr.type =3D 0; + hdr.protocol =3D SCMI_BASE_PROTOCOL; + + ret =3D do_smc_xfer(channel, &hdr, NULL, 0, &rx, sizeof(rx)); + if ( ret ) + goto error; + + n_agents =3D SCMI_FIELD_GET(SCMI_BASE_ATTR_NUM_AGENT, rx.attributes); + printk(XENLOG_DEBUG "scmi: Got agent count %d\n", n_agents); + ret =3D collect_agents(scmi_node); + if ( ret ) + goto error; + + ret =3D sci_register(&scmi_ops); + if ( ret ) + { + printk(XENLOG_ERR "SCMI: mediator already registered (ret =3D %d)\= n", + ret); + return ret; + } + + scmi_data.initialized =3D true; + goto out; + +error: + unmap_channel_memory(channel); + free_channel_list(); +out: + return ret; +} + +static const struct dt_device_match scmi_smc_match[] __initconst =3D { + DT_MATCH_COMPATIBLE("arm,scmi-smc"), + { /* sentinel */ }, +}; + +DT_DEVICE_START(scmi_smc_ma, "SCMI SMC MEDIATOR", DEVICE_FIRMWARE) + .dt_match =3D scmi_smc_match, + .init =3D scmi_probe, +DT_DEVICE_END + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h index d30a288592..8f0f68544e 100644 --- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -329,6 +329,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); =20 #define XEN_DOMCTL_CONFIG_ARM_SCI_NONE 0 #define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC 1 +#define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA 2 =20 struct xen_arch_domainconfig { /* IN/OUT */ @@ -355,6 +356,8 @@ struct xen_arch_domainconfig { uint32_t clock_frequency; /* IN */ uint8_t arm_sci_type; + /* IN */ + uint8_t arm_sci_agent_id; }; #endif /* __XEN__ || __XEN_TOOLS__ */ =20 --=20 2.34.1 From xen-devel-bounces@lists.xenproject.org Thu Jan 29 14:24:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 14:24:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216622.1526569 (Exim 4.92) (envelope-from ) id 1vlSwc-0005Le-UJ; Thu, 29 Jan 2026 14:24:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216622.1526569; Thu, 29 Jan 2026 14:24:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlSwc-0005LX-RD; Thu, 29 Jan 2026 14:24:26 +0000 Received: by outflank-mailman (input) for mailman id 1216622; Thu, 29 Jan 2026 14: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 1vlSwa-0005LI-Mt for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 14:24:24 +0000 Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [2a00:1450:4864:20::444]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 35893b88-fd1e-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 15:24:23 +0100 (CET) Received: by mail-wr1-x444.google.com with SMTP id ffacd0b85a97d-42fb5810d39so743727f8f.2 for ; Thu, 29 Jan 2026 06:24:23 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e1048a54sm14044408f8f.0.2026.01.29.06.24.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 06:24:23 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 35893b88-fd1e-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769696663; x=1770301463; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=yUks7eNetVwpKzfbiYWPmagkxOdBNqngs8+VH2ernxM=; b=LiFx18wlJ+ortDmrcxFy2utVl+KPbgBxy5nL+oyV0ksoAQXYf9iv3wStscX4VlZUEA YQj+kQqME+vJ0nlzDGut8y2AKQCuSpms1NxyVP6GHfsnPyjspQybaR2IDp4HMekaKiCE ee4QmNpwzCT1uGA68+r5mgZAU2ZhSWXsRgrpyp2DqtM0erL4UlFba2lioZi2GujHkFj1 cnKbvn0laIyBCmkcpJWRjtYyjw2FpXWiLEyYRkYl0zdR1DgOzYRgnSR3uBFrZGpYhYV1 CiKKWjNmnIZXxCiYF1NkZg1Z1v+UwZkswfD9sDqyRfk1kNE2FXOEyY4UmNni8VF8CWzI 8uMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769696663; x=1770301463; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yUks7eNetVwpKzfbiYWPmagkxOdBNqngs8+VH2ernxM=; b=MRoFhujW8OeAx4BPMN2c8cGPvMye1G8uyDP6RCjMo5j+VlNL4K4ORdTvtxUa/EGlHT OCOVZFHZ6umYIy7Waje2biwRaWdq0hY2mhujbU1fOub1WOFX62GJ+Rlu/m3NB+iXfBHt SoRWFw0Aqpj3N3Enf/vvoipv2yLE/9tc5gqxhEQUdzVAhsGJ9gA3kQxuvLLoLLPNWOPC mzj/kHX3qSlsnN9JferRecNCQFIA1qT8kThvHj1g6eJiPkJn4YfBgKHlJuCTVsnBOU+P eEU310kcCDQdAA8YxSnszb4qQSoIniF+uDWuprqdWbJHE6orU6qRgUw9VN1zq6ovRTTI sGtw== X-Forwarded-Encrypted: i=1; AJvYcCXOPLMHAH5SXi6ptTBI/7doOJyNdUveyZkqLjL943Y0cGyx67XFFXqsUjykLxvRaZSZ1nxlxsEkvx4=@lists.xenproject.org X-Gm-Message-State: AOJu0YwxApk9JV7EvBExrsLRbOg9yCeZsU0h65UOv106dT1wAk0CBauG kQ7Z15quvfEchMG6UgCsRhXVGgQums/YhnBKLCG+Mcjo84fbrrbKIjAPC/rBiVOd/g== X-Gm-Gg: AZuq6aJb4IpFmmJ+dgrCdaPsq6s2tz8NNpNWpBjEdJvXPfGfHj3Le75xEApCLGvApL5 IphELvT48pXF5fm7q+6bLAjhev9yBQ5peYdjUzNcXNPRGohH2sxczfHFP4yqk1lWYxLgS41PCDA e+iYXLPR0+kIod4TVEOLHxmPMy9UoTA2ZVWBjQlc6Bxs7MLObZyGiuiWPGobgKx47hfy1lNAeWG WS2QNxDcMoBP0xHC3UqWNfFBdqJOgaINZU0YDEx834508JyfGnovsnQAHDFC9Yu0Yui3rwRRj1Y m/dKDCyVsqdMjuGn97eevj306kad+PkYNpv5o2nZaPJfeXRaduyZLaU7vAn0fJV34NoZS6zvMPE gqVtj7NIgn8cB0+yJPlsZWw/drlrfe3hUhb6zjrXv5wr6dAbqhDJ1Wb25O8q3lkcPzyTki4x0ER 4uJO72/SNTH2LYduZjyromTliCo0/W/YHQvi4nulKDHTkDLIFC1zTJYTk75Bft4hOg+Ma1hWR/h Q4= X-Received: by 2002:a05:6000:420b:b0:432:851d:23e2 with SMTP id ffacd0b85a97d-435dd1ccbbamr13027393f8f.49.1769696663291; Thu, 29 Jan 2026 06:24:23 -0800 (PST) Message-ID: Date: Thu, 29 Jan 2026 15:24:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 1/5] xen/domctl: chain SCI handling before IOMMU in assign_device domctl To: Oleksii Moisieiev Cc: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" References: <69d32e2440b2ef194b4893e5dd29c2dd9d216a90.1769696107.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: <69d32e2440b2ef194b4893e5dd29c2dd9d216a90.1769696107.git.oleksii_moisieiev@epam.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 29.01.2026 15:16, Oleksii Moisieiev wrote: > From: Grygorii Strashko > > Add chained handling of assigned DT devices to support access-controller > functionality through SCI framework, so a DT device assign request can be > passed to firmware for processing and enabling VM access to the requested > device (for example, device power management through SCMI). > > The SCI access-controller DT device processing is called before the IOMMU > path. It runs for any DT-described device (protected or not, and even when > the IOMMU is disabled). The IOMMU path remains unchanged for PCI devices; > only the DT path is relaxed to permit non-IOMMU devices. > > This lets xl.cfg:"dtdev" list both IOMMU-protected and non-protected DT > devices: > > dtdev = [ > "/soc/video@e6ef0000", <- IOMMU protected device > "/soc/i2c@e6508000", <- not IOMMU protected device > ] > > The change is done in two parts: > 1) call sci_do_domctl() in do_domctl() before IOMMU processing. If > sci_do_domctl() reports an error other than -ENXIO, treat it as > authoritative and skip the IOMMU path. A return of -ENXIO indicates > that SCI did not handle the request and is ignored, allowing the > existing IOMMU handling to run unchanged; > 2) update iommu_do_dt_domctl() to check for dt_device_is_protected() and > not fail if DT device is not protected by IOMMU. iommu_do_pci_domctl > doesn't need to be updated because iommu_do_domctl first tries > iommu_do_pci_domctl (when CONFIG_HAS_PCI) and falls back to > iommu_do_dt_domctl only if PCI returns -ENODEV. > > The new dt_device_is_protected() bypass in iommu_do_dt_domctl only > applies to DT-described devices; SCI parameters are carried via DT > nodes. PCI devices handled by iommu_do_pci_domctl do not carry DT/SCI > metadata in this path, so there is no notion of “SCI parameters on a > non-IOMMU-protected PCI device” for it to interpret or to skip. The PCI > path should continue to report errors if assignment cannot be performed > by the IOMMU layer. So we should leave iommu_do_pci_domctl unchanged; the > SCI/DT-specific relaxations belong only in the DT path. Also SCI handling > only exists when DT is present. > > Signed-off-by: Grygorii Strashko > Signed-off-by: Oleksii Moisieiev Acked-by: Jan Beulich provided you get an Arm person's R-b covering ... > --- a/xen/common/domctl.c > +++ b/xen/common/domctl.c > @@ -29,6 +29,9 @@ > #include > > #include > +#ifdef CONFIG_ARM > +#include > +#endif > #include > #include > #include > @@ -833,6 +836,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) > case XEN_DOMCTL_test_assign_device: > case XEN_DOMCTL_deassign_device: > case XEN_DOMCTL_get_device_group: > + /* > + * Chain SCI DT handling ahead of the IOMMU path so an SCI mediator > + * can authorise access-controlled DT devices. Unhandled cases report > + * -ENXIO, which is ignored. Any other SCI error aborts before the > + * IOMMU path runs. > + */ > +#ifdef CONFIG_ARM_SCI > + ret = sci_do_domctl(op, d, u_domctl); > + if ( ret < 0 && ret != -ENXIO ) > + break; > +#endif > + > ret = iommu_do_domctl(op, d, u_domctl); > break; ... this change (among anything / everything else). I can't prove its correctness, I can only state (by way of the tag) that I see nothing wrong anymore. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 29 14:27:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 14:27:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216636.1526578 (Exim 4.92) (envelope-from ) id 1vlSzl-0005zt-B7; Thu, 29 Jan 2026 14:27:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216636.1526578; Thu, 29 Jan 2026 14: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 1vlSzl-0005zm-8e; Thu, 29 Jan 2026 14:27:41 +0000 Received: by outflank-mailman (input) for mailman id 1216636; Thu, 29 Jan 2026 14:27:40 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlSq9-0000f7-KD for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 14:17:45 +0000 Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [2a00:1450:4864:20::543]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 46a934fd-fd1d-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 15:17:43 +0100 (CET) Received: by mail-ed1-x543.google.com with SMTP id 4fb4d7f45d1cf-658cc45847cso1367317a12.0 for ; Thu, 29 Jan 2026 06:17:43 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8dbf1c5b23sm261841866b.57.2026.01.29.06.17.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 06:17:42 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 46a934fd-fd1d-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769696262; x=1770301062; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=RN73keMBdn5sF5YAcK29ak1jpV6CD23sxnl8yLJ4dIQ=; b=B8ZirNpHWiW5QoOzJhoygVkHSiV1mlfo0a6glZNPX44bJFeauDIVBTEK0zG+StB+jy IcDUGAa2nJMP9oF9qmCLCSDSMb233g6+IK8wVpV94usU7RAZkPeV2s95AFuyTQ/b31T0 1r/UdOnk0FtH1/5jSLfQXJTHWnE+jOeXl5Vr/BNlTbnBAw3KW5Dxu+UqoyfMXaWT4MuQ DqXs+ReHSvX1nDJI1pcCttBzCx+hqNILMb64x8iXJ+ID0stWqAeGYyFdk5X6OrgAgtBc 1+2H12HqltSf7XtBU2/a0J3CAZcolP1RPVOifakBIlIDeq9ub9W4hs0bWDLHoM6AIRaa kS/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769696262; x=1770301062; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=RN73keMBdn5sF5YAcK29ak1jpV6CD23sxnl8yLJ4dIQ=; b=HZ1PM8yzZTGWhaVanUH21OI90TDNtfx6RkgzbOToUtF8z0Dm0ZrQdlScEY6ie9kCb0 EyRS52dzBPDv/3QU82JOmctAiQl05WToXrbF9mbUZR8zPPJsY5Br/DvfjUfBWHXeEUe+ tKQNCCO0y2NkMRTTG/mi+NBwM9Ak1X3bS5kbKydts2q0lkxv8u+0FLaG4dHxgtzs8gik 2kSPXaiTNUEgeVULpTFbo+8/Qz0VBjoWZ4YyNC5hwl6/0lJ7QiW1WIm5Inh86hfgqkYC wQOiFUItz4Bofahevj7L6HZIK6UgzyclLWKIncGiz2k0JZYToiK7xdp365h961gu1YSW Fmow== X-Gm-Message-State: AOJu0YwbUMMobRAhRoQDXLCWQLsPgA5HrfpkohRH0Zv/1TwbMDBgTz0t vc+OUE8D1pBQZMUN8BlhiSQiSyPYEL1sYjcATHSALDSyIABAOyKIAZsq5xSd0Ax0xw== X-Gm-Gg: AZuq6aI39nVmD5IjydhQxyGwkxLk8SOI+dIzLjmVRy2QjLr39CxTEN6puQm+c7mGp5h R1oIp2aJslvBY4Dfkt+S7N1oKVVNJ8trVeZEtrNG/UzZrbFl3tiVhLmZjBlGn9A5MU73URU8ELP u3FchxZZPrqrpJgNkI9Isvy1Wn14HOHcWETWVIAV6SjiZBxkygBm4APq6H0qqmyPo2dyqPMEC2v s73GZb5xVY6BFCXuKuokrbuCZ44BLwxKs8q1J16AaFX6qA3K3XGesp9V6DrrK6eJG//ADlAOlgJ uuyJf6org9qeHZAHcvW2EvWS+q7c1QXWFhWHN8s39Ez/FiE4PyNhO+rZLCwqIHgDmAYsVWZuV/w GFMQLd3xKq95vafbxgGoacdBcyd712hkLjqeXBcDcTCXD6QuP39c81RTcim78b7wkES4VejxSZM EmzJGohBDwVNsmQ5rREHwN3M/79FOaImPJAtTMbZl71oPpX0rCL3DId9GryzXZTjqhwQhyHG3ro c8= X-Received: by 2002:a17:907:3c87:b0:b88:3b3a:42b6 with SMTP id a640c23a62f3a-b8dab2fe030mr563791366b.37.1769696262410; Thu, 29 Jan 2026 06:17:42 -0800 (PST) Message-ID: <45640da8-9e9f-4b9e-83a0-3bfe701cf5d4@suse.com> Date: Thu, 29 Jan 2026 15:17:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/6] PCI: determine whether a device has extended config space 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 , Stewart Hildebrand References: <99d45a27-ce67-4f10-9883-dba96f055285@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.01.2026 15:09, Roger Pau Monné wrote: > On Thu, Jan 29, 2026 at 02:08:27PM +0100, Jan Beulich wrote: >> Legacy PCI devices don't have any extended config space. Reading any part >> thereof may return all ones or other arbitrary data, e.g. in some cases >> base config space contents repeatedly. >> >> Logic follows Linux 6.19-rc's pci_cfg_space_size(), albeit leveraging our >> determination of device type; in particular some comments are taken >> verbatim from there. Like with Linux'es CONFIG_PCI_QUIRKS, only the alias >> detection logic is covered by the new "pci=no-quirks". The singular access >> at PCI_CFG_SPACE_SIZE is left unconditional. >> >> Signed-off-by: Jan Beulich >> Acked-by: Roger Pau Monné >> --- >> The warning near the bottom of pci_check_extcfg() may be issued multiple >> times for a single device now. Should we try to avoid that? >> >> Note that no vPCI adjustments are done here, but they're going to be >> needed: Whatever requires extended capabilities will need re- >> evaluating / newly establishing / tearing down in case an invocation of >> PHYSDEVOP_pci_mmcfg_reserved alters global state. >> --- >> v3: Add command line (sub-)option. >> v2: Major re-work to also check upon PHYSDEVOP_pci_mmcfg_reserved >> invocation. >> >> --- a/docs/misc/xen-command-line.pandoc >> +++ b/docs/misc/xen-command-line.pandoc >> @@ -2009,12 +2009,21 @@ Only effective if CONFIG_PARTIAL_EMULATI >> behavior.** >> >> ### pci >> - = List of [ serr=, perr= ] >> + = List of [ serr=, perr=, quirks= ] >> + >> +* `serr` and `perr` >> >> Default: Signaling left as set by firmware. >> >> -Override the firmware settings, and explicitly enable or disable the >> -signalling of PCI System and Parity errors. >> + Override the firmware settings, and explicitly enable or disable the >> + signalling of PCI System and Parity errors. >> + >> +* `quirks` >> + >> + Default: `on` >> + >> + In its negative form, allows to suppress certain quirk workarounds, in case >> + they cause issues. > > Not that I oppose to this, but I've assumed that you would introduce > an option to fallback to the previous behavior where Xen would just > assume extended space to be accessible. But that would be wrong. It didn't even occur to me that you could have wanted that. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 29 14:27:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 14:27:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216637.1526589 (Exim 4.92) (envelope-from ) id 1vlSzt-0006H5-Kh; Thu, 29 Jan 2026 14:27:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216637.1526589; Thu, 29 Jan 2026 14: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 1vlSzt-0006Gy-GW; Thu, 29 Jan 2026 14:27:49 +0000 Received: by outflank-mailman (input) for mailman id 1216637; Thu, 29 Jan 2026 14: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 1vlSzs-0005x4-0V for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 14:27:48 +0000 Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id acfd4d5f-fd1e-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 15:27:45 +0100 (CET) Received: by mx.zohomail.com with SMTPS id 1769696848567136.48743967324322; Thu, 29 Jan 2026 06:27:28 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: acfd4d5f-fd1e-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; t=1769696852; cv=none; d=zohomail.com; s=zohoarc; b=RmRZrQhgTnx8pI0Vt/7hDJuJAkvazWPBtKFQWS/Q04u5dda1jYh92a0l/943939Q2Q+XmaWG12jLCZBtrregbmXwiNWeMZ46FF3Fxg0beWjvSRYCkMDtIRzo9R9EyxdPSGAiQVrStY5xkYAkp18QHZB2JgjiuZbohEqdtc7NVX8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1769696852; 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=Csi40rQ6fKyJbiyM0FXQWkQQah5ioh+4oM6lP9s5imQ=; b=LQgjpzY6DnPvLX0MNQEJ7kbTqt0x3B6oft645cD4yBkeVoplE3l+jRG+uEI/u6w+iCChC99CebVctB9WIidW1G8Q63tpxvGUPhLbnxghjrZNU2/NNh30c5RPV/TAbcgJiIKXukfwmFaCFRjZtByW0UV9Hdfqe9wC5zhYviPdPZ0= 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=1769696852; s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=Csi40rQ6fKyJbiyM0FXQWkQQah5ioh+4oM6lP9s5imQ=; b=cdonrx28oM4RGm/3ytQKpagvsam3hs3ZEjPCK+z10ymkZzbYCs9FRjjlZdUN32CA 1QdfFsP94ULp5bAWTgcOyeGp53pHMCmbBneO8tn3OeC9aFj5r2HGoFr+/sDH9KSEAK9 YMG2Z+eLHTQukclzVAGWHJM0ycathaGcM9WMccno= Message-ID: <24f75da5-116d-4955-a999-04366ec3146b@apertussolutions.com> Date: Thu, 29 Jan 2026 09:27:28 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 1/2] xen/console: handle multiple domains using console_io hypercalls To: Jan Beulich , Stefano Stabellini Cc: Stefano Stabellini , grygorii_strashko@epam.com, anthony.perard@vates.tech, michal.orzel@amd.com, julien@xen.org, roger.pau@citrix.com, jason.andryuk@amd.com, victorm.lira@amd.com, andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org References: <20260123010640.1194863-1-stefano.stabellini@amd.com> <2044f927-6d9f-4c7f-9e47-6e4c6dbb2fcd@suse.com> Content-Language: en-US From: "Daniel P. Smith" In-Reply-To: <2044f927-6d9f-4c7f-9e47-6e4c6dbb2fcd@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ZohoMailClient: External On 1/29/26 3:24 AM, Jan Beulich wrote: > On 29.01.2026 03:42, Stefano Stabellini wrote: >> On Wed, 28 Jan 2026, Jan Beulich wrote: >>> On 23.01.2026 02:06, Stefano Stabellini wrote: >>>> @@ -742,17 +758,36 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, >>>> if ( copy_from_guest(kbuf, buffer, kcount) ) >>>> return -EFAULT; >>>> >>>> - if ( is_hardware_domain(cd) ) >>>> + /* >>>> + * Take both cons->lock and console_lock: >>>> + * - cons->lock protects cons->buf and cons->idx >>>> + * - console_lock protects console_send and is_focus_domain >>>> + * checks >>>> + * >>>> + * The order must be respected. guest_printk takes the >>>> + * console_lock so it is important that cons->lock is taken >>>> + * first. >>>> + */ >>>> + spin_lock(&cons->lock); >>>> + nrspin_lock_irq(&console_lock); >>>> + if ( is_focus_domain(cd) ) >>> >>> Why would any of the domains possibly being permitted to be "focus" suddenly >>> gain direct access here? Full access in do_console_io() is still prevented by >>> the XSM check there, afaict. Cc-ing Daniel, as it's not quite clear to me >>> whether to introduce another XSM check here, whether to check ->is_console >>> directly, or yet something else. >> >> The XSM check still happens first in do_console_io() via >> xsm_console_io(XSM_OTHER, current->domain, cmd), which validates that >> the domain has permission to use console_io hypercalls. The focus check >> is an additional restriction that only allows reading when the domain >> has focus: it doesn't grant new permissions. Dom0less domains with >> input_allowed = true are already permitted by XSM policy to use >> console_io; > > Are they? I don't see any XSM or Flask code checking that flag. What the > dummy xsm_console_io() checks is ->is_console. Unless I am misunderstanding what you are asking here, I don't see why XSM would be concerned with this check. The `is_focus_domain()` conditional is not an access decision but a decision whether write to the console or buffer the write. > However, what indeed I didn't pay attention to when writing the original > comment is that guest_console_write() has only a single caller, > do_console_io(). So there's no concern in this regard here as long as no > new caller appears. Correct, the `xsm_console_io()` hook is the access check if the guest is allowed to read/write to the console. Any paths to this function should be guarded by a call to this hook. v/r, dps From xen-devel-bounces@lists.xenproject.org Thu Jan 29 14:41:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 14:41:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216664.1526598 (Exim 4.92) (envelope-from ) id 1vlTCj-0001AB-Mb; Thu, 29 Jan 2026 14:41:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216664.1526598; Thu, 29 Jan 2026 14:41:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlTCj-0001A4-JZ; Thu, 29 Jan 2026 14:41:05 +0000 Received: by outflank-mailman (input) for mailman id 1216664; Thu, 29 Jan 2026 14:41: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 1vlTCh-00019y-RN for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 14:41:03 +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 884cf30d-fd20-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 15:41:01 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-4801bc32725so8064525e9.0 for ; Thu, 29 Jan 2026 06:41:01 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806ce564f9sm142288155e9.14.2026.01.29.06.40.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Jan 2026 06:41:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 884cf30d-fd20-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769697661; x=1770302461; 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=9It+LgUBP+HQMboZ37j1eEcPa8t6CGcqjlQAntYPfIo=; b=fdF7mkXd0S4UhaGoSeraMprWpYxmgb82OLqBdcDeV506EdqhXWQhzwc1PEYiqAFv9j yZrhq6eZmo5ustZAyqwxiBEDqJc/xGipNwJbhSu1JJuowkTBJVbwKvzKdh2x8de1taSq WY8vmMHpHXsGzC37dCNKxR5wWQZrwQkQBto+Hd06RP8hFxH2ZH5iDbI95UjEUW87/pp6 0YcI/ql8HZZp3qcWF1Gk2E942T7iD63IMrEPGdu7NG9dEM9bThnNswN2MNBqyQu9fKKj kVsxy63qBbVxbZnxAGQ6hDMdG4brvoIXNur+nwlCn0eYLUp9vh87Z5HCrn/AUlDsESYE P4qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769697661; x=1770302461; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=9It+LgUBP+HQMboZ37j1eEcPa8t6CGcqjlQAntYPfIo=; b=GY1Hb5UNOZq72DYB3W5oG6+yY4btpHVxAgaURzlvfEhB2q/Fo/VUsoZZGpqt8d3qmf Fw5IyzJi2DNO0Yn9F/YcvLpSSAcg3VpQykGUFqgzf4ogsJiuCqqiA7h9NuQXTIjB64Vo nhzuVDiZqSV0tVoVoQbPemBUTzUpjNCeEPTqWma7sNZf0taNCQcN3aAlcYWqlbVS8dfv cy1wMgrFT33tb20OLsZ80EjMjN9z3kJe7gxnrH5XRmVe+rZQ/iAnlsgZxjbNYHdQ0Lso sOV/IoOkFgt46W6h3UVOhH46NgnB1CzXOyohpWsj4Nqyk3t57HRpMIoE03eJTXundsVP mgkw== X-Gm-Message-State: AOJu0YyrnDlRMGsGKi4tsjpIgz6DQw4xoEgsEE+IXHNdwJnB1mITMACG S4I3jhK2LswmPfXfK7IFYYx/5IZNHTmujkYLF5nLsYoVGldlnjODGjADuGEDcA== X-Gm-Gg: AZuq6aKAAmZBUOUPh/6odu6rl7kTd/12usV+G99hVkarlryanO2ejEWGbTOKGw1vYfv FbrNNtou5t5CFe+5zwfWstDL20/UFYmVDtUNSTolKxKjSvT+Ky+yYPKMwk2Xsltu0Gz8qsTKhYm cyTH1+f0ULbJjMdtuBGVLeQOWbcX5vX4cZYks0/fcHVEJQrDpXEDCkIX5yZ44kmcRvALLd+17jh N1341ARyrEWGbOT6dyKxmDOCYTV7v7l5bypCGmH0UJ9K5oF/ALO54j3h8wQ7ulRizEFAT2hIG+1 feRIQpwyC6K0ooZUGYxvvol84KuqogiTecxI0vh4HpddZcj610VCFBXnXbd7vYYrvX1wcp+rUkR eX/z+92df/CQorwdC5OnKGalJ2GgCzc5z18M25PQ8Gm3gyHnNvv0f2rwOu16iYV7PFkwfnjlnEv TPkISInRFMfeHawHeir290IM8A+v+6JW8bFEsRzGjTG0yyuiTz7fm0+Q== X-Received: by 2002:a05:600c:3b96:b0:475:dcbb:7903 with SMTP id 5b1f17b1804b1-48069c37e2dmr126208425e9.9.1769697660684; Thu, 29 Jan 2026 06:41:00 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1] xen/riscv: route unhandled interrupts to do_unexpected_trap() Date: Thu, 29 Jan 2026 15:40:52 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Currently, an interrupt cause which is not explicitly handled is silently ignored, and execution resumes without reporting the fault. This is incorrect and do_unexpected_trap() should be called in the case of unhandled interrupt. Fixes: a8b85fabf6090 ("xen/riscv: add external interrupt handling for hypervisor mode") Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/traps.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c index 84b5ab4142f6..34920f4e5693 100644 --- a/xen/arch/riscv/traps.c +++ b/xen/arch/riscv/traps.c @@ -196,6 +196,7 @@ void do_trap(struct cpu_user_regs *cpu_regs) { /* Handle interrupt */ unsigned long icause = cause & ~CAUSE_IRQ_FLAG; + bool intr_handled = true; switch ( icause ) { @@ -204,10 +205,12 @@ void do_trap(struct cpu_user_regs *cpu_regs) break; default: + intr_handled = false; break; } - break; + if ( intr_handled ) + break; } do_unexpected_trap(cpu_regs); -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Thu Jan 29 14:45:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 14:45:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216675.1526609 (Exim 4.92) (envelope-from ) id 1vlTGb-0001lr-9r; Thu, 29 Jan 2026 14:45:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216675.1526609; Thu, 29 Jan 2026 14:45: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 1vlTGb-0001lk-6L; Thu, 29 Jan 2026 14:45:05 +0000 Received: by outflank-mailman (input) for mailman id 1216675; Thu, 29 Jan 2026 14:45: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 1vlTGZ-0001le-PA for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 14:45:03 +0000 Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1650b221-fd21-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 15:45:01 +0100 (CET) Received: by mx.zohomail.com with SMTPS id 1769697895270324.40780646864755; Thu, 29 Jan 2026 06:44:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1650b221-fd21-11f0-b160-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; t=1769697898; cv=none; d=zohomail.com; s=zohoarc; b=QumGtfraMk7/B+Rw3bHtVP4cg2CsIu7usSzgqg1wswMQgl9+x013osCjsQsHiPeEioMBOjyrvOwV+GZ4/2892DOoDY57VXSApb3x4Eu8K2JFeiOuuJGyFwNR+Ud+845t9AGZ31tE2T4H4IvBp6grzwbRdSYsReuRAYItykOiMWo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1769697898; 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=j8yBhKx1G41u1LsCGtjrmCUpwycCbK+hk+TjR9aoEpY=; b=S3+PTSSkXYV+6oheYjCZcs1SEUXa3t5U/xXmIB04xM28udoNulO7IaRN8sn2Wdr4mkds+IcuyJQNTR17gbsIq4R+MhhO10+nKQ59BAOF65RNEpe7Vd/yYh2cE6RXBrOxKlWIwPS8Hlm4lZINd8HUk59vwdg3rvY2J4B//WYvvdQ= 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=1769697898; s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=j8yBhKx1G41u1LsCGtjrmCUpwycCbK+hk+TjR9aoEpY=; b=oONzvDiMY8MPc24KT8IIilMN/AzkI7bgnWMdPzN7HccuMwivAMzPF1RhZntDPPFp bOLE7E+DKzlsUzBQ/oA2cW2ECIzvCBv3M0J81bKTGfcdu5zXIw77IoUC4wnguMNM1xQ eZjouobCqMeIGIfGXqiK9h9XwxyKdnySqdrcBBWY= Message-ID: <2506be14-5615-4221-b6b9-079c709fddc0@apertussolutions.com> Date: Thu, 29 Jan 2026 09:44:56 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/EFI: correct symbol table generation with older GNU ld To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Marek Marczykowski References: <27f291a3-6546-4834-a9cd-22a4636b152e@suse.com> Content-Language: en-US From: "Daniel P. Smith" In-Reply-To: <27f291a3-6546-4834-a9cd-22a4636b152e@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ZohoMailClient: External On 1/21/26 5:05 AM, Jan Beulich wrote: > See the extensive code comment. This isn't really nice, but unless I'm > overlooking something there doesn't look to be a way to have the linker > strip individual symbols while doing its work. > > Fixes: bf6501a62e80 ("x86-64: EFI boot code") > Reported-by: Roger Pau Monné > Signed-off-by: Jan Beulich > --- > Should we try to somehow avoid the introduction of the two symbols when > using new enough ld, i.e. relocs-dummy.o not needing linking in? > > --- a/xen/arch/x86/xen.lds.S > +++ b/xen/arch/x86/xen.lds.S > @@ -339,6 +339,24 @@ SECTIONS > *(.reloc) > __base_relocs_end = .; > } > + > + /* > + * When efi/relocs-dummy.o is linked into the first-pass binary, the two > + * symbols supplied by it (for ./Makefile to use) may appear in the symbol > + * table (newer linkers strip them, for not being properly representable). Just a suggestion, but do we have the minimal version where the stripping is handled properly? I just think it would be good to have the minimum version documented here. Doing so would make it easier that if the minimum supported build tools are bumped past this version, hopefully someone will either remember or notice the comment and could drop these declarations. > + * No such symbols would appear during subsequent passes. At least some of > + * those older ld versions emit VIRT_START as absolute, but ALT_START as if > + * it was part of .text. The symbols tool generating our own symbol table > + * would hence not ignore it when passed --all-symbols, leading to the 2nd > + * pass binary having one more symbol than the final (3rd pass) one. > + * > + * Arrange for both (just in case) symbols to always be there, and to always > + * be absolute (zero). > + */ > + PROVIDE(VIRT_START = 0); > + PROVIDE(ALT_START = 0); > + VIRT_START &= 0; > + ALT_START &= 0; > #elif defined(XEN_BUILD_EFI) > /* > * Due to the way EFI support is currently implemented, these two symbols With or without the suggestion, Acked-by: Daniel P. Smith From xen-devel-bounces@lists.xenproject.org Thu Jan 29 15:20:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 15:20:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216709.1526647 (Exim 4.92) (envelope-from ) id 1vlTou-0007W5-4d; Thu, 29 Jan 2026 15:20:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216709.1526647; Thu, 29 Jan 2026 15:20:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlTou-0007Vy-1V; Thu, 29 Jan 2026 15:20:32 +0000 Received: by outflank-mailman (input) for mailman id 1216709; Thu, 29 Jan 2026 15:20:31 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlTot-0007Vs-Bg for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 15:20:31 +0000 Received: from SN4PR0501CU005.outbound.protection.outlook.com (mail-southcentralusazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c10d::3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0ad1d34b-fd26-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 16:20:28 +0100 (CET) Received: from SJ2PR07CA0007.namprd07.prod.outlook.com (2603:10b6:a03:505::12) by BL1PR12MB5924.namprd12.prod.outlook.com (2603:10b6:208:39b::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Thu, 29 Jan 2026 15:20:21 +0000 Received: from SJ5PEPF000001F1.namprd05.prod.outlook.com (2603:10b6:a03:505:cafe::87) by SJ2PR07CA0007.outlook.office365.com (2603:10b6:a03:505::12) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.11 via Frontend Transport; Thu, 29 Jan 2026 15:20:18 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by SJ5PEPF000001F1.mail.protection.outlook.com (10.167.242.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Thu, 29 Jan 2026 15:20:20 +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, 29 Jan 2026 09:20:20 -0600 Received: from [172.23.55.58] (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, 29 Jan 2026 09:20:19 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0ad1d34b-fd26-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=t4iPywzyyozOTBTdmgsu4CCVOLI9o2NGezJX28rqCfJMT608Wt/5ve+4FSReVcGPHsfeqc16uadkwwL7P8abMiPxYtOcbkkrwl8v6G0UcM/RcqlPVI2T/k3uGsfcUoEhNgp5Buq3d+sL8fsrFGQi1jcFy3iHX+UFEa/HeV121h7kBgfzH3VXBFPSpTMhC1K88baSiLepa/SBtma24BbvglUL+J8YfZv6slskqsekTItWG8s1m1ELr835O2z6/j3P1SvJDFOOMj2hpvpySNA6pqj+Gw4H555K6+5VoDXPgyuaPt2LsKv1SKtlEVJNGZ7boNiiG3NqWnAHveMHcpC26w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=U4wVsQMcWky+6nPVQj5ljwRn38RHzT86zi9CQAuM6Ns=; b=hGmxXne0rUrfKWob6Xc91ZG3V+IyNQaiUE7UBtZgw8p4Of+h1dgZ3X0ogCzX7HWu37I2vyWC3u3flTrNR9U7wsvb0wgcqeEkOFqImHOeHoCQFOWgU9S3mtyWmSt/ktXW1HMIq8A0Tum9wDLVlDeLZ8a0sEYVxnSMPRqW4kfCZCHZUYxGnfp5HBgn8A7qm5lBNr61BipqiqrhD5wSDMQWPT0wflkoUkEagHkHontG9RW9o18P9gLbJ3u/N1lc/WYZkY5jkFTjmAsjs6ExjyYogNSZEWI1AuL0DGJXBIwuHvDFaPk4uWLYCPhoGjUPxjPXrhjbjORjoILaUeOj52LApA== 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=U4wVsQMcWky+6nPVQj5ljwRn38RHzT86zi9CQAuM6Ns=; b=niBgLjrtm3NRa9A05DWm9wvLlj7sSJ81KL2dUiRwrDnTMERyCONYxWdE1Gn0hillqeGcVwG2Zj/2s3pp/qU8iTJceFzOBywfv45oB4emWSyQg8+e3NzIK7DcUqXfM7PGv114oyOxE5JOb9wdpFnMAHqyi+6CswY0ISO3mHlIs50= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: <5cef7401-7b48-4ecd-9bb6-d92950678a08@amd.com> Date: Thu, 29 Jan 2026 10:20:18 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86emul: allow ->write_msr() to distinguish origins of writes To: Jan Beulich , "xen-devel@lists.xenproject.org" CC: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <7987f1fc-5b5e-40c6-866e-ac332097c635@suse.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <7987f1fc-5b5e-40c6-866e-ac332097c635@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: SJ5PEPF000001F1:EE_|BL1PR12MB5924:EE_ X-MS-Office365-Filtering-Correlation-Id: 734ab816-1504-4b0e-748b-08de5f49eab9 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?VlJray9YVlBRSVEzUDhJUjFDRlBDS0lNS1YyWmp0V0FnbENxMDNxUHlnWG10?= =?utf-8?B?QVhNcE90VGg1V2NqdjNHK3pPeXdlZ01uYTFoNWJzWlh6YlE5TVdNYXBvSnVI?= =?utf-8?B?NWxRcHlOaXgyaHRNT21ZZWxxanFCSkdsQzNuK1R1Q04ySFpQN0RHcWczN0lt?= =?utf-8?B?QjFpN21uaVN5RUpPc085RkQvK0g2SDh2cm5tQ3YyUHF4U2pyc0JpTTNqbHZE?= =?utf-8?B?aUdRMTZqOHg5R1Zvbk5QTTRDVFBoQis1dzF0NW9LUW1TTjNFMjZEVE1IbHYv?= =?utf-8?B?QmREVXdBeW43QmxhOUhaNk1NeFV4QmJkWi9GWG52RjNKTHRpSUxacDFhbVdN?= =?utf-8?B?S2E1NVpOeWtKRTB4RWRvbTZBcThjZzhQazZQczA0R2kzUUllUC9yRHZ2cjR0?= =?utf-8?B?eHVBVVl6NnhyRHllM0hmbVRhTWJ0Um9WV1pBMC85Z2o0NjRoSEtBWERVWTMr?= =?utf-8?B?YXdMbGNENy9ZTkhEWmh0VHhidDR2VlM1a1JpMFNaa3lSRXltbkRBSEdMcDBh?= =?utf-8?B?bVZsNzlmc3F1TXZyYUxTQUxXT2ZkOXVOOVhrZ1pDZUdTM2F2Y2tWcVBTdW50?= =?utf-8?B?WEZoRWZWcWZQTEtmZEtKeEFrcTZWNDNjUlY4VXBVYzdXc1dEYWI3czFTektT?= =?utf-8?B?VDdFS1lsN2k3V0x3TklpbE9JLzQ2SmIxL0hjaFo0aUc4Z083bnhpbVpITi90?= =?utf-8?B?TVVSQ2lOOVE2UExUSFBxeXRaaG1lRWpXQVZ2eTJrYkdFRHRuL2dyQlRyTjVl?= =?utf-8?B?N011TEVlSW4xUWYrUGFTd3J5WmlyRGdTNW5OSm9xTkFQcVA3RmxYQ2F5OUEw?= =?utf-8?B?L0dyelVJRS9CNTNOV3IrcDMvQ01NeTMzcGtTSU5DTmNySVMxanZDbFlLMXFs?= =?utf-8?B?dUllaUlFckdlK2R4WGhYdHVXMGJwS3FHajZ5UDBjWWpULzE1R3VnblNXeE5r?= =?utf-8?B?STlyN2MvODJGaDBPRGxhY2VoYm94dmQvdjc4RjhuYkFDOXJDeFJpN25kSmFV?= =?utf-8?B?T0ZDYkJmaDQ2Z3RJSnZsYndYSE0waFNIejl6aDFGSmwwLzc3bVMzcVNseUY3?= =?utf-8?B?QW1WVTJVcVVzWVZXTHhQYkxuSDdxTUFwNVhTTms3eWVmMHVMOWdVNFdlbjJr?= =?utf-8?B?S2RBNXJnYXF1Uk9IdjhrczJaTC80bm5xdHJTMWFXVjdyaEw2ZnA5ZUV5ZUhj?= =?utf-8?B?ZVdvUHdRck1PcDBUVUplakFKSTFXTVAyZDFONnBGZnpHR0NwdjhhSVQxVTVt?= =?utf-8?B?RXo4RnBranM3bHF0MjRYV2gwT0loZlBGU016SjVHMzkyNlpoaUt2cS9GVXdE?= =?utf-8?B?YjdaNFk4QkFqRUgzSEJOVzZvc1orOE50UUdRUTYzTkpCczlmaUF2bXgwUzlY?= =?utf-8?B?VGFRd0dWdi9Ndnk3TXVZUXBBbXoxeGtXYmlyL3MyZmdjZ01tczVDTk84TWhO?= =?utf-8?B?R1lhZlFBTXJNaG1kdERMTnV0YUVGT1pscklzN3N4YzJVMEJ4dSszNyt3Z0Vz?= =?utf-8?B?QkZBNGNteFZxMUh4SWw1VkcwcU5QUWEyTnlRaWZJdVAwNW9WdnpTRTR1aURv?= =?utf-8?B?SnpNLzl6WWdkOWYydGVxMkU5RXJBRFRjRWFrZmMyR3FKRy9BQnM1Y1Fmdmhv?= =?utf-8?B?b0FhdDZVZVdXREduYS90cGhlWmxuc25NM2NQT3ZDcXdkSkovMXplVm5FK3N5?= =?utf-8?B?L0JLd2hYSXVlT1MrdmxJY01kMnVhRTRhSG9IWDhnMkJqa2lNZElkdFZtR3JL?= =?utf-8?B?UDF0OGdLTlpmZHNKcTBKQnYxZ25PbWljRG5PajFBeDE0NllyOHNCbUlzeVMx?= =?utf-8?B?cHNNNTlIMlVTYjNFaU8rbFJuNG9IT1ZIYWFLeTlVOXJvR3lYK201Rm5maEFP?= =?utf-8?B?WjRjeE5KUzFueDFId1ZiRC9kR3lsY1ByTnhsdlljNnpXc0VFK1pVZ1Z5MEhD?= =?utf-8?B?K0FYODBJN0EwSVNMbmFiSTIrMC9DdmdIdlpPODFVT0RHamVMQzA5cXMzSmM1?= =?utf-8?B?L0dhOEFXbVg3TDIxSGFjWStiWjB3RUJhZnFQV0V6Ri9SRVFyMFprQXlDVEhK?= =?utf-8?B?V0RrVGlNZ3JTR3hzMUhURjJhVFZHVU5wY3dJUVpyWUZWb3luRXBra28zN0xE?= =?utf-8?B?aUVyZDNFYnl3RkQ1eVp1Q2dsbXpWWEg0V1p2eUlKNUFUa21lM0ZwSHZOSkY4?= =?utf-8?B?Z0lteUE4Vk8wa2lVbFJqR2pvMzJ0UW1HQmlPeVJOTi9sMXpYZzBReXJwd3dr?= =?utf-8?B?aEhGSHh4Skczb2kwTk5hTndzYUtRPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(376014)(36860700013)(7053199007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2026 15:20:20.7123 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 734ab816-1504-4b0e-748b-08de5f49eab9 X-MS-Exchange-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: SJ5PEPF000001F1.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5924 On 2026-01-27 05:21, Jan Beulich wrote: > Only explicit writes are subject to e.g. the checking of the MSR intercept > bitmap, which extends to VM-event's hvm_monitor_msr(). Indicate, by way of > a new boolean parameter, to the hook functions which variant it is. > > Fixes: 6eb43fcf8a0b ("x86emul: support SWAPGS") > Reported-by: Andrew Cooper > Signed-off-by: Jan Beulich Reviewed-by: Jason Andryuk From xen-devel-bounces@lists.xenproject.org Thu Jan 29 15:27:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 15:27:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216717.1526658 (Exim 4.92) (envelope-from ) id 1vlTv9-000859-Pv; Thu, 29 Jan 2026 15:26:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216717.1526658; Thu, 29 Jan 2026 15: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 1vlTv9-000852-LT; Thu, 29 Jan 2026 15:26:59 +0000 Received: by outflank-mailman (input) for mailman id 1216717; Thu, 29 Jan 2026 15: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 1vlTv8-00084w-QE for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 15:26:58 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id f00c221f-fd26-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 16:26:53 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B270E1576; Thu, 29 Jan 2026 07:26:45 -0800 (PST) Received: from [10.1.36.12] (unknown [10.1.36.12]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BCFE83F73F; Thu, 29 Jan 2026 07:26:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f00c221f-fd26-11f0-9ccf-f158ae23cfc8 Message-ID: <5b7d587b-e8db-4211-939a-48c4fcd4dc37@arm.com> Date: Thu, 29 Jan 2026 15:26:49 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] arm/mpu: implement setup_virt_paging for MPU system Content-Language: en-GB To: "Orzel, Michal" , xen-devel@lists.xenproject.org Cc: Luca.Fancellu@arm.com, Penny Zheng , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , Wei Chen , Hari Limaye References: <20260119105022.3616126-1-harry.ramsey@arm.com> <899a572a-1ba6-4bc6-806e-d049b4ac3ce3@amd.com> From: Harry Ramsey In-Reply-To: <899a572a-1ba6-4bc6-806e-d049b4ac3ce3@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 27/01/2026 10:14, Orzel, Michal wrote: >> For MPU system, we could have the following memory translation regime: >> - PMSAv8-64 at both EL1/EL0 and EL2 >> - VMSAv8-64 at EL1/EL0 and PMSAv8-64 at EL2 >> The default option will be the second, unless the platform could not support, >> which could be checked against MSA_frac bit in Memory Model Feature Register 0( >> ID_AA64MMFR0_EL1). > What's the reasoning behind it? Why do we prefer VMSA at EL1 rather than PMSA? > AFAICT PMSA is a default and VMSA is optional, so logically PMSA should be > preffered. We should also make it configurable I think, so that a user has a choice. Can we introduce this as a device tree parameter since we may want to run multiple guests with one guest to use PMSA such as Zephyr and Linux to use VMSA? >> - BUG_ON("unimplemented"); >> + uint64_t vtcr_el2 = 0, vstcr_el2 = 0; >> + bool p2m_vmsa = true; >> + >> + /* PA size */ >> + const unsigned int pa_range_info[] = { 32, 36, 40, 42, 44, 48, 52, 0, /* Invalid */ }; > 80 chars exceeded. > Do we still need 0 here to denote invalid value? It is possible for the architecture to be expanded with new features which increase the potential PA range (requiring additional support). Additionally for consistency this is how it is defined in MMU. Is there another reason why we should remove it? >> + vtcr_el2 |= VTCR_VS; >> + >> + p2m_vmid_allocator_init(); >> + >> + WRITE_SYSREG(vtcr_el2, VTCR_EL2); > Where do we set NSA bit? On ARMv8-R EL0, EL1 and EL2 all run in the secure state so we do not set that bit in this context. Regarding the other comments, I plan on reworking/cleaning up the patch to address them and make the code/intents clearer. Thanks, Harry Ramsey From xen-devel-bounces@lists.xenproject.org Thu Jan 29 15:32:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 15:32:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216729.1526667 (Exim 4.92) (envelope-from ) id 1vlU0p-0001Jf-D2; Thu, 29 Jan 2026 15:32:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216729.1526667; Thu, 29 Jan 2026 15:32:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlU0p-0001JY-9C; Thu, 29 Jan 2026 15:32:51 +0000 Received: by outflank-mailman (input) for mailman id 1216729; Thu, 29 Jan 2026 15:32:50 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlU0o-0001JO-Dk for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 15:32:50 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c3db69a6-fd27-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 16:32:49 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DM6PR03MB5180.namprd03.prod.outlook.com (2603:10b6:5:1::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Thu, 29 Jan 2026 15:32:46 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.008; Thu, 29 Jan 2026 15:32: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: c3db69a6-fd27-11f0-b160-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=FfLMKSdz7+RoM5YCHz6Um8j3jcNZC3RGdTKubZiES/xYun7abeAmhXfG1a5PMzmfj/hNq0sOdQYGjkbnpsBckG8NkHFwVtcxgAgS2Ir9iDaaM+rdtt9Plxb3uT66izlnLgE2/F6rc6UnjwO51yMJlbxieCOJZHc57luSwQY0eDhOUrV/jz+ek36zP54kIkuMaDKFqyeooVcXfmMOgBg0d3YabB8i35L6DNNR/INzIYyHwzGWCKNyDPOxpjgtRDDPQ7+shw/A0G6fKRXIo3gC04NzpO+e1sReyuiy1qixSFI1VwPc+2AodRTjkvGZqFYtnZ8r1viInEzWEl4AAB7maQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VuIVjMsD8z/WTemF1vaO+4Tej9Jwy+LLlnwIfT0DoJg=; b=SczC2JXn6oBTQYBcqh0XDMGFGi1Oqo40AmRTZyXR0PyAHfqwqQOl8GIaGs2HBGuy/GANzxHe+XsKXa91+20KYE13tbQ4ZQE81tVSMeRHMBZbuYJ2+p2n463MuuCQaPUg4cMoZxu2v/zTPOvdodZrS+QrmjJoCgqp9QJyUruM4BLXeqh0ZGukAptVZ500ZwBCNMW251iUdGRi30uG3lDgzpLARyncBh/alJKGBx2PLf2k3avnlwEJG9VGMNDDvSnJmrES1Pj0fDGVGDFAH8tyLifPddRX0UcFLEP8I7T3pProxXOF6pqEv2zpMpjeITST0u6PjjZTuHEV8NNj0DlCTA== 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=VuIVjMsD8z/WTemF1vaO+4Tej9Jwy+LLlnwIfT0DoJg=; b=Z2arAxDa71nFLS71uQvlnIQ6EYk2gjw/BzgYk4Q+EWmwEdjq4X0/BWktDl06wxp46d2F6WiqwZmY4yLEozz0JxVhJnF8EArG4uRt8NVdQsJMPjFEXbiDtPxNQ5agjm37kepWQybWiKgM0SQ8yWKChmzwhfEAaL16KEVuGtE4n0E= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 29 Jan 2026 16:32:42 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Stewart Hildebrand Subject: Re: [PATCH v3 5/6] x86/PCI: avoid re-evaluation of extended config space accessibility Message-ID: References: Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: PAZP264CA0155.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:1f9::19) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DM6PR03MB5180:EE_ X-MS-Office365-Filtering-Correlation-Id: 8c750eea-4388-483d-74d1-08de5f4ba69f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?Kzc3L2ZvSzJ1WkJMU0NNdkpLQ0NUWXNnclpQUTRtS0k4VjlDTUtaTkhWalBv?= =?utf-8?B?RUFiUnpjZHo2ZDdLUmhaOFN2ZzRMbGhTK2U2RUlxeFJXVEVzN0ZpYWUxN0o4?= =?utf-8?B?bUNDOVNhdVljTGhDdFZPZDZ2S0J4c3NCMWxEc2VOTThpZ0tkazFpam44VGIz?= =?utf-8?B?QWh1OUpIcXNaeXZwNEtuQlJpc1ZwZWs4b0tIK29HQ3pQcW5pVTRhbUNYWnN4?= =?utf-8?B?cy95TmtjVU81YUhzOWx6QU4wS0R6OEVJL0hISDFWMkdkbEdZTnZmVkdxVGp6?= =?utf-8?B?QVdoYnNUd21hem5hdEgybjZGaDlZQ3BPdkNFbFNHZFNQMWlHRlozRXdyeHFO?= =?utf-8?B?bmIwR0JDbFhwcUlwZDVOUGpTV3lOU3lPUlRzNkN0WEVjMkFyZXpQZnd1Vk4r?= =?utf-8?B?QW16WWdBUzNVRjdjSjZvelkwQ3dOZ0E3N1VOYWpMUDdEZ3A4VHc2OFhXUCts?= =?utf-8?B?bUZDbjdMSnhmMllRK1NyVm5iU0xTb3Z4bkhnV2tGSGplWkcxMUE1VEFueW9v?= =?utf-8?B?RXdNSW1YdnE1NldRdFlvbitOUzI3VVpwVTA4bkVwMHUwWmcvbU52c05XMDA2?= =?utf-8?B?LzkzM0R5Wk5lcU5FbXpwZlhOTDZsdkFweVhRRXlaMGZYTzJhbkdrOXdPTUp4?= =?utf-8?B?YmpBOHE1eVEzOTdnRWl5MG9aYVMvSmpYa0J3alE4YW82MS9Nbzdoa0JPZDl5?= =?utf-8?B?MEp5S1Y0VzFSYjQxUjRJTC81REgvNjVXRkpVOXZzSE5DeS9KNUI5WTdlMWJQ?= =?utf-8?B?YlliRTEwTnh2Wm9pV2dOSUJWbm5Yc3VheDduUmlkbVI0L2x1OE81L0xrcGI1?= =?utf-8?B?cmpvUmlrM2dyRDBVYXBTbTZTdGtsZ1ozWFp3REhNM05ENUg4UmE1R0tWVWxN?= =?utf-8?B?V0NhZDBBR2UvMm51RWpyVjBJMEF4cm9sT0dVUkp4QzJaM294V3VYMVNDRmxS?= =?utf-8?B?dHNzTHZ3RGpDNXIwRDhidmxHRVRVaXBJdDdxNW1jUmthYXljNEZFNjV6cjFu?= =?utf-8?B?MXlKVXNGdHg1Q1pzOC9kYnlpN0p2cEYvV20zTjlseWRod29FQTBNclh4MVFo?= =?utf-8?B?aUlFYU4rTzR2ekVJZkNyUHd3WDFKYkNNQThCdzBYd1o2cFRNZWtER3JSRmtw?= =?utf-8?B?UXdsRjd3WlgzZy90QWtIUjhscmZ0a2p1T1pZSUR5K2EzVHE0bmNsSFY1Tm52?= =?utf-8?B?QmRtUVhWWmorRXF6VDcrdU5YSFI0RUEzNmtoaFdqWW8yMktoVlAxR0IzM1Mz?= =?utf-8?B?eEhhZW9HTlVHaWFBYW9JcFdVU0JOZ2dqZ29DZko3VlpQTjN4dm9XZXJhT0Nu?= =?utf-8?B?VzBic2FBblNKMTNHbFVZNHJNbXFSbmtleGo5VDk2TW5Oell3aWpRT05jek5G?= =?utf-8?B?VWlCT1BuQlB4MkVjeFNqdEJnTTMrNXFQZStiSjgxL1pWQTJLYk14cVl4MlNx?= =?utf-8?B?VHUrazRhWk10eWJhd2QrMG5BQ0FUWGZ3TE5mSmJvZzhhSzZ5R0VYaEg5WmM4?= =?utf-8?B?QzFyOFc0UkxZdnZ6TEprbFdHbWNmcjQzSjdBQTRNcEFqdWxRVHA0NFZpQURR?= =?utf-8?B?bWlZTUF1dnhZOFRJUW1qRVdOUEYrNTgzc0x3MlJ1MWtRV1Y2ckNpblg0eFQ0?= =?utf-8?B?cnZaWStLdGRWb3J1TUJJRWoxanhENkYyclRyK2pyTlZKdWJPTE1hTnpTM3dU?= =?utf-8?B?d1oxY1laTXdMNFFFMlkxdVQyaTQwWFhRb29vRjNKUUhHMjRkeWRPeS93S2ho?= =?utf-8?B?K2tvSnBLTVYxYUpOVTFLZUhieDI5aXFQcFR4SjRJV3VPa1FxVG03UjE5MWFq?= =?utf-8?B?VEh1ZTRJakg1YnRCY1dGK1dsK1RMSlFRdE5oYTVVYStvbjVXQ2VxOUJnbmJQ?= =?utf-8?B?V2d3MmJIdnpXUHYwemdTRFVWQjVKdk1GZE1WM2VQem51bE10V3RTVUZpT0l5?= =?utf-8?B?SUxsNmhpWkxZQWJKdjlwUjBkTmtVS090T2VrRzNVZVRVUWFjbjE5RnVjNytk?= =?utf-8?B?T2c3aVZJNWhWcGhaNXQ2cGhkdDFMRHhWTmxjbWpDRTBxM3M2djhhWVlHMHN4?= =?utf-8?B?TE41cnZ0TXBBcUZRQlU4LzRjV2FmTklOM2lzUk1WMi9pUEtCaXAwTkxyNDM2?= =?utf-8?Q?Fr24=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YUMxazFQcTZGcUx0bGRoQlZJL05xUGtURThCcjBSK2IwRVpTQTFyaUZxeTJh?= =?utf-8?B?K2xkdDVUU1hHMjRUdVRreHNtR1hrM082ekxVb0FUQzNuVURIbWZYdXRwVGRx?= =?utf-8?B?SE9kakdEcE9xOWo4TS9Ya2NTQ1FLd3JFTkR1d281Y3ByVWpkTVUyTG9qRVlR?= =?utf-8?B?TFo5eDIwMzNqQjdpUVF5UlM1MU9FTy9URmpaVE9ZT0xLQTVlTlZqQ1hjWnpm?= =?utf-8?B?bEhkQXZtRzYyU2ZpUEJWbTluSTByM2c5a1pmeXdHcTExMnVpYWdEd2d6MVJN?= =?utf-8?B?bGdBSGJTRjh6NGpZMkJ2YjBYOUJESytNamMvWnBVUDd2Q1hCNERJUWpCNVk5?= =?utf-8?B?dmFUVkM4UDB4ZXNEVWJQYU14b0FNeEdHTUJlRFZXZFZESU1HcXl1Nmt2cmQw?= =?utf-8?B?bm90QVkzTG8wYkdncVhyT0xvSFFJNkFNd2RDVXFMOWxnTC9EMkhsNm1kVVM1?= =?utf-8?B?VkR4WDg3VndDWVVsZTd2Lyt2YU1vQ0ZYd3ltUDVJb1R5UThNSm10ZWRaQXFC?= =?utf-8?B?NmdwVE1kU1F6MjAzZnRWd0dPRjVDUlRMZkwzL0VMdkhWRUc3Smo5NmpMMmVZ?= =?utf-8?B?T25XRzRwVDRGdE81Rk5pa3g0RHp6aG1hNEJrNGMvcFN1Sk8zL2F6TVlSZGtr?= =?utf-8?B?bUxxWGpJbGFiSmVlYzdoZ1hweUlSc3FreUw3NDFIMEViODUvWi8zQjFnRXVM?= =?utf-8?B?R1RsQkRtQUEyaE5oWnRWb3hxTkt3dVZBSUVQb3Nuc0RkYnRtVDgrZW5qM200?= =?utf-8?B?a2ZDRktjK3BzM2s5ZFdjdDRjWDVqM3Y2NGVPdTdDdllZODRNc3JWRXRTdG9I?= =?utf-8?B?ZXM3SVhXRXE2dkFBaFFudkRPdzB6Sm05WFdHTmdUcXltTlBKYW4vMkU4TFdR?= =?utf-8?B?emxPU1h5WVhuZit0aVpXcUJrQ0lkSzIrOGlyQ1BZOHBtWU01ME1wSjlYN1ZP?= =?utf-8?B?cmtmM3d4MERES3JVTk9mQUhXM3ZkZmdnNGpLNGxJeFdQN0xucTNGa0d2cHlH?= =?utf-8?B?NUJzSWM2WmZIRDZLQlBpQ1gzdy9BNlpIdEhPMVJwR1NLb0hhbVNSS0hMYWRD?= =?utf-8?B?TDZKY0QyRXJQMDJ2S0tyZkh3Q0hBa0xuNzdvZkhvb1ZnL0UxaHlGaHcyWmQw?= =?utf-8?B?eGdWR28zZmpsVTljOHI4TFYxcW5MZjZpb0ZmRHdudHRZdzJIRjVtTVpiVFNK?= =?utf-8?B?aDllWitacUhNeXJ4bWJzNHVwSDZuellJNGZzS1MyVS9sYkZ2ZnR1MURhUWlG?= =?utf-8?B?U3crcTIrZkt1K2pwRURaRzB2bWczNyt0eWhKVzN0VktLTnU1bTFOaTEwS3Jz?= =?utf-8?B?VG1KNWlmSkZBWmpPTTFOY2srRFRCZDJFYUhMemQ4bzI1ZmVMY0Y5ck9CMjhE?= =?utf-8?B?UTZuejdSVnRjRTMvMW1LZGRiVHRIcHI1WG1iVkd6QlUrdk44NlpLK2x2dmph?= =?utf-8?B?WlN2cTk1UUcrenpNS0NEaVNSS0pFUThVdmJlMVMyMjN3bVN5ekxrNW5sUUhH?= =?utf-8?B?aXFOck5oR3VFeCtXdS9JNHAycmxFTWNWYTR0ZUQ0NnVsbHhxSnFXSnVRVlJt?= =?utf-8?B?SFJ0MWRjK2VnemRXbFVQczNITGRVeEF4eUIvMGc3OFVzVFNpeXg4ald2NWFT?= =?utf-8?B?VDVPc1I3NWZrRU5BR01PbjFXSDQySkNxM0xBSjhnS1I0ZzltR2w1bCtIK3hl?= =?utf-8?B?UEVaV2xValVqL3VzNXZoMm1lRnY0M2lQaFFWN0N3aGp4OW9qWkNCSVQ3dnRn?= =?utf-8?B?VlZYUUxjbjFDLzRTUDFRa29BVlk0QlF2MHl3QW9hN0Qyc1Rlb0E3TnZYTis4?= =?utf-8?B?VjBkbzRGQmxBTHVidVRaNEhEN0pwbmtoRXRhYUNidFRNenpKa3oxcTBuVUZS?= =?utf-8?B?ZTNWZ25SaFJoMXpuZVhGeW5XQjh2R0NFWXpmTW1mVncxRnhMVGN0K01IOFRz?= =?utf-8?B?QVo1RUgyd2lJV1A4OTBpUWJMTmRDekw5cm5xMjFhSDlYTXNrTllsQ0l0Mlp5?= =?utf-8?B?QUpPZFJiRzZsRkNPdWg4aTRIMXRralE5TlRvTFBkcjlJUUh4a2puOXNrbm9k?= =?utf-8?B?WEN5U0x5MDRyYzkxMEw2dUJFcW9CTnJjM2lZakF2NWxRV1hPandHclQ1SUV6?= =?utf-8?B?VmVaMG9PRUEwSnhCNEcrQ1ozR3V4RE02dURqSnBoR2I5cjlVQ1lvd2oyM0xy?= =?utf-8?B?N054SGVlYVZwMmVhZ0M1a1FBS0kwWFN1cUJGNVdSRlVHWVd2alZxWncwTmUx?= =?utf-8?B?aGVNeUluV3FhR3BXVDAwSmkwT0p6OWwxeXJ6aEVCdU0zOHF5dWhTTXREYlpT?= =?utf-8?B?Q0w5b0ZrY09pQTROdGZNV3F3cWlWUDJoMGNIQ2NoNjBoQkRLaDNtUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8c750eea-4388-483d-74d1-08de5f4ba69f X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2026 15:32:45.8798 (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: SHHpUlVd30GzgsJhCNA7HUtONSBPJSEa8LIvjF/WNIELa6cZH0HGHQr/mm7ifPRpPbtYtrajOzTHB+6Z2fQERQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR03MB5180 On Thu, Jan 29, 2026 at 02:10:01PM +0100, Jan Beulich wrote: > When, during boot, we have already correctly determined availability of > the MMCFG access method for a given bus range, there's then no need to > invoke pci_check_extcfg() again for every of the devices. This in > particular avoids ->ext_cfg to transiently indicate the wrong state. > > Switch to using Xen style on lines being touched and immediately adjacent > ones. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné One suggestion for a further addition below. > --- > v3: New. > > --- a/xen/arch/x86/physdev.c > +++ b/xen/arch/x86/physdev.c > @@ -528,6 +528,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H > if ( !ret ) > ret = pci_segment_iterate(info.segment, physdev_check_pci_extcfg, > &info); > + else if ( ret > 0 ) /* Indication of "no change". */ > + ret = 0; > > if ( !ret && has_vpci(currd) && (info.flags & XEN_PCI_MMCFG_RESERVED) ) Maybe it doesn't need to be strictly done here, but now that pci_mmcfg_reserved() signals whether the MMCFG was already registered, could you also restrict the register_vpci_mmcfg_handler() call to ret == 0? That will also simplify the logic in register_vpci_mmcfg_handler() since we no longer need to return 0 when the region is already registered, returning -EEXIST should be fine if the caller is adjusted. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 29 15:33:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 15:33:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216733.1526676 (Exim 4.92) (envelope-from ) id 1vlU14-0001c5-Nn; Thu, 29 Jan 2026 15:33:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216733.1526676; Thu, 29 Jan 2026 15: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 1vlU14-0001bv-KB; Thu, 29 Jan 2026 15:33:06 +0000 Received: by outflank-mailman (input) for mailman id 1216733; Thu, 29 Jan 2026 15:33:05 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlU13-0001ZW-76 for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 15:33:05 +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 cca27834-fd27-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 16:33:02 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-4806e0f6b69so8323095e9.3 for ; Thu, 29 Jan 2026 07:33:02 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-481a5e195ebsm6799705e9.4.2026.01.29.07.33.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 07:33:02 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cca27834-fd27-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769700782; x=1770305582; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=FNESxqxlFIjDAU4QM5qdfIM9OEBNjbf3UfqROLfs0jA=; b=FL4RCHt/h55Yr71d3aRO8aVrF9UbCG/nm4xhmapBxoHmiXV6cuhQV04bN3pl4UBF7Q bgcnQDvWR/qImitUmvbZOZnAFIEezohyzT1Fu/Crt1i9r/ikMLk4naiFoMM++YLFuwe5 0xgvd7NPf3tWfMIZGZEeW3rYb/RSdEKtWrsWf//RUF2Wlix9A8EXF/XI+VmudftUwPxe ChW3SBvoEFluB/8e4dFfHUBxuIkcEhZRdB1pdw10IWO7tm0Xq4/ipHkXeb6op+0t+d2g NDYnXoDf1jD3gMsMS5cMPrLQ59tpkClrJ3iUGsFMBwZpiFXHwESQpwbEBomZHDbueiiN g+bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769700782; x=1770305582; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=FNESxqxlFIjDAU4QM5qdfIM9OEBNjbf3UfqROLfs0jA=; b=Fy3cqROrIZjz4WgKuRtYMWfyTOnB/Wgyc7hVBkUJwi5pfEpnwpCdThMwsLEGZEmYR3 j9mViwpKJSeZmd+pc4qtlAuvDEdNHnqpg5E8FPgbauEQkHfmK83tw/ArdPtAadTToSKu NPn+2mkC7/rg/aiKPZHIMdm6KetjAlyhF5x8wbd1Ib8Tkps8DafiP61QXJz4QQ9S7x82 79eABQuuuE4sUkx8bC04kwNX48uAXksBPPOAF+fxumtRbmDe3SzUzStxedMg98mQW/ZQ sXwLHYe2R2SAhWOc/gD4M5rD34BQFCljMbNWeaaWceca1Ho9ACGWLv2fWtyYfPesXjgy owGw== X-Forwarded-Encrypted: i=1; AJvYcCUK6PzasvDZrehAzhGyyojYIX1MoED1BgPAlYjAn/OfxDxK2cXVR+5aVSYbn8csKFSHlRJe4GPl2QE=@lists.xenproject.org X-Gm-Message-State: AOJu0YziDykrrgg5DTm/cIcdWvlOvvMdx1149GtoDKdp/4gADzwQXjwN HC5oUzrmvv8wjXpL1otqvPso8xpmWYs8zDz9RzCOQ/AAYL9uwMLYSsevJA/2IAnJMg== X-Gm-Gg: AZuq6aKlzaRPOwFAaeNjEeP9XpaQz299Ik7Fc8+vfJlF7fOuRH/xlFN/ctUGTWQknX6 3+ZI1SunP9l2/d/kJbFEGN/Zz/a9DrLnMhDNUWx6wGIPstV/fINh5yCfeHDd7/UjYT3cxG1gQc5 GiuS7PjbJHF/X1g/gtm5AQJNYNPNIWApypE8fY/qUepqAI6YrTrObkIXDxPGwwOs/e3S7PgQXKo PM5ldQOn3L8To/FSNZXpKhUEMjMnxiPWpSzaAmEeQOCGVt79s8Gb/hR7WQ6FwIA5w3H06li5oHP CHAra91+//M3HQc97ddl6BDVKm9MOfpnp8LYoTh+Gy9DsqagxRcn1uCpc3lu4RnG48qtK7obfk1 voWHd3h+9z3/Veiq2P1BA9j8QnODBxlJNKdergAVRBc0j/QuUtkm0ClaYdzX1cohjkOAXcVuxrd sYgCedEqrqHSPx6aWPJRBZqIszu5coqAa8YpKmEA4++MKb9BoKxoAN241WcMD7gFjqHVwx0LBSz MiIPR+DT9ut2g== X-Received: by 2002:a05:600c:620b:b0:480:39ad:3b7c with SMTP id 5b1f17b1804b1-48069c16922mr125053255e9.16.1769700782288; Thu, 29 Jan 2026 07:33:02 -0800 (PST) Message-ID: <1c69cccb-6247-4c2a-9011-2ebbae0f77e6@suse.com> Date: Thu, 29 Jan 2026 16:32:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/EFI: correct symbol table generation with older GNU ld To: "Daniel P. Smith" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Marek Marczykowski , "xen-devel@lists.xenproject.org" References: <27f291a3-6546-4834-a9cd-22a4636b152e@suse.com> <2506be14-5615-4221-b6b9-079c709fddc0@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: <2506be14-5615-4221-b6b9-079c709fddc0@apertussolutions.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 29.01.2026 15:44, Daniel P. Smith wrote: > On 1/21/26 5:05 AM, Jan Beulich wrote: >> See the extensive code comment. This isn't really nice, but unless I'm >> overlooking something there doesn't look to be a way to have the linker >> strip individual symbols while doing its work. >> >> Fixes: bf6501a62e80 ("x86-64: EFI boot code") >> Reported-by: Roger Pau Monné >> Signed-off-by: Jan Beulich >> --- >> Should we try to somehow avoid the introduction of the two symbols when >> using new enough ld, i.e. relocs-dummy.o not needing linking in? >> >> --- a/xen/arch/x86/xen.lds.S >> +++ b/xen/arch/x86/xen.lds.S >> @@ -339,6 +339,24 @@ SECTIONS >> *(.reloc) >> __base_relocs_end = .; >> } >> + >> + /* >> + * When efi/relocs-dummy.o is linked into the first-pass binary, the two >> + * symbols supplied by it (for ./Makefile to use) may appear in the symbol >> + * table (newer linkers strip them, for not being properly representable). > > Just a suggestion, but do we have the minimal version where the > stripping is handled properly? I just think it would be good to have the > minimum version documented here. Doing so would make it easier that if > the minimum supported build tools are bumped past this version, > hopefully someone will either remember or notice the comment and could > drop these declarations. I've changed this to "GNU ld 2.37 and newer strip them, ...". It's always extra work to dig out version boundaries, and then the other toolchain (clang/llvm) still isn't covered. >> + * No such symbols would appear during subsequent passes. At least some of >> + * those older ld versions emit VIRT_START as absolute, but ALT_START as if >> + * it was part of .text. The symbols tool generating our own symbol table >> + * would hence not ignore it when passed --all-symbols, leading to the 2nd >> + * pass binary having one more symbol than the final (3rd pass) one. >> + * >> + * Arrange for both (just in case) symbols to always be there, and to always >> + * be absolute (zero). >> + */ >> + PROVIDE(VIRT_START = 0); >> + PROVIDE(ALT_START = 0); >> + VIRT_START &= 0; >> + ALT_START &= 0; >> #elif defined(XEN_BUILD_EFI) >> /* >> * Due to the way EFI support is currently implemented, these two symbols > > With or without the suggestion, > > Acked-by: Daniel P. Smith Thanks. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 29 15:40:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 15:40:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216754.1526687 (Exim 4.92) (envelope-from ) id 1vlU8J-0003Yi-Fp; Thu, 29 Jan 2026 15:40:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216754.1526687; Thu, 29 Jan 2026 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 1vlU8J-0003Ya-CU; Thu, 29 Jan 2026 15:40:35 +0000 Received: by outflank-mailman (input) for mailman id 1216754; Thu, 29 Jan 2026 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 1vlU8I-0003Xy-BJ for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 15:40:34 +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 d6510eef-fd28-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 16:40:29 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DM6PR03MB5113.namprd03.prod.outlook.com (2603:10b6:5:1f0::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.10; Thu, 29 Jan 2026 15:40:26 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.008; Thu, 29 Jan 2026 15:40:26 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d6510eef-fd28-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rRDQiOQofRzgWsRb6++YbTm+raasV/Puw5g6wUqlQTk1Gy2/uF6b89IoPHL0MfCbp5GVSJEfagb2VoT2pwHXYY5tJQzkn17gC3uY+cxifaG7teNX/as5E4IoOZ978mAj+WFSn61ber8EAfpFSuHa2y/C0vU5/pChOg6uqP38oRJVlCVznQ1i0+H4jIdNtgTHzhF3BsMp3ihihBOGW3hnml/ytUatgVN76i47uIQHKM9CyTT+5tru44C+QQWbsgQ17yrTIWzuSkbINvWELCyDnBQfWrgwLyxJSNxiiyJKbOAxgOq0OFcCwB3bY2tSDAo8knXniSBXRjxGHF9ql8Bzew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4dwL8rrY/y++f5OGvSXoGfG00JAjbmmn1Q+mF9wl2pA=; b=XFrRzp86MQDoe02ZIec0XqGkY6xJwGN/fQK41WzqiVJia6z765S2lyROjpgQyVTDYxezIlOAxkXf6dGNT48r7kOJMYu0JwaXc/mf/mzXrm9HJEAtoOIhvhLMB7yNx3QN6cNuyAYeJ8w+sXaTGX5qGU0f3Wa1TW5qNATwBT7qFp8t+8W3rQWcej2DdJuszIwOdTz04OEzuLHu8cq8iKFu3iff0wdghIn2pBAQ0M2HxGwUd13nuof3rse55Rv85qXI+SLALEfsGk64yEe0hzQ+K2LI/IPohi8IBDsaYPN/9+nU9nDkQuSySJHbOwbI7tj6W+zx9zOfh7DFId578R4j+A== 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=4dwL8rrY/y++f5OGvSXoGfG00JAjbmmn1Q+mF9wl2pA=; b=eTzmyjywoWKTZLR0IVTblbnyMTn9vzYIlBZKZtKbyyNVABnUonB15r7/6op5OZkLw2HSDKJAAnggs9JoVpYIjWy8HBe0f23rQb8mWnXK+7lWwHJfFDZDiwjJmNvphzjMKEsTvayGVb5HCbn2aF8Ny0thwgZHRX0HzzmsfJxhP8w= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 29 Jan 2026 16:40:23 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Stewart Hildebrand Subject: Re: [PATCH v3 6/6] vPCI: re-init extended-capability lists when MMCFG availability changed Message-ID: References: Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: MA3P292CA0073.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:49::13) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DM6PR03MB5113:EE_ X-MS-Office365-Filtering-Correlation-Id: a63217c5-129b-4089-d698-08de5f4cb90e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?NnZZM0JyOTNxdFlNTU0xclZRZ29TeXoxbzlWQjdZNlowc3Y5UE43YkZ3cFl1?= =?utf-8?B?Z29nRU80Y3cwSG5qbCt2NmtBRlJDT0RNc0pmM0tNQnl0VkJtNEhDSzdqVkE4?= =?utf-8?B?M2h0KzlvVGNxZllYYjlsWWxCcU5MRkY1VmdZRU9rMmhYNDNTbFV3bTFlOWk2?= =?utf-8?B?dmVYRDhnUDU0VVZ2Y2lJV3B2MDloT1JVc3VTazJIOUVnSFlDZ0daS3pOUlJi?= =?utf-8?B?OVAyRGl0cFY1elozMFhyRnFCUXU4WTF4bmZEcWFxZzBEQ09VUFpBaC9aYXBZ?= =?utf-8?B?TnQ0bENhREh6RDA4dVNSRUp6U3FGWHBFNktzYmdmaEpXWklPNzkyVlZ2UEdV?= =?utf-8?B?R3RYaG9Bb0VuYWkrWjJtUnpuL0daclVHclR0NWp3bDRQbWgzcGorSjBaUy9k?= =?utf-8?B?RGwzYmdYRjREdXRWdGp2OWREMDN2dUNFUUU0YWY1bWg5S1hnZU5XZDRudUZy?= =?utf-8?B?OFIrOTFScm94MDlyUnpZaDYrNXhHMWVkRk9rME5LcWpKNW5CL0xyRTNoQlhi?= =?utf-8?B?WFRHbXNvZTg5SzZKM3lJdTAwRTEwTHhFNXYwUkI2NHZWOHY0MWx6STV1S3c1?= =?utf-8?B?YWtlTGtsR2V1VXltQnNKbmZ2VUdtcWE1NVRuMmtLRG5FRkVwdk82dGR2MlZo?= =?utf-8?B?WDluRHlQbWo0dys5eXU4RkNrRWw0bDNiWG9BSHVlVkJhU0JPOVdBUjhpdFhh?= =?utf-8?B?a2QwTGR4ZklwekRRd2QzSXQ1V2NZMkhKeWIrSWplR2VxdTI3SXpBdTd2RnN2?= =?utf-8?B?MURTY2x1RnlCTkhtRWdqQXZjK3Y5STlYN1JyY29oa3RoZGVRVUJGMnNHNkFx?= =?utf-8?B?T1dlUmxPUG5lRkJ6eWlSVTRadkFxRGFVcUJBL0VWSmp6c21ZSUNmR0lRclp3?= =?utf-8?B?bTF6eGU5WUo2VnN2VWlRNDhKdVR3ZGU5aUttVkx5bVBSL24zMEIxRUR2N1pw?= =?utf-8?B?MU9BTkxBajdQbHRueXNxeFY3NHFyQjdEc3BWZ3dpT1dpRWg1aTZRcUhvSmxE?= =?utf-8?B?bDZpOVYvRlRhZldZbVkvb2dEbjhWUWpKOGVGVVFFSWJVcnhIVEhYcVoxUTND?= =?utf-8?B?N1FUcisvVjNQbUJNMDBMMEhya2hLK21sd1RDcDJEVlN5SmNyVC9mWkhBZXRj?= =?utf-8?B?eVpvNXIreEs4dk1XSnFtOThpSEpFa290N1ZWaThwSStibzlvODFMbUJEYXQ3?= =?utf-8?B?WnJ4dXhCQkVock9vcHNyeGJQSDZrak0ybkNndnBjREtqV1JzakRYSTJuaE4z?= =?utf-8?B?ZWs0K3dNajB4elV6TUIvb2N4YVlCMDBPS2tGejRqTXpDTXpDZndNZnNBL291?= =?utf-8?B?MnliWXE3S0h1YUk2YUVYbmZ5dXh1VzJvTmtuOG53UW0zcW51eldqY3V1N2Iw?= =?utf-8?B?N0FRUEVzMXZVd25HaEVLSEpPL0J3NDhsSGxYUDYrOUQvZDBpOVhjOEcrcTRY?= =?utf-8?B?K01iQVpRYzEyRFZ0VzQ1SHV0MFpqdjVFb3lEZjZabGFRdUVsYzBKY2tudUtt?= =?utf-8?B?bHltclByRWlXSWw2NXBHenoyV1JwUzdQSkJYYm10b3dXZkFEQWpMRlBFNDF5?= =?utf-8?B?NVZlc1U0N0lvaGJoSXJIbGw2QjhqMHpMNmJmam16L3dvU2NOZnd1OWp0WlJU?= =?utf-8?B?UGRmSFFkcDRFUitUMEswbHdPZ2h1WjRoMVBYOVlCY2VzaEQxbVUxTjJXRWJu?= =?utf-8?B?NmkvTnNOaEhZWlEvTjh6UG9xWFRMUVEwcEJlejRGcXI4aWVJSzR2RzNsRzRL?= =?utf-8?B?ZXQ1enl3N3FFcGhDVkpjKzRHNFFyajY5OThZa0VCUlVhTHFqUXh6eTMwMWdm?= =?utf-8?B?VVYrUEhCVm81RmkzMFpOcVdFYlljZk5EUXFocGV5M3BYMkZCY3c1azdmajRt?= =?utf-8?B?Qlp0cExwU2ZUKzVJSWhmUDcrMXA4MHBjclVPbm45TVVlTUZ1Rm52NUY2Q0Jj?= =?utf-8?B?cmxXZ3NkQnRjOG1aYVc5SkttZGNkOHp5MllsVU1YUkkzKytFWU9ZSmw0V2xI?= =?utf-8?B?Z2p2QnVPcVBVS2hQZWY1M0h0bEJKcDY1d3JkVWJSak9oa1Y2MWZ5Wm5sTW5D?= =?utf-8?B?ZlRrQjRmRWdaU2hLN21MVXJjOHlUZFFrUDVJNlZ1eUF3NWNHVno2VFE5VnBX?= =?utf-8?Q?NroM=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eFRkVjhRMWgzNDFyS2ZNWXZEdUZLdWFLMjFhWENaaHVrek0xRzVyc05BeXV6?= =?utf-8?B?bnFhRGVhSFlKNE5YeVdxVkt5Z3JwcDJ2RWVLUlNhV0Y1aTZZb2NlNW5TNHho?= =?utf-8?B?ekxYaURDQWhidXNVQmNXK2R2NkRTRWU2M2puUFJ1YTRTVkZCQ2lLWGZWNk9B?= =?utf-8?B?N1ljRkhIb2loMm1oeXY4RXp2S1ZGbjNsK05yQjhRbWFYUUJQOFcxbFMrZEJi?= =?utf-8?B?YXJ6bWd2OVlvcVU4eStEa3p4UzhYaW4rTTJLTTRWSUZCSXdMcHNqMHBxYUYw?= =?utf-8?B?TXNhSjNkdnU0OXRiTlNNSlI2UVNQL1pXNUJaOFVJWmpNUkpaTWRpdDFLSmJH?= =?utf-8?B?TmlKVGp5czI2YjVoRzA3ekcxUzdZNFYvblcxUUFjeFozdk42N2xqRWtOZ295?= =?utf-8?B?VVljemtncm1ONlloV1duZTVlUGpuNWRzT1laQys4cVVTSXYvb3dUZFQrR1Jl?= =?utf-8?B?RGpqUHhBMmFqNWRKZjY4UHVKeUt1eU5QbzVVd3Q2cWF0OEFpQ0dhVWN0Yy93?= =?utf-8?B?K2s0RWtSTWZJVFNoZitwS2d2Y3NhYXJhempKaUJTNnp1SmRwVVoydFArME5T?= =?utf-8?B?aGtKbjBnT1pUN3E0ZHJWZzlNWHJoWElLa3dMUklDbVlhK2N6M3RtOUpUNUdw?= =?utf-8?B?Y1hlWjh2eE91eVpoYkd2b3REMU5aOUxuN25rb09PNXcrVktVeWlFd1JIZFcv?= =?utf-8?B?dWVDQ3d3Vnh1ajgvdlhOaGF2Q2IzTElIM3djaW1OQmcwaTJ5bGpBVDBvaFZD?= =?utf-8?B?RzVVY3laWElZNGk4YzRkbVFQbnMzZlFXbUR2OU1LcnR4ZlQ3bWlubEU1Qk5p?= =?utf-8?B?ZXYwb2JMK1dCQzFDUjNmSEdhUmE3NW81TWgvYkdCM3lNYjdQaU8yWkkxVnh4?= =?utf-8?B?ckk1MXZIUXozZFFXUGV5LzBVMXBvTDg4MVZoTXlJQ2QyZDNCcmRKVGpEam5o?= =?utf-8?B?WE1NUkZLWWhzaFNiSHNzUVRkNmVXN3VIS3loQWRNVFh4Y3Y1VkcyZSt4N28z?= =?utf-8?B?S1BzUkxaVk9KZ3NpTkY0cG1kZ3A5aitHZ1A2c1o2VlN6SlV2RGV0eXFvTjFG?= =?utf-8?B?ckdyOVlMYjhLSG44YkF0K3hsejhacHRhV3drUC9XNnU1ZytIL2RmUjV4UmVL?= =?utf-8?B?R0w0VnkvZnAwcE5TZXVSOGQ4UlB1MDhJTGpHTU5hVlFRRDErOEVZQndsR2N2?= =?utf-8?B?OWNWdy9sNHpzNytGeUhUUkZ2STRmSU43UzQrZFR2Rm1uZ0ZKcUtRRGZQMFda?= =?utf-8?B?WlRHT3R1N1FmQ3hUaHdielphUGJhUzNoNGZOaFY5TTZTYTNrNXA5L0tJVzJn?= =?utf-8?B?TFRSLzdUQmFuQUVwZUwvRkR5NXlpaWNEWnhKM0xtMnpsdHp3bExZUHhrNktk?= =?utf-8?B?ZHExNEJ1ZHU5dUlUSVhJYUJNVU84RlR5UnRuTXlUNHZ4SmgzRVN0ZGlFR2hJ?= =?utf-8?B?T2MxcEdWditDSlpZeTVUd1dFcy95SG4yZ3JoeUxCd2VRbFA2VXVFM010WW9O?= =?utf-8?B?aTRDSmI5cE9kb1ZlYlJyWWIwTGRDZFA0UjByemRWM3FmR1YzTEF4b0R4TDh1?= =?utf-8?B?TCtBY0tUb285aCtoOE1HR3E3RDM2bS8xdk1oL3ROd28vWTdOTGtjTzZXN3dG?= =?utf-8?B?bVV2QWF4dEFlMG1kQmQ4a0Z4TUI3K3pHTUxtYVExKzkreEJKWWc4TlBuZUZV?= =?utf-8?B?elFIcWY3NXA4Sk0rUU5yTlc0ZkpYdm5oUldwTWFzcEsrbDV2V2RrYlhLTDlG?= =?utf-8?B?Zk9lTzVsMUlnZDRpeFdSNTl1Z2dlcnNSeWRhWllDOENCSFhMeFhESHRiMzhD?= =?utf-8?B?ZzNraGhFSDRtc3RrTU9XRzJNdjRJeGJyTjZPckp3Tkh2Z0NCalpYOGVKQ2Rv?= =?utf-8?B?NysxZDRkaFFpbU1tR2pOSWpzaUwveE9BaGE2RGcwMGs0cW8yQ055VjVocmNS?= =?utf-8?B?NnVSS3I3dXAvWXVmNXJQc3J0WkVqdjBBY09oN1VhcElIT1pYZVhwZTRPdGZB?= =?utf-8?B?Z3hVSUZ5bWZDUk50dmVjWFNuZWhEeklrZnZGN3NkZUlZTU1xN0NNeU40bkpH?= =?utf-8?B?UGMrSjNlNGVQYVQrMnIrQldkb0FscVVWMGxPV1MvOW9JRktWZ3hMQ2VsQSsx?= =?utf-8?B?d29icTVrQy9CLy9meUJSODM2Unc2dy9mc2ZNOU1UK285ZmtXakhtU0o0MDh1?= =?utf-8?B?L2ExT1RRVnkvdEhFbmEzNGFzZ3RuZGo1Y2piRjhHVTU1TUVld0NyUGc3Uy8v?= =?utf-8?B?NHg1WkttdmRZM2hQN0tWUlAvb1h4Z0prM0dWa3oveWNsV3dZTEFiYW80TS93?= =?utf-8?B?UTd5UWs2TW44cDVzR1RFNk44WXhSNTVrUjFGZndETit3QlRwLzVYZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a63217c5-129b-4089-d698-08de5f4cb90e X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2026 15:40:26.2598 (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: vrhwxFuHA5Xt0tltP+y5KQpascGEunknfRRHBeghOlHY9OkbmXMOtNiHdg2hV7o5vfxjrYDczLAU83ZUAUjvXw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR03MB5113 On Thu, Jan 29, 2026 at 02:10:34PM +0100, Jan Beulich wrote: > When Dom0 informs up about MMCFG usability, this may change whether > extended capabilities are available (accessible) for devices. Zap what > might be on record, and re-initialize the list. > > No synchronization is added for the case where devices may already be in > use. That'll need sorting when (a) DomU support was added and (b) DomU-s > may run already while Dom0 / hwdom still boots (dom0less, Hyperlaunch). > > Signed-off-by: Jan Beulich > --- > vpci_reinit_ext_capability_list()'s return value isn't checked, as it > doesn't feel quite right to fail the hypercall because of this. At the > same time it also doesn't feel quite right to have the function return > "void". Thoughts? > --- > v3: New. > > --- a/xen/arch/x86/physdev.c > +++ b/xen/arch/x86/physdev.c > @@ -8,6 +8,8 @@ > #include > #include > #include > +#include > + > #include > #include > #include > @@ -169,7 +171,10 @@ int cf_check physdev_check_pci_extcfg(st > > ASSERT(pdev->seg == info->segment); > if ( pdev->bus >= info->start_bus && pdev->bus <= info->end_bus ) > + { > pci_check_extcfg(pdev); > + vpci_reinit_ext_capability_list(pdev); > + } > > return 0; > } > --- a/xen/drivers/vpci/header.c > +++ b/xen/drivers/vpci/header.c > @@ -869,6 +869,18 @@ static int vpci_init_ext_capability_list > return 0; > } > > +int vpci_reinit_ext_capability_list(const struct pci_dev *pdev) > +{ > + if ( !pdev->vpci ) > + return 0; > + > + if ( vpci_remove_registers(pdev->vpci, PCI_CFG_SPACE_SIZE, > + PCI_CFG_SPACE_EXP_SIZE - PCI_CFG_SPACE_SIZE) ) > + ASSERT_UNREACHABLE(); > + > + return vpci_init_ext_capability_list(pdev); Isn't this missing the possible addition or removal of managed extended capabilities? IOW: on removal of access to the extended space the vPCI managed capabilties that have is_ext == true should call their ->cleanup() hooks, and on discovery of MMCFG access we should call the ->init() hooks? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 29 15:43:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 15:43:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216764.1526697 (Exim 4.92) (envelope-from ) id 1vlUBG-00044x-SB; Thu, 29 Jan 2026 15:43:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216764.1526697; Thu, 29 Jan 2026 15:43:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlUBG-00044q-P9; Thu, 29 Jan 2026 15:43:38 +0000 Received: by outflank-mailman (input) for mailman id 1216764; Thu, 29 Jan 2026 15:43: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 1vlUBG-00044k-5s for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 15:43:38 +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 45d15303-fd29-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 16:43:35 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-47ff94b46afso10205025e9.1 for ; Thu, 29 Jan 2026 07:43:35 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-481a5d64e84sm6934505e9.8.2026.01.29.07.43.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 07:43:34 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 45d15303-fd29-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769701415; x=1770306215; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=K3M0D+2vMkG/JiL3ryK/fSU6dBdjb9kIbYCGZYfg1yE=; b=XwTSLMOzxr6kI4Mt1rPWgEju8nfAzKd7i/6YNpXUafC9moMrH8799Xd2yCQsQwpJG8 T3x2SyOZKcJnMFEvosAEelzShmXZjWy1IwJRTUwpiFYywMyylBm9WM6s8gVoE+kulW+l nniEy+hsdDIIY9iu7eqjMgI17GqHY7RLAPL8LsmWaIw3pqYjydn9Nw+Th9q8sKPozKo2 KO2HfBabkSPtvherynKN0IOvvojVwpYwtVNtB9q/kravtAW1YDZr7eysPYmIDplwjw+Y 9VQ0CKE9mc2r410UPusnQFjaEkmXvj3dW6VBsmqMdBNvunvCT2WwvAoXgKvESBLgAw8h wK2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769701415; x=1770306215; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=K3M0D+2vMkG/JiL3ryK/fSU6dBdjb9kIbYCGZYfg1yE=; b=Bl5WsoLQbUiPiqKkvU6GqAZZvbO1ZYujMA4jsnUQdQMu4XZP99kPDFhiAtgqHbQgfE Owo/zVY1ofL5A/PaESA9RZxLLvXsMHEMBbGevyeAVuCyzeg1zQdlaEcItjb/OMz6bYY0 CyNPh6f3WIn75NtPaweLEB1Xh3I4B7VYa4Iiqf/XUYcs6kSu/S1CUJPGWv39NreAqXug EG/yTY+3mRfTsXyoDkcjP6Af6lgFikoKzGB3qRQS6ZRqQAPsVKh783Y2+DuZJ1ZxyzkM YXeFouMB7L55y6O9H+JpSfiGEg5T7bnmw48P2Q/o70UkVfcPE65odW8pE2IkO+CMXm5A USuA== X-Forwarded-Encrypted: i=1; AJvYcCVuBbWlSHk9XOPFNSpx8QWdfx9G32uaaYJq0lkh+s3XRot0sryoTO+9don7e8psImoBjErfFdJigks=@lists.xenproject.org X-Gm-Message-State: AOJu0YzuWGeSPmIFIFfR3LhZ8f+BZBEuYARUsjumVgklWilpGINi4MEK iVXp1ErnkcWtMTNCLHFxi+azgX86J37Rd7qp07wZHQwrgHc1L4n/KaaO3A4nWvxlhoViWoZK+Ou eyNg= X-Gm-Gg: AZuq6aKPs/RuBJmyNZ7Nb0i1Fl79kWaiWqEJ4XW1qyqXj6FZ96l7fkE+RI5kE20ATe8 omZfmS/AZX8OHES4S59ynTeHPcj7jxCIq6W9RnfCotgpg+I1593TDpCC3p5RgMR9cket/xWEfZm 7UivI9U0H3glImH00iYojx9d876Me0vYw7K5jnluUl3dQY1Z3U0IldDrtjiZxGdaLrwzinrkaPI p2i9M4n4CROoy8VqylhVlE70QdfPs6tYOIlQFwdcWkdZsyTj+asvoW9JAcKR1Vwx7HQ8iE30T1O wpvtBipMEbMraUJaMgkLPQtOlYQmrE64NZdPKoV1N5xJEEfxQx8R00EnXkpTImOY5RmDOmjj6hZ RmLceYogFd+RrewOItQXMBBvm4Qb3y1iuY6C1DnHNzBSKzswuz4WQWytYvAhlOxZpWEUqKPIrT2 KCJnFNagsBSPZw0Q05r0L6OLXCOXe2wCXkTgO4QEVVRnBXR3E3LgHGC1SkEKIsf9PVI3Uhn8Hhs uA= X-Received: by 2002:a05:600c:81ca:b0:47e:e59c:67c5 with SMTP id 5b1f17b1804b1-480828a6f7dmr43752675e9.8.1769701415143; Thu, 29 Jan 2026 07:43:35 -0800 (PST) Message-ID: <3b2a9dbe-fa14-43a3-a7c3-a4c1396a5c70@suse.com> Date: Thu, 29 Jan 2026 16:43:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] xen/riscv: route unhandled interrupts to do_unexpected_trap() To: Oleksii Kurochko Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.01.2026 15:40, Oleksii Kurochko wrote: > --- a/xen/arch/riscv/traps.c > +++ b/xen/arch/riscv/traps.c > @@ -196,6 +196,7 @@ void do_trap(struct cpu_user_regs *cpu_regs) > { > /* Handle interrupt */ > unsigned long icause = cause & ~CAUSE_IRQ_FLAG; > + bool intr_handled = true; Of course I don't know what your further plans are here, so maybe doing it this way really is desirable. As the code is right now, I wonder if you couldn't make this a 2-line change, ... > @@ -204,10 +205,12 @@ void do_trap(struct cpu_user_regs *cpu_regs) > break; ... using return here and ... > default: > + intr_handled = false; > break; > } > > - break; > + if ( intr_handled ) > + break; ... simply dropping this break altogether. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 29 15:47:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 15:47:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216774.1526707 (Exim 4.92) (envelope-from ) id 1vlUEq-0004cy-AI; Thu, 29 Jan 2026 15:47:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216774.1526707; Thu, 29 Jan 2026 15: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 1vlUEq-0004cr-7b; Thu, 29 Jan 2026 15:47:20 +0000 Received: by outflank-mailman (input) for mailman id 1216774; Thu, 29 Jan 2026 15:47:19 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlUEp-0004cl-J2 for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 15:47: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 ca0c0eb9-fd29-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 16:47:17 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-47ee937ecf2so9509775e9.0 for ; Thu, 29 Jan 2026 07:47:17 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806ce4c3d1sm141106715e9.9.2026.01.29.07.47.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 07:47:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ca0c0eb9-fd29-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769701637; x=1770306437; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=faEELfnZlk+DnBUx7Ezay4imuuMlevSLumPBQ7F7zxI=; b=R8k3uJE8RTa1xzIe1K5/va/R6bcUct1MC/hNPh3tWcTKhU9kskqKWDxr8wMuz/yh0n 7+lxrJ34NyOEN2IsbG4fy1W/sWZIH7uCNsPFu0Jmbnl5l5forBmUvufIdVc3kZpgR1Js nccq5sAaZDtsNBmxTe72Qt1JvHUm688N8z4gPtpW2WUJKq/ZhWOF3F41lXrv/GlDGB20 7eP0we4eo18tquWMVXnTDIRCwXuAUvYHdSl1hW2ZYeeh7RJ4+m+FcMfYpxFk8hjaJTu3 LczxspM5yUZep5F1MA1qnEkmcezi8v7mYHfn0Da4e13EKDh/JRUjFdzjzdT0q2iruYnU xlwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769701637; x=1770306437; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=faEELfnZlk+DnBUx7Ezay4imuuMlevSLumPBQ7F7zxI=; b=T+UXI8AqCIxKfajzuo8eCw4kL/3c7REfkoeCKtW7Waar2XopPt4OrLBGO0V+d0SlNN gQiP9HXp0VF81R95rDlHLnk1GP9os6EPKkZuwtttnkcO3OT3GD2JiAt4mGbN0/HwUoh7 0Ja75L/xarpPfFleKuL5avzLPoYmUTJZcSb5j9zCJ6twPjmrNMe/OYFdOZpXGXuWS8nP GkD3swDxYgUA2ZuLU2oErpvEKTP+f/ikpzgVpQOFepEQC7eqYKoxSYjQNTBlMOruAUNk +3j+cWkx3yJthG1iBBwxeAvF2YRrQZyAaeBLkRSdZtbP3OvDvPNOm854BXAqe6N6fHbN ORXw== X-Gm-Message-State: AOJu0YxG7WXagyAUtU/OdOWjdnC3ctm6Fh513etsc/KKA0TeuY3djDFU 7372+VEJuwIkgRZjm/vL00309Gs3qL9rPC0UAwSg9YlK1yHL2fPArgKYL+PSKfbUNg== X-Gm-Gg: AZuq6aKfI5L5pMQODbQU6xLSV0LK3Sw5BXY5eiiW5PGmOrz4bfVz0qXWMzfxa1hy+OL SGeQlO1Tgx0UHilaVAA7NVKw2RG3Q409GKRBNn2IJJv8lctAI6NNSdAgMpqJRWJi+e4Ht91kgwv LLUV/H/8Lng/EHPrmZdvrKKG7jjdrhwtoBBw9SJyLz6fY/oFtsGT1ldI0iYyjhOboB1vjJQBjPo 3WZ9p+lRRk+pvWLZrsyZsldyY0LbVNqGxbWwaPjeZut2uysXrY2FyFNGwRw2unjLHjq7eG9yfJy ikBC04vDMsm9L4DKj2vUfqE1TIu9E19izX2DWTdGQ/YQwNpEnm8tP8b7lUOUYzfEQfCwDZyl93O Piqgu2Qqbn/01TPbwRveCZ/fQSFq/nZa0Or5fDv+TUXGF4P2oJszxNU9WTmc8mv0jiENht+RIwo Z4DBVMxjbsjeqbw4jrZTmTsWjWQGJqzmAOMg7BxcHP1KRtydT9zaplxPo7e/NwBJ3P8v3eGTmAO 5M= X-Received: by 2002:a05:600c:6489:b0:477:9890:9ab8 with SMTP id 5b1f17b1804b1-4808288f60bmr45605205e9.3.1769701636890; Thu, 29 Jan 2026 07:47:16 -0800 (PST) Message-ID: <8132f09b-74b5-41da-a136-dc59c2d79e98@suse.com> Date: Thu, 29 Jan 2026 16:47:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 5/6] x86/PCI: avoid re-evaluation of extended config space accessibility To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Stewart Hildebrand 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 29.01.2026 16:32, Roger Pau Monné wrote: > On Thu, Jan 29, 2026 at 02:10:01PM +0100, Jan Beulich wrote: >> When, during boot, we have already correctly determined availability of >> the MMCFG access method for a given bus range, there's then no need to >> invoke pci_check_extcfg() again for every of the devices. This in >> particular avoids ->ext_cfg to transiently indicate the wrong state. >> >> Switch to using Xen style on lines being touched and immediately adjacent >> ones. >> >> Signed-off-by: Jan Beulich > > Acked-by: Roger Pau Monné Thanks. > One suggestion for a further addition below. > >> --- >> v3: New. >> >> --- a/xen/arch/x86/physdev.c >> +++ b/xen/arch/x86/physdev.c >> @@ -528,6 +528,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H >> if ( !ret ) >> ret = pci_segment_iterate(info.segment, physdev_check_pci_extcfg, >> &info); >> + else if ( ret > 0 ) /* Indication of "no change". */ >> + ret = 0; >> >> if ( !ret && has_vpci(currd) && (info.flags & XEN_PCI_MMCFG_RESERVED) ) > > Maybe it doesn't need to be strictly done here, but now that > pci_mmcfg_reserved() signals whether the MMCFG was already registered, > could you also restrict the register_vpci_mmcfg_handler() call to ret > == 0? Possibly; you know vPCI better than I do. > That will also simplify the logic in register_vpci_mmcfg_handler() > since we no longer need to return 0 when the region is already > registered, returning -EEXIST should be fine if the caller is > adjusted. I think this then will want to be a separate change, with its own justification. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 29 15:55:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 15:55:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216789.1526716 (Exim 4.92) (envelope-from ) id 1vlUML-0006TY-50; Thu, 29 Jan 2026 15:55:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216789.1526716; Thu, 29 Jan 2026 15:55: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 1vlUML-0006TR-2R; Thu, 29 Jan 2026 15:55:05 +0000 Received: by outflank-mailman (input) for mailman id 1216789; Thu, 29 Jan 2026 15:55: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 1vlUMJ-0006TL-Sx for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 15:55:03 +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 df1785a4-fd2a-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 16:55:02 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-47ee07570deso9776065e9.1 for ; Thu, 29 Jan 2026 07:55:02 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806cdd79c7sm129615085e9.2.2026.01.29.07.55.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 07:55:01 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: df1785a4-fd2a-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769702102; x=1770306902; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=aTYgaIwpD6zQ/VXsCYvzmWGHpgFMVj2e1rILg4BrlM4=; b=BX/eB0zrHAzFmOP/EbldqgtqLV03krJXa1PlPYAPP/57y9/0RDgWjckAfR2i+8iKHA dfTOlVlIyijlo0jyKXohoIGIkMOFCepMbM27BTw8H+rV+0fpq4BKIA2+W9nYtCaNu+oP GhuATF+9v/6ffrKrmRVA5p+ktcJy39GBhme26MRrvwJY641WySCaDfEss9BZ0ebhMLwB LV/6rvV/uyXjK+PpapQBvfCr0/KH1sTShGrucEzFgnSOVMHGJRjfB5vO7+03TPhMV+fs ceaBWx9UVJdISlrEx6bK9+W6oMTzTAAZzPZPnG4tEJ0zcR8QzXLyq3+mOU5baQ6SBLgr hy7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769702102; x=1770306902; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=aTYgaIwpD6zQ/VXsCYvzmWGHpgFMVj2e1rILg4BrlM4=; b=aU9AY1C2NWLc36ZN4bSDINE7N+t/TjKcjQ2whv0WEitwT6Vdq1z3Ub5u/ygHOF2Czd DMiKBU5TwUZHhiqnnNkaO7XCGVSkfSAxqMARKRx4j+3M2eMrjnDjCpXqAVP4Z9OYTcc6 jLgRiS2vIvfd8t7Cw4WOxzsTy5wV5IGGB4lIiSyIlF3GRHJLlz2TJioxk/ovCKQIAD1+ kRdqVQufVYZor5py7c1zTznQoPfWnKM7xmDAYVcRqS3KBwtZAqeYKo0gx5xANMIgOXQa p7518J7lQg34IT1r31afG+aqno8bg+vTUIzrB5en2xQYxgDP0DF1zYSUXKDDf4icOZeY fVvA== X-Gm-Message-State: AOJu0Yw9olejqLPlmS7+PLjYQJn/js0VmSfG3L3EaVJaizQEMDlNEiUh B7qv4Z6F9RGFhVT8UCxhNhKcgljqTKMLYAboAZOJyqHady2LHdDrzZJX09WI27FiPA== X-Gm-Gg: AZuq6aK6lbhG9ZmFz6jRNyg+myozZ1ExwAa6tIn0BjGWb3z8R7M7pjvlCYodqf9w6WW SjfU01kmxmxjEiPuABrwUx/4FFnzj83ws2FnBblNk6nNtSx2NoFlu1N9qAGPNVotivlhyf0q8Ao oP+iyGvucHHW2rio3eMwI/Yms5gqAub8/bEHAYHvjCPsbvlVXIWmJTDUyUNzDAd5+mZ28NvIgF1 cLTHr6RhnMo2oOT242qLEVVveX9bS2viGTBWKMCw9KL+ElCya1UboNSwluClU1PpIXNJXn6GjgE ENDMxrdnb/vVKOA2WFawjkv9bCIIEjI/IqUs1jbPRjIPgxDJYABW37lOghb/43k6MRzZtYiJcZ2 nvuPyYH4sqydUl12LyPWscyPXPgPIv3BH4DNidshJuCX/yHxDPt4LcC9rWpEBDz91XkcHd37jEH vsRLWqZ+A89psWPdgo0PSwm/54kZXQU1/ZIK3vJ88d2rGPFUV7DKx9kc4uKjMpEvWhCS4AlBadI MFGASOSq7B/sA== X-Received: by 2002:a05:600c:3595:b0:477:a978:3a7b with SMTP id 5b1f17b1804b1-48069c78bdamr129417605e9.22.1769702101820; Thu, 29 Jan 2026 07:55:01 -0800 (PST) Message-ID: <45ea72d4-bbc6-49b9-8d29-d18876dd187d@suse.com> Date: Thu, 29 Jan 2026 16:54:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 6/6] vPCI: re-init extended-capability lists when MMCFG availability changed To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Stewart Hildebrand 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 29.01.2026 16:40, Roger Pau Monné wrote: > On Thu, Jan 29, 2026 at 02:10:34PM +0100, Jan Beulich wrote: >> --- a/xen/drivers/vpci/header.c >> +++ b/xen/drivers/vpci/header.c >> @@ -869,6 +869,18 @@ static int vpci_init_ext_capability_list >> return 0; >> } >> >> +int vpci_reinit_ext_capability_list(const struct pci_dev *pdev) >> +{ >> + if ( !pdev->vpci ) >> + return 0; >> + >> + if ( vpci_remove_registers(pdev->vpci, PCI_CFG_SPACE_SIZE, >> + PCI_CFG_SPACE_EXP_SIZE - PCI_CFG_SPACE_SIZE) ) >> + ASSERT_UNREACHABLE(); >> + >> + return vpci_init_ext_capability_list(pdev); > > Isn't this missing the possible addition or removal of managed > extended capabilities? IOW: on removal of access to the extended > space the vPCI managed capabilties that have is_ext == true should > call their ->cleanup() hooks, and on discovery of MMCFG access we > should call the ->init() hooks? Now I know why this felt too easy. Yet I wonder: Why is this done in two parts in the first place? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 29 16:04:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 16:04:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216799.1526727 (Exim 4.92) (envelope-from ) id 1vlUV6-0000OU-Uh; Thu, 29 Jan 2026 16:04:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216799.1526727; Thu, 29 Jan 2026 16:04: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 1vlUV6-0000ON-Rl; Thu, 29 Jan 2026 16:04:08 +0000 Received: by outflank-mailman (input) for mailman id 1216799; Thu, 29 Jan 2026 16:04:07 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlUV5-0000OH-DL for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 16:04:07 +0000 Received: from mail134-16.atl141.mandrillapp.com (mail134-16.atl141.mandrillapp.com [198.2.134.16]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2233c147-fd2c-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 17:04:05 +0100 (CET) Received: from pmta10.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail134-16.atl141.mandrillapp.com (Mailchimp) with ESMTP id 4f23q737bnzB5vfgS for ; Thu, 29 Jan 2026 16:04:03 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 73d8d46b397548ecad44944e93a33563; Thu, 29 Jan 2026 16:04: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: 2233c147-fd2c-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1769702643; x=1769972643; bh=QHKAeUR7kH8mvgAor9G1mV+cUywA6KCBVPBkM7zRzXc=; 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=DT4UQEJoczy6lsxjau88DYXWnvsudZf8MxdKGwui+/CtLec3yTdiMhRzfv7wIjMZq 4o37kLRBZMiSFOxcXaTLyZ0/ca/ZBraoLuuLLlaMO9X7oiPEGDjCKmrICUOS8sjlzl 6Ya40lp84HkvoUI4jug67pbK4tApfufmnk0n6HlJ5OAC3ohhKjfZA5KeHRJzSJa3fJ n21yxzNjRC0hUfXwFImeHqG29M23O41UgbKfTOyrTy6iSvvZUW+aecc5KOYqz7ZHYH eoxaQUAxYQ8lBUBfmYwDweZK0Xpo1DRkOvj74joMfDjwO0lu3Rndbf/gstIVr6tb+H XJ/Zcz4TPcWzQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1769702643; x=1769963143; i=teddy.astie@vates.tech; bh=QHKAeUR7kH8mvgAor9G1mV+cUywA6KCBVPBkM7zRzXc=; 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=HeEvlY9ptYUG4J4tqvzd4qvG7i3Hbjkz2Aa9qTj3NmLIBXz8BsZLVOH58LKkUN/0n 9lgXiZM8S1qZZ3Tx0Y+AH9A27r6oDKVqLQ9uIngCQGU5U2roFTaX9us8hTgvzgnb4I TjNZ3dZl+BCvadv+jzK+I+c2b39aQaFYtRMLKG+UXcmyqsQMIMq33/MyiGmmWQgsKN oiq9YkEyS9Qk+xwxYj49ksqSIuONWCB9beI5PkpZ8biDBIacsPJciRm4PQuJnfbxI9 kQZDmDI5qRmhEzroy5ZZq1IJbzPZLGiE/93mmCpA27Mmjh++9PXBOVmgrxDH4FZ4FU K5ibJT1q64xkg== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH]=20x86:=20Always=20display=20CPU=20vendor=20string?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1769702640904 Message-Id: <90b5ac3f-9238-4344-8dbe-f7d5873a45c8@vates.tech> To: "Jan Beulich" Cc: "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , xen-devel@lists.xenproject.org References: <8b50a689e549fd174d6c34dadc5df5c65711c615.1769694285.git.teddy.astie@vates.tech> <87181edd-fc9d-4221-827c-97abc7aaca65@suse.com> In-Reply-To: <87181edd-fc9d-4221-827c-97abc7aaca65@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.73d8d46b397548ecad44944e93a33563?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260129:md Date: Thu, 29 Jan 2026 16:04:03 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 29/01/2026 =C3=A0 15:06, Jan Beulich a =C3=A9crit=C2=A0: > On 29.01.2026 14:58, Teddy Astie wrote: >> While we may not want all the other CPU informations. We likely >> want to keep the CPU string as it's more practical than trying to >> decode it from the family/model/stepping combination. > > Yet why would we want it logged several hundred times by default, on a > big enough system? IOW ... > Ah I see; one idea I had was to move this to early_cpu_init() or somewhere similar, and only displaying it once (only for BSP ?) ? >> --- a/xen/arch/x86/cpu/common.c >> +++ b/xen/arch/x86/cpu/common.c >> @@ -819,9 +819,6 @@ void print_cpu_info(unsigned int cpu) >> =09const struct cpuinfo_x86 *c =3D cpu_data + cpu; >> =09const char *vendor =3D NULL; >> >> -=09if (!opt_cpu_info) >> -=09=09return; > > ... this conditional doesn't want removing, but amending. E.g. > > =09if (!opt_cpu_info && system_state >=3D SYS_STATE_smp_boot) > =09=09return; > > Jan > -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Thu Jan 29 16:13:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 16:13:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216811.1526737 (Exim 4.92) (envelope-from ) id 1vlUe9-00026r-P9; Thu, 29 Jan 2026 16:13:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216811.1526737; Thu, 29 Jan 2026 16:13:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlUe9-00026k-Ls; Thu, 29 Jan 2026 16:13:29 +0000 Received: by outflank-mailman (input) for mailman id 1216811; Thu, 29 Jan 2026 16:13: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 1vlUe9-00026e-3z for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 16:13:29 +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 6f97d86c-fd2d-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 17:13:23 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-4806cc07ce7so10524475e9.1 for ; Thu, 29 Jan 2026 08:13:23 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066bee7d0sm220333435e9.4.2026.01.29.08.13.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 08:13:22 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6f97d86c-fd2d-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769703203; x=1770308003; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=jRB24tX67tI2lywGWxRiTuPr64WQXluDOasgw5Bm6Tk=; b=F7KAIn1qvxgUIjqRD8k/eKmTWaRxG0mUP8fdpYdxr3laUgyU+Dekaw6Yvijoz0l76Z gIuf45Xb9saJDmR6lWot4B0wd82GkqoWROQwAPhmksr3YiwSl3yl4fYc3IktRfOdegkt n0eNcA+mkaG559tWAnxHYrr/xQD6QhkDnKSyrFmzRhwAci2Mvr/YTHg60+zMTvJgC4XS adI05neJXS9BIypQzJIKBkjf8cjNbCNNPXryE24n0ypDt3dVSRXGJPwF0Y+bvdT42RnQ KNYnvA5eeNvL80j7Ku0GOwTCuE/JJ1QCj4bqaluWCH78wtdsyrTh4BA37DFm6gsaIvYO 8+4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769703203; x=1770308003; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=jRB24tX67tI2lywGWxRiTuPr64WQXluDOasgw5Bm6Tk=; b=bXZJb9YnCkHVjfp8LJfW6j7rNzvdmDkyHUY4yvGOGK/Du01GBpn8sf56iwEsr0uVpX 4VRwGyAHS5h8htrlZcEr5nX/Bey0WVfdxW+fi874l9vWr9IrnxETVGC3ogS7jUmJxaU1 kFLFSModfqPLy5DlkQo/7BeUspcMEp+nHOifcFq9vSvLGK8c+3Su9JfCy3O66utRuk7g 2NUPdZWqrpBIpNtXE70C1klnj9xffm7gC4/TcBOoPnClZVA/B3dxtnuiB/s1y9KFAc5+ LW8JE8o3OMb9mPVLUFmDI6LLC6yW4ZHGefUyCoDguMXHvKLoMHBVNrzPpvYozx7XHKl7 +u6g== X-Forwarded-Encrypted: i=1; AJvYcCVvVN9Co9+CqEWkg++h2Q1sJSTFqby4hjHI3xB7LSj8bMbAaJkurZtDb5s6gOUOZPDgxdCJ5w39QCU=@lists.xenproject.org X-Gm-Message-State: AOJu0YyqOz4gadCgsh594j46WUxjdjkIc/4rQDHJKp767AXg024RKx0K HnWkOnNEb8QQYVWKnQCfrtyAveLL+lZ9z4ySNKOq2BXpoAxurpkyNAmzoduCRLVTFQ== X-Gm-Gg: AZuq6aLQHq6srW3JaNw68Z3HbjqDH3lX34mvntWVhLhuALNTKF8udqtkpbL3IFffKgh 8GWyhaB0R3cxb+z0J0B3jUOXTRPcsXbqMpbgWY8rGndPOuWUcyyKGsn/8kW5RzK4zUjEujrfMfv PrLP6OyWp7jXwr8PWY/9tgilwHseGtHfEaJNsbQBvCbxTtNafyYoCNVrxonkP7onHp4vl0aR196 0sVqUDYOU9LJ31n6nuZd2egHubAZyGZa20Qd7Q5vQm++Xo2+E0Zw93Or5bwv0NPAteJJQ0sCTam ss1HMfbQsr1/nmlX5H0COAlCV3qYXhnN9SQkq/mfx7wlGh0klof/Eh7lWubn+QQ8dzd3ItWo19r hB6aP5DrRWHa429BFsbK8kbtjL2p8WfP7Vf2OlEhrcbvhFYiTttbhVMfuChho+GmHYRRCMAYzzt a9D7pkb0obFT6xEH/1+YPwH0+8E7lSR4NvzksZL1n2vBo+PBL39yoc8z7OimgzClUdXE9V74Evg v8= X-Received: by 2002:a05:600c:3e16:b0:480:3b4e:41ba with SMTP id 5b1f17b1804b1-48069c5b971mr109579195e9.18.1769703203138; Thu, 29 Jan 2026 08:13:23 -0800 (PST) Message-ID: Date: Thu, 29 Jan 2026 17:13:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86: Always display CPU vendor string To: Teddy Astie Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <8b50a689e549fd174d6c34dadc5df5c65711c615.1769694285.git.teddy.astie@vates.tech> <87181edd-fc9d-4221-827c-97abc7aaca65@suse.com> <90b5ac3f-9238-4344-8dbe-f7d5873a45c8@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: <90b5ac3f-9238-4344-8dbe-f7d5873a45c8@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 29.01.2026 17:04, Teddy Astie wrote: > Le 29/01/2026 à 15:06, Jan Beulich a écrit : >> On 29.01.2026 14:58, Teddy Astie wrote: >>> While we may not want all the other CPU informations. We likely >>> want to keep the CPU string as it's more practical than trying to >>> decode it from the family/model/stepping combination. >> >> Yet why would we want it logged several hundred times by default, on a >> big enough system? IOW ... > > Ah I see; one idea I had was to move this to early_cpu_init() or > somewhere similar, and only displaying it once (only for BSP ?) ? Well, we have the command line option to log data for all CPUs to help in case of problems. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 29 16:21:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 16:21:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216824.1526747 (Exim 4.92) (envelope-from ) id 1vlUlf-0003uC-GP; Thu, 29 Jan 2026 16:21:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216824.1526747; Thu, 29 Jan 2026 16:21: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 1vlUlf-0003u5-DO; Thu, 29 Jan 2026 16:21:15 +0000 Received: by outflank-mailman (input) for mailman id 1216824; Thu, 29 Jan 2026 16:21: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 1vlUle-0003ty-8o for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 16:21:14 +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 868ef1a2-fd2e-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 17:21:11 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-43590777e22so759738f8f.3 for ; Thu, 29 Jan 2026 08:21:11 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e1353ac2sm16663314f8f.38.2026.01.29.08.21.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 08:21:10 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 868ef1a2-fd2e-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769703671; x=1770308471; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=vLkucR59sAdtvYrkMLt/05rHLLUs9rTlDgadaY7ykos=; b=DXygxX69Goa6aHQLjOk2mY9BezdmBFpmm0i1mEmW9sUVkdBXEwNiDz1zi6KeRfGUkJ DuQEfFqfdSSDZLR+BuANEWHjkhLIIk0l2Ohhd1tKFp/E36krwEz3Xp7oiaoHD6EfenJR LSJt+SpDYkD21DroxI9tmc+dQ+HbPzv1g8zhE6Igci1j8QkxwPk305pbMVyFWIMyTYAl XmBxfntKoFiLougbJ1jMWCQqeYSPZnC1qECfUCwZPa389uPNrsGcBf7k3zmFv1M2i/3k UGAb7LDs30Zl1pLG4e3arXaXOo8Y0T+Iji+CtaDY5h/77lXTkefseC4bXhi8ZVBdlLBT ry1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769703671; x=1770308471; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vLkucR59sAdtvYrkMLt/05rHLLUs9rTlDgadaY7ykos=; b=cEA6aCsWAv3f/FfhDqBeMvnLWdIqbOc4dsNOx1KJXIuy0hvSH/jIDe8woDxFplYgij Wkd2WRHqPUyLTYyyO8cGFKVhbw/61au7zJ0QES7ow4bJLK1Xg+B33/Yz254ibqo6gJYC DaCiqhK2LXfjSk4hpa5w9shFlYS6lAPrd5oi9t7lSZ4n/s5t6W44cQ3djVWW2ZbhD+nc +s+rMOPXx1plCDMZPwZmhzsjlF7+Ee4s6FmZq7qXkfm5HSGgz35rTE8OflTWC/gKpQR7 4h1PAmKMNu1QtfXADxkn5RG2ySDn2pDrQu5VBvQE6YSdU/KkzlqGLymaVqvBRM3oiyeQ vI2w== X-Forwarded-Encrypted: i=1; AJvYcCXdwuofFc4FdzRquwdvidlh7HzE/rb9lj+ts8oP+dprZm2rclnYkQeMjSAzdkUvIPjrRCM9iTvoBJc=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz1oOa+Knd14QYLbi9oES/Kufkvq9M0wMZJtPZbsu6IbEp8a2iZ 3sCNmjYD0J8VgIWonWUyGChuvI1aJyPAPp60UKNzd4Coz7UllTKYvDRMvsPsNEIMFw== X-Gm-Gg: AZuq6aKn+8ZQmrwPeAMbko7UJakLs3/MZIzOMw0eY7QO/WGvXaRIZkeLDZT1X1kUTp5 iZO9g5e5/PZ5Ia4N2cg1i79PnPoSz/18G9mBGkW4FIqEorCSHRrvoBsRa8vQX5SCTEw1atMu9Og EKX4QerPWMmXg8j8hp85UxEP7qcNV8avDWQRLnjgkohhnnhif6WLroLfM8drOUXvcrYdyFjiieC 9C6mNCxeCvUX2bnDKFvxLyc98r4/WK07UUaWGkSgAR8OqwQ0GuXQubsROlfmWfU71QikTbaRILQ 9Sb0/AZ9iLIEzASg04H+pRw1+GqH4KZHKHAP/+lzm1kcLU046JoRaN0pJQCobdF6iEnfc28lo+n RIFz5/kzdmDvOxdm6vlU7bD8sPZ+AKBTPHwrC9k+kN4VGuzWkRdLe+S8yaxcX5xtwdWqSm/XYwJ p9NBAsCt8h5w5A6eia6D0JVWqAdJ0c1idxVhnqD+XEoKHS4HUnixrff9dBpVRs+il25vtd+WEnv z4= X-Received: by 2002:a05:6000:2304:b0:435:9cd5:bb2a with SMTP id ffacd0b85a97d-435f3a7449amr228678f8f.24.1769703671192; Thu, 29 Jan 2026 08:21:11 -0800 (PST) Message-ID: <1308a872-dc7f-4e0f-aa9e-e9d05af3d135@suse.com> Date: Thu, 29 Jan 2026 17:21:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 3/5] lib/arm: Add I/O memory copy helpers To: Oleksii Moisieiev Cc: Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "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.01.2026 15:16, Oleksii Moisieiev wrote: > --- /dev/null > +++ b/xen/arch/arm/lib/memcpy-fromio.c > @@ -0,0 +1,56 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#include > + > +#include Why both, when xen/io.h includes asm/io.h anyway? > +/* > + * Arm implementation notes / limitations: > + * - Uses ordered 8-bit for leading/trailing unaligned bytes and ordered > + * 32-bit accesses for the aligned bulk; no wider accesses are issued. > + * - Only suitable for devices that tolerate 8-bit and 32-bit accesses; > + * do not use with devices requiring strictly 16-bit or 64-bit accesses. > + * - MMIO must be mapped with appropriate device attributes to preserve > + * ordering; no extra barriers beyond the ordered accessors are added. > + * - If source or destination is misaligned, leading bytes are copied > + * byte-by-byte until both sides are 32-bit aligned, Which may be never, which in turn may not be obvious to the reader. > then bulk copy uses > + * 32-bit accesses. > + */ It'll be Arm maintainers to judge whether these restrictions are really going to be acceptable. I think I pointed out more than once that I think these functions end up being too-narrow-purpose. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 29 16:22:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 16:22:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216831.1526757 (Exim 4.92) (envelope-from ) id 1vlUmh-0004N8-PO; Thu, 29 Jan 2026 16:22:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216831.1526757; Thu, 29 Jan 2026 16: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 1vlUmh-0004N1-Mm; Thu, 29 Jan 2026 16:22:19 +0000 Received: by outflank-mailman (input) for mailman id 1216831; Thu, 29 Jan 2026 16:22: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 1vlUmg-0004Mp-88 for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 16:22:18 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ad02c092-fd2e-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 17:22:17 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by PH0PR03MB5944.namprd03.prod.outlook.com (2603:10b6:510:36::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.15; Thu, 29 Jan 2026 16:22:10 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%6]) with mapi id 15.20.9564.008; Thu, 29 Jan 2026 16:22: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: ad02c092-fd2e-11f0-b160-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MLhj2O7dQqDlQRY/rL2L/EpcnHWzU+gcxv/gytFXfzVzrDHPdjmTCyuxXqqP6/Vj9jkp6YM6ft1MVRGn4hO31qs9+u6S8uciGW3gAF/HXB/ClNsauFosdczoeC5AqpQ40C1ugixUjtNFWn5yZ0KJHG5GpV487cGpVnCCE4TSVyMK9/44a2P9Zly6eFnsqgrKwuu7kKZHc0sT43odR1LMCNLqS8Lf/xtxCK4jojtPrkG2i248jFfcn+3807yhuYGS509fyc8YBxvOdA325Blz23ra96uEVjODhbM3I3zXC9JrKD00RfSNon/gDLGI5ZivDaectwDbSQklGXWDmSRmvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+ld5kYGQhPjo6emeGrwZ+RbLe3jVXmNS36W6aS7UWsg=; b=BccuwZrCvPQ3xxLUIi3oehUSTYzf8V4KHoZXkiRJe3wa1EyP12XOCFbqi7GYrSvdhEa4MTcxAepgmDUJPLDoMPMPQ4X9AWpK1PCF4hynQEnK1J1JsrH/GuBXPns3cAf3JQKms943d0I86XjORF+lpitghcF9zSxlPo4UfjbFKQTx3e4Crs05BZvaOBlw8NzYcPHh+00Y/zCx3zMBmXlY1EAjLmH5MQojZxhtuIIY4CA0WZwdzdPHKza63Tx41vlinogqGQPsDDSgB5kHI6pcYRJVIDlmHYJ19cUfBGWS16GcJim//U1Jlej7xCv1/FpS0mQfHOIcAIOo59RBfO4SGQ== 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=+ld5kYGQhPjo6emeGrwZ+RbLe3jVXmNS36W6aS7UWsg=; b=z1I5CrAqhHangtFXLcMEzeAFGBzAyW3alATq/ZzOkj4scwFA14qtlVCV2NO+C7TsEQF0aH8famFPQftFwum2Y7qEzkNOJu2FCaUKHYTRs9PixZ2Bpb3ieAwriNvQtArMpEfcuxMT6WXJlDcjLbaaVoORu0yx1n1PJL+UIMcxNDY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Thu, 29 Jan 2026 16:22:06 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH] x86: Always display CPU vendor string To: Teddy Astie , xen-devel@lists.xenproject.org References: <8b50a689e549fd174d6c34dadc5df5c65711c615.1769694285.git.teddy.astie@vates.tech> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <8b50a689e549fd174d6c34dadc5df5c65711c615.1769694285.git.teddy.astie@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P302CA0029.GBRP302.PROD.OUTLOOK.COM (2603:10a6:600:2c1::20) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|PH0PR03MB5944:EE_ X-MS-Office365-Filtering-Correlation-Id: 73e90914-0d46-4086-1b4f-08de5f528d68 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?UmpIYVFQYUxqcXlsSFVnV1NPNzB0N3Exd29tMkpIWVV2MEgzdE1mdUExVDcw?= =?utf-8?B?S0VveTZaenJpZ0VaYUdDZFJ4QU5QR24rRkZ2WGJINThlTkl3UjAwa2lMcGJP?= =?utf-8?B?L3o3ZndwZ2ZZd2I0Szg3cXNtTGJXWW5SVzJ4bUQwWktRWjZvb1o0dVcyenQ4?= =?utf-8?B?UmZnTDkzcWkzbnVZenU0ZXl1b3llYzZWYmREeFhIZTlFdjFPSlBhK0pkTzJw?= =?utf-8?B?dGhKdWRUVU9kSnZHYzE1OHhNb3lVcEhOWFFlaDQxeFlLMlIzeXE4S3RWU0ZH?= =?utf-8?B?UGpqOHBlaFE3QlB3K1RYcmUzMU9Bck03OHp1YW9ZeGJrcktHeEU3OWxoQUhp?= =?utf-8?B?T09LL1I4QUR5YzdDSm5oWDQxclF1SU01LzNDMUFGT3dLa0RyWDhLYUJFSEcz?= =?utf-8?B?TDFFYkNVdmo0emRQRnZvRVZ2M2lsakFJamozT3lVSkQraTNubmticDRGbDhN?= =?utf-8?B?elFLVFpEUWUxbTNhdHlwTndyc3c2T1NVemNPMmRmQ3k4eC85ZWJ3UXA4N2Y4?= =?utf-8?B?WmFoN3pPNE5wZHVoeEl4dzN4V0FXU3VwSTBsZGxXZTNYRFNWNWd0d2xuNksz?= =?utf-8?B?bDRiZnJBVEtMWHg3SFJBY3FaMEJacjVweTg3NEsydU9PeDJiNlRDU1dYNklF?= =?utf-8?B?NGhsNDVYZk5pZEE3d2FvVlRXKys0c05xRHo2ZWd0aFpuQ01uOEx6K3BBSXcz?= =?utf-8?B?aFYramRqMEs2MlR6aDI0VDhjb29ub3FhZEtDbEtsK000TlRtQWtxWER5NjFY?= =?utf-8?B?MFR4ejBkalJ0dmwybXkxOUN3WXkzbENPWUZZU05uRi9SWkxRNUs2Ym5tOWp4?= =?utf-8?B?RzJUc2ZoN0RzNEdQQ0hxMW92aTM2ZHExQXB0d2MvRVRJLzlFWGFBZnRiQUFt?= =?utf-8?B?dTV0L0J5NGRiajNIZ1RPYklrSDcvTGtLRmpSR1ZDNHhpQ1VRNy9PK0RwbXJI?= =?utf-8?B?aW5LcHdYU1Y4K1VHd0c1VkNxL3JWTnQvYWFsa2JzeldLaFVlMnBodDdWWC9Y?= =?utf-8?B?UkpKN04xV2lwZEdXdGlGdHdmTE5nVlpYb21NNFVQYmNMNnRXamtkRmNtM3Nt?= =?utf-8?B?U1BXTEdaTUcrdk0vMUh2WXNNb1l5OE5MMXVCbXVDcTRVb3RoZU81bnAxRDlZ?= =?utf-8?B?VlBhZ2tLdVpVZzE5OU44S0pZc2dhVkF5MnI1S0EwY0prZWN6TzF5aGtNYTUx?= =?utf-8?B?b044WWptZEM3eVFFL0VZMzVrdmp6WUVqQkg2QXlldSt6VkFSZ0VaNGtubmxm?= =?utf-8?B?NmxrWmVycXpqSHhMOHM3bWtjWXdMakxEdlNIdjBJM2d2a2xtR1cvU0hyenUv?= =?utf-8?B?S2t3WXg2UDNOdVNzNERoWm5qK29OY1hWSGlhL2tuU1dpMndhT0o3bEltVU9K?= =?utf-8?B?NENOT25yNGlwNGhQMVFVUVZDelNJYlU2WnJLaUplWU00aW93RkVPd3g5MjFt?= =?utf-8?B?NVdaSEUya1FVMzZVb1BEaVUzSnJiMHVyeDBlS29SdC9FbFNOa21zelBIYmVu?= =?utf-8?B?TllBaU1nbmJLblJ3cysyRUNzc29TK3pIOGFHekc1ZU1rOGV0TlcwZ2IvT0o5?= =?utf-8?B?VS9WejRHd3ArTk1RR0NJcmFtMDJSUFhZdjBaekh2SUk1bjdjT1c2SlV6dnR4?= =?utf-8?B?bXFsS2tEWEYvZ3J5REJMVE9YMS9tM2pQV2hoa3E2RXpHSVg4QzQ0c2RDSXgx?= =?utf-8?B?d1ZPR0xXSDhNaVU4cGZ3Wld0Q2pYQ0E5YWM5TEk2TWdhQWcxeGpZY2RPZXcr?= =?utf-8?B?b3A3bE9nQVRBWWhRcXBCNnl1K0p6SkZ3UDNoM1hPZDY4bDZHVmFSM0M5bThU?= =?utf-8?B?clZvTTZYOGF1UUhUaUNPRUNzZzZMREVTNVdVOTlrVWsrdUcrUk11NnZqOThC?= =?utf-8?B?NE5NZ09LZjhyei90b3F0OXpTWW1ONEVJbWtHK3Jtdkg2TmhnRHI3Z3hEb1pv?= =?utf-8?B?TkpQZG5mcWRzSTRNN0Iyb0lyR3pZWlhFa2xDR21TK0lrTmt5NTlYb1ViQXJq?= =?utf-8?B?RWZQWmtSRjBYQ01CdW5lU2huRjNRQW9vaDkzSnlNbThkTkFWVGM0ckcybjQr?= =?utf-8?B?THlNTHFISE1yRlFXZWlqZkxWeEdDN0ZhRFNWVE1uNkFuZHRkekdzQVFzRFFy?= =?utf-8?Q?/O1w=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH8PR03MB8275.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Q0xrMk5CMWlDeGx5VG5mVzBEODM2dHNUWlZKcmwrNkxWMmNmMEl3cFkzZEdD?= =?utf-8?B?ZW5QRXdKSGE2SHBPTU5KZ3hBWklNRXd5N3R1ckFGcWlwd1lQeWNrMkJTYXFl?= =?utf-8?B?Y1gzZUFzWmI1YmRja3hieG1ueGxGWHJxYmNrcG9kR1BacGxaWXRKSFpDVExH?= =?utf-8?B?Q1YxOHN5eiswbEVLclBKRWFEWmlQSXU4TEpSRC9MYnpwQ0FaMEVGTnZEK1dC?= =?utf-8?B?RTNoU0RwOHRsQTV3VVU0emhGcVJYbHFBbWpBUGkwK0FiczBmVDBEcnhiOUo4?= =?utf-8?B?K0o1NVZwQjhnb3hUSWVoYVJZUGNnYW8rWGpCY203M2lWWnBoMU11dTJKeHhz?= =?utf-8?B?WXBzcHZ0ZmdtYWRESXNxcW9HOTVpNFNCRmhqbVdFZ1Bmbm1ySmg2K1pjN1dj?= =?utf-8?B?b0V3N1ZvUzQyRVU5cHJFZEdpNm5Xblh1Q2FUTzRKZmFlZy81eTZSU3Bza25v?= =?utf-8?B?YXBLdU4yT2M1aFJmeFBFdmpqb0d1cFNFWENPdFRESzJpYmJZSnFrT1QrdXh6?= =?utf-8?B?aHNXSlpnUVRxeElkay82NkhhS1cxRmV3VUh6Mis2N3FwdkNEVHA3YXBqcEUw?= =?utf-8?B?UFNESDVNdklncldjQisxdHB0Q2RRY3d3R0ZiQk5CaWhveFlJS3FseGVteGQx?= =?utf-8?B?TzVHNVRzZ2R4czloYlVLNHE2YzVpYlRWb1RVMnl0TGxoUVJDVTExbk81R3FX?= =?utf-8?B?dEVqLzJpalh3QTZPcmlkd3FwU25STzNKZkFrbHozOVE2ZTJuWWVlRzZ4SEpZ?= =?utf-8?B?dUM2TDM5SzhyZG90bWpOWGMvdzFKeVZ5VmlXcmhWSlNJdkoyeGIrN29ibDZx?= =?utf-8?B?UFk5RWN1NHFsdmN0S0hzVFBFTWo4b3kxcFNmTXZHYmxIdVVnRFlyc0NMNHU1?= =?utf-8?B?Sk53TTB4RkJaM1gvbmdFSDh0S2QwMGY4WVluREJxREVHQXF5eXFmTk9oQ3RO?= =?utf-8?B?M3VzT3YrcjZ1Z1hlUk1HaFZhMGdDdzBpMzM5NW15cjBCUjdzdjZ4R0JucklX?= =?utf-8?B?dSt6clQ4aklxZXo0S292STRJUHhicHNoRjRvWWF0WkZ0bUlNMXBiRU1OcU9s?= =?utf-8?B?bTBTOHoxMVlsemdJUWtPUmxjUmhaRnVLY3RNajVDSWFyV1RFUWI3Qk5RLzAz?= =?utf-8?B?VWFvMW5CUlhCM0h1d0RMeTg2STZWODlQYU1FbWVJdkU5d3NFcExNR3FTcUF3?= =?utf-8?B?alpYcmk0R2Zwc0kvVlIwRFRZY1lqSGNNNmw3R0F4V0pYRXZNeDVJU25JbDM2?= =?utf-8?B?dGVCQURuWlNqbjBNeGVmcUtEdWs2QUcvSmkwYkNnT1RRSHozS3JxczRPZTNF?= =?utf-8?B?Y3dleXNUd3ROblUwNVU1cFVFS2Z3cERSQXJxVDc2VXpMRDZVRHJHTDBGQU1F?= =?utf-8?B?MngvQTE3RWxXOWN6OXZJZnpmcTE2OW0rcG41bzlQQnQ0dHlFbVgzQi8vZ2Fu?= =?utf-8?B?NUxRTS9uZGNUeVA5TXlUNUVJOTBKbURLSEZ2UUQxL0wydStsMytPSXV6RTdU?= =?utf-8?B?QjF1eHJPOWowQ3p1RGJLSFhla0YzRXFITWVrMTAwWmNScTZoMjErbUhNVzdV?= =?utf-8?B?YmJrMW95MTB0OUYxREh4QkNSUFpMWURmWk1XTmcva3c4NG82MjQ4M3NPUFZR?= =?utf-8?B?YnVkbnVzY0VoOTFwRVpUMXRLN1RXS1p2NzVYcFM4QWtOR3hBbXdGTlZEYjlM?= =?utf-8?B?cHdQRC9JdTREUDlwTFh2OEVnRkJRRG1NN0VwMjVtaTN4VEFvSUtKWlRXVnhL?= =?utf-8?B?Mml5SiszVU02eVNnRkx3VzFobVpTaDlDQk9EQStNUkZSMHJGY01TWWlQNkI2?= =?utf-8?B?OTJtZFF3VCsya3pVM2VRc3d4L3ZKSkJMOHFJMUhXNmJMMSs0d29JUVQvNVdx?= =?utf-8?B?ZjNZTWJMNXE0VVhZVWFoVVRqVTFEMitSaHpSNzgwdWc0N1FMTG85YjdwQ3B5?= =?utf-8?B?RjVCSDBlQ0s3VVNQYjlKN1R0aHpNOTYzN3YvcC9BT0N2b2U5dHF1cVEzNnhM?= =?utf-8?B?bDl0aHpLZ0lLTkdpNzJvWFhYaXBjQ2Fzdm0yNWp5QURnTHA3dk51Qy9RWnlt?= =?utf-8?B?RE9zaFh1NEFwTmVCTTRWMUx3Mk1FT1ZBZVRtR0NLejIrQXJ3T1JJNFZoYi9u?= =?utf-8?B?d1Z6dFh5YWUxTUZjNmJ2MDhDbE5qYzhONktwdDVUejhkc2tMUzhKSUFiOHBD?= =?utf-8?B?WGxRTVZGdVpjbTZaOThPZU9ZN0hjRkxvRys1ZTRjaGhWSmhSMy9LVFNIMzVx?= =?utf-8?B?SDdBNXpaeEVEazJvaGVKem12dC9KUnpPczlJNlVxMkk1VDBHc1ZOU1FIUWk2?= =?utf-8?B?Rnc0cytGc3hWZFFUL0hKMG9nL2pMaGZEVTBuaE1Rck9ybGZqakFsUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 73e90914-0d46-4086-1b4f-08de5f528d68 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2026 16:22:09.8429 (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: lspbuQ224nO08hUgNeBRRPjWqsGK25QBeXCAZymhe1UMg1x8nV6xvQHhNszeS5cFWCeErkQwvl2afvNv1DQQxJ6aadWi3Cl1N26txLPSK1I= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB5944 On 29/01/2026 1:58 pm, Teddy Astie wrote: > While we may not want all the other CPU informations. We likely > want to keep the CPU string as it's more practical than trying to > decode it from the family/model/stepping combination. > > Amends: 35d60c59af28 ("Increase default console ring allocation size and reduce default verbosity") > Signed-off-by: Teddy Astie > --- > It would be preferable it such message could be written sooner, e.g right > after the family/model/stepping one of early_cpu_init() instead of at the > beginning of smp_prepare_cpus(). > > xen/arch/x86/cpu/common.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c > index ebe2baf8b9..831da72cd8 100644 > --- a/xen/arch/x86/cpu/common.c > +++ b/xen/arch/x86/cpu/common.c > @@ -819,9 +819,6 @@ void print_cpu_info(unsigned int cpu) > const struct cpuinfo_x86 *c = cpu_data + cpu; > const char *vendor = NULL; > > - if (!opt_cpu_info) > - return; > - > printk("CPU%u: ", cpu); > > vendor = x86_cpuid_vendor_to_str(c->x86_vendor); I tried deleting this function (it's almost useless), but left that out of the NX rework because it wasn't sufficiently related. Previously (before I was a maintainer), I did try printing this string because it's specifically useful IMO, but others did not agree.  I'm definitely +1 to try putting it back in. To be useful, this wants to be in early_cpu_init() next to the place where we unconditionally print family/model/stepping. However, Intel at least needs to do preprocessing on the string.  (Intel right-justifies the string, and we've got logic to undo that which we inherited from Linux.) While I to serialise things, this will probably be better based on top of my NX cleanup, where you can do the Intel processing in the (now earlier) early CPU init hook. Also... if you fancy fixing another todo in this area. It is only convention that these strings are ASCII, and they're arbitrarily programmable in general.  Also things like the cmdline come in from external sources (including people typing into a grub interactive menu), and accidentally getting VT characters into dmesg ruins debugging. It would be nice to port the %pE (escaped string) format option from Linux, so we can have some defence in depth when printing external content.  I don't think we want anything more than the default ESCAPE_ANY_NP behaviour. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Jan 29 16:33:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 16:33:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216851.1526766 (Exim 4.92) (envelope-from ) id 1vlUx4-0006M8-Oz; Thu, 29 Jan 2026 16:33:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216851.1526766; Thu, 29 Jan 2026 16:33: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 1vlUx4-0006M1-MF; Thu, 29 Jan 2026 16:33:02 +0000 Received: by outflank-mailman (input) for mailman id 1216851; Thu, 29 Jan 2026 16:33: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 1vlUx2-0006Lv-QE for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 16:33:00 +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 2c72f93f-fd30-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 17:32:59 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-4806bf39419so14557985e9.1 for ; Thu, 29 Jan 2026 08:32:59 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066be7404sm230124885e9.1.2026.01.29.08.32.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 08:32:58 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2c72f93f-fd30-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769704379; x=1770309179; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=6TpI3bZAq+Y1dFXT0IhJwAFFD7kNt+f5P4wPO/TMEdE=; b=SQ4kniflwqIDbME1eiM6VBNzUudxEteI1SgnW4jL0bYwnUXa+hfvtIjqtAyZcOIQa8 KVM4Jm5inoLi1hOlVQmO3AoOmm/vU37o9z03wGqcA5mE2vFGmW09w1k84SONeh8Eh8+W H2zf/TwzP/2iAufbs2Ns7j9b2KrPljSnK7Wm3CDgf2mPOEXSTnQvy2sOXYqwtxLLFcip qxJZUeuUwvimNACFS56oF7miUvM1g/A1Q7uQ2biQhAsvLLYG5BVVwxOWUaxhG351lCVo 5cyjvwB5/25KjoaXIpIVHhFCWb6PQV0Fsx0z7CC3UkM4FJwZdMIVNtNY8eT+OXc/bHze PbTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769704379; x=1770309179; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6TpI3bZAq+Y1dFXT0IhJwAFFD7kNt+f5P4wPO/TMEdE=; b=K+ROzwi9jJ2hDdT6nobMReodclPmkMQ2aaarAv6TSoj+dCGnuQSaPze+GNZmIuFnKH mzd3jxOxVVldWdxYJiF5dJhFiWySD2OffTLHoyMioM8oZxoI3ipVMXJOhpNxJj20SDaa MKzdW9Yf71B2gXP/Q0x+23DP8XroU9DmBgRUYOXUiYSW9Y8Xos9UC4KEA9x9gmJK66RP EjEXEc0imqrTS3WdXnVNsXD5sSFU8Pyv40PhwAm+5LYRWwqvePF5J+SwJA8s/HumQL1n 8O5g2k6rGUXFt1XUcHzjs1ozL4GtxXtuSfV39V6udMPUhcqZ52lP2Dj7gGtzjI06CB94 eYsQ== X-Forwarded-Encrypted: i=1; AJvYcCWUl59u2F616CveMMWWtnDUdh2jCtUHjbx07fXhN5ra1z6ZbjTFnbBCR0US+aSgEPvhSBx/5H3s6dA=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywl65w5Nrr48DqvOEpZQnOSDWMFIQBoQCyBoFzJjN/ZkIhfz+l/ JcsL9PQDJ0OMkHFG/q01GKZkFsWbC4C+c2yqcoUqxS9PpKzvsKCDGSjWdLsLMHYRrw== X-Gm-Gg: AZuq6aKRrPcg8jrHno3SCpsFcCEHeM5AJ/M0/T/7EappyVz0G71Pgo/6CQZsG+u9lel cwv3mbHcP6T73QIpp1JQTDPc0qQMMnm4sDPt7rRuN8xMrE4HLWm1h3WGGUWimXLxwZ2kCI4tUGo 1Jq3yd26ExphsjwY0BB1CC75x8Zr4ZZsa7dru/wXHftjSE4XduCo6ZmS+SOhjB+UHDFDqdbPfVK ElkMfZA/j9Mmu8ATUhmftrjnIk386Z7JyMq87FeJ9C9lXVDa/PhYceXnfQ3AF+ajlo+XdSQiI98 L4DcfFY2Iw4PO79hz0UPt8KbVe6SzMkf/EMjUAbdoBK2mY0eE/5uyWX9pCUxzoIbOypaeft5jIW L7yBzXEQMGqLhDFGzcd4DYsWSua/U3k2NSIkiz/mC8jXhPjhGq/vxJb07L4m4MDTIRfcG2gvkyy NjWKVISbipl3+kDBQezAoyFRDDDElbCQ3qicTL9zO5DV2aREslFoVL+2ZVmF87Y7RCQYzJQW7/V 9w= X-Received: by 2002:a05:600c:58c1:b0:477:a53c:8ca1 with SMTP id 5b1f17b1804b1-48082ab60e8mr29348615e9.14.1769704378973; Thu, 29 Jan 2026 08:32:58 -0800 (PST) Message-ID: Date: Thu, 29 Jan 2026 17:32:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 08/16] xen/riscv: add temporary stub for smp_send_event_check_mask() To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <062dbab8751bd0c27b913ce78de3a3eeb0ffe22f.1769099885.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: <062dbab8751bd0c27b913ce78de3a3eeb0ffe22f.1769099885.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 22.01.2026 17:47, Oleksii Kurochko wrote: > RISC-V SMP support is not yet implemented, but smp_send_event_check_mask() > is required by common code and vcpu_kick(), which is introduced later. > Provide a temporary stub implementation that asserts the mask only targets > CPU0. > > cpumask_subset() is used instead of cpumask_equal() because some callers > (e.g. cpumask_raise_softirq() or cpu_raise_softirq_batch_finish()) may > legitimately pass an empty mask, which would otherwise cause false > failures. > > The BUG_ON() ensures that attempts to use this function with multiple CPUs > are caught early once SMP support is introduced. > > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich Looks like this is independent of earlier patches in the series, and hence could go in right away? Please confirm. Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 29 16:34:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 16:34:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216859.1526777 (Exim 4.92) (envelope-from ) id 1vlUy5-0006sU-28; Thu, 29 Jan 2026 16:34:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216859.1526777; Thu, 29 Jan 2026 16: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 1vlUy4-0006sN-V7; Thu, 29 Jan 2026 16:34:04 +0000 Received: by outflank-mailman (input) for mailman id 1216859; Thu, 29 Jan 2026 16:34:03 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlUy3-0006ru-4p for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 16:34:03 +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 517f1141-fd30-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 17:34:01 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-4807068eacbso10153045e9.2 for ; Thu, 29 Jan 2026 08:34:01 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e132303fsm15827255f8f.36.2026.01.29.08.34.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 08:34:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 517f1141-fd30-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769704441; x=1770309241; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=2RxVW2ZuPEVl3xAbIsuPf+Wrc0pD3R0gkpUeQ1mBnrw=; b=JeDCfG1QQpjLN939g3S0UqK4nVBQhnM+BRlTU/pT4l6IwmEFkeVGMiRZC+2jlYGWBM VR9jZuYoael8dubAyJDiWxX/zSetDHVtnoGqpf9LAv8LzmI7YBdfc5Nk/1ttgLF2hXOf tBltE9dhYgjjVRvGd/ZSeUPOW3lCu7zcKS3HXr7IdXgxVxKD26P/leqMdFvBrfgGjq0o iaGbIn/SHpOAhuGiFB2MKqxtwzh3pU0tnw10WiY4+t8ZfOsQq1lq28c+P0ehPqR+JNjn /y4PsTVEgTdkCQ329LFmwY0v82B7q6O3dSvAUm0FWhB1T2NnBLpUFUTgCIA24gdDavrW yTSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769704441; x=1770309241; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2RxVW2ZuPEVl3xAbIsuPf+Wrc0pD3R0gkpUeQ1mBnrw=; b=HEGBTlDml5At9hKoPY4z75mYFT0MVXaFQo5noQy9r3IjCEV/tIRQwXDQ0Qtd7xNYxe 5UoJbiMEd+MtRIwO4PWIK/o3a3QCWMEgxefk82ii0ljTD6YHWN4sJ4Dg90wFvqhSI+32 Cga69fCY9m0NtQJbFNfoBdgt9gO9FBhjyByF6fNCv+alxb3UON74XvPm3nnKi5viESJU rC0Q/Ap5a4OIbGju6heXMZqh316V6JTn3VDgml65PcoQoAbCXG3gOhtON69zBKp6IUb+ 0/76Z7aQrvT9AW1QpJ9Haqr5rx2awjr2AWWjBK4CzvFpCBj02Nid2tQDhHTq5itSXR/A BSOw== X-Forwarded-Encrypted: i=1; AJvYcCVUswfeAAXqAPa1TbxIu40fciBkxdd5GR7TCSkv5wbhYQlI19rAqIPZu1K8DkBVbi7wGwzJwC7laEM=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy+k5znhZEfF1kDMnUUxzFmwEli54d5dzpSqoRnrbSY0qDxeLRt 8z4VQu4TJTTHWPf8BV4Um1wEuZsqwvntVENjycIB3jurlvnuapEdaj+zUgnWJPamug== X-Gm-Gg: AZuq6aJiSlEcPA/Q+sMPO0JJYNc2JTNJB5a6EjD+KULtWTYrN055nSDgEfVLldjUari k1x2JZhDeUcmb4AQpisRsNrvQMorROvToHuAF9pB3PSHPBGuBIioFNZ4v90vFTFRcDGTkUnFwc3 5njDvkr7pDFQllTh9x6Fz5vHYuDUpX0u5c2BF5osna1dCh5F4bU3mMjUEMhxGzd0BOF+kW99icR McLo3fRkppefaPsJHiPCSy8LtDsoz8duoHn4ecKpvNpd+lf1uUx1qsR0SDC0Ix16UK+ORNkqa8N Dspz0wjvFOdVI9zZlc5N33spz95H1Bvnb06zy6VslzMrANqEzC3j7eUnghRdvaaRDdXp4FkGXfL N+cb52IiOax6er4aC3mIEgcrFn0l0bEvZxCXdkZC9gLTOgoQf7Dzm8TdLf4S3ETX3Ix/49wfrMd KPxO6AmQUCOubMj8LjBNsT6BE63rew2+qmSGjV7PPKbMoZQnjotyoSeTh/mrLZXAAD+SPuKvPQH Qk= X-Received: by 2002:a05:600c:4fc4:b0:480:3338:292d with SMTP id 5b1f17b1804b1-48069c8b7demr135726455e9.31.1769704441109; Thu, 29 Jan 2026 08:34:01 -0800 (PST) Message-ID: Date: Thu, 29 Jan 2026 17:33:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 15/16] xen/riscv: init tasklet subsystem To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <36c05146c82f20f7760ec7f1de9700a2f1c698d8.1769099885.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: <36c05146c82f20f7760ec7f1de9700a2f1c698d8.1769099885.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 22.01.2026 17:47, Oleksii Kurochko wrote: > As the tasklet subsystem is now initialized, it is necessary to implement > sync_local_execstate(), since it is invoked when something calls > tasklet_softirq_action(), which is registered in tasklet_subsys_init(). > > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Jan 29 16:44:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 16:44:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216875.1526787 (Exim 4.92) (envelope-from ) id 1vlV8R-0000Lt-WE; Thu, 29 Jan 2026 16:44:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216875.1526787; Thu, 29 Jan 2026 16:44:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlV8R-0000Lm-Sr; Thu, 29 Jan 2026 16:44:47 +0000 Received: by outflank-mailman (input) for mailman id 1216875; Thu, 29 Jan 2026 16:44: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 1vlV8Q-0000Lg-Nc for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 16:44:46 +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 d07eb92c-fd31-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 17:44:44 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-4807068eacbso10228845e9.2 for ; Thu, 29 Jan 2026 08:44:44 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e131ce64sm15983859f8f.26.2026.01.29.08.44.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 08:44:43 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d07eb92c-fd31-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769705084; x=1770309884; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=IkHhVJ/Vbrsk3q8sQ0lJAfa6aQokFuXl4wPk+2eSUxA=; b=GYZOWRnULdoNA7mbpbmWYhOuQHEFn77Ry6YV3z+Uxrg67v5WnXKGpUaKUj7C33UcaI Kb894Iy8/oTwwIa8lt6vA4OTJmSZxyszcAs6OucLIDPqt+FmX+CCyY4Yjky9xqCfGhJh qUJtVyOPHw+L3LG3vVaw+5aFyPnHy4SJD+aqudUZSka5o4Oo2GC5/27MFEGpZfySM2Nt sbllNwozzANaJQjP3zGfhUDIURIft7p99ALGDh3vLOJX6PVdM0C1kDIqDOmKULZKG6if sy3ytANkaUUQydMZLuTRzjOV4cYalxyMc20Pejt9jQtc3embEifYkZ3BpeGLrew3phyh FhLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769705084; x=1770309884; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=IkHhVJ/Vbrsk3q8sQ0lJAfa6aQokFuXl4wPk+2eSUxA=; b=p1n8T1htzc+12N7v3j2800I3aAZugFjnt1kKGYm64zLzgfZ5TRtHmJeLG49SFGKJpW VkWjVnSvke/4yAo3qTS0pEgDnYnpz2WA+bo0KIS1/UBU0P4TJD57e3sdNlrZcjfoqlh1 HEp3jbyK+Yle/2yw/rJWNwgnBro/UxOovJ4NHuYROC7qsUXVboiRRjrR+Iu05GyUIWkP uK6FbFZafyRH0MzJ4xg8SAwvMFznRhuCxwmSdLj+z1auMui9jnNAAek8VKlzQMAeSi3F 9sDppC7nqfhVXNu2SxakAXPsgsxP5jdYVQ1Au+Mwi5boETp+mHZuq+0WO8F1F2iWQGsO cdQA== X-Forwarded-Encrypted: i=1; AJvYcCVthyhgQBqJFvf9MyN2J0ehy36Fdpa7VppUTijIFGXHDEf9BdaC+k4oivDPLwlx4IHGGcUs3L3xyLg=@lists.xenproject.org X-Gm-Message-State: AOJu0YwOKRLsO4Gh2XG/X7QoWDAfAYLHBuq+C01docb4ToI6vTRULjyS YUss+loy87MjmwYYIxRQYGkKbFoCu2OPLTAjYt7xmhkk/XFiPgPMZ5OzTMKdSaE4NA== X-Gm-Gg: AZuq6aJYiJzGJIIGemTQ+bzzUmBoe9q7RFbD//gS5RPsCrTZtvUhtewR/qpJSzdJau4 xJkfgVenymXTdCZ1bf+InkiLLvkru+1fWjIg/qF7CNoCb5eFlRqDSwGdiDXVzFa3Iy8n+6cA13o dAYQ3K4Bl6W45rzppSDaE18yIdMn7xWnAIrwCn8Wh8s8Nx+Xy8phGZzsktDSxbAaP8NTq6f6I+n IyX/ael4kYr1N3piEN/F0GI/JKEGH0/H3DWbsFVccGn1AJXrAYEsDrdSWlvJ6pfAUG7wlTcINCV 9eEbjfZW6cTcJdyW4w8HFi/7rHgodGhTDtX5bnrne3fhMQx4DQEKHdRH02rUFkDgftLk8T6667L lflbN1G8bL5S8bZEK7IvAfFUqjAeOOxOO8Da+byveGw4RKccnxgNPUG+/Pvsm6TyfXoL1tyNSkq Hgs6vd5RvjXYe4mDSVq4iUJxqQEwB62qTQHdHK7+zhdPCIuGG3CEEfAdJrp30RNfajqZJFOlR45 eo= X-Received: by 2002:a05:600c:3b0c:b0:477:b48d:ba7a with SMTP id 5b1f17b1804b1-48069c8ba67mr105790895e9.32.1769705083648; Thu, 29 Jan 2026 08:44:43 -0800 (PST) Message-ID: Date: Thu, 29 Jan 2026 17:44:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 04/16] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <7b5b7cceb8a131b198d33a83f49ed112ff310389.1769099885.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: <7b5b7cceb8a131b198d33a83f49ed112ff310389.1769099885.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 22.01.2026 17:47, Oleksii Kurochko wrote: > Based on Linux kernel v6.16.0. > > Add lockless tracking of pending vCPU interrupts using atomic bitops. > Two bitmaps are introduced: > - irqs_pending — interrupts currently pending for the vCPU > - irqs_pending_mask — bits that have changed in irqs_pending > > The design follows a multi-producer, single-consumer model, where the > consumer is the vCPU itself. Producers may set bits in > irqs_pending_mask without a lock. Clearing bits in irqs_pending_mask is > performed only by the consumer via xchg_acquire(). The consumer must not > write to irqs_pending and must not act on bits that are not set in the > mask. Otherwise, extra synchronization should be provided. > > On RISC-V interrupts are not injected via guest registers, so pending > interrupts must be recorded in irqs_pending (using the new > vcpu_{un}set_interrupt() helpers) and flushed to the guest by updating > HVIP before returning control to the guest. The consumer side is > implemented in a follow-up patch. > > A barrier between updating irqs_pending and setting the corresponding > mask bit in vcpu_set_interrupt() / vcpu_unset_interrupt() guarantees > that if the consumer observes a mask bit set, the corresponding pending > bit is also visible. This prevents missed interrupts during the flush. > > Signed-off-by: Oleksii Kurochko The use of barriers here matches the (Linux) specification, so Acked-by: Jan Beulich However, ... > @@ -130,3 +131,43 @@ void arch_vcpu_destroy(struct vcpu *v) > { > vfree((char *)v->arch.cpu_info + sizeof(struct cpu_info)); > } > + > +int vcpu_set_interrupt(struct vcpu *v, unsigned int irq) > +{ > + /* > + * We only allow VS-mode software, timer, and external > + * interrupts when irq is one of the local interrupts > + * defined by RISC-V privilege specification. > + */ > + if ( irq != IRQ_VS_SOFT && > + irq != IRQ_VS_TIMER && > + irq != IRQ_VS_EXT ) > + return -EINVAL; > + > + set_bit(irq, v->arch.irqs_pending); > + smp_mb__before_atomic(); > + set_bit(irq, v->arch.irqs_pending_mask); ... isn't it too heavy a barrier here? You only need ordering of writes, without any regard to reads, don't you? Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 29 16:46:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 16:46:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216882.1526798 (Exim 4.92) (envelope-from ) id 1vlV9t-0000qa-Bf; Thu, 29 Jan 2026 16:46:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216882.1526798; Thu, 29 Jan 2026 16:46: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 1vlV9t-0000qS-6j; Thu, 29 Jan 2026 16:46:17 +0000 Received: by outflank-mailman (input) for mailman id 1216882; Thu, 29 Jan 2026 16:46: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 1vlV9r-0000qJ-Mj for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 16:46:15 +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 02871d12-fd32-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 17:46:08 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-47ee07570deso10273185e9.1 for ; Thu, 29 Jan 2026 08:46:08 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-481a5dddb2bsm725705e9.8.2026.01.29.08.46.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 08:46:07 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 02871d12-fd32-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769705168; x=1770309968; 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=ijeuy7NR98hE9WqGDyBoicU2CZPmwQBUOd7DtzCUen4=; b=VVCRgEsksXfKR7iQzGzvn7R+iBfldaPtYaEK02JETUtO/d5yizg2Amt/djk0OnWuBc sTnLdKoI41ONH6hvyIGoBNGTrXaYPSN1UlR9dB/DuRyMx6UsUWqPVygI8i45P0jW+CVR 42mNO9QMFUvvBX1hVDNdKq6LTtsqLWn+ncikBFDpXCorVPUnGjm6XAeNATz6fj9DhOnJ S7fS7kkdQnpxw2wo+lZLTDH5hN0Uwbep2YyB6CizqcOv5HRcIMO2EO3zYYQcV9gkfCvz lpRBSDgVUjvyzk8bI5lc8mmx8umL7L7+DpMXMjlDmq8TWJI/MykmzhyS1ragfl5L6xbx 35xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769705168; x=1770309968; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ijeuy7NR98hE9WqGDyBoicU2CZPmwQBUOd7DtzCUen4=; b=BSU2lOUEMData9Y4XbqbMH+SwxQ9fs41PaCiIF6vi6QDTpJ+iTasr1ob0o6h3J8S3a Nm6EsLhBrRPU7i8H/5OQU126c3pFK6cr6zRvu5Z2TGLjLy73YIDw1TXFhW5/XLX/5aYb OOH6G7nQjuJ9d110ycVW+R0uYolLwY23PHvGEj9Y3hZYPBW1Id0VDUtTkTVqdL9+HpVb xDCJhuTUYe3yDsFYInZiCP7p4KuMzBl3kErf2N9JSexkfpqbAH2o+/iWEDkHTRnymkk2 87U27KCm9LkAc4UdomYPw/BdlK8I6w/goA/IiQpmoX3eboA2ZjsQb3wbofvTt/zqjtYG aRCg== X-Forwarded-Encrypted: i=1; AJvYcCWoVWFQln/z53MlO8Tim3/O4vM+qsIRJ80MZj/B2gtbSDxKGViIW/lRvFa/j0Py2q29BtTe1ZMdB9E=@lists.xenproject.org X-Gm-Message-State: AOJu0YwP5SEkidqbMOewb+S843KvvttvrjHzcrrnFG1s0UVi1gfzZEFV nZhRBYUCruJ4XJGLJGZDRZylAfscimLhYWSK/sPWHr9CD+C66lD13dO1 X-Gm-Gg: AZuq6aLl2k7YwHWjDMkKKKs/3n48z3H6uEXNnWYN1zuUO0RbFFq5LfGhceShnXafDxH QiQ0MzBw+d2GIKj0qTVh6amm1se/kCmtoenveZG1IDvas93zWZ5+5e+FBmNjR2ppN7RF07JCsul nXZQqRoDqkTRQEjKW9E8YDciptn4oFxxcEG2RqT07Upsd6Wc+2IsjeBhEYL6Y42klAyaRrQIJvn v/KZOFZ5rS+YeLiJol33U2h/6F5gefkNUg321iPDeFnQB8dZ9/8A5IGws5CLdzY/wabCS0kAhv+ 0sc1MvuLe6CaxmiUpzwi0QUCquSKAQAYL5HhIPxdY3F7ekZg9qsk4em4f8EKLRvOXrUbXUbbjkP KhJzJn+CEOIQGaaPEdaTOVBai/QYYQRx/08SpejQ+Fa74LVF+oTOtI0f117fz9DD07TYTaKuIK2 2U3xCpmYVVcE7Wij6rgvsMZYIZDF1MTZx5uWIA8IBTdjf6mmvkMx8rUcr3YmSz3MAoWcYKaUsOX A== X-Received: by 2002:a05:600c:1d16:b0:47a:8088:439c with SMTP id 5b1f17b1804b1-48069c9ec08mr136662435e9.35.1769705167489; Thu, 29 Jan 2026 08:46:07 -0800 (PST) Message-ID: <1937ff09-1037-499a-aa01-35112e02f232@gmail.com> Date: Thu, 29 Jan 2026 17:46:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 08/16] xen/riscv: add temporary stub for smp_send_event_check_mask() To: Jan Beulich Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <062dbab8751bd0c27b913ce78de3a3eeb0ffe22f.1769099885.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/29/26 5:32 PM, Jan Beulich wrote: > On 22.01.2026 17:47, Oleksii Kurochko wrote: >> RISC-V SMP support is not yet implemented, but smp_send_event_check_mask() >> is required by common code and vcpu_kick(), which is introduced later. >> Provide a temporary stub implementation that asserts the mask only targets >> CPU0. >> >> cpumask_subset() is used instead of cpumask_equal() because some callers >> (e.g. cpumask_raise_softirq() or cpu_raise_softirq_batch_finish()) may >> legitimately pass an empty mask, which would otherwise cause false >> failures. >> >> The BUG_ON() ensures that attempts to use this function with multiple CPUs >> are caught early once SMP support is introduced. >> >> Signed-off-by: Oleksii Kurochko > Acked-by: Jan Beulich Thanks. > > Looks like this is independent of earlier patches in the series, and hence > could go in right away? Please confirm. I confirm that it is independent and could go right away. I, also, checked locally compilation of this patch on top of current staging and it is fine. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Jan 29 16:56:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 16:56:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216897.1526807 (Exim 4.92) (envelope-from ) id 1vlVJY-0002mH-9r; Thu, 29 Jan 2026 16:56:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216897.1526807; Thu, 29 Jan 2026 16:56:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlVJY-0002mA-6f; Thu, 29 Jan 2026 16:56:16 +0000 Received: by outflank-mailman (input) for mailman id 1216897; Thu, 29 Jan 2026 16:56: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 1vlVJW-0002k4-QU for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 16:56:14 +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 6af950de-fd33-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 17:56:13 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-4806d23e9f1so13832465e9.2 for ; Thu, 29 Jan 2026 08:56:13 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806ce56068sm132750625e9.13.2026.01.29.08.56.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 08:56:11 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6af950de-fd33-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769705772; x=1770310572; 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=cub1RFwZp6v1FzV2qW+f32eURjkoUCqrv9MbmlN/GXQ=; b=eJuUDy03s9nD3x05UafWruG5im+JOxJmm3HVLwGUGgbI4SwDgcDa9S1+00pTZZE6oW BGO3nlDrNATWGzENenBhZrOYqDCakc88RkVgrZRGccujJWGldqv2zG+oCh1zSwa+iwRT olE4L2c9o7fBAwfDvnAM1FUhBN4TUtJ4LuHDjV9PQGaqrpqrFnYfxkPkIAe2j6NlC9pY lB0BV/ljqW3EMf5JH+J+o297MWh7pgQrS+QCmvvru/9VO54ljoT6WK9hl3Sip+42KIoa zAAQo5QThXrlFrulW+kbuQtxPwlVB3mEmpC2rFE5z0ctSx+zwas6bUdlXmJyXAqmSG5p ZTkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769705772; x=1770310572; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cub1RFwZp6v1FzV2qW+f32eURjkoUCqrv9MbmlN/GXQ=; b=OYTd+0qxixyeYH/Yp6XGiZzfkV6N57q71y/RLe5yE0XG4PwzNKrYLVupbuv8hhf1aS ZJ+h/p2kZ3GHpcb3d/BdNgm9S3Etge9CJmsywwy3HwKsrKlWNDO+oTEC9mD64KNWHR6x oQRKyLwlOCJkDZ9vor1Le7c6vkHqVPCDRUxbJmu6zkRn/y1ZvMKkSxX0RFR+vNf8YnqW oJF/HO2yCKLn/kzRtwyDN1i9GYlkw4o77asjgf+KdnFpssZR2n2GpMzStIVI8+Zb92oI Goq7Lzo6gxbCnsuSz08fXU2lOgC6bRQHXKyXh6MaLPYJUntcIAmXBJl+KGgpTxGBdjOu hR6g== X-Forwarded-Encrypted: i=1; AJvYcCVcqIeVcBeqybHsDKEMVoKqS0WEIsthAL8Crf+NDmtJq2d5WJgsM4iNttL8qY4cP2sO23Keb1cikPA=@lists.xenproject.org X-Gm-Message-State: AOJu0YwBeaQ5ET5H/OQsXeljibpy8kmfaVFJa/EwycFgoecGJ8a90dAk mesATM6sVpRhWvcATyRmHB1URVf10n6ZEp6qlZ34G9w0VGrLtRjFgY0X X-Gm-Gg: AZuq6aJoS+M6uoc3CsJdzvtKYWJaLMou57z3rxgTQmK8/QqF/6cmmk4yatM/Byh4Whc DmU+i/YJHJ9gYX5jkI9/KR2bH72zuhB6iA3qzhPZVHIHmlsBegws1Ws7fZmJ0ynJbGTYocJQuRC bppUl5BKh8QL96Zq6onaZVVSJdKbBi8O4C0Wtu3yidsLZDNNLfUL4VGDrE4kcAcS0BAqN0fk628 RcGdaYUwlE3sKelq9MCvWUMRADB6xPimfEB8UCpvhsUCobuK/N3K7lgCmmlQyXrz55WoH1h3xgF ibu5Nh02Tc6CdfCOWza+eFxKNZfkkMphEvdCDPQYerCtYhUqx9X/il4TkkLtVKqEfhrVJtRQdSU ifsCl9Nnkxjfs6iYncPKgRoqZonZHq6MCXIHHzSD3Y7xxRD2GspglWoOeVv79DqlRuMm0NmP1mE FnnvzOjILajYPiCHR211HD9tGYtF1gRq123boWq+PX/CADid3czKm54USvz81xHC8= X-Received: by 2002:a05:600c:154f:b0:47e:e2ec:9960 with SMTP id 5b1f17b1804b1-48069c9a68amr147957075e9.35.1769705772178; Thu, 29 Jan 2026 08:56:12 -0800 (PST) Message-ID: Date: Thu, 29 Jan 2026 17:56:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] xen/riscv: route unhandled interrupts to do_unexpected_trap() To: Jan Beulich Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <3b2a9dbe-fa14-43a3-a7c3-a4c1396a5c70@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <3b2a9dbe-fa14-43a3-a7c3-a4c1396a5c70@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/29/26 4:43 PM, Jan Beulich wrote: > On 29.01.2026 15:40, Oleksii Kurochko wrote: >> --- a/xen/arch/riscv/traps.c >> +++ b/xen/arch/riscv/traps.c >> @@ -196,6 +196,7 @@ void do_trap(struct cpu_user_regs *cpu_regs) >> { >> /* Handle interrupt */ >> unsigned long icause = cause & ~CAUSE_IRQ_FLAG; >> + bool intr_handled = true; > Of course I don't know what your further plans are here, so maybe doing > it this way really is desirable. As the code is right now, I wonder if > you couldn't make this a 2-line change, ... > >> @@ -204,10 +205,12 @@ void do_trap(struct cpu_user_regs *cpu_regs) >> break; > ... using return here and ... > >> default: >> + intr_handled = false; >> break; >> } >> >> - break; >> + if ( intr_handled ) >> + break; > ... simply dropping this break altogether. Well, your change is better but it won't apply to my current code of do_trap(): .... default: if ( cause & CAUSE_IRQ_FLAG ) { /* Handle interrupt */ unsigned long icause = cause & ~CAUSE_IRQ_FLAG; bool intr_handled = true; switch ( icause ) { case IRQ_S_EXT: intc_handle_external_irqs(cpu_regs); break; ... default: intr_handled = false; break; } if ( intr_handled ) break; } do_unexpected_trap(cpu_regs); break; } if ( cpu_regs->hstatus & HSTATUS_SPV ) check_for_pcpu_work(); } So if to use return instead of break here, I will miss the call of check_for_pcpu_work() which is syncing interrupt and check if some softirq should be done: static void check_for_pcpu_work(void) { ASSERT(!local_irq_is_enabled()); while ( softirq_pending(smp_processor_id()) ) { local_irq_enable(); do_softirq(); local_irq_disable(); } vcpu_flush_interrupts(current); vcpu_sync_interrupts(current); } ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Jan 29 17:01:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 17:01:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216906.1526817 (Exim 4.92) (envelope-from ) id 1vlVOv-0004ZP-RV; Thu, 29 Jan 2026 17:01:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216906.1526817; Thu, 29 Jan 2026 17:01: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 1vlVOv-0004ZI-OU; Thu, 29 Jan 2026 17:01:49 +0000 Received: by outflank-mailman (input) for mailman id 1216906; Thu, 29 Jan 2026 17: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 1vlVOu-0004ZC-L8 for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 17:01:48 +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 31a00db2-fd34-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 18:01:46 +0100 (CET) Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-42fbbc3df8fso973129f8f.2 for ; Thu, 29 Jan 2026 09:01:46 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e10e476dsm15711848f8f.4.2026.01.29.09.01.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 09:01:45 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 31a00db2-fd34-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769706106; x=1770310906; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=KGZ//S/eoyd0DV8Ciatjv9y3uqiqnAF8V09hA+6Di3M=; b=DtnAw5PydVEfx/Mx8itrCJtKurbFXh7Ze4JCMgjJApTadjI3tTr5TSPCG9xmToyVZ/ c3qg1LLa5YCZxLg/IuvmrkmhK6ZRH0yjm4shDE++2LG/f2t3PyuwZsoODm8S9n45eEpJ /d052IKtEKnadOVAzqaVWSZEtl4NbgqCO9KQ5xKrA2RfEvBkHUlsp+dHTsyyvKPHQvZf BtpaM4sVdlvge+bclReD756JZTEZGs7cz5iQ/W7BWKE2JgrL7kateQrO/9JT3lpns92O 7ktTQ/WvDILHSZyf8m5laE4pFnSTwSPmp0rXlBEsL50xEqsCeR7HjDxUOpUG0nbwfF4/ YQog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769706106; x=1770310906; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=KGZ//S/eoyd0DV8Ciatjv9y3uqiqnAF8V09hA+6Di3M=; b=vjiM6hdoxkuwA7LNWoqfRUojV9wPsnJ54q7MlE8l6e78B0rv9LPZnPaKWH7qm94Pqn HxKXoVe8MGSRLlFDYmnGy1RI6O01Piw0N9GMaP598nEMQinMciU2uLdN+UuPc7/TPUJF gpHVCZjXXWEvoU5Grs07u0i8el4K30UVW2M0oyvPY6s/BSbe4xgaA3BNy2lnnLgYTlxi RP89UYQkK+UZ6RITq0xAnVzLdz9ya96dgN/EoGXpslva8SBDDJd5GnwF6XERW2n3nJy7 yruW2IUs+e1zpMbpAsMOfaL4lDKBkW0yABJ1uKUQLGTjrAu3Qk1px+VHSvN/x0oqAWgb vkSA== X-Forwarded-Encrypted: i=1; AJvYcCX1NbRRMoxHyFE7tIDd1j9ZQPztTt6ZuotGGQKTftfncrnIqUBJefQuVbxxRHQUL4tiEyiqXSgEpPM=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx83aN0/pQkCrYtPSpUeliZjtVf1kk140jBgOMf/ccKty3CA3A6 Hh7ZZW+6Kwj/5aYUh+k64l2Et5gvAHh+jnhezWkXXdg+iQ88Kai1nL17aFtN4B1dLw== X-Gm-Gg: AZuq6aKZVnK+oPEc9t/rQWVPL9tCZljYyNyaY8gaXpEta0Fo0smFIh1gOP+RXgx0Yip f8Vv3hOsx8fUxb0UJp1ncSYRriDorLPYjT7pRvQ48NBX54nDMzzZd+3DDRTrxd1BdofrelTG2dm wYv3wR6iKfunVIisKCqMHSnGULpS9ZvbY6HITH3V4kilrS3Bct5olLk47jpXfq4dcTt1By2S6h4 zO/uE+yiBbWfDkg0/0DVBVjMjoKCVyeaxXJK2/orLqabdA5dckFWR+zoF7gKxymnF59RFdct9tv wSHL7vLaFUPl9hVp96Pls8k6mD8pQ0CtGzww0yNwDrfRcvFTLE3kE9freXWdCIrpmtnVq6rM4Nc TCAtymabT45eheMopB9HjOIKurRZCeKXV7hpGaGSPc9pUEK5a2+V6YGU7zYyhIUlAejir+Oj3AO DO+G8Uc58+FeXlr0bNka18rlZtYsMMldHuY3QLNJgB9mn8WP7v0Wcer5bDZ4zDj81ufb2MiiXKm 3M= X-Received: by 2002:a05:6000:3110:b0:433:1d30:45f with SMTP id ffacd0b85a97d-435f3a6d009mr384971f8f.1.1769706105484; Thu, 29 Jan 2026 09:01:45 -0800 (PST) Message-ID: <1bd0726d-20d8-4506-bb8e-849fd8b091a7@suse.com> Date: Thu, 29 Jan 2026 18:01:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 05/16] xen/riscv: introduce tracking of pending vCPU interrupts, part 2 To: Oleksii Kurochko Cc: Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Romain Caritey , xen-devel@lists.xenproject.org References: <58a7723ec48d84b91fd4730fe3ae653f55a0fd99.1769099885.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: <58a7723ec48d84b91fd4730fe3ae653f55a0fd99.1769099885.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 22.01.2026 17:47, Oleksii Kurochko wrote: > This patch is based on Linux kernel 6.16.0. > > Add the consumer side (vcpu_flush_interrupts()) of the lockless pending > interrupt tracking introduced in part 1 (for producers). According, to the > design only one consumer is possible, and it is vCPU itself. > vcpu_flush_interrupts() is expected to be ran (as guests aren't ran now due > to the lack of functionality) before the hypervisor returns control to the > guest. > > Producers may set bits in irqs_pending_mask without a lock. Clearing bits in > irqs_pending_mask is performed only by the consumer via xchg() (with aquire & > release semantics). The consumer must not write to irqs_pending and must not > act on bits that are not set in the mask. Otherwise, extra synchronization > should be provided. > The worst thing which could happen with such approach is that a new pending > bit will be set to irqs_pending bitmap during update of hvip variable in > vcpu_flush_interrupt() but it isn't problem as the new pending bit won't > be lost and just be proceded during the next flush. > > It is possible a guest could have pending bit not result in the hardware > register without to be marked pending in irq_pending bitmap as: > According to the RISC-V ISA specification: > Bits hip.VSSIP and hie.VSSIE are the interrupt-pending and > interrupt-enable bits for VS-level software interrupts. VSSIP in hip > is an alias (writable) of the same bit in hvip. > Additionally: > When bit 2 of hideleg is zero, vsip.SSIP and vsie.SSIE are read-only > zeros. Else, vsip.SSIP and vsie.SSIE are aliases of hip.VSSIP and > hie.VSSIE. > This means the guest may modify vsip.SSIP, which implicitly updates > hip.VSSIP and the bit being writable with 1 would also trigger an interrupt > as according to the RISC-V spec: > These conditions for an interrupt trap to occur must be evaluated in a > bounded amount of time from when an interrupt becomes, or ceases to be, > pending in sip, and must also be evaluated immediately following the > execution of an SRET instruction or an explicit write to a CSR on which > these interrupt trap conditions expressly depend (including sip, sie and > sstatus). > What means that IRQ_VS_SOFT must be synchronized separately, what is done > in vcpu_sync_interrupts(). And this function is going to be used from where? Exit from guest into the hypervisor? Whereas vcpu_flush_interrupt() is to be called ahead of re- entering the guest? I ask because vcpu_sync_interrupts() very much looks like a producer to me, yet the patch here supposedly is the consumer side. > --- a/xen/arch/riscv/domain.c > +++ b/xen/arch/riscv/domain.c > @@ -171,3 +171,68 @@ int vcpu_unset_interrupt(struct vcpu *v, unsigned int irq) > > return 0; > } > + > +static void vcpu_update_hvip(struct vcpu *v) Pointer-to-const? > +{ > + csr_write(CSR_HVIP, v->arch.hvip); > +} > + > +void vcpu_flush_interrupts(struct vcpu *v) > +{ > + register_t *hvip = &v->arch.hvip; > + > + unsigned long mask, val; These are used ... > + if ( ACCESS_ONCE(v->arch.irqs_pending_mask[0]) ) > + { > + mask = xchg(&v->arch.irqs_pending_mask[0], 0UL); > + val = ACCESS_ONCE(v->arch.irqs_pending[0]) & mask; > + > + *hvip &= ~mask; > + *hvip |= val; ... solely in this more narrow scope. > + } > + > + /* > + * Flush AIA high interrupts. > + * > + * It is necessary to do only for CONFIG_RISCV_32 which isn't supported > + * now. > + */ > +#ifdef CONFIG_RISCV_32 > +# error "Update hviph" > +#endif > + > + vcpu_update_hvip(v); Why would bits for which the mask bit wasn't set be written here? > +void vcpu_sync_interrupts(struct vcpu *v) > +{ > + unsigned long hvip; > + > + /* Read current HVIP and VSIE CSRs */ > + v->arch.vsie = csr_read(CSR_VSIE); > + > + /* Sync-up HVIP.VSSIP bit changes does by Guest */ Nit: s/does/done/ ? > + hvip = csr_read(CSR_HVIP); > + if ( (v->arch.hvip ^ hvip) & BIT(IRQ_VS_SOFT, UL) ) > + { > + if ( !test_and_set_bit(IRQ_VS_SOFT, > + &v->arch.irqs_pending_mask) ) Why two separate, nested if()s? > + { > + if ( hvip & BIT(IRQ_VS_SOFT, UL) ) > + set_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); > + else > + clear_bit(IRQ_VS_SOFT, &v->arch.irqs_pending); > + } In the previous patch you set forth strict ordering rules, with a barrier in the middle. All of this is violated here. > + } > + > + /* > + * Sync-up AIA high interrupts. > + * > + * It is necessary to do only for CONFIG_RISCV_32 which isn't supported > + * now. > + */ > +#ifdef CONFIG_RISCV_32 > +# error "Update vsieh" > +#endif Here you mean the register or the struct vcpu field? It may be helpful to disambiguate; assuming it's the latter, simply spell out v->arch.vsieh? (Same then for the similar code in vcpu_flush_interrupts().) Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 29 17:03:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 17:03:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216912.1526826 (Exim 4.92) (envelope-from ) id 1vlVQf-000545-4c; Thu, 29 Jan 2026 17:03:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216912.1526826; Thu, 29 Jan 2026 17:03:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlVQf-00053y-1c; Thu, 29 Jan 2026 17:03:37 +0000 Received: by outflank-mailman (input) for mailman id 1216912; Thu, 29 Jan 2026 17:03: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 1vlVQd-00053q-Fw for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 17:03:35 +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 717c047f-fd34-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 18:03:33 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-47ee937ecf2so10159295e9.0 for ; Thu, 29 Jan 2026 09:03:33 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c42895sm213120475e9.14.2026.01.29.09.03.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 09:03:32 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 717c047f-fd34-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769706213; x=1770311013; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=vCcfHHmatJ4vGGgYGaUxRM+jo98CkzvCmhVWfzCg96w=; b=N8bLbcEqSMqQrFQX236aixYZ0uc4MbZZsfSSUopFtSQSTjpCSuSnpDKwexIxK7ko34 Fy/e4izk45alMdcb9siZuyiDCMIAXjNCcUcJ+9E285rzx8VclQM/dUJRUq5uaBwzebe3 JqHztE9RP2zFchy5Du8gIIwjmT1PC0qTbXG8XK4Tdf2VVigBb8k6yqRnOdW7viD0Dg4o riZkPXia2mhQez7L33dQ/bo32YFo7C/wFAYS7dHD+VUCnBT6/GlHXIknPoeKYadjsbjr m0SOyFwxlAiUxZVKil3Ya+7lWqpDwBrY/+fkfvG2orikMLuntsgNcOkHfTUKN4i0jvSx 3c5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769706213; x=1770311013; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vCcfHHmatJ4vGGgYGaUxRM+jo98CkzvCmhVWfzCg96w=; b=l+Npk9E3WFV6fq98Czpr3kdwmAJq/TAUpWQkTSJv0fymEU/Y0llMTLacUV65bzBZY1 FgqIbf0Y7xOEmRp0huqC9Cn64kPygyXIbl5R4rTeta4mvkgQMwjzAhklva736y5zOoGF VXH92cryOIg4tBp8fil8wcT3X8V5MVorePA8KNy+eawhFCnZ6z+M7fgtkD442Vj3qQEj RwQDU8Ds9WuhBCMGjewlCwVl08OvANIHgD78/3O/U1UBOsiiM9I4FKwTk6LudF7C6ev7 mlzVCe84cLj2S40Ur+DYRrwRs7n7LS7FwngBcX9aY2w7btylcQUlVAzz2y1yGh+UAlOH 3qyg== X-Forwarded-Encrypted: i=1; AJvYcCUI3aXvRyUmTsA5qnc+xlqekVX46YB6uLcw2sEfN93HCOSdJFzXM0x1pM62rTCmm7nuMARnB9ac7GA=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywag1TMmn0N94LTBAZ4OjsFBJ/S93QqRLAeuHyvAWERUUca8WcH cKcSjPNuJujA4yRU8RmHusa2/IVqDqDSuJDuIAeafEsyFLRkN0yZNBFvcE5Fvw3L4w== X-Gm-Gg: AZuq6aIYHxizlJX7yOpj6PKR0HrCzijw6JUgg8RXBLMk/zalm8go9zIjEMHaqfEiQlE P8bbQQnboOZ7KH3qWEQQjCeC+Q+QxazXKQ9T1Zhi/u7uImh91MMtgL61heDPRjA7gcSyeOtxrqw ge5bnAQjfRkel0XJAylizEHGOl2n1vJNGnKxgEmejUf1ftibM6gZ2K2Tx157RblutYYtYUITVHl K6ukibe1k+5D4yJ+B0oscRogmIRXJ8Lpe2hT1I2VZuYph9Uvq58LqKeyO0oTmFqTEx1YvQ86dee edr7oPVcePZ/nHib93JHZns09zjQnFFpHq99bnd4uuccTsZaETMvu2GIzaf81ZCh2dTydnb30+W 8911R3MZXGJNzYCn1TVPzA9TsPnk5vNFbINJE2p2s5tt9R8B4nm/VUrUOxIIKAgBNrvCVPwEdD1 pFGonoZ+NCoZfyY4Tar+hT+7DEvAFIS2C2eUSAO0fr/De6c1/9LO2LI0c0y1AoYL5I1X25Y1FOh dw= X-Received: by 2002:a05:600c:8b05:b0:480:1c1c:47d6 with SMTP id 5b1f17b1804b1-4808289fa19mr54506835e9.6.1769706212784; Thu, 29 Jan 2026 09:03:32 -0800 (PST) Message-ID: <0d4f6079-1ce3-45a1-841b-4dbea29cd315@suse.com> Date: Thu, 29 Jan 2026 18:03:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] xen/riscv: route unhandled interrupts to do_unexpected_trap() To: Oleksii Kurochko Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <3b2a9dbe-fa14-43a3-a7c3-a4c1396a5c70@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 29.01.2026 17:56, Oleksii Kurochko wrote: > > On 1/29/26 4:43 PM, Jan Beulich wrote: >> On 29.01.2026 15:40, Oleksii Kurochko wrote: >>> --- a/xen/arch/riscv/traps.c >>> +++ b/xen/arch/riscv/traps.c >>> @@ -196,6 +196,7 @@ void do_trap(struct cpu_user_regs *cpu_regs) >>> { >>> /* Handle interrupt */ >>> unsigned long icause = cause & ~CAUSE_IRQ_FLAG; >>> + bool intr_handled = true; >> Of course I don't know what your further plans are here, so maybe doing >> it this way really is desirable. As the code is right now, I wonder if >> you couldn't make this a 2-line change, ... >> >>> @@ -204,10 +205,12 @@ void do_trap(struct cpu_user_regs *cpu_regs) >>> break; >> ... using return here and ... >> >>> default: >>> + intr_handled = false; >>> break; >>> } >>> >>> - break; >>> + if ( intr_handled ) >>> + break; >> ... simply dropping this break altogether. > > Well, your change is better but it won't apply to my current code of do_trap(): > .... > default: > if ( cause & CAUSE_IRQ_FLAG ) > { > /* Handle interrupt */ > unsigned long icause = cause & ~CAUSE_IRQ_FLAG; > bool intr_handled = true; > > switch ( icause ) > { > case IRQ_S_EXT: > intc_handle_external_irqs(cpu_regs); > break; > ... > default: > intr_handled = false; > break; > } > > if ( intr_handled ) > break; > } > > do_unexpected_trap(cpu_regs); > break; > } > > if ( cpu_regs->hstatus & HSTATUS_SPV ) > check_for_pcpu_work(); > } > > So if to use return instead of break here, I will miss the call of check_for_pcpu_work() Ah, I see. But how should I have known without the description saying anything along these lines? Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Thu Jan 29 17:34:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 17:34:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216939.1526837 (Exim 4.92) (envelope-from ) id 1vlVtx-00012i-F3; Thu, 29 Jan 2026 17:33:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216939.1526837; Thu, 29 Jan 2026 17: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 1vlVtx-00012b-Ba; Thu, 29 Jan 2026 17:33:53 +0000 Received: by outflank-mailman (input) for mailman id 1216939; Thu, 29 Jan 2026 17: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 1vlVtw-00012V-Ix for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 17:33:52 +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 ac79fe23-fd38-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 18:33:51 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by IA3PR03MB8455.namprd03.prod.outlook.com (2603:10b6:208:53c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.9; Thu, 29 Jan 2026 17:33:48 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.008; Thu, 29 Jan 2026 17:33: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: ac79fe23-fd38-11f0-b160-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qK0C72eA66ZCJzqCiNMo7F4Z8WWGEt1mrNKMx7htRLHA//hajPGxHwY01PP0AKAi/7LV6r+ohnrs6Fm/ozDdW4F5EjD07XFjbvZZk0C/+StNrfzx4XJEwzngVZ6j1DCtgO3uYgJlE+LUaJuPgq2ynw9Nw4Q504RYETXkBqYy4HnEwUm9fYhC2JOr9612B6UB99+pltgTUhuTArRWyxlTDwx2bN2vCaYxo8BjaRd+sJfkJF9uSKlrHfBblJc08FPwRoVIWy4hEolWxT63iGjSkxVYZsZOOxr4f7h3j7PpSUki1ifnZRSAz2lrbUgV/bhb51yJ3DmxvO4uCTwMhhmb4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eWHjyiGi6yM4GUU8FOEpWD4BhCr0Dthkr0JJUa2/YuU=; b=GmQgGjphKGFKbUkZEpJbxLHhjHGwzlqTjHry1U2GigoMtfYtCSwXIA+WFIZR8VwFheGekXrCbyo+pdUnFM8sFxKfNGDb5B6+QZUtPsSQAupVJGFYHvmEC9+tE71mPsi/bAkxHc4VgXNQf1o6Yb6e5onN3i2c6LuAT+Vcg78lHqPG4YLPswSYo0MSs3h73EqYT7eDu2ZupbczznSWeXMkGT75N2I7RQIoHjpJH3XOMe7TwijIqU3byVeelMzyM+6OpewKY6+T77vUFbzAMQ01Xc8ySHAS6rPk53T1jSzz24A4cQXDY4CJ7LDjDPdNDuOu3QSeLmk9rdEKPbY0Lvcqyg== 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=eWHjyiGi6yM4GUU8FOEpWD4BhCr0Dthkr0JJUa2/YuU=; b=BO1ftad+LJEZ7EYIV0cWWzOyoWcY5pQDv7snvTkA1finNWKNyJ/3b49JrENnqS9dUfj9TJ9+wdjxEaxf3Ib+b60aquScI28Awb6smVzDDrPWj/gAiImMqRsVCotjSXkHKtoeKRPgjY3Ipx6Kw0eZyQqZniwqtW1kuV0jNZekWFM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 29 Jan 2026 18:33:44 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , Andrew Cooper Subject: Re: [PATCH v4 2/3] xen/mm: allow deferred scrub of physmap populate allocated pages Message-ID: References: <20260128120339.47373-1-roger.pau@citrix.com> <20260128120339.47373-3-roger.pau@citrix.com> <163e1fed-8a06-4078-aaff-8f0ad0ce6601@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <163e1fed-8a06-4078-aaff-8f0ad0ce6601@suse.com> X-ClientProxiedBy: PR3P191CA0011.EURP191.PROD.OUTLOOK.COM (2603:10a6:102:54::16) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|IA3PR03MB8455:EE_ X-MS-Office365-Filtering-Correlation-Id: 5bb20d02-e0e3-450e-898e-08de5f5c8f52 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?ZXFWc1B3eUw4UWdwT0FUY2dQY3VKb2Y3Ny9qc1ZodFRCQ1JScWh5c09XUjgx?= =?utf-8?B?bkQ1QmFiNHhRdTRnRzVleGk4RWlZOVg4T25kOVhKcE94ZzU5YytLUERPYitp?= =?utf-8?B?NlJLeGxqVCtlYVhFbXBCbXZUWHhYT0tWV0NYekRwdHRIcmEwY3JTY2NVdDRJ?= =?utf-8?B?KzY2b05MZ0xPR2JEcDJoZUV4UmptVnJuZXUrZ3dzOG9MNnR0a2tScmRVdUVm?= =?utf-8?B?ejJTRGdIWnFaVUkxOHkvOXhzaU9WMnVNUUVhWFNTR0czc3FuUzNLampIb2pp?= =?utf-8?B?NFRLWlBQQXQrTDBDb1NtQm9XOXNjSm1nZkZEYzZVV1N5aDJ3U3p6STRFNC9w?= =?utf-8?B?bmtRWE04MXp6SFMyVDU5Y2RFUGxGUjh3VU9hbWZKbTVWSkUzS2t1WWloV0lD?= =?utf-8?B?YU9heVFGYTBSZ3dpYjFKK3hQVlhyN0xnM2xnb0VCUjI5SWdnK1J0WGROYVA2?= =?utf-8?B?cDNWNkRvYTl2MHZKSTdIRkRidmpWRzJCQlNFczdKZVN2VUNPWGRIQVo4bWMx?= =?utf-8?B?TDkzZ1B4T1MwbmQ2SVQvZU9QWVJweFE2Zmg4YUErZ1FuMjBPWnVRUGUxVlRl?= =?utf-8?B?VXBJa3VMYWsyMkRCdGdydGpjRE5CVmFjMlJkTUlwYTRybjhsdjBXYkdUSUVw?= =?utf-8?B?MzA0dDJybjdhbDFkUVZydi83TDdNWWkwTlVMc3N1SmtTM3BUaXVnSnJlQXlu?= =?utf-8?B?TXI2U2NLZlN3c3BUN05kWm1nc05RSVVLOVFnUG44S282aFQ2bDJxRURQSGpW?= =?utf-8?B?MUtkZEhTaFpRbUFRK0RDd0YxNDBNWlRmMkt4WnNkd1l3WXlPd3ZoWHUxVVll?= =?utf-8?B?U2NCV0ZKSk13eTFEY2ZsYTVYMG54d1pzL1RRY2lZWHFrWmlMaWVaNDEvLzMw?= =?utf-8?B?dFUwNnZLRHFXVE1xQnhHN3FSRXlsZHhaZU9Ud083TVVzWldzQm5heFU2M2Ro?= =?utf-8?B?VUU1WXVNNVBhUklKVy95WTdMb3BjWVVjZnZYdnJDQjZvdnV2dmx1ei9jZGVV?= =?utf-8?B?cGJFMWVMMm1rMTJveS9BUVd6cWV0MHRCQ1ZFTDU0OFpmMkE0UVN4bTROcWJ4?= =?utf-8?B?cjQ2SkM1dWlCeXc1cEo4TGN3a3pmY3VyUUV5ckhkMXByaFlvWTYzRHR4TWZS?= =?utf-8?B?Mk1UOTN0NVZGVWpXRGtnOFo0Z09EdzJkc3dsZkU1TmQ1MmZ1T0hvR3k3YmFY?= =?utf-8?B?SE1kY3NLTm4remRrWDlSUGpFejZnNGxVNWYzLzROTldlUXNraHl2UlBNd3Nu?= =?utf-8?B?cmpUYjcvdHR1T05pa0dBQzdCeVJvWVFIWXp6WGs3VEp4ZklkSHgwT051WlV3?= =?utf-8?B?MkJHY2FFWGpEYllXcHNreVRQcEJNUFZNWHphdSt5eURUcEVEckxOSmtBQ0Nm?= =?utf-8?B?R2V2WXNVV0RYUllzdTduT2R2MUhPVWlDTzFrK2tLYUJxeENCb2V0L1dyWjlw?= =?utf-8?B?T1kxaWlvNnh0UUdmam9qNG9XMEVHQWpidmVqKzFkWmdSZWNjUklUVEM2bEpI?= =?utf-8?B?VW4xN09WZkdzdCtvaExsMW9BOFJOWWdSZVZxOFRmSFhvUDNIL1dNVWhFRGpr?= =?utf-8?B?bE1OdHpKTGN1WW1maXNGYk5Tb1k1RU8vc1ZYeC8vQTRXSDViMHRScWJDcXlB?= =?utf-8?B?dDIvZXd0WEloN0kzSXhDSXhBUnhod21tY2VoRXhLQ2o0UDFCc2hYNW9yWjNO?= =?utf-8?B?MXgrUW5xbDhadG13d3NYNnFzQ1J2eHhTcW9KVjcvS052QldkU3JKR3VxVmVq?= =?utf-8?B?QURTRVRUbFdmTmJlcnRBM2Y3QnJWTXpIbXRhelR4SnhSMEthMnNHNEZxc3RN?= =?utf-8?B?bXlRZlZ5VGU5b3paRHRlMWgrR2tGbEw5OWJYa29jTzYrWnlLMjduWmRDRjE3?= =?utf-8?B?eWdyT2IvTFcxSG1FQ29oQmdHYytmeEtMVllWU0N4TmI2eFpseXhBMXJ2VHNa?= =?utf-8?B?eWZqSUs2R05keVJLSDdZR0RZUVkya01lSysrQTQxeGxOQjFKaFRVSEZPeWJV?= =?utf-8?B?ZjNmTFA3NVVPZDlDSkpQSlpiTDJWZm81UnBuTndGdWJuT0lsYzBJMnduT3NZ?= =?utf-8?B?S3Z2MFRJaDRhcTZjWVBEclpWV0NpWmFIbHRKU3V4UU5Jb0JzeU4zZmNJeFRV?= =?utf-8?Q?zShw=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RU0vOUNjNHJ3Znl5OEVGOEMvd0w3OW94L0xHQjNjYXdVUmZXaUo0Z05za0NJ?= =?utf-8?B?QmFiVUZIcXh1ekZYclAxNmp0ZmtmVU8rbXRXbFBpUFlIVG5XU2gxWm9LZ29V?= =?utf-8?B?SktSNVZQNExNRytpQjVlTzltSXdNY1NDTHlDWXNxV0lQd3IxWUJ2TGllRzVB?= =?utf-8?B?SlVFdmxqVGJTbU9jd0dXaWhVNGw5OG9NQ24zenVtNWtieVIvdVFzS2RFdlp6?= =?utf-8?B?SG1sU1pSZGV3cDA0bEN4Z0JLVnNaUUZoY1FuQUozYVcybHpxQUhTdE9JRktF?= =?utf-8?B?QzRGWE1UTHo3VHdwdWRiSjlVSlN2eUd4NGZMdmRuL2g0OHc1Y0h3YThFWE51?= =?utf-8?B?K0s2WXAxTVVPaUpXNVNvaTF3MFk5TmhGWmUzdHFRRllzcEtRcHVycktFSzNw?= =?utf-8?B?RzNoM3lVRXJIVkRZUzNVVGpFQ3g5NThrbUpudk5XdlhQbnZ6MEtQckczVjI1?= =?utf-8?B?QUdPM2x0KzFheTY1MW5rQUUrYVhvalg3U1VxTEtaU0pKWVRQZW5rRVpPb1Y0?= =?utf-8?B?VURVRlVQNC9kRWJFUXdnS0R1aTZTcTVINGFPK0t3Z3lnS1JLZFdRZnhSdXhG?= =?utf-8?B?aDE5NkpnbEZScXArbDNTUC9SNTRPMityMDVpK0tDcmZNS3ZKVWtydGFiNDZz?= =?utf-8?B?MWpxTWFuUE56NEVlN3FnQlUrWkdnblhCNG8wanV1M0VTZW5sYXpBQll6bUFS?= =?utf-8?B?RnhBS3cxUUhXUXdlcDhkMmcxa1o1WWNabFJ5d3hWV3UxWmN5eU1DVjFNUFlM?= =?utf-8?B?dWVMb3F6THdmY0RyTHM0VGdPRitKWTJFNlR1cUxjUllpbEFSYXd6MmFTdkRX?= =?utf-8?B?NURldUlEQTl2T3RYVWxFQlRSa09Sa3BuTVZ1SHA0WkloVUk0TDU5d0pJWFJM?= =?utf-8?B?ZlVzb1IzWm1seEhqeVk4dnFHU2hadkNyeVo1RXFzeFkwU2FpZmZhK2piVHBL?= =?utf-8?B?OGIwK0MyVVhmWHo1QTZTT0tySit6ME1aOFZOVVNFTHptaWh5VEMrc0xtRmpY?= =?utf-8?B?c1ZYd3cyNE5kMFBOV2hvYWZpOVd2citKQWtkWTREY3FPYUNJQkxxYkwyb2NL?= =?utf-8?B?YlhUV2VoZmlLV29yQ1UxZVdRc0RsaU9sMGRiUFdRd09pKzVabEpReFlKU1dY?= =?utf-8?B?KzBlRDRWMVFIQlpOdFlFdUdxVDRkTFQ5T2lvQ0NkTnN0Tnl3cWgrMUx0UkFz?= =?utf-8?B?TFE1ZkVBODkvcmI3eGpmT25FVmxrRTQ0elNsdE05Sm9sdVNKUko1aWt2aURL?= =?utf-8?B?dnJYOEVuTW84RUhqMWZxbmhockZNeGorOFBlSXNRUW4xUWtub0tmaW9mODNi?= =?utf-8?B?RGVoZEdRT3ZsOG54VS9KTHVGVWUwUUYrUWFtRnBOUDY2Wnl5SUkzL0d5R3Uz?= =?utf-8?B?VEdabjVobTB0WkYxUUVuWlVhU2pWTGFyVUlJeDFKRHRJK3V3azZwYmhvcjJo?= =?utf-8?B?ZXIzRWtPQlluV01LN3lTZVMzL3JNdFhiRlkwQkJ2ME1ZMnNvM0VvRVB4Y0lM?= =?utf-8?B?cS9vRHpuSW5rbW9ZWndyU2FmV3U2YkhnRzRod2I4REVRMFhlMHBaV2ZKQ203?= =?utf-8?B?Y1dpVXh0S1owdmpaUXoySDFnSnpLdDJCUDlYZzVvRHZCVnlpck53R0pMTE9D?= =?utf-8?B?eW5jdE02cFphMUZCU2JBMVBneS9tdXpaVEgzTzF3WnJWcjhzMGxwMWRranBG?= =?utf-8?B?aWw5RzhRWnVrbWVUVHh3YlhMVGJaQThzOTFMUWZNRUFPOUlLRFNObVUzT1F0?= =?utf-8?B?M1ZqNFI4aE5EZ2pKNTMzNE9UK0J6TmZ3ZmhkUkMyM1Y3dXJBRWx1dDJaeHNK?= =?utf-8?B?MHFEN0RpY3dJMFhWMTJXa3diTkIyTWNOazd2UlZqeHloQkM2OVdMRHRRaXFF?= =?utf-8?B?VDczaU5ZSUpkdHA2MnduRFY4TzVlUkllZW11TW8vOFlvOVpmdjQ5YUlIYlVu?= =?utf-8?B?c0FBZEVPd1c2ZXBkbzVTbC90NVZ3S2pubVVpS3RaWDZFb25QK2d4UWFzSGNq?= =?utf-8?B?RXc1d0VkY1pMaDV1anV2OVJCWUZPZU9rbVRHckVoa29oOTRqOHBtSUhhVnVD?= =?utf-8?B?NzE5VFovaUlrQlJycVUxZmdFS28wVEszbEV6SjdYUWFrRGVuQ2Z6c2JuS0c4?= =?utf-8?B?bWcyR1Z3MnlUVTUvS1pzL01WMmFRYzJrMmxlM0JHTlRXZHIxYjQ0NlFnUFAy?= =?utf-8?B?NWJIa3U1UkVMUmVyRE9CdDRIdk5ha2lYaUp6dUM4QVd6Z1dLd2RtT0NSZlZw?= =?utf-8?B?N29UbE9waHpWMXZMcDlRZzd5Y2Z6UHJBa1hvTGdnSXNIaTBLZkNSbWtQeU5B?= =?utf-8?B?c3drRG5UR2x0S3k4cUg2STZsbjd2L3ZXaVJ3R3Y3d29mTmMvTlFTdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5bb20d02-e0e3-450e-898e-08de5f5c8f52 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2026 17:33:48.1251 (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: KPDnoq4huSj2mbD6WcVouiPIrxPlkzFFKh/Z/Rta/1qcBGPjLHfcmi7vAW+WtXHb6KqZ8sDakavB74wI5L/wpQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA3PR03MB8455 On Wed, Jan 28, 2026 at 03:34:11PM +0100, Jan Beulich wrote: > On 28.01.2026 14:33, Roger Pau Monné wrote: > > On Wed, Jan 28, 2026 at 12:44:26PM +0000, Andrew Cooper wrote: > >> In principle we could assert that it's already NULL in _domain_destroy() > >> which might help catch an error if it gets set early but the domain > >> destroyed before getting into the domlist, but that seems like a rather > >> slim case. > > > > Given my understanding of the logic in the XENMEM_ hypercalls, I think > > toolstack can still target domains in the process of being destroyed, > > at which point we need to keep a final cleanup instance > > _domain_destroy(), or otherwise adjust XENMEM_populate_physmap > > hypercall (and others?) so they can't target dying domains. > > Considering that these requests will fail for dying domains because of the > check in assign_pages(), it may indeed make sense to have another earlier > check for the purposes here. Otoh doing this early may not buy us very > much, as the domain may become "dying" immediately after the check. Whereas > switching stash_allocation()'s if() to > > if ( d->pending_scrub || d->is_dying ) > > looks like it might do. Oh, I didn't notice the check in assign_pages(). I think a check in stash_allocation() together with a call to domain_pending_scrub_free() in domain_teardown() (which is after setting d->is_dying) should be enough to ensure the field is clear when reaching _domain_destroy(). The call to domain_pending_scrub_free() in _domain_destroy() can be replaced with an ASSERT(!d->pending_scrub) then. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 29 17:41:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 17:41:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1216957.1526848 (Exim 4.92) (envelope-from ) id 1vlW1L-0002mf-9y; Thu, 29 Jan 2026 17:41:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1216957.1526848; Thu, 29 Jan 2026 17:41:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlW1L-0002mY-5X; Thu, 29 Jan 2026 17:41:31 +0000 Received: by outflank-mailman (input) for mailman id 1216957; Thu, 29 Jan 2026 17:41:29 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlW1J-0002mS-Ri for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 17:41:29 +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 ba873408-fd39-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 18:41:24 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by CH4PR03MB7603.namprd03.prod.outlook.com (2603:10b6:610:23c::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.8; Thu, 29 Jan 2026 17:41:21 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.008; Thu, 29 Jan 2026 17:41: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: ba873408-fd39-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Jp8tWPYOE3lWc4aBjg2VNx/f9KtQPdKh/LiSI33HtRoQ1fQWYMUgVyrAhvI02vNcmLNC4JK09DwMZuNvfuSjblGW8XWwKL2LgF3qYeF/MJzW07gOQZpg8o30/0TOCEsnPEQqSdAgwJt+3uYXauCoS41DG0qQfXB/Mm2m249PZ0XkL5D7Q3yIfQBmoTdU4xpO5Bjhr3ZVIjqMo4OkZEkOs1baZkUvwXgP3qYHcWN8N4K7fEZhbhw8Iu22fvvJxuQH5/tQjsG8Wqyhg2/+7DZ4iclQeo6h+/TyMt2lZA3d+3vWmP6v3mmSoJzSJ8q/DMFzousfRwvzYqPEK2TbRZGCDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SiqXL9W6hAWngzdxVBW/2/UPd4WslBMeLjVSaL0Wvz4=; b=GY67TgaizhMqQM2dAU8qaQhtfdSD00ilcNh4dMZEx+Afz9ayDp7amxb5E8wGnowqVuT9ZY5wG9HxLGDMA62Z3cPMzV6war9i8jI4aH2c7+Na/b0H/PdcQffLSBU8NSOtNuqENNVJ7SdmLkzDCeXHCjwVgqC8qFNTNKo76oOtJhSqk0LZzn+9nhPM/BPsFowQ7AhKcatm6R6ws9rh527uEx/6W7ssV79CEFcfvib8+aMWdjFw3VYDCj08FCP6vsNkSDPP8/DmSuAO/ELapuLcf77wfZuleMm9WTPaD+W8doqGVc4ENItswSIkim0zbUzwzsB3dtA6pzyk9BDZnZPSpQ== 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=SiqXL9W6hAWngzdxVBW/2/UPd4WslBMeLjVSaL0Wvz4=; b=JKFtUHYx1Hzr5yUa6W5KER9kQvzxNfyZq85FbNoLjRRb/Gbs3dI6DA2iGs98no0n1KXH8OdOCGKILh1toEm6t/W9hpCRYXxr4K7Zr8qOqKdD7W3R4JxidypYCAw3iBBgj8Om4uGjPuKUfXN3hqqhP6sRU1NSGtd/gD9ocw5tH9w= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 29 Jan 2026 18:41:18 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Stewart Hildebrand Subject: Re: [PATCH v3 6/6] vPCI: re-init extended-capability lists when MMCFG availability changed Message-ID: References: <45ea72d4-bbc6-49b9-8d29-d18876dd187d@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <45ea72d4-bbc6-49b9-8d29-d18876dd187d@suse.com> X-ClientProxiedBy: MN2PR13CA0016.namprd13.prod.outlook.com (2603:10b6:208:160::29) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|CH4PR03MB7603:EE_ X-MS-Office365-Filtering-Correlation-Id: 0bcfdfef-b566-4593-5cb1-08de5f5d9d37 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?cHU1cXJnQUtLOElEVU01NXpuaXhLQ2YwTGNScUs3QThBL0JTR2hIblQvYUtI?= =?utf-8?B?bHVLMis5clhFSnRPdG5IUmlwdHdzbFlySnF6ZjFtanhvRGdJYjdWbXhyRGpQ?= =?utf-8?B?M1JBQUFaTEZTMERUZWdqem5PbVRmb0FuZUZMTEJFRThWZDMzK3hUU1d0Q3E2?= =?utf-8?B?QTVYbnNqdmc2VlR0NGlzYUs4aGxTa1h5d3FVSmp3anFIYVZUYW1xV2JGbVpS?= =?utf-8?B?eUFRWXRSK2pGSndiN0Z4Rm1OekxPR1BrNmE1L2tpclovY0Q3amZQV0FKcDlX?= =?utf-8?B?OUtnelU2SDgvc3FOTlF6emRPMjh3akdoQi95ZXR0ZWd4Z0FBRmxKVm9mckp1?= =?utf-8?B?dWtwYS95NkttUk05Vlp5c1NZQzB1bnl4UUZxT2RMaHMreVkzK2JLYnJwd3NK?= =?utf-8?B?MDRuOU9BN1NweEdHQ3llZDBSNzZPT2t2WGFiZWVicXl6ZmhIM0pPRHZWYlRJ?= =?utf-8?B?dy9KQ0FyOGpnUlRPLzBsZVRiV0JNMkthenNFdDBQS2tuR0c3MlByTm9aYW84?= =?utf-8?B?Z0xhNWVTUVY3K1FGU0VtZ1djUE1LWk4wZTlKQ1poTXg5ZzVaSUpsVjkwaXZ6?= =?utf-8?B?bWJSLzF0OGFCOVdKU2VhUjUzdnJieVhEUFQwT285SXErOWtoNEx3NkoyTFNy?= =?utf-8?B?bEN4V09IcW0wSXJNR3ArbWZTWVhwRHVDNnd1L25EenYvTmpoT2RHeXo5QWYz?= =?utf-8?B?aENGUEgxc0JsUERlR2lrcjFlRUdUWitMQnlkSEViRUl6QlJVbys0T2hjeTIv?= =?utf-8?B?ZGgyd3JpbzduSVFQaXAvdXVtaGIraXMwQ1BWMXFWZkkzd3VkWm1GODlqWEd4?= =?utf-8?B?RnBLSGNTVjZsWVYzY1pObWxJQkphQUQxK0FuMTB5UG5Qd2dJN1hDMUdxMzJh?= =?utf-8?B?ZXZRWW9YTkFsVGE5ZzJaM2xiZUUvY1kwZnRnM2hKQ0FxdmYrUGNERDVqLzcw?= =?utf-8?B?VG45bCszekdsZjNwdk0rU0lVb200MkprK2h5c2wzQXdrQzdNYnlHa3RaTStO?= =?utf-8?B?MUdhREt5Z0liZzNYWmJHRGpLVm1CQ3FJYjNQVW9CTUM5Y1hYKzBiQjRNYVhy?= =?utf-8?B?dGtaZFlhOVBJM3hna090TFF0QXFCM1FKQ2gydzdQOUpJM1M3WWg1VE80WnJ1?= =?utf-8?B?UnNFSENZRmtCRUJrYys3MVFFRlNyN24ya21GSDlCY0h5UTJKUXpNQkkxR3Vl?= =?utf-8?B?SWt1aDNWOWR0L0w4MzBZS1R6dnNNSWdGVjZ1K3NUZDFzRmcxQlhOU24yKzJv?= =?utf-8?B?alhod3BZM0ZZVno5R3ZCTWFoK3hUVG5VaVBoL01LVFRMRUVMVmpYU0U0MDRy?= =?utf-8?B?ajNGbUxocjJsMGJrZ1E2YWNnT09kSjZzd1FwRTdRSng4V1ZiYVNPQnBWNkpD?= =?utf-8?B?cVdPS0RYUTE1WWtnM3lVcElodksxZXFITk9MdHhWMHFPRnluQXBiWVhTNkpY?= =?utf-8?B?ZHlPVGJUQmNwZzhLMHY4bGtqb09rR2Z0R1RIR1FkY28yaE92SEtFb1dQYnps?= =?utf-8?B?SVJjWHhtWmF1a1dYR1kzUi9tdnJVZ3ZNWGFPMEVCQ0F1cThFVUF2Y3kwVlBI?= =?utf-8?B?cGJvY1RJc2ROQnhOeHYvVnU5SStzRlFxaHluK0xKWGpFbGs2Z2ZqUlF2NitY?= =?utf-8?B?eGVqaGFMek9aQlFGTzVGVXBZdW84bWc5aXJHRUZ1NGdDYWxlSndLb3cxTUFL?= =?utf-8?B?dis4aTFEL0h4SDRuRkloVWdwdUhubmEyQ3ZkeHMwOUV5MWFubHErZGlXYWIz?= =?utf-8?B?L0FmRXdwdXB1SkVpVDVvVzVhRG9hOEp5eVhUVUQvLzZBcnh2eWJkZ0FiS3lk?= =?utf-8?B?aWl3dHNIMkthWERibTd6Y0Q3MmdUZEhlQVkyMFd6UlRhelcza1hkcEM4Smg4?= =?utf-8?B?cGV4NEhHb2N3RVovdXFpcm9CN0hwcEZRTStnRGFlQUpWVUU2OW9oMmhPTVJQ?= =?utf-8?B?QjdTSm1BYjBRYXowa0d2UlpzZW1aakx4V3NzY0dYTlJnSGtobnFaQk9BSUwx?= =?utf-8?B?ak4ydHg3SmJPT0o5WHJrVkxhMDNQc1FyR0xPN3pvYW5WcyszSkl2dEhDOWlF?= =?utf-8?B?ZHhsQjNObGJYaGh3b2p3OFV5UVJ1WkN6TFVxVklxTHp3aTRhNTdybUVNYjFx?= =?utf-8?Q?52KI=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?akhneGZPNmdKdHgvTmdtNnhOeTZFb0ZuRFFvaEVOOU54TVdkVnpOWEhlY2FE?= =?utf-8?B?OWlPMmZCRmJCb2VUZkd3eEQvdXZwS2VYOG1RODVDb2pURENEQzRzUFQ3UUND?= =?utf-8?B?MjdwKzlSTHdSdHFNTk1JSlU1MldhQVlvWVowSXdxMG9MQjhXZ1R4YmFiQkNZ?= =?utf-8?B?UnRaVzZLR1ZIMUFLWjhNaE5jdHh0eklNaUgraU5vZFFzSEMrUzFNYlB6TzN5?= =?utf-8?B?K1VxUXBlS01xOFZNU1h0aVdwYlRaNzg1bWE1eGtmWEZlaXR2L08xV1RyWlND?= =?utf-8?B?bEFERHFNaCs0VkViT2hPUmFhaVRRZmdXTFQvOFZ2amhMbEFkWEcwcE1LbEhQ?= =?utf-8?B?SDhGcnNhRXRFdEtoOE5mSXEvQ0M4MzJ1R0Jqc3NTSjRQUFJIalloTTJVVDNR?= =?utf-8?B?VUc4dk14N0JGYXUrRjFzWXZaZzlubDZhcUE0QTBHcTZVb3M2bGxnYW5GZVNw?= =?utf-8?B?L3BtYUxDUzVtZUZSWmkrY2FPOVlTT2o2b3F2OXlRNzZveDlKNDhjaWlqcXRN?= =?utf-8?B?K2JpRzFnY2x6U2E4TTdWaHZSR0JST01MYitmMmpzKzVWWjRoaW9JOXBZRk5G?= =?utf-8?B?bmFTK1h2dmZ5b0hFaEhhdVRmR251czFIUzIvZDFYUjZxVG9LRlV1T0dYMVhh?= =?utf-8?B?TDF3WXp1T09RWndvRkd6TzlpRTB0d2drNitwbkRpQWR4Y2FNKzFqTm1adUlB?= =?utf-8?B?cTlGdDJDRDlmMHBGSTBnK2NTVDJEUWJhU0pQbzErREFBelQyTjh6L0N5WGM0?= =?utf-8?B?TTdKVk9lMzFmcDRKaFpqQjJ2djhoblNObVhtTm5SVTdEK29jVlFHSU9EZVJS?= =?utf-8?B?WU9pNTFXZHMyYlZxcjduckJiN2NtZmFUYjBuVUZNa3VxOXZiQ1l3YVhrQ0Fp?= =?utf-8?B?T2JBcVNoNHE3Zk8vd0RvbHlBdENHWHNNTHlERUNPQlJxWDMvQVZJd1NFTllP?= =?utf-8?B?Rk1ianVlNGNFYlVGY1hscWFCNzh0dTRRWThWZ0EzWjA2UkorWk85S09iZEQ4?= =?utf-8?B?Qlg3RnI5ZUFHcEg3cW5nbVJ1dUpKSHRma3VyMm11NDdBT052WjJPUlE0bGdD?= =?utf-8?B?OTdIZkNFS29VMGVjRmQ0NklZamxVU1YyYnpnR05icmRnT1hoK2k0S2o3MnQz?= =?utf-8?B?T2YwSGhJMEJONERyNTFUL29Ka3M5c1VJODNkWVppVGFhN0dROEowbTdCVXp1?= =?utf-8?B?aVJhTExOSTZBTTY2MEZUOHRHSXRPaUg1NkNXanhyOUJaSUFCSnN1cVZ1a2JO?= =?utf-8?B?OHY1UnowNzllMTZmVFk0cFpWZkRYUUVWWEptdkRuaTZoOXZsdVpZY3h5Mkh3?= =?utf-8?B?eDdxVVlSNVFaYU9OQzd2MVdLejNrckxjM2E1ZVRXUW1QaUxBUER4TzB1L3FU?= =?utf-8?B?bFpQS0FiaHViWlFzM1c2My9RL1lHcjB0a0V2UHZZcnlVVzltVUxuNER2enZM?= =?utf-8?B?OUd1VnpkVHJxN2RpbHQ5VHltTVlFOXpJTlBRVGpLeWhVdEdHc3N2YmJtSlVs?= =?utf-8?B?STczblRQMGxlRTNqdGp4b3l1VHVRSTlXWEhmVU5sckZZK0MyY3ZlQVlRck0v?= =?utf-8?B?bjBGOGI0S1pGT011emhZaGJCcXJjemlXeEgzTk81V3d6S1hja25HV013WExR?= =?utf-8?B?RnVma09lRDM2b29mYTNOWUdjaTNHRGh2MkQzUE5yc3Ryc3FqbVBMejJINVRD?= =?utf-8?B?RzhRWWtKNmtTVngreEtCbGNCQmFMWFlValA1cVRvYTJzbjZwekxEYitsWnB6?= =?utf-8?B?U0V6dkpWRm5BV3E2VFJxb3h6cUMzRlplc1R3ekdybDI4MDQ5ZnFUMmxzVldE?= =?utf-8?B?azB4ZEpyYWRHcnZIM2h1WjNrdklWU01TUlhPaDVnSy9KNldzUllrTFFiWURk?= =?utf-8?B?dUN0S1gxckszc0tOT0FFUzZHSE1OcnhYbGlHdHZ6YnBkRjJtbitWOEdtUzlF?= =?utf-8?B?OHdjTnpheFBWSjlBcklldGZ3bndNcVNUL3M4bTFJd0tPdW1oM05vME83Mm4r?= =?utf-8?B?Q2F5bUs5NmNhOVgzYjE0Zjk1QXRUTkhkR2YrU3VEUlpqQ1FhZG9vdXgveXcr?= =?utf-8?B?V2JEZnFUdFNqMWpUMjRFcEdWZEw3UlA0WGlIbUk5MU5aTDlaWW01Q2tRNFlX?= =?utf-8?B?ZnB3Y0p3T1I4Y1M2WFRrNlk2UkRlVXZIZ2VqTzk3TldpNFdOeVNNQkRQN05i?= =?utf-8?B?TE9xdHZtaFJPNUdCQi9XNzNNMzFtcHlSRHcxVWRuNkdCSHRNU1ZaUEN5VUcy?= =?utf-8?B?cVZwSmozaFBWNlJydDYreVkzdzBsNVpwWnhZMnNUR3BXK0FLbExweVRReDlP?= =?utf-8?B?RkdNcTQyckYzV25hMldnWWtoME9YcFJzVjZUbmw4Y3NFdUtLY1VGdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0bcfdfef-b566-4593-5cb1-08de5f5d9d37 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2026 17:41:20.9225 (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: +VVZXFAokJYgqnq3HXLI0kfAiKIo3CsfWyHGWJwe/N9WBfGh/yuc6k4ouYjqkVEQKpVYpwtxcJ3Q6rNGWEdsFw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH4PR03MB7603 On Thu, Jan 29, 2026 at 04:54:59PM +0100, Jan Beulich wrote: > On 29.01.2026 16:40, Roger Pau Monné wrote: > > On Thu, Jan 29, 2026 at 02:10:34PM +0100, Jan Beulich wrote: > >> --- a/xen/drivers/vpci/header.c > >> +++ b/xen/drivers/vpci/header.c > >> @@ -869,6 +869,18 @@ static int vpci_init_ext_capability_list > >> return 0; > >> } > >> > >> +int vpci_reinit_ext_capability_list(const struct pci_dev *pdev) > >> +{ > >> + if ( !pdev->vpci ) > >> + return 0; > >> + > >> + if ( vpci_remove_registers(pdev->vpci, PCI_CFG_SPACE_SIZE, > >> + PCI_CFG_SPACE_EXP_SIZE - PCI_CFG_SPACE_SIZE) ) > >> + ASSERT_UNREACHABLE(); > >> + > >> + return vpci_init_ext_capability_list(pdev); > > > > Isn't this missing the possible addition or removal of managed > > extended capabilities? IOW: on removal of access to the extended > > space the vPCI managed capabilties that have is_ext == true should > > call their ->cleanup() hooks, and on discovery of MMCFG access we > > should call the ->init() hooks? > > Now I know why this felt too easy. Yet I wonder: Why is this done in two > parts in the first place? I think this boils down to us (me I would think) not planning ahead that capabilities might appear _after_ the initial device assignation. This is true for example when Xen doesn't have access to the MMCFG at boot, and it's only made aware of such after starting the hardware domain. Right now vpci_init_{,ext_}capability_list() is called from vpci_init_header(), but for the case where MMCFG is registered late we don't really want to re-init the header, so calling that helper is not an option. We might want to create two new wrappers that encapsulate vpci_init_{,ext_}capability_list() + the calling of the vpci_init_capabilities(), provided that vpci_init_capabilities() is also split between legacy and extended capabilities. We want to call those new helpers from vpci_assign_device() instead of vpci_init_header(). Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jan 29 20:28:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 20:28:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217008.1526856 (Exim 4.92) (envelope-from ) id 1vlYco-0004p7-8S; Thu, 29 Jan 2026 20:28:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217008.1526856; Thu, 29 Jan 2026 20: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 1vlYco-0004p0-5v; Thu, 29 Jan 2026 20:28:22 +0000 Received: by outflank-mailman (input) for mailman id 1217008; Thu, 29 Jan 2026 20:28: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 1vlYcm-0004ou-Qk for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 20:28:20 +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 0c30627a-fd51-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 21:28:18 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-4806f80cac9so8795565e9.1 for ; Thu, 29 Jan 2026 12:28:18 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806ce56068sm143099505e9.13.2026.01.29.12.28.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 12:28:17 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0c30627a-fd51-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769718498; x=1770323298; 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=saCq/Yzes5VXl76F58dkLElaB5R3og0823+IoM8YGVQ=; b=iGDjsjcsMCpvQF7HcIMdJM4dVIcQ5zAbbW3I0fAxpPz+bpezg/E1bYSWE6CJH2u1jo kPQrVNCZhqzTiixdJVUZBe6s47LfiN9KYyGwmX5u4IFwfpU6U+IwnvPEyTKZzI9dSVP2 7qqFRpobi0ibpkcdQdU6pIzJI1XwQ/IzD3CD1gZThED1BTtK2TxwYnDvhZXQP4lJrmIT m+IOnQTBFzx5achdESyLJKhy+9n+lEZHTPqZAerhQQyqBr7+hmFyWxlwgUgzOhH7DVY6 cMDCw3loKCGpCX4ehZZgsTOMrwsCtQy0zJg8KDorAxxiiEevObeMjgeSmtjMHNoItFmB TJMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769718498; x=1770323298; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=saCq/Yzes5VXl76F58dkLElaB5R3og0823+IoM8YGVQ=; b=K6K6QhmMcMxUxu24Ixpbu98/4Q/oouFX9rCzvv+ytxL9sA2rkFUbVSpp78xOTbS1mL +S/7Cq19WlG7whZAJWILsbAgbE8QtRs4kOf2YYMMeajg887MhlG54F/ZuK/brsY815oN bry/C8SoneAi7WsgpYZ+wecvOlRd8iKpgSjozr2CP84Hu4n00EC9pcZkBUuS/W0TpFZM TLKbBaopuoMyHxHP4HnTcAa3eQ88alsv/ugV79/+wj/TRQiHyPJxuxRyMzMe47Kho44F hxZ1nj/+UjYQtWdESZCl4kvXbJNJ0s/IYCdnKjJ0FgjlTzV4228L0imrfSoyiPMMshKa Spuw== X-Forwarded-Encrypted: i=1; AJvYcCUuH0/8iAP1rJtpOFMcKjuTsQUTKKKE7e1MuuvwdJ3FjclnmAULIMcsWEiWKLw3kBUZ5OeGE5b8ioU=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx6w1WoC4kAt9Pzd0oJI4yl4ZIAYoMpwqpEe/YBG9GwQzfhOUBi TtM+7yOHMBYHiFaXfyCUAixPZXJxS/mLOxlsD+yTYjgHEEf+Lq574dn8 X-Gm-Gg: AZuq6aKqi2+dV3HtrzVy6WU1e7nSy1HKPANWH8nZmalmLXOR1xPIbNBytyq9RZDTekt YNgmmCkpMw48BiVW92Ad5b65T8Y+g5HYDlwMVDprgRpKlrickYo52cUXDo2OthOeYzr3vp1UfhV qDbZy3ecxjhxPB9EIkAVgQ5c/dF1ReTJVqlVNzq5NQ+YWc1dUya5BSlemh9NupMBh9I2WFDewI8 GwoTclGmbGAj9ACIKUCfWcNWsw03VC2v7xFdbmH1lXazZJNm/hRp5I1L6rZSZslye85hRNEqVj6 zjJymJJS8SPHAkG1C9K1OF2KgzlKUdpQBafQp9UZYa4/y7RnDptMlCsJuL83MA6eldLbMRQjg6i l0mxccqflr6SzJ/2HUlN6819eIo9AdkH+UpYnF1z3XegRcxL3GSjcsEGU/UlvY7e/dRBMHRrAZJ jjM47Zz2q7ys8dpF09kCIlJp4KNbHuM3Uz53nnIjEDrCzXb3w3sPYjz69kyzlI+G0= X-Received: by 2002:a05:600c:348b:b0:47e:e779:36d with SMTP id 5b1f17b1804b1-482db4d826dmr3898415e9.23.1769718497908; Thu, 29 Jan 2026 12:28:17 -0800 (PST) Message-ID: <9ce6f636-3b75-4ccb-b5c5-d6a0fac30897@gmail.com> Date: Thu, 29 Jan 2026 21:28:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] xen/riscv: route unhandled interrupts to do_unexpected_trap() To: Jan Beulich Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <3b2a9dbe-fa14-43a3-a7c3-a4c1396a5c70@suse.com> <0d4f6079-1ce3-45a1-841b-4dbea29cd315@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <0d4f6079-1ce3-45a1-841b-4dbea29cd315@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/29/26 6:03 PM, Jan Beulich wrote: > On 29.01.2026 17:56, Oleksii Kurochko wrote: >> On 1/29/26 4:43 PM, Jan Beulich wrote: >>> On 29.01.2026 15:40, Oleksii Kurochko wrote: >>>> --- a/xen/arch/riscv/traps.c >>>> +++ b/xen/arch/riscv/traps.c >>>> @@ -196,6 +196,7 @@ void do_trap(struct cpu_user_regs *cpu_regs) >>>> { >>>> /* Handle interrupt */ >>>> unsigned long icause = cause & ~CAUSE_IRQ_FLAG; >>>> + bool intr_handled = true; >>> Of course I don't know what your further plans are here, so maybe doing >>> it this way really is desirable. As the code is right now, I wonder if >>> you couldn't make this a 2-line change, ... >>> >>>> @@ -204,10 +205,12 @@ void do_trap(struct cpu_user_regs *cpu_regs) >>>> break; >>> ... using return here and ... >>> >>>> default: >>>> + intr_handled = false; >>>> break; >>>> } >>>> >>>> - break; >>>> + if ( intr_handled ) >>>> + break; >>> ... simply dropping this break altogether. >> Well, your change is better but it won't apply to my current code of do_trap(): >> .... >> default: >> if ( cause & CAUSE_IRQ_FLAG ) >> { >> /* Handle interrupt */ >> unsigned long icause = cause & ~CAUSE_IRQ_FLAG; >> bool intr_handled = true; >> >> switch ( icause ) >> { >> case IRQ_S_EXT: >> intc_handle_external_irqs(cpu_regs); >> break; >> ... >> default: >> intr_handled = false; >> break; >> } >> >> if ( intr_handled ) >> break; >> } >> >> do_unexpected_trap(cpu_regs); >> break; >> } >> >> if ( cpu_regs->hstatus & HSTATUS_SPV ) >> check_for_pcpu_work(); >> } >> >> So if to use return instead of break here, I will miss the call of check_for_pcpu_work() > Ah, I see. But how should I have known without the description saying anything > along these lines? Of course, without proper description it was impossible to understand that. > Acked-by: Jan Beulich Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Thu Jan 29 22:06:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 22:06:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217037.1526866 (Exim 4.92) (envelope-from ) id 1vla9V-0008J3-4c; Thu, 29 Jan 2026 22:06:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217037.1526866; Thu, 29 Jan 2026 22:06: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 1vla9V-0008Iw-21; Thu, 29 Jan 2026 22:06:13 +0000 Received: by outflank-mailman (input) for mailman id 1217037; Thu, 29 Jan 2026 22: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 1vla9T-0008Iq-5X for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 22:06:11 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b6cd97b3-fd5e-11f0-b160-2bf370ae4941; Thu, 29 Jan 2026 23:06:09 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id A2EAC6001A; Thu, 29 Jan 2026 22:06:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0672EC4CEF7; Thu, 29 Jan 2026 22:06: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: b6cd97b3-fd5e-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769724367; bh=zPcvXu5VCYMukLaN255k/MTEnsytblLlj+oHAvHnX7g=; h=Date:From:To:cc:Subject:From; b=bhlJaGDfsxtsGJJu+IAA2VQXRjl3vZkr13Rby2K90GBWT7s6aYzEy6ZqIF2z4nMD/ OBnSqcdff2jVuY+WMbN0oji2H7jUUN9lE/0sCG/v7DHDi9KTSBNISyarpj7c44AmLo bgi7GAFwjyH+ICY1VGEq3XlH0N10+FH2syReW4g5PV1Vne7jI55ucL4Is8fEkIJnPe C6g2lINfYQjLDemNYQlEqaboi9SFPx4HRfTJYXpSjefg4ETNzjh9/0j+nV+Up+IyNC CVtfoQedbTdxDmoYpPP9+Jwa2fXRLbuOUj6W9vZX4VdFSjniJfNmIaPFnfL6gbp602 cisR8GyzkVrMw== Date: Thu, 29 Jan 2026 14:06:04 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: xen-devel@lists.xenproject.org cc: grygorii_strashko@epam.com, Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Victor Lira , andrew.cooper3@citrix.com, jbeulich@suse.com, sstabellini@kernel.org Subject: [PATCH v8 0/2] xen: console_io for dom0less guests Message-ID: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Hi all, This short patch series enable the usage of console_io hypercalls for dom0less guests. Cheers, Stefano From xen-devel-bounces@lists.xenproject.org Thu Jan 29 22:09:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 22:09:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217047.1526876 (Exim 4.92) (envelope-from ) id 1vlaCP-0000SZ-Hy; Thu, 29 Jan 2026 22:09:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217047.1526876; Thu, 29 Jan 2026 22: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 1vlaCP-0000SS-FP; Thu, 29 Jan 2026 22:09:13 +0000 Received: by outflank-mailman (input) for mailman id 1217047; Thu, 29 Jan 2026 22: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 1vlaCO-0000SM-VO for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 22:09:13 +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 236bd160-fd5f-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 23:09:10 +0100 (CET) Received: from BYAPR08CA0057.namprd08.prod.outlook.com (2603:10b6:a03:117::34) by IA0PR12MB8837.namprd12.prod.outlook.com (2603:10b6:208:491::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Thu, 29 Jan 2026 22:09:04 +0000 Received: from SJ5PEPF000001CB.namprd05.prod.outlook.com (2603:10b6:a03:117:cafe::37) by BYAPR08CA0057.outlook.office365.com (2603:10b6:a03:117::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.8 via Frontend Transport; Thu, 29 Jan 2026 22:09:04 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by SJ5PEPF000001CB.mail.protection.outlook.com (10.167.242.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Thu, 29 Jan 2026 22:09:03 +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, 29 Jan 2026 16:09:02 -0600 Received: from SATLEXMB03.amd.com (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Thu, 29 Jan 2026 16:09:01 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 236bd160-fd5f-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JD2c9eo7wUG/bFMa9k7TZ3gN+nNe5BXSLgKnswbbXaLXRRMALfCIvuSEx3cqsc7y8T4IQaCtx56ZIOSBiynA8Rui0J5d8z3yftm8MqwZIC57b9QSYaVA0R1V74IchqK2Cb5Y3SdJ81Mof4Wrw5RzGJcC969yeP0pKf7MXUABFW01O70A57Whmbp9jFAAh3J5ySTulxSG4nIPvzm+OEIn3T8uOCaDf8sB3VPR1r9VCgw+mYHwwsB/DzOfxdXwRg9reCFHx4VKDz7raotL2Rr9erOSoJV3w/A3ufGbqEK2IuR+qN/lYfz6xnIp2dfBXSX69AjI+aVkGS1faNHusAUW0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yhb/Ct6/30TNWJ4dGiIhm+GmR7yGbSpklZW15TSwm7s=; b=iaCv0X5WuagjICWfF0z3kGoymyg8lyTzGmaAArbguzQmf3S4+1kjH/LVGQUD49FFcQuW1d3mOzazzyMiySVNFF5PbRYCpJEUYd6FQT818h1LgPoTaooUH9E05nVYVRUHzTYiFpNaxYbXlpnkJwmpggb4gtyZElWwdw1f8zedvfwWIP8N6mf0VVEw0OjKVtdNWSQ7rhY4TSV6jBjNwJmCgyBSmcdN1ZD+F8E7n2ojb5CTqAgUTPa01K2Rn816KVz7VnVFZpKQi9jYlvaMc5hYAHHefQnPBiLn9xuaYHT2Gozz7JmmESFwrJBtRwHKJmJjsDOsUfD+0jwadkXlJHX0OA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yhb/Ct6/30TNWJ4dGiIhm+GmR7yGbSpklZW15TSwm7s=; b=2VJ2sCvlwKOtYFF+8ikXMsgQY2dJ+8/ae/F3b6l+e1hQloymvMegReRorV7ZryT8nypmR0cV+g+LsnNua/yNs9TmskJT4pNeebnb1BDTMpow2lEbxpM6Iy8fe2l+wxunsogZYaB2WG5YGTp4d3JrrEBEBPdGuYOjXQYoAsaC86c= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: Stefano Stabellini To: CC: , , , , , , , , , , Stefano Stabellini Subject: [PATCH v8 2/2] xen: enable dom0less guests to use console_io hypercalls Date: Thu, 29 Jan 2026 14:08:58 -0800 Message-ID: <20260129220858.2371938-2-stefano.stabellini@amd.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001CB:EE_|IA0PR12MB8837:EE_ X-MS-Office365-Filtering-Correlation-Id: 77d9e8b7-bc38-41e2-0b1e-08de5f83039e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?8GuEIkv/50CcJRiNR+c9nq4ubbVQGYk+zllYU228ZKO+UIff1VVr6ypd47bt?= =?us-ascii?Q?lWBx0vBXXttWtFnZYcK+4EhjEEz1RvVDoYz2LI3869CiMlCdIlCGK+xUJ4Qr?= =?us-ascii?Q?D1sIJgNfnSuiFhZkm5GKou2rpstqwbOH9YSXeHg8fF11m0sY5yhRqbPZ80d2?= =?us-ascii?Q?EGdNKEoGcRL+kARnZPTb1TB3z5lPM/6ko+n7lSBMruZxtK+O4G6EhXtvfvem?= =?us-ascii?Q?8mKm1DfMIhjoXEqa9EKo126gniOV+9Adluu/CxjpOfGre/JZ9uxKJDoUuBdj?= =?us-ascii?Q?EbzWLNbj6cvsQOz9V3SpIwdjkbMkv5y6gI+8hegytTTAcLwwneVQGglMTZpo?= =?us-ascii?Q?iPBTk/5Zq7RwIefQGqj7MgE/95TjcIMJfJmQcG/fOK6FkwatJgo54cxu0NcZ?= =?us-ascii?Q?qai8EsQCKtb7+n6EnktQNo/W/HGf+XsHpoMA69k5gZwyVJ3MHwR7iUBKwHW2?= =?us-ascii?Q?BAU8kHBZH5BgrK9kdnpFb4gVOR+9ZgHyeR5M/83HKtl0WRCU17F7AY3FudkV?= =?us-ascii?Q?QXpWI3jutByJAOAE7zzszw0XOKxwnokhCsWhkN1oW9rMDGcA9IAJ+R1TX8pL?= =?us-ascii?Q?wTcVkHugtU6mspD3DmXVVdW8cH0H+rfqsXcVEgx7eEaY7qtlydQ3HCqYsU0A?= =?us-ascii?Q?dvQkTBvaKdEN/EJDTl2E0I4vYYjpM73C5g32wPnkNz1rHtqGqr5WPkeSn2JZ?= =?us-ascii?Q?h36H1HLDtgLbzij8QHsd287L13ST0q0jNksQtEngjb2q3uPQnGZ0mhfLiiYE?= =?us-ascii?Q?jyt3T3PoD5S9BQF9Ve2Zp+ayMtB2PDxBCH/9++MsNhibDBGn0Z2+JrT1vrFF?= =?us-ascii?Q?tpA4mbFMbPGQIAvg4mUbStXM0WD9wg7OYWpnPKH5Gjl5qjw+ePo9ygGu+Xun?= =?us-ascii?Q?R+wnwF/h3FUGFJsRuWlHRFgcA2myDXVc3QWN9Ihxo0zG7JxuBBSFyBPzUyNX?= =?us-ascii?Q?Rhi3Axql374xUHg7asf+av6O6I1tUhkDZ3UuSvQ/Kd/JrvNsC4ufwfO3XTWG?= =?us-ascii?Q?4AOwc0asevX1GHsx7ch64If0ctbInDthPTqLhpdjAFtfhMF9pQkhUYfJkafK?= =?us-ascii?Q?fiy/VsscrY552gZjTTYCUG5c25akLezS0MJZik43T8N2CdRhf9kyB9CBQzGm?= =?us-ascii?Q?vBMGSfqcrWfOMg3JxujPSrlCzaez60nUTAxZsiNh3B2/GglTGzBAgPOLvWZP?= =?us-ascii?Q?znOGV8lqZv0s8FEcfm3YH4z9LPaIsN8jXT6xnz9mFMql9i/4zQyfogkMLcVT?= =?us-ascii?Q?VBKJy1cQGeWVFtO16UIoWRv02UW3LR1RjoArDNz0RUsvLTCNff5nCdlkYAx9?= =?us-ascii?Q?FNHJjedumcXMOq+Kfr+WcUzLMZEHQGeYPyu6MIqmRU1eeyvFLo2wmWaKFOK7?= =?us-ascii?Q?dzsflDwEnQfOn+GHzL33FLaUuEX59G0YQltn3MpRJSJDKP3mfpLc6LzsWNcG?= =?us-ascii?Q?+ZMBqeNhUg/Qu7xmCoa6arsJ9s+YnAKJnDStm0KPnRfloh6uFRKvizoe+wwV?= =?us-ascii?Q?0E1wQsyrAdspMo7oE80OcgjzY+Qjvy5Qe4EESwv7+KpLJwzp3w2uPa8TVPJn?= =?us-ascii?Q?IK6/FYXbPMPVWYLB9WGQWEaW7Z1PXJcQmfVxmauoO5q4NWHym1OEPycB6nXN?= =?us-ascii?Q?M84fl6vKJcYy0qGZJ5nb42WNT8WIiMXrfF5vziRZd+4TrCeTfa0ciIrF+Z+c?= =?us-ascii?Q?tHSE/A=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: aCzSXLPfi2rCkiH+8Gk0o1CTwZusyrtjd07IVA88AlLfIl18pNP6EVn3OQNC7RLwEvLy+NO8SwBlBj5AxjiCPNCxOiQZNrWDUCb7fvX7W1xpJLlKizKu3HT4xk4PlVkayek97DDzQ8U4BJmM9b4boeYbYnOSNcRBOKXsFXYzo9SMKqQPvI5p2Ig/r87YaqKzCk72VIEeoQ8DQXEx3pdwA+tZPqGsJlbW5YOxurAIRsJwQuFQcY0+2OPM110S6Kr8X2GK+e2stXey6gK/s3yt3X7rX5ylOttfWcWue1lYqb20cnVzZbKnyBA/JpHv4vA/alnexmWfEnmrVsUkCwIyyT1cfMcBFC10YKHB6k32VDRHKZpOeHydrabMRkBhqmj5V36t6e1jlyA/UPhki7vSxF6SluvhHCZGd9ckYmBggN+jq8quH8ikhs7xfFk2NMFH X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2026 22:09:03.7758 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 77d9e8b7-bc38-41e2-0b1e-08de5f83039e X-MS-Exchange-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: SJ5PEPF000001CB.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8837 Enable dom0less guests on ARM to use console_io hypercalls: - set input_allow = true for dom0less domains - update the in-code comment in console.c - prioritize the VUART check to retain the same behavior as today Signed-off-by: Stefano Stabellini --- Changes in v8: - move in-code comment update to previous patch - add in-code comment about is_focus_domain() check --- xen/common/device-tree/dom0less-build.c | 2 ++ xen/drivers/char/console.c | 16 ++++++++++------ 2 files changed, 12 insertions(+), 6 deletions(-) diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c index 840d14419d..cb7026fa7e 100644 --- a/xen/common/device-tree/dom0less-build.c +++ b/xen/common/device-tree/dom0less-build.c @@ -829,6 +829,8 @@ static int __init construct_domU(struct kernel_info *kinfo, rangeset_destroy(kinfo->xen_reg_assigned); + d->console->input_allowed = true; + return rc; } diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index ed8f1ad8f2..418d194cef 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -613,11 +613,20 @@ static void __serial_rx(char c) if ( console_rx == 0 ) return handle_keypress(c, false); + /* Includes an is_focus_domain() check. */ d = console_get_domain(); if ( !d ) return; - if ( is_hardware_domain(d) ) +#ifdef CONFIG_SBSA_VUART_CONSOLE + /* Prioritize vpl011 if enabled for this domain */ + if ( d->arch.vpl011.base_addr ) + { + /* Deliver input to the emulated UART. */ + rc = vpl011_rx_char_xen(d, c); + } + else +#endif { unsigned long flags; @@ -636,11 +645,6 @@ static void __serial_rx(char c) */ send_global_virq(VIRQ_CONSOLE); } -#ifdef CONFIG_SBSA_VUART_CONSOLE - else - /* Deliver input to the emulated UART. */ - rc = vpl011_rx_char_xen(d, c); -#endif if ( consoled_is_enabled() ) /* Deliver input to the PV shim console. */ -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Jan 29 22:09:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 22:09:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217050.1526887 (Exim 4.92) (envelope-from ) id 1vlaCb-0000kl-SZ; Thu, 29 Jan 2026 22:09:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217050.1526887; Thu, 29 Jan 2026 22: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 1vlaCb-0000kb-Pc; Thu, 29 Jan 2026 22:09:25 +0000 Received: by outflank-mailman (input) for mailman id 1217050; Thu, 29 Jan 2026 22:09:24 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlaCa-0000SM-PU for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 22:09:24 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 21b63017-fd5f-11f0-9ccf-f158ae23cfc8; Thu, 29 Jan 2026 23:09:08 +0100 (CET) Received: from SJ0PR05CA0177.namprd05.prod.outlook.com (2603:10b6:a03:339::32) by SN7PR12MB8102.namprd12.prod.outlook.com (2603:10b6:806:359::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Thu, 29 Jan 2026 22:09:02 +0000 Received: from SJ5PEPF000001C9.namprd05.prod.outlook.com (2603:10b6:a03:339:cafe::d7) by SJ0PR05CA0177.outlook.office365.com (2603:10b6:a03:339::32) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.7 via Frontend Transport; Thu, 29 Jan 2026 22:09:02 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by SJ5PEPF000001C9.mail.protection.outlook.com (10.167.242.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Thu, 29 Jan 2026 22:09:01 +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, 29 Jan 2026 16:09:01 -0600 Received: from SATLEXMB03.amd.com (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Thu, 29 Jan 2026 16:09:00 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 21b63017-fd5f-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JBZUjU7NcQmdJuW9xjC8p2MAkJnO9OUbxArlNnOEO2/aOrnO0Au+rCwzLl42qiJiS6DcQvZOg02wqQ1oAeuPigtsNetI8VIyLxhOiigBqrIbo8TAmAukWzYzg/65qEP7UMKhxoURk65DJHrVpgvkBVU3zV5tgZh+sw/nvjehXcDIOD4gtVoPQqGdmF7SMVR5HJr6AbxhM3NVngKf0DYj2MHDtDq4FKNsqScPb7uSjEkRy76zJhhvK1feAGPJ5qUDJ7ZNXRjzmwak63bCTxLSQI5L6W+fFb2UPQvygZeTHD3XnBhTo5ldrF8botg9iEY5A3opWwiNVI3JtrLT1yXwcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gvd6fc7XOc0NaN65HjV2UWYq1G1YeJLe/XO2kD7iR+s=; b=WKV+tL8MbSV0KVMZqo2GrJGcC3ujSfqDb/nVismsOdbYTxCBdWa92SpB/jPJA62yy3bLko4abxqmqEnH997EdjpoxuQQOUQo0lPqE6fpLhju3Uvj24c3g9n08m0tY6e9/H+zlBNG2TpB5g8ZPOoQWg/wzYII7g9G0cT0KKsjEavGHTEGLfwr5VYd7SL0tM/8mlDQTCfRf+fwCIDPpYqp6Lr6GPcggTsEEMU6a0zshTTNmdSCPHk3NOrzUqSmlCbONn1jlLl8uG8S/kR5KbXJ4JoQ9Q/+mEHlnUNCESczWrcUQOJzo191ONOQOy/+zYT4IYsd+2MjIBo/w7Q8JbjLfg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gvd6fc7XOc0NaN65HjV2UWYq1G1YeJLe/XO2kD7iR+s=; b=aHhV9XxHugevQJgch6vjzsNdA9y989QWROJs6fAbPS2HcnOr6zXe38FRxdqn7SxBtp04wM1bgh9E4CifnnYJb3398rWPkz+ziuJrhV4e+uAT1P1aMbsv/mp+1aCSoyWf5aOW2RqPVnwdTItGJzoioZiogVRwOlyH4N5le9YyzEc= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: Stefano Stabellini To: CC: , , , , , , , , , , Stefano Stabellini Subject: [PATCH v8 1/2] xen/console: handle multiple domains using console_io hypercalls Date: Thu, 29 Jan 2026 14:08:57 -0800 Message-ID: <20260129220858.2371938-1-stefano.stabellini@amd.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001C9:EE_|SN7PR12MB8102:EE_ X-MS-Office365-Filtering-Correlation-Id: 632e1726-8f5c-45da-7a4c-08de5f83025d 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?gQ6dffjK5xbhTSuOk3uKPvw61+SKt+GU2sf2L6+yDek/6+3NaS3LtwDEjbMK?= =?us-ascii?Q?ZuuLpWZzvvCwRv1uZqeHR0TpFmvhFO/ORxsIpXCx9HgbwkEdSuG4nuODViP5?= =?us-ascii?Q?pKMkfm9kb/UG+eD53xZ3ALLcR4wk4lqQQcaigSzZPt3nmbDZKCYPgc7HP0C3?= =?us-ascii?Q?ioD46ClZtfm0HUTokFobZpzOWXijgDsej/eQ4e+RqtaISoAbEh0Z/bTC+I1z?= =?us-ascii?Q?IZsBai81vPSbNYCBctTzN34y+dBrOkBqNmHP4+jnyYhBK4lMGPblqfrGIKTn?= =?us-ascii?Q?1HmgdFL3w/bk1vh1zl9rPtNZT2tCJYuVnRtYwyQMHqj9Hgu8CKb63CuSSI/t?= =?us-ascii?Q?80PmcOmu2vKDsB3VoZEPy7Ofxjk7POuv4KD4ICgf4kHec9x7qDBjKBjXQUdF?= =?us-ascii?Q?+Yxse6SPXyfWZd123purHtZhC3JrN9i6aiQW2iAyjK/3BwXTkze+yH6dmVXe?= =?us-ascii?Q?yDbGE4QJ9liSAyOvxNYqpFupYNQPC9e/f2ESxNOAxCbu9zej5K6McUXitkzg?= =?us-ascii?Q?w/Oq7qCMLm9n7M3rDiGeD+Ip7l2idr5qShyTfqfa8GN7HzrkDGagGE8mKYXa?= =?us-ascii?Q?m4zKvkhlmcYZ/S7bnABQi65z02LXxar07Yza5hY738/vwwJ5COt8xS6+1g6D?= =?us-ascii?Q?3/t1gSKCQImlihjxhB8veIGZw/P5RTfd2D3yt6vfNHdf3Nh2OVyCu3CJyJAq?= =?us-ascii?Q?cIwGSTUXMXpKUWLoLyJgABnebnjncr1bMJthnZAsXgPhvO9ocOFVDXUMsihu?= =?us-ascii?Q?/p6njYxbfy1FuMVMy91TzuSqjpPPUNwDb7klqUbDzauYaoXH9uFdbIjyxGdF?= =?us-ascii?Q?ICpoVXSAgRkGuJHPwz+3NLz/9wQ2UnIxvJ+6DHh4AzJsquxi5jkdD/eqgzPZ?= =?us-ascii?Q?thSEdDzBGYYW7NNEGH9VcadxNo8COzaQ8zGMD9TaJ6FMgU+eJiSJjU5jQGX5?= =?us-ascii?Q?FnZ69wxKnOPhac7SAUPxxSW1e7jrlw8GRtGGhZuUOw7C7V3HX3oscXUgaUrf?= =?us-ascii?Q?T+HDAZ+2jXBAQZsCGD6CvIYCl9J1asUmVkB1SiiwPj+kaZrdSzHQNIFTN1XJ?= =?us-ascii?Q?v93+oHrCyZTQj0ZmsDLHW+c0+HZ63fU5dutngRMTltGQ4FebNHhFfUmOjqcE?= =?us-ascii?Q?3GGjR0lEw2v0mMjEzoS8m48Vg9o11hK0+7WaKaZKl+POR0V7rt/uRT+2Uc33?= =?us-ascii?Q?qbOYn325bFPTVgmlghdzfsbAuKf1MM+ITVNlyoBhLUY6WRy1kTy4rMJa6bpQ?= =?us-ascii?Q?AbEg6bGJ9I7pcXVcP4vuKHHo+hqCB0zazeXPl1IG20QexdHgIdCGRfcrVQAe?= =?us-ascii?Q?+bSqfUgD4PzdVBKEBgmpZkFKPhmlTLsyqMk7fYUC5EOb6yZFJ2Vi5CSX3rmJ?= =?us-ascii?Q?kStCU56Al9lEQywKkWwjrzUjjjJ0d92wm2qwbm1qxORbR/fOYiWaAmYq6Bml?= =?us-ascii?Q?uadMiYIcPrfrvIRCuWXBnEoqDKAGHGrgZlAsgJnuWgkrKQHCpXDertJlqCIG?= =?us-ascii?Q?cW+hPOlyDibQKZn8qSeji4uUZhe1LOtdWPk24NewJiYdIE3vWimbQ7Vm6p48?= =?us-ascii?Q?tW298sD/B+7ijoVW9a4nKTiR7eNAfTjOQfJXnJ04GGHsfNxLwdpmJbSBSTbb?= =?us-ascii?Q?UqoqzibVFHnZElyqrYjsATJUYGPzo1oCg+b1EdmpGECf2P6QTEWTS7WANe71?= =?us-ascii?Q?V3gRhQ=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(82310400026)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: eibUuI4xyHBdsXUxvgtHd9tUBaMn5NB2JuyKPAZH8Y2RWujDPFXTCf01XM1wtaWKuQPGURdLSGfsB09v4hn28tmevPNoM4WilR4uauZCrbxe0LUQVGkQHg9MMQ1dDEpJL52mJ+YwZU+33qRj7mpWNNZTbQVgeTdjCS1eEr0ueGWRQJOtHrb7aEzhbxXdGB9XP4bYaLU0pnucbk0udC92VjFPRmDYawOvv7+mzYtyKSfT259kRt3zzeIx0teWhIVepoD5lbZTA+ii/rrHzTSIsVqZeUb34veqj9QA+TDDxGAiJPbeySeWh4JPzjAvAbpPew6baG662g3bOUk3x1QxKK6b7OIP2ylazdfzZlUZRyxp1afpXO6mD3byrgv0WAjPT7mALlUNmTU81cAG/QQc6ULqfm/qRLiRtr7y6FNxpbRQOAQFCwkqeFq9y70uZWe4 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2026 22:09:01.7433 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 632e1726-8f5c-45da-7a4c-08de5f83025d X-MS-Exchange-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: SJ5PEPF000001C9.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8102 Allow multiple dom0less domains to use the console_io hypercalls to print to the console. Handle them in a similar way to vpl011: only the domain which has focus can read from the console. All domains can write to the console but the ones without focus have a prefix. In this case the prefix is applied by using guest_printk instead of printk or console_puts which is what the original code was already doing. When switching focus using Ctrl-AAA, discard any unread data in the input buffer. Input is read quickly and the user would be aware of it being slow or stuck as they use Ctrl-AAA to switch focus domain. In that situation, it is to be expected that the unread input is lost. The domain writes are buffered when the domain is not in focus. Push out the buffer after the domain enters focus on the first guest write. Locking updates: - Guard every mutation of serial_rx_cons/prod with console_lock and discard unread input under the lock when switching focus (including when returning to Xen) so that cross-domain reads can't see stale data - Require is_focus_domain() callers to hold console_lock, and take that lock around the entire CONSOLEIO_read loop, re-checking focus after each chunk so a focus change simply stops further copies without duplicating or leaking input - Hold cons->lock while flushing buffered writes in the focus path so the direct-write fast path does not race buffered guests or HVM debug output Signed-off-by: Stefano Stabellini --- Changes in v8: - protect console_rx read - move printk() to last - update "Deliver input..." comment - in __serial_rx() use nrspin_lock_irqsave - in do_console_io() use count = 0 to skip the loop - in do_console_io() move nrspin_unlock_irq up a few lines - append () to function names in in-code comments --- xen/drivers/char/console.c | 80 ++++++++++++++++++++++++++++++++------ 1 file changed, 69 insertions(+), 11 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 2bdb4d5fb4..ed8f1ad8f2 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -518,11 +518,16 @@ static unsigned int __read_mostly console_rx = 0; struct domain *console_get_domain(void) { struct domain *d; + unsigned int rx; - if ( console_rx == 0 ) + nrspin_lock(&console_lock); + rx = console_rx; + nrspin_unlock(&console_lock); + + if ( rx == 0 ) return NULL; - d = rcu_lock_domain_by_id(console_rx - 1); + d = rcu_lock_domain_by_id(rx - 1); if ( !d ) return NULL; @@ -540,6 +545,12 @@ void console_put_domain(struct domain *d) rcu_unlock_domain(d); } +static bool is_focus_domain(const struct domain *d) +{ + ASSERT(rspin_is_locked(&console_lock)); + return d != NULL && d->domain_id == console_rx - 1; +} + static void console_switch_input(void) { unsigned int next_rx = console_rx; @@ -555,7 +566,10 @@ static void console_switch_input(void) if ( next_rx++ >= max_console_rx ) { + nrspin_lock_irq(&console_lock); console_rx = 0; + serial_rx_cons = serial_rx_prod; + nrspin_unlock_irq(&console_lock); printk("*** Serial input to Xen"); break; } @@ -575,7 +589,11 @@ static void console_switch_input(void) rcu_unlock_domain(d); + nrspin_lock_irq(&console_lock); console_rx = next_rx; + /* Don't let the next dom read the previous dom's unread data. */ + serial_rx_cons = serial_rx_prod; + nrspin_unlock_irq(&console_lock); printk("*** Serial input to DOM%u", domid); break; } @@ -601,12 +619,16 @@ static void __serial_rx(char c) if ( is_hardware_domain(d) ) { + unsigned long flags; + /* - * Deliver input to the hardware domain buffer, unless it is + * Deliver input to the focus domain buffer, unless it is * already full. */ + nrspin_lock_irqsave(&console_lock, flags); if ( (serial_rx_prod - serial_rx_cons) != SERIAL_RX_SIZE ) serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c; + nrspin_unlock_irqrestore(&console_lock, flags); /* * Always notify the hardware domain: prevents receive path from @@ -730,6 +752,7 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, unsigned int flags = opt_console_to_ring ? CONSOLE_ALL : CONSOLE_DEFAULT; struct domain *cd = current->domain; + struct domain_console *cons = cd->console; while ( count > 0 ) { @@ -742,17 +765,36 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, if ( copy_from_guest(kbuf, buffer, kcount) ) return -EFAULT; - if ( is_hardware_domain(cd) ) + /* + * Take both cons->lock and console_lock: + * - cons->lock protects cons->buf and cons->idx + * - console_lock protects console_send() and is_focus_domain() + * checks + * + * The order must be respected. guest_printk() takes the + * console_lock so it is important that cons->lock is taken + * first. + */ + spin_lock(&cons->lock); + nrspin_lock_irq(&console_lock); + if ( is_focus_domain(cd) ) { + if ( cons->idx ) + { + console_send(cons->buf, cons->idx, flags); + cons->idx = 0; + } + spin_unlock(&cons->lock); + /* Use direct console output as it could be interactive */ - nrspin_lock_irq(&console_lock); console_send(kbuf, kcount, flags); nrspin_unlock_irq(&console_lock); } else { char *kin = kbuf, *kout = kbuf, c; - struct domain_console *cons = cd->console; + + nrspin_unlock_irq(&console_lock); /* Strip non-printable characters */ do @@ -765,7 +807,6 @@ static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, } while ( --kcount > 0 ); *kout = '\0'; - spin_lock(&cons->lock); kcount = kin - kbuf; if ( c != '\n' && (cons->idx + (kout - kbuf) < (ARRAY_SIZE(cons->buf) - 1)) ) @@ -816,22 +857,39 @@ long do_console_io( break; rc = 0; + nrspin_lock_irq(&console_lock); + if ( !is_focus_domain(current->domain) ) + count = 0; while ( (serial_rx_cons != serial_rx_prod) && (rc < count) ) { idx = SERIAL_RX_MASK(serial_rx_cons); len = serial_rx_prod - serial_rx_cons; + nrspin_unlock_irq(&console_lock); if ( (idx + len) > SERIAL_RX_SIZE ) len = SERIAL_RX_SIZE - idx; if ( (rc + len) > count ) len = count - rc; if ( copy_to_guest_offset(buffer, rc, &serial_rx_ring[idx], len) ) - { - rc = -EFAULT; - break; - } + return -EFAULT; rc += len; + + /* + * First get console_lock again, then check is_focus_domain(). + * It is possible that we switched focus domain during + * copy_to_guest_offset(). In that case, serial_rx_cons and + * serial_rx_prod have been reset so it would be wrong to + * update serial_rx_cons here. Get out of the loop instead. + * + * rc is updated regardless to provide the correct return + * value to the VM as the data has been copied. + */ + nrspin_lock_irq(&console_lock); + if ( !is_focus_domain(current->domain) ) + break; + serial_rx_cons += len; } + nrspin_unlock_irq(&console_lock); break; default: rc = -ENOSYS; -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Jan 29 23:04:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 23:04:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217075.1526897 (Exim 4.92) (envelope-from ) id 1vlb3R-0008HD-P1; Thu, 29 Jan 2026 23:04:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217075.1526897; Thu, 29 Jan 2026 23:04: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 1vlb3R-0008H6-Lg; Thu, 29 Jan 2026 23:04:01 +0000 Received: by outflank-mailman (input) for mailman id 1217075; Thu, 29 Jan 2026 23:04: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 1vlb3Q-0008H0-Jl for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 23:04:00 +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 cb0e0b27-fd66-11f0-b160-2bf370ae4941; Fri, 30 Jan 2026 00:03:58 +0100 (CET) Received: from BN9PR03CA0952.namprd03.prod.outlook.com (2603:10b6:408:108::27) 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.9564.7; Thu, 29 Jan 2026 23:03:51 +0000 Received: from BN1PEPF00004685.namprd03.prod.outlook.com (2603:10b6:408:108:cafe::d9) by BN9PR03CA0952.outlook.office365.com (2603:10b6:408:108::27) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9542.16 via Frontend Transport; Thu, 29 Jan 2026 23:03:34 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN1PEPF00004685.mail.protection.outlook.com (10.167.243.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Thu, 29 Jan 2026 23:03:50 +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; Thu, 29 Jan 2026 17:03:50 -0600 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb09.amd.com (10.181.42.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 29 Jan 2026 15:03:50 -0800 Received: from SATLEXMB03.amd.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Thu, 29 Jan 2026 15:03:50 -0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cb0e0b27-fd66-11f0-b160-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xEyHoZuNuLqfs3aJcNDewhXFvdanpNKFhcfKh2ff8AZt+UKw0KnERrpcIPdc+WmmXucTdrReyvhfxe6cFPF+LFZlR9P2GiBj5BjJYhHAV8LdZo85Oa8ZKiUWHt4EaBk5osBG+PhE+0sKz+QL1nCEMeIP5bA9lmBoD16y8PhtOLUc/37J9R6C0vvKFRsEc31Vnt/1C9iZq42RZKH/1F6dvDqfVyMViR1H5aQTZ2LvYsnHlgR4ySq+yq/A2L6zIiPftoFKEGw2wqt6xwfmuRQeRMWgj4Ci8vTaF7TvQvR3lg8tesHikM4HB3VQeQXkoI11xadh8pF2T8vwuNzvtihclg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Rc/3iRD0JqFXqIjo/xG/IZyeLwM/HjQ1QMov9Grx2n8=; b=Q+63x/e7s1QoLtDyfwMo7kSOJ13HAELPrCNTuM9ehH0v49rJrIwKKZX/piNHa87P64Rum1MXtlxShGSauLS4TOqyERM2vG9UwRIqLE2bLLJ3GITbLScBli063zdefoSTkSLastDrNDf9kpVW0dkZWjPe9IyTgcA3Gk5Kgr95yvgCCdsxDHSjo90PuYne6cHV1+W98vUnkTUT/K1UzgpYkZQx/cSP6qoIWIbzQmc8NQAezdEz3v0vRRD5SiwbZ23Uu/ORwbBUcT9sDSBEJUcOUQUyYHrbDOe1mxj+kkBxM4Ngzt8B0kPbe8A4zJgsBjLvtj4AacALc5UrLsv4p7062g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rc/3iRD0JqFXqIjo/xG/IZyeLwM/HjQ1QMov9Grx2n8=; b=0yhX5u3st8C9DIaNFX635jNbOzGmr5DKtlbdWvFk6Y71WvPs7kTQyYs5NyXYbmELcZeSTuAXOrBX6ZWC2ELGuNtHaRX0rZMOFZodkON65zlbVQmpiRfm2tMqN6Dp7Xd8HYvg43DwqG2Fok2yYqdfJVG9ZCGY/mxXyaoixA6cNl0= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: Stefano Stabellini To: CC: , , , , , , , Stefano Stabellini Subject: [PATCH v2] 9p/xen: protect xen_9pfs_front_free against concurrent calls Date: Thu, 29 Jan 2026 15:03:48 -0800 Message-ID: <20260129230348.2390470-1-stefano.stabellini@amd.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1PEPF00004685:EE_|SA3PR12MB7976:EE_ X-MS-Office365-Filtering-Correlation-Id: cfb85172-49e5-4457-6db3-08de5f8aaae2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700013|1800799024|82310400026; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?g+QUrCUF3Zqorx7xMLo9LenwN+sTfaAr2Hdp2y246LyaQGx1XhBgAXyxQf+t?= =?us-ascii?Q?0/C7f/RQOGiKqgObB2Nc/18vaB39JIpJkjmFD6DATvtYdtHUzYWBttxc+QZo?= =?us-ascii?Q?zHvjz2CFkApHe3zA8YX/15v+0osi4uexxWT8oKTNbmWlBd6RvZzGfUO2XEyt?= =?us-ascii?Q?pKaPaQuZvAGBHc76o0plGDlUZNsYNjwdvOGFUHMy5kv/IPDhw1lksB3x2geJ?= =?us-ascii?Q?Izr1DX8mRYf4hMuHPmvHIVclvC876POZvLi8DkznuuQCNRyORdxYewVSN/RD?= =?us-ascii?Q?qf6FJRRBViIDHeA8I1nrt5rz79eSngIl3Io+2gi87rXkcfjup8mP/ehMdII9?= =?us-ascii?Q?vMwAEWX4leM6JFmcvDwsA9zl1piVIGwzDqBHqZXrAo6UXunKm8z3OUBrZ11R?= =?us-ascii?Q?LpqcMOWydFmQuIq/2OI5sGzLakMHZbanevbgw02IzGTs1e3uKdGmms4FPpIV?= =?us-ascii?Q?h0tDmblOeIqYVA8mCW+scFHwNKhEim71HFpcYEMtvQsGz9CbFxCGEhvTRRUz?= =?us-ascii?Q?ZE1SyzMhSiX8spaEr0LaOI4tfCUcTw4Gi9RGvYbdYoQei2ug1mJ5WQbiuoAF?= =?us-ascii?Q?U31a/YqPY8LSyyMj49cKaI8tIx9/Y/SEq0nB6wG3GSzmpjsL+PIQA7WC/LHB?= =?us-ascii?Q?PJ68axgMBIuO0JAquos7hCyGIoRH8PEfc5I73roBluPotv/+R3/8AvXECYmg?= =?us-ascii?Q?/sM679lJWXQHPmN9yL3KzrbNJCyHE2UDPBvfD2jijeHA+kCR8c8vUOqeIKh2?= =?us-ascii?Q?XJv0VwtbMgJRUUJ7XAyvk+zvfGdwMZbPx+YVsv4Wd21EHrsiJZdHUhbx18US?= =?us-ascii?Q?pM8GUDVtZDEjneN8fcm5YlRuq317o6wsHpHsyqK8QmNgfp80xOqJsnMK5qIp?= =?us-ascii?Q?DPI9MSMr+3rPWP5jQ4ioj0+ziEI7TVMsB7jnnObgDhLnLa2Bpggi5IyJbJxe?= =?us-ascii?Q?3bEPb4cG2M4StQtv2g8Lx3qhXNNAKSmFHUfUYnvTJTX+LnvqB3YddNQigVTg?= =?us-ascii?Q?faDaBh1pzKCcOFy/NXaIvn0bNTWaN/QojtFcrVuaeVY04qH6YrmdmsufYXxm?= =?us-ascii?Q?BXte+DhyO8jM7AhHI5Bg5pVaZj88xfUrYMSp2kE5bif9AEHN9zCR9IuwP9TZ?= =?us-ascii?Q?2KVmCRUuWZ1VVaC8NEfam5Ox6kQhJRWS87n2CWpr7sZJ90nmT/UEVFfYedJN?= =?us-ascii?Q?HPWYyPvBG3B9qllWtBctUmTmyGtCnx2B9E+Pe+vTwON0lffbp1BSzY0mlF/W?= =?us-ascii?Q?w40Q/Lhf7tDcjIn1Y1Ku6E3sn+nTzLaw02Lb2fd70udrC8XdmZE07xy4b2e8?= =?us-ascii?Q?jNMTVNeQX0slca9ZJw4nAGwM67zQ9k7uqJ/fQM/RCnRYvkm/yYWQAJ/0AtrL?= =?us-ascii?Q?HqyXwiYRDileQnBs4dR/qm93PlgjDd2+52J3xYM9E+VhDrN8i1XCC+qBaAzx?= =?us-ascii?Q?zzg9jPVlB96qwOZmTscX05dHcaH/nK1AWJIshbvpkoQ2gziqCMevkwFe94ZP?= =?us-ascii?Q?vFX1OkrNyGv2k3Iidv697E05GcGXcNFfE6x9+k28RUlam2pWwkPbwhaEmpFo?= =?us-ascii?Q?ce2PgMR+uLyTHCOnco9cWMHml/7NyGmOl8UA3ylhAIm3pbpuN0LNlGWiibGt?= =?us-ascii?Q?DxQyCkLqdydhQb3b1MpTLj0bmdmqeuLluwtO1ENVPyb9zwkijveyHNKCG9gB?= =?us-ascii?Q?Hm2qTw=3D=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(376014)(36860700013)(1800799024)(82310400026);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: jnoSlLdE/HpUKS8u8czDDMIioILQtOUNPe75hjWI8kz7uPkbrjun6+bK00tSThV/rH6SRkXO48s2rsoM3FxD5bC7oJJuMmrIJii7ewhyEtuB1I1OUoxRGC9IwjgdnpGfu4Te5r2bfr+WwLDFoB7HhJt+b99xDsqvgvSegWlNftO4py7BzsuWLJfATsJfVe4uaSn3glQQYsuqHwpPdyfHy5b8cpS7MWjTiyOq1H9RUJaykVfBdgRfN33hRTQQ+C1ETIxvsBfxQpc5nxn97ZixRsKqPFo3qfeEh86iveQvbh/eQ/EhHUdcA8pwid1+SSzrD5vhWXnLt+FNHohgH7x3XY74sxikXfRht4tTSTNgWN4yJvbT9DJ9n7Ox//C4YDfK//fV6e7ZX6lxHtJ40tg5WRJN58twhXmH8+BWBhjCl4mV82YI9vq9K8061H3CF+G5 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2026 23:03:50.9854 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cfb85172-49e5-4457-6db3-08de5f8aaae2 X-MS-Exchange-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: BN1PEPF00004685.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB7976 The xenwatch thread can race with other back-end change notifications and call xen_9pfs_front_free() twice, hitting the observed general protection fault due to a double-free. Guard the teardown path so only one caller can release the front-end state at a time, preventing the crash. This is a fix for the following double-free: [ 27.052347] Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [ 27.052357] CPU: 0 UID: 0 PID: 32 Comm: xenwatch Not tainted 6.18.0-02087-g51ab33fc0a8b-dirty #60 PREEMPT(none) [ 27.052363] RIP: e030:xen_9pfs_front_free+0x1d/0x150 [ 27.052368] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 41 55 41 54 55 48 89 fd 48 c7 c7 48 d0 92 85 53 e8 cb cb 05 00 48 8b 45 08 48 8b 55 00 <48> 3b 28 0f 85 f9 28 35 fe 48 3b 6a 08 0f 85 ef 28 35 fe 48 89 42 [ 27.052377] RSP: e02b:ffffc9004016fdd0 EFLAGS: 00010246 [ 27.052381] RAX: 6b6b6b6b6b6b6b6b RBX: ffff88800d66e400 RCX: 0000000000000000 [ 27.052385] RDX: 6b6b6b6b6b6b6b6b RSI: 0000000000000000 RDI: 0000000000000000 [ 27.052389] RBP: ffff88800a887040 R08: 0000000000000000 R09: 0000000000000000 [ 27.052393] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888009e46b68 [ 27.052397] R13: 0000000000000200 R14: 0000000000000000 R15: ffff88800a887040 [ 27.052404] FS: 0000000000000000(0000) GS:ffff88808ca57000(0000) knlGS:0000000000000000 [ 27.052408] CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 27.052412] CR2: 00007f9714004360 CR3: 0000000004834000 CR4: 0000000000050660 [ 27.052418] Call Trace: [ 27.052420] [ 27.052422] xen_9pfs_front_changed+0x5d5/0x720 [ 27.052426] ? xenbus_otherend_changed+0x72/0x140 [ 27.052430] ? __pfx_xenwatch_thread+0x10/0x10 [ 27.052434] xenwatch_thread+0x94/0x1c0 [ 27.052438] ? __pfx_autoremove_wake_function+0x10/0x10 [ 27.052442] kthread+0xf8/0x240 [ 27.052445] ? __pfx_kthread+0x10/0x10 [ 27.052449] ? __pfx_kthread+0x10/0x10 [ 27.052452] ret_from_fork+0x16b/0x1a0 [ 27.052456] ? __pfx_kthread+0x10/0x10 [ 27.052459] ret_from_fork_asm+0x1a/0x30 [ 27.052463] [ 27.052465] Modules linked in: [ 27.052471] ---[ end trace 0000000000000000 ]--- Signed-off-by: Stefano Stabellini --- Changes in v2: - move priv->rings check above the loop - replace list_del_init with list_del --- net/9p/trans_xen.c | 85 ++++++++++++++++++++++++---------------------- 1 file changed, 44 insertions(+), 41 deletions(-) diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c index 12f752a923324..9bbfc20744f69 100644 --- a/net/9p/trans_xen.c +++ b/net/9p/trans_xen.c @@ -277,45 +277,52 @@ static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv) { int i, j; - write_lock(&xen_9pfs_lock); - list_del(&priv->list); - write_unlock(&xen_9pfs_lock); - - for (i = 0; i < XEN_9PFS_NUM_RINGS; i++) { - struct xen_9pfs_dataring *ring = &priv->rings[i]; - - cancel_work_sync(&ring->work); - - if (!priv->rings[i].intf) - break; - if (priv->rings[i].irq > 0) - unbind_from_irqhandler(priv->rings[i].irq, ring); - if (priv->rings[i].data.in) { - for (j = 0; - j < (1 << priv->rings[i].intf->ring_order); - j++) { - grant_ref_t ref; - - ref = priv->rings[i].intf->ref[j]; - gnttab_end_foreign_access(ref, NULL); - } - free_pages_exact(priv->rings[i].data.in, + if (priv->rings) { + for (i = 0; i < XEN_9PFS_NUM_RINGS; i++) { + struct xen_9pfs_dataring *ring = &priv->rings[i]; + + cancel_work_sync(&ring->work); + + if (!priv->rings[i].intf) + break; + if (priv->rings[i].irq > 0) + unbind_from_irqhandler(priv->rings[i].irq, ring); + if (priv->rings[i].data.in) { + for (j = 0; + j < (1 << priv->rings[i].intf->ring_order); + j++) { + grant_ref_t ref; + + ref = priv->rings[i].intf->ref[j]; + gnttab_end_foreign_access(ref, NULL); + } + free_pages_exact(priv->rings[i].data.in, 1UL << (priv->rings[i].intf->ring_order + XEN_PAGE_SHIFT)); + } + gnttab_end_foreign_access(priv->rings[i].ref, NULL); + free_page((unsigned long)priv->rings[i].intf); } - gnttab_end_foreign_access(priv->rings[i].ref, NULL); - free_page((unsigned long)priv->rings[i].intf); + kfree(priv->rings); } - kfree(priv->rings); kfree(priv->tag); kfree(priv); } static void xen_9pfs_front_remove(struct xenbus_device *dev) { - struct xen_9pfs_front_priv *priv = dev_get_drvdata(&dev->dev); + struct xen_9pfs_front_priv *priv; + write_lock(&xen_9pfs_lock); + priv = dev_get_drvdata(&dev->dev); + if (priv == NULL) { + write_unlock(&xen_9pfs_lock); + return; + } dev_set_drvdata(&dev->dev, NULL); + list_del(&priv->list); + write_unlock(&xen_9pfs_lock); + xen_9pfs_front_free(priv); } @@ -382,7 +389,7 @@ static int xen_9pfs_front_init(struct xenbus_device *dev) { int ret, i; struct xenbus_transaction xbt; - struct xen_9pfs_front_priv *priv = dev_get_drvdata(&dev->dev); + struct xen_9pfs_front_priv *priv; char *versions, *v; unsigned int max_rings, max_ring_order, len = 0; @@ -410,6 +417,10 @@ static int xen_9pfs_front_init(struct xenbus_device *dev) if (p9_xen_trans.maxsize > XEN_FLEX_RING_SIZE(max_ring_order)) p9_xen_trans.maxsize = XEN_FLEX_RING_SIZE(max_ring_order) / 2; + priv = kzalloc(sizeof(*priv), GFP_KERNEL); + if (!priv) + return -ENOMEM; + priv->dev = dev; priv->rings = kcalloc(XEN_9PFS_NUM_RINGS, sizeof(*priv->rings), GFP_KERNEL); if (!priv->rings) { @@ -468,6 +479,11 @@ static int xen_9pfs_front_init(struct xenbus_device *dev) goto error; } + write_lock(&xen_9pfs_lock); + dev_set_drvdata(&dev->dev, priv); + list_add_tail(&priv->list, &xen_9pfs_devs); + write_unlock(&xen_9pfs_lock); + xenbus_switch_state(dev, XenbusStateInitialised); return 0; @@ -482,19 +498,6 @@ static int xen_9pfs_front_init(struct xenbus_device *dev) static int xen_9pfs_front_probe(struct xenbus_device *dev, const struct xenbus_device_id *id) { - struct xen_9pfs_front_priv *priv = NULL; - - priv = kzalloc(sizeof(*priv), GFP_KERNEL); - if (!priv) - return -ENOMEM; - - priv->dev = dev; - dev_set_drvdata(&dev->dev, priv); - - write_lock(&xen_9pfs_lock); - list_add_tail(&priv->list, &xen_9pfs_devs); - write_unlock(&xen_9pfs_lock); - return 0; } -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Jan 29 23:15:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 23:15:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217086.1526906 (Exim 4.92) (envelope-from ) id 1vlbDq-0001X8-PG; Thu, 29 Jan 2026 23:14:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217086.1526906; Thu, 29 Jan 2026 23:14:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlbDq-0001X1-Md; Thu, 29 Jan 2026 23:14:46 +0000 Received: by outflank-mailman (input) for mailman id 1217086; Thu, 29 Jan 2026 23:14: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 1vlbDo-0001Wv-UY for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 23:14:44 +0000 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 49c48f32-fd68-11f0-9ccf-f158ae23cfc8; Fri, 30 Jan 2026 00:14:42 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id CC7B843B4B; Thu, 29 Jan 2026 23:14:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1DD25C4CEF7; Thu, 29 Jan 2026 23:14: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: 49c48f32-fd68-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769728479; bh=IMB7VcEJt6ShCjRGSVjQhf+3NOfNUF0WgNW1SVN78TU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=YE2wG8vGhqNyQfuQLo5f6BpdTUJtj9DE1my+eiwF87Owy/OelF3TvVLhDJgkFRyWe HkyxFrE52LpRkl22VdPwxdTFthAtG7OFnotuRXaSdz5SAEq+Kke9nMQcG0cwNVrSnu CZ872DPCpX4/GQYU8mWRbRt88zWPhLkN+n2bQ5x9/XGgmlbcixw8pThoAFHehuDGi7 tVuD5Zb1bbzzfghO+lgJ7aWSNf/9in1L9e/1srEBRaORq+deFpQLU9Eooc/qFCL45h W6C28UohhhEc8UtrQ+lY+ut5SRP7DDtox6/wMVanvecDasUShy4sQ6iBKdnBTEaeiN +kB2/tSSKbwEQ== Date: Thu, 29 Jan 2026 15:14:36 -0800 (PST) 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 v9 1/5] xen/domctl: chain SCI handling before IOMMU in assign_device domctl In-Reply-To: <69d32e2440b2ef194b4893e5dd29c2dd9d216a90.1769696107.git.oleksii_moisieiev@epam.com> Message-ID: References: <69d32e2440b2ef194b4893e5dd29c2dd9d216a90.1769696107.git.oleksii_moisieiev@epam.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-1779629773-1769728429=:2238666" Content-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1779629773-1769728429=:2238666 Content-Type: text/plain; CHARSET=UTF-8 Content-Transfer-Encoding: 8BIT Content-ID: On Thu, 29 Jan 2026, Oleksii Moisieiev wrote: > From: Grygorii Strashko > > Add chained handling of assigned DT devices to support access-controller > functionality through SCI framework, so a DT device assign request can be > passed to firmware for processing and enabling VM access to the requested > device (for example, device power management through SCMI). > > The SCI access-controller DT device processing is called before the IOMMU > path. It runs for any DT-described device (protected or not, and even when > the IOMMU is disabled). The IOMMU path remains unchanged for PCI devices; > only the DT path is relaxed to permit non-IOMMU devices. > > This lets xl.cfg:"dtdev" list both IOMMU-protected and non-protected DT > devices: > > dtdev = [ > "/soc/video@e6ef0000", <- IOMMU protected device > "/soc/i2c@e6508000", <- not IOMMU protected device > ] > > The change is done in two parts: > 1) call sci_do_domctl() in do_domctl() before IOMMU processing. If > sci_do_domctl() reports an error other than -ENXIO, treat it as > authoritative and skip the IOMMU path. A return of -ENXIO indicates > that SCI did not handle the request and is ignored, allowing the > existing IOMMU handling to run unchanged; > 2) update iommu_do_dt_domctl() to check for dt_device_is_protected() and > not fail if DT device is not protected by IOMMU. iommu_do_pci_domctl > doesn't need to be updated because iommu_do_domctl first tries > iommu_do_pci_domctl (when CONFIG_HAS_PCI) and falls back to > iommu_do_dt_domctl only if PCI returns -ENODEV. > > The new dt_device_is_protected() bypass in iommu_do_dt_domctl only > applies to DT-described devices; SCI parameters are carried via DT > nodes. PCI devices handled by iommu_do_pci_domctl do not carry DT/SCI > metadata in this path, so there is no notion of “SCI parameters on a > non-IOMMU-protected PCI device” for it to interpret or to skip. The PCI > path should continue to report errors if assignment cannot be performed > by the IOMMU layer. So we should leave iommu_do_pci_domctl unchanged; the > SCI/DT-specific relaxations belong only in the DT path. Also SCI handling > only exists when DT is present. > > Signed-off-by: Grygorii Strashko > Signed-off-by: Oleksii Moisieiev > --- > > Changes in v9: > - treat SCI as a gate for XEN_DOMCTL_*assign_device: abort before > IOMMU if sci_do_domctl() returns an error other than -ENXIO, instead > of trying to propagate SCI errors after a successful IOMMU > operation. This avoids partial success and the need for IOMMU rollback. > - remove early return from do_domctl() in the assign_device > path to keep RCU handling intact. > - change IS_ENABLED(*) to #ifdef in sci_do_domctl quard > > Changes in v8: > - check for CONFIG_ARM_SCI to be ebabled instead of COMFIG_ARM before > calling sci_do_domctl > - rework sci_do_domctl call to avoid extra checks, improved error > handling. > - do not propagate ret1 if sci_do_domctl returned positive ret > - updated comment in domctl.c code > > Changes in v7: > - update domctl to build on both Arm and x86 platforms > - move ret1 declaration to the top of the function as required by code > style > > Changes in v6: > - change iommu_do_domctl and sci_do_domctl command order and > call sci_do_domctl first which will produce cleaner code path. > Also dropped changing return code when iommu was disabled in > iommu_do_domctl. > > Changes in v5: > - return -EINVAL if mediator without assign_dt_device was provided > - invert return code check for iommu_do_domctl in > XEN_DOMCTL_assign_device domctl processing to make cleaner code > - change -ENOTSUPP error code to -ENXIO in sci_do_domctl > - handle -ENXIO return comde of iommu_do_domctl > - leave !dt_device_is_protected check in iommu_do_dt_domctl to make > code work the same way it's done in "handle_device" call while > creating hwdom(dom0) and "handle_passthrough_prop" call for dom0less > creation > - drop return check from sci_assign_dt_device call as not needed > - do not return EINVAL when addign_dt_device is not set. That is > because this callback is optional and not implemented in single-agent driver > > xen/arch/arm/firmware/sci.c | 36 +++++++++++++++++++++++++ > xen/arch/arm/include/asm/firmware/sci.h | 14 ++++++++++ > xen/common/domctl.c | 15 +++++++++++ > xen/drivers/passthrough/device_tree.c | 6 +++++ > 4 files changed, 71 insertions(+) > > diff --git a/xen/arch/arm/firmware/sci.c b/xen/arch/arm/firmware/sci.c > index aa93cda7f0..a6c647a09d 100644 > --- a/xen/arch/arm/firmware/sci.c > +++ b/xen/arch/arm/firmware/sci.c > @@ -126,6 +126,42 @@ int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev) > return 0; > } > > +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d, > + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) > +{ > + struct dt_device_node *dev; > + int ret = 0; Should this be -ENXIO? > + > + switch ( domctl->cmd ) > + { > + case XEN_DOMCTL_assign_device: > + ret = -ENXIO; > + if ( domctl->u.assign_device.dev != XEN_DOMCTL_DEV_DT ) > + break; > + > + if ( !cur_mediator ) > + break; > + > + if ( !cur_mediator->assign_dt_device ) > + break; > + > + ret = dt_find_node_by_gpath(domctl->u.assign_device.u.dt.path, > + domctl->u.assign_device.u.dt.size, &dev); > + if ( ret ) > + return ret; > + > + ret = sci_assign_dt_device(d, dev); > + > + break; > + > + default: > + /* do not fail here as call is chained with iommu handling */ > + break; > + } > + > + return ret; > +} > + > static int __init sci_init(void) > { > struct dt_device_node *np; > diff --git a/xen/arch/arm/include/asm/firmware/sci.h b/xen/arch/arm/include/asm/firmware/sci.h > index 3500216bc2..a2d314e627 100644 > --- a/xen/arch/arm/include/asm/firmware/sci.h > +++ b/xen/arch/arm/include/asm/firmware/sci.h > @@ -146,6 +146,14 @@ int sci_dt_finalize(struct domain *d, void *fdt); > * control" functionality. > */ > int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev); > + > +/* > + * SCI domctl handler > + * > + * Only XEN_DOMCTL_assign_device is handled for now. > + */ > +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d, > + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl); > #else > > static inline bool sci_domain_is_enabled(struct domain *d) > @@ -195,6 +203,12 @@ static inline int sci_assign_dt_device(struct domain *d, > return 0; > } > > +static inline int sci_do_domctl(struct xen_domctl *domctl, struct domain *d, > + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) > +{ > + return 0; This should be -ENXIO? Other than this: Reviewed-by: Stefano Stabellini Those two changes can be done on commit > +} > + > #endif /* CONFIG_ARM_SCI */ > > #endif /* __ASM_ARM_SCI_H */ > diff --git a/xen/common/domctl.c b/xen/common/domctl.c > index 29a7726d32..b3d1381182 100644 > --- a/xen/common/domctl.c > +++ b/xen/common/domctl.c > @@ -29,6 +29,9 @@ > #include > > #include > +#ifdef CONFIG_ARM > +#include > +#endif > #include > #include > #include > @@ -833,6 +836,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) > case XEN_DOMCTL_test_assign_device: > case XEN_DOMCTL_deassign_device: > case XEN_DOMCTL_get_device_group: > + /* > + * Chain SCI DT handling ahead of the IOMMU path so an SCI mediator > + * can authorise access-controlled DT devices. Unhandled cases report > + * -ENXIO, which is ignored. Any other SCI error aborts before the > + * IOMMU path runs. > + */ > +#ifdef CONFIG_ARM_SCI > + ret = sci_do_domctl(op, d, u_domctl); > + if ( ret < 0 && ret != -ENXIO ) > + break; > +#endif > + > ret = iommu_do_domctl(op, d, u_domctl); > break; > > diff --git a/xen/drivers/passthrough/device_tree.c b/xen/drivers/passthrough/device_tree.c > index f5850a2607..29a44dc773 100644 > --- a/xen/drivers/passthrough/device_tree.c > +++ b/xen/drivers/passthrough/device_tree.c > @@ -379,6 +379,12 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d, > break; > } > > + if ( !dt_device_is_protected(dev) ) > + { > + ret = 0; > + break; > + } > + > ret = iommu_assign_dt_device(d, dev); > > if ( ret ) > -- > 2.34.1 > --8323329-1779629773-1769728429=:2238666-- From xen-devel-bounces@lists.xenproject.org Thu Jan 29 23:20:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 23:20:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217105.1526917 (Exim 4.92) (envelope-from ) id 1vlbJ0-00032w-Bw; Thu, 29 Jan 2026 23:20:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217105.1526917; Thu, 29 Jan 2026 23:20: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 1vlbJ0-00032p-97; Thu, 29 Jan 2026 23:20:06 +0000 Received: by outflank-mailman (input) for mailman id 1217105; Thu, 29 Jan 2026 23:20:05 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlbIz-0002qh-9Y for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 23:20: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 09ff99fb-fd69-11f0-b160-2bf370ae4941; Fri, 30 Jan 2026 00:20:03 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 60D106001A; Thu, 29 Jan 2026 23:20:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 85587C4CEF7; Thu, 29 Jan 2026 23:20: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: 09ff99fb-fd69-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769728802; bh=VzOS7K6H7Wqg5KcjJXPpN5yAoinwvbEy5F7XI3gKziA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=YZSY4P+U7lWFlnunk/tyaRqVx8/aXMd6Hs/XGF1ypr1N9vSObWPLHHbW2t0igh3VG dEm06qQE17ObTJy0rTDTkB7TZWwEpONIq7H8cehyF/OpQCrWEmbP1AyOFxF4T/A1oa M/VMLPrvyvekzAA4LRwxN0XHh0IyyWnPubnYpENwYuRShmamiB6tDA3anAosHSbxgM bUqRxJGC0+WpS92B6YUQXAJhQT6Y0PFoixpGyICPkb/2KhLlwwzz+jNF2csoWlMXch AwJX7h7pe8lK53vMTfnXk4gq0+kJW4r74YAwZ7TAI6jgunDDdq5GSvEeOYuvhP9S4G dG5eEbwfxOsWw== Date: Thu, 29 Jan 2026 15:19:59 -0800 (PST) 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 v9 2/5] xen: arm: smccc: add INVALID_PARAMETER error code In-Reply-To: <366a3a85e89e868a12e261ea0ae07aca661d0ab6.1769696107.git.oleksii_moisieiev@epam.com> Message-ID: References: <366a3a85e89e868a12e261ea0ae07aca661d0ab6.1769696107.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 Thu, 29 Jan 2026, Oleksii Moisieiev wrote: > According to the "7.1 Return Codes" section of DEN0028 [1] > INVALID_PARAMETER code (-3) is returned when one of the call > parameters has a non-supported value. > Adding this error code to the common smccc header file. > > [1]: https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6 > > Signed-off-by: Oleksii Moisieiev Acked-by: Stefano Stabellini > --- > > > > xen/arch/arm/include/asm/smccc.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/xen/arch/arm/include/asm/smccc.h b/xen/arch/arm/include/asm/smccc.h > index 441b3ab65d..478444fb09 100644 > --- a/xen/arch/arm/include/asm/smccc.h > +++ b/xen/arch/arm/include/asm/smccc.h > @@ -381,6 +381,7 @@ void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs *args, > 0x3FFF) > > /* SMCCC error codes */ > +#define ARM_SMCCC_INVALID_PARAMETER (-3) > #define ARM_SMCCC_NOT_REQUIRED (-2) > #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION (-1) > #define ARM_SMCCC_NOT_SUPPORTED (-1) > -- > 2.34.1 > From xen-devel-bounces@lists.xenproject.org Thu Jan 29 23:34:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 29 Jan 2026 23:34:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217113.1526927 (Exim 4.92) (envelope-from ) id 1vlbWQ-0004sp-GS; Thu, 29 Jan 2026 23:33:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217113.1526927; Thu, 29 Jan 2026 23:33: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 1vlbWQ-0004si-Dh; Thu, 29 Jan 2026 23:33:58 +0000 Received: by outflank-mailman (input) for mailman id 1217113; Thu, 29 Jan 2026 23:33:57 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlbWP-0004sc-TE for xen-devel@lists.xenproject.org; Thu, 29 Jan 2026 23:33: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 f799f821-fd6a-11f0-9ccf-f158ae23cfc8; Fri, 30 Jan 2026 00:33:52 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 6DECC440EE; Thu, 29 Jan 2026 23:33:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B6CB2C4CEF7; Thu, 29 Jan 2026 23:33: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: f799f821-fd6a-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769729630; bh=XrUTPXDKKPRFMjII7zeiwjtCO89SxFuV/F/W1/Ggk7s=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=f/QWiOUbjBKGsJNC91hWIZ0D761M/ZbM4EsKuJt09kfSNBlQ6wVyWkvR8Q+GXX7fp M9yAv6YziojN50ggS0OalaWVmm4WX12/wpPXgxHKigoHDL7zwMzTrVBYvLtBLX6I4X ABg+5h6b0E0bP9ikI1I0wzO99ESMWW+LmKSJFdCmj6jb2dbWsvdYKdQ4SEjwh1wE62 i4f5eGHllp7r9oOgyNYFBklAuTiiUMkn5QxnZjJXbHRim/++/M2GtbGFRJRKKcvWLO +ymyd9tL3VB76Lx4rWhFV+9pszW+/iQR0deGEFZRJn3D8FeARo3wtF3P0tWyE7SCq9 c9UWG7WK5+kZQ== Date: Thu, 29 Jan 2026 15:33:47 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Jan Beulich cc: Oleksii Moisieiev , Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Volodymyr Babchuk , Grygorii Strashko , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v9 3/5] lib/arm: Add I/O memory copy helpers In-Reply-To: <1308a872-dc7f-4e0f-aa9e-e9d05af3d135@suse.com> Message-ID: References: <1308a872-dc7f-4e0f-aa9e-e9d05af3d135@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, 29 Jan 2026, Jan Beulich wrote: > On 29.01.2026 15:16, Oleksii Moisieiev wrote: > > --- /dev/null > > +++ b/xen/arch/arm/lib/memcpy-fromio.c > > @@ -0,0 +1,56 @@ > > +/* SPDX-License-Identifier: GPL-2.0-only */ > > +#include > > + > > +#include > > Why both, when xen/io.h includes asm/io.h anyway? > > > +/* > > + * Arm implementation notes / limitations: > > + * - Uses ordered 8-bit for leading/trailing unaligned bytes and ordered > > + * 32-bit accesses for the aligned bulk; no wider accesses are issued. > > + * - Only suitable for devices that tolerate 8-bit and 32-bit accesses; > > + * do not use with devices requiring strictly 16-bit or 64-bit accesses. > > + * - MMIO must be mapped with appropriate device attributes to preserve > > + * ordering; no extra barriers beyond the ordered accessors are added. > > + * - If source or destination is misaligned, leading bytes are copied > > + * byte-by-byte until both sides are 32-bit aligned, > > Which may be never, which in turn may not be obvious to the reader. > > > then bulk copy uses > > + * 32-bit accesses. > > + */ > > It'll be Arm maintainers to judge whether these restrictions are really > going to be acceptable. I think I pointed out more than once that I > think these functions end up being too-narrow-purpose. I am not the greatest fan of this code, but it seems to fit the purpose well enough, so: Reviewed-by: Stefano Stabellini From xen-devel-bounces@lists.xenproject.org Fri Jan 30 00:12:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Jan 2026 00:12:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217124.1526937 (Exim 4.92) (envelope-from ) id 1vlc7d-0002HD-Ry; Fri, 30 Jan 2026 00:12:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217124.1526937; Fri, 30 Jan 2026 00: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 1vlc7d-0002H6-P3; Fri, 30 Jan 2026 00:12:25 +0000 Received: by outflank-mailman (input) for mailman id 1217124; Fri, 30 Jan 2026 00: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 1vlc7c-0002H0-1B for xen-devel@lists.xenproject.org; Fri, 30 Jan 2026 00:12:24 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 53c8d3b5-fd70-11f0-b160-2bf370ae4941; Fri, 30 Jan 2026 01:12:14 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 6B8126001A; Fri, 30 Jan 2026 00:12:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4D4B5C4CEF7; Fri, 30 Jan 2026 00:12: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: 53c8d3b5-fd70-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769731932; bh=X9e4aRwvs3kMES98wOmVhd/s13fJZzIY3zI8ol73llo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=nWA3NN2dbT0vXX2+Zf6GRDNN6BP5lkTnC4jI3eHg5kYfBXIXc6bcLrLUag2EQ6jBy nvchuncOpHG3RWLBAUo8T0VrJ5XkJvaF2HYwZuLYG83iJ8IjImASBeUHj8BgyLjatc idz61UpbstVL0hMwBdq1kmzqKqzcHg//RkVi4GPGHKNzVL2+LWZIRt/Qz+apteqtLm dTGZhw2Xr1PUP8K3ffNtvwr3x47QNViN4GeQNhtauTsiUoFG8YfgK96q7pxwIaZJ9J 5u0jCDJOPz3cgFk1PFNx4KHM127sYiko0KhpbzZmcbOxmQsn8R2sXC5g13tu20sLAu 3MA3LcuF9uWpA== Date: Thu, 29 Jan 2026 16:12:08 -0800 (PST) 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 v9 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver In-Reply-To: <3a5ff98b9c46c393e856c2e9a645b2cb1509d5c4.1769696107.git.oleksii_moisieiev@epam.com> Message-ID: References: <3a5ff98b9c46c393e856c2e9a645b2cb1509d5c4.1769696107.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 Thu, 29 Jan 2026, Oleksii Moisieiev wrote: > This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-A > (TF-A) which provides SCMI interface with multi-agent support, as shown > below. > > +-----------------------------------------+ > | | > | EL3 TF-A SCMI | > +-------+--+-------+--+-------+--+-------++ > |shmem1 | |shmem0 | |shmem2 | |shmemX | > +-----+-+ +---+---+ +--+----+ +---+---+ > smc-id1 | | | | > agent1 | | | | > +-----v--------+---------+-----------+----+ > | | | | | > | | | | | > +--------------+---------+-----------+----+ > smc-id0 | smc-id2| smc-idX| > agent0 | agent2 | agentX | > | | | > +----v---+ +--v-----+ +--v-----+ > | | | | | | > | Dom0 | | Dom1 | | DomX | > | | | | | | > | | | | | | > +--------+ +--------+ +--------+ > > The EL3 SCMI multi-agent firmware is expected to provide SCMI SMC shared > memory transport for every Agent in the system. > > The SCMI Agent transport channel defined by pair: > - smc-id: SMC id used for Doorbell > - shmem: shared memory for messages transfer, Xen page > aligned. Shared memort is mapped with the following flags: > MT_DEVICE_nGnRE. > > The follwoing SCMI Agents are expected to be defined by SCMI FW to enable SCMI > multi-agent functionality under Xen: > - Xen management agent: trusted agents that accesses to the Base Protocol > commands to configure agent specific permissions > - OSPM VM agents: non-trusted agent, one for each Guest domain which is > allowed direct HW access. At least one OSPM VM agent has to be provided > by FW if HW is handled only by Dom0 or Driver Domain. > > The EL3 SCMI FW is expected to implement following Base protocol messages: > - BASE_DISCOVER_AGENT (optional if agent_id was provided) > - BASE_RESET_AGENT_CONFIGURATION (optional) > - BASE_SET_DEVICE_PERMISSIONS (optional) > > The SCI SCMI SMC multi-agent driver implements following > functionality: > - The driver is initialized from the Xen SCMI container ``xen_scmi_config`` > (compatible ``xen,sci``) placed under ``/chosen/xen``. Only the > ``arm,scmi-smc`` node that is a child of this container will bind to Xen; > other SCMI nodes (for example under ``/firmware``) are ignored to avoid > stealing the host OSPM instance. > > scmi_shm_1: sram@47ff1000 { > compatible = "arm,scmi-shmem"; > reg = <0x0 0x47ff1000 0x0 0x1000>; > }; > scmi_xen: scmi { > compatible = "arm,scmi-smc"; > arm,smc-id = <0x82000003>; <--- Xen management agent smc-id > #address-cells = < 1>; > #size-cells = < 0>; > #access-controller-cells = < 1>; > shmem = <&scmi_shm_1>; <--- Xen management agent shmem > }; > > - The driver obtains Xen specific SCMI Agent's configuration from the > Host DT, probes Agents and builds SCMI Agents list. The Agents > configuration is taken from "scmi-secondary-agents" property where > first item is "arm,smc-id", second - "arm,scmi-shmem" phandle and > third is optional "agent_id": > > / { > chosen { > xen { > ranges; > xen_scmi_config { > compatible = "xen,sci"; > #address-cells = <2>; > #size-cells = <2>; > ranges; > > scmi_shm_0: sram@47ff0000 { > compatible = "arm,scmi-shmem"; > reg = <0x0 0x47ff0000 0x0 0x1000>; > }; > > /* Xen SCMI management channel */ > scmi_shm_1: sram@47ff1000 { > compatible = "arm,scmi-shmem"; > reg = <0x0 0x47ff1000 0x0 0x1000>; > }; > > scmi_shm_2: sram@47ff2000 { > compatible = "arm,scmi-shmem"; > reg = <0x0 0x47ff2000 0x0 0x1000>; > }; > > scmi_shm_3: sram@47ff3000 { > compatible = "arm,scmi-shmem"; > reg = <0x0 0x47ff3000 0x0 0x1000>; > }; > > scmi-secondary-agents = < > 0x82000002 &scmi_shm_0 0 > 0x82000004 &scmi_shm_2 2 > 0x82000005 &scmi_shm_3 3>; <--- func_id, shmem, agent_id > #scmi-secondary-agents-cells = <3>; > xen,dom0-sci-agent-id = <0>; > > scmi_xen: scmi { > compatible = "arm,scmi-smc"; > arm,smc-id = <0x82000003>; <--- Xen management agent func_id > #address-cells = <1>; > #size-cells = <0>; > #access-controller-cells = <1>; > shmem = <&scmi_shm_1>; <--- Xen management agent shmem > }; > }; > }; > }; > }; > > / { > /* > * Host SCMI OSPM channel - provided to the Dom0 as is if SCMI > * enabled for it, ignored by Xen multi-agent mediator > */ > scmi_shm: sram@47ff0000 { > compatible = "arm,scmi-shmem"; > reg = <0x0 0x47ff0000 0x0 0x1000>; > }; > > firmware { > scmi: scmi { > compatible = "arm,scmi-smc"; > arm,smc-id = <0x82000002>; <--- Host OSPM agent smc-id > #address-cells = < 1>; > #size-cells = < 0>; > shmem = <&scmi_shm>; <--- Host OSPM agent shmem > > protocol@X{ > }; > }; > }; > }; > > This approach allows defining multiple SCMI Agents by adding > Xen-specific properties under the ``/chosen`` node to the Host Device > Tree, leaving the main part unchanged. The Host DT SCMI channel will > be passed to Dom0. > > The Xen management agent is described as a ``scmi_xen`` node under the > ``xen,sci`` comaptible node, which is used by Xen to control other > SCMI Agents in the system. > > All secondary agents' configurations are provided in the > ``scmi-secondary-agents`` property with an optional ``agent_id`` field. > > The ``agent_id`` from the ``scmi-secondary-agents`` property is used > to identify the agent in the system and can be omitted by setting > ``#scmi-secondary-agents-cells = <2>``, so the Secondary Agents > configuration will look like this: > > / { > chosen { > xen { > xen_scmi_config { > compatible = "xen,sci"; > #address-cells = <2>; > #size-cells = <2>; > ranges; > > /* Shared memory nodes as defined earlier */ > > scmi-secondary-agents = < > 0x82000003 &scmi_shm_0 > 0x82000004 &scmi_shm_2 > 0x82000005 &scmi_shm_3 > 0x82000006 &scmi_shm_4>; > #scmi-secondary-agents-cells = <2>; > }; > }; > }; > } > > In this case, Xen will use the ``SCMI_BASE_DISCOVER_AGENT`` call to > discover the ``agent_id`` for each secondary agent. Providing the > ``agent_id`` in the ``scmi-secondary-agents`` property allows skipping > the discovery call, which is useful when the secondary agent's shared > memory is not accessible by Xen or when boot time is important because > it allows skipping the agent discovery procedure. > > Note that Xen is the only one entry in the system which need to know > about SCMI multi-agent support. > > SMC ID Configuration and SCMI Connection Compatibility: > > The configuration allows the same device tree to work for both baremetal > Linux and Linux Dom0. This is achieved because: > > - Baremetal Linux uses: func_id 0x82000002, scmi-shmem 0x47ff0000 > - Dom0 Linux uses: func_id 0x82000002, scmi-shmem 0x47ff0000 > - Xen management uses: func_id 0x82000003, scmi-shmem 0x47ff1000 > > This works because the privileged SCMI connection in EL3 firmware is not > tied exclusively to func_id 0x82000002. The EL3 firmware supports multiple > SCMI agents with different SMC IDs and shared memory regions. Each agent > (Dom0 via 0x82000002, Xen via 0x82000003, other domains via additional > func_ids) has an independent communication channel to the firmware. > > The key distinction is that Xen's management channel (0x82000003) is used > for privileged operations like agent configuration and device permissions > (BASE_SET_DEVICE_PERMISSIONS, BASE_RESET_AGENT_CONFIGURATION), while Dom0's > channel (0x82000002) is used for standard SCMI protocol operations (power, > clock, sensor management, etc.). The firmware enforces different permission > levels for each agent based on their agent_id, not the SMC ID. > > Therefore, there is no conflict: Linux Dom0 retains its standard SCMI > connection for hardware management, while Xen uses its separate privileged > channel for mediating access between multiple domains. > > - It implements the SCI subsystem interface required for configuring and > enabling SCMI functionality for Dom0/hwdom and Guest domains. To enable > SCMI functionality for domain it has to be configured with unique supported > SCMI Agent_id and use corresponding SCMI SMC shared memory transport > [smc-id, shmem] defined for this SCMI Agent_id. > - Once Xen domain is configured it can communicate with EL3 SCMI FW: > -- zero-copy, the guest domain puts SCMI message in shmem; > -- the guest triggers SMC exception with smc-id (doorbell); > -- the Xen driver catches exception, do checks and synchronously forwards > it to EL3 FW. > - the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen > management agent channel on domain destroy event. This allows to reset > resources used by domain and so implement use-case like domain reboot. > > Dom0 Enable SCMI SMC: > - set xen,dom0-sci-agent-id= under the xen,sci container in > the Host DT. If the property is absent, SCMI is disabled for Dom0 > and all SCMI nodes are removed from the Dom0 DT. The driver updates > the Dom0 DT SCMI node "arm,smc-id" value and fixes up the shmem > node according to the assigned agent_id. > > - pass dom0=sci-agent-id= in Xen command line. if not provided > SCMI will be disabled for Dom0 and all SCMI nodes removed from Dom0 DT. > The driver updates Dom0 DT SCMI node "arm,smc-id" value and fix up shmem > node according to assigned agent_id. > > Guest domains enable SCMI SMC: > - xl.cfg: add configuration option as below > > arm_sci = "type=scmi_smc_multiagent,agent_id=2" > > - xl.cfg: enable access to the "arm,scmi-shmem" which should > correspond assigned agent_id for the domain, for example: > > iomem = [ > "47ff2,1@22001", > ] > > - DT: add SCMI nodes to the Driver domain partial device tree as in the > below example. The "arm,smc-id" should correspond assigned agent_id > for the domain: > > passthrough { > scmi_shm_0: sram@22001000 { > compatible = "arm,scmi-shmem"; > reg = <0x0 0x22001000 0x0 0x1000>; > }; > > firmware { > compatible = "simple-bus"; > scmi: scmi { > compatible = "arm,scmi-smc"; > arm,smc-id = <0x82000004>; > shmem = <&scmi_shm_0>; > ... > } > } > } > > SCMI "4.2.1.1 Device specific access control" > > The XEN SCI SCMI SMC multi-agent driver performs "access-controller" > provider function in case EL3 SCMI FW implements SCMI "4.2.1.1 Device > specific access control" and provides the BASE_SET_DEVICE_PERMISSIONS > command to configure the devices that an agents have access to. > The DT SCMI node should "#access-controller-cells=<1>" property and DT > devices should be bound to the Xen SCMI. > > &i2c1 { > access-controllers = <&scmi 0>; > }; > > The Dom0 and dom0less domains DT devices will be processed > automatically through sci_assign_dt_device() call, but to assign SCMI > devices from toolstack the xl.cfg:"dtdev" property > shall be used: > > dtdev = [ > "/soc/i2c@e6508000", > ] > > xl.cfg:dtdev will contain all nodes which are under SCMI > management (not only those which are behind IOMMU). > > Additionally, this patch adds documentation for the pre-existing > scmi-smc-passthrough command line option, which was previously > undocumented. > > [0] https://developer.arm.com/documentation/den0056 > [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > [2] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml > > Signed-off-by: Grygorii Strashko > Signed-off-by: Oleksii Moisieiev > --- > > Changes in v9: > - sort and refactor MAINTAINERS enties > - remove Spurious changes > - add extra check to avoid ASSERT when calling unmap_channel_memory > from assign device method > - set correct tx flag to SCMI_BASE_AGENT_PERMISSIONS_RESET when > freeing resources. Flag should be set to 1 according to the > section 4.2.2.12 [0]. > - fix dt node copmaring > - moved channel->shmem check from ASSERT in unmap_memory_channel to > "if" statement. This will prevent firing ASSERT if > unmap_channel_memory was called twice on the same channel. > > Changes in v8: > - update xen_scmi func_id in commit description > - updated documentation with the new DT format > - updated opt_dom0_scmi_agent_id setting to avoid it to be equal > SCMI_AGENT_ID_INVALID. > - changed SCMI_AGENT_ID_INVALID from 0xff to UINT8_MAX which makes > code more clear showing that UINT8_MAX is theated like invalid > agent_id and couldn't be used. Also excluded SCMI_AGENT_ID_INVALID > from acceptable value range > - remove outdated xen,config property ignore, added xen,sci compatible > to skip_matches in handle_node > - add documentation for pre-existing scmi-smc-passthrough command line > option in alphabetically correct location (in 's' section) > - add note to commit description about documentation for previously > undocumented scmi-smc-passthrough > - Fix SMC IDs in DT examples (Xen management uses 0x82000003, Dom0 uses 0x82000002) > - Add explicit note explaining why Dom0 and Xen channels do not conflict > - Document dom0less multi-agent configuration example (xen,sci_type / xen,sci-agent-id) > - Add scmi_xen node to agent-discovery example with #scmi-secondary-agents-cells = 2 > - Drop dom0=sci-agent-id command line handling; Dom0 SCMI is now enabled via > xen,dom0-sci-agent-id in the xen,sci DT container > - Refresh docs and examples to mention the DT property instead of the cmdline option > > Changes in v7: > - rework scmi nodes for xen to match on compatible string instead of > the direct path > > Changes in v6: > - updated scmi-shmem to use io.h from generic location > - update scmi_agent_id parameter to be provided inside dom0= parameter > list and have the following format "dom0=sci-agent-id=0" > This change was done as a response for Stefano comment and > requires a lot of code changes, but produces much cleaner solution > that's why I've added it to the code. > - fix file comments and return codes > - fix lenght checks in shmem_{get,put}_message to use offsetof > - remove len member from scmi_channel structure as it is not used > - set scmi-secondary-agents property to be mandatory since if no > secondary agents were provided then there is no sence to enable scmi > when no secondary agents are populated to the Domains > - update documentation in booting.txt, added xen_scmi node to the > example > - adjust d->arch.sci_enabled value in scmi_domain_destroy > - fix lock management in smc_create_channel call > - avoid extra map_channel_memory command for Xen management channel > because collect_agent_id call unmaps memory if DOMID_XEN is not > set. So for Xen management channel we can init domain_id ad DOMID_XEN > before calling collect_agent_id so memory shouldn't be unmapped. > > Changes in v5: > - fix device-tree example format in booting.txt, added ";" after "}". > - update define in scmi-proto.h > - update define in scmi-shmem.h file > - scmi_assign_device - do not ignore -EOPNOTSUPP return > code of the do_smc_xfer > - remove overwriting agent_channel->agent_id after > SCMI_BASE_DISCOVER_AGENT call > - add multi-agent files to the MAINTAINERS > - add SCMI multi-agent description to the SUPPORT.md > - handle ARM_SMCCC_INVALID_PARAMETER return code and return -EINVAL > for smc call > - updated collect_agents function. Set agent_id parameter as optional > in scmi-secondary-agents device-tree property > - introduce "#scmi-secondary-agents-cells" parameter to set if > agent_id was provided > - reanme xen,scmi-secondary-agents property to scmi-secondary-agents > - move memcpu_toio/fromio for the generic place > - update Xen to get management channel from /chosen/xen,config node > - get hypervisor channnel from node instead of using hardcoded > - update handling scmi and shmem nodes for the domain > - Set multi-agent driver to support only Arm64 > > Changes in v4: > - toolstack comments from Anthony PERARD > - added dom0less support > - added doc for "xen,scmi-secondary-agents" > > MAINTAINERS | 1 + > SUPPORT.md | 11 + > docs/man/xl.cfg.5.pod.in | 13 + > docs/misc/arm/device-tree/booting.txt | 196 +++++ > tools/libs/light/libxl_arm.c | 4 + > tools/libs/light/libxl_types.idl | 4 +- > tools/xl/xl_parse.c | 12 + > xen/arch/arm/dom0less-build.c | 11 + > xen/arch/arm/domain_build.c | 39 + > xen/arch/arm/firmware/Kconfig | 12 + > xen/arch/arm/firmware/Makefile | 1 + > xen/arch/arm/firmware/scmi-proto.h | 164 ++++ > xen/arch/arm/firmware/scmi-shmem.c | 115 +++ > xen/arch/arm/firmware/scmi-shmem.h | 45 ++ > xen/arch/arm/firmware/scmi-smc-multiagent.c | 818 ++++++++++++++++++++ > xen/include/public/arch-arm.h | 3 + > 16 files changed, 1448 insertions(+), 1 deletion(-) > create mode 100644 xen/arch/arm/firmware/scmi-proto.h > create mode 100644 xen/arch/arm/firmware/scmi-shmem.c > create mode 100644 xen/arch/arm/firmware/scmi-shmem.h > create mode 100644 xen/arch/arm/firmware/scmi-smc-multiagent.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index bf00be928c..3f82a07070 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -529,6 +529,7 @@ SCI MEDIATORS > R: Oleksii Moisieiev > S: Supported > F: xen/arch/arm/firmware/sci.c > +F: xen/arch/arm/firmware/scmi-*.[ch] mixing tabs and spaces > F: xen/arch/arm/include/asm/firmware/sci.h > > SEABIOS UPSTREAM > diff --git a/SUPPORT.md b/SUPPORT.md > index d441bccf37..03e3985da2 100644 > --- a/SUPPORT.md > +++ b/SUPPORT.md > @@ -956,6 +956,17 @@ by hwdom. Some platforms use SCMI for access to system-level resources. > > Status: Supported > > +### Arm: SCMI SMC multi-agent support > + > +Enable support for the multi-agent configuration of the EL3 Firmware, which > +allows Xen to provide an SCMI interface to the Domains. > +Xen manages access permissions to the HW resources and provides an SCMI interface > +to the Domains. Each Domain is represented as a separate Agent, which can > +communicate with EL3 Firmware using a dedicated shared memory region, and > +notifications are passed through by Xen. > + > + Status, ARM64: Tech Preview > + > ### ARM: Guest PSCI support > > Emulated PSCI interface exposed to guests. We support all mandatory > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in > index 27c455210b..6943ae29ad 100644 > --- a/docs/man/xl.cfg.5.pod.in > +++ b/docs/man/xl.cfg.5.pod.in > @@ -3156,8 +3156,21 @@ single SCMI OSPM agent support. > Should be used together with B Xen command line > option. > > +=item B > + > +Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI over > +SMC calls forwarding from domain to the EL3 firmware (like Trusted Firmware-A) > +with a multi SCMI OSPM agent support. The SCMI B should be > +specified for the guest. > + > =back > > +=item B > + > +Specifies a non-zero ARM SCI agent id for the guest. This option is mandatory > +if the SCMI SMC support is enabled for the guest. The agent ids of domains > +existing on a single host must be unique and in the range [1..255]. > + > =back > > =back > diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt > index 977b428608..6b88dae347 100644 > --- a/docs/misc/arm/device-tree/booting.txt > +++ b/docs/misc/arm/device-tree/booting.txt > @@ -322,6 +322,20 @@ with the following properties: > Should be used together with scmi-smc-passthrough Xen command line > option. > > + - "scmi_smc_multiagent" > + > + Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI over > + SMC calls forwarding from domain to the EL3 firmware (like ARM > + Trusted Firmware-A) with a multi SCMI OSPM agent support. > + The SCMI agent_id should be specified for the guest with "xen,sci-agent-id" > + property. > + > +- "xen,sci-agent-id" > + > + Specifies ARM SCMI agent id for the guest. This option is mandatory if the > + SCMI SMC "scmi_smc_multiagent" support is enabled for the guest. The agent ids > + of guest must be unique and in the range [0..255]. > + > Under the "xen,domain" compatible node, one or more sub-nodes are present > for the DomU kernel and ramdisk. > > @@ -824,3 +838,185 @@ The automatically allocated static shared memory will get mapped at > 0x80000000 in DomU1 guest physical address space, and at 0x90000000 in DomU2 > guest physical address space. DomU1 is explicitly defined as the owner domain, > and DomU2 is the borrower domain. > + > +SCMI SMC multi-agent support > +============================ > + > +For enabling the ARM SCMI SMC multi-agent support (enabled by CONFIG_SCMI_SMC_MA) > +the Xen specific SCMI Agent's configuration shall be provided in the Host DT > +according to the SCMI compliant EL3 Firmware specification with ARM SMC/HVC > +transport. The SCMI configuration must live under the Xen SCMI container > +"xen,sci" beneath "/chosen" (for example "/chosen/xen/xen_scmi_config/scmi"). The > +Xen SCMI mediator will bind only to the "arm,scmi-smc" node that is a child of > +this "xen,sci" container; any other "arm,scmi-smc" nodes (for example under > +"/firmware") are ignored to avoid stealing the host's SCMI OSPM instance. > + > +- scmi-secondary-agents > + > + Defines a set of SCMI agents configuration supported by SCMI EL3 FW and > + available for Xen. Each Agent defined as triple consisting of: > + SMC/HVC function_id assigned for the agent transport ("arm,smc-id"), > + phandle to SCMI SHM assigned for the agent transport ("arm,scmi-shmem"), > + SCMI agent_id (optional) if not set - Xen will determine Agent ID for > + each provided channel using BASE_DISCOVER_AGENT message. > + > +- xen,dom0-sci-agent-id > + > + Optional. Specifies the Dom0/hwdom SCMI agent_id inside the ``xen,sci`` > + container. When provided, Dom0 will be configured for SCMI multi-agent > + support; when omitted, SCMI remains disabled for Dom0. The value must > + match the ``func_id`` and shmem pairing that EL3 firmware exposes for > + Dom0 (for example via ``/firmware/scmi``). > + > +As an example: > + > +/ { > + chosen { > + xen { > + ranges; > + xen_scmi_config { > + compatible = "xen,sci"; > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + > + scmi_shm_0: sram@47ff0000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x47ff0000 0x0 0x1000>; > + }; > + > + /* Xen SCMI management channel */ > + scmi_shm_1: sram@47ff1000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x47ff1000 0x0 0x1000>; > + }; > + > + scmi_shm_2: sram@47ff2000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x47ff2000 0x0 0x1000>; > + }; > + > + scmi_shm_3: sram@47ff3000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x47ff3000 0x0 0x1000>; > + }; > + > + xen,dom0-sci-agent-id = <0>; <--- dom0 agent id > + scmi-secondary-agents = < > + 0x82000002 &scmi_shm_0 0 > + 0x82000004 &scmi_shm_2 2 > + 0x82000005 &scmi_shm_3 3>; <--- func_id, shmem, agent_id > + #scmi-secondary-agents-cells = <3>; > + > + scmi_xen: scmi { > + compatible = "arm,scmi-smc"; > + arm,smc-id = <0x82000003>; <--- Xen management agent func_id > + #address-cells = <1>; > + #size-cells = <0>; > + #access-controller-cells = <1>; > + shmem = <&scmi_shm_1>; <--- Xen management agent shmem > + }; > + }; > + }; > + }; > +}; > + > +Note: This example keeps the Host DT unchanged for Dom0 and baremetal Linux > +by using func_id 0x82000002 / shmem 0x47ff0000 for Dom0, while Xen uses a > +separate privileged channel func_id 0x82000003 / shmem 0x47ff1000. EL3 > +firmware enforces permissions per agent_id, so there is no conflict between > +Dom0 and Xen channels. > + > +- #scmi-secondary-agents-cells > + > + Defines whether Agent_id is set in the "scmi-secondary-agents" property. > + Possible values are: 2, 3. > + When set to 3 (the default), expect agent_id to be present in the secondary > + agents list. > + When set to 2, agent_id will be discovered for each channel using > + BASE_DISCOVER_AGENT message. > + > + > +Example: > + > +/ { > + chosen { > + xen { > + ranges; > + xen_scmi_config { > + compatible = "xen,sci"; > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + > + /* Shared memory nodes as in the previous example */ > + > + scmi-secondary-agents = < > + 0x82000002 &scmi_shm_0 > + 0x82000004 &scmi_shm_2 > + 0x82000005 &scmi_shm_3 > + 0x82000006 &scmi_shm_4>; > + #scmi-secondary-agents-cells = <2>; > + > + scmi_xen: scmi { > + compatible = "arm,scmi-smc"; > + arm,smc-id = <0x82000003>; <--- Xen management agent func_id > + #address-cells = <1>; > + #size-cells = <0>; > + #access-controller-cells = <1>; > + shmem = <&scmi_shm_1>; <--- Xen management agent shmem > + }; > + }; > + }; > + }; > +}; > + > +Dom0less example (multi-agent) > +------------------------------- > + > +Below is a minimal dom0less configuration showing how to enable SCMI SMC > +multi-agent for a pre-defined guest domain using xen,sci_type and > +xen,sci-agent-id, together with the Xen SCMI container: > + > +chosen { > + xen { > + ranges; > + xen_scmi_config { > + compatible = "xen,sci"; > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + > + /* Xen management channel shared memory */ > + scmi_shm_1: sram@47ff1000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x47ff1000 0x0 0x1000>; > + }; > + > + scmi_shm_domu: sram@47ff2000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x47ff2000 0x0 0x1000>; > + }; > + > + scmi-secondary-agents = < > + 0x82000004 &scmi_shm_domu 2>; > + #scmi-secondary-agents-cells = <3>; > + > + scmi_xen: scmi { > + compatible = "arm,scmi-smc"; > + arm,smc-id = <0x82000003>; > + #address-cells = <1>; > + #size-cells = <0>; > + #access-controller-cells = <1>; > + shmem = <&scmi_shm_1>; > + }; > + }; > + }; > + > + xen,domain@1 { > + compatible = "xen,domain"; > + xen,sci_type = "scmi_smc_multiagent"; > + xen,sci-agent-id = <2>; > + /* Additional domain properties (memory, cpus, kernels, etc.) */ > + }; > +}; > diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c > index e4407d6e3f..be0e6263ae 100644 > --- a/tools/libs/light/libxl_arm.c > +++ b/tools/libs/light/libxl_arm.c > @@ -240,6 +240,10 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc, > case LIBXL_ARM_SCI_TYPE_SCMI_SMC: > config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; > break; > + case LIBXL_ARM_SCI_TYPE_SCMI_SMC_MULTIAGENT: > + config->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA; > + config->arch.arm_sci_agent_id = d_config->b_info.arch_arm.arm_sci.agent_id; > + break; > default: > LOG(ERROR, "Unknown ARM_SCI type %d", > d_config->b_info.arch_arm.arm_sci.type); > diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl > index 4a958f69f4..9bfbf09145 100644 > --- a/tools/libs/light/libxl_types.idl > +++ b/tools/libs/light/libxl_types.idl > @@ -554,11 +554,13 @@ libxl_sve_type = Enumeration("sve_type", [ > > libxl_arm_sci_type = Enumeration("arm_sci_type", [ > (0, "none"), > - (1, "scmi_smc") > + (1, "scmi_smc"), > + (2, "scmi_smc_multiagent") > ], init_val = "LIBXL_ARM_SCI_TYPE_NONE") > > libxl_arm_sci = Struct("arm_sci", [ > ("type", libxl_arm_sci_type), > + ("agent_id", uint8) > ]) > > libxl_rdm_reserve = Struct("rdm_reserve", [ > diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c > index 1cc41f1bff..0c389d25f9 100644 > --- a/tools/xl/xl_parse.c > +++ b/tools/xl/xl_parse.c > @@ -1306,6 +1306,18 @@ static int parse_arm_sci_config(XLU_Config *cfg, libxl_arm_sci *arm_sci, > } > } > > + if (MATCH_OPTION("agent_id", ptr, oparg)) { > + unsigned long val = parse_ulong(oparg); > + > + if (!val || val > 255) { this rejects zero > + fprintf(stderr, "An invalid ARM_SCI agent_id specified (%lu). Valid range [1..255]\n", > + val); > + ret = ERROR_INVAL; > + goto out; > + } > + arm_sci->agent_id = val; > + } > + > ptr = strtok(NULL, ","); > } > > diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c > index 4181c10538..ddadc89148 100644 > --- a/xen/arch/arm/dom0less-build.c > +++ b/xen/arch/arm/dom0less-build.c > @@ -299,6 +299,17 @@ static int __init domu_dt_sci_parse(struct dt_device_node *node, > d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_NONE; > else if ( !strcmp(sci_type, "scmi_smc") ) > d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC; > + else if ( !strcmp(sci_type, "scmi_smc_multiagent") ) > + { > + uint32_t agent_id = 0; > + > + if ( !dt_property_read_u32(node, "xen,sci-agent-id", &agent_id) || > + agent_id > UINT8_MAX ) > + return -EINVAL; > + > + d_cfg->arch.arm_sci_type = XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA; > + d_cfg->arch.arm_sci_agent_id = agent_id; This accepts zero > + } > else > { > printk(XENLOG_ERR "xen,sci_type in not valid (%s) for domain %s\n", > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > index 986a456f17..c09f50040e 100644 > --- a/xen/arch/arm/domain_build.c > +++ b/xen/arch/arm/domain_build.c > @@ -86,6 +86,37 @@ int __init parse_arch_dom0_param(const char *s, const char *e) > return -EINVAL; > } > > +/* SCMI agent ID for dom0 obtained from xen,sci container */ > +#define SCMI_AGENT_ID_INVALID UINT8_MAX > + > +static uint8_t __init get_dom0_scmi_agent_id(void) > +{ > + const struct dt_device_node *config_node; > + u32 val; > + const struct dt_property *prop; > + > + config_node = dt_find_compatible_node(NULL, NULL, "xen,sci"); > + if ( !config_node ) > + return SCMI_AGENT_ID_INVALID; > + > + prop = dt_find_property(config_node, "xen,dom0-sci-agent-id", NULL); > + if ( !prop ) > + return SCMI_AGENT_ID_INVALID; > + > + if ( !dt_property_read_u32(config_node, "xen,dom0-sci-agent-id", &val) ) > + return SCMI_AGENT_ID_INVALID; > + > + if ( val >= SCMI_AGENT_ID_INVALID ) > + { > + printk(XENLOG_WARNING > + "Invalid xen,dom0-sci-agent-id=%u, SCMI disabled for Dom0\n", > + val); > + return SCMI_AGENT_ID_INVALID; > + } > + > + return val; > +} > + > /* Override macros from asm/page.h to make them work with mfn_t */ > #undef virt_to_mfn > #define virt_to_mfn(va) _mfn(__virt_to_mfn(va)) > @@ -1459,6 +1490,7 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo, > DT_MATCH_TYPE("memory"), > /* The memory mapped timer is not supported by Xen. */ > DT_MATCH_COMPATIBLE("arm,armv7-timer-mem"), > + DT_MATCH_COMPATIBLE("xen,sci"), > { /* sentinel */ }, > }; > static const struct dt_device_match timer_matches[] __initconst = > @@ -1947,6 +1979,13 @@ void __init create_dom0(void) > dom0_cfg.arch.tee_type = tee_get_type(); > dom0_cfg.max_vcpus = dom0_max_vcpus(); > > + /* Set up SCMI agent ID if provided in the xen,sci container */ > + dom0_cfg.arch.arm_sci_agent_id = get_dom0_scmi_agent_id(); > + dom0_cfg.arch.arm_sci_type = (dom0_cfg.arch.arm_sci_agent_id != > + SCMI_AGENT_ID_INVALID) ? > + XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA : > + XEN_DOMCTL_CONFIG_ARM_SCI_NONE; > + > if ( iommu_enabled ) > dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu; > > diff --git a/xen/arch/arm/firmware/Kconfig b/xen/arch/arm/firmware/Kconfig > index 5c5f0880c4..972cd9b173 100644 > --- a/xen/arch/arm/firmware/Kconfig > +++ b/xen/arch/arm/firmware/Kconfig > @@ -29,6 +29,18 @@ config SCMI_SMC > driver domain. > Use with EL3 firmware which supports only single SCMI OSPM agent. > > +config SCMI_SMC_MA > + bool "Enable ARM SCMI SMC multi-agent driver" > + depends on ARM_64 > + select ARM_SCI > + help > + Enables SCMI SMC/HVC multi-agent in XEN to pass SCMI requests from Domains > + to EL3 firmware (TF-A) which supports multi-agent feature. > + This feature allows to enable SCMI per Domain using unique SCMI agent_id, > + so Domain is identified by EL3 firmware as an SCMI Agent and can access > + allowed platform resources through dedicated SMC/HVC Shared memory based > + transport. > + > endchoice > > endmenu > diff --git a/xen/arch/arm/firmware/Makefile b/xen/arch/arm/firmware/Makefile > index 71bdefc24a..37927e690e 100644 > --- a/xen/arch/arm/firmware/Makefile > +++ b/xen/arch/arm/firmware/Makefile > @@ -1,2 +1,3 @@ > obj-$(CONFIG_ARM_SCI) += sci.o > obj-$(CONFIG_SCMI_SMC) += scmi-smc.o > +obj-$(CONFIG_SCMI_SMC_MA) += scmi-shmem.o scmi-smc-multiagent.o > diff --git a/xen/arch/arm/firmware/scmi-proto.h b/xen/arch/arm/firmware/scmi-proto.h > new file mode 100644 > index 0000000000..49f63cfc0a > --- /dev/null > +++ b/xen/arch/arm/firmware/scmi-proto.h > @@ -0,0 +1,164 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Arm System Control and Management Interface definitions > + * Version 3.0 (DEN0056C) > + * > + * Copyright (c) 2025 EPAM Systems > + */ > + > +#ifndef ARM_FIRMWARE_SCMI_PROTO_H_ > +#define ARM_FIRMWARE_SCMI_PROTO_H_ > + > +#include > + > +#define SCMI_SHORT_NAME_MAX_SIZE 16 > + > +/* SCMI status codes. See section 4.1.4 */ > +#define SCMI_SUCCESS 0 > +#define SCMI_NOT_SUPPORTED (-1) > +#define SCMI_INVALID_PARAMETERS (-2) > +#define SCMI_DENIED (-3) > +#define SCMI_NOT_FOUND (-4) > +#define SCMI_OUT_OF_RANGE (-5) > +#define SCMI_BUSY (-6) > +#define SCMI_COMMS_ERROR (-7) > +#define SCMI_GENERIC_ERROR (-8) > +#define SCMI_HARDWARE_ERROR (-9) > +#define SCMI_PROTOCOL_ERROR (-10) > + > +/* Protocol IDs */ > +#define SCMI_BASE_PROTOCOL 0x10 > + > +/* Base protocol message IDs */ > +#define SCMI_BASE_PROTOCOL_VERSION 0x0 > +#define SCMI_BASE_PROTOCOL_ATTIBUTES 0x1 > +#define SCMI_BASE_PROTOCOL_MESSAGE_ATTRIBUTES 0x2 > +#define SCMI_BASE_DISCOVER_AGENT 0x7 > +#define SCMI_BASE_SET_DEVICE_PERMISSIONS 0x9 > +#define SCMI_BASE_RESET_AGENT_CONFIGURATION 0xB > + > +typedef struct scmi_msg_header { > + uint8_t id; > + uint8_t type; > + uint8_t protocol; > + uint32_t status; > +} scmi_msg_header_t; Should this be __packed or is there padding in here? > +/* Table 2 Message header format */ > +#define SCMI_HDR_ID GENMASK(7, 0) > +#define SCMI_HDR_TYPE GENMASK(9, 8) > +#define SCMI_HDR_PROTO GENMASK(17, 10) > + > +#define SCMI_FIELD_GET(_mask, _reg) \ > + ((typeof(_mask))(((_reg) & (_mask)) >> (ffs64(_mask) - 1))) > +#define SCMI_FIELD_PREP(_mask, _val) \ > + (((typeof(_mask))(_val) << (ffs64(_mask) - 1)) & (_mask)) > + > +static inline uint32_t pack_scmi_header(scmi_msg_header_t *hdr) > +{ > + return SCMI_FIELD_PREP(SCMI_HDR_ID, hdr->id) | > + SCMI_FIELD_PREP(SCMI_HDR_TYPE, hdr->type) | > + SCMI_FIELD_PREP(SCMI_HDR_PROTO, hdr->protocol); > +} > + > +static inline void unpack_scmi_header(uint32_t msg_hdr, scmi_msg_header_t *hdr) > +{ > + hdr->id = SCMI_FIELD_GET(SCMI_HDR_ID, msg_hdr); > + hdr->type = SCMI_FIELD_GET(SCMI_HDR_TYPE, msg_hdr); > + hdr->protocol = SCMI_FIELD_GET(SCMI_HDR_PROTO, msg_hdr); > +} > + > +static inline int scmi_to_xen_errno(int scmi_status) > +{ > + if ( scmi_status == SCMI_SUCCESS ) > + return 0; > + > + switch ( scmi_status ) > + { > + case SCMI_NOT_SUPPORTED: > + return -EOPNOTSUPP; > + case SCMI_INVALID_PARAMETERS: > + return -EINVAL; > + case SCMI_DENIED: > + return -EACCES; > + case SCMI_NOT_FOUND: > + return -ENOENT; > + case SCMI_OUT_OF_RANGE: > + return -ERANGE; > + case SCMI_BUSY: > + return -EBUSY; > + case SCMI_COMMS_ERROR: > + return -ENOTCONN; > + case SCMI_GENERIC_ERROR: > + return -EIO; > + case SCMI_HARDWARE_ERROR: > + return -ENXIO; > + case SCMI_PROTOCOL_ERROR: > + return -EBADMSG; > + default: > + return -EINVAL; > + } > +} > + > +/* PROTOCOL_VERSION */ > +#define SCMI_VERSION_MINOR GENMASK(15, 0) > +#define SCMI_VERSION_MAJOR GENMASK(31, 16) > + > +struct scmi_msg_prot_version_p2a { > + uint32_t version; > +} __packed; > + > +/* BASE PROTOCOL_ATTRIBUTES */ > +#define SCMI_BASE_ATTR_NUM_PROTO GENMASK(7, 0) > +#define SCMI_BASE_ATTR_NUM_AGENT GENMASK(15, 8) > + > +struct scmi_msg_base_attributes_p2a { > + uint32_t attributes; > +} __packed; > + > +/* > + * BASE_DISCOVER_AGENT > + */ > +#define SCMI_BASE_AGENT_ID_OWN 0xFFFFFFFF > + > +struct scmi_msg_base_discover_agent_a2p { > + uint32_t agent_id; > +} __packed; > + > +struct scmi_msg_base_discover_agent_p2a { > + uint32_t agent_id; > + char name[SCMI_SHORT_NAME_MAX_SIZE]; > +} __packed; > + > +/* > + * BASE_SET_DEVICE_PERMISSIONS > + */ > +#define SCMI_BASE_DEVICE_ACCESS_ALLOW BIT(0, UL) > + > +struct scmi_msg_base_set_device_permissions_a2p { > + uint32_t agent_id; > + uint32_t device_id; > + uint32_t flags; > +} __packed; > + > +/* > + * BASE_RESET_AGENT_CONFIGURATION > + */ > +#define SCMI_BASE_AGENT_PERMISSIONS_RESET BIT(0, UL) > + > +struct scmi_msg_base_reset_agent_cfg_a2p { > + uint32_t agent_id; > + uint32_t flags; > +} __packed; > + > +#endif /* ARM_FIRMWARE_SCMI_PROTO_H_ */ > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * tab-width: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/arch/arm/firmware/scmi-shmem.c b/xen/arch/arm/firmware/scmi-shmem.c > new file mode 100644 > index 0000000000..6683e62544 > --- /dev/null > +++ b/xen/arch/arm/firmware/scmi-shmem.c > @@ -0,0 +1,115 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * SMC/HVC shmem transport implementation used by > + * SCI SCMI multi-agent driver. > + * > + * Oleksii Moisieiev > + * Copyright (c) 2025 EPAM Systems > + */ > +/* SPDX-License-Identifier: GPL-2.0-only */ duplicated SPDX tag > +#include > +#include > +#include > + > +#include "scmi-proto.h" > +#include "scmi-shmem.h" > + > +static inline int > +shmem_channel_is_free(const volatile struct scmi_shared_mem __iomem *shmem) > +{ > + return (readl(&shmem->channel_status) & > + SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE) ? 0 : -EBUSY; This return zero when it is free but the function is called "shmem_channel_is_free", which typically you would expect returns true on success and false on failure > +} > + > +int shmem_put_message(volatile struct scmi_shared_mem __iomem *shmem, > + scmi_msg_header_t *hdr, void *data, int len) > +{ > + int ret; > + > + if ( (len + offsetof(struct scmi_shared_mem, msg_payload)) > should len be unsigned? > + SCMI_SHMEM_MAPPED_SIZE ) > + { > + printk(XENLOG_ERR "scmi: Wrong size of smc message. Data is invalid\n"); > + return -EINVAL; > + } > + > + ret = shmem_channel_is_free(shmem); > + if ( ret ) > + return ret; > + > + writel_relaxed(0x0, &shmem->channel_status); > + /* Writing 0x0 right now, but "shmem"_FLAG_INTR_ENABLED can be set */ > + writel_relaxed(0x0, &shmem->flags); > + writel_relaxed(sizeof(shmem->msg_header) + len, &shmem->length); > + writel(pack_scmi_header(hdr), &shmem->msg_header); > + > + if ( len > 0 && data ) > + memcpy_toio(shmem->msg_payload, data, len); > + > + return 0; > +} > + > +int shmem_get_response(const volatile struct scmi_shared_mem __iomem *shmem, > + scmi_msg_header_t *hdr, void *data, int len) > +{ > + int recv_len; > + int ret; > + int pad = sizeof(hdr->status); this deserves a comment > + if ( len >= SCMI_SHMEM_MAPPED_SIZE - > + offsetof(struct scmi_shared_mem, msg_payload) ) > + { > + printk(XENLOG_ERR > + "scmi: Wrong size of input smc message. Data may be invalid\n"); > + return -EINVAL; > + } > + > + ret = shmem_channel_is_free(shmem); > + if ( ret ) > + return ret; > + > + recv_len = readl(&shmem->length) - sizeof(shmem->msg_header); > + > + if ( recv_len < 0 ) > + { > + printk(XENLOG_ERR > + "scmi: Wrong size of smc message. Data may be invalid\n"); > + return -EINVAL; > + } > + > + unpack_scmi_header(readl(&shmem->msg_header), hdr); > + > + hdr->status = readl(&shmem->msg_payload); > + recv_len = recv_len > pad ? recv_len - pad : 0; > + > + ret = scmi_to_xen_errno(hdr->status); > + if ( ret ) > + { > + printk(XENLOG_DEBUG "scmi: Error received: %d\n", ret); > + return ret; > + } > + > + if ( recv_len > len ) > + { > + printk(XENLOG_ERR > + "scmi: Not enough buffer for message %d, expecting %d\n", > + recv_len, len); > + return -EINVAL; > + } > + > + if ( recv_len > 0 ) > + memcpy_fromio(data, shmem->msg_payload + pad, recv_len); > + > + return 0; > +} > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * tab-width: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/arch/arm/firmware/scmi-shmem.h b/xen/arch/arm/firmware/scmi-shmem.h > new file mode 100644 > index 0000000000..7313cb6b26 > --- /dev/null > +++ b/xen/arch/arm/firmware/scmi-shmem.h > @@ -0,0 +1,45 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Arm System Control and Management Interface definitions > + * Version 3.0 (DEN0056C) > + * Shared Memory based Transport > + * > + * Copyright (c) 2024 EPAM Systems > + */ > + > +#ifndef ARM_FIRMWARE_SCMI_SHMEM_H_ > +#define ARM_FIRMWARE_SCMI_SHMEM_H_ > + > +#include > + > +#define SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE BIT(0, UL) > +#define SCMI_SHMEM_CHAN_STAT_CHANNEL_ERROR BIT(1, UL) > + > +struct scmi_shared_mem { > + uint32_t reserved; > + uint32_t channel_status; > + uint32_t reserved1[2]; > + uint32_t flags; > + uint32_t length; > + uint32_t msg_header; > + uint8_t msg_payload[]; > +}; > + > +#define SCMI_SHMEM_MAPPED_SIZE PAGE_SIZE > + > +int shmem_put_message(volatile struct scmi_shared_mem __iomem *shmem, > + scmi_msg_header_t *hdr, void *data, int len); > + > +int shmem_get_response(const volatile struct scmi_shared_mem __iomem *shmem, > + scmi_msg_header_t *hdr, void *data, int len); > +#endif /* ARM_FIRMWARE_SCMI_SHMEM_H_ */ > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * tab-width: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/arch/arm/firmware/scmi-smc-multiagent.c b/xen/arch/arm/firmware/scmi-smc-multiagent.c > new file mode 100644 > index 0000000000..339c45f285 > --- /dev/null > +++ b/xen/arch/arm/firmware/scmi-smc-multiagent.c > @@ -0,0 +1,818 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * SCI SCMI multi-agent driver, using SMC/HVC shmem as transport. > + * > + * Oleksii Moisieiev > + * Copyright (c) 2025 EPAM Systems > + */ > + > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > + > +#include "scmi-proto.h" > +#include "scmi-shmem.h" > + > +#define SCMI_SECONDARY_AGENTS "scmi-secondary-agents" > + > +struct scmi_channel { > + uint32_t agent_id; > + uint32_t func_id; > + domid_t domain_id; > + uint64_t paddr; > + struct scmi_shared_mem __iomem *shmem; > + spinlock_t lock; > + struct list_head list; > +}; > + > +struct scmi_data { > + struct list_head channel_list; > + spinlock_t channel_list_lock; > + uint32_t func_id; > + bool initialized; > + uint32_t shmem_phandle; > + uint32_t hyp_channel_agent_id; > + struct dt_device_node *dt_dev; > +}; > + > +static struct scmi_data scmi_data; > + > +static bool scmi_is_under_xen_sci(const struct dt_device_node *node) > +{ > + const struct dt_device_node *p; > + > + for ( p = node->parent; p; p = p->parent ) > + if ( dt_device_is_compatible(p, "xen,sci") ) > + return true; > + > + return false; > +} > + > +static int send_smc_message(struct scmi_channel *chan_info, > + scmi_msg_header_t *hdr, void *data, int len) > +{ > + struct arm_smccc_res resp; > + int ret; > + > + ret = shmem_put_message(chan_info->shmem, hdr, data, len); > + if ( ret ) > + return ret; > + > + arm_smccc_1_1_smc(chan_info->func_id, 0, 0, 0, 0, 0, 0, 0, &resp); > + > + if ( resp.a0 == ARM_SMCCC_INVALID_PARAMETER ) just noting that a0 is unsigned long and ARM_SMCCC_INVALID_PARAMETER is (-3). Maybe at least an explicit cast? > + return -EINVAL; > + > + if ( resp.a0 ) > + return -EOPNOTSUPP; > + > + return 0; > +} > + > +static int do_smc_xfer(struct scmi_channel *chan_info, scmi_msg_header_t *hdr, > + void *tx_data, int tx_size, void *rx_data, int rx_size) > +{ > + int ret = 0; > + > + ASSERT(chan_info && chan_info->shmem); > + > + if ( !hdr ) > + return -EINVAL; > + > + spin_lock(&chan_info->lock); > + > + printk(XENLOG_DEBUG > + "scmi: agent_id = %d msg_id = %x type = %d, proto = %x\n", > + chan_info->agent_id, hdr->id, hdr->type, hdr->protocol); > + > + ret = send_smc_message(chan_info, hdr, tx_data, tx_size); > + if ( ret ) > + goto clean; > + > + ret = shmem_get_response(chan_info->shmem, hdr, rx_data, rx_size); > + > +clean: > + printk(XENLOG_DEBUG > + "scmi: get smc response agent_id = %d msg_id = %x proto = %x res=%d\n", > + chan_info->agent_id, hdr->id, hdr->protocol, ret); > + > + spin_unlock(&chan_info->lock); > + > + return ret; > +} > + > +static struct scmi_channel *get_channel_by_id(uint32_t agent_id) > +{ > + struct scmi_channel *curr; > + bool found = false; > + > + spin_lock(&scmi_data.channel_list_lock); > + list_for_each_entry(curr, &scmi_data.channel_list, list) > + { > + if ( curr->agent_id == agent_id ) > + { > + found = true; > + break; > + } > + } > + > + spin_unlock(&scmi_data.channel_list_lock); > + if ( found ) > + return curr; > + > + return NULL; > +} > + > +static struct scmi_channel *acquire_scmi_channel(struct domain *d, > + uint32_t agent_id) > +{ > + struct scmi_channel *curr; > + struct scmi_channel *ret = ERR_PTR(-ENOENT); > + > + spin_lock(&scmi_data.channel_list_lock); > + list_for_each_entry(curr, &scmi_data.channel_list, list) > + { > + if ( curr->agent_id == agent_id ) > + { > + if ( curr->domain_id != DOMID_INVALID ) > + { > + ret = ERR_PTR(-EEXIST); > + break; > + } > + > + curr->domain_id = d->domain_id; > + ret = curr; > + break; > + } > + } > + > + spin_unlock(&scmi_data.channel_list_lock); > + > + return ret; > +} > + > +static void relinquish_scmi_channel(struct scmi_channel *channel) > +{ > + ASSERT(channel != NULL); > + > + spin_lock(&scmi_data.channel_list_lock); > + channel->domain_id = DOMID_INVALID; > + spin_unlock(&scmi_data.channel_list_lock); > +} > + > +static int map_channel_memory(struct scmi_channel *channel) > +{ > + ASSERT(channel && channel->paddr); > + channel->shmem = ioremap_nocache(channel->paddr, SCMI_SHMEM_MAPPED_SIZE); > + if ( !channel->shmem ) > + return -ENOMEM; > + > + channel->shmem->channel_status = SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE; > + printk(XENLOG_DEBUG "scmi: Got shmem %lx after vmap %p\n", channel->paddr, > + channel->shmem); > + > + return 0; > +} > + > +static void unmap_channel_memory(struct scmi_channel *channel) > +{ > + ASSERT(channel); > + > + if ( !channel->shmem ) > + return; > + > + iounmap(channel->shmem); > + channel->shmem = NULL; > +} > + > +static struct scmi_channel *smc_create_channel(uint32_t agent_id, > + uint32_t func_id, uint64_t addr) > +{ > + struct scmi_channel *channel, *curr; > + > + spin_lock(&scmi_data.channel_list_lock); > + > + /* Check if channel already exists while holding the lock */ > + list_for_each_entry(curr, &scmi_data.channel_list, list) > + { > + if ( curr->agent_id == agent_id ) > + { > + spin_unlock(&scmi_data.channel_list_lock); > + return ERR_PTR(-EEXIST); > + } > + } > + > + channel = xmalloc(struct scmi_channel); > + if ( !channel ) > + { > + spin_unlock(&scmi_data.channel_list_lock); > + return ERR_PTR(-ENOMEM); > + } > + > + spin_lock_init(&channel->lock); > + channel->agent_id = agent_id; > + channel->func_id = func_id; > + channel->domain_id = DOMID_INVALID; > + channel->shmem = NULL; > + channel->paddr = addr; > + list_add_tail(&channel->list, &scmi_data.channel_list); > + > + spin_unlock(&scmi_data.channel_list_lock); > + return channel; > +} > + > +static void free_channel_list(void) > +{ > + struct scmi_channel *curr, *_curr; > + > + list_for_each_entry_safe(curr, _curr, &scmi_data.channel_list, list) > + { > + list_del(&curr->list); > + xfree(curr); > + } this is done without locking > +} > + > +static int __init > +scmi_dt_read_hyp_channel_addr(struct dt_device_node *scmi_node, u64 *addr, > + u64 *size) > +{ > + struct dt_device_node *shmem_node; > + const __be32 *prop; > + > + prop = dt_get_property(scmi_node, "shmem", NULL); > + if ( !prop ) > + return -EINVAL; > + > + shmem_node = dt_find_node_by_phandle(be32_to_cpu(*prop)); > + if ( IS_ERR_OR_NULL(shmem_node) ) > + { > + printk(XENLOG_ERR > + "scmi: Device tree error, can't parse reserved memory %ld\n", > + PTR_ERR(shmem_node)); > + return PTR_ERR(shmem_node); > + } > + > + return dt_device_get_address(shmem_node, 0, addr, size); > +} > + > +/* > + * Handle Dom0 SCMI specific DT nodes > + * > + * Make a decision on copying SCMI specific nodes into Dom0 device tree. > + * For SCMI multi-agent case: > + * - shmem nodes will not be copied and generated instead if SCMI > + * is enabled for Dom0 > + * - scmi node will be copied if SCMI is enabled for Dom0 > + */ > +static bool scmi_dt_handle_node(struct domain *d, struct dt_device_node *node) > +{ > + static const struct dt_device_match shmem_matches[] __initconst = { > + DT_MATCH_COMPATIBLE("arm,scmi-shmem"), > + { /* sentinel */ }, > + }; > + static const struct dt_device_match scmi_matches[] __initconst = { > + DT_MATCH_PATH("/firmware/scmi"), > + { /* sentinel */ }, > + }; > + > + if ( !scmi_data.initialized ) > + return false; > + > + /* 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; > + } > + > + /* drop scmi if not enabled */ > + if ( dt_match_node(scmi_matches, node) && !sci_domain_is_enabled(d) ) > + { > + dt_dprintk(" Skip scmi node\n"); > + return true; > + } > + > + return false; > +} > + > +static int scmi_assign_device(uint32_t agent_id, uint32_t device_id, > + uint32_t flags) > +{ > + struct scmi_msg_base_set_device_permissions_a2p tx; > + struct scmi_channel *channel; > + scmi_msg_header_t hdr; > + > + channel = get_channel_by_id(scmi_data.hyp_channel_agent_id); > + if ( !channel ) > + return -EINVAL; > + > + hdr.id = SCMI_BASE_SET_DEVICE_PERMISSIONS; > + hdr.type = 0; > + hdr.protocol = SCMI_BASE_PROTOCOL; > + > + tx.agent_id = agent_id; > + tx.device_id = device_id; > + tx.flags = flags; > + > + return do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0); > +} > + > +static int scmi_dt_assign_device(struct domain *d, > + struct dt_phandle_args *ac_spec) > +{ > + struct scmi_channel *agent_channel; > + uint32_t scmi_device_id = ac_spec->args[0]; > + int ret; > + > + if ( !d->arch.sci_data ) > + return 0; > + > + /* The access-controllers is specified for DT dev, but it's not a SCMI */ > + if ( !scmi_data.dt_dev || > + !dt_node_path_is_equal(ac_spec->np, scmi_data.dt_dev->full_name) ) > + return 0; > + > + agent_channel = d->arch.sci_data; > + > + spin_lock(&agent_channel->lock); > + > + ret = scmi_assign_device(agent_channel->agent_id, scmi_device_id, > + SCMI_BASE_DEVICE_ACCESS_ALLOW); > + if ( ret ) > + { > + printk(XENLOG_ERR > + "scmi: could not assign dev for %pd agent:%d dev_id:%u (%d)", > + d, agent_channel->agent_id, scmi_device_id, ret); > + } > + > + spin_unlock(&agent_channel->lock); > + return ret; > +} > + > +static int collect_agent_id(struct scmi_channel *agent_channel) > +{ > + int ret; > + scmi_msg_header_t hdr; > + struct scmi_msg_base_discover_agent_p2a da_rx; > + struct scmi_msg_base_discover_agent_a2p da_tx; > + > + ret = map_channel_memory(agent_channel); > + if ( ret ) > + return ret; > + > + hdr.id = SCMI_BASE_DISCOVER_AGENT; > + hdr.type = 0; > + hdr.protocol = SCMI_BASE_PROTOCOL; > + > + da_tx.agent_id = agent_channel->agent_id; > + > + ret = do_smc_xfer(agent_channel, &hdr, &da_tx, sizeof(da_tx), &da_rx, > + sizeof(da_rx)); > + if ( agent_channel->domain_id != DOMID_XEN ) > + unmap_channel_memory(agent_channel); > + if ( ret ) > + return ret; On error (ret != 0) should we call unmap_channel_memory ? > + printk(XENLOG_DEBUG "id=0x%x name=%s\n", da_rx.agent_id, da_rx.name); > + agent_channel->agent_id = da_rx.agent_id; > + return 0; > +} > + > +static __init int collect_agents(struct dt_device_node *scmi_node) > +{ > + const struct dt_device_node *config_node; > + const __be32 *prop; > + uint32_t len; > + const __be32 *end; > + uint32_t cells_per_entry = 3; /* Default to 3 cells if property is absent. */ > + > + config_node = dt_find_compatible_node(NULL, NULL, "xen,sci"); > + if ( !config_node ) > + { > + printk(XENLOG_WARNING "scmi: xen,sci node not found, no agents to collect.\n"); > + return -ENOENT; > + } > + > + /* Check for the optional '#scmi-secondary-agents-cells' property. */ > + if ( dt_property_read_u32(config_node, "#scmi-secondary-agents-cells", > + &cells_per_entry) ) > + { > + if ( cells_per_entry != 2 && cells_per_entry != 3 ) > + { > + printk(XENLOG_ERR "scmi: Invalid #scmi-secondary-agents-cells value: %u\n", > + cells_per_entry); > + return -EINVAL; > + } > + } > + > + prop = dt_get_property(config_node, SCMI_SECONDARY_AGENTS, &len); > + if ( !prop ) > + { > + printk(XENLOG_ERR "scmi: No %s property found, no agents to collect.\n", > + SCMI_SECONDARY_AGENTS); > + return -EINVAL; > + } > + > + /* Validate that the property length is a multiple of the cell size. */ > + if ( len == 0 || len % (cells_per_entry * sizeof(uint32_t)) != 0 ) > + { > + printk(XENLOG_ERR "scmi: Invalid length of %s property: %u for %u cells per entry\n", > + SCMI_SECONDARY_AGENTS, len, cells_per_entry); > + return -EINVAL; > + } > + > + end = (const __be32 *)((const u8 *)prop + len); > + > + for ( ; prop < end; ) > + { > + uint32_t agent_id; > + uint32_t smc_id; > + uint32_t shmem_phandle; > + struct dt_device_node *node; > + u64 addr, size; > + int ret; > + struct scmi_channel *agent_channel; > + > + smc_id = be32_to_cpu(*prop++); > + shmem_phandle = be32_to_cpu(*prop++); > + > + if ( cells_per_entry == 3 ) > + agent_id = be32_to_cpu(*prop++); > + else > + agent_id = SCMI_BASE_AGENT_ID_OWN; > + > + node = dt_find_node_by_phandle(shmem_phandle); > + if ( !node ) > + { > + printk(XENLOG_ERR "scmi: Could not find shmem node for agent %u\n", > + agent_id); > + return -EINVAL; > + } > + > + ret = dt_device_get_address(node, 0, &addr, &size); > + if ( ret ) > + { > + printk(XENLOG_ERR > + "scmi: Could not read shmem address for agent %u: %d\n", > + agent_id, ret); > + return ret; > + } > + > + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) ) > + { > + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); > + return -EINVAL; > + } > + > + agent_channel = smc_create_channel(agent_id, smc_id, addr); > + if ( IS_ERR(agent_channel) ) > + { > + printk(XENLOG_ERR "scmi: Could not create channel for agent %u: %ld\n", > + agent_id, PTR_ERR(agent_channel)); > + return PTR_ERR(agent_channel); > + } > + > + if ( cells_per_entry == 2 ) > + { > + ret = collect_agent_id(agent_channel); > + if ( ret ) > + return ret; > + } > + > + printk(XENLOG_DEBUG "scmi: Agent %u SMC %X addr %lx\n", agent_channel->agent_id, > + smc_id, (unsigned long)addr); > + } > + > + return 0; > +} > + > +static int scmi_domain_init(struct domain *d, > + struct xen_domctl_createdomain *config) > +{ > + struct scmi_channel *channel; > + int ret; > + > + if ( !scmi_data.initialized ) > + return 0; > + > + /* > + * SCMI support is configured via: > + * - For dom0: xen,dom0-sci-agent-id property under the xen,sci container > + * - For dom0less: xen,sci-agent-id in the domain node > + * The config->arch.arm_sci_type and config->arch.arm_sci_agent_id > + * are already set by domain_build.c or dom0less-build.c > + */ > + > + if ( config->arch.arm_sci_type == XEN_DOMCTL_CONFIG_ARM_SCI_NONE ) > + return 0; > + > + channel = acquire_scmi_channel(d, config->arch.arm_sci_agent_id); > + if ( IS_ERR(channel) ) > + { > + printk(XENLOG_ERR > + "scmi: Failed to acquire SCMI channel for agent_id %u: %ld\n", > + config->arch.arm_sci_agent_id, PTR_ERR(channel)); > + return PTR_ERR(channel); > + } > + > + printk(XENLOG_INFO > + "scmi: Acquire channel id = 0x%x, domain_id = %d paddr = 0x%lx\n", > + channel->agent_id, channel->domain_id, channel->paddr); > + > + /* > + * Dom0 (if present) needs to have an access to the guest memory range > + * to satisfy iomem_access_permitted() check in XEN_DOMCTL_iomem_permission > + * domctl. > + */ > + if ( hardware_domain && !is_hardware_domain(d) ) > + { > + ret = iomem_permit_access(hardware_domain, paddr_to_pfn(channel->paddr), > + paddr_to_pfn(channel->paddr + PAGE_SIZE - 1)); it doesn't take into account the size of the region > + if ( ret ) > + goto error; > + } > + > + d->arch.sci_data = channel; > + d->arch.sci_enabled = true; > + > + return 0; > + > +error: > + relinquish_scmi_channel(channel); > + return ret; > +} > + > +int scmi_domain_sanitise_config(struct xen_domctl_createdomain *config) > +{ > + if ( config->arch.arm_sci_type != XEN_DOMCTL_CONFIG_ARM_SCI_NONE && > + config->arch.arm_sci_type != XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA ) > + { > + dprintk(XENLOG_INFO, "scmi: Unsupported ARM_SCI type\n"); > + return -EINVAL; > + } > + > + return 0; > +} > + > +static int scmi_relinquish_resources(struct domain *d) > +{ > + int ret; > + struct scmi_channel *channel, *agent_channel; > + scmi_msg_header_t hdr; > + struct scmi_msg_base_reset_agent_cfg_a2p tx; > + > + if ( !d->arch.sci_data ) > + return 0; > + > + agent_channel = d->arch.sci_data; > + > + spin_lock(&agent_channel->lock); > + tx.agent_id = agent_channel->agent_id; > + spin_unlock(&agent_channel->lock); > + > + channel = get_channel_by_id(scmi_data.hyp_channel_agent_id); > + if ( !channel ) > + { > + printk(XENLOG_ERR > + "scmi: Unable to get Hypervisor scmi channel for domain %d\n", > + d->domain_id); > + return -EINVAL; > + } > + > + hdr.id = SCMI_BASE_RESET_AGENT_CONFIGURATION; > + hdr.type = 0; > + hdr.protocol = SCMI_BASE_PROTOCOL; > + > + tx.flags = SCMI_BASE_AGENT_PERMISSIONS_RESET; > + > + ret = do_smc_xfer(channel, &hdr, &tx, sizeof(tx), NULL, 0); > + if ( ret == -EOPNOTSUPP ) > + return 0; > + > + return ret; > +} > + > +static void scmi_domain_destroy(struct domain *d) > +{ > + struct scmi_channel *channel; > + > + if ( !d->arch.sci_data ) > + return; > + > + channel = d->arch.sci_data; > + spin_lock(&channel->lock); > + > + relinquish_scmi_channel(channel); > + printk(XENLOG_DEBUG "scmi: Free domain %d\n", d->domain_id); > + > + d->arch.sci_data = NULL; > + d->arch.sci_enabled = false; > + > + spin_unlock(&channel->lock); > +} > + > +static bool scmi_handle_call(struct cpu_user_regs *regs) > +{ > + uint32_t fid = (uint32_t)get_user_reg(regs, 0); > + struct scmi_channel *agent_channel; > + struct domain *d = current->domain; > + struct arm_smccc_res resp; > + bool res = false; > + > + if ( !sci_domain_is_enabled(d) ) > + return false; missing d->arch.sci_data != NULL check > + agent_channel = d->arch.sci_data; > + spin_lock(&agent_channel->lock); > + > + if ( agent_channel->func_id != fid ) > + { > + res = false; > + goto unlock; > + } > + > + arm_smccc_1_1_smc(fid, > + get_user_reg(regs, 1), > + get_user_reg(regs, 2), > + get_user_reg(regs, 3), > + get_user_reg(regs, 4), > + get_user_reg(regs, 5), > + get_user_reg(regs, 6), > + get_user_reg(regs, 7), > + &resp); > + > + set_user_reg(regs, 0, resp.a0); > + set_user_reg(regs, 1, resp.a1); > + set_user_reg(regs, 2, resp.a2); > + set_user_reg(regs, 3, resp.a3); > + res = true; > +unlock: > + spin_unlock(&agent_channel->lock); > + > + return res; > +} > + > +static const struct sci_mediator_ops scmi_ops = { > + .domain_init = scmi_domain_init, > + .domain_destroy = scmi_domain_destroy, > + .relinquish_resources = scmi_relinquish_resources, > + .handle_call = scmi_handle_call, > + .dom0_dt_handle_node = scmi_dt_handle_node, > + .domain_sanitise_config = scmi_domain_sanitise_config, > + .assign_dt_device = scmi_dt_assign_device, > +}; > + > +static int __init scmi_check_smccc_ver(void) > +{ > + if ( smccc_ver < ARM_SMCCC_VERSION_1_1 ) > + { > + printk(XENLOG_WARNING > + "scmi: No SMCCC 1.1 support, SCMI calls forwarding disabled\n"); > + return -ENOSYS; > + } > + > + return 0; > +} > + > +static int __init scmi_dt_hyp_channel_read(struct dt_device_node *scmi_node, > + struct scmi_data *scmi_data, > + u64 *addr) > +{ > + int ret; > + u64 size; > + > + if ( !dt_property_read_u32(scmi_node, "arm,smc-id", &scmi_data->func_id) ) > + { > + printk(XENLOG_ERR "scmi: unable to read smc-id from DT\n"); > + return -ENOENT; > + } > + > + ret = scmi_dt_read_hyp_channel_addr(scmi_node, addr, &size); > + if ( IS_ERR_VALUE(ret) ) > + return -ENOENT; > + > + if ( !IS_ALIGNED(size, SCMI_SHMEM_MAPPED_SIZE) ) > + { > + printk(XENLOG_ERR "scmi: shmem memory is not aligned\n"); > + return -EINVAL; > + } should we check for alignment of addr? > + return 0; > +} > + > +static __init int scmi_probe(struct dt_device_node *scmi_node, const void *data) > +{ > + u64 addr; > + int ret; > + struct scmi_channel *channel; > + unsigned int n_agents; > + scmi_msg_header_t hdr; > + struct scmi_msg_base_attributes_p2a rx; > + > + ASSERT(scmi_node != NULL); > + > + /* > + * Only bind to the SCMI node provided by Xen under the xen,sci container > + * (e.g. /chosen/xen/xen_scmi_config/scmi). This avoids binding to firmware > + * SCMI nodes that belong to the host OSPM and keeps the mediator scoped to > + * Xen-provided configuration only. > + */ > + if ( !scmi_is_under_xen_sci(scmi_node) ) > + return -ENODEV; > + > + INIT_LIST_HEAD(&scmi_data.channel_list); > + spin_lock_init(&scmi_data.channel_list_lock); > + > + if ( !acpi_disabled ) > + { > + printk(XENLOG_WARNING "scmi: is not supported when using ACPI\n"); > + return -EINVAL; > + } > + > + ret = scmi_check_smccc_ver(); > + if ( ret ) > + return ret; > + > + ret = scmi_dt_hyp_channel_read(scmi_node, &scmi_data, &addr); > + if ( ret ) > + return ret; > + > + scmi_data.dt_dev = scmi_node; > + > + channel = smc_create_channel(SCMI_BASE_AGENT_ID_OWN, scmi_data.func_id, addr); > + if ( IS_ERR(channel) ) we are losing the error code > + goto out; > + > + /* Mark as Xen management channel before collecting agent ID */ > + channel->domain_id = DOMID_XEN; > + > + /* Request agent id for Xen management channel */ > + ret = collect_agent_id(channel); > + if ( ret ) > + goto error; > + > + /* Save the agent id for Xen management channel */ > + scmi_data.hyp_channel_agent_id = channel->agent_id; > + > + hdr.id = SCMI_BASE_PROTOCOL_ATTIBUTES; > + hdr.type = 0; > + hdr.protocol = SCMI_BASE_PROTOCOL; > + > + ret = do_smc_xfer(channel, &hdr, NULL, 0, &rx, sizeof(rx)); > + if ( ret ) > + goto error; > + > + n_agents = SCMI_FIELD_GET(SCMI_BASE_ATTR_NUM_AGENT, rx.attributes); > + printk(XENLOG_DEBUG "scmi: Got agent count %d\n", n_agents); > + ret = collect_agents(scmi_node); > + if ( ret ) > + goto error; > + > + ret = sci_register(&scmi_ops); > + if ( ret ) > + { > + printk(XENLOG_ERR "SCMI: mediator already registered (ret = %d)\n", > + ret); > + return ret; > + } > + > + scmi_data.initialized = true; > + goto out; > + > +error: > + unmap_channel_memory(channel); > + free_channel_list(); > +out: > + return ret; > +} > + > +static const struct dt_device_match scmi_smc_match[] __initconst = { > + DT_MATCH_COMPATIBLE("arm,scmi-smc"), > + { /* sentinel */ }, > +}; > + > +DT_DEVICE_START(scmi_smc_ma, "SCMI SMC MEDIATOR", DEVICE_FIRMWARE) > + .dt_match = scmi_smc_match, > + .init = scmi_probe, > +DT_DEVICE_END > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * tab-width: 4 > + * indent-tabs-mode: nil > + * End: > + */ > diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h > index d30a288592..8f0f68544e 100644 > --- a/xen/include/public/arch-arm.h > +++ b/xen/include/public/arch-arm.h > @@ -329,6 +329,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t); > > #define XEN_DOMCTL_CONFIG_ARM_SCI_NONE 0 > #define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC 1 > +#define XEN_DOMCTL_CONFIG_ARM_SCI_SCMI_SMC_MA 2 > > struct xen_arch_domainconfig { > /* IN/OUT */ > @@ -355,6 +356,8 @@ struct xen_arch_domainconfig { > uint32_t clock_frequency; > /* IN */ > uint8_t arm_sci_type; > + /* IN */ > + uint8_t arm_sci_agent_id; > }; > #endif /* __XEN__ || __XEN_TOOLS__ */ > > -- > 2.34.1 > From xen-devel-bounces@lists.xenproject.org Fri Jan 30 00:23:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Jan 2026 00:23:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217137.1526947 (Exim 4.92) (envelope-from ) id 1vlcIW-0003vh-1E; Fri, 30 Jan 2026 00:23:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217137.1526947; Fri, 30 Jan 2026 00:23:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlcIV-0003va-Ui; Fri, 30 Jan 2026 00:23:39 +0000 Received: by outflank-mailman (input) for mailman id 1217137; Fri, 30 Jan 2026 00:23:39 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlcIU-0003vU-T1 for xen-devel@lists.xenproject.org; Fri, 30 Jan 2026 00:23: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 e889b48f-fd71-11f0-9ccf-f158ae23cfc8; Fri, 30 Jan 2026 01:23:33 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 711E36001A; Fri, 30 Jan 2026 00:23:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 917A5C4CEF7; Fri, 30 Jan 2026 00:23: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: e889b48f-fd71-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769732611; bh=MEltI2cCPlssu2KOL0WlU661UsBIBmLJ9wAmtTzzN/0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=F43u8TYUQzArOQQSzsEZQW7znFd/B+e/tAtYQgZ9gFo6p3th0sLinocJ8KegfdYiB Jr+N7/WtUqGeImdEhanLY1YdTcTSCm3dSK9EFsaShYGHGokcdyywNLz5VJEM3bxxp5 jHOZ9tpPmQakOSb9tzyM1uIrIz2vFjoYkhWMd0SpRpjq94e27QBGGwSxTWsjfwOb7T ZRT8iD/VKvEs+ALeLZ9Cl/q8zkC4zii7KgQ5fa5+olKu9Xjl5mS54PSyUxDpqFY+D7 ioGf+36s6+TS21rkQxr8rnNnEjkw+IvbqCyX8AoolgxqNAkItK1wC5yop40ETP64Pg zB1jep9MOYcCg== Date: Thu, 29 Jan 2026 16:23:28 -0800 (PST) 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 v9 5/5] docs: arm: add SCI SCMI SMC multi-agent driver docs In-Reply-To: <9a95d21c212013b8e76f20a0248e94108512c94f.1769696107.git.oleksii_moisieiev@epam.com> Message-ID: References: <9a95d21c212013b8e76f20a0248e94108512c94f.1769696107.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 Thu, 29 Jan 2026, Oleksii Moisieiev wrote: > From: Grygorii Strashko > > Add SCI SCMI SMC multi-agent driver documentation. > It includes a detailed description of the SCMI multi-agent driver. > This document explains the driver's functionality, configuration, > and the compilation process. The Xen SCMI multi-agent driver is > designed to provide SCMI access to system resources from different > domains. > > Signed-off-by: Grygorii Strashko > Signed-off-by: Oleksii Moisieiev > --- > > (no changes since v8) > > Changes in v8: > - update documentation to match the last DT format > - fixed RST: "... code-block:: dts" -> ".. code-block:: dts" > - update documentation with dom0less configuration example > - update documentation with new param xen,dom0-sci-agent-id > instead of the command line parameter > > Changes in v7: > - update documentation in section of the xen_scmi configuration which > is matched by "xen,sci" compatible instead of the direct path. > > Changes in v6: > - remove all HVC mentions from the multi-agent doc > - update sci-agent-id parameter description in the documentation > - add missing Sign-of > - minor fixes across the document > > Changes in v5: > - rework multi-agent driver to leave Host Device-tree unmodified > > .../arm/firmware/arm-scmi.rst | 420 ++++++++++++++++++ > 1 file changed, 420 insertions(+) > > diff --git a/docs/hypervisor-guide/arm/firmware/arm-scmi.rst b/docs/hypervisor-guide/arm/firmware/arm-scmi.rst > index d9698f4e4b..2497a870f3 100644 > --- a/docs/hypervisor-guide/arm/firmware/arm-scmi.rst > +++ b/docs/hypervisor-guide/arm/firmware/arm-scmi.rst > @@ -36,6 +36,8 @@ The below sections describe SCMI support options available for Xen. > > | [1] `Arm SCMI `_ > | [2] `System Control and Management Interface (SCMI) bindings `_ > +| [3] `Generic Domain Access Controllers bindings `_ > + > > Simple SCMI over SMC calls forwarding driver (EL3) > ------------------------------------------------------ > @@ -189,3 +191,421 @@ except explicitly enabling SCMI with "arm_sci" xl.cfg option. > -> xen,reg = <0x0 0x47ff0000 0x0 0x1000 0x0 0x22001000>; > -> xen,force-assign-without-iommu; > }; > + > +SCMI SMC multi-agent driver (EL3) > +------------------------------------- > + > +The SCMI SMC multi-agent driver enables support for ARM EL3 Trusted Firmware-A (TF-A) which > +provides SCMI interface with multi-agent support, as shown below. > + > +:: > + > + +-----------------------------------------+ > + | | > + | EL3 TF-A SCMI | > + +-------+--+-------+--+-------+--+-------++ > + |shmem1 | |shmem0 | |shmem2 | |shmemX | > + +-----+-+ +---+---+ +--+----+ +---+---+ > + smc-id1 | | | | > + agent1 | | | | > + +-----v--------+---------+-----------+----+ > + | | | | | > + | | | | | > + +--------------+---------+-----------+----+ > + smc-id0 | smc-id2| smc-idX| > + agent0 | agent2 | agentX | > + | | | > + +----v---+ +--v-----+ +--v-----+ > + | | | | | | > + | Dom0 | | Dom1 | | DomX | > + | | | | | | > + | | | | | | > + +--------+ +--------+ +--------+ > + > +The EL3 SCMI multi-agent firmware is expected to provide SCMI SMC shared-memory transport > +for every Agent in the system. The SCMI Agent transport channel defined by pair: > + > +- smc-id: SMC function id used for Doorbell > +- shmem: shared memory for messages transfer, **Xen page aligned**. > + Shared memory is mapped with the following flags: MT_DEVICE_nGnRE and _PAGE_DEVICE, indicating that this > + memory is mapped as device memory. > + > +The following SCMI Agents are expected to be defined by SCMI FW to enable SCMI multi-agent functionality > +under Xen: > + > +- Xen management agent: trusted agents that accesses to the Base Protocol commands to configure > + agent specific permissions > +- OSPM VM agents: non-trusted agent, one for each Guest domain which is allowed direct HW access. > + At least one OSPM VM agent has to be provided by FW if HW is handled only by Dom0 or Driver Domain. > + > +The EL3 SCMI FW is expected to implement following Base protocol messages: > + > +- BASE_DISCOVER_AGENT (optional if agent_id was provided) > +- BASE_RESET_AGENT_CONFIGURATION (optional) > +- BASE_SET_DEVICE_PERMISSIONS (optional) > + > +The number of supported SCMI agents and their transport specifications are SCMI FW implementation > +specific. > + > +Compiling with multi-agent support > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > +To build with the SCMI SMC multi-agent driver support, enable Kconfig option: > + > +:: > + > + CONFIG_SCMI_SMC_MA > + > + > +Driver functionality > +^^^^^^^^^^^^^^^^^^^^ > + > +The SCI SCMI SMC multi-agent driver implements following functionality: > + > +- The driver is initialized from the Xen SCMI container ``xen_scmi_config`` > + under ``/chosen/xen`` (for example ``/chosen/xen/xen_scmi_config/scmi``). > + Only one SCMI interface is supported. The SCMI configuration must live under > + the Xen SCMI container ``xen,sci`` beneath ``/chosen``. > + The Xen SCMI mediator will bind only to the "arm,scmi-smc" node that is a child of > + this "xen,sci" container; any other "arm,scmi-smc" nodes (for example under > + "/firmware") are ignored to avoid stealing the host's SCMI OSPM instance. > + > +.. code-block:: dts > + > + scmi_shm_1: sram@47ff1000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x47ff1000 0x0 0x1000>; > + }; > + scmi_xen: scmi { > + compatible = "arm,scmi-smc"; > + arm,smc-id = <0x82000003>; <--- Xen management agent smc-id > + #address-cells = < 1>; > + #size-cells = < 0>; > + #access-controller-cells = < 1>; > + shmem = <&scmi_shm_1>; <--- Xen management agent shmem > + }; > + > +.. note:: > + This layout keeps the Host DT unchanged for Dom0 and baremetal Linux by > + using func_id 0x82000002 / shmem 0x47ff0000 for Dom0, while Xen uses a > + separate privileged channel func_id 0x82000003 / shmem 0x47ff1000. EL3 > + firmware enforces permissions per agent_id, so there is no conflict between > + Dom0 and Xen channels. > + > +- The driver obtains Xen specific SCMI Agent's configuration from the Host DT, probes Agents and > + builds SCMI Agents list. The Agents configuration is taken from "scmi-secondary-agents" > + property where first item is "arm,smc-id", second - "arm,scmi-shmem" phandle and third is > + optional "agent_id": > + > +.. code-block:: dts > + > + chosen { > + ranges; <--- set default ranges so address can be translated when parsing scmi_shm node > + xen { > + ranges; > + xen_scmi_config { > + compatible = "xen,sci"; > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; <--- set default ranges so address can be translated when parsing scmi_shm node > + scmi-secondary-agents = < > + 0x82000002 &scmi_shm_0 0 > + 0x82000004 &scmi_shm_2 2 > + 0x82000005 &scmi_shm_3 3 > + 0x82000006 &scmi_shm_4 4>; > + #scmi-secondary-agents-cells = <3>; <--- optional, default 3 > + xen,dom0-sci-agent-id = <0>; /* Dom0 agent ID */ > + > + scmi_shm_0 : sram@47ff0000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x47ff0000 0x0 0x1000>; > + }; > + > + scmi_shm_2: sram@47ff2000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x47ff2000 0x0 0x1000>; > + }; > + scmi_shm_3: sram@47ff3000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x47ff3000 0x0 0x1000>; > + }; > + scmi_shm_4: sram@47ff4000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x47ff4000 0x0 0x1000>; > + }; > + > + // Xen SCMI management channel > + scmi_shm_1: sram@47ff1000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x47ff1000 0x0 0x1000>; > + }; > + > + scmi_xen: scmi { > + compatible = "arm,scmi-smc"; > + arm,smc-id = <0x82000003>; <--- Xen management agent smc-id > + #address-cells = < 1>; > + #size-cells = < 0>; > + #access-controller-cells = < 1>; > + shmem = <&scmi_shm_1>; <--- Xen management agent shmem > + }; > + }; > + }; > + }; > + > + /{ > + // Host SCMI OSPM channel - provided to the Dom0 as is if SCMI enabled for it > + scmi_shm: sram@47ff0000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x47ff0000 0x0 0x1000>; > + }; > + > + firmware { > + scmi: scmi { > + compatible = "arm,scmi-smc"; > + arm,smc-id = <0x82000002>; <--- Host OSPM agent smc-id > + #address-cells = < 1>; > + #size-cells = < 0>; > + shmem = <&scmi_shm>; <--- Host OSPM agent shmem > + > + protocol@X{ > + }; > + }; > + }; > + }; > + > + This approach allows defining multiple SCMI Agents by adding Xen-specific properties under > + the ``/chosen`` node to the Host Device Tree, leaving the main part unchanged. The Host DT > + SCMI channel will be passed to Dom0. > + > + The Xen management agent is described as a ``scmi_xen`` node under the ``xen,sci`` compatible node, > + which is used by Xen to control other SCMI Agents in the system. > + > + All secondary agents' configurations are provided in the ``scmi-secondary-agents`` property with > + an optional ``agent_id`` field. > + > + The ``agent_id`` from the ``scmi-secondary-agents`` property is used to identify the agent in the > + system and can be omitted by setting ``#scmi-secondary-agents-cells = <2>``, so the Secondary > + Agents configuration will look like this: > + > +.. code-block:: dts > + > + chosen { > + xen { > + xen_scmi_config { > + compatible = "xen,sci"; > + scmi-secondary-agents = < > + 0x82000002 &scmi_shm_0 > + 0x82000004 &scmi_shm_2 > + 0x82000005 &scmi_shm_3 > + 0x82000006 &scmi_shm_4>; > + #scmi-secondary-agents-cells = <2>; > + }; > + }; > + } > + > + In this case, Xen will use the ``SCMI_BASE_DISCOVER_AGENT`` call to discover the ``agent_id`` > + for each secondary agent. Providing the ``agent_id`` in the ``scmi-secondary-agents`` property > + allows skipping the discovery call, which is useful when the secondary agent's shared memory is > + not accessible by Xen or when boot time is important because it allows skipping the agent > + discovery procedure. > + > +.. note:: > + > + Note that Xen is the only one entry in the system which need to know about SCMI multi-agent support. > + > +- The driver implements the SCI subsystem interface required for configuring and enabling SCMI > + functionality for Dom0/hwdom and Guest domains. To enable SCMI functionality for guest domain > + it has to be configured with unique supported SCMI Agent_id and use corresponding SCMI SMC > + shared-memory transport ``[smc-id, shmem]`` defined for this SCMI Agent_id. > + > +- Once Xen domain is configured it can communicate with EL3 SCMI FW: > + > + - zero-copy, the guest domain puts/gets SCMI message in/from shmem; > + - the guest triggers SMC exception with agent "smc-id" (doorbell); > + - the Xen driver catches exception, do checks and synchronously forwards it to EL3 FW. > + > +- the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen management agent channel on > + domain destroy event. This allows to reset resources used by domain and so implement use-case > + like domain reboot. > + > + > +Configure SCMI for Dom0 > +^^^^^^^^^^^^^^^^^^^^^^^ > +Set the Dom0 SCMI agent ID in the device tree using the Xen SCMI container under ``/chosen``. > +Add ``xen,dom0-sci-agent-id`` to the ``xen,sci`` node. If the property is absent, SCMI stays > +disabled for Dom0 and the SCMI nodes are removed from Dom0 DT. > + > +.. code-block:: dts > + > + chosen { > + xen { > + ranges; > + xen_scmi_config { > + compatible = "xen,sci"; > + xen,dom0-sci-agent-id = <0>; /* Dom0 agent ID */ > + /* scmi-secondary-agents and scmi_xen as shown above */ > + }; > + }; > + }; > + > +Xen utilizes the Host DT ``/firmware/scmi`` node to configure the Dom0 SCMI agent, leaving the > +rest of the Host DT unchanged except for the Xen-specific properties under ``/chosen``. If the > +``/firmware/scmi`` node is missing or disabled, the Dom0 SCMI agent will not be configured. It might be good to clarify that actually /firmware/scmi is simply copied to the Dom0 DT unmodified. However, for Dom0 SCMI configuration, Xen actually relies on scmi-secondary-agents and xen,dom0-sci-agent-id. > +.. note:: > + > + The ``xen,dom0-sci-agent-id`` value must match the ``func_id`` and ``shmem`` pairing provided by > + the EL3 firmware for Dom0 (for example in the ``/firmware/scmi`` node). > + > +Configure SCMI for for guest domain with toolstack > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > +* In domain's xl.cfg file add **"arm_sci"** option as below > + > +:: > + > + arm_sci = "type=scmi_smc_multiagent,agent_id=2" > + > +* In domain's xl.cfg file enable access to the "arm,scmi-shmem" which should correspond > + assigned "agent_id" for the domain, for example: > + > +:: > + > + iomem = [ > + "47ff2,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. > + The "arm,smc-id" should correspond assigned agent_id for the domain: > + > +.. code:: > + > + passthrough { > + scmi_shm_0: sram@22001000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x22001000 0x0 0x1000>; > + }; > + > + firmware { > + compatible = "simple-bus"; > + scmi: scmi { > + compatible = "arm,scmi-smc"; > + arm,smc-id = <0x82000004>; <--- smc-id for agent_id=2 > + shmem = <&scmi_shm_0>; > + ... > + } > + } > + } > + > +**Device specific access control** > + > +The XEN SCMI SMC multi-agent driver performs "access-controller" provider function in case > +EL3 SCMI FW implements SCMI "4.2.1.1 Device specific access control" and provides the > +BASE_SET_DEVICE_PERMISSIONS command to configure the devices that an agents have access to. > +The Host DT SCMI node should have "#access-controller-cells=<1>" property and DT devices should > +be bound to the SCMI node using Access Controllers bindings [3]. > + > +For example: > + > +.. code-block:: dts > + > + &i2c1 { > + access-controllers = <&scmi 0>; > + }; > + > +Use domain's xl.cfg file **"dtdev"** property to assign SCMI devices from toolstack to the guest: > + > +:: > + > + dtdev = [ > + "/soc/i2c@e6508000", > + ] > + > +.. note:: > + > + xl.cfg:"dtdev" need contain all nodes which are under SCMI management (not only those which are > + behind IOMMU) and passed-through to the guest domain. > + > +Configure SCMI for predefined domains (dom0less) > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > +* add "xen,sci_type" and "xen,sci-agent-id" properties for required DomU ("xen,domain") node > + > +:: > + > + xen,sci_type="scmi_smc_multiagent" > + xen,sci-agent-id=2 > + > +* add scmi nodes to the Driver domain partial device tree the same way as above (toolstack case) and > + enable access to the "arm,scmi-shmem" according to the dom0less documentation. For example: > + > +.. code-block:: dts > + > + scmi_shm_0: sram@22001000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x00 0x22001000 0x00 0x1000>; > + -> xen,reg = <0x0 0x47ff0000 0x0 0x1000 0x0 0x22001000>; this should be 0x47ff2000 ? > + -> xen,force-assign-without-iommu; > + }; > + > +* For SCMI device access control configure pass-through devices in the guest partial DT according to > + the dom0less documentation and ensure that devices SCMI management has "xen,path" property set: > + > +Example (dom0less, multi-agent): > + > +.. code-block:: dts > + > + chosen { > + xen { > + ranges; > + xen_scmi_config { > + compatible = "xen,sci"; > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + > + /* Xen management channel shared memory */ > + scmi_shm_1: sram@47ff1000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x47ff1000 0x0 0x1000>; > + }; > + > + scmi_shm_domu: sram@47ff2000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x0 0x47ff2000 0x0 0x1000>; > + }; > + > + scmi-secondary-agents = < > + 0x82000004 &scmi_shm_domu 2>; > + #scmi-secondary-agents-cells = <3>; > + > + scmi_xen: scmi { > + compatible = "arm,scmi-smc"; > + arm,smc-id = <0x82000003>; > + #address-cells = <1>; > + #size-cells = <0>; > + #access-controller-cells = <1>; > + shmem = <&scmi_shm_1>; > + }; > + }; > + }; > + > + xen,domain@1 { > + compatible = "xen,domain"; > + xen,sci_type = "scmi_smc_multiagent"; > + xen,sci-agent-id = <2>; > + /* other domain properties here */ > + }; > + }; > + > +.. code-block:: dts > + > + i2c@e6508000 { > + ... > + reg = <0x00 0xe6508000 0x00 0x1000>; > + -> xen,path = "/soc/i2c@e6508000" > + -> xen,reg = <0x0 0xe6508000 0x0 0x1000 0x0 0xe6508000>; > + -> xen,force-assign-without-iommu; > + }; > -- > 2.34.1 > From xen-devel-bounces@lists.xenproject.org Fri Jan 30 00:37:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Jan 2026 00:37:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217147.1526958 (Exim 4.92) (envelope-from ) id 1vlcW6-0005lu-6d; Fri, 30 Jan 2026 00:37:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217147.1526958; Fri, 30 Jan 2026 00:37:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlcW6-0005lm-2Y; Fri, 30 Jan 2026 00:37:42 +0000 Received: by outflank-mailman (input) for mailman id 1217147; Fri, 30 Jan 2026 00:37:41 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlcW4-0005lg-Vp for xen-devel@lists.xenproject.org; Fri, 30 Jan 2026 00:37:40 +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 e065cda9-fd73-11f0-b160-2bf370ae4941; Fri, 30 Jan 2026 01:37:38 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id F24556001A; Fri, 30 Jan 2026 00:37:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D8C4C16AAE; Fri, 30 Jan 2026 00:37: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: e065cda9-fd73-11f0-b160-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769733456; bh=i0keCIhFda6evaNyBPFwQYFrGOnQMP6B8Lxs5pCR4fE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Ul992zkoV82eQRq/lmxNRfzCu1VDbDPUryinRwaRPoEgMMulEBR3kBbSbvmiFWqtr VqCl+6/f6qvqHWSTk8V2Wa2jgXvRURFHsfuQT7x10FXEpr98K3yevDUsYbmFIXSEls yPyGeavpQr6tDCZG/oILANa0zi4VYkuI8xzme5fjutbP+gU5u97Kckm7e2FAuMwaGL hG6eWt614TzIVhLUflAQXN8l8a7TP/PKnNN89X8tUCa/S5i8cgf57MHFLUAGGqZVnM G1MF7fWma740+VN/2Qit2vO+T2X7ETWew7DQdwK4JD6/NUobUxUPXCCVRZ110qlVPT rXEN+/g5bp2/A== Date: Thu, 29 Jan 2026 16:37:34 -0800 (PST) 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 v4] xen/domain: introduce DOMID_ANY In-Reply-To: <20260109140747.195460-2-dmukhin@ford.com> Message-ID: References: <20260109140747.195460-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, 9 Jan 2026, dmukhin@xen.org wrote: > From: Denis Mukhin > > Add a new symbol DOMID_ANY 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 I think it improves readability and this new version addresses Roger's concerns as far as I can tell. One minor comment: domid_alloc effectively still accept DOMID_INVALID to say "give me any DOMID" although it is no longer documented or used. If we wanted to enforce a different behavior between DOMID_INVALID and DOMID_ANY we would need to modify domid_alloc. However, I think this patch is sufficient as it is: Reviewed-by: Stefano Stabellini > --- > Changes since v3: > - new value for DOMID_ANY instead of aliasing DOMID_INVALID > - Link to v3: https://lore.kernel.org/xen-devel/20250924030630.122229-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..65da0d075a2b 100644 > --- a/tools/tests/domid/harness.h > +++ b/tools/tests/domid/harness.h > @@ -41,6 +41,7 @@ extern unsigned long find_next_zero_bit(const unsigned long *addr, > > #define DOMID_FIRST_RESERVED (100) > #define DOMID_INVALID (101) > +#define DOMID_ANY (102) > > #endif /* _TEST_HARNESS_ */ > > diff --git a/tools/tests/domid/test-domid.c b/tools/tests/domid/test-domid.c > index 5915c4699a5c..71cc4e7fd86d 100644 > --- a/tools/tests/domid/test-domid.c > +++ b/tools/tests/domid/test-domid.c > @@ -41,20 +41,20 @@ int main(int argc, char **argv) > domid_free(expected); > > /* > - * Test that that two consecutive calls of domid_alloc(DOMID_INVALID) > + * Test that that two consecutive calls of domid_alloc(DOMID_ANY) > * will never return the same ID. > * NB: ID#0 is reserved and shall not be allocated by > - * domid_alloc(DOMID_INVALID). > + * domid_alloc(DOMID_ANY). > */ > for ( expected = 1; expected < DOMID_FIRST_RESERVED; expected++ ) > { > - allocated = domid_alloc(DOMID_INVALID); > + allocated = domid_alloc(DOMID_ANY); > verify(allocated == expected, > "TEST 3: expected %u allocated %u\n", expected, allocated); > } > for ( expected = 1; expected < DOMID_FIRST_RESERVED; expected++ ) > { > - allocated = domid_alloc(DOMID_INVALID); > + allocated = domid_alloc(DOMID_ANY); > verify(allocated == DOMID_INVALID, > "TEST 4: expected %u allocated %u\n", DOMID_INVALID, allocated); > } > @@ -64,7 +64,7 @@ int main(int argc, char **argv) > domid_free(expected); > for ( expected = 1; expected < DOMID_FIRST_RESERVED / 2; expected++ ) > { > - allocated = domid_alloc(DOMID_INVALID); > + allocated = domid_alloc(DOMID_ANY); > verify(allocated == expected, > "TEST 5: expected %u allocated %u\n", expected, allocated); > } > @@ -72,7 +72,7 @@ int main(int argc, char **argv) > /* Re-allocate last ID from [1..DOMID_FIRST_RESERVED - 1]. */ > expected = DOMID_FIRST_RESERVED - 1; > domid_free(DOMID_FIRST_RESERVED - 1); > - allocated = domid_alloc(DOMID_INVALID); > + allocated = domid_alloc(DOMID_ANY); > verify(allocated == expected, > "TEST 6: expected %u allocated %u\n", expected, allocated); > > diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c > index 495ef7b16aa0..9130c38681df 100644 > --- a/xen/common/device-tree/dom0less-build.c > +++ b/xen/common/device-tree/dom0less-build.c > @@ -842,7 +842,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 29a7726d32d0..e2c8990531ad 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 7f15204c3885..b5789c32ae1f 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 xen_mk_uint(0x7FF5) > +#endif > + > /* Idle domain. */ > #define DOMID_IDLE xen_mk_uint(0x7FFF) > > -- > 2.52.0 > From xen-devel-bounces@lists.xenproject.org Fri Jan 30 01:16:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Jan 2026 01:16:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217167.1526967 (Exim 4.92) (envelope-from ) id 1vld7M-0001nI-2f; Fri, 30 Jan 2026 01:16:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217167.1526967; Fri, 30 Jan 2026 01:16:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vld7L-0001nB-VX; Fri, 30 Jan 2026 01:16:11 +0000 Received: by outflank-mailman (input) for mailman id 1217167; Fri, 30 Jan 2026 01:16:10 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vld7K-0001n5-26 for xen-devel@lists.xenproject.org; Fri, 30 Jan 2026 01:16:10 +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 3f5c8bb8-fd79-11f0-9ccf-f158ae23cfc8; Fri, 30 Jan 2026 02:16:05 +0100 (CET) Received: from BY3PR04CA0012.namprd04.prod.outlook.com (2603:10b6:a03:217::17) by BL3PR12MB9050.namprd12.prod.outlook.com (2603:10b6:208:3b9::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Fri, 30 Jan 2026 01:15:58 +0000 Received: from SJ5PEPF000001D4.namprd05.prod.outlook.com (2603:10b6:a03:217:cafe::de) by BY3PR04CA0012.outlook.office365.com (2603:10b6:a03:217::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9564.10 via Frontend Transport; Fri, 30 Jan 2026 01:15:41 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by SJ5PEPF000001D4.mail.protection.outlook.com (10.167.242.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.3 via Frontend Transport; Fri, 30 Jan 2026 01:15:56 +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, 29 Jan 2026 19:15:55 -0600 Received: from [172.23.55.58] (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, 29 Jan 2026 19:15:55 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3f5c8bb8-fd79-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=BxCcdxyppVZAOFMTimCpS5k6nCKiO33UjhEulJRVDwreyFgqRTgEORv3YcJb9Kt44GAUgBuG1FywDX7Y2cDDD25UtSKOQcbtIzMaq0ogYP+wGTCC/edGknFVVuUkKVVF8R6t0JZyuZ3PHyY+IcJ800y96klt4q5JEb+Sa+GYIOf8tKyfMe91jtZjlH9/MEUB65J/fdAa4r48ltKXrZbhvGoxfwBfBJFaMHrnBXF8PRu89tNZAfB6cCRhRVt64hjMqZwnUwMTPwKTpp6j3nAQjr1OsunXJLuNk1KBA5k2CSwJQpPK/0WMLVTPgjTx6AkgMW8IDjcp+0hywn8tRJ6kLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qzcptzbJOo7Yz/i9v0LFtExbw5pxyLcL/Da0og1H+6U=; b=DAT4gxi+vvlQkSmaz1bvUu3X3LJcv5TXXCMSfS56YcONniLsSMVFU9wBaViNsflL/dWbO8kGO6jHhScD0ZEw0ubIpSz0MVNHokyB93F18CLV+WOd9SXnEevJWMMI6EiZd7nSvc8NX4wdQKu00Ygc2y0WPUAXa5KYDqgP+2r2JcEtwqGTsti7MAICCsakqWbdu72L6miJIx2qYBeHz9uBzWbdqQIjdRgBvB/OxdmFC5I2IAuZQJHtCdvPAqVM0RaMPqb/YsKxSuZqRd6bvC0fAElOndOkSCPZrTaAf9YuxfGkcy3sXpstEuUrw4UbhfPjV+MQIgH6Af0YoD38bIgPJA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qzcptzbJOo7Yz/i9v0LFtExbw5pxyLcL/Da0og1H+6U=; b=tbcIOXNyzwEh46AbykTp0n+NN3oNPp5VSXZwNHUJUFYMnkuiE7Yr7rEqmEElqz0bGIgPXZdFxXLTCyRwlG5pqT6DIkkvgtfkHJK6ARaf2UId2+c2cWVz73BnPxze0Fr8Yi3a7abvuqLuvt01kTMYKyP+IbBLzw36cRQF+fv1nY8= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.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: Thu, 29 Jan 2026 20:15:55 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 2/2] xen: enable dom0less guests to use console_io hypercalls To: Stefano Stabellini , CC: , , , , , , , , References: <20260129220858.2371938-2-stefano.stabellini@amd.com> Content-Language: en-US From: Jason Andryuk In-Reply-To: <20260129220858.2371938-2-stefano.stabellini@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: SJ5PEPF000001D4:EE_|BL3PR12MB9050:EE_ X-MS-Office365-Filtering-Correlation-Id: fdb7b723-a104-44c4-e003-08de5f9d1f06 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|82310400026|376014|1800799024; X-Microsoft-Antispam-Message-Info: =?utf-8?B?VjRWK3FFTWUxTGVsclNBTkJ5cUIveXZabWczRmRwWENOM0gwRDdBWWxEeFh2?= =?utf-8?B?OWFTc1JvcVVyeS9TLzBSNXF6cURnUFo3MkxjcEhxOG83L1VGcHpYWUJ0SU1Y?= =?utf-8?B?TGw5amlpc2JDcTUrc2xtV0F4ZGhETEZLdmhMZldJR1hzS2xxVnBKQWdpYnFv?= =?utf-8?B?cE9PeGo2cjVTdmxzNXVBZ1VEKzB6RElWa2M2VGVQUzZrNHBpNTE0Zk81RS9X?= =?utf-8?B?WWdEemFpYWlZK0pRN3VaUEN0MytMYjVpd2wvZ2NEbmVrc0NLMEh0Nkt6TG8v?= =?utf-8?B?bzZFNDdGSC96UUJ1eW9TWTBUY3Y4SDFTVkRkelNuWklzUGRuL1ovRnZoeDBD?= =?utf-8?B?eitBL2dCNzM2RXhDMzFlbGo5WjBtY3VsZmRJaEN4MWVERkZCOTdVRkRWeHph?= =?utf-8?B?OVVQak5TNmkxOW9RYkEvRG5uYVgvL2lZa0tlZ0paNjNmQzZlQksxbExYaW4w?= =?utf-8?B?SUhSK3VncDdYM2lBdE5pNFA2QThXVDdYWWxydFhGWU9JUEZxSWFvTzlreHRM?= =?utf-8?B?djQyRVZaRDE2a293dlRiVDdPSVpSajFCc2p6TUo1RkN6MUViMStmd1hlTjEy?= =?utf-8?B?c1FuYmwrb1JXUTV5T0ZkRDZ1YkgrS2pXTS9xRG1SSHhmN0pPa05wbzVVS2Jz?= =?utf-8?B?VTBDZVBmaG1kMTBXaElydnRXamErU0lzK3ZWVnRRbnVxTi9FZ1oyQXdLdG41?= =?utf-8?B?bDBPaFF3K0VTM1M2T1gwNGJPZ21TR2lTNjZsVGQzMG8zcXNNYklBdlFpMzMz?= =?utf-8?B?K1QzaGpuUVE2WUtHZVlQdm5jcVJ3MEtzZ05qbDluRC9wbTlTSVBtN0lCVFlC?= =?utf-8?B?czR4RVRVL0g3Nkc4RU9qdk94SE51R3RwYm85MDNGZmV4bno1U3B2cUZ1M2NC?= =?utf-8?B?dENRcHdLWUFhZjljMjFnTDVIR1loblhEQmwrbVpVRUFNNnhZYlVHcnB5RURK?= =?utf-8?B?WmJUMlVIZ1ZNRHlZY1k2UllBM3hub3JpaVByS2g4ck9pcmcxS2xoWmdLWXhw?= =?utf-8?B?OElEK1ppR2pZVzEwT0xuT1VyRWtyOE9xMVBqcERkamIyZmhTRXJQQnE0cWo4?= =?utf-8?B?QlA1NGhyYXVVL2llcG9oYTlMOE54d0twUUxvaXVScFBUN1BPems0SW42WG5w?= =?utf-8?B?MXdhN2NhQVNIViswdU1vU2ttblJTYTBzR2cxREQ0ZDQ1V1A5cTBmc3VOdkUz?= =?utf-8?B?a0xaSnE2b0pCZ085NVQzbjg2UVY4RGJLL0hVY05aR25ISnZCdUdwUUNEdFg3?= =?utf-8?B?bXBzM1dNZUlHL2lTWDMxUzJYQVR3YzlGeU1YU1Y1TW5ESWJyei9yYlQ3RnFH?= =?utf-8?B?UUcwVE5UWDdZa25kaEtYS0x2L2VSL3lNV24wRnIyNk5haTVMYlAwdjNGN3Y5?= =?utf-8?B?dHdzRlBTVlVvVXBSdDdOR3Q2SndMYitoN1pHbXZkb2VGSE1VSUVLQ092T1oy?= =?utf-8?B?bkhqV3VkR1VCbU4zT3JndE1DVTNqVVFBZE5qMG9PUzFRNWcrZmdJalFvbnZ6?= =?utf-8?B?VjhBNkxCU1VsSEwvOXhlMDViMW4vY0hjcGVtbjFaTllkS0lqcGNRQTJxZG1w?= =?utf-8?B?SXgranJmdER2Tng4U0Q4SCtldWxCMDBvUHJ1TVNuT3hpcDRCWkR5Z2UrNTVK?= =?utf-8?B?MWYrQWxYU2hIaVAvZDRhV3YxbWhwdTBnNEpEK3hJY1RsNFFIYms3VXhkbDda?= =?utf-8?B?OEVESklXY3VUMlhGYVlxZDhCL1diRTFGeXpraWV1Y2k5SmxJYzJuMGxyMFBN?= =?utf-8?B?VW1iclczUlAxbWpVbXNQaHM2TVdVcWIvUmtTZ2hYdzdaS29RMjROWFRCeWZh?= =?utf-8?B?Y1A3OGdSZWtoVmduMHJDcXFuVmV4K0E4RjhkdmhFNGxOSWN2ZVRlWUtHMVRR?= =?utf-8?B?S0JOc3VPazNKWGt0QlBaaUpFNjNVaE9oenArdzVxb2l0anRORXkvS2tVMFp1?= =?utf-8?B?YVFSTHBjU2JnRDd5aFI1N0ZVNXBYcmt0UWF2MUJrUUlFbTNyQndYc2lmRElX?= =?utf-8?B?LzNHRjhXY2N6N1pycVlWUCs0cCtEbldSaFhNT0dWYVFPRWJLMG9sNFFMakw4?= =?utf-8?B?UWVBeG5uTi9iTjhvR0J3K2lVNzlTZXN3Q0w0OU5MZWpkTjRYRkw5MXBvOENM?= =?utf-8?B?SUxWb2pqMi8vZVk4QlV0RjBCQnhMZ2orQy9OalNWUEJYOEE2ZEpRZFVhVlpL?= =?utf-8?B?T3JNbERlbkdkV05wU2ppZTZTcmJTQi8yMnFpWlVNUUVqUWhLOHc1TUtUVUVX?= =?utf-8?B?SE9sZHJXMm8zSWRjR01vdWhTSm1RPT0=?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(36860700013)(82310400026)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: yLXBNcTDPRE/JnzA8P0Be5z4S9xxUtSgxHW7iUeYU2xomhj+xArlylUWuItoTFBJuAXNQ83JMlwmxDCcIq20VWvuZ5hhp3XiSaIffem9Wm7B8auxe1a+ccLVUiep0sSJnTKu3avICVZyVISfToLziPLT8VLOXuKC5gUgPydWhi4pDIn21PkaAQCgkHGMfljw7VYX9pNElJkOEMLcK/HI9CkWQ5e/Lbea5/Fsn8LLPbOYY+UuBwLp0gsrQ7UBh2FE3jNTXqcHpwJ8PdJ1a+idlaoSrycZ6bt02tyn65hLHSzyknQ5sRWDDbT8Re23I6Q2I1zmsPgRt0YwByvVsW+N7dAjlJ5Ec3U1tqzFfI+yIOASKVGPOIL1IHiiuPnAOeRvo2W9fbAmgySGag1NKF+9V7rlgUldPvrxbFCniGx/U6lvEyiPPzPO1FV7Jt4wSsoR X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2026 01:15:56.6899 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fdb7b723-a104-44c4-e003-08de5f9d1f06 X-MS-Exchange-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: SJ5PEPF000001D4.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR12MB9050 On 2026-01-29 17:08, Stefano Stabellini wrote: > Enable dom0less guests on ARM to use console_io hypercalls: > - set input_allow = true for dom0less domains > - update the in-code comment in console.c > - prioritize the VUART check to retain the same behavior as today > > Signed-off-by: Stefano Stabellini > --- > Changes in v8: > - move in-code comment update to previous patch > - add in-code comment about is_focus_domain() check > --- > xen/common/device-tree/dom0less-build.c | 2 ++ > xen/drivers/char/console.c | 16 ++++++++++------ > 2 files changed, 12 insertions(+), 6 deletions(-) > > diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c > index 840d14419d..cb7026fa7e 100644 > --- a/xen/common/device-tree/dom0less-build.c > +++ b/xen/common/device-tree/dom0less-build.c > @@ -829,6 +829,8 @@ static int __init construct_domU(struct kernel_info *kinfo, > > rangeset_destroy(kinfo->xen_reg_assigned); > > + d->console->input_allowed = true; > + > return rc; > } > > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c > index ed8f1ad8f2..418d194cef 100644 > --- a/xen/drivers/char/console.c > +++ b/xen/drivers/char/console.c > @@ -613,11 +613,20 @@ static void __serial_rx(char c) > if ( console_rx == 0 ) > return handle_keypress(c, false); > > + /* Includes an is_focus_domain() check. */ > d = console_get_domain(); > if ( !d ) > return; > > - if ( is_hardware_domain(d) ) > +#ifdef CONFIG_SBSA_VUART_CONSOLE > + /* Prioritize vpl011 if enabled for this domain */ > + if ( d->arch.vpl011.base_addr ) > + { > + /* Deliver input to the emulated UART. */ > + rc = vpl011_rx_char_xen(d, c); > + } > + else > +#endif > { > unsigned long flags; > > @@ -636,11 +645,6 @@ static void __serial_rx(char c) > */ > send_global_virq(VIRQ_CONSOLE); I think we need an additional patch, or included in one of these two, to change VIRQ_CONSOLE to a VIRQ_DOMAIN. Otherwise only hwdom could bind to the virq, I think? It would be the two changes below: Regards, Jason diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c index 67700b050a..dab123f20d 100644 --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.c @@ -138,6 +138,7 @@ static enum virq_type get_virq_type(unsigned int virq) return VIRQ_VCPU; case VIRQ_ARGO: + case VIRQ_CONSOLE: return VIRQ_DOMAIN; case VIRQ_ARCH_0 ... VIRQ_ARCH_7: diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 903ad912cc..138eeaa14d 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -611,7 +611,7 @@ static void __serial_rx(char c) * Always notify the hardware domain: prevents receive path from * getting stuck. */ - send_global_virq(VIRQ_CONSOLE); + send_guest_domain_virq(d, VIRQ_CONSOLE); } #ifdef CONFIG_SBSA_VUART_CONSOLE else From xen-devel-bounces@lists.xenproject.org Fri Jan 30 06:14:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Jan 2026 06:14:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217223.1526976 (Exim 4.92) (envelope-from ) id 1vlhmB-0003TW-4A; Fri, 30 Jan 2026 06:14:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217223.1526976; Fri, 30 Jan 2026 06: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 1vlhmB-0003TP-1N; Fri, 30 Jan 2026 06:14:39 +0000 Received: by outflank-mailman (input) for mailman id 1217223; Fri, 30 Jan 2026 06:14: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 1vlhm9-0003TJ-G0 for xen-devel@lists.xenproject.org; Fri, 30 Jan 2026 06:14:37 +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 f038bdca-fda2-11f0-9ccf-f158ae23cfc8; Fri, 30 Jan 2026 07:14:30 +0100 (CET) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-b886fc047d5so322460866b.3 for ; Thu, 29 Jan 2026 22:14:30 -0800 (PST) Received: from ?IPV6:2a00:12d0:af5b:2f01:4042:c03:ce4d:a5a1? (2a00-12d0-af5b-2f01-4042-c03-ce4d-a5a1.ip.tng.de. [2a00:12d0:af5b:2f01:4042:c03:ce4d:a5a1]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8dbefc56e8sm367842766b.15.2026.01.29.22.14.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 22:14:29 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f038bdca-fda2-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769753670; x=1770358470; 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=odLvTtll6kkmjgwy4IMUke75LnRrXnUGi25AXl2U3+g=; b=WXujBznd9jTgXWjFr29H9VvcPNWOpOkn4S8mniUjAw929jAG1mb5S8c69UTJAKiaD/ Dta7MmLPk3EnePI5A+MHPSWW/AQWbdtOjkAZV6H2ga7eegFCCgWS1hOvlwCXeNplIbUo fR7CBNiwJ7xxjG/9TGPVVRAj5JPmi6NCm5k+m73Vip2INFdzWYB6KUrAW222Yfl9TXnF F7qM8v9uxSX8RTVTVmlYo58iqPBk1TiGtbqVKvQ8l2GnTJv7yfVorNA1xdxScBHCnvV+ edboHa3yLkcDtHOGWyfSKoivEf9jpZc6QlZxnwStUyfQMOSJZCuPlQoK3bgMHTkSlUS2 9IAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769753670; x=1770358470; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=odLvTtll6kkmjgwy4IMUke75LnRrXnUGi25AXl2U3+g=; b=NEWI7eHRff4YzZIRfyjUVDMUtFH7NrUlnpeCdOeDsQ0/NWlsRFh+1ePgBF+odDA21E NGi7IcY256xHbtwO7EnJpjA6v1vuz/wNHs82KdIZNoizSTrS3mpWcja8HsZvGLiDas+9 d/0B6vEn9hC2kqbVyyoM5vprjf0+j+DcZ65P/exfXgztcmu3oeDUqVL7FcWrI0/UYaUb IuQSWa16RZv6sLFNHxjzbwKTKn/4yYaHbCzoTmC8JPkY70WhItOFRhOgB6WMfRjsnpUD 6u7uKaW7LdQgk5k70RSV8jJoHIRRlutTlsROAutKZgFEpAUwnNV64aXoM9lRnX7JUSYV QXYQ== X-Forwarded-Encrypted: i=1; AJvYcCVltn4EZHLUsxdNfjOWU/LZf7cI1Dg4VjsgeVMiuUllleiOp7uzbTUySOi+xy1jI1oZvvfdEANW69A=@lists.xenproject.org X-Gm-Message-State: AOJu0YxP9xNvBIJ46WwwazmFHbQ1xvPZDLITGf7x54pahXDDRsUT8Hol K2EE5yeX1XFCef8nJafUlT3RzRzINz7LUUytH1XfbMOg+KgrvUcWtw7uuBGBlZD8RKo= X-Gm-Gg: AZuq6aJLyW1Tw8t+f7QMT8weNPmPfEEnHwO0GeRV1WBBhDh7zTufM7O+YMiQ1FGdicS JTNOORWghPrRwyKr4/j7cpJAxWXB94CEj6DWeBvZmGm3/wAAL5II7n+7p04i7MRU+tpra2LhjYi A5z29El4oImvTxPkxGSlQAey5c588M9S53o2HgbbyX7jNalZVKvinbeV0x2A13ARZ23XVehLRsw upsU9BMUi9u1yV7hd5jHTlMa0AVvkplbFWYDmdM3oHGRrm+aHgBQO9nLY1LBwEUKroOSLBqhKZv JAE5xih5QA8IP0yprFcdwyWGKRj6VI0MfgSWx8u3NBu0aBukgh3cqY0be7SZ7LdbjUATv2qI5PE SWeGQnzO9tn2nCLb96V1LhWnxfhSeSku4eKJaPqot+rzlqlQWI0W6l6/9EQEgQJMWRJ0wkiu/GK z8mnl53Pkdj41BfwAz2JZMkV0u+h5HXEkO/tcijJfsfhcDghCzQPsa/axlf7Sxqc5XXOfD3c9GE Mq/dy4UCtktp+fMeUUA/1F7ejK3p3goBnFeKg== X-Received: by 2002:a17:907:3d56:b0:b88:626a:adbe with SMTP id a640c23a62f3a-b8dff21f20amr93965066b.0.1769753670260; Thu, 29 Jan 2026 22:14:30 -0800 (PST) Message-ID: <83ae6264-bae0-4b04-81f0-8a7ede0b12d2@suse.com> Date: Fri, 30 Jan 2026 07:14:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] 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: <20260109140747.195460-2-dmukhin@ford.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: <20260109140747.195460-2-dmukhin@ford.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------oH0i10GgAQ7jZXiDxXnwQWSf" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------oH0i10GgAQ7jZXiDxXnwQWSf Content-Type: multipart/mixed; boundary="------------qQe5jbTlHEuJU8EX19oSioWV"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 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 Message-ID: <83ae6264-bae0-4b04-81f0-8a7ede0b12d2@suse.com> Subject: Re: [PATCH v4] xen/domain: introduce DOMID_ANY References: <20260109140747.195460-2-dmukhin@ford.com> In-Reply-To: <20260109140747.195460-2-dmukhin@ford.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= --------------qQe5jbTlHEuJU8EX19oSioWV Content-Type: multipart/mixed; boundary="------------Q5BHO6vhuX0BaCUYy50Rsz7g" --------------Q5BHO6vhuX0BaCUYy50Rsz7g Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDkuMDEuMjYgMTU6MDcsIGRtdWtoaW5AeGVuLm9yZyB3cm90ZToNCj4gRnJvbTogRGVu aXMgTXVraGluIDxkbXVraGluQGZvcmQuY29tPg0KPiANCj4gQWRkIGEgbmV3IHN5bWJvbCBE T01JRF9BTlkgdG8gaW1wcm92ZSB0aGUgcmVhZGFiaWxpdHkgb2YgdGhlIGNvZGUuDQo+IA0K PiBVcGRhdGUgYWxsIHJlbGV2YW50IGRvbWlkX2FsbG9jKCkgY2FsbCBzaXRlcy4NCj4gDQo+ IEFtZW5kczogMmQ1MDY1MDYwNzEwICgieGVuL2RvbWFpbjogdW5pZnkgZG9tYWluIElEIGFs bG9jYXRpb24iKQ0KPiBTaWduZWQtb2ZmLWJ5OiBEZW5pcyBNdWtoaW4gPGRtdWtoaW5AZm9y ZC5jb20+DQoNCkknbSByZWFsbHkgaGFwcHkgeW91IHdyb3RlIHRoaXMgcGF0Y2gsIGFzIEkn bSB3b3JraW5nIG9uIGEgc2VyaWVzIGZvcg0KeGVuc3RvcmVkLCB3aGVyZSBJIG5lZWQgRE9N SURfQU5ZLiBJIHdhcyBqdXN0IGFib3V0IHRvIGludHJvZHVjZSBzb21ldGhpbmcNCmxpa2Ug dGhhdCBteXNlbGYuIDotKQ0KDQpSZXZpZXdlZC1ieTogSnVlcmdlbiBHcm9zcyA8amdyb3Nz QHN1c2UuY29tPg0KDQoNCkp1ZXJnZW4NCg== --------------Q5BHO6vhuX0BaCUYy50Rsz7g 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----- --------------Q5BHO6vhuX0BaCUYy50Rsz7g-- --------------qQe5jbTlHEuJU8EX19oSioWV-- --------------oH0i10GgAQ7jZXiDxXnwQWSf 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/Ey8FAml8TEQFAwAAAAAACgkQsN6d1ii/Ey+r vQf/U0UrswGXJxUOdlHaozZtVmYmdaZMNv4Lxjc0V7ow6azzOYT1ek50wmUPVlV2Vx4+vE+mAxsn djg1oRAKPCpDpd77YSKfcqgS8G0yoms+Dyx4bSYlUsJof8EQsXhco7rjfXo6x4NkIAk7G5SYLTQv hNImgzfj+n3ApVRELyWWgLeMVuTAH8IkqtVEGJwBm7FBgiWYNN4GKYmxaU4irJL00BYg6K8cTN0b X+xAq9WDubfLWLL7iri7UaN5nn4qBhvY39upNPZfujZ6cK543xGVx/8lY9MVk/7Z8qf2MxFmb7fb qVaX0OGlzTLd8ycEaMzpblGaJnuaCnB0pKDaBW94wA== =hTUf -----END PGP SIGNATURE----- --------------oH0i10GgAQ7jZXiDxXnwQWSf-- From xen-devel-bounces@lists.xenproject.org Fri Jan 30 07:25:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Jan 2026 07:25:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217238.1526988 (Exim 4.92) (envelope-from ) id 1vlise-0003UW-6v; Fri, 30 Jan 2026 07:25:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217238.1526988; Fri, 30 Jan 2026 07:25: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 1vlise-0003UO-1k; Fri, 30 Jan 2026 07:25:24 +0000 Received: by outflank-mailman (input) for mailman id 1217238; Fri, 30 Jan 2026 07:25:22 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlisc-0003UI-Ty for xen-devel@lists.xenproject.org; Fri, 30 Jan 2026 07:25:22 +0000 Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [2a00:1450:4864:20::341]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d5719009-fdac-11f0-b161-2bf370ae4941; Fri, 30 Jan 2026 08:25:20 +0100 (CET) Received: by mail-wm1-x341.google.com with SMTP id 5b1f17b1804b1-47ff94b46afso15533025e9.1 for ; Thu, 29 Jan 2026 23:25:20 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806cdd78d3sm184204025e9.1.2026.01.29.23.25.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 23:25:19 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d5719009-fdac-11f0-b161-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769757920; x=1770362720; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=FLxaQfvYhPb6GtKPj8giu6ojgpmYWheD88uOj7YdUAA=; b=DgAHxStKYkxPYjew4H/ujWVoMWSYUvxjw7iA/MazA7KkmHOXLGlfjl/KERWxzI7jIC 41SgdmS6FNcvMAHYUjMT5+Oal0b9zAzZqH6u+GGD5BZWRz4tFBrVYhAABrsSJJWTHeCL EDP8jSMoXeb8Y0mWTTd3R00ewRxA7i9L/Rv5EaOVCWRC2qwF76dg8lncMcuWhgfGaPWx t0JB2/6geN9IhklIyuHOUzKQ+UA6Bz4z/CSkai3jPSkMRi0B+CRx9sRgS/uCW/3MSGtS N45pNS+12IFz4Ill09468FwvgeN7Xpu9doP3lt30DKEv6VssGtUq4BkK/1gPJUq4Kwhh yiyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769757920; x=1770362720; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=FLxaQfvYhPb6GtKPj8giu6ojgpmYWheD88uOj7YdUAA=; b=XCVwI/OWe5B60xy5Mq3ETdJnDUyX+0ld5m7mt9KFwjRXC8sYTfEnMYhZjN9pmrpIMJ hm5ztFP7uOCDAyyI8qhRtBBDgSgtEKARcMlQQoiOR5zwPT+IdH2fvphYkyDvEKMwrEyn qn+/1Fk90daKao3O821QGjP/xqVG3jpmSx0QjzPcH+0bGriB8NdrNa4AU8tHEK4BdeEe aWC5x8EjKQkvuRrDeZpNknar9YFEClxsYzjBOMULI0+O3twMsLU9xNLlpwmEXUjppHfI 2DnOsDzYqbNZblMmZTVV80NvZ4SzHKU+KlY46RLCSjiUuEod7s96IVOXWJQuJc5Q7TJ6 ZXVQ== X-Gm-Message-State: AOJu0YxecVGGzYAID2TBy0G/6zTO+uYPel+e7rOXDmE0GC3b/2OCRwDt VLyn8uGjwzBYPQJamAvbotgQqhB8ZB62pgi/cFgrO6GQt6ndm5XB2MhJ21KR0sUK7Q== X-Gm-Gg: AZuq6aI1LrOe0IuvijcGNvrVdjizwJs4GTh2IaQZm/EEqz99tzFePBtFtqez79C4JGn CiStpM4/aY+XhkqW2Z3INrYCJjX+onjM11BK1h13XghJMCr9HTmhdZ+NExLQpvW8HtdJ68uxOF7 +lZCptnEdoTxfrCdVkpJO/qC4rBtqMhGInuO+Q4aVMySFmcvEpbUPYzEppiO9xWwP0WMqB//AWE nXg99YnmPaWFakrpnbITROx1TwfANkUpQQcaiE2NSC2IAIKueqRVDUMjIKTKoUKy2qpiXSOvW+6 0dgBwAZluvmpawcHW7hViWCZ/8EbMnzpM9f2/BoZdhgdOt9Pw+TzEC3DKFkPmPMmA8/cLF0q8eb rdxRjYu9aACAgF1fb/2RPA7mtF/lszamHL2HTZA/JShGS+sx8MaCR7bGlo+BjaW3NZUpZnsYHNy HJwt4VV2WfKbSmPqo96ekGWoPgoAKybpTqfnEJrKGI81o4bTMjKA40Pkces6v9vKeUt5P1pF7o4 nw= X-Received: by 2002:a05:600d:4452:10b0:47e:e2b8:66e6 with SMTP id 5b1f17b1804b1-482db48b7acmr14751845e9.14.1769757920080; Thu, 29 Jan 2026 23:25:20 -0800 (PST) Message-ID: <7bea7067-0d7d-4eaa-bd52-8735f90998c5@suse.com> Date: Fri, 30 Jan 2026 08:25:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 1/5] xen/domctl: chain SCI handling before IOMMU in assign_device domctl To: Stefano Stabellini Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Volodymyr Babchuk , Grygorii Strashko , Oleksii Moisieiev References: <69d32e2440b2ef194b4893e5dd29c2dd9d216a90.1769696107.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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.01.2026 00:14, Stefano Stabellini wrote: > On Thu, 29 Jan 2026, Oleksii Moisieiev wrote: >> --- a/xen/arch/arm/firmware/sci.c >> +++ b/xen/arch/arm/firmware/sci.c >> @@ -126,6 +126,42 @@ int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev) >> return 0; >> } >> >> +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d, >> + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) >> +{ >> + struct dt_device_node *dev; >> + int ret = 0; > > Should this be -ENXIO? Not unless further changes are made. That error code being set ... >> + switch ( domctl->cmd ) >> + { >> + case XEN_DOMCTL_assign_device: >> + ret = -ENXIO; ... here makes sure that other XEN_DOMCTL_* making it into this function will ... >> + if ( domctl->u.assign_device.dev != XEN_DOMCTL_DEV_DT ) >> + break; >> + >> + if ( !cur_mediator ) >> + break; >> + >> + if ( !cur_mediator->assign_dt_device ) >> + break; >> + >> + ret = dt_find_node_by_gpath(domctl->u.assign_device.u.dt.path, >> + domctl->u.assign_device.u.dt.size, &dev); >> + if ( ret ) >> + return ret; >> + >> + ret = sci_assign_dt_device(d, dev); >> + >> + break; >> + >> + default: >> + /* do not fail here as call is chained with iommu handling */ >> + break; ... succeed (by making it here). If you used -ENXIO as initializer, ret would then need setting to 0 here. Which is functionally identical to what is there now. >> @@ -195,6 +203,12 @@ static inline int sci_assign_dt_device(struct domain *d, >> return 0; >> } >> >> +static inline int sci_do_domctl(struct xen_domctl *domctl, struct domain *d, >> + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) >> +{ >> + return 0; > > This should be -ENXIO? Why? Then several other XEN_DOMCTL_* would break. Or wait, no, nothing would break at all, as this stub looks to never come into play. It hence should be dropped. Jan From xen-devel-bounces@lists.xenproject.org Fri Jan 30 10:01:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Jan 2026 10:01:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217297.1526997 (Exim 4.92) (envelope-from ) id 1vllJB-0005fp-50; Fri, 30 Jan 2026 10:00:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217297.1526997; Fri, 30 Jan 2026 10: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 1vllJB-0005fi-1x; Fri, 30 Jan 2026 10:00:57 +0000 Received: by outflank-mailman (input) for mailman id 1217297; Fri, 30 Jan 2026 10: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 1vllJA-0005fc-Ad for xen-devel@lists.xenproject.org; Fri, 30 Jan 2026 10:00:56 +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 905a0b46-fdc2-11f0-b161-2bf370ae4941; Fri, 30 Jan 2026 11:00:54 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by LV8PR03MB7494.namprd03.prod.outlook.com (2603:10b6:408:190::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Fri, 30 Jan 2026 10:00:51 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.010; Fri, 30 Jan 2026 10:00: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: 905a0b46-fdc2-11f0-b161-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=LtflugoFJq5ZWb/WcPpN9HQiIHaWMnTrDmsJR/9zA6GacvO31xxFGKKxKXDjyFe0RV21KGJksZCugzfRvBAk+5/ECTIvTM+oO12QF4lCtMi1atMjaHYe6rZiGLsgMd15PZHCkUt2NVLcE+NNrurC4W0ZydgSNS3AgL6gUwFqIRsKVESIrfK8nWqqqYgh78Lvq4A/47rVCaRyUq81u/SatUAmfVAFvdtig4EX5bl4rgiFkSZydw7RENRb8lPRaIhRLtwx5dUkYaAs1bKick8Qq8Yb2y/5ZxogRt0TBpNIW7FCEX7kEfDnv2/J1A5lSxgyaI2ggbRp/VPxeqpRlwQM0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MAG0Y3HFPg+G9GbM4LfSgPa/2Fv0rpz07T57JiD+Oys=; b=IC6CTTVPFM1sJSOO/CZXmSZEHTxLTnvUF6GTNXk3xyT6ISk91Opg3Js/7IC8UsvXs2d5f8tN5imucUf1icCbne4wW16Kub1+CkUheQfFJuLvUwCzZXQfHWOh/RT4HZjHPtASU0nwMuqEPUDzuZcO6iXjhJPHDl3TWWB72gThLGybxttYq2djkvU43Df6Tncusk7w9fkrZ30ulPisI3ehxxEHH4oPWZnkIXZrn30IGN6jE8TNMfVgsB5WkU8+WtC3hMQeR21lnZgRYgWiOx9GC+eoJaCIuYceoUm0H4lvlNfIEkCPok8tixXMat59CX7E2+aGFM6vT8n/UGZ68QT2Ug== 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=MAG0Y3HFPg+G9GbM4LfSgPa/2Fv0rpz07T57JiD+Oys=; b=A/ynxeKFfo/mB9ywdk1lg4vDofUcaE7tMXcLtSYD1HKfFYOivHf72cxsYZXXAMMhQM462JYufOh7L2mjXinsQR68vzVJB9CDqI2/MUkMyzuIv6OsCd0k2Wkoha72fZgcATJSn0ANKc0wnW5hLlAUlOLQwIG2RtB31YJvWvl4iEA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Fri, 30 Jan 2026 11:00:47 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH] x86emul: allow ->write_msr() to distinguish origins of writes Message-ID: References: <7987f1fc-5b5e-40c6-866e-ac332097c635@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7987f1fc-5b5e-40c6-866e-ac332097c635@suse.com> X-ClientProxiedBy: MA3P292CA0022.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:47::17) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|LV8PR03MB7494:EE_ X-MS-Office365-Filtering-Correlation-Id: 3355668b-8a0a-4c14-8d64-08de5fe672c4 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?MUVuWjRGL3BQaUJmTmtRRlo2akkzZHMxZStQTU9pSDRoRVJTUUtQRnQySXZT?= =?utf-8?B?ZWl3Q2QvN1ZzZEdtcXdOa2hKTXdyK2ZFeFNVN1BiQ2xhcEhMSW5TK1BuMERC?= =?utf-8?B?Ty9TT1I1azB5QUNWOXZOODdPd0RtNFJZUEFHYzg2cm96ekhJdGw2TTQzVlI1?= =?utf-8?B?YWZGZXVYcmgzWGd4K0R5anlLb3YrNUNWSkkvS3ZjMHVUQWg0U3NhYk80NWhz?= =?utf-8?B?OGo4VElaZDlDaHpZQ2p4a1U2RENQVS9qWUNUUExJR1VBNWFEc0F2SmhNUGVF?= =?utf-8?B?MXpxbXV1T25VQnM5REtRY25xcXArY25nRGI5RDFkR0Z4d0hacjBWMnh6ZVZP?= =?utf-8?B?bUZod0JiRWZXMmlRVlU2MEZZRVVCWTUzcDJGcUQ0UUtLTUFRK2N3Qms3VDJp?= =?utf-8?B?SGVnaXNZZ29BYUV5NDF2WGF6cUxrMUNBZkVlR1dBaElYa2tkcXk2bURka1ZL?= =?utf-8?B?Q1R0ejhKTG9TQ0lQL0tMdEF0NFBKL0N2VTVNRXQ2Mk1pU2ZZRVVFc092S3pY?= =?utf-8?B?TGtKQmdyejg0Uzk3dWVOelNsTUEwTmdycUVFSzVicDVJT1pTQTNUOGdUREJm?= =?utf-8?B?U1BES3JQU2wxR1UrdTZSUWY5NGptK0xJb2JXRDVndVRLZjJQVEZBWUk0YndE?= =?utf-8?B?cmF3b3JGTjRITitDVEdHeWw4dlBYalZhbUlxalFNc0RVVlhJUStidmlXS0JK?= =?utf-8?B?OGZRa2RsNmdHc2NWM0lzVjJzRDE3aXVnTGR3QmtjMWpxdmtnZ0hjQy80MWlL?= =?utf-8?B?cjdIR2htZVErNk9DdSt1aWgzYjhZcVVCR0dWdm1LRzFiQlN5Z0tmLzl5eHVj?= =?utf-8?B?Q3cvWXJ0aEl0L3BxMW8yVWJlZHYvOWpzeXA4MEVRQUVrWTdqRVBEUUg3OE1v?= =?utf-8?B?bEFCVHZ5MG9JZXN2R0x3UlNZNHBTbHp2OUNhcnI5eEJid1BONFRwdDE4M1Rz?= =?utf-8?B?RkkvRU1pRmFWeGpzb2JVdWVsQVIvUHF1SzJnejFTVUw5TGZ1dUJDWHRYTU5F?= =?utf-8?B?UkMzdzIyQkF4SmwvMUx3d2lzWFlPWHB6aHFoalBqV3NNWEZZV1JEWXk2V2M3?= =?utf-8?B?WUJDdVFyUHVoMis0M1NEdlFkN0c0V3VEeDR1aGdGNW9qQzRySkxoaWpHZ00y?= =?utf-8?B?WUxyNEpobXh6MDI1L1l0TlBZMkF5cU02R3FvYTBPZGN1VU1DMjNYUUxCQmRI?= =?utf-8?B?aWcxRHVxWTBad2dyUFVydFdZS2tsZkQxMmp5TFFBNTBPbEJ6OWE3UjU0RVVr?= =?utf-8?B?MVR2Wmk2U28vZXd4b29yeVdzR2tUdlQ1Q1cwSmdCdFpoUmFxbnNlZEJEcXpk?= =?utf-8?B?U1hOazJsbjRXWlJwQTVUOHB2SHJRZmVEMkJrUkpqMmVDMlQzc2s1bUpKYzBW?= =?utf-8?B?NGhtcHV3VFl2NE9kK0hBYmh5MEE2U3VqR1VtVlpoN2dQMUEwdEp6RnQzYzVj?= =?utf-8?B?YUhkVVhrZXdqYjMwM28rOGVXampJZGpXcXRKL20zamFycHAvUkl3aGdQQVJl?= =?utf-8?B?STliWWxNaHRHNnpvcC9wY1cxVmRSamhWRS8zYkVXUHJVZFNKOG1KZFEzNmtI?= =?utf-8?B?eU1KdjE2UitaRDcwdFMrbDlmRmp1eFczOVY1S1VyaXhlVEpjbGg0Uk96WWhz?= =?utf-8?B?cUdndGxlZHhDSkQ3Y3Rwc01IdHp3YlpjWkp5OFRTYWN1Nk9hdzdJbGZLMkN0?= =?utf-8?B?YTk1cVpLQVFYa2xseWtPYUY1LzJ2c3g2QVVuSzhqR1E3NDY0VmZORldRTGhI?= =?utf-8?B?RVBITThjTXVMTU10dlIva2hPOWdDNHFQNk81UDQyOWZLcFpqZzdWSXJtM0Ry?= =?utf-8?B?RnFjT2VZbGhPOWJGcHgvd2xrOFZ5VU9wdWRWOWtOWmpweWRlU3VLWjd0Wk53?= =?utf-8?B?ZFZIeERCZndHM2NnWXFYdnhYZDNjem94UGhvM2tDWjZrTVZDYm9YQ3BpR09X?= =?utf-8?B?NHl3Z25EbzFGcjFueDdrVm1GcFlma3cxLzVYTGY0VCtxbTRBeCtaMVpvdDlC?= =?utf-8?B?dnhKUzhRUzArV0d2VDluUklWb3YzcGR0REFTSUVqVGhwMVFxSFJuQTRkS1BR?= =?utf-8?B?QWV3QWhOaDVoUUNmS000UEJxc0pNRUlrS2lGTmNBQnNUK1hNdCt5N0dnSmgv?= =?utf-8?Q?P9DU=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?THZ2Q3hTZDdKcVNmT2hjQTE3L012QURlR2FwTE9FY3JHdTNRRnVFMGlDY1R0?= =?utf-8?B?R0JGYklJb2MxdWJ1ang2UUhDZUN1bnJWbDhVeU41QXFGUDJSNHZqNDgyZHBV?= =?utf-8?B?NVVoNzkwTkhnSEdQbVQyYWtMNDBRZ040cE9jM0FEWFF2UjhXOFFuMEdiaGt5?= =?utf-8?B?bENtYjk4cEY4eFh6d3VFdHlFUThKZVBsK2JQUjhJVmRJTElKSnMyUnF5Q052?= =?utf-8?B?WGlRazlMNG9URXRGOEZDTnZjak55emlObU5aemMwZzBWbGxiZXVoVThiRGdU?= =?utf-8?B?akdlUytPbm1PY2R3V3JrZEp5SkJ0aStDdzB5LytXcFpJTXp2R3Voc2Nrb3FM?= =?utf-8?B?S3dETjYySWt4K3JjSHg5K0I0RFBJZ1pERlRqK2prdkZWTFQ4T1g4SkZmM0VT?= =?utf-8?B?cHRGMUJhbXdOQ1FXK3FPT3hpSlFLQUF4dWxhaXlmankrYnR0UzRFKzBPR2VQ?= =?utf-8?B?NjE2WWVhdHNuUm5zRzlqek14VnBxZmxLZmV4WFpCWStVVEFQTG1ueitNaURL?= =?utf-8?B?aEJoekVTNG5KT0U4VEt3R25uak9jQStvZUo3RzA3YTZyRDdTSHpKMW5DRGNl?= =?utf-8?B?WmFCd1lkZVNCZndaT0lEakpuUFhZb29BajRGblEvVWlXOTVHRzhCRWpxQUN6?= =?utf-8?B?ZXRaYlQ5S2h1ckFtWG5DRzc5OWkvU0VDNmgvc29haEdvVVFqUUpOaWF5R0dt?= =?utf-8?B?aGxEbFhORmZ5NmhjTklaUHJtVHo3cXliaEd6VHZKd0dFLzdGVFR3c1JXWEZH?= =?utf-8?B?MzY2cjU4WWR1aFZMVFNlY3NDOUdQU1VnQTFUSFpoRGtTcERlZE1CRnhLZEZS?= =?utf-8?B?a0M0U1dkcWF5OTJoTldlNk1sKzYwS3BDdlVWVVJGaXN1a2dHaDBSMjg5bG9D?= =?utf-8?B?QXBoWmFRdnZ1aENXeThrbDhnQ0xObUNVOGxOTjF5OHM1SFlmR1JLcEFPMlRp?= =?utf-8?B?TWl6RWFnL0loSE9tOWxhNHR5TG54U0U5YVJIYmFSazlLV3pxbG5xRy9HUjVw?= =?utf-8?B?dnFjNlJlaGdzRHJqTHpxcUZMVU9DOUl2RXVDR3ZzVDBLbjkyNDAwQURoUnJH?= =?utf-8?B?SVZRZ0NuYytQejNVOGFaSmpvc1RUOWk3WDJSTTdlaEM2SmZZUlNRRDVHOEFJ?= =?utf-8?B?ekdKY1VFMUkwSER2MjVwVVNGUFYvc3BzWkllNm9lMUJLVW1SUnYrdTNBckpM?= =?utf-8?B?QmxZK0JSYlRqa25hMVU3Q3RzR3FnMjNySGd0b2xoS3d2SUZKZ21sVGprR0Q5?= =?utf-8?B?NXFtNnFYbmJDVVZWZWZqOXpraGErYjdlV0FoWlpDNCsrS0tJVjlnRWF0QUU3?= =?utf-8?B?MmZsVW9nOGx0S0JwV1BqZFQrQTVIWS9ZR00xaTZERmJFQkhGdFFWZ1ZRa1hR?= =?utf-8?B?SlJ3dkxKR3FYNU4xNVplTjlEV2FqWjVKTEVQdmxmRHJmOFUzc2g3WEIvV1pW?= =?utf-8?B?TGdiVVlJaHc1M2p5bndFMEhlZUJUOVQyUzVQYml1NXhkU2psYTVINGtBNHNl?= =?utf-8?B?QWlRZ1BwN0toMkNsWFJ2eGFvODBnd21lcS9aOXJOaFJLYjZlR3RUdkVrN1VF?= =?utf-8?B?OUZwOTlyRW9Wb1Y3cUtNN1JHZXVHZkdKejQvVG54K05FK2s2bXB0Y1AyK09S?= =?utf-8?B?NktiWjVPaW9tMVlUTktBZlE2dHZZWFY0RjVnYWdrOForT092ci9WWGlVUmN3?= =?utf-8?B?c1F1Sk5DM1JDL00yc1hBNkFkU3RGZklXN3dnbGwxODVxbzdSQmhtdlNOMzBI?= =?utf-8?B?ZFpsdG5RK0h1aEtnQ0cyeWVYc09BMHkvLzVwKzVnQlIzd2NWclhsbkZVWGxO?= =?utf-8?B?UVlkMG02cWowY3hvcGhvUXpKZVZvNEZkbHliV2tMUzN4bkFldkV3aHJrZ3Qx?= =?utf-8?B?SjBHam1nZFBFLy9teklNQ09vNDZwcEVqTnZxUk0yQ1VHVVFiZUpPcXBoR0tG?= =?utf-8?B?SUxaSVNWK21YVThUNGxzcmhrZmlsSWs3OEZST3NEZ0JENTRBQlRoTkJPanls?= =?utf-8?B?YWpod0tPOWsyTTkyT1M3cHQ3MVY0ckl0TEpRakJDcjQxLzJSaGZQMWlIUmEr?= =?utf-8?B?YnNxb0pWUy9kbGRJL2dacWQ2RGxPeWFER01OOU5veS9mK1J3L2NLT2dlNTNy?= =?utf-8?B?QTRXRFVJdUM3eklJaENUQkEzNHc0NDNTNnpvbHVvbXpQSVRTT21OQ0k3cXlE?= =?utf-8?B?YTFxdHhjRzE2UnFVZ0tVSmhKMGhxMDdrYWZNTThJZnl3Ym9TRlpUelN4K1Ft?= =?utf-8?B?MCt4L0VZaVQrRlpKNXcrZk5Nay94K1A2V2xJYmcwMWtFWDBHaEsxcUZ4ZzZL?= =?utf-8?B?WU4zZ3YrTUxlZ2s3MTQ2Y0oyYTlsUUZaU1BVV0Qrald6YmRqbkkzdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3355668b-8a0a-4c14-8d64-08de5fe672c4 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2026 10:00:50.8797 (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: 468+AgkojX8Dceh4YuppAhSK44bi/2dygH+y8Mh4itJmlY6rBRiTkdhw8RwXAeQWD5R76vnjfBPHURH8ehSAhA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR03MB7494 On Tue, Jan 27, 2026 at 11:21:06AM +0100, Jan Beulich wrote: > Only explicit writes are subject to e.g. the checking of the MSR intercept > bitmap, which extends to VM-event's hvm_monitor_msr(). Indicate, by way of > a new boolean parameter, to the hook functions which variant it is. > > Fixes: 6eb43fcf8a0b ("x86emul: support SWAPGS") > Reported-by: Andrew Cooper > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné > --- > Later, in particular for nested, ->read_msr() may need to gain a similar > parameter. > > Prior to nested making use of it, the new parameter is effectively dead > code with VM_EVENT=n. If we accepted Misra rule 2.2, something would > likely need doing about this. Hm, yes, it propagates into hvm_msr_write_intercept() which then turns into `if ( may_defer && false )` in the VM_EVENT=n. But then you could say the same about the code inside the if block above for the VM_EVENT=n, it's also effectively unreachable code. > I've suitably re-based "x86emul: misc additions" on top of this, but I > don't think I'll re-post it just for that. > > --- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c > +++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c > @@ -569,7 +569,8 @@ static int fuzz_read_msr( > static int fuzz_write_msr( > unsigned int reg, > uint64_t val, > - struct x86_emulate_ctxt *ctxt) > + struct x86_emulate_ctxt *ctxt, > + bool explicit) > { > struct fuzz_state *s = ctxt->data; > struct fuzz_corpus *c = s->corpus; > --- a/xen/arch/x86/hvm/emulate.c > +++ b/xen/arch/x86/hvm/emulate.c > @@ -1705,7 +1705,8 @@ static int cf_check hvmemul_write_io_dis > static int cf_check hvmemul_write_msr_discard( > unsigned int reg, > uint64_t val, > - struct x86_emulate_ctxt *ctxt) > + struct x86_emulate_ctxt *ctxt, > + bool explicit) > { > return X86EMUL_OKAY; > } > @@ -2427,9 +2428,10 @@ static int cf_check hvmemul_read_msr( > static int cf_check hvmemul_write_msr( > unsigned int reg, > uint64_t val, > - struct x86_emulate_ctxt *ctxt) > + struct x86_emulate_ctxt *ctxt, > + bool explicit) > { > - int rc = hvm_msr_write_intercept(reg, val, true); > + int rc = hvm_msr_write_intercept(reg, val, explicit); I've wondered whether we also want to rename the parameter of hvm_msr_write_intercept() into something different than may_defer. It feels weird to translate a parameter that denotes an explicit MSR access into one that signals whether it's fine to defer the operation or not. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Jan 30 14:01:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Jan 2026 14:01:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217592.1527007 (Exim 4.92) (envelope-from ) id 1vlp47-0008NS-Pq; Fri, 30 Jan 2026 14:01:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217592.1527007; Fri, 30 Jan 2026 14:01: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 1vlp47-0008NL-MV; Fri, 30 Jan 2026 14:01:39 +0000 Received: by outflank-mailman (input) for mailman id 1217592; Fri, 30 Jan 2026 14:01:39 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlp47-0008NF-80 for xen-devel@lists.xenproject.org; Fri, 30 Jan 2026 14:01:39 +0000 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [2a00:1450:4864:20::42e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2d71874a-fde4-11f0-9ccf-f158ae23cfc8; Fri, 30 Jan 2026 15:01:30 +0100 (CET) Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-43590777e22so1369281f8f.3 for ; Fri, 30 Jan 2026 06:01:30 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806ce56068sm192940895e9.13.2026.01.30.06.01.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Jan 2026 06:01:29 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2d71874a-fde4-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769781690; x=1770386490; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=wfzMo+NakLZygboHWLa1nAa4V5nThGPZmL5ZVtFLazU=; b=K5d9KzXuYIcTckVLtIcFPgNxnWvhnFlvYpZebkJh0KgdqtS1dI7tMxfhWDKp/bmeco uxFbsSktYKqyjjzr1GLhry7y3nuX+dFLMJ3q6WVh65BzzYlLtTbrlZrtt7q6XGi6mB14 Os1ERRwLVM21+pWCFzXbnyp2xyIbaWIjh3/oIYn1BijvNIOXdc8H0mxlInipX6Xe2cvo iWmtCx2q1LqzIBXlXwMCEswjP1OFoj8UerZGzNwLkzXaL3+ePg7/1UHPd+UhBQSETUq7 YDph7nCJfsl2FngiIQym1ps4jFtrOSlJaSo05EMgzJ6aNrKrE7O/4s/KlOdhPZKUH6w+ uN1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769781690; x=1770386490; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=wfzMo+NakLZygboHWLa1nAa4V5nThGPZmL5ZVtFLazU=; b=d1WtfavBA8djGL0ZgOk7zp4ag6/2NkzBO8xMhMMo1KEEPJxxtU9cG5k5SU6iEvMiYH xSp8dtjdBB97gKaNWYwd7sPA0Kx1ndEdMfLX9Hgs/mYuH0p2tJto3l18F08keJ2fc2uR /grJ8U2mNdhpXL4ypRjcUqvwK996r73XMPyvV4EtCMD1dJvqmAUgokHBLRpTVPu+rSkn GpGuve6cOeLhM2DjpWxo8fNyxhOUIUPFS+KZqzsVLF9ZhWq5rywnE53VvEay4eLiMsJ0 JEHdYiDBTYm6hARZditS96kybj9BR+dg/gAlJ9fl7pOD2UFtscCm5Ts44MVzMW0xIhdR NErQ== X-Gm-Message-State: AOJu0YzWZ17AopsLkkdOwFYixWZ/7n6mVTBEHGc+C846V9A6vCodNQtr LynTMtRoEq+1yHP5XxCGmMbBtiHwvTZcw2vAjA4wLMvHbC678IQVlGeCHX0oGjlJ0Q== X-Gm-Gg: AZuq6aKkQKv3SluvsDqNvf91wZYIK+1Msonw3ClX0Ueje1BweG1FLNndwe7glRf1fCP tviWBzv1OKoCPJnC+bv/ZqqNLOEFIBw6oGrdeaeVW5xp74FGVAlMtGYLQxQyozR1xyrD3B4rO1Z oCElaDNoMGjkhqcxSwbYJ8y4ls1yZidcDZn2yh8ZVF3YsfqzASVj27hez7IzEsg+lPUXmfiLJG0 4CRsWZY392fZxx9QE39UZKqQmO3LD7JrE4FVYkTKLT0y7KyaWWuE/Blk7DGQEbC43gzMxBHbVha LMOVD6UhwEgv+EfDY+Utbss/SqdCS/S+o185ubSfnSgsLEwjNJP4r7PDGbkDOSBAR+ZpVuTU/VV oBmaf8TYndOhDx7CtFGYglTYUPKi7e57pwQRUelYfk+aAAJoQ1mGHLmTvpxTHR/EgpeLAhF+3vd j6KwnrmO1brJyoQU+9u+fizaFkqF+fP0YnxAoGIJsgDw2FEArJQJBH6atT7/KQ/qAupiyCHo/Iz RA= X-Received: by 2002:a05:600c:b8a:b0:477:9b35:3e49 with SMTP id 5b1f17b1804b1-482db4525b7mr34418325e9.3.1769781690003; Fri, 30 Jan 2026 06:01:30 -0800 (PST) Message-ID: <3743c709-90bf-4a4f-90b2-04935881436b@suse.com> Date: Fri, 30 Jan 2026 15:01:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86emul: allow ->write_msr() to distinguish origins of writes To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper References: <7987f1fc-5b5e-40c6-866e-ac332097c635@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 30.01.2026 11:00, Roger Pau Monné wrote: > On Tue, Jan 27, 2026 at 11:21:06AM +0100, Jan Beulich wrote: >> Only explicit writes are subject to e.g. the checking of the MSR intercept >> bitmap, which extends to VM-event's hvm_monitor_msr(). Indicate, by way of >> a new boolean parameter, to the hook functions which variant it is. >> >> Fixes: 6eb43fcf8a0b ("x86emul: support SWAPGS") >> Reported-by: Andrew Cooper >> Signed-off-by: Jan Beulich > > Acked-by: Roger Pau Monné Thanks. >> --- >> Later, in particular for nested, ->read_msr() may need to gain a similar >> parameter. >> >> Prior to nested making use of it, the new parameter is effectively dead >> code with VM_EVENT=n. If we accepted Misra rule 2.2, something would >> likely need doing about this. > > Hm, yes, it propagates into hvm_msr_write_intercept() which then turns > into `if ( may_defer && false )` in the VM_EVENT=n. But then you > could say the same about the code inside the if block above for the > VM_EVENT=n, it's also effectively unreachable code. Unreachable and dead code are different things to Misra, though. It is my understanding that we deliberately permit constructs reducing to "if (0)" in certain configurations, relying on DCE: There's then no generated code for the construct, and hence nothing that cannot be reached. The situation is different for a parameter that has no use: Its removal (in the specific configuration) wouldn't alter the behavior. Hence the parameter and all arguments passed for it are "dead". >> @@ -2427,9 +2428,10 @@ static int cf_check hvmemul_read_msr( >> static int cf_check hvmemul_write_msr( >> unsigned int reg, >> uint64_t val, >> - struct x86_emulate_ctxt *ctxt) >> + struct x86_emulate_ctxt *ctxt, >> + bool explicit) >> { >> - int rc = hvm_msr_write_intercept(reg, val, true); >> + int rc = hvm_msr_write_intercept(reg, val, explicit); > > I've wondered whether we also want to rename the parameter of > hvm_msr_write_intercept() into something different than may_defer. It > feels weird to translate a parameter that denotes an explicit MSR > access into one that signals whether it's fine to defer the operation > or not. I did think the same, just that - considering all use sites - I couldn't even come close to thinking of some sensible new name. Jan From xen-devel-bounces@lists.xenproject.org Fri Jan 30 14:26:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Jan 2026 14:26:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217620.1527017 (Exim 4.92) (envelope-from ) id 1vlpS4-0002nn-MI; Fri, 30 Jan 2026 14:26:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217620.1527017; Fri, 30 Jan 2026 14: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 1vlpS4-0002ng-JS; Fri, 30 Jan 2026 14:26:24 +0000 Received: by outflank-mailman (input) for mailman id 1217620; Fri, 30 Jan 2026 14: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 1vlpS3-0002na-23 for xen-devel@lists.xenproject.org; Fri, 30 Jan 2026 14:26:23 +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 a5134b5d-fde7-11f0-9ccf-f158ae23cfc8; Fri, 30 Jan 2026 15:26:20 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by BN5PR03MB8043.namprd03.prod.outlook.com (2603:10b6:408:2ab::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9542.16; Fri, 30 Jan 2026 14:26:17 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.010; Fri, 30 Jan 2026 14:26: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: a5134b5d-fde7-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Re/fyCKarahq8nlKwHC/r2+q3cKOEOTHSSKu8aIkIdNjnLntWHNxAF3/YWjmWmXHe+aWgr7li/BgHUxz397j7S6qz21/jD9KtvAAe3oa8twNZb0y5fRB4K418Kdp0bGzPH8tkCiZ6rgjVCRdBrIhLSceik0d8K0VLOXVVq1CtiVXun8nWBjmQVSFK4oAcy6UbiewprbhqdY7t+kqKvIjqKPQSV6gGh+yxf+yCIYKb65+YWyj1ydr21SkfzCfZ1IKGllFfF9f2B7lTXKdoJZqROl+8+iL4RvmHf5P/lT49S6so7tqAcMh6DWqpNniGEqOVcboZJ6l1tH91HDtZqdv0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PqBZceQU8Si33A1G4vH33efcvvXOMvAWcQqV0kmX25A=; b=ZDOMrjuYTmx8wGp0OAVwxQsi60ndFMRWCIQSAwTm9PiJI+kSSv4rcEGeyge9lnZ/nzzKXjQsOr0/iZPCxKAjR/K4NxQRudue/QHKakuOvAAgwPsRVCr4C8YzSRqTpibswaN34ds1JjrKryezyoGQi7fUGZSVWMv28PZEF7Qq0Mfx1rXw4B+6f+JglrowQXsxmho5bUs//3jSiRcAP/k6jo+MAxVRSi3zcYsyjBE8Pz0hYVEUaPodp9cp7giyYo1gYWntjSTtQPcqbeUjxFq2GKOqqnPb9KUY2EpUmcvyQMSCnsb58y5AdulxFNVUGic+qWgJpky6Yggq9T1P2AHzdQ== 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=PqBZceQU8Si33A1G4vH33efcvvXOMvAWcQqV0kmX25A=; b=xeuV/QLv6xGwgm4b+OSsc+R3ZO5gIcCE+O9pD5LcVLaQi2G/s+i46moMJKRNYx5u6Vn5Uma+bt4Hv8J1NTOHltKIv9tgIw6vkO9oBG+UedAFYxQqWw95gtss0OBWi4UH9al3a0Mo7LvxDRaUOS5xXHpU6BGsViq+j1bFzFdQXkw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Fri, 30 Jan 2026 15:26:12 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH] x86emul: allow ->write_msr() to distinguish origins of writes Message-ID: References: <7987f1fc-5b5e-40c6-866e-ac332097c635@suse.com> <3743c709-90bf-4a4f-90b2-04935881436b@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3743c709-90bf-4a4f-90b2-04935881436b@suse.com> X-ClientProxiedBy: MA3P292CA0064.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:49::16) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|BN5PR03MB8043:EE_ X-MS-Office365-Filtering-Correlation-Id: f3cba892-ff0a-40cd-0108-08de600b86e2 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?RnJBOG12VEFKSGtMTkJ2QXhwRjhPSnNQSXRaQ29Dd2EyYS9hWFlUZ3V3RGNJ?= =?utf-8?B?V0NZdzBZczNPa3c0bFhPMEZQVUtzUnJzaFRsVjVMMFBPVXFNOGptVXhIcE5t?= =?utf-8?B?a3NJdTVHWDlIYklid0orbFpTcEw5Z3NhQ1l3ZDVlUDBNeGVsdURORVgrSnlj?= =?utf-8?B?bkwyNmRGTXFoMTN2Wk44dzBlNkxKUHBVSDQvZ3diUUpEWlRMWUVNajVyQWNL?= =?utf-8?B?N2t2M282eXo1bWgyNThBby9HaVJLMHNaYmM1MEY1cXNDK1MrcVVONVRrMUVQ?= =?utf-8?B?aUVOemZmZzN4bmJLUnNubnlaWHNnQXd5cWVTb2QvYzlsUjhUemNWU1p5cWd6?= =?utf-8?B?SDl6eGliWU1LLzM0MldEN3QydTZCYnZkNStyK3l2Z0dRdXdhaXhja2NvTXpz?= =?utf-8?B?M0F3ZEZ0WFRUbTZEY0hmN2ZoSy9OWU5ydk9ZVy83ekZrV0l0bW5KSk4zM0wy?= =?utf-8?B?UUEwOTJWKzZmRE1Sa2hSVlA1WFVBVDFsU2MyS0xKUkNLdmZYSTFnaGMxemYw?= =?utf-8?B?a05nd2tXdEl1aTdxclg2dDF5cmVKdEN6aDlHQ1djTzgrZVNaKzViSEk4UVI1?= =?utf-8?B?NVBTNks0dXVQU2x3K09EVVo5K2hURjlYc3hlekgycmRoaktHUC9yT0JVWXlU?= =?utf-8?B?VFZoZ1dORDVqaTRVb3ltTVZmQUkzWVAzZzJpNFN6b3QzQm5JenJTTUtQNmw5?= =?utf-8?B?ZjdXVkFoL3VzSmVsb0NqS1h5S3NYZi8zZDRqU2xvVTVGaGVYYUZkb0JqNGVk?= =?utf-8?B?Y1plN1E4ZU9iRlpQU2RKTXBHVVp3NXJweUNlVk04TUVtUWdGRkpyZGFOUXRG?= =?utf-8?B?VGtsY0hEaVhrMVkveDdmWFFmZW5sdmhFcHN2dkg4dEtHLy9ISzB6YWNIL2dh?= =?utf-8?B?VXFQa0hCOHoxQUltcjBJcEloMU5PVGNIcUs1Z3BCWUNVZEM5aXdsN1FsT3Y4?= =?utf-8?B?ZjBhdEE0dFBvNlVIUE1jZ2xDcm1Mb3ZOUlFOZWQrQVFDcEd2aUtFd3J5TGQx?= =?utf-8?B?TUhGOEtTOGZkYnV6M25oaDk0YnhIVTVyczlWZG9CRHFiak9ZdHNocThuZVVz?= =?utf-8?B?YTVEUFlQNitOaUpMMzdQNWpDdUFCNVhOQjY2Y0g3bTZLaGROVDBaL1RrMTNO?= =?utf-8?B?M2h2QmJIUzJEWk92c2xkV0xoRFlwYVE2bEFPR1lLQnZ0SUtQOXJLcFFSZXp3?= =?utf-8?B?YWFLWWJ6Ynk1bFliTSt6YVAxcEVsZldudGh2c2JlMFNZcVpMK3NHVkQ3WmJD?= =?utf-8?B?YVFaSUhXbGF0ZUw0NHpzSDRLbnJBR2FTY3U3enpIZFN5MjRlTnhJNVBhYXNl?= =?utf-8?B?Mld1Ykh4TDRUWjk5RkNFa01DTVQxNlVmM3VERVZ5RmpZeUxLa1BpbHlhM2Nm?= =?utf-8?B?anJzcDNIUzIxQ3Rkd0F1M2ZmcWFGaFBGS2lNV0VPZWR0dWtsMmFqcm9rVTdL?= =?utf-8?B?cWZnVXIyQUFrQVYyY3U5cjJZWUdFbVZpOFh6Qm5LSHNhTXNsZmdUSUFUemZL?= =?utf-8?B?QjAvTlY4MUQ2RG5BRUdkanNsK0lHdnJTdHZtTS9yZ0kwODRhTCs2dk54UTFv?= =?utf-8?B?U0pOTm1HaHV6NmRlRDFVYjNwUk1YeWVjS3B0VlZHNENyTTBNek41ZzhMOXdt?= =?utf-8?B?UnRrUmJVdnZnMWdSR0pWWkcwejE3bi9MNklDa0RuVDZuZll2VWhaSjRlOGpC?= =?utf-8?B?c0JyMFNOK0VtKzc2NnN1WndZUzJrU1hTWUZVOExWZUlNZFhrOUNsRlltWVdm?= =?utf-8?B?NjlFaEYxOVE0MmplWHA2UE43L054a2hjVWtCRGFiWS9Ec0hwSFJzWHphQWov?= =?utf-8?B?ZjJPREk4RFdVRnJlQk5MdXByY0RkWUZQenRFSnZrbGhwcXB2TW9MZENTZFJh?= =?utf-8?B?Rm5HMk4rZDU4ajUwc082R2tiNzJvYmozMDNYOTNzSGFwL2FmWmcrTlZWaWx4?= =?utf-8?B?UHBFSTVQM3VPbXdPRFhFQWlqN0xqV29kVlRaWU44d3Y0VEZSTTdGRnhwT0xV?= =?utf-8?B?SkQ2a0piMWhINEJhME9qYytkb09CT0o5S01lSGE4U1YyenhMM2xJOXBuN0d6?= =?utf-8?B?a0l3RC9yT0cyajdnS2FhbUhzMDQxSmFOV01tUXhsU1g0Lzl3UmRValNML2d0?= =?utf-8?Q?0dyw=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dnc2M3ZuUm5senhNcEpRc21QUlRvam1LQURtRmtoMXJma3h4ZkFqUHVEZG0w?= =?utf-8?B?bDdSR2FQbHNwRkFZWEM2LzZsQUxqRTNjNFJZRTloZk1YeW9CR3BOZ05BdDJI?= =?utf-8?B?VENYdXVxR01TbGtFaWhPVER0TEg0NmhtSEd1cDlkOURWUXN2eTZpczhTM3Nh?= =?utf-8?B?SW1uZzlVMUsrNnVSV2pTclpqcWZYVDhpNTdjSTVoSHAwQWR6d0s5UlJEKzBH?= =?utf-8?B?WGZNZEpZR3VlR2FmL0JIK0JYUk1WSGc3TXBhVTFqdWRzRDJtdW9FUlpMOUw2?= =?utf-8?B?Z1FlSVM4eFgzTHNXRzRoRWJrZWxvbnp0bWlNR1MwOG5EVGVWZDV2QTE3T1dF?= =?utf-8?B?UEladGhIdzU5Nlh4QnB0aXNtQXdqS3dCVHRnUVUwWTRGbVowM1BJelk2Wkdm?= =?utf-8?B?N2lEQXh4dFJ3SDA1em1jKzJvZms1SC9FNGd0MHVtcWQwcW9EKyt5K01LcFNk?= =?utf-8?B?TUk4czc1ejVoUmZoc1pnWVdxUjBZV0NkY3RrNXBlTG1JaDExeTg5cURmL21u?= =?utf-8?B?SGZXVEx5dEZ1V0lvZWc0Nis3dVErb3MxRlpib1FqSjluL2RUWkxKWDBLYmUz?= =?utf-8?B?RHhtbkMvcWt3VWVGQzlob25rSnFwTnhXa0RGNmxnSVFOaW9pemtQeHcyekxD?= =?utf-8?B?R0R2RFZMbmFydmNxc0tqNDJueFNWTXR3Q0IyL01VVGx1ZExCVzFMOEtwYzBU?= =?utf-8?B?OXVoTndVL05oQWoyTW1pYWY5NVlKSTFDVTZxVklXOGc1OUpSaEk4bmJ5TTRO?= =?utf-8?B?RnV1clhwSURnaFg1YWE0blB2UkZmelNSVjNDM2t6ZW9vTzZXL1kvZXk0Nm5y?= =?utf-8?B?cE9PbWZOTlFMRW9Lb0hIK3RIcEc3QXdURWJJNXNEM3dUVGdvOHVGdHR5VVA0?= =?utf-8?B?ekhiejR3b1hHOUM0Mm1nTURsUEV1Ky9aZFd4VTN5VXRDUFVxa24wMkhUdjdk?= =?utf-8?B?THRRMm9wL2NibjVQckRTS0xiSFZ4TnNCWENHb3dUZkdxRUwwV0ZEangzemJP?= =?utf-8?B?YzBhVDVIc3BFNnBsTkFRWGlTVkVMT2FVWllNRkVrbFptQjJiL0p1SytzOUM0?= =?utf-8?B?V1k3MTgyTnVVSEZBNWhHdmZxaTNjMm9oMk9mTjNSSWZZcnJMUEpiNUJ3NGNz?= =?utf-8?B?UFVIRjRDaXpXRy9ReVU4bzBYR2xYaTVlTk9EUFJnanNJUWluZ1dPRlhjTUpz?= =?utf-8?B?Um9NL1hzSC9SS3YzdVZXVlg5ZE5CeXptQ29qUWloM2I3ZTFQYjF4RFVCdE5M?= =?utf-8?B?SFQ4V012QjMxRGJHYUJQTk5LSmJ5UVM1ZkorQlFuOUhTNDJjaXJNMHF0NjMy?= =?utf-8?B?QmNHWElEelIvUjAxZDVHQ1kvK25GOEo0UGs3YzRkeHQyM3R0dHJSeG9ZZVFU?= =?utf-8?B?NXZBK25OS05QanA2elM3Q1gzMW5RZlcyL2hwL0JlQ3ZGZ3ZOR0w4akw2MS8r?= =?utf-8?B?VmNraEdOVjVCVFZPSUh4cFBpQjRjbkkybWN0UHFROTJsTzF3SFNnOXY1WUNy?= =?utf-8?B?NmRuK08vdlZoV2RVVUhxU3RMWmJjWDMxSFRBeVpxM2QyVU5IMWNqa1JFL1ov?= =?utf-8?B?dFoxbnFWTmEyclJ0WTdLU2dudWxLSGd1UnRCSzExS0xuWmNkaHJHeHVVWGJE?= =?utf-8?B?eHROQ2J0MEtPNkZFSHF4TE9TaEV5VXROcnhiTytKUzFiRXlOV0M4Z3VqZFdI?= =?utf-8?B?Z3hCL05Bc3RlZERHTFZDQm5OQ0c3K2NiSUZiSnY3ODhHZ0hTQWRxZTBwc2FQ?= =?utf-8?B?ZHU5cEIxMThUUWdUQjRRVWt2UlFvRy9Ia3ZvK3M2OHg1N1V6SUVTUHVyT21t?= =?utf-8?B?TDZWSjBWZnYycktFeVdGYXlsWlZhWmVDTUJIcGZMdjFtclNCVEQ0WHRsVkQ0?= =?utf-8?B?WFFrSzF1cDc2dXdRRWcrZ1A1SUZQdWo5THRkYjAwVUJGYVFaQjlKQ1lsTUdR?= =?utf-8?B?TDNJRitoRkZrKzI1V3EwdjFNOVNGaVlrQjVad0k4RnJPS0dVMTJDSk5KWHpS?= =?utf-8?B?bndtMXQrOVlSS0NwQ1V1RTBwd2twaE1OY3RqemVUMUxwZ0VtMEh6Y1ppOFBx?= =?utf-8?B?RlBnR2NRdm5ibnZRNEJtYUR4T3REQU1EL25KeVFsd1BHR1dRNzBXblk2NDJC?= =?utf-8?B?UlpvSWhRalVKWklKUEhYeVc2KzR1Ym9SSFVwcXc3Qk9RejlFRE50SFMrcGpJ?= =?utf-8?B?ZGlFRFFqbXJpU3ExZ0lGeEZrNGJWNUFMTXgvdlFxc2k5NHpTK2R5SGs5VTZ1?= =?utf-8?B?dFgyV3ZzMUdnOGMzL0RrMEF1R2ZnRVJZMkRhSHR0ZUluSUJUL3hrUHdZUHJj?= =?utf-8?B?ZmlqWGJEbHhITGpXOWFsQnV4Ly95NGYxOXdBelhhUWNzbnllQzFqUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: f3cba892-ff0a-40cd-0108-08de600b86e2 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2026 14:26:15.9192 (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: HEnWkUwOkGQqycapVJBY5CrytBdxyqZ6EV4NZZhvkzdN0480bfSqgJyQb+oaN7nOr+450Erdk1s6iLFcbh+rTQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN5PR03MB8043 On Fri, Jan 30, 2026 at 03:01:28PM +0100, Jan Beulich wrote: > On 30.01.2026 11:00, Roger Pau Monné wrote: > > On Tue, Jan 27, 2026 at 11:21:06AM +0100, Jan Beulich wrote: > >> Only explicit writes are subject to e.g. the checking of the MSR intercept > >> bitmap, which extends to VM-event's hvm_monitor_msr(). Indicate, by way of > >> a new boolean parameter, to the hook functions which variant it is. > >> > >> Fixes: 6eb43fcf8a0b ("x86emul: support SWAPGS") > >> Reported-by: Andrew Cooper > >> Signed-off-by: Jan Beulich > > > > Acked-by: Roger Pau Monné > > Thanks. > > >> --- > >> Later, in particular for nested, ->read_msr() may need to gain a similar > >> parameter. > >> > >> Prior to nested making use of it, the new parameter is effectively dead > >> code with VM_EVENT=n. If we accepted Misra rule 2.2, something would > >> likely need doing about this. > > > > Hm, yes, it propagates into hvm_msr_write_intercept() which then turns > > into `if ( may_defer && false )` in the VM_EVENT=n. But then you > > could say the same about the code inside the if block above for the > > VM_EVENT=n, it's also effectively unreachable code. > > Unreachable and dead code are different things to Misra, though. It is my > understanding that we deliberately permit constructs reducing to "if (0)" > in certain configurations, relying on DCE: There's then no generated code > for the construct, and hence nothing that cannot be reached. The > situation is different for a parameter that has no use: Its removal (in > the specific configuration) wouldn't alter the behavior. Hence the > parameter and all arguments passed for it are "dead". Yeah, I think dead is a good definition, the variable is possible evaluated, but it's value doesn't change the flow of execution in the VM_EVENT=n case. > >> @@ -2427,9 +2428,10 @@ static int cf_check hvmemul_read_msr( > >> static int cf_check hvmemul_write_msr( > >> unsigned int reg, > >> uint64_t val, > >> - struct x86_emulate_ctxt *ctxt) > >> + struct x86_emulate_ctxt *ctxt, > >> + bool explicit) > >> { > >> - int rc = hvm_msr_write_intercept(reg, val, true); > >> + int rc = hvm_msr_write_intercept(reg, val, explicit); > > > > I've wondered whether we also want to rename the parameter of > > hvm_msr_write_intercept() into something different than may_defer. It > > feels weird to translate a parameter that denotes an explicit MSR > > access into one that signals whether it's fine to defer the operation > > or not. > > I did think the same, just that - considering all use sites - I couldn't > even come close to thinking of some sensible new name. Let's leave as-is then. Since maybe_defer is tied to the monitor logic it might be helpful to give it that meaning, but I'm having a hard time coming with a proper way to name it that's not too verbose. Let's leave as-is for now then. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Jan 30 15:00:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Jan 2026 15:00:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217650.1527036 (Exim 4.92) (envelope-from ) id 1vlpyi-0007y4-9X; Fri, 30 Jan 2026 15:00:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217650.1527036; Fri, 30 Jan 2026 15: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 1vlpyi-0007xx-6l; Fri, 30 Jan 2026 15:00:08 +0000 Received: by outflank-mailman (input) for mailman id 1217650; Fri, 30 Jan 2026 15: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 1vlpyg-0007Ra-P8 for xen-devel@lists.xenproject.org; Fri, 30 Jan 2026 15:00:06 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5c2cdf50-fdec-11f0-9ccf-f158ae23cfc8; Fri, 30 Jan 2026 16:00:05 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by BY5PR03MB5329.namprd03.prod.outlook.com (2603:10b6:a03:22a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Fri, 30 Jan 2026 14:59:35 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.010; Fri, 30 Jan 2026 14:59: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: 5c2cdf50-fdec-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QdSFwI8CbbaT/VSru3+8GrBlUltiG64RR6XfFjabBRlFjJSzLGneaYqVtlVwVIWMR+auY9ncuHzMGVhjPdq/8XEs5EwfKRIeeTLC5tGxc7PHAZSjrbQ12I9kiVAHDiFE+s0B8ku+Fv3FF8h6wCnJ5InAT+WYtCimEtuyCdSJxxTLG97FeXWq8gYAQyBBxAA3qoD1qzOJXOLCR3qBFFgP/RqZHrH+yKyMX2fQzdP7Ag6fenZk/oiOXXQWe3GuUT5Za4sHt6Fa+X1CsNl78hmxx3wApwUWS+Kf4dTPgTvGxqpKgyU8PObOa7tIPoY4wSUy162C7F0dPtpGlpwb3crOww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iq7LypTnBSn8i0P1LD1jgEQls24ME2uQhILN6C907Xk=; b=jQUXci0zbhTSOKSo75UU3Ub75kMZxeJr9Xv3BT/aQLUZybSqoSO0UU8NfR4XfkNaM2az4C8UKimZZS3SJeP8e91NeyQ1BeV2rtpoCQzbXUtF1Jamv16xUfFbP1Ielh3miAch4JG6n+ZV5Hl87zWOALpihcBJ9Mix9s5kZqRwPiGeP9eTIzhIeNJ9R9V2TI140EOw3ALmZKKYxxGIgvs6F/4Pw6BM0BgqlNCiUbI8AoxdqzTHjf+EUt4sYlSl6KvCaMPN81mgqAaWlqm++bH4dj0arJQN0dG4h5M7eBRLCi90KptyiTy3MlyG/6Zs63UvVR/7DmEz4qr61OMYUfK7yw== 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=iq7LypTnBSn8i0P1LD1jgEQls24ME2uQhILN6C907Xk=; b=AJiE/oDdGtKikxtkVq8gku66Gh+tGBx+XZJQfl+INLAn8Dc7Xzwv47PvDyV6myhv+Oc4JMxWMLrh3vROJCFORt7JJoFZOS/lSFnab8JNcwxQuTpppq+L84bArshMc4KkiLYVqRgkB3tyS/YVxMX1qSmA5/CV0MXK8gtbyzzqx/w= 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 , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , Timothy Pearson , Alistair Francis , Connor Davis , Oleksii Kurochko Subject: [PATCH v5 0/4] xen/mm: limit in-place scrubbing Date: Fri, 30 Jan 2026 15:57:22 +0100 Message-ID: <20260130145726.85907-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: MR1P264CA0129.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:51::17) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|BY5PR03MB5329:EE_ X-MS-Office365-Filtering-Correlation-Id: 6793c20d-86f2-4277-280d-08de60102eb7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7416014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?cGtqNFRISXUrQjRQVkMzSlZGbDlUV1NwNUFzcExHdzlEL1NuRXBHc0hqenNV?= =?utf-8?B?aDNTQWlaZFBUaWdQYTc5RVo1TTRDNVoyd2dhdzZUT3Vmd3VKVC9FMms3RjhS?= =?utf-8?B?RGwxU2c2K3hEenduaGdxdng2VHpiUU9vWnN0dkVtcG9NT2lqdDIwWTg5QUd5?= =?utf-8?B?VW9aUXpUMFhlWEdGMmc4UWtaWVNwTVQxNmlRVDh1TTUvekNmUzZ5S2dCbVhv?= =?utf-8?B?YWxPNGFmcjUxb3RKeFJ5MTkvaVRtVCs0ZUtJVHpUSXpRczBFRlFLbDJ1cTFQ?= =?utf-8?B?eU5vTmJySklOanFNZU9nQmRRSFJaWFlVbHJEeDlTQ2x4YWdKMm5mWFkzZ2xo?= =?utf-8?B?NE9Sb0UwRXh4aFh2TUg1blR4NnV0QnlSbHJhWWs1MkFFaWpzUEhUTlV5U1Jh?= =?utf-8?B?SytRUVgxd0hidHJLSEhweG0rdWNvNXpUeHRlbUlqY0RlY0NnVGxieEQwbHBG?= =?utf-8?B?bU1NK2YxR2NjdENocHY1aFdKK2xjeGJCK2Z3V1hLSmxkc0lnVzZaY0hRbzJZ?= =?utf-8?B?T25mTzg2dmZ0MzF2aDFJU3pQUEJqd2h2SlNVdWJlR0w4UFFmSHl1SUJEc0RM?= =?utf-8?B?ZTBPb0RRUWJ6OUJGdStlb1lGTno4bDd2eW0xN1MweDlnTmgwWFJUOUFCUWV6?= =?utf-8?B?ZThYT25PSXlwZ1ZxRCsxOUZxY2R4ZVdyVkpEYXAzZVlUYlA2MmxBOTBiSStS?= =?utf-8?B?V2VNNHRzbmR1a3RpRWsxNklZSC9iVWMrNEtYdkZYeTR6REFmZUNndExxbjZt?= =?utf-8?B?UmVORXhmRzdCeU9ZNmt1VllwN2dTemhCUjlmUWpKM3czVFBQV085NUttWDRC?= =?utf-8?B?QjlnNko1R2Flcy9Ud3phY0szUmVkaDFmRWJoUlVJM3NQMS9nL1FmU1BoMVBs?= =?utf-8?B?N1FRY2Jsd3dSMytkM0xPdzVYbnF0eEp6ZTY0SXRIV0JSaEdpZGN2ckREbW1a?= =?utf-8?B?R293NUQySDFRaVRud3E1ajBLN2t0MWNja1Q0TFVMcTNjZ1ZMRnJNZmlJS3Q4?= =?utf-8?B?ZXNTMzJIQ0FjS0RiMzlYUzhOL3dUeXJrQU0rQjZrMG1EcERZMHdUSUMyS0dT?= =?utf-8?B?SE9qdE5sS2lGWTlnN3pSamo1WFA5eGg3VUR0YjRXK1dnNFp5bGlidkd1RXUv?= =?utf-8?B?cXRrNkNXclNXSzFpUzJMQWJqanpIb1RRQnpzVmlPWTRnUSsyQ0w1aHF1am1L?= =?utf-8?B?dWVLaXFnYzYyVWNYVUF5ZktRTXQ5SUxCNzEzbmRTeWFWY2xyTElOTm9JeEc1?= =?utf-8?B?N1huVUtLeG1xd0FJeENGM3crR1B3Njd5NklxL0JNYmZKSk54OHZua0lvSzFm?= =?utf-8?B?bElrWUVvRmxsZGlwYi9UcWpYSlZnMFhpUmx4ajBicmlkN0xDKzRYa0hJL1hQ?= =?utf-8?B?T1BxSU03ckYyQndxT1VUQklUZnAxNEQ1dTUzQ1Y1Y1JWNWc1QWJQYXZJcGxO?= =?utf-8?B?OHZhbUloUU9Eb0NTOVoxKzAvU3gxS3pYOGN1MnlCa3hyZHh6VTFOY28vUEhj?= =?utf-8?B?a2N0OHhiSC9UVGhVR2JzbEczbEdqcTZnSTZqTUtxVk0rUFhKeU9GSGE5MTBw?= =?utf-8?B?QTR6VjB4SFBiVEN4aGx0NG9ja2RlaW9IaTcxQjk5REVYK0MveTlLZjJWSU52?= =?utf-8?B?K0ZPYXNQUUpOWWQyclB3Yml5TndCYml2NW00a2JWODNEczJIc0JOQjR1SEc3?= =?utf-8?B?WHZTVkFTRS9jT1BrRTZXaXdabnNLbEh4aG9BQ0NMZ1hoMDFYRWNUNk0yTVRk?= =?utf-8?B?MllQclNNVXdQV09QNVFsZEk4UG1jdWl5TGNWOVkySStpWThmUUV5Y3BpUVN1?= =?utf-8?B?bW56WXJQYWNEK3ZZdWJLbitIcGNreVJNaUFGUk5TQWhVV2s5ZS9DODBoS0Ft?= =?utf-8?B?V29MaXlkTU1aalBXMVdlZU1PTTJkMmFSbDVkcHJ5NitWSTFiZzJDTUZlakVo?= =?utf-8?B?dzhSN216UXZ1YmRoNGdhdEVwUkJoeTdpNmpoejlwUEo5NHptQjNSRkNucnNx?= =?utf-8?B?ZjRvaW1QK2kwcnZiUTYzVFVnTFJYOUpIZVkraitMbFlvODlYb0Yyb1cyNVpn?= =?utf-8?B?ZnJMbkY2emRyUWgwM3JFMjFnSFNvQjNNVzllL09VZ1NqcnVMVk5yUnVhZUxI?= =?utf-8?Q?AWZY=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7416014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?V0l0LzNaWk15NDdrQkZvRmI4UGc4YlVkRVlZdXRnTm0xOGYzSGZ1UjNvaXpW?= =?utf-8?B?RzZLYldYNkREVmV2WUpSN1NxTHNsY0pFL2x0cEd1MktXakU3NmtHZ1ZYRTY0?= =?utf-8?B?QytKMWpGR3lYU3p4UkxaZnR1N0RVandlNTdMb2NCNXVjaTVjZkdoSEZtenJa?= =?utf-8?B?bytTVE9MMjh2bFNRWFVtZmIxSkRGY3dibVpDUlozd2lFeGF3dWZFYmlVMngy?= =?utf-8?B?ME5xTGJKbERxd0pNQitkRjJET1lMN1U5Y2ZpZjg2Ynkwdm1ibVJLSlpOdTNm?= =?utf-8?B?OGFwZ0ZzQmhGam05bGdLMFM1WmxGTk1PbGF3K0ZhSjBBaXc5dC83a3d6UFlD?= =?utf-8?B?Uk80MjV3bmlpK2ZlaGJCU3lEMkhkUFJteVNYeGxHSzJiU2xIcjIreVpIUnFw?= =?utf-8?B?MkcwMDRFYmcxa0M0dXBReWRlZkZNaE41OHpHVzJZOW1yNGpwN0RZcTFIc3Ja?= =?utf-8?B?VUorb1ZWUVVqVHYvOUYvVTUwb1FnSzBvTXNJMm1hMGZ0QXdZTjBXNk9KaXVs?= =?utf-8?B?Q2w1Z3pwY1prRnVjeVBiQkJaNCtmUG9iUzRoL2V1bmpiYlM1eVcreGk4bnp2?= =?utf-8?B?Q01adUFOZ2lQTjVON2ZyUzdoWHVVRHpiZ0xOZXhBMkZKc2pDWVpOZHZma2dp?= =?utf-8?B?L1l1M3RGaDRXTkd5WG5ZU0ZMNEg3MVNqbzEyelYrT1VrNThlekQ3Uit4R0NT?= =?utf-8?B?NmxocUFxOW8ybjFad2dhTG4vS0llbjh6RGVXQjFETHBPOE9SaGF1ck8ydWFZ?= =?utf-8?B?Sm95WEhJdXMyenNXL2MwY09uUFZZU0J6aHVZWDF5U3NrVXRYZi9Vd0JZK3Jm?= =?utf-8?B?a3dIaEVldHdTd0hNNENneWVmdW83eEduQjlSY3gzTkQzazRnZFFOSzBkcXVs?= =?utf-8?B?YmVMVnZaMUo5SklGSDRIN1hNLzk1Zkp6S3VMNWwyVlkvTnRiUkMxVnJSRjh1?= =?utf-8?B?NUlTdGM1NUJTLzl0by9lZ1ZaQVZPaGplbWhGaWVrMUl4M2plQ2VKKzRpMUFW?= =?utf-8?B?Ni96dUJXRnhzZGVMQW9yYUR3V0dsb1h1d1FGelV5WFlnYnFKYUUzOEFMREFw?= =?utf-8?B?N0g0OG83NE02MkJCcm8wM2o5bGdQQUVOcDB2TGNDaTNkUEtMZUxCMlU5Y0Vz?= =?utf-8?B?Nkwya1lob3VkV244bGtIeTRpdDRhZVUzMzJXb2UxcnRyU0lIbG1sN3pXajlh?= =?utf-8?B?NUVaWGRpVTVzMmpTNVVWclozOGgvTEROdnJid0hrWGQvelFZeXE2eFhzY3Za?= =?utf-8?B?Q0dHNUVTaTBqWWh3RUtENmVBd3Zjbm9GZzRMUG9BMWJ6aGRHOXhzZCtEQVph?= =?utf-8?B?Rk5hZjVHNlEwcDNCMWFxVVhtOE1rd2w3aWJrU0RjY291R3g3TnJvMzVnNXpL?= =?utf-8?B?UkE2L2RzbmYzU0pPekY1TDZmR0pHeFhhZFJQcm9EdlZDa1l3aGhNOXU5ZHh4?= =?utf-8?B?UGpXZ3c3by9KZlFadXRJMFRvdThQTnkwV0dNU0xGTXRkNXgraEU0YnNWYVFO?= =?utf-8?B?eDhpQy9oTHFnd3A4bmhwOVhYcm8xOTJGOG1DV0VHYkkweHc4ZWo4OUNQN3lY?= =?utf-8?B?SmJua0I4QzdqYUZxYzdsc0xxY0svZ1NZU0VBSDVkZjAyVjM4VXFkaGxNMkRD?= =?utf-8?B?K2JzUVJ4aENEbENUU2dSYzF6VExNTmkzWEhQZE1LY3ZtRCtpQy8xV3RZUlhP?= =?utf-8?B?NmlTSVJ6K3V0b2x6RW1qWUVyVWh1RElnYTlmbklXSjQ4ZjNDNTE2aDFSUDNx?= =?utf-8?B?T2NFRkpkeTNFbk1YY2hPc2JhNStZdlZkb3J6RFM3Q3BHRVJhb0o4S0pnT2hJ?= =?utf-8?B?czNyZU5iMUtvZzM2am1WTXRRSzVic0ZMMjgyNGFnYm1JZmtrR3pYYzh0aGVB?= =?utf-8?B?RmJudld0Zy9XdmJnNGFXL201NklERHJOSGpSczE0VmQyUVZGWk93QXh4czFF?= =?utf-8?B?akVKUUFCQlFwWUJEWWRNanEzRHE1N3UvRWd5cG1BM1ZlZWhEbE90dEwyUlJX?= =?utf-8?B?ZlZJNHFacjkzbU5wSmg0VUEwcFFFY1luOGo0Q2pwdW52ZVNuR0tFNjRka0FJ?= =?utf-8?B?MFFGa3YrVFNPclI5N3lLUEVLV0FKRUdCa09Ja0dKZFVVWXQ1Z25GRGFoN1Ur?= =?utf-8?B?b05QUVVBQ3NtSXJWZ093ZmtkYmdyV2NzN3h3eW85TXRJaitNT1c1NEpubWlP?= =?utf-8?B?bFYxZ1NFVy9jSnNCaWZyVis0Miswd2dJbFZFaWFxS20yeEhBa1JSWEp0eHV3?= =?utf-8?B?YVNicUEvZmVNUWhqVEZBMURBeWVyUng2VVVBLzhQQjFmK09tcVZOdFJ3aFJp?= =?utf-8?B?RzI2bTV6cklwZ1VMNEFOVk1JWWZKY3kzbUxTbFlCbS9oZzZDRlJ4Zz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6793c20d-86f2-4277-280d-08de60102eb7 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2026 14:59:35.5465 (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: K8SzAgH/YVBW6Jmg/nGiUn0bv9CmpocVvwiTbrX3+smP6Gqjj2bJEezg9IKqXCZmPIbEpdISCYDrap8zp1IDfg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB5329 Hello, In XenServer we have seen the watchdog occasionally triggering during domain creation if 1GB pages are scrubbed in-place during physmap population. The following series attempt to mitigate this by adding preemption to page scrubbing in populate_physmap(). Also a new limit and command line option to signal the maximum allocation order when doing in-place scrubbing. This is set by default to CONFIG_PTDOM_MAX_ORDER. Thanks, Roger. Roger Pau Monne (4): xen/mm: remove aliasing of PGC_need_scrub over PGC_allocated xen/mm: enforce SCRUB_DEBUG checks for MEMF_no_scrub allocations xen/mm: allow deferred scrub of physmap populate allocated pages xen/mm: limit non-scrubbed allocations to a specific order docs/misc/xen-command-line.pandoc | 13 ++++ xen/arch/arm/include/asm/mm.h | 10 +-- xen/arch/ppc/include/asm/mm.h | 10 +-- xen/arch/riscv/include/asm/mm.h | 10 +-- xen/arch/x86/include/asm/mm.h | 18 ++--- xen/common/domain.c | 24 +++++++ xen/common/memory.c | 108 ++++++++++++++++++++++++++++-- xen/common/page_alloc.c | 32 +++++++-- xen/include/xen/mm.h | 14 ++++ xen/include/xen/sched.h | 5 ++ 10 files changed, 202 insertions(+), 42 deletions(-) -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Fri Jan 30 15:00:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Jan 2026 15:00:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217651.1527047 (Exim 4.92) (envelope-from ) id 1vlpyk-0008CB-HM; Fri, 30 Jan 2026 15:00:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217651.1527047; Fri, 30 Jan 2026 15:00:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlpyk-0008C3-Dn; Fri, 30 Jan 2026 15:00:10 +0000 Received: by outflank-mailman (input) for mailman id 1217651; Fri, 30 Jan 2026 15:00: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 1vlpyi-0007Ra-L0 for xen-devel@lists.xenproject.org; Fri, 30 Jan 2026 15:00:08 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5d520cf2-fdec-11f0-9ccf-f158ae23cfc8; Fri, 30 Jan 2026 16:00:07 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by BY5PR03MB5329.namprd03.prod.outlook.com (2603:10b6:a03:22a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Fri, 30 Jan 2026 14:59:43 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.010; Fri, 30 Jan 2026 14:59: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: 5d520cf2-fdec-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=NF/3fEv+aVjvTJoXckOAxyfGjJkjZX2ITJYKcBrxjgAr1O3NRMBNzE328vUjN5LpNur3IS68a4wgBgnm12YUkUyv3z6GigQ9xBbYkxLjBiklS8rympkdHI+00YY0mgZGfFtKxlFL4WQh0nEi1MMSRuI4rtxa7PiqrGP7qd95mB5yKZhXIhvf9cBZdcYItSx5a4BeriB/NmxpXplCDCoCaK0gt+80+BK6YRXadjXwA4ONoAFiNlCc38aWIKBnJ1L9o8+cfugpkC+WYKv/ypC28pXAT/LGlx4GIqV1+OJR9TuhPytfR+aA3MgVBpfF66a1z89qXJ/ozGb654FaKOq8+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=VLyvniffw+rJL9gj6KU+iB92xXBhLAscEsULPJ7TSQ4=; b=xbI4kFUaggKllKIyXWG6SwFAJrtSJGTuxehiRde3dAj7n8du6ELBsxrYOKGTsZPkXO9Svh1BJZbUbxSvNLTRfQ3rWhU4o8Cqk36CZvlnyCv6RsALxP1odixXYxcbIwaIv7DJitG+4v/pqR0PUgz57tO9x+NxcqggwUKKnhJwfDZ16Kxmcqb5L0Qew0bFoVwt2M6okLbH9S6F1c0zq/PxL6xfu7NYe+fb2Mng32DiKd3B178qauUqadFvoSz1uzudq376Mbuu9HdjiIEh2m/987dfGNpXXIB0PnaX1kli4AjalAAtYOYY5lxddI59CDkwyW0oUqQa3ghb+tzGdqAlVA== 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=VLyvniffw+rJL9gj6KU+iB92xXBhLAscEsULPJ7TSQ4=; b=Z2YyCx8y7mT3baAizvouWWwx3bCJXEqW58w0DuvW4juo9rGc3HxOR8YqlKcl2UplFkVD/cVJgNF9mt9Qxx2KM2HOjbYOaD2IN2v4kEMzUAz5mlI6TFlHREBMnzD7pWJwk7x9IejE9Kr4ZtzP2Fu6eDSbu0+t9mgPQq7qXZDZGAI= 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 , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v5 2/4] xen/mm: enforce SCRUB_DEBUG checks for MEMF_no_scrub allocations Date: Fri, 30 Jan 2026 15:57:24 +0100 Message-ID: <20260130145726.85907-3-roger.pau@citrix.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260130145726.85907-1-roger.pau@citrix.com> References: <20260130145726.85907-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MR1P264CA0149.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:54::15) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|BY5PR03MB5329:EE_ X-MS-Office365-Filtering-Correlation-Id: a14699a6-f19e-439f-a615-08de60103338 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?dVN3dXNDcm56WmRTOFZlSDZ0QjNkc3JzaVBqYVN3M01RMTN2SDVSZUIwcFJC?= =?utf-8?B?bk5tb3RBZDVLTHlIYTRNS2I5bVBmc2FnTC9jbDZITDZ4RlFqWklmS2RpbkIr?= =?utf-8?B?UkFBTEFsdHh4VVRtaTJhWnNacHpVSEwxbGhPVE9hUXc1aEJNSERoVkdnUWU0?= =?utf-8?B?NkoxQzBlM2p3TjR3UEpOMEhVRG1uNDJnSHgwdXUzRGpFMVE5eVR3aU5KbU5v?= =?utf-8?B?eWNzTlBDOHAxMmRUdTdzT1dGUWZIam9yQjJRSStUa2U2b2VRKzhLa0MraUpG?= =?utf-8?B?dVhiaXlVMW8wZTBSMTlnTkxzcmJzb081Z002YzlMZ0FoaUNza0ZVc080Z0JV?= =?utf-8?B?L3ozeGs5OFdSVGxCU3p4cTJzVnNsQlo0RHJFTFVSbHpWR1RZeit5VWJteGZO?= =?utf-8?B?bXdpTTE2OEh5SWlqa2t1ZzlrUkR6Skt1R25WUVczWVFnM3RKc2k2ZVlpNkY1?= =?utf-8?B?QWVCNWlvb1lSVUg4cE1FNzFpSDNrbmdzQmtYY0NNVTNNcU14RU1YbGhhNW9B?= =?utf-8?B?Sk5QV1NyL1NkdmJaU3FvMm1ucVV2Z2krTWdobEhSVituLzRuNndKdC8wL1RG?= =?utf-8?B?TklXQVpweUVEckZaZHZZODVYMmJRY2pnK2ZUMTRWc2Y3d3BJeHJjU1hMODcw?= =?utf-8?B?NlFoOFhpYXZXU09RQVZwQ0FUTkRWRTJkK2Era1h1eVppcVNEVDhVYzFOcFMz?= =?utf-8?B?Z2hLTHBvT0ZlTVZYdjlSTk9Ub3BNMk9sWUNDSjdFUmw4aEx4SFc0dGprTE54?= =?utf-8?B?MU0vQmpPS3QzZXFlcjhIa2dJaWZ4UUhJTkd6RThIQWp1Nmxla2g4M096aWZR?= =?utf-8?B?RFJTdGNGQVJqNi9aMmIyRDRUQVRuVllHR0hudndrWlV5bVpYTzFhaW9MdmxO?= =?utf-8?B?R2t4MVduREdQSFhUNTlGREIva2xrNkNock9OZU1XZi9zN0hDREp3S29IL1dl?= =?utf-8?B?a3UvTXhXNkZScnkvOU5JeUU1c0NUa01KVnhmZVNDMVBoMWxBUTNXUTd1ajdq?= =?utf-8?B?Nm1JM2QxUVJYVjhlZnpoYWkrSmRDZ0ZvdTJGWEdya2FQMWhMajAvOGxnNml1?= =?utf-8?B?cU4vQ3V5dC9KdGVaMmV4RWt0WDFhbkpUNDMrVUc1Qkx6Rm9pSmdXdTBKUWxB?= =?utf-8?B?ei9TVEhYOURab3hTc3NSVGJJSXgxUjJYcW9hY0hlMUFYRE0zSFRUWGU1ZG9l?= =?utf-8?B?VU93bzRzblFVb29nT2tNUnA4NmltMk9BWVpjSjBqSjA2aUpZMEpiRXVsWHBr?= =?utf-8?B?cTFub1QvY0EvSDdKVG1Td0ZOTkxSeWNHR0IzZ2t6dm0zTUJFRXN0MGpaek1Q?= =?utf-8?B?VHF0Y1dEVGlYbzJsUlFUdGpieGZhUGsvL3RHK0IxTms5Y0lOWlVUeDI5ZVBY?= =?utf-8?B?azlqL1pyKzJjcXRteGxkWmdBMnpMNGZKM0ZzVk4vOS94dW12Q000Q2hoSkpY?= =?utf-8?B?c0Z6dzNtVXZoa2paZWNpMTZkSEoyTHp0R3F4MGtqdnMyYUxjSXNubGdUL1Ay?= =?utf-8?B?U3J2aUJHeFZuUEljM1d2S2pUQzhiWURxaCt1aXE1UVIxNGVLTlRnS3BiYVdo?= =?utf-8?B?ODMwVnRXWFE4aUlxbHBvU0EvUk5jVDZQYy9pNVJ5OVFmZU53emNRNmhXdG9K?= =?utf-8?B?TmZ2MWtKYml0Rlo2UTN0Um0va2ZPckdpeUFYZWR1VDNUSVBoU2tzNTA3T0Fp?= =?utf-8?B?ZGNvNjFSS2YxVzIvd2IxRFRGZVl0Y2xkK3BGNytmSWVJcTdMM3Z5Vmx2ZmNX?= =?utf-8?B?M2M4YjY1dnJvcGNoaCtKOWFkM3J5Z0xqR2M1cTJVMjRqQ3RxZUJjTUp3UjFY?= =?utf-8?B?SHRCaXVoS1NLMWNJOStHQjRDQi9ESThIM2xMeUJwM2NsaU5TN3NoYS9takZ6?= =?utf-8?B?QXRVb2tjUUhyaXI2MTN2VU5ITlhDMDFjZDlHOVhTRjBlVEZ5Z0ltUlkybzRE?= =?utf-8?B?YzZzeEZkOS9nMjd0WFdlMmh2SkxQTnhVWTFMb21KUnZLaWs3dUg3TzZyV1RZ?= =?utf-8?B?dE5XeVh3S2VtaCt6a2Z1TEpSa09IUXR5ZThmY3FWK0RSVkhFKy9lRTVaYU0y?= =?utf-8?B?ZG83cFlMS3RmMEZxdnhrR3k1blJlWmZtTVhXaG9DOVJkOWZpL0ptdGVxUXZ3?= =?utf-8?Q?ZP44=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?L2l5R1JyK3g2RzNlL1dqOEIxQ053RzU1MmZTa21MMDdEUzNvS1I4aXF2dFUr?= =?utf-8?B?VXFWSDB6RmpRR0Vrc1Q3K3NiWld5NVVQZEsxZGhZZXRHcmdNcGtpRmxWT0Zo?= =?utf-8?B?TzRRa1VQZlpQTWI2eEh4b2hHY0xmOWF2UGdZK2JkaTI2ekFmWUVjQlBEcTRB?= =?utf-8?B?Ym02WEZ3VUtFQm1YUDd0d2xFRTFCZUM0R2g3S3VLL25TdTdaczA1ekZXMEk5?= =?utf-8?B?UU05OEU1WEtGR1JCd1hkNU9ZZTZNVy9KWWJ0Q094WmZYVHNmNnVBR3JrRjhL?= =?utf-8?B?OHFsQUZxUGlhcWFQRVEreWltcndEODFFYXpMNERuam5rYWFrN3kvdW0yaGg3?= =?utf-8?B?UWhaclNwK3NhYmRldExLNUczamFDa2owYzEwbGQxbTVBbmlURitRY2M2d24w?= =?utf-8?B?TjZhR0hxNVV5cDQ5cGcrNndjbG8xRzF1RDdEZTVyQkFnNjF6VmVzTUlmWE1S?= =?utf-8?B?aG1kSmo4dU13bFlTbzZLTWI5b3djVG83cmhsUGJaaThVRkt2Ti81SWZkSTlq?= =?utf-8?B?RE51K0ZtU2g0c0dCK2xya0ZpWTd0UEdUZGx3SmxiNGticXh2N2JkZmhTMGQx?= =?utf-8?B?QzhhZmd5YWtmTHMxb0lpVnJTVGxNM1FCb3IzS0pKb25PZXFjcnJxVE5zb0Nt?= =?utf-8?B?UEt3REU2UWlHWE02SGlIdDRSc2F5emRENTBZNjI4YXhIMUovTjZkNmdaK2lX?= =?utf-8?B?ZkpoeWlSRFM2QnQrb1U5S0xiSzAwWmk2Q0NkY3VtRnA5QlFtQWZhTGJTU3Vr?= =?utf-8?B?QllGZUJyVUFjVkJDcC9CV1VVaVhoTXVDeWpPRlAyUTk1ZlVySDlUSWF3Q09Y?= =?utf-8?B?d0wzbHQ0L2VSRDdVTHhEajF0eC9WU0lzRzZsaG9UbHlLcWloTVdMMjErWG0x?= =?utf-8?B?T2Z2aDIzU1Q4QVNPRFlna0dsNDlvWFNob3NXN3pGQk1aYVFkOTRWaURlQVUx?= =?utf-8?B?aVNUYkJzS0luOXJURitKTDZvNTc2dEh6d2FSeFg4c0swODN6UzMyc2xXQy9Q?= =?utf-8?B?NTZGelhDeHoyV3ZFY21TWitYY2kvTnJCTVM5TWd1TUxSUWYvdVBKL2hybVg0?= =?utf-8?B?ZDBBck15UWdBbnlNTWFMcGxRRnZVS1VVb1BoSzJWWElscjBaU0ZhU1BRYktZ?= =?utf-8?B?YmtoQlJKd3lOTUlZeEJsS0dBeG56TUxzOTduOU90Mkl0WitGelVWMTZxQU9i?= =?utf-8?B?dEFxc3VmWDJJckZPeFo4SW5DSktuekNnS1dyRlVpOFZ3d3c1c2Uwbm12dEg4?= =?utf-8?B?MXNDSTZLQW1ITzhNS1JYOUR4UVZoQXoxT0lTQkpzNXBQMWpTeUtZQmtzSXJp?= =?utf-8?B?cVUwMDZHVTcxWUl6SjhRM2xBV3VVT2k1aWFLcEpvaUtlNGFMaVc0Tm9oZTNj?= =?utf-8?B?OTJEeWlSUUxHVndGMDlheFdRb3pLWTJhM2RpQUJRc05KL1B0Y0RESlVxYVdv?= =?utf-8?B?dTdNSlM1MXNLWEFweWovcS9KbVJ3WitmQUhIR1l5ZW12NXhVUTBVODBpbEhs?= =?utf-8?B?OENHV1pZVHl0Vk5ncU55UHB5VVpRZ21TdWIyUWZPOXFvWXlOdjZUZlNjVG1r?= =?utf-8?B?bHpiT2JrNFJMS2FoMUM5a2pSQVQzQllRTENURDYva1dDL1FrZWtpUEEramN3?= =?utf-8?B?OS9wR0xvRTcvcG84N1pmemRndGNBcEJ4b1B0aUJYM1RRSnd4Y2pSU1gzbVVq?= =?utf-8?B?cHNXQzlUTjhlQW5iZGVBRDUrVStKZG9KZVBIWFJOY2ZBNUVJblEraUQrWXky?= =?utf-8?B?bXhXZVpFZ3JzZG56SktFNWFoZDB0MWJWNW1nN2g5a3hIUkNreC9aZGd2bTU0?= =?utf-8?B?TnYvT21WOEJTUmdzVkpnd0tacUtFTHBVbnlncWV4NnhrUmVuNHIrZFE3VXl3?= =?utf-8?B?Wkgvem5IM0ROOFlvelZ6bTlURGNmdmtNWDN3Z0FOM0E4a0VVR2dibUVVRXo3?= =?utf-8?B?UHVGcUZVOXgyODg3cXAwT0c4K0VjRjZyak0ySEFtRlMrVEg2MkZzU3lZNUdF?= =?utf-8?B?Yi9BMHN0QjZMclZSSUxtNnRESDBsVDFNZkFZV0Vzdk5DNW1IMkpPNmcxak9B?= =?utf-8?B?bTNycVBNNVZWTDVVTHRQUFp1U0F3cFJZV0JBekF0cUpGMzBkTzkyM1hQdERE?= =?utf-8?B?eFJmbzI0dk1pT1F4eUdoODU5SWRHODRUck1vNG00ckZjdU8rbjRERk8xcWwx?= =?utf-8?B?dzY5NGtZQUh4ZnVIaE45Unh5RVd4ZSt5d1AwelJDRVMrK2VIMkRlYVBncVY0?= =?utf-8?B?ZWRIMjNtWm03dGNrRjJOam9mUXVIajZYQitQY0IyWEZTUkpjYnhDRzU5VWRY?= =?utf-8?B?UVNoUE9NMlNDRTVOU3VRM1pXQ0VkN0FBVmpCUkJLYXBQc1lJRjFSUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a14699a6-f19e-439f-a615-08de60103338 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2026 14:59:43.0202 (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: pD8p0251a03R4tFduPIC4nW53BmvAy/bB0GoV7R8ANc+qXpOKr7RYCKvPPJLa7HXFCmzIPrDSQzF7bx7296rQA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB5329 The logic in alloc_heap_pages() only checks for scrubbing pattern correctness when the caller doesn't pass MEMF_no_scrub in memflags. However already scrubbed pages can be checked for correctness, regardless of the caller having requested MEMF_no_scrub. Relax the checking around the check_one_page() call, to allow for calls with MEMF_no_scrub to also check the correctness of pages marked as already scrubbed when allocated. This widens the checking of scrubbing correctness, so it would also check the scrubbing correctness of MEMF_no_scrub allocations. Signed-off-by: Roger Pau Monné --- After discussing with Jan I've deliberately omitted the tag: Fixes: 0c5f2f9cefac ("mm: Make sure pages are scrubbed") The intended approach might have been to ensure the caller of alloc_heap_pages() gets properly scrubbed pages, rather than asserting the internal state of free pages is as expected. --- xen/common/page_alloc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 2ee249ac365a..dcb95309b12a 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -1105,8 +1105,7 @@ static struct page_info *alloc_heap_pages( spin_unlock(&heap_lock); - if ( first_dirty != INVALID_DIRTY_IDX || - (scrub_debug && !(memflags & MEMF_no_scrub)) ) + if ( first_dirty != INVALID_DIRTY_IDX || scrub_debug ) { bool cold = d && d != current->domain; @@ -1119,7 +1118,7 @@ static struct page_info *alloc_heap_pages( dirty_cnt++; } - else if ( !(memflags & MEMF_no_scrub) ) + else check_one_page(&pg[i]); } -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Fri Jan 30 15:00:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Jan 2026 15:00:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217649.1527028 (Exim 4.92) (envelope-from ) id 1vlpyh-0007ew-25; Fri, 30 Jan 2026 15:00:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217649.1527028; Fri, 30 Jan 2026 15:00:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlpyg-0007ep-TJ; Fri, 30 Jan 2026 15:00:06 +0000 Received: by outflank-mailman (input) for mailman id 1217649; Fri, 30 Jan 2026 15:00:05 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlpyf-0007Ra-A5 for xen-devel@lists.xenproject.org; Fri, 30 Jan 2026 15:00:05 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4f70d9df-fdec-11f0-9ccf-f158ae23cfc8; Fri, 30 Jan 2026 15:59:45 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by BY5PR03MB5329.namprd03.prod.outlook.com (2603:10b6:a03:22a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Fri, 30 Jan 2026 14:59:41 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.010; Fri, 30 Jan 2026 14:59: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: 4f70d9df-fdec-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Z2x1IMFuX7Zomi/n4dSqdxB0Xsl9uqQuppmyVkLG617Yj/DiQXg+SwzXErTpvo5RlHTuGPK1kTyRNaru1yOsqyflUWCvrO/oF3L3NqGrbtA8ffU5ETFOVOwuEgtTdUfSFhJgaVuhQcDar5/zRmGAqV41lsBPPpFREpIFMWJgoNBCZIYOGXTKZ/IDrt/QcW08bPyH5eifj1zPv3sfrF82oYRjUG7XBotPDVSxZ039KYlHyXly6JHYgQbOrg0m/RMPXM9Lm/uRCt6if5dq9DGw7oRQZz4w+c3us2dqGNUqnoLhXkNfnYmx7FrV8FkbNuUU8HFQwXNjL0TPBj3D6D+NLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=meYD0sEYsHml9Llwi+NW6eF01LWKICbMJckmF1mY/m0=; b=VAyzHajGiZylf3mnDaSM40Trx9ljutGbBjTfmrOW5sqnxoRYVI8auXVeffHczylFXqvXRCjA0X3S1J9lHitT+IvLyxb+jAIeaXI1C3r20xSg/M39LrlRBXG73W5YSufIB9mjStyH3yNbEuazGp6cQ9GlQfDmMAnSnWV4xrU31RJVT8hcoCwLa67UGvu//Vx3F5sZ1MYxxR+VQNCt/2eprEiVlJaKtkGfYt/+o1fpbyn4C9fBBHIEg03Weo4sgPk58I6ZpreyXyiMw8rjSIKtFUfXmRKhkTUsKqdnSkO2Ukase+YYy69hmVOyvwa/4KSGF4Cit1X/RW90NN9uYFJJCg== 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=meYD0sEYsHml9Llwi+NW6eF01LWKICbMJckmF1mY/m0=; b=AxHgvW97gqJIJiM/oWIoCFK5AGXJnwHSxC6geyWrbs95xsoQwKU55BzOZvHbOOqsZtbPbBezg3c1YxGA2Yi6Ob9mEZzWqMcIjdw0hPFdZOVAa4UEN8M9maaLyaM5ppTKTqEgaKJNLexbyoXRFP/K6280YTKtChtp0RVw4quuAqM= 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 , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , Timothy Pearson , Alistair Francis , Connor Davis , Oleksii Kurochko Subject: [PATCH v5 1/4] xen/mm: remove aliasing of PGC_need_scrub over PGC_allocated Date: Fri, 30 Jan 2026 15:57:23 +0100 Message-ID: <20260130145726.85907-2-roger.pau@citrix.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260130145726.85907-1-roger.pau@citrix.com> References: <20260130145726.85907-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MR2P264CA0152.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:1::15) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|BY5PR03MB5329:EE_ X-MS-Office365-Filtering-Correlation-Id: 43f45895-a2e0-4f78-53e5-08de60103102 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7416014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?YVZ4RFZXWE9ZL3dBUXlzRWY0NlhSbGhYNTVNK2VCc3V3clFLMFVwVFRJM1U1?= =?utf-8?B?cnNyb2JVcDByOTVyZ0JMZHhlMlBHb05RWDBGelZiZzEzWmZqbHRVaVVRU3JY?= =?utf-8?B?T0dSdGllK3QvelFPcm5aOGIrOEFkYmd4OHpMNzdVT3I2K2pZOWVTemJvM2s1?= =?utf-8?B?eHZESFNKUUp1REJIYmhXTzNCR1JoRXJDeG92MGZGU3RsMFVTeWhXOHdGVzEw?= =?utf-8?B?UTE3VUxEdUtYalBSdnZBdDYvYXk0L21Va3FJQmdqcjdIQnR0MVRnaUhBL1NY?= =?utf-8?B?ZHZmSCtFK2Q2aTNHa2lhc1NyVGlDWmRGeUFlbmRndDNWNy9zM1hyZTNDaWVY?= =?utf-8?B?RTc2MFhiUjN2Z3J1blJFU0FvUEg0N3J1UUM5ME56Znd1NzNNQ1dvS2dXMkR4?= =?utf-8?B?NU5qTHl2akpGNmMyeE5ickdBbXY1T3lYUHhvcXhKY3BtR2tBREczcWJFSElj?= =?utf-8?B?TGxPVWxOWUJ3ODdDSXlwNHV6QlRsT3pkYzZxVk5CcG4wUHN2eFpWTTNzZU5q?= =?utf-8?B?NkdpbG9ueW92Tkt0bXR0QkVkdHowMmowamczUDVaOHVJczRtWTFSSW10Uk9o?= =?utf-8?B?eERWQWNvdVRRS2FyMXl6QlhhemlxMmtMMWRUdUNLUmNvYmhrTjArUmdFYUVM?= =?utf-8?B?OC9hUElvaWlGSE5jb1ZhZnFtcGYwdm5RcUE0VFNvMUR4R2dNUVFDSTBmeFl0?= =?utf-8?B?TXFHYnpRcmYwZDFJbG05RVp5YjFNdE1UVkZKNzVaU3pKeG1TbC9aM2tkMmNP?= =?utf-8?B?NFIzam51aExXc2txeS9NMHA3R3l1NEJqc3ZkV09Wbm5YYkxRNzBYQnp0RFFn?= =?utf-8?B?NXFhaEFwdWl6dktOclpJMmdCS0hxUnhyRXpGMVY0QW1TWkZwNTZjejFiWGw0?= =?utf-8?B?SzkwUlhKYzlsakNXMTA2TmRhVjhCUWJ0V3hwdCtVTFQzQ3psK01tV3RwaFpH?= =?utf-8?B?eTczYzhEK3k1aUQ1SFc5TkJncXNpa2pMSmZKVERSaWt0bjdUWmR2NGc4SEJi?= =?utf-8?B?MlhXTStydVJJdmFsOXRucHUvL3VlbHFvOWk1TDkrQVhtREtXYVZBWmxNN3Vp?= =?utf-8?B?VE56Q2xGcFdiTm9lRUJCdk9ia1dKSUkwenUvMXprSHpvZFFUdnd3Yjh1UUoz?= =?utf-8?B?RWFldlJmR1JWS0Nkd0FEcmlTa2pSbzE0L3lLazlsbjB1UXV4eHNVNklVYVRY?= =?utf-8?B?aEk3MnBZRWtmcDR3cmpFQmdlZmZGSkNqTVJCV2puZENMTmZ4VUpQUmpZRGhJ?= =?utf-8?B?OS8vSm1lcEFUZzlUSzgzQ255bUlWVmp2QXp1VjJWQzVSZmpqNng5S3ZmSE94?= =?utf-8?B?Q0FGdC8wdEFvdUIwQi9nVTc1TEVXWkNpVEs0RUtoQkdLUkhUTFRpRHI2NFBu?= =?utf-8?B?YmZjcmk4RFdqQ3VBUXJzaUV1NXhabFVKb21vVkdWcmtNZFJhbklHYkszUTRC?= =?utf-8?B?TldWTGY5ZW16bGpVVXdKbDE0QUFETGRzVkJuN0JoYThzT3J2RVFaVmdoaHdF?= =?utf-8?B?L0ZNdTIwRjJmRG0xVGlKQ1ZRdjNVbkdtUFNZcGRjWGEvaG4rZmkyQW0vLzU3?= =?utf-8?B?VWNZVytYSVR4d05xdzU2citTU24vcmVOSXlGSC9LZ1pwbUIvcHl1Z0Q4WDVt?= =?utf-8?B?Y0Q0SVYyZVBUK2g1eWpvMm1zNXlPeC9rWDdieW51c0duUFFsK1BnMmx5dDVX?= =?utf-8?B?NE9jTGRTN0JGcmlpMGpOQUhRVHAzRHBDVHV5K0EwVnpWZlhQKzRRQmhJZnVS?= =?utf-8?B?SDVnNXM0enhtNUNoT3NZc01Pc0JEa0xoMklra0N1RkgzL2k3djJEQ3NKZkJX?= =?utf-8?B?UGR5KzlUYmovUzBvWUhxWjYzVTE4WkRwWVl1dDdHc1lGdytIZ21kd0lFWS9X?= =?utf-8?B?NXZUbU96VUtxYW9VU2I1dklRazVkVmlMaTlIUUJhcjhzVW5CVkZDSG9DV3dY?= =?utf-8?B?SEVMYmVCY0I0dWRCLy9Ball2VjBVdTRuUENZbnQzWHl0MzdUQUhxMVB0SFND?= =?utf-8?B?czZzNkR0dDhEdGtHNk1vY29jK0xObXczNTlIcmlXTFAzbnExUlRsbUVYQ1JY?= =?utf-8?B?eGNLbFBra1pvWk02Z0prM1l2aDF2b3oyd0IwbTZxSXM0eVAvalRjc1Bsc0FI?= =?utf-8?Q?Ygno=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7416014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QWtxenFrMFc3eDNLR3ovaHZkTlVPZ09mZ0dxUDhnMGZ2SVhZdkVZTlAyMDRl?= =?utf-8?B?cWNMbjZ1RG9oejZleDJhVkhwMFRUbmwzeUFFVGN3NWdpM3oxWVF0Y0JRV2lL?= =?utf-8?B?UU9Ja2hVQWI0Zk5mQWFrNHNXOGpVQnpZK2NEN21yT2UyTWtFaW53WkVYUE9r?= =?utf-8?B?U1pvdU1iYjQzVEFBcy8vNXQ3K2YwVEhoYlcxSnhZUGZ2UDNCZ3I2TTB0MTha?= =?utf-8?B?MEQ5MjNaNHNweUg2Z2lwYXF4SE5VdE55ZjFsczZJMmtqaVBDZzFwdllJU3FX?= =?utf-8?B?VXp2bUoyUFZ2Zjh4dUtVeExWUEZHR0pWZGR4RE0zdEhUaHJmNTRVaWFDUXIx?= =?utf-8?B?K0NKMC9jZnp1cGkzcXlScXEyY01XOFhXaGVRckxlKzBIMzcydG0wMXdPTWtC?= =?utf-8?B?VnRGS1AvN2dQdGkyWFdWOEN4cWkzeTZ5dzByNVU2YjE5YkN5K09pRzhKd0RG?= =?utf-8?B?dUVQVnE0UlFMejV2bzU0QTAzSmY0cFlUeWowS3ZOSEdYODNJTlBWT3MvbVJp?= =?utf-8?B?VGg1VWFGY054Qmg4MDMxTVl3enlNRnJWYVNsT2QycHJ0U21nN3Y5Zk9xdGRr?= =?utf-8?B?ZGVjeWZJTG8raEo1U3Q0eXdjOThsV2V3Z01IMU8vS28xWXdrdy9Oa01pN2hJ?= =?utf-8?B?VWFBeThBY3RTM3JOWHA5Y2o3RTlheVhxNkg4U3dhNDFQeENQUHhKWVp6Zmtq?= =?utf-8?B?MjlRck1BNnY3OVFXWFltK0RkRHR6YnFoYW53Z3VqT0R3MklaOW5Xc2hpTGY5?= =?utf-8?B?Z21ydG4reU43cDRwdlFCUkMycGYxT3M5Y1BNNkRkOWJzd2FGaTZ2aURUU1M1?= =?utf-8?B?NGFJNExuT1kvL3RFY2JROExBTG9SeXlMZ0RIYlRFb0laVFBCMGlyQkVHcVhP?= =?utf-8?B?L0h6M0VNMWJRVHhLNUlFV1NvNHhuMFRkQTN0dnZwVGhMZk9KdzVCL0lxREhE?= =?utf-8?B?cUJZR0VUbzdpOWxnTlpSV0FYeXNsdVFWd3B2bTAzcXpYU2NPUnR1dkY5N09R?= =?utf-8?B?QVRyamRnNkhobWEreGhSQytXZWlCUXV4Tm5GWlAvNnVGSnFKbmc4a2ZxTnVi?= =?utf-8?B?ZDdXdHVJdnFuWGl4THNjRmhIRDh4ZytoMjJEVDdEeGppRXMyUHVkN0dJS2RP?= =?utf-8?B?bmxOSGRaNitTWmw1R1lGUjlRUXpEUmVWd2tVclphWDROYUFlVlhQbW9QOWdw?= =?utf-8?B?U0R4ZkJQWUd2OEpBcUsxUE82YjdHYTNQaDNaTVh1SnJKVWI3dS85YTFxSHVs?= =?utf-8?B?WUx5ZUlGMng4S1M1bFBOamFzMkVwVkVreElIK1VBK3VlZTJVM0k2MGFZTGJW?= =?utf-8?B?QjQzTitrMzVVa0piWk9DM2lmWlZIcitQa0R6Ym0vUHZDNnJKUkhid3FFVVI3?= =?utf-8?B?bVZMNTd3OHpBcDg2a3pWMWlLVnd5czZFTnVxUWZ5M2YrTkY4eWZCOVNVRlQ0?= =?utf-8?B?ZnNXMjhFeGJwM2Y2V2kyaC9vdVZNMkp5M290UEN2LzFUTk1Bc245QURMSWw2?= =?utf-8?B?T2haUmRFd1c4VEhKZ2pGQW9yQzcva250L3ZZWTcyREdWeWRnd1FpQng5a2t5?= =?utf-8?B?VThpUFFnY2czcEpBRkN0RGF4b041UVdzZ3NVK29OOG10QlMxcE9hV0hvR01o?= =?utf-8?B?T3dNZk9xZFFSMVNlZE8ycWNqeDZBUmp3V29sMEN1d1VER2xQU3A1clJPNWl0?= =?utf-8?B?dlFUaVpneGQvZGNJZUVld0VLSWV5RHYwamJ1dkhmZHZybHNsYUJzT09WNlhh?= =?utf-8?B?T1I0Qjl5OVE1bEhWc0RwM0NRM1gzcmNSb1NUd2hiVGdoQzh1KzB3YURSY25z?= =?utf-8?B?YnRaWGpuYTgrY1BpTGY4Rmp4RE1hcG5Nbyt3WHRCY0hGYms0cWdZM211dC8z?= =?utf-8?B?NG5mQk9QbHh0R2RESFNac1hvU1R3dWh3M0RZQndlQVNVVXpTTmw3SXRqQ3Nh?= =?utf-8?B?T0JEa0VLSlIzeEo3cFdTd2h1SHVOK1dkU3NKdlBxZWJMKzA1d1I4OU5XRGo0?= =?utf-8?B?bmpIN2Q4aWtHb1VBeXhEZVFTcXp1OVVMOXdUaVJ2ZFdwL3Z3dUt4V2wxZjRw?= =?utf-8?B?UzJNMnZSTm9hN0swcURyWlROSFc1c3JhUkE1MUJaYk0xaGFCVzhDejhxd1JN?= =?utf-8?B?RUI3b0huSU5CZDNGVmVlVmg4N1VBaFRmOUVHV0ZSQ2FmQjdOd2U0U1dwc0Qz?= =?utf-8?B?RnpoZWhkVDJ3K3RkeFhiQTVMc1FqYmFnd0hHUkxJZnEzQVRpSTZuaCtjdU14?= =?utf-8?B?NTRlU0pPdklqMTNsVmI3aHp0ZHpmanhEWDNYV0U3WEs3dC9mUXQwbWN6OUZX?= =?utf-8?B?YUVnQjBiTTdVbHdTSWUxVTRsbjEzRnRPTUVkK0R2c3VxbnUxVDBOQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 43f45895-a2e0-4f78-53e5-08de60103102 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2026 14:59:39.3222 (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: JJIL+QLsWl47x+eDHwRi8vwVzLNKDMq1Kifpr33mQupXwsfHvluV+/qYCvJCFrQ12dHmBxQzupF8dnJ9cOhKQg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB5329 Future changes will care about the state of the PGC_need_scrub flag even when pages have the PGC_allocated set, and hence it's no longer possible to alias both values. Also introduce PGC_need_scrub to the set of preserved flags, so it's not dropped by assign_pages(). No functional change intended, albeit the page counter on x86 looses a bit. Suggested-by: Jan Beulich Signed-off-by: Roger Pau Monné --- Changes since v4: - New in this version. --- The PGC space on arches different than x86 is not compact, so I've just used a hole in those. --- xen/arch/arm/include/asm/mm.h | 10 +++------- xen/arch/ppc/include/asm/mm.h | 10 +++------- xen/arch/riscv/include/asm/mm.h | 10 +++------- xen/arch/x86/include/asm/mm.h | 18 +++++++----------- xen/common/page_alloc.c | 2 +- 5 files changed, 17 insertions(+), 33 deletions(-) diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h index ec2d2dc5372a..72a692862420 100644 --- a/xen/arch/arm/include/asm/mm.h +++ b/xen/arch/arm/include/asm/mm.h @@ -144,6 +144,9 @@ struct page_info #define _PGC_colored PG_shift(4) #define PGC_colored PG_mask(1, 4) #endif +/* Page needs to be scrubbed. */ +#define _PGC_need_scrub PG_shift(5) +#define PGC_need_scrub PG_mask(1, 5) /* ... */ /* Page is broken? */ #define _PGC_broken PG_shift(7) @@ -163,13 +166,6 @@ struct page_info #define PGC_count_width PG_shift(10) #define PGC_count_mask ((1UL<count_info & PGC_xen_heap) #define is_xen_heap_mfn(mfn) \ diff --git a/xen/arch/ppc/include/asm/mm.h b/xen/arch/ppc/include/asm/mm.h index 91c405876bd0..402d06bdaa9f 100644 --- a/xen/arch/ppc/include/asm/mm.h +++ b/xen/arch/ppc/include/asm/mm.h @@ -57,6 +57,9 @@ static inline struct page_info *virt_to_page(const void *v) /* Page is Xen heap? */ #define _PGC_xen_heap PG_shift(2) #define PGC_xen_heap PG_mask(1, 2) +/* Page needs to be scrubbed. */ +#define _PGC_need_scrub PG_shift(3) +#define PGC_need_scrub PG_mask(1, 3) /* Page is broken? */ #define _PGC_broken PG_shift(7) #define PGC_broken PG_mask(1, 7) @@ -75,13 +78,6 @@ static inline struct page_info *virt_to_page(const void *v) #define PGC_count_width PG_shift(10) #define PGC_count_mask ((1UL<count_info & PGC_xen_heap) #define is_xen_heap_mfn(mfn) \ (mfn_valid(mfn) && is_xen_heap_page(mfn_to_page(mfn))) diff --git a/xen/arch/riscv/include/asm/mm.h b/xen/arch/riscv/include/asm/mm.h index a005d0247a6f..9e28c2495462 100644 --- a/xen/arch/riscv/include/asm/mm.h +++ b/xen/arch/riscv/include/asm/mm.h @@ -273,13 +273,6 @@ static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr) #define PGT_count_width PG_shift(2) #define PGT_count_mask ((1UL << PGT_count_width) - 1) -/* - * Page needs to be scrubbed. Since this bit can only be set on a page that is - * free (i.e. in PGC_state_free) we can reuse PGC_allocated bit. - */ -#define _PGC_need_scrub _PGC_allocated -#define PGC_need_scrub PGC_allocated - /* Cleared when the owning guest 'frees' this page. */ #define _PGC_allocated PG_shift(1) #define PGC_allocated PG_mask(1, 1) @@ -293,6 +286,9 @@ static inline bool arch_mfns_in_directmap(unsigned long mfn, unsigned long nr) #else #define PGC_static 0 #endif +/* Page needs to be scrubbed. */ +#define _PGC_need_scrub PG_shift(4) +#define PGC_need_scrub PG_mask(1, 4) /* Page is broken? */ #define _PGC_broken PG_shift(7) #define PGC_broken PG_mask(1, 7) diff --git a/xen/arch/x86/include/asm/mm.h b/xen/arch/x86/include/asm/mm.h index 419fa17a4373..06c20ab8de33 100644 --- a/xen/arch/x86/include/asm/mm.h +++ b/xen/arch/x86/include/asm/mm.h @@ -83,29 +83,25 @@ #define PGC_state_offlined PG_mask(2, 6) #define PGC_state_free PG_mask(3, 6) #define page_state_is(pg, st) (((pg)->count_info&PGC_state) == PGC_state_##st) +/* Page needs to be scrubbed. */ +#define _PGC_need_scrub PG_shift(7) +#define PGC_need_scrub PG_mask(1, 7) #ifdef CONFIG_SHADOW_PAGING /* Set when a page table page has been shadowed. */ -#define _PGC_shadowed_pt PG_shift(7) -#define PGC_shadowed_pt PG_mask(1, 7) +#define _PGC_shadowed_pt PG_shift(8) +#define PGC_shadowed_pt PG_mask(1, 8) #else #define PGC_shadowed_pt 0 #endif /* Count of references to this frame. */ #if PGC_shadowed_pt -#define PGC_count_width PG_shift(7) +#define PGC_count_width PG_shift(8) #else -#define PGC_count_width PG_shift(6) +#define PGC_count_width PG_shift(7) #endif #define PGC_count_mask ((1UL< Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Jan 2026 15:00:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217652.1527057 (Exim 4.92) (envelope-from ) id 1vlpyn-0008Sx-OI; Fri, 30 Jan 2026 15:00:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217652.1527057; Fri, 30 Jan 2026 15:00:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlpyn-0008Sq-L5; Fri, 30 Jan 2026 15:00:13 +0000 Received: by outflank-mailman (input) for mailman id 1217652; Fri, 30 Jan 2026 15:00: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 1vlpyl-0007Ra-Jw for xen-devel@lists.xenproject.org; Fri, 30 Jan 2026 15:00:11 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5ee4d43e-fdec-11f0-9ccf-f158ae23cfc8; Fri, 30 Jan 2026 16:00:09 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by BY5PR03MB5329.namprd03.prod.outlook.com (2603:10b6:a03:22a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Fri, 30 Jan 2026 14:59:46 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.010; Fri, 30 Jan 2026 14:59:46 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5ee4d43e-fdec-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fvEm3JLwpDDYawbhGhwAk7PDjIPWqL6yMoH+2fY/CWODaOlw8HSHVnVpblB6th7uPo8XpHEAddaypiRg+PhpoyVpQpiy/wX6JnqwU+aEgfqwhcyQVnluA1Kx7ocI9Do78bhAGTfjxVzvIuGWgEDeodynVnC3Wctvufx8UZGLyRmdYEV9L57sOmRH7Czpl/kQsqjkR156vyLtt06st4Q8dPJ3dLq7z4TNWikQqIo5Eyi0+DdQxawMDHbjx//YIZv7Hsf6N9qlOGKDrxhGmUDG0PkE54J/hF2HrYrWzTa3OWP5WFzfJLHiDT/PEJTnIHnz/meqs9I5tN/oBQgBwUCLJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=w4kt3HlIslTe7oWtZiavcZv96YzHLGl9cFCLUCvUUtE=; b=R4Qh5CcxLFXBjsoMZk68biKXR/cYqgy34rtYO7CHjgoAGiMgoAl3Q/4hRDjf3JpB5KJzPuo55cNicQfyd7zL+vYlDnbHqnl0f1jiMAoxRcF+00069OeNnEwBE3kohtrtbTZjO0gOtWHWWFdh/4BlujXlI0FogJFWSLw6UepDh9sT21S0vuAd0uBy/Yp4U98UJpoqVOLrlvFZWvkXEjVPIDfjrG7bPPS7nj9gyUzMTKR34mNSqQuuzs5swiHD38U3xPw/gA/fxdj2PSr6nO0CfHvt9i6ZscycNqcb7LDNrBLi4ja+VTVv3IVO5Qc6LdAwwEtpBlZeYLxpjQHgmJGlWw== 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=w4kt3HlIslTe7oWtZiavcZv96YzHLGl9cFCLUCvUUtE=; b=DKHi6qvy8uij7AcX4kPjA7Ay2kKXBVG2kdZAfuC9d/r//g+hWZJk3MHorrdSzmcLfgL3DrEtO0iWh1IaGtFU0AevLWKAP9H9YpEQCmvu2E2IKu3D4swJYAVredLu+XJOmO/64M6FNsLXm4kBMTl+kXTHDL3kAC8S3RJkhGqn7k0= 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 , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v5 3/4] xen/mm: allow deferred scrub of physmap populate allocated pages Date: Fri, 30 Jan 2026 15:57:25 +0100 Message-ID: <20260130145726.85907-4-roger.pau@citrix.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260130145726.85907-1-roger.pau@citrix.com> References: <20260130145726.85907-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MR1P264CA0208.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:56::8) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|BY5PR03MB5329:EE_ X-MS-Office365-Filtering-Correlation-Id: 37b8877d-429c-41d6-138a-08de6010353c 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?d0ZqOW5BcTBEWUw5WTRla3NSc3J2eXJBTUdJdHhZaFVXNEM3TWszcFg0UFow?= =?utf-8?B?dXNmKzFwRmFGaFBqTmh0aUFIT2Nxblo3MGZFajRKU0lrS2ZTMlRBUnowZ1dh?= =?utf-8?B?ekZEWkdOaHpkUjZPL0VsMHhZS09NblZZVTVYT2ZscmJFMWZjZzVlTUNqejNG?= =?utf-8?B?NlN6c280WEZmZlVraWFvcGdTdk1xdzdlZXk5VUlZbjd0cStrUW1ZSE5MRkNQ?= =?utf-8?B?bFVsV1dTQjFPQzZrY05TR0EzaG42OG9iZjVpOG01Z2xiQitjL1o5N003Y0dT?= =?utf-8?B?cTU0VEdaZzEwTU8vaXhaMnY2KzJ1eTVCd3ZUMjFPQk5tRFV5a0dEdnRidTVN?= =?utf-8?B?YnJjQmxVa2NJTWFxckhidURoMHpxMkp5aVRmcEhmRmdYM3VGRUttUXFrM2dR?= =?utf-8?B?dnl6dHNISEVXUDNkQk1IQm5TUFdLaG1VTGtxRitaR1BPeFIzUjdHTG1iN21j?= =?utf-8?B?anZvbEd6NTM5UEVJK3krTUw5TitXWlpzbGoxWU0xSjk4RGhlb0VXN1RyRTFG?= =?utf-8?B?c2hUUkYvUVZOczZXdEtTdWlzY1MrdlcrR0RTd0Rlb3ZWdHJzdExzbGZvVDZG?= =?utf-8?B?NG4wWXFMR0REc1FRYk5CVjJWMWJYd3Qza0xpV0QrbG40SXQ2L0ZzVXpKTG50?= =?utf-8?B?REFLZUE5YXNpb1dZNlVtcElUbzZJdWlGbXhNbUdCM0ZjeFJzRDMvV0dSbTlI?= =?utf-8?B?aTZTV0pudjNOczV3U2gwS3N0cE5oaTMvWldMS2VPWkVScXFzS3BvRk9VcU1R?= =?utf-8?B?ZnhzMFZCNkV1SGJMYTg3clNYQXhMcTNId1BHZ085bXpYZTNyUldaUzcxcEZB?= =?utf-8?B?amgycUJWb25XWGxNdU8rVlN4bDRNUzIwenR6VEtyUlR3a1hNVVJ1Q2Fia0FL?= =?utf-8?B?SmJHREYvV2JuYXNLN3pNamZuY2ZTdUhVd3A2VGFtNHYybG8xNkRaRFlDR1pN?= =?utf-8?B?RHZScWdUVldlNXpsNmp5Qm5hUEtHR3E4MktTdm9lV0JqL3kwcDZZSTFuTGFp?= =?utf-8?B?YWVZUTZJMEViZDdBenVUVWRwcndadWJiWFovSVFqbEFrUVNNb0QraTNlRC9L?= =?utf-8?B?UUJ5Qno3dXZYR1NyMzBjcTZuVmFIbnUzemZuUThIQVdDL2VPUktudG9tVDlG?= =?utf-8?B?QXZSZmpiR3psbzVHcnZWY0hjQVpOSnQ1UmNxVXZzc3NmMUI0V1B2cm5nNkVE?= =?utf-8?B?NVBmSHlHUGplSklBNGVkUzBzMjhUZ3U1ZDlSRWo1NElzdkJyZ3BOQTJSZTJv?= =?utf-8?B?RkoraUZzRlJzZEZobmswVUc3YzBGUnMwOS9ualNLRHVaOWw1MDVNNkJtRk5B?= =?utf-8?B?Vkd6NlZMNUtFTGtnR3REb0tGQkdXdGdKc0xoMTljUTZUTForWWRnLzlNbDgx?= =?utf-8?B?Y051dWZLZjFqSUExRUxhZUFoTkNkQVRmWVNuQTFjTWxhZWxrZXVUM2tEUVlN?= =?utf-8?B?M1loUUw1YW9rTWRmUjYybnhYSGdNcmc5V3dPU1FQZC9ibFNxYnBteDI5WGhZ?= =?utf-8?B?UVBPMXNEWm9WZnNPWUtkckNHZ2x0SHNSRlFUaEtvMDBHQWdHV09HWXJjVEl2?= =?utf-8?B?RTdSWlJCck9LZVRZUlR2ZE5jckt4bHdZODlaQXVOQ01HK1JIYUNZdDFJay94?= =?utf-8?B?ZC9tbXdPZkdNWnRDQ0czZlRLdVBVbm40R1RHcU1yeDd6SnJiTXkrTXUvRWJG?= =?utf-8?B?cERiWHJOVzBzWk1KMnltMzhtZCs0ZU44MDVSSVF3a0x4VjUwemZjS1grdm5t?= =?utf-8?B?MFdWNXdDR0R0bnZsZmJKWGtjNUF1V1Voc3luWExub2hCQ1NzRXg0aUFoWXI0?= =?utf-8?B?cGMvQWRXdnJvM0xVbHVaZ3lRdmN2WElMRlZFS3dReSs1UWcyTzF0OHlPdVZ5?= =?utf-8?B?MVRVZ21Ba21aTlJndW5saXZodVJnK3JMcWFMQk1tT1pQN0FCZGFnTExWYjJK?= =?utf-8?B?QlNKbWcxajQxNmJXVTlieG81UUEyOENLOEhhY0sxYnJDMmpyTW5FZWR6ZGpY?= =?utf-8?B?RHBGSTIvQ0crd2NLMGkxY0pramhxYUsram5MK2VIVGg4b0UrYUlLYlB3NHI0?= =?utf-8?B?ang3Y1c5MW82M1ZBQ2RIQTJpMjUvVEZBcUtjb3JuY3FaUTVvdm94WU0zQVln?= =?utf-8?Q?Lk60=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YytWZEkzRDBudkJEVStMeHJRREt2c05zb2MvQ2hlMkQxQ2xRUmxrODNmRDJ3?= =?utf-8?B?alN0S2laUnBadDNnRWlROVkyaGozUnZNRldjTnhiV1RMbktuY1JBTzF2ZHV1?= =?utf-8?B?WUxjODNITWw3R0VtNVc0OU54aURNTWM3YTNNRWtpSXZqRUlKamhpb0F2bmdv?= =?utf-8?B?Vk9DWDhpRlRkS0ZNWGZFakhlcG5FUFZUSVJETXpreTUwOXk0R2hJc1BQSDJC?= =?utf-8?B?TzZjcmxVRFB4dzVUOVJsTW90WlljNURlSVkvWjgvVmZjWjl6V1FsT0wzRVJ3?= =?utf-8?B?ZjJuK0ZLZldRT0VDWUhtWjFWK2lrSS96cU5nNmw0UFo5UGZYS1ZkQ2dLeXQx?= =?utf-8?B?d25FaFJUeTZaVkpGTVQ0bDQ2YXF4YmV5TnRIZGhWYmlHT05vVGYzQm01Ymdi?= =?utf-8?B?K0NpcWdaVjh1UjZBU1phOEI0VHpyQWtrWUY5WHVTQXI4T2gxN1l6eWwwb2RD?= =?utf-8?B?SUZ4YkI2d3VmMEJ0T1RzeXV1cnlyNTJZWCtrRENHMXd5MmZEYTdWR1M1M1Q4?= =?utf-8?B?U1NpYkVqclBtRUtKV1FOcmduR3Nna3ZVdE80QTF0TWV2bExZZmpPVC95eEFX?= =?utf-8?B?eC8zU2dFNDJibGJVM2ltUXhHVUhORXZDRUlVMk00UU4ySVdKZ3NiT0dOKzVI?= =?utf-8?B?YXRpdmx1WkNIeHBKTDdkektremhKRkFCbzBsTytYanFBZWJmRUMvMGVxQ0xK?= =?utf-8?B?bzFXdnpUaXJVaVpVd0VERmRpci9UM29LMTluSGViVmZMZEFNeU1vNG1tYWJQ?= =?utf-8?B?OGdZZUIvdUpudksxVXFTZE9ONGJXNllwYnNCa0JYM0pUSis1OEJKV3Y4OHYx?= =?utf-8?B?dGNDSTNFVmlsQ3pYclRneVNha3QxRjg1YTQxN1FkcE10Z3lYN3VmdzYyRGxC?= =?utf-8?B?Yk1hemZxMmRKWmJLYXVqNWpTRXR5bGE1bzdOWGdvNHdSbjZGS0oyd2lwN01U?= =?utf-8?B?SWptUkJnU2UxT0xyZkg5UVJPZ0FOd3FLeWZDOVVQVm9QNzdDUi9KQWx6ZGV3?= =?utf-8?B?UU1QdWhYcHlsV2hvVmo5dXJMd1dPZW1TRFR0SzFMMnZwVHcySFNRM2ZCem8r?= =?utf-8?B?WkVqTTltRDErYVZsUFZlZVoyK2pUOEZXS1ZXTTIzMGg4YktFTHV4dUsyeW1V?= =?utf-8?B?amVqMGZkbVBkaGJrc1ZJc09WcFZNcU92RXl1QnNrNHY5UFhVUEUrODYya0hH?= =?utf-8?B?d1ZJRU1UY1VlQUV1UEdHeTJ2NWN2WW9rejIraWQ0emtMc2MyK2xXVHpDUnVJ?= =?utf-8?B?Z2xIUmp4UGVNUk5PdEhwMUJhMk9SSUIyeWJMZzJoTWcyTjlTNzJqek05UkV3?= =?utf-8?B?cjFOSHdEaEl3S0dXaDFzZEN6SnFpdysrUlF3cVIrRjhJN2xrRWk5K1NhT0hL?= =?utf-8?B?YjhEOW9KODIxOWxjVUFIVFk1MTBER1JJL2ZPZTNCaHl0ZjRzOG1mM2V6eU5T?= =?utf-8?B?TlZ6Q2FUQ3lkQXRRb0kxTkc2YWxicFVjcnBZUzR1RGE2ck9POG1ISTM4V2pn?= =?utf-8?B?MDR2VU1TT0ZyMWZHSjNTVmtnM0ErTnhyTnR0Q0NwcmxNR0RheCtTYWY3Y0hv?= =?utf-8?B?Mkg2d2ZNMzFIN2NNWHE4S0d5Tlo1NXJhZUZnMVN6UFU3RkRPUUpiK3dEUW4z?= =?utf-8?B?bVFoMHFOZ05WZFNXeCtBd1c1dDFkSnBrV09NaEFyZFowd3c5TzhrejVrWCsy?= =?utf-8?B?d3hlT3FFZ3l4eHFZSzNKZmhpNVNoYmpmcXE5Z3JjSXN6QkFTdXNNZ29EbDdk?= =?utf-8?B?aDZNTGFseWQ5ZXF3eFU0NUxkY2pNRW5hYSt0SUpoSVU0UmlLZUIvcVFOQkFl?= =?utf-8?B?YktGVWd0VTVxL09tVGJwUlI0WFFZY3FpRzdnVW1ta3ZHT0JqUkZzSE92VTRL?= =?utf-8?B?LzN0MXhyMEN6dVF5YTlpTjJIWjBjVkcxaFNEZ2RCYzZlbFdZWnh4NHZ2ZWlr?= =?utf-8?B?Z0liSENVWVkvT3RDYjNReGhRREFNMTdQWW9ycFNFTFlTLytjbGJQSTBLaU1Z?= =?utf-8?B?Zk9jUjBFdUhjUm5lR3FYSWVvdy9HMzBkWFh6M2hUM3QwWFk5ZUY5MlRUM1U0?= =?utf-8?B?YkxFRUNkaDBsWGhFS2tBRDJvQjArcWc3ZTRGdmVWSmFOSlArNFlMckdtNS9o?= =?utf-8?B?ZTEyNEU1OFBEa1g2Rnc2S25OSWhJNjdEUGxaMXVwZTgzNWhjdFRzcHRTTWtV?= =?utf-8?B?dm1iM0s0RTU4czVLdEJaaWhxQUFNM0d0eDRiWmFhSDFWMWJ6aEVPbElNeWwx?= =?utf-8?B?YmViYlhOVEdIUm8xa25NOVNsWEhXdld0MEhPMVBXWXlrK0RGZGtZdnY2c1JG?= =?utf-8?B?cURHaUNnSmFTbXNlcUJ0VlBGZTN5NmVpckg2bU9QeGVpWVVPaWQ4Zz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 37b8877d-429c-41d6-138a-08de6010353c X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2026 14:59:46.4126 (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: qewn8ZFA5YbE9kgbFZ1vnef26QGw1SWcDbQCw/+BabJag58lFJPXVrqHcKvZPOvXlDU/Ay8fTBgWCAL8TsX7bg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB5329 Physmap population has the need to use pages as big as possible to reduce p2m shattering. However that triggers issues when big enough pages are not yet scrubbed, and so scrubbing must be done at allocation time. On some scenarios with added contention the watchdog can trigger: Watchdog timer detects that CPU55 is stuck! ----[ Xen-4.17.5-21 x86_64 debug=n Not tainted ]---- CPU: 55 RIP: e008:[] clear_page_sse2+0x1a/0x30 RFLAGS: 0000000000000202 CONTEXT: hypervisor (d0v12) [...] Xen call trace: [] R clear_page_sse2+0x1a/0x30 [] S clear_domain_page+0x11/0x20 [] S common/page_alloc.c#alloc_heap_pages+0x400/0x5a0 [] S alloc_domheap_pages+0x67/0x180 [] S common/memory.c#populate_physmap+0x22f/0x3b0 [] S do_memory_op+0x728/0x1970 Introduce a mechanism to preempt page scrubbing in populate_physmap(). It relies on stashing the dirty page in the domain struct temporarily to preempt to guest context, so the scrubbing can resume when the domain re-enters the hypercall. The added deferral mechanism will only be used for domain construction, and is designed to be used with a single threaded domain builder. If the toolstack makes concurrent calls to XENMEM_populate_physmap for the same target domain it will trash stashed pages, resulting in slow domain physmap population. Note a similar issue is present in increase reservation. However that hypercall is likely to only be used once the domain is already running and the known implementations use 4K pages. It will be deal with in a separate patch using a different approach, that will also take care of the allocation in populate_physmap() once the domain is running. Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed") Signed-off-by: Roger Pau Monné --- Changes since v4: - Introduce d->is_dying check in stash_allocation(). - Move call to domain_pending_scrub_free() to domain_teardown(). Changes since v3: - Introduce helper to free stashed pages. - Attempt to free stashed pages from domain_unpause_by_systemcontroller() also. - Free stashed page in get_stashed_allocation() if it doesn't match the requested parameters. Changes since v2: - Introduce FREE_DOMHEAP_PAGE{,S}(). - Remove j local counter. - Free page pending scrub in domain_kill() also. - Remove BUG_ON(). - Reorder get_stashed_allocation() flow. - s/dirty/unscrubbed/ in a printk message. Changes since v1: - New in this version, different approach than v1. --- xen/common/domain.c | 23 +++++++++ xen/common/memory.c | 105 +++++++++++++++++++++++++++++++++++++++- xen/common/page_alloc.c | 2 +- xen/include/xen/mm.h | 10 ++++ xen/include/xen/sched.h | 5 ++ 5 files changed, 143 insertions(+), 2 deletions(-) diff --git a/xen/common/domain.c b/xen/common/domain.c index 376351b528c9..163f7fc96658 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -615,6 +615,18 @@ static int __init cf_check parse_dom0_param(const char *s) } custom_param("dom0", parse_dom0_param); +static void domain_pending_scrub_free(struct domain *d) +{ + rspin_lock(&d->page_alloc_lock); + if ( d->pending_scrub ) + { + FREE_DOMHEAP_PAGES(d->pending_scrub, d->pending_scrub_order); + d->pending_scrub_order = 0; + d->pending_scrub_index = 0; + } + rspin_unlock(&d->page_alloc_lock); +} + /* * Release resources held by a domain. There may or may not be live * references to the domain, and it may or may not be fully constructed. @@ -676,6 +688,7 @@ static int domain_teardown(struct domain *d) /* Trivial teardown, not long-running enough to need a preemption check. */ domain_llc_coloring_free(d); + domain_pending_scrub_free(d); PROGRESS(gnttab_mappings): rc = gnttab_release_mappings(d); @@ -719,6 +732,7 @@ static void _domain_destroy(struct domain *d) { BUG_ON(!d->is_dying); BUG_ON(atomic_read(&d->refcnt) != DOMAIN_DESTROYED); + ASSERT(!d->pending_scrub); XVFREE(d->console); @@ -1678,6 +1692,15 @@ int domain_unpause_by_systemcontroller(struct domain *d) */ if ( new == 0 && !d->creation_finished ) { + if ( d->pending_scrub ) + { + printk(XENLOG_ERR + "%pd: cannot be started with pending unscrubbed pages, destroying\n", + d); + domain_crash(d); + domain_pending_scrub_free(d); + return -EBUSY; + } d->creation_finished = true; arch_domain_creation_finished(d); } diff --git a/xen/common/memory.c b/xen/common/memory.c index 10becf7c1f4c..285546298ed9 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -159,6 +159,73 @@ static void increase_reservation(struct memop_args *a) a->nr_done = i; } +/* + * Temporary storage for a domain assigned page that's not been fully scrubbed. + * Stored pages must be domheap ones. + * + * The stashed page can be freed at any time by Xen, the caller must pass the + * order and NUMA node requirement to the fetch function to ensure the + * currently stashed page matches it's requirements. + */ +static void stash_allocation(struct domain *d, struct page_info *page, + unsigned int order, unsigned int scrub_index) +{ + rspin_lock(&d->page_alloc_lock); + + /* + * Drop the passed page in preference for the already stashed one. This + * interface is designed to be used for single-threaded domain creation. + */ + if ( d->pending_scrub || d->is_dying ) + free_domheap_pages(page, order); + else + { + d->pending_scrub_index = scrub_index; + d->pending_scrub_order = order; + d->pending_scrub = page; + } + + rspin_unlock(&d->page_alloc_lock); +} + +static struct page_info *get_stashed_allocation(struct domain *d, + unsigned int order, + nodeid_t node, + unsigned int *scrub_index) +{ + struct page_info *page = NULL; + + rspin_lock(&d->page_alloc_lock); + + /* + * If there's a pending page to scrub check if it satisfies the current + * request. If it doesn't free it and return NULL. + */ + if ( d->pending_scrub ) + { + if ( d->pending_scrub_order == order && + (node == NUMA_NO_NODE || node == page_to_nid(d->pending_scrub)) ) + { + page = d->pending_scrub; + *scrub_index = d->pending_scrub_index; + } + else + free_domheap_pages(d->pending_scrub, d->pending_scrub_order); + + /* + * The caller now owns the page or it has been freed, clear stashed + * information. Prevent concurrent usages of get_stashed_allocation() + * from returning the same page to different contexts. + */ + d->pending_scrub_index = 0; + d->pending_scrub_order = 0; + d->pending_scrub = NULL; + } + + rspin_unlock(&d->page_alloc_lock); + return page; +} + static void populate_physmap(struct memop_args *a) { struct page_info *page; @@ -275,7 +342,19 @@ static void populate_physmap(struct memop_args *a) } else { - page = alloc_domheap_pages(d, a->extent_order, a->memflags); + unsigned int scrub_start = 0; + unsigned int memflags = + a->memflags | (d->creation_finished ? 0 + : MEMF_no_scrub); + nodeid_t node = + (a->memflags & MEMF_exact_node) ? MEMF_get_node(a->memflags) + : NUMA_NO_NODE; + + page = get_stashed_allocation(d, a->extent_order, node, + &scrub_start); + + if ( !page ) + page = alloc_domheap_pages(d, a->extent_order, memflags); if ( unlikely(!page) ) { @@ -286,6 +365,30 @@ static void populate_physmap(struct memop_args *a) goto out; } + if ( memflags & MEMF_no_scrub ) + { + unsigned int dirty_cnt = 0; + + /* Check if there's anything to scrub. */ + for ( j = scrub_start; j < (1U << a->extent_order); j++ ) + { + if ( !test_and_clear_bit(_PGC_need_scrub, + &page[j].count_info) ) + continue; + + scrub_one_page(&page[j], true); + + if ( (j + 1) != (1U << a->extent_order) && + !(++dirty_cnt & 0xff) && + hypercall_preempt_check() ) + { + a->preempted = 1; + stash_allocation(d, page, a->extent_order, ++j); + goto out; + } + } + } + if ( unlikely(a->memflags & MEMF_no_tlbflush) ) { for ( j = 0; j < (1U << a->extent_order); j++ ) diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index dcb95309b12a..87ebf5a024dc 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -792,7 +792,7 @@ static void page_list_add_scrub(struct page_info *pg, unsigned int node, # define scrub_page_cold clear_page_cold #endif -static void scrub_one_page(const struct page_info *pg, bool cold) +void scrub_one_page(const struct page_info *pg, bool cold) { void *ptr; diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index 426362adb2f4..d80bfba6d393 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -145,6 +145,16 @@ unsigned long avail_node_heap_pages(unsigned int nodeid); #define alloc_domheap_page(d,f) (alloc_domheap_pages(d,0,f)) #define free_domheap_page(p) (free_domheap_pages(p,0)) +/* Free an allocation, and zero the pointer to it. */ +#define FREE_DOMHEAP_PAGES(p, o) do { \ + void *_ptr_ = (p); \ + (p) = NULL; \ + free_domheap_pages(_ptr_, o); \ +} while ( false ) +#define FREE_DOMHEAP_PAGE(p) FREE_DOMHEAP_PAGES(p, 0) + +void scrub_one_page(const struct page_info *pg, bool cold); + int online_page(mfn_t mfn, uint32_t *status); int offline_page(mfn_t mfn, int broken, uint32_t *status); int query_page_offline(mfn_t mfn, uint32_t *status); diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index 91d6a49daf16..735d5b76b411 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -661,6 +661,11 @@ struct domain /* Pointer to console settings; NULL for system domains. */ struct domain_console *console; + + /* Pointer to allocated domheap page that possibly needs scrubbing. */ + struct page_info *pending_scrub; + unsigned int pending_scrub_order; + unsigned int pending_scrub_index; } __aligned(PAGE_SIZE); static inline struct page_list_head *page_to_list( -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Fri Jan 30 15:00:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Jan 2026 15:00:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217653.1527067 (Exim 4.92) (envelope-from ) id 1vlpyp-0000HT-4V; Fri, 30 Jan 2026 15:00:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217653.1527067; Fri, 30 Jan 2026 15:00: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 1vlpyp-0000HI-1C; Fri, 30 Jan 2026 15:00:15 +0000 Received: by outflank-mailman (input) for mailman id 1217653; Fri, 30 Jan 2026 15:00:13 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlpyn-0007Ra-Jk for xen-devel@lists.xenproject.org; Fri, 30 Jan 2026 15:00:13 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 603537b5-fdec-11f0-9ccf-f158ae23cfc8; Fri, 30 Jan 2026 16:00:11 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by BY5PR03MB5329.namprd03.prod.outlook.com (2603:10b6:a03:22a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9564.7; Fri, 30 Jan 2026 14:59:50 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9564.010; Fri, 30 Jan 2026 14: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" X-Inumbo-ID: 603537b5-fdec-11f0-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=dxSVNY+H06UcZuHBWayl5UWS6JIFcyHyBgdDoFW421knGu0YV/z8uS/6alyMNbhgUOxXGK84FWgnu5vJ6MOCr+vlYjTtfmgttfQaZH0H2RVBNlERPnC9dLyBa8yF36oX7j3y1+kcgJoVUGNKmYEzQFDMnbVijINvcvIbVxUKVYf0mfZ0Ma7Ws5OQhUxgVw2v9dz70buf1FlmSbhLF/OdgV+KsMDfngO1LewYDJAxbea8wKHMCy+kJq4uJBY+g7jzgXfm7y+85ip6bvZjO3EHloHSc/sq0EOEwQ/MKPEMDarOZtZ5dkyySIE87UAu7OHz7LtQkYUxIBXHiCgYA/1D7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mMY1WE+YoJfenQ/Yslc4hayY+Dxvy/1KaKMmJebvlhM=; b=DGu+nZId9U+TlNRFpvPPYQvcR3eUrKQCy6iVK+F3TRCVqEEMCGq4vWGdsBMy3x+adnSV8lZPAtCy+6unYv/YWG9f1NL6xM7HCGPg8gfZJSlSK5VuSTjngwqhZEi0Pfdiornkd5wjUG66qlaMZUmZbv++5xcBVFOHH+SY+nm6F1n3jbTyDiyNHSKyQKhhXpWd53NiSI181PDderQXVITkPZymvoZoQeHBOu7z98TbS9mNjUUnz/SrlkHhUKXUhS8eAhybAI2ZDbGyAxTV4gFeYbN/Yazdm+cavpplKxSODcBtkXVcmH4lLJZXqtiEmnZqAJhEgSV3BTsbDn7VQfNy7A== 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=mMY1WE+YoJfenQ/Yslc4hayY+Dxvy/1KaKMmJebvlhM=; b=Xkir3ZfghtEgAq5BGkNp7XMN9NWyjV1P0b7Y9yRug42FW+yG7bHZOoIlFdDhX6/mBxclVrIcITH91EIPJyoNqCNGlxuikDeql4O1Sghi7VbBz5sFkaFS90gZ2r5pVWCAcwIKcSoTrQFJVuQhK6BHSNQJ2oSFpRyPj1qVyeoQ9mM= 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 , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: [PATCH v5 4/4] xen/mm: limit non-scrubbed allocations to a specific order Date: Fri, 30 Jan 2026 15:57:26 +0100 Message-ID: <20260130145726.85907-5-roger.pau@citrix.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260130145726.85907-1-roger.pau@citrix.com> References: <20260130145726.85907-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MR1P264CA0189.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:58::16) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|BY5PR03MB5329:EE_ X-MS-Office365-Filtering-Correlation-Id: 40828875-fd64-4bad-c2cb-08de60103776 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?aERaYzdqTEt0ZCtlU1hTS1BQakM3KzFvUDVlVzEyYU5nNC9CRlVRNGFkczl3?= =?utf-8?B?WjA2c1JPZFBOdG8yWkJZamJtSlgrZ1FLb0VUR2FPaFNsS28rN3pIT2p3Z0NB?= =?utf-8?B?dnd0cnVyeFFZNC9yMWVjUnJTNFJWUStqSnllU0pTTjNoekxGN0xtblJBWm41?= =?utf-8?B?OG9XYnBMTkNveVpockQyNlpBN0tjYTVOUUk3cDhJNllTRS9GS2MwbURucFIz?= =?utf-8?B?c2NYcWQ0WEkrczk2RDJ6MkFteUJzWnYwblpURnErNUpxRnRody82b0xjWW1l?= =?utf-8?B?MG00akZQMjdPT0ZGNmFoeWZLZGxaSnVTYUpGZm42dEF0cDBNNWtIM05HZnhv?= =?utf-8?B?WFd1eGxIbTVCZWIrbkVWSTB6UEdDaUdaak1JWWpnTmcwMWdpdzN5YlVqOUJC?= =?utf-8?B?VmhhdUtNV0JjUUZXNlhJY1pLazNSVjI0SEpkVzd5eWxOMjJ0ekxSb2wyWWZH?= =?utf-8?B?cnFTbVoyY0ZhZHRoaDg2TVhObmJPOXFLZlVTcnFZdWZ5WDU4QTBOeUNDeURr?= =?utf-8?B?dTRRM2tNQjd1M0RWYlNoOWFFS3NjVE5RY1RYaG0veUQrTFh2WjlnYmx4amxk?= =?utf-8?B?dWRtK1dvd1lCYml3RU1JVzZXakpXb2JhV3d3YmUxOWVHMCtOWWtOVW5aY3BM?= =?utf-8?B?NzlOK01INHo0Q0pycXlPQmRBNmhyNDBnTFV1RFhXQXdrSEZWemk3cXBTV1dY?= =?utf-8?B?SnNSWmMvSHNEM0xuTGdtN2VDYnM3SkM2RFZ5R3pvbjFiTE8xSGFOZ1lCVHNa?= =?utf-8?B?bHBOWS9EYWo5SVFqSGdpdVlLaDNKZnZFbGYzeFY2SFZtYVpSZEViZDhqNytE?= =?utf-8?B?bERSRXNmaTJuOUxYbTQ0M3hCSmV6TlVobDlrRk9reFFQRnRwTEl5WXpaUlhJ?= =?utf-8?B?dFRObzk1a3VBdWNPVWptaVp3eDZ4YzdYNWx3Wi83enVvOWo0UnBqeEh3WjNY?= =?utf-8?B?SUlCMzF0ejVyUXpSNFU4cDZVbVZraDFVaTZrUzlrVkV1VjYzdUp1QVRFb2Rk?= =?utf-8?B?eVpiZEN3VGprU1BXSnN0U21nUmFZLzN4ZjE4N2wxWEdZNlFYbnoxM0YzSTlo?= =?utf-8?B?dDYxTVVWeWpvUDYzRFAvYmNNWGtuYVR2dWRDc25Xd3lxaTdnaW96MmdRODQy?= =?utf-8?B?RTlPWDdxdVdMcEgyVXVFbjU0dzlKQ2kyL0VMSGdxZ3lpdFJWUjZweGM0VGNQ?= =?utf-8?B?YXFNSUZrY2d4TmpBdXF6dkJ1UG1xWXNHRklVWVN0RnNpbWZvam8yM0p2bENC?= =?utf-8?B?QnBrKzYvNnJGa014UVo5ZkNleVpvU1poZHlXdEIzdXNJSDdHVTBpR0E3blhE?= =?utf-8?B?RzFSUnNRbVpVUVZZQUtMbEZ5L3lMczlzdk9VTW1vNXJWeFFQZjN2bXVDZW83?= =?utf-8?B?VE1FOTM5UFlMWHNsVS9qT3RMQ0Y0bFlWTTdrblBqQVlZdjJUNXRSWVdtVjJZ?= =?utf-8?B?SnRkcWU4UTVhOG5zVVgvMjdlMHhVbWZmNXA0MTJGWEswNzloQm4xS3FmNGdJ?= =?utf-8?B?TXplalZvaVNaN2xNNE9ta3F1NEd2QUdFSyt2R3g3THhKYVdhVm1LMkdyTzFD?= =?utf-8?B?Ymd0aXRTRi9zcVpvaGFNaUhuUFE5VHBHdTZvUTdDU2ZjV0FoYXZpVDI1S04z?= =?utf-8?B?Wkt3ckViME5QQ1lrQ09rVWRSci93b3lvRlhIQm1RT1l6Z0VmYW8rZUFzRm1G?= =?utf-8?B?M3RqT3FWamhkK0J4RjlhdGhNRll6Mm1QLytJdzdBRnhMSVdqZFVWZllzL3Ex?= =?utf-8?B?NFR1czdXcFlmaUdOSmlXWEh4dmJHaDdDQTA1R2VvMDkzSXBBWnErcFRrT1Z1?= =?utf-8?B?a1ArSFEyV2xQSmdqNnZOMXMvM0VxSTBtaU9mU25tdGF2b24xWk11QktEQVFz?= =?utf-8?B?M0NYUmlac3F5MFJsWERKc3gydUxoUk9mVUZxeDFhVk9QeWhvUmZSTGNJM2VU?= =?utf-8?B?SWZobmY2T0hJZ3Z5akE5am9qQ25MZFdDRU1aOWZPODFhdGhoMndwTkxUemZG?= =?utf-8?B?MjBQWEdaT0dHTDRkRlJNczFTNGN3S2FnRUFQTzllSlJTTWs0SzZ0UTViY0Zz?= =?utf-8?B?L3ZvWGJPeXo5cENCYm1ObGpDbHVPL1g1TGVrb3U3cmdlS3N0Mm11VWFjTEMy?= =?utf-8?Q?P4ns=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?V1lTNEtuOEkxdHUvUHVNSWJ5cjJ2SUVnRW4zejFVckFyRk5IZkdUU0NlZEVq?= =?utf-8?B?NVpBdkRpdUk1V1Rrd29Xc0pXUlAzbHkrSHZSaEs2UUFOL1J4c25jcnNFNVJM?= =?utf-8?B?RUhzQktoeE1xdkdHVXlhcVI2NmRHZmRHS2diTDZqTjlPRkwvR291SVFVUVVR?= =?utf-8?B?bG02MnM1STJCY3U4VHViYTM3dlRDdmZlQWdRMmtkRC92L1Fld21yY250MWFh?= =?utf-8?B?R0NpVnA2RkhvcFRidlljNlMwSU8zYkJhTzNodFAzMFJ0bG1QbEZSVThjY0w5?= =?utf-8?B?ZkVaYWNmTlpBUEhseXhucFozd1lSSnVzdTd3OEgrY1B6VGRLeXJTNGplTUJ4?= =?utf-8?B?VmRHcUoyQitVSnRyZmdZU1hCdzRSRTk5SklxK0tNVGlVOFhCekswRWNmS0lx?= =?utf-8?B?SHZ5WVhEanVTOHdDUXZWNnVyVkp3OWUrREdNSTZjcWdHbDlGaS9KUWVqR3FV?= =?utf-8?B?MnZjRDFNd25xSWNjcnVuR2NEak9EVVE1KytmdStUcjlzelZvYjNmMlhnbDJs?= =?utf-8?B?ZUhFNzVDQUluVzRDczBiM1hDV2VHbml1aTk1czc2TSsxamVRMFlLeEo2bTJD?= =?utf-8?B?OUF0RWxZeW11dVhxV0Y5RVZFU0s3em9aY09obXdsdVhhbzIzeTJmdU9leUZ1?= =?utf-8?B?TjBVcUloTXdMcit3THlOckcvemM3RHhpYlBNQnYxV0xHZmdxWUVVUXl1VFhG?= =?utf-8?B?Zng3NS80UWlpbTRCYTZnS09ibXFDUW40SittdFF4YUxkTXY2SHg1b1E3Q2Ju?= =?utf-8?B?bmlIbHlFZkZ2MlNBSXBCaWdnMGZib0ZlUVVPanZBRmQ4eVM4dzNtZVdHVFpE?= =?utf-8?B?UkFtd3YzRUU2ZkR1OFIzeUFYbzA4TThhVFhRZXk2UG0yWU5JN00xMEZRd1hi?= =?utf-8?B?U3VYMDFOV2hkeWJzS1RsaTdYM2R2MC91YndYaG8yanU1b2Q0THVDbERheUtn?= =?utf-8?B?THQ4Y3ZNNFd1ZEc1Q3VmZE0zQXE5Zm1xNE0zU0k0Q0ZWcWJwRFh6a3NOVmxL?= =?utf-8?B?SHlVUEQwZTdEaFR3Q2Y5QzR2ZkJreUd4c0pUZ0FPRHJyY0R2ZlFoZmJYSTBh?= =?utf-8?B?RWZURXdoRmR3ZHVpOEFCam5pWXBWaXhySVFlMHVId3k4bXFzcnlBTk5XcXFF?= =?utf-8?B?eWgwelVKKzNwbzJTbVB0bEVKc3NQNDlNNTd0NXBoZUJUN3BMNDBFUmhNVTVN?= =?utf-8?B?NzVwbFNZU05VZmV4UVNmbHJBL1QxRmQ5Z0V4bFluMEVjc1NpZnlwNU05QVZW?= =?utf-8?B?VEhXbm0xY0NZNDJZblUwd1pvYk5CNitHMVI3NEtxOXhTNDRLRTlnQVI0TTJl?= =?utf-8?B?VHN5NVoxcHJIcUt5dkJYNlUxeHRXMDNKQ3ZwVnlrb2U3b3lKS1U4WkV1TEQ4?= =?utf-8?B?OVpKbnJ1V1RkeVpXVTF1dVpDUVE5VWR0YXpRYUI1eHlZL2tOK2l5SkViR3hr?= =?utf-8?B?aVNFbEFsRzg2UzgzV3RuaXp2b0dreVJ5OGYrT3BXM2J0RXJUWVRYc1J6NXc0?= =?utf-8?B?R1JjUEJLcVUzNHBkZUZxeUhmejYzWDkvSzM2VVBoemRJSkdNYkFkN25nbGI0?= =?utf-8?B?ekRjL0xBSG1FTXIvblNMZ05yaHBqaUZpSFY4c0xVNjZBSWErWFFrdHF0b0to?= =?utf-8?B?Qmk0U2ZVeXZydWpQYVkweEtvWTU3NnZML0V4SWFjSTNkblhMcDRDY2hkeVM4?= =?utf-8?B?ZzdYMml3TnJjcjYzOFJYM1phSTNKYlNvS01aYmpwNk1aV0JwQ2l6cFU5TjFs?= =?utf-8?B?ZXlKQnMwMUloMkJZalg0aEs5aHEwTVBWdXZjWFJ6WUhPZmVaYmpSYzl6VHNI?= =?utf-8?B?SlVyZXVQU1VEUkJhRXFQRzdqYWhLbmRzSzUvcmFLNXR1MUF3VSs2d0trcC83?= =?utf-8?B?V2FQaWxwTm9HRi93ajJvdkhhZ2pHZ0c3aGE2NjNOL2kwc054c2N6K3dxTmJC?= =?utf-8?B?WkdrSW5wR2NhamwvSG12VTRuV2R4MEhCNEtJMHg2d2V4MkRWOGQ2ZWUyQW5P?= =?utf-8?B?UWY3MHV2S0NmUmYrOCtGSUdGNjBJakRWUXphcCt6bDJySmYxL1YxSjFJWFVz?= =?utf-8?B?eDhvODVoMy9GL0hwT25EeGtCS2lRZWQ3S29UQVBialJQZ281NytNNmovN1c2?= =?utf-8?B?ejNpczhSUFAvREhKWjUycE02eHVnbWxMWE1uL3NzNUhmeXIyOG9ST1h6RHlJ?= =?utf-8?B?ZTdXTVY2cEtHZE5UaC9ZTmtiNXh1a1lQbXUrTlUwWW52cjkvSktuZHFUUG5q?= =?utf-8?B?ZWhkck81NkZDdm9tSGNRb2JKdCt4b29PeFFwRyt1ZERhNGVWbHIrTHE4aDZt?= =?utf-8?B?anVnZko5QWpLdm9VOWJ2Q1AyNmUxZVZnc0JyT2txV09PRVZ0QlpQZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 40828875-fd64-4bad-c2cb-08de60103776 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2026 14:59:50.1458 (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: KDiA6ntw4JjT2SI5r/rkIF51X5+aOPWCQ0MZcl6El2XJefWJocqqemexQ/vezLfdLd8xYEhGPvs5FBO0tOhGwA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB5329 The current logic allows for up to 1G pages to be scrubbed in place, which can cause the watchdog to trigger in practice. Reduce the limit for in-place scrubbed allocations to a newly introduced define: CONFIG_DIRTY_MAX_ORDER. This currently defaults to CONFIG_PTDOM_MAX_ORDER on all architectures. Also introduce a command line option to set the value. Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed") Signed-off-by: Roger Pau Monné --- Changes since v3: - Note the order limitation is only post-boot. Changes since v2: - Move placement of the max-order-dirty option help. - Add note in memop-max-order about interactions. - Use CONFIG_PTDOM_MAX_ORDER as the default. Changes since v1: - Split from previous patch. - Introduce a command line option to set the limit. --- docs/misc/xen-command-line.pandoc | 13 +++++++++++++ xen/common/memory.c | 3 --- xen/common/page_alloc.c | 23 ++++++++++++++++++++++- xen/include/xen/mm.h | 4 ++++ 4 files changed, 39 insertions(+), 4 deletions(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 15f7a315a4b5..3577e491e379 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -1837,6 +1837,16 @@ presented as the number of bits needed to encode it. This must be at least one pending bit to be allocated. Defaults to 20 bits (to cover at most 1048576 interrupts). +### max-order-dirty +> `= ` + +Specify the maximum allocation order allowed when scrubbing allocated pages +in-place. The allocation is non-preemptive, and hence the value must be keep +low enough to avoid hogging the CPU for too long. + +Defaults to `CONFIG_DIRTY_MAX_ORDER` or if unset to `CONFIG_PTDOM_MAX_ORDER`. +Note those are internal per-architecture defines not available from Kconfig. + ### mce (x86) > `= ` @@ -1878,6 +1888,9 @@ requests issued by the various kinds of domains (in this order: ordinary DomU, control domain, hardware domain, and - when supported by the platform - DomU with pass-through device assigned). +Note orders here can be further limited by the value in `max-order-dirty` for +allocations requesting pages to be scrubbed in-place. + ### mmcfg (x86) > `= [,amd-fam10]` diff --git a/xen/common/memory.c b/xen/common/memory.c index 285546298ed9..c2682ecbe5b8 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -56,9 +56,6 @@ struct memop_args { #ifndef CONFIG_CTLDOM_MAX_ORDER #define CONFIG_CTLDOM_MAX_ORDER CONFIG_PAGEALLOC_MAX_ORDER #endif -#ifndef CONFIG_PTDOM_MAX_ORDER -#define CONFIG_PTDOM_MAX_ORDER CONFIG_HWDOM_MAX_ORDER -#endif static unsigned int __read_mostly domu_max_order = CONFIG_DOMU_MAX_ORDER; static unsigned int __read_mostly ctldom_max_order = CONFIG_CTLDOM_MAX_ORDER; diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 87ebf5a024dc..725d6ee488a4 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -267,6 +267,13 @@ static PAGE_LIST_HEAD(page_offlined_list); /* Broken page list, protected by heap_lock. */ static PAGE_LIST_HEAD(page_broken_list); +/* Maximum order allowed for post-boot allocations with MEMF_no_scrub. */ +#ifndef CONFIG_DIRTY_MAX_ORDER +# define CONFIG_DIRTY_MAX_ORDER CONFIG_PTDOM_MAX_ORDER +#endif +static unsigned int __ro_after_init dirty_max_order = CONFIG_DIRTY_MAX_ORDER; +integer_param("max-order-dirty", dirty_max_order); + /************************* * BOOT-TIME ALLOCATOR */ @@ -1008,7 +1015,13 @@ static struct page_info *alloc_heap_pages( pg = get_free_buddy(zone_lo, zone_hi, order, memflags, d); /* Try getting a dirty buddy if we couldn't get a clean one. */ - if ( !pg && !(memflags & MEMF_no_scrub) ) + if ( !pg && !(memflags & MEMF_no_scrub) && + /* + * Allow any order unscrubbed allocations during boot time, we + * compensate by processing softirqs in the scrubbing loop below once + * irqs are enabled. + */ + (order <= dirty_max_order || system_state < SYS_STATE_active) ) pg = get_free_buddy(zone_lo, zone_hi, order, memflags | MEMF_no_scrub, d); if ( !pg ) @@ -1117,6 +1130,14 @@ static struct page_info *alloc_heap_pages( scrub_one_page(&pg[i], cold); dirty_cnt++; + + /* + * Use SYS_STATE_smp_boot explicitly; ahead of that state + * interrupts are disabled. + */ + if ( system_state == SYS_STATE_smp_boot && + !(dirty_cnt & 0xff) ) + process_pending_softirqs(); } else check_one_page(&pg[i]); diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index d80bfba6d393..cf3796d4286d 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -232,6 +232,10 @@ struct npfec { #else #define MAX_ORDER 20 /* 2^20 contiguous pages */ #endif +#ifndef CONFIG_PTDOM_MAX_ORDER +# define CONFIG_PTDOM_MAX_ORDER CONFIG_HWDOM_MAX_ORDER +#endif + mfn_t acquire_reserved_page(struct domain *d, unsigned int memflags); /* Private domain structs for DOMID_XEN, DOMID_IO, etc. */ -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Fri Jan 30 22:10:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 30 Jan 2026 22:10:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1217909.1527077 (Exim 4.92) (envelope-from ) id 1vlwh1-0000r9-MT; Fri, 30 Jan 2026 22:10:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1217909.1527077; Fri, 30 Jan 2026 22:10:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vlwh1-0000r1-HJ; Fri, 30 Jan 2026 22:10:19 +0000 Received: by outflank-mailman (input) for mailman id 1217909; Fri, 30 Jan 2026 22:10: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 1vlwh0-0000qv-Gk for xen-devel@lists.xenproject.org; Fri, 30 Jan 2026 22:10:18 +0000 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 73d76008-fe28-11f0-9ccf-f158ae23cfc8; Fri, 30 Jan 2026 23:10:15 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id A0EAB44046; Fri, 30 Jan 2026 22:10:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE37BC4CEF7; Fri, 30 Jan 2026 22:10: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: 73d76008-fe28-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769811013; bh=KHtw9k9MNomHYBkR+y/1CIUVqSW/4g99PMmsyPDbuoQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=juQ6A1CfCMYpJy+fSnJ5ryuhK5WjkC0n4n2c36AMlBvsXc9Qq4YwCeyKO35lRSk6r 2sFGVU2xkPlB2Heskh00c5R6HgA30mQnQ0CGCAHALbnlTAoZGIVXVYUxn5VvUlyWDd TdYpfWYy+OX0fdli5yTUlKOtoYOuJh27Dmqj8VJFUEgUb5vm3m+91C5qWbMcYj/qN3 urB24OvVQsqlinkjaqFziR4y0+DEiOsELH7Lb+SI9Ss0AeP72RNBYKbBCCJP1isVV2 HM0MyC2aYI/KBSO0LnqBeZ3sByV4t4uZ7IM13oav2djPDAoTulI52/N+psPbjKYHEk lLCYVccgxor6w== Date: Fri, 30 Jan 2026 14:10:06 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Jan Beulich cc: Stefano Stabellini , "xen-devel@lists.xenproject.org" , Andrew Cooper , Anthony PERARD , Bertrand Marquis , Juergen Gross , Julien Grall , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Volodymyr Babchuk , Grygorii Strashko , Oleksii Moisieiev Subject: Re: [PATCH v9 1/5] xen/domctl: chain SCI handling before IOMMU in assign_device domctl In-Reply-To: <7bea7067-0d7d-4eaa-bd52-8735f90998c5@suse.com> Message-ID: References: <69d32e2440b2ef194b4893e5dd29c2dd9d216a90.1769696107.git.oleksii_moisieiev@epam.com> <7bea7067-0d7d-4eaa-bd52-8735f90998c5@suse.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Fri, 29 Jan 2026, Jan Beulich wrote: > On 30.01.2026 00:14, Stefano Stabellini wrote: > > On Thu, 29 Jan 2026, Oleksii Moisieiev wrote: > >> --- a/xen/arch/arm/firmware/sci.c > >> +++ b/xen/arch/arm/firmware/sci.c > >> @@ -126,6 +126,42 @@ int sci_assign_dt_device(struct domain *d, struct dt_device_node *dev) > >> return 0; > >> } > >> > >> +int sci_do_domctl(struct xen_domctl *domctl, struct domain *d, > >> + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) > >> +{ > >> + struct dt_device_node *dev; > >> + int ret = 0; > > > > Should this be -ENXIO? > > Not unless further changes are made. That error code being set ... > > >> + switch ( domctl->cmd ) > >> + { > >> + case XEN_DOMCTL_assign_device: > >> + ret = -ENXIO; > > ... here makes sure that other XEN_DOMCTL_* making it into this function > will ... > > >> + if ( domctl->u.assign_device.dev != XEN_DOMCTL_DEV_DT ) > >> + break; > >> + > >> + if ( !cur_mediator ) > >> + break; > >> + > >> + if ( !cur_mediator->assign_dt_device ) > >> + break; > >> + > >> + ret = dt_find_node_by_gpath(domctl->u.assign_device.u.dt.path, > >> + domctl->u.assign_device.u.dt.size, &dev); > >> + if ( ret ) > >> + return ret; > >> + > >> + ret = sci_assign_dt_device(d, dev); > >> + > >> + break; > >> + > >> + default: > >> + /* do not fail here as call is chained with iommu handling */ > >> + break; > > ... succeed (by making it here). If you used -ENXIO as initializer, ret would > then need setting to 0 here. Which is functionally identical to what is there > now. OK you are right > >> @@ -195,6 +203,12 @@ static inline int sci_assign_dt_device(struct domain *d, > >> return 0; > >> } > >> > >> +static inline int sci_do_domctl(struct xen_domctl *domctl, struct domain *d, > >> + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) > >> +{ > >> + return 0; > > > > This should be -ENXIO? > > Why? Then several other XEN_DOMCTL_* would break. Or wait, no, nothing would > break at all, as this stub looks to never come into play. It hence should be > dropped. Yes, good point, it can be dropped From xen-devel-bounces@lists.xenproject.org Sat Jan 31 06:54:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 31 Jan 2026 06:54:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1218002.1527087 (Exim 4.92) (envelope-from ) id 1vm4sL-00021z-7C; Sat, 31 Jan 2026 06:54:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1218002.1527087; Sat, 31 Jan 2026 06: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 1vm4sL-00021h-1G; Sat, 31 Jan 2026 06:54:33 +0000 Received: by outflank-mailman (input) for mailman id 1218002; Sat, 31 Jan 2026 06:54: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 1vm4sK-00021b-9Z for xen-devel@lists.xenproject.org; Sat, 31 Jan 2026 06:54:32 +0000 Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [2607:f8b0:4864:20::72c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b05957e7-fe71-11f0-9ccf-f158ae23cfc8; Sat, 31 Jan 2026 07:54:29 +0100 (CET) Received: by mail-qk1-x72c.google.com with SMTP id af79cd13be357-8c70ce93afaso310076385a.0 for ; Fri, 30 Jan 2026 22:54:29 -0800 (PST) Received: from wirelessprv-10-195-209-164.near.illinois.edu (mobile-130-126-255-98.near.illinois.edu. [130.126.255.98]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8c711b8b4d3sm788464185a.13.2026.01.30.22.54.27 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Fri, 30 Jan 2026 22:54:27 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b05957e7-fe71-11f0-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769842468; x=1770447268; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=4O5ls4XojzMaTTlDBbUfkrZhtU6PflT35+xKNQyIQTw=; b=ShNv/6QMD0qlLWyRJjwn49vbMN6lYyePTiByFAkOkVw+fAud8UQEpvytzFGa/ykqEV hysuw+gZFiJz0hQZdHK+2+3i4EhKQXjnDCi5fxUGAef+Zy//rOFH4oIoQc+kGIseMQaM CqIfeCWx9oUSsnGYHos97vaWpaiYvefHo4EoIfq36EXQo/rlTKiyvdhBMAXz8eqWn/aB uD5rrQs31Gv4hnRmMOfo25PfxkpmqMRIctgy7gx3PVOPZhsce1BDchzpQHEICaXY8F86 JtYj19n3llNlG+H+dIEEbR/3/ZpkOIK9vshXjQVhQJjEa2Pb45dFHS8O06UQbRGPoome wr9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769842468; x=1770447268; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=4O5ls4XojzMaTTlDBbUfkrZhtU6PflT35+xKNQyIQTw=; b=gjw9iN0OCSqwNbgLVXMX8kwvm4pRa6ji1zi4uRu4McDMOrz0aRDU4JAlVZl/jZNclj xuEQbUkjGkIKx7bh7IPjedRvRhyh+F4gh/dd5QLiYl9aETzUv+hhKG95rcmfuvR9N8W6 WYxC68NtecNjR8EhKehwzEIYHGpepKdJgDKg9B2R2XTzXnw1eoRli9IzZV6ofxhHH4mE gHcJvVjfirsvoowOqaDg/WF2PkQ4ryKjOJrIjuuvZSaUJAD1LSK2+T7tHUTTnjqu/6OJ oyGnu35Bf3zEwFD6y9fqGFNgtEdRFT9MHSFXvcsZzGwwWcYo3fngzVOjNYEynj2+zhud vO5A== X-Forwarded-Encrypted: i=1; AJvYcCUztKFWJPI4HbhOwpMFRyoqakDGdpgy+E40veCgQ+77qaG+qcOkBobw23exwJQt7Qlr+v0bMGX2+OI=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw29QjHrrCp44ckQo4yCjKLO2dKBLWX84Weps9Ft6OXEJk8NEUb faptiKUToYywQIoCuaBHPmxzLJGt3akySR+cLl3FwvJVdrfl85n5+Q2R X-Gm-Gg: AZuq6aLi9m3jAKaZfeKDWGXn6T4vfcKDdcXsjRjq5cSyPUfwvongpFON+hjdv0oPeYj uFRawZtp+KMKhy+1z6VCP08vJ6fqhKOZYOUkSnq+jmcXscN4zIah+baVQIWeG7J2UTnKg/X4zyY nf+2zjJ/JdFP4MpjbbxvkA9/9fNeVXAxKt1JOomoeuXOyKGvPcBmFpzlNPQblqCyXFUE+L2YP23 ZgQEQkJAJI+oe78jQ6O8f/4k0oLbNBGAB5XsaaTC2x5MtFI9+nRUUptq3IsmlZhFCnwvGhD3lrw PVKui1opxCXY9Ikh5V4wJMZqrYtHVlr2SmMg5I8gxKv7tXoTkn/ACC+pH+VAh0F4iZVYQ9DCzBX JhdRy68O0HgZgDRGwWkMyBoE0GM5dHDc4mYafjXOd87Zx5/rtwW+R3WDiuInEoIj5oyMSwAMHJI mPqS3QYzXXvheg2bfkl4Kxk5E89MYBJuggd5qm1cQKEollAfKE2DrDz0PvEqe9pQjriTfdifAJU jy2oouRTHooyVVkpesnQcSWZUHR+SFUzL3TFqcBcg6xhhRMIw+r3QY= X-Received: by 2002:a05:620a:2544:b0:8c7:995:b961 with SMTP id af79cd13be357-8c9eb2dffc6mr728698485a.58.1769842468447; Fri, 30 Jan 2026 22:54:28 -0800 (PST) From: Wentao Zhang To: andrew.cooper3@citrix.com Cc: anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, nicola.vetrini@bugseng.com, roger.pau@citrix.com, sstabellini@kernel.org, xen-devel@lists.xenproject.org, samaan.dehghan@gmail.com Subject: Re: [PATCH] CI/randconfig: Disable CONFIG_CONDITION_COVERAGE Date: Sat, 31 Jan 2026 00:54:07 -0600 Message-Id: <20260131065407.12992-1-zhangwt1997@gmail.com> X-Mailer: git-send-email 2.39.5 (Apple Git-154) In-Reply-To: <20260112163827.1023401-1-andrew.cooper3@citrix.com> References: <20260112163827.1023401-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit > In addition to GCC not liking x86_emulate(), it turns out that Clang is still > rather more a work in progress than a usable feature, causing failures in the > FreeBSD builds: > > https://cirrus-ci.com/task/5934059060199424 > > Exclude CONFIG_CONDITION_COVERAGE from Ranconfig until it gets a bit more > stable. Hi Andrew, Thanks for catching this. I can confirm it is reliably reproducible on a FreeBSD host with LLVM toolchain, as long as CONFIG_COVERAGE is on (regardless of CONFIG_CONDITION_COVERAGE). So this patch probably won't avoid the failure in the future. See also the report by Roger which predates the introduction of LLVM condition coverage: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290381 The cause looks multifold: 1. Direct cause is null dereferences in LLVM linker https://github.com/llvm/llvm-project/blob/llvmorg-23-init/lld/ELF/OutputSections.cpp#L631 https://github.com/llvm/llvm-project/blob/llvmorg-23-init/lld/ELF/InputSection.cpp#L419 2. The use of objcopy from elftoolchain on FreeBSD $ objcopy --version objcopy (elftoolchain r3769) 3. gnu_inline attribute of xen/include/xen/sort.h On FreeBSD 14.2, the following sequence using small program reproduces the crash: ``` cat > 1.c <<'EOF' #include "h.h" int fun1(int a, int b) { return add(a, b); } EOF cat > 2.c <<'EOF' #include "h.h" int func2(int a, int b) { return add(a+1, b+1); } EOF cat > h.h <<'EOF' extern inline __attribute__((__gnu_inline__)) int add(int a, int b) { return a + b; } EOF # OBJCOPY=/usr/local/bin/objcopy # binutils -- fine # OBJCOPY=/usr/bin/llvm-objcopy # LLVM -- fine # OBJCOPY=cp # skip -- fine OBJCOPY=/usr/bin/objcopy # elftoolchain -- X CFLAGS='-O1 -fprofile-instr-generate -fcoverage-mapping' clang $CFLAGS -c 1.c -o 1.o.tmp clang $CFLAGS -c 2.c -o 2.o.tmp $OBJCOPY 1.o.tmp 1.o $OBJCOPY 2.o.tmp 2.o ld.lld -o output.o -r 1.o 2.o ``` I will consider filing a report/patch to LLVM but I am frankly not sure whether it will be accommodated given (1) this unusual combination of toolchain to trigger the bug (2) elftoolchain is retiring in newer FreeBSD. Thanks, Wentao > > Signed-off-by: Andrew Cooper [snip] From xen-devel-bounces@lists.xenproject.org Sat Jan 31 07:11:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 31 Jan 2026 07:11:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1218010.1527098 (Exim 4.92) (envelope-from ) id 1vm58n-0004r7-FI; Sat, 31 Jan 2026 07:11:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1218010.1527098; Sat, 31 Jan 2026 07:11: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 1vm58n-0004r0-Ax; Sat, 31 Jan 2026 07:11:33 +0000 Received: by outflank-mailman (input) for mailman id 1218010; Sat, 31 Jan 2026 07:11:32 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vm58m-0004qu-J5 for xen-devel@lists.xenproject.org; Sat, 31 Jan 2026 07:11:32 +0000 Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [2607:f8b0:4864:20::731]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0c4ce113-fe74-11f0-b161-2bf370ae4941; Sat, 31 Jan 2026 08:11:23 +0100 (CET) Received: by mail-qk1-x731.google.com with SMTP id af79cd13be357-8c533228383so177401085a.3 for ; Fri, 30 Jan 2026 23:11:23 -0800 (PST) Received: from wirelessprv-10-195-209-164.near.illinois.edu (mobile-130-126-255-98.near.illinois.edu. [130.126.255.98]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-894d376da66sm74364426d6.50.2026.01.30.23.11.19 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Fri, 30 Jan 2026 23:11:20 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0c4ce113-fe74-11f0-b161-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769843482; x=1770448282; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=dZJSAdndnBx9rrkCE0DjP5dE8MJAA2DW4Ofjhp7aSoM=; b=deTncHYRD+BqKcRD7BB3vxzt2TQmQWGEpxHC+EmXjKO0+mPTpgWM4Ug5rL8hXzfq13 Px4Gz6gZgBZ6icaJaJZBiWrsP+80s00DdOgBO6A+WB0Chtzui0tKc4+KIMlPJb2Scfmd Rvp1Q1EPWknMZyQdpsgva1UNW6ieB0AHfpEUwB5Wp47+8BdAuu32h3WxxH5aoPFxLfYD b3A/vc75EcasHTuy6y6dOkDKKMK1qCJn36OYxUCeCIWddv5iyl6zNOQwnexaJQnfn292 3zLWybGDq/a+NzFc62lk8J7J7cZ3aD9PNMLbJURrstexEEcCKJOr+fBD61x9VXdCqeqC S69A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769843482; x=1770448282; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=dZJSAdndnBx9rrkCE0DjP5dE8MJAA2DW4Ofjhp7aSoM=; b=Td/WM2kpoBNLUilRZhL9YOxqSpTr1/+B9G6rkMH/yTkM97+MLh9VSNoPp2YyQjh/GJ qy4roxsCXZDmtClIBnnIrL2PhgRdB35tnKpYLHs5Y2k+uLVSBRBGvhLH5LQ+yGrYIUTe UXwp+LICKTF9k7BeabA5qj8cxgliIgNwoBXzmD+ret4IkiPZuNkxX2slf7i4Eb9k8W7E l40M1ev0MiKG/F+98bMDDRDGaVCqkBKcvbWW3o0vteUjdaVOZjt2eIqx2y1346YLW76f 463Oa2MtomlxA3dmobxPqNSUnnMjlsR0jHRrHQ4Yp97rebtcCkdW8Ou6ogWdnWp/3GcP N6oQ== X-Forwarded-Encrypted: i=1; AJvYcCWqtf8YGiW9mM98rbr0YmzppJfN1N5ssp8bLSfOTCULOKZZPv+sphsk2YJ64e3TvOEj4+QQzN/QYBk=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz8Iw4cx3MInsyNgKyezsCqEtpZsDDLDotG/6NAW38hbUGTZGky 17kCB5ssTJ2NDlNW8/yyD23jffEAloX/b2QXY6sIF3/UOA350yPsIPNP X-Gm-Gg: AZuq6aIr+L9UHSylLEtZusoir/3gGYjnQvdz/uR0t/0FO+lQ+4YjPGmrpwk/y9LGRna 7kmOVBSj2XDPISKEHe4W/JuL20D8ybRfoYfX3rChnQ5eYSBwfAZ6bYdggPjysMLuWJUPrJFD7+m 3tfoVZJZkaclZ3bG1zMDB9P5wIzZMBVPOjg71WBfusY+CUU4ZESiYf0aPMUJHrs5qo+WC+yoAXk 0dsGA1K4FI74601keH5lDeU5+WocUr/jf/EeFlPclHnoVK+hvZQ4FcSVPuuSdMi1vbggLtk/zT+ ps22LjWHochzJrll2UqcbbHZWCxVjOIlFh/MOQoEWbLi0hx5cxJNjxwx5UopRbTg1K8W0fOykwV j0oaNvCkp99Jaw5ReSD3Ixl+C0JhhJhWL073UkNCR3AaZBr76986IcMBIEZDYHvTbbBZNxf4Hza 8wrg09ZRssDzHLNKcQkeeJbRF2BXhxRA79rBp3HByf4tVuQtYqceQjFquwUhvJysE8eS/FZXy37 ui2R5NeCpNR4crOuyzQQQ8LZ2a8EkyDBl0s6dBzpQU9 X-Received: by 2002:a05:620a:1d0a:b0:8ca:55:ac60 with SMTP id af79cd13be357-8ca0055ae50mr44081285a.78.1769843481649; Fri, 30 Jan 2026 23:11:21 -0800 (PST) From: Wentao Zhang To: zhangwt1997@gmail.com Cc: andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, samaan.dehghan@gmail.com, sstabellini@kernel.org, xen-devel@lists.xenproject.org Subject: Ping: [XEN PATCH] xen: add paddings after bitmap section in LLVM coverage profile Date: Sat, 31 Jan 2026 01:11:16 -0600 Message-Id: <20260131071116.13650-1-zhangwt1997@gmail.com> X-Mailer: git-send-email 2.39.5 (Apple Git-154) In-Reply-To: <71775ef5c267b3888ddf3e4a55bdb5914cf1f890.1766228666.git.zhangwt1997@gmail.com> References: <71775ef5c267b3888ddf3e4a55bdb5914cf1f890.1766228666.git.zhangwt1997@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Thanks, Wentao On Sat, 20 Dec 2025 05:22:43 -0600, Wentao Zhang wrote: > The layout of LLVM coverage profile is like > > header > data section > (padding #1) > counter section > (padding #2) > bitmap section > (padding #3) > name section > (padding #4) > > Padding areas #1 and #2 are always zeroed on 64-bit platforms, but that > is not the case for padding area #3 and #4. See LLVM docs [1] and > compiler-rt's own version of "get_size()" [2]. > > The implementation in 08c787f "xen: Enable MC/DC coverage for Clang" > partly considers padding #4 in get_size() but not in dump(). It worked > because in the header .padding_bytes_after_bitmap_bytes is also > initialized to zero so a reader may still know how to parse the profile. > But we should probably not base ourselves on such assumption. Instead > let's be as close as possible to hosted environment generated profiles, > i.e. those generated by compiler-rt. > > In this patch, get_size() implementation is mathematically the same but > changed to reflect the layout somewhat better. For dump(), padding #4 is > added both in the header and in the payload. > > [1] https://llvm.org/docs/InstrProfileFormat.html > [2] https://github.com/llvm/llvm-project/blob/llvmorg-20.1.8/compiler-rt/lib/profile/InstrProfilingBuffer.c#L223 > > Signed-off-by: Wentao Zhang > > --- > > As an aside, an alternative way that has better long-term > maintainability would be [3]. I ran it with Xen and could unofficially > confirm it works, modulo implementation nitty-gritties. > > [3] https://github.com/llvm/llvm-project/pull/167998 > --- > xen/common/coverage/llvm.c | 12 +++++++----- > 1 file changed, 7 insertions(+), 5 deletions(-) > > diff --git a/xen/common/coverage/llvm.c b/xen/common/coverage/llvm.c > index 5663fb1..f15ec11 100644 > --- a/xen/common/coverage/llvm.c > +++ b/xen/common/coverage/llvm.c > @@ -141,11 +141,11 @@ static void cf_check reset_counters(void) > > static uint32_t cf_check get_size(void) > { > - uint32_t size = ROUNDUP(sizeof(struct llvm_profile_header) + END_DATA - START_DATA + > - END_COUNTERS - START_COUNTERS + END_NAMES - START_NAMES, 8); > - if ( IS_ENABLED(CONFIG_CONDITION_COVERAGE) ) > - size += ROUNDUP(END_BITMAP - START_BITMAP, 8); > - return size; > + return sizeof(struct llvm_profile_header) + > + END_DATA - START_DATA + > + END_COUNTERS - START_COUNTERS + > + ROUNDUP(END_BITMAP - START_BITMAP, 8) + > + ROUNDUP(END_NAMES - START_NAMES, 8); > } > > static int cf_check dump( > @@ -167,6 +167,7 @@ static int cf_check dump( > #if defined(CONFIG_CONDITION_COVERAGE) && LLVM_PROFILE_VERSION >= 9 > .num_bitmap_bytes = END_BITMAP - START_BITMAP, > .bitmap_delta = START_BITMAP - START_DATA, > + .padding_bytes_after_bitmap_bytes = (-(END_BITMAP - START_BITMAP)) & 7, > #endif > }; > unsigned int off = 0; > @@ -183,6 +184,7 @@ static int cf_check dump( > APPEND_TO_BUFFER(START_COUNTERS, END_COUNTERS - START_COUNTERS); > #if defined(CONFIG_CONDITION_COVERAGE) > APPEND_TO_BUFFER(START_BITMAP, END_BITMAP - START_BITMAP); > + off += header.padding_bytes_after_bitmap_bytes; > #endif > APPEND_TO_BUFFER(START_NAMES, END_NAMES - START_NAMES); > #undef APPEND_TO_BUFFER > -- > 2.34.1 From xen-devel-bounces@lists.xenproject.org Sat Jan 31 14:14:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 31 Jan 2026 14:14:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1218118.1527107 (Exim 4.92) (envelope-from ) id 1vmBjH-0002Qx-58; Sat, 31 Jan 2026 14:13:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1218118.1527107; Sat, 31 Jan 2026 14:13:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vmBjH-0002Qp-0n; Sat, 31 Jan 2026 14:13:39 +0000 Received: by outflank-mailman (input) for mailman id 1218118; Sat, 31 Jan 2026 14:13:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vmBjF-0002Qj-Mb for xen-devel@lists.xenproject.org; Sat, 31 Jan 2026 14:13:37 +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 07f22d7b-feaf-11f0-b161-2bf370ae4941; Sat, 31 Jan 2026 15:13:36 +0100 (CET) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-b7cf4a975d2so431111066b.2 for ; Sat, 31 Jan 2026 06:13:35 -0800 (PST) Received: from [192.168.0.109] ([91.123.155.165]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8dd99188adsm448717366b.50.2026.01.31.06.13.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 31 Jan 2026 06:13:33 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 07f22d7b-feaf-11f0-b161-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769868815; x=1770473615; 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=cOcO4OFNFjOuvP+jlNFYVPlommE9wXOl86bUnyhSPrM=; b=k2AysRoIHhcYrHOfhnF28NT9KwdEGA5Hu5mcw0+cenk4BNnQXE76rx7Sfbapsdpmci 6oJYMqrUDWVwVzad5yCEWej64M4C2n13k78kZGrPMM1uCtFAl25aXaDhfCydsOYnVkOM oMVS1LFKzzPQm/7aIA3i2GCxHf72t2emxnbjLgabiru8SlNgdwMIMyK/+ZAHfXwwP89N I2tgOBpxZ7Mh2BGIbFHraY1r8BuKYYQMA4GXwcAS+EMqB2pMOyx/b/w1tGBRDFJfINHZ N39exdH9tOndOcyAaovQ6xqYkizq52fJYRLiNoBgQ7gX6k7LR4H5f+AjUXDMa2xK1H43 61QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769868815; x=1770473615; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cOcO4OFNFjOuvP+jlNFYVPlommE9wXOl86bUnyhSPrM=; b=nDg4uCzf53sDR+WsTWQY1b+BwrO3sbmVtr4SS98Xq7EKg1NPiaEJQ54ztmnWtFXEjz OL1P0MyZGtsrMGvx1RSyl3d+WBa8OVPBbOAnUBu7oZqZimM662+ZQTU9b2CJ9r2QcDjs 5UPbuKfJ+FmR7/WnmdgEpCfuTkmMRmIdsMaa5H9cC1BUeXR7q1knU0cI45eWTnRDA2+Z 537VUxE9msfW4e+6VYN5xyzkwB/n1SJSGiAhE/ZobFZ3dmtAQxsLwl+pXgVJ/L+JnEZg WGbuWxBWX4iDconahmsG6QQ9SS9D5Ggrrtz9K3YaFOOuzV0+PSfIcKhDCAQ2SGdOmUXZ CQEw== X-Forwarded-Encrypted: i=1; AJvYcCXkmDRBoGrgKnM9BCJsViPmk7oao+xqGBknYC3DnnxhaL3tAWx0VR+sBRwz78AExVRkHXk/nr4GDVE=@lists.xenproject.org X-Gm-Message-State: AOJu0YyuaIizfJehMXg+zr3PBN1UsuY8uDxijL1b5EhkiN8R/c4+9ppE km2I6hst7QTgGsrwOsyDWLiGna3rKL2mlVX+FtTSkRl6Sjx4I6auvATw+2cU+EEO X-Gm-Gg: AZuq6aIcxjQuPxeCx5w0S1TK3nD+HfZUQOVlUdXMBkkg7xN6z9qiG9vVgFesZTFCDIk garPvLprtyo/JTWZwnNXhX+j1FsMgC6VWeupQXgrgfSvFsxxoxxiiCtcxI80F+BNj4URJbAuofj +O946hZBUrjGXeZQ1a3LY7cPYMyMvnJyX8cI9tum8EOCE5EDvVX2BZ2EzDhyoscZB35JJkWoqBZ Uz473zwXm9QrhFOn7Zn4AVuBqSHdfpqMIEBoihYLoQF8zB4y+07V5AapWHMHsU/0OmSR/DTmS7q Ir9kFbDAw0DEowRnAicccb1aVpHSU1uOv8VZsWT/aNdP9adiEJVk4VBsgvr4KZY6snYsdKgcFTZ 13C1CmScrCeHmVLbAE4zyPlKfd+bl2oNiaAuOLf4P77d5kBGOlU2ICHTeDBF/uDxZkog42kytRY 8FrTOcsEpcXSm7+VQ= X-Received: by 2002:a17:907:9494:b0:b87:34e3:a79e with SMTP id a640c23a62f3a-b8dff56a919mr337390066b.12.1769868814574; Sat, 31 Jan 2026 06:13:34 -0800 (PST) Message-ID: <3fd46041-77e0-44c9-891e-8a50b89cb56a@gmail.com> Date: Sat, 31 Jan 2026 16:13:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 07/12] iommu/ipmmu-vmsa: Implement suspend/resume callbacks To: Mykola Kvach , xen-devel@lists.xenproject.org Cc: Mykola Kvach , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <220c777ee30fd35afeedefff5a73d62d6ea1e0ac.1765472890.git.mykola_kvach@epam.com> Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: <220c777ee30fd35afeedefff5a73d62d6ea1e0ac.1765472890.git.mykola_kvach@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11.12.25 20:43, 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 V7: > - moved suspend context allocation before pci stuff Thanks for making this change, one note below ... > --- > xen/drivers/passthrough/arm/ipmmu-vmsa.c | 305 ++++++++++++++++++++++- > 1 file changed, 298 insertions(+), 7 deletions(-) > > diff --git a/xen/drivers/passthrough/arm/ipmmu-vmsa.c b/xen/drivers/passthrough/arm/ipmmu-vmsa.c > index ea9fa9ddf3..6765bd3083 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,245 @@ 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; > +} > + > +#ifdef CONFIG_HAS_PCI > +static void ipmmu_free_ctx_suspend(struct device *dev) > +{ > + struct ipmmu_vmsa_backup *backup_data, *tmp; > + > + spin_lock(&ipmmu_devices_backup_lock); > + > + list_for_each_entry_safe( backup_data, tmp, &ipmmu_devices_backup, list ) > + { > + if ( backup_data->dev == dev ) > + { > + list_del(&backup_data->list); > + xfree(backup_data->utlbs_val); > + xfree(backup_data->asids_val); > + xfree(backup_data); > + break; > + } > + } > + > + spin_unlock(&ipmmu_devices_backup_lock); > +} > +#endif /* CONFIG_HAS_PCI */ > + > +#endif /* CONFIG_SYSTEM_SUSPEND */ ... I noticed the Kconfig guards for ipmmu_alloc_ctx_suspend() and ipmmu_free_ctx_suspend() are asymmetrical. This creates a configuration (CONFIG_SYSTEM_SUSPEND=y, CONFIG_HAS_PCI=n) where the allocation function exists but the deallocation function is compiled out. While this feels a bit fragile, I understand this is necessary to avoid an "unused function" compiler error, as the only caller is within a CONFIG_HAS_PCI block. Since the alternative would break the build, I think the current implementation is acceptable. I have no further comments. The patch looks good now. > + > static int ipmmu_domain_init_context(struct ipmmu_vmsa_domain *domain) > { > uint64_t ttbr; > @@ -559,6 +821,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 +880,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); > } > > @@ -1340,10 +1608,11 @@ static int ipmmu_add_device(u8 devfn, struct device *dev) > struct iommu_fwspec *fwspec; > > #ifdef CONFIG_HAS_PCI > + int ret; > + > if ( dev_is_pci(dev) ) > { > struct pci_dev *pdev = dev_to_pci(dev); > - int ret; > > if ( devfn != pdev->devfn ) > return 0; > @@ -1371,6 +1640,15 @@ static int ipmmu_add_device(u8 devfn, struct device *dev) > /* Let Xen know that the master device is protected by an IOMMU. */ > dt_device_set_protected(dev_to_dt(dev)); > } > + > +#ifdef CONFIG_SYSTEM_SUSPEND > + if ( ipmmu_alloc_ctx_suspend(dev) ) > + { > + dev_err(dev, "Failed to allocate context for suspend\n"); > + return -ENOMEM; > + } > +#endif > + > #ifdef CONFIG_HAS_PCI > if ( dev_is_pci(dev) ) > { > @@ -1379,26 +1657,28 @@ static int ipmmu_add_device(u8 devfn, struct device *dev) > struct pci_host_bridge *bridge; > struct iommu_fwspec *fwspec_bridge; > unsigned int utlb_osid0 = 0; > - int ret; > > bridge = pci_find_host_bridge(pdev->seg, pdev->bus); > if ( !bridge ) > { > dev_err(dev, "Failed to find host bridge\n"); > - return -ENODEV; > + ret = -ENODEV; > + goto free_suspend_ctx; > } > > fwspec_bridge = dev_iommu_fwspec_get(dt_to_dev(bridge->dt_node)); > if ( fwspec_bridge->num_ids < 1 ) > { > dev_err(dev, "Failed to find host bridge uTLB\n"); > - return -ENXIO; > + ret = -ENXIO; > + goto free_suspend_ctx; > } > > if ( fwspec->num_ids < 1 ) > { > dev_err(dev, "Failed to find uTLB"); > - return -ENXIO; > + ret = -ENXIO; > + goto free_suspend_ctx; > } > > rcar4_pcie_osid_regs_init(bridge); > @@ -1407,7 +1687,7 @@ static int ipmmu_add_device(u8 devfn, struct device *dev) > if ( ret < 0 ) > { > dev_err(dev, "No unused OSID regs\n"); > - return ret; > + goto free_suspend_ctx; > } > reg_id = ret; > > @@ -1422,7 +1702,7 @@ static int ipmmu_add_device(u8 devfn, struct device *dev) > { > rcar4_pcie_osid_bdf_clear(bridge, reg_id); > rcar4_pcie_osid_reg_free(bridge, reg_id); > - return ret; > + goto free_suspend_ctx; > } > } > #endif > @@ -1431,6 +1711,13 @@ static int ipmmu_add_device(u8 devfn, struct device *dev) > dev_name(fwspec->iommu_dev), fwspec->num_ids); > > return 0; > +#ifdef CONFIG_HAS_PCI > + free_suspend_ctx: > +#ifdef CONFIG_SYSTEM_SUSPEND > + ipmmu_free_ctx_suspend(dev); > +#endif > + return ret; > +#endif > } > > static int ipmmu_iommu_domain_init(struct domain *d) > @@ -1492,6 +1779,10 @@ static const struct iommu_ops ipmmu_iommu_ops = > .unmap_page = arm_iommu_unmap_page, > .dt_xlate = ipmmu_dt_xlate, > .add_device = ipmmu_add_device, > +#ifdef CONFIG_SYSTEM_SUSPEND > + .suspend = ipmmu_suspend, > + .resume = ipmmu_resume, > +#endif > }; > > static __init int ipmmu_init(struct dt_device_node *node, const void *data) From xen-devel-bounces@lists.xenproject.org Sat Jan 31 17:01:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 31 Jan 2026 17:01:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1218177.1527117 (Exim 4.92) (envelope-from ) id 1vmELE-0005RK-C8; Sat, 31 Jan 2026 17:01:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1218177.1527117; Sat, 31 Jan 2026 17:01:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vmELE-0005RD-8s; Sat, 31 Jan 2026 17:01:00 +0000 Received: by outflank-mailman (input) for mailman id 1218177; Sat, 31 Jan 2026 17:00: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 1vmELC-0005R5-Mu for xen-devel@lists.xenproject.org; Sat, 31 Jan 2026 17:00: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 696c31ac-fec6-11f0-b161-2bf370ae4941; Sat, 31 Jan 2026 18:00:57 +0100 (CET) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-6580dbdb41eso4863279a12.0 for ; Sat, 31 Jan 2026 09:00:57 -0800 (PST) Received: from [192.168.0.109] ([91.123.155.165]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-658b4453094sm5430433a12.14.2026.01.31.09.00.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 31 Jan 2026 09:00:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 696c31ac-fec6-11f0-b161-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769878857; x=1770483657; 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=2bhQQevyf9AdeIPxUCE2YsbW12q7eOLP2FUGRr8woF4=; b=F6QPRwgn1uNw9/JD1vuwNBY5N1R8Ha/G6KxV8dLhnsOTg2gpUTFYBf57b4A8zp2Wwc sEUtMnnJWRqNMbP20l9L6bL0Ms5d83434EgdKcd6vhMii9iDjGbeJr3iza20jyz/mL52 n3jjmzxPY6F2FJ3lTs1VgtzD8oczzp1LJ8CWH1/zsgr0dbrvR781CmuwkehFMVFZr30Q f7Fq+C/YZz5p9cdrAQJ+wk+rZskZJG/RpTL1nJVXRep7PQvcer1v7/fLvItDL0hT/SC4 gUT8UARrXoXaEXNFuyVMt3pgeHR22sIFittnVgNJFxeOQQ2JC6OUwT/nXK7J92rYx6me jJZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769878857; x=1770483657; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2bhQQevyf9AdeIPxUCE2YsbW12q7eOLP2FUGRr8woF4=; b=vrBeUpsjgs0PN8yHgZfhGPAIaSVjeho/zCoGdWYPhs0r6DD6DDLrMCHHZBGVzODoGR 7EHpbNMvxkXkJTjCypHHB98a8HJCLrICa/bBs8ZdgiE7NRSdtMl+vaKJq3rtuZkP7sqW hJ8Lng/04/ZylgZt4BlNozYuFp2t/zAX0yiYIM14pn18mjOey/UR6c+cskw2h84STJ+F 1Xe53b2PRilXRc1+jE4YItr0Ndq6kvkd+2kOmWS6XiSrthKd+yXDW4d9jiqyc83spttu v/O850Pec/FcBLhWiX4cxJsQH0Du5Q2zdjoaKAKITl81zQz+YjGPle/Si43Yko6j9NhA aFVg== X-Forwarded-Encrypted: i=1; AJvYcCWGbp5CR2Uqn9eieOnWNshpoYcjpI4uPbZuAQWwbGMOK+mA7IAd+PtRNfEyBTgg9ir9QOXl59o7cRA=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywo3FGUxkHRI7h++/kQtKbVmAEEFR0YkpQYhIC67M3EYl7f6K42 yeD2/r2rijCgeG77zcSD/njWUxeZLeHlwu4mO9ZBu+VdZBFiUMhicSDd X-Gm-Gg: AZuq6aIJq2crMdyRjEdNdu+Juv0zaBQR/gXNxBc+VvVT/1Jg4JICazh9O0zUP8oLMnZ F8qwXfLZgKp2OvSrRrE+GIt/Ae+LcAn9aalaBvh9FOW3IL/LQZfc1bIaI9BgOKbO832XJVOFfgQ 7lr/jLuZVqzW6GkLAXgh6wTWr+mNQngJz5M9U+CcFAvrnmjzB6gSwtiWoeclY5331pLHD0amsZt 2gbliSC9NhulXdZ/zVxDG9+nC+gjfMI9HmeGESDLhJz7dIApnUYCrU8KACKS16doe7R22f09a9V 2JQ/QSi9a1iDZIH80o1cRnyIr1lalmRFePGMM8J9lvbdR5jBTC6Uv7WSHnjslNoF6Khyqr46+i6 LjkVWjwWiBzskiYLt+Py0aWKUWzgJ3L3ALBgXLn8TjdMn+gV1wornknNVVsoeTyfAce8Yg8OsE6 rWbG92THoL5rwx27nkT172hgSEZw== X-Received: by 2002:a05:6402:50ca:b0:658:c177:7510 with SMTP id 4fb4d7f45d1cf-658de544fdfmr4025009a12.7.1769878856595; Sat, 31 Jan 2026 09:00:56 -0800 (PST) Message-ID: <7c93f37d-3699-454e-abb9-4499b08d0654@gmail.com> Date: Sat, 31 Jan 2026 19:00:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 04/12] xen/arm: gic-v3: add ITS suspend/resume support To: Mykola Kvach , 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_Pau_Monn=C3=A9?= References: <2fade2b96128053fbe3ed59f1d5e3444b32b96c3.1765472890.git.mykola_kvach@epam.com> Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: <2fade2b96128053fbe3ed59f1d5e3444b32b96c3.1765472890.git.mykola_kvach@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11.12.25 20:43, Mykola Kvach wrote: Hello Mykola > From: Mykola Kvach > > Handle system suspend/resume for GICv3 with an ITS present so LPIs keep > working after firmware powers the GIC down. Snapshot the CPU interface, > distributor and last-CPU redistributor state, disable the ITS to cache its > CTLR/CBASER/BASER registers, then restore everything and re-arm the > collection on resume. > > Add list_for_each_entry_continue_reverse() in list.h for the ITS suspend > error path that needs to roll back partially saved state. > > Based on Linux commit: dba0bc7b76dc ("irqchip/gic-v3-its: Add ability to save/restore ITS state") > Signed-off-by: Mykola Kvach > --- > xen/arch/arm/gic-v3-its.c | 91 +++++++++++++++++++++++++++ > xen/arch/arm/gic-v3.c | 15 ++++- > xen/arch/arm/include/asm/gic_v3_its.h | 23 +++++++ > xen/include/xen/list.h | 14 +++++ > 4 files changed, 140 insertions(+), 3 deletions(-) > > diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c > index 34833166ad..08a3d8d1ef 100644 > --- a/xen/arch/arm/gic-v3-its.c > +++ b/xen/arch/arm/gic-v3-its.c > @@ -1209,6 +1209,97 @@ int gicv3_its_init(void) > return 0; > } > > +#ifdef CONFIG_SYSTEM_SUSPEND > +int gicv3_its_suspend(void) > +{ > + struct host_its *its; > + int ret; > + > + list_for_each_entry(its, &host_its_list, entry) > + { > + unsigned int i; > + void __iomem *base = its->its_base; > + > + its->suspend_ctx.ctlr = readl_relaxed(base + GITS_CTLR); > + ret = gicv3_disable_its(its); > + if ( ret ) > + { > + writel_relaxed(its->suspend_ctx.ctlr, base + GITS_CTLR); > + goto err; > + } > + > + its->suspend_ctx.cbaser = readq_relaxed(base + GITS_CBASER); > + > + for (i = 0; i < GITS_BASER_NR_REGS; i++) { > + uint64_t baser = readq_relaxed(base + GITS_BASER0 + i * 8); > + > + if ( !(baser & GITS_VALID_BIT) ) > + continue; > + > + its->suspend_ctx.baser[i] = baser; > + } > + } > + > + return 0; > + > + err: > + list_for_each_entry_continue_reverse(its, &host_its_list, entry) > + writel_relaxed(its->suspend_ctx.ctlr, its->its_base + GITS_CTLR); > + > + return ret; > +} > + > +void gicv3_its_resume(void) > +{ > + struct host_its *its; > + int ret; > + > + list_for_each_entry(its, &host_its_list, entry) > + { > + void __iomem *base; > + unsigned int i; > + > + base = its->its_base; > + > + /* > + * Make sure that the ITS is disabled. If it fails to quiesce, > + * don't restore it since writing to CBASER or BASER > + * registers is undefined according to the GIC v3 ITS > + * Specification. > + * > + * Firmware resuming with the ITS enabled is terminally broken. > + */ > + WARN_ON(readl_relaxed(base + GITS_CTLR) & GITS_CTLR_ENABLE); > + ret = gicv3_disable_its(its); > + if ( ret ) > + continue; If ITS fails to disable (quiesce), the code skips restoration and ITS remains in an unconfigured state. However, immediately after the loop ... > + > + writeq_relaxed(its->suspend_ctx.cbaser, base + GITS_CBASER); > + > + /* > + * Writing CBASER resets CREADR to 0, so make CWRITER and > + * cmd_write line up with it. NIT: The variable "cmd_write" does not exist in the Xen driver. As I understand, this comment was ported from the Linux kernel driver as is, which maintains a software shadow copy of the write pointer named "cmd_write". > + */ > + writeq_relaxed(0, base + GITS_CWRITER); > + > + /* Restore GITS_BASER from the value cache. */ > + for (i = 0; i < GITS_BASER_NR_REGS; i++) { > + uint64_t baser = its->suspend_ctx.baser[i]; > + > + if ( !(baser & GITS_VALID_BIT) ) > + continue; > + > + writeq_relaxed(baser, base + GITS_BASER0 + i * 8); > + } > + writel_relaxed(its->suspend_ctx.ctlr, base + GITS_CTLR); > + } > + > + ret = gicv3_its_setup_collection(smp_processor_id()); ... this function iterates over all host ITS instances (including the one we skipped) and attempts to send MAPC commands. I am afraid, that attempting to write to the command queue of an uninitialized/unrestored ITS might have bad consequences. > + if ( ret ) > + panic("GICv3: ITS: resume setup collection failed: %d\n", ret); > +} > + > +#endif /* CONFIG_SYSTEM_SUSPEND */ > [snip] From xen-devel-bounces@lists.xenproject.org Sat Jan 31 17:42:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 31 Jan 2026 17:42:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1218195.1527127 (Exim 4.92) (envelope-from ) id 1vmEz0-00028G-9i; Sat, 31 Jan 2026 17:42:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1218195.1527127; Sat, 31 Jan 2026 17: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 1vmEz0-000289-63; Sat, 31 Jan 2026 17:42:06 +0000 Received: by outflank-mailman (input) for mailman id 1218195; Sat, 31 Jan 2026 17: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 1vmEyy-000283-Uo for xen-devel@lists.xenproject.org; Sat, 31 Jan 2026 17:42:04 +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 268b6b14-fecc-11f0-b161-2bf370ae4941; Sat, 31 Jan 2026 18:42:02 +0100 (CET) Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-b872f1c31f1so404215966b.0 for ; Sat, 31 Jan 2026 09:42:02 -0800 (PST) Received: from [192.168.0.109] ([91.123.155.165]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-658b4256a92sm5664393a12.5.2026.01.31.09.41.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 31 Jan 2026 09:42:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 268b6b14-fecc-11f0-b161-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769881322; x=1770486122; 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=EGzVawKXaeV8L7wcprQQ5jGf+RpWYe0HrXbbkHxwQ9I=; b=iO4Wocc3e0FvjOJMdka2HHxaskVU+TMzXT8EkHKjQpMR6YbOx3tgF7pfKEOFHFflQ3 rj9bYwUoi2CBp8sqvU3Bu/fz+kdxxihFgsesQc53nzXx0E+5PJZ4N1Q7uPclDrInRMzR qUn0hbluxXOadL/oeXIKCwoQmDXMs8Va6tYDO+ej6mcDYOrTQDYIalscJPFK9Iaw9P2y imHTyxvDGL8cmMTjuQ4m3KjjY1Tjge6Io97F2acJqvmh1NpX9Sa0UeqQkApvKIsgeX2Q Uf1awsMvhLiUozdsH3AG+mDYifVVMPb4kwMHXGqkUsqetIcmOGnL9MD4eEK7FTTcvRtx lbHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769881322; x=1770486122; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EGzVawKXaeV8L7wcprQQ5jGf+RpWYe0HrXbbkHxwQ9I=; b=Pu6Pfbf/ftHhEt6bn6nYgRQ1FBeAnkqqctgvTSZTZ1QmvFlyD3690R/HsqszsQKmUX LH+et2gd6b8QRo+ZO7ufxKzenLd8UUCjW5uFZ1XUdJGgIADegUekKQBaio5dh6I5XnKO HuB9rxy/zU+bluL+Q38N3GlV4n+e9/BdSaiZaqcHnk8wB/S2pfkp0STf4GMd8KQlPddT r9qG5Oy/C3s6MvuGNaERRP2RKtzbBmscYHW7VeXDKsTRs21KE0woI5sdjl8b51alrWjA Y4PxJZSjqBMDFzOrQCYx8eHh2q0sdoXQF6OmMJ92tBHWNNroesakrKPnyFYDG3niwiLI DS5Q== X-Forwarded-Encrypted: i=1; AJvYcCW81t8t9coCuM/X2wGDhHBAQzh/fZR79OW5/Usg9LAILH0q8tPFUhQMFh5k927IPYnl97YMODUsXCc=@lists.xenproject.org X-Gm-Message-State: AOJu0YxA/S/0qAhYbd4lLwnrxtwJcCO8HQccjgmHuDZeXUloai0wYbCe T1UOAXYGOtpz10rWfNsxfsH+jf9PucmPr2s7xVbTksmkXdHdhnZNvXbB X-Gm-Gg: AZuq6aIwMtzLZ8p1lK7R8yA6Ri08F29n/sazg2WU+x70Do6DH2oXsXWfC13MFL6Q4Lu 5FnfoJE2YxYiKurWvnE7kvM5dYXnXJzlypj39zOKDgTB5c6FR+g5A9HJ8rYS8JRtv1Qo79dJNJo 4V6ZFy05K9N8rbvJxcqeoBOZ/vqXV+LVh+9o/i/zc/5QjQh0Jbi/OGiyxOnWeRNQuIyJ6cP7plL 1MMGLfCh67+74/8Rlj7rkWDFLA2FepR3UcVJl//mBe33aEhXmPlqXRQgE/OciKvETflnNk66IBH 7jra2D8uSb4pN5FHg8x7RpZJBGAVCW2gClDAogViA0iQfme8t0LiByr7L3ZiLDDxQ8PE6Gn545q tXwMbyPDoU7rQtxN7cv2QP2MYUBgGYRr1wuzX5KUqi3Pk9CGmR0GbBxRgYDWbIL9KmxJC+Mz1vx d8cPO3NiNicnqSt3w= X-Received: by 2002:a17:907:608d:b0:b87:778b:89ba with SMTP id a640c23a62f3a-b8dff684809mr416646566b.39.1769881321278; Sat, 31 Jan 2026 09:42:01 -0800 (PST) Message-ID: Date: Sat, 31 Jan 2026 19:41:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 08/12] arm/smmu-v3: add suspend/resume handlers To: Mykola Kvach , xen-devel@lists.xenproject.org Cc: Mykola Kvach , Bertrand Marquis , Rahul Singh , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk , Pranjal Shrivastava References: <58c1873d355f5ea9b5182349895905d25cb57256.1765472890.git.mykola_kvach@epam.com> Content-Language: en-US From: Oleksandr Tyshchenko In-Reply-To: <58c1873d355f5ea9b5182349895905d25cb57256.1765472890.git.mykola_kvach@epam.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11.12.25 20:43, Mykola Kvach wrote: Hello Mykola > From: Mykola Kvach > > Before we suspend SMMU, we want to ensure that all commands (especially > ATC_INV) have been flushed by the CMDQ, i.e. the CMDQs are empty. > > The suspend callback configures the SMMU to abort new transactions, > disables the main translation unit and then drains the command queue > to ensure completion of any in-flight commands. > > The resume callback performs a full device reset via 'arm_smmu_device_reset' > to bring the SMMU back to an operational state. > > Link: https://lore.kernel.org/linux-iommu/20251117191433.3360130-1-praan@google.com / > Based-on-patch-by: Pranjal Shrivastava > Signed-off-by: Mykola Kvach > --- > xen/drivers/passthrough/arm/smmu-v3.c | 170 ++++++++++++++++++++------ > 1 file changed, 134 insertions(+), 36 deletions(-) > > diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c > index bf153227db..10c4c5dee0 100644 > --- a/xen/drivers/passthrough/arm/smmu-v3.c > +++ b/xen/drivers/passthrough/arm/smmu-v3.c > @@ -1814,8 +1814,7 @@ static int arm_smmu_write_reg_sync(struct arm_smmu_device *smmu, u32 val, > } > > /* GBPA is "special" */ > -static int __init arm_smmu_update_gbpa(struct arm_smmu_device *smmu, > - u32 set, u32 clr) > +static int arm_smmu_update_gbpa(struct arm_smmu_device *smmu, u32 set, u32 clr) > { > int ret; > u32 reg, __iomem *gbpa = smmu->base + ARM_SMMU_GBPA; > @@ -1995,10 +1994,29 @@ err_free_evtq_irq: > return ret; > } > > +static int arm_smmu_enable_irqs(struct arm_smmu_device *smmu) > +{ > + int ret; > + u32 irqen_flags = IRQ_CTRL_EVTQ_IRQEN | IRQ_CTRL_GERROR_IRQEN; > + > + if ( smmu->features & ARM_SMMU_FEAT_PRI ) > + irqen_flags |= IRQ_CTRL_PRIQ_IRQEN; > + > + /* Enable interrupt generation on the SMMU */ > + ret = arm_smmu_write_reg_sync(smmu, irqen_flags, > + ARM_SMMU_IRQ_CTRL, ARM_SMMU_IRQ_CTRLACK); > + if ( ret ) > + { > + dev_warn(smmu->dev, "failed to enable irqs\n"); > + return ret; > + } > + > + return 0; > +} > + > static int __init arm_smmu_setup_irqs(struct arm_smmu_device *smmu) > { > int ret, irq; > - u32 irqen_flags = IRQ_CTRL_EVTQ_IRQEN | IRQ_CTRL_GERROR_IRQEN; > > /* Disable IRQs first */ > ret = arm_smmu_write_reg_sync(smmu, 0, ARM_SMMU_IRQ_CTRL, > @@ -2028,22 +2046,7 @@ static int __init arm_smmu_setup_irqs(struct arm_smmu_device *smmu) > } > } > > - if (smmu->features & ARM_SMMU_FEAT_PRI) > - irqen_flags |= IRQ_CTRL_PRIQ_IRQEN; > - > - /* Enable interrupt generation on the SMMU */ > - ret = arm_smmu_write_reg_sync(smmu, irqen_flags, > - ARM_SMMU_IRQ_CTRL, ARM_SMMU_IRQ_CTRLACK); > - if (ret) { > - dev_warn(smmu->dev, "failed to enable irqs\n"); > - goto err_free_irqs; > - } > - > return 0; > - > -err_free_irqs: > - arm_smmu_free_irqs(smmu); > - return ret; > } > > static int arm_smmu_device_disable(struct arm_smmu_device *smmu) > @@ -2057,7 +2060,7 @@ static int arm_smmu_device_disable(struct arm_smmu_device *smmu) > return ret; > } > > -static int __init arm_smmu_device_reset(struct arm_smmu_device *smmu) > +static int arm_smmu_device_reset(struct arm_smmu_device *smmu) > { > int ret; > u32 reg, enables; > @@ -2163,17 +2166,9 @@ static int __init arm_smmu_device_reset(struct arm_smmu_device *smmu) > } > } > > - ret = arm_smmu_setup_irqs(smmu); > - if (ret) { > - dev_err(smmu->dev, "failed to setup irqs\n"); > + ret = arm_smmu_enable_irqs(smmu); > + if ( ret ) > return ret; > - } > - > - /* Initialize tasklets for threaded IRQs*/ > - tasklet_init(&smmu->evtq_irq_tasklet, arm_smmu_evtq_tasklet, smmu); > - tasklet_init(&smmu->priq_irq_tasklet, arm_smmu_priq_tasklet, smmu); > - tasklet_init(&smmu->combined_irq_tasklet, arm_smmu_combined_irq_tasklet, > - smmu); > > /* Enable the SMMU interface, or ensure bypass */ > if (disable_bypass) { > @@ -2181,20 +2176,16 @@ static int __init arm_smmu_device_reset(struct arm_smmu_device *smmu) > } else { > ret = arm_smmu_update_gbpa(smmu, 0, GBPA_ABORT); > if (ret) > - goto err_free_irqs; > + return ret; > } > ret = arm_smmu_write_reg_sync(smmu, enables, ARM_SMMU_CR0, > ARM_SMMU_CR0ACK); > if (ret) { > dev_err(smmu->dev, "failed to enable SMMU interface\n"); > - goto err_free_irqs; > + return ret; > } > > return 0; > - > -err_free_irqs: > - arm_smmu_free_irqs(smmu); > - return ret; > } > > static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu) > @@ -2558,10 +2549,23 @@ static int __init arm_smmu_device_probe(struct platform_device *pdev) > if (ret) > goto out_free; > > + ret = arm_smmu_setup_irqs(smmu); > + if ( ret ) > + { > + dev_err(smmu->dev, "failed to setup irqs\n"); > + goto out_free; > + } > + > + /* Initialize tasklets for threaded IRQs*/ > + tasklet_init(&smmu->evtq_irq_tasklet, arm_smmu_evtq_tasklet, smmu); > + tasklet_init(&smmu->priq_irq_tasklet, arm_smmu_priq_tasklet, smmu); > + tasklet_init(&smmu->combined_irq_tasklet, arm_smmu_combined_irq_tasklet, > + smmu); > + > /* Reset the device */ > ret = arm_smmu_device_reset(smmu); > if (ret) > - goto out_free; > + goto out_free_irqs; > > /* > * Keep a list of all probed devices. This will be used to query > @@ -2575,6 +2579,8 @@ static int __init arm_smmu_device_probe(struct platform_device *pdev) > > return 0; > > +out_free_irqs: > + arm_smmu_free_irqs(smmu); > > out_free: > arm_smmu_free_structures(smmu); > @@ -2855,6 +2861,94 @@ static void arm_smmu_iommu_xen_domain_teardown(struct domain *d) > xfree(xen_domain); > } > > +#ifdef CONFIG_SYSTEM_SUSPEND > + > +static int arm_smmu_suspend(void) > +{ > + struct arm_smmu_device *smmu; > + int ret = 0; > + > + list_for_each_entry(smmu, &arm_smmu_devices, devices) > + { > + /* Abort all transactions before disable to avoid spurious bypass */ > + ret = arm_smmu_update_gbpa(smmu, GBPA_ABORT, 0); > + if ( ret ) > + goto fail; > + > + /* Disable the SMMU via CR0.EN and all queues except CMDQ */ > + ret = arm_smmu_write_reg_sync(smmu, CR0_CMDQEN, ARM_SMMU_CR0, > + ARM_SMMU_CR0ACK); > + if ( ret ) > + { > + dev_err(smmu->dev, "Timed-out while disabling smmu\n"); > + goto fail; > + } > + > + /* > + * At this point the SMMU is completely disabled and won't access > + * any translation/config structures, even speculative accesses > + * aren't performed as per the IHI0070 spec (section 6.3.9.6). > + */ > + > + /* Wait for the CMDQs to be drained to flush any pending commands */ > + ret = queue_poll_cons(&smmu->cmdq.q, true, 0); I wonder, why ignoring ARM_SMMU_FEAT_SEV in suspend? In the runtime function __arm_smmu_cmdq_issue_sync(), the driver checks if the SMMU supports ARM_SMMU_FEAT_SEV and passes this flag to queue_poll_cons(). However, here, this check is missing, and the wfe argument is hardcoded to 0. > + if ( ret ) > + { > + dev_err(smmu->dev, "Draining queues timed-out\n"); > + goto fail; > + } > + > + /* Disable everything */ > + ret = arm_smmu_device_disable(smmu); > + if ( ret ) > + goto fail; > + > + dev_dbg(smmu->dev, "Suspended smmu\n"); > + } > + > + return 0; > + > + fail: > + { > + int rc; > + > + /* Reset the device that failed as well as any already-suspended ones. */ > + rc = arm_smmu_device_reset(smmu); > + if ( rc ) > + dev_err(smmu->dev, "Failed to reset during resume operation: %d\n", rc); > + > + list_for_each_entry_continue_reverse(smmu, &arm_smmu_devices, devices) > + { > + rc = arm_smmu_device_reset(smmu); > + if ( rc ) > + dev_err(smmu->dev, "Failed to reset during resume operation: %d\n", rc); > + } NIT: Could this duplicated reset call (and error message) be optimized somehow? Maybe, by using a do-while loop to manually walk back up the list from the current SMMU to the head, but not sure. > + } > + > + return ret; > +} > + > +static void arm_smmu_resume(void) > +{ > + int ret; > + struct arm_smmu_device *smmu; > + > + list_for_each_entry(smmu, &arm_smmu_devices, devices) > + { > + dev_dbg(smmu->dev, "Resuming device\n"); > + > + /* > + * The reset will re-initialize all the base addresses, queues, > + * prod and cons maintained within struct arm_smmu_device as well as > + * re-enable the interrupts. > + */ > + ret = arm_smmu_device_reset(smmu); > + if ( ret ) > + dev_err(smmu->dev, "Failed to reset during resume operation: %d\n", ret); In your GICv3 ITS patch, a failure during resume triggers a panic(), but here only an error message that might go unnoticed. May I please ask, why such diverging? The IOMMU is as critical as the Interrupt Controller. I see that you configure Abort state during suspend, so if I understand the things correctly - if the SMMU fails to reset (e.g., remains in GBPA_ABORT), all DMA for for any passed-through devices behind it will be blocked after resuming. > + } > +} > +#endif > + > static const struct iommu_ops arm_smmu_iommu_ops = { > .page_sizes = PAGE_SIZE_4K, > .init = arm_smmu_iommu_xen_domain_init, > @@ -2867,6 +2961,10 @@ static const struct iommu_ops arm_smmu_iommu_ops = { > .unmap_page = arm_iommu_unmap_page, > .dt_xlate = arm_smmu_dt_xlate, > .add_device = arm_smmu_add_device, > +#ifdef CONFIG_SYSTEM_SUSPEND > + .suspend = arm_smmu_suspend, > + .resume = arm_smmu_resume, > +#endif > }; > > static __init int arm_smmu_dt_init(struct dt_device_node *dev,